< 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]