From: Eric Anholt <eric@anholt.net>
To: u-boot@lists.denx.de
Subject: [U-Boot] [RFC PATCH] usb: dwc2: handle bcm2835 phys->virt address translations
Date: Fri, 13 Mar 2015 10:02:49 -0700 [thread overview]
Message-ID: <87fv98rft2.fsf@eliezer.anholt.net> (raw)
In-Reply-To: <1426227189-30488-1-git-send-email-swarren@wwwdotorg.org>
Stephen Warren <swarren@wwwdotorg.org> writes:
> BCM2835 bus addresses use the top 2 bits to determine whether peripherals
> use or bypass the GPU L1 and L2 cache. BCM2835-ARM-Peripherals.pdf states
> that:
>
> 0: L1 & L2 cached
> 4: L2 cache coherent (non allocaing)
> 8: L2 cached only
> c: Direct uncached.
>
> That document also states that "Software accessing RAM using the DMA
> engines must use bus addresses (base at 0xc0000000). However, this appears
> to be incorrect since it does not work in practice on the bcm2835
> (although it does on bcm2836). "usb start" causes some EABI function to
> call raise(8), presumably due to corrupted USB IN data (the converse is
> true on bcm2836; a value of 4 causes signals). However, I haven't
> investigated the cause.
>
> A value of 4 matches what the RPI Foundation's kernel; see the definition
> of _REAL_BUS_OFFSET in arch/arm/mach-bcm2708/include/mach/memory.h. With
> the code updated to implement a phys->bus translation by setting the top
> two bits of DWC2 DMA addresses to 4, USB keyboard support appears stable.
>
> A similar change is made for bcm2836 (RPi 2). I can't justify this value
> since it doesn't match the RPi Foundation kernel. However, it does appear
> to work for the built-in USB Ethernet at least.
>
> Ideally, the bcm2835 SoC support would provide some common function for
> any DMA-capable driver to call to perform the phys->bus translation,
> rather than placing ifdefs in each driver file. However, I can't find
> such a standard function in U-Boot.
Huh. Agreed that it seems like it should be 0xc top bits on both, but I
guess whatever works.
It does seem like we ought to have some vtophys / vtobus functions.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150313/639bb1f3/attachment.sig>
next prev parent reply other threads:[~2015-03-13 17:02 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-13 6:13 [U-Boot] [RFC PATCH] usb: dwc2: handle bcm2835 phys->virt address translations Stephen Warren
2015-03-13 14:30 ` Marek Vasut
2015-03-13 16:35 ` Stephen Warren
2015-03-13 18:13 ` Marek Vasut
2015-03-13 18:39 ` Stephen Warren
2015-03-13 18:49 ` Marek Vasut
2015-03-13 17:02 ` Eric Anholt [this message]
2015-03-15 16:04 ` Stephen Warren
2015-03-15 18:20 ` Marek Vasut
2015-03-17 3:04 ` Stephen Warren
2015-03-17 14:57 ` popcorn mix
2015-03-17 17:29 ` Stephen Warren
2015-03-17 17:53 ` popcorn mix
2015-03-15 16:51 ` Stephen Warren
2015-03-15 18:20 ` Marek Vasut
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=87fv98rft2.fsf@eliezer.anholt.net \
--to=eric@anholt.net \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox