< pinchartl> welcome to the multimedia meeting < pinchartl> Topic 1. Status Check for the Multimedia Tasks < pinchartl> * Jacopo Since last meeting: - GMSL reliability (v5) - MAX9286 integration on Eagle (v3) Until next meeting: - Complete RDACM20 stress tests after having validated RDACM21 - max9271 to be turned into an I2C driver Issues and blockers: None jmondi: any comment ? not really [16:48] thank you * Kieran Since last meeting: - GMSL review and support - GP LED support integrated for V3U - V3U FCPVD and VSPD support posted. - Rebased and pushing the DU group rework Until next meeting: maybe geertu can explain me what he meant with 'gpio-hog' style - Further development on VSPD/DU for V3U but later Issues and blockers: None [16:49] kbingham: any comment ? No thank you * Laurent Since last meeting: - V4L2 multiplexed streams development - Periject triage for display (complete) - Upported and submitted DU driver fixes - SN65DSI86 upporting Upporting complete, with RFC patch series sent. The code can't be tested yet, as VSP, DU and DSI are needed. Upstreaming is thus on hold. - DSI driver upporting Work in progress. Until next meeting: - V4L2 multiplexed streams development Patches should be posted within the next month. - DSI driver upporting - DU driver upporting This will enable testing of the whole display chain, once VSP is ready. - Display drivers upstreaming Tentative, if testing (and bug fixing) can be completed on time. Issues and blockers: None any question ? * Morimoto-san [16:50] Since last meeting: - ALSA Framework cleanup is finally done ! - Started to post new generic sound card driver - Creating sound autotest environment by using Ulrich's atest It's not the best match to the test environment, asked Ulrich to add new features. Until next meeting: - Continue to posting patch ot ALSA - Update Sound autotest environment by using Ulrich's atest Issues and Blockers: - Ulrich's atest sometimes fails, the reason is unknown morimoto: any comment ? I want to talk to Ulrich about atest about others, no comment. thanks yes? On Email, OK ? [16:51] sure Thanks a lot thank you * Niklas Since last meeting: - [PATCH] rcar-csi2: Add support for Y10 and Y8 - [PATCH] media: dt-bindings: media: renesas,csi2: Node port@0 is not mandatory - [PATCH] arm64: dts: renesas: aistarvision-mipi-adapter-2.1: Explicitly state csi40 port - [PATCH] media: staging: max96712: Add basic support for MAX96712 GMSL2 deserializer - [PATCH] media: dt-bindings: media: renesas,csi2: Add r8a779a0 support - [PATCH] rcar-csi2: Add r8a779a0 support [16:52] - [PATCH] media: dt-bindings: media: renesas,isp: Add bindings for ISP Channel Selector - [PATCH] media: rcar-isp: Add Renesas R-Car Image Signal Processor driver - [PATCH] media: dt-bindings: media: renesas,vin: Add r8a779a0 support - [PATCH 00/11] rcar-vin: Add r8a779a0 support - [PATCH] arm64: dts: renesas: falcon-csi-dsi: Add GPIO extenders - [PATCH 0/2] arm64: dts: renesas: falcon: Wire up MAX96712 - Video capture on V3U work in Japan lab This uses the MAX96712 and R-Car ISP drivers. media graph: https://www.ragnatech.se/~neg/v3u/mc-graph.png patterns captured: https://www.ragnatech.se/~neg/v3u/checkerboard.png https://www.ragnatech.se/~neg/v3u/gradient.png Until next meeting: - Follow up pending patches - Finish a set of cleanup patches found while working on V3U Issues and blockers: - Need GMSL2 cameras (ideally locally, worst case remotely) neg: any comment ? I have a few questions. the test patterns are generated by the MAX96712, right ? yes the patterns are generated by the MAX96712, no I don't have any comments ;-) [16:53] :-) neg, I have GMSL1 (RDACM21) cameras attached to the v3u here. But RDACM21 != GMSL2. I suppose that's running the BSP code ? nope I wrote a new driver ah, nice with the ISP in bypass mode ? [16:54] No the ISP is used for channel selection I mean the ISP core Ahh yes [16:55] now that you've had a chance to play with this, does the datasheet provide all the information we need, or at there missing parts, or parts that are unclear ? [16:56] For MAX96712 i think we have all we need if we want to take it further. For the ISP I think my knowledge about real world ISP is the limiting factor to awnser that [16:57] we know we don't have information about the ISP core My current plan is to extend the ISP channel selection to allow routing VC/DT freely, but I will not do that before we have a multiplexed stream poc ok [16:58] and for that I think we have enough information, anything more advanced that that I have not really checked or thought about but you haven't noticed clearly missing information when it comes to configuration of the routing (still with the ISP core bypassed) ? So far I only have one bit of information missing [16:59] what is it ? Each ISP is connected to two CSI-2 recivers, which the first one is is clear, but for each ISP which the second one is missing in the datasheet [17:00] or at least I have not found it I managed to figure out what was needed for V3U by trail and error, but it should ideally be confirmed in a datasheet at some point [17:01] ok thanks for the information and nice work ! thanks IMHO all of the current work is ready to be consumed [17:02] * Ulrich Since last meeting: - Fixed another bug in atest, applied Morimoto-san's patches Until next meeting: - Fix more issues in atest Issues and blockers: None uli__: any comment ? nope [17:03] the MAX96712 is placed in staging in an attempt to avoid the huge amount of fun we had with the out-of-tree GMSL1 series ;-) thank you Topic 2. Discussions any discussion topic for today ? [17:04] kbingham: GMSL1 cams can also be useful, but it's more or less split brain inside the MAX96712 between GMSL1 and GMSL2 as far as I can tell neg, Does the MAX96712 need separate configuration to support both? [17:05] kbingham: Also for totally understandable reasons the fire board is not reachable during my office hours ;-) neg You could stay up 'late' one night hehehe but indeed. neg, Let me know if you want me to test things though. [17:06] kbingham: Not sure all I know is from looking at the block diagrams and parts I read in the docs by mistake. GMSL2 looks much more fun then GMSL1 kbingham: Absolutely, thanks! neg, but the driver will be able to support both right? yes [17:07] or is it 'a separate' driver ... a la gen2/gen3 vin :-) from what I think now there will be two code paths in the driver, one for GMSL1 and one for GMSL2. And I'm not sure if one can mix and match between the two but it would not surprise me, but maybe we don't need to start out by considering that ;-0 [17:08] :-) kbingham: you rather have the board on fire when you sleep?? wsa, No ;-) Neg staying up late pushes him into my office hours ;-) [17:09] wsa: I can't really function before 23pm :-) oh, that are your office hours then... [17:10] That's it from me, sorry to drag on no worries if there's no other discussion topic, I propose adjourning the meeting. does anyone second ? o/ +1 [17:11] meeting adjourned. thank you for attending everybody have a nice day have a nice day EuroPeri [17:12] see you ERC>