< pinchartl> welcome to the multimedia meeting < pinchartl> Topic 1. Status Check for the Multimedia Tasks * Geert Since last meeting: - Investigated an ADV7511 s2ram crash, to discover a DRM EDID bug Until next meeting: None Issues and blockers: None geertu: any comment ? It seems the i2c bus is locked up and on subsequent reset, EDID cannot be read, too [17:06] Wolfram mentioned he would investigate on the I2C side I have another display bug reported by Morimoto-san to handle so I'll happily ignore the adv7511 for now :-) until Wolfram completes his investigations (or I fix the other bug) [17:07] Yeah, I saw that. Could that be fw_devlink? I doubt it [17:08] pinchartl: that will be an interesting race :) :-) [17:09] * Jacopo Since last meeting: - V4L2 multiplexed streams support for GMSL - review and discussion of v4l2-mux support from Tomi - R-Car CSI-2 + GMSL ported to v4l2-mux - R-Car ISP review Until next meeting: - New version of v4l2-mux with VIN channels properly handled Issues and blockers: None jmondi: any comment ? pinchartl: not really, apart from the point I mentioned in C) I've added it to the discussion points thanks thank you let's keep it for later [17:10] * Kieran Since last meeting: - Investigate V3U display timings Until next meeting: - Investigate V3U display timings Peripheral clock confirmed, but still need to dig in and verify things here. Issues and blockers: None Kieran is on vacation this week, I don't think he's with us today I've been working with him on the V3U display, so I can try to answer questions if there are any * Laurent [17:11] Since last meeting: - Upstreamed pending patches Most notably, sent pull requests for V3U support in DU, and for non-contiguous buffer import. - V4L2 multiplexed streams development Continued working with Tomi Valkeinen. Still work in progress (v9 is out). Reviewed Jacopo's MAX9286 multiplexed streams support. - Tested HDMI probe issue with v5.15-rc1 Couldn't reproduce on M3-N Salvator-XS, will test on ULCB next. Until next meeting: - Debug HDMI probe issue on v5.15-rc1 - V4L2 multiplexed streams development Issues and blockers: None any question ? thank you for checking HDMI issue [17:12] you're welcome. now I have to dust my ULCB :-) * Morimoto-san Since last meeting: - Posted ALSA SoC new generic sound card driver Maintainer said basically OK, got some feedback about from non-maintainer, posted v4. Until next meeting: - Continue ALSA SoC work Issues and Blockers: - v5.15-rc1 doesn't probe HDMI Issue reported to Laurent and to mailing list. moriperi: any comment ? nothing, thanks *** damm (~damm@167.99.4.198) has quit: Remote host closed the connection [17:13] *** damm (~damm@167.99.4.198) has joined channel #periperi * Niklas Since last meeting: - [PATCH] media: rcar-vin: Use user proved buffers when starting - [PATCH v3] media: staging: max96712: Add basic support for MAX96712 GMSL2 deserializer - [PATCH v5] media: rcar-isp: Add Renesas R-Car Image Signal Processor driver - [PATCH v2 0/2] rcar-csi2: Serialize format cfg and improve mutex handling - [PATCH v6] media: rcar-isp: Add Renesas R-Car Image Signal Processor driver Until next meeting: - Follow up pending patches Issues and blockers: None neg: any comment ? No comment thank you [17:14] that's it for the MM status update unless I've forgotten someone Topic 2. Discussions - R-Car VIN channel handling for v4l2-mux [17:15] jmondi: what is that about ? so, I've implemented support for multiplxing and CSI-2 VC routing on max9286 and R-Car CSI-2 the part I am missing, and from a brief discussion we had I am probably misunderstanding, is the VIN part [17:16] as we all know VIN has a CHSEL register with a fixed number of combinations it is currently populated inspecting the enabled links between CSI-2 and the VIN instances which are used to build a mask of enabled routes [17:17] afaiu this does not take into account which VC is routed to the CSI-2 source pad linked to the VIN instance at hand [17:18] I can make an example From a multiplexed stream PoV just ignore that the CHSEL register exists ;-) how so ? The documentation is missleading and it have nothing to do with VC, it just configure which parallel bus on the CSI-2 soruce side is routed to which VIN instance [17:19] from what I see empirically, it also have an impact on filtering I can make an example VC only exists on the CSI-2 sink pad and inside the CSI-2 driver where a VC is routed to a physical source pad (aka parallel bus) that faces the VIN [17:20] on V3M, have a look at the chsel table (page 2006 of datasheet 2.20) I am configuring the CSI-2 interface to route VC0 on source pad#1 and VC1 to source pad #4 [17:21] this in my understanding corresponds to the first row of the chsel table the way the chsel mask building procedure works leads to a chsel mask of value 0x3 [17:22] which expects VC3 to be on pad #4, not VC1 in my mind that could be solved by inspecting the CSI-2 frame desc, and configuring the mask accordingly [17:23] but I got from the two of you that chsel should not be involved with routing unfortunately, if I stick with the computed chsel=0x3 VIN3 output is blank [17:24] if I instead use a chsel value of 0x00 I get good images The CHSEL value calculation don't care about VC, it only looks at the media graph links [17:26] I understand, and that's the culprit of my issues, but I got from our previous discussions that the mask building procedure should not be changed [17:27] If you first disable all MC links and then enable CSI40.sourcepad0 -> VIN0 and CSI40.sourcepad4 -> VIN3 and don't get a CHSEL value of 0x00 there is a bug in VIN and that of course shall be fixed But this bug would then exists today and would not depend on any multiplexed stream work [17:28] I don't think it's a bug, I think the current procedure assumes CSI40.sourcepad4 = VC3 *** wsa (~wsa@p54b33006.dip0.t-ipconnect.de) has quit: Quit: cya! [17:29] d00h, yes I got confused that in your multiplexed work you break that assumtion ;-) [17:32] and also, inspecting the enabled links is not enough, as in example to dishern if (in the same example I've given) on CSI40.pad#4 you have VC1 or embedded data. you should inspect the frame desc But this is good news then, I had been mening to try if what you descirbe here works (even if I don't get why VC and datatype are mixed there) I mean, we might assume the [VC, CSI source pad] association is fixed [17:33] Because if it do we could simplify the VIN routing I think, as we could allow any VIN to be routed to any VC but it would limit the HW supported features yeah, well, considering the limited number of possible routes each SoC supports :) [17:34] I'm thinking a hardcoded CHSEL value and immutable links between CSI-2 and VIN. The routing of VC to VIN is controlled by the multiplexed API inside the CSI-2 [17:35] can that be done ? [17:36] are the other options than CHSEL to control routing ? didn't get the question :) s/are the/are there/ [17:37] If I understood Jacopo this is what he does in his multiplexed stream series and this is why he see this issue my understanding is that CHSEL does not control routing but rather filtering [17:38] As he "routes VC1 to source pad #4" he breaks the assumtion we had that each VC was mapped to a fixed pad VCn -> source pad n and that surprises me as it means the VIN has the notion of VC/DT while I always assumed there's just a parallel data bus between VIN and CSI-2 [17:39] how do you control routing within the CSI-2 receiver ? through which registers you mean ? yes VCDT and VCDT2 SEL_VC - These bits specify the virtual channels for channel 0 to capture. SEL_VC2 - These bits specify the virtual channels for channel 1 to capture. [17:41] give me a sec I should re-look into my patches I think Laurent is asking how this is handled according to the routing API that is interesting indeed [17:42] especially the mention of the TAG signal which would imply that the output of the CSI-2 has a tag for each sample So with a multiplexd stream API we could set what VC to output for which channel and have a fixed immutable CSI-2 to VIN remving much of the need for the horrible VIN group design I still think the CHSEL routes CSI-2 channels, not CSI-2 VC/DT would it be fair to conclude that more tests are needed ? [17:44] to check more combinations of parameter I think so, but it's an interesting find s I would welcome a shared testing strategy [17:46] how so ? by sharing testing, or by discussing the strategy ? [17:47] *** damm (~damm@167.99.4.198) has quit: Remote host closed the connection [17:48] *** damm (~damm@167.99.4.198) has joined channel #periperi I thought about this a while back and wanted to start to test if what Jacopo now reports even was possibe using VCDT [17:49] I'm thinking about a shared plan about -what- to test [17:50] The next step was my dream of removing the horrid routing limitations between VIN and CSI-2, back then I thought about using media links, but if multiplexed streams is on the way maybe S/G_ROUTING would have been my first experiment as I think it would be simpler [17:51] If I where to test this I would force a static CHSEL from VIN, one CSI-2 output channel to each VIN and then see if I can using VCDT route a single VC to each VIN and if that works move on to use more streams [17:52] *** damm (~damm@167.99.4.198) has quit: Ping timeout: 256 seconds [17:53] If that works I think we can start to bikeshed about how to best make use of it. But I think a first step is to make sure it works as a prototype could the two of you coordinate on the test strategy then ? [17:54] sure if there's any interest in me continuing with this activty ofc I'm certainly interested :-) [17:55] we have an odd hardware setup, and making sure it can be properly supported with the new API is important ok then I think it's mostly about me and niklas agreeing on a time to work together on this if he has bandwidth [17:56] I'm extatic about anything that can reduce the complexity and get rid of the VIN groups ;-) [17:57] ok, so let's sync to do some work and discussions on this then sounds good thanks :-) [17:58] thank you any other discussion topic for today ? no thanks :) at least not from me ? I'm good I thus propose adjourning the meeting. does anyone second ? [17:59] +1 +1 thank you all [18:00] Thanks all have a great day meeting adjourned thank you all for attending thank you all. bye! [18:02]