diff options
| -rw-r--r-- | wiki/Chat_log/20201001-io-chatlog | 110 |
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! |