Re: [GPIO] Crashed when not using
On Tue, Jul 31, 2012 at 6:26 PM, Poddar, Sourav sourav.pod...@ti.com wrote:
Hi Santosh,
On Tue, Jul 31, 2012 at 6:02 PM, Shilimkar, Santosh
santosh.shilim...@ti.com wrote:
On Tue, Jul 31, 2012 at 8:52 AM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Tue, Jul 31, 2012 at 10:23:16AM +0530, Poddar, Sourav wrote:
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.
Thanks for this confirmation.
Why do you want to avoid using gpio_request/gpio_free?
I was assuming that DT based gpio IRQ registration will automatically
take care of
the above APIs. But since that is not the case(as mentioned by
santosh), we need to use the
gpio_request/free apis.
Hang on for a while, let's try to get to the bottom of this debate first
;-)
We have a canonical way of passing IRQ numbers to drivers through DT and
that is the interrupts attribute. It shouldn't matter if that IRQ pin
is connected to a real IRQ line or through a GPIO controller. In both
cases we should use the interrupts attribute.
If DT core doesn't allocate the GPIO for us then how does this work:
(omap4-sdp.dts)
127 mcspi1 {
128 eth@0 {
129 compatible = ks8851;
130 spi-max-frequency = 2400;
131 reg = 0;
132 interrupt-parent = gpio2;
133 interrupts = 2; /* gpio line 34 */
134 vdd-supply = vdd_eth;
135 };
136 };
There's no gpio request on the driver:
$ git grep -e gpio_request drivers/net/ethernet/micrel/ks8851.c
$
Since Benoit was the one who added that to the dts file (commit
e7c64db9), I assume he tested his patch before posting, so again I ask -
How does that work and why doesn't this work for Sourav's tsl2771
controller ?
This is either a regression on drivers/of, or commit e7c64db9 is also
broken...
Benoit, do you know how should this work ?
I had a discussion with Benoit on this. In fact there is a way to actually
trigger the GPIO request.
132 interrupt-parent = gpio2;
133 interrupts = 2; /* gpio line 34 */
As above you can see, GPIO2 bank and 2nd line.
And then it will make use of gpio_irq chip properties
to probe the GPIO line.
Saurabh can try this out for his use case.
I am using the above properties only and seeing the issue.
There seeems to be an issue with the GPIO DT probing. The Ethernet
works because there is another GPIO line from BANK2 is probed and since
BANK2 shares the clock, you won't see any issue.
We are looking at fixing the issue. Will keep the thread posted.
Regards
Santosh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GPIO] Crashed when not using
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
signature.asc
Description: Digital signature
Re: [GPIO] Crashed when not using
Hi,
On Tue, Jul 31, 2012 at 10:23:16AM +0530, Poddar, Sourav wrote:
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.
Thanks for this confirmation.
Why do you want to avoid using gpio_request/gpio_free?
I was assuming that DT based gpio IRQ registration will automatically
take care of
the above APIs. But since that is not the case(as mentioned by
santosh), we need to use the
gpio_request/free apis.
Hang on for a while, let's try to get to the bottom of this debate first
;-)
We have a canonical way of passing IRQ numbers to drivers through DT and
that is the interrupts attribute. It shouldn't matter if that IRQ pin
is connected to a real IRQ line or through a GPIO controller. In both
cases we should use the interrupts attribute.
If DT core doesn't allocate the GPIO for us then how does this work:
(omap4-sdp.dts)
127 mcspi1 {
128 eth@0 {
129 compatible = ks8851;
130 spi-max-frequency = 2400;
131 reg = 0;
132 interrupt-parent = gpio2;
133 interrupts = 2; /* gpio line 34 */
134 vdd-supply = vdd_eth;
135 };
136 };
There's no gpio request on the driver:
$ git grep -e gpio_request drivers/net/ethernet/micrel/ks8851.c
$
Since Benoit was the one who added that to the dts file (commit
e7c64db9), I assume he tested his patch before posting, so again I ask -
How does that work and why doesn't this work for Sourav's tsl2771
controller ?
This is either a regression on drivers/of, or commit e7c64db9 is also
broken...
Benoit, do you know how should this work ?
--
balbi
signature.asc
Description: Digital signature
Re: [GPIO] Crashed when not using
On Tue, Jul 31, 2012 at 8:52 AM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Tue, Jul 31, 2012 at 10:23:16AM +0530, Poddar, Sourav wrote:
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.
Thanks for this confirmation.
Why do you want to avoid using gpio_request/gpio_free?
I was assuming that DT based gpio IRQ registration will automatically
take care of
the above APIs. But since that is not the case(as mentioned by
santosh), we need to use the
gpio_request/free apis.
Hang on for a while, let's try to get to the bottom of this debate first
;-)
We have a canonical way of passing IRQ numbers to drivers through DT and
that is the interrupts attribute. It shouldn't matter if that IRQ pin
is connected to a real IRQ line or through a GPIO controller. In both
cases we should use the interrupts attribute.
If DT core doesn't allocate the GPIO for us then how does this work:
(omap4-sdp.dts)
127 mcspi1 {
128 eth@0 {
129 compatible = ks8851;
130 spi-max-frequency = 2400;
131 reg = 0;
132 interrupt-parent = gpio2;
133 interrupts = 2; /* gpio line 34 */
134 vdd-supply = vdd_eth;
135 };
136 };
There's no gpio request on the driver:
$ git grep -e gpio_request drivers/net/ethernet/micrel/ks8851.c
$
Since Benoit was the one who added that to the dts file (commit
e7c64db9), I assume he tested his patch before posting, so again I ask -
How does that work and why doesn't this work for Sourav's tsl2771
controller ?
This is either a regression on drivers/of, or commit e7c64db9 is also
broken...
Benoit, do you know how should this work ?
I had a discussion with Benoit on this. In fact there is a way to actually
trigger the GPIO request.
132 interrupt-parent = gpio2;
133 interrupts = 2; /* gpio line 34 */
As above you can see, GPIO2 bank and 2nd line.
And then it will make use of gpio_irq chip properties
to probe the GPIO line.
Saurabh can try this out for his use case.
Regards
Santosh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GPIO] Crashed when not using
Hi Santosh,
On Tue, Jul 31, 2012 at 6:02 PM, Shilimkar, Santosh
santosh.shilim...@ti.com wrote:
On Tue, Jul 31, 2012 at 8:52 AM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Tue, Jul 31, 2012 at 10:23:16AM +0530, Poddar, Sourav wrote:
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.
Thanks for this confirmation.
Why do you want to avoid using gpio_request/gpio_free?
I was assuming that DT based gpio IRQ registration will automatically
take care of
the above APIs. But since that is not the case(as mentioned by
santosh), we need to use the
gpio_request/free apis.
Hang on for a while, let's try to get to the bottom of this debate first
;-)
We have a canonical way of passing IRQ numbers to drivers through DT and
that is the interrupts attribute. It shouldn't matter if that IRQ pin
is connected to a real IRQ line or through a GPIO controller. In both
cases we should use the interrupts attribute.
If DT core doesn't allocate the GPIO for us then how does this work:
(omap4-sdp.dts)
127 mcspi1 {
128 eth@0 {
129 compatible = ks8851;
130 spi-max-frequency = 2400;
131 reg = 0;
132 interrupt-parent = gpio2;
133 interrupts = 2; /* gpio line 34 */
134 vdd-supply = vdd_eth;
135 };
136 };
There's no gpio request on the driver:
$ git grep -e gpio_request drivers/net/ethernet/micrel/ks8851.c
$
Since Benoit was the one who added that to the dts file (commit
e7c64db9), I assume he tested his patch before posting, so again I ask -
How does that work and why doesn't this work for Sourav's tsl2771
controller ?
This is either a regression on drivers/of, or commit e7c64db9 is also
broken...
Benoit, do you know how should this work ?
I had a discussion with Benoit on this. In fact there is a way to actually
trigger the GPIO request.
132 interrupt-parent = gpio2;
133 interrupts = 2; /* gpio line 34 */
As above you can see, GPIO2 bank and 2nd line.
And then it will make use of gpio_irq chip properties
to probe the GPIO line.
Saurabh can try this out for his use case.
I am using the above properties only and seeing the issue.
~Sourav
Regards
Santosh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GPIO] Crashed when not using
Sourav, On Mon, Jul 30, 2012 at 2:13 PM, Poddar, Sourav sourav.pod...@ti.com wrote: Hi All, I tried using gpio as an interrupt line for my driver (drivers/staging/iio/light/tsl2x7x_core.c) for omap5. The interrupt line number was directly passed to the driver using device tree. But what I observed is the following crash.. [1.599273] mousedev: PS/2 mouse device common for all mice [1.607513] i2c /dev entries driver [1.613739] Driver for 1-wire Dallas network protocol. [1.622650] usbcore: registered new interface driver usbhid [1.628540] usbhid: USB HID core driver [1.633728] Unhandled fault: imprecise external abort (0x1406) at 0x [1.641113] Internal error: : 1406 [#1] SMP ARM [1.645874] Modules linked in: [1.649078] CPU: 0Not tainted (3.5.0-02045-g0b474d6-dirty #415) [1.655761] PC is at _set_gpio_triggering+0x44/0x264 [1.660980] LR is at gpio_irq_type+0xb8/0x160 [1.665527] pc : [c02dbb68]lr : [c02dc2dc]psr: 6093 [1.665527] sp : dc851df0 ip : c07a8f00 fp : [1.677581] r10: 0081 r9 : r8 : dc8ffc10 [1.683074] r7 : 2093 r6 : r5 : 0001 r4 : fa05b000 [1.689910] r3 : dc8ffc10 r2 : 0002 r1 : 0002 r0 : 0140 [1.696746] Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel [1.704528] Control: 10c53c7d Table: 8000406a DAC: 0017 [1.710540] Process swapper/0 (pid: 1, stack limit = 0xdc8502f8) [1.716857] Stack: (0xdc851df0 to 0xdc852000) [1.721405] 1de0: 0002 c0731280 dc8ffc6c 2093 [1.730010] 1e00: c02dc224 c0731280 dc8d4980 c07a8e50 0141 0002 c00a37b8 [1.738586] 1e20: 2002 c0731280 dc8d4980 0141 c07312d4 c07312b4 4013 c00a3d7c [1.747161] 1e40: 0141 c06728c0 c0090578 c247f000 c00a2d5c c0412258 0141 [1.755737] 1e60: c0731280 c0537818 dc8d4980 c00a3fe4 c07bf6a0 2002 c071bed8 c247f000 [1.764312] 1e80: dc9df000 0004 c07bf6a0 dc9df020 c247f3c0 c04ea344 c06728c0 c247f000 [1.772888] 1ea0: 09090578 c07bf6a0 dc9df004 dc9df000 c04ea194 0091 c071bed8 [1.781494] 1ec0: c06f89f4 c03e13c0 c03e1314 dc9df020 c0d1afd8 dc9df054 c07bf60c c03272ac [1.790069] 1ee0: dc9df020 c07bf60c dc9df054 0091 c03274c0 c07bf60c dc851f08 [1.798645] 1f00: c032742c c0325b10 dc8f26a8 dc9ef790 c07bf60c c07bcea8 c243d6c0 [1.807220] 1f20: c0326240 c0672958 c02bce08 c07bf5e4 c07bf60c c03e12a0 [1.815795] 1f40: 0091 c071bed8 c06f89f4 c0327ab0 c07bf5e4 0007 c07c8c40 [1.824401] 1f60: 0091 c03e1738 dc85 0007 c0008648 c112c9f0 [1.832977] 1f80: c06a6d58 c06f89f4 0001 6013 c06694c8 0006 0006 [1.841552] 1fa0: 6013 c0700a20 0007 c07c8c40 c06d020c 0091 c071bed8 c0700a28 [1.850128] 1fc0: c06d0380 0006 0006 c06d020c c06d028c [1.858703] 1fe0: c001548c 0013 c001548c 3f3f3f3f 3f3f3f3f [1.867309] [c02dbb68] (_set_gpio_triggering+0x44/0x264) from [c02dc224] (gpio_irq_type+0x0/0x160) [1.877075] [c02dc224] (gpio_irq_type+0x0/0x160) from [2002] (0x2002) [1.884552] Code: e3120008 11816006 01c66001 e7846000 (e593c0fc) [1.890960] [ cut here ] [1.895812] WARNING: at arch/arm/mach-omap2/omap_l3_noc.c:113 l3_interrupt_handler+0x184/0x1bc() [1.905029] L3 custom error: MASTER:MPU TARGET:L4 PER2 [1.910430] Modules linked in: [1.913635] [c001bd5c] (unwind_backtrace+0x0/0xf4) from [c00414c4] (warn_slowpath_common+0x4c/0x64) [1.923492] [c00414c4] (warn_slowpath_common+0x4c/0x64) from [c0041570] (warn_slowpath_fmt+0x30/0x40) [1.933563] [c0041570] (warn_slowpath_fmt+0x30/0x40) from [c0035de4] (l3_interrupt_handler+0x184/0x1bc) [1.943786] [c0035de4] (l3_interrupt_handler+0x184/0x1bc) from [c00a28b8] (handle_irq_event_percpu+0x64/0x24c) [1.954650] [c00a28b8] (handle_irq_event_percpu+0x64/0x24c) from [c00a2adc] (handle_irq_event+0x3c/0x5c) [1.964965] [c00a2adc] (handle_irq_event+0x3c/0x5c) from [c00a56a8] (handle_fasteoi_irq+0x98/0x13c) [1.974822] [c00a56a8] (handle_fasteoi_irq+0x98/0x13c) from [c00a235c] (generic_handle_irq+0x34/0x44) [1.984863] [c00a235c] (generic_handle_irq+0x34/0x44) from [c00153a0] (handle_IRQ+0x4c/0xac) [1.994110] [c00153a0] (handle_IRQ+0x4c/0xac) from [c0008480] (gic_handle_irq+0x2c/0x60) [2.002960] [c0008480] (gic_handle_irq+0x2c/0x60) from [c04f26e4] (__irq_svc+0x44/0x60) [2.011718] Exception stack(0xdc851c48 to 0xdc851c90) [2.017028] 1c40: c07a87a0 dc851c80 c0743f80 dc851da8 [2.025604] 1c60: 0001 0001 dc851cd7 c02dbb6a c02dbb6c dc851c90 [2.034179] 1c80:
Re: [GPIO] Crashed when not using
On Mon, Jul 30, 2012 at 3:04 PM, DebBarma, Tarun Kanti tarun.ka...@ti.com wrote: Sourav, On Mon, Jul 30, 2012 at 2:13 PM, Poddar, Sourav sourav.pod...@ti.com wrote: Hi All, I tried using gpio as an interrupt line for my driver (drivers/staging/iio/light/tsl2x7x_core.c) for omap5. The interrupt line number was directly passed to the driver using device tree. But what I observed is the following crash.. [1.599273] mousedev: PS/2 mouse device common for all mice [1.607513] i2c /dev entries driver [1.613739] Driver for 1-wire Dallas network protocol. [1.622650] usbcore: registered new interface driver usbhid [1.628540] usbhid: USB HID core driver [1.633728] Unhandled fault: imprecise external abort (0x1406) at 0x [1.641113] Internal error: : 1406 [#1] SMP ARM [1.645874] Modules linked in: [1.649078] CPU: 0Not tainted (3.5.0-02045-g0b474d6-dirty #415) [1.655761] PC is at _set_gpio_triggering+0x44/0x264 [1.660980] LR is at gpio_irq_type+0xb8/0x160 [1.665527] pc : [c02dbb68]lr : [c02dc2dc]psr: 6093 [1.665527] sp : dc851df0 ip : c07a8f00 fp : [1.677581] r10: 0081 r9 : r8 : dc8ffc10 [1.683074] r7 : 2093 r6 : r5 : 0001 r4 : fa05b000 [1.689910] r3 : dc8ffc10 r2 : 0002 r1 : 0002 r0 : 0140 [1.696746] Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel [1.704528] Control: 10c53c7d Table: 8000406a DAC: 0017 [1.710540] Process swapper/0 (pid: 1, stack limit = 0xdc8502f8) [1.716857] Stack: (0xdc851df0 to 0xdc852000) [1.721405] 1de0: 0002 c0731280 dc8ffc6c 2093 [1.730010] 1e00: c02dc224 c0731280 dc8d4980 c07a8e50 0141 0002 c00a37b8 [1.738586] 1e20: 2002 c0731280 dc8d4980 0141 c07312d4 c07312b4 4013 c00a3d7c [1.747161] 1e40: 0141 c06728c0 c0090578 c247f000 c00a2d5c c0412258 0141 [1.755737] 1e60: c0731280 c0537818 dc8d4980 c00a3fe4 c07bf6a0 2002 c071bed8 c247f000 [1.764312] 1e80: dc9df000 0004 c07bf6a0 dc9df020 c247f3c0 c04ea344 c06728c0 c247f000 [1.772888] 1ea0: 09090578 c07bf6a0 dc9df004 dc9df000 c04ea194 0091 c071bed8 [1.781494] 1ec0: c06f89f4 c03e13c0 c03e1314 dc9df020 c0d1afd8 dc9df054 c07bf60c c03272ac [1.790069] 1ee0: dc9df020 c07bf60c dc9df054 0091 c03274c0 c07bf60c dc851f08 [1.798645] 1f00: c032742c c0325b10 dc8f26a8 dc9ef790 c07bf60c c07bcea8 c243d6c0 [1.807220] 1f20: c0326240 c0672958 c02bce08 c07bf5e4 c07bf60c c03e12a0 [1.815795] 1f40: 0091 c071bed8 c06f89f4 c0327ab0 c07bf5e4 0007 c07c8c40 [1.824401] 1f60: 0091 c03e1738 dc85 0007 c0008648 c112c9f0 [1.832977] 1f80: c06a6d58 c06f89f4 0001 6013 c06694c8 0006 0006 [1.841552] 1fa0: 6013 c0700a20 0007 c07c8c40 c06d020c 0091 c071bed8 c0700a28 [1.850128] 1fc0: c06d0380 0006 0006 c06d020c c06d028c [1.858703] 1fe0: c001548c 0013 c001548c 3f3f3f3f 3f3f3f3f [1.867309] [c02dbb68] (_set_gpio_triggering+0x44/0x264) from [c02dc224] (gpio_irq_type+0x0/0x160) [1.877075] [c02dc224] (gpio_irq_type+0x0/0x160) from [2002] (0x2002) [1.884552] Code: e3120008 11816006 01c66001 e7846000 (e593c0fc) [1.890960] [ cut here ] [1.895812] WARNING: at arch/arm/mach-omap2/omap_l3_noc.c:113 l3_interrupt_handler+0x184/0x1bc() [1.905029] L3 custom error: MASTER:MPU TARGET:L4 PER2 [1.910430] Modules linked in: [1.913635] [c001bd5c] (unwind_backtrace+0x0/0xf4) from [c00414c4] (warn_slowpath_common+0x4c/0x64) [1.923492] [c00414c4] (warn_slowpath_common+0x4c/0x64) from [c0041570] (warn_slowpath_fmt+0x30/0x40) [1.933563] [c0041570] (warn_slowpath_fmt+0x30/0x40) from [c0035de4] (l3_interrupt_handler+0x184/0x1bc) [1.943786] [c0035de4] (l3_interrupt_handler+0x184/0x1bc) from [c00a28b8] (handle_irq_event_percpu+0x64/0x24c) [1.954650] [c00a28b8] (handle_irq_event_percpu+0x64/0x24c) from [c00a2adc] (handle_irq_event+0x3c/0x5c) [1.964965] [c00a2adc] (handle_irq_event+0x3c/0x5c) from [c00a56a8] (handle_fasteoi_irq+0x98/0x13c) [1.974822] [c00a56a8] (handle_fasteoi_irq+0x98/0x13c) from [c00a235c] (generic_handle_irq+0x34/0x44) [1.984863] [c00a235c] (generic_handle_irq+0x34/0x44) from [c00153a0] (handle_IRQ+0x4c/0xac) [1.994110] [c00153a0] (handle_IRQ+0x4c/0xac) from [c0008480] (gic_handle_irq+0x2c/0x60) [2.002960] [c0008480] (gic_handle_irq+0x2c/0x60) from [c04f26e4] (__irq_svc+0x44/0x60) [2.011718] Exception stack(0xdc851c48 to 0xdc851c90) [2.017028] 1c40: c07a87a0 dc851c80 c0743f80 dc851da8 [2.025604] 1c60: 0001
Re: [GPIO] Crashed when not using
Poddar, Sourav sourav.pod...@ti.com writes: On Mon, Jul 30, 2012 at 3:04 PM, DebBarma, Tarun Kanti tarun.ka...@ti.com wrote: Sourav, On Mon, Jul 30, 2012 at 2:13 PM, Poddar, Sourav sourav.pod...@ti.com wrote: Hi All, I tried using gpio as an interrupt line for my driver (drivers/staging/iio/light/tsl2x7x_core.c) for omap5. The interrupt line number was directly passed to the driver using device tree. But what I observed is the following crash.. [1.599273] mousedev: PS/2 mouse device common for all mice [1.607513] i2c /dev entries driver [1.613739] Driver for 1-wire Dallas network protocol. [1.622650] usbcore: registered new interface driver usbhid [1.628540] usbhid: USB HID core driver [1.633728] Unhandled fault: imprecise external abort (0x1406) at 0x [1.641113] Internal error: : 1406 [#1] SMP ARM [1.645874] Modules linked in: [1.649078] CPU: 0Not tainted (3.5.0-02045-g0b474d6-dirty #415) [1.655761] PC is at _set_gpio_triggering+0x44/0x264 [1.660980] LR is at gpio_irq_type+0xb8/0x160 [1.665527] pc : [c02dbb68]lr : [c02dc2dc]psr: 6093 [1.665527] sp : dc851df0 ip : c07a8f00 fp : [1.677581] r10: 0081 r9 : r8 : dc8ffc10 [1.683074] r7 : 2093 r6 : r5 : 0001 r4 : fa05b000 [1.689910] r3 : dc8ffc10 r2 : 0002 r1 : 0002 r0 : 0140 [1.696746] Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel [1.704528] Control: 10c53c7d Table: 8000406a DAC: 0017 [1.710540] Process swapper/0 (pid: 1, stack limit = 0xdc8502f8) [1.716857] Stack: (0xdc851df0 to 0xdc852000) [1.721405] 1de0: 0002 c0731280 dc8ffc6c 2093 [1.730010] 1e00: c02dc224 c0731280 dc8d4980 c07a8e50 0141 0002 c00a37b8 [1.738586] 1e20: 2002 c0731280 dc8d4980 0141 c07312d4 c07312b4 4013 c00a3d7c [1.747161] 1e40: 0141 c06728c0 c0090578 c247f000 c00a2d5c c0412258 0141 [1.755737] 1e60: c0731280 c0537818 dc8d4980 c00a3fe4 c07bf6a0 2002 c071bed8 c247f000 [1.764312] 1e80: dc9df000 0004 c07bf6a0 dc9df020 c247f3c0 c04ea344 c06728c0 c247f000 [1.772888] 1ea0: 09090578 c07bf6a0 dc9df004 dc9df000 c04ea194 0091 c071bed8 [1.781494] 1ec0: c06f89f4 c03e13c0 c03e1314 dc9df020 c0d1afd8 dc9df054 c07bf60c c03272ac [1.790069] 1ee0: dc9df020 c07bf60c dc9df054 0091 c03274c0 c07bf60c dc851f08 [1.798645] 1f00: c032742c c0325b10 dc8f26a8 dc9ef790 c07bf60c c07bcea8 c243d6c0 [1.807220] 1f20: c0326240 c0672958 c02bce08 c07bf5e4 c07bf60c c03e12a0 [1.815795] 1f40: 0091 c071bed8 c06f89f4 c0327ab0 c07bf5e4 0007 c07c8c40 [1.824401] 1f60: 0091 c03e1738 dc85 0007 c0008648 c112c9f0 [1.832977] 1f80: c06a6d58 c06f89f4 0001 6013 c06694c8 0006 0006 [1.841552] 1fa0: 6013 c0700a20 0007 c07c8c40 c06d020c 0091 c071bed8 c0700a28 [1.850128] 1fc0: c06d0380 0006 0006 c06d020c c06d028c [1.858703] 1fe0: c001548c 0013 c001548c 3f3f3f3f 3f3f3f3f [1.867309] [c02dbb68] (_set_gpio_triggering+0x44/0x264) from [c02dc224] (gpio_irq_type+0x0/0x160) [1.877075] [c02dc224] (gpio_irq_type+0x0/0x160) from [2002] (0x2002) [1.884552] Code: e3120008 11816006 01c66001 e7846000 (e593c0fc) [1.890960] [ cut here ] [1.895812] WARNING: at arch/arm/mach-omap2/omap_l3_noc.c:113 l3_interrupt_handler+0x184/0x1bc() [1.905029] L3 custom error: MASTER:MPU TARGET:L4 PER2 [1.910430] Modules linked in: [1.913635] [c001bd5c] (unwind_backtrace+0x0/0xf4) from [c00414c4] (warn_slowpath_common+0x4c/0x64) [1.923492] [c00414c4] (warn_slowpath_common+0x4c/0x64) from [c0041570] (warn_slowpath_fmt+0x30/0x40) [1.933563] [c0041570] (warn_slowpath_fmt+0x30/0x40) from [c0035de4] (l3_interrupt_handler+0x184/0x1bc) [1.943786] [c0035de4] (l3_interrupt_handler+0x184/0x1bc) from [c00a28b8] (handle_irq_event_percpu+0x64/0x24c) [1.954650] [c00a28b8] (handle_irq_event_percpu+0x64/0x24c) from [c00a2adc] (handle_irq_event+0x3c/0x5c) [1.964965] [c00a2adc] (handle_irq_event+0x3c/0x5c) from [c00a56a8] (handle_fasteoi_irq+0x98/0x13c) [1.974822] [c00a56a8] (handle_fasteoi_irq+0x98/0x13c) from [c00a235c] (generic_handle_irq+0x34/0x44) [1.984863] [c00a235c] (generic_handle_irq+0x34/0x44) from [c00153a0] (handle_IRQ+0x4c/0xac) [1.994110] [c00153a0] (handle_IRQ+0x4c/0xac) from [c0008480] (gic_handle_irq+0x2c/0x60) [2.002960] [c0008480] (gic_handle_irq+0x2c/0x60) from [c04f26e4] (__irq_svc+0x44/0x60) [2.011718] Exception stack(0xdc851c48 to 0xdc851c90) [2.017028] 1c40: c07a87a0 dc851c80 c0743f80
Re: [GPIO] Crashed when not using
On Mon, Jul 30, 2012 at 10:36 PM, Kevin Hilman khil...@ti.com wrote:
Poddar, Sourav sourav.pod...@ti.com writes:
On Mon, Jul 30, 2012 at 3:04 PM, DebBarma, Tarun Kanti
tarun.ka...@ti.com wrote:
Sourav,
On Mon, Jul 30, 2012 at 2:13 PM, Poddar, Sourav sourav.pod...@ti.com
wrote:
Hi All,
I tried using gpio as an interrupt line for my driver
(drivers/staging/iio/light/tsl2x7x_core.c) for omap5.
The interrupt line number was directly passed to the driver using
device tree. But what I observed
is the following crash..
[1.599273] mousedev: PS/2 mouse device common for all mice
[1.607513] i2c /dev entries driver
[1.613739] Driver for 1-wire Dallas network protocol.
[1.622650] usbcore: registered new interface driver usbhid
[1.628540] usbhid: USB HID core driver
[1.633728] Unhandled fault: imprecise external abort (0x1406) at
0x
[1.641113] Internal error: : 1406 [#1] SMP ARM
[1.645874] Modules linked in:
[1.649078] CPU: 0Not tainted (3.5.0-02045-g0b474d6-dirty
#415)
[1.655761] PC is at _set_gpio_triggering+0x44/0x264
[1.660980] LR is at gpio_irq_type+0xb8/0x160
[1.665527] pc : [c02dbb68]lr : [c02dc2dc]psr: 6093
[1.665527] sp : dc851df0 ip : c07a8f00 fp :
[1.677581] r10: 0081 r9 : r8 : dc8ffc10
[1.683074] r7 : 2093 r6 : r5 : 0001 r4 :
fa05b000
[1.689910] r3 : dc8ffc10 r2 : 0002 r1 : 0002 r0 :
0140
[1.696746] Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM
Segment kernel
[1.704528] Control: 10c53c7d Table: 8000406a DAC: 0017
[1.710540] Process swapper/0 (pid: 1, stack limit = 0xdc8502f8)
[1.716857] Stack: (0xdc851df0 to 0xdc852000)
[1.721405] 1de0: 0002
c0731280 dc8ffc6c 2093
[1.730010] 1e00: c02dc224 c0731280 dc8d4980 c07a8e50
0141 0002 c00a37b8
[1.738586] 1e20: 2002 c0731280 dc8d4980 0141 c07312d4
c07312b4 4013 c00a3d7c
[1.747161] 1e40: 0141 c06728c0 c0090578 c247f000
c00a2d5c c0412258 0141
[1.755737] 1e60: c0731280 c0537818 dc8d4980 c00a3fe4 c07bf6a0
2002 c071bed8 c247f000
[1.764312] 1e80: dc9df000 0004 c07bf6a0 dc9df020 c247f3c0
c04ea344 c06728c0 c247f000
[1.772888] 1ea0: 09090578 c07bf6a0 dc9df004 dc9df000
c04ea194 0091 c071bed8
[1.781494] 1ec0: c06f89f4 c03e13c0 c03e1314 dc9df020 c0d1afd8
dc9df054 c07bf60c c03272ac
[1.790069] 1ee0: dc9df020 c07bf60c dc9df054 0091
c03274c0 c07bf60c dc851f08
[1.798645] 1f00: c032742c c0325b10 dc8f26a8 dc9ef790
c07bf60c c07bcea8 c243d6c0
[1.807220] 1f20: c0326240 c0672958 c02bce08 c07bf5e4
c07bf60c c03e12a0
[1.815795] 1f40: 0091 c071bed8 c06f89f4 c0327ab0 c07bf5e4
0007 c07c8c40
[1.824401] 1f60: 0091 c03e1738 dc85 0007
c0008648 c112c9f0
[1.832977] 1f80: c06a6d58 c06f89f4 0001 6013 c06694c8
0006 0006
[1.841552] 1fa0: 6013 c0700a20 0007 c07c8c40 c06d020c
0091 c071bed8 c0700a28
[1.850128] 1fc0: c06d0380 0006 0006 c06d020c
c06d028c
[1.858703] 1fe0: c001548c 0013
c001548c 3f3f3f3f 3f3f3f3f
[1.867309] [c02dbb68] (_set_gpio_triggering+0x44/0x264) from
[c02dc224] (gpio_irq_type+0x0/0x160)
[1.877075] [c02dc224] (gpio_irq_type+0x0/0x160) from
[2002] (0x2002)
[1.884552] Code: e3120008 11816006 01c66001 e7846000 (e593c0fc)
[1.890960] [ cut here ]
[1.895812] WARNING: at arch/arm/mach-omap2/omap_l3_noc.c:113
l3_interrupt_handler+0x184/0x1bc()
[1.905029] L3 custom error: MASTER:MPU TARGET:L4 PER2
[1.910430] Modules linked in:
[1.913635] [c001bd5c] (unwind_backtrace+0x0/0xf4) from
[c00414c4] (warn_slowpath_common+0x4c/0x64)
[1.923492] [c00414c4] (warn_slowpath_common+0x4c/0x64) from
[c0041570] (warn_slowpath_fmt+0x30/0x40)
[1.933563] [c0041570] (warn_slowpath_fmt+0x30/0x40) from
[c0035de4] (l3_interrupt_handler+0x184/0x1bc)
[1.943786] [c0035de4] (l3_interrupt_handler+0x184/0x1bc) from
[c00a28b8] (handle_irq_event_percpu+0x64/0x24c)
[1.954650] [c00a28b8] (handle_irq_event_percpu+0x64/0x24c) from
[c00a2adc] (handle_irq_event+0x3c/0x5c)
[1.964965] [c00a2adc] (handle_irq_event+0x3c/0x5c) from
[c00a56a8] (handle_fasteoi_irq+0x98/0x13c)
[1.974822] [c00a56a8] (handle_fasteoi_irq+0x98/0x13c) from
[c00a235c] (generic_handle_irq+0x34/0x44)
[1.984863] [c00a235c] (generic_handle_irq+0x34/0x44) from
[c00153a0] (handle_IRQ+0x4c/0xac)
[1.994110] [c00153a0] (handle_IRQ+0x4c/0xac) from [c0008480]
(gic_handle_irq+0x2c/0x60)
[2.002960] [c0008480] (gic_handle_irq+0x2c/0x60) from
Re: [GPIO] Crashed when not using
Hi Kevin, On Tue, Jul 31, 2012 at 2:06 AM, Kevin Hilman khil...@ti.com wrote: Poddar, Sourav sourav.pod...@ti.com writes: On Mon, Jul 30, 2012 at 3:04 PM, DebBarma, Tarun Kanti tarun.ka...@ti.com wrote: Sourav, On Mon, Jul 30, 2012 at 2:13 PM, Poddar, Sourav sourav.pod...@ti.com wrote: Hi All, I tried using gpio as an interrupt line for my driver (drivers/staging/iio/light/tsl2x7x_core.c) for omap5. The interrupt line number was directly passed to the driver using device tree. But what I observed is the following crash.. [1.599273] mousedev: PS/2 mouse device common for all mice [1.607513] i2c /dev entries driver [1.613739] Driver for 1-wire Dallas network protocol. [1.622650] usbcore: registered new interface driver usbhid [1.628540] usbhid: USB HID core driver [1.633728] Unhandled fault: imprecise external abort (0x1406) at 0x [1.641113] Internal error: : 1406 [#1] SMP ARM [1.645874] Modules linked in: [1.649078] CPU: 0Not tainted (3.5.0-02045-g0b474d6-dirty #415) [1.655761] PC is at _set_gpio_triggering+0x44/0x264 [1.660980] LR is at gpio_irq_type+0xb8/0x160 [1.665527] pc : [c02dbb68]lr : [c02dc2dc]psr: 6093 [1.665527] sp : dc851df0 ip : c07a8f00 fp : [1.677581] r10: 0081 r9 : r8 : dc8ffc10 [1.683074] r7 : 2093 r6 : r5 : 0001 r4 : fa05b000 [1.689910] r3 : dc8ffc10 r2 : 0002 r1 : 0002 r0 : 0140 [1.696746] Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel [1.704528] Control: 10c53c7d Table: 8000406a DAC: 0017 [1.710540] Process swapper/0 (pid: 1, stack limit = 0xdc8502f8) [1.716857] Stack: (0xdc851df0 to 0xdc852000) [1.721405] 1de0: 0002 c0731280 dc8ffc6c 2093 [1.730010] 1e00: c02dc224 c0731280 dc8d4980 c07a8e50 0141 0002 c00a37b8 [1.738586] 1e20: 2002 c0731280 dc8d4980 0141 c07312d4 c07312b4 4013 c00a3d7c [1.747161] 1e40: 0141 c06728c0 c0090578 c247f000 c00a2d5c c0412258 0141 [1.755737] 1e60: c0731280 c0537818 dc8d4980 c00a3fe4 c07bf6a0 2002 c071bed8 c247f000 [1.764312] 1e80: dc9df000 0004 c07bf6a0 dc9df020 c247f3c0 c04ea344 c06728c0 c247f000 [1.772888] 1ea0: 09090578 c07bf6a0 dc9df004 dc9df000 c04ea194 0091 c071bed8 [1.781494] 1ec0: c06f89f4 c03e13c0 c03e1314 dc9df020 c0d1afd8 dc9df054 c07bf60c c03272ac [1.790069] 1ee0: dc9df020 c07bf60c dc9df054 0091 c03274c0 c07bf60c dc851f08 [1.798645] 1f00: c032742c c0325b10 dc8f26a8 dc9ef790 c07bf60c c07bcea8 c243d6c0 [1.807220] 1f20: c0326240 c0672958 c02bce08 c07bf5e4 c07bf60c c03e12a0 [1.815795] 1f40: 0091 c071bed8 c06f89f4 c0327ab0 c07bf5e4 0007 c07c8c40 [1.824401] 1f60: 0091 c03e1738 dc85 0007 c0008648 c112c9f0 [1.832977] 1f80: c06a6d58 c06f89f4 0001 6013 c06694c8 0006 0006 [1.841552] 1fa0: 6013 c0700a20 0007 c07c8c40 c06d020c 0091 c071bed8 c0700a28 [1.850128] 1fc0: c06d0380 0006 0006 c06d020c c06d028c [1.858703] 1fe0: c001548c 0013 c001548c 3f3f3f3f 3f3f3f3f [1.867309] [c02dbb68] (_set_gpio_triggering+0x44/0x264) from [c02dc224] (gpio_irq_type+0x0/0x160) [1.877075] [c02dc224] (gpio_irq_type+0x0/0x160) from [2002] (0x2002) [1.884552] Code: e3120008 11816006 01c66001 e7846000 (e593c0fc) [1.890960] [ cut here ] [1.895812] WARNING: at arch/arm/mach-omap2/omap_l3_noc.c:113 l3_interrupt_handler+0x184/0x1bc() [1.905029] L3 custom error: MASTER:MPU TARGET:L4 PER2 [1.910430] Modules linked in: [1.913635] [c001bd5c] (unwind_backtrace+0x0/0xf4) from [c00414c4] (warn_slowpath_common+0x4c/0x64) [1.923492] [c00414c4] (warn_slowpath_common+0x4c/0x64) from [c0041570] (warn_slowpath_fmt+0x30/0x40) [1.933563] [c0041570] (warn_slowpath_fmt+0x30/0x40) from [c0035de4] (l3_interrupt_handler+0x184/0x1bc) [1.943786] [c0035de4] (l3_interrupt_handler+0x184/0x1bc) from [c00a28b8] (handle_irq_event_percpu+0x64/0x24c) [1.954650] [c00a28b8] (handle_irq_event_percpu+0x64/0x24c) from [c00a2adc] (handle_irq_event+0x3c/0x5c) [1.964965] [c00a2adc] (handle_irq_event+0x3c/0x5c) from [c00a56a8] (handle_fasteoi_irq+0x98/0x13c) [1.974822] [c00a56a8] (handle_fasteoi_irq+0x98/0x13c) from [c00a235c] (generic_handle_irq+0x34/0x44) [1.984863] [c00a235c] (generic_handle_irq+0x34/0x44) from [c00153a0] (handle_IRQ+0x4c/0xac) [1.994110] [c00153a0] (handle_IRQ+0x4c/0xac) from [c0008480] (gic_handle_irq+0x2c/0x60) [2.002960] [c0008480] (gic_handle_irq+0x2c/0x60) from [c04f26e4] (__irq_svc+0x44/0x60) [2.011718] Exception stack(0xdc851c48 to 0xdc851c90) [
