Memory aliasing and nodes

Memory aliasing and nodes

[Ramon Fried]

Hi all,
This is the second time in my career that I've stumbled upon a SOC
which has 32bit memory aliasing for high memory for the usage of
drivers that can only address 32bit address space.

Basically, a subset of a memory higher than 4GB can be accessed also
through a range in the low 4GB addresses.

I didn't see any support for this neither Linux kernel nor in device
tree. I'm wondering if you considered adding a way to describe such
addressing in the device tree, and maybe later Linux can add support
for it.

Thanks,
Ramon

Re: Memory aliasing and nodes

[Arnd Bergmann]

On Thu, Apr 21, 2022 at 12:33 PM Ramon Fried <rfried.dev-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> Hi all,
> This is the second time in my career that I've stumbled upon a SOC
> which has 32bit memory aliasing for high memory for the usage of
> drivers that can only address 32bit address space.
>
> Basically, a subset of a memory higher than 4GB can be accessed also
> through a range in the low 4GB addresses.
>
> I didn't see any support for this neither Linux kernel nor in device
> tree. I'm wondering if you considered adding a way to describe such
> addressing in the device tree, and maybe later Linux can add support
> for it.

I think we have some of those already, notably the TI Keystone platform,
which only lists one of the two areas in the DT.

It probably does not matter which one it is, but it may help to have
at least some memory in the lower address range.

In either case, make sure to add the correct dma-ranges properties to
describe which memory is visible to which devices at a given address.

       Arnd

Re: Memory aliasing and nodes

[Ramon Fried]

On Thu, Apr 21, 2022 at 3:55 PM Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
>
> On Thu, Apr 21, 2022 at 12:33 PM Ramon Fried <rfried.dev-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >
> > Hi all,
> > This is the second time in my career that I've stumbled upon a SOC
> > which has 32bit memory aliasing for high memory for the usage of
> > drivers that can only address 32bit address space.
> >
> > Basically, a subset of a memory higher than 4GB can be accessed also
> > through a range in the low 4GB addresses.
> >
> > I didn't see any support for this neither Linux kernel nor in device
> > tree. I'm wondering if you considered adding a way to describe such
> > addressing in the device tree, and maybe later Linux can add support
> > for it.
>
> I think we have some of those already, notably the TI Keystone platform,
> which only lists one of the two areas in the DT.
>
> It probably does not matter which one it is, but it may help to have
> at least some memory in the lower address range.
>
> In either case, make sure to add the correct dma-ranges properties to
> describe which memory is visible to which devices at a given address.
>
>        Arnd
Hi Arnd.
What you suggest will of course work, and this is how I planned to implement it.
The problem, IMO, is that the addressing of the SOC it's not obvious
from the device tree.
My understanding is that device-tree should describe the hardware, it
just looks like a workaround to me.
Thanks,
Ramon.

Re: Memory aliasing and nodes

[Rob Herring]

On Thu, Apr 21, 2022 at 12:25 PM Ramon Fried <rfried.dev-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> On Thu, Apr 21, 2022 at 3:55 PM Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
> >
> > On Thu, Apr 21, 2022 at 12:33 PM Ramon Fried <rfried.dev-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > >
> > > Hi all,
> > > This is the second time in my career that I've stumbled upon a SOC
> > > which has 32bit memory aliasing for high memory for the usage of
> > > drivers that can only address 32bit address space.
> > >
> > > Basically, a subset of a memory higher than 4GB can be accessed also
> > > through a range in the low 4GB addresses.
> > >
> > > I didn't see any support for this neither Linux kernel nor in device
> > > tree. I'm wondering if you considered adding a way to describe such
> > > addressing in the device tree, and maybe later Linux can add support
> > > for it.
> >
> > I think we have some of those already, notably the TI Keystone platform,
> > which only lists one of the two areas in the DT.
> >
> > It probably does not matter which one it is, but it may help to have
> > at least some memory in the lower address range.
> >
> > In either case, make sure to add the correct dma-ranges properties to
> > describe which memory is visible to which devices at a given address.
> >
> >        Arnd
> Hi Arnd.
> What you suggest will of course work, and this is how I planned to implement it.
> The problem, IMO, is that the addressing of the SOC it's not obvious
> from the device tree.
> My understanding is that device-tree should describe the hardware, it
> just looks like a workaround to me.

The h/w has some translation from one address to another and that's
exactly what 'dma-ranges' is for. How is that not describing the h/w?

Rob

Re: Memory aliasing and nodes

[Arnd Bergmann]

On Thu, Apr 21, 2022 at 9:28 PM Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>
> On Thu, Apr 21, 2022 at 12:25 PM Ramon Fried <rfried.dev-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >
> > On Thu, Apr 21, 2022 at 3:55 PM Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
> > >
> > > On Thu, Apr 21, 2022 at 12:33 PM Ramon Fried <rfried.dev-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > > >
> > > > Hi all,
> > > > This is the second time in my career that I've stumbled upon a SOC
> > > > which has 32bit memory aliasing for high memory for the usage of
> > > > drivers that can only address 32bit address space.
> > > >
> > > > Basically, a subset of a memory higher than 4GB can be accessed also
> > > > through a range in the low 4GB addresses.
> > > >
> > > > I didn't see any support for this neither Linux kernel nor in device
> > > > tree. I'm wondering if you considered adding a way to describe such
> > > > addressing in the device tree, and maybe later Linux can add support
> > > > for it.
> > >
> > > I think we have some of those already, notably the TI Keystone platform,
> > > which only lists one of the two areas in the DT.
> > >
> > > It probably does not matter which one it is, but it may help to have
> > > at least some memory in the lower address range.
> > >
> > > In either case, make sure to add the correct dma-ranges properties to
> > > describe which memory is visible to which devices at a given address.
> > >
> > What you suggest will of course work, and this is how I planned to implement it.
> > The problem, IMO, is that the addressing of the SOC it's not obvious
> > from the device tree.
> > My understanding is that device-tree should describe the hardware, it
> > just looks like a workaround to me.
>
> The h/w has some translation from one address to another and that's
> exactly what 'dma-ranges' is for. How is that not describing the h/w?

I think he was just referring to the memory nodes that don't let you
describe how the same physical memory appears at two addresses.

I don't think it's a big deal though, as memory nodes are somewhat
special to start with, and the problem is more with the hardware
being badly designed than the dt failing to describe it.

     Arnd

Re: Memory aliasing and nodes

[David Gibson]

[-- Attachment #1: Type: text/plain, Size: 3030 bytes --]

On Thu, Apr 21, 2022 at 10:15:46PM +0200, Arnd Bergman wrote:
> On Thu, Apr 21, 2022 at 9:28 PM Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> >
> > On Thu, Apr 21, 2022 at 12:25 PM Ramon Fried <rfried.dev-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > >
> > > On Thu, Apr 21, 2022 at 3:55 PM Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
> > > >
> > > > On Thu, Apr 21, 2022 at 12:33 PM Ramon Fried <rfried.dev-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > > > >
> > > > > Hi all,
> > > > > This is the second time in my career that I've stumbled upon a SOC
> > > > > which has 32bit memory aliasing for high memory for the usage of
> > > > > drivers that can only address 32bit address space.
> > > > >
> > > > > Basically, a subset of a memory higher than 4GB can be accessed also
> > > > > through a range in the low 4GB addresses.
> > > > >
> > > > > I didn't see any support for this neither Linux kernel nor in device
> > > > > tree. I'm wondering if you considered adding a way to describe such
> > > > > addressing in the device tree, and maybe later Linux can add support
> > > > > for it.
> > > >
> > > > I think we have some of those already, notably the TI Keystone platform,
> > > > which only lists one of the two areas in the DT.
> > > >
> > > > It probably does not matter which one it is, but it may help to have
> > > > at least some memory in the lower address range.
> > > >
> > > > In either case, make sure to add the correct dma-ranges properties to
> > > > describe which memory is visible to which devices at a given address.
> > > >
> > > What you suggest will of course work, and this is how I planned to implement it.
> > > The problem, IMO, is that the addressing of the SOC it's not obvious
> > > from the device tree.
> > > My understanding is that device-tree should describe the hardware, it
> > > just looks like a workaround to me.
> >
> > The h/w has some translation from one address to another and that's
> > exactly what 'dma-ranges' is for. How is that not describing the h/w?
> 
> I think he was just referring to the memory nodes that don't let you
> describe how the same physical memory appears at two addresses.

> I don't think it's a big deal though, as memory nodes are somewhat
> special to start with, and the problem is more with the hardware
> being badly designed than the dt failing to describe it.

I don't think you need to appeal to special cases here - this can be
described in the dt.  Just put the memory on a sub-ordinate bus, and
have the top-level bus with a 'ranges' property that maps the two
aliased windows to the same place in the memory's address space.

Of course... at present Linux might not react well to having memory
nodes somewhere other than top-level nodes.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]