Hi Geert,
Sorry to bother you!
qspi_transfer_in() does:
while (n > 0) {
len = qspi_set_receive_trigger(rspi, n);
// len will be <= n
I agree. This is len = min value of n and 32.
if (len == QSPI_BUFFER_SIZE) {
// receive blocks of len bytes
Yes, This is len == 32 bytes
...
} else {
// receive n (not len) bytes
This is always n == len ( This case, len or n is always < 32)
Because this is the last n bytes should be received.
ret = rspi_pio_transfer(rspi, NULL, rx, n);
//
if (ret < 0)
return ret;
// bogus write (which your patch removes: OK)
*rx++ = ret;
I agree. This code needs to be removed.
// here we should also return (see below why)
// (in qspi_transfer_out() we should "break")
}
// Either we received a block of len bytes
// or we received n bytes, and the below is wrong if len < n!
n -= len;
// If len was < n, n will be non-zero, and we will receive more
// bytes in the next iteration
I am sorry, I don't understand your opinion here also.
The following is my opinion:
In case of receiving n bytes data > 32 bytes (Ex: n= 50bytes)
The first loop, n= 50,and len = 32 bytes by getting min value of 50 and
32 from qspi_set_receive_trigger()
(this case was n < len).
Then it receives 32 bytes in "if (len == QSPI_BUFFER_SIZE)" statement.
After received 32bytes of data, n -= len is implemented. It means n =(n
- len) = (50-32)= 18 bytes.
The first loop finished.
The second loop, n=18 bytes, and len = 18 bytes by getting min value of
32 and 18 from qspi_set_receive_trigger().
This time, 'else' statement would be implemented. *rx pointer was
increased into rspi_pio_transfer()
After received the last 18 bytes of data into 'else' statement, n -=len
was implemented again.
It means n = (n - len) = (18 -18) = 0 byte.
The second loop finished.
This time n = 0, Completed receiving data.
In case of receiving n bytes data < 32 bytes (Ex: n= 20 bytes).
It's the same with the second loop above.
Thank you.
Hiep.
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
