drm: exynos: mixer: fix using usleep() in atomic context

Thierry Reding thierry.reding at gmail.com
Mon Dec 1 07:54:49 PST 2014


On Sun, Nov 30, 2014 at 01:35:25AM +0100, tjakobi at math.uni-bielefeld.de wrote:
> From: Tomasz Stanislawski <t.stanislaws at samsung.com>
> 
> This patch fixes calling usleep_range() after taking reg_slock
> using spin_lock_irqsave(). The mdelay() is used instead.
> Waiting in atomic context is not the best idea in general.
> Hopefully, waiting occurs only when Video Processor fails
> to reset correctly.
> 
> Signed-off-by: Tomasz Stanislawski <t.stanislaws at samsung.com>
> ---
>  drivers/gpu/drm/exynos/exynos_mixer.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c b/drivers/gpu/drm/exynos/exynos_mixer.c
> index a41c84e..cc7cccc 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> @@ -632,7 +632,7 @@ static void vp_win_reset(struct mixer_context *ctx)
>  		/* waiting until VP_SRESET_PROCESSING is 0 */
>  		if (~vp_reg_read(res, VP_SRESET) & VP_SRESET_PROCESSING)
>  			break;
> -		usleep_range(10000, 12000);
> +		mdelay(10);
>  	}
>  	WARN(tries == 0, "failed to reset Video Processor\n");
>  }

I can't see a reason why you would need to hold the lock around this
code. Perhaps a better way to fix this would be to drop the lock before
calling vp_win_reset()?

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141201/e30b9bbe/attachment.sig>


More information about the dri-devel mailing list