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
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
|
08:59 < wsa_> hi guys!
08:59 -!- uli__ [~uli___@static.206.203.46.78.clients.your-server.de] has joined #periperi
08:59 < geertu> Mornin'
08:59 < jmondi> 'morning!
09:00 < uli__> good morning
09:01 < morimoto> Marex: I will bring your sound board in next ELCE ;P
09:02 < Marex> morimoto: nice, thank you :-)
09:02 < wsa_> morimoto: do you know if Shimoda-san will attend the meeting?
09:02 < Marex> morimoto: at least we know where the problem is now
09:02 < morimoto> wsa_: Now shimoda-san is talking to our Boss.
09:02 < wsa_> I see
09:03 < wsa_> So, I guess we'll start then
09:03 < morimoto> Marex: the most biggest problem is that I have it ;P
09:03 < Marex> morimoto: why so ?
09:03 < morimoto> It means, I have your sound board. You can't fix it, right
09:04 < Marex> btw minor announcement regarding prague taxis and their price, I was just reading an article today about that in local news
09:04 < Marex> they did a test with local people and some foreigners and apparently there was some difference, so please be a bit careful
09:04 < wsa_> so, welcome to the io meeting! I collected all the status updates from you guys and will paste them now. After that, there is room for questions
09:04 < wsa_> A)
09:04 < wsa_> Geert:
09:04 < wsa_> - Sent patch to consolidate RAVB clock handling.
09:04 < wsa_> Simon:
09:04 < wsa_> - Began backporting HS400 from BSP
09:04 < wsa_> - Posted fallback bindings for SDHI and SH-Eth
09:04 < wsa_> - Posted and merged patches to use R-Car GPIO fallback bindings
09:04 < wsa_> Niklas:
09:04 < wsa_> - [RFC] mmc: tmio: fix tuning for stubborn cards
09:04 < wsa_> Not sure if I should repost this as a PATCH, got positive
09:04 < wsa_> feedback from Simon.
09:04 < wsa_> - Familiarised my self with SDIO and the basics of tuning
09:04 < wsa_> SDR50/SDR104.
09:04 < wsa_> Shimoda-san:
09:04 < wsa_> - Investigate MMC driver issues in v4.14-rc3.
09:04 < wsa_> - Submitted the following patch(es):
09:04 < wsa_> - Modify phy-rcar-gen3-usb2 driver for R-Car D3 support.
09:04 < wsa_> - Fix the SDHI driver for v4.14, but needs update the patch.
09:04 < wsa_> - Merged the following patch(es) into the subsystem:
09:04 < wsa_> - Add support suspend/resume and generic phy for USB3.0 peripheral.
09:04 < wsa_> - Add R-Car D3 support for phy-rcar-gen3-usb2 driver.
09:04 < wsa_> Wolfram:
09:04 < wsa_> * sent out PFC patches for HSCIF on XS
09:04 < wsa_> * discuss use of mmc_regulator_get_supply() and fix drivers
09:04 < wsa_> * resent eMMC driver strength patches addressing comments from Ulf
09:04 < wsa_> * implemented the missing bits for the I2C DMA series
09:04 < wsa_> * various SDHI discussions
09:04 < wsa_> * various I2C/IIC/RIIC discussions
09:04 < wsa_> * reviewed a few patches
09:04 < wsa_> * last Q4 add tasks on the way now
09:04 < wsa_> * started working on my talk for ELCE
09:04 < wsa_> B)
09:04 < wsa_> Geert:
09:04 < wsa_> - Rework EtherAVB PHY reset according to review comments
09:04 < wsa_> (Sergei's old patches look promising),
09:04 < wsa_> - MSIOF (add. task + issues reported by Dirk Behme).
09:04 < wsa_> Simon:
09:04 < wsa_> - Continue HS400 work
09:04 < wsa_> Niklas:
09:04 < wsa_> - Help Wolfram with more SDIO tests if he needs it.
09:04 < wsa_> Shimoda-san:
09:04 < wsa_> - Fix USBHS driver more if I got feedback from HW team.
09:04 < wsa_> - Continue to investigate how to implement bugfix code for MMC world.
09:04 < wsa_> - Continue to watch if Sergei submits updated patch for phylib gpio-reset.
09:04 < wsa_> Or, do I misunderstand somethings?
09:04 < wsa_> https://marc.info/?l=linux-netdev&m=150755343716727&w=2
09:04 < wsa_> Wolfram:
09:04 < wsa_> * finish talk for ELCE
09:04 < wsa_> * add arbitration_lost_test to i2c_fault_injector and resend
09:04 < wsa_> * test I2C DMA patches and resend
09:04 < wsa_> * start working on no_busy_looping in MMC core
09:04 < wsa_> * verify Niklas' SDR findings
09:04 < wsa_> C)
09:04 < wsa_> Shimoda-san:
09:04 < wsa_> - HW team of USB area always blocks my works...
09:04 < wsa_> - Maintainer(s) doesn't review the following patch(es) yet...:
09:04 < wsa_> - Add PWM dt-binding for r8a77995.
09:04 < wsa_> Wolfram:
09:04 < wsa_> * private life issues usually have bad timing
09:05 < Marex> the distance from the airport to the city center is about 16 km and price per km is ~28 CZK, so that should give you the idea of how much and how long it takes
09:06 < wsa_> neg: please wait with resending the SDR tuning patch until I had the chance to test it
09:07 < neg> wsa_: OK, will do
09:07 < wsa_> geertu: i assume your "Rework EtherAVB PHY reset" is the same as what shimoda-san mentioned with "Continue to watch if Sergei submits updated patch for phylib gpio-reset"?
09:08 < horms> shimoda-san: in general i advise against waiting for sergei, i would take over anything you need done quckly. i would tell him if you think he would mind - probably he will not
09:08 < geertu> wsa_: Yes it is
09:08 < wsa_> good
09:08 < geertu> horms: I'll take over the series, It already works as-is.
09:08 < horms> good plan
09:09 < wsa_> so, then there is this swiotlb thing
09:10 < geertu> Commit 7453c549f5f6485c ("swiotlb: Export swiotlb_max_segment to users") appears to be the solution?
09:10 < wsa_> this has turned into a core issue IIUC?
09:10 < geertu> It's in v4.10 and later
09:10 -!- shimoda [~shimoda@relprex1.renesas.com] has joined #periperi
09:10 < shimoda> sorry for the delayed
09:10 < geertu> Let's repeat
09:10 < geertu> Commit 7453c549f5f6485c ("swiotlb: Export swiotlb_max_segment to users") appears to be the solution?
09:11 < wsa_> hello shimoda-san
09:11 < geertu> It's in v4.10 and later
09:11 < shimoda> geertu: I don't think so, because
09:12 < shimoda> a mmc device cannot recognise which ops (swiotlb or iommu) is used
09:12 < shimoda> on local code of mine, some api seems to detect it
09:12 < geertu> Indeed, the check is not a real runtime check
09:13 < geertu> On arm64, it will always limit the size, as swiotlb is always compiled in.
09:13 * pinchartl has to leave for a bit, I'll be back in 45 minutes at the latest
09:13 < shimoda> the api is of_iommu_configure().
09:15 < shimoda> if the return value is not null, we can assume the device is on iommu.
09:15 < geertu> Thatg's called by core device code?
09:16 < shimoda> on my local code, it's called by sdhi code, not core device code. but i guess core device code can use it
09:17 < geertu> It's called from drivers/of/device.c:of_dma_configure
09:18 < geertu> which is called from drivers/base/dma-mapping.c:dma_configure()
09:18 < shimoda> in my opinion, we should fix this issue in v4.14. so, i'd like to apply a workaround code (adjust max_req_size) into v4.14. is it reasonable?
09:18 < wsa_> uli__: about the receive margin thing: any idea how to set it up without sysfs?
09:18 < geertu> whcih is called from drivers/base/dd.c:really_probe(), i.e. for all devices
09:19 < uli__> no, none yet
09:19 < geertu> uli__: Have you noticed any improvements by fiddling with the sampling point?
09:19 < uli__> it behaves as you would expect; shifting the sampling point down adds margin at the lower and and removes it at the higher end
09:19 < uli__> and vice versa
09:20 < geertu> uli__: So you can derive a formula to calculate optimal sampling point for sepcific requested bps?
09:20 < geertu> s/sepcific/specific/
09:21 < uli__> yes, but i am not sure about how this should behave when you change the baud rate
09:21 < geertu> shimoda: Can you look at the dma_ops configured for the device?
09:21 < geertu> uli__: What do you mean? Can't you just recalculate?
09:22 < uli__> yes, but that makes little sense; if you have a device connected that deviates, it will not deviate the same way at different baud rates
09:22 < uli__> so scaling is not helpful
09:22 < uli__> resetting is even worse, it's a biting-the-carpet bug generator for userspace
09:23 < geertu> uli__: Ah, so the goal is to accomodate an off device at the other side.
09:23 < uli__> yes
09:23 < horms> shimoda: assuming the problem was introduced in v4.14 then fixing it there seems to be a good idea. and providing a simple fix/work around sounds appropriate if a full fix is too invasive.
09:23 < geertu> Then you need a way to communicate the other side's rate to the driver => sysfs?
09:23 < uli__> exactly
09:23 < geertu> Or ioctl. Ugh
09:24 < uli__> and that gregkh doesn't like new sysfs attributes doesn't help either
09:24 < geertu> But it can also be used if the local scif cannot support the exact requested rate, right?
09:25 < shimoda> geertu: you're request means what of_dma_configure() output the message? dev_dbg(dev, "device is%sbehind an iommu\n", iommu ? " " : " not ");
09:25 < geertu> shimoda: I mean if the MMC driver can figure out if the IOMMU is used by looking at its dma_ops
09:26 < geertu> I believe of_dma_configure() is already called anyway.
09:26 < shimoda> horms: thank you for your comment! I will add such document and submit v2 patch
09:26 < uli__> geertu: that is also possible, but it's not the use case i have looked into
09:26 < geertu> uli__: OK. But it's something that doesn't rely on sysfs ;-)
09:27 < geertu> So for now you could calculate sampling point based on requested rate vs. scif-supported rate.
09:28 < geertu> Later it can be extended to remote-supported rate vs. scif-supported rate
09:28 < uli__> that would probably work
09:28 < geertu> The latter of course depends on discussing with Greg and friends about a good way to configue remote-supported rate
09:28 < geertu> Does that make sense?
09:29 < uli__> i think it does
09:30 < wsa_> shimoda: was my mail about your IIC requests helpful to you?
09:31 < shimoda> geertu: i don't think dma_ops is useful to figure out if the iommu ise used or not because dma_ops only has function pointers. So, it is diffcult to use on multiple arch.
09:32 < shimoda> wsa_: I'm sorry, i need to read your comment more about stop condition.
09:32 < geertu> shimoda: OK. Then we have to bring up to Konrad that we can use his suggestion as a temporary workaround, but that it doesn't solve the full problem (i.e. it limits mapping size if the device uses the IOMMU)
09:33 < wsa_> shimoda: i see, no worries. Please ask if there are still questions or if it is more urgent
09:33 < horms> can you use dma_ops like this? if (dma_ops == renesas_sdhi_sys_dmac_dma_ops) ...
09:34 < shimoda> geertu: ok. you means we should use his suggested api on the sdhi driver instead of hardcoded value of max_blk_size?
09:35 < geertu> shimoda: Yes. If swiotlb_set_max_segment() returns non-zero, we should use the returned value.
09:35 < shimoda> wsa_: i got it. thanks!
09:35 < shimoda> geertu: i got it!
09:35 < geertu> shimoda: Optimization for IOMMU can be done later
09:35 < geertu> Correctness first ;-)
09:35 < wsa_> swiotlb_max_segment()
09:36 < wsa_> not swiotlb_set_max_segment
09:36 < geertu> wsa_: Thanks, copy-and-pasted the wrong fucntion
09:36 < geertu> s/fucntion/function/
09:36 < wsa_> :)
09:36 < wsa_> ok, i think that was it for io?
09:37 < neg> One question is thermeal driver support IO or Core ? :-)
09:37 < geertu> neg: If you want to control e.g. CPUFreq, it's core
09:37 < geertu> neg: If it's just about measuring temperatures, it's I/O
09:38 < geertu> wsa_: Do you agree? ;-)
09:38 < wsa_> I was about to write the same thing, yes
09:38 < wsa_> :)
09:38 < neg> OK I'm thinking about thermal readig of temps for V3M, so then I guess it's IO :-) Do we have a request/plan for V3M support as it looks like this will be different from rcar_gen3_thermal
09:39 < wsa_> neg: I didn't get anything like that yet
09:40 < wsa_> I didn't get any request for V3M yet
09:40 < neg> wsa_: OK I just wanted you (or Geert if it where Core ;-) to be aware of the hardware difference that is all :-)
09:40 < wsa_> ok, thanks!
09:41 < wsa_> so, it's core time now...
09:41 < wsa_> thanks guys! happy hacking...
09:41 < geertu> wsa_: Thank you!
|
