Alsa-Devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Takashi Iwai <tiwai@suse.de>
Cc: "Lu, Han" <han.lu@intel.com>,
	alsa-devel@alsa-project.org,
	"intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>,
	"Girdwood, Liam R" <liam.r.girdwood@intel.com>
Subject: Re: [PATCH 3/4] snd: add support for displayport multi-stream to hda codec.
Date: Mon, 22 Jun 2015 14:54:29 +0200	[thread overview]
Message-ID: <20150622125429.GW25769@phenom.ffwll.local> (raw)
In-Reply-To: <s5hpp4s9ceq.wl-tiwai@suse.de>

On Fri, Jun 19, 2015 at 01:15:57PM +0200, Takashi Iwai wrote:
> At Fri, 19 Jun 2015 20:33:39 +1000,
> Dave Airlie wrote:
> > 
> > On 19 June 2015 at 19:54, Lin, Mengdong <mengdong.lin@intel.com> wrote:
> > > Hi Takashi/Dave,
> > >
> > > Shall we move or cc this discussion on audio driver side to ALSA ML?
> > 
> > Oops I thought I had cc'ed these patches to alsa-devel as well when I sent them.
> > 
> > > I think we also need to decide how to manage PCM devices for DP MST.
> > > Now the HD-A driver create a PCM device for each pin, and the substream
> > > number is 1 for each PCM. Now with DP MST enabled, each pin can support
> > > multiple streams (e.g. 3 on Intel HSW/BDW/SKL).
> > >
> > > There may be 2 options:
> > > -#1: Let an HDMI codec specify number of substreams, same as the number
> > > of device entries on a pin. We can specify 3 for HSW/BDW/SKL. Other
> > > vendors can also specify a value according to actual HW capabilities.
> > >
> > > So for HSW, we have 3x3 subtreams totally. But we only have 3 convertors
> > > (for 3 display pipelines), so we can open up to 3 substreams at the same
> > > time. When the audio driver finds all 3 convertors are used when opening
> > > a new substream, it will fail.
> > 
> > One thing I noticed is the number of devices on a PIN is only updated when
> > the MST device is plugged in so normally pins 5,6,7 have 0 devices, and when
> > I plug in MST device, I get the 3 devices on port 6. So it seems dynamic
> > enough at this point, though I guess it'll always be 0 or 3.
> > >
> > > - #2: Create PCM device dynamically. Only create a PCM devices for a device
> > > entry which connects to monitor with audio support. When the monitor
> > > is removed, the PCM device will be disconnected, closed and removed,
> > > similar to the USB case.
> > >
> > > This will change ALSA core. But there will be less PCM devices and
> > > substreams, since the number of connected monitors Is decided by the
> > > actual GPU display pipeline.
> > 
> > I like this option more, since I think it should be more like USB, but I've
> > no idea how much work it would be from the alsa side, this patch was
> > probably as deep into alsa as I've gone.
> 
> Two things have to be considered for compatibility:
> - ELD, channel map and jack detection: these are created per PCM
>   device, and extending to substream would confuse user space a lot.
>   In theory, it can be extended using subdevice number, but in anyway
>   this won't work with PulseAudio as is.
> 
> - The per-pin assignment provides a more or less persistent route to a
>   certain device.  Changing the assignment method may break the
>   previous setup.
> 
> Also, the dynamic PCM creation / removal is an issue that has been
> discussed many times.  Unfortunately it won't work as is, at lest for
> PA.  Currently PA does probing of devices only at the card probe time.
> The hotplug of USB-audio works because it's always tied with the
> card.  But in this case, the card remains while only the PCM devices
> will be created / removed, thus the probe in PA won't be triggered.

I guess that means we either have to hotplug entire (fake) cards or fix up
userspace to support mst audio properly? We had to do some minimal changes
to the ddx drivers too to make sure they're rescanning the connector list
properly. Imo since this is all new I think we could require PA to rescan
the PCM dev list on hotplug events too to support DP MST. And we kinda do
need hotplug at that level since if we'd hotplug the entire card we'd kill
a stream that's running on some other display.

And always registering all of them feels like a very bad hack too.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2015-06-22 12:54 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1434513719-3580-1-git-send-email-airlied@gmail.com>
     [not found] ` <1434513719-3580-4-git-send-email-airlied@gmail.com>
     [not found]   ` <F46914AEC2663F4A9BB62374E5EEF8F82B895171@SHSMSX101.ccr.corp.intel.com>
2015-06-19 10:33     ` [PATCH 3/4] snd: add support for displayport multi-stream to hda codec Dave Airlie
2015-06-19 11:15       ` Takashi Iwai
2015-06-22 12:54         ` Daniel Vetter [this message]
2015-06-22 13:23           ` Takashi Iwai
2015-06-22 13:29             ` Liam Girdwood
2015-06-22 15:21               ` Kaskinen, Tanu
2015-06-22 15:44                 ` Takashi Iwai
2015-06-23  7:51                   ` [Intel-gfx] " Kaskinen, Tanu
2015-06-23  8:06                     ` Takashi Iwai
2015-06-24 12:41                       ` [Intel-gfx] " Kaskinen, Tanu
2015-06-24 13:06                         ` [alsa-devel] " Liam Girdwood
2015-06-24 20:47                           ` Kaskinen, Tanu
2015-06-25  9:44                             ` [alsa-devel] " Liam Girdwood
2015-06-26 10:14                               ` [alsa-devel] [Intel-gfx] " Kaskinen, Tanu
2015-06-26 10:50                     ` Kaskinen, Tanu
2015-06-26 18:45                       ` Liam Girdwood
2015-06-26 16:27                   ` [Intel-gfx] " Kaskinen, Tanu
2015-06-27  6:09         ` [alsa-devel] " Raymond Yau
2015-06-29  8:00           ` Jani Nikula
2015-07-03  3:45             ` Raymond Yau
2015-07-03  8:54               ` Jani Nikula
2015-06-25  8:22       ` Raymond Yau
2015-06-25 12:52         ` David Weinehall

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=20150622125429.GW25769@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=alsa-devel@alsa-project.org \
    --cc=han.lu@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=liam.r.girdwood@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox