public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
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>

  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