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]

 



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






[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