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:06 < marex> the text binding documents were far more readable, some sane "binding document viewer" would be real nice I think
09:07 < marex> bindings2html maybe
09:07 < marex> something where one can view the whole bindings instead of having to traverse multiple files , and where each property has actual description instead of some opaque blurb
09:07 < wsa> :)
09:08 < wsa> what I would need now would be breakpoints and a single-step mode for 'make dtb_checks'
09:08 < marex> wsa: how come ?
09:09 < wsa> I just see results I don't understand, so by following the steps of the DTB checker, I might be enlightened
09:09 < wsa> or geertu has to explain it to me :D
09:09 < marex> wsa: pipe them into file, sort, look into the file ?
09:10 < marex> wsa: I usually pester robh , he's nicer on irc
09:11 < wsa> I tried the free online-book mentioned in the kernel docs, but it doesn't even talk about 'if:'
09:11 < wsa> I am clearly missing experience here
09:11 < geertu> wsa: The errors from dt_binding_check are indeed hard, but it has improved.
09:11 < marex> wsa: right, writing the binding documents is cryptic as ....
09:11 < wsa> okay, after the nice move from covid to technical topics, let's start the meeting officially
09:12 < geertu> If something fails, remove lines until it no longer complains ;-)
09:12 < marex> wsa: no morimoto no meeting ?
09:12 < wsa> he is here and our best wishes are with him
09:12 < geertu> shimoday: Sorry for keeping you awake one more hour ;-)
09:13 < wsa> To support him, I will eat a not-tasting burger for lunch :D
09:13 < marex> wsa: no tabasco no taste ?
09:14 < wsa> so, welcome to the IO meeting
09:14 < wsa> marex: you need Magnus to have fun with tobasco and Morimoto-san
09:14 < shimoday> geertu: no problem :)
09:14 < wsa> I hope you are all well, and, as mentioned, we hope for Morimoto-san's well being
09:15 < marex> I miss the real-life meetings, being hikikomori for over a year is not great
09:15 < wsa> here are the collected status updates
09:15 < marex> wsa: +1
09:15 < wsa> marex: so true, I was hoping for FOSDEM, but still no cigar...
09:15 < wsa> Status updates
09:15 < wsa> ==============
09:15 < wsa> A - what have I done since last time
09:15 < wsa> ------------------------------------
09:15 < wsa> Geert
09:15 < wsa> : reviewed Renesas 8T49N241 clock bindings and driver, investigated PCIe lock-ups during resume with E1000E present on R-Car Gen3
09:15 < wsa> Kieran
09:15 < wsa> : discussed and added CAN loopbacks for V3U in his remotelab
09:15 < wsa> Marek
09:15 < wsa> : submitted next version PCIe L1 clock fix
09:15 < wsa> Niklas
09:15 < wsa> : sent next versions of thermal patches for reading calibration from fuses
09:15 < wsa> Shimoda-san
09:15 < wsa> : bridged various SDHI questions between the IO group and the BSP team
09:15 < wsa> Ulrich
09:15 < wsa> : worked on next version of the CAN enablement patchset for V3U
09:15 < wsa> Wolfram
09:15 < wsa> : was two weeks in quarantine, worked on next revision of SDnH separation patches, reproduced suspend/resume issue with Ebisu, sent SDHI fix to enable card detection after hard reset plus cleanup patch, reviewed RPC-IF patches for G2L
09:15 < wsa> B - what I want to do until next time
09:15 < wsa> -------------------------------------
09:15 < wsa> Geert
09:15 < wsa> : wants to help Wolfram with SDnH DT binding addition, do more PCIe investigation
09:15 < wsa> Shimoda-san
09:15 < wsa> : wants to follow up on the remaining SDHI questions, continue to make more eLinux articles
09:15 < wsa> Ulrich
09:15 < wsa> : wants to work out a (semi-)automated test procedure for CAN on Falcon and send out the CAN enablement patches for V3U
09:15 < wsa> Wolfram
09:15 < wsa> : wants to send out next revision of SDnH separation patches, investigate suspend/resume issue on Ebisu, send out final version of the GPIO logic analyzer, send fix for usage of undocumented bits in RPC-IF driver, handle bus-recovery consistently in the I2C subsystem
09:16 < wsa> C - problems I currently have
09:16 < wsa> -----------------------------
09:16 < wsa> Wolfram
09:16 < wsa> : couldn't describe separate SDnH clock in the DT schema yet
09:17 < wsa> shimoday: you didn't mention the S4 ethernet driver. Is it done? Or will S4 fallback to RAVB again? ;)
09:17 < wsa> uli: are you set up for accessing Kieran's lab?
09:18 < uli> not yet. but i'd rather figure out a way to do it without me having to do remote access
09:18 < uli> hence the automated test procedure todo
09:19 < wsa> uli: you want to run a script there?
09:19 < uli> yes
09:19 < wsa> I see
09:19 < kbingham> If you change your mind, I just need an ssh key. The procedure is ... scp kernel+dtb across, and ssh to get a console/turn on and off.
09:19 < shimoday> wsa: I'm thinking some other issues (memory issue and PCIe RC/EP) are high than S4 ethernet. So, I dropped it.
09:19 < kbingham> But if you have a script that handles the tests, I can do that too.
09:20 < uli> i'll get back to you either way, thx
09:20 < wsa> shimoday: ah, it is on hold, I see
09:21 < wsa> if you have other questions or comments, fire away
09:21 < wsa> my topic for today is V3U status from the IO perspective
09:21 < wsa> IIRC shimoday wanted V3U to be fully supported by the end of the year
09:22 < wsa> and I think we are doing good
09:22 < wsa> RPC has just been added upstream and CAN is on the way
09:22 < wsa> only things missing:
09:22 < wsa> PCIe (considered broken in HW)
09:23 < wsa> RAVB ports on the ethernet subboard (we couldn't access the PHYs and it was not clear if this is a HW issue)
09:23 < geertu> kbingham: As you have physical access, are the PHYs mounted?
09:23 < kbingham> I believe so.
09:23 < wsa> PWM (not exposed, only possible if we can sniff the GPIOs which seems impossible on V3U)
09:23 < kbingham> Both 'add on' boards are connected.
09:24 < geertu> kbingham: I mean the PHY ICs
09:24 < geertu> on the add-on board
09:24 < geertu> SMP? (yes, that's core ;-)
09:24 < neg> geertu: :-)
09:24 < kbingham> geertu, I don't know what to look for. Can you give me a pointer?
09:24 < geertu> depends on PSCI
09:25 < wsa> shimoday: to see if we can enable PWM support, could you kindly ping the HW team to answer my question in "Question: GPIO input on V3U"?
09:25 < geertu> kbingham: there should be an array of Marvel 88Q2110/QFN40 1000Base-T1 PHYs
09:25 < wsa> shimoday: sorry to keep you so busy with all this proxy stuff
09:25 < geertu> U1/U4/U7/U10/U13/U16
09:26 < kbingham> 6 of them.... looks like they are there yes
09:27 < geertu> kbingham: OK, thanks for checking
09:27 < wsa> has someone ever tried the BSP on V3U?
09:27 < wsa> at least all the RAVB ports are described in DT
09:28 < geertu> Aha, they have PHY resets. Perhaps they are asserted when Linux boots? The MDIO subsystem won't deassert them, unless you describe the PHY ID in DT
09:29 < wsa> that may be worth a try
09:29 < shimoday> wsa: of course, i sent a ping now
09:29 < wsa> shimoday: thank you!
09:30 < kbingham> geertu, https://pasteboard.co/JL3qSvgGweVX.jpg
09:30 < wsa> geertu: would you be interested in this task?
09:31 < geertu> wsa: You mean retrying RAVB1-6?
09:32 < wsa> yup
09:33 < geertu> I can try, until the PHYs are detected (I guess there's no network connected to the matenet connector?
09:33 < geertu> )
09:33 < geertu> ok
09:33 < kbingham> no physical connections on that add on board here no.
09:35 < wsa> thanks, geert
09:35 < wsa> dunno if magnus has net connections there?
09:36 < wsa> but we will find out
09:36 < wsa> time for core, I think?
09:36 < wsa> thanks everyone and let's hope for good health all around!
|