path: root/wiki/Chat_log/20151215-core-chatlog

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