From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: DP1.2 MST audio support discussion Date: Tue, 13 Oct 2015 11:20:33 +0200 Message-ID: References: <96A12704CE18D347B625EE2D4A099D1974C250@SHSMSX103.ccr.corp.intel.com> <561CA911.7070405@canonical.com> <96A12704CE18D347B625EE2D4A099D1974C304@SHSMSX103.ccr.corp.intel.com> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by alsa0.perex.cz (Postfix) with ESMTP id DAE6F261A96 for ; Tue, 13 Oct 2015 11:20:34 +0200 (CEST) In-Reply-To: <96A12704CE18D347B625EE2D4A099D1974C304@SHSMSX103.ccr.corp.intel.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: alsa-devel-bounces@alsa-project.org To: "Yang, Libin" Cc: "alsa-devel@alsa-project.org" , "airlied@linux.ie" , "Lin, Mengdong" , "Girdwood, Liam R" , "tanuk@iki.fi" , David Henningsson List-Id: alsa-devel@alsa-project.org On Tue, 13 Oct 2015 09:34:49 +0200, Yang, Libin 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. Takashi