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