devicetree-spec.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Gibson <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org>
To: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
Cc: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	Ramon Fried <rfried.dev-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	Mailing List
	<devicetree-spec-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: Memory aliasing and nodes
Date: Fri, 22 Apr 2022 11:40:49 +1000	[thread overview]
Message-ID: <YmIHoY3kTAbsGHv4@yekko> (raw)
In-Reply-To: <CAK8P3a2KGkH0Sf7fzWBAByTRnSXSy_u22=_s6Y7WLhrWNvJuyQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

[-- 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 --]

      parent reply	other threads:[~2022-04-22  1:40 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-21 10:33 Memory aliasing and nodes Ramon Fried
     [not found] ` <CAGi-RUL4FJBXYUMbpdMo=XNd7DE1wD6aUqXUt5Y+5BY1KO-FYg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2022-04-21 12:54   ` Arnd Bergmann
     [not found]     ` <CAK8P3a3AjEbFE1D-n4Q53_UjBwRk3D-XdaaEqVJs3QOWLHOeqg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2022-04-21 17:24       ` Ramon Fried
     [not found]         ` <CAGi-RUJ5rn5Zn_rv6JX4XhGSfxUw_QcWe=M80ET5sYbi11e7GA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2022-04-21 19:28           ` Rob Herring
     [not found]             ` <CAL_JsqLXRcQa_h8JiUWHK=Gph=vvMvmsbq4OACLKT==iPgaYqg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2022-04-21 20:15               ` Arnd Bergmann
     [not found]                 ` <CAK8P3a2KGkH0Sf7fzWBAByTRnSXSy_u22=_s6Y7WLhrWNvJuyQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2022-04-22  1:40                   ` David Gibson [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YmIHoY3kTAbsGHv4@yekko \
    --to=david-xt8fgy+axnrb3ne2bgzf6laj5h9x9tb+@public.gmane.org \
    --cc=arnd-r2nGTMty4D4@public.gmane.org \
    --cc=devicetree-spec-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=rfried.dev-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).