Hi, On 9/12/22 13:11, Andy Shevchenko wrote: > On Sun, Sep 11, 2022 at 07:16:37PM +0200, Hans de Goede wrote: >> There is no reason for atomisp to use a rt_mutex instead of a normal >> mutex, so switch over to a normal mutex. >> >> All the changes in this patch are just s/rt_mutex/mutex/. >> >> This is a preparation patch for switching the ioctl locking over >> to using the video_dev.lock member so that the v4l2-core takes >> care of the locking. > > So the idea behind rt_mutex here is to inherit the priority on the task. Right. > I'm wondering what could be possible the bottle neck this is trying to > solve. I don't think there is any specific reasoning behind the code using this. The atomisp code is quite questionable in lots of cases and I have a feeling this was just a case of "oh this sounds like it is faster, lets use this" . > If there is no other V4L2 driver that does the same, any specific > run flow of AtomISP v2 code that may suffer of this? See above. Regards, Hans
