Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 16 4月, 2013 1 次提交
  3. 15 4月, 2013 6 次提交
  5. 31 3月, 2013 1 次提交
  7. 22 3月, 2013 1 次提交
    • F
      mv643xx_eth: convert to use the Marvell Orion MDIO driver · c3a07134
      由 Florian Fainelli 提交于 
      This patch converts the Marvell MV643XX ethernet driver to use the
Marvell Orion MDIO driver. As a result, PowerPC and ARM platforms
registering the Marvell MV643XX ethernet driver are also updated to
register a Marvell Orion MDIO driver. This driver voluntarily overlaps
with the Marvell Ethernet shared registers because it will use a subset
of this shared register (shared_base + 0x4 to shared_base + 0x84). The
Ethernet driver is also updated to look up for a PHY device using the
Orion MDIO bus driver.

For ARM and PowerPC we register a single instance of the "mvmdio" driver
in the system like it used to be done with the use of the "shared_smi"
platform_data cookie on ARM.

Note that it is safe to register the mvmdio driver only for the "ge00"
instance of the driver because this "ge00" interface is guaranteed to
always be explicitely registered by consumers of
arch/arm/plat-orion/common.c and other instances (ge01, ge10 and ge11)
were all pointing their shared_smi to ge00. For PowerPC the in-tree
Device Tree Source files mention only one MV643XX ethernet MAC instance
so the MDIO bus driver is registered only when id == 0.
Signed-off-by: NFlorian Fainelli <florian@openwrt.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c3a07134
  9. 20 3月, 2013 1 次提交
  11. 18 3月, 2013 2 次提交
    • T
      arm: plat-orion: use mv_mbus_dram_info() in PCIe code · 59f16137
      由 Thomas Petazzoni 提交于 
      The PCIe code was directly accessing the orion_mbus_dram_info
structure to get access to a description of the SDRAM chip selects in
order to configure the PCIe -> SDRAM address decoding
windows.

However, with the introduction of the orion-mbus driver, we are going
to remove this global structure and instead leave only the exported
mv_mbus_dram_info() function to access this description of the SDRAM
chip selects. Therefore, we simply switch to using this API.
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: NJason Cooper <jason@lakedaemon.net>
      59f16137
    • T
      arm: plat-orion: only build addr-map.c when needed · efaaa98d
      由 Thomas Petazzoni 提交于 
      -flagmail-match: MVEBU
X-flagmail-match: KIRKWOOD
X-flagmail-match: DOVE

For now, addr-map.c is needed by all 5 Marvell EBU
sub-architectures. However, we are going to introduce the orion-mbus
driver, which will replace the address decoding code from
addr-map.c. In order to ease the migration process, we will do that
one sub-architecture at a time, which will require us to remove the
compilation of addr-map.c one sub-architecture at a time.

Therefore, we split the unconditional obj-y inclusion of addr-map.c
into 5 conditionals obj-$(CONFIG_...) lines, one per sub-architecture.
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: NJason Cooper <jason@lakedaemon.net>
      efaaa98d
  13. 09 3月, 2013 1 次提交
    • T
      arm: plat-orion: fix address decoding when > 4GB is used · 217bef3d
      由 Thomas Petazzoni 提交于 
      During the system initialization, the orion_setup_cpu_mbus_target()
function reads the SDRAM address decoding registers to find out how
many chip-selects of SDRAM have been enabled, and builds a small array
with one entry per chip-select. This array is then used by device
drivers (XOR, Ethernet, etc.) to configure their own address decoding
windows to the SDRAM.

However, devices can only access the first 32 bits of the physical
memory. Even though LPAE is not supported for now, some Marvell boards
are now showing up with 8 GB of RAM, configured using two SDRAM
address decoding windows: the first covering the first 4 GB, the
second covering the last 4 GB. The array built by
orion_setup_cpu_mbus_target() has therefore two entries, and device
drivers try to set up two address decoding windows to the
SDRAM. However, in the device registers for the address decoding, the
base address is only 32 bits, so those two windows overlap each other,
and the devices do not work at all.

This patch makes sure that the array built by
orion_setup_cpu_mbus_target() only contains the SDRAM decoding windows
that correspond to the first 4 GB of the memory. To do that, it
ignores the SDRAM decoding windows for which the 4 low-order bits are
not zero (the 4 low-order bits of the base register are used to store
bits 32:35 of the base address, so they actually indicate whether the
base address is above 4 GB).

This patch allows the newly introduced armada-xp-gp board to properly
operate when it is mounted with more than 4 GB of RAM. Without that,
all devices doing DMA (for example XOR and Ethernet) do not work at
all.
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: NJason Cooper <jason@lakedaemon.net>
      217bef3d
  15. 23 1月, 2013 1 次提交
  17. 15 1月, 2013 1 次提交
  19. 24 11月, 2012 1 次提交
  21. 22 11月, 2012 1 次提交
  23. 20 11月, 2012 10 次提交
  25. 29 9月, 2012 1 次提交
  27. 22 9月, 2012 6 次提交
  29. 19 9月, 2012 1 次提交
  31. 14 9月, 2012 1 次提交
  33. 15 8月, 2012 1 次提交
  35. 27 7月, 2012 2 次提交
  37. 24 6月, 2012 1 次提交
    • A
      ARM: Orion: Fix Virtual/Physical mixup with watchdog · 0fa1f060
      由 Andrew Lunn 提交于 
      The orion watchdog is expecting to be passed the physcial address of
the hardware, and will ioremap() it to give a virtual address it will
use as the base address for the hardware. However, when creating the
platform resource record, a virtual address was being used.

Add the necassary #define's so we can pass the physical address as
expected.

Tested on Kirkwood and Orion5x.

Cc: stable <stable@vger.kernel.org>
Signed-off-by: NAndrew Lunn <andrew@lunn.ch>
Signed-off-by: NOlof Johansson <olof@lixom.net>
      0fa1f060