aboutsummaryrefslogtreecommitdiffstats
path: root/arch/arm/mach-orion5x/addr-map.c
Commit message (Collapse)AuthorAge
* Fix common misspellingsLucas De Marchi2011-03-31
| | | | | | Fixes generated by 'codespell' and manually reviewed. Signed-off-by: Lucas De Marchi <lucas.demarchi@profusion.mobi>
* ¶ARM] Orion5x: fix cpu window mapping for 88f6183Lennert Buytenhek2009-08-10
| | | | | | | | | | | On the 88f6183, orion5x's setup_cpu_win() fails to ever program any mbus bridge remap registers, which causes transactions for PCI/PCIe IO/MEM space to get sent to random mbus targets. Adding a check for the 6183 in orion5x_cpu_win_can_remap() is necessary and sufficient to make PCIe wlan cards work on the 6183 reference design. Signed-off-by: Lennert Buytenhek <buytenh@marvell.com> Signed-off-by: Nicolas Pitre <nico@marvell.com>
* [ARM] orion5x: increment window counter after adding sram mappingSebastian Andrzej Siewior2009-06-15
| | | | | | | | Without incrementing the counter the next window setup will overwrite the SRAM mapping. Signed-off-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc> Signed-off-by: Nicolas Pitre <nico@marvell.com>
* [ARM] orion5x: add sram support for cryptoSebastian Andrzej Siewior2009-06-08
| | | | | | | | | | | | 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>
* [ARM] 5460/1: Orion: reduce namespace pollutionNicolas Pitre2009-04-23
| | | | | | | | | | | | | | | | | 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>
* [ARM] Convert asm/io.h to linux/io.hRussell King2008-09-06
| | | | Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* [ARM] Move include/asm-arm/arch-* to arch/arm/*/include/machRussell King2008-08-07
| | | | | | This just leaves include/asm-arm/plat-* to deal with. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* [ARM] Remove asm/hardware.h, use asm/arch/hardware.h insteadRussell King2008-08-07
| | | | | | | | | Remove includes of asm/hardware.h in addition to asm/arch/hardware.h. Then, since asm/hardware.h only exists to include asm/arch/hardware.h, update everything to directly include asm/arch/hardware.h and remove asm/hardware.h. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* [ARM] Orion: nuke orion5x_{read,write}Lennert Buytenhek2008-06-22
| | | | | | Nuke the Orion-specific orion5x_{read,write} wrappers. Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
* [ARM] Orion: DRAM mapping granularity is 64KiB, not 16MiBLennert Buytenhek2008-06-22
| | | | | | | | | | | | | The DRAM base address and size fields in the CPU's MBUS bridge have 64KiB granularity, instead of the currently used 16MiB. Since all of the currently supported MBUS peripherals support 64KiB granularity as well, this patch changes the Orion address map code to stop rounding base addresses down and sizes up to multiples of 16MiB. Found by Ke Wei <kewei@marvell.com>. Signed-off-by: Lennert Buytenhek <buytenh@marvell.com> Acked-by: Russell King <linux@arm.linux.org.uk>
* [ARM] Orion: make window setup a little more safeLennert Buytenhek2008-06-22
| | | | | | | | | | | | | | Currently, Orion window setup uses hardcoded window indexes for each of the boot/cs0/cs1/cs2/PCIe WA windows. The static window allocation used can clash if board support code will ever attempt to configure both a dev2 and a PCIe WA window, as both of those use CPU mbus window #7 at present. This patch keeps track of the last used window, and opens subsequently requested windows sequentially, starting from 4. (Windows 0-3 are used as MEM/IO windows for the PCI/PCIe buses.) Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
* [ARM] Orion: clean up addr-map.c after window setting code purgeLennert Buytenhek2008-05-09
| | | | | | | | | | This patch cleans up Orion's addr-map.c a bit after all peripheral window programming code has been moved out into the relevant drivers. Signed-off-by: Lennert Buytenhek <buytenh@marvell.com> Reviewed-by: Tzachi Perelstein <tzachi@marvell.com> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Nicolas Pitre <nico@marvell.com>
* [ARM] Orion: use mv643xx_eth driver mbus window handlingLennert Buytenhek2008-05-09
| | | | | | | | | | | Make the Orion 5x platform code use the mbus window handling code that's in the mv643xx_eth driver, instead of programming the GigE block's mbus window registers by hand. Signed-off-by: Lennert Buytenhek <buytenh@marvell.com> Reviewed-by: Tzachi Perelstein <tzachi@marvell.com> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Nicolas Pitre <nico@marvell.com>
* [ARM] Orion: catch a couple more alternative spellings of PCIeLennert Buytenhek2008-04-28
| | | | | | | Unify a couple more spellings of "PCIe" ("PCI-E", "PCIE".) Signed-off-by: Lennert Buytenhek <buytenh@marvell.com> Signed-off-by: Nicolas Pitre <nico@marvell.com>
* Orion: orion -> orion5x renameLennert Buytenhek2008-03-27
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>