| Message ID | 20250214231759.119481-2-mattwmajewski@gmail.com |
|---|---|
| State | New |
| Headers | show |
| Series | media: m2m-deinterlace: add device-tree support | expand |
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
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
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.
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
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
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
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>; + };
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