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]