wiki: Add I/O chatlog for 20210415

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

1 files changed, 84 insertions, 0 deletions

diff --git a/wiki/Chat_log/20210415-io-chatlog b/wiki/Chat_log/20210415-io-chatlog
new file mode 100644
index 0000000..0d55c57
--- /dev/null
+++ b/wiki/Chat_log/20210415-io-chatlog
@@ -0,0 +1,84 @@
+09:02 < wsa> welcome to today's IO meeting
+09:02 < wsa> let's start with the status updates
+09:02 < wsa> I don't have one from Shimoda-san in my inbox, though
+09:03 < wsa> was it sent to Geert only, maybe?
+09:03 < shimoday> wsa: sorry, i sent an email now
+09:03 < wsa> anyway I can add it later
+09:03 -!- morimoto [~user@2001:268:c141:3b12:85ab:e1cb:3723:afda] has joined #periperi
+09:03 < wsa> the rest is like this:
+09:03 < wsa> A - what have I done since last time
+09:03 < wsa> ------------------------------------
+09:03 < wsa> Marek
+09:03 < wsa> : sent next version of PCIe L1 recovery patch
+09:03 < wsa> Shimoda-san
+09:03 < wsa> :
+09:03 < wsa> Ulrich
+09:03 < wsa> : investigated and fixed code relics in SCIF driver about minimum DMA timeout, investigated SDHI clock being left on after card is suspended/removed
+09:03 < wsa> Wolfram
+09:03 < wsa> : documented and sent "logic analyzer via isolated CPU" work, made more SDHI fixes like better irq mask handling and avoiding unneeded polling by the MMC core, checked I2C core and Renesas I2C drivers for RPM reference leaks, upstreamed CMT and TMU support for V3U, periject updates, especially for BSP41x commits, reviewed a few patches, mostly I2C
+09:03 < wsa> B - what I want to do until next time
+09:03 < wsa> -------------------------------------
+09:03 < wsa> Niklas
+09:03 < wsa> : wants to check and enable Thermal interrupt mode
+09:03 < wsa> Shimoda-san
+09:03 < wsa> : wants to
+09:03 < wsa> Ulrich
+09:03 < wsa> : wants to find out why default_suspend_ok() says that suspend is not ok with SDHI, look at the gpio logic analyzer
+09:03 < wsa> Wolfram
+09:03 < wsa> : wants to send next version of the logic analyzer based on feedback, continue with extended RECV_LEN and its R-Car support for I2C, refactor SDHn to be a seperate clock
+09:03 < wsa> C - problems I currently have
+09:03 < wsa> -----------------------------
+09:03 < wsa> Wolfram
+09:03 < wsa> : wants to do Condor board eMMC fixes but it seems we don't have HW to test
+09:04 < wsa> so, let's see what comes out of the next version of the PCIe patch
+09:04 < wsa> marex: thanks for sending it out
+09:05 < wsa> uli__: nice that you already found the culprit of the SDHI RPM issue
+09:05 < wsa> about the "Condor" problem...
+09:05 < wsa> damm: according to my information, there is none in your lab. But maybe my information is outdated?
+09:07 < wsa> about add. tasks in Q2:
+09:07 < wsa> shimoda-san told me there is no budget for add. IO tasks in Q2
+09:08 < wsa> so, the CAN task is moved to Q3 (HW is still missing, too)
+09:08 < wsa> ad the PCIe task as well. But we also don't have a workaround for the HW problem yet in the BSP
+09:09 < wsa> I dunno if one exists as a prototype
+09:09 < wsa> marex: are you running out of tasks? maybe RPC-IF enablement for V3U might be a task then...
+09:09 < wsa> marex: you have a V3U already, no?
+09:10 < marex> wsa: V3U U-Boot port in general seems like a lot of work, and also ATF/U-Boot CI
+09:10 < wsa> marex: i read this as "no free time"
+09:11 < wsa> ?
+09:11 < marex> wsa: the board is here, I plan to unpack it soon, so far I was busy with preparing for the later (hence the abloader)
+09:11 < wsa> ok
+09:11 < marex> wsa: at least not in the next few cycles
+09:11 < wsa> noted
+09:11 < marex> wsa: where do you want to enable the RPCHF, in Linux ?
+09:12 < wsa> yes, V3U has it enabled like all other V3x
+09:13 < marex> wsa: and all other boards with ATF built with RCAR_RPC_HYPERFLASH_LOCKED=0 , heh
+09:14 < wsa> yes
+09:14 < wsa> we will probably need that to work on the RPC driver fixes first
+09:15 < wsa> whoever does it will likely not have V3U
+09:15 < wsa> but given the possibility to brick the flash, it might be a good case for good old ES1.0 boards ;)
+09:16 < marex> wsa: what is it about this "brick the flash" again ?
+09:16 < damm> guys, there is a condor board in my remote access lab if you need it
+09:16 < wsa> for the V3U case, too much data was written which ended up in the fuse section IIUC
+09:16 < marex> wsa: of the flash ?
+09:16 < wsa> marex: yes
+09:17 < wsa> damm: which port?
+09:17 < marex> wsa: I have to look into that, that sounds odd
+09:17 < marex> wsa: anyway, I'll look up the email when I get to it
+09:17 < damm> please email me and i will provide details
+09:18 < wsa> damm: is there a always current list of available boards?
+09:18 < wsa> damm: I'll happily mail you again :)
+09:20 < damm> sorry information is sparse but just contact me and i'll help
+09:21 < wsa> ok
+09:22 < wsa> no further questions from my side
+09:22 < marex> wsa: btw I find that breakage hard to believe, either there is HF attached to the RPC on the V3U and HF is basically CFI NOR with AMD standard command set, or there is QSPI NOR with JEDEC command set, neither has any way to blow fuses during page program easily ... I think I need to read the flash emails
+09:22 < wsa> marex: or the BSP commits
+09:22 < wsa> 0d37f69cacb3343514380ff4a9c271b746959190 # memory: renesas-rpc-if: Correct QSPI data transfer in Manual mode
+09:23 < marex> wsa: thanks
+09:23 < wsa> marex: but that one likely needs to be refactored. mixing regmap and register access looks wrong
+09:24 < wsa> ok, time to move to core?
+09:24 < geertu> almost ;-)
+09:25 < marex> wsa: that commit only talks about some additional modes where RPC causes data corruption in various data lengths, that's normal property of that IP though
+09:26 < wsa> marex: and from the mails, this somehow set up some fuses, if I recall correctly
+09:26 < wsa> but that needs a closer look
+09:26 < marex> wsa: yep
+09:26 < wsa> okay, geert, have fun!