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

2015-08-03 Thread Tony Lindgren 
* Roger Quadros rog...@ti.com [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

2015-07-31 Thread Roger Quadros 
On 29/07/15 15:06, Roger Quadros wrote:
 Tony,
 
 On 13/07/15 15:40, Tony Lindgren wrote:
 * Roger Quadros rog...@ti.com [150713 03:07]:
 Tony,

 On 13/07/15 10:10, Tony Lindgren wrote:
 * Roger Quadros rog...@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
 
 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

2015-07-29 Thread Roger Quadros 
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 rog...@ti.com [150713 03:07]:
 Tony,

 On 13/07/15 10:10, Tony Lindgren wrote:
 * Roger Quadros rog...@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

 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

2015-07-29 Thread Roger Quadros 
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 rog...@ti.com [150713 03:07]:
 Tony,

 On 13/07/15 10:10, Tony Lindgren wrote:
 * Roger Quadros rog...@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

 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

2015-07-29 Thread Roger Quadros 
Tony,

On 13/07/15 15:40, Tony Lindgren wrote:
 * Roger Quadros rog...@ti.com [150713 03:07]:
 Tony,

 On 13/07/15 10:10, Tony Lindgren wrote:
 * Roger Quadros rog...@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

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

2015-07-29 Thread Roger Quadros 
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 rog...@ti.com [150713 03:07]:
 Tony,

 On 13/07/15 10:10, Tony Lindgren wrote:
 * Roger Quadros rog...@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

 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

2015-07-13 Thread Roger Quadros 
Tony,

On 13/07/15 10:10, Tony Lindgren wrote:
 * Roger Quadros rog...@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-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

2015-07-13 Thread Tony Lindgren 
* Roger Quadros rog...@ti.com [150713 03:07]:
 Tony,
 
 On 13/07/15 10:10, Tony Lindgren wrote:
  * Roger Quadros rog...@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-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

2015-07-13 Thread Roger Quadros 
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 xerofo...@gmail.com [150713 05:54]:
 On 2015-07-13 08:40 AM, Tony Lindgren wrote:
 * Roger Quadros rog...@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

 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

2015-07-13 Thread Roger Quadros 
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 xerofo...@gmail.com [150713 05:54]:
 On 2015-07-13 08:40 AM, Tony Lindgren wrote:
 * Roger Quadros rog...@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

 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

2015-07-13 Thread Tony Lindgren 
* nick xerofo...@gmail.com [150713 05:54]:
 On 2015-07-13 08:40 AM, Tony Lindgren wrote:
  * Roger Quadros rog...@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-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

2015-07-13 Thread Roger Quadros 
On 13/07/15 16:03, nick wrote:
 
 
 On 2015-07-13 09:01 AM, Tony Lindgren wrote:
 * nick xerofo...@gmail.com [150713 05:54]:
 On 2015-07-13 08:40 AM, Tony Lindgren wrote:
 * Roger Quadros rog...@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

 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

2015-07-13 Thread Tony Lindgren 
* Roger Quadros rog...@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-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

2015-07-10 Thread Roger Quadros 
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 rog...@ti.com
---
 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 +