Re: [PATCH v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

[Roger Quadros]

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-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 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

[Tony Lindgren]

* 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-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 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

[Brian Norris]

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-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 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

[Brian Norris]

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-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 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

[Tony Lindgren]

* 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-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 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

[Roger Quadros]

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-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 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

[Brian Norris]

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-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 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

[Brian Norris]

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-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 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

[Brian Norris]

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-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 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

[Roger Quadros]

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-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 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

[Roger Quadros]

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-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 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

[Tony Lindgren]

* 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-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 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

[Brian Norris]

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-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 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

[Roger Quadros]

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

[Roger Quadros]

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
[  

Re: [PATCH v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

[Brian Norris]

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-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 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

[Roger Quadros]

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-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 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

[Tony Lindgren]

* 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-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 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

[Roger Quadros]

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-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 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

[Roger Quadros]

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-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 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

[Tony Lindgren]

* 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-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 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

[Tony Lindgren]

* 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-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 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

[Roger Quadros]

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-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 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

[Tony Lindgren]

* 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-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 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

[Roger Quadros]

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-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 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

[Roger Quadros]

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-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 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

[Tony Lindgren]

* 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-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 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

[Roger Quadros]

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-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 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

[Roger Quadros]

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   

Re: [PATCH v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

[Roger Quadros]

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|