[linux-sunxi] Re: [U-Boot] [PATCH v1 0/9] sunxi: initial upstreamining effort
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.