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
