Core-chat-meeting-2018-07-12 09:34 < geertu> Welcome to Today's Core Group Meeting 09:35 < geertu> Agenda: 09:35 < geertu> 1. Status Updates 09:35 < geertu> 2. Discussion Topics 09:35 < neg> geertu: which datasheet can I find that in? :-) 09:35 < kbingham> geertu, so ... do we have to be rivals now or something ? I've never quite understood football :D 09:36 < geertu> Topic 1. Status updates 09:36 < geertu> A) What have we done since last time: 09:36 < geertu> Jacopo picked up and respun lost ipmmu patches, and attended OSS-J and 09:36 < geertu> met periperi people in Tokyo. 09:36 < geertu> Kieran supported Hoan/Jinso with serial passthrough testing. 09:36 < geertu> Marek worked on U-Boot (E3 Ebisu, V3M Eagle, D3 Draak, Spectre), ATF 09:36 < geertu> (V3M Eagle and D3 Draak), and OpenOCD (H2/M2/E2 support accepted). 09:36 < geertu> Morimoto is enforcing SPDX license tags, and working on periject v2 09:36 < geertu> (please send feedback!). 09:36 < geertu> Niklas fixed a V3M pinctrl crash. 09:36 < geertu> Shimoda-san submitted patches for PFC (E3 USB3.0), IPMMU (IMUCTR.TTSEL 09:36 < geertu> handling), R-Car DMAC (a.o. pause support), DTS (E2 USB2.0, RWDT 09:36 < geertu> unification), and asked BSP team about INTC-{AP,EX} clocks and 09:36 < geertu> resets removal. 09:36 < geertu> Ulrich sent ATF/U-Boot patches for H3 ES3.0 memory detection. 09:36 < geertu> Geert resubmitted bd9571mwv toggle power switch support, sent a first 09:36 < geertu> set of CLK and PFC pull requests for v4.19, tested 4.14 backports from 09:36 < geertu> Simon for LTSI, upported R-Car gen3 OSC and RCLK improvements, and 09:36 < geertu> submitted a GPIO virtualization presentation to ELCE2018. 09:37 < geertu> B) What we plan to do till next time: 09:37 < geertu> Jacopo will work on M3-W ULCB Z clock support and CPU idle. 09:37 < geertu> Kaneko-san will work on M3-N CPUFreq upport. 09:37 < geertu> Kieran may work on the DMAC virtualisation investigation continuation 09:37 < geertu> (TBC). 09:37 < geertu> Marek will work on U-Boot (SPL-alike replacement for Minimon) and 09:37 < geertu> OpenOCD for Gen3. 09:37 < geertu> Morimoto-san will continue SPDX and periject. 09:37 < geertu> Niklas will provide a fix for the V3M PFC crash for the stable tree. 09:37 < geertu> Shimoda-san will add the USB3 node to E3 DTS, and pave the way forward 09:37 < geertu> for IPMMU. 09:37 < geertu> Ulrich will revise the H3 ES3.0 memory detection patches, and is hoping 09:37 < geertu> for a consensus on the solution to use. 09:37 < geertu> Geert plans to work on rcar-gpio get_direction(), BD9571MWV toggle power 09:37 < geertu> switch rework, SYSC errata, and LTSI sub-maintainership, and hopes to 09:37 < geertu> look into GPIO paravirtualization. 09:38 < geertu> (anything I missed?) 09:38 < geertu> C) Problems we have currently: 09:38 < geertu> Ulrich is living in a house right between a Croatian and an English pub. 09:38 < geertu> Geert is worried by module clocks and resets that are described in DT, 09:38 < geertu> but disappeared from the datasheet, and by RZ/N1D pincontrol etc. 09:38 < geertu> EOT 09:39 < geertu> I assume Uli's problem has been solved by now, (or for now, reduced by 50%) 09:40 < ulih> loss of sleep is still noticable 09:40 < geertu> and they killed your Internet connection? 09:41 < geertu> Topic 2. Discussion Topics 09:41 < ulih> for their sake, i hope not 09:42 < geertu> So, how many resources do we want to spend on "Handle 32-bit DMA limitation"? 09:43 < Marex> given how the maintainers keep bouncing it between one another like a hot potato, a lot ? 09:43 < Marex> it seems to be moving from "PCI problem" to "DMA problem" to "generic arch problem" 09:43 < wsa_> I guess the task as a whole is more of an add. task 09:43 < dammsan> ZONE_DMA32? 09:44 < wsa_> however to find out how much time we really need some initial effort is needed? 09:44 < dammsan> isn't this same as Gen2 PCI-based USB? 09:44 < geertu> Correct 09:45 < geertu> ("Correct" for the estimation effort) 09:46 < Marex> dammsan: gen2 has 32bit address space, so it's "fine" there, right ? 09:46 < dammsan> Marex: no, with LPAE we have 40 09:46 < Marex> dammsan: gen3 has 64bit address space and the PCIe devices cannot access all of it 09:46 < Marex> dammsan: ha 09:47 < dammsan> ok so similar to 32-bit PCI space on a 40-bit machine =) 09:48 < dammsan> so we have bus mastering limitations for our PCI hosts 09:48 < dammsan> i guess we should describe those as part of DT 09:49 < dammsan> and then implement workarounds somehow, maybe bounce buffer or ZONE32 09:49 < Marex> dammsan: but it's not the host, it's how it's connected to the CPU bus 09:49 < Marex> dammsan: that's how I understand it anyway 09:49 < dammsan> to the CPU? 09:49 < Marex> dammsan: my understanding is that only 32 out of 64 address lines are connected 09:50 < dammsan> haha, if so surprisingly similar to gen2 =) 09:50 < dammsan> but this results that PCI cards cannot access memory outside 32 bits? 09:51 < dammsan> if we use IPMMU we can make that IOVA perhaps and translate that to any 64-bit address? 09:51 < Marex> dammsan: I believe that is the actual problem, PCIe cards cannot accesss stuff above 32bit boundary 09:52 < dammsan> so bounce buffer or IOMMU? 09:52 < dammsan> perhaps we need to clearly identify the problem unless already done 09:53 < dammsan> do we have a test case to reproduce? 09:53 < Marex> dammsan: I am looking for a suitable device 09:54 < Marex> dammsan: if my understanding is correct, one of those memory mapped storage devices would do nicely, since it needs a massive amount of PCIe space, well beyond 32bit 09:55 < dammsan> i recall intel based nics were popular 09:55 < dammsan> oh i see 09:55 < dammsan> i recall paul used graphics cards for PCI testing on SH 09:55 < Marex> dammsan: the intel NICs I have map below 32bit just fine 09:55 < dammsan> but you can force allocation of memory to higher address ? 09:55 < Marex> dammsan: oh, that could do too, but the slot is usually x1 only 09:56 < dammsan> to check if address lines mismatch somehow 09:56 < Marex> possibly, but how would that help ? 09:56 < dammsan> i guess those are two separate issues 09:57 < dammsan> maximum window space limited by 32 bits 09:57 < dammsan> and 09:57 -!- uli___ [~uli___@static.206.203.46.78.clients.your-server.de] has joined #periperi 09:57 < dammsan> address for bus mastering limited to lowest 32 bits 09:57 < dammsan> ? 09:57 -!- ulih [~Mutter@x2f7fd43.dyn.telefonica.de] has quit [Quit: Mutter: www.mutterirc.com] 09:57 < Marex> right 09:57 < horms> sounds like two variants of the same limit to me 09:58 < Marex> the window limit can be already dealt with 09:58 < Marex> that's nothing new 09:58 < dammsan> my point is that gfx card will be suitable for the first case 09:58 < Marex> but the bus mastering limit is the problem 09:58 < geertu> We're running out of time. Any closing remarks about PCIe and 32-bit limits? 09:58 < dammsan> and nic or any i/o card fine for the second 09:59 < dammsan> but anyway 09:59 < Marex> dammsan: or an FPGA 09:59 < dammsan> sure 09:59 < Marex> dammsan: I have an example design, maybe I should revisit it 09:59 < pinchartl> geertu: you can take a5 minutes extra, I'm slightly late 09:59 < Marex> dammsan: and it actually fits into the slot on the renesas board(s) 09:59 < geertu> Marex: would be nice 09:59 < dammsan> for sure 10:01 < dammsan> let me know how to reproduce =) 10:01 < Marex> dammsan: the 32bit limitation ? 10:01 < dammsan> yeah 10:02 < Marex> dammsan: I'll look for a suitable HW and let you know 10:02 < dammsan> thanks 10:02 < geertu> Does anyone care about RZ/N1? 10:03 < horms> If its a question of 1x PCI slots, I think you can get adapters if need be 10:03 < dammsan> in general yes, but it is not part of automotive effort, right? 10:04 < Marex> geertu: follow up question -- does anyone care about U-Boot on RZ ? :-) 10:04 < geertu> Marex: RZ/N, RZ/G, RZ/A, or RZ/T? 10:04 < geertu> RZ/G we probably do 10:05 < geertu> RZ/A Chris Brandt does 10:05 < geertu> RZ/T too low spec 10:05 < geertu> RZ/N the new kid on the block 10:06 < Marex> geertu: you can run U-Boot on cortex-m/r ;-) 10:06 < Marex> geertu: but yes, what about RZ/G and RZ/N ? 10:06 < Marex> geertu: maybe we should fix them early on 10:07 < geertu> I expect RZ/N using the worst Fankenboot 10:07 < geertu> s/Fan/Fran/ 10:07 < dammsan> sausage boot 10:07 < geertu> RZ/G should be similar to R-Car Gen2 10:07 < Marex> geertu: exactly 10:08 < dammsan> my opinion is that after gen2 u-boot is complete we can move over to other RZ as a low prio activity 10:08 < geertu> And RZ/G should be trivial to handle 10:09 < dammsan> openocd for rz/g? 10:09 < geertu> Trivial 10:10 < dammsan> good, the more reason to do it then =) 10:10 < geertu> The trivial ones are not consuming our cycles 10:11 < geertu> Things like RZ/N1D pincontrol do 10:11 < geertu> Anyway, time to finish. 10:11 < geertu> Anyone else who has a (quick) topic to discuss? 10:11 < dammsan> geertu: i guess we have no funding from RZ/N guys? 10:11 * pinchartl is ready 10:11 < dammsan> no other topic from me 10:11 < dammsan> thanks 10:12 < pinchartl> dammsan: is there a chance we could get funding ? or to put it differently, do you think it's worth trying to push in that direction ? 10:12 < geertu> Thanks for joining, and have a nice continued day! 10:12 * geertu passes the mic to pinchartl 10:12 < Marex> dammsan: do we have RZ/G and RZ/N board ? 10:13 < dammsan> Marex: nope, never seen them 10:13 < dammsan> pinchartl: yes it would make sense to get funding from those groups too 10:14 < pinchartl> dammsan: would you like to lead that effort, or should group leaders do so individually ? I think a joint effort would make more sense 10:15 < dammsan> pinchartl: good question 10:15 < Marex> dammsan: so uh, how do we do U-Boot port if we don't have reference platform ? :) 10:16 < pinchartl> dammsan: should we discuss that separately ? 10:16 < dammsan> perhaps we can begin by asking to get hardware platforms for free? 10:16 < pinchartl> that's a good idea 10:17 < dammsan> my opinion is that we can do that on an individual basis or group leaders do it 10:17 < dammsan> whenever there is demand 10:17 < pinchartl> ok 10:17 < dammsan> and then based on outcome of activity improve relationship 10:17 < dammsan> let me know if i can help somehow 10:18 < geertu> Marex: r8a7743-sk-rzg1m ~ Porter, r8a7745-sk-rzg1e ~ ALT 10:20 < horms> As I understand it the RZ/G work is coming out of Renesas UK. Chris Patterson seems pretty friendly. I would talk with him. But perhaps dammsan has a better idea 10:20 < horms> s/tt/t/ 10:21 < kbingham> I think me and Chris have a 'special relationship' now that we sang the grease song in duet :D 10:21 < Marex> geertu: I can imagine, should be easy to implement U-Boot support then 10:22 < dammsan> sounds good to me - thanks!