Hi, On 2/17/24 19:52, Andy Shevchenko wrote: > On Sat, Feb 17, 2024 at 1:25 PM Hans de Goede <hdegoede@xxxxxxxxxx> wrote: >> >> The atomisp driver's Android heritage makes it weird in that >> even though it uses MC + subdev-s it is designed to primarily >> be controlled through its /dev/video# node. >> >> It implements s_input on /dev/video# to select which sensor to use, >> while ignoring setup_link calls to enable a link to another sensor. >> >> Add support for selecting the active sensor the MC way by adding >> setup_link support. > > ->link_setup() > >> The implementation is a bit convoluted due to the atomisp driver's >> heritage. > > ... > >> #include "atomisp_common.h" >> #include "atomisp_compat.h" >> #include "atomisp_fops.h" >> +#include "atomisp_ioctl.h" >> #include "atomisp_internal.h" > > Hmm... Perhaps keep it ordered? Yeah my bad, I intended to keep it ordered but I somehow got it wrong. this and the commit msg remark are both fixed in my personal tree now. > > ... > >> + mutex_lock(&isp->mutex); > > Side note: Are you planning to use cleanup.h at some point? Maybe. I have no objections against. For functions needing e.g. heap memory only locally it certainly makes sense. Regards, Hans > >> + ret = atomisp_pipe_check(&asd->video_out, true); >> + if (ret == 0) >> + asd->input_curr = i; >> + mutex_unlock(&isp->mutex); >> + >> + return ret; > >
