[Intel-gfx] [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver

[Takashi Iwai]

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