From: Roger Quadros <rogerq@ti.com>
To: Brian Norris <computersforpeace@gmail.com>, <tony@atomide.com>
Cc: <dwmw2@infradead.org>, <ezequiel@vanguardiasur.com.ar>,
<javier@dowhile0.org>, <fcooper@ti.com>, <nsekhar@ti.com>,
<linux-mtd@lists.infradead.org>, <linux-omap@vger.kernel.org>,
<devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
Date: Thu, 3 Dec 2015 14:31:37 +0530 [thread overview]
Message-ID: <566004F1.2040806@ti.com> (raw)
In-Reply-To: <20151203062206.GB16368@brian-ubuntu>
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
>>>> 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.
>
> 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
next prev parent reply other threads:[~2015-12-03 9:02 UTC|newest]
Thread overview: 79+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-18 14:53 [PATCH v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms Roger Quadros
2015-09-18 14:53 ` [PATCH v3 01/27] ARM: OMAP2+: gpmc: Add platform data Roger Quadros
2015-09-18 14:53 ` [PATCH v3 02/27] ARM: OMAP2+: gpmc: Add gpmc timings and settings to " Roger Quadros
2015-09-18 14:53 ` [PATCH v3 03/27] memory: omap-gpmc: Introduce GPMC to NAND interface Roger Quadros
2015-09-18 14:53 ` [PATCH v3 04/27] mtd: nand: omap2: Use gpmc_omap_get_nand_ops() to get NAND registers Roger Quadros
2015-12-03 5:00 ` Brian Norris
2015-09-18 14:53 ` [PATCH v3 05/27] memory: omap-gpmc: Add GPMC-NAND ops to get writebufferempty status Roger Quadros
2015-09-18 14:53 ` [PATCH v3 06/27] mtd: nand: omap2: Switch to using GPMC-NAND ops for writebuffer empty check Roger Quadros
2015-09-18 14:53 ` [PATCH v3 07/27] memory: omap-gpmc: Remove NAND IRQ code Roger Quadros
2015-09-18 14:53 ` [PATCH v3 08/27] memory: omap-gpmc: Add IRQ ops for GPMC-NAND interface Roger Quadros
2015-09-18 14:53 ` [PATCH v3 09/27] mtd: nand: omap2: manage NAND interrupts Roger Quadros
2015-09-18 14:53 ` [PATCH v3 10/27] mtd: nand: omap: Copy platform data parameters to omap_nand_info data Roger Quadros
2015-09-18 14:53 ` [PATCH v3 11/27] mtd: nand: omap: Clean up device tree support Roger Quadros
2015-10-06 10:35 ` [PATCH v4 " Roger Quadros
2015-12-03 4:29 ` Brian Norris
2015-12-03 5:57 ` Roger Quadros
2015-12-03 6:09 ` Brian Norris
2015-09-18 14:53 ` [PATCH v3 12/27] mtd: nand: omap: Update DT binding documentation Roger Quadros
2015-09-18 14:53 ` [PATCH v3 13/27] memory: omap-gpmc: Prevent mapping into 1st 16MB Roger Quadros
2015-09-18 14:53 ` [PATCH v3 14/27] memory: omap-gpmc: Move device tree binding to correct location Roger Quadros
2015-09-18 14:53 ` [PATCH v3 15/27] memory: omap-gpmc: Support general purpose input for WAITPINs Roger Quadros
2015-09-18 14:53 ` [PATCH v3 16/27] memory: omap-gpmc: Reserve WAITPIN if needed for WAIT monitoring Roger Quadros
2015-09-18 14:53 ` [PATCH v3 17/27] memory: omap-gpmc: Add irqchip support to the gpiochip Roger Quadros
2015-09-18 14:53 ` [PATCH v3 18/27] mtd: nand: omap2: Implement NAND ready using gpiolib Roger Quadros
2015-10-26 20:49 ` Brian Norris
2015-10-27 8:03 ` Roger Quadros
2015-10-27 8:12 ` Boris Brezillon
2015-10-27 8:43 ` Roger Quadros
2015-10-27 8:28 ` Boris Brezillon
2015-12-03 4:45 ` Brian Norris
2015-12-03 8:41 ` Boris Brezillon
2015-09-18 14:53 ` [PATCH v3 19/27] memory: omap-gpmc: Prevent GPMC_STATUS from being accessed via gpmc_regs Roger Quadros
2015-09-18 14:53 ` [PATCH v3 20/27] ARM: dts: dra7: Fix NAND device nodes Roger Quadros
2015-10-14 13:34 ` Franklin S Cooper Jr.
2015-10-14 14:17 ` Roger Quadros
2015-10-14 14:37 ` Franklin S Cooper Jr.
2015-09-18 14:53 ` [PATCH v3 21/27] ARM: dts: dra7x-evm: Provide NAND ready pin Roger Quadros
2015-09-18 14:53 ` [PATCH v3 22/27] ARM: dts: am437x: Fix NAND device nodes Roger Quadros
2015-09-18 14:53 ` [PATCH v3 23/27] ARM: dts: am437x-gp-evm: Provide NAND ready pin Roger Quadros
2015-09-18 14:53 ` [PATCH v3 24/27] ARM: dts: am335x: Fix NAND device nodes Roger Quadros
2015-09-18 14:53 ` [PATCH v3 25/27] ARM: dts: am335x: Provide NAND ready pin Roger Quadros
2015-09-18 14:53 ` [PATCH v3 26/27] ARM: dts: dm816x: Fix gpmc and NAND node Roger Quadros
2015-09-18 14:53 ` [PATCH v3 27/27] ARM: dts: omap3: Fix gpmc and NAND nodes Roger Quadros
2015-10-13 0:43 ` Tony Lindgren
2015-10-13 6:29 ` Roger Quadros
2015-10-13 15:18 ` Tony Lindgren
2015-10-14 7:39 ` Roger Quadros
2015-10-14 8:55 ` [PATCH v4 " Roger Quadros
2015-09-30 7:39 ` [PATCH v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms Roger Quadros
2015-09-30 11:00 ` Roger Quadros
2015-10-06 8:33 ` Tony Lindgren
2015-10-06 9:54 ` Roger Quadros
2015-10-06 10:00 ` Tony Lindgren
2015-10-06 10:05 ` Roger Quadros
2015-10-06 10:28 ` Roger Quadros
2015-10-06 11:01 ` Tony Lindgren
2015-10-06 11:09 ` Roger Quadros
2015-10-16 21:25 ` Tony Lindgren
2015-10-19 7:08 ` Roger Quadros
2015-10-21 8:31 ` Roger Quadros
2015-10-21 15:20 ` Tony Lindgren
2015-10-23 7:09 ` Roger Quadros
2015-11-30 17:26 ` Tony Lindgren
2015-10-26 21:23 ` Brian Norris
2015-10-27 9:37 ` Roger Quadros
2015-11-25 10:42 ` Roger Quadros
2015-11-30 19:54 ` Brian Norris
2015-12-01 14:41 ` Roger Quadros
2015-12-02 3:26 ` Brian Norris
2015-12-02 5:12 ` Roger Quadros
2015-12-02 15:03 ` Tony Lindgren
2015-12-02 18:13 ` Brian Norris
2015-12-02 20:05 ` Tony Lindgren
2015-12-02 18:43 ` Brian Norris
2015-12-03 5:09 ` Brian Norris
2015-12-03 6:08 ` Roger Quadros
2015-12-03 6:22 ` Brian Norris
2015-12-03 9:01 ` Roger Quadros [this message]
2015-12-03 15:17 ` Tony Lindgren
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=566004F1.2040806@ti.com \
--to=rogerq@ti.com \
--cc=computersforpeace@gmail.com \
--cc=devicetree@vger.kernel.org \
--cc=dwmw2@infradead.org \
--cc=ezequiel@vanguardiasur.com.ar \
--cc=fcooper@ti.com \
--cc=javier@dowhile0.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=nsekhar@ti.com \
--cc=tony@atomide.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).