1 files changed, 173 insertions, 0 deletions
diff --git a/wiki/Chat_log/20180712-core-chatlog b/wiki/Chat_log/20180712-core-chatlog
new file mode 100644
index 0000000..6fc83f9
--- /dev/null
+++ b/wiki/Chat_log/20180712-core-chatlog
@@ -0,0 +1,173 @@
+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!