path: root/wiki/Chat_log/20160216-core-chatlog

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!