wiki: Add M/M chatlog for 20210415

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

1 files changed, 198 insertions, 0 deletions

diff --git a/wiki/Chat_log/20210415-mm-chatlog b/wiki/Chat_log/20210415-mm-chatlog
new file mode 100644
index 0000000..27754f8
--- /dev/null
+++ b/wiki/Chat_log/20210415-mm-chatlog
@@ -0,0 +1,198 @@
+<pinchartl> welcome to the multimedia meeting
+<pinchartl> Topic 1. Status Check for the Multimedia Tasks
+<pinchartl> * Jacopo
+<pinchartl> Since last meeting:
+<pinchartl> - GMSL reliability (v5)
+<pinchartl> - MAX9286 integration on Eagle (v3)
+<pinchartl> Until next meeting:
+<pinchartl> - Complete RDACM20 stress tests after having validated RDACM21
+<pinchartl> - max9271 to be turned into an I2C driver
+<pinchartl> Issues and blockers: None
+<pinchartl> jmondi: any comment ?
+<jmondi> not really						        [16:48]
+<pinchartl> thank you
+<pinchartl> * Kieran
+<pinchartl> Since last meeting:
+<pinchartl> - GMSL review and support
+<pinchartl> - GP LED support integrated for V3U
+<pinchartl> - V3U FCPVD and VSPD support posted.
+<pinchartl> - Rebased and pushing the DU group rework
+<pinchartl> Until next meeting:
+<jmondi> maybe geertu can explain me what he meant with 'gpio-hog' style
+<pinchartl> - Further development on VSPD/DU for V3U
+<jmondi> but later
+<pinchartl> Issues and blockers: None				        [16:49]
+<pinchartl> kbingham: any comment ?
+<kbingham> No
+<pinchartl> thank you
+<pinchartl> * Laurent
+<pinchartl> Since last meeting:
+<pinchartl> - V4L2 multiplexed streams development
+<pinchartl> - Periject triage for display (complete)
+<pinchartl> - Upported and submitted DU driver fixes
+<pinchartl> - SN65DSI86 upporting
+<pinchartl> 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.
+<pinchartl> - DSI driver upporting
+<pinchartl> Work in progress.
+<pinchartl> Until next meeting:
+<pinchartl> - V4L2 multiplexed streams development
+<pinchartl> Patches should be posted within the next month.
+<pinchartl> - DSI driver upporting
+<pinchartl> - DU driver upporting
+<pinchartl> This will enable testing of the whole display chain, once VSP is
+	    ready.
+<pinchartl> - Display drivers upstreaming
+<pinchartl> Tentative, if testing (and bug fixing) can be completed on time.
+<pinchartl> Issues and blockers: None
+<pinchartl> any question ?
+<pinchartl> * Morimoto-san					        [16:50]
+<pinchartl> Since last meeting:
+<pinchartl> - ALSA Framework cleanup is finally done !
+<pinchartl> - Started to post new generic sound card driver
+<pinchartl> - Creating sound autotest environment by using Ulrich's atest
+<pinchartl> It's not the best match to the test environment, asked Ulrich to
+	    add new features.
+<pinchartl> Until next meeting:
+<pinchartl> - Continue to posting patch ot ALSA
+<pinchartl> - Update Sound autotest environment by using Ulrich's atest
+<pinchartl> Issues and Blockers:
+<pinchartl> - Ulrich's atest sometimes fails, the reason is unknown
+<pinchartl> morimoto: any comment ?
+<morimoto> I want to talk to Ulrich about atest
+<morimoto> about others, no comment. thanks
+<uli__> yes?
+<morimoto> On Email, OK ?					        [16:51]
+<uli__> sure
+<morimoto> Thanks a lot
+<pinchartl> thank you
+<pinchartl> * Niklas
+<pinchartl> Since last meeting:
+<pinchartl> - [PATCH] rcar-csi2: Add support for Y10 and Y8
+<pinchartl> - [PATCH] media: dt-bindings: media: renesas,csi2: Node port@0 is
+	    not mandatory
+<pinchartl> - [PATCH] arm64: dts: renesas: aistarvision-mipi-adapter-2.1:
+	    Explicitly state csi40 port
+<pinchartl> - [PATCH] media: staging: max96712: Add basic support for MAX96712
+	    GMSL2 deserializer
+<pinchartl> - [PATCH] media: dt-bindings: media: renesas,csi2: Add r8a779a0
+	    support
+<pinchartl> - [PATCH] rcar-csi2: Add r8a779a0 support		        [16:52]
+<pinchartl> - [PATCH] media: dt-bindings: media: renesas,isp: Add bindings for
+	    ISP Channel Selector
+<pinchartl> - [PATCH] media: rcar-isp: Add Renesas R-Car Image Signal
+	    Processor driver
+<pinchartl> - [PATCH] media: dt-bindings: media: renesas,vin: Add r8a779a0
+	    support
+<pinchartl> - [PATCH 00/11] rcar-vin: Add r8a779a0 support
+<pinchartl> - [PATCH] arm64: dts: renesas: falcon-csi-dsi: Add GPIO extenders
+<pinchartl> - [PATCH 0/2] arm64: dts: renesas: falcon: Wire up MAX96712
+<pinchartl> - Video capture on V3U work in Japan lab
+<pinchartl> This uses the MAX96712 and R-Car ISP drivers.
+<pinchartl> 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
+<pinchartl> Until next meeting:
+<pinchartl> - Follow up pending patches
+<pinchartl> - Finish a set of cleanup patches found while working on V3U
+<pinchartl> Issues and blockers:
+<pinchartl> - Need GMSL2 cameras (ideally locally, worst case remotely)
+<pinchartl> neg: any comment ?
+<pinchartl> I have a few questions. the test patterns are generated by the
+	    MAX96712, right ?
+<neg> yes
+<neg> the patterns are generated by the MAX96712, no I don't have any comments
+      ;-)							        [16:53]
+<pinchartl> :-)
+<kbingham> neg, I have GMSL1 (RDACM21) cameras attached to the v3u here. But
+	   RDACM21 != GMSL2.
+<pinchartl> I suppose that's running the BSP code ?
+<neg> nope
+<neg> I wrote a new driver
+<pinchartl> ah, nice
+<pinchartl> with the ISP in bypass mode ?			        [16:54]
+<neg> No the ISP is used for channel selection
+<pinchartl> I mean the ISP core
+<neg> Ahh yes							        [16:55]
+<pinchartl> 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]
+<neg> 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]
+<pinchartl> we know we don't have information about the ISP core
+<neg> 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
+<pinchartl> ok							        [16:58]
+<neg> and for that I think we have enough information, anything more advanced
+      that that I have not really checked or thought about
+<pinchartl> but you haven't noticed clearly missing information when it comes
+	    to configuration of the routing (still with the ISP core bypassed)
+	    ?
+<neg> So far I only have one bit of information missing		        [16:59]
+<pinchartl> what is it ?
+<neg> 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]
+<neg> or at least I have not found it
+<neg> 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]
+<pinchartl> ok
+<pinchartl> thanks for the information
+<pinchartl> and nice work !
+<neg> thanks
+<neg> IMHO all of the current work is ready to be consumed	        [17:02]
+<pinchartl> * Ulrich
+<pinchartl> Since last meeting:
+<pinchartl> - Fixed another bug in atest, applied Morimoto-san's patches
+<pinchartl> Until next meeting:
+<pinchartl> - Fix more issues in atest
+<pinchartl> Issues and blockers: None
+<pinchartl> uli__: any comment ?
+<uli__> nope							        [17:03]
+<neg> 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 ;-)
+<pinchartl> thank you
+<pinchartl> Topic 2. Discussions
+<pinchartl> any discussion topic for today ?			        [17:04]
+<neg> 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
+<kbingham> neg, Does the MAX96712 need separate configuration to support both?
+								        [17:05]
+<neg> kbingham: Also for totally understandable reasons the fire board is not
+      reachable during my office hours ;-)
+<kbingham> neg You could stay up 'late' one night hehehe
+<kbingham> but indeed.
+<kbingham> neg, Let me know if you want me to test things though.       [17:06]
+<neg> 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
+<neg> kbingham: Absolutely, thanks!
+<kbingham> neg, but the driver will be able to support both right?
+<neg> yes							        [17:07]
+<kbingham> or is it 'a separate' driver ... a la gen2/gen3 vin :-)
+<neg> 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
+<neg> but it would not surprise me, but maybe we don't need to start out by
+      considering that ;-0					        [17:08]
+<kbingham> :-)
+<wsa> kbingham: you rather have the board on fire when you sleep??
+<kbingham> wsa, No ;-) Neg staying up late pushes him into my office hours ;-)
+								        [17:09]
+<neg> wsa: I can't really function before 23pm :-)
+<wsa> oh, that are your office hours then...			        [17:10]
+<neg> That's it from me, sorry to drag on
+<pinchartl> no worries
+<pinchartl> if there's no other discussion topic, I propose adjourning the
+	    meeting. does anyone second ?
+<jmondi> o/
+<neg> +1							        [17:11]
+<pinchartl> meeting adjourned. thank you for attending everybody
+<neg> have a nice day
+<morimoto> have a nice day EuroPeri 				        [17:12]
+<uli__> see you
+ERC> 
\ No newline at end of file