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? The I2C core only rejects transfers that don't fit into the max_read/write_len and nothing more.
