public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Marek Vasut <marex@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [RFC PATCH] usb: dwc2: handle bcm2835 phys->virt address translations
Date: Fri, 13 Mar 2015 19:49:49 +0100	[thread overview]
Message-ID: <201503131949.49519.marex@denx.de> (raw)
In-Reply-To: <55032ECC.3050805@wwwdotorg.org>

On Friday, March 13, 2015 at 07:39:08 PM, Stephen Warren wrote:
> On 03/13/2015 12:13 PM, Marek Vasut wrote:
> > On Friday, March 13, 2015 at 05:35:53 PM, Stephen Warren wrote:
> >> On 03/13/2015 08:30 AM, Marek Vasut wrote:
> >>> On Friday, March 13, 2015 at 07:13:09 AM, Stephen Warren wrote:
> >>>> 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.
> >>> 
> >>> Caches aren't working on BCM2xxx or what's the reason for this hack ?
> >>> Or are these different (not on-CPU) caches we're talking about (yes,
> >>> I did notice the GPU Lx cache stuff)?
> >> 
> >> Yes, the "GPU" has its own caches, entirely separate from the ARM core
> >> and at a different location in the system bus structure, and it seems as
> >> if at least some other peripherals other than GPU/graphics/VideoCore
> >> access DRAM via those caches too.
> >> 
> >> There are some brief details in BCM2835-ARM-Peripherals.pdf, although it
> >> isn't terribly clear.
> > 
> > Thanks for clearing this up. I suspect there's no way to turn those
> > caches off altogether, right ? But uh ... ew :(
> 
> There may be, Search for disable_l2cache at http://elinux.org/RPiconfig.
> That option is read by the SoC's binary bootloader (which I believe
> 99%-100% runs on the VideoCore not ARM) and programmed before the ARM
> bootloader (U-Boot) is started.
> 
> The disadvantages of the option are:
> 
> * According to all descriptions of the option I've seen, it requires
> that SW that wishes to run with that option enabled must pass a
> different upper 2 bits of physical address to DMA engines. See for
> example the elinux.org link above and:
> 
> https://github.com/raspberrypi/linux/blob/rpi-3.18.y/arch/arm/mach-bcm2708/
> include/mach/memory.h#L38
> 
> https://github.com/raspberrypi/linux/blob/rpi-3.18.y/arch/arm/mach-bcm2708/
> Kconfig#L43
> 
> * It's a system-wide option without any runtime control that I'm aware
> of, and so would affect anything U-Boot boots such as Linux, so Linux
> would need to be modified too. I assume it would reduce graphics
> performance at least.
> 
> As such, I don't think we want to require that option.

Agreed.

Best regards,
Marek Vasut

  reply	other threads:[~2015-03-13 18:49 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 [this message]
2015-03-13 17:02 ` Eric Anholt
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=201503131949.49519.marex@denx.de \
    --to=marex@denx.de \
    --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