All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hans de Goede <hdegoede@redhat.com>
To: Mika Westerberg <mika.westerberg@linux.intel.com>,
	Dmitry Torokhov <dtor@chromium.org>
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>,
	Enrico Granata <egranata@google.com>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Enric Balletbo i Serra <enric.balletbo@collabora.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Gwendal Grignou <gwendal@chromium.org>,
	ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
	Brian Norris <briannorris@chromium.org>,
	Enrico Granata <egranata@chromium.org>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Subject: Re: [PATCH] driver: platform: Add support for GpioInt() ACPI to platform_get_irq()
Date: Mon, 11 Feb 2019 16:42:55 +0100	[thread overview]
Message-ID: <daea3a4e-8cfb-8878-70ab-679da8432d12@redhat.com> (raw)
In-Reply-To: <20190211103024.GY7875@lahna.fi.intel.com>

Hi,

On 11-02-19 11:30, Mika Westerberg wrote:
> Hi,
> 
> On Thu, Feb 07, 2019 at 12:29:17PM -0800, Dmitry Torokhov wrote:
>>>
>>>> Do you have a suggestion as to how to write ACPI tables to avoid the issue?
>>>
>>> 1. Allocate new ID and use it (perhaps not the best path).
>>> 2. Use GPE(s).
>>>
>>
>> Or just solve the issue of intermixing Interrupt() with GpioInt(). We
>> have similar issue with i2c and spi, but we sidestep that there as we
>> only parse the first interrupt and do not give option of fetching 2nd,
>> 3rd, etc. Maybe we should only GpioInt parsing for the first interrupt
>> in platform_get_irq() as well for the first iteration and then see if
>> we need to improve it if we see devices with multiple interrupts.
> 
> I think it should be fine to intermix them or do what you suggest and
> start supporting index 0 for now and then maybe extend it in the future
> to cover more.

I think only support fallback to GpioInt for index 0 for now is probably
the best solution. A device could have both Interrupt and GpioInt resources,
as soon as that is the case then the meaning of index becomes ambiguous.

We are already seeing something similar with mixed use of GpioInt + Gpio
resources on some devices, where we need the GpioInt for the IRQ and
the Gpio resource to toggle something else and the ACPI tables on
different devices have them in a different order, see:
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git/commit/?id=4d1f7a6eabd45639d9de22a8a004f3c208d13c1a

I suspect that on Windows device drivers specifically specify if they want a
Gpio or a GpioInt; or in this case if they want an Interrupt or a GpioInt.

Regards,

Hans

  reply	other threads:[~2019-02-11 15:42 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-07 18:59 [PATCH] driver: platform: Add support for GpioInt() ACPI to platform_get_irq() egranata
2019-02-07 19:02 ` Rafael J. Wysocki
2019-02-07 19:39   ` Andy Shevchenko
2019-02-07 19:45     ` Andy Shevchenko
2019-02-07 19:55     ` Enrico Granata
     [not found]     ` <CAPR809vnpuh8nOjU3QMCh6YJUKmtX92+bnHSUKGiAXAp6NwCHQ@mail.gmail.com>
2019-02-07 20:18       ` Andy Shevchenko
2019-02-07 20:29         ` Dmitry Torokhov
2019-02-11 10:30           ` Mika Westerberg
2019-02-11 15:42             ` Hans de Goede [this message]
2019-02-11 19:01 ` [PATCH v2] driver: platform: Support parsing GpioInt 0 in platform_get_irq() egranata
2019-02-11 19:25   ` Dmitry Torokhov
2019-02-12  7:29   ` Hans de Goede
2019-02-12  9:08   ` Mika Westerberg
2019-02-12  9:18   ` Rafael J. Wysocki
2019-02-12 12:46   ` Andy Shevchenko
2019-02-20 18:05   ` Brian Norris
2019-02-21 18:58     ` Enrico Granata
2019-02-21 19:34     ` [PATCH v3] " egranata
2019-02-22  9:03       ` Rafael J. Wysocki
2019-02-22 17:06         ` Brian Norris
2019-02-24 19:34   ` [PATCH v2] " Rafael J. Wysocki
  -- strict thread matches above, loose matches on Subject: below --
2019-02-07 18:50 [PATCH] driver: platform: Add support for GpioInt() ACPI to platform_get_irq() egranata
2019-02-07 18:57 ` Rafael J. Wysocki

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=daea3a4e-8cfb-8878-70ab-679da8432d12@redhat.com \
    --to=hdegoede@redhat.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=briannorris@chromium.org \
    --cc=dtor@chromium.org \
    --cc=egranata@chromium.org \
    --cc=egranata@google.com \
    --cc=enric.balletbo@collabora.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=gwendal@chromium.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mika.westerberg@linux.intel.com \
    --cc=rafael@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.