RE: Suspend/Resume support with Omap2fb

RE: Suspend/Resume support with Omap2fb

[Hiremath, Vaibhav]

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 <linux/completion.h>
+#include <linux/jiffies.h>

+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

RE: Suspend/Resume support with Omap2fb

[Tomi Valkeinen]

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 <linux/completion.h>
> +#include <linux/jiffies.h>
> 
> +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

RE: Suspend/Resume support with Omap2fb

[Hiremath, Vaibhav]

Thanks,
Vaibhav Hiremath

> -----Original Message-----
> From: Tomi Valkeinen [mailto:tomi.valkeinen@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 <linux/completion.h>
> > +#include <linux/jiffies.h>
> >
> > +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
> 

RE: Suspend/Resume support with Omap2fb

[Tomi Valkeinen]

On Fri, 2009-03-13 at 10:10 +0100, ext Hiremath, Vaibhav wrote:
> 
> Thanks,
> Vaibhav Hiremath
> 
> > -----Original Message-----
> > From: Tomi Valkeinen [mailto:tomi.valkeinen@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

RE: Suspend/Resume support with Omap2fb

[Hiremath, Vaibhav]

Thanks,
Vaibhav Hiremath

> -----Original Message-----
> From: Tomi Valkeinen [mailto:tomi.valkeinen@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.valkeinen@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
> 
> 

RE: Suspend/Resume support with Omap2fb

[Tomi Valkeinen]

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

Suspend/Resume support with Omap2fb

[Hiremath, Vaibhav]

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 - 
------------

root@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.

root@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

Re: Suspend/Resume support with Omap2fb

[Tomi Valkeinen]

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 - 
> ------------
> 
> root@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.
> 
> root@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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Suspend/Resume support with Omap2fb

[Hiremath, Vaibhav]

Thanks,
Vaibhav Hiremath

> -----Original Message-----
> From: Tomi Valkeinen [mailto:tomi.valkeinen@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.

root@arago:~# cat /sys/devices/platform/omap-dss/clk
- dss -
internal clk count      0
dss_ick         83000000        0
dss1_alwon_fck  96000000        0
dss2_alwon_fck  13000000        0
dss_tv_fck      54000000        0
dss_96m_fck     96000000        0
- dispc -
dispc fclk source = dss1_alwon_fclk
pixel clk = 96000000 / 1 / 5 = 19200000
root@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 -
> > ------------
> >
> > root@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.
> >
> > root@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 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 majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

RE: Suspend/Resume support with Omap2fb

[Tomi Valkeinen]

On Wed, 2009-03-11 at 09:46 +0100, ext Hiremath, Vaibhav wrote:
> 
> Thanks,
> Vaibhav Hiremath
> 
> > -----Original Message-----
> > From: Tomi Valkeinen [mailto:tomi.valkeinen@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.
> 
> root@arago:~# cat /sys/devices/platform/omap-dss/clk
> - dss -
> internal clk count      0
> dss_ick         83000000        0
> dss1_alwon_fck  96000000        0
> dss2_alwon_fck  13000000        0
> dss_tv_fck      54000000        0
> dss_96m_fck     96000000        0
> - dispc -
> dispc fclk source = dss1_alwon_fclk
> pixel clk = 96000000 / 1 / 5 = 19200000
> root@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 -
> > > ------------
> > >
> > > root@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.
> > >
> > > root@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?

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.

 Tomi

RE: Suspend/Resume support with Omap2fb

[Hiremath, Vaibhav]

Thanks,
Vaibhav Hiremath

> -----Original Message-----
> From: Tomi Valkeinen [mailto:tomi.valkeinen@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.valkeinen@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.
> >
> > root@arago:~# cat /sys/devices/platform/omap-dss/clk
> > - dss -
> > internal clk count      0
> > dss_ick         83000000        0
> > dss1_alwon_fck  96000000        0
> > dss2_alwon_fck  13000000        0
> > dss_tv_fck      54000000        0
> > dss_96m_fck     96000000        0
> > - dispc -
> > dispc fclk source = dss1_alwon_fclk
> > pixel clk = 96000000 / 1 / 5 = 19200000
> > root@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 -
> > > > ------------
> > > >
> > > > root@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.
> > > >
> > > > root@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?
> 
> 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.
>  Tomi
> 
> 

RE: Suspend/Resume support with Omap2fb

[Tomi Valkeinen]

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

RE: Suspend/Resume support with Omap2fb

[Hiremath, Vaibhav]

Thanks,
Vaibhav Hiremath

> -----Original Message-----
> From: Tomi Valkeinen [mailto:tomi.valkeinen@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
> 
>