All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andre Przywara <andre.przywara@arm.com>
To: u-boot@lists.denx.de
Subject: 32-bit DMA limit for devices (and drivers)
Date: Fri, 30 Apr 2021 12:21:21 +0100	[thread overview]
Message-ID: <20210430122121.00ea642d@slackpad.fritz.box> (raw)

Hi,

We now see the first Allwinner devices [1] having DRAM located above
4GB in address space (4GB DRAM starting at 1GB). After one fix[2]
this works somewhat fine, but the sun8i-emac network device is still
limited to 32-bit DMA addresses. With U-Boot relocating itself (plus
stack and heap) to the end of DRAM, it now runs completely beyond 4GB
on those machines, so not giving pure 32-bit addresses for buffers
anymore.
In Linux we handle this easily by just keeping the default DMA
mask at 32 bits, and letting the DMA framework deal with the nasty
details.

I was wondering how this should be handled in U-Boot? The straight
forward solution would be:
- Let the driver allocate the RX and TX buffers separately, placing them
  below 4GB in the address space (using lmb_reserve(), I guess?)
- Use those RX buffers and hand the addresses back to the upper layers.
- We already copy TX packets, so this would also be covered, in this
  situation. Other drivers might need to introduce copying.

This sounds like a common problem, so I was wondering if there is a
more generic solution to this? Maybe there are already platforms or
devices affected? Or should the whole heap and stack be moved below 4GB
(if this is easily possible)?
In our case we make the buffers part of our priv struct, so should
there be an option to let the priv_auto allocation come from below 4GB?

Grateful for any input on this!

Thanks!
Andre

[1] https://linux-sunxi.org/X96_Mate
[2] https://lists.denx.de/pipermail/u-boot/2021-April/448327.html

             reply	other threads:[~2021-04-30 11:21 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-30 11:21 Andre Przywara [this message]
2021-04-30 12:02 ` 32-bit DMA limit for devices (and drivers) Mark Kettenis
2021-04-30 13:34   ` Andre Przywara
2021-04-30 16:31     ` Jernej Škrabec
2021-05-01 11:45 ` Bin Meng
2021-05-01 12:23   ` Mark Kettenis
2021-05-02  0:21     ` Andre Przywara
2021-05-02  0:30       ` Bin Meng

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=20210430122121.00ea642d@slackpad.fritz.box \
    --to=andre.przywara@arm.com \
    --cc=u-boot@lists.denx.de \
    /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.