All of lore.kernel.org
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: James Hogan <james.hogan@imgtec.com>
Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>,
	linux-kernel@vger.kernel.org,
	devicetree-discuss@lists.ozlabs.org,
	Linus Walleij <linus.walleij@linaro.org>,
	linux-sh@vger.kernel.org
Subject: Re: [RFC] pinctrl: generic: Add DT bindings
Date: Thu, 13 Jun 2013 22:46:11 +0000	[thread overview]
Message-ID: <1489582.v1309hbNQ9@avalon> (raw)
In-Reply-To: <51B8878B.5090705@imgtec.com>

Hi James,

On Wednesday 12 June 2013 15:36:59 James Hogan wrote:
> On 11/06/13 23:03, Laurent Pinchart wrote:
> > Document DT properties for the generic pinctrl parameters and add a
> > parser function.
> > 
> > Signed-off-by: Laurent Pinchart
> > <laurent.pinchart+renesas@ideasonboard.com>
> > ---
> > 
> >  .../bindings/pinctrl/pinctrl-bindings.txt          | 29 +++++++
> >  drivers/pinctrl/pinconf-generic.c                  | 94 +++++++++++++++++
> >  drivers/pinctrl/pinconf.h                          | 17 ++++
> >  3 files changed, 140 insertions(+)
> > 
> > I've successfully tested this patch (or more accurately only the pull-up
> > and pull-down properties) with the Renesas sh-pfc pinctrl device driver.
> > I will resent the sh-pfc DT bindings patch series rebased on the generic
> > pinconf bindings.
> > 
> > Not all generic pinconf properties are currently implemented, but I don't
> > think that should be a showstopper. We can add them later as needed.
> > 
> > The code is based on both the sh-pfc pinconf DT parser and James Hogan's
> > tz1090 DT parser ("[PATCH v2 6/9] pinctrl-tz1090: add TZ1090 pinctrl
> > driver").
>
> Thanks for this patch. I haven't tested it (yet), but have a few
> comments below.
> 
> > diff --git
> > a/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
> > b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt index
> > c95ea82..e499ff0 100644
> > --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
> > +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
> > @@ -126,3 +126,32 @@ device; they may be grandchildren, for example.
> > Whether this is legal, and> 
> >  whether there is any interaction between the child and intermediate
> >  parent nodes, is again defined entirely by the binding for the individual
> >  pin controller device.
> > 
> > +
> > += Generic pinconf parameters =
> > +
> > +Pin configuration parameters are expressed by DT properties in the pin
> > +controller device state nodes and child nodes. For devices that use the
> > generic +pinconf parameters the following properties are defined.
> > +
> > +- tristate: A boolean, put the pin into high impedance state when set.
> > +
> > +- pull-up: An integer representing the pull-up strength. 0 disables the
> > pull-up, +  non-zero values enable it.
> > +
> > +- pull-down: An integer representing the pull-down strength. 0 disables
> > the +  pull-down, non-zero values enables it.
> > +
> > +- schmitt: An integer, enable or disable Schmitt trigger mode for the
> > pins. +  Valid values are
> > +    0: Schmitt trigger disabled (no hysteresis)
> > +    1: Schmitt trigger enabled
> 
> this is set as a flag, so I think it should be described like tristate,
> "A boolean, ... when set."? Same for pull-up and pull-down (see comment
> below).

Can't the value be used to control schmitt trigger parameters (same as for the 
pull-up and pull-down values, as explained below) ?

> <snip>
> 
> > +	{ "pull-up",		PIN_CONFIG_BIAS_PULL_UP,		false },
> > +	{ "pull-down",		PIN_CONFIG_BIAS_PULL_DOWN,		false },
> 
> pinconf-generic.h says "If the argument is != 0 pull-up is enabled, if
> it is 0, pull-up is disabled", so I think these should be flags unless
> it's changed there first.

= 0 for disabled and != 0 for enabled doesn't mean that all != 0 values are 
equivalent. As I read it drivers can use the value to control the pull-up/down 
strength without violating the documentation.

> Any chance of adding the new "bus-hold" entry too
> (PIN_CONFIG_BIAS_BUS_HOLD, and flag=true I suppose)? see
> aa69352252a7a952e6e77734cb87135143a377d2 in LinuxW's pinctrl for-next
> branch.

Another generic pinconf DT bindings proposal has been submitted and applied to 
the devel branch in Linus' pinctrl tree. It includes support for 
PIN_CONFIG_BIAS_BUS_HOLD. Linus asked me to review the patch, so this one will 
likely be dropped or at least integrated into the other one.

> <snip>
> 
> > +EXPORT_SYMBOL_GPL(pinconf_generic_parse_params);
> > diff --git a/drivers/pinctrl/pinconf.h b/drivers/pinctrl/pinconf.h
> > index 92c7267..eb8550b 100644
> > --- a/drivers/pinctrl/pinconf.h
> > +++ b/drivers/pinctrl/pinconf.h
> > @@ -90,6 +90,23 @@ static inline void pinconf_init_device_debugfs(struct
> > dentry *devroot,> 
> >   * pin config.
> >   */
> > 
> > +#if defined(CONFIG_GENERIC_PINCONF)
> > +
> > +int pinconf_generic_parse_params(struct device *dev, struct device_node
> > *np, +				 unsigned long **cfgs);
> > +
> > +#else
> > +
> > +static inline int pinconf_generic_parse_params(struct device *dev,
> > +					       struct device_node *np,
> > +					       unsigned long **cfgs)
> > +{
> > +	*cfgs = NULL;
> > +	return 0;
> > +}
> 
> Should this ever be necessary? Sounds like if the driver wanted to use
> this it should already have selected GENERIC_PINCONF anyway.

You're right.

-- 
Regards,

Laurent Pinchart


WARNING: multiple messages have this Message-ID (diff)
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: James Hogan <james.hogan@imgtec.com>
Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>,
	linux-kernel@vger.kernel.org,
	devicetree-discuss@lists.ozlabs.org,
	Linus Walleij <linus.walleij@linaro.org>,
	linux-sh@vger.kernel.org
Subject: Re: [RFC] pinctrl: generic: Add DT bindings
Date: Fri, 14 Jun 2013 00:46:11 +0200	[thread overview]
Message-ID: <1489582.v1309hbNQ9@avalon> (raw)
In-Reply-To: <51B8878B.5090705@imgtec.com>

Hi James,

On Wednesday 12 June 2013 15:36:59 James Hogan wrote:
> On 11/06/13 23:03, Laurent Pinchart wrote:
> > Document DT properties for the generic pinctrl parameters and add a
> > parser function.
> > 
> > Signed-off-by: Laurent Pinchart
> > <laurent.pinchart+renesas@ideasonboard.com>
> > ---
> > 
> >  .../bindings/pinctrl/pinctrl-bindings.txt          | 29 +++++++
> >  drivers/pinctrl/pinconf-generic.c                  | 94 +++++++++++++++++
> >  drivers/pinctrl/pinconf.h                          | 17 ++++
> >  3 files changed, 140 insertions(+)
> > 
> > I've successfully tested this patch (or more accurately only the pull-up
> > and pull-down properties) with the Renesas sh-pfc pinctrl device driver.
> > I will resent the sh-pfc DT bindings patch series rebased on the generic
> > pinconf bindings.
> > 
> > Not all generic pinconf properties are currently implemented, but I don't
> > think that should be a showstopper. We can add them later as needed.
> > 
> > The code is based on both the sh-pfc pinconf DT parser and James Hogan's
> > tz1090 DT parser ("[PATCH v2 6/9] pinctrl-tz1090: add TZ1090 pinctrl
> > driver").
>
> Thanks for this patch. I haven't tested it (yet), but have a few
> comments below.
> 
> > diff --git
> > a/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
> > b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt index
> > c95ea82..e499ff0 100644
> > --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
> > +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
> > @@ -126,3 +126,32 @@ device; they may be grandchildren, for example.
> > Whether this is legal, and> 
> >  whether there is any interaction between the child and intermediate
> >  parent nodes, is again defined entirely by the binding for the individual
> >  pin controller device.
> > 
> > +
> > +== Generic pinconf parameters ==
> > +
> > +Pin configuration parameters are expressed by DT properties in the pin
> > +controller device state nodes and child nodes. For devices that use the
> > generic +pinconf parameters the following properties are defined.
> > +
> > +- tristate: A boolean, put the pin into high impedance state when set.
> > +
> > +- pull-up: An integer representing the pull-up strength. 0 disables the
> > pull-up, +  non-zero values enable it.
> > +
> > +- pull-down: An integer representing the pull-down strength. 0 disables
> > the +  pull-down, non-zero values enables it.
> > +
> > +- schmitt: An integer, enable or disable Schmitt trigger mode for the
> > pins. +  Valid values are
> > +    0: Schmitt trigger disabled (no hysteresis)
> > +    1: Schmitt trigger enabled
> 
> this is set as a flag, so I think it should be described like tristate,
> "A boolean, ... when set."? Same for pull-up and pull-down (see comment
> below).

Can't the value be used to control schmitt trigger parameters (same as for the 
pull-up and pull-down values, as explained below) ?

> <snip>
> 
> > +	{ "pull-up",		PIN_CONFIG_BIAS_PULL_UP,		false },
> > +	{ "pull-down",		PIN_CONFIG_BIAS_PULL_DOWN,		false },
> 
> pinconf-generic.h says "If the argument is != 0 pull-up is enabled, if
> it is 0, pull-up is disabled", so I think these should be flags unless
> it's changed there first.

== 0 for disabled and != 0 for enabled doesn't mean that all != 0 values are 
equivalent. As I read it drivers can use the value to control the pull-up/down 
strength without violating the documentation.

> Any chance of adding the new "bus-hold" entry too
> (PIN_CONFIG_BIAS_BUS_HOLD, and flag=true I suppose)? see
> aa69352252a7a952e6e77734cb87135143a377d2 in LinuxW's pinctrl for-next
> branch.

Another generic pinconf DT bindings proposal has been submitted and applied to 
the devel branch in Linus' pinctrl tree. It includes support for 
PIN_CONFIG_BIAS_BUS_HOLD. Linus asked me to review the patch, so this one will 
likely be dropped or at least integrated into the other one.

> <snip>
> 
> > +EXPORT_SYMBOL_GPL(pinconf_generic_parse_params);
> > diff --git a/drivers/pinctrl/pinconf.h b/drivers/pinctrl/pinconf.h
> > index 92c7267..eb8550b 100644
> > --- a/drivers/pinctrl/pinconf.h
> > +++ b/drivers/pinctrl/pinconf.h
> > @@ -90,6 +90,23 @@ static inline void pinconf_init_device_debugfs(struct
> > dentry *devroot,> 
> >   * pin config.
> >   */
> > 
> > +#if defined(CONFIG_GENERIC_PINCONF)
> > +
> > +int pinconf_generic_parse_params(struct device *dev, struct device_node
> > *np, +				 unsigned long **cfgs);
> > +
> > +#else
> > +
> > +static inline int pinconf_generic_parse_params(struct device *dev,
> > +					       struct device_node *np,
> > +					       unsigned long **cfgs)
> > +{
> > +	*cfgs = NULL;
> > +	return 0;
> > +}
> 
> Should this ever be necessary? Sounds like if the driver wanted to use
> this it should already have selected GENERIC_PINCONF anyway.

You're right.

-- 
Regards,

Laurent Pinchart


  reply	other threads:[~2013-06-13 22:46 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-11 22:03 [RFC] pinctrl: generic: Add DT bindings Laurent Pinchart
2013-06-11 22:03 ` Laurent Pinchart
2013-06-12 12:48 ` Grant Likely
2013-06-12 12:48   ` Grant Likely
2013-06-13 22:39   ` Laurent Pinchart
2013-06-13 22:39     ` Laurent Pinchart
2013-06-15 19:56     ` Linus Walleij
2013-06-15 19:56       ` Linus Walleij
2013-06-15 20:16       ` Heiko Stübner
2013-06-15 20:16         ` Heiko Stübner
2013-06-15 23:35         ` Laurent Pinchart
2013-06-15 23:35           ` Laurent Pinchart
2013-06-15 23:51           ` Linus Walleij
2013-06-15 23:51             ` Linus Walleij
2013-06-15 23:52             ` Laurent Pinchart
2013-06-15 23:52               ` Laurent Pinchart
2013-06-16  0:04               ` Linus Walleij
2013-06-16  0:04                 ` Linus Walleij
2013-06-16  0:04                 ` Linus Walleij
     [not found]         ` <201306152216.14252.heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>
2013-06-19 21:52           ` Stephen Warren
2013-06-19 21:52             ` Stephen Warren
2013-06-19 21:52             ` Stephen Warren
2013-06-12 14:36 ` James Hogan
2013-06-12 14:36   ` James Hogan
2013-06-12 14:36   ` James Hogan
2013-06-13 22:46   ` Laurent Pinchart [this message]
2013-06-13 22:46     ` Laurent Pinchart
2013-06-19 21:58 ` Stephen Warren
2013-06-19 21:58   ` Stephen Warren
2013-06-24  9:43   ` Linus Walleij
2013-06-24  9:43     ` Linus Walleij

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=1489582.v1309hbNQ9@avalon \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=devicetree-discuss@lists.ozlabs.org \
    --cc=james.hogan@imgtec.com \
    --cc=laurent.pinchart+renesas@ideasonboard.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sh@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.