From mboxrd@z Thu Jan 1 00:00:00 1970 From: Charles Keepax Subject: Re: [PATCH 2/4] ASoC: compress: Clarify the intent of current compressed ops handling Date: Fri, 4 May 2018 12:59:22 +0100 Message-ID: <20180504115922.GK20410@imbe.wolfsonmicro.main> References: <20180426163007.5632-1-ckeepax@opensource.cirrus.com> <20180426163007.5632-2-ckeepax@opensource.cirrus.com> <20180503162714.GX6014@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mx0b-001ae601.pphosted.com (mx0b-001ae601.pphosted.com [67.231.152.168]) by alsa0.perex.cz (Postfix) with ESMTP id B8E64267235 for ; Fri, 4 May 2018 13:59:26 +0200 (CEST) Content-Disposition: inline In-Reply-To: <20180503162714.GX6014@localhost> 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: Vinod Koul Cc: alsa-devel@alsa-project.org, kuninori.morimoto.gx@renesas.com, patches@opensource.cirrus.com, lgirdwood@gmail.com, vkoul@kernel.org, broonie@kernel.org List-Id: alsa-devel@alsa-project.org On Thu, May 03, 2018 at 09:57:14PM +0530, Vinod Koul wrote: > On Thu, Apr 26, 2018 at 05:30:05PM +0100, Charles Keepax wrote: > > It is proposed that the model adopted for compressed component > > support currently should be that multiple components are supported > > on a compressed DAI but that they must provide a unified set of > > capabilities. So for example having multiple components involved in > > the decode is fine but the core will not presently attempt to make > > smart decisions like offloading MP3 to this component and AAC another. > > Well this is supposed to be entirely a userspace call, we just present > devices with capabilities and the usespace decides... Btw capabilities are > supposed to be dynamic. My intention was to not suggest otherwise. The only point I was really making is that if there are multiple components on the link the core won't make attempt to amalgamate output from those components, but we will inform all components of activity on the DAI. > Looking at the code again now, I realized that we are treating compress like > PCM. It makes little sense to me to have multiple components for a > compressed device, does that model on your systems..? So that was very much my initial reaction as well [1], and certainly for our devices it only really makes sense to have a single component handle the compressed ops. Hence why I initially started with basically just returning the first component with compressed ops. That said however, thinking about it more I do think there are pretty reasonable systems that have multiple components on a compressed DAI. For example I could imagine a system where you have a DSP on both the AP and CODEC ends of the DAI link and they split the decode doing some work on each. In that case one would want calls like open and set_params to go to both components. As you say separate decode engines probably belong on separate DAIs and that kinda is what led me to the current series. It should implement enough to enable basic multi-component use-cases but makes it more clear that we are not supporting multiplexing multiple offloads onto a single DAI at the moment. Thanks, Charles [1] https://patchwork.kernel.org/patch/10182603/