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:05 < wsa> welcome to the IO meeting
09:05 < wsa> hope you are all well (again)
09:05 < wsa> here are the 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> : enabled and tested MSIOF on R-Car V3U with manual pinctrl
09:05 < wsa> Niklas
09:05 < wsa> : had an initial look at Thermal support for V3U
09:05 < wsa> Shimoda-san
09:05 < wsa> : investigated the issues of the SDHI driver with Wolfram, and additionally sent patches to clean up resources in the SDHI driver, discussed using MMC aliases in DT, resent SCIF bindings for V3U, and discussed sending a power off notification in the MMC core
09:05 < wsa> Wolfram
09:05 < wsa> : worked on a lot of SDHI related issues: sent series to remove the hw_reset workaround by properly resetting the SCC which fixes the SD card insertion regression, sent series to reset SCC only when available, updated the "refactor SCC reset" series, sent cleanup series made possible by the previous refactoring, upported BSP patch to clear stale IRQs on errors, sent out series
09:05 < wsa> for proper max_busy_timeout handling, worked on a patch for resetting via reset controller, discussed how to handle SDHn clocks better nad how to handle data timeouts
09:05 < wsa> B - what I want to do until next time
09:05 < wsa> -------------------------------------
09:05 < wsa> Geert
09:05 < wsa> : wants to retest MSIOF when R-Car V3U pinctrl driver is posted
09:05 < wsa> Niklas
09:05 < wsa> : wants to test if V3U thermal can be supported with existing driver with small changes in polling mode, and work on the additional task about timers
09:05 < wsa> Shimoda-san
09:05 < wsa> : wants to collect more information about R-Car Gen3e, continue to develop R-Car S4 Ethernet driver, continue to investigate SDHI driver's issues, add some pages about eMMC (block merging and PARTUUID) to the elinux wiki
09:05 < wsa> Ulrich
09:05 < wsa> : wants to implement atomic transfers for I2C
09:05 < wsa> Wolfram
09:05 < wsa> : wants to keep working on the open SDHI tickets, enable and test V3U IO devices, guide increase of I2C_M_RECV_LEN length to 255 and upstream R-Car support for it, resend WDT patch to fix scheduling while atomic, start with isolated CPUs as logic analyzers
09:06 < wsa> C - problems I currently have
09:06 < wsa> -----------------------------
09:06 < wsa> Geert
09:06 < wsa> : notes that MSIOF external loopback test fails on R-Car V3U/Falcon, and got no feedback on an IIC patch for the suspended state
09:06 < wsa> geertu: reading A) and C) I didn't really get if MSIOF testing was a success or not?
09:07 < wsa> geertu: and sorry for the i2c-sh_mobile delay. I plan to have a non-SDHI week next week
09:08 <@geertu> wsa: it worked in the sense that the driver didn't complain (e.g no hardware timeout), but the received data over loopback was wrong
09:08 < wsa> marex: lorenzo responded to your PCIe patch. IIRC he asked an outdated question, or?
09:08 < wsa> geertu: and the idea is to wait for the PFC driver to see if it works then?
09:09 < marex> wsa: I still need to read that email
09:09 <@geertu> wsa: Indeed. I may have overlooked something in my manual pinctrl config
09:09 <@geertu> marex: We want it as a fix for v5.9^Wv5.10, no?
09:09 < wsa> marex: ok
09:09 < marex> geertu: it -- the pcie 32bit thing ?
09:10 < wsa> geertu: ok, makes sense
09:10 < wsa> shimoday: I'd like to recap the open SDHI issues, so we know if we are aligned
09:11 < shimoday> wsa: i got it. may i recap open SDHI issues on an email later?
09:12 < wsa> there is the SDHn discussion, where Geert made an interesting suggestion. However, IIUC you implemented an clock framework abuse because it is simpler?
09:12 < wsa> you = you / or the BSP team
09:13 < wsa> and then, there is the open issue of resetting via the reset controller; we have a prototype but are waiting for feedback from the HW team
09:14 < shimoday> wsa: about SDHn, yes, bsp team tried it because it seems easy than Geert-san's suggestion
09:15 < wsa> I hope the "max_busy_timeout" issue is solved with my latest series; we could honor "cmd->busy_timeout" from the MMC core, but this is an additional optimization, something like the cherry on top. Not urgent
09:15 < shimoday> wsa: about reset controller for SDHI, I'm asking hw team but I got any feedback yet
09:16 < shimoday> wsa: about max_busy_timeout, I'm testing it and seems OK
09:16 < wsa> and then, we need to take care of data timeout; I still have to dive into your last email again, but it seems more refactoring of the BSP patch is needed
09:17 < wsa> these are the open issues I have on my list, if you have more, please tell :)
09:18 < shimoday> wsa: about data timeout, yes, i also think we need more refactoring to follow both mmc_test #15 and SDHI manual (retuning)
09:19 < wsa> shimoday: but are you okay that we try Geert's suggestion for upstream (SDHn clock)
09:19 < wsa> ?
09:20 < shimoday> wsa: i have one more thing from bsp team, but I don't ask you yet :)
09:20 < shimoday> bsp team said the mmc performance on v5.4 is lower than v4.14.
09:21 < shimoday> i tried to investiagte this a little, but I'm not sure this is really sdhi driver issue or not
09:22 < shimoday> so, I'll investigate this by myself (sorry, I should report this on today's report)
09:22 < wsa> shimoday: yes, it is hard to say if it is SDHI or MMC core
09:22 < wsa> without specific testing
09:23 < wsa> is it significant?
09:24 < shimoday> wsa: perhaps, it's significant because I guess customer will ask Renesas about this after provided the v5.4 base BSP
09:25 < wsa> yeah, it is important, that is for sure
09:25 < wsa> I mean is the performance loss like 50% or more like 5% or 0.5%?
09:26 < shimoday> according to bsp team report, on v4.14 = 240MB/s (read), on v5.4 = 173MB/s (read)
09:27 < shimoday> if we use IPMMU, on v4.14 = 270MB/s, on v5.4 = 240MB/s
09:27 < shimoday> so, BSP team is worries about non-IPMMU speed
09:28 < wsa> 240 -> 173, that is significant
09:28 <@geertu> sounds like some bounce-buffering is involved if the IPMMU is not used
09:28 < wsa> I'll check why I never noticed sth like that
09:29 < wsa> are there any other questions from you guys?
09:29 < marex> wsa: 173 is HS200, 240 is HS400 ...
09:29 < marex> wsa: so likely HS400 calibration failed
09:29 < shimoday> wsa: thanks!
09:30 < wsa> marex: interestig pointer
09:30 < wsa> thanks!
09:30 <@geertu> marex: Hmm, IPMMU or not should not impact HS400 calib
09:30 < shimoday> marex: i'm sorry, my report "on v4.14" and "on v5.4" are BSPs
09:31 < shimoday> v4.14 means rcar-3.9.x, v5.4 means rcar-4.1.0.rc1
09:31 < shimoday> so, bsp team use HS400 on these kernel versions i think
09:34 < wsa> okay, let's see if I can reproduce the results
09:34 < marex> shimoday: the thing is, if you do sustained block read in HS200, the bus tops at ~170 MiB/s, for HS400 the bus tops at 350 MiB/s , but the card does at 240 MiB/s
09:35 < marex> so the numbers provided would indicate HS400 mode problem
09:35 < marex> probably cat /sys/kernel/debug/mmc*/ios would give you some input quickly
09:36 < marex> geertu: the IPMMU difference is likely due to the buffers being above 32bit boundary, with IPMMU they dont have to be copied back and forth
09:37 <@geertu> marex: yeah, bounce buffers. but v5.4+ipmmu does should hs400 speeds
09:37 <@geertu> s/should/show/
09:39 < marex> geertu: aha, thats a valid point
09:42 < shimoday> marex: thanks. I think so about these speeds. i'll check the ios later
09:42 < wsa> okay
09:42 < wsa> shall we move to core then?
|
