On Wed, 1 Oct 2025 at 00:46, Marek Szyprowski [off-list ref] wrote:

Hi Krzysztof,

On 30.09.2025 07:54, Krzysztof Kozlowski wrote:

quoted

On Tue, 30 Sept 2025 at 12:56, Himanshu Dewangan [off-list ref] wrote:

quoted

From: Nagaraju Siddineni <redacted>

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.