[meta-freescale] No HDMI video on imx6qsabresd with dizzy

[Nikolay Dimitrov]

Hi Andreas,

On 11/13/2014 05:48 PM, Andreas Müller wrote:
> On Thu, Nov 13, 2014 at 4:17 PM, Nikolay Dimitrov <picmaster at mail.bg> wrote:
>> Hi Andreas,
>>
>>
>> On 11/13/2014 11:29 AM, Andreas Müller wrote:
>>>
>>> On Wed, Nov 12, 2014 at 11:58 PM, Nikolay Dimitrov <picmaster at mail.bg>
>>> wrote:
>>>>
>>>> Hi guys,
>>>>
>>>> I'm trying to use unmodified dizzy build with imx6q sabresd, for
>>>> testing video playback. U-Boot outputs HDMI image during boot, but in
>>>> Linux there's no HDMI image (no console, no video playback).
>>>>
>>>> The image is "fsl-image-multimedia-full", kernel 3.10.17. The device
>>>> files /dev/video* and /dev/fb* are available, but gstreamer playback
>>>> doesn't output any image on the HDMI port (seems to be stuck instead of
>>>> playing).
>>>>
>>>> The kernel cmdline doesn't specify any video settings, which typically
>>>> is an issue, but when I add the video bootargs:
>>>>
>>>> ...video=mxcfb0:dev=hdmi,1024x768M at 60,if=RGB24...
>>>>
>>>> The board stops to print any boot messages after "Starting kernel..."
>>>> and seems to be stuck. Removing the video bootargs allows again to boot
>>>> normally.
>>>>
>>>> I must admit that I'm somewhat puzzled by this behavior, as I already
>>>> have daizy running with 3.10.17 on a custom board, and the video is
>>>> working there with almost the same bootargs. Do you guys have any ideas
>>>> for how to configure imx6q sabresd for HDMI video?
>>>>
>>>> Thanks in advance. Regards,
>>>> Nikolay
>>>> --
>>>
>>> Had same here.
>>>
>>> I think there are two problems:
>>> * 3.10.17 EDID decoding works only for monitors with EDID extended
>>> blocks (patch 0001..)
>>> * 1024x768 is not a CEA mode. If I read the code of 3.10.17 correct,
>>> HDMI supports only modes which are found in
>>> drivers/video/mxc/mxc_edid.c const struct fb_videomode
>>> mxc_cea_mode[64]. I hacked up working solution (patch 0002..). Note
>>> that this is just a hack - it might lead to incorrect colour space
>>> conversion or wrong PixelRepetitionOutput (see mxc_hdmi_setup:
>>> hdmi->vic is always 0 for my patches).
>>>
>>> These patches were tested with two monitors (1280x1024 / 1650x<I
>>> forgot>) and seem to work fine.
>>
>>
>> Thanks for your detailed answer. I remember seeing discussions on the
>> net about a safe fallback resolution for imx6 hdmi, so that's the only
>> reason to choose 1024x768.
>>
>> Also, are you sure that the HDMI code doesn't use the CVT (Common VESA
>> Table) resolutions? Need to check this. I'll also look a the code
>> which you pointed me to, and try your patches.
>>
>> I'm not looking for big or pixel-exact resolutions on HDMI, just some
>> reasonable resolution so I can test my gstreamer issues there :).
>>
>> Regards,
>> Nikolay
> After re reading this thread I saw that my patches are addressing a
> different problem. In short: Whatever monitor I connected to HDMI (via
> DVI) I got only 640x480 and complaints like
>
> [    0.829299] mxc_hdmi 20e0000.hdmi_video: mxc_edid_read_internal
> [    0.960509] mxc_hdmi 20e0000.hdmi_video: Read EDID again
> [    0.960522] mxc_hdmi 20e0000.hdmi_video: mxc_edid_read_internal
> [    1.091703] mxc_hdmi 20e0000.hdmi_video: No modes read from edid
> [    1.091714] mxc_hdmi 20e0000.hdmi_video: create default modelist

Ahh, I see. Yes, I also think they are 2 separate issues. Still, thanks 
for trying to help.

Regards,
Nikolay