Re: Request for Clarification: old - legacy - new driver model

[Michael Lawnick <nospam_lawnick-Mmb7MZpHnFY@public.gmane.org>]

Jean Delvare said the following:
> 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.

Only 2 LM75 per MUX are shown above, but there will be 10+ in real ...
Don't ask - H/W engineers ...

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

I don't get the point here. The problem of correct identification will
have to be solved in any case.

> 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 would have to be done in kernel, doesn't it? I dislike such an
idea. Furthermore I raise the question of my previous posting again:
>>> 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.

> 
>> 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.
> 
What was meant is the auto instantiation of sub controllers.
I'm talking based on i2c-pca954x.c posted by Rodolfo Giometti on
01/28/09. I can't see an class attribute there. So how gets it
instantiated? Until now I assumed an automatic call of probe() for every
host controller.

>> 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? 

Dynamically add of new instances of already running devices to the I2C
system.

> What is wrong with auto instantiation
> as it is implemented today?
> 
The point of time when it is done (AFAICS);-)
As I previously said:
>>>> 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.
>>>> 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.
Until now I can see no way to initiate an additional instantiation of an
I2C driver without reloading the module.

So far I have seen, the new model assumes a static network of devices
that can be initialized on boot strap. Information for this is taken
from device tree or kernel configuration data.
What I need is a user space initiated additional registration of a device.

I have the typical S/W engineers problem: no H/W, no documentation, but
should design and implement a system that has to run out of the box when
first version of H/W arrives ;-)
Therefore I asked for links in the OP so I can understand the idea of
the so called 'new I2C model'. The kernel documentation seems not to be
sufficient to achieve my goals.
Currently I'm waiting for 2 MUXes and an LM75, so I can connect them to
our current MUX-less board and start to play.

-- 

Michael Lawnick
Software Design Engineer

Lise-Meitner-Str. 7/1
89081 Ulm
Tel: +49 731 9533 2066

Michael.Lawnick.ext-OYasijW0DpE@public.gmane.org
http://www.nokiasiemensnetworks.com/global/

Think before you print