First off, thank you so much for your help Michael, we almost have a working solution !
> I guess that depends on your "current state"
I'm talking about the latest stable Xilinx kernels, (v2023.1 / v2023.2 at the moment), I never use unstable tags.
> You are mixing the bindings of the downstream and the upstream driver. You have to stick to one binding to use one driver or the other.
That was just our latest attempt. It is not very clear what we are supposed to declare (see following question).
>From what you said, I adapted the devicetree to the following, allegrodvt is now probed, it fails to locate IRQ#0, but I am just starting to debug, I'm confident we will find the solution to this :
// vcu settings
1369 vcu_settings: vcu@a0241000 {
1370 compatible = "xlnx,vcu-settings", "syscon";
1371 reg = <0x0 0xa0241000 0x0 0x1000>;
1372 reg-names = "logicore";
1373 };
// new section
1374 vcu_al5e: video-codec@a0009000 {
1375 compatible = "allegro,al5e-1.1", "allegro,al5e";
1376 reg = <0 0xa0009000 0 0x1000>, <0 0xa0000000 0 0x8000>;
1377 reg-names = "regs", "sram";
1378 interrupts = <0 104 4>; // try to establish IRQ relationship, but not sure yet IRQ#0 is actually this one or another.
1379 clocks = <&vcu 0>, <&vcu 1>, <&zynqmp_clk 71>, <&zynqmp_clk 71>, <&zynqmp_clk 71>;
1380 clock-names = "core_clk", "mcu_clk", "m_axi_core_aclk", "m_axi_mcu_aclk", "s_axi_lite_aclk";
1381 };
// still partially needed
1382 vcu: vcu@a0200000 {
1383 #address-cells = <2>;
1384 #clock-cells = <1>;
1385 #size-cells = <2>;
1386 clock-names = "pll_ref", "aclk", "vcu_core_enc", "vcu_core_dec", "vcu_mcu_enc", "vcu_mcu_dec";
1387 clocks = <&misc_clk_1>, <&zynqmp_clk 71>, <&vcu 1>, <&vcu 2>, <&vcu 3>, <&vcu 4>;
1388 compatible = "xlnx,vcu-1.2", "xlnx,vcu";
1389 interrupt-names = "vcu_host_interrupt";
1390 interrupt-parent = <&gic>;
1391 interrupts = <0 104 4>;
1392 ranges ;
1393 reg-names = "vcu_slcr";
1394 reg = <0x0 0xa0240000 0x0 0x1000>;
1395 reset-gpios = <&vfrmbuf_gpio 6 GPIO_ACTIVE_LOW>;
1396 };
> What kind of documentation did you expect and where did you expect it?
I think the current kernel lacks some notes - no idea what their appropriate location might be, that explain the relationship between all those drivers, especially the syscon setup.
For the simple reason that you need all of these drivers to work at the same time, and one of them by itself will never be enough.
> I'm not using the out-of-tree module anymore.
OK thanks once again, we should be able to get a working solution then
> The upstream driver is product-driven, and only has the features that are needed for the product
Could you elaborate or point out to a location where we can have detailed documentation of the current capabilities ?
so we can make a decision whether we should upgrade to mainline, or remain on the out-of-tree module ?
Thank you very much,
Guillaume W. Bres,
Digital systems - Bertin Technologies
<buillaume.bres@bertin.group>
-----Message d'origine-----
De : Michael Tretter <m.tretter@xxxxxxxxxxxxxx>
Envoyé : mardi 9 avril 2024 10:08
À : BRES, Guillaume <guillaume.bres@bertin.group>
Cc : Michal Simek <michal.simek@xxxxxxx>; Michal Simek <michal.simek@xxxxxxxxxx>; ORIOT DE LA CHAPELLE, DAVID <david.oriot@bertin.group>; DUMAS, Victor <victor.dumas@bertin.group>; kernel@xxxxxxxxxxxxxx
Objet : Re: Allegro/VCU on Zynq-MP 2023+
[WARNING] This message comes from an external organization. Be careful of embedded links and attached files.
Hi Guillaume,
On Tue, 09 Apr 2024 06:46:18 +0000, BRES, Guillaume wrote:
> Hello, my name is Guillaume and I work for a french company named Bertin Technologies.
>
> We have used v2020 Kernels on Zynq-MP EV platforms successfully in the past.
> We're currently trying to upgrade to v2023.1+ kernels.
> My question is simple, is the VCU correctly supported in the current state ?
I guess that depends on your "current state".
> We have noticed you initiated work to integrate its support into
> mainline, but it is not obvious whether this work has converged or
> not.
I am using the upstream driver in a production system. For the motivation for writing this driver, see my talk at FOSDEM 2021 [0]. The talk also addresses potential issues of the upstream driver. For example, the upstream driver currently uses a pretty old VCU firmware.
> The previous out of tree module does not seem to work with newer kernels.
I'm not using the out-of-tree module anymore.
>
> Here is the configuration that used to work :
>
> [cid:image001.png@01DA8A5A.621D0650]
>
> Here is our latest attempt:
>
> [cid:image002.png@01DA8A5A.621D0650]
> We have guessed (1) by reading the code (it lacks documentation).
What kind of documentation did you expect and where did you expect it?
The device tree bindings are documented in the kernel (Documentation/devicetree/bindings), and the actual device tree depends on the configuration of your FPGA bitstream.
> We're wondering whether (2) should be similarly extracted from the VCU node.
You are mixing the bindings of the downstream and the upstream driver.
You have to stick to one binding to use one driver or the other.
> We're wondering whether we should transition from al,al5e (out of
> tree) to allegro,al5e-1.1 (mainline), is it ready or not ?
Depends on your use case. The upstream driver is product-driven, and only has the features that are needed for the product. If these features are sufficient for you, you may use the driver. If not, you may add the features to the upstream driver and send patches. If this is not an option, you may have to continue using the downstream driver.
If you need further support, please include the public mailing list
(linux-media@xxxxxxxxxxxxxxx) or contact sales@xxxxxxxxxxxxxx for professional support.
Michael
[0] https://video.fosdem.org/2021/D.embedded/mainline_zynqmp_vcu_driver.webm
--
Pengutronix e.K. | Michael Tretter |
Steuerwalder Str. 21 | https://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
