Message-ID: <4e876c89ee58cd1408511a34573005e3df359cd0.camel@mediatek.com>
Date:   Mon, 8 Nov 2021 17:40:52 +0800
From:   YC Hung <yc.hung@...iatek.com>
To:     Mark Brown <broonie@...nel.org>,
        Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>
CC:     Trevor Wu <trevor.wu@...iatek.com>, <devicetree@...r.kernel.org>,
        <alsa-devel@...a-project.org>, <tiwai@...e.com>,
        <linux-kernel@...r.kernel.org>, <robh+dt@...nel.org>,
        <linux-mediatek@...ts.infradead.org>, <matthias.bgg@...il.com>,
        <daniel.baluta@....com>, <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH 3/4] ASoC: mediatek: mt8195: separate the common code
 from machine driver

Hi Mark,

I am YC Hung from Mediatek. Let me show our block diagram as the link
below for the sound card which support SOF.

https://user-images.githubusercontent.com/62316/132476344-923dfe3a-5305-43e5-9fc8-c63d9ab2c58f.png
In this sound card, there are two components , one is SOF based
component and another is non-SOF based component(called Normal in the
block).
We want to reuse some BEs of Normal which can control Mediatek Audio
Front End hardware power, clock , and DAI module and still keep some
FEs(e.g. DPTX) then we can use it on the same sound card.
Therefore, we use late_probe callback function
"mt8195_mt6359_rt1019_rt5682_card_late_probe" to add route path from
SOF widget to non-SOF BEs.
For two patches https://github.com/thesofproject/linux/pull/3217 and 
https://github.com/thesofproject/linux/pull/3236, we want to keep FEs
of non-SOF components and can reuse them. Please let me know if I am
not clear enough.Thanks.

On Fri, 2021-11-05 at 16:41 +0000, Mark Brown wrote:
> On Fri, Nov 05, 2021 at 11:16:05AM -0500, Pierre-Louis Bossart wrote:
> > On 11/5/21 10:38 AM, Mark Brown wrote:
> > > We shouldn't be requiring people to load completely different
> > > drivers
> > > based on software configuration, what if a system wants to bypass
> > > the
> > > DSP in some but not all configurations?  Can we not just have
> > > controls
> > > allowing users to route round the DSP where appropriate?
> > It was my understanding the card relies on separate components
> > - a SOF-based component to provide support for DSP-managed
> > interfaces
> > - a 'non-SOF' component for 'regular' interfaces not handled by the
> > DSP.
> > this was the basis for the changes discussed in
> > https://github.com/thesofproject/linux/pull/3217 and
> > https://github.com/thesofproject/linux/pull/3236
> 
> So it's actually supposed to end up as two different cards which
> can't
> possibly be interlinked?  That doesn't seem to add up entirely given
> that there's stuff being moved out of the current card, and I thought
> these systems had a fairly comprehensive audio muxing capability.
> Trevor, could you be a bit more specific about what's actually going
> on
> here physically please?
> 
> > But indeed if the same interface can be managed by the DSP or not,
> > depending on software choices it's a different problem altogether.
> > We've looked into this recently, if the choice to involve the DSP
> > or not
> > is at the interface level, it might be better to have both
> > components
> > expose different DAIs for the same interface, with some sort of
> > run-time
> > mutual exclusion, so that all possible/allowed permutations are
> > allowed.
> 
> Yes, if the interface can optionally be completely hidden by the DSP
> that's adding another layer of complication.
> _______________________________________________
> Linux-mediatek mailing list
> Linux-mediatek@...ts.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek

Powered by blists - more mailing lists