From 0d0231577b52a8480f125d7668a1a3b34744ba01 Mon Sep 17 00:00:00 2001 From: Wolfram Sang Date: Thu, 6 Aug 2020 09:44:20 +0200 Subject: wiki: add IO chatlog from 20200806 Signed-off-by: Wolfram Sang --- wiki/Chat_log/20200806-io-chatlog | 108 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 108 insertions(+) create mode 100644 wiki/Chat_log/20200806-io-chatlog (limited to 'wiki/Chat_log/20200806-io-chatlog') diff --git a/wiki/Chat_log/20200806-io-chatlog b/wiki/Chat_log/20200806-io-chatlog new file mode 100644 index 0000000..3273dec --- /dev/null +++ b/wiki/Chat_log/20200806-io-chatlog @@ -0,0 +1,108 @@ +09:03 < wsa> but now for the IO meeting +09:03 < wsa> hey shimoda-san, glad you could make it +09:03 < marex> wsa: run the crappy software in qemu and use usbmon ? +09:04 < wsa> marex: http://shop.sysmocom.de/products/openvizsla-v3-dot-2-usb-protocol-analyzer-pcba +09:04 < wsa> it's open HW, I always wanted to have it, but seems I need some reason ;) +09:04 < marex> wsa: what for ? you can use plain software +09:04 < wsa> not all the time +09:05 < marex> wsa: those few times I needed bus analyzer, I used beagle and it was good enough +09:05 < marex> wsa: USB is usually slightly broken, I don't feel like having to fix usually slightly broken debug tool too :) +09:06 * wsa prefers openHW over QEMU solutions, might be taste +09:06 < wsa> but now for 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 generic bindings for Ethernet MAC explicit internal delay setting as implemented by RAVB, fixed boot crash in pci-rcar-gen2 +09:06 < wsa> Shimoda-san +09:06 < wsa> : added DT support for eMMC needing full power cycle in suspend, converted the SDHI binding docs to YAML, fixed the USB PHY driver to handle DEBUG_SHIRQ, and fixed a re-initialization failure in the RAVB driver +09:06 < wsa> Ulrich +09:06 < wsa> : found a way to make sure the i2c controller is awake before triggering atomic transfers +09:06 < wsa> Wolfram +09:06 < wsa> : discussed and sent out binding to activate emulated SMBus features for I2C, reviewed the HostNotify I2C implementation and updated the usage of it in i2c-rcar, made bugfixes for I2C slave (race when unregistering, timeout problems with Gen2, better sanity checks in the core), reviewed proposal to increase I2C_M_RECV_LEN limit from 32 to 255 and added I2C_M_RECV_LEN to +09:06 < wsa> i2c-rcar, bugfixed the i2c slave testunit and added a I2C_M_RECV_LEN test, guided and reviewed generic initialization of i2c bus recover via GPIO/pinctrl, tested that the DEBUG_SHIRQ issue is gone, made patches to update its documentation +09:06 < wsa> B - what I want to do until next time +09:06 < wsa> ------------------------------------- +09:06 < wsa> Geert +09:06 < wsa> : wants to test PCIe suspend/resume after arrival of Intel PCIe Ethernet card +09:06 < wsa> Niklas +09:06 < wsa> : wants to do the yearly test with SDIO-WIFI on Koelsch +09:06 < wsa> Shimoda-san +09:06 < wsa> : wants to convert rcar-pci dt doc to json-schema, fix usbhs issue for u_serial driver +09:06 < wsa> Ulrich +09:06 < wsa> : wants to send next version of atomic transfers for IIC, and implement the same for I2C +09:06 < wsa> Wolfram +09:06 < wsa> : wants to activate generic I2C recovery for i2c-sh_mobile, upstream SMBus emulation binding and core HostNotify support and R-Car support for it, upstream I2C slave testunit, guide increase of I2C_M_RECV_LEN length to 255 and upstream R-Car support for it, fix all the flaws I found while developing the above, resend series 'fix stalled SCC' and 'implement manual calibration' for SDHI +09:06 < wsa> C - problems I currently have +09:06 < wsa> ----------------------------- +09:06 < wsa> Ulrich +09:06 < wsa> : wonders where to add the reboot notifier handling, in the driver or in the watchdog core +09:06 < wsa> Wolfram +09:06 < wsa> : has a second Zebax adapter which has a pin not working and wonders how the others are doing +09:07 < wsa> comments? +09:07 < wsa> we will talk about uli__'s question shortly +09:07 < wsa> (shortly? I meant "in a bit") +09:08 -!- morimoto [~user@FL1-119-240-85-188.iba.mesh.ad.jp] has joined #periperi +09:08 < wsa> from my side, it was nice that a few people tackled I2C issues which were also relevant for Renesas +09:08 < wsa> so, I could delegate some work to them and just guide them +09:09 < wsa> although it needed discussions, too +09:09 < wsa> however, this explains the heavy shift to I2C related work the last weeks +09:09 < wsa> shimoda: I will do an SDHI week next week to catch up with pending patches +09:10 < shimoda> wsa: i got it. thanks! JFYI, I will have a vacation from tomorrow to 16th +09:11 < shimoda> ah, just I got a report from BSP team about SDHI driver +09:11 < shimoda> so, I'll send an email to you today :) +09:12 < wsa> shimoda: thanks +09:14 < wsa> uli__: I wondered if you could add a helper function to the core (which still must be called from the driver) +09:14 < geertu> wsa: uli__ : or a flag, like spi_controller.auto_runtime_pm +09:15 < wsa> so, it is still not fully like "the core handles PM" but more like "there is code in the core reducing boilerplate if I want this feature" +09:15 < wsa> geertu: this will save converting the drivers, but still one would need to add generic PM handling to the core, right? +09:16 < geertu> wsa: yes +09:16 < geertu> Not much to do there, right? +09:16 < geertu> Start, Stop, Reboot? +09:17 < geertu> Adding 3 pm_runtime_*() calls if auto_runtime_pm is set? +09:17 < geertu> Or am I missing something? +09:18 < uli__> i must admit that i haven't looked in detail into what exactly those WDT drivers are doing in terms of PM, but that should be all I guess +09:18 < wsa> There are 4 WDT drivers using RPM +09:18 < wsa> 2 of them are from Renesas :) +09:19 < geertu> We are the RPM heroes ;-) +09:19 < wsa> just from grepping, it looks like OMAP does a bit more complicated things with RPM +09:21 < uli__> it still seems to me that the drivers that don't do runtime PM should do it, too. either i'm missing something, or it just "happens to work" for everyone +09:21 < wsa> i think it boils down if uli__ has the time and initiative to add this to the WDT core +09:21 < wsa> it would be nice to have, of course +09:23 < uli__> my gut feeling tells me to try getting it in the DA9063 driver first, and only do the WDT core if there are objections... +09:23 < geertu> That's always a valid approach. +09:24 < geertu> 1. Implement feature in one or more drivers +09:24 < geertu> 2. Move it to the core +09:24 < geertu> 3. Profit! +09:24 < wsa> Fine with me, too +09:24 < geertu> You could ponder step 2 in step 1 +09:25 < uli__> then i'll do that +09:25 < uli__> thanks for the advice +09:25 < wsa> sure thing, uli__ :) +09:25 < wsa> are there other questions or topics? +09:26 < wsa> has someone else experienced Zebax problems? Like Pin33 does not work anymore, but the rest does? +09:26 < geertu> It's the adapter, and not the board? +09:27 < geertu> IIRC, these are rated for less than 100 insertions, which I find a bit low. +09:28 < wsa> it is the adapter, another one works +09:28 < wsa> geertu: in deed :( +09:29 < wsa> I measured the adapter and the signal of my multimeter goes through. Very weird! +09:29 < wsa> But if you don't have problems, lucky you :) +09:29 < geertu> Probably a sloght displacement of the contact +09:29 < geertu> So far no problems (holds wood) +09:30 < uli__> which adapter are we talking about? +09:31 < wsa> uli__: The ones you dislike so much that you made your own one :) +09:31 < uli__> aren't there two kinds with different pin pitches? +09:31 < wsa> Samtec-to-breakout +09:32 < wsa> anyhow, I think this was it for the IO meeting +09:32 < wsa> uli__: yes, there are +09:33 < uli__> so which is the one that broke? +09:33 < wsa> uli__: I only have the "wide" pitch +09:33 < wsa> I'd like to have a narrow one somehow, but was irritated by the one losing a pin now +09:33 < geertu> That's 0.8 mm, right? +09:34 < wsa> yes +09:34 < marex> morimoto: shimoda: hi, I was curious, is there some extra documentation for the bootrom ? esp. the IPL A/B switching mechanism ? I recall the security LCS stuff in TFA implements some calls into bootrom, so maybe there is some list of bootrom functions you can call from your own system software ? is there some internal renesas documentation for that ? +09:35 < marex> I mean, there must be some way to push the bootrom to boot the IPL Bcopy, right ? +09:35 < geertu> marex: Sounds like Core? +09:35 < wsa> then, let's switch over to core. Zebax adapters fit there, too, if we want to keep the topic ;) +09:35 < wsa> geertu: have fun! -- cgit v1.2.3