diff mbox

[v3,3/7] arm: dts: dt-bindings: Add Renesas RZ pinctrl header

Message ID 1490368934-12494-4-git-send-email-jacopo+renesas@jmondi.org
State New
Headers show

Commit Message

Jacopo Mondi March 24, 2017, 3:22 p.m. UTC 
Add dt-bindings for Renesas r7s72100 pin controller header file.

Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
---
 include/dt-bindings/pinctrl/r7s72100-pinctrl.h | 36 ++++++++++++++++++++++++++
 1 file changed, 36 insertions(+)
 create mode 100644 include/dt-bindings/pinctrl/r7s72100-pinctrl.h

Comments

Linus Walleij March 29, 2017, 1:22 p.m. UTC | #1 
On Fri, Mar 24, 2017 at 4:22 PM, Jacopo Mondi <jacopo+renesas@jmondi.org> wrote:

> Add dt-bindings for Renesas r7s72100 pin controller header file.
>
> Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>

> +/*
> + * Pin is bi-directional.
> + * An alternate function that needs both input/output functionalities shall
> + * be configured as bidirectional.
> + * Eg. SDA/SCL pins of an I2c interface.
> + */
> +#define BI_DIR                 (1 << 3)

Any specific reason why this should not simply be added to
include/linux/pinctrl/pinconf-generic.h
as PIN_CONFIG_BIDIRECTIONAL and parsed in
drivers/pinctrl/pinconf-generic.c
from the (new) DT property "bidirectional" simply?

> +/*
> + * Flags used to ask software to drive the pin I/O direction overriding the
> + * alternate function configuration.
> + * Some alternate functions require software to force I/O direction of a pin,
> + * overriding the designated one.
> + * Refer to the HW manual to know when this flag shall be used.
> + */
> +#define SWIO_IN                        (1 << 4)
> +#define SWIO_OUT               (1 << 5)

What is wrong in doing this with generic pin config using
PIN_CONFIG_INPUT_ENABLE and PIN_CONFIG_OUTPUT
(ignoring the argument)?

In the device tree use input-enable and add a new output-enable
(with unspecified value) with proper description and DT bindings?

And if you think these have no general applicability, by the end
of the day they are *still* pin config, not magic flags we can choose to
toss in with the muxing, so you can do what the Qualcomm driver
does and add custom pin configurations extending the generic
pin config, see drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
qcom,pull-up-strength etc.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Chris Brandt March 29, 2017, 2:55 p.m. UTC | #2 
On Wednesday, March 29, 2017, Linus Walleij wrote:
> On Fri, Mar 24, 2017 at 4:22 PM, Jacopo Mondi <jacopo+renesas@jmondi.org>

> wrote:

> 

> > Add dt-bindings for Renesas r7s72100 pin controller header file.

> >

> > Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>

> 

> > +/*

> > + * Pin is bi-directional.

> > + * An alternate function that needs both input/output functionalities

> > +shall

> > + * be configured as bidirectional.

> > + * Eg. SDA/SCL pins of an I2c interface.

> > + */

> > +#define BI_DIR                 (1 << 3)

> 

> Any specific reason why this should not simply be added to

> include/linux/pinctrl/pinconf-generic.h

> as PIN_CONFIG_BIDIRECTIONAL and parsed in drivers/pinctrl/pinconf-

> generic.c from the (new) DT property "bidirectional" simply?


I see your point. It would cut down from every driver out there
inventing some new property or config instead of everyone just sharing
a fixed set.
Maybe someone else out there will end up having a need for a
"bidirectional" option.


> > +/*

> > + * Flags used to ask software to drive the pin I/O direction

> > +overriding the

> > + * alternate function configuration.

> > + * Some alternate functions require software to force I/O direction

> > +of a pin,

> > + * overriding the designated one.

> > + * Refer to the HW manual to know when this flag shall be used.

> > + */

> > +#define SWIO_IN                        (1 << 4)

> > +#define SWIO_OUT               (1 << 5)

> 

> What is wrong in doing this with generic pin config using

> PIN_CONFIG_INPUT_ENABLE and PIN_CONFIG_OUTPUT (ignoring the argument)?

> 

> In the device tree use input-enable and add a new output-enable (with

> unspecified value) with proper description and DT bindings?


Again, that's probably fine. It seems we are still doing the same thing
which is using the DT to pass extra config information to the driver.
And, we can do whatever we want with that info.


> And if you think these have no general applicability, by the end of the

> day they are *still* pin config, not magic flags we can choose to toss in

> with the muxing, so you can do what the Qualcomm driver does and add

> custom pin configurations extending the generic pin config, see

> drivers/pinctrl/qcom/pinctrl-spmi-gpio.c

> qcom,pull-up-strength etc.


But, it seems that when you set a config option, it applies to everything
in "pins"?

I2C Example: (seem OK)
	/* P1_6 = RIIC3SCL (bi dir) */
	/* P1_7 = RIIC3SDA (bi dir) */
	i2c3_pins: i2c3 {
		pins = <PIN(1, 6) | FUNC_1>,
		       <PIN(1, 7) | FUNC_1>;
		bidirectional;
	};


But, what do we do for Ethernet? All the pins are "normal" except just
the MDIO pin needs to be bidirectional.
That's the part I'm confused by.
How do we flag that just the ET_MDIO needs "bidirectional"?

	/* Ethernet */
	ether_pins: ether {
		/* Ethernet on Ports 1,2,3,5 */
		pins = <PIN(1, 14) | FUNC_4)>, /* P1_14 = ET_COL */
			<PIN(5, 9) | FUNC_2)>,	/* P5_9 = ET_MDC */
			<PIN(3, 3) | FUNC_2)>,	/* P3_3 = ET_MDIO !!!! (bi dir) !!!!!! */
			<PIN(3, 4) | FUNC_2)>,	/* P3_4 = ET_RXCLK */
			<PIN(3, 5) | FUNC_2)>,	/* P3_5 = ET_RXER */
			<PIN(3, 6) | FUNC_2)>,	/* P3_6 = ET_RXDV */
			<PIN(2, 0) | FUNC_2)>,	/* P2_0 = ET_TXCLK */
			<PIN(2, 1) | FUNC_2)>,	/* P2_1 = ET_TXER */
			<PIN(2, 2) | FUNC_2)>,	/* P2_2 = ET_TXEN */
			<PIN(2, 3) | FUNC_2)>,	/* P2_3 = ET_CRS */
			<PIN(2, 4) | FUNC_2)>,	/* P2_4 = ET_TXD0 */
			<PIN(2, 5) | FUNC_2)>,	/* P2_5 = ET_TXD1 */
			<PIN(2, 6) | FUNC_2)>,	/* P2_6 = ET_TXD2 */
			<PIN(2, 7) | FUNC_2)>,	/* P2_7 = ET_TXD3 */
			<PIN(2, 8) | FUNC_2)>,	/* P2_8 = ET_RXD0 */
			<PIN(2, 9) | FUNC_2)>,	/* P2_9 = ET_RXD1 */
			<PIN(2, 10) | FUNC_2)>, /* P2_10 = ET_RXD2 */
			<PIN(2, 11) | FUNC_2)>; /* P2_11 = ET_RXD3 */
	};


Chris
Geert Uytterhoeven March 29, 2017, 2:59 p.m. UTC | #3 
Hi Chris,

On Wed, Mar 29, 2017 at 4:55 PM, Chris Brandt <Chris.Brandt@renesas.com> wrote:
> On Wednesday, March 29, 2017, Linus Walleij wrote:
>> On Fri, Mar 24, 2017 at 4:22 PM, Jacopo Mondi <jacopo+renesas@jmondi.org> wrote:
>> > +/*
>> > + * Flags used to ask software to drive the pin I/O direction
>> > +overriding the
>> > + * alternate function configuration.
>> > + * Some alternate functions require software to force I/O direction
>> > +of a pin,
>> > + * overriding the designated one.
>> > + * Refer to the HW manual to know when this flag shall be used.
>> > + */
>> > +#define SWIO_IN                        (1 << 4)
>> > +#define SWIO_OUT               (1 << 5)
>>
>> What is wrong in doing this with generic pin config using
>> PIN_CONFIG_INPUT_ENABLE and PIN_CONFIG_OUTPUT (ignoring the argument)?
>>
>> In the device tree use input-enable and add a new output-enable (with
>> unspecified value) with proper description and DT bindings?
>
> Again, that's probably fine. It seems we are still doing the same thing
> which is using the DT to pass extra config information to the driver.
> And, we can do whatever we want with that info.
>
>
>> And if you think these have no general applicability, by the end of the
>> day they are *still* pin config, not magic flags we can choose to toss in
>> with the muxing, so you can do what the Qualcomm driver does and add
>> custom pin configurations extending the generic pin config, see
>> drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
>> qcom,pull-up-strength etc.
>
> But, it seems that when you set a config option, it applies to everything
> in "pins"?
>
> I2C Example: (seem OK)
>         /* P1_6 = RIIC3SCL (bi dir) */
>         /* P1_7 = RIIC3SDA (bi dir) */
>         i2c3_pins: i2c3 {
>                 pins = <PIN(1, 6) | FUNC_1>,
>                        <PIN(1, 7) | FUNC_1>;
>                 bidirectional;
>         };

Correct.

> But, what do we do for Ethernet? All the pins are "normal" except just
> the MDIO pin needs to be bidirectional.
> That's the part I'm confused by.
> How do we flag that just the ET_MDIO needs "bidirectional"?

You add subnodes, cfr. arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts:

        avb_pins: avb {
                mux {
                        groups = "avb_link", "avb_phy_int", "avb_mdc",
                                 "avb_mii";
                        function = "avb";
                };

                pins_mdc {
                        groups = "avb_mdc";
                        drive-strength = <24>;
                };

                pins_mii_tx {
                        pins = "PIN_AVB_TX_CTL", "PIN_AVB_TXC", "PIN_AVB_TD0",
                               "PIN_AVB_TD1", "PIN_AVB_TD2", "PIN_AVB_TD3";
                        drive-strength = <12>;
                };
        };

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
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Chris Brandt March 29, 2017, 3:18 p.m. UTC | #4 
Hi Geert,

On Wednesday, March 29, 2017, Geert Uytterhoeven wrote:
> > But, what do we do for Ethernet? All the pins are "normal" except just

> > the MDIO pin needs to be bidirectional.

> > That's the part I'm confused by.

> > How do we flag that just the ET_MDIO needs "bidirectional"?

> 

> You add subnodes, cfr. arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts:

> 

>         avb_pins: avb {

>                 mux {

>                         groups = "avb_link", "avb_phy_int", "avb_mdc",

>                                  "avb_mii";

>                         function = "avb";

>                 };

> 

>                 pins_mdc {

>                         groups = "avb_mdc";

>                         drive-strength = <24>;

>                 };

> 

>                 pins_mii_tx {

>                         pins = "PIN_AVB_TX_CTL", "PIN_AVB_TXC",

> "PIN_AVB_TD0",

>                                "PIN_AVB_TD1", "PIN_AVB_TD2",

> "PIN_AVB_TD3";

>                         drive-strength = <12>;

>                 };

>         };


Oh, so there is a way!

Thank you.


So, for clarity:

	/* Ethernet */
	ether_pins: ether {
		/* Ethernet on Ports 1,2,3,5 */
		mux {
			pins = <PIN(1, 14) | FUNC_4)>, /* P1_14 = ET_COL */
				<PIN(5, 9) | FUNC_2)>,	/* P5_9 = ET_MDC */
				<PIN(3, 4) | FUNC_2)>,	/* P3_4 = ET_RXCLK */
				<PIN(3, 5) | FUNC_2)>,	/* P3_5 = ET_RXER */
				<PIN(3, 6) | FUNC_2)>,	/* P3_6 = ET_RXDV */
				<PIN(2, 0) | FUNC_2)>,	/* P2_0 = ET_TXCLK */
				<PIN(2, 1) | FUNC_2)>,	/* P2_1 = ET_TXER */
				<PIN(2, 2) | FUNC_2)>,	/* P2_2 = ET_TXEN */
				<PIN(2, 3) | FUNC_2)>,	/* P2_3 = ET_CRS */
				<PIN(2, 4) | FUNC_2)>,	/* P2_4 = ET_TXD0 */
				<PIN(2, 5) | FUNC_2)>,	/* P2_5 = ET_TXD1 */
				<PIN(2, 6) | FUNC_2)>,	/* P2_6 = ET_TXD2 */
				<PIN(2, 7) | FUNC_2)>,	/* P2_7 = ET_TXD3 */
				<PIN(2, 8) | FUNC_2)>,	/* P2_8 = ET_RXD0 */
				<PIN(2, 9) | FUNC_2)>,	/* P2_9 = ET_RXD1 */
				<PIN(2, 10) | FUNC_2)>, /* P2_10 = ET_RXD2 */
				<PIN(2, 11) | FUNC_2)>; /* P2_11 = ET_RXD3 */
		};
		pins_bidir {
			pins = <PIN(3, 3) | FUNC_2)>,	/* P3_3 = ET_MDIO */
			bidirectional;
		};
	};



Chris
Chris Brandt March 29, 2017, 3:39 p.m. UTC | #5 
T24gV2VkbmVzZGF5LCBNYXJjaCAyOSwgMjAxNywgQ2hyaXMgQnJhbmR0IHdyb3RlOg0KPiBPbiBX
ZWRuZXNkYXksIE1hcmNoIDI5LCAyMDE3LCBHZWVydCBVeXR0ZXJob2V2ZW4gd3JvdGU6DQo+ID4g
PiBCdXQsIHdoYXQgZG8gd2UgZG8gZm9yIEV0aGVybmV0PyBBbGwgdGhlIHBpbnMgYXJlICJub3Jt
YWwiIGV4Y2VwdA0KPiA+ID4ganVzdCB0aGUgTURJTyBwaW4gbmVlZHMgdG8gYmUgYmlkaXJlY3Rp
b25hbC4NCj4gPiA+IFRoYXQncyB0aGUgcGFydCBJJ20gY29uZnVzZWQgYnkuDQo+ID4gPiBIb3cg
ZG8gd2UgZmxhZyB0aGF0IGp1c3QgdGhlIEVUX01ESU8gbmVlZHMgImJpZGlyZWN0aW9uYWwiPw0K
PiA+DQo+ID4gWW91IGFkZCBzdWJub2RlcywgY2ZyLiBhcmNoL2FybTY0L2Jvb3QvZHRzL3JlbmVz
YXMvcjhhNzc5NS1zYWx2YXRvci0NCj4geC5kdHM6DQo+ID4NCj4gPiAgICAgICAgIGF2Yl9waW5z
OiBhdmIgew0KPiA+ICAgICAgICAgICAgICAgICBtdXggew0KPiA+ICAgICAgICAgICAgICAgICAg
ICAgICAgIGdyb3VwcyA9ICJhdmJfbGluayIsICJhdmJfcGh5X2ludCIsICJhdmJfbWRjIiwNCj4g
PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAiYXZiX21paSI7DQo+ID4gICAgICAg
ICAgICAgICAgICAgICAgICAgZnVuY3Rpb24gPSAiYXZiIjsNCj4gPiAgICAgICAgICAgICAgICAg
fTsNCj4gPg0KPiA+ICAgICAgICAgICAgICAgICBwaW5zX21kYyB7DQo+ID4gICAgICAgICAgICAg
ICAgICAgICAgICAgZ3JvdXBzID0gImF2Yl9tZGMiOw0KPiA+ICAgICAgICAgICAgICAgICAgICAg
ICAgIGRyaXZlLXN0cmVuZ3RoID0gPDI0PjsNCj4gPiAgICAgICAgICAgICAgICAgfTsNCj4gPg0K
PiA+ICAgICAgICAgICAgICAgICBwaW5zX21paV90eCB7DQo+ID4gICAgICAgICAgICAgICAgICAg
ICAgICAgcGlucyA9ICJQSU5fQVZCX1RYX0NUTCIsICJQSU5fQVZCX1RYQyIsDQo+ID4gIlBJTl9B
VkJfVEQwIiwNCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIlBJTl9BVkJfVEQx
IiwgIlBJTl9BVkJfVEQyIiwNCj4gPiAiUElOX0FWQl9URDMiOw0KPiA+ICAgICAgICAgICAgICAg
ICAgICAgICAgIGRyaXZlLXN0cmVuZ3RoID0gPDEyPjsNCj4gPiAgICAgICAgICAgICAgICAgfTsN
Cj4gPiAgICAgICAgIH07DQo+IA0KPiBPaCwgc28gdGhlcmUgaXMgYSB3YXkhDQo+IA0KPiBUaGFu
ayB5b3UuDQo+IA0KPiANCj4gU28sIGZvciBjbGFyaXR5Og0KDQoNCkFjdHVhbGx5LCBMaW51cydz
IHJlcXVlc3Qgd2FzIHRvIHVzZSAicGlubXV4Iiwgbm90ICJwaW5zIi4NCg0KU28sIGl0IHNob3Vs
ZCBiZToNCg0KCS8qIFAxXzYgPSBSSUlDM1NDTCAoYmkgZGlyKSAqLw0KCS8qIFAxXzcgPSBSSUlD
M1NEQSAoYmkgZGlyKSAqLw0KCWkyYzNfcGluczogaTJjMyB7DQoJCXBpbm11eCA9IDxQSU4oMSwg
NikgfCBGVU5DXzE+LA0KCQkgICAgICAgICA8UElOKDEsIDcpIHwgRlVOQ18xPjsNCgkJYmlkaXJl
Y3Rpb25hbDsNCgl9Ow0KDQogDQoJLyogRXRoZXJuZXQgKi8NCglldGhlcl9waW5zOiBldGhlciB7
DQoJCS8qIEV0aGVybmV0IG9uIFBvcnRzIDEsMiwzLDUgKi8NCgkJbXV4IHsNCgkJCXBpbm11eCA9
IDxQSU4oMSwgMTQpIHwgRlVOQ180KT4sIC8qIFAxXzE0ID0gRVRfQ09MICovDQoJCQkJPFBJTig1
LCA5KSB8IEZVTkNfMik+LAkvKiBQNV85ID0gRVRfTURDICovDQoJCQkJPFBJTigzLCA0KSB8IEZV
TkNfMik+LAkvKiBQM180ID0gRVRfUlhDTEsgKi8NCgkJCQk8UElOKDMsIDUpIHwgRlVOQ18yKT4s
CS8qIFAzXzUgPSBFVF9SWEVSICovDQoJCQkJPFBJTigzLCA2KSB8IEZVTkNfMik+LAkvKiBQM182
ID0gRVRfUlhEViAqLw0KCQkJCTxQSU4oMiwgMCkgfCBGVU5DXzIpPiwJLyogUDJfMCA9IEVUX1RY
Q0xLICovDQoJCQkJPFBJTigyLCAxKSB8IEZVTkNfMik+LAkvKiBQMl8xID0gRVRfVFhFUiAqLw0K
CQkJCTxQSU4oMiwgMikgfCBGVU5DXzIpPiwJLyogUDJfMiA9IEVUX1RYRU4gKi8NCgkJCQk8UElO
KDIsIDMpIHwgRlVOQ18yKT4sCS8qIFAyXzMgPSBFVF9DUlMgKi8NCgkJCQk8UElOKDIsIDQpIHwg
RlVOQ18yKT4sCS8qIFAyXzQgPSBFVF9UWEQwICovDQoJCQkJPFBJTigyLCA1KSB8IEZVTkNfMik+
LAkvKiBQMl81ID0gRVRfVFhEMSAqLw0KCQkJCTxQSU4oMiwgNikgfCBGVU5DXzIpPiwJLyogUDJf
NiA9IEVUX1RYRDIgKi8NCgkJCQk8UElOKDIsIDcpIHwgRlVOQ18yKT4sCS8qIFAyXzcgPSBFVF9U
WEQzICovDQoJCQkJPFBJTigyLCA4KSB8IEZVTkNfMik+LAkvKiBQMl84ID0gRVRfUlhEMCAqLw0K
CQkJCTxQSU4oMiwgOSkgfCBGVU5DXzIpPiwJLyogUDJfOSA9IEVUX1JYRDEgKi8NCgkJCQk8UElO
KDIsIDEwKSB8IEZVTkNfMik+LCAvKiBQMl8xMCA9IEVUX1JYRDIgKi8NCgkJCQk8UElOKDIsIDEx
KSB8IEZVTkNfMik+OyAvKiBQMl8xMSA9IEVUX1JYRDMgKi8NCgkJfTsNCgkJcGluc19iaWRpciB7
DQoJCQlwaW5tdXggPSA8UElOKDMsIDMpIHwgRlVOQ18yKT4sCS8qIFAzXzMgPSBFVF9NRElPICov
DQoJCQliaWRpcmVjdGlvbmFsOw0KCQl9Ow0KCX07DQoNCg0KICBOT1RFOiAiRlVOQ18yIiBjYW4g
anVzdCBiZSAiMiIgYXMgcGVyIEdlZXJ0J3MgcmVxdWVzdC4NCg0KDQoNCkNocmlzDQoNCg0K
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Jacopo Mondi March 29, 2017, 3:56 p.m. UTC | #6 
Hi Linus,
    another reply to your email, please don't feel assaulted :)

On Wed, Mar 29, 2017 at 03:22:23PM +0200, Linus Walleij wrote:
> On Fri, Mar 24, 2017 at 4:22 PM, Jacopo Mondi <jacopo+renesas@jmondi.org> wrote:
> 
> > Add dt-bindings for Renesas r7s72100 pin controller header file.
> >
> > Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
> 
> > +/*
> > + * Pin is bi-directional.
> > + * An alternate function that needs both input/output functionalities shall
> > + * be configured as bidirectional.
> > + * Eg. SDA/SCL pins of an I2c interface.
> > + */
> > +#define BI_DIR                 (1 << 3)
> 
> Any specific reason why this should not simply be added to
> include/linux/pinctrl/pinconf-generic.h
> as PIN_CONFIG_BIDIRECTIONAL and parsed in
> drivers/pinctrl/pinconf-generic.c
> from the (new) DT property "bidirectional" simply?
> 

I can try to give you a few reasons why I don't see those flags fit in
the pin configuration flags definition.

*) those flags are used during pin multiplexing procedure only and that
procedure has a specific order to be respected:

You can have a look here:
https://www.spinics.net/lists/linux-renesas-soc/msg12793.html
In "rza1_alternate_function_conf()" function, we need to set bidir
before setting every other register.
The same applies some lines below:, the PIPC, PMC and PM register set order
has to be respected, and depends on those BIDIR and SWIO_* parameters.
This implies those configuration cannot be applied after pin muxing,
certainly not in pin_config[_group]_set() whose invocation time
is independent from pin_mux_set()'s one.

One way forward would be, every time we mux a pin, look for a pinconf group
that includes the pin we're muxing. That would happen for each pin,
for no added benefits imo.

*) as Geert already pointed out, we may need dedicated subnodes to
specify those pin configuration flags, not only because of what Chris
said, but because pinconf_generic_dt_subnode_to_map() wants "pins" or
"groups" to be there in the subnode, and in our pin multiplexing
sub-nodes we only have "pinmux" property (say: we cannot specify
pin_conf flags in the same sub-node where we describe pin
multiplexing, we always need a dedicated sub-node).
Chris and Geert gave some examples in their replies on how that would
like, and how it makes the bindings a little more complex.

*) those flags, according to Chris, won't be used in RZ/A2, and
reasonably not in any other RZ device. Do we want to add them to the
generic bindings, being them so specific to this hardware platform?

One thing I suggest considering is to get rid of those flags, at
least in bindings, and introduce 3 variants for each pin multiplexing
function identifier.

Say:
include/dt-bindings/pinctrl/r7s72100-pinctrl.h:
#define MUX_1               (1 << 16)
#define MUX_1_BIDIR         (1 << 16 | 1 << 24)
#define MUX_1_SWIO_IN       (1 << 16 | 2 << 24)
#define MUX_1_SWIO_OUT      (1 << 16 | 3 << 24)
...
#define MUX_8               (8 << 16)
#define MUX_8_BIDIR         (8 << 16 | 1 << 24)
....

this way we get rid of those extra flag values and squeeze pin id
and mux function id in a single integer, part of the "pinmux"
arguments list.

i2c_pins {
    pinmux = <(PIN(1, 6) | MUX_1_BIDIR)>,
             <(PIN(1, 7) | MUX_2_BIDIR)>;
};

The driver will parse the bits from [31:24] to find out if it needs
to enable some special multiplexing property, and performs
multiplexing as it is doing right now.

> > +/*
> > + * Flags used to ask software to drive the pin I/O direction overriding the
> > + * alternate function configuration.
> > + * Some alternate functions require software to force I/O direction of a pin,
> > + * overriding the designated one.
> > + * Refer to the HW manual to know when this flag shall be used.
> > + */
> > +#define SWIO_IN                        (1 << 4)
> > +#define SWIO_OUT               (1 << 5)
> 
> What is wrong in doing this with generic pin config using
> PIN_CONFIG_INPUT_ENABLE and PIN_CONFIG_OUTPUT
> (ignoring the argument)?
> 
> In the device tree use input-enable and add a new output-enable
> (with unspecified value) with proper description and DT bindings?
> 
> And if you think these have no general applicability, by the end
> of the day they are *still* pin config, not magic flags we can choose to
> toss in with the muxing, so you can do what the Qualcomm driver
> does and add custom pin configurations extending the generic
> pin config, see drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
> qcom,pull-up-strength etc.
> 

I see, but that custom pin configuration flag can be applied
independently from pin muxing procedure and it can be applied to pins
while they're configured in GPIO mode.
Our "flags" are not of that nature, and only apply to some register
setting during pinmux, as I hopefully tried to clarify above.

Thanks for time and patience in this long email thread.
    j

> Yours,
> Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Linus Walleij March 30, 2017, 8:15 a.m. UTC | #7 
On Wed, Mar 29, 2017 at 4:55 PM, Chris Brandt <Chris.Brandt@renesas.com> wrote:
> On Wednesday, March 29, 2017, Linus Walleij wrote:
>> On Fri, Mar 24, 2017 at 4:22 PM, Jacopo Mondi <jacopo+renesas@jmondi.org>
>> wrote:
>>
>> > Add dt-bindings for Renesas r7s72100 pin controller header file.
>> >
>> > Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
>>
>> > +/*
>> > + * Pin is bi-directional.
>> > + * An alternate function that needs both input/output functionalities
>> > +shall
>> > + * be configured as bidirectional.
>> > + * Eg. SDA/SCL pins of an I2c interface.
>> > + */
>> > +#define BI_DIR                 (1 << 3)
>>
>> Any specific reason why this should not simply be added to
>> include/linux/pinctrl/pinconf-generic.h
>> as PIN_CONFIG_BIDIRECTIONAL and parsed in drivers/pinctrl/pinconf-
>> generic.c from the (new) DT property "bidirectional" simply?
>
> I see your point. It would cut down from every driver out there
> inventing some new property or config instead of everyone just sharing
> a fixed set.
> Maybe someone else out there will end up having a need for a
> "bidirectional" option.

I was thinking about that one. It is a bit weird electrically, like what
kind of electronics is really bidirectional?

It seems like a fancy name for open drain/open source, what we
call "single ended" configuration. (See docs in
Documentation/gpio/driver.txt)

It would be great if you could check if that is what they mean,
actually.

> But, what do we do for Ethernet? All the pins are "normal" except just
> the MDIO pin needs to be bidirectional.

I see Geert clarified what we could do here.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Linus Walleij March 30, 2017, 8:33 a.m. UTC | #8 
On Wed, Mar 29, 2017 at 5:56 PM, jacopo <jacopo@jmondi.org> wrote:

> I can try to give you a few reasons why I don't see those flags fit in
> the pin configuration flags definition.
>
> *) those flags are used during pin multiplexing procedure only and that
> procedure has a specific order to be respected:
>
> You can have a look here:
> https://www.spinics.net/lists/linux-renesas-soc/msg12793.html
> In "rza1_alternate_function_conf()" function, we need to set bidir
> before setting every other register.
> The same applies some lines below:, the PIPC, PMC and PM register set order
> has to be respected, and depends on those BIDIR and SWIO_* parameters.
> This implies those configuration cannot be applied after pin muxing,
> certainly not in pin_config[_group]_set() whose invocation time
> is independent from pin_mux_set()'s one.

But now you are mixing up syntax and semantics.

You are describing what steps are necessary on this hardware to
apply a certain setting. That is fine, if you didn't need any specific
semantics there, you could be using pinctrl-single which will just
hammer stuff into registers, one register per pin. You have a pin
controller driver exactly beacause your hardware has semantics.

How this is described in the device tree or a board file is a different
thing from how you write your driver.

I understand why i makes for easier code, but does it make for more
generic and understandable device trees for people maintaining
several systems? I don't think so.

> One way forward would be, every time we mux a pin, look for a pinconf group
> that includes the pin we're muxing. That would happen for each pin,
> for no added benefits imo.

The benefit is clearly abstraction, standardization and readability of the
device tree. I, as developer, understand what is going on electrically,
having seen this on other systems, and being able to access generic
documentation on generic pin config properties.

> *) as Geert already pointed out, we may need dedicated subnodes to
> specify those pin configuration flags, not only because of what Chris
> said, but because pinconf_generic_dt_subnode_to_map() wants "pins" or
> "groups" to be there in the subnode, and in our pin multiplexing
> sub-nodes we only have "pinmux" property (say: we cannot specify
> pin_conf flags in the same sub-node where we describe pin
> multiplexing, we always need a dedicated sub-node).
> Chris and Geert gave some examples in their replies on how that would
> like, and how it makes the bindings a little more complex.

Very little more complex, and actually it could be argued that this
is exactly why subnodes exist: to be able to have different pin config
on pins. I think it is very readable.

> *) those flags, according to Chris, won't be used in RZ/A2, and
> reasonably not in any other RZ device. Do we want to add them to the
> generic bindings, being them so specific to this hardware platform?

I have seen so much stuff that people say is "necessarily different"
for their platform. It turns our that silicon IO and solid state physics
isn't that much different between systems. The same things invariably
pop up in several chips.

Hell this was what people said about this whole subsystem from the
beginning: pin control is so necessarily different that there is no point
in trying to create an abstraction for it.

If I had listened to that kind of advice we wouldn't be where we are today.

And that said, I have already pointed out that two of them already
exist in the pin control subsystem (PIN_CONFIG*). Because other SoCs
are doing similar things.

> One thing I suggest considering is to get rid of those flags, at
> least in bindings, and introduce 3 variants for each pin multiplexing
> function identifier.
>
> Say:
> include/dt-bindings/pinctrl/r7s72100-pinctrl.h:
> #define MUX_1               (1 << 16)
> #define MUX_1_BIDIR         (1 << 16 | 1 << 24)
> #define MUX_1_SWIO_IN       (1 << 16 | 2 << 24)
> #define MUX_1_SWIO_OUT      (1 << 16 | 3 << 24)
> ...
> #define MUX_8               (8 << 16)
> #define MUX_8_BIDIR         (8 << 16 | 1 << 24)
> ....

I understand they can be made more beautiful, but in my view
that is putting make up on a pig, I want generic pin config for these
things.


>> What is wrong in doing this with generic pin config using
>> PIN_CONFIG_INPUT_ENABLE and PIN_CONFIG_OUTPUT
>> (ignoring the argument)?
>>
>> In the device tree use input-enable and add a new output-enable
>> (with unspecified value) with proper description and DT bindings?
>>
>> And if you think these have no general applicability, by the end
>> of the day they are *still* pin config, not magic flags we can choose to
>> toss in with the muxing, so you can do what the Qualcomm driver
>> does and add custom pin configurations extending the generic
>> pin config, see drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
>> qcom,pull-up-strength etc.
>>
>
> I see, but that custom pin configuration flag can be applied
> independently from pin muxing procedure and it can be applied to pins
> while they're configured in GPIO mode.

See "GPIO mode pitfalls" in Documentation/pinctrl.txt
I've been over this hardware lingo so many times already.

It is not about "GPIO" at all, it is about pin configuration. The
generic pin config was not invented for GPIO, it was just recently
that we started to provide pin config back-ends for GPIO. Only
Intel do that so far.

> Our "flags" are not of that nature, and only apply to some register
> setting during pinmux, as I hopefully tried to clarify above.

And that is a driver semantic. Or even a subsystem semantic. No
big deal, accumulate such writes in the driver and apply it all when you have
it all available no matter if pin multiplexing or pin config happens first?
Surely this is just a hardware pecularity, then it warrants some special
driver code.

If you definately feel you must get a call from the pin control core setting
up muxing and config at the same time we need to think of a way to
augment the pin control core if necessary?

The fact that Linux pin control subsystem semantics you don't
like does not affect the relevant device tree bindings.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Chris Brandt March 30, 2017, 1:27 p.m. UTC | #9 
T24gVGh1cnNkYXksIE1hcmNoIDMwLCAyMDE3LCBMaW51cyBXYWxsZWlqIHdyb3RlOg0KPiA+PiA+
ICsvKg0KPiA+PiA+ICsgKiBQaW4gaXMgYmktZGlyZWN0aW9uYWwuDQo+ID4+ID4gKyAqIEFuIGFs
dGVybmF0ZSBmdW5jdGlvbiB0aGF0IG5lZWRzIGJvdGggaW5wdXQvb3V0cHV0DQo+ID4+ID4gK2Z1
bmN0aW9uYWxpdGllcyBzaGFsbA0KPiA+PiA+ICsgKiBiZSBjb25maWd1cmVkIGFzIGJpZGlyZWN0
aW9uYWwuDQo+ID4+ID4gKyAqIEVnLiBTREEvU0NMIHBpbnMgb2YgYW4gSTJjIGludGVyZmFjZS4N
Cj4gPj4gPiArICovDQo+ID4+ID4gKyNkZWZpbmUgQklfRElSICAgICAgICAgICAgICAgICAoMSA8
PCAzKQ0KPiA+Pg0KPiA+PiBBbnkgc3BlY2lmaWMgcmVhc29uIHdoeSB0aGlzIHNob3VsZCBub3Qg
c2ltcGx5IGJlIGFkZGVkIHRvDQo+ID4+IGluY2x1ZGUvbGludXgvcGluY3RybC9waW5jb25mLWdl
bmVyaWMuaA0KPiA+PiBhcyBQSU5fQ09ORklHX0JJRElSRUNUSU9OQUwgYW5kIHBhcnNlZCBpbiBk
cml2ZXJzL3BpbmN0cmwvcGluY29uZi0NCj4gPj4gZ2VuZXJpYy5jIGZyb20gdGhlIChuZXcpIERU
IHByb3BlcnR5ICJiaWRpcmVjdGlvbmFsIiBzaW1wbHk/DQo+ID4NCj4gPiBJIHNlZSB5b3VyIHBv
aW50LiBJdCB3b3VsZCBjdXQgZG93biBmcm9tIGV2ZXJ5IGRyaXZlciBvdXQgdGhlcmUNCj4gPiBp
bnZlbnRpbmcgc29tZSBuZXcgcHJvcGVydHkgb3IgY29uZmlnIGluc3RlYWQgb2YgZXZlcnlvbmUg
anVzdCBzaGFyaW5nDQo+ID4gYSBmaXhlZCBzZXQuDQo+ID4gTWF5YmUgc29tZW9uZSBlbHNlIG91
dCB0aGVyZSB3aWxsIGVuZCB1cCBoYXZpbmcgYSBuZWVkIGZvciBhDQo+ID4gImJpZGlyZWN0aW9u
YWwiIG9wdGlvbi4NCj4gDQo+IEkgd2FzIHRoaW5raW5nIGFib3V0IHRoYXQgb25lLiBJdCBpcyBh
IGJpdCB3ZWlyZCBlbGVjdHJpY2FsbHksIGxpa2Ugd2hhdA0KPiBraW5kIG9mIGVsZWN0cm9uaWNz
IGlzIHJlYWxseSBiaWRpcmVjdGlvbmFsPw0KPiANCj4gSXQgc2VlbXMgbGlrZSBhIGZhbmN5IG5h
bWUgZm9yIG9wZW4gZHJhaW4vb3BlbiBzb3VyY2UsIHdoYXQgd2UgY2FsbA0KPiAic2luZ2xlIGVu
ZGVkIiBjb25maWd1cmF0aW9uLiAoU2VlIGRvY3MgaW4NCj4gRG9jdW1lbnRhdGlvbi9ncGlvL2Ry
aXZlci50eHQpDQo+IA0KPiBJdCB3b3VsZCBiZSBncmVhdCBpZiB5b3UgY291bGQgY2hlY2sgaWYg
dGhhdCBpcyB3aGF0IHRoZXkgbWVhbiwgYWN0dWFsbHkuDQoNCkhlcmUgaXMgdGhlIGRlZmluaXRp
b24gb2YgdGhlIHJlZ2lzdGVyIGluIHRoZSBoYXJkd2FyZSBtYW51YWw6DQoNCi0tLQ0KNTQuMy4x
MyBQb3J0IEJpZGlyZWN0aW9uIENvbnRyb2wgUmVnaXN0ZXIgKFBCRENuKQ0KDQpUaGlzIHJlZ2lz
dGVyIGVuYWJsZXMgb3IgZGlzYWJsZXMgdGhlIGlucHV0IGJ1ZmZlciB3aGlsZSB0aGUgb3V0cHV0
IGJ1ZmZlciBpcyBlbmFibGVkLiBXaGVuIHRoZSBpbnB1dCBidWZmZXIgaXMgZW5hYmxlZA0Kd2hp
bGUgdGhlIG91dHB1dCBidWZmZXIgaXMgZW5hYmxlZCwgdGhlIGJpZGlyZWN0aW9uYWwgbW9kZSBp
cyBlbnRlcmVkLCBhbGxvd2luZyB0aGUgbGV2ZWwgb2YgdGhlIFBuX20gcGluIHRvIGFsd2F5cyBi
ZSByZWFkDQp2aWEgdGhlIFBQUm4uUFBSbm0gYml0Lg0KLS0tDQoNCg0KQnV0Li4ud2hhdCB0aGV5
IGRvbid0IHJlYWxseSB0ZWxsIHlvdSBpcyB0aGF0IGFueSBwZXJpcGhlcmFsIHRoYXQgbmVlZHMg
dG8gVFggYW5kIFJYIGRhdGEgb3ZlciBhIHBpbiBuZWVkcyB0aGlzIHNldC4NCg0KDQpJbiB0aGUg
aGFyZHdhcmUgbWFudWFsLCB0aGVyZSBpcyBhIHByZXR0eSBwaWN0dXJlIChGaWd1cmUgNTQuMSBM
b2dpY2FsIERpYWdyYW0gb2YgUG9ydCBDb250cm9sKSB0aGF0IHNob3dzIGEgZGV0YWlsZWQgbG9n
aWMgZGlhZ3JhbSBvZiB0aGUgaW50ZXJmYWNlIGJldHdlZW4gdGhlIHBlcmlwaGVyYWwgYnVzIGFu
ZCB0aGUgcGluIHBhZC4NCkFzIGZhciBhcyBJIGNhbiB0ZWxsLCB0aGUgImZ1bmN0aW9uIG11eCIg
cG9ydGlvbiBvZiB0aGlzIGNvbnRyb2xsZXIgb25seSBrbm93cyBob3cgdG8gc2V0IGEgcGluIGFz
IGRpcmVjdGlvbj1pbiBvciBkaXJlY3Rpb249b3V0Lg0KU28sIGluIHRoZSBjYXNlIG9mIEkyQyB3
aGVyZSBlYWNoIHRoZSBTQ0wgYW5kIFNEQSBwaW5zIG5lZWRzIHRvIGJlIGRyaXZlbiBhbmQgcmVh
ZC4uLml0IGNhbid0IGRvIHRoYXQuDQpUaGVyZWZvcmUsIHRoZXJlIGlzIGFuIGFkZGl0aW9uYWwg
cmVnaXN0ZXIgdG8gbWFudWFsbHkgZW5hYmxlIHRoZSBpbnB1dCBidWZmZXIgYW5kIGxldCB0aGUg
bXV4IGVuYWJsZSB0aGUgb3V0cHV0IGJ1ZmZlci4NCg0KU28gd2hpbGUgeWVzLCBJMkMgaXMgb3Bl
bi1kcmFpbiwgdGhpcyBpcyBhbHNvIHRoZSBjYXNlIGZvciB0aGUgZGF0YSBwaW5zIGZvciB0aGUg
U0RISS4gQW5kIHRoZSBNRElPIHBpbiBmcm9tIEV0aGVybmV0LiBJdCByZWFsbHkgaGFzIHRvIGRv
IHdpdGggdGhlIGZhY3QgdGhhdCB0aGlzIHBpbiBjb250cm9sbGVyIHdhc24ndCBkZXNpZ25lZCB0
byBlbmFibGUgYm90aCB0aGUgaW5wdXQgYW5kIG91dHB1dCBidWZmZXJzIGF0IHRoZSBzYW1lIHRp
bWUuDQoNClRoZSBzaXR1YXRpb24gaXMgc2ltaWxhciBmb3Igb3VyIFNXSU9fSU4gYW5kIFNXSU9f
T1VUIGZsYWdzLiBGb3IgZXhhbXBsZSwgdG8gdXNlIHRoZSBTU0kgc291bmQgaW50ZXJmYWNlLCB5
b3UgaGF2ZSB0byBzZXQgdGhlIFRYIHNpZ25hbHMgdG8gImlucHV0IiAoU1dJT19JTikuIE1ha2Vz
IHNlbnNlLCByaWdodD8/DQoNCkkgY291bGQgYXJndWUgdGhhdCBhbGwgb2YgdGhlc2UgIkZMQUdT
IiBzZXR0aW5ncyBzaG91bGQgaGF2ZSBiZWVuIGluY29ycG9yYXRlZCBpbiB0aGUgSFcgbG9naWMg
b2YgdGhlIHBpbiBjb250cm9sbGVyLi4uYnV0IGZvciB3aGF0ZXZlciByZWFzb24sIHRoZSB0aGV5
IGhhZCB0byBtYWtlIHRoZW0gc2VwYXJhdGUgcmVnaXN0ZXJzIGFuZCBtYWtlIFNXIGRvIGl0Lg0K
U28sIEkgY291bGQgYXJndWUgdGhhdCB0aGVzZSByZWdpc3RlcnMgc2V0dGluZ3MgYXJlIHJlYWxs
eSBwYXJ0IG9mIHBpbiBtdXhpbmcsIG5vdCByZWFsbHkgdXNlciBjb25maWcuLi4uYW5kIGhlbmNl
IGJlbG9uZyBpbiB0aGUgInBpbm11eCIgcHJvcGVydHkuDQoNCg0KSG93IGFib3V0IHRoaXMgY29t
cHJvbWlzZTogSW5zdGVhZCBvZiBCSV9ESVIsIHdlIHVzZSAiVFlQRV9JMkMiLCAiVFlQRV9TRERB
VEEiLCAiVFlQRV9NRElPIiwgIlRZUEVfTFZEUyIsIGV0Yy4uLiB0byBkZXNjcmliZSB0aGUgJ3Nw
ZWNpYWwnIG9uZXMuIFRoYXQgd2F5IGl0IGNhbiBnbyBiYWNrIHVuZGVyICJwaW5tdXgiLiBMaWtl
IEphY29wbyBzYWlkLCB0aGVzZSByZWdpc3RlciBzZXR0aW5ncyBhcmUgcmVhbGx5IHN1cHBvc2Vk
IHRvIGJlIHNldCB3aGVuIHlvdSBhcmUgc2VsZWN0aW5nIHRoZSBwaW4tbXV4IG9wdGlvbi4NCg0K
DQpPZiBjb3Vyc2UgYmVoaW5kIHRoZSBzY2VuZXMsIGl0J3MgcmVhbGx5Og0KICAjZGVmaW5lIFRZ
UEVfSTJDICAgIEJJX0RJUiANCiAgI2RlZmluZSBUWVBFX1NEREFUQSBCSV9ESVINCiAgI2RlZmlu
ZSBUWVBFX1NEQ01EICBCSV9ESVINCiAgI2RlZmluZSBUWVBFX0xWRFMgICBTV0lPX09VVA0KDQpF
eGFtcGxlczoNCg0KCWkyYzNfcGluczogaTJjMyB7DQoJCXBpbm11eCA9IDxQSU4oMSwgNikgfCBG
VU5DXzEgfCBUWVBFX0kyQz4sDQoJCSAgICAgICAgIDxQSU4oMSwgNykgfCBGVU5DXzEgfCBUWVBF
X0kyQz47DQoJfTsNCg0KCS8qIFNIREkgY2gxIG9uIENOMSAqLw0KCXNkaGkxX3BpbnM6IHNkaGkx
IHsNCgkJLyogU0hESSBjaDEgb24gUG9ydCAzICovDQoJCXBpbm11eCA9IDxQSU4oMywgOCkgfCBG
VU5DXzc+LAkJCS8qIFNESEkxIENEICovDQoJCQkJPFBJTigzLCA5KSBGVU5DXzcpPiwJCQkvKiBT
REhJMSBXUCAqLw0KCQkJCTxQSU4oMywgMTApIEZVTkNfNyB8IFRZUEVfU0REQVRBKT4sCS8qIFNE
SEkxIERBVDEgKi8NCgkJCQk8UElOKDMsIDExKSBGVU5DXzcgfCBUWVBFX1NEREFUQSk+LAkvKiBT
REhJMSBEQVQwICovDQoJCQkJPFBJTigzLCAxMikgRlVOQ183KT4sCQkJLyogU0RISTEgQ0xLICov
DQoJCQkJPFBJTigzLCAxMykgRlVOQ183IHwgVFlQRV9TRENNRCk+LAkvKiBTREhJMSBDTUQgKi8N
CgkJCQk8UElOKDMsIDE0KSBGVU5DXzcgfCBUWVBFX1NEREFUQSk+LAkvKiBTREhJMSBEQVQzICov
DQoJCQkJPFBJTigzLCAxNSkgRlVOQ183IHwgVFlQRV9TRERBVEEpPjsJLyogU0RISTEgREFUMiAq
Lw0KCX07DQoNCg0KDQojIEhvbmVzdGx5LCBJIGhhdmUgbm8gaWRlYSB3aGVyZSB0aGlzIHBpbiBj
b250cm9sbGVyIGNhbWUgZnJvbS4gSSBoYXZlIG5vdCBzZWVuIGl0IGluIGFueSBvdGhlciBSZW5l
c2FzIHBhcnQgKE1pdHN1YmlzaGkvSGl0YWNoaS9ORUMpLg0KDQoNCkNocmlzDQoNCg0K
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

diff --git a/include/dt-bindings/pinctrl/r7s72100-pinctrl.h b/include/dt-bindings/pinctrl/r7s72100-pinctrl.h
new file mode 100644
index 0000000..170338b
--- /dev/null
+++ b/include/dt-bindings/pinctrl/r7s72100-pinctrl.h
@@ -0,0 +1,36 @@ 
+/*
+ * Defines macros and constants for Renesas RZ/A1 pin controller pin
+ * muxing functions.
+ */
+#ifndef __DT_BINDINGS_PINCTRL_RENESAS_RZA1_H
+#define __DT_BINDINGS_PINCTRL_RENESAS_RZA1_H
+
+#define RZA1_PINS_PER_PORT	16
+
+/* Create the pin index from its bank and position numbers */
+#define PIN(b, p)		((b) * RZA1_PINS_PER_PORT + (p))
+
+/*
+ * Flags to apply to alternate function configuration
+ * All of the following are mutually exclusive.
+ */
+
+/*
+ * Pin is bi-directional.
+ * An alternate function that needs both input/output functionalities shall
+ * be configured as bidirectional.
+ * Eg. SDA/SCL pins of an I2c interface.
+ */
+#define BI_DIR			(1 << 3)
+
+/*
+ * Flags used to ask software to drive the pin I/O direction overriding the
+ * alternate function configuration.
+ * Some alternate functions require software to force I/O direction of a pin,
+ * overriding the designated one.
+ * Refer to the HW manual to know when this flag shall be used.
+ */
+#define SWIO_IN			(1 << 4)
+#define SWIO_OUT		(1 << 5)
+
+#endif