All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
To: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@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: Fri, 22 Jun 2012 01:39:56 -0700	[thread overview]
Message-ID: <20120622083955.GZ12766@atomide.com> (raw)
In-Reply-To: <4FE39C86.5070901-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>

Hi,

* Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> [120621 15:17]:
> On 06/19/2012 07:56 AM, Tony Lindgren wrote:
> > +
> > +- 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.

It might be better to just add support for pin_config_get/set to avoid
changing the binding later:

 static int pcs_pinconf_get(struct pinctrl_dev *pctldev,
                                unsigned pin, unsigned long *config)
 {
-	return -ENOTSUPP;
+	struct pcs_device *pcs;
+	void __iomem *reg;
+	int res;
+
+	pcs = pinctrl_dev_get_drvdata(pctldev);
+	res = pcs_pin_to_reg(pcs, pin, &reg);
+	if (res)
+		return res;
+
+	return pcs->read(reg) & pcs->cmask;
 }

A have not done that yet as currently the pcs_pin_to_reg() would need to be
sorted out in somewhat clean manner.
 
> > +- 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?

Heh good point :) Will change.
 
> > +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.

Will add.
 
> > +The pinctrl register offsets and default values are specified as pairs
> 
> I thought we were going to remove "default" here?

Oops, looks like one was left, will remove.
 
> > +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.

OK
 
> > +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.

Will move that to the driver comments.
 
> > +Example:
> 
> I only reviewed the binding document, not the code.

Thanks,

Tony

WARNING: multiple messages have this Message-ID (diff)
From: tony@atomide.com (Tony Lindgren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] pinctrl: Add one-register-per-pin type device tree based pinctrl driver
Date: Fri, 22 Jun 2012 01:39:56 -0700	[thread overview]
Message-ID: <20120622083955.GZ12766@atomide.com> (raw)
In-Reply-To: <4FE39C86.5070901@wwwdotorg.org>

Hi,

* Stephen Warren <swarren@wwwdotorg.org> [120621 15:17]:
> On 06/19/2012 07:56 AM, Tony Lindgren wrote:
> > +
> > +- 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.

It might be better to just add support for pin_config_get/set to avoid
changing the binding later:

 static int pcs_pinconf_get(struct pinctrl_dev *pctldev,
                                unsigned pin, unsigned long *config)
 {
-	return -ENOTSUPP;
+	struct pcs_device *pcs;
+	void __iomem *reg;
+	int res;
+
+	pcs = pinctrl_dev_get_drvdata(pctldev);
+	res = pcs_pin_to_reg(pcs, pin, &reg);
+	if (res)
+		return res;
+
+	return pcs->read(reg) & pcs->cmask;
 }

A have not done that yet as currently the pcs_pin_to_reg() would need to be
sorted out in somewhat clean manner.
 
> > +- 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?

Heh good point :) Will change.
 
> > +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.

Will add.
 
> > +The pinctrl register offsets and default values are specified as pairs
> 
> I thought we were going to remove "default" here?

Oops, looks like one was left, will remove.
 
> > +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.

OK
 
> > +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.

Will move that to the driver comments.
 
> > +Example:
> 
> I only reviewed the binding document, not the code.

Thanks,

Tony

WARNING: multiple messages have this Message-ID (diff)
From: Tony Lindgren <tony@atomide.com>
To: Stephen Warren <swarren@wwwdotorg.org>
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: Fri, 22 Jun 2012 01:39:56 -0700	[thread overview]
Message-ID: <20120622083955.GZ12766@atomide.com> (raw)
In-Reply-To: <4FE39C86.5070901@wwwdotorg.org>

Hi,

* Stephen Warren <swarren@wwwdotorg.org> [120621 15:17]:
> On 06/19/2012 07:56 AM, Tony Lindgren wrote:
> > +
> > +- 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.

It might be better to just add support for pin_config_get/set to avoid
changing the binding later:

 static int pcs_pinconf_get(struct pinctrl_dev *pctldev,
                                unsigned pin, unsigned long *config)
 {
-	return -ENOTSUPP;
+	struct pcs_device *pcs;
+	void __iomem *reg;
+	int res;
+
+	pcs = pinctrl_dev_get_drvdata(pctldev);
+	res = pcs_pin_to_reg(pcs, pin, &reg);
+	if (res)
+		return res;
+
+	return pcs->read(reg) & pcs->cmask;
 }

A have not done that yet as currently the pcs_pin_to_reg() would need to be
sorted out in somewhat clean manner.
 
> > +- 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?

Heh good point :) Will change.
 
> > +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.

Will add.
 
> > +The pinctrl register offsets and default values are specified as pairs
> 
> I thought we were going to remove "default" here?

Oops, looks like one was left, will remove.
 
> > +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.

OK
 
> > +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.

Will move that to the driver comments.
 
> > +Example:
> 
> I only reviewed the binding document, not the code.

Thanks,

Tony

  parent reply	other threads:[~2012-06-22  8:39 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
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 [this message]
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=20120622083955.GZ12766@atomide.com \
    --to=tony-4v6ys6ai5vpbdgjk7y7tuq@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=swarren-3lzwWm7+Weoh9ZMKESR00Q@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.