On 2014-12-01 16:54, Thierry Reding wrote: > 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
Hmm, I'm pretty new to spinlocks (only have worked with the usual mutex stuff in userspace), but wouldn't that mean that it is then possible for mixer_win_reset to execute while a (previous) vp_win_reset is still running? With best wishes, Tobias
