linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: jamie@jamieiles.com (Jamie Iles)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 10/12] arm/tegra: Add device tree support to pinmux driver
Date: Mon, 15 Aug 2011 21:50:42 +0100	[thread overview]
Message-ID: <20110815205042.GC22355@gallagher> (raw)
In-Reply-To: <74CDBE0F657A3D45AFBB94109FB122FF04AEA25174@HQMAIL01.nvidia.com>

On Mon, Aug 15, 2011 at 01:44:53PM -0700, Stephen Warren wrote:
> Jamie Iles wrote at Monday, August 15, 2011 2:36 PM:
> > On Mon, Aug 15, 2011 at 09:07:16PM +0100, Jamie Iles wrote:
> > > Hi Stephen,
> > >
> > > On Fri, Aug 12, 2011 at 04:54:55PM -0600, Stephen Warren wrote:
> > > > Signed-off-by: Stephen Warren <swarren@nvidia.com>
> ...
> > > > diff --git a/arch/arm/mach-tegra/pinmux.c b/arch/arm/mach-tegra/pinmux.c
> ...
> > > > +static void __init tegra_pinmux_probe_dt(struct platform_device *pdev)
> > > > +{
> > > > +	int pg;
> > > > +
> > > > +	for (pg = 0; pg < TEGRA_MAX_PINGROUP; pg++) {
> > > > +		const char *pg_name = pingroup_name(pg);
> > > > +		struct tegra_pingroup_config config;
> > > > +		struct device_node *pg_node;
> > > > +		int ret;
> > > > +		const char *s;
> > > > +
> > > > +		pg_node = of_find_child_node_by_name(pdev->dev.of_node,
> > > > +						     pg_name);
> > > > +		if (pg_node == NULL)
> > > > +			continue;
> > > > +
> > > > +		config.pingroup = pg;
> > > > +
> > > > +		ret = of_property_read_string(pg_node, "nvidia,function", &s);
> ...
> > > > +		ret = of_property_read_string(pg_node, "nvidia,pull", &s);
> ...
> > > > +		if (of_find_property(pg_node, "nvidia,tristate", NULL))
> ...
> > > > +		tegra_pinmux_config_pingroup(&config);
> > > > +
> > > > +		of_node_put(pg_node);
> > > > +	}
> > > > +}
> > >
> > > I need to implement DT muxing configuration for my platform, and I believe
> > > that what you have here would work fine for me too, and to avoid duplicating
> > > the same thing, I wonder if this could be a little more generic.
> > >
> > > So if the platform specific pinmux driver called the pinmux parser with a
> > > callback for a pingroup configuration function then this wouldn't need the
> > > nvidia specific properties.  I'd envisage the setup callback to be something
> > > like:
> > >
> > > 	int pingroup_configure(const char *name, unsigned long flags);
> > 
> > and it if this took the device_node too then the platform specific bits could
> > handle more esoteric properties if required.  I'll have a go at prototyping
> > this tomorrow unless there are any obvious reasons that this is a stupid idea!
> 
> I expect some of the code could be shared.
> 
> The only worry I have is whether some SoCs don't configure things like
> pinmux function in the same place as pad function (pullup/down, tristate),
> and hence whether a generic binding is generally applicable. I suppose the
> code could always ignore unused properties.

Yes, well our hardware doesn't support any of these features other than 
setting the function so in the picoxcell backend I'd just WARN_ON() invalid 
flags settings.

> I wonder how much of this is relevant to Linus W's pinctrl API?

Hmm, not sure on that one, it's been a while since I've looked at Linus' 
patches.

> Note that in the updated patch series I just posted, I reworked the binding
> a little; Tegra has two sets of pin-groups, one configuring muxing, pullup/
> down, and tri-state, and the other configuring various driver strength/
> rate properties. Hence, the tree is now e.g.:
> 
> 	pinmux: pinmux at 70000000 {
> 		compatible = "nvidia,tegra20-pinmux";
> 		reg = < 0x70000000 0xc00 >;
> 		nvidia,mux-groups {
> 			cdev1 {
> 				nvidia,function = "plla_out";
> 			};
> 			cdev2 {
> 				nvidia,function = "pllp_out4";
> 				nvidia,pull-down;
> 				nvidia,tristate;
> 			};
> 		};
> 		nvidia,drive-groups {
> 			sdio1 {
> 				nvidia,schmitt;
> 				nvidia,drive-power = <1>;
> 				nvidia,pull-down-strength = <31>;
> 				nvidia,pull-up-strength = <31>;
> 				nvidia,slew-rate-rising = <3>;
> 				nvidia,slew-rate-falling = <3>;
> 			};
> 		};
> 	};
> 
> But it's probably still reasonably easy to make the parser for the mux-groups
> node generic. Perhaps it makes sense for all SoCs to have a "mux-settings"
> node, even if they don't have any other custom nodes?

You have a much more complex chip than I do!  I don't know if *all* SoC's have 
to have the same muxing binding, but it feels that this one should cover a lot 
of the most common bases.

Jamie

  reply	other threads:[~2011-08-15 20:50 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-12 22:54 [RFC PATCH 00/12] arm/tegra: Initialize GPIO & pinmux from DT Stephen Warren
2011-08-12 22:54 ` [RFC PATCH 01/12] dt: Add of_find_child_node_by_name() Stephen Warren
2011-08-12 22:54 ` [RFC PATCH 02/12] arm/tegra: Prep boards for gpio/pinmux conversion to pdevs Stephen Warren
2011-08-12 22:54 ` [RFC PATCH 03/12] arm/tegra: Avoid duplicate gpio/pinmux devices with dt Stephen Warren
2011-08-12 22:54 ` [RFC PATCH 04/12] arm/tegra: board-dt: Add AUXDATA for tegra-gpio and tegra-pinmux Stephen Warren
2011-08-12 22:54 ` [RFC PATCH 05/12] arm/dt: Tegra: Add nvidia, gpios property to GPIO controller Stephen Warren
2011-08-14  7:01   ` [RFC PATCH 05/12] arm/dt: Tegra: Add nvidia,gpios " Olof Johansson
2011-08-15 16:15     ` Stephen Warren
2011-08-12 22:54 ` [RFC PATCH 06/12] arm/dt: Tegra: Add pinmux node Stephen Warren
2011-08-14  7:24   ` Olof Johansson
2011-08-15 16:41     ` Stephen Warren
2011-08-12 22:54 ` [RFC PATCH 07/12] gpio/tegra: Convert to a platform device Stephen Warren
2011-08-12 22:54 ` [RFC PATCH 08/12] gpio/tegra: Add device tree support Stephen Warren
2011-08-13  9:49   ` Belisko Marek
2011-08-15 15:47     ` Stephen Warren
2011-08-12 22:54 ` [RFC PATCH 09/12] arm/tegra: Convert pinmux driver to a platform device Stephen Warren
2011-08-12 22:54 ` [RFC PATCH 10/12] arm/tegra: Add device tree support to pinmux driver Stephen Warren
2011-08-13 10:43   ` Jamie Iles
2011-08-13 10:48     ` Jamie Iles
2011-08-15 16:09       ` Stephen Warren
2011-08-15 20:07   ` Jamie Iles
2011-08-15 20:36     ` Jamie Iles
2011-08-15 20:44       ` Stephen Warren
2011-08-15 20:50         ` Jamie Iles [this message]
2011-08-12 22:54 ` [RFC PATCH 11/12] arm/tegra: board-dt: Remove dependency on non-dt pinmux functions Stephen Warren
2011-08-12 22:54 ` [RFC PATCH 12/12] arm/tegra: Remove temporary gpio/pinmux registration workaround Stephen Warren
2011-08-15 11:12   ` Sergei Shtylyov
2011-08-15 16:03     ` Stephen Warren
2011-08-13 13:08 ` [RFC PATCH 00/12] arm/tegra: Initialize GPIO & pinmux from DT Shawn Guo
2011-08-15 16:07   ` Stephen Warren

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=20110815205042.GC22355@gallagher \
    --to=jamie@jamieiles.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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).