Hi Jeff,
I reviewed the code and some confused about some operation,
In patches:
+ /* Switch SDRAM to selfrefresh */
+ ldr r0, ddr2_ctrl_base
+ ldr r1, self_refresh
+ ldr r2, [r0]
+ orr r2, r2, r1
+ str r2, [r0]
...
+ddr2_ctrl_base:
+ .word DDR2_CTRL_VIRT
+self_refresh:
+ .word 0x80000000
...
+#define DDR2_CTRL_PHYS DAVINCI_DDR2_CTRL_BASE /* 0x20000000 */
+#define DDR2_CTRL_VIRT 0xfeb00000
+#define DDR2_CTRL_SIZE SZ_1M
...
+ {
+ .virtual = DDR2_CTRL_VIRT,
+ .pfn = __phys_to_pfn(DDR2_CTRL_PHYS),
+ .length = DDR2_CTRL_SIZE,
+ .type = MT_DEVICE
+ },
...
Can I say, the code try to write 0x80000000 into 0x20000000 to make DDR
into self refresh mode?
But refer the tms320dm6446.pdf Table 6-36. DDR2 Memory Controller
Registers
in http://focus.ti.com/lit/ds/symlink/tms320dm6446.pdf and the Table 23.
SDRAM Refresh Control Register (SDRCR) Field Descriptions in
TMS320DM644x DMSoC DDR2 Memory Controller User's Guide in
http://focus.ti.com.cn/cn/lit/ug/sprue22c/sprue22c.pdf,
We should write control word to 0x2000 000C,
And one more issue I am not sure: the control word need also include
Refresh rate for self refresh mode or not? Means should write 0x8000xxxx
to 0x2000000C to make it refresh, right?
Best Regards
Sun
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Jeff Cooper
Sent: Friday, September 12, 2008 1:27 AM
To: Deepak Shankar-TLS,Chennai.
Cc: [email protected]
Subject: Re: Deep sleep on the DM355
Deepak,
I've modified the LSP 1.20 source tree to add in this patch:
http://www.mail-archive.com/[EMAIL PROTECTED]
om/msg04407.html
Since it's for the git tree, it didn't apply, but it gave me enough info
to get similar support on the 1.20 source tree.
Part of being about to go into deep sleep is to put your DDR into
self-refresh mode. The only place you can do that is while you're
running out of TCM. Part of the patch creates sleep.S which are some
ASM routines that get copied into TCM. When you want to suspend, you
jump to the routine in TCM and then it's safe to shut down the DDR.
After I've shut down the DDR, then I send a I2C command to an external
processor (an MSP430) in my case to tell it I'm ready to sleep and to
drop the GIO0 line. My ASM code looks like:
/* Inform the MSP that we're going into deep sleep */
ldr r0, MSP_I2C_ADDRESS
adr r1, MSP_CMD_SLEEP @ load r1 with the address of
MSP_CMD_SLEEP
ldr r2, MSP_CMD_SLEEP_BYTES
bl i2c_send_data
/* Enter deep sleep */
ldr r0, SYS_DEEPSLEEP_ADDR
ldr r2, [r0] @ load the contents of
the deepsleep reg
ldr r1, SYS_DEEPSLEEP_ENABLE_MASK
orr r2, r2, r1 @ set the enable bit
str r2, [r0]
ldr r1, SYS_DEEPSLEEP_COMPLETE_MASK
sleep_complete:
ldr r2, [r0] @ load the deep sleep
reg
ands r2, r2, r1 @ test if the complete
bit is set
beq sleep_complete @ if it's not 1, keep
waiting
ldr r1, SYS_DEEPSLEEP_ENABLE_MASK
bic r2, r2, r1 @ clear the enable bit
str r2, [r0]
What do you mean by 'cutdown the core-clock'? I'm not changing my clock
rate at all. My understanding is that deep sleep mode shuts down all
clocks and that that wouldn't have any effect.
What section of SPRUFB3 (I assume that's the one you mean, I can't find
SPRUB3), are you quoting from?
thanks,
Jeff
Deepak Shankar-TLS,Chennai. wrote:
I'm also working on this but have not succeeded to take the system to
sleep yet.
Could you please tell me if you just set the GIO000 to low to take it
to
sleep?
However regarding the other peripherals it looks like we have to
disable
the outputs of PSC entirely.
Have you also cutdown the core-clock?
The SPRUB3 mentions
"To reduce the chip stand by power, it is advised to power down all
the
analog blocks (PLL cores, DDR
PHY DLL, DDR PHY, USB PHY, Video DAC, and CCP PHY). "
-----Original Message-----
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
p.com] On Behalf Of Jeff Cooper
Sent: Thursday, September 11, 2008 8:39 PM
To: [email protected]
Subject: Deep sleep on the DM355
I'm trying to enable deep sleep on a DM355 and I'd like to know if
anyone else has done that?
I think that I've been able to enter and exit deep sleep mode
successfully as I see the power draw on my system drop from 650 mW
down
to 190 mW when I'm in deep sleep.
There's very little hard information on how much power the DM355
should
draw in deep sleep mode. I've found a Power Point presentation on the
net at:
http://www.arrownac.com/manufacturers/texas-instruments/npi/products/dm3
55/davinci-dm355.ppt
that states that the power consumption should be less that 5 mW while
it's in deep sleep.
I've also found a FAQ from TI that states that it should be approx 1
mW:
http://focus.ti.com.cn/cn/lit/ml/sprv063a/sprv063a.pdf
Assuming that the DM355 is in deep sleep mode and is really drawing
around 5 mW, when I add in the maximum power draw from the other major
components on my system, I'm still pretty far away from from what I'd
expect the system to be drawing.
The documentation in the Arm Subsystems User Guide (SPRUFB3) section
12.5.1 states:
The transition of GIO0 from high to low creates a clock pulse
advancing the Deep Sleep state machine. After this transition, all
clocks are stopped and then the internal oscillators are powered down.
I may be misunderstanding that statement, but I took it to mean that
the
system is in it's lowest power state at that point. I suspect that
that
may not be entirely true. I found that the VPSS oscillator, OTG
analog
block and USB PHY are still powered on. Turning those off saves about
12 mW.
I suspect that other areas of the DM355 are still drawing power. Does
anyone know of other areas of the chip that should be powered off
separately prior to entering deep sleep?
I've tried turning off the VPSS_Master and VPSS_Slave using the PSC
controller, but that didn't have any noticeable effect.
Does the PSC have any effect on power consumption when the system is
in
deep sleep mode?
Does anyone know if the DSP side goes to sleep when you enter deep
sleep?
I've also noticed that the amount of power that the system consumes
can
very quite a bit between various deep sleeps. Using a software load
that boots the kernel and puts the system to sleep, I've seen as much
as
31 mW variance between boots once the system has entered deep sleep.
I've yet to figure that one out.
Any ideas on things to try or look into would be appreciated.
thanks,
Jeff
--
Jeff Cooper // senior embedded software engineer
LOGIC // engineering design services
411 Washington Ave. N. Suite 400
Minneapolis, MN 55401
T // 612.436.5176
F // 612.672.9489
[EMAIL PROTECTED]
www.logicpd.com
/ / / / / / / / / / / / / / / / / / / / / / / / / / / /
This message (including any attachments) contains confidential
information intended for a specific individual and purpose, and is
protected by law. If you are not the intended recipient, you should
delete this message and are hereby notified that any disclosure,
copying, distribution, or other use of this message, or the taking of
any action based on it, is strictly prohibited.
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
DISCLAIMER:
------------------------------------------------------------------------
-----------------------------------------------
The contents of this e-mail and any attachment(s) are confidential and
intended for the named recipient(s) only.
It shall not attach any liability on the originator or HCL or its
affiliates. Any views or opinions presented in
this email are solely those of the author and may not necessarily
reflect the opinions of HCL or its affiliates.
Any form of reproduction, dissemination, copying, disclosure,
modification, distribution and / or publication of
this message without the prior written consent of the author of this
e-mail is strictly prohibited. If you have
received this email in error please delete it and notify the sender
immediately. Before opening any mail and
attachments please check them for viruses and defect.
------------------------------------------------------------------------
-----------------------------------------------
