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

On 29/07/15 18:26, nick wrote:

On 2015-07-29 11:12 AM, Roger Quadros wrote:

quoted

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

quoted

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

That was my other suggestion for IRQ issues. Would you mind sending me a link to a spec sheet so
I can review your patches better as you stated you wanted me to do this for you.

Sure. You can pick up any of omap3/4 or 5 Technical Reference Manuals.
e.g. omap5 TRM is here
http://www.ti.com/product/OMAP5432/technicaldocuments

cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html