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