On Wed, 1 Oct 2025 at 00:46, Marek Szyprowski <[email protected]> wrote: > > Hi Krzysztof, > > On 30.09.2025 07:54, Krzysztof Kozlowski wrote: > > On Tue, 30 Sept 2025 at 12:56, Himanshu Dewangan <[email protected]> > > wrote: > >> From: Nagaraju Siddineni <[email protected]> > >> > >> Introduce a new Kconfig entry VIDEO_EXYNOS_MFC for the Samsung > >> Exynos MFC driver that supports firmware version 13 and later. > >> Extend the top‑level Samsung platform Kconfig to disable the legacy > >> S5P‑MFC driver when its firmware version is > v12 and to select the > >> new Exynos‑MFC driver only when VIDEO_SAMSUNG_S5P_MFC is not enabled. > >> > >> Add exynos-mfc Kconfig and Makefile for probe functionality and creation > >> of decoder and encoder device files by registering the driver object > >> exynos_mfc.o and other relevant source files. > >> > >> Provide header files mfc_core_ops.h and mfc_rm.h containing core > >> operation prototypes, resource‑manager helpers, > >> and core‑selection utilities. > >> > >> Add a configurable option MFC_USE_COREDUMP to enable core‑dump > >> support for debugging MFC errors. > >> > >> These changes bring support for newer Exynos‑based MFC hardware, > >> cleanly separate it from the legacy S5P‑MFC driver, and lay the > >> groundwork for future feature development and debugging. > >> > > No, NAK. Existing driver is well tested and already used on newest > > Exynos SoC, so all this new driver is exactly how you should not work > > in upstream. You need to integrate into existing driver. > > > > Samsung received this review multiple times already. > > Please don't be so categorical. The MFC hardware evolved quite a bit > from the ancient times of S5PV210 SoC, when s5p-mfc driver was designed. > The feature list of the new hardware hardly matches those and I really > don't see the reason for forcing support for so different hardware in a > single driver. Sometimes it is easier just to have 2 separate drivers if > the common part is just the acronym in the hardware block name... >
I know it is easier for Samsung to write new driver, but this should answer to - why the maintainers and the community would like to maintain two drivers. Sure, make a case why we would like to take this code. The easiest argument here why we wouldn't is: new vendor downstream code means replicating all known issues, old coding style, everything which we already fixed and changed.
