diff options
Diffstat (limited to 'wiki/Chat_log/20151215-core-chatlog')
| -rw-r--r-- | wiki/Chat_log/20151215-core-chatlog | 492 |
1 files changed, 492 insertions, 0 deletions
diff --git a/wiki/Chat_log/20151215-core-chatlog b/wiki/Chat_log/20151215-core-chatlog new file mode 100644 index 0000000..6e76672 --- /dev/null +++ b/wiki/Chat_log/20151215-core-chatlog @@ -0,0 +1,492 @@ +Core-chat-meeting-2015-12-15 + +10:03 < geertu> Agenda: +10:03 < geertu> 1. Upcoming Gen3 development for the Core group, +10:03 < geertu> 2. Status check for tasks from last meeting - what is remaining? +10:03 < geertu> 3. SMP enablement on Gen3 +10:03 < geertu> 4. Cache enablement on Gen3 +10:03 < geertu> 5. DMA-Engine framework development and SYS-DMAC on Gen3 +10:03 < geertu> Topic 1. Upcoming Gen3 development for the Core group +10:05 < geertu> Nothing new, good ;-) +10:05 < dammsan> FYI, my plan is to push out a bunch of IPMMU patches for r8a7795 soon +10:05 < geertu> Nice! +10:06 < dammsan> Apart from that, I'd like to test them with the DU - but it was dropped in a recent renesas-devel release +10:06 < geertu> Yeah, too many issues with the media tree +10:07 < dammsan> understandable!! +10:07 < geertu> As I dropped media-next, perhaps you can just "git fetch git://linuxtv.org/pinchartl/media.git vsp1-kms-20151206 && git merge FETCH_HEAD~3" yourself? +10:08 < dammsan> i may simply not move forwards +10:08 < dammsan> for this test case +10:08 < geertu> That's another solution ;-) +10:08 * geertu shuffles agenda topics +10:08 < dammsan> i'm yet to poke with the external interrupt pins +10:08 < geertu> BUG_ON and NULL pointer dereference after merging media-next +10:08 < dammsan> yum +10:09 < geertu> and another one after merging in vsp1-kms-20151206 and solving the (many) conflicts +10:09 < dammsan> wolfram was talking about some lack of runtime pm in the gpio driver, do you know about that? +10:09 < dammsan> (sorry for not putting htat on the agenda) +10:09 < horms> dammsan: do you plan to follow up on "ARM: shmobile: IPMMU compat string SoC part number" > +10:09 < horms> ? +10:10 < dammsan> horms: i was actually not sure what the current state was - the DT binding was accepted I think? +10:10 < horms> i see an email from myself saying that i queued them up +10:11 < horms> i'll check +10:11 < geertu> dammsan: it's more a lack of runtime PM handling in the irq subsystem +10:11 < geertu> irq-renesas-irqc just does pm_runtime_get_sync() for its whole lifetime +10:11 < dammsan> geertu: sure - is it worth adding a task for that? +10:11 < dammsan> horms: thanks +10:12 < dammsan> geertu: yeah, irq-renesas-irqc is good and simple =) +10:12 < geertu> we can do the same in rcar-gpio, but then we loose al saving we did before +10:13 < geertu> AFAIK the Tegar people are working on it +10:13 < geertu> s/Tegar/Tegra/ +10:13 < dammsan> yeah, that seems a step in the wrong direction +10:13 < dammsan> we need some sort of handling for this +10:13 < horms> dammsan: ok, i see, i deffered them pending the driver update +10:13 < dammsan> eventually +10:13 < horms> has that happened? +10:14 < dammsan> the DT binding has been appied +10:14 < horms> ok +10:14 < horms> i was waiting on that +10:14 < dammsan> according to the maintainer +10:14 < dammsan> i'm not sure if it is in next or not +10:14 < horms> sorry if my email wasn't clear about me waiting on that +10:14 < dammsan> horms: sorry for not testing your gose GPIO yet +10:14 < geertu> Unfortunately the core ARM irqchip people don't seem to have much graps for Runtime PM and PM (power and clock) Domains +10:14 < dammsan> no worries +10:15 < horms> no problem! +10:15 < geertu> s/graps/grasp/ +10:15 < dammsan> s/for Runtime PM and PM/g +10:15 < dammsan> oh, and i found out that some of the IPMMU instances are located in power domains =) +10:16 < geertu> next-20151214 only has "renesas,ipmmu-vmsa" +10:16 < dammsan> so we need multiple IPMMUs with bindings together +10:16 < dammsan> it may take someeeeeeeeeeee time +10:17 < dammsan> geertu: how is the cpg-mssr driver merge looking? +10:17 < geertu> dammsan: Mike is hiding somewhere +10:17 < geertu> No review, no response to pull request +10:18 < geertu> (he's on #periperi now, so he may read everything we write ;-) +10:19 < uli___> morning. sorry, overslept... +10:20 * geertu added task "gpio-rcar,v4.6,noplan,?,Fix Runtime PM with GPIO interrupts +10:21 < dammsan> geertu: i ran into mike the other day, and he said he had looked over the code +10:21 < dammsan> lets see what happens +10:21 < geertu> dammsan: He's in Tokyo? +10:22 < dammsan> he was for a brief moment +10:22 < geertu> We should reduce his travel budget ;-) +10:22 < horms> dammsan: [off-topic] do you plan to revisit "[PATCH 00/08] clocksource: sh_cmt: DT binding rework"? +10:22 < dammsan> yes, eventually =) +10:23 < horms> thanks +10:23 < dammsan> and do the same for TMU +10:23 < dammsan> some of the DT bindings got acked +10:23 < horms> ok, for some reason TMU isn't on my radar +10:24 < dammsan> it may be low priority stuff +10:24 < horms> it would be moderately helpful if the series also covered r8a7793 and 92 +10:24 < dammsan> i should really deal with that when i resend +10:24 < dammsan> oh, +10:24 < dammsan> that reminds me +10:24 < dammsan> do we need soc-part-number for the DMAC devices in DT? +10:25 < dammsan> i recall that they were missing +10:25 < horms> what do you mean? +10:25 < horms> if you are talking about compat strings +10:25 < horms> they are either done, in progress or on my list +10:25 < horms> i can check on a case by case basis if you need the information +10:25 < geertu> [PATCH] dmaengine: rcar-dmac: Document SoC specific bindings +10:26 < dammsan> yeah, but thing have improved +10:26 < dammsan> thanks!! +10:26 < horms> slowly the gaps are being filled in +10:26 < dammsan> please ignore my comment about DT DMAC +10:26 < dammsan> very nice +10:27 < horms> with cmt, the r8a7793 appears to be using an undocmented per-soc binding. i was going to fix it but noticed you are planning to change the world +10:27 < dammsan> yeah, that's the idea +10:27 < horms> ... and i finally got around to asking you about it +10:27 * geertu still has Magnus' CMT series in his local tree +10:28 < dammsan> yes +10:28 < dammsan> will fix +10:30 < dammsan> geertu: is it possible to work around the GPIO issue in the CPG-MSSR driver somehow? +10:30 < dammsan> for short term +10:30 < dammsan> keeping the clock enabled or something +10:30 < geertu> Yes, but that only helps r8a7795 +10:30 < dammsan> i'm mainly concerned about that one for the short term +10:31 < dammsan> it is not super important +10:31 < dammsan> but i'd like the r8a7795 code to be rock solid +10:31 < geertu> Oops, next doesn't have CLK_ENABLE_HAND_OFF yet +10:32 < geertu> So if you add the GPIO clocks to r8a7795_crit_mod_clks[], they won't be registered +10:32 < geertu> and rcar-gpio won't work at all +10:33 < dammsan> ok, i was hoping on just increasing their use count temporarily +10:33 < dammsan> but no big deal +10:34 < geertu> yeah, that's what renesas-cpg-mssr.c really should do if CLK_ENABLE_HAND_OFF is not enabled, but I took a shortcut, as it doesn't matter for intc-ap +10:34 < geertu> Topic 2. SMP enablement on Gen3 +10:34 < geertu> Seems we have it ;-) +10:35 < geertu> It works for the CA57s +10:35 < geertu> Haven't tried Dirk's newer patch for CA53 yet +10:35 < horms> ok, gerat +10:35 < geertu> (does anyone know who Dirk Behme is?) +10:35 < dammsan> so i'd like to order the enablement here somehow +10:35 < horms> no +10:36 < dammsan> because the cache, dmac and smp tie together +10:36 < dammsan> also, for SMP, if we enable CA53 then the system will become strange +10:36 < horms> i was kind of expecting some feedback to be given to dirk... +10:37 < geertu> big.LITTLE is strange? :-) +10:37 < dammsan> unless the big little patch stack has been merged +10:37 < dammsan> is the scheduler aware yet? +10:37 < dammsan> last time i bother checking ARM assigned summer interns to the scheduler work +10:37 < geertu> I don't know. There should be zillions of big.LITTLE SoCs in use by now +10:38 < dammsan> running upstream? +10:38 < dammsan> on r8a7790 we worked around it by only enabling the Big cores +10:38 < dammsan> by default +10:38 < dammsan> and if little boot mode was selected we used little only +10:38 < dammsan> this may not be needed with the current scheduler +10:39 < dammsan> but we should check before enabling both big + little +10:39 < geertu> Does it matter much that the scheduler is aware? +10:39 < geertu> I guess 4xCA57 + 4xCA53 is better than 1xCA57 +10:39 < dammsan> if you execute something and it is not deterministic +10:39 < dammsan> and the tasks do not migrate +10:39 < dammsan> then it turns to poo IMO +10:40 < dammsan> I think the end goal should be 4 + 4 +10:40 < dammsan> or whatever is on other Gen3 SoCs +10:40 < dammsan> so i feel we need to control the enablement somehow +10:41 < dammsan> but maybe you guys are already doing that, and i'm lost as usual? =) +10:41 < dammsan> what is the opinion? +10:41 < horms> I was hoping for feedback from you +10:41 < dammsan> i see +10:42 < horms> my opinion is, as yours, that we should be careful +10:42 < dammsan> i've been overfocusin on IPMMU due to sudden customer demand... +10:42 < dammsan> and i think i shared some "long term" plan for our upstream development +10:42 < horms> but that we should communicate our plan/concerns to dirk +10:42 < dammsan> and SMP is not happening until next year +10:42 < horms> i did queue up the CA57 patches +10:43 < horms> i can (quickly) drop them for v4.5 if needed +10:43 < dammsan> i don't see any reason to rush +10:43 < dammsan> i think we need a plan =) +10:43 < dammsan> thanks for queuing up things btw +10:43 < horms> i was planning to queue up the CA53 patches for v4.6 unless there was some feedback +10:43 < horms> so i also agree that there is no rush +10:43 < horms> but o think we need to communicate a bit with dirk +10:44 < horms> possibly refocussing his energy elewhere +10:44 < dammsan> i would like to ask someone to check SMP and big.little +10:44 < geertu> dammsan: Do you know a simple test to check if the scheduler is aware? +10:45 < dammsan> geertu: no turn-key, but say spawning off twice the number of benchmark jobs as number of cpus, and see how it behaves? +10:45 < dammsan> if you run with two cores - one big and one little, and spawn off one benchmark job, if it gets stuck on the little one you are screwed +10:46 < dammsan> busy tasks should migrate to the faster cores +10:46 < horms> because it will be slow? +10:46 < geertu> ok, will try something +10:46 < dammsan> yes, and the other big core will be fast and idle +10:46 < horms> ok +10:46 < horms> so how about someone (e.g. me) communicates this with dirk +10:47 < dammsan> that's of course fine with me +10:47 < dammsan> but i think we still need a plan +10:47 < horms> we can deffer his patches until we get a better idea of what their implicatinos are +10:47 < geertu> horms: Please let me try it first +10:47 < horms> geertu: sure, no problem +10:47 < horms> I'm also quite ok with you responding to him +10:47 < dammsan> so one idea can be to get SMP support working as first step +10:48 < dammsan> on big cores +10:48 < horms> isn't that what we now have? +10:48 < dammsan> in a perfect world +10:48 < dammsan> but there are dependencies on timers +10:48 < dammsan> on firware +10:48 < dammsan> cpu hotplug +10:48 < dammsan> kexec +10:48 < dammsan> kernel command line parameters +10:48 < dammsan> ... +10:49 < dammsan> i highly doubt that everything is working +10:49 < dammsan> unless it is a x86 system +10:49 < horms> ok +10:49 < horms> so perhaps we partially have it +10:49 < dammsan> more testing is needed for sure +10:49 < dammsan> either merge (like you did) or topic branch +10:49 < dammsan> and then combine with some testing +10:50 < horms> the point is the merge is done +10:50 < dammsan> right +10:50 < horms> and we have a small window to change our mind +10:50 < dammsan> twhat is your opinion? +10:50 < horms> of course we can revert later +10:51 < dammsan> if you are ok with depending more on teh boot loader stack then i'm fine +10:51 < geertu> How do we know which boot loader stack we have? +10:51 < dammsan> good question +10:51 < geertu> horms: You said you saw one CPU only? +10:51 < dammsan> i kept my various versions in different directories +10:51 < horms> yes i did +10:51 < geertu> I was using my own tree, with my own config +10:51 < dammsan> but lately they seem to be aligned to yocto releases inside renesas +10:51 < horms> but i was using devel + cpg+mssr, not renesas-drivers +10:52 < dammsan> i think we should use the same boot loader stack ideally +10:52 < dammsan> so we may need to coordinate that as well +10:52 < dammsan> so what is a good plan i wonder...? +10:53 < dammsan> I think we should do a joint effort to update our boards after new year +10:53 < horms> is the implication that geert and I may be using different boot loaders? +10:54 < dammsan> i've used 3 different versions +10:54 < dammsan> one worked with IPMMU +10:54 < dammsan> i have not yet used SMP +10:54 < geertu> horms: that's what I'm wondering about, too +10:54 < horms> about the merge, i'm inclined to leave it unless we feel it will be harmful e.g. in terms of updates, in future +10:54 < horms> but i am happy to be convinced otherwise +10:55 < dammsan> horms: i think it is fine to include it if "maxcpus=1" works as on other architectures +10:55 < dammsan> so we have a simple way to boot with a single CPU only +10:55 < dammsan> if we end up with random crashes +10:55 < dammsan> on certain boards +10:56 < dammsan> or we can merge it regardless +10:56 < dammsan> if you are willing to deal with the potential trouble... +10:56 < dammsan> its up to you really +10:56 < dammsan> geert? +10:56 < geertu> I'd be surprised if "maxcpus=1" wouldn't work, but let's try +10:56 < dammsan> do you have any idea how to order SMP + cache + DMAC +10:56 < geertu> cache first +10:57 < geertu> (needed for SYSC PM Domains too) +10:57 < dammsan> ok, lets do that +10:57 < horms> geertu: could you try; i only see one CPU regardless +10:57 < geertu> which brings us to +10:57 < geertu> Topic 3. Cache enablement on Gen3 +10:57 < geertu> The cache is enabled automatically, I think +10:58 < dammsan> i listed it because it ties in with both the DMAC and the CPUs +10:58 < dammsan> apparently the IPMMU has some cache coherent support for page tables +10:58 < geertu> Presence in DT is just dressing up (ARM core viewpoint?), or hard requirement for SYSC PM Domains +10:58 < dammsan> otherwise the other devices require cache management by the CPU +10:59 < geertu> I don't follow that part +10:59 < geertu> There's already cache managment without an IPMMU? +10:59 < dammsan> each bus master device on the system +10:59 < dammsan> well +10:59 < dammsan> i mean, if we use say SYS-DMAC without IPMMU +11:00 < dammsan> we still need to manage the cache since the SYS-DMAC is behind the caches +11:00 < dammsan> that is true for most bus master devices +11:00 < dammsan> the only exception that i am aware of is the IPMMU page tables, but i think there is an errata =) +11:01 < dammsan> so my point is that there is a per-bus-master device coherent/non-coherent view +11:01 < dammsan> and maybe gray zone with different inner sharable / outer sharable domains +11:02 < dammsan> i think the only sane way to handle things for now is to assume that all devices are non-coherent +11:02 < dammsan> and opt-in if needed +11:03 < dammsan> geertu: about the PM domain and caches, why do you need the DT binding? +11:03 < dammsan> to restore state? +11:04 < geertu> dammsan: I don't need a binding, just a power-domains property pointing to the SYSC PM Domain +11:04 < dammsan> ok! +11:04 < dammsan> so caches first? +11:05 < dammsan> in the same way as SMP needs testing, I think we want some benchmarking with/without caches +11:05 < geertu> cfr. http://lists.infradead.org/pipermail/linux-arm-kernel/2015-June/348750.html +11:05 < geertu> Aren't the caches automatically enabled? +11:06 < dammsan> neat! +11:07 < dammsan> it depends on boot loader version +11:07 < dammsan> but i guess it should +11:07 < dammsan> for Gen2 we need to handle caches when doing CPU hotplug +11:07 < geertu> For gen3, we have arm,psci +11:07 < dammsan> on Gen3 i guess the PSCI bits do something magic for us +11:08 < dammsan> geertu: so your plan is to enable caches first? +11:09 < dammsan> or somehow hook them in according to your patch +11:09 < geertu> Without the caches in DT, my debug prints on Salvator-X still print +11:09 < dammsan> above +11:09 < geertu> L1-D: CCSIDR = 0x701fe00a: 32 KiB, 256 sets, 2 ways, 64 bytes/line, WB, RA, WA +11:09 < geertu> L1-I: CCSIDR = 0x201fe012: 48 KiB, 256 sets, 3 ways, 64 bytes/line, RA +11:09 < geertu> L2-U: CCSIDR = 0x70ffe07a: 2048 KiB, 2048 sets, 16 ways, 64 bytes/line, WB, RA, WA +11:09 < dammsan> i see +11:09 < dammsan> i don't recall if we are able to disable caches in the Kconfig for ARM64 +11:10 < geertu> and +11:10 < geertu> Detected PIPT I-cache on CPU0 +11:10 < geertu> Detected PIPT I-cache on CPU1 +11:10 < geertu> CPU1: Booted secondary processor [411fd073] +11:10 < geertu> Detected PIPT I-cache on CPU2 +11:10 < geertu> CPU2: Booted secondary processor [411fd073] +11:10 < geertu> Detected PIPT I-cache on CPU3 +11:10 < geertu> CPU3: Booted secondary processor [411fd073] +11:10 < geertu> Brought up 4 CPUs +11:10 < geertu> SMP: Total of 4 processors activated. +11:10 < geertu> CPU: All CPU(s) started at EL1 +11:10 < geertu> but +11:10 < geertu> Unable to detect cache hierarchy from DT for CPU 0 +11:11 < dammsan> hm +11:11 < dammsan> i wonder what juno says +11:11 < geertu> I'll run my memory speed benchmark... +11:13 * geertu notices that "maxcpus=1" works as expected +11:13 < horms> geertu: thanks! +11:13 < dammsan> yeah, thank you! +11:13 < horms> lets leave those patches in and revert them if the wheels fall off +11:14 < geertu> ok +11:14 < dammsan> horms: but wait with ca53? +11:14 < horms> yes +11:14 < horms> i have no plan to add them to v4.5 +11:15 < horms> and i will wait for some testing before considering them for v4.6 +11:15 < horms> of course our plan will evolve... +11:15 < horms> (or die!) +11:15 < dammsan> goooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooosounds good - thanks! +11:16 < dammsan> (darn my VM environment gets key stuck sometimes) +11:16 < horms> it got stuck in a goood place! +11:16 < dammsan> indeeed +11:17 < horms> btw, i am hoping to finish up at 19:30 +11:17 < dammsan> so what do we do about firmware update? +11:17 < dammsan> any idea? +11:18 < dammsan> horms: i want to discuss the DMAC framework bits too, but you may not care so much +11:18 < horms> well, presumably there is a procedure. perhaps morimoto-san can get us the new images etc... +11:18 < horms> dammsan: perhaps i can go away and come back +11:18 < horms> i only plan to give my son a bath +11:19 < dammsan> anything is fine with me really +11:19 < horms> ok +11:19 * geertu notices his MemSpeed test (which read/writes/copies increasing blocks of memory) shows no difference between L2 cache nodes present in DT or not +11:20 < dammsan> how much memory do you have on your system geert? +11:20 * geertu notices MemSpeed shows performance drops near the documented L1 and L2 cache sizes => L1 and L2 caches are enabled +11:20 < geertu> 1 GiB +11:20 < morimoto> horms: we have procedure for it +11:20 < dammsan> ok i see +11:20 < dammsan> you want to update the boot loader at some point +11:21 < dammsan> to enable 4 GiB and probably a different configuration for the interleave mode +11:21 < dammsan> which may affect the bandwidth +11:21 < horms> (i will wander off for a bit an come back) +11:21 < shimoda> i think we cannot use more than 1GiB on old boot loader +11:22 < geertu> RAM is ca 50% faster than on koelsch +11:22 < dammsan> 50% less? =) +11:22 < dammsan> good old half empty vs half full +11:23 < dammsan> on CA9 systems i noticed quite different speed for Single-core vs SMP +11:23 < shimoda> also ddr speed setting is slow (DDR1600?) +11:23 < horms> (phht; failed to wander off) +11:23 < dammsan> i suspect the coherency logic slowed things down, but i don't know for sure +11:24 < geertu> of course +11:24 < geertu> shared-override? ;-) +11:24 < dammsan> hehe +11:24 < dammsan> so boot loader update early 2016? =) +11:24 < dammsan> joint effort? +11:25 < dammsan> to keep coherent environemnt +11:25 < horms> how about +11:25 < horms> we stage it a bit +11:25 < geertu> and if it breaks, we send the boards to Japan for adding capacitors ;-) +11:25 < horms> in case it goes to poo +11:26 < geertu> Plus we may have regressions on different versions +11:26 < dammsan> s/may/will/g +11:26 < horms> also, if the EU people upgraded in Feb then they may have more immediate options for servicing +11:26 < horms> i agree we should get in sync +11:26 < horms> i just think its a bit dangerous if we all move at once +11:27 < dammsan> i agree +11:27 < horms> probably thouse in Tokyo should go first :) +11:27 < dammsan> i have updated files, but no time yet =) +11:28 < dammsan> you can add a task for me for next time =) +11:28 < horms> time,2015,magnus,plan,get some! +11:29 * geertu is waiting for the move to prototype +11:29 < geertu> next-20151215 has renesas,ipmmu-r8a7* +11:30 < horms> thanks +11:30 < horms> i pushed the integration changes +11:30 < dammsan> thanks!! +11:32 < dammsan> geertu: so whats the conclusion for the cache? need to figure out how to handle the DT topology? +11:32 < geertu> horms; will you disappear? +11:32 < horms> i will try +11:32 < geertu> dammsan: just add it? +11:32 < horms> and if so i will come back +11:33 -!- horms is now known as horms_away +11:33 < dammsan> geertu: sure, sounds good +11:34 < dammsan> so about the DMAC, i was wondering if we can ask neg for help +11:34 < dammsan> geertu: is it ok to move over to the DMAC topic? +11:34 < geertu> Topic 4. DMA-Engine framework development and SYS-DMAC on Gen3 +11:35 < dammsan> ok, so i noticed that we still have that IPMMU + DMAC framework limitation +11:35 < neg> I'm willing to help out here +11:36 < dammsan> i also hope that laurent can help us +11:36 < dammsan> i basically want us to focus on SYS-DMAC in the first quarter to improve the state +11:37 < dammsan> geertu: do you have any ideas for us? +11:37 < dammsan> more detailed plan or similar +11:38 < geertu> nfortunately not +11:39 < dammsan> in parallel i'd to focus on SCIF as well +11:39 < dammsan> so by the end of the quarter i'd like to run SCIF + DMAC + IPMMU with the loopback adapter +11:39 < dammsan> geertu: do you think that is feasible? +11:40 < dammsan> i'm about to post my IPMMU bits + prototypes for integration and DMAC +11:40 < geertu> yesm, if the hardware supports ot +11:40 < geertu> yes, if the hardware supports it +11:41 < dammsan> at least some part of the hardware will support it =) +11:44 < geertu> ok +11:44 < dammsan> feel free to search the linuxsh-dev list for "[PATCH] ARM: shmobile: IPMMU and DMAC prototype" +11:44 < dammsan> there is a reply from Laurent there +11:44 < dammsan> listing the issues we are having +11:45 < dammsan> geertu: i would like us to figure out which steps that are needed for DMAC + IPMMU support on a framework level +11:46 < dammsan> neg: can you find that patch and the reply? +11:46 < neg> sure +11:47 < dammsan> so the issue exists on older platforms too, so we can use gen2 boards too for this development +11:47 < neg> I can start to lookinto the issues Laurent brings up in that thread +11:47 < dammsan> the framework portion +11:47 < dammsan> that would be great +11:47 < geertu> Will ping Vinod... +11:48 < geertu> done +11:48 < dammsan> thanks! +11:48 < dammsan> did some visteon guy produce dmac changes too? +11:49 < dammsan> i wonder if we have any outstanding issue that neg can look into +11:50 < geertu> yes +11:50 < geertu> they are included in renesas-drivers +11:50 < geertu> topic/rcar-dmac-hamza-v3 +11:51 < dammsan> neg: congrats - more stuff! +11:51 < geertu> Of course "[PATCH] dmaengine: use phys_addr_t for slave configuration" is only the first step +11:51 < geertu> currently all drivers store virtual addresses there +11:52 < neg> ok I will start to dig in to it +11:53 < dammsan> thanks!! +11:54 < dammsan> that's all from my side +11:55 < geertu> Topic 5. Status check for tasks from last meeting - what is remaining? +11:56 < dammsan> everything for me =) +11:56 < geertu> I don't think anything has changed in the list +11:56 < neg> NDA papers for me :) +11:56 < geertu> So we're finished. Unless someone has something else to say (I have)? +11:57 < dammsan> yes, thats on me =) +11:57 < dammsan> i'm fine +11:57 < geertu> LinusW asked me to become official sh-pfc co-maintainer +11:57 < geertu> Laurent isn't here, and I don't know what will be in his next SoW +11:57 < dammsan> how do you feel about that? +11:57 < geertu> I feel fine about that +11:58 < dammsan> geertu: the idea is that he will have some core group task +11:58 < geertu> I'll do everything to get more pfc patches in ;-) +11:58 < dammsan> but it is up to you to assign +11:58 < dammsan> good idea =) +11:58 < dammsan> i guess M3 is on the horizon +11:58 < dammsan> with PFC +12:00 < geertu> good! +12:01 -!- horms_away is now known as horms +12:01 < geertu> Any other topics? (right on time, horms) +12:02 < dammsan> not from me +12:02 < horms> i looked over our old friend boot mode register +12:02 < horms> laurent has an idea to eliminate the idea for it being needed early for arch timer on gen2, that part seems ok +12:02 < horms> but its still needed early for cpg +12:03 < horms> i sent an email about it +12:03 < horms> I have also reworked things to use a binding etc... but there seems not much point in posting it if the "early" bit needs more discussion +12:03 < horms> i would also not be at all upset if someone had a burning desire to take over this task :^) +12:04 < dammsan> horms: haha +12:04 < dammsan> next core meeting why don't your bring laurent and we can hash it out? +12:04 < horms> iirc that and dirk were the topics i wanted to bring up +12:04 < horms> and we spoke about mr. dirk already +12:04 < geertu> I think next core meeting will be after v4.4? +12:04 < horms> i have no urgency :) +12:05 < horms> yes, i think laurent needs to be involved +12:05 < horms> either over email or a a chat meeting +12:05 < horms> geertu: perhaps you could invite him to the next one if its still haning in the air at that time +12:05 < dammsan> geertu: did we need any activity for CPG-MSSR driver merge again? +12:06 < geertu> dammsan: I can send a ping. Not more I can do, I'm afraid +12:06 < dammsan> geertu: if you ask him off list, please CC me +12:06 < geertu> him = Laurent? or Dirk? +12:06 < geertu> invite him = Laurent? or Dirk? +12:06 < dammsan> i can forward to my superiors +12:06 < dammsan> Mike +12:06 < horms> geertu: invite Laurent +12:07 < horms> geertu: I'm not suggesting inviting Dirk at this time +12:07 < horms> though it is an interesting idea for the future, now you mention it +12:07 < geertu> :aurent was invited, but he's in ca.us +12:07 < geertu> s/:/L/ +12:07 < horms> ok +12:07 < horms> he is a busy man +12:07 < geertu> Nah, he's asleep now ;-) +12:08 < horms> dammsan: do we have some sort of business relationship with Mike? +12:08 < dammsan> my superiors may have such a setup with his superiors +12:08 < horms> ok, i understand +12:08 < dammsan> so if we are blocked we should involve them +12:08 < horms> good to know +12:10 < dammsan> ok guys, i'm task switching now +12:10 < dammsan> see ya later +12:10 < geertu> For next core group chat, does Tuesday, January 5 sound OK? +12:10 < horms> jya ne +12:10 < neg> works for me +12:10 < shimoda> oops, at Jun 5, i will take day off +12:10 < horms> let me check +12:11 < geertu> Monday 4? +12:11 < horms> yes +12:11 < shimoda> at 4th is also day off, Im afraid +12:11 < dammsan> that is in the middle of japanese holidays +12:11 < horms> i will be on a plane on the evening of the 7th +12:12 < geertu> Sorry, didn't know that +12:12 < horms> pahapnese holidays aer most likely from the 29th - 3rd +12:12 < horms> Renesas may have their own schedule +12:12 < horms> wow, nice typo +12:12 < dammsan> heheh +12:12 < horms> Japanese holidays are... +12:13 < geertu> dammsan said in an email: In early 2016 I think we should resume meetings on or after January 6. +12:13 < dammsan> may i suggest the 6th? +12:13 < geertu> 6th is fine for me (actually all days of that week are fine for me) +12:14 < uli___> that's a holiday here, but i'm willing to make an exception :) +12:14 < horms> uli___: you can build up your appetite for your holiday lunch :) +12:14 < geertu> Epiphany is a legal holiday in the following provinces of germany: +12:15 < geertu> Baden Wuerttemberg, Bavaria, Saxony Anhalt +12:15 < uli___> aka the good ones :) +12:15 < neg> and in Sweden, but it works for me anyway +12:15 < geertu> Thanks for joining! +12:16 < geertu> Have a nice evening/day/night |