On Wed, May 22, 2019 at 12:24 PM Hoegeun Kwon <hoegeun.k...@samsung.com>
wrote:

> On 4/10/19 1:24 AM, Eric Anholt wrote:
>
> Hoegeun Kwon <hoegeun.k...@samsung.com> <hoegeun.k...@samsung.com> writes:
>
>
> On 4/2/19 2:48 AM, Eric Anholt wrote:
>
> Hoegeun Kwon <hoegeun.k...@samsung.com> <hoegeun.k...@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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Reply via email to