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

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!