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/20160831-mm-chatlog | 384 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 384 insertions(+) create mode 100644 wiki/Chat_log/20160831-mm-chatlog (limited to 'wiki/Chat_log/20160831-mm-chatlog') diff --git a/wiki/Chat_log/20160831-mm-chatlog b/wiki/Chat_log/20160831-mm-chatlog new file mode 100644 index 0000000..01be483 --- /dev/null +++ b/wiki/Chat_log/20160831-mm-chatlog @@ -0,0 +1,384 @@ +Multimedia-chat-meeting-2016-08-31 + +10:05 < pinchartl> topics for the day +10:05 < pinchartl> 1. Status check for the multimedia tasks +10:06 < dammsan> pinchartl: please connect to me via google chat at some point today so we can briefly talk about some paper stuff? +10:06 < pinchartl> sure +10:06 < pinchartl> does anyone want to add another topic ? +10:07 < dammsan> i have an idea: +10:07 < dammsan> additional task proposals for next quarter +10:08 < dammsan> at least something to start thinking about +10:08 < pinchartl> it's a good time to start thinking about it, yes +10:08 < dammsan> nothing apart from that from my side +10:09 < pinchartl> Topic 1. Status check for the multimedia tasks +10:09 < pinchartl> ---------------------------------------------- +10:09 < pinchartl> in sort -R order +10:09 -!- Irssi: Pasting 5 lines to #periperi. Press Ctrl-K if you wish to do this or Ctrl-C to cancel. +10:09 < pinchartl> - Ulrich +10:09 < pinchartl> - Magnus +10:09 < pinchartl> - Niklas +10:09 < pinchartl> - Kieran +10:09 < pinchartl> - Morimoto-san +10:09 < pinchartl> - Laurent +10:09 < pinchartl> uli___: your turn +10:10 * geertu stops using gose +10:10 < uli___> see the e-mail i sent; i think task statusses are not affected by any stuff i have done since last time +10:10 < uli___> we would have to talk about how to proceed with hdmi out +10:11 < pinchartl> let me copy it here for reference +10:11 < pinchartl> A) Since last time +10:11 < pinchartl> - Refreshed HDMI out series for Gen3 +10:11 < pinchartl> Updated for 4.8-rc2. (See also C.). Some of the larger patches (e.g. bridge API conversion) have been upstreamed and could be dropped. +10:11 < pinchartl> B) Until next time +10:11 < pinchartl> - Gen2 VIN integration +10:11 < pinchartl> C) Problems +10:11 < pinchartl> - HDMI out doesn't work on Morimoto-san's Salvator-X board. +10:12 < pinchartl> The CMA reservation patch that is part of the HDMI out series breaks the kernel. This patch is required, so we'll have to find out why it doesn't work. An issue with firmware 2.8.0 is the prime suspect ATM. +10:12 < pinchartl> - Product register access unresolved +10:12 < pinchartl> The HDMI out series requires access to the product register. How to implement that the right way is part of a discussion ("[PATCH 0/4] ARM: Renesas: R-Car3: Add product register support") that ended without conclusion. +10:12 < uli___> thanks +10:12 < dammsan> i sort of thought we had a plan about PRR +10:12 < dammsan> but that's a topic for core i think +10:12 < geertu> Yes, ES handling +10:12 < pinchartl> regarding the HDMI output series for Gen3, are there patches you think could be upstreamed sooner than latter ? +10:13 < pinchartl> s/latter/later/ +10:13 < uli___> it consists of a lot of bit parts that should not bother anybody if they get merged +10:13 < uli___> the big issues are prr and (i guess) binding the dw-hdmi driver +10:14 < uli___> nobody has commented on the latter yet +10:14 < pinchartl> to ask it differently, are there patches you'd like to fast-track now, or should everything be merged together ? +10:14 < uli___> those things have already been picked up (bridge API etc.) +10:14 < uli___> the rest makes more sense together +10:14 < pinchartl> I agree +10:15 < dammsan> May I ask why the CMA reservation patch is required? +10:15 < pinchartl> what's the plan for the CMA issue ? +10:17 < uli___> without it, the du driver fails to initialize +10:17 < uli___> i get the same result as morimoto-san in that case +10:17 < uli___> (panic) +10:17 < pinchartl> do you know why ? +10:17 < uli___> no +10:18 < dammsan> it is usually possible to increase the default CMA area with other standard methods +10:18 < morimoto> This patch was created by Fukawa-san, and I can ask to him. But he is talking to other guy now +10:18 < dammsan> morimoto: Fukawa-san is adding that patch for the MMP +10:18 < dammsan> see the patch commit message +10:19 < dammsan> it is way of dealing with memory management for the inhouse multimedia package +10:19 < dammsan> it is not the same as what upstream is supposed to do +10:19 < dammsan> just applying it blindly seems a bit short sighted IMO +10:19 < pinchartl> I'll have a look at that +10:20 < dammsan> uli___: what happens if you increase the default CMA size? +10:20 < uli___> haven't tried that. now that i think about it, i had a similar issue on lager where that helped... +10:20 < uli___> i'll check it out +10:20 < pinchartl> the DU driver could fail with the default CMA area, but the kernel should not panic in any case +10:21 < dammsan> yeah, same thing existed on older generation as well +10:21 < dammsan> pinchartl: agree that panic is not supposed to happen +10:21 < morimoto> Mine doesn't *panic*, but DU do nothing. +10:22 < neg> (My M3 carrier just arrived, need to run down and fetch it) +10:23 < dammsan> pinchartl: any idea how much work there is to enable HDMI on M3-W? +10:23 < pinchartl> dammsan: once it works on H3 it should be pretty straightforward +10:24 < pinchartl> (after enabling DU on M3-W of course) +10:24 < dammsan> i wonder if DU on r8a7796 differs from r8a7795 +10:24 < dammsan> the driver development portion for that would be useful to get done sooner than later +10:24 < pinchartl> it differs but not in a way that should cause any issue +10:24 < dammsan> please note that i would like to control the integration order on r8a7796 to coordinate with IPMMU +10:25 < dammsan> but some prototyping w/o IPMMU would be useful for sure +10:26 * neg is back with a big box of 'High Reliabibility Parts of Electronics' +10:26 < geertu> Christmas is early this year... +10:27 < pinchartl> uli___: what's the status of 'VIN HDMI input EDID' ? +10:28 < uli___> i guess hans needs a nudge there, i was asking if the series should be split up into code and DT +10:28 < uli___> i though he was just going to review niklas's patches first +10:29 < pinchartl> please remember to send the description of the test environment to Jinzai by the end of the weekend (September the 4th) +10:29 < uli___> will do +10:30 < pinchartl> thans +10:30 < pinchartl> thanks +10:30 < pinchartl> next, dammsan +10:31 < dammsan> nothing to report here really +10:31 < dammsan> currently poking around with IPMMU and DU, about to test the code from pinchartl =) +10:32 < pinchartl> any issue or blocker ? +10:33 < dammsan> not so far, i suspect some display list code may need more attention +10:33 < dammsan> but i will know for sure later today +10:34 < pinchartl> ok +10:34 < pinchartl> next, neg +10:34 < neg> a) VSP HGT driver almost done, evrything works just some documentation missing. Hans picked up a patch sereis for VIN so one step closer to Gen3 support upstream +10:34 < neg> b) Post HGT driver and onther VIN patch which Hans hopefully will pickup for v4.9 +10:34 < neg> c) HGT test program to emulate HST (RGB->HSV) do not match HW perfectly. No review on VIN GEN3 patches I don't think they will make it to v4.9 :-( +10:35 < pinchartl> regarding HGT +10:36 < pinchartl> I had a look at the RGB to HSV transformation +10:36 < pinchartl> the test application that generate frames is able to compute S and V exactly +10:36 < pinchartl> but for H it differs from the hardware values by 1 at most, in ~8% of the cases +10:37 < pinchartl> you've asked Morimoto-san to check if we can get information about how the hardware performs the transformation +10:37 < morimoto> About your question about RGB <-> HSV, I think I replyed answer. Does it OK for you ? +10:37 < pinchartl> and he replied that the BSP team has no information about it +10:37 < pinchartl> I'm not surprised, as it's a hardware-related question :-) +10:38 < pinchartl> do you think we could get information from the hardware team ? +10:39 < morimoto> The Document issue S vs V is under HW team control now. +10:39 < pinchartl> S and V are fine. it's H that we have trouble with +10:40 < neg> morimoto: yes I understand that precision is lost in RGB->HSV->RGB as the manual states but this is for RGB->HSV which is deterministic. If I use a lookup table for the 8% of values I can not compute the HW is emulated perfectly +10:41 < pinchartl> there's a division by 3 in the equation used to compute H, and I'm pretty sure the hardware approximates that by a multiplication followed by a shift (probably *341/1024 or *683/2048) +10:41 < pinchartl> but even with that we haven't been able to achieve a perfect match +10:41 < neg> so it's the way I calculate RGB->H that is wrong and if possible I would like input on +10:42 < pinchartl> neg: I wouldn't say it's wrong. the issue is that the hardware performs approximations and rounding in a way we don't know +10:44 < geertu> neg: How big are the absolute errors? E.g. can't you just allow -1/+1 differences? +10:44 < pinchartl> geertu: when comparing images, sure, but when computing histograms it can cause an unknown amount of pixels to fall into another bucket +10:45 < neg> geertu: the error is in the range +/- 1 but it's used to generate a histogram with buckets and that error results in a value being counted in the wrong bucket unfortunatly +10:46 < neg> alsa this is only for the test application, so one workaround is to only test it using 1 out of 6 buckets +10:46 < geertu> Can multiple values end up in the same bucket? or is it one-to-one? +10:46 < neg> multiple values can go in the same bucket +10:47 < pinchartl> the histogram generator puts pixels in buckets and reports the number of pixels in each bucket (roughly) +10:47 < neg> there are in total 6 buckets wich can be spread out over a value range of 0-255 +10:48 < geertu> If the test software uses one-to-one buckets, it can calculate upper and lower bounds for each hardware bucket, assuming a max error of -1/+1 +10:48 < pinchartl> geertu: I don't see how that would help +10:49 < pinchartl> a -1/+1 error can cause a pixel to fall in the next bucket +10:49 < geertu> i.e. sum (sw_bucket[first..last]) <= hw_bucket <= sum(sw_bucket[first-1..last+1]) +10:49 < geertu> And the total sum must match +10:49 < pinchartl> in the worst case all pixels could fall in another bucket +10:50 < pinchartl> the purpose of the test is to verify that the driver works correctly. if we have to accept 100% errors, it's quite pointless +10:50 < geertu> Sure, but only due to a -1/+1 difference, right? +10:51 < pinchartl> still +10:51 < pinchartl> we want to catch things like an off-by-one write to registers +10:51 < pinchartl> which would result in pixels falling the another bucket the same way than the H computation error would +10:52 < geertu> In that case you do need to know exactly how the hardware works +10:52 < pinchartl> that's my point, yes +10:52 < pinchartl> anyway, Morimoto-san, if we can get information from the hardware team about how the hardware computes the H value from the R,G,B values, then we'll be able to test the HGT +10:53 < neg> geertu: we know how the HW works for S and V only H still eludes me :-) +10:53 < pinchartl> otherwise we won't be able to catch HGT regressions in the test suite +10:54 < pinchartl> neg: regarding the deadlines +10:54 < pinchartl> you mentioned that tests should be done tomorrow +10:54 < pinchartl> but, first of all, the due date is September the 4th +10:54 < pinchartl> and it's only the description of the test environment that's needed +10:55 < pinchartl> not the full test suite +10:55 < morimoto> OK, I will find HW guy, and will ask. +10:55 < pinchartl> i.e. the list of the test tools +10:55 < morimoto> I can say it will be long term. +10:55 < pinchartl> so that Jinzai can cross-compile them already +10:55 < neg> pinchartl: ohh I thought the entier test suite should be done +10:56 < pinchartl> morimoto: thank you. if we can get the verilog code corresponding to the H computation, I can find out how the hardware works myself ;-) +10:56 < morimoto> pinchartl: OK +10:56 < pinchartl> neg: test scripts can still be modified until the final due date +10:56 < neg> but if they need to compile the tools now this still needs to be done since this is in the gen-image test tool of vsp-tests +10:57 < pinchartl> they can recompile the test tools when performing tests +10:57 < neg> ahh great +10:57 < pinchartl> what they want to avoid is running into cross-compilation issues at the last minute +10:57 < pinchartl> a git pull && make, if there's no additional dependency, is fine +10:58 < neg> I take it from this discussion that it's better for me to submit a vsp-tests that only uses 1 bucket over bundeling the 54M lookup table and use all 6 buckets? Atlest untill we figure out how the HW works +10:59 < pinchartl> yes, please +10:59 < neg> good +11:00 < pinchartl> kbingham: you're next +11:00 < neg> About VIN Gen3, please find time to review it :-) +11:00 < kbingham> VSP-Partitioning Status +11:00 < kbingham> Initial prototype for partition algorithm implemented, work in progress to debug some issues, and get some real testing going. +11:00 < kbingham> Ongoing Plan: +11:00 < kbingham> After a little bit of catch up from being on holiday, my plan is to work on progressing the VSP partitioning, and get some viable tests going. Then of course solve all the bugs that will inevitably pop up. +11:02 < kbingham> If you need me to look at FDP1 stuff anytime - let me know, as I'll focus on VSP for the moment. +11:02 < pinchartl> thanks +11:02 < pinchartl> let's focus on the VSP, yes +11:02 < pinchartl> I'll post my current version of the FDP patches +11:03 < pinchartl> no issue or blocker ? +11:04 < morimoto> pinchartl: could you get M3 board ? and forwarded it to kbingham ? I would like to know +11:04 < kbingham> none at the moment - as I've not got very far yet with being back. Various accountant things and email catch up took up most of yesterday. but I can actually boot a board today :D +11:05 < pinchartl> morimoto: not yet, it's currently in a plane from Tokyo to Helsinki according to the shipment tracking page. it should land in the afternoon +11:05 < morimoto> Ahh, OK. Thank you +11:06 < pinchartl> morimoto: your turn :-) +11:06 < morimoto> OK +11:06 < morimoto> RSND,v4.10,public,morimoto,DT bindings for graph sound +11:06 < morimoto> +11:06 < morimoto> this is on going. it need many steps. +11:07 < morimoto> but it have small steps now. +11:07 < morimoto> RSND,v4.10,public,morimoto,dw-hdmi-i2s-audio prototype on Gen3 +11:07 < morimoto> I posted this patch to ML, and I think it is OK +11:07 < morimoto> but maintainer had summer vacation, and it seems forgot about this +11:07 < morimoto> RSND,v4.10,prototype,morimoto,HDMI SSI prototype on Gen3 +11:08 < morimoto> This works in my local envilonment on old kernel. +11:08 < morimoto> It doesn't work on latest geert's branch, because of above HDMI out issue. +11:08 < morimoto> HDMI sound is based on HDMI video +11:09 < morimoto> RSND,v4.10,plan,morimoto,HDMI sound Upstream support without hotplug on Gen2 +11:09 < morimoto> RSND,2016-09-30,plan,morimoto,Hotplug support upstream on Gen3 +11:09 < morimoto> Is is big topic +11:09 < morimoto> ALSA SoC framework should be cleanup/update +11:09 < morimoto> This is related to unbind issue too +11:10 < morimoto> I posted this topic to ML, and we had discussion +11:10 < morimoto> And I posted cleanup patches. +11:10 < morimoto> 1 series was accepted. but other was NACK:ed by Lars +11:11 < morimoto> I think I and Lars and maintainer (= Mark) want to talk F2F (?) +11:11 < morimoto> EOT +11:11 < pinchartl> thank you +11:11 < pinchartl> regarding the HDMI output issue with the latest renesas drivers tree +11:12 < pinchartl> you mentioned in your e-mail that you would like to know the plan +11:12 < morimoto> Yes, is this Ulrich's task ? +11:12 < pinchartl> we've discussed this earlier, Ulrich will check if we can just increase the default CMA area size without requiring the DT patch +11:12 < pinchartl> uli___: is my understanding correct ? +11:12 < uli___> yes +11:13 < pinchartl> thanks +11:13 < morimoto> OK, nice. I thought it (= prototype) was his task, but after that it is Laurent's task. +11:13 < morimoto> OK, uli___ has this handle +11:15 < morimoto> no more comment form me +11:15 < morimoto> s/form/from/ +11:15 < pinchartl> morimoto: will you attend ELCE ? +11:16 < morimoto> Yes +11:16 < morimoto> Lars has presentation about this topics +11:16 < pinchartl> it would be good to schedule a face to face discussion with Lars +11:16 < morimoto> I think so +11:16 < pinchartl> I'm not sure if his presentation will address this specifically +11:17 < pinchartl> I think he will talk, among other things, about the current mess with the Intel audio hardware +11:17 < pinchartl> (i.e. no Linux support for audio on latest Intel platforms) +11:18 < morimoto> interesting +11:18 < pinchartl> could you contact Lars to schedule a meeting ? +11:19 < morimoto> no. I think I can find him on ECLE ? or should I ask to him ? +11:19 < pinchartl> please ask him beforehand, everybody is busy during ELCE, and this is important enough to make sure we can allocate enough time for the discussion +11:20 < morimoto> OK, will do +11:20 < pinchartl> thank you +11:21 < pinchartl> next, me +11:21 < pinchartl> since last meeting +11:21 < pinchartl> vacation :-) +11:22 < pinchartl> I've submitted IPMMU + DU integration patches +11:22 < pinchartl> they have been tested on Gen2 only due to the IPMMU being broken on H3 +11:22 < dammsan> pinchartl: on ES1 =) +11:22 < pinchartl> the patches include DT integration and changes to the FCP, VSP and DU drivers to make it all work +11:22 < pinchartl> dammsan: yes, ES1.0 :-) +11:23 < pinchartl> I've also reworked Kieran's FDP driver and will post a v2 +11:23 < dammsan> pinchartl: it seems the integration stuff is somewhat experimental, is that correct? +11:23 < pinchartl> which fixes several issues but breaks overalll operation :-) +11:23 < pinchartl> yes, it's experimental +11:23 < dammsan> cool, thanks +11:23 < pinchartl> the DT part should be quite stable +11:24 < pinchartl> changes to the FCP, VSP and DU drivers is experimental +11:24 < pinchartl> I'd really appreciate a careful review +11:24 < pinchartl> not so much for the implementation itself, but for the APIs between the drivers +11:24 < dammsan> right +11:26 < pinchartl> for the next two weeks +11:26 < dammsan> the DT part does not seem to change so much =) +11:26 < pinchartl> no, the DT part is quite stable I think +11:26 < dammsan> hehe +11:26 < pinchartl> there's no new Dt binding +11:26 < dammsan> that's a good thing +11:27 < dammsan> but we do want a stable implementation too =) +11:27 < dammsan> but it begins with a review +11:27 < pinchartl> definitely :-) +11:27 < pinchartl> for the next two weeks +11:27 < pinchartl> - Continue working on the FDP driver to get it merged upstream +11:27 < pinchartl> - VSP image partitioning support +11:27 < pinchartl> - DU and VSP integration on H3 +11:27 < pinchartl> - VIN and HDMI output patch review +11:28 < pinchartl> blockers and issues +11:29 < pinchartl> Geert pointed out, when reviewing the DU and VSP DT integration patches, that the latest Gen3 errata removed VSPD3 +11:29 < pinchartl> the DU3 channel is now fed by VSPD0, as is the DU0 channel +11:30 < dammsan> this is true for both H3 and M3-W? +11:30 < pinchartl> no, only for H3, M3-W has 3 DU channels only (DU0 to DU2) +11:30 < pinchartl> not only does this not match my experience with H3 ES1.0 on which I've used VSPD3 with DU3 successfully +11:30 < pinchartl> but it would also completely break the whole VSP + DU software model +11:31 < pinchartl> I think I've politely mentioned "brain-dead design" when replying to the e-mail +11:31 < pinchartl> I'd like to get more information about this +11:31 < dammsan> that's very polite of you =) +11:31 < pinchartl> and how it's supposed to work +11:33 < dammsan> there may be some sort of reason behind all this +11:33 < pinchartl> morimoto: do you think I could bother you to get more information about this ? +11:33 < dammsan> if it makes sense or not is a different question +11:34 < pinchartl> first of all, whether the errata is correct or not +11:34 < pinchartl> whether it applies to H3 ES1.1 only or ES1.0 too +11:34 < pinchartl> and how DU0 and DU3 are supposed to be operated if they use the same VSPD +11:35 < dammsan> right +11:35 < morimoto> Can you email it me ? I can ask to HW guys. +11:36 < pinchartl> sure, thanks +11:36 < pinchartl> I'll explain that in the meeting report +11:36 < pinchartl> would you like a separate e-mail ? +11:36 < morimoto> meeting report is OK +11:36 < morimoto> Is this for HW team ? or BSP team ? +11:36 < pinchartl> thank you +11:36 < pinchartl> that's all for me +11:36 < pinchartl> Topic 2. Additional tasks for Q3 2016 +11:36 < pinchartl> ------------------------------------- +11:37 < pinchartl> we need to start thinking about additional tasks +11:37 < pinchartl> obviously specific requests from Renesas should be taken into account +11:37 < pinchartl> but we can also be proactive and propose tasks for areas that we have identified as needing love +11:37 < pinchartl> I would thus like feedback from all of you about this +11:38 < pinchartl> if you already have ideas please mention them now +11:38 < pinchartl> otherwise, please think about it this week and propose them by e-mail +11:38 < pinchartl> and just talk to me on IRC +11:38 < dammsan> M3-W DU prototype +11:39 < dammsan> M3-W VIN prototype +11:39 < pinchartl> I'll double-check the details, but I think we can skip the prototype stage and go directly to an upstream-ready patch series for M3-W DU +11:39 < pinchartl> for VIN I'll let neg check what makes sense +11:40 < neg> Will check and get back to you +11:40 < dammsan> that sounds nice, but perhaps we can do prototype for first batch and upstream for next +11:40 < dammsan> we don't know what kind of issues that may be lurking +11:40 < dammsan> if you can do upstream-ready directly then that's fine too +11:41 < dammsan> we need HDMI video out support too eventually +11:41 < pinchartl> let me get my M3-W board and then I'll check what makes the most sense +11:41 < pinchartl> but in any case an M3-W DU task makes sense +11:41 < pinchartl> yes +11:41 < dammsan> sounds good +11:42 < dammsan> are we ready for a dma_buf zero copy user space test program? +11:42 < dammsan> from vin via vsp to du +11:42 < pinchartl> I think we're ready to start working on that, yes +11:43 < pinchartl> we still haven't addressed cache management +11:43 < dammsan> how about audio test program, for loopback testing of kHz setting and L-R issues +11:44 < dammsan> i think the cache management requirement actually means that they want to improve performance +11:44 < pinchartl> yes +11:44 < dammsan> and they have some sort of proposal +11:44 < dammsan> which may or may not make so much sense +11:44 < dammsan> but we probably need some base line to begin with +11:45 < pinchartl> we need to come up with a proposal to achieve proper performances +11:45 < pinchartl> whether it requires special cache management is more of an implementation detail +11:45 < dammsan> yes exactly +11:46 < dammsan> it depends on what user space does too +11:46 < dammsan> i think it makes sense to cook up a zero copy test app as counter-proposal +11:47 < dammsan> but perhaps i need to listen to their requirement more +11:47 < pinchartl> :-) +11:47 < dammsan> how long time would a zero copy test app take to implement? +11:47 < dammsan> would it be possible in one "slot" of additional tasks? +11:48 < pinchartl> I think so +11:48 < dammsan> in two weeks something should be doable IMO +11:48 < dammsan> so i hope to figure out some additional task for all memebers sometime soon this month +11:49 < dammsan> this for the first slot of next quarter +11:49 < dammsan> the second slot content can be discussed in Berlin +11:49 < dammsan> i hope to fix the first slot content in middle of September +11:50 < pinchartl> sounds good to me. I propose letting everybody think about additional tasks until the end of the week and discussing them early next week +11:50 < dammsan> good idea +11:50 < pinchartl> everybody, please think about what you believe is needed and let me know by the end of the weekend +11:52 < pinchartl> I propose holding the next meeting in two weeks from now +11:52 < pinchartl> 2016-09-14 at 09:00 BST / 10:00 CEST / 11:00 +11:52 < pinchartl> EEST / 17:00 JST +11:53 < neg> time works for me +11:53 < uli___> +1 +11:53 < dammsan> me too +11:54 < dammsan> we should have finalised the first slot of additional tasks by then +11:54 < dammsan> the due for first slot is 11/M and second slot is 12/M +11:54 < dammsan> same pattern as current quarter +11:55 < pinchartl> ELCE and LPC will fall in the first slot +11:55 < pinchartl> who will not attend ELCE ? and who will attend LPC (I will) ? +11:55 < morimoto> LPC is what ? +11:55 < morimoto> +11:56 < pinchartl> Linux Plumbers Conference +11:56 < dammsan> did not consider LPC yet +11:56 < pinchartl> in Santa Fe https://www.linuxplumbersconf.org/2016/ +11:56 < pinchartl> (November 1-4) +11:56 < dammsan> intend to attend ELCE and also Linuxcon +11:56 < pinchartl> it will be collocated with the kernel summit +11:56 < pinchartl> anyone plans to attend the kernel summit by the way ? +11:57 < pinchartl> (I will) +11:57 < morimoto> Kobayashi will attend to LPC from OSD2 :) +11:57 < morimoto> I wil attend ELCE +11:57 < pinchartl> :-) +11:57 < pinchartl> neg: uli___: kbingham: how about you ? +11:57 < uli___> elce only. +11:58 < kbingham> ELCE only here ... +11:58 < neg> ELCE and if there is periperi stuff before LinuxCon I will also attend it +11:58 < morimoto> Oh, we can meet kbingham this time !! +11:58 < kbingham> I haven't booked flights yet - so Ican extend if needed. +11:58 < kbingham> but I'm booked in the Conference hotel. +11:59 < pinchartl> we need to decide whether to have a peripericon in Berlin sooner than later, but that's not a multimedia topic +11:59 < morimoto> I will go to Berlin 10/3 - 10/14 +11:59 < dammsan> i'll also be there those days +12:00 < pinchartl> I currently don't plan on attending LinuxCon but I can change my plans to some extent if needed +12:01 < dammsan> there is a deadline for cheaper conference tickets on 3rd btw +12:01 < morimoto> Maybe we can have MiniPeriCon if needed ? not FullPeriCon +12:01 < pinchartl> that's an option too, yes +12:02 < pinchartl> I think we're done for today +12:02 < pinchartl> I propose adjourning this meeting +12:02 < pinchartl> does anyone second ? +12:02 < neg> I'm happy to go also go 10/3 - 10/14 if there is meeting or stuff to be done (drinking beer is stuff) +12:03 < neg> seconded +12:04 < pinchartl> thank you +12:04 < pinchartl> have a nice day/evening everybody +12:04 < pinchartl> thank you for attending +12:04 < dammsan> thanks, you too +12:04 < morimoto> Thanks. +12:04 < neg> thanks all +12:04 < uli___> thank you -- cgit v1.2.3