From: "Wang, Jiada" <jiada_wang@mentor.com>
To: Dmitry Osipenko <digetx@gmail.com>, <nick@shmanahar.org>,
<dmitry.torokhov@gmail.com>, <robh+dt@kernel.org>
Cc: <linux-input@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<andy.shevchenko@gmail.com>, <erosca@de.adit-jv.com>,
<Andrew_Gabbasov@mentor.com>
Subject: Re: [PATCH v2 2/2] Input: atmel_mxt_ts - wake mXT1386 from deep-sleep mode
Date: Sun, 20 Sep 2020 14:28:45 +0900 [thread overview]
Message-ID: <e9ad6ba7-05a3-af3b-85c3-94797fb33554@mentor.com> (raw)
In-Reply-To: <11e0052b-ae7a-71bc-1b28-9d5b42acfd11@gmail.com>
Hi Dmitry
On 2020/09/20 4:49, Dmitry Osipenko wrote:
> 18.09.2020 18:55, Wang, Jiada пишет:
> ...
>>>> +static void mxt_wake(struct mxt_data *data)
>>>> +{
>>>> + struct i2c_client *client = data->client;
>>>> + struct device *dev = &data->client->dev;
>>>> + struct device_node *np = dev->of_node;
>>>> + union i2c_smbus_data dummy;
>>>> +
>>>> + if (!of_device_is_compatible(np, "atmel,mXT1386"))
>>>> + return;
>>> I'm not sure whether you misses the previous answers from Dmitry
>>> Torokhov and Rob Herring, but they suggested to add a new device-tree
>>> property which should specify the atmel,wakeup-method.
>>>
>> I think Rob Herring prefers for the compatible solution than property.
>
> Actually, seems you're right. But I'm not sure now whether he just made
> a typo, because it's actually a board-specific option.
>
Right, I think since it is a board specific issue,
so "property" is the preferred way,
if I understand you correctly,
compatible combine with property is what you are suggesting, right?
> It could be more preferred to skip the i2c_smbus_xfer() for the NONE
> variant, but it also should be harmless in practice. I guess we indeed
> could keep the current variant of yours patch and then add a clarifying
> comment to the commit message and to the code, telling that
> i2c_smbus_xfer() is harmless in a case of the hardwired WAKE-LINE.
>
I will skip dummy read for "NONE" variant.
>>> There are 3 possible variants:
>>>
>>> - NONE
>>> - GPIO
>>> - I2C-SCL
>>>
>>> Hence we should bail out from mxt_wake() if method is set to NONE or
>>> GPIO.
>>>
>> for "GPIO", we still need 25 ms sleep. but rather than a dummy read,
>> WAKE line need to be asserted before sleep.
>
> Correct, I just meant to bail out because GPIO is currently unsupported.
>
OK
> ...
>>>> static int mxt_initialize(struct mxt_data *data)
>>>> {
>>>> struct i2c_client *client = data->client;
>>>> int recovery_attempts = 0;
>>>> int error;
>>>> + mxt_wake(data);
>>>> +
>>>> while (1) {
>>>
>>> I assume the mxt_wake() should be placed here, since there is a 3
>>> seconds timeout in the end of the while-loop, meaning that device may
>>> get back into deep-sleep on a retry.
>>>
>> Can you elaborate a little more why exit from bootload mode after sleep
>> for 3 second could enter deep-sleep mode.
>
> The loop attempts to exit from bootload mode and then I suppose
> mxt_read_info_block() may fail if I2C "accidentally" fails, hence the
> deep-sleep mode still will be enabled on a retry.
>
> The datasheet says that there are 2 seconds since the time of the last
> I2C access before TS is put back into auto-sleep if deep-sleep mode is
> enabled. The wait-loop has msleep(3000).
OK, thanks for the clarification
Thanks,
Jiada
>
next prev parent reply other threads:[~2020-09-20 5:35 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-18 12:56 [PATCH v1 1/2] dt-bindings: input: atmel: add compatible for mXT1386 Jiada Wang
2020-09-18 12:56 ` [PATCH v2 2/2] Input: atmel_mxt_ts - wake mXT1386 from deep-sleep mode Jiada Wang
2020-09-18 13:32 ` Dmitry Osipenko
2020-09-18 15:55 ` Wang, Jiada
2020-09-19 19:49 ` Dmitry Osipenko
2020-09-20 5:28 ` Wang, Jiada [this message]
2020-09-20 6:02 ` Dmitry Torokhov
2020-09-20 13:13 ` Wang, Jiada
2020-09-20 14:21 ` Dmitry Osipenko
2020-09-20 14:36 ` Wang, Jiada
2020-09-20 15:49 ` Dmitry Osipenko
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=e9ad6ba7-05a3-af3b-85c3-94797fb33554@mentor.com \
--to=jiada_wang@mentor.com \
--cc=Andrew_Gabbasov@mentor.com \
--cc=andy.shevchenko@gmail.com \
--cc=digetx@gmail.com \
--cc=dmitry.torokhov@gmail.com \
--cc=erosca@de.adit-jv.com \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nick@shmanahar.org \
--cc=robh+dt@kernel.org \
/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).