On Wed, Nov 6, 2013 at 3:02 AM, Sherman Yin <syin@xxxxxxxxxxxx> wrote:When Linus asked me to try using generic pinconf instead, I ran into
problems with this feature due to how the generic pinconf properties are
defined differently than my properties - perhaps this feature just doesn't
work for generic pinconf-based drivers with the (Unless we are ok with using
1/0 for boolean properties, but it has already been pointed out that these
should be valueless.).
Well it seems you would need a way to pass an array of the same
boolean property and that seems a bit more complex and hard to
read than the generic boolean bindings.
You would have to patch the OF core to do something like that:
bias-pull-up = <true true false>;
1/0 isn't so good I think, what should the parser do with e.g. 2?
This is more to the point.
While I'd love to be able define my pin config nodes this way, if I have to
use generic pinconf for the driver to be upstreamed, then I'm fine with it.
Well you need to use generic pin config because all the custom
stuff - i.MX comes to mind - is creating a mess. I prefer that we
share bindings and code, as any programmer would...
That said, if you can patch the OF core and the generic pin config
parser to do what you want with lists like that, it's your pick.
It may take some time though.
This setting disconnects the input (DIN) to the internal logic from >the
pin pad. However, the output (DOUT) can still drive the pad. It
seems to match PIN_CONFIG_OUTPUT, but the current generic option is
either "output-low" or "output-high" - are these referring to a static
output of 0 and 1?
What's the best property to use in this case?
Seems like a new case.
What about you patch include/linux/pinctrl/pinconf-generic.h
to add PIN_CONFIG_INPUT_DISABLE with this semantic
and also patch the generic pinconf parser in drivers/pinctrl/pinconf-generic.c
to handle this?
This controls several aspect of the pin (slew rate, pull up strength,
etc) to meet I2C specs for Standard/Fast mode vs High Speed mode. I
think the best way is to map this to slew rate, which would require
some explanation because the meaning of slew rate differs depending on
what pin function is selected:
- When I2C (*_SCL or *_SDA) function is selected for the pin: 0:
& Fast mode (400kbps), 1: High Speed mode (3.4Mbps)
- When IC_DM or IC_DP function is selected, 0: normal slew rate, 1:
fast slew rate
- Else: 0: fast slew rate, 1: normal slew rate
Do we agree that the "slew rate" is the best property to use for "mode"?
It seems to be indeed mostly related to slew rate.
However if you want a custom brcm,mode binding that should
be possible too, as well as augmenting the driver to use
*both* generic pinconf *and* some custom config options
on top. That has not been done so far though I think, so you
might need a bit of hacking to do that.