diff options
Diffstat (limited to 'wiki/Chat_log/20161122-core-chatlog')
| -rw-r--r-- | wiki/Chat_log/20161122-core-chatlog | 286 |
1 files changed, 286 insertions, 0 deletions
diff --git a/wiki/Chat_log/20161122-core-chatlog b/wiki/Chat_log/20161122-core-chatlog new file mode 100644 index 0000000..60c25b8 --- /dev/null +++ b/wiki/Chat_log/20161122-core-chatlog @@ -0,0 +1,286 @@ +Core-chat-meeting-2016-11-22 + +09:05 < geertu> Welcome to today's Core Group Meeting! +09:05 < geertu> Agenda: +09:05 < geertu> 1. Status updates +09:05 < geertu> 2. CPG/MSSR reset support +09:05 < geertu> 3. R-Car DMAC transfer termination synchronization support +09:05 < geertu> 4. Shared GPIOs +09:05 < geertu> 5. BSP GPIO question +09:05 < geertu> Topic 1. Status updates +09:05 < geertu> A) What have I done since last time +09:05 < geertu> B) What I plan to do till next time +09:06 < geertu> C) Problems I have currently +09:06 < geertu> First is Ulrich. +09:06 < geertu> -ENODEV +09:06 < geertu> Second is Simon +09:07 < horms> Status: +09:07 < horms> A) What have I done since last time +09:07 < horms> * No core task at this time +09:07 < horms> B) What I plan to do till next time +09:07 < horms> * See above +09:07 < horms> C) Problems I have currently +09:07 < horms> * Push back from Olof on pull-requests: under discussion with him +09:07 < horms> * Gen3 Suspend-to-RAM: What are the next steps (same as last time) +09:07 < horms> -- end -- +09:07 < geertu> I think the next step is +09:07 < geertu> r8a7796,?,noplan,?,Investigate suspend-to-idle +09:07 < horms> got it +09:08 < geertu> About Olof, looks like he was not very responsive yesterday? +09:08 < horms> yes +09:09 < horms> i am concerned that he may continue to be unresponsive +09:09 < horms> and drivers + arm32 will simply not be included in v4.10 +09:09 < horms> to be frank, not responsinve is the normal mode of operation +09:09 < geertu> And every user who wants to use soc_device_match() in v4.11 will have to import an immutable branch? +09:10 < geertu> Let's wait and see? +09:10 < horms> I think wating a little is resonable +09:10 < horms> but I also think we need to consider what plan B should look like +09:10 < horms> that doesn't need to be discussed in this meeting +09:11 < geertu> Looks like there will be an -rc8, so more time left +09:11 < geertu> Thanks Simon. +09:11 < geertu> Next is Shimoda-san +09:11 < shimoda> yes +09:11 < shimoda> A) B) nothing +09:12 < shimoda> C) I would like to use soc_device_match() for xhci-rcar to supprt H3 ES2.0 +09:12 < shimoda> EOT +09:12 < shimoda> s/supprt/support/ +09:12 < geertu> According to the latest updates to rel/todo, H3 ES2.0 is expected to arrive on 2017-02-31? +09:13 < shimoda> geertu: yes +09:13 < geertu> Or is that the target date of the working software support? +09:13 < pinchartl> geertu: if the hardware really arrives on 2017-02-31 then we'll have to wait a looooong time +09:14 < shimoda> it is arrive date of the hardware +09:14 < shimoda> pinchartl: indeed... +09:15 < geertu> I understand Tokyo is already writing support for it? +09:15 < pinchartl> any chance it could arrive on 2017-02-28, or 2017-03-03 instead ? :-) +09:16 < horms> pinchartl: its timeless hardware +09:16 * geertu hadn't noticed the invalid date ;-) +09:16 < morimoto> or un-exist hardware ? +09:17 < geertu> Ok, we'll handle it as soon as it arrives, i.e. on Feb. 32. +09:17 < geertu> Thanks Shimoda-san. +09:17 < geertu> Next is Niklas +09:17 < neg> A) PFC drive-strength and bias setting for none-GPIO pins on r8a7795 and r8a7796 posted +09:17 < neg> B) Nothing planed yet, keep talking to Geert and try to find a suitable core task :-) +09:17 < neg> C) None +09:17 < neg> EOT +09:18 < horms> neg: what if any issues are there with drive strength on Gen3? +09:19 < geertu> We still have to enable drive strength for ravb in the .dts, right? +09:20 < neg> horms: I have not seen any issues, on r8a7795 there where none GPIO pins missing in the driver +09:20 < neg> geertu: yes +09:20 < horms> neg: thanks +09:21 < geertu> neg: Will you handle the .dts part? +09:22 < geertu> Probably it'll have a hard dependency on the pfc driver updates (hi Olof ;-) +09:22 < neg> geertu: yes, I was waiting for all PFC parts to be picked up first but then I will +09:23 < horms> any chance the PFC (driver) parts can be included in v4.10? +09:23 < geertu> neg: It wouldn't hurt to have it in renesas-drivers (not today, though) +09:23 < geertu> horms: For r8a7795, it will (cfr. pinctrl/for-next) +09:24 < geertu> I don't plan to send any more clk/pinctrl pull request for v4.10, though. +09:24 < horms> ok, thenk the DT portion could go into v4.11, right? +09:24 < geertu> Yep. +09:24 < horms> a related question. how late in the cycle does LinusW take (PFC) patches? +09:25 < geertu> Or late v4.10 (as in: example for a bug fix needed for people doing their own boards and boot loaders) +09:25 < neg> geertu: yes, I will have it ready for next weeks renesas-drivers, you and Laurent have reviewd the PFC driver so it should be OK for .dts now +09:25 < geertu> horms: I'm not so sure. Quite late, I think. +09:25 < horms> ok. of course if its a bug fix then we can submit dt changes for v4.10. +09:26 < geertu> horms: You're thinking about having drive strength for r8a7796 in v4.10, too? +09:26 < horms> I have no particular thoughts +09:26 < horms> other than that if driver changes are in version n then its easy to add dt changes to version n+1 +09:27 < geertu> Yep, it's easy. The issue is if you want it earlier ;-) +09:27 < horms> s/easy/easier/ +09:27 < horms> I am in no rush +09:27 < geertu> ok +09:27 < horms> sorry for giving the impression that I was +09:27 < geertu> Thanks Niklas +09:27 < geertu> Next is Morimoto-san +09:28 < morimoto> int a, b, c; +09:28 < morimoto> +09:28 < morimoto> a = b = c = -ENOTASK; +09:28 < morimoto> +09:28 < morimoto> return 0; +09:28 < morimoto> +09:28 < geertu> return -EPROBE_DEFER? +09:28 < morimoto> no idea :) +09:29 < geertu> morimoto: you found the hard drive? +09:29 < morimoto> But I need to know BSP team's question answer :) +09:29 < geertu> Sure, that's a separate topic. +09:29 < morimoto> hard drive ? +09:29 < geertu> "Our team's server HDD has gone" (HDD != hard disk drive?) +09:30 < morimoto> Ahh, yes ! +09:30 < morimoto> I re-start works for us :) +09:30 < geertu> Good. +09:30 < morimoto> Thanks +09:30 < geertu> morimoto: About TDSEL: Sure there must be documented HDL source code for R-Car Gen2? +09:31 < morimoto> Maybe, but I don't know +09:31 < pinchartl> geertu: s/documented // +09:31 < morimoto> HW team is busy +09:32 < geertu> OK +09:32 < pinchartl> morimoto: if we can get the HDL source we can have a look and find out :-) +09:32 < geertu> Can I include it in renesas-drivers? +09:32 < morimoto> 1) Maybe HW team doesn't give it to me +09:32 < morimoto> 2) It can't export to you guys +09:33 < morimoto> I can't export +09:33 < horms> morimoto: i think they were joking :) +09:33 < morimoto> :( +09:33 * geertu was +09:33 < geertu> THanks, Morimoto-san +09:33 < morimoto> geertu: what is "it" mean ? +09:33 < geertu> Next is Magnus +09:34 < geertu> it == HDL source +09:34 < geertu> -EJAPANESE_LESSON? +09:34 < morimoto> Ahh, of course not +09:34 < geertu> Next is Laurent +09:34 < morimoto> -EDRINKING +09:35 < pinchartl> nothing to report +09:36 < geertu> Thanks Laurent +09:36 < geertu> Next is Khiem +09:36 < geertu> -EINTR? +09:37 < geertu> Next (last) is Geert +09:37 < geertu> A) What have I done since last time - Completed SoC identifaction - Queued up RZ/G1M and RZ/G1E clock drivers, - Sent more clock and pinctrl pull requests, +09:37 < geertu> B) What I plan to do till next time - Coerce Simon into taking all MODEMR related patches, - Investigate IPMMU and Ethernet +09:37 < geertu> C) Problems I have currently - What's wrong with the IPMMU and Ethernet? +09:37 < geertu> (hm, bad formatting. should switch to .rst?) +09:38 < geertu> Anyone else who tried IPMMU and had mixed results? +09:38 < horms> For B, we need to to take into account our recent interation with Mr. Olof. Probably after the current round of bother blows over. +09:38 < pinchartl> geertu: there's "a bit" of corruption on the screen when IPMMU is enabled for the VSP/DU +09:39 < geertu> B depends on the RST series, which is going in through clk +09:39 < shimoda> pinchartl: about VSP/DU with IPMMU, did you try on M3? +09:40 < geertu> pinchartl: Corruption could explain it. I haven't dug deeper into it, but NFS root works initially, then the network stops working (on M3) +09:40 < pinchartl> shimoda: not personally, no +09:41 < neg> I have problem on H3 and VIN+IPMMU, corruption on VIN1 but not on VIN0 if I look at the video using applications but works fine in VIN->DU +09:42 < shimoda> pinchartl: i see. H3 ES1.x has an issue about ipmmu. if multiple request happens from hw, the IPMMU TLBs will currupt +09:43 < pinchartl> shimoda: that could explain it +09:43 < pinchartl> we should retest everything on M3 +09:43 < shimoda> pinchartl: I think so +09:43 < geertu> Any known issues on M3? +09:45 < shimoda> geertu: about IPMMU? if so, no serious issue on M3, but some performance issues exist +09:46 < geertu> OK +09:46 < geertu> Let' +09:46 < geertu> s continue +09:46 < geertu> Topic 2. CPG/MSSR reset support +09:46 < geertu> From morimoto-san +09:46 < geertu> We would like to have MSTP::Reset feature for each devices, +09:46 < geertu> it is requested on HW user manual (maybe we don't have it ?). +09:46 < geertu> This Reset is necessary on initial time. +09:46 < geertu> First of all, who should handle it ? by Linux ? by IPL ? +09:46 < geertu> If answer was "IPL", we will ask it to BSP guys. +09:46 < geertu> If answer was linux, it can be Core topics. +09:46 < geertu> I guess it should be handled by pm_runtime_xxx() ? +09:46 < geertu> EOT +09:47 < geertu> To me, it looks like this should be handled by the CPG/MSSR driver (the old MSTP driver cannot easily be extended for that) +09:48 < pinchartl> I agree. there's a reset controller API in the kernel that can be used for this purpose +09:48 < geertu> I'm a bit puzzled by the conflicting "This Reset is necessary on initial time." and "I guess it should be handled by pm_runtime_xxx()" +09:48 < morimoto> please drop last comment +09:48 < geertu> It's still a bit unclear how this is supposed to be used. +09:48 < morimoto> it is just my opinion +09:48 < geertu> OK +09:49 < geertu> From a quick look, drivers call into the reset controller API when they want to reset a module? +09:49 < geertu> But that means the driver for the module is in control, why we need reset for all modules on initial time? +09:49 < geertu> Also, what does the "HW user manual" say? +09:50 < pinchartl> could "initial time" mean "probe time" ? +09:51 < geertu> Possibly. +09:52 < geertu> Or "resume" time? (with "DDR backup" in the BSP) +09:52 < morimoto> Above my comment (= pm_runtime_xxx) was based on every "use time" +09:52 < geertu> If this is a common requirement, it would be good to handle it in common infrastructure, and not in each individual driver (cfr. PM domains) +09:53 < geertu> morimoto: Note that each time you reset the module, all registers are changed to their reset values +09:54 < morimoto> Yes, I know. Each driver shouldn't assume it can keep register settings IMO +09:56 < geertu> If you reset the module on every pm_runtime_get_sync(), you have to restore all registers all the time, which will kill performance +09:57 < morimoto> But it is necessary if you want to support Suspend/Resume. +09:57 < morimoto> Suspend will kill Power, and all register value will gone +09:57 < geertu> If "reset on initial time" is the only thing we need, then the CPG/MSSR driver could reset each module the first time its clock is enabled. +09:58 < geertu> morimoto: Sure, but that doesn't mean we have to do it in every pm_runtime_get_sync(), only when resuming. +09:58 < morimoto> Current R-Car doesn't have PowerDomain, so maybe yes. But if SoC has PowerDomain, it needs +09:59 < geertu> If Suspend kills power, we have to reset the module after resume, too? +09:59 < morimoto> If SoC has PowerDomain, and if no user exist, module power will be killed +10:01 < pinchartl> Gen3 has power domains +10:01 < geertu> Yes, and we already have to handle that in drivers shared with SH/R-Mobile, which does have power domaains +10:02 < geertu> Still, it would be good to know what the "HW user manual" says... Is that document available? +10:02 < morimoto> About Reset, maybe it is needed on Probe time, and resume time. +10:02 < morimoto> My pm_runtime_xxx is related a little bit different topic +10:02 < pinchartl> one concern I have with resetting modules is that the secure firmware might poke with some (possibly undocumented) registers after resume. if we then reset the modules, things might start breaking +10:03 < geertu> Can't the secure firmware prevent us from resetting some modules? +10:05 < pinchartl> indeed it can +10:06 < geertu> I think we need to know more of the "why" behind this request. We've been living without resetting modules for many years. +10:07 < pinchartl> for some modules, though, it would be useful, if only as a workaround +10:07 < pinchartl> for instance the VSP sometimes fail to stop +10:07 < pinchartl> that's most likely cause by a driver bug +10:07 < geertu> OK. That reset under driver control. +10:07 < geertu> Not "This Reset is necessary on initial time" +10:07 < pinchartl> but the failure can be detected, and a module reset could potentially be helpful +10:07 < geertu> s/That/That's/ +10:08 < pinchartl> correct, although I wouldn't mind being able to reset moduls at probe time, to wipe off crazy configurations applied by the boot loader :-) +10:08 < pinchartl> that problem should of course ideally be fixed in the boot loader, which shouldn't apply crazy configurations in the first place +10:08 < geertu> Well, drivers should not make assumptions about the boot loader, and initialize all registers anyway? +10:10 < morimoto> geertu: not all, but some deivce was indicated on datasheet. +10:10 < pinchartl> it's easily to overlook a register whose reset default value is fine +10:10 < morimoto> For example SATA, can you see v0.52 manual, 72.3.10 ? +10:12 < pinchartl> morimoto: I think that what we'd like to know is whether some modules require a reset (as in the module will fail in more or less subtle ways if it's not reset) or if it's more of a good practice rule that would make the BSP team sleep better at night +10:13 < pinchartl> or, to put it differently, what are the problems that will be fixed by resetting modules ? +10:14 < geertu> Exactly. +10:14 < morimoto> SATA, Thermal are indicated on datasheet, Sound was indicated on Application manual +10:14 < geertu> The flow chart in 72.3.10 is indeed interesting +10:14 < morimoto> The reason why BSP team needs it is because it is indicated on datasheet :( +10:15 < geertu> 1. It refers to SASRSTECR (unfortunately in graphical form, so a text search won't find it) +10:15 < geertu> 2. The corresponding CPG/MSSR sections says: This register is functional safety use only. Keep initial value +10:15 < geertu> ??? +10:16 < horms> morimoto: I understand that the BSP team wants to comply with the documentation. But in my experience some kind of run-time behaviour enhancment/fix/... helps to motivate changes in mainline +10:18 < morimoto> horms: do you mean, "because it was indicated on datasheet" is not good reason ? +10:18 < horms> i mean it would be easier from a mainline point of view if that was not the only reason +10:21 < geertu> I think we should move on to the next topic... +10:21 < geertu> Topic 3. R-Car DMAC transfer termination synchronization support +10:21 < geertu> From Morimoto-san: +10:22 < geertu> BSP team has rcar-dmac issue. Laurent posted its patch last year, but it was +10:22 < geertu> canceled. because it needed new frame-work. +10:22 < geertu> https://patchwork.kernel.org/patch/7175381/ +10:22 < geertu> Now, upstream has it. It can be next Core group Task ? +10:22 < geertu> b36f09c3c441a6e59eab9315032e7d546571de3f +10:22 < geertu> ("dmaengine: Add transfer termination synchronization support") +10:22 < geertu> EOT +10:22 < geertu> Is there anything to discuss, or just a task to add? +10:22 < morimoto> pinchartl: can you explain ? +10:23 < pinchartl> the BSP patch was waiting for the hardware to complete all transactions when terminating them +10:24 < pinchartl> but the termination function was sometimes called from non-sleepable contexts, so I nacked the patch +10:24 < pinchartl> now the DMA engine API has support for synchronous and asynchronous termination +10:24 < pinchartl> so we can implement the feature +10:25 < morimoto> it can be 17Q1 task ? +10:26 < geertu> I think so +10:27 < morimoto> Nice. BSP team (or customer) needs it +10:27 < geertu> Topic 4. Shared GPIOs +10:27 < geertu> From Laurent: For key + LED operation +10:27 < pinchartl> Linus isn't against the idea +10:28 < pinchartl> all we need is someone to implement it +10:28 < pinchartl> neg: did you say you were looking for a core task ? :-) +10:28 < geertu> I think he already has an option on "GPIO-RCAR,?,noplan,?,Fix Runtime PM with GPIO interrupts (depends on irqchip PM) +10:29 < pinchartl> shared GPIOs might not be the most urgent one though, but it's nice for our upstream PR to drive API and framework changes +10:29 < geertu> Well said ;-) +10:30 < geertu> I'll add a task to core/todo +10:30 < geertu> Topic 5. BSP GPIO question +10:30 < horms> fwiw, i am for such activities +10:30 < geertu> shimoda: Any last minute info? +10:30 < neg> I happy to work on either of them :-) +10:32 < shimoda> unfotunately, i don't receive the detail so we can skip it :) +10:32 < shimoda> i'll forward it by email laster +10:32 < geertu> OK, thanks +10:32 < shimoda> s/laster/later/ +10:32 < geertu> Anything else to add? +10:34 < neg> Have we settled on next face to face core meeting to be at FOSDEM timing? +10:34 < geertu> Well, looks like Magnus wants to evade by arriving late? ;-) +10:35 < geertu> Probably it'll happen on Friday (half a day shared with I/O) +10:35 < horms> geertu: any thoughts on Olof's idea regarding pfc/Kconfig? +10:36 < geertu> horms: I still have to reply why it's a bad idea +10:36 < horms> ok +10:36 < horms> fwiw, i think its a can of worms +10:37 < pinchartl> geertu: Friday before the FOSDEM ? +10:37 < geertu> pinchartl: yep +10:37 < pinchartl> I'll be there +10:37 < geertu> OK +10:37 < geertu> Thanks for joining, and have a nice continued day! +10:38 < pinchartl> I mean, at least in Belgium :-) +10:38 < neg> I only asked so i can buy tickets before my financial year ends :-) I will be there +10:38 < geertu> horms: Bummer, forgot to email sfr yesterday +10:38 < horms> I also expect to be there +10:39 < horms> geertu: I for one was distracted +10:57 < morimoto> I guess chat meeting was finished ? +10:57 < horms> I guess so too +10:59 < neg> next meeting in 2 weeks, same time? +10:59 < geertu> Yes, that's the plan. Will send the report later +10:59 < morimoto> Today is started on EuroPeri side, but Today will finish on Japan side. So, please finalize meeting if it was finished. Otherwise we can't go back :P +11:00 < geertu> (repeat) Thanks for joining, and have a nice continued day! |