Re: [PATCH 03/12] mtd: nand: omap: Move IRQ handling from GPMC to NAND driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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@xxxxxxxxx> [150713 05:54]:
>>>>> On 2015-07-13 08:40 AM, Tony Lindgren wrote:
>>>>>> * Roger Quadros <rogerq@xxxxxx> [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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]
  Powered by Linux