1 files changed, 164 insertions, 0 deletions
diff --git a/wiki/Chat_log/20160301-core-chatlog b/wiki/Chat_log/20160301-core-chatlog
new file mode 100644
index 0000000..62ab441
--- /dev/null
+++ b/wiki/Chat_log/20160301-core-chatlog
@@ -0,0 +1,164 @@
+Core-chat-meeting-2016-03-01
+
+10:01 < geertu> Hi all
+10:02 < geertu> Welcome to the wonderful world of Renesas Core SoC development
+10:02 < geertu> All set, Shimoda-san and Mr. Magnus are excused.
+10:02 < geertu> Agenda:
+10:02 < geertu> 1. Upcoming Gen3 development for the Core group,
+10:02 < geertu> 2. Status check for tasks from last meeting - what is remaining?
+10:02 < geertu> Topic 1. Upcoming Gen3 development for the Core group
+10:03 < morimoto> Hi
+10:03 < pinchartl> before we start, I'll have to leave in an hour, I'm sorry aobut that
+10:03 < pinchartl> so if there are topics you would like to keep secret for me, the last half hour of the meeting is the right time to discuss them
+10:04 < geertu> OK, we'll discuss the secret SH4 pwower area at the end fo the meeting ;-)
+10:05 < pinchartl> :-)
+10:05 < geertu> I'm working on massaging the SYSC power domain driver into shape
+10:05 < geertu> s/SYSC/R-Car SYSC/
+10:06 < pinchartl> thank you for that
+10:06 < pinchartl> it's a dependency for upstreaming VSP and FCP support on H3
+10:06 < geertu> horms: I assume (new) drivers/soc/renesas/ will go to arm-soc via your tree?
+10:07 < horms> I would assume it needs to not go via arm-soc. Can we arrange so either you or I send it directly to Linus?
+10:07 < geertu> Well...
+10:08 < horms> ok, perhaps i take that back
+10:08 < geertu> For SYSC power domains, there will be a hard dependency of the DT part on the driver part.
+10:08 < geertu> I think it's easier to order if both do to arm-soc via you.
+10:08 < geertu> s/do/go/
+10:09 < horms> sure, in that case it makes perfect sense
+10:09 < horms> to do as you suggest
+10:10 < geertu> Sorry, it seems I'm always the one who creates patch series with complex dependencies
+10:10 < horms> Thanks for dealing with the complexity :)
+10:10 < geertu> That's it from my side for now
+10:11 < pinchartl> not much to report on my side
+10:11 < geertu> Sorry, forgot one thing.
+10:11 < pinchartl> I'll review Niklas' DMA patches as I already mentioned
+10:12 < horms> From my side I need to get on to analusing IPMMU as Magnus requested in Lueven.
+10:12 < geertu> There are three pull-request from me waiting for action (pfc and clk)
+10:12 < neg> I would like to have a bit more to do for core. There is not much happening whith slave IOMMU+DMAC and not mutch to do with the DMAC erratas since the IPMMU issues on Gen3. Still need to check DMADAR setup on Gen3 however.
+10:12 < horms> Are we stuck on Vinod for DMAE again? I.e. what Magnus was worring about in Holsbeek?
+10:13 < geertu> horms: Vinod took the improtant patch
+10:13 < horms> superb!
+10:14 < geertu> neg: Anything in core/todo you're interested in?
+10:16 < pinchartl> neg: if you're bored there's something useful that could be done for IPMMU with Gen2
+10:16 < pinchartl> although it might be difficult
+10:16 < pinchartl> the datasheet mentions two register banks
+10:16 < pinchartl> for secure/non-secure modes
+10:17 < pinchartl> and we don't really know how they work
+10:17  * horms needs to change locations. I'll leave this client running and check the scrollback in about 5min when I get to the other end. Sorry about this, time got away from me.
+10:17 < neg> geertu: I do not understand all bullets but I would love to do some small PM or clock stuff to learn more
+10:17 < pinchartl> I tried booting H2 and M2 in both secure and non-secure mode (but might have failed doing so) and it didn't make a difference from an IPMMU driver point of view
+10:18 < pinchartl> understanding what's going on would be useful, I expect it will come and bite us back at the worst possible moment
+10:19 < neg> I could look at that
+10:20 < pinchartl> it's just an idea, if there's anything more important/interresting feel free to ignore me :-)
+10:20 < neg> But I would also like something that could give me a patch to put in my next report :)
+10:20 < geertu> neg: r8a779[0-4],v4.6,plan,?,Start adding dmas pointing to all SYS-DMAC engines
+10:21 < geertu> neg: lots of patches :-)
+10:21 < neg> geertu: sounds good :)
+10:23 < neg> I can also have a go at the secure/non-secure IPMMU modes and see if I can understand them
+10:26 -!- horms_ [~horms@penelope-musen.kanocho.kobe.vergenet.net] has joined #periperi
+10:28 < horms_> I'm on the other side now.
+10:30 < geertu> Dark side of the force?
+10:31 < morimoto> geertu: Quick question
+10:31 < morimoto> BSP team want to have PFC "Driving Ability" and "Pull UP" feature. Are these under control ?
+10:31 < horms_> geertu: yes!
+10:33 < geertu> PFC,v4.6,plan,ulrich,add r8a7795 bias support
+10:33 < geertu> There's no task for "Driving Ability" yet.
+10:34 < geertu> Any status update?
+10:34 < morimoto> No, but BSP team want to have it
+10:34 < morimoto> Not urgent, but
+10:34 < geertu> uli___: ?
+10:35 < uli___> no update there
+10:36 < morimoto> OK, thanks. No stress
+10:36 < geertu> neg: https://lists.vergenet.net/private/periperi/2015-September/000784.html provides context for that task
+10:37 < geertu> Added PFC,v4.7,plan,?,add r8a7795 drive-strength support
+10:37 < geertu> Any takers?
+10:38 < geertu> Seems we forgot to add that task at PeriPeriCon
+10:38 < pinchartl> I'll see if I can give it a go
+10:38 < geertu> OK, thx
+10:38 < neg> geertu: thanks
+10:39 < geertu> Let's hope people don't step in each other's toes with 1.8v, bias, and drive strength
+10:39 < geertu> s/in/on/
+10:41 < pinchartl> I might need help testing it thought
+10:41 < pinchartl> s/thought/though/
+10:42 < pinchartl> as I'll try to submit a patch set for the 17th of March
+10:42 < pinchartl> but will leave for Linaro Connect this Friday and will likely not take any Renesas board with me
+10:44 < pinchartl> this leads me to the next topic I wanted to discuss
+10:45 < pinchartl> I'll be at Connect next week. there will be quite a few ARM core developers there, is there anything I should bring up with them ?
+10:46 < geertu> Not from my side
+10:49 < geertu> Anyone else with topics for LC?
+10:50 < pinchartl> I already plan to try and talk to Arnd about the dma mapping API
+10:50 < horms_> not at this moment, the interaction with the ARM SoC maintainers is going pretty smoothly at this time
+10:50 < neg> speak well of my {map,unmap}_resource :)
+10:50 < horms_> If I met Arnd or Olof I'd ask them what they'd like us to be doing that we aren't doing
+10:50 < geertu> I don't think Vinod will be there, will he?
+10:52 < pinchartl> horms_: I'll try to do that
+10:52 < pinchartl> geertu: not that I know of
+10:54 < horms_> pinchartl: thanks
+10:54 < geertu> morimoto: Laurent and I have a question about r8a7795
+10:54 < geertu> morimoto: Does it have SH4, or not?
+10:55 < pinchartl> horms_: you're welcome
+10:55 < geertu> morimoto: It has mostly disappeared from the datasheet in 0.5 (but e.g. RT-DMAC is still there)
+10:55 < pinchartl> morimoto: and does it have an A3SH power domain ?
+10:56 < pinchartl> geertu: even if the SH4 is still there, could we leave the A3SH power domain out for now, or do you consider that blocking for your SYSC patch series on H3 ?
+10:57 < geertu> pinchartl: We can leave it out. The SH4 is not in DT, and A3SH would be in C (or not) after the rework.
+10:57 < pinchartl> sounds good to me
+10:58 < morimoto> geertu: about SH4, it seems option. But we don't know what does this "option" mean
+10:59 < geertu> morimoto: And you cannot check for its presence in the Product Register (PRR), as that contains ARM cores only (CA57/CA53/CR7)
+10:59 < geertu> pinchartl: I'm also wondering if the SH4 got disabled by the firmware update we did at PeriPeriCon.
+11:00 < pinchartl> geertu: good question
+11:01 < geertu> pinchartl: Anyway, you have to leave now, right?
+11:01 < morimoto> geertu: do you need to use it ?
+11:01 < pinchartl> geertu: yes, sorry about that
+11:01 < geertu> morimoto: No, we don't need to use it.
+11:02 < pinchartl> morimoto: we don't, but while testing Geert's SYSC patch series, I found out the system would freeze due to the driver trying to disable the A3SH power domain
+11:02 < pinchartl> geertu: could be useful to check the boot loader sources to see if it touches that power domain
+11:02 < geertu> morimoto: But Laurent found out the A3VC power area (which he needs for multimedia) fails to power up if the A3SH power area was touched before.
+11:03 < morimoto> Hmm... So you want to know detail of it to HW team ?
+11:03 < geertu> morimoto: yes please
+11:04  * pinchartl is gone
+11:04 < pinchartl> have a nice day/evening
+11:04 < geertu> thx, bye!
+11:06 < morimoto> geertu: can you please send me detail mail about that ? It can help me to ask HW team
+11:07 < geertu> morimoto: Sure, I'll send an email to you
+11:07 < morimoto> thank you
+11:08 < geertu> Topic 2. Status check for tasks from last meeting - what is remaining?
+11:09 < geertu> https://osdr.renesas.com/projects/linux-kernel-development/wiki/Core-todo-list
+11:09 < geertu> I did some updates yesterday, cfr. the invitation email
+11:10 < geertu> Any other updates?
+11:11 < geertu> I guess I can start postponing unfinished tasks for v4.6 to v4.7?
+11:11 < neg> I don't have much to tell since last meeting, no feedback yet on slave IOMMU+DMAC and running tests on DMAC errata
+11:14 < morimoto> geertu: does upstream already have "Reset"  ?
+11:15 < geertu> morimoto: No, AFAIK no work has been done on that
+11:15 < morimoto> OK, thanks
+11:15 < horms_> geertu: anything for my tree should be moved to v4.7
+11:15 < geertu> morimoto: Is this system reset (reboot)?
+11:15 < morimoto> I think so
+11:16 < geertu> Perhaps Wolfram's watchdog timer works for that (perhaps UP only)?
+11:16 < geertu> I don't know he has tried on H3
+11:17 < morimoto> geertu: OK thanks
+11:19 < geertu> Anything else to report
+11:19 < geertu> Anything else to report?
+11:19 < morimoto> nothing from me
+11:19 < horms_> nor me
+11:19 < geertu> Sorry, one more thing from me.
+11:20 < geertu> It seems shmobile_defconfig now always triggers the (RCU related?) lock-up on Koelsch.
+11:21 < horms_> using which branch/tag ?
+11:21 < geertu> It may not (always) happen with Simon's tree, but as soon as you add more stuff from -next it fails.
+11:21 < geertu> Today's renesas-drivers (to be released soon)
+11:21 < horms_> ok
+11:22 < horms_> sounds painful
+11:23 < geertu> It doesn't happen with my usual config, which has more debugging options.
+11:23 < geertu> Wolfram saw it, too, on Lager
+11:23 < neg> I can test it on my koelsch once you release renesas-drivers
+11:24 < horms_> I guess its a bit tricky to bisect if its not always reliably triggered
+11:25 < geertu> I bisected it to an innocent RCU change
+11:25 < geertu> Reverting that did fix the issue
+11:25 < horms_> Ok, but is it the root cause, or just uncovering a deeper problem?
+11:25 < geertu> But it shouldn't.
+11:26 < geertu> Magnus thinks it's an issue with our timers.
+11:26 < horms_> He usually deos :)
+11:27 < geertu> If it would happen relibably on kzm9g, I could use JTAG
+11:30 < horms_> Ok, it sounds like we need some more data
+11:30 < horms_> I'll also try testing renesas-drivers on my Koelsch (and other boards)
+11:31 < horms_> I need to depart shortly. Was there anything more to discuss?
+11:31 < geertu> No, we're finished.
+11:32 < geertu> Thanks for joining!