path: root/wiki/Chat_log/20180215-mm-chatlog

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