All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Bedel, Alban" <alban.bedel@aerq.com>
To: "linus.walleij@linaro.org" <linus.walleij@linaro.org>
Cc: "linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
	"bgolaszewski@baylibre.com" <bgolaszewski@baylibre.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] gpio: pca953x: add support for open drain pins on PCAL6524
Date: Tue, 2 Feb 2021 17:45:21 +0000	[thread overview]
Message-ID: <93036ef781d20df4c6017178cc545702bd0f42bc.camel@aerq.com> (raw)
In-Reply-To: <CACRpkdaP8-mnXuBZRKad53tvGrS0BdfTRKNezr0mhRVf8qkYig@mail.gmail.com>

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

On Tue, 2021-02-02 at 14:57 +0100, Linus Walleij wrote:
> On Thu, Jan 28, 2021 at 4:36 PM Alban Bedel <alban.bedel@aerq.com>
> wrote:
> 
> > From a quick glance at various datasheet the PCAL6524 seems to be
> > the
> > only chip in this familly that support setting the drive mode of
> > single pins. Other chips either don't support it at all, or can
> > only
> > set the drive mode of whole banks, which doesn't map to the GPIO
> > API.
> > 
> > Add a new flag, PCAL6524, to mark chips that have the extra
> > registers
> > needed for this feature. Then mark the needed register banks as
> > readable and writable, here we don't set OUT_CONF as writable,
> > although it is, as we only need to read it. Finally add a function
> > that configure the OUT_INDCONF register when the GPIO API set the
> > drive mode of the pins.
> > 
> > Signed-off-by: Alban Bedel <alban.bedel@aerq.com>
> 
> Thats's nice!
> 
> > + *     Output port configuration       0x40 + 7 * bank_size    R
> > + *
> > + *   - PCAL6524 with individual pin configuration
> > + *     Individual pin output config    0x40 + 12 * bank_size   RW
> 
> So this will become 0x70? It's a bit hard for me this weird
> register layout...

Correct.

> > +static int pcal6524_gpio_set_drive_mode(struct pca953x_chip *chip,
> > +                                       unsigned int offset,
> > +                                       unsigned long config)
> > +{
> > +       u8 out_conf_reg = pca953x_recalc_addr(
> > +               chip, PCAL953X_OUT_CONF, 0);
> > +       u8 out_indconf_reg = pca953x_recalc_addr(
> > +               chip, PCAL6524_OUT_INDCONF, offset);
> > +       u8 mask = BIT(offset % BANK_SZ), val;
> 
> Split to two variable declarations please, this is hard to read.

Will do.

> > +       unsigned int out_conf;
> > +       int ret;
> 
> So we set mask to the bit index for the line we want to affect.
> 
> > +       if (config == PIN_CONFIG_DRIVE_OPEN_DRAIN)
> > +               val = mask;
> > +       else if (config == PIN_CONFIG_DRIVE_PUSH_PULL)
> > +               val = 0;
> > +       else
> > +               return -EINVAL;
> 
> And this makes sense, we set it to 1 to enable open drain.
> 
> > +       /* Invert the value if ODENn is set */
> > +       ret = regmap_read(chip->regmap, out_conf_reg, &out_conf);
> > +       if (ret)
> > +               goto exit;
> > +       if (out_conf & BIT(offset / BANK_SZ))
> 
> I suppose this could be written if (out_conf & mask)?

No, the mask in ODENn is per bank (group of 8 pins) and not per pin.

> > +               val ^= mask;
> 
> Invert? Why?
> 
> The datasheet says:
> 
>   "If the ODENx bit is set at logic 0 (push-pull), any bit set to
> logic 1
>   in the IOCRx register will reverse the output state of that pin
> only
>   to open-drain. When ODENx bit is set at logic 1 (open-drain), a
>   logic 1 in IOCRx will set that pin to push-pull."
> 
> So your logic is accounting for the fact that someone go and set
> one of the bits in ODENx to 1, but aren't they all by default set
> to zero (or should be programmed by the driver to zero)
> so that you can control open drain individually here by simply
> setting the corresponding bit to 1 for open drain and 0 for
> push-pull?

Yes the ODENx bits are 0 by default, but the bootloader might have
changed them for example. Currently the driver doesn't do any reset so
I think it make sense to correctly handle this case as it doesn't bring
that much extra complexity.

Alban

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2021-02-02 17:49 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-28 15:36 [PATCH] gpio: pca953x: add support for open drain pins on PCAL6524 Alban Bedel
2021-02-02 11:42 ` Bartosz Golaszewski
2021-02-02 17:45   ` Bedel, Alban
2021-02-03 10:12   ` Andy Shevchenko
2021-02-02 13:57 ` Linus Walleij
2021-02-02 17:45   ` Bedel, Alban [this message]
2021-02-02 19:21     ` Linus Walleij
2021-02-03 10:10 ` Andy Shevchenko

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=93036ef781d20df4c6017178cc545702bd0f42bc.camel@aerq.com \
    --to=alban.bedel@aerq.com \
    --cc=bgolaszewski@baylibre.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /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.