Re: [PATCH v3] ARM: OMAP3: gpmc: add BCH ecc api and modes
On Thu, 2012-05-10 at 19:45 +0200, Ivan Djelic wrote: On Thu, May 10, 2012 at 04:52:18PM +0100, Artem Bityutskiy wrote: On Thu, 2012-05-10 at 17:17 +0200, Ivan Djelic wrote: But in order to do so, I need the changes that Afzal has submitted (in particular [3]). Those changes (and as a consequence, my new patch) won't hit 3.5. So, when Afzal's patches are pushed, I'll submit a new, single MTD patch. But this is not going to happen this merge window as I understood, may be not even the next one. We need to make UBIFS happy sooner than that, I think. So may be we go forward with your original patch? I'm OK with this too, as the patches are ready and tested. The MTD patch is [2], it depends on [1] which has been pushed, then dropped by Tony. Do you need me to repost [2] ? Tony, sorry to backpedal on this: would you re-push patch [1], if indeed Afzal's patches are not going to be merged soon ? In the meantime, I can prepare a patch on top of Afzal's to have a smooth transition w.r.t BCH support. What do you think ? OK, since we now have Tony's ack - I have applied both patches to l2-mtd.git. Thanks. I have a question though - will send separately. -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part
RE: [PATCH v3] ARM: OMAP3: gpmc: add BCH ecc api and modes
Hi Ivan, On Thu, May 10, 2012 at 23:15:27, Ivan Djelic wrote: So, when Afzal's patches are pushed, I'll submit a new, single MTD patch. But this is not going to happen this merge window as I understood, may be not even the next one. We need to make UBIFS happy sooner than that, I think. So may be we go forward with your original patch? I'm OK with this too, as the patches are ready and tested. The MTD patch is [2], it depends on [1] which has been pushed, then dropped by Tony. Do you need me to repost [2] ? Tony, sorry to backpedal on this: would you re-push patch [1], if indeed Afzal's patches are not going to be merged soon ? In the meantime, I can prepare a patch on top of Afzal's to have a smooth transition w.r.t BCH support. What do you think ? A new series [A-D] has been sent for handling GPMC NAND registers by NAND driver itself. This is being targeted for 3.5. Hopefully if every one is in agreement, we can avoid patching for BCH support again when GPMC driver migration happens. And the effect of GPMC driver migration on NAND driver can be reduced when it happens. Can you try a patch on top of this series checks if it works for you, if more is required from my side let me know. Regards Afzal [A] http://marc.info/?l=linux-omapm=133675113218509w=2 [B] http://marc.info/?l=linux-omapm=133675123118577w=2 [C] http://marc.info/?l=linux-omapm=133675123718579w=2 [D] http://marc.info/?l=linux-omapm=133675124818580w=2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3] ARM: OMAP3: gpmc: add BCH ecc api and modes
Hi Ivan, On Wed, May 09, 2012 at 21:01:42, Tony Lindgren wrote: Note that I could prepare a new MTD patch with BCH ecc code included, allowing to drop the GPMC BCH ecc api. OK, let's do that then. I'll drop this patch and you can coordinate your patch with Afzal. Now that some review comments has been received on the series, let me try to come up with a suitable way forward and contact you within a day or two. Regards Afzal -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] ARM: OMAP3: gpmc: add BCH ecc api and modes
On Wed, 2012-05-09 at 08:31 -0700, Tony Lindgren wrote: Note that I could prepare a new MTD patch with BCH ecc code included, allowing to drop the GPMC BCH ecc api. OK, let's do that then. I'll drop this patch and you can coordinate your patch with Afzal. Ivan, so are you going to send new patches early enough to make them hit 3.5? Can you please then re-send all the dependent patches again and again describe what depends on what, because I am getting lost :-) -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part
Re: [PATCH v3] ARM: OMAP3: gpmc: add BCH ecc api and modes
On Thu, 2012-05-10 at 17:17 +0200, Ivan Djelic wrote: But in order to do so, I need the changes that Afzal has submitted (in particular [3]). Those changes (and as a consequence, my new patch) won't hit 3.5. So, when Afzal's patches are pushed, I'll submit a new, single MTD patch. But this is not going to happen this merge window as I understood, may be not even the next one. We need to make UBIFS happy sooner than that, I think. So may be we go forward with your original patch? -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part
Re: [PATCH v3] ARM: OMAP3: gpmc: add BCH ecc api and modes
On Thu, May 10, 2012 at 04:52:18PM +0100, Artem Bityutskiy wrote: On Thu, 2012-05-10 at 17:17 +0200, Ivan Djelic wrote: But in order to do so, I need the changes that Afzal has submitted (in particular [3]). Those changes (and as a consequence, my new patch) won't hit 3.5. So, when Afzal's patches are pushed, I'll submit a new, single MTD patch. But this is not going to happen this merge window as I understood, may be not even the next one. We need to make UBIFS happy sooner than that, I think. So may be we go forward with your original patch? I'm OK with this too, as the patches are ready and tested. The MTD patch is [2], it depends on [1] which has been pushed, then dropped by Tony. Do you need me to repost [2] ? Tony, sorry to backpedal on this: would you re-push patch [1], if indeed Afzal's patches are not going to be merged soon ? In the meantime, I can prepare a patch on top of Afzal's to have a smooth transition w.r.t BCH support. What do you think ? Best Regards, -- Ivan [1] http://lists.infradead.org/pipermail/linux-mtd/2012-April/040965.html [2] http://lists.infradead.org/pipermail/linux-mtd/2012-April/041020.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] ARM: OMAP3: gpmc: add BCH ecc api and modes
* Ivan Djelic ivan.dje...@parrot.com [120510 10:49]: On Thu, May 10, 2012 at 04:52:18PM +0100, Artem Bityutskiy wrote: On Thu, 2012-05-10 at 17:17 +0200, Ivan Djelic wrote: But in order to do so, I need the changes that Afzal has submitted (in particular [3]). Those changes (and as a consequence, my new patch) won't hit 3.5. So, when Afzal's patches are pushed, I'll submit a new, single MTD patch. But this is not going to happen this merge window as I understood, may be not even the next one. We need to make UBIFS happy sooner than that, I think. So may be we go forward with your original patch? I'm OK with this too, as the patches are ready and tested. The MTD patch is [2], it depends on [1] which has been pushed, then dropped by Tony. Do you need me to repost [2] ? Tony, sorry to backpedal on this: would you re-push patch [1], if indeed Afzal's patches are not going to be merged soon ? In the meantime, I can prepare a patch on top of Afzal's to have a smooth transition w.r.t BCH support. What do you think ? Yes this is OK with me as this removes the blocker for UBIFS work. For arch/arm/mach-omap2/gpmc.c, I have the following two patches queued: 27aeb3da5f97c55f61d92e3dbfb738762f76dc32 Merge tag 'omap-cleanup-for-v3.5' into tmp-merge 2c65e7440d56b3b285d1c95563b4dcce8e40dea3 GPMC: add ECC control definitions 355f8eee48134ba10ca81664ee90eeb240f5f928 ARM: OMAP2+: GPMC: resolve type-conversion warning from sparse Looks your patch applies to v3.4-rc6 and what I have queued without conflicts, so I suggest you merge both via MTD patches: Acked-by: Tony Lindgren t...@atomide.com [1] http://lists.infradead.org/pipermail/linux-mtd/2012-April/040965.html [2] http://lists.infradead.org/pipermail/linux-mtd/2012-April/041020.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] ARM: OMAP3: gpmc: add BCH ecc api and modes
On Wed, May 09, 2012 at 01:29:28AM +0100, Tony Lindgren wrote: * Ivan Djelic ivan.dje...@parrot.com [120426 05:23]: Hello, Here is version 3 of this patch after review from Tony Lindgren. This version adds a separate initialization function mostly to check CPU compatibility. This check cannot be done in gpmc_enable_hwecc_bch() (which is meant to be called from mtd function ecc.hwctl) because ecc.hwctl is not called before the first NAND read access, and it cannot return an error status. Thanks applying into devel-gpmc branch. OK thanks! I still have a question though: there are recent patches from Afzal Mohammed that seem to go into the opposite direction, that is giving back GPMC register access to the omap2 NAND driver. In particular, [PATCH v4 17/39] [1] commit message says: GPMC driver has been modified to fill NAND platform data with GPMC NAND register details. As these registers are accessible in NAND driver itself, configure NAND in GPMC by itself. This also includes ecc configuration. My original mtd driver patch indeed had ecc handling code inside the driver (not in arch/arm/mach-omap2/gpmc.c). So, my question is: which direction are we going to with respect to this OMAP GPMC/NAND code separation ? Note that I could prepare a new MTD patch with BCH ecc code included, allowing to drop the GPMC BCH ecc api. BR, -- Ivan [1] http://lists.infradead.org/pipermail/linux-mtd/2012-May/041105.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] ARM: OMAP3: gpmc: add BCH ecc api and modes
On Wed, May 09, 2012 at 01:29:28AM +0100, Tony Lindgren wrote: * Ivan Djelic ivan.dje...@parrot.com [120426 05:23]: Hello, Here is version 3 of this patch after review from Tony Lindgren. This version adds a separate initialization function mostly to check CPU compatibility. This check cannot be done in gpmc_enable_hwecc_bch() (which is meant to be called from mtd function ecc.hwctl) because ecc.hwctl is not called before the first NAND read access, and it cannot return an error status. Thanks applying into devel-gpmc branch. OK thanks! I still have a question though: there are recent patches from Afzal Mohammed that seem to go into the opposite direction, that is giving back GPMC register access to the omap2 NAND driver. In particular, [PATCH v4 17/39] [1] commit message says: GPMC driver has been modified to fill NAND platform data with GPMC NAND register details. As these registers are accessible in NAND driver itself, configure NAND in GPMC by itself. This also includes ecc configuration. My original mtd driver patch indeed had ecc handling code inside the driver (not in arch/arm/mach-omap2/gpmc.c). So, my question is: which direction are we going to with respect to this OMAP GPMC/NAND code separation ? Note that I could prepare a new MTD patch with BCH ecc code included, allowing to drop the GPMC BCH ecc api. BR, -- Ivan [1] http://lists.infradead.org/pipermail/linux-mtd/2012-May/041105.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] ARM: OMAP3: gpmc: add BCH ecc api and modes
* Ivan Djelic ivan.dje...@parrot.com [120509 01:15]: On Wed, May 09, 2012 at 01:29:28AM +0100, Tony Lindgren wrote: * Ivan Djelic ivan.dje...@parrot.com [120426 05:23]: Hello, Here is version 3 of this patch after review from Tony Lindgren. This version adds a separate initialization function mostly to check CPU compatibility. This check cannot be done in gpmc_enable_hwecc_bch() (which is meant to be called from mtd function ecc.hwctl) because ecc.hwctl is not called before the first NAND read access, and it cannot return an error status. Thanks applying into devel-gpmc branch. OK thanks! I still have a question though: there are recent patches from Afzal Mohammed that seem to go into the opposite direction, that is giving back GPMC register access to the omap2 NAND driver. In particular, [PATCH v4 17/39] [1] commit message says: GPMC driver has been modified to fill NAND platform data with GPMC NAND register details. As these registers are accessible in NAND driver itself, configure NAND in GPMC by itself. This also includes ecc configuration. My original mtd driver patch indeed had ecc handling code inside the driver (not in arch/arm/mach-omap2/gpmc.c). So, my question is: which direction are we going to with respect to this OMAP GPMC/NAND code separation ? What Afzal is doing is where we're heading. However, I'm afraid that may not be quite ready for v3.5 merge window as it needs proper testing on quite a few platforms to avoid issues with various devices connected to GPMC. Note that I could prepare a new MTD patch with BCH ecc code included, allowing to drop the GPMC BCH ecc api. OK, let's do that then. I'll drop this patch and you can coordinate your patch with Afzal. Regards, Tony [1] http://lists.infradead.org/pipermail/linux-mtd/2012-May/041105.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] ARM: OMAP3: gpmc: add BCH ecc api and modes
* Ivan Djelic ivan.dje...@parrot.com [120426 05:23]: Hello, Here is version 3 of this patch after review from Tony Lindgren. This version adds a separate initialization function mostly to check CPU compatibility. This check cannot be done in gpmc_enable_hwecc_bch() (which is meant to be called from mtd function ecc.hwctl) because ecc.hwctl is not called before the first NAND read access, and it cannot return an error status. Thanks applying into devel-gpmc branch. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html