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

[Tobias Jakobi]

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