Re: [ANN] Registration and Request for Topics for the Media Summit on May 13th in Nice, France

Chen-Yu Tsai
2025-04-08T06:32:19Z

On Tue, Apr 8, 2025 at 1:32 PM Mauro Carvalho Chehab
<mchehab+huawei@kernel.org> wrote:
>
> Em Mon, 7 Apr 2025 22:39:09 +0300
> Laurent Pinchart <laurent.pinchart@ideasonboard.com> 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"

This actually has two drivers:

a. cedrus

IIRC Paul has some more patches that are part of the stateless encoding
work. Those would finish the remaining TODO items. Even without those
I believe the existing decoding functionality is working fine.

b. sun6i-isp

This was also done by Paul during his time at Bootlin. However I don't
think anyone is using it, since the DT parts never landed.

ChenYu

> 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.
>
> > 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.
>
> 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,
> Mauro
>