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.
>
>
------------------------------------------------------------------------
-----------------------------------------------
>
--
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
CONFIDENTIALITY
This e-mail message and any attachments thereto, is intended only for use by
the addressee(s) named herein and may contain legally privileged and/or
confidential information. If you are not the intended recipient of this e-mail
message, you are hereby notified that any dissemination, distribution or
copying of this e-mail message, and any attachments thereto, is strictly
prohibited. If you have received this e-mail message in error, please
immediately notify the sender and permanently delete the original and any
copies of this email and any prints thereof.
ABSENT AN EXPRESS STATEMENT TO THE CONTRARY HEREINABOVE, THIS E-MAIL IS NOT
INTENDED AS A SUBSTITUTE FOR A WRITING. Notwithstanding the Uniform Electronic
Transactions Act or the applicability of any other law of similar substance and
effect, absent an express statement to the contrary hereinabove, this e-mail
message its contents, and any attachments hereto are not intended to represent
an offer or acceptance to enter into a contract and are not otherwise intended
to bind the sender, Sanmina-SCI Corporation (or any of its subsidiaries), or
any other person or entity.
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
