Re: Re: Re: [RESEND PATCH v6 5/6] arm64: tegra: Audio graph header for Tegra210

[Sameer Pujar]

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@xxxxxxxxxx>
> > > > Reviewed-by: Jon Hunter <jonathanh@xxxxxxxxxx>
> > > > ---
> > > >    .../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.