linux-mtd.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Roger Quadros <rogerq@ti.com>
To: nick <xerofoify@gmail.com>, Tony Lindgren <tony@atomide.com>
Cc: <devicetree@vger.kernel.org>, <computersforpeace@gmail.com>,
	<linux-kernel@vger.kernel.org>, <linux-mtd@lists.infradead.org>,
	<ezequiel@vanguardiasur.com.ar>, <bcousson@baylibre.com>,
	<linux-omap@vger.kernel.org>, <dwmw2@infradead.org>
Subject: Re: [PATCH 03/12] mtd: nand: omap: Move IRQ handling from GPMC to NAND driver
Date: Mon, 13 Jul 2015 16:21:17 +0300	[thread overview]
Message-ID: <55A3BB4D.3080003@ti.com> (raw)
In-Reply-To: <55A3B9DD.60705@gmail.com>

On 13/07/15 16:15, nick wrote:
> 
> 
> On 2015-07-13 09:12 AM, Roger Quadros wrote:
>> On 13/07/15 16:03, nick wrote:
>>>
>>>
>>> On 2015-07-13 09:01 AM, Tony Lindgren wrote:
>>>> * nick <xerofoify@gmail.com> [150713 05:54]:
>>>>> On 2015-07-13 08:40 AM, Tony Lindgren wrote:
>>>>>> * Roger Quadros <rogerq@ti.com> [150713 03:07]:
>>>>>>  
>>>>>>> What is the best map we should use for irqchip?
>>>>>>> Some Socs have 4 WAIT pins, some have 3 and some have 2.
>>>>>>>
>>>>>>> Should we start with 0,1,2, for the wait pins and use the next
>>>>>>> available free one for the NAND?
>>>>>>
>>>>>> Maybe we can just use the bits defined for each SoC in the
>>>>>> GPMC_IRQSTATUS register for the mapping?  
>>>>>> Regards,
>>>>>
>>>>> Is that a good idea as to my knowledge of OMAP platforms that register is hardware
>>>>> dependent and therefore that may be an issue unless your idea is to create device
>>>>> tables like the way they do in the nand subsystems to support various vendor's 
>>>>> nand flash expect here for the pins on OMAP SOCs.
>>>>
>>>> Do you mean mapping irqs based on the GPMC_IRQSTATUS register
>>>> bits? If so, that's pretty much how all the GPIO drivers
>>>> handle them. We can have a SoC specific irqmask of the valid
>>>> bits passed from the dts files, and if necessary we can also
>>>> add custom SoC specific IRQ handlers to the GPMC driver if
>>>> needed.
>>>>
>>>> The idea is that the NAND driver can just request the irq
>>>> from the GPMC driver and do whatever it wants with the
>>>> interrupt.
>>>>
>>>> Regards,
>>>>
>>>> Tony
>>>>
>>> Tony,
>>> That is what I was hoping the code was doing. So what appears to be the problem with the 
>>> patches related to irq requesting from the GPMC driver.
>>> Cheers,
>>> Nick 
>>>
>>
>> The problem with this patch is that it expects GPMC_IRQ registers
>> to be accessible by the NAND driver and looses the 2 to 4 pins
>> of WAIT pin edge detection interrupt capability if it is needed
>> for generic use. (not NAND/GPMC memory specific)
>>
>> cheers,
>> -roger
>>
> I am not sure if this is possible with OMAP boards but can we split the pins
> into 1 or 2 for NAND/GPMC memory specific and use the others for WAIT interrupt
> capability.
> Nick
> 
Yes if the wait pins are not used for NAND/GPMC memory then they can be used
as generic edge detect interrupt or probably even a GPI.
I don't see what would prevent it.

I'm not sure if anyone will dare to use them though as they weren't originally meant
for that use and none of the existing kernels support that. So it is really a
chicken and egg situation here. :)

But I see value in doing it the way Tony says cause it is much cleaner to specify
which interrupt (or wait pin) you want for NAND use.

cheers,
-roger

  reply	other threads:[~2015-07-13 13:21 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-10 12:23 [PATCH 00/12] ARM: omap: mtd: nand: Support GPMC NAND on non-OMAP platforms Roger Quadros
2015-07-10 12:23 ` [PATCH 01/12] ARM: OMAP2+: gpmc: Add platform data Roger Quadros
2015-07-10 12:23 ` [PATCH 02/12] ARM: OMAP2+: gpmc: Add gpmc timings and settings to " Roger Quadros
2015-07-13 13:31   ` Tony Lindgren
2015-07-13 13:34     ` Roger Quadros
2015-07-10 12:23 ` [PATCH 03/12] mtd: nand: omap: Move IRQ handling from GPMC to NAND driver Roger Quadros
2015-07-13  7:10   ` Tony Lindgren
2015-07-13 10:04     ` Roger Quadros
2015-07-13 12:40       ` Tony Lindgren
2015-07-13 12:51         ` nick
2015-07-13 13:01           ` Tony Lindgren
2015-07-13 13:03             ` nick
2015-07-13 13:12               ` Roger Quadros
2015-07-13 13:15                 ` nick
2015-07-13 13:21                   ` Roger Quadros [this message]
2015-07-13 13:32                     ` nick
2015-07-13 13:35                       ` Roger Quadros
2015-07-29 12:06         ` Roger Quadros
2015-07-29 12:13           ` nick
2015-07-29 13:52             ` Roger Quadros
2015-07-29 14:08               ` nick
2015-07-29 15:12                 ` Roger Quadros
2015-07-29 15:26                   ` nick
2015-07-29 15:39                     ` Roger Quadros
2015-07-31 10:21           ` Roger Quadros
2015-08-03 13:08             ` Tony Lindgren
2015-07-10 12:23 ` [PATCH 04/12] mtd: nand: omap: Move gpmc_update_nand_reg to nand driver Roger Quadros
2015-07-10 12:23 ` [PATCH 05/12] mtd: nand: omap: Move NAND write protect code from GPMC to NAND driver Roger Quadros
2015-07-10 12:23 ` [PATCH 06/12] mtd: nand: omap: Copy platform data parameters to omap_nand_info data Roger Quadros
2015-07-10 12:23 ` [PATCH 07/12] mtd: nand: omap: Clean up device tree support Roger Quadros
2015-07-10 12:23 ` [PATCH 08/12] mtd: nand: omap: Update DT binding documentation Roger Quadros
2015-07-10 12:23 ` [PATCH 09/12] memory: omap-gpmc: use module_platform_driver() Roger Quadros
2015-07-10 12:23 ` [PATCH 10/12] memory: omap-gpmc: Prevent mapping into 1st 16MB Roger Quadros
2015-07-10 12:23 ` [PATCH 11/12] ARM: dts: OMAP2+: Fix NAND device nodes Roger Quadros
2015-07-10 12:23 ` [PATCH 12/12] ARM: dts: omap3: Fix gpmc memory resource size Roger Quadros

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=55A3BB4D.3080003@ti.com \
    --to=rogerq@ti.com \
    --cc=bcousson@baylibre.com \
    --cc=computersforpeace@gmail.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dwmw2@infradead.org \
    --cc=ezequiel@vanguardiasur.com.ar \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=tony@atomide.com \
    --cc=xerofoify@gmail.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).