EDID and HDMI Audio not correct on Sony Bravia KLV-32J400A

Did you try forcing the mode as suggested by Rob Clark in email?

http://nouveau.freedesktop.org/wiki/KernelModeSetting

There are two kinds of resolution supported by the EDID information returned by the TV, sort of "VESA" modes and proper "HDMI" modes. Only the proper HDMI modes support piggybacking audio on the link.

I guess the heuristic is to use the highest resolution the TV reports it can handle that the display driver can also handle, and that resolution wins because it's higher than 720p HDMI resolution.

So I think the display driver is doing the right thing according to its rules and what the TV reported.

I'm not sure if i set the error video arguments, but the result is same -- 1360x768
cat /proc/cmdline --
"console=tty0 console=ttyO2,115200n8 root=UUID=62508d35-a5b1-412e-9d23-5ac79ae69
739 rootwait ro earlyprintk fixrtc nocompcache vram=48M omapfb.vram=0:24M mem=45
6M@0x80000000 mem=512M@0xA0000000 video=TV-1:1280x720@60"

boot up message --
[ 4.615447] fb0: omapdrm frame buffer device
[ 4.615447] drm: registered panic notifier
[ 4.624511] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[ 4.631591] [drm] No driver support for vblank timestamp query.
[ 4.638061] [drm] Initialized omapdrm 1.0.0 20110403 on minor 0

BTW, the TV support 1920x1080 and so it's not the highest resolution.

> BTW, the TV support 1920x1080 and so it's not the highest resolution.

Huh OK that does not sound good at all.

I will resume the thread with Rob Clark and point him to this bug since this his code he knows very well.

Feng Wei, could you add to your boot args "text debug drm.debug=7 console=ttyO2,115200n8"

That should be enough to get all the DRM traces enabled, and going to the serial port. If you could upload the boot log, that would be quite informative.

BR,
-R

After add drm.debug, and correct my original video settings to "video=HDMI-A-1:1280x720@60", the messages are listed below:
[ 4.001953] [drm:omap_drm_init], init
[ 4.005279] [drm:pdev_probe], omapdrm
[ 4.005279] [drm:drm_platform_init],
[ 4.013763] [drm:drm_get_platform_dev],
[ 4.013763] [drm:drm_get_minor],
[ 4.022521] [drm:drm_get_minor], new minor assigned 64
[ 4.022521] [drm:drm_get_minor],
[ 4.032073] [drm:drm_get_minor], new minor assigned 0
[ 4.037445] [drm:dev_load], load: dev=ef184800
[ 4.042358] [drm:omap_encoder_init], lcd
[ 4.046630] [drm:omap_encoder_init], tv
[ 4.050750] [drm:omap_encoder_init], lcd2
[ 4.055023] [drm:omap_connector_init], hdmi
[ 4.055023] [drm:drm_sysfs_connector_add], adding "HDMI-A-1" to sysfs
[ 4.066650] [drm:drm_sysfs_hotplug_event], generating hotplug event
[ 4.073486] [drm:omap_connector_init], dvi
[ 4.077362] [drm:drm_sysfs_connector_add], adding "DVI-D-1" to sysfs
[ 4.084869] [drm:drm_sysfs_hotplug_event], generating hotplug event
[ 4.092376] Not enabling generic panel as no connector is detected
[ 4.097442] [drm:omap_connector_init], dvi: failed to enable: 1
[ 4.105163] [drm:omap_connector_destroy], dvi
[ 4.109771] [drm:drm_sysfs_connector_remove], removing "DVI-D-1" from sysfs
[ 4.118286] omapdrm omapdrm.0: could not create connector
[ 4.124023] [drm:create_crtc], disconnecting gfx from tv
[ 4.124023] [drm:omap_connector_attached_encoder], hdmi: found tv
[ 4.134582] [drm:create_crtc], connecting gfx to tv
[ 4.139190] [drm:omap_crtc_init], gfx
[ 4.144744] [drm:omap_modeset_init], lcd: possible_crtcs=00000000
[ 4.151550] [drm:omap_modeset_init], tv: possible_crtcs=00000001
[ 4.157897] [drm:omap_modeset_init], lcd2: possible_crtcs=00000000
[ 4.159393] [drm:dump_video_chains], dumping video chains:
[ 4.166931] [drm:dump_video_chains], 0: gfx -> tv -> hdmi
[ 4.175994] [drm:dump_video_chains], 1: vid1 -> tv -> hdmi
[ 4.175994] [drm:dump_video_chains], 2: vid2 -> tv -> hdmi
[ 4.187561] [drm:omap_encoder_dpms], lcd: 3
[ 4.191986] [drm:omap_encoder_dpms], tv: 3
[ 4.196319] [drm:omap_encoder_dpms], lcd2: 3
[ 4.196319] [drm:omap_crtc_dpms], gfx: 3
[ 4.204956] [drm:commit], gfx
[ 4.204956] [drm:commit], 0x0 -> 0x0 (0)
[ 4.210754] [drm:commit], 0,0 (null) 00000000
[ 4.217010] [drm:drm_fb_helper_parse_command_line], cmdline mode for connector HDMI-A-1 1280x720@60Hz
[ 4.226776] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:6:HDMI-A-1]
[ 4.232452] [drm:omap_connector_get_modes], hdmi
[ 4.239013] [drm:omap_connector_native_mode], native mode from preferred: 1360x768@60
[ 4.239624] [drm:omap_connector_scaler_modes_add], adding scaler mode: 1280x720@60
[ 4.255889] [drm:omap_connector_scaler_modes_add], adding scaler mode: 1152x768@60
[ 4.260864] [drm:omap_connector_scaler_modes_add], adding scaler mode: 1024x768@60
[ 4.268829] [drm:omap_connector_scaler_modes_add], adding scaler mode: 800x600@60
[ 4.279785] [drm:omap_connector_scaler_modes_add], adding scaler mode: 720x480@59
[ 4.287689] [drm:omap_connector_scaler_modes_add], adding scaler mode: 640x48...

Although the monitor displayed 1280x720@60 as expected, there's a warning "could not apply the stored configurations for monitor" at the monitor when starting. And also I find a error message:
[ 4.259552] input: Panda Headset Jack as /devices/platform/soc-audio.0/sound/card0/input0
[ 4.267700] Error: Driver 'hdmi-audio-dai' is already registered, aborting...
[ 4.267700] OMAP4 HDMI audio SoC init
[ 4.268646] asoc: omap4-hdmi-audio-codec <-> hdmi-audio-dai mapping ok
[ 4.270812] ALSA device list:
[ 4.270812] #0: TI OMAP4 Board
[ 4.270812] #1: TI OMAP4 HDMI Board

After that running "aplay -l" cause seg fault, and aplay -l again, system hang at "**** List of PLAYBACK Hardware Devices ****"

From the EDID traces, it doesn't look like the monitor advertises 1920x1080 as a supported resolution. So the display driver is doing the "correct" thing and picking the highest supported resolution, which happens to be a VESA mode instead of CEA mode.

There is one possibility, in earlier versions of the drm driver, in omap_connector.c, there was a:

  #define MAX_EDID 256

which should have been:

  #define MAX_EDID 512

there is a slim chance that this is causing it to miss a 1920x1080 mode. Although I would have expected the 1080p timings to be in the first 128byte block of the EDID.

Beyond that, you need the pvr accelerated xorg driver (default xf86-video-fbdev does not support KMS) to support changing resolution. Or you can use bootargs to force 1280x720. I guess that should be enough to make HDMI audio to work, or at least get the driver to pick a CEA mode, which I think is required for HDMI audio to work.

The bit about aplay segfaulting sounds like a different issue.. at least that part is not related to the display driver so I can't say anything intelligent about that ;-)

BR,
-R

Is anything (Oops, BUG, ...) printed to the kernel log when aplay -l crashes?

It's strange when I power up the board again today, aplay -l finished successfully. But when I play with "aplay -Dhw:1,0 /mnt/b34248/wav/audio_int16le_48.wav", the program could run without error, but no sound can be heard.

How's the status for the TV's own audio level settings?

IIRC there are no alsa controls for HDMI audio but maybe pulse has muted it or something?

BTW I found as Rob Clark told EDID limit is 256. I will extend to 512.

I'm sure TV's own audio level is right. And I think pulseaudio has nothing to do with "aplay -Dhw:1,0", is it true?

I updated these with EDID limit 512 patch, might be interesting to see if it changes video mode selection

http://warmcat.com/uImage
http://warmcat.com/modules.tar.gz

I don't really understand how pulse interacts with alsa. If you run alsamixer on a system with pulse, it shows pulse volume control by default, so alsalib stuff knows about pulse. It's just a thought.

If aplay -Dhw:1,0 runs without error, it can only mean the output is muted somewhere, either on the board or in the TV.

andy-warmcat, I use the binary at http://warmcat.com, and test again, all things are same as the past. 1080p still not detected, and forced 720p causes no sound.
 Any one knows if there're something can control the HDMI output?

one thought.. I noticed there is a 1280x720 VESA mode:

 static const struct hdmi_timings cea_vesa_timings[OMAP_HDMI_TIMINGS_NB] = {
 ...
  /* VESA From Here */
 ...
  { {1280, 720, 74250, 40, 110, 220, 5, 5, 20}, 1, 1}
 };

I think this is what it is picking when you force 720x1280 in the bootargs:

[ 4.743347] [drm:drm_mode_debug_printmodeline], Modeline 15: "1280x720" 60 74250 1280 1390 1430 1650 720 725 730 750 0x40 0x5

if I am doing the math to convert between cea_vesa_timings table and the drm timings printed out in the trace, I think this is what is being picked..

I'm not sure if there is a way to force CEA 720p vs VESA 720p? For a quick test to verify this is the issue, you could just alter the last row in the table to make it not match, so one of the other 1280x720p modes is picked. (ie change pixel clock to -1 or something like that)

Is there any point setting a milestone on this? What does setting a milestone actually mean, an intention or a sort of happy wish?

There is new HDMI management code in 3.2 / tracking that might impact it (particularly I added a 500ms sleep before reading the edid) but presumably that won't show for 11.11 since there won't be any linux-linaro-3.2 to merge. I don't have a Sony Bravia KLV-32J400A and still won't even when there is a linux-linaro-3.2.

It seems to me we'll be better off if we only mark bugs we actually intend to see solved for a milestone with the milestone. This will only get solved for 11.11 by chance.

On 11 November 2011 12:19, warmcat <email address hidden> wrote:
> Is there any point setting a milestone on this?  What does setting a
> milestone actually mean, an intention or a sort of happy wish?

Target the bug to a milestone, makes it appear in the milestone page.
Page that we use to track what's happening for the cycle.
Except if you look to your bugs list, you'll missed it and most likely
won't be fixed.

In current case, it's an happy wish for Linaro Ubuntu.
Milestone or not, it doesn't change anything for you. We rely on LT to
get it fixed.

I understood we should use milestone to "tracking what's happening for the cycle", that sounds good and useful.

However in this case we mark a bug that I am pretty sure won't get any attention for 11.11 as "happening for the cycle". It won't get any attention because the code involved changed quite a bit already for 3.2 so we would be working on deprecated code, and 11.11 will presumably be 3.1 kernel. It seems pretty sure it's not "happening for the cycle".

Generally we won't spend much time on release kernel, it's better to spend the time fixing things on tracking and then 3.2 will come out in better shape from the start.

Maybe a good solution is package our tracking (tilt-tracking) without linux-linaro stuff in addition to release kernel. Then Wei Feng (who needed a binary kernel for last tests) can let us know if we changed anything for the better on 3.2 stuff.

Agreed. It doesn't make sense to have a milestone for this bug.

We changed a lot of things in video stack since October, is there any update from the original poster using current kernels?

Just had some mail with Wei Feng and he is experiencing trouble with a different TV now, it's corrupted / truncated EDID. I wonder if his problems are down to his HDMI cable.

Having quite the same issue with any of Linaro's builds > 11.09

My Monitor is a HP w2216 connected via HDMI->DVI.

http://pastebin.com/zWNcgdhd

I tried robclarks advise with video= syntax (http://nouveau.freedesktop.org/wiki/KernelModeSetting) but only console ran at desired resolution. During boot my pb falls back to 1024x768 resulting in endless lightdm respawns without X ever really starting.

On Sun, Jan 22, 2012 at 1:39 PM, Thorsten <email address hidden> wrote:
> Having quite the same issue with any of Linaro's builds > 11.09
>
> My Monitor is a HP w2216 connected via HDMI->DVI.
>
> http://pastebin.com/zWNcgdhd
>
> I tried robclarks advise with video= syntax
> (http://nouveau.freedesktop.org/wiki/KernelModeSetting) but only console
> ran at desired resolution. During boot my pb falls back to 1024x768
> resulting in endless lightdm respawns without X ever really starting.

Could you also add 'omapdss.debug=1 drm.debug=7' at your kernel
cmdline and paste your dmesg again?

To edit your kernel cmdline:
sudo cp /media/boot/boot.txt /boot/boot.script (if boot is not
mounted, mount /dev/mmcbl0p1 /media/boot)
sudo vim /boot/boot.script (add the additional cmd line arguments at
the bootargs line)
sudo flash-kernel
reboot

>
> --
> You received this bug notification because you are a member of Linaro
> Developer Platform, which is subscribed to Linaro-Ubuntu.
> https://bugs.launchpad.net/bugs/849625
>
> Title:
>  EDID and HDMI Audio not correct on Sony Bravia KLV-32J400A
>
> Status in Linaro Texas Instruments Landing Team:
>  Confirmed
> Status in Linaro Ubuntu Evaluation Builds:
>  Triaged
>
> Bug description:
>  When boot up panda, the HDMI resolution is auto detected as 1360x768. No HDMI audio can be outputted at such resolution.
>  TV brand is Sony Bravia KLV-32J400A
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/linaro-landing-team-ti/+bug/849625/+subscriptions

--
Ricardo Salveti de Araujo

sorry for delay - tried precise yesterday which worked really well with robclarks advice regarding KernelModeSetting. Edid and Monitor detection didn't work though. No Video-accel - but unity was very responsive.

Back to 12.01 panda-leb: console comes at desired (forced) resolution and again omaplfb falls back to 1024x768 and lightdm respawning over and over. Will have to fetch dmesg - it's kind of annoying since I only got about 2 hours a day to try different images. The setup of each image needs about 30 minutes and checking takes another 20 minutes.

I really hope that edid and correct monitor detection are working anytime soon. My Samsung TV (PS50C6970) isn't detected either so I've got no working solution.

fwiw, Thorsten's issue is different from the original bug.. not sure if there is a way to move his comments over into a new bug to keep things better organized..

apart from that bit of adminstrivia, given that he sees the same issue with multiple monitors, I have to think that the issue is either related to the internal/external pull-up for HDMI DDC. Or that there is just something broken about his board.

Thorsten, I don't remember if I asked you already, but what rev is your board? If you don't mind, I'd like to give you a uImage to try w/ drm.debug=7 logging enabled. (Don't care about what rootfs, if any, you have.. the traces I want to see are before userspace starts.)

I suggest we open a new bug and reference this one in the first
comment. Having two different issues in the same bug is confusing.

log attatched w/drm.debug enabled, sry for this issue regarding different bugs. I just didn't want to open a new bug since my problem might be related to this one.

It's an A3 es2.3 so your guess should be right

Guys what is the status of reproducing these problems on tilt-3.4-based 12.06 release?

Closing as invalid, since nothing has happened since Jan 2012

For project "linaro-ubuntu", Linaro has switched from GUI based ubuntu image to solid command line console, and this "HDMI Audio" test is no longer required.