Re: I2C slave mode for i2c-at91 driver

[Juergen Fitschen <me@jue.yt>]

Hi Wolfram,

>> 1) According to [1] the return value of the I2C_SLAVE_WRITE_RECEIVED 
>> event
>> determines whether the received byte shall be ACKed or NACKed. The 
>> problem
>> with the Atmel hardware is that it is not possible to manipulate the 
>> ACK bit
>> of the current byte in flight; it will be ACKed automatically. It is 
>> only
>> possible to (N)ACK the following byte(s) since some FIFO magic is 
>> going on
>> inside the hardware.
>
> So, it is not possible to NACK the last byte?

If you would like to receive 3 bytes from a remote master and the last 
byte shall be NACKed, the backend must have the following behaviour to 
be compatible with the SAMA5 MPUs:

                                  +-----+-+-----+-+-----+-+
   Data on wire:                  |BYTE1|A|BYTE2|A|BYTE3|N|
                                  +-----+-+-----+-+-----+-+
   I2C_SLAVE_WRITE_RECEIVED fired:        ^       ^       ^
   Event's return value:                  A       N       X  (X=don't 
care)

But if I understand the documentation correctly, the return value 
corresponds to the currently received byte and not the next byte. So the 
following backend behaviour is described by the docs:

                                  +-----+-+-----+-+-----+-+
   Data on wire:                  |BYTE1|A|BYTE2|A|BYTE3|N|
                                  +-----+-+-----+-+-----+-+
   I2C_SLAVE_WRITE_RECEIVED fired:      ^       ^       ^
   Event's return value:                A       A       N

Or am I wrong?


>> Do you think it is a valid approach to ignore the return value and 
>> always
>> ACK received bytes? Or would you rather set the behaviour for the 
>> following
>> bytes? That would delay the desired ACK bit by at least one byte.
>
> Tricky, since both options are really sub-optimal. I tend to think 
> that
> reporting the error a bit later is the slightly better option. Most
> client drivers will act on the fact that the whole transfer failed
> somehow. Where it fails is not so essential. We don't have proper 
> means
> to report the exact position of the failure currently anyhow.

I had a look into the i2c-designware driver sources. As far as I 
understand it also does not respect the return value of the 
I2C_SLAVE_WRITE_RECEIVED event. It just prints out debug messages if the 
received byte shall be ACKed.


>> How would you implement blocking master transactions while slave 
>> mode is
>> enabled? I would return EBUSY if master_xfer is called.
>
> The i2c-designware driver has the same problem. We decided to have
> seperate struct i2c_algorithms for master and slave. The core helper
> i2c_detect_slave_mode() can help you to determine which mode should 
> be
> used. The designware drive might give you some inspiration.

Thank you for the hint! This really helps.


Kind regards,
   Juergen