>-----Original Message----- >From: Jacopo Mondi <jacopo.mo...@ideasonboard.com> >Sent: Saturday, August 2, 2025 5:23 PM >To: Mauro Carvalho Chehab <mche...@kernel.org>; Devarsh Thakkar ><devar...@ti.com>; Benoit Parrot <bpar...@ti.com>; Hans Verkuil ><hverk...@kernel.org>; Mike Isely <is...@pobox.com>; Laurent Pinchart ><laurent.pinch...@ideasonboard.com>; Hans de Goede <ha...@kernel.org>; >Parthiban Veerasooran <parthiban.veerasoo...@microchip.com>; Christian >Gromm <christian.gr...@microchip.com>; Greg Kroah-Hartman ><gre...@linuxfoundation.org>; Alex Shi <al...@kernel.org>; Yanteng Si ><si.yant...@linux.dev>; Dongliang Mu <dz...@hust.edu.cn>; Jonathan >Corbet <cor...@lwn.net>; Tomasz Figa <tf...@chromium.org>; Marek >Szyprowski <m.szyprow...@samsung.com>; Andy Walls ><awa...@md.metrocast.net>; Michael Tretter <m.tret...@pengutronix.de>; >Pengutronix Kernel Team <ker...@pengutronix.de>; Bin Liu ><bin....@mediatek.com>; Matthias Brugger <matthias....@gmail.com>; >AngeloGioacchino Del Regno <angelogioacchino.delre...@collabora.com>; >Dmitry Osipenko <dig...@gmail.com>; Thierry Reding ><thierry.red...@gmail.com>; Jonathan Hunter <jonath...@nvidia.com>; >Mirela Rabulea <mirela.rabu...@nxp.com>; Shawn Guo ><shawn...@kernel.org>; Sascha Hauer <s.ha...@pengutronix.de>; Fabio >Estevam <feste...@gmail.com>; Kieran Bingham ><kieran.bingham+rene...@ideasonboard.com>; Michal Simek ><michal.si...@amd.com>; Ming Qian <ming.q...@nxp.com>; Eagle Zhou ><eagle.z...@nxp.com>; Xavier Roumegue (OSS) ><xavier.roume...@oss.nxp.com>; Philipp Zabel <p.za...@pengutronix.de>; >Vikash Garodia <quic_vgaro...@quicinc.com>; Dikshita Agarwal ><quic_diksh...@quicinc.com>; Abhinav Kumar <abhinav.ku...@linux.dev>; >Bryan O'Donoghue <bryan.odonog...@linaro.org>; Sylwester Nawrocki ><sylvester.nawro...@gmail.com>; Jernej Skrabec <jernej.skra...@gmail.com>; >Chen-Yu Tsai <w...@csie.org>; Samuel Holland <sam...@sholland.org>; >Daniel Almeida <daniel.alme...@collabora.com>; Neil Armstrong ><neil.armstr...@linaro.org>; Kevin Hilman <khil...@baylibre.com>; Jerome >Brunet <jbru...@baylibre.com>; Martin Blumenstingl ><martin.blumensti...@googlemail.com>; Nas Chung ><nas.ch...@chipsnmedia.com>; Jackson Lee ><jackson....@chipsnmedia.com>; Minghsiu Tsai ><minghsiu.t...@mediatek.com>; Houlong Wei <houlong....@mediatek.com>; >Andrew-CT Chen <andrew-ct.c...@mediatek.com>; Tiffany Lin ><tiffany....@mediatek.com>; Yunfei Dong <yunfei.d...@mediatek.com>; >Geert Uytterhoeven <geert+rene...@glider.be>; Magnus Damm ><magnus.d...@gmail.com>; Mikhail Ulyanov ><mikhail.ulya...@cogentembedded.com>; Jacob Chen <jacob- >c...@iotwrt.com>; Ezequiel Garcia <ezequ...@vanguardiasur.com.ar>; Heiko >Stuebner <he...@sntech.de>; Detlev Casanova ><detlev.casan...@collabora.com>; Krzysztof Kozlowski <k...@kernel.org>; >Alim Akhtar <alim.akh...@samsung.com>; Sylwester Nawrocki ><s.nawro...@samsung.com>; Łukasz Stelmach <l.stelm...@samsung.com>; >Andrzej Pietrasiewicz <andrzejtp2...@gmail.com>; Jacek Anaszewski ><jacek.anaszew...@gmail.com>; Andrzej Hajda <andrzej.ha...@intel.com>; >Fabien Dessenne <fabien.desse...@foss.st.com>; Hugues Fruchet ><hugues.fruc...@foss.st.com>; Jean-Christophe Trotin <jean- >christophe.tro...@foss.st.com>; Maxime Coquelin ><mcoquelin.st...@gmail.com>; Alexandre Torgue ><alexandre.tor...@foss.st.com>; Nicolas Dufresne ><nicolas.dufre...@collabora.com>; Benjamin Gaignard ><benjamin.gaign...@collabora.com>; Steve Longerbeam ><slongerb...@gmail.com>; Maxime Ripard <mrip...@kernel.org>; Paul >Kocialkowski <pa...@sys-base.io>; Niklas Söderlund ><niklas.soderl...@ragnatech.se>; Robert Foss <rf...@kernel.org>; Todor >Tomov <todor....@gmail.com>; Vladimir Zapolskiy ><vladimir.zapols...@linaro.org>; Corentin Labbe <cla...@baylibre.com>; >Sakari Ailus <sakari.ai...@linux.intel.com>; Bingbu Cao ><bingbu....@intel.com>; Tianshu Qiu <tian.shu....@intel.com>; Stanislaw >Gruszka <stanislaw.grus...@linux.intel.com> >Cc: linux-me...@vger.kernel.org; linux-ker...@vger.kernel.org; linux- >stag...@lists.linux.dev; linux-...@vger.kernel.org; linux-arm- >ker...@lists.infradead.org; linux-media...@lists.infradead.org; linux- >te...@vger.kernel.org; i...@lists.linux.dev; linux-renesas-...@vger.kernel.org; >linux-arm-...@vger.kernel.org; linux-samsung-...@vger.kernel.org; linux- >su...@lists.linux.dev; linux-...@vger.kernel.org; linux- >amlo...@lists.infradead.org; linux-rockc...@lists.infradead.org; linux- >st...@st-md-mailman.stormreply.com; mjpeg-users@lists.sourceforge.net; >Jacopo Mondi <jacopo.mo...@ideasonboard.com> >Subject: [EXT] [PATCH 14/65] media: amphion: Delete v4l2_fh synchronously >in .release() > >Caution: This is an external email. Please take care when clicking links or >opening attachments. When in doubt, report the message using the 'Report >this email' button > > >From: Laurent Pinchart <laurent.pinch...@ideasonboard.com> > >The v4l2_fh initialized and added in vpu_v4l2_open() is delete and cleaned up >when the last reference to the vpu_inst is released. This may happen later than >at vpu_v4l2_close() time. > >Not deleting and cleaning up the v4l2_fh when closing the file handle to the >video device is not ideal, as the v4l2_fh will still be present in the video >device's >fh_list, and will store a copy of events queued to the video device. There may >also be other side effects of keeping alive an object that represents an open >file >handle after the file handle is closed. > >The v4l2_fh instance is embedded in the vpu_inst structure, and is accessed in >two different ways: > >- in vpu_notify_eos() and vpu_notify_source_change(), to queue V4L2 > events to the file handle ; and > >- through the driver to access the v4l2_fh.m2m_ctx pointer. > >The v4l2_fh.m2m_ctx pointer is not touched by v4l2_fh_del() and >v4l2_fh_exit(). It is set to NULL by the driver when closing the file handle, >in >vpu_v4l2_close(). > >The vpu_notify_eos() and vpu_notify_source_change() functions are called in >vpu_set_last_buffer_dequeued() and vdec_handle_resolution_change() >respectively, only if the v4l2_fh.m2m_ctx pointer is not NULL. There is >therefore >a guarantee that no new event will be queued to the v4l2_fh after >vpu_v4l2_close() destroys the m2m_ctx. > >The vpu_notify_eos() function is also called from vpu_vb2_buf_finish(), which >is guaranteed to be called for all queued buffers when >vpu_v4l2_close() calls v4l2_m2m_ctx_release(), and will not be called later. > >It is therefore safe to assume that the driver will not touch the v4l2_fh, >except >to check the m2m_ctx pointer, after vpu_v4l2_close() destroys the m2m_ctx. >We can safely delete and cleanup the v4l2_fh synchronously in >vpu_v4l2_close(). > >Signed-off-by: Laurent Pinchart <laurent.pinch...@ideasonboard.com> >Signed-off-by: Jacopo Mondi <jacopo.mo...@ideasonboard.com>
Reviewed-by: Ming Qian <ming.q...@oss.nxp.com> >--- > drivers/media/platform/amphion/vpu_v4l2.c | 7 +++++-- > 1 file changed, 5 insertions(+), 2 deletions(-) > >diff --git a/drivers/media/platform/amphion/vpu_v4l2.c >b/drivers/media/platform/amphion/vpu_v4l2.c >index >306d94e0f8e79faaacfa35b28e5786860f7bd1ca..57ca6262bb04b356a85e217ef >51cfb13cb9a0a36 100644 >--- a/drivers/media/platform/amphion/vpu_v4l2.c >+++ b/drivers/media/platform/amphion/vpu_v4l2.c >@@ -724,8 +724,6 @@ static int vpu_v4l2_release(struct vpu_inst *inst) > > v4l2_ctrl_handler_free(&inst->ctrl_handler); > mutex_destroy(&inst->lock); >- v4l2_fh_del(&inst->fh); >- v4l2_fh_exit(&inst->fh); > > call_void_vop(inst, cleanup); > >@@ -794,6 +792,8 @@ int vpu_v4l2_open(struct file *file, struct vpu_inst >*inst) > > return 0; > error: >+ v4l2_fh_del(&inst->fh); >+ v4l2_fh_exit(&inst->fh); > vpu_inst_put(inst); > return ret; > } >@@ -813,6 +813,9 @@ int vpu_v4l2_close(struct file *file) > call_void_vop(inst, release); > vpu_inst_unlock(inst); > >+ v4l2_fh_del(&inst->fh); >+ v4l2_fh_exit(&inst->fh); >+ > vpu_inst_unregister(inst); > vpu_inst_put(inst); > > >-- >2.49.0 _______________________________________________ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
