[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YFfMNQPvaNOjUwBB@google.com>
Date: Sun, 21 Mar 2021 15:44:05 -0700
From: Dmitry Torokhov <dmitry.torokhov@...il.com>
To: Dmitry Osipenko <digetx@...il.com>
Cc: Nick Dyer <nick@...anahar.org>, Rob Herring <robh+dt@...nel.org>,
Thierry Reding <thierry.reding@...il.com>,
Jonathan Hunter <jonathanh@...dia.com>,
Linus Walleij <linus.walleij@...aro.org>,
Jiada Wang <jiada_wang@...tor.com>,
linux-input@...r.kernel.org, devicetree@...r.kernel.org,
linux-tegra@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v6 0/3] Support wakeup methods of Atmel maXTouch
controllers
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.
--
Dmitry
Powered by blists - more mailing lists