lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Wed, 26 Jun 2019 11:22:49 +0100
From:   Liviu Dudau <liviu.dudau@....com>
To:     Pavel Machek <pavel@....cz>
Cc:     linux-kernel@...r.kernel.org, Wen He <wen.he_1@....com>,
        Sasha Levin <sashal@...nel.org>
Subject: Re: [PATCH 4.19 55/90] drm/arm/mali-dp: Add a loop around the second
 set CVAL and try 5 times

On Wed, Jun 26, 2019 at 09:56:19AM +0200, Pavel Machek wrote:
> 
> On Mon 2019-06-24 17:56:45, Greg Kroah-Hartman wrote:
> > [ Upstream commit 6a88e0c14813d00f8520d0e16cd4136c6cf8b4d4 ]
> > 
> > This patch trying to fix monitor freeze issue caused by drm error
> > 'flip_done timed out' on LS1028A platform. this set try is make a loop
> > around the second setting CVAL and try like 5 times before giveing up.
> 
> 
> > @@ -204,8 +205,18 @@ static void malidp_atomic_commit_hw_done(struct drm_atomic_state *state)
> >  			drm_crtc_vblank_get(&malidp->crtc);
> >  
> >  		/* only set config_valid if the CRTC is enabled */
> > -		if (malidp_set_and_wait_config_valid(drm) < 0)
> > +		if (malidp_set_and_wait_config_valid(drm) < 0) {
> > +			/*
> > +			 * make a loop around the second CVAL setting and
> > +			 * try 5 times before giving up.
> > +			 */
> > +			while (loop--) {
> > +				if (!malidp_set_and_wait_config_valid(drm))
> > +					break;
> > +			}
> >  			DRM_DEBUG_DRIVER("timed out waiting for updated configuration\n");
> > +		}
> > +
> 
> We'll still get the debug message even if
> malidp_set_and_wait_config_valid() suceeded. That does not sound
> right.
> 									Pavel

It does, because the first malidp_set_and_wait_config_valid() has timed out, which
is not the expected behaviour at all. LS1028A has some quirks that require this
loop in order to get it out of some stalled state, but any other implementation
of the IP should not have this issue.

Hope this clarifies things.

Best regards,
Liviu

> -- 
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html



-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ