On 2021/3/2 15:24, Viresh Kumar wrote:

On 02-03-21, 14:24, Jie Deng wrote:

quoted

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 ?

quoted

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 ?

Correct.  By checking the sequences of descriptor's R/W in the virtqueue,
You can know the type of request. A simple state machine can be used to
classify in this case.

O I  I   : read request.

O O I  : write request.

O O I I : read-write request.

But if only using the first two types like in this driver, the backend 
will be much easier to
implement since the request is fixed to 3 descriptors and we only need 
to check the second
descriptor to know the type.

quoted

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) :).