All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mika Westerberg <mika.westerberg@linux.intel.com>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Linus Walleij <linus.walleij@linaro.org>,
	Bartosz Golaszewski <bgolaszewski@baylibre.com>,
	linux-gpio@vger.kernel.org, linux-acpi@vger.kernel.org
Subject: Re: [PATCH v1 5/5] gpio: pca953x: Override GpioInt() pin for Intel Galileo Gen 2
Date: Mon, 25 May 2020 16:47:48 +0300	[thread overview]
Message-ID: <20200525134748.GW247495@lahna.fi.intel.com> (raw)
In-Reply-To: <20200525130108.GU1634618@smile.fi.intel.com>

On Mon, May 25, 2020 at 04:01:08PM +0300, Andy Shevchenko wrote:
> On Mon, May 25, 2020 at 03:21:36PM +0300, Mika Westerberg wrote:
> > On Mon, May 25, 2020 at 02:35:51PM +0300, Andy Shevchenko wrote:
> > > On Mon, May 25, 2020 at 02:05:56PM +0300, Mika Westerberg wrote:
> > > > On Mon, May 25, 2020 at 01:13:35PM +0300, Andy Shevchenko wrote:
> > > > > Due to parsing of ACPI tables. I don't want to copy'n'paste 25% of
> > > > > gpiolib-acpi.c in here. I think provided solution is cleaner and (more)
> > > > > flexible in terms of maintenance.
> > > > 
> > > > Hmm, you seem to pass a hard-coded pin number (1) to the core that then
> > > > passes it back to the driver. Why you can't simple use that number here
> > > > directly? You don't need to parse anything. What I'm missing? :-)
> > > 
> > > Okay, so, AFAIU you are proposing something like this:
> > > 
> > > 1) find a GPIO controller by the ACPI path (somehow, I guess by finding a
> > >    handle followed by physical device behind it); 2) somehow to request a
> > >    pin from that device by number;
> > > 3) convert to IRQ and use.
> > > 
> > > Is it correct?
> > 
> > Well, no. In the first patch you do this:
> > 
> >   pin = lookup->info.quirks_data;
> > 
> > and this essentially becomes 1 so you know the pin number upfront in the
> > driver. Why not simply get GPIO number 1 in the driver and use it as an
> > interrupt? You know already that this particular board with the matching
> > DMI identifier always uses the this number anyway.
> 
> But GPIO (relative!) number is not enough. We need to understand more, i.e.:
> 1) from which GPIO controller it comes from (okay, for this particular platform I know it);
> 2) which expander does have this resource (they all have same ACPI HID).
> 
> So, second one means to count GpioInt() resources (I don't remember if we have
> helper for that, probably we can add one). For the first we need to get a GPIO
> controller something (gpiochip?) And this first one I have no idea how we can
> perform without talking to the core.
> 
> Basically, it may be done by reimplementing acpi_dev_gpio_irq_get(), followed
> by acpi_get_gpiod_by_index(), followed by acpi_gpio_resource_lookup(), followed
> by acpi_populate_gpio_lookup(), where at last this quirk should be applied.
> 
> It seems for me like an over duplicated solution.
> 
> I really don't understand how we can shortcut all these. What am I missing?

Why for example following would not work? If it is using global GPIO numbers
anyway.

static int pca953x_acpi_interrupt_get_irq(struct device *dev)
{
        struct gpio_desc *desc;                                                          
 
        desc = gpio_to_desc(1);
        if (!desc)
                return -ENODEV;

        return gpiod_to_irq(desc);
}

  reply	other threads:[~2020-05-25 13:47 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-20 21:19 [PATCH v1 1/5] gpiolib: acpi: Introduce opaque data field for quirks Andy Shevchenko
2020-05-20 21:19 ` [PATCH v1 2/5] gpiolib: acpi: Introduce a quirk to force GpioInt pin Andy Shevchenko
2020-05-20 21:19 ` [PATCH v1 3/5] gpio: pca953x: Drop unneeded ACPI_PTR() Andy Shevchenko
2020-05-25 17:58   ` Andy Shevchenko
2020-05-27 13:13     ` Bartosz Golaszewski
2020-05-27 13:38       ` Andy Shevchenko
2020-06-03 12:05       ` Linus Walleij
2020-05-20 21:19 ` [PATCH v1 4/5] gpio: pca935x: Allow IRQ support for driver built as a module Andy Shevchenko
2020-05-25  9:38   ` Bartosz Golaszewski
2020-05-25 10:09     ` Andy Shevchenko
2020-05-20 21:19 ` [PATCH v1 5/5] gpio: pca953x: Override GpioInt() pin for Intel Galileo Gen 2 Andy Shevchenko
2020-05-25  9:20   ` Mika Westerberg
2020-05-25  9:31     ` Andy Shevchenko
2020-05-25  9:45       ` Mika Westerberg
2020-05-25 10:13         ` Andy Shevchenko
2020-05-25 11:05           ` Mika Westerberg
2020-05-25 11:35             ` Andy Shevchenko
2020-05-25 12:01               ` Andy Shevchenko
2020-05-25 12:21               ` Mika Westerberg
2020-05-25 13:01                 ` Andy Shevchenko
2020-05-25 13:47                   ` Mika Westerberg [this message]
2020-05-25 14:34                     ` Andy Shevchenko

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=20200525134748.GW247495@lahna.fi.intel.com \
    --to=mika.westerberg@linux.intel.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=bgolaszewski@baylibre.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-gpio@vger.kernel.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.