RE: Suspend/Resume support with Omap2fb
On Fri, 2009-03-13 at 10:17 +0100, ext Hiremath, Vaibhav wrote: > > > > Hi, > > > > > > > > On Thu, 2009-03-12 at 19:26 +0100, ext Hiremath, Vaibhav wrote: > > > > > Hi, > > > > > > > > > > Finally I could able to find the root-cause, actually some of > > the > > > > previous observations miss-led me to dig into power management, > > > > suspend/resume path and clock structure. But after bit debugging > > and > > > > with the help of Sanjeev, we got the rid of it. > > > > > > > > > > The issue is with DSS2 library, inside function > > > > "dpi_display_suspend". It calls dispc_enable_lcd_out(0), but > > doesn't > > > > wait till the frame-done interrupt. And due to this I was > > getting > > > > some abrupt behavior in suspend/resume path. > > > > > Actually in the beginning I overlooked legacy frame-buffer > > driver, > > > > which handles this scenario perfectly. > > > > > > > > dispc_enable_lcd_out(0) waits for FRAMEDONE. Please use the > > latest > > > > DSS2 > > > > version from my git repository =). > > > > > > > [Hiremath, Vaibhav] Ohhh great, but I think yesterday only I > > pulled changes from your repository, and it was not there. > > > > > > Ok, but it's great that you merged the change. > > > > No, it's been there for quite a while... (weeks, months, I don't > > remember). > > > [Hiremath, Vaibhav] May be I looked into wrong branch, can you please provide > in which branch of yours the change is? So that I can validate my changes and > make it more close to yours, it will be easy for me to migrate in the future. All the latest DSS2 stuff is in the master branch. Tomi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Suspend/Resume support with Omap2fb
Thanks, Vaibhav Hiremath > -Original Message- > From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com] > Sent: Friday, March 13, 2009 2:44 PM > To: Hiremath, Vaibhav > Cc: linux-omap@vger.kernel.org > Subject: RE: Suspend/Resume support with Omap2fb > > On Fri, 2009-03-13 at 10:10 +0100, ext Hiremath, Vaibhav wrote: > > > > Thanks, > > Vaibhav Hiremath > > > > > -Original Message- > > > From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com] > > > Sent: Friday, March 13, 2009 2:01 PM > > > To: Hiremath, Vaibhav > > > Cc: linux-omap@vger.kernel.org > > > Subject: RE: Suspend/Resume support with Omap2fb > > > > > > Hi, > > > > > > On Thu, 2009-03-12 at 19:26 +0100, ext Hiremath, Vaibhav wrote: > > > > Hi, > > > > > > > > Finally I could able to find the root-cause, actually some of > the > > > previous observations miss-led me to dig into power management, > > > suspend/resume path and clock structure. But after bit debugging > and > > > with the help of Sanjeev, we got the rid of it. > > > > > > > > The issue is with DSS2 library, inside function > > > "dpi_display_suspend". It calls dispc_enable_lcd_out(0), but > doesn't > > > wait till the frame-done interrupt. And due to this I was > getting > > > some abrupt behavior in suspend/resume path. > > > > Actually in the beginning I overlooked legacy frame-buffer > driver, > > > which handles this scenario perfectly. > > > > > > dispc_enable_lcd_out(0) waits for FRAMEDONE. Please use the > latest > > > DSS2 > > > version from my git repository =). > > > > > [Hiremath, Vaibhav] Ohhh great, but I think yesterday only I > pulled changes from your repository, and it was not there. > > > > Ok, but it's great that you merged the change. > > No, it's been there for quite a while... (weeks, months, I don't > remember). > [Hiremath, Vaibhav] May be I looked into wrong branch, can you please provide in which branch of yours the change is? So that I can validate my changes and make it more close to yours, it will be easy for me to migrate in the future. > Tomi > > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Suspend/Resume support with Omap2fb
On Fri, 2009-03-13 at 10:10 +0100, ext Hiremath, Vaibhav wrote: > > Thanks, > Vaibhav Hiremath > > > -Original Message- > > From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com] > > Sent: Friday, March 13, 2009 2:01 PM > > To: Hiremath, Vaibhav > > Cc: linux-omap@vger.kernel.org > > Subject: RE: Suspend/Resume support with Omap2fb > > > > Hi, > > > > On Thu, 2009-03-12 at 19:26 +0100, ext Hiremath, Vaibhav wrote: > > > Hi, > > > > > > Finally I could able to find the root-cause, actually some of the > > previous observations miss-led me to dig into power management, > > suspend/resume path and clock structure. But after bit debugging and > > with the help of Sanjeev, we got the rid of it. > > > > > > The issue is with DSS2 library, inside function > > "dpi_display_suspend". It calls dispc_enable_lcd_out(0), but doesn't > > wait till the frame-done interrupt. And due to this I was getting > > some abrupt behavior in suspend/resume path. > > > Actually in the beginning I overlooked legacy frame-buffer driver, > > which handles this scenario perfectly. > > > > dispc_enable_lcd_out(0) waits for FRAMEDONE. Please use the latest > > DSS2 > > version from my git repository =). > > > [Hiremath, Vaibhav] Ohhh great, but I think yesterday only I pulled changes > from your repository, and it was not there. > > Ok, but it's great that you merged the change. No, it's been there for quite a while... (weeks, months, I don't remember). Tomi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Suspend/Resume support with Omap2fb
Thanks,
Vaibhav Hiremath
> -Original Message-
> From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com]
> Sent: Friday, March 13, 2009 2:01 PM
> To: Hiremath, Vaibhav
> Cc: linux-omap@vger.kernel.org
> Subject: RE: Suspend/Resume support with Omap2fb
>
> Hi,
>
> On Thu, 2009-03-12 at 19:26 +0100, ext Hiremath, Vaibhav wrote:
> > Hi,
> >
> > Finally I could able to find the root-cause, actually some of the
> previous observations miss-led me to dig into power management,
> suspend/resume path and clock structure. But after bit debugging and
> with the help of Sanjeev, we got the rid of it.
> >
> > The issue is with DSS2 library, inside function
> "dpi_display_suspend". It calls dispc_enable_lcd_out(0), but doesn't
> wait till the frame-done interrupt. And due to this I was getting
> some abrupt behavior in suspend/resume path.
> > Actually in the beginning I overlooked legacy frame-buffer driver,
> which handles this scenario perfectly.
>
> dispc_enable_lcd_out(0) waits for FRAMEDONE. Please use the latest
> DSS2
> version from my git repository =).
>
[Hiremath, Vaibhav] Ohhh great, but I think yesterday only I pulled changes
from your repository, and it was not there.
Ok, but it's great that you merged the change.
> Tomi
>
> >
> > For Display sub-system we have 2 interface clocks coming, L3_ICLK
> and L4_ICLK. Out of these, L4_ICLK goes to Display register access
> and L3_ICLK goes to DMA register. In our suspend call we are
> disabling clocks for L3_ICLK (we don't control L4_ICLK), and due to
> this L4_ICLK stays attached with GFX. You will only be able to find
> out this by looking to CM_CLKSTST_DSS.CLKACTIVITY_DSS, which is set
> 1 and indicates some interface clock is still active in DSS domain.
> >
> > Below is the patch which will explain the change
> >
> >
> > +#include
> > +#include
> >
> > +static void dpi_display_isr(void *arg, unsigned int irqstatus)
> > +{
> > + struct omap_display *display = (struct omap_display *)arg;
> > +
> > + complete(&display->frame_done);
> > +}
> >
> > static int dpi_display_suspend(struct omap_display *display)
> > {
> > + void *handle = NULL;
> > +
> > if (display->state != OMAP_DSS_DISPLAY_ACTIVE)
> > return -EINVAL;
> >
> > if (display->panel->suspend)
> > display->panel->suspend(display);
> >
> > + /*
> > +* Wait for frame done interrupt
> > +*/
> > + handle = omap_dispc_register_isr(dpi_display_isr, display,
> > + DISPC_IRQ_FRAMEDONE);
> > + if (!handle)
> > + return -EINVAL;
> > +
> > + init_completion(&display->frame_done);
> > +
> > dispc_enable_lcd_out(0);
> > + if (!wait_for_completion_timeout(&display->frame_done,
> > + msecs_to_jiffies(500))) {
> > + printk("timeout waiting for FRAME DONE\n");
> > + }
> >
> > Still I need to test this thoroughly, I may hit some another issue
> (Already I am seeing some crashes also when off state is enabled). I
> will create consolidated patch for this and will submit to list.
> >
> > Thanks,
> > Vaibhav Hiremath
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Suspend/Resume support with Omap2fb
Hi,
On Thu, 2009-03-12 at 19:26 +0100, ext Hiremath, Vaibhav wrote:
> Hi,
>
> Finally I could able to find the root-cause, actually some of the previous
> observations miss-led me to dig into power management, suspend/resume path
> and clock structure. But after bit debugging and with the help of Sanjeev, we
> got the rid of it.
>
> The issue is with DSS2 library, inside function "dpi_display_suspend". It
> calls dispc_enable_lcd_out(0), but doesn't wait till the frame-done
> interrupt. And due to this I was getting some abrupt behavior in
> suspend/resume path.
> Actually in the beginning I overlooked legacy frame-buffer driver, which
> handles this scenario perfectly.
dispc_enable_lcd_out(0) waits for FRAMEDONE. Please use the latest DSS2
version from my git repository =).
Tomi
>
> For Display sub-system we have 2 interface clocks coming, L3_ICLK and
> L4_ICLK. Out of these, L4_ICLK goes to Display register access and L3_ICLK
> goes to DMA register. In our suspend call we are disabling clocks for L3_ICLK
> (we don't control L4_ICLK), and due to this L4_ICLK stays attached with GFX.
> You will only be able to find out this by looking to
> CM_CLKSTST_DSS.CLKACTIVITY_DSS, which is set 1 and indicates some interface
> clock is still active in DSS domain.
>
> Below is the patch which will explain the change
>
>
> +#include
> +#include
>
> +static void dpi_display_isr(void *arg, unsigned int irqstatus)
> +{
> + struct omap_display *display = (struct omap_display *)arg;
> +
> + complete(&display->frame_done);
> +}
>
> static int dpi_display_suspend(struct omap_display *display)
> {
> + void *handle = NULL;
> +
> if (display->state != OMAP_DSS_DISPLAY_ACTIVE)
> return -EINVAL;
>
> if (display->panel->suspend)
> display->panel->suspend(display);
>
> + /*
> +* Wait for frame done interrupt
> +*/
> + handle = omap_dispc_register_isr(dpi_display_isr, display,
> + DISPC_IRQ_FRAMEDONE);
> + if (!handle)
> + return -EINVAL;
> +
> + init_completion(&display->frame_done);
> +
> dispc_enable_lcd_out(0);
> + if (!wait_for_completion_timeout(&display->frame_done,
> + msecs_to_jiffies(500))) {
> + printk("timeout waiting for FRAME DONE\n");
> + }
>
> Still I need to test this thoroughly, I may hit some another issue (Already I
> am seeing some crashes also when off state is enabled). I will create
> consolidated patch for this and will submit to list.
>
> Thanks,
> Vaibhav Hiremath
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Suspend/Resume support with Omap2fb
Hi,
Finally I could able to find the root-cause, actually some of the previous
observations miss-led me to dig into power management, suspend/resume path and
clock structure. But after bit debugging and with the help of Sanjeev, we got
the rid of it.
The issue is with DSS2 library, inside function "dpi_display_suspend". It calls
dispc_enable_lcd_out(0), but doesn't wait till the frame-done interrupt. And
due to this I was getting some abrupt behavior in suspend/resume path.
Actually in the beginning I overlooked legacy frame-buffer driver, which
handles this scenario perfectly.
For Display sub-system we have 2 interface clocks coming, L3_ICLK and L4_ICLK.
Out of these, L4_ICLK goes to Display register access and L3_ICLK goes to DMA
register. In our suspend call we are disabling clocks for L3_ICLK (we don't
control L4_ICLK), and due to this L4_ICLK stays attached with GFX. You will
only be able to find out this by looking to CM_CLKSTST_DSS.CLKACTIVITY_DSS,
which is set 1 and indicates some interface clock is still active in DSS domain.
Below is the patch which will explain the change
+#include
+#include
+static void dpi_display_isr(void *arg, unsigned int irqstatus)
+{
+ struct omap_display *display = (struct omap_display *)arg;
+
+ complete(&display->frame_done);
+}
static int dpi_display_suspend(struct omap_display *display)
{
+ void *handle = NULL;
+
if (display->state != OMAP_DSS_DISPLAY_ACTIVE)
return -EINVAL;
if (display->panel->suspend)
display->panel->suspend(display);
+ /*
+* Wait for frame done interrupt
+*/
+ handle = omap_dispc_register_isr(dpi_display_isr, display,
+ DISPC_IRQ_FRAMEDONE);
+ if (!handle)
+ return -EINVAL;
+
+ init_completion(&display->frame_done);
+
dispc_enable_lcd_out(0);
+ if (!wait_for_completion_timeout(&display->frame_done,
+ msecs_to_jiffies(500))) {
+ printk("timeout waiting for FRAME DONE\n");
+ }
Still I need to test this thoroughly, I may hit some another issue (Already I
am seeing some crashes also when off state is enabled). I will create
consolidated patch for this and will submit to list.
Thanks,
Vaibhav Hiremath
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Suspend/Resume support with Omap2fb
Thanks, Vaibhav Hiremath > -Original Message- > From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com] > Sent: Wednesday, March 11, 2009 6:20 PM > To: Hiremath, Vaibhav > Cc: linux-omap@vger.kernel.org > Subject: RE: Suspend/Resume support with Omap2fb > > On Wed, 2009-03-11 at 11:47 +0100, ext Hiremath, Vaibhav wrote: > > > > > > > > > How have you tested this? > > > > Have you also tested with "echo mem > /sys/power/state"? > > > > Are you using Kevin's power management tree? What is default > > > configuration of your kernel during this test? > > > > > > It's been some time since I tested it, but it did work on OMAP3 > SDP > > > with > > > the pm-branch. Only changed needed were the > > > get_last_off_on_transaction_id and omapfb -> omapdss. I also > tested > > > echo > > > mem > > > > > > > I'll try to find time to test it again with latest trees. > > > > > [Hiremath, Vaibhav] That would be great, I am also trying few > things here at my end. Hopefully I will get something. > > Yeah, it works ok for me. I rebased my DSS2 tree to latest l-o, then > merged pm-branch, and made the changes mentioned above. I get some > warnings from getnstimeofday when resuming the kernel, but they seem > to > be unrelated to DSS, and the image is fine after resume. I used my > dss_omap_3430sdp_defconfig and made the following commands to enable > PM: > > echo 1 > /sys/power/clocks_off_while_idle > echo 1 > /sys/power/enable_off_mode > echo 1 > /sys/power/voltage_off_while_idle > echo 1 > /sys/power/sleep_while_idle > [Hiremath, Vaibhav] Tomi, I looked into your latest code base, and I can see that you have added suspend and resume functionality and as you mentioned it is working for you. The only difference I could point out here is, I am handling suspend at driver level (fb and v4l2) and you are handling it at DSS2 level. I can give try to your implementation; tomorrow morning after reaching to office first thing I will try this and let you know. Just to share with wider audience, I am seeing some abrupt behavior and I doubt some timing synchronization is causing problem. I could see suspend is working if I comment "ovl->enable" or if I call "echo "gfx e:0 > /sys/devices/platform/omapfb/overlays". Although I have same implementation in omapfb_suspend and it does disables clock and overlay, system doesn't go to off state. It always gives error for dss_prwm. Tomi, Can you try enabling CONFIG_CPU_IDLE flag and see whether it is going to state5 or not? And I think it won't go due to obvious reasons, framebuffer will hold the clocks. You have to have something in your framebuffer driver to trigger display disable. I have implemented timer here to do that. I will send you the patch once I get rid of this issue. > Tomi > > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Suspend/Resume support with Omap2fb
On Wed, 2009-03-11 at 11:47 +0100, ext Hiremath, Vaibhav wrote: > > > > > > How have you tested this? > > > Have you also tested with "echo mem > /sys/power/state"? > > > Are you using Kevin's power management tree? What is default > > configuration of your kernel during this test? > > > > It's been some time since I tested it, but it did work on OMAP3 SDP > > with > > the pm-branch. Only changed needed were the > > get_last_off_on_transaction_id and omapfb -> omapdss. I also tested > > echo > > mem > > > > > I'll try to find time to test it again with latest trees. > > > [Hiremath, Vaibhav] That would be great, I am also trying few things here at > my end. Hopefully I will get something. Yeah, it works ok for me. I rebased my DSS2 tree to latest l-o, then merged pm-branch, and made the changes mentioned above. I get some warnings from getnstimeofday when resuming the kernel, but they seem to be unrelated to DSS, and the image is fine after resume. I used my dss_omap_3430sdp_defconfig and made the following commands to enable PM: echo 1 > /sys/power/clocks_off_while_idle echo 1 > /sys/power/enable_off_mode echo 1 > /sys/power/voltage_off_while_idle echo 1 > /sys/power/sleep_while_idle Tomi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Suspend/Resume support with Omap2fb
Thanks, Vaibhav Hiremath > -Original Message- > From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com] > Sent: Wednesday, March 11, 2009 3:01 PM > To: Hiremath, Vaibhav > Cc: linux-omap@vger.kernel.org > Subject: RE: Suspend/Resume support with Omap2fb > > On Wed, 2009-03-11 at 09:46 +0100, ext Hiremath, Vaibhav wrote: > > > > Thanks, > > Vaibhav Hiremath > > > > > -Original Message- > > > From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com] > > > Sent: Wednesday, March 11, 2009 1:23 PM > > > To: Hiremath, Vaibhav > > > Cc: linux-omap@vger.kernel.org > > > Subject: Re: Suspend/Resume support with Omap2fb > > > > > > Hi, > > > > > > On Wed, 2009-03-11 at 07:55 +0100, ext Hiremath, Vaibhav wrote: > > > > Hi, > > > > > > > > I am using New Frame-Buffer driver which is based on DSS2 > library > > > submitted by Tomi, and I am trying to add full power management > > > support. But things are not working out as expected, every time > when > > > I am issuing command "echo mem > /sys/power/state" the system > > > doesn't go into off state. It always points to dss_prwdm, below > are > > > the steps I am following - > > > > > > OFF mode should work. I have verified it with DSI, DPI and SDI. > > > However, > > > it needs passing the get_last_off_on_transaction_id pointer in > > > omap_dss_platform_data. > > > > > > Also, see below. > > > > > [Hiremath, Vaibhav] I believe this is only required when you do > save and restore context right? > > Well, yes. But you need to save and restore context if you want OFF > mode. > [Hiremath, Vaibhav] As I mentioned I am hitting full OFF state (state5), and save and restore is happening perfectly fine. > > Actually I have modified that part of code where it doesn't expect > this pointer and save/restore happens perfectly fine, which I am > very will sure about, since I am hitting state5 of CPU_IDLE (Full > OFF state) and it resumes back with the same state. > > > > Again one more data point which I missed in last mail is, I am > following clk->usecount which shows me 0. That means clocks are > already disabled. > > > > r...@arago:~# cat /sys/devices/platform/omap-dss/clk > > - dss - > > internal clk count 0 > > dss_ick 83000 > > dss1_alwon_fck 96000 > > dss2_alwon_fck 13000 > > dss_tv_fck 54000 > > dss_96m_fck 96000 > > - dispc - > > dispc fclk source = dss1_alwon_fclk > > pixel clk = 9600 / 1 / 5 = 1920 > > r...@arago:~# > > > > > > > > - Build the kernel with CPU_IDLE > > > > - Enable all the PM flags > > > > > > > > # echo 1 > /sys/power/sleep_while_idle > > > > # echo 1 > /sys/power/clocks_off_while_idle > > > > # echo 1 > /sys/power/enable_off_mode > > > > > > > > - From Linux prompt issue command > > > > > > > > # echo mem > /sys/power/state > > > > > > > > The log is - > > > > > > > > > > > > r...@arago:~# echo mem > /sys/power/state > > > > <6>PM: Syncing filesystems ... PM: Syncing filesystems ... > done. > > > > done. > > > > Freezing user space processes ... Freezing user space > processes > > > ... (elapsed 0.00 seconds) (elapsed 0.00 seconds) done. > > > > done. > > > > Freezing remaining freezable tasks ... Freezing remaining > > > freezable tasks ... (elapsed 0.06 seconds) (elapsed 0.06 > seconds) > > > done.done. > > > > Suspending console(s) (use no_console_suspend to debug) > > > > Suspending console(s) (use no_console_suspend to debug) > > > > <6>omap-backlight: suspending... > > > > omapfb_suspend > > > > > > > > omapfb_resume > > > > <6>omap-backlight: resuming... > > > > omap-backlight: suspending... > > > > omapfb_suspend > > > > Powerdomain (core_pwrdm) didn't enter target state 0 > > > > Powerdomain (dss_pwrdm) didn't enter target state 0 > > > > Powerdomain (per_pwrdm) didn't enter target state 0 > > > > Could not enter target state in pm_suspend > > > > eth0: link down > > > > omapf
RE: Suspend/Resume support with Omap2fb
On Wed, 2009-03-11 at 09:46 +0100, ext Hiremath, Vaibhav wrote: > > Thanks, > Vaibhav Hiremath > > > -Original Message- > > From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com] > > Sent: Wednesday, March 11, 2009 1:23 PM > > To: Hiremath, Vaibhav > > Cc: linux-omap@vger.kernel.org > > Subject: Re: Suspend/Resume support with Omap2fb > > > > Hi, > > > > On Wed, 2009-03-11 at 07:55 +0100, ext Hiremath, Vaibhav wrote: > > > Hi, > > > > > > I am using New Frame-Buffer driver which is based on DSS2 library > > submitted by Tomi, and I am trying to add full power management > > support. But things are not working out as expected, every time when > > I am issuing command "echo mem > /sys/power/state" the system > > doesn't go into off state. It always points to dss_prwdm, below are > > the steps I am following - > > > > OFF mode should work. I have verified it with DSI, DPI and SDI. > > However, > > it needs passing the get_last_off_on_transaction_id pointer in > > omap_dss_platform_data. > > > > Also, see below. > > > [Hiremath, Vaibhav] I believe this is only required when you do save and > restore context right? Well, yes. But you need to save and restore context if you want OFF mode. > Actually I have modified that part of code where it doesn't expect this > pointer and save/restore happens perfectly fine, which I am very will sure > about, since I am hitting state5 of CPU_IDLE (Full OFF state) and it resumes > back with the same state. > > Again one more data point which I missed in last mail is, I am following > clk->usecount which shows me 0. That means clocks are already disabled. > > r...@arago:~# cat /sys/devices/platform/omap-dss/clk > - dss - > internal clk count 0 > dss_ick 83000 > dss1_alwon_fck 96000 > dss2_alwon_fck 13000 > dss_tv_fck 54000 > dss_96m_fck 96000 > - dispc - > dispc fclk source = dss1_alwon_fclk > pixel clk = 9600 / 1 / 5 = 1920 > r...@arago:~# > > > > > - Build the kernel with CPU_IDLE > > > - Enable all the PM flags > > > > > > # echo 1 > /sys/power/sleep_while_idle > > > # echo 1 > /sys/power/clocks_off_while_idle > > > # echo 1 > /sys/power/enable_off_mode > > > > > > - From Linux prompt issue command > > > > > > # echo mem > /sys/power/state > > > > > > The log is - > > > > > > > > > r...@arago:~# echo mem > /sys/power/state > > > <6>PM: Syncing filesystems ... PM: Syncing filesystems ... done. > > > done. > > > Freezing user space processes ... Freezing user space processes > > ... (elapsed 0.00 seconds) (elapsed 0.00 seconds) done. > > > done. > > > Freezing remaining freezable tasks ... Freezing remaining > > freezable tasks ... (elapsed 0.06 seconds) (elapsed 0.06 seconds) > > done.done. > > > Suspending console(s) (use no_console_suspend to debug) > > > Suspending console(s) (use no_console_suspend to debug) > > > <6>omap-backlight: suspending... > > > omapfb_suspend > > > > > > omapfb_resume > > > <6>omap-backlight: resuming... > > > omap-backlight: suspending... > > > omapfb_suspend > > > Powerdomain (core_pwrdm) didn't enter target state 0 > > > Powerdomain (dss_pwrdm) didn't enter target state 0 > > > Powerdomain (per_pwrdm) didn't enter target state 0 > > > Could not enter target state in pm_suspend > > > eth0: link down > > > omapfb_resume > > > omap-backlight: resuming... > > > Restarting tasks ... Restarting tasks ... done. > > > done. > > > > > > r...@arago:~# > > > > > > > > > Some analysis which I observed during debugging this issue - > > > > > > - The root-cause is, DSS PowerDomain always shows it is in ON > > state (PWRDM_POWER_ON), and if I understand correctly this is only > > dependent on clocks. But I am making sure that DSS clocks are > > disabled. And with CPU_IDLE enabled I am going to complete OFF > > state. (/sys/devices/system/cpu/cpu0/cpuidle/state5/usage is > > incrementing). > > > > > > - If I compile out framebuffer driver and include DSS2 and > > V4L2 driver, everything works fine. I am not sure how "omapfb" is > > being tied with PowerDomain. Again I have seen r
RE: Suspend/Resume support with Omap2fb
Thanks, Vaibhav Hiremath > -Original Message- > From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com] > Sent: Wednesday, March 11, 2009 1:23 PM > To: Hiremath, Vaibhav > Cc: linux-omap@vger.kernel.org > Subject: Re: Suspend/Resume support with Omap2fb > > Hi, > > On Wed, 2009-03-11 at 07:55 +0100, ext Hiremath, Vaibhav wrote: > > Hi, > > > > I am using New Frame-Buffer driver which is based on DSS2 library > submitted by Tomi, and I am trying to add full power management > support. But things are not working out as expected, every time when > I am issuing command "echo mem > /sys/power/state" the system > doesn't go into off state. It always points to dss_prwdm, below are > the steps I am following - > > OFF mode should work. I have verified it with DSI, DPI and SDI. > However, > it needs passing the get_last_off_on_transaction_id pointer in > omap_dss_platform_data. > > Also, see below. > [Hiremath, Vaibhav] I believe this is only required when you do save and restore context right? Actually I have modified that part of code where it doesn't expect this pointer and save/restore happens perfectly fine, which I am very will sure about, since I am hitting state5 of CPU_IDLE (Full OFF state) and it resumes back with the same state. Again one more data point which I missed in last mail is, I am following clk->usecount which shows me 0. That means clocks are already disabled. r...@arago:~# cat /sys/devices/platform/omap-dss/clk - dss - internal clk count 0 dss_ick 83000 dss1_alwon_fck 96000 dss2_alwon_fck 13000 dss_tv_fck 54000 dss_96m_fck 96000 - dispc - dispc fclk source = dss1_alwon_fclk pixel clk = 9600 / 1 / 5 = 1920 r...@arago:~# > > - Build the kernel with CPU_IDLE > > - Enable all the PM flags > > > > # echo 1 > /sys/power/sleep_while_idle > > # echo 1 > /sys/power/clocks_off_while_idle > > # echo 1 > /sys/power/enable_off_mode > > > > - From Linux prompt issue command > > > > # echo mem > /sys/power/state > > > > The log is - > > > > > > r...@arago:~# echo mem > /sys/power/state > > <6>PM: Syncing filesystems ... PM: Syncing filesystems ... done. > > done. > > Freezing user space processes ... Freezing user space processes > ... (elapsed 0.00 seconds) (elapsed 0.00 seconds) done. > > done. > > Freezing remaining freezable tasks ... Freezing remaining > freezable tasks ... (elapsed 0.06 seconds) (elapsed 0.06 seconds) > done.done. > > Suspending console(s) (use no_console_suspend to debug) > > Suspending console(s) (use no_console_suspend to debug) > > <6>omap-backlight: suspending... > > omapfb_suspend > > > > omapfb_resume > > <6>omap-backlight: resuming... > > omap-backlight: suspending... > > omapfb_suspend > > Powerdomain (core_pwrdm) didn't enter target state 0 > > Powerdomain (dss_pwrdm) didn't enter target state 0 > > Powerdomain (per_pwrdm) didn't enter target state 0 > > Could not enter target state in pm_suspend > > eth0: link down > > omapfb_resume > > omap-backlight: resuming... > > Restarting tasks ... Restarting tasks ... done. > > done. > > > > r...@arago:~# > > > > > > Some analysis which I observed during debugging this issue - > > > > - The root-cause is, DSS PowerDomain always shows it is in ON > state (PWRDM_POWER_ON), and if I understand correctly this is only > dependent on clocks. But I am making sure that DSS clocks are > disabled. And with CPU_IDLE enabled I am going to complete OFF > state. (/sys/devices/system/cpu/cpu0/cpuidle/state5/usage is > incrementing). > > > > - If I compile out framebuffer driver and include DSS2 and > V4L2 driver, everything works fine. I am not sure how "omapfb" is > being tied with PowerDomain. Again I have seen references in > arch/arm/mach-omap2/omapdev3xxx.h to the pdev_name = "omapfb", not > sure how this is being used. > > You have to change it to omapdss (or omap-dss in earlier DSS2 > versions). > [Hiremath, Vaibhav] I have tried this option also, didn't work out. Tomi, Do you have summary or list of changes required in clock and PowerDomain related files to make it work? How have you tested this? Have you also tested with "echo mem > /sys/power/state"? Are you using Kevin's power management tree? What is default configuration of your kernel during this test? > Tomi > > > > > I believe if
Re: Suspend/Resume support with Omap2fb
Hi, On Wed, 2009-03-11 at 07:55 +0100, ext Hiremath, Vaibhav wrote: > Hi, > > I am using New Frame-Buffer driver which is based on DSS2 library submitted > by Tomi, and I am trying to add full power management support. But things are > not working out as expected, every time when I am issuing command "echo mem > > /sys/power/state" the system doesn't go into off state. It always points to > dss_prwdm, below are the steps I am following - OFF mode should work. I have verified it with DSI, DPI and SDI. However, it needs passing the get_last_off_on_transaction_id pointer in omap_dss_platform_data. Also, see below. > - Build the kernel with CPU_IDLE > - Enable all the PM flags > > # echo 1 > /sys/power/sleep_while_idle > # echo 1 > /sys/power/clocks_off_while_idle > # echo 1 > /sys/power/enable_off_mode > > - From Linux prompt issue command > > # echo mem > /sys/power/state > > The log is - > > > r...@arago:~# echo mem > /sys/power/state > <6>PM: Syncing filesystems ... PM: Syncing filesystems ... done. > done. > Freezing user space processes ... Freezing user space processes ... (elapsed > 0.00 seconds) (elapsed 0.00 seconds) done. > done. > Freezing remaining freezable tasks ... Freezing remaining freezable tasks ... > (elapsed 0.06 seconds) (elapsed 0.06 seconds) done.done. > Suspending console(s) (use no_console_suspend to debug) > Suspending console(s) (use no_console_suspend to debug) > <6>omap-backlight: suspending... > omapfb_suspend > > omapfb_resume > <6>omap-backlight: resuming... > omap-backlight: suspending... > omapfb_suspend > Powerdomain (core_pwrdm) didn't enter target state 0 > Powerdomain (dss_pwrdm) didn't enter target state 0 > Powerdomain (per_pwrdm) didn't enter target state 0 > Could not enter target state in pm_suspend > eth0: link down > omapfb_resume > omap-backlight: resuming... > Restarting tasks ... Restarting tasks ... done. > done. > > r...@arago:~# > > > Some analysis which I observed during debugging this issue - > > - The root-cause is, DSS PowerDomain always shows it is in ON state > (PWRDM_POWER_ON), and if I understand correctly this is only dependent on > clocks. But I am making sure that DSS clocks are disabled. And with CPU_IDLE > enabled I am going to complete OFF state. > (/sys/devices/system/cpu/cpu0/cpuidle/state5/usage is incrementing). > > - If I compile out framebuffer driver and include DSS2 and V4L2 driver, > everything works fine. I am not sure how "omapfb" is being tied with > PowerDomain. Again I have seen references in > arch/arm/mach-omap2/omapdev3xxx.h to the pdev_name = "omapfb", not sure how > this is being used. You have to change it to omapdss (or omap-dss in earlier DSS2 versions). Tomi > > I believe if system is hitting OFF state, then my enable/disable paths are > proper, but really not sure about why "mem" is causing problem here. > > Thanks, > Vaibhav Hiremath > Platform Support Products > Texas Instruments Inc > Ph: +91-80-25099927 > > > Thanks, > Vaibhav Hiremath > Platform Support Products > Texas Instruments Inc > Ph: +91-80-25099927 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Suspend/Resume support with Omap2fb
Hi, I am using New Frame-Buffer driver which is based on DSS2 library submitted by Tomi, and I am trying to add full power management support. But things are not working out as expected, every time when I am issuing command "echo mem > /sys/power/state" the system doesn't go into off state. It always points to dss_prwdm, below are the steps I am following - - Build the kernel with CPU_IDLE - Enable all the PM flags # echo 1 > /sys/power/sleep_while_idle # echo 1 > /sys/power/clocks_off_while_idle # echo 1 > /sys/power/enable_off_mode - From Linux prompt issue command # echo mem > /sys/power/state The log is - r...@arago:~# echo mem > /sys/power/state <6>PM: Syncing filesystems ... PM: Syncing filesystems ... done. done. Freezing user space processes ... Freezing user space processes ... (elapsed 0.00 seconds) (elapsed 0.00 seconds) done. done. Freezing remaining freezable tasks ... Freezing remaining freezable tasks ... (elapsed 0.06 seconds) (elapsed 0.06 seconds) done.done. Suspending console(s) (use no_console_suspend to debug) Suspending console(s) (use no_console_suspend to debug) <6>omap-backlight: suspending... omapfb_suspend omapfb_resume <6>omap-backlight: resuming... omap-backlight: suspending... omapfb_suspend Powerdomain (core_pwrdm) didn't enter target state 0 Powerdomain (dss_pwrdm) didn't enter target state 0 Powerdomain (per_pwrdm) didn't enter target state 0 Could not enter target state in pm_suspend eth0: link down omapfb_resume omap-backlight: resuming... Restarting tasks ... Restarting tasks ... done. done. r...@arago:~# Some analysis which I observed during debugging this issue - - The root-cause is, DSS PowerDomain always shows it is in ON state (PWRDM_POWER_ON), and if I understand correctly this is only dependent on clocks. But I am making sure that DSS clocks are disabled. And with CPU_IDLE enabled I am going to complete OFF state. (/sys/devices/system/cpu/cpu0/cpuidle/state5/usage is incrementing). - If I compile out framebuffer driver and include DSS2 and V4L2 driver, everything works fine. I am not sure how "omapfb" is being tied with PowerDomain. Again I have seen references in arch/arm/mach-omap2/omapdev3xxx.h to the pdev_name = "omapfb", not sure how this is being used. I believe if system is hitting OFF state, then my enable/disable paths are proper, but really not sure about why "mem" is causing problem here. Thanks, Vaibhav Hiremath Platform Support Products Texas Instruments Inc Ph: +91-80-25099927 Thanks, Vaibhav Hiremath Platform Support Products Texas Instruments Inc Ph: +91-80-25099927 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
