wiki: add IO chatlog from 20201001

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

1 files changed, 110 insertions, 0 deletions

diff --git a/wiki/Chat_log/20201001-io-chatlog b/wiki/Chat_log/20201001-io-chatlog
new file mode 100644
index 0000000..dc6588b
--- /dev/null
+++ b/wiki/Chat_log/20201001-io-chatlog
@@ -0,0 +1,110 @@
+09:06 < wsa> welcome to the IO meeting!
+09:06 < wsa> here are the status updates:
+09:06 < wsa> Status updates
+09:06 < wsa> ==============
+09:06 < wsa> A - what have I done since last time
+09:06 < wsa> ------------------------------------
+09:06 < wsa> Geert
+09:06 < wsa> : posted next version of binding for Ethernet MAC explicit internal delay setting, investigated ravb s2ram regression, investigated MSIOF CS deassert delay, verified R-Car E3 MSIOF DMA erratum, tested R-Car Gen2 PCIe s2ram fix
+09:06 < wsa> Marek
+09:06 < wsa> :investigate L1 link state recovery with PCIe on Gen2, sent patches
+09:06 < wsa> Shimoda-san
+09:06 < wsa> : forwarded and assisted with various SDHI problems from the BSP team, resent fix for Ethernet PHYs, worked to fix a DMA issue with the SATA driver
+09:06 < wsa> Ulrich
+09:06 < wsa> : sent new revisions of IIC atomic transfer patches, discussed the DA9063 PM patches for the WDT with maintainer, reviewed patches
+09:06 < wsa> Wolfram
+09:06 < wsa> : upstreamed SMBus emulation binding and core HostNotify support, updated and upstreamed R-Car support for HostNotify and I2C slave testunit, resent patch to support WDT handover from bootloader, removed unused SDHI stp_ck handling from Gen3 CPG, created series to handle TAP_EN on SDHI reset including some more SDHI cleanups, reviewed some SDHI patches coming from upstream, sent
+09:06 < wsa>  improvements to MMC core on and SDHI the way, started debugging a regression when re-inserting SD cards
+09:06 < wsa> B - what I want to do until next time
+09:06 < wsa> -------------------------------------
+09:06 < wsa> Marek
+09:06 < wsa> : wants to subit new patch for L1 link state recovery with PCIe on Gen2
+09:06 < wsa> Shimoda-san
+09:06 < wsa> : wants to convert rcar-pci dt doc to json-schema, correct information about R-Car Gen3e, do more R-Car V3U support
+09:06 < wsa> Ulrich
+09:06 < wsa> : wants to implement atomic transfers for i2c-rcar
+09:06 < wsa> Wolfram
+09:06 < wsa> : wants to fix the SD card re-insertion regression, send out the SDHI TAP_EN series after that, retest and apply Uli's IIC patch for atomic transfers, work on further SDHI issues (max_busy_timeout) which Shimoda-san reported, guide increase of I2C_M_RECV_LEN length to 255 and upstream R-Car support
+09:07 < wsa> Skipping C) because nobody has problems ;)
+09:07 < wsa> geertu: did the investigations (s2ram and MSIOF CS) result in something?
+09:08 < wsa> geertu: and did you verify the DMA errata exists or it has been fixed properly?
+09:08 < geertu> wsa: ravb regression cause was reverted
+09:08 < geertu> wsa: msiof investigation was to be relayed back to customer
+09:09 < geertu> 77972b55fb9d35d4 ("Revert "ravb: Fixed to be able to unload modules"")
+09:11 < wsa> geertu: so, Ashizuka-san from Fujitsu needs to work on a better patch then
+09:11 < wsa> ?
+09:12 < geertu> wsa: The reverted patch was a temporary fix anyway
+09:12 < geertu> Davem hinted to a proper solution in https://lore.kernel.org/linux-renesas-soc/20200820.165244.540878641387937530.davem@davemloft.net/
+09:12 < wsa> uli__: I thought I already replied to Guenter as well (increasing the pressure) but I overlooked it in my draft folder.
+09:12 < wsa> uli__: will send it out later
+09:12 < geertu> That is a solution for the MDIO subsystem
+09:13 < wsa> geertu: that is a real homework for Fujitsu then :)
+09:14 < uli__> ok, thx
+09:14 < geertu> wsa: Indeed (no response from Fujitsu so far, was his/her's first patch)
+09:16 < wsa> okay, other questions/comments from your side?
+09:16 < wsa> JapaPERI?
+09:16 < marex> wsa: btw you did the SCIF rework recently , didnt you
+09:16 < marex> wsa: did you test break/sysrq ?
+09:16 < marex> (meta-f in minicom)
+09:16 < wsa> shimoda: I will work on the SDHI issues one after the other
+09:17 < shimoda> wsa: i got it. thanks!
+09:17 < wsa> marex: I can't recall when I touched SCIF the last time
+09:17 < marex> wsa: might've been someone else then
+09:17 < geertu> marex: Do we need https://patchwork.kernel.org/project/linux-renesas-soc/list/?q=sh-sci&series=&submitter=&state=&archive= ?
+09:17 < wsa> marex: I think it was uli__ who did the last bigger changes there? And geertu taking care of the occasional fixes?
+09:18 < uli__> i didn't do anything recently, though
+09:18 < marex> geertu: isnt that for earlycon only ?
+09:18 < wsa> shimoda: and no worries, just bring them up. SDHI is nasty one, we all know that :)
+09:19 < wsa> uli__: yes, it was not really "recently"
+09:19 < wsa> marex: why the question
+09:19 < wsa> ?
+09:19 < geertu> marex: Oh, the second one is obsolete since dc9a325426f1113e ("tty/serial: Migrate sh-sci to use has_sysrq")
+09:19 < marex> geertu: uli__: there was something like a timeout when you send sysrq(break)-B to reboot the machine
+09:20 < geertu> "Unfortunately magic SysRq only works if CONFIG_SERIAL_SH_SCI_DMA=n.
+09:20 < geertu> "
+09:20 < shimoda> wsa: :)
+09:20 < marex> geertu: maybe something to improve then ?
+09:22 < geertu> marex: Actually all new people who enter the team are supposed to work a bit on SCIF (no joke, look at "git log"!). Have you served your time already? ;-)
+09:22 < marex> geertu: does uboot and qemu count ?
+09:23 < wsa> okay, now that sounds like an action item
+09:23 < wsa> "make SysRq work with DMA=y"
+09:24 < geertu> I think you can't detect BREAK when using DMA
+09:24 < geertu> same for parity errors
+09:25 < wsa> shimoda: about v3u, when you say that an IP core needs just "// DT-only" updates: did you check datasheets already or is it your guess based on other information you have so far?
+09:26 < wsa> geertu: I wonder if other IP cores can do that
+09:26 < wsa> geertu: seems like this needs investigation first?
+09:27 < shimoda> wsa: it's my guess based
+09:28 < marex> shimoda: are there any plans to push out sources for the bootloaders items, tfa, uboot ?
+09:28 < wsa> shimoda: ok, so, the first task is exactly that, to check datasheets
+09:28 < wsa> our V3U datasheet is from July 2020
+09:31 < geertu> but we still lack the board documentation, to check what we can test?
+09:31 < shimoda> marex: i'd like to support u-boot for v3u at least. but, if so, we cannot support PSCI. So, perhaps, we also should support atf? Or, u-boot only is enough?
+09:31 < wsa> it is "best effort" for now as I understood it
+09:32 < marex> shimoda: we can do both
+09:32 < shimoda> ah, i also got boards datasheets.
+09:32 < geertu> Note that upstream won't accept arm64 SMP support that does not use PSCI
+09:32 < marex> shimoda: isnt v3u booting via tfa/uboot anyway ?
+09:32 < shimoda> moriperi: could we share boards datasheets to europeri members?
+09:32 < wsa> no PSCI? we need a proper reboot, then
+09:33 < marex> geertu: you mean ARM Linux people won't accept a system which does not run ARM BSD-licensed firmware
+09:33 < marex> geertu: sounds to me like there is incentive on both sides to force that BSD-licensed firmware onto you
+09:34 < marex> wsa: PSCI isnt only about reboot, but also about bringing up secondary CPU cores
+09:34 < marex> wsa: and I would highly recommend keeping it at that
+09:34 < wsa> marex: yes, but that is stuff for core ;)
+09:34 < shimoda> marex: v3u will boot from "ICUMXA" cpu core. and the cpu kicks cortex-A cpu0
+09:34 < marex> wsa: anything beyond that, like power domains ... uuuurgh
+09:34 < geertu> marex: PSCI is just a spec, so you can provide your own inmplementation?
+09:34 < wsa> why is there no PSCI on v3u?
+09:34 < marex> geertu: and the "only up to date implementation" is by whom ?
+09:35 < marex> geertu: U-Boot implements only PSCI 0.2 I think, and on Gen3 the TFA already installs the handlers
+09:35 < marex> wsa: there likely is ?
+09:35 < moriperi> shimoda: I think I already did
+09:35 < marex> shimoda: is it using the CR7 loader ?
+09:36 < marex> shimoda: was that why you asked me about it some time ago ?
+09:36 < marex> shimoda: or is that something else entirely ?
+09:37 < wsa> seems we already switched to core
+09:37 < wsa> is there something left to discuss for IO
+09:37 < wsa> ?
+09:37 < geertu> wsa: Shall we make that official?
+09:37 < geertu> Next meeting?
+09:38 < wsa> okay, then, this time a on-the-fly-mic-takeover, geertu have fun!