path: root/wiki/Chat_log/20200806-io-chatlog

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!