On Wed, Oct 9, 2013 at 3:45 PM, Russell King - ARM Linux
<linux@xxxxxxxxxxxxxxxx> wrote:
> Right, so that means doing this:
>
> pinctrl_usdhc1_1: usdhc1grp-1 {
> fsl,pins = <
> ...
> MX6QDL_PAD_SD1_DAT3__SD1_DATA3 0x17059
> ...
> >;
> };
>
> pinctrl_usdhc1_1_dat3cd: usdhc1grp-3 {
> fsl,pins = <
> MX6QDL_PAD_SD1_DAT3__SD1_DATA3 0x13059
> >;
> };
>
> and then:
>
> pinctrl-0 = <&pinctrl_usdhc1_1 &pinctrl_usdhc1_1_dat3cd>;
>
> can result in either "MX6QDL_PAD_SD1_DAT3__SD1_DATA3 0x17059" or
> "MX6QDL_PAD_SD1_DAT3__SD1_DATA3 0x13059" being the final configuration
> for that pin.
I'm uncertain about the device tree case. I guess it is indeed
an array of handles indexed [0,1], the framework will only
send that array down to the driver, no strings attached.
> What that means is that for any pinctrl setting, pins to be configured
> must be mentioned exactly once and once only.
Either that (and the above does seem very ambigous) or the driver
need to combine and handle the conflicting configurations,
maintaining a state for the pin and so on ...
This seems like two *complete* configs fighting over the same pin
rather than two complementary configs that we could | together
and write, and that is indeed ambigous. The array passed to
the config function is supposed to be individual settings like
[ pull-up, schmitt-trigger ] not two complete sets of config.
The generic pin config binding is luckily more clear than this
i.MX-specific handling.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
