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!