linux-kernel - Re: [PATCH v2 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <3d729159-4d13-4a61-88c7-3be992b23728@kernel.org>
Date: Mon, 3 Mar 2025 08:31:24 +0100
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Matthew Majewski <mattwmajewski@...il.com>
Cc: 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>, devicetree@...r.kernel.org,
 linux-media@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/2] media: dt-bindings: Add dt bindings for
 m2m-deinterlace device

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