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>
Subject: Re: [PATCH v4 2/2] gpio: add a reusable generic gpio_chip using regmap
Date: Tue, 26 May 2020 23:27:57 +0200	[thread overview]
Message-ID: <6d08ebbfbc9f656cb5650ede988cf36d@walle.cc> (raw)
In-Reply-To: <d245b4f5-065f-4c82-ef8e-d906b363fdcf@linux.intel.com>

Hi,

Am 2020-05-26 19:29, schrieb Pierre-Louis Bossart:
>> +struct gpio_regmap {
>> +    struct device *parent;
>> +    struct regmap *regmap;
>> +    struct gpio_chip gpio_chip;
>> +
>> +    int reg_stride;
>> +    int ngpio_per_reg;
>> +    unsigned int reg_dat_base;
>> +    unsigned int reg_set_base;
>> +    unsigned int reg_clr_base;
>> +    unsigned int reg_dir_in_base;
>> +    unsigned int reg_dir_out_base;
> 
> I wonder if a base is enough, shouldn't there be a 'last' or something
> that constrains the range of regmap addresses to be used for gpios?

This should be covered on the regmap, shouldn't it?

> related question since I couldn't figure out how to convert my PCM512x
> example, where there are 6 GPIOs configured with 3 regmap-visible
> registers [1], to this mapping.
> 
> GPIO_EN defines if the GPIO is used or not (each bitfield is tied to a
> GPIO)
> 
> GPIO_CONTROL_1 defines the level (each bitfield is tied to a GPIO)
> 
> GPIO_OUTPUT_1+offset defines what signal is routed to each GPIO. I am
> really not sure how this part would be handled?
> 
> That's 8 registers total to deal with GPIOs.

Looks like you need a custom xlate function:

int pcm512x_gpio_regmap_xlate(struct gpio_regmap *gpio, unsigned int 
base,
                               unsigned int offset, unsigned int *reg,
                               unsigned int *mask)
{
   switch (base)
   case GPIO_EN:
   case GPIO_CONTROL_1:
      *reg = base;
      *mask = (1 << offset);
      break;
   case GPIO_OUTPUT_1:
      *reg = base + offset;
      *mask = ...
      break;
}

base is always one of the xx_base properties in the "struct
gpio_regmap_config".

>> +/**
>> + * struct gpio_regmap_config - Description of a generic regmap
>> gpio_chip.
>> + *
>> + * @parent:        The parent device
>> + * @regmap:        The regmap used to access the registers
>> + *            given, the name of the device is used
>> + * @label:        (Optional) Descriptive name for GPIO controller.
>> + *            If not given, the name of the device is used.
>> + * @ngpio:        Number of GPIOs
>> + * @reg_dat_base:    (Optional) (in) register base address
>> + * @reg_set_base:    (Optional) set register base address
>> + * @reg_clr_base:    (Optional) clear register base address
>> + * @reg_dir_in_base:    (Optional) in setting register base address
>> + * @reg_dir_out_base:    (Optional) out setting register base
>> address
>> + * @reg_stride:        (Optional) May be set if the registers (of
>> the
>> + *            same type, dat, set, etc) are not consecutive.
>> + * @ngpio_per_reg:    Number of GPIOs per register
>> + * @irq_domain:        (Optional) IRQ domain if the controller is
>> + *            interrupt-capable
>> + * @reg_mask_xlate:     (Optional) Translates base address and GPIO
>> + *            offset to a register/bitmask pair. If not
>> + *            given the default gpio_regmap_simple_xlate()
>> + *            is used.
>> + *
>> + * The reg_mask_xlate translates a given base address and GPIO
>> offset to
>> + * register and mask pair. The base address is one of the given
>> reg_*_base.
>> + *
>> + * All base addresses may have the special value
>> GPIO_REGMAP_ADDR_ZERO
>> + * which forces the address to the value 0.
>> + */
>> +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.

[snip]

-michael

  parent reply	other threads:[~2020-05-26 21:28 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 [this message]
2020-05-28  0:31       ` Pierre-Louis Bossart
2020-05-28  4:07         ` Michael Walle
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=6d08ebbfbc9f656cb5650ede988cf36d@walle.cc \
    --to=michael@walle.cc \
    --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

Powered by JetHome