From: Takashi Iwai <tiwai@suse.de>
To: Raymond Yau <superquad.vortex2@gmail.com>
Cc: "Yang, Libin" <libin.yang@intel.com>,
ALSA Development Mailing List <alsa-devel@alsa-project.org>,
"airlied@linux.ie" <airlied@linux.ie>,
"Lin, Mengdong" <mengdong.lin@intel.com>,
"Girdwood, Liam R" <liam.r.girdwood@intel.com>,
"tanuk@iki.fi" <tanuk@iki.fi>,
David Henningsson <david.henningsson@canonical.com>
Subject: Re: DP1.2 MST audio support discussion
Date: Wed, 14 Oct 2015 08:44:14 +0200 [thread overview]
Message-ID: <s5htwpuj6f5.wl-tiwai@suse.de> (raw)
In-Reply-To: <CAN8cciZJ_YJhHEoU9HovR=P7FsxiKMDQ7johrmFGEWHQK_ZYNg@mail.gmail.com>
On Wed, 14 Oct 2015 01:52:08 +0200,
Raymond Yau wrote:
>
> > >
> > > > One could then allocate two extra PCMs from the start (9 and 10) to
> > > > try
> > > > in case the other PCM is busy (my preference), or one could steal one
> > > > of
> > > > the existing non-busy ones (Takashi's preference).
> > >
> > > We will create the PCMs based on converter. This means we will
> > > create 3 PCMs. And it will not support dynamically allocating PCM.
> > > As there are only 3 converters, no more PCMs will be supported.
> > > Each PCM will use one converter. If 3 PCMs are all used, connecting
> > > monitor will not create new PCM.
> > >
> > > Yes, if we are not using the PCM, we can re-assign the PCM to another
> > > monitor. Currently, user can't decide which PCM is used for which
> > > monitor. Image the scenario PCM 3 is assigned to monitor 1, PCM 7 is
> > > assigned to monitor 2, PCM 8 is assigned to monitor 3. Monitor 4 is
> > > connected, no PCM is available, and driver don't know whether it
> > > should steal one PCM for the monitor 4 and user can't change the
> > > mapping currently.
> >
> > Actually, there are a few things to implement properly:
> >
> > 1. The plug/unplug events are triggered at the actual graphics output
> > switching via xrandr or such, not at the time the monitor is
> > physically plugged/unplugged.
> >
> > 2. At switching, the unplug event must be handled at first, and then
> > the plug event.
> >
> > 3. At unplug, detach per_pin object properly from PCM.
> > We currently just notify it via jack ctl, and doesn't care the
> > rest. Ideally, we should force to stop the PCM and detach
> > internally from the assigned pin.
> >
> > 4. At plug, assign the monitor to the free per_pin object.
> >
> > So what we've discussed is about the last step; how to map the new
> > monitor to per_pin object. This requires the other steps beforehand
> > which assures a free per_pin is present at plug time.
> >
>
> Do it mean that only one DP MST port and no HDMI port on the same graphic
> card ?
No.
> If DP MST are dasiy chained, the unplug of the first monitor from Display
> Port will cause all DP monitor in the dasiy chain disconnect
Yes.
Takashi
next prev parent reply other threads:[~2015-10-14 6:44 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-13 6:25 DP1.2 MST audio support discussion Yang, Libin
2015-10-13 6:47 ` David Henningsson
2015-10-13 7:34 ` Yang, Libin
2015-10-13 9:20 ` Takashi Iwai
2015-10-13 12:31 ` Yang, Libin
2015-10-13 14:03 ` Takashi Iwai
2015-10-13 14:12 ` Yang, Libin
2015-10-13 16:20 ` Takashi Iwai
2015-10-14 2:03 ` Yang, Libin
2015-10-13 23:52 ` Raymond Yau
2015-10-14 2:15 ` Yang, Libin
2015-10-14 6:44 ` Takashi Iwai [this message]
2015-10-16 0:32 ` Raymond Yau
2015-10-16 6:38 ` Takashi Iwai
2015-10-16 8:51 ` Yang, Libin
2015-10-16 9:00 ` Takashi Iwai
2015-10-16 11:55 ` Yang, Libin
2015-10-19 5:16 ` Yang, Libin
2015-10-22 1:31 ` Yang, Libin
2015-10-22 6:51 ` David Henningsson
2015-10-22 6:56 ` Yang, Libin
2015-10-22 7:27 ` David Henningsson
2015-10-22 7:40 ` Yang, Libin
2015-10-22 8:52 ` David Henningsson
2015-10-22 11:21 ` Yang, Libin
2015-10-22 17:42 ` Takashi Iwai
2015-10-23 5:30 ` Lin, Mengdong
2015-10-23 5:53 ` Takashi Iwai
2015-10-23 8:35 ` Lin, Mengdong
2015-10-23 8:44 ` Takashi Iwai
2015-10-23 10:15 ` Lin, Mengdong
2015-11-13 7:27 ` Raymond Yau
2015-10-23 10:55 ` David Henningsson
2015-10-23 12:35 ` Lin, Mengdong
2015-10-27 8:45 ` Yang, Libin
2015-10-30 11:27 ` Takashi Iwai
2015-11-01 8:53 ` Raymond Yau
2015-11-02 7:54 ` Yang, Libin
2015-11-02 7:30 ` Yang, Libin
2015-11-02 7:46 ` Takashi Iwai
2015-11-02 7:55 ` David Henningsson
2015-11-04 14:17 ` Yang, Libin
2015-11-04 15:04 ` Jani Nikula
2015-11-05 9:07 ` David Henningsson
2015-11-05 9:39 ` Raymond Yau
2015-11-10 6:46 ` Yang, Libin
2015-11-10 7:45 ` David Henningsson
2015-11-11 2:04 ` Yang, Libin
2015-11-11 7:58 ` Yang, Libin
2015-11-11 8:05 ` Takashi Iwai
2015-11-11 8:11 ` Yang, Libin
2015-11-11 8:26 ` Takashi Iwai
2015-11-11 8:33 ` Yang, Libin
2015-11-11 8:52 ` Takashi Iwai
2015-10-23 9:40 ` Raymond Yau
2015-10-23 13:08 ` Lin, Mengdong
2015-10-16 1:11 ` Yang, Libin
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=s5htwpuj6f5.wl-tiwai@suse.de \
--to=tiwai@suse.de \
--cc=airlied@linux.ie \
--cc=alsa-devel@alsa-project.org \
--cc=david.henningsson@canonical.com \
--cc=liam.r.girdwood@intel.com \
--cc=libin.yang@intel.com \
--cc=mengdong.lin@intel.com \
--cc=superquad.vortex2@gmail.com \
--cc=tanuk@iki.fi \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox