Em Sat, 16 Dec 2017 19:53:55 +0800
Jia-Ju Bai <baijiaju1990@xxxxxxxxx> escreveu:
> Hi,
>
> On 2017/12/15 22:51, Fabien DESSENNE wrote:
> > Hi
> >
> > On 12/12/17 14:47, Jia-Ju Bai wrote:
> >> The driver may sleep under a spinlock.
> >> The function call path is:
> >> bdisp_device_run (acquire the spinlock)
> >> bdisp_hw_reset
> >> msleep --> may sleep
> >>
> >> To fix it, msleep is replaced with mdelay.
> > May I suggest you to use readl_poll_timeout_atomic (instead of the whole
> > "for" block): this fixes the problem and simplifies the code?
>
> Okay, I have submitted a patch according to your advice.
> You can have a look :)
This can still be usind mdelay() to wait for a long time.
It doesn't seem wise to do that, as it could cause system
contention. Couldn't this be reworked in a way to avoid
having the spin locked while sleeping?
Once we had a similar issue on Siano, and it was solved by this
commit 3cdadc50bbe8f04c1231c8af614cafd7ddd622bf
Author: Richard Zidlicky <rz@xxxxxxxxxxxxxx>
Date: Tue Aug 24 09:52:36 2010 -0300
V4L/DVB: dvb: fix smscore_getbuffer() logic
Drivers shouldn't sleep while holding a spinlock. A previous workaround
were to release the spinlock before callinc schedule().
This patch uses a different approach: it just waits for the
siano hardware to answer.
Signed-off-by: Richard Zidlicky <rz@xxxxxxxxxxxxxx>
Cc: stable@xxxxxxxxxx
Signed-off-by: Mauro Carvalho Chehab <mchehab@xxxxxxxxxx>
The code as changed to use wait_event() at the kthread that was
waiting for data to arrive. Only when the data is ready, the
code with the spin lock is called.
It made the driver a way more stable, and didn't add any penalties
of needing to do long delays on a non-interruptible code.
Thanks,
Mauro
