From: grant.likely@secretlab.ca (Grant Likely)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] PINCTRL: SiRF: add CSR SiRFprimaII GPIO driver depending on pinmux APIs
Date: Fri, 25 May 2012 18:33:20 -0600 [thread overview]
Message-ID: <20120526003320.DCFE63E1BBF@localhost> (raw)
In-Reply-To: <CACRpkdZOTZaVp6rfuQvZaQyk0+zxeAjwHryBMYY-C1WVABaLLA@mail.gmail.com>
On Thu, 24 May 2012 16:48:25 +0200, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Tue, May 22, 2012 at 9:14 AM, Barry Song <Barry.Song@csr.com> wrote:
>
> > From: Barry Song <Baohua.Song@csr.com>
> >
> > In SiRFprimaII, Each GPIO pin can be configured as input or output
> > independently. If a GPIO is configured as input, it can also be
> > enabled as an interrupt source (either edge or level triggered).
> >
> > These pins must be either MUXed as GPIO or other function pads. So
> > this drivers depend on pinctrl_request_gpio() API pinctrl-sirf.c
> > implements.
> >
> > Signed-off-by: Yuping Luo <yuping.luo@csr.com>
> > Signed-off-by: Barry Song <Baohua.Song@csr.com>
>
> This is actually such a nice and clean cut that it can be put into
> drivers/gpio, it's just using pinctrl, not sharing code or hardware
> registers with it. (If I understand correctly.)
>
> Let's check with Grant how he wants these things.
If it is a gpio controller, then it really should be in drivers/gpio.
If it is a memory mapped gpio controller, then it really should use
gpio-generic.c
>
> > +#define SIRFSOC_GPIO_IRQ_START ?? ?? (SIRFSOC_INTENAL_IRQ_END + 1)
>
> This is spelled wrong (inteRnal) but where is that #define coming from
> anyway? And is this really used? I think this line can be simply deleted.
>
> > +static inline struct sirfsoc_gpio_bank *sirfsoc_irq_to_bank(unsigned int irq)
> > +{
> > + ?? ?? ?? return &sgpio_bank[(irq - SIRFSOC_GPIO_IRQ_START) / SIRFSOC_GPIO_BANK_SIZE];
> > +}
> > +
> > +static inline int sirfsoc_gpio_to_irq(struct gpio_chip *chip, unsigned offset)
> > +{
> > + ?? ?? ?? return SIRFSOC_GPIO_IRQ_START + (chip->base + offset);
> > +}
>
> Ick! Can you please use irqdomain for this?
Yes.
> > +static int sirfsoc_gpio_irq_type(struct irq_data *d, unsigned type)
> > +{
> > + ?? ?? ?? struct sirfsoc_gpio_bank *bank = sirfsoc_irq_to_bank(d->irq);
> > + ?? ?? ?? int idx = sirfsoc_irq_to_offset(d->irq);
> > + ?? ?? ?? u32 status, offset;
>
> "status" is a real bad name for this variable since you're not
> checking or changing any status by it. Use "val" or something.
>
> > + ?? ?? ?? unsigned long flags;
> > +
> > + ?? ?? ?? offset = SIRFSOC_GPIO_CTRL(bank->id, idx);
> > +
> > + ?? ?? ?? spin_lock_irqsave(&sgpio_lock, flags);
> > +
> > + ?? ?? ?? status = readl(bank->chip.regs + offset);
> > + ?? ?? ?? status &= ~SIRFSOC_GPIO_CTL_INTR_STS_MASK;
> > +
> > + ?? ?? ?? switch (type) {
> > + ?? ?? ?? case IRQ_TYPE_NONE:
> > + ?? ?? ?? ?? ?? ?? ?? break;
> > + ?? ?? ?? case IRQ_TYPE_EDGE_RISING:
> > + ?? ?? ?? ?? ?? ?? ?? status |= (SIRFSOC_GPIO_CTL_INTR_HIGH_MASK | SIRFSOC_GPIO_CTL_INTR_TYPE_MASK);
> > + ?? ?? ?? ?? ?? ?? ?? status &= ~SIRFSOC_GPIO_CTL_INTR_LOW_MASK;
> > + ?? ?? ?? ?? ?? ?? ?? break;
> > + ?? ?? ?? case IRQ_TYPE_EDGE_FALLING:
> > + ?? ?? ?? ?? ?? ?? ?? status &= ~SIRFSOC_GPIO_CTL_INTR_HIGH_MASK;
> > + ?? ?? ?? ?? ?? ?? ?? status |= (SIRFSOC_GPIO_CTL_INTR_LOW_MASK | SIRFSOC_GPIO_CTL_INTR_TYPE_MASK);
> > + ?? ?? ?? ?? ?? ?? ?? break;
> > + ?? ?? ?? case IRQ_TYPE_EDGE_BOTH:
> > + ?? ?? ?? ?? ?? ?? ?? status |=
> > + ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? (SIRFSOC_GPIO_CTL_INTR_HIGH_MASK | SIRFSOC_GPIO_CTL_INTR_LOW_MASK |
> > + ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??SIRFSOC_GPIO_CTL_INTR_TYPE_MASK);
> > + ?? ?? ?? ?? ?? ?? ?? break;
> > + ?? ?? ?? case IRQ_TYPE_LEVEL_LOW:
> > + ?? ?? ?? ?? ?? ?? ?? status &= ~(SIRFSOC_GPIO_CTL_INTR_HIGH_MASK | SIRFSOC_GPIO_CTL_INTR_TYPE_MASK);
> > + ?? ?? ?? ?? ?? ?? ?? status |= SIRFSOC_GPIO_CTL_INTR_LOW_MASK;
> > + ?? ?? ?? ?? ?? ?? ?? break;
> > + ?? ?? ?? case IRQ_TYPE_LEVEL_HIGH:
> > + ?? ?? ?? ?? ?? ?? ?? status |= SIRFSOC_GPIO_CTL_INTR_HIGH_MASK;
> > + ?? ?? ?? ?? ?? ?? ?? status &= ~(SIRFSOC_GPIO_CTL_INTR_LOW_MASK | SIRFSOC_GPIO_CTL_INTR_TYPE_MASK);
> > + ?? ?? ?? ?? ?? ?? ?? break;
> > + ?? ?? ?? }
> > +
> > + ?? ?? ?? writel(status, bank->chip.regs + offset);
> > +
> > + ?? ?? ?? spin_unlock_irqrestore(&sgpio_lock, flags);
> > +
> > + ?? ?? ?? return 0;
> > +}
> (...)
> > + ?? ?? ?? ?? ?? ?? ?? /*
> > + ?? ?? ?? ?? ?? ?? ?? ??* Here we must check whether the corresponding GPIO's interrupt
> > + ?? ?? ?? ?? ?? ?? ?? ??* has been enabled, otherwise just skip it
> > + ?? ?? ?? ?? ?? ?? ?? ??*/
> > + ?? ?? ?? ?? ?? ?? ?? if ((status & 0x1) && (ctrl & SIRFSOC_GPIO_CTL_INTR_EN_MASK)) {
> > + ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? pr_debug("%s: gpio id %d idx %d happens\n",
> > + ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? __func__, bank->id, idx);
> > + ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? irq =
> > + ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? (SIRFSOC_GPIO_IRQ_START +
> > + ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??(bank->id * SIRFSOC_GPIO_BANK_SIZE)) + idx;
>
> So this is where irqdomain makes things simpler.
>
> > + ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? generic_handle_irq(irq);
> > + ?? ?? ?? ?? ?? ?? ?? }
> > +
> > + ?? ?? ?? ?? ?? ?? ?? idx++;
> > + ?? ?? ?? ?? ?? ?? ?? status = status >> 1;
> > + ?? ?? ?? }
> > +}
>
> > +static inline void sirfsoc_gpio_set_output(struct sirfsoc_gpio_bank *bank, unsigned offset,
> > + ?? ?? ?? int value)
> > +{
> > + ?? ?? ?? u32 status;
>
> Again what does this has to do with any status...
>
> > +static void sirfsoc_gpio_set_value(struct gpio_chip *chip, unsigned offset,
> > + ?? ?? ?? int value)
> > +{
> > + ?? ?? ?? struct sirfsoc_gpio_bank *bank = sirfsoc_irqchip_to_bank(chip);
> > + ?? ?? ?? u32 status;
>
> Neither this.
>
> Apart from that it looks good.
>
> Yours,
> Linus Walleij
--
Grant Likely, B.Sc, P.Eng.
Secret Lab Technologies, Ltd.
next prev parent reply other threads:[~2012-05-26 0:33 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-22 7:14 [PATCH] PINCTRL: SiRF: add CSR SiRFprimaII GPIO driver depending on pinmux APIs Barry Song
2012-05-24 14:48 ` Linus Walleij
2012-05-26 0:33 ` Grant Likely [this message]
2012-05-28 15:03 ` Barry Song
2012-05-28 16:24 ` Linus Walleij
2012-05-29 0:20 ` Barry Song
2012-05-29 1:47 ` Linus Walleij
2012-06-10 13:16 ` Barry Song
2012-06-12 11:39 ` Linus Walleij
2012-06-12 11:43 ` Linus Walleij
2012-06-12 12:03 ` Barry Song
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=20120526003320.DCFE63E1BBF@localhost \
--to=grant.likely@secretlab.ca \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).