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!