From 55e3b2f45880faaf06f3c660ca9e8a6d9aa14bce Mon Sep 17 00:00:00 2001 From: Kuninori Morimoto Date: Mon, 9 Dec 2019 15:29:52 +0900 Subject: wiki: Porting wiki: Porting Chat Log Signed-off-by: Kuninori Morimoto --- wiki/Chat_log/20180823-io-chatlog | 117 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 117 insertions(+) create mode 100644 wiki/Chat_log/20180823-io-chatlog (limited to 'wiki/Chat_log/20180823-io-chatlog') 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! -- cgit v1.2.3