Re: [PATCH 03/12] mtd: nand: omap: Move IRQ handling from GPMC to NAND driver
* Roger Quadros [150731 03:24]:
>
> One more observation I've had is that using irqchip modelling for
> the 2 NAND events causes a performance impact.
>
> Using mtd_oobtest I see the following on dra7-evm
>
> 1) v4.2-rc4 with prefetch-polled (no IRQs used)
> mtd_speedtest: eraseblock write speed is 7142 KiB/s
> mtd_speedtest: eraseblock read speed is 13721 KiB/s
>
> 2) v4.2-rc4 with prefetch-irq (IRQchip model)
> eraseblock write speed is 5475 KiB/s
> eraseblock read speed is 6420 KiB/s
>
> 3) this series (*) with prefetch-irq (no IRQchip model, nand driver
> directly accesses irqstatus/irqenable)
> eraseblock write speed is 6564 KiB/s
> eraseblock read speed is 10850 KiB/s
>
> (*) diff at the end is required on top to fix an issue with this series.
>
> So should we continue IRQchip modelling for the NAND events
> or use the GPMC interrupt as shared and add APIs to access
> the NAND bits of the IRQSTATUS/ENABLE register.
In the long run chained IRQ would be the most flexible solution
for sure.
It might be worth checking why we have so much overhead with
the irqchip modelling compared to shared IRQ. If the overhead
is really all the extra IRQ handling then it seems the shared
interrupt plus an API to access IRQSTATUS/ENABLE is the way
to go. Up to you.
Regards,
Tony
> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
> index fecc054..26ef2bd 100644
> --- a/drivers/mtd/nand/omap2.c
> +++ b/drivers/mtd/nand/omap2.c
> @@ -1832,13 +1832,14 @@ static int omap_get_dt_info(struct device *dev,
> struct omap_nand_info *info)
> for (i = 0; i < ARRAY_SIZE(nand_xfer_types); i++) {
> if (!strcasecmp(s, nand_xfer_types[i])) {
> info->xfer_type = i;
> - break;
> + goto next;
> }
> }
>
> dev_err(dev, "unrecognized value for ti,nand-xfer-type\n");
> return -EINVAL;
> }
> +next:
>
> of_get_nand_on_flash_bbt(child);
>
> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
> index 26ef2bd..e8bdff5 100644
> --- a/drivers/mtd/nand/omap2.c
> +++ b/drivers/mtd/nand/omap2.c
> @@ -670,17 +670,12 @@ static irqreturn_t omap_nand_irq(int this_irq, void
> *dev)
> goto done;
> }
>
> - /* Clear FIFOEVENT STATUS */
> - irqstatus &= ~GPMC_IRQ_FIFOEVENT;
> - writel(irqstatus, info->reg.gpmc_irqstatus);
> -
> return IRQ_HANDLED;
>
> done:
> complete(&info->comp);
>
> - /* Clear FIFOEVENT and TERMCOUNT STATUS */
> - irqstatus &= ~(GPMC_IRQ_TERMCOUNT | GPMC_IRQ_FIFOEVENT);
> + /* Clear IRQ STATUS */
> writel(irqstatus, info->reg.gpmc_irqstatus);
>
> /* Disable Interrupt generation */
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/12] mtd: nand: omap: Move IRQ handling from GPMC to NAND driver
On 29/07/15 15:06, Roger Quadros wrote:
> Tony,
>
> On 13/07/15 15:40, Tony Lindgren wrote:
>> * Roger Quadros [150713 03:07]:
>>> Tony,
>>>
>>> On 13/07/15 10:10, Tony Lindgren wrote:
* Roger Quadros [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
>
> 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.
One more observation I've had is that using irqchip modelling for
the 2 NAND events causes a performance impact.
Using mtd_oobtest I see the following on dra7-evm
1) v4.2-rc4 with prefetch-polled (no IRQs used)
mtd_speedtest: eraseblock write speed is 7142 KiB/s
mtd_speedtest: eraseblock read speed is 13721 KiB/s
2) v4.2-rc4 with prefetch-irq (IRQchip model)
eraseblock write speed is 5475 KiB/s
eraseblock read speed is 6420 KiB/s
3) this series (*) with prefetch-irq (no IRQchip model, nand driver
directly accesses irqstatus/irqenable)
eraseblock write speed is 6564 KiB/s
eraseblock read speed is 10850 KiB/s
(*) diff at the end is required on top to fix an issue with this series.
So should we continue IRQchip modelling for the NAND events
or use the GPMC interrupt as shared and add APIs to access
the NAND bits of the IRQSTATUS/ENABLE register.
cheers,
-roger
--
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index fecc054..26ef2bd 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -1832,13 +1832,14 @@ static int omap_get_dt_info(struct device *dev, struct
omap_nand_info *info)
for (i = 0; i < ARRAY_SIZE(nand_xfer_types); i++) {
if (!strcasecmp(s, nand_xfer_types[i])) {
info->xfer_type = i;
- break;
+ goto next;
}
}
dev_err(dev, "unrecognized value for ti,nand-xfer-type\n");
return -EINVAL;
}
+next:
of_get_nand_on_flash_bbt(child);
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 26ef2bd..e8bdff5 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -670,17 +670,12 @@ static irqreturn_t omap_nand_irq(int this_irq, void *dev)
goto done;
}
- /* Clear FIFOEVENT STATUS */
- irqstatus &= ~GPMC_IRQ_FIFOEVENT;
- writel(irqstatus, info->reg.gpmc_irqstatus);
-
return IRQ_HANDLED;
done:
complete(&info->comp);
- /* Clear FIFOEVENT and TERMCOUNT STATUS */
- irqstatus &= ~(GPMC_IRQ_TERMCOUNT | GPMC_IRQ_FIFOEVENT);
+ /* Clear IRQ STATUS */
writel(irqstatus, info->reg.gpmc_irqstatus);
/* Disable Interrupt generation */
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
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: >> On 29/07/15 17:08, nick wrote: >>> >>> >>> On 2015-07-29 09:52 AM, Roger Quadros wrote: On 29/07/15 15:13, nick wrote: > > > On 2015-07-29 08:06 AM, Roger Quadros wrote: >> Tony, >> >> On 13/07/15 15:40, Tony Lindgren wrote: >>> * Roger Quadros [150713 03:07]: Tony, On 13/07/15 10:10, Tony Lindgren wrote: > * Roger Quadros [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 >> >> 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 linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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: >> On 29/07/15 15:13, nick wrote: >>> >>> >>> On 2015-07-29 08:06 AM, Roger Quadros wrote: Tony, On 13/07/15 15:40, Tony Lindgren wrote: > * Roger Quadros [150713 03:07]: >> Tony, >> >> On 13/07/15 10:10, Tony Lindgren wrote: >>> * Roger Quadros [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 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 >>> Nick > >> 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 > __ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/12] mtd: nand: omap: Move IRQ handling from GPMC to NAND driver
On 29/07/15 15:13, nick wrote: > > > On 2015-07-29 08:06 AM, Roger Quadros wrote: >> Tony, >> >> On 13/07/15 15:40, Tony Lindgren wrote: >>> * Roger Quadros [150713 03:07]: Tony, On 13/07/15 10:10, Tony Lindgren wrote: > * Roger Quadros [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 >> >> 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 > Nick >>> 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 >>> >> >> __ >> Linux MTD discussion mailing list >> http://lists.infradead.org/mailman/listinfo/linux-mtd/ >> -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/12] mtd: nand: omap: Move IRQ handling from GPMC to NAND driver
Tony, On 13/07/15 15:40, Tony Lindgren wrote: > * Roger Quadros [150713 03:07]: >> Tony, >> >> On 13/07/15 10:10, Tony Lindgren wrote: >>> * Roger Quadros [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 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 > >> 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-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/12] mtd: nand: omap: Move IRQ handling from GPMC to NAND driver
On 13/07/15 16:32, nick wrote: > > > On 2015-07-13 09:21 AM, Roger Quadros wrote: >> 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 [150713 05:54]: >>> On 2015-07-13 08:40 AM, Tony Lindgren wrote: * Roger Quadros [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 >> > I would also have to agree with Tony about this issue and feel his solution > seems fine. However why don't recent kernel's support this feature? > Nick > kernel supports the feature but OMAP GPMC/NAND driver never supported it because nobody implemented it. cheers, -roger -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/12] mtd: nand: omap: Move IRQ handling from GPMC to NAND driver
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 [150713 05:54]: > On 2015-07-13 08:40 AM, Tony Lindgren wrote: >> * Roger Quadros [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 linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/12] mtd: nand: omap: Move IRQ handling from GPMC to NAND driver
On 13/07/15 16:03, nick wrote: > > > On 2015-07-13 09:01 AM, Tony Lindgren wrote: >> * nick [150713 05:54]: >>> On 2015-07-13 08:40 AM, Tony Lindgren wrote: * Roger Quadros [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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/12] mtd: nand: omap: Move IRQ handling from GPMC to NAND driver
* nick [150713 05:54]: > On 2015-07-13 08:40 AM, Tony Lindgren wrote: > > * Roger Quadros [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-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/12] mtd: nand: omap: Move IRQ handling from GPMC to NAND driver
* Roger Quadros [150713 03:07]: > Tony, > > On 13/07/15 10:10, Tony Lindgren wrote: > > * Roger Quadros [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-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/12] mtd: nand: omap: Move IRQ handling from GPMC to NAND driver
Tony, On 13/07/15 10:10, Tony Lindgren wrote: > * Roger Quadros [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-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/12] mtd: nand: omap: Move IRQ handling from GPMC to NAND driver
* Roger Quadros [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-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/12] mtd: nand: omap: Move IRQ handling from GPMC to NAND driver
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.
Let's manage the interrupt registers directly in the NAND driver
and get rid of irqchip model from GPMC driver.
Get rid of IRQ commands and unused commands from gpmc_configure() in
the GPMC driver.
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap2/gpmc-nand.c | 4 +-
drivers/memory/omap-gpmc.c | 176 ++-
drivers/mtd/nand/omap2.c | 76 ++--
include/linux/omap-gpmc.h| 5 +-
include/linux/platform_data/mtd-nand-omap2.h | 2 +
5 files changed, 56 insertions(+), 207 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index 72918c4..b960876 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -80,7 +80,6 @@ int gpmc_nand_init(struct omap_nand_platform_data
*gpmc_nand_data,
struct resource gpmc_nand_res[] = {
{ .flags = IORESOURCE_MEM, },
{ .flags = IORESOURCE_IRQ, },
- { .flags = IORESOURCE_IRQ, },
};
BUG_ON(gpmc_nand_data->cs >= GPMC_CS_NUM);
@@ -93,8 +92,7 @@ int gpmc_nand_init(struct omap_nand_platform_data
*gpmc_nand_data,
return err;
}
gpmc_nand_res[0].end = gpmc_nand_res[0].start + NAND_IO_SIZE - 1;
- gpmc_nand_res[1].start = gpmc_get_client_irq(GPMC_IRQ_FIFOEVENTENABLE);
- gpmc_nand_res[2].start = gpmc_get_client_irq(GPMC_IRQ_COUNT_EVENT);
+ gpmc_nand_res[1].start = gpmc_get_irq();
memset(&s, 0, sizeof(struct gpmc_settings));
if (gpmc_nand_data->of_node)
diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
index 3a27a84..50806e7 100644
--- a/drivers/memory/omap-gpmc.c
+++ b/drivers/memory/omap-gpmc.c
@@ -121,12 +121,6 @@
#define GPMC_CS_NAND_ADDRESS 0x20
#define GPMC_CS_NAND_DATA 0x24
-/* Control Commands */
-#define GPMC_CONFIG_RDY_BSY0x0001
-#define GPMC_CONFIG_DEV_SIZE 0x0002
-#define GPMC_CONFIG_DEV_TYPE 0x0003
-#define GPMC_SET_IRQ_STATUS0x0004
-
#define GPMC_CONFIG1_WRAPBURST_SUPP (1 << 31)
#define GPMC_CONFIG1_READMULTIPLE_SUPP (1 << 30)
#define GPMC_CONFIG1_READTYPE_ASYNC (0 << 29)
@@ -174,17 +168,11 @@
#define GPMC_CONFIG_WRITEPROTECT 0x0010
#define WR_RD_PIN_MONITORING 0x0060
-#define GPMC_ENABLE_IRQ0x000d
-
/* ECC commands */
#define GPMC_ECC_READ 0 /* Reset Hardware ECC for read */
#define GPMC_ECC_WRITE 1 /* Reset Hardware ECC for write */
#define GPMC_ECC_READSYN 2 /* Reset before syndrom is read back */
-/* XXX: Only NAND irq has been considered,currently these are the only ones
used
- */
-#defineGPMC_NR_IRQ 2
-
enum gpmc_clk_domain {
GPMC_CD_FCLK,
GPMC_CD_CLK
@@ -199,11 +187,6 @@ struct gpmc_cs_data {
struct resource mem;
};
-struct gpmc_client_irq {
- unsignedirq;
- u32 bitmask;
-};
-
/* Structure to save gpmc cs context */
struct gpmc_cs_config {
u32 config1;
@@ -231,10 +214,6 @@ struct omap3_gpmc_regs {
struct gpmc_cs_config cs_context[GPMC_CS_NUM];
};
-static struct gpmc_client_irq gpmc_client_irq[GPMC_NR_IRQ];
-static struct irq_chip gpmc_irq_chip;
-static int gpmc_irq_start;
-
static struct resource gpmc_mem_root;
static struct gpmc_cs_data gpmc_cs[GPMC_CS_NUM];
static DEFINE_SPINLOCK(gpmc_mem_lock);
@@ -242,15 +221,13 @@ static DEFINE_SPINLOCK(gpmc_mem_lock);
static unsigned int gpmc_cs_num = GPMC_CS_NUM;
static unsigned int gpmc_nr_waitpins;
static struct device *gpmc_dev;
-static int gpmc_irq;
+static int gpmc_irq = -EINVAL;
static resource_size_t phys_base, mem_size;
static unsigned gpmc_capability;
static void __iomem *gpmc_base;
static struct clk *gpmc_l3_clk;
-static irqreturn_t gpmc_handle_irq(int irq, void *dev);
-
static void gpmc_write_reg(int idx, u32 val)
{
writel_relaxed(val, gpmc_base + idx);
@@ -1035,14 +1012,6 @@ int gpmc_configure(int cmd, int wval)
u32 regval;
switch (cmd) {
- case GPMC_ENABLE_IRQ:
- gpmc_write_reg(GPMC_IRQENABLE, wval);
- break;
-
- case GPMC_SET_IRQ_STATUS:
- gpmc_write_reg(GPMC_IRQSTATUS, wval);
- break;
-
case GPMC_CONFIG_WP:
regval = gpmc_read_reg(GPMC_CONFIG);
if (wval)
@@ -1066,6 +1035,8 @@ void gpmc_update_nand_reg(struct gpmc_nand_regs *reg, int
cs)
int i;
reg->gpmc_status = gpmc_base + GPMC_STATUS;
+ reg->gpmc_irqstatus = gpmc_base + GPMC_IRQSTATUS;
+ reg->gpmc_irqenable = gpmc_base + GPMC_IRQENABLE;
reg->gpmc_nand_command = gpmc_base + GPMC_CS0_OFFSET +
GPMC_CS_N
