Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1182550 > unrolled thread

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

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 03/12] mtd: nand: omap: Move IRQ handling from GPMC to  NAND driver Tony Lindgren <tony@atomide.com> - 2015-07-13 09:20 +0200
    Re: [PATCH 03/12] mtd: nand: omap: Move IRQ handling from GPMC to  NAND driver Roger Quadros <rogerq@ti.com> - 2015-07-13 12:10 +0200
      Re: [PATCH 03/12] mtd: nand: omap: Move IRQ handling from GPMC to  NAND driver Tony Lindgren <tony@atomide.com> - 2015-07-13 14:50 +0200
        Re: [PATCH 03/12] mtd: nand: omap: Move IRQ handling from GPMC to  NAND driver Tony Lindgren <tony@atomide.com> - 2015-07-13 15:10 +0200

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

* Roger Quadros <rogerq@ti.com> [150710 05:26]:
> 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.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1182685

Tony,

On 13/07/15 10:10, Tony Lindgren wrote:
> * Roger Quadros <rogerq@ti.com> [150710 05:26]:
>> 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.

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.

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?

cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1182783

* Roger Quadros <rogerq@ti.com> [150713 03:07]:
> Tony,
> 
> On 13/07/15 10:10, Tony Lindgren wrote:
> > * Roger Quadros <rogerq@ti.com> [150710 05:26]:
> >> 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
 
> 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
 
> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1182794

* 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web