On 2014-12-01 16:54, Thierry Reding wrote:
On Sun, Nov 30, 2014 at 01:35:25AM +0100, tjak...@math.uni-bielefeld.de
wrote:
From: Tomasz Stanislawski <t.stanisl...@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.stanisl...@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
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
