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