wiki: Add M/M chatlog for 20210902

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>

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]