Re: [PATCH v2 0/4] mtd: pxa3xx_nand: rework the timing setup

[Ezequiel Garcia]

On 17 July 2015 at 11:36, Ezequiel Garcia  wrote:
> Hi Antoine,
>
> On 07/17/2015 10:41 AM, Antoine Tenart wrote:
>>
>> Hi guys,
>>
>> On Tue, Jul 07, 2015 at 05:08:23PM +0200, Antoine Tenart wrote:
>>>
>>>
>>> This series was part of a bigger one[1], which was split into smaller
>>> ones as asked by Ezequiel[2]. When we take this into account, this is
>>> v7. In addition, there was absolutely no comment for more than 1 month
>>> (since June 2nd). Given this, I really expect the series to be merge
>>> soon as other series are based on this.
>>
>>
>> Any news on this series?
>>

Antoine,

Do you think you can respin this patchset and send a new one so we
can move forward? There might be still some issues with it (16-bit support),
but I think it'll be better to discuss them on a fresh patchset.

Don't forget to Cc Robert, since he's able to provide valuable input
and testing on PXA boards.

Thanks a lot,
-- 
Ezequiel García, VanguardiaSur
www.vanguardiasur.com.ar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 0/4] mtd: pxa3xx_nand: rework the timing setup

[Ezequiel Garcia]

On 17 July 2015 at 11:36, Ezequiel Garcia  wrote:
> Hi Antoine,
>
> On 07/17/2015 10:41 AM, Antoine Tenart wrote:
>>
>> Hi guys,
>>
>> On Tue, Jul 07, 2015 at 05:08:23PM +0200, Antoine Tenart wrote:
>>>
>>>
>>> This series was part of a bigger one[1], which was split into smaller
>>> ones as asked by Ezequiel[2]. When we take this into account, this is
>>> v7. In addition, there was absolutely no comment for more than 1 month
>>> (since June 2nd). Given this, I really expect the series to be merge
>>> soon as other series are based on this.
>>
>>
>> Any news on this series?
>>

Antoine,

Do you think you can respin this patchset and send a new one so we
can move forward? There might be still some issues with it (16-bit support),
but I think it'll be better to discuss them on a fresh patchset.

Don't forget to Cc Robert, since he's able to provide valuable input
and testing on PXA boards.

Thanks a lot,
-- 
Ezequiel García, VanguardiaSur
www.vanguardiasur.com.ar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 0/4] mtd: pxa3xx_nand: rework the timing setup

[Robert Jarzmik]

Ezequiel Garcia  writes:

>>
>> The issue I see is that :
>>  - there is a bug in the clk driver for pxa3xx I introduced (CKEN_AB)

>>  - and shutting down the GCU clock prevents the NAND from working (I can't
>>  explain that one yet)

Ah actually it's even trickier, but it has nothing to do with the GCU clock,
that was a wrong interpretation of the test sequence.

What actually happens is that on the platform I have, the NAND is sharing the
DFI bus with the Static Memory Controller. Now let's see what happens on
boot-up, knowing that my pxa3xx-nand is a module, not builtin :
 - the kernel boots
 - the core clock initializes
 - the ethernet card initializes (it is on the static memory controller)
 - the kernel finishes the boot sequence
   => the NAND clock is unused
   => as such, the core clock framework disables it

And here is the catch : on the next ethernet access, the system bus will be
stalled forever. The reason behind is that because the bootloader left the
"NDCR_ND_ARB_EN" bit enabled, the DFI bus sees the ethernet register access, and
asks for arbitration; as the NAND clock is down, the arbitration never happens,
and the pxa3xx is stalled forever.

The very same thing happens when you load and unload pxa3xx-nand with a platform
where it was loaded with "enable-arbiter" platform-data, and if that platform
has any driver mapped in the SMC address space (0x0 .. 0x1400).

If you have an opportunity to load/unload a pxa3xx-nand, I'd be glad to have
someone verify this theory.

The first fix comming to my mind would be to :
 - disable the NDCR_ND_ARB_EN in the pxa3xx core bring up
 - keep enablement in pxa3xx-nand
 - ensure it is disabled on the probe error path or remove of pxa3xx-nand

Cheers.

--
Robert

PS: That also means that the fix I posted for CKENA/CKENB inversion should fix
the issues you see.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 0/4] mtd: pxa3xx_nand: rework the timing setup

[Robert Jarzmik]

Ezequiel Garcia ezequ...@vanguardiasur.com.ar writes:


 The issue I see is that :
  - there is a bug in the clk driver for pxa3xx I introduced (CKEN_AB)

  - and shutting down the GCU clock prevents the NAND from working (I can't
  explain that one yet)

Ah actually it's even trickier, but it has nothing to do with the GCU clock,
that was a wrong interpretation of the test sequence.

What actually happens is that on the platform I have, the NAND is sharing the
DFI bus with the Static Memory Controller. Now let's see what happens on
boot-up, knowing that my pxa3xx-nand is a module, not builtin :
 - the kernel boots
 - the core clock initializes
 - the ethernet card initializes (it is on the static memory controller)
 - the kernel finishes the boot sequence
   = the NAND clock is unused
   = as such, the core clock framework disables it

And here is the catch : on the next ethernet access, the system bus will be
stalled forever. The reason behind is that because the bootloader left the
NDCR_ND_ARB_EN bit enabled, the DFI bus sees the ethernet register access, and
asks for arbitration; as the NAND clock is down, the arbitration never happens,
and the pxa3xx is stalled forever.

The very same thing happens when you load and unload pxa3xx-nand with a platform
where it was loaded with enable-arbiter platform-data, and if that platform
has any driver mapped in the SMC address space (0x0 .. 0x1400).

If you have an opportunity to load/unload a pxa3xx-nand, I'd be glad to have
someone verify this theory.

The first fix comming to my mind would be to :
 - disable the NDCR_ND_ARB_EN in the pxa3xx core bring up
 - keep enablement in pxa3xx-nand
 - ensure it is disabled on the probe error path or remove of pxa3xx-nand

Cheers.

--
Robert

PS: That also means that the fix I posted for CKENA/CKENB inversion should fix
the issues you see.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 0/4] mtd: pxa3xx_nand: rework the timing setup

[Ezequiel Garcia]

On 3 August 2015 at 01:44, Robert Jarzmik  wrote:
> Ezequiel Garcia  writes:
>
>> Just tested linux-next (hence *without* the patchset) and I see
>> the same "Wait time out". In other words, pxa3xx-nand is broken
>> on PXA :/
>>
>> Interestingly, the culprit doesn't seem to be in pxa3xx-nand itself.
>> Reverting the recent commits on pxa3xx-nand doesn't help.
>>
>> ce914e6 mtd: nand: pxa3xx: fix build on ARM64
>> afca11e mtd: nand: pxa3xx: Switch FIFO draining to jiffies-based timeout
>> e5860c1 mtd: pxa3xx_nand: cleanup wait_for_completion handling
>> 7c2f717 mtd: pxa3xx_nand: initialiaze pxa3xx_flash_ids to 0
>> ed446cc Merge MTD updates into -next
>> e423c90 mtd: pxa3xx_nand: fix driver when num_cs is 0
>> 2454225 mtd: pxa3xx-nand: handle PIO in threaded interrupt
>> 8dad038 mtd: nand: pxa3xx: Fix PIO FIFO draining
>> b7e46062 mtd: pxa3xx_nand: make the driver work on big-endian systems
>> 5b3e507 mtd: nand: pxa3xx: Use ECC strength and step size devicetree binding
>> eee0166 mtd: nand: pxa3xx: Clean pxa_ecc_init() error handling
>> 17754ad mtd: nand: pxa3xx: Make of_device_id array const
>> e634ce5 mtd: nand: pxa3xx: Print actual ECC strength in error message
>>
>> Yet v3.18 succeeds to pass a few NAND blocks on nandtest.
>>
>> Robert: any ideas?
> Actually yes, I worked on that this weekend.
> Would you try the following patch [1] to see if it works for you ?
>
> The issue I see is that :
>  - there is a bug in the clk driver for pxa3xx I introduced (CKEN_AB)
>  - and shutting down the GCU clock prevents the NAND from working (I can't
>  explain that one yet)
>

IIRC, on Armada 370/XP SoCs we have two clocks feeding the NAND
controller: one for the NAND logic (not really sure?), and one for the
NAND ECC engine.

Maybe the GCU feeds the ECC?

> Cheers.
>
> --
> Robert
>
> [1] Clocks patch

Ah, good. I was almost sure it was the clock (after trying a bunch of
other stuff it was the only big change left).

I'll try this and will let you know.

> ---8>---
> diff --git a/drivers/clk/pxa/clk-pxa3xx.c b/drivers/clk/pxa/clk-pxa3xx.c
> index c677b9ab5367..a47a0c40f937 100644
> --- a/drivers/clk/pxa/clk-pxa3xx.c
> +++ b/drivers/clk/pxa/clk-pxa3xx.c
> @@ -126,7 +126,7 @@ PARENTS(pxa3xx_ac97_bus) = { "ring_osc_60mhz", "ac97" };
>  PARENTS(pxa3xx_sbus) = { "ring_osc_60mhz", "system_bus" };
>  PARENTS(pxa3xx_smemcbus) = { "ring_osc_60mhz", "smemc" };
>
> -#define CKEN_AB(bit) ((CKEN_ ## bit > 31) ?  : )
> +#define CKEN_AB(bit) ((CKEN_ ## bit > 31) ?  : )
>  #define PXA3XX_CKEN(dev_id, con_id, parents, mult_lp, div_lp, mult_hp, \
> div_hp, bit, is_lp, flags)  \
> PXA_CKEN(dev_id, con_id, bit, parents, mult_lp, div_lp, \
> @@ -136,6 +136,10 @@ PARENTS(pxa3xx_smemcbus) = { "ring_osc_60mhz", "smemc" };
>  mult_hp, div_hp, delay)\
> PXA3XX_CKEN(dev_id, con_id, pxa3xx_pbus_parents, mult_lp,   \
> div_lp, mult_hp, div_hp, bit, pxa3xx_is_ring_osc_forced, 
> 0)
> +#define PXA3XX_PBUS_CKENF(dev_id, con_id, bit, mult_lp, div_lp,  
>   \
> + mult_hp, div_hp, delay, flag) \
> +   PXA3XX_CKEN(dev_id, con_id, pxa3xx_pbus_parents, mult_lp,   \
> +   div_lp, mult_hp, div_hp, bit, pxa3xx_is_ring_osc_forced, 
> flag)
>  #define PXA3XX_CKEN_1RATE(dev_id, con_id, bit, parents)  
>   \
> PXA_CKEN_1RATE(dev_id, con_id, bit, parents,\
>CKEN_AB(bit), (CKEN_ ## bit % 32), 0)
> @@ -173,13 +177,13 @@ static struct desc_clk_cken pxa3xx_clocks[] __initdata 
> = {
>
>  static struct desc_clk_cken pxa300_310_clocks[] __initdata = {
>
> -   PXA3XX_PBUS_CKEN("pxa3xx-gcu", NULL, PXA300_GCU, 1, 1, 1, 1, 0),
> -   PXA3XX_PBUS_CKEN("pxa3xx-nand", NULL, NAND, 1, 2, 1, 4, 0),
> +   PXA3XX_PBUS_CKENF("pxa3xx-gcu", NULL, PXA300_GCU, 1, 1, 1, 1, 0, 
> CLK_IGNORE_UNUSED),
> +   PXA3XX_PBUS_CKENF("pxa3xx-nand", NULL, NAND, 1, 2, 1, 4, 0, 
> CLK_IGNORE_UNUSED),
> PXA3XX_CKEN_1RATE("pxa3xx-gpio", NULL, GPIO, 
> pxa3xx_13MHz_bus_parents),
>  };
>
>  static struct desc_clk_cken pxa320_clocks[] __initdata = {
> -   PXA3XX_PBUS_CKEN("pxa3xx-nand", NULL, NAND, 1, 2, 1, 6, 0),
> +   PXA3XX_PBUS_CKENF("pxa3xx-nand", NULL, NAND, 1, 2, 1, 4, 0, 
> CLK_IGNORE_UNUSED),
> PXA3XX_PBUS_CKEN("pxa3xx-gcu", NULL, PXA320_GCU, 1, 1, 1, 1, 0),
> PXA3XX_CKEN_1RATE("pxa3xx-gpio", NULL, GPIO, 
> pxa3xx_13MHz_bus_parents),
>  };
> @@ -187,7 +191,7 @@ static struct desc_clk_cken pxa320_clocks[] __initdata = {
>  static struct desc_clk_cken pxa93x_clocks[] __initdata = {
>
> PXA3XX_PBUS_CKEN("pxa3xx-gcu", NULL, PXA300_GCU, 1, 1, 1, 1, 0),
> -   PXA3XX_PBUS_CKEN("pxa3xx-nand", NULL, NAND, 1, 2, 1, 4, 0),
> +   PXA3XX_PBUS_CKENF("pxa3xx-nand", NULL, NAND, 1, 2, 1, 4, 0, 
> CLK_IGNORE_UNUSED),
> PXA3XX_CKEN_1RATE("pxa93x-gpio", NULL, 

Re: [PATCH v2 0/4] mtd: pxa3xx_nand: rework the timing setup

[Ezequiel Garcia]

On 3 August 2015 at 01:44, Robert Jarzmik robert.jarz...@free.fr wrote:
 Ezequiel Garcia ezequ...@vanguardiasur.com.ar writes:

 Just tested linux-next (hence *without* the patchset) and I see
 the same Wait time out. In other words, pxa3xx-nand is broken
 on PXA :/

 Interestingly, the culprit doesn't seem to be in pxa3xx-nand itself.
 Reverting the recent commits on pxa3xx-nand doesn't help.

 ce914e6 mtd: nand: pxa3xx: fix build on ARM64
 afca11e mtd: nand: pxa3xx: Switch FIFO draining to jiffies-based timeout
 e5860c1 mtd: pxa3xx_nand: cleanup wait_for_completion handling
 7c2f717 mtd: pxa3xx_nand: initialiaze pxa3xx_flash_ids to 0
 ed446cc Merge MTD updates into -next
 e423c90 mtd: pxa3xx_nand: fix driver when num_cs is 0
 2454225 mtd: pxa3xx-nand: handle PIO in threaded interrupt
 8dad038 mtd: nand: pxa3xx: Fix PIO FIFO draining
 b7e46062 mtd: pxa3xx_nand: make the driver work on big-endian systems
 5b3e507 mtd: nand: pxa3xx: Use ECC strength and step size devicetree binding
 eee0166 mtd: nand: pxa3xx: Clean pxa_ecc_init() error handling
 17754ad mtd: nand: pxa3xx: Make of_device_id array const
 e634ce5 mtd: nand: pxa3xx: Print actual ECC strength in error message

 Yet v3.18 succeeds to pass a few NAND blocks on nandtest.

 Robert: any ideas?
 Actually yes, I worked on that this weekend.
 Would you try the following patch [1] to see if it works for you ?

 The issue I see is that :
  - there is a bug in the clk driver for pxa3xx I introduced (CKEN_AB)
  - and shutting down the GCU clock prevents the NAND from working (I can't
  explain that one yet)


IIRC, on Armada 370/XP SoCs we have two clocks feeding the NAND
controller: one for the NAND logic (not really sure?), and one for the
NAND ECC engine.

Maybe the GCU feeds the ECC?

 Cheers.

 --
 Robert

 [1] Clocks patch

Ah, good. I was almost sure it was the clock (after trying a bunch of
other stuff it was the only big change left).

I'll try this and will let you know.

 ---8---
 diff --git a/drivers/clk/pxa/clk-pxa3xx.c b/drivers/clk/pxa/clk-pxa3xx.c
 index c677b9ab5367..a47a0c40f937 100644
 --- a/drivers/clk/pxa/clk-pxa3xx.c
 +++ b/drivers/clk/pxa/clk-pxa3xx.c
 @@ -126,7 +126,7 @@ PARENTS(pxa3xx_ac97_bus) = { ring_osc_60mhz, ac97 };
  PARENTS(pxa3xx_sbus) = { ring_osc_60mhz, system_bus };
  PARENTS(pxa3xx_smemcbus) = { ring_osc_60mhz, smemc };

 -#define CKEN_AB(bit) ((CKEN_ ## bit  31) ? CKENA : CKENB)
 +#define CKEN_AB(bit) ((CKEN_ ## bit  31) ? CKENB : CKENA)
  #define PXA3XX_CKEN(dev_id, con_id, parents, mult_lp, div_lp, mult_hp, \
 div_hp, bit, is_lp, flags)  \
 PXA_CKEN(dev_id, con_id, bit, parents, mult_lp, div_lp, \
 @@ -136,6 +136,10 @@ PARENTS(pxa3xx_smemcbus) = { ring_osc_60mhz, smemc };
  mult_hp, div_hp, delay)\
 PXA3XX_CKEN(dev_id, con_id, pxa3xx_pbus_parents, mult_lp,   \
 div_lp, mult_hp, div_hp, bit, pxa3xx_is_ring_osc_forced, 
 0)
 +#define PXA3XX_PBUS_CKENF(dev_id, con_id, bit, mult_lp, div_lp,  
   \
 + mult_hp, div_hp, delay, flag) \
 +   PXA3XX_CKEN(dev_id, con_id, pxa3xx_pbus_parents, mult_lp,   \
 +   div_lp, mult_hp, div_hp, bit, pxa3xx_is_ring_osc_forced, 
 flag)
  #define PXA3XX_CKEN_1RATE(dev_id, con_id, bit, parents)  
   \
 PXA_CKEN_1RATE(dev_id, con_id, bit, parents,\
CKEN_AB(bit), (CKEN_ ## bit % 32), 0)
 @@ -173,13 +177,13 @@ static struct desc_clk_cken pxa3xx_clocks[] __initdata 
 = {

  static struct desc_clk_cken pxa300_310_clocks[] __initdata = {

 -   PXA3XX_PBUS_CKEN(pxa3xx-gcu, NULL, PXA300_GCU, 1, 1, 1, 1, 0),
 -   PXA3XX_PBUS_CKEN(pxa3xx-nand, NULL, NAND, 1, 2, 1, 4, 0),
 +   PXA3XX_PBUS_CKENF(pxa3xx-gcu, NULL, PXA300_GCU, 1, 1, 1, 1, 0, 
 CLK_IGNORE_UNUSED),
 +   PXA3XX_PBUS_CKENF(pxa3xx-nand, NULL, NAND, 1, 2, 1, 4, 0, 
 CLK_IGNORE_UNUSED),
 PXA3XX_CKEN_1RATE(pxa3xx-gpio, NULL, GPIO, 
 pxa3xx_13MHz_bus_parents),
  };

  static struct desc_clk_cken pxa320_clocks[] __initdata = {
 -   PXA3XX_PBUS_CKEN(pxa3xx-nand, NULL, NAND, 1, 2, 1, 6, 0),
 +   PXA3XX_PBUS_CKENF(pxa3xx-nand, NULL, NAND, 1, 2, 1, 4, 0, 
 CLK_IGNORE_UNUSED),
 PXA3XX_PBUS_CKEN(pxa3xx-gcu, NULL, PXA320_GCU, 1, 1, 1, 1, 0),
 PXA3XX_CKEN_1RATE(pxa3xx-gpio, NULL, GPIO, 
 pxa3xx_13MHz_bus_parents),
  };
 @@ -187,7 +191,7 @@ static struct desc_clk_cken pxa320_clocks[] __initdata = {
  static struct desc_clk_cken pxa93x_clocks[] __initdata = {

 PXA3XX_PBUS_CKEN(pxa3xx-gcu, NULL, PXA300_GCU, 1, 1, 1, 1, 0),
 -   PXA3XX_PBUS_CKEN(pxa3xx-nand, NULL, NAND, 1, 2, 1, 4, 0),
 +   PXA3XX_PBUS_CKENF(pxa3xx-nand, NULL, NAND, 1, 2, 1, 4, 0, 
 CLK_IGNORE_UNUSED),
 PXA3XX_CKEN_1RATE(pxa93x-gpio, NULL, GPIO, 
 pxa3xx_13MHz_bus_parents),
  };




-- 
Ezequiel García, VanguardiaSur

Re: [PATCH v2 0/4] mtd: pxa3xx_nand: rework the timing setup

[Robert Jarzmik]

Ezequiel Garcia  writes:

> Just tested linux-next (hence *without* the patchset) and I see
> the same "Wait time out". In other words, pxa3xx-nand is broken
> on PXA :/
>
> Interestingly, the culprit doesn't seem to be in pxa3xx-nand itself.
> Reverting the recent commits on pxa3xx-nand doesn't help.
>
> ce914e6 mtd: nand: pxa3xx: fix build on ARM64
> afca11e mtd: nand: pxa3xx: Switch FIFO draining to jiffies-based timeout
> e5860c1 mtd: pxa3xx_nand: cleanup wait_for_completion handling
> 7c2f717 mtd: pxa3xx_nand: initialiaze pxa3xx_flash_ids to 0
> ed446cc Merge MTD updates into -next
> e423c90 mtd: pxa3xx_nand: fix driver when num_cs is 0
> 2454225 mtd: pxa3xx-nand: handle PIO in threaded interrupt
> 8dad038 mtd: nand: pxa3xx: Fix PIO FIFO draining
> b7e46062 mtd: pxa3xx_nand: make the driver work on big-endian systems
> 5b3e507 mtd: nand: pxa3xx: Use ECC strength and step size devicetree binding
> eee0166 mtd: nand: pxa3xx: Clean pxa_ecc_init() error handling
> 17754ad mtd: nand: pxa3xx: Make of_device_id array const
> e634ce5 mtd: nand: pxa3xx: Print actual ECC strength in error message
>
> Yet v3.18 succeeds to pass a few NAND blocks on nandtest.
>
> Robert: any ideas?
Actually yes, I worked on that this weekend.
Would you try the following patch [1] to see if it works for you ?

The issue I see is that :
 - there is a bug in the clk driver for pxa3xx I introduced (CKEN_AB)
 - and shutting down the GCU clock prevents the NAND from working (I can't
 explain that one yet)

Cheers.

-- 
Robert

[1] Clocks patch
---8>---
diff --git a/drivers/clk/pxa/clk-pxa3xx.c b/drivers/clk/pxa/clk-pxa3xx.c
index c677b9ab5367..a47a0c40f937 100644
--- a/drivers/clk/pxa/clk-pxa3xx.c
+++ b/drivers/clk/pxa/clk-pxa3xx.c
@@ -126,7 +126,7 @@ PARENTS(pxa3xx_ac97_bus) = { "ring_osc_60mhz", "ac97" };
 PARENTS(pxa3xx_sbus) = { "ring_osc_60mhz", "system_bus" };
 PARENTS(pxa3xx_smemcbus) = { "ring_osc_60mhz", "smemc" };
 
-#define CKEN_AB(bit) ((CKEN_ ## bit > 31) ?  : )
+#define CKEN_AB(bit) ((CKEN_ ## bit > 31) ?  : )
 #define PXA3XX_CKEN(dev_id, con_id, parents, mult_lp, div_lp, mult_hp, \
div_hp, bit, is_lp, flags)  \
PXA_CKEN(dev_id, con_id, bit, parents, mult_lp, div_lp, \
@@ -136,6 +136,10 @@ PARENTS(pxa3xx_smemcbus) = { "ring_osc_60mhz", "smemc" };
 mult_hp, div_hp, delay)\
PXA3XX_CKEN(dev_id, con_id, pxa3xx_pbus_parents, mult_lp,   \
div_lp, mult_hp, div_hp, bit, pxa3xx_is_ring_osc_forced, 0)
+#define PXA3XX_PBUS_CKENF(dev_id, con_id, bit, mult_lp, div_lp,
\
+ mult_hp, div_hp, delay, flag) \
+   PXA3XX_CKEN(dev_id, con_id, pxa3xx_pbus_parents, mult_lp,   \
+   div_lp, mult_hp, div_hp, bit, pxa3xx_is_ring_osc_forced, 
flag)
 #define PXA3XX_CKEN_1RATE(dev_id, con_id, bit, parents)
\
PXA_CKEN_1RATE(dev_id, con_id, bit, parents,\
   CKEN_AB(bit), (CKEN_ ## bit % 32), 0)
@@ -173,13 +177,13 @@ static struct desc_clk_cken pxa3xx_clocks[] __initdata = {
 
 static struct desc_clk_cken pxa300_310_clocks[] __initdata = {
 
-   PXA3XX_PBUS_CKEN("pxa3xx-gcu", NULL, PXA300_GCU, 1, 1, 1, 1, 0),
-   PXA3XX_PBUS_CKEN("pxa3xx-nand", NULL, NAND, 1, 2, 1, 4, 0),
+   PXA3XX_PBUS_CKENF("pxa3xx-gcu", NULL, PXA300_GCU, 1, 1, 1, 1, 0, 
CLK_IGNORE_UNUSED),
+   PXA3XX_PBUS_CKENF("pxa3xx-nand", NULL, NAND, 1, 2, 1, 4, 0, 
CLK_IGNORE_UNUSED),
PXA3XX_CKEN_1RATE("pxa3xx-gpio", NULL, GPIO, pxa3xx_13MHz_bus_parents),
 };
 
 static struct desc_clk_cken pxa320_clocks[] __initdata = {
-   PXA3XX_PBUS_CKEN("pxa3xx-nand", NULL, NAND, 1, 2, 1, 6, 0),
+   PXA3XX_PBUS_CKENF("pxa3xx-nand", NULL, NAND, 1, 2, 1, 4, 0, 
CLK_IGNORE_UNUSED),
PXA3XX_PBUS_CKEN("pxa3xx-gcu", NULL, PXA320_GCU, 1, 1, 1, 1, 0),
PXA3XX_CKEN_1RATE("pxa3xx-gpio", NULL, GPIO, pxa3xx_13MHz_bus_parents),
 };
@@ -187,7 +191,7 @@ static struct desc_clk_cken pxa320_clocks[] __initdata = {
 static struct desc_clk_cken pxa93x_clocks[] __initdata = {
 
PXA3XX_PBUS_CKEN("pxa3xx-gcu", NULL, PXA300_GCU, 1, 1, 1, 1, 0),
-   PXA3XX_PBUS_CKEN("pxa3xx-nand", NULL, NAND, 1, 2, 1, 4, 0),
+   PXA3XX_PBUS_CKENF("pxa3xx-nand", NULL, NAND, 1, 2, 1, 4, 0, 
CLK_IGNORE_UNUSED),
PXA3XX_CKEN_1RATE("pxa93x-gpio", NULL, GPIO, pxa3xx_13MHz_bus_parents),
 };
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 0/4] mtd: pxa3xx_nand: rework the timing setup

[Ezequiel Garcia]

On 20 July 2015 at 16:49, Robert Jarzmik  wrote:
> Ezequiel Garcia  writes:
>
>> Here you go:
>>
>> http://git.infradead.org/users/ezequielg/linux/shortlog/refs/heads/pxa3xx-nand-timing-rework-v2
>
> Okay, I've tested this on cm-x300. The result is not bright :
> nand: device found, Manufacturer ID: 0xec, Chip ID: 0xdc
> nand: Samsung NAND 512MiB 3,3V 8-bit
> nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> pxa3xx-nand pxa3xx-nand: ECC strength 1, ECC step size 512
> Scanning device for bad blocks
> random: nonblocking pool is initialized
> Bad eraseblock 1037 at 0x081a
> Creating 6 MTD partitions on "pxa3xx_nand-0":
> 0x-0x0004 : "OBM"
> 0x0004-0x0008 : "U-Boot"
> 0x0008-0x000c : "Environment"
> 0x000c-0x0020 : "reserved"
> 0x0020-0x0060 : "kernel"
> 0x0060-0x2000 : "fs"
>
> The bad black is not bad normally.
> And then :
> # dd if=/dev/mtd0 of=toto count=1
> pxa3xx-nand pxa3xx-nand: Wait time out!!!
> 1+0 records in
> 1+0 records out
> # ls -l toto
> -rw-r--r--1 root root   512 Jan  1 00:02 toto
> # hexdump-C toto
>   ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  
> ||
> *
> 0200
>
> That's not possible, as it should have dumped the OBMI.
>
> And yet, I hesitate to incriminate this patchset, I will try without it. It 
> wont
> be very fast, as my USB to serial converter just broke, and my order will 
> take a
> couple of days to complete.
>

Just tested linux-next (hence *without* the patchset) and I see
the same "Wait time out". In other words, pxa3xx-nand is broken
on PXA :/

Interestingly, the culprit doesn't seem to be in pxa3xx-nand itself.
Reverting the recent commits on pxa3xx-nand doesn't help.

ce914e6 mtd: nand: pxa3xx: fix build on ARM64
afca11e mtd: nand: pxa3xx: Switch FIFO draining to jiffies-based timeout
e5860c1 mtd: pxa3xx_nand: cleanup wait_for_completion handling
7c2f717 mtd: pxa3xx_nand: initialiaze pxa3xx_flash_ids to 0
ed446cc Merge MTD updates into -next
e423c90 mtd: pxa3xx_nand: fix driver when num_cs is 0
2454225 mtd: pxa3xx-nand: handle PIO in threaded interrupt
8dad038 mtd: nand: pxa3xx: Fix PIO FIFO draining
b7e46062 mtd: pxa3xx_nand: make the driver work on big-endian systems
5b3e507 mtd: nand: pxa3xx: Use ECC strength and step size devicetree binding
eee0166 mtd: nand: pxa3xx: Clean pxa_ecc_init() error handling
17754ad mtd: nand: pxa3xx: Make of_device_id array const
e634ce5 mtd: nand: pxa3xx: Print actual ECC strength in error message

Yet v3.18 succeeds to pass a few NAND blocks on nandtest.

Robert: any ideas?
-- 
Ezequiel García, VanguardiaSur
www.vanguardiasur.com.ar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 0/4] mtd: pxa3xx_nand: rework the timing setup

[Robert Jarzmik]

Ezequiel Garcia ezequ...@vanguardiasur.com.ar writes:

 Just tested linux-next (hence *without* the patchset) and I see
 the same Wait time out. In other words, pxa3xx-nand is broken
 on PXA :/

 Interestingly, the culprit doesn't seem to be in pxa3xx-nand itself.
 Reverting the recent commits on pxa3xx-nand doesn't help.

 ce914e6 mtd: nand: pxa3xx: fix build on ARM64
 afca11e mtd: nand: pxa3xx: Switch FIFO draining to jiffies-based timeout
 e5860c1 mtd: pxa3xx_nand: cleanup wait_for_completion handling
 7c2f717 mtd: pxa3xx_nand: initialiaze pxa3xx_flash_ids to 0
 ed446cc Merge MTD updates into -next
 e423c90 mtd: pxa3xx_nand: fix driver when num_cs is 0
 2454225 mtd: pxa3xx-nand: handle PIO in threaded interrupt
 8dad038 mtd: nand: pxa3xx: Fix PIO FIFO draining
 b7e46062 mtd: pxa3xx_nand: make the driver work on big-endian systems
 5b3e507 mtd: nand: pxa3xx: Use ECC strength and step size devicetree binding
 eee0166 mtd: nand: pxa3xx: Clean pxa_ecc_init() error handling
 17754ad mtd: nand: pxa3xx: Make of_device_id array const
 e634ce5 mtd: nand: pxa3xx: Print actual ECC strength in error message

 Yet v3.18 succeeds to pass a few NAND blocks on nandtest.

 Robert: any ideas?
Actually yes, I worked on that this weekend.
Would you try the following patch [1] to see if it works for you ?

The issue I see is that :
 - there is a bug in the clk driver for pxa3xx I introduced (CKEN_AB)
 - and shutting down the GCU clock prevents the NAND from working (I can't
 explain that one yet)

Cheers.

-- 
Robert

[1] Clocks patch
---8---
diff --git a/drivers/clk/pxa/clk-pxa3xx.c b/drivers/clk/pxa/clk-pxa3xx.c
index c677b9ab5367..a47a0c40f937 100644
--- a/drivers/clk/pxa/clk-pxa3xx.c
+++ b/drivers/clk/pxa/clk-pxa3xx.c
@@ -126,7 +126,7 @@ PARENTS(pxa3xx_ac97_bus) = { ring_osc_60mhz, ac97 };
 PARENTS(pxa3xx_sbus) = { ring_osc_60mhz, system_bus };
 PARENTS(pxa3xx_smemcbus) = { ring_osc_60mhz, smemc };
 
-#define CKEN_AB(bit) ((CKEN_ ## bit  31) ? CKENA : CKENB)
+#define CKEN_AB(bit) ((CKEN_ ## bit  31) ? CKENB : CKENA)
 #define PXA3XX_CKEN(dev_id, con_id, parents, mult_lp, div_lp, mult_hp, \
div_hp, bit, is_lp, flags)  \
PXA_CKEN(dev_id, con_id, bit, parents, mult_lp, div_lp, \
@@ -136,6 +136,10 @@ PARENTS(pxa3xx_smemcbus) = { ring_osc_60mhz, smemc };
 mult_hp, div_hp, delay)\
PXA3XX_CKEN(dev_id, con_id, pxa3xx_pbus_parents, mult_lp,   \
div_lp, mult_hp, div_hp, bit, pxa3xx_is_ring_osc_forced, 0)
+#define PXA3XX_PBUS_CKENF(dev_id, con_id, bit, mult_lp, div_lp,
\
+ mult_hp, div_hp, delay, flag) \
+   PXA3XX_CKEN(dev_id, con_id, pxa3xx_pbus_parents, mult_lp,   \
+   div_lp, mult_hp, div_hp, bit, pxa3xx_is_ring_osc_forced, 
flag)
 #define PXA3XX_CKEN_1RATE(dev_id, con_id, bit, parents)
\
PXA_CKEN_1RATE(dev_id, con_id, bit, parents,\
   CKEN_AB(bit), (CKEN_ ## bit % 32), 0)
@@ -173,13 +177,13 @@ static struct desc_clk_cken pxa3xx_clocks[] __initdata = {
 
 static struct desc_clk_cken pxa300_310_clocks[] __initdata = {
 
-   PXA3XX_PBUS_CKEN(pxa3xx-gcu, NULL, PXA300_GCU, 1, 1, 1, 1, 0),
-   PXA3XX_PBUS_CKEN(pxa3xx-nand, NULL, NAND, 1, 2, 1, 4, 0),
+   PXA3XX_PBUS_CKENF(pxa3xx-gcu, NULL, PXA300_GCU, 1, 1, 1, 1, 0, 
CLK_IGNORE_UNUSED),
+   PXA3XX_PBUS_CKENF(pxa3xx-nand, NULL, NAND, 1, 2, 1, 4, 0, 
CLK_IGNORE_UNUSED),
PXA3XX_CKEN_1RATE(pxa3xx-gpio, NULL, GPIO, pxa3xx_13MHz_bus_parents),
 };
 
 static struct desc_clk_cken pxa320_clocks[] __initdata = {
-   PXA3XX_PBUS_CKEN(pxa3xx-nand, NULL, NAND, 1, 2, 1, 6, 0),
+   PXA3XX_PBUS_CKENF(pxa3xx-nand, NULL, NAND, 1, 2, 1, 4, 0, 
CLK_IGNORE_UNUSED),
PXA3XX_PBUS_CKEN(pxa3xx-gcu, NULL, PXA320_GCU, 1, 1, 1, 1, 0),
PXA3XX_CKEN_1RATE(pxa3xx-gpio, NULL, GPIO, pxa3xx_13MHz_bus_parents),
 };
@@ -187,7 +191,7 @@ static struct desc_clk_cken pxa320_clocks[] __initdata = {
 static struct desc_clk_cken pxa93x_clocks[] __initdata = {
 
PXA3XX_PBUS_CKEN(pxa3xx-gcu, NULL, PXA300_GCU, 1, 1, 1, 1, 0),
-   PXA3XX_PBUS_CKEN(pxa3xx-nand, NULL, NAND, 1, 2, 1, 4, 0),
+   PXA3XX_PBUS_CKENF(pxa3xx-nand, NULL, NAND, 1, 2, 1, 4, 0, 
CLK_IGNORE_UNUSED),
PXA3XX_CKEN_1RATE(pxa93x-gpio, NULL, GPIO, pxa3xx_13MHz_bus_parents),
 };
 
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 0/4] mtd: pxa3xx_nand: rework the timing setup

[Ezequiel Garcia]

On 20 July 2015 at 16:49, Robert Jarzmik robert.jarz...@free.fr wrote:
 Ezequiel Garcia ezequ...@vanguardiasur.com.ar writes:

 Here you go:

 http://git.infradead.org/users/ezequielg/linux/shortlog/refs/heads/pxa3xx-nand-timing-rework-v2

 Okay, I've tested this on cm-x300. The result is not bright :
 nand: device found, Manufacturer ID: 0xec, Chip ID: 0xdc
 nand: Samsung NAND 512MiB 3,3V 8-bit
 nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
 pxa3xx-nand pxa3xx-nand: ECC strength 1, ECC step size 512
 Scanning device for bad blocks
 random: nonblocking pool is initialized
 Bad eraseblock 1037 at 0x081a
 Creating 6 MTD partitions on pxa3xx_nand-0:
 0x-0x0004 : OBM
 0x0004-0x0008 : U-Boot
 0x0008-0x000c : Environment
 0x000c-0x0020 : reserved
 0x0020-0x0060 : kernel
 0x0060-0x2000 : fs

 The bad black is not bad normally.
 And then :
 # dd if=/dev/mtd0 of=toto count=1
 pxa3xx-nand pxa3xx-nand: Wait time out!!!
 1+0 records in
 1+0 records out
 # ls -l toto
 -rw-r--r--1 root root   512 Jan  1 00:02 toto
 # hexdump-C toto
   ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  
 ||
 *
 0200

 That's not possible, as it should have dumped the OBMI.

 And yet, I hesitate to incriminate this patchset, I will try without it. It 
 wont
 be very fast, as my USB to serial converter just broke, and my order will 
 take a
 couple of days to complete.


Just tested linux-next (hence *without* the patchset) and I see
the same Wait time out. In other words, pxa3xx-nand is broken
on PXA :/

Interestingly, the culprit doesn't seem to be in pxa3xx-nand itself.
Reverting the recent commits on pxa3xx-nand doesn't help.

ce914e6 mtd: nand: pxa3xx: fix build on ARM64
afca11e mtd: nand: pxa3xx: Switch FIFO draining to jiffies-based timeout
e5860c1 mtd: pxa3xx_nand: cleanup wait_for_completion handling
7c2f717 mtd: pxa3xx_nand: initialiaze pxa3xx_flash_ids to 0
ed446cc Merge MTD updates into -next
e423c90 mtd: pxa3xx_nand: fix driver when num_cs is 0
2454225 mtd: pxa3xx-nand: handle PIO in threaded interrupt
8dad038 mtd: nand: pxa3xx: Fix PIO FIFO draining
b7e46062 mtd: pxa3xx_nand: make the driver work on big-endian systems
5b3e507 mtd: nand: pxa3xx: Use ECC strength and step size devicetree binding
eee0166 mtd: nand: pxa3xx: Clean pxa_ecc_init() error handling
17754ad mtd: nand: pxa3xx: Make of_device_id array const
e634ce5 mtd: nand: pxa3xx: Print actual ECC strength in error message

Yet v3.18 succeeds to pass a few NAND blocks on nandtest.

Robert: any ideas?
-- 
Ezequiel García, VanguardiaSur
www.vanguardiasur.com.ar
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 0/4] mtd: pxa3xx_nand: rework the timing setup

[Robert Jarzmik]

Ezequiel Garcia  writes:

> Here you go:
>
> http://git.infradead.org/users/ezequielg/linux/shortlog/refs/heads/pxa3xx-nand-timing-rework-v2

Okay, I've tested this on cm-x300. The result is not bright :
nand: device found, Manufacturer ID: 0xec, Chip ID: 0xdc
nand: Samsung NAND 512MiB 3,3V 8-bit
nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
pxa3xx-nand pxa3xx-nand: ECC strength 1, ECC step size 512
Scanning device for bad blocks
random: nonblocking pool is initialized
Bad eraseblock 1037 at 0x081a
Creating 6 MTD partitions on "pxa3xx_nand-0":
0x-0x0004 : "OBM"
0x0004-0x0008 : "U-Boot"
0x0008-0x000c : "Environment"
0x000c-0x0020 : "reserved"
0x0020-0x0060 : "kernel"
0x0060-0x2000 : "fs"

The bad black is not bad normally.
And then :
# dd if=/dev/mtd0 of=toto count=1
pxa3xx-nand pxa3xx-nand: Wait time out!!!
1+0 records in
1+0 records out
# ls -l toto
-rw-r--r--1 root root   512 Jan  1 00:02 toto
# hexdump-C toto
  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  
||
*
0200

That's not possible, as it should have dumped the OBMI.

And yet, I hesitate to incriminate this patchset, I will try without it. It wont
be very fast, as my USB to serial converter just broke, and my order will take a
couple of days to complete.

And of course without this converter I cannot test anymore, especially the
zylonite board which will be more interesting.

So I'll report back as soon as the UK mail has completed the shipment.

Cheers.

-- 
Robert
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 0/4] mtd: pxa3xx_nand: rework the timing setup

[Robert Jarzmik]

Ezequiel Garcia ezequ...@vanguardiasur.com.ar writes:

 Here you go:

 http://git.infradead.org/users/ezequielg/linux/shortlog/refs/heads/pxa3xx-nand-timing-rework-v2

Okay, I've tested this on cm-x300. The result is not bright :
nand: device found, Manufacturer ID: 0xec, Chip ID: 0xdc
nand: Samsung NAND 512MiB 3,3V 8-bit
nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
pxa3xx-nand pxa3xx-nand: ECC strength 1, ECC step size 512
Scanning device for bad blocks
random: nonblocking pool is initialized
Bad eraseblock 1037 at 0x081a
Creating 6 MTD partitions on pxa3xx_nand-0:
0x-0x0004 : OBM
0x0004-0x0008 : U-Boot
0x0008-0x000c : Environment
0x000c-0x0020 : reserved
0x0020-0x0060 : kernel
0x0060-0x2000 : fs

The bad black is not bad normally.
And then :
# dd if=/dev/mtd0 of=toto count=1
pxa3xx-nand pxa3xx-nand: Wait time out!!!
1+0 records in
1+0 records out
# ls -l toto
-rw-r--r--1 root root   512 Jan  1 00:02 toto
# hexdump-C toto
  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  
||
*
0200

That's not possible, as it should have dumped the OBMI.

And yet, I hesitate to incriminate this patchset, I will try without it. It wont
be very fast, as my USB to serial converter just broke, and my order will take a
couple of days to complete.

And of course without this converter I cannot test anymore, especially the
zylonite board which will be more interesting.

So I'll report back as soon as the UK mail has completed the shipment.

Cheers.

-- 
Robert
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 0/4] mtd: pxa3xx_nand: rework the timing setup

[Ezequiel Garcia]

On 17 July 2015 at 14:55, Robert Jarzmik  wrote:
> Ezequiel Garcia  writes:
>
>> Hi Antoine,
>>
>> On 07/17/2015 10:41 AM, Antoine Tenart wrote:
>>> Hi guys,
>>>
>>> On Tue, Jul 07, 2015 at 05:08:23PM +0200, Antoine Tenart wrote:

 This series was part of a bigger one[1], which was split into smaller
 ones as asked by Ezequiel[2]. When we take this into account, this is
 v7. In addition, there was absolutely no comment for more than 1 month
 (since June 2nd). Given this, I really expect the series to be merge
 soon as other series are based on this.
>>>
>>> Any news on this series?
>>>
>>
>> I'll try to take a look and do some testing over the weekend.
>>
>> Robert: think you can test this on a pxa board? I have one here,
>> but it's non trivial for me to set it up.
>
> Sure, if somebody sends patches to me, it's very easy and automated, so please
> send the whole serie to robert.jarz...@free.fr, and I'll reply to this mail 
> with
> the test result on both cm-x300 and zylonite board.
>

Here you go:

http://git.infradead.org/users/ezequielg/linux/shortlog/refs/heads/pxa3xx-nand-timing-rework-v2

-- 
Ezequiel García, VanguardiaSur
www.vanguardiasur.com.ar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 0/4] mtd: pxa3xx_nand: rework the timing setup

[Ezequiel Garcia]

On 17 July 2015 at 14:55, Robert Jarzmik robert.jarz...@free.fr wrote:
 Ezequiel Garcia ezequ...@vanguardiasur.com.ar writes:

 Hi Antoine,

 On 07/17/2015 10:41 AM, Antoine Tenart wrote:
 Hi guys,

 On Tue, Jul 07, 2015 at 05:08:23PM +0200, Antoine Tenart wrote:

 This series was part of a bigger one[1], which was split into smaller
 ones as asked by Ezequiel[2]. When we take this into account, this is
 v7. In addition, there was absolutely no comment for more than 1 month
 (since June 2nd). Given this, I really expect the series to be merge
 soon as other series are based on this.

 Any news on this series?


 I'll try to take a look and do some testing over the weekend.

 Robert: think you can test this on a pxa board? I have one here,
 but it's non trivial for me to set it up.

 Sure, if somebody sends patches to me, it's very easy and automated, so please
 send the whole serie to robert.jarz...@free.fr, and I'll reply to this mail 
 with
 the test result on both cm-x300 and zylonite board.


Here you go:

http://git.infradead.org/users/ezequielg/linux/shortlog/refs/heads/pxa3xx-nand-timing-rework-v2

-- 
Ezequiel García, VanguardiaSur
www.vanguardiasur.com.ar
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 0/4] mtd: pxa3xx_nand: rework the timing setup

[Robert Jarzmik]

Ezequiel Garcia  writes:

> Hi Antoine,
>
> On 07/17/2015 10:41 AM, Antoine Tenart wrote:
>> Hi guys,
>>
>> On Tue, Jul 07, 2015 at 05:08:23PM +0200, Antoine Tenart wrote:
>>>
>>> This series was part of a bigger one[1], which was split into smaller
>>> ones as asked by Ezequiel[2]. When we take this into account, this is
>>> v7. In addition, there was absolutely no comment for more than 1 month
>>> (since June 2nd). Given this, I really expect the series to be merge
>>> soon as other series are based on this.
>>
>> Any news on this series?
>>
>
> I'll try to take a look and do some testing over the weekend.
>
> Robert: think you can test this on a pxa board? I have one here,
> but it's non trivial for me to set it up.

Sure, if somebody sends patches to me, it's very easy and automated, so please
send the whole serie to robert.jarz...@free.fr, and I'll reply to this mail with
the test result on both cm-x300 and zylonite board.

Cheers.

-- 
Robert
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 0/4] mtd: pxa3xx_nand: rework the timing setup

[Ezequiel Garcia]

Hi Antoine,

On 07/17/2015 10:41 AM, Antoine Tenart wrote:

Hi guys,

On Tue, Jul 07, 2015 at 05:08:23PM +0200, Antoine Tenart wrote:


This series was part of a bigger one[1], which was split into smaller
ones as asked by Ezequiel[2]. When we take this into account, this is
v7. In addition, there was absolutely no comment for more than 1 month
(since June 2nd). Given this, I really expect the series to be merge
soon as other series are based on this.


Any news on this series?



I'll try to take a look and do some testing over the weekend.

Robert: think you can test this on a pxa board? I have one here,
but it's non trivial for me to set it up.

Thanks,
--
Ezequiel Garcia, VanguardiaSur
www.vanguardiasur.com.ar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 0/4] mtd: pxa3xx_nand: rework the timing setup

[Antoine Tenart]

Hi guys,

On Tue, Jul 07, 2015 at 05:08:23PM +0200, Antoine Tenart wrote:
> 
> This series was part of a bigger one[1], which was split into smaller
> ones as asked by Ezequiel[2]. When we take this into account, this is
> v7. In addition, there was absolutely no comment for more than 1 month
> (since June 2nd). Given this, I really expect the series to be merge
> soon as other series are based on this.

Any news on this series?

Thanks,

Antoine

> The aim here is to use the nand framework to setup the timings,
> while keeping the old in-driver way of configuration timings for
> compatibility reasons.
> 
> Since v1:
>   - Rebased on top of v4.2-rc1
> 
> Since the series was split up:
> - reworked the ndcr setup
> - removed the read_id_bytes update after device detection
> 
> [1] https://lkml.org/lkml/2015/5/11/495
> [2] https://lkml.org/lkml/2015/5/16/309
> 
> Antoine Tenart (4):
>   mtd: pxa3xx_nand: add a default chunk size
>   mtd: pxa3xx_nand: add helpers to setup the timings
>   mtd: pxa3xx_nand: rework flash detection and timing setup
>   mtd: pxa3xx_nand: clean up the pxa3xx timings
> 
>  drivers/mtd/nand/pxa3xx_nand.c| 251 
> ++
>  include/linux/platform_data/mtd-nand-pxa3xx.h |  11 +-
>  2 files changed, 143 insertions(+), 119 deletions(-)
> 
> -- 
> 2.4.5
> 

-- 
Antoine Ténart, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 0/4] mtd: pxa3xx_nand: rework the timing setup

[Ezequiel Garcia]

Hi Antoine,

On 07/17/2015 10:41 AM, Antoine Tenart wrote:

Hi guys,

On Tue, Jul 07, 2015 at 05:08:23PM +0200, Antoine Tenart wrote:


This series was part of a bigger one[1], which was split into smaller
ones as asked by Ezequiel[2]. When we take this into account, this is
v7. In addition, there was absolutely no comment for more than 1 month
(since June 2nd). Given this, I really expect the series to be merge
soon as other series are based on this.


Any news on this series?



I'll try to take a look and do some testing over the weekend.

Robert: think you can test this on a pxa board? I have one here,
but it's non trivial for me to set it up.

Thanks,
--
Ezequiel Garcia, VanguardiaSur
www.vanguardiasur.com.ar
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 0/4] mtd: pxa3xx_nand: rework the timing setup

[Antoine Tenart]

Hi guys,

On Tue, Jul 07, 2015 at 05:08:23PM +0200, Antoine Tenart wrote:
 
 This series was part of a bigger one[1], which was split into smaller
 ones as asked by Ezequiel[2]. When we take this into account, this is
 v7. In addition, there was absolutely no comment for more than 1 month
 (since June 2nd). Given this, I really expect the series to be merge
 soon as other series are based on this.

Any news on this series?

Thanks,

Antoine

 The aim here is to use the nand framework to setup the timings,
 while keeping the old in-driver way of configuration timings for
 compatibility reasons.
 
 Since v1:
   - Rebased on top of v4.2-rc1
 
 Since the series was split up:
 - reworked the ndcr setup
 - removed the read_id_bytes update after device detection
 
 [1] https://lkml.org/lkml/2015/5/11/495
 [2] https://lkml.org/lkml/2015/5/16/309
 
 Antoine Tenart (4):
   mtd: pxa3xx_nand: add a default chunk size
   mtd: pxa3xx_nand: add helpers to setup the timings
   mtd: pxa3xx_nand: rework flash detection and timing setup
   mtd: pxa3xx_nand: clean up the pxa3xx timings
 
  drivers/mtd/nand/pxa3xx_nand.c| 251 
 ++
  include/linux/platform_data/mtd-nand-pxa3xx.h |  11 +-
  2 files changed, 143 insertions(+), 119 deletions(-)
 
 -- 
 2.4.5
 

-- 
Antoine Ténart, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 0/4] mtd: pxa3xx_nand: rework the timing setup

[Robert Jarzmik]

Ezequiel Garcia ezequ...@vanguardiasur.com.ar writes:

 Hi Antoine,

 On 07/17/2015 10:41 AM, Antoine Tenart wrote:
 Hi guys,

 On Tue, Jul 07, 2015 at 05:08:23PM +0200, Antoine Tenart wrote:

 This series was part of a bigger one[1], which was split into smaller
 ones as asked by Ezequiel[2]. When we take this into account, this is
 v7. In addition, there was absolutely no comment for more than 1 month
 (since June 2nd). Given this, I really expect the series to be merge
 soon as other series are based on this.

 Any news on this series?


 I'll try to take a look and do some testing over the weekend.

 Robert: think you can test this on a pxa board? I have one here,
 but it's non trivial for me to set it up.

Sure, if somebody sends patches to me, it's very easy and automated, so please
send the whole serie to robert.jarz...@free.fr, and I'll reply to this mail with
the test result on both cm-x300 and zylonite board.

Cheers.

-- 
Robert
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 0/4] mtd: pxa3xx_nand: rework the timing setup

[Antoine Tenart]

Hi,

This series was part of a bigger one[1], which was split into smaller
ones as asked by Ezequiel[2]. When we take this into account, this is
v7. In addition, there was absolutely no comment for more than 1 month
(since June 2nd). Given this, I really expect the series to be merge
soon as other series are based on this.

The aim here is to use the nand framework to setup the timings,
while keeping the old in-driver way of configuration timings for
compatibility reasons.

Since v1:
- Rebased on top of v4.2-rc1

Since the series was split up:
- reworked the ndcr setup
- removed the read_id_bytes update after device detection

[1] https://lkml.org/lkml/2015/5/11/495
[2] https://lkml.org/lkml/2015/5/16/309

Antoine Tenart (4):
  mtd: pxa3xx_nand: add a default chunk size
  mtd: pxa3xx_nand: add helpers to setup the timings
  mtd: pxa3xx_nand: rework flash detection and timing setup
  mtd: pxa3xx_nand: clean up the pxa3xx timings

 drivers/mtd/nand/pxa3xx_nand.c| 251 ++
 include/linux/platform_data/mtd-nand-pxa3xx.h |  11 +-
 2 files changed, 143 insertions(+), 119 deletions(-)

-- 
2.4.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 0/4] mtd: pxa3xx_nand: rework the timing setup

[Antoine Tenart]

Hi,

This series was part of a bigger one[1], which was split into smaller
ones as asked by Ezequiel[2]. When we take this into account, this is
v7. In addition, there was absolutely no comment for more than 1 month
(since June 2nd). Given this, I really expect the series to be merge
soon as other series are based on this.

The aim here is to use the nand framework to setup the timings,
while keeping the old in-driver way of configuration timings for
compatibility reasons.

Since v1:
- Rebased on top of v4.2-rc1

Since the series was split up:
- reworked the ndcr setup
- removed the read_id_bytes update after device detection

[1] https://lkml.org/lkml/2015/5/11/495
[2] https://lkml.org/lkml/2015/5/16/309

Antoine Tenart (4):
  mtd: pxa3xx_nand: add a default chunk size
  mtd: pxa3xx_nand: add helpers to setup the timings
  mtd: pxa3xx_nand: rework flash detection and timing setup
  mtd: pxa3xx_nand: clean up the pxa3xx timings

 drivers/mtd/nand/pxa3xx_nand.c| 251 ++
 include/linux/platform_data/mtd-nand-pxa3xx.h |  11 +-
 2 files changed, 143 insertions(+), 119 deletions(-)

-- 
2.4.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/