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!