Re: pxa270, nBATT_FAULT and disabling the platform i2c-1 driver

[Aleksandr Koltsoff <czr@xxxxxx>]

Jeff Sutherland wrote:
> On Tuesday 03 March 2009, Aleksandr Koltsoff wrote:
>> Jeff Sutherland wrote:
>>> On Friday 27 February 2009, Aleksandr Koltsoff wrote:
>>>> First off, the question:
>>>> Is it detrimental to continue running the PXA270 with the following
>>>> settings:
>>>>   Initially PMCR==0x15, then nBATT_FAULT goes down and PMCR is at 0x3d.
>>>>   (0x15==Instead of entering deep-sleep on the fault signals, cause an
>>>> interrupt, aka BIDAE+VIDAE+IAS).
>> It must've been a bad morning. If one decodes the 0x3d, one sees that it
>> was actually nVDD_FAULT, not nBATT_FAULT. However, the effects are the
>> same on the pxa270, although the wiring from the TPS is somewhat
>> different (looking at the example schema from the TPS datasheet).
> 
> OIC, well that makes all the difference in the world then ;-)  nVDD_FAULT is 
> recoverable if you set up PCMR as below and simply generate an interrupt on a 
> VDD_FAULT, but you need to handle the interrupt though.  But it might be 
> better to simply disable the INT# output from the TPS65020 for now.  See my 
> closing comments below.

Ah, thanks for the clarification. I re-read the schema for the
recommended TPS connection and the vddfault is indeed fed by the INT#.
To cut a long story short, masking off the INT wasn't too successful.
Even with MASK (reg 02) set to zero (other regs at defaults), we still
get the vddfault (since the i2c-1 is enabled to talk to the TPS, I get
the 'spurious irq'-loop now, but that was to be expected).

Now this is somewhat odd. OTOH I'd expect the TPS to behave badly when
the power event happens, but after resetting the PXA270 I'm dumping the
TPS registers and they still seem all intact, so the TPS registers at
least survive.

As for the power source not being beefy enough, I think I can rule that
one out since I can repeat the same effect with various lab powers. I'll
have to talk with our HW people though before drawing final conclusions.

> The way the TPS65020 is set up, you should never get a nVDD_FAULT in a running 
> system even on a low battery condition, and it has nothing to do with the 
> resistor network that programs low batt and power fail settings.  It looks 
> like you have a system problem where one of the switching supplies of the 
> TPS65020 is getting overloaded, or else, since you mention you are not 
> running off of a battery, it is a case of 'wimpy power supply syndrome'.  The 
> TPS65020 should be getting fed by a 4.2V supply that can supply a couple amps 
> if it has to.  Check leads and input bypassing.  Also beware that this little 
> bugger is nice for small systems, but that it doesn't have a whole lot of 
> power left over once it gets done supplying VCC_CORE, VCC_MEM, and some 3.3V 
> or 3.0V for IO.  Sounds to me like it might be getting overloaded...

>From our tests we've noticed the following things that will make the
power event more frequent:
* Using the UARTs. Higher speed == more frequent power events. More
simultanous UARTs used == more frequent power events.
* Using the SD and USB isn't as significant contributor to power events,
which is somewhat counter-logical, but they do have a small effect.
* Sometimes it only takes an incoming SSH connection to push the system
over the limit, but I guess this just the ethernet chip drawing some
extra juice.

By lowering the operating freq for the core and bus (using cpufreq), the
 power event frequency is also lowered (we didn't change the TPS
settings in step with cpufreq, TPS was always running with default
settings, although we did try to change the FFPWM vs PWM/PFM modes, but
that didn't have any effect).

So in combination, it certainly looks like something is drawing too much
power, the odd thing being that irrespective of which power source we
use, the effects persist.

Thanks again for the answer Jeff, really appreciated. We've been trying
to track the core issue down for past months (on and off), and short of
making our own PXA270 boards (or using the horrible "disable power i2c
bus and set PMCR to 0x15) I'm running out of options. And seems that
we're the only people using Colibri that have run across the issue,
although I find it somewhat amusing that Toradex suggests setting the
PMCR to 0x15 as well because "some customers have had issues".

Best regards,

ak.

-------------------------------------------------------------------
List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm
FAQ:        http://www.arm.linux.org.uk/mailinglists/faq.php
Etiquette:  http://www.arm.linux.org.uk/mailinglists/etiquette.php