[PATCH 0/4] Allwinner A64 SRAM C (DE2 SRAM) support

[PATCH 0/4] Allwinner A64 SRAM C (DE2 SRAM) support

[Icenowy Zheng]

The DE2 in Allwinner A64 SoC requires the SRAM C to be claimed to work.

This patchset adds the support of SRAM C in A64 for the sunxi-sram driver.

As the SRAM C controlling bit is a little different with other peripherals'
SRAM controlling bit (inverted), a function value to register value
remapping is added, which is also useful for the SRAM C1 (VE SRAM) on some
SoCs.

Patch 1 is the device tree binding patch.

Patch 2 is a fix for the usage of the DE2 SRAM -- as it's claimed by a
clock driver, and kernel are trying to probe the DE2 clock driver before
probing sunxi-sram driver; this patch fixed probe defering when claiming
SRAM region.

Patch 3 adds the remapping code.

Patch 4 adds necessary codes for A64 SRAM C.

Icenowy Zheng (4):
  dt-bindings: add binding for Allwinner A64 SRAM controller and SRAM C
  drivers: soc: sunxi: fix error processing on base address when
    claiming
  drivers: soc: sunxi: add support for remapping func value to reg value
  drivers: soc: sunxi: add support for A64 and its SRAM C

 .../devicetree/bindings/sram/sunxi-sram.txt        |  9 +++-
 drivers/soc/sunxi/sunxi_sram.c                     | 57 ++++++++++++++++++----
 2 files changed, 55 insertions(+), 11 deletions(-)

-- 
2.13.0

[PATCH 1/4] dt-bindings: add binding for Allwinner A64 SRAM controller and SRAM C

[Icenowy Zheng]

The display engine on Allwinner A64 wants to claim the SRAM C section.

Add a SRAM controller compatible for A64, and a SRAM section compatible
for its SRAM C.

Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
---
 Documentation/devicetree/bindings/sram/sunxi-sram.txt | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/sram/sunxi-sram.txt b/Documentation/devicetree/bindings/sram/sunxi-sram.txt
index 8d5665468fe7..f34b3a553d7c 100644
--- a/Documentation/devicetree/bindings/sram/sunxi-sram.txt
+++ b/Documentation/devicetree/bindings/sram/sunxi-sram.txt
@@ -9,7 +9,9 @@ Controller Node
 ---------------
 
 Required properties:
-- compatible : "allwinner,sun4i-a10-sram-controller"
+- compatible : should be:
+    - "allwinner,sun4i-a10-sram-controller"
+    - "allwinner,sun50i-a64-sram-controller"
 - reg : sram controller register offset + length
 
 SRAM nodes
@@ -22,10 +24,13 @@ Each SRAM will have SRAM sections that are going to be handled by the
 SRAM controller as subnodes. These sections are represented following
 once again the representation described in the mmio-sram binding.
 
-The valid sections compatible are:
+The valid sections compatible for A10 are:
     - allwinner,sun4i-a10-sram-a3-a4
     - allwinner,sun4i-a10-sram-d
 
+The valid sections compatible for A64 are:
+    - allwinner,sun50i-a64-sram-c
+
 Devices using SRAM sections
 ---------------------------
 
-- 
2.13.0

Re: [linux-sunxi] [PATCH 1/4] dt-bindings: add binding for Allwinner A64 SRAM controller and SRAM C

[Chen-Yu Tsai]

On Wed, Aug 9, 2017 at 4:56 PM, Icenowy Zheng <icenowy@aosc.io> wrote:
> The display engine on Allwinner A64 wants to claim the SRAM C section.
>
> Add a SRAM controller compatible for A64, and a SRAM section compatible
> for its SRAM C.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>

Looks good to me. Will wait for device tree maintainers to have a say.

ChenYu

Re: [PATCH 1/4] dt-bindings: add binding for Allwinner A64 SRAM controller and SRAM C

[Rob Herring]

On Wed, Aug 09, 2017 at 04:56:24PM +0800, Icenowy Zheng wrote:
> The display engine on Allwinner A64 wants to claim the SRAM C section.
> 
> Add a SRAM controller compatible for A64, and a SRAM section compatible
> for its SRAM C.
> 
> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
> ---
>  Documentation/devicetree/bindings/sram/sunxi-sram.txt | 9 +++++++--
>  1 file changed, 7 insertions(+), 2 deletions(-)

Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/4] drivers: soc: sunxi: fix error processing on base address when claiming

[Icenowy Zheng]

When claiming SRAM, if the base is set to an error, it means that the
SRAM controller has been probed, but failed to remap the controller
memory zone. If the base is zero, thus the SRAM controller should be not
probed at all, and it should return -EPROBE_DEFER. However, currently we
returned -EPROBE_DEFER in the former situation, and ignored the latter
situation (which will lead to the kernel to panic).

Fix the behavior on abnormal base address processing when claiming.

Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
---
 drivers/soc/sunxi/sunxi_sram.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/soc/sunxi/sunxi_sram.c b/drivers/soc/sunxi/sunxi_sram.c
index 99e354c8f53f..c1ff7fa62cb4 100644
--- a/drivers/soc/sunxi/sunxi_sram.c
+++ b/drivers/soc/sunxi/sunxi_sram.c
@@ -190,6 +190,9 @@ int sunxi_sram_claim(struct device *dev)
 	u32 val, mask;
 
 	if (IS_ERR(base))
+		return PTR_ERR(base);
+
+	if (!base)
 		return -EPROBE_DEFER;
 
 	if (!dev || !dev->of_node)
-- 
2.13.0

Re: [PATCH 2/4] drivers: soc: sunxi: fix error processing on base address when claiming

[Chen-Yu Tsai]

On Wed, Aug 9, 2017 at 4:56 PM, Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org> wrote:
> When claiming SRAM, if the base is set to an error, it means that the
> SRAM controller has been probed, but failed to remap the controller
> memory zone. If the base is zero, thus the SRAM controller should be not
> probed at all, and it should return -EPROBE_DEFER. However, currently we
> returned -EPROBE_DEFER in the former situation, and ignored the latter
> situation (which will lead to the kernel to panic).
>
> Fix the behavior on abnormal base address processing when claiming.
>
> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>

Fixes: 4af34b572a85 ("drivers: soc: sunxi: Introduce SoC driver to map SRAMs") ?

I can add the tag when applying.

ChenYu

Re: [PATCH 2/4] drivers: soc: sunxi: fix error processing on base address when claiming

[Chen-Yu Tsai]

Hi,

On Wed, Aug 9, 2017 at 4:56 PM, Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org> wrote:
> When claiming SRAM, if the base is set to an error, it means that the
> SRAM controller has been probed, but failed to remap the controller
> memory zone. If the base is zero, thus the SRAM controller should be not
> probed at all, and it should return -EPROBE_DEFER. However, currently we
> returned -EPROBE_DEFER in the former situation, and ignored the latter
> situation (which will lead to the kernel to panic).
>
> Fix the behavior on abnormal base address processing when claiming.

Could you describe how you actually ran into this? The failure seems
unlikely for a properly written device tree.

Thanks
ChenYu

Re: [PATCH 2/4] drivers: soc: sunxi: fix error processing on base address when claiming

[Icenowy Zheng]

于 2017年8月18日 GMT+08:00 下午2:21:07, Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org> 写到:
>Hi,
>
>On Wed, Aug 9, 2017 at 4:56 PM, Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org> wrote:
>> When claiming SRAM, if the base is set to an error, it means that the
>> SRAM controller has been probed, but failed to remap the controller
>> memory zone. If the base is zero, thus the SRAM controller should be
>not
>> probed at all, and it should return -EPROBE_DEFER. However, currently
>we
>> returned -EPROBE_DEFER in the former situation, and ignored the
>latter
>> situation (which will lead to the kernel to panic).
>>
>> Fix the behavior on abnormal base address processing when claiming.
>
>Could you describe how you actually ran into this? The failure seems
>unlikely for a properly written device tree.

In fact it's possible, as the probe defering used to be broken.

On the A64 situation, the SRAM is referenced by the DE2 CCU driver, which will be probed very early -- before SRAM is probed, and the problem happens.

>
>Thanks
>ChenYu

-- 
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.

Re: [PATCH 2/4] drivers: soc: sunxi: fix error processing on base address when claiming

[Chen-Yu Tsai]

On Fri, Aug 18, 2017 at 2:23 PM, Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org> wrote:
>
>
> 于 2017年8月18日 GMT+08:00 下午2:21:07, Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org> 写到:
>>Hi,
>>
>>On Wed, Aug 9, 2017 at 4:56 PM, Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org> wrote:
>>> When claiming SRAM, if the base is set to an error, it means that the
>>> SRAM controller has been probed, but failed to remap the controller
>>> memory zone. If the base is zero, thus the SRAM controller should be
>>not
>>> probed at all, and it should return -EPROBE_DEFER. However, currently
>>we
>>> returned -EPROBE_DEFER in the former situation, and ignored the
>>latter
>>> situation (which will lead to the kernel to panic).
>>>
>>> Fix the behavior on abnormal base address processing when claiming.
>>
>>Could you describe how you actually ran into this? The failure seems
>>unlikely for a properly written device tree.
>
> In fact it's possible, as the probe defering used to be broken.
>
> On the A64 situation, the SRAM is referenced by the DE2 CCU driver, which
> will be probed very early -- before SRAM is probed, and the problem happens.

OK. I see it's because the DE block's address if before almost everything
else. I was wondering why we never ran into this before.

Given there are no actual users in the kernel that could trigger this,
I'll queue this for 4.14 instead.

ChenYu

-- 
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.

[PATCH 4/4] drivers: soc: sunxi: add support for A64 and its SRAM C

[Icenowy Zheng]

Allwinner A64's display engine claims the SRAM C section to work.

Add support for the A64 SRAM controller and the SRAM C section of it.

Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
---
 drivers/soc/sunxi/sunxi_sram.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/drivers/soc/sunxi/sunxi_sram.c b/drivers/soc/sunxi/sunxi_sram.c
index edc993480020..882be5ed7e84 100644
--- a/drivers/soc/sunxi/sunxi_sram.c
+++ b/drivers/soc/sunxi/sunxi_sram.c
@@ -69,6 +69,12 @@ static struct sunxi_sram_desc sun4i_a10_sram_d = {
 				  SUNXI_SRAM_MAP(1, 1, "usb-otg")),
 };
 
+static struct sunxi_sram_desc sun50i_a64_sram_c = {
+	.data	= SUNXI_SRAM_DATA("C", 0x4, 24, 1,
+				  SUNXI_SRAM_MAP(0, 1, "cpu"),
+				  SUNXI_SRAM_MAP(1, 0, "de2")),
+};
+
 static const struct of_device_id sunxi_sram_dt_ids[] = {
 	{
 		.compatible	= "allwinner,sun4i-a10-sram-a3-a4",
@@ -78,6 +84,10 @@ static const struct of_device_id sunxi_sram_dt_ids[] = {
 		.compatible	= "allwinner,sun4i-a10-sram-d",
 		.data		= &sun4i_a10_sram_d.data,
 	},
+	{
+		.compatible	= "allwinner,sun50i-a64-sram-c",
+		.data		= &sun50i_a64_sram_c.data,
+	},
 	{}
 };
 
@@ -295,6 +305,7 @@ static int sunxi_sram_probe(struct platform_device *pdev)
 
 static const struct of_device_id sunxi_sram_dt_match[] = {
 	{ .compatible = "allwinner,sun4i-a10-sram-controller" },
+	{ .compatible = "allwinner,sun50i-a64-sram-controller" },
 	{ },
 };
 MODULE_DEVICE_TABLE(of, sunxi_sram_dt_match);
-- 
2.13.0

Re: [linux-sunxi] [PATCH 4/4] drivers: soc: sunxi: add support for A64 and its SRAM C

[Chen-Yu Tsai]

On Wed, Aug 9, 2017 at 4:56 PM, Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org> wrote:
> Allwinner A64's display engine claims the SRAM C section to work.
>
> Add support for the A64 SRAM controller and the SRAM C section of it.
>
> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>

Looks good to me. Will apply all 4 once the dt bindings are acked.

ChenYu
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/4] drivers: soc: sunxi: add support for A64 and its SRAM C

[Chen-Yu Tsai]

On Mon, Aug 14, 2017 at 5:48 PM, Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org> wrote:
> On Wed, Aug 9, 2017 at 4:56 PM, Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org> wrote:
>> Allwinner A64's display engine claims the SRAM C section to work.
>>
>> Add support for the A64 SRAM controller and the SRAM C section of it.
>>
>> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
>
> Looks good to me. Will apply all 4 once the dt bindings are acked.

Applied patch 1, 3, and 4 for 4.14, and patch 2 as a fix for 4.13.

Thanks
ChenYu

[PATCH 3/4] drivers: soc: sunxi: add support for remapping func value to reg value

[Icenowy Zheng]

On some Allwinner SoCs, sometimes the value needed to write into the
register to claim SRAM is not equal to the value specified in the
device tree.

We now defines 0 as "CPU" and 1 as "Device", however, for VE SRAM, the
register needs to be written 0x7FFFFFFF to claim it to VE, and for
Allwinner A64's SRAM C the needed register value to claim it to DE2 is
0, and the value that enables CPU's access to the SRAM is 1.

Add a value remapping in sunxi_sram_func structure, and let the
sunxi_sram_of_parse function set the remapped register value.

Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
---
 drivers/soc/sunxi/sunxi_sram.c | 43 +++++++++++++++++++++++++++++++++---------
 1 file changed, 34 insertions(+), 9 deletions(-)

diff --git a/drivers/soc/sunxi/sunxi_sram.c b/drivers/soc/sunxi/sunxi_sram.c
index c1ff7fa62cb4..edc993480020 100644
--- a/drivers/soc/sunxi/sunxi_sram.c
+++ b/drivers/soc/sunxi/sunxi_sram.c
@@ -23,6 +23,7 @@
 struct sunxi_sram_func {
 	char	*func;
 	u8	val;
+	u32	reg_val;
 };
 
 struct sunxi_sram_data {
@@ -39,10 +40,11 @@ struct sunxi_sram_desc {
 	bool			claimed;
 };
 
-#define SUNXI_SRAM_MAP(_val, _func)				\
+#define SUNXI_SRAM_MAP(_reg_val, _val, _func)			\
 	{							\
 		.func = _func,					\
 		.val = _val,					\
+		.reg_val = _reg_val,				\
 	}
 
 #define SUNXI_SRAM_DATA(_name, _reg, _off, _width, ...)		\
@@ -57,14 +59,14 @@ struct sunxi_sram_desc {
 
 static struct sunxi_sram_desc sun4i_a10_sram_a3_a4 = {
 	.data	= SUNXI_SRAM_DATA("A3-A4", 0x4, 0x4, 2,
-				  SUNXI_SRAM_MAP(0, "cpu"),
-				  SUNXI_SRAM_MAP(1, "emac")),
+				  SUNXI_SRAM_MAP(0, 0, "cpu"),
+				  SUNXI_SRAM_MAP(1, 1, "emac")),
 };
 
 static struct sunxi_sram_desc sun4i_a10_sram_d = {
 	.data	= SUNXI_SRAM_DATA("D", 0x4, 0x0, 1,
-				  SUNXI_SRAM_MAP(0, "cpu"),
-				  SUNXI_SRAM_MAP(1, "usb-otg")),
+				  SUNXI_SRAM_MAP(0, 0, "cpu"),
+				  SUNXI_SRAM_MAP(1, 1, "usb-otg")),
 };
 
 static const struct of_device_id sunxi_sram_dt_ids[] = {
@@ -121,7 +123,8 @@ static int sunxi_sram_show(struct seq_file *s, void *data)
 
 			for (func = sram_data->func; func->func; func++) {
 				seq_printf(s, "\t\t%s%c\n", func->func,
-					   func->val == val ? '*' : ' ');
+					   func->reg_val == val ?
+					   '*' : ' ');
 			}
 		}
 
@@ -149,10 +152,13 @@ static inline struct sunxi_sram_desc *to_sram_desc(const struct sunxi_sram_data
 }
 
 static const struct sunxi_sram_data *sunxi_sram_of_parse(struct device_node *node,
-							 unsigned int *value)
+							 unsigned int *reg_value)
 {
 	const struct of_device_id *match;
+	const struct sunxi_sram_data *data;
+	struct sunxi_sram_func *func;
 	struct of_phandle_args args;
+	u8 val;
 	int ret;
 
 	ret = of_parse_phandle_with_fixed_args(node, "allwinner,sram", 1, 0,
@@ -165,8 +171,7 @@ static const struct sunxi_sram_data *sunxi_sram_of_parse(struct device_node *nod
 		goto err;
 	}
 
-	if (value)
-		*value = args.args[0];
+	val = args.args[0];
 
 	match = of_match_node(sunxi_sram_dt_ids, args.np);
 	if (!match) {
@@ -174,6 +179,26 @@ static const struct sunxi_sram_data *sunxi_sram_of_parse(struct device_node *nod
 		goto err;
 	}
 
+	data = match->data;
+	if (!data) {
+		ret = -EINVAL;
+		goto err;
+	};
+
+	for (func = data->func; func->func; func++) {
+		if (val == func->val) {
+			if (reg_value)
+				*reg_value = func->reg_val;
+
+			break;
+		}
+	}
+
+	if (!func->func) {
+		ret = -EINVAL;
+		goto err;
+	}
+
 	of_node_put(args.np);
 	return match->data;
 
-- 
2.13.0

Re: [linux-sunxi] [PATCH 3/4] drivers: soc: sunxi: add support for remapping func value to reg value

[Chen-Yu Tsai]

On Wed, Aug 9, 2017 at 4:56 PM, Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org> wrote:
> On some Allwinner SoCs, sometimes the value needed to write into the
> register to claim SRAM is not equal to the value specified in the
> device tree.
>
> We now defines 0 as "CPU" and 1 as "Device", however, for VE SRAM, the
> register needs to be written 0x7FFFFFFF to claim it to VE, and for
> Allwinner A64's SRAM C the needed register value to claim it to DE2 is
> 0, and the value that enables CPU's access to the SRAM is 1.

The device tree binding defines 0 as "mapped to CPU" and 1 as "mapped
to X device". This matches the value written to the configuration
register for the SRAM blocks currently supported. However, the not yet
supported VE SRAM block is claimed for the device by writing 0x7fffffff,
which is vastly different from the other blocks. On the A64, SRAM C is
claimed by the device by writing a 0, which is the opposite of the current
design.

>
> Add a value remapping in sunxi_sram_func structure, and let the
> sunxi_sram_of_parse function set the remapped register value.

Add:

This allows us to keep the convention currently used in the device tree
binding.

> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>

Some amendments to the commit message above. Code looks good.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html