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!