| Message ID | cover.1547445576.git.vilhelm.gray@gmail.com |
|---|---|
| Headers | show |
| Series | Introduce the for_each_set_clump8 macro | expand |
On Mon, 14 Jan 2019 15:19:17 +0900 William Breathitt Gray <vilhelm.gray@gmail.com> wrote: > While adding GPIO get_multiple/set_multiple callback support for various > drivers, I noticed a pattern of looping manifesting that would be useful > standardized as a macro. > > This patchset introduces the for_each_set_clump8 macro and utilizes it > in several GPIO drivers. The for_each_set_clump macro8 facilitates a > for-loop syntax that iterates over a memory region entire groups of set > bits at a time. > > For example, suppose you would like to iterate over a 32-bit integer 8 > bits at a time, skipping over 8-bit groups with no set bit, where > XXXXXXXX represents the current 8-bit group: > > Example: 10111110 00000000 11111111 00110011 > First loop: 10111110 00000000 11111111 XXXXXXXX > Second loop: 10111110 00000000 XXXXXXXX 00110011 > Third loop: XXXXXXXX 00000000 11111111 00110011 > > Each iteration of the loop returns the next 8-bit group that has at > least one set bit. > > The for_each_set_clump8 macro has four parameters: > > * start: set to the bit offset of the current clump > * clump: set to the current clump value > * bits: bitmap to search within > * size: bitmap size in number of bits > > In this version of the patchset, the for_each_set_clump macro has been > reimplemented and simplified based on the suggestions provided by Rasmus > Villemoes and Andy Shevchenko in the version 4 submission. > > In particular, the function of the for_each_set_clump macro has been > restricted to handle only 8-bit clumps; the drivers that use the > for_each_set_clump macro only handle 8-bit ports so a generic > for_each_set_clump implementation is not necessary. Thus, a solution for > large clumps (i.e. those larger than the width of a bitmap word) can be > postponed until a driver appears that actually requires such a generic > for_each_set_clump implementation. > > For what it's worth, a semi-generic for_each_set_clump (i.e. for clumps > smaller than the width of a bitmap word) can be implemented by simply > replacing the hardcoded '8' and '0xFF' instances with respective > variables. I have not yet had a need for such an implementation, and > since it falls short of a true generic for_each_set_clump function, I > have decided to forgo such an implementation for now. > > In addition, the bitmap_get_value8 and bitmap_set_value8 functions are > introduced to get and set 8-bit values respectively. Their use is based > on the behavior suggested in the patchset version 4 review. Nice-looking code. > drivers/gpio/gpio-104-dio-48e.c | 73 ++++++-------------- > drivers/gpio/gpio-104-idi-48.c | 37 +++------- > drivers/gpio/gpio-gpio-mm.c | 73 ++++++-------------- > drivers/gpio/gpio-pci-idio-16.c | 75 ++++++++------------ > drivers/gpio/gpio-pcie-idio-24.c | 111 +++++++++++------------------- > drivers/gpio/gpio-ws16c48.c | 72 ++++++------------- > include/asm-generic/bitops/find.h | 14 ++++ > include/linux/bitops.h | 5 ++ > lib/find_bit.c | 81 ++++++++++++++++++++++ > lib/test_bitmap.c | 65 +++++++++++++++++ > 10 files changed, 307 insertions(+), 299 deletions(-) It's a shame that it doesn't actually dercease the kernel line count, but there are other benefits. The patches are missing the hoped-for acks, but I think you maintain most/all of those drivers. Do we have any expectation that these facilities will be used by anything other than GPIO? If not then perhaps they should be sited within drivers/gpio (presumably as a standalone module) until such a need is found?
On Wed, Jan 30, 2019 at 2:07 AM Andrew Morton <akpm@linux-foundation.org> wrote: > On Mon, 14 Jan 2019 15:19:17 +0900 William Breathitt Gray <vilhelm.gray@gmail.com> wrote: > > drivers/gpio/gpio-104-dio-48e.c | 73 ++++++-------------- > > drivers/gpio/gpio-104-idi-48.c | 37 +++------- > > drivers/gpio/gpio-gpio-mm.c | 73 ++++++-------------- > > drivers/gpio/gpio-pci-idio-16.c | 75 ++++++++------------ > > drivers/gpio/gpio-pcie-idio-24.c | 111 +++++++++++------------------- > > drivers/gpio/gpio-ws16c48.c | 72 ++++++------------- > > include/asm-generic/bitops/find.h | 14 ++++ > > include/linux/bitops.h | 5 ++ > > lib/find_bit.c | 81 ++++++++++++++++++++++ > > lib/test_bitmap.c | 65 +++++++++++++++++ > > 10 files changed, 307 insertions(+), 299 deletions(-) > > It's a shame that it doesn't actually dercease the kernel line count, > but there are other benefits. > > The patches are missing the hoped-for acks, but I think you maintain > most/all of those drivers. He does, but FWIW: Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Yours, Linus Walleij
On Tue, Jan 29, 2019 at 05:07:34PM -0800, Andrew Morton wrote: > Do we have any expectation that these facilities will be used by > anything other than GPIO? If not then perhaps they should be sited > within drivers/gpio (presumably as a standalone module) until such a > need is found? I can move it within drivers/gpio since my only use at moment is for these gpio drivers I maintain. However, moving it to the gpio subsystem does make it less likely to be seen by authors in other subsystems who may have use for it -- so there is the chance that this becomes isolated and untilized only amonst the gpio drivers. That may not be such a bad thing in the end; I suspect it will be easy to spot if other subsystems start implementing their own for_each_set_clump (if other subsystems would even have such a need for it). Linus, if I move the for_each_set_clump macro and related functions to drivers/gpio, should I move the code into the gpiolib.h and gpiolib.c files? Or would it be best to implement this as a separate standalone module, and make a Kconfig dependency for those gpio drivers which require it? A standalone module feels somewhat overkill for such little code in my opinion. William Breathitt Gray
On Wed, Jan 30, 2019 at 11:17 AM William Breathitt Gray <vilhelm.gray@gmail.com> wrote: > On Tue, Jan 29, 2019 at 05:07:34PM -0800, Andrew Morton wrote: > > Do we have any expectation that these facilities will be used by > > anything other than GPIO? If not then perhaps they should be sited > > within drivers/gpio (presumably as a standalone module) until such a > > need is found? > > I can move it within drivers/gpio since my only use at moment is for > these gpio drivers I maintain. However, moving it to the gpio subsystem > does make it less likely to be seen by authors in other subsystems who > may have use for it -- so there is the chance that this becomes isolated > and untilized only amonst the gpio drivers. That may not be such a bad > thing in the end; I suspect it will be easy to spot if other subsystems > start implementing their own for_each_set_clump (if other subsystems > would even have such a need for it). I would sure prefer to have these in the generic core where this patch puts them. I don't see the problem with that. We have to start generic code from some point. > Linus, if I move the for_each_set_clump macro and related functions to > drivers/gpio, should I move the code into the gpiolib.h and gpiolib.c > files? Or would it be best to implement this as a separate standalone > module, and make a Kconfig dependency for those gpio drivers which > require it? A standalone module feels somewhat overkill for such little > code in my opinion. Yeah. I was however thinking about that we should create a helper library for port-mapped IO along the lines of gpio-mmio.c so we might as well get started with that in that case, just call it gpio-port-mapped-io.c and put these in first or something. Yours, Linus Walleij
On Tue, Jan 29, 2019 at 05:07:34PM -0800, Andrew Morton wrote: > On Mon, 14 Jan 2019 15:19:17 +0900 William Breathitt Gray <vilhelm.gray@gmail.com> wrote: > It's a shame that it doesn't actually dercease the kernel line count, > but there are other benefits. > > The patches are missing the hoped-for acks, but I think you maintain > most/all of those drivers. I'm okay with the code as well, so, Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> > Do we have any expectation that these facilities will be used by > anything other than GPIO? If not then perhaps they should be sited > within drivers/gpio (presumably as a standalone module) until such a > need is found? I think I have an example out of GPIO realm. But I need time to prove that. In any case I tend to bend to the generic exposure than to local one.
Changes in v8: - Return unsigned long for bitmap_get_value8 for consistency - Add clobbering risk warning to bitmap_set_value8 documentation - Reimplement bitmap_get_value8 and bitmap_set_value8 to account for clumps that fall across bitmap word boundaries - Add a bitmap size argument to the bitmap_get_value8 and bitmap_set_value8 functions While adding GPIO get_multiple/set_multiple callback support for various drivers, I noticed a pattern of looping manifesting that would be useful standardized as a macro. This patchset introduces the for_each_set_clump8 macro and utilizes it in several GPIO drivers. The for_each_set_clump macro8 facilitates a for-loop syntax that iterates over a memory region entire groups of set bits at a time. For example, suppose you would like to iterate over a 32-bit integer 8 bits at a time, skipping over 8-bit groups with no set bit, where XXXXXXXX represents the current 8-bit group: Example: 10111110 00000000 11111111 00110011 First loop: 10111110 00000000 11111111 XXXXXXXX Second loop: 10111110 00000000 XXXXXXXX 00110011 Third loop: XXXXXXXX 00000000 11111111 00110011 Each iteration of the loop returns the next 8-bit group that has at least one set bit. The for_each_set_clump8 macro has four parameters: * start: set to the bit offset of the current clump * clump: set to the current clump value * bits: bitmap to search within * size: bitmap size in number of bits In this version of the patchset, the for_each_set_clump macro has been reimplemented and simplified based on the suggestions provided by Rasmus Villemoes and Andy Shevchenko in the version 4 submission. In particular, the function of the for_each_set_clump macro has been restricted to handle only 8-bit clumps; the drivers that use the for_each_set_clump macro only handle 8-bit ports so a generic for_each_set_clump implementation is not necessary. Thus, a solution for large clumps (i.e. those larger than the width of a bitmap word) can be postponed until a driver appears that actually requires such a generic for_each_set_clump implementation. For what it's worth, a semi-generic for_each_set_clump (i.e. for clumps smaller than the width of a bitmap word) can be implemented by simply replacing the hardcoded '8' and '0xFF' instances with respective variables. I have not yet had a need for such an implementation, and since it falls short of a true generic for_each_set_clump function, I have decided to forgo such an implementation for now. In addition, the bitmap_get_value8 and bitmap_set_value8 functions are introduced to get and set 8-bit values respectively. Their use is based on the behavior suggested in the patchset version 4 review. William Breathitt Gray (8): bitops: Introduce the for_each_set_clump8 macro lib/test_bitmap.c: Add for_each_set_clump8 test cases gpio: 104-dio-48e: Utilize for_each_set_clump8 macro gpio: 104-idi-48: Utilize for_each_set_clump8 macro gpio: gpio-mm: Utilize for_each_set_clump8 macro gpio: ws16c48: Utilize for_each_set_clump8 macro gpio: pci-idio-16: Utilize for_each_set_clump8 macro gpio: pcie-idio-24: Utilize for_each_set_clump8 macro drivers/gpio/gpio-104-dio-48e.c | 73 ++++++-------------- drivers/gpio/gpio-104-idi-48.c | 37 +++------- drivers/gpio/gpio-gpio-mm.c | 73 ++++++-------------- drivers/gpio/gpio-pci-idio-16.c | 75 ++++++++------------ drivers/gpio/gpio-pcie-idio-24.c | 111 +++++++++++------------------- drivers/gpio/gpio-ws16c48.c | 72 ++++++------------- include/asm-generic/bitops/find.h | 14 ++++ include/linux/bitops.h | 5 ++ lib/find_bit.c | 81 ++++++++++++++++++++++ lib/test_bitmap.c | 65 +++++++++++++++++ 10 files changed, 307 insertions(+), 299 deletions(-)