All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
To: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>,
	linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: Re: [PATCH] pinctrl: Add one-register-per-pin type device tree based pinctrl driver
Date: Thu, 21 Jun 2012 16:13:26 -0600	[thread overview]
Message-ID: <4FE39C86.5070901@wwwdotorg.org> (raw)
In-Reply-To: <20120619135600.GX12766-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>

On 06/19/2012 07:56 AM, Tony Lindgren wrote:
> Hi,
> 
> Below is the pinctrl-single patch updated with hopefully all the Stephen's
> comments addressed. The binding still needs to be looked at, see relevant
> parts of the discussion below.
...
> From: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
> Date: Wed, 6 Jun 2012 04:18:18 -0700
> Subject: [PATCH] pinctrl: Add one-register-per-pin type device tree based pinctrl driver
> 
> Add one-register-per-pin type device tree based pinctrl driver.
> 
> Currently this driver only works on omap2+ series of processors,
> where there is either an 8 or 16-bit padconf register for each pin.
> Support for other similar pinmux controllers can be added.
> 
> Signed-off-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
> 
> diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
> new file mode 100644
> index 0000000..929254c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
> @@ -0,0 +1,106 @@
> +One-register-per-pin type device tree based pinctrl driver
> +
> +Required properties:
> +- compatible : "pinctrl-single"
> +
> +- reg : offset and length of the register set for the mux registers
> +
> +- pinctrl-single,register-width : pinmux register access width in bits
> +
> +- pinctrl-single,function-mask : mask of allowed pinmux function bits
> +  in the pinmux register
> +
> +- pinctrl-single,pinconf-mask : mask of allowed pinconf bits in the
> +  pinmux register; this gets combined with pinconf mask but is a separate
> +  mask to allow the option of setting pinconf separatately from the
> +  function

Given that this binding doesn't allow describing pin configuration at
present, I would simply remove all mention of that property in the
binding documentation. It can be added back if/when that feature is
added. Any future driver using this binding can refuse to allow pin
configuration if that property is missing.

> +- pinctrl-single,function-off : function off mode for disabled state if
> +  available and same for all registers; if not, use a value larger than
> +  function-mask to ignore disabling of registers

Rather than requiring an invalid value in this property, shouldn't the
lack of a valid function-off value be represented by the property not
being present in the DT?

> +This driver assumes that there is only one register for each pin,
> +and uses the common pinctrl bindings as specified in the pinctrl-bindings.txt
> +document in this directory.

At this point in the file, I think you need to mention that you're
switching from describing the top-level device node to describing pin
configuration nodes.

> +The pinctrl register offsets and default values are specified as pairs

I thought we were going to remove "default" here?

> +using pinctrl-single,pins. For example, setting a pin for a device
> +could be done with:
> +
> +	pinctrl-single,pins = <0xdc 0x118>;
> +
> +Where 0xdc is the offset from the pinctrl register base address for the
> +device pinctrl register, and 0x118 contains the desired value of the
> +pinctrl register. See the device example and static board pins example
> +below for more information.

There should be some explanation only the portion of this value covered
by the pinctrl-single,function-mask value is updated in the register.

> +This driver tries to avoid understanding pin and function names because of
> +the extra bloat they would cause especially in the case of a large number
> +of pins. This driver just sets what is specified for the board in the .dts file.
> +Further user space debugging tools can be developed to decipher the pin and
> +function names using debugfs.

There shouldn't be any discussion of a driver here; the binding is a HW
description.

> +Example:

I only reviewed the binding document, not the code.

WARNING: multiple messages have this Message-ID (diff)
From: swarren@wwwdotorg.org (Stephen Warren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] pinctrl: Add one-register-per-pin type device tree based pinctrl driver
Date: Thu, 21 Jun 2012 16:13:26 -0600	[thread overview]
Message-ID: <4FE39C86.5070901@wwwdotorg.org> (raw)
In-Reply-To: <20120619135600.GX12766@atomide.com>

On 06/19/2012 07:56 AM, Tony Lindgren wrote:
> Hi,
> 
> Below is the pinctrl-single patch updated with hopefully all the Stephen's
> comments addressed. The binding still needs to be looked at, see relevant
> parts of the discussion below.
...
> From: Tony Lindgren <tony@atomide.com>
> Date: Wed, 6 Jun 2012 04:18:18 -0700
> Subject: [PATCH] pinctrl: Add one-register-per-pin type device tree based pinctrl driver
> 
> Add one-register-per-pin type device tree based pinctrl driver.
> 
> Currently this driver only works on omap2+ series of processors,
> where there is either an 8 or 16-bit padconf register for each pin.
> Support for other similar pinmux controllers can be added.
> 
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> 
> diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
> new file mode 100644
> index 0000000..929254c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
> @@ -0,0 +1,106 @@
> +One-register-per-pin type device tree based pinctrl driver
> +
> +Required properties:
> +- compatible : "pinctrl-single"
> +
> +- reg : offset and length of the register set for the mux registers
> +
> +- pinctrl-single,register-width : pinmux register access width in bits
> +
> +- pinctrl-single,function-mask : mask of allowed pinmux function bits
> +  in the pinmux register
> +
> +- pinctrl-single,pinconf-mask : mask of allowed pinconf bits in the
> +  pinmux register; this gets combined with pinconf mask but is a separate
> +  mask to allow the option of setting pinconf separatately from the
> +  function

Given that this binding doesn't allow describing pin configuration at
present, I would simply remove all mention of that property in the
binding documentation. It can be added back if/when that feature is
added. Any future driver using this binding can refuse to allow pin
configuration if that property is missing.

> +- pinctrl-single,function-off : function off mode for disabled state if
> +  available and same for all registers; if not, use a value larger than
> +  function-mask to ignore disabling of registers

Rather than requiring an invalid value in this property, shouldn't the
lack of a valid function-off value be represented by the property not
being present in the DT?

> +This driver assumes that there is only one register for each pin,
> +and uses the common pinctrl bindings as specified in the pinctrl-bindings.txt
> +document in this directory.

At this point in the file, I think you need to mention that you're
switching from describing the top-level device node to describing pin
configuration nodes.

> +The pinctrl register offsets and default values are specified as pairs

I thought we were going to remove "default" here?

> +using pinctrl-single,pins. For example, setting a pin for a device
> +could be done with:
> +
> +	pinctrl-single,pins = <0xdc 0x118>;
> +
> +Where 0xdc is the offset from the pinctrl register base address for the
> +device pinctrl register, and 0x118 contains the desired value of the
> +pinctrl register. See the device example and static board pins example
> +below for more information.

There should be some explanation only the portion of this value covered
by the pinctrl-single,function-mask value is updated in the register.

> +This driver tries to avoid understanding pin and function names because of
> +the extra bloat they would cause especially in the case of a large number
> +of pins. This driver just sets what is specified for the board in the .dts file.
> +Further user space debugging tools can be developed to decipher the pin and
> +function names using debugfs.

There shouldn't be any discussion of a driver here; the binding is a HW
description.

> +Example:

I only reviewed the binding document, not the code.

WARNING: multiple messages have this Message-ID (diff)
From: Stephen Warren <swarren@wwwdotorg.org>
To: Tony Lindgren <tony@atomide.com>
Cc: Linus Walleij <linus.walleij@linaro.org>,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, linux-omap@vger.kernel.org,
	devicetree-discuss@lists.ozlabs.org,
	Stephen Warren <swarren@nvidia.com>,
	Arnd Bergmann <arnd@arndb.de>,
	Grant Likely <grant.likely@secretlab.ca>,
	Rob Herring <rob.herring@calxeda.com>
Subject: Re: [PATCH] pinctrl: Add one-register-per-pin type device tree based pinctrl driver
Date: Thu, 21 Jun 2012 16:13:26 -0600	[thread overview]
Message-ID: <4FE39C86.5070901@wwwdotorg.org> (raw)
In-Reply-To: <20120619135600.GX12766@atomide.com>

On 06/19/2012 07:56 AM, Tony Lindgren wrote:
> Hi,
> 
> Below is the pinctrl-single patch updated with hopefully all the Stephen's
> comments addressed. The binding still needs to be looked at, see relevant
> parts of the discussion below.
...
> From: Tony Lindgren <tony@atomide.com>
> Date: Wed, 6 Jun 2012 04:18:18 -0700
> Subject: [PATCH] pinctrl: Add one-register-per-pin type device tree based pinctrl driver
> 
> Add one-register-per-pin type device tree based pinctrl driver.
> 
> Currently this driver only works on omap2+ series of processors,
> where there is either an 8 or 16-bit padconf register for each pin.
> Support for other similar pinmux controllers can be added.
> 
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> 
> diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
> new file mode 100644
> index 0000000..929254c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
> @@ -0,0 +1,106 @@
> +One-register-per-pin type device tree based pinctrl driver
> +
> +Required properties:
> +- compatible : "pinctrl-single"
> +
> +- reg : offset and length of the register set for the mux registers
> +
> +- pinctrl-single,register-width : pinmux register access width in bits
> +
> +- pinctrl-single,function-mask : mask of allowed pinmux function bits
> +  in the pinmux register
> +
> +- pinctrl-single,pinconf-mask : mask of allowed pinconf bits in the
> +  pinmux register; this gets combined with pinconf mask but is a separate
> +  mask to allow the option of setting pinconf separatately from the
> +  function

Given that this binding doesn't allow describing pin configuration at
present, I would simply remove all mention of that property in the
binding documentation. It can be added back if/when that feature is
added. Any future driver using this binding can refuse to allow pin
configuration if that property is missing.

> +- pinctrl-single,function-off : function off mode for disabled state if
> +  available and same for all registers; if not, use a value larger than
> +  function-mask to ignore disabling of registers

Rather than requiring an invalid value in this property, shouldn't the
lack of a valid function-off value be represented by the property not
being present in the DT?

> +This driver assumes that there is only one register for each pin,
> +and uses the common pinctrl bindings as specified in the pinctrl-bindings.txt
> +document in this directory.

At this point in the file, I think you need to mention that you're
switching from describing the top-level device node to describing pin
configuration nodes.

> +The pinctrl register offsets and default values are specified as pairs

I thought we were going to remove "default" here?

> +using pinctrl-single,pins. For example, setting a pin for a device
> +could be done with:
> +
> +	pinctrl-single,pins = <0xdc 0x118>;
> +
> +Where 0xdc is the offset from the pinctrl register base address for the
> +device pinctrl register, and 0x118 contains the desired value of the
> +pinctrl register. See the device example and static board pins example
> +below for more information.

There should be some explanation only the portion of this value covered
by the pinctrl-single,function-mask value is updated in the register.

> +This driver tries to avoid understanding pin and function names because of
> +the extra bloat they would cause especially in the case of a large number
> +of pins. This driver just sets what is specified for the board in the .dts file.
> +Further user space debugging tools can be developed to decipher the pin and
> +function names using debugfs.

There shouldn't be any discussion of a driver here; the binding is a HW
description.

> +Example:

I only reviewed the binding document, not the code.

  parent reply	other threads:[~2012-06-21 22:13 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-11 13:58 [PATCH] pinctrl: Add one-register-per-pin type device tree based pinctrl driver Tony Lindgren
2012-06-11 13:58 ` Tony Lindgren
     [not found] ` <20120611135826.GB12766-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
2012-06-14 23:12   ` Stephen Warren
2012-06-14 23:12     ` Stephen Warren
2012-06-14 23:12     ` Stephen Warren
2012-06-15  9:49     ` Tony Lindgren
2012-06-15  9:49       ` Tony Lindgren
2012-06-15 16:17       ` Stephen Warren
2012-06-15 16:17         ` Stephen Warren
2012-06-18  5:50         ` Tony Lindgren
2012-06-18  5:50           ` Tony Lindgren
2012-06-19 13:56           ` Tony Lindgren
2012-06-19 13:56             ` Tony Lindgren
2012-06-21  8:09             ` Linus Walleij
2012-06-21  8:09               ` Linus Walleij
     [not found]             ` <20120619135600.GX12766-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
2012-06-21 22:13               ` Stephen Warren [this message]
2012-06-21 22:13                 ` Stephen Warren
2012-06-21 22:13                 ` Stephen Warren
     [not found]                 ` <4FE39C86.5070901-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2012-06-22  8:39                   ` Tony Lindgren
2012-06-22  8:39                     ` Tony Lindgren
2012-06-22  8:39                     ` Tony Lindgren
2012-06-22 17:32                     ` Stephen Warren
2012-06-22 17:32                       ` Stephen Warren
2012-06-26 13:43                       ` Tony Lindgren
2012-06-26 13:43                         ` Tony Lindgren
2012-06-26 17:05                         ` Stephen Warren
2012-06-26 17:05                           ` Stephen Warren
2012-06-26 17:05                           ` Stephen Warren
2012-06-27 10:28                           ` Tony Lindgren
2012-06-27 10:28                             ` Tony Lindgren
2012-07-10  9:11                             ` Tony Lindgren
2012-07-10  9:11                               ` Tony Lindgren
     [not found]                               ` <20120710091131.GQ1122-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
2012-07-14 20:16                                 ` Linus Walleij
2012-07-14 20:16                                   ` Linus Walleij
2012-07-14 20:16                                   ` Linus Walleij
2012-07-16  7:10                                   ` Tony Lindgren
2012-07-16  7:10                                     ` 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=4FE39C86.5070901@wwwdotorg.org \
    --to=swarren-3lzwwm7+weoh9zmkesr00q@public.gmane.org \
    --cc=devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org \
    --cc=tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.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.