On Tue, Jun 4, 2013 at 2:05 PM, Heiko St?bner [off-list ref] wrote:

quoted

quoted

+PULL_AUTO      (1 << 0): indicate this pin needs a pull setting for SoCs
+                         that determine the pull up or down themselfs

Hm, never saw that before...

Citing the original gpio driver:

        /*
         * Values written to this register independently
         * control Pullup/Pulldown or not for the
         * corresponding data bit in GPIO.
         * 0: pull up/down enable, PAD type will decide
         * to be up or down, not related with this value
         * 1: pull up/down disable
         */

So if it's a pull up or down is decided based on the mux of the pin. Calling
everything a "pull down" (or up) when it isn't seemed somehow wrong to me.

The rk3188 on the other hand supports both pull up and down separately.

Or should this be selected as PULL_UP | PULL_DOWN in the config?

The generic config is pretty much either/or so it'd be a new
config for that approach.

Basically it seems they have embedded knowledge into the
silicon: there is no specific rule as to whether a pad should be
pulled up or down depending on "pad type" as is stated, rather
it's so that if you know a pad will be used for I2C SCL then
you know it needs pull-up. Probably something like a "1" on
some constant switch in VHDL/Verilog is hard-coded into
the silicon turning on pull-up if I2C is selected and the
autopull is set for example.

quoted

+config PINCTRL_ROCKCHIP
+       bool
+       select PINMUX
+       select PINCONF
+       select GENERIC_IRQ_CHIP

Why is this super-simple pin config thing not using
GENERIC_PINCONF?

I *know* it is simpler to implement your own thing, but think of the
poor maintainers that have to wade through 50 identical implementations.
Do this, it pays off.

generic pinconf sounds interesting ... will give it a try.

The only problem is the pull stuff mentioned above that is either pull up or
down without the driver having knowledge about it. And generic_pinconf only
knows about them separately right now.

Create a separate patch adding PIN_CONFIG_BIAS_PULL_AUTO
to include/linux/pinctrl/pinconf-generic.h, don't forget the
kerneldoc, and patching drivers/pinctrl/pinconf-generic.c.

I'll apply it right away.

quoted

Nothing else you want to say about the pins here?
(No big deal for sure, but....)

when using pinconfig_generic, its dump_pin function should be more talkative
right?

Yes, one of the things you get for free... soon also the pin config
DT parser will be for free I hope.

Yours,
Linus Walleij