From: Libin Yang <libin.yang@linux.intel.com>
To: Takashi Iwai <tiwai@suse.de>
Cc: Libin Yang <libin.yang@intel.com>,
alsa-devel@alsa-project.org, mengdong.lin@linux.intel.com
Subject: Re: [RFC PATCH 2/2] ALSA: hda - HDMI codec driver dynamically attach PCM
Date: Mon, 9 Nov 2015 09:38:18 +0800 [thread overview]
Message-ID: <563FF90A.3000206@linux.intel.com> (raw)
In-Reply-To: <s5hpoznlcez.wl-tiwai@suse.de>
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?
Best Regards,
Libin
>
>
> Takashi
>
next prev parent reply other threads:[~2015-11-09 1:39 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-03 8:22 [RFC PATCH 0/2] ALSA: hda - patch set for DP MST audio support libin.yang
2015-11-03 8:22 ` [RFC PATCH 1/2] ALSA: hda - add hda_dev_t typedef for DP MST audio libin.yang
2015-11-03 16:28 ` Takashi Iwai
2015-11-04 2:37 ` Libin Yang
2015-11-03 8:22 ` [RFC PATCH 2/2] ALSA: hda - HDMI codec driver dynamically attach PCM libin.yang
2015-11-03 16:44 ` Takashi Iwai
2015-11-04 5:38 ` Libin Yang
2015-11-04 7:55 ` Libin Yang
2015-11-06 5:33 ` Libin Yang
2015-11-06 9:12 ` Takashi Iwai
2015-11-09 1:38 ` Libin Yang [this message]
2015-11-09 7:55 ` Takashi Iwai
2015-11-09 8:45 ` Libin Yang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=563FF90A.3000206@linux.intel.com \
--to=libin.yang@linux.intel.com \
--cc=alsa-devel@alsa-project.org \
--cc=libin.yang@intel.com \
--cc=mengdong.lin@linux.intel.com \
--cc=tiwai@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.