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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Nov 30, 2014 at 01:35:25AM +0100, tjakobi@xxxxxxxxxxxxxxxxxxxxx wrote:
> From: Tomasz Stanislawski <t.stanislaws@xxxxxxxxxxx>
> 
> 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@xxxxxxxxxxx>
> ---
>  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

Attachment: pgpfabvqjvt0U.pgp
Description: PGP signature


[Index of Archives]     [Linux SoC Development]     [Linux Rockchip Development]     [Linux USB Development]     [Video for Linux]     [Linux Audio Users]     [Linux SCSI]     [Yosemite News]

  Powered by Linux