[PATCH v5 0/4] Introduce the for_each_set_clump macro

[PATCH v5 0/4] Introduce the for_each_set_clump macro

[Syed Nayyar Waris]

This patchset introduces a new generic version of for_each_set_clump. 
The previous version of for_each_set_clump8 used a fixed size 8-bit
clump, but the new generic version can work with clump of any size but
less than or equal to BITS_PER_LONG. The patchset utilizes the new macro 
in several GPIO drivers.

The earlier 8-bit for_each_set_clump8 facilitated 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.

But with the new for_each_set_clump the clump size can be different from 8 bits.
Moreover, the clump can be split at word boundary in situations where word 
size is not multiple of clump size. Following are examples showing the working 
of new macro for clump sizes of 24 bits and 6 bits.

Example 1:
clump size: 24 bits, Number of clumps (or ports): 10
bitmap stores the bit information from where successive clumps are retrieved.

     /* bitmap memory region */
        0x00aa0000ff000000;  /* Most significant bits */
        0xaaaaaa0000ff0000;
        0x000000aa000000aa;
        0xbbbbabcdeffedcba;  /* Least significant bits */

Different iterations of for_each_set_clump:-
'offset' is the bit position and 'clump' is the 24 bit clump from the
above bitmap.
Iteration first:        offset: 0 clump: 0xfedcba
Iteration second:       offset: 24 clump: 0xabcdef
Iteration third:        offset: 48 clump: 0xaabbbb
Iteration fourth:       offset: 96 clump: 0xaa
Iteration fifth:        offset: 144 clump: 0xff
Iteration sixth:        offset: 168 clump: 0xaaaaaa
Iteration seventh:      offset: 216 clump: 0xff
Loop breaks because in the end the remaining bits (0x00aa) size was less
than clump size of 24 bits.

In above example it can be seen that in iteration third, the 24 bit clump
that was retrieved was split between bitmap[0] and bitmap[1]. This example 
also shows that 24 bit zeroes if present in between, were skipped (preserving
the previous for_each_set_macro8 behaviour). 

Example 2:
clump size = 6 bits, Number of clumps (or ports) = 3.

     /* bitmap memory region */
        0x00aa0000ff000000;  /* Most significant bits */
        0xaaaaaa0000ff0000;
        0x0f00000000000000;
        0x0000000000000ac0;  /* Least significant bits */

Different iterations of for_each_set_clump:
'offset' is the bit position and 'clump' is the 6 bit clump from the
above bitmap.
Iteration first:        offset: 6 clump: 0x2b
Loop breaks because 6 * 3 = 18 bits traversed in bitmap.
Here 6 * 3 is clump size * no. of clumps.

Changes in v5:
 - [Patch 4/4]: Minor change: Hardcode value for better code readability.

Changes in v4:
 - [Patch 2/4]: Use 'for' loop in test function of for_each_set_clump.
 - [Patch 3/4]: Minor change: Hardcode value for better code readability.
 - [Patch 4/4]: Minor change: Hardcode value for better code readability.

Changes in v3:
 - [Patch 3/4]: Change datatype of some variables from u64 to unsigned long
   in function thunderx_gpio_set_multiple.

CHanges in v2:
 - [Patch 2/4]: Unify different tests for 'for_each_set_clump'. Pass test data as
   function parameters.
 - [Patch 2/4]: Remove unnecessary bitmap_zero calls.

Syed Nayyar Waris (4):
  bitops: Introduce the the for_each_set_clump macro
  lib/test_bitmap.c: Add for_each_set_clump test cases
  gpio: thunderx: Utilize for_each_set_clump macro
  gpio: xilinx: Utilize for_each_set_clump macro

 drivers/gpio/gpio-thunderx.c      |  11 ++-
 drivers/gpio/gpio-xilinx.c        |  62 ++++++-------
 include/asm-generic/bitops/find.h |  19 ++++
 include/linux/bitmap.h            |  61 +++++++++++++
 include/linux/bitops.h            |  13 +++
 lib/find_bit.c                    |  14 +++
 lib/test_bitmap.c                 | 141 ++++++++++++++++++++++++++++++
 7 files changed, 287 insertions(+), 34 deletions(-)


base-commit: 25c04a75f14fdc074d7dd1d6d40b49eddd0e66e7
-- 
2.26.2

[PATCH v5 0/4] Introduce the for_each_set_clump macro

[Syed Nayyar Waris]

This patchset introduces a new generic version of for_each_set_clump. 
The previous version of for_each_set_clump8 used a fixed size 8-bit
clump, but the new generic version can work with clump of any size but
less than or equal to BITS_PER_LONG. The patchset utilizes the new macro 
in several GPIO drivers.

The earlier 8-bit for_each_set_clump8 facilitated 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.

But with the new for_each_set_clump the clump size can be different from 8 bits.
Moreover, the clump can be split at word boundary in situations where word 
size is not multiple of clump size. Following are examples showing the working 
of new macro for clump sizes of 24 bits and 6 bits.

Example 1:
clump size: 24 bits, Number of clumps (or ports): 10
bitmap stores the bit information from where successive clumps are retrieved.

     /* bitmap memory region */
        0x00aa0000ff000000;  /* Most significant bits */
        0xaaaaaa0000ff0000;
        0x000000aa000000aa;
        0xbbbbabcdeffedcba;  /* Least significant bits */

Different iterations of for_each_set_clump:-
'offset' is the bit position and 'clump' is the 24 bit clump from the
above bitmap.
Iteration first:        offset: 0 clump: 0xfedcba
Iteration second:       offset: 24 clump: 0xabcdef
Iteration third:        offset: 48 clump: 0xaabbbb
Iteration fourth:       offset: 96 clump: 0xaa
Iteration fifth:        offset: 144 clump: 0xff
Iteration sixth:        offset: 168 clump: 0xaaaaaa
Iteration seventh:      offset: 216 clump: 0xff
Loop breaks because in the end the remaining bits (0x00aa) size was less
than clump size of 24 bits.

In above example it can be seen that in iteration third, the 24 bit clump
that was retrieved was split between bitmap[0] and bitmap[1]. This example 
also shows that 24 bit zeroes if present in between, were skipped (preserving
the previous for_each_set_macro8 behaviour). 

Example 2:
clump size = 6 bits, Number of clumps (or ports) = 3.

     /* bitmap memory region */
        0x00aa0000ff000000;  /* Most significant bits */
        0xaaaaaa0000ff0000;
        0x0f00000000000000;
        0x0000000000000ac0;  /* Least significant bits */

Different iterations of for_each_set_clump:
'offset' is the bit position and 'clump' is the 6 bit clump from the
above bitmap.
Iteration first:        offset: 6 clump: 0x2b
Loop breaks because 6 * 3 = 18 bits traversed in bitmap.
Here 6 * 3 is clump size * no. of clumps.

Changes in v5:
 - [Patch 4/4]: Minor change: Hardcode value for better code readability.

Changes in v4:
 - [Patch 2/4]: Use 'for' loop in test function of for_each_set_clump.
 - [Patch 3/4]: Minor change: Hardcode value for better code readability.
 - [Patch 4/4]: Minor change: Hardcode value for better code readability.

Changes in v3:
 - [Patch 3/4]: Change datatype of some variables from u64 to unsigned long
   in function thunderx_gpio_set_multiple.

CHanges in v2:
 - [Patch 2/4]: Unify different tests for 'for_each_set_clump'. Pass test data as
   function parameters.
 - [Patch 2/4]: Remove unnecessary bitmap_zero calls.

Syed Nayyar Waris (4):
  bitops: Introduce the the for_each_set_clump macro
  lib/test_bitmap.c: Add for_each_set_clump test cases
  gpio: thunderx: Utilize for_each_set_clump macro
  gpio: xilinx: Utilize for_each_set_clump macro

 drivers/gpio/gpio-thunderx.c      |  11 ++-
 drivers/gpio/gpio-xilinx.c        |  62 ++++++-------
 include/asm-generic/bitops/find.h |  19 ++++
 include/linux/bitmap.h            |  61 +++++++++++++
 include/linux/bitops.h            |  13 +++
 lib/find_bit.c                    |  14 +++
 lib/test_bitmap.c                 | 141 ++++++++++++++++++++++++++++++
 7 files changed, 287 insertions(+), 34 deletions(-)


base-commit: 25c04a75f14fdc074d7dd1d6d40b49eddd0e66e7
-- 
2.26.2


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v5 1/4] bitops: Introduce the the for_each_set_clump macro

[Syed Nayyar Waris]

This macro iterates for each group of bits (clump) with set bits,
within a bitmap memory region. For each iteration, "start" is set to
the bit offset of the found clump, while the respective clump value is
stored to the location pointed by "clump". Additionally, the
bitmap_get_value and bitmap_set_value functions are introduced to
respectively get and set a value of n-bits in a bitmap memory region.
The n-bits can have any size less than or equal to BITS_PER_LONG.
Moreover, during setting value of n-bit in bitmap, if a situation arise
that the width of next n-bit is exceeding the word boundary, then it
will divide itself such that some portion of it is stored in that word,
while the remaining portion is stored in the next higher word. Similar
situation occurs while retrieving value of n-bits from bitmap.

Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Syed Nayyar Waris <syednwaris@gmail.com>
Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
---
Changes in v5:
 - No change.

Changes in v4:
 - No change

Changes in v3:
 - No change

Changes in v2:
 - No change

 include/asm-generic/bitops/find.h | 19 ++++++++++
 include/linux/bitmap.h            | 61 +++++++++++++++++++++++++++++++
 include/linux/bitops.h            | 13 +++++++
 lib/find_bit.c                    | 14 +++++++
 4 files changed, 107 insertions(+)

diff --git a/include/asm-generic/bitops/find.h b/include/asm-generic/bitops/find.h
index 9fdf21302fdf..4e6600759455 100644
--- a/include/asm-generic/bitops/find.h
+++ b/include/asm-generic/bitops/find.h
@@ -97,4 +97,23 @@ extern unsigned long find_next_clump8(unsigned long *clump,
 #define find_first_clump8(clump, bits, size) \
 	find_next_clump8((clump), (bits), (size), 0)
 
+/**
+ * find_next_clump - find next clump with set bits in a memory region
+ * @clump: location to store copy of found clump
+ * @addr: address to base the search on
+ * @size: bitmap size in number of bits
+ * @offset: bit offset at which to start searching
+ * @clump_size: clump size in bits
+ *
+ * Returns the bit offset for the next set clump; the found clump value is
+ * copied to the location pointed by @clump. If no bits are set, returns @size.
+ */
+extern unsigned long find_next_clump(unsigned long *clump,
+				      const unsigned long *addr,
+				      unsigned long size, unsigned long offset,
+				      unsigned long clump_size);
+
+#define find_first_clump(clump, bits, size, clump_size) \
+	find_next_clump((clump), (bits), (size), 0, (clump_size))
+
 #endif /*_ASM_GENERIC_BITOPS_FIND_H_ */
diff --git a/include/linux/bitmap.h b/include/linux/bitmap.h
index 99058eb81042..7ab2c65fc964 100644
--- a/include/linux/bitmap.h
+++ b/include/linux/bitmap.h
@@ -75,7 +75,11 @@
  *  bitmap_from_arr32(dst, buf, nbits)          Copy nbits from u32[] buf to dst
  *  bitmap_to_arr32(buf, src, nbits)            Copy nbits from buf to u32[] dst
  *  bitmap_get_value8(map, start)               Get 8bit value from map at start
+ *  bitmap_get_value(map, start, nbits)		Get bit value of size
+ *						'nbits' from map at start
  *  bitmap_set_value8(map, value, start)        Set 8bit value to map at start
+ *  bitmap_set_value(map, value, start, nbits)	Set bit value of size 'nbits'
+ *						of map at start
  *
  * Note, bitmap_zero() and bitmap_fill() operate over the region of
  * unsigned longs, that is, bits behind bitmap till the unsigned long
@@ -563,6 +567,34 @@ static inline unsigned long bitmap_get_value8(const unsigned long *map,
 	return (map[index] >> offset) & 0xFF;
 }
 
+/**
+ * bitmap_get_value - get a value of n-bits from the memory region
+ * @map: address to the bitmap memory region
+ * @start: bit offset of the n-bit value
+ * @nbits: size of value in bits
+ *
+ * Returns value of nbits located at the @start bit offset within the @map
+ * memory region.
+ */
+static inline unsigned long bitmap_get_value(const unsigned long *map,
+					      unsigned long start,
+					      unsigned long nbits)
+{
+	const size_t index = BIT_WORD(start);
+	const unsigned long offset = start % BITS_PER_LONG;
+	const unsigned long ceiling = roundup(start + 1, BITS_PER_LONG);
+	const unsigned long space = ceiling - start;
+	unsigned long value_low, value_high;
+
+	if (space >= nbits)
+		return (map[index] >> offset) & GENMASK(nbits - 1, 0);
+	else {
+		value_low = map[index] & BITMAP_FIRST_WORD_MASK(start);
+		value_high = map[index + 1] & BITMAP_LAST_WORD_MASK(start + nbits);
+		return (value_low >> offset) | (value_high << space);
+	}
+}
+
 /**
  * bitmap_set_value8 - set an 8-bit value within a memory region
  * @map: address to the bitmap memory region
@@ -579,6 +611,35 @@ static inline void bitmap_set_value8(unsigned long *map, unsigned long value,
 	map[index] |= value << offset;
 }
 
+/**
+ * bitmap_set_value - set n-bit value within a memory region
+ * @map: address to the bitmap memory region
+ * @value: value of nbits
+ * @start: bit offset of the n-bit value
+ * @nbits: size of value in bits
+ */
+static inline void bitmap_set_value(unsigned long *map,
+				    unsigned long value,
+				    unsigned long start, unsigned long nbits)
+{
+	const size_t index = BIT_WORD(start);
+	const unsigned long offset = start % BITS_PER_LONG;
+	const unsigned long ceiling = roundup(start + 1, BITS_PER_LONG);
+	const unsigned long space = ceiling - start;
+
+	value &= GENMASK(nbits - 1, 0);
+
+	if (space >= nbits) {
+		map[index] &= ~(GENMASK(nbits + offset - 1, offset));
+		map[index] |= value << offset;
+	} else {
+		map[index] &= ~BITMAP_FIRST_WORD_MASK(start);
+		map[index] |= value << offset;
+		map[index + 1] &= ~BITMAP_LAST_WORD_MASK(start + nbits);
+		map[index + 1] |= (value >> space);
+	}
+}
+
 #endif /* __ASSEMBLY__ */
 
 #endif /* __LINUX_BITMAP_H */
diff --git a/include/linux/bitops.h b/include/linux/bitops.h
index 9acf654f0b19..41c2d9ce63e7 100644
--- a/include/linux/bitops.h
+++ b/include/linux/bitops.h
@@ -62,6 +62,19 @@ extern unsigned long __sw_hweight64(__u64 w);
 	     (start) < (size); \
 	     (start) = find_next_clump8(&(clump), (bits), (size), (start) + 8))
 
+/**
+ * for_each_set_clump - iterate over bitmap for each clump with set bits
+ * @start: bit offset to start search and to store the current iteration offset
+ * @clump: location to store copy of current 8-bit clump
+ * @bits: bitmap address to base the search on
+ * @size: bitmap size in number of bits
+ * @clump_size: clump size in bits
+ */
+#define for_each_set_clump(start, clump, bits, size, clump_size) \
+	for ((start) = find_first_clump(&(clump), (bits), (size), (clump_size)); \
+	     (start) < (size); \
+	     (start) = find_next_clump(&(clump), (bits), (size), (start) + (clump_size), (clump_size)))
+
 static inline int get_bitmask_order(unsigned int count)
 {
 	int order;
diff --git a/lib/find_bit.c b/lib/find_bit.c
index 49f875f1baf7..1341bd39b32a 100644
--- a/lib/find_bit.c
+++ b/lib/find_bit.c
@@ -190,3 +190,17 @@ unsigned long find_next_clump8(unsigned long *clump, const unsigned long *addr,
 	return offset;
 }
 EXPORT_SYMBOL(find_next_clump8);
+
+unsigned long find_next_clump(unsigned long *clump, const unsigned long *addr,
+			       unsigned long size, unsigned long offset,
+			       unsigned long clump_size)
+{
+	offset = find_next_bit(addr, size, offset);
+	if (offset == size)
+		return size;
+
+	offset = rounddown(offset, clump_size);
+	*clump = bitmap_get_value(addr, offset, clump_size);
+	return offset;
+}
+EXPORT_SYMBOL(find_next_clump);
-- 
2.26.2

[PATCH v5 2/4] lib/test_bitmap.c: Add for_each_set_clump test cases

[Syed Nayyar Waris]

The introduction of the generic for_each_set_clump macro need test
cases to verify the implementation. This patch adds test cases for
scenarios in which clump sizes are 8 bits, 24 bits, 30 bits and 6 bits.
The cases contain situations where clump is getting split at the word
boundary and also when zeroes are present in the start and middle of
bitmap.

Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Syed Nayyar Waris <syednwaris@gmail.com>
Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
---
Changes in v5:
 - No change.

Changes in v4:
 - Use 'for' loop in test function of 'for_each_set_clump'.

Changes in v3:
 - No Change.

Changes in v2:
 - Unify different tests for 'for_each_set_clump'. Pass test data as
   function parameters.
 - Remove unnecessary bitmap_zero calls.

 lib/test_bitmap.c | 141 ++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 141 insertions(+)

diff --git a/lib/test_bitmap.c b/lib/test_bitmap.c
index 6b13150667f5..a2a1c411dd62 100644
--- a/lib/test_bitmap.c
+++ b/lib/test_bitmap.c
@@ -155,6 +155,38 @@ static bool __init __check_eq_clump8(const char *srcfile, unsigned int line,
 	return true;
 }
 
+static bool __init __check_eq_clump(const char *srcfile, unsigned int line,
+				    const unsigned int offset,
+				    const unsigned int size,
+				    const unsigned long *const clump_exp,
+				    const unsigned long *const clump,
+				    const unsigned long clump_size)
+{
+	unsigned long exp;
+
+	if (offset >= size) {
+		pr_warn("[%s:%u] bit offset for clump out-of-bounds: expected less than %u, got %u\n",
+			srcfile, line, size, offset);
+		return false;
+	}
+
+	exp = clump_exp[offset / clump_size];
+	if (!exp) {
+		pr_warn("[%s:%u] bit offset for zero clump: expected nonzero clump, got bit offset %u with clump value 0",
+			srcfile, line, offset);
+		return false;
+	}
+
+	if (*clump != exp) {
+		pr_warn("[%s:%u] expected clump value of 0x%lX, got clump value of 0x%lX",
+			srcfile, line, exp, *clump);
+		return false;
+	}
+
+	return true;
+}
+
+
 #define __expect_eq(suffix, ...)					\
 	({								\
 		int result = 0;						\
@@ -172,6 +204,7 @@ static bool __init __check_eq_clump8(const char *srcfile, unsigned int line,
 #define expect_eq_pbl(...)		__expect_eq(pbl, ##__VA_ARGS__)
 #define expect_eq_u32_array(...)	__expect_eq(u32_array, ##__VA_ARGS__)
 #define expect_eq_clump8(...)		__expect_eq(clump8, ##__VA_ARGS__)
+#define expect_eq_clump(...)		__expect_eq(clump, ##__VA_ARGS__)
 
 static void __init test_zero_clear(void)
 {
@@ -588,6 +621,71 @@ static const unsigned char clump_exp[] __initconst = {
 	0x05,	/* non-adjacent 2 bits set */
 };
 
+static const unsigned long bitmap_test_data[] __initconst = {
+	0x38000201,
+	0x05ff0f38,
+	0xeffedcba,
+	0xbbbbabcd,
+	0x000000aa,
+	0x000000aa,
+	0x00ff0000,
+	0xaaaaaa00,
+	0xff000000,
+	0x00aa0000,
+	0x00000000,
+	0x00000000,
+	0x00000000,
+	0x0f000000,
+	0x00000ac0,
+};
+
+static const unsigned long clump_exp1[] __initconst = {
+	0x01,	/* 1 bit set */
+	0x02,	/* non-edge 1 bit set */
+	0x00,	/* zero bits set */
+	0x38,	/* 3 bits set across 4-bit boundary */
+	0x38,	/* Repeated clump */
+	0x0F,	/* 4 bits set */
+	0xFF,	/* all bits set */
+	0x05,	/* non-adjacent 2 bits set */
+};
+
+static const unsigned long clump_exp2[] __initconst = {
+	0xfedcba,	/* 24 bits */
+	0xabcdef,
+	0xaabbbb,	/* Clump split between 2 words */
+	0x000000,	/* zeroes in between */
+	0x0000aa,
+	0x000000,
+	0x0000ff,
+	0xaaaaaa,
+	0x000000,
+	0x0000ff,
+};
+
+static const unsigned long clump_exp3[] __initconst = {
+	0x00000000,	/* starting with 0s*/
+	0x00000000,	/* All 0s */
+	0x00000000,
+	0x00000000,
+	0x3f00000f,     /* Non zero set */
+	0x2aa80003,
+	0x00000aaa,
+	0x00003fc0,
+};
+
+static const unsigned long clump_exp4[] __initconst = {
+	0x00,
+	0x2b,
+};
+
+static const unsigned long * const clump_data[] __initconst = {
+	clump_exp1,
+	clump_exp2,
+	clump_exp3,
+	clump_exp4,
+};
+
 static void __init test_for_each_set_clump8(void)
 {
 #define CLUMP_EXP_NUMBITS 64
@@ -610,6 +708,48 @@ static void __init test_for_each_set_clump8(void)
 		expect_eq_clump8(start, CLUMP_EXP_NUMBITS, clump_exp, &clump);
 }
 
+static void __init execute_for_each_set_clump_test(unsigned long *bits,
+				unsigned long size,
+				unsigned long clump_size,
+				const unsigned long *clump_exp)
+{
+	unsigned long start, clump;
+
+	for_each_set_clump(start, clump, bits, size, clump_size)
+		expect_eq_clump(start, size, clump_exp, &clump, clump_size);
+}
+
+static void __init prepare_test_data(unsigned long * bits,
+				const unsigned long * test_data,
+				int start, int count)
+{
+	int i;
+	unsigned long position = 0;
+
+	for(i = 0; i < count; i++)
+	{
+		bitmap_set_value(bits, test_data[start++], position, 32);
+		position += 32;
+	}
+}
+
+static void __init test_for_each_set_clump(void)
+{
+	int i;
+	int count[] = {2, 8, 4, 1};
+	int offset[] = {0, 2, 10, 14};
+	unsigned long limit[] = {64, 240, 240, 18};
+	unsigned long clump_size[] = {8, 24, 30, 6};
+	DECLARE_BITMAP(bits, 256);
+
+	for(i = 0; i < 4; i++)
+	{
+		prepare_test_data(bits, bitmap_test_data, offset[i], count[i]);
+		execute_for_each_set_clump_test(bits, limit[i],
+					clump_size[i], clump_data[i]);
+	}
+}
+
 static void __init selftest(void)
 {
 	test_zero_clear();
@@ -623,6 +763,7 @@ static void __init selftest(void)
 	test_bitmap_parselist_user();
 	test_mem_optimisations();
 	test_for_each_set_clump8();
+	test_for_each_set_clump();
 }
 
 KSTM_MODULE_LOADERS(test_bitmap);
-- 
2.26.2

[PATCH v5 3/4] gpio: thunderx: Utilize for_each_set_clump macro

[Syed Nayyar Waris]

This patch reimplements the thunderx_gpio_set_multiple function in
drivers/gpio/gpio-thunderx.c to use the new for_each_set_clump macro.
Instead of looping for each bank in thunderx_gpio_set_multiple
function, now we can skip bank which is not set and save cycles.

Cc: Robert Richter <rrichter@marvell.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: Syed Nayyar Waris <syednwaris@gmail.com>
Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
---
Changes in v5:
 - No change.

Changes in v4:
 - Minor change: Inline value '64' in code for better code readability.

Changes in v3:
 - Change datatype of some variables from u64 to unsigned long
   in function thunderx_gpio_set_multiple.

CHanges in v2:
 - No change.

 drivers/gpio/gpio-thunderx.c | 11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/gpio/gpio-thunderx.c b/drivers/gpio/gpio-thunderx.c
index 9f66deab46ea..58c9bb25a377 100644
--- a/drivers/gpio/gpio-thunderx.c
+++ b/drivers/gpio/gpio-thunderx.c
@@ -275,12 +275,15 @@ static void thunderx_gpio_set_multiple(struct gpio_chip *chip,
 				       unsigned long *bits)
 {
 	int bank;
-	u64 set_bits, clear_bits;
+	unsigned long set_bits, clear_bits, gpio_mask;
+	unsigned long offset;
+
 	struct thunderx_gpio *txgpio = gpiochip_get_data(chip);
 
-	for (bank = 0; bank <= chip->ngpio / 64; bank++) {
-		set_bits = bits[bank] & mask[bank];
-		clear_bits = ~bits[bank] & mask[bank];
+	for_each_set_clump(offset, gpio_mask, mask, chip->ngpio, 64) {
+		bank = offset / 64;
+		set_bits = bits[bank] & gpio_mask;
+		clear_bits = ~bits[bank] & gpio_mask;
 		writeq(set_bits, txgpio->register_base + (bank * GPIO_2ND_BANK) + GPIO_TX_SET);
 		writeq(clear_bits, txgpio->register_base + (bank * GPIO_2ND_BANK) + GPIO_TX_CLR);
 	}
-- 
2.26.2

[PATCH v5 4/4] gpio: xilinx: Utilize for_each_set_clump macro

[Syed Nayyar Waris]

This patch reimplements the xgpio_set_multiple function in
drivers/gpio/gpio-xilinx.c to use the new for_each_set_clump macro.
Instead of looping for each bit in xgpio_set_multiple
function, now we can check each channel at a time and save cycles.

Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Cc: Michal Simek <michal.simek@xilinx.com>
Signed-off-by: Syed Nayyar Waris <syednwaris@gmail.com>
Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
---
Changes in v5:
 - Minor change: Inline values '32' and '64' in code for better 
   code readability.

Changes in v4:
 - Minor change: Inline values '32' and '64' in code for better 
   code readability.

Changes in v3:
 - No change.

Changes in v2:
 - No change.

 drivers/gpio/gpio-xilinx.c | 62 ++++++++++++++++++++------------------
 1 file changed, 32 insertions(+), 30 deletions(-)

diff --git a/drivers/gpio/gpio-xilinx.c b/drivers/gpio/gpio-xilinx.c
index 67f9f82e0db0..e81092dea27e 100644
--- a/drivers/gpio/gpio-xilinx.c
+++ b/drivers/gpio/gpio-xilinx.c
@@ -136,39 +136,41 @@ static void xgpio_set(struct gpio_chip *gc, unsigned int gpio, int val)
 static void xgpio_set_multiple(struct gpio_chip *gc, unsigned long *mask,
 			       unsigned long *bits)
 {
-	unsigned long flags;
+	unsigned long flags[2];
 	struct xgpio_instance *chip = gpiochip_get_data(gc);
-	int index = xgpio_index(chip, 0);
-	int offset, i;
-
-	spin_lock_irqsave(&chip->gpio_lock[index], flags);
-
-	/* Write to GPIO signals */
-	for (i = 0; i < gc->ngpio; i++) {
-		if (*mask == 0)
-			break;
-		/* Once finished with an index write it out to the register */
-		if (index !=  xgpio_index(chip, i)) {
-			xgpio_writereg(chip->regs + XGPIO_DATA_OFFSET +
-				       index * XGPIO_CHANNEL_OFFSET,
-				       chip->gpio_state[index]);
-			spin_unlock_irqrestore(&chip->gpio_lock[index], flags);
-			index =  xgpio_index(chip, i);
-			spin_lock_irqsave(&chip->gpio_lock[index], flags);
-		}
-		if (__test_and_clear_bit(i, mask)) {
-			offset =  xgpio_offset(chip, i);
-			if (test_bit(i, bits))
-				chip->gpio_state[index] |= BIT(offset);
-			else
-				chip->gpio_state[index] &= ~BIT(offset);
-		}
+	u32 *const state = chip->gpio_state;
+	unsigned int *const width = chip->gpio_width;
+	unsigned long offset, clump;
+	size_t index;
+
+	DECLARE_BITMAP(old, 64);
+	DECLARE_BITMAP(new, 64);
+	DECLARE_BITMAP(changed, 64);
+
+	spin_lock_irqsave(&chip->gpio_lock[0], flags[0]);
+	spin_lock_irqsave(&chip->gpio_lock[1], flags[1]);
+
+	bitmap_set_value(old, state[0], 0, width[0]);
+	bitmap_set_value(old, state[1], width[0], width[1]);
+	bitmap_replace(new, old, bits, mask, gc->ngpio);
+
+	bitmap_set_value(old, state[0], 0, 32);
+	bitmap_set_value(old, state[1], 32, 32);
+	state[0] = bitmap_get_value(new, 0, width[0]);
+	state[1] = bitmap_get_value(new, width[0], width[1]);
+	bitmap_set_value(new, state[0], 0, 32);
+	bitmap_set_value(new, state[1], 32, 32);
+	bitmap_xor(changed, old, new, 64);
+
+	for_each_set_clump(offset, clump, changed, 64, 32) {
+		index = offset / 32;
+		xgpio_writereg(chip->regs + XGPIO_DATA_OFFSET +
+				index * XGPIO_CHANNEL_OFFSET,
+				state[index]);
 	}
 
-	xgpio_writereg(chip->regs + XGPIO_DATA_OFFSET +
-		       index * XGPIO_CHANNEL_OFFSET, chip->gpio_state[index]);
-
-	spin_unlock_irqrestore(&chip->gpio_lock[index], flags);
+	spin_unlock_irqrestore(&chip->gpio_lock[1], flags[1]);
+	spin_unlock_irqrestore(&chip->gpio_lock[0], flags[0]);
 }
 
 /**
-- 
2.26.2

[PATCH v5 4/4] gpio: xilinx: Utilize for_each_set_clump macro

[Syed Nayyar Waris]

This patch reimplements the xgpio_set_multiple function in
drivers/gpio/gpio-xilinx.c to use the new for_each_set_clump macro.
Instead of looping for each bit in xgpio_set_multiple
function, now we can check each channel at a time and save cycles.

Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Cc: Michal Simek <michal.simek@xilinx.com>
Signed-off-by: Syed Nayyar Waris <syednwaris@gmail.com>
Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
---
Changes in v5:
 - Minor change: Inline values '32' and '64' in code for better 
   code readability.

Changes in v4:
 - Minor change: Inline values '32' and '64' in code for better 
   code readability.

Changes in v3:
 - No change.

Changes in v2:
 - No change.

 drivers/gpio/gpio-xilinx.c | 62 ++++++++++++++++++++------------------
 1 file changed, 32 insertions(+), 30 deletions(-)

diff --git a/drivers/gpio/gpio-xilinx.c b/drivers/gpio/gpio-xilinx.c
index 67f9f82e0db0..e81092dea27e 100644
--- a/drivers/gpio/gpio-xilinx.c
+++ b/drivers/gpio/gpio-xilinx.c
@@ -136,39 +136,41 @@ static void xgpio_set(struct gpio_chip *gc, unsigned int gpio, int val)
 static void xgpio_set_multiple(struct gpio_chip *gc, unsigned long *mask,
 			       unsigned long *bits)
 {
-	unsigned long flags;
+	unsigned long flags[2];
 	struct xgpio_instance *chip = gpiochip_get_data(gc);
-	int index = xgpio_index(chip, 0);
-	int offset, i;
-
-	spin_lock_irqsave(&chip->gpio_lock[index], flags);
-
-	/* Write to GPIO signals */
-	for (i = 0; i < gc->ngpio; i++) {
-		if (*mask == 0)
-			break;
-		/* Once finished with an index write it out to the register */
-		if (index !=  xgpio_index(chip, i)) {
-			xgpio_writereg(chip->regs + XGPIO_DATA_OFFSET +
-				       index * XGPIO_CHANNEL_OFFSET,
-				       chip->gpio_state[index]);
-			spin_unlock_irqrestore(&chip->gpio_lock[index], flags);
-			index =  xgpio_index(chip, i);
-			spin_lock_irqsave(&chip->gpio_lock[index], flags);
-		}
-		if (__test_and_clear_bit(i, mask)) {
-			offset =  xgpio_offset(chip, i);
-			if (test_bit(i, bits))
-				chip->gpio_state[index] |= BIT(offset);
-			else
-				chip->gpio_state[index] &= ~BIT(offset);
-		}
+	u32 *const state = chip->gpio_state;
+	unsigned int *const width = chip->gpio_width;
+	unsigned long offset, clump;
+	size_t index;
+
+	DECLARE_BITMAP(old, 64);
+	DECLARE_BITMAP(new, 64);
+	DECLARE_BITMAP(changed, 64);
+
+	spin_lock_irqsave(&chip->gpio_lock[0], flags[0]);
+	spin_lock_irqsave(&chip->gpio_lock[1], flags[1]);
+
+	bitmap_set_value(old, state[0], 0, width[0]);
+	bitmap_set_value(old, state[1], width[0], width[1]);
+	bitmap_replace(new, old, bits, mask, gc->ngpio);
+
+	bitmap_set_value(old, state[0], 0, 32);
+	bitmap_set_value(old, state[1], 32, 32);
+	state[0] = bitmap_get_value(new, 0, width[0]);
+	state[1] = bitmap_get_value(new, width[0], width[1]);
+	bitmap_set_value(new, state[0], 0, 32);
+	bitmap_set_value(new, state[1], 32, 32);
+	bitmap_xor(changed, old, new, 64);
+
+	for_each_set_clump(offset, clump, changed, 64, 32) {
+		index = offset / 32;
+		xgpio_writereg(chip->regs + XGPIO_DATA_OFFSET +
+				index * XGPIO_CHANNEL_OFFSET,
+				state[index]);
 	}
 
-	xgpio_writereg(chip->regs + XGPIO_DATA_OFFSET +
-		       index * XGPIO_CHANNEL_OFFSET, chip->gpio_state[index]);
-
-	spin_unlock_irqrestore(&chip->gpio_lock[index], flags);
+	spin_unlock_irqrestore(&chip->gpio_lock[1], flags[1]);
+	spin_unlock_irqrestore(&chip->gpio_lock[0], flags[0]);
 }
 
 /**
-- 
2.26.2


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v5 2/4] lib/test_bitmap.c: Add for_each_set_clump test cases

[Andy Shevchenko]

On Sun, May 03, 2020 at 04:41:42AM +0530, Syed Nayyar Waris wrote:
> The introduction of the generic for_each_set_clump macro need test
> cases to verify the implementation. This patch adds test cases for
> scenarios in which clump sizes are 8 bits, 24 bits, 30 bits and 6 bits.
> The cases contain situations where clump is getting split at the word
> boundary and also when zeroes are present in the start and middle of
> bitmap.


> +static const unsigned long bitmap_test_data[] __initconst = {
> +	0x38000201,
> +	0x05ff0f38,
> +	0xeffedcba,
> +	0xbbbbabcd,
> +	0x000000aa,
> +	0x000000aa,
> +	0x00ff0000,
> +	0xaaaaaa00,
> +	0xff000000,
> +	0x00aa0000,
> +	0x00000000,
> +	0x00000000,
> +	0x00000000,
> +	0x0f000000,
> +	0x00000ac0,
> +};
> +
> +static const unsigned long clump_exp1[] __initconst = {
> +	0x01,	/* 1 bit set */
> +	0x02,	/* non-edge 1 bit set */
> +	0x00,	/* zero bits set */
> +	0x38,	/* 3 bits set across 4-bit boundary */
> +	0x38,	/* Repeated clump */
> +	0x0F,	/* 4 bits set */
> +	0xFF,	/* all bits set */
> +	0x05,	/* non-adjacent 2 bits set */
> +};
> +
> +static const unsigned long clump_exp2[] __initconst = {
> +	0xfedcba,	/* 24 bits */
> +	0xabcdef,
> +	0xaabbbb,	/* Clump split between 2 words */
> +	0x000000,	/* zeroes in between */
> +	0x0000aa,
> +	0x000000,
> +	0x0000ff,
> +	0xaaaaaa,
> +	0x000000,
> +	0x0000ff,
> +};
> +
> +static const unsigned long clump_exp3[] __initconst = {
> +	0x00000000,	/* starting with 0s*/
> +	0x00000000,	/* All 0s */
> +	0x00000000,
> +	0x00000000,
> +	0x3f00000f,     /* Non zero set */
> +	0x2aa80003,
> +	0x00000aaa,
> +	0x00003fc0,
> +};
> +
> +static const unsigned long clump_exp4[] __initconst = {
> +	0x00,
> +	0x2b,
> +};
> +

One more struct here, like

struct clump_test_data {
	unsigned long *data; // with offset implied
	unsigned long count;
	unsigned long size;
	unsigned long limit;
	unsigned long *exp;
};

> +static const unsigned long * const clump_data[] __initconst = {
> +	clump_exp1,
> +	clump_exp2,
> +	clump_exp3,
> +	clump_exp4,
> +};
> +
>  static void __init test_for_each_set_clump8(void)
>  {
>  #define CLUMP_EXP_NUMBITS 64
> @@ -610,6 +708,48 @@ static void __init test_for_each_set_clump8(void)
>  		expect_eq_clump8(start, CLUMP_EXP_NUMBITS, clump_exp, &clump);
>  }
>  
> +static void __init execute_for_each_set_clump_test(unsigned long *bits,
> +				unsigned long size,
> +				unsigned long clump_size,
> +				const unsigned long *clump_exp)
> +{
> +	unsigned long start, clump;
> +
> +	for_each_set_clump(start, clump, bits, size, clump_size)
> +		expect_eq_clump(start, size, clump_exp, &clump, clump_size);
> +}
> +

> +static void __init prepare_test_data(unsigned long * bits,
> +				const unsigned long * test_data,
> +				int start, int count)

... prepare_test_data(struct clump_test_data *data)
{
	...
}

> +{
> +	int i;
> +	unsigned long position = 0;
> +
> +	for(i = 0; i < count; i++)
> +	{
> +		bitmap_set_value(bits, test_data[start++], position, 32);
> +		position += 32;
> +	}
> +}
> +
> +static void __init test_for_each_set_clump(void)
> +{
> +	int i;
> +	int count[] = {2, 8, 4, 1};
> +	int offset[] = {0, 2, 10, 14};
> +	unsigned long limit[] = {64, 240, 240, 18};
> +	unsigned long clump_size[] = {8, 24, 30, 6};
> +	DECLARE_BITMAP(bits, 256);
> +
> +	for(i = 0; i < 4; i++)
> +	{
> +		prepare_test_data(bits, bitmap_test_data, offset[i], count[i]);
> +		execute_for_each_set_clump_test(bits, limit[i],
> +					clump_size[i], clump_data[i]);
> +	}

As I told you it should be as simple as

	unsigned int i;

	for (i < ARRAY_SIZE(clump_test_data)) {
		prepare()
		execute()
	}

> +}


-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v5 0/4] Introduce the for_each_set_clump macro

[Andy Shevchenko]

On Sun, May 03, 2020 at 04:38:36AM +0530, Syed Nayyar Waris wrote:
> This patchset introduces a new generic version of for_each_set_clump. 
> The previous version of for_each_set_clump8 used a fixed size 8-bit
> clump, but the new generic version can work with clump of any size but
> less than or equal to BITS_PER_LONG. The patchset utilizes the new macro 
> in several GPIO drivers.
> 
> The earlier 8-bit for_each_set_clump8 facilitated 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.
> 
> But with the new for_each_set_clump the clump size can be different from 8 bits.
> Moreover, the clump can be split at word boundary in situations where word 
> size is not multiple of clump size. Following are examples showing the working 
> of new macro for clump sizes of 24 bits and 6 bits.
> 
> Example 1:
> clump size: 24 bits, Number of clumps (or ports): 10
> bitmap stores the bit information from where successive clumps are retrieved.
> 
>      /* bitmap memory region */
>         0x00aa0000ff000000;  /* Most significant bits */
>         0xaaaaaa0000ff0000;
>         0x000000aa000000aa;
>         0xbbbbabcdeffedcba;  /* Least significant bits */
> 
> Different iterations of for_each_set_clump:-
> 'offset' is the bit position and 'clump' is the 24 bit clump from the
> above bitmap.
> Iteration first:        offset: 0 clump: 0xfedcba
> Iteration second:       offset: 24 clump: 0xabcdef
> Iteration third:        offset: 48 clump: 0xaabbbb
> Iteration fourth:       offset: 96 clump: 0xaa
> Iteration fifth:        offset: 144 clump: 0xff
> Iteration sixth:        offset: 168 clump: 0xaaaaaa
> Iteration seventh:      offset: 216 clump: 0xff
> Loop breaks because in the end the remaining bits (0x00aa) size was less
> than clump size of 24 bits.
> 
> In above example it can be seen that in iteration third, the 24 bit clump
> that was retrieved was split between bitmap[0] and bitmap[1]. This example 
> also shows that 24 bit zeroes if present in between, were skipped (preserving
> the previous for_each_set_macro8 behaviour). 
> 
> Example 2:
> clump size = 6 bits, Number of clumps (or ports) = 3.
> 
>      /* bitmap memory region */
>         0x00aa0000ff000000;  /* Most significant bits */
>         0xaaaaaa0000ff0000;
>         0x0f00000000000000;
>         0x0000000000000ac0;  /* Least significant bits */
> 
> Different iterations of for_each_set_clump:
> 'offset' is the bit position and 'clump' is the 6 bit clump from the
> above bitmap.
> Iteration first:        offset: 6 clump: 0x2b
> Loop breaks because 6 * 3 = 18 bits traversed in bitmap.
> Here 6 * 3 is clump size * no. of clumps.

Looking into the last patches where we have examples I still do not see a
benefit of variadic clump sizes. power of 2 sizes would make sense (and be
optimized accordingly (64-bit, 32-bit).

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v5 0/4] Introduce the for_each_set_clump macro

[Andy Shevchenko]

On Sun, May 03, 2020 at 04:38:36AM +0530, Syed Nayyar Waris wrote:
> This patchset introduces a new generic version of for_each_set_clump. 
> The previous version of for_each_set_clump8 used a fixed size 8-bit
> clump, but the new generic version can work with clump of any size but
> less than or equal to BITS_PER_LONG. The patchset utilizes the new macro 
> in several GPIO drivers.
> 
> The earlier 8-bit for_each_set_clump8 facilitated 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.
> 
> But with the new for_each_set_clump the clump size can be different from 8 bits.
> Moreover, the clump can be split at word boundary in situations where word 
> size is not multiple of clump size. Following are examples showing the working 
> of new macro for clump sizes of 24 bits and 6 bits.
> 
> Example 1:
> clump size: 24 bits, Number of clumps (or ports): 10
> bitmap stores the bit information from where successive clumps are retrieved.
> 
>      /* bitmap memory region */
>         0x00aa0000ff000000;  /* Most significant bits */
>         0xaaaaaa0000ff0000;
>         0x000000aa000000aa;
>         0xbbbbabcdeffedcba;  /* Least significant bits */
> 
> Different iterations of for_each_set_clump:-
> 'offset' is the bit position and 'clump' is the 24 bit clump from the
> above bitmap.
> Iteration first:        offset: 0 clump: 0xfedcba
> Iteration second:       offset: 24 clump: 0xabcdef
> Iteration third:        offset: 48 clump: 0xaabbbb
> Iteration fourth:       offset: 96 clump: 0xaa
> Iteration fifth:        offset: 144 clump: 0xff
> Iteration sixth:        offset: 168 clump: 0xaaaaaa
> Iteration seventh:      offset: 216 clump: 0xff
> Loop breaks because in the end the remaining bits (0x00aa) size was less
> than clump size of 24 bits.
> 
> In above example it can be seen that in iteration third, the 24 bit clump
> that was retrieved was split between bitmap[0] and bitmap[1]. This example 
> also shows that 24 bit zeroes if present in between, were skipped (preserving
> the previous for_each_set_macro8 behaviour). 
> 
> Example 2:
> clump size = 6 bits, Number of clumps (or ports) = 3.
> 
>      /* bitmap memory region */
>         0x00aa0000ff000000;  /* Most significant bits */
>         0xaaaaaa0000ff0000;
>         0x0f00000000000000;
>         0x0000000000000ac0;  /* Least significant bits */
> 
> Different iterations of for_each_set_clump:
> 'offset' is the bit position and 'clump' is the 6 bit clump from the
> above bitmap.
> Iteration first:        offset: 6 clump: 0x2b
> Loop breaks because 6 * 3 = 18 bits traversed in bitmap.
> Here 6 * 3 is clump size * no. of clumps.

Looking into the last patches where we have examples I still do not see a
benefit of variadic clump sizes. power of 2 sizes would make sense (and be
optimized accordingly (64-bit, 32-bit).

-- 
With Best Regards,
Andy Shevchenko



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v5 0/4] Introduce the for_each_set_clump macro

[William Breathitt Gray]

[-- Attachment #1: Type: text/plain, Size: 4570 bytes --]

On Mon, May 04, 2020 at 02:41:09PM +0300, Andy Shevchenko wrote:
> On Sun, May 03, 2020 at 04:38:36AM +0530, Syed Nayyar Waris wrote:
> > This patchset introduces a new generic version of for_each_set_clump. 
> > The previous version of for_each_set_clump8 used a fixed size 8-bit
> > clump, but the new generic version can work with clump of any size but
> > less than or equal to BITS_PER_LONG. The patchset utilizes the new macro 
> > in several GPIO drivers.
> > 
> > The earlier 8-bit for_each_set_clump8 facilitated 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.
> > 
> > But with the new for_each_set_clump the clump size can be different from 8 bits.
> > Moreover, the clump can be split at word boundary in situations where word 
> > size is not multiple of clump size. Following are examples showing the working 
> > of new macro for clump sizes of 24 bits and 6 bits.
> > 
> > Example 1:
> > clump size: 24 bits, Number of clumps (or ports): 10
> > bitmap stores the bit information from where successive clumps are retrieved.
> > 
> >      /* bitmap memory region */
> >         0x00aa0000ff000000;  /* Most significant bits */
> >         0xaaaaaa0000ff0000;
> >         0x000000aa000000aa;
> >         0xbbbbabcdeffedcba;  /* Least significant bits */
> > 
> > Different iterations of for_each_set_clump:-
> > 'offset' is the bit position and 'clump' is the 24 bit clump from the
> > above bitmap.
> > Iteration first:        offset: 0 clump: 0xfedcba
> > Iteration second:       offset: 24 clump: 0xabcdef
> > Iteration third:        offset: 48 clump: 0xaabbbb
> > Iteration fourth:       offset: 96 clump: 0xaa
> > Iteration fifth:        offset: 144 clump: 0xff
> > Iteration sixth:        offset: 168 clump: 0xaaaaaa
> > Iteration seventh:      offset: 216 clump: 0xff
> > Loop breaks because in the end the remaining bits (0x00aa) size was less
> > than clump size of 24 bits.
> > 
> > In above example it can be seen that in iteration third, the 24 bit clump
> > that was retrieved was split between bitmap[0] and bitmap[1]. This example 
> > also shows that 24 bit zeroes if present in between, were skipped (preserving
> > the previous for_each_set_macro8 behaviour). 
> > 
> > Example 2:
> > clump size = 6 bits, Number of clumps (or ports) = 3.
> > 
> >      /* bitmap memory region */
> >         0x00aa0000ff000000;  /* Most significant bits */
> >         0xaaaaaa0000ff0000;
> >         0x0f00000000000000;
> >         0x0000000000000ac0;  /* Least significant bits */
> > 
> > Different iterations of for_each_set_clump:
> > 'offset' is the bit position and 'clump' is the 6 bit clump from the
> > above bitmap.
> > Iteration first:        offset: 6 clump: 0x2b
> > Loop breaks because 6 * 3 = 18 bits traversed in bitmap.
> > Here 6 * 3 is clump size * no. of clumps.
> 
> Looking into the last patches where we have examples I still do not see a
> benefit of variadic clump sizes. power of 2 sizes would make sense (and be
> optimized accordingly (64-bit, 32-bit).
> 
> -- 
> With Best Regards,
> Andy Shevchenko

There is of course benefit in defining for_each_set_clump with clump
sizes of powers of 2 (we can optimize for 32 and 64 bit sizes and avoid
boundary checks that we know will not occur), but at the very least the
variable size bitmap_set_value and bitmap_get_value provide significant
benefit for the readability of the gpio-xilinx code:

	bitmap_set_value(old, state[0], 0, width[0]);
	bitmap_set_value(old, state[1], width[0], width[1]);
	...
	state[0] = bitmap_get_value(new, 0, width[0]);
	state[1] = bitmap_get_value(new, width[0], width[1]);

These lines are simple and clear to read: we know immediately what they
do. But if we did not have bitmap_set_value/bitmap_get_value, we'd have
to use several bitwise operations for each line; the obfuscation of the
code would be an obvious hinderance here.

William Breathitt Gray

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v5 0/4] Introduce the for_each_set_clump macro

[William Breathitt Gray]

[-- Attachment #1.1: Type: text/plain, Size: 4570 bytes --]

On Mon, May 04, 2020 at 02:41:09PM +0300, Andy Shevchenko wrote:
> On Sun, May 03, 2020 at 04:38:36AM +0530, Syed Nayyar Waris wrote:
> > This patchset introduces a new generic version of for_each_set_clump. 
> > The previous version of for_each_set_clump8 used a fixed size 8-bit
> > clump, but the new generic version can work with clump of any size but
> > less than or equal to BITS_PER_LONG. The patchset utilizes the new macro 
> > in several GPIO drivers.
> > 
> > The earlier 8-bit for_each_set_clump8 facilitated 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.
> > 
> > But with the new for_each_set_clump the clump size can be different from 8 bits.
> > Moreover, the clump can be split at word boundary in situations where word 
> > size is not multiple of clump size. Following are examples showing the working 
> > of new macro for clump sizes of 24 bits and 6 bits.
> > 
> > Example 1:
> > clump size: 24 bits, Number of clumps (or ports): 10
> > bitmap stores the bit information from where successive clumps are retrieved.
> > 
> >      /* bitmap memory region */
> >         0x00aa0000ff000000;  /* Most significant bits */
> >         0xaaaaaa0000ff0000;
> >         0x000000aa000000aa;
> >         0xbbbbabcdeffedcba;  /* Least significant bits */
> > 
> > Different iterations of for_each_set_clump:-
> > 'offset' is the bit position and 'clump' is the 24 bit clump from the
> > above bitmap.
> > Iteration first:        offset: 0 clump: 0xfedcba
> > Iteration second:       offset: 24 clump: 0xabcdef
> > Iteration third:        offset: 48 clump: 0xaabbbb
> > Iteration fourth:       offset: 96 clump: 0xaa
> > Iteration fifth:        offset: 144 clump: 0xff
> > Iteration sixth:        offset: 168 clump: 0xaaaaaa
> > Iteration seventh:      offset: 216 clump: 0xff
> > Loop breaks because in the end the remaining bits (0x00aa) size was less
> > than clump size of 24 bits.
> > 
> > In above example it can be seen that in iteration third, the 24 bit clump
> > that was retrieved was split between bitmap[0] and bitmap[1]. This example 
> > also shows that 24 bit zeroes if present in between, were skipped (preserving
> > the previous for_each_set_macro8 behaviour). 
> > 
> > Example 2:
> > clump size = 6 bits, Number of clumps (or ports) = 3.
> > 
> >      /* bitmap memory region */
> >         0x00aa0000ff000000;  /* Most significant bits */
> >         0xaaaaaa0000ff0000;
> >         0x0f00000000000000;
> >         0x0000000000000ac0;  /* Least significant bits */
> > 
> > Different iterations of for_each_set_clump:
> > 'offset' is the bit position and 'clump' is the 6 bit clump from the
> > above bitmap.
> > Iteration first:        offset: 6 clump: 0x2b
> > Loop breaks because 6 * 3 = 18 bits traversed in bitmap.
> > Here 6 * 3 is clump size * no. of clumps.
> 
> Looking into the last patches where we have examples I still do not see a
> benefit of variadic clump sizes. power of 2 sizes would make sense (and be
> optimized accordingly (64-bit, 32-bit).
> 
> -- 
> With Best Regards,
> Andy Shevchenko

There is of course benefit in defining for_each_set_clump with clump
sizes of powers of 2 (we can optimize for 32 and 64 bit sizes and avoid
boundary checks that we know will not occur), but at the very least the
variable size bitmap_set_value and bitmap_get_value provide significant
benefit for the readability of the gpio-xilinx code:

	bitmap_set_value(old, state[0], 0, width[0]);
	bitmap_set_value(old, state[1], width[0], width[1]);
	...
	state[0] = bitmap_get_value(new, 0, width[0]);
	state[1] = bitmap_get_value(new, width[0], width[1]);

These lines are simple and clear to read: we know immediately what they
do. But if we did not have bitmap_set_value/bitmap_get_value, we'd have
to use several bitwise operations for each line; the obfuscation of the
code would be an obvious hinderance here.

William Breathitt Gray

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v5 0/4] Introduce the for_each_set_clump macro

[Andy Shevchenko]

On Mon, May 4, 2020 at 5:41 PM William Breathitt Gray
<vilhelm.gray@gmail.com> wrote:
> On Mon, May 04, 2020 at 02:41:09PM +0300, Andy Shevchenko wrote:
> > On Sun, May 03, 2020 at 04:38:36AM +0530, Syed Nayyar Waris wrote:

...

> > Looking into the last patches where we have examples I still do not see a
> > benefit of variadic clump sizes. power of 2 sizes would make sense (and be
> > optimized accordingly (64-bit, 32-bit).
> >
> > --
> > With Best Regards,
> > Andy Shevchenko
>
> There is of course benefit in defining for_each_set_clump with clump
> sizes of powers of 2 (we can optimize for 32 and 64 bit sizes and avoid
> boundary checks that we know will not occur), but at the very least the
> variable size bitmap_set_value and bitmap_get_value provide significant
> benefit for the readability of the gpio-xilinx code:
>
>         bitmap_set_value(old, state[0], 0, width[0]);
>         bitmap_set_value(old, state[1], width[0], width[1]);
>         ...
>         state[0] = bitmap_get_value(new, 0, width[0]);
>         state[1] = bitmap_get_value(new, width[0], width[1]);
>
> These lines are simple and clear to read: we know immediately what they
> do. But if we did not have bitmap_set_value/bitmap_get_value, we'd have
> to use several bitwise operations for each line; the obfuscation of the
> code would be an obvious hinderance here.

Do I understand correctly that width[0] and width[1] may not be power
of two and it's actually the case?

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v5 0/4] Introduce the for_each_set_clump macro

[Andy Shevchenko]

On Mon, May 4, 2020 at 5:41 PM William Breathitt Gray
<vilhelm.gray@gmail.com> wrote:
> On Mon, May 04, 2020 at 02:41:09PM +0300, Andy Shevchenko wrote:
> > On Sun, May 03, 2020 at 04:38:36AM +0530, Syed Nayyar Waris wrote:

...

> > Looking into the last patches where we have examples I still do not see a
> > benefit of variadic clump sizes. power of 2 sizes would make sense (and be
> > optimized accordingly (64-bit, 32-bit).
> >
> > --
> > With Best Regards,
> > Andy Shevchenko
>
> There is of course benefit in defining for_each_set_clump with clump
> sizes of powers of 2 (we can optimize for 32 and 64 bit sizes and avoid
> boundary checks that we know will not occur), but at the very least the
> variable size bitmap_set_value and bitmap_get_value provide significant
> benefit for the readability of the gpio-xilinx code:
>
>         bitmap_set_value(old, state[0], 0, width[0]);
>         bitmap_set_value(old, state[1], width[0], width[1]);
>         ...
>         state[0] = bitmap_get_value(new, 0, width[0]);
>         state[1] = bitmap_get_value(new, width[0], width[1]);
>
> These lines are simple and clear to read: we know immediately what they
> do. But if we did not have bitmap_set_value/bitmap_get_value, we'd have
> to use several bitwise operations for each line; the obfuscation of the
> code would be an obvious hinderance here.

Do I understand correctly that width[0] and width[1] may not be power
of two and it's actually the case?

-- 
With Best Regards,
Andy Shevchenko

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v5 0/4] Introduce the for_each_set_clump macro

[William Breathitt Gray]

[-- Attachment #1: Type: text/plain, Size: 2207 bytes --]

On Tue, May 05, 2020 at 04:51:56PM +0300, Andy Shevchenko wrote:
> On Mon, May 4, 2020 at 5:41 PM William Breathitt Gray
> <vilhelm.gray@gmail.com> wrote:
> > On Mon, May 04, 2020 at 02:41:09PM +0300, Andy Shevchenko wrote:
> > > On Sun, May 03, 2020 at 04:38:36AM +0530, Syed Nayyar Waris wrote:
> 
> ...
> 
> > > Looking into the last patches where we have examples I still do not see a
> > > benefit of variadic clump sizes. power of 2 sizes would make sense (and be
> > > optimized accordingly (64-bit, 32-bit).
> > >
> > > --
> > > With Best Regards,
> > > Andy Shevchenko
> >
> > There is of course benefit in defining for_each_set_clump with clump
> > sizes of powers of 2 (we can optimize for 32 and 64 bit sizes and avoid
> > boundary checks that we know will not occur), but at the very least the
> > variable size bitmap_set_value and bitmap_get_value provide significant
> > benefit for the readability of the gpio-xilinx code:
> >
> >         bitmap_set_value(old, state[0], 0, width[0]);
> >         bitmap_set_value(old, state[1], width[0], width[1]);
> >         ...
> >         state[0] = bitmap_get_value(new, 0, width[0]);
> >         state[1] = bitmap_get_value(new, width[0], width[1]);
> >
> > These lines are simple and clear to read: we know immediately what they
> > do. But if we did not have bitmap_set_value/bitmap_get_value, we'd have
> > to use several bitwise operations for each line; the obfuscation of the
> > code would be an obvious hinderance here.
> 
> Do I understand correctly that width[0] and width[1] may not be power
> of two and it's actually the case?
> 
> -- 
> With Best Regards,
> Andy Shevchenko

I'm under the impression that width[0] and width[1] are arbitrarily
chosen by the user and could be any integer. I have never used this
hardware so I'm hoping one of the gpio-xilinx or GPIO subsystem
maintainers in this thread will respond with some guidance.

If the values of width[0] and width[1] are restricted to powers of 2,
then I agree that there is no need for generic bitmap_set_value and
bitmap_get_value functions and we can instead use more optimized power
of 2 versions.

William Breathitt Gray

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v5 0/4] Introduce the for_each_set_clump macro

[William Breathitt Gray]

[-- Attachment #1: Type: text/plain, Size: 2207 bytes --]

On Tue, May 05, 2020 at 04:51:56PM +0300, Andy Shevchenko wrote:
> On Mon, May 4, 2020 at 5:41 PM William Breathitt Gray
> <vilhelm.gray@gmail.com> wrote:
> > On Mon, May 04, 2020 at 02:41:09PM +0300, Andy Shevchenko wrote:
> > > On Sun, May 03, 2020 at 04:38:36AM +0530, Syed Nayyar Waris wrote:
> 
> ...
> 
> > > Looking into the last patches where we have examples I still do not see a
> > > benefit of variadic clump sizes. power of 2 sizes would make sense (and be
> > > optimized accordingly (64-bit, 32-bit).
> > >
> > > --
> > > With Best Regards,
> > > Andy Shevchenko
> >
> > There is of course benefit in defining for_each_set_clump with clump
> > sizes of powers of 2 (we can optimize for 32 and 64 bit sizes and avoid
> > boundary checks that we know will not occur), but at the very least the
> > variable size bitmap_set_value and bitmap_get_value provide significant
> > benefit for the readability of the gpio-xilinx code:
> >
> >         bitmap_set_value(old, state[0], 0, width[0]);
> >         bitmap_set_value(old, state[1], width[0], width[1]);
> >         ...
> >         state[0] = bitmap_get_value(new, 0, width[0]);
> >         state[1] = bitmap_get_value(new, width[0], width[1]);
> >
> > These lines are simple and clear to read: we know immediately what they
> > do. But if we did not have bitmap_set_value/bitmap_get_value, we'd have
> > to use several bitwise operations for each line; the obfuscation of the
> > code would be an obvious hinderance here.
> 
> Do I understand correctly that width[0] and width[1] may not be power
> of two and it's actually the case?
> 
> -- 
> With Best Regards,
> Andy Shevchenko

I'm under the impression that width[0] and width[1] are arbitrarily
chosen by the user and could be any integer. I have never used this
hardware so I'm hoping one of the gpio-xilinx or GPIO subsystem
maintainers in this thread will respond with some guidance.

If the values of width[0] and width[1] are restricted to powers of 2,
then I agree that there is no need for generic bitmap_set_value and
bitmap_get_value functions and we can instead use more optimized power
of 2 versions.

William Breathitt Gray

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v5 0/4] Introduce the for_each_set_clump macro

[William Breathitt Gray]

[-- Attachment #1: Type: text/plain, Size: 2207 bytes --]

On Tue, May 05, 2020 at 04:51:56PM +0300, Andy Shevchenko wrote:
> On Mon, May 4, 2020 at 5:41 PM William Breathitt Gray
> <vilhelm.gray@gmail.com> wrote:
> > On Mon, May 04, 2020 at 02:41:09PM +0300, Andy Shevchenko wrote:
> > > On Sun, May 03, 2020 at 04:38:36AM +0530, Syed Nayyar Waris wrote:
> 
> ...
> 
> > > Looking into the last patches where we have examples I still do not see a
> > > benefit of variadic clump sizes. power of 2 sizes would make sense (and be
> > > optimized accordingly (64-bit, 32-bit).
> > >
> > > --
> > > With Best Regards,
> > > Andy Shevchenko
> >
> > There is of course benefit in defining for_each_set_clump with clump
> > sizes of powers of 2 (we can optimize for 32 and 64 bit sizes and avoid
> > boundary checks that we know will not occur), but at the very least the
> > variable size bitmap_set_value and bitmap_get_value provide significant
> > benefit for the readability of the gpio-xilinx code:
> >
> >         bitmap_set_value(old, state[0], 0, width[0]);
> >         bitmap_set_value(old, state[1], width[0], width[1]);
> >         ...
> >         state[0] = bitmap_get_value(new, 0, width[0]);
> >         state[1] = bitmap_get_value(new, width[0], width[1]);
> >
> > These lines are simple and clear to read: we know immediately what they
> > do. But if we did not have bitmap_set_value/bitmap_get_value, we'd have
> > to use several bitwise operations for each line; the obfuscation of the
> > code would be an obvious hinderance here.
> 
> Do I understand correctly that width[0] and width[1] may not be power
> of two and it's actually the case?
> 
> -- 
> With Best Regards,
> Andy Shevchenko

I'm under the impression that width[0] and width[1] are arbitrarily
chosen by the user and could be any integer. I have never used this
hardware so I'm hoping one of the gpio-xilinx or GPIO subsystem
maintainers in this thread will respond with some guidance.

If the values of width[0] and width[1] are restricted to powers of 2,
then I agree that there is no need for generic bitmap_set_value and
bitmap_get_value functions and we can instead use more optimized power
of 2 versions.

William Breathitt Gray

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v5 0/4] Introduce the for_each_set_clump macro

[William Breathitt Gray]

[-- Attachment #1.1: Type: text/plain, Size: 2207 bytes --]

On Tue, May 05, 2020 at 04:51:56PM +0300, Andy Shevchenko wrote:
> On Mon, May 4, 2020 at 5:41 PM William Breathitt Gray
> <vilhelm.gray@gmail.com> wrote:
> > On Mon, May 04, 2020 at 02:41:09PM +0300, Andy Shevchenko wrote:
> > > On Sun, May 03, 2020 at 04:38:36AM +0530, Syed Nayyar Waris wrote:
> 
> ...
> 
> > > Looking into the last patches where we have examples I still do not see a
> > > benefit of variadic clump sizes. power of 2 sizes would make sense (and be
> > > optimized accordingly (64-bit, 32-bit).
> > >
> > > --
> > > With Best Regards,
> > > Andy Shevchenko
> >
> > There is of course benefit in defining for_each_set_clump with clump
> > sizes of powers of 2 (we can optimize for 32 and 64 bit sizes and avoid
> > boundary checks that we know will not occur), but at the very least the
> > variable size bitmap_set_value and bitmap_get_value provide significant
> > benefit for the readability of the gpio-xilinx code:
> >
> >         bitmap_set_value(old, state[0], 0, width[0]);
> >         bitmap_set_value(old, state[1], width[0], width[1]);
> >         ...
> >         state[0] = bitmap_get_value(new, 0, width[0]);
> >         state[1] = bitmap_get_value(new, width[0], width[1]);
> >
> > These lines are simple and clear to read: we know immediately what they
> > do. But if we did not have bitmap_set_value/bitmap_get_value, we'd have
> > to use several bitwise operations for each line; the obfuscation of the
> > code would be an obvious hinderance here.
> 
> Do I understand correctly that width[0] and width[1] may not be power
> of two and it's actually the case?
> 
> -- 
> With Best Regards,
> Andy Shevchenko

I'm under the impression that width[0] and width[1] are arbitrarily
chosen by the user and could be any integer. I have never used this
hardware so I'm hoping one of the gpio-xilinx or GPIO subsystem
maintainers in this thread will respond with some guidance.

If the values of width[0] and width[1] are restricted to powers of 2,
then I agree that there is no need for generic bitmap_set_value and
bitmap_get_value functions and we can instead use more optimized power
of 2 versions.

William Breathitt Gray

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v5 0/4] Introduce the for_each_set_clump macro

[Syed Nayyar Waris]

On Tue, May 5, 2020 at 8:24 PM William Breathitt Gray
<vilhelm.gray@gmail.com> wrote:
>
> On Tue, May 05, 2020 at 04:51:56PM +0300, Andy Shevchenko wrote:
> > On Mon, May 4, 2020 at 5:41 PM William Breathitt Gray
> > <vilhelm.gray@gmail.com> wrote:
> > > On Mon, May 04, 2020 at 02:41:09PM +0300, Andy Shevchenko wrote:
> > > > On Sun, May 03, 2020 at 04:38:36AM +0530, Syed Nayyar Waris wrote:
> >
> > ...
> >
> > > > Looking into the last patches where we have examples I still do not see a
> > > > benefit of variadic clump sizes. power of 2 sizes would make sense (and be
> > > > optimized accordingly (64-bit, 32-bit).
> > > >
> > > > --
> > > > With Best Regards,
> > > > Andy Shevchenko
> > >
> > > There is of course benefit in defining for_each_set_clump with clump
> > > sizes of powers of 2 (we can optimize for 32 and 64 bit sizes and avoid
> > > boundary checks that we know will not occur), but at the very least the
> > > variable size bitmap_set_value and bitmap_get_value provide significant
> > > benefit for the readability of the gpio-xilinx code:
> > >
> > >         bitmap_set_value(old, state[0], 0, width[0]);
> > >         bitmap_set_value(old, state[1], width[0], width[1]);
> > >         ...
> > >         state[0] = bitmap_get_value(new, 0, width[0]);
> > >         state[1] = bitmap_get_value(new, width[0], width[1]);
> > >
> > > These lines are simple and clear to read: we know immediately what they
> > > do. But if we did not have bitmap_set_value/bitmap_get_value, we'd have
> > > to use several bitwise operations for each line; the obfuscation of the
> > > code would be an obvious hinderance here.
> >
> > Do I understand correctly that width[0] and width[1] may not be power
> > of two and it's actually the case?
> >
> > --
> > With Best Regards,
> > Andy Shevchenko
>
> I'm under the impression that width[0] and width[1] are arbitrarily
> chosen by the user and could be any integer. I have never used this
> hardware so I'm hoping one of the gpio-xilinx or GPIO subsystem
> maintainers in this thread will respond with some guidance.
>
> If the values of width[0] and width[1] are restricted to powers of 2,
> then I agree that there is no need for generic bitmap_set_value and
> bitmap_get_value functions and we can instead use more optimized power
> of 2 versions.
>
> William Breathitt Gray


Regarding the question that whether width[0] and width[1] can have any
value or they are restricted to power-of-2.

Referring to the document (This xilinx GPIO IP was mentioned in the
gpio-xilinx.c file):
https://www.xilinx.com/support/documentation/ip_documentation/axi_gpio/v2_0/pg144-axi-gpio.pdf

On page 8, we can see that the GPIO widths for the 2 channels can have
values different from power-of-2.For example: 5, 15 etc.

So, I think we should keep the 'for_each_set_clump',
'bitmap_get_value' and 'bitmap_set_value' as completely generic.

I am proceeding further for my next patchset submission keeping above
findings in mind. If you guys think something else or would like to
add something, let me know.

Regards
Syed Nayyar Waris

Re: [PATCH v5 0/4] Introduce the for_each_set_clump macro

[Syed Nayyar Waris]

On Tue, May 5, 2020 at 8:24 PM William Breathitt Gray
<vilhelm.gray@gmail.com> wrote:
>
> On Tue, May 05, 2020 at 04:51:56PM +0300, Andy Shevchenko wrote:
> > On Mon, May 4, 2020 at 5:41 PM William Breathitt Gray
> > <vilhelm.gray@gmail.com> wrote:
> > > On Mon, May 04, 2020 at 02:41:09PM +0300, Andy Shevchenko wrote:
> > > > On Sun, May 03, 2020 at 04:38:36AM +0530, Syed Nayyar Waris wrote:
> >
> > ...
> >
> > > > Looking into the last patches where we have examples I still do not see a
> > > > benefit of variadic clump sizes. power of 2 sizes would make sense (and be
> > > > optimized accordingly (64-bit, 32-bit).
> > > >
> > > > --
> > > > With Best Regards,
> > > > Andy Shevchenko
> > >
> > > There is of course benefit in defining for_each_set_clump with clump
> > > sizes of powers of 2 (we can optimize for 32 and 64 bit sizes and avoid
> > > boundary checks that we know will not occur), but at the very least the
> > > variable size bitmap_set_value and bitmap_get_value provide significant
> > > benefit for the readability of the gpio-xilinx code:
> > >
> > >         bitmap_set_value(old, state[0], 0, width[0]);
> > >         bitmap_set_value(old, state[1], width[0], width[1]);
> > >         ...
> > >         state[0] = bitmap_get_value(new, 0, width[0]);
> > >         state[1] = bitmap_get_value(new, width[0], width[1]);
> > >
> > > These lines are simple and clear to read: we know immediately what they
> > > do. But if we did not have bitmap_set_value/bitmap_get_value, we'd have
> > > to use several bitwise operations for each line; the obfuscation of the
> > > code would be an obvious hinderance here.
> >
> > Do I understand correctly that width[0] and width[1] may not be power
> > of two and it's actually the case?
> >
> > --
> > With Best Regards,
> > Andy Shevchenko
>
> I'm under the impression that width[0] and width[1] are arbitrarily
> chosen by the user and could be any integer. I have never used this
> hardware so I'm hoping one of the gpio-xilinx or GPIO subsystem
> maintainers in this thread will respond with some guidance.
>
> If the values of width[0] and width[1] are restricted to powers of 2,
> then I agree that there is no need for generic bitmap_set_value and
> bitmap_get_value functions and we can instead use more optimized power
> of 2 versions.
>
> William Breathitt Gray


Regarding the question that whether width[0] and width[1] can have any
value or they are restricted to power-of-2.

Referring to the document (This xilinx GPIO IP was mentioned in the
gpio-xilinx.c file):
https://www.xilinx.com/support/documentation/ip_documentation/axi_gpio/v2_0/pg144-axi-gpio.pdf

On page 8, we can see that the GPIO widths for the 2 channels can have
values different from power-of-2.For example: 5, 15 etc.

So, I think we should keep the 'for_each_set_clump',
'bitmap_get_value' and 'bitmap_set_value' as completely generic.

I am proceeding further for my next patchset submission keeping above
findings in mind. If you guys think something else or would like to
add something, let me know.

Regards
Syed Nayyar Waris

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v5 0/4] Introduce the for_each_set_clump macro

[Andy Shevchenko]

On Sat, May 9, 2020 at 7:36 PM Syed Nayyar Waris <syednwaris@gmail.com> wrote:
> On Tue, May 5, 2020 at 8:24 PM William Breathitt Gray
> <vilhelm.gray@gmail.com> wrote:
> > On Tue, May 05, 2020 at 04:51:56PM +0300, Andy Shevchenko wrote:
> > > On Mon, May 4, 2020 at 5:41 PM William Breathitt Gray
> > > <vilhelm.gray@gmail.com> wrote:
> > > > On Mon, May 04, 2020 at 02:41:09PM +0300, Andy Shevchenko wrote:
> > > > > On Sun, May 03, 2020 at 04:38:36AM +0530, Syed Nayyar Waris wrote:

...

> > > > > Looking into the last patches where we have examples I still do not see a
> > > > > benefit of variadic clump sizes. power of 2 sizes would make sense (and be
> > > > > optimized accordingly (64-bit, 32-bit).

> > > > There is of course benefit in defining for_each_set_clump with clump
> > > > sizes of powers of 2 (we can optimize for 32 and 64 bit sizes and avoid
> > > > boundary checks that we know will not occur), but at the very least the
> > > > variable size bitmap_set_value and bitmap_get_value provide significant
> > > > benefit for the readability of the gpio-xilinx code:
> > > >
> > > >         bitmap_set_value(old, state[0], 0, width[0]);
> > > >         bitmap_set_value(old, state[1], width[0], width[1]);
> > > >         ...
> > > >         state[0] = bitmap_get_value(new, 0, width[0]);
> > > >         state[1] = bitmap_get_value(new, width[0], width[1]);
> > > >
> > > > These lines are simple and clear to read: we know immediately what they
> > > > do. But if we did not have bitmap_set_value/bitmap_get_value, we'd have
> > > > to use several bitwise operations for each line; the obfuscation of the
> > > > code would be an obvious hinderance here.
> > >
> > > Do I understand correctly that width[0] and width[1] may not be power
> > > of two and it's actually the case?

> > I'm under the impression that width[0] and width[1] are arbitrarily
> > chosen by the user and could be any integer. I have never used this
> > hardware so I'm hoping one of the gpio-xilinx or GPIO subsystem
> > maintainers in this thread will respond with some guidance.
> >
> > If the values of width[0] and width[1] are restricted to powers of 2,
> > then I agree that there is no need for generic bitmap_set_value and
> > bitmap_get_value functions and we can instead use more optimized power
> > of 2 versions.

> Regarding the question that whether width[0] and width[1] can have any
> value or they are restricted to power-of-2.
>
> Referring to the document (This xilinx GPIO IP was mentioned in the
> gpio-xilinx.c file):
> https://www.xilinx.com/support/documentation/ip_documentation/axi_gpio/v2_0/pg144-axi-gpio.pdf
>
> On page 8, we can see that the GPIO widths for the 2 channels can have
> values different from power-of-2.For example: 5, 15 etc.
>
> So, I think we should keep the 'for_each_set_clump',
> 'bitmap_get_value' and 'bitmap_set_value' as completely generic.
>
> I am proceeding further for my next patchset submission keeping above
> findings in mind. If you guys think something else or would like to
> add something, let me know.

Thank you for investigation. So, if Xilinx is okay with the change, I
have no objections.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v5 0/4] Introduce the for_each_set_clump macro

[Andy Shevchenko]

On Sat, May 9, 2020 at 7:36 PM Syed Nayyar Waris <syednwaris@gmail.com> wrote:
> On Tue, May 5, 2020 at 8:24 PM William Breathitt Gray
> <vilhelm.gray@gmail.com> wrote:
> > On Tue, May 05, 2020 at 04:51:56PM +0300, Andy Shevchenko wrote:
> > > On Mon, May 4, 2020 at 5:41 PM William Breathitt Gray
> > > <vilhelm.gray@gmail.com> wrote:
> > > > On Mon, May 04, 2020 at 02:41:09PM +0300, Andy Shevchenko wrote:
> > > > > On Sun, May 03, 2020 at 04:38:36AM +0530, Syed Nayyar Waris wrote:

...

> > > > > Looking into the last patches where we have examples I still do not see a
> > > > > benefit of variadic clump sizes. power of 2 sizes would make sense (and be
> > > > > optimized accordingly (64-bit, 32-bit).

> > > > There is of course benefit in defining for_each_set_clump with clump
> > > > sizes of powers of 2 (we can optimize for 32 and 64 bit sizes and avoid
> > > > boundary checks that we know will not occur), but at the very least the
> > > > variable size bitmap_set_value and bitmap_get_value provide significant
> > > > benefit for the readability of the gpio-xilinx code:
> > > >
> > > >         bitmap_set_value(old, state[0], 0, width[0]);
> > > >         bitmap_set_value(old, state[1], width[0], width[1]);
> > > >         ...
> > > >         state[0] = bitmap_get_value(new, 0, width[0]);
> > > >         state[1] = bitmap_get_value(new, width[0], width[1]);
> > > >
> > > > These lines are simple and clear to read: we know immediately what they
> > > > do. But if we did not have bitmap_set_value/bitmap_get_value, we'd have
> > > > to use several bitwise operations for each line; the obfuscation of the
> > > > code would be an obvious hinderance here.
> > >
> > > Do I understand correctly that width[0] and width[1] may not be power
> > > of two and it's actually the case?

> > I'm under the impression that width[0] and width[1] are arbitrarily
> > chosen by the user and could be any integer. I have never used this
> > hardware so I'm hoping one of the gpio-xilinx or GPIO subsystem
> > maintainers in this thread will respond with some guidance.
> >
> > If the values of width[0] and width[1] are restricted to powers of 2,
> > then I agree that there is no need for generic bitmap_set_value and
> > bitmap_get_value functions and we can instead use more optimized power
> > of 2 versions.

> Regarding the question that whether width[0] and width[1] can have any
> value or they are restricted to power-of-2.
>
> Referring to the document (This xilinx GPIO IP was mentioned in the
> gpio-xilinx.c file):
> https://www.xilinx.com/support/documentation/ip_documentation/axi_gpio/v2_0/pg144-axi-gpio.pdf
>
> On page 8, we can see that the GPIO widths for the 2 channels can have
> values different from power-of-2.For example: 5, 15 etc.
>
> So, I think we should keep the 'for_each_set_clump',
> 'bitmap_get_value' and 'bitmap_set_value' as completely generic.
>
> I am proceeding further for my next patchset submission keeping above
> findings in mind. If you guys think something else or would like to
> add something, let me know.

Thank you for investigation. So, if Xilinx is okay with the change, I
have no objections.

-- 
With Best Regards,
Andy Shevchenko

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v5 2/4] lib/test_bitmap.c: Add for_each_set_clump test cases

[Syed Nayyar Waris]

On Mon, May 4, 2020 at 5:08 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Sun, May 03, 2020 at 04:41:42AM +0530, Syed Nayyar Waris wrote:
> > The introduction of the generic for_each_set_clump macro need test
> > cases to verify the implementation. This patch adds test cases for
> > scenarios in which clump sizes are 8 bits, 24 bits, 30 bits and 6 bits.
> > The cases contain situations where clump is getting split at the word
> > boundary and also when zeroes are present in the start and middle of
> > bitmap.
>
>
> > +static const unsigned long bitmap_test_data[] __initconst = {
> > +     0x38000201,
> > +     0x05ff0f38,
> > +     0xeffedcba,
> > +     0xbbbbabcd,
> > +     0x000000aa,
> > +     0x000000aa,
> > +     0x00ff0000,
> > +     0xaaaaaa00,
> > +     0xff000000,
> > +     0x00aa0000,
> > +     0x00000000,
> > +     0x00000000,
> > +     0x00000000,
> > +     0x0f000000,
> > +     0x00000ac0,
> > +};
> > +
> > +static const unsigned long clump_exp1[] __initconst = {
> > +     0x01,   /* 1 bit set */
> > +     0x02,   /* non-edge 1 bit set */
> > +     0x00,   /* zero bits set */
> > +     0x38,   /* 3 bits set across 4-bit boundary */
> > +     0x38,   /* Repeated clump */
> > +     0x0F,   /* 4 bits set */
> > +     0xFF,   /* all bits set */
> > +     0x05,   /* non-adjacent 2 bits set */
> > +};
> > +
> > +static const unsigned long clump_exp2[] __initconst = {
> > +     0xfedcba,       /* 24 bits */
> > +     0xabcdef,
> > +     0xaabbbb,       /* Clump split between 2 words */
> > +     0x000000,       /* zeroes in between */
> > +     0x0000aa,
> > +     0x000000,
> > +     0x0000ff,
> > +     0xaaaaaa,
> > +     0x000000,
> > +     0x0000ff,
> > +};
> > +
> > +static const unsigned long clump_exp3[] __initconst = {
> > +     0x00000000,     /* starting with 0s*/
> > +     0x00000000,     /* All 0s */
> > +     0x00000000,
> > +     0x00000000,
> > +     0x3f00000f,     /* Non zero set */
> > +     0x2aa80003,
> > +     0x00000aaa,
> > +     0x00003fc0,
> > +};
> > +
> > +static const unsigned long clump_exp4[] __initconst = {
> > +     0x00,
> > +     0x2b,
> > +};
> > +
>
> One more struct here, like
>
> struct clump_test_data {
>         unsigned long *data; // with offset implied
>         unsigned long count;
>         unsigned long size;
>         unsigned long limit;
>         unsigned long *exp;
> };
>
> > +static const unsigned long * const clump_data[] __initconst = {
> > +     clump_exp1,
> > +     clump_exp2,
> > +     clump_exp3,
> > +     clump_exp4,
> > +};
> > +
> >  static void __init test_for_each_set_clump8(void)
> >  {
> >  #define CLUMP_EXP_NUMBITS 64
> > @@ -610,6 +708,48 @@ static void __init test_for_each_set_clump8(void)
> >               expect_eq_clump8(start, CLUMP_EXP_NUMBITS, clump_exp, &clump);
> >  }
> >
> > +static void __init execute_for_each_set_clump_test(unsigned long *bits,
> > +                             unsigned long size,
> > +                             unsigned long clump_size,
> > +                             const unsigned long *clump_exp)
> > +{
> > +     unsigned long start, clump;
> > +
> > +     for_each_set_clump(start, clump, bits, size, clump_size)
> > +             expect_eq_clump(start, size, clump_exp, &clump, clump_size);
> > +}
> > +
>
> > +static void __init prepare_test_data(unsigned long * bits,
> > +                             const unsigned long * test_data,
> > +                             int start, int count)
>
> ... prepare_test_data(struct clump_test_data *data)
> {
>         ...
> }

Hi. I have sent a new patchset (v6) incorporating your review
comments. Regarding your above review comment for function
'prepare_test_data', the parameter 'struct clump_test_data' has
already been declared outside (as was suggested.. see further above),
so I didn't require that (struct clump_test_data) as a parameter for
the function, as it can be accessed from everywhere.

Further, below ...

...

> > +static void __init test_for_each_set_clump(void)
> > +{
> > +     int i;
> > +     int count[] = {2, 8, 4, 1};
> > +     int offset[] = {0, 2, 10, 14};
> > +     unsigned long limit[] = {64, 240, 240, 18};
> > +     unsigned long clump_size[] = {8, 24, 30, 6};
> > +     DECLARE_BITMAP(bits, 256);
> > +
> > +     for(i = 0; i < 4; i++)
> > +     {
> > +             prepare_test_data(bits, bitmap_test_data, offset[i], count[i]);
> > +             execute_for_each_set_clump_test(bits, limit[i],
> > +                                     clump_size[i], clump_data[i]);
> > +     }
>
> As I told you it should be as simple as
>
>         unsigned int i;
>
>         for (i < ARRAY_SIZE(clump_test_data)) {
>                 prepare()
>                 execute()
>         }
>

Since it is required to use 'for loop' with 'ARRAY_SIZE', this implies
that 'clump_test_data'  be an array, which has been done so. I have
done here a minor addition that the 'prepare_test_data' function is
called with argument 'i' (index) to prepare data specifically for the
ith test case. Without passing 'i' it would not be possible (I
believe) to populate the bitmap properly for the ith test case.

Let me know if the new patchset seems alright. Thank you.

Regards
Syed Nayyar Waris