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

On 29/07/15 17:08, nick wrote:

On 2015-07-29 09:52 AM, Roger Quadros wrote:

quoted

On 29/07/15 15:13, nick wrote:

quoted

On 2015-07-29 08:06 AM, Roger Quadros wrote:

quoted

Tony,

On 13/07/15 15:40, Tony Lindgren wrote:

quoted

* Roger Quadros [off-list ref] [150713 03:07]:

quoted

Tony,

On 13/07/15 10:10, Tony Lindgren wrote:

quoted

* Roger Quadros [off-list ref] [150710 05:26]:

quoted

Since the Interrupt Events are used only by the NAND driver,
there is no point in managing the Interrupt registers
in the GPMC driver and complicating it with irqchip modeling.

I don't think it's a good idea to allow external drivers to
tinker directly with GPMC registers. How about just set up GPMC
as an irqchip for the edge detection interrupts?

I think we already have devices with multiple NAND chips. And
there's nothing stopping other drivers from using the edge
detection interrupts.

OK. The GPMC_IRQ registers manage 2 NAND specific interrupts
(terminalcount and fifo) and 'n' WAIT pin edge interrupts.

 So we can model this as a irqchip with 'n + 2' interrupts.

OK

For the wait pins irqchip is not sufficient and it needs to be gpiochip
with irqchip. Waitpin status can be read from GPIO_STATUS register.

Just getting the interrupt is not enough and we want to know if the
line is high or low. That is how nand->dev_ready works.

How about having 2 IRQ domains?
One is irqchip with 2 interrupts (terminalcount and fifo) and second is
gpiochip + irqchip for the n wait pins.

The nand driver can then be modified to use GPIO to get Read/Busy
pin status from the wait pin.

cheers,
-roger

Doesn't OMAP boards support shared IRQs and if so why not share them across one
IRQ domain if possible to save IRQ domains for other hardware that needs its 
own IRQ domain. This is just a suggestion through as I don't have the hardware
spec sheet on me Roger.

IRQ domain is a virtual abstraction introduced to prevent kernel irq number overlapping
in a single flat domain. I don't see what you can save by domain reuse.
Some memory maybe at most.

Shared interrupt is something totally different but we're trying to add real
hardware interrupts here. Didn't understand what you will share it with.

cheers,
-roger

My question then is do these hardware interrupts need to be on their own interrupt line
for the CPU or can they share a CPU line as my concern is if possible we may be able to
save a interrupt line for other use. I known on Intel CPUs this is a very limited resource
but not sure on OMAP based boards if not then just avoid my recommendations.

It is like adding an external interrupt controller to expand the number of available
hardware interrupts.
This interrupt controller will still use the same GPMC IRQ line to propagate the
irq event upwards.

cheers,
-roger

Nick 

quoted

quoted

Nick 

quoted

quoted

quoted

We need to take care that if a GPMC chip select needs a
wait pin then it can't be used as a generic interrupt.

We need to get rid of omap_dev_ready() in nand/omap2.c as
it accesses the GPMC_STATUS register directly. Plus it is
hard coded to only monitor wait0 pin.

OK
 

quoted

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,

Tony

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/