Hi Daniel,
On 15/12/19 21:27, Daniel Mack wrote:
Hi,
Thanks for the review!
On 12/12/2019 5:33 pm, Wolfram Sang wrote:
Hi Luca,
thanks for the review!
good, but I think there's a problem in this function. A "normal" master_xfer function issues a repeated start between one msg and the next one, at least in the typical case where all msgs have the same slave address. Your implementation breaks repeated start. At first sight we might need more complex code here to coalesce all consecutive msgs with the same address into a single i2c_transfer() call.
Note that it is by far the standard case that all messages in a transfer have the same client address (99,999%?). But technically, this is not a requirement and the repeated start on the bus is totally independent of the addresses used. It is just a master wanting to send without being interrupted by another master.
I'm not quite sure I understand.
Let's assume the following setup. An i2c client (some driver code) is sending a list of messages to the a2b xfer function, which in turn is logically connected to a 'real' i2c bus master that'll put the data on the wire.
The a2b code has to tell the 'master node' the final destination of the payload by programming registers on its primary i2c address, and then forwards the messages to its secondary i2c address. The layout of the messages don't change, and neither do the flags; i2c messages are being sent as i2c messages, except their addresses are changed, a bit like NAT in networking. That procedure is described on page 3-4 of the TRM, "Remote Peripheral I2C Accesses".
The 'real' i2c master that handles the hardware bus is responsible for adding start conditions, and as the messages as such are untouched, I believe it should do the right thing. The code in my xfer functions merely suppresses reprogramming remote addresses by remembering the last one that was used, but that is independent of the start conditions on the wire.
My concern is not about the start condition, it's about the *repeated* start condition.
The first question is whether the A2B chips can do it. What if the host processor sets a slave chip address and then issues two messages separated by a repeated start condition? Will the slave transceiver emit a repeated start condition too?
If the answer is "yes", then the issue moves to the driver code. A master xfer function receives a set of messages that are normally emitted with a repeated start between each other. But ad242x_i2c_xfer() splits the msgs and calls i2c_transfer_buffer_flags() with one msg at a time. i2c_transfer_buffer_flags() then will emit a stop condition.
This is not necessarily a problem, unless multi-master is used, but if there are limitations or deviations from the standard they should at least be well known and documented.