
On 21.03.2017 18:33, Joe Hershberger wrote:
On Tue, Mar 21, 2017 at 9:27 AM, Stefan Roese sr@denx.de wrote:
From: Thomas Petazzoni thomas.petazzoni@free-electrons.com
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
drivers/net/mvpp2.c | 39 +++++++++++++++++++++++++++++++-------- 1 file changed, 31 insertions(+), 8 deletions(-)
diff --git a/drivers/net/mvpp2.c b/drivers/net/mvpp2.c index c297097c3a..1b6e5586c0 100644 --- a/drivers/net/mvpp2.c +++ b/drivers/net/mvpp2.c @@ -342,6 +342,9 @@ do { \ #define MVPP2_GMAC_TX_FIFO_MIN_TH_MASK(v) (((v) << 6) & \ MVPP2_GMAC_TX_FIFO_MIN_TH_ALL_MASK)
+#define MVPP22_PORT_BASE 0x30e00 +#define MVPP22_PORT_OFFSET 0x1000
#define MVPP2_CAUSE_TXQ_SENT_DESC_ALL_MASK 0xff
/* Descriptor ring Macros */ @@ -702,6 +705,7 @@ struct mvpp2 { /* Shared registers' base addresses */ void __iomem *base; void __iomem *lms_base;
void __iomem *iface_base;
Curious why this is a new variable instead of reusing the existing lms_base, but I suspect it was something needed for the multi-cpu case that Stefan removed and here all by itself, the change looks odd. Still probably better to keep it closer to the Linux version.
Yes, this was exactly my reasoning.
Thanks, Stefan