* [PATCH v4 06/12] dt: bindings: Add bindings for Marvell Xenon SD Host Controller
From: Gregory CLEMENT @ 2016-12-13 17:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.67d726f70f6bd48d38a2023513f2711080bc66c8.1481651244.git-series.gregory.clement@free-electrons.com>
From: Hu Ziji <huziji@marvell.com>
Marvell Xenon SDHC can support eMMC/SD/SDIO.
Add Xenon-specific properties.
Also add properties for Xenon PHY setting.
Signed-off-by: Hu Ziji <huziji@marvell.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.txt | 197 +++++++-
MAINTAINERS | 1 +-
2 files changed, 198 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.txt
diff --git a/Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.txt b/Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.txt
new file mode 100644
index 000000000000..c7589f8d4e3e
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.txt
@@ -0,0 +1,197 @@
+Marvell Xenon SDHCI Controller device tree bindings
+This file documents differences between the core mmc properties
+described by mmc.txt and the properties used by the Xenon implementation.
+
+Multiple SDHCs might be put into a single Xenon IP, to save size and cost.
+Each SDHC is independent and owns independent resources, such as register sets,
+clock and PHY.
+Each SDHC should have an independent device tree node.
+
+Required Properties:
+- compatible: should be one of the following
+ - "marvell,armada-3700-sdhci": For controllers on Armada-3700 SOC.
+ Must provide a second register area and marvell,pad-type.
+ - "marvell,armada-7000-sdhci": For controllers on Armada 7K/8K SOC.
+
+- clocks:
+ Array of clocks required for SDHC.
+ Require at least input clock for Xenon IP core.
+
+- clock-names:
+ Array of names corresponding to clocks property.
+ The input clock for Xenon IP core should be named as "core".
+
+- reg:
+ * For "marvell,armada-3700-sdhci", two register areas.
+ The first one for Xenon IP register. The second one for the Armada 3700 SOC
+ PHY PAD Voltage Control register.
+ Please follow the examples with compatible "marvell,armada-3700-sdhci"
+ in below.
+ Please also check property marvell,pad-type in below.
+
+ * For other compatible strings, one register area for Xenon IP.
+
+Optional Properties:
+- mmc-card:
+ mmc-card child node must be provided when current SDHC is for eMMC.
+ Xenon SDHC often can support both SD and eMMC. This child node indicates that
+ current SDHC is for eMMC card. Thus Xenon eMMC specific configuration and
+ operations can be enabled prior to eMMC init sequence.
+ Please refer to Documentation/devicetree/bindings/mmc/mmc-card.txt.
+ This child node should not be set if current Xenon SDHC is for SD/SDIO.
+
+- bus-width:
+ When 8-bit data bus width is in use for eMMC, this property should be
+ explicitly provided and set as 8.
+ It is optional when data bus width is 4-bit or 1-bit.
+
+- mmc-ddr-1_8v:
+ Select this property when eMMC HS DDR is supported on SDHC side.
+
+- mmc-hs400-1_8v:
+ Select this property when eMMC HS400 is supported on SDHC side.
+
+- no-1-8-v:
+ Select this property when 1.8V signaling voltage supply is unavailable.
+ When this property is enabled, both mmc-ddr-1_8v and mmc-hs400-1_8v should be
+ cleared.
+
+- marvell,xenon-sdhc-id:
+ Indicate the corresponding bit index of current SDHC in
+ SDHC System Operation Control Register Bit[7:0].
+ Set/clear the corresponding bit to enable/disable current SDHC.
+ If Xenon IP contains only one SDHC, this property is optional.
+
+- marvell,xenon-phy-type:
+ Xenon support mutilple types of PHYs.
+ To select eMMC 5.1 PHY, set:
+ marvell,xenon-phy-type = "emmc 5.1 phy"
+ eMMC 5.1 PHY is the default choice if this property is not provided.
+ To select eMMC 5.0 PHY, set:
+ marvell,xenon-phy-type = "emmc 5.0 phy"
+
+ All those types of PHYs can support eMMC, SD and SDIO.
+ Please note that this property only presents the type of PHY.
+ It doesn't stand for the entire SDHC type or property.
+ For example, "emmc 5.1 phy" doesn't mean that this Xenon SDHC only supports
+ eMMC 5.1.
+
+- marvell,xenon-phy-znr:
+ Set PHY ZNR value.
+ Only available for eMMC PHY 5.1 and eMMC PHY 5.0.
+ Valid range = [0:0x1F].
+ ZNR is set as 0xF by default if this property is not provided.
+
+- marvell,xenon-phy-zpr:
+ Set PHY ZPR value.
+ Only available for eMMC PHY 5.1 and eMMC PHY 5.0.
+ Valid range = [0:0x1F].
+ ZPR is set as 0xF by default if this property is not provided.
+
+- marvell,xenon-phy-nr-success-tun:
+ Set the number of required consecutive successful sampling points used to
+ identify a valid sampling window, in tuning process.
+ Valid range = [1:7].
+ Set as 0x4 by default if this property is not provided.
+
+- marvell,xenon-phy-tun-step-divider:
+ Set the divider for calculating TUN_STEP.
+ Set as 64 by default if this property is not provided.
+
+- marvell,xenon-phy-slow-mode:
+ If this property is selected, transfers will bypass PHY.
+ Only available when bus frequency lower than 55MHz in SDR mde.
+ Disabled by default. Please only try this property if timing issues always
+ occur with PHY enabled in eMMC HS SDR, SD SDR12, SD SDR25, SD SDR50 mode.
+
+- marvell,xenon-tun-count:
+ Xenon SDHC SOC usually doesn't provide re-tuning counter in
+ Capabilities Register 3 Bit[11:8].
+ This property provides the re-tuning counter.
+ If this property is not set, default re-tuning counter will
+ be set as 0x9 in driver.
+
+- marvell,pad-type:
+ Type of Armada 3700 SOC PHY PAD Voltage Controller register.
+ Only valid when "marvell,armada-3700-sdhci" is selected.
+ Two types: "sd" and "fixed-1-8v".
+ If "sd" is slected, SOC PHY PAD is set as 3.3V at the beginning and is
+ switched to 1.8V when SD in UHS-I.
+ If "fixed-1-8v" is slected, SOC PHY PAD is fixed 1.8V, such as for eMMC.
+ Please follow the examples with compatible "marvell,armada-3700-sdhci"
+ in below.
+
+Example:
+- For eMMC:
+
+ sdhci at aa0000 {
+ compatible = "marvell,armada-7000-sdhci";
+ reg = <0xaa0000 0x1000>;
+ interrupts = <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>
+ clocks = <&emmc_clk>;
+ clock-names = "core";
+ bus-width = <8>;
+ mmc-ddr-1_8v;
+ mmc-hs400-1_8v;
+ marvell,xenon-sdhc-id = <0>;
+ marvell,xenon-phy-type = "emmc 5.1 phy";
+ marvell,xenon-tun-count = <11>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+ mmccard: mmccard at 0 {
+ compatible = "mmc-card";
+ reg = <0>;
+ };
+ };
+
+- For SD/SDIO:
+
+ sdhci at ab0000 {
+ compatible = "marvell,armada-7000-sdhci";
+ reg = <0xab0000 0x1000>;
+ interrupts = <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>
+ vqmmc-supply = <&sd_regulator>;
+ clocks = <&sdclk>;
+ clock-names = "core";
+ bus-width = <4>;
+ marvell,xenon-tun-count = <9>;
+ };
+
+- For eMMC with compatible "marvell,armada-3700-sdhci":
+
+ sdhci at aa0000 {
+ compatible = "marvell,armada-3700-sdhci";
+ reg = <0xaa0000 0x1000>,
+ <phy_addr 0x4>;
+ interrupts = <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>
+ clocks = <&emmcclk>;
+ clock-names = "core";
+ bus-width = <8>;
+ mmc-ddr-1_8v;
+ mmc-hs400-1_8v;
+
+ marvell,pad-type = "fixed-1-8v";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+ mmccard: mmccard at 0 {
+ compatible = "mmc-card";
+ reg = <0>;
+ };
+ };
+
+- For SD/SDIO with compatible "marvell,armada-3700-sdhci":
+
+ sdhci at ab0000 {
+ compatible = "marvell,armada-3700-sdhci";
+ reg = <0xab0000 0x1000>,
+ <phy_addr 0x4>;
+ interrupts = <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>
+ vqmmc-supply = <&sd_regulator>;
+ clocks = <&sdclk>;
+ clock-names = "core";
+ bus-width = <4>;
+
+ marvell,pad-type = "sd";
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index 1a5c4c30ea24..850a0afb0c8d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7608,6 +7608,7 @@ MARVELL XENON MMC/SD/SDIO HOST CONTROLLER DRIVER
M: Ziji Hu <huziji@marvell.com>
L: linux-mmc at vger.kernel.org
S: Supported
+F: Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.txt
MATROX FRAMEBUFFER DRIVER
L: linux-fbdev at vger.kernel.org
--
git-series 0.9.1
^ permalink raw reply related
* [PATCH v4 05/12] MAINTAINERS: add entry for Marvell Xenon MMC Host Controller drivers
From: Gregory CLEMENT @ 2016-12-13 17:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.67d726f70f6bd48d38a2023513f2711080bc66c8.1481651244.git-series.gregory.clement@free-electrons.com>
From: Hu Ziji <huziji@marvell.com>
Add maintainer entry for Marvell Xenon eMMC/SD/SDIO Host
Controller drivers.
Signed-off-by: Hu Ziji <huziji@marvell.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
MAINTAINERS | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index c44795306342..1a5c4c30ea24 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7604,6 +7604,11 @@ M: Nicolas Pitre <nico@fluxnic.net>
S: Odd Fixes
F: drivers/mmc/host/mvsdio.*
+MARVELL XENON MMC/SD/SDIO HOST CONTROLLER DRIVER
+M: Ziji Hu <huziji@marvell.com>
+L: linux-mmc at vger.kernel.org
+S: Supported
+
MATROX FRAMEBUFFER DRIVER
L: linux-fbdev at vger.kernel.org
S: Orphan
--
git-series 0.9.1
^ permalink raw reply related
* [PATCH v4 04/12] mmc: sdhci: Export sdhci_enable_sdio_irq() from sdhci.c
From: Gregory CLEMENT @ 2016-12-13 17:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.67d726f70f6bd48d38a2023513f2711080bc66c8.1481651244.git-series.gregory.clement@free-electrons.com>
From: Hu Ziji <huziji@marvell.com>
Export sdhci_enable_sdio_irq() from sdhci.c. Thus vendor SDHC
driver can implement its specific SDIO irq contorl.
Signed-off-by: Hu Ziji <huziji@marvell.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
drivers/mmc/host/sdhci.c | 3 ++-
drivers/mmc/host/sdhci.h | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index e971abb1368f..e174379ee019 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1817,7 +1817,7 @@ static void sdhci_enable_sdio_irq_nolock(struct sdhci_host *host, int enable)
}
}
-static void sdhci_enable_sdio_irq(struct mmc_host *mmc, int enable)
+void sdhci_enable_sdio_irq(struct mmc_host *mmc, int enable)
{
struct sdhci_host *host = mmc_priv(mmc);
unsigned long flags;
@@ -1831,6 +1831,7 @@ static void sdhci_enable_sdio_irq(struct mmc_host *mmc, int enable)
sdhci_enable_sdio_irq_nolock(host, enable);
spin_unlock_irqrestore(&host->lock, flags);
}
+EXPORT_SYMBOL_GPL(sdhci_enable_sdio_irq);
int sdhci_start_signal_voltage_switch(struct mmc_host *mmc,
struct mmc_ios *ios)
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index 95beadc66849..a3e8913452fc 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -692,6 +692,7 @@ void sdhci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios);
int sdhci_start_signal_voltage_switch(struct mmc_host *mmc,
struct mmc_ios *ios);
int sdhci_execute_tuning(struct mmc_host *mmc, u32 opcode);
+void sdhci_enable_sdio_irq(struct mmc_host *mmc, int enable);
#ifdef CONFIG_PM
extern int sdhci_suspend_host(struct sdhci_host *host);
--
git-series 0.9.1
^ permalink raw reply related
* [PATCH v4 03/12] mmc: sdhci: Export sdhci_execute_tuning() in sdhci.c
From: Gregory CLEMENT @ 2016-12-13 17:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.67d726f70f6bd48d38a2023513f2711080bc66c8.1481651244.git-series.gregory.clement@free-electrons.com>
From: Hu Ziji <huziji@marvell.com>
Export sdhci_execute_tuning() from sdhci.c.
Thus vendor sdhci driver can execute its own tuning process.
Signed-off-by: Hu Ziji <huziji@marvell.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
drivers/mmc/host/sdhci.c | 3 ++-
drivers/mmc/host/sdhci.h | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 8e6e4e37e3b4..e971abb1368f 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1950,7 +1950,7 @@ static int sdhci_prepare_hs400_tuning(struct mmc_host *mmc, struct mmc_ios *ios)
return 0;
}
-static int sdhci_execute_tuning(struct mmc_host *mmc, u32 opcode)
+int sdhci_execute_tuning(struct mmc_host *mmc, u32 opcode)
{
struct sdhci_host *host = mmc_priv(mmc);
u16 ctrl;
@@ -2139,6 +2139,7 @@ static int sdhci_execute_tuning(struct mmc_host *mmc, u32 opcode)
spin_unlock_irqrestore(&host->lock, flags);
return err;
}
+EXPORT_SYMBOL_GPL(sdhci_execute_tuning);
static int sdhci_select_drive_strength(struct mmc_card *card,
unsigned int max_dtr, int host_drv,
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index cd18b6f19c3b..95beadc66849 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -691,6 +691,7 @@ void sdhci_set_uhs_signaling(struct sdhci_host *host, unsigned timing);
void sdhci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios);
int sdhci_start_signal_voltage_switch(struct mmc_host *mmc,
struct mmc_ios *ios);
+int sdhci_execute_tuning(struct mmc_host *mmc, u32 opcode);
#ifdef CONFIG_PM
extern int sdhci_suspend_host(struct sdhci_host *host);
--
git-series 0.9.1
^ permalink raw reply related
* [PATCH v4 02/12] mmc: sdhci: Export sdhci_start_signal_voltage_switch() in sdhci.c
From: Gregory CLEMENT @ 2016-12-13 17:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.67d726f70f6bd48d38a2023513f2711080bc66c8.1481651244.git-series.gregory.clement@free-electrons.com>
From: Hu Ziji <huziji@marvell.com>
Export sdhci_start_signal_voltage_switch() from sdhci.c.
Thus vendor sdhci driver can implement its own signal voltage
switch routine.
Signed-off-by: Hu Ziji <huziji@marvell.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
drivers/mmc/host/sdhci.c | 5 +++--
drivers/mmc/host/sdhci.h | 2 ++
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index ea06faf8a437..8e6e4e37e3b4 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1832,8 +1832,8 @@ static void sdhci_enable_sdio_irq(struct mmc_host *mmc, int enable)
spin_unlock_irqrestore(&host->lock, flags);
}
-static int sdhci_start_signal_voltage_switch(struct mmc_host *mmc,
- struct mmc_ios *ios)
+int sdhci_start_signal_voltage_switch(struct mmc_host *mmc,
+ struct mmc_ios *ios)
{
struct sdhci_host *host = mmc_priv(mmc);
u16 ctrl;
@@ -1925,6 +1925,7 @@ static int sdhci_start_signal_voltage_switch(struct mmc_host *mmc,
return 0;
}
}
+EXPORT_SYMBOL_GPL(sdhci_start_signal_voltage_switch);
static int sdhci_card_busy(struct mmc_host *mmc)
{
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index 37771de4cafa..cd18b6f19c3b 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -689,6 +689,8 @@ void sdhci_set_bus_width(struct sdhci_host *host, int width);
void sdhci_reset(struct sdhci_host *host, u8 mask);
void sdhci_set_uhs_signaling(struct sdhci_host *host, unsigned timing);
void sdhci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios);
+int sdhci_start_signal_voltage_switch(struct mmc_host *mmc,
+ struct mmc_ios *ios);
#ifdef CONFIG_PM
extern int sdhci_suspend_host(struct sdhci_host *host);
--
git-series 0.9.1
^ permalink raw reply related
* [PATCH v4 01/12] mmc: sdhci: Export sdhci_set_ios() from sdhci.c
From: Gregory CLEMENT @ 2016-12-13 17:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.67d726f70f6bd48d38a2023513f2711080bc66c8.1481651244.git-series.gregory.clement@free-electrons.com>
From: Hu Ziji <huziji@marvell.com>
Export sdhci_set_ios() in sdhci.c.
Thus vendor sdhci driver can implement its own set_ios() routine.
Signed-off-by: Hu Ziji <huziji@marvell.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
drivers/mmc/host/sdhci.c | 3 ++-
drivers/mmc/host/sdhci.h | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 71654b90227f..ea06faf8a437 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1563,7 +1563,7 @@ void sdhci_set_uhs_signaling(struct sdhci_host *host, unsigned timing)
}
EXPORT_SYMBOL_GPL(sdhci_set_uhs_signaling);
-static void sdhci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
+void sdhci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
{
struct sdhci_host *host = mmc_priv(mmc);
unsigned long flags;
@@ -1723,6 +1723,7 @@ static void sdhci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
mmiowb();
spin_unlock_irqrestore(&host->lock, flags);
}
+EXPORT_SYMBOL_GPL(sdhci_set_ios);
static int sdhci_get_cd(struct mmc_host *mmc)
{
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index 766df17fb7eb..37771de4cafa 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -688,6 +688,7 @@ void sdhci_set_power_noreg(struct sdhci_host *host, unsigned char mode,
void sdhci_set_bus_width(struct sdhci_host *host, int width);
void sdhci_reset(struct sdhci_host *host, u8 mask);
void sdhci_set_uhs_signaling(struct sdhci_host *host, unsigned timing);
+void sdhci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios);
#ifdef CONFIG_PM
extern int sdhci_suspend_host(struct sdhci_host *host);
--
git-series 0.9.1
^ permalink raw reply related
* [PATCH v4 00/12] mmc: Add support to Marvell Xenon SD Host Controller
From: Gregory CLEMENT @ 2016-12-13 17:48 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
This the forth version of the series adding support for the SDHCI
Xenon controller. It can be currently found on the Armada 37xx and the
Armada 7K/8K but will be also used in more Marvell SoC (and not only
the mvebu ones actually).
v3 -> v4:
For this version a few change have been done:
- fixes 2 bug reported by kbuild-bot
- remove extra of_node_put()
- convert 0 in false for function returning boolean
- add a device tree node for the sdhci controller present on the CP
master for A7K/A8K. It also led to rename the sdhci0 node on AP to
ap_sdhci0 to make a distinction with the one present on CP master.
v2 -> v3
I think that now most (if not all) the remarks had been taking into
account since the second version. According to Ziji Hu, here are the
following changes:
" Changes in V3:
Adjust and improve Xenon DT bindings. Move some caps setting from driver into
DT. Use mmc-card sub-node to represent eMMC type.
Remove PHY Sampling Fixed Delay Line scan in lower speed mode.
Improve Xenon probe and ->init_card() functions.
Export sdhci_enable_sdio_irq() and implement own SDIO IRQ control.
Split PHY patch into two smaller patches.
Temporarily remove AXI clock before its implementation is improved."
Besides this changes I also
- Removed the sdhci-xenon-phy.h and moved its content in the
shc-xenon-phy.c file.
- Fixed the tuning-count usage
- Managed the error case for clk_prepare_enable
For the record the change from v1 was:
" Changes in V2:
rebase on v4.9-rc2.
Re-write Xenon bindings. Ajust Xenon DT property naming.
Add a new DT property to indicate eMMC card type, instead of using
variable card_candidate.
Clear quirks SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12 in Xenon platform data
Add support to HS400 retuning."
Thanks,
Gregory
Gregory CLEMENT (3):
arm64: dts: marvell: add eMMC support for Armada 37xx
arm64: dts: marvell: add sdhci support for Armada 7K/8K
arm64: configs: enable SDHCI driver for Xenon
Hu Ziji (9):
mmc: sdhci: Export sdhci_set_ios() from sdhci.c
mmc: sdhci: Export sdhci_start_signal_voltage_switch() in sdhci.c
mmc: sdhci: Export sdhci_execute_tuning() in sdhci.c
mmc: sdhci: Export sdhci_enable_sdio_irq() from sdhci.c
MAINTAINERS: add entry for Marvell Xenon MMC Host Controller drivers
dt: bindings: Add bindings for Marvell Xenon SD Host Controller
mmc: sdhci-xenon: Add Marvell Xenon SDHC core functionality
mmc: sdhci-xenon: Add support to PHYs of Marvell Xenon SDHC.
mmc: sdhci-xenon: Add SOC PHY PAD voltage control
Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.txt | 197 ++-
MAINTAINERS | 7 +-
arch/arm64/boot/dts/marvell/armada-3720-db.dts | 17 +-
arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 11 +-
arch/arm64/boot/dts/marvell/armada-7040-db.dts | 14 +-
arch/arm64/boot/dts/marvell/armada-ap806.dtsi | 9 +-
arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi | 10 +-
arch/arm64/configs/defconfig | 1 +-
drivers/mmc/host/Kconfig | 9 +-
drivers/mmc/host/Makefile | 3 +-
drivers/mmc/host/sdhci-xenon-phy.c | 908 +++++++-
drivers/mmc/host/sdhci-xenon.c | 615 +++++-
drivers/mmc/host/sdhci-xenon.h | 111 +-
drivers/mmc/host/sdhci.c | 14 +-
drivers/mmc/host/sdhci.h | 5 +-
15 files changed, 1926 insertions(+), 5 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.txt
create mode 100644 drivers/mmc/host/sdhci-xenon-phy.c
create mode 100644 drivers/mmc/host/sdhci-xenon.c
create mode 100644 drivers/mmc/host/sdhci-xenon.h
base-commit: 9fe68cad6e74967b88d0c6aeca7d9cd6b6e91942
--
git-series 0.9.1
^ permalink raw reply
* [PATCH 9/9] arm64: dts: rockchip: add regulator info for Kevin digitizer
From: Heiko Stuebner @ 2016-12-13 17:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480645653-36943-10-git-send-email-briannorris@chromium.org>
Am Donnerstag, 1. Dezember 2016, 18:27:33 CET schrieb Brian Norris:
> We need to enable this regulator before the digitizer can be used. Wacom
> recommended waiting for 100 ms before talking to the HID.
>
> Signed-off-by: Brian Norris <briannorris@chromium.org>
> ---
> Uses WIP bindings:
>
> [PATCH v3 1/2] devicetree: i2c-hid: Add regulator support
> https://patchwork.kernel.org/patch/9457493/
if you notice the bindings being accepted before me, could you notify here
please?
Thanks
Heiko
^ permalink raw reply
* [PATCH v6] arm64: fpsimd: improve stacking logic in non-interruptible context
From: Catalin Marinas @ 2016-12-13 17:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481632529-24218-1-git-send-email-ard.biesheuvel@linaro.org>
On Tue, Dec 13, 2016 at 12:35:29PM +0000, Ard Biesheuvel wrote:
> Currently, we allow kernel mode NEON in softirq or hardirq context by
> stacking and unstacking a slice of the NEON register file for each call
> to kernel_neon_begin() and kernel_neon_end(), respectively.
>
> Given that
> a) a CPU typically spends most of its time in userland, during which time
> no kernel mode NEON in process context is in progress,
> b) a CPU spends most of its time in the kernel doing other things than
> kernel mode NEON when it gets interrupted to perform kernel mode NEON
> in softirq context
>
> the stacking and subsequent unstacking is only necessary if we are
> interrupting a thread while it is performing kernel mode NEON in process
> context, which means that in all other cases, we can simply preserve the
> userland FPSIMD state once, and only restore it upon return to userland,
> even if we are being invoked from softirq or hardirq context.
>
> So instead of checking whether we are running in interrupt context, keep
> track of the level of nested kernel mode NEON calls in progress, and only
> perform the eager stack/unstack if the level exceeds 1.
>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
> v6:
> - use a spinlock instead of disabling interrupts
My concern with the spinlock or disabling interrupts is the latency if
we ever get some insanely long SVE vectors.
--
Catalin
^ permalink raw reply
* [PATCH v6 3/8] PWM: add pwm-stm32 DT bindings
From: Rob Herring @ 2016-12-13 17:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CA+M3ks6CQsOA0w82yiTaCw04e7gRwNx1mfeHanE3MDjkuX-gjg@mail.gmail.com>
On Tue, Dec 13, 2016 at 10:28 AM, Benjamin Gaignard
<benjamin.gaignard@linaro.org> wrote:
> 2016-12-13 16:57 GMT+01:00 Rob Herring <robh@kernel.org>:
>> On Tue, Dec 13, 2016 at 5:11 AM, Lee Jones <lee.jones@linaro.org> wrote:
>>> On Mon, 12 Dec 2016, Rob Herring wrote:
>>>
>>>> On Fri, Dec 09, 2016 at 03:15:14PM +0100, Benjamin Gaignard wrote:
>>>> > Define bindings for pwm-stm32
>>>> >
>>>> > version 6:
>>>> > - change st,breakinput parameter format to make it usuable on stm32f7 too.
>>>> >
>>>> > version 2:
>>>> > - use parameters instead of compatible of handle the hardware configuration
>>>> >
>>>> > Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
>>>> > ---
>>>> > .../devicetree/bindings/pwm/pwm-stm32.txt | 33 ++++++++++++++++++++++
>>>> > 1 file changed, 33 insertions(+)
>>>> > create mode 100644 Documentation/devicetree/bindings/pwm/pwm-stm32.txt
>>>> >
>>>> > diff --git a/Documentation/devicetree/bindings/pwm/pwm-stm32.txt b/Documentation/devicetree/bindings/pwm/pwm-stm32.txt
>>>> > new file mode 100644
>>>> > index 0000000..866f222
>>>> > --- /dev/null
>>>> > +++ b/Documentation/devicetree/bindings/pwm/pwm-stm32.txt
>>>> > @@ -0,0 +1,33 @@
>>>> > +STMicroelectronics STM32 Timers PWM bindings
>>>> > +
>>>> > +Must be a sub-node of an STM32 Timers device tree node.
>>>> > +See ../mfd/stm32-timers.txt for details about the parent node.
>>>> > +
>>>> > +Required parameters:
>>>> > +- compatible: Must be "st,stm32-pwm".
>>>> > +- pinctrl-names: Set to "default".
>>>> > +- pinctrl-0: List of phandles pointing to pin configuration nodes for PWM module.
>>>> > + For Pinctrl properties see ../pinctrl/pinctrl-bindings.txt
>>>> > +
>>>> > +Optional parameters:
>>>> > +- st,breakinput: Arrays of three u32 <index level filter> to describe break input configurations.
>>>> > + "index" indicates on which break input the configuration should be applied.
>>>> > + "level" gives the active level (0=low or 1=high) for this configuration.
>>>> > + "filter" gives the filtering value to be applied.
>>>> > +
>>>> > +Example:
>>>> > + timers at 40010000 {
>>>>
>>>> timer at ...
>>>
>>> No, it should be timers.
>>
>> Read the spec. "timer" is a generic node name. "timers" is not. How
>> many is not relevant.
>
> "timer" is already used in stm32 DT for clocksource node... It is also why
> I use "timers" for this.
That doesn't matter. They are at different levels in the hierarchy.
Rob
^ permalink raw reply
* [RFC v3 PATCH 00/25] Allow NOMMU for MULTIPLATFORM
From: Russell King - ARM Linux @ 2016-12-13 17:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161211070104.GB3035@afzalpc>
On Sun, Dec 11, 2016 at 12:31:04PM +0530, Afzal Mohammed wrote:
> And in buildroot,
> couldn't see Cortex R option in menuconfig, and selecting Cortex-A's
> excludes flat binary target & presents only with ELF.
That's something which has changed in the kernel - you can now build
for MMUful platforms, and run flat binaries. See commit d782e426b835
("ARM: 8594/1: enable binfmt_flat on systems with an MMU").
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH] net: mvpp2: fix dma unmapping of TX buffers for fragments
From: Marcin Wojtas @ 2016-12-13 17:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481647995-7213-1-git-send-email-thomas.petazzoni@free-electrons.com>
Hi Thomas,
Reviewed-by: Marcin Wojtas <mw@semihalf.com>
Best regards,
Marcin
2016-12-13 17:53 GMT+01:00 Thomas Petazzoni
<thomas.petazzoni@free-electrons.com>:
> Since commit 71ce391dfb784 ("net: mvpp2: enable proper per-CPU TX
> buffers unmapping"), we are not correctly DMA unmapping TX buffers for
> fragments.
>
> Indeed, the mvpp2_txq_inc_put() function only stores in the
> txq_cpu->tx_buffs[] array the physical address of the buffer to be
> DMA-unmapped when skb != NULL. In addition, when DMA-unmapping, we use
> skb_headlen(skb) to get the size to be unmapped. Both of this works fine
> for TX descriptors that are associated directly to a SKB, but not the
> ones that are used for fragments, with a NULL pointer as skb:
>
> - We have a NULL physical address when calling DMA unmap
> - skb_headlen(skb) crashes because skb is NULL
>
> This causes random crashes when fragments are used.
>
> To solve this problem, this commit:
>
> - Stores the physical address of the buffer to be unmapped
> unconditionally, regardless of whether it is tied to a SKB or not.
>
> - Adds a txq_cpu->tx_data_size[] array to store the size of the DMA
> buffer to be unmapped upon TX completion.
>
> Fixes: 71ce391dfb784 ("net: mvpp2: enable proper per-CPU TX buffers unmapping")
> Reported-by: Raphael G <raphael.glon@corp.ovh.com>
> Cc: Raphael G <raphael.glon@corp.ovh.com>
> Cc: stable at vger.kernel.org
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> ---
> drivers/net/ethernet/marvell/mvpp2.c | 20 ++++++++++++++++----
> 1 file changed, 16 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/ethernet/marvell/mvpp2.c b/drivers/net/ethernet/marvell/mvpp2.c
> index 1026c45..d168b13 100644
> --- a/drivers/net/ethernet/marvell/mvpp2.c
> +++ b/drivers/net/ethernet/marvell/mvpp2.c
> @@ -791,6 +791,8 @@ struct mvpp2_txq_pcpu {
> /* Array of transmitted buffers' physical addresses */
> dma_addr_t *tx_buffs;
>
> + size_t *tx_data_size;
> +
> /* Index of last TX DMA descriptor that was inserted */
> int txq_put_index;
>
> @@ -980,9 +982,10 @@ static void mvpp2_txq_inc_put(struct mvpp2_txq_pcpu *txq_pcpu,
> struct mvpp2_tx_desc *tx_desc)
> {
> txq_pcpu->tx_skb[txq_pcpu->txq_put_index] = skb;
> - if (skb)
> - txq_pcpu->tx_buffs[txq_pcpu->txq_put_index] =
> - tx_desc->buf_phys_addr;
> + txq_pcpu->tx_data_size[txq_pcpu->txq_put_index] =
> + tx_desc->data_size;
> + txq_pcpu->tx_buffs[txq_pcpu->txq_put_index] =
> + tx_desc->buf_phys_addr;
> txq_pcpu->txq_put_index++;
> if (txq_pcpu->txq_put_index == txq_pcpu->size)
> txq_pcpu->txq_put_index = 0;
> @@ -4404,11 +4407,13 @@ static void mvpp2_txq_bufs_free(struct mvpp2_port *port,
> dma_addr_t buf_phys_addr =
> txq_pcpu->tx_buffs[txq_pcpu->txq_get_index];
> struct sk_buff *skb = txq_pcpu->tx_skb[txq_pcpu->txq_get_index];
> + size_t data_size =
> + txq_pcpu->tx_data_size[txq_pcpu->txq_get_index];
>
> mvpp2_txq_inc_get(txq_pcpu);
>
> dma_unmap_single(port->dev->dev.parent, buf_phys_addr,
> - skb_headlen(skb), DMA_TO_DEVICE);
> + data_size, DMA_TO_DEVICE);
> if (!skb)
> continue;
> dev_kfree_skb_any(skb);
> @@ -4662,6 +4667,11 @@ static int mvpp2_txq_init(struct mvpp2_port *port,
> if (!txq_pcpu->tx_buffs)
> goto error;
>
> + txq_pcpu->tx_data_size = kmalloc(txq_pcpu->size *
> + sizeof(size_t), GFP_KERNEL);
> + if (!txq_pcpu->tx_data_size)
> + goto error;
> +
> txq_pcpu->count = 0;
> txq_pcpu->reserved_num = 0;
> txq_pcpu->txq_put_index = 0;
> @@ -4675,6 +4685,7 @@ static int mvpp2_txq_init(struct mvpp2_port *port,
> txq_pcpu = per_cpu_ptr(txq->pcpu, cpu);
> kfree(txq_pcpu->tx_skb);
> kfree(txq_pcpu->tx_buffs);
> + kfree(txq_pcpu->tx_data_size);
> }
>
> dma_free_coherent(port->dev->dev.parent,
> @@ -4695,6 +4706,7 @@ static void mvpp2_txq_deinit(struct mvpp2_port *port,
> txq_pcpu = per_cpu_ptr(txq->pcpu, cpu);
> kfree(txq_pcpu->tx_skb);
> kfree(txq_pcpu->tx_buffs);
> + kfree(txq_pcpu->tx_data_size);
> }
>
> if (txq->descs)
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH] ARM: add cmpxchg64 helper for ARMv7-M
From: Russell King - ARM Linux @ 2016-12-13 16:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161210123234.GA5468@salvia>
On Sat, Dec 10, 2016 at 01:32:34PM +0100, Pablo Neira Ayuso wrote:
> Hi Arnd,
>
> On Sat, Dec 10, 2016 at 11:36:34AM +0100, Arnd Bergmann wrote:
> > A change to the netfilter code in net-next introduced the first caller of
> > cmpxchg64 that can get built on ARMv7-M, leading to an error from the
> > assembler that points out the lack of 64-bit atomics on this architecture:
> >
> > /tmp/ccMe7djj.s: Assembler messages:
> > /tmp/ccMe7djj.s:367: Error: selected processor does not support `ldrexd r0,r1,[lr]' in Thumb mode
> > /tmp/ccMe7djj.s:371: Error: selected processor does not support `strexd ip,r2,r3,[lr]' in Thumb mode
> > /tmp/ccMe7djj.s:389: Error: selected processor does not support `ldrexd r8,r9,[r7]' in Thumb mode
> > /tmp/ccMe7djj.s:393: Error: selected processor does not support `strexd lr,r0,r1,[r7]' in Thumb mode
> > scripts/Makefile.build:299: recipe for target 'net/netfilter/nft_counter.o' failed
> >
> > This makes ARMv7-M use the same emulation from asm-generic/cmpxchg-local.h
> > that we use on architectures earlier than ARMv6K, to fix the build. The
> > 32-bit atomics are available on ARMv7-M and we keep using them there.
> > This ARM specific change is probably something we should do regardless
> > of the netfilter code.
> >
> > However, looking at the new nft_counter_reset() function in nft_counter.c,
> > this looks incorrect to me not just on ARMv7-M but also on other
> > architectures, with at least the following possible race:
>
> Right, Eric Dumazet already spotted this problem. I'm preparing a
> patch that doesn't require cmpxchg64(). Will keep you on Cc. Thanks.
Please keep me on the Cc as well so I know what's happening, thanks.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* double free issue, mvpp2 driver, armada375 modules
From: Thomas Petazzoni @ 2016-12-13 16:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57272206.6070703@corp.ovh.com>
Hello,
On Mon, 2 May 2016 11:46:46 +0200, Raphael G wrote:
> enclosed the kernel panic we obtain after boot with a slightly patched
> upstream kernel (4.5.2).
>
> (as well as the patchset applied to the upstream kernel, so that you can
> know which code we are talking about. Too bad we cannot use the upstream
> kernel but we had no choice about this + we're no experts so we rely on
> provided patches, adapted to our bootloader and hardware for this)
>
> Reproduce:
> boot on kernel on an armada375 module, connect to it, launch a top in
> commandline
>
> As seen with Marcin Wojtas, reverting commit
> e864b4c7b184bde36fa6a02bb3190983d2f796f9 fixes this issue.
>
> Reporting upstream so that you can decide what should be done next
Thanks for your report. I have finally submitted a fix for this issue.
You can find it at:
http://lists.infradead.org/pipermail/linux-arm-kernel/2016-December/473989.html
If you have the time to test it and report back, it would be very
useful.
Thanks a lot!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH] net: mvpp2: fix dma unmapping of TX buffers for fragments
From: Thomas Petazzoni @ 2016-12-13 16:53 UTC (permalink / raw)
To: linux-arm-kernel
Since commit 71ce391dfb784 ("net: mvpp2: enable proper per-CPU TX
buffers unmapping"), we are not correctly DMA unmapping TX buffers for
fragments.
Indeed, the mvpp2_txq_inc_put() function only stores in the
txq_cpu->tx_buffs[] array the physical address of the buffer to be
DMA-unmapped when skb != NULL. In addition, when DMA-unmapping, we use
skb_headlen(skb) to get the size to be unmapped. Both of this works fine
for TX descriptors that are associated directly to a SKB, but not the
ones that are used for fragments, with a NULL pointer as skb:
- We have a NULL physical address when calling DMA unmap
- skb_headlen(skb) crashes because skb is NULL
This causes random crashes when fragments are used.
To solve this problem, this commit:
- Stores the physical address of the buffer to be unmapped
unconditionally, regardless of whether it is tied to a SKB or not.
- Adds a txq_cpu->tx_data_size[] array to store the size of the DMA
buffer to be unmapped upon TX completion.
Fixes: 71ce391dfb784 ("net: mvpp2: enable proper per-CPU TX buffers unmapping")
Reported-by: Raphael G <raphael.glon@corp.ovh.com>
Cc: Raphael G <raphael.glon@corp.ovh.com>
Cc: stable at vger.kernel.org
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
drivers/net/ethernet/marvell/mvpp2.c | 20 ++++++++++++++++----
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2.c b/drivers/net/ethernet/marvell/mvpp2.c
index 1026c45..d168b13 100644
--- a/drivers/net/ethernet/marvell/mvpp2.c
+++ b/drivers/net/ethernet/marvell/mvpp2.c
@@ -791,6 +791,8 @@ struct mvpp2_txq_pcpu {
/* Array of transmitted buffers' physical addresses */
dma_addr_t *tx_buffs;
+ size_t *tx_data_size;
+
/* Index of last TX DMA descriptor that was inserted */
int txq_put_index;
@@ -980,9 +982,10 @@ static void mvpp2_txq_inc_put(struct mvpp2_txq_pcpu *txq_pcpu,
struct mvpp2_tx_desc *tx_desc)
{
txq_pcpu->tx_skb[txq_pcpu->txq_put_index] = skb;
- if (skb)
- txq_pcpu->tx_buffs[txq_pcpu->txq_put_index] =
- tx_desc->buf_phys_addr;
+ txq_pcpu->tx_data_size[txq_pcpu->txq_put_index] =
+ tx_desc->data_size;
+ txq_pcpu->tx_buffs[txq_pcpu->txq_put_index] =
+ tx_desc->buf_phys_addr;
txq_pcpu->txq_put_index++;
if (txq_pcpu->txq_put_index == txq_pcpu->size)
txq_pcpu->txq_put_index = 0;
@@ -4404,11 +4407,13 @@ static void mvpp2_txq_bufs_free(struct mvpp2_port *port,
dma_addr_t buf_phys_addr =
txq_pcpu->tx_buffs[txq_pcpu->txq_get_index];
struct sk_buff *skb = txq_pcpu->tx_skb[txq_pcpu->txq_get_index];
+ size_t data_size =
+ txq_pcpu->tx_data_size[txq_pcpu->txq_get_index];
mvpp2_txq_inc_get(txq_pcpu);
dma_unmap_single(port->dev->dev.parent, buf_phys_addr,
- skb_headlen(skb), DMA_TO_DEVICE);
+ data_size, DMA_TO_DEVICE);
if (!skb)
continue;
dev_kfree_skb_any(skb);
@@ -4662,6 +4667,11 @@ static int mvpp2_txq_init(struct mvpp2_port *port,
if (!txq_pcpu->tx_buffs)
goto error;
+ txq_pcpu->tx_data_size = kmalloc(txq_pcpu->size *
+ sizeof(size_t), GFP_KERNEL);
+ if (!txq_pcpu->tx_data_size)
+ goto error;
+
txq_pcpu->count = 0;
txq_pcpu->reserved_num = 0;
txq_pcpu->txq_put_index = 0;
@@ -4675,6 +4685,7 @@ static int mvpp2_txq_init(struct mvpp2_port *port,
txq_pcpu = per_cpu_ptr(txq->pcpu, cpu);
kfree(txq_pcpu->tx_skb);
kfree(txq_pcpu->tx_buffs);
+ kfree(txq_pcpu->tx_data_size);
}
dma_free_coherent(port->dev->dev.parent,
@@ -4695,6 +4706,7 @@ static void mvpp2_txq_deinit(struct mvpp2_port *port,
txq_pcpu = per_cpu_ptr(txq->pcpu, cpu);
kfree(txq_pcpu->tx_skb);
kfree(txq_pcpu->tx_buffs);
+ kfree(txq_pcpu->tx_data_size);
}
if (txq->descs)
--
2.7.4
^ permalink raw reply related
* [PATCH] ARM: dts: Add missing CPU frequencies for Exynos5422/5800
From: Bartlomiej Zolnierkiewicz @ 2016-12-13 16:52 UTC (permalink / raw)
To: linux-arm-kernel
Add missing 2000MHz & 1900MHz OPPs (for A15 cores) and 1400MHz OPP
(for A7 cores). Also update common Odroid-XU3 Lite/XU3/XU4 thermal
cooling maps to account for new OPPs.
Since new OPPs are not available on all Exynos5422/5800 boards modify
dts files for Odroid-XU3 Lite (limited to 1.8 GHz / 1.3 GHz) & Peach
Pi (limited to 2.0 GHz / 1.3 GHz) accordingly.
Tested on Odroid-XU3 and XU3 Lite.
Cc: Doug Anderson <dianders@chromium.org>
Cc: Javier Martinez Canillas <javier@osg.samsung.com>
Cc: Andreas Faerber <afaerber@suse.de>
Cc: Thomas Abraham <thomas.ab@samsung.com>
Cc: Ben Gamari <ben@smart-cactus.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
---
arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 14 +++++++-------
arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts | 17 +++++++++++++++++
arch/arm/boot/dts/exynos5800-peach-pi.dts | 4 ++++
arch/arm/boot/dts/exynos5800.dtsi | 15 +++++++++++++++
4 files changed, 43 insertions(+), 7 deletions(-)
Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
===================================================================
--- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-13 15:59:33.779763261 +0100
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-13 15:59:33.775763261 +0100
@@ -118,7 +118,7 @@
/*
* When reaching cpu_alert3, reduce CPU
* by 2 steps. On Exynos5422/5800 that would
- * be: 1600 MHz and 1100 MHz.
+ * (usually) be: 1800 MHz and 1200 MHz.
*/
map3 {
trip = <&cpu_alert3>;
@@ -131,16 +131,16 @@
/*
* When reaching cpu_alert4, reduce CPU
- * further, down to 600 MHz (11 steps for big,
- * 7 steps for LITTLE).
+ * further, down to 600 MHz (13 steps for big,
+ * 8 steps for LITTLE).
*/
- map5 {
+ cooling_map5: map5 {
trip = <&cpu_alert4>;
- cooling-device = <&cpu0 3 7>;
+ cooling-device = <&cpu0 3 8>;
};
- map6 {
+ cooling_map6: map6 {
trip = <&cpu_alert4>;
- cooling-device = <&cpu4 3 11>;
+ cooling-device = <&cpu4 3 13>;
};
};
};
Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts
===================================================================
--- a/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-13 15:59:33.779763261 +0100
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-13 15:59:33.775763261 +0100
@@ -21,6 +21,23 @@
compatible = "hardkernel,odroid-xu3-lite", "samsung,exynos5800", "samsung,exynos5";
};
+&cluster_a15_opp_table {
+ /delete-node/opp at 2000000000;
+ /delete-node/opp at 1900000000;
+};
+
+&cluster_a7_opp_table {
+ /delete-node/opp at 1400000000;
+};
+
+&cooling_map5 {
+ cooling-device = <&cpu0 3 7>;
+};
+
+&cooling_map6 {
+ cooling-device = <&cpu4 3 11>;
+};
+
&pwm {
/*
* PWM 0 -- fan
Index: b/arch/arm/boot/dts/exynos5800-peach-pi.dts
===================================================================
--- a/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-13 15:59:33.779763261 +0100
+++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-13 15:59:33.779763261 +0100
@@ -146,6 +146,10 @@
vdd-supply = <&ldo9_reg>;
};
+&cluster_a7_opp_table {
+ /delete-property/opp at 1400000000;
+};
+
&cpu0 {
cpu-supply = <&buck2_reg>;
};
Index: b/arch/arm/boot/dts/exynos5800.dtsi
===================================================================
--- a/arch/arm/boot/dts/exynos5800.dtsi 2016-12-13 15:59:33.779763261 +0100
+++ b/arch/arm/boot/dts/exynos5800.dtsi 2016-12-13 15:59:33.779763261 +0100
@@ -24,6 +24,16 @@
};
&cluster_a15_opp_table {
+ opp at 2000000000 {
+ opp-hz = /bits/ 64 <2000000000>;
+ opp-microvolt = <1250000>;
+ clock-latency-ns = <140000>;
+ };
+ opp at 1900000000 {
+ opp-hz = /bits/ 64 <1900000000>;
+ opp-microvolt = <1250000>;
+ clock-latency-ns = <140000>;
+ };
opp at 1700000000 {
opp-microvolt = <1250000>;
};
@@ -85,6 +95,11 @@
};
&cluster_a7_opp_table {
+ opp_a7_14: opp at 1400000000 {
+ opp-hz = /bits/ 64 <1400000000>;
+ opp-microvolt = <1250000>;
+ clock-latency-ns = <140000>;
+ };
opp at 1300000000 {
opp-microvolt = <1250000>;
};
^ permalink raw reply
* [PATCH v2 2/2] mfd: axp20x: Fix AXP806 access errors on cold boot
From: Mark Brown @ 2016-12-13 16:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161209112018.GL3625@dell.home>
On Fri, Dec 09, 2016 at 11:20:18AM +0000, Lee Jones wrote:
> Is the following valid/necessary?
> On Wed, 23 Nov 2016, Chen-Yu Tsai wrote:
> > The AXP806 supports either master/standalone or slave mode.
> > Slave mode allows sharing the serial bus, even with multiple
> > AXP806 which all have the same hardware address.
> > This is done with extra "serial interface address extension",
> > or AXP806_BUS_ADDR_EXT, and "register address extension", or
> > AXP806_REG_ADDR_EXT, registers. The former is read-only, with
> > 1 bit customizable at the factory, and 1 bit depending on the
I don't really know anything about the details of this chip, sorry.
> > This patch sets AXP806_REG_ADDR_EXT to 0x10, which is what we
> > know to be the proper value for a standard AXP806 in slave mode.
> > Afterwards it will reinitialize the regmap cache, to purge any
> > invalid stale values.
If the chip has been reset then you'd want to reset the cache too. I've
no idea if that's needed here or not though, it depends what happens to
the global state of the chip when this reconfiguration happens.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 484 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161213/18150a5a/attachment.sig>
^ permalink raw reply
* [PATCH 3/6] ARM: dts: sun8i: add a cpu0 label to cpu@0 node on A23/33
From: Sudeep Holla @ 2016-12-13 16:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v65=Sh-WMEVk0Db48sgUcV6d7-wF_Yh0yJAHANMkGUzFwQ@mail.gmail.com>
On 13/12/16 16:31, Chen-Yu Tsai wrote:
> On Wed, Dec 14, 2016 at 12:09 AM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>
>>
>> On 13/12/16 15:22, Icenowy Zheng wrote:
>>> A "cpu0" label is needed on cpu at 0 for cpufreq-dt to work.
>>>
>>
>> IIUC any label should be fine and I don't see anything in the driver
>> looking for such label name. All I see is it looks for cpu0 regulator
>> for *legacy* DTs
>>
>>> Add such a label, in order to prepare for cpufreq support of A23/33.
>>>
>>
>> You need this as you add the same label in the following patches. The
>> commit message sounds like cpufreq-dt search for that label by name.
>
> I think a more proper explanation would be:
>
> The cpu's supply regulator is specified at the board level, hence we
> need to add a label to it to reference it without replicating the whole
> tree structure.
Thanks for clarifying, was confused based on the commit log.
--
Regards,
Sudeep
^ permalink raw reply
* [linux-sunxi] sunxi-ng clocks: leaving certain clocks alone?
From: Chen-Yu Tsai @ 2016-12-13 16:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161213150813.uq6megq24nmaircc@lukather>
On Tue, Dec 13, 2016 at 11:08 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> Hi,
>
> On Mon, Dec 12, 2016 at 12:16:07PM +0000, Andre Przywara wrote:
>> Hi Chen-Yu,
>>
>> thanks for the answer!
>>
>> On 12/12/16 04:41, Chen-Yu Tsai wrote:
>> > On Mon, Dec 12, 2016 at 7:54 AM, Andr? Przywara <andre.przywara@arm.com> wrote:
>> >> Hi,
>> >>
>> >> I was observing that the new sunxi-ng clock code apparently explicitly
>> >> turns off _all_ clocks that are not used or needed. I find this rather
>> >> unfortunate, as I wanted to use the THS temperature sensor from ARM
>> >> Trusted Firmware to implement emergency shutdown or DVFS throttling.
>> >> That works until the clock framework finds the clock (as enumerated in
>> >> ccu-sun50i-a64.c) and obviously explicitly clears bit 31 in the THS mod
>> >> clock register and bit 8 in the respective clock gate register.
>> >> Turning them manually back on via /dev/mem or removing the THS clock
>> >> from the sunxi-ng driver fixes this for me.
>> >>
>> >> This was not happening with the old Allwinner clocks, since the kernel
>> >> wouldn't even know about it if there was no driver and the clock wasn't
>> >> mentioned in the DT.
>> >>
>> >> Now with sunxi-ng even though the THS clock is not actually referenced
>> >> or used in the DT, the kernel turns it off. I would expect that upon
>> >> entering the kernel all unneeded clocks are turned off anyway, so there
>> >> is no need to mess with clocks that have no user, but are enumerated in
>> >> the ccu driver.
>> >
>> > I can't say that's absolutely true (wink).
>> >
>> >>
>> >> I wonder if this kills simplefb as well, for instance, since I believe
>> >> that U-Boot needs to turn on certain clocks and relies on them staying up.
>> >
>> > The simplefb bindings takes clocks and regulators expressly for the
>> > purpose of keeping them enabled.
>>
>> Right, I should have checked this before ...
>>
>> >>
>> >> So my questions:
>> >> 1) Is this expected behaviour?
>> >
>> > Yes.
>> >
>> >> 2) If yes, should it really be?
>> >> 3) If yes, shouldn't there be way to explicitly tell Linux to leave that
>> >> clock alone, preferably via DT? Although the sunxi-ng clocks take
>> >> control over the whole CCU unit, I wonder if it should really mess with
>> >> clocks there are not referenced in the DT.
>> >
>> > As it owns the whole CCU unit, why not? And how would it know if some
>> > clock is referenced or not, unless going through the whole device tree?
>>
>> I was hoping that it just provides clocks to any users (drivers) and
>> wouldn't bother with tinkering with every clock unless explicitly being
>> asked for (by a driver being pointed to a specific clock through DT).
>> So it would need to iterate through anything - neither the whole DT nor
>> it's own list of clocks.
>>
>> > Furthermore, nothing prevents another device driver from referencing
>> > said clock and turning it off when it's not in use. Think THS driver
>> > with runtime PM.
>>
>> I am totally OK with that: Any potential Linux THS driver can take over,
>> if the DT references this device and the clock.
>> My point is that atm there is no such driver and so the clocks framework
>> shouldn't turn that clock off.
>
> You could turn that exact argument the other way though. If there's no
> user in the system, why should we waste power and leave it enabled?
>
>> > Are you also mapping the THS to secure only? Otherwise nothing would
>> > prevent Linux from also claiming it.
>>
>> Unfortunately the THS is always unsecure. And even if it could be
>> switched, after a recent IRC discussion I came to believe that those
>> secure peripherals features only works when the secure boot feature is
>> used, which requires to blow an efuse and thus is not easily doable on
>> most boards and also irreversible.
>> Also I am not sure whether this security feature actually extends to the
>> mod clocks and the bus reset and clock gates bits.
>>
>> But I was relying on that Linux doesn't touch hardware that's not
>> referenced in the DT, so if firmware uses the THS, any Linux THS node
>> would need to go - or the other way around: if there is a Linux THS
>> node, firmware backs off.
>
> It's not just about node though, but also based on the kernel
> configuration. If the kernel didn't have a THS driver compiled (or not
> loaded), then if you want to implement such a behaviour, you should
> also keep the THS driver in the firmware.
>
>> >> Maybe there is some way to reference those clocks via some dummy driver
>> >> or DT node to avoid this behaviour? Is there any prior art in this respect?
>> >
>> > If you want a clock to not be disabled by anyone, adding CLK_IS_CRITICAL
>> > to its flags is the proper option. This is done in the clk driver though.
>>
>> Yes, I was thinking about that, but it indeed sounds like a hack to
>> follow this.
>
> You also have the option to add a clock-critical property.
This is not supported by the clk core though. Rather, the clk core just
provides the helper function of_clk_detect_critical() to set the flag.
We don't support it either. Furthermore, the function's comment says:
Do not use this function. It exists only for legacy Device Tree
bindings, such as the one-clock-per-node style that are outdated.
Those bindings typically put all clock data into .dts and the Linux
driver has no clock data, thus making it impossible to set this flag
correctly from the driver. Only those drivers may call
of_clk_detect_critical from their setup functions.
ChenYu
>
> Keep in mind that just preventing it from shutting down at boot gives
> no warranty that the clock will remain enabled. Other clocks in the
> same sub-tree might do a reparenting or a disable that would lead to
> that clock being modified or disabled too as a side effect.
>
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
^ permalink raw reply
* [PATCH 3/6] ARM: dts: sun8i: add a cpu0 label to cpu@0 node on A23/33
From: Chen-Yu Tsai @ 2016-12-13 16:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <139af71f-390a-4023-8f82-71dd80212518@arm.com>
On Wed, Dec 14, 2016 at 12:09 AM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>
>
> On 13/12/16 15:22, Icenowy Zheng wrote:
>> A "cpu0" label is needed on cpu at 0 for cpufreq-dt to work.
>>
>
> IIUC any label should be fine and I don't see anything in the driver
> looking for such label name. All I see is it looks for cpu0 regulator
> for *legacy* DTs
>
>> Add such a label, in order to prepare for cpufreq support of A23/33.
>>
>
> You need this as you add the same label in the following patches. The
> commit message sounds like cpufreq-dt search for that label by name.
I think a more proper explanation would be:
The cpu's supply regulator is specified at the board level, hence we
need to add a label to it to reference it without replicating the whole
tree structure.
ChenYu
^ permalink raw reply
* [PATCH v6 3/8] PWM: add pwm-stm32 DT bindings
From: Benjamin Gaignard @ 2016-12-13 16:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_JsqL8pJSFb8LbABAYJOQ0URaMpyupbFryk_mS2ToN1kStdA@mail.gmail.com>
2016-12-13 16:57 GMT+01:00 Rob Herring <robh@kernel.org>:
> On Tue, Dec 13, 2016 at 5:11 AM, Lee Jones <lee.jones@linaro.org> wrote:
>> On Mon, 12 Dec 2016, Rob Herring wrote:
>>
>>> On Fri, Dec 09, 2016 at 03:15:14PM +0100, Benjamin Gaignard wrote:
>>> > Define bindings for pwm-stm32
>>> >
>>> > version 6:
>>> > - change st,breakinput parameter format to make it usuable on stm32f7 too.
>>> >
>>> > version 2:
>>> > - use parameters instead of compatible of handle the hardware configuration
>>> >
>>> > Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
>>> > ---
>>> > .../devicetree/bindings/pwm/pwm-stm32.txt | 33 ++++++++++++++++++++++
>>> > 1 file changed, 33 insertions(+)
>>> > create mode 100644 Documentation/devicetree/bindings/pwm/pwm-stm32.txt
>>> >
>>> > diff --git a/Documentation/devicetree/bindings/pwm/pwm-stm32.txt b/Documentation/devicetree/bindings/pwm/pwm-stm32.txt
>>> > new file mode 100644
>>> > index 0000000..866f222
>>> > --- /dev/null
>>> > +++ b/Documentation/devicetree/bindings/pwm/pwm-stm32.txt
>>> > @@ -0,0 +1,33 @@
>>> > +STMicroelectronics STM32 Timers PWM bindings
>>> > +
>>> > +Must be a sub-node of an STM32 Timers device tree node.
>>> > +See ../mfd/stm32-timers.txt for details about the parent node.
>>> > +
>>> > +Required parameters:
>>> > +- compatible: Must be "st,stm32-pwm".
>>> > +- pinctrl-names: Set to "default".
>>> > +- pinctrl-0: List of phandles pointing to pin configuration nodes for PWM module.
>>> > + For Pinctrl properties see ../pinctrl/pinctrl-bindings.txt
>>> > +
>>> > +Optional parameters:
>>> > +- st,breakinput: Arrays of three u32 <index level filter> to describe break input configurations.
>>> > + "index" indicates on which break input the configuration should be applied.
>>> > + "level" gives the active level (0=low or 1=high) for this configuration.
>>> > + "filter" gives the filtering value to be applied.
>>> > +
>>> > +Example:
>>> > + timers at 40010000 {
>>>
>>> timer at ...
>>
>> No, it should be timers.
>
> Read the spec. "timer" is a generic node name. "timers" is not. How
> many is not relevant.
"timer" is already used in stm32 DT for clocksource node... It is also why
I use "timers" for this.
>
>> The 's' is intentional, since this parent (MFD) device houses 3
>> different types of timers. The "timer" node is a child of this one.
--
Benjamin Gaignard
Graphic Study Group
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH] tty/serial: atmel_serial: BUG: stop DMA from transmitting in stop_tx
From: Richard Genoud @ 2016-12-13 16:27 UTC (permalink / raw)
To: linux-arm-kernel
If we don't disable the transmitter in atmel_stop_tx, the DMA buffer
continues to send data until it is emptied.
This cause problems with the flow control (CTS is asserted and data are
still sent).
So, disabling the transmitter in atmel_stop_tx is a sane thing to do.
Tested on at91sam9g35-cm(DMA)
Tested for regressions on sama5d2-xplained(Fifo) and at91sam9g20ek(PDC)
Cc: <stable@vger.kernel.org> (beware, this won't apply before 4.3)
Signed-off-by: Richard Genoud <richard.genoud@gmail.com>
---
drivers/tty/serial/atmel_serial.c | 11 +++++++++++
1 file changed, 11 insertions(+)
NB: this is not for the 4.10 merge window, I'm just sending it now to
have some comments if someone is againts it.
diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
index 168b10cad47b..f9d42de5ab2d 100644
--- a/drivers/tty/serial/atmel_serial.c
+++ b/drivers/tty/serial/atmel_serial.c
@@ -481,6 +481,14 @@ static void atmel_stop_tx(struct uart_port *port)
/* disable PDC transmit */
atmel_uart_writel(port, ATMEL_PDC_PTCR, ATMEL_PDC_TXTDIS);
}
+
+ /*
+ * Disable the transmitter.
+ * This is mandatory when DMA is used, otherwise the DMA buffer
+ * is fully transmitted.
+ */
+ atmel_uart_writel(port, ATMEL_US_CR, ATMEL_US_TXDIS);
+
/* Disable interrupts */
atmel_uart_writel(port, ATMEL_US_IDR, atmel_port->tx_done_mask);
@@ -513,6 +521,9 @@ static void atmel_start_tx(struct uart_port *port)
/* Enable interrupts */
atmel_uart_writel(port, ATMEL_US_IER, atmel_port->tx_done_mask);
+
+ /* re-enable the transmitter */
+ atmel_uart_writel(port, ATMEL_US_CR, ATMEL_US_TXEN);
}
/*
^ permalink raw reply related
* [PATCH 3/6] ARM: dts: sun8i: add a cpu0 label to cpu@0 node on A23/33
From: Sudeep Holla @ 2016-12-13 16:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161213152252.53749-4-icenowy@aosc.xyz>
On 13/12/16 15:22, Icenowy Zheng wrote:
> A "cpu0" label is needed on cpu at 0 for cpufreq-dt to work.
>
IIUC any label should be fine and I don't see anything in the driver
looking for such label name. All I see is it looks for cpu0 regulator
for *legacy* DTs
> Add such a label, in order to prepare for cpufreq support of A23/33.
>
You need this as you add the same label in the following patches. The
commit message sounds like cpufreq-dt search for that label by name.
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH v6 3/8] PWM: add pwm-stm32 DT bindings
From: Rob Herring @ 2016-12-13 15:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161213111137.GW3625@dell.home>
On Tue, Dec 13, 2016 at 5:11 AM, Lee Jones <lee.jones@linaro.org> wrote:
> On Mon, 12 Dec 2016, Rob Herring wrote:
>
>> On Fri, Dec 09, 2016 at 03:15:14PM +0100, Benjamin Gaignard wrote:
>> > Define bindings for pwm-stm32
>> >
>> > version 6:
>> > - change st,breakinput parameter format to make it usuable on stm32f7 too.
>> >
>> > version 2:
>> > - use parameters instead of compatible of handle the hardware configuration
>> >
>> > Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
>> > ---
>> > .../devicetree/bindings/pwm/pwm-stm32.txt | 33 ++++++++++++++++++++++
>> > 1 file changed, 33 insertions(+)
>> > create mode 100644 Documentation/devicetree/bindings/pwm/pwm-stm32.txt
>> >
>> > diff --git a/Documentation/devicetree/bindings/pwm/pwm-stm32.txt b/Documentation/devicetree/bindings/pwm/pwm-stm32.txt
>> > new file mode 100644
>> > index 0000000..866f222
>> > --- /dev/null
>> > +++ b/Documentation/devicetree/bindings/pwm/pwm-stm32.txt
>> > @@ -0,0 +1,33 @@
>> > +STMicroelectronics STM32 Timers PWM bindings
>> > +
>> > +Must be a sub-node of an STM32 Timers device tree node.
>> > +See ../mfd/stm32-timers.txt for details about the parent node.
>> > +
>> > +Required parameters:
>> > +- compatible: Must be "st,stm32-pwm".
>> > +- pinctrl-names: Set to "default".
>> > +- pinctrl-0: List of phandles pointing to pin configuration nodes for PWM module.
>> > + For Pinctrl properties see ../pinctrl/pinctrl-bindings.txt
>> > +
>> > +Optional parameters:
>> > +- st,breakinput: Arrays of three u32 <index level filter> to describe break input configurations.
>> > + "index" indicates on which break input the configuration should be applied.
>> > + "level" gives the active level (0=low or 1=high) for this configuration.
>> > + "filter" gives the filtering value to be applied.
>> > +
>> > +Example:
>> > + timers at 40010000 {
>>
>> timer at ...
>
> No, it should be timers.
Read the spec. "timer" is a generic node name. "timers" is not. How
many is not relevant.
> The 's' is intentional, since this parent (MFD) device houses 3
> different types of timers. The "timer" node is a child of this one.
^ permalink raw reply
* [PATCH 3/6] ARM: dts: sun8i: add a cpu0 label to cpu@0 node on A23/33
From: Maxime Ripard @ 2016-12-13 15:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161213152252.53749-4-icenowy@aosc.xyz>
On Tue, Dec 13, 2016 at 11:22:49PM +0800, Icenowy Zheng wrote:
> A "cpu0" label is needed on cpu at 0 for cpufreq-dt to work.
>
> Add such a label, in order to prepare for cpufreq support of A23/33.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
Applied, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161213/41eadf1e/attachment-0001.sig>
^ 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