Re: [PATCH 1/6] drm/bridge: use bus flags in bridge timings
On 14.09.2018 02:49, Laurent Pinchart wrote: > Hi Stefan, > > On Thursday, 6 September 2018 23:25:56 EEST Stefan Agner wrote: >> On 06.09.2018 04:07, Linus Walleij wrote: >> > On Wed, Sep 5, 2018 at 8:32 PM Stefan Agner wrote: >> >> On 05.09.2018 00:44, Laurent Pinchart wrote: >> >> >> >> Good point! I actually really don't like that we use the same flags here >> >> but from a different perspective. Especially since the flags defines >> >> document things differently: >> >> >> >> /* drive data on pos. edge */ >> >> #define DRM_BUS_FLAG_PIXDATA_POSEDGE(1<<2) >> >> /* drive data on neg. edge */ >> >> #define DRM_BUS_FLAG_PIXDATA_NEGEDGE(1<<3) >> > >> > Maybe a stupid comment from my side, but can't we just change the >> > documentation to match the usecases? >> > >> > /* Trigger pixel data latch on positive edge */ >> > #define DRM_BUS_FLAG_PIXDATA_POSEDGE(1<<2) >> > >> >> Using the opposite perspective would also need translation in crtc >> >> drivers... So far no driver uses sampling_edge. >> >> >> >> I would prefer if we always use the meaning as documented by the flags. >> >> >> >> I guess we would need to convert DRM_BUS_FLAG_PIXDATA_POSEDGE -> >> >> DRM_BUS_FLAG_PIXDATA_NEGEDGE. >> >> >> >> Linus Walleij, you added sampling edge, any thoughts? >> > >> > I just thought it was generally useful to have triggering edge encoded >> > into the bridge as it makes it clear that this edge is something >> > that is a delayed version of the driving edge which is subject to >> > clock skew caused by the speed of electrons in silicon and >> > copper and slew rate caused by parasitic capacitance. >> >> Ok, I read a bit up on the history of bridge timing, especially: >> https://www.spinics.net/lists/dri-devel/msg155618.html >> >> IMHO, this got overengineered. For displays we do not need all that >> setup/sample delay timing information, and much longer cables are in >> use. So why is all that needed for bridges? >> >> For Linus case, the THS8134(A/B) data sheet I found (revised March 2010) >> clearly states: >> Clock input. A rising edge on CLK latches RPr0-7, GY0-7, BPb0-7. >> >> So we need to drive on negative edge, hence DRM_BUS_FLAG_PIXDATA_NEGEDGE >> should be used, which makes the pl111 driver setting TIM2_IPC: >> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0121d/index.h >> tml >> >> > DRM_BUS_FLAG_PIXDATA_POSEDGE is the right value for my use cases, but it >> > doesn't match how the ADV7123 operates. Using DRM_BUS_FLAG_PIXDATA_NEGEDGE >> > would match the hardware, but would break display for some modes, >> > depending on the display clock frequency as the internal 8.5ns output >> > delay applied to a falling clock edge would fall right into the 1.7ns >> > setup + hold time window of the ADV7123 around the rising edge. I can't >> > test this right now as I don't have local access to boards using the >> > ADV7123, but from a quick calculation that ignores the PCB transmission >> > delay modes with frequencies between 57MHz and 71MHz could break if the >> > data was output on the falling edge of the clock. >> >> If clocks vs. data signal are really that much off on R-Car DU, then >> parallel displays must have the very same issue... >> >> Are you sure that only the clock signal has an output delay? And that >> this output delay is a fixed value, clock independent? >> >> Typically, delays apply to all signals equally, and often are clock >> frequency dependent... >> >> Without really looking at the signals, I would not jump to conclusions >> here! I am pretty sure that driving on negative edge works just as well. > > I've tested Linus' original patch and it broke display on R-Car, so, no, it > doesn't work :-) > How can that be, R-Car does not use struct bridge timings or DRM_BUS_FLAG_PIXDATA_*EDGE bus_flags? Which version exactly did you test? (in v4 you claimed that you did not have access to hardware at that point..) > The R-Car display engine delays the clock internally (in some cases that > delay > is even configurable, and that's not uncommon in display controllers). We > really need all this information, and I believe we need it for panels too, > not > just for bridges. The fact that we managed to get away without adding it to > panels is likely due to the large number of panels out there, which makes it > less likely that the same panel gets used by different systems in mainline > with different clock delays. I expect that some panel drivers report the > wrong > clock edge to make things work on the board they were tested with, and I > expect we'll eventually need to add the same information for panels too. I used a bunch of parallel displays which are upstream (EDT, KEO, TPK) all of them on several different SoCs with mainline drivers, namely mxsfb, drm-mxsfb, FSL DCU, Tegra (RGB). I had several cases where data have been driven on the wrong edge, hooking up oscilloscope and fix the driver helped in all cases... As long as there is no case at hand
[Bug 107213] [amdgpu/DisplayPort] KDE Wayland session is segfaulting right after login
https://bugs.freedesktop.org/show_bug.cgi?id=107213 Lee Donaghy changed: What|Removed |Added CC||lee295...@gmail.com --- Comment #19 from Lee Donaghy --- Created attachment 141650 --> https://bugs.freedesktop.org/attachment.cgi?id=141650&action=edit dmesg error msg while suspending. Found this bug report from a google search, i'm not using wayland and the machine appears to have suspended and resumed fine but i did happen to see the same error in the logs. posting in case it help narrow down the problem. System:Host: Plasma Kernel: 4.18.8-arch1-1-ARCH x86_64 bits: 64 Desktop: KDE Plasma 5.13.5 Distro: Antergos Linux CPU: Topology: 6-Core model: Intel Core i7-5820K bits: 64 type: MT MCP L2 cache: 15.0 MiB Speed: 2697 MHz min/max: 1200/3600 MHz Core speeds (MHz): 1: 2292 2: 1949 3: 2333 4: 2576 5: 2371 6: 3401 7: 2804 8: 2979 9: 2767 10: 2782 11: 3069 12: 3402 Graphics: Card-1: AMD Vega 10 XT [Radeon RX Vega 64] driver: amdgpu v: kernel Display: x11 server: X.Org 1.20.1 driver: modesetting unloaded: fbdev,vesa resolution: 2560x1440~144Hz, 1280x720~60Hz OpenGL: renderer: Radeon RX Vega (VEGA10 DRM 3.26.0 4.18.8-arch1-1-ARCH LLVM 6.0.1) v: 4.5 Mesa 18.2.0 -- 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] drm/virtio: add dma sync for dma mapped virtio gpu framebuffer pages
With virtio gpu ttm-pages being dma mapped, dma sync is needed when
swiotlb is used as bounce buffers, before TRANSFER_TO_HOST_2D/3D
commands are sent.
Signed-off-by: Jiandi An
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 8
drivers/gpu/drm/virtio/virtgpu_fb.c | 7 ---
drivers/gpu/drm/virtio/virtgpu_vq.c | 18 ++
3 files changed, 26 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
b/drivers/gpu/drm/virtio/virtgpu_drv.h
index ec9a38f99558..4dafe712c81b 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.h
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
@@ -36,6 +36,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -132,6 +133,13 @@ struct virtio_gpu_framebuffer {
#define to_virtio_gpu_framebuffer(x) \
container_of(x, struct virtio_gpu_framebuffer, base)
+struct virtio_gpu_fbdev {
+ struct drm_fb_helper helper;
+ struct virtio_gpu_framebuffer vgfb;
+ struct virtio_gpu_device *vgdev;
+ struct delayed_workwork;
+};
+
struct virtio_gpu_mman {
struct ttm_bo_global_refbo_global_ref;
struct drm_global_reference mem_global_ref;
diff --git a/drivers/gpu/drm/virtio/virtgpu_fb.c
b/drivers/gpu/drm/virtio/virtgpu_fb.c
index b5cebc9a179a..b9678c4082ac 100644
--- a/drivers/gpu/drm/virtio/virtgpu_fb.c
+++ b/drivers/gpu/drm/virtio/virtgpu_fb.c
@@ -29,13 +29,6 @@
#define VIRTIO_GPU_FBCON_POLL_PERIOD (HZ / 60)
-struct virtio_gpu_fbdev {
- struct drm_fb_helper helper;
- struct virtio_gpu_framebuffer vgfb;
- struct virtio_gpu_device *vgdev;
- struct delayed_workwork;
-};
-
static int virtio_gpu_dirty_update(struct virtio_gpu_framebuffer *fb,
bool store, int x, int y,
int width, int height)
diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c
b/drivers/gpu/drm/virtio/virtgpu_vq.c
index bf631d32d497..817ba156514e 100644
--- a/drivers/gpu/drm/virtio/virtgpu_vq.c
+++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
@@ -490,6 +490,15 @@ void virtio_gpu_cmd_transfer_to_host_2d(struct
virtio_gpu_device *vgdev,
{
struct virtio_gpu_transfer_to_host_2d *cmd_p;
struct virtio_gpu_vbuffer *vbuf;
+ struct virtio_gpu_fbdev *vgfbdev = vgdev->vgfbdev;
+ struct virtio_gpu_framebuffer *fb = &vgfbdev->vgfb;
+ struct virtio_gpu_object *obj = gem_to_virtio_gpu_obj(fb->base.obj[0]);
+ bool use_dma_api = !virtio_has_iommu_quirk(vgdev->vdev);
+
+ if (use_dma_api)
+ dma_sync_sg_for_device(vgdev->vdev->dev.parent,
+ obj->pages->sgl, obj->pages->nents,
+ DMA_TO_DEVICE);
cmd_p = virtio_gpu_alloc_cmd(vgdev, &vbuf, sizeof(*cmd_p));
memset(cmd_p, 0, sizeof(*cmd_p));
@@ -788,6 +797,15 @@ void virtio_gpu_cmd_transfer_to_host_3d(struct
virtio_gpu_device *vgdev,
{
struct virtio_gpu_transfer_host_3d *cmd_p;
struct virtio_gpu_vbuffer *vbuf;
+ struct virtio_gpu_fbdev *vgfbdev = vgdev->vgfbdev;
+ struct virtio_gpu_framebuffer *fb = &vgfbdev->vgfb;
+ struct virtio_gpu_object *obj = gem_to_virtio_gpu_obj(fb->base.obj[0]);
+ bool use_dma_api = !virtio_has_iommu_quirk(vgdev->vdev);
+
+ if (use_dma_api)
+ dma_sync_sg_for_device(vgdev->vdev->dev.parent,
+ obj->pages->sgl, obj->pages->nents,
+ DMA_TO_DEVICE);
cmd_p = virtio_gpu_alloc_cmd(vgdev, &vbuf, sizeof(*cmd_p));
memset(cmd_p, 0, sizeof(*cmd_p));
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [virtio-dev] [PATCH 2/2] drm/virtio: add iommu support.
On 09/18/2018 11:46 PM, Gerd Hoffmann wrote: > Hi, > >> buffer. I tried to put a dma_sync_sg_for_device() on virtio_gpu_object >> obj->pages-sgl >> before VIRTIO_GPU_CMD_TRANSFER_TO_HOST_2D is sent. This fixes the kernel >> console path. > > That should be the right place. > >> Once display manger is kicked off for example (sudo systemctl start >> lightdm.service) and >> resource id 3 gets created from user space down, it still gives a blank >> black screen. > > Hmm. I'd suspect there is simply a code path missing. Can you send the > patch you have? > > cheers, > Gerd > I sent the patch. For now it does dma_sync_sg on the pages in TRANSFER_TO_HOST_2D/3D when use_dma_api is true. https://lore.kernel.org/lkml/20180919070931.91168-1-jiandi...@amd.com/ - Jiandi ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] [RFC]drm: add syncobj timeline support v6
Am 19.09.2018 um 06:26 schrieb Chunming Zhou:
This patch is for VK_KHR_timeline_semaphore extension, semaphore is called
syncobj in kernel side:
This extension introduces a new type of syncobj that has an integer payload
identifying a point in a timeline. Such timeline syncobjs support the
following operations:
* CPU query - A host operation that allows querying the payload of the
timeline syncobj.
* CPU wait - A host operation that allows a blocking wait for a
timeline syncobj to reach a specified value.
* Device wait - A device operation that allows waiting for a
timeline syncobj to reach a specified value.
* Device signal - A device operation that allows advancing the
timeline syncobj to a specified value.
v1:
Since it's a timeline, that means the front time point(PT) always is signaled
before the late PT.
a. signal PT design:
Signal PT fence N depends on PT[N-1] fence and signal opertion fence, when
PT[N] fence is signaled,
the timeline will increase to value of PT[N].
b. wait PT design:
Wait PT fence is signaled by reaching timeline point value, when timeline is
increasing, will compare
wait PTs value with new timeline value, if PT value is lower than timeline
value, then wait PT will be
signaled, otherwise keep in list. syncobj wait operation can wait on any point
of timeline,
so need a RB tree to order them. And wait PT could ahead of signal PT, we need
a sumission fence to
perform that.
v2:
1. remove unused DRM_SYNCOBJ_CREATE_TYPE_NORMAL. (Christian)
2. move unexposed denitions to .c file. (Daniel Vetter)
3. split up the change to drm_syncobj_find_fence() in a separate patch.
(Christian)
4. split up the change to drm_syncobj_replace_fence() in a separate patch.
5. drop the submission_fence implementation and instead use wait_event() for
that. (Christian)
6. WARN_ON(point != 0) for NORMAL type syncobj case. (Daniel Vetter)
v3:
1. replace normal syncobj with timeline implemenation. (Vetter and Christian)
a. normal syncobj signal op will create a signal PT to tail of signal pt
list.
b. normal syncobj wait op will create a wait pt with last signal point,
and this wait PT is only signaled by related signal point PT.
2. many bug fix and clean up
3. stub fence moving is moved to other patch.
v4：
1. fix RB tree loop with while(node=rb_first(...)). (Christian)
2. fix syncobj lifecycle. (Christian)
3. only enable_signaling when there is wait_pt. (Christian)
4. fix timeline path issues.
5. write a timeline test in libdrm
v5: (Christian)
1. semaphore is called syncobj in kernel side.
2. don't need 'timeline' characters in some function name.
3. keep syncobj cb
v6: (Christian)
1. merge syncobj_timeline to syncobj structure
2. simplify some check sentences.
3. some misc change.
4. fix CTS failed issue
normal syncobj is tested by ./deqp-vk -n dEQP-VK*semaphore*
timeline syncobj is tested by ./amdgpu_test -s 9
Signed-off-by: Chunming Zhou
Cc: Christian Konig
Cc: Dave Airlie
Cc: Daniel Rakos
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_syncobj.c | 307 ++---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 2 +-
include/drm/drm_syncobj.h | 65 ++---
include/uapi/drm/drm.h | 1 +
4 files changed, 299 insertions(+), 76 deletions(-)
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index e9ce623d049e..987b5a120b65 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -56,6 +56,9 @@
#include "drm_internal.h"
#include
+/* merge normal syncobj to timeline syncobj, the point interval is 1 */
+#define DRM_SYNCOBJ_INDIVIDUAL_POINT 1
+
struct drm_syncobj_stub_fence {
struct dma_fence base;
spinlock_t lock;
@@ -82,6 +85,11 @@ static const struct dma_fence_ops drm_syncobj_stub_fence_ops
= {
.release = drm_syncobj_stub_fence_release,
};
+struct drm_syncobj_signal_pt {
+ struct dma_fence_array *base;
+ u64value;
+ struct list_head list;
+};
/**
* drm_syncobj_find - lookup and reference a sync object.
@@ -117,6 +125,9 @@ static void drm_syncobj_add_callback_locked(struct
drm_syncobj *syncobj,
list_add_tail(&cb->node, &syncobj->cb_list);
}
+static int drm_syncobj_search_fence(struct drm_syncobj *syncobj, u64 point,
+ u64 flags, struct dma_fence **fence);
+
static int drm_syncobj_fence_get_or_add_callback(struct drm_syncobj *syncobj,
struct dma_fence **fence,
struct drm_syncobj_cb *cb,
@@ -124,8 +135,8 @@ static int drm_syncobj_fence_get_or_add_callback(struct
drm_syncobj *syncobj,
{
int ret;
- *fence = drm_syncobj_fence_get(syncobj);
- if (*fence)
+ ret = drm_syncobj_search_fence(syncobj, 0, 0, fence);
+ if (!ret)
return 1;
spin_lock(&syncobj->lock);
@@ -133,10
Re: [PATCH] [RFC]drm: add syncobj timeline support v5
Am 19.09.2018 um 05:20 schrieb zhoucm1:
On 2018年09月18日 16:32, Christian König wrote:
+ for (i = 0; i < args->count_handles; i++) {
+ if (syncobjs[i]->type == DRM_SYNCOBJ_TYPE_TIMELINE) {
+ DRM_ERROR("timeline syncobj cannot reset!\n");
Why not? I mean that should still work or do I miss anything?
timeline semaphore spec doesn't require reset interface, it says the
timeline value only can be changed by signal operations.
Yeah, but we don't care about the timeline spec in the kernel.
Question is rather if that still makes sense to support that and as
far as I can see it should be trivial to reinitialize the object.
Hi Daniel Rakos,
Could you give a comment on this question? Is it necessary to support
timeline reset interface? I only see the timeline value can be
changed by signal operations in Spec.
I think the Vulkan spec is rather irrelevant here. We added the reset
operation because of drivers which wanted to re-use an existing syncobj.
That is still a valid use case even when Vulkan doesn't have an
interface for it.
Christian.
Thanks,
David Zhou
___
amd-gfx mailing list
amd-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] [RFC]drm: add syncobj timeline support v6
On 2018年09月19日 15:18, Christian König wrote:
Am 19.09.2018 um 06:26 schrieb Chunming Zhou:
[snip]
*fence = NULL;
drm_syncobj_add_callback_locked(syncobj, cb, func);
@@ -164,6 +177,153 @@ void drm_syncobj_remove_callback(struct
drm_syncobj *syncobj,
spin_unlock(&syncobj->lock);
}
+static void drm_syncobj_timeline_init(struct drm_syncobj *syncobj)
We still have _timeline_ in the name here.
the func is relevant to timeline members, or which name is proper?
+{
+ spin_lock(&syncobj->lock);
+ syncobj->timeline_context = dma_fence_context_alloc(1);
[snip]
+}
+
+int drm_syncobj_lookup_fence(struct drm_syncobj *syncobj, u64 point,
+ struct dma_fence **fence) {
+
+ return drm_syncobj_search_fence(syncobj, point,
+ DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT,
I still have a bad feeling setting that flag as default cause it might
change the behavior for the UAPI.
Maybe export drm_syncobj_search_fence directly? E.g. with the flags
parameter.
previous v5 indeed do this, you let me wrap it, need change back?
Regards,
David Zhou
Regards,
Christian.
+ fence);
+}
+EXPORT_SYMBOL(drm_syncobj_lookup_fence);
+
/**
* drm_syncobj_find_fence - lookup and reference the fence in a
sync object
* @file_private: drm file private pointer
@@ -228,7 +443,7 @@ static int drm_syncobj_assign_null_handle(struct
drm_syncobj *syncobj)
* @fence: out parameter for the fence
*
* This is just a convenience function that combines
drm_syncobj_find() and
- * drm_syncobj_fence_get().
+ * drm_syncobj_lookup_fence().
*
* Returns 0 on success or a negative error value on failure. On
success @fence
* contains a reference to the fence, which must be released by
calling
@@ -236,18 +451,11 @@ static int
drm_syncobj_assign_null_handle(struct drm_syncobj *syncobj)
*/
int drm_syncobj_find_fence(struct drm_file *file_private,
u32 handle, u64 point,
- struct dma_fence **fence)
-{
+ struct dma_fence **fence) {
struct drm_syncobj *syncobj = drm_syncobj_find(file_private,
handle);
- int ret = 0;
-
- if (!syncobj)
- return -ENOENT;
+ int ret;
- *fence = drm_syncobj_fence_get(syncobj);
- if (!*fence) {
- ret = -EINVAL;
- }
+ ret = drm_syncobj_lookup_fence(syncobj, point, fence);
drm_syncobj_put(syncobj);
return ret;
}
@@ -264,7 +472,7 @@ void drm_syncobj_free(struct kref *kref)
struct drm_syncobj *syncobj = container_of(kref,
struct drm_syncobj,
refcount);
- drm_syncobj_replace_fence(syncobj, 0, NULL);
+ drm_syncobj_timeline_fini(syncobj);
kfree(syncobj);
}
EXPORT_SYMBOL(drm_syncobj_free);
@@ -294,6 +502,11 @@ int drm_syncobj_create(struct drm_syncobj
**out_syncobj, uint32_t flags,
kref_init(&syncobj->refcount);
INIT_LIST_HEAD(&syncobj->cb_list);
spin_lock_init(&syncobj->lock);
+ if (flags & DRM_SYNCOBJ_CREATE_TYPE_TIMELINE)
+ syncobj->type = DRM_SYNCOBJ_TYPE_TIMELINE;
+ else
+ syncobj->type = DRM_SYNCOBJ_TYPE_INDIVIDUAL;
+ drm_syncobj_timeline_init(syncobj);
if (flags & DRM_SYNCOBJ_CREATE_SIGNALED) {
ret = drm_syncobj_assign_null_handle(syncobj);
@@ -576,7 +789,8 @@ drm_syncobj_create_ioctl(struct drm_device *dev,
void *data,
return -ENODEV;
/* no valid flags yet */
- if (args->flags & ~DRM_SYNCOBJ_CREATE_SIGNALED)
+ if (args->flags & ~(DRM_SYNCOBJ_CREATE_SIGNALED |
+ DRM_SYNCOBJ_CREATE_TYPE_TIMELINE))
return -EINVAL;
return drm_syncobj_create_as_handle(file_private,
@@ -669,9 +883,8 @@ static void syncobj_wait_syncobj_func(struct
drm_syncobj *syncobj,
struct syncobj_wait_entry *wait =
container_of(cb, struct syncobj_wait_entry, syncobj_cb);
- /* This happens inside the syncobj lock */
- wait->fence =
dma_fence_get(rcu_dereference_protected(syncobj->fence,
- lockdep_is_held(&syncobj->lock)));
+ drm_syncobj_search_fence(syncobj, 0, 0, &wait->fence);
+
wake_up_process(wait->task);
}
@@ -698,7 +911,8 @@ static signed long
drm_syncobj_array_wait_timeout(struct drm_syncobj **syncobjs,
signaled_count = 0;
for (i = 0; i < count; ++i) {
entries[i].task = current;
- entries[i].fence = drm_syncobj_fence_get(syncobjs[i]);
+ ret = drm_syncobj_search_fence(syncobjs[i], 0, 0,
+ &entries[i].fence);
if (!entries[i].fence) {
if (flags & DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT) {
continue;
@@ -970,12 +1184,19 @@ drm_syncobj_reset_ioctl(struct drm_device
*dev, void *data,
if (ret < 0)
return ret;
- for (i = 0; i < args->count_handles; i++)
- drm_syncobj_replace_fence(syncobjs[i], 0, NULL);
-
+ for (i = 0; i < args->count_handles; i++) {
+ if (syncobjs[i
Re: [PATCH 1/4] [RFC]drm: add syncobj timeline support v6
On 2018年09月19日 15:18, Christian König wrote:
Am 19.09.2018 um 06:26 schrieb Chunming Zhou:
[snip]
*fence = NULL;
drm_syncobj_add_callback_locked(syncobj, cb, func);
@@ -164,6 +177,153 @@ void drm_syncobj_remove_callback(struct
drm_syncobj *syncobj,
spin_unlock(&syncobj->lock);
}
+static void drm_syncobj_timeline_init(struct drm_syncobj *syncobj)
We still have _timeline_ in the name here.
the func is relevant to timeline members, or which name is proper?
+{
+ spin_lock(&syncobj->lock);
+ syncobj->timeline_context = dma_fence_context_alloc(1);
[snip]
+}
+
+int drm_syncobj_lookup_fence(struct drm_syncobj *syncobj, u64 point,
+ struct dma_fence **fence) {
+
+ return drm_syncobj_search_fence(syncobj, point,
+ DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT,
I still have a bad feeling setting that flag as default cause it might
change the behavior for the UAPI.
Maybe export drm_syncobj_search_fence directly? E.g. with the flags
parameter.
previous v5 indeed do this, you let me wrap it, need change back?
Regards,
David Zhou
Regards,
Christian.
+ fence);
+}
+EXPORT_SYMBOL(drm_syncobj_lookup_fence);
+
/**
* drm_syncobj_find_fence - lookup and reference the fence in a
sync object
* @file_private: drm file private pointer
@@ -228,7 +443,7 @@ static int drm_syncobj_assign_null_handle(struct
drm_syncobj *syncobj)
* @fence: out parameter for the fence
*
* This is just a convenience function that combines
drm_syncobj_find() and
- * drm_syncobj_fence_get().
+ * drm_syncobj_lookup_fence().
*
* Returns 0 on success or a negative error value on failure. On
success @fence
* contains a reference to the fence, which must be released by
calling
@@ -236,18 +451,11 @@ static int
drm_syncobj_assign_null_handle(struct drm_syncobj *syncobj)
*/
int drm_syncobj_find_fence(struct drm_file *file_private,
u32 handle, u64 point,
- struct dma_fence **fence)
-{
+ struct dma_fence **fence) {
struct drm_syncobj *syncobj = drm_syncobj_find(file_private,
handle);
- int ret = 0;
-
- if (!syncobj)
- return -ENOENT;
+ int ret;
- *fence = drm_syncobj_fence_get(syncobj);
- if (!*fence) {
- ret = -EINVAL;
- }
+ ret = drm_syncobj_lookup_fence(syncobj, point, fence);
drm_syncobj_put(syncobj);
return ret;
}
@@ -264,7 +472,7 @@ void drm_syncobj_free(struct kref *kref)
struct drm_syncobj *syncobj = container_of(kref,
struct drm_syncobj,
refcount);
- drm_syncobj_replace_fence(syncobj, 0, NULL);
+ drm_syncobj_timeline_fini(syncobj);
kfree(syncobj);
}
EXPORT_SYMBOL(drm_syncobj_free);
@@ -294,6 +502,11 @@ int drm_syncobj_create(struct drm_syncobj
**out_syncobj, uint32_t flags,
kref_init(&syncobj->refcount);
INIT_LIST_HEAD(&syncobj->cb_list);
spin_lock_init(&syncobj->lock);
+ if (flags & DRM_SYNCOBJ_CREATE_TYPE_TIMELINE)
+ syncobj->type = DRM_SYNCOBJ_TYPE_TIMELINE;
+ else
+ syncobj->type = DRM_SYNCOBJ_TYPE_INDIVIDUAL;
+ drm_syncobj_timeline_init(syncobj);
if (flags & DRM_SYNCOBJ_CREATE_SIGNALED) {
ret = drm_syncobj_assign_null_handle(syncobj);
@@ -576,7 +789,8 @@ drm_syncobj_create_ioctl(struct drm_device *dev,
void *data,
return -ENODEV;
/* no valid flags yet */
- if (args->flags & ~DRM_SYNCOBJ_CREATE_SIGNALED)
+ if (args->flags & ~(DRM_SYNCOBJ_CREATE_SIGNALED |
+ DRM_SYNCOBJ_CREATE_TYPE_TIMELINE))
return -EINVAL;
return drm_syncobj_create_as_handle(file_private,
@@ -669,9 +883,8 @@ static void syncobj_wait_syncobj_func(struct
drm_syncobj *syncobj,
struct syncobj_wait_entry *wait =
container_of(cb, struct syncobj_wait_entry, syncobj_cb);
- /* This happens inside the syncobj lock */
- wait->fence =
dma_fence_get(rcu_dereference_protected(syncobj->fence,
- lockdep_is_held(&syncobj->lock)));
+ drm_syncobj_search_fence(syncobj, 0, 0, &wait->fence);
+
wake_up_process(wait->task);
}
@@ -698,7 +911,8 @@ static signed long
drm_syncobj_array_wait_timeout(struct drm_syncobj **syncobjs,
signaled_count = 0;
for (i = 0; i < count; ++i) {
entries[i].task = current;
- entries[i].fence = drm_syncobj_fence_get(syncobjs[i]);
+ ret = drm_syncobj_search_fence(syncobjs[i], 0, 0,
+ &entries[i].fence);
if (!entries[i].fence) {
if (flags & DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT) {
continue;
@@ -970,12 +1184,19 @@ drm_syncobj_reset_ioctl(struct drm_device
*dev, void *data,
if (ret < 0)
return ret;
- for (i = 0; i < args->count_handles; i++)
- drm_syncobj_replace_fence(syncobjs[i], 0, NULL);
-
+ for (i = 0; i < args->count_handles; i++) {
+ if (syncobjs[i
[PATCH] drm/i915: set i915 driver probe to asynchronous
From: Zhang Ning
when i915 is built in module, and system has built-in display, eg. eDP,
i915 will detect and active it during driver probe. it will take long
time.
set i915 driver probe to asynchrous can save kernel initial time.
Signed-off-by: Zhang Ning
---
drivers/gpu/drm/i915/i915_pci.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 6a4d1388ad2d..0f57d71d0abb 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -738,6 +738,7 @@ static struct pci_driver i915_pci_driver = {
.probe = i915_pci_probe,
.remove = i915_pci_remove,
.driver.pm = &i915_pm_ops,
+ .driver.probe_type = PROBE_PREFER_ASYNCHRONOUS,
};
static int __init i915_init(void)
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] [RFC]drm: add syncobj timeline support v6
Am 19.09.2018 um 09:32 schrieb zhoucm1:
On 2018年09月19日 15:18, Christian König wrote:
Am 19.09.2018 um 06:26 schrieb Chunming Zhou:
[snip]
*fence = NULL;
drm_syncobj_add_callback_locked(syncobj, cb, func);
@@ -164,6 +177,153 @@ void drm_syncobj_remove_callback(struct
drm_syncobj *syncobj,
spin_unlock(&syncobj->lock);
}
+static void drm_syncobj_timeline_init(struct drm_syncobj *syncobj)
We still have _timeline_ in the name here.
the func is relevant to timeline members, or which name is proper?
Yeah, but we now use the timeline implementation for the individual
syncobj as well.
Not a big issue, but I would just name it
drm_syncobj_init()/drm_syncobj_fini.
+{
+ spin_lock(&syncobj->lock);
+ syncobj->timeline_context = dma_fence_context_alloc(1);
[snip]
+}
+
+int drm_syncobj_lookup_fence(struct drm_syncobj *syncobj, u64 point,
+ struct dma_fence **fence) {
+
+ return drm_syncobj_search_fence(syncobj, point,
+ DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT,
I still have a bad feeling setting that flag as default cause it
might change the behavior for the UAPI.
Maybe export drm_syncobj_search_fence directly? E.g. with the flags
parameter.
previous v5 indeed do this, you let me wrap it, need change back?
No, the problem is that drm_syncobj_find_fence() is still using
drm_syncobj_lookup_fence() which sets the flag instead of
drm_syncobj_search_fence() without the flag.
That changes the UAPI behavior because previously we would have returned
an error code and now we block for a fence to appear.
So I think the right solution would be to add the flags parameter to
drm_syncobj_find_fence() and let the driver decide if we need to block
or get -ENOENT.
Regards,
Christian.
Regards,
David Zhou
Regards,
Christian.
+ fence);
+}
+EXPORT_SYMBOL(drm_syncobj_lookup_fence);
+
/**
* drm_syncobj_find_fence - lookup and reference the fence in a
sync object
* @file_private: drm file private pointer
@@ -228,7 +443,7 @@ static int drm_syncobj_assign_null_handle(struct
drm_syncobj *syncobj)
* @fence: out parameter for the fence
*
* This is just a convenience function that combines
drm_syncobj_find() and
- * drm_syncobj_fence_get().
+ * drm_syncobj_lookup_fence().
*
* Returns 0 on success or a negative error value on failure. On
success @fence
* contains a reference to the fence, which must be released by
calling
@@ -236,18 +451,11 @@ static int
drm_syncobj_assign_null_handle(struct drm_syncobj *syncobj)
*/
int drm_syncobj_find_fence(struct drm_file *file_private,
u32 handle, u64 point,
- struct dma_fence **fence)
-{
+ struct dma_fence **fence) {
struct drm_syncobj *syncobj = drm_syncobj_find(file_private,
handle);
- int ret = 0;
-
- if (!syncobj)
- return -ENOENT;
+ int ret;
- *fence = drm_syncobj_fence_get(syncobj);
- if (!*fence) {
- ret = -EINVAL;
- }
+ ret = drm_syncobj_lookup_fence(syncobj, point, fence);
drm_syncobj_put(syncobj);
return ret;
}
@@ -264,7 +472,7 @@ void drm_syncobj_free(struct kref *kref)
struct drm_syncobj *syncobj = container_of(kref,
struct drm_syncobj,
refcount);
- drm_syncobj_replace_fence(syncobj, 0, NULL);
+ drm_syncobj_timeline_fini(syncobj);
kfree(syncobj);
}
EXPORT_SYMBOL(drm_syncobj_free);
@@ -294,6 +502,11 @@ int drm_syncobj_create(struct drm_syncobj
**out_syncobj, uint32_t flags,
kref_init(&syncobj->refcount);
INIT_LIST_HEAD(&syncobj->cb_list);
spin_lock_init(&syncobj->lock);
+ if (flags & DRM_SYNCOBJ_CREATE_TYPE_TIMELINE)
+ syncobj->type = DRM_SYNCOBJ_TYPE_TIMELINE;
+ else
+ syncobj->type = DRM_SYNCOBJ_TYPE_INDIVIDUAL;
+ drm_syncobj_timeline_init(syncobj);
if (flags & DRM_SYNCOBJ_CREATE_SIGNALED) {
ret = drm_syncobj_assign_null_handle(syncobj);
@@ -576,7 +789,8 @@ drm_syncobj_create_ioctl(struct drm_device *dev,
void *data,
return -ENODEV;
/* no valid flags yet */
- if (args->flags & ~DRM_SYNCOBJ_CREATE_SIGNALED)
+ if (args->flags & ~(DRM_SYNCOBJ_CREATE_SIGNALED |
+ DRM_SYNCOBJ_CREATE_TYPE_TIMELINE))
return -EINVAL;
return drm_syncobj_create_as_handle(file_private,
@@ -669,9 +883,8 @@ static void syncobj_wait_syncobj_func(struct
drm_syncobj *syncobj,
struct syncobj_wait_entry *wait =
container_of(cb, struct syncobj_wait_entry, syncobj_cb);
- /* This happens inside the syncobj lock */
- wait->fence =
dma_fence_get(rcu_dereference_protected(syncobj->fence,
- lockdep_is_held(&syncobj->lock)));
+ drm_syncobj_search_fence(syncobj, 0, 0, &wait->fence);
+
wake_up_process(wait->task);
}
@@ -698,7 +911,8 @@ static signed long
drm_syncobj_array_wait_timeout(struct drm_syncobj **syncobjs,
sig
Re: [PATCH libdrm] intel: annotate the intel genx helpers as private
2018-09-14 2:23 GMT+08:00 Lucas De Marchi :
> +Chris
>>
>> 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?
Hmm... There is no private declaration in this header.
Why is it private?
If so, what is the correct way to get the gen of Intel's GPU?
Or the userspace should not know it?
--
Chih-Wei
Android-x86 project
http://www.android-x86.org
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH 1/4] [RFC]drm: add syncobj timeline support v6
> -Original Message-
> From: amd-gfx On Behalf Of
> Christian K?nig
> Sent: Wednesday, September 19, 2018 3:45 PM
> To: Zhou, David(ChunMing) ; Zhou,
> David(ChunMing) ; dri-
> de...@lists.freedesktop.org
> Cc: Dave Airlie ; Rakos, Daniel
> ; Daniel Vetter ; amd-
> g...@lists.freedesktop.org
> Subject: Re: [PATCH 1/4] [RFC]drm: add syncobj timeline support v6
>
> Am 19.09.2018 um 09:32 schrieb zhoucm1:
> >
> >
> > On 2018年09月19日 15:18, Christian König wrote:
> >> Am 19.09.2018 um 06:26 schrieb Chunming Zhou:
> > [snip]
> >>> *fence = NULL;
> >>> drm_syncobj_add_callback_locked(syncobj, cb, func); @@
> >>> -164,6 +177,153 @@ void drm_syncobj_remove_callback(struct
> >>> drm_syncobj *syncobj,
> >>> spin_unlock(&syncobj->lock);
> >>> }
> >>> +static void drm_syncobj_timeline_init(struct drm_syncobj
> >>> *syncobj)
> >>
> >> We still have _timeline_ in the name here.
> > the func is relevant to timeline members, or which name is proper?
>
> Yeah, but we now use the timeline implementation for the individual syncobj
> as well.
>
> Not a big issue, but I would just name it
> drm_syncobj_init()/drm_syncobj_fini.
There is already drm_syncobj_init/fini in drm_syncboj.c , any other name can be
suggested?
>
> >
> >>
> >>> +{
> >>> + spin_lock(&syncobj->lock);
> >>> + syncobj->timeline_context = dma_fence_context_alloc(1);
> > [snip]
> >>> +}
> >>> +
> >>> +int drm_syncobj_lookup_fence(struct drm_syncobj *syncobj, u64
> >>> +point,
> >>> + struct dma_fence **fence) {
> >>> +
> >>> + return drm_syncobj_search_fence(syncobj, point,
> >>> + DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT,
> >>
> >> I still have a bad feeling setting that flag as default cause it
> >> might change the behavior for the UAPI.
> >>
> >> Maybe export drm_syncobj_search_fence directly? E.g. with the flags
> >> parameter.
> > previous v5 indeed do this, you let me wrap it, need change back?
>
> No, the problem is that drm_syncobj_find_fence() is still using
> drm_syncobj_lookup_fence() which sets the flag instead of
> drm_syncobj_search_fence() without the flag.
>
> That changes the UAPI behavior because previously we would have returned
> an error code and now we block for a fence to appear.
>
> So I think the right solution would be to add the flags parameter to
> drm_syncobj_find_fence() and let the driver decide if we need to block or
> get -ENOENT.
Got your means,
Exporting flag in func is easy,
but driver doesn't pass flag, which flag is proper by default? We still need
to give a default flag in patch, don't we?
Thanks,
David Zhou
>
> Regards,
> Christian.
>
> >
> > Regards,
> > David Zhou
> >>
> >> Regards,
> >> Christian.
> >>
> >>> + fence);
> >>> +}
> >>> +EXPORT_SYMBOL(drm_syncobj_lookup_fence);
> >>> +
> >>> /**
> >>> * drm_syncobj_find_fence - lookup and reference the fence in a
> >>> sync object
> >>> * @file_private: drm file private pointer @@ -228,7 +443,7 @@
> >>> static int drm_syncobj_assign_null_handle(struct
> >>> drm_syncobj *syncobj)
> >>> * @fence: out parameter for the fence
> >>> *
> >>> * This is just a convenience function that combines
> >>> drm_syncobj_find() and
> >>> - * drm_syncobj_fence_get().
> >>> + * drm_syncobj_lookup_fence().
> >>> *
> >>> * Returns 0 on success or a negative error value on failure. On
> >>> success @fence
> >>> * contains a reference to the fence, which must be released by
> >>> calling @@ -236,18 +451,11 @@ static int
> >>> drm_syncobj_assign_null_handle(struct drm_syncobj *syncobj)
> >>> */
> >>> int drm_syncobj_find_fence(struct drm_file *file_private,
> >>> u32 handle, u64 point,
> >>> - struct dma_fence **fence) -{
> >>> + struct dma_fence **fence) {
> >>> struct drm_syncobj *syncobj = drm_syncobj_find(file_private,
> >>> handle);
> >>> - int ret = 0;
> >>> -
> >>> - if (!syncobj)
> >>> - return -ENOENT;
> >>> + int ret;
> >>> - *fence = drm_syncobj_fence_get(syncobj);
> >>> - if (!*fence) {
> >>> - ret = -EINVAL;
> >>> - }
> >>> + ret = drm_syncobj_lookup_fence(syncobj, point, fence);
> >>> drm_syncobj_put(syncobj);
> >>> return ret;
> >>> }
> >>> @@ -264,7 +472,7 @@ void drm_syncobj_free(struct kref *kref)
> >>> struct drm_syncobj *syncobj = container_of(kref,
> >>> struct drm_syncobj,
> >>> refcount);
> >>> - drm_syncobj_replace_fence(syncobj, 0, NULL);
> >>> + drm_syncobj_timeline_fini(syncobj);
> >>> kfree(syncobj);
> >>> }
> >>> EXPORT_SYMBOL(drm_syncobj_free);
> >>> @@ -294,6 +502,11 @@ int drm_syncobj_create(struct drm_syncobj
> >>> **out_syncobj, uint32_t flags,
> >>> kref_init(&syncobj->refcount);
> >>> INIT_LIST_HEAD(&syncobj->cb_list);
> >>> spin_lock_init(&syncobj->lock);
> >>> + if (flags & DRM_SYNCOBJ_CREATE_TYPE_TIMELINE)
> >>> +
Re: [PATCH 1/4] [RFC]drm: add syncobj timeline support v6
Am 19.09.2018 um 10:03 schrieb Zhou, David(ChunMing):
-Original Message-
From: amd-gfx On Behalf Of
Christian K?nig
Sent: Wednesday, September 19, 2018 3:45 PM
To: Zhou, David(ChunMing) ; Zhou,
David(ChunMing) ; dri-
de...@lists.freedesktop.org
Cc: Dave Airlie ; Rakos, Daniel
; Daniel Vetter ; amd-
g...@lists.freedesktop.org
Subject: Re: [PATCH 1/4] [RFC]drm: add syncobj timeline support v6
Am 19.09.2018 um 09:32 schrieb zhoucm1:
On 2018年09月19日 15:18, Christian König wrote:
Am 19.09.2018 um 06:26 schrieb Chunming Zhou:
[snip]
*fence = NULL;
drm_syncobj_add_callback_locked(syncobj, cb, func); @@
-164,6 +177,153 @@ void drm_syncobj_remove_callback(struct
drm_syncobj *syncobj,
spin_unlock(&syncobj->lock);
}
+static void drm_syncobj_timeline_init(struct drm_syncobj
*syncobj)
We still have _timeline_ in the name here.
the func is relevant to timeline members, or which name is proper?
Yeah, but we now use the timeline implementation for the individual syncobj
as well.
Not a big issue, but I would just name it
drm_syncobj_init()/drm_syncobj_fini.
There is already drm_syncobj_init/fini in drm_syncboj.c , any other name can be
suggested?
Hui what? I actually checked that there is no
drm_syncobj_init()/drm_syncobj_fini() in drm_syncobj.c before suggesting
it. Am I missing something?
+{
+ spin_lock(&syncobj->lock);
+ syncobj->timeline_context = dma_fence_context_alloc(1);
[snip]
+}
+
+int drm_syncobj_lookup_fence(struct drm_syncobj *syncobj, u64
+point,
+ struct dma_fence **fence) {
+
+ return drm_syncobj_search_fence(syncobj, point,
+ DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT,
I still have a bad feeling setting that flag as default cause it
might change the behavior for the UAPI.
Maybe export drm_syncobj_search_fence directly? E.g. with the flags
parameter.
previous v5 indeed do this, you let me wrap it, need change back?
No, the problem is that drm_syncobj_find_fence() is still using
drm_syncobj_lookup_fence() which sets the flag instead of
drm_syncobj_search_fence() without the flag.
That changes the UAPI behavior because previously we would have returned
an error code and now we block for a fence to appear.
So I think the right solution would be to add the flags parameter to
drm_syncobj_find_fence() and let the driver decide if we need to block or
get -ENOENT.
Got your means,
Exporting flag in func is easy,
but driver doesn't pass flag, which flag is proper by default? We still need
to give a default flag in patch, don't we?
Well proper solution is to keep the old behavior as it is for now.
So passing 0 as flag by default and making sure we get a -ENOENT in that
case sounds like the right approach to me.
Adding the DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT flag can happen when
the driver starts to provide a proper point as well.
Christian.
Thanks,
David Zhou
Regards,
Christian.
Regards,
David Zhou
Regards,
Christian.
+ fence);
+}
+EXPORT_SYMBOL(drm_syncobj_lookup_fence);
+
/**
* drm_syncobj_find_fence - lookup and reference the fence in a
sync object
* @file_private: drm file private pointer @@ -228,7 +443,7 @@
static int drm_syncobj_assign_null_handle(struct
drm_syncobj *syncobj)
* @fence: out parameter for the fence
*
* This is just a convenience function that combines
drm_syncobj_find() and
- * drm_syncobj_fence_get().
+ * drm_syncobj_lookup_fence().
*
* Returns 0 on success or a negative error value on failure. On
success @fence
* contains a reference to the fence, which must be released by
calling @@ -236,18 +451,11 @@ static int
drm_syncobj_assign_null_handle(struct drm_syncobj *syncobj)
*/
int drm_syncobj_find_fence(struct drm_file *file_private,
u32 handle, u64 point,
- struct dma_fence **fence) -{
+ struct dma_fence **fence) {
struct drm_syncobj *syncobj = drm_syncobj_find(file_private,
handle);
- int ret = 0;
-
- if (!syncobj)
- return -ENOENT;
+ int ret;
- *fence = drm_syncobj_fence_get(syncobj);
- if (!*fence) {
- ret = -EINVAL;
- }
+ ret = drm_syncobj_lookup_fence(syncobj, point, fence);
drm_syncobj_put(syncobj);
return ret;
}
@@ -264,7 +472,7 @@ void drm_syncobj_free(struct kref *kref)
struct drm_syncobj *syncobj = container_of(kref,
struct drm_syncobj,
refcount);
- drm_syncobj_replace_fence(syncobj, 0, NULL);
+ drm_syncobj_timeline_fini(syncobj);
kfree(syncobj);
}
EXPORT_SYMBOL(drm_syncobj_free);
@@ -294,6 +502,11 @@ int drm_syncobj_create(struct drm_syncobj
**out_syncobj, uint32_t flags,
kref_init(&syncobj->refcount);
INIT_LIST_HEAD(&syncobj->cb_list);
spin_lock_init(&syncobj->lock);
+ if (flags & DRM_SYNCOBJ_CREATE_TYPE_TIMELINE)
+ syncobj->type = DRM_SYNCOBJ_TYPE_TIMELINE;
+ else
Re: [PATCH 1/4] [RFC]drm: add syncobj timeline support v6
On 2018年09月19日 16:07, Christian König wrote:
Am 19.09.2018 um 10:03 schrieb Zhou, David(ChunMing):
-Original Message-
From: amd-gfx On Behalf Of
Christian K?nig
Sent: Wednesday, September 19, 2018 3:45 PM
To: Zhou, David(ChunMing) ; Zhou,
David(ChunMing) ; dri-
de...@lists.freedesktop.org
Cc: Dave Airlie ; Rakos, Daniel
; Daniel Vetter ; amd-
g...@lists.freedesktop.org
Subject: Re: [PATCH 1/4] [RFC]drm: add syncobj timeline support v6
Am 19.09.2018 um 09:32 schrieb zhoucm1:
On 2018年09月19日 15:18, Christian König wrote:
Am 19.09.2018 um 06:26 schrieb Chunming Zhou:
[snip]
*fence = NULL;
drm_syncobj_add_callback_locked(syncobj, cb, func); @@
-164,6 +177,153 @@ void drm_syncobj_remove_callback(struct
drm_syncobj *syncobj,
spin_unlock(&syncobj->lock);
}
+static void drm_syncobj_timeline_init(struct drm_syncobj
*syncobj)
We still have _timeline_ in the name here.
the func is relevant to timeline members, or which name is proper?
Yeah, but we now use the timeline implementation for the individual
syncobj
as well.
Not a big issue, but I would just name it
drm_syncobj_init()/drm_syncobj_fini.
There is already drm_syncobj_init/fini in drm_syncboj.c , any other
name can be suggested?
Hui what? I actually checked that there is no
drm_syncobj_init()/drm_syncobj_fini() in drm_syncobj.c before
suggesting it. Am I missing something?
messed syncobj_create/destroy in brain :(
+{
+ spin_lock(&syncobj->lock);
+ syncobj->timeline_context = dma_fence_context_alloc(1);
[snip]
+}
+
+int drm_syncobj_lookup_fence(struct drm_syncobj *syncobj, u64
+point,
+ struct dma_fence **fence) {
+
+ return drm_syncobj_search_fence(syncobj, point,
+ DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT,
I still have a bad feeling setting that flag as default cause it
might change the behavior for the UAPI.
Maybe export drm_syncobj_search_fence directly? E.g. with the flags
parameter.
previous v5 indeed do this, you let me wrap it, need change back?
No, the problem is that drm_syncobj_find_fence() is still using
drm_syncobj_lookup_fence() which sets the flag instead of
drm_syncobj_search_fence() without the flag.
That changes the UAPI behavior because previously we would have
returned
an error code and now we block for a fence to appear.
So I think the right solution would be to add the flags parameter to
drm_syncobj_find_fence() and let the driver decide if we need to
block or
get -ENOENT.
Got your means,
Exporting flag in func is easy,
but driver doesn't pass flag, which flag is proper by default? We
still need to give a default flag in patch, don't we?
Well proper solution is to keep the old behavior as it is for now.
So passing 0 as flag by default and making sure we get a -ENOENT in
that case sounds like the right approach to me.
Adding the DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT flag can happen when
the driver starts to provide a proper point as well.
Sounds more flexible.
v7 will come soon.
thanks,
David Zhou
Christian.
Thanks,
David Zhou
Regards,
Christian.
Regards,
David Zhou
Regards,
Christian.
+ fence);
+}
+EXPORT_SYMBOL(drm_syncobj_lookup_fence);
+
/**
* drm_syncobj_find_fence - lookup and reference the fence in a
sync object
* @file_private: drm file private pointer @@ -228,7 +443,7 @@
static int drm_syncobj_assign_null_handle(struct
drm_syncobj *syncobj)
* @fence: out parameter for the fence
*
* This is just a convenience function that combines
drm_syncobj_find() and
- * drm_syncobj_fence_get().
+ * drm_syncobj_lookup_fence().
*
* Returns 0 on success or a negative error value on failure. On
success @fence
* contains a reference to the fence, which must be released by
calling @@ -236,18 +451,11 @@ static int
drm_syncobj_assign_null_handle(struct drm_syncobj *syncobj)
*/
int drm_syncobj_find_fence(struct drm_file *file_private,
u32 handle, u64 point,
- struct dma_fence **fence) -{
+ struct dma_fence **fence) {
struct drm_syncobj *syncobj = drm_syncobj_find(file_private,
handle);
- int ret = 0;
-
- if (!syncobj)
- return -ENOENT;
+ int ret;
- *fence = drm_syncobj_fence_get(syncobj);
- if (!*fence) {
- ret = -EINVAL;
- }
+ ret = drm_syncobj_lookup_fence(syncobj, point, fence);
drm_syncobj_put(syncobj);
return ret;
}
@@ -264,7 +472,7 @@ void drm_syncobj_free(struct kref *kref)
struct drm_syncobj *syncobj = container_of(kref,
struct drm_syncobj,
refcount);
- drm_syncobj_replace_fence(syncobj, 0, NULL);
+ drm_syncobj_timeline_fini(syncobj);
kfree(syncobj);
}
EXPORT_SYMBOL(drm_syncobj_free);
@@ -294,6 +502,11 @@ int drm_syncobj_create(struct drm_syncobj
**out_syncobj, uint32_t flags,
kref_init(&syncobj->refcount);
INIT_LIST_HEAD(&syncobj->cb_list);
spin_
[PATCH 2/6] [RFC]drm: add syncobj timeline support v7
This patch is for VK_KHR_timeline_semaphore extension, semaphore is called
syncobj in kernel side:
This extension introduces a new type of syncobj that has an integer payload
identifying a point in a timeline. Such timeline syncobjs support the
following operations:
* CPU query - A host operation that allows querying the payload of the
timeline syncobj.
* CPU wait - A host operation that allows a blocking wait for a
timeline syncobj to reach a specified value.
* Device wait - A device operation that allows waiting for a
timeline syncobj to reach a specified value.
* Device signal - A device operation that allows advancing the
timeline syncobj to a specified value.
v1:
Since it's a timeline, that means the front time point(PT) always is signaled
before the late PT.
a. signal PT design:
Signal PT fence N depends on PT[N-1] fence and signal opertion fence, when
PT[N] fence is signaled,
the timeline will increase to value of PT[N].
b. wait PT design:
Wait PT fence is signaled by reaching timeline point value, when timeline is
increasing, will compare
wait PTs value with new timeline value, if PT value is lower than timeline
value, then wait PT will be
signaled, otherwise keep in list. syncobj wait operation can wait on any point
of timeline,
so need a RB tree to order them. And wait PT could ahead of signal PT, we need
a sumission fence to
perform that.
v2:
1. remove unused DRM_SYNCOBJ_CREATE_TYPE_NORMAL. (Christian)
2. move unexposed denitions to .c file. (Daniel Vetter)
3. split up the change to drm_syncobj_find_fence() in a separate patch.
(Christian)
4. split up the change to drm_syncobj_replace_fence() in a separate patch.
5. drop the submission_fence implementation and instead use wait_event() for
that. (Christian)
6. WARN_ON(point != 0) for NORMAL type syncobj case. (Daniel Vetter)
v3:
1. replace normal syncobj with timeline implemenation. (Vetter and Christian)
a. normal syncobj signal op will create a signal PT to tail of signal pt
list.
b. normal syncobj wait op will create a wait pt with last signal point, and
this wait PT is only signaled by related signal point PT.
2. many bug fix and clean up
3. stub fence moving is moved to other patch.
v4：
1. fix RB tree loop with while(node=rb_first(...)). (Christian)
2. fix syncobj lifecycle. (Christian)
3. only enable_signaling when there is wait_pt. (Christian)
4. fix timeline path issues.
5. write a timeline test in libdrm
v5: (Christian)
1. semaphore is called syncobj in kernel side.
2. don't need 'timeline' characters in some function name.
3. keep syncobj cb.
v6: (Christian)
1. merge syncobj_timeline to syncobj structure.
2. simplify some check sentences.
3. some misc change.
4. fix CTS failed issue.
v7: (Christian)
1. error handling when creating signal pt.
2. remove timeline naming in func.
3. export flags in find_fence.
4. allow reset timeline.
normal syncobj is tested by ./deqp-vk -n dEQP-VK*semaphore*
timeline syncobj is tested by ./amdgpu_test -s 9
Signed-off-by: Chunming Zhou
Cc: Christian Konig
Cc: Dave Airlie
Cc: Daniel Rakos
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_syncobj.c | 291 ++---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 2 +-
include/drm/drm_syncobj.h | 65 ++---
include/uapi/drm/drm.h | 1 +
4 files changed, 285 insertions(+), 74 deletions(-)
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index f796c9fc3858..d69126b690c2 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -56,6 +56,9 @@
#include "drm_internal.h"
#include
+/* merge normal syncobj to timeline syncobj, the point interval is 1 */
+#define DRM_SYNCOBJ_INDIVIDUAL_POINT 1
+
struct drm_syncobj_stub_fence {
struct dma_fence base;
spinlock_t lock;
@@ -82,6 +85,11 @@ static const struct dma_fence_ops drm_syncobj_stub_fence_ops
= {
.release = drm_syncobj_stub_fence_release,
};
+struct drm_syncobj_signal_pt {
+ struct dma_fence_array *base;
+ u64value;
+ struct list_head list;
+};
/**
* drm_syncobj_find - lookup and reference a sync object.
@@ -124,8 +132,8 @@ static int drm_syncobj_fence_get_or_add_callback(struct
drm_syncobj *syncobj,
{
int ret;
- *fence = drm_syncobj_fence_get(syncobj);
- if (*fence)
+ ret = drm_syncobj_search_fence(syncobj, 0, 0, fence);
+ if (!ret)
return 1;
spin_lock(&syncobj->lock);
@@ -133,10 +141,12 @@ static int drm_syncobj_fence_get_or_add_callback(struct
drm_syncobj *syncobj,
* have the lock, try one more time just to be sure we don't add a
* callback when a fence has already been set.
*/
- if (syncobj->fence) {
- *fence = dma_fence_get(rcu_dereference_protected(syncobj->fence,
-
lockdep_is_held(&syncobj->lock)));
-
[PATCH 3/6] drm: add support of syncobj timeline point wait v2
points array is one-to-one match with syncobjs array.
v2:
add seperate ioctl for timeline point wait, otherwise break uapi.
Signed-off-by: Chunming Zhou
---
drivers/gpu/drm/drm_internal.h | 2 +
drivers/gpu/drm/drm_ioctl.c| 2 +
drivers/gpu/drm/drm_syncobj.c | 99 +-
include/uapi/drm/drm.h | 14 +
4 files changed, 103 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index 0c4eb4a9ab31..566d44e3c782 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -183,6 +183,8 @@ int drm_syncobj_fd_to_handle_ioctl(struct drm_device *dev,
void *data,
struct drm_file *file_private);
int drm_syncobj_wait_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_private);
+int drm_syncobj_timeline_wait_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file_private);
int drm_syncobj_reset_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_private);
int drm_syncobj_signal_ioctl(struct drm_device *dev, void *data,
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 6b4a633b4240..c0891614f516 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -669,6 +669,8 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_WAIT, drm_syncobj_wait_ioctl,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_TIMELINE_WAIT,
drm_syncobj_timeline_wait_ioctl,
+ DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_RESET, drm_syncobj_reset_ioctl,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_SIGNAL, drm_syncobj_signal_ioctl,
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index d69126b690c2..251d48a18999 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -126,13 +126,14 @@ static void drm_syncobj_add_callback_locked(struct
drm_syncobj *syncobj,
}
static int drm_syncobj_fence_get_or_add_callback(struct drm_syncobj *syncobj,
+u64 point,
struct dma_fence **fence,
struct drm_syncobj_cb *cb,
drm_syncobj_func_t func)
{
int ret;
- ret = drm_syncobj_search_fence(syncobj, 0, 0, fence);
+ ret = drm_syncobj_search_fence(syncobj, point, 0, fence);
if (!ret)
return 1;
@@ -143,7 +144,7 @@ static int drm_syncobj_fence_get_or_add_callback(struct
drm_syncobj *syncobj,
*/
if (!list_empty(&syncobj->signal_pt_list)) {
spin_unlock(&syncobj->lock);
- drm_syncobj_search_fence(syncobj, 0, 0, fence);
+ drm_syncobj_search_fence(syncobj, point, 0, fence);
if (*fence)
return 1;
spin_lock(&syncobj->lock);
@@ -356,7 +357,9 @@ void drm_syncobj_replace_fence(struct drm_syncobj *syncobj,
spin_lock(&syncobj->lock);
list_for_each_entry_safe(cur, tmp, &syncobj->cb_list, node) {
list_del_init(&cur->node);
+ spin_unlock(&syncobj->lock);
cur->func(syncobj, cur);
+ spin_lock(&syncobj->lock);
}
spin_unlock(&syncobj->lock);
}
@@ -860,6 +863,7 @@ struct syncobj_wait_entry {
struct dma_fence *fence;
struct dma_fence_cb fence_cb;
struct drm_syncobj_cb syncobj_cb;
+ u64point;
};
static void syncobj_wait_fence_func(struct dma_fence *fence,
@@ -877,12 +881,13 @@ static void syncobj_wait_syncobj_func(struct drm_syncobj
*syncobj,
struct syncobj_wait_entry *wait =
container_of(cb, struct syncobj_wait_entry, syncobj_cb);
- drm_syncobj_search_fence(syncobj, 0, 0, &wait->fence);
+ drm_syncobj_search_fence(syncobj, wait->point, 0, &wait->fence);
wake_up_process(wait->task);
}
static signed long drm_syncobj_array_wait_timeout(struct drm_syncobj
**syncobjs,
+ void __user *user_points,
uint32_t count,
uint32_t flags,
signed long timeout,
@@ -890,13 +895,27 @@ static signed long drm_syncobj_array_wait_timeout(struct
drm_syncobj **syncobjs,
{
struct syncobj_wait_entry *entries;
struct dma_fence *fence;
+ uint64_t *points;
signed long ret;
u
[PATCH 4/6] drm: add timeline syncobj payload query ioctl
user mode can query timeline payload.
Signed-off-by: Chunming Zhou
---
drivers/gpu/drm/drm_internal.h | 2 ++
drivers/gpu/drm/drm_ioctl.c| 2 ++
drivers/gpu/drm/drm_syncobj.c | 53 ++
include/uapi/drm/drm.h | 11 +++
4 files changed, 68 insertions(+)
diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index 566d44e3c782..9c4826411a3c 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -189,6 +189,8 @@ int drm_syncobj_reset_ioctl(struct drm_device *dev, void
*data,
struct drm_file *file_private);
int drm_syncobj_signal_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_private);
+int drm_syncobj_query_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file_private);
/* drm_framebuffer.c */
void drm_framebuffer_print_info(struct drm_printer *p, unsigned int indent,
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index c0891614f516..c3c0617e6372 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -675,6 +675,8 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_SIGNAL, drm_syncobj_signal_ioctl,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_QUERY, drm_syncobj_query_ioctl,
+ DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_CRTC_GET_SEQUENCE, drm_crtc_get_sequence_ioctl,
DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_CRTC_QUEUE_SEQUENCE,
drm_crtc_queue_sequence_ioctl, DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_CREATE_LEASE, drm_mode_create_lease_ioctl,
DRM_MASTER|DRM_UNLOCKED),
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 251d48a18999..831e64da4339 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -1293,3 +1293,56 @@ drm_syncobj_signal_ioctl(struct drm_device *dev, void
*data,
return ret;
}
+
+static void drm_syncobj_timeline_query_payload(struct drm_syncobj *syncobj,
+ uint64_t *point)
+{
+ if (syncobj->type != DRM_SYNCOBJ_TYPE_TIMELINE) {
+ DRM_ERROR("Normal syncobj cann't be queried!");
+ *point = 0;
+ return;
+ }
+ *point = syncobj->signal_point;
+}
+
+int drm_syncobj_query_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file_private)
+{
+ struct drm_syncobj_timeline_query *args = data;
+ struct drm_syncobj **syncobjs;
+ uint64_t *points;
+ uint32_t i;
+ int ret;
+
+ if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ))
+ return -ENODEV;
+
+ if (args->count_handles == 0)
+ return -EINVAL;
+
+ ret = drm_syncobj_array_find(file_private,
+u64_to_user_ptr(args->handles),
+args->count_handles,
+&syncobjs);
+ if (ret < 0)
+ return ret;
+
+
+ points = kmalloc_array(args->count_handles, sizeof(*points),
+ GFP_KERNEL);
+ if (points == NULL) {
+ ret = -ENOMEM;
+ goto out;
+ }
+ for (i = 0; i < args->count_handles; i++) {
+ drm_syncobj_timeline_query_payload(syncobjs[i], &points[i]);
+ copy_to_user(u64_to_user_ptr(args->points), points,
+sizeof(uint64_t) * args->count_handles);
+ }
+
+ kfree(points);
+out:
+ drm_syncobj_array_free(syncobjs, args->count_handles);
+
+ return ret;
+}
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 501e86d81f47..188b63f1975b 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -767,6 +767,15 @@ struct drm_syncobj_array {
__u32 pad;
};
+struct drm_syncobj_timeline_query {
+ __u64 handles;
+ /* points are timeline syncobjs payloads returned by query ioctl */
+ __u64 points;
+ __u32 count_handles;
+ __u32 pad;
+};
+
+
/* Query current scanout sequence number */
struct drm_crtc_get_sequence {
__u32 crtc_id; /* requested crtc_id */
@@ -924,6 +933,8 @@ extern "C" {
#define DRM_IOCTL_MODE_REVOKE_LEASEDRM_IOWR(0xC9, struct
drm_mode_revoke_lease)
#define DRM_IOCTL_SYNCOBJ_TIMELINE_WAITDRM_IOWR(0xCA, struct
drm_syncobj_timeline_wait)
+#define DRM_IOCTL_SYNCOBJ_QUERYDRM_IOWR(0xCB, struct
drm_syncobj_timeline_query)
+
/**
* Device specific ioctls should only be in their respective headers
* The device specific ioctl range is from 0x40 to 0x9f.
--
2.17.1
___
dri-devel mailing list
dri-devel@lists
[PATCH 6/6] drm/amdgpu: update version for timeline syncobj support in amdgpu
Signed-off-by: Chunming Zhou --- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c index 6870909da926..58cba492ba55 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c @@ -70,9 +70,10 @@ * - 3.25.0 - Add support for sensor query info (stable pstate sclk/mclk). * - 3.26.0 - GFX9: Process AMDGPU_IB_FLAG_TC_WB_NOT_INVALIDATE. * - 3.27.0 - Add new chunk to to AMDGPU_CS to enable BO_LIST creation. + * - 3.28.0 - Add syncobj timeline support to AMDGPU_CS. */ #define KMS_DRIVER_MAJOR 3 -#define KMS_DRIVER_MINOR 27 +#define KMS_DRIVER_MINOR 28 #define KMS_DRIVER_PATCHLEVEL 0 int amdgpu_vram_limit = 0; -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/6] drm: add flags to drm_syncobj_find_fence
flags can be used by driver to decide whether need to block wait submission.
Signed-off-by: Chunming Zhou
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +-
drivers/gpu/drm/drm_syncobj.c | 4 ++--
drivers/gpu/drm/v3d/v3d_gem.c | 4 ++--
drivers/gpu/drm/vc4/vc4_gem.c | 2 +-
include/drm/drm_syncobj.h | 2 +-
5 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index d9d2ede96490..412fac238575 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -1102,7 +1102,7 @@ static int amdgpu_syncobj_lookup_and_add_to_sync(struct
amdgpu_cs_parser *p,
{
int r;
struct dma_fence *fence;
- r = drm_syncobj_find_fence(p->filp, handle, 0, &fence);
+ r = drm_syncobj_find_fence(p->filp, handle, 0, 0, &fence);
if (r)
return r;
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index e9ce623d049e..f796c9fc3858 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -235,7 +235,7 @@ static int drm_syncobj_assign_null_handle(struct
drm_syncobj *syncobj)
* dma_fence_put().
*/
int drm_syncobj_find_fence(struct drm_file *file_private,
- u32 handle, u64 point,
+ u32 handle, u64 point, u64 flags,
struct dma_fence **fence)
{
struct drm_syncobj *syncobj = drm_syncobj_find(file_private, handle);
@@ -506,7 +506,7 @@ static int drm_syncobj_export_sync_file(struct drm_file
*file_private,
if (fd < 0)
return fd;
- ret = drm_syncobj_find_fence(file_private, handle, 0, &fence);
+ ret = drm_syncobj_find_fence(file_private, handle, 0, 0, &fence);
if (ret)
goto err_put_fd;
diff --git a/drivers/gpu/drm/v3d/v3d_gem.c b/drivers/gpu/drm/v3d/v3d_gem.c
index 70c54774400b..97477879d3d4 100644
--- a/drivers/gpu/drm/v3d/v3d_gem.c
+++ b/drivers/gpu/drm/v3d/v3d_gem.c
@@ -521,12 +521,12 @@ v3d_submit_cl_ioctl(struct drm_device *dev, void *data,
kref_init(&exec->refcount);
ret = drm_syncobj_find_fence(file_priv, args->in_sync_bcl,
-0, &exec->bin.in_fence);
+0, 0, &exec->bin.in_fence);
if (ret == -EINVAL)
goto fail;
ret = drm_syncobj_find_fence(file_priv, args->in_sync_rcl,
-0, &exec->render.in_fence);
+0, 0, &exec->render.in_fence);
if (ret == -EINVAL)
goto fail;
diff --git a/drivers/gpu/drm/vc4/vc4_gem.c b/drivers/gpu/drm/vc4/vc4_gem.c
index 5b22e996af6c..251198194c38 100644
--- a/drivers/gpu/drm/vc4/vc4_gem.c
+++ b/drivers/gpu/drm/vc4/vc4_gem.c
@@ -1173,7 +1173,7 @@ vc4_submit_cl_ioctl(struct drm_device *dev, void *data,
if (args->in_sync) {
ret = drm_syncobj_find_fence(file_priv, args->in_sync,
-0, &in_fence);
+0, 0, &in_fence);
if (ret)
goto fail;
diff --git a/include/drm/drm_syncobj.h b/include/drm/drm_syncobj.h
index 425432b85a87..2eda44def639 100644
--- a/include/drm/drm_syncobj.h
+++ b/include/drm/drm_syncobj.h
@@ -134,7 +134,7 @@ struct drm_syncobj *drm_syncobj_find(struct drm_file
*file_private,
void drm_syncobj_replace_fence(struct drm_syncobj *syncobj, u64 point,
struct dma_fence *fence);
int drm_syncobj_find_fence(struct drm_file *file_private,
- u32 handle, u64 point,
+ u32 handle, u64 point, u64 flags,
struct dma_fence **fence);
void drm_syncobj_free(struct kref *kref);
int drm_syncobj_create(struct drm_syncobj **out_syncobj, uint32_t flags,
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/6] drm/amdgpu: add timeline support in amdgpu CS
syncobj wait/signal operation is appending in command submission.
Signed-off-by: Chunming Zhou
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 8 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 114 +++--
include/uapi/drm/amdgpu_drm.h | 10 +++
3 files changed, 104 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 447c4c7a36d6..6e4a3db56833 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -975,6 +975,11 @@ struct amdgpu_cs_chunk {
void*kdata;
};
+struct amdgpu_cs_syncobj_post_dep {
+ struct drm_syncobj *post_dep_syncobj;
+ u64 point;
+};
+
struct amdgpu_cs_parser {
struct amdgpu_device*adev;
struct drm_file *filp;
@@ -1003,9 +1008,8 @@ struct amdgpu_cs_parser {
/* user fence */
struct amdgpu_bo_list_entry uf_entry;
-
+ struct amdgpu_cs_syncobj_post_dep *post_dep_syncobjs;
unsigned num_post_dep_syncobjs;
- struct drm_syncobj **post_dep_syncobjs;
};
static inline u32 amdgpu_get_ib_value(struct amdgpu_cs_parser *p,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 412fac238575..0efe75bf2f03 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -204,6 +204,8 @@ static int amdgpu_cs_parser_init(struct amdgpu_cs_parser
*p, union drm_amdgpu_cs
case AMDGPU_CHUNK_ID_DEPENDENCIES:
case AMDGPU_CHUNK_ID_SYNCOBJ_IN:
case AMDGPU_CHUNK_ID_SYNCOBJ_OUT:
+ case AMDGPU_CHUNK_ID_SYNCOBJ_TIMELINE_WAIT:
+ case AMDGPU_CHUNK_ID_SYNCOBJ_TIMELINE_SIGNAL:
break;
default:
@@ -783,7 +785,7 @@ static void amdgpu_cs_parser_fini(struct amdgpu_cs_parser
*parser, int error,
&parser->validated);
for (i = 0; i < parser->num_post_dep_syncobjs; i++)
- drm_syncobj_put(parser->post_dep_syncobjs[i]);
+ drm_syncobj_put(parser->post_dep_syncobjs[i].post_dep_syncobj);
kfree(parser->post_dep_syncobjs);
dma_fence_put(parser->fence);
@@ -1098,11 +1100,13 @@ static int amdgpu_cs_process_fence_dep(struct
amdgpu_cs_parser *p,
}
static int amdgpu_syncobj_lookup_and_add_to_sync(struct amdgpu_cs_parser *p,
-uint32_t handle)
+uint32_t handle, u64 point,
+u64 flags)
{
int r;
struct dma_fence *fence;
- r = drm_syncobj_find_fence(p->filp, handle, 0, 0, &fence);
+
+ r = drm_syncobj_find_fence(p->filp, handle, point, flags, &fence);
if (r)
return r;
@@ -1113,48 +1117,91 @@ static int amdgpu_syncobj_lookup_and_add_to_sync(struct
amdgpu_cs_parser *p,
}
static int amdgpu_cs_process_syncobj_in_dep(struct amdgpu_cs_parser *p,
- struct amdgpu_cs_chunk *chunk)
+ struct amdgpu_cs_chunk *chunk,
+ bool timeline)
{
unsigned num_deps;
int i, r;
- struct drm_amdgpu_cs_chunk_sem *deps;
- deps = (struct drm_amdgpu_cs_chunk_sem *)chunk->kdata;
- num_deps = chunk->length_dw * 4 /
- sizeof(struct drm_amdgpu_cs_chunk_sem);
+ if (!timeline) {
+ struct drm_amdgpu_cs_chunk_sem *deps;
- for (i = 0; i < num_deps; ++i) {
- r = amdgpu_syncobj_lookup_and_add_to_sync(p, deps[i].handle);
+ deps = (struct drm_amdgpu_cs_chunk_sem *)chunk->kdata;
+ num_deps = chunk->length_dw * 4 /
+ sizeof(struct drm_amdgpu_cs_chunk_sem);
+ for (i = 0; i < num_deps; ++i) {
+ r = amdgpu_syncobj_lookup_and_add_to_sync(p,
deps[i].handle,
+ 0, 0);
if (r)
return r;
+ }
+ } else {
+ struct drm_amdgpu_cs_chunk_syncobj *syncobj_deps;
+
+ syncobj_deps = (struct drm_amdgpu_cs_chunk_syncobj
*)chunk->kdata;
+ num_deps = chunk->length_dw * 4 /
+ sizeof(struct drm_amdgpu_cs_chunk_syncobj);
+ for (i = 0; i < num_deps; ++i) {
+ r = amdgpu_syncobj_lookup_and_add_to_sync(p,
syncobj_deps[i].handle,
+
syncobj_deps[i].point,
+
syncobj_deps[i].flags);
+ if (r)
+ return r;
+ }
}
+
return 0;
}
static int amdgpu_cs_process_syncobj_out_dep(str
[Bug 201183] New: AMDGPU Dual displays and only DP screen works after grub.
https://bugzilla.kernel.org/show_bug.cgi?id=201183 Bug ID: 201183 Summary: AMDGPU Dual displays and only DP screen works after grub. Product: Drivers Version: 2.5 Kernel Version: 4.18.* Hardware: Intel OS: Linux Tree: Mainline Status: NEW Severity: high Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: marte...@gmail.com Regression: No Created attachment 278653 --> https://bugzilla.kernel.org/attachment.cgi?id=278653&action=edit kernel 4.18.7 dmesg Kernel 4.17 is working but the last 2 versions of 4.18.* will not register my HDMI TV connected to an RX 480. I have a Dell LCD on DP and an LG TV on HDMI. If I unplug the DP display after grub screen the computer will have no display. -- 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 201183] AMDGPU Dual displays and only DP screen works after grub.
https://bugzilla.kernel.org/show_bug.cgi?id=201183 --- Comment #1 from marten (marte...@gmail.com) --- Created attachment 278655 --> https://bugzilla.kernel.org/attachment.cgi?id=278655&action=edit Working kernel 4.17 dmesg -- 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 2/6] [RFC]drm: add syncobj timeline support v7
This patch is for VK_KHR_timeline_semaphore extension, semaphore is called
syncobj in kernel side:
This extension introduces a new type of syncobj that has an integer payload
identifying a point in a timeline. Such timeline syncobjs support the
following operations:
* CPU query - A host operation that allows querying the payload of the
timeline syncobj.
* CPU wait - A host operation that allows a blocking wait for a
timeline syncobj to reach a specified value.
* Device wait - A device operation that allows waiting for a
timeline syncobj to reach a specified value.
* Device signal - A device operation that allows advancing the
timeline syncobj to a specified value.
v1:
Since it's a timeline, that means the front time point(PT) always is signaled
before the late PT.
a. signal PT design:
Signal PT fence N depends on PT[N-1] fence and signal opertion fence, when
PT[N] fence is signaled,
the timeline will increase to value of PT[N].
b. wait PT design:
Wait PT fence is signaled by reaching timeline point value, when timeline is
increasing, will compare
wait PTs value with new timeline value, if PT value is lower than timeline
value, then wait PT will be
signaled, otherwise keep in list. syncobj wait operation can wait on any point
of timeline,
so need a RB tree to order them. And wait PT could ahead of signal PT, we need
a sumission fence to
perform that.
v2:
1. remove unused DRM_SYNCOBJ_CREATE_TYPE_NORMAL. (Christian)
2. move unexposed denitions to .c file. (Daniel Vetter)
3. split up the change to drm_syncobj_find_fence() in a separate patch.
(Christian)
4. split up the change to drm_syncobj_replace_fence() in a separate patch.
5. drop the submission_fence implementation and instead use wait_event() for
that. (Christian)
6. WARN_ON(point != 0) for NORMAL type syncobj case. (Daniel Vetter)
v3:
1. replace normal syncobj with timeline implemenation. (Vetter and Christian)
a. normal syncobj signal op will create a signal PT to tail of signal pt
list.
b. normal syncobj wait op will create a wait pt with last signal point, and
this wait PT is only signaled by related signal point PT.
2. many bug fix and clean up
3. stub fence moving is moved to other patch.
v4：
1. fix RB tree loop with while(node=rb_first(...)). (Christian)
2. fix syncobj lifecycle. (Christian)
3. only enable_signaling when there is wait_pt. (Christian)
4. fix timeline path issues.
5. write a timeline test in libdrm
v5: (Christian)
1. semaphore is called syncobj in kernel side.
2. don't need 'timeline' characters in some function name.
3. keep syncobj cb.
v6: (Christian)
1. merge syncobj_timeline to syncobj structure.
2. simplify some check sentences.
3. some misc change.
4. fix CTS failed issue.
v7: (Christian)
1. error handling when creating signal pt.
2. remove timeline naming in func.
3. export flags in find_fence.
4. allow reset timeline.
individual syncobj is tested by ./deqp-vk -n dEQP-VK*semaphore*
timeline syncobj is tested by ./amdgpu_test -s 9
Signed-off-by: Chunming Zhou
Cc: Christian Konig
Cc: Dave Airlie
Cc: Daniel Rakos
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_syncobj.c | 293 ++---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 2 +-
include/drm/drm_syncobj.h | 65 ++---
include/uapi/drm/drm.h | 1 +
4 files changed, 287 insertions(+), 74 deletions(-)
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index f796c9fc3858..95b60ac045c6 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -56,6 +56,9 @@
#include "drm_internal.h"
#include
+/* merge normal syncobj to timeline syncobj, the point interval is 1 */
+#define DRM_SYNCOBJ_INDIVIDUAL_POINT 1
+
struct drm_syncobj_stub_fence {
struct dma_fence base;
spinlock_t lock;
@@ -82,6 +85,11 @@ static const struct dma_fence_ops drm_syncobj_stub_fence_ops
= {
.release = drm_syncobj_stub_fence_release,
};
+struct drm_syncobj_signal_pt {
+ struct dma_fence_array *base;
+ u64value;
+ struct list_head list;
+};
/**
* drm_syncobj_find - lookup and reference a sync object.
@@ -124,8 +132,8 @@ static int drm_syncobj_fence_get_or_add_callback(struct
drm_syncobj *syncobj,
{
int ret;
- *fence = drm_syncobj_fence_get(syncobj);
- if (*fence)
+ ret = drm_syncobj_search_fence(syncobj, 0, 0, fence);
+ if (!ret)
return 1;
spin_lock(&syncobj->lock);
@@ -133,10 +141,12 @@ static int drm_syncobj_fence_get_or_add_callback(struct
drm_syncobj *syncobj,
* have the lock, try one more time just to be sure we don't add a
* callback when a fence has already been set.
*/
- if (syncobj->fence) {
- *fence = dma_fence_get(rcu_dereference_protected(syncobj->fence,
-
lockdep_is_held(&syncobj->lock)));
-
[Bug 201183] AMDGPU Dual displays and only DP screen works after grub.
https://bugzilla.kernel.org/show_bug.cgi?id=201183 Michel Dänzer (mic...@daenzer.net) changed: What|Removed |Added CC||harry.wentl...@amd.com, ||nicholas.kazlaus...@amd.com --- Comment #2 from Michel Dänzer (mic...@daenzer.net) --- For the time being, maybe amdgpu.dc=0 on the kernel command line can serve as a workaround. -- 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 libdrm 1/5] [libdrm] sync drm.h for syncobj part
Signed-off-by: Chunming Zhou
---
include/drm/drm.h | 24
1 file changed, 24 insertions(+)
diff --git a/include/drm/drm.h b/include/drm/drm.h
index f0bd91de..d1688269 100644
--- a/include/drm/drm.h
+++ b/include/drm/drm.h
@@ -695,6 +695,7 @@ struct drm_prime_handle {
struct drm_syncobj_create {
__u32 handle;
#define DRM_SYNCOBJ_CREATE_SIGNALED (1 << 0)
+#define DRM_SYNCOBJ_CREATE_TYPE_TIMELINE (1 << 1)
__u32 flags;
};
@@ -725,12 +726,32 @@ struct drm_syncobj_wait {
__u32 pad;
};
+struct drm_syncobj_timeline_wait {
+__u64 handles;
+/* wait on specific timeline point for every handles*/
+__u64 points;
+/* absolute timeout */
+__s64 timeout_nsec;
+__u32 count_handles;
+__u32 flags;
+__u32 first_signaled; /* only valid when not waiting all */
+__u32 pad;
+};
+
struct drm_syncobj_array {
__u64 handles;
__u32 count_handles;
__u32 pad;
};
+struct drm_syncobj_timeline_query {
+__u64 handles;
+/* points are timeline syncobjs payloads returned by query ioctl */
+__u64 points;
+__u32 count_handles;
+__u32 pad;
+};
+
/* Query current scanout sequence number */
struct drm_crtc_get_sequence {
__u32 crtc_id; /* requested crtc_id */
@@ -887,6 +908,9 @@ extern "C" {
#define DRM_IOCTL_MODE_GET_LEASE DRM_IOWR(0xC8, struct
drm_mode_get_lease)
#define DRM_IOCTL_MODE_REVOKE_LEASEDRM_IOWR(0xC9, struct
drm_mode_revoke_lease)
+#define DRM_IOCTL_SYNCOBJ_TIMELINE_WAIT DRM_IOWR(0xCA, struct
drm_syncobj_timeline_wait)
+#define DRM_IOCTL_SYNCOBJ_QUERY DRM_IOWR(0xCB, struct
drm_syncobj_timeline_query)
+
/**
* Device specific ioctls should only be in their respective headers
* The device specific ioctl range is from 0x40 to 0x9f.
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm 2/5] [libdrm] addr cs chunk for syncobj timeline
Signed-off-by: Chunming Zhou
---
include/drm/amdgpu_drm.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/include/drm/amdgpu_drm.h b/include/drm/amdgpu_drm.h
index c363b67f..b9f99587 100644
--- a/include/drm/amdgpu_drm.h
+++ b/include/drm/amdgpu_drm.h
@@ -482,6 +482,8 @@ struct drm_amdgpu_gem_va {
#define AMDGPU_CHUNK_ID_DEPENDENCIES 0x03
#define AMDGPU_CHUNK_ID_SYNCOBJ_IN 0x04
#define AMDGPU_CHUNK_ID_SYNCOBJ_OUT 0x05
+#define AMDGPU_CHUNK_ID_SYNCOBJ_TIMELINE_WAIT0x07
+#define AMDGPU_CHUNK_ID_SYNCOBJ_TIMELINE_SIGNAL 0x08
struct drm_amdgpu_cs_chunk {
__u32 chunk_id;
@@ -553,6 +555,14 @@ struct drm_amdgpu_cs_chunk_sem {
__u32 handle;
};
+struct drm_amdgpu_cs_chunk_syncobj {
+ __u32 handle;
+ __u32 pad;
+ __u64 point;
+ __u64 flags;
+};
+
+
#define AMDGPU_FENCE_TO_HANDLE_GET_SYNCOBJ 0
#define AMDGPU_FENCE_TO_HANDLE_GET_SYNCOBJ_FD 1
#define AMDGPU_FENCE_TO_HANDLE_GET_SYNC_FILE_FD2
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm 4/5] [libdrm]: wrap syncobj timeline query and wait for amdgpu v2
v2: symbos are stored in lexical order.
Signed-off-by: Chunming Zhou
---
amdgpu/amdgpu-symbol-check | 2 ++
amdgpu/amdgpu.h| 39 ++
amdgpu/amdgpu_cs.c | 24 +++
3 files changed, 65 insertions(+)
diff --git a/amdgpu/amdgpu-symbol-check b/amdgpu/amdgpu-symbol-check
index 58646e85..e6cd2205 100755
--- a/amdgpu/amdgpu-symbol-check
+++ b/amdgpu/amdgpu-symbol-check
@@ -47,8 +47,10 @@ amdgpu_cs_submit
amdgpu_cs_submit_raw
amdgpu_cs_syncobj_export_sync_file
amdgpu_cs_syncobj_import_sync_file
+amdgpu_cs_syncobj_query
amdgpu_cs_syncobj_reset
amdgpu_cs_syncobj_signal
+amdgpu_cs_syncobj_timeline_wait
amdgpu_cs_syncobj_wait
amdgpu_cs_wait_fences
amdgpu_cs_wait_semaphore
diff --git a/amdgpu/amdgpu.h b/amdgpu/amdgpu.h
index dc51659a..330658a0 100644
--- a/amdgpu/amdgpu.h
+++ b/amdgpu/amdgpu.h
@@ -1489,6 +1489,45 @@ int amdgpu_cs_syncobj_wait(amdgpu_device_handle dev,
int64_t timeout_nsec, unsigned flags,
uint32_t *first_signaled);
+/**
+ * Wait for one or all sync objects on their points to signal.
+ *
+ * \param dev- \c [in] self-explanatory
+ * \param handles - \c [in] array of sync object handles
+ * \param points - \c [in] array of sync points to wait
+ * \param num_handles - \c [in] self-explanatory
+ * \param timeout_nsec - \c [in] self-explanatory
+ * \param flags - \c [in] a bitmask of DRM_SYNCOBJ_WAIT_FLAGS_*
+ * \param first_signaled - \c [in] self-explanatory
+ *
+ * \return 0 on success\n
+ * -ETIME - Timeout
+ * <0 - Negative POSIX Error code
+ *
+ */
+int amdgpu_cs_syncobj_timeline_wait(amdgpu_device_handle dev,
+ uint32_t *handles, uint64_t *points,
+ unsigned num_handles,
+ int64_t timeout_nsec, unsigned flags,
+ uint32_t *first_signaled);
+/**
+ * Query sync objects payloads.
+ *
+ * \param dev- \c [in] self-explanatory
+ * \param handles - \c [in] array of sync object handles
+ * \param points - \c [out] array of sync points returned, which presents
+ * syncobj payload.
+ * \param num_handles - \c [in] self-explanatory
+ *
+ * \return 0 on success\n
+ * -ETIME - Timeout
+ * <0 - Negative POSIX Error code
+ *
+ */
+int amdgpu_cs_syncobj_query(amdgpu_device_handle dev,
+ uint32_t *handles, uint64_t *points,
+ unsigned num_handles);
+
/**
* Export kernel sync object to shareable fd.
*
diff --git a/amdgpu/amdgpu_cs.c b/amdgpu/amdgpu_cs.c
index 3c9be6c2..b32c0a75 100644
--- a/amdgpu/amdgpu_cs.c
+++ b/amdgpu/amdgpu_cs.c
@@ -658,6 +658,30 @@ int amdgpu_cs_syncobj_wait(amdgpu_device_handle dev,
flags, first_signaled);
}
+int amdgpu_cs_syncobj_timeline_wait(amdgpu_device_handle dev,
+ uint32_t *handles, uint64_t *points,
+ unsigned num_handles,
+ int64_t timeout_nsec, unsigned flags,
+ uint32_t *first_signaled)
+{
+ if (NULL == dev)
+ return -EINVAL;
+
+ return drmSyncobjTimelineWait(dev->fd, handles, points, num_handles,
+ timeout_nsec, flags, first_signaled);
+}
+
+int amdgpu_cs_syncobj_query(amdgpu_device_handle dev,
+ uint32_t *handles, uint64_t *points,
+ unsigned num_handles)
+{
+ if (NULL == dev)
+ return -EINVAL;
+
+ return drmSyncobjQuery(dev->fd, handles, points, num_handles);
+}
+
+
int amdgpu_cs_export_syncobj(amdgpu_device_handle dev,
uint32_t handle,
int *shared_fd)
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm 3/5] [libdrm]: add timeline wait/query ioctl
Signed-off-by: Chunming Zhou
---
xf86drm.c | 44
xf86drm.h | 6 ++
2 files changed, 50 insertions(+)
diff --git a/xf86drm.c b/xf86drm.c
index b2388194..0cd1cb75 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -4249,3 +4249,47 @@ int drmSyncobjSignal(int fd, const uint32_t *handles,
uint32_t handle_count)
ret = drmIoctl(fd, DRM_IOCTL_SYNCOBJ_SIGNAL, &args);
return ret;
}
+
+int drmSyncobjTimelineWait(int fd, uint32_t *handles, uint64_t *points,
+ unsigned num_handles,
+ int64_t timeout_nsec, unsigned flags,
+ uint32_t *first_signaled)
+{
+struct drm_syncobj_timeline_wait args;
+int ret;
+
+memclear(args);
+args.handles = (uintptr_t)handles;
+args.points = (uint64_t)(uintptr_t)points;
+args.timeout_nsec = timeout_nsec;
+args.count_handles = num_handles;
+args.flags = flags;
+
+ret = drmIoctl(fd, DRM_IOCTL_SYNCOBJ_TIMELINE_WAIT, &args);
+if (ret < 0)
+return -errno;
+
+if (first_signaled)
+*first_signaled = args.first_signaled;
+return ret;
+}
+
+
+int drmSyncobjQuery(int fd, uint32_t *handles, uint64_t *points,
+ uint32_t handle_count)
+{
+struct drm_syncobj_timeline_query args;
+int ret;
+
+memclear(args);
+args.handles = (uintptr_t)handles;
+args.points = (uint64_t)(uintptr_t)points;
+args.count_handles = handle_count;
+
+ret = drmIoctl(fd, DRM_IOCTL_SYNCOBJ_QUERY, &args);
+if (ret)
+return ret;
+return 0;
+}
+
+
diff --git a/xf86drm.h b/xf86drm.h
index 7773d71a..49a40633 100644
--- a/xf86drm.h
+++ b/xf86drm.h
@@ -875,6 +875,12 @@ extern int drmSyncobjWait(int fd, uint32_t *handles,
unsigned num_handles,
uint32_t *first_signaled);
extern int drmSyncobjReset(int fd, const uint32_t *handles, uint32_t
handle_count);
extern int drmSyncobjSignal(int fd, const uint32_t *handles, uint32_t
handle_count);
+extern int drmSyncobjTimelineWait(int fd, uint32_t *handles, uint64_t *points,
+ unsigned num_handles,
+ int64_t timeout_nsec, unsigned flags,
+ uint32_t *first_signaled);
+extern int drmSyncobjQuery(int fd, uint32_t *handles, uint64_t *points,
+ uint32_t handle_count);
#if defined(__cplusplus)
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm 5/5] [libdrm] add syncobj timeline tests
Signed-off-by: Chunming Zhou
---
tests/amdgpu/Makefile.am | 3 +-
tests/amdgpu/amdgpu_test.c | 12 ++
tests/amdgpu/amdgpu_test.h | 21 +++
tests/amdgpu/meson.build | 2 +-
tests/amdgpu/syncobj_tests.c | 259 +++
5 files changed, 295 insertions(+), 2 deletions(-)
create mode 100644 tests/amdgpu/syncobj_tests.c
diff --git a/tests/amdgpu/Makefile.am b/tests/amdgpu/Makefile.am
index e79c1bd3..61f2b426 100644
--- a/tests/amdgpu/Makefile.am
+++ b/tests/amdgpu/Makefile.am
@@ -32,4 +32,5 @@ amdgpu_test_SOURCES = \
vcn_tests.c \
uve_ib.h \
deadlock_tests.c \
- vm_tests.c
+ vm_tests.c \
+ syncobj_tests.c
diff --git a/tests/amdgpu/amdgpu_test.c b/tests/amdgpu/amdgpu_test.c
index 96fcd687..cdcb93a5 100644
--- a/tests/amdgpu/amdgpu_test.c
+++ b/tests/amdgpu/amdgpu_test.c
@@ -56,6 +56,7 @@
#define UVD_ENC_TESTS_STR "UVD ENC Tests"
#define DEADLOCK_TESTS_STR "Deadlock Tests"
#define VM_TESTS_STR "VM Tests"
+#define SYNCOBJ_TIMELINE_TESTS_STR "SYNCOBJ TIMELINE Tests"
/**
* Open handles for amdgpu devices
@@ -116,6 +117,12 @@ static CU_SuiteInfo suites[] = {
.pCleanupFunc = suite_vm_tests_clean,
.pTests = vm_tests,
},
+ {
+ .pName = SYNCOBJ_TIMELINE_TESTS_STR,
+ .pInitFunc = suite_syncobj_timeline_tests_init,
+ .pCleanupFunc = suite_syncobj_timeline_tests_clean,
+ .pTests = syncobj_timeline_tests,
+ },
CU_SUITE_INFO_NULL,
};
@@ -165,6 +172,11 @@ static Suites_Active_Status suites_active_stat[] = {
.pName = VM_TESTS_STR,
.pActive = suite_vm_tests_enable,
},
+ {
+ .pName = SYNCOBJ_TIMELINE_TESTS_STR,
+ .pActive = suite_syncobj_timeline_tests_enable,
+ },
+
};
diff --git a/tests/amdgpu/amdgpu_test.h b/tests/amdgpu/amdgpu_test.h
index f2ece3c3..960df046 100644
--- a/tests/amdgpu/amdgpu_test.h
+++ b/tests/amdgpu/amdgpu_test.h
@@ -194,6 +194,27 @@ CU_BOOL suite_vm_tests_enable(void);
*/
extern CU_TestInfo vm_tests[];
+/**
+ * Initialize syncobj timeline test suite
+ */
+int suite_syncobj_timeline_tests_init();
+
+/**
+ * Deinitialize syncobj timeline test suite
+ */
+int suite_syncobj_timeline_tests_clean();
+
+/**
+ * Decide if the suite is enabled by default or not.
+ */
+CU_BOOL suite_syncobj_timeline_tests_enable(void);
+
+/**
+ * Tests in syncobj timeline test suite
+ */
+extern CU_TestInfo syncobj_timeline_tests[];
+
+
/**
* Helper functions
*/
diff --git a/tests/amdgpu/meson.build b/tests/amdgpu/meson.build
index 4c1237c6..3ceec715 100644
--- a/tests/amdgpu/meson.build
+++ b/tests/amdgpu/meson.build
@@ -24,7 +24,7 @@ if dep_cunit.found()
files(
'amdgpu_test.c', 'basic_tests.c', 'bo_tests.c', 'cs_tests.c',
'vce_tests.c', 'uvd_enc_tests.c', 'vcn_tests.c', 'deadlock_tests.c',
- 'vm_tests.c',
+ 'vm_tests.c', 'syncobj_tests.c',
),
dependencies : [dep_cunit, dep_threads],
include_directories : [inc_root, inc_drm,
include_directories('../../amdgpu')],
diff --git a/tests/amdgpu/syncobj_tests.c b/tests/amdgpu/syncobj_tests.c
new file mode 100644
index ..a70bd92d
--- /dev/null
+++ b/tests/amdgpu/syncobj_tests.c
@@ -0,0 +1,259 @@
+/*
+ * Copyright 2017 Advanced Micro Devices, Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ *
+*/
+
+#include "CUnit/Basic.h"
+
+#include "amdgpu_test.h"
+#include "amdgpu_drm.h"
+#include "amdgpu_internal.h"
+#include
+
+static amdgpu_device_handle device_handle;
+static uint32_t major_version;
+static uint32_t minor_version;
+
+static void amdgpu_syncobj_timeline_test(void);
+
+CU_BOOL suite_syncobj_timeline_tests_enable(void)
+{
+ return CU_TRUE;
+}
+
+int suite_syncobj_timeline_tests_init(void)
+{
+ int r;
+
+ r = amdgpu
Re: [PATCH v2 0/4] Fix A64/R40 HDMI PHY device tree binding
On Sun, Sep 16, 2018 at 12:34:05PM +0800, Icenowy Zheng wrote: > When adding support for A64 HDMI PHY in 4.19, we assumed that the two > PLL-VIDEOs can both feed the HDMI PHY clock. However experiments show > that the mux bit discovered in R40 blob is not applicable on A64. This > is not discovered, as normally with a single display pipeline only > PLL-VIDEO0 will be used. > > In this patchset the second PLL is dropped, and a binding specially for > R40 HDMI PHY is added (which seems to have the mux). > > PATCH 1 is dropping second PLL for A64 HDMI PHY, and PATCH 2 to 4 > are adding R40 HDMI PHY binding, as R40 behaves differently with A64 > with this. > > This patchset targets v4.19 fixes tree, because the binding is > introduced in v4.19, and if we don't fix it there a wrong binding will > be left in a stable version released. A64 display pipeline support is > not yet in v4.19, but R40 support is in it. Applied 1 and 4 as fixes for 4.19, 2 and 3 for 4.20, since they are not fixes per se, and the R40 display engine is not enabled in 4.19 anyway. Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 201183] AMDGPU Dual displays and only DP screen works after grub.
https://bugzilla.kernel.org/show_bug.cgi?id=201183 --- Comment #3 from marten (marte...@gmail.com) --- Thank you Michel. That fixes it. -- 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 v4 19/25] drm/i915/dsc: Add a power domain for VDSC on eDP/MIPI DSI
On Tue, Sep 18, 2018 at 02:10:17PM -0700, Manasi Navare wrote:
> On Tue, Sep 18, 2018 at 10:46:46PM +0300, Ville Syrjälä wrote:
> > On Tue, Sep 18, 2018 at 12:31:54PM -0700, Manasi Navare wrote:
> > > On Tue, Sep 18, 2018 at 10:12:24PM +0300, Ville Syrjälä wrote:
> > > > On Tue, Sep 18, 2018 at 12:04:35PM -0700, Manasi Navare wrote:
> > > > > Thanks Imre for your review comments. Please find the comments below:
> > > > >
> > > > > On Fri, Sep 14, 2018 at 01:55:00PM +0300, Imre Deak wrote:
> > > > > > On Tue, Sep 11, 2018 at 05:56:01PM -0700, Manasi Navare wrote:
> > > > > > > On Icelake, a separate power well PG2 is created for
> > > > > > > VDSC engine used for eDP/MIPI DSI. This patch adds a new
> > > > > > > display power domain for Power well 2.
> > > > > > >
> > > > > > > Cc: Rodrigo Vivi
> > > > > > > Cc: Imre Deak
> > > > > > > Signed-off-by: Manasi Navare
> > > > > > > ---
> > > > > > > drivers/gpu/drm/i915/intel_display.h| 1 +
> > > > > > > drivers/gpu/drm/i915/intel_runtime_pm.c | 12 ++--
> > > > > > > 2 files changed, 7 insertions(+), 6 deletions(-)
> > > > > > >
> > > > > > > diff --git a/drivers/gpu/drm/i915/intel_display.h
> > > > > > > b/drivers/gpu/drm/i915/intel_display.h
> > > > > > > index 3fe52788b4cf..bef71d27cdfe 100644
> > > > > > > --- a/drivers/gpu/drm/i915/intel_display.h
> > > > > > > +++ b/drivers/gpu/drm/i915/intel_display.h
> > > > > > > @@ -256,6 +256,7 @@ enum intel_display_power_domain {
> > > > > > > POWER_DOMAIN_MODESET,
> > > > > > > POWER_DOMAIN_GT_IRQ,
> > > > > > > POWER_DOMAIN_INIT,
> > > > > > > + POWER_DOMAIN_VDSC_EDP_MIPI,
> > > > > >
> > > > > > This is better named VDSC_PIPE_A. The other pipes have also VDSC
> > > > > > functionality which could be on separate power wells in the future.
> > > > > >
> > > > >
> > > > > Yea naming it as VDSC_PIPE_A makes sense since eDP/MIPI DSI on Pipe A
> > > > > will use this VDSC power well.
> > > > > I will change this in the next revision.
> > > >
> > > > Isn't the VDSC in the transcoder for now though? And I guess it's
> > > > moving to the pipe later?
> > >
> > > VDSC engine is attached to the eDP/DSI transcoders and this gets used
> > > for eDP/DSI VDSC on Pipe A.
> >
> > And what happens when I want to use pipe B instead?
>
> DP VDSC on Pipe B uses the VDSC engine on Pipe B. Same for Pipe C
There are no VDSCs in pipe B or C. There are VDSCs in transcoder B
and C. But that's not the same thing at all. The mux is between the
pipe and transcoder.
> Can we have a situation where eDP uses Pipe B?
Sure. 'xrandr --output eDP --crtc 1', or whatever.
> Because in case of VDSC
> in case of eDP, it will always use the VDSC on transcoder eDP which will
> require this power well.
>
> Manasi
>
> >
> > > So we could call it VDSC_PIPE_A since VDSC on Pipe A for eDP/DSI
> > > will use this power well. But may be we should add a comment that
> > > this is only for eDP/DSI on Pipe A since ICL does not support
> > > VDSC on DP on Pipe A
> > >
> > > What do you think?
> > >
> > > Manasi
> > >
> > > >
> > > > If we call it PIPE_A then it's going to a bit confusing when we
> > > > use it with pipe B or C. Needs at least clear comments in the code
> > > > why we're doing something that looks like nonsense of the first
> > > > glance.
> > > >
> > > > --
> > > > Ville Syrjälä
> > > > Intel
> >
> > --
> > Ville Syrjälä
> > Intel
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 4/5] drm/bochs: support changing byteorder at mode set time
Add bochs_hw_set_*_endian() helper functions, to set the framebuffer
byteorder at mode set time. Support both DRM_FORMAT_XRGB and
DRM_FORMAT_BGRX framebuffer formats, no matter what the native
machine byte order is.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/bochs/bochs.h | 4 ++-
drivers/gpu/drm/bochs/bochs_fbdev.c | 3 +-
drivers/gpu/drm/bochs/bochs_hw.c| 64 +
drivers/gpu/drm/bochs/bochs_kms.c | 8 +++--
4 files changed, 61 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/bochs/bochs.h b/drivers/gpu/drm/bochs/bochs.h
index b4f6bb5219..e7a69077e4 100644
--- a/drivers/gpu/drm/bochs/bochs.h
+++ b/drivers/gpu/drm/bochs/bochs.h
@@ -58,6 +58,7 @@ struct bochs_device {
void __iomem *fb_map;
unsigned long fb_base;
unsigned long fb_size;
+ unsigned long qext_size;
/* mode */
u16 xres;
@@ -121,7 +122,8 @@ int bochs_hw_init(struct drm_device *dev);
void bochs_hw_fini(struct drm_device *dev);
void bochs_hw_setmode(struct bochs_device *bochs,
- struct drm_display_mode *mode);
+ struct drm_display_mode *mode,
+ const struct drm_format_info *format);
void bochs_hw_setbase(struct bochs_device *bochs,
int x, int y, u64 addr);
diff --git a/drivers/gpu/drm/bochs/bochs_fbdev.c
b/drivers/gpu/drm/bochs/bochs_fbdev.c
index c46fdae44e..dd3c7df267 100644
--- a/drivers/gpu/drm/bochs/bochs_fbdev.c
+++ b/drivers/gpu/drm/bochs/bochs_fbdev.c
@@ -140,7 +140,8 @@ static struct drm_framebuffer *
bochs_gem_fb_create(struct drm_device *dev, struct drm_file *file,
const struct drm_mode_fb_cmd2 *mode_cmd)
{
- if (mode_cmd->pixel_format != DRM_FORMAT_HOST_XRGB)
+ if (mode_cmd->pixel_format != DRM_FORMAT_XRGB &&
+ mode_cmd->pixel_format != DRM_FORMAT_BGRX)
return ERR_PTR(-EINVAL);
return drm_gem_fb_create(dev, file, mode_cmd);
diff --git a/drivers/gpu/drm/bochs/bochs_hw.c b/drivers/gpu/drm/bochs/bochs_hw.c
index 16e4f1cacc..cacff73a64 100644
--- a/drivers/gpu/drm/bochs/bochs_hw.c
+++ b/drivers/gpu/drm/bochs/bochs_hw.c
@@ -47,11 +47,33 @@ static void bochs_dispi_write(struct bochs_device *bochs,
u16 reg, u16 val)
}
}
+static void bochs_hw_set_big_endian(struct bochs_device *bochs)
+{
+ if (bochs->qext_size < 8)
+ return;
+
+ writel(0xbebebebe, bochs->mmio + 0x604);
+}
+
+static void bochs_hw_set_little_endian(struct bochs_device *bochs)
+{
+ if (bochs->qext_size < 8)
+ return;
+
+ writel(0x1e1e1e1e, bochs->mmio + 0x604);
+}
+
+#ifdef __BIG_ENDIAN
+#define bochs_hw_set_native_endian(_b) bochs_hw_set_big_endian(_b)
+#else
+#define bochs_hw_set_native_endian(_b) bochs_hw_set_little_endian(_b)
+#endif
+
int bochs_hw_init(struct drm_device *dev)
{
struct bochs_device *bochs = dev->dev_private;
struct pci_dev *pdev = dev->pdev;
- unsigned long addr, size, mem, ioaddr, iosize, qext_size;
+ unsigned long addr, size, mem, ioaddr, iosize;
u16 id;
if (pdev->resource[2].flags & IORESOURCE_MEM) {
@@ -117,19 +139,14 @@ int bochs_hw_init(struct drm_device *dev)
ioaddr);
if (bochs->mmio && pdev->revision >= 2) {
- qext_size = readl(bochs->mmio + 0x600);
- if (qext_size < 4 || qext_size > iosize)
+ bochs->qext_size = readl(bochs->mmio + 0x600);
+ if (bochs->qext_size < 4 || bochs->qext_size > iosize) {
+ bochs->qext_size = 0;
goto noext;
- DRM_DEBUG("Found qemu ext regs, size %ld\n", qext_size);
- if (qext_size >= 8) {
-#ifdef __BIG_ENDIAN
- writel(0xbebebebe, bochs->mmio + 0x604);
-#else
- writel(0x1e1e1e1e, bochs->mmio + 0x604);
-#endif
- DRM_DEBUG(" qext endian: 0x%x\n",
- readl(bochs->mmio + 0x604));
}
+ DRM_DEBUG("Found qemu ext regs, size %ld\n",
+ bochs->qext_size);
+ bochs_hw_set_native_endian(bochs);
}
noext:
@@ -150,7 +167,8 @@ void bochs_hw_fini(struct drm_device *dev)
}
void bochs_hw_setmode(struct bochs_device *bochs,
- struct drm_display_mode *mode)
+ struct drm_display_mode *mode,
+ const struct drm_format_info *format)
{
bochs->xres = mode->hdisplay;
bochs->yres = mode->vdisplay;
@@ -158,8 +176,12 @@ void bochs_hw_setmode(struct bochs_device *bochs,
bochs->stride = mode->hdisplay * (bochs->bpp / 8);
bochs->yres_virtual = bochs->fb_size / bochs->stride;
- DRM_DEBUG_DRIVER("%dx%d @ %d bpp, vy %d\n",
+ DRM_DEBUG_DRIVER("%dx%d @ %d bpp, format %c%c%c%c, vy %d\n",
bochs->xres,
[PATCH v3 0/5] drm: more byteorder fixes
Fix fbdev emulation. Fix bochs-drm and virtio-gpu drivers. Gerd Hoffmann (5): drm: move native byte order quirk to new drm_mode_legacy_fb_format2 function drm: use drm_mode_legacy_fb_format2 in drm_gem_fbdev_fb_create drm/bochs: fix DRM_FORMAT_* handling for big endian machines. drm/bochs: support changing byteorder at mode set time drm/virtio: fix DRM_FORMAT_* handling drivers/gpu/drm/bochs/bochs.h| 4 +- include/drm/drm_fourcc.h | 2 + drivers/gpu/drm/bochs/bochs_fbdev.c | 18 ++-- drivers/gpu/drm/bochs/bochs_hw.c | 64 ++-- drivers/gpu/drm/bochs/bochs_kms.c| 40 - drivers/gpu/drm/drm_fourcc.c | 28 drivers/gpu/drm/drm_framebuffer.c| 15 ++- drivers/gpu/drm/drm_gem_framebuffer_helper.c | 6 ++- drivers/gpu/drm/virtio/virtgpu_display.c | 5 +++ drivers/gpu/drm/virtio/virtgpu_fb.c | 2 +- drivers/gpu/drm/virtio/virtgpu_gem.c | 7 ++- drivers/gpu/drm/virtio/virtgpu_plane.c | 54 +-- 12 files changed, 155 insertions(+), 90 deletions(-) -- 2.9.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/5] drm: use drm_mode_legacy_fb_format2 in drm_gem_fbdev_fb_create
Creating framebuffers for fbdev emulation should use the correct format
code too, so switch drm_gem_fbdev_fb_create() over to use the new
drm_mode_legacy_fb_format2() function.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/drm_gem_framebuffer_helper.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
index 7607f9cd6f..3619f1c78a 100644
--- a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
+++ b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
@@ -308,6 +308,7 @@ drm_gem_fbdev_fb_create(struct drm_device *dev,
const struct drm_framebuffer_funcs *funcs)
{
struct drm_mode_fb_cmd2 mode_cmd = { 0 };
+ bool native = dev->mode_config.quirk_addfb_prefer_host_byte_order;
mode_cmd.width = sizes->surface_width;
mode_cmd.height = sizes->surface_height;
@@ -316,8 +317,9 @@ drm_gem_fbdev_fb_create(struct drm_device *dev,
if (pitch_align)
mode_cmd.pitches[0] = roundup(mode_cmd.pitches[0],
pitch_align);
- mode_cmd.pixel_format = drm_mode_legacy_fb_format(sizes->surface_bpp,
- sizes->surface_depth);
+ mode_cmd.pixel_format = drm_mode_legacy_fb_format2(sizes->surface_bpp,
+ sizes->surface_depth,
+ native);
if (obj->size < mode_cmd.pitches[0] * mode_cmd.height)
return ERR_PTR(-EINVAL);
--
2.9.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 5/5] drm/virtio: fix DRM_FORMAT_* handling
Use DRM_FORMAT_HOST_XRGB, so we are using the correct format code
on bigendian machines. Also set the quirk_addfb_prefer_host_byte_order
mode_config bit so drm_mode_addfb() asks for the correct format code.
Both DRM_FORMAT_* and VIRTIO_GPU_FORMAT_* are defined to be little
endian, so using a different mapping on bigendian machines is wrong.
It's there because of broken drm_mode_addfb() behavior. So with
drm_mode_addfb() being fixed we can fix this too.
While wading through the code I've noticed we have a little issue in
virtio: We attach a format to the bo when it is created
(DRM_IOCTL_MODE_CREATE_DUMB), not when we map it as framebuffer
(DRM_IOCTL_MODE_ADDFB). Easy way out: Support a single format only.
Pick DRM_FORMAT_HOST_XRGB, it is the only one actually used in
practice. Drop unused mappings in virtio_gpu_translate_format().
With this patch applied both ADDFB and ADDFB2 ioctls work correctly in
the virtio-gpu.ko driver on big endian machines. Without the patch only
ADDFB (which still seems to be used by the majority of userspace) works
correctly.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_display.c | 5 +++
drivers/gpu/drm/virtio/virtgpu_fb.c | 2 +-
drivers/gpu/drm/virtio/virtgpu_gem.c | 7 +++--
drivers/gpu/drm/virtio/virtgpu_plane.c | 54 ++--
4 files changed, 13 insertions(+), 55 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c
b/drivers/gpu/drm/virtio/virtgpu_display.c
index 0379d68976..8f8fed471e 100644
--- a/drivers/gpu/drm/virtio/virtgpu_display.c
+++ b/drivers/gpu/drm/virtio/virtgpu_display.c
@@ -307,6 +307,10 @@ virtio_gpu_user_framebuffer_create(struct drm_device *dev,
struct virtio_gpu_framebuffer *virtio_gpu_fb;
int ret;
+ if (mode_cmd->pixel_format != DRM_FORMAT_HOST_XRGB &&
+ mode_cmd->pixel_format != DRM_FORMAT_HOST_ARGB)
+ return ERR_PTR(-ENOENT);
+
/* lookup object associated with res handle */
obj = drm_gem_object_lookup(file_priv, mode_cmd->handles[0]);
if (!obj)
@@ -355,6 +359,7 @@ int virtio_gpu_modeset_init(struct virtio_gpu_device *vgdev)
int i;
drm_mode_config_init(vgdev->ddev);
+ vgdev->ddev->mode_config.quirk_addfb_prefer_host_byte_order = true;
vgdev->ddev->mode_config.funcs = &virtio_gpu_mode_funcs;
vgdev->ddev->mode_config.helper_private = &virtio_mode_config_helpers;
diff --git a/drivers/gpu/drm/virtio/virtgpu_fb.c
b/drivers/gpu/drm/virtio/virtgpu_fb.c
index b5cebc9a17..6c89974c7f 100644
--- a/drivers/gpu/drm/virtio/virtgpu_fb.c
+++ b/drivers/gpu/drm/virtio/virtgpu_fb.c
@@ -233,7 +233,7 @@ static int virtio_gpufb_create(struct drm_fb_helper *helper,
mode_cmd.width = sizes->surface_width;
mode_cmd.height = sizes->surface_height;
mode_cmd.pitches[0] = mode_cmd.width * 4;
- mode_cmd.pixel_format = drm_mode_legacy_fb_format(32, 24);
+ mode_cmd.pixel_format = DRM_FORMAT_HOST_XRGB;
format = virtio_gpu_translate_format(mode_cmd.pixel_format);
if (format == 0)
diff --git a/drivers/gpu/drm/virtio/virtgpu_gem.c
b/drivers/gpu/drm/virtio/virtgpu_gem.c
index 0f2768eaca..82c817f37c 100644
--- a/drivers/gpu/drm/virtio/virtgpu_gem.c
+++ b/drivers/gpu/drm/virtio/virtgpu_gem.c
@@ -90,7 +90,10 @@ int virtio_gpu_mode_dumb_create(struct drm_file *file_priv,
uint32_t resid;
uint32_t format;
- pitch = args->width * ((args->bpp + 1) / 8);
+ if (args->bpp != 32)
+ return -EINVAL;
+
+ pitch = args->width * 4;
args->size = pitch * args->height;
args->size = ALIGN(args->size, PAGE_SIZE);
@@ -99,7 +102,7 @@ int virtio_gpu_mode_dumb_create(struct drm_file *file_priv,
if (ret)
goto fail;
- format = virtio_gpu_translate_format(DRM_FORMAT_XRGB);
+ format = virtio_gpu_translate_format(DRM_FORMAT_HOST_XRGB);
virtio_gpu_resource_id_get(vgdev, &resid);
virtio_gpu_cmd_create_resource(vgdev, resid, format,
args->width, args->height);
diff --git a/drivers/gpu/drm/virtio/virtgpu_plane.c
b/drivers/gpu/drm/virtio/virtgpu_plane.c
index 88f2fb8c61..a84ff56507 100644
--- a/drivers/gpu/drm/virtio/virtgpu_plane.c
+++ b/drivers/gpu/drm/virtio/virtgpu_plane.c
@@ -28,22 +28,11 @@
#include
static const uint32_t virtio_gpu_formats[] = {
- DRM_FORMAT_XRGB,
- DRM_FORMAT_ARGB,
- DRM_FORMAT_BGRX,
- DRM_FORMAT_BGRA,
- DRM_FORMAT_RGBX,
- DRM_FORMAT_RGBA,
- DRM_FORMAT_XBGR,
- DRM_FORMAT_ABGR,
+ DRM_FORMAT_HOST_XRGB,
};
static const uint32_t virtio_gpu_cursor_formats[] = {
-#ifdef __BIG_ENDIAN
- DRM_FORMAT_BGRA,
-#else
- DRM_FORMAT_ARGB,
-#endif
+ DRM_FORMAT_HOST_ARGB,
};
uint32_t virtio_gpu_translate_format(uint32_t drm_fourcc)
@@ -51,32 +40,6 @@ uint3
[PATCH v3 1/5] drm: move native byte order quirk to new drm_mode_legacy_fb_format2 function
Turns out we need the pixel format fixup not only for the addfb ioctl,
but also for fbdev emulation code.
Ideally we would place it in drm_mode_legacy_fb_format(). That would
create alot of churn though, and most drivers don't care because they
never ever run on a big endian platform. So add a new
drm_mode_legacy_fb_format2() function instead.
Signed-off-by: Gerd Hoffmann
---
include/drm/drm_fourcc.h | 2 ++
drivers/gpu/drm/drm_fourcc.c | 28
drivers/gpu/drm/drm_framebuffer.c | 15 +++
3 files changed, 33 insertions(+), 12 deletions(-)
diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
index fac831c401..4b82bb6576 100644
--- a/include/drm/drm_fourcc.h
+++ b/include/drm/drm_fourcc.h
@@ -88,6 +88,8 @@ const struct drm_format_info *
drm_get_format_info(struct drm_device *dev,
const struct drm_mode_fb_cmd2 *mode_cmd);
uint32_t drm_mode_legacy_fb_format(uint32_t bpp, uint32_t depth);
+uint32_t drm_mode_legacy_fb_format2(uint32_t bpp, uint32_t depth,
+ bool native);
int drm_format_num_planes(uint32_t format);
int drm_format_plane_cpp(uint32_t format, int plane);
int drm_format_horz_chroma_subsampling(uint32_t format);
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index be1d6aaef6..1c1aaa8b23 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -96,6 +96,34 @@ uint32_t drm_mode_legacy_fb_format(uint32_t bpp, uint32_t
depth)
EXPORT_SYMBOL(drm_mode_legacy_fb_format);
/**
+ * drm_mode_legacy_fb_format2 - compute drm fourcc code from legacy description
+ * @bpp: bits per pixels
+ * @depth: bit depth per pixel
+ * @native: use host native byte order
+ *
+ * Computes a drm fourcc pixel format code for the given @bpp/@depth values.
+ * Useful in fbdev emulation code, since that deals in those values.
+ */
+uint32_t drm_mode_legacy_fb_format2(uint32_t bpp, uint32_t depth,
+ bool native)
+{
+ uint32_t fmt = drm_mode_legacy_fb_format(bpp, depth);
+
+ if (native) {
+ if (fmt == DRM_FORMAT_XRGB)
+ fmt = DRM_FORMAT_HOST_XRGB;
+ if (fmt == DRM_FORMAT_ARGB)
+ fmt = DRM_FORMAT_HOST_ARGB;
+ if (fmt == DRM_FORMAT_RGB565)
+ fmt = DRM_FORMAT_HOST_RGB565;
+ if (fmt == DRM_FORMAT_XRGB1555)
+ fmt = DRM_FORMAT_HOST_XRGB1555;
+ }
+ return fmt;
+}
+EXPORT_SYMBOL(drm_mode_legacy_fb_format2);
+
+/**
* drm_get_format_name - fill a string with a drm fourcc format's name
* @format: format to compute name of
* @buf: caller-supplied buffer
diff --git a/drivers/gpu/drm/drm_framebuffer.c
b/drivers/gpu/drm/drm_framebuffer.c
index 1ee3d6b442..f72e3dffc7 100644
--- a/drivers/gpu/drm/drm_framebuffer.c
+++ b/drivers/gpu/drm/drm_framebuffer.c
@@ -111,12 +111,14 @@ int drm_mode_addfb(struct drm_device *dev, struct
drm_mode_fb_cmd *or,
struct drm_file *file_priv)
{
struct drm_mode_fb_cmd2 r = {};
+ bool native = dev->mode_config.quirk_addfb_prefer_host_byte_order;
int ret;
if (!drm_core_check_feature(dev, DRIVER_MODESET))
return -EOPNOTSUPP;
- r.pixel_format = drm_mode_legacy_fb_format(or->bpp, or->depth);
+ r.pixel_format = drm_mode_legacy_fb_format2(or->bpp, or->depth,
+ native);
if (r.pixel_format == DRM_FORMAT_INVALID) {
DRM_DEBUG("bad {bpp:%d, depth:%d}\n", or->bpp, or->depth);
return -EINVAL;
@@ -133,17 +135,6 @@ int drm_mode_addfb(struct drm_device *dev, struct
drm_mode_fb_cmd *or,
r.pixel_format == DRM_FORMAT_XRGB2101010)
r.pixel_format = DRM_FORMAT_XBGR2101010;
- if (dev->mode_config.quirk_addfb_prefer_host_byte_order) {
- if (r.pixel_format == DRM_FORMAT_XRGB)
- r.pixel_format = DRM_FORMAT_HOST_XRGB;
- if (r.pixel_format == DRM_FORMAT_ARGB)
- r.pixel_format = DRM_FORMAT_HOST_ARGB;
- if (r.pixel_format == DRM_FORMAT_RGB565)
- r.pixel_format = DRM_FORMAT_HOST_RGB565;
- if (r.pixel_format == DRM_FORMAT_XRGB1555)
- r.pixel_format = DRM_FORMAT_HOST_XRGB1555;
- }
-
ret = drm_mode_addfb2(dev, &r, file_priv);
if (ret)
return ret;
--
2.9.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 3/5] drm/bochs: fix DRM_FORMAT_* handling for big endian machines.
Use DRM_FORMAT_HOST_XRGB, so we are using the correct format code
on bigendian machines. Also set the quirk_addfb_prefer_host_byte_order
mode_config bit so drm_mode_addfb() asks for the correct format code.
Create our own plane and use drm_crtc_init_with_planes() instead of
depending on the default created by drm_crtc_init(). That way the plane
format list is correct on bigendian machines.
Also re-add the framebuffer format check dropped by "df2052cc92 bochs:
convert to drm_fb_helper_fbdev_setup/teardown".
With this patch applied both ADDFB and ADDFB2 ioctls work correctly in
the bochs-drm.ko driver on big endian machines. Without the patch only
ADDFB (which still seems to be used by the majority of userspace) works
correctly.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/bochs/bochs_fbdev.c | 17 +
drivers/gpu/drm/bochs/bochs_kms.c | 34 +-
2 files changed, 46 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/bochs/bochs_fbdev.c
b/drivers/gpu/drm/bochs/bochs_fbdev.c
index 8f4d6c052f..c46fdae44e 100644
--- a/drivers/gpu/drm/bochs/bochs_fbdev.c
+++ b/drivers/gpu/drm/bochs/bochs_fbdev.c
@@ -63,9 +63,8 @@ static int bochsfb_create(struct drm_fb_helper *helper,
mode_cmd.width = sizes->surface_width;
mode_cmd.height = sizes->surface_height;
- mode_cmd.pitches[0] = mode_cmd.width * ((sizes->surface_bpp + 7) / 8);
- mode_cmd.pixel_format = drm_mode_legacy_fb_format(sizes->surface_bpp,
- sizes->surface_depth);
+ mode_cmd.pitches[0] = sizes->surface_width * 4;
+ mode_cmd.pixel_format = DRM_FORMAT_HOST_XRGB;
size = mode_cmd.pitches[0] * mode_cmd.height;
/* alloc, pin & map bo */
@@ -137,8 +136,18 @@ static const struct drm_fb_helper_funcs
bochs_fb_helper_funcs = {
.fb_probe = bochsfb_create,
};
+static struct drm_framebuffer *
+bochs_gem_fb_create(struct drm_device *dev, struct drm_file *file,
+ const struct drm_mode_fb_cmd2 *mode_cmd)
+{
+ if (mode_cmd->pixel_format != DRM_FORMAT_HOST_XRGB)
+ return ERR_PTR(-EINVAL);
+
+ return drm_gem_fb_create(dev, file, mode_cmd);
+}
+
const struct drm_mode_config_funcs bochs_mode_funcs = {
- .fb_create = drm_gem_fb_create,
+ .fb_create = bochs_gem_fb_create,
};
int bochs_fbdev_init(struct bochs_device *bochs)
diff --git a/drivers/gpu/drm/bochs/bochs_kms.c
b/drivers/gpu/drm/bochs/bochs_kms.c
index ea9a43d31b..f3fdaf9456 100644
--- a/drivers/gpu/drm/bochs/bochs_kms.c
+++ b/drivers/gpu/drm/bochs/bochs_kms.c
@@ -126,12 +126,43 @@ static const struct drm_crtc_helper_funcs
bochs_helper_funcs = {
.commit = bochs_crtc_commit,
};
+static const uint32_t bochs_formats[] = {
+ DRM_FORMAT_HOST_XRGB,
+};
+
+static struct drm_plane *bochs_primary_plane(struct drm_device *dev)
+{
+ struct drm_plane *primary;
+ int ret;
+
+ primary = kzalloc(sizeof(*primary), GFP_KERNEL);
+ if (primary == NULL) {
+ DRM_DEBUG_KMS("Failed to allocate primary plane\n");
+ return NULL;
+ }
+
+ ret = drm_universal_plane_init(dev, primary, 0,
+ &drm_primary_helper_funcs,
+ bochs_formats,
+ ARRAY_SIZE(bochs_formats),
+ NULL,
+ DRM_PLANE_TYPE_PRIMARY, NULL);
+ if (ret) {
+ kfree(primary);
+ primary = NULL;
+ }
+
+ return primary;
+}
+
static void bochs_crtc_init(struct drm_device *dev)
{
struct bochs_device *bochs = dev->dev_private;
struct drm_crtc *crtc = &bochs->crtc;
+ struct drm_plane *primary = bochs_primary_plane(dev);
- drm_crtc_init(dev, crtc, &bochs_crtc_funcs);
+ drm_crtc_init_with_planes(dev, crtc, primary, NULL,
+ &bochs_crtc_funcs, NULL);
drm_crtc_helper_add(crtc, &bochs_helper_funcs);
}
@@ -250,6 +281,7 @@ int bochs_kms_init(struct bochs_device *bochs)
bochs->dev->mode_config.fb_base = bochs->fb_base;
bochs->dev->mode_config.preferred_depth = 24;
bochs->dev->mode_config.prefer_shadow = 0;
+ bochs->dev->mode_config.quirk_addfb_prefer_host_byte_order = true;
bochs->dev->mode_config.funcs = &bochs_mode_funcs;
--
2.9.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/virtio: add dma sync for dma mapped virtio gpu framebuffer pages
On Wed, Sep 19, 2018 at 07:09:53AM +, An, Jiandi wrote: > With virtio gpu ttm-pages being dma mapped, dma sync is needed when > swiotlb is used as bounce buffers, before TRANSFER_TO_HOST_2D/3D > commands are sent. Pushed to drm-misc-next. thanks, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [virtio-dev] [PATCH 2/2] drm/virtio: add iommu support.
> >> Once display manger is kicked off for example (sudo systemctl start > >> lightdm.service) and > >> resource id 3 gets created from user space down, it still gives a blank > >> black screen. > > > > Hmm. I'd suspect there is simply a code path missing. Can you send the > > patch you have? > > > > cheers, > > Gerd > > > > I sent the patch. For now it does dma_sync_sg on the pages in > TRANSFER_TO_HOST_2D/3D when use_dma_api is true. > > https://lore.kernel.org/lkml/20180919070931.91168-1-jiandi...@amd.com/ Hmm, the way it is hooked up it should not miss any resource update. So not sure why it isn't working. Pushed the patch nevertheless as it is clearly a step into the right direction. cheers, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/i915: re-check the hotplug with a delayed work
Quoting Chris Chiu (2018-09-19 12:29:33)
> I have few ASUS laptops, X705FD(Intel i7-8565), X560UD(Intel i5-8250U)
> and X530UN(Intel i7-8550U) share the same problem. The HDMI connector
> status stays 'connected' even the HDMI cable has been unplugged.
> Then the status in sysfs would never change since then until we
> do 'xrandr' to reprobe the devices. It would also cause the audio
> output path cannot correctly swicth based on the connector status.
>
> This commit kicks off a delayed work when the status remains unchanged
> in the first hotplug event handling, which may not be the perfect
> timing in some special cases.
>
> Signed-off-by: Chris Chiu
> ---
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> drivers/gpu/drm/i915/intel_hotplug.c | 35 +++
> 2 files changed, 32 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index d51d8574a679..78e2cf09cc10 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -286,6 +286,7 @@ struct i915_hotplug {
> } stats[HPD_NUM_PINS];
> u32 event_bits;
> struct delayed_work reenable_work;
> + struct delayed_work recheck_work;
>
> struct intel_digital_port *irq_port[I915_MAX_PORTS];
> u32 long_port_mask;
> diff --git a/drivers/gpu/drm/i915/intel_hotplug.c
> b/drivers/gpu/drm/i915/intel_hotplug.c
> index 43aa92beff2a..089a24588ec8 100644
> --- a/drivers/gpu/drm/i915/intel_hotplug.c
> +++ b/drivers/gpu/drm/i915/intel_hotplug.c
> @@ -349,14 +349,15 @@ static void i915_digport_work_func(struct work_struct
> *work)
> }
> }
>
> +#define HPD_RECHECK_DELAY(2 * 1000)
Or just (2 * HZ)
> /*
> * Handle hotplug events outside the interrupt handler proper.
> */
> -static void i915_hotplug_work_func(struct work_struct *work)
> +static void do_i915_hotplug_check(struct work_struct *work,
> + struct drm_i915_private *dev_priv,
> + struct drm_device *dev, bool do_recheck)
struct drm_i915_private == struct drm_device, no need for tautology
Local struct drm_device *dev = &i915->drm; are eliminated by the
compiler.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 1/1] drm/mediatek: add function to match the connector and crtc
Hi, Stu:
On Wed, 2018-09-12 at 14:02 +0800, Stu Hsieh wrote:
> This patch add function to match the connector and crtc
>
> Because the connector set the possible_crtc to match the crtc.
>
> This function would search the connector in every ddp path and
> return the corresponding value for possible_crtc.
>
> Change-Id: Id51de53b95039f8174462d483eb9bfee31b3b93b
> Signed-off-by: Stu Hsieh
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 41
> +
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 2 ++
> 2 files changed, 43 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> index ff974d82a4a6..1f734b806a00 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> @@ -245,6 +245,22 @@ static const struct mtk_ddp_comp_match
> mtk_ddp_matches[DDP_COMPONENT_ID_MAX] = {
> [DDP_COMPONENT_WDMA1] = { MTK_DISP_WDMA, 1, NULL },
> };
>
> +static bool mtk_drm_find_comp_in_ddp(struct mtk_ddp_comp ddp_comp,
> + const enum mtk_ddp_comp_id *path,
> + unsigned int path_len)
> +{
> + int i;
> +
> + if (!path)
> + return false;
> +
> + for (i = 0; i < path_len; i++)
> + if (ddp_comp.id == path[i])
> + return true;
> +
> + return false;
> +}
> +
> int mtk_ddp_comp_get_id(struct device_node *node,
> enum mtk_ddp_comp_type comp_type)
> {
> @@ -260,6 +276,31 @@ int mtk_ddp_comp_get_id(struct device_node *node,
> return -EINVAL;
> }
>
> +unsigned int mtk_drm_find_possible_crtc_by_comp(struct drm_device *drm,
> + struct mtk_ddp_comp ddp_comp)
> +{
> + struct mtk_drm_private *private = drm->dev_private;
> + unsigned int ret;
> +
> + if (mtk_drm_find_comp_in_ddp(ddp_comp, private->data->main_path,
> + private->data->main_len) == true) {
> + ret = BIT(0);
> + } else if (mtk_drm_find_comp_in_ddp(ddp_comp,
> + private->data->ext_path,
> + private->data->ext_len) == true) {
> + ret = BIT(1);
> + } else if (mtk_drm_find_comp_in_ddp(ddp_comp,
> + private->data->third_path,
> + private->data->third_len) == true) {
> + ret = BIT(2);
> + } else {
> + DRM_INFO("Failed to find comp in ddp table\n");
> + ret = 0;
> + }
The variable naming is very important. If one day there are fourth path,
fifth path, and sixth path, you would find everywhere where are such 'if
else'. So I would like you to change main_path, ext_path, third_path to
an array such as path[]. So this patch would be only a simple for-loop
and when you add more path, you need not to modify this function.
And would you also send the patch that include the caller call
mtk_drm_find_possible_crtc_by_comp(), so I could understand how do you
pass the parameter.
Regards,
CK
> +
> + return ret;
> +}
> +
> int mtk_ddp_comp_init(struct device *dev, struct device_node *node,
> struct mtk_ddp_comp *comp, enum mtk_ddp_comp_id comp_id,
> const struct mtk_ddp_comp_funcs *funcs)
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> index 8399229e6ad2..f882e69088b8 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> @@ -166,6 +166,8 @@ static inline void mtk_ddp_gamma_set(struct mtk_ddp_comp
> *comp,
> comp->funcs->gamma_set(comp, state);
> }
>
> +unsigned int mtk_drm_find_possible_crtc_by_comp(struct drm_device *drm,
> + struct mtk_ddp_comp ddp_comp);
> int mtk_ddp_comp_get_id(struct device_node *node,
> enum mtk_ddp_comp_type comp_type);
> int mtk_ddp_comp_init(struct device *dev, struct device_node *comp_node,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [BUG] i915 HDMI connector status is connected after disconnection
On Wed, 19 Sep 2018, Chris Chiu wrote:
> I tried to add a slight delay in the hotplug work as follows
>
> --- a/drivers/gpu/drm/i915/intel_hotplug.c
> +++ b/drivers/gpu/drm/i915/intel_hotplug.c
> @@ -378,6 +378,8 @@ static void do_i915_hotplug_check(struct work_struct
> *work,
>
> spin_unlock_irq(&dev_priv->irq_lock);
>
> + msleep(100);
> +
> drm_connector_list_iter_begin(dev, &conn_iter);
> drm_for_each_connector_iter(connector, &conn_iter) {
> intel_connector = to_intel_connector(connector);
>
> It does work in most cases, but still fail to update the status if I
> unplug the HDMI
> cable very slow. I basically pull the HDMI cable in loose connected
> state first, and
> hold in that state ~1 second, totally unplug after that. The status in
> sysfs will report
> connected as it used to. There was no problem when I tried the patch
> https://bugs.freedesktop.org/show_bug.cgi?id=107125#c8
>
> I'll try to modify this patch a little bit and send upstream for
> discussion later. Please
> advise if any. Thanks.
Please let's not add excessive msleeps in work functions.
My idea was more along the lines of making the hotplug function run in a
delayed work. After a chat with Ville, below is what I came up with.
Please let me know how it works. Feel free to toy with the
delay. However, 1-2 seconds or more seems too much.
BR,
Jani.
From 72515b3e856171e52e96bb74796774f595a7f418 Mon Sep 17 00:00:00 2001
From: Jani Nikula
Date: Tue, 18 Sep 2018 13:12:34 +0300
Subject: [PATCH] drm/i915: delay hotplug scheduling
Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
Cc: Jani Nikula
On some systems we get the hotplug irq on unplug before the DDC pins
have been disconnected, resulting in connector status remaining
connected. Since previous attempts at using hotplug live status before
DDC have failed, the only viable option is to reduce the window for
mistakes. Delay the hotplug processing.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/intel_hotplug.c | 15 ++-
2 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7d4daa7412f1..27f579abddae 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -286,7 +286,7 @@ enum hpd_pin {
#define HPD_STORM_DEFAULT_THRESHOLD 5
struct i915_hotplug {
- struct work_struct hotplug_work;
+ struct delayed_work hotplug_work;
struct {
unsigned long last_jiffies;
diff --git a/drivers/gpu/drm/i915/intel_hotplug.c
b/drivers/gpu/drm/i915/intel_hotplug.c
index 648a13c6043c..3af64daa5cfc 100644
--- a/drivers/gpu/drm/i915/intel_hotplug.c
+++ b/drivers/gpu/drm/i915/intel_hotplug.c
@@ -110,6 +110,8 @@ enum hpd_pin intel_hpd_pin_default(struct drm_i915_private
*dev_priv,
}
}
+#define HOTPLUG_DELAY_MS 300
+
#define HPD_STORM_DETECT_PERIOD1000
#define HPD_STORM_REENABLE_DELAY (2 * 60 * 1000)
@@ -319,7 +321,8 @@ static void i915_digport_work_func(struct work_struct *work)
spin_lock_irq(&dev_priv->irq_lock);
dev_priv->hotplug.event_bits |= old_bits;
spin_unlock_irq(&dev_priv->irq_lock);
- schedule_work(&dev_priv->hotplug.hotplug_work);
+ schedule_delayed_work(&dev_priv->hotplug.hotplug_work,
+ msecs_to_jiffies(HOTPLUG_DELAY_MS));
}
}
@@ -329,7 +332,7 @@ static void i915_digport_work_func(struct work_struct *work)
static void i915_hotplug_work_func(struct work_struct *work)
{
struct drm_i915_private *dev_priv =
- container_of(work, struct drm_i915_private,
hotplug.hotplug_work);
+ container_of(work, struct drm_i915_private,
hotplug.hotplug_work.work);
struct drm_device *dev = &dev_priv->drm;
struct intel_connector *intel_connector;
struct intel_encoder *intel_encoder;
@@ -466,7 +469,8 @@ void intel_hpd_irq_handler(struct drm_i915_private
*dev_priv,
if (queue_dig)
queue_work(dev_priv->hotplug.dp_wq,
&dev_priv->hotplug.dig_port_work);
if (queue_hp)
- schedule_work(&dev_priv->hotplug.hotplug_work);
+ schedule_delayed_work(&dev_priv->hotplug.hotplug_work,
+ msecs_to_jiffies(HOTPLUG_DELAY_MS));
}
/**
@@ -586,7 +590,8 @@ void intel_hpd_poll_init(struct drm_i915_private *dev_priv)
void intel_hpd_init_work(struct drm_i915_private *dev_priv)
{
- INIT_WORK(&dev_priv->hotplug.hotplug_work, i915_hotplug_work_func);
+ INIT_DELAYED_WORK(&dev_priv->hotplug.hotplug_work,
+ i915_hotplug_work_func);
INIT_WORK(&dev_priv->hotplug.dig_port_work, i915_digport_work_func);
INIT_WORK(&dev_priv->hotplug.poll_init_work, i915_hpd_poll_init_work);
Re: [PATCH 02/10] phy: Add configuration interface
Hi, On Fri, Sep 14, 2018 at 02:18:37PM +0530, Kishon Vijay Abraham I wrote: > > +/** > > + * phy_validate() - Checks the phy parameters > > + * @phy: the phy returned by phy_get() > > + * @mode: phy_mode the configuration is applicable to. > > + * @opts: Configuration to check > > + * > > + * Used to check that the current set of parameters can be handled by > > + * the phy. Implementations are free to tune the parameters passed as > > + * arguments if needed by some implementation detail or > > + * constraints. It will not change any actual configuration of the > > + * PHY, so calling it as many times as deemed fit will have no side > > + * effect. > > + * > > + * Returns: 0 if successful, an negative error code otherwise > > + */ > > +int phy_validate(struct phy *phy, enum phy_mode mode, > > + union phy_configure_opts *opts) > > IIUC the consumer driver will pass configuration options (or PHY > parameters) > which will be validated by the PHY driver and in some cases the PHY > driver can > modify the configuration options? And these modified configuration > options will > again be given to phy_configure? > > Looks like it's a round about way of doing the same thing. > >>> > >>> Not really. The validate callback allows to check whether a particular > >>> configuration would work, and try to negotiate a set of configurations > >>> that both the consumer and the PHY could work with. > >> > >> Maybe the PHY should provide the list of supported features to the consumer > >> driver and the consumer should select a supported feature? > > > > It's not really about the features it supports, but the boundaries it > > might have on those features. For example, the same phy integrated in > > two different SoCs will probably have some limit on the clock rate it > > can output because of the phy design itself, but also because of the > > clock that is fed into that phy, and that will be different from one > > SoC to the other. > > > > This integration will prevent us to use some clock rates on the first > > SoC, while the second one would be totally fine with it. > > If there's a clock that is fed to the PHY from the consumer, then the consumer > driver should model a clock provider and the PHY can get a reference to it > using clk_get(). Rockchip and Arasan eMMC PHYs has already used something like > that. That would be doable, but no current driver has had this in their binding. So that would prevent any further rework, and make that whole series moot. And while I could live without the Allwinner part, the Cadence one is really needed. > Assuming the PHY can get a reference to the clock provided by the consumer, > what are the parameters we'll be able to get rid of in struct > phy_configure_opts_mipi_dphy? hs_clock_rate and lp_clock_rate. All the other ones are needed. > I'm sorry but I'm not convinced a consumer driver should have all the details > that are added in phy_configure_opts_mipi_dphy. If it can convince you, here is the parameters that are needed by all the MIPI-DSI drivers currently in Linux to configure their PHY: - cdns-dsi (drivers/gpu/drm/bridge/cdns-dsi.c) - hs_clk_rate - lanes - videomode - kirin (drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c) - hs_exit - hs_prepare - hs_trail - hs_zero - lpx - ta_get - ta_go - wakeup - msm (drivers/gpu/drm/msm/dsi/*) - clk_post - clk_pre - clk_prepare - clk_trail - clk_zero - hs_clk_rate - hs_exit - hs_prepare - hs_trail - hs_zero - lp_clk_rate - ta_get - ta_go - ta_sure - mtk (drivers/gpu/drm/mediatek/mtk_dsi.c) - hs_clk_rate - hs_exit - hs_prepare - hs_trail - hs_zero - lpx - sun4i (drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c) - clk_post - clk_pre - clk_prepare - clk_zero - hs_prepare - hs_trail - lanes - lp_clk_rate - tegra (drivers/gpu/drm/tegra/dsi.c) - clk_post - clk_pre - clk_prepare - clk_trail - clk_zero - hs_exit - hs_prepare - hs_trail - hs_zero - lpx - ta_get - ta_go - ta_sure - vc4 (drivers/gpu/drm/vc4/vc4_dsi.c) - hs_clk_rate - lanes Now, for MIPI-CSI receivers: - marvell-ccic (drivers/media/platform/marvell-ccic/mcam-core.c) - clk_term_en - clk_settle - d_term_en - hs_settle - lp_clk_rate - omap4iss (drivers/staging/media/omap4iss/iss_csiphy.c) - clk_miss - clk_settle - clk_term - hs_settle - hs_term - lanes - rcar-vin (drivers/media/platform/rcar-vin/rcar-csi2.c) - hs_clk_rate - lanes - ti-vpe (drivers/media/platform/ti-vpe/cal.c) - clk_term_en - d_term_en - hs_settle - hs_term So the timings expressed in the structure are the set of all the ones currently used in the tree by DSI and CSI drivers.
Re: [PATCH] drm/i915: re-check the hotplug with a delayed work
On Wed, 19 Sep 2018, Chris Chiu wrote:
> I have few ASUS laptops, X705FD(Intel i7-8565), X560UD(Intel i5-8250U)
> and X530UN(Intel i7-8550U) share the same problem. The HDMI connector
> status stays 'connected' even the HDMI cable has been unplugged.
> Then the status in sysfs would never change since then until we
> do 'xrandr' to reprobe the devices. It would also cause the audio
> output path cannot correctly swicth based on the connector status.
>
> This commit kicks off a delayed work when the status remains unchanged
> in the first hotplug event handling, which may not be the perfect
> timing in some special cases.
Please see [1].
BR,
Jani.
[1] http://patchwork.freedesktop.org/patch/msgid/87k1nhy9ie@intel.com
>
> Signed-off-by: Chris Chiu
> ---
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> drivers/gpu/drm/i915/intel_hotplug.c | 35 +++
> 2 files changed, 32 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index d51d8574a679..78e2cf09cc10 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -286,6 +286,7 @@ struct i915_hotplug {
> } stats[HPD_NUM_PINS];
> u32 event_bits;
> struct delayed_work reenable_work;
> + struct delayed_work recheck_work;
>
> struct intel_digital_port *irq_port[I915_MAX_PORTS];
> u32 long_port_mask;
> diff --git a/drivers/gpu/drm/i915/intel_hotplug.c
> b/drivers/gpu/drm/i915/intel_hotplug.c
> index 43aa92beff2a..089a24588ec8 100644
> --- a/drivers/gpu/drm/i915/intel_hotplug.c
> +++ b/drivers/gpu/drm/i915/intel_hotplug.c
> @@ -349,14 +349,15 @@ static void i915_digport_work_func(struct work_struct
> *work)
> }
> }
>
> +#define HPD_RECHECK_DELAY(2 * 1000)
> +
> /*
> * Handle hotplug events outside the interrupt handler proper.
> */
> -static void i915_hotplug_work_func(struct work_struct *work)
> +static void do_i915_hotplug_check(struct work_struct *work,
> +struct drm_i915_private *dev_priv,
> +struct drm_device *dev, bool do_recheck)
> {
> - struct drm_i915_private *dev_priv =
> - container_of(work, struct drm_i915_private,
> hotplug.hotplug_work);
> - struct drm_device *dev = &dev_priv->drm;
> struct intel_connector *intel_connector;
> struct intel_encoder *intel_encoder;
> struct drm_connector *connector;
> @@ -396,8 +397,31 @@ static void i915_hotplug_work_func(struct work_struct
> *work)
>
> if (changed)
> drm_kms_helper_hotplug_event(dev);
> + else if (do_recheck) {
> + spin_lock_irq(&dev_priv->irq_lock);
> + dev_priv->hotplug.event_bits |= hpd_event_bits;
> + spin_unlock_irq(&dev_priv->irq_lock);
> + schedule_delayed_work(&dev_priv->hotplug.recheck_work,
> msecs_to_jiffies(HPD_RECHECK_DELAY));
> + }
> }
>
> +static void i915_hotplug_work_func(struct work_struct *work)
> +{
> + struct drm_i915_private *dev_priv =
> + container_of(work, struct drm_i915_private,
> hotplug.hotplug_work);
> + struct drm_device *dev = &dev_priv->drm;
> +
> + do_i915_hotplug_check(work, dev_priv, dev, true);
> +}
> +
> +static void i915_hotplug_recheck_func(struct work_struct *work)
> +{
> + struct drm_i915_private *dev_priv =
> + container_of(work, struct drm_i915_private,
> hotplug.recheck_work.work);
> + struct drm_device *dev = &dev_priv->drm;
> +
> + do_i915_hotplug_check(work, dev_priv, dev, false);
> +}
>
> /**
> * intel_hpd_irq_handler - main hotplug irq handler
> @@ -619,6 +643,8 @@ void intel_hpd_init_work(struct drm_i915_private
> *dev_priv)
> INIT_WORK(&dev_priv->hotplug.poll_init_work, i915_hpd_poll_init_work);
> INIT_DELAYED_WORK(&dev_priv->hotplug.reenable_work,
> intel_hpd_irq_storm_reenable_work);
> + INIT_DELAYED_WORK(&dev_priv->hotplug.recheck_work,
> + i915_hotplug_recheck_func);
> }
>
> void intel_hpd_cancel_work(struct drm_i915_private *dev_priv)
> @@ -635,6 +661,7 @@ void intel_hpd_cancel_work(struct drm_i915_private
> *dev_priv)
> cancel_work_sync(&dev_priv->hotplug.hotplug_work);
> cancel_work_sync(&dev_priv->hotplug.poll_init_work);
> cancel_delayed_work_sync(&dev_priv->hotplug.reenable_work);
> + cancel_delayed_work_sync(&dev_priv->hotplug.recheck_work);
> }
>
> bool intel_hpd_disable(struct drm_i915_private *dev_priv, enum hpd_pin pin)
--
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/scheduler: remove timeout work_struct from drm_sched_job
Am 18.09.2018 um 18:17 schrieb Nayan Deshmukh:
having a delayed work item per job is redundant as we only need one
per scheduler to track the time out the currently executing job.
Well that looks simpler than I thought it would be.
But it shows the next problem that the timeout and the completion could
race.
As far as I can see that can be fixed by moving the
dma_fence_remove_callback()/dma_fence_add_callback() dance from
drm_sched_hw_job_reset() to drm_sched_job_timedout().
Anyway, I would say drop patch #1 and fix the one comment below and we
can use this.
Signed-off-by: Nayan Deshmukh
Suggested-by: Christian König
---
drivers/gpu/drm/scheduler/sched_main.c | 16 +---
include/drm/gpu_scheduler.h| 6 +++---
2 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
index 0e6ccc8243db..f213b5c7f718 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -198,7 +198,7 @@ static void drm_sched_job_finish(struct work_struct *work)
* manages to find this job as the next job in the list, the fence
* signaled check below will prevent the timeout to be restarted.
*/
- cancel_delayed_work_sync(&s_job->work_tdr);
+ cancel_delayed_work_sync(&sched->work_tdr);
spin_lock(&sched->job_list_lock);
/* queue TDR for next job */
@@ -207,7 +207,7 @@ static void drm_sched_job_finish(struct work_struct *work)
if (sched->timeout != MAX_SCHEDULE_TIMEOUT &&
!list_is_last(&s_job->node, &sched->ring_mirror_list)) {
if (!dma_fence_is_signaled(&next->s_fence->finished))
Since we now have only one delayed work item we can just drop the test
if next is already signaled.
Regards,
Christian.
- schedule_delayed_work(&next->work_tdr, sched->timeout);
+ schedule_delayed_work(&sched->work_tdr, sched->timeout);
}
/* remove job from ring_mirror_list */
list_del(&s_job->node);
@@ -237,7 +237,7 @@ static void drm_sched_job_begin(struct drm_sched_job *s_job)
if (list_first_entry_or_null(&sched->ring_mirror_list,
struct drm_sched_job, node) == s_job) {
if (sched->timeout != MAX_SCHEDULE_TIMEOUT)
- schedule_delayed_work(&s_job->work_tdr, sched->timeout);
+ schedule_delayed_work(&sched->work_tdr, sched->timeout);
sched->curr_job = s_job;
}
spin_unlock(&sched->job_list_lock);
@@ -245,8 +245,10 @@ static void drm_sched_job_begin(struct drm_sched_job
*s_job)
static void drm_sched_job_timedout(struct work_struct *work)
{
- struct drm_sched_job *job = container_of(work, struct drm_sched_job,
-work_tdr.work);
+ struct drm_gpu_scheduler *sched = container_of(work,
+ struct drm_gpu_scheduler,
+ work_tdr.work);
+ struct drm_sched_job *job = sched->curr_job;
job->sched->ops->timedout_job(job);
}
@@ -318,7 +320,7 @@ void drm_sched_job_recovery(struct drm_gpu_scheduler *sched)
s_job = list_first_entry_or_null(&sched->ring_mirror_list,
struct drm_sched_job, node);
if (s_job && sched->timeout != MAX_SCHEDULE_TIMEOUT)
- schedule_delayed_work(&s_job->work_tdr, sched->timeout);
+ schedule_delayed_work(&sched->work_tdr, sched->timeout);
if (s_job)
sched->curr_job = s_job;
@@ -389,7 +391,6 @@ int drm_sched_job_init(struct drm_sched_job *job,
INIT_WORK(&job->finish_work, drm_sched_job_finish);
INIT_LIST_HEAD(&job->node);
- INIT_DELAYED_WORK(&job->work_tdr, drm_sched_job_timedout);
return 0;
}
@@ -580,6 +581,7 @@ int drm_sched_init(struct drm_gpu_scheduler *sched,
INIT_LIST_HEAD(&sched->ring_mirror_list);
spin_lock_init(&sched->job_list_lock);
atomic_set(&sched->hw_rq_count, 0);
+ INIT_DELAYED_WORK(&sched->work_tdr, drm_sched_job_timedout);
atomic_set(&sched->num_jobs, 0);
atomic64_set(&sched->job_id_count, 0);
diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
index 07e776b1ca42..9d50d7f3eaa4 100644
--- a/include/drm/gpu_scheduler.h
+++ b/include/drm/gpu_scheduler.h
@@ -175,8 +175,6 @@ struct drm_sched_fence *to_drm_sched_fence(struct dma_fence
*f);
* finished to remove the job from the
* @drm_gpu_scheduler.ring_mirror_list.
* @node: used to append this struct to the
@drm_gpu_scheduler.ring_mirror_list.
- * @work_tdr: schedules a delayed call to @drm_sched_job_timedout after the
timeout
- *interval is over.
* @id: a unique id assigned to each job scheduled on the sche
[Bug 201183] AMDGPU Dual displays and only DP screen works after grub.
https://bugzilla.kernel.org/show_bug.cgi?id=201183 --- Comment #4 from Nicholas Kazlauskas (nicholas.kazlaus...@amd.com) --- Do you only see this problem occur before you start an X session? It might help if you could post a log from 4.18 with drm.debug=6 included in your boot parameters. -- 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 v2 13/16] arm64: dts: renesas: r8a77990: Add display output support
Hi Simon,
On Wednesday, 19 September 2018 11:35:07 EEST Simon Horman wrote:
> On Mon, Sep 17, 2018 at 11:59:32AM +0300, Laurent Pinchart wrote:
> > On Monday, 17 September 2018 11:54:04 EEST Laurent Pinchart wrote:
> >> On Monday, 17 September 2018 11:47:15 EEST Laurent Pinchart wrote:
> >>> On Monday, 17 September 2018 11:14:20 EEST Simon Horman wrote:
> On Mon, Sep 17, 2018 at 09:50:55AM +0200, Simon Horman wrote:
> > On Fri, Sep 14, 2018 at 12:10:43PM +0300, Laurent Pinchart wrote:
> >> The R8A77990 (E3) platform has one RGB output and two LVDS
> >> outputs connected to the DU. Add the DT nodes for the DU, LVDS
> >> encoders and supporting VSP and FCP.
> >>
> >> Signed-off-by: Laurent Pinchart
> >>
> >> Tested-by: Jacopo Mondi
> >> ---
> >>
> >> arch/arm64/boot/dts/renesas/r8a77990.dtsi | 167
> >> 1 file changed, 167 insertions(+)
> >>
> >> diff --git a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> >> b/arch/arm64/boot/dts/renesas/r8a77990.dtsi index
> >> abb14af76c0e..600074ca3ee5 100644
> >> --- a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> >> +++ b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
[snip]
> >> + lvds0: lvds-encoder@feb9 {
> >> + compatible = "renesas,r8a77990-lvds";
> >> + reg = <0 0xfeb9 0 0x20>;
> >> + clocks = <&cpg CPG_MOD 727>;
> >> + power-domains = <&sysc R8A77990_PD_ALWAYS_ON>;
> >> + resets = <&cpg 727>;
> >> + status = "disabled";
> >> +
> >> + ports {
> >> + #address-cells = <1>;
> >> + #size-cells = <0>;
> >> +
> >> + port@0 {
> >> + reg = <0>;
> >> + lvds0_in: endpoint {
> >> + remote-endpoint =
> >> <&du_out_lvds0>;
> >> + };
> >> + };
> >> +
> >> + port@1 {
> >> + reg = <1>;
> >> + lvds0_out: endpoint {
> >> + };
> >> + };
> >> + };
> >> + };
> >> +
> >> + lvds1: lvds-encoder@feb90100 {
> >> + compatible = "renesas,r8a77990-lvds";
> >> + reg = <0 0xfeb90100 0 0x20>;
> >> + clocks = <&cpg CPG_MOD 727>;
> >> + power-domains = <&sysc R8A77990_PD_ALWAYS_ON>;
> >> + resets = <&cpg 726>;
>
> Also, is the missmatch between the index for the clock and reset
> intentional?
> >>>
> >>> It is. According to the datasheet, the two LVDS encoders have
> >>> different module stop bits, but share the same reset (lovely hardware
> >>> design, it will be fun to support that in the driver :-S).
> >>
> >> Sorry, I got it wrong. it's bit 725 that is shared between the two LVDS
> >> encoders, to reset the two LVDS PLLs together. The encoders themselves
> >> still have independent reset bits. I'll fix this.
> >
> > And of course it's the clock you were commenting on, not the reset. *sigh*
> >
> > According to the datasheets the two LVDS encoders share one MSTP. Whether
> > that's a mistake in the documentation or not I can't tell yet, as I have
> > only tested LVDS0.
>
> Could we follow-up with the HW team?
> I'm not opposed to taking the patch with this portion as-is
> but it would be good to clarify this somehow.
I tried setting the clock to MSTP 726, and I then get vblank interrupt
timeouts. Furthermore I've now tested the LVDS1 output with a display panel,
and while I still can't get the backlight to work, the panel displays the
correct image with MSTP 727. I thus conclude that the above is correct.
> >> + status = "disabled";
> >> +
> >> + ports {
> >> + #address-cells = <1>;
> >> + #size-cells = <0>;
> >> +
> >> + port@0 {
> >> + reg = <0>;
> >> + lvds1_in: endpoint {
> >> + remote-endpoint =
> >> <&du_out_lvds1>;
> >> + };
> >> + };
> >> +
> >> + port@1 {
> >> + reg = <1>;
> >> + lvds1_out: endpoint {
>
Re: [PATCH v4 0/3] add LG panel to dpcd quirk database
On Tue, 11 Sep 2018, "Lee, Shawn C" wrote: > Only specific N value (0x8000) would be acceptable for LG > LP140WF6-SPM1 eDP panel which is running at asynchronous > clock mode. With the other N value, it will enter BITS mode > and display black screen. This patch series set constant N > value for specific sink/branch device that would cover > similar issue. Pushed the series to drm-misc-next. Thanks for the patches, review and testing. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107990] Got Dying Light working in Arch by changing Mesa's compile steps, how to get it working Out Of the Box?
https://bugs.freedesktop.org/show_bug.cgi?id=107990 Bug ID: 107990 Summary: Got Dying Light working in Arch by changing Mesa's compile steps, how to get it working Out Of the Box? Product: Mesa Version: 18.2 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel@lists.freedesktop.org Reporter: john.etted...@gmail.com QA Contact: dri-devel@lists.freedesktop.org Hello, I've been looking for a while on how to get DL running on Arch and I finally found it. Now I'd like this to be possible by default, but I don't know if the issue lies in Arch or Mesa and I'm hopeful someone here will be able to help. Arch's default compiler flags are: CFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt" CXXFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt" LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now" "-fno-plt" in C/CXXFLAGS and ",-z,now" in LDFLAGS need to be unset when compiling Mesa to get DL to not crash. The other change required is to not use glvnd, with "-D glvnd=false". I tried building libglvnd with the same flags as Mesa, or none at all, but it didn't help. Here's the original 18.2.0 PKGBUILD in case it helps: https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/mesa The behavior is the same with Mesa 18.2.0 or master, with LLVM 6.0 or master. I haven't tried with autoconf though, only Meson, but I can try if you think it'd be helpful. I don't have any helpful log, as the game segfaults without these, a backtrace in gdb doesn't show me anything useful, and there's nothing in dmesg. I'm using a 280X but people with 5xx seem to have the same behavior, so I don't think it depends on the model. We're all on amdgpu. I'd be happy to try / provide whatever would help. Current versions: Linux 4.18.8, GCC 8.2.1, glibc 2.28, but it failed in previous ones too. Thank you! -- 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
[PULL] drm-misc-fixes
drm-misc-fixes-2018-09-19: drm-misc-fixes for v4.19-rc5: - Fix crash in vgem in drm_drv_uses_atomic_modeset. - Allow atomic drivers that don't set DRIVER_ATOMIC to create debugfs entries. - Fix compiler warning for unused connector_funcs. - Fix null pointer deref on UDL unplug. - Disable DRM support for sun4i's R40 for now. (Not all patches went in for v4.19, so it has to wait a cycle.) - NULL-terminate the of_device_id table in pl111. - Make sure vc4 NV12 planar format works when displaying an unscaled fb. The following changes since commit 67c6ed7cf9ebe53815f15bfdeb49ad91801c2235: Merge tag 'drm-intel-fixes-2018-09-05' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes (2018-09-07 11:07:03 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2018-09-19 for you to fetch changes up to 558a9ef94a329a1ac75613407ad15d0d0071ff4c: drm: sun4i: drop second PLL from A64 HDMI PHY (2018-09-19 09:58:40 +0200) drm-misc-fixes for v4.19-rc5: - Fix crash in vgem in drm_drv_uses_atomic_modeset. - Allow atomic drivers that don't set DRIVER_ATOMIC to create debugfs entries. - Fix compiler warning for unused connector_funcs. - Fix null pointer deref on UDL unplug. - Disable DRM support for sun4i's R40 for now. (Not all patches went in for v4.19, so it has to wait a cycle.) - NULL-terminate the of_device_id table in pl111. - Make sure vc4 NV12 planar format works when displaying an unscaled fb. Boris Brezillon (1): drm/vc4: Fix the "no scaling" case on multi-planar YUV formats Chen-Yu Tsai (1): drm/sun4i: Remove R40 display pipeline compatibles Dave Airlie (1): drm: fix drm_drv_uses_atomic_modeset on non modesetting drivers. Emil Lundmark (1): drm: udl: Destroy framebuffer only if it was initialized Icenowy Zheng (1): drm: sun4i: drop second PLL from A64 HDMI PHY Lyude Paul (1): drm/atomic: Use drm_drv_uses_atomic_modeset() for debugfs creation YueHaibing (1): drm/fb-helper: Remove set but not used variable 'connector_funcs' zhong jiang (1): drm/pl111: Make sure of_device_id tables are NULL terminated drivers/gpu/drm/drm_atomic.c | 2 +- drivers/gpu/drm/drm_debugfs.c | 2 +- drivers/gpu/drm/drm_fb_helper.c| 3 --- drivers/gpu/drm/pl111/pl111_vexpress.c | 3 ++- drivers/gpu/drm/sun4i/sun4i_drv.c | 1 - drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 1 - drivers/gpu/drm/sun4i/sun8i_mixer.c| 24 drivers/gpu/drm/sun4i/sun8i_tcon_top.c | 1 - drivers/gpu/drm/udl/udl_fb.c | 8 +--- drivers/gpu/drm/vc4/vc4_plane.c| 25 - include/drm/drm_drv.h | 2 +- 11 files changed, 22 insertions(+), 50 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] meson.build: enable static build
On 18.07.2018 22:33, Peter Seiderer wrote: > Use meson library instead of shared_library to enable static build. > > Signed-off-by: Peter Seiderer thanks, seems to work -- t ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-intel-fixes
Hi Dave, Here goes drm-intel-fixes-2018-09-19: Only fixes coming from gvt containing "Two more BXT fixes from Colin, one srcu locking fix and one fix for GGTT clear when destroy vGPU." Thanks, Rodrigo. The following changes since commit 7876320f88802b22d4e2daf7eb027dd14175a0f8: Linux 4.19-rc4 (2018-09-16 11:52:37 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2018-09-19 for you to fetch changes up to a530bf948ab77b0f5cc57c55dd525eb813768782: Merge tag 'gvt-fixes-2018-09-18' of https://github.com/intel/gvt-linux into drm-intel-fixes (2018-09-18 08:09:44 -0700) Only fixes coming from gvt containing "Two more BXT fixes from Colin, one srcu locking fix and one fix for GGTT clear when destroy vGPU." Colin Xu (2): drm/i915/gvt: Init PHY related registers for BXT drm/i915/gvt: Add GEN9_CLKGATE_DIS_4 to default BXT mmio handler Rodrigo Vivi (1): Merge tag 'gvt-fixes-2018-09-18' of https://github.com/intel/gvt-linux into drm-intel-fixes Weinan Li (1): drm/i915/gvt: request srcu_read_lock before checking if one gfn is valid Zhipeng Gong (1): drm/i915/gvt: clear ggtt entries when destroy vgpu drivers/gpu/drm/i915/gvt/handlers.c | 1 + drivers/gpu/drm/i915/gvt/kvmgt.c| 7 ++- drivers/gpu/drm/i915/gvt/mmio.c | 28 drivers/gpu/drm/i915/gvt/vgpu.c | 1 + 4 files changed, 36 insertions(+), 1 deletion(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/scheduler: remove timeout work_struct from drm_sched_job
On 2018-09-19 2:30 p.m., Christian König wrote: > Am 18.09.2018 um 18:17 schrieb Nayan Deshmukh: >> having a delayed work item per job is redundant as we only need one >> per scheduler to track the time out the currently executing job. > > Well that looks simpler than I thought it would be. > > But it shows the next problem that the timeout and the completion could > race. > > As far as I can see that can be fixed by moving the > dma_fence_remove_callback()/dma_fence_add_callback() dance from > drm_sched_hw_job_reset() to drm_sched_job_timedout(). BTW, while you guys are looking into this code, please keep an eye open for things that could explain https://bugs.freedesktop.org/107762 . -- 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 0/2] drm: Alpha blending issue
Testing on the RCar Salvaltor-XS using the rcar-du has identified that
commit 161ad653d6c9 ("drm: rcar-du: Use __drm_atomic_helper_plane_reset
instead of copying the logic") caused a regression in display output on
the primary planes.
The effect was that primary plane was 'invisible' though secondary
planes were displayed correctly.
This issue turned out to be a change in the initialisation of the
default alpha property value in the state object. A plane without an
alpha property would leave the alpha property unset (and thus at zero,
or 'transparent').
Two patches are thus presented, which both individually can fix this
regression - but both are suitable for integration.
The RCar-DU driver is updated to provide an alpha property on primary
planes, as it isn't unreasonable to be able to set the property there.
This alone would have the effect of ensuring that the default value was
set to the full opaque setting, and repair the regression.
As a separate patch, we also update __drm_atomic_helper_plane_reset()
call such that the alpha values are always initialised to a more
practical default value of DRM_BLEND_ALPHA_OPAQUE for all planes.
Kieran Bingham (2):
drm/atomic: Initialise planes with opaque alpha values
drm: rcar-du: Enable alpha property on primary planes
drivers/gpu/drm/drm_atomic_helper.c | 4 +---
drivers/gpu/drm/rcar-du/rcar_du_plane.c | 7 ++-
2 files changed, 7 insertions(+), 4 deletions(-)
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm: rcar-du: Enable alpha property on primary planes
If the alpha property is not added to a plane, a default value will be
used, which can result in a non-visible layer if the alpha is
initialised as 0.
Provide an alpha blend property on all planes.
Fixes: 161ad653d6c9 ("drm: rcar-du: Use __drm_atomic_helper_plane_reset
instead of copying the logic")
Signed-off-by: Kieran Bingham
---
drivers/gpu/drm/rcar-du/rcar_du_plane.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
index 9e07758a755c..72399a19d8a6 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
@@ -783,13 +783,18 @@ int rcar_du_planes_init(struct rcar_du_group *rgrp)
drm_plane_helper_add(&plane->plane,
&rcar_du_plane_helper_funcs);
+ /*
+* The alpha property needs to be initialised on all planes
+* to ensure the correct setting at the output.
+*/
+ drm_plane_create_alpha_property(&plane->plane);
+
if (type == DRM_PLANE_TYPE_PRIMARY)
continue;
drm_object_attach_property(&plane->plane.base,
rcdu->props.colorkey,
RCAR_DU_COLORKEY_NONE);
- drm_plane_create_alpha_property(&plane->plane);
drm_plane_create_zpos_property(&plane->plane, 1, 1, 7);
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/atomic: Initialise planes with opaque alpha values
Planes without an alpha property, using __drm_atomic_helper_plane_reset will have their plane state alpha initialised as zero, which represents a transparent alpha. If this value is then used for the plane, it may not be visible by default, and thus doesn't represent a good initialisation state. Update the default state->alpha value to DRM_BLEND_ALPHA_OPAQUE unconditionally when the plane is reset. Signed-off-by: Kieran Bingham --- drivers/gpu/drm/drm_atomic_helper.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c index 3cf1aa132778..e49b22381048 100644 --- a/drivers/gpu/drm/drm_atomic_helper.c +++ b/drivers/gpu/drm/drm_atomic_helper.c @@ -3569,9 +3569,7 @@ void __drm_atomic_helper_plane_reset(struct drm_plane *plane, state->plane = plane; state->rotation = DRM_MODE_ROTATE_0; - /* Reset the alpha value to fully opaque if it matters */ - if (plane->alpha_property) - state->alpha = plane->alpha_property->values[1]; + state->alpha = DRM_BLEND_ALPHA_OPAQUE; state->pixel_blend_mode = DRM_MODE_BLEND_PREMULTI; plane->state = state; -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/atomic: Initialise planes with opaque alpha values
On Wed, Sep 19, 2018 at 04:56:58PM +0100, Kieran Bingham wrote: > Planes without an alpha property, using __drm_atomic_helper_plane_reset > will have their plane state alpha initialised as zero, which represents > a transparent alpha. > > If this value is then used for the plane, it may not be visible by > default, and thus doesn't represent a good initialisation state. > > Update the default state->alpha value to DRM_BLEND_ALPHA_OPAQUE > unconditionally when the plane is reset. > > Signed-off-by: Kieran Bingham > --- > drivers/gpu/drm/drm_atomic_helper.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c > b/drivers/gpu/drm/drm_atomic_helper.c > index 3cf1aa132778..e49b22381048 100644 > --- a/drivers/gpu/drm/drm_atomic_helper.c > +++ b/drivers/gpu/drm/drm_atomic_helper.c > @@ -3569,9 +3569,7 @@ void __drm_atomic_helper_plane_reset(struct drm_plane > *plane, > state->plane = plane; > state->rotation = DRM_MODE_ROTATE_0; > > - /* Reset the alpha value to fully opaque if it matters */ > - if (plane->alpha_property) > - state->alpha = plane->alpha_property->values[1]; > + state->alpha = DRM_BLEND_ALPHA_OPAQUE; I can't come up with a solid excuse for not initializing it always. Reviewed-by: Ville Syrjälä > state->pixel_blend_mode = DRM_MODE_BLEND_PREMULTI; > > plane->state = state; > -- > 2.17.1 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Ville Syrjälä Intel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] Re: [PATCH 5/5] ARM: sun8i: dts: drop A64 HDMI PHY fallback compatible from R40 DT
On Tue, Sep 18, 2018 at 6:57 AM Icenowy Zheng wrote:
>
> 在 2018-09-17一的 16:54 +0200，Maxime Ripard写道：
> > On Mon, Sep 10, 2018 at 04:32:30PM +0200, Jernej Škrabec wrote:
> > > Dne ponedeljek, 10. september 2018 ob 16:23:54 CEST je Maxime
> > > Ripard
> > > napisal(a):
> > > > On Fri, Sep 07, 2018 at 03:22:34PM +0800, Icenowy Zheng wrote:
> > > > > The R40 HDMI PHY seems to be different to the A64 one, the A64
> > > > > one
> > > > > has no input mux, but the R40 one has.
> > > > >
> > > > > Drop the A64 fallback compatible from the HDMI PHY node in R40
> > > > > DT.
> > > > >
> > > > > Signed-off-by: Icenowy Zheng
> > > > > ---
> > > > >
> > > > > arch/arm/boot/dts/sun8i-r40.dtsi | 3 +--
> > > > > 1 file changed, 1 insertion(+), 2 deletions(-)
> > > > >
> > > > > diff --git a/arch/arm/boot/dts/sun8i-r40.dtsi
> > > > > b/arch/arm/boot/dts/sun8i-r40.dtsi index
> > > > > ffd9f00f74a4..5f547c161baf
> > > > > 100644
> > > > > --- a/arch/arm/boot/dts/sun8i-r40.dtsi
> > > > > +++ b/arch/arm/boot/dts/sun8i-r40.dtsi
> > > > > @@ -800,8 +800,7 @@
> > > > >
> > > > > };
> > > > >
> > > > > hdmi_phy: hdmi-phy@1ef {
> > > > >
> > > > > - compatible = "allwinner,sun8i-r40-hdmi-
> > > > > phy",
> > > > > -"allwinner,sun50i-a64-
> > > > > hdmi-phy";
> > > > > + compatible = "allwinner,sun8i-r40-hdmi-
> > > > > phy";
> > > >
> > > > If you could use the A64 phy before, you can still use it now.
> > >
> > > Not exactly. Given that we don't know how to switch between HDMI
> > > PHY clock
> > > parents on A64 (if it is actually connected at all, there is no
> > > information
> > > about that in manual and AW didn't answered our questions, despite
> > > asking them
> > > through different channels), A64 compatible will be associated with
> > > quirk,
> > > which will tell that only one clock parent is usable.
> > >
> > > However, R40 HDMI PHY has definetly two clock parents, as it was
> > > tested by me
> > > and Icenowy and we know how to switch between them without issues.
> > > Technically, we could have A64 compatible there, but that would
> > > mean only
> > > single PHY parent is considered instead of two.
> >
> > The DT change above would mean that you can't operate the R40 phy in
> > the same way than the A64's. From what you're telling me now, this
> > isn't exactly what is going on: you can operate the R40 phy just like
> > the A64: with a single PLL instead of two. You operate in a degraded
> > and non-optimal mode, but it still works.
I suppose it's a slightly different semantic. While we have no definite
data regarding the A64, there are some possibilities:
1. The muxing mechanism isn't present on the A64, and the HDMI PHY
only takes one clock.
2. The muxing is present, but only the first parent is connected.
Switching to the second input causes it to stop working.
3. Same as above, but both parents are connected to video0-pll.
This might be indistinguishable from 1., even if checking whether
the bit modifications stick or not.
In any case, I think this deserves proper experimentation, and subsequent
documentation in the bindings of our "assumptions" (i.e. educated guess)
about what the hardware is doing.
>
> The status of R40 HDMI PHY input mux is not determined when use A64
> driver, which makes it not working when the bootloader initializes it
> to use the second PLL (the A64 driver will assume the parent is the
> first PLL).
That doesn't sound good. But it really depends on what we assume the
A64 is doing.
ChenYu
> >
> > And it's exactly what the DT is already saying.
> >
> > Maxime
> >
>
> --
> You received this message because you are subscribed to the Google Groups
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to linux-sunxi+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107001] hard system freeze with mesa 18.1.x on AMD RX 580
https://bugs.freedesktop.org/show_bug.cgi?id=107001 cla...@mathr.co.uk changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |WORKSFORME --- Comment #4 from cla...@mathr.co.uk --- Closing this as I've had no problems for a week or two. I debated selecting "not our bug" as the reason as I think it's most likely a Linux kernel bug that just happened to be exposed more often by certain Mess version, but I have no proof of this, so I selected the more neutral "works for me". -- 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/2] drm/atomic: Initialise planes with opaque alpha values
Hi Kieran, On Wed, Sep 19, 2018 at 07:15:45PM +0300, Ville Syrjälä wrote: > On Wed, Sep 19, 2018 at 04:56:58PM +0100, Kieran Bingham wrote: > > Planes without an alpha property, using __drm_atomic_helper_plane_reset > > will have their plane state alpha initialised as zero, which represents > > a transparent alpha. > > > > If this value is then used for the plane, it may not be visible by > > default, and thus doesn't represent a good initialisation state. > > > > Update the default state->alpha value to DRM_BLEND_ALPHA_OPAQUE > > unconditionally when the plane is reset. > > > > Signed-off-by: Kieran Bingham > > --- > > drivers/gpu/drm/drm_atomic_helper.c | 4 +--- > > 1 file changed, 1 insertion(+), 3 deletions(-) > > > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c > > b/drivers/gpu/drm/drm_atomic_helper.c > > index 3cf1aa132778..e49b22381048 100644 > > --- a/drivers/gpu/drm/drm_atomic_helper.c > > +++ b/drivers/gpu/drm/drm_atomic_helper.c > > @@ -3569,9 +3569,7 @@ void __drm_atomic_helper_plane_reset(struct drm_plane > > *plane, > > state->plane = plane; > > state->rotation = DRM_MODE_ROTATE_0; > > > > - /* Reset the alpha value to fully opaque if it matters */ > > - if (plane->alpha_property) > > - state->alpha = plane->alpha_property->values[1]; > > + state->alpha = DRM_BLEND_ALPHA_OPAQUE; > > I can't come up with a solid excuse for not initializing it always. > > Reviewed-by: Ville Syrjälä Neither do I, so: Reviewed-by: Alexandru Gheorghe And thanks again. I plan to push it tomorrow to drm-misc-next. Now, I've seen the plane_reset patches in the pull request for drm-next 4.20, I wonder if someone could tell me what should I do to get this patch on that train. > > > state->pixel_blend_mode = DRM_MODE_BLEND_PREMULTI; > > > > plane->state = state; > > -- > > 2.17.1 > > > > ___ > > dri-devel mailing list > > dri-devel@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > -- > Ville Syrjälä > Intel -- Cheers, Alex G ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/nouveau: Add size to vbios.rom file in debugfs
With this, nvbios /sys/kernel/debug/dri/*/vbios.rom now works!
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/nouveau_debugfs.c | 23 +++
1 file changed, 19 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_debugfs.c
b/drivers/gpu/drm/nouveau/nouveau_debugfs.c
index 7379c20584a2..88a52f6b39fe 100644
--- a/drivers/gpu/drm/nouveau/nouveau_debugfs.c
+++ b/drivers/gpu/drm/nouveau/nouveau_debugfs.c
@@ -220,8 +220,9 @@ static const struct nouveau_debugfs_files {
int
nouveau_drm_debugfs_init(struct drm_minor *minor)
{
+ struct nouveau_drm *drm = nouveau_drm(minor->dev);
struct dentry *dentry;
- int i;
+ int i, ret;
for (i = 0; i < ARRAY_SIZE(nouveau_debugfs_files); i++) {
dentry = debugfs_create_file(nouveau_debugfs_files[i].name,
@@ -232,9 +233,23 @@ nouveau_drm_debugfs_init(struct drm_minor *minor)
return -ENOMEM;
}
- return drm_debugfs_create_files(nouveau_debugfs_list,
- NOUVEAU_DEBUGFS_ENTRIES,
- minor->debugfs_root, minor);
+ ret = drm_debugfs_create_files(nouveau_debugfs_list,
+ NOUVEAU_DEBUGFS_ENTRIES,
+ minor->debugfs_root, minor);
+ if (ret)
+ return ret;
+
+ /* Set the size of the vbios since we know it, and it's confusing to
+* userspace if it wants to seek() but the file has a length of 0
+*/
+ dentry = debugfs_lookup("vbios.rom", minor->debugfs_root);
+ if (!dentry)
+ return 0;
+
+ d_inode(dentry)->i_size = drm->vbios.length;
+ dput(dentry);
+
+ return 0;
}
int
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/2] drm/nouveau: Allow parsing vbios.rom with nvbios from debugfs
This is a small patch series that adds a strap_peek file into our debugfs, and sets the size of the vbios.rom debugfs file so that nvbios can easily be used to parse the vbios even on systems where the normal BIOS retrieval methods (for example, laptops that need ACPI to access the vbios for the nvidia GPU) won't work. This should make it a little easier to collect vbioses. Lyude Paul (2): drm/nouveau: Add strap_peek to debugfs drm/nouveau: Add size to vbios.rom file in debugfs drivers/gpu/drm/nouveau/nouveau_debugfs.c | 46 --- 1 file changed, 41 insertions(+), 5 deletions(-) -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/nouveau: Add strap_peek to debugfs
Since we already expose the vbios.rom file here, why not also expose the
strap_peek?
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/nouveau_debugfs.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_debugfs.c
b/drivers/gpu/drm/nouveau/nouveau_debugfs.c
index 9109b69cd052..7379c20584a2 100644
--- a/drivers/gpu/drm/nouveau/nouveau_debugfs.c
+++ b/drivers/gpu/drm/nouveau/nouveau_debugfs.c
@@ -46,6 +46,26 @@ nouveau_debugfs_vbios_image(struct seq_file *m, void *data)
return 0;
}
+static int
+nouveau_debugfs_strap_peek(struct seq_file *m, void *data)
+{
+ struct drm_info_node *node = m->private;
+ struct nouveau_drm *drm = nouveau_drm(node->minor->dev);
+ int ret;
+
+ ret = pm_runtime_get_sync(drm->dev->dev);
+ if (ret < 0 && ret != -EACCES)
+ return ret;
+
+ seq_printf(m, "0x%08x\n",
+ nvif_rd32(&drm->client.device.object, 0x101000));
+
+ pm_runtime_mark_last_busy(drm->dev->dev);
+ pm_runtime_put_autosuspend(drm->dev->dev);
+
+ return 0;
+}
+
static int
nouveau_debugfs_pstate_get(struct seq_file *m, void *data)
{
@@ -185,7 +205,8 @@ static const struct file_operations nouveau_pstate_fops = {
};
static struct drm_info_list nouveau_debugfs_list[] = {
- { "vbios.rom", nouveau_debugfs_vbios_image, 0, NULL },
+ { "vbios.rom", nouveau_debugfs_vbios_image, 0, NULL },
+ { "strap_peek", nouveau_debugfs_strap_peek, 0, NULL },
};
#define NOUVEAU_DEBUGFS_ENTRIES ARRAY_SIZE(nouveau_debugfs_list)
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107991] RX580 ~ ring gfx timeout ~ particular shaders created by a dolphin-emu game can bring down AMDGPU
https://bugs.freedesktop.org/show_bug.cgi?id=107991 Bug ID: 107991 Summary: RX580 ~ ring gfx timeout ~ particular shaders created by a dolphin-emu game can bring down AMDGPU Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: major Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel@lists.freedesktop.org Reporter: kyle.de...@mykolab.com QA Contact: dri-devel@lists.freedesktop.org Created attachment 141652 --> https://bugs.freedesktop.org/attachment.cgi?id=141652&action=edit dolphin-emu apitrace I have successfully captured an apitrace that intercepted the crashy frame before the driver crashed. The issues occur at very specific parts of Fire Emblem: Path of Radiance, where the frames / shaders / textures generated by dolphin-emu cause the driver to crash. -- 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 107991] RX580 ~ ring gfx timeout ~ particular shaders created by a dolphin-emu game can bring down AMDGPU ~ attached apitrace
https://bugs.freedesktop.org/show_bug.cgi?id=107991 kyle.de...@mykolab.com changed: What|Removed |Added Summary|RX580 ~ ring gfx timeout ~ |RX580 ~ ring gfx timeout ~ |particular shaders created |particular shaders created |by a dolphin-emu game can |by a dolphin-emu game can |bring down AMDGPU |bring down AMDGPU ~ ||attached apitrace -- 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 107991] RX580 ~ ring gfx timeout ~ particular shaders created by a dolphin-emu game can bring down AMDGPU ~ attached apitrace
https://bugs.freedesktop.org/show_bug.cgi?id=107991 --- Comment #1 from kyle.de...@mykolab.com --- I'm running Mesa master compiled with LLVM master, and kernel 4.18.8. -- 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 1/3] drm/msm: dpu: Clear frame_busy_mask bit after trace
From: Sean Paul
We're printing the frame_busy_mask in a trace, but after it's been
cleared. This, as it turns out, is pretty pointless.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index c2e8985b4c54..e56f29190121 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -1361,9 +1361,9 @@ static void dpu_encoder_frame_done_callback(
/* One of the physical encoders has become idle */
for (i = 0; i < dpu_enc->num_phys_encs; i++) {
if (dpu_enc->phys_encs[i] == ready_phys) {
- clear_bit(i, dpu_enc->frame_busy_mask);
trace_dpu_enc_frame_done_cb(DRMID(drm_enc), i,
dpu_enc->frame_busy_mask[0]);
+ clear_bit(i, dpu_enc->frame_busy_mask);
}
}
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] drm/msm: dpu: Add extra_flush_bits to trigger_flush trace
From: Sean Paul
It's useful to know which bits of the flush come from "extra_flush_bits"
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 3 ++-
drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h | 14 +-
2 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index e56f29190121..8f6880db5c99 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -1444,7 +1444,8 @@ static inline void _dpu_encoder_trigger_flush(struct
drm_encoder *drm_enc,
ret = ctl->ops.get_pending_flush(ctl);
trace_dpu_enc_trigger_flush(DRMID(drm_enc), phys->intf_idx,
- pending_kickoff_cnt, ctl->idx, ret);
+ pending_kickoff_cnt, ctl->idx,
+ extra_flush_bits, ret);
}
/**
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h
index 0be51db02f2e..ae6b0c51ba52 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h
@@ -468,14 +468,16 @@ TRACE_EVENT(dpu_enc_frame_done_cb,
TRACE_EVENT(dpu_enc_trigger_flush,
TP_PROTO(uint32_t drm_id, enum dpu_intf intf_idx,
-int pending_kickoff_cnt, int ctl_idx, u32 pending_flush_ret),
+int pending_kickoff_cnt, int ctl_idx, u32 extra_flush_bits,
+u32 pending_flush_ret),
TP_ARGS(drm_id, intf_idx, pending_kickoff_cnt, ctl_idx,
- pending_flush_ret),
+ extra_flush_bits, pending_flush_ret),
TP_STRUCT__entry(
__field(uint32_t, drm_id )
__field(enum dpu_intf, intf_idx)
__field(int,pending_kickoff_cnt )
__field(int,ctl_idx )
+ __field(u32,extra_flush_bits)
__field(u32,pending_flush_ret )
),
TP_fast_assign(
@@ -483,12 +485,14 @@ TRACE_EVENT(dpu_enc_trigger_flush,
__entry->intf_idx = intf_idx;
__entry->pending_kickoff_cnt = pending_kickoff_cnt;
__entry->ctl_idx = ctl_idx;
+ __entry->extra_flush_bits = extra_flush_bits;
__entry->pending_flush_ret = pending_flush_ret;
),
TP_printk("id=%u, intf_idx=%d, pending_kickoff_cnt=%d ctl_idx=%d "
- "pending_flush_ret=%u", __entry->drm_id,
- __entry->intf_idx, __entry->pending_kickoff_cnt,
- __entry->ctl_idx, __entry->pending_flush_ret)
+ "extra_flush_bits=0x%x pending_flush_ret=0x%x",
+ __entry->drm_id, __entry->intf_idx,
+ __entry->pending_kickoff_cnt, __entry->ctl_idx,
+ __entry->extra_flush_bits, __entry->pending_flush_ret)
);
DECLARE_EVENT_CLASS(dpu_enc_ktime_template,
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] drm/msm: dpu: Don't store/deref pointers in trace ringbuffer
From: Sean Paul
TP_printk is not synchronous, so storing pointers and then later
derferencing them is a Bad Idea. This patch stores everything locally to
avoid display stomped memory.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h | 98 +--
1 file changed, 55 insertions(+), 43 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h
index ae6b0c51ba52..e12c4cefb742 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h
@@ -686,37 +686,41 @@ TRACE_EVENT(dpu_crtc_setup_mixer,
TP_STRUCT__entry(
__field(uint32_t, crtc_id )
__field(uint32_t, plane_id)
- __field(struct drm_plane_state*,state )
- __field(struct dpu_plane_state*,pstate )
+ __field(uint32_t, fb_id )
+ __field_struct( struct drm_rect,src_rect)
+ __field_struct( struct drm_rect,dst_rect)
__field(uint32_t, stage_idx )
+ __field(enum dpu_stage, stage )
__field(enum dpu_sspp, sspp)
+ __field(uint32_t, multirect_idx )
+ __field(uint32_t, multirect_mode )
__field(uint32_t, pixel_format)
__field(uint64_t, modifier)
),
TP_fast_assign(
__entry->crtc_id = crtc_id;
__entry->plane_id = plane_id;
- __entry->state = state;
- __entry->pstate = pstate;
+ __entry->fb_id = state ? state->fb->base.id : 0;
+ __entry->src_rect = drm_plane_state_src(state);
+ __entry->dst_rect = drm_plane_state_dest(state);
__entry->stage_idx = stage_idx;
+ __entry->stage = pstate->stage;
__entry->sspp = sspp;
+ __entry->multirect_idx = pstate->multirect_index;
+ __entry->multirect_mode = pstate->multirect_mode;
__entry->pixel_format = pixel_format;
__entry->modifier = modifier;
),
- TP_printk("crtc_id:%u plane_id:%u fb_id:%u src:{%ux%u+%ux%u} "
- "dst:{%ux%u+%ux%u} stage_idx:%u stage:%d, sspp:%d "
+ TP_printk("crtc_id:%u plane_id:%u fb_id:%u src:" DRM_RECT_FP_FMT
+ " dst:" DRM_RECT_FMT " stage_idx:%u stage:%d, sspp:%d "
"multirect_index:%d multirect_mode:%u pix_format:%u "
"modifier:%llu",
- __entry->crtc_id, __entry->plane_id,
- __entry->state->fb ? __entry->state->fb->base.id : -1,
- __entry->state->src_w >> 16, __entry->state->src_h >> 16,
- __entry->state->src_x >> 16, __entry->state->src_y >> 16,
- __entry->state->crtc_w, __entry->state->crtc_h,
- __entry->state->crtc_x, __entry->state->crtc_y,
- __entry->stage_idx, __entry->pstate->stage, __entry->sspp,
- __entry->pstate->multirect_index,
- __entry->pstate->multirect_mode, __entry->pixel_format,
- __entry->modifier)
+ __entry->crtc_id, __entry->plane_id, __entry->fb_id,
+ DRM_RECT_FP_ARG(&__entry->src_rect),
+ DRM_RECT_ARG(&__entry->dst_rect),
+ __entry->stage_idx, __entry->stage, __entry->sspp,
+ __entry->multirect_idx, __entry->multirect_mode,
+ __entry->pixel_format, __entry->modifier)
);
TRACE_EVENT(dpu_crtc_setup_lm_bounds,
@@ -725,15 +729,15 @@ TRACE_EVENT(dpu_crtc_setup_lm_bounds,
TP_STRUCT__entry(
__field(uint32_t, drm_id )
__field(int,mixer )
- __field(struct drm_rect *, bounds )
+ __field_struct( struct drm_rect,bounds )
),
TP_fast_assign(
__entry->drm_id = drm_id;
__entry->mixer = mixer;
- __entry->bounds = bounds;
+ __entry->bounds = *bounds;
),
TP_printk("id:%u mixer:%d bounds:" DRM_RECT_FMT, __entry->drm_id,
- __entry->mixer, DRM_RECT_ARG(__entry->bounds))
+ __entry->mixer, DRM_RECT_ARG(&__entry->bounds))
);
TRACE_EVENT(dpu_crtc_vblank_enable,
@@ -744,21 +748,25 @@ TRACE_EVENT(dpu_crtc_vblank_enable,
__field(uint32_t, drm_id )
__field(uint32_t, enc_id )
__field(bool,
[Bug 107950] Delayed freeze with DRI_PRIME=1 on Topaz
https://bugs.freedesktop.org/show_bug.cgi?id=107950 --- Comment #8 from SET --- (In reply to Michel Dänzer from comment #6) Tried with xf86-video-ati 18.1.0 : Same delayed freeze. I think the host gets overheated. The last line in kernel.log is Sep 19 20:44:44 hp2 kernel: [ 337.131484] amdgpu: [powerplay] GPU over temperature range detected on PCIe 0:0.0! I was monitoring the temperature with 'sensors' command. Last output for amdgpu sensor was : amdgpu-pci-0100 Adapter: PCI adapter vddgfx: +0.82 V fan1: N/A temp1:+190.0°C (crit = +104000.0°C, hyst = -273.1°C) power1:1.04 kW (cap = 30.00 W) Perhaps powerplay needs some fix ? Regards. -- 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 107991] RX580 ~ ring gfx timeout ~ particular shaders created by a dolphin-emu game can bring down AMDGPU ~ attached apitrace
https://bugs.freedesktop.org/show_bug.cgi?id=107991 kyle.de...@mykolab.com changed: What|Removed |Added Product|Mesa|DRI Component|Drivers/Gallium/radeonsi|DRM/AMDgpu Version|git |unspecified QA Contact|dri-devel@lists.freedesktop | |.org| -- 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/3] drm/msm: dpu: Clear frame_busy_mask bit after trace
On 2018-09-19 11:33, Sean Paul wrote:
From: Sean Paul
We're printing the frame_busy_mask in a trace, but after it's been
cleared. This, as it turns out, is pretty pointless.
Signed-off-by: Sean Paul
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index c2e8985b4c54..e56f29190121 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -1361,9 +1361,9 @@ static void dpu_encoder_frame_done_callback(
/* One of the physical encoders has become idle */
for (i = 0; i < dpu_enc->num_phys_encs; i++) {
if (dpu_enc->phys_encs[i] == ready_phys) {
- clear_bit(i, dpu_enc->frame_busy_mask);
trace_dpu_enc_frame_done_cb(DRMID(drm_enc), i,
dpu_enc->frame_busy_mask[0]);
+ clear_bit(i, dpu_enc->frame_busy_mask);
}
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] drm/msm: dpu: Add extra_flush_bits to trigger_flush trace
On 2018-09-19 11:33, Sean Paul wrote:
From: Sean Paul
It's useful to know which bits of the flush come from
"extra_flush_bits"
Signed-off-by: Sean Paul
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 3 ++-
drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h | 14 +-
2 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index e56f29190121..8f6880db5c99 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -1444,7 +1444,8 @@ static inline void
_dpu_encoder_trigger_flush(struct drm_encoder *drm_enc,
ret = ctl->ops.get_pending_flush(ctl);
trace_dpu_enc_trigger_flush(DRMID(drm_enc), phys->intf_idx,
- pending_kickoff_cnt, ctl->idx, ret);
+ pending_kickoff_cnt, ctl->idx,
+ extra_flush_bits, ret);
}
/**
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h
index 0be51db02f2e..ae6b0c51ba52 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h
@@ -468,14 +468,16 @@ TRACE_EVENT(dpu_enc_frame_done_cb,
TRACE_EVENT(dpu_enc_trigger_flush,
TP_PROTO(uint32_t drm_id, enum dpu_intf intf_idx,
-int pending_kickoff_cnt, int ctl_idx, u32 pending_flush_ret),
+int pending_kickoff_cnt, int ctl_idx, u32 extra_flush_bits,
+u32 pending_flush_ret),
TP_ARGS(drm_id, intf_idx, pending_kickoff_cnt, ctl_idx,
- pending_flush_ret),
+ extra_flush_bits, pending_flush_ret),
TP_STRUCT__entry(
__field(uint32_t, drm_id )
__field(enum dpu_intf, intf_idx)
__field(int,pending_kickoff_cnt )
__field(int,ctl_idx )
+ __field(u32,extra_flush_bits)
__field(u32,pending_flush_ret )
),
TP_fast_assign(
@@ -483,12 +485,14 @@ TRACE_EVENT(dpu_enc_trigger_flush,
__entry->intf_idx = intf_idx;
__entry->pending_kickoff_cnt = pending_kickoff_cnt;
__entry->ctl_idx = ctl_idx;
+ __entry->extra_flush_bits = extra_flush_bits;
__entry->pending_flush_ret = pending_flush_ret;
),
TP_printk("id=%u, intf_idx=%d, pending_kickoff_cnt=%d ctl_idx=%d "
- "pending_flush_ret=%u", __entry->drm_id,
- __entry->intf_idx, __entry->pending_kickoff_cnt,
- __entry->ctl_idx, __entry->pending_flush_ret)
+ "extra_flush_bits=0x%x pending_flush_ret=0x%x",
+ __entry->drm_id, __entry->intf_idx,
+ __entry->pending_kickoff_cnt, __entry->ctl_idx,
+ __entry->extra_flush_bits, __entry->pending_flush_ret)
);
DECLARE_EVENT_CLASS(dpu_enc_ktime_template,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-misc-next
Hi Dave, Another week another PR. There's a conflict in i915_drv.c, as you may have seen from Stephen's email earlier this week. The rerere cache has the resolution, so dim to the rescue! drm-misc-next-2018-09-19: drm-misc-next for 4.20: UAPI Changes: - None Cross-subsystem Changes: - None Core Changes: - Allow drivers to disable features with per-device granularity (Ville) - Use EOPNOTSUPP when iface/feature is unsupported instead of EINVAL/errno soup (Chris) - Simplify M/N DP quirk by using constant N to limit size of M/N (Shawn) - add quirk for LG LP140WF6-SPM1 eDP panel (Shawn) Driver Changes: - i915/amdgpu: Disable DRIVER_ATOMIC for older/unsupported devices (Ville) - sun4i: add support for R40 HDMI PHY (Icenowy) Cc: Ville Syrjälä Cc: Chris Wilson Cc: Icenowy Zheng Cc: Lee, Shawn C Cheers, Sean The following changes since commit 169cc4c7a14e988985c8833ddec2f3e897de2c28: drm: bridge: document bridge attach/detach imbalance (2018-09-13 11:28:12 +0200) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2018-09-19 for you to fetch changes up to e884818cc0edb9bd128de95e7ca6b569f4667c0f: drm: add LG eDP panel to quirk database (2018-09-19 16:44:12 +0300) drm-misc-next for 4.20: UAPI Changes: - None Cross-subsystem Changes: - None Core Changes: - Allow drivers to disable features with per-device granularity (Ville) - Use EOPNOTSUPP when iface/feature is unsupported instead of EINVAL/errno soup (Chris) - Simplify M/N DP quirk by using constant N to limit size of M/N (Shawn) - add quirk for LG LP140WF6-SPM1 eDP panel (Shawn) Driver Changes: - i915/amdgpu: Disable DRIVER_ATOMIC for older/unsupported devices (Ville) - sun4i: add support for R40 HDMI PHY (Icenowy) Cc: Ville Syrjälä Cc: Chris Wilson Cc: Icenowy Zheng Cc: Lee, Shawn C Chris Wilson (1): drm: Differentiate the lack of an interface from invalid parameter Dan Carpenter (1): udmabuf: fix error code in map_udmabuf() Icenowy Zheng (2): dt-bindings: sun4i-drm: add compatible for R40 HDMI PHY drm/sun4i: add support for R40 HDMI PHY Jiandi An (1): drm/virtio: add dma sync for dma mapped virtio gpu framebuffer pages Lee, Shawn C (3): drm: Add support for device_id based detection. drm: Change limited M/N quirk to constant N quirk. drm: add LG eDP panel to quirk database Ville Syrjälä (3): drm: Introduce per-device driver_features drm/i915: Clear DRIVER_ATOMIC on a per-device basis drm/amdgpu: Use per-device driver_features to disable atomic .../bindings/display/sunxi/sun4i-drm.txt | 5 ++-- drivers/dma-buf/udmabuf.c | 4 ++- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 12 +++- 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_dp_helper.c| 17 +++- drivers/gpu/drm/drm_drv.c | 3 ++ 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 +-- drivers/gpu/drm/i915/i915_drv.c| 8 +++--- drivers/gpu/drm/i915/intel_display.c | 28 +-- drivers/gpu/drm/i915/intel_display.h | 2 +- drivers/gpu/drm/i915/intel_dp.c| 8 +++--- drivers/gpu/drm/i915/intel_dp_mst.c| 6 ++-- drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 12 drivers/gpu/drm/virtio/virtgpu_drv.h | 8 ++ drivers/gpu/drm/virtio/virtgpu_fb.c
Re: [PATCH 3/3] drm/msm: dpu: Don't store/deref pointers in trace ringbuffer
On 2018-09-19 11:33, Sean Paul wrote:
From: Sean Paul
TP_printk is not synchronous, so storing pointers and then later
derferencing them is a Bad Idea. This patch stores everything locally
to
minor typo "dereferencing",
avoid display stomped memory.
Signed-off-by: Sean Paul
After fixing the minor nit please add,
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h | 98 +--
1 file changed, 55 insertions(+), 43 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h
index ae6b0c51ba52..e12c4cefb742 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h
@@ -686,37 +686,41 @@ TRACE_EVENT(dpu_crtc_setup_mixer,
TP_STRUCT__entry(
__field(uint32_t, crtc_id )
__field(uint32_t, plane_id)
- __field(struct drm_plane_state*,state )
- __field(struct dpu_plane_state*,pstate )
+ __field(uint32_t, fb_id )
+ __field_struct( struct drm_rect,src_rect)
+ __field_struct( struct drm_rect,dst_rect)
__field(uint32_t, stage_idx )
+ __field(enum dpu_stage, stage )
__field(enum dpu_sspp, sspp)
+ __field(uint32_t, multirect_idx )
+ __field(uint32_t, multirect_mode )
__field(uint32_t, pixel_format)
__field(uint64_t, modifier)
),
TP_fast_assign(
__entry->crtc_id = crtc_id;
__entry->plane_id = plane_id;
- __entry->state = state;
- __entry->pstate = pstate;
+ __entry->fb_id = state ? state->fb->base.id : 0;
+ __entry->src_rect = drm_plane_state_src(state);
+ __entry->dst_rect = drm_plane_state_dest(state);
__entry->stage_idx = stage_idx;
+ __entry->stage = pstate->stage;
__entry->sspp = sspp;
+ __entry->multirect_idx = pstate->multirect_index;
+ __entry->multirect_mode = pstate->multirect_mode;
__entry->pixel_format = pixel_format;
__entry->modifier = modifier;
),
- TP_printk("crtc_id:%u plane_id:%u fb_id:%u src:{%ux%u+%ux%u} "
- "dst:{%ux%u+%ux%u} stage_idx:%u stage:%d, sspp:%d "
+ TP_printk("crtc_id:%u plane_id:%u fb_id:%u src:" DRM_RECT_FP_FMT
+ " dst:" DRM_RECT_FMT " stage_idx:%u stage:%d, sspp:%d "
"multirect_index:%d multirect_mode:%u pix_format:%u "
"modifier:%llu",
- __entry->crtc_id, __entry->plane_id,
- __entry->state->fb ? __entry->state->fb->base.id : -1,
- __entry->state->src_w >> 16, __entry->state->src_h >> 16,
- __entry->state->src_x >> 16, __entry->state->src_y >> 16,
- __entry->state->crtc_w, __entry->state->crtc_h,
- __entry->state->crtc_x, __entry->state->crtc_y,
- __entry->stage_idx, __entry->pstate->stage, __entry->sspp,
- __entry->pstate->multirect_index,
- __entry->pstate->multirect_mode, __entry->pixel_format,
- __entry->modifier)
+ __entry->crtc_id, __entry->plane_id, __entry->fb_id,
+ DRM_RECT_FP_ARG(&__entry->src_rect),
+ DRM_RECT_ARG(&__entry->dst_rect),
+ __entry->stage_idx, __entry->stage, __entry->sspp,
+ __entry->multirect_idx, __entry->multirect_mode,
+ __entry->pixel_format, __entry->modifier)
);
TRACE_EVENT(dpu_crtc_setup_lm_bounds,
@@ -725,15 +729,15 @@ TRACE_EVENT(dpu_crtc_setup_lm_bounds,
TP_STRUCT__entry(
__field(uint32_t, drm_id )
__field(int,mixer )
- __field(struct drm_rect *, bounds )
+ __field_struct( struct drm_rect,bounds )
),
TP_fast_assign(
__entry->drm_id = drm_id;
__entry->mixer = mixer;
- __entry->bounds = bounds;
+ __entry->bounds = *bounds;
),
TP_printk("id:%u mixer:%d bounds:" DRM_RECT_FMT, __entry->drm_id,
- __entry->mixer, DRM_RECT_ARG(__entry->bounds))
+ __entry->mixer, DRM_RECT_ARG(&__entry->bounds))
);
TRACE_EVENT(dpu_crtc_vblank_enable,
@@ -744,21 +748,25 @@ TRACE_EVENT(dpu_crtc_vblank_enable,
__field(uint32_t,
Re: [PATCH 1/6] drm/dp_mst: Introduce drm_dp_mst_connector_atomic_check() (fwd)
Hello,
I don't think you can update the loop index variable in
list_for_each_entry, because the mcro uses th index variable to get to the
next element. Perhaps list_for_each_entry_safe would be more suitable?
julia
-- Forwarded message --
Date: Thu, 20 Sep 2018 04:30:13 +0800
From: kbuild test robot
To: kbu...@01.org
Cc: Julia Lawall
Subject: Re: [PATCH 1/6] drm/dp_mst: Introduce
drm_dp_mst_connector_atomic_check()
CC: kbuild-...@01.org
In-Reply-To: <20180918230637.20700-2-ly...@redhat.com>
References: <20180918230637.20700-2-ly...@redhat.com>
TO: Lyude Paul
CC: dri-devel@lists.freedesktop.org, nouv...@lists.freedesktop.org,
intel-...@lists.freedesktop.org, amd-...@lists.freedesktop.org
CC: David Airlie , linux-ker...@vger.kernel.org,
sta...@vger.kernel.org, Sean Paul
Hi Lyude,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on v4.19-rc4 next-20180919]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Lyude-Paul/Fix-legacy-DPMS-changes-with-MST/20180919-203434
base: git://anongit.freedesktop.org/drm-intel for-linux-next
:: branch date: 8 hours ago
:: commit date: 8 hours ago
>> drivers/gpu/drm/drm_dp_mst_topology.c:3144:1-20: iterator with update on
>> line 3145
#
https://github.com/0day-ci/linux/commit/f8df31d5221b9a6da6698d4a37e622253bb17cdc
git remote add linux-review https://github.com/0day-ci/linux
git remote update linux-review
git checkout f8df31d5221b9a6da6698d4a37e622253bb17cdc
vim +3144 drivers/gpu/drm/drm_dp_mst_topology.c
3f3353b7 Pandiyan, Dhinakaran 2017-04-20 3131
f8df31d5 Lyude Paul 2018-09-18 3132 static bool
f8df31d5 Lyude Paul 2018-09-18 3133
drm_dp_mst_connector_still_exists(struct drm_connector *connector,
f8df31d5 Lyude Paul 2018-09-18 3134
struct drm_dp_mst_topology_mgr *mgr,
f8df31d5 Lyude Paul 2018-09-18 3135
struct drm_dp_mst_branch *mstb)
f8df31d5 Lyude Paul 2018-09-18 3136 {
f8df31d5 Lyude Paul 2018-09-18 3137 struct drm_dp_mst_port
*port;
f8df31d5 Lyude Paul 2018-09-18 3138 bool exists = false;
f8df31d5 Lyude Paul 2018-09-18 3139
f8df31d5 Lyude Paul 2018-09-18 3140 mstb =
drm_dp_get_validated_mstb_ref(mgr, mstb);
f8df31d5 Lyude Paul 2018-09-18 3141 if (!mstb)
f8df31d5 Lyude Paul 2018-09-18 3142 return false;
f8df31d5 Lyude Paul 2018-09-18 3143
f8df31d5 Lyude Paul 2018-09-18 @3144
list_for_each_entry(port, &mstb->ports, next) {
f8df31d5 Lyude Paul 2018-09-18 @3145 port =
drm_dp_get_validated_port_ref(mgr, port);
f8df31d5 Lyude Paul 2018-09-18 3146 if (!port)
f8df31d5 Lyude Paul 2018-09-18 3147
continue;
f8df31d5 Lyude Paul 2018-09-18 3148
f8df31d5 Lyude Paul 2018-09-18 3149 exists =
(port->connector == connector ||
f8df31d5 Lyude Paul 2018-09-18 3150
(port->mstb &&
f8df31d5 Lyude Paul 2018-09-18 3151
drm_dp_mst_connector_still_exists(connector, mgr,
f8df31d5 Lyude Paul 2018-09-18 3152
port->mstb)));
f8df31d5 Lyude Paul 2018-09-18 3153
f8df31d5 Lyude Paul 2018-09-18 3154
drm_dp_put_port(port);
f8df31d5 Lyude Paul 2018-09-18 3155 if (exists)
f8df31d5 Lyude Paul 2018-09-18 3156 break;
f8df31d5 Lyude Paul 2018-09-18 3157 }
f8df31d5 Lyude Paul 2018-09-18 3158
f8df31d5 Lyude Paul 2018-09-18 3159
drm_dp_put_mst_branch_device(mstb);
f8df31d5 Lyude Paul 2018-09-18 3160 return exists;
f8df31d5 Lyude Paul 2018-09-18 3161 }
f8df31d5 Lyude Paul 2018-09-18 3162
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] MAINTAINERS: Move udl drm driver to drm-misc tree
From: Sean Paul Move udl maintenance into drm-misc tree. I've also signed up to be a reviewer, but have kept it at "Odd Fixes" level of support. Cc: Dave Airlie Cc: David Airlie Cc: Gustavo Padovan Cc: Maarten Lankhorst Signed-off-by: Sean Paul --- MAINTAINERS | 3 +++ 1 file changed, 3 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 9d9068ed4ee5..ba1dbb8735b8 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4720,8 +4720,11 @@ F: drivers/gpu/drm/tdfx/ DRM DRIVER FOR USB DISPLAYLINK VIDEO ADAPTERS M: Dave Airlie +R: Sean Paul +L: dri-devel@lists.freedesktop.org S: Odd Fixes F: drivers/gpu/drm/udl/ +T: git git://anongit.freedesktop.org/drm/drm-misc DRM DRIVER FOR VMWARE VIRTUAL GPU M: "VMware Graphics" -- Sean Paul, Software Engineer, Google / Chromium OS ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] MAINTAINERS: Move mxsfb drm driver to drm-misc tree
From: Sean Paul Another "small driver" moving into drm-misc. Stefan has also offered to co-maintain it. Cc: Marek Vasut Cc: Stefan Agner Cc: David Airlie Cc: Gustavo Padovan Cc: Maarten Lankhorst Signed-off-by: Sean Paul --- MAINTAINERS | 3 +++ 1 file changed, 3 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index ba1dbb8735b8..7184d53dcbd8 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -9891,9 +9891,12 @@ F: drivers/media/tuners/mxl5007t.* MXSFB DRM DRIVER M: Marek Vasut +M: Stefan Agner +L: dri-devel@lists.freedesktop.org S: Supported F: drivers/gpu/drm/mxsfb/ F: Documentation/devicetree/bindings/display/mxsfb.txt +T: git git://anongit.freedesktop.org/drm/drm-misc MYRICOM MYRI-10G 10GbE DRIVER (MYRI10GE) M: Chris Lee -- Sean Paul, Software Engineer, Google / Chromium OS ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] drm/msm: dpu: Don't store/deref pointers in trace ringbuffer
On Wed, Sep 19, 2018 at 01:04:42PM -0700, Abhinav Kumar wrote:
> On 2018-09-19 11:33, Sean Paul wrote:
> > From: Sean Paul
> >
> > TP_printk is not synchronous, so storing pointers and then later
> > derferencing them is a Bad Idea. This patch stores everything locally to
> minor typo "dereferencing",
> > avoid display stomped memory.
> >
> > Signed-off-by: Sean Paul
> After fixing the minor nit please add,
> Reviewed-by: Abhinav Kumar
Thanks for the reviews, Abhinav, I've stuffed the set in dpu-staging/for-next.
Sean
> > ---
> > drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h | 98 +--
> > 1 file changed, 55 insertions(+), 43 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h
> > b/drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h
> > index ae6b0c51ba52..e12c4cefb742 100644
> > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h
> > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h
> > @@ -686,37 +686,41 @@ TRACE_EVENT(dpu_crtc_setup_mixer,
> > TP_STRUCT__entry(
> > __field(uint32_t, crtc_id )
> > __field(uint32_t, plane_id)
> > - __field(struct drm_plane_state*,state )
> > - __field(struct dpu_plane_state*,pstate )
> > + __field(uint32_t, fb_id )
> > + __field_struct( struct drm_rect,src_rect)
> > + __field_struct( struct drm_rect,dst_rect)
> > __field(uint32_t, stage_idx )
> > + __field(enum dpu_stage, stage )
> > __field(enum dpu_sspp, sspp)
> > + __field(uint32_t, multirect_idx )
> > + __field(uint32_t, multirect_mode )
> > __field(uint32_t, pixel_format)
> > __field(uint64_t, modifier)
> > ),
> > TP_fast_assign(
> > __entry->crtc_id = crtc_id;
> > __entry->plane_id = plane_id;
> > - __entry->state = state;
> > - __entry->pstate = pstate;
> > + __entry->fb_id = state ? state->fb->base.id : 0;
> > + __entry->src_rect = drm_plane_state_src(state);
> > + __entry->dst_rect = drm_plane_state_dest(state);
> > __entry->stage_idx = stage_idx;
> > + __entry->stage = pstate->stage;
> > __entry->sspp = sspp;
> > + __entry->multirect_idx = pstate->multirect_index;
> > + __entry->multirect_mode = pstate->multirect_mode;
> > __entry->pixel_format = pixel_format;
> > __entry->modifier = modifier;
> > ),
> > - TP_printk("crtc_id:%u plane_id:%u fb_id:%u src:{%ux%u+%ux%u} "
> > - "dst:{%ux%u+%ux%u} stage_idx:%u stage:%d, sspp:%d "
> > + TP_printk("crtc_id:%u plane_id:%u fb_id:%u src:" DRM_RECT_FP_FMT
> > + " dst:" DRM_RECT_FMT " stage_idx:%u stage:%d, sspp:%d "
> > "multirect_index:%d multirect_mode:%u pix_format:%u "
> > "modifier:%llu",
> > - __entry->crtc_id, __entry->plane_id,
> > - __entry->state->fb ? __entry->state->fb->base.id : -1,
> > - __entry->state->src_w >> 16, __entry->state->src_h >> 16,
> > - __entry->state->src_x >> 16, __entry->state->src_y >> 16,
> > - __entry->state->crtc_w, __entry->state->crtc_h,
> > - __entry->state->crtc_x, __entry->state->crtc_y,
> > - __entry->stage_idx, __entry->pstate->stage, __entry->sspp,
> > - __entry->pstate->multirect_index,
> > - __entry->pstate->multirect_mode, __entry->pixel_format,
> > - __entry->modifier)
> > + __entry->crtc_id, __entry->plane_id, __entry->fb_id,
> > + DRM_RECT_FP_ARG(&__entry->src_rect),
> > + DRM_RECT_ARG(&__entry->dst_rect),
> > + __entry->stage_idx, __entry->stage, __entry->sspp,
> > + __entry->multirect_idx, __entry->multirect_mode,
> > + __entry->pixel_format, __entry->modifier)
> > );
> >
> > TRACE_EVENT(dpu_crtc_setup_lm_bounds,
> > @@ -725,15 +729,15 @@ TRACE_EVENT(dpu_crtc_setup_lm_bounds,
> > TP_STRUCT__entry(
> > __field(uint32_t, drm_id )
> > __field(int,mixer )
> > - __field(struct drm_rect *, bounds )
> > + __field_struct( struct drm_rect,bounds )
> > ),
> > TP_fast_assign(
> > __entry->drm_id = drm_id;
> > __entry->mixer = mixer;
> > - __entry->bounds = bounds;
> > + __entry->bounds = *bounds;
> > ),
> > TP_printk("id:%u mixer:%d bounds:" DRM_RECT_FMT, __entry->drm_id,
> > - __entry->mixer, DRM_RECT_ARG
Re: [PATCH 1/2] MAINTAINERS: Move udl drm driver to drm-misc tree
On Thu, Sep 20, 2018 at 6:40 AM Sean Paul wrote: > > From: Sean Paul > > Move udl maintenance into drm-misc tree. I've also signed up to be a > reviewer, but have kept it at "Odd Fixes" level of support. > > Cc: Dave Airlie Acked-by: Dave Airlie > Cc: David Airlie > Cc: Gustavo Padovan > Cc: Maarten Lankhorst > Signed-off-by: Sean Paul > --- > MAINTAINERS | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 9d9068ed4ee5..ba1dbb8735b8 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -4720,8 +4720,11 @@ F: drivers/gpu/drm/tdfx/ > > DRM DRIVER FOR USB DISPLAYLINK VIDEO ADAPTERS > M: Dave Airlie > +R: Sean Paul > +L: dri-devel@lists.freedesktop.org > S: Odd Fixes > F: drivers/gpu/drm/udl/ > +T: git git://anongit.freedesktop.org/drm/drm-misc > > DRM DRIVER FOR VMWARE VIRTUAL GPU > M: "VMware Graphics" > -- > Sean Paul, Software Engineer, Google / Chromium OS > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] gpu: do not double put device node in zx_drm_probe
On Tue, Sep 18, 2018 at 05:19:09PM +0200, Daniel Vetter wrote: > On Mon, Aug 27, 2018 at 9:18 AM, Shawn Guo wrote: > > On Fri, Aug 17, 2018 at 10:24:06AM +0800, zhong jiang wrote: > >> for_each_available_child_of_node will get and put the node properly, > >> the following of_node_put will lead to the double put. So just > >> remove it. > >> > >> Signed-off-by: zhong jiang > > > > Acked-by: Shawn Guo > > Shawn, I'm assuming you'll push this to drm-misc-next? You're the > maintainer with commit rights after all. Just pushed to drm-misc-next. Sorry for the delay. Shawn ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/6] drm/dp_mst: Introduce drm_dp_mst_connector_atomic_check() (fwd)
oh, good catch! will fix and respin in just a little bit
On Wed, 2018-09-19 at 22:38 +0200, Julia Lawall wrote:
> Hello,
>
> I don't think you can update the loop index variable in
> list_for_each_entry, because the mcro uses th index variable to get to the
> next element. Perhaps list_for_each_entry_safe would be more suitable?
>
> julia
>
> -- Forwarded message --
> Date: Thu, 20 Sep 2018 04:30:13 +0800
> From: kbuild test robot
> To: kbu...@01.org
> Cc: Julia Lawall
> Subject: Re: [PATCH 1/6] drm/dp_mst: Introduce
> drm_dp_mst_connector_atomic_check()
>
> CC: kbuild-...@01.org
> In-Reply-To: <20180918230637.20700-2-ly...@redhat.com>
> References: <20180918230637.20700-2-ly...@redhat.com>
> TO: Lyude Paul
> CC: dri-devel@lists.freedesktop.org, nouv...@lists.freedesktop.org,
> intel-...@lists.freedesktop.org, amd-...@lists.freedesktop.org
> CC: David Airlie , linux-ker...@vger.kernel.org,
> sta...@vger.kernel.org, Sean Paul
>
> Hi Lyude,
>
> Thank you for the patch! Perhaps something to improve:
>
> [auto build test WARNING on drm-intel/for-linux-next]
> [also build test WARNING on v4.19-rc4 next-20180919]
> [if your patch is applied to the wrong git tree, please drop us a note to help
> improve the system]
>
> url:
> https://github.com/0day-ci/linux/commits/Lyude-Paul/Fix-legacy-DPMS-changes-with-MST/20180919-203434
> base: git://anongit.freedesktop.org/drm-intel for-linux-next
> :: branch date: 8 hours ago
> :: commit date: 8 hours ago
>
> > > drivers/gpu/drm/drm_dp_mst_topology.c:3144:1-20: iterator with update on
> > > line 3145
>
> #
> https://github.com/0day-ci/linux/commit/f8df31d5221b9a6da6698d4a37e622253bb17cdc
> git remote add linux-review https://github.com/0day-ci/linux
> git remote update linux-review
> git checkout f8df31d5221b9a6da6698d4a37e622253bb17cdc
> vim +3144 drivers/gpu/drm/drm_dp_mst_topology.c
>
> 3f3353b7 Pandiyan, Dhinakaran 2017-04-20 3131
> f8df31d5 Lyude Paul 2018-09-18 3132 static bool
> f8df31d5 Lyude Paul 2018-09-
> 18 3133 drm_dp_mst_connector_still_exists(struct drm_connector *connector,
> f8df31d5 Lyude Paul 2018-09-18 3134
> struct drm_dp_mst_topology_mgr *mgr,
> f8df31d5 Lyude Paul 2018-09-18 3135
> struct drm_dp_mst_branch *mstb)
> f8df31d5 Lyude Paul 2018-09-18 3136 {
> f8df31d5 Lyude Paul 2018-09-18 3137struct drm_dp_mst_port
> *port;
> f8df31d5 Lyude Paul 2018-09-18 3138bool exists = false;
> f8df31d5 Lyude Paul 2018-09-18 3139
> f8df31d5 Lyude Paul 2018-09-18 3140mstb =
> drm_dp_get_validated_mstb_ref(mgr, mstb);
> f8df31d5 Lyude Paul 2018-09-18 3141if (!mstb)
> f8df31d5 Lyude Paul 2018-09-18 3142return false;
> f8df31d5 Lyude Paul 2018-09-18 3143
> f8df31d5 Lyude Paul 2018-09-18 @3144list_for_each_entry(port
> , &mstb->ports, next) {
> f8df31d5 Lyude Paul 2018-09-18 @3145port =
> drm_dp_get_validated_port_ref(mgr, port);
> f8df31d5 Lyude Paul 2018-09-18 3146if (!port)
> f8df31d5 Lyude Paul 2018-09-18 3147continue
> ;
> f8df31d5 Lyude Paul 2018-09-18 3148
> f8df31d5 Lyude Paul 2018-09-18 3149exists = (port-
> >connector == connector ||
> f8df31d5 Lyude Paul 2018-09-18 3150 (port-
> >mstb &&
> f8df31d5 Lyude Paul 2018-09-18 3151 drm_d
> p_mst_connector_still_exists(connector, mgr,
> f8df31d5 Lyude Paul 2018-09-18 3152
>
>port->mstb)));
> f8df31d5 Lyude Paul 2018-09-18 3153
> f8df31d5 Lyude Paul 2018-09-18 3154drm_dp_put_port(
> port);
> f8df31d5 Lyude Paul 2018-09-18 3155if (exists)
> f8df31d5 Lyude Paul 2018-09-18 3156break;
> f8df31d5 Lyude Paul 2018-09-18 3157}
> f8df31d5 Lyude Paul 2018-09-18 3158
> f8df31d5 Lyude Paul 2018-09-18 3159drm_dp_put_mst_branch_de
> vice(mstb);
> f8df31d5 Lyude Paul 2018-09-18 3160return exists;
> f8df31d5 Lyude Paul 2018-09-18 3161 }
> f8df31d5 Lyude Paul 2018-09-18 3162
>
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all Intel Corporation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/6] drm/dp_mst: Introduce drm_dp_mst_connector_atomic_check()
On Wed, 2018-09-19 at 18:58 +, Sasha Levin wrote:
> Hi,
>
> [This is an automated email]
>
> This commit has been processed because it contains a -stable tag.
> The stable tag indicates that it's relevant for the following trees: all
>
> The bot has tested the following trees: v4.18.8, v4.14.70, v4.9.127, v4.4.156,
> v3.18.122,
>
> v4.18.8: Build OK!
> v4.14.70: Build OK!
> v4.9.127: Failed to apply! Possible dependencies:
> 3f3353b7e121 ("drm/dp: Introduce MST topology state to track available
> link bandwidth")
> edb1ed1ab7d3 ("drm/dp: Add DP MST helpers to atomically find and release
> vcpi slots")
>
> v4.4.156: Failed to apply! Possible dependencies:
> 3f3353b7e121 ("drm/dp: Introduce MST topology state to track available
> link bandwidth")
> edb1ed1ab7d3 ("drm/dp: Add DP MST helpers to atomically find and release
> vcpi slots")
>
> v3.18.122: Failed to apply! Possible dependencies:
> 3f3353b7e121 ("drm/dp: Introduce MST topology state to track available
> link bandwidth")
> edb1ed1ab7d3 ("drm/dp: Add DP MST helpers to atomically find and release
> vcpi slots")
>
>
> Please let us know how to resolve this.
...is this the email address I'm supposed to "let you know how to resolve this"
with? if that is the case, it's 100% OK to simply ignore all of the versions
that don't apply with this patch.
>
> --
> Thanks,
> Sasha
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/6] drm/i915: Leave intel_conn->mst_port set, use mst_port_gone instead
On Wed, 2018-09-19 at 18:58 +, Sasha Levin wrote:
> Hi,
>
> [This is an automated email]
>
> This commit has been processed because it contains a -stable tag.
> The stable tag indicates that it's relevant for the following trees: all
>
> The bot has tested the following trees: v4.18.8, v4.14.70, v4.9.127, v4.4.156,
> v3.18.122,
>
> v4.18.8: Build OK!
> v4.14.70: Build OK!
> v4.9.127: Failed to apply! Possible dependencies:
> 06bfe5b0d892 ("drm/i915: Avoid null dereference if mst_port is unset.")
> 22a2c8e0457f ("drm/i915: Validate mode against max. link data rate for DP
> MST")
> 9301397a63b3 ("drm/i915: Implement Link Rate fallback on Link training
> failure")
> af2405af07d1 ("drm/fb-helper: Push down modeset lock into FB helpers")
>
> v4.4.156: Failed to apply! Possible dependencies:
> 0552f7651bc2 ("drm/i915/mst: use reference counted connectors. (v3)")
> 06bfe5b0d892 ("drm/i915: Avoid null dereference if mst_port is unset.")
> 22a2c8e0457f ("drm/i915: Validate mode against max. link data rate for DP
> MST")
> 9301397a63b3 ("drm/i915: Implement Link Rate fallback on Link training
> failure")
> af2405af07d1 ("drm/fb-helper: Push down modeset lock into FB helpers")
>
> v3.18.122: Failed to apply! Possible dependencies:
> 0552f7651bc2 ("drm/i915/mst: use reference counted connectors. (v3)")
> 06bfe5b0d892 ("drm/i915: Avoid null dereference if mst_port is unset.")
> 22a2c8e0457f ("drm/i915: Validate mode against max. link data rate for DP
> MST")
> 459485ad3513 ("drm/i915: Fixup dp mst encoder selection")
> 9301397a63b3 ("drm/i915: Implement Link Rate fallback on Link training
> failure")
> af2405af07d1 ("drm/fb-helper: Push down modeset lock into FB helpers")
> c6a0aed4d493 ("drm/mst: cached EDID for logical ports (v2)")
>
>
> Please let us know how to resolve this.
...is this the email address I'm supposed to "let you know how to resolve this"
with? if that is the case, it's 100% OK to simply ignore all of the versions
that don't apply with this patch.
>
> --
> Thanks,
> Sasha
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [virtio-dev] [PATCH 2/2] drm/virtio: add iommu support.
On 09/19/2018 06:38 AM, Gerd Hoffmann wrote: Once display manger is kicked off for example (sudo systemctl start lightdm.service) and resource id 3 gets created from user space down, it still gives a blank black screen. >>> >>> Hmm. I'd suspect there is simply a code path missing. Can you send the >>> patch you have? >>> >>> cheers, >>> Gerd >>> >> >> I sent the patch. For now it does dma_sync_sg on the pages in >> TRANSFER_TO_HOST_2D/3D when use_dma_api is true. >> >> https://lore.kernel.org/lkml/20180919070931.91168-1-jiandi...@amd.com/ > > Hmm, the way it is hooked up it should not miss any resource update. > So not sure why it isn't working. > Pushed the patch nevertheless as it is clearly a step into the right > direction. > > cheers, > Gerd > I did more tracing and digging. The ttm-pages that needs to be dma_synced are inside virtio_gpu_object. There are 4 VIRTIO_GPU_CMD_RESOURCE_CREATE_2D/_ATTACH_BACKING coming down the driver creating virtio_gpu_objects with resource_id = 1, 2, 3, 4 respectively. resource_id = 1 is created during driver load in the path of virtio_gpu_probe() virtio_gpu_fbdev_init() virtio_gpufb_create() In this path virtio_gpu_framebuffer_init() is called where it ties virtio_gpu_object -> drm_gem_object into virtio_gpu_framebuffer -> drm_framebuffer -> drm_gem_object obj[0] So later with given drm_gem_object, gem_to_virtio_gpu_obj() can get to the virtio_gpu_object that contains it. When kicking off display manager such as lightdm resource_id = 2, 3, and 4 are created in the drm_mode_create_dumb ioctl path drm_mode_create_dumb() drm_ioctl() drm_mode_create_dumb_ioctl() virtio_gpu_mode_dumb_create() In this path a different virtio_gpu_object is created for each resource_id. The virtio_gpu_object or the underlying drm_gem_object is not tied to virtio_gpu_framebuffer. It is published to userspace through drm_file which registers the gem_handle for the drm_gem_object. After display manger is kicked off, the VIRTIO_GPU_CMD_TRANSFER_TO_HOST_2D command is acting on the virtio_gpu_object resource created for resource_id = 3. In virtio_gpu_cmd_transfer_to_host(), it only has access to struct virtio_gpu_device, so the virtio_gpu_object it accesses through virtio_gpu_device is resource_id = 1's virtio_gpu_object. void virtio_gpu_cmd_transfer_to_host_2d(struct virtio_gpu_device *vgdev, uint32_t resource_id, uint64_t offset, ... struct virtio_gpu_fbdev *vgfbdev = vgdev->vgfbdev; struct virtio_gpu_framebuffer *fb = &vgfbdev->vgfb; struct virtio_gpu_object *obj = gem_to_virtio_gpu_obj(fb->base.obj[0]); In struct drm_framebuffer, there is struct drm_gem_object *obj[4], only first element is being used here. Can the virtio_gpu_object created from user space for resource_id 3 be saved here to tie it to virtio_gpu_framebuffer? Is there better way to get to the virtio_gpu_object created in the virtio_gpu_mode_dumb_create() path from virtio_gpu_device or somehow from drm_file via gem_handle down at the layer of virtio_gpu_cmd_transfer_to_host()? Thanks - Jiandi ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102962] GPU crash running Overwatch in wine-staging
https://bugs.freedesktop.org/show_bug.cgi?id=102962 --- Comment #16 from Simon --- I have the same issue - I am running ArchLabs with arch repos, recent drivers, lutris installer of Overwatch. When firing D.Vas rockets or certain other sparkly effects, the gpu hangs. This is dmesg of when it happens: https://pastebin.com/VBtc5nxE My specs are CPU: A8 2.3ghz quadcore RAM: 8GB Video: Radeon R5 M240 with 1gb "dedicated VRAM" AKA southern island "Mullins" GCN1.0 I am currently using the radeon driver, which works fine (actually very well - I have vdpau and most other relevant packages installed, and glxinfo tells me I have OpenGL core profile 4.5 working). I cant get amdgpu or vulkan to work sadly, so this issue makes overwatch unplayable. I use the stock ARCH kernel 4.18 -- 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 v2 0/6] Fix legacy DPMS changes with MST
There's two major things this patchset does: - Add drm_dp_mst_connector_atomic_check() so drivers don't need to use ->best_encoder() to prevent modesets on zombie MST connectors. We'll use this later for implementing MST fallback retraining as well. - Fix DPMS on->off changes failing with legacy modesetting users after an MST connector's topology has disappeared, which resulted in CRTCs being left on when they shouldn't have been Lyude Paul (6): drm/dp_mst: Introduce drm_dp_mst_connector_atomic_check() drm/nouveau: Unbreak nv50_mstc->best_encoder() drm/i915: Leave intel_conn->mst_port set, use mst_port_gone instead drm/i915: Skip vcpi allocation for MSTB ports that are gone drm/i915: Fix intel_dp_mst_best_encoder() drm/amdgpu/dm/mst: Use drm_dp_mst_connector_atomic_check() .../display/amdgpu_dm/amdgpu_dm_mst_types.c | 12 +++ drivers/gpu/drm/drm_dp_mst_topology.c | 76 +++ drivers/gpu/drm/i915/intel_dp_mst.c | 46 ++- drivers/gpu/drm/i915/intel_drv.h | 1 + drivers/gpu/drm/nouveau/dispnv50/disp.c | 25 +++--- include/drm/drm_dp_mst_helper.h | 3 + 6 files changed, 132 insertions(+), 31 deletions(-) -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/6] drm/dp_mst: Introduce drm_dp_mst_connector_atomic_check()
Currently the way that we prevent userspace from performing new modesets
on MST connectors that have just been destroyed is rather broken.
There's nothing in the actual DRM DP MST topology helpers that checks
whether or not a connector still exists, instead each DRM driver does
this on it's own, usually by returning NULL from the best_encoder
callback which in turn, causes the atomic commit to fail.
However, this is wrong in a rather subtle way. If ->best_encoder()
returns NULL, this makes ALL modesets involving the connector fail. This
includes modesets from userspace that would shut off the CRTCs being
used by the connector. Since this results in blocking any changes to a
connector's DPMS prop, it has the sideaffect of preventing legacy
modesetting users from ever disabling a CRTC that was previously enabled
for use in an MST topology. An example of this, where X tries to
change the DPMS property of an MST connector that was just detached from
the system:
[ 2908.320131] [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]]
[CONNECTOR:82:DP-6]
[ 2908.320148] [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]]
[CONNECTOR:82:DP-6] status updated from connected to disconnected
[ 2908.320166] [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]]
[CONNECTOR:82:DP-6] disconnected
[ 2908.320193] [drm:drm_mode_object_put.part.2 [drm]] OBJ ID: 111 (1)
[ 2908.320230] [drm:drm_sysfs_hotplug_event [drm]] generating hotplug event
...
[ 2908.638539] [drm:drm_ioctl [drm]] pid=12928, dev=0xe201, auth=1,
DRM_IOCTL_MODE_SETPROPERTY
[ 2908.638546] [drm:drm_atomic_state_init [drm]] Allocated atomic state
7155ba49
[ 2908.638553] [drm:drm_mode_object_get [drm]] OBJ ID: 114 (1)
[ 2908.638560] [drm:drm_mode_object_get [drm]] OBJ ID: 108 (1)
[ 2908.638568] [drm:drm_atomic_get_crtc_state [drm]] Added [CRTC:41:head-0]
97a6396e state to 7155ba49
[ 2908.638575] [drm:drm_atomic_add_affected_connectors [drm]] Adding all
current connectors for [CRTC:41:head-0] to 7155ba49
[ 2908.638582] [drm:drm_mode_object_get [drm]] OBJ ID: 82 (3)
[ 2908.638589] [drm:drm_mode_object_get [drm]] OBJ ID: 82 (4)
[ 2908.638596] [drm:drm_atomic_get_connector_state [drm]] Added
[CONNECTOR:82:DP-6] 87427144 state to 7155ba49
[ 2908.638603] [drm:drm_atomic_check_only [drm]] checking 7155ba49
[ 2908.638609] [drm:drm_atomic_helper_check_modeset [drm_kms_helper]]
[CRTC:41:head-0] active changed
[ 2908.638613] [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] Updating
routing for [CONNECTOR:82:DP-6]
[ 2908.638616] [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] No
suitable encoder found for [CONNECTOR:82:DP-6]
[ 2908.638623] [drm:drm_atomic_check_only [drm]] atomic driver check for
7155ba49 failed: -22
[ 2908.638630] [drm:drm_atomic_state_default_clear [drm]] Clearing atomic state
7155ba49
[ 2908.638637] [drm:drm_mode_object_put.part.2 [drm]] OBJ ID: 82 (4)
[ 2908.638643] [drm:drm_mode_object_put.part.2 [drm]] OBJ ID: 82 (3)
[ 2908.638650] [drm:drm_mode_object_put.part.2 [drm]] OBJ ID: 114 (2)
[ 2908.638656] [drm:drm_mode_object_put.part.2 [drm]] OBJ ID: 108 (2)
[ 2908.638663] [drm:__drm_atomic_state_free [drm]] Freeing atomic state
7155ba49
[ 2908.638669] [drm:drm_mode_object_put.part.2 [drm]] OBJ ID: 82 (2)
[ 2908.638676] [drm:drm_ioctl [drm]] pid=12928, ret = -22
While this doesn't usually result in any errors that would be obvious to
the user, it does result in us leaving display resources on. This in
turn leads to unwanted sideaffects like inactive GPUs being left on
(usually from the resulting leaked runtime PM ref).
So, provide an easier way of doing this that doesn't require breaking
->best_encoder(): add a common drm_dp_mst_connector_atomic_check()
function that DRM drivers can call in order to have CRTC enabling
commits fail automatically if the MST port driving the connector no
longer exists. We'll also be able to expand upon this later as well once
we add MST fallback retraining support.
Changes since v1:
- Use list_for_each_entry_safe in drm_dp_mst_connector_still_exists() -
Julia Lawall
Signed-off-by: Lyude Paul
Cc: Julia Lawall
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/drm_dp_mst_topology.c | 76 +++
include/drm/drm_dp_mst_helper.h | 3 ++
2 files changed, 79 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 7780567aa669..58b9554711c7 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -3129,6 +3129,82 @@ static const struct drm_private_state_funcs
mst_state_funcs = {
.atomic_destroy_state = drm_dp_mst_destroy_state,
};
+static bool
+drm_dp_mst_connector_still_exists(struct drm_connector *connector,
+ struct drm_dp_mst_topology_mgr *mgr,
+ struct drm_dp_mst_branch *mstb)
+{
+ struct
[PATCH v2 2/6] drm/nouveau: Unbreak nv50_mstc->best_encoder()
As mentioned in the previous commit, we currently prevent new modesets
on recently-removed MST connectors by returning no encoder from our
->best_encoder() callback once the MST port has disappeared. This is
wrong however, because it prevents legacy modesetting users from being
able to disable CRTCs on MST connectors after the connector's respective
topology has disappeared.
So, fix this by instead using the new
drm_dp_mst_connector_atomic_check() helper instead while always
returning a valid encoder from ->best_encoder().
Signed-off-by: Lyude Paul
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 25 +++--
1 file changed, 15 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 9da0bdfe1e1c..8d6f6ee9bc75 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -881,22 +881,16 @@ nv50_mstc_atomic_best_encoder(struct drm_connector
*connector,
{
struct nv50_head *head = nv50_head(connector_state->crtc);
struct nv50_mstc *mstc = nv50_mstc(connector);
- if (mstc->port) {
- struct nv50_mstm *mstm = mstc->mstm;
- return &mstm->msto[head->base.index]->encoder;
- }
- return NULL;
+
+ return &mstc->mstm->msto[head->base.index]->encoder;
}
static struct drm_encoder *
nv50_mstc_best_encoder(struct drm_connector *connector)
{
struct nv50_mstc *mstc = nv50_mstc(connector);
- if (mstc->port) {
- struct nv50_mstm *mstm = mstc->mstm;
- return &mstm->msto[0]->encoder;
- }
- return NULL;
+
+ return &mstc->mstm->msto[0]->encoder;
}
static enum drm_mode_status
@@ -926,10 +920,21 @@ nv50_mstc_get_modes(struct drm_connector *connector)
return ret;
}
+static int
+nv50_mstc_atomic_check(struct drm_connector *connector,
+ struct drm_connector_state *state)
+{
+ struct nv50_mstc *mstc = nv50_mstc(connector);
+
+ return drm_dp_mst_connector_atomic_check(connector, state,
+&mstc->mstm->mgr);
+}
+
static const struct drm_connector_helper_funcs
nv50_mstc_help = {
.get_modes = nv50_mstc_get_modes,
.mode_valid = nv50_mstc_mode_valid,
+ .atomic_check = nv50_mstc_atomic_check,
.best_encoder = nv50_mstc_best_encoder,
.atomic_best_encoder = nv50_mstc_atomic_best_encoder,
};
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/6] drm/i915: Leave intel_conn->mst_port set, use mst_port_gone instead
Currently we set intel_connector->mst_port to NULL to signify that the
MST port has been removed from the system so that we can prevent further
action on the port such as connector probes, mode probing, etc.
However, we're going to need access to intel_connector->mst_port in
order to fixup ->best_encoder() so that it can always return the correct
encoder for an MST port to prevent legacy DPMS prop changes from
failing. This should be safe, so instead keep intel_connector->mst_port
always set and instead add intel_connector->mst_port_gone in order to
signify whether or not the connector has disappeared from the system.
Signed-off-by: Lyude Paul
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/i915/intel_dp_mst.c | 14 +++---
drivers/gpu/drm/i915/intel_drv.h| 1 +
2 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
b/drivers/gpu/drm/i915/intel_dp_mst.c
index 4ecd65375603..fcb9b87b9339 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -311,9 +311,8 @@ static int intel_dp_mst_get_ddc_modes(struct drm_connector
*connector)
struct edid *edid;
int ret;
- if (!intel_dp) {
+ if (intel_connector->mst_port_gone)
return intel_connector_update_modes(connector, NULL);
- }
edid = drm_dp_mst_get_edid(connector, &intel_dp->mst_mgr,
intel_connector->port);
ret = intel_connector_update_modes(connector, edid);
@@ -328,9 +327,10 @@ intel_dp_mst_detect(struct drm_connector *connector, bool
force)
struct intel_connector *intel_connector = to_intel_connector(connector);
struct intel_dp *intel_dp = intel_connector->mst_port;
- if (!intel_dp)
+ if (intel_connector->mst_port_gone)
return connector_status_disconnected;
- return drm_dp_mst_detect_port(connector, &intel_dp->mst_mgr,
intel_connector->port);
+ return drm_dp_mst_detect_port(connector, &intel_dp->mst_mgr,
+ intel_connector->port);
}
static void
@@ -370,7 +370,7 @@ intel_dp_mst_mode_valid(struct drm_connector *connector,
int bpp = 24; /* MST uses fixed bpp */
int max_rate, mode_rate, max_lanes, max_link_clock;
- if (!intel_dp)
+ if (intel_connector->mst_port_gone)
return MODE_ERROR;
if (mode->flags & DRM_MODE_FLAG_DBLSCAN)
@@ -402,7 +402,7 @@ static struct drm_encoder
*intel_mst_atomic_best_encoder(struct drm_connector *c
struct intel_dp *intel_dp = intel_connector->mst_port;
struct intel_crtc *crtc = to_intel_crtc(state->crtc);
- if (!intel_dp)
+ if (intel_connector->mst_port_gone)
return NULL;
return &intel_dp->mst_encoders[crtc->pipe]->base.base;
}
@@ -514,7 +514,7 @@ static void intel_dp_destroy_mst_connector(struct
drm_dp_mst_topology_mgr *mgr,
connector);
/* prevent race with the check in ->detect */
drm_modeset_lock(&connector->dev->mode_config.connection_mutex, NULL);
- intel_connector->mst_port = NULL;
+ intel_connector->mst_port_gone = true;
drm_modeset_unlock(&connector->dev->mode_config.connection_mutex);
drm_connector_put(connector);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 8fc61e96754f..87ce772ae7f8 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -409,6 +409,7 @@ struct intel_connector {
void *port; /* store this opaque as its illegal to dereference it */
struct intel_dp *mst_port;
+ bool mst_port_gone;
/* Work struct to schedule a uevent on link train failure */
struct work_struct modeset_retry_work;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 4/6] drm/i915: Skip vcpi allocation for MSTB ports that are gone
Since we need to be able to allow DPMS on->off prop changes after an MST
port has disappeared from the system, we need to be able to make sure we
can compute a config for the resulting atomic commit. Currently this is
impossible when the port has disappeared, since the VCPI slot searching
we try to do in intel_dp_mst_compute_config() will fail with -EINVAL.
Since the only commits we want to allow on no-longer-present MST ports
are ones that shut off display hardware, we already know that no VCPI
allocations are needed. So, hardcode the VCPI slot count to 0 when
intel_dp_mst_compute_config() is called on an MST port that's gone.
Signed-off-by: Lyude Paul
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/i915/intel_dp_mst.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
b/drivers/gpu/drm/i915/intel_dp_mst.c
index fcb9b87b9339..a366f32b048a 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -42,7 +42,7 @@ static bool intel_dp_mst_compute_config(struct intel_encoder
*encoder,
to_intel_connector(conn_state->connector);
struct drm_atomic_state *state = pipe_config->base.state;
int bpp;
- int lane_count, slots;
+ int lane_count, slots = 0;
const struct drm_display_mode *adjusted_mode =
&pipe_config->base.adjusted_mode;
int mst_pbn;
bool reduce_m_n = drm_dp_has_quirk(&intel_dp->desc,
@@ -76,11 +76,16 @@ static bool intel_dp_mst_compute_config(struct
intel_encoder *encoder,
mst_pbn = drm_dp_calc_pbn_mode(adjusted_mode->crtc_clock, bpp);
pipe_config->pbn = mst_pbn;
- slots = drm_dp_atomic_find_vcpi_slots(state, &intel_dp->mst_mgr,
- connector->port, mst_pbn);
- if (slots < 0) {
- DRM_DEBUG_KMS("failed finding vcpi slots:%d\n", slots);
- return false;
+ if (!connector->mst_port_gone) {
+ slots = drm_dp_atomic_find_vcpi_slots(state,
+ &intel_dp->mst_mgr,
+ connector->port,
+ mst_pbn);
+ if (slots < 0) {
+ DRM_DEBUG_KMS("failed finding vcpi slots:%d\n",
+ slots);
+ return false;
+ }
}
intel_link_compute_m_n(bpp, lane_count,
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 5/6] drm/i915: Fix intel_dp_mst_best_encoder()
Currently, i915 appears to rely on blocking modesets on
no-longer-present MSTB ports by simply returning NULL for
->best_encoder(), which in turn causes any new atomic commits that don't
disable the CRTC to fail. This is wrong however, since we still want to
allow userspace to disable CRTCs on no-longer-present MSTB ports by
changing the DPMS state to off and this still requires that we retrieve
an encoder.
So, fix this by always returning a valid encoder regardless of the state
of the MST port. Additionally, make intel_dp_mst_atomic_check() simply
rely on drm_dp_mst_connector_atomic_check() to prevent new modesets on
no-longer-present MSTB ports.
Signed-off-by: Lyude Paul
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/i915/intel_dp_mst.c | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
b/drivers/gpu/drm/i915/intel_dp_mst.c
index a366f32b048a..2b798d4592f0 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -106,14 +106,21 @@ static bool intel_dp_mst_compute_config(struct
intel_encoder *encoder,
}
static int intel_dp_mst_atomic_check(struct drm_connector *connector,
- struct drm_connector_state *new_conn_state)
+struct drm_connector_state *new_conn_state)
{
struct drm_atomic_state *state = new_conn_state->state;
struct drm_connector_state *old_conn_state;
struct drm_crtc *old_crtc;
struct drm_crtc_state *crtc_state;
+ struct drm_dp_mst_topology_mgr *mgr =
+ &to_intel_connector(connector)->mst_port->mst_mgr;
int slots, ret = 0;
+ ret = drm_dp_mst_connector_atomic_check(connector, new_conn_state,
+ mgr);
+ if (ret)
+ return ret;
+
old_conn_state = drm_atomic_get_old_connector_state(state, connector);
old_crtc = old_conn_state->crtc;
if (!old_crtc)
@@ -122,12 +129,6 @@ static int intel_dp_mst_atomic_check(struct drm_connector
*connector,
crtc_state = drm_atomic_get_new_crtc_state(state, old_crtc);
slots = to_intel_crtc_state(crtc_state)->dp_m_n.tu;
if (drm_atomic_crtc_needs_modeset(crtc_state) && slots > 0) {
- struct drm_dp_mst_topology_mgr *mgr;
- struct drm_encoder *old_encoder;
-
- old_encoder = old_conn_state->best_encoder;
- mgr = &enc_to_mst(old_encoder)->primary->dp.mst_mgr;
-
ret = drm_dp_atomic_release_vcpi_slots(state, mgr, slots);
if (ret)
DRM_DEBUG_KMS("failed releasing %d vcpi slots:%d\n",
slots, ret);
@@ -407,8 +408,6 @@ static struct drm_encoder
*intel_mst_atomic_best_encoder(struct drm_connector *c
struct intel_dp *intel_dp = intel_connector->mst_port;
struct intel_crtc *crtc = to_intel_crtc(state->crtc);
- if (intel_connector->mst_port_gone)
- return NULL;
return &intel_dp->mst_encoders[crtc->pipe]->base.base;
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 6/6] drm/amdgpu/dm/mst: Use drm_dp_mst_connector_atomic_check()
Hook this into amdgpu's atomic check for their connectors so they never
get modesets on no-longer-present MST connectors. We'll also expand on
this later once we add DP MST fallback retraining support.
As well, turns out that the only atomic DRM driver without the
->best_encoder() bug is amdgpu. Congrats AMD!
Signed-off-by: Lyude Paul
---
.../drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 9a300732ba37..d011a39f17b2 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -294,10 +294,22 @@ static struct drm_encoder *dm_mst_best_encoder(struct
drm_connector *connector)
return &amdgpu_dm_connector->mst_encoder->base;
}
+static int
+amdgpu_dm_mst_connector_atomic_check(struct drm_connector *connector,
+struct drm_connector_state *new_cstate)
+{
+ struct amdgpu_dm_connector *aconnector =
+ to_amdgpu_dm_connector(connector);
+
+ return drm_dp_mst_connector_atomic_check(connector, new_cstate,
+&aconnector->mst_mgr);
+}
+
static const struct drm_connector_helper_funcs
dm_dp_mst_connector_helper_funcs = {
.get_modes = dm_dp_mst_get_modes,
.mode_valid = amdgpu_dm_connector_mode_valid,
.best_encoder = dm_mst_best_encoder,
+ .atomic_check = amdgpu_dm_mst_connector_atomic_check,
};
static void amdgpu_dm_encoder_destroy(struct drm_encoder *encoder)
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107990] Got Dying Light working in Arch by changing Mesa's compile steps, how to get it working Out Of the Box?
https://bugs.freedesktop.org/show_bug.cgi?id=107990 --- Comment #1 from John --- I had someone else try this, and it worked for him as well with a 580. -- 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
On Wed, Sep 19, 2018 at 03:47:48PM +0800, Chih-Wei Huang wrote:
> 2018-09-14 2:23 GMT+08:00 Lucas De Marchi :
> > +Chris
> >>
> >> 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?
>
> Hmm... There is no private declaration in this header.
???
> Why is it private?
All headers are private unless they are exported/installed. Android does
things a little differently by incorporating libdrm inside this drm_gralloc.
>
> If so, what is the correct way to get the gen of Intel's GPU?
> Or the userspace should not know it?
libdrm *is* userspace. Better question: why do you need to know the gen? Can
this be decided in another way by using a properly exported function from
libdrm?
If you only want to hack it to work again, just link with the static library
since you are already incorporating the library, as Chris suggested. If you
want to do it right you may need to look into your library to see why it
is doing that.
Lucas De Marchi
>
>
> --
> Chih-Wei
> Android-x86 project
> http://www.android-x86.org
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v9 1/2] drm: Add connector property to limit max bpc
At times 12bpc HDMI cannot be driven due to faulty cables, dongles
level shifters etc. To workaround them we may need to drive the output
at a lower bpc. Currently the user space does not have a way to limit
the bpc. The default bpc to be programmed is decided by the driver and
is run against connector limitations.
Creating a new connector property "max bpc" in order to limit the bpc.
xrandr can make use of this connector property to make sure that bpc does
not exceed the configured value. This property can be used by userspace to
set the bpc.
V2: Initialize max_bpc to satisfy kms_properties
V3: Move the property to drm_connector
V4: Split drm and i915 components(Ville)
V5: Make the property per connector(Ville)
V6: Compare the requested bpc to connector bpc(Daniel)
Move the attach_property function to core(Ville)
V7: Fix checkpatch warnings
V8: Simplify the connector check code(Ville)
V9: Const display_info(Ville)
Cc: Ville Syrjälä
Cc: Daniel Vetter
Cc: Kishore Kadiyala
Cc: Rodrigo Vivi
Cc: Manasi Navare
Cc: Stanislav Lisovskiy
Reviewed-by: Ville Syrjälä
Signed-off-by: Radhakrishna Sripada
---
drivers/gpu/drm/drm_atomic.c| 5 +
drivers/gpu/drm/drm_atomic_helper.c | 4
drivers/gpu/drm/drm_atomic_uapi.c | 4
drivers/gpu/drm/drm_connector.c | 33 +
include/drm/drm_connector.h | 20
5 files changed, 66 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 2870ae205237..dffac8738a4d 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -390,6 +390,7 @@ static int drm_atomic_connector_check(struct drm_connector
*connector,
{
struct drm_crtc_state *crtc_state;
struct drm_writeback_job *writeback_job = state->writeback_job;
+ const struct drm_display_info *info = &connector->display_info;
if ((connector->connector_type != DRM_MODE_CONNECTOR_WRITEBACK) ||
!writeback_job)
return 0;
@@ -417,6 +418,10 @@ static int drm_atomic_connector_check(struct drm_connector
*connector,
return -EINVAL;
}
+ state->max_bpc = info->bpc ?: 8;
+ if (connector->max_bpc_property)
+ state->max_bpc = min(state->max_bpc, state->max_requested_bpc);
+
return 0;
}
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 3cf1aa132778..d9ce8077fb6a 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -639,6 +639,10 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
if (old_connector_state->link_status !=
new_connector_state->link_status)
new_crtc_state->connectors_changed = true;
+
+ if (old_connector_state->max_requested_bpc !=
+ new_connector_state->max_requested_bpc)
+ new_crtc_state->connectors_changed = true;
}
if (funcs->atomic_check)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index d5b7f315098c..86ac33922b09 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -740,6 +740,8 @@ static int drm_atomic_connector_set_property(struct
drm_connector *connector,
return set_out_fence_for_connector(state->state, connector,
fence_ptr);
+ } else if (property == connector->max_bpc_property) {
+ state->max_requested_bpc = val;
} else if (connector->funcs->atomic_set_property) {
return connector->funcs->atomic_set_property(connector,
state, property, val);
@@ -804,6 +806,8 @@ drm_atomic_connector_get_property(struct drm_connector
*connector,
*val = 0;
} else if (property == config->writeback_out_fence_ptr_property) {
*val = 0;
+ } else if (property == connector->max_bpc_property) {
+ *val = state->max_requested_bpc;
} else if (connector->funcs->atomic_get_property) {
return connector->funcs->atomic_get_property(connector,
state, property, val);
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 1e40e5decbe9..65e22c1b37a5 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1583,6 +1583,39 @@ void drm_connector_set_link_status_property(struct
drm_connector *connector,
EXPORT_SYMBOL(drm_connector_set_link_status_property);
/**
+ * drm_connector_attach_max_bpc_property - attach "max bpc" property
+ * @connector: connector to attach max bpc property on.
+ * @min: The minimum bit depth supported by the connector.
+ * @max: The maximum bit depth supported by the connector.
+ *
+ * This is used
[PATCH v9 2/2] drm/i915: Allow "max bpc" property to limit pipe_bpp
Use the newly added "max bpc" connector property to limit pipe bpp.
V3: Use drm_connector_state to access the "max bpc" property
V4: Initialize the drm property, add suuport to DP(Ville)
V5: Use the property in the connector and fix CI failure(Ville)
V6: Use the core function to attach max_bpc property, remove the redundant
clamping of pipe bpp based on connector info
V7: Fix Checkpatch warnings
V9: Cleanup connected_sink_max_bpp and fix initial value in DP(Ville)
Cc: Ville Syrjälä
Cc: Daniel Vetter
Cc: Rodrigo Vivi
Cc: Kishore Kadiyala
Cc: Manasi Navare
Cc: Stanislav Lisovskiy
Signed-off-by: Radhakrishna Sripada
---
drivers/gpu/drm/i915/intel_display.c | 48 +---
drivers/gpu/drm/i915/intel_dp.c | 4 +++
drivers/gpu/drm/i915/intel_hdmi.c| 5
3 files changed, 37 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index fbcc56caffb6..bc1e9599456d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -10842,30 +10842,38 @@ static void
intel_modeset_update_connector_atomic_state(struct drm_device *dev)
drm_connector_list_iter_end(&conn_iter);
}
-static void
-connected_sink_compute_bpp(struct intel_connector *connector,
- struct intel_crtc_state *pipe_config)
+static int
+connected_sink_max_bpp(const struct drm_connector_state *conn_state,
+ struct intel_crtc_state *pipe_config)
{
- const struct drm_display_info *info = &connector->base.display_info;
- int bpp = pipe_config->pipe_bpp;
+ int bpp;
+ struct drm_display_info *info = &conn_state->connector->display_info;
- DRM_DEBUG_KMS("[CONNECTOR:%d:%s] checking for sink bpp constrains\n",
- connector->base.base.id,
- connector->base.name);
+ bpp = min(pipe_config->pipe_bpp, conn_state->max_bpc * 3);
- /* Don't use an invalid EDID bpc value */
- if (info->bpc != 0 && info->bpc * 3 < bpp) {
- DRM_DEBUG_KMS("clamping display bpp (was %d) to EDID reported
max of %d\n",
- bpp, info->bpc * 3);
- pipe_config->pipe_bpp = info->bpc * 3;
+ switch (conn_state->max_bpc) {
+ case 6 ... 7:
+ pipe_config->pipe_bpp = 6 * 3;
+ case 8 ... 9:
+ pipe_config->pipe_bpp = 8 * 3;
+ break;
+ case 10 ... 11:
+ pipe_config->pipe_bpp = 10 * 3;
+ break;
+ case 12:
+ pipe_config->pipe_bpp = 12 * 3;
+ break;
+ default:
+ return -EINVAL;
}
- /* Clamp bpp to 8 on screens without EDID 1.4 */
- if (info->bpc == 0 && bpp > 24) {
- DRM_DEBUG_KMS("clamping display bpp (was %d) to default limit
of 24\n",
- bpp);
- pipe_config->pipe_bpp = 24;
+ if (bpp != pipe_config->pipe_bpp) {
+ DRM_DEBUG_KMS("Limiting display bpp to %d instead of requested "
+ "bpp %d, Edid bpp %d\n", bpp, 3 * info->bpc,
+ 3 * conn_state->max_requested_bpc);
+ pipe_config->pipe_bpp = bpp;
}
+ return 0;
}
static int
@@ -10896,8 +10904,8 @@ compute_baseline_pipe_bpp(struct intel_crtc *crtc,
if (connector_state->crtc != &crtc->base)
continue;
- connected_sink_compute_bpp(to_intel_connector(connector),
- pipe_config);
+ if (connected_sink_max_bpp(connector_state, pipe_config) < 0)
+ return -EINVAL;
}
return bpp;
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 6b4c19123f2a..d8e128e771a1 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -5719,6 +5719,10 @@ intel_dp_add_properties(struct intel_dp *intel_dp,
struct drm_connector *connect
intel_attach_force_audio_property(connector);
intel_attach_broadcast_rgb_property(connector);
+ if (HAS_GMCH_DISPLAY(dev_priv))
+ drm_connector_attach_max_bpc_property(connector, 6, 10);
+ else if (INTEL_GEN(dev_priv) >= 5)
+ drm_connector_attach_max_bpc_property(connector, 6, 12);
if (intel_dp_is_edp(intel_dp)) {
u32 allowed_scalers;
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index a2dab0b6bde6..2b432c7e4f8a 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -2109,11 +2109,16 @@ static const struct drm_encoder_funcs
intel_hdmi_enc_funcs = {
static void
intel_hdmi_add_properties(struct intel_hdmi *intel_hdmi, struct drm_connector
*connector)
{
+ struct drm_i915_private *dev_priv = to_i915(connector->dev
[PATCH libdrm v2] CONTRIBUTING: clarify how to request a Developer role
While requesting a Developer role I was pointed to this url and check
those with "owner" role. So add it to our documentation.
v2: rollback previous text, but add a link to gitlab's page
showing project members.
Signed-off-by: Lucas De Marchi
---
CONTRIBUTING | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/CONTRIBUTING b/CONTRIBUTING
index 96f1e4fb..5d38e5e9 100644
--- a/CONTRIBUTING
+++ b/CONTRIBUTING
@@ -80,7 +80,9 @@ below criteria:
To apply for commit rights ("Developer" role in gitlab) send a mail to
dri-devel@lists.freedesktop.org and please ping the maintainers if your request
-is stuck.
+is stuck: any member with "owner" role in
+https://gitlab.freedesktop.org/mesa/drm/project_members?sort=access_level_desc
+can give you access.
Committers are encouraged to request their commit rights get removed when they
no longer contribute to the project. Commit rights will be reinstated when they
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102322] System crashes after "[drm] IP block:gmc_v8_0 is hung!" / [drm] IP block:sdma_v3_0 is hung!
https://bugs.freedesktop.org/show_bug.cgi?id=102322 --- Comment #64 from Anthony Ruhier --- (In reply to Anthony Ruhier from comment #63) > FYI, I also had this bug under linux 4.17 and 4.18, but it seems to have > been fixed in 4.19-rc3. The suspend/hibernate issue has also been fixed. Forgot to say that I have a vega 64. -- 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
