Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp436192pxk; Wed, 23 Sep 2020 07:04:00 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyGOfUb0vdmZ15b4ELrZ8Q9MqD22kb+C0DkYrKqUl33rLMSH7tYrEIKnuT2jI0VPn0Djj60 X-Received: by 2002:a1c:a184:: with SMTP id k126mr6649394wme.39.1600869839919; Wed, 23 Sep 2020 07:03:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1600869839; cv=none; d=google.com; s=arc-20160816; b=j34/qeMK2fbmvBjLRKS5ILSsm0PJmTdpd5MSXmu7sHr/+gMx1SBcFnE1J8i87n/jts qwsmWCpimSG1VYaLHJsWVA2c9S5A9XO9wqftShqyZcLOv+aCL3LoW34MV1wilXkXN9Id XfPhTYi2no66PdPq06ujrF5HphlHeXUCVxU6NKCTFyCPU974POxVuE13EgYMzb/vGCfl 6n7J9avAkrK+mfri1191fLbzA7Tj4zfC/jW5FZSghk0ov881T+nJhpM6kl8ZRPWxjk/l Yi3HShPZnm8ypUyn42rJv7ABctov/5GS2h7pPIcbsIrLB+fT3TB32isdiHlSFo3Mydin RvpQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject:ironport-sdr:ironport-sdr; bh=mSZ2aIjpD6nXCL+GHVtUhdbOOKx7Q6jTssSMGwqW5Qw=; b=ex16vM6J/StD3X11Y05gRVhYFeNaINYcXljgeThb8CLPJgq9MRP0AY5jVVvE9L+P5F 4kBp1CnFe71OME62r1EhdCdVbpNtQAsXv23f4/bdrQC8jo+KBUlalogXK7ekrf2TU2Pn qwNURotn3f3+iUFISGYuGdo7nWGlUUgqBPBA5sL2NHq09FiMA+AHeqpdxp+KNQylG1Nj uv1twVk5yVVbHt505kH0ZfnwO+NHGyRcyYgJgAZb6E+2cifDNeu16erKAB5mOLIQk3C+ F5E2TupdRWNB3lTPSZuDDOGTaB5BB3vAcTaydVmOLwfGLUXp89ze95VfImUd06Y//63t 2KTg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id r23si12513573ejs.259.2020.09.23.07.03.21; Wed, 23 Sep 2020 07:03:59 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726662AbgIWN73 (ORCPT + 99 others); Wed, 23 Sep 2020 09:59:29 -0400 Received: from mga09.intel.com ([134.134.136.24]:22474 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726460AbgIWN73 (ORCPT ); Wed, 23 Sep 2020 09:59:29 -0400 IronPort-SDR: HSDgW3bp6augOKhIPrnwomHK7A7XxZWUW8jUGxAtXSoOd3946P1/fOVbPpG6uqmzmbziAyPWg8 FhSxkgvxJnzw== X-IronPort-AV: E=McAfee;i="6000,8403,9752"; a="161826177" X-IronPort-AV: E=Sophos;i="5.77,293,1596524400"; d="scan'208";a="161826177" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Sep 2020 06:59:28 -0700 IronPort-SDR: 8Oy5AgqLUvn41mrOnHSUoULieLzrAnjuAay2f7s2JTlXC+LLeuNY+bsqH3+VOnac40F8u7XiWx I1CPmyJ3ogDA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.77,293,1596524400"; d="scan'208";a="309916738" Received: from mylly.fi.intel.com (HELO [10.237.72.56]) ([10.237.72.56]) by orsmga006.jf.intel.com with ESMTP; 23 Sep 2020 06:59:25 -0700 Subject: Re: [PATCH v2 0/4] i2c-hid: Save power by reducing i2c xfers with block reads To: Andy Shevchenko , Sultan Alsawaf Cc: linux-i2c , Jiri Kosina , Aaron Ma , Pavel Balan , Andy Shevchenko , Benjamin Tissoires , Hans de Goede , HungNien Chen , Kai-Heng Feng , linux-input , Linux Kernel Mailing List , Mika Westerberg , You-Sheng Yang , Wolfram Sang References: <20200917052256.5770-1-sultan@kerneltoast.com> From: Jarkko Nikula Message-ID: <86cbe3f2-30c9-615e-6d29-c94c98d6be53@linux.intel.com> Date: Wed, 23 Sep 2020 16:59:24 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 9/17/20 5:02 PM, Andy Shevchenko wrote: > On Thu, Sep 17, 2020 at 8:26 AM Sultan Alsawaf wrote: >> >> From: Sultan Alsawaf >> >> This is a fixed resubmission of "[PATCH 0/2] i2c-hid: Save power by reducing i2c >> xfers with block reads". That original patchset did not have enough fixes for >> the designware i2c adapter's I2C_M_RECV_LEN feature, which is documented >> extensively in the original email thread. >> >> Here is the original cover letter, which still applies: >> "I noticed on my Dell Precision 15 5540 with an i9-9880H that simply putting my >> finger on the touchpad would increase my system's power consumption by 4W, which >> is quite considerable. Resting my finger on the touchpad would generate roughly >> 4000 i2c irqs per second, or roughly 20 i2c irqs per touchpad irq. >> >> Upon closer inspection, I noticed that the i2c-hid driver would always transfer >> the maximum report size over i2c (which is 60 bytes for my touchpad), but all of >> my touchpad's normal touch events are only 32 bytes long according to the length >> byte contained in the buffer sequence. >> >> Therefore, I was able to save about 2W of power by passing the I2C_M_RECV_LEN >> flag in i2c-hid, which says to look for the payload length in the first byte of >> the transfer buffer and adjust the i2c transaction accordingly. The only problem >> though is that my i2c controller's driver allows bytes other than the first one >> to be used to retrieve the payload length, which is incorrect according to the >> SMBus spec, and would break my i2c-hid change since not *all* of the reports >> from my touchpad are conforming SMBus block reads. >> >> This patchset fixes the I2C_M_RECV_LEN behavior in the designware i2c driver and >> modifies i2c-hid to use I2C_M_RECV_LEN to save quite a bit of power. Even if the >> peripheral controlled by i2c-hid doesn't support block reads, the i2c controller >> drivers should cope with this and proceed with the i2c transfer using the >> original requested length." > > Reviewed-by: Andy Shevchenko > for I²C DesignWare patches. > Also for i2c-designware Acked-by: Jarkko Nikula