Re: [PATCH v3 0/3] Support wakeup methods of Atmel maXTouch controllers

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 v3 0/3] Support wakeup methods of Atmel maXTouch controllers
Date: Fri, 8 Jan 2021 01:05:04 +0300	[thread overview]
Message-ID: <508585f7-6c2b-3b33-ada8-91cc15ed683e@gmail.com> (raw)
In-Reply-To: <6b515373-e7b3-4700-7d34-4413a630c461@gmail.com>

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?