mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Michael Walle <michael@walle.cc>
To: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Cc: linux-kernel@vger.kernel.org, linux-gpio@vger.kernel.org,
	Linus Walleij <linus.walleij@linaro.org>,
	Bartosz Golaszewski <bgolaszewski@baylibre.com>,
	Mark Brown <broonie@kernel.org>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Subject: Re: [PATCH v4 2/2] gpio: add a reusable generic gpio_chip using regmap
Date: Thu, 28 May 2020 06:07:02 +0200	[thread overview]
Message-ID: <143ec2f44c881706db9744465328329f@walle.cc> (raw)
In-Reply-To: <fe44039a-4fa9-dab3-cd14-04967b729158@linux.intel.com>

Hi,

Am 2020-05-28 02:31, schrieb Pierre-Louis Bossart:
> Hi Michael,
> 
>>>> +struct gpio_regmap_config {
>>>> +    struct device *parent;
>>>> +    struct regmap *regmap;
>>>> +
>>>> +    const char *label;
>>>> +    int ngpio;
>>> 
>>> could we add a .names field for the gpio_chip, I found this useful 
>>> for
>>> PCM512x GPIO support, e.g.
>> 
>> Sure, I have the names in the device tree.
>> 
>> But I'd prefer that you'd do a patch on top of this (assuming it is
>> applied soon), because you can actually test it and there might be
>> missing more.
> 
> I am happy to report that this gpio-regmap worked like a charm for me,
> after I applied the minor diff below (complete code at
> https://github.com/plbossart/sound/tree/fix/regmap-gpios).
> 
> I worked around my previous comments by forcing the GPIO internal
> routing directly in regmap, and that allowed me to only play with the
> _set and _dir bases. I see the LEDs and clock selected as before,
> quite nice indeed.
> 
> The chip->label test is probably wrong, since the gpio_chip structure
> is zeroed out if(!chip->label) is always true so the label is always
> set to the device name. I don't know what the intent was so just
> removed that test - maybe the correct test should be if
> (!config->label) ?

yes, that was a typo. should have been if (!config->label).

I've send a v5 with that fix and your names property.

> I added the names support as well, and btw I don't understand how one
> would get them through device tree?

gpio-line-names property, see
Documentation/devicetree/bindings/gpio/gpio.txt.

> I still have a series of odd warnings I didn't have before:
> 
> [  101.400263] WARNING: CPU: 3 PID: 1129 at
> drivers/gpio/gpiolib.c:4084 gpiod_set_value+0x3f/0x50
> 
> This seems to come from
> 	/* Should be using gpiod_set_value_cansleep() */
> 	WARN_ON(desc->gdev->chip->can_sleep);

Right now, gpio-regmap hardcodes can_sleep to true. But the only regmap
which don't sleep is regmap-mmio. The PCM512x seems to be either I2C or
SPI, which can both sleep. So this warning is actually correct and
wherever this gpio is set should do it by calling the _cansleep()
version.

> so maybe we need an option here as well? Or use a different function?
> 
> Anyways, that gpio-regmap does simplify my code a great deal so thanks
> for this work, much appreciated.

Glad to see that there are more users for it ;)

-michael

  reply	other threads:[~2020-05-28  4:07 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-25 16:07 [PATCH v4 0/2] gpio: generic regmap implementation Michael Walle
2020-05-25 16:07 ` [PATCH v4 1/2] gpiolib: Introduce gpiochip_irqchip_add_domain() Michael Walle
2020-05-25 16:07 ` [PATCH v4 2/2] gpio: add a reusable generic gpio_chip using regmap Michael Walle
     [not found]   ` <d245b4f5-065f-4c82-ef8e-d906b363fdcf@linux.intel.com>
2020-05-26 21:27     ` Michael Walle
2020-05-28  0:31       ` Pierre-Louis Bossart
2020-05-28  4:07         ` Michael Walle [this message]
2020-05-28  8:37           ` Andy Shevchenko
2020-05-28  8:46             ` Michael Walle
2020-05-28 10:08               ` Andy Shevchenko
2020-05-27 13:20 ` [PATCH v4 0/2] gpio: generic regmap implementation Bartosz Golaszewski

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=143ec2f44c881706db9744465328329f@walle.cc \
    --to=michael@walle.cc \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=bgolaszewski@baylibre.com \
    --cc=broonie@kernel.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pierre-louis.bossart@linux.intel.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

all inboxes | Powered by JetHome®