Brian,

On 03/12/15 10:39, Brian Norris wrote:

Hi,

On Fri, Sep 18, 2015 at 05:53:22PM +0300, Roger Quadros wrote:

quoted

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
git@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