Hi Quan,
When tested with ast2500, it is observed that there's always a
I2C_SLAVE_WRITE_REQUESTED comes first then other I2C_SLAVE_WRITE_RECEIVED's
follow for all transactions.
Yes, that's the design of the interface :)
In case slave is busy, the NAK will be asserted on the first occurrence of
I2C_SLAVE_WRITE_REQUESTED make host to stop the current transaction (host
later will retry with other transaction) until slave ready.
This behavior is expected as we want host to drop all transactions while
slave is busy on working on the response. That is why we choose to assert
NAK on the first I2C_SLAVE_WRITE_REQUESTED of the transaction instead of
I2C_SLAVE_WRITE_RECEIVED.
From Documentation/i2c/slave-interface.rst:
===
About ACK/NACK
--------------
It is good behaviour to always ACK the address phase, so the master knows if a
device is basically present or if it mysteriously disappeared. Using NACK to
state being busy is troublesome. SMBus demands to always ACK the address phase,
while the I2C specification is more loose on that. Most I2C controllers also
automatically ACK when detecting their slave addresses, so there is no option
to NACK them. For those reasons, this API does not support NACK in the address
phase.
===
So, the proper design is to NACK on the first received byte. All EEPROMs
do it this way when they are busy because of erasing a page.