On Thu, 19 Feb 2009 15:17:13 +0100, Michael Lawnick wrote: > Wolfram Sang said the following: > > Hi Michael, > > > >> Can someone give me explanations/links/msg ids? > > > > Documentation/i2c/upgrading-clients > > > After re-reading it, I have to state that this document doesn't answer > the questions behind my original ones (which I wanted to answer myself > by following helpful links): > From which kernel version on should the 'new-binding' model work? It started in kernel 2.6.22. But there were significant changes later in kernels 2.6.25 and 2.6.26. > How is attaching of a hot plugged i2c device achieved a) from kernel b) > from user space. The I2C bus doesn't support hot-plugging, so I am not sure what you mean? > For kernel space init I assume its a call to i2c_new_device(). Here I'm > wondering where I should get the adapter info from. Depends. i2c_new_device() is suitable for TV adapters for example. For embedded boards, you'd rather declare all I2C devices with i2c_register_board_info() and use fixed I2C bus numbers. > For user space I'm completely lost (ioctl on /dev/i2cx?). User-space access through i2c-dev is entirely unchanged. If you mean creating I2C devices from user-space, the interface for this doesn't exist yet. I have a simple one in mind, but I can never find the time to work on it :/ That being said, this can be worked around using the old I2C_CLIENT_INSMOD macros. These let you pass module parameters forcing clients at a specific address. > Our situation: main board is up and running, all drivers loaded. > Now an extension board will be plugged in. It is detected by > periodically polling via I2C for MUX. After detection the drivers e.g. This is totally unsupported. I2C isn't an hot-pluggable bus. (Not to mention that support for mux chips is currently missing, but at least this is being worked on and fixable.) > for temperature an MUX on the secondary board need to be attached to I2C > subsystem. Instances of both drivers are already running for local > devices, re-loading is only a bad option. You shouldn't have to reload any driver. > Do I really have to read and understand i2c-core.c and i2c-dev.c to find > out? i2c-dev most probably doesn't have anything to do with your problem. What you are missing, as far as I can see, is proper mux support. Rodolfo Giometti (Cc'd) is working on this, if you want to test his patches (which I still didn't have the time to look at, sadly.) -- Jean Delvare -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
