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/20160525-mm-chatlog | 478 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 478 insertions(+) create mode 100644 wiki/Chat_log/20160525-mm-chatlog (limited to 'wiki/Chat_log/20160525-mm-chatlog') diff --git a/wiki/Chat_log/20160525-mm-chatlog b/wiki/Chat_log/20160525-mm-chatlog new file mode 100644 index 0000000..f0e3cd3 --- /dev/null +++ b/wiki/Chat_log/20160525-mm-chatlog @@ -0,0 +1,478 @@ +Multimedia-chat-meeting-2016-05-25 + + hello Morimoto-san + Hi + sorry for my late + we've just started + no worries, you're excused + I've posted the topics for the day + Topic 1. Status check for the multimedia tasks + Topic 2. Additional '50%' tasks + Topic 3. New upstream DRM/KMS rules + Topic 4. Next meeting + would anyone like to add another topic ? [17:02] + I added Renesas request to peripelist + hi guys, sorry about the delay + (it was already requested by email to each member, but not listed) + in multimedia/request ? [17:03] + Yes + (kbingham: for your information, the lists of pending and + requested tasks are maintained in text format in a git tree called + peripelist) [17:04] + pinchartl: I see :) + I have a question about that, let's add it as a topic [17:05] + Topic 4. Renesas requests + thanks [17:06] + let's get started with the status, and let's try to keep it short + :) + in alphabetical order [17:07] + FDP,v4.8,plan,laurent,Develop and upstream driver + (which is handled by Kieran, otherwise I wouldn't be first in + alphabetical order) + kbingham: what's the status ? [17:08] + FDP1: M2M driver can handle frames, and support MPLANE/MPIX + api. Now working with getting the hardware to do + 'something'. IPBlock is powered up, (using RuntimePM) and + interrupts are firing. Not currently getting 'successful' FrameEnd + status yet though. + Switched to using OPMODE_INTERRUPT with a VPERIOD setting, and that + fires regular VSyncs + do you have ideas regarding what to explore or are you getting + blocked ? [17:09] + Starting to feel blocked. I've gone through most of the register + settings, and the programming sequence and I'm running out of + ideas. My next plan is to try moving away from Progressive mode and + try de-int mode to see if there is a difference there but I fear + that is complicating things rather than simplifying. The only other + thing I have thought needs checking is the FCP [17:10] + have you linked the FDP to the FCP in DT ? [17:11] + No! [17:12] + That sounds like a step I've missed :) + and do you call rcar_fcp_enable() and rcar_fcp_disabled() in your + driver ? + Ok - I'm unblocked :) + at least temporarily :-) + the FCP driver isn't upstream yet + you need to get it from my git tree at + git://linuxtv.org/pinchartl/media.git [17:13] + I do have a pending action to confirm the CPG clock parents + though. morimoto - are you able to look into that for me? + branches drm/next/dt and vsp1/next + pinchartl: Ok - thanks. I'll get on that next. + kbingham: can you send question email to me or periperil ML ? + [17:14] + kbingham: I can send it to HW / datasheet guys + morimoto: Sure. I'll send a dedicated mail. thanks :) + kbingham: np + next, Magnus [17:15] + VIN,?,plan,magnus,IPMMU integration on Gen2 + VIN,?,plan,magnus,IPMMU integration on Gen3 + VIN,?,plan,magnus,IPMMU support on Gen2 + VIN,?,plan,magnus,IPMMU support on Gen3 + no progress on that I assume ? + nothing done yet, but i intend to try Gen3 early next month + with VIN in mean + but not with the IPMMU, right ? [17:16] + s/in/i/g + test with the IPMMU + just to figure out what is needed + so we're not blocked by the IPMMU hardware bug anymore ? + kbingham: for your information: I asked to BSP team about FDP + sample code / test code now. I'm not sure it exists or not. please + wait :) + it is probably flakey on H3 + but worth looking into to see what our limitations are [17:17] + M3 may work better + morimoto: Thanks. Will be useful reference if it exists. + same situation as DU + morimoto: thank you ! + morimoto: there's a 'fdpm-driver.tar.bz2' archive mentioned in the + yocto recipes, but that file is nowhere to be found [17:18] + so I assume code exists + dammsan: thanks + np + next, morimoto + RSND,2016-06-30,plan,morimoto,DT bindings for HDMI sound + RSND,2016-06-30,plan,morimoto,dw-hdmi-ahb-audio prototype on Gen3 + RSND,2016-06-30,plan,morimoto,HDMI SSI prototype on Gen3 + RSND,2016-06-30,plan,morimoto,HDMI sound Upstream support without + hotplug on Gen2 + RSND,2016-09-30,plan,morimoto,Hotplug support upstream on Gen3 + graph base HDMI sound needs hack. [17:19] + I posted its 1st step patches to ALSA and Renesas ML + It is under reviewing now + And now, I'm hacking of prototype of graph base sound card + not yet finished. + over [17:20] + (and i bothered morimoto-san by asking about HDMI-in audio-input) + as you've posted patches, which of the tasks should now be + 'public' [17:21] + I'm bothering it, yes + well... + RSND,2016-06-30,plan,morimoto,DT bindings for HDMI sound + but, 30% for it + 30% of it [17:22] + I wonder how to report the 30% in the tasks list :-) + should I leave it as 'plan' for now until we reach 50% ? [17:23] + can you separate it into more small tasks ? + split ? separate ? + sure [17:24] + how would you like me to split it ? + 1. clean up simle-card [17:25] + 2. create simple-card core + 3. share simple-card core with DPCM + 4. share simple-card core with graph + 5. use graph simple-card on ASoC + 6. use graph simple-card on Gen2 + 7. use graph simple-card on Gen3 + + Maybe these are enough + 1, 2, 3 are posted + I mean public + that's very fine-grained. do we really need to go to that level of + details in the tasks list, or can I just list that in the meeting + report ? [17:27] + OK, please wait + I will clean up again + thanks [17:28] + I'll include that in the report anyway + I'll move on to Niklas' tasks in the meantime + ADV7482,v4.7,plan,niklas,Prototype on Gen3 + ADV7482,v4.9,plan,niklas,Gen3 support upstream + ADV7482,v4.9,plan,niklas,Interlace support upstream + VIN,v4.7,plan,niklas,CSI2 prototype (Gen3) [17:29] + VIN,v4.8,plan,niklas,Gen3 support + VIN,v4.8,plan,niklas,Scaler support (on Gen3) + VIN,v4.8,public,niklas,New VIN driver without soc-camera (tested + on Gen2) + VIN,v4.9,plan,niklas,CSI2 interlace support upstream (Gen3) + VIN,v4.9,plan,niklas,CSI2 support upstream (Gen3) + VIN,v4.9,plan,niklas,Gen3 support upstream (without CSI-2) + I will post the Gen3 VIN patches today + including CSI ? [17:30] + yes it will include the CSI2 and ADV7482 prototypes from BSP with some + small fixes ontop + so that covers + - ADV7482,v4.7,plan,niklas,Prototype on Gen3 + - VIN,v4.7,plan,niklas,CSI2 prototype (Gen3) + - VIN,v4.8,plan,niklas,Gen3 support [17:31] + right ? + yes, but I will not include the CSI2 and ADV in the patch sereis but + make them avaliable in a topic branch for testing + so I don't think they should be marked public + for prototype patches that's fine, and I think it's enough to + consider them as public [17:32] + OK + are the Gen3 support patches in a good enough shape to be reviewed + ? + or are they prototype code ? + yes I hope they are ready for review, they use s_input for input + selection which we might not want to commit to. But I think it worked + out OK [17:33] + ok, thanks + pinchartl: hmm.. then, current task list is enough ;) [17:34] + pinchartl: can you set "DT bindings for HDMI sound" as "public" ? + + morimoto: sure + kbingham: we got FDP sample code from BSP team. I will send it to + you + morimoto: great ! + morimoto: Thanks! + neg: no progress on the other tasks I assume [17:35] + at lest you can grab frame from both HDMI and CVBS sources on both Gen2 + and Gen3 + pinchartl: yes no progress on the rest + ok + are we still on track with the targets ? [17:36] + - VIN,v4.8,plan,niklas,Scaler support (on Gen3) + - VIN,v4.8,public,niklas,New VIN driver without soc-camera (tested + on Gen2) + and the rest is for v4.9 + I think we are + yes I think so + so do I, good :-) + next, uli___ [17:37] + DU,v4.7,plan,ulrich,Atomic API test program + DU,v4.7,public,ulrich,HDMI output on Gen3 prototype + DU,v4.7,prototype,ulrich,Test setup with HDMI output to HDMI input + loopback (without EDID) + DU,v4.7,public,ulrich,EDID generation support for the HDMI + loopback test setup + DU,v4.8,plan,ulrich,HDMI output on Gen3 upstream + VIN,v4.8,public,ulrich,Add DV timings support to rcar-vin + api test is in progress right now + hdmi output i will brush up and make public as an rfc before the end + of the month [17:38] + gen3 i mean + dv for r-car vin is at v4 now + hans's complaints are limited to the fixed edid blob + gotta implement s_edid/g_edid instead + that's about it for now [17:39] + uli___: Is renesas-driver including your latest HDMI out code ? I + still have HDMI1_OUT issue on latest renesas-driver + there is a topic branch, iirc [17:40] + OK + as the HDMI out prototype is an additional task please make sure + with Geert that the topic branch is merged in the renesas-drivers + tree + topic/salvator-x-hdmi-prototype-v2 + thanks [17:41] + thanks, + I'll keep HDMI loopback targetted at v4.7 as it's due for end of + June [17:42] + yes + I don't think 'DU,v4.8,plan,ulrich,HDMI output on Gen3 upstream' + will make it to v4.8 [17:43] + probably not + I'll push it back to v4.9 + next, me [17:44] + (what happened to the alphabetical order, anyway?) + scnr + good question :-) + DU,?,plan,laurent,IPMMU integration on Gen3 [17:45] + DU,?,plan,laurent,IPMMU support on Gen3 (through VSPD+FCP) + no progress + DU,v4.8,public,laurent,VSPD Z-order support upstream (Gen3) + still public :-) [17:46] + the patches missed the v4.7 merge window, they will make it to + v4.8 [17:47] + VSP,?,plan,laurent,Fixed alpha support (VI6_DPR_*_ROUTE.FXA) + VSP,?,plan,laurent,CLU WARN_ON fix + VSP,?,plan,laurent,CLU 2D and 3D mode support + VSP,?,plan,laurent,CLU/LUT test application + VSP,?,plan,laurent,CLU/LUT upstream API + no progress + CLU support is an additional task for June [17:48] + I'll mark it for v4.8 + VSP,?,plan,laurent,UDS regression fix [17:49] + no progrss + I plan to have a look at it in June, v4.8 as well + VSP,v4.8,plan,laurent,Fix suspend/resume crash [17:50] + no progress + VSP,v4.8,public,laurent,CLU/LUT support submitted upstream on Gen3 + no progress either, still on track for v4.8 with the rest of the + CLU tasks [17:51] + VSP,v4.8,p,laurent,HGO operation mode selection + VSP,v4.8,plan,laurent,HGO support upstream on Gen3 + VSP,v4.8,plan,laurent,HGO test application + patches are now public + on track for v4.8 + testing doesn't require a new test application [17:52] + patches to yavta test tool have been pushed to the repository in a + topic branch until the API changes get accepted upstream + and test scripts have been pushed to a new project [17:53] + git://git.ideasonboard.com/renesas/vsp-tests.git + this is an initial attempt at creating unit tests for the vsp + driver + if anyone is interested I can elaborate on that [17:55] + i would be... + ok, let's address that as a separate topic + VSP,v4.8,public,laurent,V4L2 request API usable prototype [17:56] + VSP,?,prototype,laurent,V4L2 request API upstream + progress :-) + but not posted yet, I will for the end of the month, which means + the end of the week + that's it for the tasks + Topic 2. Additional '50%' tasks + has everybody received their additional tasks for June ? [17:57] + ('everybody' being Niklas and Ulrich) + you have sent something to magnus, not sure what became of that :) + [17:58] + yes I got task descriptions from Magnus today + dammsan: what's the status ? [17:59] + anything needed on our side, or is everything in the pipeline ? + while waiting for Magnus to reply + is everybody on track with their additional tasks for May ? + [18:00] + (dammsan is talking to Renesas guy now, please wait) + the report needs to be a bit more detailed than what we are used + to + and should really not miss the deadline + neg: uli___: are you all good ? + i am [18:01] + yes, I'm fine + great + I am as well + pinchartl: need to finalize one bit with wolfram to cover uli___ + Only outstading issue I have is to ping geert for a topic branch in + renesas-drivers but I think that is OK to contain prototype code right? + [18:02] + but i hope to do so today or tomorrow + to have final review on friday + neg: it is, yes. if you push your patches to a git tree and send a + pull request to Geert for renesas-drivers that's enough for the + report + dammsan: thanks + pinchartl: great thanks + Topic 3. New upstream DRM/KMS rules [18:04] + this one is a rather bad one + DRM/KMS has long required GPU kernel drivers to have an + open-source userspace implementation in order to get merged + that's at least how the rule was communicated interpreted [18:05] + they're now changing, if not their base rule, at least how they + apply it + and require open-source userspace upstream code for any new kernel + API + including driver-specific properties + z-order and alpha support got accepted right before they decided + to enforce that rule [18:06] +*** horms (~horms@reginn.isobedori.kobe.vergenet.net) has quit: Quit: Leaving + but from now on, an implementation in Android hardware composer, + wayland or X11 will be required for any API extension + this is a major issue for us + as our team works on the kernel side only [18:07] + not only don't we have the bandwidth to cover the userspace side + but userspace is the responsibility of other teams within Renesas, + and we can't claim ownership of those areas + the new rule will be announced shortly [18:08] + there will likely be a grace period + but we'll have to adjust + I've learnt about that yesterday and don't have a plan yet + any comment ? + so does the userspace part only have to exist somewhere, or does it + really have to be upstream? [18:09] + it has to be acked by upstream developers + not merged obviously, as it can't be merged before the kernel API + is available [18:10] + does z-order and alpha support will be updated ? + they will be merged in v4.8 as they have been accepted right + before the change of rule [18:11] + but if they hadn't been + we would have had to submit patches to android hwcomposer, weston + or X11 to use Z-order and alpha + so this might mean we'll have to collaborate with the Renesas + upstream developers [18:14] + s/upstream/userspace/ + I'll bring that topic up during the meeting in Japan + any suggestion regarding what to do in the meantime will be + welcome [18:15] + while this sinks in + Topic 4. Renesas requests + Morimoto-san, you've updated multimedia/request [18:16] + how are we supposed to handle that list ? + is it just there to keep track of the request, and let us propose + additional tasks (or handle them as part of the base contract), or + do we need to be more proactive ? [18:17] + It is not a big deal, just for my / Renesas information + I sometimes requests something, and clean forgot :) [18:18] + ok, so no action required from me, apart from looking at it and + using it as a source of inspiration to propose tasks ? + I would like to track what is requested, and current status + something like that [18:19] + thanks [18:20] + Topic 5. VSP unit tests + as I mentioned earlier, we now have a vsp unit tests framework + it's implemented as a set of shell scripts using the yavta and + media-ctl test tools + as well as the compare utility from ImageMagick [18:21] + on the host side python is also needed to generate test data + there are 8 tests so far, and they already allowed me to catch two + bugs in the vsp driver, for which I've submitted patches + I plan to add more test script in the future + and will also need to work on creating a new test tool to generate + test data (both input reference frames and excepted output frames + for comparison) at runtime instead of build time [18:22] + as there's already 230MB of test frames, and that won't scale + new test scripts will be added as I develop driver features + and I'll propose an additional task for work on the test framework + core, as that will need quite a bit of time [18:23] + I encourage you all to start thinking about unit test scripts for + the driver(s) you work on + pinchartl: I'd been looking at gstreamer as a potential for testing + my M2M driver - as the Videotestsrc element will enable me to + create many types of frames consistently - dynamically. + feel free to use vsp-tests as a base and provide feedback + for the FDP I think that's an option [18:24] + it would depend on gstreamer obviously, but that shouldn't be a + too big deal + on the other hand [18:25] + gstreamer will only exercise the API as it's meant to be used + if you want to unit-test the error paths then you'll need + something at a lower level + yes. that's true. + but you can have diffrent unit test scripts that use different + tools [18:26] + I'm fine with gstreamer, but if you realize that you could perform + the exact same tests easily with less dependencies, then I'd + prefer avoiding gstreamer + if it brings added value, then no worries + Ok - I'll bear that in mind :) [18:27] + regarding the test scripts themselves, we should standardize on + naming, output and other technical details to make sure they could + all be run from a single test runner, and generate a coherent + report + I haven't given that much thoughts yet on my side + if you start writing unit test scripts please get in touch with me + to discuss those points [18:28] + that's all I have on this topic [18:29] + Topic 5. Next meeting + I propose Wednesday in two weeks (8th of June), same time as today + Ok for me. [18:30] + me too + OK for me + OK for me too + dammsan: ? + (Mr Magnus is still taling to Renesas guy) + ok :-) + I assume he will voice his concerns over e-mail if there's any + issue + we're done with the agenda, any last remark or question ? [18:31] + pinchartl: thank you for your new topic for RenesasCon + you're welcome + it's two new topics actually [18:32] + I plan to talk about the test framework too + in addition to the DRM/KMS rule change + but regarding the test framework + we should discuss it internally first before adding the topic to + the RenesasCon agenda + we can talk about it during the next multimedia meeting, I will + hopefully have a bit more information by then [18:33] + and others will hopefully have time to give it a look too :-) + I propose adjourning for today. does everybody second ? [18:34] + Seconded :) + thank you for joining everybody [18:35] + have a nice day + cu + thanks all [18:36] + Thanks :) + pinchartl: it seems we need Kurokawa-san to next meeting ? + for DRM/KMS topis [18:37] + topis/topics + morimoto: that could be useful + OK + thanks + I'd like to think about it for a couple of days and then discuss + it with you and Magnus + OK. by chat ? [18:38] + or e-mail [18:40] + both are fine with me + I'll likely chat with Magnus about this when he won't be busy with + "the Renesas guy" :-) [18:41] + OK :) + I can ask it to him, after kicking Renesas guy :) [18:42] + kbingham: can I ask you ? + kbingham: are you still there ? + morimoto: I'm here :) + thanks. does your question about FDP parent clock [18:43] + morimoto: How can I help ? + does it just parent clock for CPG ? + or do you have some issue on it ? [18:44] + morimoto: Thats correct. + OK, so you have no big issue now + morimoto: I don't think there is an issue currently. I can read and + write to the registers - so I assume we have it right, but I don't + have a datasheet clock diagram to confirm it is correct (and not + that I'm just lucky and something else has actually turned the + clock on for me) + morimoto: it's the usual "what is the correct parent for the MSTP + clock" question. the FDP doesn't care about the clock rate so it's + no big deal, it's just about correctness [18:45] + (I'll be back in 20 minutes) + Yeah, same here. + According to HW / datasheet guys, they decided to indicate it in + block diagram [18:46] + but, not yet completed + OK, thanks. I asked it to HW / datasheet guys. please wait [18:47] + morimoto: Ok - so just waiting on them finishing the document. + Thanks + morimoto: Thankyou :) -- cgit v1.2.3