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

[Aleksandr Koltsoff <czr@xxxxxx>]

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).

>> We are currently using a work around the problem:
>> 1) Set PMCR to 0x15 at the earliest moment (currently in init, but I
>> plan to move this to uboot at some point).
>> 2) Disable the power i2c driver from the platform driver. This will
>> disable the irq handler from ever launching, even when the nBATT_FAULT
>> condition occurs. This also forces me to change the pxa27x.c, which I'd
>> rather not do, but currently it doesn't offer any way of disabling i2c-1
>>  (other than disabling i2c completely, but we need i2c-0). Ideally, we'd
>> like to use i2c-1 at some point to access the TPS, but we can live
>> without it for now.
> 
> The nBATT_FAULT signal sounds like it might be mis-applied here or there could 
> be a configuration problem with the power fail and low batt sense pins of the 
> TPS65020.  If you don't have access to the hardware and no way to fix the 
> problem there you could be stuffed.  The default settings of the TPS65020 
> should be fine if you are not doing voltage scaling, so no need for power 
> I2C.  Low batt and power fail interrupts are masked off by default so you 
> will not get a nVDD_FAULT assertion when the system enters low battery.  If 
> however any of the regulators have a problem that will generate a nVDD_FAULT 
> signal.
> 
> The TPS65020 PWRFAIL# pin should be connected to PXA's nBATT_FAULT pin, and 
> voltage resistors on the 65020 should be set to assert it when the input 
> voltage drops below the worst case low battery voltage, usually around 2.8V 
> for a single lithium ion cell.  If the battery voltage has got this low and 
> you are still running as if all systems are normal then you've got problems 
> elsewhere, most everything else in the system is going to start falling over 
> below 3.0V.  An orderly shutdown should have begun after the 65020 asserted 
> its LOWBATT# pin.  nBATT_FAULT is fatal regardless of PCMR settings in the 
> PXA.  It either causes immediate entry into deep sleep, or an imprecise data 
> abort which you must install a handler for.  The only purpose for the handler 
> is to do emergency cleanup (shutting down all peripheral power for example) 
> then drop the processor into sleep mode.  There is no exit from this state 
> other than hardware reset, it is fatal.  You cannot simply install an 
> interrupt handler and go merrily along afterwards.  (Well, OK, if nBATT_FAULT 
> merely glitched it should be possible to recover if an abort handler is 
> provided, but this points to other system problems.)
> 
> With a running system, nBATT_FAULT is the last line of defense, the absolute 
> last thing that should ever happen as input power drains away.  For a 
> suspended or sleeping system, nBATT_FAULT asserted prevents the system from 
> starting as it indicates there's not enough power available to run normally.

Thanks for the detailed response Jeff. However, my boards (which are
under constant test bench variable current loads) seem to survive the
condition just fine.

Note that the IAS bit is set in my case in the PCMR. This turns the
"imprecise data abort" into an interrupt. When IAS is set to zero
(default), the kernel will indeed abort. I'll get a nice "kernel oops
inside an irq handler", mostly from pxa_serial (seems that the serial is
most likely trigger the problem in the CPU board that we're using).

So, once we've changed IAS to 1, it won't cause an abort at all, but
instead signal an interrupt to the pxa core. Since we've disabled the
power-i2c support from the platform driver, the interrupt will stay
asserted (reflected in PMCR and it cannot be reset, even if attempt to
do it according to pxa datasheet) but will never have any effect since
the IRQ has been disabled from the IRQ controller.

So, as long as PMCR is set to 0x15 prior to the power event, and as long
as we don't enable the platform power-i2c support, the system survives
quite nicely all of the power events. The CPU operation doesn't seem to
be affected by this condition (no excess CPU load/interrupts, since
they're disabled at the irq-controller in this case).

As a side note, I'm assuming that the CPU board supplier is using a very
similar schema for the TPS as the example one in the TPS datasheet
("typical configuration for the intel bulverde processor") wrt the
PWRFAIL_SNS and LOWBAT_SNS, since we're running from one power supply
(we don't use batteries). We managed to locate the two resistors which
divide the Vcc going into these two inputs and by removing one of them,
we can reduce the frequency of the failure event. It still does occur
however, but instead of occuring within 5-15 seconds, it does this once
per week or two. Either the Vcc input to PWRFAIL_SNS or the two outputs
from the TPS are coupling with something (my guess, but can't really do
anything about it).

Granted, this is far from the situation where we'd like to be. The
question still is whether running the PXA270 in this situation is a sane
thing to do. The datasheet doesn't really say how the CPU will behave in
this case and is rather vague.

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