1 files changed, 117 insertions, 0 deletions
diff --git a/wiki/Chat_log/20180823-io-chatlog b/wiki/Chat_log/20180823-io-chatlog
new file mode 100644
index 0000000..27ee67a
--- /dev/null
+++ b/wiki/Chat_log/20180823-io-chatlog
@@ -0,0 +1,117 @@
+09:04 < wsa> then, let's start and welcome to the IO meeting!
+09:04 < horms> sorry for being late
+09:05 < wsa> again, first the status update, then topics
+09:05 < wsa> here they are:
+09:05 < wsa> Status updates
+09:05 < wsa> ==============
+09:05 < wsa> A - what have I done since last time
+09:05 < wsa> ------------------------------------
+09:05 < wsa> Geert
+09:05 < wsa> : fixed SPI controllers using DT aliases
+09:05 < wsa> Marek
+09:05 < wsa> : discussed the PCIe link L0/L1 switching on Gen3 upstream and created inquiry for the HW
+09:05 < wsa>   team
+09:05 < wsa> Shimoda-san
+09:05 < wsa> : fixed a build error for the USB gadget and continued learning virtualization of USB
+09:05 < wsa> Ulrich
+09:05 < wsa> : sent I2C0/3/5 pin control for H3 and M3-W, reviewed new REP_START generation series from
+09:05 < wsa>   Wolfram, and worked on the SCIF task about checking other flags in sci_receive_chars
+09:05 < wsa> Wolfram
+09:05 < wsa> : picked up watchdog task mentioned by Shimoda-san, sketched a better I2C safe DMA buffer API,
+09:05 < wsa>   reviewed & tested Yamada-san's SDHI patches as well as SDHI patches from Sergei and Fabrizio,
+09:05 < wsa>   upstreamed SDR104 support for Gen3, planned ELCE and IO hackfest in Edinburgh and
+09:05 < wsa>   sent a SPDX patch series
+09:05 < wsa> B - what I want to do until next time
+09:05 < wsa> -------------------------------------
+09:05 < wsa> Geert
+09:05 < wsa> : wants to get SCIF earlycon fixed in upstream handle SISTR.[TR]DREQ in MSIOF
+09:05 < wsa> Kaneko-san
+09:05 < wsa> : wants to continue D3 MSIOF upporting and start with E3 MSIOF upporting
+09:05 < wsa> Marek
+09:05 < wsa> : wants to continue with PCIe link L0/L1 switching on Gen3
+09:05 < wsa> Niklas
+09:05 < wsa> : wants to handle response about SDHI mapping sg segment size and respin
+09:05 < wsa>   4-tap HS400 tuning patch
+09:05 < wsa> Shimoda-san
+09:05 < wsa> : wants to ping the HW team for information about USB errata and create fixes based on that,
+09:05 < wsa>   experiment with KVM, and document his findings about USB virtualization on the wiki
+09:05 < wsa> Simon
+09:05 < wsa> : wants to revisit RAVB upporting candidates
+09:05 < wsa> Wolfram
+09:05 < wsa> : wants to finish watchdog task mentioned by Shimoda-san, finish the better I2C safe DMA
+09:05 < wsa>   buffer API, review next version of Yamada-san's SDHI patches and do I2C core PM
+09:05 < wsa>   improvements
+09:05 < wsa> C - problems I currently have
+09:05 < wsa> -----------------------------
+09:05 < wsa> Marek
+09:05 < wsa> : also needs info from the HW team about PCIe L0/L1 handling
+09:05 < wsa> Shimoda-san
+09:05 < wsa> : is still blocked by HW team concerning USB tasks
+09:05 < wsa> Wolfram
+09:05 < wsa> : still has zero time for the QEMU task
+09:05 < wsa> Topics
+09:05 < wsa> ======
+09:05 < wsa> Next meeting
+09:05 < wsa> ============
+09:05 < wsa> 2018-04-19, 09:00 CEST, 16:00 JST
+09:05 < wsa> ehrm, the next meeting line is bogus, of course
+09:06 -!- vaishali [~vaishali@116.75.86.10] has joined #periperi
+09:07 < wsa> and the overall summary would probably be "vacation time" ;)
+09:07 < wsa> Marex: glad to see the PCIe thread being so lively again!
+09:08 < Marex> wsa: it's more of an IRC thing now
+09:08 < Marex> (#linux-pci on oftc)
+09:08 < wsa> horms: is the priority boost for this RAVB patch okay with you, or are you still stuck with LTSI?
+09:08 < Marex> but the real question is, what is the controller doing when the transition to L1 is mid-way
+09:08 < Marex> shimoda: ^ :)
+09:09 < horms> wsa: should be fine if LTSI goes to plan
+09:09 < Marex> wsa: I will need to rework the patch using IRQs to conserve as much power as possible when switching to L1 state, but still ...
+09:09 < wsa> Marex: i think it is great that you reached the "real question"
+09:10 < Marex> wsa: why does the controller not do the transition automatically ? is there an errata ? what is really happening to the 5.3.2.1 state machine point 6..8 ? where is it broken ?
+09:10 < Marex> wsa: it's a start, yeah
+09:11 < wsa> geertu: the BSP patches for MSIOF suspend/resume are not commented in periupport. Do you have an eye on those?
+09:12 < geertu> wsa: I plan to test them, together with the other MSIOF work
+09:12 < wsa> geertu: 3e1497927bdf76dcad93f928ba0e4bf8d34a23e0 and 18f856640582163b365babdf9ab69c9ef4e02d57
+09:12 < wsa> Good, thanks
+09:13 < shimoda> Marex: I'll ask HW team about this PCIe things, but the person is the same as USB, so I don't think he replies soon... By the way, I'm not familiar about PCIe, so I'd like get a simple question for asking HW guys from you :) If simple, I think I can translate it to Japanese
+09:15 < wsa> uli___: what about this series "serial: sh-sci: Use pm_runtime_get_sync()/put()"? Any reason to not continue it?
+09:15 < Marex> shimoda: sure :)
+09:16 < Marex> shimoda: maybe I can talk to him directly ? :)
+09:16 < uli___> wsa: i honestly don't remember what that was about, i'll look into it :)
+09:17 < wsa> Please do
+09:17 < Marex> shimoda: but the question really is ... "what happens when the Gen3 PCIe controller receives PM_Enter_L1 DLLP from the PCI device?"
+09:17 < shimoda> Marex: by the way, R-Car Gen3 supports PCIe spec Rev.2.0, not Rev.3.0
+09:17 < wsa> So, any questions from your side?
+09:17 < wsa> I have one but we can do this last
+09:18 < Marex> shimoda: From PCI EXPRESS BASE SPECIFICATION v3.0 , the Gen3 PCIe controller should send PM_Request_ACK . Does it ?
+09:18 < Marex> shimoda: I think it does not, it needs to be forced to do so by setting this bit 31 in PMCTRL
+09:19 < Marex> shimoda: I only have the newer version of the PCIe spec, 3.0, but the L0-L1 transition procedure is the same
+09:19 < wsa> My question is about watchdog and clocks
+09:20 < Marex> shimoda: the v3.0 of the spec covers PCIe 1.0,2.0,3.0, I just ignore the PCIe 3.0 specific extra parts
+09:20 < wsa> if we don't have NOWAYOUT enabled, it does RuntimePM clock handling as our other drivers
+09:20 < wsa> if NOWAYOUT is set, we want to enable it once and never disable it again
+09:21 < wsa> I could skip pm_runtime_put on remove(), but isn't that kind of leaking?
+09:22 < wsa> Is pm_runtime_forbid() better? Yet, it also increments the ref counter
+09:22 < wsa> Any ideas on how to do that properly?
+09:22 < Marex> shimoda: do those three questions above make it easier to inquire about the PCIe or shall I rephrase them ?
+09:23 < geertu> pm_runtime_forbid() sounds like a good solution to me, also in wording (nowayout -> forbid)
+09:23 < wsa> yet, there will also be no pm_runtime_allow to balance it
+09:25 < wsa> ok, seems I will try pm_runtime_forbid and CC the rpm people
+09:25 < geertu> Will it ever call pm_runtime_put() if WDOG_NO_WAY_OUT is set?
+09:25 < geertu> watchdog_stop() returns -EBUSY
+09:27 < wsa> 1004         if (watchdog_active(wdd) && 
+09:27 < wsa> 1005             test_bit(WDOG_STOP_ON_UNREGISTER, &wdd->status)) { 
+09:27 < wsa> 1006                 watchdog_stop(wdd); 
+09:27 < wsa> 1007         }
+09:28 < geertu> nowautout assumes it has been started (once), right?
+09:28 < wsa> according to the docs, this will only trigger for !NOWAYOUT
+09:29 < shimoda> Marex: I'm afraid but, would you send an email about your questions? So, it' easy to forward to HW guy :)
+09:29 < Marex> shimoda: one moment please
+09:29 < wsa> geertu: i don't think so, but need to check
+09:31 < wsa> the problem I want to avoid is to increase the ref counter every time on rebind with NOWAYOUT enabled
+09:31 < wsa> dunno if this is academic
+09:31 < geertu> nowayout sounds mutually exclusive with unbind to me ;-)
+09:32 < wsa> yes :) somehow
+09:32 < geertu> Of course there's no way to enforce that in the driver framework (zero .remove callback?)
+09:32 < wsa> nice idea!
+09:33 < wsa> OK, maybe it is time now for the core meeting?
+09:34 < wsa> Looks like it... thanks everyone!