All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
To: Ramon Fried <rfried.dev-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: devicetree-spec-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: Memory aliasing and nodes
Date: Thu, 21 Apr 2022 14:54:48 +0200	[thread overview]
Message-ID: <CAK8P3a3AjEbFE1D-n4Q53_UjBwRk3D-XdaaEqVJs3QOWLHOeqg@mail.gmail.com> (raw)
In-Reply-To: <CAGi-RUL4FJBXYUMbpdMo=XNd7DE1wD6aUqXUt5Y+5BY1KO-FYg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

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

  parent reply	other threads:[~2022-04-21 12:54 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 [this message]
     [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

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=CAK8P3a3AjEbFE1D-n4Q53_UjBwRk3D-XdaaEqVJs3QOWLHOeqg@mail.gmail.com \
    --to=arnd-r2ngtmty4d4@public.gmane.org \
    --cc=devicetree-spec-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=rfried.dev-Re5JQEeQqe8AvxtiuMwx3w@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.