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
|
09:03 < wsa> welcome to the IO meeting
09:03 < wsa> collected status updates
09:03 < wsa> Status updates
09:03 < wsa> ==============
09:03 < wsa> A - what have I done since last time
09:03 < wsa> ------------------------------------
09:03 < wsa> Geert
09:03 < wsa> : DT binding doc conversion to json-schema for em,uart, em,sti, mtu2, and tmu (updated), rtc-sh (updated), SDHI Runtime PM testing/investigation, fixed (worked around) RAVB regression due to Micrel PHY using internal delays now, RSPI/QSPI bit rate improvements
09:03 < wsa> Niklas
09:03 < wsa> : did clean ups for both thermal drivers
09:03 < wsa> Shimoda-san
09:03 < wsa> : Checked a BSP team's report about an SDHI DMA map/unmap unbalance and sent a fix, checked a RAVB driver patch from Bosch and submitted a patch, upported a thermal patch from BSP, reviewed SDHI driver's patches from Wolfram
09:03 < wsa> Ulrich
09:03 < wsa> : sent atomic transfers implementation for i2c-sh_mobile
09:03 < wsa> Wolfram
09:03 < wsa> : reviewed and tested RPM and clk_imbalance updates for SDHI, removed manual clock handling from renesas_sdhi_core, reworked and sent out series 'fix stalled SCC' and 'implement manual, calibration' for SDHI, sent out cleanup patches for I2C core, and I2C slave eeprom, review patches for IIC, I2C core, and r8a7742
09:03 < wsa> B - what I want to do until next time
09:03 < wsa> -------------------------------------
09:03 < wsa> Geert
09:03 < wsa> : wants to implement explicit internal delay setting from DT for RAVB, DT binding doc conversion to json-schema
09:03 < wsa> Shimoda-san
09:03 < wsa> : wants to continue investigating how to avoid mmc suspend/resume issue, ping Cogent about RAVB driver patch, convert usb-xhci, rcar-pci and sdhi dt docs to json-schema
09:03 < wsa> Ulrich
09:03 < wsa> : wants to implement atomic transfers implementation for i2c-rcar
09:03 < wsa> Wolfram
09:03 < wsa> : wants to resend series 'fix stalled SCC' and 'implement manual calibration' for SDHI, remove final bits of i2c_new_device API, new version of the series about blocked I2C devices in DT, review Ulrich's atomic_xfer patches for IIC
09:03 < wsa> C - problems I currently have
09:03 < wsa> -----------------------------
09:03 < wsa> Shimoda-san
09:03 < wsa> : wonders if any driver should not call cma_alloc() in system resume state?
09:04 < wsa> uli__, geertu: the 'never-disable' series for WDT clocks is still under review?
09:05 < geertu> wsa: My suggestion from last meeting was to mark the RWDT clock with CLK_IS_CRITICAL if it's already enabled.
09:05 < wsa> uli__: and I am looking forward to test the atomic_xfer patch :)
09:05 < wsa> geertu: ah, right, I remember
09:06 < wsa> I think uli__ agreed?
09:06 < uli__> i think i did.
09:06 < uli__> didn't make it to my todo list for some reason...
09:06 < wsa> uli__: can you work on that before atomic_xfer for i2c-rcar?
09:07 < uli__> sure
09:07 < wsa> great, thanks
09:07 < wsa> so, there is also the cma_alloc question from shimoda-san
09:08 < wsa> shimoda: i am not much into the RAVB driver, it frees the CMA memory when the system suspends?
09:09 < shimoda> shimoda: yes if user will not use wake-on-LAN
09:09 < wsa> i'd think you don't need to free CMA memory until shutdown, but maybe I am naive here...
09:09 < wsa> how much is it BTW?
09:09 < geertu> I'm thinking the same
09:10 < geertu> shimoda: BTW, who from Cogent are you expecting feedback from?
09:10 < wsa> sergei
09:10 < wsa> probably
09:10 < Marex> wsa: no longer with cogent, no ?
09:10 < geertu> Cogent is under restructuring, and (at last) Sergei has been laid off.
09:10 < wsa> really?
09:10 < wsa> wowo
09:10 < Marex> sadly seems that way
09:10 < geertu> FWIW, Sergei always worked on ravb/sh_eth in his spare time
09:11 < shimoda> ah, this cma thing is for BSP and our customer (bosch). because critical issue happen on BSP only
09:11 < geertu> s/at last/at least/
09:11 < wsa> shimoda: so, this issue is not present upstream?
09:11 < shimoda> about other patch (fix race condition on ravb driver), I expect Sergei reviews my patch.
09:12 < wsa> phew, let's see if sergei still wants to donate time for the ethernet drivers
09:12 < geertu> wsa: Probablt the issue was upstream, but fixed in the mean time. BSP is at v5.4 now, old BSp was v4.14.
09:12 < shimoda> wsa: you're correct. because the DMA API calls other alloc function if cma_alloc() failed
09:13 < shimoda> geertu: oops, I didn't know that.
09:14 < wsa> well, as long as sergei is still listed as maintainer
09:15 < wsa> shimoda: so, do you still need input on the cma issue?
09:15 < wsa> are there other questions/issues?
09:16 < geertu> wsa: Do you have plans to convert the i2c bindings to json-schema?
09:17 < wsa> nope
09:17 < wsa> too much other stuff to do
09:17 < wsa> is it high priority?
09:18 < shimoda> I don't have any question/issues for now. i wanted to feedback if some one knew
09:18 < shimoda> wsa: ^
09:18 * geertu just notices dt-schema/yaml-bindings/schemas/i2c/i2c-controller.yaml
09:19 < wsa> i am not an expert with CMA (maybe the MM guys can add) but as I said I wonder why you won't keep the memory until shutdown
09:19 * kbingham needs an i2c-mux schema too :-S
09:19 < wsa> geertu: i think rob was working on tha
09:19 < wsa> that
09:20 < geertu> wsa: I was mainly waiting for the i2c maintainer to write the core i2c controller schema iunder Documentation/devicetree/bindings/i2c/, but apparently that exists in dt-schema already
09:20 < shimoda> wsa: i don't know why. But, there is good point to fix the issue I think. Thank you for your feedback!
09:21 < wsa> noob question: where is dt-schema/yaml-bindings/schemas/i2c/i2c-controller.yaml
09:21 < wsa> ?
09:21 < geertu> https://github.com/devicetree-org/dt-schema.git
09:22 < geertu> For e.g. SPI, spi-controller.yaml is in Documentation/devicetree/bindings/spi/, not in dt-schema
09:22 < wsa> github? well, ok...
09:23 < wsa> so, this is the OS independent DT bindings repo?
09:23 < wsa> and linux should pull it in?
09:23 < kbingham> I don't think linux pulls it in - the dt-validator uses it ?
09:23 < wsa> no, it's the tool
09:23 < geertu> You need the dt-schema repo to run make dt_bindings_check and/or dtbs_check
09:24 < wsa> anyhow, I recall Rob saying he had an issue to tackle for a proper i2c-controller.yaml
09:25 < wsa> ok, i think this was it?
09:26 < wsa> then, let's move to the core issues :)
09:26 < wsa> geertu: enjoy!
09:26 < wsa> thanks for this meeting and your work, everyone!
|
