linux-gpio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Graeme Gregory <graeme.gregory@linaro.org>,
	Marc Zyngier <marc.zyngier@arm.com>,
	"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
	Masahisa Kojima <masahisa.kojima@linaro.org>,
	Mika Westerberg <mika.westerberg@linux.intel.com>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [RFC PATCH 3/3] gpio: mb86s70: enable ACPI and irqchip support
Date: Thu, 25 Apr 2019 15:35:45 +0200	[thread overview]
Message-ID: <CAKv+Gu9+NqrtOrdkxcwPz63EW9gGnHLADTR9K2EPRsm0nHOS4g@mail.gmail.com> (raw)
In-Reply-To: <CACRpkdacwYder5e0ik2T32heSBQhKvmbem8XMpUF0iShsw3D3w@mail.gmail.com>

On Thu, 25 Apr 2019 at 15:24, Linus Walleij <linus.walleij@linaro.org> wrote:
>
> Hi Ard, thanks for your patch!
>
> Including Mika here as well, he knows how ACPI is supposed to
> be wired up with GPIOs.
>
> On Thu, Apr 25, 2019 at 12:20 PM Ard Biesheuvel
> <ard.biesheuvel@linaro.org> wrote:
>
> > In order to support this GPIO block in combination with an EXIU
> > interrupt controller on ACPI systems such as Socionext SynQuacer,
> > add the enumeration boilerplate, and add the EXIU irqchip handling
> > to the probe path. Also, make the clock handling conditonal on
> > non-ACPI enumeration, since ACPI handles this internally.
> >
> > Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> (...)
>
> > +config GPIO_MB86S7X_ACPI
> > +       def_bool y
> > +       depends on ACPI && ARCH_SYNQUACER
>
> I would say
>
> depends on ACPI
> depends on (ARCH_SYNQUACER || COMPILE_TEST)
>
> so we get some compiler coverage.
>
> > +#include <linux/acpi.h>
> >  #include <linux/io.h>
> >  #include <linux/init.h>
> >  #include <linux/clk.h>
> > @@ -27,6 +28,8 @@
> >  #include <linux/spinlock.h>
> >  #include <linux/slab.h>
> >
> > +#include "gpiolib.h"
>
> Normally not a good sign to dereference gpiolib internals,
> but there are some few exceptions. Why do you do this?
>

I needed this for acpi_gpiochip_request_interrupts() et al

> > +int exiu_acpi_init(struct platform_device *pdev, struct gpio_chip *gc);
>
> Just merge it all into one file instead of having these crisscrossy calls.
> I prefer some minor #ifdef or straight C if (IS_ENABLED()) around
> specific code.
>

Fair enough, but please see below.

> > -       return ret;
> > +       if (mb86s70_gpio_have_acpi(pdev))
> > +               acpi_gpiochip_request_interrupts(&gchip->gc);
> > +
> > +       return 0;
>
> I guess this is right...
>
> >         struct mb86s70_gpio_chip *gchip = platform_get_drvdata(pdev);
> >
> > +       if (gchip->gc.irq.domain) {
> > +               acpi_gpiochip_free_interrupts(&gchip->gc);
> > +               irq_domain_remove(gchip->gc.irq.domain);
> > +       }
>
> Mika can possibly comment on the right way to do ACPI bring-up
> and take-down.
>
> Overall it looks pretty straightforward to me, but I'd prefer to just
> merge the irqchip driver over into the gpio driver, I can't see why
> not.
>
> Or is the irqchip used without the GPIO driver sometimes?
>

This is where it becomes a bit nasty: the GPIO controller and the EXIU
interrupt controller are two separate IP blocks, but they are
obviously complimentary. *However*, on SynQuacer, the first 4 physical
lines are not shared between the two, and so you could have 4
interrupt lines handled through the EXIU and 4 different GPIO lines
through the GPIO unit.

On DT, we don't care since we model them as two different units. On
ACPI, however, we cannot model interrupt controllers in the same way,
and so I decided to merge them.

Perhaps the solution is to model the EXIU as a pseudo-GPIO block that
only supports interrupts and not ordinary GPIO?

  reply	other threads:[~2019-04-25 13:35 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-25 10:20 [RFC PATCH 0/3] synquacer: implement ACPI gpio/interrupt support Ard Biesheuvel
2019-04-25 10:20 ` [RFC PATCH 1/3] irqchip/exiu: preparatory refactor for ACPI support Ard Biesheuvel
2019-04-25 10:20 ` [RFC PATCH 2/3] irqchip/exiu: implement ACPI gpiolib/irqchip support Ard Biesheuvel
2019-04-25 13:14   ` Linus Walleij
2019-04-25 15:33   ` Marc Zyngier
2019-04-26  8:24     ` Ard Biesheuvel
2019-04-26  8:44       ` Marc Zyngier
2019-04-26 11:45         ` Ard Biesheuvel
2019-04-26 22:27           ` Ard Biesheuvel
2019-04-29  9:09             ` Ard Biesheuvel
2019-04-29  9:35               ` Marc Zyngier
2019-04-25 10:20 ` [RFC PATCH 3/3] gpio: mb86s70: enable ACPI and irqchip support Ard Biesheuvel
2019-04-25 13:23   ` Linus Walleij
2019-04-25 13:35     ` Ard Biesheuvel [this message]
2019-04-25 14:27     ` Mika Westerberg
2019-04-26  8:19       ` Ard Biesheuvel
2019-04-26  9:15         ` Mika Westerberg

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=CAKv+Gu9+NqrtOrdkxcwPz63EW9gGnHLADTR9K2EPRsm0nHOS4g@mail.gmail.com \
    --to=ard.biesheuvel@linaro.org \
    --cc=graeme.gregory@linaro.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=marc.zyngier@arm.com \
    --cc=masahisa.kojima@linaro.org \
    --cc=mika.westerberg@linux.intel.com \
    /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).