Re: [PATCH] Revert "arm64: dts: juno: add dma-ranges property"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Nov 28, 2019 at 03:58:28PM +0000, Robin Murphy wrote:
> On 28/11/2019 3:42 pm, Sudeep Holla wrote:
> > This reverts commit 193d00a2b35ee3353813b4006a18131122087205.
> >
> > Commit 951d48855d86 ("of: Make of_dma_get_range() work on bus nodes")
> > reworked the logic such that of_dma_get_range() works correctly
> > starting from a bus node containing "dma-ranges".
> >
> > Since on Juno we don't have a SoC level bus node and "dma-ranges" is
> > present only in the root node, we get the following error:
> >
> > OF: translation of DMA address(0) to CPU address failed node(/sram@2e000000)
> > OF: translation of DMA address(0) to CPU address failed node(/uart@7ff80000)
> > ...
> > OF: translation of DMA address(0) to CPU address failed node(/mhu@2b1f0000)
> > OF: translation of DMA address(0) to CPU address failed node(/iommu@2b600000)
> > OF: translation of DMA address(0) to CPU address failed node(/iommu@2b600000)
> > OF: translation of DMA address(0) to CPU address failed node(/iommu@2b600000)
> >
> > So let's fix it by dropping the "dma-ranges" property for now. We can
> > add it later with a proper SoC bus node and moving all the devices that
> > belong there along with the "dma-ranges" if required.
>
> Acked-by: Robin Murphy <robin.murphy@xxxxxxx>
>

Thanks.

> As mentioned before, this is fine since it doesn't represent any kind of
> device-visible restriction; it was only there for completeness, and we've
> since given in to the assumption that missing "dma-ranges" implies a 1:1
> mapping anyway.
>

Agreed.

--
Regards,
Sudeep



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux