From: Lars-Peter Clausen <lars@metafoo.de>
To: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: Linus Walleij <linus.walleij@linaro.org>,
Robert Dolca <robert.dolca@gmail.com>,
Robert Dolca <robert.dolca@intel.com>,
"linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>,
Jonathan Cameron <jic23@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Hartmut Knaack <knaack.h@gmx.de>,
Peter Meerwald <pmeerw@pmeerw.net>,
Denis CIOCCA <denis.ciocca@st.com>,
"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
Alexandre Courbot <gnurou@gmail.com>
Subject: Re: [PATCH] IIO: Adds ACPI support for ST gyroscopes
Date: Tue, 24 Mar 2015 17:43:21 +0100 [thread overview]
Message-ID: <55119429.6070806@metafoo.de> (raw)
In-Reply-To: <20150324155515.GR1878@lahna.fi.intel.com>
On 03/24/2015 04:55 PM, Mika Westerberg wrote:
> On Tue, Mar 24, 2015 at 04:22:16PM +0100, Lars-Peter Clausen wrote:
>> Add Alexandre and linux-gpio to Cc.
>>
>> On 03/24/2015 04:06 PM, Mika Westerberg wrote:
>>> On Tue, Mar 24, 2015 at 02:57:49PM +0100, Linus Walleij wrote:
>>>> On Tue, Mar 24, 2015 at 2:38 PM, Lars-Peter Clausen <lars@metafoo.de> wrote:
>>>>> On 03/24/2015 02:26 PM, Robert Dolca wrote:
>>>>>> On Tue, Mar 24, 2015 at 2:17 PM, Lars-Peter Clausen <lars@metafoo.de>
>>>>>> wrote:
>>>>
>>>>>> In the ACPI description you specify one or more IRQ GPIO pins. In the
>>>>>> driver you request the GPIO pin using the index. In the ACPI 5.1
>>>>>> specification you can use named GPIOs instead of index.
>>>>>
>>>>>
>>>>> But is there a way to distinguish between IRQ GPIOs and non IRQ GPIOs? If it
>>>>> is clear that a certain GPIO is the IRQ for the device the I2C framework
>>>>> should take care of assigning the client->irq field, instead of doing it
>>>>> manually in each and every device driver.
>>>>
>>>> In the device tree case we have a mechanism where each
>>>> GPIO chip implements two API:s, one gpio_chip API and
>>>> one irqchip API.
>>>>
>>>> Then in the tree both the GPIO and IRQs can be assigned as
>>>> resources to clients, orthogonally. Usually this will only work
>>>> if there is a 1-to-1 correspondence between the GPIO lines
>>>> and available IRQ line triggers on the GPIO chip, but that is
>>>> indeed the most common. They will then usually also have
>>>> the same line offset numbers. In some odd cases I guess it
>>>> won't work this way.
>>>>
>>>> The I2C subsystem does this for the device tree case in
>>>> i2c_device_probe() like this:
>>>>
>>>> if (!client->irq && dev->of_node) {
>>>> int irq = of_irq_get(dev->of_node, 0);
>>>>
>>>> if (irq == -EPROBE_DEFER)
>>>> return irq;
>>>> if (irq < 0)
>>>> irq = 0;
>>>>
>>>> client->irq = irq;
>>>> }
>>>>
>>>> This is why the code does not contain any OF/DT
>>>> IRQ assignment code.
>>>>
>>>> However in the ACPI probe path I guess it doesn't
>>>> happen then?
>>>
>>> In ACPI we have two kind of GPIOs: GpioIo and GpioInt. The latter is
>>> used to describe GPIOs that can be used as interrupts.
>>>
>>> In order to translate a GpioInt to an interrupt number we would need to
>>> request the GPIO first here (in the I2C core), call gpiod_to_irq() to it
>>> and assign that to the client->irq.
>>
>> Maybe the API can be extended to support to translate a GPIO to a IRQ
>> without actually requesting the GPIO first.
>
> We still need to take care the the GPIO is properly requested and locked
> as IRQ. Otherwise something else (userspace for example) can mess this
> up.
>
>>>
>>> This has few problems that I have not yet figured out. Maybe someone
>>> here can suggest what to do:
>>>
>>> 1) Who is responsible in releasing the GPIO?
>>> 2) What if the driver wants to use that pin as a GPIO instead? The GPIO
>>> is already requested by the I2C core.
>>> 3) We may have multiple GpioInts for devices like GPIO button array.
>>> Which one we should pick, or should we let the driver to handle this
>>> separetely?
>>
>> Well, we have the same issue with devicetree already. I'd say use the first
>> IRQ for client->irq and ignore the other ones for now.
>
> For devices like the button array above doing that leaves the driver
> wondering where the heck is one of my GPIOs :-) Perhaps we could to
> automatic translation if we find out that there is only one GpioInt for
> this device.
Btw. in the ACPI case client->irq is already initialized by
acpi_dev_resource_interrupt() in the I2C core. Should the GpioInts just map
onto this API as well?
- Lars
next prev parent reply other threads:[~2015-03-24 16:43 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-23 13:40 [PATCH] IIO: Adds ACPI support for ST gyroscopes Robert Dolca
2015-03-23 13:40 ` [PATCH] IIO: Add support for L3GD20H gyroscope Robert Dolca
2015-03-24 10:29 ` Linus Walleij
2015-03-28 11:14 ` Jonathan Cameron
2015-03-23 15:18 ` [PATCH] IIO: Adds ACPI support for ST gyroscopes Mika Westerberg
2015-03-24 11:51 ` Daniel Baluta
2015-03-24 10:22 ` Linus Walleij
2015-03-24 10:37 ` Linus Walleij
2015-03-24 10:44 ` Linus Walleij
2015-03-24 12:17 ` Lars-Peter Clausen
2015-03-24 13:26 ` Robert Dolca
2015-03-24 13:38 ` Lars-Peter Clausen
2015-03-24 13:57 ` Linus Walleij
2015-03-24 15:06 ` Mika Westerberg
2015-03-24 15:22 ` Lars-Peter Clausen
2015-03-24 15:28 ` Daniel Baluta
2015-03-24 15:55 ` Mika Westerberg
2015-03-24 16:43 ` Lars-Peter Clausen [this message]
2015-03-24 16:55 ` Mika Westerberg
2015-03-25 8:44 ` Linus Walleij
2015-03-25 9:43 ` Mika Westerberg
2015-03-25 12:25 ` Mika Westerberg
2015-03-25 13:21 ` Mika Westerberg
2015-03-25 13:42 ` Robert Dolca
2015-03-25 18:05 ` sathyanarayanan kuppuswamy
2015-03-25 18:08 ` Lars-Peter Clausen
2015-03-25 21:12 ` Octavian Purdila
2015-03-26 10:06 ` Robert Dolca
2015-03-26 10:36 ` Mika Westerberg
2015-03-26 10:16 ` Mika Westerberg
2015-03-26 12:04 ` Octavian Purdila
2015-03-26 14:04 ` Mika Westerberg
2015-03-26 14:37 ` Octavian Purdila
2015-03-26 14:47 ` Mika Westerberg
2015-03-26 15:00 ` Octavian Purdila
2015-03-26 16:28 ` Octavian Purdila
2015-03-27 10:06 ` Mika Westerberg
2015-03-27 10:36 ` Linus Walleij
2015-03-30 9:52 ` Mika Westerberg
2015-03-30 12:55 ` Octavian Purdila
2015-03-30 13:33 ` Mika Westerberg
2015-03-30 13:52 ` Octavian Purdila
2015-03-30 14:18 ` Mika Westerberg
2015-04-07 9:35 ` Linus Walleij
2015-04-07 9:39 ` Lars-Peter Clausen
2015-03-26 18:32 ` Jonathan Cameron
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=55119429.6070806@metafoo.de \
--to=lars@metafoo.de \
--cc=denis.ciocca@st.com \
--cc=gnurou@gmail.com \
--cc=jic23@kernel.org \
--cc=knaack.h@gmx.de \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mika.westerberg@linux.intel.com \
--cc=pmeerw@pmeerw.net \
--cc=robert.dolca@gmail.com \
--cc=robert.dolca@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).