Hardware Environment: * WRAP.1E-1 (http://www.pcengines.ch/wrap.htm) * uses a AMD Geode SC1100 CPU with 2 ACCESS.bus ports Software Environment: * no udev and devfs, created the device-nodes by hand * all i2c stuff compiled into the kernel * the intigrated lm77 (on bus 2) works Problem Description: the scx200_i2c module failed to find the bus on 0x840 (message: 'probe failed' on startup), the second on 0x820 works but produces crap in /proc/ioports ('0820-0827 : z
I guess you mean scx200_acb and not scx200_i2c? Please try with a 2.6.17-rc1 or later kernel first. The scx200_acb driver got many fixes and improvements there.
>I guess you mean scx200_acb and not scx200_i2c? yes, sorry for that... >Please try with a 2.6.17-rc1 or later kernel first. The scx200_acb driver got many fixes and improvements there. I'll try that one now.
still the same with 2.6.17-rc2. I'm getting: <4>scx200_acb: probe failed <4>initcall at 0xc02dda7d: returned with error code -6 on bootup. This one in /proc/ioports: 0820-0827 : And ls /sys/bus/i2c/devices/ says: 0-0048 (it's my LM77)
Please attach your kernel configuration file.
Created attachment 7961 [details] 2.6.17-rc2
Created attachment 7962 [details] Fix the init return value With this patch, the bus at 0x820 should work better (e.g. entry in /proc/ioports should no more be garbage.)
Please enable "I2C Bus debugging messages" (under "I2C support"). You should have some debug messages when the driver fails for bus 0x840, please report them. You could unselect "I2C PCF 8584 interfaces", "I2C PCA 9564 interfaces" and maybe even "I2C bit-banging interfaces" (under "I2C Algorithms") for a slightly smaller kernel.
On second thought, attachement #7961 will probably not solve the /proc/ioports issue, the problem is different. I'll post another patch for that soon.
Created attachment 7963 [details] my /proc/kmsg i've to recompile scx200_acb to store the kmsg. The module was inserted right after startup.
Created attachment 7964 [details] Fix the init return value (v2) This version is more simple. Note that this is only needed for 2.6.17-rc1 and later kernels, scx200_acb in earlier kernels doesn't have that bug. This will fix the "can't allocate io 0x820-0x827" error you had in your log. You'll have to reboot once though.
Created attachment 7965 [details] Fix /proc/ioports garbage This one should let you have a real string in /proc/ioports instead of garbage for the bus at 0x820.
These two patches should fix the bugs you had in 2.6.17-rc2. The second bus doesn't seem to exist at 0x840 for you. You'll need to search the technical documentation for your board to find out the correct address. Addresses can be passed as parameters to the module: modprobe scx200_acb base=0x820,0x840
nice, the garbage is gone in /proc/ioports - good work! -static int base[MAX_DEVICES] = { 0x820, 0x840 }; +static int base[MAX_DEVICES] = { 0x810, 0x820, 0x840 }; Using address 0x810 works and i can access my i2c device on the first port too (i unplugged it and it was gone, used i2cdetect to check for it). so far thanks a lot for your help!
You shouldn't have to modify the code to adjust the port numbers. If you have scx200_acb built into your kernel, you can add the following to the boot loader command line: scx200_acb.base=0x810,0x820 If you have scx200_acb built as a module, you can add the following line to /etc/modprobe.conf: options scx200_acb base=0x810,0x820 At any rate, don't list 0x840 as we know you don't have a bus at this address. It would be nice if the driver could use the right addresses automatically for each board, but that's a different issue.
>scx200_acb.base=0x810,0x820 thanks, I'll use that one now. >It would be nice if the driver could use the right addresses automatically for each board, but that's a different issue. Maybe adding some submenus in the kernel configuration would be good, to set these addresses? I'm thinking of something like: #ifndef I2C_ACB_IOBASE #define I2C_ACB_IOBASE 0x820,0x840 #endif static int base[MAX_DEVICES] = { I2C_ACB_IOBASE }; Well, i would write another patch is desired.
The addresses may be automatically detectable: http://lists.lm-sensors.org/pipermail/lm-sensors/2006-April/016012.html If so that would be even better, of course.
Fixed in 2.6.17, 2.6.16.17 and 2.4.33-rc1.