[linux-sunxi] Re: [U-Boot] [PATCH v2 1/9] sunxi: initial sun7i clocks and timer support.

[Wolfgang Denk]

Dear Olliver Schinagl,

In message <5330b4c9.10...@schinagl.nl> you wrote:
>
> > sr32() is not defined anywhere.
> it should be defined in
> arch/arm/include/asm/arch-sunxi/sys_proto.h
> and comes from
> arch/arm/cpu/armv7/syslib.c

Please avoid using sr32() alltogether.  It is basically only used in a
single file (arch/arm/cpu/armv7/omap3/clock.c) [plus a single call in
board/ti/panda/panda.c] and should be replaced by standard I/O
accessor functions.  I will prepare a patch to remove it from mainline
soon, so better don't start using it.

Thanks.

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
A metaphor is like a simile.

-- 
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: A10-meminfo: DRAMC settings dump utility

[ratin]

On Sunday, November 18, 2012 1:16:28 PM UTC-8, Max wrote:
> Hi,
> 
> 
> 
> I experimented a bit with dumping the A10 memory settings using /dev/mem 
> 
> under Linux/Android, and that seems to work.
> 
> At least on my Cubieboard 1 GB and Hackberry 512 MB.
> 
> 
> 
> I was wondering if someone with a different A10 board could give it a 
> 
> try, and tell me if the results it outputs are correct.
> 
> 
> 
> 
> 
> Source code and a static binary is available at: 
> 
> https://github.com/maxnet/a10-meminfo
> 
> 
> 
> On Linux simply execute a10-meminfo-static as root.
> 
> To run it under Android use one of the terminal apps to start it.
> 
> (If you downloaded the executable with the Android browser to 
> 
> /sdcard/Downloads, make sure you move it to a different location first 
> 
> as /sdcard is mounted noexec)
> 
> 
> 
> Will see if I can write an easier to use Android app to display the 
> 
> information, if the utility works correctly.
> 
> 
> 
> 
> 
> Yours sincerely,
> 
> 
> 
> Floris Bos

Got a question : Since the mmap flag set to O_RDWR|O_SYNC, is it possible to 
write something to the CCM register to alter DRAM PLL to a bit smaller value? 
Seeing a lot of problems with the high DRAM clk and there does not seem to be a 
easy way to alter the DRAM clock setting (booting from Nand)  

-- 
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 v2 1/9] sunxi: initial sun7i clocks and timer support.

[Marek Vasut]

On Monday, March 24, 2014 at 11:42:17 PM, Olliver Schinagl wrote:
> On 03/24/2014 09:52 PM, Marek Vasut wrote:
> > On Friday, March 21, 2014 at 10:54:18 PM, Ian Campbell wrote:
> >> This has been stripped back for mainlining and supports only sun7i.
> >> These changes are not useful by themselves but are split out to make
> >> the patch sizes more manageable.
> > 
> > [...]
> > 
> >> +int clock_init(void)
> >> +{
> >> +  struct sunxi_ccm_reg *const ccm =
> >> +  (struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
> >> +
> >> +#ifdef CONFIG_SPL_BUILD
> >> +  clock_init_safe();
> >> +#endif
> >> +
> >> +  /* uart clock source is apb1 */
> >> +  sr32(&ccm->apb1_clk_div_cfg, 24, 2, APB1_CLK_SRC_OSC24M);
> >> +  sr32(&ccm->apb1_clk_div_cfg, 16, 2, APB1_FACTOR_N);
> >> +  sr32(&ccm->apb1_clk_div_cfg, 0, 5, APB1_FACTOR_M);
> > 
> > sr32() is not defined anywhere.
> 
> it should be defined in
> arch/arm/include/asm/arch-sunxi/sys_proto.h
> and comes from
> arch/arm/cpu/armv7/syslib.c
> 
> it was added for the ti omap's
> 
> I've got a local cleanup patch set where I fixed this already to
> clrsetbits_le32

It's not part of this patch, but then, use clrsetbits_le32() instead of course.

> >> +  /* open the clock for uart */
> >> +  sr32(&ccm->apb1_gate, 16 + CONFIG_CONS_INDEX - 1, 1, CLK_GATE_OPEN);
> >> +
> >> +  return 0;
> >> +}
> >> +
> >> +/* Return PLL5 frequency in Hz
> >> + * Note: Assumes PLL5 reference is 24MHz clock
> >> + */
> >> +unsigned int clock_get_pll5(void)
> >> +{
> >> +  struct sunxi_ccm_reg *const ccm =
> >> +  (struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
> >> +  uint32_t rval = readl(&ccm->pll5_cfg);
> >> +  int n = (rval >> 8) & 0x1f;
> >> +  int k = ((rval >> 4) & 3) + 1;
> >> +  int p = 1 << ((rval >> 16) & 3);
> >> +  return 2400 * n * k / p;
> > 
> > Please fix the magic values here.
> > [...]
> 
> Same here, got that in my local tree too

Then make it part of the V3 please.

[...]

-- 
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 v2 1/9] sunxi: initial sun7i clocks and timer support.

[Olliver Schinagl]

On 03/24/2014 09:52 PM, Marek Vasut wrote:

On Friday, March 21, 2014 at 10:54:18 PM, Ian Campbell wrote:

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

[...]


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


sr32() is not defined anywhere.

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

it was added for the ti omap's

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



+   /* open the clock for uart */
+   sr32(&ccm->apb1_gate, 16 + CONFIG_CONS_INDEX - 1, 1, CLK_GATE_OPEN);
+
+   return 0;
+}
+
+/* Return PLL5 frequency in Hz
+ * Note: Assumes PLL5 reference is 24MHz clock
+ */
+unsigned int clock_get_pll5(void)
+{
+   struct sunxi_ccm_reg *const ccm =
+   (struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
+   uint32_t rval = readl(&ccm->pll5_cfg);
+   int n = (rval >> 8) & 0x1f;
+   int k = ((rval >> 4) & 3) + 1;
+   int p = 1 << ((rval >> 16) & 3);
+   return 2400 * n * k / p;

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

Same here, got that in my local tree too



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

\

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

Here is well.

dito :)



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

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

[...]

That one i didn't have;

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



+   /* Map divisors to register values */
+   axi = axi - 1;
+   if (ahb > 4)
+   ahb = 3;
+   else if (ahb > 2)
+   ahb = 2;
+   else if (ahb > 1)
+   ahb = 1;
+   else
+   ahb = 0;
+
+   apb0 = apb0 - 1;
+
+   /* Switch to 24MHz clock while changing PLL1 */
+   writel(AXI_DIV_1 << AXI_DIV_SHIFT |
+  AHB_DIV_2 << AHB_DIV_SHIFT |
+  APB0_DIV_1 << APB0_DIV_SHIFT |
+  CPU_CLK_SRC_OSC24M << CPU_CLK_SRC_SHIFT,
+  &ccm->cpu_ahb_apb0_cfg);
+   sdelay(20);

What is sdelay() function all about ?

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

With the sr32 and sdelays gone everywhere, sunxi/sys_proto.h can even go!


[...]


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

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

[...]

Olliver

--
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: A10 versus A20 versus A20 , gtkperf result.

[Rajesh Mallah]

I also observed that a clone of the rootfs from Mele M3 to another
A20 based TB Box consistently performed slower than Mele M3.

MeleM3 :18.95 secs
Other A20:  25  secs

the dump from a10-meminfo-static were same in both the cases
except for dram_zq param

Can anyone pls explain why the difference in the A20 based boards
itself  ?

regds
mallah.

-- 
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 v5 1/7] clk: sunxi: Remove calls to clk_put

[Mike Turquette]

Quoting Maxime Ripard (2014-03-13 08:14:13)
> Callers of clk_put must disable the clock first. This also means that as long
> as the clock is enabled the driver should hold a reference to that clock.
> Hence, the call to clk_put here are bogus and should be removed.
> 
> Signed-off-by: Maxime Ripard 

Looks good to me. There is a balanced clk_put in the module remove
function?

Regards,
Mike

> ---
>  drivers/clk/sunxi/clk-sunxi.c | 8 ++--
>  1 file changed, 2 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
> index 23baad9d934a..7119c02c9fa8 100644
> --- a/drivers/clk/sunxi/clk-sunxi.c
> +++ b/drivers/clk/sunxi/clk-sunxi.c
> @@ -1290,17 +1290,13 @@ static void __init sunxi_clock_protect(void)
>  
> /* memory bus clock - sun5i+ */
> clk = clk_get(NULL, "mbus");
> -   if (!IS_ERR(clk)) {
> +   if (!IS_ERR(clk))
> clk_prepare_enable(clk);
> -   clk_put(clk);
> -   }
>  
> /* DDR clock - sun4i+ */
> clk = clk_get(NULL, "pll5_ddr");
> -   if (!IS_ERR(clk)) {
> +   if (!IS_ERR(clk))
> clk_prepare_enable(clk);
> -   clk_put(clk);
> -   }
>  }
>  
>  static void __init sunxi_init_clocks(void)
> -- 
> 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] Re: [U-Boot] [PATCH v2 2/9] sunxi: initial sun7i pinmux and gpio support

[Marek Vasut]

On Friday, March 21, 2014 at 10:54:19 PM, Ian Campbell wrote:
[...]

> diff --git a/arch/arm/cpu/armv7/sunxi/pinmux.c
> b/arch/arm/cpu/armv7/sunxi/pinmux.c new file mode 100644
> index 000..8f5cbfe
> --- /dev/null
> +++ b/arch/arm/cpu/armv7/sunxi/pinmux.c
> @@ -0,0 +1,80 @@
> +/*
> + * (C) Copyright 2007-2011
> + * Allwinner Technology Co., Ltd. 
> + * Tom Cubie 
> + *
> + * SPDX-License-Identifier:  GPL-2.0+
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +int sunxi_gpio_set_cfgpin(u32 pin, u32 val)
> +{
> + u32 cfg;
> + u32 bank = GPIO_BANK(pin);
> + u32 index = GPIO_CFG_INDEX(pin);
> + u32 offset = GPIO_CFG_OFFSET(pin);
> + struct sunxi_gpio *pio =
> + &((struct sunxi_gpio_reg *)SUNXI_PIO_BASE)->gpio_bank[bank];
> +
> + cfg = readl(&pio->cfg[0] + index);
> + cfg &= ~(0xf << offset);
> + cfg |= val << offset;
> +
> + writel(cfg, &pio->cfg[0] + index);

clrsetbits_le32() here.

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

Here as well.

> + return 0;
> +}
> +
> +int sunxi_gpio_set_pull(u32 pin, u32 val)
> +{
> + u32 pull;
> + u32 bank = GPIO_BANK(pin);
> + u32 index = GPIO_PULL_INDEX(pin);
> + u32 offset = GPIO_PULL_OFFSET(pin);
> + struct sunxi_gpio *pio =
> + &((struct sunxi_gpio_reg *)SUNXI_PIO_BASE)->gpio_bank[bank];
> +
> + pull = readl(&pio->pull[0] + index);
> + pull &= ~(0x3 << offset);
> + pull |= val << offset;
> +
> + writel(pull, &pio->pull[0] + index);

Same here.

> + return 0;
> +}

[...]

> +int sunxi_gpio_set_cfgpin(u32 pin, u32 val);
> +int sunxi_gpio_get_cfgpin(u32 pin);
> +int sunxi_gpio_set_drv(u32 pin, u32 val);
> +int sunxi_gpio_set_pull(u32 pin, u32 val);
> +int name_to_gpio(const char *name);
> +#define name_to_gpio name_to_gpio

What is this ugly define doing here ?

-- 
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 v2 8/9] sunxi: mmc support

[Marek Vasut]

On Friday, March 21, 2014 at 10:54:25 PM, Ian Campbell wrote:
> As well as the following signed-off-by the sunxi branch shows commits to
> these files authored by the following:
>   Stefan Roese
>   Tom Cubie
>   yemao
> 
> Signed-off-by: Henrik Nordstrom 
> Signed-off-by: Luke Leighton 
> Signed-off-by: Oliver Schinagl 
> Signed-off-by: Wills Wang 
> Signed-off-by: Ian Campbell 
> Cc: Pantelis Antoniou 
[...]

> +
> +static void dumphex32(char *name, char *base, int len)
> +{
> + __u32 i;
> +
> + debug("dump %s registers:", name);
> + for (i = 0; i < len; i += 4) {
> + if (!(i & 0xf))
> + debug("\n0x%p : ", base + i);
> + debug("0x%08x ", readl(base + i));
> + }
> + debug("\n");
> +}

Looks like print_hex_dump() reimplementation ...

[...]

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

Are these two branches almost the same ? Why not just clear that up by 
squashing 
them into one with a small if (...) at the begining of this function ?

[...]

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

Yum, this pointer voodoo looks tasty (and ready for fixing up ... ).
[...]

-- 
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 

[linux-sunxi] Re: [U-Boot] [PATCH v2 1/9] sunxi: initial sun7i clocks and timer support.

[Marek Vasut]

On Friday, March 21, 2014 at 10:54:18 PM, Ian Campbell wrote:
> This has been stripped back for mainlining and supports only sun7i. These
> changes are not useful by themselves but are split out to make the patch
> sizes more manageable.

[...]

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


sr32() is not defined anywhere.

> + /* open the clock for uart */
> + sr32(&ccm->apb1_gate, 16 + CONFIG_CONS_INDEX - 1, 1, CLK_GATE_OPEN);
> +
> + return 0;
> +}
> +
> +/* Return PLL5 frequency in Hz
> + * Note: Assumes PLL5 reference is 24MHz clock
> + */
> +unsigned int clock_get_pll5(void)
> +{
> + struct sunxi_ccm_reg *const ccm =
> + (struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
> + uint32_t rval = readl(&ccm->pll5_cfg);
> + int n = (rval >> 8) & 0x1f;
> + int k = ((rval >> 4) & 3) + 1;
> + int p = 1 << ((rval >> 16) & 3);
> + return 2400 * n * k / p;

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

> +#ifdef CONFIG_SPL_BUILD
> +#define PLL1_CFG(N, K, M, P) (1 << 31 | 0 << 30 | 8 << 26 | 0 << 25 | 
\
> +  16 << 20 | (P) << 16 | 2 << 13 | (N) << 8 | \
> +  (K) << 4 | 0 << 3 | 0 << 2 | (M) << 0)

Here is well.

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

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

[...]

> + /* Map divisors to register values */
> + axi = axi - 1;
> + if (ahb > 4)
> + ahb = 3;
> + else if (ahb > 2)
> + ahb = 2;
> + else if (ahb > 1)
> + ahb = 1;
> + else
> + ahb = 0;
> +
> + apb0 = apb0 - 1;
> +
> + /* Switch to 24MHz clock while changing PLL1 */
> + writel(AXI_DIV_1 << AXI_DIV_SHIFT |
> +AHB_DIV_2 << AHB_DIV_SHIFT |
> +APB0_DIV_1 << APB0_DIV_SHIFT |
> +CPU_CLK_SRC_OSC24M << CPU_CLK_SRC_SHIFT,
> +&ccm->cpu_ahb_apb0_cfg);
> + sdelay(20);

What is sdelay() function all about ?

[...]

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

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

[...]

-- 
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 v2 5/9] sunxi: generic sun7i build infrastructure.

[Marek Vasut]

On Friday, March 21, 2014 at 10:54:22 PM, Ian Campbell wrote:
> This has been stripped back for mainlining and supports only sun7i booting
> via FEL mode. These changes are not useful by themselves but are split out
> to make the patch sizes more manageable.
> 
> As well as the following signed-off-by the sunxi branch shows commits to
> these files authored by the following:
>   Almo Nito
>   Carl van Schaik
>   FUKAUMI Naoki
>   hehopmajieh
>   j
>   Sergey Lapin
>   Tom Cubie
> 
> Signed-off-by: Adam Sampson 
> Signed-off-by: Aleksei Mamlin 
> Signed-off-by: Chen-Yu Tsai 
> Signed-off-by: Emilio López 
> Signed-off-by: Hans de Goede 
> Signed-off-by: Henrik Nordstrom 
> Signed-off-by: Jens Kuske 
> Signed-off-by: Luc Verhaegen 
> Signed-off-by: Luke Leighton 
> Signed-off-by: Oliver Schinagl 
> Signed-off-by: Patrick Wood 
> Signed-off-by: Stefan Roese 
> Signed-off-by: Wills Wang 
> Signed-off-by: Ian Campbell 
> ---
> v2: Based on u-boot-sunxi.git#sunxi d9aa5dd3d15c "sunxi: mmc:
> checkpatch whitespace fixes" with v2014.04-rc2 merged in:
> - sunxi-common.h updates, including pulling some command additions back
>   from the non-FEL patch and switchin to bootm_size not BOOTMAPSZ
> 
> v1: Based on u-boot-sunxi.git#sunxi commit d854c4de2f57 "arm: Handle
> .gnu.hash section in ldscripts" vs v2014.01.
> ---
>  arch/arm/cpu/armv7/Makefile |   2 +-
>  arch/arm/cpu/armv7/sunxi/u-boot-spl-fel.lds |  59 +++
>  arch/arm/include/asm/arch-sunxi/spl.h   |  20 
>  board/sunxi/Makefile|   1 +
>  include/configs/sun7i.h |  24 +
>  include/configs/sunxi-common.h  | 153
>  6 files changed, 258 insertions(+), 1
> deletion(-)
>  create mode 100644 arch/arm/cpu/armv7/sunxi/u-boot-spl-fel.lds
>  create mode 100644 arch/arm/include/asm/arch-sunxi/spl.h
>  create mode 100644 include/configs/sun7i.h
>  create mode 100644 include/configs/sunxi-common.h
> 
> diff --git a/arch/arm/cpu/armv7/Makefile b/arch/arm/cpu/armv7/Makefile
> index 119ebb3..ddf00f3 100644
> --- a/arch/arm/cpu/armv7/Makefile
> +++ b/arch/arm/cpu/armv7/Makefile
> @@ -12,7 +12,7 @@ obj-y   += cache_v7.o
>  obj-y+= cpu.o
>  obj-y+= syslib.o
> 
> -ifneq
> ($(CONFIG_AM43XX)$(CONFIG_AM33XX)$(CONFIG_OMAP44XX)$(CONFIG_OMAP54XX)$(CON
> FIG_TEGRA)$(CONFIG_MX6)$(CONFIG_TI81XX)$(CONFIG_AT91FAMILY),) +ifneq
> ($(CONFIG_AM43XX)$(CONFIG_AM33XX)$(CONFIG_OMAP44XX)$(CONFIG_OMAP54XX)$(CON
> FIG_TEGRA)$(CONFIG_MX6)$(CONFIG_TI81XX)$(CONFIG_AT91FAMILY)$(CONFIG_SUNXI),
> ) ifneq ($(CONFIG_SKIP_LOWLEVEL_INIT),y)
>  obj-y+= lowlevel_init.o
>  endif
> diff --git a/arch/arm/cpu/armv7/sunxi/u-boot-spl-fel.lds
> b/arch/arm/cpu/armv7/sunxi/u-boot-spl-fel.lds new file mode 100644
> index 000..cf02300
> --- /dev/null
> +++ b/arch/arm/cpu/armv7/sunxi/u-boot-spl-fel.lds
> @@ -0,0 +1,59 @@
> +OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm")
> +OUTPUT_ARCH(arm)
> +ENTRY(s_init)
> +SECTIONS
> +{
> + . = 0x2000;
> + . = ALIGN(4);
> + .text :
> + {


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

[...]

> +/*
> + * Display CPU information
> + */
> +#define CONFIG_DISPLAY_CPUINFO
> +
> +/* Serial & console */
> +#define CONFIG_SYS_NS16550
> +#define CONFIG_SYS_NS16550_SERIAL
> +/* ns16550 reg in the low bits of cpu reg */
> +#define CONFIG_SYS_NS16550_REG_SIZE  (-4)
> +#define CONFIG_SYS_NS16550_CLK   (2400)

The braces are not needed .

> +#define CONFIG_SYS_NS16550_COM1  SUNXI_UART0_BASE
> +#define CONFIG_SYS_NS16550_COM2  SUNXI_UART1_BASE
> +#define CONFIG_SYS_NS16550_COM3  SUNXI_UART2_BASE
> +#define CONFIG_SYS_NS16550_COM4  SUNXI_UART3_BASE
[...]

-- 
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] Re: Build sunxi-next for A20

[Olliver Schinagl]

On 03/24/2014 01:55 PM, i...@integrazioneweb.com wrote:

Hi Olliver,
i tryed some defconfig but i haven't uart cable so i don't know where is boot 
problem.


Then it will be next to impossible to debug.

Olliver

--
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] uboot for Mele M3 A20

[Luc Verhaegen]

On Mon, Mar 24, 2014 at 10:31:56AM +0100, Olliver Schinagl wrote:
> On 03/23/2014 06:27 PM, Rajesh Mallah wrote:
>> Hi,
>>
>> I regularly search Alibaba market place for devices (TV boxes) can be
>> reused as low powered general purpose computers. Many of such devices
>> have debug
>> ports ( some do not have also ).
>>
>> Most allwinner based devices on marketplace are A20 based, 1 GB model
>> A10 and A31  are not seen in general. In Quad core segment generally
>> device makers are
>> going for RK3188.  In in dual core segment AMLogic MX is also seen along
>> with RK3066.
>>
>> My question is that is it really worth documenting such allwinner
>> devices in linux-sunxi
>> website ?
> Yes, yes yes! The more devices are documented, the better it is for all  
> of us :)
>
> In this specific case, the Mele was our main target for a long time.  
> Many developers still have Mele's. The A20 based mele for some reason  
> has been skipped and has very little information however. Which is why  
> we are very interested in the guts and glory :)

One caveat to that triple yes.

We only want to see devices documented that people actually own, and 
which have been brought up properly. With u-boot-sunxi and sunxi-boards
patches and with photos of the innards, etc.

We do not want people to look at aliexpress and just throw some 
marketing info in our wiki. That's just counterproductive.

So Rajesh, buy the device(s) that you fancy, and work through our 
http://linux-sunxi.org/New_Device_howto and help yourself and others, 
and enjoy your new arm-based linux device(s) afterwards.

Luc Verhaegen.

-- 
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: A31 pmic (axp221) support

[Hans de Goede]

Hi,

On 03/24/2014 03:06 PM, Maxime Ripard wrote:
> On Tue, Mar 11, 2014 at 12:00:14PM +0100, Hans de Goede wrote:
>>> On Tue, Mar 11, 2014 at 11:16:16AM +0100, Hans de Goede wrote:
> There's still some subtleties I don't get yet, but the more I
> think about this, the more I feel like we'll have to write our own
> bus :(

 So on the bus things are different then with i2c, that does not mean
 we cannot still pretend it is i2c to upper layers in the kernel.
>>>
>>> The fact that it's not having any ACK, nor any address is kind of a
>>> show stopper. For all we now, we could just as much pretend it's SPI :)
>>
>> According to:
>> https://github.com/oliv3r/u-boot-sunxi/commit/52b8454fb8951e95da76b3d9ba82461adab5ee7f
>>
>> It does have a device address, and if I read your previous mail
>> correct, there is an ack.
> 
> I'm not sure about what this is actually about, but the protocol
> description clearly shows that there is no address sent over the bus.
> 
> However, I think what happens is that it starts as an I2C bus, and
> that a write to this register actually switch the PMIC from I2C to
> P2WI mode, hence why it needs an address.
> 
> And there is an ACK, but at the end of the transfer, not between each
> byte like on I2C.
> 
> 
>>> Plus, a lot of devices can actually be plugged onto several different
>>> buses, and have driver that add a small layer to access registers
>>> depending on which bus they're loaded from.
>>>
>>> We could very well imagine having to use regmap for the i2c part, and
>>> p2wi bus calls for the A31's case.
>>
>> This actually sounds like something which using a regmap would make
>> easier to do.
> 
> Indeed.
> 
 And if we try and fail we can always define our own bus for this
 later.
>>>
>>> You can still ask the i2c maintainer, but I'm afraid I know his
>>> answer.
>>
>> As said before I think we first need to learn more about how this
>> bus works before we can make a call one way or the other.
> 
> What's missing from my previous mail?

Nothing, in the mean time I've taken a look at the i2c-regmap code and
that actually is quite small. So I've come around and I agree that
making this its own bus from day 1 is the best thing to do.

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: A31 pmic (axp221) support

[Hans de Goede]

Hi,

p.s.

I've taken a quick look at the mmc code we've for the A31 in the sunxi
provided kernel sources and it seems 100% identical to the mmc controller
in sun5i and sun7i. I've not yet gotten around to actually hooking things
up in devicetree and given it a shot though.

My rough plan for moving forward with A31 atm is:

1) Get mmc working in the kernel
2) Get mmc working in u-boot so that we can replace the allwinnner u-boot
binary on the sdcard images (we'll still need allwinners boot0 and boot1 for 
now)
3) Add push-pull controller + pmic support to u-boot (and make it power on the
network phy)
4) Get the gmac working
5) profit ?

This will all be as time permits...

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 v7 1/8] clk: sunxi: factors: automatic reparenting support

[Maxime Ripard]

On Wed, Mar 19, 2014 at 04:39:45PM -0700, Mike Turquette wrote:
> Quoting Maxime Ripard (2014-02-18 06:05:16)
> > On Mon, Feb 17, 2014 at 11:02:15AM +0100, David Lanzendörfer wrote:
> > > From: Emilio López 
> > > 
> > > This commit implements .determine_rate, so that our factor clocks can be
> > > reparented when needed.
> > > 
> > > Signed-off-by: Emilio López 
> > 
> > Your signed-off-by is missing here.
> > 
> > Once you added it, you can add my Acked-by
> 
> Yes the patch looks good to me as well. Am I correct in thinking that it
> is independent of the MMC clock phase discussion? If it is resubmitted
> with a proper SoB then I can pick it.

Yes, it's completely independant of the MMC phase stuff.

Emilio, or David, could you resend it?

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


signature.asc
Description: Digital signature

Re: [linux-sunxi] [A20] sunxi framebuffer overlay help needed

[Luc Verhaegen]

On Mon, Mar 24, 2014 at 07:00:39AM -0700, Ivan Kozic wrote:
> Hi all,
> 
> Up to now, I have successfully debugged and fixed CSI issues in 3.4 kernel 
> so that it works more-less closer to the spec of sun7i (driver is only 
> sun4i compatible by default - for more advanced features, you'll need some 
> changes in the code). For more info, you can visit:
> 
> https://groups.google.com/forum/#!searchin/linux-sunxi/A20$20csi/linux-sunxi/vU5-3Pc3iOs/aVpmpfb1FkAJ
> 
> This is all for A20 or sun7i (as I have Olinuxino A20).
> 
> Right now I'd need some help regarding overlay framebuffer - my initial 
> idea was to have a full screen video, while having a small functional GUI 
> (more like a widget) on the overlay channel to use for controls (this would 
> be done using Qt).
> However, this seems to be much harder than on i.MX6 for instance (I have 
> previous experience with i.MX6), mainly because Freescale is using 2 
> separate framebuffers for one screen. So to sum up:
> 1. fb0 is BG (video for instance),
> 2. fb1 is FG (overlay, ideal for GUI).
> 
> When I look at the HW layout (especially page 414 of the A20 user manual), 
> I see that the Allwinner's intent was to make something similar, as DEBE 
> does the mixing of the overlay/background. However, the driver does not 
> seem to have such an option (or I am not familiar with this).
> 
> At the end, I can make video show up in Qt - this is not a huge problem (I 
> have taken libv4l2 made for Qt and I get the output) - the problem is that 
> it's painfully slow (like barely 3fps), as it doesn't use HW mixer - it 
> only copies the data from V4L2 buffers into the userland and into QImage 
> object, which is quite slow.
> 
> So the way it would have worked on i.MX6 is that video is simply driven 
> into fb0 via small library using DMA, while Qt would be configured to use 
> fb1 only - I'm after something like this on A20.
> Maybe I'm missing something obvious here, but still I couldn't find a good 
> solution up to now.
> 
> Of course, if I find something out, I'll post back.
> 
> All help greatly appreciated!

You only need DEFE for your CSI captured information, as that is in some 
non RGB colour format.

You can happily attach RGB32 to any layer directly, and achieve your 
goal that way.

Luc Verhaegen.


-- 
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: A31 pmic (axp221) support

[Maxime Ripard]

On Tue, Mar 11, 2014 at 12:00:14PM +0100, Hans de Goede wrote:
> > On Tue, Mar 11, 2014 at 11:16:16AM +0100, Hans de Goede wrote:
> >>> There's still some subtleties I don't get yet, but the more I
> >>> think about this, the more I feel like we'll have to write our own
> >>> bus :(
> >>
> >> So on the bus things are different then with i2c, that does not mean
> >> we cannot still pretend it is i2c to upper layers in the kernel.
> > 
> > The fact that it's not having any ACK, nor any address is kind of a
> > show stopper. For all we now, we could just as much pretend it's SPI :)
> 
> According to:
> https://github.com/oliv3r/u-boot-sunxi/commit/52b8454fb8951e95da76b3d9ba82461adab5ee7f
> 
> It does have a device address, and if I read your previous mail
> correct, there is an ack.

I'm not sure about what this is actually about, but the protocol
description clearly shows that there is no address sent over the bus.

However, I think what happens is that it starts as an I2C bus, and
that a write to this register actually switch the PMIC from I2C to
P2WI mode, hence why it needs an address.

And there is an ACK, but at the end of the transfer, not between each
byte like on I2C.


> > Plus, a lot of devices can actually be plugged onto several different
> > buses, and have driver that add a small layer to access registers
> > depending on which bus they're loaded from.
> > 
> > We could very well imagine having to use regmap for the i2c part, and
> > p2wi bus calls for the A31's case.
> 
> This actually sounds like something which using a regmap would make
> easier to do.

Indeed.

> >> And if we try and fail we can always define our own bus for this
> >> later.
> > 
> > You can still ask the i2c maintainer, but I'm afraid I know his
> > answer.
> 
> As said before I think we first need to learn more about how this
> bus works before we can make a call one way or the other.

What's missing from my previous mail?

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


signature.asc
Description: Digital signature

[linux-sunxi] [A20] sunxi framebuffer overlay help needed

[Ivan Kozic]

Hi all,

Up to now, I have successfully debugged and fixed CSI issues in 3.4 kernel 
so that it works more-less closer to the spec of sun7i (driver is only 
sun4i compatible by default - for more advanced features, you'll need some 
changes in the code). For more info, you can visit:

https://groups.google.com/forum/#!searchin/linux-sunxi/A20$20csi/linux-sunxi/vU5-3Pc3iOs/aVpmpfb1FkAJ

This is all for A20 or sun7i (as I have Olinuxino A20).

Right now I'd need some help regarding overlay framebuffer - my initial 
idea was to have a full screen video, while having a small functional GUI 
(more like a widget) on the overlay channel to use for controls (this would 
be done using Qt).
However, this seems to be much harder than on i.MX6 for instance (I have 
previous experience with i.MX6), mainly because Freescale is using 2 
separate framebuffers for one screen. So to sum up:
1. fb0 is BG (video for instance),
2. fb1 is FG (overlay, ideal for GUI).

When I look at the HW layout (especially page 414 of the A20 user manual), 
I see that the Allwinner's intent was to make something similar, as DEBE 
does the mixing of the overlay/background. However, the driver does not 
seem to have such an option (or I am not familiar with this).

At the end, I can make video show up in Qt - this is not a huge problem (I 
have taken libv4l2 made for Qt and I get the output) - the problem is that 
it's painfully slow (like barely 3fps), as it doesn't use HW mixer - it 
only copies the data from V4L2 buffers into the userland and into QImage 
object, which is quite slow.

So the way it would have worked on i.MX6 is that video is simply driven 
into fb0 via small library using DMA, while Qt would be configured to use 
fb1 only - I'm after something like this on A20.
Maybe I'm missing something obvious here, but still I couldn't find a good 
solution up to now.

Of course, if I find something out, I'll post back.

All help greatly appreciated!

-- 
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] Re: Build sunxi-next for A20

[info]

Hi Olliver,
i tryed some defconfig but i haven't uart cable so i don't know where is boot 
problem. 

-- 
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: sunxi-3.4 usb and rtl8188 regressions.

[Drona Nagarajan]

Hi,

I'm facing the same issues. After adding the usb_wifi_para section, my wifi 
still refuses to work. I'm able to modprobe the module but nothing after 
that. "wlan0" is not being detected!

On Friday, January 3, 2014 5:30:48 PM UTC+5:30, Luc Verhaegen wrote:
>
> Hi, 
>
> I have just brought up a new a20 tablet and upgraded the kernel on my 
> a10 tablet from sunxi-3.0 to sunxi-3.4. And here are my findings. 
>
> My a20 tablet comes with RTL8188ETV wifi, attached to the usbc2 bus. The 
> 8188eu driver was totally unable to see it until: 
> a) i explicitely powered on the usbc2 bus from script.bin 
> b) i added a usb_wifi_para section to script.bin, especially for the 
> 8188eu driver. 
>
> My a10 tablet was, up until now, happily running sunxi-3.0. The 8192cu 
> driver on sunxi-3.0 worked with the RTL8188CUS just fine. On sunxi-3.4 
> however, it no longer works. It nicely enables the usb bus (which 8188eu 
> doesn't), but then fails to associate, and this is what it spews: 
>
> ioctl[SIOCSIWAP]: Operation not permitted 
> ioctl[SIOCSIWESSID]: Operation not permitted 
> ioctl[SIOCSIWENCODEEXT]: Invalid argument 
> ioctl[SIOCSIWENCODEEXT]: Invalid argument 
> ioctl[SIOCSIWAP]: Operation not permitted 
> ioctl[SIOCSIWESSID]: Operation not permitted 
>
> 8192cu has regressed directly with the change from sunxi-3.0 to 
> sunxi-3.4. 
>
> I could of course go and try 8188eu, but for that i have to: 
> a) explicitely power on the usbc2 bus from script.bin 
> b) add a usb_wifi_para section to script.bin, especially for the 8188eu 
> driver. 
>
> You will find the above changes littered across our wiki and poorly 
> sprinkled into our sunxi-boards. This means that rtl8188* based boards 
> have mostly broken wifi with the script.bins in sunxi-boards. We also no 
> longer can claim that we can just grab script.bin from android, and it 
> will just work. 
>
> This kills one of the main advantages of our project, and puts us in the 
> same league as all the other ARM SoCs: only a handful of development 
> boards work. This is totally unacceptable. 
>
> Luc Verhaegen. 
>

-- 
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] uboot for Mele M3 A20

[Olliver Schinagl]

On 03/23/2014 06:27 PM, Rajesh Mallah wrote:

Hi,

I regularly search Alibaba market place for devices (TV boxes) can be
reused as low powered general purpose computers. Many of such devices
have debug
ports ( some do not have also ).

Most allwinner based devices on marketplace are A20 based, 1 GB model
A10 and A31  are not seen in general. In Quad core segment generally
device makers are
going for RK3188.  In in dual core segment AMLogic MX is also seen along
with RK3066.

My question is that is it really worth documenting such allwinner
devices in linux-sunxi
website ?
Yes, yes yes! The more devices are documented, the better it is for all 
of us :)


In this specific case, the Mele was our main target for a long time. 
Many developers still have Mele's. The A20 based mele for some reason 
has been skipped and has very little information however. Which is why 
we are very interested in the guts and glory :)


Olliver


There is no surety if such devices will even be seen after even 1 year
down the line.

Regds
mallah.

--
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.


--
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 u-boot-sunxi.git] sunxi: dram: checkpatch.pl cleanups

[Chen-Yu Tsai]

On Mon, Mar 24, 2014 at 4:39 PM, Ian Campbell  wrote:
> On Mon, 2014-03-24 at 12:55 +0800, Chen-Yu Tsai wrote:
>> Hi,
>>
>> On Mon, Mar 24, 2014 at 4:21 AM, Hans de Goede  wrote:
>> > Hi,
>> >
>> > On 03/23/2014 04:13 PM, Ian Campbell wrote:
>> >> On Sat, 2014-03-22 at 20:22 +0100, Hans de Goede wrote:
>> >>> One thing that stands out when doing a diff against 
>> >>> sunxi-merge-v2014.04-rc2
>> >>> is this:
>> >>>
>> >>> --- u-boot/drivers/net/designware.c 2014-03-21 16:26:42.229522420 
>> >>> +0100
>> >>> +++ u-boot-sunxi/drivers/net/designware.c   2014-03-22 
>> >>> 17:21:51.907879720 +
>> >>> @@ -249,10 +249,10 @@
>> >>> rx_descs_init(dev);
>> >>> tx_descs_init(dev);
>> >>>
>> >>> -   writel(FIXEDBURST | PRIORXTX_41 | BURST_16, &dma_p->busmode);
>> >>> +   writel(FIXEDBURST | PRIORXTX_41 | BURST_8, &dma_p->busmode);
>>
>> This is required. The GMAC IP does not support DMA burst lengths above 8.
>
> Should this be a per-platform option or should it be reduced for
> everyone? Having to make that call is one of the main reasons I've been
> leaving it alone since I just don't have the necessary context.

Reducing it for everyone shouldn't break anything. As for the performance
decrease, does anyone actually use U-boot to transfer loads of data?

>> >>> -   writel(readl(&dma_p->opmode) | FLUSHTXFIFO | STOREFORWARD,
>> >>> -  &dma_p->opmode);
>> >>> +   writel(readl(&dma_p->opmode) | FLUSHTXFIFO | STOREFORWARD |
>> >>> +   TXSECONDFRAME, &dma_p->opmode);
>>
>> This is a performance improvement change,
>
> What sort of magnitude is it? e.g. I'm not sure how important a few
> percent would be in a bootloader, but if it were a 200% improvement then
> well.
>
> In any case I think I won't tackle this bit as part of the initial
> upstreaming attempt.

A quick blame shows this was removed in

92a190a net/designware - switch driver to phylib usage

The whole section was reworked. I don't know if it was purposely left
out, or it was just an error. The commit log doesn't mention it.

As for the performance improvement, I don't think it would be up
to 200%, but I haven't tested it.


Cheers,
ChenYu

>> >> I was under the impression that Wens (or
>> >> someone else) had this under control WRT upstreaming so I was leaving it
>> >> for now,
>> >
>> > I'm not sure wens, or anyone for that matter is actively working on gmac
>> > u-boot support.
>>
>> Sorry, no one is actively working on this ATM. If you could do it, that
>> would be nice. Only a oneliner to change the burst length is required.
>
> I'll add it (the burst setting) to my list, but I may not do it until
> after the initial effort has gone upstream.
>
> 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 u-boot-sunxi.git] sunxi: dram: checkpatch.pl cleanups

[Ian Campbell]

On Mon, 2014-03-24 at 12:55 +0800, Chen-Yu Tsai wrote:
> Hi,
> 
> On Mon, Mar 24, 2014 at 4:21 AM, Hans de Goede  wrote:
> > Hi,
> >
> > On 03/23/2014 04:13 PM, Ian Campbell wrote:
> >> On Sat, 2014-03-22 at 20:22 +0100, Hans de Goede wrote:
> >>> One thing that stands out when doing a diff against 
> >>> sunxi-merge-v2014.04-rc2
> >>> is this:
> >>>
> >>> --- u-boot/drivers/net/designware.c 2014-03-21 16:26:42.229522420 
> >>> +0100
> >>> +++ u-boot-sunxi/drivers/net/designware.c   2014-03-22 
> >>> 17:21:51.907879720 +
> >>> @@ -249,10 +249,10 @@
> >>> rx_descs_init(dev);
> >>> tx_descs_init(dev);
> >>>
> >>> -   writel(FIXEDBURST | PRIORXTX_41 | BURST_16, &dma_p->busmode);
> >>> +   writel(FIXEDBURST | PRIORXTX_41 | BURST_8, &dma_p->busmode);
> 
> This is required. The GMAC IP does not support DMA burst lengths above 8.

Should this be a per-platform option or should it be reduced for
everyone? Having to make that call is one of the main reasons I've been
leaving it alone since I just don't have the necessary context.

> >>> -   writel(readl(&dma_p->opmode) | FLUSHTXFIFO | STOREFORWARD,
> >>> -  &dma_p->opmode);
> >>> +   writel(readl(&dma_p->opmode) | FLUSHTXFIFO | STOREFORWARD |
> >>> +   TXSECONDFRAME, &dma_p->opmode);
> 
> This is a performance improvement change,

What sort of magnitude is it? e.g. I'm not sure how important a few
percent would be in a bootloader, but if it were a 200% improvement then
well.

In any case I think I won't tackle this bit as part of the initial
upstreaming attempt.

> >> I was under the impression that Wens (or
> >> someone else) had this under control WRT upstreaming so I was leaving it
> >> for now,
> >
> > I'm not sure wens, or anyone for that matter is actively working on gmac
> > u-boot support.
> 
> Sorry, no one is actively working on this ATM. If you could do it, that
> would be nice. Only a oneliner to change the burst length is required.

I'll add it (the burst setting) to my list, but I may not do it until
after the initial effort has gone upstream.

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] Re: [PATCH v2 1/8] mfd: AXP20x: Add mfd driver for AXP20x PMIC

[Lee Jones]

> > > +static struct mfd_cell axp20x_cells[] = {
> > > + {
> > > + .name   = "axp20x-pek",
> > > + .num_resources  = ARRAY_SIZE(axp20x_pek_resources),
> > > + .resources  = axp20x_pek_resources,
> > > + }, {
> > > + .name   = "axp20x-regulator",
> > > + },
> > > +};
> > 
> > nit: The format of these two structs are inconsistent.
> 
> Uhm, what do you mean?

Well you've removed the struct above this one in your reply. Take a
look at my reply to you and see the differences between this _two_
structs, this being only one of them.

[...]

> > > +static const struct i2c_device_id axp20x_i2c_id[] = {
> > > + { "axp202", AXP202_ID },
> > > + { "axp209", AXP209_ID },
> > > + { }
> > > +};
> > > +MODULE_DEVICE_TABLE(i2c, axp20x_i2c_id);
> > 
> > Isn't this redundant now that you're using of_id?
> 
> It is not. Even it is unused it has to be in the driver otherwise the
> driver is not loaded. Probably it is something wrong in the I2C core.

Sorry, I should have been more specific. The I2C core requires this
struct, but the IDs are unused and redundant. Best remove them in
order to mitigate any confusion.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

-- 
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] Re: [PATCH 4/9] sunxi: only try to init dram once.

[Ian Campbell]

On Mon, 2014-03-24 at 00:21 +0100, Henrik Nordström wrote:
> sön 2014-03-16 klockan 17:34 + skrev Ian Campbell:
> > As Alex explains in [0] this triple call likely dates back to before the 
> > DRAM
> > init code used proper timings. It is not necessary any more.
> 
> maybe, but not comfortable removing it without some test showing that
> the problem is indeed solved.

Well all I can say is that it Worked For Me(tm) when I removed it.

Base on that and upstream's feedback the code upstreamed in my initial
attempt will only have a single call.

If someone has a platform which requires these triple calls (and it
sounds like you have one in mind) and it can't be fixed "properly" (e.g.
by changing the DRAM timings or something similar) then the extra calls
could be upstreamed as an independent patch which can come with a
concrete rationale (I can't really do that now as the board I'm
upstreaming doesn't appear to suffer from the issue).

> We found it randomly failing on reboot some boards, I think it was
> OLinuXino A13. Cold boot always worked. Then looked at Allwinner boot0
> code and copied retry from there.
> 
> The code is from Sun Nov 4 22:32:41 2012 (ffe3d4fb)

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+GIT 0/9] sunxi: upstream review based cleanups

[Ian Campbell]

On Mon, 2014-03-24 at 00:00 +0100, Henrik Nordström wrote:
> sön 2014-03-16 klockan 19:40 +0100 skrev Hans de Goede:
> 
> > 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.
> 
> Merges from upstream is always welcome. Just make sure it builds and
> boots on some board before pushing.

git://gitorious.org/ijc/u-boot.git sunxi-merge-v2014.04-rc2 should be
suitable, I tested it on cubietruck.

If not I will be creating an updated version of this branch as part of
preparing v3 of the upstreaming patches, so you could wait for that.

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 u-boot-sunxi.git] sunxi: dram: checkpatch.pl cleanups

[Hans de Goede]

Hi,

On 03/24/2014 12:04 AM, Henrik Nordström wrote:
> fre 2014-03-21 klockan 16:33 + skrev Ian Campbell:
> 
>> Thanks, I was really hoping we could pull mainline up to this level too
>> ASAP. I want to avoid the possibility of diverging into two forks with
>> different featuresets. But I guess hno isn't around so this will have to
>> do.
> 
> What is held back on me?

I was waiting for an ack from you to go ahead and pull in the merge
up to v2014.04-rc4 Ian did. Now that I've your ack I'll do so as soon as
I find some time for this.

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] GPIO EINT driver showing gpio_irq_hdl: handler failed

[Dave McLaughlin]

I've ported a touch driver to my system and each time the interrupt handler 
fires I am seeing this in the debug output.

gpio_irq_hdl: handler failed

I've checked the handler and it is passing back IRQ_HANDLED to this 
function so it appears to be a bug in the code here.

if (pdev_id->handler) {
if (pdev_id->handler(pdev_id->parg) != IRQ_HANDLED) {
PIO_ERR("%s: handler failed\n", __func__);
}
}


The above code would always indicate an error for any handler passing back 
the correct state as IRQ_HANDLED is defined as (1<<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.