Hi Luca,
On 12/17/19 9:35 AM, Luca Ceresoli wrote:
On 15/12/19 21:27, Daniel Mack wrote:
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?
Ah, alright. Thanks for taking the time to explain. I'll have to do some
measurements with a hardware analyzer. Will revisit this then, and
either provide an implementation that handles such cases correctly, or a
comment to explain that the hardware can't do it.
Best regards,
Daniel
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
