sunxi: initial upstreamining effort

This has been stripped back for mainlining and supports only sun7i. These changes are not useful by themselves but are split out to make the patch sizes more manageable.

arch/arm/cpu/armv7/sunxi/clock.c new file +8 -0

+	/* open the clock for uart */
+	sr32(&ccm->apb1_gate, 16 + CONFIG_CONS_INDEX - 1, 1, CLK_GATE_OPEN);
+
+	return 0;
+}
+
+/* Return PLL5 frequency in Hz
+ * Note: Assumes PLL5 reference is 24MHz clock

+#define RDIV(a, b) ((a + (b) - 1) / (b))

arch/arm/cpu/armv7/sunxi/clock.c new file +10 -0

+	/* Map divisors to register values */
+	axi = axi - 1;
+	if (ahb > 4)
+		ahb = 3;
+	else if (ahb > 2)
+		ahb = 2;
+	else if (ahb > 1)
+		ahb = 1;
+	else
+		ahb = 0;

arch/arm/cpu/armv7/sunxi/timer.c new file +4 -0

+static struct sunxi_timer *timer_base =
+	&((struct sunxi_timer_reg *)SUNXI_TIMER_BASE)->timer[TIMER_NUM];
+
+/* macro to read the 32 bit timer: since it decrements, we invert read

value */ +#define READ_TIMER() (~readl(&timer_base->val))

Quoted 3 lines · Ian Campbell

This has been stripped back for mainlining and supports only sun7i. These changes are not useful by themselves but are split out to make the patch sizes more manageable.

[...]

arch/arm/cpu/armv7/sunxi/clock.c line 57

Quoted 13 lines

arch/arm/cpu/armv7/sunxi/clock.c new file +13 -0

+int clock_init(void)
+{
+	struct sunxi_ccm_reg *const ccm =
+		(struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
+
+#ifdef CONFIG_SPL_BUILD
+	clock_init_safe();
+#endif
+
+	/* uart clock source is apb1 */
+	sr32(&ccm->apb1_clk_div_cfg, 24, 2, APB1_CLK_SRC_OSC24M);
+	sr32(&ccm->apb1_clk_div_cfg, 16, 2, APB1_FACTOR_N);
+	sr32(&ccm->apb1_clk_div_cfg, 0, 5, APB1_FACTOR_M);

sr32() is not defined anywhere.

Quoted 13 lines

arch/arm/cpu/armv7/sunxi/clock.c new file +12 -0

+	/* open the clock for uart */
+	sr32(&ccm->apb1_gate, 16 + CONFIG_CONS_INDEX - 1, 1, CLK_GATE_OPEN);
+
+	return 0;
+}
+
+/* Return PLL5 frequency in Hz
+ * Note: Assumes PLL5 reference is 24MHz clock
+ */
+unsigned int clock_get_pll5(void)
+{
+	struct sunxi_ccm_reg *const ccm =

arch/arm/cpu/armv7/sunxi/clock.c line 76

Quoted 6 lines

arch/arm/cpu/armv7/sunxi/clock.c new file +6 -0

+		(struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
+	uint32_t rval = readl(&ccm->pll5_cfg);
+	int n = (rval >> 8) & 0x1f;
+	int k = ((rval >> 4) & 3) + 1;
+	int p = 1 << ((rval >> 16) & 3);
+	return 24000000 * n * k / p;

Please fix the magic values here.
[...]

Review

Quoted 3 lines

(quoted diff) +2 -0

+#ifdef CONFIG_SPL_BUILD
+#define PLL1_CFG(N, K, M, P)	(1 << 31 | 0 << 30 | 8 << 26 | 0 << 25 |

\

arch/arm/cpu/armv7/sunxi/clock.c line 96

Quoted 2 lines

arch/arm/cpu/armv7/sunxi/clock.c new file +2 -0

+				 16 << 20 | (P) << 16 | 2 << 13 | (N) << 8 | \
+				 (K) << 4 | 0 << 3 | 0 << 2 | (M) << 0)

Here is well.

Quoted 2 lines

+#define RDIV(a, b) ((a + (b) - 1) / (b))

This is some kind of DIV_ROUND_UP() from include/common.h ?

[...]

Quoted 14 lines

arch/arm/cpu/armv7/sunxi/clock.c new file +13 -0

+	/* Map divisors to register values */
+	axi = axi - 1;
+	if (ahb > 4)
+		ahb = 3;
+	else if (ahb > 2)
+		ahb = 2;
+	else if (ahb > 1)
+		ahb = 1;
+	else
+		ahb = 0;
+
+	apb0 = apb0 - 1;
+

arch/arm/cpu/armv7/sunxi/clock.c line 159

Quoted 7 lines

arch/arm/cpu/armv7/sunxi/clock.c new file +7 -0

+	/* Switch to 24MHz clock while changing PLL1 */
+	writel(AXI_DIV_1 << AXI_DIV_SHIFT |
+	       AHB_DIV_2 << AHB_DIV_SHIFT |
+	       APB0_DIV_1 << APB0_DIV_SHIFT |
+	       CPU_CLK_SRC_OSC24M << CPU_CLK_SRC_SHIFT,
+	       &ccm->cpu_ahb_apb0_cfg);
+	sdelay(20);

What is sdelay() function all about ?

[...]

Quoted 5 lines

arch/arm/cpu/armv7/sunxi/timer.c new file +4 -0

+static struct sunxi_timer *timer_base =
+	&((struct sunxi_timer_reg *)SUNXI_TIMER_BASE)->timer[TIMER_NUM];
+
+/* macro to read the 32 bit timer: since it decrements, we invert read

value */ +#define READ_TIMER() (~readl(&timer_base->val))

This macro has to go, just use ~readl() in place. But still, why do you use that negation in "~readl()" anyway ?

[...]

Quoted 7 lines · Marek Vasut

Quoted 3 lines · Ian Campbell

This has been stripped back for mainlining and supports only sun7i. These changes are not useful by themselves but are split out to make the patch sizes more manageable.

[...]

Quoted 15 lines

arch/arm/cpu/armv7/sunxi/clock.c line 57

Quoted 13 lines

arch/arm/cpu/armv7/sunxi/clock.c new file +13 -0

+int clock_init(void)
+{
+	struct sunxi_ccm_reg *const ccm =
+		(struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
+
+#ifdef CONFIG_SPL_BUILD
+	clock_init_safe();
+#endif
+
+	/* uart clock source is apb1 */
+	sr32(&ccm->apb1_clk_div_cfg, 24, 2, APB1_CLK_SRC_OSC24M);
+	sr32(&ccm->apb1_clk_div_cfg, 16, 2, APB1_FACTOR_N);
+	sr32(&ccm->apb1_clk_div_cfg, 0, 5, APB1_FACTOR_M);

sr32() is not defined anywhere.

it should be defined in
arch/arm/include/asm/arch-sunxi/sys_proto.h
and comes from
arch/arm/cpu/armv7/syslib.c

it was added for the ti omap's

I've got a local cleanup patch set where I fixed this already to clrsetbits_le32

Quoted 13 lines

Quoted 13 lines

arch/arm/cpu/armv7/sunxi/clock.c new file +13 -0

+	/* open the clock for uart */
+	sr32(&ccm->apb1_gate, 16 + CONFIG_CONS_INDEX - 1, 1, CLK_GATE_OPEN);
+
+	return 0;
+}
+
+/* Return PLL5 frequency in Hz
+ * Note: Assumes PLL5 reference is 24MHz clock
+ */
+unsigned int clock_get_pll5(void)
+{
+	struct sunxi_ccm_reg *const ccm =
+		(struct sunxi_ccm_reg *)SUNXI_CCM_BASE;

Quoted 8 lines

arch/arm/cpu/armv7/sunxi/clock.c line 76

Quoted 5 lines

arch/arm/cpu/armv7/sunxi/clock.c new file +5 -0

+	uint32_t rval = readl(&ccm->pll5_cfg);
+	int n = (rval >> 8) & 0x1f;
+	int k = ((rval >> 4) & 3) + 1;
+	int p = 1 << ((rval >> 16) & 3);
+	return 24000000 * n * k / p;

Please fix the magic values here.
[...]

Same here, got that in my local tree too

Quoted 2 lines

sr32() is not defined anywhere.

it should be defined in
arch/arm/include/asm/arch-sunxi/sys_proto.h
and comes from
arch/arm/cpu/armv7/syslib.c

I've got a local cleanup patch set where I fixed this already to clrsetbits_le32
[...]
Same here, got that in my local tree too

Quoted 6 lines

Review

Quoted 2 lines

(quoted diff) +2 -0

+#ifdef CONFIG_SPL_BUILD
+#define PLL1_CFG(N, K, M, P)	(1 << 31 | 0 << 30 | 8 << 26 | 0 << 25 |

\

arch/arm/cpu/armv7/sunxi/clock.c line 96

Quoted 2 lines

arch/arm/cpu/armv7/sunxi/clock.c new file +2 -0

+				 16 << 20 | (P) << 16 | 2 << 13 | (N) << 8 | \
+				 (K) << 4 | 0 << 3 | 0 << 2 | (M) << 0)

Here is well.

dito :)

Quoted 1 line

Quoted 4 lines

Quoted 1 line

+#define RDIV(a, b) ((a + (b) - 1) / (b))

This is some kind of DIV_ROUND_UP() from include/common.h ?

[...]

That one i didn't have;

Ian, I guess you can verify that generic macro works for here?

Quoted 8 lines · Marek Vasut

arch/arm/cpu/armv7/sunxi/clock.c line 159

Quoted 7 lines

arch/arm/cpu/armv7/sunxi/clock.c new file +7 -0

+	/* Switch to 24MHz clock while changing PLL1 */
+	writel(AXI_DIV_1 << AXI_DIV_SHIFT |
+	       AHB_DIV_2 << AHB_DIV_SHIFT |
+	       APB0_DIV_1 << APB0_DIV_SHIFT |
+	       CPU_CLK_SRC_OSC24M << CPU_CLK_SRC_SHIFT,
+	       &ccm->cpu_ahb_apb0_cfg);
+	sdelay(20);

What is sdelay() function all about ?

It also is from
arch/arm/include/asm/arch-sunxi/sys_proto.h
and I thought all where replaced with udelays

Quoted 11 lines · Olliver Schinagl

Quoted 9 lines · Marek Vasut

arch/arm/cpu/armv7/sunxi/clock.c line 159

Quoted 7 lines

arch/arm/cpu/armv7/sunxi/clock.c new file +7 -0

+	/* Switch to 24MHz clock while changing PLL1 */
+	writel(AXI_DIV_1 << AXI_DIV_SHIFT |
+	       AHB_DIV_2 << AHB_DIV_SHIFT |
+	       APB0_DIV_1 << APB0_DIV_SHIFT |
+	       CPU_CLK_SRC_OSC24M << CPU_CLK_SRC_SHIFT,
+	       &ccm->cpu_ahb_apb0_cfg);
+	sdelay(20);

What is sdelay() function all about ?

Quoted 3 lines

It also is from
arch/arm/include/asm/arch-sunxi/sys_proto.h
and I thought all where replaced with udelays

Since these sdelays() are used while we are frobbing around with the clocks I'm not sure that switching to udelay is possible/wise. sdelay is documented as:
* sdelay() - simple spin loop. Will be constant time as
* its generally used in bypass conditions only. This
* is necessary until timers are accessible.

IOW it sounds like it is designed to be used in exactly these circumstances.

Given the lack of documentation for what is actually required by the hardware when changing these clocks I'm a bit reluctant to go changing things.

Quoted 3 lines · Ian Campbell

This has been stripped back for mainlining and supports only sun7i. These changes are not useful by themselves but are split out to make the patch sizes more manageable.

[...]

Quoted 5 lines

arch/arm/cpu/armv7/sunxi/timer.c new file +4 -0

+static struct sunxi_timer *timer_base =
+     &((struct sunxi_timer_reg *)SUNXI_TIMER_BASE)->timer[TIMER_NUM];
+
+/* macro to read the 32 bit timer: since it decrements, we invert read

value */ +#define READ_TIMER() (~readl(&timer_base->val))

This macro has to go, just use ~readl() in place. But still, why do you use that negation in "~readl()" anyway ?

Quoted 8 lines · Marek Vasut

Quoted 5 lines

arch/arm/cpu/armv7/sunxi/timer.c new file +4 -0

+static struct sunxi_timer *timer_base =
+     &((struct sunxi_timer_reg *)SUNXI_TIMER_BASE)->timer[TIMER_NUM];
+
+/* macro to read the 32 bit timer: since it decrements, we invert read

value */ +#define READ_TIMER() (~readl(&timer_base->val))

This macro has to go, just use ~readl() in place. But still, why do you use that negation in "~readl()" anyway ?

The comment right above it explains why: the timer counts backwards and inverting it accounts for that.

This is subtle enough that I don't think using ~readl() in place in the 3 callers would be an improvement.

Quoted 13 lines · Ian Campbell

Quoted 8 lines · Marek Vasut

Quoted 5 lines

arch/arm/cpu/armv7/sunxi/timer.c new file +4 -0

+static struct sunxi_timer *timer_base =
+     &((struct sunxi_timer_reg *)SUNXI_TIMER_BASE)->timer[TIMER_NUM];
+
+/* macro to read the 32 bit timer: since it decrements, we invert read

value */ +#define READ_TIMER() (~readl(&timer_base->val))

This macro has to go, just use ~readl() in place. But still, why do you use that negation in "~readl()" anyway ?

The comment right above it explains why: the timer counts backwards and inverting it accounts for that.

Quoted 2 lines

This is subtle enough that I don't think using ~readl() in place in the 3 callers would be an improvement.

Please do it, we don't want any implementers down the line using this "READ_TIMER()" call and getting hit by "timer_base undefined" . That macro hides the dependency on this symbol, while if you expanded it in-place, the dependency would be explicit. I really do want to see that macro gone, sorry.

Quoted 14 lines · Marek Vasut

Quoted 13 lines · Ian Campbell

Quoted 8 lines · Marek Vasut

Quoted 5 lines

(quoted diff) +2 -0

+static struct sunxi_timer *timer_base =
+     &((struct sunxi_timer_reg

*)SUNXI_TIMER_BASE)->timer[TIMER_NUM]; +
+/* macro to read the 32 bit timer: since it decrements, we invert read value */ +#define READ_TIMER() (~readl(&timer_base->val))

This macro has to go, just use ~readl() in place. But still, why do you use that negation in "~readl()" anyway ?

The comment right above it explains why: the timer counts backwards and inverting it accounts for that.

Quoted 8 lines

Quoted 2 lines

This is subtle enough that I don't think using ~readl() in place in the 3 callers would be an improvement.

Please do it, we don't want any implementers down the line using this "READ_TIMER()" call and getting hit by "timer_base undefined" . That macro hides the dependency on this symbol, while if you expanded it in-place, the dependency would be explicit. I really do want to see that macro gone, sorry.

How about a static inline instead of the macro? I'm thinking with a body:

{
	struct sunxi_timer *timers =
		(struct sunxi_timer_reg *)SUNXI_TIMER_BASE;
	return timers[TIMER_NUM]->val;
}

With something similar in timer_init then both the macro and the static global timer_base can be dropped.

BTW this macro is in arch/arm/cpu/armv7/sunxi/timer.c not a header, so I'm not sure which implementers down the line you were worried about using it in some other context where it breaks.

Quoted 26 lines · Ian Campbell

Quoted 14 lines · Marek Vasut

Quoted 13 lines · Ian Campbell

Quoted 8 lines · Marek Vasut

Quoted 5 lines

(quoted diff) +2 -0

+static struct sunxi_timer *timer_base =
+     &((struct sunxi_timer_reg

*)SUNXI_TIMER_BASE)->timer[TIMER_NUM]; +
+/* macro to read the 32 bit timer: since it decrements, we invert read value */ +#define READ_TIMER() (~readl(&timer_base->val))

This macro has to go, just use ~readl() in place. But still, why do you use that negation in "~readl()" anyway ?

The comment right above it explains why: the timer counts backwards and inverting it accounts for that.

Quoted 8 lines

Quoted 2 lines

This is subtle enough that I don't think using ~readl() in place in the 3 callers would be an improvement.

Please do it, we don't want any implementers down the line using this "READ_TIMER()" call and getting hit by "timer_base undefined" . That macro hides the dependency on this symbol, while if you expanded it in-place, the dependency would be explicit. I really do want to see that macro gone, sorry.

How about a static inline instead of the macro? I'm thinking with a body:

Quoted 7 lines

{
      struct sunxi_timer *timers =
              (struct sunxi_timer_reg *)SUNXI_TIMER_BASE;
      return timers[TIMER_NUM]->val;
}

With something similar in timer_init then both the macro and the static global timer_base can be dropped.

That's just wrapping a readl() into another function, which seems unnecessary really.

Quoted 3 lines

BTW this macro is in arch/arm/cpu/armv7/sunxi/timer.c not a header, so I'm not sure which implementers down the line you were worried about using it in some other context where it breaks.

People plumbing in the timer.c file who are not aware the macro has a dependency which is not passed as it's parameter.

Quoted 34 lines · Marek Vasut

Quoted 33 lines · Ian Campbell

Quoted 15 lines · Marek Vasut

Quoted 14 lines · Ian Campbell

Quoted 9 lines · Marek Vasut

Quoted 6 lines

(quoted diff) +2 -0

+static struct sunxi_timer *timer_base =
+     &((struct sunxi_timer_reg

*)SUNXI_TIMER_BASE)->timer[TIMER_NUM]; +
+/* macro to read the 32 bit timer: since it decrements, we invert read value */ +#define READ_TIMER() (~readl(&timer_base->val))

This macro has to go, just use ~readl() in place. But still, why do you use that negation in "~readl()" anyway ?

The comment right above it explains why: the timer counts backwards and inverting it accounts for that.

Quoted 8 lines

Quoted 2 lines

This is subtle enough that I don't think using ~readl() in place in the 3 callers would be an improvement.

Please do it, we don't want any implementers down the line using this "READ_TIMER()" call and getting hit by "timer_base undefined" . That macro hides the dependency on this symbol, while if you expanded it in-place, the dependency would be explicit. I really do want to see that macro gone, sorry.

How about a static inline instead of the macro? I'm thinking with a body:
{

struct sunxi_timer *timers =

(struct sunxi_timer_reg *)SUNXI_TIMER_BASE;

Quoted 8 lines

Quoted 5 lines

      return timers[TIMER_NUM]->val;

}
With something similar in timer_init then both the macro and the static global timer_base can be dropped.

That's just wrapping a readl() into another function, which seems unnecessary really.

Sorry, but I think inlining the readl (and along with it the interesting/subtle) inverting functionality is a terrible idea, it should be wrapped in some sort of accessor precisely because it is not a raw readl.

I'm going to make it a function as I suggested.

Quoted 4 lines

Quoted 3 lines

BTW this macro is in arch/arm/cpu/armv7/sunxi/timer.c not a header, so I'm not sure which implementers down the line you were worried about using it in some other context where it breaks.

Quoted 2 lines

People plumbing in the timer.c file who are not aware the macro has a dependency which is not passed as it's parameter.

What people? What plumbing? I've no idea what you are concerned about here.

Quoted 35 lines · Marek Vasut

Quoted 26 lines · Ian Campbell

Quoted 14 lines · Marek Vasut

Quoted 13 lines · Ian Campbell

Quoted 8 lines · Marek Vasut

Quoted 5 lines

(quoted diff) +2 -0

+static struct sunxi_timer *timer_base =
+     &((struct sunxi_timer_reg

*)SUNXI_TIMER_BASE)->timer[TIMER_NUM]; +
+/* macro to read the 32 bit timer: since it decrements, we invert read value */ +#define READ_TIMER() (~readl(&timer_base->val))

This macro has to go, just use ~readl() in place. But still, why do you use that negation in "~readl()" anyway ?

The comment right above it explains why: the timer counts backwards and inverting it accounts for that.

Quoted 8 lines

Quoted 2 lines

This is subtle enough that I don't think using ~readl() in place in the 3 callers would be an improvement.

Please do it, we don't want any implementers down the line using this "READ_TIMER()" call and getting hit by "timer_base undefined" . That macro hides the dependency on this symbol, while if you expanded it in-place, the dependency would be explicit. I really do want to see that macro gone, sorry.

How about a static inline instead of the macro? I'm thinking with a body:

Quoted 7 lines

{
      struct sunxi_timer *timers =
              (struct sunxi_timer_reg *)SUNXI_TIMER_BASE;
      return timers[TIMER_NUM]->val;
}

With something similar in timer_init then both the macro and the static global timer_base can be dropped.

Quoted 2 lines

That's just wrapping a readl() into another function, which seems unnecessary really.

Sorry, but I think inlining the readl (and along with it the interesting/subtle) inverting functionality is a terrible idea, it should be wrapped in some sort of accessor precisely because it is not a raw readl.

I'm going to make it a function as I suggested.

Quoted 4 lines

Quoted 3 lines

BTW this macro is in arch/arm/cpu/armv7/sunxi/timer.c not a header, so I'm not sure which implementers down the line you were worried about using it in some other context where it breaks.

Quoted 2 lines

People plumbing in the timer.c file who are not aware the macro has a dependency which is not passed as it's parameter.

What people? What plumbing? I've no idea what you are concerned about here.

Hi,

Quoted 57 lines · Ian Campbell

Quoted 33 lines · Marek Vasut

Quoted 32 lines · Ian Campbell

Quoted 14 lines · Marek Vasut

Quoted 13 lines · Ian Campbell

Quoted 8 lines · Marek Vasut

Quoted 5 lines

(quoted diff) +2 -0

+static struct sunxi_timer *timer_base =
+     &((struct sunxi_timer_reg

*)SUNXI_TIMER_BASE)->timer[TIMER_NUM]; +
+/* macro to read the 32 bit timer: since it decrements, we invert read value */ +#define READ_TIMER() (~readl(&timer_base->val))

This macro has to go, just use ~readl() in place. But still, why do you use that negation in "~readl()" anyway ?

The comment right above it explains why: the timer counts backwards and inverting it accounts for that.

Quoted 8 lines

Quoted 2 lines

This is subtle enough that I don't think using ~readl() in place in the 3 callers would be an improvement.

Please do it, we don't want any implementers down the line using this "READ_TIMER()" call and getting hit by "timer_base undefined" . That macro hides the dependency on this symbol, while if you expanded it in-place, the dependency would be explicit. I really do want to see that macro gone, sorry.

How about a static inline instead of the macro? I'm thinking with a body:
{

struct sunxi_timer *timers =

(struct sunxi_timer_reg *)SUNXI_TIMER_BASE;

Quoted 8 lines

Quoted 5 lines

      return timers[TIMER_NUM]->val;

}
With something similar in timer_init then both the macro and the static global timer_base can be dropped.

That's just wrapping a readl() into another function, which seems unnecessary really.

Sorry, but I think inlining the readl (and along with it the interesting/subtle) inverting functionality is a terrible idea, it should be wrapped in some sort of accessor precisely because it is not a raw readl.

I'm going to make it a function as I suggested.

Quoted 6 lines

Quoted 3 lines

BTW this macro is in arch/arm/cpu/armv7/sunxi/timer.c not a header, so I'm not sure which implementers down the line you were worried about using it in some other context where it breaks.

People plumbing in the timer.c file who are not aware the macro has a dependency which is not passed as it's parameter.

Quoted 2 lines

What people? What plumbing? I've no idea what you are concerned about here.

I think what Marek is concerned about is people making some global u-boot change which for some reason requires fixing up a bunch of platform specific files, and they end up touching our timer.c without ever test-compiling it.

These kind of things happen in qemu / the kernel too. In this case they could move a READ_TIMER() somewhere where the timer_base is not defined.

Your suggestion of making it a proper function will fix that though, and I think is the best solution.

(quoted diff) +0 -0

b/arch/arm/cpu/armv7/sunxi/pinmux.c new file mode 100644 index 0000000..8f5cbfe

arch/arm/cpu/armv7/sunxi/pinmux.c new file +16 -0

@@ -0,0 +1,80 @@
+/*
+ * (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/arch/gpio.h>
+
+int sunxi_gpio_set_cfgpin(u32 pin, u32 val)
+{
+	u32 cfg;
+	u32 bank = GPIO_BANK(pin);

arch/arm/cpu/armv7/sunxi/pinmux.c new file +22 -0

+	return 0;
+}
+
+int sunxi_gpio_get_cfgpin(u32 pin)
+{
+	u32 cfg;
+	u32 bank = GPIO_BANK(pin);
+	u32 index = GPIO_CFG_INDEX(pin);
+	u32 offset = GPIO_CFG_OFFSET(pin);
+	struct sunxi_gpio *pio =
+	    &((struct sunxi_gpio_reg *)SUNXI_PIO_BASE)->gpio_bank[bank];
+
+	cfg = readl(&pio->cfg[0] + index);
+	cfg >>= offset;
+
+	return cfg & 0xf;
+}
+
+int sunxi_gpio_set_drv(u32 pin, u32 val)
+{
+	u32 drv;
+	u32 bank = GPIO_BANK(pin);

arch/arm/cpu/armv7/sunxi/pinmux.c new file +7 -0

+	return 0;
+}
+
+int sunxi_gpio_set_pull(u32 pin, u32 val)
+{
+	u32 pull;
+	u32 bank = GPIO_BANK(pin);

arch/arm/cpu/armv7/sunxi/pinmux.c new file +2 -0

+	return 0;
+}

arch/arm/cpu/armv7/sunxi/pinmux.c line 26

Quoted 5 lines

arch/arm/cpu/armv7/sunxi/pinmux.c new file +5 -0

+     cfg = readl(&pio->cfg[0] + index);
+     cfg &= ~(0xf << offset);
+     cfg |= val << offset;
+
+     writel(cfg, &pio->cfg[0] + index);

clrsetbits_le32() here.

Quoted 7 lines · Marek Vasut

arch/arm/cpu/armv7/sunxi/pinmux.c line 26

Quoted 5 lines

arch/arm/cpu/armv7/sunxi/pinmux.c new file +5 -0

+     cfg = readl(&pio->cfg[0] + index);
+     cfg &= ~(0xf << offset);
+     cfg |= val << offset;
+
+     writel(cfg, &pio->cfg[0] + index);

clrsetbits_le32() here.

I looked at this transform in a few different contexts and one concern I had was that readl and writel have barriers in them (after the read and before the write respectively) while clrsetbits and friends do not. I don't think this will matter for the read/modify/write bit twiddling itself (since there are register dependencies) but I was slightly concerned that the barriers were hiding the lack of explicit barriers which would be required between the various reads/writes.

But I think I am probably being overly cautious here and the obvious transformation can be made. Anyone got any thoughts?

I looked at this transform in a few different contexts and one concern I had was that readl and writel have barriers in them (after the read and before the write respectively) while clrsetbits and friends do not. I

But I think I am probably being overly cautious here and the obvious transformation can be made. Anyone got any thoughts?

I'm not an expert for ARM, but this indeed looks suspiscious - thanks for reporting this.

arch/arm/include/asm/arch-sunxi/gpio.h line 143

Quoted 6 lines

arch/arm/include/asm/arch-sunxi/gpio.h new file +6 -0

+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 name_to_gpio(const char *name);
+#define name_to_gpio name_to_gpio

What is this ugly define doing here ?

Quoted 8 lines · Marek Vasut

arch/arm/include/asm/arch-sunxi/gpio.h line 143

Quoted 6 lines

arch/arm/include/asm/arch-sunxi/gpio.h new file +6 -0

+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 name_to_gpio(const char *name);
+#define name_to_gpio name_to_gpio

What is this ugly define doing here ?

common/cmd_gpio.c uses the #ifndef name_to_gpio pattern to provide (or not) a default fallback implementation. I think this is a reasonably (but not very) common idiom for such cases where the non-default variant is not best expressed as a macro.

Quoted 8 lines · Marek Vasut

arch/arm/include/asm/arch-sunxi/gpio.h line 143

Quoted 6 lines

arch/arm/include/asm/arch-sunxi/gpio.h new file +6 -0

+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 name_to_gpio(const char *name);
+#define name_to_gpio name_to_gpio

What is this ugly define doing here ?

common/cmd_gpio.c uses the #ifndef name_to_gpio pattern to provide (or not) a default fallback implementation. I think this is a reasonably (but not very) common idiom for such cases where the non-default variant is not best expressed as a macro.

Dear Ian Campbell,

Quoted 11 lines · In message <[email protected]> you wrote:

Quoted 8 lines · Marek Vasut

arch/arm/include/asm/arch-sunxi/gpio.h line 143

Quoted 6 lines

arch/arm/include/asm/arch-sunxi/gpio.h new file +6 -0

+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 name_to_gpio(const char *name);
+#define name_to_gpio name_to_gpio

What is this ugly define doing here ?

Quoted 4 lines

common/cmd_gpio.c uses the #ifndef name_to_gpio pattern to provide (or not) a default fallback implementation. I think this is a reasonably (but not very) common idiom for such cases where the non-default variant is not best expressed as a macro.

Please add a comment to explain that.

Quoted 18 lines · Wolfgang Denk

Dear Ian Campbell,

Quoted 14 lines · In message <[email protected]> you wrote:

Quoted 8 lines · Marek Vasut

arch/arm/include/asm/arch-sunxi/gpio.h line 143

Quoted 6 lines

arch/arm/include/asm/arch-sunxi/gpio.h new file +6 -0

+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 name_to_gpio(const char *name);
+#define name_to_gpio name_to_gpio

What is this ugly define doing here ?

common/cmd_gpio.c uses the #ifndef name_to_gpio pattern to provide (or not) a default fallback implementation. I think this is a reasonably (but not very) common idiom for such cases where the non-default variant is not best expressed as a macro.

Quoted 1 line

Please add a comment to explain that.

Unless you object I think I'll do as Marek suggested name the function sunxi_name_to_gpio and make the #define to that, it seems more consistent that way.

Quoted 2 lines

Please add a comment to explain that.

Unless you object I think I'll do as Marek suggested name the function sunxi_name_to_gpio and make the #define to that, it seems more consistent that way.

This has been stripped back for mainlining and supports only sun7i. These changes are not useful by themselves but are split out to make the patch sizes more manageable.

As well as the following signed-off-by the sunxi branch shows commits to these files authored by the following:
Almo Nito
Carl van Schaik
FUKAUMI Naoki
hehopmajieh
j
Sergey Lapin
Tom Cubie

And we implement the same Developer's Certificate of Origin as used in Linux, so we need real names and working e-mail addresses in the Signed-off-by lines - a cursory mentioning that some mysterious "j" or some "hehopmajieh" authored some code is not sufficient.

Dear Ian Campbell,

Quoted 4 lines · In message <[email protected]> you wrote:

This has been stripped back for mainlining and supports only sun7i. These changes are not useful by themselves but are split out to make the patch sizes more manageable.

Quoted 9 lines

As well as the following signed-off-by the sunxi branch shows commits to these files authored by the following:
Almo Nito
Carl van Schaik
FUKAUMI Naoki
hehopmajieh
j
Sergey Lapin
Tom Cubie

Sorry, this is a NAK for these patches.

"These changes are not useful by themselves but are split out to make the patch sizes more manageable." This is not how we work. Patches have to implement specific features, or fix specific bugs. And they have to maintain bisectability of the code.

Quoted 6 lines

Sorry, this is a NAK for these patches.

"These changes are not useful by themselves but are split out to make the patch sizes more manageable." This is not how we work. Patches have to implement specific features, or fix specific bugs. And they have to maintain bisectability of the code.

These patches do implement specific features, like dram init, timer/clk init, etc. They just don't enable them yet as by themselves they are not useful.

The patches also maintain bisectability since they don't touch any existing files until the patch 5 and 6 come into play, and the changes in patch 5 keep things compiling just fine.

FWIW I believe the split-up Ian has done makes sense. But if you insist I guess we can merge patch 1-6 (the minimum set to get something working) into 1 big patch.

Quoted 5 lines

"These changes are not useful by themselves but are split out to make the patch sizes more manageable." This is not how we work. Patches have to implement specific features, or fix specific bugs. And they have to maintain bisectability of the code.

These patches do implement specific features, like dram init, timer/clk init, etc. They just don't enable them yet as by themselves they are not useful.

The patches also maintain bisectability since they don't touch any existing files until the patch 5 and 6 come into play, and the changes in patch 5 keep things compiling just fine.

FWIW I believe the split-up Ian has done makes sense. But if you insist I guess we can merge patch 1-6 (the minimum set to get something working) into 1 big patch.

Dear Hans de Goede,

Quoted 6 lines · In message <[email protected]> you wrote:

Quoted 5 lines

"These changes are not useful by themselves but are split out to make the patch sizes more manageable." This is not how we work. Patches have to implement specific features, or fix specific bugs. And they have to maintain bisectability of the code.

Quoted 2 lines

These patches do implement specific features, like dram init, timer/clk init, etc. They just don't enable them yet as by themselves they are not useful.

Well, then at least the commit meSsage needs some serious rework.

Quoted 3 lines

The patches also maintain bisectability since they don't touch any existing files until the patch 5 and 6 come into play, and the changes in patch 5 keep things compiling just fine.

I think I have seen some interdependencies between the patches - like referring to stuff that gets only added in later patches?

This has been stripped back for mainlining and supports only sun7i booting via FEL mode. These changes are not useful by themselves but are split out to make the patch sizes more manageable.

As well as the following signed-off-by the sunxi branch shows commits to these files authored by the following:

Almo Nito
Carl van Schaik
FUKAUMI Naoki
hehopmajieh
j

Dear Ian Campbell,

Quoted 6 lines · In message <[email protected]> you wrote:

This has been stripped back for mainlining and supports only sun7i booting via FEL mode. These changes are not useful by themselves but are split out to make the patch sizes more manageable.

As well as the following signed-off-by the sunxi branch shows commits to these files authored by the following:

What does that mean? I cannot find these names in the SoB lines?

Quoted 5 lines

Almo Nito
Carl van Schaik
FUKAUMI Naoki
hehopmajieh
j

And these are not actually names ... nor do we have the e-mail addresses...

Quoted 2 lines

What does that mean? I cannot find these names in the SoB lines?

I explained the process by which I arrived at these lists in 0/9. It means that they appear as an author for a commit in the history in the u-boot-sunxi.git, but did not supply an S-o-b. However I am adding my own S-o-b under clause (b) of the DCO, which I believe applies here.

It's entirely possible that none of these peoples' contributions still remain in the files being upstreamed, but figuring that out for sure would be a large and manual task. As I explained in 0/9 I prefer to over-credit by mentioning people whose actual contributions no longer remain rather than fail to credit someone whose contribution does

I have email addresses from the commit authorship, which I should indeed have included here, I shall definitely do that for v3. Please let me know whether or not I should also spend hours trawling down the precise pedigree of each line of code.

Dear Ian,

Quoted 7 lines · In message <[email protected]> you wrote:

Quoted 2 lines

What does that mean? I cannot find these names in the SoB lines?

I explained the process by which I arrived at these lists in 0/9. It means that they appear as an author for a commit in the history in the u-boot-sunxi.git, but did not supply an S-o-b. However I am adding my own S-o-b under clause (b) of the DCO, which I believe applies here.

Please read (again) what the Developer's Certificate of Origin means. It appears that such code would fall under clause (c):

The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it.

Did for example "j" or "hehopmajieh" provide such certificates to you?

Quoted 5 lines

It's entirely possible that none of these peoples' contributions still remain in the files being upstreamed, but figuring that out for sure would be a large and manual task. As I explained in 0/9 I prefer to over-credit by mentioning people whose actual contributions no longer remain rather than fail to credit someone whose contribution does

The Sob is only partially for crediting; the major purpose is to make sure we really have the full rights to distribute such code under the listed licenses. To guarantee that, the chain of certificates mustnot be interrupted.

Quoted 4 lines

I have email addresses from the commit authorship, which I should indeed have included here, I shall definitely do that for v3. Please let me know whether or not I should also spend hours trawling down the precise pedigree of each line of code.

The SoB lines need real names plus real, working mail addresses. The Linux "Documentation/SubmittingPatches" filemakes this clear:

using your real name (sorry, no pseudonyms or anonymous contributions.)

Hi,

Quoted 14 lines · Wolfgang Denk

Dear Ian,

Quoted 7 lines · In message <[email protected]> you wrote:

Quoted 2 lines

What does that mean? I cannot find these names in the SoB lines?

I explained the process by which I arrived at these lists in 0/9. It means that they appear as an author for a commit in the history in the u-boot-sunxi.git, but did not supply an S-o-b. However I am adding my own S-o-b under clause (b) of the DCO, which I believe applies here.

Please read (again) what the Developer's Certificate of Origin means. It appears that such code would fall under clause (c):

Quoted 3 lines

The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it.

No as said before the parts for which we don't have a Signed-off-by for falls under b), since we took it from existing code which has clear GPLv2+ license headers on each and every file.

b) Reads:

(b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or

Quoted 8 lines

Did for example "j" or "hehopmajieh" provide such certificates to you?

Quoted 5 lines

It's entirely possible that none of these peoples' contributions still remain in the files being upstreamed, but figuring that out for sure would be a large and manual task. As I explained in 0/9 I prefer to over-credit by mentioning people whose actual contributions no longer remain rather than fail to credit someone whose contribution does

Quoted 4 lines

The Sob is only partially for crediting; the major purpose is to make sure we really have the full rights to distribute such code under the listed licenses. To guarantee that, the chain of certificates mustnot be interrupted.

Right, and we do since the files we're basing our work on is GPLv2+ licensed, the purpose of the listing of extra names other then the Signed-off-by:
tags is for solely for attribution.

Note in some cases we do have email addresses and Ian has said he will add those in the next version,

No as said before the parts for which we don't have a Signed-off-by for falls under b), since we took it from existing code which has clear GPLv2+ license headers on each and every file.

Quoted 1 line

using your real name (sorry, no pseudonyms or anonymous contributions.)

Right but these are not Signed-off-by lines. Just as I may thank a tester in a commit message with just his name because he does not want me to disclose his email address, we are attributing people here with just there names.

Note in some cases we do have email addresses and Ian has said he will add those in the next version, but we cannot magically conjure up Signed-off-by's which we don't have, and section b) says we don't need to since all the original files have a clear GPLv2+ license header.

Dear Hans de Goede,

Quoted 4 lines · In message <[email protected]> you wrote:

No as said before the parts for which we don't have a Signed-off-by for falls under b), since we took it from existing code which has clear GPLv2+ license headers on each and every file.

Can the code be properly attributed, i. e. does it have proper
Signed-off-by: lines?

Quoted 5 lines

Quoted 1 line

using your real name (sorry, no pseudonyms or anonymous contributions.)

Right but these are not Signed-off-by lines. Just as I may thank a tester in a commit message with just his name because he does not want me to disclose his email address, we are attributing people here with just there names.

If these people attributed to the code, we should have their commits with their respective Signed-off-by: lines.

This has been stripped back for mainlining and supports only sun7i booting via FEL mode. These changes are not useful by themselves but are split out to make the patch sizes more manageable.

As well as the following signed-off-by the sunxi branch shows commits to these files authored by the following:
Almo Nito
Carl van Schaik
FUKAUMI Naoki
hehopmajieh
j
Sergey Lapin
Tom Cubie

Signed-off-by Adam Sampson <[email protected]>

Signed-off-by Aleksei Mamlin <[email protected]>

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

Signed-off-by Emilio L?pez <[email protected]>

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

Signed-off-by Henrik Nordstrom <[email protected]>

Signed-off-by Jens Kuske <[email protected]>

Signed-off-by Luc Verhaegen <[email protected]>

Signed-off-by Luke Leighton <[email protected]>

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

Signed-off-by Patrick Wood <[email protected]>

Signed-off-by Stefan Roese <[email protected]>

Signed-off-by Wills Wang <[email protected]>

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

---
v2: Based on u-boot-sunxi.git#sunxi d9aa5dd3d15c "sunxi: mmc:
checkpatch whitespace fixes" with v2014.04-rc2 merged in:
- sunxi-common.h updates, including pulling some command additions back from the non-FEL patch and switchin to bootm_size not BOOTMAPSZ

v1: Based on u-boot-sunxi.git#sunxi commit d854c4de2f57 "arm: Handle .gnu.hash section in ldscripts" vs v2014.01.

---
 arch/arm/cpu/armv7/Makefile                 |   2 +-
 arch/arm/cpu/armv7/sunxi/u-boot-spl-fel.lds |  59 +++++++++++
 arch/arm/include/asm/arch-sunxi/spl.h       |  20 ++++
 board/sunxi/Makefile                        |   1 +
 include/configs/sun7i.h                     |  24 +++++
 include/configs/sunxi-common.h              | 153
++++++++++++++++++++++++++++ 6 files changed, 258 insertions(+), 1
deletion(-)
 create mode 100644 arch/arm/cpu/armv7/sunxi/u-boot-spl-fel.lds
 create mode 100644 arch/arm/include/asm/arch-sunxi/spl.h
 create mode 100644 include/configs/sun7i.h
 create mode 100644 include/configs/sunxi-common.h

arch/arm/cpu/armv7/Makefile +0 -1

index 119ebb3..ddf00f3 100644
@@ -12,7 +12,7 @@ obj-y	+= cache_v7.o
 obj-y	+= cpu.o
 obj-y	+= syslib.o
 
-ifneq

($(CONFIG_AM43XX)$(CONFIG_AM33XX)$(CONFIG_OMAP44XX)$(CONFIG_OMAP54XX)$(CON FIG_TEGRA)$(CONFIG_MX6)$(CONFIG_TI81XX)$(CONFIG_AT91FAMILY),) +ifneq ($(CONFIG_AM43XX)$(CONFIG_AM33XX)$(CONFIG_OMAP44XX)$(CONFIG_OMAP54XX)$(CON FIG_TEGRA)$(CONFIG_MX6)$(CONFIG_TI81XX)$(CONFIG_AT91FAMILY)$(CONFIG_SUNXI), ) ifneq ($(CONFIG_SKIP_LOWLEVEL_INIT),y)
obj-y += lowlevel_init.o
endif

(quoted diff) +0 -0

b/arch/arm/cpu/armv7/sunxi/u-boot-spl-fel.lds new file mode 100644 index 0000000..cf02300

arch/arm/cpu/armv7/sunxi/u-boot-spl-fel.lds new file +4 -0

+#define CONFIG_SYS_NS16550_COM1		SUNXI_UART0_BASE
+#define CONFIG_SYS_NS16550_COM2		SUNXI_UART1_BASE
+#define CONFIG_SYS_NS16550_COM3		SUNXI_UART2_BASE
+#define CONFIG_SYS_NS16550_COM4		SUNXI_UART3_BASE

arch/arm/cpu/armv7/sunxi/u-boot-spl-fel.lds

Quoted 5 lines

(quoted diff) +0 -0

b/arch/arm/cpu/armv7/sunxi/u-boot-spl-fel.lds new file mode 100644 index 0000000..cf02300

arch/arm/cpu/armv7/sunxi/u-boot-spl-fel.lds new file +0 -0

This file is unreadable. Can you not actually merge it into u-boot-spl.lds with some #ifdef ?

Quoted 8 lines · Marek Vasut

arch/arm/cpu/armv7/sunxi/u-boot-spl-fel.lds

Quoted 5 lines

(quoted diff) +0 -0

b/arch/arm/cpu/armv7/sunxi/u-boot-spl-fel.lds new file mode 100644 index 0000000..cf02300

arch/arm/cpu/armv7/sunxi/u-boot-spl-fel.lds new file +0 -0

This file is unreadable. Can you not actually merge it into u-boot-spl.lds with some #ifdef ?

They look pretty much entirely different to me. I should sort out the whitespace and stuff though, it is a mess in that regard. Perhaps that will help.

Quoted 10 lines · Ian Campbell

Quoted 8 lines · Marek Vasut

arch/arm/cpu/armv7/sunxi/u-boot-spl-fel.lds

Quoted 5 lines

(quoted diff) +0 -0

b/arch/arm/cpu/armv7/sunxi/u-boot-spl-fel.lds new file mode 100644 index 0000000..cf02300

arch/arm/cpu/armv7/sunxi/u-boot-spl-fel.lds new file +0 -0

This file is unreadable. Can you not actually merge it into u-boot-spl.lds with some #ifdef ?

Quoted 3 lines

They look pretty much entirely different to me. I should sort out the whitespace and stuff though, it is a mess in that regard. Perhaps that will help.

Likely, but is it really necessary for those two files to be so different or is this some legacy stuff in the sunxi-specific .lds file?

Quoted 15 lines · Marek Vasut

Quoted 13 lines · Ian Campbell

Quoted 8 lines · Marek Vasut

arch/arm/cpu/armv7/sunxi/u-boot-spl-fel.lds

Quoted 5 lines

(quoted diff) +0 -0

b/arch/arm/cpu/armv7/sunxi/u-boot-spl-fel.lds new file mode 100644 index 0000000..cf02300

arch/arm/cpu/armv7/sunxi/u-boot-spl-fel.lds new file +0 -0

This file is unreadable. Can you not actually merge it into u-boot-spl.lds with some #ifdef ?

They look pretty much entirely different to me. I should sort out the whitespace and stuff though, it is a mess in that regard. Perhaps that will help.

Quoted 2 lines

Likely, but is it really necessary for those two files to be so different or is this some legacy stuff in the sunxi-specific .lds file?

The standard lds file is pretty standard. This -fel version is for a special boot mode which sunxi processors have[0] which allows for booting over USB OTG, so the image needs to be built appropriately.

As well as the following signed-off-by the sunxi branch shows commits to these files authored by the following:
Stefan Roese
Tom Cubie
yemao

Signed-off-by Henrik Nordstrom <[email protected]>

Signed-off-by Luke Leighton <[email protected]>

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

Signed-off-by Wills Wang <[email protected]>

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

Cc Pantelis Antoniou <[email protected]>

drivers/mmc/sunxi_mmc.c new file +21 -0

+static int mmc_trans_data_by_cpu(struct mmc *mmc, struct mmc_data *data)
+{
+	struct sunxi_mmc_host *mmchost = (struct sunxi_mmc_host *)mmc->priv;
+	unsigned i;
+	unsigned byte_cnt = data->blocksize * data->blocks;
+	unsigned *buff;
+	unsigned timeout = 0xfffff;
+
+	if (data->flags & MMC_DATA_READ) {
+		buff = (unsigned int *)data->dest;
+		for (i = 0; i < (byte_cnt >> 2); i++) {
+			while (--timeout &&
+			       (readl(&mmchost->reg->status) &
+				SUNXI_MMC_STATUS_FIFO_EMPTY))
+				;
+			if (timeout <= 0)
+				goto out;
+			buff[i] = readl(mmchost->database);
+			timeout = 0xfffff;
+		}
+	} else {

drivers/mmc/sunxi_mmc.c new file +41 -0

+static int mmc_trans_data_by_dma(struct mmc *mmc, struct mmc_data *data)
+{
+	struct sunxi_mmc_host *mmchost = (struct sunxi_mmc_host *)mmc->priv;
+	unsigned byte_cnt = data->blocksize * data->blocks;
+	unsigned char *buff;
+	unsigned des_idx = 0;
+	unsigned buff_frag_num =
+		(byte_cnt + SDXC_DES_BUFFER_MAX_LEN - 1) >> SDXC_DES_NUM_SHIFT;
+	unsigned remain;
+	unsigned i, rval;
+	ALLOC_CACHE_ALIGN_BUFFER(struct sunxi_mmc_des, pdes, buff_frag_num);
+
+	buff = data->flags & MMC_DATA_READ ?
+	    (unsigned char *)data->dest : (unsigned char *)data->src;
+	remain = byte_cnt & (SDXC_DES_BUFFER_MAX_LEN - 1);
+	if (!remain)
+		remain = SDXC_DES_BUFFER_MAX_LEN;
+
+	flush_cache((unsigned long)buff, (unsigned long)byte_cnt);
+	for (i = 0; i < buff_frag_num; i++, des_idx++) {
+		memset((void *)&pdes[des_idx], 0, sizeof(struct sunxi_mmc_des));
+		pdes[des_idx].des_chain = 1;
+		pdes[des_idx].own = 1;
+		pdes[des_idx].dic = 1;
+		if (buff_frag_num > 1 && i != buff_frag_num - 1)
+			pdes[des_idx].data_buf1_sz =
+			    (SDXC_DES_BUFFER_MAX_LEN -
+			     1) & SDXC_DES_BUFFER_MAX_LEN;
+		else
+			pdes[des_idx].data_buf1_sz = remain;
+
+		pdes[des_idx].buf_addr_ptr1 =
+		    (u32) buff + i * SDXC_DES_BUFFER_MAX_LEN;
+		if (i == 0)
+			pdes[des_idx].first_des = 1;
+
+		if (i == buff_frag_num - 1) {
+			pdes[des_idx].dic = 0;
+			pdes[des_idx].last_des = 1;
+			pdes[des_idx].end_of_ring = 1;
+			pdes[des_idx].buf_addr_ptr2 = 0;

This is my second cut at an upstreamable series based upon the
https://github.com/linux-sunxi/u-boot-sunxi.git#sunxi tree. The intention is to present a minimal starting point for upstreaming to which support for other processors, peripherals, boards etc can be added in the future. Therefore this has been stripped right back and currently supports only sun7i processors AKA Allwinner A20 and the cubietruck board. Supported peripherals are UART, MMC and Ethernet.

I've tried to give corect credit and S-o-b based upon:
git log --pretty='%aN' linux-sunxi/sunxi -- [PATHS] | sort -u git log linux-sunxi/sunxi -- [PATHS] | grep -i signed.off.by | sort -u Manual inspection

fre 2014-03-21 klockan 21:54 +0000 skrev Ian Campbell:

Quoted 4 lines

I've tried to give corect credit and S-o-b based upon:
git log --pretty='%aN' linux-sunxi/sunxi -- [PATHS] | sort -u git log linux-sunxi/sunxi -- [PATHS] | grep -i signed.off.by | sort -u Manual inspection

As you noticed there is S-o-b lines missing on most of my commits in sunxi branch. This was corrected in the sunxi-patchqueue branch where previous patchset were prepared for mainlining.

Please add an implicit S-o-b line on any arch/arm/cpu/armv7/sunxi/ or board/sunxi/ on patches including code I have committed.