From: Dmitry Osipenko <digetx@gmail.com>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Nick Dyer <nick@shmanahar.org>, Rob Herring <robh+dt@kernel.org>,
Thierry Reding <thierry.reding@gmail.com>,
Jonathan Hunter <jonathanh@nvidia.com>,
Linus Walleij <linus.walleij@linaro.org>,
Jiada Wang <jiada_wang@mentor.com>,
linux-input@vger.kernel.org, devicetree@vger.kernel.org,
linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v6 0/3] Support wakeup methods of Atmel maXTouch controllers
Date: Mon, 22 Mar 2021 02:08:09 +0300 [thread overview]
Message-ID: <9f1f1bbb-31ef-c4fe-fcf5-c798e53739cf@gmail.com> (raw)
In-Reply-To: <YFfMNQPvaNOjUwBB@google.com>
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.
prev parent reply other threads:[~2021-03-21 23:09 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-02 10:21 [PATCH v6 0/3] Support wakeup methods of Atmel maXTouch controllers Dmitry Osipenko
2021-03-02 10:21 ` [PATCH v6 1/3] dt-bindings: input: atmel_mxt_ts: Document atmel,wakeup-method and WAKE line GPIO Dmitry Osipenko
2021-03-21 22:40 ` Dmitry Torokhov
2021-03-02 10:21 ` [PATCH v6 2/3] Input: atmel_mxt_ts - support wakeup methods Dmitry Osipenko
2021-03-21 22:40 ` Dmitry Torokhov
2021-03-02 10:21 ` [PATCH v6 3/3] ARM: tegra: acer-a500: Add atmel,wakeup-method property Dmitry Osipenko
2021-03-21 22:40 ` Dmitry Torokhov
2021-03-25 14:10 ` Thierry Reding
2021-03-25 18:15 ` Dmitry Torokhov
2021-03-26 12:21 ` Thierry Reding
2021-03-20 16:02 ` [PATCH v6 0/3] Support wakeup methods of Atmel maXTouch controllers Dmitry Osipenko
2021-03-21 22:44 ` Dmitry Torokhov
2021-03-21 23:08 ` Dmitry Osipenko [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9f1f1bbb-31ef-c4fe-fcf5-c798e53739cf@gmail.com \
--to=digetx@gmail.com \
--cc=devicetree@vger.kernel.org \
--cc=dmitry.torokhov@gmail.com \
--cc=jiada_wang@mentor.com \
--cc=jonathanh@nvidia.com \
--cc=linus.walleij@linaro.org \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=nick@shmanahar.org \
--cc=robh+dt@kernel.org \
--cc=thierry.reding@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).