Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp485102imm; Wed, 29 Aug 2018 05:05:36 -0700 (PDT) X-Google-Smtp-Source: ANB0Vdar8BVV9anslw3LmWE1pMBGrnVSEJwe19CBrPaptF9tEslM7XN7Rs139PeB59p4RWMmj3RK X-Received: by 2002:a17:902:4503:: with SMTP id m3-v6mr5682125pld.168.1535544336288; Wed, 29 Aug 2018 05:05:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1535544336; cv=none; d=google.com; s=arc-20160816; b=dJXL1NDIXYmAJCDI5p2k0AIjSi6uCyxxWPwsqUduchbBVbkrTywGtm3mBFIHb/OCWt yoo7Cplpi3OGIn1XQ9PZf2/OtQIw7lAlYMXGxWWhPIKQ5ir38fI+Chmz0fl0bkvboZ84 Qo2VcDVvyJgJDK0LYO9iAIh/NdEMivalQEVCig3ZyxJtAa6biNrvMiU9jKj7vj/Vo6Yt KMTdj8jbkJvz8BYgg5f//Xcss/zddZYqTS+iXmbIlj65LiP5Zyrexar432V6laSz94rw DH73MCczyiYQky10zcKqAhhNdBURVXUuRLsiWvn6FBqvMh+FSjYyQETSzydK9G55M6ai SSbA== 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 :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=QhyyQ5o8Tbf1PRCvhaTyJhFjlkhiBxtgPelayeRtD3w=; b=jTcgVJ+HI2POobtQZJf2UHcNPTWdvpYXGggCATAxiIiwbnjgs8/Ffvunak8jT5KcVm Yf/qapu9XVL51o8yH1WP/Q45Z0IrYuNADJRT+ZU6WDC7Rao6ZI0wh5FHBDomNh8RuFUv 7ryoM0TTho2zWCwm7A3mC0fdVHU8Ugva5CfNIKTKKyO/gzNMNdSqOTDDQCQUNwcx90L/ EWqGXfUzRJoTr6YVXzt0hGCkGFgF744+Hxu6GH8oGW4JJF5AAoBdnrEritVzD2j6GZbd MAtO6KbsGbNmc5Z42j0WlwxeVIPkh+Hqh0CyHYUeJQPjb20ECGr0CNduABsri/JejFou yWnA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=nxqNbVlJ; 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 q14-v6si3506937plr.510.2018.08.29.05.05.20; Wed, 29 Aug 2018 05:05:36 -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=nxqNbVlJ; 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 S1727945AbeH2QAP (ORCPT + 99 others); Wed, 29 Aug 2018 12:00:15 -0400 Received: from mail-qt0-f196.google.com ([209.85.216.196]:35852 "EHLO mail-qt0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727316AbeH2QAP (ORCPT ); Wed, 29 Aug 2018 12:00:15 -0400 Received: by mail-qt0-f196.google.com with SMTP id t5-v6so5361672qtn.3; Wed, 29 Aug 2018 05:03:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QhyyQ5o8Tbf1PRCvhaTyJhFjlkhiBxtgPelayeRtD3w=; b=nxqNbVlJUU92BbTvT8nlwsKHmPTeT8JgXq2mfIA3snNb6/eMxMa1tRERXPNnuOWoiG PhI/GyZkzeLg0Hc0pGoF0AaCOGQtgXFXGxJ4T53t8LgEdA41JB41Ct/Rddt4mjOotOb8 Oyw4ioaf2W5YgiXE+ehwd3tmfQWqpdIOMIQq8da8dWAw2F7eVhd/Wq/8S8+4+ue7nCHq +slR50cLmD6/GLvLh1FKXl86AP1CwfYtg9egyP9a9EDXUBCFX63E7nF9dfcdpV7nEunh mrw/Of0WBeuxmRNMdtcHVFxcwQaAgPZuUHgSGWIM8b5K/XUyO41NQym8t0SQwuQXNQ/M yGRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QhyyQ5o8Tbf1PRCvhaTyJhFjlkhiBxtgPelayeRtD3w=; b=q0gCQQoJVQazDGSOXtUa5sLy6zqz+UNjN62qjxynXO0J8JI4rv5Vt7bL/w+Rofi79f LTCqORUF0KGfG7wbnkbJHmMOpeS9quLtXaMas7iNOBU7s+ayA5I69iPkNJ/5EjRAlT9U h6QBGDaV01HGRQmVmqsDUyaRkjKs7T4/9TrKzpyXynTvlrfJl7ff1gV/Z7hj51Qz7e2F tUPJ8D7h/6gbgWTlneD5ZFRkL1jIzISXn5klxSIcASLq5NlPZJw0xSSkS9tY9O8GBEn5 BeCPhzw2tT0nPW4/U4ESaq64Ok6qvW2hodYIWy3yTPfkyeEiuNG0Hoypw7xa2NmuGXBV zwUg== X-Gm-Message-State: APzg51C35oWapWApwMzPHRiM4GmaFw4CQ3MbdUHvo6K/Fn9UH61Ogo6o WsmQ6VI8l7o2oO1sonrTxEbGP/RVZkvHLLmxyJk= X-Received: by 2002:ac8:350f:: with SMTP id y15-v6mr6320343qtb.241.1535544218743; Wed, 29 Aug 2018 05:03:38 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac8:471a:0:0:0:0:0 with HTTP; Wed, 29 Aug 2018 05:03:18 -0700 (PDT) In-Reply-To: <20180820234341.5271-2-jmkrzyszt@gmail.com> References: <20180813223448.21316-1-jmkrzyszt@gmail.com> <20180820234341.5271-1-jmkrzyszt@gmail.com> <20180820234341.5271-2-jmkrzyszt@gmail.com> From: Miguel Ojeda Date: Wed, 29 Aug 2018 14:03:18 +0200 Message-ID: Subject: Re: [RFC RFT PATCH v4 1/4] gpiolib: Pass bitmaps, not integer arrays, to get/set array To: Janusz Krzysztofik Cc: Linus Walleij , Jonathan Corbet , Peter Korsgaard , Peter Rosin , Ulf Hansson , Andrew Lunn , Florian Fainelli , "David S. Miller" , Dominik Brodowski , Kishon Vijay Abraham I , Lars-Peter Clausen , Michael Hennerich , Jonathan Cameron , Hartmut Knaack , Peter Meerwald-Stadler , Greg Kroah-Hartman , Jiri Slaby , linux-gpio@vger.kernel.org, Linux Doc Mailing List , linux-i2c@vger.kernel.org, linux-mmc@vger.kernel.org, Network Development , linux-iio@vger.kernel.org, devel@driverdev.osuosl.org, linux-serial@vger.kernel.org, linux-kernel , Willy Tarreau , Geert Uytterhoeven 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 Hi Janusz, On Tue, Aug 21, 2018 at 1:43 AM, Janusz Krzysztofik wrote: > Most users of get/set array functions iterate consecutive bits of data, > usually a single integer, while or processing array of results obtained > from or building an array of values to be passed to those functions. > Save time wasted on those iterations by changing the functions' API to > accept bitmaps. > > All current users are updated as well. > > More benefits from the change are expected as soon as planned support > for accepting/passing those bitmaps directly from/to respective GPIO > chip callbacks if applicable is implemented. > > Signed-off-by: Janusz Krzysztofik > --- > Documentation/driver-api/gpio/consumer.rst | 22 ++++---- > drivers/auxdisplay/hd44780.c | 52 +++++++++-------- [CC'ing Willy and Geert for hd44780] > diff --git a/drivers/auxdisplay/hd44780.c b/drivers/auxdisplay/hd44780.c > index f1a42f0f1ded..d340473aa142 100644 > --- a/drivers/auxdisplay/hd44780.c > +++ b/drivers/auxdisplay/hd44780.c > @@ -62,20 +62,19 @@ static void hd44780_strobe_gpio(struct hd44780 *hd) > /* write to an LCD panel register in 8 bit GPIO mode */ > static void hd44780_write_gpio8(struct hd44780 *hd, u8 val, unsigned int rs) > { > - int values[10]; /* for DATA[0-7], RS, RW */ > - unsigned int i, n; > + unsigned long value_bitmap[1]; /* for DATA[0-7], RS, RW */ Why [1]? I understand it is because in other cases it may be more than one, but... > + unsigned int n; > > - for (i = 0; i < 8; i++) > - values[PIN_DATA0 + i] = !!(val & BIT(i)); > - values[PIN_CTRL_RS] = rs; > + value_bitmap[0] = val; > + __assign_bit(PIN_CTRL_RS, value_bitmap, rs); > n = 9; > if (hd->pins[PIN_CTRL_RW]) { > - values[PIN_CTRL_RW] = 0; > + __clear_bit(PIN_CTRL_RW, value_bitmap); > n++; > } > > /* Present the data to the port */ > - gpiod_set_array_value_cansleep(n, &hd->pins[PIN_DATA0], values); > + gpiod_set_array_value_cansleep(n, &hd->pins[PIN_DATA0], value_bitmap); > > hd44780_strobe_gpio(hd); > } > @@ -83,32 +82,31 @@ static void hd44780_write_gpio8(struct hd44780 *hd, u8 val, unsigned int rs) > /* write to an LCD panel register in 4 bit GPIO mode */ > static void hd44780_write_gpio4(struct hd44780 *hd, u8 val, unsigned int rs) > { > - int values[10]; /* for DATA[0-7], RS, RW, but DATA[0-3] is unused */ > - unsigned int i, n; > + /* for DATA[0-7], RS, RW, but DATA[0-3] is unused */ > + unsigned long value_bitmap[0]; This one is even more strange... :-) > + unsigned int n; > > /* High nibble + RS, RW */ > - for (i = 4; i < 8; i++) > - values[PIN_DATA0 + i] = !!(val & BIT(i)); > - values[PIN_CTRL_RS] = rs; > + value_bitmap[0] = val; > + __assign_bit(PIN_CTRL_RS, value_bitmap, rs); > n = 5; > if (hd->pins[PIN_CTRL_RW]) { > - values[PIN_CTRL_RW] = 0; > + __clear_bit(PIN_CTRL_RW, value_bitmap); > n++; > } > + value_bitmap[0] = value_bitmap[0] >> PIN_DATA4; Maybe >>=? > > /* Present the data to the port */ > - gpiod_set_array_value_cansleep(n, &hd->pins[PIN_DATA4], > - &values[PIN_DATA4]); > + gpiod_set_array_value_cansleep(n, &hd->pins[PIN_DATA4], value_bitmap); > > hd44780_strobe_gpio(hd); > > /* Low nibble */ > - for (i = 0; i < 4; i++) > - values[PIN_DATA4 + i] = !!(val & BIT(i)); > + value_bitmap[0] &= ~((1 << PIN_DATA4) - 1); > + value_bitmap[0] |= val & ~((1 << PIN_DATA4) - 1); Are you sure this is correct? You are basically doing an or of value_bitmap and val and clearing the low-nibble. > > /* Present the data to the port */ > - gpiod_set_array_value_cansleep(n, &hd->pins[PIN_DATA4], > - &values[PIN_DATA4]); > + gpiod_set_array_value_cansleep(n, &hd->pins[PIN_DATA4], value_bitmap); > > hd44780_strobe_gpio(hd); > } Cheers, Miguel