Re: [Intel-gfx] [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver
-Original Message- From: intel-gfx- bounces+vijay.a.purushothaman=intel@lists.freedesktop.org [mailto:intel-gfx- bounces+vijay.a.purushothaman=intel@lists.freedesktop.org] On Behalf Of Wu Fengguang Sent: Monday, November 14, 2011 6:56 PM To: Takashi Iwai Cc: Wang, Zhenyu Z; intel-gfx@lists.freedesktop.org; Barnes, Jesse; Jeremy Bush; Christopher White; Bossart, Pierre-louis Subject: Re: [Intel-gfx] [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver On Mon, Nov 14, 2011 at 05:45:12PM +0800, Takashi Iwai wrote: At Sat, 12 Nov 2011 10:27:26 +0800, Wu Fengguang wrote: (snip) And I'm not sure whether HDMI audio is played while DPMS is off. I haven't tested it. It will go silence on DPMS. I noticed this while doing long term HDMI audio playback tests. This should better be fixed in future on the graphics side. Hm, but I wonder what could be done alternatively. Hopefully there is a register for video-only control... There may be some mode that can keep video off while still keep minimal signals to play HDMI sound? Let's hope :) You can turn off only the plane (but don't turn off the pipe port) to achieve this. Not much of power saving compared to DPMS though. Looks very possible, here is the clue of hardware support: TRANS_DP_CTL - Transcoder DisplayPort Control bit 26: Transcoder DP Audio Only Mode Good to know! But what about HDMI? I'm not sure.. There are no corresponding TRANS_HDMI_CTL registers... Bit 26 of TRANS_DP_CTL does not work. Also there is no such bit for HDMI. Thanks, Fengguang ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx Thanks, Vijay ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver
At Sat, 12 Nov 2011 10:27:26 +0800, Wu Fengguang wrote: (snip) And I'm not sure whether HDMI audio is played while DPMS is off. I haven't tested it. It will go silence on DPMS. I noticed this while doing long term HDMI audio playback tests. This should better be fixed in future on the graphics side. Hm, but I wonder what could be done alternatively. Hopefully there is a register for video-only control... There may be some mode that can keep video off while still keep minimal signals to play HDMI sound? Let's hope :) Looks very possible, here is the clue of hardware support: TRANS_DP_CTL - Transcoder DisplayPort Control bit 26: Transcoder DP Audio Only Mode Good to know! But what about HDMI? thanks, Takashi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver
On Mon, Nov 14, 2011 at 05:45:12PM +0800, Takashi Iwai wrote: At Sat, 12 Nov 2011 10:27:26 +0800, Wu Fengguang wrote: (snip) And I'm not sure whether HDMI audio is played while DPMS is off. I haven't tested it. It will go silence on DPMS. I noticed this while doing long term HDMI audio playback tests. This should better be fixed in future on the graphics side. Hm, but I wonder what could be done alternatively. Hopefully there is a register for video-only control... There may be some mode that can keep video off while still keep minimal signals to play HDMI sound? Let's hope :) Looks very possible, here is the clue of hardware support: TRANS_DP_CTL - Transcoder DisplayPort Control bit 26: Transcoder DP Audio Only Mode Good to know! But what about HDMI? I'm not sure.. There are no corresponding TRANS_HDMI_CTL registers... Thanks, Fengguang ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver
At Fri, 11 Nov 2011 16:22:41 +0800, Wu Fengguang wrote: On Fri, Nov 11, 2011 at 03:40:37PM +0800, Takashi Iwai wrote: At Fri, 11 Nov 2011 10:29:25 +0800, Wu Fengguang wrote: On Thu, Nov 10, 2011 at 10:28:19PM +0800, Takashi Iwai wrote: At Thu, 10 Nov 2011 21:51:50 +0800, Wu Fengguang wrote: So maybe the hardware is in some state that is unable to provide the real ELD content? That's my guess as well. I think the hardware may still be doing some form of data negotiation with the HDMI display device at that stage, and doesn't have the copy of the EDID+ELD buffer until a tiny bit later. Possibly? Look at the below dmesg. The ELD seem to available immediately after the DPMS state setting.. Interesting. Does HDMI audio work at all while HDMI DPMS off? It clears SDVO_ENABLE bit, so this might turn off both video and audio? We normally see transient blank screen and silence of audio when switching the video mode. Well, what I suspected is that ELD won't be transferred while SDVO_ENABLE is cleared. It's not about SDVO_ENABLE. The transient ELD invalid state I see in dmesg is caused by the graphics driver doing ELD_Valid = 0 = trigger 1st unsolicited event But why this triggers at *plugging*? Wasn't it zero beforehand? If I understand correctly, changing AUD_CNTL_ST register triggers the HD-audio codec unsol event. Writing even the same value matters? Sorry I assumed the mode switching context. Ah, I see. But this could be suppressed by your patch drm/i915: don't trigger hotplug events on unchanged ELD no? (snip) Depending on the timing, the 1st unsolicited event may see ELD_Valid=0 (if it's fast enough) or ELD_Valid=1 (if the event handling is delayed after the graphics driver sets ELD_Valid=1). I know that because I literally saw both cases happening in dmesg. The 1st hot plug event itself will send ELD_Valid=0, however the audio driver is not trusting this and always do a status query (the HDMI status line) whose result depends on the timing. The problem in this procedure is that this looks as if you are re-connecting the HDMI from the audio-codec POV. The re-connecting events can be distinguished from the video-mode-switching events by the Presence_Detect bit. Hm, OK, so the codec driver can simply ignore (or postpone) the case when the connection is kept but ELD is invalidated. Here is one hot removal event (I just wrote a patch to trigger this), with Presence_Detect=0: One note that we don't rely on PD bit because not all (non-Intel) hardware report it correctly. [ 91.777028] [drm:ironlake_write_eld], ELD on pipe B [ 91.778561] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=0 ELD_Valid=1 [ 91.783078] HDMI status: Codec=3 Pin=6 Presence_Detect=0 ELD_Valid=0 [ 91.783083] [drm:ironlake_write_eld], Audio directed to unknown port [ 91.783095] [drm:output_poll_execute], [CONNECTOR:12:HDMI-A-2] status updated from 1 to 2 The HDA spec even mentioned doing some timeout mechanism for the Presence_Detect=1 ELD_Valid=0 state. Well it may help some corner cases, but perhaps not an urgent feature. Yeah, this sounds like the workaround for such a case. We might end up with some delayed probe with a dedicated work_struct (because it's bad to have a too long delay in unsol event handler that run on a single workq). Understand. What if the graphics driver can delay the ELD writing (I can try that), so that the audio driver only need to wait for something like 10ms? Or, we can introduce a dirty flag, and set it when ELD is changed, but don't prase ELD contents yet. First upon the next access, the driver updates the status, and clear the dirty flag. We may put a small delay at this update, too. And I'm not sure whether HDMI audio is played while DPMS is off. I haven't tested it. It will go silence on DPMS. I noticed this while doing long term HDMI audio playback tests. This should better be fixed in future on the graphics side. Hm, but I wonder what could be done alternatively. Hopefully there is a register for video-only control... There may be some mode that can keep video off while still keep minimal signals to play HDMI sound? Let's hope :) thanks, Takashi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver
On Fri, Nov 11, 2011 at 04:49:57PM +0800, Takashi Iwai wrote: At Fri, 11 Nov 2011 16:22:41 +0800, Wu Fengguang wrote: On Fri, Nov 11, 2011 at 03:40:37PM +0800, Takashi Iwai wrote: At Fri, 11 Nov 2011 10:29:25 +0800, Wu Fengguang wrote: On Thu, Nov 10, 2011 at 10:28:19PM +0800, Takashi Iwai wrote: At Thu, 10 Nov 2011 21:51:50 +0800, Wu Fengguang wrote: So maybe the hardware is in some state that is unable to provide the real ELD content? That's my guess as well. I think the hardware may still be doing some form of data negotiation with the HDMI display device at that stage, and doesn't have the copy of the EDID+ELD buffer until a tiny bit later. Possibly? Look at the below dmesg. The ELD seem to available immediately after the DPMS state setting.. Interesting. Does HDMI audio work at all while HDMI DPMS off? It clears SDVO_ENABLE bit, so this might turn off both video and audio? We normally see transient blank screen and silence of audio when switching the video mode. Well, what I suspected is that ELD won't be transferred while SDVO_ENABLE is cleared. It's not about SDVO_ENABLE. The transient ELD invalid state I see in dmesg is caused by the graphics driver doing ELD_Valid = 0 = trigger 1st unsolicited event But why this triggers at *plugging*? Wasn't it zero beforehand? If I understand correctly, changing AUD_CNTL_ST register triggers the HD-audio codec unsol event. Writing even the same value matters? Sorry I assumed the mode switching context. Ah, I see. But this could be suppressed by your patch drm/i915: don't trigger hotplug events on unchanged ELD no? Mostly. The ELD may still change if the mode switching changes the av-sync-delay field, or suppresses the bandwidth available to audio samples. (snip) Depending on the timing, the 1st unsolicited event may see ELD_Valid=0 (if it's fast enough) or ELD_Valid=1 (if the event handling is delayed after the graphics driver sets ELD_Valid=1). I know that because I literally saw both cases happening in dmesg. The 1st hot plug event itself will send ELD_Valid=0, however the audio driver is not trusting this and always do a status query (the HDMI status line) whose result depends on the timing. The problem in this procedure is that this looks as if you are re-connecting the HDMI from the audio-codec POV. The re-connecting events can be distinguished from the video-mode-switching events by the Presence_Detect bit. Hm, OK, so the codec driver can simply ignore (or postpone) the case when the connection is kept but ELD is invalidated. Yes. Here is one hot removal event (I just wrote a patch to trigger this), with Presence_Detect=0: One note that we don't rely on PD bit because not all (non-Intel) hardware report it correctly. Oops. Do you imply ELDV is reliable on all platforms? ;-) [ 91.777028] [drm:ironlake_write_eld], ELD on pipe B [ 91.778561] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=0 ELD_Valid=1 [ 91.783078] HDMI status: Codec=3 Pin=6 Presence_Detect=0 ELD_Valid=0 [ 91.783083] [drm:ironlake_write_eld], Audio directed to unknown port [ 91.783095] [drm:output_poll_execute], [CONNECTOR:12:HDMI-A-2] status updated from 1 to 2 The HDA spec even mentioned doing some timeout mechanism for the Presence_Detect=1 ELD_Valid=0 state. Well it may help some corner cases, but perhaps not an urgent feature. Yeah, this sounds like the workaround for such a case. Yeah, your mentioned DVI case may be always in state Presence_Detect=1 ELD_Valid=0 where audio playback should be denied. And there might be the error case that the 2nd event is lost or not generated at all for changing Presence_Detect=1 ELD_Valid=0 to Presence_Detect=1 ELD_Valid=1 We might end up with some delayed probe with a dedicated work_struct (because it's bad to have a too long delay in unsol event handler that run on a single workq). Understand. What if the graphics driver can delay the ELD writing (I can try that), so that the audio driver only need to wait for something like 10ms? Or, we can introduce a dirty flag, and set it when ELD is changed, but don't prase ELD contents yet. First upon the next access, the driver updates the status, and clear the dirty flag. We may put a small delay at this update, too. It should work fine for cat /proc/asound/card0/eld* and other interfaces, however it could still delay the printks' significantly. And it feels not good that accessing ELD may be blocked for some time.. So I now prefer to avoid the msleep totally and schedule a delayed work for parsing ELD. Thanks, Fengguang
Re: [Intel-gfx] [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver
At Fri, 11 Nov 2011 17:24:21 +0800, Wu Fengguang wrote: On Fri, Nov 11, 2011 at 04:49:57PM +0800, Takashi Iwai wrote: At Fri, 11 Nov 2011 16:22:41 +0800, Wu Fengguang wrote: On Fri, Nov 11, 2011 at 03:40:37PM +0800, Takashi Iwai wrote: At Fri, 11 Nov 2011 10:29:25 +0800, Wu Fengguang wrote: On Thu, Nov 10, 2011 at 10:28:19PM +0800, Takashi Iwai wrote: At Thu, 10 Nov 2011 21:51:50 +0800, Wu Fengguang wrote: So maybe the hardware is in some state that is unable to provide the real ELD content? That's my guess as well. I think the hardware may still be doing some form of data negotiation with the HDMI display device at that stage, and doesn't have the copy of the EDID+ELD buffer until a tiny bit later. Possibly? Look at the below dmesg. The ELD seem to available immediately after the DPMS state setting.. Interesting. Does HDMI audio work at all while HDMI DPMS off? It clears SDVO_ENABLE bit, so this might turn off both video and audio? We normally see transient blank screen and silence of audio when switching the video mode. Well, what I suspected is that ELD won't be transferred while SDVO_ENABLE is cleared. It's not about SDVO_ENABLE. The transient ELD invalid state I see in dmesg is caused by the graphics driver doing ELD_Valid = 0 = trigger 1st unsolicited event But why this triggers at *plugging*? Wasn't it zero beforehand? If I understand correctly, changing AUD_CNTL_ST register triggers the HD-audio codec unsol event. Writing even the same value matters? Sorry I assumed the mode switching context. Ah, I see. But this could be suppressed by your patch drm/i915: don't trigger hotplug events on unchanged ELD no? Mostly. The ELD may still change if the mode switching changes the av-sync-delay field, or suppresses the bandwidth available to audio samples. OK, that's possible. (snip) Depending on the timing, the 1st unsolicited event may see ELD_Valid=0 (if it's fast enough) or ELD_Valid=1 (if the event handling is delayed after the graphics driver sets ELD_Valid=1). I know that because I literally saw both cases happening in dmesg. The 1st hot plug event itself will send ELD_Valid=0, however the audio driver is not trusting this and always do a status query (the HDMI status line) whose result depends on the timing. The problem in this procedure is that this looks as if you are re-connecting the HDMI from the audio-codec POV. The re-connecting events can be distinguished from the video-mode-switching events by the Presence_Detect bit. Hm, OK, so the codec driver can simply ignore (or postpone) the case when the connection is kept but ELD is invalidated. Yes. Here is one hot removal event (I just wrote a patch to trigger this), with Presence_Detect=0: One note that we don't rely on PD bit because not all (non-Intel) hardware report it correctly. Oops. Do you imply ELDV is reliable on all platforms? ;-) Oh hell, no :) The driver tries to probe explicitly via GET_PIN_SENSE HD-audio verb. [ 91.777028] [drm:ironlake_write_eld], ELD on pipe B [ 91.778561] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=0 ELD_Valid=1 [ 91.783078] HDMI status: Codec=3 Pin=6 Presence_Detect=0 ELD_Valid=0 [ 91.783083] [drm:ironlake_write_eld], Audio directed to unknown port [ 91.783095] [drm:output_poll_execute], [CONNECTOR:12:HDMI-A-2] status updated from 1 to 2 The HDA spec even mentioned doing some timeout mechanism for the Presence_Detect=1 ELD_Valid=0 state. Well it may help some corner cases, but perhaps not an urgent feature. Yeah, this sounds like the workaround for such a case. Yeah, your mentioned DVI case may be always in state Presence_Detect=1 ELD_Valid=0 where audio playback should be denied. And there might be the error case that the 2nd event is lost or not generated at all for changing Presence_Detect=1 ELD_Valid=0 to Presence_Detect=1 ELD_Valid=1 We might end up with some delayed probe with a dedicated work_struct (because it's bad to have a too long delay in unsol event handler that run on a single workq). Understand. What if the graphics driver can delay the ELD writing (I can try that), so that the audio driver only need to wait for something like 10ms? Or, we can introduce a dirty flag, and set it when ELD is changed, but don't prase ELD contents yet. First upon the next access, the driver updates the status, and clear the dirty flag. We may put a small delay at this update, too. It should work fine for cat
Re: [Intel-gfx] [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver
At Fri, 11 Nov 2011 19:12:57 +0800, Wu Fengguang wrote: (snip) One note that we don't rely on PD bit because not all (non-Intel) hardware report it correctly. Oops. Do you imply ELDV is reliable on all platforms? ;-) Oh hell, no :) The driver tries to probe explicitly via GET_PIN_SENSE HD-audio verb. Yeah the below HDMI status:... line. Can we rely on it then? I guess yes. At least, it worked with Nvidia and ATI, too, so far. The point is that the value passed in the codec unsol event is unreliable for some chips. [ 91.777028] [drm:ironlake_write_eld], ELD on pipe B [ 91.778561] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=0 ELD_Valid=1 [ 91.783078] HDMI status: Codec=3 Pin=6 Presence_Detect=0 ELD_Valid=0 [ 91.783083] [drm:ironlake_write_eld], Audio directed to unknown port [ 91.783095] [drm:output_poll_execute], [CONNECTOR:12:HDMI-A-2] status updated from 1 to 2 The HDA spec even mentioned doing some timeout mechanism for the Presence_Detect=1 ELD_Valid=0 state. Well it may help some corner cases, but perhaps not an urgent feature. Yeah, this sounds like the workaround for such a case. Yeah, your mentioned DVI case may be always in state Presence_Detect=1 ELD_Valid=0 where audio playback should be denied. And there might be the error case that the 2nd event is lost or not generated at all for changing Presence_Detect=1 ELD_Valid=0 to Presence_Detect=1 ELD_Valid=1 We might end up with some delayed probe with a dedicated work_struct (because it's bad to have a too long delay in unsol event handler that run on a single workq). Understand. What if the graphics driver can delay the ELD writing (I can try that), so that the audio driver only need to wait for something like 10ms? Or, we can introduce a dirty flag, and set it when ELD is changed, but don't prase ELD contents yet. First upon the next access, the driver updates the status, and clear the dirty flag. We may put a small delay at this update, too. It should work fine for cat /proc/asound/card0/eld* and other interfaces, however it could still delay the printks' significantly. Well, this reminds me of another question -- do we need these printks unconditionally? Maybe not. How about the attached patch to remove them all? I'm fine with it (better after debugging the ELD problems :) thanks, Takashi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver
On Fri, Nov 11, 2011 at 07:23:05PM +0800, Takashi Iwai wrote: At Fri, 11 Nov 2011 19:12:57 +0800, Wu Fengguang wrote: (snip) One note that we don't rely on PD bit because not all (non-Intel) hardware report it correctly. Oops. Do you imply ELDV is reliable on all platforms? ;-) Oh hell, no :) The driver tries to probe explicitly via GET_PIN_SENSE HD-audio verb. Yeah the below HDMI status:... line. Can we rely on it then? I guess yes. At least, it worked with Nvidia and ATI, too, so far. The point is that the value passed in the codec unsol event is unreliable for some chips. Yeah, for example the below HDMI hot plug event. When device is hot removed, Presence_Detect and ELD_Valid both goes 0, but the driver has to clear them one by one. As I choose to disable SDVO_AUDIO_ENABLE first, we see the strange Presence_Detect=0 ELD_Valid=1 combination below. [ 91.777028] [drm:ironlake_write_eld], ELD on pipe B [ 91.778561] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=0 ELD_Valid=1 [ 91.783078] HDMI status: Codec=3 Pin=6 Presence_Detect=0 ELD_Valid=0 [ 91.783083] [drm:ironlake_write_eld], Audio directed to unknown port [ 91.783095] [drm:output_poll_execute], [CONNECTOR:12:HDMI-A-2] status updated from 1 to 2 The HDA spec even mentioned doing some timeout mechanism for the Presence_Detect=1 ELD_Valid=0 state. Well it may help some corner cases, but perhaps not an urgent feature. Yeah, this sounds like the workaround for such a case. Yeah, your mentioned DVI case may be always in state Presence_Detect=1 ELD_Valid=0 where audio playback should be denied. And there might be the error case that the 2nd event is lost or not generated at all for changing Presence_Detect=1 ELD_Valid=0 to Presence_Detect=1 ELD_Valid=1 We might end up with some delayed probe with a dedicated work_struct (because it's bad to have a too long delay in unsol event handler that run on a single workq). Understand. What if the graphics driver can delay the ELD writing (I can try that), so that the audio driver only need to wait for something like 10ms? Or, we can introduce a dirty flag, and set it when ELD is changed, but don't prase ELD contents yet. First upon the next access, the driver updates the status, and clear the dirty flag. We may put a small delay at this update, too. It should work fine for cat /proc/asound/card0/eld* and other interfaces, however it could still delay the printks' significantly. Well, this reminds me of another question -- do we need these printks unconditionally? Maybe not. How about the attached patch to remove them all? I'm fine with it (better after debugging the ELD problems :) OK, when all the ELD/hotplug stuff calms down. Thanks, Fengguang ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver
(snip) And I'm not sure whether HDMI audio is played while DPMS is off. I haven't tested it. It will go silence on DPMS. I noticed this while doing long term HDMI audio playback tests. This should better be fixed in future on the graphics side. Hm, but I wonder what could be done alternatively. Hopefully there is a register for video-only control... There may be some mode that can keep video off while still keep minimal signals to play HDMI sound? Let's hope :) Looks very possible, here is the clue of hardware support: TRANS_DP_CTL - Transcoder DisplayPort Control bit 26: Transcoder DP Audio Only Mode Thanks, Fengguang ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver
On Thu, Nov 10, 2011 at 03:55:22PM +0800, Wu Fengguang wrote: On Thu, Nov 10, 2011 at 03:33:50PM +0800, Wu Fengguang wrote: Wow I reproduced the bug and got a very interesting dmesg: gfx =[ 4561.287980] [drm:intel_write_eld], ELD on [CONNECTOR:12:HDMI-A-2], [ENCODER:11:TMDS-11] gfx =[ 4561.291730] [drm:ironlake_write_eld], ELD on pipe B gfx =[ 4561.293804] [drm:ironlake_write_eld], Audio directed to unknown port gfx =[ 4561.295273] [drm:ironlake_write_eld], alsa = [ 4561.295486] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=0 alsa = [ 4561.295564] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=0 gfx =[ 4561.300020] ELD size 13 alsa = [ 4561.300697] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=1 alsa = [ 4561.303322] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=1 alsa = [ 4561.311120] ALSA hda_eld.c:259 HDMI: Unknown ELD version 0 Hey the two parts are interleaved! But still it should work all fine, since the gfx driver does set ELD_Valid = 0 write ELD set ELD_Valid = 1 So the audio driver would read the correct ELD unless the ELD content and flag writes are somehow _reordered_ underneath. Or the ELD content writes take some time to take effect? Just confirmed that adding 1s delay can fix it! My test steps are 1) fresh boot 2) cat /proc/asound/card0/eld* == OK 3) startx 4) DISPLAY=:0.0 xrandr --output HDMI2 --mode 720x480 5) cat /proc/asound/card0/eld* == ZEROS before patch, OK after patch I guess avoiding the extra ELD passing can also fix this problem, since we never meet timing problems with the first HDMI hot plug event. Thanks, Fengguang New dmesg is: [ 48.564923] [drm:drm_crtc_helper_set_mode], [ENCODER:11:TMDS-11] set [MODE:34:] [ 48.567481] [drm:intel_hdmi_mode_set], Enabling HDMI audio on pipe B [ 48.568975] [drm:intel_write_eld], ELD on [CONNECTOR:12:HDMI-A-2], [ENCODER:11:TMDS-11] [ 48.571728] [drm:ironlake_write_eld], ELD on pipe B [ 48.572882] [drm:ironlake_write_eld], Audio directed to unknown port [ 48.575252] [drm:ironlake_write_eld], [ 48.575400] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=0 [ 48.575487] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=0 [ 48.580116] ELD size 13 [ 48.580795] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=1 [ 48.583340] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=1 [ 48.632514] [drm:intel_wait_for_vblank], vblank wait timed out [ 48.685322] [drm:intel_wait_for_vblank], vblank wait timed out [ 48.687438] [drm:ironlake_update_wm], FIFO watermarks For pipe A - plane 5, cursor: 6 [ 48.687438] [drm:ironlake_update_wm], FIFO watermarks For pipe A - plane 5, cursor: 6 [ 48.690106] [drm:ironlake_update_wm], FIFO watermarks For pipe B - plane 42, cursor: 6 [ 48.745204] [drm:intel_wait_for_vblank], vblank wait timed out [ 48.798035] [drm:intel_wait_for_vblank], vblank wait timed out [ 48.799633] [drm:ironlake_fdi_link_train], FDI_RX_IIR 0x100 [ 48.802686] [drm:ironlake_fdi_link_train], FDI train 1 done. [ 48.805103] [drm:ironlake_fdi_link_train], FDI_RX_IIR 0x600 [ 48.807246] [drm:ironlake_fdi_link_train], FDI train 2 done. [ 48.809426] [drm:ironlake_fdi_link_train], FDI train done [ 48.813960] [drm:intel_update_fbc], [ 48.814782] [drm:drm_crtc_helper_set_config], Setting connector DPMS state to on [ 48.818093] [drm:drm_crtc_helper_set_config], [CONNECTOR:12:HDMI-A-2] set DPMS on [ 48.828633] [drm:intel_prepare_page_flip], preparing flip with no unpin work? [ 49.618962] HDMI: detected monitor RX-V1800 at connection type HDMI [ 49.621013] HDMI: available speakers: FL/FR LFE FC RL/RR RC RLC/RRC [ 49.622304] HDMI: supports coding type LPCM: channels = 2, rates = 32000 44100 48000 96000 176400 192000 384000, bits = 16 20 24 [ 49.625069] HDMI: supports coding type LPCM: channels = 8, rates = 32000 44100 48000 96000 176400 192000 384000, bits = 16 20 24 [ 49.628535] HDMI: supports coding type AC-3: channels = 6, rates = 32000 44100 48000, max bitrate = 64 [ 49.630810] HDMI: supports coding type DTS: channels = 7, rates = 32000 44100 48000 96000 176400, max bitrate = 1536000 [ 49.633148] HDMI: supports coding type DSD (One Bit Audio): channels = 6, rates = 44100 [ 49.635039] HDMI: supports coding type E-AC-3/DD+ (Dolby Digital Plus): channels = 8, rates = 44100 48000 [ 49.637130] HDMI: supports coding type MLP (Dolby TrueHD): channels = 8, rates = 48000 176400 384000 [ 49.639172] HDMI: supports coding type DTS-HD: channels = 8, rates = 48000 176400 384000 Thanks, Fengguang Subject: Date: Thu Nov 10 15:41:11 CST 2011 Signed-off-by: Wu Fengguang fengguang...@intel.com --- sound/pci/hda/hda_eld.c |3 +++ 1 file
Re: [Intel-gfx] [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver
On 11/10/11 8:55 AM, Wu Fengguang wrote: On Thu, Nov 10, 2011 at 03:33:50PM +0800, Wu Fengguang wrote: Wow I reproduced the bug and got a very interesting dmesg: gfx = [ 4561.287980] [drm:intel_write_eld], ELD on [CONNECTOR:12:HDMI-A-2], [ENCODER:11:TMDS-11] gfx = [ 4561.291730] [drm:ironlake_write_eld], ELD on pipe B gfx = [ 4561.293804] [drm:ironlake_write_eld], Audio directed to unknown port gfx = [ 4561.295273] [drm:ironlake_write_eld], alsa = [ 4561.295486] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=0 alsa = [ 4561.295564] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=0 gfx = [ 4561.300020] ELD size 13 alsa = [ 4561.300697] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=1 alsa = [ 4561.303322] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=1 alsa = [ 4561.311120] ALSA hda_eld.c:259 HDMI: Unknown ELD version 0 Hey the two parts are interleaved! But still it should work all fine, since the gfx driver does set ELD_Valid = 0 write ELD set ELD_Valid = 1 So the audio driver would read the correct ELD unless the ELD content and flag writes are somehow _reordered_ underneath. Or the ELD content writes take some time to take effect? Just confirmed that adding 1s delay can fix it! New dmesg is: [ 48.564923] [drm:drm_crtc_helper_set_mode], [ENCODER:11:TMDS-11] set [MODE:34:] [ 48.567481] [drm:intel_hdmi_mode_set], Enabling HDMI audio on pipe B [ 48.568975] [drm:intel_write_eld], ELD on [CONNECTOR:12:HDMI-A-2], [ENCODER:11:TMDS-11] [ 48.571728] [drm:ironlake_write_eld], ELD on pipe B [ 48.572882] [drm:ironlake_write_eld], Audio directed to unknown port [ 48.575252] [drm:ironlake_write_eld], [ 48.575400] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=0 [ 48.575487] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=0 [ 48.580116] ELD size 13 [ 48.580795] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=1 [ 48.583340] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=1 [ 48.632514] [drm:intel_wait_for_vblank], vblank wait timed out [ 48.685322] [drm:intel_wait_for_vblank], vblank wait timed out [ 48.687438] [drm:ironlake_update_wm], FIFO watermarks For pipe A - plane 5, cursor: 6 [ 48.687438] [drm:ironlake_update_wm], FIFO watermarks For pipe A - plane 5, cursor: 6 [ 48.690106] [drm:ironlake_update_wm], FIFO watermarks For pipe B - plane 42, cursor: 6 [ 48.745204] [drm:intel_wait_for_vblank], vblank wait timed out [ 48.798035] [drm:intel_wait_for_vblank], vblank wait timed out [ 48.799633] [drm:ironlake_fdi_link_train], FDI_RX_IIR 0x100 [ 48.802686] [drm:ironlake_fdi_link_train], FDI train 1 done. [ 48.805103] [drm:ironlake_fdi_link_train], FDI_RX_IIR 0x600 [ 48.807246] [drm:ironlake_fdi_link_train], FDI train 2 done. [ 48.809426] [drm:ironlake_fdi_link_train], FDI train done [ 48.813960] [drm:intel_update_fbc], [ 48.814782] [drm:drm_crtc_helper_set_config], Setting connector DPMS state to on [ 48.818093] [drm:drm_crtc_helper_set_config],[CONNECTOR:12:HDMI-A-2] set DPMS on [ 48.828633] [drm:intel_prepare_page_flip], preparing flip with no unpin work? [ 49.618962] HDMI: detected monitor RX-V1800 at connection type HDMI [ 49.621013] HDMI: available speakers: FL/FR LFE FC RL/RR RC RLC/RRC [ 49.622304] HDMI: supports coding type LPCM: channels = 2, rates = 32000 44100 48000 96000 176400 192000 384000, bits = 16 20 24 [ 49.625069] HDMI: supports coding type LPCM: channels = 8, rates = 32000 44100 48000 96000 176400 192000 384000, bits = 16 20 24 [ 49.628535] HDMI: supports coding type AC-3: channels = 6, rates = 32000 44100 48000, max bitrate = 64 [ 49.630810] HDMI: supports coding type DTS: channels = 7, rates = 32000 44100 48000 96000 176400, max bitrate = 1536000 [ 49.633148] HDMI: supports coding type DSD (One Bit Audio): channels = 6, rates = 44100 [ 49.635039] HDMI: supports coding type E-AC-3/DD+ (Dolby Digital Plus): channels = 8, rates = 44100 48000 [ 49.637130] HDMI: supports coding type MLP (Dolby TrueHD): channels = 8, rates = 48000 176400 384000 [ 49.639172] HDMI: supports coding type DTS-HD: channels = 8, rates = 48000 176400 384000 Thanks, Fengguang Wow, you were able to reproduce it! That's the best news ever. I will be applying this patch and rebuilding now to see what happens. So it was some sort of timing issue after all. Expect me to reply within 1h, but rebuild takes some time. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver
On 11/10/11 12:22 PM, Takashi Iwai wrote: At Thu, 10 Nov 2011 12:00:53 +0100, Christopher White wrote: On 11/10/11 9:55 AM, Christopher White wrote: On 11/10/11 8:55 AM, Wu Fengguang wrote: On Thu, Nov 10, 2011 at 03:33:50PM +0800, Wu Fengguang wrote: Wow I reproduced the bug and got a very interesting dmesg: gfx = [ 4561.287980] [drm:intel_write_eld], ELD on [CONNECTOR:12:HDMI-A-2], [ENCODER:11:TMDS-11] gfx = [ 4561.291730] [drm:ironlake_write_eld], ELD on pipe B gfx = [ 4561.293804] [drm:ironlake_write_eld], Audio directed to unknown port gfx = [ 4561.295273] [drm:ironlake_write_eld], alsa = [ 4561.295486] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=0 alsa = [ 4561.295564] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=0 gfx = [ 4561.300020] ELD size 13 alsa = [ 4561.300697] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=1 alsa = [ 4561.303322] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=1 alsa = [ 4561.311120] ALSA hda_eld.c:259 HDMI: Unknown ELD version 0 Hey the two parts are interleaved! But still it should work all fine, since the gfx driver does set ELD_Valid = 0 write ELD set ELD_Valid = 1 So the audio driver would read the correct ELD unless the ELD content and flag writes are somehow _reordered_ underneath. Or the ELD content writes take some time to take effect? Just confirmed that adding 1s delay can fix it! New dmesg is: [ 48.564923] [drm:drm_crtc_helper_set_mode], [ENCODER:11:TMDS-11] set [MODE:34:] [ 48.567481] [drm:intel_hdmi_mode_set], Enabling HDMI audio on pipe B [ 48.568975] [drm:intel_write_eld], ELD on [CONNECTOR:12:HDMI-A-2], [ENCODER:11:TMDS-11] [ 48.571728] [drm:ironlake_write_eld], ELD on pipe B [ 48.572882] [drm:ironlake_write_eld], Audio directed to unknown port [ 48.575252] [drm:ironlake_write_eld], [ 48.575400] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=0 [ 48.575487] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=0 [ 48.580116] ELD size 13 [ 48.580795] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=1 [ 48.583340] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=1 [ 48.632514] [drm:intel_wait_for_vblank], vblank wait timed out [ 48.685322] [drm:intel_wait_for_vblank], vblank wait timed out [ 48.687438] [drm:ironlake_update_wm], FIFO watermarks For pipe A - plane 5, cursor: 6 [ 48.687438] [drm:ironlake_update_wm], FIFO watermarks For pipe A - plane 5, cursor: 6 [ 48.690106] [drm:ironlake_update_wm], FIFO watermarks For pipe B - plane 42, cursor: 6 [ 48.745204] [drm:intel_wait_for_vblank], vblank wait timed out [ 48.798035] [drm:intel_wait_for_vblank], vblank wait timed out [ 48.799633] [drm:ironlake_fdi_link_train], FDI_RX_IIR 0x100 [ 48.802686] [drm:ironlake_fdi_link_train], FDI train 1 done. [ 48.805103] [drm:ironlake_fdi_link_train], FDI_RX_IIR 0x600 [ 48.807246] [drm:ironlake_fdi_link_train], FDI train 2 done. [ 48.809426] [drm:ironlake_fdi_link_train], FDI train done [ 48.813960] [drm:intel_update_fbc], [ 48.814782] [drm:drm_crtc_helper_set_config], Setting connector DPMS state to on [ 48.818093] [drm:drm_crtc_helper_set_config], [CONNECTOR:12:HDMI-A-2] set DPMS on [ 48.828633] [drm:intel_prepare_page_flip], preparing flip with no unpin work? [ 49.618962] HDMI: detected monitor RX-V1800 at connection type HDMI [ 49.621013] HDMI: available speakers: FL/FR LFE FC RL/RR RC RLC/RRC [ 49.622304] HDMI: supports coding type LPCM: channels = 2, rates = 32000 44100 48000 96000 176400 192000 384000, bits = 16 20 24 [ 49.625069] HDMI: supports coding type LPCM: channels = 8, rates = 32000 44100 48000 96000 176400 192000 384000, bits = 16 20 24 [ 49.628535] HDMI: supports coding type AC-3: channels = 6, rates = 32000 44100 48000, max bitrate = 64 [ 49.630810] HDMI: supports coding type DTS: channels = 7, rates = 32000 44100 48000 96000 176400, max bitrate = 1536000 [ 49.633148] HDMI: supports coding type DSD (One Bit Audio): channels = 6, rates = 44100 [ 49.635039] HDMI: supports coding type E-AC-3/DD+ (Dolby Digital Plus): channels = 8, rates = 44100 48000 [ 49.637130] HDMI: supports coding type MLP (Dolby TrueHD): channels = 8, rates = 48000 176400 384000 [ 49.639172] HDMI: supports coding type DTS-HD: channels = 8, rates = 48000 176400 384000 Thanks, Fengguang Wow, you were able to reproduce it! That's the best news ever. I will be applying this patch and rebuilding now to see what happens. So it was some sort of timing issue after all. Expect me to reply within 1h, but rebuild takes some time. I still had the old build directory and only had to rebuild one module which only took 5 minutes. The rest of the delay was me doing an hour of tests as well as being on a 45 minute phone call. Anyway, now the result: Success! So we know it's a timing issue somewhere.
Re: [Intel-gfx] [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver
At Thu, 10 Nov 2011 12:50:11 +0100, Christopher White wrote: On 11/10/11 12:22 PM, Takashi Iwai wrote: At Thu, 10 Nov 2011 12:00:53 +0100, Christopher White wrote: On 11/10/11 9:55 AM, Christopher White wrote: On 11/10/11 8:55 AM, Wu Fengguang wrote: On Thu, Nov 10, 2011 at 03:33:50PM +0800, Wu Fengguang wrote: Wow I reproduced the bug and got a very interesting dmesg: gfx = [ 4561.287980] [drm:intel_write_eld], ELD on [CONNECTOR:12:HDMI-A-2], [ENCODER:11:TMDS-11] gfx = [ 4561.291730] [drm:ironlake_write_eld], ELD on pipe B gfx = [ 4561.293804] [drm:ironlake_write_eld], Audio directed to unknown port gfx = [ 4561.295273] [drm:ironlake_write_eld], alsa = [ 4561.295486] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=0 alsa = [ 4561.295564] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=0 gfx = [ 4561.300020] ELD size 13 alsa = [ 4561.300697] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=1 alsa = [ 4561.303322] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=1 alsa = [ 4561.311120] ALSA hda_eld.c:259 HDMI: Unknown ELD version 0 Hey the two parts are interleaved! But still it should work all fine, since the gfx driver does set ELD_Valid = 0 write ELD set ELD_Valid = 1 So the audio driver would read the correct ELD unless the ELD content and flag writes are somehow _reordered_ underneath. Or the ELD content writes take some time to take effect? Just confirmed that adding 1s delay can fix it! New dmesg is: [ 48.564923] [drm:drm_crtc_helper_set_mode], [ENCODER:11:TMDS-11] set [MODE:34:] [ 48.567481] [drm:intel_hdmi_mode_set], Enabling HDMI audio on pipe B [ 48.568975] [drm:intel_write_eld], ELD on [CONNECTOR:12:HDMI-A-2], [ENCODER:11:TMDS-11] [ 48.571728] [drm:ironlake_write_eld], ELD on pipe B [ 48.572882] [drm:ironlake_write_eld], Audio directed to unknown port [ 48.575252] [drm:ironlake_write_eld], [ 48.575400] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=0 [ 48.575487] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=0 [ 48.580116] ELD size 13 [ 48.580795] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=1 [ 48.583340] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=1 [ 48.632514] [drm:intel_wait_for_vblank], vblank wait timed out [ 48.685322] [drm:intel_wait_for_vblank], vblank wait timed out [ 48.687438] [drm:ironlake_update_wm], FIFO watermarks For pipe A - plane 5, cursor: 6 [ 48.687438] [drm:ironlake_update_wm], FIFO watermarks For pipe A - plane 5, cursor: 6 [ 48.690106] [drm:ironlake_update_wm], FIFO watermarks For pipe B - plane 42, cursor: 6 [ 48.745204] [drm:intel_wait_for_vblank], vblank wait timed out [ 48.798035] [drm:intel_wait_for_vblank], vblank wait timed out [ 48.799633] [drm:ironlake_fdi_link_train], FDI_RX_IIR 0x100 [ 48.802686] [drm:ironlake_fdi_link_train], FDI train 1 done. [ 48.805103] [drm:ironlake_fdi_link_train], FDI_RX_IIR 0x600 [ 48.807246] [drm:ironlake_fdi_link_train], FDI train 2 done. [ 48.809426] [drm:ironlake_fdi_link_train], FDI train done [ 48.813960] [drm:intel_update_fbc], [ 48.814782] [drm:drm_crtc_helper_set_config], Setting connector DPMS state to on [ 48.818093] [drm:drm_crtc_helper_set_config], [CONNECTOR:12:HDMI-A-2] set DPMS on [ 48.828633] [drm:intel_prepare_page_flip], preparing flip with no unpin work? [ 49.618962] HDMI: detected monitor RX-V1800 at connection type HDMI [ 49.621013] HDMI: available speakers: FL/FR LFE FC RL/RR RC RLC/RRC [ 49.622304] HDMI: supports coding type LPCM: channels = 2, rates = 32000 44100 48000 96000 176400 192000 384000, bits = 16 20 24 [ 49.625069] HDMI: supports coding type LPCM: channels = 8, rates = 32000 44100 48000 96000 176400 192000 384000, bits = 16 20 24 [ 49.628535] HDMI: supports coding type AC-3: channels = 6, rates = 32000 44100 48000, max bitrate = 64 [ 49.630810] HDMI: supports coding type DTS: channels = 7, rates = 32000 44100 48000 96000 176400, max bitrate = 1536000 [ 49.633148] HDMI: supports coding type DSD (One Bit Audio): channels = 6, rates = 44100 [ 49.635039] HDMI: supports coding type E-AC-3/DD+ (Dolby Digital Plus): channels = 8, rates = 44100 48000 [ 49.637130] HDMI: supports coding type MLP (Dolby TrueHD): channels = 8, rates = 48000 176400 384000 [ 49.639172] HDMI: supports coding type DTS-HD: channels = 8, rates = 48000 176400 384000 Thanks, Fengguang Wow, you were able to reproduce it! That's the best news ever. I will be applying this patch and rebuilding now to see what happens. So it was some sort of timing issue after all. Expect me to reply within 1h, but rebuild takes some time. I still had the
Re: [Intel-gfx] [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver
On 11/10/11 12:53 PM, Takashi Iwai wrote: At Thu, 10 Nov 2011 12:50:11 +0100, Christopher White wrote: On 11/10/11 12:22 PM, Takashi Iwai wrote: At Thu, 10 Nov 2011 12:00:53 +0100, Christopher White wrote: On 11/10/11 9:55 AM, Christopher White wrote: On 11/10/11 8:55 AM, Wu Fengguang wrote: On Thu, Nov 10, 2011 at 03:33:50PM +0800, Wu Fengguang wrote: Wow I reproduced the bug and got a very interesting dmesg: gfx = [ 4561.287980] [drm:intel_write_eld], ELD on [CONNECTOR:12:HDMI-A-2], [ENCODER:11:TMDS-11] gfx = [ 4561.291730] [drm:ironlake_write_eld], ELD on pipe B gfx = [ 4561.293804] [drm:ironlake_write_eld], Audio directed to unknown port gfx = [ 4561.295273] [drm:ironlake_write_eld], alsa =[ 4561.295486] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=0 alsa =[ 4561.295564] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=0 gfx = [ 4561.300020] ELD size 13 alsa =[ 4561.300697] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=1 alsa =[ 4561.303322] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=1 alsa =[ 4561.311120] ALSA hda_eld.c:259 HDMI: Unknown ELD version 0 Hey the two parts are interleaved! But still it should work all fine, since the gfx driver does set ELD_Valid = 0 write ELD set ELD_Valid = 1 So the audio driver would read the correct ELD unless the ELD content and flag writes are somehow _reordered_ underneath. Or the ELD content writes take some time to take effect? Just confirmed that adding 1s delay can fix it! New dmesg is: [ 48.564923] [drm:drm_crtc_helper_set_mode], [ENCODER:11:TMDS-11] set [MODE:34:] [ 48.567481] [drm:intel_hdmi_mode_set], Enabling HDMI audio on pipe B [ 48.568975] [drm:intel_write_eld], ELD on [CONNECTOR:12:HDMI-A-2], [ENCODER:11:TMDS-11] [ 48.571728] [drm:ironlake_write_eld], ELD on pipe B [ 48.572882] [drm:ironlake_write_eld], Audio directed to unknown port [ 48.575252] [drm:ironlake_write_eld], [ 48.575400] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=0 [ 48.575487] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=0 [ 48.580116] ELD size 13 [ 48.580795] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=1 [ 48.583340] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=1 [ 48.632514] [drm:intel_wait_for_vblank], vblank wait timed out [ 48.685322] [drm:intel_wait_for_vblank], vblank wait timed out [ 48.687438] [drm:ironlake_update_wm], FIFO watermarks For pipe A - plane 5, cursor: 6 [ 48.687438] [drm:ironlake_update_wm], FIFO watermarks For pipe A - plane 5, cursor: 6 [ 48.690106] [drm:ironlake_update_wm], FIFO watermarks For pipe B - plane 42, cursor: 6 [ 48.745204] [drm:intel_wait_for_vblank], vblank wait timed out [ 48.798035] [drm:intel_wait_for_vblank], vblank wait timed out [ 48.799633] [drm:ironlake_fdi_link_train], FDI_RX_IIR 0x100 [ 48.802686] [drm:ironlake_fdi_link_train], FDI train 1 done. [ 48.805103] [drm:ironlake_fdi_link_train], FDI_RX_IIR 0x600 [ 48.807246] [drm:ironlake_fdi_link_train], FDI train 2 done. [ 48.809426] [drm:ironlake_fdi_link_train], FDI train done [ 48.813960] [drm:intel_update_fbc], [ 48.814782] [drm:drm_crtc_helper_set_config], Setting connector DPMS state to on [ 48.818093] [drm:drm_crtc_helper_set_config], [CONNECTOR:12:HDMI-A-2] set DPMS on [ 48.828633] [drm:intel_prepare_page_flip], preparing flip with no unpin work? [ 49.618962] HDMI: detected monitor RX-V1800 at connection type HDMI [ 49.621013] HDMI: available speakers: FL/FR LFE FC RL/RR RC RLC/RRC [ 49.622304] HDMI: supports coding type LPCM: channels = 2, rates = 32000 44100 48000 96000 176400 192000 384000, bits = 16 20 24 [ 49.625069] HDMI: supports coding type LPCM: channels = 8, rates = 32000 44100 48000 96000 176400 192000 384000, bits = 16 20 24 [ 49.628535] HDMI: supports coding type AC-3: channels = 6, rates = 32000 44100 48000, max bitrate = 64 [ 49.630810] HDMI: supports coding type DTS: channels = 7, rates = 32000 44100 48000 96000 176400, max bitrate = 1536000 [ 49.633148] HDMI: supports coding type DSD (One Bit Audio): channels = 6, rates = 44100 [ 49.635039] HDMI: supports coding type E-AC-3/DD+ (Dolby Digital Plus): channels = 8, rates = 44100 48000 [ 49.637130] HDMI: supports coding type MLP (Dolby TrueHD): channels = 8, rates = 48000 176400 384000 [ 49.639172] HDMI: supports coding type DTS-HD: channels = 8, rates = 48000 176400 384000 Thanks, Fengguang Wow, you were able to reproduce it! That's the best news ever. I will be applying this patch and rebuilding now to see what happens. So it was some sort of timing issue after all. Expect me to reply within 1h, but rebuild takes some time. I still had the old build directory and only had to rebuild one module which only took 5 minutes. The rest of the delay was me doing an hour of
Re: [Intel-gfx] [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver
On Thu, Nov 10, 2011 at 07:50:11PM +0800, Christopher White wrote: On 11/10/11 12:22 PM, Takashi Iwai wrote: At Thu, 10 Nov 2011 12:00:53 +0100, Christopher White wrote: On 11/10/11 9:55 AM, Christopher White wrote: On 11/10/11 8:55 AM, Wu Fengguang wrote: On Thu, Nov 10, 2011 at 03:33:50PM +0800, Wu Fengguang wrote: Wow I reproduced the bug and got a very interesting dmesg: gfx = [ 4561.287980] [drm:intel_write_eld], ELD on [CONNECTOR:12:HDMI-A-2], [ENCODER:11:TMDS-11] gfx = [ 4561.291730] [drm:ironlake_write_eld], ELD on pipe B gfx = [ 4561.293804] [drm:ironlake_write_eld], Audio directed to unknown port gfx = [ 4561.295273] [drm:ironlake_write_eld], alsa = [ 4561.295486] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=0 alsa = [ 4561.295564] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=0 gfx = [ 4561.300020] ELD size 13 alsa = [ 4561.300697] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=1 alsa = [ 4561.303322] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=1 alsa = [ 4561.311120] ALSA hda_eld.c:259 HDMI: Unknown ELD version 0 Hey the two parts are interleaved! But still it should work all fine, since the gfx driver does set ELD_Valid = 0 write ELD set ELD_Valid = 1 So the audio driver would read the correct ELD unless the ELD content and flag writes are somehow _reordered_ underneath. Or the ELD content writes take some time to take effect? Just confirmed that adding 1s delay can fix it! New dmesg is: [ 48.564923] [drm:drm_crtc_helper_set_mode], [ENCODER:11:TMDS-11] set [MODE:34:] [ 48.567481] [drm:intel_hdmi_mode_set], Enabling HDMI audio on pipe B [ 48.568975] [drm:intel_write_eld], ELD on [CONNECTOR:12:HDMI-A-2], [ENCODER:11:TMDS-11] [ 48.571728] [drm:ironlake_write_eld], ELD on pipe B [ 48.572882] [drm:ironlake_write_eld], Audio directed to unknown port [ 48.575252] [drm:ironlake_write_eld], [ 48.575400] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=0 [ 48.575487] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=0 [ 48.580116] ELD size 13 [ 48.580795] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=1 [ 48.583340] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=1 [ 48.632514] [drm:intel_wait_for_vblank], vblank wait timed out [ 48.685322] [drm:intel_wait_for_vblank], vblank wait timed out [ 48.687438] [drm:ironlake_update_wm], FIFO watermarks For pipe A - plane 5, cursor: 6 [ 48.687438] [drm:ironlake_update_wm], FIFO watermarks For pipe A - plane 5, cursor: 6 [ 48.690106] [drm:ironlake_update_wm], FIFO watermarks For pipe B - plane 42, cursor: 6 [ 48.745204] [drm:intel_wait_for_vblank], vblank wait timed out [ 48.798035] [drm:intel_wait_for_vblank], vblank wait timed out [ 48.799633] [drm:ironlake_fdi_link_train], FDI_RX_IIR 0x100 [ 48.802686] [drm:ironlake_fdi_link_train], FDI train 1 done. [ 48.805103] [drm:ironlake_fdi_link_train], FDI_RX_IIR 0x600 [ 48.807246] [drm:ironlake_fdi_link_train], FDI train 2 done. [ 48.809426] [drm:ironlake_fdi_link_train], FDI train done [ 48.813960] [drm:intel_update_fbc], [ 48.814782] [drm:drm_crtc_helper_set_config], Setting connector DPMS state to on [ 48.818093] [drm:drm_crtc_helper_set_config], [CONNECTOR:12:HDMI-A-2] set DPMS on [ 48.828633] [drm:intel_prepare_page_flip], preparing flip with no unpin work? [ 49.618962] HDMI: detected monitor RX-V1800 at connection type HDMI [ 49.621013] HDMI: available speakers: FL/FR LFE FC RL/RR RC RLC/RRC [ 49.622304] HDMI: supports coding type LPCM: channels = 2, rates = 32000 44100 48000 96000 176400 192000 384000, bits = 16 20 24 [ 49.625069] HDMI: supports coding type LPCM: channels = 8, rates = 32000 44100 48000 96000 176400 192000 384000, bits = 16 20 24 [ 49.628535] HDMI: supports coding type AC-3: channels = 6, rates = 32000 44100 48000, max bitrate = 64 [ 49.630810] HDMI: supports coding type DTS: channels = 7, rates = 32000 44100 48000 96000 176400, max bitrate = 1536000 [ 49.633148] HDMI: supports coding type DSD (One Bit Audio): channels = 6, rates = 44100 [ 49.635039] HDMI: supports coding type E-AC-3/DD+ (Dolby Digital Plus): channels = 8, rates = 44100 48000 [ 49.637130] HDMI: supports coding type MLP (Dolby TrueHD): channels = 8, rates = 48000 176400 384000 [ 49.639172] HDMI: supports coding type DTS-HD: channels = 8, rates = 48000 176400 384000 Thanks, Fengguang Wow, you were able to reproduce it! That's the best news ever. I will be applying this patch and rebuilding now to see what happens. So it was some sort of timing issue after all. Expect me to reply within 1h, but rebuild takes some time. I still had
Re: [Intel-gfx] [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver
On 11/10/11 1:56 PM, Wu Fengguang wrote: On Thu, Nov 10, 2011 at 07:50:11PM +0800, Christopher White wrote: On 11/10/11 12:22 PM, Takashi Iwai wrote: At Thu, 10 Nov 2011 12:00:53 +0100, Christopher White wrote: On 11/10/11 9:55 AM, Christopher White wrote: On 11/10/11 8:55 AM, Wu Fengguang wrote: On Thu, Nov 10, 2011 at 03:33:50PM +0800, Wu Fengguang wrote: Wow I reproduced the bug and got a very interesting dmesg: gfx = [ 4561.287980] [drm:intel_write_eld], ELD on [CONNECTOR:12:HDMI-A-2], [ENCODER:11:TMDS-11] gfx = [ 4561.291730] [drm:ironlake_write_eld], ELD on pipe B gfx = [ 4561.293804] [drm:ironlake_write_eld], Audio directed to unknown port gfx = [ 4561.295273] [drm:ironlake_write_eld], alsa =[ 4561.295486] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=0 alsa =[ 4561.295564] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=0 gfx = [ 4561.300020] ELD size 13 alsa =[ 4561.300697] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=1 alsa =[ 4561.303322] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=1 alsa =[ 4561.311120] ALSA hda_eld.c:259 HDMI: Unknown ELD version 0 Hey the two parts are interleaved! But still it should work all fine, since the gfx driver does set ELD_Valid = 0 write ELD set ELD_Valid = 1 So the audio driver would read the correct ELD unless the ELD content and flag writes are somehow _reordered_ underneath. Or the ELD content writes take some time to take effect? Just confirmed that adding 1s delay can fix it! New dmesg is: [ 48.564923] [drm:drm_crtc_helper_set_mode], [ENCODER:11:TMDS-11] set [MODE:34:] [ 48.567481] [drm:intel_hdmi_mode_set], Enabling HDMI audio on pipe B [ 48.568975] [drm:intel_write_eld], ELD on [CONNECTOR:12:HDMI-A-2], [ENCODER:11:TMDS-11] [ 48.571728] [drm:ironlake_write_eld], ELD on pipe B [ 48.572882] [drm:ironlake_write_eld], Audio directed to unknown port [ 48.575252] [drm:ironlake_write_eld], [ 48.575400] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=0 [ 48.575487] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=0 [ 48.580116] ELD size 13 [ 48.580795] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=1 [ 48.583340] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=1 [ 48.632514] [drm:intel_wait_for_vblank], vblank wait timed out [ 48.685322] [drm:intel_wait_for_vblank], vblank wait timed out [ 48.687438] [drm:ironlake_update_wm], FIFO watermarks For pipe A - plane 5, cursor: 6 [ 48.687438] [drm:ironlake_update_wm], FIFO watermarks For pipe A - plane 5, cursor: 6 [ 48.690106] [drm:ironlake_update_wm], FIFO watermarks For pipe B - plane 42, cursor: 6 [ 48.745204] [drm:intel_wait_for_vblank], vblank wait timed out [ 48.798035] [drm:intel_wait_for_vblank], vblank wait timed out [ 48.799633] [drm:ironlake_fdi_link_train], FDI_RX_IIR 0x100 [ 48.802686] [drm:ironlake_fdi_link_train], FDI train 1 done. [ 48.805103] [drm:ironlake_fdi_link_train], FDI_RX_IIR 0x600 [ 48.807246] [drm:ironlake_fdi_link_train], FDI train 2 done. [ 48.809426] [drm:ironlake_fdi_link_train], FDI train done [ 48.813960] [drm:intel_update_fbc], [ 48.814782] [drm:drm_crtc_helper_set_config], Setting connector DPMS state to on [ 48.818093] [drm:drm_crtc_helper_set_config], [CONNECTOR:12:HDMI-A-2] set DPMS on [ 48.828633] [drm:intel_prepare_page_flip], preparing flip with no unpin work? [ 49.618962] HDMI: detected monitor RX-V1800 at connection type HDMI [ 49.621013] HDMI: available speakers: FL/FR LFE FC RL/RR RC RLC/RRC [ 49.622304] HDMI: supports coding type LPCM: channels = 2, rates = 32000 44100 48000 96000 176400 192000 384000, bits = 16 20 24 [ 49.625069] HDMI: supports coding type LPCM: channels = 8, rates = 32000 44100 48000 96000 176400 192000 384000, bits = 16 20 24 [ 49.628535] HDMI: supports coding type AC-3: channels = 6, rates = 32000 44100 48000, max bitrate = 64 [ 49.630810] HDMI: supports coding type DTS: channels = 7, rates = 32000 44100 48000 96000 176400, max bitrate = 1536000 [ 49.633148] HDMI: supports coding type DSD (One Bit Audio): channels = 6, rates = 44100 [ 49.635039] HDMI: supports coding type E-AC-3/DD+ (Dolby Digital Plus): channels = 8, rates = 44100 48000 [ 49.637130] HDMI: supports coding type MLP (Dolby TrueHD): channels = 8, rates = 48000 176400 384000 [ 49.639172] HDMI: supports coding type DTS-HD: channels = 8, rates = 48000 176400 384000 Thanks, Fengguang Wow, you were able to reproduce it! That's the best news ever. I will be applying this patch and rebuilding now to see what happens. So it was some sort of timing issue after all. Expect me to reply within 1h, but rebuild takes some time. I still had the old build directory and only had to rebuild one module which only took 5 minutes. The rest of the delay was me doing an hour of
Re: [Intel-gfx] [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver
At Thu, 10 Nov 2011 13:39:00 +0100, Christopher White wrote: On 11/10/11 12:53 PM, Takashi Iwai wrote: At Thu, 10 Nov 2011 12:50:11 +0100, Christopher White wrote: On 11/10/11 12:22 PM, Takashi Iwai wrote: At Thu, 10 Nov 2011 12:00:53 +0100, Christopher White wrote: On 11/10/11 9:55 AM, Christopher White wrote: On 11/10/11 8:55 AM, Wu Fengguang wrote: On Thu, Nov 10, 2011 at 03:33:50PM +0800, Wu Fengguang wrote: Wow I reproduced the bug and got a very interesting dmesg: gfx = [ 4561.287980] [drm:intel_write_eld], ELD on [CONNECTOR:12:HDMI-A-2], [ENCODER:11:TMDS-11] gfx = [ 4561.291730] [drm:ironlake_write_eld], ELD on pipe B gfx = [ 4561.293804] [drm:ironlake_write_eld], Audio directed to unknown port gfx = [ 4561.295273] [drm:ironlake_write_eld], alsa =[ 4561.295486] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=0 alsa =[ 4561.295564] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=0 gfx = [ 4561.300020] ELD size 13 alsa =[ 4561.300697] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=1 alsa =[ 4561.303322] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=1 alsa =[ 4561.311120] ALSA hda_eld.c:259 HDMI: Unknown ELD version 0 Hey the two parts are interleaved! But still it should work all fine, since the gfx driver does set ELD_Valid = 0 write ELD set ELD_Valid = 1 So the audio driver would read the correct ELD unless the ELD content and flag writes are somehow _reordered_ underneath. Or the ELD content writes take some time to take effect? Just confirmed that adding 1s delay can fix it! New dmesg is: [ 48.564923] [drm:drm_crtc_helper_set_mode], [ENCODER:11:TMDS-11] set [MODE:34:] [ 48.567481] [drm:intel_hdmi_mode_set], Enabling HDMI audio on pipe B [ 48.568975] [drm:intel_write_eld], ELD on [CONNECTOR:12:HDMI-A-2], [ENCODER:11:TMDS-11] [ 48.571728] [drm:ironlake_write_eld], ELD on pipe B [ 48.572882] [drm:ironlake_write_eld], Audio directed to unknown port [ 48.575252] [drm:ironlake_write_eld], [ 48.575400] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=0 [ 48.575487] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=0 [ 48.580116] ELD size 13 [ 48.580795] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=1 [ 48.583340] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=1 [ 48.632514] [drm:intel_wait_for_vblank], vblank wait timed out [ 48.685322] [drm:intel_wait_for_vblank], vblank wait timed out [ 48.687438] [drm:ironlake_update_wm], FIFO watermarks For pipe A - plane 5, cursor: 6 [ 48.687438] [drm:ironlake_update_wm], FIFO watermarks For pipe A - plane 5, cursor: 6 [ 48.690106] [drm:ironlake_update_wm], FIFO watermarks For pipe B - plane 42, cursor: 6 [ 48.745204] [drm:intel_wait_for_vblank], vblank wait timed out [ 48.798035] [drm:intel_wait_for_vblank], vblank wait timed out [ 48.799633] [drm:ironlake_fdi_link_train], FDI_RX_IIR 0x100 [ 48.802686] [drm:ironlake_fdi_link_train], FDI train 1 done. [ 48.805103] [drm:ironlake_fdi_link_train], FDI_RX_IIR 0x600 [ 48.807246] [drm:ironlake_fdi_link_train], FDI train 2 done. [ 48.809426] [drm:ironlake_fdi_link_train], FDI train done [ 48.813960] [drm:intel_update_fbc], [ 48.814782] [drm:drm_crtc_helper_set_config], Setting connector DPMS state to on [ 48.818093] [drm:drm_crtc_helper_set_config], [CONNECTOR:12:HDMI-A-2] set DPMS on [ 48.828633] [drm:intel_prepare_page_flip], preparing flip with no unpin work? [ 49.618962] HDMI: detected monitor RX-V1800 at connection type HDMI [ 49.621013] HDMI: available speakers: FL/FR LFE FC RL/RR RC RLC/RRC [ 49.622304] HDMI: supports coding type LPCM: channels = 2, rates = 32000 44100 48000 96000 176400 192000 384000, bits = 16 20 24 [ 49.625069] HDMI: supports coding type LPCM: channels = 8, rates = 32000 44100 48000 96000 176400 192000 384000, bits = 16 20 24 [ 49.628535] HDMI: supports coding type AC-3: channels = 6, rates = 32000 44100 48000, max bitrate = 64 [ 49.630810] HDMI: supports coding type DTS: channels = 7, rates = 32000 44100 48000 96000 176400, max bitrate = 1536000 [ 49.633148] HDMI: supports coding type DSD (One Bit Audio): channels = 6, rates = 44100 [ 49.635039] HDMI: supports coding type E-AC-3/DD+ (Dolby Digital Plus): channels = 8, rates = 44100 48000 [ 49.637130] HDMI: supports coding type MLP (Dolby TrueHD): channels = 8, rates = 48000 176400 384000 [ 49.639172] HDMI: supports coding type DTS-HD: channels = 8, rates = 48000 176400 384000 Thanks, Fengguang Wow, you were able to reproduce it! That's the best news ever. I will be applying this patch and rebuilding now to see what
Re: [Intel-gfx] [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver
On Thu, Nov 10, 2011 at 09:01:24PM +0800, Christopher White wrote: On 11/10/11 1:56 PM, Wu Fengguang wrote: On Thu, Nov 10, 2011 at 07:50:11PM +0800, Christopher White wrote: On 11/10/11 12:22 PM, Takashi Iwai wrote: At Thu, 10 Nov 2011 12:00:53 +0100, Christopher White wrote: On 11/10/11 9:55 AM, Christopher White wrote: On 11/10/11 8:55 AM, Wu Fengguang wrote: On Thu, Nov 10, 2011 at 03:33:50PM +0800, Wu Fengguang wrote: Wow I reproduced the bug and got a very interesting dmesg: gfx = [ 4561.287980] [drm:intel_write_eld], ELD on [CONNECTOR:12:HDMI-A-2], [ENCODER:11:TMDS-11] gfx = [ 4561.291730] [drm:ironlake_write_eld], ELD on pipe B gfx = [ 4561.293804] [drm:ironlake_write_eld], Audio directed to unknown port gfx = [ 4561.295273] [drm:ironlake_write_eld], alsa =[ 4561.295486] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=0 alsa =[ 4561.295564] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=0 gfx = [ 4561.300020] ELD size 13 alsa =[ 4561.300697] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=1 alsa =[ 4561.303322] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=1 alsa =[ 4561.311120] ALSA hda_eld.c:259 HDMI: Unknown ELD version 0 Hey the two parts are interleaved! But still it should work all fine, since the gfx driver does set ELD_Valid = 0 write ELD set ELD_Valid = 1 So the audio driver would read the correct ELD unless the ELD content and flag writes are somehow _reordered_ underneath. Or the ELD content writes take some time to take effect? Just confirmed that adding 1s delay can fix it! New dmesg is: [ 48.564923] [drm:drm_crtc_helper_set_mode], [ENCODER:11:TMDS-11] set [MODE:34:] [ 48.567481] [drm:intel_hdmi_mode_set], Enabling HDMI audio on pipe B [ 48.568975] [drm:intel_write_eld], ELD on [CONNECTOR:12:HDMI-A-2], [ENCODER:11:TMDS-11] [ 48.571728] [drm:ironlake_write_eld], ELD on pipe B [ 48.572882] [drm:ironlake_write_eld], Audio directed to unknown port [ 48.575252] [drm:ironlake_write_eld], [ 48.575400] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=0 [ 48.575487] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=0 [ 48.580116] ELD size 13 [ 48.580795] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=1 [ 48.583340] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=1 [ 48.632514] [drm:intel_wait_for_vblank], vblank wait timed out [ 48.685322] [drm:intel_wait_for_vblank], vblank wait timed out [ 48.687438] [drm:ironlake_update_wm], FIFO watermarks For pipe A - plane 5, cursor: 6 [ 48.687438] [drm:ironlake_update_wm], FIFO watermarks For pipe A - plane 5, cursor: 6 [ 48.690106] [drm:ironlake_update_wm], FIFO watermarks For pipe B - plane 42, cursor: 6 [ 48.745204] [drm:intel_wait_for_vblank], vblank wait timed out [ 48.798035] [drm:intel_wait_for_vblank], vblank wait timed out [ 48.799633] [drm:ironlake_fdi_link_train], FDI_RX_IIR 0x100 [ 48.802686] [drm:ironlake_fdi_link_train], FDI train 1 done. [ 48.805103] [drm:ironlake_fdi_link_train], FDI_RX_IIR 0x600 [ 48.807246] [drm:ironlake_fdi_link_train], FDI train 2 done. [ 48.809426] [drm:ironlake_fdi_link_train], FDI train done [ 48.813960] [drm:intel_update_fbc], [ 48.814782] [drm:drm_crtc_helper_set_config], Setting connector DPMS state to on [ 48.818093] [drm:drm_crtc_helper_set_config], [CONNECTOR:12:HDMI-A-2] set DPMS on [ 48.828633] [drm:intel_prepare_page_flip], preparing flip with no unpin work? [ 49.618962] HDMI: detected monitor RX-V1800 at connection type HDMI [ 49.621013] HDMI: available speakers: FL/FR LFE FC RL/RR RC RLC/RRC [ 49.622304] HDMI: supports coding type LPCM: channels = 2, rates = 32000 44100 48000 96000 176400 192000 384000, bits = 16 20 24 [ 49.625069] HDMI: supports coding type LPCM: channels = 8, rates = 32000 44100 48000 96000 176400 192000 384000, bits = 16 20 24 [ 49.628535] HDMI: supports coding type AC-3: channels = 6, rates = 32000 44100 48000, max bitrate = 64 [ 49.630810] HDMI: supports coding type DTS: channels = 7, rates = 32000 44100 48000 96000 176400, max bitrate = 1536000 [ 49.633148] HDMI: supports coding type DSD (One Bit Audio): channels = 6, rates = 44100 [ 49.635039] HDMI: supports coding type E-AC-3/DD+ (Dolby Digital Plus): channels = 8, rates = 44100 48000 [ 49.637130] HDMI: supports coding type MLP (Dolby TrueHD): channels = 8, rates = 48000 176400 384000 [ 49.639172] HDMI: supports coding type DTS-HD: channels = 8, rates = 48000 176400 384000 Thanks, Fengguang Wow, you were able to reproduce it! That's the best news ever. I will be applying this patch and rebuilding now to see what
Re: [Intel-gfx] [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver
On 11/10/11 2:17 PM, Wu Fengguang wrote: On Thu, Nov 10, 2011 at 09:01:24PM +0800, Christopher White wrote: On 11/10/11 1:56 PM, Wu Fengguang wrote: On Thu, Nov 10, 2011 at 07:50:11PM +0800, Christopher White wrote: On 11/10/11 12:22 PM, Takashi Iwai wrote: At Thu, 10 Nov 2011 12:00:53 +0100, Christopher White wrote: On 11/10/11 9:55 AM, Christopher White wrote: On 11/10/11 8:55 AM, Wu Fengguang wrote: On Thu, Nov 10, 2011 at 03:33:50PM +0800, Wu Fengguang wrote: Wow I reproduced the bug and got a very interesting dmesg: gfx =[ 4561.287980] [drm:intel_write_eld], ELD on [CONNECTOR:12:HDMI-A-2], [ENCODER:11:TMDS-11] gfx =[ 4561.291730] [drm:ironlake_write_eld], ELD on pipe B gfx =[ 4561.293804] [drm:ironlake_write_eld], Audio directed to unknown port gfx =[ 4561.295273] [drm:ironlake_write_eld], alsa = [ 4561.295486] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=0 alsa = [ 4561.295564] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=0 gfx =[ 4561.300020] ELD size 13 alsa = [ 4561.300697] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=1 alsa = [ 4561.303322] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=1 alsa = [ 4561.311120] ALSA hda_eld.c:259 HDMI: Unknown ELD version 0 Hey the two parts are interleaved! But still it should work all fine, since the gfx driver does set ELD_Valid = 0 write ELD set ELD_Valid = 1 So the audio driver would read the correct ELD unless the ELD content and flag writes are somehow _reordered_ underneath. Or the ELD content writes take some time to take effect? Just confirmed that adding 1s delay can fix it! New dmesg is: [ 48.564923] [drm:drm_crtc_helper_set_mode], [ENCODER:11:TMDS-11] set [MODE:34:] [ 48.567481] [drm:intel_hdmi_mode_set], Enabling HDMI audio on pipe B [ 48.568975] [drm:intel_write_eld], ELD on [CONNECTOR:12:HDMI-A-2], [ENCODER:11:TMDS-11] [ 48.571728] [drm:ironlake_write_eld], ELD on pipe B [ 48.572882] [drm:ironlake_write_eld], Audio directed to unknown port [ 48.575252] [drm:ironlake_write_eld], [ 48.575400] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=0 [ 48.575487] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=0 [ 48.580116] ELD size 13 [ 48.580795] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=1 [ 48.583340] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=1 [ 48.632514] [drm:intel_wait_for_vblank], vblank wait timed out [ 48.685322] [drm:intel_wait_for_vblank], vblank wait timed out [ 48.687438] [drm:ironlake_update_wm], FIFO watermarks For pipe A - plane 5, cursor: 6 [ 48.687438] [drm:ironlake_update_wm], FIFO watermarks For pipe A - plane 5, cursor: 6 [ 48.690106] [drm:ironlake_update_wm], FIFO watermarks For pipe B - plane 42, cursor: 6 [ 48.745204] [drm:intel_wait_for_vblank], vblank wait timed out [ 48.798035] [drm:intel_wait_for_vblank], vblank wait timed out [ 48.799633] [drm:ironlake_fdi_link_train], FDI_RX_IIR 0x100 [ 48.802686] [drm:ironlake_fdi_link_train], FDI train 1 done. [ 48.805103] [drm:ironlake_fdi_link_train], FDI_RX_IIR 0x600 [ 48.807246] [drm:ironlake_fdi_link_train], FDI train 2 done. [ 48.809426] [drm:ironlake_fdi_link_train], FDI train done [ 48.813960] [drm:intel_update_fbc], [ 48.814782] [drm:drm_crtc_helper_set_config], Setting connector DPMS state to on [ 48.818093] [drm:drm_crtc_helper_set_config], [CONNECTOR:12:HDMI-A-2] set DPMS on [ 48.828633] [drm:intel_prepare_page_flip], preparing flip with no unpin work? [ 49.618962] HDMI: detected monitor RX-V1800 at connection type HDMI [ 49.621013] HDMI: available speakers: FL/FR LFE FC RL/RR RC RLC/RRC [ 49.622304] HDMI: supports coding type LPCM: channels = 2, rates = 32000 44100 48000 96000 176400 192000 384000, bits = 16 20 24 [ 49.625069] HDMI: supports coding type LPCM: channels = 8, rates = 32000 44100 48000 96000 176400 192000 384000, bits = 16 20 24 [ 49.628535] HDMI: supports coding type AC-3: channels = 6, rates = 32000 44100 48000, max bitrate = 64 [ 49.630810] HDMI: supports coding type DTS: channels = 7, rates = 32000 44100 48000 96000 176400, max bitrate = 1536000 [ 49.633148] HDMI: supports coding type DSD (One Bit Audio): channels = 6, rates = 44100 [ 49.635039] HDMI: supports coding type E-AC-3/DD+ (Dolby Digital Plus): channels = 8, rates = 44100 48000 [ 49.637130] HDMI: supports coding type MLP (Dolby TrueHD): channels = 8, rates = 48000 176400 384000 [ 49.639172] HDMI: supports coding type DTS-HD: channels = 8, rates = 48000 176400 384000 Thanks, Fengguang Wow, you were able to reproduce it! That's the best news ever. I will be applying this patch and rebuilding now to see what happens. So it was some sort of timing issue after all. Expect me to reply within 1h, but rebuild takes some time. I still had the
Re: [Intel-gfx] [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver
At Thu, 10 Nov 2011 21:17:53 +0800, Wu Fengguang wrote: On Thu, Nov 10, 2011 at 09:01:24PM +0800, Christopher White wrote: On 11/10/11 1:56 PM, Wu Fengguang wrote: On Thu, Nov 10, 2011 at 07:50:11PM +0800, Christopher White wrote: On 11/10/11 12:22 PM, Takashi Iwai wrote: At Thu, 10 Nov 2011 12:00:53 +0100, Christopher White wrote: On 11/10/11 9:55 AM, Christopher White wrote: On 11/10/11 8:55 AM, Wu Fengguang wrote: On Thu, Nov 10, 2011 at 03:33:50PM +0800, Wu Fengguang wrote: Wow I reproduced the bug and got a very interesting dmesg: gfx = [ 4561.287980] [drm:intel_write_eld], ELD on [CONNECTOR:12:HDMI-A-2], [ENCODER:11:TMDS-11] gfx = [ 4561.291730] [drm:ironlake_write_eld], ELD on pipe B gfx = [ 4561.293804] [drm:ironlake_write_eld], Audio directed to unknown port gfx = [ 4561.295273] [drm:ironlake_write_eld], alsa =[ 4561.295486] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=0 alsa =[ 4561.295564] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=0 gfx = [ 4561.300020] ELD size 13 alsa =[ 4561.300697] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=1 alsa =[ 4561.303322] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=1 alsa =[ 4561.311120] ALSA hda_eld.c:259 HDMI: Unknown ELD version 0 Hey the two parts are interleaved! But still it should work all fine, since the gfx driver does set ELD_Valid = 0 write ELD set ELD_Valid = 1 So the audio driver would read the correct ELD unless the ELD content and flag writes are somehow _reordered_ underneath. Or the ELD content writes take some time to take effect? Just confirmed that adding 1s delay can fix it! New dmesg is: [ 48.564923] [drm:drm_crtc_helper_set_mode], [ENCODER:11:TMDS-11] set [MODE:34:] [ 48.567481] [drm:intel_hdmi_mode_set], Enabling HDMI audio on pipe B [ 48.568975] [drm:intel_write_eld], ELD on [CONNECTOR:12:HDMI-A-2], [ENCODER:11:TMDS-11] [ 48.571728] [drm:ironlake_write_eld], ELD on pipe B [ 48.572882] [drm:ironlake_write_eld], Audio directed to unknown port [ 48.575252] [drm:ironlake_write_eld], [ 48.575400] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=0 [ 48.575487] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=0 [ 48.580116] ELD size 13 [ 48.580795] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=1 [ 48.583340] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=1 [ 48.632514] [drm:intel_wait_for_vblank], vblank wait timed out [ 48.685322] [drm:intel_wait_for_vblank], vblank wait timed out [ 48.687438] [drm:ironlake_update_wm], FIFO watermarks For pipe A - plane 5, cursor: 6 [ 48.687438] [drm:ironlake_update_wm], FIFO watermarks For pipe A - plane 5, cursor: 6 [ 48.690106] [drm:ironlake_update_wm], FIFO watermarks For pipe B - plane 42, cursor: 6 [ 48.745204] [drm:intel_wait_for_vblank], vblank wait timed out [ 48.798035] [drm:intel_wait_for_vblank], vblank wait timed out [ 48.799633] [drm:ironlake_fdi_link_train], FDI_RX_IIR 0x100 [ 48.802686] [drm:ironlake_fdi_link_train], FDI train 1 done. [ 48.805103] [drm:ironlake_fdi_link_train], FDI_RX_IIR 0x600 [ 48.807246] [drm:ironlake_fdi_link_train], FDI train 2 done. [ 48.809426] [drm:ironlake_fdi_link_train], FDI train done [ 48.813960] [drm:intel_update_fbc], [ 48.814782] [drm:drm_crtc_helper_set_config], Setting connector DPMS state to on [ 48.818093] [drm:drm_crtc_helper_set_config], [CONNECTOR:12:HDMI-A-2] set DPMS on [ 48.828633] [drm:intel_prepare_page_flip], preparing flip with no unpin work? [ 49.618962] HDMI: detected monitor RX-V1800 at connection type HDMI [ 49.621013] HDMI: available speakers: FL/FR LFE FC RL/RR RC RLC/RRC [ 49.622304] HDMI: supports coding type LPCM: channels = 2, rates = 32000 44100 48000 96000 176400 192000 384000, bits = 16 20 24 [ 49.625069] HDMI: supports coding type LPCM: channels = 8, rates = 32000 44100 48000 96000 176400 192000 384000, bits = 16 20 24 [ 49.628535] HDMI: supports coding type AC-3: channels = 6, rates = 32000 44100 48000, max bitrate = 64 [ 49.630810] HDMI: supports coding type DTS: channels = 7, rates = 32000 44100 48000 96000 176400, max bitrate = 1536000 [ 49.633148] HDMI: supports coding type DSD (One Bit Audio): channels = 6, rates = 44100 [ 49.635039] HDMI: supports coding type E-AC-3/DD+ (Dolby Digital Plus): channels = 8, rates = 44100 48000 [ 49.637130] HDMI: supports coding type MLP (Dolby TrueHD): channels = 8, rates = 48000 176400 384000 [ 49.639172] HDMI: supports coding type
Re: [Intel-gfx] [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver
Got the delay - it's 72.986623-72.747632 = 239ms. [ 72.739944] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=0 [ 72.742541] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=0 [ 72.745082] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=1 [ 72.747632] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=1 [ 72.794240] [drm:intel_wait_for_vblank], vblank wait timed out [ 72.848099] [drm:intel_wait_for_vblank], vblank wait timed out [ 72.850507] [drm:ironlake_update_wm], FIFO watermarks For pipe A - plane 5, cursor: 6 [ 72.853244] [drm:ironlake_update_wm], FIFO watermarks For pipe B - plane 42, cursor: 6 [ 72.907937] [drm:intel_wait_for_vblank], vblank wait timed out [ 72.960790] [drm:intel_wait_for_vblank], vblank wait timed out [ 72.962757] [drm:ironlake_fdi_link_train], FDI_RX_IIR 0x100 [ 72.964880] [drm:ironlake_fdi_link_train], FDI train 1 done. [ 72.968341] [drm:ironlake_fdi_link_train], FDI_RX_IIR 0x600 [ 72.970274] [drm:ironlake_fdi_link_train], FDI train 2 done. [ 72.972535] [drm:ironlake_fdi_link_train], FDI train done [ 72.976751] [drm:intel_update_fbc], [ 72.977558] [drm:drm_crtc_helper_set_config], Setting connector DPMS state to on == [ 72.981550] [drm:drm_crtc_helper_set_config], [CONNECTOR:12:HDMI-A-2] set DPMS on [ 72.986623] HDMI: detected monitor RX-V1800 at connection type HDMI [ 72.988260] HDMI: available speakers: FL/FR LFE FC RL/RR RC RLC/RRC I wonder if the DPMS line has anything to do with the delay... Thanks, Fengguang Nice find! It does seem likely since the ELD read worked right after that. Hmm. I am not familiar with the event order for the Intel hardware, and what's calling your edid_to_eld code, etc. Is it possible to move the EDID read call to after the DPMS state is ready? I added a dump_stack() at the very beginning of drm_crtc_helper_set_config(). Judging from drm_crtc_helper_set_config()'s comment and the below dmesg, it's called by user space. [ 84.470633] Pid: 2893, comm: Xorg Tainted: GW3.2.0-rc1-eld+ #244 [ 84.472188] Call Trace: [ 84.472795] [8195dfba] ? printk+0x41/0x43 [ 84.474011] [8148aa04] drm_crtc_helper_set_config+0x24/0x852 [ 84.476342] [81493e52] ? drm_ut_debug_printk+0x57/0x5e [ 84.477743] [8196052d] ? mutex_unlock+0xe/0x10 [ 84.479015] [8149a403] ? drm_mode_object_find+0x61/0x70 [ 84.481326] [8149b632] drm_mode_setcrtc+0x35d/0x38e [ 84.482679] [8196052d] ? mutex_unlock+0xe/0x10 [ 84.483934] [8148efc6] drm_ioctl+0x2c0/0x38c [ 84.486033] [8149b2d5] ? drm_mode_getencoder+0x9b/0x9b [ 84.487463] [811567b0] do_vfs_ioctl+0x490/0x4d1 [ 84.489657] [81156838] sys_ioctl+0x47/0x6b [ 84.490780] [8149a3cf] ? drm_mode_object_find+0x2d/0x70 [ 84.492235] [81968a82] system_call_fastpath+0x16/0x1b [ 84.495536] [drm:drm_crtc_helper_set_config], [ 84.496561] [drm:drm_crtc_helper_set_config], [CRTC:4] [FB:31] #connectors=1 (x y) (0 0) [ 84.498323] [drm:drm_crtc_helper_set_config], modes are different, full mode set [ 84.499958] [drm:drm_mode_debug_printmodeline], Modeline 27:720x576 50 27000 720 732 796 864 576 581 586 625 0x40 0xa [ 84.502454] [drm:drm_mode_debug_printmodeline], Modeline 34: 0 27000 720 736 798 858 480 489 495 525 0x0 0xa [ 84.504672] [drm:drm_crtc_helper_set_config], [CONNECTOR:5:VGA-1] to [CRTC:3] [ 84.506205] [drm:drm_crtc_helper_set_config], [CONNECTOR:12:HDMI-A-2] to [CRTC:4] [ 84.507869] [drm:drm_crtc_helper_set_config], attempting to set mode from userspace [ 84.509699] [drm:drm_mode_debug_printmodeline], Modeline 34: 0 27000 720 736 798 858 480 489 495 525 0x0 0xa [ 84.511903] [drm:drm_crtc_helper_set_mode], [CRTC:4] [ 84.521961] [drm:intel_prepare_page_flip], preparing flip with no unpin work? [ 84.564804] [drm:intel_wait_for_vblank], vblank wait timed out [ 84.603175] [drm:ironlake_update_wm], FIFO watermarks For pipe A - plane 5, cursor: 6 [ 84.606681] [drm:ironlake_update_wm], FIFO watermarks For pipe B - plane 42, cursor: 6 [ 84.610472] [drm:intel_update_fbc], [ 84.611501] [drm:intel_choose_pipe_bpp_dither], forcing bpc to 8 for HDMI [ 84.613791] [drm:intel_choose_pipe_bpp_dither], setting pipe bpc to 8 (max display bpc 8) [ 84.616531] [drm:ironlake_crtc_mode_set], Mode for pipe 1: [ 84.617884] [drm:drm_mode_debug_printmodeline], Modeline 34: 0 27000 720 736 798 858 480 489 495 525 0x0 0xa [ 84.622337] [drm:ironlake_crtc_mode_set], disabling CxSR downclocking [ 84.676554] [drm:intel_wait_for_vblank], vblank wait timed out [ 84.678981] [drm:ironlake_update_plane], Writing base 00343000
Re: [Intel-gfx] [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver
On Thu, Nov 10, 2011 at 09:47:46PM +0800, Wu Fengguang wrote: Got the delay - it's 72.986623-72.747632 = 239ms. [ 72.739944] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=0 [ 72.742541] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=0 [ 72.745082] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=1 [ 72.747632] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=1 [ 72.794240] [drm:intel_wait_for_vblank], vblank wait timed out [ 72.848099] [drm:intel_wait_for_vblank], vblank wait timed out [ 72.850507] [drm:ironlake_update_wm], FIFO watermarks For pipe A - plane 5, cursor: 6 [ 72.853244] [drm:ironlake_update_wm], FIFO watermarks For pipe B - plane 42, cursor: 6 [ 72.907937] [drm:intel_wait_for_vblank], vblank wait timed out [ 72.960790] [drm:intel_wait_for_vblank], vblank wait timed out [ 72.962757] [drm:ironlake_fdi_link_train], FDI_RX_IIR 0x100 [ 72.964880] [drm:ironlake_fdi_link_train], FDI train 1 done. [ 72.968341] [drm:ironlake_fdi_link_train], FDI_RX_IIR 0x600 [ 72.970274] [drm:ironlake_fdi_link_train], FDI train 2 done. [ 72.972535] [drm:ironlake_fdi_link_train], FDI train done [ 72.976751] [drm:intel_update_fbc], [ 72.977558] [drm:drm_crtc_helper_set_config], Setting connector DPMS state to on == [ 72.981550] [drm:drm_crtc_helper_set_config], [CONNECTOR:12:HDMI-A-2] set DPMS on [ 72.986623] HDMI: detected monitor RX-V1800 at connection type HDMI [ 72.988260] HDMI: available speakers: FL/FR LFE FC RL/RR RC RLC/RRC I wonder if the DPMS line has anything to do with the delay... Thanks, Fengguang Nice find! It does seem likely since the ELD read worked right after that. Hmm. I am not familiar with the event order for the Intel hardware, and what's calling your edid_to_eld code, etc. Is it possible to move the EDID read call to after the DPMS state is ready? I added a dump_stack() at the very beginning of drm_crtc_helper_set_config(). Judging from drm_crtc_helper_set_config()'s comment and the below dmesg, it's called by user space. [ 84.470633] Pid: 2893, comm: Xorg Tainted: GW3.2.0-rc1-eld+ #244 [ 84.472188] Call Trace: [ 84.472795] [8195dfba] ? printk+0x41/0x43 [ 84.474011] [8148aa04] drm_crtc_helper_set_config+0x24/0x852 [ 84.476342] [81493e52] ? drm_ut_debug_printk+0x57/0x5e [ 84.477743] [8196052d] ? mutex_unlock+0xe/0x10 [ 84.479015] [8149a403] ? drm_mode_object_find+0x61/0x70 [ 84.481326] [8149b632] drm_mode_setcrtc+0x35d/0x38e [ 84.482679] [8196052d] ? mutex_unlock+0xe/0x10 [ 84.483934] [8148efc6] drm_ioctl+0x2c0/0x38c [ 84.486033] [8149b2d5] ? drm_mode_getencoder+0x9b/0x9b [ 84.487463] [811567b0] do_vfs_ioctl+0x490/0x4d1 [ 84.489657] [81156838] sys_ioctl+0x47/0x6b [ 84.490780] [8149a3cf] ? drm_mode_object_find+0x2d/0x70 [ 84.492235] [81968a82] system_call_fastpath+0x16/0x1b [ 84.495536] [drm:drm_crtc_helper_set_config], [ 84.496561] [drm:drm_crtc_helper_set_config], [CRTC:4] [FB:31] #connectors=1 (x y) (0 0) [ 84.498323] [drm:drm_crtc_helper_set_config], modes are different, full mode set [ 84.499958] [drm:drm_mode_debug_printmodeline], Modeline 27:720x576 50 27000 720 732 796 864 576 581 586 625 0x40 0xa [ 84.502454] [drm:drm_mode_debug_printmodeline], Modeline 34: 0 27000 720 736 798 858 480 489 495 525 0x0 0xa [ 84.504672] [drm:drm_crtc_helper_set_config], [CONNECTOR:5:VGA-1] to [CRTC:3] [ 84.506205] [drm:drm_crtc_helper_set_config], [CONNECTOR:12:HDMI-A-2] to [CRTC:4] [ 84.507869] [drm:drm_crtc_helper_set_config], attempting to set mode from userspace [ 84.509699] [drm:drm_mode_debug_printmodeline], Modeline 34: 0 27000 720 736 798 858 480 489 495 525 0x0 0xa [ 84.511903] [drm:drm_crtc_helper_set_mode], [CRTC:4] [ 84.521961] [drm:intel_prepare_page_flip], preparing flip with no unpin work? [ 84.564804] [drm:intel_wait_for_vblank], vblank wait timed out [ 84.603175] [drm:ironlake_update_wm], FIFO watermarks For pipe A - plane 5, cursor: 6 [ 84.606681] [drm:ironlake_update_wm], FIFO watermarks For pipe B - plane 42, cursor: 6 [ 84.610472] [drm:intel_update_fbc], [ 84.611501] [drm:intel_choose_pipe_bpp_dither], forcing bpc to 8 for HDMI [ 84.613791] [drm:intel_choose_pipe_bpp_dither], setting pipe bpc to 8 (max display bpc 8) [ 84.616531] [drm:ironlake_crtc_mode_set], Mode for pipe 1: [ 84.617884] [drm:drm_mode_debug_printmodeline], Modeline 34: 0 27000 720 736 798 858 480 489 495 525 0x0 0xa [ 84.622337] [drm:ironlake_crtc_mode_set],
Re: [Intel-gfx] [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver
At Thu, 10 Nov 2011 21:51:50 +0800, Wu Fengguang wrote: So maybe the hardware is in some state that is unable to provide the real ELD content? That's my guess as well. I think the hardware may still be doing some form of data negotiation with the HDMI display device at that stage, and doesn't have the copy of the EDID+ELD buffer until a tiny bit later. Possibly? Look at the below dmesg. The ELD seem to available immediately after the DPMS state setting.. Interesting. Does HDMI audio work at all while HDMI DPMS off? It clears SDVO_ENABLE bit, so this might turn off both video and audio? We normally see transient blank screen and silence of audio when switching the video mode. Well, what I suspected is that ELD won't be transferred while SDVO_ENABLE is cleared. And I'm not sure whether HDMI audio is played while DPMS is off. I haven't tested it. Unfortunately I can't test it right now since my colleague is using a desk where the HDMI monitor is on... Takashi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver
On Thu, Nov 10, 2011 at 10:28:19PM +0800, Takashi Iwai wrote: At Thu, 10 Nov 2011 21:51:50 +0800, Wu Fengguang wrote: So maybe the hardware is in some state that is unable to provide the real ELD content? That's my guess as well. I think the hardware may still be doing some form of data negotiation with the HDMI display device at that stage, and doesn't have the copy of the EDID+ELD buffer until a tiny bit later. Possibly? Look at the below dmesg. The ELD seem to available immediately after the DPMS state setting.. Interesting. Does HDMI audio work at all while HDMI DPMS off? It clears SDVO_ENABLE bit, so this might turn off both video and audio? We normally see transient blank screen and silence of audio when switching the video mode. Well, what I suspected is that ELD won't be transferred while SDVO_ENABLE is cleared. It's not about SDVO_ENABLE. The transient ELD invalid state I see in dmesg is caused by the graphics driver doing ELD_Valid = 0 = trigger 1st unsolicited event write ELD contents ELD_Valid = 1 = trigger 2nd unsolicited event The two unsolicited events are described in Figure 72. PD and ELDV unsolicited responses flow for digital display codecs of the High Definition Audio Specification Rev. 1.0a. [ 467.574207] [drm:ironlake_write_eld], ELD on pipe B [ 467.579346] [drm:ironlake_write_eld], Audio directed to unknown port [ 467.584724] [drm:ironlake_write_eld], ELD: DisplayPort detected 1st event =[ 467.586540] HDMI hot plug event: Codec=3 Pin=7 Presence_Detect=1 ELD_Valid=0 [ 467.599608] [drm:ironlake_write_eld], 1st event =[ 467.599922] HDMI status: Codec=3 Pin=7 Presence_Detect=1 ELD_Valid=0 [ 467.605834] ELD size 9 [ 467.610434] [drm:sandybridge_update_wm], FIFO watermarks For pipe A - plane 7, cursor: 6 2nd event =[ 467.612365] HDMI hot plug event: Codec=3 Pin=7 Presence_Detect=1 ELD_Valid=1 [ 467.620654] [drm:sandybridge_update_wm], 2nd event =[ 467.620765] HDMI status: Codec=3 Pin=7 Presence_Detect=1 ELD_Valid=1 Depending on the timing, the 1st unsolicited event may see ELD_Valid=0 (if it's fast enough) or ELD_Valid=1 (if the event handling is delayed after the graphics driver sets ELD_Valid=1). I know that because I literally saw both cases happening in dmesg. The 1st hot plug event itself will send ELD_Valid=0, however the audio driver is not trusting this and always do a status query (the HDMI status line) whose result depends on the timing. And I'm not sure whether HDMI audio is played while DPMS is off. I haven't tested it. It will go silence on DPMS. I noticed this while doing long term HDMI audio playback tests. This should better be fixed in future on the graphics side. Unfortunately I can't test it right now since my colleague is using a desk where the HDMI monitor is on... I'm always borrowing HDMI/DP monitors and test boxes, too ;-) Thanks, Fengguang ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver
At Fri, 11 Nov 2011 10:29:25 +0800, Wu Fengguang wrote: On Thu, Nov 10, 2011 at 10:28:19PM +0800, Takashi Iwai wrote: At Thu, 10 Nov 2011 21:51:50 +0800, Wu Fengguang wrote: So maybe the hardware is in some state that is unable to provide the real ELD content? That's my guess as well. I think the hardware may still be doing some form of data negotiation with the HDMI display device at that stage, and doesn't have the copy of the EDID+ELD buffer until a tiny bit later. Possibly? Look at the below dmesg. The ELD seem to available immediately after the DPMS state setting.. Interesting. Does HDMI audio work at all while HDMI DPMS off? It clears SDVO_ENABLE bit, so this might turn off both video and audio? We normally see transient blank screen and silence of audio when switching the video mode. Well, what I suspected is that ELD won't be transferred while SDVO_ENABLE is cleared. It's not about SDVO_ENABLE. The transient ELD invalid state I see in dmesg is caused by the graphics driver doing ELD_Valid = 0 = trigger 1st unsolicited event But why this triggers at *plugging*? Wasn't it zero beforehand? If I understand correctly, changing AUD_CNTL_ST register triggers the HD-audio codec unsol event. Writing even the same value matters? write ELD contents ELD_Valid = 1 = trigger 2nd unsolicited event The two unsolicited events are described in Figure 72. PD and ELDV unsolicited responses flow for digital display codecs of the High Definition Audio Specification Rev. 1.0a. [ 467.574207] [drm:ironlake_write_eld], ELD on pipe B [ 467.579346] [drm:ironlake_write_eld], Audio directed to unknown port [ 467.584724] [drm:ironlake_write_eld], ELD: DisplayPort detected 1st event =[ 467.586540] HDMI hot plug event: Codec=3 Pin=7 Presence_Detect=1 ELD_Valid=0 [ 467.599608] [drm:ironlake_write_eld], 1st event =[ 467.599922] HDMI status: Codec=3 Pin=7 Presence_Detect=1 ELD_Valid=0 [ 467.605834] ELD size 9 [ 467.610434] [drm:sandybridge_update_wm], FIFO watermarks For pipe A - plane 7, cursor: 6 2nd event =[ 467.612365] HDMI hot plug event: Codec=3 Pin=7 Presence_Detect=1 ELD_Valid=1 [ 467.620654] [drm:sandybridge_update_wm], 2nd event =[ 467.620765] HDMI status: Codec=3 Pin=7 Presence_Detect=1 ELD_Valid=1 Depending on the timing, the 1st unsolicited event may see ELD_Valid=0 (if it's fast enough) or ELD_Valid=1 (if the event handling is delayed after the graphics driver sets ELD_Valid=1). I know that because I literally saw both cases happening in dmesg. The 1st hot plug event itself will send ELD_Valid=0, however the audio driver is not trusting this and always do a status query (the HDMI status line) whose result depends on the timing. The problem in this procedure is that this looks as if you are re-connecting the HDMI from the audio-codec POV. We might end up with some delayed probe with a dedicated work_struct (because it's bad to have a too long delay in unsol event handler that run on a single workq). And I'm not sure whether HDMI audio is played while DPMS is off. I haven't tested it. It will go silence on DPMS. I noticed this while doing long term HDMI audio playback tests. This should better be fixed in future on the graphics side. Hm, but I wonder what could be done alternatively. Hopefully there is a register for video-only control... thanks, Takashi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver
Hi Christopher,
Now, onto the intel-gpu-tools test. I ran intel_audio_dump as requested
and it only comes back with Couldn't map MMIO region: No such file or
directory. I spent 10 minutes looking around on Google to no avail. It
seems it tries to mmap() something that doesn't exist.
What if you run it with
export HAS_PCH_SPLIT=1
intel_audio_dump
I also queued a patch for the tool. Note that if the above trick
failed to work, the applied patch won't help, too.
Thanks,
Fengguang
Subject: intel_audio_dump: fix CPT detection logic
Date: Wed Nov 02 17:16:39 CST 2011
Signed-off-by: Wu Fengguang fengguang...@intel.com
---
tools/intel_audio_dump.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- intel-gpu-tools.orig/tools/intel_audio_dump.c 2011-11-09
10:35:35.0 +0800
+++ intel-gpu-tools/tools/intel_audio_dump.c2011-11-09 10:35:35.0
+0800
@@ -1194,7 +1194,7 @@ int main(int argc, char **argv)
else
intel_get_mmio(pci_dev);
- if (HAS_PCH_SPLIT(devid) || getenv(HAS_PCH_SPLIT)) {
+ if (IS_GEN6(devid) || IS_GEN7(devid) || getenv(HAS_PCH_SPLIT)) {
intel_check_pch();
dump_cpt();
} else if (IS_GEN5(devid))
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver
Hi Fengguang, I am quoting both your messages below so read until the bottom. I've even found what looks to be the cause. On 11/9/11 2:01 PM, Wu Fengguang wrote: Christopher, On Wed, Nov 09, 2011 at 05:30:18PM +0800, Christopher White wrote: Couldn't resist connecting to my machine over VNC even though I'm not home. Thanks a lot! So, I booted it with the new patch and see that while you HAVE found the bug, the new register addresses still seem to be wrong. Instead of the audio registers containing their default, pre-filled, standard 2-speaker configuration, Yeah, AFAICS the BIOS may choose to pre-fill some simple ELD at boot time. Indeed, I could tell that the 2ch standard configuration was a pre-filled default. it's now being overwritten - which is good. With garbage - which is bad. ;-) One step forward ;-) Yes! ;-) One possible cause is that the SandyBridge addresses shouldn't use the same register addresses as IvyBridge after all. This will have to be double checked. What puzzled me is that I've been testing DisplayPort on a Sandybridge notebook today and it is working fine. The other question is, why the intel_audio_dump tool goes wrong with your hardware? It's reading the right register addresses in all the boxes I tested... I've got good news about that further down. Instead of /proc/asound/card0/eld#3.0 containing the default 2-speaker configuration, it now contains: monitor_present1 eld_valid1 So at least it sets the ELD valid bit right. Hehe. That might be a side effect of incorrect writing though. We'll see. monitor_name connection_typeHDMI eld_version[0x0] reserved edid_version[0x0] no CEA EDID Timing Extension block present manufacture_id0x0 product_id0x0 port_id0x0 support_hdcp0 support_ai0 audio_sync_delay0 speakers[0x0] sad_count0 You can see that the data is obviously zeroed out, and I bet it's due to a misaligned address. Did you view *every* ELD file? cat /proc/asound/card0/eld* Yeah, the attached _eld.txt file shows that there is only *one* ELD file there. This is the file that used to contain the default 2ch initialization of the audio registers. At least we've come far enough that it's now being overwritten. It's being incorrectly overwritten or corrupted afterwards, but it's a start. I verified that it's writing to the right address in the spec. And even find direct evidence in your dmesg that the ELD contents are correctly received and interpreted by the audio driver: [ 10.278612] HDMI hot plug event: Pin=7 Presence_Detect=1 ELD_Valid=1 [ 10.278644] HDMI status: Pin=7 Presence_Detect=1 ELD_Valid=1 Output by snd_hdmi_show_eld(): [ 10.282143] HDMI: detected monitor TX-SR607 at connection type HDMI [ 10.282145] HDMI: available speakers: FL/FR LFE FC RL/RR RLC/RRC [ 10.282147] HDMI: supports coding type LPCM: channels = 2, rates = 44100 48000 88200 176400 192000 384000, bits = 16 20 24 [ 10.282149] HDMI: supports coding type LPCM: channels = 8, rates = 44100 48000 88200 176400 192000 384000, bits = 16 20 24 [ 10.282151] HDMI: supports coding type AC-3: channels = 8, rates = 44100 48000 88200, max bitrate = 64 [ 10.282152] HDMI: supports coding type DTS: channels = 8, rates = 48000 88200, max bitrate = 1536000 [ 10.282154] HDMI: supports coding type DSD (One Bit Audio): channels = 6, rates = 48000 [ 10.282155] HDMI: supports coding type E-AC-3/DD+ (Dolby Digital Plus): channels = 8, rates = 48000 88200 [ 10.282157] HDMI: supports coding type DTS-HD: channels = 8, rates = 48000 88200 176400 192000 384000 [ 10.282159] HDMI: supports coding type MLP (Dolby TrueHD): channels = 8, rates = 88200 192000 Hmm, wow, I compared this to my older dmesg.log which I gave you a few weeks ago, and that's definitely news. It was only showing the default 2ch configuration before. Now it IS writing to the correct address. How VERY strange! So it DOES write to the correct register... It gets STRANGER though, as you'll see at the bottom of this email. Booting with drm.debug=6 produced the attached log file which I've included for completeness. However, there's nothing strange in it. Thanks, the full dmesg helped a lot! On 11/9/11 10:00 AM, Christopher White wrote: Good day, Fengguang! Great work! This sounds very promising! I went through the ELD parsing code myself (drm_edid_to_eld), as my programmer mind's curiosity killed me even though I didn't really have time for it, and I could see that it grabs the CEA extension block, grabs the monitor name string, then goes through each data block collection, copying all short descriptor data for each of the block types we're interested in. Good and clean code. So, I came to the same conclusion - that the parsing code was completely correct. I'm therefore very happy to hear that you've found the real problem; trying to write the ELD structure to the wrong audio
Re: [Intel-gfx] [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver
Christopher,
The dump tool did not work with that environment variable either.
However, it occurred to me that intel_audio_dump may be too outdated in
my distro. It was built on 2010-04-01, v1.0.2+git20100324. If I look at
http://cgit.freedesktop.org/xorg/app/intel-gpu-tools/ I can see that the
reason for this is that the latest stable was 1.0.2 tagged nearly two
years ago.
I decided to build intel-gpu-tools from the latest Git source instead.
That took a while to figure out as it also needed xutils-dev package for
xorg-macros.m4, required by the autoconf script, and libtool (needed by
the resulting configure script). So the complete list of dependencies is
autotools-dev pkg-config libpciaccess-dev libdrm-dev libdrm-intel1
xutils-dev libtool. DebugFS must also be ready and mounted on
Sorry I should have reminded you of the build dependencies. I use
debian and it's fairly easy for me to install the relevant packages:
apt-get build-dep intel-gpu-tools
/sys/kernel/debug and enabled in the kernel (kernel hacking debug file
system). Finally, building it is standard procedure with autogen.sh,
configure, make and make install. (I am writing down these instructions
just in case someone else reads this down the line; Google is a
wonderful thing).
After building, I tried running intel_audio_dump, and was first
dumbfounded as it gave me the same error, Couldn't map MMIO region. I
verified with which intel_audio_dump that it DID point to the NEW
/usr/local/bin/intel_audio_dump path, and not the OLD
/usr/bin/intel_audio_dump path.
However, I thought that maybe it WAS running the OLD version for some
reason despite claiming it was pointing to the new one. So, I tried
calling it specifically with the full path to the new binary, and...
SUCCESS! You need to tag a new release version of intel-gpu-tools soon
so that distros are updated, since the old 1.0.2 release does NOT
support SandyBridge.
FYI I'm preparing a bunch of patches for intel_audio_dump :-)
I've attached the full dump here. Scroll down to the bottom and you can
see that I was right in my theory that all the ELD data was zeroed out.
But hey at least we're getting SOMEWHERE! ;-)
So what we KNOW now: ELD parsing code = 100% correct. ELD writing to
correct audio register = 100% correct, verified by looking at
snd_hdmi_show_eld()'s output in dmesg log. However, SOMETIME after the
boot, it seems that it gets corrupted/zeroed out. I'll replicate the
Yes, and I'm still puzzled how come ironlake_write_eld() writes
nonzero ELD to pipe A and the audio driver gets all zero. Some hw
reset in between (sounds very unlikely)?
relevant dump portion here:
AUD_HDMIW_HDMIEDID_A HDMI ELD:
1d00 6882004f 3dcb6508
That's written by ironlake_write_eld(), which will never write all
zeros because it has an explicit test
if (!eld[0])
return;
AUD_HDMIW_HDMIEDID_B HDMI ELD:
AUD_HDMIW_HDMIEDID_C HDMI ELD:
AUD_HDMIW_INFOFR_A HDMI audio Infoframe:
84010a70 0100
AUD_HDMIW_INFOFR_B HDMI audio Infoframe:
AUD_HDMIW_INFOFR_C HDMI audio Infoframe:
I decided to look in /sys/class/drm/card0-HDMI-A-2/edid and it's 0
bytes! This used to be 256 bytes! How freaking weird is that?! That
That's mysterious indeed.
means: System boots up, Intel driver sees 256 byte EDID, parses it into
ELD, writes it to the audio register, the system dmesg log shows that it
parsed all supported audio modes correctly, then the system boots and
edid becomes 0 bytes, and the ELD is zeroed out. What the heck is going
on here? :-O I tried dmesg | grep HDMI: detected monitor and see
NOTHING later than the initial boot event, meaning I have no freaking
clue why it's zeroing out the EDID.
I'm sure that the gfx/audio driver code I wrote won't zero out the
ELD SILENTLY without any clues in dmesg. There must be something else
happening.
It almost looks like the act of writing ELD to the audio register is
tampering with the ability of the graphics card to read the EDID itself
after that point. Erhmm... This is very odd.
Finally, I tried a complete power cycle of every component, turning off
the outlet power on everything. I then started the Receiver, then the
Projector, and finally the computer. Not that startup order matters
much, but this is the optimal order. However, it still did the same
thing. With one difference. /sys/class/drm/card0-HDMI-A-2/edid now
contains the correct contents. Everything else was as before:
/proc/asound/card0/eld#3.0 full of zeroes as shown in the attached file.
Intel_Audio_Dump showing the EXACT SAME zeroed out content as I have
quoted above.
Re: [Intel-gfx] [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver
Wow I reproduced the bug and got a very interesting dmesg: gfx =[ 4561.287980] [drm:intel_write_eld], ELD on [CONNECTOR:12:HDMI-A-2], [ENCODER:11:TMDS-11] gfx =[ 4561.291730] [drm:ironlake_write_eld], ELD on pipe B gfx =[ 4561.293804] [drm:ironlake_write_eld], Audio directed to unknown port gfx =[ 4561.295273] [drm:ironlake_write_eld], alsa = [ 4561.295486] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=0 alsa = [ 4561.295564] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=0 gfx =[ 4561.300020] ELD size 13 alsa = [ 4561.300697] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=1 alsa = [ 4561.303322] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=1 alsa = [ 4561.311120] ALSA hda_eld.c:259 HDMI: Unknown ELD version 0 Hey the two parts are interleaved! But still it should work all fine, since the gfx driver does set ELD_Valid = 0 write ELD set ELD_Valid = 1 So the audio driver would read the correct ELD unless the ELD content and flag writes are somehow _reordered_ underneath. Or the ELD content writes take some time to take effect? Thanks, Fengguang ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver
On Thu, Nov 10, 2011 at 03:33:50PM +0800, Wu Fengguang wrote: Wow I reproduced the bug and got a very interesting dmesg: gfx =[ 4561.287980] [drm:intel_write_eld], ELD on [CONNECTOR:12:HDMI-A-2], [ENCODER:11:TMDS-11] gfx =[ 4561.291730] [drm:ironlake_write_eld], ELD on pipe B gfx =[ 4561.293804] [drm:ironlake_write_eld], Audio directed to unknown port gfx =[ 4561.295273] [drm:ironlake_write_eld], alsa = [ 4561.295486] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=0 alsa = [ 4561.295564] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=0 gfx =[ 4561.300020] ELD size 13 alsa = [ 4561.300697] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=1 alsa = [ 4561.303322] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=1 alsa = [ 4561.311120] ALSA hda_eld.c:259 HDMI: Unknown ELD version 0 Hey the two parts are interleaved! But still it should work all fine, since the gfx driver does set ELD_Valid = 0 write ELD set ELD_Valid = 1 So the audio driver would read the correct ELD unless the ELD content and flag writes are somehow _reordered_ underneath. Or the ELD content writes take some time to take effect? Just confirmed that adding 1s delay can fix it! New dmesg is: [ 48.564923] [drm:drm_crtc_helper_set_mode], [ENCODER:11:TMDS-11] set [MODE:34:] [ 48.567481] [drm:intel_hdmi_mode_set], Enabling HDMI audio on pipe B [ 48.568975] [drm:intel_write_eld], ELD on [CONNECTOR:12:HDMI-A-2], [ENCODER:11:TMDS-11] [ 48.571728] [drm:ironlake_write_eld], ELD on pipe B [ 48.572882] [drm:ironlake_write_eld], Audio directed to unknown port [ 48.575252] [drm:ironlake_write_eld], [ 48.575400] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=0 [ 48.575487] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=0 [ 48.580116] ELD size 13 [ 48.580795] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=1 [ 48.583340] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=1 [ 48.632514] [drm:intel_wait_for_vblank], vblank wait timed out [ 48.685322] [drm:intel_wait_for_vblank], vblank wait timed out [ 48.687438] [drm:ironlake_update_wm], FIFO watermarks For pipe A - plane 5, cursor: 6 [ 48.687438] [drm:ironlake_update_wm], FIFO watermarks For pipe A - plane 5, cursor: 6 [ 48.690106] [drm:ironlake_update_wm], FIFO watermarks For pipe B - plane 42, cursor: 6 [ 48.745204] [drm:intel_wait_for_vblank], vblank wait timed out [ 48.798035] [drm:intel_wait_for_vblank], vblank wait timed out [ 48.799633] [drm:ironlake_fdi_link_train], FDI_RX_IIR 0x100 [ 48.802686] [drm:ironlake_fdi_link_train], FDI train 1 done. [ 48.805103] [drm:ironlake_fdi_link_train], FDI_RX_IIR 0x600 [ 48.807246] [drm:ironlake_fdi_link_train], FDI train 2 done. [ 48.809426] [drm:ironlake_fdi_link_train], FDI train done [ 48.813960] [drm:intel_update_fbc], [ 48.814782] [drm:drm_crtc_helper_set_config], Setting connector DPMS state to on [ 48.818093] [drm:drm_crtc_helper_set_config],[CONNECTOR:12:HDMI-A-2] set DPMS on [ 48.828633] [drm:intel_prepare_page_flip], preparing flip with no unpin work? [ 49.618962] HDMI: detected monitor RX-V1800 at connection type HDMI [ 49.621013] HDMI: available speakers: FL/FR LFE FC RL/RR RC RLC/RRC [ 49.622304] HDMI: supports coding type LPCM: channels = 2, rates = 32000 44100 48000 96000 176400 192000 384000, bits = 16 20 24 [ 49.625069] HDMI: supports coding type LPCM: channels = 8, rates = 32000 44100 48000 96000 176400 192000 384000, bits = 16 20 24 [ 49.628535] HDMI: supports coding type AC-3: channels = 6, rates = 32000 44100 48000, max bitrate = 64 [ 49.630810] HDMI: supports coding type DTS: channels = 7, rates = 32000 44100 48000 96000 176400, max bitrate = 1536000 [ 49.633148] HDMI: supports coding type DSD (One Bit Audio): channels = 6, rates = 44100 [ 49.635039] HDMI: supports coding type E-AC-3/DD+ (Dolby Digital Plus): channels = 8, rates = 44100 48000 [ 49.637130] HDMI: supports coding type MLP (Dolby TrueHD): channels = 8, rates = 48000 176400 384000 [ 49.639172] HDMI: supports coding type DTS-HD: channels = 8, rates = 48000 176400 384000 Thanks, Fengguang Subject: Date: Thu Nov 10 15:41:11 CST 2011 Signed-off-by: Wu Fengguang fengguang...@intel.com --- sound/pci/hda/hda_eld.c |3 +++ 1 file changed, 3 insertions(+) --- linux.orig/sound/pci/hda/hda_eld.c 2011-11-10 15:39:43.0 +0800 +++ linux/sound/pci/hda/hda_eld.c 2011-11-10 15:52:09.0 +0800 @@ -23,6 +23,7 @@ #include linux/init.h #include linux/slab.h +#include linux/delay.h #include sound/core.h #include asm/unaligned.h #include hda_codec.h @@ -326,6 +327,8 @@ int snd_hdmi_get_eld(struct hdmi_eld *el if (!eld-eld_valid) return -ENOENT; + msleep(1000); + size = snd_hdmi_get_eld_size(codec,
Re: [Intel-gfx] [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver
Hi Christopher,
I don't find anything wrong with the ELD parsing code, however I do
find a bug that prevented ELD from being passed to the audio driver on
SandyBridge.
I just posted the fix. For your convenience, it's attached in this
email too.
Thanks,
Fengguang
On Fri, Oct 28, 2011 at 03:57:23AM +0800, Christopher White wrote:
There appears to be some issues with the patch? I'm on SandyBridge and
using the HD3000's HDMI.
I've now tried manually merging the ELD patch (both files Wu Fengguang
submitted) and compiling Kernel 3.0.4. I've also tried drm-intel-next
Kernel 3.1 pre-built from
http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-next/current/ as
I knew it was built from keithp's latest drm-intel-next repository.
Both of these methods had the patch applied, yet neither were able to
read the ELD correctly from my Onkyo TX-SR607 receiver.
If I manually dump the EDID from my receiver and analyze it with Monitor
Asset Manager (by EnTech Taiwan), it shows that the ELD contains an 8
channel specification up to 192 kHz, and that's what's being exposed
over HDMI to the Intel graphics adapter, yet this isn't detected. It
just plain isn't being read, and is falling back to the default 2ch
16kHz configuration. It's exactly as it was in the past, before this
patch attempt.
You can see my 256 byte EDID dump, straight from the receiver, over at:
http://www.pulseforce.com/node/edid.dump
It shows exactly what the receiver is exposing over HDMI, proving that
it's not the device that's at fault.
Any ideas what's wrong? Here's the HDMI messages from the startup log:
HDMI status: Pin=7 Presence_Detect=1 ELD_Valid=1
HDMI: detected monitor at connection type HDMI
HDMI: available speakers: FL/FR
HDMI: supports coding type LPCM: channels = 2, rates = 44100 48000
88200, bits = 16
HDMI hot plug event: Pin=7 Presence_Detect=1 ELD_Valid=1
HDMI status: Pin=7 Presence_Detect=1 ELD_Valid=1
input: HDA Intel PCH HDMI/DP as
/devices/pci:00/:00:1b.0/sound/card0/input9
HDMI: detected monitor at connection type HDMI
HDMI: available speakers: FL/FR
HDMI: supports coding type LPCM: channels = 2, rates = 44100 48000
88200, bits = 16
HDMI hot plug event: Pin=7 Presence_Detect=1 ELD_Valid=1
HDMI status: Pin=7 Presence_Detect=1 ELD_Valid=1
HDMI: detected monitor at connection type HDMI
HDMI: available speakers: FL/FR
HDMI: supports coding type LPCM: channels = 2, rates = 44100 48000
88200, bits = 16
Christopher White
Subject: drm/i915: fix ELD writing for SandyBridge
Date: Wed Nov 09 13:17:14 CST 2011
SandyBridge should be using the same register addresses as IvyBridge.
Signed-off-by: Wu Fengguang fengguang...@intel.com
---
drivers/gpu/drm/i915/i915_reg.h |6 +++---
drivers/gpu/drm/i915/intel_display.c | 10 +-
2 files changed, 8 insertions(+), 8 deletions(-)
--- linux.orig/drivers/gpu/drm/i915/i915_reg.h 2011-11-09 13:17:19.0
+0800
+++ linux/drivers/gpu/drm/i915/i915_reg.h 2011-11-09 13:18:39.0
+0800
@@ -3543,8 +3543,8 @@
#define GEN5_ELD_VALIDB(1 0)
#define GEN5_CP_READYB (1 1)
-#define GEN7_HDMIW_HDMIEDID_A 0xE5050
-#define GEN7_AUD_CNTRL_ST_A0xE50B4
-#define GEN7_AUD_CNTRL_ST2 0xE50C0
+#define GEN6_HDMIW_HDMIEDID_A 0xE5050
+#define GEN6_AUD_CNTL_ST_A 0xE50B4
+#define GEN6_AUD_CNTRL_ST2 0xE50C0
#endif /* _I915_REG_H_ */
--- linux.orig/drivers/gpu/drm/i915/intel_display.c 2011-11-09
13:19:28.0 +0800
+++ linux/drivers/gpu/drm/i915/intel_display.c 2011-11-09 13:20:02.0
+0800
@@ -5857,14 +5857,14 @@ static void ironlake_write_eld(struct dr
int aud_cntl_st;
int aud_cntrl_st2;
- if (IS_IVYBRIDGE(connector-dev)) {
- hdmiw_hdmiedid = GEN7_HDMIW_HDMIEDID_A;
- aud_cntl_st = GEN7_AUD_CNTRL_ST_A;
- aud_cntrl_st2 = GEN7_AUD_CNTRL_ST2;
- } else {
+ if (IS_GEN5(connector-dev)) {
hdmiw_hdmiedid = GEN5_HDMIW_HDMIEDID_A;
aud_cntl_st = GEN5_AUD_CNTL_ST_A;
aud_cntrl_st2 = GEN5_AUD_CNTL_ST2;
+ } else {
+ hdmiw_hdmiedid = GEN6_HDMIW_HDMIEDID_A;
+ aud_cntl_st = GEN6_AUD_CNTL_ST_A;
+ aud_cntrl_st2 = GEN6_AUD_CNTRL_ST2;
}
i = to_intel_crtc(crtc)-pipe;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver
On 11/2/11 2:45 AM, Wu Fengguang wrote: Hi Christopher, The log does confirm that the drm_edid_to_eld function is running, and that we're not far from a solution: [ 21.061417] [drm:drm_edid_to_eld], ELD monitor TX-SR607 [ 21.061421] [drm:drm_edid_to_eld], ELD size 13, SAD count 8 It looks all sane to this point. As for where I am getting the EDID dump from, I am getting it from /sys/devices/pci:00/:00:02.0/drm/card0/card0-HDMI-A-2/edid, which provides direct virtual access to the EDID response of the connected device. I'm completely confident that the device doesn't report too small of a buffer size, and that it's completely compliant with the spec: If you Agreed. have a Windows virtual machine (or if you're masochistic enough - a real machine) you should download the excellent, free Monitor Asset Manager by EnTech Taiwan from http://www.entechtaiwan.com/util/moninfo.shtm. It will let you analyze EDID + ELD + extended timings, etc from an EDID dump, such as the one taken above. It understands every part of EDID. I've put together a small archive containing my exact EDID binary dump (taken from the above device path), the FULL dmesg log, as well as EnTech's interpretation of the EDID dump, showing the full list of supported channels, formats, etc. I'm guessing there is some tiny bug in your interpretation of how to read ELD, maybe an incorrect 1 byte offset or something like that. Here's the pack: http://www.pulseforce.com/node/edid_to_eld.zip Thanks! It's great tool and information! If you do a hex analysis of my EDID dump and compare it to what the edid_to_eld function is trying to do, it will probably show what's wrong. I'd love to have a look at that myself but am really busy with a project over here so I can't help out other than to recompile and test as fast as I can. Would you install the intel-gpu-tools package and run its intel_audio_dump utility? If not shipped with your distribution, the source code is also available in git://anongit.freedesktop.org/git/xorg/app/intel-gpu-tools You'll need to install packages autotools-dev pkg-config libpciaccess-dev libdrm-dev libdrm-intel1 in order to build it from source. intel_audio_dump will dump the ELD data in the hardware buffer for use by the audio driver. By verifying if that data is correct, we are able to analyze whether and how the audio driver goes wrong. Thanks, Fengguang I've been really busy on a project (as mentioned in my last posting) and apologize for the 2 day delay. The project is now done and no further response delays will happen. Promise. Alright, so first of all I am glad that you found the tool and information useful. Now, onto the intel-gpu-tools test. I ran intel_audio_dump as requested and it only comes back with Couldn't map MMIO region: No such file or directory. I spent 10 minutes looking around on Google to no avail. It seems it tries to mmap() something that doesn't exist. I then spent some time looking in /var/log/Xorg.0.log to double-check what driver it's using. It says: Matched intel as autoconfigured driver 0 Matched vesa as autoconfigured driver 1 Matched fbdev as autoconfigured driver 2 VESA: driver for VESA chipsets: vesa FBDEV: driver for framebuffer: fbdev Loading: /usr/lib/xorg/modules/drivers/intel_drv.so All in all it looks fine, at least as far as I can tell. I mean, we already KNOW the driver has to be running since I see the DRM module in the logs. So, the Intel driver is running, yet whatever file intel_audio_dump is looking for doesn't exist. We already know that the DRM driver is reading the correct EDID, by the way, since we saw [ 21.061417] [drm:drm_edid_to_eld], ELD monitor TX-SR607. The EDID it's reading from is the dump I linked to in the previous posting. To go the extra mile, I just looked at the xf86-video-intel source in src/reg_dumper_util.c, which is where the Couldn't map MMIO region message originated. I now see that it's not trying to mmap() a physical file. It tries to map the graphics card's physical memory using pci_device_map_range(dev, dev-regions[mmio_bar].base_addr, dev-regions[mmio_bar].size, PCI_DEV_MAP_FLAG_WRITABLE, mmio); It tries that AFTER it has already found the graphics adapter and verified that it's from Intel. So, why it fails to actually map the memory of the device is anyone's guess. Perhaps there's no support for the HD3000 in intel_audio_dump? Anyway, with all of this out of the way: Why not instead look at the EDID binary dump I sent you and step through the edid_to_eld() function to see what it's doing? Christopher ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver
Wu Fengguang fengguang.wu at intel.com writes: Hi Christopher, The log does confirm that the drm_edid_to_eld function is running, and that we're not far from a solution: [ 21.061417] [drm:drm_edid_to_eld], ELD monitor TX-SR607 [ 21.061421] [drm:drm_edid_to_eld], ELD size 13, SAD count 8 It looks all sane to this point. As for where I am getting the EDID dump from, I am getting it from /sys/devices/pci:00/:00:02.0/drm/card0/card0-HDMI-A-2/edid, which provides direct virtual access to the EDID response of the connected device. I'm completely confident that the device doesn't report too small of a buffer size, and that it's completely compliant with the spec: If you Agreed. have a Windows virtual machine (or if you're masochistic enough - a real machine) you should download the excellent, free Monitor Asset Manager by EnTech Taiwan from http://www.entechtaiwan.com/util/moninfo.shtm. It will let you analyze EDID + ELD + extended timings, etc from an EDID dump, such as the one taken above. It understands every part of EDID. I've put together a small archive containing my exact EDID binary dump (taken from the above device path), the FULL dmesg log, as well as EnTech's interpretation of the EDID dump, showing the full list of supported channels, formats, etc. I'm guessing there is some tiny bug in your interpretation of how to read ELD, maybe an incorrect 1 byte offset or something like that. Here's the pack: http://www.pulseforce.com/node/edid_to_eld.zip Thanks! It's great tool and information! If you do a hex analysis of my EDID dump and compare it to what the edid_to_eld function is trying to do, it will probably show what's wrong. I'd love to have a look at that myself but am really busy with a project over here so I can't help out other than to recompile and test as fast as I can. Would you install the intel-gpu-tools package and run its intel_audio_dump utility? If not shipped with your distribution, the source code is also available in git://anongit.freedesktop.org/git/xorg/app/intel-gpu-tools You'll need to install packages autotools-dev pkg-config libpciaccess-dev libdrm-dev libdrm-intel1 in order to build it from source. intel_audio_dump will dump the ELD data in the hardware buffer for use by the audio driver. By verifying if that data is correct, we are able to analyze whether and how the audio driver goes wrong. Thanks, Fengguang I have a similar receiver to Christopher, an Onkyo TX-SR507, which is the same model year, but fewer speaker outputs (5.1 instead of his I think 7.2). I had been having trouble getting ELD data to read properly, but was able to play sound (for the most part, I'll touch on that below). I have an ECS H55H-I, so the H55 chipset. The alsa generated file /proc/asound/card0/eld#3.0 used to say there was no valid ELD data and just had zeroes in all fields. Following Keith Packard's suggestion, I checked out rev 43672a0784707d795556b1f93925da8b8e797d03 (I forget how much you can truncate a git rev number and still be safe) from Linus's kernel git. git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git . I compiled and restarted and then I did get good ELD. There is a peculiar error at the end of dmesg that says [73093.946346] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 29, but the proc eld file still looks good. Despite all of that, speaker-test only gives good results with the rate set to 44100 or its multiples 88200 and 176400. 32000, 48000, 96000, 192000 do play the pink noise, but drop out intermittently. The problem seems to either cause or be an effect of the receiver losing its mind about what the incoming stream is. While it plays the 44100 speaker-test the front panel lights are locked in to PCM MULTICHANNEL HDMI. When I play 48000 the same lights come on, but every few seconds PCM and MULTICHANNEL will go off at the same time, followed by HDMI. This is when the sound cuts out, the video however remains on screen untouched. The HDMI light will come back on shortly after, followed by the PCM MULTICHANNEL and sound will resume. This was a problem before the patched kernel that I was hoping proper ELD info would clear up. I see no messages in dmesg while the skipping is occurring, nor anything interesting from HDAAnalyzer. Here are some dumps: proc/asound/card0/eld#3.0 http://pastebin.com/d3FsG8fn intel-audio-dump http://pastebin.com/f6M915Ui alsa-info http://pastebin.com/ddwNcLVL Entech output http://pastebin.com/7ENTiBrb Thanks, -Tony Olivo ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver
On Tue, Nov 1, 2011 at 8:45 PM, Wu Fengguang fengguang...@intel.com wrote: Hi Christopher, The log does confirm that the drm_edid_to_eld function is running, and that we're not far from a solution: [ 21.061417] [drm:drm_edid_to_eld], ELD monitor TX-SR607 [ 21.061421] [drm:drm_edid_to_eld], ELD size 13, SAD count 8 It looks all sane to this point. As for where I am getting the EDID dump from, I am getting it from /sys/devices/pci:00/:00:02.0/drm/card0/card0-HDMI-A-2/edid, which provides direct virtual access to the EDID response of the connected device. I'm completely confident that the device doesn't report too small of a buffer size, and that it's completely compliant with the spec: If you Agreed. have a Windows virtual machine (or if you're masochistic enough - a real machine) you should download the excellent, free Monitor Asset Manager by EnTech Taiwan from http://www.entechtaiwan.com/util/moninfo.shtm. It will let you analyze EDID + ELD + extended timings, etc from an EDID dump, such as the one taken above. It understands every part of EDID. I've put together a small archive containing my exact EDID binary dump (taken from the above device path), the FULL dmesg log, as well as EnTech's interpretation of the EDID dump, showing the full list of supported channels, formats, etc. I'm guessing there is some tiny bug in your interpretation of how to read ELD, maybe an incorrect 1 byte offset or something like that. Here's the pack: http://www.pulseforce.com/node/edid_to_eld.zip Thanks! It's great tool and information! If you do a hex analysis of my EDID dump and compare it to what the edid_to_eld function is trying to do, it will probably show what's wrong. I'd love to have a look at that myself but am really busy with a project over here so I can't help out other than to recompile and test as fast as I can. Would you install the intel-gpu-tools package and run its intel_audio_dump utility? If not shipped with your distribution, the source code is also available in git://anongit.freedesktop.org/git/xorg/app/intel-gpu-tools You'll need to install packages autotools-dev pkg-config libpciaccess-dev libdrm-dev libdrm-intel1 in order to build it from source. intel_audio_dump will dump the ELD data in the hardware buffer for use by the audio driver. By verifying if that data is correct, we are able to analyze whether and how the audio driver goes wrong. I think I experience similar issues. In my case the multi-channel pcm playback through HDMI doesn't work. Stereo and passthrough seem to work fine though !? It's hookedup to my TV via a yamaha receiver. I'm currently running Linux 3.1 with a G45 chipset. libdrm 2.4.27-1 xf86-video-intel 2.16.0-1 The eld seems be incorrectly parsed, though the kernel log didn't give much info. The eld info from alsa is rather empty: cat /proc/asound/Intel/eld#3.0 monitor_present 1 eld_valid 0 Using the same Monitor Asset Manager I was able to verify that the edid from (/sys/devices/pci\:00/\:00\:02.0/drm/card0/card0-HDMI-A-1/edid ) does seem to contain the correct information. I've attached both the edid and the output of Monitor Asset Manager.In addition I also run the intel_audio_dump. Let me know if you need anymore information. Cheers, Sander PS. Hope the attachments are not too big. Monitor Model name... SAMSUNG Manufacturer. Samsung Plug and Play ID. SAM050D Serial number 1 Manufacture date. 2008, ISO week 48 Filter driver None - EDID revision 1.3 Input signal type Digital Color bit depth.. Undefined Display type. RGB color Screen size.. 160 x 90 mm (7.2 in) Power management. Not supported Extension blocs.. 1 (CEA-EXT) - DDC/CI... n/a Color characteristics Default color space.. Non-sRGB Display gamma 2.20 Red chromaticity. Rx 0.640 - Ry 0.330 Green chromaticity... Gx 0.300 - Gy 0.600 Blue chromaticity Bx 0.150 - By 0.060 White point (default) Wx 0.313 - Wy 0.329 Additional descriptors... None Timing characteristics Horizontal scan range 26-81kHz Vertical scan range.. 24-75Hz Video bandwidth.. 150MHz CVT standard. Not supported GTF standard. Not supported Additional descriptors... None Preferred timing. Yes Native/preferred timing.. 1920x1080p at 60Hz (16:9) Modeline... 1920x1080 148.500 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync Detailed timing #1... 1280x720p at 60Hz (16:9) Modeline... 1280x720 74.250 1280 1390 1430 1650 720 725 730 750 +hsync +vsync Standard timings supported 720 x 400p at 70Hz - IBM VGA 640 x 480p at 60Hz - IBM VGA 640 x 480p at
Re: [Intel-gfx] [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver
Dear Sander, Am Mittwoch, den 02.11.2011, 01:10 -0500 schrieb Sander Jansen: On Tue, Nov 1, 2011 at 8:45 PM, Wu Fengguang fengguang...@intel.com wrote: The log does confirm that the drm_edid_to_eld function is running, and that we're not far from a solution: [ 21.061417] [drm:drm_edid_to_eld], ELD monitor TX-SR607 [ 21.061421] [drm:drm_edid_to_eld], ELD size 13, SAD count 8 It looks all sane to this point. As for where I am getting the EDID dump from, I am getting it from /sys/devices/pci:00/:00:02.0/drm/card0/card0-HDMI-A-2/edid, which provides direct virtual access to the EDID response of the connected device. I'm completely confident that the device doesn't report too small of a buffer size, and that it's completely compliant with the spec: If you Agreed. have a Windows virtual machine (or if you're masochistic enough - a real machine) you should download the excellent, free Monitor Asset Manager by EnTech Taiwan from http://www.entechtaiwan.com/util/moninfo.shtm. It will let you analyze EDID + ELD + extended timings, etc from an EDID dump, such as the one taken above. It understands every part of EDID. I've put together a small archive containing my exact EDID binary dump (taken from the above device path), the FULL dmesg log, as well as EnTech's interpretation of the EDID dump, showing the full list of supported channels, formats, etc. I'm guessing there is some tiny bug in your interpretation of how to read ELD, maybe an incorrect 1 byte offset or something like that. Here's the pack: http://www.pulseforce.com/node/edid_to_eld.zip Thanks! It's great tool and information! If you do a hex analysis of my EDID dump and compare it to what the edid_to_eld function is trying to do, it will probably show what's wrong. I'd love to have a look at that myself but am really busy with a project over here so I can't help out other than to recompile and test as fast as I can. Would you install the intel-gpu-tools package and run its intel_audio_dump utility? If not shipped with your distribution, the source code is also available in git://anongit.freedesktop.org/git/xorg/app/intel-gpu-tools You'll need to install packages autotools-dev pkg-config libpciaccess-dev libdrm-dev libdrm-intel1 in order to build it from source. intel_audio_dump will dump the ELD data in the hardware buffer for use by the audio driver. By verifying if that data is correct, we are able to analyze whether and how the audio driver goes wrong. I think I experience similar issues. In my case the multi-channel pcm playback through HDMI doesn't work. Stereo and passthrough seem to work fine though !? It's hookedup to my TV via a yamaha receiver. I'm currently running Linux 3.1 with a G45 chipset. libdrm 2.4.27-1 xf86-video-intel 2.16.0-1 do you have Fengguang’s patch applied? This thread is about testing that patch. The eld seems be incorrectly parsed, though the kernel log didn't give much info. The eld info from alsa is rather empty: cat /proc/asound/Intel/eld#3.0 monitor_present 1 eld_valid 0 Using the same Monitor Asset Manager I was able to verify that the edid from (/sys/devices/pci\:00/\:00\:02.0/drm/card0/card0-HDMI-A-1/edid ) does seem to contain the correct information. I've attached both the edid and the output of Monitor Asset Manager.In addition I also run the intel_audio_dump. Let me know if you need anymore information. It would be great if you could test the patch. Thanks, Paul signature.asc Description: This is a digitally signed message part ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver
Hi Sander, On Tue, Nov 1, 2011 at 8:45 PM, Wu Fengguang fengguang...@intel.com wrote: Hi Christopher, The log does confirm that the drm_edid_to_eld function is running, and that we're not far from a solution: [ 21.061417] [drm:drm_edid_to_eld], ELD monitor TX-SR607 [ 21.061421] [drm:drm_edid_to_eld], ELD size 13, SAD count 8 It looks all sane to this point. As for where I am getting the EDID dump from, I am getting it from /sys/devices/pci:00/:00:02.0/drm/card0/card0-HDMI-A-2/edid, which provides direct virtual access to the EDID response of the connected device. I'm completely confident that the device doesn't report too small of a buffer size, and that it's completely compliant with the spec: If you Agreed. have a Windows virtual machine (or if you're masochistic enough - a real machine) you should download the excellent, free Monitor Asset Manager by EnTech Taiwan from http://www.entechtaiwan.com/util/moninfo.shtm. It will let you analyze EDID + ELD + extended timings, etc from an EDID dump, such as the one taken above. It understands every part of EDID. I've put together a small archive containing my exact EDID binary dump (taken from the above device path), the FULL dmesg log, as well as EnTech's interpretation of the EDID dump, showing the full list of supported channels, formats, etc. I'm guessing there is some tiny bug in your interpretation of how to read ELD, maybe an incorrect 1 byte offset or something like that. Here's the pack: http://www.pulseforce.com/node/edid_to_eld.zip Thanks! It's great tool and information! If you do a hex analysis of my EDID dump and compare it to what the edid_to_eld function is trying to do, it will probably show what's wrong. I'd love to have a look at that myself but am really busy with a project over here so I can't help out other than to recompile and test as fast as I can. Would you install the intel-gpu-tools package and run its intel_audio_dump utility? If not shipped with your distribution, the source code is also available in git://anongit.freedesktop.org/git/xorg/app/intel-gpu-tools You'll need to install packages autotools-dev pkg-config libpciaccess-dev libdrm-dev libdrm-intel1 in order to build it from source. intel_audio_dump will dump the ELD data in the hardware buffer for use by the audio driver. By verifying if that data is correct, we are able to analyze whether and how the audio driver goes wrong. I think I experience similar issues. In my case the multi-channel pcm playback through HDMI doesn't work. Stereo and passthrough seem to work fine though !? It's hookedup to my TV via a yamaha receiver. Yeah, multi-channel playback should not work due to the audio driver not knowing the HDMI sink is multi-channel capable. Stereo and passthrough should work always. I'm currently running Linux 3.1 with a G45 chipset. libdrm 2.4.27-1 xf86-video-intel 2.16.0-1 The eld seems be incorrectly parsed, though the kernel log didn't give much info. The eld info from alsa is rather empty: In fact Linux 3.1 does not have the ELD patch yet. It should go into the upcoming 3.2. cat /proc/asound/Intel/eld#3.0 monitor_present 1 eld_valid 0 Using the same Monitor Asset Manager I was able to verify that the edid from (/sys/devices/pci\:00/\:00\:02.0/drm/card0/card0-HDMI-A-1/edid ) does seem to contain the correct information. That's good. I've attached both the edid and the output of Monitor Asset Manager.In addition I also run the intel_audio_dump. Let me know if you need anymore information. As the ELD patch is not there, intel_audio_dump correctly reports AUD_CNTL_ST ELD valid 0 I'm not sure if it's convenient for you to compile new kernels (with the ELD patch applied). If not, we can wait Christopher White for the feedback. Thanks, Fengguang Monitor Model name... SAMSUNG Manufacturer. Samsung Plug and Play ID. SAM050D Serial number 1 Manufacture date. 2008, ISO week 48 Filter driver None - EDID revision 1.3 Input signal type Digital Color bit depth.. Undefined Display type. RGB color Screen size.. 160 x 90 mm (7.2 in) Power management. Not supported Extension blocs.. 1 (CEA-EXT) - DDC/CI... n/a Color characteristics Default color space.. Non-sRGB Display gamma 2.20 Red chromaticity. Rx 0.640 - Ry 0.330 Green chromaticity... Gx 0.300 - Gy 0.600 Blue chromaticity Bx 0.150 - By 0.060 White point (default) Wx 0.313 - Wy 0.329 Additional descriptors... None Timing characteristics Horizontal scan range 26-81kHz Vertical scan
Re: [Intel-gfx] [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver
On Wed, Nov 2, 2011 at 2:35 AM, Paul Menzel paulepan...@users.sourceforge.net wrote: Dear Sander, Am Mittwoch, den 02.11.2011, 01:10 -0500 schrieb Sander Jansen: On Tue, Nov 1, 2011 at 8:45 PM, Wu Fengguang fengguang...@intel.com wrote: The log does confirm that the drm_edid_to_eld function is running, and that we're not far from a solution: [ 21.061417] [drm:drm_edid_to_eld], ELD monitor TX-SR607 [ 21.061421] [drm:drm_edid_to_eld], ELD size 13, SAD count 8 It looks all sane to this point. As for where I am getting the EDID dump from, I am getting it from /sys/devices/pci:00/:00:02.0/drm/card0/card0-HDMI-A-2/edid, which provides direct virtual access to the EDID response of the connected device. I'm completely confident that the device doesn't report too small of a buffer size, and that it's completely compliant with the spec: If you Agreed. have a Windows virtual machine (or if you're masochistic enough - a real machine) you should download the excellent, free Monitor Asset Manager by EnTech Taiwan from http://www.entechtaiwan.com/util/moninfo.shtm. It will let you analyze EDID + ELD + extended timings, etc from an EDID dump, such as the one taken above. It understands every part of EDID. I've put together a small archive containing my exact EDID binary dump (taken from the above device path), the FULL dmesg log, as well as EnTech's interpretation of the EDID dump, showing the full list of supported channels, formats, etc. I'm guessing there is some tiny bug in your interpretation of how to read ELD, maybe an incorrect 1 byte offset or something like that. Here's the pack: http://www.pulseforce.com/node/edid_to_eld.zip Thanks! It's great tool and information! If you do a hex analysis of my EDID dump and compare it to what the edid_to_eld function is trying to do, it will probably show what's wrong. I'd love to have a look at that myself but am really busy with a project over here so I can't help out other than to recompile and test as fast as I can. Would you install the intel-gpu-tools package and run its intel_audio_dump utility? If not shipped with your distribution, the source code is also available in git://anongit.freedesktop.org/git/xorg/app/intel-gpu-tools You'll need to install packages autotools-dev pkg-config libpciaccess-dev libdrm-dev libdrm-intel1 in order to build it from source. intel_audio_dump will dump the ELD data in the hardware buffer for use by the audio driver. By verifying if that data is correct, we are able to analyze whether and how the audio driver goes wrong. I think I experience similar issues. In my case the multi-channel pcm playback through HDMI doesn't work. Stereo and passthrough seem to work fine though !? It's hookedup to my TV via a yamaha receiver. I'm currently running Linux 3.1 with a G45 chipset. libdrm 2.4.27-1 xf86-video-intel 2.16.0-1 do you have Fengguang’s patch applied? This thread is about testing that patch. The eld seems be incorrectly parsed, though the kernel log didn't give much info. The eld info from alsa is rather empty: cat /proc/asound/Intel/eld#3.0 monitor_present 1 eld_valid 0 Using the same Monitor Asset Manager I was able to verify that the edid from (/sys/devices/pci\:00/\:00\:02.0/drm/card0/card0-HDMI-A-1/edid ) does seem to contain the correct information. I've attached both the edid and the output of Monitor Asset Manager.In addition I also run the intel_audio_dump. Let me know if you need anymore information. It would be great if you could test the patch. Ah, that explains. I was under the impression this was already in 3.1 (but then again, it was rather late for me :) ) I will give the patch a try and report back. . Thanks, Sander ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver
On Wed, Nov 2, 2011 at 6:17 AM, Sander Jansen s.jan...@gmail.com wrote: On Wed, Nov 2, 2011 at 2:35 AM, Paul Menzel paulepan...@users.sourceforge.net wrote: Dear Sander, Am Mittwoch, den 02.11.2011, 01:10 -0500 schrieb Sander Jansen: On Tue, Nov 1, 2011 at 8:45 PM, Wu Fengguang fengguang...@intel.com wrote: The log does confirm that the drm_edid_to_eld function is running, and that we're not far from a solution: [ 21.061417] [drm:drm_edid_to_eld], ELD monitor TX-SR607 [ 21.061421] [drm:drm_edid_to_eld], ELD size 13, SAD count 8 It looks all sane to this point. As for where I am getting the EDID dump from, I am getting it from /sys/devices/pci:00/:00:02.0/drm/card0/card0-HDMI-A-2/edid, which provides direct virtual access to the EDID response of the connected device. I'm completely confident that the device doesn't report too small of a buffer size, and that it's completely compliant with the spec: If you Agreed. have a Windows virtual machine (or if you're masochistic enough - a real machine) you should download the excellent, free Monitor Asset Manager by EnTech Taiwan from http://www.entechtaiwan.com/util/moninfo.shtm. It will let you analyze EDID + ELD + extended timings, etc from an EDID dump, such as the one taken above. It understands every part of EDID. I've put together a small archive containing my exact EDID binary dump (taken from the above device path), the FULL dmesg log, as well as EnTech's interpretation of the EDID dump, showing the full list of supported channels, formats, etc. I'm guessing there is some tiny bug in your interpretation of how to read ELD, maybe an incorrect 1 byte offset or something like that. Here's the pack: http://www.pulseforce.com/node/edid_to_eld.zip Thanks! It's great tool and information! If you do a hex analysis of my EDID dump and compare it to what the edid_to_eld function is trying to do, it will probably show what's wrong. I'd love to have a look at that myself but am really busy with a project over here so I can't help out other than to recompile and test as fast as I can. Would you install the intel-gpu-tools package and run its intel_audio_dump utility? If not shipped with your distribution, the source code is also available in git://anongit.freedesktop.org/git/xorg/app/intel-gpu-tools You'll need to install packages autotools-dev pkg-config libpciaccess-dev libdrm-dev libdrm-intel1 in order to build it from source. intel_audio_dump will dump the ELD data in the hardware buffer for use by the audio driver. By verifying if that data is correct, we are able to analyze whether and how the audio driver goes wrong. I think I experience similar issues. In my case the multi-channel pcm playback through HDMI doesn't work. Stereo and passthrough seem to work fine though !? It's hookedup to my TV via a yamaha receiver. I'm currently running Linux 3.1 with a G45 chipset. libdrm 2.4.27-1 xf86-video-intel 2.16.0-1 do you have Fengguang’s patch applied? This thread is about testing that patch. The eld seems be incorrectly parsed, though the kernel log didn't give much info. The eld info from alsa is rather empty: cat /proc/asound/Intel/eld#3.0 monitor_present 1 eld_valid 0 Using the same Monitor Asset Manager I was able to verify that the edid from (/sys/devices/pci\:00/\:00\:02.0/drm/card0/card0-HDMI-A-1/edid ) does seem to contain the correct information. I've attached both the edid and the output of Monitor Asset Manager.In addition I also run the intel_audio_dump. Let me know if you need anymore information. It would be great if you could test the patch. Ah, that explains. I was under the impression this was already in 3.1 (but then again, it was rather late for me :) ) I will give the patch a try and report back. . I applied the patch you posted on Sept 3 to Linux 3.1. This was just a quick test, I didn't have more time to look at it in more detail this morning. The initial look really good. I've been able to playback multi channel audio and the speaker-test was also successful. Now I did boot without the TV on, so it initialized xorg with some weird resolution from the receiver (one not supported by the TV). From what I remember looking at the edid returned from the receiver only, I believe it include timings for 1080p (I'll post this edid later today if needed). - For analog multi channel playback, you usually have to select one of the surround* devices in Alsa since the 'default' device only knows about stereo and has no idea about channel ordering of the hardware. I assume since the eld contains this information, the hdmi will also have a implied pcm channel ordering? - With the patch, would passthrough of DTS-HD and Dolby True-HD also work? Although I read somewhere the HBR flag needs to be set in order to pass this losslessly, though that doesn't seems
Re: [Intel-gfx] [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver
On 11/1/11 12:36 PM, Wu Fengguang wrote: Hi Christopher, Sorry I'm just back from traveling.. No worries, I am not in any hurry, and I hope you had a great holiday! :-) On Fri, Oct 28, 2011 at 03:54:23AM +0800, Christopher White wrote: There appears to be some issues with the patch? I'm on SandyBridge and using the HD3000's HDMI. I've now tried manually merging the ELD patch (both files Wu Fengguang submitted) and compiling Kernel 3.0.4. I've also tried drm-intel-next Kernel 3.1 pre-built from http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-next/current/ as I knew it was built from keithp's latest drm-intel-next repository. Both of these methods had the patch applied, yet neither were able to read the ELD correctly from my Onkyo TX-SR607 receiver. If I manually dump the EDID from my receiver and analyze it with Monitor Asset Manager (by EnTech Taiwan), it shows that the ELD contains an 8 channel specification up to 192 kHz, and that's what's being exposed over HDMI to the Intel graphics adapter, yet this isn't detected. It just plain isn't being read, and is falling back to the default 2ch 16kHz configuration. It's exactly as it was in the past, before this patch attempt. You can see my 256 byte EDID dump, straight from the receiver, over at: http://www.pulseforce.com/node/edid.dump It shows exactly what the receiver is exposing over HDMI, proving that it's not the device that's at fault. Any ideas what's wrong? Here's the HDMI messages from the startup log: Would you boot the kernel with drm.debug=6 and post the dmesg? That will show more details. One possible problem is the hardware reports small ELD buffer size which truncates the additional 8-channel information. Thanks, Fengguang Done. Sorry for the delay, didn't see your message until now, and also had to re-build the kernel. The log does confirm that the drm_edid_to_eld function is running, and that we're not far from a solution: [ 21.061417] [drm:drm_edid_to_eld], ELD monitor TX-SR607 [ 21.061421] [drm:drm_edid_to_eld], ELD size 13, SAD count 8 As for where I am getting the EDID dump from, I am getting it from /sys/devices/pci:00/:00:02.0/drm/card0/card0-HDMI-A-2/edid, which provides direct virtual access to the EDID response of the connected device. I'm completely confident that the device doesn't report too small of a buffer size, and that it's completely compliant with the spec: If you have a Windows virtual machine (or if you're masochistic enough - a real machine) you should download the excellent, free Monitor Asset Manager by EnTech Taiwan from http://www.entechtaiwan.com/util/moninfo.shtm. It will let you analyze EDID + ELD + extended timings, etc from an EDID dump, such as the one taken above. It understands every part of EDID. I've put together a small archive containing my exact EDID binary dump (taken from the above device path), the FULL dmesg log, as well as EnTech's interpretation of the EDID dump, showing the full list of supported channels, formats, etc. I'm guessing there is some tiny bug in your interpretation of how to read ELD, maybe an incorrect 1 byte offset or something like that. Here's the pack: http://www.pulseforce.com/node/edid_to_eld.zip If you do a hex analysis of my EDID dump and compare it to what the edid_to_eld function is trying to do, it will probably show what's wrong. I'd love to have a look at that myself but am really busy with a project over here so I can't help out other than to recompile and test as fast as I can. Christopher HDMI status: Pin=7 Presence_Detect=1 ELD_Valid=1 HDMI: detected monitor at connection type HDMI HDMI: available speakers: FL/FR HDMI: supports coding type LPCM: channels = 2, rates = 44100 48000 88200, bits = 16 HDMI hot plug event: Pin=7 Presence_Detect=1 ELD_Valid=1 HDMI status: Pin=7 Presence_Detect=1 ELD_Valid=1 input: HDA Intel PCH HDMI/DP as /devices/pci:00/:00:1b.0/sound/card0/input9 HDMI: detected monitor at connection type HDMI HDMI: available speakers: FL/FR HDMI: supports coding type LPCM: channels = 2, rates = 44100 48000 88200, bits = 16 HDMI hot plug event: Pin=7 Presence_Detect=1 ELD_Valid=1 HDMI status: Pin=7 Presence_Detect=1 ELD_Valid=1 HDMI: detected monitor at connection type HDMI HDMI: available speakers: FL/FR HDMI: supports coding type LPCM: channels = 2, rates = 44100 48000 88200, bits = 16 Christopher White ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver
Hi Christopher, The log does confirm that the drm_edid_to_eld function is running, and that we're not far from a solution: [ 21.061417] [drm:drm_edid_to_eld], ELD monitor TX-SR607 [ 21.061421] [drm:drm_edid_to_eld], ELD size 13, SAD count 8 It looks all sane to this point. As for where I am getting the EDID dump from, I am getting it from /sys/devices/pci:00/:00:02.0/drm/card0/card0-HDMI-A-2/edid, which provides direct virtual access to the EDID response of the connected device. I'm completely confident that the device doesn't report too small of a buffer size, and that it's completely compliant with the spec: If you Agreed. have a Windows virtual machine (or if you're masochistic enough - a real machine) you should download the excellent, free Monitor Asset Manager by EnTech Taiwan from http://www.entechtaiwan.com/util/moninfo.shtm. It will let you analyze EDID + ELD + extended timings, etc from an EDID dump, such as the one taken above. It understands every part of EDID. I've put together a small archive containing my exact EDID binary dump (taken from the above device path), the FULL dmesg log, as well as EnTech's interpretation of the EDID dump, showing the full list of supported channels, formats, etc. I'm guessing there is some tiny bug in your interpretation of how to read ELD, maybe an incorrect 1 byte offset or something like that. Here's the pack: http://www.pulseforce.com/node/edid_to_eld.zip Thanks! It's great tool and information! If you do a hex analysis of my EDID dump and compare it to what the edid_to_eld function is trying to do, it will probably show what's wrong. I'd love to have a look at that myself but am really busy with a project over here so I can't help out other than to recompile and test as fast as I can. Would you install the intel-gpu-tools package and run its intel_audio_dump utility? If not shipped with your distribution, the source code is also available in git://anongit.freedesktop.org/git/xorg/app/intel-gpu-tools You'll need to install packages autotools-dev pkg-config libpciaccess-dev libdrm-dev libdrm-intel1 in order to build it from source. intel_audio_dump will dump the ELD data in the hardware buffer for use by the audio driver. By verifying if that data is correct, we are able to analyze whether and how the audio driver goes wrong. Thanks, Fengguang ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver
There appears to be some issues with the patch? I'm on SandyBridge and using the HD3000's HDMI. I've now tried manually merging the ELD patch (both files Wu Fengguang submitted) and compiling Kernel 3.0.4. I've also tried drm-intel-next Kernel 3.1 pre-built from http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-next/current/ as I knew it was built from keithp's latest drm-intel-next repository. Both of these methods had the patch applied, yet neither were able to read the ELD correctly from my Onkyo TX-SR607 receiver. If I manually dump the EDID from my receiver and analyze it with Monitor Asset Manager (by EnTech Taiwan), it shows that the ELD contains an 8 channel specification up to 192 kHz, and that's what's being exposed over HDMI to the Intel graphics adapter, yet this isn't detected. It just plain isn't being read, and is falling back to the default 2ch 16kHz configuration. It's exactly as it was in the past, before this patch attempt. You can see my 256 byte EDID dump, straight from the receiver, over at: http://www.pulseforce.com/node/edid.dump It shows exactly what the receiver is exposing over HDMI, proving that it's not the device that's at fault. Any ideas what's wrong? Here's the HDMI messages from the startup log: HDMI status: Pin=7 Presence_Detect=1 ELD_Valid=1 HDMI: detected monitor at connection type HDMI HDMI: available speakers: FL/FR HDMI: supports coding type LPCM: channels = 2, rates = 44100 48000 88200, bits = 16 HDMI hot plug event: Pin=7 Presence_Detect=1 ELD_Valid=1 HDMI status: Pin=7 Presence_Detect=1 ELD_Valid=1 input: HDA Intel PCH HDMI/DP as /devices/pci:00/:00:1b.0/sound/card0/input9 HDMI: detected monitor at connection type HDMI HDMI: available speakers: FL/FR HDMI: supports coding type LPCM: channels = 2, rates = 44100 48000 88200, bits = 16 HDMI hot plug event: Pin=7 Presence_Detect=1 ELD_Valid=1 HDMI status: Pin=7 Presence_Detect=1 ELD_Valid=1 HDMI: detected monitor at connection type HDMI HDMI: available speakers: FL/FR HDMI: supports coding type LPCM: channels = 2, rates = 44100 48000 88200, bits = 16 Christopher White ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver
On Mon, 5 Sep 2011 09:14:00 +0800, Wu Fengguang fengguang...@intel.com wrote: On Sun, Sep 04, 2011 at 08:08:37PM +0800, Chris Wilson wrote: On Sun, 4 Sep 2011 05:15:10 +0800, Wu Fengguang fengguang...@intel.com wrote: This patch should be split between adding the core drm functionality to build the ELD and the introduction of i915 support. OK. I didn't do this because I was not sure if it's OK to just add the drm_*() functions without any code to call them.. Right, we don't introduce new interfaces without users - but it is acceptable to say ... which will be used by i915 in a following patch if you want to clarify the need for the interface. It just helps to compartmentalize the damage should we find something goes horribly wrong later. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver
On Mon, Sep 05, 2011 at 07:04:50PM +0800, Chris Wilson wrote: On Mon, 5 Sep 2011 09:14:00 +0800, Wu Fengguang fengguang...@intel.com wrote: On Sun, Sep 04, 2011 at 08:08:37PM +0800, Chris Wilson wrote: On Sun, 4 Sep 2011 05:15:10 +0800, Wu Fengguang fengguang...@intel.com wrote: This patch should be split between adding the core drm functionality to build the ELD and the introduction of i915 support. OK. I didn't do this because I was not sure if it's OK to just add the drm_*() functions without any code to call them.. Right, we don't introduce new interfaces without users - but it is acceptable to say ... which will be used by i915 in a following patch if you want to clarify the need for the interface. It just helps to compartmentalize the damage should we find something goes horribly wrong later. Sounds pretty reasonable. And the logical split may help make a bit easier to review :) Fengguang ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver
WF == Wu Fengguang fengguang...@intel.com writes: WF ... If only the stereo playback capability is reported, the user WF won't be able to start 8-channel playback; if the 8-channel ELD is WF reported, then user space applications may send 8-channel samples WF down, however the user may actually be listening to the 2-channel WF monitor and not connecting speakers to the 8-channel monitor. WF Overall, it's more safe to report maximum profiles to the user WF space, so that the user can at least be able to do 8-channel WF playback if he want to. Be aware that many TVs will either refuse the display anything or pop-up an OSD warning whenever they receive hdmi audio which they cannot handle. Sending 8-channel in your example may render the stereo-only monitor useless. That said, one step at a time is reasonable. But eventually you will require configurability and/or per-monitor audio control even when the video is cloned. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver
Dear Wu,
I hope that is your first name.
Am Sonntag, den 04.09.2011, 05:15 +0800 schrieb Wu Fengguang:
Changes from v4: remove a debug call to dump_stack().
Thanks to Bossart for catching this!
His first name is Pierre-Louis. I do not know how you address people at
Intel though.
---
I think your format will confuse `git am`. Please always put that under
the »---« under the Signed-off-by lines.
Add ELD support for Intel Eaglelake, IbexPeak/Ironlake,
SandyBridge/CougarPoint and IvyBridge/PantherPoint chips.
ELD (EDID-Like Data) describes to the HDMI/DP audio driver the audio
capabilities of the plugged monitor. It's built and passed to audio
driver in 2 steps:
(1) at get_modes time, parse EDID and save ELD to drm_connector.eld[]
(2) at mode_set time, write drm_connector.eld[] to the Transcoder's hw
ELD buffer and set the ELD_valid bit to inform HDMI/DP audio driver
ELD selection policy: it's possible for one encoder to be associated
with multiple connectors (ie. monitors), in which case the first found
ELD will be used. This policy may not be suitable for all users, but
let's start it simple first.
The impact of ELD selection policy: assume there are two monitors, one
supports stereo playback and the other has 8-channel output; cloned
display mode is used, so that the two monitors are associated with the
same internal encoder. If only the stereo playback capability is reported,
the user won't be able to start 8-channel playback; if the 8-channel ELD
is reported, then user space applications may send 8-channel samples
down, however the user may actually be listening to the 2-channel
monitor and not connecting speakers to the 8-channel monitor. Overall,
it's more safe to report maximum profiles to the user space, so that
the user can at least be able to do 8-channel playback if he want to.
s'he's/he'
This patch is tested OK on G45/HDMI, IbexPeak/HDMI and IvyBridge/HDMI+DP.
What is the correct way to test this patch. Just plug in the HDMI
monitor and it should work out of the box?
Minor imperfection: the GEN6_AUD_CNTL_ST/DIP_Port_Select field always
reads 0 (reserved). Without knowing the port number, I worked it around
by setting the ELD_valid bit for ALL the three ports. It's tested to not
be a problem, because the audio driver will find invalid ELD data and
hence rightfully abort, even when it sees the ELD_valid indicator.
Thanks to Zhenyu and Bossart for a lot of valuable help and testing.
Again the first name is Pierre-Louis or put Mr in front of it.
CC: Zhao Yakui yakui.z...@intel.com
CC: Wang Zhenyu zhenyu.z.w...@intel.com
CC: Jeremy Bush contractfrombe...@gmail.com
CC: Christopher White c.wh...@pulseforce.com
CC: Bossart, Pierre-louis pierre-louis.boss...@intel.com
Pierre-Louis Bossart
Signed-off-by: Ben Skeggs bske...@redhat.com
Signed-off-by: Wu Fengguang fengguang...@intel.com
---
drivers/gpu/drm/drm_edid.c | 171 +
drivers/gpu/drm/i915/i915_drv.h |2
drivers/gpu/drm/i915/i915_reg.h | 25 +++
drivers/gpu/drm/i915/intel_display.c | 131 +++
drivers/gpu/drm/i915/intel_dp.c |6
drivers/gpu/drm/i915/intel_drv.h |2
drivers/gpu/drm/i915/intel_hdmi.c|3
drivers/gpu/drm/i915/intel_modes.c |2
include/drm/drm_crtc.h |9 +
include/drm/drm_edid.h |9 +
10 files changed, 358 insertions(+), 2 deletions(-)
Some more style things follow.
[…]
+/**
+ * drm_av_sync_delay - HDMI/DP sink audio-video sync delay in milli-seconds
+ * @connector: connector associated with the HDMI/DP sink
+ * @mode: the display mode
+ */
+int drm_av_sync_delay(struct drm_connector *connector,
+ struct drm_display_mode *mode)
+{
+ int i = !!(mode-flags DRM_MODE_FLAG_INTERLACE);
+ int a, v;
+
+ if (!connector-latency_present[0])
+ return 0;
+ if (!connector-latency_present[1])
+ i = 0;
+
+ a = connector-audio_latency[i];
+ v = connector-video_latency[i];
+
+ /*
+ * HDMI/DP sink doesn't support audio or video?
+ */
+ if (a == 255 || v == 255)
+ return 0;
+
+ /*
+ * Convert raw edid values to milli-seconds.
s/edid/EDID/ (nitpick)
s/milli-seconds/millisecond/
http://www.merriam-webster.com/dictionary/millisecond
+ * Treat unknown latency as 0ms.
+ */
+ if (a)
+ a = min(2 * (a - 1), 500);
+ if (v)
+ v = min(2 * (v - 1), 500);
+
+ return max(v - a, 0);
+}
+EXPORT_SYMBOL(drm_av_sync_delay);
[…]
--- linux-next.orig/drivers/gpu/drm/i915/i915_reg.h 2011-09-02
15:59:31.0 +0800
+++ linux-next/drivers/gpu/drm/i915/i915_reg.h2011-09-02
15:59:40.0 +0800
@@ -3470,4 +3470,29 @@
#define GEN6_PCODE_DATA 0x138128
#define GEN6_PCODE_FREQ_IA_RATIO_SHIFT 8
+#define
Re: [Intel-gfx] [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver
On Sun, 4 Sep 2011 05:15:10 +0800, Wu Fengguang fengguang...@intel.com wrote:
Changes from v4: remove a debug call to dump_stack().
Thanks to Bossart for catching this!
---
Add ELD support for Intel Eaglelake, IbexPeak/Ironlake,
SandyBridge/CougarPoint and IvyBridge/PantherPoint chips.
ELD (EDID-Like Data) describes to the HDMI/DP audio driver the audio
capabilities of the plugged monitor. It's built and passed to audio
driver in 2 steps:
(1) at get_modes time, parse EDID and save ELD to drm_connector.eld[]
(2) at mode_set time, write drm_connector.eld[] to the Transcoder's hw
ELD buffer and set the ELD_valid bit to inform HDMI/DP audio driver
ELD selection policy: it's possible for one encoder to be associated
with multiple connectors (ie. monitors), in which case the first found
ELD will be used. This policy may not be suitable for all users, but
let's start it simple first.
The impact of ELD selection policy: assume there are two monitors, one
supports stereo playback and the other has 8-channel output; cloned
display mode is used, so that the two monitors are associated with the
same internal encoder. If only the stereo playback capability is reported,
the user won't be able to start 8-channel playback; if the 8-channel ELD
is reported, then user space applications may send 8-channel samples
down, however the user may actually be listening to the 2-channel
monitor and not connecting speakers to the 8-channel monitor. Overall,
it's more safe to report maximum profiles to the user space, so that
the user can at least be able to do 8-channel playback if he want to.
This patch is tested OK on G45/HDMI, IbexPeak/HDMI and IvyBridge/HDMI+DP.
Minor imperfection: the GEN6_AUD_CNTL_ST/DIP_Port_Select field always
reads 0 (reserved). Without knowing the port number, I worked it around
by setting the ELD_valid bit for ALL the three ports. It's tested to not
be a problem, because the audio driver will find invalid ELD data and
hence rightfully abort, even when it sees the ELD_valid indicator.
--- linux-next.orig/drivers/gpu/drm/i915/intel_display.c 2011-09-02
15:59:31.0 +0800
+++ linux-next/drivers/gpu/drm/i915/intel_display.c 2011-09-04
05:11:44.0 +0800
+static void ironlake_write_eld(struct drm_connector *connector,
+ struct drm_crtc *crtc)
+{
+ struct drm_i915_private *dev_priv = connector-dev-dev_private;
+ uint8_t *eld = connector-eld;
+ uint32_t eldv;
+ uint32_t i;
+ int len;
+ int hdmiw_hdmiedid;
+ int aud_cntl_st;
+ int aud_cntrl_st2;
+
+ if (IS_IVYBRIDGE(connector-dev)) {
+ hdmiw_hdmiedid = GEN7_HDMIW_HDMIEDID_A;
+ aud_cntl_st = GEN7_AUD_CNTRL_ST_A;
+ aud_cntrl_st2 = GEN7_AUD_CNTRL_ST2;
+ } else {
+ hdmiw_hdmiedid = GEN6_HDMIW_HDMIEDID_A;
+ aud_cntl_st = GEN6_AUD_CNTL_ST_A;
+ aud_cntrl_st2 = GEN6_AUD_CNTL_ST2;
+ }
This register naming is inconsistent with its intent. If these registers
were indeed introduced on Ironlake as you seem to imply by using them
with Ironlake, you should label them as GEN5 and not GEN6.
This patch should be split between adding the core drm functionality to
build the ELD and the introduction of i915 support.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver
Dear Paul,
On Sun, Sep 04, 2011 at 07:11:54PM +0800, Paul Menzel wrote:
Dear Wu,
I hope that is your first name.
My first name is Fengguang. LAST NAME, FIRSTNAME is the convention
in Intel emails. However I often forgot this and pick whatever comes
first...and happily accept both Fengguang and Wu :)
Am Sonntag, den 04.09.2011, 05:15 +0800 schrieb Wu Fengguang:
Changes from v4: remove a debug call to dump_stack().
Thanks to Bossart for catching this!
His first name is Pierre-Louis. I do not know how you address people at
Intel though.
Thanks for the reminding!
---
I think your format will confuse `git am`. Please always put that under
the »---« under the Signed-off-by lines.
OK, good point!
Add ELD support for Intel Eaglelake, IbexPeak/Ironlake,
SandyBridge/CougarPoint and IvyBridge/PantherPoint chips.
ELD (EDID-Like Data) describes to the HDMI/DP audio driver the audio
capabilities of the plugged monitor. It's built and passed to audio
driver in 2 steps:
(1) at get_modes time, parse EDID and save ELD to drm_connector.eld[]
(2) at mode_set time, write drm_connector.eld[] to the Transcoder's hw
ELD buffer and set the ELD_valid bit to inform HDMI/DP audio driver
ELD selection policy: it's possible for one encoder to be associated
with multiple connectors (ie. monitors), in which case the first found
ELD will be used. This policy may not be suitable for all users, but
let's start it simple first.
The impact of ELD selection policy: assume there are two monitors, one
supports stereo playback and the other has 8-channel output; cloned
display mode is used, so that the two monitors are associated with the
same internal encoder. If only the stereo playback capability is reported,
the user won't be able to start 8-channel playback; if the 8-channel ELD
is reported, then user space applications may send 8-channel samples
down, however the user may actually be listening to the 2-channel
monitor and not connecting speakers to the 8-channel monitor. Overall,
it's more safe to report maximum profiles to the user space, so that
the user can at least be able to do 8-channel playback if he want to.
s'he's/he'
Fixed.
This patch is tested OK on G45/HDMI, IbexPeak/HDMI and IvyBridge/HDMI+DP.
What is the correct way to test this patch. Just plug in the HDMI
monitor and it should work out of the box?
Just plug in the HDMI/DP monitor, and run
cat /proc/asound/card0/eld*
to check if the monitor name, HDMI/DP type, etc. show up correctly.
Minor imperfection: the GEN6_AUD_CNTL_ST/DIP_Port_Select field always
reads 0 (reserved). Without knowing the port number, I worked it around
by setting the ELD_valid bit for ALL the three ports. It's tested to not
be a problem, because the audio driver will find invalid ELD data and
hence rightfully abort, even when it sees the ELD_valid indicator.
Thanks to Zhenyu and Bossart for a lot of valuable help and testing.
Again the first name is Pierre-Louis or put Mr in front of it.
Got it, so the convention is either Pierre-Louis, or Mr. Bossart.
CC: Zhao Yakui yakui.z...@intel.com
CC: Wang Zhenyu zhenyu.z.w...@intel.com
CC: Jeremy Bush contractfrombe...@gmail.com
CC: Christopher White c.wh...@pulseforce.com
CC: Bossart, Pierre-louis pierre-louis.boss...@intel.com
Pierre-Louis Bossart
Corrected.
Signed-off-by: Ben Skeggs bske...@redhat.com
Signed-off-by: Wu Fengguang fengguang...@intel.com
---
drivers/gpu/drm/drm_edid.c | 171 +
drivers/gpu/drm/i915/i915_drv.h |2
drivers/gpu/drm/i915/i915_reg.h | 25 +++
drivers/gpu/drm/i915/intel_display.c | 131 +++
drivers/gpu/drm/i915/intel_dp.c |6
drivers/gpu/drm/i915/intel_drv.h |2
drivers/gpu/drm/i915/intel_hdmi.c|3
drivers/gpu/drm/i915/intel_modes.c |2
include/drm/drm_crtc.h |9 +
include/drm/drm_edid.h |9 +
10 files changed, 358 insertions(+), 2 deletions(-)
Some more style things follow.
[…]
+/**
+ * drm_av_sync_delay - HDMI/DP sink audio-video sync delay in milli-seconds
+ * @connector: connector associated with the HDMI/DP sink
+ * @mode: the display mode
+ */
+int drm_av_sync_delay(struct drm_connector *connector,
+ struct drm_display_mode *mode)
+{
+ int i = !!(mode-flags DRM_MODE_FLAG_INTERLACE);
+ int a, v;
+
+ if (!connector-latency_present[0])
+ return 0;
+ if (!connector-latency_present[1])
+ i = 0;
+
+ a = connector-audio_latency[i];
+ v = connector-video_latency[i];
+
+ /*
+* HDMI/DP sink doesn't support audio or video?
+*/
+ if (a == 255 || v == 255)
+ return 0;
+
+ /*
+* Convert raw edid values to milli-seconds.
s/edid/EDID/ (nitpick)
s/milli-seconds/millisecond/
Fixed.
Re: [Intel-gfx] [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver
On Sun, Sep 04, 2011 at 08:08:37PM +0800, Chris Wilson wrote:
On Sun, 4 Sep 2011 05:15:10 +0800, Wu Fengguang fengguang...@intel.com
wrote:
Changes from v4: remove a debug call to dump_stack().
Thanks to Bossart for catching this!
---
Add ELD support for Intel Eaglelake, IbexPeak/Ironlake,
SandyBridge/CougarPoint and IvyBridge/PantherPoint chips.
ELD (EDID-Like Data) describes to the HDMI/DP audio driver the audio
capabilities of the plugged monitor. It's built and passed to audio
driver in 2 steps:
(1) at get_modes time, parse EDID and save ELD to drm_connector.eld[]
(2) at mode_set time, write drm_connector.eld[] to the Transcoder's hw
ELD buffer and set the ELD_valid bit to inform HDMI/DP audio driver
ELD selection policy: it's possible for one encoder to be associated
with multiple connectors (ie. monitors), in which case the first found
ELD will be used. This policy may not be suitable for all users, but
let's start it simple first.
The impact of ELD selection policy: assume there are two monitors, one
supports stereo playback and the other has 8-channel output; cloned
display mode is used, so that the two monitors are associated with the
same internal encoder. If only the stereo playback capability is reported,
the user won't be able to start 8-channel playback; if the 8-channel ELD
is reported, then user space applications may send 8-channel samples
down, however the user may actually be listening to the 2-channel
monitor and not connecting speakers to the 8-channel monitor. Overall,
it's more safe to report maximum profiles to the user space, so that
the user can at least be able to do 8-channel playback if he want to.
This patch is tested OK on G45/HDMI, IbexPeak/HDMI and IvyBridge/HDMI+DP.
Minor imperfection: the GEN6_AUD_CNTL_ST/DIP_Port_Select field always
reads 0 (reserved). Without knowing the port number, I worked it around
by setting the ELD_valid bit for ALL the three ports. It's tested to not
be a problem, because the audio driver will find invalid ELD data and
hence rightfully abort, even when it sees the ELD_valid indicator.
--- linux-next.orig/drivers/gpu/drm/i915/intel_display.c2011-09-02
15:59:31.0 +0800
+++ linux-next/drivers/gpu/drm/i915/intel_display.c 2011-09-04
05:11:44.0 +0800
+static void ironlake_write_eld(struct drm_connector *connector,
+struct drm_crtc *crtc)
+{
+ struct drm_i915_private *dev_priv = connector-dev-dev_private;
+ uint8_t *eld = connector-eld;
+ uint32_t eldv;
+ uint32_t i;
+ int len;
+ int hdmiw_hdmiedid;
+ int aud_cntl_st;
+ int aud_cntrl_st2;
+
+ if (IS_IVYBRIDGE(connector-dev)) {
+ hdmiw_hdmiedid = GEN7_HDMIW_HDMIEDID_A;
+ aud_cntl_st = GEN7_AUD_CNTRL_ST_A;
+ aud_cntrl_st2 = GEN7_AUD_CNTRL_ST2;
+ } else {
+ hdmiw_hdmiedid = GEN6_HDMIW_HDMIEDID_A;
+ aud_cntl_st = GEN6_AUD_CNTL_ST_A;
+ aud_cntrl_st2 = GEN6_AUD_CNTL_ST2;
+ }
This register naming is inconsistent with its intent. If these registers
were indeed introduced on Ironlake as you seem to imply by using them
with Ironlake, you should label them as GEN5 and not GEN6.
Yeah, I admit that I'm a bit confused in choosing the exact names.
I'll fix that.
This patch should be split between adding the core drm functionality to
build the ELD and the introduction of i915 support.
OK. I didn't do this because I was not sure if it's OK to just add the
drm_*() functions without any code to call them..
Thanks,
Fengguang
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver
On Sun, Sep 04, 2011 at 06:57:23PM +0800, James Cloos wrote: WF == Wu Fengguang fengguang...@intel.com writes: WF ... If only the stereo playback capability is reported, the user WF won't be able to start 8-channel playback; if the 8-channel ELD is WF reported, then user space applications may send 8-channel samples WF down, however the user may actually be listening to the 2-channel WF monitor and not connecting speakers to the 8-channel monitor. WF Overall, it's more safe to report maximum profiles to the user WF space, so that the user can at least be able to do 8-channel WF playback if he want to. Be aware that many TVs will either refuse the display anything or pop-up an OSD warning whenever they receive hdmi audio which they cannot handle. OK, good to know that. Sending 8-channel in your example may render the stereo-only monitor useless. Yes. That said, one step at a time is reasonable. But eventually you will require configurability and/or per-monitor audio control even when the video is cloned. Fair enough. Thanks, Fengguang ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
