diff options
| -rw-r--r-- | wiki/Chat_log/20211007-mm-chatlog | 252 |
1 files changed, 252 insertions, 0 deletions
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 +<pinchartl> * Geert +<pinchartl> Since last meeting: +<pinchartl> - Investigated an ADV7511 s2ram crash, to discover a DRM EDID bug +<pinchartl> Until next meeting: None +<pinchartl> Issues and blockers: None +<pinchartl> geertu: any comment ? +<geertu> It seems the i2c bus is locked up +<geertu> and on subsequent reset, EDID cannot be read, too [17:06] +<pinchartl> Wolfram mentioned he would investigate on the I2C side +<pinchartl> I have another display bug reported by Morimoto-san to handle +<pinchartl> so I'll happily ignore the adv7511 for now :-) until Wolfram + completes his investigations (or I fix the other bug) [17:07] +<geertu> Yeah, I saw that. Could that be fw_devlink? +<pinchartl> I doubt it [17:08] +<wsa> pinchartl: that will be an interesting race :) +<pinchartl> :-) [17:09] +<pinchartl> * Jacopo +<pinchartl> Since last meeting: +<pinchartl> - V4L2 multiplexed streams support for GMSL - review and + discussion of v4l2-mux support from Tomi - R-Car CSI-2 + GMSL + ported to v4l2-mux +<pinchartl> - R-Car ISP review +<pinchartl> Until next meeting: +<pinchartl> - New version of v4l2-mux with VIN channels properly handled +<pinchartl> Issues and blockers: None +<pinchartl> jmondi: any comment ? +<jmondi> pinchartl: not really, apart from the point I mentioned in C) +<pinchartl> I've added it to the discussion points +<jmondi> thanks +<pinchartl> thank you +<jmondi> let's keep it for later [17:10] +<pinchartl> * Kieran +<pinchartl> Since last meeting: +<pinchartl> - Investigate V3U display timings +<pinchartl> Until next meeting: +<pinchartl> - Investigate V3U display timings +<pinchartl> Peripheral clock confirmed, but still need to dig in and verify + things here. +<pinchartl> Issues and blockers: None +<pinchartl> Kieran is on vacation this week, I don't think he's with us today +<pinchartl> I've been working with him on the V3U display, so I can try to + answer questions if there are any +<pinchartl> * Laurent [17:11] +<pinchartl> Since last meeting: +<pinchartl> - Upstreamed pending patches +<pinchartl> Most notably, sent pull requests for V3U support in DU, and for + non-contiguous buffer import. +<pinchartl> - V4L2 multiplexed streams development +<pinchartl> Continued working with Tomi Valkeinen. Still work in progress (v9 + is out). Reviewed Jacopo's MAX9286 multiplexed streams support. +<pinchartl> - Tested HDMI probe issue with v5.15-rc1 +<pinchartl> Couldn't reproduce on M3-N Salvator-XS, will test on ULCB next. +<pinchartl> Until next meeting: +<pinchartl> - Debug HDMI probe issue on v5.15-rc1 +<pinchartl> - V4L2 multiplexed streams development +<pinchartl> Issues and blockers: None +<pinchartl> any question ? +<moriperi> thank you for checking HDMI issue [17:12] +<pinchartl> you're welcome. now I have to dust my ULCB :-) +<pinchartl> * Morimoto-san +<pinchartl> Since last meeting: +<pinchartl> - Posted ALSA SoC new generic sound card driver +<pinchartl> Maintainer said basically OK, got some feedback about from + non-maintainer, posted v4. +<pinchartl> Until next meeting: +<pinchartl> - Continue ALSA SoC work +<pinchartl> Issues and Blockers: +<pinchartl> - v5.15-rc1 doesn't probe HDMI +<pinchartl> Issue reported to Laurent and to mailing list. +<pinchartl> moriperi: any comment ? +<moriperi> 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 +<pinchartl> * Niklas +<pinchartl> Since last meeting: +<pinchartl> - [PATCH] media: rcar-vin: Use user proved buffers when starting +<pinchartl> - [PATCH v3] media: staging: max96712: Add basic support for + MAX96712 GMSL2 deserializer +<pinchartl> - [PATCH v5] media: rcar-isp: Add Renesas R-Car Image Signal + Processor driver +<pinchartl> - [PATCH v2 0/2] rcar-csi2: Serialize format cfg and improve mutex + handling +<pinchartl> - [PATCH v6] media: rcar-isp: Add Renesas R-Car Image Signal + Processor driver +<pinchartl> Until next meeting: +<pinchartl> - Follow up pending patches +<pinchartl> Issues and blockers: None +<pinchartl> neg: any comment ? +<neg> No comment +<pinchartl> thank you [17:14] +<pinchartl> that's it for the MM status update unless I've forgotten someone +<pinchartl> Topic 2. Discussions +<pinchartl> - R-Car VIN channel handling for v4l2-mux [17:15] +<pinchartl> jmondi: what is that about ? +<jmondi> so, I've implemented support for multiplxing and CSI-2 VC routing on + max9286 and R-Car CSI-2 +<jmondi> the part I am missing, and from a brief discussion we had I am + probably misunderstanding, is the VIN part [17:16] +<jmondi> as we all know VIN has a CHSEL register with a fixed number of + combinations +<jmondi> 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] +<jmondi> 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] +<jmondi> I can make an example +<neg> From a multiplexed stream PoV just ignore that the CHSEL register exists + ;-) +<jmondi> how so ? +<neg> 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] +<jmondi> from what I see empirically, it also have an impact on filtering +<jmondi> I can make an example +<neg> 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] +<jmondi> on V3M, have a look at the chsel table (page 2006 of datasheet 2.20) +<jmondi> I am configuring the CSI-2 interface to route VC0 on source pad#1 and + VC1 to source pad #4 [17:21] +<jmondi> this in my understanding corresponds to the first row of the chsel + table +<jmondi> the way the chsel mask building procedure works leads to a chsel mask + of value 0x3 [17:22] +<jmondi> which expects VC3 to be on pad #4, not VC1 +<jmondi> in my mind that could be solved by inspecting the CSI-2 frame desc, + and configuring the mask accordingly [17:23] +<jmondi> but I got from the two of you that chsel should not be involved with + routing +<jmondi> unfortunately, if I stick with the computed chsel=0x3 VIN3 output is + blank [17:24] +<jmondi> if I instead use a chsel value of 0x00 I get good images +<neg> The CHSEL value calculation don't care about VC, it only looks at the + media graph links [17:26] +<jmondi> 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] +<neg> 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 +<neg> and that of course shall be fixed +<neg> But this bug would then exists today and would not depend on any + multiplexed stream work [17:28] +<jmondi> 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] +<neg> d00h, yes I got confused that in your multiplexed work you break that + assumtion ;-) [17:32] +<jmondi> 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 +<neg> But this is good news then, I had been mening to try if what you + descirbe here works +<jmondi> (even if I don't get why VC and datatype are mixed there) +<jmondi> I mean, we might assume the [VC, CSI source pad] association is fixed + [17:33] +<neg> Because if it do we could simplify the VIN routing I think, as we could + allow any VIN to be routed to any VC +<jmondi> but it would limit the HW supported features +<jmondi> yeah, well, considering the limited number of possible routes each + SoC supports :) [17:34] +<neg> 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] +<pinchartl> can that be done ? [17:36] +<pinchartl> are the other options than CHSEL to control routing ? +<jmondi> didn't get the question :) +<pinchartl> s/are the/are there/ [17:37] +<neg> If I understood Jacopo this is what he does in his multiplexed stream + series and this is why he see this issue +<jmondi> my understanding is that CHSEL does not control routing but rather + filtering [17:38] +<neg> 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 +<jmondi> and that surprises me as it means the VIN has the notion of VC/DT +<jmondi> while I always assumed there's just a parallel data bus between VIN + and CSI-2 [17:39] +<pinchartl> how do you control routing within the CSI-2 receiver ? +<jmondi> through which registers you mean ? +<pinchartl> yes +<neg> VCDT and VCDT2 +<neg> 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] +<jmondi> give me a sec I should re-look into my patches +<jmondi> I think Laurent is asking how this is handled according to the + routing API +<pinchartl> that is interesting indeed [17:42] +<pinchartl> especially the mention of the TAG signal +<pinchartl> which would imply that the output of the CSI-2 has a tag for each + sample +<neg> 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 +<pinchartl> I still think the CHSEL routes CSI-2 channels, not CSI-2 VC/DT +<pinchartl> would it be fair to conclude that more tests are needed ? [17:44] +<pinchartl> to check more combinations of parameter +<neg> I think so, but it's an interesting find +<pinchartl> s +<jmondi> I would welcome a shared testing strategy [17:46] +<pinchartl> 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 +<neg> 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] +<jmondi> I'm thinking about a shared plan about -what- to test [17:50] +<neg> 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] +<neg> 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] +<neg> 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 +<pinchartl> could the two of you coordinate on the test strategy then ? + [17:54] +<jmondi> sure +<jmondi> if there's any interest in me continuing with this activty ofc +<pinchartl> I'm certainly interested :-) [17:55] +<pinchartl> we have an odd hardware setup, and making sure it can be properly + supported with the new API is important +<jmondi> ok then +<jmondi> I think it's mostly about me and niklas agreeing on a time to work + together on this if he has bandwidth [17:56] +<neg> I'm extatic about anything that can reduce the complexity and get rid of + the VIN groups ;-) [17:57] +<jmondi> ok, so let's sync to do some work and discussions on this then +<neg> sounds good +<jmondi> thanks +<pinchartl> :-) [17:58] +<pinchartl> thank you +<pinchartl> any other discussion topic for today ? +<jmondi> no thanks :) +<jmondi> at least not from me ? +<neg> I'm good +<pinchartl> I thus propose adjourning the meeting. does anyone second ? + [17:59] +<neg> +1 +<jmondi> +1 thank you all [18:00] +<neg> Thanks all have a great day +<pinchartl> meeting adjourned +<pinchartl> thank you all for attending +<shimoday> thank you all. bye! [18:02] |