All of lore.kernel.org
 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)>;
		}
	};

WARNING: multiple messages have this Message-ID (diff)
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)>;
		}
	};

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

Thread overview: 30+ 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 ` Rafał Miłecki
2021-11-24 23:04 ` [PATCH V2 1/6] dt-bindings: pinctrl: support specifying " Rafał Miłecki
2021-11-24 23:04   ` Rafał Miłecki
2021-11-25  8:49   ` Tony Lindgren
2021-11-25  8:49     ` Tony Lindgren
2021-11-25 12:28     ` Rafał Miłecki [this message]
2021-11-25 12:28       ` Rafał Miłecki
2021-11-26  1:03       ` Linus Walleij
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-24 23:04   ` Rafał Miłecki
2021-11-25 21:26   ` Rob Herring
2021-11-25 21:26     ` [PATCH V2 2/6] dt-bindings: pinctrl: brcm, ns-pinmux: " 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   ` 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-24 23:04   ` Rafał Miłecki
2021-11-25  9:49   ` Andy Shevchenko
2021-11-25  9:49     ` Andy Shevchenko
2021-11-25  9:51     ` 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   ` Rafał Miłecki
2021-11-24 23:04 ` [PATCH V2 6/6] ARM: dts: BCM5301X: add pinctrl " Rafał Miłecki
2021-11-24 23:04   ` Rafał Miłecki
2021-11-25  9:58 ` [PATCH V2 0/6] pinctrl: support platform (e.g. DT) stored " Andy Shevchenko
2021-11-25  9:58   ` Andy Shevchenko
2021-12-09 14:30   ` Rafał Miłecki
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 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.