Re: [RFC PATCH 2/2] ALSA: hda - HDMI codec driver dynamically attach PCM

[Takashi Iwai <tiwai@suse.de>]

On Mon, 09 Nov 2015 02:38:18 +0100,
Libin Yang wrote:
> 
> Hi Takashi,
> 
> On 11/06/2015 05:12 PM, Takashi Iwai wrote:
> > On Fri, 06 Nov 2015 06:33:48 +0100,
> > Libin Yang wrote:
> >>
> >> Hi Takashi,
> >>
> >> On 11/04/2015 01:38 PM, Libin Yang wrote:
> >>> On 11/04/2015 12:44 AM, Takashi Iwai wrote:
> >>>> On Tue, 03 Nov 2015 09:22:53 +0100,
> >>>> libin.yang@linux.intel.com wrote:
> >>>>>
> >>>>> From: Libin Yang <libin.yang@intel.com>
> >>>>>
> >>>>> Allocate the PCM based on the number of pin and device entry.
> >>>>> The number of PCM is pin num plus device entry number per pin.
> >>>>> For example, on Intel platform, it will be 5 PCMs.
> >>>>>
> >>>>> Do not attach the PCM to pin in initialization.
> >>>>> Dynamically attach PCM to pin when monitor is connected
> >>>>> in HDMI audio codec driver.
> >>>>>
> >>>>> When monitor is disconnected, detach the PCM from the pin.
> >>>>> And if the audio is playing, stop the playback.
> >>>>>
> >>>>> The below is the example of device entry and PCM binding:
> >>>>> For a monitor is plugged in, we need to dynamically assign
> >>>>> this monitor to 5 PCM devices (on Intel platform):
> >>>>> For a monitor at pin nid 0x05, dev index 0, it will prefer PCM 3
> >>>>> For a monitor at pin nid 0x06, dev index 0, it will prefer PCM 7
> >>>>> For a monitor at pin nid 0x07, dev index 0, it will prefer PCM 8
> >>>>> For a monitor at dev index 1 (any pin), it will prefer PCM 9
> >>>>> For a monitor at dev index 2 (any pin), it will prefer PCM 10
> >>>>>
> >>>>> If the preferred PCM is not available, try PCM in this order:
> >>>>> 9, 10, 3, 7 ,8.
> >>>>>
> >>>>> Signed-off-by: Libin Yang <libin.yang@linux.intel.com>
> >>>>
> >>>> We should split the changes to a few patches here.  For example,
> >>>> stopping the stream at discussion is basically an implementation
> >>>> independent from the MST itself.  IOW, the dynamic attach/detach can
> >>>> be implemented and tested even without MST support.  Let's code them
> >>>> at first, then add MST support.
> >>>
> >>> This patch actually doesn't depend on MST. I use the dev_num to
> >>> determine how many PCMs to be created.
> >>>
> >>> To Split the patch, how about I create the PCM number based the pin
> >>> number in the patch?
> >>>
> >>>>
> >>>> Also, it's an open question whether we apply the dynamic attach/detach
> >>>> to all devices that use the generic hdmi framework.  It means
> >>>> including AMD and Nvidia.  You hard-coded it to be applied
> >>>> unconditionally.  Would it break anything potentially...?
> >>>
> >>> I have no other verdors platforms to test. But it seems to be OK on
> >>> other platforms. The impact is, i think, it will stop the stream when
> >>> monitor is disconnected. Should we apply the code by judging whehter
> >>> it is Intel platform?
> >>
> >> If you are concerning the impact on other vendors, what about I create
> >> a separate mst codec driver? In the driver, I will still use virtual
> >> pin, but other vendors platform will not be supported at the moment.
> >> Other vendors can add their patches to the new codec driver to support
> >> their own mst audio.
> >
> > No, it's not the option.  Such a behavior change is the big burden to
> > user-space.  We should provide consistent behavior as much as
> > possible.
> 
> OK, I see. What do you think if I judge the platform before using DP 
> MST mode?

Yes, I'd love to have more tests before doing any radical changes.

As already mentioned, basically your work has to individual changes:
the stream validation and dynamic disconnect per monitor plug/unplug,
and the MST support via dynamic PCM assignment.

The former is definitely a generic framework, and it's worth to have
even without MST support.  OTOH, the former *is* the biggest change
from user-space POV.  User won't notice much about the latter -- the
usage pattern should be almost same.  So, it's the former change we
need to test and evaluate carefully.


Takashi