From: Kevin Hickey <khickey@rmicorp.com>
To: Manuel Lauss <mano@roarinelk.homelinux.net>
Cc: linux-mips@linux-mips.org, ralf@linux-mips.org
Subject: Re: [PATCH v3 2/5] Alchemy: Au1300 new interrupt controller
Date: Thu, 09 Apr 2009 09:27:58 -0500 [thread overview]
Message-ID: <1239287278.5812.6.camel@kh-d820> (raw)
In-Reply-To: <20090409120715.1f53f12c@scarran.roarinelk.net>
On Thu, 2009-04-09 at 12:07 +0200, Manuel Lauss wrote:
> Hi Kevin!
>
> Some major nits:
>
> > --- /dev/null
> > +++ b/arch/mips/alchemy/common/gpio_int.c
> > +static struct irq_chip gpio_int_irq_type = {
> > + .name = "Au GPIO/INT",
> > + .ack = gpio_int_ack,
> > + .mask = gpio_int_mask,
> > + .unmask = gpio_int_unmask,
> > + .mask_ack = gpio_int_mask_ack
> > +void __init arch_init_irq(void)
> > +{
> [...]
> > + for (i = 0; i < nr_basic_irqs; ++i) {
> > + printk(KERN_DEBUG "Initializing IRQ %d\n",
> > + basic_irqs[i].number);
> > + set_pin_cfg(&basic_irqs[i]);
> > + if (basic_irqs[i].intcfg == LEVEL_LOW)
> > + set_irq_chip_and_handler_name(
> > + basic_irqs[i].number + GPINT_LINUX_IRQ_OFFSET,
> > + &gpio_int_irq_type,
> > + handle_level_irq,
> > + "lowlevel");
> > + else if (basic_irqs[i].intcfg == LEVEL_HIGH)
> > + set_irq_chip_and_handler_name(
> > + basic_irqs[i].number + GPINT_LINUX_IRQ_OFFSET,
> > + &gpio_int_irq_type,
> > + handle_level_irq,
> > + "highlevel");
> > + else if (basic_irqs[i].intcfg == FALLING)
> > + set_irq_chip_and_handler_name(
> > + basic_irqs[i].number + GPINT_LINUX_IRQ_OFFSET,
> > + &gpio_int_irq_type,
> > + handle_edge_irq,
> > + "fallingedge");
> > + else if (basic_irqs[i].intcfg == RISING)
> > + set_irq_chip_and_handler_name(
> > + basic_irqs[i].number + GPINT_LINUX_IRQ_OFFSET,
> > + &gpio_int_irq_type,
> > + handle_edge_irq,
> > + "risingedge");
> > + else if (basic_irqs[i].intcfg == ANY_CHANGE)
> > + set_irq_chip_and_handler_name(
> > + basic_irqs[i].number + GPINT_LINUX_IRQ_OFFSET,
> > + &gpio_int_irq_type,
> > + handle_edge_irq,
> > + "bothedge");
> > + else
> > + set_irq_chip(
> > + basic_irqs[i].number + GPINT_LINUX_IRQ_OFFSET,
> > + &gpio_int_irq_type);
> > + }
>
> Please please move this to a irq_chip.set_irq_type hook, and replace
> LEVEL_LOW and friends with linux' IRQ_TYPE_LEVEL_LOW... constants
> (So one can pass IRQ flags via platform resource information).
>
>
> > diff --git a/arch/mips/alchemy/devboards/cascade_irq.c b/arch/mips/alchemy/devboards/cascade_irq.c
> > + * The following must be declared/defined in an included file:
> > + * - volatile struct bcsr_regs (declared)
> > + * (which much include fields int_status, intset_mask, intclr_mask, intset,
> > + * and intclr)
> > + * - volatile struct bcsr_regs *const bcsr (defined)
> > + * - CASCADE_IRQ_MIN
> > + * - CASCADE_IRQ_MAX
> > + * - CASCADE_IRQ_TYPE_STRING
> > + * - CASCADE_IRQ (System IRQ to which the cascade is connected)
> > + */
> > +
> > +void __init board_init_irq(void);
> > +
> > +irqreturn_t cascade_handler(int irq, void *dev_id)
> > +{
> > + u16 int_status = au_ioread16(&db_bcsr->int_status);
> > + int irq_in_service;
> > +
> > + au_iowrite16(int_status, &db_bcsr->int_status);
> > + for ( ; int_status; int_status &= int_status - 1) {
> > + irq_in_service = CASCADE_IRQ_MIN + __ffs(int_status);
> > + db_set_hex((u8)(irq_in_service));
> > + do_IRQ(irq_in_service);
>
> generic_handle_irq() please,
>
>
> > +static unsigned int cascade_startup(unsigned int irq)
> > +{
> > + int retval = 0;
> > +
> > + mutex_lock(&cascade_use_count_mutex);
> > + ++cascade_use_count;
> > + if (cascade_use_count == 1)
> > + retval = request_irq(CASCADE_IRQ,
> > + &cascade_handler, 0, "Cascade",
> > + &cascade_handler);
>
> Use "set_irq_chained_handler" after registering the cascades and the
> startup/shutdown hooks can go away.
>
> Also, "cascade" is too generic, maybe call it "db1300cascade". The
> Db1200 too has a cascade but works slightly different (I even doubt it
> makes sense to place this code outside the directory. As it currently
> is, it's not generic enough to be usable by the Db1200/Pb1200; and
> the code is rather tiny anyway).
>
To address all of your comments, I wrote this code some time ago and
have not had time to digest some of the changes that have been posted to
the DB1200 interrupt code since then. I have every intention of finding
some time down the line to revisit this and merge it with the DB1200
cascade code. The controllers are very similar - in fact in my local
tree I am using this same code on both platforms.
In the interest of time and schedule, I was hoping to have this version
included in 2.6.30 so that I had something to build on for future
updates and something to release other driver and peripheral patches
against.
> (Off topic: why the 2-stage mask/unmask system [the 'enable' and
> 'mask' bits] I didn't make sense to me on the DB1200 either...)
>
I'm not really sure either but I can ask the folks responsible for the
CPLD. My guess is that it is just because traditionally interrupt
controllers have both enables and masks and that's how it was written.
>
> > +/*
> > + * Set the GPIO to the specified value. The value must be 0 or 1. Any other
> > + * value results in a no-op.
> > + *
> > + * This call will implicitly reconfigure the pin to be a GPIO if it is
> > + * configured as a device pin.
> > + */
> > +void set_gpio(u8 gpio, u8 value);
> > +
> > +/*
> > + * Get the value of any GPIO pin (including those controlled by devices).
> > + *
> > + * This will not change the pin configuration
> > + */
> > +u8 get_gpio(u8 gpio);
> > +
> > +#endif /* _GPIO_INT_H */
> > +
>
> no support for linux' GPIO framework?
Again, at the time I was unaware of any GPIO standards. I will probably
revise this to use gpiolib or whaterver down the line.
>
--
Kevin Hickey
Alchemy Solutions
RMI Corporation
khickey@rmicorp.com
P: 512.691.8044
next prev parent reply other threads:[~2009-04-09 14:28 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-08 23:36 [PATCH v3 0/5] Alchemy: Basic Au1300 and DB1300 support Kevin Hickey
2009-04-08 23:36 ` [PATCH v3 1/5] Alchemy: Initial Au1300 and DBAu1300 support Kevin Hickey
2009-04-08 23:36 ` [PATCH v3 2/5] Alchemy: Au1300 new interrupt controller Kevin Hickey
2009-04-08 23:36 ` [PATCH v3 3/5] Alchemy: Au1300/DB1300 UART support Kevin Hickey
2009-04-08 23:36 ` [PATCH v3 4/5] Alchemy: Au1300/DB1300 peripheral resource declarations Kevin Hickey
2009-04-08 23:36 ` [PATCH v3 5/5] Alchemy: Au1300: Add LCD framebuffer support Kevin Hickey
2009-04-09 10:07 ` [PATCH v3 2/5] Alchemy: Au1300 new interrupt controller Manuel Lauss
2009-04-09 10:07 ` Manuel Lauss
2009-04-09 14:27 ` Kevin Hickey [this message]
2009-04-09 15:15 ` Manuel Lauss
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=1239287278.5812.6.camel@kh-d820 \
--to=khickey@rmicorp.com \
--cc=linux-mips@linux-mips.org \
--cc=mano@roarinelk.homelinux.net \
--cc=ralf@linux-mips.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox