Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp2616421ybt; Tue, 16 Jun 2020 10:23:45 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwIIoQ8ccMVqBRQliy/pBIzKStA4Mvdj+O0osXKLvM81NQMr9RBicl0Qzs6YwrDizE40TOZ X-Received: by 2002:a17:907:402e:: with SMTP id nr22mr3586370ejb.239.1592328225519; Tue, 16 Jun 2020 10:23:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1592328225; cv=none; d=google.com; s=arc-20160816; b=UCgyRm30Oos/9a/27kpJMW2ubdpsyUFsSlUveirTO63zyTsr2XQm/SPEaZak6X+dWu J1W1/bRXjPTR3anasF/9Xk3ruY2KbXha3BP6HFKq4SQdzj7AkiAmJgZ1tSIQtKOE7rjR 0Vsf14DgjTpkETetfvZcaZXn9S1HQntMBFS7I9oGvKLfWLER+o/9X7ocv/oUxuNugHvk EgtpcSOA9QyhP/18Z3IiOK36kOWCD4D8Y7oNv6MzfhHybD7vYq+XVuuG66LVsOYBM6BC 0EVsvQrQ9AYfUjeYmk30D7hb0w5xd+LMwvnXTwG1R2fGiWmK2HHWH/B2Nna+1lMySHh+ D96g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :ironport-sdr:ironport-sdr; bh=UVedXbJanURnL2a0tS0PYT8qRoz9EBn8+n/vxDrXEhI=; b=I3gcyg3pQgk6j1jsC2GaB69bMrqa4OD7sBBn+d54DtwuSOpx6C/P0PdNmoyr66n+AM rmi2LzeOqRo/5T8H2vBRP4LbPArmp7PyyjpPg/g9SLcFXu+2UCPY1QI9sTZCLgQvYrna pMvLlUZN0xUqKhxptynNKcMy1CkBstp7lYPFqdcgW8HdmMP6hMCY6kQY15RI7GT2sQQ3 JniRGz38qURm8pr3Li7EuMgVwe+ok/WSWHJpDsY1t4C2BGetr9NC3+Loqrgj8yhSdezC yiXzkFltXfab58UePBBiczI4Rq2E+UJNeftjy+FTG+otbVKc1Na6Jz46g5yHqYf7ScGt jYJQ== 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 l15si10703491ejc.97.2020.06.16.10.23.23; Tue, 16 Jun 2020 10:23:45 -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 S1728751AbgFPRTC (ORCPT + 99 others); Tue, 16 Jun 2020 13:19:02 -0400 Received: from mga11.intel.com ([192.55.52.93]:36599 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726630AbgFPRTB (ORCPT ); Tue, 16 Jun 2020 13:19:01 -0400 IronPort-SDR: Kb2nRk8r/1qvENrJmyPawleHqzB4tdft2mApEndQCe9uxR06KPXcNV8ZkvpsoUhbXz4NCPIkQi TQ/jBTZp9hDg== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Jun 2020 10:19:00 -0700 IronPort-SDR: HPPTnoVMM9cF4ZrV3z6gERadUOEYz01w9Pc8K1U0rwqGA/pHFooWfUooLD5cImk7Tkjn3gqczO P9u1ee/Ft3xw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.73,518,1583222400"; d="scan'208";a="298984794" Received: from unknown (HELO intel.com) ([10.251.95.102]) by fmsmga004.fm.intel.com with ESMTP; 16 Jun 2020 10:18:54 -0700 Date: Tue, 16 Jun 2020 20:18:54 +0300 From: Andi Shyti To: Andy Shevchenko Cc: Sultan Alsawaf , jarkko.nikula@linux.intel.com, aaron.ma@canonical.com, admin@kryma.net, benjamin.tissoires@redhat.com, hdegoede@redhat.com, hn.chen@weidahitech.com, jikos@kernel.org, kai.heng.feng@canonical.com, linux-i2c@vger.kernel.org, linux-input@vger.kernel.org, linux-kernel@vger.kernel.org, mika.westerberg@linux.intel.com, vicamo.yang@canonical.com, wsa@kernel.org Subject: Re: [PATCH v2] HID: i2c-hid: Use block reads when possible to save power Message-ID: <20200616171854.GA1415@intel.intel> References: <20200616154951.3050-1-sultan@kerneltoast.com> <20200616164101.GY2428291@smile.fi.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200616164101.GY2428291@smile.fi.intel.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Andy, > > so the only strategy available up until now has been to always retrieve > > the maximum possible report length over i2c, which can be quite > > inefficient. For devices that send reports in block read format, the i2c > > controller driver can read the payload length on the fly and terminate > > the i2c transaction early, resulting in considerable power savings. > > > > On a Dell Precision 15 5540 with an i9-9880H, resting my finger on the > > touchpad causes psys power readings to go up by about 4W and hover there > > until I remove my finger. With this patch, my psys readings go from 4.7W > > down to 3.1W, yielding about 1.6W in savings. This is because my > > touchpad's max report length is 60 bytes, but all of the regular reports > > it sends for touch events are only 32 bytes, so the i2c transfer is > > roughly halved for the common case. > > > + /* Try to do a block read if the size fits in one byte */ > > + flags = size > 255 ? I2C_M_RD : I2C_M_RD | I2C_M_RECV_LEN; > > AFAIR SMBus specification tells about 256. Why 255? > > Andi, am I correct? Actually the SMBUS 3.0 protocol from 2015[*] says 255: " D.6 255 Bytes in Process Call The maximum number of bytes allowed in the Block Write-Block Read Process Call (Section 6.5.8) was increased from 32 to 255. " But why does it matter... I see the patch is detatching itself from smbus. And, actually, I wonder if this is the right way to fix it, isn't it better to fix smbus instead? I have a patch ready that fixes the smbus transfer size, perhaps I should rebase, test and send it. Andi [*] http://smbus.org/specs/SMBus_3_0_20141220.pdf