Hi All,
I am using android from this branch boundary-imx-android-r13.4-ga @ https://github.com/boundarydevices/linux-imx6/tree/boundary-imx-android-r13.4-ga
@ git://github.com/boundarydevices/imx-android-r13.4-ga.git
While using faytech 10" HDMI display, I am getting android ICS running/displaying well on HDMI with resolution 1280x1024@60, while the sound card:1 imx-hdmi-soc won't respond audio.
Following are the debug parameters..
kernel command line has HDMI resolution:
video=mxcfb0:dev=hdmi,1280x1024M@60,if=RGB24
root@mx6q:~# aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: sgtl5000audio [sgtl5000-audio], device 0: HiFi sgtl5000-0 []
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: imxhdmisoc [imx-hdmi-soc], device 0: IMX HDMI TX mxc-hdmi-soc-0 []
Subdevices: 1/1
Subdevice #0: subdevice #0
root@mx6q:~# zcat /proc/config.gz | grep HDMI
CONFIG_IMX_HAVE_PLATFORM_MXC_HDMI=y
CONFIG_MFD_MXC_HDMI=y
CONFIG_FB_MXC_HDMI=y
CONFIG_SND_SOC_IMX_HDMI=y
CONFIG_SND_SOC_MXC_HDMI=y
# MXC HDMI CEC (Consumer Electronics Control) support
# CONFIG_MXC_HDMI_CEC is not set
root@mx6q:~# cat /sys/class/graphics/fb0/mode
S:1280x1024p-60
root@mx6q:~# cat /sys/class/graphics/fb0/modes
S:1920x1080p-60
S:720x480p-60
S:1280x720p-60
U:1680x1680p-60
U:1440x1440p-60
S:1280x1024p-60
U:800x450p-60
V:1024x768p-60
V:640x480p-60
D:1280x720p-60
D:800x480p-60
U:640x480p-60
root@mx6q:~#
root@mx6q:~# aplay -D hw:1,0 Albinoni.wav
Playing WAVE 'Albinoni.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo
As in above mode list I am getting 1280x1024@60 as supported mode, also android home-screen fits well (all home-screen corner controls visible) on HDMI displays with only this resolution.,
But the imx-hdmi-soc sound card : 1 not responding audio.
While debugging the mxc_hdmi_setup related functionality observed that my selected mode falls under non-CEA mode,
It actually skips the HDMi initialization step E & F.
quick ref, @ https://github.com/boundarydevices/linux-imx6/blob/boundary-imx-android-r13.4-ga/drivers/video/mxc_h...
On other hand trying the CEA modes e.g. 1080p, as audio imx-hdmi-soc works well, But the faytech 10" HDMI monitor won't take actual resolution it displays around 1824x1026@60hz, which resulting into actual rendering area issue.i.e android home-screen won't fit well on display. [e.g. android touch-screen corner controls disappearing..]
CEA mode quick ref: http://blogimg.chinaunix.net/blog/upfile2/090903185737.pdf
Faytech 10" HDMI Display: quick manual ref: http://mypdfmanuals.com/dref/3595894
Please advice,
Anyone having similar thoughts, pointers or suggestions sharing will be a great help.
So far following these references..
https://community.freescale.com/thread/306901
https://community.freescale.com/thread/305063
https://community.freescale.com/thread/301965
http://boundarydevices.com/hdmi-cea-mode/
https://github.com/imx6-dongle/linux-imx/issues/14
So far tried in following ways.. please suggest on pointers if any..
forcing video mode 1920x1080 as fb_videomode but not much help,
@ https://github.com/boundarydevices/linux-imx6/blob/boundary-imx-android-r13.4-ga/drivers/video/mxc_h...
forcing 1280x1024 in mxc_cea_mode array but no much help.
@ https://github.com/boundarydevices/linux-imx6/blob/boundary-imx-android-r13.4-ga/drivers/video/mxc/m...
Thanks !
Shrikant Bobade
Solved! Go to Solution.
Here's what I've found from looking into it. I'm linking to the 3.5.7 kernel but the relevant code is the same in 3.0
The crux is the if statement based on mDVI as Eric mentioned and mDVI is set based on the VIC
VIC is the index in mxc_cea_modes in mxc_edid.c but it's more than that. It's part of the CEA specification, they write it to a register for heaven's sake.
Look at this function:
and this one:
Xindong Yu above says it's a matter of setting the pixel clock. But based on the above links, ie, the fact that VIC and mDVI are written to
and/or affect what's written to actual registers I'm not sure it's that simple if it's even possible.
When I changed the this if check
to look like it does in 3.5.7
so that (with Eric's change) everything got mDVI set to false I got the audio problems, some modes faster some slower, some static. IRCC,
there may have been a couple VIC = 0 modes that audio did work correctly but the problem is in here
which is called in the mDVI=false case. So that change did "set the pixel clock" but all the internal logic if you go into it calculates and
sets everything based strictly on the HDMI (and CEA) specs/tables which is wrong for arbitrary modes. It seems like it would be possible to extend
the cases/logic to handle more modes correctly but it's not straight forward.
In fact this isn't just about audio. I found that the video doesn't work some VIC=0 modes displayed. With my monitor, 1024x768@60 is displayed
as an option in EDID and thus in fb0/modes but it did not work. I tried booting with 1024x768M@60, R@60 and simply @60. In 2 cases it would be black
and flicker on for a second every minute or so in 1 it had extreme artifacts, red bands running vertically and flickering etc.
I've added a command line parameter for the module, only_cea which basically makes Eric's change a toggle. If you only want to see the modes that
definitely will work both video and audio, set only_cea to true.
https://github.com/boundarydevices/linux-imx6/commit/d4cc8b757f360c0d6c01cf8287580007fa1b7b8f
it defaults to false if unspecified of course and usually that's the way you'd want it because you will get more video modes that will work.
As for adding other modes, it seems to be possible
http://boundarydevices.com/freescale-ubuntu-image-with-4-0-0-kernel/#comment-47835
but as with everything else in this post, YMMV
Here's the CEA spec from 2008
http://blogimg.chinaunix.net/blog/upfile2/090903185624.pdf
Unfortunately I can't find a link to the HDMI spec ...
Here's what I've found from looking into it. I'm linking to the 3.5.7 kernel but the relevant code is the same in 3.0
The crux is the if statement based on mDVI as Eric mentioned and mDVI is set based on the VIC
VIC is the index in mxc_cea_modes in mxc_edid.c but it's more than that. It's part of the CEA specification, they write it to a register for heaven's sake.
Look at this function:
and this one:
Xindong Yu above says it's a matter of setting the pixel clock. But based on the above links, ie, the fact that VIC and mDVI are written to
and/or affect what's written to actual registers I'm not sure it's that simple if it's even possible.
When I changed the this if check
to look like it does in 3.5.7
so that (with Eric's change) everything got mDVI set to false I got the audio problems, some modes faster some slower, some static. IRCC,
there may have been a couple VIC = 0 modes that audio did work correctly but the problem is in here
which is called in the mDVI=false case. So that change did "set the pixel clock" but all the internal logic if you go into it calculates and
sets everything based strictly on the HDMI (and CEA) specs/tables which is wrong for arbitrary modes. It seems like it would be possible to extend
the cases/logic to handle more modes correctly but it's not straight forward.
In fact this isn't just about audio. I found that the video doesn't work some VIC=0 modes displayed. With my monitor, 1024x768@60 is displayed
as an option in EDID and thus in fb0/modes but it did not work. I tried booting with 1024x768M@60, R@60 and simply @60. In 2 cases it would be black
and flicker on for a second every minute or so in 1 it had extreme artifacts, red bands running vertically and flickering etc.
I've added a command line parameter for the module, only_cea which basically makes Eric's change a toggle. If you only want to see the modes that
definitely will work both video and audio, set only_cea to true.
https://github.com/boundarydevices/linux-imx6/commit/d4cc8b757f360c0d6c01cf8287580007fa1b7b8f
it defaults to false if unspecified of course and usually that's the way you'd want it because you will get more video modes that will work.
As for adding other modes, it seems to be possible
http://boundarydevices.com/freescale-ubuntu-image-with-4-0-0-kernel/#comment-47835
but as with everything else in this post, YMMV
Here's the CEA spec from 2008
http://blogimg.chinaunix.net/blog/upfile2/090903185624.pdf
Unfortunately I can't find a link to the HDMI spec ...
Thanks for collecting all of this information, Shrikant.
It seems that you've identified the source of the problem.
The line of code you pointed at seems to use the "mode" to determine whether or not to enable audio based on the mode.
That seems wrong.
As I read the EDID spec, the audio blocks are completely separate from the various supported video modes, so the driver should be asking "does the monitor support audio", and not "does the mode support audio".
Have you tried removing this conditional (always taking the CEA path)?
Thanks Eric for the response,
Yes, I have tried removing the mode based audio enabling condition.
Allowed 1280x1024@60 mode under CEA path. i.e. allowing to call step E & F. But the imx-hdmi-soc continues in same, audio not responding state.
Thanks
Shrikant
The audio work faster or slower or not work is expect if HDMI video run in Non-CEA mode, such as VESA mode 1024x768.
MX6 HDMI IP not support Non-CEA mode, though in most time the HDMI can work in VESA mode,
but it is not guarantee VESA mode work on all monitor.
In freescale HDMI audio driver, the n and cts is configure according the HDMI1.4 specification table 7-1.7-2 and 7-3.
The table is for CEA mode.
If HDMI work in non-CEA mode, for example, 1024x768
the HDMI audio n and cts will configure according pixel 74.25MHz, in table 7-1.
but the actual pixel clock for 1024x768 is 65MHz, so the audio will run faster.
If you want audio work well in 1024x768, the n and cts parameter should recalculate according 64MHz pixel clock.
Please reference HDMI 1.4 specification chapter 7.
But Freescale not commit the HDMI audio will work well on Non-CEA mode.