diff options
author | Chris Metcalf <cmetcalf@tilera.com> | 2010-07-02 14:19:35 -0400 |
---|---|---|
committer | Chris Metcalf <cmetcalf@tilera.com> | 2010-07-06 13:42:15 -0400 |
commit | ef06f55a5c936a395f3ee2e1237bbebdb4396c65 (patch) | |
tree | fce333d35dc147020a773ec36cfdb17690e2f00a /arch/tile/include/asm/processor.h | |
parent | bcd97c3f9a385e8e658a416cd72dd65ca0eeb544 (diff) |
arch/tile: catch up on various minor cleanups.
None of these changes fix any actual bugs, but are just various cleanups
that fell out along the way. In particular, some unused #defines and
includes are removed, PREFETCH_STRIDE is added (the default is right for
our shipping chips, but wrong for our next generation), our tile-specific
prefetching code is removed so the (identical) generic prefetching code
can be used instead, a comment is fixed to be proper GPL and not just a
"paste GPL here" token, a "//" comment is converted to "/* */", etc.
Signed-off-by: Chris Metcalf <cmetcalf@tilera.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Diffstat (limited to 'arch/tile/include/asm/processor.h')
-rw-r--r-- | arch/tile/include/asm/processor.h | 24 |
1 files changed, 6 insertions, 18 deletions
diff --git a/arch/tile/include/asm/processor.h b/arch/tile/include/asm/processor.h index 09584e263b00..d942d09b252e 100644 --- a/arch/tile/include/asm/processor.h +++ b/arch/tile/include/asm/processor.h | |||
@@ -267,32 +267,20 @@ extern int hash_default; | |||
267 | 267 | ||
268 | /* Should kernel stack pages be hash-for-home? */ | 268 | /* Should kernel stack pages be hash-for-home? */ |
269 | extern int kstack_hash; | 269 | extern int kstack_hash; |
270 | |||
271 | /* Does MAP_ANONYMOUS return hash-for-home pages by default? */ | ||
272 | #define uheap_hash hash_default | ||
273 | |||
270 | #else | 274 | #else |
271 | #define hash_default 0 | 275 | #define hash_default 0 |
272 | #define kstack_hash 0 | 276 | #define kstack_hash 0 |
277 | #define uheap_hash 0 | ||
273 | #endif | 278 | #endif |
274 | 279 | ||
275 | /* Are we using huge pages in the TLB for kernel data? */ | 280 | /* Are we using huge pages in the TLB for kernel data? */ |
276 | extern int kdata_huge; | 281 | extern int kdata_huge; |
277 | 282 | ||
278 | /* | 283 | #define PREFETCH_STRIDE CHIP_L2_LINE_SIZE() |
279 | * Note that with OLOC the prefetch will return an unused read word to | ||
280 | * the issuing tile, which will cause some MDN traffic. Benchmarking | ||
281 | * should be done to see whether this outweighs prefetching. | ||
282 | */ | ||
283 | #define ARCH_HAS_PREFETCH | ||
284 | #define ARCH_HAS_PREFETCHW | ||
285 | #define ARCH_HAS_SPINLOCK_PREFETCH | ||
286 | |||
287 | #define prefetch(ptr) __builtin_prefetch((ptr), 0, 3) | ||
288 | #define prefetchw(ptr) __builtin_prefetch((ptr), 1, 3) | ||
289 | |||
290 | #ifdef CONFIG_SMP | ||
291 | #define spin_lock_prefetch(ptr) prefetchw(ptr) | ||
292 | #else | ||
293 | /* Nothing to prefetch. */ | ||
294 | #define spin_lock_prefetch(lock) do { } while (0) | ||
295 | #endif | ||
296 | 284 | ||
297 | #else /* __ASSEMBLY__ */ | 285 | #else /* __ASSEMBLY__ */ |
298 | 286 | ||