Hi Michael, On Tue, 24 Feb 2009 16:09:33 +0100, Michael Lawnick wrote: > Jean Delvare said the following: > > On Thu, 19 Feb 2009 15:17:13 +0100, Michael Lawnick wrote: > <snip> > >> 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. > > > <snip> > > > > 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.) > > > I have seen the patches, I am planning based on them. > > Well, thinking about it, I hope to have a solution. > Here is what a H/W might look like: > +-------+ +--------+ > | LM75 | | EEPROM | > +-------+ +--------+ > Mainboard | | > +------------+ | | > | controller |----------------+-----+-----+---.... > +------------+ | > | > | > +------+ > | | > ...>--------------------------| MUX1 |----------------------<... > +-----------------| |---------------+ > | +------+ | > | | > | | > ^ ^ > Plugin1 | Plugin2 | > +------+ +------+ > | | +-------+ | | +-------+ > +---| MUX2 |---| LM75 | +---| MUX3 |---| LM75 | > | | | +-------+ | | | +-------+ > | +------+ | +------+ > | | > | +-------+ | +-------+ > +---| LM75 | +---| LM75 | > | +-------+ | +-------+ > | | > | +--------+ | +--------+ > +---| EEPROM | +---| EEPROM | > | +--------+ | +--------+ > | | > I don't quite get the point of MUX2 and MUX3. > > The idea: when deferring the instantiation of the adapters of MUX1, > there should be something like a hot-plug event. > AFAIK, after adding an adapter via i2c_add_numbered_adapter(), the I2C > subsystem will probe for all currently known clients on this new bus. > Correct? > If so, this should cascade through the newly plugged in board. For I2C chip drivers which do device autodetection (lm75 and eeprom are amongst them but for example at24 is not) yes. For other drivers (say at24) there should be a board definition for the new i2c bus segment. This might be a little difficult to implement with the traditional i2c_register_board_info() due to the hotplug nature is not all plugins have the same set of I2C chips. But some custom code using i2c_new_device() should do. > This defer could be implemented by removing auto instantiation (module > parameter) Auto instantiation only happens if the bus driver asks for it (through an I2C_CLASS_* flag). If you don't want it, no need for a module parameter, simply don't set any class flag. > but adding a sysFs entry on MUX that does it on demand: > #start controller 5 > echo 5 > /sys/bus/i2c/devices/1-0020/startAdapter > #stop controller 5 > echo 5 > /sys/bus/i2c/devices/1-0020/stopAdapter > > Any contradictions? What are you trying to achieve? What is wrong with auto instantiation as it is implemented today? -- 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
