From patchwork Thu Jan 28 12:57:44 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Hans de Goede X-Patchwork-Id: 12053637 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-16.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D3E0AC4332B for ; Thu, 28 Jan 2021 12:59:39 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 9D4DB64DF7 for ; Thu, 28 Jan 2021 12:59:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231705AbhA1M7U (ORCPT ); Thu, 28 Jan 2021 07:59:20 -0500 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:38298 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231919AbhA1M7Q (ORCPT ); Thu, 28 Jan 2021 07:59:16 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1611838669; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=koKIjG7c9KwazpO0cI7+f+dHsF7T5faqtbrXIF83334=; b=YlZLegqVcOKFr5MPEkLw+yB0jzN5Itx8u+9dN10b0tNvAbtnxrKMu2wlXNN+USq0mQqbkf 8NW3Py9N6rmvkNryXVrlNj7C2fnB5Fr4zHy7mla/3405kt0+6WWENyCSru4Znrl2n4MAiD Y0Vx1Gs3Z/CtVOjMj9ILd161HbzbGEQ= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-147-KkzlQ-GuMCCuOm2IGReC3g-1; Thu, 28 Jan 2021 07:57:47 -0500 X-MC-Unique: KkzlQ-GuMCCuOm2IGReC3g-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id B4CFB107ACE4; Thu, 28 Jan 2021 12:57:46 +0000 (UTC) Received: from x1.localdomain (ovpn-114-250.ams2.redhat.com [10.36.114.250]) by smtp.corp.redhat.com (Postfix) with ESMTP id CC77560C13; Thu, 28 Jan 2021 12:57:45 +0000 (UTC) From: Hans de Goede To: Dmitry Torokhov Cc: Hans de Goede , linux-input@vger.kernel.org Subject: [PATCH v2] 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:44 +0100 Message-Id: <20210128125744.109119-1-hdegoede@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 Precedence: bulk List-ID: X-Mailing-List: linux-input@vger.kernel.org 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 --- Changes in v2: - Fix brown paper-bag bug where v1 did not compile --- 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..4df0f93dbb56 100644 --- a/drivers/input/touchscreen/silead.c +++ b/drivers/input/touchscreen/silead.c @@ -20,6 +20,7 @@ #include #include #include +#include #include #include @@ -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(&client->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)