[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <508585f7-6c2b-3b33-ada8-91cc15ed683e@gmail.com>
Date: Fri, 8 Jan 2021 01:05:04 +0300
From: Dmitry Osipenko <digetx@...il.com>
To: Dmitry Torokhov <dmitry.torokhov@...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 v3 0/3] Support wakeup methods of Atmel maXTouch
controllers
13.12.2020 12:26, Dmitry Osipenko пишет:
> 13.12.2020 07:41, Dmitry Torokhov пишет:
>> Thank you for the logs. I am confused where these calls to put the
>> controller into deep sleep are coming from. Does something constantly
>> open and close input device?
>
> Input devices are re-opened multiple times during Linux distro boot-up,
> a regular Ubuntu 20.10 in this case.
>
>> Do you have any additional patches?
>
> No, I'm using next-20201211 + this "wakeup methods" patchset.
>
>> We definitely do not issue deep sleep request in mxt_start(). Do you mind
>> putting dump_stack() into mxt_set_t7_power_cfg() to see where the calls
>> are coming from?
>
> Please see the log below, I added it like this:
>
> diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c
> b/drivers/input/touchscreen/atmel_mxt_ts.c
> index e3342fdfe9f3..bbc5a5ee158a 100644
> --- a/drivers/input/touchscreen/atmel_mxt_ts.c
> +++ b/drivers/input/touchscreen/atmel_mxt_ts.c
> @@ -2271,6 +2271,8 @@ static int mxt_set_t7_power_cfg(struct mxt_data
> *data, u8 sleep)
> dev_dbg(dev, "Set T7 ACTV:%d IDLE:%d\n",
> new_config->active, new_config->idle);
>
> + dump_stack();
> +
> return 0;
> }
>
>> I also do not see additional "waking up controller" messages after
>> requesting the chip via T7 to be configured to be active, which I'd
>> expected to see if we indeed needed to wake it up again for T6 to
>> succeed.
>
> I'm not familiar with what controller does internally, hence no clue.
>
>
> [ 1.195295] Family: 160 Variant: 0 Firmware V1.0.AA Objects: 18
> [ 1.195468] T37 Start:118 Size:130 Instances:1 Report IDs:0-0
...
Dmitry Torokhov, do you have any more comments? Are you okay with v3? If
yes, could you please pick up patches into -next?
Powered by blists - more mailing lists