[radeon-alex:amd-staging-drm-next 324/336] htmldocs: drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:533: warning: Function parameter or member 'adev' not described in 'for_each_amdgpu_vm_pt_leaf'
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next head: bc29281af131ae8c02e05322e7fc72829ec555f0 commit: ed238ee1ef30254146a5811270d37ed1cc9826d1 [324/336] drm/amdgpu: add some VM PD/PT iterators v2 reproduce: make htmldocs All warnings (new ones prefixed by >>): include/net/mac80211.h:977: warning: Function parameter or member 'control.rts_cts_rate_idx' not described in 'ieee80211_tx_info' include/net/mac80211.h:977: warning: Function parameter or member 'control.use_rts' not described in 'ieee80211_tx_info' include/net/mac80211.h:977: warning: Function parameter or member 'control.use_cts_prot' not described in 'ieee80211_tx_info' include/net/mac80211.h:977: warning: Function parameter or member 'control.short_preamble' not described in 'ieee80211_tx_info' include/net/mac80211.h:977: warning: Function parameter or member 'control.skip_table' not described in 'ieee80211_tx_info' include/net/mac80211.h:977: warning: Function parameter or member 'control.jiffies' not described in 'ieee80211_tx_info' include/net/mac80211.h:977: warning: Function parameter or member 'control.vif' not described in 'ieee80211_tx_info' include/net/mac80211.h:977: warning: Function parameter or member 'control.hw_key' not described in 'ieee80211_tx_info' include/net/mac80211.h:977: warning: Function parameter or member 'control.flags' not described in 'ieee80211_tx_info' include/net/mac80211.h:977: warning: Function parameter or member 'control.enqueue_time' not described in 'ieee80211_tx_info' include/net/mac80211.h:977: warning: Function parameter or member 'ack' not described in 'ieee80211_tx_info' include/net/mac80211.h:977: warning: Function parameter or member 'ack.cookie' not described in 'ieee80211_tx_info' include/net/mac80211.h:977: warning: Function parameter or member 'status.rates' not described in 'ieee80211_tx_info' include/net/mac80211.h:977: warning: Function parameter or member 'status.ack_signal' not described in 'ieee80211_tx_info' include/net/mac80211.h:977: warning: Function parameter or member 'status.ampdu_ack_len' not described in 'ieee80211_tx_info' include/net/mac80211.h:977: warning: Function parameter or member 'status.ampdu_len' not described in 'ieee80211_tx_info' include/net/mac80211.h:977: warning: Function parameter or member 'status.antenna' not described in 'ieee80211_tx_info' include/net/mac80211.h:977: warning: Function parameter or member 'status.tx_time' not described in 'ieee80211_tx_info' include/net/mac80211.h:977: warning: Function parameter or member 'status.is_valid_ack_signal' not described in 'ieee80211_tx_info' include/net/mac80211.h:977: warning: Function parameter or member 'status.status_driver_data' not described in 'ieee80211_tx_info' include/net/mac80211.h:977: warning: Function parameter or member 'driver_rates' not described in 'ieee80211_tx_info' include/net/mac80211.h:977: warning: Function parameter or member 'pad' not described in 'ieee80211_tx_info' include/net/mac80211.h:977: warning: Function parameter or member 'rate_driver_data' not described in 'ieee80211_tx_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'rx_stats_avg' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'rx_stats_avg.signal' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'rx_stats_avg.chain_signal' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.filtered' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.retry_failed' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.retry_count' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.lost_packets' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.last_tdls_pkt_time' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.msdu_retries' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.msdu_failed' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.last_ack' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.last_ack_signal' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.ack_signal_filled' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.avg_ack_signal' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function
[PATCH libdrm v2 11/13] exynos: annotate public functions
while read sym; do
read f func line _ <<<$(cscope -d -L -1 $sym)
if [ ! -z "$f" ]; then
sed -i "${line}s/^/drm_public /" $f
fi
done < /tmp/a.txt
In which /tmp/a.txt contains the public symbols from
exynos-symbol-check. The idea here will be to switch the default
visibility to hidden so we don't export symbols we shouldn't.
Signed-off-by: Lucas De Marchi
---
exynos/exynos_drm.c| 30 +++---
exynos/exynos_fimg2d.c | 20 ++--
2 files changed, 25 insertions(+), 25 deletions(-)
diff --git a/exynos/exynos_drm.c b/exynos/exynos_drm.c
index e1afef65..078bf2c5 100644
--- a/exynos/exynos_drm.c
+++ b/exynos/exynos_drm.c
@@ -48,7 +48,7 @@
*
* if true, return the device object else NULL.
*/
-struct exynos_device * exynos_device_create(int fd)
+drm_public struct exynos_device * exynos_device_create(int fd)
{
struct exynos_device *dev;
@@ -69,7 +69,7 @@ struct exynos_device * exynos_device_create(int fd)
*
* @dev: exynos drm device object.
*/
-void exynos_device_destroy(struct exynos_device *dev)
+drm_public void exynos_device_destroy(struct exynos_device *dev)
{
free(dev);
}
@@ -87,8 +87,8 @@ void exynos_device_destroy(struct exynos_device *dev)
*
* if true, return a exynos buffer object else NULL.
*/
-struct exynos_bo * exynos_bo_create(struct exynos_device *dev,
- size_t size, uint32_t flags)
+drm_public struct exynos_bo * exynos_bo_create(struct exynos_device *dev,
+ size_t size, uint32_t flags)
{
struct exynos_bo *bo;
struct drm_exynos_gem_create req = {
@@ -141,8 +141,8 @@ fail:
*
* if true, return 0 else negative.
*/
-int exynos_bo_get_info(struct exynos_device *dev, uint32_t handle,
- size_t *size, uint32_t *flags)
+drm_public int exynos_bo_get_info(struct exynos_device *dev, uint32_t handle,
+ size_t *size, uint32_t *flags)
{
int ret;
struct drm_exynos_gem_info req = {
@@ -167,7 +167,7 @@ int exynos_bo_get_info(struct exynos_device *dev, uint32_t
handle,
*
* @bo: a exynos buffer object to be destroyed.
*/
-void exynos_bo_destroy(struct exynos_bo *bo)
+drm_public void exynos_bo_destroy(struct exynos_bo *bo)
{
if (!bo)
return;
@@ -199,7 +199,7 @@ void exynos_bo_destroy(struct exynos_bo *bo)
* if true, return a exynos buffer object else NULL.
*
*/
-struct exynos_bo *
+drm_public struct exynos_bo *
exynos_bo_from_name(struct exynos_device *dev, uint32_t name)
{
struct exynos_bo *bo;
@@ -242,7 +242,7 @@ err_free_bo:
*
* if true, return 0 else negative.
*/
-int exynos_bo_get_name(struct exynos_bo *bo, uint32_t *name)
+drm_public int exynos_bo_get_name(struct exynos_bo *bo, uint32_t *name)
{
if (!bo->name) {
struct drm_gem_flink req = {
@@ -265,7 +265,7 @@ int exynos_bo_get_name(struct exynos_bo *bo, uint32_t *name)
return 0;
}
-uint32_t exynos_bo_handle(struct exynos_bo *bo)
+drm_public uint32_t exynos_bo_handle(struct exynos_bo *bo)
{
return bo->handle;
}
@@ -278,7 +278,7 @@ uint32_t exynos_bo_handle(struct exynos_bo *bo)
*
* if true, user pointer mmaped else NULL.
*/
-void *exynos_bo_map(struct exynos_bo *bo)
+drm_public void *exynos_bo_map(struct exynos_bo *bo)
{
if (!bo->vaddr) {
struct exynos_device *dev = bo->dev;
@@ -315,7 +315,7 @@ void *exynos_bo_map(struct exynos_bo *bo)
*
* @return: 0 on success, -1 on error, and errno will be set
*/
-int
+drm_public int
exynos_prime_handle_to_fd(struct exynos_device *dev, uint32_t handle, int *fd)
{
return drmPrimeHandleToFD(dev->fd, handle, 0, fd);
@@ -330,7 +330,7 @@ exynos_prime_handle_to_fd(struct exynos_device *dev,
uint32_t handle, int *fd)
*
* @return: 0 on success, -1 on error, and errno will be set
*/
-int
+drm_public int
exynos_prime_fd_to_handle(struct exynos_device *dev, int fd, uint32_t *handle)
{
return drmPrimeFDToHandle(dev->fd, fd, handle);
@@ -353,7 +353,7 @@ exynos_prime_fd_to_handle(struct exynos_device *dev, int
fd, uint32_t *handle)
*
* if true, return 0 else negative.
*/
-int
+drm_public int
exynos_vidi_connection(struct exynos_device *dev, uint32_t connect,
uint32_t ext, void *edid)
{
@@ -394,7 +394,7 @@ exynos_handle_vendor(int fd, struct drm_event *e, void *ctx)
}
}
-int
+drm_public int
exynos_handle_event(struct exynos_device *dev, struct exynos_event_context
*ctx)
{
char buffer[1024];
diff --git a/exynos/exynos_fimg2d.c b/exynos/exynos_fimg2d.c
index bca884b9..ac6fa687 100644
--- a/exynos/exynos_fimg2d.c
+++ b/exynos/exynos_fimg2d.c
@@ -356,7 +356,7 @@ static int g2d_flush(struct g2d_context *ctx)
*
* fd: a file descriptor to an opened drm device.
*/
-struct g2d_context *g2d_init(int fd)
+drm_public struct
[PATCH libdrm v2 12/13] meson: make symbols hidden by default
Now that symbols that should be exported are annotated accordingly, make
all the rest hidden by default.
Signed-off-by: Lucas De Marchi
---
amdgpu/meson.build | 2 +-
etnaviv/meson.build | 2 +-
exynos/meson.build | 2 +-
freedreno/meson.build | 2 +-
intel/meson.build | 4 ++--
libkms/meson.build | 2 +-
meson.build | 5 -
nouveau/meson.build | 2 +-
omap/meson.build| 2 +-
radeon/meson.build | 2 +-
tegra/meson.build | 2 +-
tests/exynos/meson.build| 6 +++---
tests/kms/meson.build | 2 +-
tests/kmstest/meson.build | 2 +-
tests/meson.build | 8
tests/modeprint/meson.build | 2 +-
tests/modetest/meson.build | 2 +-
tests/nouveau/meson.build | 2 +-
tests/proptest/meson.build | 2 +-
tests/radeon/meson.build| 2 +-
tests/tegra/meson.build | 2 +-
tests/vbltest/meson.build | 2 +-
22 files changed, 31 insertions(+), 28 deletions(-)
diff --git a/amdgpu/meson.build b/amdgpu/meson.build
index d9d7de2d..7c8ccc7e 100644
--- a/amdgpu/meson.build
+++ b/amdgpu/meson.build
@@ -31,7 +31,7 @@ libdrm_amdgpu = shared_library(
config_file,
],
c_args : [
-warn_c_args,
+libdrm_c_args,
'-DAMDGPU_ASIC_ID_TABLE="@0@"'.format(join_paths(datadir_amdgpu,
'amdgpu.ids')),
],
include_directories : [inc_root, inc_drm],
diff --git a/etnaviv/meson.build b/etnaviv/meson.build
index ca2aa544..515a4ed0 100644
--- a/etnaviv/meson.build
+++ b/etnaviv/meson.build
@@ -30,7 +30,7 @@ libdrm_etnaviv = shared_library(
],
include_directories : [inc_root, inc_drm],
link_with : libdrm,
- c_args : warn_c_args,
+ c_args : libdrm_c_args,
dependencies : [dep_pthread_stubs, dep_rt, dep_atomic_ops],
version : '1.0.0',
install : true,
diff --git a/exynos/meson.build b/exynos/meson.build
index 30d36405..bdfc3fc6 100644
--- a/exynos/meson.build
+++ b/exynos/meson.build
@@ -21,7 +21,7 @@
libdrm_exynos = shared_library(
'drm_exynos',
[files('exynos_drm.c', 'exynos_fimg2d.c'), config_file],
- c_args : warn_c_args,
+ c_args : libdrm_c_args,
include_directories : [inc_root, inc_drm],
link_with : libdrm,
dependencies : [dep_pthread_stubs],
diff --git a/freedreno/meson.build b/freedreno/meson.build
index 015b7fb1..c9aba060 100644
--- a/freedreno/meson.build
+++ b/freedreno/meson.build
@@ -42,7 +42,7 @@ endif
libdrm_freedreno = shared_library(
'drm_freedreno',
[files_freedreno, config_file],
- c_args : warn_c_args,
+ c_args : libdrm_c_args,
include_directories : [inc_root, inc_drm],
dependencies : [dep_valgrind, dep_pthread_stubs, dep_rt, dep_atomic_ops],
link_with : libdrm,
diff --git a/intel/meson.build b/intel/meson.build
index ff40ab91..3d6bbac6 100644
--- a/intel/meson.build
+++ b/intel/meson.build
@@ -30,7 +30,7 @@ libdrm_intel = shared_library(
include_directories : [inc_root, inc_drm],
link_with : libdrm,
dependencies : [dep_pciaccess, dep_pthread_stubs, dep_rt, dep_valgrind,
dep_atomic_ops],
- c_args : warn_c_args,
+ c_args : libdrm_c_args,
version : '1.0.0',
install : true,
)
@@ -59,7 +59,7 @@ test_decode = executable(
files('test_decode.c'),
include_directories : [inc_root, inc_drm],
link_with : [libdrm, libdrm_intel],
- c_args : warn_c_args,
+ c_args : libdrm_c_args,
)
test(
diff --git a/libkms/meson.build b/libkms/meson.build
index 86d1a4ee..dc931608 100644
--- a/libkms/meson.build
+++ b/libkms/meson.build
@@ -44,7 +44,7 @@ endif
libkms = shared_library(
'kms',
[files_libkms, config_file],
- c_args : warn_c_args,
+ c_args : libdrm_c_args,
include_directories : libkms_include,
link_with : libdrm,
version : '1.0.0',
diff --git a/meson.build b/meson.build
index 75c7bdff..80d50188 100644
--- a/meson.build
+++ b/meson.build
@@ -211,6 +211,9 @@ foreach a : ['unused-parameter', 'attributes', 'long-long',
endif
endforeach
+# all c args:
+libdrm_c_args = warn_c_args + ['-fvisibility=hidden']
+
dep_pciaccess = dependency('pciaccess', version : '>= 0.10', required :
with_intel)
dep_cunit = dependency('cunit', version : '>= 2.1', required : false)
@@ -286,7 +289,7 @@ libdrm = shared_library(
),
config_file,
],
- c_args : warn_c_args,
+ c_args : libdrm_c_args,
dependencies : [dep_valgrind, dep_rt, dep_m],
include_directories : inc_drm,
version : '2.4.0',
diff --git a/nouveau/meson.build b/nouveau/meson.build
index 51c9a712..0c1498d7 100644
--- a/nouveau/meson.build
+++ b/nouveau/meson.build
@@ -22,7 +22,7 @@
libdrm_nouveau = shared_library(
'drm_nouveau',
[files( 'nouveau.c', 'pushbuf.c', 'bufctx.c', 'abi16.c'), config_file],
- c_args : warn_c_args,
+ c_args : libdrm_c_args,
include_directories : [inc_root, inc_drm],
link_with : libdrm,
dependencies : [dep_threads, dep_atomic_ops],
diff --git a/omap/meson.build b/omap/meson.build
index e57b8f5d..54698c6a 100644
--- a/omap/meson.build
+++ b/omap/meson.build
@@ -22,7 +22,7
[PATCH libdrm v2 08/13] omap: annotate public functions
while read sym; do
read f func line _ <<<$(cscope -d -L -1 $sym)
if [ ! -z "$f" ]; then
sed -i "${line}s/^/drm_public /" $f
fi
done < /tmp/a.txt
In which /tmp/a.txt contains the public symbols from
omap-symbol-check. The idea here will be to switch the default
visibility to hidden so we don't export symbols we shouldn't.
Signed-off-by: Lucas De Marchi
---
omap/omap_drm.c | 36 ++--
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/omap/omap_drm.c b/omap/omap_drm.c
index 417d522c..3136e04e 100644
--- a/omap/omap_drm.c
+++ b/omap/omap_drm.c
@@ -88,7 +88,7 @@ static struct omap_device * omap_device_new_impl(int fd)
return dev;
}
-struct omap_device * omap_device_new(int fd)
+drm_public struct omap_device * omap_device_new(int fd)
{
struct omap_device *dev = NULL;
@@ -111,13 +111,13 @@ struct omap_device * omap_device_new(int fd)
return dev;
}
-struct omap_device * omap_device_ref(struct omap_device *dev)
+drm_public struct omap_device * omap_device_ref(struct omap_device *dev)
{
atomic_inc(>refcnt);
return dev;
}
-void omap_device_del(struct omap_device *dev)
+drm_public void omap_device_del(struct omap_device *dev)
{
if (!atomic_dec_and_test(>refcnt))
return;
@@ -129,7 +129,7 @@ void omap_device_del(struct omap_device *dev)
}
int
-omap_get_param(struct omap_device *dev, uint64_t param, uint64_t *value)
+drm_public omap_get_param(struct omap_device *dev, uint64_t param, uint64_t
*value)
{
struct drm_omap_param req = {
.param = param,
@@ -147,7 +147,7 @@ omap_get_param(struct omap_device *dev, uint64_t param,
uint64_t *value)
}
int
-omap_set_param(struct omap_device *dev, uint64_t param, uint64_t value)
+drm_public omap_set_param(struct omap_device *dev, uint64_t param, uint64_t
value)
{
struct drm_omap_param req = {
.param = param,
@@ -227,7 +227,7 @@ fail:
/* allocate a new (un-tiled) buffer object */
struct omap_bo *
-omap_bo_new(struct omap_device *dev, uint32_t size, uint32_t flags)
+drm_public omap_bo_new(struct omap_device *dev, uint32_t size, uint32_t flags)
{
union omap_gem_size gsize = {
.bytes = size,
@@ -240,7 +240,7 @@ omap_bo_new(struct omap_device *dev, uint32_t size,
uint32_t flags)
/* allocate a new buffer object */
struct omap_bo *
-omap_bo_new_tiled(struct omap_device *dev, uint32_t width,
+drm_public omap_bo_new_tiled(struct omap_device *dev, uint32_t width,
uint32_t height, uint32_t flags)
{
union omap_gem_size gsize = {
@@ -255,7 +255,7 @@ omap_bo_new_tiled(struct omap_device *dev, uint32_t width,
return omap_bo_new_impl(dev, gsize, flags);
}
-struct omap_bo *omap_bo_ref(struct omap_bo *bo)
+drm_public struct omap_bo *omap_bo_ref(struct omap_bo *bo)
{
atomic_inc(>refcnt);
return bo;
@@ -282,7 +282,7 @@ static int get_buffer_info(struct omap_bo *bo)
/* import a buffer object from DRI2 name */
struct omap_bo *
-omap_bo_from_name(struct omap_device *dev, uint32_t name)
+drm_public omap_bo_from_name(struct omap_device *dev, uint32_t name)
{
struct omap_bo *bo = NULL;
struct drm_gem_open req = {
@@ -316,7 +316,7 @@ fail:
* with it (even if it is still using the 'struct omap_bo *')
*/
struct omap_bo *
-omap_bo_from_dmabuf(struct omap_device *dev, int fd)
+drm_public omap_bo_from_dmabuf(struct omap_device *dev, int fd)
{
struct omap_bo *bo = NULL;
struct drm_prime_handle req = {
@@ -347,7 +347,7 @@ fail:
}
/* destroy a buffer object */
-void omap_bo_del(struct omap_bo *bo)
+drm_public void omap_bo_del(struct omap_bo *bo)
{
if (!bo) {
return;
@@ -380,7 +380,7 @@ void omap_bo_del(struct omap_bo *bo)
}
/* get the global flink/DRI2 buffer name */
-int omap_bo_get_name(struct omap_bo *bo, uint32_t *name)
+drm_public int omap_bo_get_name(struct omap_bo *bo, uint32_t *name)
{
if (!bo->name) {
struct drm_gem_flink req = {
@@ -401,7 +401,7 @@ int omap_bo_get_name(struct omap_bo *bo, uint32_t *name)
return 0;
}
-uint32_t omap_bo_handle(struct omap_bo *bo)
+drm_public uint32_t omap_bo_handle(struct omap_bo *bo)
{
return bo->handle;
}
@@ -409,7 +409,7 @@ uint32_t omap_bo_handle(struct omap_bo *bo)
/* caller owns the dmabuf fd that is returned and is responsible
* to close() it when done
*/
-int omap_bo_dmabuf(struct omap_bo *bo)
+drm_public int omap_bo_dmabuf(struct omap_bo *bo)
{
if (bo->fd < 0) {
struct drm_prime_handle req = {
@@ -428,7 +428,7 @@ int omap_bo_dmabuf(struct omap_bo *bo)
return dup(bo->fd);
}
-uint32_t omap_bo_size(struct omap_bo *bo)
+drm_public uint32_t omap_bo_size(struct omap_bo *bo)
{
if (!bo->size) {
get_buffer_info(bo);
@@ -436,7 +436,7 @@ uint32_t
[PATCH libdrm v2 04/13] libkms: annotate public functions
This was done with:
nm --dynamic --defined-only build/amdgpu/libdrm_amdgpu.so | \
grep amdgpu_ | \
cut -d' ' -f3 > /tmp/a.txt
while read sym; do
read f func line _ <<<$(cscope -d -L -1 $sym)
if [ ! -z "$f" ]; then
line=$((line-1))
sed -i "${line}s/^/drm_public /" $f
fi
done < /tmp/a.txt
Then the alignment of function arguments were manually fixed all over.
The idea here will be to switch the default visibility to hidden so we
don't export symbols we shouldn't.
Signed-off-by: Lucas De Marchi
---
amdgpu/amdgpu_bo.c | 104 ++---
amdgpu/amdgpu_cs.c | 137 ---
amdgpu/amdgpu_device.c | 19 +++---
amdgpu/amdgpu_gpu_info.c | 51 ---
amdgpu/amdgpu_vamgr.c| 24 +++
amdgpu/amdgpu_vm.c | 5 +-
6 files changed, 173 insertions(+), 167 deletions(-)
diff --git a/amdgpu/amdgpu_bo.c b/amdgpu/amdgpu_bo.c
index 6a95929c..cd29c014 100644
--- a/amdgpu/amdgpu_bo.c
+++ b/amdgpu/amdgpu_bo.c
@@ -69,9 +69,9 @@ static int amdgpu_bo_create(amdgpu_device_handle dev,
return 0;
}
-int amdgpu_bo_alloc(amdgpu_device_handle dev,
- struct amdgpu_bo_alloc_request *alloc_buffer,
- amdgpu_bo_handle *buf_handle)
+drm_public int amdgpu_bo_alloc(amdgpu_device_handle dev,
+ struct amdgpu_bo_alloc_request *alloc_buffer,
+ amdgpu_bo_handle *buf_handle)
{
union drm_amdgpu_gem_create args;
unsigned heap = alloc_buffer->preferred_heap;
@@ -112,8 +112,8 @@ out:
return r;
}
-int amdgpu_bo_set_metadata(amdgpu_bo_handle bo,
- struct amdgpu_bo_metadata *info)
+drm_public int amdgpu_bo_set_metadata(amdgpu_bo_handle bo,
+ struct amdgpu_bo_metadata *info)
{
struct drm_amdgpu_gem_metadata args = {};
@@ -135,8 +135,8 @@ int amdgpu_bo_set_metadata(amdgpu_bo_handle bo,
, sizeof(args));
}
-int amdgpu_bo_query_info(amdgpu_bo_handle bo,
-struct amdgpu_bo_info *info)
+drm_public int amdgpu_bo_query_info(amdgpu_bo_handle bo,
+ struct amdgpu_bo_info *info)
{
struct drm_amdgpu_gem_metadata metadata = {};
struct drm_amdgpu_gem_create_in bo_info = {};
@@ -232,9 +232,9 @@ static int amdgpu_bo_export_flink(amdgpu_bo_handle bo)
return r;
}
-int amdgpu_bo_export(amdgpu_bo_handle bo,
-enum amdgpu_bo_handle_type type,
-uint32_t *shared_handle)
+drm_public int amdgpu_bo_export(amdgpu_bo_handle bo,
+ enum amdgpu_bo_handle_type type,
+ uint32_t *shared_handle)
{
int r;
@@ -260,9 +260,9 @@ int amdgpu_bo_export(amdgpu_bo_handle bo,
return -EINVAL;
}
-int amdgpu_bo_import(amdgpu_device_handle dev,
-enum amdgpu_bo_handle_type type,
-uint32_t shared_handle,
+drm_public int amdgpu_bo_import(amdgpu_device_handle dev,
+ enum amdgpu_bo_handle_type type,
+ uint32_t shared_handle,
struct amdgpu_bo_import_result *output)
{
struct drm_gem_open open_arg = {};
@@ -406,7 +406,7 @@ unlock:
return r;
}
-int amdgpu_bo_free(amdgpu_bo_handle buf_handle)
+drm_public int amdgpu_bo_free(amdgpu_bo_handle buf_handle)
{
struct amdgpu_device *dev;
struct amdgpu_bo *bo = buf_handle;
@@ -438,12 +438,12 @@ int amdgpu_bo_free(amdgpu_bo_handle buf_handle)
return 0;
}
-void amdgpu_bo_inc_ref(amdgpu_bo_handle bo)
+drm_public void amdgpu_bo_inc_ref(amdgpu_bo_handle bo)
{
atomic_inc(>refcount);
}
-int amdgpu_bo_cpu_map(amdgpu_bo_handle bo, void **cpu)
+drm_public int amdgpu_bo_cpu_map(amdgpu_bo_handle bo, void **cpu)
{
union drm_amdgpu_gem_mmap args;
void *ptr;
@@ -491,7 +491,7 @@ int amdgpu_bo_cpu_map(amdgpu_bo_handle bo, void **cpu)
return 0;
}
-int amdgpu_bo_cpu_unmap(amdgpu_bo_handle bo)
+drm_public int amdgpu_bo_cpu_unmap(amdgpu_bo_handle bo)
{
int r;
@@ -517,7 +517,7 @@ int amdgpu_bo_cpu_unmap(amdgpu_bo_handle bo)
return r;
}
-int amdgpu_query_buffer_size_alignment(amdgpu_device_handle dev,
+drm_public int amdgpu_query_buffer_size_alignment(amdgpu_device_handle dev,
struct amdgpu_buffer_size_alignments *info)
{
info->size_local = dev->dev_info.pte_fragment_size;
@@ -525,8 +525,8 @@ int amdgpu_query_buffer_size_alignment(amdgpu_device_handle
dev,
return 0;
}
-int amdgpu_bo_wait_for_idle(amdgpu_bo_handle bo,
- uint64_t timeout_ns,
+drm_public int amdgpu_bo_wait_for_idle(amdgpu_bo_handle bo,
+ uint64_t timeout_ns,
bool *busy)
[PATCH libdrm v2 13/13] autotools: make symbols hidden by default
Now that symbols that should be exported are annotated accordingly, make all the rest hidden by default. Signed-off-by: Lucas De Marchi --- Makefile.am | 1 + amdgpu/Makefile.am | 1 + etnaviv/Makefile.am | 1 + exynos/Makefile.am | 1 + freedreno/Makefile.am | 1 + intel/Makefile.am | 1 + libkms/Makefile.am | 1 + nouveau/Makefile.am | 1 + omap/Makefile.am| 1 + radeon/Makefile.am | 1 + tegra/Makefile.am | 3 ++- tests/Makefile.am | 1 + tests/amdgpu/Makefile.am| 1 + tests/etnaviv/Makefile.am | 1 + tests/exynos/Makefile.am| 1 + tests/kms/Makefile.am | 3 ++- tests/kmstest/Makefile.am | 1 + tests/modeprint/Makefile.am | 1 + tests/modetest/Makefile.am | 1 + tests/nouveau/Makefile.am | 1 + tests/proptest/Makefile.am | 1 + tests/radeon/Makefile.am| 1 + tests/tegra/Makefile.am | 4 +++- tests/vbltest/Makefile.am | 1 + vc4/Makefile.am | 1 + 25 files changed, 29 insertions(+), 3 deletions(-) diff --git a/Makefile.am b/Makefile.am index faf0f750..730de1f2 100644 --- a/Makefile.am +++ b/Makefile.am @@ -121,6 +121,7 @@ libdrm_la_LIBADD = @CLOCK_LIB@ -lm libdrm_la_CPPFLAGS = -I$(top_srcdir)/include/drm AM_CFLAGS = \ $(WARN_CFLAGS) \ + -fvisibility=hidden \ $(VALGRIND_CFLAGS) libdrm_la_SOURCES = $(LIBDRM_FILES) diff --git a/amdgpu/Makefile.am b/amdgpu/Makefile.am index a1b0d05c..707082f0 100644 --- a/amdgpu/Makefile.am +++ b/amdgpu/Makefile.am @@ -26,6 +26,7 @@ include Makefile.sources AM_CFLAGS = \ $(WARN_CFLAGS) \ + -fvisibility=hidden \ -I$(top_srcdir) \ $(PTHREADSTUBS_CFLAGS) \ -I$(top_srcdir)/include/drm diff --git a/etnaviv/Makefile.am b/etnaviv/Makefile.am index be96ba86..9c2a3d7d 100644 --- a/etnaviv/Makefile.am +++ b/etnaviv/Makefile.am @@ -2,6 +2,7 @@ include Makefile.sources AM_CFLAGS = \ $(WARN_CFLAGS) \ + -fvisibility=hidden \ -I$(top_srcdir) \ $(PTHREADSTUBS_CFLAGS) \ -I$(top_srcdir)/include/drm diff --git a/exynos/Makefile.am b/exynos/Makefile.am index f99f8981..918b8d82 100644 --- a/exynos/Makefile.am +++ b/exynos/Makefile.am @@ -1,5 +1,6 @@ AM_CFLAGS = \ $(WARN_CFLAGS) \ + -fvisibility=hidden \ -I$(top_srcdir) \ $(PTHREADSTUBS_CFLAGS) \ -I$(top_srcdir)/include/drm diff --git a/freedreno/Makefile.am b/freedreno/Makefile.am index cbb0d031..4cb542d3 100644 --- a/freedreno/Makefile.am +++ b/freedreno/Makefile.am @@ -3,6 +3,7 @@ include Makefile.sources AM_CFLAGS = \ $(WARN_CFLAGS) \ + -fvisibility=hidden \ -I$(top_srcdir) \ $(PTHREADSTUBS_CFLAGS) \ $(VALGRIND_CFLAGS) \ diff --git a/intel/Makefile.am b/intel/Makefile.am index c52e8c08..5b1f2f56 100644 --- a/intel/Makefile.am +++ b/intel/Makefile.am @@ -26,6 +26,7 @@ include Makefile.sources AM_CFLAGS = \ $(WARN_CFLAGS) \ + -fvisibility=hidden \ -I$(top_srcdir) \ $(PTHREADSTUBS_CFLAGS) \ $(PCIACCESS_CFLAGS) \ diff --git a/libkms/Makefile.am b/libkms/Makefile.am index 461fc35b..5e08a380 100644 --- a/libkms/Makefile.am +++ b/libkms/Makefile.am @@ -2,6 +2,7 @@ include Makefile.sources AM_CFLAGS = \ $(WARN_CFLAGS) \ + -fvisibility=hidden \ -I$(top_srcdir)/include/drm \ -I$(top_srcdir) diff --git a/nouveau/Makefile.am b/nouveau/Makefile.am index 344a8445..3c4d043b 100644 --- a/nouveau/Makefile.am +++ b/nouveau/Makefile.am @@ -2,6 +2,7 @@ include Makefile.sources AM_CFLAGS = \ $(WARN_CFLAGS) \ + -fvisibility=hidden \ -I$(top_srcdir) \ $(PTHREADSTUBS_CFLAGS) \ -I$(top_srcdir)/include/drm \ diff --git a/omap/Makefile.am b/omap/Makefile.am index 599bb9de..26978ae7 100644 --- a/omap/Makefile.am +++ b/omap/Makefile.am @@ -1,5 +1,6 @@ AM_CFLAGS = \ $(WARN_CFLAGS) \ + -fvisibility=hidden \ -I$(top_srcdir) \ $(PTHREADSTUBS_CFLAGS) \ -I$(top_srcdir)/include/drm diff --git a/radeon/Makefile.am b/radeon/Makefile.am index e2415314..c07b4922 100644 --- a/radeon/Makefile.am +++ b/radeon/Makefile.am @@ -26,6 +26,7 @@ include Makefile.sources AM_CFLAGS = \ $(WARN_CFLAGS) \ + -fvisibility=hidden \ -I$(top_srcdir) \ $(PTHREADSTUBS_CFLAGS) \ -I$(top_srcdir)/include/drm diff --git a/tegra/Makefile.am b/tegra/Makefile.am index fb40be55..08b5e7c4 100644 --- a/tegra/Makefile.am +++ b/tegra/Makefile.am @@ -4,7 +4,8 @@ AM_CPPFLAGS = \ AM_CFLAGS = \ @PTHREADSTUBS_CFLAGS@ \ - $(WARN_CFLAGS) + $(WARN_CFLAGS) \ + -fvisibility=hidden libdrm_tegra_ladir = $(libdir) libdrm_tegra_la_LTLIBRARIES = libdrm_tegra.la diff --git a/tests/Makefile.am b/tests/Makefile.am index b72c24f9..d274a3e9 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -32,6 +32,7 @@ endif AM_CFLAGS = \ $(WARN_CFLAGS)\ +
[PATCH libdrm v2 07/13] freedreno: annotate public functions
while read sym; do
read f func line _ <<<$(cscope -d -L -1 $sym)
if [ ! -z "$f" ]; then
sed -i "${line}s/^/drm_public /" $f
fi
done < /tmp/a.txt
In which /tmp/a.txt contains the public symbols from
freedreno-symbol-check. The idea here will be to switch the default
visibility to hidden so we don't export symbols we shouldn't.
Signed-off-by: Lucas De Marchi
---
freedreno/freedreno_bo.c | 32 -
freedreno/freedreno_device.c | 12 +-
freedreno/freedreno_pipe.c | 14 +--
freedreno/freedreno_ringbuffer.c | 40
4 files changed, 49 insertions(+), 49 deletions(-)
diff --git a/freedreno/freedreno_bo.c b/freedreno/freedreno_bo.c
index 34c285fb..dbb87a5b 100644
--- a/freedreno/freedreno_bo.c
+++ b/freedreno/freedreno_bo.c
@@ -79,7 +79,7 @@ static struct fd_bo * bo_from_handle(struct fd_device *dev,
}
struct fd_bo *
-fd_bo_new(struct fd_device *dev, uint32_t size, uint32_t flags)
+drm_public fd_bo_new(struct fd_device *dev, uint32_t size, uint32_t flags)
{
struct fd_bo *bo = NULL;
uint32_t handle;
@@ -104,7 +104,7 @@ fd_bo_new(struct fd_device *dev, uint32_t size, uint32_t
flags)
}
struct fd_bo *
-fd_bo_from_handle(struct fd_device *dev, uint32_t handle, uint32_t size)
+drm_public fd_bo_from_handle(struct fd_device *dev, uint32_t handle, uint32_t
size)
{
struct fd_bo *bo = NULL;
@@ -125,7 +125,7 @@ out_unlock:
}
struct fd_bo *
-fd_bo_from_dmabuf(struct fd_device *dev, int fd)
+drm_public fd_bo_from_dmabuf(struct fd_device *dev, int fd)
{
int ret, size;
uint32_t handle;
@@ -156,7 +156,7 @@ out_unlock:
return bo;
}
-struct fd_bo * fd_bo_from_name(struct fd_device *dev, uint32_t name)
+drm_public struct fd_bo * fd_bo_from_name(struct fd_device *dev, uint32_t name)
{
struct drm_gem_open req = {
.name = name,
@@ -191,23 +191,23 @@ out_unlock:
return bo;
}
-uint64_t fd_bo_get_iova(struct fd_bo *bo)
+drm_public uint64_t fd_bo_get_iova(struct fd_bo *bo)
{
return bo->funcs->iova(bo);
}
-void fd_bo_put_iova(struct fd_bo *bo)
+drm_public void fd_bo_put_iova(struct fd_bo *bo)
{
/* currently a no-op */
}
-struct fd_bo * fd_bo_ref(struct fd_bo *bo)
+drm_public struct fd_bo * fd_bo_ref(struct fd_bo *bo)
{
atomic_inc(>refcnt);
return bo;
}
-void fd_bo_del(struct fd_bo *bo)
+drm_public void fd_bo_del(struct fd_bo *bo)
{
struct fd_device *dev = bo->dev;
@@ -250,7 +250,7 @@ drm_private void bo_del(struct fd_bo *bo)
bo->funcs->destroy(bo);
}
-int fd_bo_get_name(struct fd_bo *bo, uint32_t *name)
+drm_public int fd_bo_get_name(struct fd_bo *bo, uint32_t *name)
{
if (!bo->name) {
struct drm_gem_flink req = {
@@ -274,12 +274,12 @@ int fd_bo_get_name(struct fd_bo *bo, uint32_t *name)
return 0;
}
-uint32_t fd_bo_handle(struct fd_bo *bo)
+drm_public uint32_t fd_bo_handle(struct fd_bo *bo)
{
return bo->handle;
}
-int fd_bo_dmabuf(struct fd_bo *bo)
+drm_public int fd_bo_dmabuf(struct fd_bo *bo)
{
int ret, prime_fd;
@@ -295,12 +295,12 @@ int fd_bo_dmabuf(struct fd_bo *bo)
return prime_fd;
}
-uint32_t fd_bo_size(struct fd_bo *bo)
+drm_public uint32_t fd_bo_size(struct fd_bo *bo)
{
return bo->size;
}
-void * fd_bo_map(struct fd_bo *bo)
+drm_public void * fd_bo_map(struct fd_bo *bo)
{
if (!bo->map) {
uint64_t offset;
@@ -322,18 +322,18 @@ void * fd_bo_map(struct fd_bo *bo)
}
/* a bit odd to take the pipe as an arg, but it's a, umm, quirk of kgsl.. */
-int fd_bo_cpu_prep(struct fd_bo *bo, struct fd_pipe *pipe, uint32_t op)
+drm_public int fd_bo_cpu_prep(struct fd_bo *bo, struct fd_pipe *pipe, uint32_t
op)
{
return bo->funcs->cpu_prep(bo, pipe, op);
}
-void fd_bo_cpu_fini(struct fd_bo *bo)
+drm_public void fd_bo_cpu_fini(struct fd_bo *bo)
{
bo->funcs->cpu_fini(bo);
}
#if !HAVE_FREEDRENO_KGSL
-struct fd_bo * fd_bo_from_fbdev(struct fd_pipe *pipe, int fbfd, uint32_t size)
+drm_public struct fd_bo * fd_bo_from_fbdev(struct fd_pipe *pipe, int fbfd,
uint32_t size)
{
return NULL;
}
diff --git a/freedreno/freedreno_device.c b/freedreno/freedreno_device.c
index 0b42561a..c5b8da96 100644
--- a/freedreno/freedreno_device.c
+++ b/freedreno/freedreno_device.c
@@ -38,7 +38,7 @@ static pthread_mutex_t table_lock = PTHREAD_MUTEX_INITIALIZER;
struct fd_device * kgsl_device_new(int fd);
struct fd_device * msm_device_new(int fd);
-struct fd_device * fd_device_new(int fd)
+drm_public struct fd_device * fd_device_new(int fd)
{
struct fd_device *dev;
drmVersionPtr version;
@@ -89,7 +89,7 @@ out:
/* like fd_device_new() but creates it's own private dup() of the fd
* which is close()d when the device is finalized.
*/
-struct fd_device * fd_device_new_dup(int fd)
+drm_public struct fd_device *
[PATCH libdrm v2 06/13] etnaviv: annotate public functions
while read sym; do
read f func line _ <<<$(cscope -d -L -1 $sym)
if [ ! -z "$f" ]; then
sed -i "${line}s/^/drm_public /" $f
fi
done < /tmp/a.txt
In which /tmp/a.txt contains the public symbols from
etnaviv-symbol-check. The idea here will be to switch the default
visibility to hidden so we don't export symbols we shouldn't.
Signed-off-by: Lucas De Marchi
---
etnaviv/etnaviv_bo.c | 25 +
etnaviv/etnaviv_cmd_stream.c | 21 -
etnaviv/etnaviv_device.c | 10 +-
etnaviv/etnaviv_gpu.c| 6 +++---
etnaviv/etnaviv_perfmon.c| 8
etnaviv/etnaviv_pipe.c | 8
6 files changed, 41 insertions(+), 37 deletions(-)
diff --git a/etnaviv/etnaviv_bo.c b/etnaviv/etnaviv_bo.c
index 32f7b348..43ce6b4e 100644
--- a/etnaviv/etnaviv_bo.c
+++ b/etnaviv/etnaviv_bo.c
@@ -104,7 +104,7 @@ static struct etna_bo *bo_from_handle(struct etna_device
*dev,
}
/* allocate a new (un-tiled) buffer object */
-struct etna_bo *etna_bo_new(struct etna_device *dev, uint32_t size,
+drm_public struct etna_bo *etna_bo_new(struct etna_device *dev, uint32_t size,
uint32_t flags)
{
struct etna_bo *bo;
@@ -131,7 +131,7 @@ struct etna_bo *etna_bo_new(struct etna_device *dev,
uint32_t size,
return bo;
}
-struct etna_bo *etna_bo_ref(struct etna_bo *bo)
+drm_public struct etna_bo *etna_bo_ref(struct etna_bo *bo)
{
atomic_inc(>refcnt);
@@ -159,7 +159,8 @@ static int get_buffer_info(struct etna_bo *bo)
}
/* import a buffer object from DRI2 name */
-struct etna_bo *etna_bo_from_name(struct etna_device *dev, uint32_t name)
+drm_public struct etna_bo *etna_bo_from_name(struct etna_device *dev,
+ uint32_t name)
{
struct etna_bo *bo;
struct drm_gem_open req = {
@@ -196,7 +197,7 @@ out_unlock:
* fd so caller should close() the fd when it is otherwise done
* with it (even if it is still using the 'struct etna_bo *')
*/
-struct etna_bo *etna_bo_from_dmabuf(struct etna_device *dev, int fd)
+drm_public struct etna_bo *etna_bo_from_dmabuf(struct etna_device *dev, int fd)
{
struct etna_bo *bo;
int ret, size;
@@ -231,7 +232,7 @@ out_unlock:
}
/* destroy a buffer object */
-void etna_bo_del(struct etna_bo *bo)
+drm_public void etna_bo_del(struct etna_bo *bo)
{
struct etna_device *dev = bo->dev;
@@ -253,7 +254,7 @@ out:
}
/* get the global flink/DRI2 buffer name */
-int etna_bo_get_name(struct etna_bo *bo, uint32_t *name)
+drm_public int etna_bo_get_name(struct etna_bo *bo, uint32_t *name)
{
if (!bo->name) {
struct drm_gem_flink req = {
@@ -277,7 +278,7 @@ int etna_bo_get_name(struct etna_bo *bo, uint32_t *name)
return 0;
}
-uint32_t etna_bo_handle(struct etna_bo *bo)
+drm_public uint32_t etna_bo_handle(struct etna_bo *bo)
{
return bo->handle;
}
@@ -285,7 +286,7 @@ uint32_t etna_bo_handle(struct etna_bo *bo)
/* caller owns the dmabuf fd that is returned and is responsible
* to close() it when done
*/
-int etna_bo_dmabuf(struct etna_bo *bo)
+drm_public int etna_bo_dmabuf(struct etna_bo *bo)
{
int ret, prime_fd;
@@ -301,12 +302,12 @@ int etna_bo_dmabuf(struct etna_bo *bo)
return prime_fd;
}
-uint32_t etna_bo_size(struct etna_bo *bo)
+drm_public uint32_t etna_bo_size(struct etna_bo *bo)
{
return bo->size;
}
-void *etna_bo_map(struct etna_bo *bo)
+drm_public void *etna_bo_map(struct etna_bo *bo)
{
if (!bo->map) {
if (!bo->offset) {
@@ -324,7 +325,7 @@ void *etna_bo_map(struct etna_bo *bo)
return bo->map;
}
-int etna_bo_cpu_prep(struct etna_bo *bo, uint32_t op)
+drm_public int etna_bo_cpu_prep(struct etna_bo *bo, uint32_t op)
{
struct drm_etnaviv_gem_cpu_prep req = {
.handle = bo->handle,
@@ -337,7 +338,7 @@ int etna_bo_cpu_prep(struct etna_bo *bo, uint32_t op)
, sizeof(req));
}
-void etna_bo_cpu_fini(struct etna_bo *bo)
+drm_public void etna_bo_cpu_fini(struct etna_bo *bo)
{
struct drm_etnaviv_gem_cpu_fini req = {
.handle = bo->handle,
diff --git a/etnaviv/etnaviv_cmd_stream.c b/etnaviv/etnaviv_cmd_stream.c
index 13730168..7139c324 100644
--- a/etnaviv/etnaviv_cmd_stream.c
+++ b/etnaviv/etnaviv_cmd_stream.c
@@ -55,7 +55,8 @@ etna_cmd_stream_priv(struct etna_cmd_stream *stream)
return (struct etna_cmd_stream_priv *)stream;
}
-struct etna_cmd_stream *etna_cmd_stream_new(struct etna_pipe *pipe, uint32_t
size,
+drm_public struct etna_cmd_stream *etna_cmd_stream_new(struct etna_pipe *pipe,
+uint32_t size,
void (*reset_notify)(struct etna_cmd_stream *stream, void
*priv),
void *priv)
{
@@ -95,7 +96,7 @@ fail:
return NULL;
}
-void etna_cmd_stream_del(struct etna_cmd_stream *stream)
+drm_public void etna_cmd_stream_del(struct etna_cmd_stream *stream)
{
[PATCH libdrm v2 10/13] tegra: annotate public functions
while read sym; do
read f func line _ <<<$(cscope -d -L -1 $sym)
if [ ! -z "$f" ]; then
sed -i "${line}s/^/drm_public /" $f
fi
done < /tmp/a.txt
In which /tmp/a.txt contains the public symbols from
tegra-symbol-check. The idea here will be to switch the default
visibility to hidden so we don't export symbols we shouldn't.
Signed-off-by: Lucas De Marchi
---
tegra/tegra.c | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/tegra/tegra.c b/tegra/tegra.c
index 1d7268e5..cf00a3ca 100644
--- a/tegra/tegra.c
+++ b/tegra/tegra.c
@@ -70,7 +70,7 @@ static int drm_tegra_wrap(struct drm_tegra **drmp, int fd,
bool close)
return 0;
}
-int drm_tegra_new(struct drm_tegra **drmp, int fd)
+drm_public int drm_tegra_new(struct drm_tegra **drmp, int fd)
{
bool supported = false;
drmVersionPtr version;
@@ -90,7 +90,7 @@ int drm_tegra_new(struct drm_tegra **drmp, int fd)
return drm_tegra_wrap(drmp, fd, false);
}
-void drm_tegra_close(struct drm_tegra *drm)
+drm_public void drm_tegra_close(struct drm_tegra *drm)
{
if (!drm)
return;
@@ -101,7 +101,7 @@ void drm_tegra_close(struct drm_tegra *drm)
free(drm);
}
-int drm_tegra_bo_new(struct drm_tegra_bo **bop, struct drm_tegra *drm,
+drm_public int drm_tegra_bo_new(struct drm_tegra_bo **bop, struct drm_tegra
*drm,
uint32_t flags, uint32_t size)
{
struct drm_tegra_gem_create args;
@@ -139,7 +139,7 @@ int drm_tegra_bo_new(struct drm_tegra_bo **bop, struct
drm_tegra *drm,
return 0;
}
-int drm_tegra_bo_wrap(struct drm_tegra_bo **bop, struct drm_tegra *drm,
+drm_public int drm_tegra_bo_wrap(struct drm_tegra_bo **bop, struct drm_tegra
*drm,
uint32_t handle, uint32_t flags, uint32_t size)
{
struct drm_tegra_bo *bo;
@@ -162,7 +162,7 @@ int drm_tegra_bo_wrap(struct drm_tegra_bo **bop, struct
drm_tegra *drm,
return 0;
}
-struct drm_tegra_bo *drm_tegra_bo_ref(struct drm_tegra_bo *bo)
+drm_public struct drm_tegra_bo *drm_tegra_bo_ref(struct drm_tegra_bo *bo)
{
if (bo)
atomic_inc(>ref);
@@ -170,13 +170,13 @@ struct drm_tegra_bo *drm_tegra_bo_ref(struct drm_tegra_bo
*bo)
return bo;
}
-void drm_tegra_bo_unref(struct drm_tegra_bo *bo)
+drm_public void drm_tegra_bo_unref(struct drm_tegra_bo *bo)
{
if (bo && atomic_dec_and_test(>ref))
drm_tegra_bo_free(bo);
}
-int drm_tegra_bo_get_handle(struct drm_tegra_bo *bo, uint32_t *handle)
+drm_public int drm_tegra_bo_get_handle(struct drm_tegra_bo *bo, uint32_t
*handle)
{
if (!bo || !handle)
return -EINVAL;
@@ -186,7 +186,7 @@ int drm_tegra_bo_get_handle(struct drm_tegra_bo *bo,
uint32_t *handle)
return 0;
}
-int drm_tegra_bo_map(struct drm_tegra_bo *bo, void **ptr)
+drm_public int drm_tegra_bo_map(struct drm_tegra_bo *bo, void **ptr)
{
struct drm_tegra *drm = bo->drm;
@@ -218,7 +218,7 @@ int drm_tegra_bo_map(struct drm_tegra_bo *bo, void **ptr)
return 0;
}
-int drm_tegra_bo_unmap(struct drm_tegra_bo *bo)
+drm_public int drm_tegra_bo_unmap(struct drm_tegra_bo *bo)
{
if (!bo)
return -EINVAL;
@@ -234,7 +234,7 @@ int drm_tegra_bo_unmap(struct drm_tegra_bo *bo)
return 0;
}
-int drm_tegra_bo_get_flags(struct drm_tegra_bo *bo, uint32_t *flags)
+drm_public int drm_tegra_bo_get_flags(struct drm_tegra_bo *bo, uint32_t *flags)
{
struct drm_tegra_gem_get_flags args;
struct drm_tegra *drm = bo->drm;
@@ -257,7 +257,7 @@ int drm_tegra_bo_get_flags(struct drm_tegra_bo *bo,
uint32_t *flags)
return 0;
}
-int drm_tegra_bo_set_flags(struct drm_tegra_bo *bo, uint32_t flags)
+drm_public int drm_tegra_bo_set_flags(struct drm_tegra_bo *bo, uint32_t flags)
{
struct drm_tegra_gem_get_flags args;
struct drm_tegra *drm = bo->drm;
@@ -278,7 +278,7 @@ int drm_tegra_bo_set_flags(struct drm_tegra_bo *bo,
uint32_t flags)
return 0;
}
-int drm_tegra_bo_get_tiling(struct drm_tegra_bo *bo,
+drm_public int drm_tegra_bo_get_tiling(struct drm_tegra_bo *bo,
struct drm_tegra_bo_tiling *tiling)
{
struct drm_tegra_gem_get_tiling args;
@@ -304,7 +304,7 @@ int drm_tegra_bo_get_tiling(struct drm_tegra_bo *bo,
return 0;
}
-int drm_tegra_bo_set_tiling(struct drm_tegra_bo *bo,
+drm_public int drm_tegra_bo_set_tiling(struct drm_tegra_bo *bo,
const struct drm_tegra_bo_tiling *tiling)
{
struct drm_tegra_gem_set_tiling args;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm v2 09/13] radeon: annotate public functions
while read sym; do
read f func line _ <<<$(cscope -d -L -1 $sym)
if [ ! -z "$f" ]; then
sed -i "${line}s/^/drm_public /" $f
fi
done < /tmp/a.txt
In which /tmp/a.txt contains the public symbols from
radeon-symbol-check. The idea here will be to switch the default
visibility to hidden so we don't export symbols we shouldn't.
Signed-off-by: Lucas De Marchi
---
radeon/radeon_bo.c | 24
radeon/radeon_bo_gem.c | 16
radeon/radeon_cs.c | 24
radeon/radeon_cs_gem.c | 4 ++--
radeon/radeon_cs_space.c | 6 +++---
radeon/radeon_surface.c | 8
6 files changed, 41 insertions(+), 41 deletions(-)
diff --git a/radeon/radeon_bo.c b/radeon/radeon_bo.c
index 821807bc..cd06c26e 100644
--- a/radeon/radeon_bo.c
+++ b/radeon/radeon_bo.c
@@ -33,7 +33,7 @@
#include
#include
-void radeon_bo_debug(struct radeon_bo *bo, const char *op)
+drm_public void radeon_bo_debug(struct radeon_bo *bo, const char *op)
{
struct radeon_bo_int *boi = (struct radeon_bo_int *)bo;
@@ -41,7 +41,7 @@ void radeon_bo_debug(struct radeon_bo *bo, const char *op)
op, bo, bo->handle, boi->size, boi->cref);
}
-struct radeon_bo *
+drm_public struct radeon_bo *
radeon_bo_open(struct radeon_bo_manager *bom, uint32_t handle, uint32_t size,
uint32_t alignment, uint32_t domains, uint32_t flags)
{
@@ -50,14 +50,14 @@ radeon_bo_open(struct radeon_bo_manager *bom, uint32_t
handle, uint32_t size,
return bo;
}
-void radeon_bo_ref(struct radeon_bo *bo)
+drm_public void radeon_bo_ref(struct radeon_bo *bo)
{
struct radeon_bo_int *boi = (struct radeon_bo_int *)bo;
boi->cref++;
boi->bom->funcs->bo_ref(boi);
}
-struct radeon_bo *radeon_bo_unref(struct radeon_bo *bo)
+drm_public struct radeon_bo *radeon_bo_unref(struct radeon_bo *bo)
{
struct radeon_bo_int *boi = (struct radeon_bo_int *)bo;
if (bo == NULL)
@@ -79,7 +79,7 @@ int radeon_bo_unmap(struct radeon_bo *bo)
return boi->bom->funcs->bo_unmap(boi);
}
-int radeon_bo_wait(struct radeon_bo *bo)
+drm_public int radeon_bo_wait(struct radeon_bo *bo)
{
struct radeon_bo_int *boi = (struct radeon_bo_int *)bo;
if (!boi->bom->funcs->bo_wait)
@@ -87,13 +87,13 @@ int radeon_bo_wait(struct radeon_bo *bo)
return boi->bom->funcs->bo_wait(boi);
}
-int radeon_bo_is_busy(struct radeon_bo *bo, uint32_t *domain)
+drm_public int radeon_bo_is_busy(struct radeon_bo *bo, uint32_t *domain)
{
struct radeon_bo_int *boi = (struct radeon_bo_int *)bo;
return boi->bom->funcs->bo_is_busy(boi, domain);
}
-int
+drm_public int
radeon_bo_set_tiling(struct radeon_bo *bo,
uint32_t tiling_flags, uint32_t pitch)
{
@@ -101,7 +101,7 @@ radeon_bo_set_tiling(struct radeon_bo *bo,
return boi->bom->funcs->bo_set_tiling(boi, tiling_flags, pitch);
}
-int
+drm_public int
radeon_bo_get_tiling(struct radeon_bo *bo,
uint32_t *tiling_flags, uint32_t *pitch)
{
@@ -109,7 +109,7 @@ radeon_bo_get_tiling(struct radeon_bo *bo,
return boi->bom->funcs->bo_get_tiling(boi, tiling_flags, pitch);
}
-int radeon_bo_is_static(struct radeon_bo *bo)
+drm_public int radeon_bo_is_static(struct radeon_bo *bo)
{
struct radeon_bo_int *boi = (struct radeon_bo_int *)bo;
if (boi->bom->funcs->bo_is_static)
@@ -117,19 +117,19 @@ int radeon_bo_is_static(struct radeon_bo *bo)
return 0;
}
-int
+drm_public int
radeon_bo_is_referenced_by_cs(struct radeon_bo *bo, struct radeon_cs *cs)
{
struct radeon_bo_int *boi = (struct radeon_bo_int *)bo;
return boi->cref > 1;
}
-uint32_t radeon_bo_get_handle(struct radeon_bo *bo)
+drm_public uint32_t radeon_bo_get_handle(struct radeon_bo *bo)
{
return bo->handle;
}
-uint32_t radeon_bo_get_src_domain(struct radeon_bo *bo)
+drm_public uint32_t radeon_bo_get_src_domain(struct radeon_bo *bo)
{
struct radeon_bo_int *boi = (struct radeon_bo_int *)bo;
uint32_t src_domain;
diff --git a/radeon/radeon_bo_gem.c b/radeon/radeon_bo_gem.c
index 774b26e4..86f7c007 100644
--- a/radeon/radeon_bo_gem.c
+++ b/radeon/radeon_bo_gem.c
@@ -281,7 +281,7 @@ static const struct radeon_bo_funcs bo_gem_funcs = {
.bo_is_referenced_by_cs = NULL,
};
-struct radeon_bo_manager *radeon_bo_manager_gem_ctor(int fd)
+drm_public struct radeon_bo_manager *radeon_bo_manager_gem_ctor(int fd)
{
struct bo_manager_gem *bomg;
@@ -294,7 +294,7 @@ struct radeon_bo_manager *radeon_bo_manager_gem_ctor(int fd)
return (struct radeon_bo_manager*)bomg;
}
-void radeon_bo_manager_gem_dtor(struct radeon_bo_manager *bom)
+drm_public void radeon_bo_manager_gem_dtor(struct radeon_bo_manager *bom)
{
struct bo_manager_gem *bomg = (struct bo_manager_gem*)bom;
@@ -304,21 +304,21 @@ void radeon_bo_manager_gem_dtor(struct radeon_bo_manager
*bom)
free(bomg);
}
-uint32_t
+drm_public uint32_t
radeon_gem_name_bo(struct
[PATCH libdrm v2 03/13] nouveau: annotate public functions
This was done with:
nm --dynamic --defined-only build/nouveau/libdrm_nouveau.so | \
grep nouveau_ | \
cut -d ' ' -f3 > /tmp/a.txt
while read sym; do
read f func line _ <<<$(cscope -d -L -1 $sym)
if [ ! -z "$f" ]; then
line=$((line-1))
sed -i "${line}s/^/drm_public /" $f
fi
done < /tmp/a.txt
Then some corner cases were manually fixed. The idea here will be to
switch the default visibility to hidden so we don't export symbols we
shouldn't.
Signed-off-by: Lucas De Marchi
---
nouveau/bufctx.c | 10 +-
nouveau/nouveau.c | 50 +++
nouveau/pushbuf.c | 18 -
3 files changed, 39 insertions(+), 39 deletions(-)
diff --git a/nouveau/bufctx.c b/nouveau/bufctx.c
index 67b7570e..00924b3c 100644
--- a/nouveau/bufctx.c
+++ b/nouveau/bufctx.c
@@ -58,7 +58,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)
{
@@ -78,7 +78,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_bufctx_priv *pctx = nouveau_bufctx(*pbctx);
@@ -95,7 +95,7 @@ nouveau_bufctx_del(struct nouveau_bufctx **pbctx)
}
}
-void
+drm_public void
nouveau_bufctx_reset(struct nouveau_bufctx *bctx, int bin)
{
struct nouveau_bufctx_priv *pctx = nouveau_bufctx(bctx);
@@ -113,7 +113,7 @@ nouveau_bufctx_reset(struct nouveau_bufctx *bctx, int bin)
pbin->relocs = 0;
}
-struct nouveau_bufref *
+drm_public struct nouveau_bufref *
nouveau_bufctx_refn(struct nouveau_bufctx *bctx, int bin,
struct nouveau_bo *bo, uint32_t flags)
{
@@ -140,7 +140,7 @@ nouveau_bufctx_refn(struct nouveau_bufctx *bctx, int bin,
return >base;
}
-struct nouveau_bufref *
+drm_public struct nouveau_bufref *
nouveau_bufctx_mthd(struct nouveau_bufctx *bctx, int bin, uint32_t packet,
struct nouveau_bo *bo, uint64_t data, uint32_t flags,
uint32_t vor, uint32_t tor)
diff --git a/nouveau/nouveau.c b/nouveau/nouveau.c
index 55593517..5be0611e 100644
--- a/nouveau/nouveau.c
+++ b/nouveau/nouveau.c
@@ -88,7 +88,7 @@ nouveau_object_ioctl(struct nouveau_object *obj, void *data,
uint32_t size)
return drmCommandWriteRead(drm->fd, DRM_NOUVEAU_NVIF, args, argc);
}
-int
+drm_public int
nouveau_object_mthd(struct nouveau_object *obj,
uint32_t mthd, void *data, uint32_t size)
{
@@ -123,14 +123,14 @@ nouveau_object_mthd(struct nouveau_object *obj,
return ret;
}
-void
+drm_public void
nouveau_object_sclass_put(struct nouveau_sclass **psclass)
{
free(*psclass);
*psclass = NULL;
}
-int
+drm_public int
nouveau_object_sclass_get(struct nouveau_object *obj,
struct nouveau_sclass **psclass)
{
@@ -180,7 +180,7 @@ nouveau_object_sclass_get(struct nouveau_object *obj,
return ret;
}
-int
+drm_public int
nouveau_object_mclass(struct nouveau_object *obj,
const struct nouveau_mclass *mclass)
{
@@ -282,7 +282,7 @@ nouveau_object_init(struct nouveau_object *parent, uint32_t
handle,
return 0;
}
-int
+drm_public int
nouveau_object_new(struct nouveau_object *parent, uint64_t handle,
uint32_t oclass, void *data, uint32_t length,
struct nouveau_object **pobj)
@@ -303,7 +303,7 @@ nouveau_object_new(struct nouveau_object *parent, uint64_t
handle,
return 0;
}
-void
+drm_public void
nouveau_object_del(struct nouveau_object **pobj)
{
struct nouveau_object *obj = *pobj;
@@ -314,14 +314,14 @@ nouveau_object_del(struct nouveau_object **pobj)
}
}
-void
+drm_public void
nouveau_drm_del(struct nouveau_drm **pdrm)
{
free(*pdrm);
*pdrm = NULL;
}
-int
+drm_public int
nouveau_drm_new(int fd, struct nouveau_drm **pdrm)
{
struct nouveau_drm *drm;
@@ -353,14 +353,14 @@ nouveau_drm_new(int fd, struct nouveau_drm **pdrm)
* is kept here to prevent AIGLX from crashing if the DDX is linked against
* the new libdrm, but the DRI driver against the old
*/
-int
+drm_public int
nouveau_device_open_existing(struct nouveau_device **pdev, int close, int fd,
drm_context_t ctx)
{
return -EACCES;
}
-int
+drm_public int
nouveau_device_new(struct nouveau_object *parent, int32_t oclass,
void *data, uint32_t size, struct nouveau_device **pdev)
{
@@ -454,7 +454,7 @@ done:
return ret;
}
-int
+drm_public int
nouveau_device_wrap(int fd, int close, struct nouveau_device **pdev)
{
struct nouveau_drm *drm;
@@ -482,7 +482,7 @@ nouveau_device_wrap(int fd, int close, struct
[PATCH libdrm v2 00/13] hide library symbols by default
Rely on -fvisibility=hidden to hide the symbols. Previous version of this series applying only to drm_intel.so is Reviewed-by: Eric Engestrom but it's not included here since I changed the approach for the build system change. drm_private can also be removed from other symbols but it proved to be a lot of manual work to re-align all the fields, so I decided to leave it to be done on top as a cleanup. There were lots of changes to param alignement that had to be done manually, I may have missed some. Changes from v1: - Include changes for all other sub-libraries - Include changes to autotools - Make main Makefil.am and meson.build define the required flag This is build-tested locally and on gitlab: https://gitlab.freedesktop.org/demarchi/drm/pipelines/4339 Lucas De Marchi (13): intel: annotate public functions libkms: annotate public functions nouveau: annotate public functions libkms: annotate public functions libdrm: annotate public functions etnaviv: annotate public functions freedreno: annotate public functions omap: annotate public functions radeon: annotate public functions tegra: annotate public functions exynos: annotate public functions meson: make symbols hidden by default autotools: make symbols hidden by default Makefile.am | 1 + amdgpu/Makefile.am | 1 + amdgpu/amdgpu_bo.c | 104 ++-- amdgpu/amdgpu_cs.c | 137 +++ amdgpu/amdgpu_device.c | 19 ++- amdgpu/amdgpu_gpu_info.c | 51 +++--- amdgpu/amdgpu_vamgr.c| 24 +-- amdgpu/amdgpu_vm.c | 5 +- amdgpu/meson.build | 2 +- etnaviv/Makefile.am | 1 + etnaviv/etnaviv_bo.c | 25 +-- etnaviv/etnaviv_cmd_stream.c | 21 ++- etnaviv/etnaviv_device.c | 10 +- etnaviv/etnaviv_gpu.c| 6 +- etnaviv/etnaviv_perfmon.c| 8 +- etnaviv/etnaviv_pipe.c | 8 +- etnaviv/meson.build | 2 +- exynos/Makefile.am | 1 + exynos/exynos_drm.c | 30 ++-- exynos/exynos_fimg2d.c | 20 +-- exynos/meson.build | 2 +- freedreno/Makefile.am| 1 + freedreno/freedreno_bo.c | 32 ++-- freedreno/freedreno_device.c | 12 +- freedreno/freedreno_pipe.c | 14 +- freedreno/freedreno_ringbuffer.c | 40 ++--- freedreno/meson.build| 2 +- intel/Makefile.am| 1 + intel/intel_bufmgr.c | 64 +++ intel/intel_bufmgr_fake.c| 10 +- intel/intel_bufmgr_gem.c | 73 intel/intel_decode.c | 14 +- intel/meson.build| 4 +- libdrm_macros.h | 2 + libkms/Makefile.am | 1 + libkms/api.c | 16 +- libkms/meson.build | 2 +- meson.build | 5 +- nouveau/Makefile.am | 1 + nouveau/bufctx.c | 10 +- nouveau/meson.build | 2 +- nouveau/nouveau.c| 50 +++--- nouveau/pushbuf.c| 18 +- omap/Makefile.am | 1 + omap/meson.build | 2 +- omap/omap_drm.c | 36 ++-- radeon/Makefile.am | 1 + radeon/meson.build | 2 +- radeon/radeon_bo.c | 24 +-- radeon/radeon_bo_gem.c | 16 +- radeon/radeon_cs.c | 24 +-- radeon/radeon_cs_gem.c | 4 +- radeon/radeon_cs_space.c | 6 +- radeon/radeon_surface.c | 8 +- tegra/Makefile.am| 3 +- tegra/meson.build| 2 +- tegra/tegra.c| 26 +-- tests/Makefile.am| 1 + tests/amdgpu/Makefile.am | 1 + tests/etnaviv/Makefile.am| 1 + tests/exynos/Makefile.am | 1 + tests/exynos/meson.build | 6 +- tests/kms/Makefile.am| 3 +- tests/kms/meson.build| 2 +- tests/kmstest/Makefile.am| 1 + tests/kmstest/meson.build| 2 +- tests/meson.build| 8 +- tests/modeprint/Makefile.am | 1 + tests/modeprint/meson.build | 2 +- tests/modetest/Makefile.am | 1 + tests/modetest/meson.build | 2 +- tests/nouveau/Makefile.am| 1 + tests/nouveau/meson.build| 2 +- tests/proptest/Makefile.am | 1 + tests/proptest/meson.build | 2 +- tests/radeon/Makefile.am | 1 + tests/radeon/meson.build | 2 +- tests/tegra/Makefile.am | 4 +- tests/tegra/meson.build | 2 +- tests/vbltest/Makefile.am| 1 + tests/vbltest/meson.build| 2 +- vc4/Makefile.am | 1 + xf86drm.c| 276 --- xf86drmHash.c| 15 +-
[PATCH libdrm v2 05/13] libdrm: annotate public functions
This was done with:
nm --dynamic --defined-only build/libdrm.so | \
grep " T " | \
grep -v _fini | grep -v _init | \
cut -d' ' -f3 > /tmp/a.txt
while read sym; do
read f func line _ <<<$(cscope -d -L -1 $sym)
if [ ! -z "$f" ]; then
sed -i "${line}s/^/drm_public /" $f
fi
done < /tmp/a.txt
Then the alignment of function arguments were manually fixed all over.
The idea here will be to switch the default visibility to hidden so we
don't export symbols we shouldn't.
Signed-off-by: Lucas De Marchi
---
xf86drm.c | 276 +---
xf86drmHash.c | 15 +--
xf86drmMode.c | 158 ++-
xf86drmRandom.c | 9 +-
xf86drmSL.c | 23 ++--
5 files changed, 254 insertions(+), 227 deletions(-)
diff --git a/xf86drm.c b/xf86drm.c
index b2388194..49150d74 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -121,7 +121,7 @@ struct drm_pciinfo {
static drmServerInfoPtr drm_server_info;
-void drmSetServerInfo(drmServerInfoPtr info)
+drm_public void drmSetServerInfo(drmServerInfoPtr info)
{
drm_server_info = info;
}
@@ -141,7 +141,7 @@ drmDebugPrint(const char *format, va_list ap)
return vfprintf(stderr, format, ap);
}
-void
+drm_public void
drmMsg(const char *format, ...)
{
va_list ap;
@@ -161,17 +161,17 @@ drmMsg(const char *format, ...)
static void *drmHashTable = NULL; /* Context switch callbacks */
-void *drmGetHashTable(void)
+drm_public void *drmGetHashTable(void)
{
return drmHashTable;
}
-void *drmMalloc(int size)
+drm_public void *drmMalloc(int size)
{
return calloc(1, size);
}
-void drmFree(void *pt)
+drm_public void drmFree(void *pt)
{
free(pt);
}
@@ -179,7 +179,7 @@ void drmFree(void *pt)
/**
* Call ioctl, restarting if it is interupted
*/
-int
+drm_public int
drmIoctl(int fd, unsigned long request, void *arg)
{
int ret;
@@ -199,7 +199,7 @@ static unsigned long drmGetKeyFromFd(int fd)
return st.st_rdev;
}
-drmHashEntry *drmGetEntry(int fd)
+drm_public drmHashEntry *drmGetEntry(int fd)
{
unsigned long key = drmGetKeyFromFd(fd);
void *value;
@@ -490,7 +490,7 @@ static int drmOpenMinor(int minor, int create, int type)
* minor and get version information. For backward compatibility with older
* Linux implementations, /proc/dri is also checked.
*/
-int drmAvailable(void)
+drm_public int drmAvailable(void)
{
drmVersionPtr version;
int retval = 0;
@@ -725,7 +725,7 @@ static int drmOpenByName(const char *name, int type)
* It calls drmOpenByBusid() if \p busid is specified or drmOpenByName()
* otherwise.
*/
-int drmOpen(const char *name, const char *busid)
+drm_public int drmOpen(const char *name, const char *busid)
{
return drmOpenWithType(name, busid, DRM_NODE_PRIMARY);
}
@@ -746,7 +746,7 @@ int drmOpen(const char *name, const char *busid)
* It calls drmOpenByBusid() if \p busid is specified or drmOpenByName()
* otherwise.
*/
-int drmOpenWithType(const char *name, const char *busid, int type)
+drm_public int drmOpenWithType(const char *name, const char *busid, int type)
{
if (!drmAvailable() && name != NULL && drm_server_info &&
drm_server_info->load_module) {
@@ -769,12 +769,12 @@ int drmOpenWithType(const char *name, const char *busid,
int type)
return -1;
}
-int drmOpenControl(int minor)
+drm_public int drmOpenControl(int minor)
{
return drmOpenMinor(minor, 0, DRM_NODE_CONTROL);
}
-int drmOpenRender(int minor)
+drm_public int drmOpenRender(int minor)
{
return drmOpenMinor(minor, 0, DRM_NODE_RENDER);
}
@@ -788,7 +788,7 @@ int drmOpenRender(int minor)
* It frees the memory pointed by \p %v as well as all the non-null strings
* pointers in it.
*/
-void drmFreeVersion(drmVersionPtr v)
+drm_public void drmFreeVersion(drmVersionPtr v)
{
if (!v)
return;
@@ -858,7 +858,7 @@ static void drmCopyVersion(drmVersionPtr d, const
drm_version_t *s)
* first with zeros to get the string lengths, and then the actually strings.
* It also null-terminates them since they might not be already.
*/
-drmVersionPtr drmGetVersion(int fd)
+drm_public drmVersionPtr drmGetVersion(int fd)
{
drmVersionPtr retval;
drm_version_t *version = drmMalloc(sizeof(*version));
@@ -906,7 +906,7 @@ drmVersionPtr drmGetVersion(int fd)
* This function allocates and fills a drm_version structure with a hard coded
* version number.
*/
-drmVersionPtr drmGetLibVersion(int fd)
+drm_public drmVersionPtr drmGetLibVersion(int fd)
{
drm_version_t *version = drmMalloc(sizeof(*version));
@@ -927,7 +927,7 @@ drmVersionPtr drmGetLibVersion(int fd)
return (drmVersionPtr)version;
}
-int drmGetCap(int fd, uint64_t capability, uint64_t *value)
+drm_public int drmGetCap(int fd, uint64_t capability, uint64_t *value)
{
struct drm_get_cap cap;
int ret;
@@ -943,7 +943,7 @@ int drmGetCap(int fd, uint64_t
[PATCH libdrm v2 02/13] libkms: annotate public functions
This was done with:
nm --dynamic --defined-only build/libkms/libkms.so | \
grep kms_ | \
cut -d' ' -f3 > /tmp/a.txt
while read sym; do
read f func line _ <<<$(cscope -d -L -1 $sym)
if [ ! -z "$f" ]; then
sed -i "${line}s/^/drm_public /" $f
fi
done < /tmp/a.txt
The idea here will be to switch the default visibility to hidden so we
don't export symbols we shouldn't.
Signed-off-by: Lucas De Marchi
---
libkms/api.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/libkms/api.c b/libkms/api.c
index 22dd32d7..caca1a87 100644
--- a/libkms/api.c
+++ b/libkms/api.c
@@ -33,12 +33,12 @@
#include "libdrm_macros.h"
#include "internal.h"
-int kms_create(int fd, struct kms_driver **out)
+drm_public int kms_create(int fd, struct kms_driver **out)
{
return linux_create(fd, out);
}
-int kms_get_prop(struct kms_driver *kms, unsigned key, unsigned *out)
+drm_public int kms_get_prop(struct kms_driver *kms, unsigned key, unsigned
*out)
{
switch (key) {
case KMS_BO_TYPE:
@@ -49,7 +49,7 @@ int kms_get_prop(struct kms_driver *kms, unsigned key,
unsigned *out)
return kms->get_prop(kms, key, out);
}
-int kms_destroy(struct kms_driver **kms)
+drm_public int kms_destroy(struct kms_driver **kms)
{
if (!(*kms))
return 0;
@@ -59,7 +59,7 @@ int kms_destroy(struct kms_driver **kms)
return 0;
}
-int kms_bo_create(struct kms_driver *kms, const unsigned *attr, struct kms_bo
**out)
+drm_public int kms_bo_create(struct kms_driver *kms, const unsigned *attr,
struct kms_bo **out)
{
unsigned width = 0;
unsigned height = 0;
@@ -97,7 +97,7 @@ int kms_bo_create(struct kms_driver *kms, const unsigned
*attr, struct kms_bo **
return kms->bo_create(kms, width, height, type, attr, out);
}
-int kms_bo_get_prop(struct kms_bo *bo, unsigned key, unsigned *out)
+drm_public int kms_bo_get_prop(struct kms_bo *bo, unsigned key, unsigned *out)
{
switch (key) {
case KMS_PITCH:
@@ -113,17 +113,17 @@ int kms_bo_get_prop(struct kms_bo *bo, unsigned key,
unsigned *out)
return 0;
}
-int kms_bo_map(struct kms_bo *bo, void **out)
+drm_public int kms_bo_map(struct kms_bo *bo, void **out)
{
return bo->kms->bo_map(bo, out);
}
-int kms_bo_unmap(struct kms_bo *bo)
+drm_public int kms_bo_unmap(struct kms_bo *bo)
{
return bo->kms->bo_unmap(bo);
}
-int kms_bo_destroy(struct kms_bo **bo)
+drm_public int kms_bo_destroy(struct kms_bo **bo)
{
int ret;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm v2 01/13] intel: annotate public functions
This was done with:
while read sym; do
read f func line _ <<<$(cscope -d -L -1 $sym)
if [ ! -z "$f" ]; then
line=$((line-1))
sed -i "${line}s/^/drm_public /" $f
fi
done < /tmp/a.txt
Then some corner cases were manually fixed. "a.txt" above contains the
symbols collected from intel/intel-symbol-check. The idea here will be
to switch the default visibility to hidden so we don't export symbols we
shouldn't.
Signed-off-by: Lucas De Marchi
---
intel/intel_bufmgr.c | 64 +-
intel/intel_bufmgr_fake.c | 10 +++---
intel/intel_bufmgr_gem.c | 73 +++
intel/intel_decode.c | 14
libdrm_macros.h | 2 ++
5 files changed, 82 insertions(+), 81 deletions(-)
diff --git a/intel/intel_bufmgr.c b/intel/intel_bufmgr.c
index 192de093..68d97c0e 100644
--- a/intel/intel_bufmgr.c
+++ b/intel/intel_bufmgr.c
@@ -45,21 +45,21 @@
* Convenience functions for buffer management methods.
*/
-drm_intel_bo *
+drm_public drm_intel_bo *
drm_intel_bo_alloc(drm_intel_bufmgr *bufmgr, const char *name,
unsigned long size, unsigned int alignment)
{
return bufmgr->bo_alloc(bufmgr, name, size, alignment);
}
-drm_intel_bo *
+drm_public drm_intel_bo *
drm_intel_bo_alloc_for_render(drm_intel_bufmgr *bufmgr, const char *name,
unsigned long size, unsigned int alignment)
{
return bufmgr->bo_alloc_for_render(bufmgr, name, size, alignment);
}
-drm_intel_bo *
+drm_public drm_intel_bo *
drm_intel_bo_alloc_userptr(drm_intel_bufmgr *bufmgr,
const char *name, void *addr,
uint32_t tiling_mode,
@@ -73,7 +73,7 @@ drm_intel_bo_alloc_userptr(drm_intel_bufmgr *bufmgr,
return NULL;
}
-drm_intel_bo *
+drm_public drm_intel_bo *
drm_intel_bo_alloc_tiled(drm_intel_bufmgr *bufmgr, const char *name,
int x, int y, int cpp, uint32_t *tiling_mode,
unsigned long *pitch, unsigned long flags)
@@ -82,13 +82,13 @@ drm_intel_bo_alloc_tiled(drm_intel_bufmgr *bufmgr, const
char *name,
tiling_mode, pitch, flags);
}
-void
+drm_public void
drm_intel_bo_reference(drm_intel_bo *bo)
{
bo->bufmgr->bo_reference(bo);
}
-void
+drm_public void
drm_intel_bo_unreference(drm_intel_bo *bo)
{
if (bo == NULL)
@@ -97,26 +97,26 @@ drm_intel_bo_unreference(drm_intel_bo *bo)
bo->bufmgr->bo_unreference(bo);
}
-int
+drm_public int
drm_intel_bo_map(drm_intel_bo *buf, int write_enable)
{
return buf->bufmgr->bo_map(buf, write_enable);
}
-int
+drm_public int
drm_intel_bo_unmap(drm_intel_bo *buf)
{
return buf->bufmgr->bo_unmap(buf);
}
-int
+drm_public int
drm_intel_bo_subdata(drm_intel_bo *bo, unsigned long offset,
unsigned long size, const void *data)
{
return bo->bufmgr->bo_subdata(bo, offset, size, data);
}
-int
+drm_public int
drm_intel_bo_get_subdata(drm_intel_bo *bo, unsigned long offset,
unsigned long size, void *data)
{
@@ -135,26 +135,26 @@ drm_intel_bo_get_subdata(drm_intel_bo *bo, unsigned long
offset,
return 0;
}
-void
+drm_public void
drm_intel_bo_wait_rendering(drm_intel_bo *bo)
{
bo->bufmgr->bo_wait_rendering(bo);
}
-void
+drm_public void
drm_intel_bufmgr_destroy(drm_intel_bufmgr *bufmgr)
{
bufmgr->destroy(bufmgr);
}
-int
+drm_public int
drm_intel_bo_exec(drm_intel_bo *bo, int used,
drm_clip_rect_t * cliprects, int num_cliprects, int DR4)
{
return bo->bufmgr->bo_exec(bo, used, cliprects, num_cliprects, DR4);
}
-int
+drm_public int
drm_intel_bo_mrb_exec(drm_intel_bo *bo, int used,
drm_clip_rect_t *cliprects, int num_cliprects, int DR4,
unsigned int rings)
@@ -174,19 +174,19 @@ drm_intel_bo_mrb_exec(drm_intel_bo *bo, int used,
}
}
-void
+drm_public void
drm_intel_bufmgr_set_debug(drm_intel_bufmgr *bufmgr, int enable_debug)
{
bufmgr->debug = enable_debug;
}
-int
+drm_public int
drm_intel_bufmgr_check_aperture_space(drm_intel_bo ** bo_array, int count)
{
return bo_array[0]->bufmgr->check_aperture_space(bo_array, count);
}
-int
+drm_public int
drm_intel_bo_flink(drm_intel_bo *bo, uint32_t * name)
{
if (bo->bufmgr->bo_flink)
@@ -195,7 +195,7 @@ drm_intel_bo_flink(drm_intel_bo *bo, uint32_t * name)
return -ENODEV;
}
-int
+drm_public int
drm_intel_bo_emit_reloc(drm_intel_bo *bo, uint32_t offset,
drm_intel_bo *target_bo, uint32_t target_offset,
uint32_t read_domains, uint32_t write_domain)
@@ -206,7 +206,7 @@ drm_intel_bo_emit_reloc(drm_intel_bo *bo, uint32_t offset,
}
/* For fence registers, not GL fences */
-int
+drm_public int
drm_intel_bo_emit_reloc_fence(drm_intel_bo *bo, uint32_t
Re: [PATCH] drm/msm/dpu: Remove an unused enum
On 2018-09-13 09:46, Jordan Crouse wrote:
enum dpu_ad isn't used and can be safely removed.
Signed-off-by: Jordan Crouse
---
Reviewed-by: Jeykumar Sankaran
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h
index 62cf127b16d4..68c54d2c9677 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h
@@ -232,12 +232,6 @@ enum dpu_wb {
WB_MAX
};
-enum dpu_ad {
- AD_0 = 0x1,
- AD_1,
- AD_MAX
-};
-
enum dpu_cwb {
CWB_0 = 0x1,
CWB_1,
--
Jeykumar S
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: Return -ENOTSUPP in drm_setclientcap() when driver do not support KMS
All DRM_CLIENT capabilities are tied to KMS support, so returning
-ENOTSUPP when KMS is not supported.
Cc: Chris Wilson
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/drm_ioctl.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 6b4a633b4240..842423fe9762 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -306,6 +306,9 @@ drm_setclientcap(struct drm_device *dev, void *data, struct
drm_file *file_priv)
{
struct drm_set_client_cap *req = data;
+ if (!drm_core_check_feature(dev, DRIVER_MODESET))
+ return -ENOTSUPP;
+
switch (req->capability) {
case DRM_CLIENT_CAP_STEREO_3D:
if (req->value > 1)
--
2.19.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 08/16] drm: rcar-du: Enable configurable DPAD0 routing on Gen3
Hi Jacopo,
Thank you for the patch.
On Tuesday, 11 September 2018 18:46:53 EEST jacopo mondi wrote:
> On Tue, Sep 04, 2018 at 03:10:19PM +0300, Laurent Pinchart wrote:
> > All Gen3 SoCs supported so far have a fixed association between DPAD0
> > and DU channels, which led to hardcoding that association when writing
> > the corresponding hardware register. The D3 and E3 will break that
> > mechanism as DPAD0 can be dynamically connected to either DU0 or DU1.
> >
> > Make DPAD0 routing dynamic on Gen3. To ensure a valid hardware
> > configuration when the DU starts without the RGB output enabled, DPAD0
> > is associated at initialization time to the first DU channel that it can
> > be connected to. This makes no change on Gen2 as all Gen2 SoCs can
> > connected DPAD0 to DU0, which is the current implicit default value.
> >
> > As the DPAD0 source is always 0 when a single source is possible on
> > Gen2, we can also simplify the Gen2 code in the same function to remove
> > a conditional check.
>
> Does this patch only prepares for routing to be mad dynamic or it is
> already supported?
It's already dynamic. We support dynamic routing of the DPAD (RGB) output on
Gen2. On Gen3 all the SoCs supported so far could only route one CRTC to the
DPAD output, so the routing wasn't very dynamic, but the register still had to
be programmed accordingly. This patch reuses the existing dynamic routing that
we use on Gen2 for Gen3.
> I am missing where those dynamic association happens, as I see the
> possible dpad0 source being changed in 'rcar_du_crtc_route_output()'
> which is in turn called by the mode set operation
> 'rcar_du_crtc_route_output()'.
>
> But at the same time, I only see the routing register DEFR8 being
> written by rcar_du_group_setup_defr8() called by the group route setup
> operation rcar_du_group_set_routing() called at crtc setup time only.
>
> Would the mode set operation on the encoder being supporsed to go to
> the group's set_routing operation? Or does DEFR8 configuration happens
> with a different call path?
Your analysis of the code flow is right. The reason why we don't write DEFR8
directly is that changes to the register only take effect when the group is
disabled (lovely hardware design, isn't it ?). The driver relies on the fact
that changing the routing involves disabling and enabling CRTCs, but the
mechanism is fragile, and it might even be buggy.
The RGB output on D3 and E3 isn't officially supported by this patch series,
so I already plan to revisit the code later and hopefully clean it.
> > Signed-off-by: Laurent Pinchart
> >
> > ---
> >
> > drivers/gpu/drm/rcar-du/rcar_du_group.c | 17 ++---
> > drivers/gpu/drm/rcar-du/rcar_du_kms.c | 12
> > 2 files changed, 18 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_group.c
> > b/drivers/gpu/drm/rcar-du/rcar_du_group.c index
> > 4c62841eff2f..f38703e7a10d 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_group.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_group.c
> > @@ -56,8 +56,6 @@ static void rcar_du_group_setup_pins(struct
> > rcar_du_group *rgrp)
> > static void rcar_du_group_setup_defr8(struct rcar_du_group *rgrp)
> > {
> > struct rcar_du_device *rcdu = rgrp->dev;
> > - unsigned int possible_crtcs =
> > - rcdu->info->routes[RCAR_DU_OUTPUT_DPAD0].possible_crtcs;
> > u32 defr8 = DEFR8_CODE;
> >
> > if (rcdu->info->gen < 3) {
> > @@ -69,21 +67,18 @@ static void rcar_du_group_setup_defr8(struct
> > rcar_du_group *rgrp)
> > * DU instances that support it.
> > */
> > if (rgrp->index == 0) {
> > - if (possible_crtcs > 1)
> > - defr8 |= DEFR8_DRGBS_DU(rcdu->dpad0_source);
> > + defr8 |= DEFR8_DRGBS_DU(rcdu->dpad0_source);
> > if (rgrp->dev->vspd1_sink == 2)
> > defr8 |= DEFR8_VSCS;
> > }
> > } else {
> > /*
> > -* On Gen3 VSPD routing can't be configured, but DPAD routing
> > -* needs to be set despite having a single option available.
> > +* On Gen3 VSPD routing can't be configured, and DPAD routing
> > +* is set in the group corresponding to the DPAD output (no Gen3
> > +* SoC has multiple DPAD sources belonging to separate groups).
> > */
> > - unsigned int rgb_crtc = ffs(possible_crtcs) - 1;
> > - struct rcar_du_crtc *crtc = >crtcs[rgb_crtc];
> > -
> > - if (crtc->index / 2 == rgrp->index)
> > - defr8 |= DEFR8_DRGBS_DU(crtc->index);
> > + if (rgrp->index == rcdu->dpad0_source / 2)
> > + defr8 |= DEFR8_DRGBS_DU(rcdu->dpad0_source);
> > }
> >
> > rcar_du_group_write(rgrp, DEFR8, defr8);
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> > b/drivers/gpu/drm/rcar-du/rcar_du_kms.c index
Re: [PATCH 07/16] drm: rcar-du: Use LVDS PLL clock as dot clock when possible
Hi Jacopo,
On Tuesday, 11 September 2018 17:59:02 EEST jacopo mondi wrote:
> On Tue, Sep 04, 2018 at 03:10:18PM +0300, Laurent Pinchart wrote:
> > On selected SoCs, the DU can use the clock output by the LVDS encoder
> > PLL as its input dot clock. This feature is optional, but on the D3 and
> > E3 SoC it is often the only way to obtain a precise dot clock frequency,
> > as the other available clocks (CPG-generated clock and external clock)
> > usually have fixed rates.
> >
> > Add a DU model information field to describe which DU channels can use
> > the LVDS PLL output clock as their input clock, and configure clock
> > routing accordingly.
> >
> > This feature is available on H2, M2-W, M2-N, D3 and E3 SoCs, with D3 and
> > E3 being the primary targets. It is left disabled in this commit, and
> > will be enabled per-SoC after careful testing.
> >
> > At the hardware level, clock routing is configured at runtime in two
> > steps, first selecting an internal dot clock between the LVDS PLL clock
> > and the external DOTCLKIN clock, and then selecting between the internal
> > dot clock and the CPG-generated clock. The first part requires stopping
> > the whole DU group in order for the change to take effect, thus causing
> > flickering on the screen. For this reason we currently hardcode the
> > clock source the the LVDS PLL clock if available, and allow flicker-free
>
> s/the the/to the/ ?
Fixed.
> > selection of the external DOTCLKIN clock or CPG-generated clock
> > otherwise. A more dynamic clock selection process can be implemented
> > later if the need arises.
> >
> > Signed-off-by: Laurent Pinchart
> >
> > ---
> >
> > drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 8 +
> > drivers/gpu/drm/rcar-du/rcar_du_drv.h | 2 ++
> > drivers/gpu/drm/rcar-du/rcar_du_group.c | 64 +---
> > 3 files changed, 59 insertions(+), 15 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> > b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c index 1d81eb21..39d2fee6d7b8
> > 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> > @@ -261,6 +261,14 @@ static void rcar_du_crtc_set_display_timing(struct
> > rcar_du_crtc *rcrtc)
> > rcar_du_group_write(rcrtc->group, DPLLCR, dpllcr);
> >
> > escr = ESCR_DCLKSEL_DCLKIN | div;
> > + } else if (rcdu->info->lvds_clk_mask & BIT(rcrtc->index)) {
> > + /*
> > +* Use the LVDS PLL output as the dot clock when outputting to
> > +* the LVDS encoder on an SoC that supports this clock routing
> > +* option. We use the clock directly in that case, without any
> > +* additional divider.
> > +*/
> > + escr = ESCR_DCLKSEL_DCLKIN;
>
> This confused me, but we have later clarified offline.
> Setting the DCLKIN bit alone does not guarantee that we use the LVDS
> PLL clock output, but the DIDSR mux must be configured to select LVDS
> over dotclkin[0] or dotclkin[1] first. Would you consider mentioning DIDSR
> in the comment here?
Please see below.
> > } else {
> > struct du_clk_params params = { .diff = (unsigned long)-1 };
[snip]
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_group.c
> > b/drivers/gpu/drm/rcar-du/rcar_du_group.c index
> > ef2c177afb6d..4c62841eff2f 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_group.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_group.c
> > @@ -89,6 +89,54 @@ static void rcar_du_group_setup_defr8(struct
> > rcar_du_group *rgrp)
> > rcar_du_group_write(rgrp, DEFR8, defr8);
> > }
> >
> > +static void rcar_du_group_setup_didsr(struct rcar_du_group *rgrp)
> > +{
> > + struct rcar_du_device *rcdu = rgrp->dev;
> > + struct rcar_du_crtc *rcrtc;
> > + unsigned int num_crtcs = 0;
> > + unsigned int i;
> > + u32 didsr;
> > +
> > + /*
> > +* Configure input dot clock routing with a hardcoded configuration. If
> > +* the DU channel can use the LVDS encoder output clock as the dot
> > +* clock, do so. Otherwise route DU_DOTCLKINn signal to DUn.
> > +*
> > +* Each channel can then select between the dot clock configured here
> > +* and the clock provided by the CPG through the ESCR register.
> > +*/
>
> well, you mention ESCR here, so maybe no need to do the same above...
> up to you...
Being lazy at this time of the night I won't change it unless you think I
should :-)
> > + if (rcdu->info->gen < 3 && rgrp->index == 0) {
> > + /*
> > +* On Gen2 a single register in the first group controls dot
> > +* clock selection for all channels.
> > +*/
> > + rcrtc = rcdu->crtcs;
> > + num_crtcs = rcdu->num_crtcs;
> > + } else if (rcdu->info->gen == 3 && rgrp->num_crtcs > 1) {
> > + /*
> > +* On Gen3 dot clocks are setup through per-group registers,
> > +* only available when the group has two
Re: [PATCH 05/16] drm: rcar-du: lvds: D3/E3 support
Hi Jacopo,
On Tuesday, 11 September 2018 16:23:23 EEST jacopo mondi wrote:
> On Tue, Sep 04, 2018 at 03:10:16PM +0300, Laurent Pinchart wrote:
> > The LVDS encoders in the D3 and E3 SoCs differ significantly from those
> > in the other R-Car Gen3 family members:
> >
> > - The LVDS PLL architecture is more complex and requires computing PLL
> > parameters manually.
> >
> > - The PLL uses external clocks as inputs, which need to be retrieved
> > from DT.
> >
> > - In addition to the different PLL setup, the startup sequence has
> > changed *again* (seems someone had trouble making his/her mind).
> >
> > Supporting all this requires DT bindings extensions for external clocks,
> > brand new PLL setup code, and a few quirks to handle the differences in
> > the startup sequence.
> >
> > The implementation doesn't support all hardware features yet, namely
> >
> > - Using the LV[01] clocks generated by the CPG as PLL input.
> > - Providing the LVDS PLL clock to the DU for use with the RGB output.
> >
> > Those features can be added later when the need will arise.
> >
> > Signed-off-by: Laurent Pinchart
> >
> > ---
> >
> > drivers/gpu/drm/rcar-du/rcar_lvds.c | 365 ++
> > drivers/gpu/drm/rcar-du/rcar_lvds_regs.h | 43 +++-
> > 2 files changed, 361 insertions(+), 47 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c
> > b/drivers/gpu/drm/rcar-du/rcar_lvds.c index ce0eb68c3416..aac4acbcfbfc
> > 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
[snip]
> > +struct pll_info {
> > + struct clk *clk;
> > + unsigned long diff;
> > + unsigned int pll_m;
> > + unsigned int pll_n;
> > + unsigned int pll_e;
> > + unsigned int div;
> > +};
> > +
> > +static void rcar_lvds_d3_e3_pll_calc(struct rcar_lvds *lvds, struct clk
> > *clk,
> > +unsigned long target, struct pll_info *pll)
>
> Do you think it is worth mentioning d3_e3 in the function name? I know
> it's not a big deal, but in future generation this PLL circuit may be
> re-used.
How would you name it ? Other LVDS encoder instances have a different PLL, and
they are not named in the datasheet. I propose renaming it later if needed.
> > +{
> > + unsigned long fin;
> > + unsigned int m_min;
> > + unsigned int m_max;
> > + unsigned int m;
> > +
> > + if (!clk)
> > + return;
> > +
> > + /*
> > +* The LVDS PLL is made of a pre-divider and a multiplier (strangerly
> > +* enough called M and N respectively), followed by a post-divider E.
> > +*
> > +* ,-. ,-. ,-. ,-.
> > +* Fin --> | 1/M | -Fpdf-> | PFD | --> | VCO | -Fvco-> | 1/E | --> Fout
> > +* `-' ,-> | | `-' | `-'
> > +* | `-' |
> > +* | ,-. |
> > +* ` | 1/N | <---'
> > +* `-'
> > +*
> > +* The clock output by the PLL is then further divided by a
programmable
> > +* divider DIV to achieve the desired target frequency. Finally, an
> > +* optional fixed /7 divider is used to convert the bit clock to a
pixel
> > +* clock (as LVDS transmits 7 bits per lane per clock sample).
> > +*
> > +* ,---. ,-. |\
> > +* Fout --> | 1/DIV | --> | 1/7 | --> | |
> > +* `---' | `-' | | --> dot clock
> > +* `> | |
> > +*|/
> > +*
> > +* The /7 divider is optional when the LVDS PLL is used to generate a
> > +* dot clock for the DU RGB output, without using the LVDS encoder. We
> > +* don't support this configuration yet.
> > +*
> > +* The PLL allowed input frequency range is 12 MHz to 192 MHz.
> > +*/
> > +
> > + fin = clk_get_rate(clk);
> > + if (fin < 1200 || fin > 19200)
> > + return;
> > +
> > + /*
> > +* The comparison frequency range is 12 MHz to 24 MHz, which limits the
> > +* allowed values for the pre-divider M (normal range 1-8).
> > +*
> > +* Fpfd = Fin / M
> > +*/
> > + m_min = max_t(unsigned int, 1, DIV_ROUND_UP(fin, 2400));
> > + m_max = min_t(unsigned int, 8, fin / 1200);
> > +
> > + for (m = m_min; m <= m_max; ++m) {
> > + unsigned long fpfd;
> > + unsigned int n_min;
> > + unsigned int n_max;
> > + unsigned int n;
> > +
> > + /*
> > +* The VCO operating range is 900 Mhz to 1800 MHz, which limits
> > +* the allowed values for the multiplier N (normal range
> > +* 60-120).
> > +*
> > +* Fvco = Fin * N / M
> > +*/
> > + fpfd = fin / m;
> > + n_min = max_t(unsigned int, 60, DIV_ROUND_UP(9,
Re: [PATCH 04/16] drm: bridge: thc63: Restrict modes based on hardware operating frequency
Hi Jacopo,
On Tuesday, 11 September 2018 16:31:55 EEST jacopo mondi wrote:
> Hi Laurent,
>sorry, I might be confused but,
>
> On Tue, Sep 04, 2018 at 03:10:15PM +0300, Laurent Pinchart wrote:
> > The THC63LVD1024 is restricted to a pixel clock frequency in the range
> > of 8 to 135 MHz. Implement the bridge .mode_valid() operation
> > accordingly.
> >
> > Signed-off-by: Laurent Pinchart
> >
> > ---
> >
> > drivers/gpu/drm/bridge/thc63lvd1024.c | 18 ++
> > 1 file changed, 18 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/bridge/thc63lvd1024.c
> > b/drivers/gpu/drm/bridge/thc63lvd1024.c index c8b9edd5a7f4..63609ba16b6d
> > 100644
> > --- a/drivers/gpu/drm/bridge/thc63lvd1024.c
> > +++ b/drivers/gpu/drm/bridge/thc63lvd1024.c
> > @@ -45,6 +45,23 @@ static int thc63_attach(struct drm_bridge *bridge)
> > return drm_bridge_attach(bridge->encoder, thc63->next, bridge);
> > }
> >
> > +static enum drm_mode_status thc63_mode_valid(struct drm_bridge *bridge,
> > + const struct drm_display_mode *mode)
> > +{
> > + /*
> > +* The THC63LVD0124 clock frequency range is 8 to 135 MHz in single-in,
> > +* single-out mode. Note that the limits depends on the mode and will
> > +* need to be adjusted accordingly.
> > +*/
> > + if (mode->clock < 8000)
> > + return MODE_CLOCK_LOW;
> > +
> > + if (mode->clock > 135000)
> > + return MODE_CLOCK_HIGH;
> > +
> > + return MODE_OK;
> > +}
> > +
>
> Are we talking about the CLKOUT frequency? Because that's the one I
> see depending on the dual/single output mode, and I assume we're
> checking for the mode->clock of the DRM mode to be applied to the
> connector (which receives an RGB stream from this bridge).
>
> In case we're talking about CLKOUT, I read
>
> "Dual LVDS port IN/Dual TTL port Out Mode:
> 8 - 135MHz(CLKOUT)
> Dual LVDS port IN/Single TTL port Out Mode:
> 40 - 150MHz(CLKOUT)"
>
> If we're talking about the PLL input clock (RCLK) then used to
> generate CLKOUT it's indeed defined in the 8-135Mhz range, but
> I don't see mention on it depending on the mode.
This is about the input clock on the LVDS side of the LVDS decoder, named
RCLK. It is received from the LVDS interface on the other side and its
frequency is equal to the pixel clock.
> > static void thc63_enable(struct drm_bridge *bridge)
> > {
> > struct thc63_dev *thc63 = to_thc63(bridge);
> > @@ -77,6 +94,7 @@ static void thc63_disable(struct drm_bridge *bridge)
> >
> > static const struct drm_bridge_funcs thc63_bridge_func = {
> > .attach = thc63_attach,
> > + .mode_valid = thc63_mode_valid,
> > .enable = thc63_enable,
> > .disable = thc63_disable,
> > };
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/nouveau: Disable atomic support on a per-device basis
Hm, one nitpick here. Since /sys/kernel/debug/dri/*/state creation depends on the driver supporting atomic, maybe it would be good to make it so that we set DRIVER_ATOMIC in the driver_stub structure, then disable it per-device depending on the nouveau_atomic setting + hw support. That way we can always have the state debugfs file while maintaining nouveau's current behavior with exposing atomic ioctls. Assuming that wouldn't have any unintended side-effects of course On Thu, 2018-09-13 at 19:31 +0300, Ville Syrjala wrote: > From: Ville Syrjälä > > We now have per-device driver_features, so let's use that > to disable atomic only for pre-nv50. > > Cc: Ben Skeggs > Cc: Lyude Paul > Cc: nouv...@lists.freedesktop.org > Cc: Daniel Vetter > Reviewed-by: Daniel Vetter > Suggested-by: Daniel Vetter > Signed-off-by: Ville Syrjälä > --- > drivers/gpu/drm/nouveau/dispnv04/disp.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/nouveau/dispnv04/disp.c > b/drivers/gpu/drm/nouveau/dispnv04/disp.c > index 70dce544984e..670535a68d3b 100644 > --- a/drivers/gpu/drm/nouveau/dispnv04/disp.c > +++ b/drivers/gpu/drm/nouveau/dispnv04/disp.c > @@ -56,7 +56,7 @@ nv04_display_create(struct drm_device *dev) > nouveau_display(dev)->fini = nv04_display_fini; > > /* Pre-nv50 doesn't support atomic, so don't expose the ioctls */ > - dev->driver->driver_features &= ~DRIVER_ATOMIC; > + dev->driver_features &= ~DRIVER_ATOMIC; > > nouveau_hw_save_vga_fonts(dev, 1); > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/2] intel: hide library symbols by default
On Thursday, 2018-09-13 21:11:18 +0100, Eric Engestrom wrote:
> On Thursday, 2018-09-13 12:43:53 -0700, Lucas De Marchi wrote:
> > On 9/13/18 1:03 AM, Eric Engestrom wrote:
> > > On Wednesday, 2018-09-12 14:05:34 -0700, Lucas De Marchi wrote:
> > > > Rely on -fvisibility=hidden to hide the symbols. This only applies to
> > > > drm_intel.so sice there's no point in extending this if it receives a
> > > > nack for some reason. For the same reason, only done on meson as well.
> > > >
> > > > drm_private can also be removed from other symbols. If this passes a
> > > > smoke test I'll add a patch on v2 doing so.
> > >
> > > Series is
> > > Reviewed-by: Eric Engestrom
> > >
> > > but yeah, without that 3rd patch to remove drm_private it isn't all that
> > > useful :P
> >
> > It actually is. It already closes the door for leaking internal symbols. the
> > drm_internal becomes a nop to be removed. I will include it in v2.
>
> Ha, you're right, my bad :)
> You could land it as it then, and remove drm_private in a follow up patch.
Also: remember that before removing drm_private, you'll need to change
all the build systems to -fvisibility=hidden.
>
> >
> > >
> > > Do you plan on converting the rest of libdrm if/when this gets accepted?
> > > It looks like you already got all the scripts ready to go ;)
> >
> > I will take a look on including them for v2 already. I just wish I
> > remembered how to use coccinelle for source code transformation like this.
> > The commands above work ok, but there's some manual work to adapt for things
> > like "int\nfoo() { }" vs "int foo() { }".
>
> Thanks!
>
> >
> > Lucas De Marchi
> >
> > >
> > > >
> > > > From git log archeology and mention in another thread we used to pass
> > > > -fvisibility=hidden, but reverted to the contrary due to bug in obscure
> > > > toolchain some years ago (see 0f8da82500ec542e269092c0718479e25eaff5f6).
> > > > I think it's time to revisit that decision: we have plenty of other
> > > > projects doing that nowadays without problem.
> > > >
> > > > Lucas De Marchi (2):
> > > >intel: annotate public functions
> > > >meson: intel: make symbols hidden by default
> > > >
> > > > intel/intel_bufmgr.c | 64 +-
> > > > intel/intel_bufmgr_fake.c | 10 +++---
> > > > intel/intel_bufmgr_gem.c | 73 +++
> > > > intel/intel_decode.c | 14
> > > > intel/meson.build | 4 ++-
> > > > libdrm_macros.h | 2 ++
> > > > 6 files changed, 85 insertions(+), 82 deletions(-)
> > > >
> > > > --
> > > > 2.17.1
> > > >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/2] intel: hide library symbols by default
On Thursday, 2018-09-13 12:43:53 -0700, Lucas De Marchi wrote:
> On 9/13/18 1:03 AM, Eric Engestrom wrote:
> > On Wednesday, 2018-09-12 14:05:34 -0700, Lucas De Marchi wrote:
> > > Rely on -fvisibility=hidden to hide the symbols. This only applies to
> > > drm_intel.so sice there's no point in extending this if it receives a
> > > nack for some reason. For the same reason, only done on meson as well.
> > >
> > > drm_private can also be removed from other symbols. If this passes a
> > > smoke test I'll add a patch on v2 doing so.
> >
> > Series is
> > Reviewed-by: Eric Engestrom
> >
> > but yeah, without that 3rd patch to remove drm_private it isn't all that
> > useful :P
>
> It actually is. It already closes the door for leaking internal symbols. the
> drm_internal becomes a nop to be removed. I will include it in v2.
Ha, you're right, my bad :)
You could land it as it then, and remove drm_private in a follow up patch.
>
> >
> > Do you plan on converting the rest of libdrm if/when this gets accepted?
> > It looks like you already got all the scripts ready to go ;)
>
> I will take a look on including them for v2 already. I just wish I
> remembered how to use coccinelle for source code transformation like this.
> The commands above work ok, but there's some manual work to adapt for things
> like "int\nfoo() { }" vs "int foo() { }".
Thanks!
>
> Lucas De Marchi
>
> >
> > >
> > > From git log archeology and mention in another thread we used to pass
> > > -fvisibility=hidden, but reverted to the contrary due to bug in obscure
> > > toolchain some years ago (see 0f8da82500ec542e269092c0718479e25eaff5f6).
> > > I think it's time to revisit that decision: we have plenty of other
> > > projects doing that nowadays without problem.
> > >
> > > Lucas De Marchi (2):
> > >intel: annotate public functions
> > >meson: intel: make symbols hidden by default
> > >
> > > intel/intel_bufmgr.c | 64 +-
> > > intel/intel_bufmgr_fake.c | 10 +++---
> > > intel/intel_bufmgr_gem.c | 73 +++
> > > intel/intel_decode.c | 14
> > > intel/meson.build | 4 ++-
> > > libdrm_macros.h | 2 ++
> > > 6 files changed, 85 insertions(+), 82 deletions(-)
> > >
> > > --
> > > 2.17.1
> > >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107898] "kfd: Failed to resume IOMMU for device 1002:15dd" on Raven Ridge
https://bugs.freedesktop.org/show_bug.cgi?id=107898 --- Comment #7 from Felix Kuehling --- Good timing. We were just given a laptop that has similar problems and found a partial workaround: Try adding "iommu=pt" to your kernel command line. This may at least get you through the KFD initialization, but there are likely more problems down the line. The problems are due to BIOS bugs. We're looking into more workarounds to ignore or patch incorrect information in the CRAT ACPI table that describes the compute devices for KFD. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105333] [gallium-nine] missing geometry after commit ac: replace ac_build_kill with ac_build_kill_if_false
https://bugs.freedesktop.org/show_bug.cgi?id=105333 --- Comment #13 from Axel Davy --- I inserted a printf inside the if condition that calls driQueryOptionb on this option in si_pipe.c and ran a nine app, and it did print, so the env var is not ignored. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3] drm: Differentiate the lack of an interface from invalid parameter
If the ioctl is not supported on a particular piece of HW/driver
combination, report ENOTSUP (aka EOPNOTSUPP) so that it can be easily
distinguished from both the lack of the ioctl and from a regular invalid
parameter.
v2: Across all the kms ioctls we had a mixture of reporting EINVAL,
ENODEV and a few ENOTSUPP (most where EINVAL) for a failed
drm_core_check_feature(). Update everybody to report ENOTSUPP.
v3: ENOTSUPP is an internal errno! It's value (524) does not correspond
to a POSIX errno, the one we want is ENOTSUP. However,
uapi/asm-generic/errno.h doesn't include ENOTSUP but man errno says
"ENOTSUP and EOPNOTSUPP have the same value on Linux,
but according to POSIX.1 these error values should be
distinct."
so use EOPNOTSUPP as its equivalent.
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
Cc: Ville Syrjälä
Reviewed-by: Daniel Vetter #v2
---
drivers/gpu/drm/drm_atomic_uapi.c | 2 +-
drivers/gpu/drm/drm_bufs.c| 32 +++
drivers/gpu/drm/drm_client.c | 2 +-
drivers/gpu/drm/drm_color_mgmt.c | 4 ++--
drivers/gpu/drm/drm_connector.c | 2 +-
drivers/gpu/drm/drm_context.c | 16
drivers/gpu/drm/drm_crtc.c| 4 ++--
drivers/gpu/drm/drm_encoder.c | 2 +-
drivers/gpu/drm/drm_framebuffer.c | 13 -
drivers/gpu/drm/drm_gem.c | 6 +++---
drivers/gpu/drm/drm_ioctl.c | 4 ++--
drivers/gpu/drm/drm_irq.c | 4 ++--
drivers/gpu/drm/drm_lease.c | 8
drivers/gpu/drm/drm_lock.c| 4 ++--
drivers/gpu/drm/drm_mode_config.c | 3 +--
drivers/gpu/drm/drm_mode_object.c | 4 ++--
drivers/gpu/drm/drm_pci.c | 4 ++--
drivers/gpu/drm/drm_plane.c | 10 +-
drivers/gpu/drm/drm_prime.c | 4 ++--
drivers/gpu/drm/drm_property.c| 8
drivers/gpu/drm/drm_scatter.c | 8
drivers/gpu/drm/drm_syncobj.c | 14 +++---
drivers/gpu/drm/drm_vblank.c | 4 ++--
23 files changed, 82 insertions(+), 80 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 26690a664ec6..d5b7f315098c 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -1251,7 +1251,7 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
/* disallow for drivers not supporting atomic: */
if (!drm_core_check_feature(dev, DRIVER_ATOMIC))
- return -EINVAL;
+ return -EOPNOTSUPP;
/* disallow for userspace that has not enabled atomic cap (even
* though this may be a bit overkill, since legacy userspace
diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
index ba8cfe65c65b..7412acaf3cde 100644
--- a/drivers/gpu/drm/drm_bufs.c
+++ b/drivers/gpu/drm/drm_bufs.c
@@ -398,7 +398,7 @@ int drm_legacy_addmap_ioctl(struct drm_device *dev, void
*data,
if (!drm_core_check_feature(dev, DRIVER_KMS_LEGACY_CONTEXT) &&
!drm_core_check_feature(dev, DRIVER_LEGACY))
- return -EINVAL;
+ return -EOPNOTSUPP;
err = drm_addmap_core(dev, map->offset, map->size, map->type,
map->flags, );
@@ -444,7 +444,7 @@ int drm_legacy_getmap_ioctl(struct drm_device *dev, void
*data,
if (!drm_core_check_feature(dev, DRIVER_KMS_LEGACY_CONTEXT) &&
!drm_core_check_feature(dev, DRIVER_LEGACY))
- return -EINVAL;
+ return -EOPNOTSUPP;
idx = map->offset;
if (idx < 0)
@@ -596,7 +596,7 @@ int drm_legacy_rmmap_ioctl(struct drm_device *dev, void
*data,
if (!drm_core_check_feature(dev, DRIVER_KMS_LEGACY_CONTEXT) &&
!drm_core_check_feature(dev, DRIVER_LEGACY))
- return -EINVAL;
+ return -EOPNOTSUPP;
mutex_lock(>struct_mutex);
list_for_each_entry(r_list, >maplist, head) {
@@ -860,7 +860,7 @@ int drm_legacy_addbufs_pci(struct drm_device *dev,
struct drm_buf **temp_buflist;
if (!drm_core_check_feature(dev, DRIVER_PCI_DMA))
- return -EINVAL;
+ return -EOPNOTSUPP;
if (!dma)
return -EINVAL;
@@ -1064,7 +1064,7 @@ static int drm_legacy_addbufs_sg(struct drm_device *dev,
struct drm_buf **temp_buflist;
if (!drm_core_check_feature(dev, DRIVER_SG))
- return -EINVAL;
+ return -EOPNOTSUPP;
if (!dma)
return -EINVAL;
@@ -1221,10 +1221,10 @@ int drm_legacy_addbufs(struct drm_device *dev, void
*data,
int ret;
if (!drm_core_check_feature(dev, DRIVER_LEGACY))
- return -EINVAL;
+ return -EOPNOTSUPP;
if (!drm_core_check_feature(dev, DRIVER_HAVE_DMA))
- return -EINVAL;
+ return -EOPNOTSUPP;
#if IS_ENABLED(CONFIG_AGP)
if (request->flags & _DRM_AGP_BUFFER)
@@ -1267,10 +1267,10 @@ int
[Bug 105333] [gallium-nine] missing geometry after commit ac: replace ac_build_kill with ac_build_kill_if_false
https://bugs.freedesktop.org/show_bug.cgi?id=105333 --- Comment #12 from Marek Olšák --- It's possible that nine ignores the env var. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/amdgpu: Use per-device driver_features to disable atomic
On Thu, Sep 13, 2018 at 12:40:20PM -0400, Alex Deucher wrote:
> On Thu, Sep 13, 2018 at 12:39 PM Michel Dänzer wrote:
> >
> > On 2018-09-13 6:31 p.m., Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > Disable atomic on a per-device basis instead of for all devices.
> > > Made possible by the new device.driver_features thing.
> > >
> > > Cc: Alex Deucher
> > > Cc: "Christian König"
> > > Cc: "David (ChunMing) Zhou"
> > > Cc: Harry Wentland
> > > Cc: Michel Dänzer
> > > Suggested-by: Michel Dänzer
> > > Signed-off-by: Ville Syrjälä
> > > ---
> > > drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 12
> > > 1 file changed, 4 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> > > index 6870909da926..8c1db96be070 100644
> > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> > > @@ -816,17 +816,13 @@ static int amdgpu_pci_probe(struct pci_dev *pdev,
> > > if (ret)
> > > return ret;
> > >
> > > - /* warn the user if they mix atomic and non-atomic capable GPUs */
> > > - if ((kms_driver.driver_features & DRIVER_ATOMIC) &&
> > > !supports_atomic)
> > > - DRM_ERROR("Mixing atomic and non-atomic capable GPUs!\n");
> > > - /* support atomic early so the atomic debugfs stuff gets created */
> > > - if (supports_atomic)
> > > - kms_driver.driver_features |= DRIVER_ATOMIC;
> > > -
> > > dev = drm_dev_alloc(_driver, >dev);
> > > if (IS_ERR(dev))
> > > return PTR_ERR(dev);
> > >
> > > + if (!supports_atomic)
> > > + dev->driver_features &= ~DRIVER_ATOMIC;
> > > +
> > > ret = pci_enable_device(pdev);
> > > if (ret)
> > > goto err_free;
> > > @@ -1078,7 +1074,7 @@ amdgpu_get_crtc_scanout_position(struct drm_device
> > > *dev, unsigned int pipe,
> > >
> > > static struct drm_driver kms_driver = {
> > > .driver_features =
> > > - DRIVER_USE_AGP |
> > > + DRIVER_USE_AGP | DRIVER_ATOMIC |
> > > DRIVER_HAVE_IRQ | DRIVER_IRQ_SHARED | DRIVER_GEM |
> > > DRIVER_PRIME | DRIVER_RENDER | DRIVER_MODESET | DRIVER_SYNCOBJ,
> > > .load = amdgpu_driver_load_kms,
> > >
> >
> > Thanks Ville for taking care of this!
> >
> > Reviewed-by: Michel Dänzer
> >
> > If Alex agrees, probably best to push this to drm-misc-next as well.
> >
>
> Reviewed-by: Alex Deucher
>
> Please go ahead and merge through drm-misc.
>
> Thanks!
You are welcome, and thanks for the r-bs. Pushed.
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm] intel: annotate the intel genx helpers as private
Quoting Lucas De Marchi (2018-09-13 19:23:49)
> +Chris
>
> On 9/13/18 12:19 AM, Chih-Wei Huang wrote:
> > Note this patch breaks drm_gralloc:
> >
> > FAILED:
> > out/target/product/x86_64/obj_x86/SHARED_LIBRARIES/libgralloc_drm_intermediates/LINKED/libgralloc_drm.so
> > /bin/bash -c "prebuilts/clang/host/linux-x86/clang-4053586/bin/clang++
> > -nostdlib -Wl,-soname,libgralloc_drm.so -Wl,--gc-sections -shared
> > out/target/product/x86_64/obj_x86/lib/crtbegin_so.o
> > out/target/product/x86_64/obj_x86/SHARED_LIBRARIES/libgralloc_drm_intermediates/gralloc_drm.o
> > out/target/product/x86_64/obj_x86/SHARED_LIBRARIES/libgralloc_drm_intermediates/gralloc_drm_kms.o
> > out/target/product/x86_64/obj_x86/SHARED_LIBRARIES/libgralloc_drm_intermediates/gralloc_drm_intel.o
> > out/target/product/x86_64/obj_x86/SHARED_LIBRARIES/libgralloc_drm_intermediates/gralloc_drm_radeon.o
> > out/target/product/x86_64/obj_x86/SHARED_LIBRARIES/libgralloc_drm_intermediates/gralloc_drm_nouveau.o
> > out/target/product/x86_64/obj_x86/SHARED_LIBRARIES/libgralloc_drm_intermediates/gralloc_drm_pipe.o
> > -Wl,--whole-archive -Wl,--no-whole-archive
> > out/target/product/x86_64/obj_x86/STATIC_LIBRARIES/libcompiler_rt-extras_intermediates/libcompiler_rt-extras.a
> >
> > out/target/product/x86_64/obj_x86/STATIC_LIBRARIES/libatomic_intermediates/libatomic.a
> > out/target/product/x86_64/obj_x86/STATIC_LIBRARIES/libgcc_intermediates/libgcc.a
> > -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now -Wl,--build-id=md5
> > -Wl,--warn-shared-textrel -Wl,--fatal-warnings -Wl,--gc-sections
> > -Wl,--hash-style=gnu -Wl,--no-undefined-version -m32 -target
> > i686-linux-android
> > -Bprebuilts/gcc/linux-x86/x86/x86_64-linux-android-4.9/x86_64-linux-android/bin
> > -Wl,--no-undefined out/target/product/x86_64/obj_x86/lib/libdrm.so
> > out/target/product/x86_64/obj_x86/lib/liblog.so
> > out/target/product/x86_64/obj_x86/lib/libcutils.so
> > out/target/product/x86_64/obj_x86/lib/libhardware_legacy.so
> > out/target/product/x86_64/obj_x86/lib/libdrm_intel.so
> > out/target/product/x86_64/obj_x86/lib/libdrm_radeon.so
> > out/target/product/x86_64/obj_x86/lib/libdrm_nouveau.so
> > out/target/product/x86_64/obj_x86/lib/libc++.so
> > out/target/product/x86_64/obj_x86/lib/libc.so
> > out/target/product/x86_64/obj_x86/lib/libm.so
> > out/target/product/x86_64/obj_x86/lib/libdl.so -o
> > out/target/product/x86_64/obj_x86/SHARED_LIBRARIES/libgralloc_drm_intermediates/LINKED/libgralloc_drm.so
> > out/target/product/x86_64/obj_x86/lib/crtend_so.o"
> > external/drm_gralloc/gralloc_drm_intel.c:631: error: undefined
> > reference to 'intel_is_genx'
> > external/drm_gralloc/gralloc_drm_intel.c:630: error: undefined
> > reference to 'intel_get_genx'
> > clang.real: error: linker command failed with exit code 1 (use -v to
> > see invocation)
> >
> >
> > That's because drm_gralloc use the IS_GEN9 macro
> > (and other IS_GEN{n} macros) directly.
> >
> > Since IS_GEN{n} are public APIs, I don't see
>
> IS_GEN() is *not* public API and should not be. It's an internal macro.
>
> DESTDIR=/tmp/inst ninja -C build install
> grep -r IS_GEN /tmp/inst/
> Binary file /tmp/inst/usr/local/lib64/libdrm_intel.so.1.0.0 matches
>
>[ same thing when using autotools ]
>
> Grepping https://android.googlesource.com/platform/external/drm_gralloc/
> I see IS_GEN* is being used, but I don't see where it's getting it from,
> unless it's using private headers... Let's see by grepping it:
>
> $ git grep intel_chipset
> gralloc_drm_intel.c:#include "intel_chipset.h" /* for platform detection
> macros */
>
>
> oh. You're a using a private header :(. How many places and libraries
> will we need to update to support different platforms? This is crazy.
> AFAICS it only uses that to get the max_stride for each platform... this
> info should be coming from somewhere else. Chris, any idea here?
Correct. They pulled libdrm into their library, they have the power to do
whatever they like. They should already be statically linking to
libdrm_intel.a and libdrm.a, so redefining drm_private to suit shouldn't
be an issue.
Just looking at the intel code suggests that drm_gralloc is but a toy.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm] intel: annotate the intel genx helpers as private
On Thursday, 2018-09-13 10:43:04 -0700, Rodrigo Vivi wrote:
> On Thu, Sep 13, 2018 at 09:45:47AM +0100, Eric Engestrom wrote:
> > On Thursday, 2018-09-13 15:19:00 +0800, Chih-Wei Huang wrote:
> > > Note this patch breaks drm_gralloc:
> > >
> > > FAILED:
> > > out/target/product/x86_64/obj_x86/SHARED_LIBRARIES/libgralloc_drm_intermediates/LINKED/libgralloc_drm.so
> > > /bin/bash -c "prebuilts/clang/host/linux-x86/clang-4053586/bin/clang++
> > > -nostdlib -Wl,-soname,libgralloc_drm.so -Wl,--gc-sections -shared
> > > out/target/product/x86_64/obj_x86/lib/crtbegin_so.o
> > > out/target/product/x86_64/obj_x86/SHARED_LIBRARIES/libgralloc_drm_intermediates/gralloc_drm.o
> > > out/target/product/x86_64/obj_x86/SHARED_LIBRARIES/libgralloc_drm_intermediates/gralloc_drm_kms.o
> > > out/target/product/x86_64/obj_x86/SHARED_LIBRARIES/libgralloc_drm_intermediates/gralloc_drm_intel.o
> > > out/target/product/x86_64/obj_x86/SHARED_LIBRARIES/libgralloc_drm_intermediates/gralloc_drm_radeon.o
> > > out/target/product/x86_64/obj_x86/SHARED_LIBRARIES/libgralloc_drm_intermediates/gralloc_drm_nouveau.o
> > > out/target/product/x86_64/obj_x86/SHARED_LIBRARIES/libgralloc_drm_intermediates/gralloc_drm_pipe.o
> > > -Wl,--whole-archive -Wl,--no-whole-archive
> > > out/target/product/x86_64/obj_x86/STATIC_LIBRARIES/libcompiler_rt-extras_intermediates/libcompiler_rt-extras.a
> > >
> > > out/target/product/x86_64/obj_x86/STATIC_LIBRARIES/libatomic_intermediates/libatomic.a
> > > out/target/product/x86_64/obj_x86/STATIC_LIBRARIES/libgcc_intermediates/libgcc.a
> > > -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now -Wl,--build-id=md5
> > > -Wl,--warn-shared-textrel -Wl,--fatal-warnings -Wl,--gc-sections
> > > -Wl,--hash-style=gnu -Wl,--no-undefined-version -m32 -target
> > > i686-linux-android
> > > -Bprebuilts/gcc/linux-x86/x86/x86_64-linux-android-4.9/x86_64-linux-android/bin
> > > -Wl,--no-undefined out/target/product/x86_64/obj_x86/lib/libdrm.so
> > > out/target/product/x86_64/obj_x86/lib/liblog.so
> > > out/target/product/x86_64/obj_x86/lib/libcutils.so
> > > out/target/product/x86_64/obj_x86/lib/libhardware_legacy.so
> > > out/target/product/x86_64/obj_x86/lib/libdrm_intel.so
> > > out/target/product/x86_64/obj_x86/lib/libdrm_radeon.so
> > > out/target/product/x86_64/obj_x86/lib/libdrm_nouveau.so
> > > out/target/product/x86_64/obj_x86/lib/libc++.so
> > > out/target/product/x86_64/obj_x86/lib/libc.so
> > > out/target/product/x86_64/obj_x86/lib/libm.so
> > > out/target/product/x86_64/obj_x86/lib/libdl.so -o
> > > out/target/product/x86_64/obj_x86/SHARED_LIBRARIES/libgralloc_drm_intermediates/LINKED/libgralloc_drm.so
> > > out/target/product/x86_64/obj_x86/lib/crtend_so.o"
> > > external/drm_gralloc/gralloc_drm_intel.c:631: error: undefined
> > > reference to 'intel_is_genx'
> > > external/drm_gralloc/gralloc_drm_intel.c:630: error: undefined
> > > reference to 'intel_get_genx'
> > > clang.real: error: linker command failed with exit code 1 (use -v to
> > > see invocation)
> > >
> > >
> > > That's because drm_gralloc use the IS_GEN9 macro
> > > (and other IS_GEN{n} macros) directly.
> >
> > Yeah, I thought some other stuff used the IS_GEN* macros ¯\_(ツ)_/¯
> >
> > I assume my other patch ("intel: use drm namespace for exported functions",
> > https://patchwork.kernel.org/patch/10590653/) works fine with drm_gralloc?
>
> What a castle of cards we have here
>
> We should pick one build system and support only this one build system.
Deprecating autotools in libdrm is a worthwhile discussion, but it
should probably be its own thread, otherwise most people will miss it.
As for Android.mk, it isn't going anywhere in the near future; it would
require AOSP to support meson in their build system, or someone to write
a compatibility layer. There's already a thread somewhere on mesa-dev@
about this.
>
> And the default build all should include tests. We shouldn't need a web
> remote CI to inform us that we could be breaking the build.
The CI runs the same tests you have locally ;)
>
> When I pushed the first series I build locally using autotools and meson
> and everything passed locally.
`meson test` wouldn't have passed, but there is a bug in the autotools
test scripts that Emil has identified that made them not actually run...
>
> But then gitlab CI warned that ninja buildir test fail...
>
> Than Daniel requested to use gitlab fork to make sure we pass CI
> and here I went:
>
> local ninja -C builddir test was happy and CI was green as we can see here:
> https://gitlab.freedesktop.org/vivijim/drm/commit/b2c25182f29ab010afbb11748c213c9a3e8a/pipelines?ref=master
>
> But then I just discovered that this broken autotools build!
This isn't a different build system, this is an external project that
uses libdrm (and depended on the macros that were rewritten).
>
> >
> > >
> > > Since IS_GEN{n} are public APIs, I don't see
> > > the rationale of this change.
> > > Unless you are going to privatize all IS_GEN{n}
[Bug 105333] [gallium-nine] missing geometry after commit ac: replace ac_build_kill with ac_build_kill_if_false
https://bugs.freedesktop.org/show_bug.cgi?id=105333 --- Comment #11 from Axel Davy --- (In reply to Marek Olšák from comment #9) > You can try to set glsl_correct_derivatives_after_discard=true, but I don't > know if that works with nine. Setting glsl_correct_derivatives_after_discard should work with nine. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm] intel: annotate the intel genx helpers as private
+Chris
On 9/13/18 12:19 AM, Chih-Wei Huang wrote:
Note this patch breaks drm_gralloc:
FAILED:
out/target/product/x86_64/obj_x86/SHARED_LIBRARIES/libgralloc_drm_intermediates/LINKED/libgralloc_drm.so
/bin/bash -c "prebuilts/clang/host/linux-x86/clang-4053586/bin/clang++
-nostdlib -Wl,-soname,libgralloc_drm.so -Wl,--gc-sections -shared
out/target/product/x86_64/obj_x86/lib/crtbegin_so.o
out/target/product/x86_64/obj_x86/SHARED_LIBRARIES/libgralloc_drm_intermediates/gralloc_drm.o
out/target/product/x86_64/obj_x86/SHARED_LIBRARIES/libgralloc_drm_intermediates/gralloc_drm_kms.o
out/target/product/x86_64/obj_x86/SHARED_LIBRARIES/libgralloc_drm_intermediates/gralloc_drm_intel.o
out/target/product/x86_64/obj_x86/SHARED_LIBRARIES/libgralloc_drm_intermediates/gralloc_drm_radeon.o
out/target/product/x86_64/obj_x86/SHARED_LIBRARIES/libgralloc_drm_intermediates/gralloc_drm_nouveau.o
out/target/product/x86_64/obj_x86/SHARED_LIBRARIES/libgralloc_drm_intermediates/gralloc_drm_pipe.o
-Wl,--whole-archive -Wl,--no-whole-archive
out/target/product/x86_64/obj_x86/STATIC_LIBRARIES/libcompiler_rt-extras_intermediates/libcompiler_rt-extras.a
out/target/product/x86_64/obj_x86/STATIC_LIBRARIES/libatomic_intermediates/libatomic.a
out/target/product/x86_64/obj_x86/STATIC_LIBRARIES/libgcc_intermediates/libgcc.a
-Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now -Wl,--build-id=md5
-Wl,--warn-shared-textrel -Wl,--fatal-warnings -Wl,--gc-sections
-Wl,--hash-style=gnu -Wl,--no-undefined-version -m32 -target
i686-linux-android
-Bprebuilts/gcc/linux-x86/x86/x86_64-linux-android-4.9/x86_64-linux-android/bin
-Wl,--no-undefined out/target/product/x86_64/obj_x86/lib/libdrm.so
out/target/product/x86_64/obj_x86/lib/liblog.so
out/target/product/x86_64/obj_x86/lib/libcutils.so
out/target/product/x86_64/obj_x86/lib/libhardware_legacy.so
out/target/product/x86_64/obj_x86/lib/libdrm_intel.so
out/target/product/x86_64/obj_x86/lib/libdrm_radeon.so
out/target/product/x86_64/obj_x86/lib/libdrm_nouveau.so
out/target/product/x86_64/obj_x86/lib/libc++.so
out/target/product/x86_64/obj_x86/lib/libc.so
out/target/product/x86_64/obj_x86/lib/libm.so
out/target/product/x86_64/obj_x86/lib/libdl.so -o
out/target/product/x86_64/obj_x86/SHARED_LIBRARIES/libgralloc_drm_intermediates/LINKED/libgralloc_drm.so
out/target/product/x86_64/obj_x86/lib/crtend_so.o"
external/drm_gralloc/gralloc_drm_intel.c:631: error: undefined
reference to 'intel_is_genx'
external/drm_gralloc/gralloc_drm_intel.c:630: error: undefined
reference to 'intel_get_genx'
clang.real: error: linker command failed with exit code 1 (use -v to
see invocation)
That's because drm_gralloc use the IS_GEN9 macro
(and other IS_GEN{n} macros) directly.
Since IS_GEN{n} are public APIs, I don't see
IS_GEN() is *not* public API and should not be. It's an internal macro.
DESTDIR=/tmp/inst ninja -C build install
grep -r IS_GEN /tmp/inst/
Binary file /tmp/inst/usr/local/lib64/libdrm_intel.so.1.0.0 matches
[ same thing when using autotools ]
Grepping https://android.googlesource.com/platform/external/drm_gralloc/
I see IS_GEN* is being used, but I don't see where it's getting it from,
unless it's using private headers... Let's see by grepping it:
$ git grep intel_chipset
gralloc_drm_intel.c:#include "intel_chipset.h" /* for platform detection
macros */
oh. You're a using a private header :(. How many places and libraries
will we need to update to support different platforms? This is crazy.
AFAICS it only uses that to get the max_stride for each platform... this
info should be coming from somewhere else. Chris, any idea here?
Lucas De Marchi
the rationale of this change.
Unless you are going to privatize all IS_GEN{n} macros.
(are you?)
2018-09-13 0:03 GMT+08:00 Rodrigo Vivi :
On Wed, Sep 12, 2018 at 08:50:54AM -0700, Rodrigo Vivi wrote:
From: Emil Velikov
They're used internally and never meant to be part of the API.
Add the drm_private notation, which should resolve that.
v2: (Rodrigo) Add missing include.
v3: (Rodrigo) Keep includes grouped per Eric suggestion.
Cc: Eric Engestrom
Cc: Lucas De Marchi
Cc: Chris Wilson
Cc: Rodrigo Vivi
Fixes: 4e81d4f9c9b ("intel: add generic functions to check PCI ID")
Signed-off-by: Emil Velikov
Acked-by: Lucas De Marchi
Signed-off-by: Rodrigo Vivi
Reviewed-by: Eric Engestrom
And pushed...
thanks for patch, ack and review ;)
---
intel/intel_chipset.c | 4 ++--
intel/intel_chipset.h | 5 +++--
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/intel/intel_chipset.c b/intel/intel_chipset.c
index d5c33cc5..5aa4a2f2 100644
--- a/intel/intel_chipset.c
+++ b/intel/intel_chipset.c
@@ -44,7 +44,7 @@ static const struct pci_device {
INTEL_SKL_IDS(9),
};
-bool intel_is_genx(unsigned int devid, int gen)
+drm_private bool intel_is_genx(unsigned int devid, int gen)
{
const struct pci_device *p,
*pend = pciids + sizeof(pciids) / sizeof(pciids[0]);
@@ -66,7 +66,7 @@ bool intel_is_genx(unsigned int
Re: [PATCH -fixes 5/5] drm/vmwgfx: Fix a buffer object eviction regression
On 09/13/2018 07:38 PM, Matthew Wilcox wrote: On Thu, Sep 13, 2018 at 06:52:43PM +0200, Thomas Hellstrom wrote: On 09/13/2018 05:28 PM, Matthew Wilcox wrote: On Thu, Sep 13, 2018 at 04:56:53PM +0200, Thomas Hellstrom wrote: On 09/13/2018 04:10 PM, Matthew Wilcox wrote: I think this could be better though ... if ida_alloc() ever starts returning a different errno in the future, you'll hit the same problem, right? So how about this ... id = ida_alloc_max(>gmr_ida, gman->max_gmr_ids - 1, GFP_KERNEL); + if (id == -ENOMEM) + return -ENOMEM; + if (id < 0) + return 0; spin_lock(>lock); But I wonder ... why is -ENOMEM seen as a fatal error? If you free up some memory, you'll free up an ID, so the next time around you should be able to allocate an ID. So shouldn't this function just have been doing this all along? id = ida_alloc_max(>gmr_ida, gman->max_gmr_ids - 1, GFP_KERNEL); + if (id < 0) + return 0; Non-fatal errors are errors that can be remedied by GPU buffer eviction, and buffer eviction will free up IDA space, so basically we need to target only the error code that indicates we've run out of IDA space. Yes, but the following situation can happen: - Allocate 1024 IDs - Run very low on memory - Allocating ID 1025 will fail (very very unlikely) - ida_alloc_max() returns -ENOMEM In this situation, we want ttm_mem_evict_first() to be called which will free up one of the 1024 existing IDs and then we can allocate that ID for our new node. I'm assuming we're analysing the behaviour of ttm_bo_mem_force_space() here. Well, that's true, but that situation depends I guess very much on the radix tree implementation of IDA? The specific number 1024 depends on the current implementation, but generally speaking at some point, the IDA has to allocate memory to store one extra ID. Because the IDA cannot allocate memory when freeing an ID, there is no more compact representation of the allocated IDs smaller than a bitmap. Also I would expect the eviction paths to try to allocate more memory here and there, so to me the preferred option when -ENOMEM happens, is really to back off as soon as possible to avoid interfering with shrinker work going on etc. I would be surprised if freeing resources needs memory to be allocated. That's not supposed to happen; the filesystems go to great lengths to pre-allocate enough memory that they can always write at least one dirty page back to storage without allocating any memory, for example. Maybe the DRM subsystem is different; I'm not an expert in your subsystem. It's different. In particular when evicting a large buffer from VRAM (which is on-card memory) to system memory, the subsystem may allocate a huge amount of memory. But this particular case is not evicting from VRAM (although it may lead to it). My point was that your solution (detect the one error which should be deemed as non-fatal) was not as robust as its inverse (detect the one error which the previous code deemed as fatal). But I now believe no error from the IDA should be seen as fatal. If you insist, I can test on -ENOMEM instead of -ENOSPC to mimic the pre-change behaviour. We should really focus on the IDA api changes here, and defer changing -ENOMEM to non-fatal to a follow-up patch if needed. I'd be comfortable with that solution for now. OK, I'll respin and check for -ENOMEM instead. Thanks, Thomas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm] intel: annotate the intel genx helpers as private
On Thu, Sep 13, 2018 at 09:45:47AM +0100, Eric Engestrom wrote:
> On Thursday, 2018-09-13 15:19:00 +0800, Chih-Wei Huang wrote:
> > Note this patch breaks drm_gralloc:
> >
> > FAILED:
> > out/target/product/x86_64/obj_x86/SHARED_LIBRARIES/libgralloc_drm_intermediates/LINKED/libgralloc_drm.so
> > /bin/bash -c "prebuilts/clang/host/linux-x86/clang-4053586/bin/clang++
> > -nostdlib -Wl,-soname,libgralloc_drm.so -Wl,--gc-sections -shared
> > out/target/product/x86_64/obj_x86/lib/crtbegin_so.o
> > out/target/product/x86_64/obj_x86/SHARED_LIBRARIES/libgralloc_drm_intermediates/gralloc_drm.o
> > out/target/product/x86_64/obj_x86/SHARED_LIBRARIES/libgralloc_drm_intermediates/gralloc_drm_kms.o
> > out/target/product/x86_64/obj_x86/SHARED_LIBRARIES/libgralloc_drm_intermediates/gralloc_drm_intel.o
> > out/target/product/x86_64/obj_x86/SHARED_LIBRARIES/libgralloc_drm_intermediates/gralloc_drm_radeon.o
> > out/target/product/x86_64/obj_x86/SHARED_LIBRARIES/libgralloc_drm_intermediates/gralloc_drm_nouveau.o
> > out/target/product/x86_64/obj_x86/SHARED_LIBRARIES/libgralloc_drm_intermediates/gralloc_drm_pipe.o
> > -Wl,--whole-archive -Wl,--no-whole-archive
> > out/target/product/x86_64/obj_x86/STATIC_LIBRARIES/libcompiler_rt-extras_intermediates/libcompiler_rt-extras.a
> >
> > out/target/product/x86_64/obj_x86/STATIC_LIBRARIES/libatomic_intermediates/libatomic.a
> > out/target/product/x86_64/obj_x86/STATIC_LIBRARIES/libgcc_intermediates/libgcc.a
> > -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now -Wl,--build-id=md5
> > -Wl,--warn-shared-textrel -Wl,--fatal-warnings -Wl,--gc-sections
> > -Wl,--hash-style=gnu -Wl,--no-undefined-version -m32 -target
> > i686-linux-android
> > -Bprebuilts/gcc/linux-x86/x86/x86_64-linux-android-4.9/x86_64-linux-android/bin
> > -Wl,--no-undefined out/target/product/x86_64/obj_x86/lib/libdrm.so
> > out/target/product/x86_64/obj_x86/lib/liblog.so
> > out/target/product/x86_64/obj_x86/lib/libcutils.so
> > out/target/product/x86_64/obj_x86/lib/libhardware_legacy.so
> > out/target/product/x86_64/obj_x86/lib/libdrm_intel.so
> > out/target/product/x86_64/obj_x86/lib/libdrm_radeon.so
> > out/target/product/x86_64/obj_x86/lib/libdrm_nouveau.so
> > out/target/product/x86_64/obj_x86/lib/libc++.so
> > out/target/product/x86_64/obj_x86/lib/libc.so
> > out/target/product/x86_64/obj_x86/lib/libm.so
> > out/target/product/x86_64/obj_x86/lib/libdl.so -o
> > out/target/product/x86_64/obj_x86/SHARED_LIBRARIES/libgralloc_drm_intermediates/LINKED/libgralloc_drm.so
> > out/target/product/x86_64/obj_x86/lib/crtend_so.o"
> > external/drm_gralloc/gralloc_drm_intel.c:631: error: undefined
> > reference to 'intel_is_genx'
> > external/drm_gralloc/gralloc_drm_intel.c:630: error: undefined
> > reference to 'intel_get_genx'
> > clang.real: error: linker command failed with exit code 1 (use -v to
> > see invocation)
> >
> >
> > That's because drm_gralloc use the IS_GEN9 macro
> > (and other IS_GEN{n} macros) directly.
>
> Yeah, I thought some other stuff used the IS_GEN* macros ¯\_(ツ)_/¯
>
> I assume my other patch ("intel: use drm namespace for exported functions",
> https://patchwork.kernel.org/patch/10590653/) works fine with drm_gralloc?
What a castle of cards we have here
We should pick one build system and support only this one build system.
And the default build all should include tests. We shouldn't need a web
remote CI to inform us that we could be breaking the build.
When I pushed the first series I build locally using autotools and meson
and everything passed locally.
But then gitlab CI warned that ninja buildir test fail...
Than Daniel requested to use gitlab fork to make sure we pass CI
and here I went:
local ninja -C builddir test was happy and CI was green as we can see here:
https://gitlab.freedesktop.org/vivijim/drm/commit/b2c25182f29ab010afbb11748c213c9a3e8a/pipelines?ref=master
But then I just discovered that this broken autotools build!
>
> >
> > Since IS_GEN{n} are public APIs, I don't see
> > the rationale of this change.
> > Unless you are going to privatize all IS_GEN{n} macros.
> > (are you?)
> >
> >
> > 2018-09-13 0:03 GMT+08:00 Rodrigo Vivi :
> > > On Wed, Sep 12, 2018 at 08:50:54AM -0700, Rodrigo Vivi wrote:
> > >> From: Emil Velikov
> > >>
> > >> They're used internally and never meant to be part of the API.
> > >> Add the drm_private notation, which should resolve that.
> > >>
> > >> v2: (Rodrigo) Add missing include.
> > >> v3: (Rodrigo) Keep includes grouped per Eric suggestion.
> > >>
> > >> Cc: Eric Engestrom
> > >> Cc: Lucas De Marchi
> > >> Cc: Chris Wilson
> > >> Cc: Rodrigo Vivi
> > >> Fixes: 4e81d4f9c9b ("intel: add generic functions to check PCI ID")
> > >> Signed-off-by: Emil Velikov
> > >> Acked-by: Lucas De Marchi
> > >> Signed-off-by: Rodrigo Vivi
> > >> Reviewed-by: Eric Engestrom
> > >
> > > And pushed...
> > > thanks for patch, ack and review ;)
> > >
> > >> ---
> > >> intel/intel_chipset.c | 4 ++--
> > >> intel/intel_chipset.h | 5 +++--
>
Re: [PATCH v2 6/8] drm/imx: support handling bridge timings bus flags
On 13.09.2018 01:38, Philipp Zabel wrote: > On Wed, 2018-09-12 at 11:32 -0700, Stefan Agner wrote: >> A bridge might require specific settings for the pixel data on >> the bus. > > On which bus? The bridge has input and output. > >> Copy the bus flags from the bridge timings if a bridge >> is in use. >> >> Signed-off-by: Stefan Agner >> --- >> drivers/gpu/drm/imx/parallel-display.c | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/drivers/gpu/drm/imx/parallel-display.c >> b/drivers/gpu/drm/imx/parallel-display.c >> index aefd04e18f93..7798a0621df7 100644 >> --- a/drivers/gpu/drm/imx/parallel-display.c >> +++ b/drivers/gpu/drm/imx/parallel-display.c >> @@ -239,6 +239,9 @@ static int imx_pd_bind(struct device *dev, struct device >> *master, void *data) >> if (ret && ret != -ENODEV) >> return ret; >> >> +if (imxpd->bridge && imxpd->bridge->timings) >> +imxpd->bus_flags = imxpd->bridge->timings->input_bus_flags; > > Oh, ok. I'd also specify input bus in the commit message. > Good point, will change in v3 to: "A bridge might require specific settings for the pixel data on its input bus. Those are specified through optional bus timings. Copy the bridges input bus flags as to the imxpd bus flags." -- Stefan >> + >> imxpd->dev = dev; >> >> ret = imx_pd_register(drm, imxpd); > > regards > Philipp ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 02/24] drivers/video/fbdev: use ioremap_wc/wt() instead of __ioremap()
On 09/12/2018 05:58 PM, Christophe Leroy wrote: > _PAGE_NO_CACHE is a platform specific flag. In addition, this flag > is misleading because one would think it requests a noncached page > whereas a noncached page is _PAGE_NO_CACHE | _PAGE_GUARDED > > _PAGE_NO_CACHE alone means write combined noncached page, so lets > use ioremap_wc() instead. > > _PAGE_WRITETHRU is also platform specific flag. Use ioremap_wt() > instead. > > Signed-off-by: Christophe Leroy After reading patch #1 this one LGTM. Acked-by: Bartlomiej Zolnierkiewicz > --- > drivers/video/fbdev/chipsfb.c| 3 +-- > drivers/video/fbdev/controlfb.c | 5 + > drivers/video/fbdev/platinumfb.c | 5 + > drivers/video/fbdev/valkyriefb.c | 12 ++-- > 4 files changed, 9 insertions(+), 16 deletions(-) Best regards, -- Bartlomiej Zolnierkiewicz Samsung R Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH -fixes 5/5] drm/vmwgfx: Fix a buffer object eviction regression
On 09/13/2018 05:28 PM, Matthew Wilcox wrote:
On Thu, Sep 13, 2018 at 04:56:53PM +0200, Thomas Hellstrom wrote:
Hi,
On 09/13/2018 04:10 PM, Matthew Wilcox wrote:
On Thu, Sep 13, 2018 at 01:58:37PM +0200, Thomas Hellstrom wrote:
Commit 4eb085e42fde ("drm/vmwgfx: Convert to new IDA API") indroduced
an incorrect return value from the function vmw_gmrid_man_get_node(),
when we run out if integer ids. Instead of returning 0 (meaning
non-fatal error) we forward the ida_simple_get error code -ENOSPC.
This causes TTM not to retry allocation after buffer eviction and
instead return -ENOSPC to user-space.
Fix this by returning 0 when ida_simple_get() returns -ENOSPC.
Thanks. I got confused by the convoluted code that was there before ;-(
I think this could be better though ... if ida_alloc() ever starts
returning a different errno in the future, you'll hit the same problem,
right? So how about this ...
id = ida_alloc_max(>gmr_ida, gman->max_gmr_ids - 1, GFP_KERNEL);
+ if (id == -ENOMEM)
+ return -ENOMEM;
+ if (id < 0)
+ return 0;
spin_lock(>lock);
But I wonder ... why is -ENOMEM seen as a fatal error? If you free up
some memory, you'll free up an ID, so the next time around you should
be able to allocate an ID. So shouldn't this function just have
been doing this all along?
id = ida_alloc_max(>gmr_ida, gman->max_gmr_ids - 1, GFP_KERNEL);
+ if (id < 0)
+ return 0;
Non-fatal errors are errors that can be remedied by GPU buffer eviction, and
buffer eviction will free up IDA space, so basically we need to target only
the error code that indicates we've run out of IDA space.
Yes, but the following situation can happen:
- Allocate 1024 IDs
- Run very low on memory
- Allocating ID 1025 will fail (very very unlikely)
- ida_alloc_max() returns -ENOMEM
In this situation, we want ttm_mem_evict_first() to be called which will
free up one of the 1024 existing IDs and then we can allocate that ID for
our new node.
I'm assuming we're analysing the behaviour of ttm_bo_mem_force_space()
here.
Well, that's true, but that situation depends I guess very much on the
radix tree implementation of IDA? Also I would expect the eviction paths
to try to allocate more memory here and there, so to me the preferred
option when -ENOMEM happens, is really to back off as soon as possible
to avoid interfering with shrinker work going on etc.
If we're worried that ida_alloc_max() will change return value, I guess we
will have to increase the IDA space and detect the error ourselves: error
if (id >= gman->max_gmr_ids)
My point was that your solution (detect the one error which should be
deemed as non-fatal) was not as robust as its inverse (detect the one
error which the previous code deemed as fatal). But I now believe no
error from the IDA should be seen as fatal.
If you insist, I can test on -ENOMEM instead of -ENOSPC to mimic the
pre-change behaviour. We should really focus on the IDA api changes
here, and defer changing -ENOMEM to non-fatal to a follow-up patch if
needed.
Thanks,
Thomas
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm/imx: Crash in drm_mode_config_cleanup
Hi Philipp, On 13.09.2018 01:36, Philipp Zabel wrote: > Hi Stefan, > > thank you for the report. I think what happens is the following: Thanks for looking into it! > > On Wed, 2018-09-12 at 15:26 -0700, Stefan Agner wrote: >> Hi, >> >> While working on Apalis iMX6 with four displays, I encountered the >> following crash: >> > [...] >> [3.781163] imx-drm display-subsystem: bound 12.hdmi (ops >> dw_hdmi_imx_ops) >> [3.788441] imx-drm display-subsystem: binding ldb (ops imx_ldb_ops) >> [3.794902] imx_ldb_bind, imx_ldb ec0da010 > > component_bind calls devres_open_group right before component->ops->bind > > The devmem_kzalloc'ed imx_ldb_channel that contains the encoder is > allocated in this devres group. > >> [3.799818] drm_encoder_init, encoder ec0da388 >> [3.804363] drm_encoder_init, ret 0 > > drm_encoder_init adds the encoder in imx_ldb to the > mode_config.encoder_list. > >> [3.807908] imx_ldb_register, encoder ec0da388 >> [3.812432] imx_ldb_register, ret 0 >> [3.815951] imx_ldb_bind encoder LVDS-46, ec0da388 ->func c0e6371c >> [3.87] imx_ldb_bind, done >> [3.825331] imx-drm display-subsystem: bound ldb (ops imx_ldb_ops) >> [3.831614] imx-drm display-subsystem: binding >> parallel-display-controller1 (ops imx_pd_ops) >> [3.840285] drm_encoder_init, encoder ec8a2b78 >> [3.844931] imx-drm display-subsystem: Linked as a consumer to panel >> [3.851472] imx-drm display-subsystem: bound parallel-display-controller1 >> (ops imx_pd_ops) >> [3.859785] imx-drm display-subsystem: binding >> parallel-display-controller0 (ops imx_pd_ops) >> [3.868561] imx-drm display-subsystem: failed to bind >> parallel-display-controller0 (ops imx_pd_ops): -517 >> [3.878225] imx-drm display-subsystem: Dropping the link to panel >> [3.884679] imx_ldb_unbind >> [3.887421] imx_ldb_unbind, encoder LVDS-46, ec0da388 ->func c0e6371c >> [3.893950] imx_ldb_unbind, encoder (null), ec0da838 ->func 0 >> [3.899723] imx_ldb_unbind, done > > component_unbind calls devres_release_group after component->ops- >>unbind, freeing imx_ldb and with it the encoder that is still in the > mode_config.encoder_list Oh I see, I did not realize that component_unbind releases devres... > >> [3.908345] imx_drm_bind, component_bind_all, ret -517 >> [3.913638] drm_mode_config_cleanup, encoder TMDS-44, ec861894 ->funcs >> c0e63a18 >> [3.921260] drm_mode_config_cleanup, calling encoder->funcs->destroy! >> [3.927897] drm_encoder_cleanup, encoder ec861894 >> [3.932717] drm_mode_config_cleanup, encoder (null), ec0da388 ->funcs 0 > > Use after free. > That all makes sense now... >> [3.939356] drm_mode_config_cleanup, calling encoder->funcs->destroy! >> [3.946050] Unable to handle kernel NULL pointer dereference at virtual >> address 0004 > [...] >> The Apalis iMX6 device tree I work with uses a dumb VGA bridge and a LVDS >> display directly specified in the ldb node. In the case above I did not >> compile in the dumb VGA bridge driver, that is the reason why binding >> parallel-display-controller0 fails. > > I suppose this means that component drivers must not allocate the > encoder in the component devres group during bind. Not only their own > failure, but any other component's failure can cause component_unbind to > be called in the cleanup path of component_bind_all, freeing the memory > before drm_mode_config_cleanup is called. > Indeed, moving allocation into driver bind fixes the crash! I wonder, how does devres knows that imx_ldb got allocated in probe and does not free on unbind? I guess that is the group mechanism which makes sure of that? ldb would not the only driver affected, also drivers/gpu/drm/imx/parallel-display.c allocates encoders in component bind, there are probably more. Actually, when thinking more about it, if we would have a way to call framework cleanup functions (drm_mode_config_cleanup() in this case) between the bind and unbind loops in component_bind_all(), we would not have that problem. [adding Russel, since he introduced the component infrastructure] >> The LVDS encoder (0xec1a0388 in that case) is somehow already cleaned up >> when calling drm_mode_config_cleanup(), which leads to a null pointer >> deference when trying to call destroy. >> >> I was unable to figure out why the DRM encoder in the second >> drm_mode_config_cleanup() call is already zeroed out. The component >> framework calls imx_ldb_unbind() first, but that should not free >> up the encoder afaict. Any idea? >> >> I was also wondering in the deferred probing case, functions like >> imx_ldb_bind() call devm_kzalloc on every try. Since the underlying >> device is not removed, doesn't this leads to multiple active allocations? > > See above. To me it looks like we have to allocate imx_ldb in probe and > deal with possibly partially preinitialzied structure when bind is > called a second time. > Yeah with the
[Bug 105333] [gallium-nine] missing geometry after commit ac: replace ac_build_kill with ac_build_kill_if_false
https://bugs.freedesktop.org/show_bug.cgi?id=105333 --- Comment #10 from had...@gmx.de --- (In reply to Marek Olšák from comment #9) > You can try to set glsl_correct_derivatives_after_discard=true, but I don't > know if that works with nine. I tried with the env variable set with latest git checkout of llvm and mesa and the bug is still there. Is there anything else i could try, like getting some logs or so? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 200621] Freezing with amdgpu driver
https://bugzilla.kernel.org/show_bug.cgi?id=200621 --- Comment #19 from Richard Smith (smit...@gmx.co.uk) --- Additional: I should probably have mentioned that I am running Debian testing. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/msm/dpu: Remove an unused enum
enum dpu_ad isn't used and can be safely removed.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h
index 62cf127b16d4..68c54d2c9677 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h
@@ -232,12 +232,6 @@ enum dpu_wb {
WB_MAX
};
-enum dpu_ad {
- AD_0 = 0x1,
- AD_1,
- AD_MAX
-};
-
enum dpu_cwb {
CWB_0 = 0x1,
CWB_1,
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 200621] Freezing with amdgpu driver
https://bugzilla.kernel.org/show_bug.cgi?id=200621 --- Comment #18 from Richard Smith (smit...@gmx.co.uk) --- Created attachment 278497 --> https://bugzilla.kernel.org/attachment.cgi?id=278497=edit dmesg The dmesg output for the last time it happened. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 200621] Freezing with amdgpu driver
https://bugzilla.kernel.org/show_bug.cgi?id=200621 Richard Smith (smit...@gmx.co.uk) changed: What|Removed |Added CC||smit...@gmx.co.uk --- Comment #17 from Richard Smith (smit...@gmx.co.uk) --- I'd like to report that I, too, am experiencing the exact same issue. I've found that a workaround is to use the boot parameter "amdgpu.dpm=0", but the downside is that your GPU fan will be running constantly. My monitor, too, is connected via display port to a Vega 64 graphics card. Steps to reproduce: --- * Simply manually power the monitor off and back on again. Alternatively: * Lock desktop, wait for monitor to sleep. Then, move the mouse or press any keyboard key and observe that the screen remains black until you reboot. Both of these reproduce the issue 100% of the time. Kernels with this issue: 4.18.6 (my current kernel) 4.17.17 Last kernel without this issue: --- 4.17.14 Other observations: --- For me, the system doesn't completely lock up. Once the issue has occurred, I can switch to a TTY with my keyboard (though screen remains blank) and trigger a reboot via CTRL + ALT + DEL. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/amdgpu: Use per-device driver_features to disable atomic
On Thu, Sep 13, 2018 at 12:39 PM Michel Dänzer wrote:
>
> On 2018-09-13 6:31 p.m., Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Disable atomic on a per-device basis instead of for all devices.
> > Made possible by the new device.driver_features thing.
> >
> > Cc: Alex Deucher
> > Cc: "Christian König"
> > Cc: "David (ChunMing) Zhou"
> > Cc: Harry Wentland
> > Cc: Michel Dänzer
> > Suggested-by: Michel Dänzer
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 12
> > 1 file changed, 4 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> > index 6870909da926..8c1db96be070 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> > @@ -816,17 +816,13 @@ static int amdgpu_pci_probe(struct pci_dev *pdev,
> > if (ret)
> > return ret;
> >
> > - /* warn the user if they mix atomic and non-atomic capable GPUs */
> > - if ((kms_driver.driver_features & DRIVER_ATOMIC) && !supports_atomic)
> > - DRM_ERROR("Mixing atomic and non-atomic capable GPUs!\n");
> > - /* support atomic early so the atomic debugfs stuff gets created */
> > - if (supports_atomic)
> > - kms_driver.driver_features |= DRIVER_ATOMIC;
> > -
> > dev = drm_dev_alloc(_driver, >dev);
> > if (IS_ERR(dev))
> > return PTR_ERR(dev);
> >
> > + if (!supports_atomic)
> > + dev->driver_features &= ~DRIVER_ATOMIC;
> > +
> > ret = pci_enable_device(pdev);
> > if (ret)
> > goto err_free;
> > @@ -1078,7 +1074,7 @@ amdgpu_get_crtc_scanout_position(struct drm_device
> > *dev, unsigned int pipe,
> >
> > static struct drm_driver kms_driver = {
> > .driver_features =
> > - DRIVER_USE_AGP |
> > + DRIVER_USE_AGP | DRIVER_ATOMIC |
> > DRIVER_HAVE_IRQ | DRIVER_IRQ_SHARED | DRIVER_GEM |
> > DRIVER_PRIME | DRIVER_RENDER | DRIVER_MODESET | DRIVER_SYNCOBJ,
> > .load = amdgpu_driver_load_kms,
> >
>
> Thanks Ville for taking care of this!
>
> Reviewed-by: Michel Dänzer
>
> If Alex agrees, probably best to push this to drm-misc-next as well.
>
Reviewed-by: Alex Deucher
Please go ahead and merge through drm-misc.
Thanks!
Alex
>
> --
> Earthling Michel Dänzer | http://www.amd.com
> Libre software enthusiast | Mesa and X developer
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/amdgpu: Use per-device driver_features to disable atomic
On 2018-09-13 6:31 p.m., Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Disable atomic on a per-device basis instead of for all devices.
> Made possible by the new device.driver_features thing.
>
> Cc: Alex Deucher
> Cc: "Christian König"
> Cc: "David (ChunMing) Zhou"
> Cc: Harry Wentland
> Cc: Michel Dänzer
> Suggested-by: Michel Dänzer
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 12
> 1 file changed, 4 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> index 6870909da926..8c1db96be070 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> @@ -816,17 +816,13 @@ static int amdgpu_pci_probe(struct pci_dev *pdev,
> if (ret)
> return ret;
>
> - /* warn the user if they mix atomic and non-atomic capable GPUs */
> - if ((kms_driver.driver_features & DRIVER_ATOMIC) && !supports_atomic)
> - DRM_ERROR("Mixing atomic and non-atomic capable GPUs!\n");
> - /* support atomic early so the atomic debugfs stuff gets created */
> - if (supports_atomic)
> - kms_driver.driver_features |= DRIVER_ATOMIC;
> -
> dev = drm_dev_alloc(_driver, >dev);
> if (IS_ERR(dev))
> return PTR_ERR(dev);
>
> + if (!supports_atomic)
> + dev->driver_features &= ~DRIVER_ATOMIC;
> +
> ret = pci_enable_device(pdev);
> if (ret)
> goto err_free;
> @@ -1078,7 +1074,7 @@ amdgpu_get_crtc_scanout_position(struct drm_device
> *dev, unsigned int pipe,
>
> static struct drm_driver kms_driver = {
> .driver_features =
> - DRIVER_USE_AGP |
> + DRIVER_USE_AGP | DRIVER_ATOMIC |
> DRIVER_HAVE_IRQ | DRIVER_IRQ_SHARED | DRIVER_GEM |
> DRIVER_PRIME | DRIVER_RENDER | DRIVER_MODESET | DRIVER_SYNCOBJ,
> .load = amdgpu_driver_load_kms,
>
Thanks Ville for taking care of this!
Reviewed-by: Michel Dänzer
If Alex agrees, probably best to push this to drm-misc-next as well.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/amdgpu: Use per-device driver_features to disable atomic
From: Ville Syrjälä
Disable atomic on a per-device basis instead of for all devices.
Made possible by the new device.driver_features thing.
Cc: Alex Deucher
Cc: "Christian König"
Cc: "David (ChunMing) Zhou"
Cc: Harry Wentland
Cc: Michel Dänzer
Suggested-by: Michel Dänzer
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 6870909da926..8c1db96be070 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -816,17 +816,13 @@ static int amdgpu_pci_probe(struct pci_dev *pdev,
if (ret)
return ret;
- /* warn the user if they mix atomic and non-atomic capable GPUs */
- if ((kms_driver.driver_features & DRIVER_ATOMIC) && !supports_atomic)
- DRM_ERROR("Mixing atomic and non-atomic capable GPUs!\n");
- /* support atomic early so the atomic debugfs stuff gets created */
- if (supports_atomic)
- kms_driver.driver_features |= DRIVER_ATOMIC;
-
dev = drm_dev_alloc(_driver, >dev);
if (IS_ERR(dev))
return PTR_ERR(dev);
+ if (!supports_atomic)
+ dev->driver_features &= ~DRIVER_ATOMIC;
+
ret = pci_enable_device(pdev);
if (ret)
goto err_free;
@@ -1078,7 +1074,7 @@ amdgpu_get_crtc_scanout_position(struct drm_device *dev,
unsigned int pipe,
static struct drm_driver kms_driver = {
.driver_features =
- DRIVER_USE_AGP |
+ DRIVER_USE_AGP | DRIVER_ATOMIC |
DRIVER_HAVE_IRQ | DRIVER_IRQ_SHARED | DRIVER_GEM |
DRIVER_PRIME | DRIVER_RENDER | DRIVER_MODESET | DRIVER_SYNCOBJ,
.load = amdgpu_driver_load_kms,
--
2.16.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/nouveau: Disable atomic support on a per-device basis
From: Ville Syrjälä We now have per-device driver_features, so let's use that to disable atomic only for pre-nv50. Cc: Ben Skeggs Cc: Lyude Paul Cc: nouv...@lists.freedesktop.org Cc: Daniel Vetter Reviewed-by: Daniel Vetter Suggested-by: Daniel Vetter Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/nouveau/dispnv04/disp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/dispnv04/disp.c b/drivers/gpu/drm/nouveau/dispnv04/disp.c index 70dce544984e..670535a68d3b 100644 --- a/drivers/gpu/drm/nouveau/dispnv04/disp.c +++ b/drivers/gpu/drm/nouveau/dispnv04/disp.c @@ -56,7 +56,7 @@ nv04_display_create(struct drm_device *dev) nouveau_display(dev)->fini = nv04_display_fini; /* Pre-nv50 doesn't support atomic, so don't expose the ioctls */ - dev->driver->driver_features &= ~DRIVER_ATOMIC; + dev->driver_features &= ~DRIVER_ATOMIC; nouveau_hw_save_vga_fonts(dev, 1); -- 2.16.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 1/2] drm: Introduce per-device driver_features
On Thu, Sep 13, 2018 at 06:06:01PM +0300, Ville Syrjälä wrote: > On Thu, Sep 13, 2018 at 04:52:34PM +0200, Michel Dänzer wrote: > > On 2018-09-13 4:29 p.m., Ville Syrjälä wrote: > > > On Thu, Sep 13, 2018 at 03:50:01PM +0200, Daniel Vetter wrote: > > >> On Thu, Sep 13, 2018 at 04:16:21PM +0300, Ville Syrjala wrote: > > >>> From: Ville Syrjälä > > >>> > > >>> We wish to control certain driver_features flags on a per-device basis > > >>> while still sharing a single drm_driver instance across all the > > >>> devices. To that end introduce device.driver_features. By default > > >>> it will be set to ~0 to not impose any limits beyond > > >>> driver.driver_features. Drivers can then clear specific flags > > >>> in the per-device bitmask to limit the capabilities of the device. > > >>> > > >>> An alternative approach would be to copy the driver_features from > > >>> the driver into the device in drm_dev_init(), however that would > > >>> require verifying that no driver is currently changing > > >>> driver.driver_features after drm_dev_init(). Hence the ~0 apporach > > >>> was easier. > > >>> > > >>> Ideally we'd also make drm_driver const but there is plenty of code > > >>> left that wants to mutate it (eg. various vfunc assignments). We'll > > >>> need to fix all that up before we can make it const. > > >>> > > >>> And while at it fix up the type of the feature flag passed to > > >>> drm_core_check_feature(). > > >>> > > >>> v2: Streamline the && vs. & (Chris) > > >>> s/int/u32/ in drm_core_check_feature() args > > >>> > > >>> Cc: Chris Wilson > > >>> Signed-off-by: Ville Syrjälä > > >> > > >> git grep DRIVER_ATOMIC -- drivers/gpu/drm/nouveau has a 2nd supporting > > >> case for this. Exactly same problem as we have here. Would be good to > > >> also > > >> convert that one, for a bit of OCD. > > > > > > Thanks for pointing it out. I'll cook it up and send separately after > > > this lands. > > > > I don't suppose you'd like to do amdgpu as well, while you're at it? :) > > Sure. I'll take a gander at it as well. Series pushed to drm-misc-next. Thanks for the reviews. -- Ville Syrjälä Intel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: i915, HDMI/DP audio with multiple monitors
On Thu, 13 Sep 2018 09:25:37 +0200, Bruno Prémont wrote: > > On Wed, 12 Sep 2018 20:06:43 +0200 Takashi Iwai wrote: > > On Wed, 12 Sep 2018 19:46:58 +0200, > > Ville Syrjälä wrote: > > > > > > On Tue, Sep 11, 2018 at 03:50:13PM +0200, Bruno Prémont wrote: > > > > Hi, > > > > > > > > I have a system with multiple monitors and would like to send > > > > notification sounds to the monitor on which corresponding > > > > window is visible. > > > > > > > > For a workstation and a tiny computer things look different: > > > > - workstation (Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz): > > > > 00:02.0 VGA compatible controller [0300]: Intel Corporation Xeon > > > > E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller > > > > [8086:0412] (rev 06) > > > > 00:03.0 Audio device [0403]: Intel Corporation Xeon E3-1200 v3/4th Gen > > > > Core Processor HD Audio Controller [8086:0c0c] (rev 06) > > > > 00:1b.0 Audio device [0403]: Intel Corporation 8 Series/C220 Series > > > > Chipset High Definition Audio Controller [8086:8c20] (rev 04) > > > > > > > > Here alsa show me two cards: > > > > - HDA Intel PCH (Realtek ALC671) > > > > - HDA Intel HDMI (Intel Generic) > > > > > > > > List of PLAYBACK Hardware Devices > > > > card 0: HDMI [HDA Intel HDMI], device 3: Generic Digital [Generic > > > > Digital] > > > >Subdevices: 1/1 > > > >Subdevice #0: subdevice #0 > > > > Is a proper kernel config (CONFIG_SND_HDA_CODEC_HDMI) enabled? > > It was missing and adding it helps a lot. > Would there be a way to auto-select it when corresponding DRM driver is > selected? > > Kind of > select SND_HDA_CODEC_HDMI if SND_HDA > or at least mention it in description, maybe as conditional comment is > done for HDA codecs. Yeah, a patch like below should work. --- a/drivers/gpu/drm/i915/Kconfig +++ b/drivers/gpu/drm/i915/Kconfig @@ -23,6 +23,7 @@ config DRM_I915 select SYNC_FILE select IOSF_MBI select CRC32 + select SND_HDA_CODEC_HDMI if SND_HDA_INTEL select SND_HDA_I915 if SND_HDA_CORE select CEC_CORE if CEC_NOTIFIER help But I'm not going to advocate it. Feel free to cook up and submit a proper patch if you really need it. Takashi ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/ttm: once more fix ttm_bo_bulk_move_lru_tail v2
Hi
This fixes a boot issue I had on Raven (
https://bugs.freedesktop.org/show_bug.cgi?id=107922)
Feel free to add to both patches:
Tested-by: Mike Lothian
Cheers
Mike
On Thu, 13 Sep 2018 at 12:22 Christian König <
ckoenig.leichtzumer...@gmail.com> wrote:
> While cutting the lists we sometimes accidentally added a list_head from
> the stack to the LRUs, effectively corrupting the list.
>
> Remove the list cutting and use explicit list manipulation instead.
>
> v2: separate out new list_bulk_move_tail helper
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/ttm/ttm_bo.c | 46
> +++-
> 1 file changed, 20 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index 138c98902033..26b889f86670 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -247,47 +247,38 @@ void ttm_bo_move_to_lru_tail(struct
> ttm_buffer_object *bo,
> }
> EXPORT_SYMBOL(ttm_bo_move_to_lru_tail);
>
> -static void ttm_bo_bulk_move_helper(struct ttm_lru_bulk_move_pos *pos,
> - struct list_head *lru, bool is_swap)
> -{
> - struct list_head *list;
> - LIST_HEAD(entries);
> - LIST_HEAD(before);
> -
> - reservation_object_assert_held(pos->last->resv);
> - list = is_swap ? >last->swap : >last->lru;
> - list_cut_position(, lru, list);
> -
> - reservation_object_assert_held(pos->first->resv);
> - list = is_swap ? pos->first->swap.prev : pos->first->lru.prev;
> - list_cut_position(, , list);
> -
> - list_splice(, lru);
> - list_splice_tail(, lru);
> -}
> -
> void ttm_bo_bulk_move_lru_tail(struct ttm_lru_bulk_move *bulk)
> {
> unsigned i;
>
> for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
> + struct ttm_lru_bulk_move_pos *pos = >tt[i];
> struct ttm_mem_type_manager *man;
>
> - if (!bulk->tt[i].first)
> + if (!pos->first)
> continue;
>
> - man = >tt[i].first->bdev->man[TTM_PL_TT];
> - ttm_bo_bulk_move_helper(>tt[i], >lru[i], false);
> + reservation_object_assert_held(pos->first->resv);
> + reservation_object_assert_held(pos->last->resv);
> +
> + man = >first->bdev->man[TTM_PL_TT];
> + list_bulk_move_tail(>lru[i], >first->lru,
> + >last->lru);
> }
>
> for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
> + struct ttm_lru_bulk_move_pos *pos = >vram[i];
> struct ttm_mem_type_manager *man;
>
> - if (!bulk->vram[i].first)
> + if (!pos->first)
> continue;
>
> - man = >vram[i].first->bdev->man[TTM_PL_VRAM];
> - ttm_bo_bulk_move_helper(>vram[i], >lru[i],
> false);
> + reservation_object_assert_held(pos->first->resv);
> + reservation_object_assert_held(pos->last->resv);
> +
> + man = >first->bdev->man[TTM_PL_VRAM];
> + list_bulk_move_tail(>lru[i], >first->lru,
> + >last->lru);
> }
>
> for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
> @@ -297,8 +288,11 @@ void ttm_bo_bulk_move_lru_tail(struct
> ttm_lru_bulk_move *bulk)
> if (!pos->first)
> continue;
>
> + reservation_object_assert_held(pos->first->resv);
> + reservation_object_assert_held(pos->last->resv);
> +
> lru = >first->bdev->glob->swap_lru[i];
> - ttm_bo_bulk_move_helper(>swap[i], lru, true);
> + list_bulk_move_tail(lru, >first->swap,
> >last->swap);
> }
> }
> EXPORT_SYMBOL(ttm_bo_bulk_move_lru_tail);
> --
> 2.14.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107922] System Freezes on Raven with agd5f 4.20-wip kernel
https://bugs.freedesktop.org/show_bug.cgi?id=107922 --- Comment #5 from Mike Lothian --- Created attachment 141553 --> https://bugs.freedesktop.org/attachment.cgi?id=141553=edit newest dmesg -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107922] System Freezes on Raven with agd5f 4.20-wip kernel
https://bugs.freedesktop.org/show_bug.cgi?id=107922 --- Comment #4 from Mike Lothian --- So that gets the machine booting however there's still this back trace [0.370419] WARNING: CPU: 2 PID: 1 at drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.c:1379 dcn_bw_update_from_pplib+0x166/0x270 [0.370422] Modules linked in: [0.370425] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.19.0-rc1-agd5f+ #260 [0.370427] Hardware name: System manufacturer System Product Name/ROG STRIX X470-I GAMING, BIOS 0901 07/23/2018 [0.370430] RIP: 0010:dcn_bw_update_from_pplib+0x166/0x270 [0.370433] Code: d8 ca d8 f1 d9 5a 50 8b 44 fc 14 49 8b 94 24 78 01 00 00 48 89 04 24 df 2c 24 d8 f1 db 42 78 de c9 de ca de f9 d9 5a 4c eb 02 <0f> 0b 48 89 da be 04 00 00 00 48 89 ef e8 68 96 fe ff 84 c 0 0f 84 [0.370438] RSP: 0018:c903b9d8 EFLAGS: 00010246 [0.370440] RAX: 0001 RBX: c903ba38 RCX: [0.370442] RDX: RSI: 0004 RDI: [0.370445] RBP: 8807fb05a000 R08: R09: 0720072007200720 [0.370447] R10: 8807fb8c0f00 R11: 0720072007200720 R12: 8807fb015000 [0.370449] R13: 8807fb055420 R14: 8807fb015000 R15: 8807fb193098 [0.370449] FS: () GS:8807ffa8() knlGS: [0.370449] CS: 0010 DS: ES: CR0: 80050033 [0.370449] CR2: c92c CR3: 0360a000 CR4: 003406a0 [0.370449] Call Trace: [0.370449] ? construct+0x7d8/0xa00 [0.370449] ? generic_reg_get+0x1b/0x30 [0.370449] ? dcn10_create_resource_pool+0x31/0x50 [0.370449] ? dc_create_resource_pool+0x3d/0x180 [0.370449] ? __kmalloc+0x15e/0x170 [0.370449] ? dc_create+0x1ec/0x5e0 [0.370449] ? kmem_cache_alloc+0x22/0x120 [0.370449] ? dm_hw_init+0xc3/0x130 [0.370449] ? amdgpu_device_init.cold.34+0xca7/0xe0d [0.370449] ? __alloc_pages_nodemask+0xc1/0x1d0 [0.370449] ? amdgpu_driver_load_kms+0x5e/0x190 [0.370449] ? drm_dev_register+0x104/0x140 [0.370449] ? amdgpu_pci_probe+0x122/0x19e [0.370449] ? _raw_spin_unlock_irqrestore+0xf/0x30 [0.370449] ? pci_device_probe+0xd1/0x160 [0.370449] ? really_probe+0x1e7/0x270 [0.370449] ? driver_probe_device+0x4a/0xb0 [0.370449] ? __driver_attach+0xaf/0xd0 [0.370449] ? driver_probe_device+0xb0/0xb0 [0.370449] ? bus_for_each_dev+0x71/0xb0 [0.370449] ? bus_add_driver+0x192/0x1d0 [0.370449] ? do_early_param+0x89/0x89 [0.370449] ? driver_register+0x66/0xb0 [0.370449] ? drm_sched_fence_slab_init+0x2c/0x2c [0.370449] ? do_one_initcall+0x42/0x162 [0.370449] ? do_early_param+0x89/0x89 [0.370449] ? kernel_init_freeable+0x14b/0x1d5 [0.370449] ? rest_init+0xb0/0xb0 [0.370449] ? kernel_init+0x5/0xf1 [0.370449] ? ret_from_fork+0x22/0x40 [0.370449] ---[ end trace 6cbafa0c2f65290d ]--- [0.370551] [drm] DM_PPLIB: values for Invalid clock But I think someone said that was harmless -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 1/2] drm: Introduce per-device driver_features
On Thu, Sep 13, 2018 at 04:52:34PM +0200, Michel Dänzer wrote: > On 2018-09-13 4:29 p.m., Ville Syrjälä wrote: > > On Thu, Sep 13, 2018 at 03:50:01PM +0200, Daniel Vetter wrote: > >> On Thu, Sep 13, 2018 at 04:16:21PM +0300, Ville Syrjala wrote: > >>> From: Ville Syrjälä > >>> > >>> We wish to control certain driver_features flags on a per-device basis > >>> while still sharing a single drm_driver instance across all the > >>> devices. To that end introduce device.driver_features. By default > >>> it will be set to ~0 to not impose any limits beyond > >>> driver.driver_features. Drivers can then clear specific flags > >>> in the per-device bitmask to limit the capabilities of the device. > >>> > >>> An alternative approach would be to copy the driver_features from > >>> the driver into the device in drm_dev_init(), however that would > >>> require verifying that no driver is currently changing > >>> driver.driver_features after drm_dev_init(). Hence the ~0 apporach > >>> was easier. > >>> > >>> Ideally we'd also make drm_driver const but there is plenty of code > >>> left that wants to mutate it (eg. various vfunc assignments). We'll > >>> need to fix all that up before we can make it const. > >>> > >>> And while at it fix up the type of the feature flag passed to > >>> drm_core_check_feature(). > >>> > >>> v2: Streamline the && vs. & (Chris) > >>> s/int/u32/ in drm_core_check_feature() args > >>> > >>> Cc: Chris Wilson > >>> Signed-off-by: Ville Syrjälä > >> > >> git grep DRIVER_ATOMIC -- drivers/gpu/drm/nouveau has a 2nd supporting > >> case for this. Exactly same problem as we have here. Would be good to also > >> convert that one, for a bit of OCD. > > > > Thanks for pointing it out. I'll cook it up and send separately after > > this lands. > > I don't suppose you'd like to do amdgpu as well, while you're at it? :) Sure. I'll take a gander at it as well. -- Ville Syrjälä Intel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH -fixes 5/5] drm/vmwgfx: Fix a buffer object eviction regression
Hi,
On 09/13/2018 04:10 PM, Matthew Wilcox wrote:
On Thu, Sep 13, 2018 at 01:58:37PM +0200, Thomas Hellstrom wrote:
Commit 4eb085e42fde ("drm/vmwgfx: Convert to new IDA API") indroduced
an incorrect return value from the function vmw_gmrid_man_get_node(),
when we run out if integer ids. Instead of returning 0 (meaning
non-fatal error) we forward the ida_simple_get error code -ENOSPC.
This causes TTM not to retry allocation after buffer eviction and
instead return -ENOSPC to user-space.
Fix this by returning 0 when ida_simple_get() returns -ENOSPC.
Thanks. I got confused by the convoluted code that was there before ;-(
I think this could be better though ... if ida_alloc() ever starts
returning a different errno in the future, you'll hit the same problem,
right? So how about this ...
id = ida_alloc_max(>gmr_ida, gman->max_gmr_ids - 1, GFP_KERNEL);
+ if (id == -ENOMEM)
+ return -ENOMEM;
+ if (id < 0)
+ return 0;
spin_lock(>lock);
But I wonder ... why is -ENOMEM seen as a fatal error? If you free up
some memory, you'll free up an ID, so the next time around you should
be able to allocate an ID. So shouldn't this function just have
been doing this all along?
id = ida_alloc_max(>gmr_ida, gman->max_gmr_ids - 1, GFP_KERNEL);
+ if (id < 0)
+ return 0;
Non-fatal errors are errors that can be remedied by GPU buffer eviction,
and buffer eviction will free up IDA space, so basically we need to
target only the error code that indicates we've run out of IDA space.
If we're worried that ida_alloc_max() will change return value, I guess
we will have to increase the IDA space and detect the error ourselves:
error if (id >= gman->max_gmr_ids)
/Thomas
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107922] System Freezes on Raven with agd5f 4.20-wip kernel
https://bugs.freedesktop.org/show_bug.cgi?id=107922 --- Comment #3 from Michel Dänzer --- Does https://patchwork.freedesktop.org/patch/249122/ help, by any chance? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[radeon-alex:drm-next-4.20-wip 89/317] drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/vega20_smumgr.c:34:26: fatal error: vega20_hwmgr.h: No such file or directory
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-4.20-wip head: 8901a65f080ad6f4d7c3ef9f23c6f3a0e3e194aa commit: f4eac80add11572fe36800c045a1ed1fd9132ec0 [89/317] drm/amd/powerplay: add the smu manager for vega20 (v2) config: i386-randconfig-s1-201836 (attached as .config) compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026 reproduce: git checkout f4eac80add11572fe36800c045a1ed1fd9132ec0 # save the attached .config to linux build tree make ARCH=i386 Note: the radeon-alex/drm-next-4.20-wip HEAD 8901a65f080ad6f4d7c3ef9f23c6f3a0e3e194aa builds fine. It only hurts bisectibility. All errors (new ones prefixed by >>): >> drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/vega20_smumgr.c:34:26: fatal >> error: vega20_hwmgr.h: No such file or directory #include "vega20_hwmgr.h" ^ compilation terminated. vim +34 drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/vega20_smumgr.c > 34 #include "vega20_hwmgr.h" 35 --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 05/20] drm/meson: Use drm_fbdev_generic_setup()
On Thu, Sep 13, 2018 at 04:26:53PM +0200, Neil Armstrong wrote: > Hi Daniel, > > On 13/09/2018 15:21, Daniel Vetter wrote: > > On Wed, Sep 12, 2018 at 01:06:07PM +0200, Noralf Trønnes wrote: > >> > >> Den 12.09.2018 12.57, skrev Noralf Trønnes: > >>> (Cc: Daniel Vetter) > >>> > >> > >> Somehow that CC was dropped somewhere after leaving email client. > >> Trying once more. > > > > Yeah I just made myself unpopular. If you want SMEM_START, then you need > > to carry a local patch now. virt_to_pfn on the vmap should work. It's > > about 2 lines, including the change to drop HIDE_SMEM_START. > > Would it be totally unacceptable to add such 2 line : > - enabled by a specific config depending on EXPERT and narrowed to specific > platforms > - printing a big fat pr_warning_once when used > - with a big fat comment specifying when this code will be dropped and why we > should not activate it module_param_debug auto-taints your kernel, I'd just go with that. Plus CONFIG_EXPERT (or CONFIG_BROKEN). But yes, I think that's something I'll happily ack. Must be acked by Dave (and perhaps a few others too), since defacto this means we now suddenly care about closed source blobs. I'd say get someone from amd and a few of the driver maintainers on board with this (nouveau, Eric, Rob, Lucas, ...), to make sure it really represents community consensus. Cheers, Daniel > > Neil > > > > And if consensus is that hiding SMEM_START is not a nice idea, then I'm > > sure we can reintroduce it through some slightly unpretty backdoor, even > > with Noralf's generic code. So not really a good reason to reject the > > cleanup I think. > > -Daniel > > > > > >>> Den 12.09.2018 11.56, skrev Maxime Ripard: > On Wed, Sep 12, 2018 at 11:48:34AM +0200, Neil Armstrong wrote: > > Hi Noralf, > > > > On 08/09/2018 15:46, Noralf Trønnes wrote: > >> The CMA helper is already using the > >> drm_fb_helper_generic_probe part of > >> the generic fbdev emulation. This patch makes full use of the generic > >> fbdev emulation by using its drm_client callbacks. This means that > >> drm_mode_config_funcs->output_poll_changed and > >> drm_driver->lastclose are > >> now handled by the emulation code. Additionally fbdev > >> unregister happens > >> automatically on drm_dev_unregister(). > >> > >> The drm_fbdev_generic_setup() call is put after > >> drm_dev_register() in the > >> driver. This is done to highlight the fact that fbdev emulation is an > >> internal client that makes use of the driver, it is not part of the > >> driver as such. If fbdev setup fails, an error is printed, > >> but the driver > >> succeeds probing. > > I can't really ack/nack this move, on one side it's great to have a > > generic fbdev emulation instead of the old fbdev code, but on the > > other side the Amlogic platform (like allwinner, samsung, rockchip, > > ...) still relies on an Fbdev variant of the libMali that uses > > smem_start... > > > > I know it's dirty and fbdev based code should be legacy now, but I > > consider it like an user-space breakage... > > > > I'll be happy if ARM provided it's Mali vendors a Fbdev libMali that > > could use FBINFO_HIDE_SMEM_START and allocate BO's from the DRM > > driver, it won't be the case and it will never be the case until the > > Lima projects finalizes. > > > > So for me it's a no-go until Lima lands upstream in Linux *and* Mesa. > My feelings exactly. If the choice is between reducing the DRM driver > by a couple of dozens of lines or keeping the mali working, I'll pick > the latter, every single day. > >>> > >>> I don't know the reasoning for blocking smem_start other than what Daniel > >>> wrote in these commit messages: > >>> > >>> da6c7707caf3736c1cf968606bd97c07e79625d4 > >>> fbdev: Add FBINFO_HIDE_SMEM_START flag > >>> > >>> DRM drivers really, really, really don't want random userspace to > >>> share buffer behind it's back, bypassing the dma-buf buffer sharing > >>> machanism. For that reason we've ruthlessly rejected any IOCTL > >>> exposing the physical address of any graphics buffer. > >>> > >>> Unfortunately fbdev comes with that built-in. We could just set > >>> smem_start to 0, but that means we'd have to hand-roll our own fb_mmap > >>> implementation. For good reasons many drivers do that, but > >>> smem_start/length is still super convenient. > >>> > >>> Hence instead just stop the leak in the ioctl, to keep fb mmap working > >>> as-is. A second patch will set this flag for all drm drivers. > >>> > >>> > >>> 6be8f3bd2c78915a9f3a058a346ae93068d35c01 > >>> drm/fb: Stop leaking physical address > >>> > >>> For buffer sharing, use dma-buf instead. We can't set smem_start to 0 > >>> unconditionally since that's used by the fbdev mmap default > >>> implementation. And we have plenty of userspace which would like to > >>> keep
Re: [Intel-gfx] [PATCH 1/2] drm: Introduce per-device driver_features
On 2018-09-13 4:29 p.m., Ville Syrjälä wrote: > On Thu, Sep 13, 2018 at 03:50:01PM +0200, Daniel Vetter wrote: >> On Thu, Sep 13, 2018 at 04:16:21PM +0300, Ville Syrjala wrote: >>> From: Ville Syrjälä >>> >>> We wish to control certain driver_features flags on a per-device basis >>> while still sharing a single drm_driver instance across all the >>> devices. To that end introduce device.driver_features. By default >>> it will be set to ~0 to not impose any limits beyond >>> driver.driver_features. Drivers can then clear specific flags >>> in the per-device bitmask to limit the capabilities of the device. >>> >>> An alternative approach would be to copy the driver_features from >>> the driver into the device in drm_dev_init(), however that would >>> require verifying that no driver is currently changing >>> driver.driver_features after drm_dev_init(). Hence the ~0 apporach >>> was easier. >>> >>> Ideally we'd also make drm_driver const but there is plenty of code >>> left that wants to mutate it (eg. various vfunc assignments). We'll >>> need to fix all that up before we can make it const. >>> >>> And while at it fix up the type of the feature flag passed to >>> drm_core_check_feature(). >>> >>> v2: Streamline the && vs. & (Chris) >>> s/int/u32/ in drm_core_check_feature() args >>> >>> Cc: Chris Wilson >>> Signed-off-by: Ville Syrjälä >> >> git grep DRIVER_ATOMIC -- drivers/gpu/drm/nouveau has a 2nd supporting >> case for this. Exactly same problem as we have here. Would be good to also >> convert that one, for a bit of OCD. > > Thanks for pointing it out. I'll cook it up and send separately after > this lands. I don't suppose you'd like to do amdgpu as well, while you're at it? :) Either way, this is awesome stuff! This patch is Reviewed-by: Michel Dänzer -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107922] System Freezes on Raven with agd5f 4.20-wip kernel
https://bugs.freedesktop.org/show_bug.cgi?id=107922 --- Comment #2 from Mike Lothian --- Created attachment 141552 --> https://bugs.freedesktop.org/attachment.cgi?id=141552=edit journalctl kernel output -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107922] System Freezes on Raven with agd5f 4.20-wip kernel
https://bugs.freedesktop.org/show_bug.cgi?id=107922 Mike Lothian changed: What|Removed |Added CC||m...@fireburn.co.uk --- Comment #1 from Mike Lothian --- Created attachment 141551 --> https://bugs.freedesktop.org/attachment.cgi?id=141551=edit dmesg -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107922] System Freezes on Raven with agd5f 4.20-wip kernel
https://bugs.freedesktop.org/show_bug.cgi?id=107922 Bug ID: 107922 Summary: System Freezes on Raven with agd5f 4.20-wip kernel Product: DRI Version: DRI git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: m...@fireburn.co.uk The system freezes up just after X starts, I did manage to capture this trace One other was in journalctl which complained about an NX-protected page exploit attempt -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/5] media: replace ADOBERGB by OPRGB
On 09/13/18 16:29, Mauro Carvalho Chehab wrote:
> Em Thu, 13 Sep 2018 13:47:27 +0200
> Hans Verkuil escreveu:
>
>> From: Hans Verkuil
>>
>> The CTA-861 standards have been updated to refer to opRGB instead
>> of AdobeRGB. The official standard is in fact named opRGB, so
>> switch to that.
>>
>> The two old defines referring to ADOBERGB in the public API are
>> put under #ifndef __KERNEL__ and a comment mentions that they are
>> deprecated.
>>
>> Signed-off-by: Hans Verkuil
>
>
>> index 184e4dbe8f9c..c1e14a3b476e 100644
>> --- a/include/uapi/linux/videodev2.h
>> +++ b/include/uapi/linux/videodev2.h
>> @@ -225,8 +225,12 @@ enum v4l2_colorspace {
>> /* For RGB colorspaces such as produces by most webcams. */
>> V4L2_COLORSPACE_SRGB = 8,
>>
>> -/* AdobeRGB colorspace */
>> +/* opRGB colorspace */
>> +V4L2_COLORSPACE_OPRGB = 9,
>> +#ifndef __KERNEL__
>> +/* Deprecated alias for V4L2_COLORSPACE_OPRGB */
>> V4L2_COLORSPACE_ADOBERGB = 9,
>> +#endif
>>
>> /* BT.2020 colorspace, used for UHDTV. */
>> V4L2_COLORSPACE_BT2020= 10,
>> @@ -258,7 +262,7 @@ enum v4l2_xfer_func {
>> *
>> * V4L2_COLORSPACE_SRGB, V4L2_COLORSPACE_JPEG: V4L2_XFER_FUNC_SRGB
>> *
>> - * V4L2_COLORSPACE_ADOBERGB: V4L2_XFER_FUNC_ADOBERGB
>> + * V4L2_COLORSPACE_OPRGB: V4L2_XFER_FUNC_OPRGB
>> *
>> * V4L2_COLORSPACE_SMPTE240M: V4L2_XFER_FUNC_SMPTE240M
>> *
>> @@ -269,7 +273,11 @@ enum v4l2_xfer_func {
>> V4L2_XFER_FUNC_DEFAULT = 0,
>> V4L2_XFER_FUNC_709 = 1,
>> V4L2_XFER_FUNC_SRGB= 2,
>> +V4L2_XFER_FUNC_OPRGB = 3,
>> +#ifndef __KERNEL__
>> +/* Deprecated alias for V4L2_XFER_FUNC_OPRGB */
>> V4L2_XFER_FUNC_ADOBERGB= 3,
>> +#endif
>> V4L2_XFER_FUNC_SMPTE240M = 4,
>> V4L2_XFER_FUNC_NONE= 5,
>> V4L2_XFER_FUNC_DCI_P3 = 6,
>
> Nitpick: instead of having #ifndef inside the enum, I would instead
> place both V4L2_COLORSPACE_ADOBERGB and V4L2_XFER_FUNC_ADOBERGB on
> a separate #define, e. g:
>
> /*
> * Deprecated names for Optional RGB colorspace (IEC 61966-2)
> *
> * WARNING: Please don't use it on your code, as those can be removed
> * from Kernelspace in the future.
> */
> #ifndef __KERNEL__
> # define V4L2_COLORSPACE_ADOBERGB V4L2_COLORSPACE_OPRGB
> # define V4L2_XFER_FUNC_ADOBERGB V4L2_XFER_FUNC_OPRGB
> #endif
>
> There are two reasons for that:
>
> 1) by adding them inside enums and not documenting, you may
>end by having warnings;
>
> 2) as you mentioned on patch 0/5, one of the goals is to
>"avoid possible future trademark complaints."
>
> So, better to add a clear warning at the Kernel that we may need
> to remove it in the future.
Will do, makes sense.
Hans
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 1/2] drm: Introduce per-device driver_features
On Thu, Sep 13, 2018 at 03:50:01PM +0200, Daniel Vetter wrote:
> On Thu, Sep 13, 2018 at 04:16:21PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > We wish to control certain driver_features flags on a per-device basis
> > while still sharing a single drm_driver instance across all the
> > devices. To that end introduce device.driver_features. By default
> > it will be set to ~0 to not impose any limits beyond
> > driver.driver_features. Drivers can then clear specific flags
> > in the per-device bitmask to limit the capabilities of the device.
> >
> > An alternative approach would be to copy the driver_features from
> > the driver into the device in drm_dev_init(), however that would
> > require verifying that no driver is currently changing
> > driver.driver_features after drm_dev_init(). Hence the ~0 apporach
> > was easier.
> >
> > Ideally we'd also make drm_driver const but there is plenty of code
> > left that wants to mutate it (eg. various vfunc assignments). We'll
> > need to fix all that up before we can make it const.
> >
> > And while at it fix up the type of the feature flag passed to
> > drm_core_check_feature().
> >
> > v2: Streamline the && vs. & (Chris)
> > s/int/u32/ in drm_core_check_feature() args
> >
> > Cc: Chris Wilson
> > Signed-off-by: Ville Syrjälä
>
> git grep DRIVER_ATOMIC -- drivers/gpu/drm/nouveau has a 2nd supporting
> case for this. Exactly same problem as we have here. Would be good to also
> convert that one, for a bit of OCD.
Thanks for pointing it out. I'll cook it up and send separately after
this lands.
>
> Irrespective of that, on the series:
>
> Reviewed-by: Daniel Vetter
>
> Feel free to also add the r-b to the nouveau patch if you do it, it's
> rather obvious.
> -Daniel
>
> > ---
> > drivers/gpu/drm/drm_drv.c | 3 +++
> > include/drm/drm_device.h | 10 ++
> > include/drm/drm_drv.h | 8
> > 3 files changed, 17 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> > index ea4941da9b27..36e8e9cbec52 100644
> > --- a/drivers/gpu/drm/drm_drv.c
> > +++ b/drivers/gpu/drm/drm_drv.c
> > @@ -506,6 +506,9 @@ int drm_dev_init(struct drm_device *dev,
> > dev->dev = parent;
> > dev->driver = driver;
> >
> > + /* no per-device feature limits by default */
> > + dev->driver_features = ~0u;
> > +
> > INIT_LIST_HEAD(>filelist);
> > INIT_LIST_HEAD(>filelist_internal);
> > INIT_LIST_HEAD(>clientlist);
> > diff --git a/include/drm/drm_device.h b/include/drm/drm_device.h
> > index f9c6e0e3aec7..42411b3ea0c8 100644
> > --- a/include/drm/drm_device.h
> > +++ b/include/drm/drm_device.h
> > @@ -45,6 +45,16 @@ struct drm_device {
> > /* currently active master for this device. Protected by master_mutex */
> > struct drm_master *master;
> >
> > + /**
> > +* @driver_features: per-device driver features
> > +*
> > +* Drivers can clear specific flags here to disallow
> > +* certain features on a per-device basis while still
> > +* sharing a single drm_driver instance across
> > +* all devices.
> > +*/
> > + u32 driver_features;
> > +
> > /**
> > * @unplugged:
> > *
> > diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
> > index 23b9678137a6..8830e3de3a86 100644
> > --- a/include/drm/drm_drv.h
> > +++ b/include/drm/drm_drv.h
> > @@ -653,14 +653,14 @@ static inline bool drm_dev_is_unplugged(struct
> > drm_device *dev)
> > * @dev: DRM device to check
> > * @feature: feature flag
> > *
> > - * This checks @dev for driver features, see _driver.driver_features
> > and the
> > - * various DRIVER_\* flags.
> > + * This checks @dev for driver features, see _driver.driver_features,
> > + * _device.driver_features, and the various DRIVER_\* flags.
> > *
> > * Returns true if the @feature is supported, false otherwise.
> > */
> > -static inline bool drm_core_check_feature(struct drm_device *dev, int
> > feature)
> > +static inline bool drm_core_check_feature(struct drm_device *dev, u32
> > feature)
> > {
> > - return dev->driver->driver_features & feature;
> > + return dev->driver->driver_features & dev->driver_features & feature;
> > }
> >
> > /**
> > --
> > 2.16.4
> >
> > ___
> > Intel-gfx mailing list
> > intel-...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/5] media: replace ADOBERGB by OPRGB
Em Thu, 13 Sep 2018 13:47:27 +0200
Hans Verkuil escreveu:
> From: Hans Verkuil
>
> The CTA-861 standards have been updated to refer to opRGB instead
> of AdobeRGB. The official standard is in fact named opRGB, so
> switch to that.
>
> The two old defines referring to ADOBERGB in the public API are
> put under #ifndef __KERNEL__ and a comment mentions that they are
> deprecated.
>
> Signed-off-by: Hans Verkuil
> index 184e4dbe8f9c..c1e14a3b476e 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -225,8 +225,12 @@ enum v4l2_colorspace {
> /* For RGB colorspaces such as produces by most webcams. */
> V4L2_COLORSPACE_SRGB = 8,
>
> - /* AdobeRGB colorspace */
> + /* opRGB colorspace */
> + V4L2_COLORSPACE_OPRGB = 9,
> +#ifndef __KERNEL__
> + /* Deprecated alias for V4L2_COLORSPACE_OPRGB */
> V4L2_COLORSPACE_ADOBERGB = 9,
> +#endif
>
> /* BT.2020 colorspace, used for UHDTV. */
> V4L2_COLORSPACE_BT2020= 10,
> @@ -258,7 +262,7 @@ enum v4l2_xfer_func {
>*
>* V4L2_COLORSPACE_SRGB, V4L2_COLORSPACE_JPEG: V4L2_XFER_FUNC_SRGB
>*
> - * V4L2_COLORSPACE_ADOBERGB: V4L2_XFER_FUNC_ADOBERGB
> + * V4L2_COLORSPACE_OPRGB: V4L2_XFER_FUNC_OPRGB
>*
>* V4L2_COLORSPACE_SMPTE240M: V4L2_XFER_FUNC_SMPTE240M
>*
> @@ -269,7 +273,11 @@ enum v4l2_xfer_func {
> V4L2_XFER_FUNC_DEFAULT = 0,
> V4L2_XFER_FUNC_709 = 1,
> V4L2_XFER_FUNC_SRGB= 2,
> + V4L2_XFER_FUNC_OPRGB = 3,
> +#ifndef __KERNEL__
> + /* Deprecated alias for V4L2_XFER_FUNC_OPRGB */
> V4L2_XFER_FUNC_ADOBERGB= 3,
> +#endif
> V4L2_XFER_FUNC_SMPTE240M = 4,
> V4L2_XFER_FUNC_NONE= 5,
> V4L2_XFER_FUNC_DCI_P3 = 6,
Nitpick: instead of having #ifndef inside the enum, I would instead
place both V4L2_COLORSPACE_ADOBERGB and V4L2_XFER_FUNC_ADOBERGB on
a separate #define, e. g:
/*
* Deprecated names for Optional RGB colorspace (IEC 61966-2)
*
* WARNING: Please don't use it on your code, as those can be removed
* from Kernelspace in the future.
*/
#ifndef __KERNEL__
# define V4L2_COLORSPACE_ADOBERGB V4L2_COLORSPACE_OPRGB
# define V4L2_XFER_FUNC_ADOBERGB V4L2_XFER_FUNC_OPRGB
#endif
There are two reasons for that:
1) by adding them inside enums and not documenting, you may
end by having warnings;
2) as you mentioned on patch 0/5, one of the goals is to
"avoid possible future trademark complaints."
So, better to add a clear warning at the Kernel that we may need
to remove it in the future.
Thanks,
Mauro
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 05/20] drm/meson: Use drm_fbdev_generic_setup()
Hi Daniel, On 13/09/2018 15:21, Daniel Vetter wrote: > On Wed, Sep 12, 2018 at 01:06:07PM +0200, Noralf Trønnes wrote: >> >> Den 12.09.2018 12.57, skrev Noralf Trønnes: >>> (Cc: Daniel Vetter) >>> >> >> Somehow that CC was dropped somewhere after leaving email client. >> Trying once more. > > Yeah I just made myself unpopular. If you want SMEM_START, then you need > to carry a local patch now. virt_to_pfn on the vmap should work. It's > about 2 lines, including the change to drop HIDE_SMEM_START. Would it be totally unacceptable to add such 2 line : - enabled by a specific config depending on EXPERT and narrowed to specific platforms - printing a big fat pr_warning_once when used - with a big fat comment specifying when this code will be dropped and why we should not activate it Neil > > And if consensus is that hiding SMEM_START is not a nice idea, then I'm > sure we can reintroduce it through some slightly unpretty backdoor, even > with Noralf's generic code. So not really a good reason to reject the > cleanup I think. > -Daniel > > >>> Den 12.09.2018 11.56, skrev Maxime Ripard: On Wed, Sep 12, 2018 at 11:48:34AM +0200, Neil Armstrong wrote: > Hi Noralf, > > On 08/09/2018 15:46, Noralf Trønnes wrote: >> The CMA helper is already using the >> drm_fb_helper_generic_probe part of >> the generic fbdev emulation. This patch makes full use of the generic >> fbdev emulation by using its drm_client callbacks. This means that >> drm_mode_config_funcs->output_poll_changed and >> drm_driver->lastclose are >> now handled by the emulation code. Additionally fbdev >> unregister happens >> automatically on drm_dev_unregister(). >> >> The drm_fbdev_generic_setup() call is put after >> drm_dev_register() in the >> driver. This is done to highlight the fact that fbdev emulation is an >> internal client that makes use of the driver, it is not part of the >> driver as such. If fbdev setup fails, an error is printed, >> but the driver >> succeeds probing. > I can't really ack/nack this move, on one side it's great to have a > generic fbdev emulation instead of the old fbdev code, but on the > other side the Amlogic platform (like allwinner, samsung, rockchip, > ...) still relies on an Fbdev variant of the libMali that uses > smem_start... > > I know it's dirty and fbdev based code should be legacy now, but I > consider it like an user-space breakage... > > I'll be happy if ARM provided it's Mali vendors a Fbdev libMali that > could use FBINFO_HIDE_SMEM_START and allocate BO's from the DRM > driver, it won't be the case and it will never be the case until the > Lima projects finalizes. > > So for me it's a no-go until Lima lands upstream in Linux *and* Mesa. My feelings exactly. If the choice is between reducing the DRM driver by a couple of dozens of lines or keeping the mali working, I'll pick the latter, every single day. >>> >>> I don't know the reasoning for blocking smem_start other than what Daniel >>> wrote in these commit messages: >>> >>> da6c7707caf3736c1cf968606bd97c07e79625d4 >>> fbdev: Add FBINFO_HIDE_SMEM_START flag >>> >>> DRM drivers really, really, really don't want random userspace to >>> share buffer behind it's back, bypassing the dma-buf buffer sharing >>> machanism. For that reason we've ruthlessly rejected any IOCTL >>> exposing the physical address of any graphics buffer. >>> >>> Unfortunately fbdev comes with that built-in. We could just set >>> smem_start to 0, but that means we'd have to hand-roll our own fb_mmap >>> implementation. For good reasons many drivers do that, but >>> smem_start/length is still super convenient. >>> >>> Hence instead just stop the leak in the ioctl, to keep fb mmap working >>> as-is. A second patch will set this flag for all drm drivers. >>> >>> >>> 6be8f3bd2c78915a9f3a058a346ae93068d35c01 >>> drm/fb: Stop leaking physical address >>> >>> For buffer sharing, use dma-buf instead. We can't set smem_start to 0 >>> unconditionally since that's used by the fbdev mmap default >>> implementation. And we have plenty of userspace which would like to >>> keep that working. >>> >>> This might break legit userspace - if it does we need to look at a >>> case-by-cases basis how to handle that. Worst case I expect overrides >>> for only specific drivers, since anything remotely modern should be >>> using dma-buf/prime now (which is about 7 years old now for DRM >>> drivers). >>> >>> This issue was uncovered because Noralf's rework to implement a >>> generic fb_probe also implements it's own fb_mmap callback. Which >>> means smem_start didn't have to be set anymore, which blew up some >>> blob in userspace rather badly. >>> >>> >>> Noralf. >>> >>> ___ >>> dri-devel mailing list >>> dri-devel@lists.freedesktop.org >>>
Re: [PATCH] MAINTAINERS: drm: Remove myself as drm-bridge maintainer
On 13.09.2018 09:53, Archit Taneja wrote: > I have moved on to other stuff for now. Haven't been able to make time > to review bridge related work. Andrzej has been doing it by himself > for a while now. > > Cc: Andrzej Hajda > Cc: Laurent Pinchart > Cc: Gustavo Padovan > Cc: Maarten Lankhorst > Cc: Sean Paul > Cc: Daniel Vetter > Signed-off-by: Archit Taneja > --- Thanks a lot and good luck with new challenges. If needed :) : Acked-by: Andrzej Hajda Regards Andrzej > MAINTAINERS | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 9d9068ed4ee5..7ed01e227684 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -4793,7 +4793,6 @@ F: Documentation/devicetree/bindings/display/atmel/ > T: git git://anongit.freedesktop.org/drm/drm-misc > > DRM DRIVERS FOR BRIDGE CHIPS > -M: Archit Taneja > M: Andrzej Hajda > R: Laurent Pinchart > S: Maintained ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] ALSA: hda - Enable runtime PM only for discrete GPU
On Thu, Sep 13, 2018 at 03:35:36PM +0200, Takashi Iwai wrote: > On Thu, 13 Sep 2018 15:27:16 +0200, Jian-Hong Pan wrote: > > 2018-09-13 14:56 GMT+08:00 Takashi Iwai : > > > The recent change of vga_switcheroo allowed the runtime PM for > > > HD-audio on AMD GPUs, but this also resulted in a regression. When > > > the HD-audio controller driver gets runtime-suspended, HD-audio link > > > is turned off, and the hotplug notification is ignored. This leads to > > > the inconsistent audio state (the connection isn't notified and ELD is > > > ignored). > > > > > > The best fix would be to implement the proper ELD notification via the > > > audio component, but it's still not ready. As a quick workaround, > > > this patch adds the check of runtime_idle and allows the runtime > > > suspend only when the vga_switcheroo is bound with discrete GPU. > > > That is, a system with a single GPU and APU would be again without > > > runtime PM to keep the HD-audio link for the hotplug notification and > > > ELD read out. > > > > > > Also, the codec->auto_runtime_pm flag is set only for the discrete GPU > > > at the time GPU gets bound via vga_switcheroo (i.e. only dGPU is > > > forcibly runtime-PM enabled), so that APU can still get the ELD > > > notification. > > > > > > For identifying which GPU is bound, a new vga_switcheroo client > > > callback, gpu_bound, is implemented. The vga_switcheroo simply calls > > > this when GPU is bound, and tells whether it's dGPU or APU. > > > > Tested-by: Jian-Hong Pan > > Thanks. I should put you also as the original reporter. > > Lukas, could you check the vga_switcheroo change whether it's > acceptable? I looked over it this morning and didn't get every little detail, e.g. why chip->running = 0 in azx_free() (seems like an unrelated change, but I'm not sure). But I do understand the idea underlying the patch and it LGTM. It's somewhat regrettable that we have to make things more complicated again to properly differentiate between integrated and discrete GPUs. I wish we could later on come up with a scheme that is lightweight and easy to follow. Obviously, such a scheme will likely not be eligible as a fix for 4.19. Anyway, Acked-by: Lukas Wunner and thanks a lot for looking into it. Please cc dri-devel for vga_switcheroo-related patches in the future (now added, + Alex, links for context: https://patchwork.kernel.org/patch/10598735/ https://bugzilla.kernel.org/show_bug.cgi?id=200945 ). Lukas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] ALSA: hda - Enable runtime PM only for discrete GPU
On Thu, 13 Sep 2018 15:58:13 +0200, Lukas Wunner wrote: > > On Thu, Sep 13, 2018 at 03:35:36PM +0200, Takashi Iwai wrote: > > On Thu, 13 Sep 2018 15:27:16 +0200, Jian-Hong Pan wrote: > > > 2018-09-13 14:56 GMT+08:00 Takashi Iwai : > > > > The recent change of vga_switcheroo allowed the runtime PM for > > > > HD-audio on AMD GPUs, but this also resulted in a regression. When > > > > the HD-audio controller driver gets runtime-suspended, HD-audio link > > > > is turned off, and the hotplug notification is ignored. This leads to > > > > the inconsistent audio state (the connection isn't notified and ELD is > > > > ignored). > > > > > > > > The best fix would be to implement the proper ELD notification via the > > > > audio component, but it's still not ready. As a quick workaround, > > > > this patch adds the check of runtime_idle and allows the runtime > > > > suspend only when the vga_switcheroo is bound with discrete GPU. > > > > That is, a system with a single GPU and APU would be again without > > > > runtime PM to keep the HD-audio link for the hotplug notification and > > > > ELD read out. > > > > > > > > Also, the codec->auto_runtime_pm flag is set only for the discrete GPU > > > > at the time GPU gets bound via vga_switcheroo (i.e. only dGPU is > > > > forcibly runtime-PM enabled), so that APU can still get the ELD > > > > notification. > > > > > > > > For identifying which GPU is bound, a new vga_switcheroo client > > > > callback, gpu_bound, is implemented. The vga_switcheroo simply calls > > > > this when GPU is bound, and tells whether it's dGPU or APU. > > > > > > Tested-by: Jian-Hong Pan > > > > Thanks. I should put you also as the original reporter. > > > > Lukas, could you check the vga_switcheroo change whether it's > > acceptable? > > I looked over it this morning and didn't get every little detail, > e.g. why chip->running = 0 in azx_free() (seems like an unrelated > change, but I'm not sure). It's to avoid the possible call of set_default_power_save() in azx_vs_gpu_bound() call, i.e. when a GPU is bound during the audio driver is being deregistered. It matters just theoretically. > But I do understand the idea underlying > the patch and it LGTM. It's somewhat regrettable that we have to > make things more complicated again to properly differentiate between > integrated and discrete GPUs. I wish we could later on come up with > a scheme that is lightweight and easy to follow. Obviously, such a > scheme will likely not be eligible as a fix for 4.19. Anyway, > > Acked-by: Lukas Wunner > > and thanks a lot for looking into it. Please cc dri-devel for > vga_switcheroo-related patches in the future (now added, + Alex, > links for context: > https://patchwork.kernel.org/patch/10598735/ > https://bugzilla.kernel.org/show_bug.cgi?id=200945 ). Oh right, I seem to have forgotten Cc, sorry for that. thanks, Takashi ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i2c/tda9950.c: set MAX_RETRIES for errors only
On 09/13/18 15:48, Russell King - ARM Linux wrote: > On Thu, Sep 13, 2018 at 03:33:20PM +0200, Hans Verkuil wrote: >> On 09/13/18 15:16, Daniel Vetter wrote: >>> On Thu, Sep 13, 2018 at 10:33:35AM +0100, Russell King - ARM Linux wrote: Hi Hans, I'll pick it up in due course. Thanks. On Tue, Sep 11, 2018 at 08:41:59AM +0200, Hans Verkuil wrote: > Russell (or someone else), can you Ack this patch? I'd like to get this > for 4.20. > > Thanks! > > Hans > > On 08/27/2018 02:28 PM, Hans Verkuil wrote: >> The CEC_TX_STATUS_MAX_RETRIES should be set for errors only to >> prevent the CEC framework from retrying the transmit. If the >> transmit was successful, then don't set this flag. >> >> Found by running 'cec-compliance -A' on a beaglebone box. >> >> Signed-off-by: Hans Verkuil >>> >>> Since the tda driver is now a brideg one, would make sense to maintain it >>> as part of drm-misc? Hans could push directly then. >> >> It isn't yet part of drm-misc? It would make sense IMHO. >> >> And 'due course' is too vague since this should be merged for 4.20. > > Given that we are at 4.19-rc3, and you are talking about it being merged > during the _next_ merge window, there is plenty of time remaining that > waiting another week or two for me to pick it up is not a problem. No problem, then I leave it to you to pick up. 'due course' can mean anything from tomorrow to next year, so that didn't help me :-) > In any case, my plan is to merge it for 4.19 since it appears to be a > bug fix, albiet a minor one. > It's a bug fix, but nothing in the kernel tree is currently using this AFAIK. The BBB would be the first to actually activate it. I'm fine with merging it in 4.19, but it is not strictly necessary. Regards, Hans ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 1/2] drm: Introduce per-device driver_features
On Thu, Sep 13, 2018 at 04:16:21PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We wish to control certain driver_features flags on a per-device basis
> while still sharing a single drm_driver instance across all the
> devices. To that end introduce device.driver_features. By default
> it will be set to ~0 to not impose any limits beyond
> driver.driver_features. Drivers can then clear specific flags
> in the per-device bitmask to limit the capabilities of the device.
>
> An alternative approach would be to copy the driver_features from
> the driver into the device in drm_dev_init(), however that would
> require verifying that no driver is currently changing
> driver.driver_features after drm_dev_init(). Hence the ~0 apporach
> was easier.
>
> Ideally we'd also make drm_driver const but there is plenty of code
> left that wants to mutate it (eg. various vfunc assignments). We'll
> need to fix all that up before we can make it const.
>
> And while at it fix up the type of the feature flag passed to
> drm_core_check_feature().
>
> v2: Streamline the && vs. & (Chris)
> s/int/u32/ in drm_core_check_feature() args
>
> Cc: Chris Wilson
> Signed-off-by: Ville Syrjälä
git grep DRIVER_ATOMIC -- drivers/gpu/drm/nouveau has a 2nd supporting
case for this. Exactly same problem as we have here. Would be good to also
convert that one, for a bit of OCD.
Irrespective of that, on the series:
Reviewed-by: Daniel Vetter
Feel free to also add the r-b to the nouveau patch if you do it, it's
rather obvious.
-Daniel
> ---
> drivers/gpu/drm/drm_drv.c | 3 +++
> include/drm/drm_device.h | 10 ++
> include/drm/drm_drv.h | 8
> 3 files changed, 17 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index ea4941da9b27..36e8e9cbec52 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -506,6 +506,9 @@ int drm_dev_init(struct drm_device *dev,
> dev->dev = parent;
> dev->driver = driver;
>
> + /* no per-device feature limits by default */
> + dev->driver_features = ~0u;
> +
> INIT_LIST_HEAD(>filelist);
> INIT_LIST_HEAD(>filelist_internal);
> INIT_LIST_HEAD(>clientlist);
> diff --git a/include/drm/drm_device.h b/include/drm/drm_device.h
> index f9c6e0e3aec7..42411b3ea0c8 100644
> --- a/include/drm/drm_device.h
> +++ b/include/drm/drm_device.h
> @@ -45,6 +45,16 @@ struct drm_device {
> /* currently active master for this device. Protected by master_mutex */
> struct drm_master *master;
>
> + /**
> + * @driver_features: per-device driver features
> + *
> + * Drivers can clear specific flags here to disallow
> + * certain features on a per-device basis while still
> + * sharing a single drm_driver instance across
> + * all devices.
> + */
> + u32 driver_features;
> +
> /**
>* @unplugged:
>*
> diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
> index 23b9678137a6..8830e3de3a86 100644
> --- a/include/drm/drm_drv.h
> +++ b/include/drm/drm_drv.h
> @@ -653,14 +653,14 @@ static inline bool drm_dev_is_unplugged(struct
> drm_device *dev)
> * @dev: DRM device to check
> * @feature: feature flag
> *
> - * This checks @dev for driver features, see _driver.driver_features and
> the
> - * various DRIVER_\* flags.
> + * This checks @dev for driver features, see _driver.driver_features,
> + * _device.driver_features, and the various DRIVER_\* flags.
> *
> * Returns true if the @feature is supported, false otherwise.
> */
> -static inline bool drm_core_check_feature(struct drm_device *dev, int
> feature)
> +static inline bool drm_core_check_feature(struct drm_device *dev, u32
> feature)
> {
> - return dev->driver->driver_features & feature;
> + return dev->driver->driver_features & dev->driver_features & feature;
> }
>
> /**
> --
> 2.16.4
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i2c/tda9950.c: set MAX_RETRIES for errors only
On Thu, Sep 13, 2018 at 03:33:20PM +0200, Hans Verkuil wrote: > On 09/13/18 15:16, Daniel Vetter wrote: > > On Thu, Sep 13, 2018 at 10:33:35AM +0100, Russell King - ARM Linux wrote: > >> Hi Hans, > >> > >> I'll pick it up in due course. > >> > >> Thanks. > >> > >> On Tue, Sep 11, 2018 at 08:41:59AM +0200, Hans Verkuil wrote: > >>> Russell (or someone else), can you Ack this patch? I'd like to get this > >>> for 4.20. > >>> > >>> Thanks! > >>> > >>> Hans > >>> > >>> On 08/27/2018 02:28 PM, Hans Verkuil wrote: > The CEC_TX_STATUS_MAX_RETRIES should be set for errors only to > prevent the CEC framework from retrying the transmit. If the > transmit was successful, then don't set this flag. > > Found by running 'cec-compliance -A' on a beaglebone box. > > Signed-off-by: Hans Verkuil > > > > Since the tda driver is now a brideg one, would make sense to maintain it > > as part of drm-misc? Hans could push directly then. > > It isn't yet part of drm-misc? It would make sense IMHO. > > And 'due course' is too vague since this should be merged for 4.20. Given that we are at 4.19-rc3, and you are talking about it being merged during the _next_ merge window, there is plenty of time remaining that waiting another week or two for me to pick it up is not a problem. In any case, my plan is to merge it for 4.19 since it appears to be a bug fix, albiet a minor one. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 13.8Mbps down 630kbps up According to speedtest.net: 13Mbps down 490kbps up ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/5] Rename AdobeRGB to opRGB
On Thu, Sep 13, 2018 at 01:47:26PM +0200, Hans Verkuil wrote: > From: Hans Verkuil > > This patch series replaces all AdobeRGB references by opRGB references. > > In November last year all references to the AdobeRGB colorspace were removed > from the CTA-861 standards (all versions) and replaced with the corresponding > international opRGB standard (IEC 61966-2-5) due to trademark issues. > > This patch series makes the same change in the kernel because: > > 1) it makes sense to keep in sync with the CTA-861 standard, > 2) using an international standard is always preferable to a company standard, > 3) avoid possible future trademark complaints. > > The first two patches can go through the media subsystem. The third patch > changes hdmi.c/h, but since the renamed defines from hdmi.h are only used > in the media subsystem I would prefer to merge this via the media subsystem > as well. So if I can get an Ack, then that would be great. > > The fourth patch I can push to drm-misc when it's reviewed, and the final > patch can go through the AMD GPU maintainers. > > There are only two references to the old name left since they are part of > the V4L2 public API, so I can't remove them. Does what it says on the tin. For the series: Acked-by: Daniel Vetter But definitely needs an ack from amdgpu folks too (plus media ofc). -Daniel > > Regards, > > Hans > > > Hans Verkuil (5): > media: replace ADOBERGB by OPRGB > media colorspaces*.rst: rename AdobeRGB to opRGB > hdmi.h: rename ADOBE_RGB to OPRGB and ADOBE_YCC to OPYCC > drm/bridge/synopsys/dw-hdmi.h: rename ADOBE to OP > drm/amd: rename ADOBE to OP > > Documentation/media/uapi/v4l/biblio.rst | 10 - > .../media/uapi/v4l/colorspaces-defs.rst | 8 +- > .../media/uapi/v4l/colorspaces-details.rst| 13 +- > .../media/videodev2.h.rst.exceptions | 2 + > .../drm/amd/display/dc/core/dc_hw_sequencer.c | 4 +- > .../gpu/drm/amd/display/dc/core/dc_resource.c | 4 +- > drivers/gpu/drm/amd/display/dc/dc_hw_types.h | 2 +- > .../amd/display/dc/dce/dce_stream_encoder.c | 2 +- > .../amd/display/dc/dcn10/dcn10_hw_sequencer.c | 2 +- > .../display/dc/dcn10/dcn10_stream_encoder.c | 2 +- > .../gpu/drm/amd/display/dc/inc/hw/transform.h | 4 +- > drivers/gpu/drm/bridge/synopsys/dw-hdmi.h | 4 +- > .../media/common/v4l2-tpg/v4l2-tpg-colors.c | 262 +- > drivers/media/i2c/adv7511.c | 6 +- > drivers/media/i2c/adv7604.c | 2 +- > drivers/media/i2c/tc358743.c | 4 +- > drivers/media/platform/vivid/vivid-core.h | 2 +- > drivers/media/platform/vivid/vivid-ctrls.c| 6 +- > drivers/media/platform/vivid/vivid-vid-out.c | 2 +- > drivers/media/v4l2-core/v4l2-dv-timings.c | 12 +- > drivers/video/hdmi.c | 8 +- > include/linux/hdmi.h | 4 +- > include/uapi/linux/videodev2.h| 16 +- > 23 files changed, 190 insertions(+), 191 deletions(-) > > -- > 2.18.0 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] MAINTAINERS: drm: Remove myself as drm-bridge maintainer
On Thu, Sep 13, 2018 at 01:23:00PM +0530, Archit Taneja wrote: > I have moved on to other stuff for now. Haven't been able to make time > to review bridge related work. Andrzej has been doing it by himself > for a while now. > > Cc: Andrzej Hajda > Cc: Laurent Pinchart > Cc: Gustavo Padovan > Cc: Maarten Lankhorst > Cc: Sean Paul > Cc: Daniel Vetter > Signed-off-by: Archit Taneja Thanks a lot for all your great work, and all the best for your journey! Acked-by: Daniel Vetter And as mentioned on irc, we're always glad to have you back. Cheers, Daniel > --- > MAINTAINERS | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 9d9068ed4ee5..7ed01e227684 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -4793,7 +4793,6 @@ F: Documentation/devicetree/bindings/display/atmel/ > T: git git://anongit.freedesktop.org/drm/drm-misc > > DRM DRIVERS FOR BRIDGE CHIPS > -M: Archit Taneja > M: Andrzej Hajda > R: Laurent Pinchart > S: Maintained > -- > 2.18.0 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i2c/tda9950.c: set MAX_RETRIES for errors only
On Thu, Sep 13, 2018 at 03:33:20PM +0200, Hans Verkuil wrote: > On 09/13/18 15:16, Daniel Vetter wrote: > > On Thu, Sep 13, 2018 at 10:33:35AM +0100, Russell King - ARM Linux wrote: > >> Hi Hans, > >> > >> I'll pick it up in due course. > >> > >> Thanks. > >> > >> On Tue, Sep 11, 2018 at 08:41:59AM +0200, Hans Verkuil wrote: > >>> Russell (or someone else), can you Ack this patch? I'd like to get this > >>> for 4.20. > >>> > >>> Thanks! > >>> > >>> Hans > >>> > >>> On 08/27/2018 02:28 PM, Hans Verkuil wrote: > The CEC_TX_STATUS_MAX_RETRIES should be set for errors only to > prevent the CEC framework from retrying the transmit. If the > transmit was successful, then don't set this flag. > > Found by running 'cec-compliance -A' on a beaglebone box. > > Signed-off-by: Hans Verkuil > > > > Since the tda driver is now a brideg one, would make sense to maintain it > > as part of drm-misc? Hans could push directly then. > > It isn't yet part of drm-misc? It would make sense IMHO. I think not formally, drm/i2c isn't one of the drm-misc areas. But it does fall under "everything else" exception. And I'd be happy to ack a formal MAINTAINERS patch (plus maybe even moving it from drm/i2c/ to drm/bridge/). > And 'due course' is too vague since this should be merged for 4.20. > I plan to add BeagleBone Black support soon for 4.20 since the GPIO issues > that blocked supporting that board are close to being resolved. And this > should be fixed before enabling BBB support. > > It's an annoying bug that trips up the cec-compliance adapter test. Acked-by: Daniel Vetter for stuffing right away into drm-misc-next, if that helps. -Daniel > > Regards, > > Hans > > > -Daniel > > > --- > drivers/gpu/drm/i2c/tda9950.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i2c/tda9950.c > b/drivers/gpu/drm/i2c/tda9950.c > index 5d2f0d548469..4a14fc3b5011 100644 > --- a/drivers/gpu/drm/i2c/tda9950.c > +++ b/drivers/gpu/drm/i2c/tda9950.c > @@ -191,7 +191,8 @@ static irqreturn_t tda9950_irq(int irq, void *data) > break; > } > /* TDA9950 executes all retries for us */ > -tx_status |= CEC_TX_STATUS_MAX_RETRIES; > +if (tx_status != CEC_TX_STATUS_OK) > +tx_status |= CEC_TX_STATUS_MAX_RETRIES; > cec_transmit_done(priv->adap, tx_status, arb_lost_cnt, > nack_cnt, 0, err_cnt); > break; > > >>> > >> > >> -- > >> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ > >> FTTC broadband for 0.8mile line in suburbia: sync at 13.8Mbps down 630kbps > >> up > >> According to speedtest.net: 13Mbps down 490kbps up > >> ___ > >> dri-devel mailing list > >> dri-devel@lists.freedesktop.org > >> https://lists.freedesktop.org/mailman/listinfo/dri-devel > > > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 02/24] drivers/video/fbdev: use ioremap_wc/wt() instead of __ioremap()
On Wed, Sep 12, 2018 at 03:58:17PM +, Christophe Leroy wrote:
> _PAGE_NO_CACHE is a platform specific flag. In addition, this flag
> is misleading because one would think it requests a noncached page
> whereas a noncached page is _PAGE_NO_CACHE | _PAGE_GUARDED
>
> _PAGE_NO_CACHE alone means write combined noncached page, so lets
> use ioremap_wc() instead.
>
> _PAGE_WRITETHRU is also platform specific flag. Use ioremap_wt()
> instead.
>
> Signed-off-by: Christophe Leroy
I wondered why this all showed up in my gfx inbox, then spotted this patch
here.
I trust you way more on the _PAGE_ flags than me, but this looks
reasonable.
Acked-by: Daniel Vetter
> ---
> drivers/video/fbdev/chipsfb.c| 3 +--
> drivers/video/fbdev/controlfb.c | 5 +
> drivers/video/fbdev/platinumfb.c | 5 +
> drivers/video/fbdev/valkyriefb.c | 12 ++--
> 4 files changed, 9 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/video/fbdev/chipsfb.c b/drivers/video/fbdev/chipsfb.c
> index f103665cad43..40182ed85648 100644
> --- a/drivers/video/fbdev/chipsfb.c
> +++ b/drivers/video/fbdev/chipsfb.c
> @@ -27,7 +27,6 @@
> #include
> #include
> #include
> -#include
>
> #ifdef CONFIG_PMAC_BACKLIGHT
> #include
> @@ -401,7 +400,7 @@ static int chipsfb_pci_init(struct pci_dev *dp, const
> struct pci_device_id *ent)
> #endif /* CONFIG_PMAC_BACKLIGHT */
>
> #ifdef CONFIG_PPC
> - p->screen_base = __ioremap(addr, 0x20, _PAGE_NO_CACHE);
> + p->screen_base = ioremap_wc(addr, 0x20);
> #else
> p->screen_base = ioremap(addr, 0x20);
> #endif
> diff --git a/drivers/video/fbdev/controlfb.c b/drivers/video/fbdev/controlfb.c
> index 8d14b29aafea..9cb0ef7ac29e 100644
> --- a/drivers/video/fbdev/controlfb.c
> +++ b/drivers/video/fbdev/controlfb.c
> @@ -48,9 +48,7 @@
> #include
> #include
> #include
> -#include
> #include
> -#include
> #include
>
> #include "macmodes.h"
> @@ -715,8 +713,7 @@ static int __init control_of_init(struct device_node *dp)
> goto error_out;
> }
> /* map at most 8MB for the frame buffer */
> - p->frame_buffer = __ioremap(p->frame_buffer_phys, 0x80,
> - _PAGE_WRITETHRU);
> + p->frame_buffer = ioremap_wt(p->frame_buffer_phys, 0x80);
>
> if (!p->control_regs_phys ||
> !request_mem_region(p->control_regs_phys, p->control_regs_size,
> diff --git a/drivers/video/fbdev/platinumfb.c
> b/drivers/video/fbdev/platinumfb.c
> index 377d3399a3ad..bf6b7fb83cf4 100644
> --- a/drivers/video/fbdev/platinumfb.c
> +++ b/drivers/video/fbdev/platinumfb.c
> @@ -32,9 +32,7 @@
> #include
> #include
> #include
> -#include
> #include
> -#include
>
> #include "macmodes.h"
> #include "platinumfb.h"
> @@ -577,8 +575,7 @@ static int platinumfb_probe(struct platform_device* odev)
>
> /* frame buffer - map only 4MB */
> pinfo->frame_buffer_phys = pinfo->rsrc_fb.start;
> - pinfo->frame_buffer = __ioremap(pinfo->rsrc_fb.start, 0x40,
> - _PAGE_WRITETHRU);
> + pinfo->frame_buffer = ioremap_wt(pinfo->rsrc_fb.start, 0x40);
> pinfo->base_frame_buffer = pinfo->frame_buffer;
>
> /* registers */
> diff --git a/drivers/video/fbdev/valkyriefb.c
> b/drivers/video/fbdev/valkyriefb.c
> index 275fb98236d3..d51c3a8009cb 100644
> --- a/drivers/video/fbdev/valkyriefb.c
> +++ b/drivers/video/fbdev/valkyriefb.c
> @@ -54,13 +54,11 @@
> #include
> #include
> #include
> -#include
> #ifdef CONFIG_MAC
> #include
> #else
> #include
> #endif
> -#include
>
> #include "macmodes.h"
> #include "valkyriefb.h"
> @@ -318,7 +316,7 @@ static void __init valkyrie_choose_mode(struct
> fb_info_valkyrie *p)
> int __init valkyriefb_init(void)
> {
> struct fb_info_valkyrie *p;
> - unsigned long frame_buffer_phys, cmap_regs_phys, flags;
> + unsigned long frame_buffer_phys, cmap_regs_phys;
> int err;
> char *option = NULL;
>
> @@ -337,7 +335,6 @@ int __init valkyriefb_init(void)
> /* Hardcoded addresses... welcome to 68k Macintosh country :-) */
> frame_buffer_phys = 0xf900;
> cmap_regs_phys = 0x50f24000;
> - flags = IOMAP_NOCACHE_SER; /* IOMAP_WRITETHROUGH?? */
> #else /* ppc (!CONFIG_MAC) */
> {
> struct device_node *dp;
> @@ -354,7 +351,6 @@ int __init valkyriefb_init(void)
>
> frame_buffer_phys = r.start;
> cmap_regs_phys = r.start + 0x304000;
> - flags = _PAGE_WRITETHRU;
> }
> #endif /* ppc (!CONFIG_MAC) */
>
> @@ -369,7 +365,11 @@ int __init valkyriefb_init(void)
> }
> p->total_vram = 0x10;
> p->frame_buffer_phys = frame_buffer_phys;
> - p->frame_buffer = __ioremap(frame_buffer_phys, p->total_vram, flags);
> +#ifdef CONFIG_MAC
> + p->frame_buffer = ioremap_nocache(frame_buffer_phys, p->total_vram);
> +#else
> + p->frame_buffer =
Re: [PATCH] drm/i2c/tda9950.c: set MAX_RETRIES for errors only
On 09/13/18 15:16, Daniel Vetter wrote: > On Thu, Sep 13, 2018 at 10:33:35AM +0100, Russell King - ARM Linux wrote: >> Hi Hans, >> >> I'll pick it up in due course. >> >> Thanks. >> >> On Tue, Sep 11, 2018 at 08:41:59AM +0200, Hans Verkuil wrote: >>> Russell (or someone else), can you Ack this patch? I'd like to get this >>> for 4.20. >>> >>> Thanks! >>> >>> Hans >>> >>> On 08/27/2018 02:28 PM, Hans Verkuil wrote: The CEC_TX_STATUS_MAX_RETRIES should be set for errors only to prevent the CEC framework from retrying the transmit. If the transmit was successful, then don't set this flag. Found by running 'cec-compliance -A' on a beaglebone box. Signed-off-by: Hans Verkuil > > Since the tda driver is now a brideg one, would make sense to maintain it > as part of drm-misc? Hans could push directly then. It isn't yet part of drm-misc? It would make sense IMHO. And 'due course' is too vague since this should be merged for 4.20. I plan to add BeagleBone Black support soon for 4.20 since the GPIO issues that blocked supporting that board are close to being resolved. And this should be fixed before enabling BBB support. It's an annoying bug that trips up the cec-compliance adapter test. Regards, Hans > -Daniel > --- drivers/gpu/drm/i2c/tda9950.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i2c/tda9950.c b/drivers/gpu/drm/i2c/tda9950.c index 5d2f0d548469..4a14fc3b5011 100644 --- a/drivers/gpu/drm/i2c/tda9950.c +++ b/drivers/gpu/drm/i2c/tda9950.c @@ -191,7 +191,8 @@ static irqreturn_t tda9950_irq(int irq, void *data) break; } /* TDA9950 executes all retries for us */ - tx_status |= CEC_TX_STATUS_MAX_RETRIES; + if (tx_status != CEC_TX_STATUS_OK) + tx_status |= CEC_TX_STATUS_MAX_RETRIES; cec_transmit_done(priv->adap, tx_status, arb_lost_cnt, nack_cnt, 0, err_cnt); break; >>> >> >> -- >> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ >> FTTC broadband for 0.8mile line in suburbia: sync at 13.8Mbps down 630kbps up >> According to speedtest.net: 13Mbps down 490kbps up >> ___ >> dri-devel mailing list >> dri-devel@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/dri-devel > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] drm: Differentiate the lack of an interface from invalid parameter
On Wed, Sep 12, 2018 at 10:29:42AM +0100, Chris Wilson wrote:
> If the ioctl is not supported on a particular piece of HW/driver
> combination, report ENOTSUPP so that it can be easily distinguished from
> both the lack of the ioctl and from a regular invalid parameter.
>
> v2: Across all the kms ioctls we had a mixture of reporting EINVAL,
> ENODEV and a few ENOTSUPP (most where EINVAL) for a failed
> drm_core_check_feature(). Update everybody to report ENOTSUPP.
>
> Signed-off-by: Chris Wilson
> Cc: Daniel Vetter
> Cc: Ville Syrjälä
I think there's a few somewhat questionable ones among the legacy
functions (not sure we should throw an ENOTSUPP when it's only called by
driver code, not userspace, WARN_ON feels more appropriate).
But I only spotted that for legacy functionality, nothing we'll ever care
about. Ang sprinkling this all over definitely increases the odds that
it'll be adopted successfully.
As-is:
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_atomic_uapi.c | 2 +-
> drivers/gpu/drm/drm_bufs.c| 32 +++
> drivers/gpu/drm/drm_color_mgmt.c | 4 ++--
> drivers/gpu/drm/drm_connector.c | 2 +-
> drivers/gpu/drm/drm_context.c | 16
> drivers/gpu/drm/drm_crtc.c| 4 ++--
> drivers/gpu/drm/drm_encoder.c | 2 +-
> drivers/gpu/drm/drm_framebuffer.c | 13 -
> drivers/gpu/drm/drm_gem.c | 6 +++---
> drivers/gpu/drm/drm_ioctl.c | 2 +-
> drivers/gpu/drm/drm_irq.c | 4 ++--
> drivers/gpu/drm/drm_lease.c | 8
> drivers/gpu/drm/drm_lock.c| 4 ++--
> drivers/gpu/drm/drm_mode_config.c | 2 +-
> drivers/gpu/drm/drm_mode_object.c | 4 ++--
> drivers/gpu/drm/drm_pci.c | 4 ++--
> drivers/gpu/drm/drm_plane.c | 10 +-
> drivers/gpu/drm/drm_prime.c | 4 ++--
> drivers/gpu/drm/drm_property.c| 8
> drivers/gpu/drm/drm_scatter.c | 8
> drivers/gpu/drm/drm_syncobj.c | 14 +++---
> drivers/gpu/drm/drm_vblank.c | 4 ++--
> 22 files changed, 80 insertions(+), 77 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index 26690a664ec6..dc4502464126 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -1251,7 +1251,7 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
>
> /* disallow for drivers not supporting atomic: */
> if (!drm_core_check_feature(dev, DRIVER_ATOMIC))
> - return -EINVAL;
> + return -ENOTSUPP;
>
> /* disallow for userspace that has not enabled atomic cap (even
>* though this may be a bit overkill, since legacy userspace
> diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
> index ba8cfe65c65b..a07e7a781d64 100644
> --- a/drivers/gpu/drm/drm_bufs.c
> +++ b/drivers/gpu/drm/drm_bufs.c
> @@ -398,7 +398,7 @@ int drm_legacy_addmap_ioctl(struct drm_device *dev, void
> *data,
>
> if (!drm_core_check_feature(dev, DRIVER_KMS_LEGACY_CONTEXT) &&
> !drm_core_check_feature(dev, DRIVER_LEGACY))
> - return -EINVAL;
> + return -ENOTSUPP;
>
> err = drm_addmap_core(dev, map->offset, map->size, map->type,
> map->flags, );
> @@ -444,7 +444,7 @@ int drm_legacy_getmap_ioctl(struct drm_device *dev, void
> *data,
>
> if (!drm_core_check_feature(dev, DRIVER_KMS_LEGACY_CONTEXT) &&
> !drm_core_check_feature(dev, DRIVER_LEGACY))
> - return -EINVAL;
> + return -ENOTSUPP;
>
> idx = map->offset;
> if (idx < 0)
> @@ -596,7 +596,7 @@ int drm_legacy_rmmap_ioctl(struct drm_device *dev, void
> *data,
>
> if (!drm_core_check_feature(dev, DRIVER_KMS_LEGACY_CONTEXT) &&
> !drm_core_check_feature(dev, DRIVER_LEGACY))
> - return -EINVAL;
> + return -ENOTSUPP;
>
> mutex_lock(>struct_mutex);
> list_for_each_entry(r_list, >maplist, head) {
> @@ -860,7 +860,7 @@ int drm_legacy_addbufs_pci(struct drm_device *dev,
> struct drm_buf **temp_buflist;
>
> if (!drm_core_check_feature(dev, DRIVER_PCI_DMA))
> - return -EINVAL;
> + return -ENOTSUPP;
>
> if (!dma)
> return -EINVAL;
> @@ -1064,7 +1064,7 @@ static int drm_legacy_addbufs_sg(struct drm_device *dev,
> struct drm_buf **temp_buflist;
>
> if (!drm_core_check_feature(dev, DRIVER_SG))
> - return -EINVAL;
> + return -ENOTSUPP;
>
> if (!dma)
> return -EINVAL;
> @@ -1221,10 +1221,10 @@ int drm_legacy_addbufs(struct drm_device *dev, void
> *data,
> int ret;
>
> if (!drm_core_check_feature(dev, DRIVER_LEGACY))
> - return -EINVAL;
> + return -ENOTSUPP;
>
> if (!drm_core_check_feature(dev, DRIVER_HAVE_DMA))
> - return -EINVAL;
> + return
Re: [PATCH 2/2] drm/i915: Clear DRIVER_ATOMIC on a per-device basis
Quoting Ville Syrjala (2018-09-13 14:16:22) > From: Ville Syrjälä > > Currently we're clearing DRIVER_ATOMIC in driver.driver_features > for older platforms. This will not work correctly should we ever > have a system with and old and new GPU in it. While that is not > possible currently let's make the code more correct and use > the per-device driver_features instead. > > Cc: Chris Wilson > Signed-off-by: Ville Syrjälä One day we will be able to have driver const again, Reviewed-by: Chris Wilson -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm: Introduce per-device driver_features
Quoting Ville Syrjala (2018-09-13 14:16:21) > From: Ville Syrjälä > > We wish to control certain driver_features flags on a per-device basis > while still sharing a single drm_driver instance across all the > devices. To that end introduce device.driver_features. By default > it will be set to ~0 to not impose any limits beyond > driver.driver_features. Drivers can then clear specific flags > in the per-device bitmask to limit the capabilities of the device. > > An alternative approach would be to copy the driver_features from > the driver into the device in drm_dev_init(), however that would > require verifying that no driver is currently changing > driver.driver_features after drm_dev_init(). Hence the ~0 apporach > was easier. > > Ideally we'd also make drm_driver const but there is plenty of code > left that wants to mutate it (eg. various vfunc assignments). We'll > need to fix all that up before we can make it const. > > And while at it fix up the type of the feature flag passed to > drm_core_check_feature(). > > v2: Streamline the && vs. & (Chris) > s/int/u32/ in drm_core_check_feature() args > > Cc: Chris Wilson > Signed-off-by: Ville Syrjälä The gradual transition makes sense (less work!), as does being able to deselect features on individual devices. Reviewed-by: Chris Wilson -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 05/20] drm/meson: Use drm_fbdev_generic_setup()
On Wed, Sep 12, 2018 at 01:06:07PM +0200, Noralf Trønnes wrote: > > Den 12.09.2018 12.57, skrev Noralf Trønnes: > > (Cc: Daniel Vetter) > > > > Somehow that CC was dropped somewhere after leaving email client. > Trying once more. Yeah I just made myself unpopular. If you want SMEM_START, then you need to carry a local patch now. virt_to_pfn on the vmap should work. It's about 2 lines, including the change to drop HIDE_SMEM_START. And if consensus is that hiding SMEM_START is not a nice idea, then I'm sure we can reintroduce it through some slightly unpretty backdoor, even with Noralf's generic code. So not really a good reason to reject the cleanup I think. -Daniel > > Den 12.09.2018 11.56, skrev Maxime Ripard: > > > On Wed, Sep 12, 2018 at 11:48:34AM +0200, Neil Armstrong wrote: > > > > Hi Noralf, > > > > > > > > On 08/09/2018 15:46, Noralf Trønnes wrote: > > > > > The CMA helper is already using the > > > > > drm_fb_helper_generic_probe part of > > > > > the generic fbdev emulation. This patch makes full use of the generic > > > > > fbdev emulation by using its drm_client callbacks. This means that > > > > > drm_mode_config_funcs->output_poll_changed and > > > > > drm_driver->lastclose are > > > > > now handled by the emulation code. Additionally fbdev > > > > > unregister happens > > > > > automatically on drm_dev_unregister(). > > > > > > > > > > The drm_fbdev_generic_setup() call is put after > > > > > drm_dev_register() in the > > > > > driver. This is done to highlight the fact that fbdev emulation is an > > > > > internal client that makes use of the driver, it is not part of the > > > > > driver as such. If fbdev setup fails, an error is printed, > > > > > but the driver > > > > > succeeds probing. > > > > I can't really ack/nack this move, on one side it's great to have a > > > > generic fbdev emulation instead of the old fbdev code, but on the > > > > other side the Amlogic platform (like allwinner, samsung, rockchip, > > > > ...) still relies on an Fbdev variant of the libMali that uses > > > > smem_start... > > > > > > > > I know it's dirty and fbdev based code should be legacy now, but I > > > > consider it like an user-space breakage... > > > > > > > > I'll be happy if ARM provided it's Mali vendors a Fbdev libMali that > > > > could use FBINFO_HIDE_SMEM_START and allocate BO's from the DRM > > > > driver, it won't be the case and it will never be the case until the > > > > Lima projects finalizes. > > > > > > > > So for me it's a no-go until Lima lands upstream in Linux *and* Mesa. > > > My feelings exactly. If the choice is between reducing the DRM driver > > > by a couple of dozens of lines or keeping the mali working, I'll pick > > > the latter, every single day. > > > > I don't know the reasoning for blocking smem_start other than what Daniel > > wrote in these commit messages: > > > > da6c7707caf3736c1cf968606bd97c07e79625d4 > > fbdev: Add FBINFO_HIDE_SMEM_START flag > > > > DRM drivers really, really, really don't want random userspace to > > share buffer behind it's back, bypassing the dma-buf buffer sharing > > machanism. For that reason we've ruthlessly rejected any IOCTL > > exposing the physical address of any graphics buffer. > > > > Unfortunately fbdev comes with that built-in. We could just set > > smem_start to 0, but that means we'd have to hand-roll our own fb_mmap > > implementation. For good reasons many drivers do that, but > > smem_start/length is still super convenient. > > > > Hence instead just stop the leak in the ioctl, to keep fb mmap working > > as-is. A second patch will set this flag for all drm drivers. > > > > > > 6be8f3bd2c78915a9f3a058a346ae93068d35c01 > > drm/fb: Stop leaking physical address > > > > For buffer sharing, use dma-buf instead. We can't set smem_start to 0 > > unconditionally since that's used by the fbdev mmap default > > implementation. And we have plenty of userspace which would like to > > keep that working. > > > > This might break legit userspace - if it does we need to look at a > > case-by-cases basis how to handle that. Worst case I expect overrides > > for only specific drivers, since anything remotely modern should be > > using dma-buf/prime now (which is about 7 years old now for DRM > > drivers). > > > > This issue was uncovered because Noralf's rework to implement a > > generic fb_probe also implements it's own fb_mmap callback. Which > > means smem_start didn't have to be set anymore, which blew up some > > blob in userspace rather badly. > > > > > > Noralf. > > > > ___ > > dri-devel mailing list > > dri-devel@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org
Re: [PATCH v3 16/23] v4l: fwnode: Initialise the V4L2 fwnode endpoints to zero
Hi Sakari, On Thu, Sep 13, 2018 at 01:19:12PM +0300, Sakari Ailus wrote: > On Thu, Sep 13, 2018 at 12:55:33PM +0300, Sakari Ailus wrote: > > Hi Jacopo, > > > > On Thu, Sep 13, 2018 at 11:46:14AM +0200, jacopo mondi wrote: > > > Hi Sakari, > > > > > > On Thu, Sep 13, 2018 at 12:29:35AM +0300, Sakari Ailus wrote: > > > > Initialise the V4L2 fwnode endpoints to zero in all drivers using > > > > v4l2_fwnode_endpoint_parse(). This prepares for setting default endpoint > > > > flags as well as the bus type. Setting bus type to zero will continue to > > > > guess the bus among the guessable set (parallel, Bt.656 and CSI-2 > > > > D-PHY). > > > > > > > > > > I've played around with this patch, trying to use defaults in the > > > renesas-ceu driver. > > > > > > This is the resulting patch, if you want I can send it as follow-up or > > > send it so that you can include it in your series if it's correct): > > > https://paste.debian.net/hidden/a7795d3e/ > > > > Looks nice; could you send it out to the list for review? > > > > The bus width default isn't specified in DT bindings; could you write a > > patch that defines it? > > Same for "pclk-sample". DT bindings do not document that; it should go to > the same patch. Actually it is 'wrong' to specify it in the default configuration in first place, as the interface does not support configuring the pixel clock edge on which to sample data. Same for data-shift, as the interface supports 8 or 16 bits only capture modes. I'll document bus_width restricting the accepted values to 8 and 16 and field-even-active as even if they're not actually implemented in the driver, they are configurable for the interface. Thanks j > > -- > Sakari Ailus > sakari.ai...@linux.intel.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/i915: Clear DRIVER_ATOMIC on a per-device basis
From: Ville Syrjälä Currently we're clearing DRIVER_ATOMIC in driver.driver_features for older platforms. This will not work correctly should we ever have a system with and old and new GPU in it. While that is not possible currently let's make the code more correct and use the per-device driver_features instead. Cc: Chris Wilson Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/i915_drv.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index 5dd7fc582e6f..2ddf8538cb47 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -1384,14 +1384,14 @@ int i915_driver_load(struct pci_dev *pdev, const struct pci_device_id *ent) struct drm_i915_private *dev_priv; int ret; - /* Enable nuclear pageflip on ILK+ */ - if (!i915_modparams.nuclear_pageflip && match_info->gen < 5) - driver.driver_features &= ~DRIVER_ATOMIC; - dev_priv = i915_driver_create(pdev, ent); if (!dev_priv) return -ENOMEM; + /* Disable nuclear pageflip by default on pre-ILK */ + if (!i915_modparams.nuclear_pageflip && match_info->gen < 5) + dev_priv->drm.driver_features &= ~DRIVER_ATOMIC; + ret = pci_enable_device(pdev); if (ret) goto out_fini; -- 2.16.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i2c/tda9950.c: set MAX_RETRIES for errors only
On Thu, Sep 13, 2018 at 10:33:35AM +0100, Russell King - ARM Linux wrote: > Hi Hans, > > I'll pick it up in due course. > > Thanks. > > On Tue, Sep 11, 2018 at 08:41:59AM +0200, Hans Verkuil wrote: > > Russell (or someone else), can you Ack this patch? I'd like to get this > > for 4.20. > > > > Thanks! > > > > Hans > > > > On 08/27/2018 02:28 PM, Hans Verkuil wrote: > > > The CEC_TX_STATUS_MAX_RETRIES should be set for errors only to > > > prevent the CEC framework from retrying the transmit. If the > > > transmit was successful, then don't set this flag. > > > > > > Found by running 'cec-compliance -A' on a beaglebone box. > > > > > > Signed-off-by: Hans Verkuil Since the tda driver is now a brideg one, would make sense to maintain it as part of drm-misc? Hans could push directly then. -Daniel > > > --- > > > drivers/gpu/drm/i2c/tda9950.c | 3 ++- > > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > > > diff --git a/drivers/gpu/drm/i2c/tda9950.c b/drivers/gpu/drm/i2c/tda9950.c > > > index 5d2f0d548469..4a14fc3b5011 100644 > > > --- a/drivers/gpu/drm/i2c/tda9950.c > > > +++ b/drivers/gpu/drm/i2c/tda9950.c > > > @@ -191,7 +191,8 @@ static irqreturn_t tda9950_irq(int irq, void *data) > > > break; > > > } > > > /* TDA9950 executes all retries for us */ > > > - tx_status |= CEC_TX_STATUS_MAX_RETRIES; > > > + if (tx_status != CEC_TX_STATUS_OK) > > > + tx_status |= CEC_TX_STATUS_MAX_RETRIES; > > > cec_transmit_done(priv->adap, tx_status, arb_lost_cnt, > > > nack_cnt, 0, err_cnt); > > > break; > > > > > > > -- > RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ > FTTC broadband for 0.8mile line in suburbia: sync at 13.8Mbps down 630kbps up > According to speedtest.net: 13Mbps down 490kbps up > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm: Introduce per-device driver_features
From: Ville Syrjälä
We wish to control certain driver_features flags on a per-device basis
while still sharing a single drm_driver instance across all the
devices. To that end introduce device.driver_features. By default
it will be set to ~0 to not impose any limits beyond
driver.driver_features. Drivers can then clear specific flags
in the per-device bitmask to limit the capabilities of the device.
An alternative approach would be to copy the driver_features from
the driver into the device in drm_dev_init(), however that would
require verifying that no driver is currently changing
driver.driver_features after drm_dev_init(). Hence the ~0 apporach
was easier.
Ideally we'd also make drm_driver const but there is plenty of code
left that wants to mutate it (eg. various vfunc assignments). We'll
need to fix all that up before we can make it const.
And while at it fix up the type of the feature flag passed to
drm_core_check_feature().
v2: Streamline the && vs. & (Chris)
s/int/u32/ in drm_core_check_feature() args
Cc: Chris Wilson
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_drv.c | 3 +++
include/drm/drm_device.h | 10 ++
include/drm/drm_drv.h | 8
3 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index ea4941da9b27..36e8e9cbec52 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -506,6 +506,9 @@ int drm_dev_init(struct drm_device *dev,
dev->dev = parent;
dev->driver = driver;
+ /* no per-device feature limits by default */
+ dev->driver_features = ~0u;
+
INIT_LIST_HEAD(>filelist);
INIT_LIST_HEAD(>filelist_internal);
INIT_LIST_HEAD(>clientlist);
diff --git a/include/drm/drm_device.h b/include/drm/drm_device.h
index f9c6e0e3aec7..42411b3ea0c8 100644
--- a/include/drm/drm_device.h
+++ b/include/drm/drm_device.h
@@ -45,6 +45,16 @@ struct drm_device {
/* currently active master for this device. Protected by master_mutex */
struct drm_master *master;
+ /**
+* @driver_features: per-device driver features
+*
+* Drivers can clear specific flags here to disallow
+* certain features on a per-device basis while still
+* sharing a single drm_driver instance across
+* all devices.
+*/
+ u32 driver_features;
+
/**
* @unplugged:
*
diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
index 23b9678137a6..8830e3de3a86 100644
--- a/include/drm/drm_drv.h
+++ b/include/drm/drm_drv.h
@@ -653,14 +653,14 @@ static inline bool drm_dev_is_unplugged(struct drm_device
*dev)
* @dev: DRM device to check
* @feature: feature flag
*
- * This checks @dev for driver features, see _driver.driver_features and
the
- * various DRIVER_\* flags.
+ * This checks @dev for driver features, see _driver.driver_features,
+ * _device.driver_features, and the various DRIVER_\* flags.
*
* Returns true if the @feature is supported, false otherwise.
*/
-static inline bool drm_core_check_feature(struct drm_device *dev, int feature)
+static inline bool drm_core_check_feature(struct drm_device *dev, u32 feature)
{
- return dev->driver->driver_features & feature;
+ return dev->driver->driver_features & dev->driver_features & feature;
}
/**
--
2.16.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-misc-next
Hi Dave, Coming to you from stormy North Carolina! It looks like Florence will wrap right around us, so hopefully no drm-misc service interruptions will occur in the next week :-) Quite a lot of activity this week, both in volume and UAPI. Two of the line items in UAPI section are functionality changes rather than new ioctls/declarations. So we'll keep a close eye out for regression reports. That's it, that's all. Please pull. drm-misc-next-2018-09-13: drm-misc-next for 4.20: UAPI Changes: - Add host endian variants for the most common formats (Gerd) - Fail ADDFB2 for big-endian drivers that don't advertise BE quirk (Gerd) - clear smem_start in fbdev for drm drivers to avoid leaking fb addr (Daniel) Cross-subsystem Changes: Core Changes: - fix drm_mode_addfb() on big endian machines (Gerd) - add timeline point to syncobj find+replace (Chunming) - more drmP.h removal effort (Daniel) - split uapi portions of drm_atomic.c into drm_atomic_uapi.c (Daniel) Driver Changes: - bochs: Convert open-coded portions to use helpers (Peter) - vkms: Add cursor support (Haneen) - udmabuf: Lots of fixups (mostly cosmetic afaict) (Gerd) - qxl: Convert to use fbdev helper (Peter) Cc: Gerd Hoffmann Cc: Chunming Zhou Cc: Daniel Vetter Cc: Peter Wu Cc: Haneen Mohammed Cheers, Sean The following changes since commit 3ee22b769fd761c98eeaceab49153c3eb7612821: drm/rockchip: rgb: add stub functions when rgb encoder is disabled (2018-09-05 15:43:14 -0400) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2018-09-13 for you to fetch changes up to 169cc4c7a14e988985c8833ddec2f3e897de2c28: drm: bridge: document bridge attach/detach imbalance (2018-09-13 11:28:12 +0200) drm-misc-next for 4.20: UAPI Changes: - Add host endian variants for the most common formats (Gerd) - Fail ADDFB2 for big-endian drivers that don't advertise BE quirk (Gerd) - clear smem_start in fbdev for drm drivers to avoid leaking fb addr (Daniel) Cross-subsystem Changes: Core Changes: - fix drm_mode_addfb() on big endian machines (Gerd) - add timeline point to syncobj find+replace (Chunming) - more drmP.h removal effort (Daniel) - split uapi portions of drm_atomic.c into drm_atomic_uapi.c (Daniel) Driver Changes: - bochs: Convert open-coded portions to use helpers (Peter) - vkms: Add cursor support (Haneen) - udmabuf: Lots of fixups (mostly cosmetic afaict) (Gerd) - qxl: Convert to use fbdev helper (Peter) Cc: Gerd Hoffmann Cc: Chunming Zhou Cc: Daniel Vetter Cc: Peter Wu Cc: Haneen Mohammed Alexandru Gheorghe (1): drm: Clarify DRM_MODE_REFLECT_X/Y documentation Chen-Yu Tsai (2): drm/sun4i: tcon: Pass drm_encoder * into sun4i_tcon0_mode_set_cpu drm/sun4i: tcon: Rename Dithering related register macros Chris Wilson (1): drm: Reject unknown legacy bpp and depth for drm_mode_addfb ioctl Chunming Zhou (4): drm: fix syncobj null_fence_enable_signaling drm: rename null fence to stub fence in syncobj v2 drm: expand drm_syncobj_find_fence to support timeline point v2 drm: expand replace_fence to support timeline point v2 Daniel Vetter (11): drm: Add drm/drm_util.h header file drm: Drop drmP.h from drm_connector.c drm: drop drmP.h include from drm_plane.c drm: drop drmP.h include from drm_crtc.c drm/atomic: trim driver interface/docs drm: Update todo.rst drm: extract drm_atomic_uapi.c fbdev: Drop FBINFO_CAN_FORCE_OUTPUT flag vt: Remove vc_panic_force_write fbdev: Add FBINFO_HIDE_SMEM_START flag drm/fb: Stop leaking physical address Gerd Hoffmann (17): drm: replace DRIVER_PREFER_XBGR_30BPP driver flag with mode_config quirk drm: byteorder: add DRM_FORMAT_HOST_* drm: do not mask out DRM_FORMAT_BIG_ENDIAN drm: fix drm_mode_addfb() on big endian machines. drm: refuse ADDFB2 ioctl for broken bigendian drivers udmabuf: sort headers, drop uapi/ path prefix udmabuf: improve map_udmabuf error handling udmabuf: use pgoff_t for pagecount udmabuf: constify udmabuf_ops udmabuf: constify udmabuf_create args udmabuf: add MEMFD_CREATE dependency udmabuf: rework limits udmabuf: improve udmabuf_create error handling udmabuf: use EBADFD in case we didn't got a memfd udmabuf: use ENOTTY for invalid ioctls udmabuf: drop WARN_ON() check. udmabuf: use sizeof(variable) instead of sizeof(type) Haneen Mohammed (4): drm/vkms: Add cursor plane support drm/vkms: Compute CRC with Cursor Plane drm/vkms: Enable/Disable cursor support with module option drm/vkms: Add kerneldoc entry Jonathan Liu (1): drm/sun4i: tcon: Add dithering support for RGB565/RGB666 LCD panels Marc Zyngier (2): drm/rockchip: Allow driver to be shutdown on
Re: [PATCH 04/16] drm: bridge: thc63: Restrict modes based on hardware operating frequency
On 04.09.2018 14:10, Laurent Pinchart wrote: > The THC63LVD1024 is restricted to a pixel clock frequency in the range > of 8 to 135 MHz. Implement the bridge .mode_valid() operation > accordingly. > > Signed-off-by: Laurent Pinchart Reviewed-by: Andrzej Hajda -- Regards Andrzej ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 0/5] drm: add support for Cadence MHDP DPI/DP bridge.
Am Dienstag, 28. August 2018, 12:24:43 CEST schrieb Damian Kos: > Hello! > > This is the series of patches that will add support for the Cadence's DPI/DP > bridge. Please note that this is a preliminary version of the driver and there > will be more patches in the future with updates, fixes and improvements. > Please keep that in mind when looking at FIXME/TODO/XXX comments. > > Initially, MHDP driver was developed as a DRM bridge driver and was planed to > be placed in drivers/gpu/drm/bridge/mhdp.c. However, there was already > a driver for Cadence's DP controller developed by RockChip, but that driver > uses the different DRM framework and looks like a part of a bigger system. > Both controllers (including firmware) are quite different internally > (MST/FEC/DSC support, link training done by driver, additional commands, IRQ's > etc.) but they have similar register map, except for Framer/Streamer (which is > noticeably different), so they appear similar. > > The following patches contain: > - Moving common code to drivers/gpu/drm/bridge/cdns-mhdp-common.* and > modifying it a bit (mostly new prefixes for functions and data types) so it > can be used by two, higher level, drivers. > - Modifying existing RockChip's DP driver to use the common code after changes > made to it (use the new cdns_mhdp_device structure and new function names). > - Modifying DRM helpers a bit. Some are required for new driver, some are > updates from DP 1.2 to 1.3 or 1.4. > - Adding documentation for device tree bindings. > - Adding preliminary Cadence DPI/DP bridge driver. > > Some of the things that will be added later on include (but are not limited > to): > - Support for Cadence SD0801 PHY (PHY's driver should be on the way by now) > - MST support > - DSC support > - FEC support > - HDCP support with te Kconfig issue in patch5 fixed, this series tested on rk3288 (analogix-dp) and rk3399 (analogix-dp + cadence-dp) Everything seems to work that worked before. Tested-by: Heiko Stuebner ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 5/5] drm/bridge: add preliminary driver for cadence dpi/dp bridge
Am Dienstag, 28. August 2018, 12:24:48 CEST schrieb Damian Kos:
> From: Quentin Schulz
>
> This patch finally adds the preliminary driver for Cadence MHDP DPI/DP bridge.
>
> Changes made in the low level driver (cdn-dp-reg.*):
> - moved it to from drivers/gpu/drm/rockchip to
> drivers/gpu/drm/bridge/cdns-mhdp-common.*
> - functions for sending/receiving commands are now public
> - added functions for reading registers and link training
> adjustment
>
> Changes made in RK's driver (cdn-dp-core.*):
> - Moved audio_info and audio_pdev fields from cdn_dp_device to
> cdns_mhdp_device structure.
>
> Signed-off-by: Damian Kos
> ---
> drivers/gpu/drm/bridge/Kconfig|9 +
> drivers/gpu/drm/bridge/Makefile |3 +
> .../cdns-mhdp-common.c} | 137 +-
> .../cdns-mhdp-common.h} | 21 +-
> drivers/gpu/drm/bridge/cdns-mhdp.c| 1308 +
> drivers/gpu/drm/rockchip/Kconfig |1 +
> drivers/gpu/drm/rockchip/Makefile |4 +-
> drivers/gpu/drm/rockchip/cdn-dp-core.c| 16 +-
> drivers/gpu/drm/rockchip/cdn-dp-core.h|4 +-
> 9 files changed, 1484 insertions(+), 19 deletions(-)
> rename drivers/gpu/drm/{rockchip/cdn-dp-reg.c => bridge/cdns-mhdp-common.c}
> (87%)
> rename drivers/gpu/drm/{rockchip/cdn-dp-reg.h => bridge/cdns-mhdp-common.h}
> (95%)
> create mode 100644 drivers/gpu/drm/bridge/cdns-mhdp.c
>
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index 9eeb8ef0b174..90a4810a8c96 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -35,6 +35,15 @@ config DRM_CDNS_DSI
> Support Cadence DPI to DSI bridge. This is an internal
> bridge and is meant to be directly embedded in a SoC.
>
> +config DRM_CDNS_MHDP
> + tristate "Cadence DPI/DP bridge"
> + select DRM_KMS_HELPER
> + select DRM_PANEL_BRIDGE
> + depends on OF
> + help
> + Support Cadence DPI to DP bridge. This is an internal
> + bridge and is meant to be directly embedded in a SoC.
> +
This ends up with a Kconfig error on my kernel, with:
scripts/kconfig/conf --oldconfig Kconfig
drivers/i2c/Kconfig:7:error: recursive dependency detected!
drivers/i2c/Kconfig:7: symbol I2C is selected by FB_DDC
drivers/video/fbdev/Kconfig:63: symbol FB_DDC depends on FB
drivers/video/fbdev/Kconfig:5: symbol FB is selected by DRM_KMS_FB_HELPER
drivers/gpu/drm/Kconfig:74: symbol DRM_KMS_FB_HELPER depends on
DRM_KMS_HELPER
drivers/gpu/drm/Kconfig:68: symbol DRM_KMS_HELPER is selected by
DRM_CDNS_MHDP
drivers/gpu/drm/bridge/Kconfig:38: symbol DRM_CDNS_MHDP is selected by
ROCKCHIP_CDN_DP
drivers/gpu/drm/rockchip/Kconfig:29:symbol ROCKCHIP_CDN_DP depends on EXTCON
drivers/extcon/Kconfig:1: symbol EXTCON is selected by CHARGER_MANAGER
drivers/power/supply/Kconfig:467: symbol CHARGER_MANAGER depends on
POWER_SUPPLY
drivers/power/supply/Kconfig:1: symbol POWER_SUPPLY is selected by
HID_BATTERY_STRENGTH
drivers/hid/Kconfig:28: symbol HID_BATTERY_STRENGTH depends on HID
drivers/hid/Kconfig:7: symbol HID is selected by I2C_HID
drivers/hid/i2c-hid/Kconfig:4: symbol I2C_HID depends on I2C
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
The culprit being the dependency on EXTCON in the Rockchip cdn-dp driver.
Moving to "select EXTCON" seems to fix the issue, but I'm not sure yet if that
is the correct solution.
Heiko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH -fixes 5/5] drm/vmwgfx: Fix a buffer object eviction regression
Commit 4eb085e42fde ("drm/vmwgfx: Convert to new IDA API") indroduced
an incorrect return value from the function vmw_gmrid_man_get_node(),
when we run out if integer ids. Instead of returning 0 (meaning
non-fatal error) we forward the ida_simple_get error code -ENOSPC.
This causes TTM not to retry allocation after buffer eviction and
instead return -ENOSPC to user-space.
Fix this by returning 0 when ida_simple_get() returns -ENOSPC.
Tested using glretrace.
Cc: Matthew Wilcox
Signed-off-by: Thomas Hellstrom
Reviewed-by: Charmaine Lee
Reviewed-by: Deepak Rawat
---
drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c
index b93c558dd86e..a38a0c3777f7 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c
@@ -57,7 +57,7 @@ static int vmw_gmrid_man_get_node(struct ttm_mem_type_manager
*man,
id = ida_alloc_max(>gmr_ida, gman->max_gmr_ids - 1, GFP_KERNEL);
if (id < 0)
- return id;
+ return (id == -ENOSPC ? 0 : id);
spin_lock(>lock);
--
2.19.0.rc1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH -fixes 4/5] drm/vmwgfx: Don't impose STDU limits on framebuffer size
From: Deepak Rawat
If framebuffers are larger, we create bounce surfaces that are within
STDU limits.
Signed-off-by: Deepak Rawat
Reviewed-by: Thomas Hellstrom
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c| 25 -
drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 24 ++--
2 files changed, 14 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
index 93f6b96ca7bb..f30e839f7bfd 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
@@ -1600,31 +1600,6 @@ int vmw_kms_stdu_init_display(struct vmw_private
*dev_priv)
dev_priv->active_display_unit = vmw_du_screen_target;
- if (dev_priv->capabilities & SVGA_CAP_3D) {
- /*
-* For 3D VMs, display (scanout) buffer size is the smaller of
-* max texture and max STDU
-*/
- uint32_t max_width, max_height;
-
- max_width = min(dev_priv->texture_max_width,
- dev_priv->stdu_max_width);
- max_height = min(dev_priv->texture_max_height,
-dev_priv->stdu_max_height);
-
- dev->mode_config.max_width = max_width;
- dev->mode_config.max_height = max_height;
- } else {
- /*
-* Given various display aspect ratios, there's no way to
-* estimate these using prim_bb_mem. So just set these to
-* something arbitrarily large and we will reject any layout
-* that doesn't fit prim_bb_mem later
-*/
- dev->mode_config.max_width = 8192;
- dev->mode_config.max_height = 8192;
- }
-
vmw_kms_create_implicit_placement_property(dev_priv, false);
for (i = 0; i < VMWGFX_NUM_DISPLAY_UNITS; ++i) {
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
index e125233e074b..80a01cd4c051 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
@@ -1404,22 +1404,17 @@ int vmw_surface_gb_priv_define(struct drm_device *dev,
*srf_out = NULL;
if (for_scanout) {
- uint32_t max_width, max_height;
-
if (!svga3dsurface_is_screen_target_format(format)) {
DRM_ERROR("Invalid Screen Target surface format.");
return -EINVAL;
}
- max_width = min(dev_priv->texture_max_width,
- dev_priv->stdu_max_width);
- max_height = min(dev_priv->texture_max_height,
-dev_priv->stdu_max_height);
-
- if (size.width > max_width || size.height > max_height) {
+ if (size.width > dev_priv->texture_max_width ||
+ size.height > dev_priv->texture_max_height) {
DRM_ERROR("%ux%u\n, exceeds max surface size %ux%u",
size.width, size.height,
- max_width, max_height);
+ dev_priv->texture_max_width,
+ dev_priv->texture_max_height);
return -EINVAL;
}
} else {
@@ -1495,8 +1490,17 @@ int vmw_surface_gb_priv_define(struct drm_device *dev,
if (srf->flags & SVGA3D_SURFACE_BIND_STREAM_OUTPUT)
srf->res.backup_size += sizeof(SVGA3dDXSOState);
+ /*
+* Don't set SVGA3D_SURFACE_SCREENTARGET flag for a scanout surface with
+* size greater than STDU max width/height. This is really a workaround
+* to support creation of big framebuffer requested by some user-space
+* for whole topology. That big framebuffer won't really be used for
+* binding with screen target as during prepare_fb a separate surface is
+* created so it's safe to ignore SVGA3D_SURFACE_SCREENTARGET flag.
+*/
if (dev_priv->active_display_unit == vmw_du_screen_target &&
- for_scanout)
+ for_scanout && size.width <= dev_priv->stdu_max_width &&
+ size.height <= dev_priv->stdu_max_height)
srf->flags |= SVGA3D_SURFACE_SCREENTARGET;
/*
--
2.19.0.rc1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH -fixes 3/5] drm/vmwgfx: limit mode size for all display unit to texture_max
From: Deepak Rawat
For all display units, limit mode size exposed to texture_max_width/
height as this is the maximum framebuffer size that virtual device can
create.
Signed-off-by: Deepak Rawat
Reviewed-by: Sinclair Yeh
Reviewed-by: Thomas Hellstrom
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index 12a41b039167..6a712a8d59e9 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -2214,12 +2214,16 @@ int vmw_du_connector_fill_modes(struct drm_connector
*connector,
if (dev_priv->assume_16bpp)
assumed_bpp = 2;
+ max_width = min(max_width, dev_priv->texture_max_width);
+ max_height = min(max_height, dev_priv->texture_max_height);
+
+ /*
+* For STDU extra limit for a mode on SVGA_REG_SCREENTARGET_MAX_WIDTH/
+* HEIGHT registers.
+*/
if (dev_priv->active_display_unit == vmw_du_screen_target) {
max_width = min(max_width, dev_priv->stdu_max_width);
- max_width = min(max_width, dev_priv->texture_max_width);
-
max_height = min(max_height, dev_priv->stdu_max_height);
- max_height = min(max_height, dev_priv->texture_max_height);
}
/* Add preferred mode */
--
2.19.0.rc1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH -fixes 1/5] drm/vmwgfx: don't check for old_crtc_state enable status
From: Deepak Rawat
During atomic check to prepare the new topology no need to check if
old_crtc_state was enabled or not. This will cause atomic_check to fail
because due to connector routing a crtc can be in atomic_state even if
there was no change to enable status.
Detected this issue with igt run.
Signed-off-by: Deepak Rawat
Reviewed-by: Sinclair Yeh
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index 23beff5d8e3c..636b962849c8 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -1615,7 +1615,7 @@ static int vmw_kms_check_topology(struct drm_device *dev,
struct drm_connector_state *conn_state;
struct vmw_connector_state *vmw_conn_state;
- if (!new_crtc_state->enable && old_crtc_state->enable) {
+ if (!new_crtc_state->enable) {
rects[i].x1 = 0;
rects[i].y1 = 0;
rects[i].x2 = 0;
--
2.19.0.rc1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH -fixes 2/5] drm/vmwgfx: limit screen size to stdu_max during check_modeset
From: Deepak Rawat
For STDU individual screen target size is limited by
SVGA_REG_SCREENTARGET_MAX_WIDTH/HEIGHT registers so add that limit
during atomic check_modeset.
An additional limit is placed in the update_layout ioctl to avoid
requesting layouts that current user-space typically can't support.
Also modified the comments to reflect current limitation on topology.
Signed-off-by: Deepak Rawat
Reviewed-by: Sinclair Yeh
Reviewed-by: Thomas Hellstrom
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 30 +
1 file changed, 22 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index 636b962849c8..12a41b039167 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -1512,21 +1512,19 @@ static int vmw_kms_check_display_memory(struct
drm_device *dev,
struct drm_rect *rects)
{
struct vmw_private *dev_priv = vmw_priv(dev);
- struct drm_mode_config *mode_config = >mode_config;
struct drm_rect bounding_box = {0};
u64 total_pixels = 0, pixel_mem, bb_mem;
int i;
for (i = 0; i < num_rects; i++) {
/*
-* Currently this check is limiting the topology within max
-* texture/screentarget size. This should change in future when
-* user-space support multiple fb with topology.
+* For STDU only individual screen (screen target) is limited by
+* SCREENTARGET_MAX_WIDTH/HEIGHT registers.
*/
- if (rects[i].x1 < 0 || rects[i].y1 < 0 ||
- rects[i].x2 > mode_config->max_width ||
- rects[i].y2 > mode_config->max_height) {
- DRM_ERROR("Invalid GUI layout.\n");
+ if (dev_priv->active_display_unit == vmw_du_screen_target &&
+ (drm_rect_width([i]) > dev_priv->stdu_max_width ||
+drm_rect_height([i]) > dev_priv->stdu_max_height)) {
+ DRM_ERROR("Screen size not supported.\n");
return -EINVAL;
}
@@ -2376,6 +2374,7 @@ int vmw_kms_update_layout_ioctl(struct drm_device *dev,
void *data,
struct drm_file *file_priv)
{
struct vmw_private *dev_priv = vmw_priv(dev);
+ struct drm_mode_config *mode_config = >mode_config;
struct drm_vmw_update_layout_arg *arg =
(struct drm_vmw_update_layout_arg *)data;
void __user *user_rects;
@@ -2421,6 +2420,21 @@ int vmw_kms_update_layout_ioctl(struct drm_device *dev,
void *data,
drm_rects[i].y1 = curr_rect.y;
drm_rects[i].x2 = curr_rect.x + curr_rect.w;
drm_rects[i].y2 = curr_rect.y + curr_rect.h;
+
+ /*
+* Currently this check is limiting the topology within
+* mode_config->max (which actually is max texture size
+* supported by virtual device). This limit is here to address
+* window managers that create a big framebuffer for whole
+* topology.
+*/
+ if (drm_rects[i].x1 < 0 || drm_rects[i].y1 < 0 ||
+ drm_rects[i].x2 > mode_config->max_width ||
+ drm_rects[i].y2 > mode_config->max_height) {
+ DRM_ERROR("Invalid GUI layout.\n");
+ ret = -EINVAL;
+ goto out_free;
+ }
}
ret = vmw_kms_check_display_memory(dev, arg->num_outputs, drm_rects);
--
2.19.0.rc1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/5] hdmi.h: rename ADOBE_RGB to OPRGB and ADOBE_YCC to OPYCC
From: Hans Verkuil
These names have been renamed in the CTA-861 standard due to trademark
issues. Replace them here as well so they are in sync with the standard.
Signed-off-by: Hans Verkuil
---
drivers/media/i2c/adv7511.c | 4 ++--
drivers/media/v4l2-core/v4l2-dv-timings.c | 4 ++--
drivers/video/hdmi.c | 8
include/linux/hdmi.h | 4 ++--
4 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/media/i2c/adv7511.c b/drivers/media/i2c/adv7511.c
index a1f73d998495..f3899cc84e27 100644
--- a/drivers/media/i2c/adv7511.c
+++ b/drivers/media/i2c/adv7511.c
@@ -1357,8 +1357,8 @@ static int adv7511_set_fmt(struct v4l2_subdev *sd,
switch (format->format.colorspace) {
case V4L2_COLORSPACE_OPRGB:
c = HDMI_COLORIMETRY_EXTENDED;
- ec = y ? HDMI_EXTENDED_COLORIMETRY_ADOBE_YCC_601 :
-HDMI_EXTENDED_COLORIMETRY_ADOBE_RGB;
+ ec = y ? HDMI_EXTENDED_COLORIMETRY_OPYCC_601 :
+HDMI_EXTENDED_COLORIMETRY_OPRGB;
break;
case V4L2_COLORSPACE_SMPTE170M:
c = y ? HDMI_COLORIMETRY_ITU_601 : HDMI_COLORIMETRY_NONE;
diff --git a/drivers/media/v4l2-core/v4l2-dv-timings.c
b/drivers/media/v4l2-core/v4l2-dv-timings.c
index facd180870d9..4e4bfb33adbe 100644
--- a/drivers/media/v4l2-core/v4l2-dv-timings.c
+++ b/drivers/media/v4l2-core/v4l2-dv-timings.c
@@ -876,7 +876,7 @@ v4l2_hdmi_rx_colorimetry(const struct hdmi_avi_infoframe
*avi,
switch (avi->colorimetry) {
case HDMI_COLORIMETRY_EXTENDED:
switch (avi->extended_colorimetry) {
- case HDMI_EXTENDED_COLORIMETRY_ADOBE_RGB:
+ case HDMI_EXTENDED_COLORIMETRY_OPRGB:
c.colorspace = V4L2_COLORSPACE_OPRGB;
c.xfer_func = V4L2_XFER_FUNC_OPRGB;
break;
@@ -947,7 +947,7 @@ v4l2_hdmi_rx_colorimetry(const struct hdmi_avi_infoframe
*avi,
c.ycbcr_enc = V4L2_YCBCR_ENC_601;
c.xfer_func = V4L2_XFER_FUNC_SRGB;
break;
- case HDMI_EXTENDED_COLORIMETRY_ADOBE_YCC_601:
+ case HDMI_EXTENDED_COLORIMETRY_OPYCC_601:
c.colorspace = V4L2_COLORSPACE_OPRGB;
c.ycbcr_enc = V4L2_YCBCR_ENC_601;
c.xfer_func = V4L2_XFER_FUNC_OPRGB;
diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
index 38716eb50408..8a3e8f61b991 100644
--- a/drivers/video/hdmi.c
+++ b/drivers/video/hdmi.c
@@ -592,10 +592,10 @@ hdmi_extended_colorimetry_get_name(enum
hdmi_extended_colorimetry ext_col)
return "xvYCC 709";
case HDMI_EXTENDED_COLORIMETRY_S_YCC_601:
return "sYCC 601";
- case HDMI_EXTENDED_COLORIMETRY_ADOBE_YCC_601:
- return "Adobe YCC 601";
- case HDMI_EXTENDED_COLORIMETRY_ADOBE_RGB:
- return "Adobe RGB";
+ case HDMI_EXTENDED_COLORIMETRY_OPYCC_601:
+ return "opYCC 601";
+ case HDMI_EXTENDED_COLORIMETRY_OPRGB:
+ return "opRGB";
case HDMI_EXTENDED_COLORIMETRY_BT2020_CONST_LUM:
return "BT.2020 Constant Luminance";
case HDMI_EXTENDED_COLORIMETRY_BT2020:
diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
index d271ff23984f..4f3febc0f971 100644
--- a/include/linux/hdmi.h
+++ b/include/linux/hdmi.h
@@ -101,8 +101,8 @@ enum hdmi_extended_colorimetry {
HDMI_EXTENDED_COLORIMETRY_XV_YCC_601,
HDMI_EXTENDED_COLORIMETRY_XV_YCC_709,
HDMI_EXTENDED_COLORIMETRY_S_YCC_601,
- HDMI_EXTENDED_COLORIMETRY_ADOBE_YCC_601,
- HDMI_EXTENDED_COLORIMETRY_ADOBE_RGB,
+ HDMI_EXTENDED_COLORIMETRY_OPYCC_601,
+ HDMI_EXTENDED_COLORIMETRY_OPRGB,
/* The following EC values are only defined in CEA-861-F. */
HDMI_EXTENDED_COLORIMETRY_BT2020_CONST_LUM,
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/5] media colorspaces*.rst: rename AdobeRGB to opRGB
From: Hans Verkuil
Drop all Adobe references and use the official opRGB standard
instead.
Signed-off-by: Hans Verkuil
---
Documentation/media/uapi/v4l/biblio.rst | 10 --
Documentation/media/uapi/v4l/colorspaces-defs.rst | 8
.../media/uapi/v4l/colorspaces-details.rst | 13 ++---
3 files changed, 10 insertions(+), 21 deletions(-)
diff --git a/Documentation/media/uapi/v4l/biblio.rst
b/Documentation/media/uapi/v4l/biblio.rst
index 1cedcfc04327..386d6cf83e9c 100644
--- a/Documentation/media/uapi/v4l/biblio.rst
+++ b/Documentation/media/uapi/v4l/biblio.rst
@@ -226,16 +226,6 @@ xvYCC
:author:International Electrotechnical Commission (http://www.iec.ch)
-.. _adobergb:
-
-AdobeRGB
-
-
-
-:title: Adobe© RGB (1998) Color Image Encoding Version 2005-05
-
-:author:Adobe Systems Incorporated (http://www.adobe.com)
-
.. _oprgb:
opRGB
diff --git a/Documentation/media/uapi/v4l/colorspaces-defs.rst
b/Documentation/media/uapi/v4l/colorspaces-defs.rst
index 410907fe9415..f24615544792 100644
--- a/Documentation/media/uapi/v4l/colorspaces-defs.rst
+++ b/Documentation/media/uapi/v4l/colorspaces-defs.rst
@@ -51,8 +51,8 @@ whole range, 0-255, dividing the angular value by 1.41. The
enum
- See :ref:`col-rec709`.
* - ``V4L2_COLORSPACE_SRGB``
- See :ref:`col-srgb`.
-* - ``V4L2_COLORSPACE_ADOBERGB``
- - See :ref:`col-adobergb`.
+* - ``V4L2_COLORSPACE_OPRGB``
+ - See :ref:`col-oprgb`.
* - ``V4L2_COLORSPACE_BT2020``
- See :ref:`col-bt2020`.
* - ``V4L2_COLORSPACE_DCI_P3``
@@ -90,8 +90,8 @@ whole range, 0-255, dividing the angular value by 1.41. The
enum
- Use the Rec. 709 transfer function.
* - ``V4L2_XFER_FUNC_SRGB``
- Use the sRGB transfer function.
-* - ``V4L2_XFER_FUNC_ADOBERGB``
- - Use the AdobeRGB transfer function.
+* - ``V4L2_XFER_FUNC_OPRGB``
+ - Use the opRGB transfer function.
* - ``V4L2_XFER_FUNC_SMPTE240M``
- Use the SMPTE 240M transfer function.
* - ``V4L2_XFER_FUNC_NONE``
diff --git a/Documentation/media/uapi/v4l/colorspaces-details.rst
b/Documentation/media/uapi/v4l/colorspaces-details.rst
index b5d551b9cc8f..09fabf4cd412 100644
--- a/Documentation/media/uapi/v4l/colorspaces-details.rst
+++ b/Documentation/media/uapi/v4l/colorspaces-details.rst
@@ -290,15 +290,14 @@ Y' is clamped to the range [0…1] and Cb and Cr are
clamped to the range
170M/BT.601. The Y'CbCr quantization is limited range.
-.. _col-adobergb:
+.. _col-oprgb:
-Colorspace Adobe RGB (V4L2_COLORSPACE_ADOBERGB)
+Colorspace opRGB (V4L2_COLORSPACE_OPRGB)
===
-The :ref:`adobergb` standard defines the colorspace used by computer
-graphics that use the AdobeRGB colorspace. This is also known as the
-:ref:`oprgb` standard. The default transfer function is
-``V4L2_XFER_FUNC_ADOBERGB``. The default Y'CbCr encoding is
+The :ref:`oprgb` standard defines the colorspace used by computer
+graphics that use the opRGB colorspace. The default transfer function is
+``V4L2_XFER_FUNC_OPRGB``. The default Y'CbCr encoding is
``V4L2_YCBCR_ENC_601``. The default Y'CbCr quantization is limited
range.
@@ -312,7 +311,7 @@ The chromaticities of the primary colors and the white
reference are:
.. tabularcolumns:: |p{4.4cm}|p{4.4cm}|p{8.7cm}|
-.. flat-table:: Adobe RGB Chromaticities
+.. flat-table:: opRGB Chromaticities
:header-rows: 1
:stub-columns: 0
:widths: 1 1 2
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/5] media: replace ADOBERGB by OPRGB
From: Hans Verkuil
The CTA-861 standards have been updated to refer to opRGB instead
of AdobeRGB. The official standard is in fact named opRGB, so
switch to that.
The two old defines referring to ADOBERGB in the public API are
put under #ifndef __KERNEL__ and a comment mentions that they are
deprecated.
Signed-off-by: Hans Verkuil
---
.../media/videodev2.h.rst.exceptions | 2 +
.../media/common/v4l2-tpg/v4l2-tpg-colors.c | 262 +-
drivers/media/i2c/adv7511.c | 2 +-
drivers/media/i2c/adv7604.c | 2 +-
drivers/media/i2c/tc358743.c | 4 +-
drivers/media/platform/vivid/vivid-core.h | 2 +-
drivers/media/platform/vivid/vivid-ctrls.c| 6 +-
drivers/media/platform/vivid/vivid-vid-out.c | 2 +-
drivers/media/v4l2-core/v4l2-dv-timings.c | 8 +-
include/uapi/linux/videodev2.h| 16 +-
10 files changed, 158 insertions(+), 148 deletions(-)
diff --git a/Documentation/media/videodev2.h.rst.exceptions
b/Documentation/media/videodev2.h.rst.exceptions
index 63fa131729c0..fe6830584514 100644
--- a/Documentation/media/videodev2.h.rst.exceptions
+++ b/Documentation/media/videodev2.h.rst.exceptions
@@ -56,6 +56,7 @@ replace symbol V4L2_MEMORY_USERPTR :c:type:`v4l2_memory`
# Documented enum v4l2_colorspace
replace symbol V4L2_COLORSPACE_470_SYSTEM_BG :c:type:`v4l2_colorspace`
replace symbol V4L2_COLORSPACE_470_SYSTEM_M :c:type:`v4l2_colorspace`
+replace symbol V4L2_COLORSPACE_OPRGB :c:type:`v4l2_colorspace`
replace symbol V4L2_COLORSPACE_ADOBERGB :c:type:`v4l2_colorspace`
replace symbol V4L2_COLORSPACE_BT2020 :c:type:`v4l2_colorspace`
replace symbol V4L2_COLORSPACE_DCI_P3 :c:type:`v4l2_colorspace`
@@ -69,6 +70,7 @@ replace symbol V4L2_COLORSPACE_SRGB :c:type:`v4l2_colorspace`
# Documented enum v4l2_xfer_func
replace symbol V4L2_XFER_FUNC_709 :c:type:`v4l2_xfer_func`
+replace symbol V4L2_XFER_FUNC_OPRGB :c:type:`v4l2_xfer_func`
replace symbol V4L2_XFER_FUNC_ADOBERGB :c:type:`v4l2_xfer_func`
replace symbol V4L2_XFER_FUNC_DCI_P3 :c:type:`v4l2_xfer_func`
replace symbol V4L2_XFER_FUNC_DEFAULT :c:type:`v4l2_xfer_func`
diff --git a/drivers/media/common/v4l2-tpg/v4l2-tpg-colors.c
b/drivers/media/common/v4l2-tpg/v4l2-tpg-colors.c
index 3a3dc23c560c..a4341205c197 100644
--- a/drivers/media/common/v4l2-tpg/v4l2-tpg-colors.c
+++ b/drivers/media/common/v4l2-tpg/v4l2-tpg-colors.c
@@ -602,14 +602,14 @@ const struct tpg_rbg_color16
tpg_csc_colors[V4L2_COLORSPACE_DCI_P3 + 1][V4L2_XFE
[V4L2_COLORSPACE_SMPTE170M][V4L2_XFER_FUNC_SRGB][5] = { 3138, 657, 810
},
[V4L2_COLORSPACE_SMPTE170M][V4L2_XFER_FUNC_SRGB][6] = { 731, 680, 3048
},
[V4L2_COLORSPACE_SMPTE170M][V4L2_XFER_FUNC_SRGB][7] = { 800, 799, 800 },
- [V4L2_COLORSPACE_SMPTE170M][V4L2_XFER_FUNC_ADOBERGB][0] = { 3033, 3033,
3033 },
- [V4L2_COLORSPACE_SMPTE170M][V4L2_XFER_FUNC_ADOBERGB][1] = { 3046, 3054,
886 },
- [V4L2_COLORSPACE_SMPTE170M][V4L2_XFER_FUNC_ADOBERGB][2] = { 0, 3058,
3031 },
- [V4L2_COLORSPACE_SMPTE170M][V4L2_XFER_FUNC_ADOBERGB][3] = { 360, 3079,
877 },
- [V4L2_COLORSPACE_SMPTE170M][V4L2_XFER_FUNC_ADOBERGB][4] = { 3103, 587,
3027 },
- [V4L2_COLORSPACE_SMPTE170M][V4L2_XFER_FUNC_ADOBERGB][5] = { 3116, 723,
861 },
- [V4L2_COLORSPACE_SMPTE170M][V4L2_XFER_FUNC_ADOBERGB][6] = { 789, 744,
3025 },
- [V4L2_COLORSPACE_SMPTE170M][V4L2_XFER_FUNC_ADOBERGB][7] = { 851, 851,
851 },
+ [V4L2_COLORSPACE_SMPTE170M][V4L2_XFER_FUNC_OPRGB][0] = { 3033, 3033,
3033 },
+ [V4L2_COLORSPACE_SMPTE170M][V4L2_XFER_FUNC_OPRGB][1] = { 3046, 3054,
886 },
+ [V4L2_COLORSPACE_SMPTE170M][V4L2_XFER_FUNC_OPRGB][2] = { 0, 3058, 3031
},
+ [V4L2_COLORSPACE_SMPTE170M][V4L2_XFER_FUNC_OPRGB][3] = { 360, 3079, 877
},
+ [V4L2_COLORSPACE_SMPTE170M][V4L2_XFER_FUNC_OPRGB][4] = { 3103, 587,
3027 },
+ [V4L2_COLORSPACE_SMPTE170M][V4L2_XFER_FUNC_OPRGB][5] = { 3116, 723, 861
},
+ [V4L2_COLORSPACE_SMPTE170M][V4L2_XFER_FUNC_OPRGB][6] = { 789, 744, 3025
},
+ [V4L2_COLORSPACE_SMPTE170M][V4L2_XFER_FUNC_OPRGB][7] = { 851, 851, 851
},
[V4L2_COLORSPACE_SMPTE170M][V4L2_XFER_FUNC_SMPTE240M][0] = { 2926,
2926, 2926 },
[V4L2_COLORSPACE_SMPTE170M][V4L2_XFER_FUNC_SMPTE240M][1] = { 2941,
2950, 546 },
[V4L2_COLORSPACE_SMPTE170M][V4L2_XFER_FUNC_SMPTE240M][2] = { 0, 2954,
2924 },
@@ -658,14 +658,14 @@ const struct tpg_rbg_color16
tpg_csc_colors[V4L2_COLORSPACE_DCI_P3 + 1][V4L2_XFE
[V4L2_COLORSPACE_SMPTE240M][V4L2_XFER_FUNC_SRGB][5] = { 3138, 657, 810
},
[V4L2_COLORSPACE_SMPTE240M][V4L2_XFER_FUNC_SRGB][6] = { 731, 680, 3048
},
[V4L2_COLORSPACE_SMPTE240M][V4L2_XFER_FUNC_SRGB][7] = { 800, 799, 800 },
- [V4L2_COLORSPACE_SMPTE240M][V4L2_XFER_FUNC_ADOBERGB][0] = { 3033, 3033,
3033 },
- [V4L2_COLORSPACE_SMPTE240M][V4L2_XFER_FUNC_ADOBERGB][1] = { 3046, 3054,
886 },
-
[PATCH 5/5] drm/amd: rename ADOBE to OP
From: Hans Verkuil
The CTA-861 standard renamed ADOBE to OP, so do the same to remain
in sync with the standard.
Signed-off-by: Hans Verkuil
Cc: amd-...@lists.freedesktop.org
---
drivers/gpu/drm/amd/display/dc/core/dc_hw_sequencer.c | 4 ++--
drivers/gpu/drm/amd/display/dc/core/dc_resource.c | 4 ++--
drivers/gpu/drm/amd/display/dc/dc_hw_types.h| 2 +-
drivers/gpu/drm/amd/display/dc/dce/dce_stream_encoder.c | 2 +-
drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c | 2 +-
drivers/gpu/drm/amd/display/dc/dcn10/dcn10_stream_encoder.c | 2 +-
drivers/gpu/drm/amd/display/dc/inc/hw/transform.h | 4 ++--
7 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_hw_sequencer.c
b/drivers/gpu/drm/amd/display/dc/core/dc_hw_sequencer.c
index 83d121510ef5..c7709711d3c3 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_hw_sequencer.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_hw_sequencer.c
@@ -99,7 +99,7 @@ static bool is_rgb_type(
color_space == COLOR_SPACE_XR_RGB ||
color_space == COLOR_SPACE_MSREF_SCRGB ||
color_space == COLOR_SPACE_2020_RGB_FULLRANGE ||
- color_space == COLOR_SPACE_ADOBERGB ||
+ color_space == COLOR_SPACE_OPRGB||
color_space == COLOR_SPACE_DCIP3||
color_space == COLOR_SPACE_DOLBYVISION)
ret = true;
@@ -230,7 +230,7 @@ void color_space_to_black_color(
case COLOR_SPACE_XV_YCC_601:
case COLOR_SPACE_2020_RGB_FULLRANGE:
case COLOR_SPACE_2020_RGB_LIMITEDRANGE:
- case COLOR_SPACE_ADOBERGB:
+ case COLOR_SPACE_OPRGB:
case COLOR_SPACE_DCIP3:
case COLOR_SPACE_DISPLAYNATIVE:
case COLOR_SPACE_DOLBYVISION:
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
index ea6beccfd89d..2e454e905ee2 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
@@ -2151,8 +2151,8 @@ static void set_avi_info_frame(
color_space == COLOR_SPACE_2020_YCBCR) {
hdmi_info.bits.EC0_EC2 = COLORIMETRYEX_BT2020RGBYCBCR;
hdmi_info.bits.C0_C1 = COLORIMETRY_EXTENDED;
- } else if (color_space == COLOR_SPACE_ADOBERGB) {
- hdmi_info.bits.EC0_EC2 = COLORIMETRYEX_ADOBERGB;
+ } else if (color_space == COLOR_SPACE_OPRGB) {
+ hdmi_info.bits.EC0_EC2 = COLORIMETRYEX_OPRGB;
hdmi_info.bits.C0_C1 = COLORIMETRY_EXTENDED;
}
diff --git a/drivers/gpu/drm/amd/display/dc/dc_hw_types.h
b/drivers/gpu/drm/amd/display/dc/dc_hw_types.h
index b789cb2b354b..ddaaf17a3bc6 100644
--- a/drivers/gpu/drm/amd/display/dc/dc_hw_types.h
+++ b/drivers/gpu/drm/amd/display/dc/dc_hw_types.h
@@ -524,7 +524,7 @@ enum dc_color_space {
COLOR_SPACE_2020_RGB_FULLRANGE,
COLOR_SPACE_2020_RGB_LIMITEDRANGE,
COLOR_SPACE_2020_YCBCR,
- COLOR_SPACE_ADOBERGB,
+ COLOR_SPACE_OPRGB,
COLOR_SPACE_DCIP3,
COLOR_SPACE_DISPLAYNATIVE,
COLOR_SPACE_DOLBYVISION,
diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_stream_encoder.c
b/drivers/gpu/drm/amd/display/dc/dce/dce_stream_encoder.c
index 91642e684858..d37d7a20ef54 100644
--- a/drivers/gpu/drm/amd/display/dc/dce/dce_stream_encoder.c
+++ b/drivers/gpu/drm/amd/display/dc/dce/dce_stream_encoder.c
@@ -423,7 +423,7 @@ static void dce110_stream_encoder_dp_set_stream_attribute(
case COLOR_SPACE_2020_YCBCR:
case COLOR_SPACE_XR_RGB:
case COLOR_SPACE_MSREF_SCRGB:
- case COLOR_SPACE_ADOBERGB:
+ case COLOR_SPACE_OPRGB:
case COLOR_SPACE_DCIP3:
case COLOR_SPACE_XV_YCC_709:
case COLOR_SPACE_XV_YCC_601:
diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
index cfcc54f2ce65..99282c6c91c3 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
@@ -1729,7 +1729,7 @@ bool is_rgb_cspace(enum dc_color_space output_color_space)
case COLOR_SPACE_SRGB_LIMITED:
case COLOR_SPACE_2020_RGB_FULLRANGE:
case COLOR_SPACE_2020_RGB_LIMITEDRANGE:
- case COLOR_SPACE_ADOBERGB:
+ case COLOR_SPACE_OPRGB:
return true;
case COLOR_SPACE_YCBCR601:
case COLOR_SPACE_YCBCR709:
diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_stream_encoder.c
b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_stream_encoder.c
index 6f9078f3c4d3..17e5d287aca7 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_stream_encoder.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_stream_encoder.c
@@ -394,7 +394,7 @@
[PATCH 0/5] Rename AdobeRGB to opRGB
From: Hans Verkuil This patch series replaces all AdobeRGB references by opRGB references. In November last year all references to the AdobeRGB colorspace were removed from the CTA-861 standards (all versions) and replaced with the corresponding international opRGB standard (IEC 61966-2-5) due to trademark issues. This patch series makes the same change in the kernel because: 1) it makes sense to keep in sync with the CTA-861 standard, 2) using an international standard is always preferable to a company standard, 3) avoid possible future trademark complaints. The first two patches can go through the media subsystem. The third patch changes hdmi.c/h, but since the renamed defines from hdmi.h are only used in the media subsystem I would prefer to merge this via the media subsystem as well. So if I can get an Ack, then that would be great. The fourth patch I can push to drm-misc when it's reviewed, and the final patch can go through the AMD GPU maintainers. There are only two references to the old name left since they are part of the V4L2 public API, so I can't remove them. Regards, Hans Hans Verkuil (5): media: replace ADOBERGB by OPRGB media colorspaces*.rst: rename AdobeRGB to opRGB hdmi.h: rename ADOBE_RGB to OPRGB and ADOBE_YCC to OPYCC drm/bridge/synopsys/dw-hdmi.h: rename ADOBE to OP drm/amd: rename ADOBE to OP Documentation/media/uapi/v4l/biblio.rst | 10 - .../media/uapi/v4l/colorspaces-defs.rst | 8 +- .../media/uapi/v4l/colorspaces-details.rst| 13 +- .../media/videodev2.h.rst.exceptions | 2 + .../drm/amd/display/dc/core/dc_hw_sequencer.c | 4 +- .../gpu/drm/amd/display/dc/core/dc_resource.c | 4 +- drivers/gpu/drm/amd/display/dc/dc_hw_types.h | 2 +- .../amd/display/dc/dce/dce_stream_encoder.c | 2 +- .../amd/display/dc/dcn10/dcn10_hw_sequencer.c | 2 +- .../display/dc/dcn10/dcn10_stream_encoder.c | 2 +- .../gpu/drm/amd/display/dc/inc/hw/transform.h | 4 +- drivers/gpu/drm/bridge/synopsys/dw-hdmi.h | 4 +- .../media/common/v4l2-tpg/v4l2-tpg-colors.c | 262 +- drivers/media/i2c/adv7511.c | 6 +- drivers/media/i2c/adv7604.c | 2 +- drivers/media/i2c/tc358743.c | 4 +- drivers/media/platform/vivid/vivid-core.h | 2 +- drivers/media/platform/vivid/vivid-ctrls.c| 6 +- drivers/media/platform/vivid/vivid-vid-out.c | 2 +- drivers/media/v4l2-core/v4l2-dv-timings.c | 12 +- drivers/video/hdmi.c | 8 +- include/linux/hdmi.h | 4 +- include/uapi/linux/videodev2.h| 16 +- 23 files changed, 190 insertions(+), 191 deletions(-) -- 2.18.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/5] drm/bridge/synopsys/dw-hdmi.h: rename ADOBE to OP
From: Hans Verkuil
The CTA-861 standard renamed this from ADOBE to OP. Make the
same change to sync with the standard.
Signed-off-by: Hans Verkuil
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h
index 9d90eb9c46e5..56f37134d748 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h
@@ -791,8 +791,8 @@ enum {
HDMI_FC_AVICONF2_EXT_COLORIMETRY_XVYCC601 = 0x00,
HDMI_FC_AVICONF2_EXT_COLORIMETRY_XVYCC709 = 0x10,
HDMI_FC_AVICONF2_EXT_COLORIMETRY_SYCC601 = 0x20,
- HDMI_FC_AVICONF2_EXT_COLORIMETRY_ADOBE_YCC601 = 0x30,
- HDMI_FC_AVICONF2_EXT_COLORIMETRY_ADOBE_RGB = 0x40,
+ HDMI_FC_AVICONF2_EXT_COLORIMETRY_OPYCC601 = 0x30,
+ HDMI_FC_AVICONF2_EXT_COLORIMETRY_OPRGB = 0x40,
HDMI_FC_AVICONF2_IT_CONTENT_MASK = 0x80,
HDMI_FC_AVICONF2_IT_CONTENT_NO_DATA = 0x00,
HDMI_FC_AVICONF2_IT_CONTENT_VALID = 0x80,
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
