Jeff, That's correct that the refresh rate refers to the rate that the DDR controller will refresh the DDR. In self-refresh mode the DDR is refreshing itself.
Brad > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf > Of Jeff Cooper > Sent: Wednesday, September 24, 2008 9:08 AM > To: Sun, ChengHao > Cc: davinci-linux-open-source@linux.davincidsp.com > Subject: Re: Deep sleep on the DM355 > > Sun, > > I actually didn't look at the patch that closely. Since I was going to > use it on a DM355 and not on a DM644x that it was originally written > for, I just replaced the self-refresh code with what is correct for the > DM355. > > After reviewing it, I'd agree with you that there seems to be a bug, I > don't think this will enter self refresh mode. The SDRCR register is > at 0x2000 000c on both the DM644x and the DM355. So I don't see how > this code ever worked. The code I'm using to enter self-refresh on the > DM355 looks like: > > /** > * Switch DDR to self-refresh mode. > */ > enter_ddr_self_refresh: > ldr r0, SDRCR_ADDR > ldr r2, [r0] > > ldr r1, SDRCR_SR_PD_MASK > bic r2, r2, r1 @ Clear the SR_PD bit > > ldr r1, SDRCR_LPMODEN_MASK > orr r2, r2, r1 @ Set the LPMODEN bit > > str r2, [r0] > > bx lr @ return > > SDRCR_ADDR: .word DDR2_CTRL_VIRT + 0x0c > SDRCR_LPMODEN_MASK: .word 0x80000000 > SDRCR_MCLKSTOPEN_MASK: .word 0x40000000 > SDRCR_SR_PD_MASK: .word 0x00800000 > > I don't believe that the Refresh Rate is used in self-refresh mode. I > think that the DDR chip itself is handling the rate in that case. > Someone please correct me if I'm wrong. > > thanks, > Jeff > > Sun, ChengHao wrote: > > 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: davinci-linux-open-source@linux.davincidsp.com > > 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: davinci-linux-open-source@linux.davincidsp.com > >> 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 > >> Davinci-linux-open-source@linux.davincidsp.com > >> 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. > >> > >> > >> > > ------------------------------------------------------------------------ > > ----------------------------------------------- > > > >> > >> > > > > > > > > > _______________________________________________ > Davinci-linux-open-source mailing list > Davinci-linux-open-source@linux.davincidsp.com > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source _______________________________________________ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
