From: Andy Green on
On 03/11/10 15:42, Somebody in the thread at some point said:
> Andy Green wrote:
>
>> I saw very similar failures for a long time on our iMX31 based device.
>> Eventually I found a Freescale errata where the RAM inside the USB2
>> macrocell started to make single bit errors below 1.38V Vcore; ours was
>> 1.4V at that time but dipped on CPU load.
>
> Good tip. It seems that nobody ported driver for the voltage control
> chip ISL6271 from 2.4 kernel, and bootloader probably does not set
> correct values.
>
> Datasheet:
> http://www.penguin.cz/~utx/zaurus/datasheets/power/Xscale/ISL6271.pdf

Unless there's more to it in the way the zaurus using it that regulator
isn't programmable digitally.

Reading about your CF Card WLAN related issues they suck down a good
amount of power when their radio is up, I would definitely suggest
monitoring with a 'scope the various rails (Vcore, RAM and whatever it
is the CF Card is powered by) while putting it under load.

-Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Stanislav Brabec on
Andy Green wrote:
> On 03/11/10 15:42, Somebody in the thread at some point said:
> > Andy Green wrote:
> >
> >> I saw very similar failures for a long time on our iMX31 based device.
> >> Eventually I found a Freescale errata where the RAM inside the USB2
> >> macrocell started to make single bit errors below 1.38V Vcore; ours was
> >> 1.4V at that time but dipped on CPU load.
> >
> > Good tip. It seems that nobody ported driver for the voltage control
> > chip ISL6271 from 2.4 kernel, and bootloader probably does not set
> > correct values.

> Unless there's more to it in the way the zaurus using it that regulator
> isn't programmable digitally.

OOPS, I made a mistake and linked ISL6721 instead of ISL6271 there.
Now it is fixed:
http://www.penguin.cz/~utx/zaurus/datasheets/power/XScale/ISL6271A.pdf

This one has I2C. It is connected to GPIO 3 (PWR_SCL) and GPIO 4
(PWR_SDA).

It is visible between the black plastic and the large circular coil:
http://www.penguin.cz/~utx/zaurus/teardown#pcbt

> Reading about your CF Card WLAN related issues they suck down a good
> amount of power when their radio is up, I would definitely suggest
> monitoring with a 'scope the various rails (Vcore, RAM and whatever it
> is the CF Card is powered by) while putting it under load.

I guess that Zaurus has a good power design and that voltage should be
constant enough. CF has a dedicated step down (plus 2.8V power detector
(Why so low, if CF standard requres more?)), HDD has a dedicated step
up/down. USB has dedicated step up. Companion chips use dedicated 3.3V
step down. Audio uses dedicated linear regulator. CPU has several
dedicated step downs, CPU 3.3V uses step-up to 5V and then down to 3.3V
(which is shared only with IOPORT).

Nearest common point between CF card power and CPU power is the battery.


________________________________________________________________________

Stanislav Brabec
http://www.penguin.cz/~utx/zaurus


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Andy Green on
On 03/12/10 09:07, Somebody in the thread at some point said:

>> Unless there's more to it in the way the zaurus using it that regulator
>> isn't programmable digitally.
>
> OOPS, I made a mistake and linked ISL6721 instead of ISL6271 there.
> Now it is fixed:
> http://www.penguin.cz/~utx/zaurus/datasheets/power/XScale/ISL6271A.pdf
>
> This one has I2C. It is connected to GPIO 3 (PWR_SCL) and GPIO 4
> (PWR_SDA).

Thanks... that defaults to 1.3V on Vcore if you don't touch it. I guess
confirm on the CPU datasheet that it's OK for your selected CPU clock speed.

> I guess that Zaurus has a good power design and that voltage should be
> constant enough. CF has a dedicated step down (plus 2.8V power detector

In that case is the PXA CF driver PIO? Then it can be the same load on
Vcore issue in disguise.

-Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Stanislav Brabec on
Andy Green wrote:

> In that case is the PXA CF driver PIO? Then it can be the same load on
> Vcore issue in disguise.

There is a proprietary ASIC chip (Sharp Scoop) that handles CF and HDD
access (and also several additional GPIOs):
http://www.penguin.cz/~utx/zaurus/datasheets/ASIC_S1L50752B26B200/412752.PDF

The ASIC runs in dual power mode. HVDD is powered from the 3.3V
dedicated to CF resp. HDD power supply (both may be turned off by the
kernel), LVDD is shared with CPU 3.3V (it is always on).

It seems that there are no other chips connected to the VCC_PLL,
VCC_SRAM and VCC_CORE.

VCC_DRAM is the same 3.3V ans CPU ans ASIC LVDD and also the same as
flash power and flash driver CPLD:
http://www.penguin.cz/~utx/zaurus/datasheets/memory/


________________________________________________________________________
Stanislav Brabec
http://www.penguin.cz/~utx/zaurus

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Andy Green on
On 03/12/10 10:43, Somebody in the thread at some point said:
> Andy Green wrote:
>
>> In that case is the PXA CF driver PIO? Then it can be the same load on
>> Vcore issue in disguise.
>
> There is a proprietary ASIC chip (Sharp Scoop) that handles CF and HDD
> access (and also several additional GPIOs):
> http://www.penguin.cz/~utx/zaurus/datasheets/ASIC_S1L50752B26B200/412752.PDF

Right but not thinking about its power arrangements, rather the load on
the CPU itself when it's transferring data to / from CF interface (via
this ASIC).

If the ASIC has bus master DMA and that's used by the driver then fair
enough, otherwise if it is done by PIO in the driver "while using CF"
(as mentioned in most symptoms) becomes the same as saying "during 100%
load on CPU" which is what leads to dents in Vcore and potential
instability by that same Vcore path.

-Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/