Thread (1 message) 1 message, 1 author, 2017-12-05

[PATCH] arm64: dts: allwinner: a64: bananapi-m64: Add LED device node

From: Chen-Yu Tsai <hidden>
Date: 2017-12-05 13:00:37
Also in: linux-devicetree

On Tue, Dec 5, 2017 at 6:05 PM, Maxime Ripard
[off-list ref] wrote:
Hi,

On Sat, Dec 02, 2017 at 12:27:33AM +0800, Chen-Yu Tsai wrote:
quoted
The Bananapi-M64 has 3 LEDS in red, green, and blue. These are toggled
via GPIO lines, which drive transistors that control current across the
LEDS. The red LED is by default on, via an additional pull-up on the
control line. We consider this means that it is a power indicator.
So we set the "default-on" property for it.

The pingroups the GPIO lines belong to require external regulators be
enabled to be able to drive the GPIO high. These regulators also have
other purposes. However the pin controller does not have bindings for
regulators. Here we just set them to always-on.
I guess we should take the opportunity to do just that.

We have been deferring this for quite some time now, this is a perfect
occasion to do it once and for all :)
True. But right now I don't see an elegant solution. What is the purpose
of having the regulator tied to pinctrl / GPIO? You can't have the pinctrl
driver asking for the regulator at probe time, as it might not be available
or even have a cyclic dependency (because the PMIC is I2C driven, which
needs an I2C controller, which needs the pinctrl). If you defer fetching
the regulator to a later point, you might end up with an inconsistent state.
Again with the I2C driven regulator example, what happens if the regulator
core decides to turn the regulator off before the pinctrl side has a chance
to take a reference and enable it?


Regards
ChenYu
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help