* [PATCH 04/14] ARM: dts: armada-375: Fixup bootrom DT warning
From: Gregory CLEMENT @ 2016-11-10 0:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161110001000.10619-1-gregory.clement@free-electrons.com>
bootrom has a reg property so the unit name should contain an address.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm/boot/dts/armada-375.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/armada-375.dtsi b/arch/arm/boot/dts/armada-375.dtsi
index 97b663d83fb6..e4150c34f128 100644
--- a/arch/arm/boot/dts/armada-375.dtsi
+++ b/arch/arm/boot/dts/armada-375.dtsi
@@ -110,7 +110,7 @@
pcie-mem-aperture = <0xe0000000 0x8000000>;
pcie-io-aperture = <0xe8000000 0x100000>;
- bootrom {
+ bootrom at 0 {
compatible = "marvell,bootrom";
reg = <MBUS_ID(0x01, 0x1d) 0 0x100000>;
};
--
2.10.1
^ permalink raw reply related
* [PATCH 03/14] ARM: dts: armada-375: Fixup mdio DT warning
From: Gregory CLEMENT @ 2016-11-10 0:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161110001000.10619-1-gregory.clement@free-electrons.com>
MDIO has a reg property so the unit name should contain an address.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm/boot/dts/armada-375.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/armada-375.dtsi b/arch/arm/boot/dts/armada-375.dtsi
index e016ff3ed970..97b663d83fb6 100644
--- a/arch/arm/boot/dts/armada-375.dtsi
+++ b/arch/arm/boot/dts/armada-375.dtsi
@@ -203,7 +203,7 @@
<0xc100 0x100>;
};
- mdio: mdio {
+ mdio: mdio at c0054 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "marvell,orion-mdio";
--
2.10.1
^ permalink raw reply related
* [PATCH 02/14] ARM: dts: armada-375: Use the node labels
From: Gregory CLEMENT @ 2016-11-10 0:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161110001000.10619-1-gregory.clement@free-electrons.com>
Use the node label when possible. As a result it flattens the device tree
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm/boot/dts/armada-375-db.dts | 269 ++++++++++++++++++------------------
1 file changed, 136 insertions(+), 133 deletions(-)
diff --git a/arch/arm/boot/dts/armada-375-db.dts b/arch/arm/boot/dts/armada-375-db.dts
index cded5f0a262d..b33a674088ed 100644
--- a/arch/arm/boot/dts/armada-375-db.dts
+++ b/arch/arm/boot/dts/armada-375-db.dts
@@ -69,138 +69,141 @@
MBUS_ID(0x09, 0x09) 0 0xf1100000 0x10000
MBUS_ID(0x09, 0x05) 0 0xf1110000 0x10000>;
- internal-regs {
- spi at 10600 {
- pinctrl-0 = <&spi0_pins>;
- pinctrl-names = "default";
- /*
- * SPI conflicts with NAND, so we disable it
- * here, and select NAND as the enabled device
- * by default.
- */
- status = "disabled";
-
- spi-flash at 0 {
- #address-cells = <1>;
- #size-cells = <1>;
- compatible = "n25q128a13", "jedec,spi-nor";
- reg = <0>; /* Chip select 0 */
- spi-max-frequency = <108000000>;
- };
- };
-
- i2c at 11000 {
- status = "okay";
- clock-frequency = <100000>;
- pinctrl-0 = <&i2c0_pins>;
- pinctrl-names = "default";
- };
-
- i2c at 11100 {
- status = "okay";
- clock-frequency = <100000>;
- pinctrl-0 = <&i2c1_pins>;
- pinctrl-names = "default";
- };
-
- serial at 12000 {
- status = "okay";
- };
-
- pinctrl {
- sdio_st_pins: sdio-st-pins {
- marvell,pins = "mpp44", "mpp45";
- marvell,function = "gpio";
- };
- };
-
- sata at a0000 {
- status = "okay";
- nr-ports = <2>;
- };
-
- nand: nand at d0000 {
- pinctrl-0 = <&nand_pins>;
- pinctrl-names = "default";
- status = "okay";
- num-cs = <1>;
- marvell,nand-keep-config;
- marvell,nand-enable-arbiter;
- nand-on-flash-bbt;
- nand-ecc-strength = <4>;
- nand-ecc-step-size = <512>;
-
- partition at 0 {
- label = "U-Boot";
- reg = <0 0x800000>;
- };
- partition at 800000 {
- label = "Linux";
- reg = <0x800000 0x800000>;
- };
- partition at 1000000 {
- label = "Filesystem";
- reg = <0x1000000 0x3f000000>;
- };
- };
-
- usb at 54000 {
- status = "okay";
- };
-
- usb3 at 58000 {
- status = "okay";
- };
-
- mvsdio at d4000 {
- pinctrl-0 = <&sdio_pins &sdio_st_pins>;
- pinctrl-names = "default";
- status = "okay";
- cd-gpios = <&gpio1 12 GPIO_ACTIVE_HIGH>;
- wp-gpios = <&gpio1 13 GPIO_ACTIVE_HIGH>;
- };
-
- mdio {
- phy0: ethernet-phy at 0 {
- reg = <0>;
- };
-
- phy3: ethernet-phy at 3 {
- reg = <3>;
- };
- };
-
- ethernet at f0000 {
- status = "okay";
-
- eth0 at c4000 {
- status = "okay";
- phy = <&phy0>;
- phy-mode = "rgmii-id";
- };
-
- eth1 at c5000 {
- status = "okay";
- phy = <&phy3>;
- phy-mode = "gmii";
- };
- };
- };
-
- pcie-controller {
- status = "okay";
- /*
- * The two PCIe units are accessible through
- * standard PCIe slots on the board.
- */
- pcie at 1,0 {
- /* Port 0, Lane 0 */
- status = "okay";
- };
- pcie at 2,0 {
- /* Port 1, Lane 0 */
- status = "okay";
- };
- };
};
};
+&pciec {
+ status = "okay";
+};
+
+/*
+ * The two PCIe units are accessible through
+ * standard PCIe slots on the board.
+ */
+&pcie0 {
+ /* Port 0, Lane 0 */
+ status = "okay";
+};
+
+&pcie1 {
+ /* Port 1, Lane 0 */
+ status = "okay";
+};
+
+
+&spi0 {
+ pinctrl-0 = <&spi0_pins>;
+ pinctrl-names = "default";
+
+ /*
+ * SPI conflicts with NAND, so we disable it here, and
+ * select NAND as the enabled device by default.
+ */
+
+ status = "disabled";
+
+ spi-flash at 0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "n25q128a13", "jedec,spi-nor";
+ reg = <0>; /* Chip select 0 */
+ spi-max-frequency = <108000000>;
+ };
+};
+
+&i2c0 {
+ status = "okay";
+ clock-frequency = <100000>;
+ pinctrl-0 = <&i2c0_pins>;
+ pinctrl-names = "default";
+};
+
+&i2c1 {
+ status = "okay";
+ clock-frequency = <100000>;
+ pinctrl-0 = <&i2c1_pins>;
+ pinctrl-names = "default";
+};
+
+&uart0 {
+ status = "okay";
+};
+
+&pinctrl {
+ sdio_st_pins: sdio-st-pins {
+ marvell,pins = "mpp44", "mpp45";
+ marvell,function = "gpio";
+ };
+};
+
+&sata {
+ status = "okay";
+ nr-ports = <2>;
+};
+
+&nand {
+ pinctrl-0 = <&nand_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+ num-cs = <1>;
+ marvell,nand-keep-config;
+ marvell,nand-enable-arbiter;
+ nand-on-flash-bbt;
+ nand-ecc-strength = <4>;
+ nand-ecc-step-size = <512>;
+
+ partition at 0 {
+ label = "U-Boot";
+ reg = <0 0x800000>;
+ };
+ partition at 800000 {
+ label = "Linux";
+ reg = <0x800000 0x800000>;
+ };
+ partition at 1000000 {
+ label = "Filesystem";
+ reg = <0x1000000 0x3f000000>;
+ };
+};
+
+&usb1 {
+ status = "okay";
+};
+
+&usb2 {
+ status = "okay";
+};
+
+&sdio {
+ pinctrl-0 = <&sdio_pins &sdio_st_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+ cd-gpios = <&gpio1 12 GPIO_ACTIVE_HIGH>;
+ wp-gpios = <&gpio1 13 GPIO_ACTIVE_HIGH>;
+};
+
+&mdio {
+ phy0: ethernet-phy at 0 {
+ reg = <0>;
+ };
+
+ phy3: ethernet-phy at 3 {
+ reg = <3>;
+ };
+};
+
+ðernet {
+ status = "okay";
+};
+
+
+ð0 {
+ status = "okay";
+ phy = <&phy0>;
+ phy-mode = "rgmii-id";
+};
+
+ð1 {
+ status = "okay";
+ phy = <&phy3>;
+ phy-mode = "gmii";
+};
--
2.10.1
^ permalink raw reply related
* [PATCH 01/14] ARM: dts: armada-375: Add node labels
From: Gregory CLEMENT @ 2016-11-10 0:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161110001000.10619-1-gregory.clement@free-electrons.com>
As it was previously done for kirkwood and for aramda 370/XP, this adds
missing node labels to Armada 375 and SoC specific nodes to allow to
reference them more easily.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm/boot/dts/armada-375.dtsi | 62 +++++++++++++++++++--------------------
1 file changed, 31 insertions(+), 31 deletions(-)
diff --git a/arch/arm/boot/dts/armada-375.dtsi b/arch/arm/boot/dts/armada-375.dtsi
index 45fa92f9cf5c..e016ff3ed970 100644
--- a/arch/arm/boot/dts/armada-375.dtsi
+++ b/arch/arm/boot/dts/armada-375.dtsi
@@ -84,12 +84,12 @@
#size-cells = <0>;
enable-method = "marvell,armada-375-smp";
- cpu at 0 {
+ cpu0: cpu at 0 {
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <0>;
};
- cpu at 1 {
+ cpu1: cpu at 1 {
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <1>;
@@ -115,7 +115,7 @@
reg = <MBUS_ID(0x01, 0x1d) 0 0x100000>;
};
- devbus-bootcs {
+ devbus_bootcs: devbus-bootcs {
compatible = "marvell,mvebu-devbus";
reg = <MBUS_ID(0xf0, 0x01) 0x10400 0x8>;
ranges = <0 MBUS_ID(0x01, 0x2f) 0 0xffffffff>;
@@ -125,7 +125,7 @@
status = "disabled";
};
- devbus-cs0 {
+ devbus_cs0: devbus-cs0 {
compatible = "marvell,mvebu-devbus";
reg = <MBUS_ID(0xf0, 0x01) 0x10408 0x8>;
ranges = <0 MBUS_ID(0x01, 0x3e) 0 0xffffffff>;
@@ -135,7 +135,7 @@
status = "disabled";
};
- devbus-cs1 {
+ devbus_cs1: devbus-cs1 {
compatible = "marvell,mvebu-devbus";
reg = <MBUS_ID(0xf0, 0x01) 0x10410 0x8>;
ranges = <0 MBUS_ID(0x01, 0x3d) 0 0xffffffff>;
@@ -145,7 +145,7 @@
status = "disabled";
};
- devbus-cs2 {
+ devbus_cs2: devbus-cs2 {
compatible = "marvell,mvebu-devbus";
reg = <MBUS_ID(0xf0, 0x01) 0x10418 0x8>;
ranges = <0 MBUS_ID(0x01, 0x3b) 0 0xffffffff>;
@@ -155,7 +155,7 @@
status = "disabled";
};
- devbus-cs3 {
+ devbus_cs3: devbus-cs3 {
compatible = "marvell,mvebu-devbus";
reg = <MBUS_ID(0xf0, 0x01) 0x10420 0x8>;
ranges = <0 MBUS_ID(0x01, 0x37) 0 0xffffffff>;
@@ -182,12 +182,12 @@
prefetch-data = <1>;
};
- scu at c000 {
+ scu: scu at c000 {
compatible = "arm,cortex-a9-scu";
reg = <0xc000 0x58>;
};
- timer at c600 {
+ timer0: timer at c600 {
compatible = "arm,cortex-a9-twd-timer";
reg = <0xc600 0x20>;
interrupts = <GIC_PPI 13 (IRQ_TYPE_EDGE_RISING | GIC_CPU_MASK_SIMPLE(2))>;
@@ -203,7 +203,7 @@
<0xc100 0x100>;
};
- mdio {
+ mdio: mdio {
#address-cells = <1>;
#size-cells = <0>;
compatible = "marvell,orion-mdio";
@@ -212,7 +212,7 @@
};
/* Network controller */
- ethernet at f0000 {
+ ethernet: ethernet at f0000 {
compatible = "marvell,armada-375-pp2";
reg = <0xf0000 0xa000>, /* Packet Processor regs */
<0xc0000 0x3060>, /* LMS regs */
@@ -235,7 +235,7 @@
};
};
- rtc at 10300 {
+ rtc: rtc at 10300 {
compatible = "marvell,orion-rtc";
reg = <0x10300 0x20>;
interrupts = <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
@@ -307,7 +307,7 @@
status = "disabled";
};
- pinctrl {
+ pinctrl: pinctrl {
compatible = "marvell,mv88f6720-pinctrl";
reg = <0x18000 0x24>;
@@ -382,7 +382,7 @@
interrupts = <GIC_SPI 62 IRQ_TYPE_LEVEL_HIGH>;
};
- system-controller at 18200 {
+ systemc: system-controller at 18200 {
compatible = "marvell,armada-375-system-controller";
reg = <0x18200 0x100>;
};
@@ -415,7 +415,7 @@
interrupts = <GIC_PPI 15 IRQ_TYPE_LEVEL_HIGH>;
};
- timer at 20300 {
+ timer1: timer at 20300 {
compatible = "marvell,armada-375-timer", "marvell,armada-370-timer";
reg = <0x20300 0x30>, <0x21040 0x30>;
interrupts-extended = <&gic GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>,
@@ -428,24 +428,24 @@
clock-names = "nbclk", "fixed";
};
- watchdog at 20300 {
+ watchdog: watchdog at 20300 {
compatible = "marvell,armada-375-wdt";
reg = <0x20300 0x34>, <0x20704 0x4>, <0x18254 0x4>;
clocks = <&coreclk 0>, <&refclk>;
clock-names = "nbclk", "fixed";
};
- cpurst at 20800 {
+ cpurst: cpurst at 20800 {
compatible = "marvell,armada-370-cpu-reset";
reg = <0x20800 0x10>;
};
- coherency-fabric at 21010 {
+ coherencyfab: coherency-fabric at 21010 {
compatible = "marvell,armada-375-coherency-fabric";
reg = <0x21010 0x1c>;
};
- usb at 50000 {
+ usb0: usb at 50000 {
compatible = "marvell,orion-ehci";
reg = <0x50000 0x500>;
interrupts = <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>;
@@ -455,7 +455,7 @@
status = "disabled";
};
- usb at 54000 {
+ usb1: usb at 54000 {
compatible = "marvell,orion-ehci";
reg = <0x54000 0x500>;
interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>;
@@ -463,7 +463,7 @@
status = "disabled";
};
- usb3 at 58000 {
+ usb2: usb3 at 58000 {
compatible = "marvell,armada-375-xhci";
reg = <0x58000 0x20000>,<0x5b880 0x80>;
interrupts = <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>;
@@ -473,7 +473,7 @@
status = "disabled";
};
- xor at 60800 {
+ xor0: xor at 60800 {
compatible = "marvell,orion-xor";
reg = <0x60800 0x100
0x60A00 0x100>;
@@ -493,7 +493,7 @@
};
};
- xor at 60900 {
+ xor1: xor at 60900 {
compatible = "marvell,orion-xor";
reg = <0x60900 0x100
0x60b00 0x100>;
@@ -513,7 +513,7 @@
};
};
- crypto at 90000 {
+ cesa: crypto at 90000 {
compatible = "marvell,armada-375-crypto";
reg = <0x90000 0x10000>;
reg-names = "regs";
@@ -528,7 +528,7 @@
marvell,crypto-sram-size = <0x800>;
};
- sata at a0000 {
+ sata: sata at a0000 {
compatible = "marvell,armada-370-sata";
reg = <0xa0000 0x5000>;
interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>;
@@ -537,7 +537,7 @@
status = "disabled";
};
- nand at d0000 {
+ nand: nand at d0000 {
compatible = "marvell,armada370-nand";
reg = <0xd0000 0x54>;
#address-cells = <1>;
@@ -547,7 +547,7 @@
status = "disabled";
};
- mvsdio at d4000 {
+ sdio: mvsdio at d4000 {
compatible = "marvell,orion-sdio";
reg = <0xd4000 0x200>;
interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
@@ -559,7 +559,7 @@
status = "disabled";
};
- thermal at e8078 {
+ thermal: thermal at e8078 {
compatible = "marvell,armada375-thermal";
reg = <0xe8078 0x4>, <0xe807c 0x8>;
status = "okay";
@@ -580,7 +580,7 @@
};
};
- pcie-controller {
+ pciec: pcie-controller {
compatible = "marvell,armada-370-pcie";
status = "disabled";
device_type = "pci";
@@ -599,7 +599,7 @@
0x82000000 0x2 0 MBUS_ID(0x04, 0xd8) 0 1 0 /* Port 1 MEM */
0x81000000 0x2 0 MBUS_ID(0x04, 0xd0) 0 1 0 /* Port 1 IO */>;
- pcie at 1,0 {
+ pcie0: pcie at 1,0 {
device_type = "pci";
assigned-addresses = <0x82000800 0 0x40000 0 0x2000>;
reg = <0x0800 0 0 0 0>;
@@ -616,7 +616,7 @@
status = "disabled";
};
- pcie at 2,0 {
+ pcie1: pcie at 2,0 {
device_type = "pci";
assigned-addresses = <0x82000800 0 0x44000 0 0x2000>;
reg = <0x1000 0 0 0 0>;
--
2.10.1
^ permalink raw reply related
* [PATCH 00/14] Various Armada 375 DT warning fixup
From: Gregory CLEMENT @ 2016-11-10 0:09 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
This series follow the work done on the Armada 370/XP:
http://lists.infradead.org/pipermail/linux-arm-kernel/2016-November/466006.html
This patchset fixes up various warning from the DT compiler when using
the flag W=1 with make. This time there is no remaining warnings.
As there was only one board associated to Armada 375 its dts have been
fully converted to use the labels.
Gregory
Gregory CLEMENT (14):
ARM: dts: armada-375: Add node labels
ARM: dts: armada-375: Use the node labels
ARM: dts: armada-375: Fixup mdio DT warning
ARM: dts: armada-375: Fixup bootrom DT warning
ARM: dts: armada-375: Fixup devbus DT warning
ARM: dts: armada-375: Fixup sa-ram DT warning
ARM: dts: armada-375: Fixup pcie DT warnings
ARM: dts: armada-375: Fixup pcie DT warnings
ARM: dts: armada-375: Fixup pinctrl DT warnings
ARM: dts: armada-375: Fixup soc DT warning
ARM: dts: armada-375: Fixup internal-regs DT warning
ARM: dts: armada-375: Remove skeleton.dtsi
ARM: dts: armada-375: Fixup memory DT warning
ARM: dts: armada-375: Fixup ethernet child DT warning
arch/arm/boot/dts/armada-375-db.dts | 273 ++++++++++++++++++------------------
arch/arm/boot/dts/armada-375.dtsi | 80 +++++------
2 files changed, 179 insertions(+), 174 deletions(-)
--
2.10.1
^ permalink raw reply
* [PATCH v2] ARM: at91/dt: fixes dbgu pinctrl, set pullup on rx, clear pullup on tx
From: Alexandre Belloni @ 2016-11-10 0:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4e332daa-7d2a-1481-c8fc-7119033b68e3@axentia.se>
On 10/11/2016 at 00:41:37 +0100, Peter Rosin wrote :
> On 2016-10-20 15:35, Alexandre Belloni wrote
> > On 16/10/2016 at 18:21:45 +0200, Sylvain Rochet wrote :
> >> Remove pullup on dbgu DTXD signal, it is a push-pull output thus the
> >> pullup is pointless.
> >>
> >> Add pullup on dbgu DRXD signal, it prevents the DRXD signal to be left
> >> floating and so consuming a useless extra amount of power in crowbarred
> >> state if nothing is externally connected to dbgu.
> >>
> >> Signed-off-by: Sylvain Rochet <sylvain.rochet@finsecur.com>
> >> ---
> >> arch/arm/boot/dts/at91rm9200.dtsi | 4 ++--
> >> arch/arm/boot/dts/at91sam9260.dtsi | 4 ++--
> >> arch/arm/boot/dts/at91sam9261.dtsi | 4 ++--
> >> arch/arm/boot/dts/at91sam9263.dtsi | 4 ++--
> >> arch/arm/boot/dts/at91sam9g45.dtsi | 4 ++--
> >> arch/arm/boot/dts/at91sam9n12.dtsi | 4 ++--
> >> arch/arm/boot/dts/at91sam9rl.dtsi | 4 ++--
> >> arch/arm/boot/dts/at91sam9x5.dtsi | 4 ++--
> >> arch/arm/boot/dts/sama5d3.dtsi | 4 ++--
> >> arch/arm/boot/dts/sama5d4.dtsi | 4 ++--
> >> 10 files changed, 20 insertions(+), 20 deletions(-)
> >>
> > Applied, thanks.
>
> I can't seem to find this patch in any of the repos I'm looking at,
> so I'm wondering where it was applied and when it might hit mainline?
>
It is applied there:
http://git.kernel.org/cgit/linux/kernel/git/abelloni/linux.git/log/?h=at91-dt
It will land in 4.10. I'll do the PR to arm-soc soon.
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH fpga 2/9] fpga zynq: Check the bitstream for validity
From: Joshua Clayton @ 2016-11-10 0:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478732303-13718-3-git-send-email-jgunthorpe@obsidianresearch.com>
Hi Jason,
Minor comment below:
On 11/09/2016 02:58 PM, Jason Gunthorpe wrote:
> @@ -184,12 +197,28 @@ static int zynq_fpga_ops_write_init(struct fpga_manager *mgr, u32 flags,
>
> priv = mgr->priv;
>
> + /* The hardware can only DMA multiples of 4 bytes, and we need at
> + * least the sync word and something else to do anything.
> + */
> + if (count <= 4 || (count % 4) != 0) {
> + dev_err(priv->dev,
> + "Invalid bitstream size, must be multiples of 4 bytes\n");
> + return -EINVAL;
> + }
> +
> err = clk_enable(priv->clk);
> if (err)
> return err;
>
> /* don't globally reset PL if we're doing partial reconfig */
> if (!(flags & FPGA_MGR_PARTIAL_RECONFIG)) {
> + if (!zynq_fpga_has_sync(buf, count)) {
> + dev_err(priv->dev,
> + "Invalid bitstream, could not find a sync word. Bitstream must be a byte swaped .bin file\n");
Nitpick: byte swaped is a misspelling... and I'm not sure I like the second half of this message.
Maybe something like "Bitstream must be lsb first" (if that is what is meant).
> + err = -EINVAL;
> + goto out_err;
> + }
> +
> /* assert AXI interface resets */
> regmap_write(priv->slcr, SLCR_FPGA_RST_CTRL_OFFSET,
> FPGA_RST_ALL_MASK);
>
Thanks,
Joshua
^ permalink raw reply
* Summary of LPC guest MSI discussion in Santa Fe
From: Alex Williamson @ 2016-11-09 23:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161109233847.GT17771@arm.com>
On Wed, 9 Nov 2016 23:38:50 +0000
Will Deacon <will.deacon@arm.com> wrote:
> On Wed, Nov 09, 2016 at 04:24:58PM -0700, Alex Williamson wrote:
> > On Wed, 9 Nov 2016 22:25:22 +0000
> > Will Deacon <will.deacon@arm.com> wrote:
> >
> > > On Wed, Nov 09, 2016 at 03:17:09PM -0700, Alex Williamson wrote:
> > > > On Wed, 9 Nov 2016 20:31:45 +0000
> > > > Will Deacon <will.deacon@arm.com> wrote:
> > > > > On Wed, Nov 09, 2016 at 08:23:03PM +0100, Christoffer Dall wrote:
> > > > > >
> > > > > > (I suppose it's technically possible to get around this issue by letting
> > > > > > QEMU place RAM wherever it wants but tell the guest to never use a
> > > > > > particular subset of its RAM for DMA, because that would conflict with
> > > > > > the doorbell IOVA or be seen as p2p transactions. But I think we all
> > > > > > probably agree that it's a disgusting idea.)
> > > > >
> > > > > Disgusting, yes, but Ben's idea of hotplugging on the host controller with
> > > > > firmware tables describing the reserved regions is something that we could
> > > > > do in the distant future. In the meantime, I don't think that VFIO should
> > > > > explicitly reject overlapping mappings if userspace asks for them.
> > > >
> > > > I'm confused by the last sentence here, rejecting user mappings that
> > > > overlap reserved ranges, such as MSI doorbell pages, is exactly how
> > > > we'd reject hot-adding a device when we meet such a conflict. If we
> > > > don't reject such a mapping, we're knowingly creating a situation that
> > > > potentially leads to data loss. Minimally, QEMU would need to know
> > > > about the reserved region, map around it through VFIO, and take
> > > > responsibility (somehow) for making sure that region is never used for
> > > > DMA. Thanks,
> > >
> > > Yes, but my point is that it should be up to QEMU to abort the hotplug, not
> > > the host kernel, since there may be ways in which a guest can tolerate the
> > > overlapping region (e.g. by avoiding that range of memory for DMA).
> >
> > The VFIO_IOMMU_MAP_DMA ioctl is a contract, the user ask to map a range
> > of IOVAs to a range of virtual addresses for a given device. If VFIO
> > cannot reasonably fulfill that contract, it must fail. It's up to QEMU
> > how to manage the hotplug and what memory regions it asks VFIO to map
> > for a device, but VFIO must reject mappings that it (or the SMMU by
> > virtue of using the IOMMU API) know to overlap reserved ranges. So I
> > still disagree with the referenced statement. Thanks,
>
> I think that's a pity. Not only does it mean that both QEMU and the kernel
> have more work to do (the former has to carve up its mapping requests,
> whilst the latter has to check that it is indeed doing this), but it also
> precludes the use of hugepage mappings on the IOMMU because of reserved
> regions. For example, a 4k hole someplace may mean we can't put down 1GB
> table entries for the guest memory in the SMMU.
>
> All this seems to do is add complexity and decrease performance. For what?
> QEMU has to go read the reserved regions from someplace anyway. It's also
> the way that VFIO works *today* on arm64 wrt reserved regions, it just has
> no way to identify those holes at present.
Sure, that sucks, but how is the alternative even an option? The user
asked to map something, we can't, if we allow that to happen now it's a
bug. Put the MSI doorbells somewhere that this won't be an issue. If
the platform has it fixed somewhere that this is an issue, don't use
that platform. The correctness of the interface is more important than
catering to a poorly designed system layout IMO. Thanks,
Alex
^ permalink raw reply
* [PATCH] drivers: mfd: ti_am335x_tscadc: increase ADC ref clock to 24MHz
From: John Syne @ 2016-11-09 23:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d7fadbf6-8026-d821-1ef8-981f536a8fdf@ti.com>
> On Oct 31, 2016, at 4:39 AM, Vignesh R <vigneshr@ti.com> wrote:
>
>
>
> On Friday 28 October 2016 02:47 AM, John Syne wrote:
>
>>>>>>>>>>>
>>>>>>>>>>> ---
>>>>>>>>>>> include/linux/mfd/ti_am335x_tscadc.h | 4 ++--
>>>>>>>>>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>>>>>>>>>
>>>>>>>>>>> diff --git a/include/linux/mfd/ti_am335x_tscadc.h b/include/linux/mfd/ti_am335x_tscadc.h
>>>>>>>>>>> index b9a53e0..96c4207 100644
>>>>>>>>>>> --- a/include/linux/mfd/ti_am335x_tscadc.h
>>>>>>>>>>> +++ b/include/linux/mfd/ti_am335x_tscadc.h
>>>>>>>>>>> @@ -90,7 +90,7 @@
>>>>>>>>>>> /* Delay register */
>>>>>>>>>>> #define STEPDELAY_OPEN_MASK (0x3FFFF << 0)
>>>>>>>>>>> #define STEPDELAY_OPEN(val) ((val) << 0)
>>>>>>>>>>> -#define STEPCONFIG_OPENDLY STEPDELAY_OPEN(0x098)
>>>>>>>>> Wouldn?t this be better to add this to the devicetree?
>>>>>>>>>
>>>>>>>>> ti,chan-step-avg = <0x16 0x16 0x16 0x16 0x16 0x16 0x16>;
>>>>>>>>> ti,chan-step-opendelay = <0x500 0x500 0x500 0x500 0x500 0x500 0x500>;
>>>>>>>>> ti,chan-step-sampledelay = <0x0 0x0 0x0 0x0 0x0 0x0 0x0>;
>>>>>>>>
>>>>>>>> For a touch screen, there is not need to change in these parameter
>>>>>>>> settings, so my opinion is to keep it as is. Or am I missing something?
>>>>>>> I was thinking that if you are using this driver as an ADC, you may want the flexibility to make these changes in the DT. I?m doing this by connecting sensors to the ADC inputs. I?m not using this driver for a touchscreen.
>>>>>>
>>>>>> Here is a DT overlay were this gets using on the BeagleBoneBlack.
>>>>>>
>>>>>> https://github.com/RobertCNelson/bb.org-overlays/blob/master/src/arm/BB-ADC-00A0.dts
>>>>>>
>>>>>> Besides, these DT features are already implemented in the driver so it is just a matter of adding these entries to the am33xx.dtsi & am4372.dtsi, which you modified in this patch series.
>>>>>
>>>>> This looks like configuration, no?
>>>>>
>>>>> DT should be used to describe the hardware.
>>>> You may be right, but how is this different to setting the baud rate on a serial channel or sampling rate on a audio channel? Looking through the DT, there are many configuration settings, so I?m not sure what is the correct way to handle this. Surely it is better to handle this in DT vs hard coding these settings?
>>>
>>> I think setting the UART baud rate is also an invalid DT entry.
>>>
>>> It's okay to list all of the options in DT, but to actually select
>>> one, that should be done either in userspace or as a kernel option.
>>> Perhaps as a Kconfig selection.
>> Yeah, this has been inconsistent for a long time. My only point was that these DT parameters had already been implemented in the ti_am335x_adc KM and I thought that this was better than hard coding these settings. Implementing this in Kconfig means rebuilding the KM, which isn?t desirable.
>
>> Perhaps this should be done via sysfs attributes so as you say, a userspace app can configure this driver.
>
> This was discussed when DT properties were added. Patches are welcome
> to add sysfs entries. There is nothing wrong with specifying an initial
> value in the DT.
>
>> I guess the DT code in ti_am335x_adc.c should be removed.
>>
>
> Removing DT properties is not an option as it will break DT backward
> compatibility.
Hi Vignesh,
OK, then back to my original question. Given that these DT properties are supported in the driver, shouldn?t the following be added to am33xx.dtsi and am4372.dtsi?
ti,chan-step-avg = <0x16 0x16 0x16 0x16 0x16 0x16 0x16>;
ti,chan-step-opendelay = <0x500 0x500 0x500 0x500 0x500 0x500 0x500>;
ti,chan-step-sampledelay = <0x0 0x0 0x0 0x0 0x0 0x0 0x0>;
Regards,
John
>
> --
> Regards
> Vignesh
^ permalink raw reply
* [PATCH v2 4/6] pinctrl: aspeed: Read and write bits in LPCHC and GFX controllers
From: Andrew Jeffery @ 2016-11-09 23:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161109182632.etsvezgfu7nhtl55@rob-hp-laptop>
On Wed, 2016-11-09 at 12:26 -0600, Rob Herring wrote:
> On Thu, Nov 03, 2016 at 01:07:59AM +1030, Andrew Jeffery wrote:
> > The System Control Unit IP block in the Aspeed SoCs is typically where
> > the pinmux configuration is found, but not always. A number of pins
> > depend on state in one of LPC Host Control (LPCHC) or SoC Display
> > Controller (GFX) IP blocks, so the Aspeed pinmux drivers should have the
> > means to adjust these as necessary.
> >
> > We use syscon to cast a regmap over the GFX and LPCHCR blocks, which is
> > used as an arbitration layer between the relevant driver and the pinctrl
> > subsystem. The regmaps are then exposed to the SoC-specific pinctrl
> > drivers by phandles in the devicetree, and are selected during a mux
> > request by querying a new 'ip' member in struct aspeed_sig_desc.
> >
> > > > Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
> > ---
> > Since v1:
> >
> > The change is now proactive: instead of reporting that we need to flip bits in
> > controllers we can't access, the patch provides access via regmaps for the
> > relevant controllers. The implementation also splits out the IP block ID into
> > its own variable rather than packing the value into the upper bits of the reg
> > member of struct aspeed_sig_desc. This drives some churn in the diff, but I've
> > tried to minimise it.
> >
> > ?.../devicetree/bindings/pinctrl/pinctrl-aspeed.txt | 50 +++++++++++++---
> > ?drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c?????????| 18 +++---
> > ?drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c?????????| 39 ++++++++++---
> > ?drivers/pinctrl/aspeed/pinctrl-aspeed.c????????????| 66 +++++++++++++---------
> > ?drivers/pinctrl/aspeed/pinctrl-aspeed.h????????????| 32 ++++++++---
> > ?5 files changed, 144 insertions(+), 61 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt
> > index 2ad18c4ea55c..115b0cce6c1c 100644
> > --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt
> > +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt
> > @@ -4,12 +4,19 @@ Aspeed Pin Controllers
> > ?The Aspeed SoCs vary in functionality inside a generation but have a common mux
> > ?device register layout.
> > ?
> > -Required properties:
> > -- compatible : Should be any one of the following:
> > - "aspeed,ast2400-pinctrl"
> > - "aspeed,g4-pinctrl"
> > - "aspeed,ast2500-pinctrl"
> > - "aspeed,g5-pinctrl"
> > +Required properties for g4:
> > +- compatible :? Should be any one of the following:
> > + "aspeed,ast2400-pinctrl"
> > + "aspeed,g4-pinctrl"
> > +
> > +Required properties for g5:
> > +- compatible :? Should be any one of the following:
> > + "aspeed,ast2500-pinctrl"
> > + "aspeed,g5-pinctrl"
> > +
> > +- aspeed,external-nodes: A cell of phandles to external controller nodes:
> > + 0: compatible with "aspeed,ast2500-gfx", "syscon"
> > + 1: compatible with "aspeed,ast2500-lpchc", "syscon"
> > ?
> > ?The pin controller node should be a child of a syscon node with the required
> > ?property:
> > @@ -47,7 +54,7 @@ RGMII1 RGMII2 RMII1 RMII2 SD1 SPI1 SPI1DEBUG SPI1PASSTHRU TIMER4 TIMER5 TIMER6
> > ?TIMER7 TIMER8 VGABIOSROM
> > ?
> > ?
> > -Examples:
> > +g4 Example:
> > ?
> > ?syscon: scu at 1e6e2000 {
> > ? compatible = "syscon", "simple-mfd";
> > @@ -63,5 +70,34 @@ syscon: scu at 1e6e2000 {
> > ? };
> > ?};
> > ?
> > +g5 Example:
> > +
> > +apb {
> > + gfx: display at 1e6e6000 {
> > + compatible = "aspeed,ast2500-gfx", "syscon";
> > + reg = <0x1e6e6000 0x1000>;
> > + };
> > +
> > + lpchc: lpchc at 1e7890a0 {
> > + compatible = "aspeed,ast2500-lpchc", "syscon";
> > + reg = <0x1e7890a0 0xc4>;
> > + };
> > +
> > + syscon: scu at 1e6e2000 {
> > + compatible = "syscon", "simple-mfd";
> > + reg = <0x1e6e2000 0x1a8>;
> > +
> > + pinctrl: pinctrl {
>
> Why the single child node here? Doesn't look like any reason for it in?
> the example.?
The SCU contains other miscellaneous functionality besides pinctrl
registers, but that's not relevant for the pinctrl bindings. This is an
example for the g5 SoCs demonstrating use of the aspeed,external-nodes
property, which isn't required for the g4 and is why I split the
examples.
Maybe I should split out the bindings for each SoC generation into
separate files?
>
> > + compatible = "aspeed,g5-pinctrl";
> > + aspeed,external-nodes = <&gfx, &lpchc>;
You didn't comment on my approach here, but I'm interested in feedback.
I've gone the route of fixed ordering of the phandles, but there are
two other approaches:
1. Relax the fixed ordering requirement by adding an "aspeed,external-
node-names" property and requiring correlated indices between them
2. Using separate properties for each required external node
Approach 1 seems pretty idiomatic and only crossed my mind after I'd
sent the patch. Approach 2 seems a bit ugly as the number of properties
scales with the number of controllers participating in the pinmux
configuration.
Something that also wasn't clear to me was whether I need the "aspeed"
prefix on the property name. What's the convention here? Do I need it
in this case?
Cheers,
Andrew
> > +
> > > > + pinctrl_i2c3_default: i2c3_default {
> > > > + function = "I2C3";
> > > > + groups = "I2C3";
> > > > + };
> > > > + };
> > > > + };
> > +};
> > +
> > ?Please refer to pinctrl-bindings.txt in this directory for details of the
> > ?common pinctrl bindings used by client devices.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161110/5d339d90/attachment.sig>
^ permalink raw reply
* [PATCH v2] ARM: at91/dt: fixes dbgu pinctrl, set pullup on rx, clear pullup on tx
From: Peter Rosin @ 2016-11-09 23:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161020153535.7e2b4frcukk2ce2i@piout.net>
On 2016-10-20 15:35, Alexandre Belloni wrote
> On 16/10/2016 at 18:21:45 +0200, Sylvain Rochet wrote :
>> Remove pullup on dbgu DTXD signal, it is a push-pull output thus the
>> pullup is pointless.
>>
>> Add pullup on dbgu DRXD signal, it prevents the DRXD signal to be left
>> floating and so consuming a useless extra amount of power in crowbarred
>> state if nothing is externally connected to dbgu.
>>
>> Signed-off-by: Sylvain Rochet <sylvain.rochet@finsecur.com>
>> ---
>> arch/arm/boot/dts/at91rm9200.dtsi | 4 ++--
>> arch/arm/boot/dts/at91sam9260.dtsi | 4 ++--
>> arch/arm/boot/dts/at91sam9261.dtsi | 4 ++--
>> arch/arm/boot/dts/at91sam9263.dtsi | 4 ++--
>> arch/arm/boot/dts/at91sam9g45.dtsi | 4 ++--
>> arch/arm/boot/dts/at91sam9n12.dtsi | 4 ++--
>> arch/arm/boot/dts/at91sam9rl.dtsi | 4 ++--
>> arch/arm/boot/dts/at91sam9x5.dtsi | 4 ++--
>> arch/arm/boot/dts/sama5d3.dtsi | 4 ++--
>> arch/arm/boot/dts/sama5d4.dtsi | 4 ++--
>> 10 files changed, 20 insertions(+), 20 deletions(-)
>>
> Applied, thanks.
I can't seem to find this patch in any of the repos I'm looking at,
so I'm wondering where it was applied and when it might hit mainline?
Cheers,
Peter
^ permalink raw reply
* [PATCH V10 6/6] arm: pmu: Add PMU definitions for cores not initially online
From: Jeremy Linton @ 2016-11-09 23:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478734793-6341-1-git-send-email-jeremy.linton@arm.com>
ACPI CPUs aren't associated with a PMU until they have been put
online. This means that we potentially have to update a PMU
definition the first time a CPU is hot added to the machine.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
---
drivers/perf/arm_pmu.c | 38 ++++++++++++++++++++++++++++++++++++--
include/linux/perf/arm_pmu.h | 4 ++++
2 files changed, 40 insertions(+), 2 deletions(-)
diff --git a/drivers/perf/arm_pmu.c b/drivers/perf/arm_pmu.c
index 07e1404..775551c 100644
--- a/drivers/perf/arm_pmu.c
+++ b/drivers/perf/arm_pmu.c
@@ -711,6 +711,30 @@ static int cpu_pmu_request_irq(struct arm_pmu *cpu_pmu, irq_handler_t handler)
return 0;
}
+static DEFINE_SPINLOCK(arm_pmu_resource_lock);
+
+static void arm_perf_associate_new_cpu(struct arm_pmu *lpmu, unsigned int cpu)
+{
+ struct platform_device *pdev = lpmu->plat_device;
+ struct resource *res;
+ struct pmu_hw_events *events;
+ int num_res;
+
+ spin_lock(&arm_pmu_resource_lock);
+ for (num_res = 0; num_res < pdev->num_resources; num_res++) {
+ if (!pdev->resource[num_res].flags)
+ break;
+ }
+ res = &pdev->resource[num_res];
+ arm_pmu_acpi_retrieve_irq(res, cpu);
+ events = per_cpu_ptr(lpmu->hw_events, cpu);
+ cpumask_set_cpu(cpu, &lpmu->supported_cpus);
+ if (lpmu->irq_affinity)
+ lpmu->irq_affinity[num_res] = cpu;
+ events->percpu_pmu = lpmu;
+ spin_unlock(&arm_pmu_resource_lock);
+}
+
/*
* PMU hardware loses all context when a CPU goes offline.
* When a CPU is hotplugged back in, since some hardware registers are
@@ -721,10 +745,18 @@ static int arm_perf_starting_cpu(unsigned int cpu, struct hlist_node *node)
{
struct arm_pmu *pmu = hlist_entry_safe(node, struct arm_pmu, node);
- if (!cpumask_test_cpu(cpu, &pmu->supported_cpus))
- return 0;
+ if (!cpumask_test_cpu(cpu, &pmu->supported_cpus)) {
+ unsigned int cpuid = read_specific_cpuid(cpu);
+
+ if (acpi_disabled)
+ return 0;
+ if (cpuid != pmu->id)
+ return 0;
+ arm_perf_associate_new_cpu(pmu, cpu);
+ }
if (pmu->reset)
pmu->reset(pmu);
+
return 0;
}
@@ -906,6 +938,8 @@ static int probe_plat_pmu(struct arm_pmu *pmu,
struct platform_device *pdev = pmu->plat_device;
int irq = platform_get_irq(pdev, 0);
+ pmu->id = pmuid;
+
if (irq >= 0 && !irq_is_percpu(irq)) {
pmu->irq_affinity = kcalloc(pdev->num_resources, sizeof(int),
GFP_KERNEL);
diff --git a/include/linux/perf/arm_pmu.h b/include/linux/perf/arm_pmu.h
index df1ba55..ed82b8f 100644
--- a/include/linux/perf/arm_pmu.h
+++ b/include/linux/perf/arm_pmu.h
@@ -112,6 +112,7 @@ struct arm_pmu {
struct mutex reserve_mutex;
u64 max_period;
bool secure_access; /* 32-bit ARM only */
+ unsigned int id;
#define ARMV8_PMUV3_MAX_COMMON_EVENTS 0x40
DECLARE_BITMAP(pmceid_bitmap, ARMV8_PMUV3_MAX_COMMON_EVENTS);
struct platform_device *plat_device;
@@ -167,8 +168,11 @@ int arm_pmu_device_probe(struct platform_device *pdev,
#ifdef CONFIG_ARM_PMU_ACPI
struct acpi_madt_generic_interrupt;
void arm_pmu_parse_acpi(int cpu, struct acpi_madt_generic_interrupt *gic);
+int arm_pmu_acpi_retrieve_irq(struct resource *pdev, int cpu);
#else
#define arm_pmu_parse_acpi(a, b) do { } while (0)
+#define arm_pmu_acpi_retrieve_irq(pdev, cpu) \
+ do { } while (0)
#endif /* CONFIG_ARM_PMU_ACPI */
#endif /* __ARM_PMU_H__ */
--
2.5.5
^ permalink raw reply related
* [PATCH V10 5/6] arm64: pmu: Detect and enable multiple PMUs in an ACPI system
From: Jeremy Linton @ 2016-11-09 23:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478734793-6341-1-git-send-email-jeremy.linton@arm.com>
Its possible that an ACPI system has multiple CPU types in it
with differing PMU counters. Iterate the CPU's and make a determination
about how many of each type exist in the system. Then take and create
a PMU platform device for each type, and assign it the interrupts parsed
from the MADT. Creating a platform device is necessary because the PMUs
are not described as devices in the DSDT table.
This code is loosely based on earlier work by Mark Salter.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
---
drivers/perf/arm_pmu.c | 8 +-
drivers/perf/arm_pmu_acpi.c | 234 +++++++++++++++++++++++++++++++++++++++++++-
2 files changed, 240 insertions(+), 2 deletions(-)
diff --git a/drivers/perf/arm_pmu.c b/drivers/perf/arm_pmu.c
index 6008be9..07e1404 100644
--- a/drivers/perf/arm_pmu.c
+++ b/drivers/perf/arm_pmu.c
@@ -1087,7 +1087,13 @@ int arm_pmu_device_probe(struct platform_device *pdev,
if (!ret)
ret = init_fn(pmu);
} else if (probe_table) {
- ret = probe_plat_pmu(pmu, probe_table, read_cpuid_id());
+ if (acpi_disabled) {
+ /* use the current cpu. */
+ ret = probe_plat_pmu(pmu, probe_table,
+ read_cpuid_id());
+ } else {
+ ret = probe_plat_pmu(pmu, probe_table, pdev->id);
+ }
}
if (ret) {
diff --git a/drivers/perf/arm_pmu_acpi.c b/drivers/perf/arm_pmu_acpi.c
index 135851c..eecf1c1 100644
--- a/drivers/perf/arm_pmu_acpi.c
+++ b/drivers/perf/arm_pmu_acpi.c
@@ -2,13 +2,17 @@
* ARM ACPI PMU support
*
* Copyright (C) 2015 Red Hat Inc.
+ * Copyright (C) 2016 ARM Ltd.
* Author: Mark Salter <msalter@redhat.com>
+ * Jeremy Linton <jeremy.linton@arm.com>
*
* This work is licensed under the terms of the GNU GPL, version 2. See
* the COPYING file in the top-level directory.
*
*/
+#define pr_fmt(fmt) "ACPI-PMU: " fmt
+
#include <asm/cpu.h>
#include <linux/acpi.h>
#include <linux/irq.h>
@@ -20,7 +24,14 @@
struct pmu_irq {
int gsi;
int trigger;
- bool registered;
+ int irq;
+ bool used;
+};
+
+struct pmu_types {
+ struct list_head list;
+ int cpu_type;
+ int cpu_count;
};
static struct pmu_irq pmu_irqs[NR_CPUS];
@@ -38,3 +49,224 @@ void __init arm_pmu_parse_acpi(int cpu, struct acpi_madt_generic_interrupt *gic)
else
pmu_irqs[cpu].trigger = ACPI_LEVEL_SENSITIVE;
}
+
+static void __init arm_pmu_acpi_handle_alloc_failure(struct list_head *pmus)
+{
+ int i;
+ struct pmu_types *pmu, *safe_temp;
+
+ list_for_each_entry_safe(pmu, safe_temp, pmus, list) {
+ list_del(&pmu->list);
+ kfree(pmu);
+ }
+
+ for_each_possible_cpu(i)
+ if (pmu_irqs[i].irq > 0)
+ acpi_unregister_gsi(pmu_irqs[i].gsi);
+}
+
+/*
+ * Count number and type of CPU cores in the system. Returns the number
+ * of "unused" MADT entries we could not associate with a PMU. This can
+ * be the result of CPU's not being online, or errors in the MADT.
+ * Under normal circumstances this will be 0.
+ */
+static int __init arm_pmu_acpi_determine_cpu_types(struct list_head *pmus)
+{
+ int i;
+ int unused_madt_entries = 0;
+
+ for_each_possible_cpu(i) {
+ struct cpuinfo_arm64 *cinfo = per_cpu_ptr(&cpu_data, i);
+ struct pmu_types *pmu;
+
+ /*
+ * Ignore GSI registration failure for now, as
+ * some of the MADT entries may not be used.
+ */
+ pmu_irqs[i].irq = acpi_register_gsi(NULL, pmu_irqs[i].gsi,
+ pmu_irqs[i].trigger,
+ ACPI_ACTIVE_HIGH);
+ /* likely not online */
+ if (cinfo->reg_midr == 0) {
+ unused_madt_entries++;
+ continue;
+ }
+
+ list_for_each_entry(pmu, pmus, list) {
+ if (pmu->cpu_type == cinfo->reg_midr) {
+ pmu->cpu_count++;
+ break;
+ }
+ }
+
+ /* we didn't find the CPU type, add an entry to identify it */
+ if (&pmu->list == pmus) {
+ pmu = kzalloc(sizeof(struct pmu_types), GFP_KERNEL);
+ if (!pmu) {
+ pr_err("Unable to allocate pmu_types\n");
+ arm_pmu_acpi_handle_alloc_failure(pmus);
+ break;
+ }
+ pmu->cpu_type = cinfo->reg_midr;
+ pmu->cpu_count++;
+ list_add_tail(&pmu->list, pmus);
+ }
+ }
+
+ return unused_madt_entries;
+}
+
+static int __init arm_pmu_acpi_register_device(int count, struct resource *res,
+ int cpu_id)
+{
+ struct platform_device *pdev;
+ int err = -ENOMEM;
+
+ pdev = platform_device_alloc(ARMV8_PMU_PDEV_NAME, cpu_id);
+ if (pdev) {
+ err = platform_device_add_resources(pdev, res, count);
+ if (!err)
+ err = platform_device_add(pdev);
+ if (err) {
+ pr_warn("Unable to register PMU device\n");
+ platform_device_put(pdev);
+ }
+ } else {
+ pr_warn("Unable to allocate platform device\n");
+ }
+
+ return err;
+}
+
+static void __init arm_pmu_acpi_unregister_pmu_gsi(int cpu_id)
+{
+ int i;
+
+ for_each_possible_cpu(i) {
+ struct cpuinfo_arm64 *cinfo = per_cpu_ptr(&cpu_data, i);
+
+ if (cinfo->reg_midr == cpu_id) {
+ pmu_irqs[i].used = false;
+ if (pmu_irqs[i].irq > 0)
+ acpi_unregister_gsi(pmu_irqs[i].gsi);
+ pmu_irqs[i].gsi = -ENODEV;
+ }
+ }
+}
+
+/*
+ * Registers the group of PMU interfaces which correspond to the 'cpu_id'.
+ * This group utilizes 'count' resources in the 'res'.
+ */
+static int __init arm_pmu_acpi_register_pmu(int count, struct resource *res,
+ int cpu_id)
+{
+ int err;
+
+ err = arm_pmu_acpi_register_device(count, res, cpu_id);
+
+ /* unmark and unregister GSIs for this PMU */
+ if (err)
+ arm_pmu_acpi_unregister_pmu_gsi(cpu_id);
+
+ return err;
+}
+
+int arm_pmu_acpi_retrieve_irq(struct resource *res, int cpu)
+{
+ int irq = -ENODEV;
+
+ if (pmu_irqs[cpu].used) {
+ pr_info("CPU %d's interrupt is already used\n", cpu);
+ } else {
+ pmu_irqs[cpu].used = true;
+ res->start = pmu_irqs[cpu].irq;
+ res->end = pmu_irqs[cpu].irq;
+ res->flags = IORESOURCE_IRQ;
+ if (pmu_irqs[cpu].trigger == ACPI_EDGE_SENSITIVE)
+ res->flags |= IORESOURCE_IRQ_HIGHEDGE;
+ else
+ res->flags |= IORESOURCE_IRQ_HIGHLEVEL;
+ }
+ return irq;
+}
+
+/*
+ * For the given cpu/pmu type, walk all known GSIs, register them, and add
+ * them to the resource structure. Return the number of GSI's contained
+ * in the res structure, and the id of the last CPU/PMU we added.
+ */
+static int __init arm_pmu_acpi_gsi_res(struct pmu_types *pmus,
+ struct resource *res)
+{
+ int i, count;
+
+ /* lets group all the PMU's from similar CPU's together */
+ count = 0;
+ for_each_possible_cpu(i) {
+ struct cpuinfo_arm64 *cinfo = per_cpu_ptr(&cpu_data, i);
+
+ if (pmus->cpu_type == cinfo->reg_midr) {
+ if ((pmu_irqs[i].gsi == 0) && (cinfo->reg_midr != 0))
+ continue;
+
+ /* likely not online */
+ if (!cinfo->reg_midr)
+ continue;
+
+ arm_pmu_acpi_retrieve_irq(&res[count], i);
+ count++;
+ }
+ }
+ return count;
+}
+
+static int __init pmu_acpi_register(struct pmu_types *pmu)
+{
+ int count;
+ int err = -ENOMEM;
+ struct resource *res;
+
+ res = kcalloc(pmu->cpu_count, sizeof(struct resource), GFP_KERNEL);
+
+ /* for a given PMU type, collect all the GSIs. */
+ if (res) {
+ count = arm_pmu_acpi_gsi_res(pmu, res);
+ /* register this set of interrupts with a new PMU device */
+ err = arm_pmu_acpi_register_pmu(pmu->cpu_count, res,
+ pmu->cpu_type);
+ if (!err)
+ pr_info("Register %d devices for %X\n", count,
+ pmu->cpu_type);
+ kfree(res);
+ } else {
+ pr_warn("PMU unable to allocate interrupt resource\n");
+ arm_pmu_acpi_unregister_pmu_gsi(pmu->cpu_type);
+ }
+ return err;
+}
+
+static int __init pmu_acpi_init(void)
+{
+ struct pmu_types *pmu, *safe_temp;
+ bool unused_madt_entries;
+ LIST_HEAD(pmus);
+
+ if (acpi_disabled)
+ return 0;
+
+ unused_madt_entries = arm_pmu_acpi_determine_cpu_types(&pmus);
+
+ list_for_each_entry_safe(pmu, safe_temp, &pmus, list) {
+ pmu->cpu_count += unused_madt_entries;
+ pmu_acpi_register(pmu);
+
+ list_del(&pmu->list);
+ kfree(pmu);
+ }
+
+ return 0;
+}
+
+arch_initcall(pmu_acpi_init);
--
2.5.5
^ permalink raw reply related
* [PATCH V10 4/6] arm: arm64: pmu: Assign platform PMU CPU affinity
From: Jeremy Linton @ 2016-11-09 23:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478734793-6341-1-git-send-email-jeremy.linton@arm.com>
On systems with multiple PMU types the PMU to CPU affinity
needs to be detected and set. The CPU to interrupt affinity
should also be set.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
---
drivers/perf/arm_pmu.c | 63 ++++++++++++++++++++++++++++++++++++++++++--------
1 file changed, 53 insertions(+), 10 deletions(-)
diff --git a/drivers/perf/arm_pmu.c b/drivers/perf/arm_pmu.c
index b37b572..6008be9 100644
--- a/drivers/perf/arm_pmu.c
+++ b/drivers/perf/arm_pmu.c
@@ -11,6 +11,7 @@
*/
#define pr_fmt(fmt) "hw perfevents: " fmt
+#include <linux/acpi.h>
#include <linux/bitmap.h>
#include <linux/cpumask.h>
#include <linux/cpu_pm.h>
@@ -24,6 +25,7 @@
#include <linux/irq.h>
#include <linux/irqdesc.h>
+#include <asm/cpu.h>
#include <asm/cputype.h>
#include <asm/irq_regs.h>
@@ -889,25 +891,67 @@ static void cpu_pmu_destroy(struct arm_pmu *cpu_pmu)
}
/*
- * CPU PMU identification and probing.
+ * CPU PMU identification and probing. Its possible to have
+ * multiple CPU types in an ARM machine. Assure that we are
+ * picking the right PMU types based on the CPU in question
*/
-static int probe_current_pmu(struct arm_pmu *pmu,
- const struct pmu_probe_info *info)
+static int probe_plat_pmu(struct arm_pmu *pmu,
+ const struct pmu_probe_info *info,
+ unsigned int pmuid)
{
- int cpu = get_cpu();
- unsigned int cpuid = read_cpuid_id();
int ret = -ENODEV;
+ int cpu;
+ int aff_ctr = 0;
+ static int duplicate_pmus;
+ struct platform_device *pdev = pmu->plat_device;
+ int irq = platform_get_irq(pdev, 0);
- pr_info("probing PMU on CPU %d\n", cpu);
+ if (irq >= 0 && !irq_is_percpu(irq)) {
+ pmu->irq_affinity = kcalloc(pdev->num_resources, sizeof(int),
+ GFP_KERNEL);
+ if (!pmu->irq_affinity)
+ return -ENOMEM;
+ }
+ for_each_possible_cpu(cpu) {
+ unsigned int cpuid = read_specific_cpuid(cpu);
+
+ if (cpuid == pmuid) {
+ cpumask_set_cpu(cpu, &pmu->supported_cpus);
+ if (pmu->irq_affinity) {
+ pmu->irq_affinity[aff_ctr] = cpu;
+ aff_ctr++;
+ }
+ }
+ }
+
+ /* find the type of PMU given the CPU */
for (; info->init != NULL; info++) {
- if ((cpuid & info->mask) != info->cpuid)
+ if ((pmuid & info->mask) != info->cpuid)
continue;
ret = info->init(pmu);
+ /*
+ * if this pmu declaration is unspecified and we have
+ * previously found a PMU on this platform then append
+ * a PMU number to the pmu name. This avoids changing
+ * the names of PMUs that are specific to a class of CPUs.
+ * The assumption is that if we match a specific PMU in the
+ * provided pmu_probe_info then it's unique, and another PMU
+ * in the system will match a different entry rather than
+ * needing the _number to assure its unique.
+ */
+ if ((!info->cpuid) && (duplicate_pmus)) {
+ pmu->name = kasprintf(GFP_KERNEL, "%s_%d",
+ pmu->name, duplicate_pmus);
+ if (!pmu->name) {
+ kfree(pmu->irq_affinity);
+ ret = -ENOMEM;
+ }
+ }
+ duplicate_pmus++;
break;
}
- put_cpu();
return ret;
}
@@ -1043,8 +1087,7 @@ int arm_pmu_device_probe(struct platform_device *pdev,
if (!ret)
ret = init_fn(pmu);
} else if (probe_table) {
- cpumask_setall(&pmu->supported_cpus);
- ret = probe_current_pmu(pmu, probe_table);
+ ret = probe_plat_pmu(pmu, probe_table, read_cpuid_id());
}
if (ret) {
--
2.5.5
^ permalink raw reply related
* [PATCH V10 3/6] arm64: pmu: Cache PMU interrupt numbers from MADT parse
From: Jeremy Linton @ 2016-11-09 23:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478734793-6341-1-git-send-email-jeremy.linton@arm.com>
From: Mark Salter <msalter@redhat.com>
In the case of ACPI, the PMU IRQ information is contained in the
MADT table. Also, since the PMU does not exist as a device in the
ACPI DSDT table, it is necessary to create a platform device so
that the appropriate driver probing is triggered. Since the platform
device creation needs to happen after the CPU's have been started, and
the MADT parsing needs to happen before, we save off the interrupt
numbers discovered during the parsing.
Signed-off-by: Mark Salter <msalter@redhat.com>
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
---
arch/arm64/kernel/smp.c | 5 +++++
drivers/perf/Kconfig | 4 ++++
drivers/perf/Makefile | 1 +
drivers/perf/arm_pmu_acpi.c | 40 ++++++++++++++++++++++++++++++++++++++++
include/linux/perf/arm_pmu.h | 7 +++++++
5 files changed, 57 insertions(+)
create mode 100644 drivers/perf/arm_pmu_acpi.c
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index f3f1c90..e350ccc 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -37,6 +37,7 @@
#include <linux/completion.h>
#include <linux/of.h>
#include <linux/irq_work.h>
+#include <linux/perf/arm_pmu.h>
#include <asm/alternative.h>
#include <asm/atomic.h>
@@ -546,6 +547,7 @@ acpi_verify_and_map_madt(struct acpi_madt_generic_interrupt *processor)
}
bootcpu_valid = true;
early_map_cpu_to_node(0, acpi_numa_get_nid(0, hwid));
+ arm_pmu_parse_acpi(0, processor);
return;
}
@@ -566,6 +568,9 @@ acpi_verify_and_map_madt(struct acpi_madt_generic_interrupt *processor)
*/
acpi_set_mailbox_entry(cpu_count, processor);
+ /* get PMU irq info */
+ arm_pmu_parse_acpi(cpu_count, processor);
+
early_map_cpu_to_node(cpu_count, acpi_numa_get_nid(cpu_count, hwid));
cpu_count++;
diff --git a/drivers/perf/Kconfig b/drivers/perf/Kconfig
index 4d5c5f9..697df05 100644
--- a/drivers/perf/Kconfig
+++ b/drivers/perf/Kconfig
@@ -19,4 +19,8 @@ config XGENE_PMU
help
Say y if you want to use APM X-Gene SoC performance monitors.
+config ARM_PMU_ACPI
+ def_bool y
+ depends on ARM_PMU && ACPI
+
endmenu
diff --git a/drivers/perf/Makefile b/drivers/perf/Makefile
index b116e98..d1d7762 100644
--- a/drivers/perf/Makefile
+++ b/drivers/perf/Makefile
@@ -1,2 +1,3 @@
obj-$(CONFIG_ARM_PMU) += arm_pmu.o
obj-$(CONFIG_XGENE_PMU) += xgene_pmu.o
+obj-$(CONFIG_ARM_PMU_ACPI) += arm_pmu_acpi.o
diff --git a/drivers/perf/arm_pmu_acpi.c b/drivers/perf/arm_pmu_acpi.c
new file mode 100644
index 0000000..135851c
--- /dev/null
+++ b/drivers/perf/arm_pmu_acpi.c
@@ -0,0 +1,40 @@
+/*
+ * ARM ACPI PMU support
+ *
+ * Copyright (C) 2015 Red Hat Inc.
+ * Author: Mark Salter <msalter@redhat.com>
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2. See
+ * the COPYING file in the top-level directory.
+ *
+ */
+
+#include <asm/cpu.h>
+#include <linux/acpi.h>
+#include <linux/irq.h>
+#include <linux/irqdesc.h>
+#include <linux/list.h>
+#include <linux/perf/arm_pmu.h>
+#include <linux/platform_device.h>
+
+struct pmu_irq {
+ int gsi;
+ int trigger;
+ bool registered;
+};
+
+static struct pmu_irq pmu_irqs[NR_CPUS];
+
+/*
+ * Called from acpi_verify_and_map_madt()'s MADT parsing during boot.
+ * This routine saves off the GSI's and their trigger state for use when we are
+ * ready to build the PMU platform device.
+ */
+void __init arm_pmu_parse_acpi(int cpu, struct acpi_madt_generic_interrupt *gic)
+{
+ pmu_irqs[cpu].gsi = gic->performance_interrupt;
+ if (gic->flags & ACPI_MADT_PERFORMANCE_IRQ_MODE)
+ pmu_irqs[cpu].trigger = ACPI_EDGE_SENSITIVE;
+ else
+ pmu_irqs[cpu].trigger = ACPI_LEVEL_SENSITIVE;
+}
diff --git a/include/linux/perf/arm_pmu.h b/include/linux/perf/arm_pmu.h
index 8462da2..df1ba55 100644
--- a/include/linux/perf/arm_pmu.h
+++ b/include/linux/perf/arm_pmu.h
@@ -164,4 +164,11 @@ int arm_pmu_device_probe(struct platform_device *pdev,
#endif /* CONFIG_ARM_PMU */
+#ifdef CONFIG_ARM_PMU_ACPI
+struct acpi_madt_generic_interrupt;
+void arm_pmu_parse_acpi(int cpu, struct acpi_madt_generic_interrupt *gic);
+#else
+#define arm_pmu_parse_acpi(a, b) do { } while (0)
+#endif /* CONFIG_ARM_PMU_ACPI */
+
#endif /* __ARM_PMU_H__ */
--
2.5.5
^ permalink raw reply related
* [PATCH V10 2/6] arm: arm64: Add routine to determine cpuid of other cpus
From: Jeremy Linton @ 2016-11-09 23:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478734793-6341-1-git-send-email-jeremy.linton@arm.com>
It is helpful if we can read the cpuid/midr of other CPUs
in the system independent of arm/arm64.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
---
arch/arm/include/asm/cputype.h | 2 ++
arch/arm64/include/asm/cputype.h | 3 +++
2 files changed, 5 insertions(+)
diff --git a/arch/arm/include/asm/cputype.h b/arch/arm/include/asm/cputype.h
index 522b5fe..31fb273 100644
--- a/arch/arm/include/asm/cputype.h
+++ b/arch/arm/include/asm/cputype.h
@@ -235,6 +235,8 @@ static inline unsigned int __attribute_const__ read_cpuid_mpidr(void)
#define cpu_is_sa1100() (read_cpuid_part() == ARM_CPU_PART_SA1100)
#define cpu_is_sa1110() (read_cpuid_part() == ARM_CPU_PART_SA1110)
+#define read_specific_cpuid(cpu_num) per_cpu_ptr(&cpu_data, cpu_num)->cpuid
+
/*
* Intel's XScale3 core supports some v6 features (supersections, L2)
* but advertises itself as v5 as it does not support the v6 ISA. For
diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h
index 26a68dd..a6d26e1 100644
--- a/arch/arm64/include/asm/cputype.h
+++ b/arch/arm64/include/asm/cputype.h
@@ -124,6 +124,9 @@ static inline u32 __attribute_const__ read_cpuid_cachetype(void)
{
return read_cpuid(CTR_EL0);
}
+
+#define read_specific_cpuid(cpu_num) per_cpu_ptr(&cpu_data, cpu_num)->reg_midr
+
#endif /* __ASSEMBLY__ */
#endif
--
2.5.5
^ permalink raw reply related
* [PATCH V10 1/6] arm64: Rename the common MADT parse routine
From: Jeremy Linton @ 2016-11-09 23:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478734793-6341-1-git-send-email-jeremy.linton@arm.com>
The MADT parser in smp.c is now being used to parse
out NUMA, PMU and ACPI parking protocol information as
well as the GIC information for which it was originally
created. Rename it to avoid a misleading name.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
---
arch/arm64/kernel/smp.c | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index 8507703..f3f1c90 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -511,13 +511,14 @@ static unsigned int cpu_count = 1;
#ifdef CONFIG_ACPI
/*
- * acpi_map_gic_cpu_interface - parse processor MADT entry
+ * acpi_verify_and_map_madt - parse processor MADT entry
*
* Carry out sanity checks on MADT processor entry and initialize
- * cpu_logical_map on success
+ * cpu_logical_map, the ACPI parking protocol, NUMA mapping
+ * and the PMU interrupts on success
*/
static void __init
-acpi_map_gic_cpu_interface(struct acpi_madt_generic_interrupt *processor)
+acpi_verify_and_map_madt(struct acpi_madt_generic_interrupt *processor)
{
u64 hwid = processor->arm_mpidr;
@@ -571,7 +572,7 @@ acpi_map_gic_cpu_interface(struct acpi_madt_generic_interrupt *processor)
}
static int __init
-acpi_parse_gic_cpu_interface(struct acpi_subtable_header *header,
+acpi_parse_madt_common(struct acpi_subtable_header *header,
const unsigned long end)
{
struct acpi_madt_generic_interrupt *processor;
@@ -582,7 +583,7 @@ acpi_parse_gic_cpu_interface(struct acpi_subtable_header *header,
acpi_table_print_madt_entry(header);
- acpi_map_gic_cpu_interface(processor);
+ acpi_verify_and_map_madt(processor);
return 0;
}
@@ -666,7 +667,7 @@ void __init smp_init_cpus(void)
* we need for SMP init
*/
acpi_table_parse_madt(ACPI_MADT_TYPE_GENERIC_INTERRUPT,
- acpi_parse_gic_cpu_interface, 0);
+ acpi_parse_madt_common, 0);
if (cpu_count > nr_cpu_ids)
pr_warn("Number of cores (%d) exceeds configured maximum of %d - clipping\n",
--
2.5.5
^ permalink raw reply related
* [PATCH V10 0/6] Enable PMUs in ACPI Systems
From: Jeremy Linton @ 2016-11-09 23:39 UTC (permalink / raw)
To: linux-arm-kernel
This patch expands and reworks the patches published by Mark Salter
in order to clean up a few of the previous review comments, as well as
add support for newer CPUs and big/little configurations.
v10:
- Rebase to 4.9
- Rework the arm_perf_start_cpu changes to support the 4.9 hotplug
changes.
- Remove the call to acpi_register_gsi() from the cpu online code path.
Instead the GSI's are registered during the initcall. This changes
the error handling a bit because we now try to clean up the
previously registered GSIs in a couple important places. This
was also a result of the rebase.
- Dropped the MIDR partnumber usage, its no longer necessary to
differentiate by only the partnum, so this helps to clarify the code
a bit.
- Shuffle some code around and rename a few variables.
- Added a few comments to hopefully clarify some questions people have
previously had about unused MADT entries, skipping processing cores
with MIDR=0, etc.
v9:
- Add/cleanup an additional hotplug patch I've had sitting around. This
patch brings the ACPI PMU mostly on par with the DT functionality with
respect to having CPUs offline during boot. This should help clarify
some of the code structuring.
- Cleanup the list of PMU types early if we fail to allocate memory for an
additional pmu type.
v8:
- Rebase to 4.8rc4
- Assorted minor comment/hunk placement/etc tweaks per Punit Agrawal
v7:
- Rebase to 4.8rc3
- Remove cpu affinity sysfs entry. While providing a CPU mask for
ARMv8 PMU's is really helpful in big/little environments, reworking
the PMU code to support the cpumask attribute for !arm64 PMUs is out
of the scope of this patch set.
- Fix CPU miscount problem where an alloc failure followed by successfully
allocating the structure can result in under counting the CPUs associated
with the PMU. This bug was created in v6 with the conversion to a linked
list.
- Remove initial platform device creation code by Mark Salter, and re-squash
multiple platform device creation code together with helper routines.
Other minor tweakage.
v6:
- Added cpu affinity sysfs entry
- Converted pmu_types array, to linked list
- Restrict use of the armv8_pmu_probe_table to ACPI systems
- Rename MADT parsing routines in smp.c
- Convert sysfs PMU name to use index rather than partnum
- Remove pr_devel statements
- Other Minor cleanups
- Add Partial Ack-by Will Deacon
v5:
- Remove list of CPU types for ACPI systems. We now match a generic
event list, and use the PMCIED[01] to select events which exist on
the given PMU. This avoids the need to update the kernel every time
a new CPU is released.
- Update the maintainers list to include the new file.
v4:
- Correct build issues with ARM (!ARM64) kernels.
- Add ThunderX to list of PMU types.
v3:
- Enable ARM performance monitoring units on ACPI/arm64 machines.
Jeremy Linton (5):
arm64: Rename the common MADT parse routine
arm: arm64: Add routine to determine cpuid of other cpus
arm: arm64: pmu: Assign platform PMU CPU affinity
arm64: pmu: Detect and enable multiple PMUs in an ACPI system
arm: pmu: Add PMU definitions for cores not initially online
Mark Salter (1):
arm64: pmu: Cache PMU interrupt numbers from MADT parse
arch/arm/include/asm/cputype.h | 2 +
arch/arm64/include/asm/cputype.h | 3 +
arch/arm64/kernel/smp.c | 18 ++-
drivers/perf/Kconfig | 4 +
drivers/perf/Makefile | 1 +
drivers/perf/arm_pmu.c | 107 +++++++++++++--
drivers/perf/arm_pmu_acpi.c | 272 +++++++++++++++++++++++++++++++++++++++
include/linux/perf/arm_pmu.h | 11 ++
8 files changed, 400 insertions(+), 18 deletions(-)
create mode 100644 drivers/perf/arm_pmu_acpi.c
--
2.5.5
^ permalink raw reply
* Summary of LPC guest MSI discussion in Santa Fe
From: Will Deacon @ 2016-11-09 23:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161109162458.39594fdb@t450s.home>
On Wed, Nov 09, 2016 at 04:24:58PM -0700, Alex Williamson wrote:
> On Wed, 9 Nov 2016 22:25:22 +0000
> Will Deacon <will.deacon@arm.com> wrote:
>
> > On Wed, Nov 09, 2016 at 03:17:09PM -0700, Alex Williamson wrote:
> > > On Wed, 9 Nov 2016 20:31:45 +0000
> > > Will Deacon <will.deacon@arm.com> wrote:
> > > > On Wed, Nov 09, 2016 at 08:23:03PM +0100, Christoffer Dall wrote:
> > > > >
> > > > > (I suppose it's technically possible to get around this issue by letting
> > > > > QEMU place RAM wherever it wants but tell the guest to never use a
> > > > > particular subset of its RAM for DMA, because that would conflict with
> > > > > the doorbell IOVA or be seen as p2p transactions. But I think we all
> > > > > probably agree that it's a disgusting idea.)
> > > >
> > > > Disgusting, yes, but Ben's idea of hotplugging on the host controller with
> > > > firmware tables describing the reserved regions is something that we could
> > > > do in the distant future. In the meantime, I don't think that VFIO should
> > > > explicitly reject overlapping mappings if userspace asks for them.
> > >
> > > I'm confused by the last sentence here, rejecting user mappings that
> > > overlap reserved ranges, such as MSI doorbell pages, is exactly how
> > > we'd reject hot-adding a device when we meet such a conflict. If we
> > > don't reject such a mapping, we're knowingly creating a situation that
> > > potentially leads to data loss. Minimally, QEMU would need to know
> > > about the reserved region, map around it through VFIO, and take
> > > responsibility (somehow) for making sure that region is never used for
> > > DMA. Thanks,
> >
> > Yes, but my point is that it should be up to QEMU to abort the hotplug, not
> > the host kernel, since there may be ways in which a guest can tolerate the
> > overlapping region (e.g. by avoiding that range of memory for DMA).
>
> The VFIO_IOMMU_MAP_DMA ioctl is a contract, the user ask to map a range
> of IOVAs to a range of virtual addresses for a given device. If VFIO
> cannot reasonably fulfill that contract, it must fail. It's up to QEMU
> how to manage the hotplug and what memory regions it asks VFIO to map
> for a device, but VFIO must reject mappings that it (or the SMMU by
> virtue of using the IOMMU API) know to overlap reserved ranges. So I
> still disagree with the referenced statement. Thanks,
I think that's a pity. Not only does it mean that both QEMU and the kernel
have more work to do (the former has to carve up its mapping requests,
whilst the latter has to check that it is indeed doing this), but it also
precludes the use of hugepage mappings on the IOMMU because of reserved
regions. For example, a 4k hole someplace may mean we can't put down 1GB
table entries for the guest memory in the SMMU.
All this seems to do is add complexity and decrease performance. For what?
QEMU has to go read the reserved regions from someplace anyway. It's also
the way that VFIO works *today* on arm64 wrt reserved regions, it just has
no way to identify those holes at present.
Will
^ permalink raw reply
* [PATCH v7 01/16] drivers: acpi: add FWNODE_ACPI_STATIC fwnode type
From: Rafael J. Wysocki @ 2016-11-09 23:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161109141948.19244-2-lorenzo.pieralisi@arm.com>
On Wed, Nov 9, 2016 at 3:19 PM, Lorenzo Pieralisi
<lorenzo.pieralisi@arm.com> wrote:
> On systems booting with a device tree, every struct device is associated
> with a struct device_node, that provides its DT firmware representation.
> The device node can be used in generic kernel contexts (eg IRQ
> translation, IOMMU streamid mapping), to retrieve the properties
> associated with the device and carry out kernel operations accordingly.
> Owing to the 1:1 relationship between the device and its device_node,
> the device_node can also be used as a look-up token for the device (eg
> looking up a device through its device_node), to retrieve the device in
> kernel paths where the device_node is available.
>
> On systems booting with ACPI, the same abstraction provided by
> the device_node is required to provide look-up functionality.
>
> The struct acpi_device, that represents firmware objects in the
> ACPI namespace already includes a struct fwnode_handle of
> type FWNODE_ACPI as their member; the same abstraction is missing
> though for devices that are instantiated out of static ACPI tables
> entries (eg ARM SMMU devices).
>
> Add a new fwnode_handle type to associate devices created out
> of static ACPI table entries to the respective firmware components
> and create a simple ACPI core layer interface to dynamically allocate
> and free the corresponding firmware nodes so that kernel subsystems
> can use it to instantiate the nodes and associate them with the
> respective devices.
>
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org>
> Tested-by: Hanjun Guo <hanjun.guo@linaro.org>
> Tested-by: Tomasz Nowicki <tn@semihalf.com>
> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Thanks!
^ permalink raw reply
* [PATCH v7 00/16] ACPI IORT ARM SMMU support
From: Rafael J. Wysocki @ 2016-11-09 23:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161109141948.19244-1-lorenzo.pieralisi@arm.com>
Hi Lorenzo,
On Wed, Nov 9, 2016 at 3:19 PM, Lorenzo Pieralisi
<lorenzo.pieralisi@arm.com> wrote:
> This patch series is v7 of a previous posting:
>
> https://lkml.org/lkml/2016/10/18/506
I don't see anything objectionable in this series.
Please let me know which patches in particular to look at in detail.
Thanks,
Rafael
^ permalink raw reply
* Summary of LPC guest MSI discussion in Santa Fe
From: Alex Williamson @ 2016-11-09 23:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161109222522.GS17771@arm.com>
On Wed, 9 Nov 2016 22:25:22 +0000
Will Deacon <will.deacon@arm.com> wrote:
> On Wed, Nov 09, 2016 at 03:17:09PM -0700, Alex Williamson wrote:
> > On Wed, 9 Nov 2016 20:31:45 +0000
> > Will Deacon <will.deacon@arm.com> wrote:
> > > On Wed, Nov 09, 2016 at 08:23:03PM +0100, Christoffer Dall wrote:
> > > >
> > > > (I suppose it's technically possible to get around this issue by letting
> > > > QEMU place RAM wherever it wants but tell the guest to never use a
> > > > particular subset of its RAM for DMA, because that would conflict with
> > > > the doorbell IOVA or be seen as p2p transactions. But I think we all
> > > > probably agree that it's a disgusting idea.)
> > >
> > > Disgusting, yes, but Ben's idea of hotplugging on the host controller with
> > > firmware tables describing the reserved regions is something that we could
> > > do in the distant future. In the meantime, I don't think that VFIO should
> > > explicitly reject overlapping mappings if userspace asks for them.
> >
> > I'm confused by the last sentence here, rejecting user mappings that
> > overlap reserved ranges, such as MSI doorbell pages, is exactly how
> > we'd reject hot-adding a device when we meet such a conflict. If we
> > don't reject such a mapping, we're knowingly creating a situation that
> > potentially leads to data loss. Minimally, QEMU would need to know
> > about the reserved region, map around it through VFIO, and take
> > responsibility (somehow) for making sure that region is never used for
> > DMA. Thanks,
>
> Yes, but my point is that it should be up to QEMU to abort the hotplug, not
> the host kernel, since there may be ways in which a guest can tolerate the
> overlapping region (e.g. by avoiding that range of memory for DMA).
The VFIO_IOMMU_MAP_DMA ioctl is a contract, the user ask to map a range
of IOVAs to a range of virtual addresses for a given device. If VFIO
cannot reasonably fulfill that contract, it must fail. It's up to QEMU
how to manage the hotplug and what memory regions it asks VFIO to map
for a device, but VFIO must reject mappings that it (or the SMMU by
virtue of using the IOMMU API) know to overlap reserved ranges. So I
still disagree with the referenced statement. Thanks,
Alex
^ permalink raw reply
* [PATCH] PCI: mvebu: Take control of mbus windows setup by the firmware
From: Jason Gunthorpe @ 2016-11-09 23:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026174440.GA24717@obsidianresearch.com>
Hey Thomas,
Could you take a look at this? Thanks
Jason
On Wed, Oct 26, 2016 at 11:44:40AM -0600, Jason Gunthorpe wrote:
> The firmware may setup the mbus to access PCI-E and indicate this
> has happened with a ranges mapping for the PCI-E ID. If this happens
> then the mbus setup and the pci dynamic setup conflict, creating
> problems.
>
> Have PCI-E assume control of the firmware specified default mapping by
> setting the value of the bridge window to match the firmware mapping.
>
> Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
> drivers/bus/mvebu-mbus.c | 36 ++++++++++++++++++++++++++++++++++++
> drivers/pci/host/pci-mvebu.c | 22 ++++++++++++++++++++++
> include/linux/mbus.h | 3 +++
> 3 files changed, 61 insertions(+)
>
> In the DT this could look like:
>
> mbus {
> ranges = <MBUS_ID(0x04, 0xe8) 0 0xe0000000 0x8000000 /* PEX 0 MEM */
> pex at e0000000 {
> compatible = "marvell,kirkwood-pcie";
> ranges = <0x82000000 0 0x40000 MBUS_ID(0xf0, 0x01) 0x40000 0 0x00002000 /* Controller regs */
> 0x82000000 1 0 MBUS_ID(0x04, 0xe8) 0 1 0 /* Port 0.0 MEM */
> >;
> pcie at 1,0 {
> ranges = <0x82000000 0 0 0x82000000 0x1 0 1 0>;
> reg = <0x0800 0 0 0 0>; // 0000:00:01.0
>
> device at 0 {
> reg = <0x0 0 0 0 0>; // 0000:01:00.0
> ranges = <0x00000000 0x82000000 0x00000000 0x00000000 0x8000000>;
>
> Which is basically the OF way to describe PCI devices downstream of
> the interface and give information about what their BARs should be.
>
> This is useful if there is even more DT stuff below the explicitly
> declared device as it allows standard DT address translation to work
> properly.
>
> diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
> index c7f396903184..ce0ac5049c1f 100644
> +++ b/drivers/bus/mvebu-mbus.c
> @@ -922,6 +922,42 @@ int mvebu_mbus_add_window_by_id(unsigned int target, unsigned int attribute,
> size, MVEBU_MBUS_NO_REMAP);
> }
>
> +/**
> + * mvebu_mbus_get_single_window_by_id() - return the location of the window if
> + * the target/attribute has a single enabled mapping.
> + *
> + * RETURNS:
> + * -ENODEV if no mapping and -E2BIG if there is more than one mapping
> + */
> +int mvebu_mbus_get_single_window_by_id(unsigned int target,
> + unsigned int attribute,
> + phys_addr_t *base, phys_addr_t *size)
> +{
> + unsigned int win;
> + unsigned int count = 0;
> +
> + for (win = 0; win < mbus_state.soc->num_wins; win++) {
> + u64 wbase;
> + u32 wsize;
> + u8 wtarget, wattr;
> + int enabled;
> +
> + mvebu_mbus_read_window(&mbus_state, win, &enabled, &wbase,
> + &wsize, &wtarget, &wattr, NULL);
> + if (enabled && wtarget == target && wattr == attribute) {
> + *base = wbase;
> + *size = wsize;
> + count++;
> + }
> + }
> +
> + if (count == 1)
> + return 0;
> + if (count == 0)
> + return -ENODEV;
> + return -E2BIG;
> +}
> +
> int mvebu_mbus_del_window(phys_addr_t base, size_t size)
> {
> int win;
> diff --git a/drivers/pci/host/pci-mvebu.c b/drivers/pci/host/pci-mvebu.c
> index 307f81d6b479..5d5a2687b73e 100644
> +++ b/drivers/pci/host/pci-mvebu.c
> @@ -464,6 +464,8 @@ static void mvebu_pcie_handle_membase_change(struct mvebu_pcie_port *port)
> static void mvebu_sw_pci_bridge_init(struct mvebu_pcie_port *port)
> {
> struct mvebu_sw_pci_bridge *bridge = &port->bridge;
> + int rc;
> + phys_addr_t base, size;
>
> memset(bridge, 0, sizeof(struct mvebu_sw_pci_bridge));
>
> @@ -480,6 +482,26 @@ static void mvebu_sw_pci_bridge_init(struct mvebu_pcie_port *port)
>
> /* Add capabilities */
> bridge->status = PCI_STATUS_CAP_LIST;
> +
> + /*
> + * If the firmware has already setup a window for PCIe then assume
> + * control of it by defaulting the BAR to the window setting.
> + */
> + rc = mvebu_mbus_get_single_window_by_id(port->mem_target,
> + port->mem_attr, &base, &size);
> + if (rc == -E2BIG)
> + pr_err(FW_BUG "%s: Too many pre-existing mbus mappings\n",
> + port->dn->name);
> + if (!rc) {
> + if ((base & 0xFFFFF) != 0 || ((size + base) & 0xFFFFF) != 0)
> + pr_err(FW_BUG "%s: Invalid pre-existing mbus mapping\n",
> + port->dn->name);
> + port->memwin_base = base;
> + port->memwin_size = size;
> + port->bridge.membase = (base >> 16) & 0xFFF0;
> + port->bridge.memlimit = ((size - 1 + base) >> 16) & 0xFFF0;
> + port->bridge.command |= PCI_COMMAND_MEMORY;
> + }
> }
>
> /*
> diff --git a/include/linux/mbus.h b/include/linux/mbus.h
> index d610232762e3..dfafc27b41b5 100644
> +++ b/include/linux/mbus.h
> @@ -83,5 +83,8 @@ int mvebu_mbus_init(const char *soc, phys_addr_t mbus_phys_base,
> size_t mbus_size, phys_addr_t sdram_phys_base,
> size_t sdram_size);
> int mvebu_mbus_dt_init(bool is_coherent);
> +int mvebu_mbus_get_single_window_by_id(unsigned int target,
> + unsigned int attribute,
> + phys_addr_t *base, phys_addr_t *size);
>
> #endif /* __LINUX_MBUS_H */
^ permalink raw reply
* [PATCH v2 0/9] ARM: DRA7: Add support for DRA718-evm
From: Tony Lindgren @ 2016-11-09 23:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1b9c4d14-78d7-841f-776c-63a8c1ae1fb1@ti.com>
* Lokesh Vutla <lokeshvutla@ti.com> [161106 20:50]:
> Hi Tony,
>
> On Friday 21 October 2016 04:08 PM, Lokesh Vutla wrote:
> > This series does minor dts cleanup for dra72-evm and adds support for
> > DRA718-evm.
>
> Do you have any comments on this series?
Looks good to me except for the regulator patch that you need to repost.
Applying the rest split into various topic branches for soc/dt/defconfig.
Regards,
Tony
^ permalink raw reply
* [PATCH fpga 9/9] fpga: Remove support for non-sg drivers
From: Jason Gunthorpe @ 2016-11-09 22:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478732303-13718-1-git-send-email-jgunthorpe@obsidianresearch.com>
All drivers now use the sg interface so there is no reason to keep
the contiguous interface any more.
Now that all drivers support this interface we can also export it.
Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
---
drivers/fpga/fpga-mgr.c | 62 +++++++------------------------------------
include/linux/fpga/fpga-mgr.h | 7 ++---
2 files changed, 11 insertions(+), 58 deletions(-)
diff --git a/drivers/fpga/fpga-mgr.c b/drivers/fpga/fpga-mgr.c
index c2491ffeabd3..4ba22925d9d5 100644
--- a/drivers/fpga/fpga-mgr.c
+++ b/drivers/fpga/fpga-mgr.c
@@ -47,8 +47,8 @@ static struct class *fpga_mgr_class;
*
* Return: 0 on success, negative error code otherwise.
*/
-static int fpga_mgr_buf_load_sg(struct fpga_manager *mgr, u32 flags,
- struct sg_table *sgt)
+int fpga_mgr_buf_load_sg(struct fpga_manager *mgr, u32 flags,
+ struct sg_table *sgt)
{
struct device *dev = &mgr->dev;
int ret;
@@ -92,52 +92,7 @@ static int fpga_mgr_buf_load_sg(struct fpga_manager *mgr, u32 flags,
return 0;
}
-
-static int fpga_mgr_buf_load_mapped(struct fpga_manager *mgr, u32 flags,
- const char *buf, size_t count)
-{
- struct device *dev = &mgr->dev;
- int ret;
-
- /*
- * Call the low level driver's write_init function. This will do the
- * device-specific things to get the FPGA into the state where it is
- * ready to receive an FPGA image.
- */
- mgr->state = FPGA_MGR_STATE_WRITE_INIT;
- ret = mgr->mops->write_init(mgr, flags, buf, count);
- if (ret) {
- dev_err(dev, "Error preparing FPGA for writing\n");
- mgr->state = FPGA_MGR_STATE_WRITE_INIT_ERR;
- return ret;
- }
-
- /*
- * Write the FPGA image to the FPGA.
- */
- mgr->state = FPGA_MGR_STATE_WRITE;
- ret = mgr->mops->write(mgr, buf, count);
- if (ret) {
- dev_err(dev, "Error while writing image data to FPGA\n");
- mgr->state = FPGA_MGR_STATE_WRITE_ERR;
- return ret;
- }
-
- /*
- * After all the FPGA image has been written, do the device specific
- * steps to finish and set the FPGA into operating mode.
- */
- mgr->state = FPGA_MGR_STATE_WRITE_COMPLETE;
- ret = mgr->mops->write_complete(mgr, flags);
- if (ret) {
- dev_err(dev, "Error after writing image data to FPGA\n");
- mgr->state = FPGA_MGR_STATE_WRITE_COMPLETE_ERR;
- return ret;
- }
- mgr->state = FPGA_MGR_STATE_OPERATING;
-
- return 0;
-}
+EXPORT_SYMBOL_GPL(fpga_mgr_buf_load_sg);
/**
* fpga_mgr_buf_load - load fpga from image in buffer
@@ -163,9 +118,6 @@ int fpga_mgr_buf_load(struct fpga_manager *mgr, u32 flags, const char *buf,
int index;
int rc;
- if (!mgr->mops->write_init_sg || !mgr->mops->write_sg)
- return fpga_mgr_buf_load_mapped(mgr, flags, buf, count);
-
/*
* Convert the linear kernel pointer into a sg_table of pages for use
* by the driver.
@@ -226,6 +178,11 @@ int fpga_mgr_firmware_load(struct fpga_manager *mgr, u32 flags,
mgr->state = FPGA_MGR_STATE_FIRMWARE_REQ;
+ /*
+ * FIXME: We do not need a vmap, just a page list, but
+ * request_firmware has no way to give us that, so this needlessly
+ * consumes vmalloc space.
+ */
ret = request_firmware(&fw, image_name, dev);
if (ret) {
mgr->state = FPGA_MGR_STATE_FIRMWARE_REQ_ERR;
@@ -369,8 +326,7 @@ int fpga_mgr_register(struct device *dev, const char *name,
int id, ret;
if (!mops || !mops->write_complete || !mops->state ||
- ((!mops->write_init || !mops->write) &&
- (!mops->write_init_sg || !mops->write_sg))) {
+ !mops->write_init_sg || !mops->write_sg) {
dev_err(dev, "Attempt to register without fpga_manager_ops\n");
return -EINVAL;
}
diff --git a/include/linux/fpga/fpga-mgr.h b/include/linux/fpga/fpga-mgr.h
index 371b30ea60eb..5c698c8fe71b 100644
--- a/include/linux/fpga/fpga-mgr.h
+++ b/include/linux/fpga/fpga-mgr.h
@@ -72,8 +72,6 @@ enum fpga_mgr_states {
/**
* struct fpga_manager_ops - ops for low level fpga manager drivers
* @state: returns an enum value of the FPGA's state
- * @write_init: prepare the FPGA to receive confuration data (linear memory)
- * @write: write count bytes of configuration data to the FPGA
* @write_init_sg: prepare the FPGA to receive confuration data (scatter list
* table)
* @write_sg: write count bytes of configuration data to the FPGA
@@ -86,9 +84,6 @@ enum fpga_mgr_states {
*/
struct fpga_manager_ops {
enum fpga_mgr_states (*state)(struct fpga_manager *mgr);
- int (*write_init)(struct fpga_manager *mgr, u32 flags,
- const char *buf, size_t count);
- int (*write)(struct fpga_manager *mgr, const char *buf, size_t count);
int (*write_init_sg)(struct fpga_manager *mgr, u32 flags,
struct sg_table *sgt);
int (*write_sg)(struct fpga_manager *mgr, struct sg_table *sgt);
@@ -118,6 +113,8 @@ struct fpga_manager {
int fpga_mgr_buf_load(struct fpga_manager *mgr, u32 flags,
const char *buf, size_t count);
+int fpga_mgr_buf_load_sg(struct fpga_manager *mgr, u32 flags,
+ struct sg_table *sgt);
int fpga_mgr_firmware_load(struct fpga_manager *mgr, u32 flags,
const char *image_name);
--
2.1.4
^ permalink raw reply related
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