1 files changed, 334 insertions, 0 deletions
diff --git a/wiki/Chat_log/20180215-mm-chatlog b/wiki/Chat_log/20180215-mm-chatlog
new file mode 100644
index 0000000..630960d
--- /dev/null
+++ b/wiki/Chat_log/20180215-mm-chatlog
@@ -0,0 +1,334 @@
+Multimedia-chat-meeting-2018-02-15
+
+10:01 < pinchartl> Topic 1. Status Check for the Multimedia Tasks
+10:01 < pinchartl> * Jacopo
+10:01 < pinchartl> Since last meeting:
+10:01 < pinchartl> - GMSL code camp in Brussels
+10:01 < pinchartl> - Fought with buildroot to compile v4l-utils
+10:01 < pinchartl> In order to help Hans testing the v4l2-compliance tool on V4L2 subdevs, a 
+10:01 < pinchartl> procedure to easily cross-compile the latest v4l-utils is desired. Buildroot 
+10:01 < pinchartl> can be used for that purpose.
+10:01 < pinchartl> Until next meeting:
+10:01 < pinchartl> - Nothing planned, but would like to give M3-W + camera board a spin
+10:01 < pinchartl> - Help with GMSL upstreaming if required
+10:01 < pinchartl> - Help a bit more with reviews
+10:01 < pinchartl> Issues and Blockers: None
+10:02 < pinchartl> jmondi: any comment ?
+10:02 < jmondi> not particularly...
+10:02 < pinchartl> a quick question from my side
+10:02 < jmondi> shoot
+10:02 < pinchartl> last time you mentioned you where planning to handle frame rate setting in the ov7720 driver
+10:02 < pinchartl> what's the status ?
+10:03 < jmondi> it's there, in CEU v8 patch series
+10:03 < jmondi> isn't it?
+10:04 < morimoto> Marex: can you give us its patch ? We can try to send it to AFT team.
+10:04 < morimoto> s/AFT/ATF/
+10:04 < pinchartl> jmondi: thanks, just wanted to double-check
+10:04 < Marex> morimoto: sure, once I have it, I'll get back to you!
+10:04 < jmondi> pinchartl: uh, there are comments.. I guess that slipped from my mind because of FOSDEM code camp
+10:05 < pinchartl> do you plan to try and address them at some point ?
+10:05 < jmondi> pinchartl: ah ok, no comment that require rework...
+10:06 < jmondi> pinchartl: yes, I have to if I want that driver in v4.17
+10:06 < jmondi> and yes, there is some rework required :)
+10:07 < pinchartl> thank you
+10:07 < pinchartl> next, kbingham 
+10:07 < pinchartl> * Kieran
+10:07 < pinchartl> Since last meeting:
+10:07 < pinchartl> - GMSL Code Camp
+10:07 < pinchartl> This resulted in lots of refactoring on GMSL
+10:07 < pinchartl> - H3 ES2.0 LVDS + VGA Performance issue resolved
+10:07 < pinchartl> - Draak D3 i2c_new_secondary_device patches ongoing
+10:07 < pinchartl> - D3 VSP enablement series
+10:07 < pinchartl> Until next meeting:
+10:07 < pinchartl> - D3 DU enablement
+10:07 < pinchartl> Not an additional task itself, but doing as base work, because it's a pseudo-
+10:07 < pinchartl> dependency of the D3 ADV7511/ADV7604 'i2c_new_secondary_device' work.
+10:07 < pinchartl> - Wait for next contract, probably one of - Dynamic BRS/BRU allocation in display pipelines - DU interlaced modes support
+10:07 < pinchartl> Issues and Blockers:
+10:07 < pinchartl> - Need to get a patch tested on a Wheat board
+10:07 < pinchartl> This semi-blocks the changes made to the ADV7511 driver. Sergei@Cogent doesn't 
+10:07 < pinchartl> seem to have access to one.
+10:07 < pinchartl> any comment ?
+10:08 < kbingham> One comment
+10:08 < kbingham> For morimoto-san really - Just to highlight that there is a fix for the LVDS VGA, and I tried to find a mail thread where the issue was reported - but couldn't find one to highlight.
+10:09 < morimoto> sorry what does "highlight" mean ?
+10:10 < kbingham> morimoto: Make you aware of it :)
+10:10 < kbingham> Or perhaps rather the BSP team would be interested in the patch (trying to dig out the title now)
+10:11 < kbingham> "[PATCH] v4l: vsp1: Fix header display list status check in continuous mode"
+10:11 < kbingham> That's it from me otherwise I think.
+10:12 < kbingham> unless someone has a wheat board :)
+10:12  * morimoto maybe British English is a Little bit difficult for me...
+10:13 < morimoto> kbingham: Thank you for your help. I guess it will be send to Jinso in 2/E ?
+10:13 < kbingham> morimoto: Yes, that's right.
+10:13 < morimoto> Thanks. BSP team will be happy
+10:14 < pinchartl> next, Morimoto-san
+10:14 < pinchartl> * Morimoto-san
+10:14 < pinchartl> Since last meeting:
+10:14 < pinchartl> - ALSA SoC cleanup patches were (finally) applied in maintainer's tree !!
+10:14 < pinchartl> - R-Car sound has ADSP which needs FW
+10:14 < pinchartl> The BSP team has created a super original framework, driver, interface for 
+10:14 < pinchartl> userspace, and has released it to customers. We already know what will be 
+10:14 < pinchartl> happen with these kind of non-standard interface.
+10:14 < pinchartl> Started to confirm ADSP releated things to solve this issue.
+10:14 < pinchartl> - Shipped M3N board to EuroPeri, but not yet for Ideas on board guys
+10:14 < pinchartl> Until next meeting:
+10:14 < pinchartl> - ADSP investigation
+10:14 < pinchartl> - M3N board shipping for Ideas on Board
+10:14 < pinchartl> - Export paper work for V2H and others
+10:14 < pinchartl> Issues and Blockers: None
+10:14 < pinchartl> any comment ?
+10:15 < morimoto> nothing.
+10:15 < morimoto> shipping to Ideas is not yet finished
+10:15 < morimoto> because of paper work guy
+10:16 < morimoto> Ah, one comment.
+10:16 < morimoto> I have X)  from BSP team
+10:17 < pinchartl> yes I've seen that
+10:18 < pinchartl> we'll discuss it after the status update
+10:18 < pinchartl> next, neg 
+10:18 < pinchartl> * Niklas
+10:18 < pinchartl> Since last meeting:
+10:18 < pinchartl> - [PATCH v2] v4l2-dev.h: fix symbol collision in media_entity_to_video_device()
+10:18 < pinchartl> - [PATCH v2 0/5] arm64: dts: renesas: r8a77970: enable HDMI output
+10:18 < pinchartl> - [PATCH v13 0/2] rcar-csi2: add Renesas R-Car MIPI CSI-2
+10:18 < pinchartl> - [PATCH v10 00/30] rcar-vin: Add Gen3 with media controller
+10:18 < pinchartl> - [PATCH] v4l: subdev: compat: update handling for VIDIOC_SUBDEV_[GS]_ROUTING
+10:18 < pinchartl> - [PATCH v2] videodev2.h: add helper to validate colorspace
+10:18 < pinchartl> - Rebased GMSL branch on renesas-drivers-2018-02-13-v4.16-rc1
+10:18 < pinchartl> The result has been pushed to the common GMSL repo in git@github.com:kbingham/linux.git v4l/next/gmsl/renesas-drivers-2018-02-13-v4.16-rc1
+10:18 < pinchartl> - Got review comments from Laurent on VIN v10 \o/, started to address them.
+10:18 < pinchartl> - GMSL code camp + FOSDEM
+10:18 < pinchartl> Until next meeting:
+10:18 < pinchartl> - Finish VIN v11 and repost
+10:18 < pinchartl> - Start pro-active work on removing single capture mode from VIN
+10:18 < pinchartl> Issues and Blockers:
+10:18 < pinchartl> - Naming schema for GMSL branches not yet set
+10:18 < pinchartl> any comment ?
+10:19 < neg> None thanks
+10:19 < pinchartl> next, uli___ 
+10:19 < pinchartl> Issues and Blockers:
+10:19 < pinchartl> - Naming schema for GMSL branches not yet set
+10:19 < pinchartl> * Ulrich
+10:19 < pinchartl> Since last meeting:
+10:19 < pinchartl> - Multimedia meeting + FOSDEM
+10:19 < pinchartl> - Added VIN*, DU pin control tables to R8A779{5,6,95}
+10:19 < pinchartl> Until next meeting:
+10:19 < pinchartl> Issues and Blockers: None
+10:19 < pinchartl> any comment ?
+10:20 < uli___> nope
+10:20 < jmondi> I would be interested in the definition of topic branches naming scheme as well (not just for multimedia)
+10:20 < pinchartl> jmondi: agreed
+10:21 < pinchartl> uli___: we haven't had time to look at the SGX issues when we were in Belgium
+10:22 < pinchartl> I'm sorry about that
+10:22 < pinchartl> do you still plan to work on it ?
+10:22 < kbingham> uli___: Oh - have you also posted patches for r8a77995 DU / VIN?
+10:23 < uli___> pinchartl: not sure, actually. but i would appreciate it if you could look at the last patch, with the drm interface
+10:23 < uli___> kbingham: yes, pin control tables. not actually posted yet, i'll do that today
+10:23 < kbingham> uli___: I might have beaten you to it on parts :)
+10:23  * kbingham slaps kbingham for duplicating work 
+10:24 < pinchartl> uli___: what was the subject of the patch?
+10:24 < uli___> kbingham: yes, for the du part, it seems
+10:25 < kbingham> uli___: Orz ...
+10:26 < uli___> pinchartl: drm/img-rogue: replace call to obsolete drm_platform_init()
+10:27 < uli___> https://github.com/uli/r8a7796-gpu
+10:27 < pinchartl> thank you
+10:27 < pinchartl> next, me
+10:27 < pinchartl> * Laurent
+10:27 < pinchartl> Since last meeting:
+10:27 < pinchartl> - GMSL Code Camp
+10:27 < pinchartl> - Brussels FOSDEM
+10:27 < pinchartl> - Virtualization investigation
+10:27 < pinchartl> - DU LVDS support rework (V3M preparation + DRM bridge API)
+10:27 < pinchartl> - Patch review
+10:27 < pinchartl> Until next meeting:
+10:27 < pinchartl> - Get the GMSL patches posted to public mailing lists
+10:27 < pinchartl> - Dynamic BRS/BRU allocation in display pipelines
+10:27 < pinchartl> - DU interlaced modes support
+10:27 < pinchartl> Issues and blockers: None
+10:27 < pinchartl> no comment from my side
+10:29 < pinchartl> kbingham: I forgot to ask
+10:29 < pinchartl> about the Wheat board
+10:29 < pinchartl> what's your plan ?
+10:29 < pinchartl> if you really can't get access to one I think we can still send the patches upstream
+10:30 < kbingham> pinchartl: morimoto-san suggested that Magnus might be able to hook up a wheat board to the board farm.
+10:30 < pinchartl> let's see if that can happen during the next two weeks
+10:30 < kbingham> If that happens I'll have to build an arm32 kernel and FS and run i2cdectect myself.
+10:30 < pinchartl> otherwise, just go forward
+10:30 < kbingham> pinchartl: Ack.
+10:31 < pinchartl> next topic, additional tasks for Q1/2
+10:32 < pinchartl> the following tasks have been accepted by Renesas
+10:32 < pinchartl> - Dynamic BRS/BRU allocation in display pipelines (Kieran, Laurent) 
+10:32 < pinchartl> - DU interlaced modes support (Kieran, Laurent) 
+10:32 < pinchartl> - Port and Run igt on the DU (Ulrich)  
+10:32 < pinchartl> - V3M Eagle display support (Jacopo)
+10:32 < pinchartl> this one is still pending approval
+10:32 < pinchartl> - VIN Capture mode update (Niklas)
+10:33 < pinchartl> Renesas has accepted the task, but it's not clear whether it will be a prototype only or a full upstreaming task, it depends on budget
+10:33 < pinchartl> I will send the full task descriptions to Magnus when I'll be done with the Q1/1 report, so likely tomorrow
+10:34 < pinchartl> it will take a few days for the SoWs to be sent out
+10:34 < pinchartl> but in the meantime I believe it's safe to start working on those tasks
+10:34 < pinchartl> that's at least what I plan to do, but I'm not forcing anyone if you prefer waiting for a signed SoW
+10:35 < pinchartl> any question ?
+10:36 < morimoto> I have one
+10:37 < morimoto> Before BSP team asked that they want to use DU / VSPD separately
+10:37 < morimoto> Do you have such support plan ?
+10:37 < pinchartl> on Gen3 ?
+10:37 < morimoto> Yes
+10:38 < pinchartl> how do they want to do that ? the DU requires VSPD for proper operation
+10:38 < pinchartl> or does it mean they want to use the VSPD standalone when the corresponding DU channel is not needed ?
+10:38 < morimoto> "separately" means, DU can be separate. They want to use 1 for Linux 1 for VM
+10:38 < morimoto> for example
+10:38 < pinchartl> ah ok
+10:39 < pinchartl> I thought you meant using the DU and the VSPD separately from each other
+10:39 < pinchartl> so they want to make some of the DU pipelines available to guests ?
+10:39 < morimoto> Ah, sorry for my English
+10:39 < pinchartl> no worries :-)
+10:39 < morimoto> Yes
+10:39 < morimoto> I think we talked it before ?
+10:40 < morimoto> It is still our Todo list (In Renesas)
+10:40 < morimoto> BSP team already have local patch, so, not a big deal
+10:40 < pinchartl> I've worked on display virtualization in Q1/1, I'll send the report today
+10:40 < pinchartl> the approach I've tested was paravirtualization, not pass-through
+10:41 < pinchartl> we'll have to decide what is best
+10:41 < pinchartl> there are two issues
+10:41 < pinchartl> one is that on some SoCs (namely H3 ES2.0) a single VSPD instance handles two DU pipelines
+10:41 < pinchartl> so those two pipelines can't be used in separate VMs
+10:42 < pinchartl> LVDS for one guest and VGA for another guest won't be possible on H3 ES2.0 with pass-through
+10:42 < pinchartl> but LVDS + VGA for one guest and HDMI for another guest should work
+10:42 < morimoto> Yeah, some HW issue exist.
+10:43 < pinchartl> the second issue is that the DU groups channels by two
+10:43 < pinchartl> with shared resources
+10:43 < pinchartl> so we can assign a group of two channels to one guest and another group to another guest
+10:43 < pinchartl> but not split a group
+10:44 < pinchartl> and unfortunately, on H3 ES2.0, the VSPD instance shared by two channels is split between two groups
+10:44 < pinchartl> that's why I think a paravirtualized approach might be better
+10:44 < pinchartl> but lots of work is still needed to prototype all that and see what we can do
+10:44 < pinchartl> it's really long-term work
+10:45 < pinchartl> especially if we want to make it upstream
+10:45 < pinchartl> given the time we currently allocate to virtualization work, I wouldn't expect any upstream solution before the end of the year
+10:46 < morimoto> OK, we knew some HW limitation exist, and we think we need to consider this kind of limition somehow
+10:46 < pinchartl> yes
+10:46 < morimoto> Actually, HW team didn't care about virtualization when they created chip
+10:46 < pinchartl> that's interesting to know
+10:47 < pinchartl> and now someone cares about virtualization ? :-)
+10:47 < morimoto> That is the reason why it has such design
+10:47 < morimoto> SW team start to consider virtualization, HW team didn't care
+10:48 < pinchartl> does the software team have use cases that they can share for virtualization ?
+10:48 < morimoto> The reason why it has not enough channel/IP/connection is HW team want to reduce cost
+10:48 < pinchartl> I hope someone will tell the hardware team it wasn't the best idea
+10:48 < morimoto> Just cost issue, no plan for virtualization
+10:49 < pinchartl> there are a few things I consider as design mistakes in the DU
+10:49 < morimoto> Yes, Now they noticed (I hope)
+10:49 < pinchartl> I would really like to see them fixed at some point
+10:49 < morimoto> I guess Gen4 timing
+10:50 < morimoto> I think Renesas SW team will have discussion time with HW team then
+10:50 < pinchartl> could the HW team listen to our feedback ?
+10:50 < morimoto> Gen3 was better than Gen2. becaming better, but not yet perfect
+10:51 < morimoto> That is the request from Renesas CEO
+10:51 < morimoto> But, HW team have their reason. Thus, not 100%
+10:52 < pinchartl> I wonder whether it could be useful to meet face to face before OSSJ to discuss Gen4 DU with the hardware team
+10:53 < morimoto> Uhm, I don't know we can do it.
+10:53 < morimoto> But let's try to ask
+10:53 < pinchartl> thank you :-)
+10:53 < morimoto> Thank you. it is all from me
+10:54 < pinchartl> this leads us to Topic 3. BSP Team Requests that we have already started
+10:54 < pinchartl> the other question being the memory leak in libdrm drmClose()
+10:55 < pinchartl> I haven't reviewed libdrm from a memory management point of view
+10:55 < pinchartl> this is a userspace issue, so I wonder what we're expected to do ?
+10:59 < morimoto> I guess BSP team is thinking that you have some "userspace" friend ?
+10:59 < morimoto> or report it to userspace ML
+10:59 < pinchartl> I'm sure they could reach out to the libdrm developers directly if they wanted :-)
+10:59 < morimoto> It sound good
+11:02 < pinchartl> next topic
+11:02 < pinchartl> Topic 4. FOSDEM Meeting Debriefing
+11:02 < pinchartl> what went well, what can we do better ?
+11:02 < pinchartl> I'll start
+11:02 < pinchartl> I think the code camp was a success
+11:03 < pinchartl> we've made good progress on GMSL
+11:03 < pinchartl> but 3 days and a half was a bit short to wrap it up
+11:03 < kbingham> I was impressed by our multi-developer instant review "Extreme Programming" rework cycle. I think we made massive progress in a short space of time.
+11:04 < pinchartl> I agree
+11:04 < jmondi> the code camp was a success imo!
+11:04 < pinchartl> we should organize more code camps in the future
+11:05 < pinchartl> 3 days is a minimum, up to 5 days could be nice
+11:05 < jmondi> if we cannot meet per-quarter at conferences, we may want to organize camps like this one, if need be
+11:05 < neg> yes, and I reallly think the shared appartment helpd, and the ease to travell to/from the destination
+11:06 < jmondi> next time a room where to sleep instead of a corridor would be nice :p
+11:06 < kbingham> neg: Perhaps we'll have our own rooms next time though :)
+11:07 < neg> kbingham: well it was an improvment in space since the last code camp in .be, but it did not have a pig :-(
+11:07 < pinchartl> :-)
+11:07  * kbingham suspects neg will wake up with a pig in his bed next code camp ...
+11:07 < jmondi> next time a want a corridor, and a pig
+11:08 < pinchartl> I think we were also lacking proper planning tools when we discussed planning for Q2. a white board or flip chart would have been useful, but also an established methodology
+11:08  * morimoto I can be pig for you :)
+11:08 < jmondi> ok, I'll leave the pig to neg... I do not even eat it, it would be a waste
+11:08 < jmondi> personally, the planning poker card has been really helpful to reason on task commitment
+11:09 < neg> I also liked the early start in the days and that take-out food was had some nights to prolong the hacking sessions
+11:11 < neg> Things to improve I think is that ad-hoc decisions taken during the week to prior to the MM meeting where not documented
+11:11 -!- pinchartl_ [~unknown@81-175-216-236.bb.dnainternet.fi] has joined #periperi
+11:12 < jmondi> neg: didn't get this
+11:12 < pinchartl_> my hosted server stopped replying :-/
+11:12 < neg> jmondi: thing I think we should improve or take-out food?
+11:12 < pinchartl_> the last thing I saw was
+11:12 < pinchartl_> 11:08 < jmondi> personally, the planning poker card has been really helpful to reason on task commitment
+11:12 < pinchartl_> what have I missed ?
+11:13 < jmondi> pinchartl_: need logs?
+11:13 < pinchartl_> please
+11:13 < jmondi> pinchartl_: https://paste.debian.net/hidden/0e0035b0/
+11:14 < jmondi> you didn't miss much though
+11:14 < pinchartl_> thank you
+11:15 < pinchartl_> neg: what did you mean ?
+11:15 < pinchartl_> by "Things to improve I think is that ad-hoc decisions taken
+11:15 < pinchartl_> during the week to prior to the MM meeting where not documented"
+11:16 < neg> For example we talked about the GMSL branch names ad-hoc and that was not documented and now we are confused :-)
+11:16 < pinchartl_> (I think my server is being DOSed)
+11:16 < pinchartl_> yes, I agree
+11:17 < pinchartl_> maybe we should create a wiki page for the next code camp
+11:17 < pinchartl_> and take notes whenever needed in a collaborative way
+11:17 < pinchartl_> or an etherpad
+11:18 < jmondi> neg: other non documented points you are thinking about?
+11:18 < jmondi> because I cannot even remember the naming scheme thing :p
+11:18 < kbingham> I think that may have just been an informal ish discussion between me and neg :D
+11:18 < neg> Also we did not execute the plan to do a team event which was OK but I think it would have been good for the team. *real issue: brought my swimsuite and we did not go diving :-)*
+11:19 < pinchartl_> :-)
+11:19 < pinchartl_> I agree too
+11:19 < pinchartl_> I think we did better than in San Sebastian
+11:19 < pinchartl_> but still not good enough
+11:19 < pinchartl_> from a social events point of view
+11:20 < neg> jmondi: none that come to mind regarding un-documented stuff, but I was not part of all discussions nor do I remember all of them I took part in
+11:20 < pinchartl_> several ideas for a social event were discussed before the meeting but we haven't officially agreed on anything, so nothing happened
+11:21 < jmondi> we would had been short on time probably for social events...
+11:21 < pinchartl_> next time I think we need to decide beforehand on what we want to do
+11:21 < pinchartl_> yes, that too, but we will always be short of time anyway :-)
+11:21 < neg> Yes, I too think if we are to make an event happen we should pre-allocate time for it
+11:22 < jmondi> my understanding is that we're not meeting in Q2/Q3, right?
+11:22 < jmondi> at least, not with Renesas sponsorship...
+11:22 < pinchartl_> we should definitely meet
+11:23 < pinchartl_> I assume there will be a meeting similar to San Sebastian around September
+11:23 < pinchartl_> hopefully in Italy :-)
+11:23 < pinchartl_> and I think another code camp at some point over the summer would be useful
+11:24 < jmondi> pinchartl_: yeah, I meant before september, sorry..
+11:27 < pinchartl_> that's it for me
+11:27 < pinchartl_> any other topic to discuss ?
+11:27 < jmondi> I would like to ask you guys if I'm the only one that had to spend a day to cross-compile v4l-utils
+11:28 < kbingham> jmondi: Normally I can just type 'make v4l2-utils' on my build - but the build does seem to have broken at the moment ...
+11:29 < jmondi> it has a -ton- of dependencies, doesn't live well will musl or ulibc.. I remember buildroot shipped versions worked fine, with last version is a bit of pain... is it me?
+11:29 < jmondi> kbingham: that's buildroot?
+11:29 < neg> jmondi: I build it as a Arch packege on target and then install that in my NFS root for each board, if it helps :-)
+11:29 < kbingham> So I'd say this is the life with cross compiling
+11:29 < pinchartl_> I cross-compile it outside of buildroot without any issue
+11:29 < kbingham> jmondi: (No that's my own custom outside-of-buildroot)
+11:29 < kbingham> All it does is git clone the latest v4l2-utils, and attempt to configure and build inside my working environment.
+11:30 < jmondi> neg: cross compile as arch package? that's nice
+11:31 < jmondi> ok, I assume it is me then, I had to add a ton of packages to buildroot produced compiler sysroot to satisfy dependencies...
+11:31 < neg> jmondi: not cross compile, Arch build system don't support that so I have to build the package on target (or in arm/arm64 VM but I don't have that)
+11:31 < neg> jmondi: also "sed -i '/#define HAVE_QTGL 1/d' config.h" helps :-)
+11:32 < jmondi> neg: oh, you're building on target! that's nasty :)
+11:33  * kbingham adds a cross-docker environment which uses qemu-system-arm to provide a 'lightweight ARM64 VM' on host.
+11:33 < kbingham> to his wish list
+11:33 < jmondi> ok, that's all from me, just wanted to make sure I was not doing something super stupid...
+11:34 < kbingham> Ok - back to report writing it is then :)
+11:34 < jmondi> (/me wonders how pinchartl_ can build with the single line ./configure string he shared)
+11:39 < pinchartl_> are we done for today ?
+11:40 < neg> I have nothing more
+11:42 < pinchartl_> then we're done
+11:42 < pinchartl_> thank you for attending