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