From patchwork Sun Sep 23 23:53:36 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Janusz Krzysztofik X-Patchwork-Id: 10611877 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id EB20513A4 for ; Sun, 23 Sep 2018 23:52:49 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id D65AC29D49 for ; Sun, 23 Sep 2018 23:52:49 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id C818029D4E; Sun, 23 Sep 2018 23:52:49 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.0 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI autolearn=unavailable version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 4970729D49 for ; Sun, 23 Sep 2018 23:52:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727363AbeIXFwJ (ORCPT ); Mon, 24 Sep 2018 01:52:09 -0400 Received: from mail-lj1-f196.google.com ([209.85.208.196]:32857 "EHLO mail-lj1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725919AbeIXFwH (ORCPT ); Mon, 24 Sep 2018 01:52:07 -0400 Received: by mail-lj1-f196.google.com with SMTP id l19-v6so2154537ljb.0; Sun, 23 Sep 2018 16:52:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=u/WVvvps4INqy3Y40qi5MvRWOHI2pdz+3o9vxbYSDG4=; b=S6FVd2BHYu/2b5qMyaKN6G+hqztoSPL88+3ZnsvAf8NybeBq4HEm31x2X3UwHKteXk oQ3weBnxNtYanLb6pxQE2hxtLJb+fcG4jTHt9VpOZZZpUk75CnRN/0RuiDZtZJkUlnh0 u6V1XZemC/yRgpcBPKv2TrKJEl7X7X5nFAV9ikhgL7nCwyizeqsNEsiTX8/vyDuYdnlo I9ibtVqthDGnMncHUoArsAlymsE6RGUT0hsPTGIWtM1barov9IFV0y1DTzCDHmIyhCYv ASa758NbQ6GgtuR2QG2M+OhvLzk9Qc+/xYkuVRVPc/lGaf0daZCHtz2duyp9aTjZtrOC N4uw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=u/WVvvps4INqy3Y40qi5MvRWOHI2pdz+3o9vxbYSDG4=; b=lfFnfPIsB5DKg2AvGBdAIEmCVHby0ygJ2tvka3Vhd++b9XVpsAIgAKC7Dn1vR/IOrs XN5gPjl0RyD1WI+9oDewkIDbtJ2KKgAuNRXVRNFVBs3PdyIRwhpyrGC/1TikjztuSXxY KhnVDFLBmvwhQh9ASNjb8liH07XaeUoEzymIcrhIGm5nY5SjhH4hJ7fzhsCbYFDzhvhM yMQDC6ZdSuTigNZrQcisTjs7gFZGE539CacSE3y7/wHUlgaZV8SaD/SCgfctlzLzE6Fe dKr2qSY+BM+LFn+M+0g2A3muogJjC+z8NCWupeFjX4NsvEF+EwLuforHTJK9U0xGuhbo 7JRw== X-Gm-Message-State: APzg51Ceg92PlnG/wfvHnRUNYt3px0vPAZGuMcEXYbSuxm0hyIBnwig9 uLtQxsY5a8VxkfwnJ7EKwqU= X-Google-Smtp-Source: ACcGV612QnapKQBiKaGACwYISbJFvvjzlmvMHhe0tAiURUYc1VxJFw8bzDs1wDM+CBSISWwbkiCXkw== X-Received: by 2002:a2e:947:: with SMTP id 68-v6mr8393674ljj.1.1537746755828; Sun, 23 Sep 2018 16:52:35 -0700 (PDT) Received: from z50.lan (93-181-165-181.internetia.net.pl. [93.181.165.181]) by smtp.gmail.com with ESMTPSA id m8-v6sm3419718lfh.25.2018.09.23.16.52.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 23 Sep 2018 16:52:35 -0700 (PDT) From: Janusz Krzysztofik To: Linus Walleij Cc: Jonathan Corbet , Miguel Ojeda Sandonis , Peter Korsgaard , Peter Rosin , Ulf Hansson , Andrew Lunn , Florian Fainelli , "David S. Miller" , Dominik Brodowski , Greg Kroah-Hartman , Kishon Vijay Abraham I , Lars-Peter Clausen , Michael Hennerich , Jonathan Cameron , Hartmut Knaack , Peter Meerwald-Stadler , Jiri Slaby , Willy Tarreau , Geert Uytterhoeven , Sebastien Bourdelin , Lukas Wunner , Rojhalat Ibrahim , Russell King , Tony Lindgren , Yegor Yefremov , =?utf-8?q?Uwe_Kleine-K=C3=B6ni?= =?utf-8?q?g?= , Janusz Krzysztofik , linux-doc@vger.kernel.org, linux-i2c@vger.kernel.org, linux-mmc@vger.kernel.org, netdev@vger.kernel.org, linux-iio@vger.kernel.org, devel@driverdev.osuosl.org, linux-serial@vger.kernel.org, linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org, Marek Szyprowski , Krzysztof Kozlowski , Linux Samsung SOC Subject: [PATCH 2/2] gpiolib: Fix array members of same chip processed separately Date: Mon, 24 Sep 2018 01:53:36 +0200 Message-Id: <20180923235336.22148-3-jmkrzyszt@gmail.com> X-Mailer: git-send-email 2.16.4 In-Reply-To: <20180923235336.22148-1-jmkrzyszt@gmail.com> References: <2785169.v6aIfS3K2k@z50> <20180923235336.22148-1-jmkrzyszt@gmail.com> Sender: linux-iio-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-iio@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP New code introduced by commit bf9346f5d47b ("gpiolib: Identify arrays matching GPIO hardware") forcibly tries to find an array member which has its array index number equal to its hardware pin number and set up an array info for possible fast bitmap processing of all arrray pins belonging to that chip which also satisfy that numbering rule. Depending on array content, it may happen that consecutive array members which belong to the same chip but don't have array indexes equal to their pin hardware numbers will be split into groups, some of them processed together via the fast bitmap path, and rest of them separetely. However, applications may expect all those pins being processed together with a single call to .set_multiple() chip callback, like that was done before the change. Limit applicability of fast bitmap processing path to cases where all pins of consecutive array members starting from 0 which belong to the same chip have their hardware numbers equal to their corresponding array indexes. That should still speed up processing of applications using whole GPIO banks as I/O ports, while not breaking simultaneous manipulation of consecutive pins of the same chip which don't follow the equal numbering rule. Cc: Jonathan Corbet Signed-off-by: Janusz Krzysztofik --- Documentation/driver-api/gpio/board.rst | 19 +++++++++++++----- drivers/gpio/gpiolib.c | 35 +++++++++++++++++++++++---------- 2 files changed, 39 insertions(+), 15 deletions(-) diff --git a/Documentation/driver-api/gpio/board.rst b/Documentation/driver-api/gpio/board.rst index c66821e033c2..a0f294e2e250 100644 --- a/Documentation/driver-api/gpio/board.rst +++ b/Documentation/driver-api/gpio/board.rst @@ -202,9 +202,18 @@ mapped to the device determines if the array qualifies for fast bitmap processing. If yes, a bitmap is passed over get/set array functions directly between a caller and a respective .get/set_multiple() callback of a GPIO chip. -In order to qualify for fast bitmap processing, the pin mapping must meet the +In order to qualify for fast bitmap processing, the array must meet the following requirements: -- it must belong to the same chip as other 'fast' pins of the function, -- its index within the function must match its hardware number within the chip. - -Open drain and open source pins are excluded from fast bitmap output processing. +- pin hardware number of array member 0 must also be 0, +- pin hardware numbers of consecutive array members which belong to the same + chip as member 0 does must also match their array indexes. + +Otherwise fast bitmap processing path is not used in order to avoid consecutive +pins which belong to the same chip but are not in hardware order being processed +separately. + +If the array applies for fast bitmap processing path, pins which belong to +different chips than member 0 does, as well as those with indexes different from +their hardware pin numbers, are excluded from the fast path, both input and +output. Moreover, open drain and open source pins are excluded from fast bitmap +output processing. diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c index 7d9536a79a66..6ae13e3e05f1 100644 --- a/drivers/gpio/gpiolib.c +++ b/drivers/gpio/gpiolib.c @@ -4376,11 +4376,10 @@ struct gpio_descs *__must_check gpiod_get_array(struct device *dev, chip = gpiod_to_chip(desc); /* - * Select a chip of first array member - * whose index matches its pin hardware number - * as a candidate for fast bitmap processing. + * If pin hardware number of array member 0 is also 0, select + * its chip as a candidate for fast bitmap processing path. */ - if (!array_info && gpio_chip_hwgpio(desc) == descs->ndescs) { + if (descs->ndescs == 0 && gpio_chip_hwgpio(desc) == 0) { struct gpio_descs *array; bitmap_size = BITS_TO_LONGS(chip->ngpio > count ? @@ -4414,14 +4413,30 @@ struct gpio_descs *__must_check gpiod_get_array(struct device *dev, count - descs->ndescs); descs->info = array_info; } - /* - * Unmark members which don't qualify for fast bitmap - * processing (different chip, not in hardware order) - */ - if (array_info && (chip != array_info->chip || - gpio_chip_hwgpio(desc) != descs->ndescs)) { + /* Unmark array members which don't belong to the 'fast' chip */ + if (array_info && array_info->chip != chip) { __clear_bit(descs->ndescs, array_info->get_mask); __clear_bit(descs->ndescs, array_info->set_mask); + } + /* + * Detect array members which belong to the 'fast' chip + * but their pins are not in hardware order. + */ + else if (array_info && + gpio_chip_hwgpio(desc) != descs->ndescs) { + /* + * Don't use fast path if all array members processed so + * far belong to the same chip as this one but its pin + * hardware number is different from its array index. + */ + if (bitmap_full(array_info->get_mask, descs->ndescs)) { + array_info = NULL; + } else { + __clear_bit(descs->ndescs, + array_info->get_mask); + __clear_bit(descs->ndescs, + array_info->set_mask); + } } else if (array_info) { /* Exclude open drain or open source from fast output */ if (gpiochip_line_is_open_drain(chip, descs->ndescs) ||