Linux-OMAP Archive on lore.kernel.org
 help / color / Atom feed
From: Tony Lindgren <tony@atomide.com>
To: Trent Piepho <tpiepho@gmail.com>
Cc: Drew Fustini <drew@beagleboard.org>,
	Rob Herring <robh+dt@kernel.org>,
	Linus Walleij <linus.walleij@linaro.org>,
	Jason Kridner <jkridner@beagleboard.org>,
	Robert Nelson <robertcnelson@gmail.com>,
	linux-omap@vger.kernel.org, linux-kernel@vger.kernel.org,
	devicetree@vger.kernel.org,
	linux-gpio <linux-gpio@vger.kernel.org>,
	Christina Quast <cquast@hanoverdisplays.com>
Subject: Re: [PATCH] ARM: dts: document pinctrl-single,pins when #pinctrl-cells = 2
Date: Wed, 30 Sep 2020 08:15:21 +0300
Message-ID: <20200930051521.GN9471@atomide.com> (raw)
In-Reply-To: <CA+7tXihBdw9AOGL7Hp2cH9+ii8fUXaaZZDUP3icyeOkMuGm4qA@mail.gmail.com>

* Trent Piepho <tpiepho@gmail.com> [200929 20:16]:
> On Thu, Sep 24, 2020 at 12:04 AM Tony Lindgren <tony@atomide.com> wrote:
> > Certainly different compatible strings can be used as needed.
> > But pinctrl-single is not going to be am335x specific though :)
> > We have quite a few SoCs using it:
> 
> So what doesn't make sense to me, is to put something am335x specific
> like two cells for conf and mux, into a generic driver like pinctrl
> single.

Treating conf and mux separately is not am335x specific. Linux treats
them separately because the conf options typically can be described
in a generic way while the mux is just signal routing.

Sure the conf values are currently not generic, but that could be
done if wanted to and added some property to specify that the
controller uses generic conf values.

> This series adds two cells ORed into one.  Ok, that's generic, other
> platforms could use it.  But it also accomplishes nothing, so what's
> the point?  You've hinted there is more to come, which will accomplish
> something, but what is it?  That can be:
> Used by platforms other than am335x
> Can't already be done with the pinctrl single pinconf features
> Needs more than one data cell per pin

For SoCs using #pinctrl-cells = <2> we now have conf and mux values
separated in the dtb. Certainly that's a better place to be compared
to earlier for any further pinconf changes.

> Interrupt controllers have different numbers of cells, but they are
> all platform specific, and the cells have defined platform specific
> meanings.  pci-host-cam-generic is a somewhat generic interrupt
> controller and it uses 1 cell, since it lacks device specific fields
> to put into additional cells.

With interrupts the IRQ_TYPE flags are generic and separate from the
hardware specific cells. If we wanted to, we could have something
similar for pinctrl framework.

> Consider also that any future changes to the pinctrl-single bindings
> would need to be backward compatible with a device tree binary where
> two cells get combined.  So if the bindings being added here aren't
> done, then adding them now creates an unnecessary additional version
> to deal with for backward compatibility.

I don't see issues with backward compabilty. If we specify that the
controller uses #pinctrl-cells = <2>, and some additional property
for specifying generic conf flags, we'd have a similar generic binding
to the interrupt binding.

Regards,

Tony

  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 [this message]
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
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:
  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=20200930051521.GN9471@atomide.com \
    --to=tony@atomide.com \
    --cc=cquast@hanoverdisplays.com \
    --cc=devicetree@vger.kernel.org \
    --cc=drew@beagleboard.org \
    --cc=jkridner@beagleboard.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=robertcnelson@gmail.com \
    --cc=robh+dt@kernel.org \
    --cc=tpiepho@gmail.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

Linux-OMAP Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-omap/0 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/ https://lore.kernel.org/linux-omap \
		linux-omap@vger.kernel.org
	public-inbox-index linux-omap

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-omap


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git