On Wed, Mar 29, 2017 at 9:35 AM, Geert Uytterhoeven
<geert@xxxxxxxxxxxxxx> wrote:
> Me:
>> See for example:
>> include/dt-bindings/pinctrl/mt65xx.h
>>
>> And how that is used in:
>> arch/arm/boot/dts/mt2701-pinfunc.h
>> arch/arm/boot/dts/mt2701-evb.dts
>>
>> The docs are here:
>> Documentation/devicetree/bindings/pinctrl/pinctrl-mt65xx.txt
>
> All of the above pack the information for a pin into a single 32-bit integer.
> Is that what you want us to use, too?
> Currently we use two integers: 1) pin index, and 2) function/flags combo.
I don't really know what you need, sorry. But some kind of figure, yes.
I would say whatever makes sense. 16+16 bits makes sense in most
combinatorial spaces does it not? If you split 32 bits in 16 bits for
pin and 16 bits for function, do you have more than 2^16 pins or 2^16
functions?
If you really do we may need to go for u64 but ... really? Is there
a rational reason for that other than "we did it like this first"?
I do not understand the notion of "flags" here. I hope that is not referring
to pin config, because I expect that to use the standard pin config
bindings outside of the pinmux value which should just define the
pin+function combo:
node {
pinmux = <PIN_NUMBER_PINMUX>;
GENERIC_PINCONFIG;
};
Example from Mediatek:
i2c1_pins_a: i2c1@0 {
pins {
pinmux = <MT8135_PIN_195_SDA1__FUNC_SDA1>,
<MT8135_PIN_196_SCL1__FUNC_SCL1>;
bias-pull-up = <55>;
};
};
So this allows for a combine pin+function number but pull ups,
bias etc are not baked into the thing, they have to be added on
separately with the generic bindings, which is nice and very readable.
Yours,
Linus Walleij
