Messages in this thread | | | Subject | Re: [PATCH v10 43/55] dt-bindings: input: atmel: support to set max bytes transferred | From | "Wang, Jiada" <> | Date | Fri, 10 Apr 2020 15:53:38 +0900 |
| |
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. >
| |