diff options
Diffstat (limited to 'wiki')
| -rw-r--r-- | wiki/Chat_log/20210902-mm-chatlog | 173 |
1 files changed, 173 insertions, 0 deletions
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 +<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] |