diff options
author | Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> | 2021-04-16 07:14:42 +0900 |
---|---|---|
committer | Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> | 2021-04-16 07:14:42 +0900 |
commit | 917d51a938158650959d711a6f43e5461103355b (patch) | |
tree | c618951c447ef3c80e9bb827e40fac7b103ba3e4 | |
parent | 648360a19e7a7e13aa72a39f4874b30254095457 (diff) |
wiki: Add M/M chatlog for 20210415
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
-rw-r--r-- | wiki/Chat_log/20210415-mm-chatlog | 198 |
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 |