summaryrefslogtreecommitdiff
path: root/wiki
diff options
context:
space:
mode:
Diffstat (limited to 'wiki')
-rw-r--r--wiki/Chat_log/20210415-mm-chatlog198
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