RE: [PATCH v3 3/7] gpio: regmap: Add gpio_regmap_operation and write-enable support

[Yu-Chun Lin <eleanor.lin@realtek.com>]

Hi all,

>> > @@ -185,7 +218,7 @@ static int gpio_regmap_set_direction(struct
>> gpio_chip *chip,
>> >                                    unsigned int offset, bool output)
>> > {
>> >       struct gpio_regmap *gpio = gpiochip_get_data(chip);
>> > -     unsigned int base, val, reg, mask;
>> > +     unsigned int base, val, reg, mask, wren_mask;
>> >       int invert, ret;
>> >
>> >       if (gpio->reg_dir_out_base) {
>> > @@ -198,7 +231,12 @@ static int gpio_regmap_set_direction(struct
>> gpio_chip *chip,
>> >               return -ENOTSUPP;
>> >       }
>> >
>> > -     ret = gpio->reg_mask_xlate(gpio, base, offset, &reg, &mask);
>> > +     ret = gpio->reg_mask_xlate(gpio, GPIO_REGMAP_SET_DIR_OP, base,
>> offset, &reg, &mask);
>> > +     if (ret)
>> > +             return ret;
>> > +
>> > +     ret = gpio->reg_mask_xlate(gpio, GPIO_REGMAP_SET_DIR_WREN_OP,
>> base, offset, &reg,
>> > +                                &wren_mask);
>> 
>> What constrains these two to provide the same value back for reg?
>> To me it seems like the write enable might well be in a different register.
>> 
>> >       if (ret)
>> >               return ret;
>> >
>> > @@ -207,7 +245,7 @@ static int gpio_regmap_set_direction(struct
>> gpio_chip *chip,
>> >       else
>> >               val = output ? mask : 0;
>> >
>> > -     return regmap_update_bits(gpio->regmap, reg, mask, val);
>> > +     return regmap_update_bits(gpio->regmap, reg, mask | wren_mask,
>> > + val | wren_mask);
>> >  }
>> >
>> >  static int gpio_regmap_direction_input(struct gpio_chip *chip,
>
> My initial design indeed assumed that the WREN mask and Data mask reside in
> the same register.
>  
> Regarding WREN support, especially if WREN and Data use separate registers, I
> came up with three ideas. Which direction do you prefer?
>  
> Approach 1: Provide Custom Callbacks in config (Let consumer driver handle it)
> We can add '.set' and '.set_direction' function pointers in
> 'struct gpio_regmap_config'. If a driver requires WREN, it can implement these
> callbacks itself.
> 
> static void gpio_regmap_set(struct gpio_chip *chip, unsigned int offset, int val)
> {
>         struct gpio_regmap *gpio = gpiochip_get_data(chip);
>  
>         /* If the driver provides a custom set (to handle WREN), delegate to it */
>         if (gpio->set) {
>                 gpio->set(chip, offset, val);
>                 return;
>         }
>         /* ... existing generic regmap logic ... */
> }
>
> Pros: Clean core, no need to touch existing drivers' xlate signature. The consumer
> driver handles its own locking for different registers.
> Cons: It feels a bit strange and inconsistent to expose only '.set' and
> '.set_direction' overrides while keeping other operations entirely abstracted.
>  
> Approach 2: Handle separate WREN register in the core (with locking concerns)
> We keep the 'XX_WREN_OP' in 'xlate'. If someone needs WREN and 'wren_reg != reg',
> we write to both.
>  
> static int gpio_regmap_set(struct gpio_chip *chip, unsigned int offset,
>                            int val)
> {
>         /* skip */
>         ret = gpio->reg_mask_xlate(gpio, GPIO_REGMAP_SET_WREN_OP, base, offset, &wren_reg,
>                                    &wren_mask);
>         if (ret == -ENOTSUPP)
>                 has_wren = false;
>         else if (ret)
>                 return ret;
> 
>        ret = gpio->reg_mask_xlate(gpio, GPIO_REGMAP_SET_OP, base, offset, &reg, &mask);
> 
>        if (has_wren && reg == wren_reg) {
>                mask |= wren_mask;
>                mask_val |= wren_mask;
>                has_wren = false;
>        }
> 
>        if (has_wren)
>                ret = regmap_set_bits(gpio->regmap, wren_reg, wren_mask); 
> 
>         /* ignore input values which shadow the old output value */
>         if (gpio->reg_dat_base == gpio->reg_set_base)
>                 ret = regmap_write_bits(gpio->regmap, reg, mask, mask_val);
>         else
>                 ret = regmap_update_bits(gpio->regmap, reg, mask, mask_val);
>  
>         return ret;
> }
>  
> Pros: Keeps all WREN logic unified inside the core framework.
> Cons: Introduces a locking issue. writing to 'wren_reg' and then 'reg' requires an
> external lock to be atomic, which seems to defeat the purpose of relying on regmap's
> internal lock. 
> 
> Approach 3: Assume WREN and Data always share the same register
> 
> static int gpio_regmap_set(struct gpio_chip *chip, unsigned int offset, int val)
> {
>         /* ... */
>         ret = gpio->reg_mask_xlate(gpio, GPIO_REGMAP_SET_WREN_OP, base, offset, &reg, &wren_mask);
>         if (ret == -ENOTSUPP)
>                 wren_mask = 0;
>         else if (ret)
>                 return ret;
>  
>         ret = gpio->reg_mask_xlate(gpio, GPIO_REGMAP_SET_OP, base, offset, &reg, &mask);
>  
>         ret = regmap_update_bits(gpio->regmap, reg, mask | wren_mask, mask_val | wren_mask);
>         return ret;
> }
>  
> Regarding this approach, I would like to ask from your experience: Is it
> actually common for hardware designs to place WREN and Data bits in completely
> different registers for GPIO operations?
> 
> If they practically always share the same register, this simpler approach might
> suffice.
>  
> Best Regards,
> Yu Chun Lin
> 

If there are no further concerns, I will proceed with the third approach and
send out v6.

Thanks.
Yu-Chun