diff options
Diffstat (limited to 'wiki/Chat_log/20160216-core-chatlog')
| -rw-r--r-- | wiki/Chat_log/20160216-core-chatlog | 195 |
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! |