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