[PATCH v2 0/2] media: m2m-deinterlace: add device-tree support

[PATCH v2 0/2] media: m2m-deinterlace: add device-tree support

[Matthew Majewski]

Hello all, this patch series adds device-tree support for the generic
m2m-deinterlace driver.

A specific dma controller channel can now be provided to the driver
via the dt, but the driver still supports the original dma query if an
of_node is not present. This should preserve backwards compatibility
with platform drivers that directly instantiate the device.

Probing the m2m-deinterlace device via device-tree was tested on the
BeagleBone Black with an m2m-appropriate edma channel.

Changes From v1 [1]:
 - [PATCH 1/2] media: dt-bindings: Add dt bindings for m2m-deinterlace
   - clarify device description and commit message for dt bindings
   - correct format error reported by yamllint for dt bindings
 - [PATCH 2/2] media: m2m-deinterlace: add device-tree support
   - no changes

[1] https://lore.kernel.org/linux-media/20250212170901.3881838-1-mattwmajewski@gmail.com/

Best,

Matthew Majewski

Matthew Majewski (2):
  media: dt-bindings: Add dt bindings for m2m-deinterlace device
  media: m2m-deinterlace: add device-tree support

 .../bindings/media/m2m-deinterlace.yaml       | 44 +++++++++++++++++++
 drivers/media/platform/m2m-deinterlace.c      | 25 ++++++++---
 2 files changed, 63 insertions(+), 6 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/media/m2m-deinterlace.yaml

-- 
2.25.1

[PATCH v2 1/2] media: dt-bindings: Add dt bindings for m2m-deinterlace device

[Matthew Majewski]

Create a new yaml schema file to describe the device tree bindings for
generic m2m-deinterlace device.

This device is supported on any hardware that provides a MEM_TO_MEM
capable dma channel with interleaved trasfer support. Device tree
bindings are for providing appropriate dma channel to device.

Signed-off-by: Matthew Majewski <mattwmajewski@gmail.com>
---
 .../bindings/media/m2m-deinterlace.yaml       | 44 +++++++++++++++++++
 1 file changed, 44 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/m2m-deinterlace.yaml

diff --git a/Documentation/devicetree/bindings/media/m2m-deinterlace.yaml b/Documentation/devicetree/bindings/media/m2m-deinterlace.yaml
new file mode 100644
index 000000000000..e39599d7d07b
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/m2m-deinterlace.yaml
@@ -0,0 +1,44 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/m2m-deinterlace.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: M2M Deinterlacer
+
+maintainers:
+  - Mauro Carvalho Chehab <mchehab@kernel.org>
+
+description: |-
+  A generic memory2memory device for deinterlacing video using dmaengine. It can
+  convert between interlaced buffer formats and can convert interlaced to
+  progressive using a simple line-doubling algorithm. This device can be used on
+  any hardware that provides a MEM_TO_MEM capable dma controller that supports
+  interleaved transfers.
+
+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>;
+    };
-- 
2.25.1

Re: [PATCH v2 1/2] media: dt-bindings: Add dt bindings for m2m-deinterlace device

[Krzysztof Kozlowski]

On Fri, Feb 14, 2025 at 06:17:58PM -0500, Matthew Majewski wrote:
> Create a new yaml schema file to describe the device tree bindings for
> generic m2m-deinterlace device.
> 
> This device is supported on any hardware that provides a MEM_TO_MEM

Which device? I don't see here any device name/model.

I asked to provide here some examples of devices.

> capable dma channel with interleaved trasfer support. Device tree
> bindings are for providing appropriate dma channel to device.

Don't describe what DT is, but the hardware.

> 
> Signed-off-by: Matthew Majewski <mattwmajewski@gmail.com>
> ---
>  .../bindings/media/m2m-deinterlace.yaml       | 44 +++++++++++++++++++
>  1 file changed, 44 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/m2m-deinterlace.yaml
> 
> diff --git a/Documentation/devicetree/bindings/media/m2m-deinterlace.yaml b/Documentation/devicetree/bindings/media/m2m-deinterlace.yaml
> new file mode 100644
> index 000000000000..e39599d7d07b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/m2m-deinterlace.yaml
> @@ -0,0 +1,44 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/media/m2m-deinterlace.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: M2M Deinterlacer
> +
> +maintainers:
> +  - Mauro Carvalho Chehab <mchehab@kernel.org>
> +
> +description: |-
> +  A generic memory2memory device for deinterlacing video using dmaengine. It can
> +  convert between interlaced buffer formats and can convert interlaced to
> +  progressive using a simple line-doubling algorithm. This device can be used on
> +  any hardware that provides a MEM_TO_MEM capable dma controller that supports
> +  interleaved transfers.

And how do you program that device to deinterlace? How do you signal end
of frame/data when writing to the memory?

It still looks all this is for driver :/

Best regards,
Krzysztof

Re: [PATCH v2 1/2] media: dt-bindings: Add dt bindings for m2m-deinterlace device

[Matthew Majewski]

Hi Krzysztof,

On Tue, 2025-02-18 at 09:30 +0100, Krzysztof Kozlowski wrote:
> On Fri, Feb 14, 2025 at 06:17:58PM -0500, Matthew Majewski wrote:
> > Create a new yaml schema file to describe the device tree bindings
> > for
> > generic m2m-deinterlace device.
> > 
> > This device is supported on any hardware that provides a MEM_TO_MEM
> 
> Which device? I don't see here any device name/model.

By "device" I am referring to the m2m-deinterlace device, which I
explained is a quasi-virtual device. If this is confusing wording I can
change. 

> I asked to provide here some examples of devices.

As I wrote, supported devices/hardware is anything that provides a
MEM_TO_MEM capable dma-controller with interleaved transfer support. I
did not list specific devices because the bindings are supposed to be
generic, as they are not describing actual silicon. But if you want me
to list some devices which provide a compatible dma-controller, here
are devices I found in the current mainline kernel:

- TI OMAP Soc Family
- TI Davinci Soc Family
- TI Keystone Processor Family
- IMX27 Processor and variants
- Several Microchip Processors (sama5, sam9x7, sam9x60)

As I mentioned in my original email, I have personally tested on a
BeagleBone Black with an AM335X OMAP processor. There are likely many
more devices with compatible dma-controllers that could be supported
with additional dmaengine driver support. 


> > capable dma channel with interleaved trasfer support. Device tree
> > bindings are for providing appropriate dma channel to device.
> 
> Don't describe what DT is, but the hardware.
> 

Ok, will remove reference to DT.

> > +description: |-
> > +  A generic memory2memory device for deinterlacing video using
> > dmaengine. It can
> > +  convert between interlaced buffer formats and can convert
> > interlaced to
> > +  progressive using a simple line-doubling algorithm. This device
> > can be used on
> > +  any hardware that provides a MEM_TO_MEM capable dma controller
> > that supports
> > +  interleaved transfers.
> 
> And how do you program that device to deinterlace? How do you signal
> end
> of frame/data when writing to the memory?
> 
> It still looks all this is for driver :/
> 

All of the deinterlacing is handled by the dma channel. To simplify a
bit, m2m-deinterlace basically just translates video format information
into appropriate interleaved dma transfers. Everything else (and
everything hardware specific) is handled by the dma engine, such as
initiation and signaling completion of transfers. 

I think an appropriate analogy for m2m-deinterlace would be spi-gpio.
Since spi-gpio leverages gpio for bitbanging the spi protocol, the
bindings do not need to describe any clocks, spi-controller registers,
etc. All of the hardware specific components are abstracted away by the
gpio controller. But the spi-gpio bindings still exist to specify which
gpios are used.

Best,
Matthew

Re: [PATCH v2 1/2] media: dt-bindings: Add dt bindings for m2m-deinterlace device

[Krzysztof Kozlowski]

On 26/02/2025 23:41, Matthew Majewski wrote:
> Hi Krzysztof,
> 
> On Tue, 2025-02-18 at 09:30 +0100, Krzysztof Kozlowski wrote:
>> On Fri, Feb 14, 2025 at 06:17:58PM -0500, Matthew Majewski wrote:
>>> Create a new yaml schema file to describe the device tree bindings
>>> for
>>> generic m2m-deinterlace device.
>>>
>>> This device is supported on any hardware that provides a MEM_TO_MEM
>>
>> Which device? I don't see here any device name/model.
> 
> By "device" I am referring to the m2m-deinterlace device, which I
> explained is a quasi-virtual device. If this is confusing wording I can
> change. 
> 
>> I asked to provide here some examples of devices.
> 
> As I wrote, supported devices/hardware is anything that provides a
> MEM_TO_MEM capable dma-controller with interleaved transfer support. I
> did not list specific devices because the bindings are supposed to be
> generic, as they are not describing actual silicon. But if you want me

I already told you that no. Bindings are not supposed to be generic.

From where did you get such information?

> to list some devices which provide a compatible dma-controller, here
> are devices I found in the current mainline kernel:
> 
> - TI OMAP Soc Family
> - TI Davinci Soc Family
> - TI Keystone Processor Family
> - IMX27 Processor and variants
> - Several Microchip Processors (sama5, sam9x7, sam9x60)

That's too generic - you just listed SoCs, which consist of dozen or
hundred of devices. Which hardware piece is here?

Maybe this is not for a real device, but then this should be marked clearly.

> 
> As I mentioned in my original email, I have personally tested on a
> BeagleBone Black with an AM335X OMAP processor. There are likely many
> more devices with compatible dma-controllers that could be supported
> with additional dmaengine driver support. 
> 
> 
>>> capable dma channel with interleaved trasfer support. Device tree
>>> bindings are for providing appropriate dma channel to device.
>>
>> Don't describe what DT is, but the hardware.
>>
> 
> Ok, will remove reference to DT.
> 
>>> +description: |-
>>> +  A generic memory2memory device for deinterlacing video using
>>> dmaengine. It can
>>> +  convert between interlaced buffer formats and can convert
>>> interlaced to
>>> +  progressive using a simple line-doubling algorithm. This device
>>> can be used on
>>> +  any hardware that provides a MEM_TO_MEM capable dma controller
>>> that supports
>>> +  interleaved transfers.
>>
>> And how do you program that device to deinterlace? How do you signal
>> end
>> of frame/data when writing to the memory?
>>
>> It still looks all this is for driver :/
>>
> 
> All of the deinterlacing is handled by the dma channel. To simplify a
> bit, m2m-deinterlace basically just translates video format information
> into appropriate interleaved dma transfers. Everything else (and
> everything hardware specific) is handled by the dma engine, such as
> initiation and signaling completion of transfers. 


So the device is the dma controller and maybe all this should be folded
into that controller bindings.

> 
> I think an appropriate analogy for m2m-deinterlace would be spi-gpio.
> Since spi-gpio leverages gpio for bitbanging the spi protocol, the
> bindings do not need to describe any clocks, spi-controller registers,

Sure, SPI GPIO is Linux driver, not a device and I am asking about it
all the time.

> etc. All of the hardware specific components are abstracted away by the
> gpio controller. But the spi-gpio bindings still exist to specify which
> gpios are used.



Best regards,
Krzysztof

Re: [PATCH v2 1/2] media: dt-bindings: Add dt bindings for m2m-deinterlace device

[Krzysztof Kozlowski]

On 03/03/2025 08:31, Krzysztof Kozlowski wrote:
> On 26/02/2025 23:41, Matthew Majewski wrote:
>> Hi Krzysztof,
>>
>> On Tue, 2025-02-18 at 09:30 +0100, Krzysztof Kozlowski wrote:
>>> On Fri, Feb 14, 2025 at 06:17:58PM -0500, Matthew Majewski wrote:
>>>> Create a new yaml schema file to describe the device tree bindings
>>>> for
>>>> generic m2m-deinterlace device.
>>>>
>>>> This device is supported on any hardware that provides a MEM_TO_MEM
>>>
>>> Which device? I don't see here any device name/model.
>>
>> By "device" I am referring to the m2m-deinterlace device, which I
>> explained is a quasi-virtual device. If this is confusing wording I can
>> change. 
>>
>>> I asked to provide here some examples of devices.
>>
>> As I wrote, supported devices/hardware is anything that provides a
>> MEM_TO_MEM capable dma-controller with interleaved transfer support. I
>> did not list specific devices because the bindings are supposed to be
>> generic, as they are not describing actual silicon. But if you want me
> 
> I already told you that no. Bindings are not supposed to be generic.
> 
> From where did you get such information?
> 
>> to list some devices which provide a compatible dma-controller, here
>> are devices I found in the current mainline kernel:
>>
>> - TI OMAP Soc Family
>> - TI Davinci Soc Family
>> - TI Keystone Processor Family
>> - IMX27 Processor and variants
>> - Several Microchip Processors (sama5, sam9x7, sam9x60)
> 
> That's too generic - you just listed SoCs, which consist of dozen or
> hundred of devices. Which hardware piece is here?
> 
> Maybe this is not for a real device, but then this should be marked clearly.
> 
>>
>> As I mentioned in my original email, I have personally tested on a
>> BeagleBone Black with an AM335X OMAP processor. There are likely many
>> more devices with compatible dma-controllers that could be supported
>> with additional dmaengine driver support. 
>>
>>
>>>> capable dma channel with interleaved trasfer support. Device tree
>>>> bindings are for providing appropriate dma channel to device.
>>>
>>> Don't describe what DT is, but the hardware.
>>>
>>
>> Ok, will remove reference to DT.
>>
>>>> +description: |-
>>>> +  A generic memory2memory device for deinterlacing video using
>>>> dmaengine. It can
>>>> +  convert between interlaced buffer formats and can convert
>>>> interlaced to
>>>> +  progressive using a simple line-doubling algorithm. This device
>>>> can be used on
>>>> +  any hardware that provides a MEM_TO_MEM capable dma controller
>>>> that supports
>>>> +  interleaved transfers.
>>>
>>> And how do you program that device to deinterlace? How do you signal
>>> end
>>> of frame/data when writing to the memory?
>>>
>>> It still looks all this is for driver :/
>>>
>>
>> All of the deinterlacing is handled by the dma channel. To simplify a
>> bit, m2m-deinterlace basically just translates video format information
>> into appropriate interleaved dma transfers. Everything else (and
>> everything hardware specific) is handled by the dma engine, such as
>> initiation and signaling completion of transfers. 
> 
> 
> So the device is the dma controller and maybe all this should be folded
> into that controller bindings.

Answering myself: obviously no, because interleaved DMA is not relevant
to this device, so again: there is no device in SoC doing that. You just
add bindings for specific Linux driver without saying that this is that
driver and calling it "generic device". There is no device here.


Best regards,
Krzysztof

Re: [PATCH v2 1/2] media: dt-bindings: Add dt bindings for m2m-deinterlace device

[Matthew Majewski]

On Mon, 2025-03-03 at 08:31 +0100, Krzysztof Kozlowski wrote:
> On 26/02/2025 23:41, Matthew Majewski wrote:
> > 
> > As I wrote, supported devices/hardware is anything that provides a
> > MEM_TO_MEM capable dma-controller with interleaved transfer
> > support. I
> > did not list specific devices because the bindings are supposed to
> > be
> > generic, as they are not describing actual silicon. But if you want
> > me
> 
> I already told you that no. Bindings are not supposed to be generic.
> 
> From where did you get such information?

There are generic bindings in the kernel and I based my bindings off of
them. spi-gpio.yaml, i2c-gpio.yaml, video-mux.yaml, etc are all generic
bindings, no?

> 
> > to list some devices which provide a compatible dma-controller,
> > here
> > are devices I found in the current mainline kernel:
> > 
> > - TI OMAP Soc Family
> > - TI Davinci Soc Family
> > - TI Keystone Processor Family
> > - IMX27 Processor and variants
> > - Several Microchip Processors (sama5, sam9x7, sam9x60)
> 
> That's too generic - you just listed SoCs, which consist of dozen or
> hundred of devices. Which hardware piece is here?
> 
> Maybe this is not for a real device, but then this should be marked
> clearly.
> 

I listed devices that have a compatible dma-controller, so the list is
a bit big, sorry. I also specifically mentioned the BeagleBone black
board which I have been testing on. 

"m2m-deinterlace" used to be a part of the mach-imx27_visstrim_m10.c
board file, but was removed with commit 879c0e5e0ac711 (ARM: imx:
Remove i.MX27 board files). So at least the Vistrim M10 device was
explicitly using the m2m-deinterlace device. 

When the move away from board files was made towards device-tree, m2m-
deinterlace support was never ported over to device-tree. This is what
I am doing now. 

And yes, m2m-deinterlace is not a "real device" if by "real device" you
mean an actual piece of silicon on a specific piece of hardware. I
think there is just some semantic confusion here. I will no longer
refer to it as a "device" then, please let me know what the more
appropriate term is and I will modify the description accordingly.

> > 
> > I think an appropriate analogy for m2m-deinterlace would be spi-
> > gpio.
> > Since spi-gpio leverages gpio for bitbanging the spi protocol, the
> > bindings do not need to describe any clocks, spi-controller
> > registers,
> 
> Sure, SPI GPIO is Linux driver, not a device and I am asking about it
> all the time.
> 

My point was that spi-gpio has dt-bindings even though these bindings
do not describe a specific hardware device, hence it is "generic". 

Best,
Matthew

Re: [PATCH v2 1/2] media: dt-bindings: Add dt bindings for m2m-deinterlace device

[Krzysztof Kozlowski]

On 03/03/2025 16:21, Matthew Majewski wrote:
> On Mon, 2025-03-03 at 08:31 +0100, Krzysztof Kozlowski wrote:
>> On 26/02/2025 23:41, Matthew Majewski wrote:
>>>
>>> As I wrote, supported devices/hardware is anything that provides a
>>> MEM_TO_MEM capable dma-controller with interleaved transfer
>>> support. I
>>> did not list specific devices because the bindings are supposed to
>>> be
>>> generic, as they are not describing actual silicon. But if you want
>>> me
>>
>> I already told you that no. Bindings are not supposed to be generic.
>>
>> From where did you get such information?
> 
> There are generic bindings in the kernel and I based my bindings off of
> them. spi-gpio.yaml, i2c-gpio.yaml, video-mux.yaml, etc are all generic
> bindings, no?

They are generic, but you said "supposed to be generic" and I am asking
about this.

BTW, any "generic" or "simple" bindings often became non-generic and
non-simple leading to mess.

> 
>>
>>> to list some devices which provide a compatible dma-controller,
>>> here
>>> are devices I found in the current mainline kernel:
>>>
>>> - TI OMAP Soc Family
>>> - TI Davinci Soc Family
>>> - TI Keystone Processor Family
>>> - IMX27 Processor and variants
>>> - Several Microchip Processors (sama5, sam9x7, sam9x60)
>>
>> That's too generic - you just listed SoCs, which consist of dozen or
>> hundred of devices. Which hardware piece is here?
>>
>> Maybe this is not for a real device, but then this should be marked
>> clearly.
>>
> 
> I listed devices that have a compatible dma-controller, so the list is
> a bit big, sorry. I also specifically mentioned the BeagleBone black
> board which I have been testing on. 
> 
> "m2m-deinterlace" used to be a part of the mach-imx27_visstrim_m10.c
> board file, but was removed with commit 879c0e5e0ac711 (ARM: imx:
> Remove i.MX27 board files). So at least the Vistrim M10 device was
> explicitly using the m2m-deinterlace device. 
> 
> When the move away from board files was made towards device-tree, m2m-
> deinterlace support was never ported over to device-tree. This is what
> I am doing now. 
> 
> And yes, m2m-deinterlace is not a "real device" if by "real device" you
> mean an actual piece of silicon on a specific piece of hardware. I
> think there is just some semantic confusion here. I will no longer
> refer to it as a "device" then, please let me know what the more
> appropriate term is and I will modify the description accordingly.
> 
>>>
>>> I think an appropriate analogy for m2m-deinterlace would be spi-
>>> gpio.
>>> Since spi-gpio leverages gpio for bitbanging the spi protocol, the
>>> bindings do not need to describe any clocks, spi-controller
>>> registers,
>>
>> Sure, SPI GPIO is Linux driver, not a device and I am asking about it
>> all the time.
>>
> 
> My point was that spi-gpio has dt-bindings even though these bindings
> do not describe a specific hardware device, hence it is "generic". 


SPI GPIO is physical GPIO lines bit-banged in software. I don't think it
is possible to achieve such SPI controller as part of some other Linux
structure.
Now your case - describe what you have here - SW for interlacing? But
that is just memory operation. I really do not see why this is supposed
to be separate device node in DTS. This is part of media pipeline, so
easily can be part of some other device.


Best regards,
Krzysztof

[PATCH v2 2/2] media: m2m-deinterlace: add device-tree support

[Matthew Majewski]

Add support for loading the m2m-deinterlace driver through the
device-tree.

Prefer to query the dma device through dma_request_chan(), which will
get the dma device information from the device-tree node if
present. Otherwise, fall back to the original dma_request_channel() to
preserve backwards compatibility.

Signed-off-by: Matthew Majewski <mattwmajewski@gmail.com>
---
 drivers/media/platform/m2m-deinterlace.c | 25 ++++++++++++++++++------
 1 file changed, 19 insertions(+), 6 deletions(-)

diff --git a/drivers/media/platform/m2m-deinterlace.c b/drivers/media/platform/m2m-deinterlace.c
index 5188f3189096..ba4e4ee6ad34 100644
--- a/drivers/media/platform/m2m-deinterlace.c
+++ b/drivers/media/platform/m2m-deinterlace.c
@@ -11,6 +11,7 @@
 #include <linux/interrupt.h>
 #include <linux/dmaengine.h>
 #include <linux/platform_device.h>
+#include <linux/module.h>
 
 #include <media/v4l2-mem2mem.h>
 #include <media/v4l2-device.h>
@@ -914,7 +915,6 @@ static int deinterlace_probe(struct platform_device *pdev)
 {
 	struct deinterlace_dev *pcdev;
 	struct video_device *vfd;
-	dma_cap_mask_t mask;
 	int ret = 0;
 
 	pcdev = devm_kzalloc(&pdev->dev, sizeof(*pcdev), GFP_KERNEL);
@@ -923,9 +923,16 @@ static int deinterlace_probe(struct platform_device *pdev)
 
 	spin_lock_init(&pcdev->irqlock);
 
-	dma_cap_zero(mask);
-	dma_cap_set(DMA_INTERLEAVE, mask);
-	pcdev->dma_chan = dma_request_channel(mask, NULL, pcdev);
+	if (pdev->dev.of_node) {
+		pcdev->dma_chan = dma_request_chan(&pdev->dev, "rxtx");
+	} else {
+		dma_cap_mask_t mask;
+
+		dma_cap_zero(mask);
+		dma_cap_set(DMA_INTERLEAVE, mask);
+		pcdev->dma_chan = dma_request_channel(mask, NULL, pcdev);
+	}
+
 	if (!pcdev->dma_chan)
 		return -ENODEV;
 
@@ -989,12 +996,18 @@ static void deinterlace_remove(struct platform_device *pdev)
 	dma_release_channel(pcdev->dma_chan);
 }
 
+static const struct of_device_id deinterlace_dt_match[] = {
+	{ .compatible = "m2m-deinterlace" },
+	{ /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, deinterlace_dt_match);
+
 static struct platform_driver deinterlace_pdrv = {
 	.probe		= deinterlace_probe,
 	.remove		= deinterlace_remove,
 	.driver		= {
-		.name	= MEM2MEM_NAME,
+		.name		= MEM2MEM_NAME,
+		.of_match_table = deinterlace_dt_match,
 	},
 };
 module_platform_driver(deinterlace_pdrv);
-
-- 
2.25.1