wiki: Porting wiki: Porting Chat Log

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>

1 files changed, 117 insertions, 0 deletions

diff --git a/wiki/Chat_log/20190822-io-chatlog b/wiki/Chat_log/20190822-io-chatlog
new file mode 100644
index 0000000..3fa0f3b
--- /dev/null
+++ b/wiki/Chat_log/20190822-io-chatlog
@@ -0,0 +1,117 @@
+09:03 < wsa> neg, jmondi: my I2C BoF has been accepted at Plumbers!
+09:04 < wsa> I was waiting for the acceptance to get my free ticket
+09:04 < wsa> But they were waiting for my registration to accept the BoF
+09:04 < wsa> no free tickets there
+09:04 < wsa> We solved that deadlock one day before the deadline :)
+09:05 < horms> :)
+09:06 < jmondi> wsa: ah! ticket deadlock!
+09:07 < jmondi> wsa: happy about the BoF, is it in the schedule already? let me check...
+09:07 < jmondi> wsa: had a look at Luca's ATF work? I read the series but refrained from commenting so far
+09:07 < wsa> If I had known that in advance I would have bought an early-bird ticket, of course. Well, life...
+09:08 < wsa> jmondi: yes, a short look. I still don't like the re-introduction of attach/detach callbacks. I think I proposed an alternative last time, but couldn't find it anynmore :/ Need to rethink
+09:09 < wsa> jmondi: nope, it is not in the schedule yet :(
+09:09 < wsa> ok, seems JapaPERI is busy
+09:09 < wsa> let's start the meeting and hope they will join soon
+09:09 < Marex> ATF ?
+09:10 < wsa> ATF?
+09:10 < wsa> welcome to the IO meeting
+09:10 < wsa> here are the collected status updates
+09:10 < wsa> A - what have I done since last time
+09:10 < wsa> ------------------------------------
+09:10 < wsa> Jacopo (long time no see here :))
+09:10 < wsa> : fixed a bug when reading temperature with a max9611
+09:10 < wsa> Marek
+09:10 < wsa> : resubmitted PCIe DMA range handling patch, and revisited PCIe 32bit
+09:10 < wsa>   limitation with a new approach.
+09:10 < wsa> Shimoda-san
+09:10 < wsa> : fixed a timeout in the XHCI driver, upported a fix from the BSP for the USBPHY,
+09:10 < wsa>   removed all Gen3 occurences in the SYS-DMAC part of the SDHI driver, cleaned
+09:10 < wsa>   up the PWM driver a little, and gave up on using GPIO for zero duty cycle for
+09:10 < wsa>   PWM (it is a hardware limitation)
+09:10 < wsa> Simon
+09:10 < wsa> : renamed binding documentation files, fixed a use-after-free case in the RAVB
+09:10 < wsa>   driver, and limited RAVB link speed for Draak and Ebisu
+09:10 < wsa> Ulrich
+09:10 < wsa> : sent v3 of changing MTU while RAVB is up, and already prepared v4
+09:10 < wsa> Wolfram
+09:10 < wsa> : continued with I2C API changes in core and drivers, fixed a race condition in
+09:10 < wsa>   Renesas I2C slave drivers, picked up watchdog-handover-from-bootloader again,
+09:10 < wsa>   reviewed smaller SDHI, media, ravb... patches, continued to organize Plumbers
+09:10 < wsa>   BoF about I2C addressing problems (now officially accepted)
+09:10 < wsa> B - what I want to do until next time
+09:10 < wsa> -------------------------------------
+09:10 < wsa> Marek
+09:10 < wsa> : wants to keep at the PCI patches
+09:10 < wsa> Shimoda-san
+09:10 < wsa> : wants to send next version of his MMC/IOMMU/BLOCK series, and update the PWM
+09:10 < wsa>   driver with the known limitations
+09:10 < wsa> Simon
+09:10 < wsa> : wants to follow-up on RAVB undocumented register patch in BSP, and keep
+09:10 < wsa>   renaming binding documentation files
+09:10 < wsa> Ulrich
+09:10 < wsa> : wants to keep at changing MTU while RAVB is up
+09:10 < wsa> Wolfram
+09:10 < wsa> : wants to pick up again prototype for a minimal SDHI clock to keep SCC active,
+09:10 < wsa>   update SDHI manual calibration once we get more infos from HW team, keep at
+09:10 < wsa>   the I2C API updates, run the BoF at Plumbers
+09:11 < wsa> C - problems I currently have
+09:11 < wsa> -----------------------------
+09:11 < wsa> Shimoda-san
+09:11 < wsa> : is currently blocked by the block layer maintainer (pun intended(tm))
+09:11 < wsa> Wolfram
+09:11 < wsa> : found out that handling a watchdog clock when probe fails is surprisingly
+09:11 < wsa>   difficult
+09:13 < wsa> Marex: maybe it helps a little getting attention for your patches if you'd write a cover letter? I kinda missed your new 32-bit PCIE limitation approach because it was described somewhere in patch 2/2 only?
+09:14 < geertu> Perhaps we should reconsider and mark the WDT module clock critical, so it will never be disabled?
+09:14 < Marex> wsa: it's the usual, Lorenzo takes forever to review stuff
+09:15 < Marex> wsa: he is "busy" and last time I checked with him on IRC, ARM is "working on solving this issue" (although, this is the reply I keep getting for months, with zero activity visible from them)
+09:15 < wsa> Marex: that's also a part of the equation ;)
+09:15 < wsa> Marex: OK. Thanks for the heads up
+09:16 < Marex> in particular, Robin (from ARM) is "working" on a fix ... except Robin is even less responsive than Lorenzo
+09:16 < wsa> Marex: Still, *I* missed the patch because of that. Just a small feedback. You can take it or not.
+09:16 < Marex> funny thing is, now there are at least three SoCs which have the same problem (R-Car3, iMX8 and some broadcom SoCs), ARM claims to know about it, but does nothing
+09:16 < Marex> wsa: ah, right
+09:17 < wsa> Marex: let's see if we can chat with ARM people at Plumbers...
+09:18 < wsa> geertu: I was thinking in a similar direction (critical clock)
+09:18 < wsa> geertu: can we do something like:
+09:18 < Marex> wsa: I am not going to plumbers
+09:18 < wsa> if (clock_enabled_by_fw) clock_is_critical else clock_is_not_critical
+09:18 < wsa> ?
+09:19 < wsa> Marex: but I am :)
+09:19 < Marex> wsa: and is Lorenzo or Robin ?
+09:19 < Marex> wsa: those are the people you want to talk to
+09:20 < wsa> I didn't find them on the speakers list
+09:20 < wsa> but I'll keep my ears open if they are there...
+09:23 < wsa> uli_: you are still at the RAVB MTU topic, or? Would be nice to have that task closed somewhen soon.
+09:24 < uli_> working on it
+09:24 < wsa> horms: has it already been discussed what happens with the periperi-ML from October on?
+09:24 < wsa> uli_: Great, thanks!
+09:25 < horms> wsa: no, thanks for raising that
+09:25 < horms> I'm happy to keep hosting it
+09:25 < horms> and ubsubscribe myself
+09:25 -!- morimoto [~user@relprex2.renesas.com] has joined #periperi
+09:25 < horms> but I'd appreciate it if, eventually, it could migrate somewhere else
+09:25  * morimoto we had Renesas inside meeting
+09:26 < wsa> hello morimoto-san!
+09:26 < morimoto> wsa: hi
+09:26 < horms> hi morimoto-san
+09:26 -!- shimoda [~shimoda@relprex2.renesas.com] has joined #periperi
+09:26 < morimoto> horms: hi
+09:27 < shimoda> hi, sorry to delay
+09:27 < wsa> horms: okay, so we it would be good if we started looking for a new home for the periperi-ml
+09:27 < wsa> hi shimoda-san
+09:27 < wsa> horms: thanks for giving us time to look
+09:28 < wsa> geertu: can we decide on the wdt clock being critical at runtime?
+09:29 < horms> wsa: no rush on my side :)
+09:30 < wsa> okay, we can move the wdt discussion to the ML
+09:30 < geertu> wsa: You can send a patch to provoke comments
+09:32 < wsa> just for completeness: the clock getting disabled has nothing to do with RPM being active or not when bailing out. AFAIU, the genpd disables the device as soon as probe fails with an errno
+09:32 < horms> wsa: I guess it would be good to assign another admin/moderator of the ML
+09:34 < wsa> horms: my hope would be that we find a new ML before October and, thus, automatically habe a new admin
+09:34 < horms> perfect
+09:34 < wsa> so, any more questions or comments?
+09:35 < wsa> JapaPERI side is happy (IO wise)?
+09:36 < wsa> seems like we are ready to move to core
+09:36 < wsa> geertu: ready?
+09:36 < geertu> Yep.
+09:36 < wsa> Have fun!