[PATCH v7 0/3] pcal6524 extensions and fixes for pca953x driver

[PATCH v7 0/3] pcal6524 extensions and fixes for pca953x driver

[H. Nikolaus Schaller]

V7:
* replace PCAL register masks by hex constants

2018-05-16 19:01:29: V6:
* added proper attribution to the formula used for fixing the
  pcal6524 register address (changes commit message only)
* add back missing first patch from V2 that defines the
  PCA_LATCH_INT constant
* removed patches already merged

2018-04-28 18:33:42: V5:
* fix wrong split up between patches 1/7 and 2/7.

2018-04-26 19:35:07: V4:
* introduced PCA_LATCH_INT constant to make of_table more
  readable (suggested by Andy Shevchenko)
* converted all register constants to hex in a separate
  patch (suggested by Andy Shevchenko)
* separated additional pcal953x and pcal6524 register
  definitions into separate patches (suggested by Andy Shevchenko)
* made special pcal6524 address adjustment more readable
  (suggested by Andy Shevchenko)
* moved gpio-controller and interrupt-controller to the
  "required" section (reviewed by Rob Herring)

2018-04-10 18:07:07: V3:
* add Reported-by: and Reviewed-by:
* fix wording for bindings description and example
* convert all register offsets to hex
* omit the LEVEL-IRQ RFC/hack commit

2018-04-04 21:00:27: V2:
* added PCA_PCAL flags if matched through of-table
* fix address calculation for extended PCAL6524 registers
* hack to map LEVEL_LOW to EDGE_FALLING to be able to
  test in combination with ts3a227e driver
* improve description of bindings for optional vcc-supply
  and interrupt-controller;

2018-03-10 09:32:53: no initial description

H. Nikolaus Schaller (3):
  gpio: pca953x: set the PCA_PCAL flag also when matching by DT
  gpio: pca953x: define masks for addressing common and extended
    registers
  gpio: pca953x: fix address calculation for pcal6524

 drivers/gpio/gpio-pca953x.c | 17 +++++++++++++----
 1 file changed, 13 insertions(+), 4 deletions(-)

-- 
2.12.2

[PATCH v7 1/3] gpio: pca953x: set the PCA_PCAL flag also when matching by DT

[H. Nikolaus Schaller]

The of_device_table is missing the PCA_PCAL flag so the
pcal6524 would be operated in tca6424 compatibility mode which
does not handle the new interrupt mask registers.

Suggested-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
---
 drivers/gpio/gpio-pca953x.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
index 7d37692d672e..2b667166e855 100644
--- a/drivers/gpio/gpio-pca953x.c
+++ b/drivers/gpio/gpio-pca953x.c
@@ -58,6 +58,7 @@
 #define PCA_GPIO_MASK		0x00FF
 #define PCA_INT			0x0100
 #define PCA_PCAL		0x0200
+#define PCA_LATCH_INT (PCA_PCAL | PCA_INT)
 #define PCA953X_TYPE		0x1000
 #define PCA957X_TYPE		0x2000
 #define PCA_TYPE_MASK		0xF000
@@ -946,8 +947,8 @@ static const struct of_device_id pca953x_dt_ids[] = {
 	{ .compatible = "nxp,pca9575", .data = OF_957X(16, PCA_INT), },
 	{ .compatible = "nxp,pca9698", .data = OF_953X(40, 0), },
 
-	{ .compatible = "nxp,pcal6524", .data = OF_953X(24, PCA_INT), },
-	{ .compatible = "nxp,pcal9555a", .data = OF_953X(16, PCA_INT), },
+	{ .compatible = "nxp,pcal6524", .data = OF_953X(24, PCA_LATCH_INT), },
+	{ .compatible = "nxp,pcal9555a", .data = OF_953X(16, PCA_LATCH_INT), },
 
 	{ .compatible = "maxim,max7310", .data = OF_953X( 8, 0), },
 	{ .compatible = "maxim,max7312", .data = OF_953X(16, PCA_INT), },
-- 
2.12.2

[PATCH v7 2/3] gpio: pca953x: define masks for addressing common and extended registers

[H. Nikolaus Schaller]

These mask bits are to be used to map the extended register
addreseses (which are defined for an unsupported 8-bit pcal chip)
to 16 and 24 bit chips (pcal6524).

Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
---
 drivers/gpio/gpio-pca953x.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
index 2b667166e855..c682921d7019 100644
--- a/drivers/gpio/gpio-pca953x.c
+++ b/drivers/gpio/gpio-pca953x.c
@@ -56,6 +56,10 @@
 #define PCAL6524_DEBOUNCE	0x2d
 
 #define PCA_GPIO_MASK		0x00FF
+
+#define PCAL_GPIO_MASK		0x1f
+#define PCAL_PINCTRL_MASK	0xe0
+
 #define PCA_INT			0x0100
 #define PCA_PCAL		0x0200
 #define PCA_LATCH_INT (PCA_PCAL | PCA_INT)
-- 
2.12.2

[PATCH v7 3/3] gpio: pca953x: fix address calculation for pcal6524

[H. Nikolaus Schaller]

The register constants are so far defined in a way that they fit
for the pcal9555a when shifted by the number of banks, i.e. are
multiplied by 2 in the accessor function.

Now, the pcal6524 has 3 banks which means the relative offset
is multiplied by 4 for the standard registers.

Simply applying the bit shift to the extended registers gives
a wrong result, since the base offset is already included in
the offset.

Therefore, we have to add code to the 24 bit accessor functions
that adjusts the register number for these exended registers.

The formula finally used was developed and proposed by
Andy Shevchenko <andy.shevchenko@gmail.com>.

Suggested-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
---
 drivers/gpio/gpio-pca953x.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
index c682921d7019..4ad553f4e41f 100644
--- a/drivers/gpio/gpio-pca953x.c
+++ b/drivers/gpio/gpio-pca953x.c
@@ -222,9 +222,11 @@ static int pca957x_write_regs_16(struct pca953x_chip *chip, int reg, u8 *val)
 static int pca953x_write_regs_24(struct pca953x_chip *chip, int reg, u8 *val)
 {
 	int bank_shift = fls((chip->gpio_chip.ngpio - 1) / BANK_SZ);
+	int addr = (reg & PCAL_GPIO_MASK) << bank_shift;
+	int pinctrl = (reg & PCAL_PINCTRL_MASK) << 1;
 
 	return i2c_smbus_write_i2c_block_data(chip->client,
-					      (reg << bank_shift) | REG_ADDR_AI,
+					      pinctrl | addr | REG_ADDR_AI,
 					      NBANK(chip), val);
 }
 
@@ -264,9 +266,11 @@ static int pca953x_read_regs_16(struct pca953x_chip *chip, int reg, u8 *val)
 static int pca953x_read_regs_24(struct pca953x_chip *chip, int reg, u8 *val)
 {
 	int bank_shift = fls((chip->gpio_chip.ngpio - 1) / BANK_SZ);
+	int addr = (reg & PCAL_GPIO_MASK) << bank_shift;
+	int pinctrl = (reg & PCAL_PINCTRL_MASK) << 1;
 
 	return i2c_smbus_read_i2c_block_data(chip->client,
-					     (reg << bank_shift) | REG_ADDR_AI,
+					     pinctrl | addr | REG_ADDR_AI,
 					     NBANK(chip), val);
 }
 
-- 
2.12.2

Re: [PATCH v7 0/3] pcal6524 extensions and fixes for pca953x driver

[Andy Shevchenko]

On Thu, May 17, 2018 at 7:59 AM, H. Nikolaus Schaller <hns@goldelico.com> wrote:
> V7:
> * replace PCAL register masks by hex constants
>

Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>

> 2018-05-16 19:01:29: V6:
> * added proper attribution to the formula used for fixing the
>   pcal6524 register address (changes commit message only)
> * add back missing first patch from V2 that defines the
>   PCA_LATCH_INT constant
> * removed patches already merged
>
> 2018-04-28 18:33:42: V5:
> * fix wrong split up between patches 1/7 and 2/7.
>
> 2018-04-26 19:35:07: V4:
> * introduced PCA_LATCH_INT constant to make of_table more
>   readable (suggested by Andy Shevchenko)
> * converted all register constants to hex in a separate
>   patch (suggested by Andy Shevchenko)
> * separated additional pcal953x and pcal6524 register
>   definitions into separate patches (suggested by Andy Shevchenko)
> * made special pcal6524 address adjustment more readable
>   (suggested by Andy Shevchenko)
> * moved gpio-controller and interrupt-controller to the
>   "required" section (reviewed by Rob Herring)
>
> 2018-04-10 18:07:07: V3:
> * add Reported-by: and Reviewed-by:
> * fix wording for bindings description and example
> * convert all register offsets to hex
> * omit the LEVEL-IRQ RFC/hack commit
>
> 2018-04-04 21:00:27: V2:
> * added PCA_PCAL flags if matched through of-table
> * fix address calculation for extended PCAL6524 registers
> * hack to map LEVEL_LOW to EDGE_FALLING to be able to
>   test in combination with ts3a227e driver
> * improve description of bindings for optional vcc-supply
>   and interrupt-controller;
>
> 2018-03-10 09:32:53: no initial description
>
> H. Nikolaus Schaller (3):
>   gpio: pca953x: set the PCA_PCAL flag also when matching by DT
>   gpio: pca953x: define masks for addressing common and extended
>     registers
>   gpio: pca953x: fix address calculation for pcal6524
>
>  drivers/gpio/gpio-pca953x.c | 17 +++++++++++++----
>  1 file changed, 13 insertions(+), 4 deletions(-)
>
> --
> 2.12.2
>



-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v7 1/3] gpio: pca953x: set the PCA_PCAL flag also when matching by DT

[Linus Walleij]

On Thu, May 17, 2018 at 6:59 AM, H. Nikolaus Schaller <hns@goldelico.com> wrote:

> The of_device_table is missing the PCA_PCAL flag so the
> pcal6524 would be operated in tca6424 compatibility mode which
> does not handle the new interrupt mask registers.
>
> Suggested-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>

Patch applied.

Yours,
Linus Walleij

Re: [PATCH v7 2/3] gpio: pca953x: define masks for addressing common and extended registers

[Linus Walleij]

On Thu, May 17, 2018 at 6:59 AM, H. Nikolaus Schaller <hns@goldelico.com> wrote:

> These mask bits are to be used to map the extended register
> addreseses (which are defined for an unsupported 8-bit pcal chip)
> to 16 and 24 bit chips (pcal6524).
>
> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>

Patch applied.

Yours,
Linus Walleij

Re: [PATCH v7 3/3] gpio: pca953x: fix address calculation for pcal6524

[Linus Walleij]

On Thu, May 17, 2018 at 6:59 AM, H. Nikolaus Schaller <hns@goldelico.com> wrote:

> The register constants are so far defined in a way that they fit
> for the pcal9555a when shifted by the number of banks, i.e. are
> multiplied by 2 in the accessor function.
>
> Now, the pcal6524 has 3 banks which means the relative offset
> is multiplied by 4 for the standard registers.
>
> Simply applying the bit shift to the extended registers gives
> a wrong result, since the base offset is already included in
> the offset.
>
> Therefore, we have to add code to the 24 bit accessor functions
> that adjusts the register number for these exended registers.
>
> The formula finally used was developed and proposed by
> Andy Shevchenko <andy.shevchenko@gmail.com>.
>
> Suggested-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>

Patch applied.

Yours,
Linus Walleij

Re: [PATCH v7 3/3] gpio: pca953x: fix address calculation for pcal6524

[Pavel Machek]

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

On Thu 2018-05-17 06:59:49, H. Nikolaus Schaller wrote:
> The register constants are so far defined in a way that they fit
> for the pcal9555a when shifted by the number of banks, i.e. are
> multiplied by 2 in the accessor function.
> 
> Now, the pcal6524 has 3 banks which means the relative offset
> is multiplied by 4 for the standard registers.
> 
> Simply applying the bit shift to the extended registers gives
> a wrong result, since the base offset is already included in
> the offset.
> 
> Therefore, we have to add code to the 24 bit accessor functions
> that adjusts the register number for these exended registers.
> 
> The formula finally used was developed and proposed by
> Andy Shevchenko <andy.shevchenko@gmail.com>.
> 
> Suggested-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
> ---
>  drivers/gpio/gpio-pca953x.c | 8 ++++++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
> index c682921d7019..4ad553f4e41f 100644
> --- a/drivers/gpio/gpio-pca953x.c
> +++ b/drivers/gpio/gpio-pca953x.c
> @@ -222,9 +222,11 @@ static int pca957x_write_regs_16(struct pca953x_chip *chip, int reg, u8 *val)
>  static int pca953x_write_regs_24(struct pca953x_chip *chip, int reg, u8 *val)
>  {
>  	int bank_shift = fls((chip->gpio_chip.ngpio - 1) / BANK_SZ);
> +	int addr = (reg & PCAL_GPIO_MASK) << bank_shift;
> +	int pinctrl = (reg & PCAL_PINCTRL_MASK) << 1;

Is this reasonable to do on each register access? Compiler will not be
able to optimize out fls and shifts, right?

								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [PATCH v7 3/3] gpio: pca953x: fix address calculation for pcal6524

[Andy Shevchenko]

On Wed, May 23, 2018 at 5:06 PM, Pavel Machek <pavel@ucw.cz> wrote:
> On Thu 2018-05-17 06:59:49, H. Nikolaus Schaller wrote:
>> The register constants are so far defined in a way that they fit
>> for the pcal9555a when shifted by the number of banks, i.e. are
>> multiplied by 2 in the accessor function.
>>
>> Now, the pcal6524 has 3 banks which means the relative offset
>> is multiplied by 4 for the standard registers.
>>
>> Simply applying the bit shift to the extended registers gives
>> a wrong result, since the base offset is already included in
>> the offset.
>>
>> Therefore, we have to add code to the 24 bit accessor functions
>> that adjusts the register number for these exended registers.
>>
>> The formula finally used was developed and proposed by
>> Andy Shevchenko <andy.shevchenko@gmail.com>.

>>       int bank_shift = fls((chip->gpio_chip.ngpio - 1) / BANK_SZ);
>> +     int addr = (reg & PCAL_GPIO_MASK) << bank_shift;
>> +     int pinctrl = (reg & PCAL_PINCTRL_MASK) << 1;

> Is this reasonable to do on each register access? Compiler will not be
> able to optimize out fls and shifts, right?

On modern CPUs fls() is one assembly command. OTOH, any proposal to do
this better?

What I can see is that bank_shift is invariant to the function, and
maybe cached.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v7 3/3] gpio: pca953x: fix address calculation for pcal6524

[Pavel Machek]

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

On Tue 2018-06-05 18:37:21, Andy Shevchenko wrote:
> On Wed, May 23, 2018 at 5:06 PM, Pavel Machek <pavel@ucw.cz> wrote:
> > On Thu 2018-05-17 06:59:49, H. Nikolaus Schaller wrote:
> >> The register constants are so far defined in a way that they fit
> >> for the pcal9555a when shifted by the number of banks, i.e. are
> >> multiplied by 2 in the accessor function.
> >>
> >> Now, the pcal6524 has 3 banks which means the relative offset
> >> is multiplied by 4 for the standard registers.
> >>
> >> Simply applying the bit shift to the extended registers gives
> >> a wrong result, since the base offset is already included in
> >> the offset.
> >>
> >> Therefore, we have to add code to the 24 bit accessor functions
> >> that adjusts the register number for these exended registers.
> >>
> >> The formula finally used was developed and proposed by
> >> Andy Shevchenko <andy.shevchenko@gmail.com>.
> 
> >>       int bank_shift = fls((chip->gpio_chip.ngpio - 1) / BANK_SZ);
> >> +     int addr = (reg & PCAL_GPIO_MASK) << bank_shift;
> >> +     int pinctrl = (reg & PCAL_PINCTRL_MASK) << 1;
> 
> > Is this reasonable to do on each register access? Compiler will not be
> > able to optimize out fls and shifts, right?
> 
> On modern CPUs fls() is one assembly command. OTOH, any proposal to do
> this better?
> 
> What I can see is that bank_shift is invariant to the function, and
> maybe cached.

Yes, I thought that caching bank_shift might be good idea. I thought
it was constant for given chip...

Best regards,
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [PATCH v7 3/3] gpio: pca953x: fix address calculation for pcal6524

[H. Nikolaus Schaller]

Hi,

> Am 05.06.2018 um 22:39 schrieb Pavel Machek <pavel@ucw.cz>:
> 
> On Tue 2018-06-05 18:37:21, Andy Shevchenko wrote:
>> On Wed, May 23, 2018 at 5:06 PM, Pavel Machek <pavel@ucw.cz> wrote:
>>> On Thu 2018-05-17 06:59:49, H. Nikolaus Schaller wrote:
>>>> The register constants are so far defined in a way that they fit
>>>> for the pcal9555a when shifted by the number of banks, i.e. are
>>>> multiplied by 2 in the accessor function.
>>>> 
>>>> Now, the pcal6524 has 3 banks which means the relative offset
>>>> is multiplied by 4 for the standard registers.
>>>> 
>>>> Simply applying the bit shift to the extended registers gives
>>>> a wrong result, since the base offset is already included in
>>>> the offset.
>>>> 
>>>> Therefore, we have to add code to the 24 bit accessor functions
>>>> that adjusts the register number for these exended registers.
>>>> 
>>>> The formula finally used was developed and proposed by
>>>> Andy Shevchenko <andy.shevchenko@gmail.com>.
>> 
>>>>      int bank_shift = fls((chip->gpio_chip.ngpio - 1) / BANK_SZ);
>>>> +     int addr = (reg & PCAL_GPIO_MASK) << bank_shift;
>>>> +     int pinctrl = (reg & PCAL_PINCTRL_MASK) << 1;
>> 
>>> Is this reasonable to do on each register access? Compiler will not be
>>> able to optimize out fls and shifts, right?
>> 
>> On modern CPUs fls() is one assembly command. OTOH, any proposal to do
>> this better?
>> 
>> What I can see is that bank_shift is invariant to the function, and
>> maybe cached.
> 
> Yes, I thought that caching bank_shift might be good idea. I thought
> it was constant for given chip...

Yes, it is an f(chip), but the question that comes to my mind is if
optimization is worth any effort. This is an accessor method over i2c
which tends to be slow (100 / 400kHz SCL) compared to the CPU. So saving
1 or 2 CPU cycles here doesn't seem to be a significant improvement.
Maybe it is more valuable to improve the code path through the i2c core?

BR,
Nikolaus

Re: [PATCH v7 3/3] gpio: pca953x: fix address calculation for pcal6524

[Pavel Machek]

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

On Wed 2018-06-06 07:33:32, H. Nikolaus Schaller wrote:
> Hi,
> 
> > Am 05.06.2018 um 22:39 schrieb Pavel Machek <pavel@ucw.cz>:
> > 
> > On Tue 2018-06-05 18:37:21, Andy Shevchenko wrote:
> >> On Wed, May 23, 2018 at 5:06 PM, Pavel Machek <pavel@ucw.cz> wrote:
> >>> On Thu 2018-05-17 06:59:49, H. Nikolaus Schaller wrote:
> >>>> The register constants are so far defined in a way that they fit
> >>>> for the pcal9555a when shifted by the number of banks, i.e. are
> >>>> multiplied by 2 in the accessor function.
> >>>> 
> >>>> Now, the pcal6524 has 3 banks which means the relative offset
> >>>> is multiplied by 4 for the standard registers.
> >>>> 
> >>>> Simply applying the bit shift to the extended registers gives
> >>>> a wrong result, since the base offset is already included in
> >>>> the offset.
> >>>> 
> >>>> Therefore, we have to add code to the 24 bit accessor functions
> >>>> that adjusts the register number for these exended registers.
> >>>> 
> >>>> The formula finally used was developed and proposed by
> >>>> Andy Shevchenko <andy.shevchenko@gmail.com>.
> >> 
> >>>>      int bank_shift = fls((chip->gpio_chip.ngpio - 1) / BANK_SZ);
> >>>> +     int addr = (reg & PCAL_GPIO_MASK) << bank_shift;
> >>>> +     int pinctrl = (reg & PCAL_PINCTRL_MASK) << 1;
> >> 
> >>> Is this reasonable to do on each register access? Compiler will not be
> >>> able to optimize out fls and shifts, right?
> >> 
> >> On modern CPUs fls() is one assembly command. OTOH, any proposal to do
> >> this better?
> >> 
> >> What I can see is that bank_shift is invariant to the function, and
> >> maybe cached.
> > 
> > Yes, I thought that caching bank_shift might be good idea. I thought
> > it was constant for given chip...
> 
> Yes, it is an f(chip), but the question that comes to my mind is if
> optimization is worth any effort. This is an accessor method over

It will also be less ugly. Copy&pasted complex exprepsion all over the
driver is not nice.
									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]