summaryrefslogtreecommitdiff
path: root/projects/linux
AgeCommit message (Collapse)Author
2021-10-08projects: linux: io: update tasks after meeting 20211007Wolfram Sang
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2021-09-15projects: linux: io: TPU and I2C updatesWolfram Sang
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2021-09-14projects: linux: io: V3U and SDHI updatesWolfram Sang
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2021-09-13Auto-update sweep for v5.15-rc1Geert Uytterhoeven
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2021-09-09projects: linux: io: further updatesWolfram Sang
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2021-09-09projects: linux: io: refactor and update V3U RPC taskWolfram Sang
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2021-09-02projects: linux: io: update tasks after meeting 20210902Wolfram Sang
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2021-08-11projects: linux: io: first updates after summer holidaysWolfram Sang
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2021-07-13projects: linux: core: Mark "RCAR3: Enable full cpufreq and voltage scaling" ↵Geert Uytterhoeven
Done Cpufreq, voltage scaling, and boost support for Z clocks on R-Car Gen3 has been upstreamed. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
2021-07-13projects: linux: core: Mark "add r8a77961 support (core)" DoneGeert Uytterhoeven
Support for R-Car M3-W+ core components has been upstreamed. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
2021-07-13projects: linux: core: Mark "dt-bindings conversion to json-schema (Core)" DoneGeert Uytterhoeven
All Device Tree bindings for Renesas core components have been converted to json-schema. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
2021-07-13projects: linux: core: Mark "CLK; Implement .determine_rate() callback" DoneGeert Uytterhoeven
All Renesas clock drivers have been converted from .round_rate() to .determine_rate(). Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
2021-07-13projects: linux: Get rid of patchwork linksGeert Uytterhoeven
Patchwork links are not super stable. Replace them by upstream commit IDs or lore links where possible. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
2021-07-12Auto-update sweep for v5.14-rc1Geert Uytterhoeven
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2021-06-17projects: linux: io: update tasks after meeting 20210617Wolfram Sang
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2021-06-02Auto-update sweep for v5.13-rc4 and next-20210602Geert Uytterhoeven
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2021-06-02projects: linux: core: pinctrl: Update statusGeert Uytterhoeven
VIN g8/high8 is now upstream. R-Car H3 ES1.x is still to be handled. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2021-05-20linux: bsp-41x: non-target: move optee changesWolfram Sang
Quoting bsp392_tee_driver.yaml: "It's difficult to refactor this driver for upstream. So, mark Abandoned" Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Acked-by: Marek Vasut <marek.vasut+renesas@gmail.com> Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
2021-05-19projects: linux: mm: Update json-schema conversionsGeert Uytterhoeven
New conversions have been posted: - imr, - jpu.
2021-05-19projects: linux: mm: Update json-schema conversionsGeert Uytterhoeven
New conversions have been merged upstream: - video-interface-devices, - renesas,dw-hdmi, - renesas,du, - renesas,drif. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2021-05-18Auto-update sweep for next-20210518Geert Uytterhoeven
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2021-05-11linux: bsp-41x: move KingFisher board items to proper placeWolfram Sang
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2021-05-11linux: bsp-41x: move minor items to proper placeWolfram Sang
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2021-05-11linux: bsp-41x: move CAN items to proper placeWolfram Sang
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2021-05-11linux: bsp-41x: move PCI items to proper placesWolfram Sang
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2021-05-11linux: bsp-41x: non-target: Move R-Car H3/M3-W OPPs table-{1-7} for cpu devicesGeert Uytterhoeven
OPPs table-{1-7} are related to AVS, which is tagged "This is just internal code" elsewhere. The included voltage correction fix for R-Car M3-W has been posted. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
2021-05-11linux: bsp-41x: non-target: Move DTS changes for memory and/or dma-rangesGeert Uytterhoeven
There is no need to keep multiple separate DTS files to accomodate board variants that differ only in memory configuration: U-Boot will update memory nodes and dma-ranges properties accordingly. See commit b3db7be4e3726092 ("ARM: renesas: Update Gen3 PCIe dma-ranges before boot") in v2019.10-rc2 / rcar-3.10.0.rc1 and later. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
2021-05-11linux: bsp-41x: non-target: Move commits cherry-picked from upstreamGeert Uytterhoeven
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
2021-05-11linux: bsp-41x: non-target: Move DMACs in R-Car V3U DTSGeert Uytterhoeven
SYS-DMAC support for R-Car V3U is already upstream. RT-DMAC has no Linux users. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
2021-05-11linux: bsp-41x: non-target: Move UIO and OSAL changesGeert Uytterhoeven
UIO and OSAL are not intended for upstream. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Much-appreciated-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
2021-05-11linux: bsp-41x: non-target: Move RMSTPCR() register offset fixGeert Uytterhoeven
The Realtime Module Stop Control Register offsets are unused, and planned to be removed. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
2021-05-11linux: bsp-41x: non-target: Move R-Car H3/M3-W/M3-N DDR2400/2800 supportGeert Uytterhoeven
Not documented in Hardware User's Manual Rev. 2.20. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
2021-05-11linux: bsp-41x: non-target: Move rcar-dmac warning fixGeert Uytterhoeven
Rejected by driver author, cfr. for bsp392_dmaengine_rcar-dmac.yaml. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
2021-05-10projects: linux: io: Update json-schema conversionsGeert Uytterhoeven
New conversions have been posted: - i2c-rcar, - iic-emev2, - rmobile-iic, - riic, - mmcif, - rcar-canfd, - rcar-can, - rcar-gen3-phy-pcie, - rzn1-spi, - tpu. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2021-05-10projects: linux: core: Update json-schema conversionsGeert Uytterhoeven
New conversions have been posted: - sysc-rmobile (v2), - emev2-smu, - r9a06g032-sysctrl. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2021-05-10Auto-update sweep for v5.13-rc1Geert Uytterhoeven
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2021-05-03projects: linux: core: Add task for R-Mobile APE6 SMP supportGeert Uytterhoeven
Patches were posted as RFC. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2021-05-03projects: linux: core: Spelling s/seconary/secondary/Geert Uytterhoeven
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2021-04-30linux: bsp-41x: move SDHI items to proper placesWolfram Sang
Acked-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2021-04-29linux: bsp-41x: non-target: found some more candidatesWolfram Sang
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2021-04-23linux: bsp-41x: non-target: added some entries related to internal codeWolfram Sang
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2021-04-23linux: io: add TPU & PWM task for V3UWolfram Sang
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2021-04-23projects: linux: io: updates for W16Wolfram Sang
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2021-04-19linux: mm: gmsl: Record v3 and v4Jacopo Mondi
Record v3 and v4 of the GMSL reliability work. Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
2021-04-19linux: mm: Record max9286 eagle integrationJacopo Mondi
Record the links of v3 and v4 series. Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
2021-04-15projects: linux: io: updates up to W15Wolfram Sang
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2021-04-14linux: bsp-41x: move Thermal items to proper placesWolfram Sang
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2021-04-13linux: bsp-41x: move I2C items to proper placesWolfram Sang
Either non-target, or a new upport task. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2021-04-09linux: bsp-41x: move RAVB items to proper placesWolfram Sang
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2021-04-08projects: linux: io: updates up to W14Wolfram Sang
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
generated by cgit v1.2.3 (git 2.25.1) at 2025-01-06 21:20:59 +0000
rcar-core.c is a nice example: 09:11 < geertu> vin->info = of_device_get_match_data(&pdev->dev); 09:11 < geertu> attr = soc_device_match(r8a7795es1); 09:11 < geertu> if (attr) 09:11 < geertu> vin->info = attr->data; 09:12 < wsa_> so, with me being on the road already... 09:12 < shimoda> wsa_: :D 09:12 < wsa_> dammsan: can you give me remote access to H3 ES2.0 Salvator-XS? So, I can check stuff remote at least 09:13 < shimoda> Marex: it's difficult to me (my skill and Renesas office rule) 09:13 < horms> geertu: I am confused now. I see that is an exmple of using soc_device_match. And indeed there are already examples in the SDHI driver. But I thought that we decided to use compat strings for the case in question? 09:13 < geertu> horms: You can start with of_device_get_match_data() 09:14 < Marex> shimoda: ah :) 09:14 < geertu> If needed later, you add the next 3 lines enabling soc_device_match(), but needing no further driver logic change 09:14 < horms> Oh, I see. Very nice. 09:15 < wsa_> So, anything more from your side about the status updates? 09:16 < Marex> wsa_: PCIe32 got one reply ! 09:16 < wsa_> \o/ 09:16 < Marex> wsa_: and I keep resubmitting DA9063L patchset 09:17 < wsa_> Maybe some of the ARM core people are in Tokyo? It seems fastest to me to poke them personally, or get the right group together there... 09:17 < Marex> wsa_: let's see what happens at OSSJ ? 09:18 < Marex> wsa_: although, I doubt that 09:18 < wsa_> I share that feeling, but let's hope a bit... 09:18 < wsa_> okay, for the topic, there is only "add. tasks" from my side 09:18 < wsa_> although there is not much change for the IO group 09:19 < wsa_> pinchartl: notification for you :) 09:19 < wsa_> the focus is still on upporting and we should have increased base time for that 09:19 < wsa_> I'll contact you about upporting individually 09:19 < pinchartl> wsa_: I'm here :-) 09:20 < pinchartl> dammsan: ping 09:20 < pinchartl> we're missing Morimoto-san 09:20 < pinchartl> kbingham: ping 09:20 < wsa_> Add. tasks are possible on request which then are discussed by Renesas 09:20 < dammsan> wsa_: port 9006 is yours 09:20 < wsa_> but no request was made to me, and I don't see one urgent in my list 09:20 < wsa_> dammsan: thanks! 09:21 < kbingham> hola 09:21 < dammsan> pinchartl: whatsup? 09:21 < wsa_> so, doesn't look like add. tasks for IO 09:22 < shimoda> pinchartl: Morimoto-san has a trouble about his PC network setting on Ubuntu 18 :) 09:22 < wsa_> dammsan: unless there is something new I don't know up to now? :) 09:22 < pinchartl> dammsan: Wolfram mentioned additional tasks 09:22 < pinchartl> I requested that to be added to the agenda 09:22 < pinchartl> as this topic concerns all groups, should we discuss it now ? 09:23 < wsa_> Frankly, I am more interested in the base time distribution again 09:23 < dammsan> sure what do you want to know? 09:24 < pinchartl> dammsan: I want to know how we can get additional tasks working 09:24 < pinchartl> as in scheduled in time 09:24 < wsa_> horms: I assume you are so busy backporting LTSI that ravb upporting had to stand back? 09:24 < pinchartl> and not repeat the Q2.2 fiasco 09:24 < dammsan> well i think we need to do two things: 09:24 < pinchartl> we've had a lengthy e-mail discussion but that wasn't public, so I'd like to broaden the audience as I don't think I'm the only one to be bothered by this 09:24 < dammsan> 1) agree on quarterly schedule for meeting dates and additional due dates first 09:25 < horms> wsa_: correct 09:25 < shimoda> wsa_: after discuss about add. task, I'd like to ask you about i2c recovery. Did you see any issues (e.g. write data to a slave wronglty) on your R-Car environment? 09:25 < dammsan> 2) do task break out ahead of time 09:25 < horms> wsa_: also, I think that the ravb backporting is a very low yeild exercise 09:25 < dammsan> pinchartl: who else is bothered? 09:25 < pinchartl> kbingham: the mic is yours :-) 09:26 * kbingham has just about caught up wit hthe mornings mails ... 09:26 < pinchartl> who thinks additional tasks work just fine, and who tihnk they don't ? 09:26 < pinchartl> s/tihnk/thinks/ 09:26 < wsa_> shimoda: sure! 09:26 < kbingham> dammsan, I agree where you said this needs an F2F ... and fortunately one is coming up :) 09:26 < kbingham> Lets make sure we have time :) 09:26 < wsa_> horms: "low yield" means most patches are not suitable for upstream? 09:26 < dammsan> unfortunately not all members are present 09:27 < geertu> Personally, I've never been a big fan of additional tasks. 09:27 < horms> wsa_: yes, I think so 09:27 < horms> But I'll go over them again 09:27 < kbingham> Essentially - for me -the *big* problem is the 'rigid square wave workload' which it causes me. 09:27 < pinchartl> I've never been a big fan of additional tasks either. they were a minor nuisance when they were introduced, but they got more and more annoying over time as they got split in two batches per quarter, and we always got late negotiating them 09:28 < wsa_> "square wave workload" :D 09:28 < kbingham> But in particular - where the due dates are fixed, but tasks are always started late. 09:28 < kbingham> I realise that this last AT is a bit of a special case - but my concerns with planning have started long before. 09:28 < uli___> if i may weigh in: i like that additional tasks tell me what to do; i'm not a self-starter when it comes to work... 09:29 < uli___> the contractual framework is secondary to me 09:29 < kbingham> And it's just this one has been a cliff-edge drop for me :( 09:29 < geertu> kbingham: One very important thing to consider is that this is a prototype 09:29 < dammsan> so historically they were created to allow lower latency operation for our group 09:29 < geertu> which means many more unknowns than "normal" additional tasks 09:30 < dammsan> as opposed to have all the fixed tasks agreed on 3 months ahead 09:30 < pinchartl> dammsan: they have created a much higher latency 09:30 < geertu> IMHO they increase latency. 09:30 < dammsan> sure 09:30 < dammsan> but how can we keep the quality and perform development (not single patch wanking) and reduce paper work? 09:30 < geertu> If something is urgent, there may not be any base time available at that moment, as ATs have a fixed deadline, and thus preempt any base work 09:31 < kbingham> uli___, I also like that an AT specifies what to do - but in the latest case - that didn't happen - until it was too late for me to realistically be able to deliver that. 09:31 < pinchartl> in my opinion, they only advantage in additional tasks, and the reason why they have been introduced, is to give a stick to Renesas to hit developers who don't deliver. with fixed deliverables and fixed due dates the work has to be completed, no excuse 09:31 < pinchartl> apart from that I see no use for additional tasks 09:32 -!- morimoto [~user@relprex2.renesas.com] has joined #periperi 09:32 < geertu> An AT deadline around the closing of a maintainer's merge window causes patches to be delayed by one kernel release. 09:32 < geertu> pinchartl: +1 09:32 < wsa_> horms: if you could add what you currently know to the periupport list? so, we at least know which patches to "drop" 09:32 < dammsan> so we have been discussing dropping AT before 09:33 < dammsan> but at that point i requested some way to get plans from the group leaders 09:33 < horms> wsa_: sure, sorry for not having already done that 09:33 < pinchartl> dammsan: we can reduce paperwork and increase quality by dropping additional tasks completely and measuring performances to make sure we don't slow down (or even sleep) 09:33 < dammsan> this was last year i recall 09:33 < pinchartl> alternatively, we can keep fixed-price, fixed-term tasks, but with a higher latency. they *have* to be negotiated in advance 09:33 < dammsan> it is not a matter of increasing speed 09:34 < pinchartl> that is a contract has to be signed at least 2 months before the due date 09:34 < dammsan> it is a matter of improving visibility and communication 09:34 < jmondi> toothless jmondi's here 09:35 < dammsan> i will ask renesas if they can start considering 2 month delay 09:35 < dammsan> it is perfect for the last quarter of this year 09:35 < pinchartl> if the goal is to improve visibility and communication, then let's focus on that 09:35 < dammsan> until that time perhaps it is best that we drop additional tasks all together? =) 09:36 < dammsan> please note that some pipe lining is required 09:36 < pinchartl> dammsan: and I will also say that I agree we need to measure performances 09:36 < dammsan> one thing is the performance 09:36 < dammsan> another thing is to agree on what to do 09:37 < dammsan> i would like to have both 09:37 < kbingham> I'd like to not have high pressure workloads with short timescales :D 09:37 < dammsan> sure 09:37 < kbingham> I'd go join a tiger team if I wanted that ;D 09:38 < dammsan> but tell me how your 5 weeks can be split onto the existing slots 09:38 < neg> That is what I like about additional contracts, it provieds me with a clear channel from Renesas on what new task/feature is moste valuable for them and therefor I should focus on it. 09:38 < pinchartl> neg: I can only agree partially to that 09:39 < pinchartl> we are tasked with proposing additional tasks 09:39 < Marex> I have to admit, I like my kinda-free reign over U-Boot, since I can focus on doing what needs to be done when it needs to be done 09:39 < pinchartl> without being told what Renesas needs 09:39 < Marex> but maybe Im wrong :) 09:39 < pinchartl> so we try to guess 09:39 < kbingham> Marex, Do you not have additional tasks ? 09:39 < pinchartl> and then we are either told that the guess was right 09:39 < dammsan> he does but he prefers not to consume them 09:39 < pinchartl> or that it was wrong, in which case we are asked to guess again 09:39 < Marex> kbingham: I do, but I can live with that 09:40 < dammsan> what a nice fellow =) 09:40 < pinchartl> neg: I don't count that as being told by Renesas what is valuable for them :-) 09:40 < dammsan> pincharl: you seem to think the content of the bsp up porting list is enough 09:41 < neg> pinchartl: agreed, sometime the planing and late scheduling/decision point for a add. task is messy and creates higher workload. All I'm saying is that for me the task once scheduled provieds value 09:41 < pinchartl> Marex: I think most of us would like to focus on what needs to be done when it needs to be done, with additional inputs from Renesas when they have specific urgent needs 09:42 < dammsan> so may i ask if fixing the quarterly dates ahead of time has any drawback? 09:42 < kbingham> dammsan, What benefit are you addding with fixed dates... 09:42 < dammsan> i am not saying it solves all the problems 09:42 < pinchartl> dammsan: do you mean the Q2.1 and Q2.2 due dates, as in Q+1.5 and Q+2.5 ? 09:42 < kbingham> the 'due dates' are already predictable ... 09:42 < dammsan> this means we are clear about the dates 09:43 < dammsan> yes and meeting dates for chat meetings 09:43 < dammsan> if we agree on these ahead of time 09:43 < pinchartl> kbingham: the due dates are not just predictable, they are fixed :-) 09:43 < dammsan> and yet we fail to schedule tasks, then we won't schedule any tasks 09:43 < kbingham> :) 09:43 < pinchartl> dammsan: but we have already agreed, haven't we ? 09:44 < dammsan> i thought we had agreed to the AT due dates somehow 09:44 < dammsan> but yet it seems that the discussion of no time available and conference timing seems to happen again and again =) 09:44 < geertu> dammsan: Agreed as in: yes, let's use the dates Jinso needs the deliverables? 09:44 < dammsan> so if we know ahead of time.. 09:44 < pinchartl> dammsan: no, the problem isn't conference timing, the problem is late scheduling 09:45 < kbingham> If I'm going to 'lose' 3 weeks of work - then I need to know in advance - so I can find another three weeks of work to fill that time. Or Hugo losses his college fund! 09:45 < pinchartl> conferences and other events happen from time to time 09:45 < pinchartl> I can handle them by myself 09:45 < dammsan> kbingham: sure understood 09:45 < pinchartl> if you give me 3 weeks of work 6 weeks ahead of the due date 09:45 < pinchartl> I'll work around the conference that happens during those 6 weeks 09:45 < dammsan> makes sense 09:45 < pinchartl> if you give me 3 weeks of work 3 weeks ahead of the due date, that won't be possible 09:45 < geertu> pinchartl: Now, if you have 2x3 weeks of AT... 09:46 < pinchartl> and that's what is happening all the time 09:46 < pinchartl> in the best case we get the AT for 3 weeks of work 3 weeks ahead of the due date... 09:46 < dammsan> that seems to be because we don't do bre 09:46 < pinchartl> sometimes it's even later 09:46 < wsa_> kbingham: Hugo should be a rich kernel developer at college time, or? ;) 09:46 < dammsan> akout early enough 09:47 < kbingham> wsa_, I'm hoping he'll be a kernel developer at primary school :D 09:47 < pinchartl> dammsan: what do you mean by not breaking out early enough ? 09:47 < dammsan> well 09:47 < dammsan> for instance this virtualization topic 09:47 < dammsan> i wish we could meet and discuss how to proceed with that 09:47 < dammsan> now we have not met so much recently 09:47 < dammsan> and when we met in san sebastian the purpose seemed more to be for hacking than planning 09:48 < dammsan> i would like to meet with group leaders (+ others maybe) to do some planning 09:48 < pinchartl> I don't think we could have planned work for Q2 2018 in detail in San Sebastien 09:48 < pinchartl> there are various ways to meet, face to face or online 09:48 < kbingham> dammsan, I get that it was a communications issue - but in the Virt task - I was only told that *I* was supposed to write the task descriptoin - well after the point at which I would have expected to start the task - - hence for me - it's just impossible to fit in to a schedule in this current instance. 09:49 < dammsan> ok but i got the impression that you wanted to do the task? 09:49 < dammsan> i was pleasantly surprised that you signed up =) 09:49 < dammsan> obviously it was a too big jump 09:49 < pinchartl> dammsan: in general I think most of us are willing to help with work that is considered to be important by Renesas or you 09:49 < pinchartl> that shouldn't be a surprise :-) 09:49 < geertu> Exactly. 09:50 < dammsan> sure 09:50 < dammsan> i feel that 09:50 < dammsan> thanks for your help 09:50 < geertu> kbingham: You should have had some idea of what the task as about when volunteering, right? 09:50 < dammsan> but how to plan? 09:50 < dammsan> (and break out) 09:50 < kbingham> I knew very little about the task. 09:50 < dammsan> (that makes you the brave man in the room) =) 09:51 < kbingham> We are trying to hunt in the dark for tasks to fit into slots. 09:51 < kbingham> From my perspective - laurent said that dammsan wants us to look into virtualisatoin topics ... 09:51 < dammsan> sorry for being unclear 09:51 < kbingham> And thus I was expeting a virt topic to fill my available slots 09:51 < kbingham> However - I was expecting it to have been planned early - and be clear so that I could ramp up 09:52 < dammsan> but we had not done enough break out 09:52 < dammsan> also i feel we are moving slowly 09:52 < dammsan> probably due to lack of resources 09:52 < kbingham> I don't even mind if it would take me longer than the available time slots to do the investigation / self learning / and ramp up - but for that to happen - 09:52 < kbingham> the task *must start weeeeeellll in advance* 09:52 < dammsan> i would love to ask geertu to focus on virt activities 09:53 < dammsan> but without AT i feel i cannot request stuff 09:53 < kbingham> I see AT time slots as time slots that I reserve in my planning for to allow Renesas to fill with tasks. 09:53 < kbingham> But they can't be booked or not booked with zero notice. 09:53 < dammsan> kbingham: that view makes sense 09:54 < dammsan> but the default IMO is unbooked unless otherwise agreed 09:54 < horms> dammsan: when you say break out, do you mean you think it would help if there were more face-to-face meetings between say yourself and group leaders? 09:54 < dammsan> horms: yes 09:54 < dammsan> thank you 09:54 < horms> ok, I see a farily obvious way to see if that helps 09:54 < pinchartl> dammsan: unbooked unless otherwise agreed isn't something I can agree on as long as we book at the last minute 09:55 < pinchartl> if you want that, then I want to be booked 3 months in advance 09:55 < kbingham> So I should assume that 6/12 weeks of my time are not scheduled - and find another customer to fill that time ? 09:55 < pinchartl> as Kieran said in an e-mail, you don't expect to call a builder for your house and have him show up the next morning 09:55 < dammsan> sure, that fits perfectly fine with current budget situation =) 09:56 < kbingham> Ok - if we have budget restrictions - can we be clear about that!? 09:56 < pinchartl> there were no budget restrictions for Q2, were there ? 09:56 < dammsan> sorry if that has not communicated enough 09:56 < dammsan> but ATs are not guaranteed to be filled 09:56 < pinchartl> dammsan: it has been communicated badly, as in "beware of the big bad wolf" 09:57 < dammsan> never has been, and they are getting closer to be more sparse if budget is going bad 09:57 < kbingham> (beware, followed by - but don't go away) 09:57 < dammsan> well 09:57 < dammsan> it was actually my proposal to renesas side to tell you in advance 09:57 < dammsan> before you signed your base contracts 09:57 < dammsan> that budget is looking bad 09:57 < dammsan> so you should look into other options if you want to sustain 09:58 < neg> I think the budget situation have been communicated and also that there are possibilities that not all additional task slots will be used. Is this not why the base time was adjusted? 09:58 < dammsan> of course i want to work to with you 09:58 < dammsan> neg: yes 09:58 < dammsan> but i can't control our budget 09:58 < kbingham> Ok - but if AT's are not to be filled - they need to be filled with something else 09:58 < dammsan> especially if i can't make plans to show to renesas side 09:58 < kbingham> and tha'ts not possible - if the AT is filled at the last minute 09:59 < pinchartl> dammsan: why have additional tasks for Q2.2 not been scheduled in time, as there was no budget restriction for that period ? 09:59 < dammsan> kbingham: we seem to have different ideas how the contracts work 10:00 < kbingham> dammsan, I agree :) 10:00 < dammsan> what says that there was no budget restriction that period? 10:00 < dammsan> i was asked to reduce cost 10:00 < dammsan> i asked to reduce travel 10:00 < dammsan> did not to to EU 10:00 < dammsan> now if other members ask renesas directly 10:01 < dammsan> and they change their mind over a week 10:01 < dammsan> then it is not my problem 10:01 < kbingham> It's a shame you could not come to EU brussels - as it would have been good to do F2F then... :( 10:01 < dammsan> i agree 10:01 < pinchartl> dammsan: when we discussed additional tasks for Q2.2 there was no budget issue that was brought up, and tasks were agreed on to fill slots (but too late to be completed on time) 10:02 < dammsan> i have no intention to reduce the slots just for the sake of it 10:02 < dammsan> but we need to know what to do before doing it 10:02 < dammsan> and like my old fried paul said 10:02 < dammsan> you don't pay contractors to learn 10:02 < dammsan> you pay contractors to do what they are good at 10:03 < dammsan> of course some ramp up time is needed 10:03 < dammsan> and acceptable 10:03 < dammsan> but either you can do what you say 10:03 < dammsan> or you cant 10:03 < kbingham> dammsan, I actually agree on that - 10:03 < dammsan> and if we cant agree before the due date 10:03 < dammsan> too bad 10:03 < kbingham> That's why I expected the virt work to be planned well in advance :) 10:03 < dammsan> sure 10:04 < dammsan> so we had a some kerfuffle there 10:04 < dammsan> and in general when it comes to task break out and planning that may happen 10:04 < dammsan> probably my fault as usual 10:04 < dammsan> =( 10:04 < dammsan> but i stand by that we need to know before we do it 10:04 < pinchartl> it's not that it may happen, it happens all the time :-( that's for me a clear indication that the process is wrong 10:05 < dammsan> sure 10:05 < dammsan> but ive asked for plans forever 10:05 < dammsan> i would like to improve the situation 10:05 < pinchartl> I can't make a plan without being able to allocate resources 10:05 < dammsan> well 10:05 < pinchartl> I can't say what we'll do and when we'll do it if I'm not given a predictable amount of development time 10:05 < kbingham> I think we're well in to the territory of best discussed F2F :) 10:06 < kbingham> which is conveniently in 2 weeks or less. 10:06 < dammsan> i would like to separate assignment from planning 10:06 < dammsan> also time required from planning 10:06 < dammsan> only focus on break out and dependencies 10:06 < dammsan> i would like to discuss this with group leaders 10:06 < dammsan> ahead of time 10:07 < dammsan> then from the result of that activity feed AT and base work 10:07 < dammsan> if we manage to move forward with base only then we can skip AT 10:07 < dammsan> but dropping AT without any plans seems insane to me 10:08 < dammsan> kbingham: sorry that it became a mess 10:08 < pinchartl> so how do we move forward ? 10:08 < dammsan> how can we proceed? 10:09 < dammsan> i proposed my two ideas to improve the planning 10:09 < pinchartl> my requirement is that anything with a fixed due date has to be scheduled (as in contracts signed) at due date - max(2 * duration, duration + 2 weeks) 10:09 < dammsan> dates ahead of time + separate planning and breakout 10:09 < pinchartl> (the numbers can be fine-tuned 10:09 < dammsan> pinchartl: i want to agree as early as you 10:10 < dammsan> but we need to work together to break out stuff 10:10 < dammsan> and say that we are late 10:10 < dammsan> what happens then? 10:10 < dammsan> i don't want to be late 10:10 < dammsan> but if we end up there anyway?