Commit | Line | Data |
---|---|---|
19f6d2a6 OG |
1 | /* |
2 | * Copyright 2014 Advanced Micro Devices, Inc. | |
3 | * | |
4 | * Permission is hereby granted, free of charge, to any person obtaining a | |
5 | * copy of this software and associated documentation files (the "Software"), | |
6 | * to deal in the Software without restriction, including without limitation | |
7 | * the rights to use, copy, modify, merge, publish, distribute, sublicense, | |
8 | * and/or sell copies of the Software, and to permit persons to whom the | |
9 | * Software is furnished to do so, subject to the following conditions: | |
10 | * | |
11 | * The above copyright notice and this permission notice shall be included in | |
12 | * all copies or substantial portions of the Software. | |
13 | * | |
14 | * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR | |
15 | * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, | |
16 | * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL | |
17 | * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR | |
18 | * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, | |
19 | * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR | |
20 | * OTHER DEALINGS IN THE SOFTWARE. | |
21 | * | |
22 | */ | |
23 | ||
24 | #include <linux/device.h> | |
25 | #include <linux/export.h> | |
26 | #include <linux/err.h> | |
27 | #include <linux/fs.h> | |
28 | #include <linux/sched.h> | |
29 | #include <linux/slab.h> | |
30 | #include <linux/uaccess.h> | |
31 | #include <linux/compat.h> | |
32 | #include <uapi/linux/kfd_ioctl.h> | |
33 | #include <linux/time.h> | |
34 | #include "kfd_priv.h" | |
35 | #include <linux/mm.h> | |
2497ee72 | 36 | #include <linux/mman.h> |
19f6d2a6 OG |
37 | #include <asm/processor.h> |
38 | ||
39 | /* | |
40 | * The primary memory I/O features being added for revisions of gfxip | |
41 | * beyond 7.0 (Kaveri) are: | |
42 | * | |
43 | * Access to ATC/IOMMU mapped memory w/ associated extension of VA to 48b | |
44 | * | |
45 | * “Flat” shader memory access – These are new shader vector memory | |
46 | * operations that do not reference a T#/V# so a “pointer” is what is | |
47 | * sourced from the vector gprs for direct access to memory. | |
48 | * This pointer space has the Shared(LDS) and Private(Scratch) memory | |
49 | * mapped into this pointer space as apertures. | |
50 | * The hardware then determines how to direct the memory request | |
51 | * based on what apertures the request falls in. | |
52 | * | |
53 | * Unaligned support and alignment check | |
54 | * | |
55 | * | |
56 | * System Unified Address - SUA | |
57 | * | |
58 | * The standard usage for GPU virtual addresses are that they are mapped by | |
59 | * a set of page tables we call GPUVM and these page tables are managed by | |
60 | * a combination of vidMM/driver software components. The current virtual | |
61 | * address (VA) range for GPUVM is 40b. | |
62 | * | |
63 | * As of gfxip7.1 and beyond we’re adding the ability for compute memory | |
64 | * clients (CP/RLC, DMA, SHADER(ifetch, scalar, and vector ops)) to access | |
65 | * the same page tables used by host x86 processors and that are managed by | |
66 | * the operating system. This is via a technique and hardware called ATC/IOMMU. | |
67 | * The GPU has the capability of accessing both the GPUVM and ATC address | |
68 | * spaces for a given VMID (process) simultaneously and we call this feature | |
69 | * system unified address (SUA). | |
70 | * | |
71 | * There are three fundamental address modes of operation for a given VMID | |
72 | * (process) on the GPU: | |
73 | * | |
74 | * HSA64 – 64b pointers and the default address space is ATC | |
75 | * HSA32 – 32b pointers and the default address space is ATC | |
76 | * GPUVM – 64b pointers and the default address space is GPUVM (driver | |
77 | * model mode) | |
78 | * | |
79 | * | |
80 | * HSA64 - ATC/IOMMU 64b | |
81 | * | |
82 | * A 64b pointer in the AMD64/IA64 CPU architecture is not fully utilized | |
83 | * by the CPU so an AMD CPU can only access the high area | |
84 | * (VA[63:47] == 0x1FFFF) and low area (VA[63:47 == 0) of the address space | |
85 | * so the actual VA carried to translation is 48b. There is a “hole” in | |
86 | * the middle of the 64b VA space. | |
87 | * | |
88 | * The GPU not only has access to all of the CPU accessible address space via | |
89 | * ATC/IOMMU, but it also has access to the GPUVM address space. The “system | |
90 | * unified address” feature (SUA) is the mapping of GPUVM and ATC address | |
91 | * spaces into a unified pointer space. The method we take for 64b mode is | |
92 | * to map the full 40b GPUVM address space into the hole of the 64b address | |
93 | * space. | |
94 | ||
95 | * The GPUVM_Base/GPUVM_Limit defines the aperture in the 64b space where we | |
96 | * direct requests to be translated via GPUVM page tables instead of the | |
97 | * IOMMU path. | |
98 | * | |
99 | * | |
100 | * 64b to 49b Address conversion | |
101 | * | |
102 | * Note that there are still significant portions of unused regions (holes) | |
103 | * in the 64b address space even for the GPU. There are several places in | |
104 | * the pipeline (sw and hw), we wish to compress the 64b virtual address | |
105 | * to a 49b address. This 49b address is constituted of an “ATC” bit | |
106 | * plus a 48b virtual address. This 49b address is what is passed to the | |
107 | * translation hardware. ATC==0 means the 48b address is a GPUVM address | |
108 | * (max of 2^40 – 1) intended to be translated via GPUVM page tables. | |
109 | * ATC==1 means the 48b address is intended to be translated via IOMMU | |
110 | * page tables. | |
111 | * | |
112 | * A 64b pointer is compared to the apertures that are defined (Base/Limit), in | |
113 | * this case the GPUVM aperture (red) is defined and if a pointer falls in this | |
114 | * aperture, we subtract the GPUVM_Base address and set the ATC bit to zero | |
115 | * as part of the 64b to 49b conversion. | |
116 | * | |
117 | * Where this 64b to 49b conversion is done is a function of the usage. | |
118 | * Most GPU memory access is via memory objects where the driver builds | |
119 | * a descriptor which consists of a base address and a memory access by | |
120 | * the GPU usually consists of some kind of an offset or Cartesian coordinate | |
121 | * that references this memory descriptor. This is the case for shader | |
122 | * instructions that reference the T# or V# constants, or for specified | |
123 | * locations of assets (ex. the shader program location). In these cases | |
124 | * the driver is what handles the 64b to 49b conversion and the base | |
125 | * address in the descriptor (ex. V# or T# or shader program location) | |
126 | * is defined as a 48b address w/ an ATC bit. For this usage a given | |
127 | * memory object cannot straddle multiple apertures in the 64b address | |
128 | * space. For example a shader program cannot jump in/out between ATC | |
129 | * and GPUVM space. | |
130 | * | |
131 | * In some cases we wish to pass a 64b pointer to the GPU hardware and | |
132 | * the GPU hw does the 64b to 49b conversion before passing memory | |
133 | * requests to the cache/memory system. This is the case for the | |
134 | * S_LOAD and FLAT_* shader memory instructions where we have 64b pointers | |
135 | * in scalar and vector GPRs respectively. | |
136 | * | |
137 | * In all cases (no matter where the 64b -> 49b conversion is done), the gfxip | |
138 | * hardware sends a 48b address along w/ an ATC bit, to the memory controller | |
139 | * on the memory request interfaces. | |
140 | * | |
141 | * <client>_MC_rdreq_atc // read request ATC bit | |
142 | * | |
143 | * 0 : <client>_MC_rdreq_addr is a GPUVM VA | |
144 | * | |
145 | * 1 : <client>_MC_rdreq_addr is a ATC VA | |
146 | * | |
147 | * | |
148 | * “Spare” aperture (APE1) | |
149 | * | |
150 | * We use the GPUVM aperture to differentiate ATC vs. GPUVM, but we also use | |
151 | * apertures to set the Mtype field for S_LOAD/FLAT_* ops which is input to the | |
152 | * config tables for setting cache policies. The “spare” (APE1) aperture is | |
153 | * motivated by getting a different Mtype from the default. | |
154 | * The default aperture isn’t an actual base/limit aperture; it is just the | |
155 | * address space that doesn’t hit any defined base/limit apertures. | |
156 | * The following diagram is a complete picture of the gfxip7.x SUA apertures. | |
157 | * The APE1 can be placed either below or above | |
158 | * the hole (cannot be in the hole). | |
159 | * | |
160 | * | |
161 | * General Aperture definitions and rules | |
162 | * | |
163 | * An aperture register definition consists of a Base, Limit, Mtype, and | |
164 | * usually an ATC bit indicating which translation tables that aperture uses. | |
165 | * In all cases (for SUA and DUA apertures discussed later), aperture base | |
166 | * and limit definitions are 64KB aligned. | |
167 | * | |
168 | * <ape>_Base[63:0] = { <ape>_Base_register[63:16], 0x0000 } | |
169 | * | |
170 | * <ape>_Limit[63:0] = { <ape>_Limit_register[63:16], 0xFFFF } | |
171 | * | |
172 | * The base and limit are considered inclusive to an aperture so being | |
173 | * inside an aperture means (address >= Base) AND (address <= Limit). | |
174 | * | |
175 | * In no case is a payload that straddles multiple apertures expected to work. | |
176 | * For example a load_dword_x4 that starts in one aperture and ends in another, | |
177 | * does not work. For the vector FLAT_* ops we have detection capability in | |
178 | * the shader for reporting a “memory violation” back to the | |
179 | * SQ block for use in traps. | |
180 | * A memory violation results when an op falls into the hole, | |
181 | * or a payload straddles multiple apertures. The S_LOAD instruction | |
182 | * does not have this detection. | |
183 | * | |
184 | * Apertures cannot overlap. | |
185 | * | |
186 | * | |
187 | * | |
188 | * HSA32 - ATC/IOMMU 32b | |
189 | * | |
190 | * For HSA32 mode, the pointers are interpreted as 32 bits and use a single GPR | |
191 | * instead of two for the S_LOAD and FLAT_* ops. The entire GPUVM space of 40b | |
192 | * will not fit so there is only partial visibility to the GPUVM | |
193 | * space (defined by the aperture) for S_LOAD and FLAT_* ops. | |
194 | * There is no spare (APE1) aperture for HSA32 mode. | |
195 | * | |
196 | * | |
197 | * GPUVM 64b mode (driver model) | |
198 | * | |
199 | * This mode is related to HSA64 in that the difference really is that | |
200 | * the default aperture is GPUVM (ATC==0) and not ATC space. | |
201 | * We have gfxip7.x hardware that has FLAT_* and S_LOAD support for | |
202 | * SUA GPUVM mode, but does not support HSA32/HSA64. | |
203 | * | |
204 | * | |
205 | * Device Unified Address - DUA | |
206 | * | |
207 | * Device unified address (DUA) is the name of the feature that maps the | |
208 | * Shared(LDS) memory and Private(Scratch) memory into the overall address | |
209 | * space for use by the new FLAT_* vector memory ops. The Shared and | |
210 | * Private memories are mapped as apertures into the address space, | |
211 | * and the hardware detects when a FLAT_* memory request is to be redirected | |
212 | * to the LDS or Scratch memory when it falls into one of these apertures. | |
213 | * Like the SUA apertures, the Shared/Private apertures are 64KB aligned and | |
214 | * the base/limit is “in” the aperture. For both HSA64 and GPUVM SUA modes, | |
215 | * the Shared/Private apertures are always placed in a limited selection of | |
216 | * options in the hole of the 64b address space. For HSA32 mode, the | |
217 | * Shared/Private apertures can be placed anywhere in the 32b space | |
218 | * except at 0. | |
219 | * | |
220 | * | |
221 | * HSA64 Apertures for FLAT_* vector ops | |
222 | * | |
223 | * For HSA64 SUA mode, the Shared and Private apertures are always placed | |
224 | * in the hole w/ a limited selection of possible locations. The requests | |
225 | * that fall in the private aperture are expanded as a function of the | |
226 | * work-item id (tid) and redirected to the location of the | |
227 | * “hidden private memory”. The hidden private can be placed in either GPUVM | |
228 | * or ATC space. The addresses that fall in the shared aperture are | |
229 | * re-directed to the on-chip LDS memory hardware. | |
230 | * | |
231 | * | |
232 | * HSA32 Apertures for FLAT_* vector ops | |
233 | * | |
234 | * In HSA32 mode, the Private and Shared apertures can be placed anywhere | |
235 | * in the 32b space except at 0 (Private or Shared Base at zero disables | |
236 | * the apertures). If the base address of the apertures are non-zero | |
237 | * (ie apertures exists), the size is always 64KB. | |
238 | * | |
239 | * | |
240 | * GPUVM Apertures for FLAT_* vector ops | |
241 | * | |
242 | * In GPUVM mode, the Shared/Private apertures are specified identically | |
243 | * to HSA64 mode where they are always in the hole at a limited selection | |
244 | * of locations. | |
245 | * | |
246 | * | |
247 | * Aperture Definitions for SUA and DUA | |
248 | * | |
249 | * The interpretation of the aperture register definitions for a given | |
250 | * VMID is a function of the “SUA Mode” which is one of HSA64, HSA32, or | |
251 | * GPUVM64 discussed in previous sections. The mode is first decoded, and | |
252 | * then the remaining register decode is a function of the mode. | |
253 | * | |
254 | * | |
255 | * SUA Mode Decode | |
256 | * | |
257 | * For the S_LOAD and FLAT_* shader operations, the SUA mode is decoded from | |
258 | * the COMPUTE_DISPATCH_INITIATOR:DATA_ATC bit and | |
259 | * the SH_MEM_CONFIG:PTR32 bits. | |
260 | * | |
261 | * COMPUTE_DISPATCH_INITIATOR:DATA_ATC SH_MEM_CONFIG:PTR32 Mode | |
262 | * | |
263 | * 1 0 HSA64 | |
264 | * | |
265 | * 1 1 HSA32 | |
266 | * | |
267 | * 0 X GPUVM64 | |
268 | * | |
269 | * In general the hardware will ignore the PTR32 bit and treat | |
270 | * as “0” whenever DATA_ATC = “0”, but sw should set PTR32=0 | |
271 | * when DATA_ATC=0. | |
272 | * | |
273 | * The DATA_ATC bit is only set for compute dispatches. | |
274 | * All “Draw” dispatches are hardcoded to GPUVM64 mode | |
275 | * for FLAT_* / S_LOAD operations. | |
276 | */ | |
277 | ||
70a31d16 | 278 | #define MAKE_GPUVM_APP_BASE_VI(gpu_num) \ |
585dbf38 | 279 | (((uint64_t)(gpu_num) << 61) + 0x1000000000000L) |
19f6d2a6 | 280 | |
d01994c2 FK |
281 | #define MAKE_GPUVM_APP_LIMIT(base, size) \ |
282 | (((uint64_t)(base) & 0xFFFFFF0000000000UL) + (size) - 1) | |
19f6d2a6 | 283 | |
70a31d16 | 284 | #define MAKE_SCRATCH_APP_BASE_VI() \ |
c7bcbfa4 | 285 | (((uint64_t)(0x1UL) << 61) + 0x100000000L) |
19f6d2a6 OG |
286 | |
287 | #define MAKE_SCRATCH_APP_LIMIT(base) \ | |
585dbf38 | 288 | (((uint64_t)base & 0xFFFFFFFF00000000UL) | 0xFFFFFFFF) |
19f6d2a6 | 289 | |
70a31d16 | 290 | #define MAKE_LDS_APP_BASE_VI() \ |
c7bcbfa4 | 291 | (((uint64_t)(0x1UL) << 61) + 0x0) |
19f6d2a6 | 292 | #define MAKE_LDS_APP_LIMIT(base) \ |
585dbf38 | 293 | (((uint64_t)(base) & 0xFFFFFFFF00000000UL) | 0xFFFFFFFF) |
19f6d2a6 | 294 | |
70a31d16 FK |
295 | /* On GFXv9 the LDS and scratch apertures are programmed independently |
296 | * using the high 16 bits of the 64-bit virtual address. They must be | |
297 | * in the hole, which will be the case as long as the high 16 bits are | |
298 | * not 0. | |
299 | * | |
300 | * The aperture sizes are still 4GB implicitly. | |
301 | * | |
302 | * A GPUVM aperture is not applicable on GFXv9. | |
303 | */ | |
304 | #define MAKE_LDS_APP_BASE_V9() ((uint64_t)(0x1UL) << 48) | |
305 | #define MAKE_SCRATCH_APP_BASE_V9() ((uint64_t)(0x2UL) << 48) | |
306 | ||
d01994c2 FK |
307 | /* User mode manages most of the SVM aperture address space. The low |
308 | * 16MB are reserved for kernel use (CWSR trap handler and kernel IB | |
309 | * for now). | |
310 | */ | |
311 | #define SVM_USER_BASE 0x1000000ull | |
312 | #define SVM_CWSR_BASE (SVM_USER_BASE - KFD_CWSR_TBA_TMA_SIZE) | |
313 | #define SVM_IB_BASE (SVM_CWSR_BASE - PAGE_SIZE) | |
314 | ||
70a31d16 FK |
315 | static void kfd_init_apertures_vi(struct kfd_process_device *pdd, uint8_t id) |
316 | { | |
317 | /* | |
318 | * node id couldn't be 0 - the three MSB bits of | |
8cd29608 | 319 | * aperture shouldn't be 0 |
70a31d16 FK |
320 | */ |
321 | pdd->lds_base = MAKE_LDS_APP_BASE_VI(); | |
322 | pdd->lds_limit = MAKE_LDS_APP_LIMIT(pdd->lds_base); | |
323 | ||
6127896f | 324 | if (!pdd->dev->use_iommu_v2) { |
70a31d16 FK |
325 | /* dGPUs: SVM aperture starting at 0 |
326 | * with small reserved space for kernel. | |
327 | * Set them to CANONICAL addresses. | |
328 | */ | |
329 | pdd->gpuvm_base = SVM_USER_BASE; | |
330 | pdd->gpuvm_limit = | |
331 | pdd->dev->shared_resources.gpuvm_size - 1; | |
332 | } else { | |
333 | /* set them to non CANONICAL addresses, and no SVM is | |
334 | * allocated. | |
335 | */ | |
336 | pdd->gpuvm_base = MAKE_GPUVM_APP_BASE_VI(id + 1); | |
337 | pdd->gpuvm_limit = MAKE_GPUVM_APP_LIMIT(pdd->gpuvm_base, | |
338 | pdd->dev->shared_resources.gpuvm_size); | |
339 | } | |
340 | ||
341 | pdd->scratch_base = MAKE_SCRATCH_APP_BASE_VI(); | |
342 | pdd->scratch_limit = MAKE_SCRATCH_APP_LIMIT(pdd->scratch_base); | |
343 | } | |
344 | ||
345 | static void kfd_init_apertures_v9(struct kfd_process_device *pdd, uint8_t id) | |
346 | { | |
347 | pdd->lds_base = MAKE_LDS_APP_BASE_V9(); | |
348 | pdd->lds_limit = MAKE_LDS_APP_LIMIT(pdd->lds_base); | |
349 | ||
350 | /* Raven needs SVM to support graphic handle, etc. Leave the small | |
351 | * reserved space before SVM on Raven as well, even though we don't | |
352 | * have to. | |
353 | * Set gpuvm_base and gpuvm_limit to CANONICAL addresses so that they | |
354 | * are used in Thunk to reserve SVM. | |
355 | */ | |
356 | pdd->gpuvm_base = SVM_USER_BASE; | |
357 | pdd->gpuvm_limit = | |
358 | pdd->dev->shared_resources.gpuvm_size - 1; | |
359 | ||
360 | pdd->scratch_base = MAKE_SCRATCH_APP_BASE_V9(); | |
361 | pdd->scratch_limit = MAKE_SCRATCH_APP_LIMIT(pdd->scratch_base); | |
362 | } | |
363 | ||
19f6d2a6 OG |
364 | int kfd_init_apertures(struct kfd_process *process) |
365 | { | |
366 | uint8_t id = 0; | |
367 | struct kfd_dev *dev; | |
368 | struct kfd_process_device *pdd; | |
369 | ||
19f6d2a6 | 370 | /*Iterating over all devices*/ |
6aac0a48 | 371 | while (kfd_topology_enum_kfd_devices(id, &dev) == 0) { |
6b855f7b HK |
372 | if (!dev || kfd_devcgroup_check_permission(dev)) { |
373 | /* Skip non GPU devices and devices to which the | |
374 | * current process have no access to. Access can be | |
375 | * limited by placing the process in a specific | |
376 | * cgroup hierarchy | |
377 | */ | |
378 | id++; | |
6d82eb0e HK |
379 | continue; |
380 | } | |
381 | ||
093c7d8c | 382 | pdd = kfd_create_process_device_data(dev, process); |
4eacc26b | 383 | if (!pdd) { |
093c7d8c | 384 | pr_err("Failed to create process device data\n"); |
70a31d16 | 385 | return -ENOMEM; |
093c7d8c | 386 | } |
19f6d2a6 | 387 | /* |
c7bcbfa4 | 388 | * For 64 bit process apertures will be statically reserved in |
19f6d2a6 OG |
389 | * the x86_64 non canonical process address space |
390 | * amdkfd doesn't currently support apertures for 32 bit process | |
391 | */ | |
392 | if (process->is_32bit_user_mode) { | |
393 | pdd->lds_base = pdd->lds_limit = 0; | |
394 | pdd->gpuvm_base = pdd->gpuvm_limit = 0; | |
395 | pdd->scratch_base = pdd->scratch_limit = 0; | |
396 | } else { | |
70a31d16 FK |
397 | switch (dev->device_info->asic_family) { |
398 | case CHIP_KAVERI: | |
399 | case CHIP_HAWAII: | |
400 | case CHIP_CARRIZO: | |
401 | case CHIP_TONGA: | |
402 | case CHIP_FIJI: | |
403 | case CHIP_POLARIS10: | |
404 | case CHIP_POLARIS11: | |
846a44d7 | 405 | case CHIP_POLARIS12: |
ed81cd6e | 406 | case CHIP_VEGAM: |
70a31d16 FK |
407 | kfd_init_apertures_vi(pdd, id); |
408 | break; | |
409 | case CHIP_VEGA10: | |
846a44d7 | 410 | case CHIP_VEGA12: |
22a3a294 | 411 | case CHIP_VEGA20: |
70a31d16 | 412 | case CHIP_RAVEN: |
4d85488c | 413 | case CHIP_RENOIR: |
49adcf8a | 414 | case CHIP_ARCTURUS: |
36e22d59 | 415 | case CHIP_ALDEBARAN: |
14328aa5 | 416 | case CHIP_NAVI10: |
0e94b564 | 417 | case CHIP_NAVI12: |
8099ae40 | 418 | case CHIP_NAVI14: |
3a2f0c81 | 419 | case CHIP_SIENNA_CICHLID: |
de89b2e4 | 420 | case CHIP_NAVY_FLOUNDER: |
3a5e715d | 421 | case CHIP_VANGOGH: |
eb5a34d4 | 422 | case CHIP_DIMGREY_CAVEFISH: |
70a31d16 FK |
423 | kfd_init_apertures_v9(pdd, id); |
424 | break; | |
425 | default: | |
426 | WARN(1, "Unexpected ASIC family %u", | |
427 | dev->device_info->asic_family); | |
428 | return -EINVAL; | |
429 | } | |
d01994c2 | 430 | |
6127896f | 431 | if (!dev->use_iommu_v2) { |
70a31d16 FK |
432 | /* dGPUs: the reserved space for kernel |
433 | * before SVM | |
d01994c2 | 434 | */ |
d01994c2 FK |
435 | pdd->qpd.cwsr_base = SVM_CWSR_BASE; |
436 | pdd->qpd.ib_base = SVM_IB_BASE; | |
437 | } | |
19f6d2a6 OG |
438 | } |
439 | ||
440 | dev_dbg(kfd_device, "node id %u\n", id); | |
441 | dev_dbg(kfd_device, "gpu id %u\n", pdd->dev->id); | |
442 | dev_dbg(kfd_device, "lds_base %llX\n", pdd->lds_base); | |
443 | dev_dbg(kfd_device, "lds_limit %llX\n", pdd->lds_limit); | |
444 | dev_dbg(kfd_device, "gpuvm_base %llX\n", pdd->gpuvm_base); | |
445 | dev_dbg(kfd_device, "gpuvm_limit %llX\n", pdd->gpuvm_limit); | |
446 | dev_dbg(kfd_device, "scratch_base %llX\n", pdd->scratch_base); | |
447 | dev_dbg(kfd_device, "scratch_limit %llX\n", pdd->scratch_limit); | |
448 | ||
449 | id++; | |
450 | } | |
451 | ||
19f6d2a6 OG |
452 | return 0; |
453 | } |