Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp1379739imm; Tue, 5 Jun 2018 13:41:20 -0700 (PDT) X-Google-Smtp-Source: ADUXVKJTWyRXDaydUyQkJhzyvWFyKMPjTFoREJk0Fq2IfzR5wYEFJMBxK6mRM4oTXgN/YCypTt+l X-Received: by 2002:a17:902:6bc1:: with SMTP id m1-v6mr153859plt.91.1528231280767; Tue, 05 Jun 2018 13:41:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528231280; cv=none; d=google.com; s=arc-20160816; b=EaffqmrG7T7+u67C8EJziPjoTlE3wXR9d2U11fT/zIHuySR+U4ds/aa2Gzd7aoSI/0 9+ar19+EXLDHHmXDXNzWdZIbyo2osHhQ5adsPDZABEmRa+C5IY3PU4j5bxCxaPW1Ac4F Oq/fkVDhF7na578dxrcIACKQ9NWjyTt+Swhya9D3ryF5UqyEc5j8CPJZWgfdaqRbcuhP DpU5MXi1Rt5vhQizTV2I2k/q8copKbxEm1lMTT/srFcUH6xcleqX9iPXt5yMJ8ke6kkh vuCKcgMgpwIc2UNsMpAeHaIRSLCvzUlyHpYvhCi2apc+zI+VVj0WGE09/WDKannI6rs7 Qo+Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=9nNcBl1qGnwYZr5pKKD+5oG7LIxjHjeI7Z69icT0Cwc=; b=To/MulcGAE1lk7V4nN6UeugPVYZP7wo5mTB2Pv23jzZj68R9BZqaJiM54Fo2OudK9F QRRke54K9HQFPcSYxHpszG9be/JlYN7oV+Xo2iCkEBhAg2oY20NLcnLNaSrHIP2otmWp K3POOYYkftkLNIQoZKaZbNJwIC2iCVWNYXc3czj10a6pkYjhQslnFDmuO2VYEVJlyI6J ggKzyy/e3y3sznUiAbjXAtXoXfX1rMT0SvtccoVm/yjiKMNTrDgnI5P37SjtMMRHemuV 8gCbdbJ9H9QTj4fgsdMdzgmgd3kfwARpz7C7S+Eeo9gAw81BFUK8Bi2IGsPVYbI4zYYH eAeQ== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q6-v6si24808840plr.134.2018.06.05.13.40.55; Tue, 05 Jun 2018 13:41:20 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752637AbeFEUjr (ORCPT + 99 others); Tue, 5 Jun 2018 16:39:47 -0400 Received: from atrey.karlin.mff.cuni.cz ([195.113.26.193]:50091 "EHLO atrey.karlin.mff.cuni.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751950AbeFEUjo (ORCPT ); Tue, 5 Jun 2018 16:39:44 -0400 Received: by atrey.karlin.mff.cuni.cz (Postfix, from userid 512) id 30318805FE; Tue, 5 Jun 2018 22:39:42 +0200 (CEST) Date: Tue, 5 Jun 2018 22:39:41 +0200 From: Pavel Machek To: Andy Shevchenko Cc: "H. Nikolaus Schaller" , Kumar Gala , Rob Herring , Pawel Moll , Mark Rutland , Ian Campbell , Linus Walleij , Alexandre Courbot , devicetree , "open list:GPIO SUBSYSTEM" , Linux Kernel Mailing List , Discussions about the Letux Kernel , kernel@pyra-handheld.com Subject: Re: [PATCH v7 3/3] gpio: pca953x: fix address calculation for pcal6524 Message-ID: <20180605203941.GA28143@amd> References: <20180523140635.GB27215@amd> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="d6Gm4EdcadzBjdND" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --d6Gm4EdcadzBjdND Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue 2018-06-05 18:37:21, Andy Shevchenko wrote: > On Wed, May 23, 2018 at 5:06 PM, Pavel Machek wrote: > > On Thu 2018-05-17 06:59:49, H. Nikolaus Schaller wrote: > >> The register constants are so far defined in a way that they fit > >> for the pcal9555a when shifted by the number of banks, i.e. are > >> multiplied by 2 in the accessor function. > >> > >> Now, the pcal6524 has 3 banks which means the relative offset > >> is multiplied by 4 for the standard registers. > >> > >> Simply applying the bit shift to the extended registers gives > >> a wrong result, since the base offset is already included in > >> the offset. > >> > >> Therefore, we have to add code to the 24 bit accessor functions > >> that adjusts the register number for these exended registers. > >> > >> The formula finally used was developed and proposed by > >> Andy Shevchenko . >=20 > >> int bank_shift =3D fls((chip->gpio_chip.ngpio - 1) / BANK_SZ); > >> + int addr =3D (reg & PCAL_GPIO_MASK) << bank_shift; > >> + int pinctrl =3D (reg & PCAL_PINCTRL_MASK) << 1; >=20 > > Is this reasonable to do on each register access? Compiler will not be > > able to optimize out fls and shifts, right? >=20 > On modern CPUs fls() is one assembly command. OTOH, any proposal to do > this better? >=20 > What I can see is that bank_shift is invariant to the function, and > maybe cached. Yes, I thought that caching bank_shift might be good idea. I thought it was constant for given chip... Best regards, Pavel --=20 (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blo= g.html --d6Gm4EdcadzBjdND Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlsW9Q0ACgkQMOfwapXb+vLnsACfXGg75eku2hgA21L/7YAzxPdY nVUAnjrmbHRLIqtsz2vg2HQKeWmv0oei =E2tb -----END PGP SIGNATURE----- --d6Gm4EdcadzBjdND--