summaryrefslogtreecommitdiff
path: root/wiki
diff options
context:
space:
mode:
authorWolfram Sang <wsa+renesas@sang-engineering.com>2020-08-06 09:44:20 +0200
committerWolfram Sang <wsa+renesas@sang-engineering.com>2020-08-06 09:44:20 +0200
commit0d0231577b52a8480f125d7668a1a3b34744ba01 (patch)
tree0a2ec286effc0ea920409b1701edc037c2ed9c30 /wiki
parent1bd0b3317ec099d575041dba6d66e9d6a5518a9d (diff)
wiki: add IO chatlog from 20200806
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Diffstat (limited to 'wiki')
-rw-r--r--wiki/Chat_log/20200806-io-chatlog108
1 files changed, 108 insertions, 0 deletions
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!