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
                              Re: [PATCH v5 01/10] pinctrl: generic: Add bi-directional and output-enable Linus Walleij <linus.walleij@linaro.org> - 2017-05-12 11:10 +0200
                              Re: [PATCH v5 01/10] pinctrl: generic: Add bi-directional and output-enable Linus Walleij <linus.walleij@linaro.org> - 2017-05-12 11:10 +0200
                                Re: [PATCH v5 01/10] pinctrl: generic: Add bi-directional and output-enable Geert Uytterhoeven <geert@linux-m68k.org> - 2017-05-12 13:20 +0200
                                  RE: [PATCH v5 01/10] pinctrl: generic: Add bi-directional and  output-enable Chris Brandt <Chris.Brandt@renesas.com> - 2017-05-12 14:20 +0200
                                    Re: [PATCH v5 01/10] pinctrl: generic: Add bi-directional and output-enable Geert Uytterhoeven <geert@linux-m68k.org> - 2017-05-12 14:30 +0200
                                      RE: [PATCH v5 01/10] pinctrl: generic: Add bi-directional and  output-enable Chris Brandt <Chris.Brandt@renesas.com> - 2017-05-12 15:00 +0200
                                RE: [PATCH v5 01/10] pinctrl: generic: Add bi-directional and  output-enable Chris Brandt <Chris.Brandt@renesas.com> - 2017-05-12 13:50 +0200
                            Re: [PATCH v5 01/10] pinctrl: generic: Add bi-directional and output-enable Dong Aisheng <dongas86@gmail.com> - 2017-05-23 12:10 +0200
                              Re: [PATCH v5 01/10] pinctrl: generic: Add bi-directional and  output-enable jmondi <jacopo@jmondi.org> - 2017-05-23 20:40 +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 4 — ← Prev page 1 2 [3] 4  Next page →

#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]

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

On Tue, May 9, 2017 at 12:54 PM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:

> 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)?

If they are intrinsic to the function, i.e. whenever someone wants to use
that function they need to do this (nb the Documentation/pinctrl.txt
definition of "function", nothing else) then this should IMO not be in
the device tree at all, but hard-coded in the driver.

E.g. if someone needs to use a function such as "i2c0", on whatever
pins, then it should just be set up by the driver, no DT involved. It is a
hardware pecularity, drivers drive hardware so...

If however it depends on which pins it is used with, then it is pin
configuration and should use a DT property.

Yours,
Linus Walleij

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

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

On Tue, May 9, 2017 at 12:54 PM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:

Oops missed this:

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

I think it is better to have large tables in the driver in this case.

It is the lesser evil.

Having unintelligible and hard to grasp stuff in the device tree that
no user will understand or dare to touch is not good, then it is better
to have it with the code, where it is being used, so the developers of
the driver can see it when they are dealing with this (quirky) hardware.

As you say this is actually fixing hardware bugs, we can expect these
quirky tables to be gone in the next hardware generation, right?

Then the right place for it is in the quirky driver for the quirky
first-generation
hardware.

Yours,
Linus Walleij

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

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

Hi Linus,

On Fri, May 12, 2017 at 11:04 AM, Linus Walleij
<linus.walleij@linaro.org> wrote:
> On Tue, May 9, 2017 at 12:54 PM, Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
>
> Oops missed this:
>
>> 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.
>
> I think it is better to have large tables in the driver in this case.

Jacopo, Chris: Would two bits per pin/function (none, input, output, bidir)
be sufficient?
That makes one u16 per pin. So roughtly 12 ports x 16 pins => 384 bytes.
Plus code to handle it. After all not that bad...

> It is the lesser evil.
>
> Having unintelligible and hard to grasp stuff in the device tree that
> no user will understand or dare to touch is not good, then it is better
> to have it with the code, where it is being used, so the developers of
> the driver can see it when they are dealing with this (quirky) hardware.
>
> As you say this is actually fixing hardware bugs, we can expect these
> quirky tables to be gone in the next hardware generation, right?

Let's hope so. Chris has a better crystal ball than I have ;-)

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]

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

Hi Geert and Linus,

On Friday, May 12, 2017, Geert Uytterhoeven wrote:
> Jacopo, Chris: Would two bits per pin/function (none, input, output,
> bidir)
> be sufficient?
> That makes one u16 per pin. So roughtly 12 ports x 16 pins => 384 bytes.
> Plus code to handle it. After all not that bad...

OK...I give up!
If that's what it takes to get it, I'm fine.

NOTE, your math is a little off, the issue is that depending on the
function that you use, you might need to do extra settings, so you'd
have to have a lookup table for every pin & function.
Each pin can have 1 of 8 functions (which is good because a 'byte' has
8 bits).

So,
 12 ports x 16 pins => 384 bytes  (this table would just be for checking if bi-dir is needed)
 12 ports x 16 pins => 384 bytes  (this table would just be for checking if input is needed)
 12 ports x 16 pins => 384 bytes  (this table would just be for checking if input is needed)
                     ------------
                     1,152 bytes

But then...there are package variations so you need another entire
table for those parts.
   1,152 bytes x 2 = 2,304 bytes

However, if these tables are constants, they will reside in flash for the
XIP_KERNEL systems, so that's OK.

#What we should really do is just make a look-up table (tables) for the
'special' ones. But, we can have that discussion in a different thread.



One final note:

There is still a need for "input-enable" and "output-enable" for the timer
pins. Because, when you choose the pin to be connected to the MTU2 timer,
the pin can be used as either input-capture/output-compare/PWM and that's
the user's choice. So that's probably a valid usage of the generic pin
properties for configuration.


Sorry Jacopo, but we'll need another round of patches.
It sounds like for sure the bi-direction needs to get ripped back out.


Chris

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

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

Hi Chris,

On Fri, May 12, 2017 at 2:13 PM, Chris Brandt <Chris.Brandt@renesas.com> wrote:
> On Friday, May 12, 2017, Geert Uytterhoeven wrote:
>> Jacopo, Chris: Would two bits per pin/function (none, input, output,
>> bidir)
>> be sufficient?
>> That makes one u16 per pin. So roughtly 12 ports x 16 pins => 384 bytes.
>> Plus code to handle it. After all not that bad...
>
> OK...I give up!
> If that's what it takes to get it, I'm fine.
>
> NOTE, your math is a little off, the issue is that depending on the
> function that you use, you might need to do extra settings, so you'd
> have to have a lookup table for every pin & function.
> Each pin can have 1 of 8 functions (which is good because a 'byte' has
> 8 bits).
>
> So,
>  12 ports x 16 pins => 384 bytes  (this table would just be for checking if bi-dir is needed)
>  12 ports x 16 pins => 384 bytes  (this table would just be for checking if input is needed)
>  12 ports x 16 pins => 384 bytes  (this table would just be for checking if input is needed)
         ------------
>                      1,152 bytes

12 x 16 = 192, not 384.

Do you need all possible combinations of input, output, and bi-dir?
I assumed they're mutually exclusive. If not, you need 3 bits/pin/function.

> But then...there are package variations so you need another entire
> table for those parts.
>    1,152 bytes x 2 = 2,304 bytes

With packages, do you mean e.g. RZ/A1H vs. RZ/A1L? These indeed differ, but
should use different compatible values.
Or do you mean QFP/BGA256 vs. BGA324? Isn't the former a subset of the latter?

> #What we should really do is just make a look-up table (tables) for the
> 'special' ones. But, we can have that discussion in a different thread.

Yep, depending on what gives the smallest code/data size.

> There is still a need for "input-enable" and "output-enable" for the timer
> pins. Because, when you choose the pin to be connected to the MTU2 timer,
> the pin can be used as either input-capture/output-compare/PWM and that's
> the user's choice. So that's probably a valid usage of the generic pin
> properties for configuration.

OK.

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]

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

Hi Geert,

On Friday, May 12, 2017, Geert Uytterhoeven wrote:
> 12 x 16 = 192, not 384.

Opps, my math was off!

  (I think I need another cup of coffee this morning)


> Do you need all possible combinations of input, output, and bi-dir?
> I assumed they're mutually exclusive. If not, you need 3 bits/pin/function

You're right, they are mutually exclusive, so 2 bits are fine.

Also, the other pinout variations chips (RZ/A1L,A1LU,A1LC) only have 10 ports:

 12 ports x 16 pins x 2bits-per-bit => 384 bytes
 10 ports x 16 pins x 2bits-per-bit => 320 bytes

 384 + 320 = 704 bytes (of const data)


> With packages, do you mean e.g. RZ/A1H vs. RZ/A1L?

Yes.


> These indeed differ,
> but
> should use different compatible values.

OK. Since r7s72100.dtsi has
    compatible = "renesas,r7s72100-ports";

We'll just override that in say my-rza1l-board.dts

&pinctrl {
	compatible = "renesas,r7s72102-ports";
};
	
  and then look for that in the driver.
	

> Or do you mean QFP/BGA256 vs. BGA324? Isn't the former a subset of the
> latter?

The "package" doesn't matter, it's the pin assignments on the die:
  RZ/A1H = RZ/A1M = pin assignments #1
  RZ/A1L = RZ/A1LU = RZ/A1LC = pin assignments #2

Then each of those parts above have multiple 'package options', but of
course doesn't change the actual pin/function assignments (that's part
of the silicon die)

Chris

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

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

On Friday, May 12, 2017, linux-renesas-soc-owner@vger.kernel.org wrote:
> As you say this is actually fixing hardware bugs, we can expect these
> quirky tables to be gone in the next hardware generation, right?

I see this particular pin controller as a one shot deal. For the next
part in this series we are moving to a completely different controller
which you could probably get away with simply using pinctrl-single.


> Then the right place for it is in the quirky driver for the quirky
> first-generation
> hardware.

Maybe to be more clear, I would say the design is not a 'bug', but
rather an under sight of the original designers where are they stared
to need pins that would be both in and out, they started tacking on
more hardware.


Chris

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

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

On Tue, May 9, 2017 at 5:19 AM, 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)
>
> Etc.
>
>> Anyway, I still fail to see why those configuration flags, only
>> affecting the way the pin controller hardware enables/disables
>> its internal buffers and its internal operations have to be
>> described in term of their externally visible electrically characteristics.
>
> To me internal vs external is not what matters. What matters is
> if this is likely to pop up in more platforms, and then the property
> should be generic.
>
> The generic pin config definitions are likely to be picked up by other
> standards and even be inspiration to hardware engineers so that
> is why it matters so much.
>
>> To me, what already exists are pin configuration properties generic to
>> the whole pin controller subsystem, and I understand you don't want to
>> see duplication there.
>>
>> At the same time, to me, those flags are settings the pin controller
>> wants to have specified by software to overcome its hw design flaws,
>> and are intended to configure its internal buffers in a way it cannot
>> do by itself for some very specific operation modes (they are listed
>> in the hw reference manual, it's not something you can chose to
>> configure or not, if you want a pin working in i2c mode, you HAVE to
>> pass those flags to pin controller).
>
> Sounds like a case for
>
> renesas,bi-directional;
> renesas,output-enable;
>
> following the Qualcomm pattern in that case.
>
> But let's see if something else comes out of this discussion.
>

I did not follow too much.
But it seems IMX7ULP/Vybrid to be also a fan of generic
output-enable/input-enable
property.

See:
Figure 5-2. GPIO PAD in Page 241
http://www.nxp.com/assets/documents/data/en/reference-manuals/VFXXXRM.pdf

It has separate register bits to control input buffer enable and
output buffer enable
and we need set it property for GPIO function.

Regards
Dong Aisheng

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

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

Hi Linus,

On Tue, May 23, 2017 at 06:08:31PM +0800, Dong Aisheng wrote:
> On Tue, May 9, 2017 at 5:19 AM, 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)
> >
> > Etc.
> >
> >> Anyway, I still fail to see why those configuration flags, only
> >> affecting the way the pin controller hardware enables/disables
> >> its internal buffers and its internal operations have to be
> >> described in term of their externally visible electrically characteristics.
> >
> > To me internal vs external is not what matters. What matters is
> > if this is likely to pop up in more platforms, and then the property
> > should be generic.
> >
> > The generic pin config definitions are likely to be picked up by other
> > standards and even be inspiration to hardware engineers so that
> > is why it matters so much.
> >
> >> To me, what already exists are pin configuration properties generic to
> >> the whole pin controller subsystem, and I understand you don't want to
> >> see duplication there.
> >>
> >> At the same time, to me, those flags are settings the pin controller
> >> wants to have specified by software to overcome its hw design flaws,
> >> and are intended to configure its internal buffers in a way it cannot
> >> do by itself for some very specific operation modes (they are listed
> >> in the hw reference manual, it's not something you can chose to
> >> configure or not, if you want a pin working in i2c mode, you HAVE to
> >> pass those flags to pin controller).
> >
> > Sounds like a case for
> >
> > renesas,bi-directional;
> > renesas,output-enable;
> >
> > following the Qualcomm pattern in that case.
> >
> > But let's see if something else comes out of this discussion.
> >
>
> I did not follow too much.
> But it seems IMX7ULP/Vybrid to be also a fan of generic
> output-enable/input-enable
> property.
>
> See:
> Figure 5-2. GPIO PAD in Page 241
> http://www.nxp.com/assets/documents/data/en/reference-manuals/VFXXXRM.pdf
>
> It has separate register bits to control input buffer enable and
> output buffer enable
> and we need set it property for GPIO function.

As it seems we have another user for 'output-enable' here, what if we just
add that one to the generic bindings properties list, and we keep
'bi-directional' (which seems to be the most debated property we have
added) out of generic properties?

We can handle 'bi-directional' pins with static tables in our pin
controller driver and not have it anywhere in DT.

I see commit 42d5a11200d0[1] has not been reverted yet as Andy asked
in some previous email. I can send another version of that patch with
only 'output-enable' if you wish.

Once we reach consesus, I can then send v6 of our pin controller driver
based on that.

Thanks
   j

[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8c58f1a7a4b6d1d723bf25fef9d842d5a11200d0
>
> Regards
> Dong Aisheng

[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]

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

Back to top | Article view | linux.kernel

csiph-web