summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2017-04-04rockchip: spl: use spl_early_init() instead of spl_init()Kever Yang
Rockchip spl driver needs using spl_early_init(). Fixes: b3d2861e (spl: Remove overwrite of relocated malloc limit) Signed-off-by: Kever Yang <kever.yang@rock-chips.com> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Heiko Stuebner <heiko@sntech.de> Reviewed-by: Simon Glass <sjg@chromium.org>
2017-04-04rockchip: pinctrl: use per-SoC option names for KconfigPhilipp Tomsich
The config options for pinctrl on the RK3188, RK3288, RK3328 and RK3399 previously showed up in menuconfig with the generic string descriptor "Rockchip pin control driver" requiring one to look through the help/full description to identify which chip each menu entry was for. This change renames each option with the chip-name in the description string to make it easy to identify the configuration options in menuconfig. Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Reviewed-by: Simon Glass <sjg@chromium.org>
2017-04-04rockchip: mkimage: update rkimage to support pre-padded payloadsPhilipp Tomsich
To simplify the creation of AArch64 SPL images for the RK3399, we use the ENABLE_ARM_SOC_BOOT0_HOOK option and prepend 4 bytes of padding at the start of the text section. This makes it easy for mkimage to rewrite this word with the 'RK33' boot magic. This change brings logic to calculate the header size and allocate the header back in sync. For the RK3399 we now limit the header to before the payload (i.e. the 'header0' and the padding up to the actual image) and overwrite the first word (inserted by the boot0-hook for this purpose) with the 'RK33' magic in-place. X-AffectedPlatforms: RK3399-Q7 Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Tested-by: Klaus Goger <klaus.goger@theobroma-systems.com>
2017-04-04rockchip: spl: RK3399: use boot0 hook to create space for SPL magicPhilipp Tomsich
The SPL binary needs to be prefixed with the boot magic ('RK33' for the RK3399) on the Rockchip platform and starts execution of the instruction word following immediately after this boot magic. This poses a challenge for AArch64 (ARMv8) binaries, as the .text section would need to start on the odd address, violating natural alignment (and potentially triggering a fault for any code that tries to access 64bit values embedded in the .text section). A quick and easy fix is to have the .text section include the 'RK33' magic and pad it with a boot0 hook to insert 4 bytes of padding at the start of the section (with the intention of having mkimage overwrite this padding with the appropriate boot magic). This avoids having to modify the linker scripts or more complex logic in mkimage. X-AffectedPlatforms: RK3399-Q7 Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Tested-by: Klaus Goger <klaus.goger@theobroma-systems.com>
2017-04-04rockchip: mkimage: pad the header to 8-bytes (using a 'nop') for RK3399Philipp Tomsich
The RK3399 boot code (running as AArch64) poses a bit of a challenge for SPL image generation: * The BootROM will start execution right after the 4-byte header (at the odd instruction word loaded into SRAM at 0xff8c2004, with the 'RK33' boot magic residing at 0xff8c2000). * The default padding (during ELF generation) for AArch64 is 0x0, which is an illegal instruction and the .text section needs to be naturally aligned (someone might locate a 64bit constant relative to the section start and unaligned loads trigger a fault for all privileged modes of an ARMv8)... so we can't simply define the CONFIG_SPL_TEXT_BASE option to the odd address (0xff8c2004). * Finally, we don't want to change the values used for padding of the SPL .text section for all ARMv8 targets to the instruction word encoding 'nop', as this would affect all padding in this section and might hide errors that would otherwise quickly trigger an illegal insn exception. To deal with this situation, we modify the rkimage generation to - understand the fact that the RK3399 needs to pad the header to an 8 byte boundary using an AArch64 'nop' - the necessary logic to adjust the header_size (which controls the location where the payload is copied into the image) and to insert this padding (AArch64 insn words are always little-endian) into the image following the 4-byte header magic. X-AffectedPlatforms: RK3399-Q7 Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Tested-by: Klaus Goger <klaus.goger@theobroma-systems.com>
2017-04-04rockchip: mkimage: simplify start/size calculation for rc4_encodePhilipp Tomsich
The RC4 encoding works on full blocks, but the calculation of the starting offset and size are needlessly complicated by using a reference value known to be offset into a block by the size of the header and then correcting for the (hard-coded) size of the header (i.e. 4 bytes). We change this over to use the RK_SPL_HDR_START directly (which is known to be on a block boundary). X-AffectedPlatforms: RK3399-Q7 Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Tested-by: Klaus Goger <klaus.goger@theobroma-systems.com>
2017-04-04rockchip: configs: correct mmc env dev for rk3288 based boardsJacob Chen
we are using mmc alias , so mmc index have been changed. now mmc dev 0 is emmc and mmc dev 1 is sdmmc. Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>
2017-04-04Prepare v2017.05-rc1Tom Rini
Signed-off-by: Tom Rini <trini@konsulko.com>
2017-04-04Merge git://git.denx.de/u-boot-tegraTom Rini
2017-04-04Merge git://git.denx.de/u-boot-arcTom Rini
In this patch-set we add support of new AXS103 firmware as well as troubleshoot unexpected execution by multiple cores simultaneously.
2017-04-04Merge git://git.denx.de/u-boot-mmcTom Rini
2017-04-04Merge git://git.denx.de/u-boot-dmTom Rini
2017-04-04Merge git://www.denx.de/git/u-boot-marvellTom Rini
This includes Marvell mvpp2 patches with the ethernet support for the ARMv8 Armada 7k/8k platforms. The ethernet patches are all acked by Joe and he is okay with me pushing them via the Marvell tree.
2017-04-04Merge git://git.denx.de/u-boot-fsl-qoriqTom Rini
2017-04-04Merge branch 'master' of git://git.denx.de/u-boot-i2cTom Rini
2017-04-01apalis-tk1: disable external clock loopback on SDMMC3Marcel Ziswiler
Actually make use of that shiny new CONFIG_TEGRA124_MMC_DISABLE_EXT_LOOPBACK. Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com> Signed-off-by: Marcel Ziswiler <marcel@ziswiler.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
2017-04-01mmc: tegra: allow disabling external clock loopbackMarcel Ziswiler
Introduce CONFIG_TEGRA124_MMC_DISABLE_EXT_LOOPBACK to disable the external clock loopback and use the internal one on SDMMC3 as per the SDMMC_VENDOR_MISC_CNTRL_0 register's SDMMC_SPARE1 bits being set to 0xfffd according to the TRM. Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com> Reviewed-by: Simon Glass <sjg@chromium.org> Acked-by: Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by: Marcel Ziswiler <marcel@ziswiler.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
2017-04-01arm: tegra: initial support for apalis tk1Marcel Ziswiler
This patch adds board support for the Toradex Apalis TK1 a computer on module which can be used on different carrier boards. The module consists of a Tegra TK1 SoC, a PMIC solution, 2 GB of DDR3L RAM, a bunch of level shifters, an eMMC, a TMP451 temperature sensor chip, an I210 gigabit Ethernet controller and a SGTL5000 audio codec. Furthermore, there is a Kinetis MK20DN512 companion micro controller for analogue, CAN and resistive touch functionality. For the sake of ease of use we do not distinguish between different carrier boards for now as the base module features are deemed sufficient enough for regular booting. The following functionality is working so far: - eMMC boot, environment storage and Toradex factory config block - Gigabit Ethernet - MMC/SD cards (both MMC1 as well as SD1 slot) - USB client/host (dual role OTG port as client e.g. for DFU/UMS or host, other two ports as host) Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Marcel Ziswiler <marcel@ziswiler.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
2017-03-31arcv2: Halt non-master coresAlexey Brodkin
Even though we expect only master core to execute U-Boot code let's make sure even if for some reason slave cores attempt to execute U-Boot in parallel with master they get halted very early. If platform wants it may kick-start slave cores before passing control to say Linux kernel or any other application that want to see all cores of SMP SoC up and running. Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
2017-03-31axs103: Support slave core kick-start on axs103 v1.1 firmwareAlexey Brodkin
In axs103 v1.1 procedure to kick-start slave cores has changed quite a bit compared t previous implementation. In particular: * We used to have a generic START bit for all cores selected by CORE_SEL mask. But now we don't touch CORE_SEL at all because we have a dedicated START bit for each core: bit 0: Core 0 (master) bit 1: Core 1 (slave) * Now there's no need to select "manual" mode of core start Additional challenge for us is how to tell which axs103 firmware we're dealing with. For now we'll rely on ARC core version which was bumped from 2.1c to 3.0. Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
2017-03-31axs103: Clean-up smp_kick_all_cpus()Alexey Brodkin
* Rely on default pulse polarity value * Don't mess with "multicore" value as it doesn't affect execution In essence we now do a bare minimal stuff: 1) Select HS38x2_1 with CORE_SEL=1 bits 2) Select "manual" core start (via CREG) with START_MODE=0 3) Generate cpu_start pulse with START=1 Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
2017-03-30mmc: omap_hsmmc: add support for CONFIG_BLKJean-Jacques Hiblot
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2017-03-30mmc: omap_hsmmc: move the mmc_config to platdata when DM_MMC is usedJean-Jacques Hiblot
This is a preparation work for the support of CONFIG_BLK. Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2017-03-30mmc: omap_hsmmc: use mmc_get_blk_desc() to get the block device descJean-Jacques Hiblot
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2017-03-30mmc: omap_hsmmc: use an accessor to get the private dataJean-Jacques Hiblot
For consistency, use an accessor to access the private data. Also for the same reason, rename all priv_data to priv. Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2017-03-29arm64: mvebu: Enable CONFIG_PHY_MARVELL in Armada7k/8k-DB defconfigStefan Roese
The Marvell PHY support is needed espescially for the A7040-DB with the SGMII port (port 2). As without the marvell PHY driver configuration for SGMII, ethernet won't work. Signed-off-by: Stefan Roese <sr@denx.de> Cc: Stefan Chulski <stefanc@marvell.com> Cc: Kostya Porotchkin <kostap@marvell.com> Cc: Nadav Haklai <nadavh@marvell.com> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2017-03-29arm64: mvebu: armada-7040-db.dts: Change eth1 speed from 2.5G to 1GStefan Roese
The default configuration for the COMPHY-0 port should be 1G, as its used as 1G SGMII connection. This change is necessary to get the MAC2 port (SGMII) working on this DB. Signed-off-by: Stefan Roese <sr@denx.de> Cc: Stefan Chulski <stefanc@marvell.com> Cc: Kostya Porotchkin <kostap@marvell.com> Cc: Nadav Haklai <nadavh@marvell.com> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2017-03-29net: mvpp2: Remove unreferenced in_use_thresh from struct mvpp2_bm_poolStefan Roese
As pointed out by Stefan Chulski, this variable is unused and should be removed. Signed-off-by: Stefan Roese <sr@denx.de> Cc: Stefan Chulski <stefanc@marvell.com> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2017-03-29net: mvpp2: Configure SMI PHY address needed for PHY pollingStefan Roese
On PPv2.2 we enable PHY polling, so we also need to configure the PHY address in the specific PHY address rgisters. Signed-off-by: Stefan Roese <sr@denx.de> Cc: Stefan Chulski <stefanc@marvell.com> Cc: Kostya Porotchkin <kostap@marvell.com> Cc: Nadav Haklai <nadavh@marvell.com> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2017-03-29net: mvpp2: Enable PHY polling mode on PPv2.2Stefan Roese
Testing shows, that PHY polling needs to be enabled on Armada 7k/8k. Otherwise ethernet transfers will not work correctly. PHY polling is enabled per default after reset, so we do not need to specifically enable it, but this makes it clearer. Signed-off-by: Stefan Roese <sr@denx.de> Cc: Stefan Chulski <stefanc@marvell.com> Cc: Kostya Porotchkin <kostap@marvell.com> Cc: Nadav Haklai <nadavh@marvell.com> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2017-03-29net: mvpp2: Add missing PHY_INTERFACE_MODE_RGMII_IDStefan Roese
Add a missing occurrance of PHY_INTERFACE_MODE_RGMII_ID, which should be handled identical to PHY_INTERFACE_MODE_RGMII. Signed-off-by: Stefan Roese <sr@denx.de> Cc: Stefan Chulski <stefanc@marvell.com> Cc: Kostya Porotchkin <kostap@marvell.com> Cc: Nadav Haklai <nadavh@marvell.com> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2017-03-29net: mvpp2: Add GoP and NetC support for port 0 (SFI)Stefan Roese
This patch adds the GoP (Group of Ports) and NetC (Net Complex) setup to the Marvell mvpp2 ethernet driver for the missing port 0. This code is mostly copied from the Marvell U-Boot version and was written by Stefan Chulski. Please note that only SFI support have been added, as this is the only interface that this code has been tested with. XAUI and RXAUI support might follow at a later stage. Signed-off-by: Stefan Roese <sr@denx.de> Cc: Stefan Chulski <stefanc@marvell.com> Cc: Kostya Porotchkin <kostap@marvell.com> Cc: Nadav Haklai <nadavh@marvell.com> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2017-03-29net: mvpp2: Add GoP and NetC support for ports 2 & 3 (RGMII & SGMII)Stefan Roese
This patch adds the GoP (Group of Ports) and NetC (Net Complex) setup to the Marvell mvpp2 ethernet driver. This code is mostly copied from the Marvell U-Boot version and was written by Stefan Chulski. Please note that only RGMII and SGMII support have been added, as these are the only interfaces that this code has been tested with. Signed-off-by: Stefan Roese <sr@denx.de> Cc: Stefan Chulski <stefanc@marvell.com> Cc: Kostya Porotchkin <kostap@marvell.com> Cc: Nadav Haklai <nadavh@marvell.com> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2017-03-29net: mvpp2: Read phy-speed from DT to select between 1GB and 2.5GB SGMIIStefan Roese
Read the "phy-speed" DT property to differentiate between 1 and 2.5GB SGMII operations. Please note that its unclear right now, if this DT property will be accepted in mainline Linux. If not, we need to revisit this code and change it to use the accepted property. Signed-off-by: Stefan Roese <sr@denx.de> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2017-03-29net: mvpp2: Restructure probe / init functionsStefan Roese
This patch does a bit of restructuring of the probe / init functions, mainly to allow earlier register access as it is needed for the upcoming GoP (Group of Ports) and NetC (Net Complex) code. Signed-off-by: Stefan Roese <sr@denx.de> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2017-03-29net: include/phy.h: Add new PHY interface modesStefan Roese
This patch adds the new PHY interface modes XAUI, RXAUI and SFI that will be used by the PPv2.2 support in the Marvell mvpp2 ethernet driver. Signed-off-by: Stefan Roese <sr@denx.de> Cc: Stefan Chulski <stefanc@marvell.com> Cc: Kostya Porotchkin <kostap@marvell.com> Cc: Nadav Haklai <nadavh@marvell.com> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2017-03-29net: mvpp2: Add RX and TX FIFO configuration for PPv2.2Stefan Roese
This patch adds the PPv2.2 specific FIFO configuration to the mvpp2 driver. The RX FIFO packet data size is changed to the recommended FIFO sizes. The TX FIFO configuration is newly added. Signed-off-by: Stefan Roese <sr@denx.de> Cc: Stefan Chulski <stefanc@marvell.com> Cc: Kostya Porotchkin <kostap@marvell.com> Cc: Nadav Haklai <nadavh@marvell.com> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2017-03-29net: mvpp2: Handle eth device naming in multi-CP case correctlyStefan Roese
Currently, the naming of the ethernet ports is not handled correctly in the multi-CP (Communication Processor) case. On Armada 8k, the slave-CP also instantiates an ethernet controller with the same device ID's. This patch now takes this into account and adds the required base-id so that the slave-CP ethernet devices will be named "mvpp2-3 ...". This patch also updates my Copyright notice to include 2017 as well. Signed-off-by: Stefan Roese <sr@denx.de> Cc: Stefan Chulski <stefanc@marvell.com> Cc: Kostya Porotchkin <kostap@marvell.com> Cc: Nadav Haklai <nadavh@marvell.com> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2017-03-29arm64: mvebu: armada-7k/8k: Enable MVPP2 ethernet driverStefan Roese
Since we've now integrated the A7k/8k support in the mvpp2 ethernet driver, lets enable the support for both Marvell developments boards. Signed-off-by: Stefan Roese <sr@denx.de> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2017-03-29arm64: marvell: dts: add PPv2.2 description to Armada 7K/8KThomas Petazzoni
This commit adds the description of the PPv2.2 hardware block for the Marvell Armada 7K and Armada 8K processors, and their corresponding Armada 7040 and 8040 Development boards. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Stefan Roese <sr@denx.de> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2017-03-29net: mvpp2: Enable compilation for Armada 7K/8K platformsStefan Roese
Since Armada 7K/8K is also equipped with a newer version of the MVPP2 ethernet controller, lets enable compilation of this driver for these platforms. Signed-off-by: Stefan Roese <sr@denx.de> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2017-03-29net: mvpp2.c: Clear all buffer / descriptor areas before usageStefan Roese
This fixes problems noticed with the PPv2.2 A7k/8k port, when not all elements of the descriptors had been cleared before use. Signed-off-by: Stefan Roese <sr@denx.de> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2017-03-29net: mvpp2: Move probe function from MISC to ETH DM driverStefan Roese
This patch moves the base_probe function mvpp2_base_probe() from the MISC driver to the ETH driver. When integrated in the MISC driver, probe is called too early before the U-Boot ethernet infrastructure (especially the MDIO / PHY interface) has been initialized. Resulting in errors in mdio_register(). Signed-off-by: Stefan Roese <sr@denx.de> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2017-03-29net: mvpp2: Add MDIO support for PPv2.2Stefan Roese
In U-Boot the MDIO / SMI support is integrated in the mvpp2 driver, currently only supporting the 32bit platforms (Armada 37x). This patch now adds the A7k/8k PPv2.2 MDIO support to that the phy / mii IF can be used as well on these platforms. Signed-off-by: Stefan Roese <sr@denx.de> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2017-03-29net: mvpp2: finally add the PPv2.2 compatible stringThomas Petazzoni
Now that the mvpp2 driver has been modified to accommodate the support for PPv2.2, we can finally advertise this support by adding the appropriate compatible string. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Stefan Roese <sr@denx.de> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2017-03-29net: mvpp2: adapt rxq distribution to PPv2.2Thomas Petazzoni
In PPv2.1, we have a maximum of 8 RXQs per port, with a default of 4 RXQs per port, and we were assigning RXQs 0->3 to the first port, 4->7 to the second port, 8->11 to the third port, etc. In PPv2.2, we have a maximum of 32 RXQs per port, and we must allocate RXQs from the range of 32 RXQs available for each port. So port 0 must use RXQs in the range 0->31, port 1 in the range 32->63, etc. This commit adapts the mvpp2 to this difference between PPv2.1 and PPv2.2: - The constant definition MVPP2_MAX_RXQ is replaced by a new field 'max_port_rxqs' in 'struct mvpp2', which stores the maximum number of RXQs per port. This field is initialized during ->probe() depending on the IP version. - MVPP2_RXQ_TOTAL_NUM is removed, and instead we calculate the total number of RXQs by multiplying the number of ports by the maximum of RXQs per port. This was anyway used in only one place. - In mvpp2_port_probe(), the calculation of port->first_rxq is adjusted to cope with the different allocation strategy between PPv2.1 and PPv2.2. Due to this change, the 'next_first_rxq' argument of this function is no longer needed and is removed. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Stefan Roese <sr@denx.de> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2017-03-29net: mvpp2: rework RXQ interrupt group initialization for PPv2.2Thomas Petazzoni
This commit adjusts how the MVPP2_ISR_RXQ_GROUP_REG register is configured, since it changed between PPv2.1 and PPv2.2. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Stefan Roese <sr@denx.de> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2017-03-29net: mvpp2: add AXI bridge initialization for PPv2.2Thomas Petazzoni
The PPv2.2 unit is connected to an AXI bus on Armada 7K/8K, so this commit adds the necessary initialization of the AXI bridge. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Stefan Roese <sr@denx.de> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2017-03-29net: mvpp2: handle misc PPv2.1/PPv2.2 differencesThomas Petazzoni
This commit handles a few miscellaneous differences between PPv2.1 and PPv2.2 in different areas, where code done for PPv2.1 doesn't apply for PPv2.2 or needs to be adjusted (getting the MAC address, disabling PHY polling, etc.). Changed by Stefan for U-Boot: Since mvpp2_port_power_up() has multiple callers in U-Boot, the U-Boot version of this patch does not remove this function but simply adds the check for MVPP21 before the mvpp2_port_fc_adv_enable() call. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Stefan Roese <sr@denx.de> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2017-03-29net: mvpp2: handle register mapping and access for PPv2.2Thomas Petazzoni
This commit adjusts the mvpp2 driver register mapping and access logic to support PPv2.2, to handle a number of differences. Due to how the registers are laid out in memory, the Device Tree binding for the "reg" property is different: - On PPv2.1, we had a first area for the common registers, and then one area per port. - On PPv2.2, we have a first area for the common registers, and a second area for all the per-ports registers. In addition, on PPv2.2, the area for the common registers is split into so-called "address spaces" of 64 KB each. They allow to access the same registers, but from different CPUs. Hence the introduction of cpu_base[] in 'struct mvpp2', and the modification of the mvpp2_write() and mvpp2_read() register accessors. For PPv2.1, the compatibility is preserved by using an "address space" size of 0. Changed by Stefan for U-Boot: Since we don't support multiple CPUs in U-Boot, I've removed all the code, macros and variables introduced in the Linux patch version for this. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Stefan Roese <sr@denx.de> Acked-by: Joe Hershberger <joe.hershberger@ni.com>