On Wed, Sep 21, 2022 at 11:52 AM Hans de Goede <hdegoede@xxxxxxxxxx> wrote: > 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" . Honestly, this is exactly what is my attitude towards the AtomISP2 codebase. But I asked to be sure that you probably investigated that more. > > 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. -- With Best Regards, Andy Shevchenko
