On 02-03-21, 14:24, Jie Deng wrote: > Not for the full duplex. As Paolo explained in those links. > We defined a combined request called "write-read request" > > " > This is when a write is followed by a read: the master > starts off the transmission with a write, then sends a second START, > then continues with a read from the same address. I think above talks about the real I2C protocol at bus level ? > In theory there's no difference between one multi-segment transaction > and many single-segment transactions _in a single-master scenario_. > > However, it is a plausible configuration to have multiple guests sharing > an I2C host device as if they were multiple master. > > So the spec should provide a way at least to support for transactions with > 1 write and 1 read segment in one request to the same address. > " > From the perspective of specification design, it hopes to provide more > choices > while from the perspective of specific implementation, we can choose what we > need > as long as it does not violate the specification. That is fine, but what I was not able to understand was how do we get to know if we should expect both write and read bufs after the out header or only one of them ? I think I have understood that part now, we need to look at incnt and outcnt and make out what kind of transfer we need to do. - If outcnt == 1 and incnt == 2, then it is read operation. - If outcnt == 2 and incnt == 1, then it is write operation. - If outcnt == 2 and incnt == 2, then it is read-write operation. Anything else is invalid. Is my understanding correct here ? > Since the current Linux driver doesn't use this mechanism. I'm considering > to move > the "struct virtio_i2c_req" into the driver and use one "buf" instead. Linux can very much have its own definition of the structure and so I am not in favor of any such structure in the spec as well, it confuses people (like me) :). -- viresh
