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: <a858367d-5953-1fba-0cb6-20ea917194e0@gpxsee.org>
Date:   Mon, 19 Dec 2022 12:10:49 +0100
From:   Martin Tůma <tumic@...see.org>
To:     Pavel Machek <pavel@....cz>
Cc:     Mauro Carvalho Chehab <mchehab@...nel.org>,
        linux-media@...r.kernel.org, linux-kernel@...r.kernel.org,
        Lizhi Hou <lizhi.hou@....com>,
        Martin Tůma <martin.tuma@...iteqautomotive.com>
Subject: Re: [PATCH v4 0/1] Digiteq Automotive MGB4 driver

On 18. 12. 22 19:58, Pavel Machek wrote:
> Hi!
> 
>> From: Martin Tůma <martin.tuma@...iteqautomotive.com>
>>
>> Hi,
>> This patch adds a driver for the Digiteq Automotive MGB4 grabber card.
>> MGB4 is a modular frame grabber PCIe card for automotive video interfaces
>> (FPD-Link and GMSL for now). It is based on a Xilinx FPGA and uses their
>> XDMA IP core for DMA transfers. Additionally, Xilinx I2C and SPI IP cores
>> which already have drivers in linux are used in the design.
>>
>> The driver is a quite standard v4l2 driver, with one exception - there are
>> a lot of sysfs options that may/must be set before opening the v4l2 device
>> to adapt the card on a specific signal (see mgb4.rst for details)
>> as the card must be able to work with various signal sources (or displays)
>> that can not be auto-detected.
> 
> Uff, that's "interesting". What kind of platform does this run on? You
> should be getting non-probeable parameters from deice tree (or APCI).
> 
> Best regards,
> 								Pavel
> 								

Hi,
It is a PCIe card, so it runs on any platform that supports PCIe cards. 
We do use the HW on x86_64 and arm platforms.

The parameters are in no way connected to the platform where the card is 
used, they are properties of the video signal that can change arbitrary 
as you can connect different car infotainments (the signal source) to 
the card (the same applies to the outputs - the car displays). Usually, 
there is no auto-configuration on the signal level, that's why you have 
to provide the various properties externally according to the 
infotainment that you have at the moment connected to the card.

Any kind of device tree or ACPI parameters make no sense for the HW/the 
intended usage.

M.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ