| Message ID | 1392459621-24003-6-git-send-email-andrew@lunn.ch (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Saturday 15 February 2014 11:20:03 Andrew Lunn wrote: > +static void __init kirkwood_l2_init(void) > +{ > +#ifdef CONFIG_CACHE_FEROCEON_L2 > +#ifdef CONFIG_CACHE_FEROCEON_L2_WRITETHROUGH > + writel(readl(L2_CONFIG_REG) | L2_WRITETHROUGH, L2_CONFIG_REG); > + feroceon_l2_init(1); > +#else > + writel(readl(L2_CONFIG_REG) & ~L2_WRITETHROUGH, L2_CONFIG_REG); > + feroceon_l2_init(0); > +#endif > +#endif > +} I assume this is correct, but I don't understand it. Why is there a configuration option for this? Do both write-through and write-back work on all machines, or could there be a case where some machine actually requires a particular mode? If not, isn't write-back normally "better", so you won't actually ever want to set write-through mode? Arnd
On Sat, Feb 15, 2014 at 02:18:08PM +0100, Arnd Bergmann wrote: > On Saturday 15 February 2014 11:20:03 Andrew Lunn wrote: > > +static void __init kirkwood_l2_init(void) > > +{ > > +#ifdef CONFIG_CACHE_FEROCEON_L2 > > +#ifdef CONFIG_CACHE_FEROCEON_L2_WRITETHROUGH > > + writel(readl(L2_CONFIG_REG) | L2_WRITETHROUGH, L2_CONFIG_REG); > > + feroceon_l2_init(1); > > +#else > > + writel(readl(L2_CONFIG_REG) & ~L2_WRITETHROUGH, L2_CONFIG_REG); > > + feroceon_l2_init(0); > > +#endif > > +#endif > > +} > > I assume this is correct, but I don't understand it. Why is there a > configuration option for this? Do both write-through and write-back > work on all machines, or could there be a case where some machine > actually requires a particular mode? If not, isn't write-back > normally "better", so you won't actually ever want to set write-through > mode? Hi Arnd The honest answer is, i've no idea. I'm just shuffling code around in this patch, and not applying my brain as to what this code does.... Maybe JasonG has a better idea of this history of this? Andrew
On Sat, Feb 15, 2014 at 03:05:05PM +0100, Andrew Lunn wrote: > On Sat, Feb 15, 2014 at 02:18:08PM +0100, Arnd Bergmann wrote: > > On Saturday 15 February 2014 11:20:03 Andrew Lunn wrote: > > > +static void __init kirkwood_l2_init(void) > > > +{ > > > +#ifdef CONFIG_CACHE_FEROCEON_L2 > > > +#ifdef CONFIG_CACHE_FEROCEON_L2_WRITETHROUGH > > > + writel(readl(L2_CONFIG_REG) | L2_WRITETHROUGH, L2_CONFIG_REG); > > > + feroceon_l2_init(1); > > > +#else > > > + writel(readl(L2_CONFIG_REG) & ~L2_WRITETHROUGH, L2_CONFIG_REG); > > > + feroceon_l2_init(0); > > > +#endif > > > +#endif > > > +} > > > > I assume this is correct, but I don't understand it. Why is there a > > configuration option for this? Do both write-through and write-back > > work on all machines, or could there be a case where some machine > > actually requires a particular mode? If not, isn't write-back > > normally "better", so you won't actually ever want to set write-through > > mode? > > Hi Arnd > > The honest answer is, i've no idea. I'm just shuffling code around in > this patch, and not applying my brain as to what this code does.... > > Maybe JasonG has a better idea of this history of this? No idea of the history, but for DMA heavy work loads write-through is better since you spend less cpu cycles doing cache flushing, while for CPU centric work loads write-back is better since you spend less time waiting for memory. Since these SOCs are popular for storage and networking apps I'm not surprised to see this option. But a static config option is not really in-line with current thinking on these sorts of things. A DT option would be better (IMHO), but even that is probably not going to be universally loved. Can we worry about this after Andrew's shuffling is done? Regards, Jason
> Can we worry about this after Andrew's shuffling is done?
Hi Jason
I think so. I plan to keep to a config option for the moment and
remove the wt-override from DT. We can put it back again later.
Andrew
On Tuesday 18 February 2014 11:37:46 Jason Gunthorpe wrote: > > No idea of the history, but for DMA heavy work loads write-through is > better since you spend less cpu cycles doing cache flushing, while for > CPU centric work loads write-back is better since you spend less time > waiting for memory. > > Since these SOCs are popular for storage and networking apps I'm not > surprised to see this option. Ok, that makes much more sense than anything I could come up with ;-) > But a static config option is not really in-line with current thinking > on these sorts of things. A DT option would be better (IMHO), but even > that is probably not going to be universally loved. One of the later patches actually introduced a DT property for it, but the implementation of that seemed incomplete, so the current plan is to keep the Kconfig option for now. > Can we worry about this after Andrew's shuffling is done? Sure. Arnd
diff --git a/arch/arm/mach-kirkwood/Makefile b/arch/arm/mach-kirkwood/Makefile index dc22bf5b21ed..3a72c5c6e747 100644 --- a/arch/arm/mach-kirkwood/Makefile +++ b/arch/arm/mach-kirkwood/Makefile @@ -1,5 +1,4 @@ -obj-y += common.o pcie.o -obj-$(CONFIG_KIRKWOOD_LEGACY) += irq.o mpp.o +obj-$(CONFIG_KIRKWOOD_LEGACY) += irq.o mpp.o common.o pcie.o obj-$(CONFIG_PM) += pm.o obj-$(CONFIG_MACH_D2NET_V2) += d2net_v2-setup.o lacie_v2-common.o diff --git a/arch/arm/mach-kirkwood/board-dt.c b/arch/arm/mach-kirkwood/board-dt.c index a0c0ff39788e..64151a4a378f 100644 --- a/arch/arm/mach-kirkwood/board-dt.c +++ b/arch/arm/mach-kirkwood/board-dt.c @@ -21,11 +21,97 @@ #include <linux/irqchip.h> #include <linux/kexec.h> #include <asm/mach/arch.h> +#include <asm/mach/map.h> #include <mach/bridge-regs.h> #include <plat/common.h> -#include "common.h" +#include <plat/cache-feroceon-l2.h> +#include <plat/pcie.h> #include "pm.h" +static struct map_desc kirkwood_io_desc[] __initdata = { + { + .virtual = (unsigned long) KIRKWOOD_REGS_VIRT_BASE, + .pfn = __phys_to_pfn(KIRKWOOD_REGS_PHYS_BASE), + .length = KIRKWOOD_REGS_SIZE, + .type = MT_DEVICE, + }, +}; + +static void __init kirkwood_map_io(void) +{ + iotable_init(kirkwood_io_desc, ARRAY_SIZE(kirkwood_io_desc)); +} + +static void __init kirkwood_l2_init(void) +{ +#ifdef CONFIG_CACHE_FEROCEON_L2 +#ifdef CONFIG_CACHE_FEROCEON_L2_WRITETHROUGH + writel(readl(L2_CONFIG_REG) | L2_WRITETHROUGH, L2_CONFIG_REG); + feroceon_l2_init(1); +#else + writel(readl(L2_CONFIG_REG) & ~L2_WRITETHROUGH, L2_CONFIG_REG); + feroceon_l2_init(0); +#endif +#endif +} + +static struct resource kirkwood_cpufreq_resources[] = { + [0] = { + .start = CPU_CONTROL_PHYS, + .end = CPU_CONTROL_PHYS + 3, + .flags = IORESOURCE_MEM, + }, +}; + +static struct platform_device kirkwood_cpufreq_device = { + .name = "kirkwood-cpufreq", + .id = -1, + .num_resources = ARRAY_SIZE(kirkwood_cpufreq_resources), + .resource = kirkwood_cpufreq_resources, +}; + +static void __init kirkwood_cpufreq_init(void) +{ + platform_device_register(&kirkwood_cpufreq_device); +} + +static struct resource kirkwood_cpuidle_resource[] = { + { + .flags = IORESOURCE_MEM, + .start = DDR_OPERATION_BASE, + .end = DDR_OPERATION_BASE + 3, + }, +}; + +static struct platform_device kirkwood_cpuidle = { + .name = "kirkwood_cpuidle", + .id = -1, + .resource = kirkwood_cpuidle_resource, + .num_resources = 1, +}; + +static void __init kirkwood_cpuidle_init(void) +{ + platform_device_register(&kirkwood_cpuidle); +} + +/* Temporary here since mach-mvebu has a function we can use */ +static void kirkwood_restart(enum reboot_mode mode, const char *cmd) +{ + /* + * Enable soft reset to assert RSTOUTn. + */ + writel(SOFT_RESET_OUT_EN, RSTOUTn_MASK); + + /* + * Assert soft reset. + */ + writel(SOFT_RESET, SYSTEM_SOFT_RESET); + + while (1) + ; +} + #define MV643XX_ETH_MAC_ADDR_LOW 0x0414 #define MV643XX_ETH_MAC_ADDR_HIGH 0x0418
In order to be able to move DT support into mach-mvebu, the DT code needs to be cleanly separated from common and pcie code. Import the needed bits of these files into board-dt.c. The "common" code then becomes purely legacy, supporting none DT boards, so reflect this in the Makefile targets. Signed-off-by: Andrew Lunn <andrew@lunn.ch> --- arch/arm/mach-kirkwood/Makefile | 3 +- arch/arm/mach-kirkwood/board-dt.c | 88 ++++++++++++++++++++++++++++++++++++++- 2 files changed, 88 insertions(+), 3 deletions(-)