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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 03/03/2025 08:31, Krzysztof Kozlowski wrote:
> 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.

Answering myself: obviously no, because interleaved DMA is not relevant
to this device, so again: there is no device in SoC doing that. You just
add bindings for specific Linux driver without saying that this is that
driver and calling it "generic device". There is no device here.


Best regards,
Krzysztof




[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux