On Wed, 1 Oct 2025 at 07:59, Krzysztof Kozlowski <[email protected]> wrote: > > 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.
And 15 second look at one of the patches already confirmed this: replicating downstream issue - undocumented DT ABI not following current style, code relying on some other downstream drivers. 15 seconds was enough to find it.
