Re: [PATCH 0/2] pinctrl: common handling of generic pinconfig propsin dt

[Linus Walleij]

On Mon, Jun 10, 2013 at 3:54 PM, Heiko Stübner <heiko@xxxxxxxxx> wrote:
> Am Montag, 10. Juni 2013, 15:39:26 schrieb Linus Walleij:
>>
>> Does this design imply that we will never be able to support any
>> more than 32 bits (well, the number of bits in unsigned long)
>> i.e. 32 different generic pin configurations?
>>
>> In that case I suspect this might not be so wise. :-(
>
> hmm, yes this would be the limit ... so back to the drawing board

Well, I'm not hopeless, if this is what everyone wants we might
need to have it like this, perhaps make it possible to extend
the config word in the device tree from 32 to 64 to 96 bits
like this, if:

= <0x00000001>;

becomes:

= <PINCONFIG_BIAS_DISABLE>;

once we hit:

= <0x80000000>;

that is maybe

= <PINCONFIG_FOO>;

and then we need to ad PINCONFIG_BAR. What to do...
Well enable the next 64 bits:

= <0x00000000 0x00000001>;

i.e.

= <PINCONFIG_NONE PINCONFIG_EXT1_BAR>;

Note necessary naming convention to remember to
put that after the other...

and then  we get to 96 bits:

= <PINCONFIG_NONE PINCONFIG_EXT1_NONE PINCONFIG_EXT2_BAZ>;

It's getting a bit ugly ...

>> my_config: my_config {
>>         bias-disable;
>>         drive-push-pull = <6>;
>>         output-high;
>> };
>>
>> It will make the device trees bigger for sure, but maybe more
>> readable as well?
>
> There was a discussion about each of the merits of the two approaches
> (bitstuffed vs. individual properties) between Tomasz Figa and Jean-Christophe
> PLAGNIOL-VILLARD a bit back if I remember correctly.

It's OK if it's bindings for a certain system where you know you
will never have more than 32 config options. But for something
generic we need to make some space.

> And it still would be possible to write short pin statements as
>
>         pins = <bank pin mux &config_node>;
>
> if I'm not mistaken.

I thinkso....

I'll take these patches out FTM so you can experiment, but I'm
ready to make a late merge of this if you can come up with something
that we agree upon to be future-safe.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/