* [PATCH v6 03/10] ARM: edma: add AM33XX support to the private EDMA API
From: Matt Porter @ 2013-01-31 18:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201301300932.58732.arnd@arndb.de>
On Wed, Jan 30, 2013 at 09:32:58AM +0000, Arnd Bergmann wrote:
> On Wednesday 30 January 2013, Matt Porter wrote:
> > + dma_cap_set(DMA_SLAVE, edma_filter_info.dma_cap);
> > + of_dma_controller_register(dev->of_node,
> > + of_dma_simple_xlate,
> > + &edma_filter_info);
> > + }
>
> How do you actually deal with the problem mentioned by Padma, that
> the filter function does not know which edma instance it is looking
> at? If you assume that there can only be a single edma instance in
> the system, that is probably a limitation that should be documented
> somewhere, and ideally the probe() function should check for that.
I make an assumption of one edma instance in the system in the case of
DT being populated. This is always true right now as the only SoC with
two EDMA controllers in existence is Davinci DA850. Until recently,
Davinci had no DT support. Given the steady work being done today on DT
support for DA850, it'll probably be something needed in 3.10.
I will add a comment and check in probe() to capture this assumption
and then plan to update separately to support DA850 booting from DT.
-Matt
^ permalink raw reply
* [PATCH 1/2] ARM: memory: use SZ_ constants for defining the virtual memory layout
From: Will Deacon @ 2013-01-31 18:17 UTC (permalink / raw)
To: linux-arm-kernel
Parts of the virtual memory layout (mainly the modules area) are
described using open-coded immediate values.
Use the SZ_ definitions from linux/sizes.h instead to make the code
clearer.
Acked-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
KernelVersion: 3.8-rc5
---
arch/arm/include/asm/memory.h | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
index 73cf03a..924320f 100644
--- a/arch/arm/include/asm/memory.h
+++ b/arch/arm/include/asm/memory.h
@@ -36,23 +36,23 @@
* TASK_UNMAPPED_BASE - the lower boundary of the mmap VM area
*/
#define PAGE_OFFSET UL(CONFIG_PAGE_OFFSET)
-#define TASK_SIZE (UL(CONFIG_PAGE_OFFSET) - UL(0x01000000))
+#define TASK_SIZE (UL(CONFIG_PAGE_OFFSET) - UL(SZ_16M))
#define TASK_UNMAPPED_BASE (UL(CONFIG_PAGE_OFFSET) / 3)
/*
* The maximum size of a 26-bit user space task.
*/
-#define TASK_SIZE_26 UL(0x04000000)
+#define TASK_SIZE_26 (UL(1) << 26)
/*
* The module space lives between the addresses given by TASK_SIZE
* and PAGE_OFFSET - it must be within 32MB of the kernel text.
*/
#ifndef CONFIG_THUMB2_KERNEL
-#define MODULES_VADDR (PAGE_OFFSET - 16*1024*1024)
+#define MODULES_VADDR (PAGE_OFFSET - SZ_16M)
#else
/* smaller range for Thumb-2 symbols relocation (2^24)*/
-#define MODULES_VADDR (PAGE_OFFSET - 8*1024*1024)
+#define MODULES_VADDR (PAGE_OFFSET - SZ_8M)
#endif
#if TASK_SIZE > MODULES_VADDR
--
1.8.0
^ permalink raw reply related
* [PATCHv2 for soc 3/4] arm: Add v7_invalidate_l1 to cache-v7.S
From: Stephen Warren @ 2013-01-31 18:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359651943-21752-4-git-send-email-dinguyen@altera.com>
On 01/31/2013 10:05 AM, dinguyen at altera.com wrote:
> From: Dinh Nguyen <dinguyen@altera.com>
>
> mach-socfpga is another platform that needs to use
> v7_invalidate_l1 to bringup additional cores. There was a comment that
> the ideal place for v7_invalidate_l1 should be in arm/mm/cache-v7.S
Tested-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Stephen Warren <swarren@nvidia.com>
(on Tegra30 Cardhu, with this patch applied on top of Tegra's for-next
branch, played audio and did repeated CPU hotplugs)
There will be a minor merge conflict when this patch is merged with the
Tegra tree changes, but it's trivial to resolve; some other code was
removed from this file right next to this function.
^ permalink raw reply
* [PATCH v2 19/27] pci: PCIe driver for Marvell Armada 370/XP systems
From: Jason Gunthorpe @ 2013-01-31 18:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2776630.gp5gC9tvLk@wuerfel>
On Thu, Jan 31, 2013 at 05:18:46PM +0100, Arnd Bergmann wrote:
> For all I could tell, the safest solution with the I/O space would
> be to pretend we had a shared 64K I/O space for all of the PCIe
> ports on Armada XP, and map a separate 64K window for each port
> using a different io_offset for each one.
> This way, you can have a device on the second PCIe port use e.g. I/O
> port number 0x3f8 for a legacy UART on the bus, which gets translated
> into the Linux-visible port number 0x103f8.
>
> The currently used method to have io_offset=0 for all PCIe ports
> and use separate I/O port ranges of 64K for each PCIe port probably
> still works for most devices, except those where we hardcode a port
> number in the Linux device driver, or where the high address bits
> don't get decoded properly.
Thinking about this some more, which of these methods to choose is
going to be dictated by what the Marvell HW does.
Since the IO space in the TLP is a full 32 bits, it matters what 32
bit value the HW PCI core places in the IO Rd/Wr transaction. This
value *must* match the value given to the Linux PCI core for resource
allocation, because it must be correctly programmed by Linux into the
downstream BARs/bridge windows.
So there are probably two choices for what the HW does, given a MBUS
window of 0xDEAD0000 -> 0xDEADFFFF set for IO, a read from physical
address 0xDEAD0000 produces a IO Rd TLP with either '0x00000000' or
'0xDEAD0000' in the address field.
If it is 0xDEAD0000, then Thomas has to keep what he has now, you
can't mess with this address. Verify that the full 32 bit address
exactly matching the MBUS window address is written to the PCI-PCI
bridge IO base/limit registers.
If it is 0x00000000 then the mmap scheme I outlined before must be
used, and verify that only 0->0xFFFF is written to the PCI-PCI bridge
IO base/limit registers..
My guess is the Marvell PCI-E copies whatever address is it given into
the IO TLP, so it would be the 0xDEAD0000 behaviour, however I bet you
can use the MBUS window target address remapping feature to get the
0x00000000 behaviour as well (though there are a limited number of
remappable MBUS windows, so that is probably not a good idea)
Jason
^ permalink raw reply
* [PATCH v3] arm: mvebu: add DTS file for Marvell RD-A370-A1 board
From: Jason Cooper @ 2013-01-31 17:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358174852-19752-1-git-send-email-florian@openwrt.org>
Florian,
On Mon, Jan 14, 2013 at 03:47:32PM +0100, Florian Fainelli wrote:
> This patch adds the DTS file to support the Marvell RD-A370-A1
> (Reference Design board) also known as RD-88F6710 board. It is almost
> entirely similar to the DB-A370 except on the following points:
>
> - second Ethernet MAC is connected to a switch using RGMII
> - it only has 512MB of physical RAM
> - SDIO interface is enabled and working by default (no need for jumpers)
>
> Signed-off-by: Florian Fainelli <florian@openwrt.org>
> ---
> Jason,
>
> This is rebased against your mvebu/for-next branch, can you please drop v2 of
> the previous patch and take this one instead? Thanks!
>
> Changes since v2:
> - rebased against Jason's mvebu/for-next
> - added SDIO bindings
> - changed commit message a bit
This breaks badly as sdio bindings aren't added until mvebu/dt. Since
this is a new board, it goes in *before* mvebu/dt (mvebu/boards). I'm
going to go ahead and pull v2 instead as there seems to be no
significant difference other than mvsdio being added.
If you want to get sdio support in for v3.9, please submit a separate
patch on top of your v2.
thx,
Jason.
>
> Changes since v1:
> - added missing entry in arch/arm/boot/dts/Makefile to actually build the DTB
>
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/armada-370-rd.dts | 68 +++++++++++++++++++++++++++++++++++
> 2 files changed, 69 insertions(+)
> create mode 100644 arch/arm/boot/dts/armada-370-rd.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index b7246d6..7a75171 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -78,6 +78,7 @@ dtb-$(CONFIG_ARCH_MSM) += msm8660-surf.dtb \
> msm8960-cdp.dtb
> dtb-$(CONFIG_ARCH_MVEBU) += armada-370-db.dtb \
> armada-370-mirabox.dtb \
> + armada-370-rd.dtb \
> armada-xp-db.dtb \
> armada-xp-openblocks-ax3-4.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx51-babbage.dtb \
> diff --git a/arch/arm/boot/dts/armada-370-rd.dts b/arch/arm/boot/dts/armada-370-rd.dts
> new file mode 100644
> index 0000000..f8e4855
> --- /dev/null
> +++ b/arch/arm/boot/dts/armada-370-rd.dts
> @@ -0,0 +1,68 @@
> +/*
> + * Device Tree file for Marvell Armada 370 Reference Design board
> + * (RD-88F6710-A1)
> + *
> + * Copied from arch/arm/boot/dts/armada-370-db.dts
> + *
> + * Copyright (C) 2013 Florian Fainelli <florian@openwrt.org>
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +/dts-v1/;
> +/include/ "armada-370.dtsi"
> +
> +/ {
> + model = "Marvell Armada 370 Reference Design";
> + compatible = "marvell,a370-rd", "marvell,armada370", "marvell,armada-370-xp";
> +
> + chosen {
> + bootargs = "console=ttyS0,115200 earlyprintk";
> + };
> +
> + memory {
> + device_type = "memory";
> + reg = <0x00000000 0x20000000>; /* 512 MB */
> + };
> +
> + soc {
> + serial at d0012000 {
> + clock-frequency = <200000000>;
> + status = "okay";
> + };
> + sata at d00a0000 {
> + nr-ports = <2>;
> + status = "okay";
> + };
> +
> + mdio {
> + phy0: ethernet-phy at 0 {
> + reg = <0>;
> + };
> +
> + phy1: ethernet-phy at 1 {
> + reg = <1>;
> + };
> + };
> +
> + ethernet at d0070000 {
> + status = "okay";
> + phy = <&phy0>;
> + phy-mode = "sgmii";
> + };
> + ethernet at d0074000 {
> + status = "okay";
> + phy = <&phy1>;
> + phy-mode = "rgmii-id";
> + };
> +
> + mvsdio at d00d4000 {
> + pinctrl-0 = <&sdio_pins1>;
> + pinctrl-names = "default";
> + status = "okay";
> + /* No CD or WP GPIOs */
> + };
> + };
> +};
> --
> 1.7.10.4
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 4/4] irqchip: gic: Perform the gic_secondary_init() call via CPU notifier
From: Russell King - ARM Linux @ 2013-01-31 17:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.02.1301311230140.6300@xanadu.home>
On Thu, Jan 31, 2013 at 12:32:11PM -0500, Nicolas Pitre wrote:
> On Thu, 31 Jan 2013, Russell King - ARM Linux wrote:
>
> > I haven't tried Versatile Express yet as it has the TC2 tile on, and I
> > don't yet a boot loader on it which is capable of TFTP (which makes it
> > rather useless to me - I've been saying this for a time now but this is
> > probably the first time publically.) I'm thinking about putting the
> > CA9x4 tile back on because that's a lot more functionally useful to me
> > than TC2.
>
> You might be interested by this then:
>
> http://lists.linaro.org/pipermail/linaro-dev/2012-October/014136.html
Great news. Everyone has been telling me that there's no uboot for TC2,
or "we think Linaro might have something but we don't really know".
^ permalink raw reply
* [PATCH 2/2] regulators: anatop: add set_voltage_time_sel interface
From: Anson Huang @ 2013-01-31 17:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <51099107.3070705@boundarydevices.com>
On Wed, Jan 30, 2013 at 02:30:47PM -0700, Troy Kisky wrote:
> On 1/30/2013 3:37 PM, Anson Huang wrote:
> >some of anatop's regulators(vppcpu, vddpu and vddsoc) have
> >register settings about LDO's step time, which will impact
> >the LDO ramp up speed, need to use set_voltage_time_sel
> >interface to add necessary delay everytime LDOs' voltage
> >is increased.
> >
> >offset 0x170:
> >bit [24-25]: vddcpu
> >bit [26-27]: vddpu
> >bit [28-29]: vddsoc
> >
> >field definition:
> >0'b00: 64 cycles of 24M clock;
> >0'b01: 128 cycles of 24M clock;
> >0'b02: 256 cycles of 24M clock;
> >0'b03: 512 cycles of 24M clock;
> >
> >Signed-off-by: Anson Huang <b20788@freescale.com>
> >---
> > drivers/regulator/anatop-regulator.c | 42 ++++++++++++++++++++++++++++++++++
> > 1 file changed, 42 insertions(+)
> >
> >diff --git a/drivers/regulator/anatop-regulator.c b/drivers/regulator/anatop-regulator.c
> >index 8f39cac..a857b9c 100644
> >--- a/drivers/regulator/anatop-regulator.c
> >+++ b/drivers/regulator/anatop-regulator.c
> >@@ -31,12 +31,18 @@
> > #include <linux/regulator/driver.h>
> > #include <linux/regulator/of_regulator.h>
> >+#define LDO_RAMP_UP_UNIT_IN_CYCLES 64 /* 64 cycles per step */
> >+#define LDO_RAMP_UP_FREQ_IN_MHZ 24 /* cycle based on 24M OSC */
> >+
> > struct anatop_regulator {
> > const char *name;
> > u32 control_reg;
> > struct regmap *anatop;
> > int vol_bit_shift;
> > int vol_bit_width;
> >+ u32 delay_reg;
> >+ int delay_bit_shift;
> >+ int delay_bit_width;
> > int min_bit_val;
> > int min_voltage;
> > int max_voltage;
> >@@ -55,6 +61,33 @@ static int anatop_regmap_set_voltage_sel(struct regulator_dev *reg,
> > return regulator_set_voltage_sel_regmap(reg, selector);
> > }
> >+static int anatop_regmap_set_voltage_time_sel(struct regulator_dev *reg,
> >+ unsigned int old_sel,
> >+ unsigned int new_sel)
> >+{
> >+ struct anatop_regulator *anatop_reg = rdev_get_drvdata(reg);
> >+ u32 val;
> >+ int ret = 0;
> >+
> >+ /* check whether need to care about LDO ramp up speed */
> >+ if (anatop_reg->delay_reg) {
> >+ /*
> >+ * the delay for LDO ramp up time is
> >+ * based on the register setting, we need
> >+ * to calculate how many steps LDO need to
> >+ * ramp up, and how much delay needed. (us)
> >+ */
> >+ regmap_read(anatop_reg->anatop, anatop_reg->delay_reg, &val);
> >+ val = (val >> anatop_reg->delay_bit_shift) &
> >+ ((1 << anatop_reg->delay_bit_width) - 1);
> >+ ret = new_sel > old_sel ? (new_sel - old_sel) *
>
> The (new_sel > old_sel) could be part of the above if.
>
> if (anatop_reg->delay_reg && new_sel > old_sel)
[Anson Huang]Good point, accepted. Please help review my v3 patch,thanks!
>
> >+ ((LDO_RAMP_UP_UNIT_IN_CYCLES << val) /
> >+ LDO_RAMP_UP_FREQ_IN_MHZ + 1) : 0;
> >+ }
> >+
> >+ return ret;
> >+}
> >+
> > static int anatop_regmap_get_voltage_sel(struct regulator_dev *reg)
> > {
> > struct anatop_regulator *anatop_reg = rdev_get_drvdata(reg);
> >@@ -67,6 +100,7 @@ static int anatop_regmap_get_voltage_sel(struct regulator_dev *reg)
> > static struct regulator_ops anatop_rops = {
> > .set_voltage_sel = anatop_regmap_set_voltage_sel,
> >+ .set_voltage_time_sel = anatop_regmap_set_voltage_time_sel,
> > .get_voltage_sel = anatop_regmap_get_voltage_sel,
> > .list_voltage = regulator_list_voltage_linear,
> > .map_voltage = regulator_map_voltage_linear,
> >@@ -143,6 +177,14 @@ static int anatop_regulator_probe(struct platform_device *pdev)
> > goto anatop_probe_end;
> > }
> >+ /* read LDO ramp up setting, only for core reg */
> >+ of_property_read_u32(np, "anatop-delay-reg-offset",
> >+ &sreg->delay_reg);
> >+ of_property_read_u32(np, "anatop-delay-bit-width",
> >+ &sreg->delay_bit_width);
> >+ of_property_read_u32(np, "anatop-delay-bit-shift",
> >+ &sreg->delay_bit_shift);
> >+
> > rdesc->n_voltages = (sreg->max_voltage - sreg->min_voltage) / 25000 + 1
> > + sreg->min_bit_val;
> > rdesc->min_uV = sreg->min_voltage;
>
>
^ permalink raw reply
* [PATCH, RFC] default machine descriptor for multiplatform
From: Arnd Bergmann @ 2013-01-31 17:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1731670.s76EGcEZ7m@wuerfel>
This is what I think it would look like to do a default platform
with an empty machine descriptor on ARM. It makes the few required
entries in the descriptor optional by using the new irqchip_init()
and clocksource_of_init() functions as defaults, and adds
a fallback for the DT case to customize_machine to probe all
the default devices.
For the case that CONFIG_MULTIPLATFORM is enabled, it then
adds a machine descriptor that never matches any machine but
is used as a fallback if nothing else matches.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 3e3444e..8ff1d38 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -979,7 +979,6 @@ config ARCH_MULTI_V7
bool "ARMv7 based platforms (Cortex-A, PJ4, Krait)"
default y
select ARCH_MULTI_V6_V7
- select ARCH_VEXPRESS
select CPU_V7
config ARCH_MULTI_V6_V7
diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
index 70f1bde..e6e34ba 100644
--- a/arch/arm/kernel/devtree.c
+++ b/arch/arm/kernel/devtree.c
@@ -180,6 +180,13 @@ struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys)
unsigned long dt_root;
const char *model;
+ if (IS_ENABLED(CONFIG_ARCH_MULTIPLATFORM)) {
+ DT_MACHINE_START(GENERIC_DT, "Generic DT based system")
+ MACHINE_END
+
+ mdesc_best = (struct machine_desc *)&__mach_desc_GENERIC_DT;
+ }
+
if (!dt_phys)
return NULL;
@@ -199,7 +206,7 @@ struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys)
mdesc_score = score;
}
}
- if (!mdesc_best) {
+ if (!mdesc_best && !IS_ENABLED(CONFIG_ARCH_MULTIPLATFORM)) {
const char *prop;
long size;
diff --git a/arch/arm/kernel/irq.c b/arch/arm/kernel/irq.c
index 8e4ef4c..df6f9a1 100644
--- a/arch/arm/kernel/irq.c
+++ b/arch/arm/kernel/irq.c
@@ -26,6 +26,7 @@
#include <linux/ioport.h>
#include <linux/interrupt.h>
#include <linux/irq.h>
+#include <linux/irqchip.h>
#include <linux/random.h>
#include <linux/smp.h>
#include <linux/init.h>
@@ -114,7 +115,10 @@ EXPORT_SYMBOL_GPL(set_irq_flags);
void __init init_IRQ(void)
{
- machine_desc->init_irq();
+ if (machine_desc->init_irq)
+ machine_desc->init_irq();
+ else
+ irqchip_init();
}
#ifdef CONFIG_MULTI_IRQ_HANDLER
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 3f6cbb2..1d40c9d 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -18,6 +18,7 @@
#include <linux/bootmem.h>
#include <linux/seq_file.h>
#include <linux/screen_info.h>
+#include <linux/of_platform.h>
#include <linux/init.h>
#include <linux/kexec.h>
#include <linux/of_fdt.h>
@@ -640,9 +641,17 @@ struct screen_info screen_info = {
static int __init customize_machine(void)
{
- /* customizes platform devices, or adds new ones */
+ /*
+ * customizes platform devices, or adds new ones
+ * On DT based machines, we fall back to populating the
+ * machine from the device tree, if no callback is provided,
+ * otherwise we would always need an init_machine callback.
+ */
if (machine_desc->init_machine)
machine_desc->init_machine();
+ else
+ of_platform_populate(NULL, of_default_bus_match_table,
+ NULL, NULL);
return 0;
}
arch_initcall(customize_machine);
@@ -732,7 +741,7 @@ void __init setup_arch(char **cmdline_p)
setup_processor();
mdesc = setup_machine_fdt(__atags_pointer);
- if (!mdesc)
+ if (!mdesc && __machine_arch_type != ~0)
mdesc = setup_machine_tags(__atags_pointer, __machine_arch_type);
machine_desc = mdesc;
machine_name = mdesc->name;
diff --git a/arch/arm/kernel/time.c b/arch/arm/kernel/time.c
index 955d92d..abff4e9 100644
--- a/arch/arm/kernel/time.c
+++ b/arch/arm/kernel/time.c
@@ -22,6 +22,7 @@
#include <linux/errno.h>
#include <linux/profile.h>
#include <linux/timer.h>
+#include <linux/clocksource.h>
#include <linux/irq.h>
#include <asm/thread_info.h>
@@ -115,6 +116,10 @@ int __init register_persistent_clock(clock_access_fn read_boot,
void __init time_init(void)
{
- machine_desc->init_time();
+ if (machine_desc->init_time)
+ machine_desc->init_time();
+ else
+ clocksource_of_init();
+
sched_clock_postinit();
}
diff --git a/drivers/irqchip/irqchip.c b/drivers/irqchip/irqchip.c
index f496afc..c5e7a45 100644
--- a/drivers/irqchip/irqchip.c
+++ b/drivers/irqchip/irqchip.c
@@ -24,7 +24,13 @@ irqchip_of_match_end __used __section(__irqchip_of_end);
extern struct of_device_id __irqchip_begin[];
+#ifdef CONFIG_IRQCHIP
void __init irqchip_init(void)
{
of_irq_init(__irqchip_begin);
}
+#else
+static inline void irqchip_init(void)
+{
+}
+#endif
diff --git a/include/linux/clocksource.h b/include/linux/clocksource.h
index 7944f14..b14d224 100644
--- a/include/linux/clocksource.h
+++ b/include/linux/clocksource.h
@@ -339,6 +339,10 @@ extern void clocksource_of_init(void);
static const struct of_device_id __clksrc_of_table_##name \
__used __section(__clksrc_of_table) \
= { .compatible = compat, .data = fn };
+#else
+static inline void clocksource_of_init(void)
+{
+}
#endif
#endif /* _LINUX_CLOCKSOURCE_H */
^ permalink raw reply related
* [PATCH 4/4] pinctrl/abx500: destroy mutex if returning early due to error
From: Lee Jones @ 2013-01-31 17:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <510AA9BA.8080704@wwwdotorg.org>
On Thu, 31 Jan 2013, Stephen Warren wrote:
> On 01/31/2013 01:01 AM, Lee Jones wrote:
> > On Wed, 30 Jan 2013, Stephen Warren wrote:
> >
> >> On 01/30/2013 12:40 PM, Linus Walleij wrote:
> >>> From: Lee Jones <lee.jones@linaro.org>
> >>>
> >>> Current failure path neglects to mutex_destroy() before returning
> >>> an error due to an invalid parameter or an error received from
> >>> gpiochip_add(). This patch aims to remedy that behaviour.
> >>
> >>> diff --git a/drivers/pinctrl/pinctrl-abx500.c b/drivers/pinctrl/pinctrl-abx500.c
> >>
> >>> @@ -1155,11 +1155,13 @@ static int abx500_gpio_probe(struct platform_device *pdev)
> >>> default:
> >>> dev_err(&pdev->dev, "Unsupported pinctrl sub driver (%d)\n",
> >>> (int) platid->driver_data);
> >>> + mutex_destroy(&pct->lock);
> >>> return -EINVAL;
> >>
> >> Especially given there's already a label out_free which performs this
> >> mutex_destroy(), those last two lines would be better as:
> >>
> >> ret = -EINVAL;
> >> goto out_free;
> >
> > Yes, that's one way of doing it. I figured it was 6 of one and half a
> > dozen of the other to be honest.
> >
> > Either I:
> >
> > + mutex_destroy(&pct->lock);
> >
> > Or:
> >
> > + ret = -EINVAL;
> > + goto out_free;
> > - return -EINVAL;
> >
> > I figured the smallest diff would be best. To be honest, I'm not
> > bothered either way. If it offends you, I can do it the other way, no
> > problem. Just let me know quick, so I can get the fixed up patch to
> > Linus.
> >
> > NB: There is no 'out_free:' at this point, it has already been
> > removed.
>
> Where has it been removed? Both the latest linux-next and LinusW's
> pinctrl tree on git.kernel.org still contain it...
It's an ordering thing. I submitted a 13 patch patch-set to Linus
which completely reworks the driver. One of the first things I did was
to remove all IRQ handling from the driver and pass responsibility over
to the AB8500 core driver. However, there were some issues with some
of the patches, so Linus decided it would be better to get the simple
stuff out of the way whilst I fixup the more complex IRQ stuff. This
was one of the simple patches which was located at the 'end' of the
patch-set. I don't think you've seen the other stuff yet.
> The style in that code is clearly "goto foo" for error-handling, and
> makes for smaller simpler code, so I don't see why the label would be
> removed.
>
> Still, this review is just a suggestion; this driver isn't anything I
> have any ownership of, so I guess feel free to go either way.
I too am easy and would be happy to go either way. The implementation
now only has one goto for post gpiochip_add() stuff. As I say, the
others have now been removed as they pertained to IRQ stuff.
Sorry for any confusion.
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCHv5 00/16] Unify arm_generic and arch_timer drivers
From: Stephen Warren @ 2013-01-31 17:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359634539-9580-1-git-send-email-mark.rutland@arm.com>
On 01/31/2013 05:15 AM, Mark Rutland wrote:
> This is an updated version of v4 of the series I posted 2 weeks ago [1].
>
> The only change is the last two patches, moving over to always using the
> virtual counters. I've left these as separate patches rather than
> folding them in to allow them to be reviewed more easily.
>
> I've tested the series on a TC2 and an AArch64 model, and I'm happy that
> it all works.
>
> Stephen, Thomas:
>
> I've not folded the CLOCKSOURCE_OF_DECLARE patch as it's unclear what
> path everything is going to take, and I don't a have a tree with
> Stephen's patch that I can base on.
I'm pretty sure it'll go through arm-soc's timer/cleanup branch. At the
very least, it'd have to go through some tree based on that...
> There's already a dependency on the timer broadcast rework, and adding
> more branches to the mix is going to get messy. I can take the version
> with ifdefs under the assumption we remove them in a later patch once
> Stephen's patch is in. Does that sound ok?
Just one more simple merge:-)
But yet, it's a simple cleanup to do later, so I have no problem with that.
^ permalink raw reply
* [PATCH v2 4/4] irqchip: gic: Perform the gic_secondary_init() call via CPU notifier
From: Nicolas Pitre @ 2013-01-31 17:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130131112538.GW23505@n2100.arm.linux.org.uk>
On Thu, 31 Jan 2013, Russell King - ARM Linux wrote:
> I haven't tried Versatile Express yet as it has the TC2 tile on, and I
> don't yet a boot loader on it which is capable of TFTP (which makes it
> rather useless to me - I've been saying this for a time now but this is
> probably the first time publically.) I'm thinking about putting the
> CA9x4 tile back on because that's a lot more functionally useful to me
> than TC2.
You might be interested by this then:
http://lists.linaro.org/pipermail/linaro-dev/2012-October/014136.html
Nicolas
^ permalink raw reply
* [PATCH 4/4] pinctrl/abx500: destroy mutex if returning early due to error
From: Stephen Warren @ 2013-01-31 17:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130131080151.GA5301@gmail.com>
On 01/31/2013 01:01 AM, Lee Jones wrote:
> On Wed, 30 Jan 2013, Stephen Warren wrote:
>
>> On 01/30/2013 12:40 PM, Linus Walleij wrote:
>>> From: Lee Jones <lee.jones@linaro.org>
>>>
>>> Current failure path neglects to mutex_destroy() before returning
>>> an error due to an invalid parameter or an error received from
>>> gpiochip_add(). This patch aims to remedy that behaviour.
>>
>>> diff --git a/drivers/pinctrl/pinctrl-abx500.c b/drivers/pinctrl/pinctrl-abx500.c
>>
>>> @@ -1155,11 +1155,13 @@ static int abx500_gpio_probe(struct platform_device *pdev)
>>> default:
>>> dev_err(&pdev->dev, "Unsupported pinctrl sub driver (%d)\n",
>>> (int) platid->driver_data);
>>> + mutex_destroy(&pct->lock);
>>> return -EINVAL;
>>
>> Especially given there's already a label out_free which performs this
>> mutex_destroy(), those last two lines would be better as:
>>
>> ret = -EINVAL;
>> goto out_free;
>
> Yes, that's one way of doing it. I figured it was 6 of one and half a
> dozen of the other to be honest.
>
> Either I:
>
> + mutex_destroy(&pct->lock);
>
> Or:
>
> + ret = -EINVAL;
> + goto out_free;
> - return -EINVAL;
>
> I figured the smallest diff would be best. To be honest, I'm not
> bothered either way. If it offends you, I can do it the other way, no
> problem. Just let me know quick, so I can get the fixed up patch to
> Linus.
>
> NB: There is no 'out_free:' at this point, it has already been
> removed.
Where has it been removed? Both the latest linux-next and LinusW's
pinctrl tree on git.kernel.org still contain it...
The style in that code is clearly "goto foo" for error-handling, and
makes for smaller simpler code, so I don't see why the label would be
removed.
Still, this review is just a suggestion; this driver isn't anything I
have any ownership of, so I guess feel free to go either way.
^ permalink raw reply
* [PATCH v3 03/15] ARM: mcpm: introduce helpers for platform coherency exit/setup
From: Nicolas Pitre @ 2013-01-31 17:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <510A96F7.8090106@ti.com>
On Thu, 31 Jan 2013, Santosh Shilimkar wrote:
> On Tuesday 29 January 2013 01:20 PM, Nicolas Pitre wrote:
> > From: Dave Martin <dave.martin@linaro.org>
> >
> > This provides helper methods to coordinate between CPUs coming down
> > and CPUs going up, as well as documentation on the used algorithms,
> > so that cluster teardown and setup
> > operations are not done for a cluster simultaneously.
> >
> > For use in the power_down() implementation:
> > * __mcpm_cpu_going_down(unsigned int cluster, unsigned int cpu)
> > * __mcpm_outbound_enter_critical(unsigned int cluster)
> > * __mcpm_outbound_leave_critical(unsigned int cluster)
> > * __mcpm_cpu_down(unsigned int cluster, unsigned int cpu)
> >
> > The power_up_setup() helper should do platform-specific setup in
> > preparation for turning the CPU on, such as invalidating local caches
> > or entering coherency. It must be assembler for now, since it must
> > run before the MMU can be switched on. It is passed the affinity level
> > which should be initialized.
> >
> > Because the mcpm_sync_struct content is looked-up and modified
> > with the cache enabled or disabled depending on the code path, it is
> > crucial to always ensure proper cache maintenance to update main memory
> > right away. Therefore, any cached write must be followed by a cache
> > clean operation and any cached read must be preceded by a cache
> > invalidate operation (actually a cache flush i.e. clean+invalidate to
> > avoid discarding possible concurrent writes) on the accessed memory.
> >
> > Also, in order to prevent a cached writer from interfering with an
> > adjacent non-cached writer, we ensure each state variable is located to
> > a separate cache line.
> >
> > Thanks to Nicolas Pitre and Achin Gupta for the help with this
> > patch.
> >
> > Signed-off-by: Dave Martin <dave.martin@linaro.org>
> > ---
> [..]
>
> > diff --git a/arch/arm/common/mcpm_entry.c b/arch/arm/common/mcpm_entry.c
> > index c8c0e2113e..2b83121966 100644
> > --- a/arch/arm/common/mcpm_entry.c
> > +++ b/arch/arm/common/mcpm_entry.c
> > @@ -18,6 +18,7 @@
> > #include <asm/proc-fns.h>
> > #include <asm/cacheflush.h>
> > #include <asm/idmap.h>
> > +#include <asm/cputype.h>
> >
> > extern volatile unsigned long
> > mcpm_entry_vectors[MAX_NR_CLUSTERS][MAX_CPUS_PER_CLUSTER];
> >
> [...]
>
> > +/*
> > + * Ensure preceding writes to *p by other CPUs are visible to
> > + * subsequent reads by this CPU. We must be careful not to
> > + * discard data simultaneously written by another CPU, hence the
> > + * usage of flush rather than invalidate operations.
> > + */
> > +static void __sync_range_r(volatile void *p, size_t size)
> > +{
> > + char *_p = (char *)p;
> > +
> > +#ifdef CONFIG_OUTER_CACHE
> > + if (outer_cache.flush_range) {
> > +
> You don't need above #ifdef. In case of non-outer
> cache the function pointer is null anyways.
We do need the #ifdef, because if CONFIG_OUTER_CACHE is not selected
then the outer_cache structure simply doesn't exist.
> /*
> > + * Ensure dirty data migrated from other CPUs into our cache
> > + * are cleaned out safely before the outer cache is cleaned:
> > + */
> > + __cpuc_clean_dcache_area(_p, size);
> > +
> > + /* Clean and invalidate stale data for *p from outer ... */
> > + outer_flush_range(__pa(_p), __pa(_p + size));
> > + }
> > +#endif
> > +
> > + /* ... and inner cache: */
> > + __cpuc_flush_dcache_area(_p, size);
> This will be un-necessary when inner cache is available, no ?
> May be you can re-arrange the code like below, unless and until
> you would like to invalidate any speculative fetches during the
> outer_flush_range()
>
> __cpuc_clean_dcache_area(_p, size);
> if (outer_cache.flush_range)
> outer_flush_range(__pa(_p), __pa(_p + size));
As you said, the code is sequenced that way to get rid of potential
speculative fetch that could happen right before L2 is flushed.
See discussion here:
http://article.gmane.org/gmane.linux.ports.arm.kernel/208887
Nicolas
^ permalink raw reply
* [PATCHv2 for soc 4/4] arm: socfpga: Add SMP support for actual socfpga harware
From: dinguyen at altera.com @ 2013-01-31 17:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359651943-21752-1-git-send-email-dinguyen@altera.com>
From: Dinh Nguyen <dinguyen@altera.com>
Because the CPU1 start address is different for socfpga-vt and
socfpga-cyclone5, we add code to use the correct CPU1 start addr.
Signed-off-by: Dinh Nguyen <dinguyen@altera.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Olof Johansson <olof@lixom.net>
Cc: Pavel Machek <pavel@denx.de>
---
.../bindings/arm/altera/socfpga-system.txt | 2 ++
arch/arm/boot/dts/socfpga_cyclone5.dts | 4 ++++
arch/arm/boot/dts/socfpga_vt.dts | 4 ++++
arch/arm/mach-socfpga/core.h | 4 +++-
arch/arm/mach-socfpga/headsmp.S | 16 ++++++++++++----
arch/arm/mach-socfpga/platsmp.c | 3 ++-
arch/arm/mach-socfpga/socfpga.c | 8 ++++++++
7 files changed, 35 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/altera/socfpga-system.txt b/Documentation/devicetree/bindings/arm/altera/socfpga-system.txt
index 07c65e3..f4d04a0 100644
--- a/Documentation/devicetree/bindings/arm/altera/socfpga-system.txt
+++ b/Documentation/devicetree/bindings/arm/altera/socfpga-system.txt
@@ -3,9 +3,11 @@ Altera SOCFPGA System Manager
Required properties:
- compatible : "altr,sys-mgr"
- reg : Should contain 1 register ranges(address and length)
+- cpu1-start-addr : CPU1 start address in hex.
Example:
sysmgr at ffd08000 {
compatible = "altr,sys-mgr";
reg = <0xffd08000 0x1000>;
+ cpu1-start-addr = <0xffd080c4>;
};
diff --git a/arch/arm/boot/dts/socfpga_cyclone5.dts b/arch/arm/boot/dts/socfpga_cyclone5.dts
index 7ad3cc6..3ae8a83 100644
--- a/arch/arm/boot/dts/socfpga_cyclone5.dts
+++ b/arch/arm/boot/dts/socfpga_cyclone5.dts
@@ -56,5 +56,9 @@
serial1 at ffc03000 {
clock-frequency = <100000000>;
};
+
+ sysmgr at ffd08000 {
+ cpu1-start-addr = <0xffd080c4>;
+ };
};
};
diff --git a/arch/arm/boot/dts/socfpga_vt.dts b/arch/arm/boot/dts/socfpga_vt.dts
index a0c6c65..1036eba 100644
--- a/arch/arm/boot/dts/socfpga_vt.dts
+++ b/arch/arm/boot/dts/socfpga_vt.dts
@@ -56,5 +56,9 @@
serial1 at ffc03000 {
clock-frequency = <7372800>;
};
+
+ sysmgr at ffd08000 {
+ cpu1-start-addr = <0xffd08010>;
+ };
};
};
diff --git a/arch/arm/mach-socfpga/core.h b/arch/arm/mach-socfpga/core.h
index 9941caa..5b76dd4 100644
--- a/arch/arm/mach-socfpga/core.h
+++ b/arch/arm/mach-socfpga/core.h
@@ -20,7 +20,7 @@
#ifndef __MACH_CORE_H
#define __MACH_CORE_H
-extern void secondary_startup(void);
+extern void v7_secondary_startup(void);
extern void __iomem *socfpga_scu_base_addr;
extern void socfpga_init_clocks(void);
@@ -29,6 +29,8 @@ extern void socfpga_sysmgr_init(void);
extern struct smp_operations socfpga_smp_ops;
extern char secondary_trampoline, secondary_trampoline_end;
+extern unsigned long cpu1start_addr;
+
#define SOCFPGA_SCU_VIRT_BASE 0xfffec000
#endif
diff --git a/arch/arm/mach-socfpga/headsmp.S b/arch/arm/mach-socfpga/headsmp.S
index f09b128..3c83582 100644
--- a/arch/arm/mach-socfpga/headsmp.S
+++ b/arch/arm/mach-socfpga/headsmp.S
@@ -13,13 +13,21 @@
__CPUINIT
.arch armv7-a
-#define CPU1_START_ADDR 0xffd08010
-
ENTRY(secondary_trampoline)
- movw r0, #:lower16:CPU1_START_ADDR
- movt r0, #:upper16:CPU1_START_ADDR
+ movw r2, #:lower16:cpu1start_addr
+ movt r2, #:upper16:cpu1start_addr
+
+ /* The socfpga VT cannot handle a 0xC0000000 page offset when loading
+ the cpu1start_addr, we bit clear it. Tested on HW and VT. */
+ bic r2, r2, #0x40000000
+ ldr r0, [r2]
ldr r1, [r0]
bx r1
ENTRY(secondary_trampoline_end)
+
+ENTRY(v7_secondary_startup)
+ bl v7_invalidate_l1
+ b secondary_startup
+ENDPROC(v7_secondary_startup)
diff --git a/arch/arm/mach-socfpga/platsmp.c b/arch/arm/mach-socfpga/platsmp.c
index 68dd1b6..c428519 100644
--- a/arch/arm/mach-socfpga/platsmp.c
+++ b/arch/arm/mach-socfpga/platsmp.c
@@ -49,7 +49,8 @@ static int __cpuinit socfpga_boot_secondary(unsigned int cpu, struct task_struct
memcpy(phys_to_virt(0), &secondary_trampoline, trampoline_size);
- __raw_writel(virt_to_phys(secondary_startup), (sys_manager_base_addr+0x10));
+ __raw_writel(virt_to_phys(v7_secondary_startup),
+ (sys_manager_base_addr + (cpu1start_addr & 0x000000ff)));
flush_cache_all();
smp_wmb();
diff --git a/arch/arm/mach-socfpga/socfpga.c b/arch/arm/mach-socfpga/socfpga.c
index 198f491..5a56370 100644
--- a/arch/arm/mach-socfpga/socfpga.c
+++ b/arch/arm/mach-socfpga/socfpga.c
@@ -29,6 +29,7 @@
void __iomem *socfpga_scu_base_addr = ((void __iomem *)(SOCFPGA_SCU_VIRT_BASE));
void __iomem *sys_manager_base_addr;
void __iomem *rst_manager_base_addr;
+unsigned long cpu1start_addr;
static struct map_desc scu_io_desc __initdata = {
.virtual = SOCFPGA_SCU_VIRT_BASE,
@@ -72,6 +73,13 @@ void __init socfpga_sysmgr_init(void)
struct device_node *np;
np = of_find_compatible_node(NULL, NULL, "altr,sys-mgr");
+
+ if (of_property_read_u32(np, "cpu1-start-addr",
+ (u32 *) &cpu1start_addr)) {
+ early_printk("Need cpu1-start-addr in device tree.\n");
+ panic("Need cpu1-start-addr in device tree.\n");
+ }
+
sys_manager_base_addr = of_iomap(np, 0);
np = of_find_compatible_node(NULL, NULL, "altr,rst-mgr");
--
1.7.9.5
^ permalink raw reply related
* [PATCHv2 for soc 3/4] arm: Add v7_invalidate_l1 to cache-v7.S
From: dinguyen at altera.com @ 2013-01-31 17:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359651943-21752-1-git-send-email-dinguyen@altera.com>
From: Dinh Nguyen <dinguyen@altera.com>
mach-socfpga is another platform that needs to use
v7_invalidate_l1 to bringup additional cores. There was a comment that
the ideal place for v7_invalidate_l1 should be in arm/mm/cache-v7.S
Signed-off-by: Dinh Nguyen <dinguyen@altera.com>
Acked-by: Simon Horman <horms+renesas@verge.net.au>
Tested-by: Pavel Machek <pavel@denx.de>
Reviewed-by: Pavel Machek <pavel@denx.de>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Olof Johansson <olof@lixom.net>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: Magnus Damm <magnus.damm@gmail.com>
Cc: Stephen Warren <swarren@wwwdotorg.org>
---
arch/arm/mach-imx/headsmp.S | 47 -------------------------------------
arch/arm/mach-shmobile/headsmp.S | 48 --------------------------------------
arch/arm/mach-tegra/headsmp.S | 43 ----------------------------------
arch/arm/mm/cache-v7.S | 46 ++++++++++++++++++++++++++++++++++++
4 files changed, 46 insertions(+), 138 deletions(-)
diff --git a/arch/arm/mach-imx/headsmp.S b/arch/arm/mach-imx/headsmp.S
index 7e49deb..921fc15 100644
--- a/arch/arm/mach-imx/headsmp.S
+++ b/arch/arm/mach-imx/headsmp.S
@@ -17,53 +17,6 @@
.section ".text.head", "ax"
-/*
- * The secondary kernel init calls v7_flush_dcache_all before it enables
- * the L1; however, the L1 comes out of reset in an undefined state, so
- * the clean + invalidate performed by v7_flush_dcache_all causes a bunch
- * of cache lines with uninitialized data and uninitialized tags to get
- * written out to memory, which does really unpleasant things to the main
- * processor. We fix this by performing an invalidate, rather than a
- * clean + invalidate, before jumping into the kernel.
- *
- * This funciton is cloned from arch/arm/mach-tegra/headsmp.S, and needs
- * to be called for both secondary cores startup and primary core resume
- * procedures. Ideally, it should be moved into arch/arm/mm/cache-v7.S.
- */
-ENTRY(v7_invalidate_l1)
- mov r0, #0
- mcr p15, 0, r0, c7, c5, 0 @ invalidate I cache
- mcr p15, 2, r0, c0, c0, 0
- mrc p15, 1, r0, c0, c0, 0
-
- ldr r1, =0x7fff
- and r2, r1, r0, lsr #13
-
- ldr r1, =0x3ff
-
- and r3, r1, r0, lsr #3 @ NumWays - 1
- add r2, r2, #1 @ NumSets
-
- and r0, r0, #0x7
- add r0, r0, #4 @ SetShift
-
- clz r1, r3 @ WayShift
- add r4, r3, #1 @ NumWays
-1: sub r2, r2, #1 @ NumSets--
- mov r3, r4 @ Temp = NumWays
-2: subs r3, r3, #1 @ Temp--
- mov r5, r3, lsl r1
- mov r6, r2, lsl r0
- orr r5, r5, r6 @ Reg = (Temp<<WayShift)|(NumSets<<SetShift)
- mcr p15, 0, r5, c7, c6, 2
- bgt 2b
- cmp r2, #0
- bgt 1b
- dsb
- isb
- mov pc, lr
-ENDPROC(v7_invalidate_l1)
-
#ifdef CONFIG_SMP
ENTRY(v7_secondary_startup)
bl v7_invalidate_l1
diff --git a/arch/arm/mach-shmobile/headsmp.S b/arch/arm/mach-shmobile/headsmp.S
index b202c12..96001fd 100644
--- a/arch/arm/mach-shmobile/headsmp.S
+++ b/arch/arm/mach-shmobile/headsmp.S
@@ -16,54 +16,6 @@
__CPUINIT
-/* Cache invalidation nicked from arch/arm/mach-imx/head-v7.S, thanks!
- *
- * The secondary kernel init calls v7_flush_dcache_all before it enables
- * the L1; however, the L1 comes out of reset in an undefined state, so
- * the clean + invalidate performed by v7_flush_dcache_all causes a bunch
- * of cache lines with uninitialized data and uninitialized tags to get
- * written out to memory, which does really unpleasant things to the main
- * processor. We fix this by performing an invalidate, rather than a
- * clean + invalidate, before jumping into the kernel.
- *
- * This funciton is cloned from arch/arm/mach-tegra/headsmp.S, and needs
- * to be called for both secondary cores startup and primary core resume
- * procedures. Ideally, it should be moved into arch/arm/mm/cache-v7.S.
- */
-ENTRY(v7_invalidate_l1)
- mov r0, #0
- mcr p15, 0, r0, c7, c5, 0 @ invalidate I cache
- mcr p15, 2, r0, c0, c0, 0
- mrc p15, 1, r0, c0, c0, 0
-
- ldr r1, =0x7fff
- and r2, r1, r0, lsr #13
-
- ldr r1, =0x3ff
-
- and r3, r1, r0, lsr #3 @ NumWays - 1
- add r2, r2, #1 @ NumSets
-
- and r0, r0, #0x7
- add r0, r0, #4 @ SetShift
-
- clz r1, r3 @ WayShift
- add r4, r3, #1 @ NumWays
-1: sub r2, r2, #1 @ NumSets--
- mov r3, r4 @ Temp = NumWays
-2: subs r3, r3, #1 @ Temp--
- mov r5, r3, lsl r1
- mov r6, r2, lsl r0
- orr r5, r5, r6 @ Reg = (Temp<<WayShift)|(NumSets<<SetShift)
- mcr p15, 0, r5, c7, c6, 2
- bgt 2b
- cmp r2, #0
- bgt 1b
- dsb
- isb
- mov pc, lr
-ENDPROC(v7_invalidate_l1)
-
ENTRY(shmobile_invalidate_start)
bl v7_invalidate_l1
b secondary_startup
diff --git a/arch/arm/mach-tegra/headsmp.S b/arch/arm/mach-tegra/headsmp.S
index 4a317fa..fb082c4 100644
--- a/arch/arm/mach-tegra/headsmp.S
+++ b/arch/arm/mach-tegra/headsmp.S
@@ -18,49 +18,6 @@
.section ".text.head", "ax"
__CPUINIT
-/*
- * Tegra specific entry point for secondary CPUs.
- * The secondary kernel init calls v7_flush_dcache_all before it enables
- * the L1; however, the L1 comes out of reset in an undefined state, so
- * the clean + invalidate performed by v7_flush_dcache_all causes a bunch
- * of cache lines with uninitialized data and uninitialized tags to get
- * written out to memory, which does really unpleasant things to the main
- * processor. We fix this by performing an invalidate, rather than a
- * clean + invalidate, before jumping into the kernel.
- */
-ENTRY(v7_invalidate_l1)
- mov r0, #0
- mcr p15, 2, r0, c0, c0, 0
- mrc p15, 1, r0, c0, c0, 0
-
- ldr r1, =0x7fff
- and r2, r1, r0, lsr #13
-
- ldr r1, =0x3ff
-
- and r3, r1, r0, lsr #3 @ NumWays - 1
- add r2, r2, #1 @ NumSets
-
- and r0, r0, #0x7
- add r0, r0, #4 @ SetShift
-
- clz r1, r3 @ WayShift
- add r4, r3, #1 @ NumWays
-1: sub r2, r2, #1 @ NumSets--
- mov r3, r4 @ Temp = NumWays
-2: subs r3, r3, #1 @ Temp--
- mov r5, r3, lsl r1
- mov r6, r2, lsl r0
- orr r5, r5, r6 @ Reg = (Temp<<WayShift)|(NumSets<<SetShift)
- mcr p15, 0, r5, c7, c6, 2
- bgt 2b
- cmp r2, #0
- bgt 1b
- dsb
- isb
- mov pc, lr
-ENDPROC(v7_invalidate_l1)
-
ENTRY(tegra_secondary_startup)
bl v7_invalidate_l1
diff --git a/arch/arm/mm/cache-v7.S b/arch/arm/mm/cache-v7.S
index 7539ec2..15451ee 100644
--- a/arch/arm/mm/cache-v7.S
+++ b/arch/arm/mm/cache-v7.S
@@ -19,6 +19,52 @@
#include "proc-macros.S"
/*
+ * The secondary kernel init calls v7_flush_dcache_all before it enables
+ * the L1; however, the L1 comes out of reset in an undefined state, so
+ * the clean + invalidate performed by v7_flush_dcache_all causes a bunch
+ * of cache lines with uninitialized data and uninitialized tags to get
+ * written out to memory, which does really unpleasant things to the main
+ * processor. We fix this by performing an invalidate, rather than a
+ * clean + invalidate, before jumping into the kernel.
+ *
+ * This function is cloned from arch/arm/mach-tegra/headsmp.S, and needs
+ * to be called for both secondary cores startup and primary core resume
+ * procedures.
+ */
+ENTRY(v7_invalidate_l1)
+ mov r0, #0
+ mcr p15, 2, r0, c0, c0, 0
+ mrc p15, 1, r0, c0, c0, 0
+
+ ldr r1, =0x7fff
+ and r2, r1, r0, lsr #13
+
+ ldr r1, =0x3ff
+
+ and r3, r1, r0, lsr #3 @ NumWays - 1
+ add r2, r2, #1 @ NumSets
+
+ and r0, r0, #0x7
+ add r0, r0, #4 @ SetShift
+
+ clz r1, r3 @ WayShift
+ add r4, r3, #1 @ NumWays
+1: sub r2, r2, #1 @ NumSets--
+ mov r3, r4 @ Temp = NumWays
+2: subs r3, r3, #1 @ Temp--
+ mov r5, r3, lsl r1
+ mov r6, r2, lsl r0
+ orr r5, r5, r6 @ Reg = (Temp<<WayShift)|(NumSets<<SetShift)
+ mcr p15, 0, r5, c7, c6, 2
+ bgt 2b
+ cmp r2, #0
+ bgt 1b
+ dsb
+ isb
+ mov pc, lr
+ENDPROC(v7_invalidate_l1)
+
+/*
* v7_flush_icache_all()
*
* Flush the whole I-cache.
--
1.7.9.5
^ permalink raw reply related
* [PATCHv2 for soc 2/4] arm: socfpga: Add entries to enable make dtbs socfpga
From: dinguyen at altera.com @ 2013-01-31 17:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359651943-21752-1-git-send-email-dinguyen@altera.com>
From: Dinh Nguyen <dinguyen@altera.com>
Signed-off-by: Dinh Nguyen <dinguyen@altera.com>
Tested-by: Pavel Machek <pavel@denx.de>
Reviewed-by: Pavel Machek <pavel@denx.de>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Olof Johansson <olof@lixom.net>
Cc: Pavel Machek <pavel@denx.de>
---
arch/arm/boot/dts/Makefile | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 5ebb44f..1b8276c 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -124,6 +124,8 @@ dtb-$(CONFIG_ARCH_SHMOBILE) += emev2-kzm9d.dtb \
r8a7740-armadillo800eva.dtb \
sh73a0-kzm9g.dtb \
sh7372-mackerel.dtb
+dtb-$(CONFIG_ARCH_SOCFPGA) += socfpga_cyclone5.dtb \
+ socfpga_vt.dtb
dtb-$(CONFIG_ARCH_SPEAR13XX) += spear1310-evb.dtb \
spear1340-evb.dtb
dtb-$(CONFIG_ARCH_SPEAR3XX)+= spear300-evb.dtb \
--
1.7.9.5
^ permalink raw reply related
* [PATCHv2 for soc 1/4] arm: socfpga: Add new device tree source for actual socfpga HW
From: dinguyen at altera.com @ 2013-01-31 17:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359651943-21752-1-git-send-email-dinguyen@altera.com>
From: Dinh Nguyen <dinguyen@altera.com>
Up to this point, support for socfpga has only been on a virtual
platform. Now that actual hardware is available, we add the appropriate
device tree source files.
Signed-off-by: Dinh Nguyen <dinguyen@altera.com>
Tested-by: Pavel Machek <pavel@denx.de>
Reviewed-by: Pavel Machek <pavel@denx.de>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Olof Johansson <olof@lixom.net>
---
arch/arm/boot/dts/socfpga.dtsi | 22 ++++++------
arch/arm/boot/dts/socfpga_cyclone5.dts | 30 ++++++++++++++--
arch/arm/boot/dts/socfpga_vt.dts | 60 ++++++++++++++++++++++++++++++++
arch/arm/mach-socfpga/socfpga.c | 1 +
4 files changed, 99 insertions(+), 14 deletions(-)
create mode 100644 arch/arm/boot/dts/socfpga_vt.dts
diff --git a/arch/arm/boot/dts/socfpga.dtsi b/arch/arm/boot/dts/socfpga.dtsi
index 19aec42..936d230 100644
--- a/arch/arm/boot/dts/socfpga.dtsi
+++ b/arch/arm/boot/dts/socfpga.dtsi
@@ -25,6 +25,10 @@
ethernet0 = &gmac0;
serial0 = &uart0;
serial1 = &uart1;
+ timer0 = &timer0;
+ timer1 = &timer1;
+ timer2 = &timer2;
+ timer3 = &timer3;
};
cpus {
@@ -98,47 +102,41 @@
interrupts = <1 13 0xf04>;
};
- timer0: timer at ffc08000 {
+ timer0: timer0 at ffc08000 {
compatible = "snps,dw-apb-timer-sp";
interrupts = <0 167 4>;
- clock-frequency = <200000000>;
reg = <0xffc08000 0x1000>;
};
- timer1: timer at ffc09000 {
+ timer1: timer1 at ffc09000 {
compatible = "snps,dw-apb-timer-sp";
interrupts = <0 168 4>;
- clock-frequency = <200000000>;
reg = <0xffc09000 0x1000>;
};
- timer2: timer at ffd00000 {
+ timer2: timer2 at ffd00000 {
compatible = "snps,dw-apb-timer-osc";
interrupts = <0 169 4>;
- clock-frequency = <200000000>;
reg = <0xffd00000 0x1000>;
};
- timer3: timer at ffd01000 {
+ timer3: timer3 at ffd01000 {
compatible = "snps,dw-apb-timer-osc";
interrupts = <0 170 4>;
- clock-frequency = <200000000>;
reg = <0xffd01000 0x1000>;
};
- uart0: uart at ffc02000 {
+ uart0: serial0 at ffc02000 {
compatible = "snps,dw-apb-uart";
reg = <0xffc02000 0x1000>;
- clock-frequency = <7372800>;
interrupts = <0 162 4>;
reg-shift = <2>;
reg-io-width = <4>;
};
- uart1: uart at ffc03000 {
+ uart1: serial1 at ffc03000 {
compatible = "snps,dw-apb-uart";
reg = <0xffc03000 0x1000>;
- clock-frequency = <7372800>;
interrupts = <0 163 4>;
reg-shift = <2>;
reg-io-width = <4>;
diff --git a/arch/arm/boot/dts/socfpga_cyclone5.dts b/arch/arm/boot/dts/socfpga_cyclone5.dts
index ab7e4a9..7ad3cc6 100644
--- a/arch/arm/boot/dts/socfpga_cyclone5.dts
+++ b/arch/arm/boot/dts/socfpga_cyclone5.dts
@@ -20,7 +20,7 @@
/ {
model = "Altera SOCFPGA Cyclone V";
- compatible = "altr,socfpga-cyclone5";
+ compatible = "altr,socfpga-cyclone5", "altr,socfpga";
chosen {
bootargs = "console=ttyS0,57600";
@@ -29,6 +29,32 @@
memory {
name = "memory";
device_type = "memory";
- reg = <0x0 0x10000000>; /* 256MB */
+ reg = <0x0 0x40000000>; /* 1GB */
+ };
+
+ soc {
+ timer0 at ffc08000 {
+ clock-frequency = <100000000>;
+ };
+
+ timer1 at ffc09000 {
+ clock-frequency = <100000000>;
+ };
+
+ timer2 at ffd00000 {
+ clock-frequency = <25000000>;
+ };
+
+ timer3 at ffd01000 {
+ clock-frequency = <25000000>;
+ };
+
+ serial0 at ffc02000 {
+ clock-frequency = <100000000>;
+ };
+
+ serial1 at ffc03000 {
+ clock-frequency = <100000000>;
+ };
};
};
diff --git a/arch/arm/boot/dts/socfpga_vt.dts b/arch/arm/boot/dts/socfpga_vt.dts
new file mode 100644
index 0000000..a0c6c65
--- /dev/null
+++ b/arch/arm/boot/dts/socfpga_vt.dts
@@ -0,0 +1,60 @@
+/*
+ * Copyright (C) 2013 Altera Corporation <www.altera.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+/dts-v1/;
+/include/ "socfpga.dtsi"
+
+/ {
+ model = "Altera SOCFPGA VT";
+ compatible = "altr,socfpga-vt", "altr,socfpga";
+
+ chosen {
+ bootargs = "console=ttyS0,57600";
+ };
+
+ memory {
+ name = "memory";
+ device_type = "memory";
+ reg = <0x0 0x40000000>; /* 1 GB */
+ };
+
+ soc {
+ timer0 at ffc08000 {
+ clock-frequency = <7000000>;
+ };
+
+ timer1 at ffc09000 {
+ clock-frequency = <7000000>;
+ };
+
+ timer2 at ffd00000 {
+ clock-frequency = <7000000>;
+ };
+
+ timer3 at ffd01000 {
+ clock-frequency = <7000000>;
+ };
+
+ serial0 at ffc02000 {
+ clock-frequency = <7372800>;
+ };
+
+ serial1 at ffc03000 {
+ clock-frequency = <7372800>;
+ };
+ };
+};
diff --git a/arch/arm/mach-socfpga/socfpga.c b/arch/arm/mach-socfpga/socfpga.c
index 6732924..198f491 100644
--- a/arch/arm/mach-socfpga/socfpga.c
+++ b/arch/arm/mach-socfpga/socfpga.c
@@ -99,6 +99,7 @@ static void __init socfpga_cyclone5_init(void)
static const char *altera_dt_match[] = {
"altr,socfpga",
"altr,socfpga-cyclone5",
+ "altr,socfpga-vt",
NULL
};
--
1.7.9.5
^ permalink raw reply related
* [PATCHv2 for soc 0/4] Enabling socfpga on hardware
From: dinguyen at altera.com @ 2013-01-31 17:05 UTC (permalink / raw)
To: linux-arm-kernel
From: Dinh Nguyen <dinguyen@altera.com>
V2:
- Remove patch that adds clock entries in the socfpga.dtsi as this
should accompany a rework in drivers/clk and will done in a different
patch series.
- Removed I-cache invalidate from v7_invalidate_l1
- Defined cpu1-start-addr as a device tree entry
- Removed the need to use CONFIG_VMSPLIT_2G
Dinh Nguyen (4):
arm: socfpga: Add new device tree source for actual socfpga HW
arm: socfpga: Add entries to enable make dtbs socfpga
arm: Add v7_invalidate_l1 to cache-v7.S
arm: socfpga: Add SMP support for actual socfpga harware
.../bindings/arm/altera/socfpga-system.txt | 2 +
arch/arm/boot/dts/Makefile | 2 +
arch/arm/boot/dts/socfpga.dtsi | 22 +++----
arch/arm/boot/dts/socfpga_cyclone5.dts | 34 ++++++++++-
arch/arm/boot/dts/socfpga_vt.dts | 64 ++++++++++++++++++++
arch/arm/mach-imx/headsmp.S | 47 --------------
arch/arm/mach-shmobile/headsmp.S | 48 ---------------
arch/arm/mach-socfpga/core.h | 4 +-
arch/arm/mach-socfpga/headsmp.S | 16 +++--
arch/arm/mach-socfpga/platsmp.c | 3 +-
arch/arm/mach-socfpga/socfpga.c | 9 +++
arch/arm/mach-tegra/headsmp.S | 43 -------------
arch/arm/mm/cache-v7.S | 46 ++++++++++++++
13 files changed, 182 insertions(+), 158 deletions(-)
create mode 100644 arch/arm/boot/dts/socfpga_vt.dts
--
1.7.9.5
^ permalink raw reply
* [PATCH v2 19/27] pci: PCIe driver for Marvell Armada 370/XP systems
From: Bjorn Helgaas @ 2013-01-31 17:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130131173343.46514422@skate>
On Thu, Jan 31, 2013 at 9:33 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear Bjorn Helgaas,
>
> On Thu, 31 Jan 2013 09:30:07 -0700, Bjorn Helgaas wrote:
>
>> > Following you're recommendation, I've changed this, and left those
>> > values initialized to 0 by default, in order to let Linux set correct
>> > values. Yes, Linux does assign appropriate values in the Secondary Bus
>> > Number Register. But before that Linux also complains loudly that the
>> > bridge configuration is invalid:
>> >
>> > pci 0000:00:01.0: bridge configuration invalid ([bus 00-00]), reconfiguring
>> > pci 0000:00:02.0: bridge configuration invalid ([bus 00-00]), reconfiguring
>> > pci 0000:00:03.0: bridge configuration invalid ([bus 00-00]), reconfiguring
>> > pci 0000:00:04.0: bridge configuration invalid ([bus 00-00]), reconfiguring
>> > pci 0000:00:05.0: bridge configuration invalid ([bus 00-00]), reconfiguring
>> > pci 0000:00:06.0: bridge configuration invalid ([bus 00-00]), reconfiguring
>>
>> Linux makes the unwarranted assumption that the PCI hierarchy has
>> already been configured by firmware. If the only problem is the
>> messages above, I think we could just rework the message so it doesn't
>> look like an error. I would guess that we probably also see the same
>> distressing message when we hot-add a card with a bridge on it,
>> because firmware won't have initialized the bridge.
>>
>> My rule of thumb is that I like to note something in dmesg about the
>> initial configuration of bus/mem/io apertures and BARs, as well as
>> indications when we update them. That way, the dmesg log should
>> contain enough information to debug most enumeration and configuration
>> defects. pci_scan_bridge() is somewhat lacking in this regard.
>
> Ok. Would something like:
>
> "bridge configuration with unassigned bus numbers ([bus 00-00]), reconfiguring"
>
> be an acceptable to replace this one?
Seems reasonable.
^ permalink raw reply
* OMAP4 PM bootloader dependency problems
From: Paul Walmsley @ 2013-01-31 16:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1301311656230.32145@utopia.booyaka.com>
On Thu, 31 Jan 2013, Paul Walmsley wrote:
> On Thu, 31 Jan 2013, Paul Walmsley wrote:
>
> > Right. I don't have any problem with adding a message to the suspend path
> > also. But I'd like to see a boot-time message added even if
> > CONFIG_CPU_IDLE=n, since it's still possible to enter full-chip retention
> > idle with dynamic idle. In other words, not everyone might use 'echo mem
> > > /sys/power/state'.
>
> (and re-reading my original E-mail to Rajendra, I can see that it was
> nuclear, so I'm sorry about that.)
Hehe, _unclear_. Time to go back to bed...
- Paul
^ permalink raw reply
* OMAP4 PM bootloader dependency problems
From: Paul Walmsley @ 2013-01-31 16:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1301311630090.32145@utopia.booyaka.com>
On Thu, 31 Jan 2013, Paul Walmsley wrote:
> Right. I don't have any problem with adding a message to the suspend path
> also. But I'd like to see a boot-time message added even if
> CONFIG_CPU_IDLE=n, since it's still possible to enter full-chip retention
> idle with dynamic idle. In other words, not everyone might use 'echo mem
> > /sys/power/state'.
(and re-reading my original E-mail to Rajendra, I can see that it was
nuclear, so I'm sorry about that.)
- Paul
^ permalink raw reply
* [PATCH v2 19/27] pci: PCIe driver for Marvell Armada 370/XP systems
From: Russell King - ARM Linux @ 2013-01-31 16:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAErSpo7fPzrF_OZSL7Ss0LT70Qz+veXLW-ihA7fAXCwsn142cQ@mail.gmail.com>
On Thu, Jan 31, 2013 at 09:30:07AM -0700, Bjorn Helgaas wrote:
> Linux makes the unwarranted assumption that the PCI hierarchy has
> already been configured by firmware. If the only problem is the
> messages above, I think we could just rework the message so it doesn't
> look like an error.
That's not a safe assumption, especially on platforms where there's no
BIOS (like ARM platforms). Thankfully, for the platforms I care about,
the boot loaders I wrote for them _do_ do a full bus setup, so I don't
see a problem. :)
However, I have historially had the kernel over many years (probably
around 14 or 15 now) reassign all resources so that things are how the
kernel wants them, and not how my half-hearted attempt at setting them
up did (which only does a limited job enough to get the system to a
state where we can load the kernel.)
^ permalink raw reply
* [v2 1/1] ARM: Add API to detect SCU base address from CP15
From: Hiroshi Doyu @ 2013-01-31 16:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358754175-15484-1-git-send-email-hdoyu@nvidia.com>
Hiroshi Doyu <hdoyu@nvidia.com> wrote @ Mon, 21 Jan 2013 08:42:55 +0100:
> Add API to detect SCU base address from CP15.
>
> Signed-off-by: Hiroshi Doyu <hdoyu@nvidia.com>
> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> ---
> For usage: http://patchwork.ozlabs.org/patch/212013/
> ---
> arch/arm/include/asm/smp_scu.h | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
Please ignore this series. The later version has been already queued for v3.9.
^ permalink raw reply
* [v3 1/9] ARM: tegra: fuse: Add chipid TEGRA114 0x35
From: Hiroshi Doyu @ 2013-01-31 16:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358237598-32413-2-git-send-email-hdoyu@nvidia.com>
Hiroshi Doyu <hdoyu@nvidia.com> wrote @ Tue, 15 Jan 2013 09:13:10 +0100:
> Add tegra_chip_id TEGRA114 0x35
>
> Signed-off-by: Hiroshi Doyu <hdoyu@nvidia.com>
> ---
> arch/arm/mach-tegra/fuse.h | 1 +
> 1 file changed, 1 insertion(+)
Please ignore this series. The later version has been already queued for v3.9.
^ permalink raw reply
* [PATCH] arm: mvebu: support for the new Armada XP evaluation board(DB-MV784MP-GP)
From: Andrew Lunn @ 2013-01-31 16:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130131162254.GD20242@lunn.ch>
On Thu, Jan 31, 2013 at 05:22:54PM +0100, Andrew Lunn wrote:
> > Well in fact it is 4GB RAM but we can only use 3GB (we need the last GB
> > of address space for peripheral, CPU registers and IOmem).
>
> Hi Gregory
>
> Does the CPU support Large Physical Addressing, LPA? Is that on the
> roadmap for Armada?
I did a bit of googling:
http://www.linleygroup.com/newsletters/newsletter_detail.php?num=3982
To address the cloud-computing market, the company added
40-bit physical addressing to Armada XP, using a method
similar to what ARM implemented in Cortex-A15. This feature
allows the memory controller to support up to one terabyte
(1TB) of DRAM.
Also:
http://www.theregister.co.uk/2012/10/24/dell_zinc_arm_server_apache_software/
talks about 40-bit.
So it should be possible to use the full 4GBytes of RAM, in theory.
Andrew
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox