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@xxxxxxxxxxxxxxx wrote: > >>>>> > >>>>> From: Libin Yang <libin.yang@xxxxxxxxx> > >>>>> > >>>>> 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@xxxxxxxxxxxxxxx> > >>>> > >>>> 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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
