Re: [PATCH] ARM: dts: integrator: Fix DMA ranges

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

 



On Fri, Sep 23, 2022 at 3:21 PM Arnd Bergmann <arnd@xxxxxxxx> wrote:
> On Fri, Sep 23, 2022, at 2:56 PM, Linus Walleij wrote:

> > Here the special memory appears in the CPU address map.
> >
> >         bus@c0000000 {
> >                 compatible = "arm,integrator-ap-lm";
> >                 #address-cells = <1>;
> >                 #size-cells = <1>;
> >                 ranges = <0xc0000000 0xc0000000 0x40000000>;
> >                 dma-ranges;
> > (...)
> >                 lm0: bus@c0000000 {
> >                         compatible = "simple-bus";
> >                         ranges = <0x00000000 0xc0000000 0x10000000>;
> >                         dma-ranges = <0x00000000 0xc0000000 0x10000000>;
> >                         reg = <0xc0000000 0x10000000>;
> >                         #address-cells = <1>;
> >                         #size-cells = <1>;
> >
> >                         display@1000000 {
> >                                 compatible = "arm,pl110", "arm,primecell";
> >                                 reg = <0x01000000 0x1000>;
> > (...)
> >                                 memory-region = <&impd1_ram>;
> >                                 dma-ranges;
> > (...)
> >
> > Here we find the reg properly at physical address 0xc1000000 thanks to
> > the ranges: 0xc0000000 + 0x00000000 + 0x01000000 = 0xc1000000.
> >
> > But the special memory region is in the root of the device tree,
> > outside of the translation.
> >
> > Now dma-ranges will assume that when we translate the memory region
> > it is in the address space of the display controller, but it isn't,
> > because the phandle goes to something in the root of the device tree.
> >
> > 0xc2000000 + 0x00000000 + 0x00000000 = 0xc2000000
> >
> > Whenever I do ranges my head start spinning :/
> >
> > If you have a better way to accomodate the DMA ranges I am happy to
> > comply!
>
> I'm still not sure I understand it. Is that reserved memory
> area in RAM or on the logic bus?

It's on the logic bus slot "lm0", so the display controller is
at 0xc1000000 and right below it at 0xc2000000 is 1MB
of dedicated graphics memory.

> The 'ranges' property makes
> it appear that all of 0xc0000000-0xcfffffff is the logic bus,

Yep it is.

> but then the vram itself is also in that address range, which
> would indicate that it is behind that bus.

Yep it is.

>  However, using the
> 'reserved-memory' property indicates that this is actually
> just normal RAM that is carved out from what the OS manages.

The binding document
Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml
unfortunately does not mention anywhere that the reserved memory
must be a subset of the system main RAM "carveout" or anything like that,
it says that  the memory should be "designed for special usage by various
device drivers", and "excluded from normal usage" which it is, hence the
misunderstanding.

We have used this for Vexpress like forever, but I did
the change from some custom vexpress memory property
to shared-dma-pool so I guess that's my fault.
Incidentally this also works very well.

Is there some other mechanism we should be using for dedicated
framebuffer memory on some odd address?

Yours,
Linus Walleij



[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux