Message ID | 20210302102158.10533-1-digetx@gmail.com |
---|---|
Headers | show |
Series | Support wakeup methods of Atmel maXTouch controllers | expand |
02.03.2021 13:21, Dmitry Osipenko пишет: > Some Atmel maXTouch controllers, like mXT1386 and mXT3432S1 for example, > have a WAKE line that needs to be asserted in order to wake controller > from a deep sleep, otherwise it will be unusable. This series implements > support for the wakeup methods in accordance to the mXT1386 datasheet [1], > see page 29 (chapter "5.8 WAKE Line"). > > The mXT1386 is a widely used controller found on many older Android tablet > devices. Touchscreen on Acer A500 tablet now works properly after this > series. > > This patchset is a continuation of the work originally started by > Jiada Wang [2]. > > [1] https://ww1.microchip.com/downloads/en/DeviceDoc/mXT1386_1vx_Datasheet_LX.pdf > [2] https://patchwork.kernel.org/project/linux-input/list/?series=357875 Hi, This series is very wanted by Android tablet devices from Acer, Asus and other vendors which use Maxtouch 1386 controller. Touchscreens don't work without the wakeup support, i.e. without this series. The wakeup support is implemented in accordance to the datasheet and touchscreens are working excellent using these patches. Could you please take this series into v5.13? Or could you please let me know what exactly needs to be improved? Thanks in advance.
On Tue, Mar 02, 2021 at 01:21:57PM +0300, Dmitry Osipenko wrote: > According to datasheets, chips like mXT1386 have a WAKE line, it is used > to wake the chip up from deep sleep mode before communicating with it via > the I2C-compatible interface. > > If the WAKE line is connected to a GPIO line, the line must be asserted > 25 ms before the host attempts to communicate with the controller. If the > WAKE line is connected to the SCL pin, the controller will send a NACK on > the first attempt to address it, the host must then retry 25 ms later. > > Implement the wake-up methods in the driver. Touchscreen now works > properly on devices like Acer A500 tablet, fixing problems like this: > > atmel_mxt_ts 0-004c: __mxt_read_reg: i2c transfer failed (-121) > atmel_mxt_ts 0-004c: mxt_bootloader_read: i2c recv failed (-121) > atmel_mxt_ts 0-004c: Trying alternate bootloader address > atmel_mxt_ts 0-004c: mxt_bootloader_read: i2c recv failed (-121) > atmel_mxt_ts: probe of 0-004c failed with error -121 > > Reviewed-by: Linus Walleij <linus.walleij@linaro.org> > Signed-off-by: Jiada Wang <jiada_wang@mentor.com> > Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Applied, thank you.
On Tue, Mar 02, 2021 at 01:21:58PM +0300, Dmitry Osipenko wrote: > Acer A500 uses Atmel Maxtouch 1386 touchscreen controller. This controller > has WAKE line which could be connected to I2C clock lane, dedicated GPIO > or fixed to HIGH level. Controller wakes up from a deep sleep when WAKE > line is asserted low. Acer A500 has WAKE line connected to I2C clock and > Linux device driver doesn't work property without knowing what wakeup > method is used by h/w. > > Add atmel,wakeup-method property to the touchscreen node. > > Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Applied, thank you.
Hi Dmitry, On Sat, Mar 20, 2021 at 07:02:43PM +0300, Dmitry Osipenko wrote: > 02.03.2021 13:21, Dmitry Osipenko пишет: > > Some Atmel maXTouch controllers, like mXT1386 and mXT3432S1 for example, > > have a WAKE line that needs to be asserted in order to wake controller > > from a deep sleep, otherwise it will be unusable. This series implements > > support for the wakeup methods in accordance to the mXT1386 datasheet [1], > > see page 29 (chapter "5.8 WAKE Line"). > > > > The mXT1386 is a widely used controller found on many older Android tablet > > devices. Touchscreen on Acer A500 tablet now works properly after this > > series. > > > > This patchset is a continuation of the work originally started by > > Jiada Wang [2]. > > > > [1] https://ww1.microchip.com/downloads/en/DeviceDoc/mXT1386_1vx_Datasheet_LX.pdf > > [2] https://patchwork.kernel.org/project/linux-input/list/?series=357875 > > Hi, > > This series is very wanted by Android tablet devices from Acer, Asus and > other vendors which use Maxtouch 1386 controller. Touchscreens don't > work without the wakeup support, i.e. without this series. The wakeup > support is implemented in accordance to the datasheet and touchscreens > are working excellent using these patches. > > Could you please take this series into v5.13? > > Or could you please let me know what exactly needs to be improved? Sorry, I was still slightly unhappy that we still are not tracking the state of controller and opportunistically retrying failed I2C transfers, but as I am failing to find time to come up with another solution I have just applied your series. Thanks.
22.03.2021 01:44, Dmitry Torokhov пишет: > Hi Dmitry, > > On Sat, Mar 20, 2021 at 07:02:43PM +0300, Dmitry Osipenko wrote: >> 02.03.2021 13:21, Dmitry Osipenko пишет: >>> Some Atmel maXTouch controllers, like mXT1386 and mXT3432S1 for example, >>> have a WAKE line that needs to be asserted in order to wake controller >>> from a deep sleep, otherwise it will be unusable. This series implements >>> support for the wakeup methods in accordance to the mXT1386 datasheet [1], >>> see page 29 (chapter "5.8 WAKE Line"). >>> >>> The mXT1386 is a widely used controller found on many older Android tablet >>> devices. Touchscreen on Acer A500 tablet now works properly after this >>> series. >>> >>> This patchset is a continuation of the work originally started by >>> Jiada Wang [2]. >>> >>> [1] https://ww1.microchip.com/downloads/en/DeviceDoc/mXT1386_1vx_Datasheet_LX.pdf >>> [2] https://patchwork.kernel.org/project/linux-input/list/?series=357875 >> >> Hi, >> >> This series is very wanted by Android tablet devices from Acer, Asus and >> other vendors which use Maxtouch 1386 controller. Touchscreens don't >> work without the wakeup support, i.e. without this series. The wakeup >> support is implemented in accordance to the datasheet and touchscreens >> are working excellent using these patches. >> >> Could you please take this series into v5.13? >> >> Or could you please let me know what exactly needs to be improved? > > Sorry, I was still slightly unhappy that we still are not tracking the > state of controller and opportunistically retrying failed I2C transfers, > but as I am failing to find time to come up with another solution I have > just applied your series. Thank you! I don't have other solutions either, although /I think/ potentially it should be possible to differentiate the I2C error here. On NVIDIA Tegra I see that I2C controller always gets a h/w NAK on TS wake-up and it returns -EREMOTEIO in this case. IIRC, some other non-NVIDIA I2C drivers always return -EIO on any error, so this method isn't universal, but certainly it feels like there is some a room for further improvements.
On Sun, Mar 21, 2021 at 03:40:28PM -0700, Dmitry Torokhov wrote: > On Tue, Mar 02, 2021 at 01:21:58PM +0300, Dmitry Osipenko wrote: > > Acer A500 uses Atmel Maxtouch 1386 touchscreen controller. This controller > > has WAKE line which could be connected to I2C clock lane, dedicated GPIO > > or fixed to HIGH level. Controller wakes up from a deep sleep when WAKE > > line is asserted low. Acer A500 has WAKE line connected to I2C clock and > > Linux device driver doesn't work property without knowing what wakeup > > method is used by h/w. > > > > Add atmel,wakeup-method property to the touchscreen node. > > > > Signed-off-by: Dmitry Osipenko <digetx@gmail.com> > > Applied, thank you. I noticed that you had applied this as I was applying a different patch that touches the same area and it causes a conflict. In general I prefer to pick up all device tree changes into the Tegra tree, specifically to avoid such conflicts. That said, I didn't see an email from Stephen about this causing a conflict in linux-next, so perhaps it's fine. If this pops up again it might be worth considering to drop this from your tree so that I can resolve the conflict in the Tegra tree. Thierry
On Thu, Mar 25, 2021 at 03:10:25PM +0100, Thierry Reding wrote: > On Sun, Mar 21, 2021 at 03:40:28PM -0700, Dmitry Torokhov wrote: > > On Tue, Mar 02, 2021 at 01:21:58PM +0300, Dmitry Osipenko wrote: > > > Acer A500 uses Atmel Maxtouch 1386 touchscreen controller. This controller > > > has WAKE line which could be connected to I2C clock lane, dedicated GPIO > > > or fixed to HIGH level. Controller wakes up from a deep sleep when WAKE > > > line is asserted low. Acer A500 has WAKE line connected to I2C clock and > > > Linux device driver doesn't work property without knowing what wakeup > > > method is used by h/w. > > > > > > Add atmel,wakeup-method property to the touchscreen node. > > > > > > Signed-off-by: Dmitry Osipenko <digetx@gmail.com> > > > > Applied, thank you. > > I noticed that you had applied this as I was applying a different patch > that touches the same area and it causes a conflict. In general I prefer > to pick up all device tree changes into the Tegra tree, specifically to > avoid such conflicts. > > That said, I didn't see an email from Stephen about this causing a > conflict in linux-next, so perhaps it's fine. If this pops up again it > might be worth considering to drop this from your tree so that I can > resolve the conflict in the Tegra tree. Sorry about that, I went ahead and dropped the patch from my branch. Thanks.
On Thu, Mar 25, 2021 at 11:15:54AM -0700, Dmitry Torokhov wrote: > On Thu, Mar 25, 2021 at 03:10:25PM +0100, Thierry Reding wrote: > > On Sun, Mar 21, 2021 at 03:40:28PM -0700, Dmitry Torokhov wrote: > > > On Tue, Mar 02, 2021 at 01:21:58PM +0300, Dmitry Osipenko wrote: > > > > Acer A500 uses Atmel Maxtouch 1386 touchscreen controller. This controller > > > > has WAKE line which could be connected to I2C clock lane, dedicated GPIO > > > > or fixed to HIGH level. Controller wakes up from a deep sleep when WAKE > > > > line is asserted low. Acer A500 has WAKE line connected to I2C clock and > > > > Linux device driver doesn't work property without knowing what wakeup > > > > method is used by h/w. > > > > > > > > Add atmel,wakeup-method property to the touchscreen node. > > > > > > > > Signed-off-by: Dmitry Osipenko <digetx@gmail.com> > > > > > > Applied, thank you. > > > > I noticed that you had applied this as I was applying a different patch > > that touches the same area and it causes a conflict. In general I prefer > > to pick up all device tree changes into the Tegra tree, specifically to > > avoid such conflicts. > > > > That said, I didn't see an email from Stephen about this causing a > > conflict in linux-next, so perhaps it's fine. If this pops up again it > > might be worth considering to drop this from your tree so that I can > > resolve the conflict in the Tegra tree. > > Sorry about that, I went ahead and dropped the patch from my branch. Applied to the Tegra tree now. Thanks, Thierry