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/20170510-mm-chatlog | 499 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 499 insertions(+) create mode 100644 wiki/Chat_log/20170510-mm-chatlog (limited to 'wiki/Chat_log/20170510-mm-chatlog') diff --git a/wiki/Chat_log/20170510-mm-chatlog b/wiki/Chat_log/20170510-mm-chatlog new file mode 100644 index 0000000..42ab2d7 --- /dev/null +++ b/wiki/Chat_log/20170510-mm-chatlog @@ -0,0 +1,499 @@ +Multimedia-chat-meeting-2017-05-10 + + pinchartl: if you could distill some additional task candidates that + would be great [15:59] + but it does not have to happen right now + that's topic 2 isn't it ? :-) + good point =) + nice that someone is awake at least [16:00] + :-D + let's get started then + Topic 1. Status check for the multimedia tasks + jmondi: as you're the last one to have posted your status update, + you can start [16:01] + that's fair + (not sure whether that will be a good enough incentive to get the + reports earlier in the future, let's see) + at least I can still go from the top of my head + A) + - Sent v3 of CEU driver [16:02] + - Working on Migo-R remote board to have CEU probe at least + - trying to build a local test platform with RZ devices + B) + - I expect a lot of review comments on CEU driver + - Have CEU probe on Migo-R [16:03] + - Have a test platform where I can at least run mainline and test the + driver + C = D = None + -- eot -- + thank you [16:04] + speaking of review comments + I'd like the rest of the team to feel free to cross-review patches + I certainly want to review them myself too + but there's no reason for me to be the only reviewer + I agree, I will try to do more reviews in MM [16:05] + neg: thank you + question: Geert seems to have sent a patch to fix the sh7722 PFC + issue, who can test and reply to him? + Also agree here! - I've started with some of Negs ' :) - but that + was easy becasuse I was looking at his patches directly. + [16:06] + dammsan: I will + great thanks + dammsan: I believe that Geert has tested the patches, but it's of + course nice to double-check + jmondi: thank you + I already planned to do so yesterday, but I failed to do so + nice with a tested-by tag + uli___: as you're second last to have posted your status update, + you're next :-) [16:07] + fair enough :) + so i did a little stub driver for the max9260 using serdev + seems pretty straightforward + but it took me a while to figure out that the max9260 always talks + uart on the controlling side [16:08] + even though it is capable of both i2c and uart on the same pins + anyway, i got my hands on two chips, and i'll wire them up to the + salvator-x board + and see that i can get it to talk + i have vays... [16:09] + scnr + nice project + just out of curiosity, what's the MAX9260 package ? + tqfp + at least mine is + 0.65mm or 0.80mm ? + .65 + that's on the verge of becoming painful [16:10] + uli___: any reason for not using remote access? + if it is not working let me know [16:11] + nothing wrong with it, i just dislike remote access. + uli___: Do you mean that the max9260 only can be controlled using uart + in your setup or at all? Is it still capable of beeing controlled over + i2c if the hw around it where different? + dammsan: i'll try it eventually, of course, but i'd like to have + something to yell at first [16:12] + ok ok + neg: on the local side (the one that sends the commands), it is + always uart + but the link can be configured in both ways, and the other way + around, it can talk either uart or i2c + uli___: are you (or do you plan to) use the serdev API ? [16:13] + i do + uli___: ahh I see, thanks for the clearification :-) + and then i intend to look at the gose vin dt thing [16:15] + that's it for now + thank you + next in report order, Morimoto-san [16:16] + OK + A) What have I done since last time + - Finally Sound OF-graph DT which is needed for HDMI sound was + accepted, but not yet applied, because of merge-window. + - BSP team want to use AGL, and has issue on sound. I had worked + with them. it seems AGL is using SMACK security, and it seems be + reason of sound noise. + - BSP team noticed 24bit sound data noise (not for AGL), and I'm + helping for debugging. It seems related to HW issue, but not sure + yet. + - BSP team want to use ADSP on ALSA. We will have meeting with them + tomorrow. + B) What I plan to do till next time + - Wait OF-graph DT applying. Then, post HDMI sound patch-set + - post stalled patches (because of OF-graph) to ML + - Help BSP team + C) Problems I have currently + D) Posted/Accepted bugfix patch + No, sir + --EOT-- + thank you + looks like the BSP team always needs your help [16:17] + you're becoming their super hero :-) + pinchartl: Unfortunately + you have in your status report e-mail enquired about multiple work + items, let's go through them [16:18] + * Fence for VSP + this is not in my base task, as I have (at least temporarily) + retired from V4L2 upstream development due to conflicts with the + V4L2 maintainer + however + while I don't want to jinx it by making early announcements + [16:19] + I hope to get confirmation at the end of the week that things will + get moving forward in V4L2 + with a setup of co-maintainers proposed to Mauro + please keep this information to yourselves for now [16:20] + Mauro isn't aware of it yet + if it works out well, I will be able to go back to working on + upstream MC and V4L2 APIs + :-) (wish I could show a bigger smile over irc) [16:21] + :-) + I don't expect things to be easy though, but there might be hope + I don't understand detail of your V4L2 problem, but I hope + everything goes to happy direction + morimoto: in a nutshell, the conflict between the V4L2 maintainer + and me got so bad that I had to stop working on upstream V4L2 + [16:22] + because I had to stop interact with him at all + him = Mauro ? + yes + OK, so, this means Fence will be delay [16:23] + ? + in the best case, delayed. in the worst case, if we don't succeed + moving forward on V4L2, it could be delayed undefinitely + [16:24] + at least for upstream + s/undefinitely/infinitely/ + fences support in V4L2 requires API extensions [16:25] + and at this time I can't propose new API extensions + because the maintainer rejects all my proposals + Wow !! very serious ! + yes :-) [16:26] + it's been going on for too long + so I've spent the last month or so to try and find a solution by + discussing the problem with many other V4L2 developers + if all goes well we will propose something in the next few weeks + [16:27] + OK, nice to know + I'm sorry for the delay and inconvenience all this is causing, but + there was no other option [16:28] + * DU Fence is missing about asynchronous + I saw the e-mail you sent a few days ago, I'll investigate and + reply to it soon + Thank you + * Cache (DMA ATTR SKIP CPU) problem [16:29] + it's on my to-do list for the next two weeks + I'll rebase the code + Thanks + may i interrupt about this topic? + dammsan: sure [16:30] + it seems to me that the DMA_ATTR_SKIP_CPU prototype patch is a local + reaction to insufficient performance or R-Car Gen3 + dammsan: partly + however the root cause for this issue seems ignored + the root cause isn't ignored. we're moving forward with cache + handling support in V4L2 and DRM [16:31] + at least i was told that the performance on Gen2 is different than + Gen3 and because of that this patch was created + I started with the V4L2 side + Sakari took my latest patch series and posted a new version a few + days ago + I plan to review it + yeah ithink i know what the plan is + so we're moving forward with fixes for the root causes + but i feel that randomly adjusting cache policy might not be the + best solution + but in the meantime I think that using DMA_ATTR_SKIP_CPU makes + sense + do we know how the performance is affected? [16:32] + yes + the issue is that + the VSP driver handles the cache + and performs a cache cleaning + while the memory is actually mapped uncached [16:33] + so it makes sense to set DMA_ATTR_SKIP_CPU because the memory is + always mapped uncached + well, i can somewhat agree to that + but i don't understand why this is needed on Gen3 and not on Gen2 + this will need to be revisited when we'll implement support for + cached mappings in the DU driver + on Gen2 the buffers are allocated in the V4L2 framework [16:34] + of course the architecture has changed + sorry, I'm mixing two thinks + s/thinks/things/ + on Gen2 DU doesn't use the VSP + i just want to avoid papering over things + the VSP driver function where we need to set DMA_ATTR_SKIP_CPU + isn't called at all on Gen2 [16:35] + so this is for the DU? + yes it's for the DU + ok + and it is not needed with V4L2 VSP + if so i'm ok + for V4L2 VSP buffers are handled by videobuf2 and we already do + the right thing + gotcha thanks [16:36] + you're welcome + cache issues are always complex [16:37] + * Request API + for the same reason as explained with fences support, I had to + stop working on this upstream [16:38] + I thus passed the project to Google + Alexandre Courbot (ex-NVidia, he now works for Google Japan) has + taken over + I've had a few meetings with him to discuss the implementation + Wow ! So, you don't work for "Request API" anymore ? [16:39] + no I don't + I had to stop all V4L2 upstream API work [16:40] + I've explained that before (about a month ago I think, or even a + bit more) + but clearly not well enough as you're now surprised + I'm sorry about that + i think i explained this to Morimoto-san before as well [16:41] + OK + but we may have some language barrier + Yes, I think so + I'm sorry too + it's a very unfortunate situation and I did all I could to avoid + it, but unfortunately all I could wasn't enough + but I didn't want to give up either, which is why I spent the last + month trying to find a way to short-circuit the V4L2 maintainer + [16:42] + again, I can't announce anything yet, but I hope to receive a + confirmation by the end of this week that we'll propose a + co-maintainer setup for V4L2 + I don't expect Mauro to easily accept it though, but we're doing + all we can to propose a gradual and smooth transition to maximize + the chances he will accept [16:43] + I should be able to tell more next week + and again, please don't share this outside of the team [16:44] + * DU / VSP initialize sequence + on my to-do list for the next two weeks + I've already started looking into it, it needs a bit more work + pinchartl: can I share this information to BSP team ? + you can share the problem, and tell them that we're working on + trying to fix it, and that more information is expected by the end + of this week [16:45] + OK, thanks + but please don't share the fact that we're trying to go for a + co-maintainers setup + * VIN V4L2_FIELD_SEQ_TB/TB feature [16:46] + neg: what's your plan ? + still on your to-do list, based on top of the Gen2 cleanup patches + ? [16:47] + yes, was hoping to get the cleanups accepted first + is there anything blocking them beside lack of review ? + nope + ok thank you + as I undertood this was a low prio request, but if that changed I can + rescedule my plan for V4L2_FIELD_SEQ_TB/TB [16:48] + I'll review them this afternoon. can you send me a pointer to the + patches by e-mail so that I don't forget ? :-) + morimoto: what's the priority for V4L2_FIELD_SEQ_TB/TB ? + sure will do, thanks + (and I assume it's actually V4L2_FIELD_SEQ_TB/BT, not + V4L2_FIELD_SEQ_TB/TB) + pinchartl: priority is not hi [16:49] + but want to have + ok. it's definitely on the to-do list + next, dammsan [16:50] + TB/TB <-> TB/BT. I'm shame ;) + (who should actually have been first, as he sent no status report + at all ;-)) [16:51] + OK, thanks. [16:52] + I will share these information with BSP team + seems we've lost dammsan + I'll go next in the meantime + I've reposted the Gen3 HDMI output DT integration patches [16:53] + Thanks. I will try it + and asked Simon to merge them when v4.12-rc1 will be released + I've provided a tag with the patchees + pinchartl: no update here apart from getting Migo-R going + dammsan: thank you [16:54] + now that you're back, I'd like to ask you if you have time for a 5 + minutes chat on IRC after this meeting ? + (continuing with my report) [16:55] + I've started working on the DU / VSP initialization sequence + [16:56] + I've also reviewed Wolfram and Niklas' proposal for the I2C + software architecture for the multi-camera setup + sure + (I'll reply to Wolfram's e-mail about that) [16:57] + last but not least, I've spent a significant amount of time + handling the fallout of the V4L2 conflicts + guiding Google with the request API development [16:58] + and trying to find a solution to the human side of the problem + with other V4L2 developers + for the next two weeks, I'll [16:59] + - Look into the DU fence issue reported by the BSP team + - Cache (DMA ATTR SKIP CPU) performance issue with VSP2 + - DU / VSP initialization sequence + and likely more (patch review hopefully) + that's it for me + this closes the first topic + pinchartl: Not quite :) + pinchartl: Not that I mind ! + I would also like to give my status report :-) + oops sorry :-/ [17:00] + Hehe :) + I had copied your report in my summary e-mail already + so I thought you were done :-) + neg: you're next + In this case, Japanese people uses "orz" + A) + - [PATCH] v4l2-async: add subnotifier registration for subdevices + - [PATCH 0/2] media: entity: add operation to help map DT node to media + pad + - [PATCH v4 00/27] rcar-vin: Add Gen3 with media controller support + - [PATCH v6 0/2] media: rcar-csi2: add Renesas R-Car MIPI CSI-2 support + - Meeting with Wolfram to discuss DT bindings for 8-ch setup devices. + [17:01] + - Continued discussions about the ADV7482 with Kieran. + B) + - Post v2 of incremental v4l2-async and DT node to media patches, work + done (available in rcar-vin-fwnode-test-3) just need to convince my self + with more testing before posting. + - Post new version of CSI-2 patches (work done (available in + rcar-vin-fwnode-test-3), more tests. + - Act on Sakaris comments on Gen3 VIN driver and repost. + C) + - None + D) + - None + -- EOT -- + thank you + http://kage-design.com/i/orz1.jpg + morimoto: I'm working from a cafe this morning. if I did that I + think people would look at me in a very weird way :-) [17:02] + kbingham: you're last ;)à [17:03] + s/;)à/:-)/ + Keeping mine quick, and not jsut copying the email - I've been + working on ADV, which I feel is making good progress - the main + topic at the moment is the async subdevs which need to be matched + by the async framework. I'll be proposing a change to the matchings + for this framework this week. - Otherwise - the ADV748x driver now + has multiple subdevs to represent the entities. + http://janet.linuxembedded.co.uk/board-salvator-mc.png shows the + new layouts + Of course Niklas has helped me with several parts of that - so + thanks neg :) [17:04] + I've also been rebasing, reworking, and retesting my older + patchsets - 3/5 of which are reposted and pull-requested. + The last two caused me a bit more thought and hopefully will be + done soon (partition algorithm work) + Moving forwards over the next two weeks, I expect to see some good + progress on the v4l2-async subdev matching proposal (which will + require changing all the other users ... ugh) - and I hope that all + my existing patchsets will be freshened with an aim for them + getting closer to integration [17:05] + - eot - + thank you [17:06] + jmondi: before I forgot, could you try to document the RZ camera + hardware setup you're working on in the elinux.org wiki ? + s/forgot/forget/ [17:08] + now we're done with the first topic + Topic 2. Additional tasks for the second batch of Q2 + dammsan: how would you like to handle this ? + we now have a working multi-camera setup [17:09] + which you considered to be a blocker for the more general + additional tasks that I proposed before + right + i'm ok with more generic tasks + but we may have to adjust the outcome? + how do you mean ? [17:10] + pinchartl: as soon as I have something assembled together :) + jmondi: sure [17:11] + dammsan: have you disappeared again ? [17:12] + nah i'm right here sorry [17:13] + i believe the old proposal included some fixed deliverables + but now kieran is working on the ADV driver + and we have slipped time wise + so some update may be needed to reflect the current state [17:14] + sure + what I propose is + - updating the plan to take new developments into account + - creating informal tasks based on the plan for the multi-camera + development [17:15] + - assigning those tasks to developers + - for those who would work on the multi-camera setup, going + forward with the generic additional task + - for those who would work on other tasks, creating classic + additional tasks [17:16] + sounds good to me + I believe you typed the SGTM line before my last item + right, SGTM again =) [17:17] + thank you :-) + so, I'd like to ask you all to provide me with a list of items not + related to the VIN multi-camera setup that you think you should + work on as additional tasks [17:18] + that can be done on IRC or over e-mail + you can use periperi as a source of inspiration + and also propose other tasks [17:19] + (such as V4L2_FIELD_SEQ_TB/BT for Niklas for instance) + what I'd like to get from this is a good idea of what you'd enjoy + working on + I'll compile that into a proposal at the end of this week [17:20] + thanks + if you can get the shared multi-camera task done soonish then i can + review this week in the renesas office =) [17:21] + it is up to you + dammsan: I'll do my best but it will have to wait for tomorrow + sure, no problem [17:22] + thank you + this closes topic 2 + Topic 3. OSS Japan trip + Magnus has been very nice and booked a meeting space for us + [17:23] + https://www.airbnb.com/rooms/17013981 + accommodation is also available there + how is everybody doing with accommodation ? +* kbingham is very excited for the meeting place. + dammsan: Good work on the meeting room :) + kbingham, neg, jmondi, do you all have a place to stay at a + reasonable price ? + I still have my original booking at conference hotel for 28th May -- + 4th of Jun [17:24] + I think me and jmondi will have to share a room on the final + Saturday night at the conference hotel. + I've been able to reserve the conference hotel for the whole period + at a rate very close to the LF proposed one + I don't have a room for arrival - I need to find somewhere else + cheap. + kbingham: thanks, we'll se + e how it goes [17:25] + execept for last day, where price is almost double, but I'll be + sharing with kbingham (as he said) + ok + dammsan: will you be staying at the Taito-ku building ? + I'm quite proud of my "hotel room reservation"-foo now.. I had to + make 5 bookings to have the room at those rates :p + pinchartl: i might do so [17:26] + morimoto: dammsan: Could you recommend anywhere (in location terms) + that is good for a new arrival to Japan for lone-ranger sightseeing + upon arrival the weekend before the conference? + we now need to work on the agenda for the meeting [17:27] + I want to have time to do hacking all togther + but there will also be a more regular meeting + kbingham: asakusa or shibuya or shinjuku? + so please reply to the meeting report with a list of topics you + would like to discuss [17:28] + and I will then draft the agenda + I haven't received any proposal for the Saturday after the + conference [17:29] + I can decide on something by myself, but I'd really appreciate if + you could all take just a bit of time to tell me what you would + enjoy seeing/doing [17:30] +* kbingham enjoys hiking - and seeing cultural / natural aspects. + I expect feedback from everybody else by e-mail :-) [17:32] + You will :-) + next and last topic, next meeting + two weeks from now is Wednesday 2017-05-24 + that's the week before the face-to-face meeting + we could skip it, but I believe it would be useful to keep it, to + avoid spending time face-to-face discussing about topic that can + be handled during our regular bi-weekly meetings [17:33] + I agree..., and keeps the pace. + I agree too try keeping it to the 2 week schedule + agreed [17:34] + and also to finalize the agenda + The one following OSS might be worth slipping a week though, + otherwise we will all just say "Went to japan" + so I propose two weeks from now, same time + works for me + ok for me + booked + Ack. + thank you + that's it for today +*** horms (~horms@217.111.208.18) has quit: Quit: Leaving + unless anyone has anything else to discuss, I propose adjourning + the meeting [17:35] + does anyone second ? + Straight to thirded. +*** horms (~horms@217.111.208.18) has joined channel #periperi + thank you all for attending, and have a nice day ! + thanks, you too + thanks all, have a good day/evening + see you, thanks! + bye + Thanks +ERC> -- cgit v1.2.3