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

[Krzysztof Kozlowski <krzk@kernel.org>]

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