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

1 files changed, 195 insertions, 0 deletions

diff --git a/wiki/Chat_log/20160216-core-chatlog b/wiki/Chat_log/20160216-core-chatlog
new file mode 100644
index 0000000..2634bf2
--- /dev/null
+++ b/wiki/Chat_log/20160216-core-chatlog
@@ -0,0 +1,195 @@
+Core-chat-meeting-2016-02-16
+
+10:02 < geertu> I think we are complete (Magnus is excuted by paperwork^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^Hsed)
+10:03 < horms> can we add a topic about ravb to the agenda if there is time?
+10:03 < geertu> Sure
+10:03 < horms> thanks
+10:03 < geertu> ravb or gpio? ;-)
+10:04 < geertu> Topic 1. Upcoming Gen3 development for the Core group
+10:04 < horms> either way :)
+10:04 < geertu> Magnus posted his INTC-EX series, and reposted CMT
+10:05 < geertu> I got sucked into SYSC PM Domains agai
+10:05 < geertu> s/agai/again/
+10:05 < geertu> as this became a blocker for media
+10:06 < pinchartl> sorry about that :-)
+10:06 < pinchartl> your patch series seems to work fine
+10:06 < pinchartl> I can read the VSP version registers
+10:06 < geertu> Great!
+10:06 < morimoto> Great !
+10:06 < pinchartl> haven't been able to test video processing yet though (and thus haven't tested the FCP) due to an unrelated problem in the media controller core
+10:07 < pinchartl> (I'll refrain from blaming Mauro)
+10:07 < geertu> So the PM domains are working.
+10:07 < pinchartl> (ah, wait, I did, damn :-))
+10:07 < pinchartl> at least for the VSP, yes
+10:07 < geertu> Before it was tested by (not) crashing when turning off CPU cores ;)
+10:07 < pinchartl> how do they interact with runtime PM btw ? the vsp1 driver doesn't support runtime PM, I assume that will make the power domain always on ?
+10:08 < geertu> Interesting, then the PM domain shold be turned off
+10:08 < geertu> What does /sys/kernel/debug/pm_genpd/pm_genpd_summary say?
+10:08 < pinchartl> I'll tell you in a minute
+10:10 < shimoda> i have a question about core/todo. it has the following todo, but I forget it :)
+10:10 < pinchartl> let's go on with the rest of the topics in the meantime
+10:10 < shimoda> SMP,v4.6,public,shimoda,Discuss SMP DT bindings with ARM SoC maintainers
+10:12 < geertu> On which mailing list was this discussed?
+10:13 < geertu> Ah, this is for Magnus' "[PATCH v3 00/09] ARM: shmobile: APMU DT support via SMP Enable method V3"?
+10:14 < pinchartl> (recompiling with CONFIG_PM_DEBUG enabled)
+10:15 < geertu> CONFIG_PM_ADVANCED_DEBUG=y
+10:16 < shimoda> geertu: sorry I don't know.. This topic was discussed at 2015-12-01, but I don't have the weechat log...
+10:17 < pinchartl> (recompiling with CONFIG_PM_ADVANCED_DEBUG enabled)
+10:18 < geertu> Can't find it in my 2015-12-01.log
+10:19 < horms> I have a log
+10:20 < pinchartl> https://paste.kde.org/pwe40pq96
+10:20 < pinchartl> the power domain is on
+10:20 < geertu> Cool, so it's indeed on if Runtime PM is not enabled in a driver, great
+10:21 < pinchartl> I'll enable runtime PM anyway
+10:22 < geertu> OK, thx
+10:25 < horms> I don't see any discussion of SMP in my log of the 2015-12-01 meeting. But there is some discussion in the 2015-12-15 meeting.
+10:27 < geertu> That involves PSCI for arm64.
+10:27 < geertu> The task was for Gen2
+10:28 < horms> ok
+10:28 < shimoda> thanks for the confirm
+10:28 < geertu> Originally it was targeted for v4.3.
+10:31 < geertu> I guess it's not super-urgent
+10:31 < geertu> shimoda: will you handle this?
+10:33 < shimoda> geertu: sorry i don't know about the detail. so, if possible, someone handles it.
+10:34 < geertu> It's about the bindings in "[PATCH v3 01/09] devicetree: bindings: Renesas APMU and SMP Enable method"
+10:35 < geertu> Personally, I don't think there's much to discuss.
+10:35 < geertu> Magnus just doesn't like the enable-method ;-)
+10:37 < geertu> Any other Upcoming Gen3 development for the Core group
+10:37 < geertu> ?
+10:37 < shimoda> geertu: thanks for the information, I will ask Magnus about it later F2F :)
+10:37 < horms> Was any progress made on the dmaengine issues we discussed in Holsbeek?
+10:38 < horms> Or is that a media topic?
+10:38 < geertu> OK, he'll be in the office tomorrow, IIRC
+10:38 < geertu> Vinod said he will accept the phys_addr_t patch
+10:38 < neg> Vinod move forward with dma slave config so I will push forward there
+10:38 < geertu> Not yet in his -next, though
+10:38 < pinchartl> it's still good news
+10:39 < pinchartl> neg: are you going to reply to his e-mail ?
+10:39 < geertu> Definitely
+10:39 < neg> pinchartl: yes
+10:40 < pinchartl> thanks
+10:40 < horms> ok so the status is: maybe good soon ?
+10:41 < horms> were we waiting on Vinod for other changes too?
+10:41 < neg> I'd say it looks good now that Vinod have accepted the approch
+10:41 < horms> ok
+10:41 < horms> Lets try and keep things going now the ball seems to be rolling in the right direction :)
+10:42 < neg> will post a new seris today and hope he picks up on it
+10:42 < horms> great
+10:43 < neg> horms: question, should I keep including the DT updates or have you queued them up?
+10:43 < horms> I have not queued them up; please keep including them
+10:43 < neg> ok
+10:44 < horms> I'd like to hold off on accepting them until the bindings are accepted. I take it that is not yet the case.
+10:45 < neg> ofc, I was unsure you told me you tentative queued them up :)
+10:45 < horms> oh, ok.
+10:45 < horms> what were the patch subjects?
+10:46 < neg> [PATCH v3 7/8] ARM: dts: r8a7790: add iommus to dmac0 and dmac1
+10:46 < neg> and I'm sorry you wrote deferred not tentative my bad
+10:46 < horms> ok, at least we agree :)
+10:47 < neg> other than that I hade a first go at the DMAC errta, got Laurents dmatest to work on gen2 but it fails for all channels on gen3 need to do more work there
+10:47 < pinchartl> all channels ? nice :-)
+10:48 < neg> I guess it's someting else that mess stuff up ;)
+10:51 < shimoda> for gen3 no SYS-DMAC + IPMMU, I think we have to use magnus' patches
+10:51 < shimoda> it is already into topic branch?
+10:52 < pinchartl> in which power domains are the iommus ?
+10:52 < geertu> topic/ipmmu-multi-arch-v1
+10:52 < geertu> topic/r8a7795-ipmmu-rfc
+10:54 < neg> IIRC I did my initial test based on renesas-drivers-2016-02-09-v4.5-rc9
+10:54 < neg> s/rc9/rc3
+10:55 < shimoda> geertu: thanks for the info.
+10:55 < neg> but I did not try as much as I wanted so I would like another go
+10:57 < pinchartl> next topic ? or has everybody fallen asleep ?
+10:58 < geertu> Topic 2. Status check for tasks from last meeting - what is remaining?
+10:58 < horms> lets move on
+10:58 < geertu> earlycon is in
+10:58 < geertu> irqc ra7795 is half-completed, according to Magnus
+10:59 < horms> is the rfc half ready or is the whole thing half way to being merged?
+10:59 < geertu> pfc improve documentation is queued for pull request
+10:59  * geertu checks chat with Magnus
+11:00 < geertu> Remaining INTC-EX issue is the unknown parent clock, which Morimoto-san and Shimoda-san will check?
+11:01 < horms> ok, sounds simple enough
+11:01 < geertu> r8a7795 SYS-DMAC integration is queued by Simon
+11:02 < morimoto> geertu: I got same request from Magnus
+11:02 < geertu> r8a7795 Cache topology is halfway
+11:02 < morimoto> I will ask it to HW guy tomorrow
+11:02 < geertu> morimoto: I know ;-)
+11:02 < geertu> morimoto: Thx!
+11:03 < geertu> Any other task status updates?
+11:03 < horms> l2c patches?
+11:04 < horms> fwiw, they look good to me and i plan to merge them
+11:04 < geertu> == r8a7795 (+ other :-) Cache topology
+11:04 < geertu> thx
+11:05 < horms> yes. not stricktly on topic
+11:05 < shimoda> how about PFC,v4.6,plan,?,PFC 1.8v switching
+11:05 < shimoda> ?
+11:06 < geertu> That's not assigned yet.
+11:07 < geertu> But if I'm not mistaken, Wolfram was going to look into it for his SDHI work?
+11:08 < shimoda> i see, so I will ask Wolfram-san on next I/O meeting
+11:10 < geertu> Simon: do you plan to queue the fixes for writing to .text for v4.5?
+11:10 < horms> Yes
+11:11 < geertu> OK, thx
+11:11 < horms> I thought I did so this morning
+11:11 < geertu> I think it's queued for v4.6
+11:11 < horms> oh ok
+11:11 < horms> yes, that would be right
+11:11 < horms> are they fixes for v4.5?
+11:12 < geertu> Not having them will cause a crash on suspend as soon as Linus will merge rmk's branch for v4.6.
+11:12 < geertu> Which may happen before arm-soc is merged.
+11:12 < geertu> So I think it's safer to fast track them to v4.5.
+11:13 < horms> ok, it seems that it wouldn't hurt to ask the ARM SoC maintainers
+11:13 < horms> it would help me to make my case if i knew which patch(es) in RMK's branch you are referring to.
+11:13 < geertu> BTW, you can already trigger the crash if you enable CONFIG_DEBUG_RODATA=y now
+11:14 < geertu> That was in the cover letter
+11:14 < horms> of course :)
+11:14 < horms> i'll see about sending them to v4.5
+11:14 < geertu> 25362dc496edaf17f714c0fecd8b3eb79670207b
+11:14 < geertu>     ARM: 8501/1: mm: flip priority of CONFIG_DEBUG_RODATA
+11:15 < horms> I sent myself an email about it to read tomorrow morning
+11:16 < geertu> OK, thanks
+11:16 < geertu> Topic 3. RAVB / GPIO
+11:17 < geertu> Waiting up to 110 more seconds for network.
+11:17 < geertu> Seen in v4.5-rc3 and later
+11:17 < pinchartl> could it be related to the nfsroot issues I'm seeing ?
+11:18 < pinchartl> [   65.247123] nfs: server 192.168.1.47 not responding, still trying
+11:18 < pinchartl> [   65.261947] nfs: server 192.168.1.47 OK
+11:18 < horms> probably not
+11:18 < horms> or at least that is a different manifestation
+11:18 < geertu> Last week's renesas-drivers already had the RFC fix for rcar-gpio
+11:18 < horms> i don't even get an address via DHCP
+11:18 < geertu> The PHY interrupt doesn't come through because the rcar-gpio instance is suspended
+11:19 < horms> right. so your patches address this. but I wonder if they have any chance of making it into v4.5.
+11:19 < horms> If not I supose we have to live with broken ethernet
+11:19 < geertu> Before v4.5-rc3, the PHY driver accidentally kept on polling. When that was fixed, it broke ravb on salvator-x
+11:20 < geertu> Probably not a chance.
+11:20 < horms> which i guess is better than living with no cpg as we did in v4.4
+11:20 < geertu> ;-)
+11:20 < geertu> Does it work if you comment out the phy interrupt in the dts?
+11:20 < horms> Ok, at least I'll have something to talk about in Tokyo next week
+11:20 < geertu> (haven't tried myself, busy fixing bugs in -next)
+11:20 < horms> I can try
+11:23 < geertu> Lemme try myself
+11:23 < horms> fwiw i'm trying
+11:24 < geertu> works!
+11:24 < horms> excellent
+11:24 < horms> i guess we have found our work-around
+11:24 < geertu> Yeah, DT describes the hardware ;-)
+11:25 < geertu> Shall we add a quirk that removes the interrupt if present?
+11:25 < geertu> Would be a good exercise to prepare for ESx.y DT fixups
+11:25 < pinchartl> geertu: shall we fix the root cause ? :-)
+11:26 < horms> i think we know the root cause
+11:26 < geertu> In the Linux kernel, we never fix root causes ;-)
+11:26 < horms> and i agree any work around should go into .c not dt
+11:28 < geertu> We can get a workaround in v4.5-rc7 if needed, can't we?
+11:28 < horms> we can try
+11:30 < geertu> Should we stick a pm_runtime_get_sync() in rcar_gpio_probe() instead?
+11:30 < geertu> That would help HDMI, too
+11:31 < horms> its a posibility
+11:31 < horms> do we expect HDMI to be effected: i.e. for it go go into mainline before the root cause is fixed?
+11:32 < geertu> HDMI on Koelsch has been broken due to this for a while.
+11:33 < horms> ok, then it does seem like a good idea from my armchair point of view
+11:34 < geertu> OK, will go that way for today's renesas-drivers
+11:34 < horms> great
+11:34 < horms> Hopefully Florian reads your email before he spends any time on the problem
+11:35 < geertu> ;-)
+11:37 < pinchartl> anything else for today or can I have lunch ?
+11:37 < geertu> I think we're finished
+11:37 < geertu> Thanks for joining!