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/20161207-mm-chatlog | 395 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 395 insertions(+) create mode 100644 wiki/Chat_log/20161207-mm-chatlog (limited to 'wiki/Chat_log/20161207-mm-chatlog') diff --git a/wiki/Chat_log/20161207-mm-chatlog b/wiki/Chat_log/20161207-mm-chatlog new file mode 100644 index 0000000..a584795 --- /dev/null +++ b/wiki/Chat_log/20161207-mm-chatlog @@ -0,0 +1,395 @@ +Multimedia-chat-meeting-2016-12-07 + + Hi [16:59] + hello + hi all + Hyvaa huomenta [17:00] +* morimoto I can't pronunciation +*** uli___ (~uli___@static.206.203.46.78.clients.your-server.de) has joined + channel #periperi [17:01] + morimoto: even writing it is difficult on your keyboard :-) + do you have a key for รค ? + Unfortunately, No. + :P + kbingham said he might not be able to attend the meeting today + [17:03] + pinchartl: Terribly sorry to say I managed to make it (just) + :-) + welcome ! + and Magnus seems to be missing + Morning all :D + Morning kbingham [17:04] + morning + so let's get started + topics for today + - Status check for the multimedia tasks [17:05] + - Next meeting + anything else ? + FOSDEM ? + (I don't go though) + the rabbits will miss you [17:06] + Hehe :) me to + too + so [17:07] + Topic 1. Status check for the multimedia tasks + kbingham: do you mind starting ? + pinchartl: I'd actaully like to go last so I can upload something + :D [17:08] + (which will show why I was skiiving of work yesterday to work on a + personal project :D) + ok, let's reverse the order then + uli___: your turn + ok + so i collected a bunch of patches and checked if the vsp-tests run + with ipmmu enabled [17:09] + on gen3 + with a little fix, they do + although i had a few issues on m3-w + what kind of issues ? + where the system gets sluggish when running vsp-tests, with or + without ipmmu enabled + sometimes it freezes + but the tests pass [17:10] + haven't found out what that could be + I haven't noticed that + but I mostly use H3 + no issues on h3 [17:11] + ok, we'll need to investigate that + I'm a bit surprised that IPMMU works given that it's supposed to + be broken at the hardware level [17:12] + :) + issues and blockers ? [17:13] + pressed for time. other than that, none + I see you'll be on vacation from next Monday to the 3rd of January + ? [17:14] + yes + Wow! winter vacation ? + have fun, both finishing all your tasks before that, and during + your vacation :-) + :) [17:15] + next, neg + A) Nothing + B) Address CSI2 review comments [17:16] + C) None + easy :-) + thanks + Will also have a shorter vacation trip then uli___ from 27 Dec -- 6 Jan + :-) + I'll wish you a good vacation during the next meeting then :-) + [17:17] + next, Morimoto-san + OK + A) [17:18] + I got review from Rob about OF-graph HDMI sound. He don't like + current style. Now I'm discussing about it. + + B) + DU side DT will have HDMI video and sound. ALSA SoC side needs to + know total how many HDMI sound port exist. + but, Rob rejected "type=" property. So, I can't know. + ---- from Rob ---------------- + I still don't think this is necessary. Simply define which port + number + is which for each HDMI chip. + If this is necessary, then the types, video and sound, are too + generic. + ------------------------------ + What does it mean ?? How to get this information from ALSA side ?? + I think I need to corroborate with HDMI video ? + s/corroborate/collaborate [17:19] + C) [17:20] + I need to re-create OF-graph patches. + Can I use Laurent version ? I'm using Ulrich version + -- EOT -- + regarding the type property + the DT bindings for each HDMI encoder define the number and type + of each port + Rob's point is that, instead of adding a generic type property, + you should query the HDMI encoder driver at runtime to know the + number of audio ports [17:21] + I'm not sure if that's feasible though, I haven't checked how it + works on ALSA"s side + but in runtime query, how the driver know total size ? [17:22] + fixed size, does it mean ? + the driver knows because the driver knows the hardware + it's hardcoded in the driver [17:23] + OK, I see. + for instance let's say we have an HDMI encoder with two sound + inputs, one video input and one HDMI output + that's 4 ports + the DT bindings would document something like + port 0: video in + port 1: audio 0 in + port 2: audio 1 in + port 3: hdmi output [17:24] + then let's imagine that the board has audio 1 in connected + and audio 0 not connected + DT would have port 2 connected with an endpoint + and port 1 not connected, with no endpoint + the driver would parse the DT node + see that port 1 is not connected and port 2 is connected [17:25] + and conclude that there's one audio input in use among the two + possible audio inputs + there's no need for a type property there + the type property would only be needed if you need geenric code to + parse the DT node, code that has no knowledge of the device + [17:26] + So this mean we need new "query" function for it ? + it tell "for video port" "for sound port" or "connected", something + like that [17:27] + that would be the idea. again, as I'm not too familiar with ALSA's + internals I don't know if that would be easy, or even good + but Rob's point is that code that parses the OF graph in a + completely generic way is usually a bad idea [17:28] + OK + because DT properties are defined by DT bindings in relationship + with the compatible strings + so a generic function that walks through the OF graph, from node + to node, trying to collect information about each node, can't know + for sure what a property means [17:29] + +1 question is that this mean, DU driver will have this "query" + function, righ ? + I'm not as opposed to that as he is, but I understand his point + do you mean the dw-hdmi driver ? + I don't know. DU has port, right ? [17:30] + not dw-hdmi +*** horms (~horms@217.111.208.18) has joined channel #periperi + the DU has a DT node, yes + but DU doesn't handle sound + the HDMI encoder DT node does [17:31] + Yes, yes. DU driver only handle video side, but will have + video/sound port in DT. + This means, DU driver need to care about video/sound port, too + + https://git.linuxtv.org/pinchartl/media.git/commit/?h=drm/du/hdmi&id=3d12f1ed444c7d38e4006d51155dfebca0bb3d22 + [17:32] + those are the DT nodes that will have audio ports + they're handled by the new rcar-dw-hdmi driver + + https://git.linuxtv.org/pinchartl/media.git/commit/?h=drm/du/hdmi&id=59115b56b8156a60b5e1d3e0077611ed403b6154 + which is the platform glue layer for the dw-hdmi core code [17:33] + Oops, I need to rebase to it [17:34] + Does renesas-driver has it ? + it should, yes + OK. + Geert told me yesterday he would merge it + And it is almost upstream version ? + yes + OK [17:35] + I've posted v1 already + and will post v2 soon + (more about that when it will be my turn) + OK, I will rebase to it, and consider about query function. + But, + HDMI will have "sound" port anyway. So video side need to care it, + right ? [17:36] + (avoid sound port, etc..) + yes it will + Or HDMI video/sound can share same port ? [17:37] + it should be two different ports + OK, nice to know + I will investigate it next week. thanks + so we would need an API to walk the DT graph with assistance from + drivers + you're welcome + I will ask about query to Rob [17:38] + I think I've answered your question about which version of the + HDMI patches you should use + so now it's my turn :-) + since last meeting [17:39] + as I said, I've posted the HDMI output on Gen3 patches + Kieran and I have been working together on that + we got rid of all hacks [17:40] + one of the good news is that ES1.x / ES2.0 don't need special + handling anymore + Nice + the series cleans up and enhances the dw-hdmi driver + I've received a few comments about that + and reworked the patches accordingly [17:41] + based on information I managed to gather about the Synopsys DWC + HDMI TX IP core + it's not easy, as there's no public datasheet from Synopsys + speaking of which, I talked to one of their engineers in private + he said he wasn't allowed to give me information + but that, if I needed support, I should be able to get it through + Renesas [17:42] + he said that if Renesas contacted Synopsys' support, the question + would be routed to him, and he could then talk to me in direct :-) + so far I managed to solve most of the problems withotu needing + that + I've also done review, there was quite a bit of discussion about + the DRIF DT bindings [17:44] + no time to post a proposal for the rotation and histogram APIs yet + I'm afraid [17:45] + I'll try to address that in the next two weeks + aV4L2 cache + oops + as well as starting the V4L2 cache discussion + no real issue or blocker, I've been slowed down by the lack of + public dwc hdmi documentation, but I found a leaked datasheet and + gathered more information from several developers [17:46] + so at the moment it's not an issue + that's it for me [17:47] + kbingham: your turn now + Ok :D + So - as per the mail I sent - I've fixed suspend resume on m2m + pipelines, and incorporated the fix for the BRU race I discovered + into this as well. [17:48] + I've also written a couple of automated tests for suspend resume + which should make their way into vsp-tests. - It's quite neat, as + it uses a PM debug tool in the kernel to suspend, and then + automatically resume after 5 seconds. [17:49] + (bit of context for the reader, M2M pipeline refers to the VSP) + [17:50] + Ah yes - sorry - I was lacking context there :D - There are still + issues in the display pipeline but that is more complicated as we + are then dealing with making sure multiple cells suspend resume + cleanly I believe. [17:51] + yes, DU suspend/resume still needs work + Aside from that - I've done some work on HDMI with Laurent, and + I've been supporting Duc@Jinso to help him get a set up for testing + the writeback prototype I posted last month. + My B) section is a little 'fuzzy' at the moment, so I'll leave that + section blank for now :D [17:52] + C) - There was a lot of time spent looking after Jinso :( [17:53] + D) Show(off) and tell - + - I've made an LED Christmas Tree Hat (for Xmas parties) + - https://goo.gl/photos/PRyXXbpJdJbokBQ56 + :-D + nice + Speak of the devil - Duc@Jinso has just mailed me again :D [17:54] + Morimoto-san: I've sent you an e-mail regarding the support we + have to provide to Jinso + Nice hat ! [17:55] + Magnus told me he would discuss it with you, tomorrow if I + remember correctly + OK, I will talk to him. + Renesas side needs discuss about that ;P + kbingham: what's your vacation schedule for the end of the year ? + [17:57] + ... + That's just what I was writing next :D + Or rather was going to ask about :D + Keri is on holiday from school from the 19th to the 3rd. [17:58] + I don't necessarily need all that time as holiday - but I don't + think I have much work planned at the moment ... + ok [17:59] + speaking of which + Certainly - I won't be working 23rd to 3rd probably [18:00] + Morimoto-san, you mentioned a VSP/DU performance problem reported + by a customer + has there been any feedback on that ? + it sounded quite urgent, is it something that we need to start + working on before January ? + There is no response from BSP team, at this point [18:01] + let me check + ok, we'll wait and see then + Ok - well I have plenty of work to continue getting my garage + office conversion :D [18:02] + :-) + and speaking of winter holidays, will Renesas be operating between + christmas and new year ? + so that will keep me busy in the meanwhile. + pinchartl: Are you going to take a break anytime ? [18:03] + I'll be in Belgium from the 21st to the 29th [18:04] + I'll still be available 21st-23rd (minus time stuck in transport + on the 21st) + and will take 24th-29th off [18:05] + Renesas side will have winter vacation from 29th Dec - 9th Jan + BSP team want to know VSP/DU plan, at this point. [18:06] + the plan to fix the issue they've reported ? + They will explain current situation to customer, but customer want + to know its plan + Yes + we can either start working on it in 2017/Q1 [18:07] + or, if it's urgent, Kieran could start investigating it in + December already + morimoto: are those dates inclusive or exclusive? + but we'll need an additional task for him + horms: sorry, what do you mean ? [18:08] + do you start holiday on Friday or Saturday? + Do you finish holiday on Sunday or Monday? + horms: the 29th is actually a Thursday + ok, sorry [18:09] + its not so important in any case + no worries, calendars are confusing :-) + BSP team is thinkingl [18:10] + oops + BSP team is thinking that they can get some kind of result from + upstream January - March [18:11] + Is it possible, do you think ? + that works for me + OK, so Kieran can spend relax Christmas :) [18:12] + :-) + morimoto: I'm not sure the words 'relax' and 'christmas' go + together anymore :S + but yes :D + sorry for my English [18:13] + kbingham: that's why I go to the caribbeans and drink rum, I will be + relaxed :-) + morimoto: No your english was fine :D + neg: Got any room in your luggage to pack me ? + horms: Renesas last working day is 28th, and holiday started from + 29th + thanks [18:14] + horms: last holiday is 9th, start works from 10th. Is this clear ? + morimoto: very clear, thanks + next topic, FOSDEM + very clear, thanks + Morimoto-san will unfortunately not be able to join us [18:15] + horms: np + has there been a confirmation that a core meeting will be held on + Friday the 3rd of February ? + I think that is more or less confirmed + ok + geertu: ? + horms: yes? [18:16] + geertu: is f2f core meeting on 3rd Feb confirmed? + horms: If Laurent and Magnus join, we are 6 persons. [18:17] + which is critical mass, I believe? So yes + I'll be there + Magnus said he arrive at Feb 3th [18:18] + Feb 3rd afternoon + ok + afternoon = 16:05 [18:19] + Hmmm... + He also said he might change his plane + geertu: I'll likely be there by then regardless - so I might join + you for somewhere to keep warm :D + If I'm not wanted - I'll explore brussels :) [18:20] + Will there be an MM meeting on Thursday? + at this point there's no formal plan for a multimedia meeting, but + I've booked the afternoon of February the 2nd nonetheless + Brussels? + Or will it just ve I/O and Core on Friday? + if you're in Brussels, I'm sure we won't run out of multimedia + topics to discuss + next topic, next meeting [18:22] + I propose two weeks from now + on the 21st + Ulrich is already excused as he will be on holidays + 21st works for me + uli___: but please report your progress by e-mail before leaving + [18:23] + 21st doesn't works for me :( + ok + morimoto: we can move it to Tuesday or Thursday + 20th, 22th are OK + Core meeting on Dec 20th? [18:24] + (still have to complete the report and mail it out) + there's the core meeting on Tuesday already. we can have the + multimedia meeting after core, but it will be late for you + so maybe 22nd then ? + 22nd is OK for me [18:25] + 22nd then. same time, 08:00 GMT / 09:00 CET / 10:00 EET / 17:00 + JST + Thanks. I booked [18:26] + and that's all we have on the agenda for today. I propose + adjourning the meeting, does anyone second ? + I'll skip to thirded :D + fourthed + thank you all for attending [18:27] + and have a nice day or evening + Cheers all ! + thanks all + Thanks! -- cgit v1.2.3