Message ID | 20151221232439.ED1AB61201@mail.nwl.cc |
---|---|
State | Superseded |
Delegated to: | Prafulla Wadaskar |
Headers | show |
Hi Phil, On 22.12.2015 00:25, Phil Sutter wrote: > This mimics the relevant code in mach-kirkwood headers. The > *_winctrl_calcsize functions are identical, as well as the MVCPU_WIN_* > macros. Implementing shared headers/code between mvebu and kirkwood is > left for someone with a better knowledge of how u-boot is organized > internally. Why do you need this functionality on your Armada XP board? It should be able to use the DM enabled ehci-marvell driver. Thanks, Stefan
Hi Stefan, On Tue, Dec 22, 2015 at 09:02:44AM +0100, Stefan Roese wrote: > On 22.12.2015 00:25, Phil Sutter wrote: > > This mimics the relevant code in mach-kirkwood headers. The > > *_winctrl_calcsize functions are identical, as well as the MVCPU_WIN_* > > macros. Implementing shared headers/code between mvebu and kirkwood is > > left for someone with a better knowledge of how u-boot is organized > > internally. > > Why do you need this functionality on your Armada XP board? It > should be able to use the DM enabled ehci-marvell driver. Yes, it works without as long as CONFIG_DM_USB is enabled. Yet I thought fixing it nevertheless was desirable to allow for testing or whatever without. If you don't see any use in it, I can drop this from the upcoming V3 of course. OTOH maybe we should enforce DM_USB for Armada XP boards with ehci-marvell enabled? Thanks, Phil
Hi Phil, On 22.12.2015 15:24, Phil Sutter wrote: > On Tue, Dec 22, 2015 at 09:02:44AM +0100, Stefan Roese wrote: >> On 22.12.2015 00:25, Phil Sutter wrote: >>> This mimics the relevant code in mach-kirkwood headers. The >>> *_winctrl_calcsize functions are identical, as well as the MVCPU_WIN_* >>> macros. Implementing shared headers/code between mvebu and kirkwood is >>> left for someone with a better knowledge of how u-boot is organized >>> internally. >> >> Why do you need this functionality on your Armada XP board? It >> should be able to use the DM enabled ehci-marvell driver. > > Yes, it works without as long as CONFIG_DM_USB is enabled. Yet I thought > fixing it nevertheless was desirable to allow for testing or whatever > without. Using a driver that supports DM on a platform that supports DM is the way to go. On the long run, all driver and platforms will get converted to DM. > If you don't see any use in it, I can drop this from the upcoming V3 of > course. Yes, please drop it. > OTOH maybe we should enforce DM_USB for Armada XP boards with > ehci-marvell enabled? Yes. I think once all the patches have reached mainline (after the next release), such an automatic selection of the DM_xxx stuff should be done. Thanks, Stefan
diff --git a/arch/arm/mach-mvebu/cpu.c b/arch/arm/mach-mvebu/cpu.c index c9b9c77..fd12c22 100644 --- a/arch/arm/mach-mvebu/cpu.c +++ b/arch/arm/mach-mvebu/cpu.c @@ -45,6 +45,27 @@ void reset_cpu(unsigned long ignored) ; } +/* + * Window Size + * Used with the Base register to set the address window size and location. + * Must be programmed from LSB to MSB as sequence of ones followed by + * sequence of zeros. The number of ones specifies the size of the window in + * 64 KByte granularity (e.g., a value of 0x00FF specifies 256 = 16 MByte). + * NOTE: A value of 0x0 specifies 64-KByte size. + */ +unsigned int mvebu_winctrl_calcsize(unsigned int sizeval) +{ + int i; + unsigned int j = 0; + u32 val = sizeval >> 1; + + for (i = 0; val >= 0x10000; i++) { + j |= (1 << i); + val = val >> 1; + } + return 0x0000ffff & j; +} + int mvebu_soc_family(void) { u16 devid = (readl(MVEBU_REG_PCIE_DEVID) >> 16) & 0xffff; diff --git a/arch/arm/mach-mvebu/include/mach/cpu.h b/arch/arm/mach-mvebu/include/mach/cpu.h index 5e8bf0c..484638b 100644 --- a/arch/arm/mach-mvebu/include/mach/cpu.h +++ b/arch/arm/mach-mvebu/include/mach/cpu.h @@ -13,6 +13,9 @@ #ifndef __ASSEMBLY__ +#define MVEBU_CPU_WIN_CTRL_DATA(size, target, attr, en) (en | (target << 4) \ + | (attr << 8) | (mvebu_winctrl_calcsize(size) << 16)) + #define MVEBU_REG_PCIE_DEVID (MVEBU_REG_PCIE_BASE + 0x00) #define MVEBU_REG_PCIE_REVID (MVEBU_REG_PCIE_BASE + 0x08) diff --git a/arch/arm/mach-mvebu/include/mach/soc.h b/arch/arm/mach-mvebu/include/mach/soc.h index 5d4ad30..cfc28c3 100644 --- a/arch/arm/mach-mvebu/include/mach/soc.h +++ b/arch/arm/mach-mvebu/include/mach/soc.h @@ -91,8 +91,15 @@ #define SDRAM_MAX_CS 4 #define SDRAM_ADDR_MASK 0xFF000000 +/* MVEBU USB Host controller */ +#define MVUSB0_BASE MVEBU_AXP_USB_BASE +#define MVUSB0_CPU_ATTR_DRAM_CS0 CPU_ATTR_DRAM_CS0 +#define MVUSB0_CPU_ATTR_DRAM_CS1 CPU_ATTR_DRAM_CS1 +#define MVUSB0_CPU_ATTR_DRAM_CS2 CPU_ATTR_DRAM_CS2 +#define MVUSB0_CPU_ATTR_DRAM_CS3 CPU_ATTR_DRAM_CS3 + /* MVEBU CPU memory windows */ -#define MVCPU_WIN_CTRL_DATA CPU_WIN_CTRL_DATA +#define MVCPU_WIN_CTRL_DATA MVEBU_CPU_WIN_CTRL_DATA #define MVCPU_WIN_ENABLE CPU_WIN_ENABLE #define MVCPU_WIN_DISABLE CPU_WIN_DISABLE
This mimics the relevant code in mach-kirkwood headers. The *_winctrl_calcsize functions are identical, as well as the MVCPU_WIN_* macros. Implementing shared headers/code between mvebu and kirkwood is left for someone with a better knowledge of how u-boot is organized internally. Signed-off-by: Phil Sutter <phil@nwl.cc> --- arch/arm/mach-mvebu/cpu.c | 21 +++++++++++++++++++++ arch/arm/mach-mvebu/include/mach/cpu.h | 3 +++ arch/arm/mach-mvebu/include/mach/soc.h | 9 ++++++++- 3 files changed, 32 insertions(+), 1 deletion(-)