From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752721AbbCXPWU (ORCPT ); Tue, 24 Mar 2015 11:22:20 -0400 Received: from smtp-out-173.synserver.de ([212.40.185.173]:1083 "EHLO smtp-out-173.synserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752514AbbCXPWR (ORCPT ); Tue, 24 Mar 2015 11:22:17 -0400 X-SynServer-TrustedSrc: 1 X-SynServer-AuthUser: lars@metafoo.de X-SynServer-PPID: 13373 Message-ID: <55118128.10402@metafoo.de> Date: Tue, 24 Mar 2015 16:22:16 +0100 From: Lars-Peter Clausen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.5.0 MIME-Version: 1.0 To: Mika Westerberg , Linus Walleij CC: Robert Dolca , Robert Dolca , "linux-iio@vger.kernel.org" , Jonathan Cameron , "linux-kernel@vger.kernel.org" , Hartmut Knaack , Peter Meerwald , Denis CIOCCA , "linux-gpio@vger.kernel.org" , Alexandre Courbot Subject: Re: [PATCH] IIO: Adds ACPI support for ST gyroscopes References: <1427118025-4380-1-git-send-email-robert.dolca@intel.com> <551155C3.2030403@metafoo.de> <551168F0.1090901@metafoo.de> <20150324150630.GP1878@lahna.fi.intel.com> In-Reply-To: <20150324150630.GP1878@lahna.fi.intel.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 wrote: >>> On 03/24/2015 02:26 PM, Robert Dolca wrote: >>>> On Tue, Mar 24, 2015 at 2:17 PM, Lars-Peter Clausen >>>> 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. > > 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. > > I recently did similar change to drivers/hid/i2c-hid/i2c-hid.c and would > be happy if we can get this factored to some generic code. >