Hi Stephen,
On Thu, Nov 15, 2012 at 3:46 PM, Stephen Warren swarren@wwwdotorg.org wrote:
On 11/15/2012 04:31 PM, Simon Glass wrote:
Hi Stephen,
On Wed, Oct 31, 2012 at 9:50 PM, Stephen Warren swarren@wwwdotorg.org wrote:
On 10/31/2012 05:59 PM, Simon Glass wrote:
Hi,
On Fri, Oct 26, 2012 at 12:17 AM, Lucas Stach dev@lynxeye.de wrote:
Am Donnerstag, den 25.10.2012, 19:31 -0700 schrieb Simon Glass:
From: Sean Paul seanpaul@chromium.org
Add get and set gpio functions to fdtdec that take into account the polarity field in fdtdec_gpio_state.flags.
In another thread Stephen Warren and I came to the conclusion that we most likely should remove this polarity flag from the GPIO bindings.
Currently it is only for the USB VBUS GPIO which should move over to regulators once they land in U-Boot. Do you have any other applications for this flag, so we might reconsider removing it?
Well, any time you have a flag which is inverted in meaning, it can be useful. We have several switches on the board which can be active high or low, and polarity is used for that.
In fact, it would be nice IMO to be able to specify input/output as well. I know the exynos bindings do this. There is a noddy function called fdtdec_setup_gpio() in U-Boot which really needs to be sorted out. I discussed with Stephen some time ago how GPIOs should be SOC-specific and it should be possible to set up a GPIO with a single call, as Linux does. The more information there is in the binding, the more it can do automatically.
Does the Tegra Linux GPIO binding still have a polarity?
Yes it does, although in practice it can't be used (and hence should really be removed), since not all GPIO bindings have such a flag, so there is always a need for a separate property to indicate the polarity (c.f. fixed-regulator with GPIO control bindings for example).
I've had a bit of time to look into this. I see that the regulator framework in the kernel seems to be used for various control purposes, and provides useful polarity stuff. I was rather hoping that GPIOs could be a bit more high level in U-Boot, with information about:
- input/output
- drive strength
- polarity
- pull up/down
In fact most of these are actually supported in most kernel bindings, but of course it is binding-specific. Would it be useful to ask for a polarity setting in the GPIO. When it is not available, the polarity would then always be normal.
This might avoid moving polarity and input/output selecting down into each client of the gpio, which seems undesirable in general.
Should we consider a second level of indirection for GPIOs to support these non-binding features? It seems a bit complicated though.
However, if it is too late to do this, or not desirable for some reason, then we should just drop this patch.
The issue may not be bad enough we have to drop flag usage. It's also being discussed at:
http://www.spinics.net/lists/arm-kernel/msg206299.html
I'd recommend seeing how that pans out before making a decision whether to start/keep using flags or not.
Thanks, will await news.
Regards, Simon