public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Johan Hovold <johan@kernel.org>
To: Lukasz Majczak <lma@chromium.org>
Cc: Jiri Kosina <jikos@kernel.org>,
	Dmitry Torokhov <dtor@chromium.org>,
	Benjamin Tissoires <benjamin.tissoires@redhat.com>,
	Douglas Anderson <dianders@chromium.org>,
	Hans de Goede <hdegoede@redhat.com>,
	Maxime Ripard <mripard@kernel.org>,
	Kai-Heng Feng <kai.heng.feng@canonical.com>,
	Johan Hovold <johan+linaro@kernel.org>,
	linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
	Radoslaw Biernacki <rad@chromium.org>
Subject: Re: [PATCH v2] HID: i2c-hid: wait for i2c touchpad deep-sleep to power-up transition
Date: Mon, 8 Apr 2024 09:27:44 +0200	[thread overview]
Message-ID: <ZhOccGFkTFkUkRUI@hovoldconsulting.com> (raw)
In-Reply-To: <20240405102436.3479210-1-lma@chromium.org>

On Fri, Apr 05, 2024 at 10:24:36AM +0000, Lukasz Majczak wrote:
> This patch extends the early bailout for probing procedure introduced in
> commit b3a81b6c4fc6 ("HID: i2c-hid: check if device is there before
> really probing"), in order to cover devices
> based on STM microcontrollers. For touchpads based on STM uC,
> the probe sequence needs to take into account the increased response time
> for i2c transaction if the device already entered a deep power state.
> STM specify the wakeup time as 400us between positive strobe of
> the clock line. Deep sleep is controlled by Touchpad FW,
> though some devices enter it pretty early to conserve power
> in case of lack of activity on the i2c bus.
> Failing to follow this requirement will result in touchpad device not being
> detected due initial transaction being dropped by STM i2c slave controller.
> By adding additional try, first transaction will wake up the touchpad
> STM controller, and the second will produce proper detection response.

Can you please explain why this would not a problem for all future
transactions as well?

If it is, then it sounds like this needs to be addressed in the i2c
driver. If not, then perhaps the problem is really that you just need a
delay after enabling the power supplies? 
 
> v1->v2:
> * Updated commit message with short sha of a base commit and proper tags
> * Rearranged while loop to perform check only once
> * Loosened sleeping range
> 
> Co-developed-by: Radoslaw Biernacki <rad@chromium.org>
> Signed-off-by: Radoslaw Biernacki <rad@chromium.org>
> Signed-off-by: Lukasz Majczak <lma@chromium.org>
> ---
>  drivers/hid/i2c-hid/i2c-hid-core.c | 12 ++++++++++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/hid/i2c-hid/i2c-hid-core.c b/drivers/hid/i2c-hid/i2c-hid-core.c
> index 2df1ab3c31cc..ece1a5815e0b 100644
> --- a/drivers/hid/i2c-hid/i2c-hid-core.c
> +++ b/drivers/hid/i2c-hid/i2c-hid-core.c
> @@ -1013,9 +1013,17 @@ static int __i2c_hid_core_probe(struct i2c_hid *ihid)
>  	struct i2c_client *client = ihid->client;
>  	struct hid_device *hid = ihid->hid;
>  	int ret;
> +	int tries = 2;

Nit: move above the 'ret' declaration to maintain reverse xmas style
ordering.

Johan

  parent reply	other threads:[~2024-04-08  7:27 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-05 10:24 [PATCH v2] HID: i2c-hid: wait for i2c touchpad deep-sleep to power-up transition Lukasz Majczak
2024-04-08  3:18 ` Doug Anderson
2024-04-08  7:27 ` Johan Hovold [this message]
2024-04-09 10:53   ` Łukasz Majczak
2024-04-09 15:46     ` Johan Hovold
2024-04-11 14:23       ` Łukasz Majczak
2024-04-12  6:28         ` Kai-Heng Feng
2024-04-15  9:08         ` Johan Hovold
2024-04-15 12:26           ` Radoslaw Biernacki
2024-04-15 13:37             ` Johan Hovold
2024-04-15 10:28     ` Kenny Levinsen
2024-04-15 12:10       ` Radoslaw Biernacki
2024-04-15 12:13         ` Radoslaw Biernacki
2024-04-15 13:22       ` Johan Hovold
2024-04-15 17:14         ` Kenny Levinsen
2024-04-23 11:32           ` Łukasz Majczak
2024-04-23 13:01             ` Kenny Levinsen

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=ZhOccGFkTFkUkRUI@hovoldconsulting.com \
    --to=johan@kernel.org \
    --cc=benjamin.tissoires@redhat.com \
    --cc=dianders@chromium.org \
    --cc=dtor@chromium.org \
    --cc=hdegoede@redhat.com \
    --cc=jikos@kernel.org \
    --cc=johan+linaro@kernel.org \
    --cc=kai.heng.feng@canonical.com \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lma@chromium.org \
    --cc=mripard@kernel.org \
    --cc=rad@chromium.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