AuxXxilium/linux_dsm_epyc7002
1
0
Fork 0
mirror of https://github.com/AuxXxilium/linux_dsm_epyc7002.git synced 2024-12-16 12:46:55 +07:00
Code Issues Actions Packages Projects Releases Wiki Activity
31f3010e60
linux_dsm_epyc7002/arch/arm/mach-orion5x/orion5x.h

147 lines
5.6 KiB
C
Raw Normal View History

Orion: orion -> orion5x rename Do a global s/orion/orion5x/ of the Orion 5x-specific bits (i.e. not the plat-orion bits.) Signed-off-by: Lennert Buytenhek <buytenh@marvell.com> Reviewed-by: Tzachi Perelstein <tzachi@marvell.com> Acked-by: Saeed Bishara <saeed@marvell.com> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Nicolas Pitre <nico@marvell.com>
2008-03-28 01:51:41 +07:00
/*
* Generic definitions of Orion SoC flavors:
[ARM] Orion: add 88F6183 (Orion-1-90) support The Orion-1-90 (88F6183) is another member of the Orion SoC family, which has a 16 bit DDR2 interface, one x1 PCIe port (configurable as Root Complex or Endpoint), one 10/100/1000 ethernet interface, one USB 2.0 port with PHY, one SPDIF/I2S interface, one SDIO interface, one TWSI interface, two UARTs, one SPI interface, a NAND controller, a crypto engine, and a 4-channel DMA engine. Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
2008-08-29 11:55:06 +07:00
* Orion-1, Orion-VoIP, Orion-NAS, Orion-2, and Orion-1-90.
Orion: orion -> orion5x rename Do a global s/orion/orion5x/ of the Orion 5x-specific bits (i.e. not the plat-orion bits.) Signed-off-by: Lennert Buytenhek <buytenh@marvell.com> Reviewed-by: Tzachi Perelstein <tzachi@marvell.com> Acked-by: Saeed Bishara <saeed@marvell.com> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Nicolas Pitre <nico@marvell.com>
2008-03-28 01:51:41 +07:00
*
* Maintainer: Tzachi Perelstein <tzachi@marvell.com>
*
* This file is licensed under the terms of the GNU General Public
* License version 2. This program is licensed "as is" without any
* warranty of any kind, whether express or implied.
*/
#ifndef __ASM_ARCH_ORION5X_H
#define __ASM_ARCH_ORION5X_H
ARM: orion5x: clean up mach/*.h headers This is a simple move of all header files that are no longer included by anything else from the include/mach directory to the platform directory itself as preparation for multiplatform support. The mach/uncompress.h headers are left in place for now, and are mildly modified to be independent of the other headers. They will be removed entirely when ARCH_MULTIPLATFORM gets enabled and they become obsolete. Rather than updating the path names inside of the comments of each header, I delete those comments to avoid having to update them again, should they get moved or copied another time. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
2015-12-03 04:27:08 +07:00
#include "irqs.h"
ARM: orion: use SPARSE_IRQ everywhere As a preparation for multiplatform support, this moves all the code using plat-orion over to use sparse irq support, which is enabled implicitly for multiplatform. In particular, the hardcoded NR_IRQS macro gets replaced with a machine specific one that is set in the machine descriptor in order to set up a static mapping for all legacy interrupts. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
2015-12-03 04:27:05 +07:00
Orion: orion -> orion5x rename Do a global s/orion/orion5x/ of the Orion 5x-specific bits (i.e. not the plat-orion bits.) Signed-off-by: Lennert Buytenhek <buytenh@marvell.com> Reviewed-by: Tzachi Perelstein <tzachi@marvell.com> Acked-by: Saeed Bishara <saeed@marvell.com> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Nicolas Pitre <nico@marvell.com>
2008-03-28 01:51:41 +07:00
/*****************************************************************************
* Orion Address Maps
*
* phys
* e0000000 PCIe MEM space
* e8000000 PCI MEM space
* f0000000 PCIe WA space (Orion-1/Orion-NAS only)
* f1000000 on-chip peripheral registers
* f2000000 PCIe I/O space
* f2100000 PCI I/O space
[ARM] orion5x: add sram support for crypto The security accelerator which can act as a puppet player for the crypto engine requires its commands in the sram. This patch adds support for the phys mapping and creates a platform device for the actual driver. [ nico: renamed device name from "mv,orion5x-crypto" to "mv_crypto" so to match the module name and be more generic for Kirkwood use ] Signed-off-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc> Signed-off-by: Nicolas Pitre <nico@marvell.com>
2009-05-08 03:59:24 +07:00
* f2200000 SRAM dedicated for the crypto unit
Orion: orion -> orion5x rename Do a global s/orion/orion5x/ of the Orion 5x-specific bits (i.e. not the plat-orion bits.) Signed-off-by: Lennert Buytenhek <buytenh@marvell.com> Reviewed-by: Tzachi Perelstein <tzachi@marvell.com> Acked-by: Saeed Bishara <saeed@marvell.com> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Nicolas Pitre <nico@marvell.com>
2008-03-28 01:51:41 +07:00
* f4000000 device bus mappings (boot)
* fa000000 device bus mappings (cs0)
* fa800000 device bus mappings (cs2)
* fc000000 device bus mappings (cs0/cs1)
*
* virt phys size
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>
2019-08-01 02:56:55 +07:00
* fec00000 f1000000 1M on-chip peripheral registers
ARM: orion5x: use fixed PCI i/o mapping Move orion5x PCI to fixed i/o mapping and remove io.h. Signed-off-by: Rob Herring <rob.herring@calxeda.com> Cc: Lennert Buytenhek <kernel@wantstofly.org> Acked-by: Nicolas Pitre <nico@linaro.org> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Arnd Bergmann <arnd@arndb.de>
2012-07-06 22:59:30 +07:00
* fee00000 f2000000 64K PCIe I/O space
* fee10000 f2100000 64K PCI I/O space
* fd000000 f0000000 16M PCIe WA space (Orion-1/Orion-NAS only)
Orion: orion -> orion5x rename Do a global s/orion/orion5x/ of the Orion 5x-specific bits (i.e. not the plat-orion bits.) Signed-off-by: Lennert Buytenhek <buytenh@marvell.com> Reviewed-by: Tzachi Perelstein <tzachi@marvell.com> Acked-by: Saeed Bishara <saeed@marvell.com> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Nicolas Pitre <nico@marvell.com>
2008-03-28 01:51:41 +07:00
****************************************************************************/
#define ORION5X_REGS_PHYS_BASE 0xf1000000
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>
2019-08-01 02:56:55 +07:00
#define ORION5X_REGS_VIRT_BASE IOMEM(0xfec00000)
Orion: orion -> orion5x rename Do a global s/orion/orion5x/ of the Orion 5x-specific bits (i.e. not the plat-orion bits.) Signed-off-by: Lennert Buytenhek <buytenh@marvell.com> Reviewed-by: Tzachi Perelstein <tzachi@marvell.com> Acked-by: Saeed Bishara <saeed@marvell.com> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Nicolas Pitre <nico@marvell.com>
2008-03-28 01:51:41 +07:00
#define ORION5X_REGS_SIZE SZ_1M
#define ORION5X_PCIE_IO_PHYS_BASE 0xf2000000
#define ORION5X_PCIE_IO_BUS_BASE 0x00000000
ARM: orion5x: use fixed PCI i/o mapping Move orion5x PCI to fixed i/o mapping and remove io.h. Signed-off-by: Rob Herring <rob.herring@calxeda.com> Cc: Lennert Buytenhek <kernel@wantstofly.org> Acked-by: Nicolas Pitre <nico@linaro.org> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Arnd Bergmann <arnd@arndb.de>
2012-07-06 22:59:30 +07:00
#define ORION5X_PCIE_IO_SIZE SZ_64K
Orion: orion -> orion5x rename Do a global s/orion/orion5x/ of the Orion 5x-specific bits (i.e. not the plat-orion bits.) Signed-off-by: Lennert Buytenhek <buytenh@marvell.com> Reviewed-by: Tzachi Perelstein <tzachi@marvell.com> Acked-by: Saeed Bishara <saeed@marvell.com> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Nicolas Pitre <nico@marvell.com>
2008-03-28 01:51:41 +07:00
#define ORION5X_PCI_IO_PHYS_BASE 0xf2100000
ARM: orion5x: use fixed PCI i/o mapping Move orion5x PCI to fixed i/o mapping and remove io.h. Signed-off-by: Rob Herring <rob.herring@calxeda.com> Cc: Lennert Buytenhek <kernel@wantstofly.org> Acked-by: Nicolas Pitre <nico@linaro.org> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Arnd Bergmann <arnd@arndb.de>
2012-07-06 22:59:30 +07:00
#define ORION5X_PCI_IO_BUS_BASE 0x00010000
#define ORION5X_PCI_IO_SIZE SZ_64K
Orion: orion -> orion5x rename Do a global s/orion/orion5x/ of the Orion 5x-specific bits (i.e. not the plat-orion bits.) Signed-off-by: Lennert Buytenhek <buytenh@marvell.com> Reviewed-by: Tzachi Perelstein <tzachi@marvell.com> Acked-by: Saeed Bishara <saeed@marvell.com> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Nicolas Pitre <nico@marvell.com>
2008-03-28 01:51:41 +07:00
[ARM] orion5x: add sram support for crypto The security accelerator which can act as a puppet player for the crypto engine requires its commands in the sram. This patch adds support for the phys mapping and creates a platform device for the actual driver. [ nico: renamed device name from "mv,orion5x-crypto" to "mv_crypto" so to match the module name and be more generic for Kirkwood use ] Signed-off-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc> Signed-off-by: Nicolas Pitre <nico@marvell.com>
2009-05-08 03:59:24 +07:00
#define ORION5X_SRAM_PHYS_BASE (0xf2200000)
#define ORION5X_SRAM_SIZE SZ_8K
Orion: orion -> orion5x rename Do a global s/orion/orion5x/ of the Orion 5x-specific bits (i.e. not the plat-orion bits.) Signed-off-by: Lennert Buytenhek <buytenh@marvell.com> Reviewed-by: Tzachi Perelstein <tzachi@marvell.com> Acked-by: Saeed Bishara <saeed@marvell.com> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Nicolas Pitre <nico@marvell.com>
2008-03-28 01:51:41 +07:00
/* Relevant only for Orion-1/Orion-NAS */
#define ORION5X_PCIE_WA_PHYS_BASE 0xf0000000
Merge branch 'kirkwood/addr_decode' of git://git.infradead.org/users/jcooper/linux into late/kirkwood * 'kirkwood/addr_decode' of git://git.infradead.org/users/jcooper/linux: arm: mvebu: add address decoding controller to the DT arm: mvebu: add basic address decoding support to Armada 370/XP arm: plat-orion: make bridge_virt_base non-const to support DT use case arm: plat-orion: introduce PLAT_ORION_LEGACY hidden config option arm: plat-orion: use void __iomem pointers for addr-map functions arm: plat-orion: use void __iomem pointers for time functions arm: plat-orion: use void __iomem pointers for MPP functions arm: plat-orion: use void __iomem pointers for UART registration functions arm: mach-mvebu: use IOMEM() for base address definitions arm: mach-orion5x: use IOMEM() for base address definitions arm: mach-mv78xx0: use IOMEM() for base address definitions arm: mach-kirkwood: use IOMEM() for base address definitions arm: mach-dove: use IOMEM() for base address definitions arm: mach-orion5x: use plus instead of or for address definitions arm: mach-mv78xx0: use plus instead of or for address definitions arm: mach-kirkwood: use plus instead of or for address definitions arm: mach-dove: use plus instead of or for address definitions This branch had quite a few conflicts, in particular with the PCI static map rework from Rob Herring, and a few other context conflicts due to changes in Kconfig, etc. I fixed up conflicts in: arch/arm/Kconfig arch/arm/mach-dove/common.c arch/arm/mach-dove/include/mach/dove.h arch/arm/mach-kirkwood/common.c arch/arm/mach-kirkwood/include/mach/kirkwood.h arch/arm/mach-mv78xx0/common.c arch/arm/mach-mv78xx0/include/mach/mv78xx0.h arch/arm/mach-orion5x/common.c arch/arm/mach-orion5x/include/mach/orion5x.h Signed-off-by: Olof Johansson <olof@lixom.net>
2012-09-23 04:09:21 +07:00
#define ORION5X_PCIE_WA_VIRT_BASE IOMEM(0xfd000000)
Orion: orion -> orion5x rename Do a global s/orion/orion5x/ of the Orion 5x-specific bits (i.e. not the plat-orion bits.) Signed-off-by: Lennert Buytenhek <buytenh@marvell.com> Reviewed-by: Tzachi Perelstein <tzachi@marvell.com> Acked-by: Saeed Bishara <saeed@marvell.com> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Nicolas Pitre <nico@marvell.com>
2008-03-28 01:51:41 +07:00
#define ORION5X_PCIE_WA_SIZE SZ_16M
#define ORION5X_PCIE_MEM_PHYS_BASE 0xe0000000
#define ORION5X_PCIE_MEM_SIZE SZ_128M
#define ORION5X_PCI_MEM_PHYS_BASE 0xe8000000
#define ORION5X_PCI_MEM_SIZE SZ_128M
/*******************************************************************************
* Orion Registers Map
******************************************************************************/
[ARM] 5460/1: Orion: reduce namespace pollution Symbols like SOFT_RESET are way too generic to be exported at large. To avoid this, let's move the mbus bridge register defines into a separate file and include it where needed. This affects mach-kirkwood, mach-loki, mach-mv78xx0 and mach-orion5x simultaneously as they all share code in plat-orion which relies on those defines. Some other defines have been moved to narrower scopes, or simply deleted when they had no user. This fixes compilation problem with mpt2sas on the above listed platforms. Signed-off-by: Nicolas Pitre <nico@marvell.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2009-04-23 02:08:17 +07:00
arm: mach-orion5x: convert to use mvebu-mbus driver This commit migrates the mach-orion5x platforms to use the mvebu-mbus driver and therefore removes the Orion5x-specific addr-map code. The dove_init_early() function now initializes the mvebu-mbus driver by calling mvebu_mbus_init(). We also convert a number of orion5x_setup_xyz_win() calls to the appropriate mvebu_mbus_add_window() calls, as each board was doing its own setup for the NOR window or other devices. Ultimately, those devices will be probed from the DT. The common address decoding windows are now registered in the orion5x_setup_wins() function. It is worth noting that the four PCIe address decoding windows will ultimately no longer have to be registered here: it will be done automatically by the PCIe driver once Dove has been migrated to use the upcoming mvebu PCIe driver. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2013-03-21 23:59:18 +07:00
#define ORION5X_DDR_PHYS_BASE (ORION5X_REGS_PHYS_BASE + 0x00000)
#define ORION5X_DDR_WINS_BASE (ORION5X_DDR_PHYS_BASE + 0x1500)
#define ORION5X_DDR_WINS_SZ (0x10)
arm: mach-orion5x: use plus instead of or for address definitions Since we are going to use IOMEM() to define many base virtual addresses, we can no longer use binary or to define the individual register addresses ("binary or" arithmetic on pointers is not allowed). Instead, use the more conventional plus operator to do so. The binary or operators were actually not useful because the low-order bits of the base address were always zero, so the usage of the binary or operators was effectively identical to a plus operator. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Tested-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2012-09-11 19:27:17 +07:00
#define ORION5X_DDR_VIRT_BASE (ORION5X_REGS_VIRT_BASE + 0x00000)
#define ORION5X_DEV_BUS_PHYS_BASE (ORION5X_REGS_PHYS_BASE + 0x10000)
#define ORION5X_DEV_BUS_VIRT_BASE (ORION5X_REGS_VIRT_BASE + 0x10000)
#define ORION5X_DEV_BUS_REG(x) (ORION5X_DEV_BUS_VIRT_BASE + (x))
ARM: Remove dependency of plat-orion GPIO code on mach directory includes. This patch makes the various mach dirs that use the plat-orion GPIO code pass in GPIO-related platform info (GPIO controller base address, secondary base IRQ number, etc) explicitly, instead of having plat-orion get those values by including a mach dir include file -- the latter mechanism is problematic if you want to support multiple ARM platforms in the same kernel image. Signed-off-by: Lennert Buytenhek <buytenh@secretlab.ca> Signed-off-by: Nicolas Pitre <nico@fluxnic.net>
2010-12-14 18:54:03 +07:00
#define GPIO_VIRT_BASE ORION5X_DEV_BUS_REG(0x0100)
arm: mach-orion5x: use plus instead of or for address definitions Since we are going to use IOMEM() to define many base virtual addresses, we can no longer use binary or to define the individual register addresses ("binary or" arithmetic on pointers is not allowed). Instead, use the more conventional plus operator to do so. The binary or operators were actually not useful because the low-order bits of the base address were always zero, so the usage of the binary or operators was effectively identical to a plus operator. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Tested-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2012-09-11 19:27:17 +07:00
#define SPI_PHYS_BASE (ORION5X_DEV_BUS_PHYS_BASE + 0x0600)
#define I2C_PHYS_BASE (ORION5X_DEV_BUS_PHYS_BASE + 0x1000)
#define UART0_PHYS_BASE (ORION5X_DEV_BUS_PHYS_BASE + 0x2000)
#define UART0_VIRT_BASE (ORION5X_DEV_BUS_VIRT_BASE + 0x2000)
#define UART1_PHYS_BASE (ORION5X_DEV_BUS_PHYS_BASE + 0x2100)
#define UART1_VIRT_BASE (ORION5X_DEV_BUS_VIRT_BASE + 0x2100)
Orion: orion -> orion5x rename Do a global s/orion/orion5x/ of the Orion 5x-specific bits (i.e. not the plat-orion bits.) Signed-off-by: Lennert Buytenhek <buytenh@marvell.com> Reviewed-by: Tzachi Perelstein <tzachi@marvell.com> Acked-by: Saeed Bishara <saeed@marvell.com> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Nicolas Pitre <nico@marvell.com>
2008-03-28 01:51:41 +07:00
arm: mach-orion5x: use plus instead of or for address definitions Since we are going to use IOMEM() to define many base virtual addresses, we can no longer use binary or to define the individual register addresses ("binary or" arithmetic on pointers is not allowed). Instead, use the more conventional plus operator to do so. The binary or operators were actually not useful because the low-order bits of the base address were always zero, so the usage of the binary or operators was effectively identical to a plus operator. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Tested-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2012-09-11 19:27:17 +07:00
#define ORION5X_BRIDGE_VIRT_BASE (ORION5X_REGS_VIRT_BASE + 0x20000)
#define ORION5X_BRIDGE_PHYS_BASE (ORION5X_REGS_PHYS_BASE + 0x20000)
arm: mach-orion5x: convert to use mvebu-mbus driver This commit migrates the mach-orion5x platforms to use the mvebu-mbus driver and therefore removes the Orion5x-specific addr-map code. The dove_init_early() function now initializes the mvebu-mbus driver by calling mvebu_mbus_init(). We also convert a number of orion5x_setup_xyz_win() calls to the appropriate mvebu_mbus_add_window() calls, as each board was doing its own setup for the NOR window or other devices. Ultimately, those devices will be probed from the DT. The common address decoding windows are now registered in the orion5x_setup_wins() function. It is worth noting that the four PCIe address decoding windows will ultimately no longer have to be registered here: it will be done automatically by the PCIe driver once Dove has been migrated to use the upcoming mvebu PCIe driver. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2013-03-21 23:59:18 +07:00
#define ORION5X_BRIDGE_WINS_BASE (ORION5X_BRIDGE_PHYS_BASE)
#define ORION5X_BRIDGE_WINS_SZ (0x80)
Orion: orion -> orion5x rename Do a global s/orion/orion5x/ of the Orion 5x-specific bits (i.e. not the plat-orion bits.) Signed-off-by: Lennert Buytenhek <buytenh@marvell.com> Reviewed-by: Tzachi Perelstein <tzachi@marvell.com> Acked-by: Saeed Bishara <saeed@marvell.com> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Nicolas Pitre <nico@marvell.com>
2008-03-28 01:51:41 +07:00
arm: mach-orion5x: use plus instead of or for address definitions Since we are going to use IOMEM() to define many base virtual addresses, we can no longer use binary or to define the individual register addresses ("binary or" arithmetic on pointers is not allowed). Instead, use the more conventional plus operator to do so. The binary or operators were actually not useful because the low-order bits of the base address were always zero, so the usage of the binary or operators was effectively identical to a plus operator. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Tested-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2012-09-11 19:27:17 +07:00
#define ORION5X_PCI_VIRT_BASE (ORION5X_REGS_VIRT_BASE + 0x30000)
Orion: orion -> orion5x rename Do a global s/orion/orion5x/ of the Orion 5x-specific bits (i.e. not the plat-orion bits.) Signed-off-by: Lennert Buytenhek <buytenh@marvell.com> Reviewed-by: Tzachi Perelstein <tzachi@marvell.com> Acked-by: Saeed Bishara <saeed@marvell.com> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Nicolas Pitre <nico@marvell.com>
2008-03-28 01:51:41 +07:00
arm: mach-orion5x: use plus instead of or for address definitions Since we are going to use IOMEM() to define many base virtual addresses, we can no longer use binary or to define the individual register addresses ("binary or" arithmetic on pointers is not allowed). Instead, use the more conventional plus operator to do so. The binary or operators were actually not useful because the low-order bits of the base address were always zero, so the usage of the binary or operators was effectively identical to a plus operator. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Tested-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2012-09-11 19:27:17 +07:00
#define ORION5X_PCIE_VIRT_BASE (ORION5X_REGS_VIRT_BASE + 0x40000)
Orion: orion -> orion5x rename Do a global s/orion/orion5x/ of the Orion 5x-specific bits (i.e. not the plat-orion bits.) Signed-off-by: Lennert Buytenhek <buytenh@marvell.com> Reviewed-by: Tzachi Perelstein <tzachi@marvell.com> Acked-by: Saeed Bishara <saeed@marvell.com> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Nicolas Pitre <nico@marvell.com>
2008-03-28 01:51:41 +07:00
arm: mach-orion5x: use plus instead of or for address definitions Since we are going to use IOMEM() to define many base virtual addresses, we can no longer use binary or to define the individual register addresses ("binary or" arithmetic on pointers is not allowed). Instead, use the more conventional plus operator to do so. The binary or operators were actually not useful because the low-order bits of the base address were always zero, so the usage of the binary or operators was effectively identical to a plus operator. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Tested-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2012-09-11 19:27:17 +07:00
#define ORION5X_USB0_PHYS_BASE (ORION5X_REGS_PHYS_BASE + 0x50000)
#define ORION5X_USB0_VIRT_BASE (ORION5X_REGS_VIRT_BASE + 0x50000)
Orion: orion -> orion5x rename Do a global s/orion/orion5x/ of the Orion 5x-specific bits (i.e. not the plat-orion bits.) Signed-off-by: Lennert Buytenhek <buytenh@marvell.com> Reviewed-by: Tzachi Perelstein <tzachi@marvell.com> Acked-by: Saeed Bishara <saeed@marvell.com> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Nicolas Pitre <nico@marvell.com>
2008-03-28 01:51:41 +07:00
arm: mach-orion5x: use plus instead of or for address definitions Since we are going to use IOMEM() to define many base virtual addresses, we can no longer use binary or to define the individual register addresses ("binary or" arithmetic on pointers is not allowed). Instead, use the more conventional plus operator to do so. The binary or operators were actually not useful because the low-order bits of the base address were always zero, so the usage of the binary or operators was effectively identical to a plus operator. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Tested-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2012-09-11 19:27:17 +07:00
#define ORION5X_XOR_PHYS_BASE (ORION5X_REGS_PHYS_BASE + 0x60900)
#define ORION5X_XOR_VIRT_BASE (ORION5X_REGS_VIRT_BASE + 0x60900)
[ARM] Orion: Instantiate mv_xor driver for 5182 Signed-off-by: Saeed Bishara <saeed@marvell.com> Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
2008-06-17 17:25:12 +07:00
arm: mach-orion5x: use plus instead of or for address definitions Since we are going to use IOMEM() to define many base virtual addresses, we can no longer use binary or to define the individual register addresses ("binary or" arithmetic on pointers is not allowed). Instead, use the more conventional plus operator to do so. The binary or operators were actually not useful because the low-order bits of the base address were always zero, so the usage of the binary or operators was effectively identical to a plus operator. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Tested-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2012-09-11 19:27:17 +07:00
#define ORION5X_ETH_PHYS_BASE (ORION5X_REGS_PHYS_BASE + 0x70000)
#define ORION5X_ETH_VIRT_BASE (ORION5X_REGS_VIRT_BASE + 0x70000)
Orion: orion -> orion5x rename Do a global s/orion/orion5x/ of the Orion 5x-specific bits (i.e. not the plat-orion bits.) Signed-off-by: Lennert Buytenhek <buytenh@marvell.com> Reviewed-by: Tzachi Perelstein <tzachi@marvell.com> Acked-by: Saeed Bishara <saeed@marvell.com> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Nicolas Pitre <nico@marvell.com>
2008-03-28 01:51:41 +07:00
arm: mach-orion5x: use plus instead of or for address definitions Since we are going to use IOMEM() to define many base virtual addresses, we can no longer use binary or to define the individual register addresses ("binary or" arithmetic on pointers is not allowed). Instead, use the more conventional plus operator to do so. The binary or operators were actually not useful because the low-order bits of the base address were always zero, so the usage of the binary or operators was effectively identical to a plus operator. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Tested-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2012-09-11 19:27:17 +07:00
#define ORION5X_SATA_PHYS_BASE (ORION5X_REGS_PHYS_BASE + 0x80000)
#define ORION5X_SATA_VIRT_BASE (ORION5X_REGS_VIRT_BASE + 0x80000)
Orion: orion -> orion5x rename Do a global s/orion/orion5x/ of the Orion 5x-specific bits (i.e. not the plat-orion bits.) Signed-off-by: Lennert Buytenhek <buytenh@marvell.com> Reviewed-by: Tzachi Perelstein <tzachi@marvell.com> Acked-by: Saeed Bishara <saeed@marvell.com> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Nicolas Pitre <nico@marvell.com>
2008-03-28 01:51:41 +07:00
arm: mach-orion5x: use plus instead of or for address definitions Since we are going to use IOMEM() to define many base virtual addresses, we can no longer use binary or to define the individual register addresses ("binary or" arithmetic on pointers is not allowed). Instead, use the more conventional plus operator to do so. The binary or operators were actually not useful because the low-order bits of the base address were always zero, so the usage of the binary or operators was effectively identical to a plus operator. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Tested-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2012-09-11 19:27:17 +07:00
#define ORION5X_CRYPTO_PHYS_BASE (ORION5X_REGS_PHYS_BASE + 0x90000)
[ARM] orion5x: add sram support for crypto The security accelerator which can act as a puppet player for the crypto engine requires its commands in the sram. This patch adds support for the phys mapping and creates a platform device for the actual driver. [ nico: renamed device name from "mv,orion5x-crypto" to "mv_crypto" so to match the module name and be more generic for Kirkwood use ] Signed-off-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc> Signed-off-by: Nicolas Pitre <nico@marvell.com>
2009-05-08 03:59:24 +07:00
arm: mach-orion5x: use plus instead of or for address definitions Since we are going to use IOMEM() to define many base virtual addresses, we can no longer use binary or to define the individual register addresses ("binary or" arithmetic on pointers is not allowed). Instead, use the more conventional plus operator to do so. The binary or operators were actually not useful because the low-order bits of the base address were always zero, so the usage of the binary or operators was effectively identical to a plus operator. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Tested-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2012-09-11 19:27:17 +07:00
#define ORION5X_USB1_PHYS_BASE (ORION5X_REGS_PHYS_BASE + 0xa0000)
#define ORION5X_USB1_VIRT_BASE (ORION5X_REGS_VIRT_BASE + 0xa0000)
Orion: orion -> orion5x rename Do a global s/orion/orion5x/ of the Orion 5x-specific bits (i.e. not the plat-orion bits.) Signed-off-by: Lennert Buytenhek <buytenh@marvell.com> Reviewed-by: Tzachi Perelstein <tzachi@marvell.com> Acked-by: Saeed Bishara <saeed@marvell.com> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Nicolas Pitre <nico@marvell.com>
2008-03-28 01:51:41 +07:00
/*******************************************************************************
* Device Bus Registers
******************************************************************************/
#define MPP_0_7_CTRL ORION5X_DEV_BUS_REG(0x000)
#define MPP_8_15_CTRL ORION5X_DEV_BUS_REG(0x004)
#define MPP_16_19_CTRL ORION5X_DEV_BUS_REG(0x050)
#define MPP_DEV_CTRL ORION5X_DEV_BUS_REG(0x008)
#define MPP_RESET_SAMPLE ORION5X_DEV_BUS_REG(0x010)
#define DEV_BANK_0_PARAM ORION5X_DEV_BUS_REG(0x45c)
#define DEV_BANK_1_PARAM ORION5X_DEV_BUS_REG(0x460)
#define DEV_BANK_2_PARAM ORION5X_DEV_BUS_REG(0x464)
#define DEV_BANK_BOOT_PARAM ORION5X_DEV_BUS_REG(0x46c)
#define DEV_BUS_CTRL ORION5X_DEV_BUS_REG(0x4c0)
#define DEV_BUS_INT_CAUSE ORION5X_DEV_BUS_REG(0x4d0)
#define DEV_BUS_INT_MASK ORION5X_DEV_BUS_REG(0x4d4)
[ARM] 5460/1: Orion: reduce namespace pollution Symbols like SOFT_RESET are way too generic to be exported at large. To avoid this, let's move the mbus bridge register defines into a separate file and include it where needed. This affects mach-kirkwood, mach-loki, mach-mv78xx0 and mach-orion5x simultaneously as they all share code in plat-orion which relies on those defines. Some other defines have been moved to narrower scopes, or simply deleted when they had no user. This fixes compilation problem with mpt2sas on the above listed platforms. Signed-off-by: Nicolas Pitre <nico@marvell.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2009-04-23 02:08:17 +07:00
/*******************************************************************************
* Supported Devices & Revisions
******************************************************************************/
/* Orion-1 (88F5181) and Orion-VoIP (88F5181L) */
#define MV88F5181_DEV_ID 0x5181
#define MV88F5181_REV_B1 3
#define MV88F5181L_REV_A0 8
#define MV88F5181L_REV_A1 9
/* Orion-NAS (88F5182) */
#define MV88F5182_DEV_ID 0x5182
#define MV88F5182_REV_A2 2
/* Orion-2 (88F5281) */
#define MV88F5281_DEV_ID 0x5281
#define MV88F5281_REV_D0 4
#define MV88F5281_REV_D1 5
#define MV88F5281_REV_D2 6
/* Orion-1-90 (88F6183) */
#define MV88F6183_DEV_ID 0x6183
#define MV88F6183_REV_B0 3
Orion: orion -> orion5x rename Do a global s/orion/orion5x/ of the Orion 5x-specific bits (i.e. not the plat-orion bits.) Signed-off-by: Lennert Buytenhek <buytenh@marvell.com> Reviewed-by: Tzachi Perelstein <tzachi@marvell.com> Acked-by: Saeed Bishara <saeed@marvell.com> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Nicolas Pitre <nico@marvell.com>
2008-03-28 01:51:41 +07:00
#endif
Reference in New Issue Copy Permalink