* [PATCH] drm/vc4: Fix with pm_runtime synchronization on DSI [not found] <CGME20190329012926epcas1p3fbfa796a221c2fd105a84c31c80016d5@epcas1p3.samsung.com> @ 2019-03-29 1:29 ` Hoegeun Kwon 2019-04-01 17:48 ` Eric Anholt 0 siblings, 1 reply; 6+ messages in thread From: Hoegeun Kwon @ 2019-03-29 1:29 UTC (permalink / raw) To: eric, airlied, daniel, dri-devel; +Cc: hoegeun.kwon There is a problem when often dpms goes from off to on. pm idle is not in sync and the problem occurs. Modify pm_runtime_put from asynchronous to synchronous. Signed-off-by: Hoegeun Kwon <hoegeun.kwon@samsung.com> --- drivers/gpu/drm/vc4/vc4_dsi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/vc4/vc4_dsi.c b/drivers/gpu/drm/vc4/vc4_dsi.c index 11702e1d9011..b0264c7b8bed 100644 --- a/drivers/gpu/drm/vc4/vc4_dsi.c +++ b/drivers/gpu/drm/vc4/vc4_dsi.c @@ -822,7 +822,7 @@ static void vc4_dsi_encoder_disable(struct drm_encoder *encoder) clk_disable_unprepare(dsi->escape_clock); clk_disable_unprepare(dsi->pixel_clock); - pm_runtime_put(dev); + pm_runtime_put_sync(dev); } /* Extends the mode's blank intervals to handle BCM2835's integer-only -- 2.17.1 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH] drm/vc4: Fix with pm_runtime synchronization on DSI 2019-03-29 1:29 ` [PATCH] drm/vc4: Fix with pm_runtime synchronization on DSI Hoegeun Kwon @ 2019-04-01 17:48 ` Eric Anholt 2019-04-08 1:05 ` Hoegeun Kwon 0 siblings, 1 reply; 6+ messages in thread From: Eric Anholt @ 2019-04-01 17:48 UTC (permalink / raw) To: airlied, daniel, dri-devel; +Cc: hoegeun.kwon [-- Attachment #1.1: Type: text/plain, Size: 1064 bytes --] Hoegeun Kwon <hoegeun.kwon@samsung.com> writes: > There is a problem when often dpms goes from off to on. pm idle is not > in sync and the problem occurs. Modify pm_runtime_put from > asynchronous to synchronous. Why would we need the power domain to go to off before we try to come back? Any idea? Also, please specify what "the problem" is. > > Signed-off-by: Hoegeun Kwon <hoegeun.kwon@samsung.com> > --- > drivers/gpu/drm/vc4/vc4_dsi.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/vc4/vc4_dsi.c b/drivers/gpu/drm/vc4/vc4_dsi.c > index 11702e1d9011..b0264c7b8bed 100644 > --- a/drivers/gpu/drm/vc4/vc4_dsi.c > +++ b/drivers/gpu/drm/vc4/vc4_dsi.c > @@ -822,7 +822,7 @@ static void vc4_dsi_encoder_disable(struct drm_encoder *encoder) > clk_disable_unprepare(dsi->escape_clock); > clk_disable_unprepare(dsi->pixel_clock); > > - pm_runtime_put(dev); > + pm_runtime_put_sync(dev); > } > > /* Extends the mode's blank intervals to handle BCM2835's integer-only > -- > 2.17.1 [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 832 bytes --] [-- Attachment #2: Type: text/plain, Size: 159 bytes --] _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] drm/vc4: Fix with pm_runtime synchronization on DSI 2019-04-01 17:48 ` Eric Anholt @ 2019-04-08 1:05 ` Hoegeun Kwon 2019-04-09 16:24 ` Eric Anholt 0 siblings, 1 reply; 6+ messages in thread From: Hoegeun Kwon @ 2019-04-08 1:05 UTC (permalink / raw) To: Eric Anholt, airlied, daniel, dri-devel; +Cc: Hoegeun Kwon On 4/2/19 2:48 AM, Eric Anholt wrote: > Hoegeun Kwon <hoegeun.kwon@samsung.com> writes: > >> There is a problem when often dpms goes from off to on. pm idle is not >> in sync and the problem occurs. Modify pm_runtime_put from >> asynchronous to synchronous. > Why would we need the power domain to go to off before we try to come > back? Any idea? Also, please specify what "the problem" is. Hi Eric, First thank you for your review. There is a problem failed to runtime PM enable on DSI when often dpms goes from off to on. The cause of this problem is that when we put pm idle, I think that there is a timing problem if I do not sync. Best regards, Hoegeun > >> Signed-off-by: Hoegeun Kwon <hoegeun.kwon@samsung.com> >> --- >> drivers/gpu/drm/vc4/vc4_dsi.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/gpu/drm/vc4/vc4_dsi.c b/drivers/gpu/drm/vc4/vc4_dsi.c >> index 11702e1d9011..b0264c7b8bed 100644 >> --- a/drivers/gpu/drm/vc4/vc4_dsi.c >> +++ b/drivers/gpu/drm/vc4/vc4_dsi.c >> @@ -822,7 +822,7 @@ static void vc4_dsi_encoder_disable(struct drm_encoder *encoder) >> clk_disable_unprepare(dsi->escape_clock); >> clk_disable_unprepare(dsi->pixel_clock); >> >> - pm_runtime_put(dev); >> + pm_runtime_put_sync(dev); >> } >> >> /* Extends the mode's blank intervals to handle BCM2835's integer-only >> -- >> 2.17.1 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] drm/vc4: Fix with pm_runtime synchronization on DSI 2019-04-08 1:05 ` Hoegeun Kwon @ 2019-04-09 16:24 ` Eric Anholt 2019-05-22 10:24 ` Hoegeun Kwon 0 siblings, 1 reply; 6+ messages in thread From: Eric Anholt @ 2019-04-09 16:24 UTC (permalink / raw) To: airlied, daniel, dri-devel; +Cc: Hoegeun Kwon [-- Attachment #1.1: Type: text/plain, Size: 727 bytes --] Hoegeun Kwon <hoegeun.kwon@samsung.com> writes: > On 4/2/19 2:48 AM, Eric Anholt wrote: >> Hoegeun Kwon <hoegeun.kwon@samsung.com> writes: >> >>> There is a problem when often dpms goes from off to on. pm idle is not >>> in sync and the problem occurs. Modify pm_runtime_put from >>> asynchronous to synchronous. >> Why would we need the power domain to go to off before we try to come >> back? Any idea? Also, please specify what "the problem" is. > > Hi Eric, > > > First thank you for your review. > > There is a problem failed to runtime PM enable on DSI when often dpms What do you mean by "failed to runtime PM enable"? The pm_runtime_enable() returned an error? Have you investigated the source that error, if so? [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 832 bytes --] [-- Attachment #2: Type: text/plain, Size: 159 bytes --] _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] drm/vc4: Fix with pm_runtime synchronization on DSI 2019-04-09 16:24 ` Eric Anholt @ 2019-05-22 10:24 ` Hoegeun Kwon 2019-05-22 11:32 ` Daniel Vetter 0 siblings, 1 reply; 6+ messages in thread From: Hoegeun Kwon @ 2019-05-22 10:24 UTC (permalink / raw) To: Eric Anholt, airlied, daniel, dri-devel, Hoegeun Kwon [-- Attachment #1.1: Type: text/plain, Size: 1232 bytes --] On 4/10/19 1:24 AM, Eric Anholt wrote: > Hoegeun Kwon <hoegeun.kwon@samsung.com> writes: > >> On 4/2/19 2:48 AM, Eric Anholt wrote: >>> Hoegeun Kwon <hoegeun.kwon@samsung.com> writes: >>> >>>> There is a problem when often dpms goes from off to on. pm idle is not >>>> in sync and the problem occurs. Modify pm_runtime_put from >>>> asynchronous to synchronous. >>> Why would we need the power domain to go to off before we try to come >>> back? Any idea? Also, please specify what "the problem" is. >> Hi Eric, >> >> >> First thank you for your review. >> >> There is a problem failed to runtime PM enable on DSI when often dpms > What do you mean by "failed to runtime PM enable"? The > pm_runtime_enable() returned an error? Have you investigated the source > that error, if so? I'm sorry for the late reply. The pm_runtime_enable() is not returned because return value is void. The problem is that if the error log is not output and the DPMS off on is repeated, the screen will stop. As a result of debugging the problem, I think that synchronization is a problem caused by dsi pm_suspend and resume. So when we entered the pm runtime idle state, if used with sync, the problem does not occur. Best regards, Hoegeun [-- Attachment #1.2.1: Type: text/html, Size: 2842 bytes --] [-- Attachment #1.2.2: Type: image/gif, Size: 13402 bytes --] [-- Attachment #2: Type: text/plain, Size: 159 bytes --] _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] drm/vc4: Fix with pm_runtime synchronization on DSI 2019-05-22 10:24 ` Hoegeun Kwon @ 2019-05-22 11:32 ` Daniel Vetter 0 siblings, 0 replies; 6+ messages in thread From: Daniel Vetter @ 2019-05-22 11:32 UTC (permalink / raw) To: Hoegeun Kwon; +Cc: Dave Airlie, dri-devel [-- Attachment #1.1.1: Type: text/plain, Size: 1713 bytes --] On Wed, May 22, 2019 at 12:24 PM Hoegeun Kwon <hoegeun.kwon@samsung.com> wrote: > On 4/10/19 1:24 AM, Eric Anholt wrote: > > Hoegeun Kwon <hoegeun.kwon@samsung.com> <hoegeun.kwon@samsung.com> writes: > > > On 4/2/19 2:48 AM, Eric Anholt wrote: > > Hoegeun Kwon <hoegeun.kwon@samsung.com> <hoegeun.kwon@samsung.com> writes: > > > There is a problem when often dpms goes from off to on. pm idle is not > in sync and the problem occurs. Modify pm_runtime_put from > asynchronous to synchronous. > > Why would we need the power domain to go to off before we try to come > back? Any idea? Also, please specify what "the problem" is. > > Hi Eric, > > > First thank you for your review. > > There is a problem failed to runtime PM enable on DSI when often dpms > > What do you mean by "failed to runtime PM enable"? The > pm_runtime_enable() returned an error? Have you investigated the source > that error, if so? > > I'm sorry for the late reply. > > The pm_runtime_enable() is not returned because return value is void. > > The problem is that if the error log is not output > and the DPMS off on is repeated, the screen will stop. > > As a result of debugging the problem, I think that synchronization > is a problem caused by dsi pm_suspend and resume. > > So when we entered the pm runtime idle state, if used with sync, > the problem does not occur. > > Sounds like not enough hystersis between disable/enable, i.e. some msleep missing somewhere. That's at least my guess, we've had a bunch of these with delayed runtime suspend of various things in i915. -Daniel > > Best regards, > Hoegeun > > > > > > > -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch [-- Attachment #1.1.2: Type: text/html, Size: 3973 bytes --] [-- Attachment #1.2: noname --] [-- Type: image/gif, Size: 13402 bytes --] [-- Attachment #2: Type: text/plain, Size: 159 bytes --] _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2019-05-22 11:33 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <CGME20190329012926epcas1p3fbfa796a221c2fd105a84c31c80016d5@epcas1p3.samsung.com> 2019-03-29 1:29 ` [PATCH] drm/vc4: Fix with pm_runtime synchronization on DSI Hoegeun Kwon 2019-04-01 17:48 ` Eric Anholt 2019-04-08 1:05 ` Hoegeun Kwon 2019-04-09 16:24 ` Eric Anholt 2019-05-22 10:24 ` Hoegeun Kwon 2019-05-22 11:32 ` Daniel Vetter
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.