All of lore.kernel.org
 help / color / mirror / Atom feed
From: Grygorii Strashko <grygorii.strashko@ti.com>
To: Tomi Valkeinen <tomi.valkeinen@ti.com>, Tony Lindgren <tony@atomide.com>
Cc: <linux-omap@vger.kernel.org>, "Andrew F . Davis" <afd@ti.com>,
	Dave Gerlach <d-gerlach@ti.com>, Faiz Abbas <faiz_abbas@ti.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Keerthy <j-keerthy@ti.com>, Nishanth Menon <nm@ti.com>,
	Peter Ujfalusi <peter.ujfalusi@ti.com>,
	Roger Quadros <rogerq@ti.com>, Suman Anna <s-anna@ti.com>,
	Tero Kristo <t-kristo@ti.com>, <linux-kernel@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<dri-devel@lists.freedesktop.org>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Subject: Re: [PATCH 1/5] drm/omap: Fix suspend resume regression after platform data removal
Date: Thu, 11 Jun 2020 17:00:59 +0300	[thread overview]
Message-ID: <d03dd04f-6f2c-25ba-fe1f-d5fc0dfb5c68@ti.com> (raw)
In-Reply-To: <9ed70121-2a53-d2b3-051a-88eb83e6c53f@ti.com>



On 09/06/2020 18:26, Tomi Valkeinen wrote:
> On 09/06/2020 18:19, Tony Lindgren wrote:
>>> But there's an extra runtime PM reference (dev.power.usage_count) that seems
>>> to come out of nowhere. So when omap_drm_suspend is finished, there's still
>>> usage_count of 1, and dispc never suspends fully.
>>
>> Hmm no idea about that. My guess is that there might be an issue that was
>> masked earlier with omap_device calling the child runtime_suspend.
> 
> Yes. It's how PM works. It calls pm_runtime_get_noresume() before starting the suspend of a device. So I guess omapdrm's suspend has been broken all the time, but it was "fixed" by omap_device.
> 

I think I might have an idea what is going wrong.

Before:
+----------------------+
|omap_device_pm_domain |
+---------------+------+------+
                 | device      |
                 +-------------+
                 | omap_device |
                 +-------------+

omap_device is embedded in DD device and PM handled by omap_device_pm_domain.

static int _od_suspend_noirq(struct device *dev)
{
...

	ret = pm_generic_suspend_noirq(dev);
[1] ^^ device suspend_noirq call

	if (!ret && !pm_runtime_status_suspended(dev)) {
		if (pm_generic_runtime_suspend(dev) == 0) {
[2] ^^ device pm_runtime_suspend force call

			omap_device_idle(pdev);
[3] ^^ omap_device disable
			od->flags |= OMAP_DEVICE_SUSPENDED;
		}
	}

	return ret;
}

Now:
+------------+
|ti sysc dev |
+-+----------+
   |
   |
   |   +-------------+
   |   | device      |
   +-->+             |
       +-------------+

With new approach the omap_device is not embedded in DD Device anymore,
instead ti-sysc (hwmod replacement) became parent of DD Device.

As result suspend sequence became the following
(Note. All PM runtime PUT calls became NOP during suspend by design):

device
|-> suspend() - in case of dss omap_drm_suspend() and Co if defined
|-> suspend_noirq() - in case of dss *not defined", equal to step [1] above
..

ti sysc dev (ti-sysc is parent, so called after device)
|-> sysc_noirq_suspend
    |-> pm_runtime_force_suspend()
	|-> sysc_runtime_suspend() - equal to step [3] above

And step [2] is missing as of now!

I think, suspend might be fixed if all devices, which are now child of ti-sysc, will do
pm_runtime_force_xxx() calls at noirq suspend stage by adding:

	SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
				      pm_runtime_force_resume)

Am I missing smth?

-- 
Best regards,
grygorii

WARNING: multiple messages have this Message-ID (diff)
From: Grygorii Strashko <grygorii.strashko@ti.com>
To: Tomi Valkeinen <tomi.valkeinen@ti.com>, Tony Lindgren <tony@atomide.com>
Cc: Nishanth Menon <nm@ti.com>, Tero Kristo <t-kristo@ti.com>,
	Suman Anna <s-anna@ti.com>, Dave Gerlach <d-gerlach@ti.com>,
	Keerthy <j-keerthy@ti.com>,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	"Andrew F . Davis" <afd@ti.com>,
	Peter Ujfalusi <peter.ujfalusi@ti.com>,
	Faiz Abbas <faiz_abbas@ti.com>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	Roger Quadros <rogerq@ti.com>
Subject: Re: [PATCH 1/5] drm/omap: Fix suspend resume regression after platform data removal
Date: Thu, 11 Jun 2020 17:00:59 +0300	[thread overview]
Message-ID: <d03dd04f-6f2c-25ba-fe1f-d5fc0dfb5c68@ti.com> (raw)
In-Reply-To: <9ed70121-2a53-d2b3-051a-88eb83e6c53f@ti.com>



On 09/06/2020 18:26, Tomi Valkeinen wrote:
> On 09/06/2020 18:19, Tony Lindgren wrote:
>>> But there's an extra runtime PM reference (dev.power.usage_count) that seems
>>> to come out of nowhere. So when omap_drm_suspend is finished, there's still
>>> usage_count of 1, and dispc never suspends fully.
>>
>> Hmm no idea about that. My guess is that there might be an issue that was
>> masked earlier with omap_device calling the child runtime_suspend.
> 
> Yes. It's how PM works. It calls pm_runtime_get_noresume() before starting the suspend of a device. So I guess omapdrm's suspend has been broken all the time, but it was "fixed" by omap_device.
> 

I think I might have an idea what is going wrong.

Before:
+----------------------+
|omap_device_pm_domain |
+---------------+------+------+
                 | device      |
                 +-------------+
                 | omap_device |
                 +-------------+

omap_device is embedded in DD device and PM handled by omap_device_pm_domain.

static int _od_suspend_noirq(struct device *dev)
{
...

	ret = pm_generic_suspend_noirq(dev);
[1] ^^ device suspend_noirq call

	if (!ret && !pm_runtime_status_suspended(dev)) {
		if (pm_generic_runtime_suspend(dev) == 0) {
[2] ^^ device pm_runtime_suspend force call

			omap_device_idle(pdev);
[3] ^^ omap_device disable
			od->flags |= OMAP_DEVICE_SUSPENDED;
		}
	}

	return ret;
}

Now:
+------------+
|ti sysc dev |
+-+----------+
   |
   |
   |   +-------------+
   |   | device      |
   +-->+             |
       +-------------+

With new approach the omap_device is not embedded in DD Device anymore,
instead ti-sysc (hwmod replacement) became parent of DD Device.

As result suspend sequence became the following
(Note. All PM runtime PUT calls became NOP during suspend by design):

device
|-> suspend() - in case of dss omap_drm_suspend() and Co if defined
|-> suspend_noirq() - in case of dss *not defined", equal to step [1] above
..

ti sysc dev (ti-sysc is parent, so called after device)
|-> sysc_noirq_suspend
    |-> pm_runtime_force_suspend()
	|-> sysc_runtime_suspend() - equal to step [3] above

And step [2] is missing as of now!

I think, suspend might be fixed if all devices, which are now child of ti-sysc, will do
pm_runtime_force_xxx() calls at noirq suspend stage by adding:

	SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
				      pm_runtime_force_resume)

Am I missing smth?

-- 
Best regards,
grygorii

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Grygorii Strashko <grygorii.strashko@ti.com>
To: Tomi Valkeinen <tomi.valkeinen@ti.com>, Tony Lindgren <tony@atomide.com>
Cc: Nishanth Menon <nm@ti.com>, Tero Kristo <t-kristo@ti.com>,
	Suman Anna <s-anna@ti.com>, Dave Gerlach <d-gerlach@ti.com>,
	Keerthy <j-keerthy@ti.com>,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	"Andrew F . Davis" <afd@ti.com>,
	Peter Ujfalusi <peter.ujfalusi@ti.com>,
	Faiz Abbas <faiz_abbas@ti.com>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	Roger Quadros <rogerq@ti.com>
Subject: Re: [PATCH 1/5] drm/omap: Fix suspend resume regression after platform data removal
Date: Thu, 11 Jun 2020 17:00:59 +0300	[thread overview]
Message-ID: <d03dd04f-6f2c-25ba-fe1f-d5fc0dfb5c68@ti.com> (raw)
In-Reply-To: <9ed70121-2a53-d2b3-051a-88eb83e6c53f@ti.com>



On 09/06/2020 18:26, Tomi Valkeinen wrote:
> On 09/06/2020 18:19, Tony Lindgren wrote:
>>> But there's an extra runtime PM reference (dev.power.usage_count) that seems
>>> to come out of nowhere. So when omap_drm_suspend is finished, there's still
>>> usage_count of 1, and dispc never suspends fully.
>>
>> Hmm no idea about that. My guess is that there might be an issue that was
>> masked earlier with omap_device calling the child runtime_suspend.
> 
> Yes. It's how PM works. It calls pm_runtime_get_noresume() before starting the suspend of a device. So I guess omapdrm's suspend has been broken all the time, but it was "fixed" by omap_device.
> 

I think I might have an idea what is going wrong.

Before:
+----------------------+
|omap_device_pm_domain |
+---------------+------+------+
                 | device      |
                 +-------------+
                 | omap_device |
                 +-------------+

omap_device is embedded in DD device and PM handled by omap_device_pm_domain.

static int _od_suspend_noirq(struct device *dev)
{
...

	ret = pm_generic_suspend_noirq(dev);
[1] ^^ device suspend_noirq call

	if (!ret && !pm_runtime_status_suspended(dev)) {
		if (pm_generic_runtime_suspend(dev) == 0) {
[2] ^^ device pm_runtime_suspend force call

			omap_device_idle(pdev);
[3] ^^ omap_device disable
			od->flags |= OMAP_DEVICE_SUSPENDED;
		}
	}

	return ret;
}

Now:
+------------+
|ti sysc dev |
+-+----------+
   |
   |
   |   +-------------+
   |   | device      |
   +-->+             |
       +-------------+

With new approach the omap_device is not embedded in DD Device anymore,
instead ti-sysc (hwmod replacement) became parent of DD Device.

As result suspend sequence became the following
(Note. All PM runtime PUT calls became NOP during suspend by design):

device
|-> suspend() - in case of dss omap_drm_suspend() and Co if defined
|-> suspend_noirq() - in case of dss *not defined", equal to step [1] above
..

ti sysc dev (ti-sysc is parent, so called after device)
|-> sysc_noirq_suspend
    |-> pm_runtime_force_suspend()
	|-> sysc_runtime_suspend() - equal to step [3] above

And step [2] is missing as of now!

I think, suspend might be fixed if all devices, which are now child of ti-sysc, will do
pm_runtime_force_xxx() calls at noirq suspend stage by adding:

	SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
				      pm_runtime_force_resume)

Am I missing smth?

-- 
Best regards,
grygorii
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  parent reply	other threads:[~2020-06-11 13:59 UTC|newest]

Thread overview: 73+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-31 19:39 [PATCH 0/5] Suspend and resume fixes for omapdrm pdata removal Tony Lindgren
2020-05-31 19:39 ` Tony Lindgren
2020-05-31 19:39 ` Tony Lindgren
2020-05-31 19:39 ` [PATCH 1/5] drm/omap: Fix suspend resume regression after platform data removal Tony Lindgren
2020-05-31 19:39   ` Tony Lindgren
2020-05-31 19:39   ` Tony Lindgren
2020-06-03 12:33   ` Tomi Valkeinen
2020-06-03 12:33     ` Tomi Valkeinen
2020-06-03 12:33     ` Tomi Valkeinen
2020-06-03 14:06     ` Tony Lindgren
2020-06-03 14:06       ` Tony Lindgren
2020-06-03 14:06       ` Tony Lindgren
2020-06-09  7:04       ` Tomi Valkeinen
2020-06-09  7:04         ` Tomi Valkeinen
2020-06-09  7:04         ` Tomi Valkeinen
2020-06-09 15:19         ` Tony Lindgren
2020-06-09 15:19           ` Tony Lindgren
2020-06-09 15:19           ` Tony Lindgren
2020-06-09 15:26           ` Tomi Valkeinen
2020-06-09 15:26             ` Tomi Valkeinen
2020-06-09 15:26             ` Tomi Valkeinen
2020-06-09 16:52             ` Tony Lindgren
2020-06-09 16:52               ` Tony Lindgren
2020-06-09 16:52               ` Tony Lindgren
2020-06-09 17:10               ` Tony Lindgren
2020-06-09 17:10                 ` Tony Lindgren
2020-06-09 17:10                 ` Tony Lindgren
2020-06-09 17:26                 ` Tony Lindgren
2020-06-09 17:26                   ` Tony Lindgren
2020-06-09 17:26                   ` Tony Lindgren
2020-06-10 11:47                 ` Tomi Valkeinen
2020-06-10 11:47                   ` Tomi Valkeinen
2020-06-10 11:47                   ` Tomi Valkeinen
2020-06-10 22:41                   ` Tony Lindgren
2020-06-10 22:41                     ` Tony Lindgren
2020-06-10 22:41                     ` Tony Lindgren
2020-06-11 14:00             ` Grygorii Strashko [this message]
2020-06-11 14:00               ` Grygorii Strashko
2020-06-11 14:00               ` Grygorii Strashko
2020-06-11 14:32               ` Tony Lindgren
2020-06-11 14:32                 ` Tony Lindgren
2020-06-11 14:32                 ` Tony Lindgren
2020-06-16 13:01               ` Tomi Valkeinen
2020-06-16 13:01                 ` Tomi Valkeinen
2020-06-16 13:01                 ` Tomi Valkeinen
2020-06-16 15:30                 ` Tony Lindgren
2020-06-16 15:30                   ` Tony Lindgren
2020-06-16 15:30                   ` Tony Lindgren
2020-06-16 16:56                   ` Grygorii Strashko
2020-06-16 16:56                     ` Grygorii Strashko
2020-06-16 16:56                     ` Grygorii Strashko
2020-06-17  6:04                     ` Tomi Valkeinen
2020-06-17  6:04                       ` Tomi Valkeinen
2020-06-17  6:04                       ` Tomi Valkeinen
2020-06-17 12:49                       ` Grygorii Strashko
2020-06-17 12:49                         ` Grygorii Strashko
2020-06-17 12:49                         ` Grygorii Strashko
2020-05-31 19:39 ` [PATCH 2/5] bus: ti-sysc: Use optional clocks on for enable and wait for softreset bit Tony Lindgren
2020-05-31 19:39   ` Tony Lindgren
2020-05-31 19:39   ` Tony Lindgren
2020-06-01  2:19   ` kbuild test robot
2020-06-01  2:19     ` kbuild test robot
2020-06-01 15:01     ` Tony Lindgren
2020-06-01 15:01       ` Tony Lindgren
2020-05-31 19:39 ` [PATCH 3/5] bus: ti-sysc: Ignore clockactivity unless specified as a quirk Tony Lindgren
2020-05-31 19:39   ` Tony Lindgren
2020-05-31 19:39   ` Tony Lindgren
2020-05-31 19:39 ` [PATCH 4/5] bus: ti-sysc: Fix uninitialized framedonetv_irq Tony Lindgren
2020-05-31 19:39   ` Tony Lindgren
2020-05-31 19:39   ` Tony Lindgren
2020-05-31 19:39 ` [PATCH 5/5] ARM: OMAP2+: Fix legacy mode dss_reset Tony Lindgren
2020-05-31 19:39   ` Tony Lindgren
2020-05-31 19:39   ` Tony Lindgren

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d03dd04f-6f2c-25ba-fe1f-d5fc0dfb5c68@ti.com \
    --to=grygorii.strashko@ti.com \
    --cc=afd@ti.com \
    --cc=d-gerlach@ti.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=faiz_abbas@ti.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=j-keerthy@ti.com \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=nm@ti.com \
    --cc=peter.ujfalusi@ti.com \
    --cc=rogerq@ti.com \
    --cc=s-anna@ti.com \
    --cc=t-kristo@ti.com \
    --cc=tomi.valkeinen@ti.com \
    --cc=tony@atomide.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.