Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp3373741yba; Mon, 29 Apr 2019 00:46:57 -0700 (PDT) X-Google-Smtp-Source: APXvYqzHpAW42EFq2KEdQtShoHFrCHNI5PW+iMIbMY/IpOTbJ1Oq5RQmxunC6dHbiVxgCVfjQhJz X-Received: by 2002:a62:5445:: with SMTP id i66mr31586284pfb.250.1556524017464; Mon, 29 Apr 2019 00:46:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1556524017; cv=none; d=google.com; s=arc-20160816; b=U2HB30EV9Jd8kCkf9M6l2cuBSQQMZ0C13Iry5VLSd5Mtzu/ter6K3BRLKoEK1jcesi 6quZl3hyf00+7FAZNeUEFantnUui0vhrkjtDXn8p33OkpCuxWJHjqiZqHH4Pc9X/gbZ6 oSSzHtmk7QDe2yhQ4wJb5IaSuZdv96Ico9r6NYewk6k7SmPrIicBNR+WEq2t5OPlo72v SjWyfb8XqP+sW23acNSMS+XGv/G/VVw+Rbqiy5WUB0wx8r6ce35Lu355QCt//25r3nLT CxOdVT8BwOwbCpl1Qqt053rAZExLVjJfq4x/gZMJOk1FduOkLRBgW+kgRpUfEWs47Xeo 9NJg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version; bh=G1fYVX4Wl40jdZ8+GWZHzYu+3eRKXOD4apXXEPaZ4Wc=; b=U40xE/QTchhsy1cPWsubadkFCkZj8srr50KXdx9Hs5bBj8zje0g+qGt+IHn3O8BNkk UZbEmtLShDa6Cmm0iWSuax9bv07jpu7xdtEQLc9mSR2gffEt5LKDhmJMAPbygsoBctDv lplq5wcfYTRW9TdTCO/EJH/gQAQS4/DmWuDKtnyVJLzX2h3KPyyMcCLFlVA0neQ1XvNT XjV8fCe7PMlbOFexCFfn106pUTt8DUccsGBq3DYrqm9j62NOjqFOYVIYPP7QFbW1AC8I ymGpsohTD/mW0ab4KLCx003FvJjzxsB3Aua9EKN00paU0OHuGgQbG4PAQZSg8T0E07HH yr+w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d11si2480631pla.87.2019.04.29.00.46.42; Mon, 29 Apr 2019 00:46:57 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727440AbfD2Hpy (ORCPT + 99 others); Mon, 29 Apr 2019 03:45:54 -0400 Received: from mail-qt1-f196.google.com ([209.85.160.196]:38877 "EHLO mail-qt1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727380AbfD2Hpy (ORCPT ); Mon, 29 Apr 2019 03:45:54 -0400 Received: by mail-qt1-f196.google.com with SMTP id d13so10858342qth.5 for ; Mon, 29 Apr 2019 00:45:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=G1fYVX4Wl40jdZ8+GWZHzYu+3eRKXOD4apXXEPaZ4Wc=; b=dSYoU72GZBkecApfUSCaglJ4NDTV0VnaPXDJwLKOcmN9hLa5FLOxOFAX8/8HE1fxmE sKyYITN6M7UKGKCVn2+5eDMPtdVKNXj8Thj4jHLlFtfbm3wadccIPjWHfqSROp8+Bok6 nyEIbyDxm47hOdTuaksQz/h5T+JO1owPZ6BAYj2dGWdPOH+iHcdvxVz7v7uXz+vbqbMq q5DAIBtkHS8Ff7IAqQTRpBSwJxmy2z92gISSdnV9jloLPgbpzw0PCDuXgB9MjmRdY8rN PCPXNcKp+dpbTmDd+0OTFX2MTVswd2wwUPCPMwlUtfCeiorfN3I5BxlkWnqdEErBnRt7 +BfA== X-Gm-Message-State: APjAAAUGvBysBcwKciKdHD01COvDhl7inAVEGhQsjeM+r/p2u5oG1TNs rsPtnHSmVoAprIZgoFQzHVLOC31s/+aU2KXLxg81lA== X-Received: by 2002:a0c:e5d0:: with SMTP id u16mr18985451qvm.48.1556523953508; Mon, 29 Apr 2019 00:45:53 -0700 (PDT) MIME-Version: 1.0 References: <20190422130814.GJ173520@google.com> <3a1139ef-10ed-6923-73c5-30fbf0c065c3@linux.intel.com> In-Reply-To: <3a1139ef-10ed-6923-73c5-30fbf0c065c3@linux.intel.com> From: Benjamin Tissoires Date: Mon, 29 Apr 2019 09:45:42 +0200 Message-ID: Subject: Re: [Bug 203297] Synaptics touchpad TM-3127 functionality broken by PCI runtime power management patch on 4.20.2 To: Jarkko Nikula Cc: Bjorn Helgaas , Keijo Vaara , Jean Delvare , "Rafael J. Wysocki" , Dmitry Torokhov , linux-pm@vger.kernel.org, linux-pci@vger.kernel.org, lkml , "open list:HID CORE LAYER" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Apr 26, 2019 at 2:14 PM Jarkko Nikula wrote: > > On 4/22/19 4:08 PM, Bjorn Helgaas wrote: > > https://bugzilla.kernel.org/show_bug.cgi?id=203297 > > > > Regression, suspected but as yet unconfirmed cause: > > > > c5eb1190074c ("PCI / PM: Allow runtime PM without callback functions") > > > > backported to 4.20 stable as 39e1be324c2f. > > > With help of Keijo it was confirmed above patch broke the Synaptics > touchpad. Not bisected but touchpad works again by forcing the i2c-i801 > SMBus controller always on: > "echo on >/sys/bus/pci/devices/0000\:00\:1f.3/power/control" > > Above patch is a generalized fix that fixed the runtime PM regression on > i2c-i801 and re-allow the controller go to runtime suspend when idle. So > most probably Synaptics touchpad was broken by i2c-i801 runtime PM also > before but got unnoticed. Which is easy since on many platforms SMBus > controller doesn't necessarily have the PCI PM capabilities. > > I would like to ask help from input subsystem experts what kind of SMBus > power state dependency Synaptics RMI4 SMBus devices have since it cease > to work if SMBus controllers idles between transfers and how this is > best to fix? Hmm, I am not sure there is such an existing architecture you could use in a simple patch. rmi-driver.c does indeed create an input device we could use to toggle on/off the PM state, but those callbacks are not wired to the transport driver (rmi_smbus.c), so it would required a little bit of extra work. And then, there are other RMI4 functions (firmware upgrade) that would not be happy if PM is in suspend while there is no open input node. So I think this "hack" (with Mika's comments addressed) should go in until someone starts propagating the PM states correctly. Cheers, Benjamin > > Instead of revert I think we'd need to have some method to force SMBus > controller on whenever the touchpad is active, like when there is a > userspace listening. > > I'm not expert in this area so as quick proof of concept I had a > following hack which forces the I2C/SMBus adapter, and eventually the > parent PCI device of it on when the RMI4 SMBus device is probed and let > the SMBus controller to idle when removed. > > According to Keijo it fixes the issue but I like to hear input experts > for better place to put these. > > diff --git a/drivers/input/rmi4/rmi_smbus.c b/drivers/input/rmi4/rmi_smbus.c > index b6ccf39c6a7b..2b11d69be313 100644 > --- a/drivers/input/rmi4/rmi_smbus.c > +++ b/drivers/input/rmi4/rmi_smbus.c > @@ -16,6 +16,7 @@ > #include > #include > #include > +#include > #include > #include > #include "rmi_driver.h" > @@ -332,6 +333,9 @@ static int rmi_smb_probe(struct i2c_client *client, > > dev_info(&client->dev, "registering SMbus-connected sensor\n"); > > + /* Force SMBus adapter on while RMI4 device is connected */ > + pm_runtime_get(&client->adapter->dev); > + > error = rmi_register_transport_device(&rmi_smb->xport); > if (error) { > dev_err(&client->dev, "failed to register sensor: %d\n", error); > @@ -346,6 +350,7 @@ static int rmi_smb_remove(struct i2c_client *client) > struct rmi_smb_xport *rmi_smb = i2c_get_clientdata(client); > > rmi_unregister_transport_device(&rmi_smb->xport); > + pm_runtime_put(&client->adapter->dev); > > return 0; > } > > -- > Jarkko