Re: [PATCH v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
* Roger Quadros [151203 01:02]: > On 03/12/15 11:52, Brian Norris wrote: > > On Thu, Dec 03, 2015 at 11:38:14AM +0530, Roger Quadros wrote: > > > > I think I may have misunderstood the branch proposal. If Tony queues up: > > > > l2-mtd.git (or just up to commit a61ae81a1907) > > + > > your patches > > > > and I pull that back into l2-mtd.git as well, then we don't need to > > worry about patches that touch multiple "trees". Just do whatever makes > > things clearest, including disregarding some of my comments along the > > line of (3). > > Tony, > > Are you fine with this? I'm fine with what you guys prefer as long as I have some immutable branch I can merge in too in case of conflicts :) Regards, Tony -- 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 v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
On 03/12/15 11:52, Brian Norris wrote: > Hi, > > On Thu, Dec 03, 2015 at 11:38:14AM +0530, Roger Quadros wrote: >> On 03/12/15 10:39, Brian Norris wrote: >>> On Fri, Sep 18, 2015 at 05:53:22PM +0300, Roger Quadros wrote: We do a couple of things in this series which result in cleaner device tree implementation, faster perfomance and multi-platform support. As an added bonus we get new GPI/Interrupt pins for use in the system. - Establish a custom interface between NAND and GPMC driver. This is needed because all of the NAND registers sit in the GPMC register space. Some bits like NAND IRQ are even shared with GPMC. - Remove NAND IRQ handling from omap-gpmc driver, share the GPMC IRQ with the omap2-nand driver and handle NAND IRQ events in the NAND driver. This causes performance increase when using prefetch-irq mode. 30% increase in read, 17% increase in write in prefetch-irq mode. - Clean up device tree support so that omap-gpmc IP and the omap2 NAND driver can be used on non-OMAP platforms. e.g. Keystone. - Implement GPIOCHIP + IRQCHIP for the GPMC WAITPINS. SoCs can contain 2 to 4 of these and most of them would be unused otherwise. It also allows a cleaner implementation of NAND Ready pin status for the NAND driver. - Implement GPIOlib based NAND ready pin checking for OMAP NAND driver. This series is available at g...@github.com:rogerq/linux.git in branch for-v4.4/gpmc-v3 cheers, -roger Changelog: v3: -Fixed and tested NAND using legacy boot on omap3-beagle. -Support rising and falling edge interrupts on WAITpins. -Update DT node of all gpmc users. >>> >>> The MTD stuff looks mostly good to me know. I've made all my comments >>> for now, but I'm not sure how you're going to end up rebasing/splitting >>> and what you're going to do with the irqchip removal, so I'll refrain >>> from ack's for now. Hopefully I can either ack or merge v4. >> >> I'll retain the irqchip model for now and send a v4 with all comments >> addressed and better subsystem wise patch split. >> >>> >>> I brought it up on one other patch, but it's not really clear to me what >>> the split is on board file vs. device tree handling, since you seem to >>> have a combination of both (i.e., platform data that passes along device >>> nodes). What's the plan on that? >> >> Platform data no longer passes device nodes. We're either true device tree >> or plain legacy. The deprecated fields are no longer used once the series is >> applied. > > Well, they're still sorta used (you assign info->of_node = > pdata->of_node, for instance). As dicussed in the other thread, I think > we can avoid the deprecation part and just kill the fields though, and > that would make things clearer. > >>> And of course, there's the question of how exactly to merge this, given >>> the: >>> (1) conflicts already existing in the MTD dev tree >> >> I'll rebase the series on top of MTD dev tree. > > OK. FWIW, we so far only need to base them on commit a61ae81a1907 ("mtd: > nand: drop unnecessary partition parser data"). Maybe when queueing up a > branch, that'd be the best starting point for Tony, so he doesn't need > to have all of MTD's stuff in his tree too? I can set up a signed tag or > something, if that would be helpful. > > But for sending patches, the latest l2-mtd.git is fine too. > >>> (2) this touches several trees, often in the same patch and >> >> I'll try my best to split the patches but not sure if this could be 100% >> clean split without functional breakage. >> >>> (3) even if the patches were split out a little better into MTD and >>> non-MTD stuff, I think there would still be dependencies such that >>> we'd need at least 1 (probably 2) cross merges to get it all >>> straight >> >> That is correct. >> Is it OK if functionality breaks if for example only MTD changes are >> considered? > > I think I may have misunderstood the branch proposal. If Tony queues up: > > l2-mtd.git (or just up to commit a61ae81a1907) > + > your patches > > and I pull that back into l2-mtd.git as well, then we don't need to > worry about patches that touch multiple "trees". Just do whatever makes > things clearest, including disregarding some of my comments along the > line of (3). Tony, Are you fine with this? cheers, -roger -- 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 v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
Hi, On Thu, Dec 03, 2015 at 11:38:14AM +0530, Roger Quadros wrote: > On 03/12/15 10:39, Brian Norris wrote: > > On Fri, Sep 18, 2015 at 05:53:22PM +0300, Roger Quadros wrote: > >> We do a couple of things in this series which result in > >> cleaner device tree implementation, faster perfomance and > >> multi-platform support. As an added bonus we get new GPI/Interrupt pins > >> for use in the system. > >> > >> - Establish a custom interface between NAND and GPMC driver. This is > >> needed because all of the NAND registers sit in the GPMC register space. > >> Some bits like NAND IRQ are even shared with GPMC. > >> > >> - Remove NAND IRQ handling from omap-gpmc driver, share the GPMC IRQ > >> with the omap2-nand driver and handle NAND IRQ events in the NAND driver. > >> This causes performance increase when using prefetch-irq mode. > >> 30% increase in read, 17% increase in write in prefetch-irq mode. > >> > >> - Clean up device tree support so that omap-gpmc IP and the omap2 NAND > >> driver can be used on non-OMAP platforms. e.g. Keystone. > >> > >> - Implement GPIOCHIP + IRQCHIP for the GPMC WAITPINS. SoCs can contain > >> 2 to 4 of these and most of them would be unused otherwise. It also > >> allows a cleaner implementation of NAND Ready pin status for the NAND > >> driver. > >> > >> - Implement GPIOlib based NAND ready pin checking for OMAP NAND driver. > >> > >> This series is available at > >> g...@github.com:rogerq/linux.git > >> in branch > >> for-v4.4/gpmc-v3 > >> > >> cheers, > >> -roger > >> > >> Changelog: > >> v3: > >> -Fixed and tested NAND using legacy boot on omap3-beagle. > >> -Support rising and falling edge interrupts on WAITpins. > >> -Update DT node of all gpmc users. > > > > The MTD stuff looks mostly good to me know. I've made all my comments > > for now, but I'm not sure how you're going to end up rebasing/splitting > > and what you're going to do with the irqchip removal, so I'll refrain > > from ack's for now. Hopefully I can either ack or merge v4. > > I'll retain the irqchip model for now and send a v4 with all comments > addressed and better subsystem wise patch split. > > > > > I brought it up on one other patch, but it's not really clear to me what > > the split is on board file vs. device tree handling, since you seem to > > have a combination of both (i.e., platform data that passes along device > > nodes). What's the plan on that? > > Platform data no longer passes device nodes. We're either true device tree > or plain legacy. The deprecated fields are no longer used once the series is > applied. Well, they're still sorta used (you assign info->of_node = pdata->of_node, for instance). As dicussed in the other thread, I think we can avoid the deprecation part and just kill the fields though, and that would make things clearer. > > And of course, there's the question of how exactly to merge this, given > > the: > > (1) conflicts already existing in the MTD dev tree > > I'll rebase the series on top of MTD dev tree. OK. FWIW, we so far only need to base them on commit a61ae81a1907 ("mtd: nand: drop unnecessary partition parser data"). Maybe when queueing up a branch, that'd be the best starting point for Tony, so he doesn't need to have all of MTD's stuff in his tree too? I can set up a signed tag or something, if that would be helpful. But for sending patches, the latest l2-mtd.git is fine too. > > (2) this touches several trees, often in the same patch and > > I'll try my best to split the patches but not sure if this could be 100% > clean split without functional breakage. > > > (3) even if the patches were split out a little better into MTD and > > non-MTD stuff, I think there would still be dependencies such that > > we'd need at least 1 (probably 2) cross merges to get it all > > straight > > That is correct. > Is it OK if functionality breaks if for example only MTD changes are > considered? I think I may have misunderstood the branch proposal. If Tony queues up: l2-mtd.git (or just up to commit a61ae81a1907) + your patches and I pull that back into l2-mtd.git as well, then we don't need to worry about patches that touch multiple "trees". Just do whatever makes things clearest, including disregarding some of my comments along the line of (3). Sorry for any confusion. Brian -- 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 v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
Brian, On 03/12/15 10:39, Brian Norris wrote: > Hi, > > On Fri, Sep 18, 2015 at 05:53:22PM +0300, Roger Quadros wrote: >> Hi, >> >> We do a couple of things in this series which result in >> cleaner device tree implementation, faster perfomance and >> multi-platform support. As an added bonus we get new GPI/Interrupt pins >> for use in the system. >> >> - Establish a custom interface between NAND and GPMC driver. This is >> needed because all of the NAND registers sit in the GPMC register space. >> Some bits like NAND IRQ are even shared with GPMC. >> >> - Remove NAND IRQ handling from omap-gpmc driver, share the GPMC IRQ >> with the omap2-nand driver and handle NAND IRQ events in the NAND driver. >> This causes performance increase when using prefetch-irq mode. >> 30% increase in read, 17% increase in write in prefetch-irq mode. >> >> - Clean up device tree support so that omap-gpmc IP and the omap2 NAND >> driver can be used on non-OMAP platforms. e.g. Keystone. >> >> - Implement GPIOCHIP + IRQCHIP for the GPMC WAITPINS. SoCs can contain >> 2 to 4 of these and most of them would be unused otherwise. It also >> allows a cleaner implementation of NAND Ready pin status for the NAND driver. >> >> - Implement GPIOlib based NAND ready pin checking for OMAP NAND driver. >> >> This series is available at >> g...@github.com:rogerq/linux.git >> in branch >> for-v4.4/gpmc-v3 >> >> cheers, >> -roger >> >> Changelog: >> v3: >> -Fixed and tested NAND using legacy boot on omap3-beagle. >> -Support rising and falling edge interrupts on WAITpins. >> -Update DT node of all gpmc users. > > The MTD stuff looks mostly good to me know. I've made all my comments > for now, but I'm not sure how you're going to end up rebasing/splitting > and what you're going to do with the irqchip removal, so I'll refrain > from ack's for now. Hopefully I can either ack or merge v4. I'll retain the irqchip model for now and send a v4 with all comments addressed and better subsystem wise patch split. > > I brought it up on one other patch, but it's not really clear to me what > the split is on board file vs. device tree handling, since you seem to > have a combination of both (i.e., platform data that passes along device > nodes). What's the plan on that? Platform data no longer passes device nodes. We're either true device tree or plain legacy. The deprecated fields are no longer used once the series is applied. > > And of course, there's the question of how exactly to merge this, given > the: > (1) conflicts already existing in the MTD dev tree I'll rebase the series on top of MTD dev tree. > (2) this touches several trees, often in the same patch and I'll try my best to split the patches but not sure if this could be 100% clean split without functional breakage. > (3) even if the patches were split out a little better into MTD and > non-MTD stuff, I think there would still be dependencies such that > we'd need at least 1 (probably 2) cross merges to get it all > straight That is correct. Is it OK if functionality breaks if for example only MTD changes are considered? cheers, -roger -- 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 v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
Hi, On Fri, Sep 18, 2015 at 05:53:22PM +0300, Roger Quadros wrote: > Hi, > > We do a couple of things in this series which result in > cleaner device tree implementation, faster perfomance and > multi-platform support. As an added bonus we get new GPI/Interrupt pins > for use in the system. > > - Establish a custom interface between NAND and GPMC driver. This is > needed because all of the NAND registers sit in the GPMC register space. > Some bits like NAND IRQ are even shared with GPMC. > > - Remove NAND IRQ handling from omap-gpmc driver, share the GPMC IRQ > with the omap2-nand driver and handle NAND IRQ events in the NAND driver. > This causes performance increase when using prefetch-irq mode. > 30% increase in read, 17% increase in write in prefetch-irq mode. > > - Clean up device tree support so that omap-gpmc IP and the omap2 NAND > driver can be used on non-OMAP platforms. e.g. Keystone. > > - Implement GPIOCHIP + IRQCHIP for the GPMC WAITPINS. SoCs can contain > 2 to 4 of these and most of them would be unused otherwise. It also > allows a cleaner implementation of NAND Ready pin status for the NAND driver. > > - Implement GPIOlib based NAND ready pin checking for OMAP NAND driver. > > This series is available at > g...@github.com:rogerq/linux.git > in branch > for-v4.4/gpmc-v3 > > cheers, > -roger > > Changelog: > v3: > -Fixed and tested NAND using legacy boot on omap3-beagle. > -Support rising and falling edge interrupts on WAITpins. > -Update DT node of all gpmc users. The MTD stuff looks mostly good to me know. I've made all my comments for now, but I'm not sure how you're going to end up rebasing/splitting and what you're going to do with the irqchip removal, so I'll refrain from ack's for now. Hopefully I can either ack or merge v4. I brought it up on one other patch, but it's not really clear to me what the split is on board file vs. device tree handling, since you seem to have a combination of both (i.e., platform data that passes along device nodes). What's the plan on that? And of course, there's the question of how exactly to merge this, given the: (1) conflicts already existing in the MTD dev tree (2) this touches several trees, often in the same patch and (3) even if the patches were split out a little better into MTD and non-MTD stuff, I think there would still be dependencies such that we'd need at least 1 (probably 2) cross merges to get it all straight I'd be happy to hear your thoughts. Brian -- 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 v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
* Brian Norris [151202 10:14]: > On Wed, Dec 02, 2015 at 07:03:17AM -0800, Tony Lindgren wrote: > > * Roger Quadros [151201 21:13]: > > > On 02/12/15 08:56, Brian Norris wrote: > > > > > > > > I'll take another pass over your patch set, but if things are looking > > > > better, how do you expect to merge this? There are significant portions > > > > that touch at least 2 or 3 different subsystem trees, AFAICT. > > > > > > Tony could create an immutable branch with all the dts and memory changes. > > > You could base the mtd changes on top of that? > > > > If we all agree on that it will be immutable Roger can set up the branch > > with our acks and we can all merge it in as needed. I believe v4.4-rc1 > > should work as a base for us all? > > There are oustanding comments about the NAND ready/busy GPIO naming in > patch 18, which I'd like addressed. I'll re-review the rest before the > end of the day (West Coast U.S.A.). I'm not sure my acks are worth much > beyond the MTD stuff. OK, I'm happy with the gpmc related parts. > Regarding branches, 4.4-rc1 is fine with me. OK Thanks, Tony -- 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 v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
Hi Roger, On Wed, Dec 02, 2015 at 10:42:12AM +0530, Roger Quadros wrote: > On 02/12/15 08:56, Brian Norris wrote: > > On Tue, Dec 01, 2015 at 04:41:16PM +0200, Roger Quadros wrote: > >> On 30/11/15 21:54, Brian Norris wrote: > >>> But anyway, I'm not sure that completely answered my question. My > >>> question was whether you were removing the irqchip code solely for > >>> performance reasons, or are there others? > >> > >> Yes. Only for performance reasons. > > > > Hmm, that's not my favorite answer. I'd prefer that more analysis was > > done here before scrapping irqchip... > > I agree. We could retain the irqchip model till we have more satisfying > analysis. I won't insist, though if it's not too ugly/horrible to do so, I think that would make sense. I'll leave it as your call. Brian -- 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 v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
On Wed, Dec 02, 2015 at 07:03:17AM -0800, Tony Lindgren wrote: > * Roger Quadros [151201 21:13]: > > On 02/12/15 08:56, Brian Norris wrote: > > > > > > I'll take another pass over your patch set, but if things are looking > > > better, how do you expect to merge this? There are significant portions > > > that touch at least 2 or 3 different subsystem trees, AFAICT. > > > > Tony could create an immutable branch with all the dts and memory changes. > > You could base the mtd changes on top of that? > > If we all agree on that it will be immutable Roger can set up the branch > with our acks and we can all merge it in as needed. I believe v4.4-rc1 > should work as a base for us all? There are oustanding comments about the NAND ready/busy GPIO naming in patch 18, which I'd like addressed. I'll re-review the rest before the end of the day (West Coast U.S.A.). I'm not sure my acks are worth much beyond the MTD stuff. Regarding branches, 4.4-rc1 is fine with me. Regards, Brian -- 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 v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
* Roger Quadros [151201 21:13]: > On 02/12/15 08:56, Brian Norris wrote: > > > > I'll take another pass over your patch set, but if things are looking > > better, how do you expect to merge this? There are significant portions > > that touch at least 2 or 3 different subsystem trees, AFAICT. > > Tony could create an immutable branch with all the dts and memory changes. > You could base the mtd changes on top of that? If we all agree on that it will be immutable Roger can set up the branch with our acks and we can all merge it in as needed. I believe v4.4-rc1 should work as a base for us all? Regards, Tony -- 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 v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
Brian, On 02/12/15 08:56, Brian Norris wrote: > Hi Roger, > > On Tue, Dec 01, 2015 at 04:41:16PM +0200, Roger Quadros wrote: >> On 30/11/15 21:54, Brian Norris wrote: >>> On Tue, Oct 27, 2015 at 11:37:03AM +0200, Roger Quadros wrote: On 26/10/15 23:23, Brian Norris wrote: > On Fri, Sep 18, 2015 at 05:53:22PM +0300, Roger Quadros wrote: >> - Remove NAND IRQ handling from omap-gpmc driver, share the GPMC IRQ >> with the omap2-nand driver and handle NAND IRQ events in the NAND driver. >> This causes performance increase when using prefetch-irq mode. >> 30% increase in read, 17% increase in write in prefetch-irq mode. > > Have you pinpointed the exact causes for the performance increase, or > can you give an educated guess? AIUI, you're reducing the number of > interrupts needed for NAND prefetch mode, but you're also removing a bit > of abstraction and implementing hooks that look awfully like the > existing abstractions: > > + int (*nand_irq_enable)(enum gpmc_nand_irq irq); > + int (*nand_irq_disable)(enum gpmc_nand_irq irq); > + void (*nand_irq_clear)(enum gpmc_nand_irq irq); > + u32 (*nand_irq_status)(void); > > That's not really a problem if there's a good reason for them (brcmnand > implements similar hooks because of quirks in the implementation of > interrupts across various BRCM SoCs, and it's not worth writing irqchip > drivers for those cases). I'm mainly curious for an explanation. I have both implementations with me. My guess is that the 20% performance gain is due to absence of irqchip/irqdomain translation code. I haven't investigated further though. >>> >>> I don't have much context for whether this makes sense or not. According >>> to your tests, you're getting ~800K interrupts over ~15 seconds. So >>> should you start noticing performance hits due to abstraction at 53K >>> interrupts per second? >> >> Yes, this was my understanding. > > Am I computing wrong, or is that a pretty insane rate of interrupts? I don't have the test board with me right now and so can't tell you for sure if the mtd tests took 15 seconds or more. I can try it out on a different board that I have and let you know for sure about how many interrupts we get per second. > >>> But anyway, I'm not sure that completely answered my question. My >>> question was whether you were removing the irqchip code solely for >>> performance reasons, or are there others? >> >> Yes. Only for performance reasons. > > Hmm, that's not my favorite answer. I'd prefer that more analysis was > done here before scrapping irqchip... I agree. We could retain the irqchip model till we have more satisfying analysis. > > But maybe that's not too bad. It seems like your patch set overall is a > net positive for disentangling some of arch/ and drivers/. :) > > I'll take another pass over your patch set, but if things are looking > better, how do you expect to merge this? There are significant portions > that touch at least 2 or 3 different subsystem trees, AFAICT. Tony could create an immutable branch with all the dts and memory changes. You could base the mtd changes on top of that? cheers, -roger -- 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 v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
Hi Roger, On Tue, Dec 01, 2015 at 04:41:16PM +0200, Roger Quadros wrote: > On 30/11/15 21:54, Brian Norris wrote: > > On Tue, Oct 27, 2015 at 11:37:03AM +0200, Roger Quadros wrote: > >> On 26/10/15 23:23, Brian Norris wrote: > >>> On Fri, Sep 18, 2015 at 05:53:22PM +0300, Roger Quadros wrote: > - Remove NAND IRQ handling from omap-gpmc driver, share the GPMC IRQ > with the omap2-nand driver and handle NAND IRQ events in the NAND driver. > This causes performance increase when using prefetch-irq mode. > 30% increase in read, 17% increase in write in prefetch-irq mode. > >>> > >>> Have you pinpointed the exact causes for the performance increase, or > >>> can you give an educated guess? AIUI, you're reducing the number of > >>> interrupts needed for NAND prefetch mode, but you're also removing a bit > >>> of abstraction and implementing hooks that look awfully like the > >>> existing abstractions: > >>> > >>> + int (*nand_irq_enable)(enum gpmc_nand_irq irq); > >>> + int (*nand_irq_disable)(enum gpmc_nand_irq irq); > >>> + void (*nand_irq_clear)(enum gpmc_nand_irq irq); > >>> + u32 (*nand_irq_status)(void); > >>> > >>> That's not really a problem if there's a good reason for them (brcmnand > >>> implements similar hooks because of quirks in the implementation of > >>> interrupts across various BRCM SoCs, and it's not worth writing irqchip > >>> drivers for those cases). I'm mainly curious for an explanation. > >> > >> I have both implementations with me. My guess is that the 20% performance > >> gain is due to absence of irqchip/irqdomain translation code. > >> I haven't investigated further though. > > > > I don't have much context for whether this makes sense or not. According > > to your tests, you're getting ~800K interrupts over ~15 seconds. So > > should you start noticing performance hits due to abstraction at 53K > > interrupts per second? > > Yes, this was my understanding. Am I computing wrong, or is that a pretty insane rate of interrupts? > > But anyway, I'm not sure that completely answered my question. My > > question was whether you were removing the irqchip code solely for > > performance reasons, or are there others? > > Yes. Only for performance reasons. Hmm, that's not my favorite answer. I'd prefer that more analysis was done here before scrapping irqchip... But maybe that's not too bad. It seems like your patch set overall is a net positive for disentangling some of arch/ and drivers/. I'll take another pass over your patch set, but if things are looking better, how do you expect to merge this? There are significant portions that touch at least 2 or 3 different subsystem trees, AFAICT. Brian -- 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 v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
Hi Brian, On 30/11/15 21:54, Brian Norris wrote: > Hi Roger, > > On Tue, Oct 27, 2015 at 11:37:03AM +0200, Roger Quadros wrote: >> On 26/10/15 23:23, Brian Norris wrote: >>> I'm not too familiar with OMAP platforms, and I might have missed out on >>> prior discussions/context, so please forgive if I'm asking silly or old >>> questions here. >> >> No worries at all. >> >>> >>> On Fri, Sep 18, 2015 at 05:53:22PM +0300, Roger Quadros wrote: - Remove NAND IRQ handling from omap-gpmc driver, share the GPMC IRQ with the omap2-nand driver and handle NAND IRQ events in the NAND driver. This causes performance increase when using prefetch-irq mode. 30% increase in read, 17% increase in write in prefetch-irq mode. >>> >>> Have you pinpointed the exact causes for the performance increase, or >>> can you give an educated guess? AIUI, you're reducing the number of >>> interrupts needed for NAND prefetch mode, but you're also removing a bit >>> of abstraction and implementing hooks that look awfully like the >>> existing abstractions: >>> >>> + int (*nand_irq_enable)(enum gpmc_nand_irq irq); >>> + int (*nand_irq_disable)(enum gpmc_nand_irq irq); >>> + void (*nand_irq_clear)(enum gpmc_nand_irq irq); >>> + u32 (*nand_irq_status)(void); >>> >>> That's not really a problem if there's a good reason for them (brcmnand >>> implements similar hooks because of quirks in the implementation of >>> interrupts across various BRCM SoCs, and it's not worth writing irqchip >>> drivers for those cases). I'm mainly curious for an explanation. >> >> I have both implementations with me. My guess is that the 20% performance >> gain is due to absence of irqchip/irqdomain translation code. >> I haven't investigated further though. > > I don't have much context for whether this makes sense or not. According > to your tests, you're getting ~800K interrupts over ~15 seconds. So > should you start noticing performance hits due to abstraction at 53K > interrupts per second? Yes, this was my understanding. > > But anyway, I'm not sure that completely answered my question. My > question was whether you were removing the irqchip code solely for > performance reasons, or are there others? Yes. Only for performance reasons. > >> Another concern I have is that I'm not using any locking around >> gpmc_nand_irq_enable/disable(). Could this pose problems in multiple NAND >> use cases? My understanding is that it should not as the controller access >> is serialized between multiple NAND chips. > > Right, if you're touching just a NAND interrupt, and it's only used by a > single instance of this NAND controller, then the NAND controller > serialization code will handle this for you. OK. cheers, -roger -- 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 v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
Hi Roger, On Tue, Oct 27, 2015 at 11:37:03AM +0200, Roger Quadros wrote: > On 26/10/15 23:23, Brian Norris wrote: > > I'm not too familiar with OMAP platforms, and I might have missed out on > > prior discussions/context, so please forgive if I'm asking silly or old > > questions here. > > No worries at all. > > > > > On Fri, Sep 18, 2015 at 05:53:22PM +0300, Roger Quadros wrote: > >> - Remove NAND IRQ handling from omap-gpmc driver, share the GPMC IRQ > >> with the omap2-nand driver and handle NAND IRQ events in the NAND driver. > >> This causes performance increase when using prefetch-irq mode. > >> 30% increase in read, 17% increase in write in prefetch-irq mode. > > > > Have you pinpointed the exact causes for the performance increase, or > > can you give an educated guess? AIUI, you're reducing the number of > > interrupts needed for NAND prefetch mode, but you're also removing a bit > > of abstraction and implementing hooks that look awfully like the > > existing abstractions: > > > > + int (*nand_irq_enable)(enum gpmc_nand_irq irq); > > + int (*nand_irq_disable)(enum gpmc_nand_irq irq); > > + void (*nand_irq_clear)(enum gpmc_nand_irq irq); > > + u32 (*nand_irq_status)(void); > > > > That's not really a problem if there's a good reason for them (brcmnand > > implements similar hooks because of quirks in the implementation of > > interrupts across various BRCM SoCs, and it's not worth writing irqchip > > drivers for those cases). I'm mainly curious for an explanation. > > I have both implementations with me. My guess is that the 20% performance > gain is due to absence of irqchip/irqdomain translation code. > I haven't investigated further though. I don't have much context for whether this makes sense or not. According to your tests, you're getting ~800K interrupts over ~15 seconds. So should you start noticing performance hits due to abstraction at 53K interrupts per second? But anyway, I'm not sure that completely answered my question. My question was whether you were removing the irqchip code solely for performance reasons, or are there others? > Another concern I have is that I'm not using any locking around > gpmc_nand_irq_enable/disable(). Could this pose problems in multiple NAND > use cases? My understanding is that it should not as the controller access > is serialized between multiple NAND chips. Right, if you're touching just a NAND interrupt, and it's only used by a single instance of this NAND controller, then the NAND controller serialization code will handle this for you. > However I do need to add some locking as the GPMC_IRQENABLE register is shared > between NAND and GPMC driver. > > NOTE: We are not using prefetch-irq mode for any of the OMAP boards because > of lesser performance than prefetch-polled mode. So if the less performance > for an unused mode is a lesser concern compared to cleaner code then > I can resend this with the irqdomain implementation. > > Below are performance logs of irqdomain vs hooks. > > -- > cheers, > -roger > > test logs. [snip] Brian -- 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 v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
* Roger Quadros [151023 00:09]: > On 21/10/15 18:20, Tony Lindgren wrote: > > * Roger Quadros [151021 01:31]: > >> > >> I couldn't run randconfig beyond few iterations as it keeps failing > >> everywhere. How do we limit the randconfig options to OMAP only > >> platforms? > > > > You can use Felipe's scripts from github. > > Thanks. I used his scripts and ran 10 randconfigs per platform. > Didn't find any issues with this series. > > How can we proceed? > Patches are on https://github.com/rogerq/linux/commits/for-v4.4/gpmc-v4 Sorry for the delay on this one. I suggest you get this series into linux next and then we can merge it for v4.5 via arm-soc as long as the pending comments are addressed. As far as I'm concerned, feel free to add for the whole series: Acked-by: Tony Lindgren Regards, Tony -- 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 v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
Brian, On 27/10/15 11:37, Roger Quadros wrote: > Hi Brian, > > On 26/10/15 23:23, Brian Norris wrote: >> Hi Roger, >> >> I'm not too familiar with OMAP platforms, and I might have missed out on >> prior discussions/context, so please forgive if I'm asking silly or old >> questions here. > > No worries at all. > >> >> On Fri, Sep 18, 2015 at 05:53:22PM +0300, Roger Quadros wrote: >>> - Remove NAND IRQ handling from omap-gpmc driver, share the GPMC IRQ >>> with the omap2-nand driver and handle NAND IRQ events in the NAND driver. >>> This causes performance increase when using prefetch-irq mode. >>> 30% increase in read, 17% increase in write in prefetch-irq mode. >> >> Have you pinpointed the exact causes for the performance increase, or >> can you give an educated guess? AIUI, you're reducing the number of >> interrupts needed for NAND prefetch mode, but you're also removing a bit >> of abstraction and implementing hooks that look awfully like the >> existing abstractions: >> >> + int (*nand_irq_enable)(enum gpmc_nand_irq irq); >> + int (*nand_irq_disable)(enum gpmc_nand_irq irq); >> + void (*nand_irq_clear)(enum gpmc_nand_irq irq); >> + u32 (*nand_irq_status)(void); >> >> That's not really a problem if there's a good reason for them (brcmnand >> implements similar hooks because of quirks in the implementation of >> interrupts across various BRCM SoCs, and it's not worth writing irqchip >> drivers for those cases). I'm mainly curious for an explanation. > > I have both implementations with me. My guess is that the 20% performance > gain is due to absence of irqchip/irqdomain translation code. > I haven't investigated further though. > > Another concern I have is that I'm not using any locking around > gpmc_nand_irq_enable/disable(). Could this pose problems in multiple NAND > use cases? My understanding is that it should not as the controller access > is serialized between multiple NAND chips. > > However I do need to add some locking as the GPMC_IRQENABLE register is shared > between NAND and GPMC driver. > > NOTE: We are not using prefetch-irq mode for any of the OMAP boards because > of lesser performance than prefetch-polled mode. So if the less performance > for an unused mode is a lesser concern compared to cleaner code then > I can resend this with the irqdomain implementation. > > Below are performance logs of irqdomain vs hooks. Any further comments? cheers, -roger > > -- > cheers, > -roger > > test logs. > > for-v4.4/gpmc-v2 - irqdomain with prefetch-irq. No ready pin. > > > [ 67.696631] > [ 67.698201] = > [ 67.704254] mtd_speedtest: MTD device: 8 > [ 67.708373] mtd_speedtest: MTD device size 8388608, eraseblock size > 131072, page size 2048, count of eraseblocks 64, pages per eraseblock 64, OOB > size 64 > [ 67.723701] mtd_test: scanning for bad eraseblocks > [ 67.735468] mtd_test: scanned 64 eraseblocks, 0 are bad > [ 67.772861] mtd_speedtest: testing eraseblock write speed > [ 70.372903] mtd_speedtest: eraseblock write speed is 3156 KiB/s > [ 70.379104] mtd_speedtest: testing eraseblock read speed > [ 72.594169] mtd_speedtest: eraseblock read speed is 3708 KiB/s > [ 72.656375] mtd_speedtest: testing page write speed > [ 75.213646] mtd_speedtest: page write speed is 3208 KiB/s > [ 75.219311] mtd_speedtest: testing page read speed > [ 77.343639] mtd_speedtest: page read speed is 3865 KiB/s > [ 77.405236] mtd_speedtest: testing 2 page write speed > [ 80.039702] mtd_speedtest: 2 page write speed is 3114 KiB/s > [ 80.045561] mtd_speedtest: testing 2 page read speed > [ 82.175098] mtd_speedtest: 2 page read speed is 3856 KiB/s > [ 82.180849] mtd_speedtest: Testing erase speed > [ 82.241548] mtd_speedtest: erase speed is 146285 KiB/s > [ 82.246920] mtd_speedtest: Testing 2x multi-block erase speed > [ 82.284789] mtd_speedtest: 2x multi-block erase speed is 264258 KiB/s > [ 82.291551] mtd_speedtest: Testing 4x multi-block erase speed > [ 82.329358] mtd_speedtest: 4x multi-block erase speed is 264258 KiB/s > [ 82.336116] mtd_speedtest: Testing 8x multi-block erase speed > [ 82.373903] mtd_speedtest: 8x multi-block erase speed is 264258 KiB/s > [ 82.380648] mtd_speedtest: Testing 16x multi-block erase speed > [ 82.418503] mtd_speedtest: 16x multi-block erase speed is 264258 KiB/s > [ 82.425356] mtd_speedtest: Testing 32x multi-block erase speed > [ 82.463227] mtd_speedtest: 32x multi-block erase speed is 264258 KiB/s > [ 82.470066] mtd_speedtest: Testing 64x multi-block erase speed > [ 82.507908] mtd_speedtest: 64x multi-block erase speed is 264258 KiB/s > [ 82.514758] mtd_speedtest: finished > [ 82.518417] = > > root@rockdesk:~# cat /proc/interrupts >CPU0 CPU1 > 324: 798720 0 CBAR 15 Level gpmc > 397: 798720 0 gpmc
Re: [PATCH v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
Hi Brian, On 26/10/15 23:23, Brian Norris wrote: > Hi Roger, > > I'm not too familiar with OMAP platforms, and I might have missed out on > prior discussions/context, so please forgive if I'm asking silly or old > questions here. No worries at all. > > On Fri, Sep 18, 2015 at 05:53:22PM +0300, Roger Quadros wrote: >> - Remove NAND IRQ handling from omap-gpmc driver, share the GPMC IRQ >> with the omap2-nand driver and handle NAND IRQ events in the NAND driver. >> This causes performance increase when using prefetch-irq mode. >> 30% increase in read, 17% increase in write in prefetch-irq mode. > > Have you pinpointed the exact causes for the performance increase, or > can you give an educated guess? AIUI, you're reducing the number of > interrupts needed for NAND prefetch mode, but you're also removing a bit > of abstraction and implementing hooks that look awfully like the > existing abstractions: > > + int (*nand_irq_enable)(enum gpmc_nand_irq irq); > + int (*nand_irq_disable)(enum gpmc_nand_irq irq); > + void (*nand_irq_clear)(enum gpmc_nand_irq irq); > + u32 (*nand_irq_status)(void); > > That's not really a problem if there's a good reason for them (brcmnand > implements similar hooks because of quirks in the implementation of > interrupts across various BRCM SoCs, and it's not worth writing irqchip > drivers for those cases). I'm mainly curious for an explanation. I have both implementations with me. My guess is that the 20% performance gain is due to absence of irqchip/irqdomain translation code. I haven't investigated further though. Another concern I have is that I'm not using any locking around gpmc_nand_irq_enable/disable(). Could this pose problems in multiple NAND use cases? My understanding is that it should not as the controller access is serialized between multiple NAND chips. However I do need to add some locking as the GPMC_IRQENABLE register is shared between NAND and GPMC driver. NOTE: We are not using prefetch-irq mode for any of the OMAP boards because of lesser performance than prefetch-polled mode. So if the less performance for an unused mode is a lesser concern compared to cleaner code then I can resend this with the irqdomain implementation. Below are performance logs of irqdomain vs hooks. -- cheers, -roger test logs. for-v4.4/gpmc-v2 - irqdomain with prefetch-irq. No ready pin. [ 67.696631] [ 67.698201] = [ 67.704254] mtd_speedtest: MTD device: 8 [ 67.708373] mtd_speedtest: MTD device size 8388608, eraseblock size 131072, page size 2048, count of eraseblocks 64, pages per eraseblock 64, OOB size 64 [ 67.723701] mtd_test: scanning for bad eraseblocks [ 67.735468] mtd_test: scanned 64 eraseblocks, 0 are bad [ 67.772861] mtd_speedtest: testing eraseblock write speed [ 70.372903] mtd_speedtest: eraseblock write speed is 3156 KiB/s [ 70.379104] mtd_speedtest: testing eraseblock read speed [ 72.594169] mtd_speedtest: eraseblock read speed is 3708 KiB/s [ 72.656375] mtd_speedtest: testing page write speed [ 75.213646] mtd_speedtest: page write speed is 3208 KiB/s [ 75.219311] mtd_speedtest: testing page read speed [ 77.343639] mtd_speedtest: page read speed is 3865 KiB/s [ 77.405236] mtd_speedtest: testing 2 page write speed [ 80.039702] mtd_speedtest: 2 page write speed is 3114 KiB/s [ 80.045561] mtd_speedtest: testing 2 page read speed [ 82.175098] mtd_speedtest: 2 page read speed is 3856 KiB/s [ 82.180849] mtd_speedtest: Testing erase speed [ 82.241548] mtd_speedtest: erase speed is 146285 KiB/s [ 82.246920] mtd_speedtest: Testing 2x multi-block erase speed [ 82.284789] mtd_speedtest: 2x multi-block erase speed is 264258 KiB/s [ 82.291551] mtd_speedtest: Testing 4x multi-block erase speed [ 82.329358] mtd_speedtest: 4x multi-block erase speed is 264258 KiB/s [ 82.336116] mtd_speedtest: Testing 8x multi-block erase speed [ 82.373903] mtd_speedtest: 8x multi-block erase speed is 264258 KiB/s [ 82.380648] mtd_speedtest: Testing 16x multi-block erase speed [ 82.418503] mtd_speedtest: 16x multi-block erase speed is 264258 KiB/s [ 82.425356] mtd_speedtest: Testing 32x multi-block erase speed [ 82.463227] mtd_speedtest: 32x multi-block erase speed is 264258 KiB/s [ 82.470066] mtd_speedtest: Testing 64x multi-block erase speed [ 82.507908] mtd_speedtest: 64x multi-block erase speed is 264258 KiB/s [ 82.514758] mtd_speedtest: finished [ 82.518417] = root@rockdesk:~# cat /proc/interrupts CPU0 CPU1 324: 798720 0 CBAR 15 Level gpmc 397: 798720 0 gpmc 0 Edge gpmc-nand-fifo 398: 24576 0 gpmc 1 Edge gpmc-nand-count root@rockdesk:~# ./nandthroughput.sh Test file blobs/50M.bin found mounting NAND partition 9 == attaching ubi to mtd9 [ 133.102184] ubi0: attaching mtd9 [ 133.8011
Re: [PATCH v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
Hi Roger, I'm not too familiar with OMAP platforms, and I might have missed out on prior discussions/context, so please forgive if I'm asking silly or old questions here. On Fri, Sep 18, 2015 at 05:53:22PM +0300, Roger Quadros wrote: > - Remove NAND IRQ handling from omap-gpmc driver, share the GPMC IRQ > with the omap2-nand driver and handle NAND IRQ events in the NAND driver. > This causes performance increase when using prefetch-irq mode. > 30% increase in read, 17% increase in write in prefetch-irq mode. Have you pinpointed the exact causes for the performance increase, or can you give an educated guess? AIUI, you're reducing the number of interrupts needed for NAND prefetch mode, but you're also removing a bit of abstraction and implementing hooks that look awfully like the existing abstractions: + int (*nand_irq_enable)(enum gpmc_nand_irq irq); + int (*nand_irq_disable)(enum gpmc_nand_irq irq); + void (*nand_irq_clear)(enum gpmc_nand_irq irq); + u32 (*nand_irq_status)(void); That's not really a problem if there's a good reason for them (brcmnand implements similar hooks because of quirks in the implementation of interrupts across various BRCM SoCs, and it's not worth writing irqchip drivers for those cases). I'm mainly curious for an explanation. Regards, Brian -- 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 v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
On 21/10/15 18:20, Tony Lindgren wrote: > * Roger Quadros [151021 01:31]: >> On 19/10/15 10:08, Roger Quadros wrote: >>> On 17/10/15 00:25, Tony Lindgren wrote: * Roger Quadros [151006 04:13]: > > Fine. The updated series is now at > > g...@github.com:rogerq/linux.git > * [new branch] for-v4.4/gpmc-v4 Looks like it produces some build errors, this with RMKs 3430 and 4430 only .configs: drivers/memory/omap-gpmc.c:2035:43: error: ‘struct gpio_chip’ has no member named ‘irqdomain’ drivers/memory/omap-gpmc.c:2116:8: error: implicit declaration of function ‘gpiochip_irqchip_add’ [-Werror=implicit-function-declaration] >>> >>> Good catch. We'll have to select GPIOLIB_IRQCHIP for this driver. >>> Maybe run randconfig builds on it for overnight? >>> >>> OK. I'll do that. >> >> I couldn't run randconfig beyond few iterations as it keeps failing >> everywhere. How do we limit the randconfig options to OMAP only >> platforms? > > You can use Felipe's scripts from github. Thanks. I used his scripts and ran 10 randconfigs per platform. Didn't find any issues with this series. How can we proceed? Patches are on https://github.com/rogerq/linux/commits/for-v4.4/gpmc-v4 cheers, -roger -- 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 v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
* Roger Quadros [151021 01:31]: > On 19/10/15 10:08, Roger Quadros wrote: > > On 17/10/15 00:25, Tony Lindgren wrote: > >> * Roger Quadros [151006 04:13]: > >>> > >>> Fine. The updated series is now at > >>> > >>> g...@github.com:rogerq/linux.git > >>> * [new branch] for-v4.4/gpmc-v4 > >> > >> Looks like it produces some build errors, this with RMKs 3430 and 4430 > >> only .configs: > >> > >> drivers/memory/omap-gpmc.c:2035:43: error: ‘struct gpio_chip’ has no > >> member named ‘irqdomain’ > >> drivers/memory/omap-gpmc.c:2116:8: error: implicit declaration of > >> function ‘gpiochip_irqchip_add’ [-Werror=implicit-function-declaration] > >> > > > > Good catch. We'll have to select GPIOLIB_IRQCHIP for this driver. > > > >> Maybe run randconfig builds on it for overnight? > > > > OK. I'll do that. > > I couldn't run randconfig beyond few iterations as it keeps failing > everywhere. How do we limit the randconfig options to OMAP only > platforms? You can use Felipe's scripts from github. Regards, Tony -- 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 v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
On 19/10/15 10:08, Roger Quadros wrote: > On 17/10/15 00:25, Tony Lindgren wrote: >> * Roger Quadros [151006 04:13]: >>> >>> Fine. The updated series is now at >>> >>> g...@github.com:rogerq/linux.git >>> * [new branch] for-v4.4/gpmc-v4 >> >> Looks like it produces some build errors, this with RMKs 3430 and 4430 >> only .configs: >> >> drivers/memory/omap-gpmc.c:2035:43: error: ‘struct gpio_chip’ has no >> member named ‘irqdomain’ >> drivers/memory/omap-gpmc.c:2116:8: error: implicit declaration of >> function ‘gpiochip_irqchip_add’ [-Werror=implicit-function-declaration] >> > > Good catch. We'll have to select GPIOLIB_IRQCHIP for this driver. > >> Maybe run randconfig builds on it for overnight? > > OK. I'll do that. I couldn't run randconfig beyond few iterations as it keeps failing everywhere. How do we limit the randconfig options to OMAP only platforms? cheers, -roger -- 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 v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
On 17/10/15 00:25, Tony Lindgren wrote: > * Roger Quadros [151006 04:13]: >> >> Fine. The updated series is now at >> >> g...@github.com:rogerq/linux.git >> * [new branch] for-v4.4/gpmc-v4 > > Looks like it produces some build errors, this with RMKs 3430 and 4430 > only .configs: > > drivers/memory/omap-gpmc.c:2035:43: error: ‘struct gpio_chip’ has no > member named ‘irqdomain’ > drivers/memory/omap-gpmc.c:2116:8: error: implicit declaration of > function ‘gpiochip_irqchip_add’ [-Werror=implicit-function-declaration] > Good catch. We'll have to select GPIOLIB_IRQCHIP for this driver. > Maybe run randconfig builds on it for overnight? OK. I'll do that. > > Other than that your series seems to behave for me now, so feel > free to add: > > Acked-by: Tony Lindgren Thanks for the tests :) cheers, -roger -- 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 v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
* Roger Quadros [151006 04:13]: > > Fine. The updated series is now at > > g...@github.com:rogerq/linux.git > * [new branch] for-v4.4/gpmc-v4 Looks like it produces some build errors, this with RMKs 3430 and 4430 only .configs: drivers/memory/omap-gpmc.c:2035:43: error: ‘struct gpio_chip’ has no member named ‘irqdomain’ drivers/memory/omap-gpmc.c:2116:8: error: implicit declaration of function ‘gpiochip_irqchip_add’ [-Werror=implicit-function-declaration] Maybe run randconfig builds on it for overnight? Other than that your series seems to behave for me now, so feel free to add: Acked-by: Tony Lindgren Regards, Tony -- 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 v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
On 06/10/15 14:01, Tony Lindgren wrote: > * Roger Quadros [151006 03:32]: >> On 06/10/15 13:05, Roger Quadros wrote: >>> On 06/10/15 13:00, Tony Lindgren wrote: * Roger Quadros [151006 02:59]: > On 06/10/15 11:33, Tony Lindgren wrote: >> Does build and boot and use NAND work throughtout the series? >> Otherwise we'll have hard time bisecting anything.. > > Yes it does with the following exceptions. > > - Patch 7 "memory: omap-gpmc: Remove NAND IRQ code" breaks prefetch-irq > mode > but none of the boards seem to be using it so it shouldn't break NAND on > existing boards. > At patch 9 "mtd: nand: omap2: manage NAND interrupts" prefetch-irq mode > is working again. > Do you want me to squash patches 7,8,9 so that pre-fetch irq is not > broken at any point? OK, no that's fine, no need to squash them together then. > - Then at patch 11 "mtd: nand: omap: Clean up device tree support" we > break NAND on all DT > boards as we expect NAND to be a real child node with compatible id. > Simply applying the > DT patch at this point makes it work again. Hmm can we at least warn about incompatible DT entry when somebody boots with an older dtb? >>> >>> Yes that could be done. It looks like we can use the missing compatible >>> property to identify >>> that it is and old DT entry. >>> >>> I'll send a v4 of patch 11. >> >> There is another issue. Some of the old DT nodes set the NAND IO address to >> 0. >> As we prevent mapping into first 16MB we see the following message for those >> nodes. e.g. dra7-evm >> >> [1.727598] omap-gpmc 5000.gpmc: cannot remap GPMC CS 0 to 0x >> [1.727605] omap-gpmc 5000.gpmc: GPMC CS 0 start cannot be lesser >> than 0x100 >> [1.727611] omap-gpmc 5000.gpmc: failed to probe DT children >> >> Hope this is good enough information that DT needs to be updated? > > Yes I think that should allow users update the out of tree dts file > easily. Fine. The updated series is now at g...@github.com:rogerq/linux.git * [new branch] for-v4.4/gpmc-v4 cheers, -roger -- 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 v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
* Roger Quadros [151006 03:32]: > On 06/10/15 13:05, Roger Quadros wrote: > > On 06/10/15 13:00, Tony Lindgren wrote: > >> * Roger Quadros [151006 02:59]: > >>> On 06/10/15 11:33, Tony Lindgren wrote: > Does build and boot and use NAND work throughtout the series? > Otherwise we'll have hard time bisecting anything.. > >>> > >>> Yes it does with the following exceptions. > >>> > >>> - Patch 7 "memory: omap-gpmc: Remove NAND IRQ code" breaks prefetch-irq > >>> mode > >>> but none of the boards seem to be using it so it shouldn't break NAND on > >>> existing boards. > >>> At patch 9 "mtd: nand: omap2: manage NAND interrupts" prefetch-irq mode > >>> is working again. > >>> Do you want me to squash patches 7,8,9 so that pre-fetch irq is not > >>> broken at any point? > >> > >> OK, no that's fine, no need to squash them together then. > >> > >>> - Then at patch 11 "mtd: nand: omap: Clean up device tree support" we > >>> break NAND on all DT > >>> boards as we expect NAND to be a real child node with compatible id. > >>> Simply applying the > >>> DT patch at this point makes it work again. > >> > >> Hmm can we at least warn about incompatible DT entry when somebody boots > >> with an older dtb? > > > > Yes that could be done. It looks like we can use the missing compatible > > property to identify > > that it is and old DT entry. > > > > I'll send a v4 of patch 11. > > There is another issue. Some of the old DT nodes set the NAND IO address to 0. > As we prevent mapping into first 16MB we see the following message for those > nodes. e.g. dra7-evm > > [1.727598] omap-gpmc 5000.gpmc: cannot remap GPMC CS 0 to 0x > [1.727605] omap-gpmc 5000.gpmc: GPMC CS 0 start cannot be lesser than > 0x100 > [1.727611] omap-gpmc 5000.gpmc: failed to probe DT children > > Hope this is good enough information that DT needs to be updated? Yes I think that should allow users update the out of tree dts file easily. Regards, Tony -- 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 v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
On 06/10/15 13:05, Roger Quadros wrote: > On 06/10/15 13:00, Tony Lindgren wrote: >> * Roger Quadros [151006 02:59]: >>> On 06/10/15 11:33, Tony Lindgren wrote: Does build and boot and use NAND work throughtout the series? Otherwise we'll have hard time bisecting anything.. >>> >>> Yes it does with the following exceptions. >>> >>> - Patch 7 "memory: omap-gpmc: Remove NAND IRQ code" breaks prefetch-irq mode >>> but none of the boards seem to be using it so it shouldn't break NAND on >>> existing boards. >>> At patch 9 "mtd: nand: omap2: manage NAND interrupts" prefetch-irq mode is >>> working again. >>> Do you want me to squash patches 7,8,9 so that pre-fetch irq is not broken >>> at any point? >> >> OK, no that's fine, no need to squash them together then. >> >>> - Then at patch 11 "mtd: nand: omap: Clean up device tree support" we break >>> NAND on all DT >>> boards as we expect NAND to be a real child node with compatible id. Simply >>> applying the >>> DT patch at this point makes it work again. >> >> Hmm can we at least warn about incompatible DT entry when somebody boots >> with an older dtb? > > Yes that could be done. It looks like we can use the missing compatible > property to identify > that it is and old DT entry. > > I'll send a v4 of patch 11. There is another issue. Some of the old DT nodes set the NAND IO address to 0. As we prevent mapping into first 16MB we see the following message for those nodes. e.g. dra7-evm [1.727598] omap-gpmc 5000.gpmc: cannot remap GPMC CS 0 to 0x [1.727605] omap-gpmc 5000.gpmc: GPMC CS 0 start cannot be lesser than 0x100 [1.727611] omap-gpmc 5000.gpmc: failed to probe DT children Hope this is good enough information that DT needs to be updated? cheers, -roger -- 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 v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
On 06/10/15 13:00, Tony Lindgren wrote: > * Roger Quadros [151006 02:59]: >> On 06/10/15 11:33, Tony Lindgren wrote: >>> Does build and boot and use NAND work throughtout the series? >>> Otherwise we'll have hard time bisecting anything.. >> >> Yes it does with the following exceptions. >> >> - Patch 7 "memory: omap-gpmc: Remove NAND IRQ code" breaks prefetch-irq mode >> but none of the boards seem to be using it so it shouldn't break NAND on >> existing boards. >> At patch 9 "mtd: nand: omap2: manage NAND interrupts" prefetch-irq mode is >> working again. >> Do you want me to squash patches 7,8,9 so that pre-fetch irq is not broken >> at any point? > > OK, no that's fine, no need to squash them together then. > >> - Then at patch 11 "mtd: nand: omap: Clean up device tree support" we break >> NAND on all DT >> boards as we expect NAND to be a real child node with compatible id. Simply >> applying the >> DT patch at this point makes it work again. > > Hmm can we at least warn about incompatible DT entry when somebody boots > with an older dtb? Yes that could be done. It looks like we can use the missing compatible property to identify that it is and old DT entry. I'll send a v4 of patch 11. cheers, -roger > Test procedure was to read an existing ubifs partition, create a new one and read it back. Need you to Ack if it looks good. Do you mind taking it via omap-soc once MTD maintainers ack their relevant parts? >>> >>> Sure. I'll try to do some testing on the series first too. >>> >> Thanks. >> >>> Can the dts changes be merged separtely? Otherwise we'll have >>> a dependency between dts branch and the GPMC/NAND changes. >> >> I'm afraid no. Patch 11 makes us incompatible with the old DT. > > OK. If we can warn about that, then the out of tree users will > have easier time to update their dts file. > > Regards, > > Tony > -- 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 v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
* Roger Quadros [151006 02:59]: > On 06/10/15 11:33, Tony Lindgren wrote: > > Does build and boot and use NAND work throughtout the series? > > Otherwise we'll have hard time bisecting anything.. > > Yes it does with the following exceptions. > > - Patch 7 "memory: omap-gpmc: Remove NAND IRQ code" breaks prefetch-irq mode > but none of the boards seem to be using it so it shouldn't break NAND on > existing boards. > At patch 9 "mtd: nand: omap2: manage NAND interrupts" prefetch-irq mode is > working again. > Do you want me to squash patches 7,8,9 so that pre-fetch irq is not broken at > any point? OK, no that's fine, no need to squash them together then. > - Then at patch 11 "mtd: nand: omap: Clean up device tree support" we break > NAND on all DT > boards as we expect NAND to be a real child node with compatible id. Simply > applying the > DT patch at this point makes it work again. Hmm can we at least warn about incompatible DT entry when somebody boots with an older dtb? > >> Test procedure was to read an existing ubifs partition, > >> create a new one and read it back. > >> > >> Need you to Ack if it looks good. > >> Do you mind taking it via omap-soc once MTD maintainers ack their relevant > >> parts? > > > > Sure. I'll try to do some testing on the series first too. > > > Thanks. > > > Can the dts changes be merged separtely? Otherwise we'll have > > a dependency between dts branch and the GPMC/NAND changes. > > I'm afraid no. Patch 11 makes us incompatible with the old DT. OK. If we can warn about that, then the out of tree users will have easier time to update their dts file. Regards, Tony -- 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 v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
On 06/10/15 11:33, Tony Lindgren wrote: > * Roger Quadros [150930 04:04]: >> Tony, >> >> On 18/09/15 17:53, Roger Quadros wrote: >>> Hi, >>> >>> We do a couple of things in this series which result in >>> cleaner device tree implementation, faster perfomance and >>> multi-platform support. As an added bonus we get new GPI/Interrupt pins >>> for use in the system. >>> >>> - Establish a custom interface between NAND and GPMC driver. This is >>> needed because all of the NAND registers sit in the GPMC register space. >>> Some bits like NAND IRQ are even shared with GPMC. >>> >>> - Remove NAND IRQ handling from omap-gpmc driver, share the GPMC IRQ >>> with the omap2-nand driver and handle NAND IRQ events in the NAND driver. >>> This causes performance increase when using prefetch-irq mode. >>> 30% increase in read, 17% increase in write in prefetch-irq mode. >>> >>> - Clean up device tree support so that omap-gpmc IP and the omap2 NAND >>> driver can be used on non-OMAP platforms. e.g. Keystone. >>> >>> - Implement GPIOCHIP + IRQCHIP for the GPMC WAITPINS. SoCs can contain >>> 2 to 4 of these and most of them would be unused otherwise. It also >>> allows a cleaner implementation of NAND Ready pin status for the NAND >>> driver. >>> >>> - Implement GPIOlib based NAND ready pin checking for OMAP NAND driver. >>> >>> This series is available at >>> g...@github.com:rogerq/linux.git >>> in branch >>> for-v4.4/gpmc-v3 > > In general, very nice work :) Thanks :) > >> I've verified this series with the following boards >> -dra7-evm >> -am437x-gp-evm >> -am335x-evm >> -beagleboard-c4 >> >> For legacy boot I've checked only on beagleboard-c4. > > Great. > > Does build and boot and use NAND work throughtout the series? > Otherwise we'll have hard time bisecting anything.. Yes it does with the following exceptions. - Patch 7 "memory: omap-gpmc: Remove NAND IRQ code" breaks prefetch-irq mode but none of the boards seem to be using it so it shouldn't break NAND on existing boards. At patch 9 "mtd: nand: omap2: manage NAND interrupts" prefetch-irq mode is working again. Do you want me to squash patches 7,8,9 so that pre-fetch irq is not broken at any point? - Then at patch 11 "mtd: nand: omap: Clean up device tree support" we break NAND on all DT boards as we expect NAND to be a real child node with compatible id. Simply applying the DT patch at this point makes it work again. > >> Test procedure was to read an existing ubifs partition, >> create a new one and read it back. >> >> Need you to Ack if it looks good. >> Do you mind taking it via omap-soc once MTD maintainers ack their relevant >> parts? > > Sure. I'll try to do some testing on the series first too. > Thanks. > Can the dts changes be merged separtely? Otherwise we'll have > a dependency between dts branch and the GPMC/NAND changes. I'm afraid no. Patch 11 makes us incompatible with the old DT. cheers, -roger -- 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 v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
* Roger Quadros [150930 04:04]: > Tony, > > On 18/09/15 17:53, Roger Quadros wrote: > > Hi, > > > > We do a couple of things in this series which result in > > cleaner device tree implementation, faster perfomance and > > multi-platform support. As an added bonus we get new GPI/Interrupt pins > > for use in the system. > > > > - Establish a custom interface between NAND and GPMC driver. This is > > needed because all of the NAND registers sit in the GPMC register space. > > Some bits like NAND IRQ are even shared with GPMC. > > > > - Remove NAND IRQ handling from omap-gpmc driver, share the GPMC IRQ > > with the omap2-nand driver and handle NAND IRQ events in the NAND driver. > > This causes performance increase when using prefetch-irq mode. > > 30% increase in read, 17% increase in write in prefetch-irq mode. > > > > - Clean up device tree support so that omap-gpmc IP and the omap2 NAND > > driver can be used on non-OMAP platforms. e.g. Keystone. > > > > - Implement GPIOCHIP + IRQCHIP for the GPMC WAITPINS. SoCs can contain > > 2 to 4 of these and most of them would be unused otherwise. It also > > allows a cleaner implementation of NAND Ready pin status for the NAND > > driver. > > > > - Implement GPIOlib based NAND ready pin checking for OMAP NAND driver. > > > > This series is available at > > g...@github.com:rogerq/linux.git > > in branch > > for-v4.4/gpmc-v3 In general, very nice work :) > I've verified this series with the following boards > -dra7-evm > -am437x-gp-evm > -am335x-evm > -beagleboard-c4 > > For legacy boot I've checked only on beagleboard-c4. Great. Does build and boot and use NAND work throughtout the series? Otherwise we'll have hard time bisecting anything.. > Test procedure was to read an existing ubifs partition, > create a new one and read it back. > > Need you to Ack if it looks good. > Do you mind taking it via omap-soc once MTD maintainers ack their relevant > parts? Sure. I'll try to do some testing on the series first too. Can the dts changes be merged separtely? Otherwise we'll have a dependency between dts branch and the GPMC/NAND changes. Regards, Tony -- 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 v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
Tony, On 18/09/15 17:53, Roger Quadros wrote: > Hi, > > We do a couple of things in this series which result in > cleaner device tree implementation, faster perfomance and > multi-platform support. As an added bonus we get new GPI/Interrupt pins > for use in the system. > > - Establish a custom interface between NAND and GPMC driver. This is > needed because all of the NAND registers sit in the GPMC register space. > Some bits like NAND IRQ are even shared with GPMC. > > - Remove NAND IRQ handling from omap-gpmc driver, share the GPMC IRQ > with the omap2-nand driver and handle NAND IRQ events in the NAND driver. > This causes performance increase when using prefetch-irq mode. > 30% increase in read, 17% increase in write in prefetch-irq mode. > > - Clean up device tree support so that omap-gpmc IP and the omap2 NAND > driver can be used on non-OMAP platforms. e.g. Keystone. > > - Implement GPIOCHIP + IRQCHIP for the GPMC WAITPINS. SoCs can contain > 2 to 4 of these and most of them would be unused otherwise. It also > allows a cleaner implementation of NAND Ready pin status for the NAND driver. > > - Implement GPIOlib based NAND ready pin checking for OMAP NAND driver. > > This series is available at > g...@github.com:rogerq/linux.git > in branch > for-v4.4/gpmc-v3 I've verified this series with the following boards -dra7-evm -am437x-gp-evm -am335x-evm -beagleboard-c4 For legacy boot I've checked only on beagleboard-c4. Test procedure was to read an existing ubifs partition, create a new one and read it back. Need you to Ack if it looks good. Do you mind taking it via omap-soc once MTD maintainers ack their relevant parts? cheers, -roger > > Changelog: > v3: > -Fixed and tested NAND using legacy boot on omap3-beagle. > -Support rising and falling edge interrupts on WAITpins. > -Update DT node of all gpmc users. > > Roger Quadros (27): > ARM: OMAP2+: gpmc: Add platform data > ARM: OMAP2+: gpmc: Add gpmc timings and settings to platform data > memory: omap-gpmc: Introduce GPMC to NAND interface > mtd: nand: omap2: Use gpmc_omap_get_nand_ops() to get NAND registers > memory: omap-gpmc: Add GPMC-NAND ops to get writebufferempty status > mtd: nand: omap2: Switch to using GPMC-NAND ops for writebuffer empty > check > memory: omap-gpmc: Remove NAND IRQ code > memory: omap-gpmc: Add IRQ ops for GPMC-NAND interface > mtd: nand: omap2: manage NAND interrupts > mtd: nand: omap: Copy platform data parameters to omap_nand_info data > mtd: nand: omap: Clean up device tree support > mtd: nand: omap: Update DT binding documentation > memory: omap-gpmc: Prevent mapping into 1st 16MB > memory: omap-gpmc: Move device tree binding to correct location > memory: omap-gpmc: Support general purpose input for WAITPINs > memory: omap-gpmc: Reserve WAITPIN if needed for WAIT monitoring > memory: omap-gpmc: Add irqchip support to the gpiochip > mtd: nand: omap2: Implement NAND ready using gpiolib > memory: omap-gpmc: Prevent GPMC_STATUS from being accessed via > gpmc_regs > ARM: dts: dra7: Fix NAND device nodes. > ARM: dts: dra7x-evm: Provide NAND ready pin > ARM: dts: am437x: Fix NAND device nodes > ARM: dts: am437x-gp-evm: Provide NAND ready pin > ARM: dts: am335x: Fix NAND device nodes > ARM: dts: am335x: Provide NAND ready pin > ARM: dts: dm816x: Fix gpmc and NAND node > ARM: dts: omap3: Fix gpmc and NAND nodes > > Documentation/devicetree/bindings/bus/ti-gpmc.txt | 130 - > .../bindings/memory-controllers/omap-gpmc.txt | 130 + > .../devicetree/bindings/mtd/gpmc-nand.txt | 16 +- > arch/arm/boot/dts/am335x-chilisom.dtsi | 7 +- > arch/arm/boot/dts/am335x-evm.dts | 7 +- > arch/arm/boot/dts/am335x-igep0033.dtsi | 7 +- > arch/arm/boot/dts/am33xx.dtsi | 4 + > arch/arm/boot/dts/am4372.dtsi | 4 + > arch/arm/boot/dts/am437x-gp-evm.dts| 8 +- > arch/arm/boot/dts/am43x-epos-evm.dts | 8 +- > arch/arm/boot/dts/dm8168-evm.dts | 7 +- > arch/arm/boot/dts/dm816x.dtsi | 4 + > arch/arm/boot/dts/dra7-evm.dts | 6 +- > arch/arm/boot/dts/dra7.dtsi| 4 + > arch/arm/boot/dts/dra72-evm.dts| 6 +- > arch/arm/boot/dts/logicpd-torpedo-som.dtsi | 7 +- > arch/arm/boot/dts/omap3-beagle.dts | 2 + > arch/arm/boot/dts/omap3-cm-t3x.dtsi| 5 +- > arch/arm/boot/dts/omap3-devkit8000-common.dtsi | 3 + > arch/arm/boot/dts/omap3-evm-37xx.dts | 7 +- > arch/arm/boot/dts/omap3-gta04.dtsi | 3 + > arch/arm/boot/dts/omap3-igep.dtsi | 5 +- > arch/arm/boot/dts/omap3-igep0020-common.dtsi | 4 +- > arch/arm/boot/dts/omap3-igep0030-common.dtsi | 4 + > arch/arm/boot/dts/omap3-ldp.dts|
Re: [PATCH v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
Brian/David, On 18/09/15 17:53, Roger Quadros wrote: > Hi, > > We do a couple of things in this series which result in > cleaner device tree implementation, faster perfomance and > multi-platform support. As an added bonus we get new GPI/Interrupt pins > for use in the system. > > - Establish a custom interface between NAND and GPMC driver. This is > needed because all of the NAND registers sit in the GPMC register space. > Some bits like NAND IRQ are even shared with GPMC. > > - Remove NAND IRQ handling from omap-gpmc driver, share the GPMC IRQ > with the omap2-nand driver and handle NAND IRQ events in the NAND driver. > This causes performance increase when using prefetch-irq mode. > 30% increase in read, 17% increase in write in prefetch-irq mode. > > - Clean up device tree support so that omap-gpmc IP and the omap2 NAND > driver can be used on non-OMAP platforms. e.g. Keystone. > > - Implement GPIOCHIP + IRQCHIP for the GPMC WAITPINS. SoCs can contain > 2 to 4 of these and most of them would be unused otherwise. It also > allows a cleaner implementation of NAND Ready pin status for the NAND driver. > > - Implement GPIOlib based NAND ready pin checking for OMAP NAND driver. > > This series is available at > g...@github.com:rogerq/linux.git > in branch > for-v4.4/gpmc-v3 Could you please ack the patches affecting the omap2 nand driver? These would be patches 4, 6, 9, 10, 11, 12, 18. Thanks. cheers, -roger > > Changelog: > v3: > -Fixed and tested NAND using legacy boot on omap3-beagle. > -Support rising and falling edge interrupts on WAITpins. > -Update DT node of all gpmc users. > > Roger Quadros (27): > ARM: OMAP2+: gpmc: Add platform data > ARM: OMAP2+: gpmc: Add gpmc timings and settings to platform data > memory: omap-gpmc: Introduce GPMC to NAND interface > mtd: nand: omap2: Use gpmc_omap_get_nand_ops() to get NAND registers > memory: omap-gpmc: Add GPMC-NAND ops to get writebufferempty status > mtd: nand: omap2: Switch to using GPMC-NAND ops for writebuffer empty > check > memory: omap-gpmc: Remove NAND IRQ code > memory: omap-gpmc: Add IRQ ops for GPMC-NAND interface > mtd: nand: omap2: manage NAND interrupts > mtd: nand: omap: Copy platform data parameters to omap_nand_info data > mtd: nand: omap: Clean up device tree support > mtd: nand: omap: Update DT binding documentation > memory: omap-gpmc: Prevent mapping into 1st 16MB > memory: omap-gpmc: Move device tree binding to correct location > memory: omap-gpmc: Support general purpose input for WAITPINs > memory: omap-gpmc: Reserve WAITPIN if needed for WAIT monitoring > memory: omap-gpmc: Add irqchip support to the gpiochip > mtd: nand: omap2: Implement NAND ready using gpiolib > memory: omap-gpmc: Prevent GPMC_STATUS from being accessed via > gpmc_regs > ARM: dts: dra7: Fix NAND device nodes. > ARM: dts: dra7x-evm: Provide NAND ready pin > ARM: dts: am437x: Fix NAND device nodes > ARM: dts: am437x-gp-evm: Provide NAND ready pin > ARM: dts: am335x: Fix NAND device nodes > ARM: dts: am335x: Provide NAND ready pin > ARM: dts: dm816x: Fix gpmc and NAND node > ARM: dts: omap3: Fix gpmc and NAND nodes > > Documentation/devicetree/bindings/bus/ti-gpmc.txt | 130 - > .../bindings/memory-controllers/omap-gpmc.txt | 130 + > .../devicetree/bindings/mtd/gpmc-nand.txt | 16 +- > arch/arm/boot/dts/am335x-chilisom.dtsi | 7 +- > arch/arm/boot/dts/am335x-evm.dts | 7 +- > arch/arm/boot/dts/am335x-igep0033.dtsi | 7 +- > arch/arm/boot/dts/am33xx.dtsi | 4 + > arch/arm/boot/dts/am4372.dtsi | 4 + > arch/arm/boot/dts/am437x-gp-evm.dts| 8 +- > arch/arm/boot/dts/am43x-epos-evm.dts | 8 +- > arch/arm/boot/dts/dm8168-evm.dts | 7 +- > arch/arm/boot/dts/dm816x.dtsi | 4 + > arch/arm/boot/dts/dra7-evm.dts | 6 +- > arch/arm/boot/dts/dra7.dtsi| 4 + > arch/arm/boot/dts/dra72-evm.dts| 6 +- > arch/arm/boot/dts/logicpd-torpedo-som.dtsi | 7 +- > arch/arm/boot/dts/omap3-beagle.dts | 2 + > arch/arm/boot/dts/omap3-cm-t3x.dtsi| 5 +- > arch/arm/boot/dts/omap3-devkit8000-common.dtsi | 3 + > arch/arm/boot/dts/omap3-evm-37xx.dts | 7 +- > arch/arm/boot/dts/omap3-gta04.dtsi | 3 + > arch/arm/boot/dts/omap3-igep.dtsi | 5 +- > arch/arm/boot/dts/omap3-igep0020-common.dtsi | 4 +- > arch/arm/boot/dts/omap3-igep0030-common.dtsi | 4 + > arch/arm/boot/dts/omap3-ldp.dts| 9 +- > arch/arm/boot/dts/omap3-lilly-a83x.dtsi| 5 +- > arch/arm/boot/dts/omap3-pandora-common.dtsi| 3 + > arch/arm/boot/dts/omap3-tao3530.dtsi | 5 +- > arch/arm/boot/dts/omap3.dtsi