On Mon, Oct 5, 2020 at 5:49 PM Sakari Ailus <sakari.ailus@xxxxxxxxxxxxxxx> wrote: > > Hi Alexandre, > > On Sun, Oct 04, 2020 at 09:22:34PM +0900, Alexandre Courbot wrote: > > The addition of MT8183 support added a dependency on the SCP remoteproc > > module. However the initial patch used the "select" Kconfig directive, > > which may result in the SCP module to not be compiled if remoteproc was > > disabled. In such a case, mtk-vcodec would try to link against > > non-existent SCP symbols. "select" was clearly misused here as explained > > in kconfig-language.txt. > > > > Replace this by a "depends" directive on at least one of the VPU and > > SCP modules, to allow the driver to be compiled as long as one of these > > is enabled, and adapt the code to support this new scenario. > > > > Also adapt the Kconfig text to explain the extra requirements for MT8173 > > and MT8183. > > > > Reported-by: Sakari Ailus <sakari.ailus@xxxxxxxxxxxxxxx> > > Signed-off-by: Alexandre Courbot <acourbot@xxxxxxxxxxxx> > > Acked-by: Randy Dunlap <rdunlap@xxxxxxxxxxxxx> # build-tested > > Thanks for the patch! > > Acked-by: Sakari Ailus <sakari.ailus@xxxxxxxxxxxxxxx> Thanks! > > I wonder if this driver suffers from similar object lifetime management > issues than V4L2 and MC do, albeit not related to either. Say, what happens > if you unbind the other device while mtk-vcodec is in use? That's a question that maybe the driver maintainers can answer, but from my experience during development I have been able to unload one of the two mtk-vcodec-* modules while keeping the other one active.
