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] [day] [month] [year] [list]

Message-ID: <7856fdff-5dc5-44e2-afde-129233b930ab@kernel.org>
Date: Tue, 4 Mar 2025 08:26:54 +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 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