On Thu, Sep 08, 2016 at 12:46:14PM +0800, Chen-Yu Tsai wrote:

quoted

I mean it like supporting these in *addition* to the custom ones, so there can
be a smooth phase-over.

Check for example Laurent's commit for SH-PFC:
commit 16ccaf5bb5a52372bfebd3dfbb79dd810ad49c09
"pinctrl: sh-pfc: Accept standard function, pins and groups properties"
It's awesome, and since, they have improved the looks of Renesas
DTS files a lot.

It could look a bit like this nice thing from
lpc4337-ciaa.dts:

&pinctrl {
        enet_rmii_pins: enet-rmii-pins {
                enet_rmii_rxd_cfg {
                        pins = "p1_15", "p0_0";
                        function = "enet";
                        slew-rate = <1>;
                        bias-disable;
                        input-enable;
                        input-schmitt-disable;
                };

                enet_rmii_txd_cfg {
                        pins = "p1_18", "p1_20";
                        function = "enet";
                        slew-rate = <1>;
                        bias-disable;
                        input-enable;
                        input-schmitt-disable;
                };
(etc)

This looks nice.

Indeed.

I've slightly looked at the generic pinconf stuff.  I think we
should be able to support them, though the sunxi pinctrl driver
currently doesn't work well with it though. For example, it doesn't
declare ".is_generic = true", it doesn't filter unsupported pinconf
parameters, and it doesn't reply to queries correctly. I will fix
these bits.

Also, I think we are needlessly using pin groups, 1 pin per group.
Can pinconf/pinctrl work without them? Would there be any harm
converting the sunxi driver to work directly with pins? This would
make it match generic pinconf parsing, and make it easier to get
both working together.

I think it comes from a requirement that you had to have groups at
some point (I don't know if it's still the case), which is why we
ended up with single-pin groups, because we can mux each pins entirely
separately.

If it's not required anymore, then yes, it makes total sense to remove
it.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com