[linux-sunxi] Re: [U-Boot] [PATCH v1 0/9] sunxi: initial upstreamining effort

2014-03-16 Thread Ian Campbell
On Fri, 2014-03-14 at 15:17 -0500, Dennis Gilmore wrote:
 On Fri, 14 Mar 2014 10:16:42 -0400
 Tom Rini tr...@ti.com wrote:
 
  On Fri, Mar 14, 2014 at 10:33:32AM +, Ian Campbell wrote:
  
   Hi,
   
   This is my first 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 and the cubietruck
   board. Supported peripherals are UART, MMC and Ethernet.
  
  Some global comments:
  - If you haven't already, make sure it's all checkpatch clean.
  - Use the SPDX tags rather than including the GPL boilerplate.
  - Please re-word the commit messages.  The how we got here / where
  this is from is fine for the cover letter.
  - Magic numbers need to be defined.
 
 I have a quick request also, Please incorporate the ongoing generic
 distro work as most if not all of the sunxi systems I know of are
 targets for generic distros.

This: http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/180540 ?

Sure.

Ian.


-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] Re: [U-Boot] [PATCH v1 5/9] sunxi: generic sun7i build infrastructure.

2014-03-16 Thread Ian Campbell
On Fri, 2014-03-14 at 10:17 -0400, Tom Rini wrote:
 On Fri, Mar 14, 2014 at 10:33:47AM +, Ian Campbell wrote:

  +/*
  + * Size of malloc() pool
  + * 1MB = 0x10, 0x10 = 1024 * 1024
  + */
  +#define CONFIG_SYS_MALLOC_LEN  (CONFIG_ENV_SIZE + (1  20))
 
 This is really really small, and precludes using UBI on NAND for
 example.

What is a suitable value? I see a lots of boards using 128kB or 1MB and
only a handful using more. Tegra uses 4MB -- is that a reasonable value?

Ian.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] [PATCH u-boot sunxi 0/4] sun4i support on top of Ian's patches

2014-03-16 Thread Hans de Goede
Hi All,

Here is a patch-set adding sun4i support on top of Ian's recent 1st
attempt to get sun7i upstream patch-set.

Note I've had to drop the raising of the cpu core clock, without matching
axp209 changes this causes issues on sun4i.

I've been thinking about how to best move forward with this patch-set, and
I think it would be best to first complete the job of splitting up what we've
in u-boot-sunxi now (at least most of it), keeping this based on v2014.01
so that we can easily diff. And then once we've everything split up, use
the split-up patch-set as a base and start working on addressing any review
comments there, which will break easy diffs against u-boot-sunxi, but at that
point we no longer need them.

We can even paralellize things. I can stick with Ian's v1 patchset for now,
adding patches on top adding what is missing in piecemeal patches, and Ian
can start working on making his initial series ready to go upstream.

Ian, does that sound like a plan ?

Regards,

Hans

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] [PATCH u-boot sunxi 1/4] sunxi: FIXUP: sunxi: initial generic sun7i cpu, board and start of day support

2014-03-16 Thread Hans de Goede
We should not be raising the cpu core frequency until we have pmic support
in place.

Signed-off-by: Hans de Goede hdego...@redhat.com
---
 board/sunxi/board.c | 10 --
 1 file changed, 10 deletions(-)

diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index 5dbcf2a..cc3083c 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -75,7 +75,6 @@ int board_mmc_init(bd_t *bis)
 #ifdef CONFIG_SPL_BUILD
 void sunxi_board_init(void)
 {
-   int power_failed = 0;
unsigned long ramsize;
 
printf(DRAM:);
@@ -91,14 +90,5 @@ void sunxi_board_init(void)
printf( %lu MiB\n, ramsize  20);
if (!ramsize)
hang();
-
-   /*
-* Only clock up the CPU to full speed if we are reasonably
-* assured it's being powered with suitable core voltage
-*/
-   if (!power_failed)
-   clock_set_pll1(91200);
-   else
-   printf(Failed to set core voltage! Can't set CPU frequency\n);
 }
 #endif
-- 
1.9.0

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] [PATCH u-boot sunxi 4/4] sunxi: Add sun4i support

2014-03-16 Thread Hans de Goede
Signed-off-by: Hans de Goede hdego...@redhat.com
---
 arch/arm/cpu/armv7/sunxi/board.c|   2 +-
 arch/arm/cpu/armv7/sunxi/clock.c|   2 +
 arch/arm/cpu/armv7/sunxi/cpu_info.c |   7 ++
 arch/arm/cpu/armv7/sunxi/dram.c | 129 
 board/sunxi/Makefile|   3 +-
 board/sunxi/dram_a10_olinuxino_l.c  |  31 +
 boards.cfg  |   1 +
 drivers/mmc/sunxi_mmc.c |  10 +++
 include/configs/sun4i.h |  40 +++
 9 files changed, 223 insertions(+), 2 deletions(-)
 create mode 100644 board/sunxi/dram_a10_olinuxino_l.c
 create mode 100644 include/configs/sun4i.h

diff --git a/arch/arm/cpu/armv7/sunxi/board.c b/arch/arm/cpu/armv7/sunxi/board.c
index 2668d52..2225e31 100644
--- a/arch/arm/cpu/armv7/sunxi/board.c
+++ b/arch/arm/cpu/armv7/sunxi/board.c
@@ -82,7 +82,7 @@ void reset_cpu(ulong addr)
 /* do some early init */
 void s_init(void)
 {
-#if !defined CONFIG_SPL_BUILD
+#if !defined CONFIG_SPL_BUILD  defined CONFIG_SUN7I
/* Enable SMP mode for CPU0, by setting bit 6 of Auxiliary Ctl reg */
asm volatile(
mrc p15, 0, r0, c1, c0, 1\n
diff --git a/arch/arm/cpu/armv7/sunxi/clock.c b/arch/arm/cpu/armv7/sunxi/clock.c
index e3abaf0..f685dda 100644
--- a/arch/arm/cpu/armv7/sunxi/clock.c
+++ b/arch/arm/cpu/armv7/sunxi/clock.c
@@ -43,8 +43,10 @@ static void clock_init_safe(void)
sdelay(200);
writel(AXI_DIV_1  0 | AHB_DIV_2  4 | APB0_DIV_1  8 |
   CPU_CLK_SRC_PLL1  16, ccm-cpu_ahb_apb0_cfg);
+#ifdef CONFIG_SUN7I
writel(0x1  6 | readl(ccm-ahb_gate0), ccm-ahb_gate0);
writel(0x1  31 | readl(ccm-pll6_cfg), ccm-pll6_cfg);
+#endif
 }
 #endif
 
diff --git a/arch/arm/cpu/armv7/sunxi/cpu_info.c 
b/arch/arm/cpu/armv7/sunxi/cpu_info.c
index 14093dd..31c9f96 100644
--- a/arch/arm/cpu/armv7/sunxi/cpu_info.c
+++ b/arch/arm/cpu/armv7/sunxi/cpu_info.c
@@ -29,7 +29,14 @@
 #ifdef CONFIG_DISPLAY_CPUINFO
 int print_cpuinfo(void)
 {
+#ifdef CONFIG_SUN4I
+   puts(CPU:   Allwinner A10 (SUN4I)\n);
+#elif defined CONFIG_SUN7I
puts(CPU:   Allwinner A20 (SUN7I)\n);
+#else
+#warning Please update cpu_info.c with correct CPU information
+   puts(CPU:   SUNXI Family\n);
+#endif
return 0;
 }
 #endif
diff --git a/arch/arm/cpu/armv7/sunxi/dram.c b/arch/arm/cpu/armv7/sunxi/dram.c
index c34322d..08db987 100644
--- a/arch/arm/cpu/armv7/sunxi/dram.c
+++ b/arch/arm/cpu/armv7/sunxi/dram.c
@@ -49,6 +49,21 @@ static void mctl_ddr3_reset(void)
struct sunxi_dram_reg *dram =
(struct sunxi_dram_reg *)SUNXI_DRAMC_BASE;
 
+#ifdef CONFIG_SUN4I
+   struct sunxi_timer_reg *timer =
+   (struct sunxi_timer_reg *)SUNXI_TIMER_BASE;
+   u32 reg_val;
+
+   writel(0, timer-cpu_cfg);
+   reg_val = readl(timer-cpu_cfg);
+
+   if ((reg_val  CPU_CFG_CHIP_VER_MASK) !=
+   CPU_CFG_CHIP_VER(CPU_CFG_CHIP_REV_A)) {
+   setbits_le32(dram-mcr, DRAM_MCR_RESET);
+   udelay(2);
+   clrbits_le32(dram-mcr, DRAM_MCR_RESET);
+   } else
+#endif
{
clrbits_le32(dram-mcr, DRAM_MCR_RESET);
udelay(2);
@@ -60,7 +75,11 @@ static void mctl_set_drive(void)
 {
struct sunxi_dram_reg *dram = (struct sunxi_dram_reg *)SUNXI_DRAMC_BASE;
 
+#ifdef CONFIG_SUN7I
clrsetbits_le32(dram-mcr, DRAM_MCR_MODE_NORM(0x3) | (0x3  28),
+#else
+   clrsetbits_le32(dram-mcr, DRAM_MCR_MODE_NORM(0x3),
+#endif
DRAM_MCR_MODE_EN(0x3) |
0xffc);
 }
@@ -112,7 +131,11 @@ static void mctl_enable_dllx(u32 phase)
n = DRAM_DCR_NR_DLLCR_16BIT;
 
for (i = 1; i  n; i++) {
+#ifdef CONFIG_SUN7I
clrsetbits_le32(dram-dllcr[i], 0xf  14,
+#else
+   clrsetbits_le32(dram-dllcr[i], 0x4  14,
+#endif
(phase  0xf)  14);
clrsetbits_le32(dram-dllcr[i], DRAM_DLLCR_NRESET,
DRAM_DLLCR_DISABLE);
@@ -132,6 +155,17 @@ static void mctl_enable_dllx(u32 phase)
 }
 
 static u32 hpcr_value[32] = {
+#ifdef CONFIG_SUN4I
+   0x0301, 0x0301, 0x0301, 0x0301,
+   0x0301, 0x0301, 0, 0,
+   0, 0, 0, 0,
+   0, 0, 0, 0,
+   0x1031, 0x1031, 0x0735, 0x1035,
+   0x1035, 0x0731, 0x1031, 0x0735,
+   0x1035, 0x1031, 0x0731, 0x1035,
+   0x1031, 0x0301, 0x0301, 0x0731
+#endif
+#ifdef CONFIG_SUN7I
0x0301, 0x0301, 0x0301, 0x0301,
0x0301, 0x0301, 0x0301, 0x0301,
0, 0, 0, 0,
@@ -145,6 +179,7 @@ static u32 hpcr_value[32] = {
 * but boot0 code skips #28 and #30, and sets #29 and #31 to the
 * value from #28 entry (0x1031)
  */
+#endif
 };
 
 static void mctl_configure_hostport(void)
@@ -186,20 +221,34 @@ static void mctl_setup_dram_clock(u32 clk)
 
/* setup MBUS clock */
reg_val = CCM_MBUS_CTRL_GATE |
+#if defined(CONFIG_SUN7I)
  

[linux-sunxi] [PATCH u-boot sunxi 2/4] sunxi: FIXUP: sunxi: initial sun7i dram setup support

2014-03-16 Thread Hans de Goede
mctl_ddr3_reset() should not be called here for sun7i, at least the
u-boot-sunxi sources don't do this.

Signed-off-by: Hans de Goede hdego...@redhat.com
---
 arch/arm/cpu/armv7/sunxi/dram.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/cpu/armv7/sunxi/dram.c b/arch/arm/cpu/armv7/sunxi/dram.c
index 81b1f50..c34322d 100644
--- a/arch/arm/cpu/armv7/sunxi/dram.c
+++ b/arch/arm/cpu/armv7/sunxi/dram.c
@@ -373,7 +373,6 @@ unsigned long dramc_init(struct dram_para *para)
mctl_setup_dram_clock(para-clock);
 
/* reset external DRAM */
-   mctl_ddr3_reset();
mctl_set_drive();
 
/* dram clock off */
-- 
1.9.0

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [U-Boot] [linux-sunxi] [PATCH v1 9/9] sunxi: add gmac Ethernet support

2014-03-16 Thread Ian Campbell
On Fri, 2014-03-14 at 10:22 -0400, Tom Rini wrote:
 On Fri, Mar 14, 2014 at 11:28:06AM +, Ian Campbell wrote:
  On Fri, 2014-03-14 at 19:11 +0800, Chen-Yu Tsai wrote:
 [snip]
   I think you should keep them in the same patch. You can then
   just add the appropriate config options when support of other A20
   boards roll in.
  
  I don't have any boards which require this, so I cannot test it. I'd
  prefer to leave it to whoever adds support for the first such board to
  put this stuff back in, it's a pretty trivial git diff invocation to
  spot the needed bits.
 
 I agree with this as well.

With the request to add RGMII here or my reasons for not doing so?
(sorry if I'm being dense)

Ian.


-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [linux-sunxi] [PATCH 3.4] sunxi:axp20x: Enable internal thermal monitoring

2014-03-16 Thread Alejandro Mery

Hi,

On 11/03/14 05:31, Patrick Wood wrote:



On Sunday, March 9, 2014 10:13:08 AM UTC-4, Alejandro Mery wrote:



On 09/03/14 13:09, Olliver Schinagl wrote:
  Mnemoc,
 
  have you checked and merged this yet?

thanks for the reminder. it fails to compile when hwmon is m

like on sun7i_defconfig:
LD  .tmp_vmlinux1
drivers/built-in.o: In function `axp20_init_chip':

/srv/build/amery/allwinner/linux-sunxi/3.4/drivers/power/axp_power/axp20-mfd.h:149:

undefined reference to `hwmon_device_register'
drivers/built-in.o: In function `axp_mfd_remove':

/srv/build/amery/allwinner/linux-sunxi/3.4/drivers/power/axp_power/axp-mfd.c:368:

undefined reference to `hwmon_device_unregister'
make[1]: *** [.tmp_vmlinux1] Error 1
make: *** [sub-make] Error 2

build_sun7i/.config:CONFIG_AXP_HWMON=y
build_sun7i/.config:CONFIG_HWMON=m

in most defconfigs hwmon is n, should I y/y them on all defconfigs? can
it be fixed to support hwmon=m?


Try this:

diff --git a/drivers/power/axp_power/Kconfig
b/drivers/power/axp_power/Kconfig
index 66aa6ac..4e942a9 100644
--- a/drivers/power/axp_power/Kconfig
+++ b/drivers/power/axp_power/Kconfig
@@ -38,7 +38,7 @@ config AXP_CHGCHANGE
  config AXP_HWMON
 depends on HWMON
-   bool Enable the internal thermal monitoring support of AXP20X
chips
+   tristate Enable the internal thermal monitoring support of
AXP20X chips
 default y
  endif # !AW_AXP


yes, that solved the problem. what about defconfig? m/m? y/y?

regards,
Alejandro Mery

--
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] Re: [U-Boot] [PATCH v1 8/9] sunxi: non-FEL SPL boot support for sun7i

2014-03-16 Thread Ian Campbell
On Sun, 2014-03-16 at 15:19 +, Ian Campbell wrote:
 On Fri, 2014-03-14 at 15:03 -0400, Tom Rini wrote:
  On 03/14/2014 02:50 PM, Hans de Goede wrote:
   Hi,
   
   On 03/14/2014 03:17 PM, Tom Rini wrote:
   On Fri, Mar 14, 2014 at 10:33:50AM +, Ian Campbell wrote:
  
   Based linux-sunxi#sunxi commit d854c4de2f57 arm: Handle .gnu.hash 
   section in
   ldscripts vs v2014.01.
   [snip]
   +/* Flat Device Tree (FDT/DT) support */
   +#define CONFIG_OF_LIBFDT
   +#define CONFIG_SYS_BOOTMAPSZ   (16  20)
  
   This seems pretty small.  This is to keep things from being relocated
   into highmem right?
   
   Hmm, this reminds me that we currently need to do a env set fdt_high 
   
   in our boot scripts to get ftd to work at all. Would be nice to fix this 
   for
   upstream. I'm afraid I'm clueless as to why we (sunxi) need it, but we do.
  
  You want to be setting bootm_low (even for bootz, it's about the
  underlying boot mechanics that bootz and bootelf and ... hook into) to
  the amount of lowmem the kernel will have.  We do this because we do
  want to make sure that the device tree isn't overwritten by the kernel
  BSS or similar.  Everyone with more DDR than kernel lowmem needs to be
  doing something along these lines.
 
 So, I'm confused about what to do here ;-)
 
 AFAICS none of the existing platforms in u-boot.git are setting
 bootm_low in their default environment.
 
 README suggests that bootm_low is the lowest address allowed for use by
 bootm/z rather than the limit, from the docs it seems that
 CONFIG_SYS_BOOTMAPSZ (overridden by env bootm_mapsize) is the limit
 
 bootm_low defaults to CONFIG_SYS_SDRAM_BASE, which sunxi sets, and this
 seems logical to me since kernel's lowmem mapping starts at offset 0
 into RAM.
 
 I think we probably do want to set BOOTMAPSZ to something like 256MB,
 which seems to be the highest in tree (although the vast majority use
 8MB...). But I'm not sure that explains why fdt_high is needed today.
 I'll have a play.

So setting BOOTMAPSZ to e.g. 256MB limits the fdt load address as you
would expect.

But it seems to not make any difference for the initramfs which still
gets loaded to the top of RAM. This is consistent with README which says
that unless initrd_high is set the ramdisk will be loaded as high as
possible, without reference to BOOTMAPSZ. Supposedly setting initrd_high
to no, off or 0 should cause initrd relocation to obey BOOTMAPSZ
-- but at least in my experiments it does not seem to do so.

boot_ramdisk_high() doesn't seem to make any reference to
bootm_{low,size,etc} like I would expect and with initrd_high==0 it
calls lmb_alloc which allocates anywhere. This is in contrast with
boot_relocate_fdt which uses getenv_bootm_mapsize() and
getenv_bootm_low().

It looks to me like the initrd reloc logic is wrong -- but it's been
that way for such a long time I think I must be mistaken.

Ian.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] [PATCH 2/9] sunxi: define bit shifts for CPU_AHB_APB0_CFG_REG

2014-03-16 Thread Ian Campbell
Signed-off-by: Ian Campbell i...@hellion.org.uk
---
 arch/arm/cpu/armv7/sunxi/clock.c| 31 +++
 arch/arm/include/asm/arch-sunxi/clock.h |  8 ++--
 2 files changed, 29 insertions(+), 10 deletions(-)

diff --git a/arch/arm/cpu/armv7/sunxi/clock.c b/arch/arm/cpu/armv7/sunxi/clock.c
index f7eb37b..54d801c 100644
--- a/arch/arm/cpu/armv7/sunxi/clock.c
+++ b/arch/arm/cpu/armv7/sunxi/clock.c
@@ -21,12 +21,18 @@ static void clock_init_safe(void)
(struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
 
/* Set safe defaults until PMU is configured */
-   writel(AXI_DIV_1  0 | AHB_DIV_2  4 | APB0_DIV_1  8 |
-  CPU_CLK_SRC_OSC24M  16, ccm-cpu_ahb_apb0_cfg);
+   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);
writel(0xa1005000, ccm-pll1_cfg);
sdelay(200);
-   writel(AXI_DIV_1  0 | AHB_DIV_2  4 | APB0_DIV_1  8 |
-  CPU_CLK_SRC_PLL1  16, ccm-cpu_ahb_apb0_cfg);
+   writel(AXI_DIV_1  AXI_DIV_SHIFT |
+  AHB_DIV_2  AHB_DIV_SHIFT |
+  APB0_DIV_1  APB0_DIV_SHIFT |
+  CPU_CLK_SRC_PLL1  CPU_CLK_SRC_SHIFT,
+  ccm-cpu_ahb_apb0_cfg);
 #ifdef CONFIG_SUN5I
/* Power on reset default for PLL6 is 2400 MHz, which is faster then
 * it can reliable do :|  Set it to a 600 MHz instead. */
@@ -158,12 +164,18 @@ void clock_set_pll1(int hz)
apb0 = apb0 - 1;
 
/* Switch to 24MHz clock while changing PLL1 */
-   writel(AXI_DIV_1  0 | AHB_DIV_2  4 | APB0_DIV_1  8 |
-  CPU_CLK_SRC_OSC24M  16, ccm-cpu_ahb_apb0_cfg);
+   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);
 
/* Configure sys clock divisors */
-   writel(axi  0 | ahb  4 | apb0  8 | CPU_CLK_SRC_OSC24M  16,
+   writel(axi  AXI_DIV_SHIFT |
+  ahb  AHB_DIV_SHIFT |
+  apb0  APB0_DIV_SHIFT |
+  CPU_CLK_SRC_OSC24M  CPU_CLK_SRC_SHIFT,
   ccm-cpu_ahb_apb0_cfg);
 
/* Configure PLL1 at the desired frequency */
@@ -171,7 +183,10 @@ void clock_set_pll1(int hz)
sdelay(200);
 
/* Switch CPU to PLL1 */
-   writel(axi  0 | ahb  4 | apb0  8 | CPU_CLK_SRC_PLL1  16,
+   writel(axi  AXI_DIV_SHIFT |
+  ahb  AHB_DIV_SHIFT |
+  apb0  APB0_DIV_SHIFT |
+  CPU_CLK_SRC_PLL1  CPU_CLK_SRC_SHIFT,
   ccm-cpu_ahb_apb0_cfg);
sdelay(20);
 }
diff --git a/arch/arm/include/asm/arch-sunxi/clock.h 
b/arch/arm/include/asm/arch-sunxi/clock.h
index 8ca2066..533f9b5 100644
--- a/arch/arm/include/asm/arch-sunxi/clock.h
+++ b/arch/arm/include/asm/arch-sunxi/clock.h
@@ -98,20 +98,24 @@ struct sunxi_ccm_reg {
 #define APB1_FACTOR_N  0
 
 /* clock divide */
-#define CPU_CLK_SRC_OSC24M 1
-#define CPU_CLK_SRC_PLL1   2
+#define AXI_DIV_SHIFT  (0)
 #define AXI_DIV_1  0
 #define AXI_DIV_2  1
 #define AXI_DIV_3  2
 #define AXI_DIV_4  3
+#define AHB_DIV_SHIFT  (4)
 #define AHB_DIV_1  0
 #define AHB_DIV_2  1
 #define AHB_DIV_4  2
 #define AHB_DIV_8  3
+#define APB0_DIV_SHIFT (8)
 #define APB0_DIV_1 0
 #define APB0_DIV_2 1
 #define APB0_DIV_4 2
 #define APB0_DIV_8 3
+#define CPU_CLK_SRC_SHIFT  (16)
+#define CPU_CLK_SRC_OSC24M 1
+#define CPU_CLK_SRC_PLL1   2
 
 #ifdef CONFIG_SUN5I
 #define AHB_CLK_SRC_AXI0
-- 
1.8.5.3

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] [PATCH 7/9] sunxi: configuration updates

2014-03-16 Thread Ian Campbell
Based on feedback from Tom Rini:
 - drop unnecessary CONFIG_SYS_PROMPT_HUSH_PS2
 - drop deprecated mtest settings
 - use generic baud rate table

Signed-off-by: Ian Campbell i...@hellion.org.uk
---
 include/configs/sunxi-common.h | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
index 81ac6f7..292a938 100644
--- a/include/configs/sunxi-common.h
+++ b/include/configs/sunxi-common.h
@@ -110,7 +110,6 @@
 #define CONFIG_SYS_LONGHELP/* undef to save memory */
 #define CONFIG_SYS_HUSH_PARSER /* use hush command parser*/
 #define CONFIG_CMD_ECHO
-#define CONFIG_SYS_PROMPT_HUSH_PS2  
 #define CONFIG_SYS_CBSIZE  256 /* Console I/O Buffer Size */
 #define CONFIG_SYS_PBSIZE  384 /* Print Buffer Size */
 #define CONFIG_SYS_MAXARGS 16  /* max number of command args */
@@ -118,9 +117,6 @@
 /* Boot Argument Buffer Size */
 #define CONFIG_SYS_BARGSIZECONFIG_SYS_CBSIZE
 
-/* memtest works on */
-#define CONFIG_SYS_MEMTEST_START   CONFIG_SYS_SDRAM_BASE
-#define CONFIG_SYS_MEMTEST_END (CONFIG_SYS_SDRAM_BASE + (256  20))
 #define CONFIG_SYS_LOAD_ADDR   0x5000 /* default load address */
 
 /* standalone support */
@@ -128,9 +124,8 @@
 
 #define CONFIG_SYS_HZ  1000
 
-/* valid baudrates */
+/* baudrate */
 #define CONFIG_BAUDRATE115200
-#define CONFIG_SYS_BAUDRATE_TABLE  { 9600, 19200, 38400, 57600, 115200 }
 
 /* The stack sizes are set up in start.S using the settings below */
 #define CONFIG_STACKSIZE   (256  10) /* 256 KiB */
-- 
1.8.5.3

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] [PATCH 9/9] sunxi: remove key driver

2014-03-16 Thread Ian Campbell
This code hasn't been called since the calls to it randomly disappeared in
71e6be0ccbd5 sunxi: get u-boot mmc spl work and 4d29a5dd7414 sunxi: further
clean sunxi platform. It seems to have only ever been used as test code anyway.

Signed-off-by: Ian Campbell i...@hellion.org.uk
---
 arch/arm/cpu/armv7/sunxi/Makefile |  1 -
 arch/arm/cpu/armv7/sunxi/key.c| 54 ---
 arch/arm/include/asm/arch-sunxi/key.h | 37 
 3 files changed, 92 deletions(-)
 delete mode 100644 arch/arm/cpu/armv7/sunxi/key.c
 delete mode 100644 arch/arm/include/asm/arch-sunxi/key.h

diff --git a/arch/arm/cpu/armv7/sunxi/Makefile 
b/arch/arm/cpu/armv7/sunxi/Makefile
index e6d8fa9..83b7c1a 100644
--- a/arch/arm/cpu/armv7/sunxi/Makefile
+++ b/arch/arm/cpu/armv7/sunxi/Makefile
@@ -21,7 +21,6 @@ obj-$(CONFIG_SYS_SECONDARY_ON)+= secondary_init.o
 obj-$(CONFIG_SYS_SECONDARY_ON) += smp.o
 
 ifndef CONFIG_SPL_BUILD
-obj-y  += key.o
 obj-y  += cpu_info.o
 ifdef CONFIG_CMD_WATCHDOG
 obj-$(CONFIG_CMD_WATCHDOG) += cmd_watchdog.o
diff --git a/arch/arm/cpu/armv7/sunxi/key.c b/arch/arm/cpu/armv7/sunxi/key.c
deleted file mode 100644
index fcdabd3..000
--- a/arch/arm/cpu/armv7/sunxi/key.c
+++ /dev/null
@@ -1,54 +0,0 @@
-/*
- * (C) Copyright 2007-2011
- * Allwinner Technology Co., Ltd. www.allwinnertech.com
- * Tom Cubie tangli...@allwinnertech.com
- *
- * SPDX-License-Identifier:GPL-2.0+
- */
-
-#include common.h
-#include asm/io.h
-#include asm/arch/cpu.h
-#include asm/arch/key.h
-#include asm/arch/sys_proto.h
-
-int sunxi_key_init(void)
-{
-   struct sunxi_lradc *sunxi_key_base =
-   (struct sunxi_lradc *)SUNXI_LRADC_BASE;
-
-   sr32(sunxi_key_base-ctrl, 0, 1, LRADC_EN);
-   sr32(sunxi_key_base-ctrl, 2, 2, LRADC_SAMPLE_RATE);
-   sr32(sunxi_key_base-ctrl, 4, 2, LEVELB_VOL);
-   sr32(sunxi_key_base-ctrl, 6, 1, LRADC_HOLD_EN);
-   sr32(sunxi_key_base-ctrl, 12, 2, KEY_MODE_SELECT);
-
-   /* disable all key irq */
-   writel(0x0, sunxi_key_base-intc);
-   /* clear all key pending */
-   writel(0x, sunxi_key_base-ints);
-
-   return 0;
-}
-
-u32 sunxi_read_key(void)
-{
-   u32 ints;
-   u32 key = 0;
-   struct sunxi_lradc *sunxi_key_base =
-   (struct sunxi_lradc *)SUNXI_LRADC_BASE;
-
-   ints = readl(sunxi_key_base-ints);
-
-   /* if there is already data pending,
-read it */
-   if (ints  ADC0_DATA_PENDING) {
-   key = readl(sunxi_key_base-data0);
-#ifdef DEBUG
-   printf(key pressed, value=0x%x\n, key);
-#endif
-   }
-   /* clear the pending data */
-   writel(ints, sunxi_key_base-ints);
-   return key;
-}
diff --git a/arch/arm/include/asm/arch-sunxi/key.h 
b/arch/arm/include/asm/arch-sunxi/key.h
deleted file mode 100644
index b2e1faa..000
--- a/arch/arm/include/asm/arch-sunxi/key.h
+++ /dev/null
@@ -1,37 +0,0 @@
-/*
- * (C) Copyright 2007-2011
- * Allwinner Technology Co., Ltd. www.allwinnertech.com
- * Tom Cubie tangli...@allwinnertech.com
- *
- * SPDX-License-Identifier:GPL-2.0+
- */
-
-#ifndef _SUNXI_KEY_H
-#define _SUNXI_KEY_H
-
-#include linux/types.h
-
-struct sunxi_lradc {
-   u32 ctrl; /* lradc control */
-   u32 intc; /* interrupt control */
-   u32 ints; /* interrupt status */
-   u32 data0;/* lradc 0 data */
-   u32 data1;/* lradc 1 data */
-};
-
-#define LRADC_EN  0x1/* LRADC enable */
-#define LRADC_SAMPLE_RATE 0x2/* 32.25 Hz */
-#define LEVELB_VOL0x2/* 0x33(~1.6v) */
-#define LRADC_HOLD_EN 0x1/* sample hold enable */
-#define KEY_MODE_SELECT   0x0/* normal mode */
-
-#define ADC0_DATA_PENDING (0x1  0)/* adc0 has data */
-#define ADC0_KEYDOWN_PENDING  (0x1  1)/* key down */
-#define ADC0_HOLDKEY_PENDING  (0x1  2)/* key hold */
-#define ADC0_ALRDY_HOLD_PENDING   (0x1  3)/* key already hold */
-#define ADC0_KEYUP_PENDING(0x1  4)/* key up */
-
-int sunxi_key_init(void);
-u32 sunxi_read_key(void);
-
-#endif
-- 
1.8.5.3

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] [PATCH 1/9] sunxi: simplify get_tbclk

2014-03-16 Thread Ian Campbell
Signed-off-by: Ian Campbell i...@hellion.org.uk
---
 arch/arm/cpu/armv7/sunxi/timer.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/arch/arm/cpu/armv7/sunxi/timer.c b/arch/arm/cpu/armv7/sunxi/timer.c
index d21289a..d0d9953 100644
--- a/arch/arm/cpu/armv7/sunxi/timer.c
+++ b/arch/arm/cpu/armv7/sunxi/timer.c
@@ -98,7 +98,5 @@ unsigned long long get_ticks(void)
  */
 ulong get_tbclk(void)
 {
-   ulong tbclk;
-   tbclk = CONFIG_SYS_HZ;
-   return tbclk;
+   return CONFIG_SYS_HZ;
 }
-- 
1.8.5.3

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] [PATCH 8/9] sunxi: Increase CONFIG_SYS_BOOTMAPSZ to 256MB

2014-03-16 Thread Ian Campbell
This value is supposed to reflect the lowmem mapping of the kernel. The
existing 16MB is clearly much to small for this. 256MB is likely to still be an
underestimate but is a reasonable, if conservative, value.

Signed-off-by: Ian Campbell i...@hellion.org.uk
---
 include/configs/sunxi-common.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
index 292a938..2cd169a 100644
--- a/include/configs/sunxi-common.h
+++ b/include/configs/sunxi-common.h
@@ -102,7 +102,7 @@
 
 /* Flat Device Tree (FDT/DT) support */
 #define CONFIG_OF_LIBFDT
-#define CONFIG_SYS_BOOTMAPSZ   (16  20)
+#define CONFIG_SYS_BOOTMAPSZ   (256  20)
 
 /*
  * Miscellaneous configurable options
-- 
1.8.5.3

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] [PATCH 5/9] sunxi: clock_set_pll1 takes Hz not MHz

2014-03-16 Thread Ian Campbell
This was only wrong in the prototype.

Signed-off-by: Ian Campbell i...@hellion.org.uk
---
 arch/arm/include/asm/arch-sunxi/clock.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/arch-sunxi/clock.h 
b/arch/arm/include/asm/arch-sunxi/clock.h
index dc8c371..b6184dc 100644
--- a/arch/arm/include/asm/arch-sunxi/clock.h
+++ b/arch/arm/include/asm/arch-sunxi/clock.h
@@ -232,7 +232,7 @@ struct sunxi_ccm_reg {
 #ifndef __ASSEMBLY__
 int clock_init(void);
 int clock_twi_onoff(int port, int state);
-void clock_set_pll1(int mhz);
+void clock_set_pll1(int hz);
 unsigned int clock_get_pll5(void);
 #endif
 
-- 
1.8.5.3

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] [PATCH 3/9] sunxi: #define default values and shifts for pll cfg registers

2014-03-16 Thread Ian Campbell
Signed-off-by: Ian Campbell i...@hellion.org.uk
---
 arch/arm/cpu/armv7/sunxi/clock.c| 10 ++
 arch/arm/include/asm/arch-sunxi/clock.h |  9 +
 2 files changed, 15 insertions(+), 4 deletions(-)

diff --git a/arch/arm/cpu/armv7/sunxi/clock.c b/arch/arm/cpu/armv7/sunxi/clock.c
index 54d801c..980fb90 100644
--- a/arch/arm/cpu/armv7/sunxi/clock.c
+++ b/arch/arm/cpu/armv7/sunxi/clock.c
@@ -26,7 +26,7 @@ static void clock_init_safe(void)
   APB0_DIV_1  APB0_DIV_SHIFT |
   CPU_CLK_SRC_OSC24M  CPU_CLK_SRC_SHIFT,
   ccm-cpu_ahb_apb0_cfg);
-   writel(0xa1005000, ccm-pll1_cfg);
+   writel(PLL1_CFG_DEFAULT, ccm-pll1_cfg);
sdelay(200);
writel(AXI_DIV_1  AXI_DIV_SHIFT |
   AHB_DIV_2  AHB_DIV_SHIFT |
@@ -36,11 +36,13 @@ static void clock_init_safe(void)
 #ifdef CONFIG_SUN5I
/* Power on reset default for PLL6 is 2400 MHz, which is faster then
 * it can reliable do :|  Set it to a 600 MHz instead. */
-   writel(0x21009911, ccm-pll6_cfg);
+   writel(PLL6_CFG_DEFAULT, ccm-pll6_cfg);
 #endif
 #ifdef CONFIG_SUN7I
-   writel(0x1  6 | readl(ccm-ahb_gate0), ccm-ahb_gate0);
-   writel(0x1  31 | readl(ccm-pll6_cfg), ccm-pll6_cfg);
+   writel(0x1  AHB_GATE_OFFSET_DMA | readl(ccm-ahb_gate0),
+  ccm-ahb_gate0);
+   writel(0x1  PLL6_ENABLE_OFFSET | readl(ccm-pll6_cfg),
+  ccm-pll6_cfg);
 #endif
 }
 #endif
diff --git a/arch/arm/include/asm/arch-sunxi/clock.h 
b/arch/arm/include/asm/arch-sunxi/clock.h
index 533f9b5..dc8c371 100644
--- a/arch/arm/include/asm/arch-sunxi/clock.h
+++ b/arch/arm/include/asm/arch-sunxi/clock.h
@@ -117,6 +117,15 @@ struct sunxi_ccm_reg {
 #define CPU_CLK_SRC_OSC24M 1
 #define CPU_CLK_SRC_PLL1   2
 
+#define PLL1_CFG_DEFAULT   0xa1005000
+
+#ifdef CONFIG_SUN5I
+#define PLL6_CFG_DEFAULT   0x21009911
+#endif
+#ifdef CONFIG_SUN7I
+#define PLL6_ENABLE_OFFSET 31
+#endif
+
 #ifdef CONFIG_SUN5I
 #define AHB_CLK_SRC_AXI0
 #endif
-- 
1.8.5.3

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] Re: [PATCH u-boot sunxi 2/4] sunxi: FIXUP: sunxi: initial sun7i dram setup support

2014-03-16 Thread Ian Campbell
On Sun, 2014-03-16 at 14:53 +0100, Hans de Goede wrote:
 mctl_ddr3_reset() should not be called here for sun7i, at least the
 u-boot-sunxi sources don't do this.

oops, I misread an ifndef. I'll fold in, thanks.

Ian.


-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] Re: [PATCH u-boot sunxi 3/4] sunxi: Implement reset_cpu

2014-03-16 Thread Ian Campbell
On Sun, 2014-03-16 at 14:53 +0100, Hans de Goede wrote:
 There is no way to reset the cpu, so use the watchdog for this.

The sunxi.git tree does this by calling watchdog_set(0). I think it
would be better to introduce the generic watchdog support and the add
this a patch to use it for reset. Unless we don't plan to upstream the
watchdog stuff for some reason?

Not sure why cmd_watchdog.c is sunxi, seems like in principal it could
be generic.

Ian.

 Signed-off-by: Hans de Goede hdego...@redhat.com
 ---
  arch/arm/cpu/armv7/sunxi/board.c| 7 +++
  arch/arm/include/asm/arch-sunxi/timer.h | 4 
  2 files changed, 11 insertions(+)
 
 diff --git a/arch/arm/cpu/armv7/sunxi/board.c 
 b/arch/arm/cpu/armv7/sunxi/board.c
 index 98cad43..2668d52 100644
 --- a/arch/arm/cpu/armv7/sunxi/board.c
 +++ b/arch/arm/cpu/armv7/sunxi/board.c
 @@ -70,6 +70,13 @@ int gpio_init(void)
  
  void reset_cpu(ulong addr)
  {
 + static const struct sunxi_wdog *wdog =
 +  ((struct sunxi_timer_reg *)SUNXI_TIMER_BASE)-wdog;
 +
 + /* Set the watchdog for its shortest interval (.5s) and wait */
 + writel(WDT_MODE_RESET_EN | WDT_MODE_EN, wdog-mode);
 + writel(WDT_CTRL_RESTART, wdog-ctl);
 + while (1);
  }
  
  /* do some early init */
 diff --git a/arch/arm/include/asm/arch-sunxi/timer.h 
 b/arch/arm/include/asm/arch-sunxi/timer.h
 index f9d4f4f..1489b2e 100644
 --- a/arch/arm/include/asm/arch-sunxi/timer.h
 +++ b/arch/arm/include/asm/arch-sunxi/timer.h
 @@ -27,6 +27,10 @@
  #ifndef _SUNXI_TIMER_H_
  #define _SUNXI_TIMER_H_
  
 +#define WDT_CTRL_RESTART(0x1  0)
 +#define WDT_MODE_EN (0x1  0)
 +#define WDT_MODE_RESET_EN   (0x1  1)
 +
  #ifndef __ASSEMBLY__
  
  #include linux/types.h


-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] Re: [PATCH+GIT 0/9] sunxi: upstream review based cleanups

2014-03-16 Thread Hans de Goede
Hi Ian,

On 03/16/2014 06:33 PM, Ian Campbell wrote:
 Hi,
 
 The following series implements some of the cleanups requested as part
 of the upstream review process (mostly the lower hanging fruit). This is
 against sunxi.git not the upstream u-boot.git (should I cc upstream
 here? I decided not but maybe other think I should).
 
 There's one extra patch sunxi: remove key driver which wasn't due to
 upstream comment but just removes something which isn't useful (or even
 used) to reduce the upstream diff a bit more.
 
 Lastly I've merged upstream v2014.04-rc2 onto this series and pushed the
 entire result to:
 
 git://gitorious.org/ijc/u-boot.git sunxi-mainlining-cleanups
 
 The majority of the conflicts were due to the upstream build system
 changes (to use Kbuild) and the use of phylib for designware (Wens, if
 you could double check what I've done that would be great).
 
 Keeping up to date with upstream should make the upstreaming easier to
 manage.
 
 I've tested this on sun7i Cubieboard2 with both FEL and SD card boot.

Thanks I've added the 9 patches to the u-boot-sunxi repo sunxi branch,
as for the merge with v2014.04-rc2, I would like to wait what HNO has
to say about that.

Regards,

Hans

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] Re: [PATCH+GIT 0/9] sunxi: upstream review based cleanups

2014-03-16 Thread Ian Campbell
On Sun, 2014-03-16 at 19:40 +0100, Hans de Goede wrote:
 Thanks I've added the 9 patches to the u-boot-sunxi repo sunxi branch,

Thanks.

 as for the merge with v2014.04-rc2, I would like to wait what HNO has
 to say about that.

I've rebased onto what you've now applied and force pushed the branch to
make this easier to pull if desired. The branch is still:
 git://gitorious.org/ijc/u-boot.git sunxi-mainlining-cleanups

Post v2014.04-rc2 I think there are two worthwhile updates which I've
noticed (but not implemented yet):
  * make mksunxiboot silent in the common case, with the new Kbuild
stuff it's output stands out a bit and isn't all that helpful
anyway.
  * Reenable DCACHE, now that the designware driver apparently no
longer conflicts.

Ian.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] Re: [U-Boot] [PATCH v1 7/9] sunxi: mmc support

2014-03-16 Thread Ian Campbell
On Fri, 2014-03-14 at 17:36 +0200, Pantelis Antoniou wrote:
 [...]

Thanks for your review. It seems there are still quite a few issues
dating back to the original allwinner dumps here.

@linux-sunxi: if anyone wants to volunteer to help cleanup this
particular driver I'd be very happy -- there's a lot of it!

 +
  +static void dumpmmcreg(struct sunxi_mmc *reg)
  +{
  +   debug(dump mmc registers:\n);
  +   debug(gctrl 0x%08x\n, reg-gctrl);
  +   debug(clkcr 0x%08x\n, reg-clkcr);
  +   debug(timeout   0x%08x\n, reg-timeout);
  +   debug(width 0x%08x\n, reg-width);
  +   debug(blksz 0x%08x\n, reg-blksz);
 [...] lots more debug(foo)
  +}
 
 ^^^ #ifdef DEBUG here?

I can if you prefer but debug() itself effectively includes the same
ifdef so the end result is already the same.

 [...]

  +/* support 4 mmc hosts */
  +struct mmc mmc_dev[4];
  +struct sunxi_mmc_host mmc_host[4];
  +
 
 ^ hosts  mmc structs can be allocated even for SPL now

Can be or must be?

  +   struct sunxi_mmc_host *mmchost = mmc_host[sdc_no];
  +   static struct sunxi_gpio *gpio_c =
  +   ((struct sunxi_gpio_reg *)SUNXI_PIO_BASE)-gpio_bank[SUNXI_GPIO_C];
  +   static struct sunxi_gpio *gpio_f =
  +   ((struct sunxi_gpio_reg *)SUNXI_PIO_BASE)-gpio_bank[SUNXI_GPIO_F];
  +#if CONFIG_MMC1_PG
  +   static struct sunxi_gpio *gpio_g =
  +   ((struct sunxi_gpio_reg *)SUNXI_PIO_BASE)-gpio_bank[SUNXI_GPIO_G];
  +#endif
  +   static struct sunxi_gpio *gpio_h =
  +   ((struct sunxi_gpio_reg *)SUNXI_PIO_BASE)-gpio_bank[SUNXI_GPIO_H];
  +   static struct sunxi_gpio *gpio_i =
  +   ((struct sunxi_gpio_reg *)SUNXI_PIO_BASE)-gpio_bank[SUNXI_GPIO_I];
  +   struct sunxi_ccm_reg *ccm = (struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
  +
 
 ^ Castings are ugly; rework with a temporary variable.

Ack.

The static's here are odd too and date back to the original alwinner
code dumps. I'll get rid of them too.

 [...]
  +   case 3:
  +   /* PI4-CMD, PI5-CLK, PI6~9-D0~D3 : 2 */
  +   writel(0x  16, gpio_i-cfg[0]);
  +   writel(0x22, gpio_i-cfg[1]);
  +   writel(0x555  8, gpio_i-pull[0]);
  +   writel(0x555  8, gpio_i-drv[0]);
  +   break;
  +
  +   default:
  +   return -1;
  +   }
  +
 
 Lots of magic constants. I have no idea what's going on here.
 Use a few defines.

Right. These came from the original allwinner dumps so I was worried
that they might be undocumented magic, but actually since the are gpio
frobbing I reckon I can figure them out.

 [...] +  cmd = (0x1  31) | (0x1  21) | (0x1  13);
  +   writel(cmd, mmchost-reg-cmd);
  +   while ((readl(mmchost-reg-cmd)  (0x1  31))  timeout--);
  +   if (!timeout)
  +   return -1;
  +
 
 ^ Eeek! Use udelay and a time based timeout. 

Ack.

  +   writel(readl(mmchost-reg-rint), mmchost-reg-rint);
  +
 
 ^ Same here - Not even a timeout?

No loop here though?
[...]

  +   rval |= (0x1  16);
 
 #define ?

Ack

[...]
 Ambiguous formatting. Use { }

Ack

 [...]
  +   /* Reset controller */
  +   writel(0x7, mmchost-reg-gctrl);
  +
 
 Magic value again.

The sum total of the docs for this one are:
 * GCTRLREG
 * GCTRL[2] : DMA reset
 * GCTRL[5] : DMA enable

But I'll see what I can do.

[...]
  +   } else {
  +   buff = (unsigned int *)data-src;
  +   for (i = 0; i  (byte_cnt  2); i++) {
  +   while (--timeout 
  +(readl(mmchost-reg-status)  (0x1  3)));
  +   if (timeout = 0)
  +   goto out;
  +   writel(buff[i], mmchost-database);
  +   timeout = 0xf;
  +   }
  +   }
  +
 
 ^ Timeouts using time values? udelay? See above.

Ack.

 []
  +   writel(rval, mmchost-reg-idie);
  +   writel((u32) pdes, mmchost-reg-dlba);
  +   writel((0x2  28) | (0x7  16) | (0x01  3),
  +  mmchost-reg-ftrglevel);
  +
 
 ^ #define again?

Some of these (ftrgllevel) have no docs whatsoever, but I'll do what I
can.

 [...]

  +   timeout = 0xf;
  +   do {
  +   status = readl(mmchost-reg-rint);
  +   if (!timeout-- || (status  0xbfc2)) {
  +   error = status  0xbfc2;
  +   debug(cmd timeout %x\n, error);
  +   error = TIMEOUT;
  +   goto out;
  +   }
 
 ^ Again timeouts without using time values.

I'm getting the picture ;-)

 [...]
  +int sunxi_mmc_init(int sdc_no)
  +{
  +   struct mmc *mmc;
  +
  +   memset(mmc_dev[sdc_no], 0, sizeof(struct mmc));
  +   memset(mmc_host[sdc_no], 0, sizeof(struct sunxi_mmc_host));
  +   mmc = mmc_dev[sdc_no];
  +
  +   sprintf(mmc-name, SUNXI SD/MMC);
  +   mmc-priv = mmc_host[sdc_no];
  +   mmc-send_cmd = mmc_send_cmd;
  +   mmc-set_ios = mmc_set_ios;
  +   mmc-init = mmc_core_init;
  +
  +   mmc-voltages = MMC_VDD_32_33 | MMC_VDD_33_34;
  +   mmc-host_caps = MMC_MODE_4BIT;
  +   mmc-host_caps |= MMC_MODE_HS_52MHz | MMC_MODE_HS;
  +
  + 

Re: [linux-sunxi] Re: gslx680 driver ported to sunxi

2014-03-16 Thread Joe Burmeister

On 14/03/14 15:36, selimte...@gmail.com wrote:

14 Mart 2014 Cuma 17:33:56 UTC+2 tarihinde selim...@gmail.com yazdı:

13 Mart 2014 Perşembe 14:22:52 UTC+2 tarihinde Joe Burmeister yazdı:


On 13/03/14 12:05, selimte...@gmail.com wrote:

13 Mart 2014 Perşembe 12:20:15 UTC+2 tarihinde Joe Burmeister yazdı:

On 13/03/14 09:52, selimte...@gmail.com wrote:

27 Ağustos 2013 Salı 22:14:14 UTC+3 tarihinde joe.a.bu...@gmail.com yazdı:

Hi,
For a while I've been working on getting my A13 tablet touch screen working 
with GNU/Linux.
It's now working well enough for my purposes and I figured it was time to push 
it out.
The code can be found at:
https://gitorious.org/gslx680-for-sunxi
It would be easy to move it in tree. What is a bit different from the other 
touch screen drivers is that it doesn't include the firmware in the driver.
I've split the firmware into a separate file that you name in the 
fex/script.bin file.
The reason for this is that the firmware defines things about the hardware such 
as resolution and can't be easily modified. So to support multiple devices 
you'd need multiple firmware included. Or your have to build for each 
driver+firmware combination. Better to have it a seperate file and which 
firmware be a configuration thing. That fits better to me with fex/script.bin 
or Device Tree. I've also added legacy single touch as well as multi touch.
Not sure where we go from here, but no point me sitting on it. ;-)
Joe


Hi,
I have a A13 tablet (just like this one -- 
http://moveontechnology.com/hugoenchina/?p=324)
and while trying to make touchscreen working I came acrross with this gslx680 
driver(https://gitorious.org/gslx680-for-sunxi)
I'm using sunxi-3.4 kernel and compiled the driver successfully for this 
kernel. My screen resolution is 800x480 so I'm using the firmware supplied by 
the source code.
I can successfully insmod the driver, got the successfull dmesg messages as expected, but 
when I try testing the driver with evtest tool, i got totally no output from 
gslx680 mmodule (/dev/event/event1).
I am completely stuck at this point, any suggestion will be really helpfull.
Thanks in advance.
selim

Hi Selim,
I've done an update recently that makes the new code work properly with
X, it was broken at one point.
At this point, as far as I know, I need to start the process of getting
it into sunxi properly. Maybe add DT and get it fully upstreamed. Yet to
start that process.
Anyway, no output from evtest tells me the problem is probably the firmware.
You need to extract the firmware from your android driver. There is a
python script in the firmware directory called fw_extractor (and
fw_info) that should be able to do this, if the driver is related to the
Android one with my device. If the firmware isn't in the Android driver,
then we need to find where it lives on your device and put it into the
same binary format.
If you feel you aren't getting anywhere, send me the Android driver and
I'll have a look to see if the firmware is in there and adapt the script
to find it there too.
We need to start building a database of the firmware for the gslx680
chips. If we can work out how to tell which chip needs which firmware,
we can select the right one automatically. The aim of course is
everything just works. :-)
Joe

Joe Hi,
Thanks for the quick reply,
Indeed I have read in some forum posts that people trying wrong
gslx680 firmwares got shifted touch outputs, I haven't seen a post
with no output from the driver.
I hope its about the wrong firmware.
Ok, now I will pull the successfully running driver (gslX680.ko)
from running android device and extract the firmware as you suggested.
Thanks again.
selim

Hi Selim,
No prob, delighted when someone has a play with it. :-)
The result of the wrong firmware is hard to guess.
The firmware for this device is just a buck load of settings from what I
can see.
Only thing that probably holds is it depends how far out your device is
from the settings in the firmware on how well it works.
Please please let me know how you get on.
Joe



Hi Joe,





Today I have rooted my tablet, successfully find the touchscreen module named as 
A13_gslX680 and pulled the ko file with adb pull.



Good news :)

After extracting the firmware from the original module and trying gslx680_ts  
driver with the original firmware everything worked like a charm, now I can get 
outputs from evtest tool.



More information about my tablet and firmware is;



my tablet exactly looks like this one -- 
https://drive.google.com/file/d/0B7kdmqnGET4eeHVlY1k2REVlemc/edit?usp=sharing



Screen size: 9 , 800x480



Mainboard ID : TW_A0910_16B_V1.1_0830



Touch screen IC : GSL3680



Original Module : 
https://docs.google.com/file/d/0B7kdmqnGET4eeHVlY1k2REVlemc/edit?pli=1



Original Firmaware (extracted): 
https://docs.google.com/file/d/0B7kdmqnGET4eNzItc0tYYW5PY3M/edit?pli=1





I hope it is useful for others.



Thanks for your help.



selim

sorry wrong link for the tablet !

my tablet 

Re: [linux-sunxi] CSI driver problems in 16bit mode + some successful debug

2014-03-16 Thread Ivan Kozic
Hi John - could you give me a link to this Android tree? I seem to have
difficulties finding it on GitHub...


On Sat, Mar 15, 2014 at 4:35 PM, jonsm...@gmail.com jonsm...@gmail.comwrote:

 On Sat, Mar 15, 2014 at 11:29 AM, Ivan Kozic jimmy...@gmail.com wrote:
  Hi John,
 
  Wow thanks - this looks quite cool - it seems that they've started
 working
  on YUV422 16bit and CCIR656 as well. May I ask where did you find the
  driver?

 It is from the current Allwinner Android tree. The CSI driver in sunxi
 is about two years old.

 sunxi kernel needs to be updated to use this driver.

  One crucial file is missing - sun4i_csi_core.h or sunxi_csi_core.h I
 guess,
  as it's not for A10 anymore.
 
 
  On Saturday, March 15, 2014 1:37:13 AM UTC+1, Jon Smirl wrote:
 
  I copied from the A10 manual.
 
  Here's a more recent driver
 
  On Fri, Mar 14, 2014 at 7:36 PM, Ivan Kozic jimm...@gmail.com wrote:
   Hi John - just saw your post. I think you're looking at a wrong
   document, as
   for A20, the register setting 100 for bits 22:20 is YUV422 16bit -
 it's
   written in the A20 User Manual on page 371. The problem is in fact
 this
   very
   vague information in the User Manual - it's almost useless. This is
 why
   I'm
   asking for help from someone who maybe knows the kernel a bit more -
 for
   instance, I'm not even sure which DMA is used for transfers from CSI
 to
   memory, because I have to figure it out from the driver.
  
   I'm also not sure where to search for the driver or more help. This
   group
   seems most professional of all by far - I have tried to contact
   Allwinner,
   but to no avail so far. As for sunxi kernel and drivers, I only know
 of
   the
   Git branch, but noone there has touched CSI driver for 8 months.
   Although I
   did always look in the 3.4 branch, maybe I should check out
 mainline...
  
   Anyway, I'll search for the actual solution myself and if I find it
 post
   back - If anyone can speed me up, I'll be most grateful.
  
  
   On Saturday, March 15, 2014 12:01:41 AM UTC+1, Jon Smirl wrote:
  
   I haven't tried any of this...
  
   Look like you would set the input format...
  
   22:20 R/W 3 INPUT_FMT
   Input data format
   000: RAW stream
   001: reserved
   010: CCIR656(one channel)
   011: YUV422
   100: YUV444({R, B, G} or {Pr, Pb, Y})
  
   When the input format is set YUV444
   1100: field planar YUV 444
   1101: field planar YUV 422 UV combined
   1110: frame planar YUV 444
   : frame planar YUV 422 UV combined
  
   The the output format is always 24b, right?
  
   You're going to have to read the user manual. I don't believe anyone
   has played with this before. But it looks like the hardware supports
   it.
  
   Also - the CSI driver in the sunxi tree is quite old. First thing I'd
   do is update it using the most recent Allwinner CSI driver we can
   locate. You might even get lucky and the newer Allwinner drivers
 could
   support 16b.
  
  
   On Fri, Mar 14, 2014 at 3:57 PM, Martin Collins 
 mar...@mkcollins.org
   wrote:
On 2014-03-14 10:42, Ivan Kozic wrote:
   
If someone knows something, please share - if I had some more
documentation, I would have probably already made the whole thing
work,
   
I don't know anything, but by chance I was looking here today:
http://dl.linux-sunxi.org/A10/
My impression was that there is an 8 bit channel and a 24 bit
channel.
So perhaps it won't do 16 bits?
   
Martin
   
--
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...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
  
  
  
   --
   Jon Smirl
   jons...@gmail.com
  
   --
   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...@googlegroups.com.
   For more options, visit https://groups.google.com/d/optout.
 
 
 
  --
  Jon Smirl
  jons...@gmail.com
 
  --
  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+unsubscr...@googlegroups.com.
  For more options, visit https://groups.google.com/d/optout.



 --
 Jon Smirl
 jonsm...@gmail.com

 --
 You received this message because you are subscribed to a topic in the
 Google Groups linux-sunxi group.
 To unsubscribe from this topic, visit
 https://groups.google.com/d/topic/linux-sunxi/vU5-3Pc3iOs/unsubscribe.
 To unsubscribe from this group and all its topics, send an email to
 linux-sunxi+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.


-- 
You received this message because you are subscribed to the Google Groups 
linux-sunxi group.
To 

Re: [linux-sunxi] Re: [U-Boot] [PATCH v1 7/9] sunxi: mmc support

2014-03-16 Thread Chen-Yu Tsai
On Mon, Mar 17, 2014 at 4:38 AM, Ian Campbell i...@hellion.org.uk wrote:
 On Fri, 2014-03-14 at 17:36 +0200, Pantelis Antoniou wrote:
 [...]

 Thanks for your review. It seems there are still quite a few issues
 dating back to the original allwinner dumps here.

 @linux-sunxi: if anyone wants to volunteer to help cleanup this
 particular driver I'd be very happy -- there's a lot of it!

 +
  +static void dumpmmcreg(struct sunxi_mmc *reg)
  +{
  +   debug(dump mmc registers:\n);
  +   debug(gctrl 0x%08x\n, reg-gctrl);
  +   debug(clkcr 0x%08x\n, reg-clkcr);
  +   debug(timeout   0x%08x\n, reg-timeout);
  +   debug(width 0x%08x\n, reg-width);
  +   debug(blksz 0x%08x\n, reg-blksz);
 [...] lots more debug(foo)
  +}

 ^^^ #ifdef DEBUG here?

 I can if you prefer but debug() itself effectively includes the same
 ifdef so the end result is already the same.

 [...]

  +/* support 4 mmc hosts */
  +struct mmc mmc_dev[4];
  +struct sunxi_mmc_host mmc_host[4];
  +

 ^ hosts  mmc structs can be allocated even for SPL now

 Can be or must be?

  +   struct sunxi_mmc_host *mmchost = mmc_host[sdc_no];
  +   static struct sunxi_gpio *gpio_c =
  +   ((struct sunxi_gpio_reg 
  *)SUNXI_PIO_BASE)-gpio_bank[SUNXI_GPIO_C];
  +   static struct sunxi_gpio *gpio_f =
  +   ((struct sunxi_gpio_reg 
  *)SUNXI_PIO_BASE)-gpio_bank[SUNXI_GPIO_F];
  +#if CONFIG_MMC1_PG
  +   static struct sunxi_gpio *gpio_g =
  +   ((struct sunxi_gpio_reg 
  *)SUNXI_PIO_BASE)-gpio_bank[SUNXI_GPIO_G];
  +#endif
  +   static struct sunxi_gpio *gpio_h =
  +   ((struct sunxi_gpio_reg 
  *)SUNXI_PIO_BASE)-gpio_bank[SUNXI_GPIO_H];
  +   static struct sunxi_gpio *gpio_i =
  +   ((struct sunxi_gpio_reg 
  *)SUNXI_PIO_BASE)-gpio_bank[SUNXI_GPIO_I];
  +   struct sunxi_ccm_reg *ccm = (struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
  +

 ^ Castings are ugly; rework with a temporary variable.

 Ack.

 The static's here are odd too and date back to the original alwinner
 code dumps. I'll get rid of them too.

You can drop the gpio ones in favor of using the sunxi gpio driver.

 [...]
  +   case 3:
  +   /* PI4-CMD, PI5-CLK, PI6~9-D0~D3 : 2 */
  +   writel(0x  16, gpio_i-cfg[0]);
  +   writel(0x22, gpio_i-cfg[1]);
  +   writel(0x555  8, gpio_i-pull[0]);
  +   writel(0x555  8, gpio_i-drv[0]);
  +   break;
  +
  +   default:
  +   return -1;
  +   }
  +

 Lots of magic constants. I have no idea what's going on here.
 Use a few defines.

 Right. These came from the original allwinner dumps so I was worried
 that they might be undocumented magic, but actually since the are gpio
 frobbing I reckon I can figure them out.

Should be something like this:

for (pin = SUNXI_GPI(4); pin = SUNXI_GPI(9); pin++) {
sunxi_gpio_set_cfgpin(pin, SUNXI_GPI_SDC3);
sunxi_gpio_set_drv(pin, 1);
sunxi_gpio_set_pull(pin, SUNXI_PULL_UP);
}

Note that SUNXI_GPI_* and SUNXI_PULL_* have not been defined.

I will send a patch for both the macros and MMC pinmux setting.

[..]

Thanks for working on this!


Cheers
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] [PATCH u-boot sunxi 5/5] mmc: sunxi: Use sunxi gpio functions to configure pins

2014-03-16 Thread Chen-Yu Tsai
Use the sunxi gpio driver to configure pins, instead of directly
writing magic numbers.

Signed-off-by: Chen-Yu Tsai w...@csie.org
---
 drivers/mmc/sunxi_mmc.c | 56 +++--
 1 file changed, 26 insertions(+), 30 deletions(-)

diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
index eae1f7c..248d669 100644
--- a/drivers/mmc/sunxi_mmc.c
+++ b/drivers/mmc/sunxi_mmc.c
@@ -138,22 +138,11 @@ static int mmc_resource_init(int sdc_no)
 
 static int mmc_clk_io_on(int sdc_no)
 {
+   unsigned int pin;
unsigned int rval;
unsigned int pll5_clk;
unsigned int divider;
struct sunxi_mmc_host *mmchost = mmc_host[sdc_no];
-   static struct sunxi_gpio *gpio_c =
-   ((struct sunxi_gpio_reg *)SUNXI_PIO_BASE)-gpio_bank[SUNXI_GPIO_C];
-   static struct sunxi_gpio *gpio_f =
-   ((struct sunxi_gpio_reg *)SUNXI_PIO_BASE)-gpio_bank[SUNXI_GPIO_F];
-#if CONFIG_MMC1_PG
-   static struct sunxi_gpio *gpio_g =
-   ((struct sunxi_gpio_reg *)SUNXI_PIO_BASE)-gpio_bank[SUNXI_GPIO_G];
-#endif
-   static struct sunxi_gpio *gpio_h =
-   ((struct sunxi_gpio_reg *)SUNXI_PIO_BASE)-gpio_bank[SUNXI_GPIO_H];
-   static struct sunxi_gpio *gpio_i =
-   ((struct sunxi_gpio_reg *)SUNXI_PIO_BASE)-gpio_bank[SUNXI_GPIO_I];
struct sunxi_ccm_reg *ccm = (struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
 
debug(init mmc %d clock and io\n, sdc_no);
@@ -162,40 +151,47 @@ static int mmc_clk_io_on(int sdc_no)
switch (sdc_no) {
case 0:
/* D1-PF0, D0-PF1, CLK-PF2, CMD-PF3, D3-PF4, D4-PF5 */
-   writel(0x22, gpio_f-cfg[0]);
-   writel(0x555, gpio_f-pull[0]);
-   writel(0xaaa, gpio_f-drv[0]);
+   for (pin = SUNXI_GPF(0); pin = SUNXI_GPF(5); pin++) {
+   sunxi_gpio_set_cfgpin(pin, SUNXI_GPF0_SDC0_CMD);
+   sunxi_gpio_set_pull(pin, SUNXI_GPIO_PULL_UP);
+   sunxi_gpio_set_drv(pin, 2);
+   }
break;
 
case 1:
 #if CONFIG_MMC1_PG
/* PG0-CMD, PG1-CLK, PG2~5-D0~3 : 4 */
-   writel(0x44, gpio_g-cfg[0]);
-   writel(0x555, gpio_g-pull[0]);
-   writel(0xaaa, gpio_g-drv[0]);
+   for (pin = SUNXI_GPG(0); pin = SUNXI_GPG(5); pin++) {
+   sunxi_gpio_set_cfgpin(pin, SUN4I_GPG0_SDC1_CMD;
+   sunxi_gpio_set_pull(pin, SUNXI_GPIO_PULL_UP);
+   sunxi_gpio_set_drv(pin, 2);
+   }
 #else
/* PH22-CMD, PH23-CLK, PH24~27-D0~D3 : 5 */
-   writel(0x55  24, gpio_h-cfg[2]);
-   writel(0x, gpio_h-cfg[3]);
-   writel(0x555  12, gpio_h-pull[1]);
-   writel(0xaaa  12, gpio_h-drv[1]);
+   for (pin = SUNXI_GPH(22); pin = SUNXI_GPH(27); pin++) {
+   sunxi_gpio_set_cfgpin(pin, SUN4I_GPH22_SDC1_CMD);
+   sunxi_gpio_set_pull(pin, SUNXI_GPIO_PULL_UP);
+   sunxi_gpio_set_drv(pin, 2);
+   }
 #endif
break;
 
case 2:
/* CMD-PC6, CLK-PC7, D0-PC8, D1-PC9, D2-PC10, D3-PC11 */
-   writel(0x33  24, gpio_c-cfg[0]);
-   writel(0x, gpio_c-cfg[1]);
-   writel(0x555  12, gpio_c-pull[0]);
-   writel(0xaaa  12, gpio_c-drv[0]);
+   for (pin = SUNXI_GPC(6); pin = SUNXI_GPC(11); pin++) {
+   sunxi_gpio_set_cfgpin(pin, SUNXI_GPC6_SDC2_CMD);
+   sunxi_gpio_set_pull(pin, SUNXI_GPIO_PULL_UP);
+   sunxi_gpio_set_drv(pin, 2);
+   }
break;
 
case 3:
/* PI4-CMD, PI5-CLK, PI6~9-D0~D3 : 2 */
-   writel(0x  16, gpio_i-cfg[0]);
-   writel(0x22, gpio_i-cfg[1]);
-   writel(0x555  8, gpio_i-pull[0]);
-   writel(0x555  8, gpio_i-drv[0]);
+   for (pin = SUNXI_GPI(4); pin = SUNXI_GPI(9); pin++) {
+   sunxi_gpio_set_cfgpin(pin, SUN4I_GPI4_SDC3_CMD);
+   sunxi_gpio_set_pull(pin, SUNXI_GPIO_PULL_UP);
+   sunxi_gpio_set_drv(pin, 2);
+   }
break;
 
default:
-- 
1.9.0

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] [PATCH u-boot sunxi 4/5] net: sunxi_gmac: Use sunxi gpio pin function macros

2014-03-16 Thread Chen-Yu Tsai
Signed-off-by: Chen-Yu Tsai w...@csie.org
---
 drivers/net/sunxi_gmac.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/sunxi_gmac.c b/drivers/net/sunxi_gmac.c
index b8b9016..98a78c4 100644
--- a/drivers/net/sunxi_gmac.c
+++ b/drivers/net/sunxi_gmac.c
@@ -31,7 +31,7 @@ int sunxi_gmac_initialize(bd_t *bis)
if (pin == SUNXI_GPA(9) || pin == SUNXI_GPA(14))
continue;
 #endif
-   sunxi_gpio_set_cfgpin(pin, 5);
+   sunxi_gpio_set_cfgpin(pin, SUN7I_GPA0_GRXD3);
sunxi_gpio_set_drv(pin, 3);
}
 
-- 
1.9.0

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] [PATCH u-boot sunxi 2/5] i2c: sunxi: Use sunxi gpio pin function macros

2014-03-16 Thread Chen-Yu Tsai
Signed-off-by: Chen-Yu Tsai w...@csie.org
---
 drivers/i2c/sunxi_i2c.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/sunxi_i2c.c b/drivers/i2c/sunxi_i2c.c
index 5fe790a..5babf06 100644
--- a/drivers/i2c/sunxi_i2c.c
+++ b/drivers/i2c/sunxi_i2c.c
@@ -19,8 +19,8 @@ void i2c_init(int speed, int slaveaddr)
 {
int timeout = 0x2ff;
 
-   sunxi_gpio_set_cfgpin(SUNXI_GPB(0), 2);
-   sunxi_gpio_set_cfgpin(SUNXI_GPB(1), 2);
+   sunxi_gpio_set_cfgpin(SUNXI_GPB(0), SUNXI_GPB0_TWI0_SCK);
+   sunxi_gpio_set_cfgpin(SUNXI_GPB(1), SUNXI_GPB0_TWI0_SCK);
clock_twi_onoff(0, 1);
 
/* Enable the i2c bus */
-- 
1.9.0

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.