[RESEND PATCH v6 5/6] arm64: tegra: Audio graph header for Tegra210
Sameer Pujar
spujar at nvidia.com
Wed Jan 20 06:06:44 CET 2021
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 at nvidia.com>
>>>> Reviewed-by: Jon Hunter <jonathanh at nvidia.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.
More information about the Alsa-devel
mailing list