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
|
09:04 < wsa> then, let's start the IO meeting
09:05 < wsa> first status updates:
09:05 < wsa> Status updates
09:05 < wsa> ==============
09:05 < wsa> A - what have I done since last time
09:05 < wsa> ------------------------------------
09:05 < wsa> Geert
09:05 < wsa> : started looking into sh-sci tx_dma_len == 0 issue
09:05 < wsa> Kaneko-san
09:05 < wsa> : got "rcar_gen3_thermal: Update calculation" merged
09:05 < wsa> Shimoda-san
09:05 < wsa> : sent new versions of the SDHI & IOMMU patch series and a DMA documentation
09:05 < wsa> fix, sent USB patches about removing memcpy and an unbalanced flag and
09:05 < wsa> adding a limitation, reviewed USB binding documentation changes
09:05 < wsa> Simon
09:05 < wsa> : posted patches renaming bindings documentation to a common pattern
09:05 < wsa> Wolfram
09:05 < wsa> : converted i2c_new_dummy() calls and i2c_new_secondary_device() to new API,
09:05 < wsa> updated SDHI HS400 quirk patches and got them merged, worked on upporting
09:05 < wsa> SDHI manual calibration offsets, sent two treewide series fixing an awkward
09:05 < wsa> way to determine the adapter of an I2C client, smaller cleanup patches to the
09:05 < wsa> I2C + MFD + and media subsystems, reviewed Shimoda-san's next version of the
09:05 < wsa> SHDI IOMMU series + watchdog delay patches and some SDHI DTS patches, sent
09:05 < wsa> talk proposal for ELCE in Lyon
09:05 < wsa> B - what I want to do until next time
09:05 < wsa> -------------------------------------
09:05 < wsa> Geert
09:05 < wsa> : wants to fix sh-sci tx_dma_len == 0 issue
09:05 < wsa> Shimoda-san
09:05 < wsa> : wants to keep working on the SDHI & IOMMU patch series, refactor the struct
09:05 < wsa> members of the usbhs driver, and keep an eye on upstream patches to avoid
09:05 < wsa> using virt_boundary_mask API
09:05 < wsa> Simon
09:05 < wsa> : wants to address review comments
09:05 < wsa> Wolfram
09:05 < wsa> : wants to continue working on upporting SDHI manual calibration offsets,
09:05 < wsa> upport more SDHI patches, continue working on I2C API changes, resend patch
09:05 < wsa> to handle watchdog handover from bootloader
09:05 < wsa> C - problems I currently have
09:05 < wsa> -----------------------------
09:05 < wsa> Ulrich
09:05 < wsa> : didn't get a reply from Dave Miller about the RAVB MTU change implementation
09:05 < wsa> Wolfram
09:05 < wsa> : needs to delay the i2c_new_dummy() conversion because of a missing declaration
09:05 < wsa> in the i2c headers, and suffers from a lagging buildbot with lots of incomplete
09:05 < wsa> builds delaying the build tests of the I2C API changes
09:06 < wsa> uli__: what about just sending the patch and asking the questions again next to the patch description?
09:07 < wsa> horms: what happened to the "follow up on RAVB on E3/D3 Errata" task?
09:07 < wsa> any patches I missed there?
09:07 < horms> oops, let me add that back on the list
09:08 < uli__> wsa: do you suggest to re-send the patch as is, or to implement the rollback somehow and ask if that's ok?
09:09 < horms> I believe that the status is that we need to verify if setting tx timing delays in the phy is sufficient to miliate against the errata. The likely answer is no and thus we will be back to updating the driver/DT
09:09 < wsa> uli__: I thought of trying the latter... unless you or others here have a different opinion?
09:10 < uli__> no, i think that makes sense
09:10 < wsa> cool
09:11 < wsa> then, about the HS400 tap auto correction issue.. we still don't have further information from the HW team
09:11 < wsa> yet, it causes troubles on at least my M3-N
09:12 < wsa> troubles == WARNs and OOPSes
09:13 < Marex> wsa: which patch is that ?
09:13 < wsa> If we don't get the information very soon(tm), I think we should disable HS400 until we got more information
09:13 < horms> wsa: I agree
09:14 < wsa> Marex: the one you already implemented for U-Boot and then we got advised to wait for more details
09:14 < horms> Would it only be disabled on M3-N, or more widely?
09:14 < shimoda> wsa: about hs400 issue, the bsp commit e6a40476f25287eb6e6df5c4 seems a workaround code, but I'll ask someone that is final decision or not
09:14 < Marex> wsa: OK, that one
09:15 < wsa> horms: I think we should first test on various SoCs again. I prefer "per-SoC", but if we can't get a clear picture, we need to disable it globally
09:15 < horms> wsa: that sounds reasonable to me
09:15 < Marex> wsa: I _think_ it improved the HS400 calibration behavior on E3, but I might be wrong
09:16 -!- damm [~damm@s214090.ppp.asahi-net.or.jp] has joined #periperi
09:16 < wsa> shimoda: thanks for asking them!
09:18 < wsa> That being said: I really wonder about the WARNings and OOPSes. I'd think we can fail more gracefully if the tuning is out-of-sync, but there seem to be competing workqueue issues
09:18 < wsa> I didn't have time to follow up on those, though. So, I wonder if there is someone interested to have a look at that?
09:19 < wsa> uli__ maybe? or kaneko maybe?
09:19 < Marex> wsa: maybe the whole calibration code needs a once-over? It seems like a convoluted mess :)
09:20 < geertu> How come you get an OOPS if tuning fails?
09:20 < horms> wsa: I would be happy to take a look into this
09:20 < horms> if no one else wants it / you think that is appropriate
09:21 < wsa> horms: sure, I just thougth you might be busy, but if you have the time I'd be happy if you have a look
09:22 < horms> I expect to have a bit of time next quarter, which is coming up pretty soon now
09:22 < wsa> On my M3-N, it shows by booting recent upstream kernel with renesas_defconfig and wait for 4 minutes or so
09:22 < wsa> if it doesn't show on your M3-N, I can give you a .config we could try
09:23 < horms> ok, sure
09:23 < wsa> horms: first thing would be to check if you can reproduce it
09:23 < horms> so I boot, then wait for mahem?
09:23 < shimoda> wsa: I asked Goda-san about HS400 issue, Renesas needs to continue investigate the issue. This means the BSP patch I indicated is still not good unfortunately..
09:24 < wsa> yup, I can mail you some logs with stuff I was seeing
09:24 < wsa> so you know what to look for
09:24 < horms> thanks, that would be helpful
09:24 < wsa> shimoda: thanks for checking!
09:24 < wsa> shimoda: do you agree that we need to disable HS400 if we don't get the information in time for v5.2?
09:25 < Marex> indeed, I will hold off the U-Boot patch too
09:26 < wsa> are there other questions / requests from your side?
09:27 < shimoda> wsa: now i am working for eMMC + IOMMU patch series, if possible, i'd like to keep HS400 mode as-is
09:29 < wsa> then, for now, let's just hope we will get more details in time :)
09:29 < wsa> so, i think this was it for the IO meeting?
09:30 < wsa> geertu: you are ready?
09:30 * geertu is ready
09:30 < wsa> then, thank you all for this meeting!
|
