Re: [linux-sunxi] [PATCH 1/3] sunxi: A20-OLinuXino-LIME2: Fix ldo3/ldo4 in DTS

2016-03-31 Thread Hans de Goede 

Hi,

On 30-03-16 10:58, Michael Haas wrote:

Am 30. März 2016 09:55:54 MESZ, schrieb Hans de Goede :

Hi,

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
in u-boot
is best. But I do not see reverting the u-boot patch disabling

ldo3/4

by default
as the solution. ldo3/4 are unused on most boards, so disabling them
by default
clearly is the right thing todo IMHO.


I just checked the Banana Pi, which exposes ports from bank E on its
CON1. Admittedly,
that's the "Camera Serial Interface", but that connector is

explicitly

also labelled
as supporting various GPIO pins:

http://www.bananapi.org/p/product.html

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
u-boot
does.


On the Cubietruck, there's also CN9, exposing some GPIO ports from

bank G:

https://linux-sunxi.org/Cubietech_Cubietruck


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

the

best to keep them enabled?


s/Many boards/Lime 2/ and we still do not fully understand what is
going
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
select
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
they
are needed on the Lime 2.

Regards,

Hans


Hi Hans,

You are making an excellent point. I will submit patches for the lime* boards 
as proposed in your earlier mail.


Note I've just added a patch with the necessary changes to my tree, so there
is no need to submit a patch for this.

Regards,

Hans

--
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] [PATCH 1/3] sunxi: A20-OLinuXino-LIME2: Fix ldo3/ldo4 in DTS

2016-03-30 Thread Michael Haas 
Am 30. März 2016 09:55:54 MESZ, schrieb Hans de Goede :
>Hi,
>
>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
>>> in u-boot
>>> is best. But I do not see reverting the u-boot patch disabling
>ldo3/4
>>> by default
>>> as the solution. ldo3/4 are unused on most boards, so disabling them
>>> by default
>>> clearly is the right thing todo IMHO.
>>
>> I just checked the Banana Pi, which exposes ports from bank E on its
>> CON1. Admittedly,
>> that's the "Camera Serial Interface", but that connector is
>explicitly
>> also labelled
>> as supporting various GPIO pins:
>http://www.bananapi.org/p/product.html
>
>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
>u-boot
>does.
>
>> On the Cubietruck, there's also CN9, exposing some GPIO ports from
>bank G:
>> https://linux-sunxi.org/Cubietech_Cubietruck
>
>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
>the
>> best to keep them enabled?
>
>s/Many boards/Lime 2/ and we still do not fully understand what is
>going
>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
>select
>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
>they
>are needed on the Lime 2.
>
>Regards,
>
>Hans

Hi Hans,

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?

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?

Michael 

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] [PATCH 1/3] sunxi: A20-OLinuXino-LIME2: Fix ldo3/ldo4 in DTS

2016-03-30 Thread Hans de Goede 

Hi,

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
in u-boot
is best. But I do not see reverting the u-boot patch disabling ldo3/4
by default
as the solution. ldo3/4 are unused on most boards, so disabling them
by default
clearly is the right thing todo IMHO.


I just checked the Banana Pi, which exposes ports from bank E on its
CON1. Admittedly,
that's the "Camera Serial Interface", but that connector is explicitly
also labelled
as supporting various GPIO pins: http://www.bananapi.org/p/product.html


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 u-boot
does.


On the Cubietruck, there's also CN9, exposing some GPIO ports from bank G:
https://linux-sunxi.org/Cubietech_Cubietruck


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 the
best to keep them enabled?


s/Many boards/Lime 2/ and we still do not fully understand what is going
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 select
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 they
are needed on the Lime 2.

Regards,

Hans

--
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] [PATCH 1/3] sunxi: A20-OLinuXino-LIME2: Fix ldo3/ldo4 in DTS

2016-03-29 Thread Michael Haas 
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
> in u-boot
> is best. But I do not see reverting the u-boot patch disabling ldo3/4
> by default
> as the solution. ldo3/4 are unused on most boards, so disabling them
> by default
> clearly is the right thing todo IMHO.

I just checked the Banana Pi, which exposes ports from bank E on its
CON1. Admittedly,
that's the "Camera Serial Interface", but that connector is explicitly
also labelled
as supporting various GPIO pins: http://www.bananapi.org/p/product.html

On the Cubietruck, there's also CN9, exposing some GPIO ports from bank G:
https://linux-sunxi.org/Cubietech_Cubietruck

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 the
best to
keep them enabled?

FWIW, Olimex did reply to my inquiry regarding misleading pin names:
https://github.com/OLIMEX/OLINUXINO/issues/35#issuecomment-202823804

> I see. We used this Allwinner document as original reference design:
> a20_pad_std_v1_1.pdf @ sunxi
>  - if you inspect
> the schematic you'd notice that the signals connected to E18 and E19
> are named respectively CSI1-VCC and CSI0-VCC. Hence, this is where the
> wrong naming of our processor pins came from. I'll add the proposal
> for correction for the future hardware revision of the boards affected.
>
> The difference between our boards and other boards come from the
> simple fact that their designs use 3.3V cameras, while we followed the
> original reference design and used 2.8V camera in A20-SOM-EVB (we even
> used the same camera - GT2005).
>

Michael

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] [PATCH 1/3] sunxi: A20-OLinuXino-LIME2: Fix ldo3/ldo4 in DTS

2016-03-29 Thread Maxime Ripard 
On Mon, Mar 28, 2016 at 03:01:27PM +0200, 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 in u-boot
> is best. But I do not see reverting the u-boot patch disabling ldo3/4 by 
> default
> as the solution. ldo3/4 are unused on most boards, so disabling them by 
> default
> clearly is the right thing todo IMHO.
> 
> Instead please submit a patch for configs/A20-OLinuXino-Lime2_defconfig which
> configures them at 2800 mV there (per the Lime2 schematic).
> 
> It would be good to also check the Lime1 schematic if they are used in the 
> same
> way there, I would also welcome a patch for:
> 
> configs/A10-OLinuXino-Lime_defconfig
> configs/A20-OLinuXino-Lime_defconfig

Adding a comment to the DT summing up that whole discussion would be
great too.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

Re: [linux-sunxi] [PATCH 1/3] sunxi: A20-OLinuXino-LIME2: Fix ldo3/ldo4 in DTS

2016-03-28 Thread Hans de Goede 

Hi,

On 27-03-16 10:08, Michael Haas wrote:

On 03/26/2016 09:56 AM, Iain Paton wrote:

Having reread the A20 datasheet yesterday, something in the back of my
mind was bothering me overnight so I took some time to check this morning.

On the lime2 schematic we see the pins labeled as follows:

F19 : VCC_CSI0
E18 : VCC_CSI1

However the A20 datasheet doesn't label them this way, instead using:

F19 : VCC-PE : Port E Power Supply
E18 : VCC-PG : Port G Power Supply

no mention at all of CSI. CSI just happens to be a function that can be
multiplexed onto ports E & G.

So lets assume for a moment we don't have a CSI device, or a CSI driver
and are not using those pins for CSI functions but are instead using
their default GPIO purpose, or in the case of PG perhaps for UART3
or UART4.

What happens when you disable the regulator?  Hopefully from the above
you'll already have worked out that you lose ports E & G when you turn
their I/O power supply off and anything multiplexed onto those ports
becomes unuseable.



Hi Iain,

I took some time to go through the data sheets and your analysis is on
point.

I did raise an issue with Olimex via github [0]. Maybe they will update
their schematics.


I do have my breakout board connected to GPIO-1.. and it turns out that
mostly port G is exposed on GPIO-1. I'll be reverting Hans' patch locally
so I can toggle some pins today. I am sure he will contribute his own
thoughts on the matter.



I've also just tested building u-boot with LDO3 & 4 voltages set to
3.3v to be the same as CubieBoard, this works for lime2.
So it's unlikely that the 2.8v & 2.3v settings from my previous patch
make sense. The crash is actually being caused by something else,
probably sequencing, due to unnecessarily turning the regulators off.
Whatever the reason, we don't have enough information in the
datasheets to know for sure so we simply shouldn't turn them off to
begin with.



I just tried that on linux and axp20x-regulator.ko refuses to set the
voltage
on ldo4:

[   88.914653] at24 1-0050: 2048 byte 24c16 EEPROM, writable, 16 bytes/write
[   96.893312] axp20x-i2c 0-0034: AXP20x variant AXP209 found
[   96.910631] axp20x-i2c 0-0034: AXP20X driver loaded
[   96.955579] input: axp20x-pek as
/devices/platform/soc@01c0/1c2ac00.i2c/i2c-0/0-0034/axp20x-pek/input/input0
[   96.971734] ldo4: failed to apply 330uV constraint(-22)
[   96.990646] axp20x-regulator axp20x-regulator: Failed to register ldo4
[   97.012686] axp20x-regulator: probe of axp20x-regulator failed with
error -22

Perhaps this requires another patch [1],


Yes setting the constraints to 3.3v requires the patch you link for things to 
work.


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 in u-boot
is best. But I do not see reverting the u-boot patch disabling ldo3/4 by default
as the solution. ldo3/4 are unused on most boards, so disabling them by default
clearly is the right thing todo IMHO.

Instead please submit a patch for configs/A20-OLinuXino-Lime2_defconfig which
configures them at 2800 mV there (per the Lime2 schematic).

It would be good to also check the Lime1 schematic if they are used in the same
way there, I would also welcome a patch for:

configs/A10-OLinuXino-Lime_defconfig
configs/A20-OLinuXino-Lime_defconfig

Regards,

Hans

--
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] [PATCH 1/3] sunxi: A20-OLinuXino-LIME2: Fix ldo3/ldo4 in DTS

2016-03-27 Thread Michael Haas 
On 03/26/2016 09:56 AM, Iain Paton wrote:
> Having reread the A20 datasheet yesterday, something in the back of my 
> mind was bothering me overnight so I took some time to check this morning.
>
> On the lime2 schematic we see the pins labeled as follows:
>
> F19 : VCC_CSI0
> E18 : VCC_CSI1
>
> However the A20 datasheet doesn't label them this way, instead using:
>
> F19 : VCC-PE : Port E Power Supply
> E18 : VCC-PG : Port G Power Supply
>
> no mention at all of CSI. CSI just happens to be a function that can be 
> multiplexed onto ports E & G.
>
> So lets assume for a moment we don't have a CSI device, or a CSI driver 
> and are not using those pins for CSI functions but are instead using 
> their default GPIO purpose, or in the case of PG perhaps for UART3 
> or UART4.
>
> What happens when you disable the regulator?  Hopefully from the above 
> you'll already have worked out that you lose ports E & G when you turn 
> their I/O power supply off and anything multiplexed onto those ports 
> becomes unuseable.
>

Hi Iain,

I took some time to go through the data sheets and your analysis is on
point.

I did raise an issue with Olimex via github [0]. Maybe they will update
their schematics.


I do have my breakout board connected to GPIO-1.. and it turns out that
mostly port G is exposed on GPIO-1. I'll be reverting Hans' patch locally
so I can toggle some pins today. I am sure he will contribute his own
thoughts on the matter.


> I've also just tested building u-boot with LDO3 & 4 voltages set to 
> 3.3v to be the same as CubieBoard, this works for lime2.
> So it's unlikely that the 2.8v & 2.3v settings from my previous patch 
> make sense. The crash is actually being caused by something else, 
> probably sequencing, due to unnecessarily turning the regulators off.
> Whatever the reason, we don't have enough information in the 
> datasheets to know for sure so we simply shouldn't turn them off to 
> begin with.


I just tried that on linux and axp20x-regulator.ko refuses to set the
voltage
on ldo4:

[   88.914653] at24 1-0050: 2048 byte 24c16 EEPROM, writable, 16 bytes/write
[   96.893312] axp20x-i2c 0-0034: AXP20x variant AXP209 found
[   96.910631] axp20x-i2c 0-0034: AXP20X driver loaded
[   96.955579] input: axp20x-pek as
/devices/platform/soc@01c0/1c2ac00.i2c/i2c-0/0-0034/axp20x-pek/input/input0
[   96.971734] ldo4: failed to apply 330uV constraint(-22)
[   96.990646] axp20x-regulator axp20x-regulator: Failed to register ldo4
[   97.012686] axp20x-regulator: probe of axp20x-regulator failed with
error -22

Perhaps this requires another patch [1], but unless there's a real need
for me to verify this,
I'll simply revert the u-boot patch and enjoy working GPIO.

Michael

[0] https://github.com/OLIMEX/OLINUXINO/issues/35
[1] https://www.spinics.net/lists/devicetree/msg118871.html




-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] [PATCH 1/3] sunxi: A20-OLinuXino-LIME2: Fix ldo3/ldo4 in DTS

2016-03-26 Thread selsinork 
On 26/03/16 06:20, Michael Haas wrote:

> Hi Iain,
> 
> thanks for the feedback.
> 
> I have yet to try your patch, but I have broken out the multimeter to
> measure LDO3. On GPIO-2, I'm measuring 2.8V between pins 2 and 4 instead
> of 2.3V you seem to measuring.
> In my setup, I have simply removed the SD card from the lime2 to get
> whatever defaults are used at boot.
> 
> How did you measure LDO3? Also, did you find any pins for LDO4 besides
> the AXP209 itelf? Mine seems to be covered in flux.

I measured them at C106 & C107 decoupling caps near the SoC. On my boards 
they're on the bottom, in the square of caps below the SoC, corner nearest 
the uSD card.

LDO3 I also measured at GPIO-2 pins 2 & 4 with a breakout board connected 
as I was concerned that 2.3v at the cap was wrong.

I can easily imagine you might get different values, the datasheet 
has them as undefined after all.  However I'd suggest a power cycle or 
use a version of u-boot from before the patches went in to set LDO3/4 
to 2.8v. Soft reboot or such like probably leaves the values previously 
programmed by whatever last touched them.

Even then, different batch of AXP209, or a different boot0 in the A20 
could lead to different results.  The danger is that we're missing 
some piece of information that means there's no safe way to turn these 
regulators off then back on without the lockup. Suggest that if you do 
get different results from me, then it's even more likely we don't know 
what's going on and something that works on my board may not on yours.

Anyway, you probably want to read my second follow up. Turning these off 
is the wrong thing to do regardless. The inputs to the SoC are mis-labeled 
in the schematics, disabling them disables all io pins in groups E & G 
whether they're configured for CSI tasks or not.

Iain


-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] [PATCH 1/3] sunxi: A20-OLinuXino-LIME2: Fix ldo3/ldo4 in DTS

2016-03-26 Thread Michael Haas 
On 03/26/2016 01:58 AM, Iain Paton wrote:
> On 25/03/16 19:04, Michael Haas wrote:
>
>> This patch implements the suggested changes. It is not enough
>> to set the voltage to 280 to avoid the crash. Hence, I have
>> also removed regulator-always-on.
> NAK.
>
> If setting both min and max to 280 isn't working then I'd suggest you're 
> just papering over the issue and not actually solving it.
>
> It should be fairly clear that whenever those regulators are turned on by 
> some driver you're going to see the same issue, you've just delayed the 
> problem by removing the regulator-always-on item.
>
> The real problem here is people monkeying with the regulators without 
> understanding what they're doing, bothering to test the results, or caring 
> about the consequences.
>
> Anyway, Hans was correct in that the datasheet we have access to says that 
> the defaults for these regulators are undefined. 
> I suspect that's not the whole story though, if these regulators had random 
> values at powerup we'd have seen problems before now. 
> Most likely the values we think we know are simply incorrect plus there's 
> probably some element of sequencing involved - perhaps LDO4 needs turned on 
> first. 
> However I don't see sufficient detail in the datasheets to confirm any of 
> that, so we shouldn't assume anything.
> Electrically on the lime2 LDO3 goes to VCC-PE and LDO4 to VCC-PG. Neither 
> groups E or G appear to be connected to anything other than gpio headers, 
> so this has little to do with board design, it's something internal to 
> the SoC that the datasheet is lacking on detail about.
>
> One of the reasons for the regulator-always-on being in the dts was so that 
> the regulator didn't get touched and so didn't break anything.
>
> All said and done, it only takes a minute with a multimeter to determine 
> actual defaults. Helpful to have multiple boards to gain some confidence 
> that they behave the same, but still basing values like this on tiny 
> sample sizes is probably unwise.
>
> Looking at other A20 based boards, Cubieboards for example, shows LDO3/4 
> being unused and the VCC-PE/PG pins they power on the lime2 being tied 
> directly to 3.3v. No issues there simply because there's no way to mess 
> with the power to those blocks.
>
> The patch you really want is something like the one below which works 
> on my boards regardless of the presence of regulator-always-on.
> Verified on four boards with u-boot 2016.03 and kernel 4.5.0.
>
> Whether you decide to remove regulator-always-on or not is a different 
> question, but please use 2.3v, or some other proven working value, for 
> ldo3. At least that way you have a fighting chance of the board 
> remaining functional when something wants to turn the regulator on.

Hi Iain,

thanks for the feedback.

I have yet to try your patch, but I have broken out the multimeter to
measure LDO3. On GPIO-2, I'm measuring 2.8V between pins 2 and 4 instead
of 2.3V you seem to measuring.
In my setup, I have simply removed the SD card from the lime2 to get
whatever defaults are used at boot.

How did you measure LDO3? Also, did you find any pins for LDO4 besides
the AXP209 itelf? Mine seems to be covered in flux.

Michael


-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] [PATCH 1/3] sunxi: A20-OLinuXino-LIME2: Fix ldo3/ldo4 in DTS

2016-03-26 Thread Iain Paton 
Having reread the A20 datasheet yesterday, something in the back of my 
mind was bothering me overnight so I took some time to check this morning.

On the lime2 schematic we see the pins labeled as follows:

F19 : VCC_CSI0
E18 : VCC_CSI1

However the A20 datasheet doesn't label them this way, instead using:

F19 : VCC-PE : Port E Power Supply
E18 : VCC-PG : Port G Power Supply

no mention at all of CSI. CSI just happens to be a function that can be 
multiplexed onto ports E & G.

So lets assume for a moment we don't have a CSI device, or a CSI driver 
and are not using those pins for CSI functions but are instead using 
their default GPIO purpose, or in the case of PG perhaps for UART3 
or UART4.

What happens when you disable the regulator?  Hopefully from the above 
you'll already have worked out that you lose ports E & G when you turn 
their I/O power supply off and anything multiplexed onto those ports 
becomes unuseable.

I haven't checked other schematics, but all of the Olimex A10/A20 
boards along with Cubieboard & CubieTruck label these pins as VCC_CSIn
It would be my guess that there's a reference design being given to 
manufacturers, perhaps the original Cubieboard even, that makes this 
mistake and everyone else has blindly copied it.

So, unless we want to lose access to 24 GPIO pins for no real reason 
I'd suggest that the u-boot patch is reverted and/or the dts is altered 
such that the gpio driver claims the regulators and prevents them being 
turned off.

The u-boot commit message and reasoning given on list are trivially 
proved incorrect. Ports E & G are not CSI-only, losing all other 
functions on these ports is not acceptable.

I've also just tested building u-boot with LDO3 & 4 voltages set to 
3.3v to be the same as CubieBoard, this works for lime2.
So it's unlikely that the 2.8v & 2.3v settings from my previous patch 
make sense. The crash is actually being caused by something else, 
probably sequencing, due to unnecessarily turning the regulators off.
Whatever the reason, we don't have enough information in the 
datasheets to know for sure so we simply shouldn't turn them off to 
begin with.

The people behind this need to take responsibility and clean up their 
mess.

Iain

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] [PATCH 1/3] sunxi: A20-OLinuXino-LIME2: Fix ldo3/ldo4 in DTS

2016-03-25 Thread Iain Paton 
On 25/03/16 19:04, Michael Haas wrote:

> This patch implements the suggested changes. It is not enough
> to set the voltage to 280 to avoid the crash. Hence, I have
> also removed regulator-always-on.

NAK.

If setting both min and max to 280 isn't working then I'd suggest you're 
just papering over the issue and not actually solving it.

It should be fairly clear that whenever those regulators are turned on by 
some driver you're going to see the same issue, you've just delayed the 
problem by removing the regulator-always-on item.

The real problem here is people monkeying with the regulators without 
understanding what they're doing, bothering to test the results, or caring 
about the consequences.

Anyway, Hans was correct in that the datasheet we have access to says that 
the defaults for these regulators are undefined. 
I suspect that's not the whole story though, if these regulators had random 
values at powerup we'd have seen problems before now. 
Most likely the values we think we know are simply incorrect plus there's 
probably some element of sequencing involved - perhaps LDO4 needs turned on 
first. 
However I don't see sufficient detail in the datasheets to confirm any of 
that, so we shouldn't assume anything.
Electrically on the lime2 LDO3 goes to VCC-PE and LDO4 to VCC-PG. Neither 
groups E or G appear to be connected to anything other than gpio headers, 
so this has little to do with board design, it's something internal to 
the SoC that the datasheet is lacking on detail about.

One of the reasons for the regulator-always-on being in the dts was so that 
the regulator didn't get touched and so didn't break anything.

All said and done, it only takes a minute with a multimeter to determine 
actual defaults. Helpful to have multiple boards to gain some confidence 
that they behave the same, but still basing values like this on tiny 
sample sizes is probably unwise.

Looking at other A20 based boards, Cubieboards for example, shows LDO3/4 
being unused and the VCC-PE/PG pins they power on the lime2 being tied 
directly to 3.3v. No issues there simply because there's no way to mess 
with the power to those blocks.

The patch you really want is something like the one below which works 
on my boards regardless of the presence of regulator-always-on.
Verified on four boards with u-boot 2016.03 and kernel 4.5.0.

Whether you decide to remove regulator-always-on or not is a different 
question, but please use 2.3v, or some other proven working value, for 
ldo3. At least that way you have a fighting chance of the board 
remaining functional when something wants to turn the regulator on.

It's a good bet that the same u-boot change will have implications 
for other boards, if not now then at some future point.

Hans, take note, the schematic is wrong. You shouldn't assume either 
the schematic or you are correct. Ill considered changes to regulators 
can cause real damage to peoples boards.
I know we've discussed regulators before and that my opinion falls on 
deaf ears, but worth one last try..



Author: Iain Paton 
Date:   Fri Mar 25 22:07:55 2016 +

sunxi: A20-OLinuXino-LIME2: Update ldo3/ldo4 in DTS

A recent ill-considered u-boot change:

>commit 02cc27c74f9b884b538bcd1b93342a4c05b5d608
>Author: Hans de Goede 
>Date:   Sat Oct 3 15:29:24 2015 +0200
>
>sunxi: power: Change axp209 LDO3 and LDO4 default to disabled

causes the lime2 to lockup/crash when LDO3/4 are re-enabled by the
kernel.

The AXP209 datasheet shows the powerup values for these regulators 
to be undefined and the 2.8v suggested by the lime2 schematic also 
causes a lockup when the regulators are re-enabled so is obviously 
also incorrect.

Empirical measurement suggests LDO3 @ 2.3v and LDO4 @ 2.8v are the 
actual defaults, but is based on a small sample size. 

Verified to work with u-boot 2016.03, kernel 4.5.0 on four lime2 
boards.

Signed-off-by: Iain Paton 
---

diff --git a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts 
b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
index d5c796c..e665d22 100644
--- a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
+++ b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
@@ -140,14 +140,14 @@
};
 
vcc_csi0: ldo3 {
-   regulator-min-microvolt = <70>;
-   regulator-max-microvolt = <350>;
+   regulator-min-microvolt = <230>;
+   regulator-max-microvolt = <230>;
regulator-always-on;
};
 
vcc_csi1: ldo4 {
-   regulator-min-microvolt = <125>;
-   regulator-max-microvolt = <330>;
+   regulator-min-microvolt = <280>;
+   regulator-max-microvolt =