| Message ID | 56F5DEB9.7070207@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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
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@01c00000/1c2ac00.i2c/i2c-0/0-0034/axp20x-pek/input/input0 [ 96.971734] ldo4: failed to apply 3300000uV 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
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@01c00000/1c2ac00.i2c/i2c-0/0-0034/axp20x-pek/input/input0 > [ 96.971734] ldo4: failed to apply 3300000uV 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
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
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 = <700000>; - regulator-max-microvolt = <3500000>; + regulator-min-microvolt = <2300000>; + regulator-max-microvolt = <2300000>; regulator-always-on; }; vcc_csi1: ldo4 { - regulator-min-microvolt = <1250000>; - regulator-max-microvolt = <3300000>; + regulator-min-microvolt = <2800000>; + regulator-max-microvolt = <2800000>; regulator-always-on; };