On 30-03-16 10:58, Michael Haas wrote:
Am 30. März 2016 09:55:54 MESZ, schrieb Hans de Goede <hdego...@redhat.com>:
On 30-03-16 06:57, Michael Haas wrote:
On 03/28/2016 03:01 PM, Hans de Goede wrote:
but unless there's a real need
for me to verify this,
I'll simply revert the u-boot patch and enjoy working GPIO.
Given the entire discussion in this thread, I agree that fixing this
is best. But I do not see reverting the u-boot patch disabling
as the solution. ldo3/4 are unused on most boards, so disabling them
clearly is the right thing todo IMHO.
I just checked the Banana Pi, which exposes ports from bank E on its
that's the "Camera Serial Interface", but that connector is
as supporting various GPIO pins:
That connector is not usable unless you've got a really special cable,
also ldo3/4 are disabled in the kernel dts, so it does not matter what
On the Cubietruck, there's also CN9, exposing some GPIO ports from
The Cubietruck also has ldo3/4 disabled in the kernel dts.
Given that there tend to be crashes on re-enabling LDO3+LDO4 and many
boards expose affected pins (not only for CSI!): wouldn't be it be
best to keep them enabled?
s/Many boards/Lime 2/ and we still do not fully understand what is
on there, we just know that not enabling ldo3/4 at the u-boot level
causes issues, we do not know / understand why though.
U-boot supports 52 boards with an axp209 pmic, yet you only name a
few which need ldo3/4 according to you, and for 2 of your examples the
kernel dts says differently.
I'm not going to enable ldo3/4 by default on all boards just because
are needed on the Lime 2.
You are making an excellent point. I will submit patches for the lime* boards
as proposed in your earlier mail.
Just to ask for some clarification: you are saying the regulators are disabled
in the kernel dts files.
I looked at the cubietruck dts files and the regulators are not mentioned in
there. If they are not mentioned, are they turned off or do they remain in
their default state, e.g the way that u-boot left them?
The kernel will turn off any unused regulators in a late_init call (just
before calling /sbin/init), so not listed regulators will get turned off.
Stepping back from kernel/u-boot issues, would it make sense to also turn on
the regulators for the cubietruck? Perhaps in u-boot and the kernel?
Have you checked the schematics to see how portG is powered on the CubieTruck?
It would only make sense to turn on ldo3 or ldo4 if it is actually used
to power an exposed port.
You received this message because you are subscribed to the Google Groups
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.