* [PATCH] ARM: NOMMU: Use instr_sync instead of plain isb in common code
From: Vladimir Murzin @ 2018-06-18 13:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d32342e7-9ff0-0e26-e9e5-17b6fa2933b5@kernel.org>
Hi Greg,
On 18/06/18 13:42, Greg Ungerer wrote:
> Hi Vladimir,
>
> On 18/06/18 19:48, Vladimir Murzin wrote:
>> Greg reported that commit 3c24121039c9d ("ARM: 8756/1: NOMMU: Postpone
>> MPU activation till __after_proc_init") is causing breakage for the
>> old Versatile platform in no-MMU mode (with out-of-tree patches):
>>
>> ?? AS????? arch/arm/kernel/head-nommu.o
>> arch/arm/kernel/head-nommu.S: Assembler messages:
>> arch/arm/kernel/head-nommu.S:180: Error: selected processor does not support `isb' in ARM mode
>> scripts/Makefile.build:417: recipe for target 'arch/arm/kernel/head-nommu.o' failed
>> make[2]: *** [arch/arm/kernel/head-nommu.o] Error 1
>> Makefile:1034: recipe for target 'arch/arm/kernel' failed
>> make[1]: *** [arch/arm/kernel] Error 2
>>
>> Since the code is common for all NOMMU builds usage of the isb was a
>> bad idea (please, note that isb also used in MPU related code which is
>> fine because MPU has dependency on CPU_V7/CPU_V7M), instead use more
>> robust instr_sync assembler macro.
>>
>> Fixes: 3c24121039c9 ("ARM: 8756/1: NOMMU: Postpone MPU activation till __after_proc_init")
>> Reported-by: Greg Ungerer <gerg@kernel.org>
>> Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
>
> Tested and working for me.
>
> Tested-by: Greg Ungerer <gerg@kernel.org>
Great! It is in Russell's tracker now (patch 8775/1)
Cheers
Vladimir
>
> Thanks
> Greg
>
>
>> ---
>> ? arch/arm/kernel/head-nommu.S | 2 +-
>> ? 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/kernel/head-nommu.S b/arch/arm/kernel/head-nommu.S
>> index dd546d6..7a9b869 100644
>> --- a/arch/arm/kernel/head-nommu.S
>> +++ b/arch/arm/kernel/head-nommu.S
>> @@ -177,7 +177,7 @@ M_CLASS(streq??? r3, [r12, #PMSAv8_MAIR1])
>> ????? bic??? r0, r0, #CR_I
>> ? #endif
>> ????? mcr??? p15, 0, r0, c1, c0, 0??????? @ write control reg
>> -??? isb
>> +??? instr_sync
>> ? #elif defined (CONFIG_CPU_V7M)
>> ? #ifdef CONFIG_ARM_MPU
>> ????? ldreq??? r3, [r12, MPU_CTRL]
>>
>
^ permalink raw reply
* [PATCH 1/3] ARM: dts: imx53: Add 'ARM platform' node
From: Fabio Estevam @ 2018-06-18 13:52 UTC (permalink / raw)
To: linux-arm-kernel
From: Fabio Estevam <fabio.estevam@nxp.com>
As per the i.MX53 Reference Manual add an entry for the
'ARM platform' region in the device tree.
This is needed for accessing the ARM_GPC register to set the
DBGEN bit, so that the debug clocks can be turned on.
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
---
arch/arm/boot/dts/imx53.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/imx53.dtsi b/arch/arm/boot/dts/imx53.dtsi
index 1a7a7bb..a70fbf4 100644
--- a/arch/arm/boot/dts/imx53.dtsi
+++ b/arch/arm/boot/dts/imx53.dtsi
@@ -672,6 +672,11 @@
status = "disabled";
};
+ arm_platform: arm-platform at 63fa0000 {
+ compatible = "fsl,imx53-arm-plat", "fsl,imx51-arm-plat";
+ reg = <0x63fa0000 0x28>;
+ };
+
owire: owire at 63fa4000 {
compatible = "fsl,imx53-owire", "fsl,imx21-owire";
reg = <0x63fa4000 0x4000>;
--
2.7.4
^ permalink raw reply related
* [PATCH 2/3] ARM: dts: imx53: Add a label for the PMU node
From: Fabio Estevam @ 2018-06-18 13:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1529329939-14117-1-git-send-email-festevam@gmail.com>
From: Fabio Estevam <fabio.estevam@nxp.com>
Add a label for the PMU node so that the board dts may be able to
pass the 'secure-reg-access' property like this:
&pmu {
secure-reg-access;
};
This also makes it consistent with the PMU node in imx6qdl.dtsi
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
---
arch/arm/boot/dts/imx53.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx53.dtsi b/arch/arm/boot/dts/imx53.dtsi
index a70fbf4..263bd39f 100644
--- a/arch/arm/boot/dts/imx53.dtsi
+++ b/arch/arm/boot/dts/imx53.dtsi
@@ -113,7 +113,7 @@
};
};
- pmu {
+ pmu: pmu {
compatible = "arm,cortex-a8-pmu";
interrupt-parent = <&tzic>;
interrupts = <77>;
--
2.7.4
^ permalink raw reply related
* [PATCH 3/3] ARM: mx5: Set the DBGEN bit in ARM_GPC register
From: Fabio Estevam @ 2018-06-18 13:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1529329939-14117-1-git-send-email-festevam@gmail.com>
From: Fabio Estevam <fabio.estevam@nxp.com>
On i.MX51/i.MX53 it is necessery to set the DBGEN bit in
ARM_GPC register in order to turn on the debug clocks.
The DBGEN bit of ARM_GPC register has the following description
in the i.MX53 Reference Manual:
"This allows the user to manually activate clocks within the debug
system. This register bit directly controls the platform's dbgen_out
output signal which connects to the DAP_SYS to enable all debug clocks.
Once enabled, the clocks cannot be disabled except by asserting the
disable_trace input of the DAP_SYS."
Based on a previous patch from Sebastian Reichel.
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
---
arch/arm/mach-imx/common.h | 1 +
arch/arm/mach-imx/cpu-imx5.c | 38 ++++++++++++++++++++++++++++++++++++++
arch/arm/mach-imx/mach-imx53.c | 2 ++
3 files changed, 41 insertions(+)
diff --git a/arch/arm/mach-imx/common.h b/arch/arm/mach-imx/common.h
index c8d68e9..db78329 100644
--- a/arch/arm/mach-imx/common.h
+++ b/arch/arm/mach-imx/common.h
@@ -62,6 +62,7 @@ void imx_gpc_set_arm_power_up_timing(u32 sw2iso, u32 sw);
void imx_gpc_set_arm_power_down_timing(u32 sw2iso, u32 sw);
void imx25_pm_init(void);
void imx27_pm_init(void);
+void imx5_pmu_init(void);
enum mxc_cpu_pwr_mode {
WAIT_CLOCKED, /* wfi only */
diff --git a/arch/arm/mach-imx/cpu-imx5.c b/arch/arm/mach-imx/cpu-imx5.c
index 4f2d1c7..6c5a055 100644
--- a/arch/arm/mach-imx/cpu-imx5.c
+++ b/arch/arm/mach-imx/cpu-imx5.c
@@ -117,3 +117,41 @@ int mx53_revision(void)
return mx5_cpu_rev;
}
EXPORT_SYMBOL(mx53_revision);
+
+#define ARM_GPC 0x4
+#define DBGEN BIT(16)
+
+/*
+ * This enables the DBGEN bit in ARM_GPC register, which is
+ * required for accessing some performance counter features.
+ * Technically it is only required while perf is used, but to
+ * keep the source code simple we just enable it all the time
+ * when the kernel configuration allows using the feature.
+ */
+void imx5_pmu_init(void)
+{
+ void __iomem *arm_plat_base;
+ struct device_node *np;
+ u32 gpc;
+
+ if (!IS_ENABLED(CONFIG_ARM_PMU))
+ return;
+
+ np = of_find_compatible_node(NULL, NULL, "arm,cortex-a8-pmu");
+ if (!np)
+ return;
+
+ np = of_find_compatible_node(NULL, NULL, "fsl,imx51-arm-plat");
+ if (!np)
+ return;
+
+ arm_plat_base = of_iomap(np, 0);
+ if (!arm_plat_base) {
+ pr_warn("Unable to map ARM platform registers\n");
+ return;
+ }
+
+ gpc = readl_relaxed(arm_plat_base + ARM_GPC);
+ gpc |= DBGEN;
+ writel_relaxed(gpc, arm_plat_base + ARM_GPC);
+}
diff --git a/arch/arm/mach-imx/mach-imx53.c b/arch/arm/mach-imx/mach-imx53.c
index 07c2e8d..15fba89 100644
--- a/arch/arm/mach-imx/mach-imx53.c
+++ b/arch/arm/mach-imx/mach-imx53.c
@@ -32,6 +32,8 @@ static void __init imx53_dt_init(void)
{
imx_src_init();
+ imx5_pmu_init();
+
imx_aips_allow_unprivileged_access("fsl,imx53-aipstz");
}
--
2.7.4
^ permalink raw reply related
* [PATCH] mtd: nand: raw: atmel: add module param to avoid using dma
From: Miquel Raynal @ 2018-06-18 14:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618103908.17a04679@bbrezillon>
Hi Boris,
On Mon, 18 Jun 2018 10:39:08 +0200, Boris Brezillon
<boris.brezillon@bootlin.com> wrote:
> On Thu, 29 Mar 2018 15:10:54 +0200
> Peter Rosin <peda@axentia.se> wrote:
>
> > On a sama5d31 with a Full-HD dual LVDS panel (132MHz pixel clock) NAND
> > flash accesses have a tendency to cause display disturbances. Add a
> > module param to disable DMA from the NAND controller, since that fixes
> > the display problem for me.
> >
> > Signed-off-by: Peter Rosin <peda@axentia.se>
>
> Reviewed-by: Boris Brezillon <boris.brezillon@bootlin.com>
>
> Miquel, can you queue this one to nand/next.
Yes of course.
I'll just change the subject to "mtd: rawnand: atmel:".
Thanks,
Miqu?l
^ permalink raw reply
* [PATCH] regulator: core: Pass max_uV value to regulator_set_voltage_rdev
From: Maciej Purski @ 2018-06-18 14:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180615112916.GK112168@atomide.com>
If the regulator is not coupled, balance_voltage() should preserve
its desired max uV, instead of setting the exact value like in
coupled regulators case.
Remove debugs, which are not necessary for now.
Signed-off-by: Maciej Purski <m.purski@samsung.com>
---
drivers/regulator/core.c | 26 ++++++++++++++++----------
1 file changed, 16 insertions(+), 10 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 266f4eb..9894f4e 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -2245,7 +2245,6 @@ static int _regulator_enable(struct regulator_dev *rdev)
{
int ret;
- rdev_err(rdev, "%s: %d\n", __func__, __LINE__);
lockdep_assert_held_once(&rdev->mutex);
/* check voltage and requested load before enabling */
@@ -2294,7 +2293,6 @@ int regulator_enable(struct regulator *regulator)
struct regulator_dev *rdev = regulator->rdev;
int ret = 0;
- rdev_err(rdev, "%s: %d\n", __func__, __LINE__);
if (rdev->coupling_desc.n_resolved != rdev->coupling_desc.n_coupled) {
rdev_err(rdev, "not all coupled regulators registered\n");
return -EPERM;
@@ -2319,7 +2317,6 @@ int regulator_enable(struct regulator *regulator)
if (ret != 0 && rdev->supply)
regulator_disable(rdev->supply);
- rdev_err(rdev, "%s: %d\n", __func__, __LINE__);
return ret;
}
EXPORT_SYMBOL_GPL(regulator_enable);
@@ -2418,7 +2415,6 @@ int regulator_disable(struct regulator *regulator)
struct regulator_dev *rdev = regulator->rdev;
int ret = 0;
- rdev_err(rdev, "%s: %d\n", __func__, __LINE__);
if (regulator->always_on)
return 0;
@@ -2431,7 +2427,6 @@ int regulator_disable(struct regulator *regulator)
if (ret == 0 && rdev->supply)
regulator_disable(rdev->supply);
- rdev_err(rdev, "%s: %d\n", __func__, __LINE__);
return ret;
}
EXPORT_SYMBOL_GPL(regulator_disable);
@@ -3112,6 +3107,8 @@ static int regulator_set_voltage_rdev(struct regulator_dev *rdev, int min_uV,
int supply_change_uV = 0;
int ret;
+ rdev_err(rdev, "%s: %d\n", __func__, __LINE__);
+
if (rdev->supply &&
regulator_ops_is_valid(rdev->supply->rdev,
REGULATOR_CHANGE_VOLTAGE) &&
@@ -3175,7 +3172,8 @@ static int regulator_set_voltage_rdev(struct regulator_dev *rdev, int min_uV,
return ret;
}
-static int regulator_get_optimal_voltage(struct regulator_dev *rdev)
+static int
+regulator_get_optimal_voltage(struct regulator_dev *rdev, int *max_uV)
{
struct coupling_desc *c_desc = &rdev->coupling_desc;
struct regulator_dev **c_rdevs = c_desc->coupled_rdevs;
@@ -3200,6 +3198,7 @@ static int regulator_get_optimal_voltage(struct regulator_dev *rdev)
*/
if (n_coupled == 1) {
ret = desired_min_uV;
+ *max_uV = desired_max_uV;
goto out;
}
@@ -3274,6 +3273,7 @@ static int regulator_get_optimal_voltage(struct regulator_dev *rdev)
goto out;
}
ret = possible_uV;
+ *max_uV = ret;
out:
return ret;
@@ -3303,6 +3303,8 @@ static int regulator_balance_voltage(struct regulator_dev *rdev,
* if there isn't any possible change.
*/
while (1) {
+ int max_uV;
+
best_delta = 0;
best_uV = 0;
best_rdev = NULL;
@@ -3318,9 +3320,9 @@ static int regulator_balance_voltage(struct regulator_dev *rdev,
* max_spread constraint in order to balance
* the coupled voltages.
*/
- int optimal_uV, current_uV;
+ int optimal_uV, current_uV;;
- optimal_uV = regulator_get_optimal_voltage(c_rdevs[i]);
+ optimal_uV = regulator_get_optimal_voltage(c_rdevs[i], &max_uV);
if (optimal_uV < 0) {
ret = optimal_uV;
goto out;
@@ -3337,6 +3339,10 @@ static int regulator_balance_voltage(struct regulator_dev *rdev,
best_rdev = c_rdevs[i];
best_uV = optimal_uV;
}
+
+ rdev_err(rdev,
+ "optimal uV: %d current uV: %d, max uV: %d\n",
+ optimal_uV, current_uV, max_uV);
}
/* Nothing to change, return successfully */
@@ -3346,7 +3352,7 @@ static int regulator_balance_voltage(struct regulator_dev *rdev,
}
ret = regulator_set_voltage_rdev(best_rdev, best_uV,
- best_uV, state);
+ max_uV, state);
if (ret < 0)
goto out;
@@ -3378,7 +3384,7 @@ int regulator_set_voltage(struct regulator *regulator, int min_uV, int max_uV)
{
int ret = 0;
- rdev_err(regulator->rdev, "%s: %d\n", __func__, __LINE__);
+ dev_err(regulator->dev, "%s: %d\n", __func__, __LINE__);
regulator_lock_dependent(regulator->rdev);
ret = regulator_set_voltage_unlocked(regulator, min_uV, max_uV,
--
2.7.4
^ permalink raw reply related
* [PATCH v5 0/5] ASoC: add driver for Atmel I2S controller
From: Codrin Ciubotariu @ 2018-06-18 14:12 UTC (permalink / raw)
To: linux-arm-kernel
This is a rework of Cyrille's patches named:
[PATCH v3 0/2] ASoC: add driver for Atmel I2S controller
https://lkml.org/lkml/2015/9/29/454
This is the version 5 of the series, and addresses the received feedback
on the mailing lists.
This series applies on top of clk-next branch of clk/linux.git.
Based on received feedback, I created a mux clock driver to select the I2S
clock source, that also includes proper devicetree bindings and nodes.
Also, I added the I2S nodes in sama5d2's devicetree, with the missing
pin muxing for the second I2S controller.
Alexandre Belloni plans to change the at91 fine grained clock nodes and
he recommended to leave the bindings for this clock driver in the same
(wrong) manner, so he could fix them all at once.
This series of patches adds support to the new Atmel I2S controller
embedded on sama5d2 SoCs.
ChangeLog
v4 -> v5
- removed patches:
[PATCH v4 4/7] ASoC: atmel-i2s: dt-bindings: add DT bindings for I2S controller
[PATCH v4 5/7] ASoC: atmel-i2s: add driver for the new Atmel I2S controller
from this series since they were applied to the asoc tree at:
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
- addressed comments received on the mux clock;
v3 -> v4
- as suggested by Rob Herring:
- added a clock mux driver for I2S's clock control bit;
- more precise description of I2S's devicetree bindings;
- removed SoC and internal detalls from bindings;
- addressed comments from Mark Brown;
- added devicetree nodes and pin muxing for I2S;
v2 -> v3
- fix the coding style, add some more comments and add a section dedicated
to sama5d2 SoCs in the DT binding documentation as suggested by Mark
Brown.
v1 -> v2
- initialize dev->dev before calling dev->caps->mck_init()
Codrin Ciubotariu (3):
dt-bindings: clk: at91: add an I2S mux clock
clk: at91: add I2S clock mux driver
ARM: dts: at91: sama5d2: add I2S clock muxing nodes
Cyrille Pitchen (2):
ARM: dts: at91: sama5d2: add nodes for I2S controllers
ARM: dts: at91: sama5d2 Xplained: add pin muxing for I2S
.../devicetree/bindings/clock/at91-clock.txt | 35 ++++++
arch/arm/boot/dts/at91-sama5d2_xplained.dts | 28 +++++
arch/arm/boot/dts/sama5d2.dtsi | 52 ++++++++
arch/arm/mach-at91/Kconfig | 4 +
drivers/clk/at91/Makefile | 1 +
drivers/clk/at91/clk-i2s-mux.c | 116 ++++++++++++++++++
6 files changed, 236 insertions(+)
create mode 100644 drivers/clk/at91/clk-i2s-mux.c
--
2.17.1
^ permalink raw reply
* [PATCH v5 1/5] dt-bindings: clk: at91: add an I2S mux clock
From: Codrin Ciubotariu @ 2018-06-18 14:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618141239.10892-1-codrin.ciubotariu@microchip.com>
The I2S mux clock can be used to select the I2S input clock. The
available parents are the peripheral and the generated clocks.
Signed-off-by: Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
---
Changes in v5:
- specified clock's parent;
- added a newline before adding the clock's compatible string;
.../devicetree/bindings/clock/at91-clock.txt | 35 +++++++++++++++++++
1 file changed, 35 insertions(+)
diff --git a/Documentation/devicetree/bindings/clock/at91-clock.txt b/Documentation/devicetree/bindings/clock/at91-clock.txt
index 51c259a92d02..d0adbf5ae144 100644
--- a/Documentation/devicetree/bindings/clock/at91-clock.txt
+++ b/Documentation/devicetree/bindings/clock/at91-clock.txt
@@ -91,6 +91,9 @@ Required properties:
at91 audio pll output on AUDIOPLLCLK that feeds the PMC
and can be used by peripheral clock or generic clock
+ "atmel,sama5d2-clk-i2s-mux" (under pmc node):
+ at91 I2S clock source selection
+
Required properties for SCKC node:
- reg : defines the IO memory reserved for the SCKC.
- #size-cells : shall be 0 (reg is used to encode clk id).
@@ -507,3 +510,35 @@ For example:
atmel,clk-output-range = <0 83000000>;
};
};
+
+Required properties for I2S mux clocks:
+- #size-cells : shall be 0 (reg is used to encode I2S bus id).
+- #address-cells : shall be 1 (reg is used to encode I2S bus id).
+- name: device tree node describing a specific mux clock.
+ * #clock-cells : from common clock binding; shall be set to 0.
+ * clocks : shall be the mux clock parent phandles; shall be 2 phandles:
+ peripheral and generated clock; the first phandle shall belong to the
+ peripheral clock and the second one shall belong to the generated
+ clock; "clock-indices" property can be user to specify
+ the correct order.
+ * reg: I2S bus id of the corresponding mux clock.
+ e.g. reg = <0>; for i2s0, reg = <1>; for i2s1
+
+For example:
+ i2s_clkmux {
+ compatible = "atmel,sama5d2-clk-i2s-mux";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ i2s0muxck: i2s0_muxclk {
+ clocks = <&i2s0_clk>, <&i2s0_gclk>;
+ #clock-cells = <0>;
+ reg = <0>;
+ };
+
+ i2s1muxck: i2s1_muxclk {
+ clocks = <&i2s1_clk>, <&i2s1_gclk>;
+ #clock-cells = <0>;
+ reg = <1>;
+ };
+ };
--
2.17.1
^ permalink raw reply related
* [PATCH v5 2/5] clk: at91: add I2S clock mux driver
From: Codrin Ciubotariu @ 2018-06-18 14:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618141239.10892-1-codrin.ciubotariu@microchip.com>
This driver is a simple muxing driver that controls the
I2S's clock input by using syscon/regmap to change the parent.
The available inputs can be peripheral clock and generated clock.
Signed-off-by: Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
---
Changes in v5:
- removed CLK_IGNORE_UNUSED flag;
- fixed typo in patch description;
- fixed letter case in patch description;
- reduced size of 'bus_id' member of struct clk_i2s_mux from 32b to 8b,
and all the other changes that come with it;
- made 'clk_i2s_mux_ops' static;
arch/arm/mach-at91/Kconfig | 4 ++
drivers/clk/at91/Makefile | 1 +
drivers/clk/at91/clk-i2s-mux.c | 116 +++++++++++++++++++++++++++++++++
3 files changed, 121 insertions(+)
create mode 100644 drivers/clk/at91/clk-i2s-mux.c
diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig
index 1254bf9d91b4..903f23c309df 100644
--- a/arch/arm/mach-at91/Kconfig
+++ b/arch/arm/mach-at91/Kconfig
@@ -27,6 +27,7 @@ config SOC_SAMA5D2
select HAVE_AT91_H32MX
select HAVE_AT91_GENERATED_CLK
select HAVE_AT91_AUDIO_PLL
+ select HAVE_AT91_I2S_MUX_CLK
select PINCTRL_AT91PIO4
help
Select this if ou are using one of Microchip's SAMA5D2 family SoC.
@@ -129,6 +130,9 @@ config HAVE_AT91_GENERATED_CLK
config HAVE_AT91_AUDIO_PLL
bool
+config HAVE_AT91_I2S_MUX_CLK
+ bool
+
config SOC_SAM_V4_V5
bool
diff --git a/drivers/clk/at91/Makefile b/drivers/clk/at91/Makefile
index 082596f37c1d..facc169ebb68 100644
--- a/drivers/clk/at91/Makefile
+++ b/drivers/clk/at91/Makefile
@@ -13,3 +13,4 @@ obj-$(CONFIG_HAVE_AT91_USB_CLK) += clk-usb.o
obj-$(CONFIG_HAVE_AT91_SMD) += clk-smd.o
obj-$(CONFIG_HAVE_AT91_H32MX) += clk-h32mx.o
obj-$(CONFIG_HAVE_AT91_GENERATED_CLK) += clk-generated.o
+obj-$(CONFIG_HAVE_AT91_I2S_MUX_CLK) += clk-i2s-mux.o
diff --git a/drivers/clk/at91/clk-i2s-mux.c b/drivers/clk/at91/clk-i2s-mux.c
new file mode 100644
index 000000000000..ab834c4a605b
--- /dev/null
+++ b/drivers/clk/at91/clk-i2s-mux.c
@@ -0,0 +1,116 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2018 Microchip Technology Inc,
+ * Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
+ *
+ *
+ */
+
+#include <linux/clk-provider.h>
+#include <linux/of.h>
+#include <linux/mfd/syscon.h>
+#include <linux/regmap.h>
+#include <linux/slab.h>
+
+#include <soc/at91/atmel-sfr.h>
+
+#define I2S_BUS_NR 2
+
+struct clk_i2s_mux {
+ struct clk_hw hw;
+ struct regmap *regmap;
+ u8 bus_id;
+};
+
+#define to_clk_i2s_mux(hw) container_of(hw, struct clk_i2s_mux, hw)
+
+static u8 clk_i2s_mux_get_parent(struct clk_hw *hw)
+{
+ struct clk_i2s_mux *mux = to_clk_i2s_mux(hw);
+ u32 val;
+
+ regmap_read(mux->regmap, AT91_SFR_I2SCLKSEL, &val);
+
+ return (val & BIT(mux->bus_id)) >> mux->bus_id;
+}
+
+static int clk_i2s_mux_set_parent(struct clk_hw *hw, u8 index)
+{
+ struct clk_i2s_mux *mux = to_clk_i2s_mux(hw);
+
+ return regmap_update_bits(mux->regmap, AT91_SFR_I2SCLKSEL,
+ BIT(mux->bus_id), index << mux->bus_id);
+}
+
+static const struct clk_ops clk_i2s_mux_ops = {
+ .get_parent = clk_i2s_mux_get_parent,
+ .set_parent = clk_i2s_mux_set_parent,
+ .determine_rate = __clk_mux_determine_rate,
+};
+
+static struct clk_hw * __init
+at91_clk_i2s_mux_register(struct regmap *regmap, const char *name,
+ const char * const *parent_names,
+ unsigned int num_parents, u8 bus_id)
+{
+ struct clk_init_data init = {};
+ struct clk_i2s_mux *i2s_ck;
+ int ret;
+
+ i2s_ck = kzalloc(sizeof(*i2s_ck), GFP_KERNEL);
+ if (!i2s_ck)
+ return ERR_PTR(-ENOMEM);
+
+ init.name = name;
+ init.ops = &clk_i2s_mux_ops;
+ init.parent_names = parent_names;
+ init.num_parents = num_parents;
+
+ i2s_ck->hw.init = &init;
+ i2s_ck->bus_id = bus_id;
+ i2s_ck->regmap = regmap;
+
+ ret = clk_hw_register(NULL, &i2s_ck->hw);
+ if (ret) {
+ kfree(i2s_ck);
+ return ERR_PTR(ret);
+ }
+
+ return &i2s_ck->hw;
+}
+
+static void __init of_sama5d2_clk_i2s_mux_setup(struct device_node *np)
+{
+ struct regmap *regmap_sfr;
+ u8 bus_id;
+ const char *parent_names[2];
+ struct device_node *i2s_mux_np;
+ struct clk_hw *hw;
+ int ret;
+
+ regmap_sfr = syscon_regmap_lookup_by_compatible("atmel,sama5d2-sfr");
+ if (IS_ERR(regmap_sfr))
+ return;
+
+ for_each_child_of_node(np, i2s_mux_np) {
+ if (of_property_read_u8(i2s_mux_np, "reg", &bus_id))
+ continue;
+
+ if (bus_id > I2S_BUS_NR)
+ continue;
+
+ ret = of_clk_parent_fill(i2s_mux_np, parent_names, 2);
+ if (ret != 2)
+ continue;
+
+ hw = at91_clk_i2s_mux_register(regmap_sfr, i2s_mux_np->name,
+ parent_names, 2, bus_id);
+ if (IS_ERR(hw))
+ continue;
+
+ of_clk_add_hw_provider(i2s_mux_np, of_clk_hw_simple_get, hw);
+ }
+}
+
+CLK_OF_DECLARE(sama5d2_clk_i2s_mux, "atmel,sama5d2-clk-i2s-mux",
+ of_sama5d2_clk_i2s_mux_setup);
--
2.17.1
^ permalink raw reply related
* [PATCH v5 3/5] ARM: dts: at91: sama5d2: add I2S clock muxing nodes
From: Codrin Ciubotariu @ 2018-06-18 14:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618141239.10892-1-codrin.ciubotariu@microchip.com>
This patch adds two clock muxes for the two I2S
buses present on sama5d2 platforms.
Signed-off-by: Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
---
arch/arm/boot/dts/sama5d2.dtsi | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/sama5d2.dtsi b/arch/arm/boot/dts/sama5d2.dtsi
index 61f68e5c48e9..eeb6afa1cda7 100644
--- a/arch/arm/boot/dts/sama5d2.dtsi
+++ b/arch/arm/boot/dts/sama5d2.dtsi
@@ -992,6 +992,24 @@
atmel,clk-output-range = <0 100000000>;
};
};
+
+ i2s_clkmux {
+ compatible = "atmel,sama5d2-clk-i2s-mux";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ i2s0muxck: i2s0_muxclk {
+ clocks = <&i2s0_clk>, <&i2s0_gclk>;
+ #clock-cells = <0>;
+ reg = <0>;
+ };
+
+ i2s1muxck: i2s1_muxclk {
+ clocks = <&i2s1_clk>, <&i2s1_gclk>;
+ #clock-cells = <0>;
+ reg = <1>;
+ };
+ };
};
qspi0: spi at f0020000 {
--
2.17.1
^ permalink raw reply related
* [PATCH v5 4/5] ARM: dts: at91: sama5d2: add nodes for I2S controllers
From: Codrin Ciubotariu @ 2018-06-18 14:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618141239.10892-1-codrin.ciubotariu@microchip.com>
From: Cyrille Pitchen <cyrille.pitchen@atmel.com>
This patch adds DT nodes for I2S0 and I2S1. It also adds an alias for
each I2S node.
Signed-off-by: Cyrille Pitchen <cyrille.pitchen@atmel.com>
[codrin.ciubotariu at microchip.com: added phandle to new mux clock]
Signed-off-by: Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
---
The bindings for the I2S node are applied to broonie/sound.git .
Changes in v5:
- the previous name was:
[PATCH v4 6/7] ARM: dts: at91: sama5d2: add nodes for I2S controllers
arch/arm/boot/dts/sama5d2.dtsi | 34 ++++++++++++++++++++++++++++++++++
1 file changed, 34 insertions(+)
diff --git a/arch/arm/boot/dts/sama5d2.dtsi b/arch/arm/boot/dts/sama5d2.dtsi
index eeb6afa1cda7..eca73ce40bc5 100644
--- a/arch/arm/boot/dts/sama5d2.dtsi
+++ b/arch/arm/boot/dts/sama5d2.dtsi
@@ -58,6 +58,8 @@
serial1 = &uart3;
tcb0 = &tcb0;
tcb1 = &tcb1;
+ i2s0 = &i2s0;
+ i2s1 = &i2s1;
};
cpus {
@@ -1313,6 +1315,22 @@
clocks = <&clk32k>;
};
+ i2s0: i2s at f8050000 {
+ compatible = "atmel,sama5d2-i2s";
+ reg = <0xf8050000 0x100>;
+ interrupts = <54 IRQ_TYPE_LEVEL_HIGH 7>;
+ dmas = <&dma0
+ (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) |
+ AT91_XDMAC_DT_PERID(31))>,
+ <&dma0
+ (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) |
+ AT91_XDMAC_DT_PERID(32))>;
+ dma-names = "tx", "rx";
+ clocks = <&i2s0_clk>, <&i2s0_gclk>, <&audio_pll_pmc>, <&i2s0muxck>;
+ clock-names = "pclk", "gclk", "aclk", "muxclk";
+ status = "disabled";
+ };
+
can0: can at f8054000 {
compatible = "bosch,m_can";
reg = <0xf8054000 0x4000>, <0x210000 0x4000>;
@@ -1506,6 +1524,22 @@
status = "disabled";
};
+ i2s1: i2s at fc04c000 {
+ compatible = "atmel,sama5d2-i2s";
+ reg = <0xfc04c000 0x100>;
+ interrupts = <55 IRQ_TYPE_LEVEL_HIGH 7>;
+ dmas = <&dma0
+ (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) |
+ AT91_XDMAC_DT_PERID(33))>,
+ <&dma0
+ (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) |
+ AT91_XDMAC_DT_PERID(34))>;
+ dma-names = "tx", "rx";
+ clocks = <&i2s1_clk>, <&i2s1_gclk>, <&audio_pll_pmc>, <&i2s1muxck>;
+ clock-names = "pclk", "gclk", "aclk", "muxclk";
+ status = "disabled";
+ };
+
can1: can at fc050000 {
compatible = "bosch,m_can";
reg = <0xfc050000 0x4000>, <0x210000 0x4000>;
--
2.17.1
^ permalink raw reply related
* [PATCH v5 5/5] ARM: dts: at91: sama5d2 Xplained: add pin muxing for I2S
From: Codrin Ciubotariu @ 2018-06-18 14:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618141239.10892-1-codrin.ciubotariu@microchip.com>
From: Cyrille Pitchen <cyrille.pitchen@atmel.com>
This patch sets the pin muxing for the I2S controllers
Signed-off-by: Cyrille Pitchen <cyrille.pitchen@atmel.com>
[codrin.ciubotariu at microchip.com: added pin muxing for the second
controller]
Signed-off-by: Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
---
Changes in v5:
- Previous name was:
[PATCH v4 7/7] ARM: dts: at91: sama5d2 Xplained: add pin muxing for I2S
arch/arm/boot/dts/at91-sama5d2_xplained.dts | 28 +++++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/arch/arm/boot/dts/at91-sama5d2_xplained.dts b/arch/arm/boot/dts/at91-sama5d2_xplained.dts
index e4bbb7e0f793..03917312dec1 100644
--- a/arch/arm/boot/dts/at91-sama5d2_xplained.dts
+++ b/arch/arm/boot/dts/at91-sama5d2_xplained.dts
@@ -281,6 +281,11 @@
status = "okay";
};
+ i2s0: i2s at f8050000 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2s0_default>;
+ };
+
can0: can at f8054000 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_can0_default>;
@@ -424,6 +429,24 @@
bias-disable;
};
+ pinctrl_i2s0_default: i2s0_default {
+ pinmux = <PIN_PC1__I2SC0_CK>,
+ <PIN_PC2__I2SC0_MCK>,
+ <PIN_PC3__I2SC0_WS>,
+ <PIN_PC4__I2SC0_DI0>,
+ <PIN_PC5__I2SC0_DO0>;
+ bias-disable;
+ };
+
+ pinctrl_i2s1_default: i2s1_default {
+ pinmux = <PIN_PA15__I2SC1_CK>,
+ <PIN_PA14__I2SC1_MCK>,
+ <PIN_PA16__I2SC1_WS>,
+ <PIN_PA17__I2SC1_DI0>,
+ <PIN_PA18__I2SC1_DO0>;
+ bias-disable;
+ };
+
pinctrl_key_gpio_default: key_gpio_default {
pinmux = <PIN_PB9__GPIO>;
bias-pull-up;
@@ -546,6 +569,11 @@
status = "okay";
};
+ i2s1: i2s at fc04c000 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2s1_default>;
+ };
+
can1: can at fc050000 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_can1_default>;
--
2.17.1
^ permalink raw reply related
* [PATCH 0/5] RFC: Mezzanine handling for 96boards
From: Arnd Bergmann @ 2018-06-18 14:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu-gAkfRsEUOc=iyxi6Twvg9cbvWNqNHRS2HzUDZg8xUhg@mail.gmail.com>
On Mon, Jun 18, 2018 at 3:22 PM, Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:
> On 18 June 2018 at 14:21, Arnd Bergmann <arnd@arndb.de> wrote:
>> On Mon, Jun 18, 2018 at 9:45 AM, Linus Walleij <linus.walleij@linaro.org> wrote:
>
> Also, given that we can (and do) already describe topologies involving
> mezzanines by ignoring the connector altogether (which is not entirely
> unreasonable given the fact that we [as Linaro/96boards] dropped the
> ball on this one and did not mandate discoverability for mezzanines).
> So ideally, DTs can be expressed such that older kernels can still use
> those peripherals.
Not sure. Modeling the connector as a device with its own driver does
seem like a significant advantage, which to me weighs more than backward
compatibility with old kernels. We can clearly always describe the devices
behind the connector individually and ignore the connector on old kernels
and we should still allow running DT files that work with the old kernels
on new kernels, but I don't see running new DT files on old kernels as
essential in this case. Many platforms don't actually care about that case
at all today (but some do of course).
Arnd
^ permalink raw reply
* [PATCHv4 0/4] arm/versatile: no-MMU support
From: Greg Ungerer @ 2018-06-18 14:19 UTC (permalink / raw)
To: linux-arm-kernel
This is a rebased resend of the no-MMU patches to support the Versatile
platform. It incorporates changes suggested by Russell (don't use a
multiplatorm arrangement) and rebased onto 4.17.
The following patches support configuring and building the versatile
machine with a no-MMU kernel.
There is only a few minor changes required. It was previously possible
in older kernels to build for versatile with CONFIG_MMU disabled, but
the change to devicetree lost that capability. These changes make it
possible again.
One patch is a fix for address translation (broken in older kernels too),
two are build problems when CONFIG_MMU is disabled, and the last is the
actual configuration changes needed.
The motivation for this is that the versatile machine is well supported
in qemu. And this provides an excellent platform for development and
testing no-MMU support on ARM in general. With these patches applied
it is possible to build and run a kernel with MMU disabled in qemu.
Russell: is this something you would take via your patch tracker?
Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
---
arch/arm/Kconfig | 11 +++++++++++
arch/arm/Kconfig.debug | 3 ++-
arch/arm/include/asm/mach/map.h | 1 +
arch/arm/mach-versatile/Kconfig | 5 +++--
arch/arm/mach-versatile/Makefile.boot | 3 +++
arch/arm/mach-versatile/versatile_dt.c | 4 ++++
6 files changed, 24 insertions(+), 3 deletions(-)
^ permalink raw reply
* [PATCHv4 1/4] ARM: versatile: support no-MMU mode addressing
From: Greg Ungerer @ 2018-06-18 14:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618141905.7789-1-gerg@linux-m68k.org>
Currently for the versatile boards the IO_ADDRESS() macro applies static
virtual address mapping for built-in IO devices. When operating without
the MMU enabled IO devices are accessed at their physical address, no
address translation is required.
For the !CONFIG_MMU case then define the IO_ADDRESS() macro to return the
physical address.
Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
---
arch/arm/mach-versatile/versatile_dt.c | 4 ++++
1 file changed, 4 insertions(+)
v2: no change
v3: rebase on top of linux-4.10
v4: rebase on top of linux-4.17
diff --git a/arch/arm/mach-versatile/versatile_dt.c b/arch/arm/mach-versatile/versatile_dt.c
index 3c8d39c12909..8cfa05a37295 100644
--- a/arch/arm/mach-versatile/versatile_dt.c
+++ b/arch/arm/mach-versatile/versatile_dt.c
@@ -37,7 +37,11 @@
#include <asm/mach/map.h>
/* macro to get at MMIO space when running virtually */
+#ifdef CONFIG_MMU
#define IO_ADDRESS(x) (((x) & 0x0fffffff) + (((x) >> 4) & 0x0f000000) + 0xf0000000)
+#else
+#define IO_ADDRESS(x) (x)
+#endif
#define __io_address(n) ((void __iomem __force *)IO_ADDRESS(n))
/*
--
2.17.1
^ permalink raw reply related
* [PATCHv4 2/4] ARM: versatile: define empty debug_ll_io_init() for no-MMU
From: Greg Ungerer @ 2018-06-18 14:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618141905.7789-1-gerg@linux-m68k.org>
No-MMU configured targets have no definition for debug_ll_io_init().
Not all machines use this and it will only be required if CONFIG_DEBUG_LL
is enabled.
But when compiling for a target that uses it and it is configured for
no-MMU (!CONFIG_MMU), for example the versatile machine, you will get:
CC arch/arm/mach-versatile/versatile_dt.o
arch/arm/mach-versatile/versatile_dt.c: In function ?versatile_map_io?:
arch/arm/mach-versatile/versatile_dt.c:283:2: error: implicit declaration of function ?debug_ll_io_init? [-Werror=implicit-function-declaration]
debug_ll_io_init();
^
Fix by adding a macro for it to the !CONFIG_MMU path in map.h.
Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
Reviewed-by: Vladimir Murzin <vladimir.murzin@arm.com>
---
arch/arm/include/asm/mach/map.h | 1 +
1 file changed, 1 insertion(+)
v2: no change
v3: rebase on top of linux-4.10
v4: rebase in top of linux-4.17
diff --git a/arch/arm/include/asm/mach/map.h b/arch/arm/include/asm/mach/map.h
index 9b7c328fb207..b1fe9c8b5c3e 100644
--- a/arch/arm/include/asm/mach/map.h
+++ b/arch/arm/include/asm/mach/map.h
@@ -62,6 +62,7 @@ extern int ioremap_page(unsigned long virt, unsigned long phys,
#else
#define iotable_init(map,num) do { } while (0)
#define vm_reserve_area_early(a,s,c) do { } while (0)
+#define debug_ll_io_init() do { } while (0)
#endif
#endif
--
2.17.1
^ permalink raw reply related
* [PATCHv4 3/4] ARM: versatile: empty Makefile.boot needed for no-MMU compile
From: Greg Ungerer @ 2018-06-18 14:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618141905.7789-1-gerg@linux-m68k.org>
To compile the arm versatile board with the MMU disabled (!CONFIG_MMU)
a Makefile.boot is required. Without it you get:
SYSMAP System.map
arch/arm/boot/Makefile:15: arch/arm/mach-versatile//Makefile.boot: No such file or directory
make[2]: *** No rule to make target `arch/arm/mach-versatile//Makefile.boot'. Stop.
Create an empty Makefile.boot for the versatile machine. This is a
copy of the other empty machine Makefile.boot files. (A few have this
same commented empty file: stm32, ep93xx, lpc18xx, efm32 and vexpress).
Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
---
arch/arm/mach-versatile/Makefile.boot | 3 +++
1 file changed, 3 insertions(+)
create mode 100644 arch/arm/mach-versatile/Makefile.boot
v2: no change
v3: rebase on top of linux-4.10
v3: rebase on top of linux-4.17
diff --git a/arch/arm/mach-versatile/Makefile.boot b/arch/arm/mach-versatile/Makefile.boot
new file mode 100644
index 000000000000..eacfc3f5c33e
--- /dev/null
+++ b/arch/arm/mach-versatile/Makefile.boot
@@ -0,0 +1,3 @@
+# Empty file waiting for deletion once Makefile.boot isn't needed any more.
+# Patch waits for application at
+# http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=7889/1 .
--
2.17.1
^ permalink raw reply related
* [PATCHv4 4/4] ARM: versatile: support configuring versatile machine for no-MMU
From: Greg Ungerer @ 2018-06-18 14:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618141905.7789-1-gerg@linux-m68k.org>
Allow the arm versatile machine to be configured for no-MMU operation.
Older kernels had the ability to build the versatile machine with the MMU
disabled (!CONFIG_MMU). Recent changes to convert the versatile machine
to device tree lost this ability. (Although older kernels could be built
they did not run due to a bug in the IO_ADDRESS() mapping on this machine).
The motivation for this is that the versatile machine is well supported
in qemu. And this provides an excellent platform for development and
testing no-MMU support on ARM in general.
This patch adds a versatile platform selection in the upper level arm
system type menu - where it appeared in older kernel versions - when
configuring for the no-MMU case. There is no visible change to the way
versatile is selected for the MMU enabled case.
Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
---
arch/arm/Kconfig | 11 +++++++++++
arch/arm/Kconfig.debug | 3 ++-
arch/arm/mach-versatile/Kconfig | 5 +++--
3 files changed, 16 insertions(+), 3 deletions(-)
v2: don't use a multiplatform setup, move versatile choice to top level menu
v3: rebase on top of linux-4.10
v3: rebase on top of linux-4.17
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 54eeb8d00bc6..0608a6a32fac 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -356,6 +356,17 @@ config ARM_SINGLE_ARMV7M
select SPARSE_IRQ
select USE_OF
+config ARM_SINGLE_ARCH_VERSATILE
+ bool "ARM Ltd. Versatile family"
+ depends on !MMU
+ select AUTO_ZRELADDR
+ select CLKSRC_OF
+ select COMMON_CLK
+ select GENERIC_CLOCKEVENTS
+ select GPIOLIB
+ select SPARSE_IRQ
+ select USE_OF
+
config ARCH_EBSA110
bool "EBSA-110"
select ARCH_USES_GETTIMEOFFSET
diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 693f84392f1b..242a0f744c8a 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -1836,7 +1836,8 @@ config DEBUG_UNCOMPRESS
config UNCOMPRESS_INCLUDE
string
default "debug/uncompress.h" if ARCH_MULTIPLATFORM || ARCH_MSM || \
- PLAT_SAMSUNG || ARM_SINGLE_ARMV7M
+ PLAT_SAMSUNG || ARM_SINGLE_ARMV7M || \
+ ARM_SINGLE_ARCH_VERSATILE
default "mach/uncompress.h"
config EARLY_PRINTK
diff --git a/arch/arm/mach-versatile/Kconfig b/arch/arm/mach-versatile/Kconfig
index f5c275434d6c..06ad999d5978 100644
--- a/arch/arm/mach-versatile/Kconfig
+++ b/arch/arm/mach-versatile/Kconfig
@@ -1,7 +1,8 @@
# SPDX-License-Identifier: GPL-2.0
config ARCH_VERSATILE
- bool "ARM Ltd. Versatile family"
- depends on ARCH_MULTI_V5
+ bool "ARM Ltd. Versatile family" if ARCH_MULTI_V5
+ depends on ARCH_MULTI_V5 || ARM_SINGLE_ARCH_VERSATILE
+ default y if ARM_SINGLE_ARCH_VERSATILE
select ARM_AMBA
select ARM_TIMER_SP804
select ARM_VIC
--
2.17.1
^ permalink raw reply related
* [linux-sunxi] [PATCH v2 00/27] Add support for R40 HDMI pipeline
From: Jernej Škrabec @ 2018-06-18 14:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMty3ZB9f_HrbJDjbAEPvf4UhcEhDm8hCaB8yq-yeVkFbtSTTg@mail.gmail.com>
Dne ponedeljek, 18. junij 2018 ob 14:58:02 CEST je Jagan Teki napisal(a):
> On Thu, Jun 14, 2018 at 10:59 PM, Jernej ?krabec
>
> <jernej.skrabec@siol.net> wrote:
> > Dne ?etrtek, 14. junij 2018 ob 19:16:46 CEST je Jagan Teki napisal(a):
> >> On Thu, Jun 14, 2018 at 8:04 PM, Jernej ?krabec <jernej.skrabec@siol.net>
> >
> > wrote:
> >> > Dne ?etrtek, 14. junij 2018 ob 09:12:41 CEST je Jagan Teki napisal(a):
> >> >> On Wed, Jun 13, 2018 at 1:30 AM, Jernej Skrabec
> >> >> <jernej.skrabec@siol.net>
> >> >
> >> > wrote:
> >> >> > This series adds support for R40 HDMI pipeline. It is a bit special
> >> >> > than other already supported pipelines because it has additional
> >> >> > unit
> >> >> > called TCON TOP responsible for relationship configuration between
> >> >> > mixers, TCONs and HDMI. Additionally, it has additional gates for
> >> >> > DSI
> >> >> > and TV TCONs, TV encoder clock settings and pin muxing between LCD
> >> >> > and TV encoders.
> >> >> >
> >> >> > However, it seems that TCON TOP will become a norm, since newer
> >> >> > Allwinner SoCs like H6 also have this unit.
> >> >> >
> >> >> > I tested different possible configurations:
> >> >> > - mixer0 <> TCON-TV0 <> HDMI
> >> >> > - mixer0 <> TCON-TV1 <> HDMI
> >> >> > - mixer1 <> TCON-TV0 <> HDMI
> >> >> > - mixer1 <> TCON-TV1 <> HDMI
> >> >> >
> >> >> > Please review.
> >> >> >
> >> >> > Best regards,
> >> >> > Jernej
> >> >> >
> >> >> > Changes from v1:
> >> >> > - Split DT bindings patch and updated description
> >> >> > - Split HDMI PHY patch
> >> >> > - Move header file from TCON TOP patch to dt bindings patch
> >> >> > - Added Rob reviewed-by tag
> >> >> > - Used clk_hw_register_gate() instead of custom gate registration
> >> >> > code
> >> >> > - Reworked TCON TOP to be part of of-graph. Because of that, a lot
> >> >> > of
> >> >> >
> >> >> > new patches were added.
> >> >> >
> >> >> > - Droped mixer index quirk patch
> >> >> > - Reworked TCON support for TCON TOP
> >> >> > - Updated commit messages
> >> >> >
> >> >> > Jernej Skrabec (27):
> >> >> > clk: sunxi-ng: r40: Add minimal rate for video PLLs
> >> >> > clk: sunxi-ng: r40: Allow setting parent rate to display related
> >> >> >
> >> >> > clocks
> >> >> >
> >> >> > clk: sunxi-ng: r40: Export video PLLs
> >> >> > dt-bindings: display: sunxi-drm: Add TCON TOP description
> >> >> > drm/sun4i: Add TCON TOP driver
> >> >> > drm/sun4i: Fix releasing node when enumerating enpoints
> >> >> > drm/sun4i: Split out code for enumerating endpoints in output port
> >> >> > drm/sun4i: Add support for traversing graph with TCON TOP
> >> >> > drm/sun4i: Don't skip TCONs if they don't have channel 0
> >> >> > dt-bindings: display: sun4i-drm: Add R40 TV TCON description
> >> >> > drm/sun4i: tcon: Add support for tcon-top gate
> >> >> > drm/sun4i: tcon: Generalize engine search algorithm
> >> >> > drm/sun4i: Don't check for LVDS and RGB when TCON has only ch1
> >> >> > drm/sun4i: Don't check for panel or bridge on TV TCONs
> >> >> > drm/sun4i: Add support for R40 TV TCON
> >> >> > dt-bindings: display: sun4i-drm: Add R40 mixer compatibles
> >> >> > drm/sun4i: Add support for R40 mixers
> >> >> > dt-bindings: display: sun4i-drm: Add description of A64 HDMI PHY
> >> >> > drm/sun4i: Enable DW HDMI PHY clock
> >> >> > drm/sun4i: Don't change clock bits in DW HDMI PHY driver
> >> >> > drm/sun4i: DW HDMI PHY: Add support for second PLL
> >> >> > drm/sun4i: Add support for second clock parent to DW HDMI PHY clk
> >> >> >
> >> >> > driver
> >> >> >
> >> >> > drm/sun4i: Add support for A64 HDMI PHY
> >> >> > drm: of: Export drm_crtc_port_mask()
> >> >> > drm/sun4i: DW HDMI: Expand algorithm for possible crtcs
> >> >> > ARM: dts: sun8i: r40: Add HDMI pipeline
> >> >> > ARM: dts: sun8i: r40: Enable HDMI output on BananaPi M2 Ultra
> >> >>
> >> >> Tested whole series on top of linux-next.
> >> >>
> >> >> Tested-by: Jagan Teki <jagan@amarulasolutions.com>
> >> >
> >> > Thanks!
> >>
> >> I've V40 board, which is same as R40. I'm able to detect the HDMI but
> >> seems edid not detecting properly.
> >>
> >> [ 0.983007] sun4i-drm display-engine: bound 1100000.mixer (ops
> >> 0xc074a80c) [ 0.999043] sun4i-drm display-engine: bound 1200000.mixer
> >> (ops 0xc074a80c) [ 1.006229] sun4i-drm display-engine: bound
> >> 1c70000.tcon-top (ops 0xc074e2ac) [ 1.013609] sun4i-drm
> >> display-engine:
> >> bound 1c73000.lcd-controller (ops 0xc0747a28)
> >> [ 1.053988] sun8i-dw-hdmi 1ee0000.hdmi: Detected HDMI TX controller
> >> v1.32a with HDCP (sun8i_dw_hdmi_phy)
> >> [ 1.063913] sun8i-dw-hdmi 1ee0000.hdmi: registered DesignWare HDMI
> >> I2C bus driver
> >> [ 1.071683] sun4i-drm display-engine: bound 1ee0000.hdmi (ops
> >> 0xc074a298) [ 1.078484] [drm] Supports vblank timestamp caching Rev 2
> >> (21.10.2013). [ 1.085098] [drm] No driver support for vblank
> >> timestamp query. [ 1.091055] [drm] Cannot find any crtc or sizes
> >> [ 1.095995] [drm] Initialized sun4i-drm 1.0.0 20150629 for
> >> display-engine on minor 0
> >
> > This seems like DT issue. Can you post somewhere your V40 DTSI (if it is
> > different to R40) and board DTS?
>
> same dtsi shared between r40 and v40, here is board dts support for HDMI[1]
>
> [1] https://paste.ubuntu.com/p/wqVz38BHrM/
This patch looks like exactly the same as mine for BananaPi M2U, so there
should be no issues.
What about VCC-HDMI? Is powered? Can you measure it to check?
Best regards,
Jernej
^ permalink raw reply
* [PATCH] power: vexpress: fix corruption in notifier registration
From: Lorenzo Pieralisi @ 2018-06-18 14:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1529322007-4637-1-git-send-email-sudeep.holla@arm.com>
On Mon, Jun 18, 2018 at 12:40:07PM +0100, Sudeep Holla wrote:
> Vexpress platforms provide two different restart handlers: SYS_REBOOT
> that restart the entire system, while DB_RESET only restarts the
> daughter board containing the CPU. DB_RESET is overridden by SYS_REBOOT
> if it exists.
>
> notifier_chain_register used in register_restart_handler by design
> allows notifier to be registered once only, however vexpress restart
> notifier can get registered twice.
Nit: I would say "notifier_chain_register() relies on notifiers to be
registered only once to work properly"; put it differently, it allows
notifiers to be registered twice (ie it does nothing to prevent it),
that's why we have this issue.
> When this happen it corrupts list of notifiers, as result some
> notifiers can be not called on proper event, traverse on list can be
> cycled forever, and second unregister can access already freed memory.
>
> So far, since this was the only restart handler in the system, no issue
> was observed even if the same notifier was registered twice. However
> commit 6c5c0d48b686 ("watchdog: sp805: add restart handler") added
> support for SP805 restart handlers and since the system under test
> contains two vexpress restart and two SP805 watchdog instances, it was
> observed that during the boot traversing the restart handler list looped
> forever as there's a cycle in that list resulting in boot hang.
>
> This patch fixes the issues by ensuring that the notifier is installed
> only once.
>
> Cc: Sebastian Reichel <sre@kernel.org>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
> drivers/power/reset/vexpress-poweroff.c | 14 +++++++++-----
> 1 file changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/power/reset/vexpress-poweroff.c b/drivers/power/reset/vexpress-poweroff.c
> index 102f95a09460..cdc68eb06a91 100644
> --- a/drivers/power/reset/vexpress-poweroff.c
> +++ b/drivers/power/reset/vexpress-poweroff.c
> @@ -35,6 +35,7 @@ static void vexpress_reset_do(struct device *dev, const char *what)
> }
>
> static struct device *vexpress_power_off_device;
> +static atomic_t vexpress_restart_nb_refcnt = ATOMIC_INIT(0);
>
> static void vexpress_power_off(void)
> {
> @@ -96,13 +97,16 @@ static const struct of_device_id vexpress_reset_of_match[] = {
>
> static int _vexpress_register_restart_handler(struct device *dev)
> {
> - int err;
> + int err = 0;
Nit: I do not not see why you need to initialize err.
> vexpress_restart_device = dev;
It is unclear to me how the !vexpress_restart_device sentinel is
used while registering FUNC_RESET. It is unrelated to this patch
but if the registration below fails for FUNC_REBOOT can we end
up in a situation where vexpress_restart_device is initialized
with no restart handler registered ?
By looking at it I am not a big fan of the vexpress_restart_device
global variable it has been there since we merged this code but
its usage is a bit obscure.
Anyway, thanks for having a look and fixing the issue.
Lorenzo
> - err = register_restart_handler(&vexpress_restart_nb);
> - if (err) {
> - dev_err(dev, "cannot register restart handler (err=%d)\n", err);
> - return err;
> + if (atomic_inc_return(&vexpress_restart_nb_refcnt) == 1) {
> + err = register_restart_handler(&vexpress_restart_nb);
> + if (err) {
> + dev_err(dev, "cannot register restart handler (err=%d)\n", err);
> + atomic_dec(&vexpress_restart_nb_refcnt);
> + return err;
> + }
> }
> device_create_file(dev, &dev_attr_active);
>
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH v4 00/19] Sunxi-Cedrus driver for the Allwinner Video Engine, using media requests
From: Paul Kocialkowski @ 2018-06-18 14:58 UTC (permalink / raw)
To: linux-arm-kernel
This is the fourth iteration of the updated Sunxi-Cedrus driver,
that supports the Video Engine found in most Allwinner SoCs, starting
with the A10. It was tested on the A13, A20 and A33.
The initial version of this driver[0] was originally written and
submitted by Florent Revest using a previous version of the request API
that is necessary to provide coherency between controls and the buffers
they apply to.
The driver was adapted to use the latest version of the media request
API[1], as submitted by Hand Verkuil. Media request API support is a
hard requirement for the Sunxi-Cedrus driver.
The driver itself currently only supports MPEG2 and more codecs will be
added to the driver eventually. The output frames provided by the
Video Engine are in a multi-planar 32x32-tiled YUV format, with a plane
for luminance (Y) and a plane for chrominance (UV). A specific format is
introduced in the V4L2 API to describe it.
This implementation is based on the significant work that was conducted
by various members of the linux-sunxi community for understanding and
documenting the Video Engine's innards.
Remaining tasks:
* verifying that the defined PCT types apply as-is to all MPEG formats;
* cleaning up register descriptions and documenting the fields used;
* testing on more platforms.
Changes since v3:
* updated to version 15 of the media request API;
* got rid of untested MPEG1 support;
* added definitons for picture coding types;
* added documentation about MPEG2 slice header fields;
* added documentation about MPEG2 slice format;
* added documentation about the MB32 NV12 format;
* added MPEG2 slice header validation;
* removed the assigned-clocks property;
* reworked and fixed error paths;
* harmonized debug prints, with v4l2 helpers when applicable;
* checked the series through checkpatch;
* switched to SPDX license headers;
* renamed MPEG2 frame header to slice header for consistency and clarity;
* removed A20 SRAM compatible from the driver's list.
Changes since v2:
* updated to version 13 of the media request API;
* integrated various changes from Maxime Ripard;
* reworked memory reservation to use CMA, dynamic allocation and allow
DMABUF;
* removed reserved memory binding since the CMA pool is the default one
(and allow ENODEV in the driver, for that use case);
* added SRAM controller support for the SRAM region used by the VE;
* updated the device-tree bindings the for SRAM region;
* added per-platform bindings;
* added A13 support;
* renamed VE node name and label;
* fixed Florent's authorship for the MPEG2 headers;
* added a MAINTAINERS entry.
Changes since v1:
* use the latest version of the request API for Hans Verkuil;
* added media controller support and dependency
* renamed v4l2 format to the more explicit V4L2_PIX_FMT_MB32_NV12;
* reworked bindings documentation;
* moved driver to drivers/media/platforms/sunxi/cedrus to pair with
incoming CSI support ;
* added a workqueue and lists to schedule buffer completion, since it
cannot be done in interrupt context;
* split mpeg2 support into a setup and a trigger function to avoid race
condition;
* split video-related ops to a dedicated sunxi_cedrus_video file;
* cleaned up the included headers for each file;
* used device PFN offset instead of subtracting PHYS_BASE;
* used reset_control_reset instead of assert+deassert;
* put the device in reset when removing driver;
* changed dt bindings to use the last 96 Mib of the first 256 MiB of
DRAM;
* made it clear in the mpeg frame header structure that forward and
backward indexes are used as reference frames for motion vectors;
* lots of small cosmetic and consistency changes, including naming
harmonization and headers text rework.
Cheers!
[0]: https://patchwork.kernel.org/patch/9299073/
[1]: https://git.linuxtv.org/hverkuil/media_tree.git/log/?h=reqv15
Maxime Ripard (4):
drivers: soc: sunxi: Add support for the C1 SRAM region
ARM: sun5i: Add support for the C1 SRAM region with the SRAM
controller
ARM: sun7i-a20: Add support for the C1 SRAM region with the SRAM
controller
ARM: sun8i-a33: Add SRAM controller node and C1 SRAM region
Paul Kocialkowski (15):
dt-bindings: sram: sunxi: Add A13, A20 and A33 SRAM controller
bindings
dt-bindings: sram: sunxi: Add A10 binding for the C1 SRAM region
dt-bindings: sram: sunxi: Add A13 binding for the C1 SRAM region
dt-bindings: sram: sunxi: Add A20 binding for the C1 SRAM region
dt-bindings: sram: sunxi: Add A33 binding for the C1 SRAM region
drivers: soc: sunxi: Add dedicated compatibles for the A13 and A33
ARM: dts: sun5i: Use dedicated SRAM controller compatible
ARM: dts: sun7i-a20: Also use dedicated SRAM controller compatible
media: v4l: Add definitions for MPEG2 slice format and header metadata
media: v4l: Add definition for Allwinner's MB32-tiled NV12 format
dt-bindings: media: Document bindings for the Sunxi-Cedrus VPU driver
media: platform: Add Sunxi-Cedrus VPU decoder driver
ARM: dts: sun5i: Add Video Engine and reserved memory nodes
ARM: dts: sun7i-a20: Add Video Engine and reserved memory nodes
ARM: dts: sun8i-a33: Add Video Engine and reserved memory nodes
.../bindings/media/sunxi-cedrus.txt | 53 ++
.../devicetree/bindings/sram/sunxi-sram.txt | 13 +
.../media/uapi/v4l/extended-controls.rst | 73 +++
.../media/uapi/v4l/pixfmt-compressed.rst | 5 +
.../media/uapi/v4l/pixfmt-reserved.rst | 15 +-
MAINTAINERS | 7 +
arch/arm/boot/dts/sun5i.dtsi | 44 +-
arch/arm/boot/dts/sun7i-a20.dtsi | 45 +-
arch/arm/boot/dts/sun8i-a33.dtsi | 51 ++
drivers/media/platform/Kconfig | 2 +
drivers/media/platform/Makefile | 1 +
drivers/media/platform/sunxi/Kconfig | 15 +
drivers/media/platform/sunxi/Makefile | 1 +
drivers/media/platform/sunxi/cedrus/Kconfig | 13 +
drivers/media/platform/sunxi/cedrus/Makefile | 3 +
drivers/media/platform/sunxi/cedrus/cedrus.c | 327 ++++++++++++
drivers/media/platform/sunxi/cedrus/cedrus.h | 117 ++++
.../media/platform/sunxi/cedrus/cedrus_dec.c | 170 ++++++
.../media/platform/sunxi/cedrus/cedrus_dec.h | 27 +
.../media/platform/sunxi/cedrus/cedrus_hw.c | 262 +++++++++
.../media/platform/sunxi/cedrus/cedrus_hw.h | 30 ++
.../platform/sunxi/cedrus/cedrus_mpeg2.c | 146 +++++
.../platform/sunxi/cedrus/cedrus_mpeg2.h | 24 +
.../media/platform/sunxi/cedrus/cedrus_regs.h | 167 ++++++
.../platform/sunxi/cedrus/cedrus_video.c | 502 ++++++++++++++++++
.../platform/sunxi/cedrus/cedrus_video.h | 23 +
drivers/media/v4l2-core/v4l2-ctrls.c | 44 ++
drivers/media/v4l2-core/v4l2-ioctl.c | 2 +
drivers/soc/sunxi/sunxi_sram.c | 12 +
include/uapi/linux/v4l2-controls.h | 30 ++
include/uapi/linux/videodev2.h | 4 +
31 files changed, 2225 insertions(+), 3 deletions(-)
create mode 100644 Documentation/devicetree/bindings/media/sunxi-cedrus.txt
create mode 100644 drivers/media/platform/sunxi/Kconfig
create mode 100644 drivers/media/platform/sunxi/Makefile
create mode 100644 drivers/media/platform/sunxi/cedrus/Kconfig
create mode 100644 drivers/media/platform/sunxi/cedrus/Makefile
create mode 100644 drivers/media/platform/sunxi/cedrus/cedrus.c
create mode 100644 drivers/media/platform/sunxi/cedrus/cedrus.h
create mode 100644 drivers/media/platform/sunxi/cedrus/cedrus_dec.c
create mode 100644 drivers/media/platform/sunxi/cedrus/cedrus_dec.h
create mode 100644 drivers/media/platform/sunxi/cedrus/cedrus_hw.c
create mode 100644 drivers/media/platform/sunxi/cedrus/cedrus_hw.h
create mode 100644 drivers/media/platform/sunxi/cedrus/cedrus_mpeg2.c
create mode 100644 drivers/media/platform/sunxi/cedrus/cedrus_mpeg2.h
create mode 100644 drivers/media/platform/sunxi/cedrus/cedrus_regs.h
create mode 100644 drivers/media/platform/sunxi/cedrus/cedrus_video.c
create mode 100644 drivers/media/platform/sunxi/cedrus/cedrus_video.h
--
2.17.0
^ permalink raw reply
* [PATCH v4 01/19] dt-bindings: sram: sunxi: Add A13, A20 and A33 SRAM controller bindings
From: Paul Kocialkowski @ 2018-06-18 14:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618145843.14631-1-paul.kocialkowski@bootlin.com>
This introduces dedicated bindings for the SRAM controllers found on the
A13, A20 and A33 sunxi platforms.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
diff --git a/Documentation/devicetree/bindings/sram/sunxi-sram.txt b/Documentation/devicetree/bindings/sram/sunxi-sram.txt
index d087f04a4d7f..19cc0b892672 100644
--- a/Documentation/devicetree/bindings/sram/sunxi-sram.txt
+++ b/Documentation/devicetree/bindings/sram/sunxi-sram.txt
@@ -11,6 +11,9 @@ Controller Node
Required properties:
- compatible : should be:
- "allwinner,sun4i-a10-sram-controller"
+ - "allwinner,sun5i-a13-sram-controller"
+ - "allwinner,sun7i-a20-sram-controller"
+ - "allwinner,sun8i-a33-sram-controller"
- "allwinner,sun50i-a64-sram-controller"
- reg : sram controller register offset + length
--
2.17.0
^ permalink raw reply related
* [PATCH v4 02/19] dt-bindings: sram: sunxi: Add A10 binding for the C1 SRAM region
From: Paul Kocialkowski @ 2018-06-18 14:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618145843.14631-1-paul.kocialkowski@bootlin.com>
This introduces a dedicated binding for the C1 SRAM region for the A10
sunxi platform.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
diff --git a/Documentation/devicetree/bindings/sram/sunxi-sram.txt b/Documentation/devicetree/bindings/sram/sunxi-sram.txt
index 19cc0b892672..5af5bafd5572 100644
--- a/Documentation/devicetree/bindings/sram/sunxi-sram.txt
+++ b/Documentation/devicetree/bindings/sram/sunxi-sram.txt
@@ -29,6 +29,7 @@ once again the representation described in the mmio-sram binding.
The valid sections compatible for A10 are:
- allwinner,sun4i-a10-sram-a3-a4
+ - allwinner,sun4i-a10-sram-c1
- allwinner,sun4i-a10-sram-d
The valid sections compatible for A64 are:
--
2.17.0
^ permalink raw reply related
* [PATCH v4 03/19] dt-bindings: sram: sunxi: Add A13 binding for the C1 SRAM region
From: Paul Kocialkowski @ 2018-06-18 14:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618145843.14631-1-paul.kocialkowski@bootlin.com>
This introduces a dedicated binding for the C1 SRAM region for the A13
sunxi platform.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
diff --git a/Documentation/devicetree/bindings/sram/sunxi-sram.txt b/Documentation/devicetree/bindings/sram/sunxi-sram.txt
index 5af5bafd5572..ddc82cbd7f4d 100644
--- a/Documentation/devicetree/bindings/sram/sunxi-sram.txt
+++ b/Documentation/devicetree/bindings/sram/sunxi-sram.txt
@@ -32,6 +32,9 @@ The valid sections compatible for A10 are:
- allwinner,sun4i-a10-sram-c1
- allwinner,sun4i-a10-sram-d
+The valid sections compatible for A13 are:
+ - allwinner,sun5i-a13-sram-c1
+
The valid sections compatible for A64 are:
- allwinner,sun50i-a64-sram-c
--
2.17.0
^ permalink raw reply related
* [PATCH v4 04/19] dt-bindings: sram: sunxi: Add A20 binding for the C1 SRAM region
From: Paul Kocialkowski @ 2018-06-18 14:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618145843.14631-1-paul.kocialkowski@bootlin.com>
This introduces a dedicated binding for the C1 SRAM region for the A20
sunxi platform.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
diff --git a/Documentation/devicetree/bindings/sram/sunxi-sram.txt b/Documentation/devicetree/bindings/sram/sunxi-sram.txt
index ddc82cbd7f4d..221fa7b42c18 100644
--- a/Documentation/devicetree/bindings/sram/sunxi-sram.txt
+++ b/Documentation/devicetree/bindings/sram/sunxi-sram.txt
@@ -35,6 +35,9 @@ The valid sections compatible for A10 are:
The valid sections compatible for A13 are:
- allwinner,sun5i-a13-sram-c1
+The valid sections compatible for A20 are:
+ - allwinner,sun7i-a20-sram-c1
+
The valid sections compatible for A64 are:
- allwinner,sun50i-a64-sram-c
--
2.17.0
^ 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