From: Hans de Goede <hdegoede@redhat.com>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: linux-input@vger.kernel.org
Subject: Re: [PATCH] Input: silead - Add workaround for x86 BIOS-es which bring the Silead chip up in a stuck state
Date: Thu, 28 Jan 2021 13:57:20 +0100 [thread overview]
Message-ID: <4cf568a0-7409-ce07-773d-9df83ec2a861@redhat.com> (raw)
In-Reply-To: <20210128125256.106879-1-hdegoede@redhat.com>
Hi,
Ugh, I had a local compile-fix which I forgot to git commit -a --amend,
so this version does not compile, please ignore.
V2 coming up right away.
Regards,
Hans
On 1/28/21 1:52 PM, Hans de Goede wrote:
> Some buggy BIOS-es bring up the touchscreen-controller in a stuck
> state where it blocks the I2C bus. Specifically this happens on
> the Jumper EZpad 7 tablet model.
>
> After much poking at this problem I have found that the following steps
> are necessary to unstuck the chip / bus:
>
> 1. Turn off the Silead chip.
> 2. Try to do an I2C transfer with the chip, this will fail in response to
> which the I2C-bus-driver will call: i2c_recover_bus() which will unstuck
> the I2C-bus. Note the unstuck-ing of the I2C bus only works if we first
> drop the chip of the bus by turning it off.
> 3. Turn the chip back on.
>
> On the x86/ACPI systems were this problem is seen, step 1. and 3. require
> making ACPI calls and dealing with ACPI Power Resources. This commit adds
> a workaround which runtime-suspends the chip to turn it off, leaving it up
> to the ACPI subsystem to deal with all the ACPI specific details.
>
> There is no good way to detect this bug, so the workaround gets activated
> by a new "silead,stuck-controller-bug" boolean device-property. Since this
> is only used on x86/ACPI, this will be set by model specific device-props
> set by drivers/platform/x86/touchscreen_dmi.c. Therefor this new
> device-property is not documented in the DT-bindings.
>
> Dmesg will contain the following messages on systems where the workaround
> is activated:
>
> [ 54.309029] silead_ts i2c-MSSL1680:00: [Firmware Bug]: Stuck I2C bus: please ignore the next 'controller timed out' error
> [ 55.373593] i2c_designware 808622C1:04: controller timed out
> [ 55.582186] silead_ts i2c-MSSL1680:00: Silead chip ID: 0x80360000
>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
> drivers/input/touchscreen/silead.c | 39 +++++++++++++++++++++++++++---
> 1 file changed, 35 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/input/touchscreen/silead.c b/drivers/input/touchscreen/silead.c
> index 8fa2f3b7cfd8..9deef6317761 100644
> --- a/drivers/input/touchscreen/silead.c
> +++ b/drivers/input/touchscreen/silead.c
> @@ -20,6 +20,7 @@
> #include <linux/input/mt.h>
> #include <linux/input/touchscreen.h>
> #include <linux/pm.h>
> +#include <linux/pm_runtime.h>
> #include <linux/irq.h>
> #include <linux/regulator/consumer.h>
>
> @@ -335,10 +336,8 @@ static int silead_ts_get_id(struct i2c_client *client)
>
> error = i2c_smbus_read_i2c_block_data(client, SILEAD_REG_ID,
> sizeof(chip_id), (u8 *)&chip_id);
> - if (error < 0) {
> - dev_err(&client->dev, "Chip ID read error %d\n", error);
> + if (error < 0)
> return error;
> - }
>
> data->chip_id = le32_to_cpu(chip_id);
> dev_info(&client->dev, "Silead chip ID: 0x%8X", data->chip_id);
> @@ -351,12 +350,44 @@ static int silead_ts_setup(struct i2c_client *client)
> int error;
> u32 status;
>
> + /*
> + * Some buggy BIOS-es bring up the chip in a stuck state where it blocks the I2C bus.
> + * The following steps are necessary to unstuck the chip / bus:
> + * 1. Turn off the Silead chip.
> + * 2. Try to do an I2C transfer with the chip, this will fail in response to
> + * which the I2C-bus-driver will call: i2c_recover_bus() which will unstuck
> + * the I2C-bus. Note the unstuck-ing of the I2C bus only works if we first
> + * drop the chip of the bus by turning it off.
> + * 3. Turn the chip back on.
> + *
> + * On the x86/ACPI systems were this problem is seen, step 1. and 3. require
> + * making ACPI calls and dealing with ACPI Power Resources. The workaround below
> + * runtime-suspends the chip to turn it off, leaving it up to the ACPI subsystem
> + * to deal with this.
> + */
> + if (device_property_read_bool(dev, "silead,stuck-controller-bug")) {
> + pm_runtime_set_active(&client->dev);
> + pm_runtime_enable(&client->dev);
> + pm_runtime_allow(&client->dev);
> +
> + pm_runtime_suspend(&client->dev);
> +
> + dev_warn(&client->dev, FW_BUG "Stuck I2C bus: please ignore the next 'controller timed out' error\n");
> + silead_ts_get_id(client);
> +
> + /* The forbid will also resume the device */
> + pm_runtime_forbid(&client->dev);
> + pm_runtime_disable(&client->dev);
> + }
> +
> silead_ts_set_power(client, SILEAD_POWER_OFF);
> silead_ts_set_power(client, SILEAD_POWER_ON);
>
> error = silead_ts_get_id(client);
> - if (error)
> + if (error) {
> + dev_err(&client->dev, "Chip ID read error %d\n", error);
> return error;
> + }
>
> error = silead_ts_init(client);
> if (error)
>
prev parent reply other threads:[~2021-01-28 12:59 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-28 12:52 [PATCH] Input: silead - Add workaround for x86 BIOS-es which bring the Silead chip up in a stuck state Hans de Goede
2021-01-28 12:57 ` Hans de Goede [this message]
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=4cf568a0-7409-ce07-773d-9df83ec2a861@redhat.com \
--to=hdegoede@redhat.com \
--cc=dmitry.torokhov@gmail.com \
--cc=linux-input@vger.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).