linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
* w1-gpio oops
@ 2010-11-09 13:59 Alan Pearson
  2010-11-09 14:29 ` Hemanth V
  0 siblings, 1 reply; 8+ messages in thread
From: Alan Pearson @ 2010-11-09 13:59 UTC (permalink / raw)
  To: linux-arm-kernel

Hi Guys,

First post to list, so be kind :)

I'm trying to get w1 (one wire) working over GPIO and despite my best efforts this results in a nasty oops.
Firstly, I'd like to say I'm no kernel hacker and my knowledge of Ooops and kernel debugging is limited, but I'm willing to learn:)

I'm using Kernel.org kernel 2.6.36 (also tried 2.6.37-rc1) on a Marvell based 'GuruPlug server' device.
I'm using the GPIO pins that are on the U-SNAP interface, namely MPP38.

Having compiled and deployed the kernel to the device and verifying that I can control the GPIO pins OK from userspace using /sys, I then proceed to try and get w1 working on GPIO (after first unexporting the pin I want).

There's sparse info on this, and most wisdom tells me to use the w1-gpio-custom module for openWRT to set the pin number before loading the module, which I've done.

sheevaplug-debian:~# modprobe wire
sheevaplug-debian:~# modprobe w1_gpio_custom bus0=0,38,0
sheevaplug-debian:~# modprobe w1_gpio
Internal error: Oops - undefined instruction: 0 [#1] PREEMPT
last sysfs file: /sys/devices/virtual/mtd/mtd2/mtdblock2/range
Modules linked in: w1_gpio(+) w1_gpio_custom wire xt_tcpudp iptable_filter ip_tables x_tables ipv6 libertas_sdio libertas sata_mv mv_c]
CPU: 0    Not tainted  (2.6.37-rc1 #3)
PC is at 0xbf0d40d8
LR is at w1_gpio_probe+0x14c/0x194 [w1_gpio]
pc : [<bf0d40d8>]    lr : [<bf0da160>]    psr: a0000013
sp : deb6be98  ip : 00000000  fp : beca8984
r10: 00000040  r9 : deb6a000  r8 : bf0da040
r7 : deb27f00  r6 : 00000000  r5 : df2fd420  r4 : deb36b80
r3 : bf0d40d4  r2 : 00000000  r1 : deb6be64  r0 : 00000001
Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
Control: 0005397f  Table: 1eb44000  DAC: 00000015
Process modprobe (pid: 2813, stack limit = 0xdeb6a270)
Stack: (0xdeb6be98 to 0xdeb6c000)
be80:                                                       deb27f00 000022cc
bea0: deb6be90 deb27f08 deb27f08 bf0d7190 bf0d7190 c02895dc 00000060 c028b630
bec0: c028b61c c028a5ec 00000000 deb27f08 deb27f3c bf0d7190 00000000 c028a704
bee0: bf0d7190 c028a6a4 00000000 c0289d94 df8240b8 deb18570 bf0d7190 deb18780
bf00: c058d5f0 c02896f0 bf0d714f bf0d714f deb6bf10 bf0d7190 00000001 00024418
bf20: 00000000 c002fbe4 00000000 c028a9d8 bf0d717c 00000001 00024418 00000000
bf40: c002fbe4 c028ba1c bf0d71c8 bf0da000 00024418 c002f42c 00000000 00000001
bf60: bf0d71c8 00000000 00024418 bf0d71c8 00000000 00024418 000014ed c002fbe4
bf80: 00000000 c0077ba0 400c3000 000014ed 00024418 00009064 00000000 00008edc
bfa0: 00000080 c002fa60 00009064 00000000 400c3000 000014ed 00024418 000014ed
bfc0: 00009064 00000000 00008edc 00000080 00000000 00000000 40102000 beca8984
bfe0: 00000000 beca88fc 0000b6b0 402af0c4 60000010 400c3000 ffffefff fffffcff
[<bf0da160>] (w1_gpio_probe+0x14c/0x194 [w1_gpio]) from [<c028b630>] (platform_drv_probe+0x14/0x18)
[<c028b630>] (platform_drv_probe+0x14/0x18) from [<c028a5ec>] (driver_probe_device+0xb0/0x168)
[<c028a5ec>] (driver_probe_device+0xb0/0x168) from [<c028a704>] (__driver_attach+0x60/0x84)
[<c028a704>] (__driver_attach+0x60/0x84) from [<c0289d94>] (bus_for_each_dev+0x48/0x74)
[<c0289d94>] (bus_for_each_dev+0x48/0x74) from [<c02896f0>] (bus_add_driver+0x144/0x2c0)
[<c02896f0>] (bus_add_driver+0x144/0x2c0) from [<c028a9d8>] (driver_register+0xa8/0x138)
[<c028a9d8>] (driver_register+0xa8/0x138) from [<c028ba1c>] (platform_driver_probe+0x18/0x98)
[<c028ba1c>] (platform_driver_probe+0x18/0x98) from [<c002f42c>] (do_one_initcall+0xcc/0x1a8)
[<c002f42c>] (do_one_initcall+0xcc/0x1a8) from [<c0077ba0>] (sys_init_module+0x90/0x1a4)
[<c0077ba0>] (sys_init_module+0x90/0x1a4) from [<c002fa60>] (ret_fast_syscall+0x0/0x2c)
Code: debcffc0 debcd0f0 deb4e120 00000000 (deb92ca0) 


As I said, this doesn't mean a lot to me, and I'm not sure it's an ARM problem, but I don't have other hardware to test on.


Any help greatly appreciated.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* w1-gpio oops
  2010-11-09 13:59 w1-gpio oops Alan Pearson
@ 2010-11-09 14:29 ` Hemanth V
  2010-11-09 14:44   ` Alan Pearson
  0 siblings, 1 reply; 8+ messages in thread
From: Hemanth V @ 2010-11-09 14:29 UTC (permalink / raw)
  To: linux-arm-kernel

----- Original Message ----- 
From: "Alan Pearson" <alandpearson@gmail.com>
To: <linux-arm-kernel@lists.infradead.org>
Sent: Tuesday, November 09, 2010 7:29 PM
Subject: w1-gpio oops


> Hi Guys,
>
> First post to list, so be kind :)
>
> I'm trying to get w1 (one wire) working over GPIO and despite my best 
> efforts this results in a nasty oops.
> Firstly, I'd like to say I'm no kernel hacker and my knowledge of Ooops 
> and kernel debugging is limited, but I'm willing to learn:)

Common cause for these errors could be nonexistent or incorrect platform 
data. Might be worth checking if w1_gpio_platform_data
is proper in your board file. You could look for examples in other board 
files like arch/arm/mach-pxa/raumfeld.c

>
> I'm using Kernel.org kernel 2.6.36 (also tried 2.6.37-rc1) on a Marvell 
> based 'GuruPlug server' device.
> I'm using the GPIO pins that are on the U-SNAP interface, namely MPP38.
>
> Having compiled and deployed the kernel to the device and verifying that I 
> can control the GPIO pins OK from userspace using /sys, I then proceed to 
> try and get w1 working on GPIO (after first unexporting the pin I want).
>
> There's sparse info on this, and most wisdom tells me to use the 
> w1-gpio-custom module for openWRT to set the pin number before loading the 
> module, which I've done.
>
> sheevaplug-debian:~# modprobe wire
> sheevaplug-debian:~# modprobe w1_gpio_custom bus0=0,38,0
> sheevaplug-debian:~# modprobe w1_gpio
> Internal error: Oops - undefined instruction: 0 [#1] PREEMPT
> last sysfs file: /sys/devices/virtual/mtd/mtd2/mtdblock2/range
> Modules linked in: w1_gpio(+) w1_gpio_custom wire xt_tcpudp iptable_filter 
> ip_tables x_tables ipv6 libertas_sdio libertas sata_mv mv_c]
> CPU: 0    Not tainted  (2.6.37-rc1 #3)
> PC is at 0xbf0d40d8
> LR is at w1_gpio_probe+0x14c/0x194 [w1_gpio]
> pc : [<bf0d40d8>]    lr : [<bf0da160>]    psr: a0000013
> sp : deb6be98  ip : 00000000  fp : beca8984
> r10: 00000040  r9 : deb6a000  r8 : bf0da040
> r7 : deb27f00  r6 : 00000000  r5 : df2fd420  r4 : deb36b80
> r3 : bf0d40d4  r2 : 00000000  r1 : deb6be64  r0 : 00000001
> Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
> Control: 0005397f  Table: 1eb44000  DAC: 00000015
> Process modprobe (pid: 2813, stack limit = 0xdeb6a270)
> Stack: (0xdeb6be98 to 0xdeb6c000)
> be80:                                                       deb27f00 
> 000022cc
> bea0: deb6be90 deb27f08 deb27f08 bf0d7190 bf0d7190 c02895dc 00000060 
> c028b630
> bec0: c028b61c c028a5ec 00000000 deb27f08 deb27f3c bf0d7190 00000000 
> c028a704
> bee0: bf0d7190 c028a6a4 00000000 c0289d94 df8240b8 deb18570 bf0d7190 
> deb18780
> bf00: c058d5f0 c02896f0 bf0d714f bf0d714f deb6bf10 bf0d7190 00000001 
> 00024418
> bf20: 00000000 c002fbe4 00000000 c028a9d8 bf0d717c 00000001 00024418 
> 00000000
> bf40: c002fbe4 c028ba1c bf0d71c8 bf0da000 00024418 c002f42c 00000000 
> 00000001
> bf60: bf0d71c8 00000000 00024418 bf0d71c8 00000000 00024418 000014ed 
> c002fbe4
> bf80: 00000000 c0077ba0 400c3000 000014ed 00024418 00009064 00000000 
> 00008edc
> bfa0: 00000080 c002fa60 00009064 00000000 400c3000 000014ed 00024418 
> 000014ed
> bfc0: 00009064 00000000 00008edc 00000080 00000000 00000000 40102000 
> beca8984
> bfe0: 00000000 beca88fc 0000b6b0 402af0c4 60000010 400c3000 ffffefff 
> fffffcff
> [<bf0da160>] (w1_gpio_probe+0x14c/0x194 [w1_gpio]) from [<c028b630>] 
> (platform_drv_probe+0x14/0x18)
> [<c028b630>] (platform_drv_probe+0x14/0x18) from [<c028a5ec>] 
> (driver_probe_device+0xb0/0x168)
> [<c028a5ec>] (driver_probe_device+0xb0/0x168) from [<c028a704>] 
> (__driver_attach+0x60/0x84)
> [<c028a704>] (__driver_attach+0x60/0x84) from [<c0289d94>] 
> (bus_for_each_dev+0x48/0x74)
> [<c0289d94>] (bus_for_each_dev+0x48/0x74) from [<c02896f0>] 
> (bus_add_driver+0x144/0x2c0)
> [<c02896f0>] (bus_add_driver+0x144/0x2c0) from [<c028a9d8>] 
> (driver_register+0xa8/0x138)
> [<c028a9d8>] (driver_register+0xa8/0x138) from [<c028ba1c>] 
> (platform_driver_probe+0x18/0x98)
> [<c028ba1c>] (platform_driver_probe+0x18/0x98) from [<c002f42c>] 
> (do_one_initcall+0xcc/0x1a8)
> [<c002f42c>] (do_one_initcall+0xcc/0x1a8) from [<c0077ba0>] 
> (sys_init_module+0x90/0x1a4)
> [<c0077ba0>] (sys_init_module+0x90/0x1a4) from [<c002fa60>] 
> (ret_fast_syscall+0x0/0x2c)
> Code: debcffc0 debcd0f0 deb4e120 00000000 (deb92ca0)
>
>
> As I said, this doesn't mean a lot to me, and I'm not sure it's an ARM 
> problem, but I don't have other hardware to test on.
>
>
> Any help greatly appreciated.
>
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

^ permalink raw reply	[flat|nested] 8+ messages in thread

* w1-gpio oops
  2010-11-09 14:29 ` Hemanth V
@ 2010-11-09 14:44   ` Alan Pearson
  2010-11-09 14:53     ` Hemanth V
  0 siblings, 1 reply; 8+ messages in thread
From: Alan Pearson @ 2010-11-09 14:44 UTC (permalink / raw)
  To: linux-arm-kernel


On 9 Nov 2010, at 14:29, Hemanth V wrote:

> ----- Original Message ----- From: "Alan Pearson" <alandpearson@gmail.com>
> To: <linux-arm-kernel@lists.infradead.org>
> Sent: Tuesday, November 09, 2010 7:29 PM
> Subject: w1-gpio oops
> 
> 
>> Hi Guys,
>> 
>> First post to list, so be kind :)
>> 
>> I'm trying to get w1 (one wire) working over GPIO and despite my best efforts this results in a nasty oops.
>> Firstly, I'd like to say I'm no kernel hacker and my knowledge of Ooops and kernel debugging is limited, but I'm willing to learn:)
> 
> Common cause for these errors could be nonexistent or incorrect platform data. Might be worth checking if w1_gpio_platform_data
> is proper in your board file. You could look for examples in other board files like arch/arm/mach-pxa/raumfeld.c
> 

<CHOP>

Ok, I had understood the platform data was being set in the w1_gpio_custom module by the loadable options.
Is this not the case, or does it also need defined in the board file, which I presume is guruplug_setup.c ?
It's currently not defined there. But as I said I expected the other module to do this, am I wrong ?


Thanks again,
Alan

^ permalink raw reply	[flat|nested] 8+ messages in thread

* w1-gpio oops
  2010-11-09 14:44   ` Alan Pearson
@ 2010-11-09 14:53     ` Hemanth V
  2010-11-09 14:56       ` Alan Pearson
  2010-11-09 15:40       ` Alan Pearson
  0 siblings, 2 replies; 8+ messages in thread
From: Hemanth V @ 2010-11-09 14:53 UTC (permalink / raw)
  To: linux-arm-kernel

----- Original Message ----- 
From: "Alan Pearson" <alandpearson@gmail.com>
To: "Hemanth V" <hemanthv@ti.com>
Cc: <linux-arm-kernel@lists.infradead.org>
Sent: Tuesday, November 09, 2010 8:14 PM
Subject: Re: w1-gpio oops



On 9 Nov 2010, at 14:29, Hemanth V wrote:

> ----- Original Message ----- From: "Alan Pearson" <alandpearson@gmail.com>
> To: <linux-arm-kernel@lists.infradead.org>
> Sent: Tuesday, November 09, 2010 7:29 PM
> Subject: w1-gpio oops
>
>
>> Hi Guys,
>>
>> First post to list, so be kind :)
>>
>> I'm trying to get w1 (one wire) working over GPIO and despite my best 
>> efforts this results in a nasty oops.
>> Firstly, I'd like to say I'm no kernel hacker and my knowledge of Ooops 
>> and kernel debugging is limited, but I'm willing to learn:)
>
> Common cause for these errors could be nonexistent or incorrect platform 
> data. Might be worth checking if w1_gpio_platform_data
> is proper in your board file. You could look for examples in other board 
> files like arch/arm/mach-pxa/raumfeld.c
>

<CHOP>

Ok, I had understood the platform data was being set in the w1_gpio_custom 
module by the loadable options.
Is this not the case, or does it also need defined in the board file, which 
I presume is guruplug_setup.c ?
It's currently not defined there. But as I said I expected the other module 
to do this, am I wrong ?


Looking at the function w1_gpio_probe, it doesnot seem to be using module 
params. So u might need to define those
in your board file.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* w1-gpio oops
  2010-11-09 14:53     ` Hemanth V
@ 2010-11-09 14:56       ` Alan Pearson
  2010-11-09 15:40       ` Alan Pearson
  1 sibling, 0 replies; 8+ messages in thread
From: Alan Pearson @ 2010-11-09 14:56 UTC (permalink / raw)
  To: linux-arm-kernel

>> 
> 
> <CHOP>
> 
> Ok, I had understood the platform data was being set in the w1_gpio_custom module by the loadable options.
> Is this not the case, or does it also need defined in the board file, which I presume is guruplug_setup.c ?
> It's currently not defined there. But as I said I expected the other module to do this, am I wrong ?
> 
> 
> Looking at the function w1_gpio_probe, it doesnot seem to be using module params. So u might need to define those
> in your board file.
> 

But the w1_gpio_custom module does. Anyhow, I'm trying it out in the board file now.
I'll post back shortly.

Tnx
Alan

^ permalink raw reply	[flat|nested] 8+ messages in thread

* w1-gpio oops
  2010-11-09 14:53     ` Hemanth V
  2010-11-09 14:56       ` Alan Pearson
@ 2010-11-09 15:40       ` Alan Pearson
  2010-11-09 15:51         ` Arnaud Patard (Rtp)
  1 sibling, 1 reply; 8+ messages in thread
From: Alan Pearson @ 2010-11-09 15:40 UTC (permalink / raw)
  To: linux-arm-kernel

>> ----- Original Message ----- From: "Alan Pearson" <alandpearson@gmail.com>
>> To: <linux-arm-kernel@lists.infradead.org>
>> Sent: Tuesday, November 09, 2010 7:29 PM
>> Subject: w1-gpio oops
>> 
>> 
>>> Hi Guys,
>>> 
>>> First post to list, so be kind :)
>>> 
>>> I'm trying to get w1 (one wire) working over GPIO and despite my best efforts this results in a nasty oops.
>>> Firstly, I'd like to say I'm no kernel hacker and my knowledge of Ooops and kernel debugging is limited, but I'm willing to learn:)
>> 
>> Common cause for these errors could be nonexistent or incorrect platform data. Might be worth checking if w1_gpio_platform_data
>> is proper in your board file. You could look for examples in other board files like arch/arm/mach-pxa/raumfeld.c
>> 
> 
> <CHOP>
> 
> Ok, I had understood the platform data was being set in the w1_gpio_custom module by the loadable options.
> Is this not the case, or does it also need defined in the board file, which I presume is guruplug_setup.c ?
> It's currently not defined there. But as I said I expected the other module to do this, am I wrong ?
> 
> 
> Looking at the function w1_gpio_probe, it doesnot seem to be using module params. So u might need to define those
> in your board file.
> 

OK, I've modified my board file like so (guruplug-setup.c) :


static struct w1_gpio_platform_data guru_gpio_platform_data = {
        .pin                    = MPP38_GPIO,
        .is_open_drain          = 0,
};

struct platform_device guru_w1_gpio_device = {
        .name   = "w1-gpio",
        .id   = -1,
        .dev    = {
                .platform_data = &guru_gpio_platform_data
        }
};

static void __init guru_w1_init(void)
{

        platform_device_register(&guru_w1_gpio_device);
}



and called guru_w1_init from it's main init function.

Loading w1-gpio without the custom module produces :
FATAL: Error inserting w1_gpio (/lib/modules/2.6.37-rc1/kernel/drivers/w1/masters/w1-gpio.ko): No such device

And loading the w1_gpio_custom with the correct parameters produces the same oops.


So I think somehow I haven't correctly defined the platform data in my board file, and the w1_gpio_custom module allows me to specify this with parameters.
You can see w1-gpio-custom here :  https://dev.openwrt.org/browser/branches/8.09/package/w1-gpio-custom/src/w1-gpio-custom.c

So any clues as to what I've done wrong with the platform data, or does it not matter as w1-gpio-custom is doing this for me ?

Again,
Thanks

Alan

^ permalink raw reply	[flat|nested] 8+ messages in thread

* w1-gpio oops
  2010-11-09 15:40       ` Alan Pearson
@ 2010-11-09 15:51         ` Arnaud Patard (Rtp)
  2010-11-09 16:52           ` Alan Pearson
  0 siblings, 1 reply; 8+ messages in thread
From: Arnaud Patard (Rtp) @ 2010-11-09 15:51 UTC (permalink / raw)
  To: linux-arm-kernel

Alan Pearson <alandpearson@gmail.com> writes:

Hi,

>>> ----- Original Message ----- From: "Alan Pearson" <alandpearson@gmail.com>
>>> To: <linux-arm-kernel@lists.infradead.org>
>>> Sent: Tuesday, November 09, 2010 7:29 PM
>>> Subject: w1-gpio oops
>>> 
>>> 
>>>> Hi Guys,
>>>> 
>>>> First post to list, so be kind :)
>>>> 
>>>> I'm trying to get w1 (one wire) working over GPIO and despite my best efforts this results in a nasty oops.
>>>> Firstly, I'd like to say I'm no kernel hacker and my knowledge of Ooops and kernel debugging is limited, but I'm willing to learn:)
>>> 
>>> Common cause for these errors could be nonexistent or incorrect platform data. Might be worth checking if w1_gpio_platform_data
>>> is proper in your board file. You could look for examples in other board files like arch/arm/mach-pxa/raumfeld.c
>>> 
>> 
>> <CHOP>
>> 
>> Ok, I had understood the platform data was being set in the w1_gpio_custom module by the loadable options.
>> Is this not the case, or does it also need defined in the board file, which I presume is guruplug_setup.c ?
>> It's currently not defined there. But as I said I expected the other module to do this, am I wrong ?
>> 
>> 
>> Looking at the function w1_gpio_probe, it doesnot seem to be using module params. So u might need to define those
>> in your board file.
>> 
>
> OK, I've modified my board file like so (guruplug-setup.c) :
>
>
> static struct w1_gpio_platform_data guru_gpio_platform_data = {
>         .pin                    = MPP38_GPIO,

It's 38 not MPP38_GPIO. MPP38_GPIO is for the guruplug_mpp_config[]
stuff (looks at how the leds are configured for instance)


Arnaud

^ permalink raw reply	[flat|nested] 8+ messages in thread

* w1-gpio oops
  2010-11-09 15:51         ` Arnaud Patard (Rtp)
@ 2010-11-09 16:52           ` Alan Pearson
  0 siblings, 0 replies; 8+ messages in thread
From: Alan Pearson @ 2010-11-09 16:52 UTC (permalink / raw)
  To: linux-arm-kernel


>>> P. So u might need to define those
>>> in your board file.
>>> 
>> 
>> OK, I've modified my board file like so (guruplug-setup.c) :
>> 
>> 
>> static struct w1_gpio_platform_data guru_gpio_platform_data = {
>>        .pin                    = MPP38_GPIO,
> 
> It's 38 not MPP38_GPIO. MPP38_GPIO is for the guruplug_mpp_config[]
> stuff (looks at how the leds are configured for instance)
> 
> 
> Arnaud
> 
> 


Guys, thanks. I've now got the module loading and utilising the GPIO pin.
I know it is, because I cannot now grab the GPIO pin for normal GPIO as the w1_gpio driver has claimed ownership.

I can't get it to see my device yet, but I'll get that figured out soon I hope.

Many thanks for all your help, it is really appreciated here.

Alan

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2010-11-09 16:52 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-11-09 13:59 w1-gpio oops Alan Pearson
2010-11-09 14:29 ` Hemanth V
2010-11-09 14:44   ` Alan Pearson
2010-11-09 14:53     ` Hemanth V
2010-11-09 14:56       ` Alan Pearson
2010-11-09 15:40       ` Alan Pearson
2010-11-09 15:51         ` Arnaud Patard (Rtp)
2010-11-09 16:52           ` Alan Pearson

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).