[PATCH v3 2/3] arm64: dts: zynqmp: Add DMA for DP audio

Michal Simek michal.simek at amd.com
Wed Oct 23 12:50:15 UTC 2024


Hi Tomi,

On 10/23/24 14:00, Tomi Valkeinen wrote:
> Hi Michal,
> 
> On 08/10/2024 11:22, Michal Simek wrote:
>>
>>
>> On 9/10/24 13:19, Tomi Valkeinen wrote:
>>> Add the two DMA channels used for the DisplayPort audio to the
>>> zynqmp_dpsub node.
>>>
>>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen at ideasonboard.com>
>>> ---
>>>   arch/arm64/boot/dts/xilinx/zynqmp.dtsi | 7 +++++--
>>>   1 file changed, 5 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi b/arch/arm64/boot/ dts/ 
>>> xilinx/zynqmp.dtsi
>>> index b1b31dcf6291..673ca8422e6b 100644
>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
>>> @@ -1207,11 +1207,14 @@ zynqmp_dpsub: display at fd4a0000 {
>>>                         "dp_vtc_pixel_clk_in";
>>>               power-domains = <&zynqmp_firmware PD_DP>;
>>>               resets = <&zynqmp_reset ZYNQMP_RESET_DP>;
>>> -            dma-names = "vid0", "vid1", "vid2", "gfx0";
>>> +            dma-names = "vid0", "vid1", "vid2", "gfx0",
>>> +                    "aud0", "aud1";
>>>               dmas = <&zynqmp_dpdma ZYNQMP_DPDMA_VIDEO0>,
>>>                      <&zynqmp_dpdma ZYNQMP_DPDMA_VIDEO1>,
>>>                      <&zynqmp_dpdma ZYNQMP_DPDMA_VIDEO2>,
>>> -                   <&zynqmp_dpdma ZYNQMP_DPDMA_GRAPHICS>;
>>> +                   <&zynqmp_dpdma ZYNQMP_DPDMA_GRAPHICS>,
>>> +                   <&zynqmp_dpdma ZYNQMP_DPDMA_AUDIO0>,
>>> +                   <&zynqmp_dpdma ZYNQMP_DPDMA_AUDIO1>;
>>>               ports {
>>>                   #address-cells = <1>;
>>>
>>
>> Acked-by: Michal Simek <michal.simek at amd.com>
>>
>> If you want me to take this patch via my tree please let me know.
> 
> Thanks. I've sent a v4, but no changes to this patch.
> 
> I'm not sure what is the custom with xilinx dts changes. With the other 
> platforms dts changes have always gone through a single tree, not via driver trees.
> 
> I don't have a preference either way, so if there's no clear rule here, I can 
> take this one with the other patches.

I have seen it both ways. If this is done with patches it is easier because I 
can't really send it before dt binding patch reaches upstream. It means there is 
going to be delay.
Normally it should be enough that I gave you my tag that you can also change the 
DT files too.

Thanks,
Michal



More information about the dri-devel mailing list