1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
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!
|
