All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
To: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>,
	Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>,
	Grygorii Strashko
	<grygorii.strashko-l0cyMroinI0@public.gmane.org>,
	Nishanth Menon <nm-l0cyMroinI0@public.gmane.org>,
	"linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Linux-OMAP <linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [PATCH 1/4] pinctrl: Introduce generic #pinctrl-cells and pinctrl_parse_index_with_args
Date: Thu, 27 Oct 2016 07:11:20 -0700	[thread overview]
Message-ID: <20161027141120.jqvul6q7iz5fjsmb@atomide.com> (raw)
In-Reply-To: <CACRpkdYWB4aa2XvW-yT39cKqy3XChSwCiFRy1mVWhbhse63=3A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

* Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> [161027 00:57]:
> On Tue, Oct 25, 2016 at 6:45 PM, Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> wrote:
> 
> I need some DT person to take a look at this binding and ACK it.
> 
> > +For pin controller hardware with a large number of identical registers naming
> > +each bit both can be unmaintainable. Further there can be a large number of similar
> > +pinctrl hardware using the same registers for different purposes depending on the
> > +packaging. For cases like this, the pinctrl driver may use pinctrl-pin-array helper
> > +binding using a hardware based index and a number of configuration values:
> 
> Maybe we can reword it a bit so that it is clear that this is an
> either-or approach
> for the pin controller, either they use the pins/groups/functions scheme
> or they use this scheme.

Sure, this is just an optional helper.

> > +pincontroller {
> > +       ... /* Standard DT properties for the device itself elided */
> > +       #pinctrl-cells = <2>;
> > +
> > +       state_0_node_a {
> > +               pinctrl-pin-array = <
> > +                       0 A_DELAY_PS(0) G_DELAY_PS(120)
> > +                       4 A_DELAY_PS(0) G_DELAY_PS(360)
> > +                       ...
> > +               >;
> > +       };
> > +       ...
> > +};
> 
> Looks all right to me. Sad to add to the binding mess, but on the other
> hand, in the overall picture this nicely consolidates and structure
> pinctrl-single.
> 
> > +The index for pinctrl-pin-array must relate to the hardware for the pinctrl
> > +registers, and must not be a virtual index of pin instances. The reason for
> > +this is to avoid mapping of the index in the dts files and the pin controller
> > +driver as it can change.
> 
> OK
> 
> > And we want to avoid another case of interrupt
> > +numbering with pinctrl numbering.
> 
> Maybe this file is not a good place for making technical arguments,
> more describing what we agreed on, so cut that sentence IMO.

Sure :)

> > +/*
> > + * For pinctrl binding, typically #pinctrl-cells is for the pin controller
> > + * device, so either parent or grandparent. See pinctrl-bindings.txt.
> > + */
> > +static int pinctrl_find_cells_size(const struct device_node *np,
> > +                                  const char *cells_name)
> > +{
> > +       int cells_size, error;
> > +
> > +       error = of_property_read_u32(np->parent, cells_name, &cells_size);
> > +       if (error) {
> > +               error = of_property_read_u32(np->parent->parent,
> > +                                            cells_name, &cells_size);
> > +               if (error)
> > +                       return -ENOENT;
> > +       }
> > +
> > +       return cells_size;
> > +}
> 
> Can't we just hardcode this to "#pinctrl-cells" and skip the cells_name
> parameter? We can parametrize it the day we need it instead.

Sure we can do that.

> The rest of the helpers look nice and clean.

OK cool thanks,

Tony
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: Tony Lindgren <tony@atomide.com>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Rob Herring <robh+dt@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Jon Hunter <jonathanh@nvidia.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Grygorii Strashko <grygorii.strashko@ti.com>,
	Nishanth Menon <nm@ti.com>,
	"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	Linux-OMAP <linux-omap@vger.kernel.org>
Subject: Re: [PATCH 1/4] pinctrl: Introduce generic #pinctrl-cells and pinctrl_parse_index_with_args
Date: Thu, 27 Oct 2016 07:11:20 -0700	[thread overview]
Message-ID: <20161027141120.jqvul6q7iz5fjsmb@atomide.com> (raw)
In-Reply-To: <CACRpkdYWB4aa2XvW-yT39cKqy3XChSwCiFRy1mVWhbhse63=3A@mail.gmail.com>

* Linus Walleij <linus.walleij@linaro.org> [161027 00:57]:
> On Tue, Oct 25, 2016 at 6:45 PM, Tony Lindgren <tony@atomide.com> wrote:
> 
> I need some DT person to take a look at this binding and ACK it.
> 
> > +For pin controller hardware with a large number of identical registers naming
> > +each bit both can be unmaintainable. Further there can be a large number of similar
> > +pinctrl hardware using the same registers for different purposes depending on the
> > +packaging. For cases like this, the pinctrl driver may use pinctrl-pin-array helper
> > +binding using a hardware based index and a number of configuration values:
> 
> Maybe we can reword it a bit so that it is clear that this is an
> either-or approach
> for the pin controller, either they use the pins/groups/functions scheme
> or they use this scheme.

Sure, this is just an optional helper.

> > +pincontroller {
> > +       ... /* Standard DT properties for the device itself elided */
> > +       #pinctrl-cells = <2>;
> > +
> > +       state_0_node_a {
> > +               pinctrl-pin-array = <
> > +                       0 A_DELAY_PS(0) G_DELAY_PS(120)
> > +                       4 A_DELAY_PS(0) G_DELAY_PS(360)
> > +                       ...
> > +               >;
> > +       };
> > +       ...
> > +};
> 
> Looks all right to me. Sad to add to the binding mess, but on the other
> hand, in the overall picture this nicely consolidates and structure
> pinctrl-single.
> 
> > +The index for pinctrl-pin-array must relate to the hardware for the pinctrl
> > +registers, and must not be a virtual index of pin instances. The reason for
> > +this is to avoid mapping of the index in the dts files and the pin controller
> > +driver as it can change.
> 
> OK
> 
> > And we want to avoid another case of interrupt
> > +numbering with pinctrl numbering.
> 
> Maybe this file is not a good place for making technical arguments,
> more describing what we agreed on, so cut that sentence IMO.

Sure :)

> > +/*
> > + * For pinctrl binding, typically #pinctrl-cells is for the pin controller
> > + * device, so either parent or grandparent. See pinctrl-bindings.txt.
> > + */
> > +static int pinctrl_find_cells_size(const struct device_node *np,
> > +                                  const char *cells_name)
> > +{
> > +       int cells_size, error;
> > +
> > +       error = of_property_read_u32(np->parent, cells_name, &cells_size);
> > +       if (error) {
> > +               error = of_property_read_u32(np->parent->parent,
> > +                                            cells_name, &cells_size);
> > +               if (error)
> > +                       return -ENOENT;
> > +       }
> > +
> > +       return cells_size;
> > +}
> 
> Can't we just hardcode this to "#pinctrl-cells" and skip the cells_name
> parameter? We can parametrize it the day we need it instead.

Sure we can do that.

> The rest of the helpers look nice and clean.

OK cool thanks,

Tony

  parent reply	other threads:[~2016-10-27 14:11 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-25 16:45 [PATCH 0/4] Generic #pinctrl-cells and and pinctrl_parse_index_with_args Tony Lindgren
2016-10-25 16:45 ` [PATCH 1/4] pinctrl: Introduce generic #pinctrl-cells " Tony Lindgren
2016-10-27  7:56   ` Linus Walleij
     [not found]     ` <CACRpkdYWB4aa2XvW-yT39cKqy3XChSwCiFRy1mVWhbhse63=3A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-10-27 14:11       ` Tony Lindgren [this message]
2016-10-27 14:11         ` Tony Lindgren
2016-10-28 16:53         ` Tony Lindgren
     [not found]           ` <20161028165338.y5fyavbw5xfxweg3-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
2016-10-31  6:13             ` Rob Herring
2016-10-31  6:13               ` Rob Herring
2016-11-04 21:36             ` Linus Walleij
2016-11-04 21:36               ` Linus Walleij
2016-10-25 16:45 ` [PATCH 2/4] pinctrl: single: Use generic parser and #pinctrl-cells for pinctrl-single,pins Tony Lindgren
2016-10-26 14:16   ` Tony Lindgren
2016-10-28 16:55     ` Tony Lindgren
2016-11-04 21:41   ` Linus Walleij
2016-10-25 16:45 ` [PATCH 3/4] pinctrl: single: Use generic parser and #pinctrl-cells for pinctrl-single,bits Tony Lindgren
2016-10-25 16:45 ` [PATCH 4/4] ARM: dts: Add #pinctrl-cells for pinctrl-single instances Tony Lindgren
2016-10-31  3:06   ` Rob Herring
2016-10-27  8:15 ` [PATCH 0/4] Generic #pinctrl-cells and and pinctrl_parse_index_with_args Linus Walleij
  -- strict thread matches above, loose matches on Subject: below --
2016-11-03 16:35 [PATCHv2 " Tony Lindgren
2016-11-03 16:35 ` [PATCH 1/4] pinctrl: Introduce generic #pinctrl-cells " Tony Lindgren
2016-11-03 20:28   ` kbuild test robot
2016-11-03 20:48     ` Tony Lindgren
2016-11-04  6:03   ` kbuild test robot
     [not found]   ` <20161103163550.27330-2-tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
2016-11-04 21:50     ` Linus Walleij
2016-11-04 21:50       ` Linus Walleij
     [not found]       ` <CACRpkdaCF4Jc7QY+L44obce=V_W4xgVbPXfuiE7bXJs7ud9q9A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-11-07 15:26         ` Tony Lindgren
2016-11-07 15:26           ` Tony Lindgren
     [not found]           ` <20161107152613.GA2428-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
2016-11-08 10:32             ` Linus Walleij
2016-11-08 10:32               ` Linus Walleij
     [not found]               ` <CACRpkdbdfM8qtMSE1O-VEsnOHGbVuMDhOFtELvqoYuE1JJ=GRg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-11-08 14:44                 ` Tony Lindgren
2016-11-08 14:44                   ` 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=20161027141120.jqvul6q7iz5fjsmb@atomide.com \
    --to=tony-4v6ys6ai5vpbdgjk7y7tuq@public.gmane.org \
    --cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=grygorii.strashko-l0cyMroinI0@public.gmane.org \
    --cc=jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
    --cc=linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
    --cc=linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=mark.rutland-5wv7dgnIgG8@public.gmane.org \
    --cc=nm-l0cyMroinI0@public.gmane.org \
    --cc=robh+dt-DgEjT+Ai2ygdnm+yROfE0A@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.