diff options
Diffstat (limited to 'wiki/Chat_log/20200903-mm-chatlog')
| -rw-r--r-- | wiki/Chat_log/20200903-mm-chatlog | 255 |
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] |