Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [PATCH v2 04/16] ASoC: qcom: dt-bindings: add bindings Audio
 Processing manager
To:     Mark Brown <broonie@kernel.org>
Cc:     Rob Herring <robh@kernel.org>, bjorn.andersson@linaro.org,
        plai@codeaurora.org, tiwai@suse.de, devicetree@vger.kernel.org,
        perex@perex.cz, alsa-devel@alsa-project.org,
        linux-kernel@vger.kernel.org, lgirdwood@gmail.com,
        bgoswami@codeaurora.org
References: <20210714153039.28373-1-srinivas.kandagatla@linaro.org>
 <20210714153039.28373-5-srinivas.kandagatla@linaro.org>
 <20210728173649.GA1290628@robh.at.kernel.org>
 <092018be-50ae-6dda-73cd-6c7eb002dc19@linaro.org>
 <20210729111338.GJ4670@sirena.org.uk>
From:   Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Message-ID: <a03beb7c-ee4c-fbe0-49bf-1d9b6fa17b94@linaro.org>
Date:   Fri, 30 Jul 2021 12:06:45 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <20210729111338.GJ4670@sirena.org.uk>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk

Thanks Mark for the review,

On 29/07/2021 12:13, Mark Brown wrote:
>>> This all looks fairly similar to the prior Qcom audio binding(s). It
>>> would be nice to not see this all re-invented.
>> AudioReach is a new DSP signal processing framework Which is different to
>> its previous DSP firmware(aka Elite).
>> It makes use of ASoC Topology to load audio graphs on to the DSP which is
>> then managed by APM (Audio Processing Manager) service.
>> So internals are not exactly same.
>>  From device tree side we might end up with similar layout, but there are
>> some subtle differences like clocks are managed by q6prm service instead of
>> q6afe service in old firmware, front-end pcm dais definitions come from ASoC
>> topology.

> The software we're running on the hardware shouldn't impact how the
> hardware is described, it should be posible to switch DSP frameworks on
> the same hardware - look at what Intel have done with SoF.

I totally agree with you.

There are two parts to the software running on the hardware, first is 
the hardware itself and second is the services that are running which 
control parts of hardware.

Hardware device tree description across these new and old DSP framework 
are exactly same, However association between hardware and DSP service 
would change as per DSP framework services it exposes.

Ex: clock controller would be associated with PRM(proxy resource 
manager) in AudioReach vs AFE (Audio Frontend Manager) in Elite, but the 
clocks and other hardware properties remain same across these.

As exiting DT-bindings had both services and hardware description in 
same document which Is why I could not reuse it.

I will try to split up the hardware parts and DSP services parts in the 
existing bindings so that we could reuse the hardware bindings across 
multiple dsp frameworks. It should also be possible to reuse some old 
code too in this process.

--srini
> 
>> Are you suggesting that we should reuse the old bindings (q6afe, q6asm) by
>> add new compatible strings along with differences ?