From: robin.murphy@arm.com (Robin Murphy)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/2] drm: hdlcd: Suspend/resume only active crtcs
Date: Thu, 5 May 2016 19:01:17 +0100 [thread overview]
Message-ID: <572B8A6D.40405@arm.com> (raw)
In-Reply-To: <20160505170601.GP1286@phenom.ffwll.local>
Hi Daniel,
On 05/05/16 18:06, Daniel Vetter wrote:
> On Thu, May 05, 2016 at 05:13:38PM +0100, Robin Murphy wrote:
>> The current PM ops simply unconditionally enable/disable the HDLCD,
>> which proves problematic when there is no display plugged in - since
>> without a crtc the hardware itself is still in an uninitialised state,
>> coming out of suspend results in it being enabled without a valid
>> framebuffer address, which typically results in it trying to scan out
>> from bus address 0 and flooding the system with error interrupts.
>>
>> Fix this by checking the crtc state on resume, and only enabling the
>> hardware if it's actually supposed to be. For the sake of consistency,
>> do the same on the suspend path as well, although there it's merely a
>> case of skipping unnecessary work.
>>
>> CC: Liviu Dudau <liviu.dudau@arm.com>
>> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>> ---
>> drivers/gpu/drm/arm/hdlcd_crtc.c | 6 ++++--
>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
>> index fef1b04c2aab..bf6ff5e48adc 100644
>> --- a/drivers/gpu/drm/arm/hdlcd_crtc.c
>> +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
>> @@ -296,12 +296,14 @@ static struct drm_plane *hdlcd_plane_init(struct drm_device *drm)
>>
>> void hdlcd_crtc_suspend(struct drm_crtc *crtc)
>> {
>> - hdlcd_crtc_disable(crtc);
>> + if (crtc->state->active)
>> + hdlcd_crtc_disable(crtc);
>> }
>>
>> void hdlcd_crtc_resume(struct drm_crtc *crtc)
>> {
>> - hdlcd_crtc_enable(crtc);
>> + if (crtc->state->active)
>> + hdlcd_crtc_enable(crtc);
>> }
>
> If you use the atomic helpers to suspend/resume your entire display
> pipeline these callbacks shouldn't even be needed at all. Tried just
> removing them?
I'll have to leave that in Liviu's hands as I know literally nothing
about the relationship between platform PM ops and DRM helpers ;)
My only motivation is for the arm64 hibernate support currently sat in
-next for 4.7 to stop being broken on my Juno board by this.
Robin.
> -Daniel
>
>>
>> int hdlcd_setup_crtc(struct drm_device *drm)
>> --
>> 2.8.1.dirty
>>
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
WARNING: multiple messages have this Message-ID (diff)
From: Robin Murphy <robin.murphy@arm.com>
To: airlied@linux.ie, liviu.dudau@arm.com,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 2/2] drm: hdlcd: Suspend/resume only active crtcs
Date: Thu, 5 May 2016 19:01:17 +0100 [thread overview]
Message-ID: <572B8A6D.40405@arm.com> (raw)
In-Reply-To: <20160505170601.GP1286@phenom.ffwll.local>
Hi Daniel,
On 05/05/16 18:06, Daniel Vetter wrote:
> On Thu, May 05, 2016 at 05:13:38PM +0100, Robin Murphy wrote:
>> The current PM ops simply unconditionally enable/disable the HDLCD,
>> which proves problematic when there is no display plugged in - since
>> without a crtc the hardware itself is still in an uninitialised state,
>> coming out of suspend results in it being enabled without a valid
>> framebuffer address, which typically results in it trying to scan out
>> from bus address 0 and flooding the system with error interrupts.
>>
>> Fix this by checking the crtc state on resume, and only enabling the
>> hardware if it's actually supposed to be. For the sake of consistency,
>> do the same on the suspend path as well, although there it's merely a
>> case of skipping unnecessary work.
>>
>> CC: Liviu Dudau <liviu.dudau@arm.com>
>> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>> ---
>> drivers/gpu/drm/arm/hdlcd_crtc.c | 6 ++++--
>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
>> index fef1b04c2aab..bf6ff5e48adc 100644
>> --- a/drivers/gpu/drm/arm/hdlcd_crtc.c
>> +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
>> @@ -296,12 +296,14 @@ static struct drm_plane *hdlcd_plane_init(struct drm_device *drm)
>>
>> void hdlcd_crtc_suspend(struct drm_crtc *crtc)
>> {
>> - hdlcd_crtc_disable(crtc);
>> + if (crtc->state->active)
>> + hdlcd_crtc_disable(crtc);
>> }
>>
>> void hdlcd_crtc_resume(struct drm_crtc *crtc)
>> {
>> - hdlcd_crtc_enable(crtc);
>> + if (crtc->state->active)
>> + hdlcd_crtc_enable(crtc);
>> }
>
> If you use the atomic helpers to suspend/resume your entire display
> pipeline these callbacks shouldn't even be needed at all. Tried just
> removing them?
I'll have to leave that in Liviu's hands as I know literally nothing
about the relationship between platform PM ops and DRM helpers ;)
My only motivation is for the arm64 hibernate support currently sat in
-next for 4.7 to stop being broken on my Juno board by this.
Robin.
> -Daniel
>
>>
>> int hdlcd_setup_crtc(struct drm_device *drm)
>> --
>> 2.8.1.dirty
>>
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
WARNING: multiple messages have this Message-ID (diff)
From: Robin Murphy <robin.murphy@arm.com>
To: airlied@linux.ie, liviu.dudau@arm.com,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 2/2] drm: hdlcd: Suspend/resume only active crtcs
Date: Thu, 5 May 2016 19:01:17 +0100 [thread overview]
Message-ID: <572B8A6D.40405@arm.com> (raw)
In-Reply-To: <20160505170601.GP1286@phenom.ffwll.local>
Hi Daniel,
On 05/05/16 18:06, Daniel Vetter wrote:
> On Thu, May 05, 2016 at 05:13:38PM +0100, Robin Murphy wrote:
>> The current PM ops simply unconditionally enable/disable the HDLCD,
>> which proves problematic when there is no display plugged in - since
>> without a crtc the hardware itself is still in an uninitialised state,
>> coming out of suspend results in it being enabled without a valid
>> framebuffer address, which typically results in it trying to scan out
>> from bus address 0 and flooding the system with error interrupts.
>>
>> Fix this by checking the crtc state on resume, and only enabling the
>> hardware if it's actually supposed to be. For the sake of consistency,
>> do the same on the suspend path as well, although there it's merely a
>> case of skipping unnecessary work.
>>
>> CC: Liviu Dudau <liviu.dudau@arm.com>
>> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>> ---
>> drivers/gpu/drm/arm/hdlcd_crtc.c | 6 ++++--
>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
>> index fef1b04c2aab..bf6ff5e48adc 100644
>> --- a/drivers/gpu/drm/arm/hdlcd_crtc.c
>> +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
>> @@ -296,12 +296,14 @@ static struct drm_plane *hdlcd_plane_init(struct drm_device *drm)
>>
>> void hdlcd_crtc_suspend(struct drm_crtc *crtc)
>> {
>> - hdlcd_crtc_disable(crtc);
>> + if (crtc->state->active)
>> + hdlcd_crtc_disable(crtc);
>> }
>>
>> void hdlcd_crtc_resume(struct drm_crtc *crtc)
>> {
>> - hdlcd_crtc_enable(crtc);
>> + if (crtc->state->active)
>> + hdlcd_crtc_enable(crtc);
>> }
>
> If you use the atomic helpers to suspend/resume your entire display
> pipeline these callbacks shouldn't even be needed at all. Tried just
> removing them?
I'll have to leave that in Liviu's hands as I know literally nothing
about the relationship between platform PM ops and DRM helpers ;)
My only motivation is for the arm64 hibernate support currently sat in
-next for 4.7 to stop being broken on my Juno board by this.
Robin.
> -Daniel
>
>>
>> int hdlcd_setup_crtc(struct drm_device *drm)
>> --
>> 2.8.1.dirty
>>
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
next prev parent reply other threads:[~2016-05-05 18:01 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-05 16:13 [PATCH 1/2] drm: hdlcd: Skip PM callbacks if unbound Robin Murphy
2016-05-05 16:13 ` Robin Murphy
2016-05-05 16:13 ` Robin Murphy
2016-05-05 16:13 ` [PATCH 2/2] drm: hdlcd: Suspend/resume only active crtcs Robin Murphy
2016-05-05 16:13 ` Robin Murphy
2016-05-05 16:13 ` Robin Murphy
2016-05-05 16:52 ` liviu.dudau at arm.com
2016-05-05 16:52 ` liviu.dudau
2016-05-05 16:52 ` liviu.dudau
2016-05-05 17:06 ` Daniel Vetter
2016-05-05 17:06 ` Daniel Vetter
2016-05-05 17:06 ` Daniel Vetter
2016-05-05 17:11 ` liviu.dudau at arm.com
2016-05-05 17:11 ` liviu.dudau
2016-05-05 17:11 ` liviu.dudau
2016-05-05 18:01 ` Robin Murphy [this message]
2016-05-05 18:01 ` Robin Murphy
2016-05-05 18:01 ` Robin Murphy
2016-05-06 14:54 ` [PATCH 1/2] drm: hdlcd: Skip PM callbacks if unbound Thierry Reding
2016-05-06 14:54 ` Thierry Reding
2016-05-06 14:54 ` Thierry Reding
2016-05-06 16:26 ` liviu.dudau at arm.com
2016-05-06 16:26 ` liviu.dudau
2016-05-06 16:26 ` liviu.dudau
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=572B8A6D.40405@arm.com \
--to=robin.murphy@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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.