[U-Boot] [RFC PATCH] usb: dwc2: handle bcm2835 phys->virt address translations

[Stephen Warren <swarren@wwwdotorg.org>]

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.