1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
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!
|
