All of lore.kernel.org
 help / color / mirror / Atom feed
From: Aidan MacDonald <aidanmacdonald.0x0@gmail.com>
To: Michael Walle <michael@walle.cc>
Cc: linus.walleij@linaro.org, brgl@bgdev.pl,
	linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org,
	Andy Shevchenko <andy.shevchenko@gmail.com>
Subject: Re: [PATCH 1/3] gpio: regmap: Support registers with more than one bit per GPIO
Date: Mon, 04 Jul 2022 17:01:15 +0100	[thread overview]
Message-ID: <R11Wg2gY4kEFeq6ZSy2mXbGejo7XRfjG@localhost> (raw)
In-Reply-To: <4c9092d20a35ef3fd6a1723e07adad79@walle.cc>


Michael Walle <michael@walle.cc> writes:

> Am 2022-07-03 13:10, schrieb Aidan MacDonald:
>> Some devices use a multi-bit register field to change the GPIO
>> input/output direction. Add the ->reg_field_xlate() callback to
>> support such devices in gpio-regmap.
>> ->reg_field_xlate() builds on ->reg_mask_xlate() by allowing the
>> driver to return a mask and values to describe a register field.
>> gpio-regmap will use the mask to isolate the field and compare or
>> update it using the values to implement GPIO level and direction
>> get and set ops.
>
> Thanks for working on this. Here are my thoughts on how to improve
> it:
>  - I'm wary on the value translation of the set and get, you
>    don't need that at the moment, correct? I'd concentrate on
>    the direction for now.
>  - I'd add a xlate_direction(), see below for an example

Yeah, I only need direction, but there's no advantage to creating a
specific mechanism. I'm not opposed to doing that but I don't see
how it can be done cleanly. Being more general is more consistent
for the API and implementation -- even if the extra flexibility
probably won't be needed, it doesn't hurt.

>  - because we can then handle the value too, we don't need the
>    invert handling in the {set,get}_direction. drop it there
>    and handle it in a simple_xlat. In gpio_regmap,
>    store "reg_dir_base" and "invert_direction", derived from
>    config->reg_dir_in_base and config->reg_dir_out_base.
>

I think this is more complicated and less consistent than handling
reg_dir_in/out_base separately.

> static int gpio_regmap_simple_xlat_direction(struct gpio_regmap *gpio
>                                              unsigend int base,
>                                              unsigned int offset,
>                                              unsigned int *dir_out,
>                                              unsigned int *dir_in)
> {
>     unsigned int line = offset % gpio->ngpio_per_reg;
>     unsigned int mask = BIT(line);
>
>     if (!gpio->invert_direction) {
>         *dir_out = mask;
>         *dir_in = 0;
>     } else {
>         *dir_out = 0;
>         *dir_in = mask;
>     }
>
>     return 0;
> }

This isn't really an independent function: what do *dir_out and *dir_in
mean on their own? You need use the matching mask from ->reg_mask_xlate
for those values to be of any use. And those two functions have to match
up because they need to agree on the same mask.

>
> And in the {set,get}_direction() you can then check both
> values and convert it from or to GPIO_LINE_DIRECTION_{OUT,IN}.

Agreed, checking both values and erroring out if the register has an
unexpected value is a good idea.

>
> Thoughts?
>
> -michael


  reply	other threads:[~2022-07-04 16:00 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-03 11:10 [PATCH 0/3] gpio-regmap support for register fields and other hooks Aidan MacDonald
2022-07-03 11:10 ` [PATCH 1/3] gpio: regmap: Support registers with more than one bit per GPIO Aidan MacDonald
2022-07-03 14:09   ` Andy Shevchenko
2022-07-04 16:03     ` Aidan MacDonald
2022-07-04 12:28   ` Michael Walle
2022-07-04 16:01     ` Aidan MacDonald [this message]
2022-07-04 19:46       ` Michael Walle
2022-07-06 20:46         ` Aidan MacDonald
2022-07-07  7:44           ` Michael Walle
2022-07-07 14:58             ` Aidan MacDonald
2022-07-03 11:10 ` [PATCH 2/3] gpio: regmap: Support combined GPIO and pin control drivers Aidan MacDonald
2022-07-03 14:14   ` Andy Shevchenko
2022-07-04 15:31     ` Aidan MacDonald
2022-07-03 11:10 ` [PATCH 3/3] gpio: regmap: Support a custom ->to_irq() hook Aidan MacDonald
2022-07-03 14:24   ` Andy Shevchenko
2022-07-04 16:38     ` Aidan MacDonald
2022-07-04 23:05   ` Linus Walleij
2022-07-05 11:09     ` Aidan MacDonald
2022-07-06 11:45       ` Andy Shevchenko
2022-07-06 20:53         ` Aidan MacDonald
2022-07-06 12:02       ` Linus Walleij
2022-07-06 13:50         ` Aidan MacDonald
2022-07-11 11:48           ` Linus Walleij

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=R11Wg2gY4kEFeq6ZSy2mXbGejo7XRfjG@localhost \
    --to=aidanmacdonald.0x0@gmail.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=brgl@bgdev.pl \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michael@walle.cc \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.