From 55e3b2f45880faaf06f3c660ca9e8a6d9aa14bce Mon Sep 17 00:00:00 2001 From: Kuninori Morimoto Date: Mon, 9 Dec 2019 15:29:52 +0900 Subject: wiki: Porting wiki: Porting Chat Log Signed-off-by: Kuninori Morimoto --- wiki/Chat_log/20180215-mm-chatlog | 334 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 334 insertions(+) create mode 100644 wiki/Chat_log/20180215-mm-chatlog (limited to 'wiki/Chat_log/20180215-mm-chatlog') 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 -- cgit v1.2.3