summaryrefslogtreecommitdiffstats
path: root/Documentation/driver-api
diff options
context:
space:
mode:
authorJanusz Krzysztofik <jmkrzyszt@gmail.com>2018-09-24 01:53:36 +0200
committerLinus Walleij <linus.walleij@linaro.org>2018-09-24 13:47:05 +0200
commitc4c958aa64f31a962ddfdfb2ea628a25c774df25 (patch)
tree6ba8ca87ceb9b96541f1a91a5a86ff2158e9a514 /Documentation/driver-api
parent35ae7f9694e3c059a9d6a6049c7c171c8233c0c9 (diff)
downloadlinux-stable-c4c958aa64f31a962ddfdfb2ea628a25c774df25.tar.gz
linux-stable-c4c958aa64f31a962ddfdfb2ea628a25c774df25.tar.bz2
linux-stable-c4c958aa64f31a962ddfdfb2ea628a25c774df25.zip
gpiolib: Fix array members of same chip processed separately
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 <corbet@lwn.net> Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Diffstat (limited to 'Documentation/driver-api')
-rw-r--r--Documentation/driver-api/gpio/board.rst19
1 files changed, 14 insertions, 5 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.