Displaying 11 results from an estimated 11 matches for "drm_public".
Did you mean:
dll_public
2014 Jul 31
1
[libdrm PATCH 1/3] nouveau: Only export public functions.
...\
-I$(top_srcdir)/nouveau \
$(PTHREADSTUBS_CFLAGS) \
diff --git a/nouveau/bufctx.c b/nouveau/bufctx.c
index 23d6f09..fdd3164 100644
--- a/nouveau/bufctx.c
+++ b/nouveau/bufctx.c
@@ -68,7 +68,7 @@ nouveau_bufctx(struct nouveau_bufctx *bctx)
return (struct nouveau_bufctx_priv *)bctx;
}
-int
+drm_public int
nouveau_bufctx_new(struct nouveau_client *client, int bins,
struct nouveau_bufctx **pbctx)
{
@@ -88,7 +88,7 @@ nouveau_bufctx_new(struct nouveau_client *client, int bins,
return -ENOMEM;
}
-void
+drm_public void
nouveau_bufctx_del(struct nouveau_bufctx **pbctx)
{
struct nouveau...
2014 Jul 30
2
[PATCH libdrm] configure: Support symbol visibility when available
...idia.com>
>
> Checks whether or not the compiler supports the -fvisibility option. If
> so it sets the VISIBILITY_CFLAGS variable which can be added to the per
> directory AM_CFLAGS where appropriate.
>
> By default all symbols will be hidden via the VISIBILITY_CFLAGS. The
> drm_public macro can be used to mark symbols that should be exported.
hmm, maybe dumb question, I might possibly have missed some discussion
on this, but if we merged this without a heap of patches to export
libdrm and libdrm_foo syms, wouldn't everything be hidden?
Maybe we should introduce drm_public...
2014 Jul 30
3
[PATCH] libdrm: hide all private symbols
On 30/07/14 11:16, Christian K?nig wrote:
> [CCing Emil as well]
>
> Am 30.07.2014 um 11:38 schrieb Maarten Lankhorst:
>> Using -export-symbols-regex all private symbols are hidden, resulting in the
>> following changes:
>
> Wasn't "-export-symbols-regex" exactly that stuff we are trying to avoid in mesa?
>
IMHO we should try to pick up Thierry
2014 Jul 30
0
[PATCH libdrm] configure: Support symbol visibility when available
...t; Checks whether or not the compiler supports the -fvisibility option. If
>> so it sets the VISIBILITY_CFLAGS variable which can be added to the per
>> directory AM_CFLAGS where appropriate.
>>
>> By default all symbols will be hidden via the VISIBILITY_CFLAGS. The
>> drm_public macro can be used to mark symbols that should be exported.
>
> hmm, maybe dumb question, I might possibly have missed some discussion
> on this, but if we merged this without a heap of patches to export
> libdrm and libdrm_foo syms, wouldn't everything be hidden?
>
> Maybe w...
2018 Oct 04
0
[ANNOUNCE] libdrm 2.4.95
...gitlab-ci builds of libdrm
xf86drm: merge get_normal_pci_path() into get_real_pci_path()
xf86drm: rename "real_path" to "pci_path"
gitlab-ci: use templates to deduplicate the build commands
headers/README: fix/add link to drm-next
intel: add missing drm_public exports
nouveau: add missing drm_public exports
radeon: add missing drm_public exports
omap: fix symbol annotations
freedreno: add missing drm_public
Ezequiel Garcia (1):
tests/util: Add support for sun4i-drm driver
Junwei Zhang (1):
amdgpu: add error return va...
2014 Jul 30
0
[PATCH libdrm] configure: Support symbol visibility when available
...Thierry Reding <treding at nvidia.com>
Checks whether or not the compiler supports the -fvisibility option. If
so it sets the VISIBILITY_CFLAGS variable which can be added to the per
directory AM_CFLAGS where appropriate.
By default all symbols will be hidden via the VISIBILITY_CFLAGS. The
drm_public macro can be used to mark symbols that should be exported.
Signed-off-by: Thierry Reding <treding at nvidia.com>
---
Changes in v3:
- distribute libdrm.h
Makefile.am | 1 +
configure.ac | 20 ++++++++++++++++++++
libdrm.h | 34 ++++++++++++++++++++++++++++++++++
3 files changed, 55 i...
2015 Feb 24
0
[PATCH 2/2] nouveau: Do not add most bo's to the global bo list.
...o)
+{
+ if (!nvbo->head.next) {
+ struct nouveau_device_priv *nvdev = nouveau_device(nvbo->base.device);
+ pthread_mutex_lock(&nvdev->lock);
+ if (!nvbo->head.next)
+ DRMLISTADD(&nvbo->head, &nvdev->bo_list);
+ pthread_mutex_unlock(&nvdev->lock);
+ }
+}
+
drm_public int
nouveau_bo_wrap(struct nouveau_device *dev, uint32_t handle,
struct nouveau_bo **pbo)
@@ -494,13 +499,17 @@ nouveau_bo_name_get(struct nouveau_bo *bo, uint32_t *name)
struct nouveau_bo_priv *nvbo = nouveau_bo(bo);
*name = nvbo->name;
- if (!*name || *name == ~0U) {
+ if (!*name) {...
2015 May 07
0
[ANNOUNCE] libdrm 2.4.61
...nouveau: add symbols test
libkms: annotate private symbols
libkms: add symbols test
exynos: add symbols test
omap: add symbols test
tegra: add symbols test
drm: rename libdrm{,_macros}.h
drm: remove no longer needed VISIBILITY_CFLAGS
drm: remove drm_public macro
configure: request/set the compiler in C99 mode
drm: use c99 __func__ over __FUNCTION__
man: rework the Makefile.am
android: set the HAVE_VISIBILITY define
freedreno: link against CLOCK_LIB
Greg Hackmann (1):
Add missing <strings.h> includes
Jan Ves...
2015 Feb 26
4
[PATCH v2 1/4] Add atomic_inc_return to atomics.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst at ubuntu.com>
---
xf86atomic.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/xf86atomic.h b/xf86atomic.h
index 8c4b696..17fb088 100644
--- a/xf86atomic.h
+++ b/xf86atomic.h
@@ -49,6 +49,7 @@ typedef struct {
# define atomic_read(x) ((x)->atomic)
# define atomic_set(x, val) ((x)->atomic = (val))
# define atomic_inc(x)
2014 Sep 26
14
[RFC] Explicit synchronization for Nouveau
Hi guys,
I'd like to start a new thread about explicit fence synchronization. This time
with a Nouveau twist. :-)
First, let me define what I understand by implicit/explicit sync:
Implicit synchronization
* Fences are attached to buffers
* Kernel manages fences automatically based on buffer read/write access
Explicit synchronization
* Fences are passed around independently
* Kernel takes
2015 Feb 24
4
[PATCH 1/2] nouveau: make nouveau importing global buffers completely thread-safe, with tests
While I've closed off most races in a previous patch, a small race still existed
where importing then unreffing cound cause an invalid bo. Add a test for this case.
Racing sequence fixed:
- thread 1 releases bo, refcount drops to zero, blocks on acquiring nvdev->lock.
- thread 2 increases refcount to 1.
- thread 2 decreases refcount to zero, blocks on acquiring nvdev->lock.
At this