wiki: Add I/O chatlog for 20220106

Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>

1 files changed, 110 insertions, 0 deletions

diff --git a/wiki/Chat_log/20220106-io-chatlog b/wiki/Chat_log/20220106-io-chatlog
new file mode 100644
index 0000000..9db36f5
--- /dev/null
+++ b/wiki/Chat_log/20220106-io-chatlog
@@ -0,0 +1,110 @@
+09:01 < wsa> welcome everyone!
+09:01 < wsa> here are the status updates:
+09:01 < wsa> Status updates
+09:01 < wsa> ==============
+09:01 < wsa> A - what have I done since last time
+09:01 < wsa> ------------------------------------
+09:01 < wsa> Geert
+09:01 < wsa> : sent RFC patch to fix ghost events in gpio-keys with both-edge irqs, cleaned up clock handling in the SCIF driver, tested GPIO sloppy logic analyzer
+09:01 < wsa> Kieran
+09:01 < wsa> : supported Ulrich with CAN V3U testing
+09:01 < wsa> Marek
+09:01 < wsa> : debugged PCI "can't change power state from D3hot to D0"
+09:01 < wsa> Shimoda-san
+09:01 < wsa> : debugged S4 PCIe
+09:01 < wsa> Ulrich
+09:01 < wsa> : tested and fixed CANFD on Falcon, prepared next version of CANFD for V3U
+09:01 < wsa> Wolfram
+09:01 < wsa> : investigated faulty SanDisk cards some more, started to guide I2C QoS support, converted I2C and IIC to the new DMAENGINE API, sent RFC to support non-strict GPIO mode for Gen3 PFC, reviewed I2C patches, sent out yet another version of the GPIO sloppy logic analyzer
+09:01 < wsa> B - what I want to do until next time
+09:01 < wsa> -------------------------------------
+09:01 < wsa> Geert
+09:01 < wsa> : wants to retest GPIO sloppy logic analyzer and non-strict GPIO mode for PFC
+09:01 < wsa> Marek
+09:01 < wsa> : wants to continue on the PCI D3hot to D0 problem
+09:01 < wsa> Shimoda-san
+09:01 < wsa> : wants to do further R-Car S4 support, especially ethernet switch and PCIe
+09:01 < wsa> Ulrich
+09:01 < wsa> : wants to find out if/why some CANFD channels don't work on the Falcon board, probably send v3 of CANFD for V3U
+09:01 < wsa> Wolfram
+09:01 < wsa> : wants to send out yet another version of the GPIO sloppy logic analyzer, find out the proper solution for faulty SanDisk cards with SDHI, continue guiding I2C QoS support, upport SDHI and/or TPU patches
+09:01 < marex> wsa: gen2/3 pci :-(
+09:02 < wsa> C - problems I currently have
+09:02 < wsa> -----------------------------
+09:02 < wsa> Marek
+09:02 < wsa> : Gen2/3 PCIe is full of severe problems
+09:02 < wsa> Wolfram
+09:02 < wsa> : wants to move to another place and would like to take the January off to do the preparations for that. He would be around for guidance and emergencies, but wants to move regular development time to February / March.
+09:03 < wsa> marex: so, the issue is affecting Gen3 as well?
+09:03 < marex> wsa: most of them anyway
+09:03 < marex> wsa: the ones which have A57
+09:04 < wsa> shimoday: I hope I did not shorten your work too much in the summary. It was not entirely clear to me, if you are still chasing bugs or if you found out that everything is ok?
+09:04 < marex> the ones which have A53, _probably_ not (to be verified)
+09:04 < wsa> marex: okay, it's already bad enough :(
+09:04 < wsa> shimoday: also, what is RC21212? Googling around didn't help me much
+09:05 < wsa> marex: are we reaching a point where we should just mark it as broken?
+09:05 < marex> wsa: it _probably_ has to do with speculation on those bigger cores, where the abort happens only once the read value has been used, not when the actual ldr instruction is called
+09:05 < marex> wsa: we passed that point a long time ago, it's just that turning OFF L1 state support in linux pci core for a controller is non-trivial
+09:06 < marex> (and pci maintainers provided no suggestions how to do it either)
+09:06 < marex> wsa: I have a workaround for this one, I am just looking for a better "fix"
+09:06 < wsa> marex: okay, good luck then
+09:07 < marex> wsa: hum, thank you
+09:07 < shimoday> wsa: RC21212 is a timing generator for PCIe and some devices
+09:08 < shimoday> wsa: about the summary, it looks good to me :)
+09:08 < marex> shimoday: some post-IDT design ? :)
+09:08 < shimoday> marex: I guess so
+09:09 < wsa> shimoday, moriperi, damm: any comment about my wish to take the January off?
+09:09 < wsa> I'd think the S4 boards won't ship to Europe in January anyhow
+09:10 < neg> wsa: Congratulations on the new flat
+09:10 < wsa> and even if so, I'd think core stuff has to be done first, so I think it should match
+09:10 < marex> shimoday: similar to renesas/idt 8SLVD1212NLGI maybe ?
+09:10 < moriperi> wsa: I have no comment about it. please enjoy moving :)
+09:10 < marex> maybe not
+09:10 < damm> likewise
+09:11 < wsa> neg: thanks :) lots of work, but I think it will be a lot better after that
+09:11 < geertu> wsa: We'll be having merge window soon, so I think you did great by aligning appartment and kernel schedules ;-)
+09:11 < wsa> moriperi: "enjoy", well.. I'd rather enjoy hacking than painting walls ;)
+09:12 < shimoday> wsa: I think it's ok to me :)
+09:12 < wsa> geertu: yeah, my move was the main reason for Linus doing an rc8 :D
+09:12  * geertu likes painting walls (well, there are worse tasks ;-)
+09:12  * wsa invites geertu over to paint walls
+09:12 < moriperi> wsa: oh, it seems there is big diff between Euro style and Japan style :)
+09:12 < wsa> moriperi: I think so :D
+09:13 < wsa> geertu: that means, I won't have time to fixup the logic analyzer script because preparing for cgroups v2 is not a trivial step
+09:13 < wsa> geertu: could you just rename the filenames manually for your tests meanwhile?
+09:14 < wsa> thanks japaperi!
+09:14 < geertu> wsa: Yeah, I'll handle fine. Just didn't get to it yet due to holidays.
+09:14 < wsa> geertu: great
+09:15 < wsa> so, another question for JapaPERI is CAN on V3U where some channels do not work, neither with Ulrich's upstream patches nor with the BSP
+09:15 < wsa> shall Ulrich invest time to debug and we pass it to the BSP then?
+09:15 < wsa> or shall the BSP team investigate and Ulrich shall upport their findings?
+09:16 < wsa> I assume everyone in Japan is busy with S4 now, so maybe it is a good task for Ulrich?
+09:16 < uli> i would prefer an opinion from the bsp team first; doing this remotely is poking around in the dark
+09:16 < wsa> But it also might be hardware related and uli only has remote access
+09:18 < wsa> because japaperi doesn't highlight in chat programs, I'll ask shimoday directly ;)
+09:18 < shimoday> wsa: thanks about the highlight :)
+09:20 < shimoday> BSP team is working for S4 and V4H. So, V3U is super low prio for now.
+09:21 < wsa> uli: maybe we could also upstream only the working channels for V3U/Falcon but still all driver changes?
+09:21 < uli> i'd be fine with that
+09:21 < shimoday> if some channels cannot work, are we possible to submit usable channel for upstream?
+09:22 < wsa> let's agree on that
+09:22 < shimoday> wsa: yes :)
+09:22 < uli> ok
+09:23 < wsa> because the channels do not work with uli's driver and the BSP driver, it is somewhat unlikely that the driver is the problem
+09:23 < wsa> and even if so, we can fix it incrementally
+09:23 < geertu> uli: You double-checked pinctrl?
+09:23 < wsa> but the driver still works on D3 and V3U channels 0-1.
+09:23 < uli> geertu: yes, i have (iirc, because i thought that was the problem at first)
+09:24 < wsa> any other questions from your side?
+09:26 < shimoday> marex: RC21212 is named as "VersaClock".
+09:26 < shimoday> so, i guess this is related to the product: https://www.renesas.com/eu/en/products/clocks-timing/versaclock-programmable-clocks
+09:26 < wsa> seems the PCIe fun continues with S4 :/
+09:27 < geertu> shimoday: And Linux already supports some vc5/vc6
+09:27 < marex> shimoday: so post-IDT design, indeed :)
+09:27 < shimoday> wsa: yes :)
+09:27 < marex> geertu: yes, linux already supports versaclock
+09:27 < shimoday> geertu: thanks! I'll check vc5/vc6 code
+09:28 < shimoday> marex: I see :)
+09:28 < shimoday> wsa: I don't have any question
+09:28 < wsa> ok. then, I think we can switch to the core meeting
+09:28 < wsa> thank you everyone for your participation