[LKP] [drm/atomic] 79ef5c1b82: general_protection_fault:#[##]
FYI, we noticed the following commit (built with gcc-6):
commit: 79ef5c1b820e59bcc240e133cd9df59b2b20415f ("[PATCH] drm/atomic: Use
drm_drv_uses_atomic_modeset() for debugfs creation")
url:
https://github.com/0day-ci/linux/commits/Lyude-Paul/drm-atomic-Use-drm_drv_uses_atomic_modeset-for-debugfs-creation/20180918-020244
in testcase: boot
on test machine: qemu-system-x86_64 -enable-kvm -cpu qemu64,+ssse3 -smp 4 -m 8G
caused below changes (please refer to attached dmesg/kmsg for entire
log/backtrace):
+--+++
|
| ad3273d5f1 | 79ef5c1b82 |
+--+++
| boot_successes
| 6 | 0 |
| boot_failures
| 2 | 6 |
|
BUG:kernel_hang_in_early-boot_stage,last_printk:Probing_EDD(edd=off_to_disable)...ok
| 2 | 2 |
| general_protection_fault:#[##]
| 0 | 4 |
| RIP:drm_debugfs_init
| 0 | 4 |
| Kernel_panic-not_syncing:Fatal_exception
| 0 | 4 |
+--+++
[ 185.861767] [drm] Driver supports precise vblank timestamp query.
[ 185.866054] [drm] Initialized vkms 1.0.0 20180514 for virtual device on
minor 0
[ 185.870315] usbcore: registered new interface driver udl
[ 185.872276] kasan: CONFIG_KASAN_INLINE enabled
[ 185.873048] kasan: GPF could be caused by NULL-ptr deref or user memory
access
[ 185.874526] general protection fault: [#1] SMP KASAN PTI
[ 185.875263] CPU: 1 PID: 1 Comm: swapper/0 Not tainted
4.19.0-rc4-00023-g79ef5c1 #1
[ 185.875263] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.10.2-1 04/01/2014
[ 185.875263] RIP: 0010:drm_debugfs_init+0x2fd/0x510
[ 185.875263] Code: 48 c1 e9 03 80 3c 11 00 0f 85 10 02 00 00 49 8b 96 00 0b
00 00 48 b9 00 00 00 00 00 fc ff df 48 8d 7a 28 48 89 fe 48 c1 ee 03 <80> 3c 0e
00 0f 85 a8 01 00 00 48 83 7a 28 00 0f 85 ab fe ff ff e9
[ 185.882598] RSP: :880107f9fa90 EFLAGS: 00010206
[ 185.882598] RAX: RBX: 8801071da000 RCX: dc00
[ 185.882598] RDX: RSI: 0005 RDI: 0028
[ 185.882598] RBP: 110020ff3f54 R08: ed0020e3b407 R09: ed0020e3b406
[ 185.882598] R10: 8801071da037 R11: ed0020e3b407 R12: 86852de0
[ 185.882598] R13: R14: 8801d521d500 R15: 3000
[ 185.882598] FS: () GS:8801e9e0()
knlGS:
[ 185.882598] CS: 0010 DS: ES: CR0: 80050033
[ 185.882598] CR2: CR3: 05624000 CR4: 06e0
[ 185.882598] Call Trace:
[ 185.882598] ? __kmalloc_track_caller+0x14f/0x2e0
[ 185.882598] ? drm_debugfs_create_files+0x420/0x420
[ 185.882598] ? memcpy+0x34/0x50
[ 185.882598] ? kstrdup+0x5a/0x70
[ 185.882598] ? lock_acquired+0x3f1/0xbf0
[ 185.898672] drm_minor_register+0xa4/0x220
[ 185.898672] drm_dev_register+0x10f/0x610
[ 185.898672] drm_get_pci_dev+0x195/0x4d0
[ 185.898672] bochs_pci_probe+0x1e6/0x2f0
[ 185.898672] pci_device_probe+0x2a7/0x4b0
[ 185.898672] ? pci_device_remove+0x2c0/0x2c0
[ 185.902591] really_probe+0x4db/0x780
[ 185.902591] driver_probe_device+0xe7/0x240
[ 185.902591] __driver_attach+0x262/0x2d0
[ 185.902591] ? driver_probe_device+0x240/0x240
[ 185.902591] bus_for_each_dev+0x138/0x1d0
[ 185.902591] ? bus_remove_file+0xe0/0xe0
[ 185.902591] bus_add_driver+0x2c5/0x5e0
[ 185.902591] ? qxl_init+0x7b/0x7b
[ 185.902591] driver_register+0x1b7/0x420
[ 185.902591] bochs_init+0x33/0x3e
[ 185.902591] do_one_initcall+0x11b/0x389
[ 185.902591] ? start_kernel+0x769/0x769
[ 185.902591] ? lock_downgrade+0x660/0x660
[ 185.902591] ? do_early_param+0x124/0x124
[ 185.902591] kernel_init_freeable+0x4c1/0x579
[ 185.902591] ? rest_init+0x130/0x130
[ 185.918576] kernel_init+0x14/0x190
[ 185.918576] ? _raw_spin_unlock_irq+0x29/0x70
[ 185.918576] ? rest_init+0x130/0x130
[ 185.918576] ret_from_fork+0x24/0x30
[ 185.932602] ---[ end trace 14d3235039b65adf ]---
[ 185.934465] RIP: 0010:drm_debugfs_init+0x2fd/0x510
[ 185.936354] Code: 48 c1 e9 03 80 3c 11 00 0f 85 10 02 00 00 49 8b 96 00 0b
00 00 48 b9 00 00 00 00 00 fc ff df 48 8d 7a 28 48 89 fe 48 c1 ee 03 <80> 3c 0e
00 0f 85 a8 01 00 00 48 83 7a 28 00 0f 85 ab fe ff ff e9
[ 185.949797] RSP: :880107f9fa90
Re: [PATCH] list: introduce list_bulk_move_tail helper
On 09/17/2018 08:08 PM, Christian König wrote:
Move all entries between @first and including @last before @head.
This is useful for LRU lists where a whole block of entries should be
moved to the end of the list.
Used as a band aid in TTM, but better placed in the common list headers.
Signed-off-by: Christian König
Reviewed-by: Junwei Zhang
---
drivers/gpu/drm/ttm/ttm_bo.c | 25 +
include/linux/list.h | 23 +++
2 files changed, 28 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index b2a33bf1ef10..26b889f86670 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -247,20 +247,6 @@ void ttm_bo_move_to_lru_tail(struct ttm_buffer_object *bo,
}
EXPORT_SYMBOL(ttm_bo_move_to_lru_tail);
-static void ttm_list_move_bulk_tail(struct list_head *list,
- struct list_head *first,
- struct list_head *last)
-{
- first->prev->next = last->next;
- last->next->prev = first->prev;
-
- list->prev->next = first;
- first->prev = list->prev;
-
- last->next = list;
- list->prev = last;
-}
-
void ttm_bo_bulk_move_lru_tail(struct ttm_lru_bulk_move *bulk)
{
unsigned i;
@@ -276,8 +262,8 @@ void ttm_bo_bulk_move_lru_tail(struct ttm_lru_bulk_move
*bulk)
reservation_object_assert_held(pos->last->resv);
man = >first->bdev->man[TTM_PL_TT];
- ttm_list_move_bulk_tail(>lru[i], >first->lru,
- >last->lru);
+ list_bulk_move_tail(>lru[i], >first->lru,
+ >last->lru);
}
for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
@@ -291,8 +277,8 @@ void ttm_bo_bulk_move_lru_tail(struct ttm_lru_bulk_move
*bulk)
reservation_object_assert_held(pos->last->resv);
man = >first->bdev->man[TTM_PL_VRAM];
- ttm_list_move_bulk_tail(>lru[i], >first->lru,
- >last->lru);
+ list_bulk_move_tail(>lru[i], >first->lru,
+ >last->lru);
}
for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
@@ -306,8 +292,7 @@ void ttm_bo_bulk_move_lru_tail(struct ttm_lru_bulk_move
*bulk)
reservation_object_assert_held(pos->last->resv);
lru = >first->bdev->glob->swap_lru[i];
- ttm_list_move_bulk_tail(lru, >first->swap,
- >last->swap);
+ list_bulk_move_tail(lru, >first->swap, >last->swap);
}
}
EXPORT_SYMBOL(ttm_bo_bulk_move_lru_tail);
diff --git a/include/linux/list.h b/include/linux/list.h
index de04cc5ed536..edb7628e46ed 100644
--- a/include/linux/list.h
+++ b/include/linux/list.h
@@ -183,6 +183,29 @@ static inline void list_move_tail(struct list_head *list,
list_add_tail(list, head);
}
+/**
+ * list_bulk_move_tail - move a subsection of a list to its tail
+ * @head: the head that will follow our entry
+ * @first: first entry to move
+ * @last: last entry to move, can be the same as first
+ *
+ * Move all entries between @first and including @last before @head.
+ * All three entries must belong to the same linked list.
+ */
+static inline void list_bulk_move_tail(struct list_head *head,
+ struct list_head *first,
+ struct list_head *last)
+{
+ first->prev->next = last->next;
+ last->next->prev = first->prev;
+
+ head->prev->next = first;
+ first->prev = head->prev;
+
+ last->next = head;
+ head->prev = last;
+}
+
/**
* list_is_last - tests whether @list is the last entry in list @head
* @list: the entry to test
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 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)
Cc: Ville Syrjälä
Cc: Daniel Vetter
Cc: Kishore Kadiyala
Cc: Rodrigo Vivi
Cc: Manasi Navare
Cc: Stanislav Lisovskiy
Signed-off-by: Radhakrishna Sripada
---
drivers/gpu/drm/drm_atomic.c| 24
drivers/gpu/drm/drm_atomic_helper.c | 4
drivers/gpu/drm/drm_atomic_uapi.c | 4
drivers/gpu/drm/drm_connector.c | 34 ++
include/drm/drm_connector.h | 20
5 files changed, 86 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 7ada75919756..fa9996deb132 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;
+ struct drm_display_info *info = >display_info;
if ((connector->connector_type != DRM_MODE_CONNECTOR_WRITEBACK) ||
!writeback_job)
return 0;
@@ -400,6 +401,29 @@ static int drm_atomic_connector_check(struct drm_connector
*connector,
return -EINVAL;
}
+ if (connector->max_bpc_property) {
+ if (info->bpc != 0 && info->bpc < state->max_requested_bpc) {
+ /* Don't use an invalid EDID bpc value */
+ DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] Clamping requested"
+" display bpp (was %d) to EDID
reported"
+"max of %d\n", connector->base.id,
+connector->name,
+state->max_requested_bpc, info->bpc);
+ state->max_bpc = info->bpc;
+ } else if (info->bpc != 0) {
+ state->max_bpc = state->max_requested_bpc;
+ } else {
+ /* Clamp bpc to 8 on screens witout EDID 1.4 */
+ DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] Clamping requested"
+" display bpp (was %d) to default
limit"
+" of 24\n", connector->base.id,
+connector->name,
state->max_requested_bpc);
+ state->max_bpc = 8;
+ }
+ } else {
+ state->max_bpc = info->bpc ? info->bpc : 8;
+ }
+
if (state->crtc)
crtc_state = drm_atomic_get_existing_crtc_state(state->state,
state->crtc);
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,
[PATCH v6 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
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 | 49
drivers/gpu/drm/i915/intel_dp.c | 5
drivers/gpu/drm/i915/intel_hdmi.c| 5
3 files changed, 38 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index eb25037d7b38..219323f6b16e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -10845,29 +10845,37 @@ static void
intel_modeset_update_connector_atomic_state(struct drm_device *dev)
}
static void
-connected_sink_compute_bpp(struct intel_connector *connector,
- struct intel_crtc_state *pipe_config)
+connected_sink_max_bpp(struct drm_connector_state *conn_state,
+ struct intel_crtc_state *pipe_config)
{
- const struct drm_display_info *info = >base.display_info;
- int bpp = pipe_config->pipe_bpp;
-
- DRM_DEBUG_KMS("[CONNECTOR:%d:%s] checking for sink bpp constrains\n",
- connector->base.base.id,
- connector->base.name);
-
- /* 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;
+ if (pipe_config->pipe_bpp < conn_state->max_bpc * 3) {
+ conn_state->max_bpc = pipe_config->pipe_bpp / 3;
+ return;
}
- /* 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;
+ switch (conn_state->max_bpc) {
+ case 8:
+ case 9:
+ pipe_config->pipe_bpp = 8*3;
+ break;
+ case 10:
+ case 11:
+ pipe_config->pipe_bpp = 10*3;
+ break;
+ case 12:
+ case 13:
+ case 14:
+ case 15:
+ pipe_config->pipe_bpp = 12*3;
+ break;
+ case 16:
+ pipe_config->pipe_bpp = 16*3;
+ break;
+ default:
+ break;
}
+
+ DRM_DEBUG_KMS("Limiting display bpp to %d\n", pipe_config->pipe_bpp);
}
static int
@@ -10898,8 +10906,7 @@ compute_baseline_pipe_bpp(struct intel_crtc *crtc,
if (connector_state->crtc != >base)
continue;
- connected_sink_compute_bpp(to_intel_connector(connector),
- pipe_config);
+ connected_sink_max_bpp(connector_state, pipe_config);
}
return bpp;
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 436c22de33b6..aefca1d9e87b 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -5719,6 +5719,11 @@ 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 ((IS_G4X(dev_priv) || IS_VALLEYVIEW(dev_priv) ||
+IS_CHERRYVIEW(dev_priv)))
+ drm_connector_attach_max_bpc_property(connector, 8, 10);
+ else if (INTEL_GEN(dev_priv) >= 5)
+ drm_connector_attach_max_bpc_property(connector, 8, 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);
+
intel_attach_force_audio_property(connector);
intel_attach_broadcast_rgb_property(connector);
intel_attach_aspect_ratio_property(connector);
drm_connector_attach_content_type_property(connector);
connector->state->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
+
+ if (!HAS_GMCH_DISPLAY(dev_priv))
+
Re: [PATCH] list: introduce list_bulk_move_tail helper
On Mon, Sep 17, 2018 at 02:08:34PM +0200, Christian König wrote:
> Move all entries between @first and including @last before @head.
>
> This is useful for LRU lists where a whole block of entries should be
> moved to the end of the list.
>
> Used as a band aid in TTM, but better placed in the common list headers.
>
> Signed-off-by: Christian König
> ---
For TTM change, patch is Reviewed-by: Huang Rui
For new list_bulk_move_tail helper in hinclude/linux/list.h, may we have
your comments from LKML?
Thanks,
Ray
> drivers/gpu/drm/ttm/ttm_bo.c | 25 +
> include/linux/list.h | 23 +++
> 2 files changed, 28 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index b2a33bf1ef10..26b889f86670 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -247,20 +247,6 @@ void ttm_bo_move_to_lru_tail(struct ttm_buffer_object
> *bo,
> }
> EXPORT_SYMBOL(ttm_bo_move_to_lru_tail);
>
> -static void ttm_list_move_bulk_tail(struct list_head *list,
> - struct list_head *first,
> - struct list_head *last)
> -{
> - first->prev->next = last->next;
> - last->next->prev = first->prev;
> -
> - list->prev->next = first;
> - first->prev = list->prev;
> -
> - last->next = list;
> - list->prev = last;
> -}
> -
> void ttm_bo_bulk_move_lru_tail(struct ttm_lru_bulk_move *bulk)
> {
> unsigned i;
> @@ -276,8 +262,8 @@ void ttm_bo_bulk_move_lru_tail(struct ttm_lru_bulk_move
> *bulk)
> reservation_object_assert_held(pos->last->resv);
>
> man = >first->bdev->man[TTM_PL_TT];
> - ttm_list_move_bulk_tail(>lru[i], >first->lru,
> - >last->lru);
> + list_bulk_move_tail(>lru[i], >first->lru,
> + >last->lru);
> }
>
> for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
> @@ -291,8 +277,8 @@ void ttm_bo_bulk_move_lru_tail(struct ttm_lru_bulk_move
> *bulk)
> reservation_object_assert_held(pos->last->resv);
>
> man = >first->bdev->man[TTM_PL_VRAM];
> - ttm_list_move_bulk_tail(>lru[i], >first->lru,
> - >last->lru);
> + list_bulk_move_tail(>lru[i], >first->lru,
> + >last->lru);
> }
>
> for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
> @@ -306,8 +292,7 @@ void ttm_bo_bulk_move_lru_tail(struct ttm_lru_bulk_move
> *bulk)
> reservation_object_assert_held(pos->last->resv);
>
> lru = >first->bdev->glob->swap_lru[i];
> - ttm_list_move_bulk_tail(lru, >first->swap,
> - >last->swap);
> + list_bulk_move_tail(lru, >first->swap, >last->swap);
> }
> }
> EXPORT_SYMBOL(ttm_bo_bulk_move_lru_tail);
> diff --git a/include/linux/list.h b/include/linux/list.h
> index de04cc5ed536..edb7628e46ed 100644
> --- a/include/linux/list.h
> +++ b/include/linux/list.h
> @@ -183,6 +183,29 @@ static inline void list_move_tail(struct list_head *list,
> list_add_tail(list, head);
> }
>
> +/**
> + * list_bulk_move_tail - move a subsection of a list to its tail
> + * @head: the head that will follow our entry
> + * @first: first entry to move
> + * @last: last entry to move, can be the same as first
> + *
> + * Move all entries between @first and including @last before @head.
> + * All three entries must belong to the same linked list.
> + */
> +static inline void list_bulk_move_tail(struct list_head *head,
> +struct list_head *first,
> +struct list_head *last)
> +{
> + first->prev->next = last->next;
> + last->next->prev = first->prev;
> +
> + head->prev->next = first;
> + first->prev = head->prev;
> +
> + last->next = head;
> + head->prev = last;
> +}
> +
> /**
> * list_is_last - tests whether @list is the last entry in list @head
> * @list: the entry to test
> --
> 2.14.1
>
> ___
> 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
[Bug 105819] Window system hang due to GPU Fault
https://bugs.freedesktop.org/show_bug.cgi?id=105819 --- Comment #9 from Greg White --- Update: I swapped the card into a machine and tried it with Windows. It still crashed. I replaced the card and all is well. -- 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 106921] System lockup with Vega10 amdgpu: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout
https://bugs.freedesktop.org/show_bug.cgi?id=106921 --- Comment #5 from Greg White --- Update: I swapped the card into a machine and tried it with Windows. It still crashed. I replaced the card and all is well. -- 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 200695] Blank screen on RX 580 with amdgpu.dc=1 enabled (no displays detected)
https://bugzilla.kernel.org/show_bug.cgi?id=200695 Claude Heiland-Allen (cla...@mathr.co.uk) changed: What|Removed |Added Kernel Version|4.18.0-rc7, 4.18.5, 4.18.6, |4.17.19, 4.18.0-rc7, |4.18.7, 4.19-rc1, 4.19-rc2, |4.18.5, 4.18.6, 4.18.7, |4.19-rc3|4.18.8, 4.19-rc1, 4.19-rc2, ||4.19-rc3, 4.19-rc4 --- Comment #12 from Claude Heiland-Allen (cla...@mathr.co.uk) --- not an issue with 4.14.70 (I think it does not have amdgpu.dc as an option?) still an issue with 4.17.19 compiled with CONFIG_DRM_AMD_DC_PRE_VEGA=y still an issue with 4.18.8 still an issue with 4.19-rc4 -- 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
linux-next: manual merge of the drm-misc tree with the drm tree
Hi all,
Today's linux-next merge of the drm-misc tree got a conflict in:
drivers/gpu/drm/i915/i915_drv.c
between commit:
55ac5a1614f9 ("drm/i915: Attach the pci match data to the device upon
creation")
from the drm tree and commit:
1feb64c49d7f ("drm/i915: Clear DRIVER_ATOMIC on a per-device basis")
from the drm-misc tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/gpu/drm/i915/i915_drv.c
index 5dd7fc582e6f,61199defb470..
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@@ -1384,14 -1336,22 +1384,14 @@@ int i915_driver_load(struct pci_dev *pd
struct drm_i915_private *dev_priv;
int ret;
- /* Enable nuclear pageflip on ILK+ */
- if (!i915_modparams.nuclear_pageflip && match_info->gen < 5)
- driver.driver_features &= ~DRIVER_ATOMIC;
- ret = -ENOMEM;
- dev_priv = kzalloc(sizeof(*dev_priv), GFP_KERNEL);
- if (dev_priv)
- ret = drm_dev_init(_priv->drm, , >dev);
- if (ret) {
- DRM_DEV_ERROR(>dev, "allocation failed\n");
- goto out_free;
- }
--
- dev_priv->drm.pdev = pdev;
- dev_priv->drm.dev_private = dev_priv;
+ dev_priv = i915_driver_create(pdev, ent);
+ if (!dev_priv)
+ return -ENOMEM;
+ /* Disable nuclear pageflip by default on pre-ILK */
+ if (!i915_modparams.nuclear_pageflip && match_info->gen < 5)
+ dev_priv->drm.driver_features &= ~DRIVER_ATOMIC;
+
ret = pci_enable_device(pdev);
if (ret)
goto out_fini;
pgpMTk6OZY7SB.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RESEND 0/5] drm/mxsfb: Fix runtime PM for unpowering lcdif block
On 17.09.2018 12:16, Sean Paul wrote: > On Mon, Sep 17, 2018 at 04:42:10PM +0300, Leonard Crestez wrote: >> Adding lcdif nodes to a power domain currently doesn't work, it results >> in black/corrupted screens or hangs. While the driver does enable >> runtime pm it does not deal correctly with the block being unpowered. >> >> --- >> >> All patches in this series have review tags from a while ago and I >> tested them again on top of next-20180913. No changes since last >> version: https://lkml.org/lkml/2018/8/27/299 >> >> This series stalled so I reached out to Marek on IRC and he was >> surprised to be listed as maintainer > > Hopefully not too surprised since Marek added themself to MAINTAINERS when > adding the driver :-) There have been some confusion about the DRM development processes around the mxsfb already in the past. I guess in general it would be quite clear: Marek as maintainer of mxsfb should pick up the patches and send a pull request to the next level of maintainer, which in DRM case would be David Airlie: https://01.org/linuxgraphics/gfx-docs/maintainer-tools/repositories.html > > I suppose we should probably move this to drm-misc since it qualifies as a > "small driver" and needs a home. Looking through git history shows the last > mxsfb-specific change was back in 02/17. Everything else has been drm-wide > refactors. Thoughts? > > Marek/Leonard: Care to sign up to be listed as a reviewers? > drm-misc seems to make sense. I volunteer to be listed as reviewer or co-maintainer. I am actually maintainer for the DCU driver (another display controller IP used in NXP products). I should probably move that to drm-misc too... -- Stefan > Sean > >> and asked me to resend and add >> Daniel Vetter. >> >> Perhaps it would help to clarify that the pengutronix people should feel >> free to push patches in this area? >> >> Right now drm/imx is mostly for IPUv3 but there are other display output >> paths on imx, such as the LCDIF supported by this driver. This LCDIF >> block is included on imx8 so still quite relevant. >> >> Leonard Crestez (5): >> drm/mxsfb: Move axi clk enable/disable to crtc enable/disable >> drm/mxsfb: Fix initial corrupt frame when activating display >> drm/mxsfb: Add pm_runtime calls to pipe_enable/disable >> drm/mxsfb: Add PM_SLEEP support >> drm/mxsfb: Switch to drm_atomic_helper_commit_tail_rpm >> >> drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 53 +++--- >> drivers/gpu/drm/mxsfb/mxsfb_drv.c | 40 ++ >> 2 files changed, 74 insertions(+), 19 deletions(-) >> >> -- >> 2.17.1 >> ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 200621] Freezing with amdgpu driver
https://bugzilla.kernel.org/show_bug.cgi?id=200621 --- Comment #25 from Jon (jon...@gmail.com) --- Here are the newest: id 3dd692e5e80f6bac71c1f4caa570bd449b68a752 reason: WARNING: CPU: 12 PID: 2159 at drivers/gpu/drm/amd/amdgpu/../display/dc/dc_helper.c:254 generic_reg_wait+0xe7/0x160 [amdgpu] time: Mon 17 Sep 2018 06:04:08 PM CDT cmdline:BOOT_IMAGE=/vmlinuz-4.18.7-200.fc28.x86_64 root=/dev/mapper/fedora_localhost--live-root ro resume=/dev/mapper/fedora_localhost--live-swap rd.lvm.lv=fedora_localhost-live/root rd.lvm.lv=fedora_localhost-live/swap rcu_nocbs=0-15 rhgb quiet LANG=en_US.UTF-8 package:kernel-core-4.18.7-200.fc28 count: 1 Directory: /var/spool/abrt/oops-2018-09-17-18:04:08-1361-0 Reported: cannot be reported id 4c51aecb4e7650a9a56b3c73a8dd7a9ddde93509 reason: WARNING: CPU: 8 PID: 2159 at drivers/gpu/drm/amd/amdgpu/../display/dc/dc_helper.c:254 generic_reg_wait+0xe7/0x160 [amdgpu] time: Mon 17 Sep 2018 05:56:51 PM CDT cmdline:BOOT_IMAGE=/vmlinuz-4.18.7-200.fc28.x86_64 root=/dev/mapper/fedora_localhost--live-root ro resume=/dev/mapper/fedora_localhost--live-swap rd.lvm.lv=fedora_localhost-live/root rd.lvm.lv=fedora_localhost-live/swap rcu_nocbs=0-15 rhgb quiet LANG=en_US.UTF-8 package:kernel-core-4.18.7-200.fc28 count: 1 Directory: /var/spool/abrt/oops-2018-09-17-17:56:51-1361-0 Reported: cannot be reported id 15ec36d73808fc148bf988eefbc8e8ea1cc70b9a reason: WARNING: CPU: 9 PID: 2159 at drivers/gpu/drm/amd/amdgpu/../display/dc/dc_helper.c:254 generic_reg_wait+0xe7/0x160 [amdgpu] time: Mon 17 Sep 2018 05:34:06 PM CDT cmdline:BOOT_IMAGE=/vmlinuz-4.18.7-200.fc28.x86_64 root=/dev/mapper/fedora_localhost--live-root ro resume=/dev/mapper/fedora_localhost--live-swap rd.lvm.lv=fedora_localhost-live/root rd.lvm.lv=fedora_localhost-live/swap rcu_nocbs=0-15 rhgb quiet LANG=en_US.UTF-8 package:kernel-core-4.18.7-200.fc28 count: 1 Directory: /var/spool/abrt/oops-2018-09-17-17:34:06-1361-0 Reported: cannot be reported id 28adbc9b406911ba19bbbc1677e460b5abf334a0 reason: WARNING: CPU: 12 PID: 1567 at drivers/gpu/drm/amd/amdgpu/../display/dc/dc_helper.c:254 generic_reg_wait+0xe7/0x160 [amdgpu] time: Mon 17 Sep 2018 05:31:59 PM CDT cmdline:BOOT_IMAGE=/vmlinuz-4.18.7-200.fc28.x86_64 root=/dev/mapper/fedora_localhost--live-root ro resume=/dev/mapper/fedora_localhost--live-swap rd.lvm.lv=fedora_localhost-live/root rd.lvm.lv=fedora_localhost-live/swap rcu_nocbs=0-15 rhgb quiet LANG=en_US.UTF-8 package:kernel-core-4.18.7-200.fc28 count: 1 Directory: /var/spool/abrt/oops-2018-09-17-17:31:59-1361-0 Reported: cannot be reported id 84b320eaa9578f1b1820b7e43a3b7867a575aa04 reason: WARNING: CPU: 7 PID: 2006 at drivers/gpu/drm/amd/amdgpu/../display/dc/dc_helper.c:254 generic_reg_wait+0xe7/0x160 [amdgpu] time: Sun 16 Sep 2018 10:40:12 PM CDT cmdline:BOOT_IMAGE=/vmlinuz-4.18.5-200.fc28.x86_64 root=/dev/mapper/fedora_localhost--live-root ro resume=/dev/mapper/fedora_localhost--live-swap rd.lvm.lv=fedora_localhost-live/root rd.lvm.lv=fedora_localhost-live/swap rcu_nocbs=0-15 rhgb quiet LANG=en_US.UTF-8 package:kernel-core-4.18.5-200.fc28 count: 1 Directory: /var/spool/abrt/oops-2018-09-16-22:40:12-1453-0 Reported: cannot be reported id 575d92f3fad2408d7476bf8dae0a2935f56d5976 reason: WARNING: CPU: 14 PID: 2006 at drivers/gpu/drm/amd/amdgpu/../display/dc/dc_helper.c:254 generic_reg_wait+0xe7/0x160 [amdgpu] time: Sun 16 Sep 2018 09:22:50 PM CDT cmdline:BOOT_IMAGE=/vmlinuz-4.18.5-200.fc28.x86_64 root=/dev/mapper/fedora_localhost--live-root ro resume=/dev/mapper/fedora_localhost--live-swap rd.lvm.lv=fedora_localhost-live/root rd.lvm.lv=fedora_localhost-live/swap rcu_nocbs=0-15 rhgb quiet LANG=en_US.UTF-8 package:kernel-core-4.18.5-200.fc28 count: 1 Directory: /var/spool/abrt/oops-2018-09-16-21:22:50-1453-0 Reported: cannot be reported -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 200621] Freezing with amdgpu driver
https://bugzilla.kernel.org/show_bug.cgi?id=200621 --- Comment #24 from Jon (jon...@gmail.com) --- Had another crash again today. Here's some output from abrt-cli that I thought might be helpful. (there are dozens of theses): id 50200875b8db5b1f4a2a8e9e1b4b9cbf28370c7c reason: WARNING: CPU: 6 PID: 2075 at drivers/gpu/drm/amd/amdgpu/../display/dc/dc_helper.c:195 generic_reg_wait+0xe7/0x160 [amdgpu] time: Thu 13 Sep 2018 07:00:26 AM CDT cmdline:BOOT_IMAGE=/vmlinuz-4.17.19-200.fc28.x86_64 root=/dev/mapper/fedora_localhost--live-root ro resume=/dev/mapper/fedora_localhost--live-swap rd.lvm.lv=fedora_localhost-live/root rd.lvm.lv=fedora_localhost-live/swap rhgb quiet LANG=en_US.UTF-8 package:kernel-core-4.17.19-200.fc28 count: 1 Directory: /var/spool/abrt/oops-2018-09-13-07:00:26-1097-0 Reported: cannot be reported id d5cac2447aa27445ca04470b34624a50821d721e reason: WARNING: CPU: 7 PID: 2075 at drivers/gpu/drm/amd/amdgpu/../display/dc/dc_helper.c:195 generic_reg_wait+0xe7/0x160 [amdgpu] time: Wed 12 Sep 2018 09:06:20 PM CDT cmdline:BOOT_IMAGE=/vmlinuz-4.17.19-200.fc28.x86_64 root=/dev/mapper/fedora_localhost--live-root ro resume=/dev/mapper/fedora_localhost--live-swap rd.lvm.lv=fedora_localhost-live/root rd.lvm.lv=fedora_localhost-live/swap rhgb quiet LANG=en_US.UTF-8 package:kernel-core-4.17.19-200.fc28 count: 1 Directory: /var/spool/abrt/oops-2018-09-12-21:06:20-1097-0 Reported: cannot be reported id 2080ce3bda97bfd322d5c990246fc1e469070719 reason: WARNING: CPU: 13 PID: 2075 at drivers/gpu/drm/amd/amdgpu/../display/dc/dc_helper.c:195 generic_reg_wait+0xe7/0x160 [amdgpu] time: Wed 12 Sep 2018 06:38:14 PM CDT cmdline:BOOT_IMAGE=/vmlinuz-4.17.19-200.fc28.x86_64 root=/dev/mapper/fedora_localhost--live-root ro resume=/dev/mapper/fedora_localhost--live-swap rd.lvm.lv=fedora_localhost-live/root rd.lvm.lv=fedora_localhost-live/swap rhgb quiet LANG=en_US.UTF-8 package:kernel-core-4.17.19-200.fc28 count: 1 Directory: /var/spool/abrt/oops-2018-09-12-18:38:14-1097-0 Reported: cannot be reported id 2b158d01373c68835fa7a7a592b6d10f46280e1a reason: WARNING: CPU: 12 PID: 2075 at drivers/gpu/drm/amd/amdgpu/../display/dc/dc_helper.c:195 generic_reg_wait+0xe7/0x160 [amdgpu] time: Wed 12 Sep 2018 07:00:59 AM CDT cmdline:BOOT_IMAGE=/vmlinuz-4.17.19-200.fc28.x86_64 root=/dev/mapper/fedora_localhost--live-root ro resume=/dev/mapper/fedora_localhost--live-swap rd.lvm.lv=fedora_localhost-live/root rd.lvm.lv=fedora_localhost-live/swap rhgb quiet LANG=en_US.UTF-8 package:kernel-core-4.17.19-200.fc28 count: 1 Directory: /var/spool/abrt/oops-2018-09-12-07:00:59-1097-0 Reported: cannot be reported id d74c82f3f41d887151e83b1972fae4d8f9c7be8b reason: WARNING: CPU: 1 PID: 1390 at drivers/gpu/drm/amd/amdgpu/../display/dc/dc_helper.c:195 generic_reg_wait+0xe7/0x160 [amdgpu] time: Tue 11 Sep 2018 05:58:37 PM CDT cmdline:BOOT_IMAGE=/vmlinuz-4.17.19-200.fc28.x86_64 root=/dev/mapper/fedora_localhost--live-root ro resume=/dev/mapper/fedora_localhost--live-swap rd.lvm.lv=fedora_localhost-live/root rd.lvm.lv=fedora_localhost-live/swap rhgb quiet LANG=en_US.UTF-8 package:kernel-core-4.17.19-200.fc28 count: 1 Directory: /var/spool/abrt/oops-2018-09-11-17:58:37-1097-0 Reported: cannot be reported -- 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] drm/radeon: change function signature to pass full range
On Mon, Sep 17, 2018 at 4:29 PM Mathieu Malaterre wrote:
>
>
>
> On Fri, Apr 13, 2018 at 9:59 AM Huang Rui wrote:
>>
>> On Thu, Apr 12, 2018 at 09:33:33PM +0200, Mathieu Malaterre wrote:
>> > In function ‘radeon_process_i2c_ch’ a comparison of a u8 value against
>> > 255 is done. Since it is always false, change the signature of this
>> > function to use an `int` instead, which match the type used in caller:
>> > `radeon_atom_hw_i2c_xfer`.
>> >
>> > Fix the following warning triggered with W=1:
>> >
>> > CC [M] drivers/gpu/drm/radeon/atombios_i2c.o
>> > drivers/gpu/drm/radeon/atombios_i2c.c: In function
>> > ‘radeon_process_i2c_ch’:
>> > drivers/gpu/drm/radeon/atombios_i2c.c:71:11: warning: comparison is
>> > always false due to limited range of data type [-Wtype-limits]
>> >if (num > ATOM_MAX_HW_I2C_READ) {
>> >^
>> >
>> > Signed-off-by: Mathieu Malaterre
>>
>> Reviewed-by: Huang Rui
>>
>
> Any chance to be included in the next pull request ? thanks
Applied. thanks for the reminder.
Alex
>
>>
>> > ---
>> > drivers/gpu/drm/radeon/atombios_i2c.c | 2 +-
>> > 1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > diff --git a/drivers/gpu/drm/radeon/atombios_i2c.c
>> > b/drivers/gpu/drm/radeon/atombios_i2c.c
>> > index 4157780585a0..9022e9af11a0 100644
>> > --- a/drivers/gpu/drm/radeon/atombios_i2c.c
>> > +++ b/drivers/gpu/drm/radeon/atombios_i2c.c
>> > @@ -35,7 +35,7 @@
>> >
>> > static int radeon_process_i2c_ch(struct radeon_i2c_chan *chan,
>> >u8 slave_addr, u8 flags,
>> > - u8 *buf, u8 num)
>> > + u8 *buf, int num)
>> > {
>> > struct drm_device *dev = chan->dev;
>> > struct radeon_device *rdev = dev->dev_private;
>> > --
>> > 2.11.0
>> >
>> > ___
>> > amd-gfx mailing list
>> > amd-...@lists.freedesktop.org
>> > https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>
> ___
> 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
[PATCH v2] drm: Return -EOPNOTSUPP in drm_setclientcap() when driver do not support KMS
All DRM_CLIENT capabilities are tied to KMS support, so returning
-EOPNOTSUPP when KMS is not supported.
v2: returning -EOPNOTSUPP(same value as posix ENOTSUP and available
in uapi) instead of -ENOTSUPP
Cc: Chris Wilson
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/drm_ioctl.c | 3 +++
drivers/gpu/drm/i915/i915_perf.c | 2 +-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 60dfbfae6a02..c0de628c194c 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -306,6 +306,9 @@ drm_setclientcap(struct drm_device *dev, void *data, struct
drm_file *file_priv)
{
struct drm_set_client_cap *req = data;
+ if (!drm_core_check_feature(dev, DRIVER_MODESET))
+ return -EOPNOTSUPP;
+
switch (req->capability) {
case DRM_CLIENT_CAP_STEREO_3D:
if (req->value > 1)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 664b96bb65a3..c1edd1e69a3e 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -2817,7 +2817,7 @@ int i915_perf_open_ioctl(struct drm_device *dev, void
*data,
if (!dev_priv->perf.initialized) {
DRM_DEBUG("i915 perf interface not available for this
system\n");
- return -ENOTSUPP;
+ return -EOPNOTSUPP;
}
known_open_flags = I915_PERF_FLAG_FD_CLOEXEC |
--
2.19.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/probe_helper: Don't bother probing when connectors are forced off
On Mon, 2018-09-17 at 21:16 +0300, Ville Syrjälä wrote:
> On Mon, Sep 17, 2018 at 02:10:02PM -0400, Lyude Paul wrote:
> > On Mon, 2018-09-17 at 20:55 +0300, Ville Syrjälä wrote:
> > > On Mon, Sep 17, 2018 at 01:43:44PM -0400, Lyude Paul wrote:
> > > > Userspace asked them to be forced off, so why would we care about what a
> > > > probe tells us?
> > >
> > > I believe there should be force checks in the callers already.
> > > Or are we missing some?
> >
> > JFYI, what triggered me to send this patch are these error messages that
> > come
> > from nouveau when a hotplug happens on a port that we've forced off:
> >
> > [ 1903.918104] nouveau :01:00.0: DRM: DDC responded, but no EDID for DP-
> > 2
> > [ 1903.918123] [drm:drm_helper_hpd_irq_event [drm_kms_helper]]
> > [CONNECTOR:61:DP-2] status updated from disconnected to disconnected
> >
> > That being said; I'm sure there are probably some checks missing, but I
> > don't
> > really see the purpose in calling the driver's probe functions at all if
> > they're
> > just supposed to return the status we forced.
>
> Digging through my cobweb ridden local git repository I found this:
>
> commit bbd17813a7c7d0210c619365707044d0fb29e3f0
> Author: Ville Syrjälä
> Date: Mon Jun 10 15:28:55 2013 +0300
>
> drm: Ignore forced connectors in drm_helper_hpd_irq_event()
>
> drm_helper_hpd_irq_event() calls the connector's .detect() function
> even for forced connectors. If the returned status doesn't match the
> forced status, we will send the hotplug event, causing userspace to
> re-probe all the connectors. Eventually we should end up back where
> we started when drm_helper_probe_single_connector_modes() overwrites
> the connector status with the forced status.
>
> We can avoid all that pointles work if we just skip forced connectors
> in drm_helper_hpd_irq_event().
>
> Signed-off-by: Ville Syrjälä
>
> diff --git a/drivers/gpu/drm/drm_crtc_helper.c
> b/drivers/gpu/drm/drm_crtc_helper.c
> index ed1334e27c33..4fc2ad76c107 100644
> --- a/drivers/gpu/drm/drm_crtc_helper.c
> +++ b/drivers/gpu/drm/drm_crtc_helper.c
> @@ -1086,6 +1086,10 @@ void drm_helper_hpd_irq_event(struct drm_device *dev)
> mutex_lock(>mode_config.mutex);
> list_for_each_entry(connector, >mode_config.connector_list, head) {
>
> + /* Ignore forced connectors. */
> + if (connector->force)
> + continue;
> +
> /* Only handle HPD capable connectors. */
> if (!(connector->polled & DRM_CONNECTOR_POLL_HPD))
> continue;
>
>
> I guess I never sent it out.
Ahhh, to be honest though this patch isn't really enough.
drm_helper_hpd_irq_event() isn't going to be used by all drivers (I may remove
some usage of it in nouveau in the near future, even) so I still think it would
be a better idea to just add this into drm_helper_probe_detect() and
drm_helper_probe_detect_ctx() so everything gets covered
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107950] Delayed freeze with DRI_PRIME=1 on Topaz
https://bugs.freedesktop.org/show_bug.cgi?id=107950 --- Comment #1 from Alex Deucher --- Can you attach the xorg log and dmesg output from your system? -- 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: [RESEND 4/5] drm/mxsfb: Add PM_SLEEP support
Hi Leonard.
On Mon, Aug 27, 2018 at 02:10:40PM +0300, Leonard Crestez wrote:
> Since power to the lcdif block can be lost on suspend implement
> PM_SLEEP_OPS using drm_mode_config_helper_suspend/resume to save/restore
> the current mode.
>
> Signed-off-by: Leonard Crestez
> Reviewed-by: Stefan Agner
> ---
> drivers/gpu/drm/mxsfb/mxsfb_drv.c | 21 +
> 1 file changed, 21 insertions(+)
>
> diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> index 68d79f5dc0d3..d797dfd40d98 100644
> --- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> +++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> @@ -416,17 +416,38 @@ static int mxsfb_remove(struct platform_device *pdev)
> drm_dev_unref(drm);
>
> return 0;
> }
>
> +#ifdef CONFIG_PM_SLEEP
> +static int mxsfb_suspend(struct device *dev)
> +{
> + struct drm_device *drm = dev_get_drvdata(dev);
> +
> + return drm_mode_config_helper_suspend(drm);
> +}
> +
> +static int mxsfb_resume(struct device *dev)
> +{
> + struct drm_device *drm = dev_get_drvdata(dev);
> +
> + return drm_mode_config_helper_resume(drm);
> +}
> +#endif
Other suspend/resume users skip the #ifdef and declare
the functions __maybe_unused
See for example arm/hdlcd_drv.c.
The resulting code is a bit simpler to read and you
have the added benefit that the suspend/resume functions
are always compiled so bit-rotting is less likely.
Sam
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm] CONTRIBUTING: clarify how to request a Developer role
On Mon, Sep 17, 2018 at 11:01:15AM +0100, Daniel Stone wrote:
> Hi,
>
> On Sat, 15 Sep 2018 at 00:56, Lucas De Marchi
> wrote:
> > -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.
> > +To apply for commit rights ("Developer" role in gitlab), check project
> > +members who have the "owner" role at
> > +https://gitlab.freedesktop.org/mesa/drm/project_members?sort=access_level_desc.
> > +Any of them can add new developers.
>
> I think it still makes sense to discuss it publicly, either on the
> list or through a bug tracker. Having an audit log of who's there and
> why is pretty important. I would suggest the process be to email
> dri-devel@ and request it, then if nothing happens ping one of the
> people listed there as an owner.
Or file a GL issue, perhaps?
Sean
>
> Cheers,
> Daniel
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
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: [RESEND 0/5] drm/mxsfb: Fix runtime PM for unpowering lcdif block
On Mon, Sep 17, 2018 at 04:42:10PM +0300, Leonard Crestez wrote: > Adding lcdif nodes to a power domain currently doesn't work, it results > in black/corrupted screens or hangs. While the driver does enable > runtime pm it does not deal correctly with the block being unpowered. > > --- > > All patches in this series have review tags from a while ago and I > tested them again on top of next-20180913. No changes since last > version: https://lkml.org/lkml/2018/8/27/299 > > This series stalled so I reached out to Marek on IRC and he was > surprised to be listed as maintainer Hopefully not too surprised since Marek added themself to MAINTAINERS when adding the driver :-) I suppose we should probably move this to drm-misc since it qualifies as a "small driver" and needs a home. Looking through git history shows the last mxsfb-specific change was back in 02/17. Everything else has been drm-wide refactors. Thoughts? Marek/Leonard: Care to sign up to be listed as a reviewers? Sean > and asked me to resend and add > Daniel Vetter. > > Perhaps it would help to clarify that the pengutronix people should feel > free to push patches in this area? > > Right now drm/imx is mostly for IPUv3 but there are other display output > paths on imx, such as the LCDIF supported by this driver. This LCDIF > block is included on imx8 so still quite relevant. > > Leonard Crestez (5): > drm/mxsfb: Move axi clk enable/disable to crtc enable/disable > drm/mxsfb: Fix initial corrupt frame when activating display > drm/mxsfb: Add pm_runtime calls to pipe_enable/disable > drm/mxsfb: Add PM_SLEEP support > drm/mxsfb: Switch to drm_atomic_helper_commit_tail_rpm > > drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 53 +++--- > drivers/gpu/drm/mxsfb/mxsfb_drv.c | 40 ++ > 2 files changed, 74 insertions(+), 19 deletions(-) > > -- > 2.17.1 > -- 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] drm/atomic: Use drm_drv_uses_atomic_modeset() for debugfs creation
On Mon, Sep 17, 2018 at 01:37:33PM -0400, Lyude Paul wrote:
> As pointed out by Daniel Vetter, we should be usinng
> drm_drv_uses_atomic_modeset() for determining whether or not we want to
> make the debugfs nodes for atomic instead of checking DRIVER_ATOMIC, as
> the former isn't an accurate representation of whether or not the driver
> is actually using atomic modesetting internally (even though it might
> not be exposing atomic capabilities).
>
> Signed-off-by: Lyude Paul
Reviewed-by: Sean Paul
> Cc: Daniel Vetter
> Cc: sta...@vger.kernel.org
> ---
> drivers/gpu/drm/drm_atomic.c | 2 +-
> drivers/gpu/drm/drm_debugfs.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 3eb061e11e2e..018fcdb353d2 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -2067,7 +2067,7 @@ static void __drm_state_dump(struct drm_device *dev,
> struct drm_printer *p,
> struct drm_connector *connector;
> struct drm_connector_list_iter conn_iter;
>
> - if (!drm_core_check_feature(dev, DRIVER_ATOMIC))
> + if (!drm_drv_uses_atomic_modeset(dev))
> return;
>
> list_for_each_entry(plane, >plane_list, head) {
> diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
> index 6f28fe58f169..373bd4c2b698 100644
> --- a/drivers/gpu/drm/drm_debugfs.c
> +++ b/drivers/gpu/drm/drm_debugfs.c
> @@ -151,7 +151,7 @@ int drm_debugfs_init(struct drm_minor *minor, int
> minor_id,
> return ret;
> }
>
> - if (drm_core_check_feature(dev, DRIVER_ATOMIC)) {
> + if (drm_drv_uses_atomic_modeset(dev)) {
> ret = drm_atomic_debugfs_init(minor);
> if (ret) {
> DRM_ERROR("Failed to create atomic debugfs files\n");
> --
> 2.17.1
>
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107873] Doom 2016 - Rendering issues
https://bugs.freedesktop.org/show_bug.cgi?id=107873 --- Comment #11 from Ahmed Elsayed --- (In reply to Timothy Arceri from comment #9) > (In reply to Zebediah Figura from comment #7) > > Do you mean that this is a bug present in Staging but not in upstream Wine? > > In particular, is the patchset "opengl32-Revert_Disable_Ext" to blame? > > Ok so it seems someone has confirmed this patch is the problem in the wine > bug, so I'm going to close this bug. It was wine bug. Sorry for posting here. And thanks for your patient. -- 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 107873] Doom 2016 - Rendering issues
https://bugs.freedesktop.org/show_bug.cgi?id=107873 --- Comment #10 from Ahmed Elsayed --- (In reply to Ahmed Elsayed from comment #6) > I can start the game with Vulkan but it stops loading at 99%, but with > opengl, I can hear the menu sounds but I can see only the red fog. > > I filed a bug in Wine but no one answered me. > > https://bugs.winehq.org/show_bug.cgi?id=45826 Using the normal wine instead of wine-staging solved this issue, and the game is working fine with opengl. Thanks for your help. -- 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: Add new DIRTY fb flags to pass interlaced alternate fields
Hi Satish, On Fri, 7 Sep 2018 at 23:04, Satish Nagireddy wrote: > The requirement is to render interlaced alternate buffers. In case of > alternate, top field and bottom field are in two different buffers. > > The question is, can we pass existing flags DRM_MODE_PRESENT_TOP_FIELD > and DRM_MODE_PRESENT_TOP_FIELD to DRM_IOCTL_MODE_SETPLANE ioctl? Yes, if the driver implements it. No in-tree driver implements it, and the core does not pass along or even check the flags, so you would have to modify the DRM core in order to implement this. This makes the userspace depend on a specific driver, but this is already the case for setplane, as the pre-atomic interface is hopelessly underspecified wrt timing etc, which differs massively between drivers. We recommend not using it. > But in case if urrent frame out of display range, application > will invoke DRM_IOCTL_MODE_PAGE_FLIP ioctl. So, it is not guaranteed > that application will always call setplane(), it may also call page_flip(). > Then we will have to introduce two more flags to pass with page_flip() > ioctl, which is complicating things. Yes, that's correct. > Background of DRM_IOCTL_MODE_DIRTYFB ioctl: This ioctl is defined, so > that userspace can notify the driver that an area of framebuffer has > changed and should be flushed to display hardware. > > The proposed solution is to introduce new dirty fb flags, so that userspace > can pass them with every alternate field buffer and the same is reached > display hardware. This patch adds new dirty framebuffer flags, so that > application can pass interlaced alternate field information to driver. If you're adding two new flags anyway, why not just add them to pageflip? DirtyFB is not required when pageflipping, and is mostly only intended for single-buffered usecases, which this is not. It is not required to be used in pageflipping pipelines, and making people use DirtyFB in order to specify frame order is quite strange. Another place where you could specify the field order would be in AddFB, which was discussed in this thread: https://lists.freedesktop.org/archives/dri-devel/2016-March/thread.html#102161 In any case, I would very much recommend using atomic modesetting both within your driver and also within GStreamer, as this solves many other issues at the same time. Cheers, Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/probe_helper: Don't bother probing when connectors are forced off
On Mon, Sep 17, 2018 at 02:10:02PM -0400, Lyude Paul wrote:
> On Mon, 2018-09-17 at 20:55 +0300, Ville Syrjälä wrote:
> > On Mon, Sep 17, 2018 at 01:43:44PM -0400, Lyude Paul wrote:
> > > Userspace asked them to be forced off, so why would we care about what a
> > > probe tells us?
> >
> > I believe there should be force checks in the callers already.
> > Or are we missing some?
>
> JFYI, what triggered me to send this patch are these error messages that come
> from nouveau when a hotplug happens on a port that we've forced off:
>
> [ 1903.918104] nouveau :01:00.0: DRM: DDC responded, but no EDID for DP-2
> [ 1903.918123] [drm:drm_helper_hpd_irq_event [drm_kms_helper]]
> [CONNECTOR:61:DP-2] status updated from disconnected to disconnected
>
> That being said; I'm sure there are probably some checks missing, but I don't
> really see the purpose in calling the driver's probe functions at all if
> they're
> just supposed to return the status we forced.
Digging through my cobweb ridden local git repository I found this:
commit bbd17813a7c7d0210c619365707044d0fb29e3f0
Author: Ville Syrjälä
Date: Mon Jun 10 15:28:55 2013 +0300
drm: Ignore forced connectors in drm_helper_hpd_irq_event()
drm_helper_hpd_irq_event() calls the connector's .detect() function
even for forced connectors. If the returned status doesn't match the
forced status, we will send the hotplug event, causing userspace to
re-probe all the connectors. Eventually we should end up back where
we started when drm_helper_probe_single_connector_modes() overwrites
the connector status with the forced status.
We can avoid all that pointles work if we just skip forced connectors
in drm_helper_hpd_irq_event().
Signed-off-by: Ville Syrjälä
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index ed1334e27c33..4fc2ad76c107 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -1086,6 +1086,10 @@ void drm_helper_hpd_irq_event(struct drm_device *dev)
mutex_lock(>mode_config.mutex);
list_for_each_entry(connector, >mode_config.connector_list, head) {
+ /* Ignore forced connectors. */
+ if (connector->force)
+ continue;
+
/* Only handle HPD capable connectors. */
if (!(connector->polled & DRM_CONNECTOR_POLL_HPD))
continue;
I guess I never sent it out.
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/probe_helper: Don't bother probing when connectors are forced off
On Mon, 2018-09-17 at 20:55 +0300, Ville Syrjälä wrote:
> On Mon, Sep 17, 2018 at 01:43:44PM -0400, Lyude Paul wrote:
> > Userspace asked them to be forced off, so why would we care about what a
> > probe tells us?
>
> I believe there should be force checks in the callers already.
> Or are we missing some?
JFYI, what triggered me to send this patch are these error messages that come
from nouveau when a hotplug happens on a port that we've forced off:
[ 1903.918104] nouveau :01:00.0: DRM: DDC responded, but no EDID for DP-2
[ 1903.918123] [drm:drm_helper_hpd_irq_event [drm_kms_helper]]
[CONNECTOR:61:DP-2] status updated from disconnected to disconnected
That being said; I'm sure there are probably some checks missing, but I don't
really see the purpose in calling the driver's probe functions at all if they're
just supposed to return the status we forced.
>
> >
> > Signed-off-by: Lyude Paul
> > ---
> > drivers/gpu/drm/drm_probe_helper.c | 7 ++-
> > 1 file changed, 6 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_probe_helper.c
> > b/drivers/gpu/drm/drm_probe_helper.c
> > index a1bb157bfdfa..56d2b5dd1f58 100644
> > --- a/drivers/gpu/drm/drm_probe_helper.c
> > +++ b/drivers/gpu/drm/drm_probe_helper.c
> > @@ -269,7 +269,9 @@ drm_helper_probe_detect_ctx(struct drm_connector
> > *connector, bool force)
> > retry:
> > ret = drm_modeset_lock(>dev->mode_config.connection_mutex,
> > );
> > if (!ret) {
> > - if (funcs->detect_ctx)
> > + if (connector->force == DRM_FORCE_OFF)
> > + ret = connector_status_disconnected;
>
> connector->force is protected by mode_config.mutex IIRC.
>
> > + else if (funcs->detect_ctx)
> > ret = funcs->detect_ctx(connector, , force);
> > else if (connector->funcs->detect)
> > ret = connector->funcs->detect(connector, force);
> > @@ -317,6 +319,9 @@ drm_helper_probe_detect(struct drm_connector *connector,
> > if (ret)
> > return ret;
> >
> > + if (connector->force == DRM_FORCE_OFF)
> > + return connector_status_disconnected;
> > +
> > if (funcs->detect_ctx)
> > return funcs->detect_ctx(connector, ctx, force);
> > else if (connector->funcs->detect)
> > --
> > 2.17.1
> >
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 200695] Blank screen on RX 580 with amdgpu.dc=1 enabled (no displays detected)
https://bugzilla.kernel.org/show_bug.cgi?id=200695 --- Comment #11 from Andrey Arapov (andrey.ara...@nixaid.com) --- Oh, that option is gone from 4.18. -- 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] drm/probe_helper: Don't bother probing when connectors are forced off
On Mon, 2018-09-17 at 20:55 +0300, Ville Syrjälä wrote:
> On Mon, Sep 17, 2018 at 01:43:44PM -0400, Lyude Paul wrote:
> > Userspace asked them to be forced off, so why would we care about what a
> > probe tells us?
>
> I believe there should be force checks in the callers already.
> Or are we missing some?
JFYI, this is to fix "DDC responded but no EDID" errors from nouveau, which
presumably come from the fact that having a connector forced off disables
reading it's EDID. It's possible we are missing something in
nouveau_connector_detect(), but I'm confused as to why we would want to call
->probe() at all in the first place
>
> >
> > Signed-off-by: Lyude Paul
> > ---
> > drivers/gpu/drm/drm_probe_helper.c | 7 ++-
> > 1 file changed, 6 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_probe_helper.c
> > b/drivers/gpu/drm/drm_probe_helper.c
> > index a1bb157bfdfa..56d2b5dd1f58 100644
> > --- a/drivers/gpu/drm/drm_probe_helper.c
> > +++ b/drivers/gpu/drm/drm_probe_helper.c
> > @@ -269,7 +269,9 @@ drm_helper_probe_detect_ctx(struct drm_connector
> > *connector, bool force)
> > retry:
> > ret = drm_modeset_lock(>dev->mode_config.connection_mutex,
> > );
> > if (!ret) {
> > - if (funcs->detect_ctx)
> > + if (connector->force == DRM_FORCE_OFF)
> > + ret = connector_status_disconnected;
>
> connector->force is protected by mode_config.mutex IIRC.
>
> > + else if (funcs->detect_ctx)
> > ret = funcs->detect_ctx(connector, , force);
> > else if (connector->funcs->detect)
> > ret = connector->funcs->detect(connector, force);
> > @@ -317,6 +319,9 @@ drm_helper_probe_detect(struct drm_connector *connector,
> > if (ret)
> > return ret;
> >
> > + if (connector->force == DRM_FORCE_OFF)
> > + return connector_status_disconnected;
> > +
> > if (funcs->detect_ctx)
> > return funcs->detect_ctx(connector, ctx, force);
> > else if (connector->funcs->detect)
> > --
> > 2.17.1
> >
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/probe_helper: Don't bother probing when connectors are forced off
On Mon, Sep 17, 2018 at 01:43:44PM -0400, Lyude Paul wrote:
> Userspace asked them to be forced off, so why would we care about what a
> probe tells us?
I believe there should be force checks in the callers already.
Or are we missing some?
>
> Signed-off-by: Lyude Paul
> ---
> drivers/gpu/drm/drm_probe_helper.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_probe_helper.c
> b/drivers/gpu/drm/drm_probe_helper.c
> index a1bb157bfdfa..56d2b5dd1f58 100644
> --- a/drivers/gpu/drm/drm_probe_helper.c
> +++ b/drivers/gpu/drm/drm_probe_helper.c
> @@ -269,7 +269,9 @@ drm_helper_probe_detect_ctx(struct drm_connector
> *connector, bool force)
> retry:
> ret = drm_modeset_lock(>dev->mode_config.connection_mutex,
> );
> if (!ret) {
> - if (funcs->detect_ctx)
> + if (connector->force == DRM_FORCE_OFF)
> + ret = connector_status_disconnected;
connector->force is protected by mode_config.mutex IIRC.
> + else if (funcs->detect_ctx)
> ret = funcs->detect_ctx(connector, , force);
> else if (connector->funcs->detect)
> ret = connector->funcs->detect(connector, force);
> @@ -317,6 +319,9 @@ drm_helper_probe_detect(struct drm_connector *connector,
> if (ret)
> return ret;
>
> + if (connector->force == DRM_FORCE_OFF)
> + return connector_status_disconnected;
> +
> if (funcs->detect_ctx)
> return funcs->detect_ctx(connector, ctx, force);
> else if (connector->funcs->detect)
> --
> 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
[Bug 200695] Blank screen on RX 580 with amdgpu.dc=1 enabled (no displays detected)
https://bugzilla.kernel.org/show_bug.cgi?id=200695 Andrey Arapov (andrey.ara...@nixaid.com) changed: What|Removed |Added CC||andrey.ara...@nixaid.com --- Comment #10 from Andrey Arapov (andrey.ara...@nixaid.com) --- Could you try enabling CONFIG_DRM_AMD_DC_PRE_VEGA option when rebuilding the kernel and see if that works with amdgpu.dc=1 ? -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/probe_helper: Don't bother probing when connectors are forced off
Userspace asked them to be forced off, so why would we care about what a
probe tells us?
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_probe_helper.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_probe_helper.c
b/drivers/gpu/drm/drm_probe_helper.c
index a1bb157bfdfa..56d2b5dd1f58 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -269,7 +269,9 @@ drm_helper_probe_detect_ctx(struct drm_connector
*connector, bool force)
retry:
ret = drm_modeset_lock(>dev->mode_config.connection_mutex,
);
if (!ret) {
- if (funcs->detect_ctx)
+ if (connector->force == DRM_FORCE_OFF)
+ ret = connector_status_disconnected;
+ else if (funcs->detect_ctx)
ret = funcs->detect_ctx(connector, , force);
else if (connector->funcs->detect)
ret = connector->funcs->detect(connector, force);
@@ -317,6 +319,9 @@ drm_helper_probe_detect(struct drm_connector *connector,
if (ret)
return ret;
+ if (connector->force == DRM_FORCE_OFF)
+ return connector_status_disconnected;
+
if (funcs->detect_ctx)
return funcs->detect_ctx(connector, ctx, force);
else if (connector->funcs->detect)
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/atomic: Use drm_drv_uses_atomic_modeset() for debugfs creation
As pointed out by Daniel Vetter, we should be usinng
drm_drv_uses_atomic_modeset() for determining whether or not we want to
make the debugfs nodes for atomic instead of checking DRIVER_ATOMIC, as
the former isn't an accurate representation of whether or not the driver
is actually using atomic modesetting internally (even though it might
not be exposing atomic capabilities).
Signed-off-by: Lyude Paul
Cc: Daniel Vetter
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/drm_atomic.c | 2 +-
drivers/gpu/drm/drm_debugfs.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 3eb061e11e2e..018fcdb353d2 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -2067,7 +2067,7 @@ static void __drm_state_dump(struct drm_device *dev,
struct drm_printer *p,
struct drm_connector *connector;
struct drm_connector_list_iter conn_iter;
- if (!drm_core_check_feature(dev, DRIVER_ATOMIC))
+ if (!drm_drv_uses_atomic_modeset(dev))
return;
list_for_each_entry(plane, >plane_list, head) {
diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index 6f28fe58f169..373bd4c2b698 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
@@ -151,7 +151,7 @@ int drm_debugfs_init(struct drm_minor *minor, int minor_id,
return ret;
}
- if (drm_core_check_feature(dev, DRIVER_ATOMIC)) {
+ if (drm_drv_uses_atomic_modeset(dev)) {
ret = drm_atomic_debugfs_init(minor);
if (ret) {
DRM_ERROR("Failed to create atomic debugfs files\n");
--
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/nouveau: Disable atomic support on a per-device basis
On Fri, 2018-09-14 at 10:11 +0200, Daniel Vetter wrote: > On Thu, Sep 13, 2018 at 11:02 PM, Lyude Paul wrote: > > Hm, one nitpick here. Since /sys/kernel/debug/dri/*/state creation depends > > on > > the driver supporting atomic, maybe it would be good to make it so that we > > set > > DRIVER_ATOMIC in the driver_stub structure, then disable it per-device > > depending > > on the nouveau_atomic setting + hw support. That way we can always have the > > state debugfs file while maintaining nouveau's current behavior with > > exposing > > atomic ioctls. Assuming that wouldn't have any unintended side-effects of > > course > > dri/*/state only works with atomic drivers. There's no explicit state > with legacy drivers at all, it's all just implicit in hw and some > random driver structures. > > We should make sure though that the debugfs stuff looks at > drm_drv_uses_atomic_modsetting(), and not DRIVER_ATOMIC. Former is > about the internals (i915 is internally atomic everywhere), latter > about the uapi (some old platforms aren't properly validated for full > atomic features, hence why it's disabled). > -Daniel Makes sense, it seems doing that results in exactly what I wanted with nouveau! As for this patch: Reviewed-by: Lyude Paul > > > On Thu, 2018-09-13 at 19:31 +0300, Ville Syrjala wrote: > > > From: Ville Syrjälä > > > > > > We now have per-device driver_features, so let's use that > > > to disable atomic only for pre-nv50. > > > > > > Cc: Ben Skeggs > > > Cc: Lyude Paul > > > Cc: nouv...@lists.freedesktop.org > > > Cc: Daniel Vetter > > > Reviewed-by: Daniel Vetter > > > Suggested-by: Daniel Vetter > > > Signed-off-by: Ville Syrjälä > > > --- > > > drivers/gpu/drm/nouveau/dispnv04/disp.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/drivers/gpu/drm/nouveau/dispnv04/disp.c > > > b/drivers/gpu/drm/nouveau/dispnv04/disp.c > > > index 70dce544984e..670535a68d3b 100644 > > > --- a/drivers/gpu/drm/nouveau/dispnv04/disp.c > > > +++ b/drivers/gpu/drm/nouveau/dispnv04/disp.c > > > @@ -56,7 +56,7 @@ nv04_display_create(struct drm_device *dev) > > > nouveau_display(dev)->fini = nv04_display_fini; > > > > > > /* Pre-nv50 doesn't support atomic, so don't expose the ioctls */ > > > - dev->driver->driver_features &= ~DRIVER_ATOMIC; > > > + dev->driver_features &= ~DRIVER_ATOMIC; > > > > > > nouveau_hw_save_vga_fonts(dev, 1); > > > > > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107955] AMDGPU driver keeps reloading on hybrid graphics system causing stuttering.
https://bugs.freedesktop.org/show_bug.cgi?id=107955
--- Comment #15 from Michel Dänzer ---
(In reply to Mike Lothian from comment #13)
> hw/xfree86/dri2/dri2.c:if (drmGetDevice(info->fd, ) || dev->bustype
> != DRM_BUS_PCI) {
> hw/xfree86/drivers/modesetting/dri2.c:info.deviceName =
> drmGetDeviceNameFromFd(ms->fd);
>
> [...]
>
> src/amdgpu_dri2.c: info->dri2.device_name =
> drmGetDeviceNameFromFd(pAMDGPUEnt->fd);
These are only called during X server startup.
> va/drm/va_drm_utils.c:name = drmGetDeviceNameFromFd(fd);
This should only be called when a video player using VA-API runs standalone,
not via X (or Wayland), and even then only once.
Try running
sudo perf record -e rpm:rpm_resume --call-graph=dwarf
in a terminal, then do whatever is needed to reproduce the problem, then
interrupt the perf command with Ctrl-C and attach the output of
sudo perf report --header
--
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] MAINTAINERS: drm: Remove myself as drm-bridge maintainer
On Thu, Sep 13, 2018 at 01:23:00PM +0530, Archit Taneja wrote: > I have moved on to other stuff for now. Haven't been able to make time > to review bridge related work. Andrzej has been doing it by himself > for a while now. > > Cc: Andrzej Hajda > Cc: Laurent Pinchart > Cc: Gustavo Padovan > Cc: Maarten Lankhorst > Cc: Sean Paul > Cc: Daniel Vetter > Signed-off-by: Archit Taneja Sorry to see you taking a less active role, Archit. Hopefully you'll stick around on IRC and find some cycles for us in the future! Acked-by: Sean Paul > --- > MAINTAINERS | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 9d9068ed4ee5..7ed01e227684 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -4793,7 +4793,6 @@ F: Documentation/devicetree/bindings/display/atmel/ > T: git git://anongit.freedesktop.org/drm/drm-misc > > DRM DRIVERS FOR BRIDGE CHIPS > -M: Archit Taneja > M: Andrzej Hajda > R: Laurent Pinchart > S: Maintained > -- > 2.18.0 > -- 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: [Freedreno] [PATCH] drm/msm/dpu: Remove an unused enum
On Thu, Sep 13, 2018 at 10:46:15AM -0600, Jordan Crouse wrote:
> enum dpu_ad isn't used and can be safely removed.
>
> Signed-off-by: Jordan Crouse
Nice catch! I've pushed it to dpu-staging
Sean
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h | 6 --
> 1 file changed, 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h
> index 62cf127b16d4..68c54d2c9677 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h
> @@ -232,12 +232,6 @@ enum dpu_wb {
> WB_MAX
> };
>
> -enum dpu_ad {
> - AD_0 = 0x1,
> - AD_1,
> - AD_MAX
> -};
> -
> enum dpu_cwb {
> CWB_0 = 0x1,
> CWB_1,
> --
> 2.18.0
>
> ___
> Freedreno mailing list
> freedr...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/freedreno
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107375] Raven: `amdgpu_device_ip_resume_phase2()` takes 750 ms
https://bugs.freedesktop.org/show_bug.cgi?id=107375 --- Comment #3 from Paul Menzel --- With v4.19-rc4-22-gad3273d5f1b9 (Merge tag 'ext4_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4) this now got worse, and `amdgpu_device_ip_resume_phase2()` now takes 1.166 s. `psp_np_fw_load()` takes 868.190 ms, and `dm_resume()` 178.380 ms. It’d be great, if you could talk to the PSP firmware team, and also document, if you can reproduce this. -- 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 201147] amdgpu, no detected monitors HP Envy x360 - AMD Ryzen 5 2500U
https://bugzilla.kernel.org/show_bug.cgi?id=201147 rezbit@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #3 from rezbit@gmail.com --- (In reply to Michel Dänzer from comment #2) > Looks like CONFIG_DRM_AMD_DC_DCN1_0 isn't enabled in the kernel build > configuration. This is a configuration error, which will no longer be > possible in 4.19. Thanks for that, there was hair pulling. -- 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 107955] AMDGPU driver keeps reloading on hybrid graphics system causing stuttering.
https://bugs.freedesktop.org/show_bug.cgi?id=107955 --- Comment #14 from Mike Lothian --- Tonight when I have access to my laptop I'll try switching those two the '2' versions and see if it stops the issues, unless anyone else has any better ideas -- 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 5/5] ARM: sun8i: dts: drop A64 HDMI PHY fallback compatible from R40 DT
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.
And it's exactly what the DT is already saying.
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 107955] AMDGPU driver keeps reloading on hybrid graphics system causing stuttering.
https://bugs.freedesktop.org/show_bug.cgi?id=107955
--- Comment #13 from Mike Lothian ---
I'm not sure, I'm hoping I might be pointing the devs in the right direction
I'm not sure if drmGetDeviceNameFromFd vs drmGetDeviceNameFromFd2 could cause
the issue too - I think it might
I found in the xserver:
hw/xfree86/dri2/dri2.c:if (drmGetDevice(info->fd, ) || dev->bustype !=
DRM_BUS_PCI) {
hw/xfree86/drivers/modesetting/dri2.c:info.deviceName =
drmGetDeviceNameFromFd(ms->fd);
drm/xf86drm.c:int drmGetDevices(drmDevicePtr devices[], int max_devices)
In the AMDGPU DDX:
src/amdgpu_dri2.c: info->dri2.device_name =
drmGetDeviceNameFromFd(pAMDGPUEnt->fd);
And in libva:
va/drm/va_drm_utils.c:name = drmGetDeviceNameFromFd(fd);
I notice in the old libva1 code there was no drmGetDevice stuff and it's only
in libva2 I could find the above reference
--
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] drm: fix use of freed memory in drm_mode_setcrtc
On 17/09/18 17:41, Ville Syrjälä wrote: > On Mon, Sep 17, 2018 at 02:00:54PM +0300, Tomi Valkeinen wrote: >> drm_mode_setcrtc() retries modesetting in case one of the functions it >> calls returns -EDEADLK. connector_set, mode and fb are freed before >> retrying, but they are not set to NULL. This can cause >> drm_mode_setcrtc() to use those variables. >> >> For example: On the first try __drm_mode_set_config_internal() returns >> -EDEADLK. connector_set, mode and fb are freed. Next retry starts, and >> drm_modeset_lock_all_ctx() returns -EDEADLK, and we jump to 'out'. The >> code will happily try to release all three again. > > This thing uses lock_all() so I guess the EDEADLK must be coming from > some private locks in the driver? Yes, I've seen this cause issues only with Benoit's work-in-progress omapdrm patches. > Anyways, patch looks good so > Reviewed-by: Ville Syrjälä Thanks! Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: fix use of freed memory in drm_mode_setcrtc
On Mon, Sep 17, 2018 at 02:00:54PM +0300, Tomi Valkeinen wrote: > drm_mode_setcrtc() retries modesetting in case one of the functions it > calls returns -EDEADLK. connector_set, mode and fb are freed before > retrying, but they are not set to NULL. This can cause > drm_mode_setcrtc() to use those variables. > > For example: On the first try __drm_mode_set_config_internal() returns > -EDEADLK. connector_set, mode and fb are freed. Next retry starts, and > drm_modeset_lock_all_ctx() returns -EDEADLK, and we jump to 'out'. The > code will happily try to release all three again. This thing uses lock_all() so I guess the EDEADLK must be coming from some private locks in the driver? Anyways, patch looks good so Reviewed-by: Ville Syrjälä > > This leads to crashes of different kinds, depending on the sequence the > EDEADLKs happen. > > Fix this by setting the three variables to NULL at the start of the > retry loop. > > Signed-off-by: Tomi Valkeinen > Cc: sta...@vger.kernel.org > --- > drivers/gpu/drm/drm_crtc.c | 10 +++--- > 1 file changed, 7 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c > index 2f6c877299e4..2ad14593fb23 100644 > --- a/drivers/gpu/drm/drm_crtc.c > +++ b/drivers/gpu/drm/drm_crtc.c > @@ -570,9 +570,9 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data, > struct drm_mode_crtc *crtc_req = data; > struct drm_crtc *crtc; > struct drm_plane *plane; > - struct drm_connector **connector_set = NULL, *connector; > - struct drm_framebuffer *fb = NULL; > - struct drm_display_mode *mode = NULL; > + struct drm_connector **connector_set, *connector; > + struct drm_framebuffer *fb; > + struct drm_display_mode *mode; > struct drm_mode_set set; > uint32_t __user *set_connectors_ptr; > struct drm_modeset_acquire_ctx ctx; > @@ -601,6 +601,10 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data, > mutex_lock(>dev->mode_config.mutex); > drm_modeset_acquire_init(, DRM_MODESET_ACQUIRE_INTERRUPTIBLE); > retry: > + connector_set = NULL; > + fb = NULL; > + mode = NULL; > + > ret = drm_modeset_lock_all_ctx(crtc->dev, ); > if (ret) > goto out; > -- > Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. > Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki > > ___ > 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
[Bug 107595] amd-staging-drm-next: BUG: unable to handle kernel NULL pointer dereference at 0000000000000018 - R4 Mullins
https://bugs.freedesktop.org/show_bug.cgi?id=107595 --- Comment #14 from Przemek --- Yeh, "Kaveri" - logical approach.(In reply to Michel Dänzer from comment #13) > (In reply to Przemek from comment #12) > > Pontus Gråskæg, if kernel compiled from the latest git repo sync > > (git://people.freedesktop.org/~agd5f/linux) does not work for you feel free > > to reopen it. > > Please rather file your own report in that case. Yeah, "Kaveri" - logical approach. Sorry. -- 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 107955] AMDGPU driver keeps reloading on hybrid graphics system causing stuttering.
https://bugs.freedesktop.org/show_bug.cgi?id=107955 --- Comment #12 from Ransu --- If this is a library file issue how should I go fixing this? Does this need a upstream or mainline fix? -- 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 107953] Screen Corruption (Bisected)
https://bugs.freedesktop.org/show_bug.cgi?id=107953 --- Comment #1 from Nick Tenney --- Realized I forgot to include some important info for the initial report: Card: Sapphire Nitro RX 580 4 GB Monitor: Monoprice 35 3440x1440@100 Hz via DP 1.2 connection Distro: Arch Linux testing repositories, up to date Mesa: up-to-date git, can look up HEAD if needed -- 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 v2 07/16] drm: rcar-du: Use LVDS PLL clock as dot clock when possible
Hi Laurent,
On Fri, Sep 14, 2018 at 12:10:37PM +0300, Laurent Pinchart wrote:
> On selected SoCs, the DU can use the clock output by the LVDS encoder
> PLL as its input dot clock. This feature is optional, but on the D3 and
> E3 SoC it is often the only way to obtain a precise dot clock frequency,
> as the other available clocks (CPG-generated clock and external clock)
> usually have fixed rates.
>
> Add a DU model information field to describe which DU channels can use
> the LVDS PLL output clock as their input clock, and configure clock
> routing accordingly.
>
> This feature is available on H2, M2-W, M2-N, D3 and E3 SoCs, with D3 and
> E3 being the primary targets. It is left disabled in this commit, and
> will be enabled per-SoC after careful testing.
>
> At the hardware level, clock routing is configured at runtime in two
> steps, first selecting an internal dot clock between the LVDS PLL clock
> and the external DOTCLKIN clock, and then selecting between the internal
> dot clock and the CPG-generated clock. The first part requires stopping
> the whole DU group in order for the change to take effect, thus causing
> flickering on the screen. For this reason we currently hardcode the
> clock source to the LVDS PLL clock if available, and allow flicker-free
> selection of the external DOTCLKIN clock or CPG-generated clock
> otherwise. A more dynamic clock selection process can be implemented
> later if the need arises.
>
> Signed-off-by: Laurent Pinchart
> Tested-by: Jacopo Mondi
Please add my
Reviewed-by: Jacopo Mondi
> ---
> drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 8 +
> drivers/gpu/drm/rcar-du/rcar_du_drv.h | 2 ++
> drivers/gpu/drm/rcar-du/rcar_du_group.c | 64
> +
> 3 files changed, 59 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> index c89751c26f9c..2f8776c1ec8f 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> @@ -261,6 +261,14 @@ static void rcar_du_crtc_set_display_timing(struct
> rcar_du_crtc *rcrtc)
> rcar_du_group_write(rcrtc->group, DPLLCR, dpllcr);
>
> escr = ESCR_DCLKSEL_DCLKIN | div;
> + } else if (rcdu->info->lvds_clk_mask & BIT(rcrtc->index)) {
> + /*
> + * Use the LVDS PLL output as the dot clock when outputting to
> + * the LVDS encoder on an SoC that supports this clock routing
> + * option. We use the clock directly in that case, without any
> + * additional divider.
> + */
> + escr = ESCR_DCLKSEL_DCLKIN;
> } else {
> struct du_clk_params params = { .diff = (unsigned long)-1 };
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
> b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
> index fef9ea5c22f3..ebba9aefba6a 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
> @@ -53,6 +53,7 @@ struct rcar_du_output_routing {
> * @routes: array of CRTC to output routes, indexed by output
> (RCAR_DU_OUTPUT_*)
> * @num_lvds: number of internal LVDS encoders
> * @dpll_mask: bit mask of DU channels equipped with a DPLL
> + * @lvds_clk_mask: bitmask of channels that can use the LVDS clock as dot
> clock
> */
> struct rcar_du_device_info {
> unsigned int gen;
> @@ -62,6 +63,7 @@ struct rcar_du_device_info {
> struct rcar_du_output_routing routes[RCAR_DU_OUTPUT_MAX];
> unsigned int num_lvds;
> unsigned int dpll_mask;
> + unsigned int lvds_clk_mask;
> };
>
> #define RCAR_DU_MAX_CRTCS4
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_group.c
> b/drivers/gpu/drm/rcar-du/rcar_du_group.c
> index ef2c177afb6d..4c62841eff2f 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_group.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_group.c
> @@ -89,6 +89,54 @@ static void rcar_du_group_setup_defr8(struct rcar_du_group
> *rgrp)
> rcar_du_group_write(rgrp, DEFR8, defr8);
> }
>
> +static void rcar_du_group_setup_didsr(struct rcar_du_group *rgrp)
> +{
> + struct rcar_du_device *rcdu = rgrp->dev;
> + struct rcar_du_crtc *rcrtc;
> + unsigned int num_crtcs = 0;
> + unsigned int i;
> + u32 didsr;
> +
> + /*
> + * Configure input dot clock routing with a hardcoded configuration. If
> + * the DU channel can use the LVDS encoder output clock as the dot
> + * clock, do so. Otherwise route DU_DOTCLKINn signal to DUn.
> + *
> + * Each channel can then select between the dot clock configured here
> + * and the clock provided by the CPG through the ESCR register.
> + */
> + if (rcdu->info->gen < 3 && rgrp->index == 0) {
> + /*
> + * On Gen2 a single register in the first group controls dot
> + * clock selection for all channels.
> + */
> + rcrtc = rcdu->crtcs;
> + num_crtcs =
Re: [PATCH v2 08/16] drm: rcar-du: Enable configurable DPAD0 routing on Gen3
Hi Laurent,
On Fri, Sep 14, 2018 at 12:10:38PM +0300, Laurent Pinchart wrote:
> All Gen3 SoCs supported so far have a fixed association between DPAD0
> and DU channels, which led to hardcoding that association when writing
> the corresponding hardware register. The D3 and E3 will break that
> mechanism as DPAD0 can be dynamically connected to either DU0 or DU1.
>
> Make DPAD0 routing dynamic on Gen3. To ensure a valid hardware
> configuration when the DU starts without the RGB output enabled, DPAD0
> is associated at initialization time to the first DU channel that it can
> be connected to. This makes no change on Gen2 as all Gen2 SoCs can
> connected DPAD0 to DU0, which is the current implicit default value.
>
> As the DPAD0 source is always 0 when a single source is possible on
> Gen2, we can also simplify the Gen2 code in the same function to remove
> a conditional check.
>
> Signed-off-by: Laurent Pinchart
> Tested-by: Jacopo Mondi
Please add my:
Reviewed-by: Jacopo Mondi
> ---
> drivers/gpu/drm/rcar-du/rcar_du_group.c | 17 ++---
> drivers/gpu/drm/rcar-du/rcar_du_kms.c | 12
> 2 files changed, 18 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_group.c
> b/drivers/gpu/drm/rcar-du/rcar_du_group.c
> index 4c62841eff2f..f38703e7a10d 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_group.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_group.c
> @@ -56,8 +56,6 @@ static void rcar_du_group_setup_pins(struct rcar_du_group
> *rgrp)
> static void rcar_du_group_setup_defr8(struct rcar_du_group *rgrp)
> {
> struct rcar_du_device *rcdu = rgrp->dev;
> - unsigned int possible_crtcs =
> - rcdu->info->routes[RCAR_DU_OUTPUT_DPAD0].possible_crtcs;
> u32 defr8 = DEFR8_CODE;
>
> if (rcdu->info->gen < 3) {
> @@ -69,21 +67,18 @@ static void rcar_du_group_setup_defr8(struct
> rcar_du_group *rgrp)
>* DU instances that support it.
>*/
> if (rgrp->index == 0) {
> - if (possible_crtcs > 1)
> - defr8 |= DEFR8_DRGBS_DU(rcdu->dpad0_source);
> + defr8 |= DEFR8_DRGBS_DU(rcdu->dpad0_source);
> if (rgrp->dev->vspd1_sink == 2)
> defr8 |= DEFR8_VSCS;
> }
> } else {
> /*
> - * On Gen3 VSPD routing can't be configured, but DPAD routing
> - * needs to be set despite having a single option available.
> + * On Gen3 VSPD routing can't be configured, and DPAD routing
> + * is set in the group corresponding to the DPAD output (no Gen3
> + * SoC has multiple DPAD sources belonging to separate groups).
>*/
> - unsigned int rgb_crtc = ffs(possible_crtcs) - 1;
> - struct rcar_du_crtc *crtc = >crtcs[rgb_crtc];
> -
> - if (crtc->index / 2 == rgrp->index)
> - defr8 |= DEFR8_DRGBS_DU(crtc->index);
> + if (rgrp->index == rcdu->dpad0_source / 2)
> + defr8 |= DEFR8_DRGBS_DU(rcdu->dpad0_source);
> }
>
> rcar_du_group_write(rgrp, DEFR8, defr8);
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> index ed7fa3204892..bd01197700c5 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> @@ -501,6 +501,7 @@ int rcar_du_modeset_init(struct rcar_du_device *rcdu)
> struct drm_device *dev = rcdu->ddev;
> struct drm_encoder *encoder;
> struct drm_fbdev_cma *fbdev;
> + unsigned int dpad0_sources;
> unsigned int num_encoders;
> unsigned int num_groups;
> unsigned int swindex;
> @@ -613,6 +614,17 @@ int rcar_du_modeset_init(struct rcar_du_device *rcdu)
> encoder->possible_clones = (1 << num_encoders) - 1;
> }
>
> + /*
> + * Initialize the default DPAD0 source to the index of the first DU
> + * channel that can be connected to DPAD0. The exact value doesn't
> + * matter as it should be overwritten by mode setting for the RGB
> + * output, but it is nonetheless required to ensure a valid initial
> + * hardware configuration on Gen3 where DU0 can't always be connected to
> + * DPAD0.
> + */
> + dpad0_sources = rcdu->info->routes[RCAR_DU_OUTPUT_DPAD0].possible_crtcs;
> + rcdu->dpad0_source = ffs(dpad0_sources) - 1;
> +
> drm_mode_config_reset(dev);
>
> drm_kms_helper_poll_init(dev);
> --
> Regards,
>
> Laurent Pinchart
>
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 06/16] drm: rcar-du: Perform the initial CRTC setup from rcar_du_crtc_get()
Hi Laurent,
On Fri, Sep 14, 2018 at 12:10:36PM +0300, Laurent Pinchart wrote:
> The rcar_du_crtc_get() function is always immediately followed by a call
> to rcar_du_crtc_setup(). Call the later from the former to simplify the
> code, and add a comment to explain how the get and put calls are
> balanced.
>
> Signed-off-by: Laurent Pinchart
> Tested-by: Jacopo Mondi
Please add my
Reviewed-by: Jacopo Mondi
> ---
> drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 107
> +
> 1 file changed, 56 insertions(+), 51 deletions(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> index 6288b9ad9e24..c89751c26f9c 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> @@ -66,39 +66,6 @@ static void rcar_du_crtc_clr_set(struct rcar_du_crtc
> *rcrtc, u32 reg,
> rcar_du_write(rcdu, rcrtc->mmio_offset + reg, (value & ~clr) | set);
> }
>
> -static int rcar_du_crtc_get(struct rcar_du_crtc *rcrtc)
> -{
> - int ret;
> -
> - ret = clk_prepare_enable(rcrtc->clock);
> - if (ret < 0)
> - return ret;
> -
> - ret = clk_prepare_enable(rcrtc->extclock);
> - if (ret < 0)
> - goto error_clock;
> -
> - ret = rcar_du_group_get(rcrtc->group);
> - if (ret < 0)
> - goto error_group;
> -
> - return 0;
> -
> -error_group:
> - clk_disable_unprepare(rcrtc->extclock);
> -error_clock:
> - clk_disable_unprepare(rcrtc->clock);
> - return ret;
> -}
> -
> -static void rcar_du_crtc_put(struct rcar_du_crtc *rcrtc)
> -{
> - rcar_du_group_put(rcrtc->group);
> -
> - clk_disable_unprepare(rcrtc->extclock);
> - clk_disable_unprepare(rcrtc->clock);
> -}
> -
> /*
> -
> * Hardware Setup
> */
> @@ -546,6 +513,51 @@ static void rcar_du_crtc_setup(struct rcar_du_crtc
> *rcrtc)
> drm_crtc_vblank_on(>crtc);
> }
>
> +static int rcar_du_crtc_get(struct rcar_du_crtc *rcrtc)
> +{
> + int ret;
> +
> + /*
> + * Guard against double-get, as the function is called from both the
> + * .atomic_enable() and .atomic_begin() handlers.
> + */
> + if (rcrtc->initialized)
> + return 0;
> +
> + ret = clk_prepare_enable(rcrtc->clock);
> + if (ret < 0)
> + return ret;
> +
> + ret = clk_prepare_enable(rcrtc->extclock);
> + if (ret < 0)
> + goto error_clock;
> +
> + ret = rcar_du_group_get(rcrtc->group);
> + if (ret < 0)
> + goto error_group;
> +
> + rcar_du_crtc_setup(rcrtc);
> + rcrtc->initialized = true;
> +
> + return 0;
> +
> +error_group:
> + clk_disable_unprepare(rcrtc->extclock);
> +error_clock:
> + clk_disable_unprepare(rcrtc->clock);
> + return ret;
> +}
> +
> +static void rcar_du_crtc_put(struct rcar_du_crtc *rcrtc)
> +{
> + rcar_du_group_put(rcrtc->group);
> +
> + clk_disable_unprepare(rcrtc->extclock);
> + clk_disable_unprepare(rcrtc->clock);
> +
> + rcrtc->initialized = false;
> +}
> +
> static void rcar_du_crtc_start(struct rcar_du_crtc *rcrtc)
> {
> bool interlaced;
> @@ -639,16 +651,7 @@ static void rcar_du_crtc_atomic_enable(struct drm_crtc
> *crtc,
> {
> struct rcar_du_crtc *rcrtc = to_rcar_crtc(crtc);
>
> - /*
> - * If the CRTC has already been setup by the .atomic_begin() handler we
> - * can skip the setup stage.
> - */
> - if (!rcrtc->initialized) {
> - rcar_du_crtc_get(rcrtc);
> - rcar_du_crtc_setup(rcrtc);
> - rcrtc->initialized = true;
> - }
> -
> + rcar_du_crtc_get(rcrtc);
> rcar_du_crtc_start(rcrtc);
> }
>
> @@ -667,7 +670,6 @@ static void rcar_du_crtc_atomic_disable(struct drm_crtc
> *crtc,
> }
> spin_unlock_irq(>dev->event_lock);
>
> - rcrtc->initialized = false;
> rcrtc->outputs = 0;
> }
>
> @@ -680,14 +682,17 @@ static void rcar_du_crtc_atomic_begin(struct drm_crtc
> *crtc,
>
> /*
>* If a mode set is in progress we can be called with the CRTC disabled.
> - * We then need to first setup the CRTC in order to configure planes.
> - * The .atomic_enable() handler will notice and skip the CRTC setup.
> + * We thus need to first get and setup the CRTC in order to configure
> + * planes. We must *not* put the CRTC in .atomic_flush(), as it must be
> + * kept awake until the .atomic_enable() call that will follow. The get
> + * operation in .atomic_enable() will in that case be a no-op, and the
> + * CRTC will be put later in .atomic_disable().
> + *
> + * If a mode set is not in progress the CRTC is enabled, and the
> + * following get call will be a no-op. There is thus no need to belance
> + * it in .atomic_flush() either.
>*/
> - if (!rcrtc->initialized) {
> - rcar_du_crtc_get(rcrtc);
> -
Re: [PATCH v2 05/16] drm: rcar-du: lvds: D3/E3 support
Hi Laurent,
On Fri, Sep 14, 2018 at 12:10:35PM +0300, Laurent Pinchart wrote:
> The LVDS encoders in the D3 and E3 SoCs differ significantly from those
> in the other R-Car Gen3 family members:
>
> - The LVDS PLL architecture is more complex and requires computing PLL
> parameters manually.
> - The PLL uses external clocks as inputs, which need to be retrieved
> from DT.
> - In addition to the different PLL setup, the startup sequence has
> changed *again* (seems someone had trouble making his/her mind).
>
> Supporting all this requires DT bindings extensions for external clocks,
> brand new PLL setup code, and a few quirks to handle the differences in
> the startup sequence.
>
> The implementation doesn't support all hardware features yet, namely
>
> - Using the LV[01] clocks generated by the CPG as PLL input.
> - Providing the LVDS PLL clock to the DU for use with the RGB output.
>
> Those features can be added later when the need will arise.
>
> Signed-off-by: Laurent Pinchart
> Tested-by: Jacopo Mondi
please add my
Reviewed-by: Jacopo Mondi
> ---
> Changes since v1:
>
> - Don't compile-out debug code based on DEBUG and CONFIG_DYNAMIC_DEBUG
> - Test all three input clocks (DOTCLKIN[01] and EXTAL) and pick the best
> one
> ---
> drivers/gpu/drm/rcar-du/rcar_lvds.c | 355
> +++
> drivers/gpu/drm/rcar-du/rcar_lvds_regs.h | 43 +++-
> 2 files changed, 351 insertions(+), 47 deletions(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c
> b/drivers/gpu/drm/rcar-du/rcar_lvds.c
> index ce0eb68c3416..23e7743144c8 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
> @@ -24,6 +24,8 @@
>
> #include "rcar_lvds_regs.h"
>
> +struct rcar_lvds;
> +
> /* Keep in sync with the LVDCR0.LVMD hardware register values. */
> enum rcar_lvds_mode {
> RCAR_LVDS_MODE_JEIDA = 0,
> @@ -31,14 +33,16 @@ enum rcar_lvds_mode {
> RCAR_LVDS_MODE_VESA = 4,
> };
>
> -#define RCAR_LVDS_QUIRK_LANES(1 << 0)/* LVDS lanes 1 and 3
> inverted */
> -#define RCAR_LVDS_QUIRK_GEN2_PLLCR (1 << 1) /* LVDPLLCR has gen2 layout */
> -#define RCAR_LVDS_QUIRK_GEN3_LVEN (1 << 2) /* LVEN bit needs to be set */
> - /* on R8A77970/R8A7799x */
> +#define RCAR_LVDS_QUIRK_LANESBIT(0) /* LVDS lanes 1 and 3
> inverted */
> +#define RCAR_LVDS_QUIRK_GEN3_LVENBIT(1) /* LVEN bit needs to be set on
> R8A77970/R8A7799x */
> +#define RCAR_LVDS_QUIRK_PWD BIT(2) /* PWD bit available (all of
> Gen3 but E3) */
> +#define RCAR_LVDS_QUIRK_EXT_PLL BIT(3) /* Has extended PLL */
> +#define RCAR_LVDS_QUIRK_DUAL_LINKBIT(4) /* Supports dual-link operation
> */
>
> struct rcar_lvds_device_info {
> unsigned int gen;
> unsigned int quirks;
> + void (*pll_setup)(struct rcar_lvds *lvds, unsigned int freq);
> };
>
> struct rcar_lvds {
> @@ -52,7 +56,11 @@ struct rcar_lvds {
> struct drm_panel *panel;
>
> void __iomem *mmio;
> - struct clk *clock;
> + struct {
> + struct clk *mod;/* CPG module clock */
> + struct clk *extal; /* External clock */
> + struct clk *dotclkin[2];/* External DU clocks */
> + } clocks;
> bool enabled;
>
> struct drm_display_mode display_mode;
> @@ -128,33 +136,212 @@ static const struct drm_connector_funcs
> rcar_lvds_conn_funcs = {
> };
>
> /*
> -
> - * Bridge
> + * PLL Setup
> */
>
> -static u32 rcar_lvds_lvdpllcr_gen2(unsigned int freq)
> +static void rcar_lvds_pll_setup_gen2(struct rcar_lvds *lvds, unsigned int
> freq)
> {
> - if (freq < 39000)
> - return LVDPLLCR_CEEN | LVDPLLCR_COSEL | LVDPLLCR_PLLDLYCNT_38M;
> - else if (freq < 61000)
> - return LVDPLLCR_CEEN | LVDPLLCR_COSEL | LVDPLLCR_PLLDLYCNT_60M;
> - else if (freq < 121000)
> - return LVDPLLCR_CEEN | LVDPLLCR_COSEL | LVDPLLCR_PLLDLYCNT_121M;
> + u32 val;
> +
> + if (freq < 3900)
> + val = LVDPLLCR_CEEN | LVDPLLCR_COSEL | LVDPLLCR_PLLDLYCNT_38M;
> + else if (freq < 6100)
> + val = LVDPLLCR_CEEN | LVDPLLCR_COSEL | LVDPLLCR_PLLDLYCNT_60M;
> + else if (freq < 12100)
> + val = LVDPLLCR_CEEN | LVDPLLCR_COSEL | LVDPLLCR_PLLDLYCNT_121M;
> else
> - return LVDPLLCR_PLLDLYCNT_150M;
> + val = LVDPLLCR_PLLDLYCNT_150M;
> +
> + rcar_lvds_write(lvds, LVDPLLCR, val);
> }
>
> -static u32 rcar_lvds_lvdpllcr_gen3(unsigned int freq)
> +static void rcar_lvds_pll_setup_gen3(struct rcar_lvds *lvds, unsigned int
> freq)
> {
> - if (freq < 42000)
> - return LVDPLLCR_PLLDIVCNT_42M;
> - else if (freq < 85000)
> - return LVDPLLCR_PLLDIVCNT_85M;
> - else if (freq < 128000)
> - return
[Bug 201163] amdgpu: carrizo: Stalls using vaapi encoder
https://bugzilla.kernel.org/show_bug.cgi?id=201163 --- Comment #5 from Ricardo Ribalda (ricardo.riba...@gmail.com) --- # cat /sys/kernel/debug/dri/0/amdgpu_firmware_info VCE feature version: 0, firmware version: 0x34040300 UVD feature version: 0, firmware version: 0x015b0b00 MC feature version: 0, firmware version: 0x ME feature version: 46, firmware version: 0x00a1 PFP feature version: 46, firmware version: 0x00eb CE feature version: 46, firmware version: 0x0086 RLC feature version: 1, firmware version: 0x009c RLC SRLC feature version: 0, firmware version: 0x RLC SRLG feature version: 0, firmware version: 0x RLC SRLS feature version: 0, firmware version: 0x MEC feature version: 46, firmware version: 0x02c1 MEC2 feature version: 46, firmware version: 0x02c1 SOS feature version: 0, firmware version: 0x ASD feature version: 0, firmware version: 0x SMC feature version: 0, firmware version: 0x1238 SDMA0 feature version: 0, firmware version: 0x0022 SDMA1 feature version: 0, firmware version: 0x0022 VCN feature version: 0, firmware version: 0x VBIOS version: 113-C75100-028 -- 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 201163] amdgpu: carrizo: Stalls using vaapi encoder
https://bugzilla.kernel.org/show_bug.cgi?id=201163 --- Comment #4 from Ricardo Ribalda (ricardo.riba...@gmail.com) --- Adding umr output. Obtained with this command: sudo umr -O verbose,follow_ib -R gfx[0:2047] sudo umr -O many,bits -r *.gfx80.mmGRBM_STATUS sudo umr -O many,bits -r *.gfx80.HEADER_DUMP sudo umr -O many,bits -r *.gfx80.CP_EOP Adding trace output. Obtained with this command: trace-cmd record -e dma_fence:* -e amdgpu:* -e gpu_scheduler:* Also dmesg and glxinfo -- 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 05/16] drm: rcar-du: lvds: D3/E3 support
Hi Ulrich,
On Monday, 17 September 2018 13:53:58 EEST Ulrich Hecht wrote:
> > On September 14, 2018 at 11:10 AM Laurent Pinchart wrote:
> >
> > The LVDS encoders in the D3 and E3 SoCs differ significantly from those
> > in the other R-Car Gen3 family members:
> >
> > - The LVDS PLL architecture is more complex and requires computing PLL
> > parameters manually.
> >
> > - The PLL uses external clocks as inputs, which need to be retrieved
> > from DT.
> >
> > - In addition to the different PLL setup, the startup sequence has
> > changed *again* (seems someone had trouble making his/her mind).
> >
> > Supporting all this requires DT bindings extensions for external clocks,
> > brand new PLL setup code, and a few quirks to handle the differences in
> > the startup sequence.
> >
> > The implementation doesn't support all hardware features yet, namely
> >
> > - Using the LV[01] clocks generated by the CPG as PLL input.
> > - Providing the LVDS PLL clock to the DU for use with the RGB output.
> >
> > Those features can be added later when the need will arise.
> >
> > Signed-off-by: Laurent Pinchart
> >
> > Tested-by: Jacopo Mondi
> > ---
> > Changes since v1:
> >
> > - Don't compile-out debug code based on DEBUG and CONFIG_DYNAMIC_DEBUG
> > - Test all three input clocks (DOTCLKIN[01] and EXTAL) and pick the best
> > one
> >
> > ---
> >
> > drivers/gpu/drm/rcar-du/rcar_lvds.c | 355 ++
> > drivers/gpu/drm/rcar-du/rcar_lvds_regs.h | 43 +++-
> > 2 files changed, 351 insertions(+), 47 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c
> > b/drivers/gpu/drm/rcar-du/rcar_lvds.c index ce0eb68c3416..23e7743144c8
> > 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
[snip]
> > +static void rcar_lvds_d3_e3_pll_calc(struct rcar_lvds *lvds, struct clk
> > *clk,
> > +unsigned long target, struct pll_info *pll,
> > +u32 clksel)
> > +{
> > + unsigned long output;
> > + unsigned long fin;
> > + unsigned int m_min;
> > + unsigned int m_max;
> > + unsigned int m;
> > + int error;
> > +
> > + if (!clk)
> > + return;
> > +
> > + /*
> > +* The LVDS PLL is made of a pre-divider and a multiplier (strangerly
>
> strangely
Will be fixed in v2.
> > +* enough called M and N respectively), followed by a post-divider E.
> > +*
> > +* ,-. ,-. ,-. ,-.
> > +* Fin --> | 1/M | -Fpdf-> | PFD | --> | VCO | -Fvco-> | 1/E | --> Fout
> > +* `-' ,-> | | `-' | `-'
> > +* | `-' |
> > +* | ,-. |
> > +* ` | 1/N | <---'
> > +* `-'
> > +*
> > +* The clock output by the PLL is then further divided by a
> > programmable
> > +* divider DIV to achieve the desired target frequency. Finally, an
> > +* optional fixed /7 divider is used to convert the bit clock to a
> > pixel
> > +* clock (as LVDS transmits 7 bits per lane per clock sample).
> > +*
> > +* ,---. ,-. |\
> > +* Fout --> | 1/DIV | --> | 1/7 | --> | |
> > +* `---' | `-' | | --> dot clock
> > +* `> | |
> > +*|/
> > +*
> > +* The /7 divider is optional when the LVDS PLL is used to generate a
> > +* dot clock for the DU RGB output, without using the LVDS encoder. We
> > +* don't support this configuration yet.
> > +*
> > +* The PLL allowed input frequency range is 12 MHz to 192 MHz.
> > +*/
> > +
> > + fin = clk_get_rate(clk);
> > + if (fin < 1200 || fin > 19200)
> > + return;
> > +
> > + /*
> > +* The comparison frequency range is 12 MHz to 24 MHz, which limits the
> > +* allowed values for the pre-divider M (normal range 1-8).
> > +*
> > +* Fpfd = Fin / M
> > +*/
> > + m_min = max_t(unsigned int, 1, DIV_ROUND_UP(fin, 2400));
> > + m_max = min_t(unsigned int, 8, fin / 1200);
> > +
> > + for (m = m_min; m <= m_max; ++m) {
> > + unsigned long fpfd;
> > + unsigned int n_min;
> > + unsigned int n_max;
> > + unsigned int n;
> > +
> > + /*
> > +* The VCO operating range is 900 Mhz to 1800 MHz, which limits
> > +* the allowed values for the multiplier N (normal range
> > +* 60-120).
> > +*
> > +* Fvco = Fin * N / M
> > +*/
> > + fpfd = fin / m;
> > + n_min = max_t(unsigned int, 60, DIV_ROUND_UP(9, fpfd));
> > + n_max = min_t(unsigned int, 120, 18 / fpfd);
> > +
> > + for (n = n_min; n < n_max; ++n) {
> > +
[Bug 201163] amdgpu: carrizo: Stalls using vaapi encoder
https://bugzilla.kernel.org/show_bug.cgi?id=201163 --- Comment #3 from Ricardo Ribalda (ricardo.riba...@gmail.com) --- Created attachment 278601 --> https://bugzilla.kernel.org/attachment.cgi?id=278601=edit umr -- 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 201163] amdgpu: carrizo: Stalls using vaapi encoder
https://bugzilla.kernel.org/show_bug.cgi?id=201163 --- Comment #2 from Ricardo Ribalda (ricardo.riba...@gmail.com) --- Created attachment 278599 --> https://bugzilla.kernel.org/attachment.cgi?id=278599=edit trace-cmd -- 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 201163] amdgpu: carrizo: Stalls using vaapi encoder
https://bugzilla.kernel.org/show_bug.cgi?id=201163 --- Comment #1 from Ricardo Ribalda (ricardo.riba...@gmail.com) --- Created attachment 278597 --> https://bugzilla.kernel.org/attachment.cgi?id=278597=edit 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
[Bug 201163] New: amdgpu: carrizo: Stalls using vaapi encoder
https://bugzilla.kernel.org/show_bug.cgi?id=201163 Bug ID: 201163 Summary: amdgpu: carrizo: Stalls using vaapi encoder Product: Drivers Version: 2.5 Kernel Version: 4.18.0 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: ricardo.riba...@gmail.com Regression: No Created attachment 278595 --> https://bugzilla.kernel.org/attachment.cgi?id=278595=edit glxinfo This command: gst-launch-1.0 v4l2src io-mode=4 ! vaapih264enc ! fakesink dump=1 results in a stall non recoverable using ctrl+c and the following kernel message [ 1617.944590] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring vce0 timeout, last signaled seq=4, last emitted seq=6 [ 1617.944628] [drm] IP block:vce_v3_0 is hung! [ 1617.944632] [drm] GPU recovery disabled. -- 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 107955] AMDGPU driver keeps reloading on hybrid graphics system causing stuttering.
https://bugs.freedesktop.org/show_bug.cgi?id=107955 --- Comment #11 from Mike Lothian --- I did a quick grep on libraries that contain drmGetDevice and drmGetDevice2 and did a diff -Binary file /usr/lib64/libva-drm.so.2.200.0 matches @@ -6 +4,0 @@ -Binary file /usr/lib64/libva-wayland.so.2.200.0 matches @@ -13,3 +10,0 @@ -Binary file /usr/lib64/xorg/modules/drivers/modesetting_drv.so matches -Binary file /usr/lib64/xorg/modules/drivers/amdgpu_drv.so matches -Binary file /usr/lib64/xorg/modules/libglamoregl.so matches My guess they're the most likely candidates for this happening -- 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 107955] AMDGPU driver keeps reloading on hybrid graphics system causing stuttering.
https://bugs.freedesktop.org/show_bug.cgi?id=107955 Mike Lothian changed: What|Removed |Added CC||m...@fireburn.co.uk --- Comment #10 from Mike Lothian --- I'm not seeing stuttering, but I do see AMDGPU loading up each time I play a video on MPV or Chromium The last time I saw this something was using drmGetDevice rather than drmGetDevice2 -- 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] drm: rcar-du: Revert "drm: rcar-du: Use __drm_atomic_helper_plane_reset instead of copying the logic"
Hi Kieran,
On Mon, Sep 17, 2018 at 11:56:23AM +0100, Kieran Bingham wrote:
> Hi Alexandru,
>
> On 17/09/18 10:10, Alexandru-Cosmin Gheorghe wrote:
> > Hi Kieran,
> >
> > Sorry for that and thanks for getting to the bottom of it.
>
> No worries,
>
>
> > On Fri, Sep 14, 2018 at 11:28:05PM +0100, Kieran Bingham wrote:
> >> Hi Laurent,
> >>
> >> I've looked through a bit further to try to understand this issue and I
> >> think I have identified a possible/probable cause.
> >>
> >> Before commit 161ad653d6c9, we *always* set the plane->state->alpha as
> >> DRM_BLEND_ALPHA_OPAQUE. (0x)
> >>
> >> After this commit, the __drm_atomic_helper_plane_reset() call will only
> >> set state->alpha to 0x if the alpha_property is set:
> >>
> >> if (plane->alpha_property)
> >> state->alpha = plane->alpha_property->values[1];
> >>
> >> Then the state->alpha value is always referenced in
> >> rcar_du_vsp_plane_setup() and passed to the VSP for that layer.
> >>
> >>
> >> We can see in rcar_du_planes_init(), that all OVERLAY planes are
> >> configured to have this propery with a call to
> >> drm_plane_create_alpha_property(>plane); however - the PRIMARY
> >> plane is skipped over before setting this.
> >>
> >>
> >> I believe I recall seeing that the kms-test-planeposition.py
> >> successfully showed other planes which were not the back one (I'm now
> >> going from hazy memory of this afternoon - but I am fairly sure I saw this)
> >>
> >>
> >> This implies that the primary planes are being incorrectly configured -
> >> but the overlay planes are still functioning as expected.
> >>
> >> So I believe we could move the call to create the alpha property:
> >>drm_plane_create_alpha_property(>plane);
> >>
> >> to occur before the if (type == DRM_PLANE_TYPE_PRIMARY) continue;
> >> statement.
> >>
> >
> > I don't see any reson why the primary plane shouldn't advertise an
> > alpha as well.
>
>
> OK - so I think we perhaps should make sure that we enable alpha for our
> primary plane in rcar-du.
>
>
> >> It may or may not make sense to have alpha blending support on the
> >> PRIMARY plane. At the risk of sounding silly - can we have anything else
> >> behind the PRIMARY plane ? (I doubt this, I don't think we have any
> >> extra layers hiding anywhere)
> >
> > I think the same question could apply to situations where PRIMARY is
> > disabled and you have just one OVERLAY plane enabled.
> >
> >>
> >> Otherwise, I think we would need to intercept the configuration of the
> >> alpha blending and make sure that all PRIMARY planes are configured to
> >> be fully opaque in our layers. I think this is happening in
> >> rcar_du_vsp_plane_setup().
> >>
> >> But rather than put in a conditional in there, I think I'd rather just
> >> initialise the plane->state->alpha = DRM_BLEND_ALPHA_OPAQUE in our
> >> rcar_du_vsp_plane_reset() call and be done with it.
> >
> > I think you could do more and just go in
> > __drm_atomic_helper_plane_reset and always initializes plane->alpha
> > with DRM_BLEND_ALPHA_OPAQUE, this way nobody else hits this problem.
>
> I think this sounds like a good thing too.
>
> Is DRM_BLEND_ALPHA_OPAQUE a suitable initial value for all of the other
> users of the helper ?
>
> I suspect the answer is yes, but I'll try to do a bit of digging through
> the other drivers tomorrow.
>
Yes, but it doesn't hurt for another pair of eyes to have a look.
> I presume we could then just remove the conditional check and always
> initialise to OPAQUE ...
>
> Or otherwise perhaps maybe initialising as an 'else' if no alpha
> property is provided.
>
> --
> Regards
>
> Kieran
>
>
>
>
>
>
> >>
> >> Anyway - just some musings and thoughts at this stage, we can
> >> investigate in more detail next week.
> >>
> >> --
> >> Regards
> >>
> >> Kieran
> >>
> >>
> >> On 14/09/18 21:09, Kieran Bingham wrote:
> >>> Commit: 161ad653d6c9 ("drm: rcar-du: Use __drm_atomic_helper_plane_reset
> >>> instead of copying the logic") causes a regression in the R-Car DU
> >>> display driver, and prevents any output from being displayed.
> >>>
> >>> The display appears to function correctly but only a black screen is
> >>> ever visible.
> >>>
> >>> Revert the commit.
> >>>
> >>> Signed-off-by: Kieran Bingham
> >>>
> >>> ---
> >>>
> >>> Looking through the code, the reason for this issue isn't particularly
> >>> obvious - and will need some further exploration, which I can't look at
> >>> until Tuesday. So I'm posting this revert patch to
> >>>
> >>> A) Report the issue
> >>> B) Provide a temporary fix
> >>>
> >>> I suspect either the initial alpha value is not set correctly or setting
> >>>
> >>> state->pixel_blend_mode = DRM_MODE_BLEND_PREMULTI;
> >>>
> >>> causes some side effect perhaps. There's not much else that could be
> >>> different between the helper, and the original code.
> >>>
> >>> drivers/gpu/drm/rcar-du/rcar_du_plane.c | 6 --
> >>> drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 5
Re: [PATCH v2 04/16] drm: bridge: thc63: Restrict modes based on hardware operating frequency
Hi Ulrich,
On Monday, 17 September 2018 13:53:43 EEST Ulrich Hecht wrote:
> > On September 14, 2018 at 11:10 AM Laurent Pinchart wrote:
> >
> > The THC63LVD1024 is restricted to a pixel clock frequency in the range
> > of 8 to 135 MHz. Implement the bridge .mode_valid() operation
> > accordingly.
> >
> > Signed-off-by: Laurent Pinchart
> >
> > Reviewed-by: Andrzej Hajda
> > Tested-by: Jacopo Mondi
> > ---
> >
> > drivers/gpu/drm/bridge/thc63lvd1024.c | 18 ++
> > 1 file changed, 18 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/bridge/thc63lvd1024.c
> > b/drivers/gpu/drm/bridge/thc63lvd1024.c index c8b9edd5a7f4..63609ba16b6d
> > 100644
> > --- a/drivers/gpu/drm/bridge/thc63lvd1024.c
> > +++ b/drivers/gpu/drm/bridge/thc63lvd1024.c
> > @@ -45,6 +45,23 @@ static int thc63_attach(struct drm_bridge *bridge)
> > return drm_bridge_attach(bridge->encoder, thc63->next, bridge);
> > }
> >
> > +static enum drm_mode_status thc63_mode_valid(struct drm_bridge *bridge,
> > + const struct drm_display_mode *mode)
> > +{
> > + /*
> > +* The THC63LVD0124 clock frequency range is 8 to 135 MHz in single-in,
>
> That should be THC63LVD1024.
Will be fixed in v3.
> > +* single-out mode.
>
> For the input clock (that's what we're talking about, right?), that also
> applies to single-in/dual-out. Maybe just omit the "single-out" clause?
Good point, I'll change that in v3.
> > Note that the limits depends on the mode and will
> > +* need to be adjusted accordingly.
> > +*/
>
> I don't quite understand. Does that refer to the THC63 mode, or the DRM
> mode?
This refers to the THC63 mode, I'll clarify this in v3 as well.
> > + if (mode->clock < 8000)
> > + return MODE_CLOCK_LOW;
> > +
> > + if (mode->clock > 135000)
> > + return MODE_CLOCK_HIGH;
> > +
> > + return MODE_OK;
> > +}
> > +
> > static void thc63_enable(struct drm_bridge *bridge)
> > {
> > struct thc63_dev *thc63 = to_thc63(bridge);
> > @@ -77,6 +94,7 @@ static void thc63_disable(struct drm_bridge *bridge)
> >
> > static const struct drm_bridge_funcs thc63_bridge_func = {
> > .attach = thc63_attach,
> > + .mode_valid = thc63_mode_valid,
> > .enable = thc63_enable,
> > .disable = thc63_disable,
> > };
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] list: introduce list_bulk_move_tail helper
Move all entries between @first and including @last before @head.
This is useful for LRU lists where a whole block of entries should be
moved to the end of the list.
Used as a band aid in TTM, but better placed in the common list headers.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 25 +
include/linux/list.h | 23 +++
2 files changed, 28 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index b2a33bf1ef10..26b889f86670 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -247,20 +247,6 @@ void ttm_bo_move_to_lru_tail(struct ttm_buffer_object *bo,
}
EXPORT_SYMBOL(ttm_bo_move_to_lru_tail);
-static void ttm_list_move_bulk_tail(struct list_head *list,
- struct list_head *first,
- struct list_head *last)
-{
- first->prev->next = last->next;
- last->next->prev = first->prev;
-
- list->prev->next = first;
- first->prev = list->prev;
-
- last->next = list;
- list->prev = last;
-}
-
void ttm_bo_bulk_move_lru_tail(struct ttm_lru_bulk_move *bulk)
{
unsigned i;
@@ -276,8 +262,8 @@ void ttm_bo_bulk_move_lru_tail(struct ttm_lru_bulk_move
*bulk)
reservation_object_assert_held(pos->last->resv);
man = >first->bdev->man[TTM_PL_TT];
- ttm_list_move_bulk_tail(>lru[i], >first->lru,
- >last->lru);
+ list_bulk_move_tail(>lru[i], >first->lru,
+ >last->lru);
}
for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
@@ -291,8 +277,8 @@ void ttm_bo_bulk_move_lru_tail(struct ttm_lru_bulk_move
*bulk)
reservation_object_assert_held(pos->last->resv);
man = >first->bdev->man[TTM_PL_VRAM];
- ttm_list_move_bulk_tail(>lru[i], >first->lru,
- >last->lru);
+ list_bulk_move_tail(>lru[i], >first->lru,
+ >last->lru);
}
for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
@@ -306,8 +292,7 @@ void ttm_bo_bulk_move_lru_tail(struct ttm_lru_bulk_move
*bulk)
reservation_object_assert_held(pos->last->resv);
lru = >first->bdev->glob->swap_lru[i];
- ttm_list_move_bulk_tail(lru, >first->swap,
- >last->swap);
+ list_bulk_move_tail(lru, >first->swap, >last->swap);
}
}
EXPORT_SYMBOL(ttm_bo_bulk_move_lru_tail);
diff --git a/include/linux/list.h b/include/linux/list.h
index de04cc5ed536..edb7628e46ed 100644
--- a/include/linux/list.h
+++ b/include/linux/list.h
@@ -183,6 +183,29 @@ static inline void list_move_tail(struct list_head *list,
list_add_tail(list, head);
}
+/**
+ * list_bulk_move_tail - move a subsection of a list to its tail
+ * @head: the head that will follow our entry
+ * @first: first entry to move
+ * @last: last entry to move, can be the same as first
+ *
+ * Move all entries between @first and including @last before @head.
+ * All three entries must belong to the same linked list.
+ */
+static inline void list_bulk_move_tail(struct list_head *head,
+ struct list_head *first,
+ struct list_head *last)
+{
+ first->prev->next = last->next;
+ last->next->prev = first->prev;
+
+ head->prev->next = first;
+ first->prev = head->prev;
+
+ last->next = head;
+ head->prev = last;
+}
+
/**
* list_is_last - tests whether @list is the last entry in list @head
* @list: the entry to test
--
2.14.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107956] [CI][SHARDS] igt@kms_busy@extended_*_render-[abc] - dmesg-warn - Asynchronous wait on fence i915:kms_busy\[\d+\]/0:1 timed out \(hint:intel_atomic_commit_ready
https://bugs.freedesktop.org/show_bug.cgi?id=107956 Lakshmi changed: What|Removed |Added Severity|normal |enhancement -- 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 107956] [CI][SHARDS] igt@kms_busy@extended_*_render-[abc] - dmesg-warn - Asynchronous wait on fence i915:kms_busy\[\d+\]/0:1 timed out \(hint:intel_atomic_commit_ready
https://bugs.freedesktop.org/show_bug.cgi?id=107956 Lakshmi changed: What|Removed |Added Assignee|intel-gfx-bugs@lists.freede |dri-devel@lists.freedesktop |sktop.org |.org QA Contact|intel-gfx-bugs@lists.freede | |sktop.org | Component|DRM/Intel |IGT -- 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 107955] AMDGPU driver keeps reloading on hybrid graphics system causing stuttering.
https://bugs.freedesktop.org/show_bug.cgi?id=107955 --- Comment #9 from Ransu --- Adding amdgpu.runpm=0 helps big time but I know this means both the AMD and Intel would be running all the time, this is not ideal. As I said before I would like to have the Intel GPU running as my main and only activating the AMD GPU when I want to make use of a better GPU, preferably with PRIME. -- 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: fix use of freed memory in drm_mode_setcrtc
drm_mode_setcrtc() retries modesetting in case one of the functions it calls returns -EDEADLK. connector_set, mode and fb are freed before retrying, but they are not set to NULL. This can cause drm_mode_setcrtc() to use those variables. For example: On the first try __drm_mode_set_config_internal() returns -EDEADLK. connector_set, mode and fb are freed. Next retry starts, and drm_modeset_lock_all_ctx() returns -EDEADLK, and we jump to 'out'. The code will happily try to release all three again. This leads to crashes of different kinds, depending on the sequence the EDEADLKs happen. Fix this by setting the three variables to NULL at the start of the retry loop. Signed-off-by: Tomi Valkeinen Cc: sta...@vger.kernel.org --- drivers/gpu/drm/drm_crtc.c | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c index 2f6c877299e4..2ad14593fb23 100644 --- a/drivers/gpu/drm/drm_crtc.c +++ b/drivers/gpu/drm/drm_crtc.c @@ -570,9 +570,9 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data, struct drm_mode_crtc *crtc_req = data; struct drm_crtc *crtc; struct drm_plane *plane; - struct drm_connector **connector_set = NULL, *connector; - struct drm_framebuffer *fb = NULL; - struct drm_display_mode *mode = NULL; + struct drm_connector **connector_set, *connector; + struct drm_framebuffer *fb; + struct drm_display_mode *mode; struct drm_mode_set set; uint32_t __user *set_connectors_ptr; struct drm_modeset_acquire_ctx ctx; @@ -601,6 +601,10 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data, mutex_lock(>dev->mode_config.mutex); drm_modeset_acquire_init(, DRM_MODESET_ACQUIRE_INTERRUPTIBLE); retry: + connector_set = NULL; + fb = NULL; + mode = NULL; + ret = drm_modeset_lock_all_ctx(crtc->dev, ); if (ret) goto out; -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: rcar-du: Revert "drm: rcar-du: Use __drm_atomic_helper_plane_reset instead of copying the logic"
Hi Alexandru,
On 17/09/18 10:10, Alexandru-Cosmin Gheorghe wrote:
> Hi Kieran,
>
> Sorry for that and thanks for getting to the bottom of it.
No worries,
> On Fri, Sep 14, 2018 at 11:28:05PM +0100, Kieran Bingham wrote:
>> Hi Laurent,
>>
>> I've looked through a bit further to try to understand this issue and I
>> think I have identified a possible/probable cause.
>>
>> Before commit 161ad653d6c9, we *always* set the plane->state->alpha as
>> DRM_BLEND_ALPHA_OPAQUE. (0x)
>>
>> After this commit, the __drm_atomic_helper_plane_reset() call will only
>> set state->alpha to 0x if the alpha_property is set:
>>
>> if (plane->alpha_property)
>> state->alpha = plane->alpha_property->values[1];
>>
>> Then the state->alpha value is always referenced in
>> rcar_du_vsp_plane_setup() and passed to the VSP for that layer.
>>
>>
>> We can see in rcar_du_planes_init(), that all OVERLAY planes are
>> configured to have this propery with a call to
>> drm_plane_create_alpha_property(>plane); however - the PRIMARY
>> plane is skipped over before setting this.
>>
>>
>> I believe I recall seeing that the kms-test-planeposition.py
>> successfully showed other planes which were not the back one (I'm now
>> going from hazy memory of this afternoon - but I am fairly sure I saw this)
>>
>>
>> This implies that the primary planes are being incorrectly configured -
>> but the overlay planes are still functioning as expected.
>>
>> So I believe we could move the call to create the alpha property:
>> drm_plane_create_alpha_property(>plane);
>>
>> to occur before the if (type == DRM_PLANE_TYPE_PRIMARY) continue; statement.
>>
>
> I don't see any reson why the primary plane shouldn't advertise an
> alpha as well.
OK - so I think we perhaps should make sure that we enable alpha for our
primary plane in rcar-du.
>> It may or may not make sense to have alpha blending support on the
>> PRIMARY plane. At the risk of sounding silly - can we have anything else
>> behind the PRIMARY plane ? (I doubt this, I don't think we have any
>> extra layers hiding anywhere)
>
> I think the same question could apply to situations where PRIMARY is
> disabled and you have just one OVERLAY plane enabled.
>
>>
>> Otherwise, I think we would need to intercept the configuration of the
>> alpha blending and make sure that all PRIMARY planes are configured to
>> be fully opaque in our layers. I think this is happening in
>> rcar_du_vsp_plane_setup().
>>
>> But rather than put in a conditional in there, I think I'd rather just
>> initialise the plane->state->alpha = DRM_BLEND_ALPHA_OPAQUE in our
>> rcar_du_vsp_plane_reset() call and be done with it.
>
> I think you could do more and just go in
> __drm_atomic_helper_plane_reset and always initializes plane->alpha
> with DRM_BLEND_ALPHA_OPAQUE, this way nobody else hits this problem.
I think this sounds like a good thing too.
Is DRM_BLEND_ALPHA_OPAQUE a suitable initial value for all of the other
users of the helper ?
I suspect the answer is yes, but I'll try to do a bit of digging through
the other drivers tomorrow.
I presume we could then just remove the conditional check and always
initialise to OPAQUE ...
Or otherwise perhaps maybe initialising as an 'else' if no alpha
property is provided.
--
Regards
Kieran
>>
>> Anyway - just some musings and thoughts at this stage, we can
>> investigate in more detail next week.
>>
>> --
>> Regards
>>
>> Kieran
>>
>>
>> On 14/09/18 21:09, Kieran Bingham wrote:
>>> Commit: 161ad653d6c9 ("drm: rcar-du: Use __drm_atomic_helper_plane_reset
>>> instead of copying the logic") causes a regression in the R-Car DU
>>> display driver, and prevents any output from being displayed.
>>>
>>> The display appears to function correctly but only a black screen is
>>> ever visible.
>>>
>>> Revert the commit.
>>>
>>> Signed-off-by: Kieran Bingham
>>>
>>> ---
>>>
>>> Looking through the code, the reason for this issue isn't particularly
>>> obvious - and will need some further exploration, which I can't look at
>>> until Tuesday. So I'm posting this revert patch to
>>>
>>> A) Report the issue
>>> B) Provide a temporary fix
>>>
>>> I suspect either the initial alpha value is not set correctly or setting
>>>
>>> state->pixel_blend_mode = DRM_MODE_BLEND_PREMULTI;
>>>
>>> causes some side effect perhaps. There's not much else that could be
>>> different between the helper, and the original code.
>>>
>>> drivers/gpu/drm/rcar-du/rcar_du_plane.c | 6 --
>>> drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 5 -
>>> 2 files changed, 8 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
>>> b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
>>> index 9e07758a755c..5c2462afe408 100644
>>> --- a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
>>> +++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
>>> @@ -686,12 +686,14 @@ static void rcar_du_plane_reset(struct drm_plane
>>> *plane)
>>> if (state == NULL)
>>>
[Bug 107955] AMDGPU driver keeps reloading on hybrid graphics system causing stuttering.
https://bugs.freedesktop.org/show_bug.cgi?id=107955 --- Comment #7 from Ransu --- Created attachment 141600 --> https://bugs.freedesktop.org/attachment.cgi?id=141600=edit xorg.config (log 1) -- 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 107955] AMDGPU driver keeps reloading on hybrid graphics system causing stuttering.
https://bugs.freedesktop.org/show_bug.cgi?id=107955 --- Comment #8 from Ransu --- All attachments for this comment was marked "log 1" This includes my current xorg.conf At the time of the attachments the kernel command line was as follows with sensitive information left out. BOOT_IMAGE=/vmlinuz-linux root=UUID= rw cryptdevice=/dev/disk/by-uuid/ radeon.si_support=0 amdgpu.si_support=1 memmap=10M$2245M quiet resume=UUID= -- 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 107955] AMDGPU driver keeps reloading on hybrid graphics system causing stuttering.
https://bugs.freedesktop.org/show_bug.cgi?id=107955 --- Comment #6 from Ransu --- Created attachment 141599 --> https://bugs.freedesktop.org/attachment.cgi?id=141599=edit dmesg -w (log 1) -- 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 107955] AMDGPU driver keeps reloading on hybrid graphics system causing stuttering.
https://bugs.freedesktop.org/show_bug.cgi?id=107955 --- Comment #5 from Ransu --- Created attachment 141598 --> https://bugs.freedesktop.org/attachment.cgi?id=141598=edit xrandr information (log 1) -- 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 107955] AMDGPU driver keeps reloading on hybrid graphics system causing stuttering.
https://bugs.freedesktop.org/show_bug.cgi?id=107955 Ransu changed: What|Removed |Added Attachment #141597|Xorg.0.log |Xorg.0.log (log 1) description|| -- 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 107955] AMDGPU driver keeps reloading on hybrid graphics system causing stuttering.
https://bugs.freedesktop.org/show_bug.cgi?id=107955 --- Comment #4 from Ransu --- Created attachment 141597 --> https://bugs.freedesktop.org/attachment.cgi?id=141597=edit Xorg.0.log -- 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 105530] Stuttering on Raven Ridge when TearFree is on
https://bugs.freedesktop.org/show_bug.cgi?id=105530 --- Comment #15 from Michel Dänzer --- (In reply to Andrew Sheldon from comment #14) > Is this expected behaviour? I'm afraid it might be at this point, due to TearFree always incurring an additional GPU copy. > If so, it might be useful to have the ability to disable the feature for > fullscreen windows, much like compositing managers have the ability to > unredirect fullscreen windows. Well, it's not quite the same, since even fullscreen windows can tear without page flipping. But yeah, it's possible to eliminate the additional GPU copy while a DRI3 client is page flipping, just haven't got around to implementing it. Anyway, that's a separate issue from the stuttering and should be tracked in a separate report. BTW, I don't suppose xf86-video-amdgpu 18.1.0 makes any difference for the stuttering? -- 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 201139] amdgpu: [drm] enabling link 1 failed: 15 (vega)
https://bugzilla.kernel.org/show_bug.cgi?id=201139 Michel Dänzer (mic...@daenzer.net) changed: What|Removed |Added CC||harry.wentl...@amd.com, ||nicholas.kazlaus...@amd.com --- Comment #1 from Michel Dänzer (mic...@daenzer.net) --- Please attach the full dmesg output. -- 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 201147] amdgpu, no detected monitors HP Envy x360 - AMD Ryzen 5 2500U
https://bugzilla.kernel.org/show_bug.cgi?id=201147 --- Comment #2 from Michel Dänzer (mic...@daenzer.net) --- Looks like CONFIG_DRM_AMD_DC_DCN1_0 isn't enabled in the kernel build configuration. This is a configuration error, which will no longer be possible in 4.19. -- 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 libdrm] CONTRIBUTING: clarify how to request a Developer role
Hi,
On Sat, 15 Sep 2018 at 00:56, Lucas De Marchi wrote:
> -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.
> +To apply for commit rights ("Developer" role in gitlab), check project
> +members who have the "owner" role at
> +https://gitlab.freedesktop.org/mesa/drm/project_members?sort=access_level_desc.
> +Any of them can add new developers.
I think it still makes sense to discuss it publicly, either on the
list or through a bug tracker. Having an audit log of who's there and
why is pretty important. I would suggest the process be to email
dri-devel@ and request it, then if nothing happens ping one of the
people listed there as an owner.
Cheers,
Daniel
___
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 Geert,
On Monday, 17 September 2018 12:48:12 EEST Geert Uytterhoeven wrote:
> On Mon, Sep 17, 2018 at 11:09 AM Laurent Pinchart wrote:
> > On Monday, 17 September 2018 11:51:06 EEST Simon Horman wrote:
> >> On Mon, Sep 17, 2018 at 11:38:43AM +0300, Laurent Pinchart wrote:
> >>> On Monday, 17 September 2018 10:50:55 EEST 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
> > @@ -537,6 +537,173 @@
> > resets = < 408>;
> > };
>
> These nodes should be placed after the gic to preserve the sorting
> of nodes by bus address and then IP block.
> >>>
> >>> Aren't they already ? :-)
> >>
> >> Git didn't seem to think so. But its not a big deal,
> >> I can fix this up locally.
> >
> > Did it apply the below hunk to a different location ? 408 is the gic,
> > isn't it ?
>
> The "-U " option (with sufficiently large) of "git diff" and "git
> show" is a great help for inspecting DT changes.
I know. This is what I have in my tree:
diff --git a/arch/arm64/boot/dts/renesas/r8a77990.dtsi b/arch/arm64/boot/dts/
renesas/r8a77990.dtsi
index abb14af76c0e..935bb313d29f 100644
--- a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
@@ -522,32 +522,199 @@
gic: interrupt-controller@f101 {
compatible = "arm,gic-400";
#interrupt-cells = <3>;
#address-cells = <0>;
interrupt-controller;
reg = <0x0 0xf101 0 0x1000>,
<0x0 0xf102 0 0x2>,
<0x0 0xf104 0 0x2>,
<0x0 0xf106 0 0x2>;
interrupts = ;
clocks = < CPG_MOD 408>;
clock-names = "clk";
power-domains = < 32>;
resets = < 408>;
};
+ vspb0: vsp@fe96 {
+ compatible = "renesas,vsp2";
+ reg = <0 0xfe96 0 0x8000>;
+ interrupts = ;
+ clocks = < CPG_MOD 626>;
+ power-domains = < R8A77990_PD_ALWAYS_ON>;
+ resets = < 626>;
+ renesas,fcp = <>;
+ };
[snip]
so I don't see where the problem that Simon pointed out is, especially given
that I took care to sort nodes out properly this time.
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107955] AMDGPU driver keeps reloading on hybrid graphics system causing stuttering.
https://bugs.freedesktop.org/show_bug.cgi?id=107955 --- Comment #3 from Michel Dänzer --- Please attach the Xorg log file and the output of dmesg and xrandr. -- 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 107940] libdrm 2.4.94-1 causes blender to crash on opencl
https://bugs.freedesktop.org/show_bug.cgi?id=107940 --- Comment #3 from Michel Dänzer --- Please attach the Xorg log file and the output of dmesg and xrandr. -- 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 107955] AMDGPU driver keeps reloading on hybrid graphics system causing stuttering.
https://bugs.freedesktop.org/show_bug.cgi?id=107955 Michel Dänzer changed: What|Removed |Added QA Contact|xorg-t...@lists.x.org | Assignee|xorg-driver-...@lists.x.org |dri-devel@lists.freedesktop ||.org Product|xorg|DRI Component|Driver/AMDgpu |DRM/AMDgpu --- Comment #2 from Michel Dänzer --- The messages appear when the AMD GPU is woken up due to userspace using some functionality of the amdgpu kernel driver. Does amdgpu.runpm=0 on the kernel command line prevent the stuttering? If so, I hope somebody can help you track down how userspace is causing the AMD GPU to wake up. (Note that the above will keep the AMD GPU powered on all the time; it's intended to confirm that the stuttering is related to powering up the AMD GPU, not as a permanent solution) -- 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 v2 13/16] arm64: dts: renesas: r8a77990: Add display output support
Hi Laurent,
On Mon, Sep 17, 2018 at 11:09 AM Laurent Pinchart
wrote:
> On Monday, 17 September 2018 11:51:06 EEST Simon Horman wrote:
> > On Mon, Sep 17, 2018 at 11:38:43AM +0300, Laurent Pinchart wrote:
> > > On Monday, 17 September 2018 10:50:55 EEST 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
> > > > > @@ -537,6 +537,173 @@
> > > > > resets = < 408>;
> > > > > };
> > > >
> > > > These nodes should be placed after the gic to preserve the sorting
> > > > of nodes by bus address and then IP block.
> > >
> > > Aren't they already ? :-)
> >
> > Git didn't seem to think so. But its not a big deal,
> > I can fix this up locally.
>
> Did it apply the below hunk to a different location ? 408 is the gic, isn't it
> ?
The "-U " option (with sufficiently large) of "git diff" and "git show"
is a great help for inspecting DT changes.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107940] libdrm 2.4.94-1 causes blender to crash on opencl
https://bugs.freedesktop.org/show_bug.cgi?id=107940 --- Comment #2 from Michel Dänzer --- Can you bisect? -- 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 107595] amd-staging-drm-next: BUG: unable to handle kernel NULL pointer dereference at 0000000000000018 - R4 Mullins
https://bugs.freedesktop.org/show_bug.cgi?id=107595 --- Comment #13 from Michel Dänzer --- (In reply to Przemek from comment #12) > Pontus Gråskæg, if kernel compiled from the latest git repo sync > (git://people.freedesktop.org/~agd5f/linux) does not work for you feel free > to reopen it. Please rather file your own report in that case. -- 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] [RFC]drm: add syncobj timeline support v5
On 2018年09月17日 16:37, Christian König wrote:
Am 14.09.2018 um 12:37 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.
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
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 | 294 ++---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 4 +-
include/drm/drm_syncobj.h | 62 +++--
include/uapi/drm/drm.h | 1 +
4 files changed, 292 insertions(+), 69 deletions(-)
diff --git a/drivers/gpu/drm/drm_syncobj.c
b/drivers/gpu/drm/drm_syncobj.c
index e9ce623d049e..e78d076f2703 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_NORMAL_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;
+ u64 value;
+ struct list_head list;
+};
/**
* drm_syncobj_find - lookup and reference a sync object.
@@ -124,7 +132,7 @@ static int
drm_syncobj_fence_get_or_add_callback(struct drm_syncobj *syncobj,
{
int ret;
- *fence = drm_syncobj_fence_get(syncobj);
+ ret = drm_syncobj_search_fence(syncobj, 0, 0, fence);
if (*fence)
Don't we need to check ret here instead?
both ok, if you like check ret, will update it in v6.
return 1;
@@ -133,10 +141,10 @@ 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(>lock)));
- ret = 1;
+ if (fence) {
+ drm_syncobj_search_fence(syncobj, 0, 0, fence);
+ if (*fence)
+ ret = 1;
That doesn't looks correct to me, drm_syncobj_search_fence() would try
to grab the lock once more.
That
Re: [PATCH] drm: rcar-du: Revert "drm: rcar-du: Use __drm_atomic_helper_plane_reset instead of copying the logic"
Hi Kieran,
Sorry for that and thanks for getting to the bottom of it.
On Fri, Sep 14, 2018 at 11:28:05PM +0100, Kieran Bingham wrote:
> Hi Laurent,
>
> I've looked through a bit further to try to understand this issue and I
> think I have identified a possible/probable cause.
>
> Before commit 161ad653d6c9, we *always* set the plane->state->alpha as
> DRM_BLEND_ALPHA_OPAQUE. (0x)
>
> After this commit, the __drm_atomic_helper_plane_reset() call will only
> set state->alpha to 0x if the alpha_property is set:
>
> if (plane->alpha_property)
> state->alpha = plane->alpha_property->values[1];
>
> Then the state->alpha value is always referenced in
> rcar_du_vsp_plane_setup() and passed to the VSP for that layer.
>
>
> We can see in rcar_du_planes_init(), that all OVERLAY planes are
> configured to have this propery with a call to
> drm_plane_create_alpha_property(>plane); however - the PRIMARY
> plane is skipped over before setting this.
>
>
> I believe I recall seeing that the kms-test-planeposition.py
> successfully showed other planes which were not the back one (I'm now
> going from hazy memory of this afternoon - but I am fairly sure I saw this)
>
>
> This implies that the primary planes are being incorrectly configured -
> but the overlay planes are still functioning as expected.
>
> So I believe we could move the call to create the alpha property:
> drm_plane_create_alpha_property(>plane);
>
> to occur before the if (type == DRM_PLANE_TYPE_PRIMARY) continue; statement.
>
I don't see any reson why the primary plane shouldn't advertise an
alpha as well.
> It may or may not make sense to have alpha blending support on the
> PRIMARY plane. At the risk of sounding silly - can we have anything else
> behind the PRIMARY plane ? (I doubt this, I don't think we have any
> extra layers hiding anywhere)
I think the same question could apply to situations where PRIMARY is
disabled and you have just one OVERLAY plane enabled.
>
> Otherwise, I think we would need to intercept the configuration of the
> alpha blending and make sure that all PRIMARY planes are configured to
> be fully opaque in our layers. I think this is happening in
> rcar_du_vsp_plane_setup().
>
> But rather than put in a conditional in there, I think I'd rather just
> initialise the plane->state->alpha = DRM_BLEND_ALPHA_OPAQUE in our
> rcar_du_vsp_plane_reset() call and be done with it.
I think you could do more and just go in
__drm_atomic_helper_plane_reset and always initializes plane->alpha
with DRM_BLEND_ALPHA_OPAQUE, this way nobody else hits this problem.
>
> Anyway - just some musings and thoughts at this stage, we can
> investigate in more detail next week.
>
> --
> Regards
>
> Kieran
>
>
> On 14/09/18 21:09, Kieran Bingham wrote:
> > Commit: 161ad653d6c9 ("drm: rcar-du: Use __drm_atomic_helper_plane_reset
> > instead of copying the logic") causes a regression in the R-Car DU
> > display driver, and prevents any output from being displayed.
> >
> > The display appears to function correctly but only a black screen is
> > ever visible.
> >
> > Revert the commit.
> >
> > Signed-off-by: Kieran Bingham
> >
> > ---
> >
> > Looking through the code, the reason for this issue isn't particularly
> > obvious - and will need some further exploration, which I can't look at
> > until Tuesday. So I'm posting this revert patch to
> >
> > A) Report the issue
> > B) Provide a temporary fix
> >
> > I suspect either the initial alpha value is not set correctly or setting
> >
> > state->pixel_blend_mode = DRM_MODE_BLEND_PREMULTI;
> >
> > causes some side effect perhaps. There's not much else that could be
> > different between the helper, and the original code.
> >
> > drivers/gpu/drm/rcar-du/rcar_du_plane.c | 6 --
> > drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 5 -
> > 2 files changed, 8 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> > b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> > index 9e07758a755c..5c2462afe408 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> > @@ -686,12 +686,14 @@ static void rcar_du_plane_reset(struct drm_plane
> > *plane)
> > if (state == NULL)
> > return;
> >
> > - __drm_atomic_helper_plane_reset(plane, >state);
> > -
> > state->hwindex = -1;
> > state->source = RCAR_DU_PLANE_MEMORY;
> > state->colorkey = RCAR_DU_COLORKEY_NONE;
> > state->state.zpos = plane->type == DRM_PLANE_TYPE_PRIMARY ? 0 : 1;
> > +
> > + plane->state = >state;
> > + plane->state->alpha = DRM_BLEND_ALPHA_OPAQUE;
> > + plane->state->plane = plane;
> > }
> >
> > static int rcar_du_plane_atomic_set_property(struct drm_plane *plane,
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> > b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> > index 4576119e..3170b126cfba 100644
> > ---
Re: [PATCH v2 13/16] arm64: dts: renesas: r8a77990: Add display output support
Hi Simon,
On Monday, 17 September 2018 11:51:06 EEST Simon Horman wrote:
> On Mon, Sep 17, 2018 at 11:38:43AM +0300, Laurent Pinchart wrote:
> > On Monday, 17 September 2018 10:50:55 EEST 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
> > > > @@ -537,6 +537,173 @@
> > > > resets = < 408>;
> > > > };
> > >
> > > These nodes should be placed after the gic to preserve the sorting
> > > of nodes by bus address and then IP block.
> >
> > Aren't they already ? :-)
>
> Git didn't seem to think so. But its not a big deal,
> I can fix this up locally.
Did it apply the below hunk to a different location ? 408 is the gic, isn't it
?
> > > > + vspb0: vsp@fe96 {
> > > > + compatible = "renesas,vsp2";
> > > > + reg = <0 0xfe96 0 0x8000>;
> > > > + interrupts = ;
> > > > + clocks = < CPG_MOD 626>;
> > > > + power-domains = < R8A77990_PD_ALWAYS_ON>;
> > > > + resets = < 626>;
> > > > + renesas,fcp = <>;
> > > > + };
> > > > +
> > > > + fcpvb0: fcp@fe96f000 {
> > > > + compatible = "renesas,fcpv";
> > > > + reg = <0 0xfe96f000 0 0x200>;
> > > > + clocks = < CPG_MOD 607>;
> > > > + power-domains = < R8A77990_PD_ALWAYS_ON>;
> > > > + resets = < 607>;
> > > > + iommus = <_vp0 5>;
> > > > + };
> > > > +
> > > > + vspi0: vsp@fe9a {
> > > > + compatible = "renesas,vsp2";
> > > > + reg = <0 0xfe9a 0 0x8000>;
> > > > + interrupts = ;
> > > > + clocks = < CPG_MOD 622>;
> > >
> > > R-Car Series, 3rd Generation, v1.00, Table Table 8A.21 indicates
> > > that this clock should be < CPG_MOD 631>. The clock above is
> > > (according to my reading of the documentation) correctly
> > > used for vspd1 below.
> >
> > Bad copy and paste, thank you for pointing it out, it will be fixed in v3.
> >
> > > > + power-domains = < R8A77990_PD_ALWAYS_ON>;
> > > > + resets = < 631>;
> > > > + renesas,fcp = <>;
> > > > + };
> > > > +
> > > > + fcpvi0: fcp@fe9af000 {
> > > > + compatible = "renesas,fcpv";
> > > > + reg = <0 0xfe9af000 0 0x200>;
> > > > + clocks = < CPG_MOD 611>;
> > > > + power-domains = < R8A77990_PD_ALWAYS_ON>;
> > > > + resets = < 611>;
> > > > + iommus = <_vp0 8>;
> > > > + };
> > > > +
> > > > + vspd0: vsp@fea2 {
> > > > + compatible = "renesas,vsp2";
> > > > + reg = <0 0xfea2 0 0x7000>;
> > > > + interrupts = ;
> > > > + clocks = < CPG_MOD 623>;
> > > > + power-domains = < R8A77990_PD_ALWAYS_ON>;
> > > > + resets = < 623>;
> > > > + renesas,fcp = <>;
> > > > + };
> > > > +
> > > > + fcpvd0: fcp@fea27000 {
> > > > + compatible = "renesas,fcpv";
> > > > + reg = <0 0xfea27000 0 0x200>;
> > > > + clocks = < CPG_MOD 603>;
> > > > + power-domains = < R8A77990_PD_ALWAYS_ON>;
> > > > + resets = < 603>;
> > > > + iommus = <_vi0 8>;
> > > > + };
> > > > +
> > > > + vspd1: vsp@fea28000 {
> > > > + compatible = "renesas,vsp2";
> > > > + reg = <0 0xfea28000 0 0x7000>;
> > > > + interrupts = ;
> > > > + clocks = < CPG_MOD 622>;
> > > > + power-domains = < R8A77990_PD_ALWAYS_ON>;
> > > > + resets = < 622>;
> > > > + renesas,fcp = <>;
> > > > + };
> > > > +
Re: [PATCH v2 13/16] arm64: dts: renesas: r8a77990: Add display output support
On Monday, 17 September 2018 11:54:04 EEST Laurent Pinchart wrote:
> Hi Simon,
>
> 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
> > > > > @@ -537,6 +537,173 @@
> > > > >
> > > > > resets = < 408>;
> > > > >
> > > > > };
> > > >
> > > > These nodes should be placed after the gic to preserve the sorting
> > > > of nodes by bus address and then IP block.
> > > >
> > > > > + vspb0: vsp@fe96 {
> > > > > + compatible = "renesas,vsp2";
> > > > > + reg = <0 0xfe96 0 0x8000>;
> > > > > + interrupts = ;
> > > > > + clocks = < CPG_MOD 626>;
> > > > > + power-domains = < R8A77990_PD_ALWAYS_ON>;
> > > > > + resets = < 626>;
> > > > > + renesas,fcp = <>;
> > > > > + };
> > > > > +
> > > > > + fcpvb0: fcp@fe96f000 {
> > > > > + compatible = "renesas,fcpv";
> > > > > + reg = <0 0xfe96f000 0 0x200>;
> > > > > + clocks = < CPG_MOD 607>;
> > > > > + power-domains = < R8A77990_PD_ALWAYS_ON>;
> > > > > + resets = < 607>;
> > > > > + iommus = <_vp0 5>;
> > > > > + };
> > > > > +
> > > > > + vspi0: vsp@fe9a {
> > > > > + compatible = "renesas,vsp2";
> > > > > + reg = <0 0xfe9a 0 0x8000>;
> > > > > + interrupts = ;
> > > > > + clocks = < CPG_MOD 622>;
> > > >
> > > > R-Car Series, 3rd Generation, v1.00, Table Table 8A.21 indicates
> > > > that this clock should be < CPG_MOD 631>. The clock above is
> > > > (according to my reading of the documentation) correctly
> > > > used for vspd1 below.
> > > >
> > > > > + power-domains = < R8A77990_PD_ALWAYS_ON>;
> > > > > + resets = < 631>;
> > > > > + renesas,fcp = <>;
> > > > > + };
> > > > > +
> > > > > + fcpvi0: fcp@fe9af000 {
> > > > > + compatible = "renesas,fcpv";
> > > > > + reg = <0 0xfe9af000 0 0x200>;
> > > > > + clocks = < CPG_MOD 611>;
> > > > > + power-domains = < R8A77990_PD_ALWAYS_ON>;
> > > > > + resets = < 611>;
> > > > > + iommus = <_vp0 8>;
> > > > > + };
> > > > > +
> > > > > + vspd0: vsp@fea2 {
> > > > > + compatible = "renesas,vsp2";
> > > > > + reg = <0 0xfea2 0 0x7000>;
> > > > > + interrupts = ;
> > > > > + clocks = < CPG_MOD 623>;
> > > > > + power-domains = < R8A77990_PD_ALWAYS_ON>;
> > > > > + resets = < 623>;
> > > > > + renesas,fcp = <>;
> > > > > + };
> > > > > +
> > > > > + fcpvd0: fcp@fea27000 {
> > > > > + compatible = "renesas,fcpv";
> > > > > + reg = <0 0xfea27000 0 0x200>;
> > > > > + clocks = < CPG_MOD 603>;
> > > > > + power-domains = < R8A77990_PD_ALWAYS_ON>;
> > > > > + resets = < 603>;
> > > > > + iommus = <_vi0 8>;
> > > > > + };
> > > > > +
> > > > > + vspd1: vsp@fea28000 {
> > > > > + compatible = "renesas,vsp2";
> > > > > + reg = <0 0xfea28000 0 0x7000>;
> > > > > + interrupts = ;
> > > > > + clocks = < CPG_MOD 622>;
> > > > > + power-domains = < R8A77990_PD_ALWAYS_ON>;
> > > > > + resets = < 622>;
> > > > > + renesas,fcp = <>;
> > > > > + };
> > > > > +
> > > > > + fcpvd1: fcp@fea2f000 {
> > > > > +
Re: [Intel-gfx] [PATCH v10 0/2] Add XYUV format support
On 17.09.2018 11:25, Lisovskiy, Stanislav wrote: On Fri, 2018-09-14 at 20:05 +0300, Juha-Pekka Heikkilä wrote: Lisovskiy, Stanislav kirjoitti 14.9.2018 klo 17.30: On Fri, 2018-09-14 at 16:47 +0300, Ville Syrjälä wrote: On Fri, Sep 14, 2018 at 01:36:32PM +, Lisovskiy, Stanislav wrote: On Fri, 2018-09-07 at 11:45 +0300, Stanislav Lisovskiy wrote: Introduced new XYUV scan-in format for framebuffer and added support for it to i915(SkyLake+). Stanislav Lisovskiy (2): drm: Introduce new DRM_FORMAT_XYUV drm/i915: Adding YUV444 packed format support for skl+ drivers/gpu/drm/drm_fourcc.c | 1 + drivers/gpu/drm/i915/i915_reg.h | 2 +- drivers/gpu/drm/i915/intel_display.c | 15 +++ drivers/gpu/drm/i915/intel_sprite.c | 2 ++ include/uapi/drm/drm_fourcc.h| 1 + 5 files changed, 20 insertions(+), 1 deletion(-) Ping. There is an IGT patch which got Reviewed-by Ville. This one left in order to get XYUV support. Did we figure out userspace for this? Was the conflict solved with the other guy (forgot who it is) trying to add the same format with a different name? Currently for userspace we have VLC(checked with Juha-Pekka) and also IGT test case. Hei, no. VLC was *not* showing the mode correctly back then when we tested. VLC kms plugin is able to initialize the mode and it's all stable but VLC didn't have correct video converter to reach matching xYUV output. You remember Stan we tried to increase the recursion for decoding in case it would help? VLC doesn't have codec which produce correct output, one of those xxx -> YUV plug-ins in VLC should be patched before VLC can be considered as userspace for this mode. Ok, I remember we managed to make it work somehow and saw some picture, so for some reason I thought it is working already. What is our plan then? Should we try to improve VLC codecs/plugins or may be I should then work with some other user space case? For VLC there are codecs which know about xYUV format but they seem to use it for input, I figure nobody so far needed it for output. If want to use VLC as userspace demo one of those codecs need to be patched up for outputting xYUV. As they already support many other YUV formats I wouldn't expect needed change to be significant on code level as KMS support is already in VLC. /Juha-Pekka I think those guys were from ARM and they were adding also support for XYUV. The only difference was that they called XYUV, like XYUV something. Our patches were otherwise identical regarding drm_fourcc.c part, I don't see their stuff merged, but I guess it really shouldn't matter, who does this first. i915 specific part doesn't conflict with their stuff. To be honest, I forgot the guy's name neither could find his email in my mailbox. So hopefully somebody shows up here. ___ 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 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
> > > > @@ -537,6 +537,173 @@
> > > >
> > > > resets = < 408>;
> > > >
> > > > };
> > >
> > > These nodes should be placed after the gic to preserve the sorting
> > > of nodes by bus address and then IP block.
> > >
> > > > + vspb0: vsp@fe96 {
> > > > + compatible = "renesas,vsp2";
> > > > + reg = <0 0xfe96 0 0x8000>;
> > > > + interrupts = ;
> > > > + clocks = < CPG_MOD 626>;
> > > > + power-domains = < R8A77990_PD_ALWAYS_ON>;
> > > > + resets = < 626>;
> > > > + renesas,fcp = <>;
> > > > + };
> > > > +
> > > > + fcpvb0: fcp@fe96f000 {
> > > > + compatible = "renesas,fcpv";
> > > > + reg = <0 0xfe96f000 0 0x200>;
> > > > + clocks = < CPG_MOD 607>;
> > > > + power-domains = < R8A77990_PD_ALWAYS_ON>;
> > > > + resets = < 607>;
> > > > + iommus = <_vp0 5>;
> > > > + };
> > > > +
> > > > + vspi0: vsp@fe9a {
> > > > + compatible = "renesas,vsp2";
> > > > + reg = <0 0xfe9a 0 0x8000>;
> > > > + interrupts = ;
> > > > + clocks = < CPG_MOD 622>;
> > >
> > > R-Car Series, 3rd Generation, v1.00, Table Table 8A.21 indicates
> > > that this clock should be < CPG_MOD 631>. The clock above is
> > > (according to my reading of the documentation) correctly
> > > used for vspd1 below.
> > >
> > > > + power-domains = < R8A77990_PD_ALWAYS_ON>;
> > > > + resets = < 631>;
> > > > + renesas,fcp = <>;
> > > > + };
> > > > +
> > > > + fcpvi0: fcp@fe9af000 {
> > > > + compatible = "renesas,fcpv";
> > > > + reg = <0 0xfe9af000 0 0x200>;
> > > > + clocks = < CPG_MOD 611>;
> > > > + power-domains = < R8A77990_PD_ALWAYS_ON>;
> > > > + resets = < 611>;
> > > > + iommus = <_vp0 8>;
> > > > + };
> > > > +
> > > > + vspd0: vsp@fea2 {
> > > > + compatible = "renesas,vsp2";
> > > > + reg = <0 0xfea2 0 0x7000>;
> > > > + interrupts = ;
> > > > + clocks = < CPG_MOD 623>;
> > > > + power-domains = < R8A77990_PD_ALWAYS_ON>;
> > > > + resets = < 623>;
> > > > + renesas,fcp = <>;
> > > > + };
> > > > +
> > > > + fcpvd0: fcp@fea27000 {
> > > > + compatible = "renesas,fcpv";
> > > > + reg = <0 0xfea27000 0 0x200>;
> > > > + clocks = < CPG_MOD 603>;
> > > > + power-domains = < R8A77990_PD_ALWAYS_ON>;
> > > > + resets = < 603>;
> > > > + iommus = <_vi0 8>;
> > > > + };
> > > > +
> > > > + vspd1: vsp@fea28000 {
> > > > + compatible = "renesas,vsp2";
> > > > + reg = <0 0xfea28000 0 0x7000>;
> > > > + interrupts = ;
> > > > + clocks = < CPG_MOD 622>;
> > > > + power-domains = < R8A77990_PD_ALWAYS_ON>;
> > > > + resets = < 622>;
> > > > + renesas,fcp = <>;
> > > > + };
> > > > +
> > > > + fcpvd1: fcp@fea2f000 {
> > > > + compatible = "renesas,fcpv";
> > > > + reg = <0 0xfea2f000 0 0x200>;
> > > > + clocks = < CPG_MOD 602>;
> > > > +
Re: [Intel-gfx] [PATCH v10 0/2] Add XYUV format support
Hi, On Mon, Sep 17, 2018 at 08:27:18AM +, Lisovskiy, Stanislav wrote: > On Fri, 2018-09-14 at 14:59 +, Alexandru-Cosmin Gheorghe wrote: > > On Fri, Sep 14, 2018 at 02:49:09PM +, Lisovskiy, Stanislav wrote: > > > On Fri, 2018-09-14 at 15:34 +0100, Saarinen, Jani wrote: > > > > Hi, > > > > > > > > > -Original Message- > > > > > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org > > > > > ] On > > > > > Behalf > > > > > Of Lisovskiy, Stanislav > > > > > Sent: perjantai 14. syyskuuta 2018 17.31 > > > > > To: ville.syrj...@linux.intel.com > > > > > Cc: intel-...@lists.freedesktop.org; Syrjala, Ville > > > > > > > > > intel.com>; > > > > > Heikkila, Juha-pekka ; dri- > > > > > de...@lists.freedesktop.org; Peres, Martin > > > > com> > > > > > Subject: Re: [Intel-gfx] [PATCH v10 0/2] Add XYUV format > > > > > support > > > > > > > > > > On Fri, 2018-09-14 at 16:47 +0300, Ville Syrjälä wrote: > > > > > > On Fri, Sep 14, 2018 at 01:36:32PM +, Lisovskiy, > > > > > > Stanislav > > > > > > wrote: > > > > > > > On Fri, 2018-09-07 at 11:45 +0300, Stanislav Lisovskiy > > > > > > > wrote: > > > > > > > > Introduced new XYUV scan-in format for framebuffer and > > > > > > > > added > > > > > > > > support for it to i915(SkyLake+). > > > > > > > > > > > > > > > > Stanislav Lisovskiy (2): > > > > > > > > drm: Introduce new DRM_FORMAT_XYUV > > > > > > > > drm/i915: Adding YUV444 packed format support for skl+ > > > > > > > > > > > > > > > > drivers/gpu/drm/drm_fourcc.c | 1 + > > > > > > > > drivers/gpu/drm/i915/i915_reg.h | 2 +- > > > > > > > > drivers/gpu/drm/i915/intel_display.c | 15 > > > > > > > > +++ > > > > > > > > drivers/gpu/drm/i915/intel_sprite.c | 2 ++ > > > > > > > > include/uapi/drm/drm_fourcc.h| 1 + > > > > > > > > 5 files changed, 20 insertions(+), 1 deletion(-) > > > > > > > > > > > > > > > > > > > > > > Ping. There is an IGT patch which got Reviewed-by Ville. > > > > > > > This one left in order to get XYUV support. > > > > > > > > > > > > Did we figure out userspace for this? > > > > > > > > > > > > Was the conflict solved with the other guy (forgot who it is) > > > > > > trying > > > > > > to add the same format with a different name? > > > > > > > > > > Currently for userspace we have VLC(checked with Juha-Pekka) > > > > > and > > > > > also IGT > > > > > test case. > > > > > > > > > > I think those guys were from ARM and they were adding also > > > > > support > > > > > for > > > > > XYUV. The only difference was that they called XYUV, like > > > > > XYUV > > > > > something. > > > > > Our patches were otherwise identical regarding drm_fourcc.c > > > > > part, I > > > > > don't > > > > > see their stuff merged, but I guess it really shouldn't matter, > > > > > who > > > > > does this > > > > > first. i915 specific part doesn't conflict with their stuff. To > > > > > be > > > > > honest, I forgot > > > > > the guy's name neither could find his email in my mailbox. > > > > > So hopefully somebody shows up here. > > > > > > > > Stan: > > > > Alexandru-Cosmin Gheorghe ? > > > > > > > > > > Exactly, found now. Thanks for the hint! > > > > Yes, that's me. > > Not a real conflict here, as long as your patches are ready to be > > merged feel free to do it and I will just rebase my series on top of > > that. > > I can change DRM_FORMAT_XYUV naming to DRM_FORMAT_XYUV also, so > that my patch series then is compatible with yours. That would be nice. Thank you. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Best Regards, > > > > > > > > > > Lisovskiy Stanislav > > > > > ___ > > > > > Intel-gfx mailing list > > > > > intel-...@lists.freedesktop.org > > > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx > > > > > > -- > > > Best Regards, > > > > > > Lisovskiy Stanislav > > > ___ > > > dri-devel mailing list > > > dri-devel@lists.freedesktop.org > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > > > > -- > Best Regards, > > Lisovskiy Stanislav -- Cheers, Alex G ___ 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 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
> > > @@ -537,6 +537,173 @@
> > >
> > > resets = < 408>;
> > >
> > > };
> >
> > These nodes should be placed after the gic to preserve the sorting
> > of nodes by bus address and then IP block.
> >
> > > + vspb0: vsp@fe96 {
> > > + compatible = "renesas,vsp2";
> > > + reg = <0 0xfe96 0 0x8000>;
> > > + interrupts = ;
> > > + clocks = < CPG_MOD 626>;
> > > + power-domains = < R8A77990_PD_ALWAYS_ON>;
> > > + resets = < 626>;
> > > + renesas,fcp = <>;
> > > + };
> > > +
> > > + fcpvb0: fcp@fe96f000 {
> > > + compatible = "renesas,fcpv";
> > > + reg = <0 0xfe96f000 0 0x200>;
> > > + clocks = < CPG_MOD 607>;
> > > + power-domains = < R8A77990_PD_ALWAYS_ON>;
> > > + resets = < 607>;
> > > + iommus = <_vp0 5>;
> > > + };
> > > +
> > > + vspi0: vsp@fe9a {
> > > + compatible = "renesas,vsp2";
> > > + reg = <0 0xfe9a 0 0x8000>;
> > > + interrupts = ;
> > > + clocks = < CPG_MOD 622>;
> >
> > R-Car Series, 3rd Generation, v1.00, Table Table 8A.21 indicates
> > that this clock should be < CPG_MOD 631>. The clock above is
> > (according to my reading of the documentation) correctly
> > used for vspd1 below.
> >
> > > + power-domains = < R8A77990_PD_ALWAYS_ON>;
> > > + resets = < 631>;
> > > + renesas,fcp = <>;
> > > + };
> > > +
> > > + fcpvi0: fcp@fe9af000 {
> > > + compatible = "renesas,fcpv";
> > > + reg = <0 0xfe9af000 0 0x200>;
> > > + clocks = < CPG_MOD 611>;
> > > + power-domains = < R8A77990_PD_ALWAYS_ON>;
> > > + resets = < 611>;
> > > + iommus = <_vp0 8>;
> > > + };
> > > +
> > > + vspd0: vsp@fea2 {
> > > + compatible = "renesas,vsp2";
> > > + reg = <0 0xfea2 0 0x7000>;
> > > + interrupts = ;
> > > + clocks = < CPG_MOD 623>;
> > > + power-domains = < R8A77990_PD_ALWAYS_ON>;
> > > + resets = < 623>;
> > > + renesas,fcp = <>;
> > > + };
> > > +
> > > + fcpvd0: fcp@fea27000 {
> > > + compatible = "renesas,fcpv";
> > > + reg = <0 0xfea27000 0 0x200>;
> > > + clocks = < CPG_MOD 603>;
> > > + power-domains = < R8A77990_PD_ALWAYS_ON>;
> > > + resets = < 603>;
> > > + iommus = <_vi0 8>;
> > > + };
> > > +
> > > + vspd1: vsp@fea28000 {
> > > + compatible = "renesas,vsp2";
> > > + reg = <0 0xfea28000 0 0x7000>;
> > > + interrupts = ;
> > > + clocks = < CPG_MOD 622>;
> > > + power-domains = < R8A77990_PD_ALWAYS_ON>;
> > > + resets = < 622>;
> > > + renesas,fcp = <>;
> > > + };
> > > +
> > > + fcpvd1: fcp@fea2f000 {
> > > + compatible = "renesas,fcpv";
> > > + reg = <0 0xfea2f000 0 0x200>;
> > > + clocks = < CPG_MOD 602>;
> > > + power-domains = < R8A77990_PD_ALWAYS_ON>;
> > > + resets = < 602>;
> > > + iommus = <_vi0 9>;
> > > + };
> > > +
> > > + du: display@feb0 {
> > > + compatible = "renesas,du-r8a77990";
> > > + reg = <0 0xfeb0 0 0x8>;
> > > + interrupts = ,
> > > + ;
> > > + clocks = < CPG_MOD 724>,
> > > + < CPG_MOD 723>;
> > > + clock-names = "du.0", "du.1";
> > > + vsps = < 0 0>;
> > > + status = "disabled";
> > > +
> > > + ports {
> > > +
Re: [PATCH v2 13/16] arm64: dts: renesas: r8a77990: Add display output support
Hi Simon,
On Monday, 17 September 2018 10:50:55 EEST 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
> > @@ -537,6 +537,173 @@
> > resets = < 408>;
> > };
>
> These nodes should be placed after the gic to preserve the sorting
> of nodes by bus address and then IP block.
Aren't they already ? :-)
> > + vspb0: vsp@fe96 {
> > + compatible = "renesas,vsp2";
> > + reg = <0 0xfe96 0 0x8000>;
> > + interrupts = ;
> > + clocks = < CPG_MOD 626>;
> > + power-domains = < R8A77990_PD_ALWAYS_ON>;
> > + resets = < 626>;
> > + renesas,fcp = <>;
> > + };
> > +
> > + fcpvb0: fcp@fe96f000 {
> > + compatible = "renesas,fcpv";
> > + reg = <0 0xfe96f000 0 0x200>;
> > + clocks = < CPG_MOD 607>;
> > + power-domains = < R8A77990_PD_ALWAYS_ON>;
> > + resets = < 607>;
> > + iommus = <_vp0 5>;
> > + };
> > +
> > + vspi0: vsp@fe9a {
> > + compatible = "renesas,vsp2";
> > + reg = <0 0xfe9a 0 0x8000>;
> > + interrupts = ;
> > + clocks = < CPG_MOD 622>;
>
> R-Car Series, 3rd Generation, v1.00, Table Table 8A.21 indicates
> that this clock should be < CPG_MOD 631>. The clock above is
> (according to my reading of the documentation) correctly
> used for vspd1 below.
Bad copy and paste, thank you for pointing it out, it will be fixed in v3.
> > + power-domains = < R8A77990_PD_ALWAYS_ON>;
> > + resets = < 631>;
> > + renesas,fcp = <>;
> > + };
> > +
> > + fcpvi0: fcp@fe9af000 {
> > + compatible = "renesas,fcpv";
> > + reg = <0 0xfe9af000 0 0x200>;
> > + clocks = < CPG_MOD 611>;
> > + power-domains = < R8A77990_PD_ALWAYS_ON>;
> > + resets = < 611>;
> > + iommus = <_vp0 8>;
> > + };
> > +
> > + vspd0: vsp@fea2 {
> > + compatible = "renesas,vsp2";
> > + reg = <0 0xfea2 0 0x7000>;
> > + interrupts = ;
> > + clocks = < CPG_MOD 623>;
> > + power-domains = < R8A77990_PD_ALWAYS_ON>;
> > + resets = < 623>;
> > + renesas,fcp = <>;
> > + };
> > +
> > + fcpvd0: fcp@fea27000 {
> > + compatible = "renesas,fcpv";
> > + reg = <0 0xfea27000 0 0x200>;
> > + clocks = < CPG_MOD 603>;
> > + power-domains = < R8A77990_PD_ALWAYS_ON>;
> > + resets = < 603>;
> > + iommus = <_vi0 8>;
> > + };
> > +
> > + vspd1: vsp@fea28000 {
> > + compatible = "renesas,vsp2";
> > + reg = <0 0xfea28000 0 0x7000>;
> > + interrupts = ;
> > + clocks = < CPG_MOD 622>;
> > + power-domains = < R8A77990_PD_ALWAYS_ON>;
> > + resets = < 622>;
> > + renesas,fcp = <>;
> > + };
> > +
> > + fcpvd1: fcp@fea2f000 {
> > + compatible = "renesas,fcpv";
> > + reg = <0 0xfea2f000 0 0x200>;
> > + clocks = < CPG_MOD 602>;
> > + power-domains = < R8A77990_PD_ALWAYS_ON>;
> > + resets = < 602>;
> > + iommus = <_vi0 9>;
> > + };
> > +
> > + du: display@feb0 {
> > + compatible = "renesas,du-r8a77990";
> > + reg = <0 0xfeb0 0 0x8>;
> > + interrupts = ,
> > +;
> > + clocks = < CPG_MOD 724>,
> > +< CPG_MOD 723>;
> > + clock-names = "du.0", "du.1";
> > + vsps = < 0 0>;
> > + status = "disabled";
> > +
> > + ports {
> > + #address-cells = <1>;
> > +
Re: [PATCH] [RFC]drm: add syncobj timeline support v5
Am 14.09.2018 um 12:37 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.
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
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 | 294 ++---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 4 +-
include/drm/drm_syncobj.h | 62 +++--
include/uapi/drm/drm.h | 1 +
4 files changed, 292 insertions(+), 69 deletions(-)
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index e9ce623d049e..e78d076f2703 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_NORMAL_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,7 +132,7 @@ static int drm_syncobj_fence_get_or_add_callback(struct
drm_syncobj *syncobj,
{
int ret;
- *fence = drm_syncobj_fence_get(syncobj);
+ ret = drm_syncobj_search_fence(syncobj, 0, 0, fence);
if (*fence)
Don't we need to check ret here instead?
return 1;
@@ -133,10 +141,10 @@ 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(>lock)));
- ret = 1;
+ if (fence) {
+ drm_syncobj_search_fence(syncobj, 0, 0, fence);
+ if (*fence)
+ ret = 1;
That doesn't looks correct to me, drm_syncobj_search_fence() would try
to grab the
Re: [Intel-gfx] [PATCH v10 0/2] Add XYUV format support
On Fri, 2018-09-14 at 14:59 +, Alexandru-Cosmin Gheorghe wrote: > On Fri, Sep 14, 2018 at 02:49:09PM +, Lisovskiy, Stanislav wrote: > > On Fri, 2018-09-14 at 15:34 +0100, Saarinen, Jani wrote: > > > Hi, > > > > > > > -Original Message- > > > > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org > > > > ] On > > > > Behalf > > > > Of Lisovskiy, Stanislav > > > > Sent: perjantai 14. syyskuuta 2018 17.31 > > > > To: ville.syrj...@linux.intel.com > > > > Cc: intel-...@lists.freedesktop.org; Syrjala, Ville > > > > > > > intel.com>; > > > > Heikkila, Juha-pekka ; dri- > > > > de...@lists.freedesktop.org; Peres, Martin > > > com> > > > > Subject: Re: [Intel-gfx] [PATCH v10 0/2] Add XYUV format > > > > support > > > > > > > > On Fri, 2018-09-14 at 16:47 +0300, Ville Syrjälä wrote: > > > > > On Fri, Sep 14, 2018 at 01:36:32PM +, Lisovskiy, > > > > > Stanislav > > > > > wrote: > > > > > > On Fri, 2018-09-07 at 11:45 +0300, Stanislav Lisovskiy > > > > > > wrote: > > > > > > > Introduced new XYUV scan-in format for framebuffer and > > > > > > > added > > > > > > > support for it to i915(SkyLake+). > > > > > > > > > > > > > > Stanislav Lisovskiy (2): > > > > > > > drm: Introduce new DRM_FORMAT_XYUV > > > > > > > drm/i915: Adding YUV444 packed format support for skl+ > > > > > > > > > > > > > > drivers/gpu/drm/drm_fourcc.c | 1 + > > > > > > > drivers/gpu/drm/i915/i915_reg.h | 2 +- > > > > > > > drivers/gpu/drm/i915/intel_display.c | 15 > > > > > > > +++ > > > > > > > drivers/gpu/drm/i915/intel_sprite.c | 2 ++ > > > > > > > include/uapi/drm/drm_fourcc.h| 1 + > > > > > > > 5 files changed, 20 insertions(+), 1 deletion(-) > > > > > > > > > > > > > > > > > > > Ping. There is an IGT patch which got Reviewed-by Ville. > > > > > > This one left in order to get XYUV support. > > > > > > > > > > Did we figure out userspace for this? > > > > > > > > > > Was the conflict solved with the other guy (forgot who it is) > > > > > trying > > > > > to add the same format with a different name? > > > > > > > > Currently for userspace we have VLC(checked with Juha-Pekka) > > > > and > > > > also IGT > > > > test case. > > > > > > > > I think those guys were from ARM and they were adding also > > > > support > > > > for > > > > XYUV. The only difference was that they called XYUV, like > > > > XYUV > > > > something. > > > > Our patches were otherwise identical regarding drm_fourcc.c > > > > part, I > > > > don't > > > > see their stuff merged, but I guess it really shouldn't matter, > > > > who > > > > does this > > > > first. i915 specific part doesn't conflict with their stuff. To > > > > be > > > > honest, I forgot > > > > the guy's name neither could find his email in my mailbox. > > > > So hopefully somebody shows up here. > > > > > > Stan: > > > Alexandru-Cosmin Gheorghe ? > > > > > > > Exactly, found now. Thanks for the hint! > > Yes, that's me. > Not a real conflict here, as long as your patches are ready to be > merged feel free to do it and I will just rebase my series on top of > that. I can change DRM_FORMAT_XYUV naming to DRM_FORMAT_XYUV also, so that my patch series then is compatible with yours. > > > > > > > > > > > > > > > > > > > > > -- > > > > Best Regards, > > > > > > > > Lisovskiy Stanislav > > > > ___ > > > > Intel-gfx mailing list > > > > intel-...@lists.freedesktop.org > > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx > > > > -- > > Best Regards, > > > > Lisovskiy Stanislav > > ___ > > dri-devel mailing list > > dri-devel@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > -- Best Regards, Lisovskiy Stanislav ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH v10 0/2] Add XYUV format support
On Fri, 2018-09-14 at 20:05 +0300, Juha-Pekka Heikkilä wrote: > > Lisovskiy, Stanislav kirjoitti 14.9.2018 klo 17.30: > > On Fri, 2018-09-14 at 16:47 +0300, Ville Syrjälä wrote: > > > On Fri, Sep 14, 2018 at 01:36:32PM +, Lisovskiy, Stanislav > > > wrote: > > > > On Fri, 2018-09-07 at 11:45 +0300, Stanislav Lisovskiy wrote: > > > > > Introduced new XYUV scan-in format for framebuffer and > > > > > added support for it to i915(SkyLake+). > > > > > > > > > > Stanislav Lisovskiy (2): > > > > >drm: Introduce new DRM_FORMAT_XYUV > > > > >drm/i915: Adding YUV444 packed format support for skl+ > > > > > > > > > > drivers/gpu/drm/drm_fourcc.c | 1 + > > > > > drivers/gpu/drm/i915/i915_reg.h | 2 +- > > > > > drivers/gpu/drm/i915/intel_display.c | 15 +++ > > > > > drivers/gpu/drm/i915/intel_sprite.c | 2 ++ > > > > > include/uapi/drm/drm_fourcc.h| 1 + > > > > > 5 files changed, 20 insertions(+), 1 deletion(-) > > > > > > > > > > > > > Ping. There is an IGT patch which got Reviewed-by Ville. > > > > This one left in order to get XYUV support. > > > > > > Did we figure out userspace for this? > > > > > > Was the conflict solved with the other guy (forgot who it is) > > > trying to add the same format with a different name? > > > > Currently for userspace we have VLC(checked with Juha-Pekka) and > > also IGT test case. > > Hei, no. VLC was *not* showing the mode correctly back then when we > tested. VLC kms plugin is able to initialize the mode and it's all > stable but VLC didn't have correct video converter to reach matching > xYUV output. You remember Stan we tried to increase the recursion > for > decoding in case it would help? VLC doesn't have codec which produce > correct output, one of those xxx -> YUV plug-ins in VLC should be > patched before VLC can be considered as userspace for this mode. Ok, I remember we managed to make it work somehow and saw some picture, so for some reason I thought it is working already. What is our plan then? Should we try to improve VLC codecs/plugins or may be I should then work with some other user space case? > > /Juha-Pekka > > > > > I think those guys were from ARM and they were adding also support > > for > > XYUV. The only difference was that they called XYUV, like XYUV > > something. > > Our patches were otherwise identical regarding drm_fourcc.c part, I > > don't see their stuff merged, but I guess it really shouldn't > > matter, > > who does this first. i915 specific part doesn't conflict with their > > stuff. To be honest, I forgot the guy's name neither could find his > > email in my mailbox. > > So hopefully somebody shows up here. > > > > > -- Best Regards, Lisovskiy Stanislav ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105530] Stuttering on Raven Ridge when TearFree is on
https://bugs.freedesktop.org/show_bug.cgi?id=105530 --- Comment #14 from Andrew Sheldon --- Okay, so on the secondary issue of the perceived framerate dropping in some cases, it appears to be related to GPU load. If the GPU usage reaches 100% the perceived framerate drops dramatically, whereas if I lower settings or artificially limit the FPS such that 100% usage isn't reached, the degradation doesn't happen. Is this expected behaviour? If so, it might be useful to have the ability to disable the feature for fullscreen windows, much like compositing managers have the ability to unredirect fullscreen windows. -- 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 v2 12/16] arm64: dts: renesas: r8a77990: Add I2C device nodes
Hi Simon,
On Monday, 17 September 2018 10:33:43 EEST Simon Horman wrote:
> On Fri, Sep 14, 2018 at 12:10:42PM +0300, Laurent Pinchart wrote:
> > From: Takeshi Kihara
> >
> > Add device nodes for I2C ch{0,1,2,3,4,5,6,7} to R-Car E3 R8A77990 device
> > tree.
> >
> > Signed-off-by: Takeshi Kihara
> > Signed-off-by: Jacopo Mondi
> > Tested-by: Jacopo Mondi
> > ---
> >
> > arch/arm64/boot/dts/renesas/r8a77990.dtsi | 123 +
> > 1 file changed, 123 insertions(+)
>
> I believe this duplicates the following patch already queued-up for
> v4.20.
>
> Fixes: bc011dfa3065 ("arm64: dts: renesas: r8a77990: Add I2C device nodes")
Yes, it does, it was just included it for completeness of the patch series
given that the commit queued for v4.20 isn't in the base branch.
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 05/20] drm/meson: Use drm_fbdev_generic_setup()
Hi Noralf, Daniel, On 14/09/2018 18:33, Noralf Trønnes wrote: > > Den 14.09.2018 10.23, skrev Neil Armstrong: >> Hi Daniel, >> >> On 13/09/2018 16:55, Daniel Vetter wrote: >>> On Thu, Sep 13, 2018 at 04:26:53PM +0200, Neil Armstrong wrote: Hi Daniel, On 13/09/2018 15:21, Daniel Vetter wrote: > On Wed, Sep 12, 2018 at 01:06:07PM +0200, Noralf Trønnes wrote: >> Den 12.09.2018 12.57, skrev Noralf Trønnes: >>> (Cc: Daniel Vetter) >>> >> Somehow that CC was dropped somewhere after leaving email client. >> Trying once more. > Yeah I just made myself unpopular. If you want SMEM_START, then you need > to carry a local patch now. virt_to_pfn on the vmap should work. It's > about 2 lines, including the change to drop HIDE_SMEM_START. Would it be totally unacceptable to add such 2 line : - enabled by a specific config depending on EXPERT and narrowed to specific platforms - printing a big fat pr_warning_once when used - with a big fat comment specifying when this code will be dropped and why we should not activate it >>> module_param_debug auto-taints your kernel, I'd just go with that. Plus >>> CONFIG_EXPERT (or CONFIG_BROKEN). >> OK, I think you mean module_param_unsafe, but I see the point. >> >>> But yes, I think that's something I'll happily ack. Must be acked by Dave >>> (and perhaps a few others too), since defacto this means we now suddenly >>> care about closed source blobs. I'd say get someone from amd and a few of >>> the driver maintainers on board with this (nouveau, Eric, Rob, Lucas, >>> ...), to make sure it really represents community consensus. >> I'll drop something, but I'm afraid a kernel won't have this hack, shouldn't >> this serie be delayed for a release ? > > It's not this series that drops smem_start support. > It happened in commit 894a677f4b3e: > drm/cma-helper: Use the generic fbdev emulation > > This series only deals with the fb_helper callbacks. > >> @Noaralf, do you have a branch somewhere I can base a work on ? > > I haven't got a git repo, but you can apply the patches from patchwork: > > [01/20] drm/fb-helper: Improve error reporting in setup > curl https://patchwork.freedesktop.org/patch/247860/mbox/ | git am > > [05/20] drm/meson: Use drm_fbdev_generic_setup() > curl https://patchwork.freedesktop.org/patch/247868/mbox/ | git am Thanks, I'll try to drop something, but not immediately. Neil > > Noralf. > >> Neil >> >>> Cheers, Daniel >>> Neil > And if consensus is that hiding SMEM_START is not a nice idea, then I'm > sure we can reintroduce it through some slightly unpretty backdoor, even > with Noralf's generic code. So not really a good reason to reject the > cleanup I think. > -Daniel > > >>> Den 12.09.2018 11.56, skrev Maxime Ripard: On Wed, Sep 12, 2018 at 11:48:34AM +0200, Neil Armstrong wrote: > Hi Noralf, > > On 08/09/2018 15:46, Noralf Trønnes wrote: >> The CMA helper is already using the >> drm_fb_helper_generic_probe part of >> the generic fbdev emulation. This patch makes full use of the generic >> fbdev emulation by using its drm_client callbacks. This means that >> drm_mode_config_funcs->output_poll_changed and >> drm_driver->lastclose are >> now handled by the emulation code. Additionally fbdev >> unregister happens >> automatically on drm_dev_unregister(). >> >> The drm_fbdev_generic_setup() call is put after >> drm_dev_register() in the >> driver. This is done to highlight the fact that fbdev emulation is an >> internal client that makes use of the driver, it is not part of the >> driver as such. If fbdev setup fails, an error is printed, >> but the driver >> succeeds probing. > I can't really ack/nack this move, on one side it's great to have a > generic fbdev emulation instead of the old fbdev code, but on the > other side the Amlogic platform (like allwinner, samsung, rockchip, > ...) still relies on an Fbdev variant of the libMali that uses > smem_start... > > I know it's dirty and fbdev based code should be legacy now, but I > consider it like an user-space breakage... > > I'll be happy if ARM provided it's Mali vendors a Fbdev libMali that > could use FBINFO_HIDE_SMEM_START and allocate BO's from the DRM > driver, it won't be the case and it will never be the case until the > Lima projects finalizes. > > So for me it's a no-go until Lima lands upstream in Linux *and* Mesa. My feelings exactly. If the choice is between reducing the DRM driver by a couple of dozens of lines or keeping the mali working, I'll pick the latter, every single day. >>> I don't know the reasoning for blocking smem_start other than what
[Bug 105530] Stuttering on Raven Ridge when TearFree is on
https://bugs.freedesktop.org/show_bug.cgi?id=105530 --- Comment #13 from Andrew Sheldon --- I should say that part of the bug seems to be worked around with amdgpu.dc=0 in that the stuttering is gone. But the other issue, that of the output looking like it's running at half the framerate in certain games (only with TearFree enabled), is not. Perhaps I should open another bug for that issue, though. -- 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 1/4] drm: sun4i: drop second PLL from A64 HDMI PHY
The A64 HDMI PHY seems to be not able to use the second video PLL as
clock parent in experiments.
Drop the support for the second PLL from A64 HDMI PHY driver.
Fixes: b46e2c9f5f64 ("drm/sun4i: Add support for A64 HDMI PHY")
Signed-off-by: Icenowy Zheng
---
Changes in v2:
- none.
drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
index 82502b351aec..a564b5dfe082 100644
--- a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
+++ b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
@@ -398,7 +398,6 @@ static struct regmap_config sun8i_hdmi_phy_regmap_config = {
static const struct sun8i_hdmi_phy_variant sun50i_a64_hdmi_phy = {
.has_phy_clk = true,
- .has_second_pll = true,
.phy_init = _hdmi_phy_init_h3,
.phy_disable = _hdmi_phy_disable_h3,
.phy_config = _hdmi_phy_config_h3,
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
