From: Marco Felsch <m.felsch@pengutronix.de>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@vger.kernel.org>,
Support Opensource <support.opensource@diasemi.com>,
"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
Bartosz Golaszewski <bgolaszewski@baylibre.com>,
Rob Herring <robh+dt@kernel.org>,
Sascha Hauer <kernel@pengutronix.de>,
Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
Subject: Re: [PATCH 3/3] gpio: da9062: add driver support
Date: Wed, 9 Oct 2019 11:56:12 +0200 [thread overview]
Message-ID: <20191009095612.einxiswkmhvipjht@pengutronix.de> (raw)
In-Reply-To: <20191007085159.uo366hmos6zk2ops@pengutronix.de>
Hi Linus,
On 19-10-07 10:51, Marco Felsch wrote:
> Hi Linus,
>
> thanks for you feedback.
>
> On 19-10-04 21:27, Linus Walleij wrote:
> > On Tue, Sep 17, 2019 at 12:59 PM Marco Felsch <m.felsch@pengutronix.de> wrote:
> >
> > > +static int da9062_gpio_direction_input(struct gpio_chip *gc,
> > > + unsigned int offset)
> > > +{
> > > + struct da9062_gpio *gpio = gpiochip_get_data(gc);
> > > + struct regmap *regmap = gpio->da9062->regmap;
> > > + struct gpio_desc *desc = gpiochip_get_desc(gc, offset);
This won't work anymore since I moved the driver to pinctrl and can't
include the drivers/gpio/gpiolib.h anymore. What is the right way to
get the same result within the pinctrl space? There are three possible
ways:
1) Revert commit 1bd6b601fe196b6fbce2c93536ce0f3f53577cec which isn't
the best due to safeness.
2) Set the gpio as active low hard as the other da90*-gpio drivers did
3) Introduce a dt-binding (seems wrong because the information is
already there).
4) "Re-implement" the gpiochip_get_desc() functionality driver
internally.
Thanks for your advice.
Regards,
Marco
> > > + unsigned int gpi_type;
> > > + int ret;
> > > +
> > > + ret = da9062_gpio_set_pin_mode(regmap, offset, DA9062_PIN_GPI);
> > > + if (ret)
> > > + return ret;
> >
> > Fair enough.
> >
> > > + /*
> > > + * If the gpio is active low we should set it in hw too. No worries
> > > + * about gpio_get() because we read and return the gpio-level. So the
> > > + * gpiolob active_low handling is still correct.
> >
> > gpiolib?
>
> Thanks for covering that.
>
> > > + *
> > > + * 0 - active low, 1 - active high
> > > + */
> > > + gpi_type = !gpiod_is_active_low(desc);
> > > + return regmap_update_bits(regmap, DA9062AA_GPIO_0_1 + (offset >> 1),
> > > + DA9062AA_GPIO0_TYPE_MASK << DA9062_TYPE(offset),
> > > + gpi_type << DA9062_TYPE(offset));
> > > +}
> >
> > So this does not affect the value out set by da9062_gpio_set()?
>
> Please check [1] table 54, the datasheet says it is only gpi
> (gpio-input). So I assume it doesn't affect out values.
>
> [1] https://www.dialog-semiconductor.com/sites/default/files/da9062-a_datasheet_2v3.pdf
>
> Unfortunately the other gpio-da90* drivers sets this as active low hard
> within the driver. I wanted to avoid this here since it isn't always
> true.
>
> > What is the electrical effect of this then, really? To me that seems like
> > something that is mostly going to be related to how interrupts
> > trigger (like whether to trig on rising or falling edge) and then it
> > should really be in the .set_type() callback, should it not?
>
> Not only interrupts.. The dialog pmics has a lot of options to use this
> pins e.g. you can set it as voltage-selection input. You saw the patches
> I made for the regulator :)
next prev parent reply other threads:[~2019-10-09 9:56 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-17 10:58 [PATCH 0/3] Add DA9062 GPIO support Marco Felsch
2019-09-17 10:59 ` [PATCH 1/3] dt-bindings: mfd: da9062: add gpio bindings Marco Felsch
2019-09-24 10:53 ` Adam Thomson
2019-10-04 19:06 ` Linus Walleij
2019-09-17 10:59 ` [PATCH 2/3] mfd: da9062: add support for the DA9062 GPIOs in the core Marco Felsch
2019-09-17 10:59 ` [PATCH 3/3] gpio: da9062: add driver support Marco Felsch
2019-09-18 7:04 ` Bartosz Golaszewski
2019-09-18 12:06 ` Marco Felsch
2019-09-19 8:24 ` Bartosz Golaszewski
2019-09-19 8:38 ` Marco Felsch
2019-09-30 18:42 ` Marco Felsch
2019-10-03 8:12 ` Bartosz Golaszewski
2019-10-04 8:25 ` Bartosz Golaszewski
2019-10-04 19:27 ` Linus Walleij
2019-10-07 8:51 ` Marco Felsch
2019-10-09 9:56 ` Marco Felsch [this message]
2019-10-09 10:17 ` Marco Felsch
2019-10-16 11:44 ` 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=20191009095612.einxiswkmhvipjht@pengutronix.de \
--to=m.felsch@pengutronix.de \
--cc=Adam.Thomson.Opensource@diasemi.com \
--cc=bgolaszewski@baylibre.com \
--cc=devicetree@vger.kernel.org \
--cc=kernel@pengutronix.de \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=robh+dt@kernel.org \
--cc=support.opensource@diasemi.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).