On 2/21/23 13:46, Martin Tůma wrote:
On 21. 02. 23 22:06, Geert Uytterhoeven wrote:
Hi Martin,
On Tue, Feb 21, 2023 at 9:45 PM Martin Tůma <tumic@xxxxxxxxxx> wrote:
On 21. 02. 23 14:25, Geert Uytterhoeven wrote:
No platform dependencies at all, while this is a platform driver that
relies on some other not-yet-existing driver creating an "xdma"
platform device?
There is at least one "already-existing" driver based on this driver
that is waiting in the v4l2 queue for xdma - our MGB4 driver:
https://patchwork.kernel.org/project/linux-media/patch/20230207150119.5542-2-tumic@xxxxxxxxxx/
Thanks for the link!
As VIDEO_MGB4 selects XILINX_XDMA, perhaps XILINX_XDMA
can be made invisible, unless compile-testing?
config XILINX_XDMA
tristate "Xilinx DMA/Bridge Subsystem DMA Engine" if
COMPILE_TEST
Gr{oetje,eeting}s,
Geert
Hi,
I think that the XDMA driver will always be used by a superior PCIe
card driver like in our case (mgb4) and using it separately makes no
sense/is not possible, so disabling it until some of the superior
drivers selects it makes sense for me. But what about out-of-the-tree
modules based on xdma? Making the module "invisible" will make compile
them much harder I guess? And there will be proprietary drivers based
on xdma, see Xilinx XRT:
https://github.com/houlz0507/XRT-1/tree/xdma_v4_usage
The xdma authors from Xilinx will definitely give you a more
authoritative answer. I'm just a "random" user of the xdma module.
Originally our mgb4 driver was based on our own xdma sub-driver (in
turn based on some old "test" driver from Xilinx) which I was glad we
could abandon when this xdma driver has appeared. I helped the xdma
module to become usable for PCIe cards like our v4l2 grabber, but the
original intents of the xdma driver are unknown to me. If it is XRT,
than Xilinx will probably like the module to stay visible.
M.
There are PCIe devices which use the XDMA IP and would use this xdma
driver. Out of tree drivers for Xilinx/AMD Alveo devices can switch to
this in kernel xdma driver.
Thanks,
Lizhi