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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <29a8e7ec-dabc-4cc1-a262-676ebd838dfd@kernel.org>
Date: Tue, 18 Feb 2025 09:34:34 +0100
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Matthew Majewski <mattwmajewski@...il.com>,
 Mauro Carvalho Chehab <mchehab@...nel.org>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, Hans Verkuil <hverkuil@...all.nl>,
 "Dr. David Alan Gilbert" <linux@...blig.org>,
 Neil Armstrong <neil.armstrong@...aro.org>,
 Uwe Kleine-Konig <u.kleine-koenig@...libre.com>,
 Andrzej Pietrasiewicz <andrzejtp2010@...il.com>
Cc: devicetree@...r.kernel.org, linux-media@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] media: dt-bindings: Add dt bindings for
 m2m-deinterlace device

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