summaryrefslogtreecommitdiffstats
path: root/drivers/gpio
diff options
context:
space:
mode:
authorArnd Bergmann <arnd@arndb.de>2019-07-31 21:56:55 +0200
committerArnd Bergmann <arnd@arndb.de>2019-08-14 19:24:58 +0200
commit3584be9ec3bfe2c12bcb40da13fa185d237bff7d (patch)
treeb6aedbac190e324bb1faf65e5fc9c94531df78df /drivers/gpio
parentARM: dove: clean up mach/*.h headers (diff)
downloadlinux-3584be9ec3bfe2c12bcb40da13fa185d237bff7d.tar.xz
linux-3584be9ec3bfe2c12bcb40da13fa185d237bff7d.zip
ARM: orion/mvebu: unify debug-ll virtual addresses
In a multiplatform configuration, enabling DEBUG_LL breaks booting on all platforms with incompatible settings. In case of the Marvell platforms of the Orion/MVEBU family, the physical addresses are all the same, we just map them at different virtual addresses, which makes it impossible to run a kernel with DEBUG_LL enabled on a combination of the merged mvebu and the legacy boardfile based platforms. This is easily solved by using the same virtual address everywhere. I picked the address that is already used by mach-mvebu for UART0: 0xfec12000. All these platforms have a 1MB region with their internal registers, almost always at physical address 0xf1000000, so I'm updating the iotable for that entry. In case of mach-dove, this is slightly trickier, as the existing mapping is 8MB and a second 8MB mapping is already at the 0xfec00000 address. I have verified from the datasheet that the last 7MB of the physical mapping are "reserved" and nothing in Linux tries to use it either. I'm putting this 1MB mapping at the same address as the others, and the second 8MB register area immediately before that. Link: https://lore.kernel.org/r/20190731195713.3150463-14-arnd@arndb.de Link: https://lore.kernel.org/linux-arm-kernel/87si3eb1z8.fsf@free-electrons.com/ Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Diffstat (limited to 'drivers/gpio')
0 files changed, 0 insertions, 0 deletions