[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <fb0d0f14-e038-cb0c-542e-011ccb4beb93@nvidia.com>
Date: Wed, 20 Jan 2021 10:36:44 +0530
From: Sameer Pujar <spujar@...dia.com>
To: Thierry Reding <thierry.reding@...il.com>
CC: <broonie@...nel.org>, <robh+dt@...nel.org>, <jonathanh@...dia.com>,
<kuninori.morimoto.gx@...esas.com>, <alsa-devel@...a-project.org>,
<devicetree@...r.kernel.org>, <linux-tegra@...r.kernel.org>,
<linux-kernel@...r.kernel.org>, <sharadg@...dia.com>
Subject: Re: Re: Re: [RESEND PATCH v6 5/6] arm64: tegra: Audio graph header
for Tegra210
On 1/19/2021 11:27 PM, Thierry Reding wrote:
> On Tue, Jan 19, 2021 at 11:09:32PM +0530, Sameer Pujar wrote:
>>
>> On 1/19/2021 10:45 PM, Thierry Reding wrote:
>>> On Tue, Jan 19, 2021 at 02:58:15PM +0530, Sameer Pujar wrote:
>>>> Expose a header which describes DT bindings required to use audio-graph
>>>> based sound card. All Tegra210 based platforms can include this header
>>>> and add platform specific information. Currently, from SoC point of view,
>>>> all links are exposed for ADMAIF, AHUB, I2S and DMIC components.
>>>>
>>>> Signed-off-by: Sameer Pujar <spujar@...dia.com>
>>>> Reviewed-by: Jon Hunter <jonathanh@...dia.com>
>>>> ---
>>>> .../boot/dts/nvidia/tegra210-audio-graph.dtsi | 153 +++++++++++++++++++++
>>>> 1 file changed, 153 insertions(+)
>>>> create mode 100644 arch/arm64/boot/dts/nvidia/tegra210-audio-graph.dtsi
>>> I prefer keeping everything in tegra210.dtsi, but I can do that merge
>>> when I apply, after the DT bindings have been acked, so no need to
>>> resend just because of that.
>> I think this may be fine for Tegra210 based boards. But for Tegra186 and
>> Tegra194, whenever we add support for it, can rely on a common audio-graph
>> dtsi because there is no change w.r.t APE. This can help us to avoid
>> duplication of the bindings. This most likely applies to future chips as
>> well (where Tegra186 audio-graph bindings can be considered as base) when
>> there is no significant change in APE.
> Maybe. Although that argument is somewhat extreme because we already
> have some of that same duplication throughout the other .dtsi files. By
> the same argument we could save a bit of duplication by having something
> like tegra-gpio.dtsi and including that in all the SoC .dtsi files and
> only update the compatible string, because that's the only significant
> change.
> Duplication isn't a big problem for DTS files because the data is meant
> to be stable anyway. So once it is in place and doesn't have to change,
> it really doesn't matter if it comes from an include or it's duplicated.
OK, if there is no issue with duplication then fine with me. Thanks.
Powered by blists - more mailing lists