linux-gpio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Rafał Miłecki" <zajec5@gmail.com>
To: Tony Lindgren <tony@atomide.com>
Cc: "Linus Walleij" <linus.walleij@linaro.org>,
	"Rob Herring" <robh+dt@kernel.org>,
	"Andy Shevchenko" <andy.shevchenko@gmail.com>,
	linux-gpio@vger.kernel.org, devicetree@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	"Florian Fainelli" <f.fainelli@gmail.com>,
	bcm-kernel-feedback-list@broadcom.com,
	"Rafał Miłecki" <rafal@milecki.pl>
Subject: Re: [PATCH V2 1/6] dt-bindings: pinctrl: support specifying pins, groups & functions
Date: Thu, 25 Nov 2021 13:28:20 +0100	[thread overview]
Message-ID: <3acea66e-c5e1-ff6c-aedb-d9ee61dcf8ab@gmail.com> (raw)
In-Reply-To: <YZ9OAC/swfCbBXFt@atomide.com>

On 25.11.2021 09:49, Tony Lindgren wrote:
> * Rafał Miłecki <zajec5@gmail.com> [211124 23:05]:
>> --- a/Documentation/devicetree/bindings/pinctrl/pinctrl.yaml
>> +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl.yaml
>> @@ -42,4 +42,44 @@ properties:
>>         This property can be set either globally for the pin controller or in
>>         child nodes for individual pin group control.
>>   
>> +  pins:
>> +    type: object
>> +
>> +    patternProperties:
>> +      "^.*$":
>> +        type: object
>> +
>> +        properties:
>> +          number:
>> +            description: Pin number
>> +            $ref: /schemas/types.yaml#/definitions/uint32
>> +
>> +        additionalProperties: false
> 
> Please don't introduce Linux kernel internal numbering here. It's
> like bringing back the interrupt numbers again.

This is a new bit to me and the reason why I got this binding that way.

I had no idea pin numbering is system specific thing. I always thought
pin numbers are present in every chip datasheets and that is just a part
of hardware.

Now I'm reading https://www.kernel.org/doc/Documentation/pinctrl.txt
again it indeed seems to mention that numbering is handled in a way not
related to specs: "I enumerated the pins from 0 in the upper left corner
to 63 in the lower right corner.".

Sorry for that, I hopefully understand your point correctly now.


> Just make this into
> a proper hardware offset from the controller base, so a reg property.
> Sure in some cases the reg property is just an index depending on
> the controller, we don't really care from the binding point of view.
> 
> We already have #pinctrl-cells, so plase do something like the four
> ximaginary examples below:
> 
> 	#pinctrl-cells = <1>;
> 	...
> 	pin@foo {
> 		reg = <0xf00 MUX_MODE0>;
> 		label = "foo_pin";
> 	};
> 
> 
> 	#pinctrl-cells = <2>;
> 	...
> 	pin@foo {
> 		reg = <0xf00 PIN_INPUT_PULLUP MUX_MODE3>;
> 	};
> 
> 
> 	#pinctrl-cells = <2>;
> 	...
> 	pin@f00 {
> 		reg = <0xf00 DELAY_PS(0) DELAY_PS(0)>;
> 	};
> 
> 
> 	#pinctrl-cells = <3>;
> 	...
> 	pin@f00 {
> 		reg = <0xf00 MUX_MODE3 PULL_UP_STRENGTH(36) PULL_DOWN_STRENGTH(20)>;
> 	};
> 
> 
> Then let's attempt to use just standard numbers and defines for the
> values where possible. Then a group of pins is just a list of the pin
> phandles in the devicetree.

I need to ask for help on understanding that reg = <...> syntax.

(Why) do we need to put that extra info in a "reg" property? That seems
like either:
1. Pin specific info
or
2. Phandle arguments

In the first case, instead of:
	pin@f00 {
		reg = <0xf00 MUX_MODE3 PULL_UP_STRENGTH(36) PULL_DOWN_STRENGTH(20)>;
	};
I'd rather use:
	pin@f00 {
		reg = <0xf00>;
		mux_mode3;
		pull_up_strength = <36>;
		pull_down_strength = <20>;
	};

In the second case, shouldn't that be something like:
	pins {
		bar: pin@f00 {
			reg = <0xf00>;
			#pinctrl-cells = <3>;
		};
	};

	groups {
		qux {
			pins = <&bar MUX_MODE3 PULL_UP_STRENGTH(36) PULL_DOWN_STRENGTH(20)>;
		}
	};

  reply	other threads:[~2021-11-25 12:30 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-24 23:04 [PATCH V2 0/6] pinctrl: support platform (e.g. DT) stored pins, groups & functions Rafał Miłecki
2021-11-24 23:04 ` [PATCH V2 1/6] dt-bindings: pinctrl: support specifying " Rafał Miłecki
2021-11-25  8:49   ` Tony Lindgren
2021-11-25 12:28     ` Rafał Miłecki [this message]
2021-11-26  1:03       ` Linus Walleij
2021-11-24 23:04 ` [PATCH V2 2/6] dt-bindings: pinctrl: brcm,ns-pinmux: extend example Rafał Miłecki
2021-11-25 21:26   ` Rob Herring
2021-11-24 23:04 ` [PATCH V2 3/6] pinctrl: prepare API for reading pins, groups & functions Rafał Miłecki
2021-11-24 23:04 ` [PATCH V2 4/6] pinctrl: support reading pins, groups & functions from DT Rafał Miłecki
2021-11-25  9:49   ` Andy Shevchenko
2021-11-25  9:51     ` Andy Shevchenko
2021-11-24 23:04 ` [PATCH V2 5/6] pinctrl: bcm: pinctrl-ns: supoprt DT specified pins, groups & functions Rafał Miłecki
2021-11-24 23:04 ` [PATCH V2 6/6] ARM: dts: BCM5301X: add pinctrl " Rafał Miłecki
2021-11-25  9:58 ` [PATCH V2 0/6] pinctrl: support platform (e.g. DT) stored " Andy Shevchenko
2021-12-09 14:30   ` Rafał Miłecki

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=3acea66e-c5e1-ff6c-aedb-d9ee61dcf8ab@gmail.com \
    --to=zajec5@gmail.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=bcm-kernel-feedback-list@broadcom.com \
    --cc=devicetree@vger.kernel.org \
    --cc=f.fainelli@gmail.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=rafal@milecki.pl \
    --cc=robh+dt@kernel.org \
    --cc=tony@atomide.com \
    /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).