[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZhVix-HJrqQbiPrB@hovoldconsulting.com>
Date: Tue, 9 Apr 2024 17:46:15 +0200
From: Johan Hovold <johan@...nel.org>
To: Łukasz Majczak <lma@...omium.org>
Cc: Jiri Kosina <jikos@...nel.org>, Dmitry Torokhov <dtor@...omium.org>,
Benjamin Tissoires <benjamin.tissoires@...hat.com>,
Douglas Anderson <dianders@...omium.org>,
Hans de Goede <hdegoede@...hat.com>,
Maxime Ripard <mripard@...nel.org>,
Kai-Heng Feng <kai.heng.feng@...onical.com>,
Johan Hovold <johan+linaro@...nel.org>, linux-input@...r.kernel.org,
linux-kernel@...r.kernel.org, Radoslaw Biernacki <rad@...omium.org>
Subject: Re: [PATCH v2] HID: i2c-hid: wait for i2c touchpad deep-sleep to
power-up transition
On Tue, Apr 09, 2024 at 12:53:43PM +0200, Łukasz Majczak wrote:
> > Can you please explain why this would not a problem for all future
> > transactions as well?
> The problem is that the probe function calling i2c_smbus_read_byte()
> is not aware that
> uC on the other end is in a deep sleep state so the first read will
> fail and so the whole probe.
>
> In a normal scenario, when a user touches the touchpad (when it is in
> a deep sleep), the touch will first wake up the uC and
> then generate an interrupt to AP, so in this case the touchpad is
> fully awake and operational.
Sure, but what about other transactions that are initiated by the host
(e.g. SET_POWER)?
Perhaps this hack at probe is enough for your use case, but is an
incomplete hack and at a minimum you'd need to add a comment explaining
why it is there.
Johan
Powered by blists - more mailing lists