Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 25 5月, 2015 1 次提交
  3. 08 4月, 2015 1 次提交
    • T
      ARM: mvebu: use 0xf1000000 as internal registers on Armada 370 DB · 4f054d44
      由 Thomas Petazzoni 提交于 
      All Marvell EBU SoCs (Kirkwood, Dove, Orion, Armada) have the
capability of changing the location of their internal registers (i.e
the registers for most hardware blocks inside the SoC). When coming
out of reset, the internal registers are mapped at 0xd0000000, but
since years and years, the tradition has been to have the internal
registers remapped at 0xf1000000 by the bootloader, and Linux has
since then assumed that the internal registers for the SoC were
located at 0xf1000000 on Kirkwood, Dove, Orion, etc. Linux has never
been aware that those registers are remappable (and there is no way to
know where they are mapped at runtime, since the register to configure
the address of the registers is itself within the internal registers).

Then came the Armada 370 and Armada XP, in which some of the very
early silicon steppings had an issue, which forced to use 0xd0000000:
the SoC was no longer working properly when the internal registers
were remapped at 0xf1000000. This issue is only affecting very early
silicon steppings and production steppings are not affected: the issue
has been fixed in between.

Since what we (Free Electrons) used to do the initial submission of
the Armada 370 and Armada XP platforms was evaluation boards with
those very early steppings, we submitted Device Tree that assumed the
internal registers were mapped at 0xd0000000. This is the case for
Armada 370 DB, Armada XP DB and Armada XP GP.

However, in practice, since Marvell has been shipping the evaluation
boards with production steppings of the SoC, they are shipping those
boards with bootloaders that remap the registers to 0xf1000000. We
have already changed this internal register address to 0xf1000000 for
the Armada XP DB in commit 82066bdb and for the Armada XP GP in
commit 91ed3220 (both merged in v3.15).

We only recently got our hand on an Armada 370 DB with a production
stepping of the SoC, which uses a bootloader that remaps internal
registers at 0xf1000000. Therefore, this commit aligns the Armada 370
DB to be like the Armada XP DB and Armada XP GP: assume that the
internal registers are mapped at 0xf1000000.

We would like to stress out the fact that the usage of 0xd0000000 as
the internal register base address was a temporary workaround for
early steppings deficiencies, and that the real long-term solution is
the usage of 0xf1000000. Having 0xd0000000 is an *accident* in the
life of the Marvell platform support in the kernel, as is confirmed by
the usage of 0xf1000000 in all previous Marvell platforms (Dove,
Kirkwood, Orion).

There are unfortunately a number of commercial devices that continue
to use 0xd0000000 even though they use production steppings of the
SoC, simply because the vendors of such devices have never bothered
using a more recent bootloader version from Marvell. There is not much
we can do about it, and we plan on keeping 0xd0000000 in the Device
Tree of such devices.

The main reason for remapping the internal registers at 0xf1000000
instead of 0xd0000000 is that it leaves more space in the 0 -> 4 GB
part of the physical address space for RAM. With registers at
0xd0000000, all RAM between 0xd0000000 to 0xffffffff is lost because
it's covered by the I/O registers.
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: NAndrew Lunn <andrew@lunn.ch>
Acked-by: NJason Cooper <jason@lakedameon.net>
Acked-by: NGregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: NGregory CLEMENT <gregory.clement@free-electrons.com>
      4f054d44
  5. 04 3月, 2015 1 次提交
  7. 27 1月, 2015 1 次提交
  9. 21 12月, 2014 1 次提交
    • G
      ARM: mvebu: Fix pinctrl configuration for Armada 370 DB · d4b0833a
      由 Gregory CLEMENT 提交于 
      The commit b4607572 (ARM: mvebu: remove conflicting muxing on
Armada 370 DB) removes the hog pins muxing. As it is explained in the
commit log it solves a warning a boot time, but more important it also
allows using the Giga port 0 of the board.

Unfortunately in the same time the commit 4904a82a (arm: mvebu:
move Armada 370/XP pinctrl node definition armada-370-xp.dtsi) was
merged and it introduced again the hog pins muxing. Because of it, the
Giga port 0 of the board is no more usable.

This commit remove again the conflicting muxing (hopefully for the
last time).
Signed-off-by: NGregory CLEMENT <gregory.clement@free-electrons.com>
[andrew@lunn.ch: Correct commit IDs]
Signed-off-by: NAndrew Lunn <andrew@lunn.ch>
Fixes: 4904a82a ("arm: mvebu: move Armada 370/XP pinctrl node definition armada-370-xp.dtsi")
      d4b0833a
  11. 22 11月, 2014 2 次提交
  13. 07 11月, 2014 2 次提交
  15. 18 8月, 2014 1 次提交
  17. 26 4月, 2014 2 次提交
  19. 17 2月, 2014 2 次提交
  21. 26 11月, 2013 1 次提交
    • T
      ARM: mvebu: re-enable PCIe on Armada 370 DB · 96039f73
      由 Thomas Petazzoni 提交于 
      Commit 14fd8ed0 ("ARM: mvebu: Relocate Armada 370/XP PCIe
device tree nodes") relocated the PCIe controller DT nodes one level
up in the Device Tree, to reflect a more correct representation of the
hardware introduced by the mvebu-mbus Device Tree binding.

However, while most of the boards were properly adjusted accordingly,
the Armada 370 DB board was left unchanged, and therefore, PCIe is
seen as not enabled on this board. This patch fixes that by moving the
PCIe controller node one level-up in armada-370-db.dts.
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: <stable@vger.kernel.org> # v3.12+
Fixes: 14fd8ed0 "ARM: mvebu: Relocate Armada 370/XP PCIe device tree nodes"
Signed-off-by: NJason Cooper <jason@lakedaemon.net>
      96039f73
  23. 06 8月, 2013 3 次提交
  25. 15 5月, 2013 1 次提交
  27. 15 4月, 2013 3 次提交
  29. 01 3月, 2013 3 次提交
  31. 11 1月, 2013 1 次提交
  33. 21 11月, 2012 1 次提交
  35. 20 11月, 2012 2 次提交
  37. 16 11月, 2012 1 次提交
  39. 10 7月, 2012 1 次提交