10:43 <tasslehoff> anyone got a kernel cmdline that gives 720p@60? struggling to make this work..

10:51 <simmel80_> tasslehoff: when it does not work, it does not work, we (me and a colleague) haven given up on fixing it through commandline

10:51 <simmel80_> it depends on the display that is attached to the hdmi

10:52 <tasslehoff> simmel80_: yeah. with hdmi-dvi I got almost no modes. with hdmi-hdmi I got more modes, but it still didn't use 720p

10:52 <simmel80_> the wandboard, resp. them imx6, reacts differently to different displays

10:52 <tasslehoff> if I don't specify anything, it uses 1080p

10:53 <tasslehoff> otherwise it falls back to 480p

10:53 <tasslehoff> ok

10:53 <simmel80_> i would suggest putting some debug printout into the drivers

10:53 <simmel80_> mx ipu v3 fb driver, its hdmi component, and the dvi parser

10:53 <simmel80_> all from freescale

10:54 <simmel80_> or try with the upstream (drm) drivers

10:54 <simmel80_> but this would mean different kernel, probably

10:55 <tasslehoff> simmel80_: ok. on 3.0.17 (yocto 1.6) now.

10:55 <simmel80_> like me

10:55 <simmel80_> ah and another thing

10:55 <simmel80_> if you happen to use xorg, you can teach the thing more modes with xrandr

10:55 <tasslehoff> if I boot without hdmi connected to the wandboard I get lots of modes to choose from.

10:55 <tasslehoff> no x here :)

10:56 <simmel80_> i guess i could work also using framebuffer ioctl

10:56 <simmel80_> hm

10:57 <simmel80_> boot without display, get the parameters for the desired mode with fb ioctl, then try to set these parameters, with display connected?

10:57 <tasslehoff> and then echo "D:1920x1080p-60" > /sys/class/graphics/fb0/mode works fine

10:58 <simmel80_> but just for switching modes

10:58 <simmel80_> i never tried it, but the code makes me believe that you could also teach it a new mode via sysfs

10:59 <simmel80_> but it would involve cat-ing binary data into sysfs, iirc, a struct deatiling the mode, from linux/fb.h

11:01 <simmel80_> i would really suggest having a look at the driver though, to see how it interprets the edid, and from there see why it fails

11:01 <tasslehoff> simmel80_: will have to do that.

11:04 <simmel80_> mxc_ipuv3_fb.c and mxc_hdmi.c are kind of glued together with mxc_dispdrv.c, i guess mxc_hdmi calls into mxc_edid.c, but only needs it for the edid extensions stuff, the base edid is probably parsed by the regular kernel edid parser

11:06 <simmel80_> fbmon.c

16:37 <codinho> is there any standard way to test hw parts of board using fsl-community-bsp-platform? I can see unit_tests directory in deployed image, but looks like all of the testing scripts are not working and fails even on sabrelite

17:15 <codinho> I meant something to test new custom board hw

17:54 <rz2k> codinho: run 4x linpack and glmark2-es2 at the same time

17:54 <rz2k> best way to hung exynos4412 boards

17:54 <rz2k> should do on imx6 too :p