wiki: add M/M chatlog from 20200702

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

1 files changed, 255 insertions, 0 deletions

diff --git a/wiki/Chat_log/20200903-mm-chatlog b/wiki/Chat_log/20200903-mm-chatlog
new file mode 100644
index 0000000..13a4f02
--- /dev/null
+++ b/wiki/Chat_log/20200903-mm-chatlog
@@ -0,0 +1,255 @@
+<pinchartl> welcome to the multimedia group meeting
+<jmondi> pinchartl: hello  [17:05]
+<pinchartl> Topic 1. Status Check for the Multimedia Tasks
+<pinchartl> * Jacopo
+<pinchartl> Since last meeting:
+<pinchartl> - Linux Plumbers Conference
+<pinchartl> - DT bindings image sensor conversion
+<pinchartl> Converted mt9v111, imx214, ov5670 and ov772x
+<pinchartl> - max9286 format configuration
+<pinchartl> To prepare for upstreaming support for RDACM21, the max9286 driver
+<pinchartl> has to be adapted to support different receivers.
+<pinchartl> [PATCH 0/4] media: i2c: max9286: Use remote endpoint image format
+<pinchartl> The series was not exactly apreciated, so a different solution is
+<pinchartl> required.
+<pinchartl> - Patch review
+<pinchartl> Reviewed Prabhakar'd ov772x and ov5640 patches for Renesas G1H dev
+<pinchartl> boards.
+<pinchartl> Until next meeting:
+<pinchartl> - Re-think how to handle formats for max9286
+<pinchartl> - Resume GMSL reverse channel configuration discussion
+<pinchartl> - Re-send dt-bindings now that we have clarified how to handle
+<pinchartl>   endpoints
+<pinchartl> Issues and blockers: None
+<pinchartl> jmondi: you can go first :-) any comment ?
+<jmondi> not really, I think I need to re-look at format handlin on max9286
+								        [17:06]
+<jmondi> but no comment on the current status update thanks
+<pinchartl> ok, thanks
+<pinchartl> regarding format handling, would you like to discuss during this
+	    meeting, or do you need to look at it first ?  [17:07]
+<jmondi> pinchartl: if we have 5 minutes at the end, let's discuss it
+<pinchartl> ok, I'll add it to the discussion points
+<jmondi> it shouldn't be long after all, I just need to convince you and
+	 Sakari... it's gonna be like 5 minutes, right ? =)  [17:08]
+<pinchartl> * Kieran
+<pinchartl> Since last meeting:
+<pinchartl> - Linux Plumbers Conference
+<pinchartl> - Patch review
+<pinchartl> - GMSL reviews/fixups
+<pinchartl> - ADV748x audio input
+<pinchartl> Failed to successfully capture anything. Responded to author, not
+	    sure
+<pinchartl> if the test procedure is wrong or if the problem lies elsewhere.
+<pinchartl> Until next meeting:
+<pinchartl>  - Aim to finish/resolve the ADV748x audio tests
+<pinchartl>  - Work towards DT integration/overlays for GMSL
+<pinchartl>  - Look at V4L2 Multiplex streams topics for GMSL
+<pinchartl> Issues and blockers: None
+<pinchartl> Kieran asked to be excused as he's stuck babysitting today
+<pinchartl> * Laurent
+<pinchartl> Since last meeting:
+<pinchartl> - Linux Plumbers Conference
+<pinchartl> Participated (among other topics) in the dmabuf heaps and
+	    userspace
+<pinchartl> buffer allocation library discussions.
+<pinchartl> - DISCOM CRC calculation tool
+<pinchartl> Implemented a tool to calculate the CRC of an image using the same
+<pinchartl> algorithm as the DISCOM, and integrated it in the DU test
+	    suite. This
+<pinchartl> exposed a crash in the DU driver, developed and posted a fix.
+<pinchartl> - V4L2 async subdev allocation fixes
+<pinchartl> Posted fixes for V4L2 async subdev allocation in the various
+	    Renesas
+<pinchartl> V4L2 drivers. The fix for VIN has been superseded by patches from
+<pinchartl> Niklas. The fix for DRIF is pending testing from the Renesas UK
+	    team.  [17:09]
+<pinchartl> - Patch review
+<pinchartl> Among other things, Renesas UK has provided the schematics for the
+	    iWave
+<pinchartl> board, which unblocked review of the DT integration.
+<pinchartl> Until next meeting:
+<pinchartl> - Follow-up on pending patch series
+<pinchartl> Get pending patches merged, pinging maintainers where needed.
+<pinchartl> - Help with debugging the DU + CMM suspend/resume crash if needed
+<pinchartl> - Move forward with the V4L2 multiplexed streams proposal
+<pinchartl> Issues and Blockers: None
+<pinchartl> any question ?
+<moriperi> Thank you for DISCOM tool
+<pinchartl> you're welcome  [17:10]
+<pinchartl> * Morimoto-san
+<pinchartl> Since last meeting:
+<pinchartl> - Post Renesas menu Kconfig patch
+<pinchartl> v3 may be needed.
+<pinchartl> - Continue posting ALSA SoC cleanup patches
+<pinchartl> - Complex connection handling in ALSA SoC
+<pinchartl> Current ALSA SoC has 2 generic sound card (= glue for SoC / Codec)
+<pinchartl> driver, and one of them is for OF-graph. Current ALSA SoC
+	    maintainer is
+<pinchartl> recommending to use it. But unfortunately, it can't handle complex
+<pinchartl> connection for now.  But in these days, at least 2 vendors want to
+	    use
+<pinchartl> complex connections by using this generic driver. One of them has
+	    posted
+<pinchartl> *hack* patches. Thus I started to think about *non-hack* expansion
+	    for
+<pinchartl> it.
+<pinchartl> Until next meeting:
+<pinchartl> - Create dummy test driver to develop complex connection handling
+<pinchartl> - Continue posting ALSA SoC cleanup patches
+<pinchartl> Issues and Blockers: None
+<pinchartl> moriperi: any comment ?
+<moriperi> thanks. no comment, but have question. later this.  [17:11]
+<pinchartl> ok
+<pinchartl> * Niklas
+<pinchartl> Since last meeting:
+<pinchartl> - [PATCH 0/2] v4l: async: Switch to endpoint node matching
+<pinchartl> - [PATCH 0/2] rcar-vin: Fix issues with partial probed media
+	    graphs
+<pinchartl> - Summer vacation, back in office Monday the 7th
+<pinchartl> Until next meeting:
+<pinchartl> - Post second round of improvements for VIN and V4L2 lifetime
+	    issues
+<pinchartl> - Backlog cleaning
+<pinchartl> Issues and blockers: None
+<pinchartl> Niklas asked to be excuse as he's travelling back to Germany
+<pinchartl> Topic 2. Discussions
+<pinchartl> moriperi: you said you have a question for later. I think later
+	    could be now :-)  [17:12]
+<moriperi> jacopo first is oK
+<pinchartl> ok :-)
+<pinchartl> MAX9286 format handlign then
+<pinchartl> jmondi: ?
+<jmondi> yup  [17:13]
+<jmondi> well, I think the deser should reflect the remote's format, you and
+	 Sakari think not
+<jmondi> I think it boils down to that, right ? :)
+<pinchartl> pretty much :-)  [17:14]
+<pinchartl> the design idea behind MC drivers is that format propagation
+	    should be handled by userspace
+<pinchartl> for multiplexed streams, we may do otherwise
+<pinchartl> but the GMSL link isn't multiplexed, it carries a single stream
+								        [17:15]
+<jmondi> I don't see it being related to multiplexed, but more specifically on
+	 what the de-serializer does
+<jmondi> you can say it's not different from any other bridge
+	 $protocol-to-csi2
+<pinchartl> correct  [17:16]
+<jmondi> I see
+<pinchartl> and if you look at a parallel to CSI-2 chips, they don't fetch the
+	    remote format on the parallel sink
+<pinchartl> userspace propagates the format on the parallel side
+<jmondi> and indeed format can be set on the sink pads
+<jmondi> so it's maybe better handled by updating the vin-test scripts  [17:17]
+<jmondi> parsing the remote format and apply it on the deser sink pads
+<pinchartl> media-ctl will do it for you  [17:18]
+<pinchartl> if you set the format on a source pad that has a connected link,
+	    it will automatically set it on the remote sink pad
+<jmondi> across links ?  [17:19]
+<jmondi> I never noticed that :/
+<pinchartl> yes, across links
+<jmondi> good to know, now I should check why it doesn't happen then
+<jmondi> anyway, let's defer to userspace
+<pinchartl> ok  [17:20]
+<jmondi> thanks, moriperi please go ahead then
+<pinchartl> another discussion point, DU + CMM suspend/resume crash
+<jmondi> ah
+<jmondi> I'm at "please rest (for now)"  [17:21]
+<pinchartl> moriperi: you mentioned in an e-mail that you would check with the
+	    customer whether we need to look into this
+<jmondi> any update ?
+<pinchartl> do you have any update on that ?
+<moriperi> no update if my memroy was correct  [17:22]
+<pinchartl> should we still wait ? I'd like to raise the issue with the PM
+	    core developers, as I think the problem would be fixed if they
+	    didn't forcefully PM-runtime-resume devices needlessly at system
+	    suspend
+<geertu> The person from Renesas EU who contacted me regards this issue, had
+	 told me he pinged Eugeniu.  [17:24]
+<geertu> But so far no response from Eugeniu, AFAIK
+<pinchartl> I propose initiating the PM discussion, as these matters may take
+	    time
+<moriperi> I don't remember detail, but DU also has bind/unbind issue ?
+								        [17:25]
+<pinchartl> is that a separate issue ?
+<moriperi> oops ? please ignore, my fault maybe  [17:26]
+<pinchartl> it could just be me misremembering it :-)
+<pinchartl> jmondi: does it ring a bell ?  [17:27]
+<jmondi> bind/unbind not really :(  [17:28]
+<moriperi> So is it my turn ?
+<pinchartl> yes :-)
+<jmondi> moriperi: please go ahead!
+<moriperi> Thanks
+<moriperi> About OF-graph
+<moriperi> I know we can use "ports" for "port" groups
+<moriperi> ports - port - endpoint
+<moriperi>         port - endpoint
+<moriperi>         ...
+<moriperi> But now, I want to have sub-groups, like this
+<moriperi> ports - port  - endpoint
+<moriperi>       - port  - endpoint
+<moriperi> 
+<moriperi>       - ports - port - endpoint   <=  [17:29]
+<moriperi>               - port - endpoint   <=
+<moriperi> I think OF-graph doesn't support it, right ?
+<pinchartl> correct
+<moriperi> Do you know someone who has same issue/idea ?
+<pinchartl> not really, no
+<pinchartl> what do you want to use that for ?
+<moriperi> now I nama it as port3, port4.
+<moriperi> s/nama/name  [17:30]
+<moriperi> port3, and port4 are separate device, but want to use in the same
+	   time as same interface
+<moriperi> thus we want to group  [17:31]
+<pinchartl> I don't know of anyone who would have tried to do that
+<pinchartl> maybe the best option would be to post an RFC to explain the
+	    problem and the proposed solution ?
+<pinchartl> it would be helpful if it explained the hardware architecture and
+	    gave a corresponding DT example  [17:32]
+<moriperi> Yes maybe. Or I already have other idea. but in that, the graph
+	   will be very huge :(
+<moriperi> but it is ok for now, not a big-deal. thanks  [17:33]
+<moriperi> pinchartl: ahhh, about bind/unbind, it was for VIN, not for DU
+								        [17:34]
+<pinchartl> you're welcome. I'd be happy to help if I can, please just let me
+	    know :-)
+<moriperi> sorry for my noise
+<pinchartl> yes, for VIN we clearly had issues
+<pinchartl> no worries
+<pinchartl> any other discussion point for today ?
+<moriperi> not from me  [17:35]
+<jmondi> pinchartl: one last thing
+<jmondi> i2c sensor yaml :) (I know..)
+<wsa> next meeting on October, 1st?
+<jmondi> we decided to defer to of-graph.yaml ports/endpoint/remote-endpoint
+<jmondi> but what if I have endpoint properties to document ?
+<pinchartl> in that case you should have the endpoints in your bindings
+								        [17:36]
+<pinchartl> it's only for the case where nothing else needs to be documented
+	    that you can drop them
+<pinchartl> basically, of-graph.yaml will take care of the schema for
+	    ports/port/endpoint/remote-endpoint  [17:37]
+<pinchartl> so it doesn't have to be duplicated everywhere
+<pinchartl> but the rest needs to be handled manually
+<pinchartl> any question still about this ?  [17:39]
+<jmondi> on
+<jmondi> no
+<jmondi> just wanted to make sure so next iteration is ok
+<jmondi> thanks for the answer
+<pinchartl> you're welcome  [17:41]
+<pinchartl> any other discussion topic ?
+<wsa> next meeting on October, 1st?
+<pinchartl> :-)
+<pinchartl> works for me
+<geertu> #metoo  [17:42]
+<shimoda> works for me
+<pinchartl> I propose adjourning the multimedia meeting
+<pinchartl> does anyone second ?
+<wsa> good, then it is decided  [17:43]
+<geertu> third?
+<jmondi> seconded!  [17:44]
+<pinchartl> meeting adjourned. thank you all for attending  [17:45]
+<pinchartl> have a nice day
+<jmondi> thank you all
+<damm> thanks guys  [17:46]
+<shimoda> thanks!  [17:47]