wiki/Chat_log/20160412-core-chatlog


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
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204

Core-chat-meeting-2016-04-12

10:10 < geertu> Agenda:
10:10 < geertu> 1. Upcoming Gen3 development for the Core group,
10:10 < geertu> 2. Firmware upgrade and consequences (hotplug, DDR, ...)
10:10 < geertu> 3. Does it make sense to have "renesas,cpg = <&cpg_clocks>;" in the SYSC device node? Or do we want to avoid that at all cost?
10:10 < geertu> 4. Status check for tasks from last meeting - what is remaining?
10:10 < geertu> horms: So that would mostly by Topics 1 and 2?
10:10 < geertu> s/1 and 2/2 and 3/?
10:10 < geertu> Topic 2. Firmware upgrade and consequences (hotplug, DDR, ...)
10:10 < geertu> horms: You've already tried v2.7.0?
10:10 < horms> geertu: yes, i lightly tested it
10:11 < horms> hotplug appears to work as per my email
10:11 < khiemnguyen> For topic 2, what is current version that all are using ? Yocto v2.3.0 ?
10:11 < horms> so that seems positive
10:11 < geertu> v2.5.0, IIRC
10:11 < geertu> Any known regressions?
10:11 < khiemnguyen> yes, hotplug has been able to work from Yocto v2.4.0
10:11 < horms> n.b. firmware version != yocto version
10:12 < horms> I think geert was referring to the former
10:12 < geertu> khiemnguyen: Only the first time. After hot-unplug, hot-plug no longer works in v2.5.0
10:12 < horms> _I_ am not aware of any regressions
10:12 < khiemnguyen> you tried with CPU0, right ?
10:12 < horms> let me check
10:12 < khiemnguyen> CPU0 has a limitation for CPU Hotplug, since the secure side will run some secure services in CPU0 all the time.
10:13 < khiemnguyen> Please try CPU Hotplug with CPU1/2/3 only.
10:13 < horms> I only tried CPU1
10:13 < horms> What happens on CPU0?
10:14 < khiemnguyen> the secure side will run some secure services in CPU0 all the time.
10:14 < khiemnguyen> CPU0 should not be hotplug.
10:14 < horms> ok
10:15 < horms> so if it is unplugged we might see some problems? like undefinded behaviour?
10:15 < khiemnguyen> so if it is unplugged we might see some problems? like undefinded behaviour?  --> yes.
10:16 < geertu> Hmm...
10:16 < geertu> It would be better if the operation just failed with an error code
10:16 < horms> yes, i think we should disallow it somehow
10:16 < geertu> Else we have to explicitly have a check to prevent the user from doing that
10:17 < horms> oh, you mean the fimrware should return an error?
10:17 < khiemnguyen> Yes. But the firmware has not supported that feature yet.
10:18 < geertu> horms: Yes, I mean the firmware
10:18 < khiemnguyen> Therefore, in in-house BSP, I have created a work-around patch to disable CPUHotplug request in CPU0.
10:18 < pinchartl> as it's a firmware requirement that CPU0 can't be unplugged, it would make sense for the firmware to implement the check
10:18 < horms> khiemnguyen: ok. good to know. do you know if that is planned?
10:19 < khiemnguyen> as it's a firmware requirement that CPU0 can't be unplugged, it would make sense for the firmware to implement the check  ---> but they put it as low-priority now. since we also has a work-round patch in Linux kernel.
10:19 < horms> ok. but from an upstream point of view it seems like a priority. could you pass that information on?
10:19 < geertu> khiemnguyen: if we include the workaround in upstream, ideally it should check for the firmware version, to know when to apply it or not.
10:20 < geertu> And the question remains where in the code to put the check (no board code)
10:20 < khiemnguyen> do you know if that is planned?  ---> official support in firmware might be available by E/this year, I heard.
10:20 < pinchartl> geertu: I'd keep the workaround away from upstream
10:21 < pinchartl> upstreaming CPU hotplug would then require a firmware that supports hotplug properly
10:21 < pinchartl> putting some pressure to implement that :-)
10:21 < khiemnguyen> And the question remains where in the code to put the check (no board code)  ---> huhm..., to check firmware version, we need more than that, need optee linux driver to communicate with secure side.
10:21 < geertu> pinchartl: Even better. Except that we alrady have hotplug in upstream/
10:21 < horms> pinchartl: fwiw, CPU hotplug is already upstream
10:22 < pinchartl> well, fixing it upstream then I suppose :-)
10:22 < khiemnguyen> yeah, CPU Hotplug is already supported in usptream, for CPU1/2/3, given that the firmware is taken from Yocto v2.4.0 or later.
10:24 < geertu> Things like CPU hotplug are enabled automagically once you have a PSCI platform.
10:24 < geertu> Whether they work or not is a different issue...
10:24 < shimoda> FYI, khiem-san's workaround is 9c910ad5a1e60b302e88ef394bcff84018e69adc in renesas-bsp.git
10:25 < horms> khiemnguyen: is there any possibility we could ask for the feature to be in firmware sooner than later. it would really help things on the upstream side.
10:26 < geertu> BTW, what's "DDR training"?
10:26 < khiemnguyen> Let me know the feature, will try to confirm with secure team.
10:27 < horms> khiemnguyen: thanks. I think the feature request is to return an error for a request to take CPU0 down.
10:27 < horms> so long as doing so causes problems.
10:27 < khiemnguyen> DDR training is rountine activity to check SDRAM operation and adjust SDRAM parameters for best performance.