Re: [PATCH 01/17] media: atomisp: Use a normal mutex for the main lock

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux Driver Development]     [Linux Driver Backports]     [DMA Engine]     [Linux GPIO]     [Linux SPI]     [Video for Linux]     [Linux USB Devel]     [Linux Coverity]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux