Received: by 10.213.65.68 with SMTP id h4csp39714imn; Wed, 21 Mar 2018 11:51:16 -0700 (PDT) X-Google-Smtp-Source: AG47ELvSBA1pELIIdKx+scfTlQGbfFxg5JtiH79z9CnFENsH0R7iDEB5Par3slMjb+weqXBBrsEt X-Received: by 10.99.143.69 with SMTP id r5mr1762457pgn.159.1521658276161; Wed, 21 Mar 2018 11:51:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521658276; cv=none; d=google.com; s=arc-20160816; b=xhFiWEgA6DKXlZoQ8AHP6tLzSUWRCof+h/Dk1DTaunsd2GU23kGqHwDMI3UeqGsJ5O 5as9U/64gPg6wXG9wbcUKZOqd//jH3QWukVJjMavs2mi27NcUfQ0HyRoWl8+o+lLZldD dWi637v3siTxOV7rUnU8AGTzEtmc4iGra+sqWVkhTzxdWuGi3VobOqNPsQk8E2zJs9v9 aZ1KbDtOAt+l6UWSo6u9IqEeKG+XliA+dKgXpMY6AcbFiN/Hp5c6sS5LaWtJK5hu5YlG MtsmBpmpKvIdxxvwe+eIGXFUXJYBeSfW54Xfo4TTo7mHOR6tkc+6PRqL7y1vh094keIO 0heQ== 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:dkim-signature:arc-authentication-results; bh=MfZS+8JnsXuyv8FuMiOFthspOxfpBbV0TEFhk/EXwaY=; b=jIxHGeSCJ4sqYdPyy27yOEEbaY61sDIzYdOMwgEIjyBERGv9Aqod7WVocw2lHHYKzT hLa3ZRAfDGrRI/2892cWzeQNtmhzMQvPp9o+DDJg6cRv5TocO5fxW/JDqmyb5yCXUhPp +lPysdyCIo+cM7fjxnNgTgoevqGCUvIvfHWoQAf9x7tj565g0npkof6ACZoG40PijW0p vWN0BGm0KmVMqCQ4ASgDZMSnTVYa9l6FfQD0r80qDEh7GBst9gbA5+V8Ae6cDU4NrR7o prV9Gp6wShgPqnOMilJnYBPqBSvQy6Hz1B+scu4KwCa/Wvzc36jXGmKVIExUk3VyiqsS X2sg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=p1tuNsVv; 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=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x16si168800pfh.76.2018.03.21.11.51.01; Wed, 21 Mar 2018 11:51:16 -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; dkim=pass header.i=@gmail.com header.s=20161025 header.b=p1tuNsVv; 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=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752873AbeCUSt7 (ORCPT + 99 others); Wed, 21 Mar 2018 14:49:59 -0400 Received: from mail-yw0-f195.google.com ([209.85.161.195]:36621 "EHLO mail-yw0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752527AbeCUSt5 (ORCPT ); Wed, 21 Mar 2018 14:49:57 -0400 Received: by mail-yw0-f195.google.com with SMTP id y64so2014165ywa.3; Wed, 21 Mar 2018 11:49:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=MfZS+8JnsXuyv8FuMiOFthspOxfpBbV0TEFhk/EXwaY=; b=p1tuNsVvVVD11gdCKPt9O/M6WQ1M4N/drnpMHYcDGVf0XnPl1moSrn9tUfV7Gmcjhe K+9dR8QjdrTqlRojpSdKlQ5M5cc2VGYdyvlwKF+AErS5PNa4XiMM0CjoVhQ2GaV+D7iR OLJnSRXMdFWl6yCWJoHKSDXwE7LnKX0ajKye3OUJsPK+4rz7wdd5j6J6yiXIeeoUDEyT Z92utfha6sIZUrU/Ivr3OwOEWo8iYO4aBqmCiSy5LBFyoVz9slNRYoVuTE95kJM1Xkg9 XekHzKooKHz8DCOz8DvbfkcP/xGlSmq9QkN9dgToII3DElu4tyXUsjCrSLZNnWjbsm9M xg/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=MfZS+8JnsXuyv8FuMiOFthspOxfpBbV0TEFhk/EXwaY=; b=nciMAKRZOGJsUVKw108GfjWpduXnxHUkUDGOtCMkqPHsVIJmJ46gebrlDzx8J+6m8x PXahPsdpp2+TGQCGePNtKzAI6roUCfs6Ae6X9jOuKz4WjAnC0apS0Eh1eeBRX2OI/WUY 7FVk5aJ1mJUDPn3p+bpvBrmZ5Mr++Z5OhJ+M5r9ypf48lYhsA8YGZYQ8tbJsI1/CoWN7 PMyqiVKXtIvOl2jyVb+A4COPOMw5v9YBQjfpsB3unXuRFmyDvuMcwdIm8Dz9dkoGqlWz /6PRtFjtxJl2w983j4WAMzZC7tDUdU4xg0ASIrw/z6t7R3ic1nChVxa3/5vQ+Yub4DXL ur6g== X-Gm-Message-State: AElRT7ErVBmzVNlgkxk/GzKFmgYlPVAxaFHIBrHfkIU+WCzma6Z+7MW4 N97tIIQLER5xumLdAd06074= X-Received: by 10.13.214.146 with SMTP id y140mr12628182ywd.434.1521658196661; Wed, 21 Mar 2018 11:49:56 -0700 (PDT) Received: from sophia ([72.188.97.40]) by smtp.gmail.com with ESMTPSA id p20sm1847587ywp.58.2018.03.21.11.49.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Mar 2018 11:49:55 -0700 (PDT) Date: Wed, 21 Mar 2018 14:49:43 -0400 From: William Breathitt Gray To: Andy Shevchenko Cc: Linus Walleij , "open list:GPIO SUBSYSTEM" , Linux Kernel Mailing List , linux-iio@vger.kernel.org Subject: Re: [PATCH v3 3/8] gpio: pci-idio-16: Implement get_multiple callback Message-ID: <20180321184943.GA24015@sophia> References: <6ca4bf0ed930c057bdbcd07bab34ed0a474dd78d.1521301345.git.vilhelm.gray@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 21, 2018 at 07:45:29PM +0200, Andy Shevchenko wrote: >On Sat, Mar 17, 2018 at 5:50 PM, William Breathitt Gray > wrote: >> The ACCES I/O PCI-IDIO-16 series of devices provides 16 >> optically-isolated digital inputs accessed via two 8-bit ports. Since >> eight input lines are acquired on a single port input read, the >> PCI-IDIO-16 GPIO driver may improve multiple input reads by utilizing a >> get_multiple callback. This patch implements the >> idio_16_gpio_get_multiple function which serves as the respective >> get_multiple callback. > >> +static int idio_16_gpio_get_multiple(struct gpio_chip *chip, >> + unsigned long *mask, unsigned long *bits) >> +{ >> + struct idio_16_gpio *const idio16gpio = gpiochip_get_data(chip); >> + size_t i; >> + const unsigned int gpio_reg_size = 8; >> + unsigned int bits_offset; >> + size_t word_index; >> + unsigned int word_offset; >> + unsigned long word_mask; > >> + const unsigned long port_mask = GENMASK(gpio_reg_size, 0); > >gpio_reg_size - 1? Oops, looks like I made an off-by-one error here so I'll make sure to fix that up. >Though I would prefer not to have that variable at all, just use 8 or >7 respectively. This device is simple enough that throughout this function I could inline gpio_reg_size and port_mask to 8 and 0xFF respectively, but I would like to keep the code generic enough for reuse in other drivers. In addition, I believe the variable names help keep the intention of the code clear, so I'll stick with dedicated const variables for now if there are no other objections. > >> + unsigned long port_state; > >> + u8 __iomem ports[] = { >> + idio16gpio->reg->out0_7, idio16gpio->reg->out8_15, > >> + idio16gpio->reg->in0_7, idio16gpio->reg->in8_15 > >I would leave comma even here. Will do. > >> + }; > >> + /* get bits are evaluated a gpio port register at a time */ >> + for (i = 0; i < ARRAY_SIZE(ports); i++) { >> + /* gpio offset in bits array */ >> + bits_offset = i * gpio_reg_size; >> + >> + /* word index for bits array */ >> + word_index = BIT_WORD(bits_offset); >> + >> + /* gpio offset within current word of bits array */ >> + word_offset = bits_offset % BITS_PER_LONG; >> + >> + /* mask of get bits for current gpio within current word */ >> + word_mask = mask[word_index] & (port_mask << word_offset); >> + if (!word_mask) { >> + /* no get bits in this port so skip to next one */ >> + continue; >> + } >> + >> + /* read bits from current gpio port */ >> + port_state = ioread8(ports + i); >> + >> + /* store acquired bits at respective bits array offset */ >> + bits[word_index] |= port_state << word_offset; >> + } > >I would propose to do other way around, i.e. >read all ports to the bitmap array and call bitmap_and() after. > >Further optimization can be something like introduction of generic > >bitmap_copy_uXX_off(unsigned long *dst, u8 src, unsigned int offset); > >It can be done using macros, though it's another story not quite >related to the topic. Port I/O is significantly more costly to perform than the bitmask evaluations for each port. Despite the increased complexity of the loop logic, I believe the latency improvements of skipping unnecessary I/O port reads are worth the trouble. I do like the idea of a bitmap_copy_uXX_off macro as that could be quite useful in general. Even if not for this particular patchset, I would be interested in seeing that functionality added to the bitmap API. Perhaps I might implement it as a standlone patch when I have some free time. William Breathitt Gray > >> +} > >-- >With Best Regards, >Andy Shevchenko