Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1631950 > unrolled thread

[PATCH v5 00/10] Renesas RZ/A1 pin and gpio controller

Back to article view | Back to linux.kernel

Contents

  [PATCH v5 00/10] Renesas RZ/A1 pin and gpio controller Jacopo Mondi <jacopo+renesas@jmondi.org> - 2017-04-27 10:30 +0200
    [PATCH v5 05/10] arm: dts: dt-bindings: Add Renesas RZ/A1 pinctrl header Jacopo Mondi <jacopo+renesas@jmondi.org> - 2017-04-27 10:30 +0200
      Re: [PATCH v5 05/10] arm: dts: dt-bindings: Add Renesas RZ/A1 pinctrl header Geert Uytterhoeven <geert@linux-m68k.org> - 2017-04-27 10:40 +0200
        Re: [PATCH v5 05/10] arm: dts: dt-bindings: Add Renesas RZ/A1  pinctrl header Simon Horman <horms@verge.net.au> - 2017-04-28 07:20 +0200
    [PATCH v5 07/10] arm: dts: genmai: Add SCIF2 pin group Jacopo Mondi <jacopo+renesas@jmondi.org> - 2017-04-27 10:30 +0200
      Re: [PATCH v5 07/10] arm: dts: genmai: Add SCIF2 pin group Simon Horman <horms@verge.net.au> - 2017-04-28 07:30 +0200
    [PATCH v5 10/10] arm: dts: genmai: Add ethernet pin group Jacopo Mondi <jacopo+renesas@jmondi.org> - 2017-04-27 10:30 +0200
      Re: [PATCH v5 10/10] arm: dts: genmai: Add ethernet pin group Geert Uytterhoeven <geert@linux-m68k.org> - 2017-04-27 12:00 +0200
        RE: [PATCH v5 10/10] arm: dts: genmai: Add ethernet pin group Chris Brandt <Chris.Brandt@renesas.com> - 2017-04-27 12:50 +0200
          Re: [PATCH v5 10/10] arm: dts: genmai: Add ethernet pin group Simon Horman <horms@verge.net.au> - 2017-04-28 07:30 +0200
          Re: [PATCH v5 10/10] arm: dts: genmai: Add ethernet pin group Geert Uytterhoeven <geert@linux-m68k.org> - 2017-04-28 09:20 +0200
            RE: [PATCH v5 10/10] arm: dts: genmai: Add ethernet pin group Chris Brandt <Chris.Brandt@renesas.com> - 2017-04-28 16:50 +0200
              Re: [PATCH v5 10/10] arm: dts: genmai: Add ethernet pin group Linus Walleij <linus.walleij@linaro.org> - 2017-05-05 14:10 +0200
                Re: [PATCH v5 10/10] arm: dts: genmai: Add ethernet pin group Geert Uytterhoeven <geert@linux-m68k.org> - 2017-05-05 14:30 +0200
                RE: [PATCH v5 10/10] arm: dts: genmai: Add ethernet pin group Chris Brandt <Chris.Brandt@renesas.com> - 2017-05-05 14:50 +0200
                  Re: [PATCH v5 10/10] arm: dts: genmai: Add ethernet pin group Linus Walleij <linus.walleij@linaro.org> - 2017-05-11 15:50 +0200
      Re: [PATCH v5 10/10] arm: dts: genmai: Add ethernet pin group Linus Walleij <linus.walleij@linaro.org> - 2017-04-28 11:00 +0200
        RE: [PATCH v5 10/10] arm: dts: genmai: Add ethernet pin group Chris Brandt <Chris.Brandt@renesas.com> - 2017-04-28 16:00 +0200
    [PATCH v5 01/10] pinctrl: generic: Add bi-directional and output-enable Jacopo Mondi <jacopo+renesas@jmondi.org> - 2017-04-27 10:30 +0200
      Re: [PATCH v5 01/10] pinctrl: generic: Add bi-directional and output-enable Andy Shevchenko <andy.shevchenko@gmail.com> - 2017-04-27 17:00 +0200
        Re: [PATCH v5 01/10] pinctrl: generic: Add bi-directional and output-enable Linus Walleij <linus.walleij@linaro.org> - 2017-04-28 10:40 +0200
          Re: [PATCH v5 01/10] pinctrl: generic: Add bi-directional and output-enable Geert Uytterhoeven <geert@linux-m68k.org> - 2017-04-28 12:20 +0200
            Re: [PATCH v5 01/10] pinctrl: generic: Add bi-directional and output-enable Linus Walleij <linus.walleij@linaro.org> - 2017-05-07 23:50 +0200
          RE: [PATCH v5 01/10] pinctrl: generic: Add bi-directional and  output-enable Chris Brandt <Chris.Brandt@renesas.com> - 2017-04-28 14:10 +0200
            Re: [PATCH v5 01/10] pinctrl: generic: Add bi-directional and output-enable Andy Shevchenko <andy.shevchenko@gmail.com> - 2017-04-28 14:20 +0200
              RE: [PATCH v5 01/10] pinctrl: generic: Add bi-directional and  output-enable Chris Brandt <Chris.Brandt@renesas.com> - 2017-04-28 15:20 +0200
                Re: [PATCH v5 01/10] pinctrl: generic: Add bi-directional and output-enable Andy Shevchenko <andy.shevchenko@gmail.com> - 2017-04-28 17:00 +0200
                  RE: [PATCH v5 01/10] pinctrl: generic: Add bi-directional and  output-enable Chris Brandt <Chris.Brandt@renesas.com> - 2017-04-28 17:20 +0200
                    Re: [PATCH v5 01/10] pinctrl: generic: Add bi-directional and output-enable Andy Shevchenko <andy.shevchenko@gmail.com> - 2017-04-28 17:40 +0200
                      RE: [PATCH v5 01/10] pinctrl: generic: Add bi-directional and  output-enable Chris Brandt <Chris.Brandt@renesas.com> - 2017-04-28 18:50 +0200
                  Re: [PATCH v5 01/10] pinctrl: generic: Add bi-directional and output-enable Linus Walleij <linus.walleij@linaro.org> - 2017-05-08 01:30 +0200
                    Re: [PATCH v5 01/10] pinctrl: generic: Add bi-directional and  output-enable jmondi <jacopo@jmondi.org> - 2017-05-08 18:10 +0200
                      Re: [PATCH v5 01/10] pinctrl: generic: Add bi-directional and output-enable Andy Shevchenko <andy.shevchenko@gmail.com> - 2017-05-08 18:20 +0200
                        RE: [PATCH v5 01/10] pinctrl: generic: Add bi-directional and  output-enable Chris Brandt <Chris.Brandt@renesas.com> - 2017-05-08 19:10 +0200
                          Re: [PATCH v5 01/10] pinctrl: generic: Add bi-directional and output-enable Andy Shevchenko <andy.shevchenko@gmail.com> - 2017-05-08 20:30 +0200
                            RE: [PATCH v5 01/10] pinctrl: generic: Add bi-directional and  output-enable Chris Brandt <Chris.Brandt@renesas.com> - 2017-05-08 22:10 +0200
                        Re: [PATCH v5 01/10] pinctrl: generic: Add bi-directional and  output-enable jmondi <jacopo@jmondi.org> - 2017-05-08 19:30 +0200
                          Re: [PATCH v5 01/10] pinctrl: generic: Add bi-directional and output-enable Andy Shevchenko <andy.shevchenko@gmail.com> - 2017-05-08 19:50 +0200
                            Re: [PATCH v5 01/10] pinctrl: generic: Add bi-directional and  output-enable jmondi <jacopo@jmondi.org> - 2017-05-09 12:00 +0200
                          Re: [PATCH v5 01/10] pinctrl: generic: Add bi-directional and output-enable Linus Walleij <linus.walleij@linaro.org> - 2017-05-08 23:20 +0200
                            Re: [PATCH v5 01/10] pinctrl: generic: Add bi-directional and output-enable Geert Uytterhoeven <geert@linux-m68k.org> - 2017-05-09 13:00 +0200
    [PATCH v5 02/10] pinctrl: generic: Add macros to unpack properties Jacopo Mondi <jacopo+renesas@jmondi.org> - 2017-04-27 10:30 +0200
      Re: [PATCH v5 02/10] pinctrl: generic: Add macros to unpack properties Geert Uytterhoeven <geert@linux-m68k.org> - 2017-04-27 10:40 +0200
      Re: [PATCH v5 02/10] pinctrl: generic: Add macros to unpack properties Linus Walleij <linus.walleij@linaro.org> - 2017-04-28 10:20 +0200
        Re: [PATCH v5 02/10] pinctrl: generic: Add macros to unpack properties Geert Uytterhoeven <geert@linux-m68k.org> - 2017-04-28 12:10 +0200
        Re: [PATCH v5 02/10] pinctrl: generic: Add macros to unpack  properties jmondi <jacopo@jmondi.org> - 2017-04-28 14:50 +0200
        Re: [PATCH v5 02/10] pinctrl: generic: Add macros to unpack properties Andy Shevchenko <andy.shevchenko@gmail.com> - 2017-04-28 18:30 +0200
    [PATCH v5 04/10] dt-bindings: pinctrl: Add RZ/A1 bindings doc Jacopo Mondi <jacopo+renesas@jmondi.org> - 2017-04-27 10:30 +0200
      Re: [PATCH v5 04/10] dt-bindings: pinctrl: Add RZ/A1 bindings doc Geert Uytterhoeven <geert@linux-m68k.org> - 2017-04-27 10:40 +0200
      Re: [PATCH v5 04/10] dt-bindings: pinctrl: Add RZ/A1 bindings doc Rob Herring <robh@kernel.org> - 2017-04-28 23:10 +0200
    [PATCH v5 06/10] arm: dts: r7s72100: Add pin controller node Jacopo Mondi <jacopo+renesas@jmondi.org> - 2017-04-27 10:30 +0200
    [PATCH v5 09/10] arm: dts: genmai: Add user led device nodes Jacopo Mondi <jacopo+renesas@jmondi.org> - 2017-04-27 10:30 +0200
    [PATCH v5 08/10] arm: dts: genmai: Add RIIC2 pin group Jacopo Mondi <jacopo+renesas@jmondi.org> - 2017-04-27 10:30 +0200
    Re: [PATCH v5 00/10] Renesas RZ/A1 pin and gpio controller Geert Uytterhoeven <geert@linux-m68k.org> - 2017-04-27 10:50 +0200
      Re: [PATCH v5 00/10] Renesas RZ/A1 pin and gpio controller Simon Horman <horms@verge.net.au> - 2017-04-28 07:30 +0200
      Re: [PATCH v5 00/10] Renesas RZ/A1 pin and gpio controller jmondi <jacopo@jmondi.org> - 2017-04-28 09:30 +0200
        Re: [PATCH v5 00/10] Renesas RZ/A1 pin and gpio controller Simon Horman <horms@verge.net.au> - 2017-04-28 09:40 +0200
        Re: [PATCH v5 00/10] Renesas RZ/A1 pin and gpio controller Geert Uytterhoeven <geert@linux-m68k.org> - 2017-04-28 09:40 +0200

Page 3 of 3 — ← Prev page 1 2 [3]

#1638033 — Re: [PATCH v5 01/10] pinctrl: generic: Add bi-directional and output-enable

Hi Linus et al,

On Mon, May 8, 2017 at 11:19 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Mon, May 8, 2017 at 7:25 PM, jmondi <jacopo@jmondi.org> wrote:
>> From my perspective these flags are configurations internal to the pin
>> controller hardware used to enable/disable input buffers when a pin needs to
>> perform in both direction.
>> The level of detail I can provide on this is the logical diagram we have pointed
>> you to already.
>>
>> As I assume you are trying to get this answer from us in order to
>> avoid duplicating things in pin controller sub-system, and I
>> understand this, but my question here was "can we have those flags as part
>> of the pinmux property argument list, as that property description
>> seems to allow us to do that, instead of making them generic pin
>> configuration properties and upset other developers?"
>
> Pinmux with all it's magic flags baked into one is not any better
> or any more readable. The solution is already very pretty except
> for these two flags which I am sure we can agree on a way forward
> for.
>
> What we choose between is not this or another less transparent
> pin configuration mechanism, the mechanism (whether magic bits
> to pinmux or reasonable properties) does not matter.
>
> There is a strong preference to use the generic bindings.
>
> So the discussion is whether to use:
>
> bi-directional;
> output-enable;
>
> Or some already defined config flags.
>
> If these are too idiomatic to be used by others, they should anyways
> look similar, like:
>
> renesas,bi-directional;
> renesas,output-enable;
>
> Like the Qualcomm weirdness found in drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
>
> qcom,pull-up-strength = <..>;
>
> Check how they use
> #define PMIC_GPIO_CONF_PULL_UP                 (PIN_CONFIG_END + 1)

The question I'm asking myself is: are these settings related to pin
configuration (i.e. depending on the use of the pin, and several settings
are valid, depending on the use case), or are they related to pinmux
(i.e. defined by the function)?

Configuring drive strength or pull-up are clearly related to pin
configuration.  Depending on what you connect, or on how you connect it,
you want a different drive strength, or choose a different output buffer
type (e.g. totem pole vs. open-collector). All of these are valid
configurations, depending on the use case.

But the settings RZ/A1H needs are different.  Some (e.g. "input-enable")
may sound like related to pin configuration. However, the big discerning
factor is that these settings are implied by the pinmux function. Their
presence is purely dictated by the chosen pinmux function. There's no use
case for doing otherwise (i.e. adding them when not needed, or removing
them when needed, according to the datasheet).

Note that e.g. the existing "input-enable" property is clearly a pin
configuration property. This is even reflected in DT, as the property is
not specified as part of the "pinmux" property, but in the surrounding pin
subnode of the pin-controller.

Hence I think we should not use generic pin properties, but consider these
settings to be part of pinmux configuration.
As having large tables in the driver is undesirable, I think storing the
settings in the "pinmux" property (by encoding them as flags passed to the
RZA1_PINMUX() macro) is our best option.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[toc] | [prev] | [next] | [standalone]

#1631957 — [PATCH v5 02/10] pinctrl: generic: Add macros to unpack properties

Add PIN_CONF_UNPACK_PARAM and PIN_CONF_UNPACK_ARGS macros useful to
unpack generic properties and their arguments

Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
---
 include/linux/pinctrl/pinconf-generic.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/include/linux/pinctrl/pinconf-generic.h b/include/linux/pinctrl/pinconf-generic.h
index 279e3c5..2cd2a03 100644
--- a/include/linux/pinctrl/pinconf-generic.h
+++ b/include/linux/pinctrl/pinconf-generic.h
@@ -118,7 +118,9 @@ enum pin_config_param {
 /*
  * Helpful configuration macro to be used in tables etc.
  */
-#define PIN_CONF_PACKED(p, a) ((a << 8) | ((unsigned long) p & 0xffUL))
+#define PIN_CONF_PACKED(p, a) (((a) << 8) | ((unsigned long) (p) & 0xffUL))
+#define PIN_CONF_UNPACK_PARAM(c) ((c) & 0xffUL)
+#define PIN_CONF_UNPACK_ARGS(c) ((c) >> 8)
 
 /*
  * The following inlines stuffs a configuration parameter and data value
-- 
2.7.4

[toc] | [prev] | [next] | [standalone]

#1631968 — Re: [PATCH v5 02/10] pinctrl: generic: Add macros to unpack properties

On Thu, Apr 27, 2017 at 10:19 AM, Jacopo Mondi
<jacopo+renesas@jmondi.org> wrote:
> Add PIN_CONF_UNPACK_PARAM and PIN_CONF_UNPACK_ARGS macros useful to
> unpack generic properties and their arguments
>
> Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>

Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[toc] | [prev] | [next] | [standalone]

#1632614 — Re: [PATCH v5 02/10] pinctrl: generic: Add macros to unpack properties

On Thu, Apr 27, 2017 at 10:19 AM, Jacopo Mondi
<jacopo+renesas@jmondi.org> wrote:

> Add PIN_CONF_UNPACK_PARAM and PIN_CONF_UNPACK_ARGS macros useful to
> unpack generic properties and their arguments
>
> Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>

(...)

/*
  * Helpful configuration macro to be used in tables etc.

Then this should say "macros" rather than "macro".

> -#define PIN_CONF_PACKED(p, a) ((a << 8) | ((unsigned long) p & 0xffUL))
> +#define PIN_CONF_PACKED(p, a) (((a) << 8) | ((unsigned long) (p) & 0xffUL))

Also adding some extra parantheses I see.

> +#define PIN_CONF_UNPACK_PARAM(c) ((c) & 0xffUL)
> +#define PIN_CONF_UNPACK_ARGS(c) ((c) >> 8)

But why.

I have these two static inlines just below your new macros:

static inline enum pin_config_param pinconf_to_config_param(unsigned
long config)
{
        return (enum pin_config_param) (config & 0xffUL);
}

static inline u32 pinconf_to_config_argument(unsigned long config)
{
        return (u32) ((config >> 8) & 0xffffffUL);
}

Why can't you use this in your code instead of macros?

We generally prefer static inlines over macros because they are easier
to read.

Yours,
Linus Walleij

[toc] | [prev] | [next] | [standalone]

#1632768 — Re: [PATCH v5 02/10] pinctrl: generic: Add macros to unpack properties

On Fri, Apr 28, 2017 at 10:16 AM, Linus Walleij
<linus.walleij@linaro.org> wrote:
> On Thu, Apr 27, 2017 at 10:19 AM, Jacopo Mondi
>> +#define PIN_CONF_UNPACK_PARAM(c) ((c) & 0xffUL)
>> +#define PIN_CONF_UNPACK_ARGS(c) ((c) >> 8)
>
> But why.
>
> I have these two static inlines just below your new macros:
>
> static inline enum pin_config_param pinconf_to_config_param(unsigned
> long config)
> {
>         return (enum pin_config_param) (config & 0xffUL);
> }
>
> static inline u32 pinconf_to_config_argument(unsigned long config)
> {
>         return (u32) ((config >> 8) & 0xffffffUL);
> }

Cool, need...more...context...in...patches ;-)

> Why can't you use this in your code instead of macros?
>
> We generally prefer static inlines over macros because they are easier
> to read.

Sure.

Thanks for noticing!

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[toc] | [prev] | [next] | [standalone]

#1632846 — Re: [PATCH v5 02/10] pinctrl: generic: Add macros to unpack properties

Hi Linus,

On Fri, Apr 28, 2017 at 10:16:22AM +0200, Linus Walleij wrote:
> On Thu, Apr 27, 2017 at 10:19 AM, Jacopo Mondi
> <jacopo+renesas@jmondi.org> wrote:
>
> > Add PIN_CONF_UNPACK_PARAM and PIN_CONF_UNPACK_ARGS macros useful to
> > unpack generic properties and their arguments
> >
> > Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
>
> (...)
>
> /*
>   * Helpful configuration macro to be used in tables etc.
>
> Then this should say "macros" rather than "macro".
>
> > -#define PIN_CONF_PACKED(p, a) ((a << 8) | ((unsigned long) p & 0xffUL))
> > +#define PIN_CONF_PACKED(p, a) (((a) << 8) | ((unsigned long) (p) & 0xffUL))
>
> Also adding some extra parantheses I see.
>
> > +#define PIN_CONF_UNPACK_PARAM(c) ((c) & 0xffUL)
> > +#define PIN_CONF_UNPACK_ARGS(c) ((c) >> 8)
>
> But why.
>
> I have these two static inlines just below your new macros:
>
> static inline enum pin_config_param pinconf_to_config_param(unsigned
> long config)
> {
>         return (enum pin_config_param) (config & 0xffUL);
> }
>
> static inline u32 pinconf_to_config_argument(unsigned long config)
> {
>         return (u32) ((config >> 8) & 0xffffffUL);
> }
>
> Why can't you use this in your code instead of macros?
>
> We generally prefer static inlines over macros because they are easier
> to read.
>

Right. I haven't noticed them.
I'll drop this patch, sorry for noise

> Yours,
> Linus Walleij

[toc] | [prev] | [next] | [standalone]

#1633013 — Re: [PATCH v5 02/10] pinctrl: generic: Add macros to unpack properties

On Fri, Apr 28, 2017 at 11:16 AM, Linus Walleij
<linus.walleij@linaro.org> wrote:
> On Thu, Apr 27, 2017 at 10:19 AM, Jacopo Mondi
> <jacopo+renesas@jmondi.org> wrote:

> But why.
>
> I have these two static inlines just below your new macros:

+1.

> We generally prefer static inlines over macros because they are easier
> to read.

Not only. It adds type checking as well AFAIUC.

-- 
With Best Regards,
Andy Shevchenko

[toc] | [prev] | [next] | [standalone]

#1631959 — [PATCH v5 04/10] dt-bindings: pinctrl: Add RZ/A1 bindings doc

Add device tree bindings documentation for Renesas RZ/A1 gpio and pin
controller.

Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
---
 .../bindings/pinctrl/renesas,rza1-pinctrl.txt      | 219 +++++++++++++++++++++
 1 file changed, 219 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pinctrl/renesas,rza1-pinctrl.txt

diff --git a/Documentation/devicetree/bindings/pinctrl/renesas,rza1-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/renesas,rza1-pinctrl.txt
new file mode 100644
index 0000000..5a1106d
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/renesas,rza1-pinctrl.txt
@@ -0,0 +1,219 @@
+Renesas RZ/A1 combined Pin and GPIO controller
+
+The Renesas SoCs of the RZ/A1 family feature a combined Pin and GPIO controller,
+named "Ports" in the hardware reference manual.
+Pin multiplexing and GPIO configuration is performed on a per-pin basis
+writing configuration values to per-port register sets.
+Each "port" features up to 16 pins, each of them configurable for GPIO
+function (port mode) or in alternate function mode.
+Up to 8 different alternate function modes exist for each single pin.
+
+Pin controller node
+-------------------
+
+Required properties:
+  - compatible
+    this shall be "renesas,r7s72100-ports".
+
+  - reg
+    address base and length of the memory area where the pin controller
+    hardware is mapped to.
+
+Example:
+Pin controller node for RZ/A1H SoC (r7s72100)
+
+pinctrl: pin-controller@fcfe3000 {
+	compatible = "renesas,r7s72100-ports";
+
+	reg = <0xfcfe3000 0x4230>;
+};
+
+Sub-nodes
+---------
+
+The child nodes of the pin controller node describe a pin multiplexing
+function or a GPIO controller alternatively.
+
+- Pin multiplexing sub-nodes:
+  A pin multiplexing sub-node describes how to configure a set of
+  (or a single) pin in some desired alternate function mode.
+  A single sub-node may define several pin configurations.
+  Some alternate functions require special pin configuration flags to be
+  supplied along with the alternate function configuration number.
+  When the hardware reference manual specifies a pin function to be either
+  "bi-directional" or "software IO driven", use the generic properties from
+  the <include/linux/pinctrl/pinconf_generic.h> header file to instruct the
+  pin controller to perform the desired pin configuration operations.
+  Please refer to pinctrl-bindings.txt to get to know more on generic
+  pin properties usage.
+
+  The allowed generic formats for a pin multiplexing sub-node are the
+  following ones:
+
+  node-1 {
+      pinmux = <PIN_ID_AND_MUX>, <PIN_ID_AND_MUX>, ... ;
+      GENERIC_PINCONFIG;
+  };
+
+  node-2 {
+      sub-node-1 {
+          pinmux = <PIN_ID_AND_MUX>, <PIN_ID_AND_MUX>, ... ;
+          GENERIC_PINCONFIG;
+      };
+
+      sub-node-2 {
+          pinmux = <PIN_ID_AND_MUX>, <PIN_ID_AND_MUX>, ... ;
+          GENERIC_PINCONFIG;
+      };
+
+      ...
+
+      sub-node-n {
+          pinmux = <PIN_ID_AND_MUX>, <PIN_ID_AND_MUX>, ... ;
+          GENERIC_PINCONFIG;
+      };
+  };
+
+  Use the second format when pins part of the same logical group need to have
+  different generic pin configuration flags applied.
+
+  Client sub-nodes shall refer to pin multiplexing sub-nodes using the phandle
+  of the most external one.
+
+  Eg.
+
+  client-1 {
+      ...
+      pinctrl-0 = <&node-1>;
+      ...
+  };
+
+  client-2 {
+      ...
+      pinctrl-0 = <&node-2>;
+      ...
+  };
+
+  Required properties:
+    - pinmux:
+      integer array representing pin number and pin multiplexing configuration.
+      When a pin has to be configured in alternate function mode, use this
+      property to identify the pin by its global index, and provide its
+      alternate function configuration number along with it.
+      When multiple pins are required to be configured as part of the same
+      alternate function they shall be specified as members of the same
+      argument list of a single "pinmux" property.
+      Helper macros to ease assembling the pin index from its position
+      (port where it sits on and pin number) and alternate function identifier
+      are provided by the pin controller header file at:
+      <include/dt-bindings/pinctrl/r7s72100-pinctrl.h>
+      Integers values in "pinmux" argument list are assembled as:
+      ((PORT * 16 + PIN) | MUX_FUNC << 16)
+
+  Optional generic properties:
+    - bi-directional:
+      for pins requiring bi-directional operations.
+    - input-enable:
+      for pins requiring software driven IO input operations.
+    - output-enable:
+      for pins requiring software driven IO output operations.
+
+  The hardware reference manual specifies when a pin has to be configured to
+  work in bi-directional mode and when the IO direction has to be specified
+  by software.
+
+  Example:
+  A serial communication interface with a TX output pin and an RX input pin.
+
+  &pinctrl {
+	scif2_pins: serial2 {
+		pinmux = <RZA1_PINMUX(3, 0, 6)>, <RZA1_PINMUX(3, 2, 4)>;
+	};
+  };
+
+  Pin #0 on port #3 is configured as alternate function #6.
+  Pin #2 on port #3 is configured as alternate function #4.
+
+  Example 2:
+  I2c master: both SDA and SCL pins need bi-directional operations
+
+  &pinctrl {
+	i2c2_pins: i2c2 {
+		pinmux = <RZA1_PINMUX(1, 4, 1)>, <RZA1_PINMUX(1, 5, 1)>;
+		bi-directional;
+	};
+  };
+
+  Pin #4 on port #1 is configured as alternate function #1.
+  Pin #5 on port #1 is configured as alternate function #1.
+  Both need to work in bi-directional mode.
+
+  Example 3:
+  Multi-function timer input and output compare pins.
+  Configure TIOC0A as software driven input and TIOC0B as software driven
+  output.
+
+  &pinctrl {
+	tioc0_pins: tioc0 {
+		tioc0_input_pins {
+			pinumx = <RZA1_PINMUX(4, 0, 2)>;
+			input-enable;
+		};
+
+		tioc0_output_pins {
+			pinmux = <RZA1_PINMUX(4, 1, 1)>;
+			output-enable;
+		};
+	};
+  };
+
+
+  &tioc0 {
+	...
+	pinctrl-0 = <&tioc0_pins>;
+	...
+  };
+
+  Pin #0 on port #4 is configured as alternate function #2 with IO direction
+  specified by software as input.
+  Pin #1 on port #4 is configured as alternate function #1 with IO direction
+  specified by software as output.
+
+- GPIO controller sub-nodes:
+  Each port of the r7s72100 pin controller hardware is itself a GPIO controller.
+  Different SoCs have different numbers of available pins per port, but
+  generally speaking, each of them can be configured in GPIO ("port") mode
+  on this hardware.
+  Describe GPIO controllers using sub-nodes with the following properties.
+
+  Required properties:
+    - gpio-controller
+      empty property as defined by the GPIO bindings documentation.
+    - #gpio-cells
+      number of cells required to identify and configure a GPIO.
+      Shall be 2.
+    - gpio-ranges
+      Describes a GPIO controller specifying its specific pin base, the pin
+      base in the global pin numbering space, and the number of controlled
+      pins, as defined by the GPIO bindings documentation. Refer to
+      Documentation/devicetree/bindings/gpio/gpio.txt file for a more detailed
+      description.
+
+  Example:
+  A GPIO controller node, controlling 16 pins indexed from 0.
+  The GPIO controller base in the global pin indexing space is pin 48, thus
+  pins [0 - 15] on this controller map to pins [48 - 63] in the global pin
+  indexing space.
+
+  port3: gpio-3 {
+	gpio-controller;
+	#gpio-cells = <2>;
+	gpio-ranges = <&pinctrl 0 48 16>;
+  };
+
+  A device node willing to use pins controlled by this GPIO controller, shall
+  refer to it as follows:
+
+  led1 {
+	gpios = <&port3 10 GPIO_ACTIVE_LOW>;
+  };
-- 
2.7.4

[toc] | [prev] | [next] | [standalone]

#1631964 — Re: [PATCH v5 04/10] dt-bindings: pinctrl: Add RZ/A1 bindings doc

On Thu, Apr 27, 2017 at 10:19 AM, Jacopo Mondi
<jacopo+renesas@jmondi.org> wrote:
> Add device tree bindings documentation for Renesas RZ/A1 gpio and pin
> controller.
>
> Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>

Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[toc] | [prev] | [next] | [standalone]

#1633157 — Re: [PATCH v5 04/10] dt-bindings: pinctrl: Add RZ/A1 bindings doc

On Thu, Apr 27, 2017 at 10:19:48AM +0200, Jacopo Mondi wrote:
> Add device tree bindings documentation for Renesas RZ/A1 gpio and pin
> controller.
> 
> Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
> ---
>  .../bindings/pinctrl/renesas,rza1-pinctrl.txt      | 219 +++++++++++++++++++++
>  1 file changed, 219 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/pinctrl/renesas,rza1-pinctrl.txt

Acked-by: Rob Herring <robh@kernel.org>

[toc] | [prev] | [next] | [standalone]

#1631960 — [PATCH v5 06/10] arm: dts: r7s72100: Add pin controller node

Add pin controller node with 12 gpio controller sub-nodes to
r7s72100 dtsi.

Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
 arch/arm/boot/dts/r7s72100.dtsi | 78 +++++++++++++++++++++++++++++++++++++++++
 1 file changed, 78 insertions(+)

diff --git a/arch/arm/boot/dts/r7s72100.dtsi b/arch/arm/boot/dts/r7s72100.dtsi
index b8aa256..9342ff4 100644
--- a/arch/arm/boot/dts/r7s72100.dtsi
+++ b/arch/arm/boot/dts/r7s72100.dtsi
@@ -180,6 +180,84 @@
 		};
 	};
 
+	pinctrl: pin-controller@fcfe3000 {
+		compatible = "renesas,r7s72100-ports";
+
+		reg = <0xfcfe3000 0x4230>;
+
+		port0: gpio-0 {
+			gpio-controller;
+			#gpio-cells = <2>;
+			gpio-ranges = <&pinctrl 0 0 6>;
+		};
+
+		port1: gpio-1 {
+			gpio-controller;
+			#gpio-cells = <2>;
+			gpio-ranges = <&pinctrl 0 16 16>;
+		};
+
+		port2: gpio-2 {
+			gpio-controller;
+			#gpio-cells = <2>;
+			gpio-ranges = <&pinctrl 0 32 16>;
+		};
+
+		port3: gpio-3 {
+			gpio-controller;
+			#gpio-cells = <2>;
+			gpio-ranges = <&pinctrl 0 48 16>;
+		};
+
+		port4: gpio-4 {
+			gpio-controller;
+			#gpio-cells = <2>;
+			gpio-ranges = <&pinctrl 0 64 16>;
+		};
+
+		port5: gpio-5 {
+			gpio-controller;
+			#gpio-cells = <2>;
+			gpio-ranges = <&pinctrl 0 80 11>;
+		};
+
+		port6: gpio-6 {
+			gpio-controller;
+			#gpio-cells = <2>;
+			gpio-ranges = <&pinctrl 0 96 16>;
+		};
+
+		port7: gpio-7 {
+			gpio-controller;
+			#gpio-cells = <2>;
+			gpio-ranges = <&pinctrl 0 112 16>;
+		};
+
+		port8: gpio-8 {
+			gpio-controller;
+			#gpio-cells = <2>;
+			gpio-ranges = <&pinctrl 0 128 16>;
+		};
+
+		port9: gpio-9 {
+			gpio-controller;
+			#gpio-cells = <2>;
+			gpio-ranges = <&pinctrl 0 144 8>;
+		};
+
+		port10: gpio-10 {
+			gpio-controller;
+			#gpio-cells = <2>;
+			gpio-ranges = <&pinctrl 0 160 16>;
+		};
+
+		port11: gpio-11 {
+			gpio-controller;
+			#gpio-cells = <2>;
+			gpio-ranges = <&pinctrl 0 176 16>;
+		};
+	};
+
 	scif0: serial@e8007000 {
 		compatible = "renesas,scif-r7s72100", "renesas,scif";
 		reg = <0xe8007000 64>;
-- 
2.7.4

[toc] | [prev] | [next] | [standalone]

#1631961 — [PATCH v5 09/10] arm: dts: genmai: Add user led device nodes

Add device nodes for user leds on Genmai board.

Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
 arch/arm/boot/dts/r7s72100-genmai.dts | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm/boot/dts/r7s72100-genmai.dts b/arch/arm/boot/dts/r7s72100-genmai.dts
index 9add1b6..f7c512e 100644
--- a/arch/arm/boot/dts/r7s72100-genmai.dts
+++ b/arch/arm/boot/dts/r7s72100-genmai.dts
@@ -11,6 +11,7 @@
 
 /dts-v1/;
 #include "r7s72100.dtsi"
+#include <dt-bindings/gpio/gpio.h>
 #include <dt-bindings/pinctrl/r7s72100-pinctrl.h>
 
 / {
@@ -35,6 +36,19 @@
 		#address-cells = <1>;
 		#size-cells = <1>;
 	};
+
+	leds {
+		status = "okay";
+		compatible = "gpio-leds";
+
+		led1 {
+			gpios = <&port4 10 GPIO_ACTIVE_LOW>;
+		};
+
+		led2 {
+			gpios = <&port4 11 GPIO_ACTIVE_LOW>;
+		};
+	};
 };
 
 &pinctrl {
-- 
2.7.4

[toc] | [prev] | [next] | [standalone]

#1631962 — [PATCH v5 08/10] arm: dts: genmai: Add RIIC2 pin group

Add pin configuration subnode for RIIC2 interface.

Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
 arch/arm/boot/dts/r7s72100-genmai.dts | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/boot/dts/r7s72100-genmai.dts b/arch/arm/boot/dts/r7s72100-genmai.dts
index c28d74b..9add1b6 100644
--- a/arch/arm/boot/dts/r7s72100-genmai.dts
+++ b/arch/arm/boot/dts/r7s72100-genmai.dts
@@ -43,6 +43,12 @@
 		/* P3_0 as TxD2; P3_2 as RxD2 */
 		pinmux = <RZA1_PINMUX(3, 0, 6)>, <RZA1_PINMUX(3, 2, 4)>;
 	};
+
+	i2c2_pins: i2c2 {
+		/* RIIC2: P1_4 as SCL, P1_5 as SDA */
+		pinmux = <RZA1_PINMUX(1, 4, 1)>, <RZA1_PINMUX(1, 5, 1)>;
+		bi-directional;
+	};
 };
 
 &extal_clk {
@@ -61,6 +67,9 @@
 	status = "okay";
 	clock-frequency = <400000>;
 
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c2_pins>;
+
 	eeprom@50 {
 		compatible = "renesas,24c128";
 		reg = <0x50>;
-- 
2.7.4

[toc] | [prev] | [next] | [standalone]

#1631971

Hi Jacopo,

On Thu, Apr 27, 2017 at 10:19 AM, Jacopo Mondi
<jacopo+renesas@jmondi.org> wrote:
>    this is 5th round of gpio/pincontroller for RZ/A1 devices.
>
> I have updated the pin controller driver to use the newly introduced
> "pinctrl_enable()" function.
> This is required since v4.11-rc7 as otherwise, as reported by Chris Brandt,
> the pin controller does not start.
>
> I have incorporated your comments on the device tree bindings documentation,
> and added to pinctrl-generic.h header file two macros to unpack generic
> properties and their arguments.
>
> Tested with SCIF, RIIC, ETHER and gpio-leds on Genmai board.

Thanks for the update!

> Jacopo Mondi (10):
>   pinctrl: generic: Add bi-directional and output-enable

Already applied by LinusW.

>   pinctrl: generic: Add macros to unpack properties

LinusW: do you want me to queue this together with the driver for v4.13,
or will you take this single patch for v4.12?

>   pinctrl: Renesas RZ/A1 pin and gpio controller
>   dt-bindings: pinctrl: Add RZ/A1 bindings doc

Will queue in sh-pfc-for-v4.13.

>   arm: dts: dt-bindings: Add Renesas RZ/A1 pinctrl header
>   arm: dts: r7s72100: Add pin controller node
>   arm: dts: genmai: Add SCIF2 pin group
>   arm: dts: genmai: Add RIIC2 pin group
>   arm: dts: genmai: Add user led device nodes
>   arm: dts: genmai: Add ethernet pin group

These are for Simon.

Does applying the DTS changes before the driver introduce regressions?
If no, Simon can queue them for v4.13.
If yes, they'll have to wait for v4.14.

Thanks!

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[toc] | [prev] | [next] | [standalone]

#1632530

On Thu, Apr 27, 2017 at 10:42:02AM +0200, Geert Uytterhoeven wrote:
> Hi Jacopo,
> 
> On Thu, Apr 27, 2017 at 10:19 AM, Jacopo Mondi
> <jacopo+renesas@jmondi.org> wrote:
> >    this is 5th round of gpio/pincontroller for RZ/A1 devices.
> >
> > I have updated the pin controller driver to use the newly introduced
> > "pinctrl_enable()" function.
> > This is required since v4.11-rc7 as otherwise, as reported by Chris Brandt,
> > the pin controller does not start.
> >
> > I have incorporated your comments on the device tree bindings documentation,
> > and added to pinctrl-generic.h header file two macros to unpack generic
> > properties and their arguments.
> >
> > Tested with SCIF, RIIC, ETHER and gpio-leds on Genmai board.
> 
> Thanks for the update!
> 
> > Jacopo Mondi (10):
> >   pinctrl: generic: Add bi-directional and output-enable
> 
> Already applied by LinusW.
> 
> >   pinctrl: generic: Add macros to unpack properties
> 
> LinusW: do you want me to queue this together with the driver for v4.13,
> or will you take this single patch for v4.12?
> 
> >   pinctrl: Renesas RZ/A1 pin and gpio controller
> >   dt-bindings: pinctrl: Add RZ/A1 bindings doc
> 
> Will queue in sh-pfc-for-v4.13.
> 
> >   arm: dts: dt-bindings: Add Renesas RZ/A1 pinctrl header
> >   arm: dts: r7s72100: Add pin controller node
> >   arm: dts: genmai: Add SCIF2 pin group
> >   arm: dts: genmai: Add RIIC2 pin group
> >   arm: dts: genmai: Add user led device nodes
> >   arm: dts: genmai: Add ethernet pin group
> 
> These are for Simon.
> 
> Does applying the DTS changes before the driver introduce regressions?
> If no, Simon can queue them for v4.13.
> If yes, they'll have to wait for v4.14.

That is my question too.

[toc] | [prev] | [next] | [standalone]

#1632579

Hi Geert, Simon,

On Thu, Apr 27, 2017 at 10:42:02AM +0200, Geert Uytterhoeven wrote:
> Hi Jacopo,
>
> On Thu, Apr 27, 2017 at 10:19 AM, Jacopo Mondi
> <jacopo+renesas@jmondi.org> wrote:
> >    this is 5th round of gpio/pincontroller for RZ/A1 devices.
> >
> > I have updated the pin controller driver to use the newly introduced
> > "pinctrl_enable()" function.
> > This is required since v4.11-rc7 as otherwise, as reported by Chris Brandt,
> > the pin controller does not start.
> >
> > I have incorporated your comments on the device tree bindings documentation,
> > and added to pinctrl-generic.h header file two macros to unpack generic
> > properties and their arguments.
> >
> > Tested with SCIF, RIIC, ETHER and gpio-leds on Genmai board.
>
> Thanks for the update!
>
> > Jacopo Mondi (10):
> >   pinctrl: generic: Add bi-directional and output-enable
>
> Already applied by LinusW.
>
> >   pinctrl: generic: Add macros to unpack properties
>
> LinusW: do you want me to queue this together with the driver for v4.13,
> or will you take this single patch for v4.12?
>
> >   pinctrl: Renesas RZ/A1 pin and gpio controller
> >   dt-bindings: pinctrl: Add RZ/A1 bindings doc
>
> Will queue in sh-pfc-for-v4.13.
>
> >   arm: dts: dt-bindings: Add Renesas RZ/A1 pinctrl header
> >   arm: dts: r7s72100: Add pin controller node
> >   arm: dts: genmai: Add SCIF2 pin group
> >   arm: dts: genmai: Add RIIC2 pin group
> >   arm: dts: genmai: Add user led device nodes
> >   arm: dts: genmai: Add ethernet pin group
>
> These are for Simon.
>
> Does applying the DTS changes before the driver introduce regressions?
> If no, Simon can queue them for v4.13.
> If yes, they'll have to wait for v4.14.
>

I tried reverting patch [03/10] which introduces the driver, and I
lose serial output on Genmai. So I guess the dts patches have to be
taken after the driver has been merged.

One question: why can't they be taken at the same time? (eg. for
v4.13?)

Thanks
   j

> Thanks!
>
> Gr{oetje,eeting}s,
>
>                         Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds

[toc] | [prev] | [next] | [standalone]

#1632584

On Fri, Apr 28, 2017 at 09:24:57AM +0200, jmondi wrote:
> Hi Geert, Simon,
> 
> On Thu, Apr 27, 2017 at 10:42:02AM +0200, Geert Uytterhoeven wrote:
> > Hi Jacopo,
> >
> > On Thu, Apr 27, 2017 at 10:19 AM, Jacopo Mondi
> > <jacopo+renesas@jmondi.org> wrote:
> > >    this is 5th round of gpio/pincontroller for RZ/A1 devices.
> > >
> > > I have updated the pin controller driver to use the newly introduced
> > > "pinctrl_enable()" function.
> > > This is required since v4.11-rc7 as otherwise, as reported by Chris Brandt,
> > > the pin controller does not start.
> > >
> > > I have incorporated your comments on the device tree bindings documentation,
> > > and added to pinctrl-generic.h header file two macros to unpack generic
> > > properties and their arguments.
> > >
> > > Tested with SCIF, RIIC, ETHER and gpio-leds on Genmai board.
> >
> > Thanks for the update!
> >
> > > Jacopo Mondi (10):
> > >   pinctrl: generic: Add bi-directional and output-enable
> >
> > Already applied by LinusW.
> >
> > >   pinctrl: generic: Add macros to unpack properties
> >
> > LinusW: do you want me to queue this together with the driver for v4.13,
> > or will you take this single patch for v4.12?
> >
> > >   pinctrl: Renesas RZ/A1 pin and gpio controller
> > >   dt-bindings: pinctrl: Add RZ/A1 bindings doc
> >
> > Will queue in sh-pfc-for-v4.13.
> >
> > >   arm: dts: dt-bindings: Add Renesas RZ/A1 pinctrl header
> > >   arm: dts: r7s72100: Add pin controller node
> > >   arm: dts: genmai: Add SCIF2 pin group
> > >   arm: dts: genmai: Add RIIC2 pin group
> > >   arm: dts: genmai: Add user led device nodes
> > >   arm: dts: genmai: Add ethernet pin group
> >
> > These are for Simon.
> >
> > Does applying the DTS changes before the driver introduce regressions?
> > If no, Simon can queue them for v4.13.
> > If yes, they'll have to wait for v4.14.
> >
> 
> I tried reverting patch [03/10] which introduces the driver, and I
> lose serial output on Genmai. So I guess the dts patches have to be
> taken after the driver has been merged.
> 
> One question: why can't they be taken at the same time? (eg. for
> v4.13?)

The problem is that the changes go through different trees. It may,
however, be possible to arrange for both sets of changes to go into v4.13
by negotiating with the ARM-SoC maintainers.

[toc] | [prev] | [next] | [standalone]

#1632585

Hi Jacopo,

On Fri, Apr 28, 2017 at 9:24 AM, jmondi <jacopo@jmondi.org> wrote:
> On Thu, Apr 27, 2017 at 10:42:02AM +0200, Geert Uytterhoeven wrote:
>> On Thu, Apr 27, 2017 at 10:19 AM, Jacopo Mondi
>> <jacopo+renesas@jmondi.org> wrote:
>> >    this is 5th round of gpio/pincontroller for RZ/A1 devices.
>> >
>> > I have updated the pin controller driver to use the newly introduced
>> > "pinctrl_enable()" function.
>> > This is required since v4.11-rc7 as otherwise, as reported by Chris Brandt,
>> > the pin controller does not start.
>> >
>> > I have incorporated your comments on the device tree bindings documentation,
>> > and added to pinctrl-generic.h header file two macros to unpack generic
>> > properties and their arguments.
>> >
>> > Tested with SCIF, RIIC, ETHER and gpio-leds on Genmai board.
>>
>> Thanks for the update!
>>
>> > Jacopo Mondi (10):
>> >   pinctrl: generic: Add bi-directional and output-enable
>>
>> Already applied by LinusW.
>>
>> >   pinctrl: generic: Add macros to unpack properties
>>
>> LinusW: do you want me to queue this together with the driver for v4.13,
>> or will you take this single patch for v4.12?
>>
>> >   pinctrl: Renesas RZ/A1 pin and gpio controller
>> >   dt-bindings: pinctrl: Add RZ/A1 bindings doc
>>
>> Will queue in sh-pfc-for-v4.13.
>>
>> >   arm: dts: dt-bindings: Add Renesas RZ/A1 pinctrl header
>> >   arm: dts: r7s72100: Add pin controller node
>> >   arm: dts: genmai: Add SCIF2 pin group
>> >   arm: dts: genmai: Add RIIC2 pin group
>> >   arm: dts: genmai: Add user led device nodes
>> >   arm: dts: genmai: Add ethernet pin group
>>
>> These are for Simon.
>>
>> Does applying the DTS changes before the driver introduce regressions?
>> If no, Simon can queue them for v4.13.
>> If yes, they'll have to wait for v4.14.
>>
>
> I tried reverting patch [03/10] which introduces the driver, and I
> lose serial output on Genmai. So I guess the dts patches have to be
> taken after the driver has been merged.
>
> One question: why can't they be taken at the same time? (eg. for
> v4.13?)

Because the driver goes in through me and LinusW, while the DTS goes in
through Simon and arm-soc.

If Simon applies the DTS patches, it will regress genmai in renesas-devel
until the release of v4.13-rc1.

An immutable branch would solve that, but for adding PFC we usuable just
postpone the DT part by one cycle.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | linux.kernel

csiph-web