wiki: Add M/M chatlog for 20211007

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>

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]