Re: i2c: slave support framework improvements

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



You are welcome.

In my implementation in PCA954x I did the following things that I would like to highlight:

1. handle slave register and store i2c_client data to the internal array
(length equal to number of channels). First obstacle – get the right offset in
the array (channel number). It's better to expose "chan_id" field from
i2c_mux_priv as a public function. I did a hack during init by writing down
first muxc->adapter's number ("nr" field store in private adap_off).

2. during handling of select_chan I'm trying to register new i2c dummy
device with newly selected slave addr corresponding to the channel
number (if it has a slave). This is the second problem – after I've registered
dummy device with some slave address, I'm not able to register slave
devices for other mux'ed busses with the same slave addr. In other words,
I have to populate all the slave devices (with the same slave addr)
right before I'm going to use the bus first time.

3. registering and/or unregister first (if applicable) slave device on the parent
bus adapter. This is the third obstacle. While the bus is already locked,
calling generic i2c_slave_{register,unregister} lead to the deadlock.
I did it directly via the reg_slave/unreg_slave calls of appropriate data structure.

Notes:
Slave works only with keeping channel selected while generic i2c-mux logic
is to deselect channel after each i2c transfers.

25.07.2016, 12:41, "Wolfram Sang" <wsa@xxxxxxxxxxxxx>:
>>  There is no way to switch mux and request to BMC #2. Logically, this shouldn't
>>  happen too.
>
> I see. I think I have the big picture now, thanks for the heads up.
>
> However, I am not sure what recommendations I can give to you. I'd start
> with adding reg_slave to the muxed adapters and then try to reconfigure
> the real adapter when the mux switches (I assume you did that already).
> But I don't have the bandwidth to dive into that and see what gory
> details come up. Maybe Peter Rosin has something to add, though?
--
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



[Index of Archives]     [Linux GPIO]     [Linux SPI]     [Linux Hardward Monitoring]     [LM Sensors]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux