> 1. From I2C_AQ_COMB quirk it looks like if there are two messages in > single i2c_transfer api to i2c-core, it has to be repeated-start. > Is my understanding correct? Yes. > 2. On calling smbus api for word read (non process call), it calls i2c > transfer api with two messages (emulation on i2c case). Now if 1 is > true we end up in repeated start case. Yes, this is exactly how it is described in the SMBus Specification. > But this may not be expected by the i2c client. Quite the contrary, you usually run into more problems if you replace repeated start with STOP/START. For example, you could get interrupted by another master on the bus. But some clients also reset their state machine after STOP. What device are you talking about? Which device cannot handle repeated start? That would be interesting to know. > Basically how to know from the i2c host/core driver, if the client > wants to use Repeated start or not? The client driver knows what the client wants. > Why don't we have a way where i2c client driver can call the i2c core > api with flag to indicate whether to use repeated-start or not? > (similar to protocolparameter in smbus api - can be set as > I2C_SMBUS_PROC_CALL for process call) Because your client is not SMBus compatible, and you need work on I2C level then where you can describe your own transfers the way you want.
Attachment:
signature.asc
Description: PGP signature
