search for: emit32

...has lib/support/endian.h. Wouldn't the new API be redundant? If > not, would it fit in that header? They're obviously related. Endian.h defines types like ulittle32, which DTRT when read and written from memory, whereas clang::io has functions to read and write memory like so: void Emit32(raw_ostream& Out, uint32_t V); uint32_t ReadLE32(const unsigned char *&Data); uint32_t ReadUnalignedLE32(const unsigned char *&Data); The (aligned) ReadLE32 is easily represented by the stuff in Endian.h, but the write to an ostream and reading unaligned aren't addressed ve...

...eau_fence *, bool lazy, bool intr); -int nouveau_fence_sync(struct nouveau_fence *, struct nouveau_channel *); +int nouveau_fence_sync(struct nouveau_bo *, struct nouveau_channel *); struct nouveau_fence_chan { struct list_head pending; @@ -38,8 +41,10 @@ struct nouveau_fence_chan { int (*emit32)(struct nouveau_channel *, u64, u32); int (*sync32)(struct nouveau_channel *, u64, u32); - spinlock_t lock; + spinlock_t *lock; u32 sequence; + u32 context; + char name[24]; }; struct nouveau_fence_priv { @@ -49,13 +54,14 @@ struct nouveau_fence_priv { int (*context_new)(struct nouvea...

I would like to use the on disk hash table that's currently in clang for instrumentation based profiling. This is a single header file that's currently found in include/clang/Basic/OnDiskHashTable.h, and I propose to move it to include/llvm/Support/OnDiskHashTable.h. Any strong objections to moving this? Also, the header includes a "clang::io" namespace with some operations for

Rafael Espíndola <rafael.espindola at gmail.com> writes: >> They're obviously related. Endian.h defines types like ulittle32, which >> DTRT when read and written from memory, whereas clang::io has functions >> to read and write memory like so: >> >> void Emit32(raw_ostream& Out, uint32_t V); >> uint32_t ReadLE32(const unsigned char *&Data); >> uint32_t ReadUnalignedLE32(const unsigned char *&Data); >> >> The (aligned) ReadLE32 is easily represented by the stuff in Endian.h, >> but the write to an ostream a...

This series depends on the previously posted reservation api patches. 2 of them are not yet in for-next-fences branch of git://git.linaro.org/people/sumit.semwal/linux-3.x.git The missing patches are still in my vmwgfx_wip branch at git://people.freedesktop.org/~mlankhorst/linux All ttm drivers are converted to the fence api, fence_lock is removed and rcu is used in its place. qxl is the first

fence_is_signaled callback should support being run in atomic context, but not in irq context. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- include/linux/fence.h | 23 +++++++++++++++++++---- 1 file changed, 19 insertions(+), 4 deletions(-) diff --git a/include/linux/fence.h b/include/linux/fence.h index d174585b874b..c1a4519ba2f5 100644 ---

This series applies on top of the driver-core-next branch of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git Before converting ttm to the new fence interface I had to fix some drivers to require a reservation before poking with fence_obj. After flipping the switch RCU becomes available instead, and the extra reservations can be dropped again. :-) I've done at least basic