sunxi: GPIO, AHCI and Cubieboard 2 support.

This is a sun7i (A20) based followup to the sun4i (A10) Cubieboard. It has GMAC using MII mode.

Signed-off-by Ian Campbell <[email protected]>

Acked-by Hans de Goede <[email protected]>

Quoted 5 lines · On Thu, 5 Jun 2014 19:00:14 +0100 Ian Campbell <[email protected]> wrote:

This is a sun7i (A20) based followup to the sun4i (A10) Cubieboard. It has GMAC using MII mode.

Signed-off-by Ian Campbell <[email protected]>

Acked-by Hans de Goede <[email protected]>

This board is using exactly the same PCB as the Cubieboard1. And only the SoC is different (Allwinner A20 instead of the pin-compatible Allwinner A10).

Before piling up more board configurations, we might want to consider supporting both Cubieboard1 and Cubieboard2 with a single u-boot binary (and perhaps keep Cubieboard1 and Cubieboard2 as aliases in boards.cfg). The Allwinner SoCs have support for runtime identification of the SoC type (sun4i/sun5i/sun7i) via the VER_REG (Version Register) located at the address 0x01C00024 as explained in the Allwinner A20 user manual. This requires replacing all the CONFIG_SUN4I/CONFIG_SUN5I/CONFIG_SUN7I ifdefs in the u-boot code with a runtime SoC type checks, but there are not too many places affected (mostly just the DRAM code).

Here is a quick and dirty example (not a patch submission yet), which allows to boot the Cubieboard2 hardware using the existing Cubieboard1 config:

    https://github.com/ssvb/u-boot-sunxi-dram/commit/3153905e0221

If the u-boot code is further extended to define a variable with the relevant dtb file name in the u-boot environment (depending on the runtime detected SoC type and selecting from "sun4i-a10-cubieboard.dtb" and "sun7i-a20-cubieboard2.dtb"), then we can have the same SD card with the whole pre-installed Linux system usable on both Cubieboard1 and Cubieboard2 hardware by just swapping the card.

Also the Cubieboards are not alone. Sharing the same PCB happens for the LIME boards from Olimex too:
https://www.olimex.com/Products/OLinuXino/A10/A10-OLinuXino-LIME
https://www.olimex.com/Products/OLinuXino/A20/A20-OLinuXino-LIME

boards.cfg Active arm armv7 s5pc1xx samsung smdkc100 · line 387

Quoted 3 lines

Active arm armv7 sunxi - sunxi Cubieboard sun4i:CUBIEBOARD,SPL,AXP209_POWER,SUNXI_EMAC Hans de Goede <[email protected]>

boards.cfg +2 -0

+Active  arm         armv7          sunxi       -               sunxi               Cubieboard2                           sun7i:CUBIEBOARD2,SPL,SUNXI_GMAC                                                                                                  Ian Campbell <[email protected]>:Hans de Goede <[email protected]>
+Active  arm         armv7          sunxi       -               sunxi               Cubieboard2_FEL                       sun7i:CUBIEBOARD2,SPL_FEL,SUNXI_GMAC                                                                                              Ian Campbell <[email protected]>:Hans de Goede <[email protected]>

The newly added Cubieboard2 from your patch appears to be missing the important AXP209_POWER option. So the patch is not good enough to be pushed anywhere in its current form.

Quoted 13 lines · Siarhei Siamashka

Quoted 5 lines · On Thu, 5 Jun 2014 19:00:14 +0100 Ian Campbell <[email protected]> wrote:

This is a sun7i (A20) based followup to the sun4i (A10) Cubieboard. It has GMAC using MII mode.

Signed-off-by Ian Campbell <[email protected]>

Acked-by Hans de Goede <[email protected]>

This board is using exactly the same PCB as the Cubieboard1. And only the SoC is different (Allwinner A20 instead of the pin-compatible Allwinner A10).

Quoted 9 lines

Before piling up more board configurations, we might want to consider supporting both Cubieboard1 and Cubieboard2 with a single u-boot binary (and perhaps keep Cubieboard1 and Cubieboard2 as aliases in boards.cfg). The Allwinner SoCs have support for runtime identification of the SoC type (sun4i/sun5i/sun7i) via the VER_REG (Version Register) located at the address 0x01C00024 as explained in the Allwinner A20 user manual. This requires replacing all the CONFIG_SUN4I/CONFIG_SUN5I/CONFIG_SUN7I ifdefs in the u-boot code with a runtime SoC type checks, but there are not too many places affected (mostly just the DRAM code).

A20 will need PSCI for SMP and virtualization support. (I know the related code isn't in there yet.) Won't this be slightly hard to do if you mix them together?

Quoted 25 lines · On Thu, 24 Jul 2014 11:18:15 +0800 Chen-Yu Tsai <[email protected]> wrote:

Quoted 22 lines · Siarhei Siamashka

Quoted 5 lines · On Thu, 5 Jun 2014 19:00:14 +0100 Ian Campbell <[email protected]> wrote:

This is a sun7i (A20) based followup to the sun4i (A10) Cubieboard. It has GMAC using MII mode.

Signed-off-by Ian Campbell <[email protected]>

Acked-by Hans de Goede <[email protected]>

This board is using exactly the same PCB as the Cubieboard1. And only the SoC is different (Allwinner A20 instead of the pin-compatible Allwinner A10).

Before piling up more board configurations, we might want to consider supporting both Cubieboard1 and Cubieboard2 with a single u-boot binary (and perhaps keep Cubieboard1 and Cubieboard2 as aliases in boards.cfg). The Allwinner SoCs have support for runtime identification of the SoC type (sun4i/sun5i/sun7i) via the VER_REG (Version Register) located at the address 0x01C00024 as explained in the Allwinner A20 user manual. This requires replacing all the CONFIG_SUN4I/CONFIG_SUN5I/CONFIG_SUN7I ifdefs in the u-boot code with a runtime SoC type checks, but there are not too many places affected (mostly just the DRAM code).

Quoted 3 lines

A20 will need PSCI for SMP and virtualization support. (I know the related code isn't in there yet.) Won't this be slightly hard to do if you mix them together?

Thanks, that's a good point. Do you expect any special challenges other than just having to handle runtime SoC detection in more places and deal with larger final binaries on the hardware, which does not need PSCI itself?

Quoted 28 lines · Siarhei Siamashka

Quoted 25 lines · On Thu, 24 Jul 2014 11:18:15 +0800 Chen-Yu Tsai <[email protected]> wrote:

Quoted 22 lines · Siarhei Siamashka

Quoted 5 lines · On Thu, 5 Jun 2014 19:00:14 +0100 Ian Campbell <[email protected]> wrote:

This is a sun7i (A20) based followup to the sun4i (A10) Cubieboard. It has GMAC using MII mode.

Signed-off-by Ian Campbell <[email protected]>

Acked-by Hans de Goede <[email protected]>

This board is using exactly the same PCB as the Cubieboard1. And only the SoC is different (Allwinner A20 instead of the pin-compatible Allwinner A10).

Before piling up more board configurations, we might want to consider supporting both Cubieboard1 and Cubieboard2 with a single u-boot binary (and perhaps keep Cubieboard1 and Cubieboard2 as aliases in boards.cfg). The Allwinner SoCs have support for runtime identification of the SoC type (sun4i/sun5i/sun7i) via the VER_REG (Version Register) located at the address 0x01C00024 as explained in the Allwinner A20 user manual. This requires replacing all the CONFIG_SUN4I/CONFIG_SUN5I/CONFIG_SUN7I ifdefs in the u-boot code with a runtime SoC type checks, but there are not too many places affected (mostly just the DRAM code).

Quoted 8 lines

Quoted 3 lines

A20 will need PSCI for SMP and virtualization support. (I know the related code isn't in there yet.) Won't this be slightly hard to do if you mix them together?

Thanks, that's a good point. Do you expect any special challenges other than just having to handle runtime SoC detection in more places and deal with larger final binaries on the hardware, which does not need PSCI itself?

We have similar issues to deal with on most TI SoCs as well. We want to share code as much as possible to avoid duplication, etc. As for run-time sharing, that's where it gets trickier. You're going to have some sort of size constraint on your binary so just how close are you to hitting it today on the smaller of the parts that you would run this on?

In some cases, for the first part of the problem, we may want to do "if (is_sun4i()) { ... }" code that boils down to a compile-time check anyhow.

I expect Simon to possibly chime in here as he's done some work in the past on this concept, for all CONFIG options (but I'm not sold on the idea for use everywhere, just yet anyhow).

Quoted 38 lines · On Thu, 24 Jul 2014 11:00:31 -0400 Tom Rini <[email protected]> wrote:

Quoted 28 lines · Siarhei Siamashka

Quoted 25 lines · On Thu, 24 Jul 2014 11:18:15 +0800 Chen-Yu Tsai <[email protected]> wrote:

Quoted 22 lines · Siarhei Siamashka

Quoted 5 lines · On Thu, 5 Jun 2014 19:00:14 +0100 Ian Campbell <[email protected]> wrote:

This is a sun7i (A20) based followup to the sun4i (A10) Cubieboard. It has GMAC using MII mode.

Signed-off-by Ian Campbell <[email protected]>

Acked-by Hans de Goede <[email protected]>

This board is using exactly the same PCB as the Cubieboard1. And only the SoC is different (Allwinner A20 instead of the pin-compatible Allwinner A10).

Before piling up more board configurations, we might want to consider supporting both Cubieboard1 and Cubieboard2 with a single u-boot binary (and perhaps keep Cubieboard1 and Cubieboard2 as aliases in boards.cfg). The Allwinner SoCs have support for runtime identification of the SoC type (sun4i/sun5i/sun7i) via the VER_REG (Version Register) located at the address 0x01C00024 as explained in the Allwinner A20 user manual. This requires replacing all the CONFIG_SUN4I/CONFIG_SUN5I/CONFIG_SUN7I ifdefs in the u-boot code with a runtime SoC type checks, but there are not too many places affected (mostly just the DRAM code).

Quoted 8 lines

Quoted 3 lines

A20 will need PSCI for SMP and virtualization support. (I know the related code isn't in there yet.) Won't this be slightly hard to do if you mix them together?

Thanks, that's a good point. Do you expect any special challenges other than just having to handle runtime SoC detection in more places and deal with larger final binaries on the hardware, which does not need PSCI itself?

Quoted 5 lines

We have similar issues to deal with on most TI SoCs as well. We want to share code as much as possible to avoid duplication, etc. As for run-time sharing, that's where it gets trickier. You're going to have some sort of size constraint on your binary so just how close are you to hitting it today on the smaller of the parts that you would run this on?

As far as I know, the most SRAM space constrained case on Allwinner hardware used to be the FEL boot mode, where we only had roughly ~15K for the SPL (code, data, stack). This can be improved though:

    http://lists.denx.de/pipermail/u-boot/2014-July/183985.html

But I need to verify the SRAM size constraints again and come up with the detailed numbers. And also have a closer look at how this all interacts with the PSCI support.

Quoted 3 lines

In some cases, for the first part of the problem, we may want to do "if (is_sun4i()) { ... }" code that boils down to a compile-time check anyhow.

Right, if the 'is_sun4i()' is a macro (should it be lower or upper case?), which expands to a compile time constant 0 or 1 in some configurations instead of the runtime checks, then the compiler is normally able to remove the unreachable parts of code and save space. This is a more flexible approach than using ifdefs.

Quoted 5 lines · On Thu, 5 Jun 2014 19:00:14 +0100 Ian Campbell <[email protected]> wrote:

This is a sun7i (A20) based followup to the sun4i (A10) Cubieboard. It has GMAC using MII mode.

Signed-off-by Ian Campbell <[email protected]>

Acked-by Hans de Goede <[email protected]>

This board is using exactly the same PCB as the Cubieboard1. And only the SoC is different (Allwinner A20 instead of the pin-compatible Allwinner A10).

Before piling up more board configurations, we might want to consider supporting both Cubieboard1 and Cubieboard2 with a single u-boot binary (and perhaps keep Cubieboard1 and Cubieboard2 as aliases in boards.cfg). The Allwinner SoCs have support for runtime identification of the SoC type (sun4i/sun5i/sun7i) via the VER_REG (Version Register) located at the address 0x01C00024 as explained in the Allwinner A20 user manual. This requires replacing all the CONFIG_SUN4I/CONFIG_SUN5I/CONFIG_SUN7I ifdefs in the u-boot code with a runtime SoC type checks, but there are not too many places affected (mostly just the DRAM code).

The newly added Cubieboard2 from your patch appears to be missing the important AXP209_POWER option. So the patch is not good enough to be pushed anywhere in its current form.

Quoted 13 lines · Siarhei Siamashka

Quoted 5 lines · On Thu, 5 Jun 2014 19:00:14 +0100 Ian Campbell <[email protected]> wrote:

This is a sun7i (A20) based followup to the sun4i (A10) Cubieboard. It has GMAC using MII mode.

Signed-off-by Ian Campbell <[email protected]>

Acked-by Hans de Goede <[email protected]>

This board is using exactly the same PCB as the Cubieboard1. And only the SoC is different (Allwinner A20 instead of the pin-compatible Allwinner A10).

Quoted 9 lines

Before piling up more board configurations, we might want to consider supporting both Cubieboard1 and Cubieboard2 with a single u-boot binary (and perhaps keep Cubieboard1 and Cubieboard2 as aliases in boards.cfg). The Allwinner SoCs have support for runtime identification of the SoC type (sun4i/sun5i/sun7i) via the VER_REG (Version Register) located at the address 0x01C00024 as explained in the Allwinner A20 user manual. This requires replacing all the CONFIG_SUN4I/CONFIG_SUN5I/CONFIG_SUN7I ifdefs in the u-boot code with a runtime SoC type checks, but there are not too many places affected (mostly just the DRAM code).

This all sounds nice but is very certainly a future piece of work not related to this patch submission.

Quoted 3 lines

The newly added Cubieboard2 from your patch appears to be missing the important AXP209_POWER option. So the patch is not good enough to be pushed anywhere in its current form.

It works for me regardless and always has.

The AXP209 config is trivial to add now that Hans has added the relevant code.

The multi-soc support (within the Allwinner A10/A13/A20 family) is the feature, which is scheduled for this merge window. It is a present piece of work.

Your patch is related in the sense that it is detrimental to this goal.

Quoted 5 lines

Quoted 3 lines

The newly added Cubieboard2 from your patch appears to be missing the important AXP209_POWER option. So the patch is not good enough to be pushed anywhere in its current form.

It works for me regardless and always has.

This simply means that your board is not very sensitive to the use of wrong voltages and may tolerate some abuse. You are just betting on luck.

If you have been tracking the linux-sunxi mailing list, wrong voltages (dcdc3 in particular) have caused some very real reliability problems for some fraction of users. "Works for me" is not the right answer.

Quoted 1 line

The AXP209 config is trivial to add now that Hans has added the relevant code.

Yes. You can fix the problem after the fact, or you can avoid pushing the problematic commit in the first place and do something better.

Quoted 3 lines · Siarhei Siamashka

The multi-soc support (within the Allwinner A10/A13/A20 family) is the feature, which is scheduled for this merge window. It is a present piece of work.

I have never seen any such code, nor am I aware of any such thing being "scheduled" for this merge window (who by?).

As far as I'm concerned this is not a goal for this merge window, if it lands then that would be nice but I think you are either underestimating the work involved or over estimating the size of the merge window.

Quoted 3 lines · Siarhei Siamashka

The multi-soc support (within the Allwinner A10/A13/A20 family) is the feature, which is scheduled for this merge window. It is a present piece of work.

I have never seen any such code, nor am I aware of any such thing being "scheduled" for this merge window (who by?).

As far as I'm concerned this is not a goal for this merge window,

if it lands then that would be nice but I think you are either underestimating the work involved or over estimating the size of the merge window.

Quoted 1 line

Your patch is related in the sense that it is detrimental to this goal.

No it is not. Whoever eventually wants to work on multi SoC support can trivially build on this series.

Quoted 4 lines

Quoted 4 lines

Quoted 3 lines

The newly added Cubieboard2 from your patch appears to be missing the important AXP209_POWER option. So the patch is not good enough to be pushed anywhere in its current form.

Quoted 5 lines

Quoted 1 line

It works for me regardless and always has.

This simply means that your board is not very sensitive to the use of wrong voltages and may tolerate some abuse. You are just betting on luck.

The sunxi github tree had exactly the same lack of power controller config issue and it appears to be fine for plenty of people.

Note that we have not yet merged FAST_MBUS into mainline.

Quoted 5 lines

If you have been tracking the linux-sunxi mailing list, wrong voltages (dcdc3 in particular) have caused some very real reliability problems for some fraction of users. "Works for me" is not the right answer.

Quoted 1 line

The AXP209 config is trivial to add now that Hans has added the relevant code.

And I have already sent a patch to do so.

Quoted 2 lines

Yes. You can fix the problem after the fact, or you can avoid pushing the problematic commit in the first place and do something better.

We are not going to redo all of these patches from scratch as you seem to be asking repeatedly for every trivial issue you have found in your review of this series which I'm afraid is several weeks to late to be useful.

Please base your work on what is currently in u-boot-sunxi#master, that is now the baseline.

Even if we *were* to redo the current stuff as you are asking your work will still have to be based on that.

This patch enables CONFIG_CMD_GPIO for the Allwinner (sunxi) platform as well as providing the common gpio API (gpio_request/free, direction in/out, get/set etc).

Signed-off-by Chen-Yu Tsai <[email protected]>

Signed-off-by Hans de Goede <[email protected]>

Signed-off-by Ma Haijun <[email protected]>

Signed-off-by Oliver Schinagl <[email protected]>

Signed-off-by Ian Campbell <[email protected]>

Cc Henrik Nordstr?m <[email protected]>

Cc Tom Cubie <[email protected]>

---
 arch/arm/include/asm/arch-sunxi/gpio.h |   2 +
 drivers/gpio/Makefile                  |   1 +
 drivers/gpio/sunxi_gpio.c              | 102 +++++++++++++++++++++++++++++++++
 include/configs/sunxi-common.h         |   4 ++
 4 files changed, 109 insertions(+)
 create mode 100644 drivers/gpio/sunxi_gpio.c

arch/arm/include/asm/arch-sunxi/gpio.h +2 -0

index 892479c..f7f3d8c 100644
@@ -143,5 +143,7 @@ int sunxi_gpio_set_cfgpin(u32 pin, u32 val);
 int sunxi_gpio_get_cfgpin(u32 pin);
 int sunxi_gpio_set_drv(u32 pin, u32 val);
 int sunxi_gpio_set_pull(u32 pin, u32 val);
+int sunxi_name_to_gpio(const char *name);
+#define name_to_gpio(name) sunxi_name_to_gpio(name)
 
 #endif /* _SUNXI_GPIO_H */

drivers/gpio/Makefile +1 -0

index 4e001e1..86813b9 100644
@@ -34,3 +34,4 @@ obj-$(CONFIG_XILINX_GPIO)	+= xilinx_gpio.o
 obj-$(CONFIG_ADI_GPIO2)	+= adi_gpio2.o
 obj-$(CONFIG_TCA642X)		+= tca642x.o
 oby-$(CONFIG_SX151X)		+= sx151x.o
+obj-$(CONFIG_SUNXI_GPIO)	+= sunxi_gpio.o

drivers/gpio/sunxi_gpio.c new file +102 -0

new file mode 100644
index 0000000..0c50a8f
@@ -0,0 +1,102 @@
+/*
+ * (C) Copyright 2012 Henrik Nordstrom <[email protected]>
+ *
+ * Based on earlier arch/arm/cpu/armv7/sunxi/gpio.c:
+ *
+ * (C) Copyright 2007-2011
+ * Allwinner Technology Co., Ltd. <www.allwinnertech.com>
+ * Tom Cubie <[email protected]>
+ *
+ * SPDX-License-Identifier:	GPL-2.0+
+ */
+
+#include <common.h>
+#include <asm/io.h>
+#include <asm/gpio.h>
+
+static int sunxi_gpio_output(u32 pin, u32 val)
+{
+	u32 dat;
+	u32 bank = GPIO_BANK(pin);
+	u32 num = GPIO_NUM(pin);
+	struct sunxi_gpio *pio = BANK_TO_GPIO(bank);
+
+	dat = readl(&pio->dat);
+	if (val)
+		dat |= 0x1 << num;
+	else
+		dat &= ~(0x1 << num);
+
+	writel(dat, &pio->dat);
+
+	return 0;
+}
+
+static int sunxi_gpio_input(u32 pin)
+{
+	u32 dat;
+	u32 bank = GPIO_BANK(pin);
+	u32 num = GPIO_NUM(pin);
+	struct sunxi_gpio *pio = BANK_TO_GPIO(bank);
+
+	dat = readl(&pio->dat);
+	dat >>= num;
+
+	return dat & 0x1;
+}
+
+int gpio_request(unsigned gpio, const char *label)
+{
+	return 0;
+}
+
+int gpio_free(unsigned gpio)
+{
+	return 0;
+}
+
+int gpio_direction_input(unsigned gpio)
+{
+	sunxi_gpio_set_cfgpin(gpio, SUNXI_GPIO_INPUT);
+
+	return sunxi_gpio_input(gpio);
+}
+
+int gpio_direction_output(unsigned gpio, int value)
+{
+	sunxi_gpio_set_cfgpin(gpio, SUNXI_GPIO_OUTPUT);
+
+	return sunxi_gpio_output(gpio, value);
+}
+
+int gpio_get_value(unsigned gpio)
+{
+	return sunxi_gpio_input(gpio);
+}
+
+int gpio_set_value(unsigned gpio, int value)
+{
+	return sunxi_gpio_output(gpio, value);
+}
+
+int sunxi_name_to_gpio(const char *name)
+{
+	int group = 0;
+	int groupsize = 9 * 32;
+	long pin;
+	char *eptr;
+	if (*name == 'P' || *name == 'p')
+		name++;
+	if (*name >= 'A') {
+		group = *name - (*name > 'a' ? 'a' : 'A');
+		groupsize = 32;
+		name++;
+	}
+
+	pin = simple_strtol(name, &eptr, 10);
+	if (!*name || *eptr)
+		return -1;
+	if (pin < 0 || pin > groupsize || group >= 9)
+		return -1;
+	return group * 32 + pin;
+}

include/configs/sunxi-common.h +4 -0

index a9d104a..ebb9f7a 100644
@@ -179,6 +179,10 @@
 #define CONFIG_CONS_INDEX              1       /* UART0 */
 #endif
 
+/* GPIO */
+#define CONFIG_SUNXI_GPIO
+#define CONFIG_CMD_GPIO
+
 /* Ethernet support */
 #ifdef CONFIG_SUNXI_EMAC
 #define CONFIG_MII			/* MII PHY management		*/

Signed-off-by Ian Campbell <[email protected]>

---
v2: Split out from "ahci: provide sunxi SATA driver using AHCI platform framework"

---
 arch/arm/cpu/armv7/sunxi/clock_sun4i.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

arch/arm/cpu/armv7/sunxi/clock_sun4i.c +1 -2

index 5a7da3c..b8b16cf 100644
@@ -36,8 +36,7 @@ void clock_init_safe(void)
 	       CPU_CLK_SRC_PLL1 << CPU_CLK_SRC_SHIFT,
 	       &ccm->cpu_ahb_apb0_cfg);
 #ifdef CONFIG_SUN7I
-	writel(0x1 << AHB_GATE_OFFSET_DMA | readl(&ccm->ahb_gate0),
-	       &ccm->ahb_gate0);
+	setbits_le32(&ccm->ahb_gate0, 0x1 << AHB_GATE_OFFSET_DMA);
 #endif
 	writel(PLL6_CFG_DEFAULT, &ccm->pll6_cfg);
 }