PMU cleanup

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

PMU cleanup

AlvieBoy
Hi,

Besides all "cleanup" issues we discussed about PMU, I think we might go a bit farther. I also found some "inconsistencies".

* GSM_ON is a global label, but only used inside PMU. We should switch to a local label, and maybe move R1729 near U1703.

* nGSM_OC is not used any more ? It was connected to EINT19, but due to ECN0001, we are using this GPIO for board revision check. What was the purpose of this
signal ?

* LDO4, LDO5 and LDO6 have buffer caps (4u7), but LDO1 and LDO2 do not. Any particular reason ?

Álvaro

_______________________________________________
gta02-core mailing list
[hidden email]
https://lists.openmoko.org/mailman/listinfo/gta02-core
Reply | Threaded
Open this post in threaded view
|

Re: PMU cleanup

Werner Almesberger
?lvaro Lopes wrote:
> * GSM_ON is a global label, but only used inside PMU. We should switch
> to a local label, and maybe move R1729 near U1703.

Sounds good.

> * nGSM_OC is not used any more ? It was connected to EINT19, but due to
> ECN0001, we are using this GPIO for board revision check. What was the
> purpose of this signal ?

Hmm, that change doesn't look so good. Spending EINTs on the board
revision sounds like a horrible waste to me. (Ah, another task for
the MPU: record the board revision :)

nGSM_OC basically tells us that the power switch has current-limited
the modem. This is an abnormal condition, that should never occur. If
it does, there's either a hardware defect or a design flaw.

So it's not a signal we strictly need. However, since we have it, we
may as well connect it. If there's modem trouble, it may help to
rule out some failure scenarios.

Now, with the GE865, the whole arrangement may have to change, but we
have to find out about the current requirements on each rail. The
GE865 has separate power inputs for the baseband processor and the RF
amplifier, just like our Calypso circuit does, so it may be possible
to use the same concept.

- Werner

_______________________________________________
gta02-core mailing list
[hidden email]
https://lists.openmoko.org/mailman/listinfo/gta02-core
Reply | Threaded
Open this post in threaded view
|

Re: PMU cleanup

Werner Almesberger
I wrote:
> Now, with the GE865, the whole arrangement may have to change, but we
> have to find out about the current requirements on each rail. The
> GE865 has separate power inputs for the baseband processor and the RF
> amplifier, just like our Calypso circuit does, so it may be possible
> to use the same concept.

I'm writing down that question for Telit, and the more I write, the
less I like that part.

The idea of cutting power to the side that has the oscillators while
leaving the side that actually puts things on the air has its merits,
but it also has great potential for unintended consequences, such as
the RF amplifier picking up EMI and sending that, or a sneak current
crawling back into the baseband and making it do *something*.

The GE865 has a feedback mechanism that tells us if it's powered up
or down (PWRMON), so we should have considerably better control over
the modem's state than with the Calypso, even without such a switch.

- Werner

_______________________________________________
gta02-core mailing list
[hidden email]
https://lists.openmoko.org/mailman/listinfo/gta02-core
Reply | Threaded
Open this post in threaded view
|

Wasting valuable pins (Was: PMU cleanup)

Rask Ingemann Lambertsen-2
In reply to this post by Werner Almesberger
On Wed, Aug 19, 2009 at 03:24:53PM -0300, Werner Almesberger wrote:
> ?lvaro Lopes wrote:
>
> > * nGSM_OC is not used any more ? It was connected to EINT19, but due to
> > ECN0001, we are using this GPIO for board revision check. What was the
> > purpose of this signal ?
>
> Hmm, that change doesn't look so good. Spending EINTs on the board
> revision sounds like a horrible waste to me.

   I agree, and we have more cases where pins with relatively valueable
special functions are used for simple GPIO when less valueable pins could
have been used instead. Other such examples are the DMA interface and the
camera port. We've had no GPIO allocation strategy to inherit from the GTA02
and now that the abundance of unused GPIO on the LCD interface has gone,
we're beginning to suffer from it.

> (Ah, another task for the MPU: record the board revision :)

   Or we could have a serial/I2C EEPROM. It would allow much more fine
grained board revision information, and as hardware fixed are applied (or
hardware bugs are discovered - think bogus GTA02 earpiece capacitors), you
could update the EEPROM to reflect the state of the board.

> So it's not a signal we strictly need. However, since we have it, we
> may as well connect it. If there's modem trouble, it may help to
> rule out some failure scenarios.

   But nGSM_OC is a bit like MODEM_RST and BT_PIO_5: It's allocated to a
GPIO but is not used by the kernel[1] and two years after Neo 1973 release,
still nobody misses it. So I think of losing nGSM_OC as a cleanup, even if
it was probably not intentional. Another signal that can go is nACCEL_CS now
that we have only one accelerometer.

[1] $ grep -E -e 'GTA.*(MODEM_RST|GSM_OC|PIO5)' --recursive *
arch/arm/mach-s3c2410/include/mach/gta01.h:#define GTA01_GPIO_MODEM_RST S3C2410_GPB6
arch/arm/mach-s3c2442/include/mach/gta02.h:#define GTA02_GPIO_MODEM_RST S3C2410_GPB5
arch/arm/mach-s3c2442/include/mach/gta02.h:#define GTA02_GPIO_PIO5 S3C2410_GPC5 /* v3 + v4 only */
arch/arm/mach-s3c2442/include/mach/gta02.h:#define GTA02v3_GPIO_nGSM_OC S3C2410_GPG11 /* v3 + v4 only */
arch/arm/mach-s3c2442/include/mach/gta02.h:#define GTA02v3_IRQ_nGSM_OC IRQ_EINT19 /* v3 + v4 only */

--
Rask Ingemann Lambertsen
Danish law requires addresses in e-mail to be logged and stored for a year

_______________________________________________
gta02-core mailing list
[hidden email]
https://lists.openmoko.org/mailman/listinfo/gta02-core
Reply | Threaded
Open this post in threaded view
|

Re: Wasting valuable pins (Was: PMU cleanup)

Werner Almesberger
Rask Ingemann Lambertsen wrote:
> Other such examples are the DMA interface and the camera port.

I know that you like the camera port :-) But a good use for the DMA
interface is new to me. What would you do with it, considering that
all the address and data lines are buried somewhere in the PCB ?

>> (Ah, another task for the MPU: record the board revision :)
>
>    Or we could have a serial/I2C EEPROM. It would allow much more fine
> grained board revision information, and as hardware fixed are applied (or
> hardware bugs are discovered - think bogus GTA02 earpiece capacitors), you
> could update the EEPROM to reflect the state of the board.

Oh, but the MPU could do that too. There's plenty of space left in
it to record extensive feature/bug lists :)

Anyway, that's something for after gta02-core. We already have a
lot more changes that I expected. Each change increases the risk
of gta02-core suffering some fatal flaw that will cripple it, and
that would be a really sad outcome.

>    But nGSM_OC is a bit like MODEM_RST and BT_PIO_5: It's allocated to a
> GPIO but is not used by the kernel[1] and two years after Neo 1973 release,
> still nobody misses it.

I also realize that nobody actually bothered to look if it was ever
asserted. Who knows, maybe the modem does go into overcurrent from
time to time, and we all think it's just a bit "unstable" ...

By the way, MODEM_RST is used for a reliable reflashing procedure.
The problem with it is that there were once issues with uncommanded
activation of these modem controls and the reset circuit was
therefore removed from some boards. Thus, you can't rely on it to
be present.

> Another signal that can go is nACCEL_CS now
> that we have only one accelerometer.

Very good point ! I've added it to ECN0016. If nobody can think of a
reason why we'd want to keep nACCEL_CS, I'll do the killing later
today.

- Werner

_______________________________________________
gta02-core mailing list
[hidden email]
https://lists.openmoko.org/mailman/listinfo/gta02-core
Reply | Threaded
Open this post in threaded view
|

Re: Wasting valuable pins (Was: PMU cleanup)

Rask Ingemann Lambertsen-2
On Tue, Aug 25, 2009 at 09:02:15AM -0300, Werner Almesberger wrote:
> Rask Ingemann Lambertsen wrote:
> > Other such examples are the DMA interface and the camera port.
>
> I know that you like the camera port :-) But a good use for the DMA
> interface is new to me. What would you do with it, considering that
> all the address and data lines are buried somewhere in the PCB ?

   You can read/write the GPIO ports so as to have an efficient means of
getting data into or out of the device. We should have at least one
nXDREQ/nXDACK pair available at test points or the debug connector for
syncronisation with an external device. But you need to have the GPIOs in
the same GPIO port and byte aligned to make use of the DMA interface, not
scattered everywhere as in GTA02.

   One possible use would be a 13-bit logic analyzer, using GPIO port J
(camera port). You could sync with nXDREQ, clock from internal clock sources
or from TCLK0/GPB4 (which I'll route to the debug connector as a substitute
for CAMDAT4/GPJ4).

--
Rask Ingemann Lambertsen
Danish law requires addresses in e-mail to be logged and stored for a year

_______________________________________________
gta02-core mailing list
[hidden email]
https://lists.openmoko.org/mailman/listinfo/gta02-core
Reply | Threaded
Open this post in threaded view
|

Re: Wasting valuable pins (Was: PMU cleanup)

Werner Almesberger
Rask Ingemann Lambertsen wrote:
> syncronisation with an external device. But you need to have the GPIOs in
> the same GPIO port and byte aligned to make use of the DMA interface, not
> scattered everywhere as in GTA02.

Okay, now I understand what you're after. Thanks ! It's an interesting
idea to keep in mind for future devices, when the entire debug interface
will have to be redesigned anyway.

To make sure it doesn't get lost, could you perhaps write an ECN that
we could then file with status "Defer" ?

- Werner

_______________________________________________
gta02-core mailing list
[hidden email]
https://lists.openmoko.org/mailman/listinfo/gta02-core