Hi,
On Mon, Jul 30, 2012 at 01:36:47PM -0700, Kevin Hilman wrote:
<little trimming>
> >>> The device tree data for acquiring the above GPIO interrupt line looks
> >>> like this.
> >>>
> >>> +++ linux-omap-storage/arch/arm/boot/dts/omap5-evm.dts 2012-07-30
> >>> 14:11:08.931694001 +0530
> >>> @@ -42,7 +42,8 @@
> >>> tsl2771@39 {
> >>> compatible = "taos,tsl2771";
> >>> reg = <0x39>;
> >>> + interrupt-parent = <&gpio5>;
> >>> + interrupts = <21>; /* gpio line 149 */
> >>> };
> >>> };
> >>>
> >>> Note: using "gpio_request_one" in the driver solves the issue.
> >>> Is using this api in the driver required?
> >>> Any pointer on the above crash?
> >>
> > Hi Tarun,
> >> Any user/client driver of GPIO is supposed to go through
> >> gpio_request() API so that module clock
> >> is enabled correctly. Overriding of APIs would put the power
> >> management state machine in jeopardy.
> >> --
> > I tried putting "pm_runtime_get_sync" in gpio_irq_type api where the kernel
> > is crashing and the crash is no longer observed. So indeed, its about
> > enabling clocks.
> >
> > One doubt: Can't we put runtime apis in "gpio_irq_type" and eliminate
> > the use of
> > "gpio_request_one"??
>
> No.
>
> You must use the GPIO requiest/free APIs to tell the GPIO core that
> the GPIO line is in use.
>
> Why do you want to avoid using gpio_request/gpio_free?
Then how do we differentiate from a driver perspective if e.g.
client->irq (for I2C client drivers) refers to a pin on a GPIO
controller or a real interrupt when running with DT ?
Having something like:
#interrupt-parent = &<gpio5>;
interrupts = <21>;
would already give me the correct IRQ number from the driver, now how do
we differentiate the interrupt parents ? There's no way to do that from
a driver perspective, so DT core has to either do it, or provide means
for drivers to detect it themselves.
--
balbi
Attachment:
signature.asc
Description: Digital signature
