[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4ec813ef-aa0d-655e-3f78-7c669d72551c@denx.de>
Date: Fri, 1 Sep 2023 17:47:57 +0200
From: Marek Vasut <marex@...x.de>
To: Adam Ford <aford173@...il.com>
Cc: linux-arm-kernel@...ts.infradead.org, aford@...conembedded.com,
Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Conor Dooley <conor+dt@...nel.org>,
Shawn Guo <shawnguo@...nel.org>,
Sascha Hauer <s.hauer@...gutronix.de>,
Pengutronix Kernel Team <kernel@...gutronix.de>,
Fabio Estevam <festevam@...il.com>,
NXP Linux Team <linux-imx@....com>,
Abel Vesa <abelvesa@...nel.org>, Peng Fan <peng.fan@....com>,
Michael Turquette <mturquette@...libre.com>,
Stephen Boyd <sboyd@...nel.org>, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-clk@...r.kernel.org
Subject: Re: [PATCH V3 1/3] arm64: dts: imx8mp: Add easrc node
On 9/1/23 13:02, Adam Ford wrote:
> On Thu, Aug 31, 2023 at 4:52 PM Marek Vasut <marex@...x.de> wrote:
>>
>> On 8/31/23 06:44, Adam Ford wrote:
>>> The i.MX8MP has an asynchronous sample rate converter which seems
>>> to be the same as what is available on the i.MX8M Nano.
>>>
>>> Signed-off-by: Adam Ford <aford173@...il.com>
>>> ---
>>> V3: No Change. The dt-binding update was already accepted into the sound tree, so that patch
>>> was dropped from the series
>>>
>>> V2: No Change.
>>> diff --git a/arch/arm64/boot/dts/freescale/imx8mp.dtsi b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
>>> index 83d907294fbc..3167706d81e1 100644
>>> --- a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
>>> +++ b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
>>> @@ -1459,6 +1459,26 @@ sai7: sai@...80000 {
>>> interrupts = <GIC_SPI 111 IRQ_TYPE_LEVEL_HIGH>;
>>> status = "disabled";
>>> };
>>> +
>>> + easrc: easrc@...90000 {
>>> + compatible = "fsl,imx8mp-easrc", "fsl,imx8mn-easrc";
>>> + reg = <0x30c90000 0x10000>;
>>> + interrupts = <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>;
>>> + clocks = <&audio_blk_ctrl IMX8MP_CLK_AUDIOMIX_ASRC_IPG>;
>>> + clock-names = "mem";
>>> + dmas = <&sdma2 16 23 0> , <&sdma2 17 23 0>,
>>> + <&sdma2 18 23 0> , <&sdma2 19 23 0>,
>>> + <&sdma2 20 23 0> , <&sdma2 21 23 0>,
>>> + <&sdma2 22 23 0> , <&sdma2 23 23 0>;
>>> + dma-names = "ctx0_rx", "ctx0_tx",
>>> + "ctx1_rx", "ctx1_tx",
>>> + "ctx2_rx", "ctx2_tx",
>>> + "ctx3_rx", "ctx3_tx";
>>> + firmware-name = "imx/easrc/easrc-imx8mn.bin";
>>
>> Should the firmware name really be imx8mn or should it be imx8mp ?
>
> The firmware blobs provided by NXP only has easrc-imx8mn.bin and would
> be concerned that having a different name might confuse people if they
> try to go look for it and they only find easrc-imx8mn.bin. To me,
> this is no different than the SDMA driver using firmware called
> sdma-imx7d.bin
On the other hand, there is "fsl,imx8mp-easrc" compatible string -- to
differentiate between IPs in case some difference between the IPs that
cannot be predicted so far is found later on.
>> I think the later is better, you can always add a symlink for the
>> firmware name, and you can discern mx8mn/mp firmwares on the same rootfs
>> in case that was ever needed in the future.
Which is what this part of my comment ^ is all about.
Powered by blists - more mailing lists