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. -- Luca _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
