[alsa-devel] [PATCH 2/2] ALSA: hda - get realtime ELD info when codec suspended

[Takashi Iwai]

At Mon, 24 Jun 2013 14:47:01 +0200,
David Henningsson wrote:
> 
> On 06/24/2013 02:00 PM, Takashi Iwai wrote:
> > At Mon, 24 Jun 2013 11:56:21 +0000,
> > Wang, Xingchao wrote:
> >>
> >>> -----Original Message-----
> >>> From: Takashi Iwai [mailto:tiwai at suse.de]
> >>> Sent: Monday, June 24, 2013 7:36 PM
> >>> To: Wang Xingchao
> >>> Cc: alsa-devel at alsa-project.org; Wang, Xingchao
> >>> Subject: Re: [PATCH 2/2] ALSA: hda - get realtime ELD info when codec
> >>> suspended
> >>>
> >>> At Mon, 24 Jun 2013 07:45:24 -0400,
> >>> Wang Xingchao wrote:
> >>>>
> >>>> when controller/codec in runtime suspended mode, monitor hotplug would
> >>>> not trigger unsolicited event.
> 
> And here's the original problem IMO: If you can't detect plug/unplug in 
> runtime suspend mode, the runtime suspend mode is broken. Userspace 
> relies on getting notification when a HDMI/DP connection is 
> plugged/unplugged. If no unsol event is triggered, how is userspace 
> notified?

It can't, so far.  The same thing happens for any other jack
detections when the power-saving is turned on.

There is a low power mode that allows the jack detection, but this is
different from the aggressive power-saving with runtime D3.

In theory, the audio driver can be resumed forcibly before unsolicited
event is sent, once if we have a layer controlling the power of both
graphics and audio devices.  This is the thing to be done in future,
together with the runtime PM control of the graphics side.


> This patch tries to power up codec and
> >>>> hdmi driver would probe ELD info again.
> >>>
> >>> I don't know whether this is the wanted behavior.
> >>> The proc file is supposed to read the driver's status, not to trigger anything.
> >>>
> >>
> >> I explained in another mail what the patch fix. In the real case, when HDMI monitor removed,
> >> Eld# still hold monitor information because the codec/controller is in suspend mode atm and has no chance to refresh eld.
> >
> > And this is no bug, per se.  The proc file shows the driver's current
> > status, not the hardware's raw status.
> 
> Well, the codec proc file shows the hardware's raw status (which 
> includes powering up the codec), perhaps it would be more consistent if 
> the eld proc file did the same?

Well, the concept is different.

The codec proc file shows the codec raw status, so it is.
The eld proc file shows the content of the data the driver currently
contains.  It's good so for debugging purpose; otherwise the driver
status would change just by reading this proc file.

> >> Even when controller/codec waken up, it will not refresh eld# as gfx side hand
> > led hdmi hotplut when audio driver suspended.
> >
> > ... and this is actually the bug.
> > But, it's still unclear why the jack detection callback isn't called
> > at resume.
> 
> Well, I haven't double checked, but is there anyone actually calling it? 
> Just setting a jack to dirty does not cause any action in itself.

The culprit was found, see my previous reply.

> And btw, even if the proc file might show old information, we also have 
> the ELD bytes ctrl, which IMO should always correctly return 0 if 
> there's nothing connected.

Right.


thanks,

Takashi