summaryrefslogtreecommitdiff
path: root/wiki/Chat_log/20211104-io-chatlog
diff options
context:
space:
mode:
Diffstat (limited to 'wiki/Chat_log/20211104-io-chatlog')
-rw-r--r--wiki/Chat_log/20211104-io-chatlog117
1 files changed, 117 insertions, 0 deletions
diff --git a/wiki/Chat_log/20211104-io-chatlog b/wiki/Chat_log/20211104-io-chatlog
new file mode 100644
index 0000000..529f796
--- /dev/null
+++ b/wiki/Chat_log/20211104-io-chatlog
@@ -0,0 +1,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!