From: u.kleine-koenig@pengutronix.de (Uwe Kleine-König)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 06/13] ARM: LPC32XX: Core architecture files
Date: Thu, 4 Feb 2010 09:17:45 +0100 [thread overview]
Message-ID: <20100204081744.GA5380@pengutronix.de> (raw)
In-Reply-To: <083DF309106F364B939360100EC290F805C8B787EB@eu1rdcrdc1wx030.exi.nxp.com>
Hello,
On Wed, Feb 03, 2010 at 10:58:55PM +0100, Kevin Wells wrote:
> > > > > + case IRQ_TYPE_EDGE_FALLING:
> > > > > + /* Falling edge sensitive */
> > > > > + reg = readl(ctrl + INTC_POLAR);
> > > > > + reg &= ~mask;
> > > > > + writel(reg, (ctrl + INTC_POLAR));
> > > > > + reg = readl(ctrl + INTC_ACT_TYPE);
> > > > > + reg |= mask;
> > > > > + writel(reg, (ctrl + INTC_ACT_TYPE));
> > > > > + set_irq_handler(irq, handle_edge_irq);
> > > > > + break;
> > > > did you test that you really need handle_edge_irq? Sane irq
> > controllers
> > > > can (and should) use handle_level_irq for both level and edge
> > sensitive
> > > > irqs. You only need handle_edge_irq if your controller doesn't
> > remember
> > > > edge transitions while the irq is masked.
> > >
> > > This is supported and intended. It's important for slow moving external
> > > GPIO events where you can't clear the active level state or pulse
> > > duration (ie, switches).
> > I didn't understand your answer here. What is supported and intended?
> > This has something to do with your controller, not with slow external
> > things.
> >
>
> The controller supports level and edge sensitive modes. There are cases
> when using external events that you want an edge based interrupt. For
> example, an event connected to a monetary switch will stay asserted
> (level-wise) as long as the switch is closed. The interrupt controller
> latches the event and can clear the latch, but the latch would never
> clear if the interrupt was level sensitive. In cases like this, you just
> want to handle the edges. This has been tested.
Oh yes. Of course. I'll retry to make my point more explicit using some
code.
Did you verify the following is broken? :
static int lpc32xx_set_irq_type(unsigned int irq, unsigned int type)
{
unsigned int reg, ctrl, mask;
get_controller(irq, &ctrl, &mask);
switch (type) {
case IRQ_TYPE_EDGE_RISING:
/* Rising edge sensitive */
__set_irq_type(ctrl, mask, mask, mask);
/*
* don't set irq_handler to handle_edge_irq here
* as handle_level_irq can handle edge sensitive
* irqs just fine. Of course the controller
* needs to be setup for edge irqs to get any
* difference to IRQ_TYPE_LEVEL_HIGH.
* See
* http://mid.gmane.org/20091007102836.GA27860 at flint.arm.linux.org.uk
* for some details
*/
break;
case IRQ_TYPE_EDGE_FALLING:
/* Falling edge sensitive */
__set_irq_type(ctrl, mask, 0, mask);
/* don't set irq_handler to handle_edge_irq here */
break;
case IRQ_TYPE_LEVEL_LOW:
/* Low level sensitive */
__set_irq_type(ctrl, mask, 0, 0);
...
}
...
void __init lpc32xx_init_irq(void)
{
...
for (i = 0; i < NR_IRQS; i++) {
set_irq_flags(i, IRQF_VALID);
set_irq_chip(i, &lpc32xx_irq_chip);
/*
* use handle_level_irq for edge and level
* triggered irqs
*/
set_irq_handler(irq, handle_level_irq);
}
...
}
> > > > Does this work without NO_HZ? I though you need to setup a periodic
> > > > mode with CONFIG_HZ irqs per second first?
> > >
> > > This is handled in the clockevents handler. It will setup the driver
> > > for the next event in the set_next_event callback. I believe the
> > > current CONFIG_HZ rate is set to 100.
> > Hmmm:
> >
> > ~/gsrc/linux-2.6/arch/arm/mach-lpc32xx$ grep HZ *
> > ~/gsrc/linux-2.6/arch/arm/mach-lpc32xx$
> >
>
> CONFIG_HZ is defined in the phy3250_defconfig file in arch/arms/configs.
> It's actually used in the clock events driver and passes the next tick delta
> to the timer driver callback. The timer driver itself doesn't know the tick
> rate or even the value of HZ - it's in the higher layers. Note this timer
> driver also works fine with NO_HZ. Sorry about the confusion on this.
Probably it's really just me who is confused, but I wondered if this
works *without* NO_HZ as I thought the timer init function is supposed
to set up a HZ tick.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
next prev parent reply other threads:[~2010-02-04 8:17 UTC|newest]
Thread overview: 72+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-28 1:43 LPC32XX architecture files (updated) wellsk40 at gmail.com
2010-01-28 1:43 ` [PATCH 01/13] i2c_pnx: Added Kconfig support for the LCP32XX wellsk40 at gmail.com
2010-01-28 1:43 ` [PATCH 02/13] pnx4008_wdt: Added Kconfig support for the LPC32XX wellsk40 at gmail.com
2010-01-28 1:43 ` [PATCH 03/13] amba clcd: Swapped CTRL/IENB registers for LCP32XX wellsk40 at gmail.com
2010-01-28 1:43 ` [PATCH 04/13] ARM: LPC32XX arch support in Kconfig and Makefile wellsk40 at gmail.com
2010-02-03 10:31 ` Uwe Kleine-König
2010-01-28 1:43 ` [PATCH 05/13] ARM: LPC32XX: arch Kconfig, plat Kconfig, and makefiles wellsk40 at gmail.com
2010-02-03 10:51 ` Uwe Kleine-König
2010-02-03 11:26 ` Russell King - ARM Linux
2010-02-03 13:57 ` Uwe Kleine-König
2010-02-03 15:02 ` Russell King - ARM Linux
2010-02-03 18:01 ` Kevin Wells
2010-02-03 18:56 ` Uwe Kleine-König
2010-01-28 1:43 ` [PATCH 06/13] ARM: LPC32XX: Core architecture files wellsk40 at gmail.com
2010-01-28 17:58 ` H Hartley Sweeten
2010-01-28 19:54 ` Kevin Wells
2010-02-03 10:54 ` Uwe Kleine-König
2010-02-03 18:05 ` Kevin Wells
2010-02-03 15:55 ` Uwe Kleine-König
2010-02-03 18:43 ` Kevin Wells
2010-02-03 20:40 ` Uwe Kleine-König
2010-02-03 21:58 ` Kevin Wells
2010-02-04 8:17 ` Uwe Kleine-König [this message]
2010-02-08 9:09 ` [PATCH 1/3] gpiolib: make names array and its values const Uwe Kleine-König
2010-02-08 9:09 ` Uwe Kleine-König
2010-02-08 9:37 ` Baruch Siach
2010-02-08 9:37 ` Baruch Siach
2010-02-08 9:43 ` Uwe Kleine-König
2010-02-08 9:43 ` Uwe Kleine-König
2010-02-24 10:35 ` Uwe Kleine-König
2010-02-24 10:35 ` Uwe Kleine-König
2010-03-22 20:47 ` Uwe Kleine-König
2010-03-22 20:47 ` Uwe Kleine-König
2010-03-23 10:24 ` Uwe Kleine-König
2010-03-23 10:24 ` [PATCH 2/3] gpiolib: a gpio is unsigned, so use %u to print it Uwe Kleine-König
2010-03-23 10:24 ` [PATCH 3/3] gpiolib: document that names can contain printk format specifiers Uwe Kleine-König
2010-02-08 9:09 ` [PATCH 2/3] gpiolib: a gpio is unsigned, so use %u to print it Uwe Kleine-König
2010-02-08 9:09 ` Uwe Kleine-König
2010-02-08 9:09 ` [PATCH 3/3] gpiolib: document that names can contain printk format specifiers Uwe Kleine-König
2010-02-08 9:09 ` Uwe Kleine-König
2010-02-08 9:16 ` Uwe Kleine-König
2010-02-08 9:16 ` Uwe Kleine-König
2010-01-28 1:43 ` [PATCH 07/13] ARM: LPC32XX: common architecture functions and structures wellsk40 at gmail.com
2010-02-03 16:01 ` Uwe Kleine-König
2010-01-28 1:43 ` [PATCH 08/13] ARM: LPC32XX: clock tree support wellsk40 at gmail.com
2010-01-28 17:07 ` Rabin Vincent
2010-01-28 19:51 ` Kevin Wells
2010-02-03 16:32 ` Uwe Kleine-König
2010-02-03 18:51 ` Kevin Wells
2010-02-03 20:20 ` Uwe Kleine-König
2010-02-05 16:48 ` Kevin Wells
2010-02-05 19:45 ` Russell King - ARM Linux
2010-01-28 1:43 ` [PATCH 09/13] ARM: LPC32XX: power and event management wellsk40 at gmail.com
2010-02-03 16:44 ` Uwe Kleine-König
2010-02-03 19:03 ` Kevin Wells
2010-01-28 1:43 ` [PATCH 10/13] ARM: LPC32XX: Phytec PHY3250 platform support file wellsk40 at gmail.com
2010-02-03 16:46 ` Uwe Kleine-König
2010-01-28 1:43 ` [PATCH 11/13] ARM: LPC32XX: printascii() output and irq support functions wellsk40 at gmail.com
2010-02-03 16:50 ` Uwe Kleine-König
2010-02-03 18:57 ` Kevin Wells
2010-02-03 20:49 ` Uwe Kleine-König
2010-01-28 1:43 ` [PATCH 12/13] ARM: LPC32XX: architecture header files wellsk40 at gmail.com
2010-02-03 17:07 ` Uwe Kleine-König
2010-02-03 19:20 ` Kevin Wells
2010-02-03 20:44 ` Uwe Kleine-König
2010-02-03 21:34 ` Russell King - ARM Linux
2010-02-03 22:06 ` Kevin Wells
2010-01-28 1:43 ` [PATCH 13/13] ARM: LPC32XX: Phytec PHY3250 default kernel config (ramdisk) wellsk40 at gmail.com
2010-01-28 11:16 ` LPC32XX architecture files (updated) Luotao Fu
2010-01-28 19:50 ` Kevin Wells
2010-01-28 19:06 ` Wolfram Sang
2010-01-28 19:58 ` Kevin Wells
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100204081744.GA5380@pengutronix.de \
--to=u.kleine-koenig@pengutronix.de \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.