public inbox for linux-media@vger.kernel.org
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Cc: "Hans Verkuil" <hverkuil@xs4all.nl>,
	"Linux Media Mailing List" <linux-media@vger.kernel.org>,
	"Mauro Carvalho Chehab" <mchehab@kernel.org>,
	"Sean Young" <sean@mess.org>,
	"Sakari Ailus" <sakari.ailus@linux.intel.com>,
	"Sebastian Fricke" <sebastian.fricke@collabora.com>,
	"Ricardo Ribalda" <ribalda@chromium.org>,
	"Nicolas Dufresne" <nicolas.dufresne@collabora.com>,
	"Jacopo Mondi" <jacopo.mondi@ideasonboard.com>,
	"Niklas Söderlund" <niklas.soderlund@ragnatech.se>,
	"Tomi Valkeinen" <tomi.valkeinen@ideasonboard.com>,
	"Alain Volmat" <alain.volmat@foss.st.com>,
	"stanimir.k.varbanov@gmail.com" <stanimir.k.varbanov@gmail.com>,
	"Bryan O'Donoghue" <bryan.odonoghue@linaro.org>,
	"Dave Stevenson" <dave.stevenson@raspberrypi.com>,
	"Daniel Almeida" <daniel.almeida@collabora.com>,
	"Michael Tretter" <m.tretter@pengutronix.de>,
	"Tomasz Figa" <tfiga@chromium.org>,
	"Hu, Jerry W" <jerry.w.hu@intel.com>,
	"Steve Cho" <stevecho@chromium.org>,
	"Kieran Bingham" <kieran.bingham@ideasonboard.com>,
	"Kevin Hilman" <khilman@baylibre.com>,
	"Paul Kocialkowski" <paulk@sys-base.io>,
	"Benjamin Mugnier" <benjamin.mugnier@foss.st.com>
Subject: Re: [ANN] Registration and Request for Topics for the Media Summit on May 13th in Nice, France
Date: Tue, 8 Apr 2025 11:54:11 +0300	[thread overview]
Message-ID: <20250408085411.GA31475@pendragon.ideasonboard.com> (raw)
In-Reply-To: <20250408133142.030bd1cf@sal.lan>

Hi Mauro,

On Tue, Apr 08, 2025 at 01:31:42PM +0800, Mauro Carvalho Chehab wrote:
> Em Mon, 7 Apr 2025 22:39:09 +0300 Laurent Pinchart escreveu:
> 
> > I would like to propose the following topic.
> > 
> > Review of the status of staging drivers
> > 
> > We have a set of 11 drivers in drivers/staging/media/, with various
> > states of maturity and development activity.
> 
> On a quick look, we have there:
> 
> 1. source "drivers/staging/media/atomisp/Kconfig"
> 2. source "drivers/staging/media/av7110/Kconfig"
> 3. source "drivers/staging/media/imx/Kconfig"
> 4. source "drivers/staging/media/ipu3/Kconfig"
> 5. source "drivers/staging/media/max96712/Kconfig"
> 6. source "drivers/staging/media/meson/vdec/Kconfig"
> 7. source "drivers/staging/media/rkvdec/Kconfig"
> 8. source "drivers/staging/media/starfive/Kconfig"
> 9. source "drivers/staging/media/sunxi/Kconfig"
> 10. source "drivers/staging/media/tegra-video/Kconfig"
> 11. source "drivers/staging/media/deprecated/atmel/Kconfig"
> 
> > drivers/staging/ is not meant as a place for drivers to die,
> 
> It is, actually: we usually move things there before dropping,
> because, on most cases, they could be salvaged if someone is
> interested on it.

I should have be clearer in my e-mail. We indeed use staging in two
different ways, for drivers to go in the kernel, and drivers to get out.
The latter is handled by the drivers/staging/media/deprecated/
directory. As I wanted to focus on drivers going in, I ignored that side
for the purpose of this discussion. I see no issue with moving drivers
to deprecated/ for a few releases before deleting them completely.

For drivers that are merged in the kernel through staging, however, my
opinion is that they're not meant to be left there to die, or they
shouldn't get merged in the first place.

> > we should nudge the relevant
> > maintainers and consider dropping drivers that show no hope of
> > progressing.
> 
> Fully agreed.
> 
> -
> 
> Yet, while it makes sense to have action plans for drivers on staging,
> I don't think that the Media Summit is the best place to discuss,
> as people that might be involved with them may not be able to
> participate there.

I'm not asking for final decisions on individual drivers to be made
there. The topic is about deciding on a subsystem policy, communicating
it clearly, and finding the right incentives to ensure those drivers get
maintained and eventually graduate to drivers/media/.

> See, there are different situations there, like:
> 
> - platform drivers: at worse case, those should be removed when
>   the core/DT support for such platform is removed. We removed
>   several such drivers in the past. We can also remove them earlier,
>   if there are reasons for doing that and nobody is complaining;
> 
> - drivers like atomisp that takes a lot of efforts to be promoted.
>   As long as I see some progress (and we've been seeing progress
>   on every kernel version), I can't see any reason why removing it.
> 
> - drivers like ipu3, which is for an entire family of PC CPUs.
>   I prefer not dropping drivers like these unless we have very good
>   reasons to do so. On the other hand, we are seeing very little
>   progress on those.
> 
> Anyway, better to split this into different threads, copying
> the people involved on the recent changes for such drivers.

-- 
Regards,

Laurent Pinchart

  parent reply	other threads:[~2025-04-08  8:54 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-14  9:59 [ANN] Registration and Request for Topics for the Media Summit on May 13th in Nice, France Hans Verkuil
2025-03-14 11:44 ` Hans Verkuil
2025-03-25 15:16 ` Jai Luthra
2025-03-28 13:58 ` Hans Verkuil
2025-04-08  9:28   ` Martin Hecht
2025-04-08 21:06   ` Ricardo Ribalda
2025-04-07 19:39 ` Laurent Pinchart
2025-04-08  5:31   ` Mauro Carvalho Chehab
2025-04-08  6:32     ` Chen-Yu Tsai
2025-04-08  9:20       ` Paul Kocialkowski
2025-04-08  6:42     ` Hans Verkuil
2025-04-08  6:58       ` Mauro Carvalho Chehab
2025-04-08  8:54     ` Laurent Pinchart [this message]
2025-04-08  6:21   ` Hans Verkuil

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250408085411.GA31475@pendragon.ideasonboard.com \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=alain.volmat@foss.st.com \
    --cc=benjamin.mugnier@foss.st.com \
    --cc=bryan.odonoghue@linaro.org \
    --cc=daniel.almeida@collabora.com \
    --cc=dave.stevenson@raspberrypi.com \
    --cc=hverkuil@xs4all.nl \
    --cc=jacopo.mondi@ideasonboard.com \
    --cc=jerry.w.hu@intel.com \
    --cc=khilman@baylibre.com \
    --cc=kieran.bingham@ideasonboard.com \
    --cc=linux-media@vger.kernel.org \
    --cc=m.tretter@pengutronix.de \
    --cc=mchehab+huawei@kernel.org \
    --cc=mchehab@kernel.org \
    --cc=nicolas.dufresne@collabora.com \
    --cc=niklas.soderlund@ragnatech.se \
    --cc=paulk@sys-base.io \
    --cc=ribalda@chromium.org \
    --cc=sakari.ailus@linux.intel.com \
    --cc=sean@mess.org \
    --cc=sebastian.fricke@collabora.com \
    --cc=stanimir.k.varbanov@gmail.com \
    --cc=stevecho@chromium.org \
    --cc=tfiga@chromium.org \
    --cc=tomi.valkeinen@ideasonboard.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox