< geertu> pinchartl: mic  [17:18]
< pinchartl> thank you
<pinchartl> welcome to the multimedia meeting
<pinchartl> we have 12 minutes ;-)
<pinchartl> Topic 1. Status Check for the Multimedia Tasks
<pinchartl> * Jacopo  [17:19]
<pinchartl> Since last meeting:
<pinchartl> - V6 of max9286 integration on Eagle and Condor
<pinchartl> [PATCH v6 0/8] arm64: dts: renesas: Enable GMSL on Eagle and
	    Condor
<pinchartl> - MAX9271 as a proper subdevice driver
<pinchartl> [RFC 0/5] media: i2c: Add MAX9271 subdevice driver
<pinchartl> - Investigated IMR support with a V4L2 M2M driver
<pinchartl> Until next meeting:
<pinchartl> - If Mauro replies, continue MAX9271 breakout
<pinchartl> - Make a plan for IMR ?
<pinchartl> Issues and blockers: None
<pinchartl> jmondi: any comment ? I've added IMR as a discussion point
<pinchartl> Since last meeting:
<pinchartl> - V3U display investigations
<pinchartl> - V3U DU v2
<pinchartl> - Supporting Wolfram with V3U access (fun poking CN4 pins)
<pinchartl> - Misc review
<pinchartl> Until next meeting:
<pinchartl> - Investigate V3U display timings
<pinchartl> Not happy at 4k resolution
<pinchartl> -
	    https://lore.kernel.org/r/CAMuHMdWSeeifBLqi4S6LrgcQg9E_1xFXzLzBBBqMf1Fc0kbMhg@mail.gmail.com/
<pinchartl> Issues and blockers: None
<pinchartl> kbingham: any comment ?
<pinchartl> (missing the header with your name, oops, sorry)
<pinchartl> * Laurent  [17:20]
<pinchartl> Since last meeting:
<pinchartl> - V4L2 multiplexed streams development
<pinchartl> Continued working with Tomi Valkeinen. Still work in progress (v8
	    is out).
<pinchartl> - Resuscitated non-contiguous DMABUF import for DU
<pinchartl> No review received so far, which is good as it means nobody
	    objects (or maybe the patch went under the radar). Still, a review
	    before merging would be good.
<pinchartl> Added support for buffer sharing between V4L2 and DRM to the
	    excellent 'cam' tool from libcamera, highly recommended for
	    testing ;-)
<pinchartl> - Fixed DU regression on Draak/Ebisu
<pinchartl> Will be integrated in v5.16.
<pinchartl> Until next meeting:
<pinchartl> - Upstream pending patches
<pinchartl> - V4L2 multiplexed streams development
<pinchartl> - If time permits, fix known issues with V3U displa
<pinchartl> Issues and blockers: None
<pinchartl> any question ?
<pinchartl> * Morimoto-san
<pinchartl> Since last meeting:
<pinchartl> - Plenty of cool non-multimedia things
<pinchartl> Until next meeting:
<pinchartl> - Resume ALSA work
<pinchartl> Issues and Blockers: None
<pinchartl> moriperi: any comment ?
<pinchartl> * Niklas
<kbingham> Only that I wonder if I need to buy ... another DisplayPort monitor
	   - or a DisplayPort/HDMI analsyzer... I know which one is cheaper,
	   and I know which one has more guaranteed results ...
<pinchartl> Since last meeting:
<pinchartl> - [PATCH 0/3] rcar-csi2: Improve link frequency selection
<pinchartl> - [PATCH 0/2] rcar-csi2: Serialize format cfg and improve mutex
	    handling
<pinchartl> - Tested and rebased work on-top the async rework/rename
<pinchartl> Until next meeting:
<pinchartl> - Follow up pending patches  [17:21]
<pinchartl> Issues and blockers: None
<pinchartl> neg: any comment ?
<pinchartl> (trying to pipeline the status reports this time, let's see if it
	    helps)
<pinchartl> the latter costs and arm and a leg
<pinchartl> and the soul of a few children
<kbingham> Yes, I'm aware of the costs ;-)
<kbingham> I have two child souls available, but I don't own the rights to
	   disperse their souls, so I can't use them as payment.  [17:22]
<damm> how about some sort of exchange?  [17:24]
<kbingham> haha ;-)
<damm> =)
<pinchartl> any other comment ?  [17:25]
<kbingham> not here
<pinchartl> Topic 2. Discussions  [17:26]
<pinchartl> - IMR development
<pinchartl> jmondi: did you want to discuss this ?
<jmondi> I would like to, yes
<jmondi> mostly to confirm it's a viable plan
<pinchartl> viable in what sense ? :-)
<jmondi> that it makes sense to upstream it  [17:27]
<jmondi> considering how tightly it is connected to the userpsace application
	 exercizing it  [17:28]
<jmondi> to which, afaict, we have no access to ?
<pinchartl> I think it makes sense  [17:29]
<pinchartl> but it means we'll have to create an application using it
<jmondi> then there's the discussion about which subsytem to use
<jmondi> cogent went up to v7 using the v4l2 m2m API
<jmondi> my understanding is that DRM would be more appropriate  [17:30]
<jmondi> what do you think ?
<pinchartl> I think DRM would be better, yes  [17:31]
<damm> if you can't decide then how about putting the driver in user space (if
       possible with IOMMU of course)
<damm> obviously a proper subsystem is better
<pinchartl> it's not just that it's an accelerator (see
	    https://lwn.net/Articles/867168/ for context)  [17:32]
<pinchartl> but it's a rendering engine
<pinchartl> the device takes textures + command buffer in, and outputs an
	    image
<jmondi> damm: with UIO you mean ?
<pinchartl> conceptually, that's like a GPU
<jmondi> so, the current implementation from cogent is much like the
	 HanbanaLab thing the article references to  [17:33]
<damm> jmondi: if doing a user space driver is the best option then perhaps
       UIO is good, but other more suitable options may exist too
<jmondi> a custom IOCTL to have the driver swallow a command set and apply it
	 to the HW  [17:34]
<pinchartl> damm: I think DRM is better than a userspace driver in this case
<damm> pinchartl: most likely yes =)
<jmondi> I'm surprised they went up to v7 without getting a nack, as even with
	 v4l2 m2m a different mechanism might be more opportune
<jmondi> like a set of v4l2-ctl like we have for codecs  [17:35]
<damm> i suppose the documentation is not public which means it is hard to get
       the details for people reviewing?
<pinchartl> damm: that's why we would need to provide an open-source userspace
	    application that actually uses the device  [17:36]
<pinchartl> it moves the burden of creating a standard userspace API from the
	    kernel to userspace
<damm> yeah makes sense
<pinchartl> I've discussed this with Daniel Vetter, and it would be enough to
	    satisfy the DRM upstreaming criteria, provided that the
	    application would be structured as a library with the
	    device-dependent code, and the application on top  [17:37]
<pinchartl> then when the next similar device gets upstream support, we can
	    turn the application into a proper framework
<jmondi> where would you see that userspace code living ?
<jmondi> I assume it cannot be a 'main.c + Makefile' in some random git tree
<pinchartl> fd.o  [17:39]
<pinchartl> and it should be a lib + main.c
<pinchartl> a framework for dewarp engines in a sense
<pinchartl> but as a prototype
<pinchartl> we can defer making it a real framework until a second driver gets
	    upstreamed  [17:40]
<pinchartl> but it should be architectured in that way to facilitate the
	    transition
<damm> can we take commands and textures and store then in DT somehow? =)
								        [17:41]
<damm> to make it side-ways compatible somehow
<pinchartl> if you want the output of the device to be static then yes
<pinchartl> but in that case I'd prerender the output and use that :-)
<damm> maybe different DT information could be overlaid during runtime?
								        [17:42]
<damm> (sorry i will stop now)  [17:43]
<pinchartl> :-)
<jmondi> :)
<pinchartl> so it seems we have a plan
<jmondi> I admit the userspace part is kind of scary
<pinchartl> a fun research project :-)
<jmondi> the driver part is too, but I can cope
<jmondi> I'm afraid the acceptance criteria for userspace can quickly escalate
	 to "implement it in weston" or similar  [17:44]
<pinchartl> that's why I've discussed it with Daniel
<pinchartl> implementing it in mesa doesn't make too much sense
<pinchartl> and creating the mesa of dewarp engines with a single device as an
	    example isn't a good idea
<jmondi> am I wrong assuming that if I do enbark in this 'reserach project' I
	 will fill up my time up to the next year ?
<pinchartl> so making a prototype for such a framework is enough
<pinchartl> next year is fairly soon  [17:45]
<jmondi> I meant end of Q12022
<jmondi> maybe it's even too optimistic
<wsa> I gotta leave now. Have a nice day everyone!  [17:46]
*** wsa (~wsa@mue-88-130-48-230.dsl.tropolys.de) has quit: Quit: ...
<pinchartl> any other discussion topic for today ?  [17:49]