Re: [PATCH RFC v2 8/8] ARM: zynq: DT: Add pinctrl information

[SÃren Brinkmann]

On Tue, 2014-10-28 at 04:05PM +0100, Linus Walleij wrote:
> On Thu, Oct 16, 2014 at 7:11 PM, Soren Brinkmann
> <soren.brinkmann@xxxxxxxxxx> wrote:
> 
> > Add pinctrl descriptions to the zc702 and zc706 device trees.
> >
> > Signed-off-by: Soren Brinkmann <soren.brinkmann@xxxxxxxxxx>
> 
> (...)
> > +&pinctrl0 {
> > +       pinctrl_can0_default: pinctrl-can0-default {
> > +               common {
> > +                       function = "can0";
> > +                       groups = "can0_9_grp";
> > +                       bias-pull-up = <0>;
> 
> No. If you want pull-up, just use
> bias-pull-up;
> 
> If you want to disable pull-up, use
> bias-disable;

But bias-disable also disables high-impedance. That doesn't work for me,
I think.

> 
> > +                       slew-rate = <0>;
> 
> If this measure is any kind of time unit, this is against the laws of nature.

It's not. As the bindings say, the argument is driver specific. In the
Zynq case you can simply choose fast or slow - whatever that means -
which maps to 0 or 1 in the DT. This though raises the question where
that documentation lives. Since this is a driver specific
interpretation, it should not be in the binding docs, IMHO. So, some
other place might need to be found to document the implementation
specifics.

> 
> > +                       io-standard = <1>;
> > +               };
> > +
> > +               rx {
> > +                       pins = "MIO46";
> > +                       bias-high-impedance = <1>;
> 
> Just
> bias-high-impedance;

Same problem as I have above. To allow all permutations of pull-up and
tri-state I can't just have a single disable-bias property.

> 
> > +               };
> > +
> > +               tx {
> > +                       pins = "MIO47";
> > +                       bias-high-impedance = <0>;
> 
> Just
> bias-disable;

That would also disable the pull-up.

	SÃren
--
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/