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.
Takashi