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