Hi Dmitry
On 2020/04/10 0:10, Dmitry Osipenko wrote:
09.04.2020 09:25, Wang, Jiada пишет:
Hi Dmitry
On 2020/04/07 23:47, Dmitry Osipenko wrote:
07.04.2020 12:27, Wang, Jiada пишет:
..
Is this a software (firmware) limitation which varies from version to
version?
the timeout issue trying to be addressed in this patch is from software,
one of our board a Serializer/Deserializer bridge exists between the SoC
(imx6) and the Atmel touch controller.
imx6 i2c controller driver has a timeout value(100ms) for each i2c
transaction,
Large i2c read transaction failed to complete within this timeout value
and therefore imx6 i2c controller driver aborts the transaction
and returns failure.
Therefore this patch was created to split the large i2c transaction into
smaller chunks which can complete
within the timeout defined by i2c controller driver.
Isn't it possible to use the max_read/write_len of the generic struct
i2c_adapter_quirks for limiting the transfer size?
BTW, it looks like the i.MX I2C driver doesn't specify the
i2c_adapter_quirks, which probably needs to be fixed.
yes, i.MX I2C driver can specify i2c_adapter_quirks to limit the size be
transferred in one transaction.
But even in this case, mxt_process_messages_t44() fails when it tries to
transfer data count larger than max_read/write_len set in i.MX I2C
driver, which we would like to avoid.
IIUC, the transfer's limitation is a part of I2C controller hardware and
not the touch controller, so it should be wrong to describe that
limitation in the maxtouch's DT node.
I meant that we probably could set the data->mtu based on
i2c_client->adapter->quirks->max_read and then the DT property shouldn't
be needed, couldn't this be done?
Thanks, now I understand your point,
and yes, by this way, we can address the I2C controller limitation issue
by its own configuration.
I will replace this commit with your proposed solution
Thanks,
jiada
The I2C core only rejects transfers that don't fit into the
max_read/write_len and nothing more.
