Hi Krzysztof, thanks for the quick feedback.
On Wed, 2025-02-12 at 18:22 +0100, Krzysztof Kozlowski wrote:
> On 12/02/2025 18:09, Matthew Majewski wrote:
> > Create a new yaml schema file to describe the device tree bindings
> > for
> > the generic m2m-deinterlace driver.
>
>
> Bindings are for hardware, not drivers, and usually not generic.
>
Ok, I'll change the wording from "driver" to "device" in V2.
> Please describe here exemplary devices.
The m2m-deinterlace device can be used on any hardware that provides a
MEM_TO_MEM and interleaved capable dma channel. I'll note that in the
commit message for V2 as well.
> >
> > +description: |
> > + A generic memory2memory device for deinterlacing video
> > + using dmaengine.
>
> And what is this generic device supposed to do? What fits to generic
> device?
>
The term "generic" was taken from the driver description. It's generic
insofar as it only relies on the dmaengine API for processing (and
hence is relatively platform agnostic).
I will add more information about the device in the description for V2.
I'll also mention that it's intended for converting between interlaced
and non-interlaced formats by line-doubling.
> > +
> > +properties:
> > + compatible:
> > + const: m2m-deinterlace
> > +
> > + dma-names:
> > + items:
> > + - const: rxtx
> > +
> > + dmas:
> > + items:
> > + - description: mem-to-mem capable DMA channel
> > +
> > +required:
> > + - compatible
> > + - dma-names
> > + - dmas
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > + m2m-deinterlace {
> > + compatible = "m2m-deinterlace";
> > + dma-names = "rxtx";
> > + dmas = <&edma 20 0>;
>
>
> This all looks rather like bindings for driver and not even quite
> generic because looks quite simple. I guess media folks will provide
> more input, but anyway it looks a bit not-DT-enough.
>
> > + };
Yes, the bindings are much simpler than a typical media device, but
that is because the m2m-deinterlace device only needs to be provided a
handle to a dma channel to function properly. My reasoning for adding
dt-bindings for this device is because it is a consumer of a dma-
channel and the dt bindings are a platform-agnostic way to be able to
provide a specific dma channel to the device.
As an example, say on an embedded device I have a dma controller which
provides multiple interleaved MEM_TO_MEM capable channels. I want the
m2m-deinterlace device to consume one particular channel because it is
higher-priority than the others. With these dt-bindings I can simply
specify the correct dma channel that should be used. Without the
device-tree bindings I would have to manually edit the driver to filter
for the correct dma channel to be used, but then the device is no
longer "generic".
It would be helpful to hear what the media people have to say about it.
The m2m-deinterlace device is a bit of an edge-case since it's not
quite a "virtual" device since it relies on the presence of specific
dma hardware. However, it doesn't follow the typical conventions of any
other in-tree media driver that consumes a dma channel, which all seem
to have dt-bindings.
Best,
Matthew
