Linux-OMAP Archive on
 help / color / Atom feed
From: Trent Piepho <>
To: Tony Lindgren <>
Cc: Drew Fustini <>,
	Rob Herring <>,
	Linus Walleij <>,
	Jason Kridner <>,
	Robert Nelson <>,,,,
	linux-gpio <>,
	Christina Quast <>
Subject: Re: [PATCH] ARM: dts: document pinctrl-single,pins when #pinctrl-cells = 2
Date: Wed, 30 Sep 2020 11:50:10 -0700
Message-ID: <> (raw)
In-Reply-To: <>

On Wed, Sep 30, 2020 at 2:47 AM Tony Lindgren <> wrote:
> * Trent Piepho <> [200930 09:34]:

> >
> > Where do these flags go?  In pinctrl-single,pins?  Like:
> >
> > pinctrl-single,pins = <AM335X_PIN_MDC MUX_MODE7 PIN_INPUT_PULLUP>;
> >
> > But PIN_INPUT_PULLUP is a generic flag?  Which is translated into the
> > proper value by??
> Yes that's what I was thinking, something like this with generic flags:
> pinctrl-single,pins = <AM335X_PIN_MDC (PIN_INPUT | PIN_PULLUP) MUX_MODE7>;

It doesn't seem like these patches help achieve that, since they
create device tree binaries with a property that has the same name and
number of cells, but the cells have a different meaning than above,
and must be handled differently by the driver.  So you either drop
compatibility or need to forever deal with supporting an interim
format that is being created by these patches.

The conf and max are already split in (all but one) of the device tree
SOURCE files via the macro with multiple fields.  That does seem like
a good step if you wanted to transition into something like the above.
But splitting it in the binary too doesn't help.  Is there a way the
dtb now being created can turn into the above via a driver change?
Absolutely not.  So what's the point of an interim binary format?  All
that matters is what the source looks like, and since that doesn't
change, nothing is accomplished.

I'll also point out that the current generic pinconf, done not via
flags but with multiple properties for each configurable parameter,
has a drive strength properties with strength in mA or µA as a
parameter.  How would you do that with generic bit flags?  I don't
think you can fit everything in pinconf-generic.h into one 32 bit

> > Or are you talking about replacing the existing pinctrl-0,
> > pinctrl-names properties with a totally different system that looks
> > more like gpio and interrupt handles?
> That would be even better :) Might be just too much to deal with..
> In any case the parser code could already be generic if we had generic
> flags based on #pinctrl-cells.

But the pinctrl-single,pins isn't parsed.  It just uses the values as
they are.  You'd have to write something to parse the cells and add
more data to the dts that told the parser how to turn them into device
specific values.  It seems like that could eventually achieve
basically what is happening already with the dts preprocessor
converting symbolic constants into device specific values.

  reply index

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-14 10:43 Drew Fustini
2020-09-17  9:03 ` Trent Piepho
2020-09-17  9:20   ` Drew Fustini
2020-09-17 10:00     ` Trent Piepho
2020-09-17 10:39       ` Drew Fustini
2020-09-23  6:57         ` Tony Lindgren
2020-09-24  1:34           ` Trent Piepho
2020-09-24  5:43             ` Tony Lindgren
2020-09-24  5:49               ` Trent Piepho
2020-09-24  6:06                 ` Tony Lindgren
2020-09-24  6:31                   ` Trent Piepho
2020-09-24  7:04                     ` Tony Lindgren
2020-09-29 20:15                       ` Trent Piepho
2020-09-30  5:15                         ` Tony Lindgren
2020-09-30  8:34                           ` Trent Piepho
2020-09-30  9:15                             ` Tony Lindgren
2020-09-30  9:34                               ` Trent Piepho
2020-09-30  9:47                                 ` Tony Lindgren
2020-09-30 18:50                                   ` Trent Piepho [this message]
2020-10-01  7:00                                     ` Tony Lindgren
2020-09-23  6:59 ` Tony Lindgren

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:

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

  git send-email \
    --in-reply-to='' \ \ \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-OMAP Archive on

Archives are clonable:
	git clone --mirror linux-omap/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-omap linux-omap/ \
	public-inbox-index linux-omap

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone