@@ -6,3 +6,23 @@ Required properties: second cell is used to specify optional parameters: - bit 0 specifies polarity (0 for normal, 1 for inverted) - gpio-controller : Marks the device node as a GPIO controller.++Optional properties:+- nvidia,enabled-gpios : The list of GPIOs that should be controlled by the+ GPIO controller rather than the pinmux controller.++Example of a gpio-controller node:++ gpio: gpio@6000d000 {+ compatible = "nvidia,tegra20-gpio";+ reg = < 0x6000d000 0x1000 >;+ interrupts = < 64 65 66 67 87 119 121 >;+ #gpio-cells = <2>;+ gpio-controller;+ nvidia,enabled-gpios = <+ 69 // TEGRA_GPIO_PI5 SD2_CD+ 57 // TEGRA_GPIO_PH1 SD2_WP+ 155 // TEGRA_GPIO_PT3 SD2_POWER+ >;+ };+
From: Stephen Warren <hidden> Date: 2011-08-25 23:44:14
The patch adds a couple empty functions for non-dt build, so that
drivers migrating to dt can save some '#ifdef CONFIG_OF'.
Signed-off-by: Stephen Warren <redacted>
---
include/linux/of.h | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
@@ -326,7 +326,6 @@ static struct irq_chip tegra_gpio_irq_chip = {#endif};-/* This lock class tells lockdep that GPIO irqs are in a different*categorythantheirparents,soitwon'treportfalserecursion.*/
From: Stephen Warren <hidden> Date: 2011-08-25 23:45:04
This patch adds macros for_each_u32_property_value and
for_each_string_property_value, which iterate over an array of values
within a device-tree property. Usage is for example:
struct of_iter_string_prop iter;
for_each_string_property_value(iter, np, "pins")
printk("Got value %s\n", iter.value);
Signed-off-by: Stephen Warren <redacted>
---
include/linux/of_iter_prop.h | 135 ++++++++++++++++++++++++++++++++++++++++++
1 files changed, 135 insertions(+), 0 deletions(-)
create mode 100644 include/linux/of_iter_prop.h
From: Stephen Warren <hidden> Date: 2011-08-25 23:45:38
From: Jamie Iles <redacted>
This patch adds a helper function of_pinmux_parse() that can be used to
extract common pinmux configuration to avoid each platform implementing
a parsing loop. Platforms supply the node containing the pinmux
definitions and a platform specific callback for configuring a pingroup.
Signed-off-by: Jamie Iles <redacted>
[swarren: Added support for pins property, added parse() callback, use
dev_err instead of pr_err, related minor changes]
Signed-off-by: Stephen Warren <redacted>
---
drivers/of/Kconfig | 5 ++
drivers/of/Makefile | 1 +
drivers/of/of_pinmux.c | 109 +++++++++++++++++++++++++++++++++++++++++++++
include/linux/of_pinmux.h | 74 ++++++++++++++++++++++++++++++
4 files changed, 189 insertions(+), 0 deletions(-)
create mode 100644 drivers/of/of_pinmux.c
create mode 100644 include/linux/of_pinmux.h
@@ -0,0 +1,109 @@+/*+*Copyright(c)2011PicochipLtd.,JamieIles+*Copyright(c)2011NVIDIA,Inc.+*+*Genericpinmuxbindingsfordevicetree.+*+*Thisprogramisfreesoftware;youcanredistributeitand/ormodify+*itunderthetermsoftheGNUGeneralPublicLicenseaspublishedby+*theFreeSoftwareFoundation;eitherversion2oftheLicense,or+*(atyouroption)anylaterversion.+*+*Thisprogramisdistributedinthehopethatitwillbeuseful,+*butWITHOUTANYWARRANTY;withouteventheimpliedwarrantyof+*MERCHANTABILITYorFITNESSFORAPARTICULARPURPOSE.Seethe+*GNUGeneralPublicLicenseformoredetails.+*/+#include<linux/device.h>+#include<linux/errno.h>+#include<linux/module.h>+#include<linux/kernel.h>+#include<linux/of.h>+#include<linux/of_iter_prop.h>+#include<linux/of_pinmux.h>++/**+*of_pinmux_parse-configureasetofpinmuxgroupsforapinmuxcontroller+*+*@controller:thecontrollertoconfigurethepinmuxentriesfor.This+*definesthecontrollerdevicenodeandthecallbackforconfiguring+*thepingroups.+*+*Thishelperloopsoverallofthechildnodesofapinmuxcontrollerand+*collectstheconfigurationforeachpinmuxgroup.Apinmuxgroupis+*definedasoneormorepinsthatareconfiguredtoacommonfunction.This+*handlescommonpropertiesthatmanyplatformsmayimplement,butfor+*platformspecificpropertiesthesemaybehandledintheconfigure+*callback.+*/+intof_pinmux_parse(conststructof_pinmux_ctrl*ctrl,+structof_pinmux_cfg*cfg)+{+structdevice_node*np;++if(!ctrl||!ctrl->dev||!ctrl->node||!ctrl->configure)+return-EINVAL;++for_each_child_of_node(ctrl->node,np){+intret;+boolhadpins=0;+structof_iter_string_propiter;++cfg->node=np;++ret=of_property_read_string(np,"function",+&cfg->function);+if(ret<0){+dev_err(ctrl->dev,"no function for node %s\n",+np->name);+continue;+}++cfg->flags&=0;++if(of_find_property(np,"pull-up",NULL))+cfg->flags|=OF_PINMUX_PULL_UP;+if(of_find_property(np,"pull-down",NULL))+cfg->flags|=OF_PINMUX_PULL_DOWN;++if((cfg->flags&OF_PINMUX_PULL_MASK)==+OF_PINMUX_PULL_MASK){+dev_warn(ctrl->dev,"node %s has both "+"pull-up and pull-down properties - "+"defaulting to no pull\n",+np->name);+cfg->flags&=~OF_PINMUX_PULL_MASK;+}++if(of_find_property(np,"tristate",NULL))+cfg->flags|=OF_PINMUX_TRISTATE;++if(ctrl->parse&&ctrl->parse(ctrl,cfg)){+dev_warn(ctrl->dev,+"failed to parse node %s\n",+np->name);+continue;+}++for_each_string_property_value(iter,np,"pins"){+hadpins=1;++cfg->pin=iter.value;++dev_dbg(ctrl->dev,+"configure pin %s func=%s flags=0x%lx\n",+cfg->pin,cfg->function,cfg->flags);+if(ctrl->configure(ctrl,cfg))+dev_warn(ctrl->dev,+"failed to configure pin %s\n",+cfg->pin);+}++if(!hadpins)+dev_warn(ctrl->dev,"no pins for node %s\n",+np->name);+}++return0;+}+EXPORT_SYMBOL_GPL(of_pinmux_parse);
From: Stephen Warren <hidden> Date: 2011-08-25 23:46:27
Add a pinmux node to tegra20.dtsi in order to instantiate the future
pinmux device. Add pinmux nodes to Harmony and Seaboard, which detail
the entire initial pinmux configuration. This configuration is identical
to that in board-harmony/seaboard-pinmux.c.
Signed-off-by: Stephen Warren <redacted>
---
arch/arm/boot/dts/tegra-harmony.dts | 243 ++++++++++++++++++++++++++++++++++
arch/arm/boot/dts/tegra-seaboard.dts | 239 +++++++++++++++++++++++++++++++++
arch/arm/boot/dts/tegra20.dtsi | 5 +
3 files changed, 487 insertions(+), 0 deletions(-)
From: Stephen Warren <hidden> Date: 2011-08-25 23:46:52
Add board-specific gpio node for Harmony and Seaboard. This lists the
GPIOs used by the board. Note that not all GPIOs that exist on the board
are listed; only those used by devices currently supported by device
tree.
Signed-off-by: Stephen Warren <redacted>
---
arch/arm/boot/dts/tegra-harmony.dts | 15 +++++++++++++++
arch/arm/boot/dts/tegra-seaboard.dts | 8 ++++++++
2 files changed, 23 insertions(+), 0 deletions(-)
From: Stephen Warren <hidden> Date: 2011-08-25 23:47:11
The Tegra GPIO driver will be converted from static registration via
postcore_initcall() to be a platform device later in this patch series.
A new Tegra pinmux platform device will also be added.
Prepare for this by modifying all boards to register the appropriate
platform devices before-hand, so that when the drivers are converted,
those devices will be probed, and git bisectability will be maintained.
Signed-off-by: Stephen Warren <redacted>
---
arch/arm/mach-tegra/board-harmony-pinmux.c | 8 ++++++++
arch/arm/mach-tegra/board-paz00-pinmux.c | 8 ++++++++
arch/arm/mach-tegra/board-seaboard-pinmux.c | 9 +++++++--
arch/arm/mach-tegra/board-trimslice-pinmux.c | 7 +++++++
arch/arm/mach-tegra/devices.c | 10 ++++++++++
arch/arm/mach-tegra/devices.h | 2 ++
6 files changed, 42 insertions(+), 2 deletions(-)
From: Olof Johansson <hidden> Date: 2011-08-26 05:04:34
On Thu, Aug 25, 2011 at 4:43 PM, Stephen Warren [off-list ref] wrote:
v3:
* Build on Jamie Iles' patches to split some of the DT parsing into
common code.
* Renamed some properties to remove "nvidia," from name; they can be
generic.
* Support pins property, to apply DT nodes to multiple pins/groups
* Some minor error-message changes driven by some of the above.
* Removed requirement to #ifdef CONFIG_OF
* Removed AUXDATA table entries in mach-tegra/board-dt.c
TODO:
* Convert from using strings to using integers for the function and pin
names. This relies on the dtc patches I posted yesterday, but should
be pretty simple once they're in.
Jamie Iles (1):
of: add a generic pinmux helper
Stephen Warren (12):
arm/tegra: Prep boards for gpio/pinmux conversion to pdevs
docs/dt: Document nvidia,tegra20-gpio's nvidia,enabled-gpios property
arm/dt: Tegra: Add nvidia,enabled-gpios property to GPIO controller
docs/dt: Document nvidia,tegra20-pinmux binding
arm/dt: Tegra: Add pinmux node
dt: add empty for_each_child_of_node, of_find_property
gpio/tegra: Convert to a platform device
gpio/tegra: Add device tree support
arm/tegra: Convert pinmux driver to a platform device
of: add property iteration helpers
arm/tegra: Add device tree support to pinmux driver
arm/tegra: board-dt: Remove dependency on non-dt pinmux functions
This is looking pretty sane to me.
Grant, how do you prefer to handle this, since it spans of/dt, gpio
and tegra code? I can start a topic branch for Arnd to pull in for the
tegra parts, would you prefer picking up the of helper functions on
your own or is an ack from you and merge through the arm-soc tree
easier?
-Olof
Hi Stephen,
On Thu, Aug 25, 2011 at 05:43:41PM -0600, Stephen Warren wrote:
quoted hunk
From: Jamie Iles <redacted>
This patch adds a helper function of_pinmux_parse() that can be used to
extract common pinmux configuration to avoid each platform implementing
a parsing loop. Platforms supply the node containing the pinmux
definitions and a platform specific callback for configuring a pingroup.
Signed-off-by: Jamie Iles <redacted>
[swarren: Added support for pins property, added parse() callback, use
dev_err instead of pr_err, related minor changes]
Signed-off-by: Stephen Warren <redacted>
---
drivers/of/Kconfig | 5 ++
drivers/of/Makefile | 1 +
drivers/of/of_pinmux.c | 109 +++++++++++++++++++++++++++++++++++++++++++++
include/linux/of_pinmux.h | 74 ++++++++++++++++++++++++++++++
4 files changed, 189 insertions(+), 0 deletions(-)
create mode 100644 drivers/of/of_pinmux.c
create mode 100644 include/linux/of_pinmux.h
@@ -0,0 +1,109 @@+/*+*Copyright(c)2011PicochipLtd.,JamieIles+*Copyright(c)2011NVIDIA,Inc.+*+*Genericpinmuxbindingsfordevicetree.+*+*Thisprogramisfreesoftware;youcanredistributeitand/ormodify+*itunderthetermsoftheGNUGeneralPublicLicenseaspublishedby+*theFreeSoftwareFoundation;eitherversion2oftheLicense,or+*(atyouroption)anylaterversion.+*+*Thisprogramisdistributedinthehopethatitwillbeuseful,+*butWITHOUTANYWARRANTY;withouteventheimpliedwarrantyof+*MERCHANTABILITYorFITNESSFORAPARTICULARPURPOSE.Seethe+*GNUGeneralPublicLicenseformoredetails.+*/+#include<linux/device.h>+#include<linux/errno.h>+#include<linux/module.h>+#include<linux/kernel.h>+#include<linux/of.h>+#include<linux/of_iter_prop.h>+#include<linux/of_pinmux.h>++/**+*of_pinmux_parse-configureasetofpinmuxgroupsforapinmuxcontroller+*+*@controller:thecontrollertoconfigurethepinmuxentriesfor.This+*definesthecontrollerdevicenodeandthecallbackforconfiguring+*thepingroups.+*+*Thishelperloopsoverallofthechildnodesofapinmuxcontrollerand+*collectstheconfigurationforeachpinmuxgroup.Apinmuxgroupis+*definedasoneormorepinsthatareconfiguredtoacommonfunction.This+*handlescommonpropertiesthatmanyplatformsmayimplement,butfor+*platformspecificpropertiesthesemaybehandledintheconfigure+*callback.+*/+intof_pinmux_parse(conststructof_pinmux_ctrl*ctrl,+structof_pinmux_cfg*cfg)+{+structdevice_node*np;++if(!ctrl||!ctrl->dev||!ctrl->node||!ctrl->configure)+return-EINVAL;++for_each_child_of_node(ctrl->node,np){+intret;+boolhadpins=0;+structof_iter_string_propiter;++cfg->node=np;++ret=of_property_read_string(np,"function",+&cfg->function);+if(ret<0){+dev_err(ctrl->dev,"no function for node %s\n",+np->name);+continue;+}++cfg->flags&=0;
cfg->flags = 0?
+
+ if (of_find_property(np, "pull-up", NULL))
+ cfg->flags |= OF_PINMUX_PULL_UP;
+ if (of_find_property(np, "pull-down", NULL))
+ cfg->flags |= OF_PINMUX_PULL_DOWN;
+
+ if ((cfg->flags & OF_PINMUX_PULL_MASK) ==
+ OF_PINMUX_PULL_MASK) {
+ dev_warn(ctrl->dev, "node %s has both "
+ "pull-up and pull-down properties - "
+ "defaulting to no pull\n",
+ np->name);
For format strings I believe it's preferred to keep it on one long line
so it can at least be grepped for.
+ */
+struct of_pinmux_cfg {
+ struct device_node *node;
+ const char *pin;
+ const char *function;
+ unsigned long flags;
+};
+
+/**
+ * struct of_pinmux_ctrl - platform specific pinmux control state.
+ *
+ * @pinmux: the pinmux device node. All child nodes are required to be the
+ * pinmux entry definitions. Depending on the platform, this may either be
+ * a single pin or a group of pins where they can be set to a common
+ * function.
+ * @configure: platform specific callback to configure the pinmux entry.
On Thu, Aug 25, 2011 at 05:43:42PM -0600, Stephen Warren wrote:
This patch adds macros for_each_u32_property_value and
for_each_string_property_value, which iterate over an array of values
within a device-tree property. Usage is for example:
struct of_iter_string_prop iter;
for_each_string_property_value(iter, np, "pins")
printk("Got value %s\n", iter.value);
Signed-off-by: Stephen Warren <redacted>
Nicely implemented! For the !CONFIG_OF case, I *think* that
of_iter_u32_prop and of_iter_string_prop can be empty struct's, but I
wouldn't want to bet money on that!
Reviewed-by: Jamie Iles <redacted>
From: Stephen Warren <hidden> Date: 2011-08-26 16:00:15
Jamie Iles wrote at Friday, August 26, 2011 3:27 AM:
On Thu, Aug 25, 2011 at 05:43:42PM -0600, Stephen Warren wrote:
quoted
This patch adds macros for_each_u32_property_value and
for_each_string_property_value, which iterate over an array of values
within a device-tree property. Usage is for example:
struct of_iter_string_prop iter;
for_each_string_property_value(iter, np, "pins")
printk("Got value %s\n", iter.value);
Signed-off-by: Stephen Warren <redacted>
Nicely implemented!
Thanks!
For the !CONFIG_OF case, I *think* that
of_iter_u32_prop and of_iter_string_prop can be empty struct's, but I
wouldn't want to bet money on that!
Empty structs themselves certainly did compile OK, but the code that
uses these macros references iter.value directly, and isn't under #ifdef
CONFIG_OF, so that field has to exist.
I suppose an alternative would be to add an accessor function:
struct of_iter_string_prop iter;
for_each_string_property_value(iter, np, "pins")
printk("Got value %s\n", of_iter_string_value(iter));
which would return NULL/"" when !CONFIG_OF, and hence allow iter.value
to be removed too. Do you think that's a good approach? It'd be easy to
implement.
--
nvpublic
From: Stephen Warren <hidden> Date: 2011-08-26 16:07:21
Olof Johansson wrote at Thursday, August 25, 2011 11:05 PM:
On Thu, Aug 25, 2011 at 4:43 PM, Stephen Warren [off-list ref] wrote:
quoted
v3:
...
This is looking pretty sane to me.
Grant, how do you prefer to handle this, since it spans of/dt, gpio
and tegra code? I can start a topic branch for Arnd to pull in for the
tegra parts, would you prefer picking up the of helper functions on
your own or is an ack from you and merge through the arm-soc tree
easier?
I haven't thought through all the merging details yet, but do be aware
of the dependencies this patchset has:
1) Rename of arch/arm/mach-tegra/gpio.c -> drivers/gpio/gpio-tegra.c
This is in Grant's gpio for-next branch, and hence linux-next.
This is in some GPIO-related branch of Russell's.
2) Various previous Tegra <mach/gpio.h> rework.
This is in some GPIO-related branch of Russell's; I assume the same one
as (1), but I can't actually find this branch, so can't check.
Neither of those is in any Linus release or rc.
I *think* that's it.
For reference, this patchset was physical written/tested on top of
next-20110823, with the patches mentioned in (2) aboe, and some others that
hopefully aren't relevant, between linux-next and this patchset.
--
nvpublic
On Fri, Aug 26, 2011 at 08:59:44AM -0700, Stephen Warren wrote:
Jamie Iles wrote at Friday, August 26, 2011 3:27 AM:
quoted
For the !CONFIG_OF case, I *think* that
of_iter_u32_prop and of_iter_string_prop can be empty struct's, but I
wouldn't want to bet money on that!
Empty structs themselves certainly did compile OK, but the code that
uses these macros references iter.value directly, and isn't under #ifdef
CONFIG_OF, so that field has to exist.
I suppose an alternative would be to add an accessor function:
struct of_iter_string_prop iter;
for_each_string_property_value(iter, np, "pins")
printk("Got value %s\n", of_iter_string_value(iter));
which would return NULL/"" when !CONFIG_OF, and hence allow iter.value
to be removed too. Do you think that's a good approach? It'd be easy to
implement.
I think I prefer what you have now rather than a separate accessor, but
I'm happy either way!
Jamie
+{
+ struct device_node *np;
+
+ if (!ctrl || !ctrl->dev || !ctrl->node || !ctrl->configure)
+ return -EINVAL;
+
+ for_each_child_of_node(ctrl->node, np) {
+ int ret;
+ bool hadpins = 0;
+ struct of_iter_string_prop iter;
+
+ cfg->node = np;
+
+ ret = of_property_read_string(np, "function",
+ &cfg->function);
+ if (ret < 0) {
+ dev_err(ctrl->dev, "no function for node %s\n",
+ np->name);
+ continue;
+ }
I buy this part.
+
+ cfg->flags &= 0;
+
+ if (of_find_property(np, "pull-up", NULL))
+ cfg->flags |= OF_PINMUX_PULL_UP;
+ if (of_find_property(np, "pull-down", NULL))
+ cfg->flags |= OF_PINMUX_PULL_DOWN;
+
+ if ((cfg->flags & OF_PINMUX_PULL_MASK) ==
+ OF_PINMUX_PULL_MASK) {
+ dev_warn(ctrl->dev, "node %s has both "
+ "pull-up and pull-down properties - "
+ "defaulting to no pull\n",
+ np->name);
+ cfg->flags &= ~OF_PINMUX_PULL_MASK;
+ }
+
+ if (of_find_property(np, "tristate", NULL))
+ cfg->flags |= OF_PINMUX_TRISTATE;
But what does this stuff has to do with pinmux?
I call this "pin biasing" and it has very little to do with muxing.
If a broader, generic term is to be used, I'd prefer "pin control"
which sort of nails the thing.
+/**
+ * struct of_pinmux_cfg - configuration state for a single pinmux entry.
+ *
+ * @function: the name of the function that the pinmux entry should be
+ * configured to.
+ * @pin: the device_node of the pinmux entry that should be configured.
+ * Platform specific properties that aren't in the generic binding may be
+ * obtained from this device node.
+ * @flags: flags for common pinmux options such as pull and tristate.
I don't think these things has anything to do with pinmux at all.
But with the struct renamed of_pinctrl_cfg I'm again happier.
The current pinctrl patch set would probably want an unsigned
"position" attribute too. (If we should build on that.)
+/**
+ * struct of_pinmux_ctrl - platform specific pinmux control state.
+ *
+ * @pinmux: the pinmux device node. All child nodes are required to be the
+ * pinmux entry definitions. Depending on the platform, this may either be
+ * a single pin or a group of pins where they can be set to a common
+ * function.
+ * @configure: platform specific callback to configure the pinmux entry.
+ */
+struct of_pinmux_ctrl {
+ struct device *dev;
+ struct device_node *node;
+ int (*parse)(const struct of_pinmux_ctrl *ctrl,
+ struct of_pinmux_cfg *cfg);
+ int (*configure)(const struct of_pinmux_ctrl *ctrl,
+ const struct of_pinmux_cfg *cfg);
+};
+{
+ struct device_node *np;
+
+ if (!ctrl || !ctrl->dev || !ctrl->node || !ctrl->configure)
+ return -EINVAL;
+
+ for_each_child_of_node(ctrl->node, np) {
+ int ret;
+ bool hadpins = 0;
+ struct of_iter_string_prop iter;
+
+ cfg->node = np;
+
+ ret = of_property_read_string(np, "function",
+ &cfg->function);
+ if (ret < 0) {
+ dev_err(ctrl->dev, "no function for node %s\n",
+ np->name);
+ continue;
+ }
I buy this part.
quoted
+
+ cfg->flags &= 0;
+
+ if (of_find_property(np, "pull-up", NULL))
+ cfg->flags |= OF_PINMUX_PULL_UP;
+ if (of_find_property(np, "pull-down", NULL))
+ cfg->flags |= OF_PINMUX_PULL_DOWN;
+
+ if ((cfg->flags & OF_PINMUX_PULL_MASK) ==
+ OF_PINMUX_PULL_MASK) {
+ dev_warn(ctrl->dev, "node %s has both "
+ "pull-up and pull-down properties - "
+ "defaulting to no pull\n",
+ np->name);
+ cfg->flags &= ~OF_PINMUX_PULL_MASK;
+ }
+
+ if (of_find_property(np, "tristate", NULL))
+ cfg->flags |= OF_PINMUX_TRISTATE;
But what does this stuff has to do with pinmux?
I call this "pin biasing" and it has very little to do with muxing.
If a broader, generic term is to be used, I'd prefer "pin control"
which sort of nails the thing.
Well, it's not just that; the struct contains the function field to
select for each pingroup, so it's not just pinctrl either.
quoted
+/**
+ * struct of_pinmux_cfg - configuration state for a single pinmux entry.
+ *
+ * @function: the name of the function that the pinmux entry should be
+ * configured to.
+ * @pin: the device_node of the pinmux entry that should be configured.
+ * Platform specific properties that aren't in the generic binding may be
+ * obtained from this device node.
+ * @flags: flags for common pinmux options such as pull and tristate.
I don't think these things has anything to do with pinmux at all.
But with the struct renamed of_pinctrl_cfg I'm again happier.
The current pinctrl patch set would probably want an unsigned
"position" attribute too. (If we should build on that.)
This does beg the question I asked previously:
The intent of this patch was to provide a way for devicetree to set the
complete initial state of the pinmux, in a SoC-specific fashion, without
interaction with the pinmux API.
However, I'm guessing you see the pinmux driver as not touching HW at
boot at all, and never programming anything except in response to a
driver calling pinmux_get()/pinmux_enable()?
In the former case, this code and related bindings wouldn't be influenced
by the pinmux API at all (and indeed arguably never should be, since DT
is supposed to be oriented purely at HW, and not influenced by driver
design). This approach might make the pinmux API mostly relevant only
for drivers that actively change between configurations at run-time, and
not for drivers that don't need dynamic muxing.
However, in the latter case, this code should be part of the pinmux core,
and my patches to Tegra's pinmux driver dropped. It'd be difficult to
define a pinmux binding that wasn't influenced by the pinmux API's needs
in this case.
So, that's probably something we have to resolve first.
--
nvpublic
From: Stephen Warren <hidden> Date: 2011-08-31 18:26:16
Stephen Warren wrote at Thursday, August 25, 2011 5:44 PM:
The patch adds a couple empty functions for non-dt build, so that
drivers migrating to dt can save some '#ifdef CONFIG_OF'.
Signed-off-by: Stephen Warren <redacted>
Grant, is there any chance you could apply this one patch without waiting
for the whole series; I just realized that the SDHCI controller changes
I published yesterday rely on this patch to compile. While I did compile-
check them without CONFIG_OF, I also had this patch in that branch and
didn't notice the problem.
Thanks.
--
nvpublic
On Mon, Aug 29, 2011 at 11:46 PM, Stephen Warren [off-list ref] wrote:
quoted
quoted
+EXPORT_SYMBOL_GPL(of_pinmux_parse);
Renamed of_pinctrl_parse I'm happier with it.
Well, it's not just that; the struct contains the function field to
select for each pingroup, so it's not just pinctrl either.
OK as of my thinking in the v6 pin control patch set groups
are an abstract concept that is part of pin control and pin
definitions (does not need to be used for muxing, could be
anything you want to do with pins) so that sorts it out I guess?
So in line with that terminology I think this should be
named pinctrl.
quoted
The current pinctrl patch set would probably want an unsigned
"position" attribute too. (If we should build on that.)
This does beg the question I asked previously:
The intent of this patch was to provide a way for devicetree to set the
complete initial state of the pinmux, in a SoC-specific fashion, without
interaction with the pinmux API.
However, I'm guessing you see the pinmux driver as not touching HW at
boot at all, and never programming anything except in response to a
driver calling pinmux_get()/pinmux_enable()?
Since the pin control driver is (supposedly) the only driver that knows
about the register range dealing with muxing, all kind of fiddling
with these registers that are *necessary* on boot (e.g. to get the
thing up in a known state) need to be in the pincontrol driver.
So it may touch hardware on boot, i.e. write default values,
even though one may argue that the boot loader should have
taken care about such things, it's now always the case in
practice.
In the former case, this code and related bindings wouldn't be influenced
by the pinmux API at all (and indeed arguably never should be, since DT
is supposed to be oriented purely at HW, and not influenced by driver
design). This approach might make the pinmux API mostly relevant only
for drivers that actively change between configurations at run-time, and
not for drivers that don't need dynamic muxing.
Platforms that do not need dynamic muxing should be using it
if they need to configure default states of the pins at boot I think.
However, in the latter case, this code should be part of the pinmux core,
and my patches to Tegra's pinmux driver dropped. It'd be difficult to
define a pinmux binding that wasn't influenced by the pinmux API's needs
in this case.
Well that depends on what you want to do.
The patch subject seems to suggest that all SoCs should use this,
not just the Tegra driver. If it had the subject "of: add a tegra
pinmux helper" and functions named of_tegra_pinmux_parse() and
so on I wouldn't have any objections whatsoever.
If however you want to create a DT binding that should be used by
anyone (as indicated by the subject) it must use abstract concepts of
some kind and then I have opinions on how to name things and
some idea that I'd like them to correspond to what the pin control
subsystem will call things.
For example not call things dealing with biasing as part of
something called "pinmux", since in the pin controller
subsystem I'm envisioning I'm striving to separation of
concerns to the point where biasing and muxing are
completely orthogonal concepts, though they might be
using the same abstract concept of pin groups...
I don't know if I'm getting across properly, I'm trying
my best.
Thanks,
Linus Walleij