Pinmux bindings proposal V2
From: Dong Aisheng <hidden>
Date: 2012-02-03 18:13:56
Also in:
linux-devicetree, lkml
On Sat, Feb 4, 2012 at 1:32 AM, Tony Lindgren [off-list ref] wrote:
* Dong Aisheng [off-list ref] [120202 11:36]:quoted
Actually i think i'd rather do not use config property, then i could be more compact: (anyway it's another issue and is flexible to be controlled by #pinmux-cells) pinctrl_usdhc4: pinconfig-usdhc4 { ? ? ? ? /* 0: pin 1: group */ ? ? ? ? mux-entity = <0>; ? ? ? ? func-name = "usdhc4func"; ? ? ? ? grp-name = "usdhc4grp";The func-name and grp-name should be optional here. This mux entry is already the group, and can be used as the group name.
For the case i discussed here, the mux entry is PIN. (the mux-entity value is 0). we introduce this value here for treating all pins is one group. When do map parsing, only one pinmux map will be created. So we need a grp-name. And we also need a func-name here for construct pinmux map.
And the function name can be generated dynamically in most cases. I'm currently using np->full_name of the driver claiming these pins as the function name.
Why i did not use np->name as function name is because the np->name can be different while actually these nodes may represent the same function but just different pins, so the function name should be same.
quoted
? ? ? ? mux = ? ? ? ? ? ? ? ? <MX6Q_SD4_CMD ?0 MX6Q_USDHC_PAD_CTRL> ? ? ? ? ? ? ? ? <MX6Q_SD4_CLK ?0 MX6Q_USDHC_PAD_CTRL> ? ? ? ? ? ? ? ? <MX6Q_SD4_DAT0 1 MX6Q_USDHC_PAD_CTRL> ? ? ? ? ? ? ? ? <MX6Q_SD4_DAT1 1 MX6Q_USDHC_PAD_CTRL> ? ? ? ? ? ? ? ? <MX6Q_SD4_DAT2 1 MX6Q_USDHC_PAD_CTRL> ? ? ? ? ? ? ? ? <MX6Q_SD4_DAT3 1 MX6Q_USDHC_PAD_CTRL> ? ? ? ? ? ? ? ? <MX6Q_SD4_DAT4 1 MX6Q_USDHC_PAD_CTRL> ? ? ? ? ? ? ? ? <MX6Q_SD4_DAT5 1 MX6Q_USDHC_PAD_CTRL> ? ? ? ? ? ? ? ? <MX6Q_SD4_DAT6 1 MX6Q_USDHC_PAD_CTRL> ? ? ? ? ? ? ? ? <MX6Q_SD4_DAT7 1 MX6Q_USDHC_PAD_CTRL>; };For listing basic pins this format works fine for me. It seems to have low overhead for parsing. And the width of the array can be driver specific. Looks like it's the binding for altenative states that's still a bit open..
Yes, it does not have states support.
So how about let's first standardize on the mux format above?
I'm afraid it may be hard for us to standardize the mux format for a standard binding in pinctrl core due to hw difference. I'm think the new way which i sent in this thread after the mail you replied. You can refer to them to see if it's reasonable for you too. Regards Dong Aisheng