Frank Buss said:
The driver is working now! The problem was the initialization order: The I2C-GPIO driver was initialized before the Broadcom GPIO driver. I"ve changed the GPIO driver initialization order to arch_initcall, which should be the right moment, because the GPIO pins should be available before any other drivers are initialized. jbeale: currently I"m using the Linux bitbanging driver, I plan to implement a driver for the hardware module on the microcontroller on weekend.
The new .config file:
http://pastebin.com/cHDdMjXv
Next step will be to integrate the changes of .config in bcmrpi_cutdown_defconfig. A simple diff doesn"t work, because looks like the "menuconfig" changed the file a lot, any ideas? I"m not sure when I just set the new defines to Y, if all dependencies are followed.
Another problem is the reservation of the GPIO pins. Of course, on
http://elinux.org/RPi_Low-leve.....eripherals the pins are labeled as SDA0 and SCL0, but you could use it as general purpose IO pins (GPIO0 and GPIO1 for the GPIO driver). But when the I2C driver allocates the pins, you can"t use it anymore with the GPIO driver. Three ideas:
1. users who needs it as GPIO pins have to compile the kernel without the settings
2. compiled as a module, so it can be removed and added on runtime
3. not enabled in the kernel per default and users who needs I2C have to compile a new kernel with the settings
I would prefer 1, because it is the easiest way for most users, and you have enough other GPIOs. Powerusers who needs more pins could use a different kernel configuration.
Great to hear progress on I2C. I've asked a similar question about pin allocation for the SPI driver.
http://www.raspberrypi.org/for.....-3/#p73509
I suggested passing in config arguments at boot time which enable which drivers/pin configs are used. I think this is what beagleboards do -- in fact I think they probe the I2C bus at boot to decide.
I also started discussing pinctrl/pinmux from the kernel which deals with this sort of thing, and can be exposed to userspace through appropriate /sys/.... or somewhere in device tree.
Thoughts?