From 2d1f105c5e1d3f5618a3cccb4847f2c16fd20d7f Mon Sep 17 00:00:00 2001 From: Kuninori Morimoto Date: Thu, 7 Oct 2021 18:03:15 +0900 Subject: wiki: Add M/M chatlog for 20211007 Signed-off-by: Kuninori Morimoto --- wiki/Chat_log/20211007-mm-chatlog | 252 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 252 insertions(+) create mode 100644 wiki/Chat_log/20211007-mm-chatlog diff --git a/wiki/Chat_log/20211007-mm-chatlog b/wiki/Chat_log/20211007-mm-chatlog new file mode 100644 index 0000000..1b839b0 --- /dev/null +++ b/wiki/Chat_log/20211007-mm-chatlog @@ -0,0 +1,252 @@ +< 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] -- cgit v1.2.3