Merge remote-tracking branch 'gitlab/wiki' into HEAD

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