Re: [PATCH v2 0/4] mtd: pxa3xx_nand: rework the timing setup
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 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
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) ? &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
Re: [PATCH v2 0/4] mtd: pxa3xx_nand: rework the timing setup
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) ? &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
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
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
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 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
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
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/
