| Message ID | 20250212170901.3881838-2-mattwmajewski@gmail.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | media: m2m-deinterlace: add device-tree support | expand |
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. Please describe here exemplary devices. > > Signed-off-by: Matthew Majewski <mattwmajewski@gmail.com> > --- > .../bindings/media/m2m-deinterlace.yaml | 41 +++++++++++++++++++ > 1 file changed, 41 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..3ac9c1e7be88 > --- /dev/null > +++ b/Documentation/devicetree/bindings/media/m2m-deinterlace.yaml > @@ -0,0 +1,41 @@ > +# 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. And what is this generic device supposed to do? What fits to generic device? > + > +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. > + }; Best regards, Krzysztof
On Wed, 12 Feb 2025 12:09:00 -0500, Matthew Majewski wrote: > Create a new yaml schema file to describe the device tree bindings for > the generic m2m-deinterlace driver. > > Signed-off-by: Matthew Majewski <mattwmajewski@gmail.com> > --- > .../bindings/media/m2m-deinterlace.yaml | 41 +++++++++++++++++++ > 1 file changed, 41 insertions(+) > create mode 100644 Documentation/devicetree/bindings/media/m2m-deinterlace.yaml > My bot found errors running 'make dt_binding_check' on your patch: yamllint warnings/errors: ./Documentation/devicetree/bindings/media/m2m-deinterlace.yaml:10:2: [warning] wrong indentation: expected 2 but found 1 (indentation) dtschema/dtc warnings/errors: doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20250212170901.3881838-2-mattwmajewski@gmail.com The base for the series is generally the latest rc1. A different dependency should be noted in *this* patch. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit after running the above command yourself. Note that DT_SCHEMA_FILES can be set to your schema file to speed up checking your schema. However, it must be unset to test all examples with your schema.
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
Hi Rob, thanks for the feedback. On Wed, 2025-02-12 at 13:26 -0600, Rob Herring (Arm) wrote: > > If you already ran 'make dt_binding_check' and didn't see the above > error(s), then make sure 'yamllint' is installed and dt-schema is up > to > date: > Yup, I missed a yaml syntax error and didn't notice because I was missing yamllint and dt_binding_check came back ok. Will fix for V2... thanks again. Best, Matthew
On 12/02/2025 23:29, Matthew Majewski wrote: > 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. I asked to give names of actual hardware you are writing bindings for. > >>> >>> +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 Really only this? How do you reset the device? How do you clock it (or does it come with internal oscillator?) How do you program anything there if there are no resources? > 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 I asked about the names already, still nothing. > 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. Then wait before sending new version. 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..3ac9c1e7be88 --- /dev/null +++ b/Documentation/devicetree/bindings/media/m2m-deinterlace.yaml @@ -0,0 +1,41 @@ +# 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. + +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 the generic m2m-deinterlace driver. Signed-off-by: Matthew Majewski <mattwmajewski@gmail.com> --- .../bindings/media/m2m-deinterlace.yaml | 41 +++++++++++++++++++ 1 file changed, 41 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/m2m-deinterlace.yaml