Re: [RFC PATCH xserver] modesetting: re-set the crtc's mode when link-status goes BAD
On Sun, Apr 02, 2017 at 07:21:09PM -0700, Eric Anholt wrote: > Daniel Vetter writes: > > > On Fri, Mar 31, 2017 at 05:22:09PM -0700, Eric Anholt wrote: > >> Manasi Navare writes: > >> > >> > On Fri, Mar 31, 2017 at 01:08:41PM -0700, Eric Anholt wrote: > >> >> Manasi Navare writes: > >> >> > >> >> > On Thu, Mar 30, 2017 at 05:37:55PM -0700, Eric Anholt wrote: > >> >> >> Martin Peres writes: > >> >> >> > >> >> >> > On 26/01/17 14:37, Martin Peres wrote: > >> >> >> >> Despite all the careful planing of the kernel, a link may become > >> >> >> >> insufficient to handle the currently-set mode. At this point, the > >> >> >> >> kernel should mark this particular configuration as being broken > >> >> >> >> and potentially prune the mode before setting the offending > >> >> >> >> connector's > >> >> >> >> link-status to BAD and send the userspace a hotplug event. This > >> >> >> >> may > >> >> >> >> happen right after a modeset or later on. > >> >> >> >> > >> >> >> >> When available, we should use the link-status information to reset > >> >> >> >> the wanted mode. > >> >> >> >> > >> >> >> >> Signed-off-by: Martin Peres > >> >> >> > > >> >> >> > The relevant kernel patches have landed in drm-tip about a month > >> >> >> > ago. > >> >> >> > > >> >> >> > Eric, would you mind providing feedback on or merging this patch? > >> >> >> > >> >> >> The later discussion has sounded like the kernel will (always) prune > >> >> >> the > >> >> >> mode when we re-query, meaning that it doesn't make any sense to try > >> >> >> to > >> >> >> re-set to the old mode. Is this not the case? > >> >> > > >> >> > > >> >> > No the kernel will simply send a hotplug with link status as bad > >> >> > and then after that point its userspace driver's responsibility > >> >> > to check if link status is BAD, retry the same mode and if it fails > >> >> > then re probe. > >> >> > >> >> So the kernel will sometimes allow the same mode to be re-set with the > >> >> same bpp? > >> > > >> > So when userspace driver re-sets the same mode, the kernel will call the > >> > mode valid function where it will see it can allow the sam mode perhaps > >> > at a lower bpp now since the link parameters are lowered. > >> > So the mode which failed at 30 bpp, might still work at 18bpp and is > >> > better going to a lower resolution. > >> > >> The question was whether the kernel will ever allow the same mode at the > >> same bpp, since that's what this patch tries to do. > > > > Yes, this can happen. Doing a full modeset with recomputing clocks and > > everything behind userspace's back might not be something the kernel > > driver can pull of with a reasonable amount of effort, hence why we punt > > to userspace. The interface spec makes this a CAN, not WILL, to allow less > > unreasonable hw to handle these cases directly in the kernel driver. E.g. > > plain link-retraining is handled in i915.ko still. > > So in that case you do need userspace to re-request the same mode at the > same bpp? So yes because when userspace requests the same mode at same bpp, kernel will still call intel_dp->mod_valid which validates the mode against 18bpp so if the requested mode can be displayed at the lowest of 18bpp, then the kernel will try to do the modeset for that mode at lower bpp. What I am trying to say is irrespective of what bpp userspace requests, kernel will check if it can display that at the lowest of 18bpp. Regards Manasi > ___ > 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
[PATCH 2/6 v2] drm/nouveau: Pin bos from imported dma-bufs to GTT. (v2)
From: Christopher James Halse Rogers
Attempting to migrate the bo will break the sharing of the buffer.
v2: Error-check the nouveau_bo_pin call; it can fail.
Signed-off-by: Christopher James Halse Rogers
---
drivers/gpu/drm/nouveau/nouveau_prime.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nouveau_prime.c
b/drivers/gpu/drm/nouveau/nouveau_prime.c
index 1fefc93af1d7..ad5eaf70c8e2 100644
--- a/drivers/gpu/drm/nouveau/nouveau_prime.c
+++ b/drivers/gpu/drm/nouveau/nouveau_prime.c
@@ -76,6 +76,12 @@ struct drm_gem_object
*nouveau_gem_prime_import_sg_table(struct drm_device *dev,
return ERR_PTR(ret);
nvbo->valid_domains = NOUVEAU_GEM_DOMAIN_GART;
+ /* pin imported buffer to GTT */
+ ret = nouveau_bo_pin(nvbo, TTM_PL_FLAG_TT, false);
+ if (ret) {
+ nouveau_bo_ref(NULL, &nvbo);
+ return ERR_PTR(ret);
+ }
/* Initialize the embedded gem-object. We return a single gem-reference
* to the caller, instead of a normal nouveau_bo ttm reference. */
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 98897] Macbook pro 11,5 screen flicker when AC adapter plugged in
https://bugs.freedesktop.org/show_bug.cgi?id=98897 --- Comment #27 from extr15 --- seems if I boot without AC adapter plugged in, then there is no flicker problem. plug in AC is OK after I log in my computer. but when I suspend and wakeup with AC plugged in, the screen flicker will happen. any idea? -- 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 7/7 v2] drm/radeon: Refuse to migrate a prime BO to VRAM. (v2)
From: Christopher James Halse Rogers
BOs shared via dma-buf, either imported or exported, cannot sensibly be
migrated to VRAM
without breaking the dma-buf sharing. Refuse userspace requests to migrate to
VRAM,
ensure such BOs are not migrated during command submission, and refuse to pin
them
to VRAM.
v2: Don't pin BOs in GTT. Instead, refuse to migrate BOs to VRAM.
Signed-off-by: Christopher James Halse Rogers
---
drivers/gpu/drm/radeon/radeon_cs.c | 10 ++
drivers/gpu/drm/radeon/radeon_gem.c| 4
drivers/gpu/drm/radeon/radeon_object.c | 5 +
3 files changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
b/drivers/gpu/drm/radeon/radeon_cs.c
index a8442f7196d6..df6b58c08544 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -164,6 +164,16 @@ static int radeon_cs_parser_relocs(struct radeon_cs_parser
*p)
p->relocs[i].allowed_domains = domain;
}
+ /* Objects shared as dma-bufs cannot be moved to VRAM */
+ if (p->relocs[i].robj->prime_shared_count) {
+ p->relocs[i].allowed_domains &= ~RADEON_GEM_DOMAIN_VRAM;
+ if (!p->relocs[i].allowed_domains) {
+ DRM_ERROR("BO associated with dma-buf cannot "
+ "be moved to VRAM\n");
+ return -EINVAL;
+ }
+ }
+
p->relocs[i].tv.bo = &p->relocs[i].robj->tbo;
p->relocs[i].tv.shared = !r->write_domain;
diff --git a/drivers/gpu/drm/radeon/radeon_gem.c
b/drivers/gpu/drm/radeon/radeon_gem.c
index 96683f5b2b1b..067ea7d7658a 100644
--- a/drivers/gpu/drm/radeon/radeon_gem.c
+++ b/drivers/gpu/drm/radeon/radeon_gem.c
@@ -120,6 +120,10 @@ static int radeon_gem_set_domain(struct drm_gem_object
*gobj,
return r;
}
}
+ if (domain == RADEON_GEM_DOMAIN_VRAM && robj->prime_shared_count) {
+ /* A BO that is associated with a dma-buf cannot be sensibly
migrated to VRAM */
+ return -EINVAL;
+ }
return 0;
}
diff --git a/drivers/gpu/drm/radeon/radeon_object.c
b/drivers/gpu/drm/radeon/radeon_object.c
index 74b276060c20..bec2ec056de4 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -352,6 +352,11 @@ int radeon_bo_pin_restricted(struct radeon_bo *bo, u32
domain, u64 max_offset,
return 0;
}
+ if (bo->prime_shared_count && domain == RADEON_GEM_DOMAIN_VRAM) {
+ /* A BO shared as a dma-buf cannot be sensibly migrated to VRAM
*/
+ return -EINVAL;
+ }
+
radeon_ttm_placement_from_domain(bo, domain);
for (i = 0; i < bo->placement.num_placement; i++) {
/* force to pin into visible video ram */
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 6/7] drm/radeon: Maintain prime import/export refcount for BOs
From: Christopher James Halse Rogers
Signed-off-by: Christopher James Halse Rogers
---
drivers/gpu/drm/radeon/radeon.h | 1 +
drivers/gpu/drm/radeon/radeon_prime.c | 6 ++
2 files changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 44e0c5ed6418..1094325c1877 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -499,6 +499,7 @@ struct radeon_bo {
u32 tiling_flags;
u32 pitch;
int surface_reg;
+ unsignedprime_shared_count;
/* list of all virtual address to which this bo
* is associated to
*/
diff --git a/drivers/gpu/drm/radeon/radeon_prime.c
b/drivers/gpu/drm/radeon/radeon_prime.c
index f3609c97496b..7110d403322c 100644
--- a/drivers/gpu/drm/radeon/radeon_prime.c
+++ b/drivers/gpu/drm/radeon/radeon_prime.c
@@ -77,6 +77,7 @@ struct drm_gem_object
*radeon_gem_prime_import_sg_table(struct drm_device *dev,
list_add_tail(&bo->list, &rdev->gem.objects);
mutex_unlock(&rdev->gem.mutex);
+ bo->prime_shared_count = 1;
return &bo->gem_base;
}
@@ -91,6 +92,9 @@ int radeon_gem_prime_pin(struct drm_gem_object *obj)
/* pin buffer into GTT */
ret = radeon_bo_pin(bo, RADEON_GEM_DOMAIN_GTT, NULL);
+ if (likely(ret == 0))
+ bo->prime_shared_count++;
+
radeon_bo_unreserve(bo);
return ret;
}
@@ -105,6 +109,8 @@ void radeon_gem_prime_unpin(struct drm_gem_object *obj)
return;
radeon_bo_unpin(bo);
+ if (bo->prime_shared_count)
+ bo->prime_shared_count--;
radeon_bo_unreserve(bo);
}
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
linux-next: build failure after merge of the drm-misc tree
Hi all,
After merging the drm-misc tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c: In function 'vmw_sou_crtc_page_flip':
drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c:327:8: error: too few arguments to
function 'drm_atomic_helper_page_flip'
ret = drm_atomic_helper_page_flip(crtc, new_fb, NULL, flags);
^
In file included from drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c:31:0:
include/drm/drm_atomic_helper.h:126:5: note: declared here
int drm_atomic_helper_page_flip(struct drm_crtc *crtc,
^
drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c: In function 'vmw_stdu_crtc_page_flip':
drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c:508:8: error: too few arguments to
function 'drm_atomic_helper_page_flip'
ret = drm_atomic_helper_page_flip(crtc, new_fb, NULL, flags);
^
In file included from drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c:32:0:
include/drm/drm_atomic_helper.h:126:5: note: declared here
int drm_atomic_helper_page_flip(struct drm_crtc *crtc,
^
Caused by commit
41292b1fa13a ("drm: Add acquire ctx parameter to ->page_flip(_target)")
interacting with commits
904bb5e5817f ("drm/vmwgfx: Switch over to internal atomic API for STDU")
b0119cb9229d ("drm/vmwgfx: Switch over to internal atomic API for SOU and
LDU")
from the drm tree.
I added this merge fix patch for today:
From: Stephen Rothwell
Date: Mon, 3 Apr 2017 13:25:55 +1000
Subject: [PATCH] drm/vmwgfx: merge fixup for page_flip API change
Signed-off-by: Stephen Rothwell
---
drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
index 02b8f2541dca..8d7dc9def7c2 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
@@ -324,7 +324,7 @@ static int vmw_sou_crtc_page_flip(struct drm_crtc *crtc,
return -EINVAL;
flags &= ~DRM_MODE_PAGE_FLIP_ASYNC;
- ret = drm_atomic_helper_page_flip(crtc, new_fb, NULL, flags);
+ ret = drm_atomic_helper_page_flip(crtc, new_fb, NULL, flags, ctx);
if (ret) {
DRM_ERROR("Page flip error %d.\n", ret);
return ret;
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
index e59bbcd8b226..bad31bdf09b6 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
@@ -505,7 +505,7 @@ static int vmw_stdu_crtc_page_flip(struct drm_crtc *crtc,
* don't hand it to the helper.
*/
flags &= ~DRM_MODE_PAGE_FLIP_ASYNC;
- ret = drm_atomic_helper_page_flip(crtc, new_fb, NULL, flags);
+ ret = drm_atomic_helper_page_flip(crtc, new_fb, NULL, flags, ctx);
if (ret) {
DRM_ERROR("Page flip error %d.\n", ret);
return ret;
--
2.11.0
--
Cheers,
Stephen Rothwell
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/6 (v2)] drm/amdgpu: Refuse to pin or change acceptable domains of prime BOs to VRAM. (v2)
From: Christopher James Halse Rogers
Migration to VRAM will break the sharing, resulting in rendering on the
exporting GPU never becoming
visible on the importing GPU.
v2: Don't pin BOs to GTT. Instead, refuse to migrate them out of GTT.
Signed-off-by: Christopher James Halse Rogers
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c| 5 +
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 4
2 files changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
index 106cf83c2e6b..bc5356d0a13d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
@@ -679,6 +679,11 @@ int amdgpu_gem_op_ioctl(struct drm_device *dev, void *data,
break;
}
case AMDGPU_GEM_OP_SET_PLACEMENT:
+ if (robj->prime_shared_count && (args->value &
AMDGPU_GEM_DOMAIN_VRAM)) {
+ r = -EINVAL;
+ amdgpu_bo_unreserve(robj);
+ break;
+ }
if (amdgpu_ttm_tt_get_usermm(robj->tbo.ttm)) {
r = -EPERM;
amdgpu_bo_unreserve(robj);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index be80a4a68d7b..323580740a74 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -665,6 +665,10 @@ int amdgpu_bo_pin_restricted(struct amdgpu_bo *bo, u32
domain,
if (WARN_ON_ONCE(min_offset > max_offset))
return -EINVAL;
+ /* A shared bo cannot be migrated to VRAM */
+ if (bo->prime_shared_count && (domain == AMDGPU_GEM_DOMAIN_VRAM))
+ return -EINVAL;
+
if (bo->pin_count) {
uint32_t mem_type = bo->tbo.mem.mem_type;
--
2.11.0
___
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 conflicts in:
drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
between commits:
904bb5e5817f ("drm/vmwgfx: Switch over to internal atomic API for STDU")
b0119cb9229d ("drm/vmwgfx: Switch over to internal atomic API for SOU and
LDU")
from the drm tree and commit:
a4eff9aa6db8 ("drm: Add acquire ctx parameter to ->set_config")
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.
From: Stephen Rothwell
Date: Mon, 3 Apr 2017 13:04:36 +1000
Subject: [PATCH] drm/vmwgfx: merge fixup for set_config API change
Signed-off-by: Stephen Rothwell
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 6 --
drivers/gpu/drm/vmwgfx/vmwgfx_kms.h | 5 -
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index c18c81f63ac3..2517debf214d 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -2940,6 +2940,7 @@ vmw_kms_create_implicit_placement_property(struct
vmw_private *dev_priv,
* vmw_kms_set_config - Wrapper around drm_atomic_helper_set_config
*
* @set: The configuration to set.
+ * @ctx: lock acquisition context
*
* The vmwgfx Xorg driver doesn't assign the mode::type member, which
* when drm_mode_set_crtcinfo is called as part of the configuration setting
@@ -2947,10 +2948,11 @@ vmw_kms_create_implicit_placement_property(struct
vmw_private *dev_priv,
* the vmwgfx modesetting. So explicitly clear that member before calling
* into drm_atomic_helper_set_config.
*/
-int vmw_kms_set_config(struct drm_mode_set *set)
+int vmw_kms_set_config(struct drm_mode_set *set,
+ struct drm_modeset_acquire_ctx *ctx)
{
if (set && set->mode)
set->mode->type = 0;
- return drm_atomic_helper_set_config(set);
+ return drm_atomic_helper_set_config(set, ctx);
}
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h
index 9c161d29aaeb..ecafa9a7648e 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h
@@ -453,6 +453,9 @@ int vmw_kms_stdu_dma(struct vmw_private *dev_priv,
bool to_surface,
bool interruptible);
-int vmw_kms_set_config(struct drm_mode_set *set);
+struct drm_modeset_acquire_ctx;
+
+int vmw_kms_set_config(struct drm_mode_set *set,
+ struct drm_modeset_acquire_ctx *ctx);
#endif
--
2.11.0
--
Cheers,
Stephen Rothwell
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH xserver] modesetting: re-set the crtc's mode when link-status goes BAD
Daniel Vetter writes: > On Fri, Mar 31, 2017 at 05:22:09PM -0700, Eric Anholt wrote: >> Manasi Navare writes: >> >> > On Fri, Mar 31, 2017 at 01:08:41PM -0700, Eric Anholt wrote: >> >> Manasi Navare writes: >> >> >> >> > On Thu, Mar 30, 2017 at 05:37:55PM -0700, Eric Anholt wrote: >> >> >> Martin Peres writes: >> >> >> >> >> >> > On 26/01/17 14:37, Martin Peres wrote: >> >> >> >> Despite all the careful planing of the kernel, a link may become >> >> >> >> insufficient to handle the currently-set mode. At this point, the >> >> >> >> kernel should mark this particular configuration as being broken >> >> >> >> and potentially prune the mode before setting the offending >> >> >> >> connector's >> >> >> >> link-status to BAD and send the userspace a hotplug event. This may >> >> >> >> happen right after a modeset or later on. >> >> >> >> >> >> >> >> When available, we should use the link-status information to reset >> >> >> >> the wanted mode. >> >> >> >> >> >> >> >> Signed-off-by: Martin Peres >> >> >> > >> >> >> > The relevant kernel patches have landed in drm-tip about a month ago. >> >> >> > >> >> >> > Eric, would you mind providing feedback on or merging this patch? >> >> >> >> >> >> The later discussion has sounded like the kernel will (always) prune >> >> >> the >> >> >> mode when we re-query, meaning that it doesn't make any sense to try to >> >> >> re-set to the old mode. Is this not the case? >> >> > >> >> > >> >> > No the kernel will simply send a hotplug with link status as bad >> >> > and then after that point its userspace driver's responsibility >> >> > to check if link status is BAD, retry the same mode and if it fails >> >> > then re probe. >> >> >> >> So the kernel will sometimes allow the same mode to be re-set with the >> >> same bpp? >> > >> > So when userspace driver re-sets the same mode, the kernel will call the >> > mode valid function where it will see it can allow the sam mode perhaps >> > at a lower bpp now since the link parameters are lowered. >> > So the mode which failed at 30 bpp, might still work at 18bpp and is >> > better going to a lower resolution. >> >> The question was whether the kernel will ever allow the same mode at the >> same bpp, since that's what this patch tries to do. > > Yes, this can happen. Doing a full modeset with recomputing clocks and > everything behind userspace's back might not be something the kernel > driver can pull of with a reasonable amount of effort, hence why we punt > to userspace. The interface spec makes this a CAN, not WILL, to allow less > unreasonable hw to handle these cases directly in the kernel driver. E.g. > plain link-retraining is handled in i915.ko still. So in that case you do need userspace to re-request the same mode at the same bpp? signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 100531] [regression] Broken graphics in several games
https://bugs.freedesktop.org/show_bug.cgi?id=100531 --- Comment #4 from Marek Olšák --- Created attachment 130650 --> https://bugs.freedesktop.org/attachment.cgi?id=130650&action=edit possible fix Would you please try this patch? -- 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 104551] Unable to resume from suspend NVIDIA GeForce GTX 650
https://bugzilla.kernel.org/show_bug.cgi?id=104551 --- Comment #9 from Ignacio Taranto (itaran...@gmail.com) --- Created attachment 255723 --> https://bugzilla.kernel.org/attachment.cgi?id=255723&action=edit Hardware information (hwinfo --short) -- 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 104551] Unable to resume from suspend NVIDIA GeForce GTX 650
https://bugzilla.kernel.org/show_bug.cgi?id=104551 Ignacio Taranto (itaran...@gmail.com) changed: What|Removed |Added Kernel Version|3.16.7-24-desktop |4.4.57-18.3-default Summary|Unable to resume from |Unable to resume from |suspend NVIDIA GeFroce GTX |suspend NVIDIA GeForce GTX |650 |650 -- 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 104551] Unable to resume from suspend NVIDIA GeFroce GTX 650
https://bugzilla.kernel.org/show_bug.cgi?id=104551 Ignacio Taranto (itaran...@gmail.com) changed: What|Removed |Added Summary|Unable to resume from |Unable to resume from |suspend AMD Radeon HD 6570 |suspend NVIDIA GeFroce GTX ||650 -- 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 104551] Unable to resume from suspend AMD Radeon HD 6570
https://bugzilla.kernel.org/show_bug.cgi?id=104551 Ignacio Taranto (itaran...@gmail.com) changed: What|Removed |Added CC||itaran...@gmail.com --- Comment #8 from Ignacio Taranto (itaran...@gmail.com) --- Created attachment 255721 --> https://bugzilla.kernel.org/attachment.cgi?id=255721&action=edit NVIDIA GTX 650 suspend to RAM S1 I'm updating the title of the bug since I'm no longer using an AMD card on this machine. Instead, I'm using a NVIDIA GTX 650 now. OS: openSUSE Leap 42.2 Motherboard: Gigabyte H61M-USB3-B3 rev1.0 Kernel version: 4.4.57-18.3-default Driver version: 375.39 I'm attaching the kernel log from journalctl after suspending to RAM (S1). After waking up from suspend, I got a black screen. I had to use the REISUB magic command to reboot properly. Although I tested with S1 I'll send and update with S3. -- 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 100531] [regression] Broken graphics in several games
https://bugs.freedesktop.org/show_bug.cgi?id=100531 --- Comment #3 from Jan Ziak <0xe2.0x9a.0...@gmail.com> --- Created attachment 130649 --> https://bugs.freedesktop.org/attachment.cgi?id=130649&action=edit Tomb Raider benchmark screenshot -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/4] drm: Add drm_object lease infrastructure
Daniel Vetter writes: > Still not sure we want to restrict objects on the lessor side. Feels like > unecessary complexity (i.e. more bugs in kernel, that's never good), and > at best only needed for lessors who can't keep track of stuff. It's been useful when hacking existing code, and will help catch application bugs. Limiting access to what you actually need always seems like good practice to me. > I'm also not sure whether we really want sub-leases in v1, that's easy > to add later on, but for now just complicates stuff. Main compositor > should be a full master, VR can be the first lease level, we don't > need more I think for now? We've discussed how leases might be used to implement multi-user support, so offering sub-leases means that environment could also support leasing resources out from the users session. We also just don't know how useful it might be until we explore the space a bit more. Given that it takes years to get new features into distributions, I tend to error on the side of generality. I think a key requirement for acceptance would be a set of robust tests, something I haven't started writing yet. >> +/* Tree of display resource leases, each of which is a drm_master struct >> + * All of these get activated simultaneously, so drm_device master >> points > > &drm_device.master to do a reference in kernel-doc. Please feed this to > kernel-doc in general and make sure the links all point at the right > stuff, and it's all parsed. Thanks, will do. -- -keith signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [BUG][REGRESSION] i915 gpu hangs under load
Am 2. April 2017 13:50:26 MESZ schrieb Thorsten Leemhuis : >Lo! On 22.03.2017 11:36, Jani Nikula wrote: >> On Wed, 22 Mar 2017, Martin Kepplinger wrote: >>> I know something similar is here: >>> https://bugs.freedesktop.org/show_bug.cgi?id=100110 too. >>> But this is rc3 and my machine is totally *not usable*. Let me be >>> annoying :) I hope I can help: >> Please file a bug over at [1]. >> […] >> [1] >https://bugs.freedesktop.org/enter_bug.cgi?product=DRI&component=DRM/Intel > >@Martin: did you file that bug? I could not find one :-/ I did. Got marked as duplicate of https://bugs.freedesktop.org/show_bug.cgi?id=100181 and there's a fix out there. I don't know if it's in rc5 though. > >@Jani: In similar situations could you do me a favour and ask people to >send one more reply to the public list which contains the link to the >bug filed? Regression tracking is quite hard already; searching various >bug tracker for follow up bug entries makes it even harder :-( > >Ciao, Thorsten -- Martin Kepplinger http://martinkepplinger.com sent from mobile ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/4] drm: Add four ioctls for managing drm mode object leases
Daniel Vetter writes: > Should we just use fd for this? Essentially lessors would be required to > keep track of all their pending leases, and just dup() them over to the > client. Would reduce the uapi scope a bit, and if a lessor can't keep > track of it's leases there's a problem. Right now, the lease terminates when the fd closes. If the lessor is holding the fd open, it would have to have some out-of-band indication that the lessee was done so that it could close its copy of the fd. However, it's not clear what value these query APIs have for the lessor in any case; surely it can remember what resources are in each lease without needing a kernel API. For the lessee, this API provides a way of learning about changes to the lease. That would mean getting rid of the lessee id in the requests, which seems good. I added them mostly to make checking the code easier during development; it caught a nasty bug where I was smashing the lessor file_priv with the lessee due to poor choice of variable names in the kernel code. I was thinking this morning that the lessee would like to know not only the ID but also the type of each resources so that it could figure out how to use the lease. I'll rewrite these to only return the resources for the fd provided, but to return both id and type. For listing lessees, I don't see value in allowing the lessor to look at sub-leases made by the lessee, so I'll remove the lessor id from that request and have it just return the list of lessees for the current lessor. > For this one here we could pass the fd of the lease as the argument. I > also still think that for v1 we just want revoke and otherwise invariant > leases. Makes things simpler. Again, that means that lessor would need to hold the lease fd open, which makes it hard to know when the lessee is done. However, there's no reason the lessor should be in control of the lessee's sub-leases, so again, I propose to restrict the scope of lessees to those directly under the lessor. > Non-driver functions please into drm-internal.h, we don't want to let > drivers even see this :-) Thanks! -- -keith signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/nouveau: enable interrupts on cards with 32 intr lines
The code attempts to enable them, but hits an undefined behaviour by
shifting by the entire register's width:
int lines = 32;
u32 mask = (1 << lines) - 1;// on x86
u32 mask = (1 << lines) - 1;// on arm (32)
u32 mask = (1 << lines) - 1;// on arm64
u32 mask = (1ULL << lines) - 1; // everywhere
Signed-off-by: Adam Borowski
---
To be honest, I can't tell the difference other than UBSAN stopping its
complaints, but the current code is obviously wrong.
drivers/gpu/drm/nouveau/nvkm/subdev/gpio/base.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/gpio/base.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/gpio/base.c
index 77c649723ad7..4a57defc99b3 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/gpio/base.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/gpio/base.c
@@ -164,7 +164,7 @@ static int
nvkm_gpio_fini(struct nvkm_subdev *subdev, bool suspend)
{
struct nvkm_gpio *gpio = nvkm_gpio(subdev);
- u32 mask = (1 << gpio->func->lines) - 1;
+ u32 mask = (1ULL << gpio->func->lines) - 1;
gpio->func->intr_mask(gpio, NVKM_GPIO_TOGGLED, mask, 0);
gpio->func->intr_stat(gpio, &mask, &mask);
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/9] drm/vmwgfx: Revert "drm/vmwgfx: Replace numeric parameter like 0444 with macro"
On 2017-03-27 15:17:54, Sinclair Yeh wrote:
> From: Øyvind A. Holm
>
> This reverts commit 2d8e60e8b074 ("drm/vmwgfx: Replace numeric
> parameter like 0444 with macro")
> [...]
> index 45d711e..d31dc34 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> @@ -241,13 +241,13 @@ static int vmwgfx_pm_notifier(struct notifier_block
> *nb, unsigned long val,
> void *ptr);
>
> MODULE_PARM_DESC(enable_fbdev, "Enable vmwgfx fbdev");
> -module_param_named(enable_fbdev, enable_fbdev, int, S_IRUSR | S_IWUSR);
> +module_param_named(enable_fbdev, enable_fbdev, int, 0600);
> MODULE_PARM_DESC(force_dma_api, "Force using the DMA API for TTM pages");
> -module_param_named(force_dma_api, vmw_force_iommu, int, S_IRUSR | S_IWUSR);
> +module_param_named(force_dma_api, vmw_force_iommu, int, 0600);
> MODULE_PARM_DESC(restrict_iommu, "Try to limit IOMMU usage for TTM pages");
> -module_param_named(restrict_iommu, vmw_restrict_iommu, int, S_IRUSR |
> S_IWUSR);
> +module_param_named(restrict_iommu, vmw_restrict_iommu, int, 0600);
> MODULE_PARM_DESC(force_coherent, "Force coherent TTM pages");
> -module_param_named(force_coherent, vmw_force_coherent, int, S_IRUSR |
> S_IWUSR);
> +module_param_named(force_coherent, vmw_force_coherent, int, 0600);
> MODULE_PARM_DESC(restrict_dma_mask, "Restrict DMA mask to 44 bits with
> IOMMU");
> module_param_named(restrict_dma_mask, vmw_restrict_dma_mask, int, S_IRUSR |
> S_IWUSR);
> MODULE_PARM_DESC(assume_16bpp, "Assume 16-bpp when filtering modes");
> --
> 2.7.4
It seems as something has happened to the patch when applied, the last
change is gone, it was in my original patch sent to the list. This
change is missing:
-module_param_named(restrict_dma_mask, vmw_restrict_dma_mask, int, S_IRUSR |
S_IWUSR);
+module_param_named(restrict_dma_mask, vmw_restrict_dma_mask, int, 0600);
I suppose it's to late to fix this exact commit (50f837371dd9) now
because it's part of the request-pull mail sent 2017-03-31 16:32:55
-0700. I can send a new patch created on top of commit 28c954299cd2
("drm/vmwgfx: Properly check display/scanout surface size") that
completes this patch, if it's ok.
Regards,
Øyvind
+-| Øyvind A. Holm - N 60.37604° E 5.9° |-+
| OpenPGP: 0xFB0CBEE894A506E5 - http://www.sunbase.org/pubkey.asc |
| Fingerprint: A006 05D6 E676 B319 55E2 E77E FB0C BEE8 94A5 06E5 |
+| 32db7b80-176e-11e7-8de9-db5caa6d21d3 |-+
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/4] drm: Check mode object lease status in all master ioctl paths
Daniel Vetter writes: > I think it'd be good if we could consolidate all the lease checking into > drm_mode_object_find (respectively __drm_mode_object_find). We'd need to > wire up the fpriv to be able to do that, but we could upstream that patch > right away before anything else. That should take care of most of the > checks in this patch here. That's a good idea. > There's a few things on top: > - filtering the various bitmasks. I think you have most, but we could > perhaps upstream the helpers for these. Yeah, would be nice to get hooks in place soon to avoid rebase adventures later. I guess that would involve shipping a stub drm_lease.h for now? > - filtering object lists (essentially getresources and getplanes ioctls). > - filtering implicit objects in the legacy ioctl. E.g. page_flip done > through atomic doesn't just need the CRTC id, but also the id of the > primary plane plus of the FB_ID atomic property. Similarly for all the > other legacy ioctls. I think we want to make sure there's no difference > here in behaviour. Oh, all of the implicit resource access from the legacy ioctls. Yeah, that will take a bit of research to identify all of them. > Especially for the last one it might be simplest to outright disallow all > legacy ioctl and require that sub-drm_master nodes only get access to the > read-only GET* ioctl (they get that anyway, even when they're not the > current master), plus atomic. Makes it a _lot_ easier to implement. > Downside is that amdgpu _really_ needs to land atomic asap :-) I'd like to avoid that particular dependency as amdgpu is something of a requirement for this particular project... I'll get started fixing the lease checking stuff to try and centralize it. -- -keith signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [BUG][REGRESSION] i915 gpu hangs under load
Lo! On 22.03.2017 11:36, Jani Nikula wrote: > On Wed, 22 Mar 2017, Martin Kepplinger wrote: >> I know something similar is here: >> https://bugs.freedesktop.org/show_bug.cgi?id=100110 too. >> But this is rc3 and my machine is totally *not usable*. Let me be >> annoying :) I hope I can help: > Please file a bug over at [1]. > […] > [1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI&component=DRM/Intel @Martin: did you file that bug? I could not find one :-/ @Jani: In similar situations could you do me a favour and ask people to send one more reply to the public list which contains the link to the bug filed? Regression tracking is quite hard already; searching various bug tracker for follow up bug entries makes it even harder :-( Ciao, Thorsten ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] vmwgfx-next
On Fri, Mar 31, 2017 at 04:32:55PM -0700, Sinclair Yeh wrote: > Hi Dave, > > This series enables atomic mode set for vmwgfx. A number of features and > larger fixes are also included. > > The following changes since commit 8cd3ac52963f2e99f4c21d1c9ce89531ce66c2d6: > > Merge branch 'drm-next-4.12' of git://people.freedesktop.org/~agd5f/linux > into drm-next (2017-03-31 11:47:18 +1000) > > are available in the git repository at: > > git://people.freedesktop.org/~syeh/repos_linux drm-vmwgfx-next > > for you to fetch changes up to 28c954299cd2b5cb5411816c9eeaf3f51ed4638e: > > drm/vmwgfx: Properly check display/scanout surface size (2017-03-31 > 15:21:20 -0700) > > > Sinclair Yeh (18): > drm/vmwgfx: Removed unused snooper.crtc field > drm/vmwgfx: Add universal plane support > drm/vmwgfx: CRTC atomic state > drm/vmwgfx: Plane atomic state > drm/vmwgfx: Connector atomic state > drm/vmwgfx: Add and connect CRTC helper functions > drm/vmwgfx: Add and connect plane helper functions > drm/vmwgfx: Add and connect connector helper function > drm/vmwgfx: Add and connect atomic state object check/commit > drm/vmwgfx: Fixes to vmwgfx_fb > drm/vmwgfx: Switch over to internal atomic API for STDU > drm/vmwgfx: Switch over to internal atomic API for SOU and LDU > drm/vmwgfx: Turn on DRIVER_ATOMIC flag > drm/vmwgfx: Explicityly track screen target width and height > drm/vmwgfx: Skipping fbdev fb pinning for ldu > drm/vmwgfx: Fix LDU X blank screen until mode change issue > drm/vmwgfx: Support topology greater than texture size > drm/vmwgfx: Properly check display/scanout surface size > > Thomas Hellstrom (3): > drm/vmwgfx: Introduce a simple resource type > drm/vmwgfx: Re-implement the stream resource as a simple resource. > drm/vmwgfx: Define an overlaid handle_close ioctl. > > Øyvind A. Holm (1): > drm/vmwgfx: Revert "drm/vmwgfx: Replace numeric parameter like 0444 > with macro" Quite a pile of conflicts of this against the drm-misc-next pull. Nothing too hairy, but just more reasons to remove all the vmwgfx special cases again :-) Also noticed that you've forgotten to garabge collect the legacy cursor functions. Probably a good reason for having vfunc implementations in the same file as the vtable so that they can all be static and the compiler will tell you when you forget to remove stuff. vmwgfx and radeon/amdgpu are anti-pattern drivers in this regard imo. On top it's annoying when you always have to change a prototype in 2 places when doing a subsystem-wide change :-) Cheers, Daniel > drivers/gpu/drm/vmwgfx/Makefile |3 +- > drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 13 +- > drivers/gpu/drm/vmwgfx/vmwgfx_drv.h |2 +- > drivers/gpu/drm/vmwgfx/vmwgfx_fb.c | 27 ++- > drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | > +++-- > drivers/gpu/drm/vmwgfx/vmwgfx_kms.h | 143 -- > drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c | 373 > --- > drivers/gpu/drm/vmwgfx/vmwgfx_resource.c| 254 > > drivers/gpu/drm/vmwgfx/vmwgfx_resource_priv.h | 40 > drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c| 510 > +++- > drivers/gpu/drm/vmwgfx/vmwgfx_simple_resource.c | 256 > > drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c| 937 > > drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 15 +- > drivers/gpu/drm/vmwgfx/vmwgfx_va.c | 168 > include/uapi/drm/vmwgfx_drm.h | 24 +++ > 15 files changed, 2856 insertions(+), 1020 deletions(-) > create mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_simple_resource.c > create mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_va.c > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/4] drm: Add drm_object lease infrastructure
On Sat, Apr 01, 2017 at 10:08:39AM -0700, Keith Packard wrote: > + BUG_ON(__mutex_owner(&master->dev->mode_config.idr_mutex) != current); Forgot to reply on this: lockdep_assert_held + enable lockdep. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 100534] Mouse cursors have abnormally dark pixels around edges
https://bugs.freedesktop.org/show_bug.cgi?id=100534 Bug ID: 100534 Summary: Mouse cursors have abnormally dark pixels around edges Product: DRI Version: XOrg git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: libdrm Assignee: dri-devel@lists.freedesktop.org Reporter: verme...@gmail.com Created attachment 130646 --> https://bugs.freedesktop.org/attachment.cgi?id=130646&action=edit Samples as seen by placing the cursor next to the preview in KDE System Settings. Most visible when viewing cursors with a white or light outline on a white or light background. Light pixels which are semitransparent will appear darkened, even pixels with no significant gray value will appear much darker than they should. For testing cursor sets which illustrate this; KDE Breeze and El Capitan show this effect extremely 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
Re: Proposal for RandR version 1.6, Leases and EDID-based output grabs
On Sat, Apr 01, 2017 at 03:58:58PM -0700, "Keith Packard" wrote:
>
> As a part of the DRM leasing work, we need a way to have the X server
> create a lease and pass it back to an X client. Here's a proposal for
> the RandR specification changes necessary for that. The basic plan is
> pretty simple:
>
> 1. Expose the ability to create a lease for a set of CRTCs and
> OUTPUTs. The X server will have to pick a suitable encoder as that's
> not visible via RandR.
On that, I think we could just unconditionally hand leases all encoders.
Encoders turned out to be a bit an uapi mistake. Neither setcrtc nor
atomic use it, the kernel always selects the right encoder for you. It's
only exposed to give userspace some hints wrt routing (and it's pretty bad
at describing modern restrictions, which often means you get a 1:1
encoder/connector mapping). Unconditionally exposing all encoders for all
lessees would fix all these troubles.
Note that there's also no properties on encoders, those only exist on
crtc, connector and planes.
Kinda more a comment on the kernel side than for xrandr.
-Daniel
> 2. Provide a way to hide some monitors from other clients using EDID
> manufacturer ids and product codes. Outputs with EDID properties
> matching the grab will report 'disconnected' to all clients other
> than the grabbing client. This way, the desktop environment never
> knows that an HMD has been plugged in, so there's no transient
> flicker of desktop being presented to it.
>
> I wanted to make it possible for the X server to set the mode on the
> leased outputs, but I'm not sure how -- I don't want to display the X
> screen on them, and there's no other frame buffer I can name over the
> wire. For now, that means the leasing client will need to set a mode
> itself. If that fails, it can go whack the X configuration over RandR
> and try again, which is all the X server would do anyways.
>
> Comments are welcome; I'll go try to write the code in the next few
> days; it all looks pretty easy at this point.
>
> diff --git a/randrproto.txt b/randrproto.txt
> index 74b7c36..8dded63 100644
> --- a/randrproto.txt
> +++ b/randrproto.txt
> @@ -1,6 +1,6 @@
> The X Resize, Rotate and Reflect Extension
> - Version 1.5.0
> -2015-03-14
> + Version 1.6.0
> +2017-04-01
>
> Jim Gettys
> jim.get...@hp.com
> @@ -9,9 +9,7 @@
> Hewlett Packard Company
>
>Keith Packard
> - keith.pack...@intel.com
> - Open Source Technology Center
> -Intel Corporation
> + kei...@keithp.com
>
> 1. Introduction
>
> @@ -186,6 +184,24 @@ consider as single viewable areas.
> Xinerama's information now comes from the Monitors instead of directly
> from the CRTCs. The Monitor marked as Primary will be listed first.
>
> +1.6. Introduction to version 1.6 of the extension
> +
> +Version 1.6 adds resource leasing.
> +
> + • A 'Lease' is a collection of crtcs and outputs which are made
> + available to a client for direct access via kernel KMS and DRM
> + APIs. This is done by passing a suitable file descriptor back to
> + the client which has access to those resources. While leased, those
> + resources aren't used by the X server.
> +
> +Version 1.6 adds EDID-based output 'grabbing'.
> +
> + • An 'Output Grab' matches a set of EDID Manufacturer ID and product
> + codes. For outputs with matching EDID values, the connected status
> + of the output is only visible to the grabbing client. Other clients
> + will see the output as disconnected. Attempts to configure the
> + grabbed output by other clients will fail.
> +
> 1.99 Acknowledgments
>
> Our thanks to the contributors to the design found on the xpert mailing
> @@ -273,6 +289,10 @@ Mode
> Provider
> A value for a PROVIDER argument does not name a defined PROVIDER.
>
> +OutputGrab
> + A value for an OUTPUTGRAB argument does not name a defined
> + OUTPUTGRAB
> +
> ❧❧❧
>
> 5. Protocol Types
> @@ -419,6 +439,23 @@ MONITORINFO { name: ATOM
>
> ❧❧❧
>
> +5.7. Protocol Types added in version 1.6 of the extension
> +
> +OUTPUTGRAB { XID }
> +
> +EDIDMATCH { id: CARD16
> + code-min: CARD16
> + code-max: CARD16 }
> +
> + These values come from the EDID specification. 'id' is the
> + Manufacturer ID value which is bytes 8 and 9 in the EDID
> + packet, stored in big endian order (MSB first). 'code-min' and
> + 'code-max' define a closed-interval of Manufacturer product
> + codes, which is byte 10 and 11 of the EDID packet, stored in
> + little endian order (LSB first).
> +
> + ❧❧❧
> +
> 6. Extensi
[Bug 98520] System randomly crashes / freezes while playing certain games
https://bugs.freedesktop.org/show_bug.cgi?id=98520 --- Comment #37 from WeKa --- Aunt Google pointed me to this bug report, because I am experimenting something similar. If it has nothing to do with this bug, feel free to delete my writing: I am running kernel 4.9.19 with nouveau module driving a GeForce 9300 GE. My desktop is KDE 4.14.2 and I am using OpenGL 3.1. I am not playing any game on this machine, I am using it for work only, but I like the desktop effects, that's the reason for OpenGL, and everything works fine. Now I tried switching to kernel 4.10, but as soon as KDE starts, the system crashes. I fiddled around the system settings a bit and I found that when switching to XRender or to OpenGL 1.2, the system does *not* crash any more. As soon as I switch to a higher OpenGL version, the system crashes again at KDE starting. Switching back to OpenGL 1.2, the system doesn't crash. Unfortunately, there's no error to be found in Xorg.log, so I cannot provide you with that information. -- 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 100306] System randomly freezes or crashes to the login screen, glitches until rebooted
https://bugs.freedesktop.org/show_bug.cgi?id=100306 MirceaKitsune changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #11 from MirceaKitsune --- To my stupefaction, the exact same issue has been re-introduced and is happening again. After another openSUSE Tumbleweed snapshot and several package updates, I believe approximately 2 days ago, the freeze occurs once more. I can however confirm that for approximately 8 days before that, the problem went away as I had one week of uninterrupted uptime. Can someone please analyze what changes fit this time pattern? -- 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 98897] Macbook pro 11,5 screen flicker when AC adapter plugged in
https://bugs.freedesktop.org/show_bug.cgi?id=98897 --- Comment #26 from extr15 --- I can now compile a single radeon module, ref: http://www.codewhirl.com/2012/04/how-to-compile-a-single-module-in-ubuntu-linux/ however, neither attachment 128481 nor attachment 128780 work for me. the screen still flicker whether plugged in AC adapter or not. I am macbookpro 11,5, and ubuntu 16.04. uname -a: 4.8.0-36-generic #36~16.04.1-Ubuntu SMP Sun Feb 5 09:39:57 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux tail /var/log/Xorg.0.log: [ 877.072] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip completion event has impossible msc 52285 < target_msc 52286 [ 877.222] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip completion event has impossible msc 52294 < target_msc 52295 [ 878.838] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip completion event has impossible msc 52391 < target_msc 52392 anyone helps? thanks! -- 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: [RFC] drm: atomic-rmfb semantics
On Sun, Apr 02, 2017 at 09:13:34AM -0400, Rob Clark wrote:
> On Sun, Apr 2, 2017 at 8:46 AM, Daniel Vetter wrote:
> > On Sat, Apr 01, 2017 at 03:11:36PM -0400, Rob Clark wrote:
> >> We possibly missed the boat on redefining rmfb semantics for atomic
> >> userspace to something more sane, unless perhaps the few existing atomic
> >> userspaces (CrOS?) could confirm that this change won't cause problems
> >> (in which case we could just call this a bug-fix, drop the cap, and
> >> delete some code?).
> >>
> >> The old semantics of rmfb shutting down the display is kind of pointless
> >> in an atomic world, and it is more awkward for userspace that creates
> >> and destroys the fb every frame, since they need to defer the rmfb.
> >> Since we have better ways for userspace to shut down the display pipe
> >> and the legacy behaviour of rmfb is awkward, provide a way for atomic
> >> userspace to simply make rmfb an unref.
> >>
> >> Signed-off-by: Rob Clark
> >
> > We can't change existing semantics, because we reuse atomic paths for
> > legacy clients. But I think this here is real good. Please come up with
> > the userspace side in any of the atomic compositors we have, and this is
> > good to merge.
>
> So, since this is done in rmfb ioctl fxn, I don't think it effects
> internal use. It is really just making rmfb ioctl into an unref.
>
> But, I'm thinking we should leave the fb on the file_priv->fbs list so
> it gets cleaned up (and legacy behaviour of shutting down pipe is
> preserved) at lastclose time..
>
> And a small related change in drm_framebuffer_free() to make sure it
> is removed from file_priv->fbs list.
We had a big discussion on irc, and my tldr is "no". The same way the
implicit cleanup on rmfb is confusing, the implicit cleanup on close is
confusing, and in most cases not what we want.
We also don't clean up any other kms state, like background color,
blending, gamma tables, color spaces or anything else, all of which can
make your kms state entirely useless for a compositor which doesn't know.
We've discussed this at great lengths about a year ago, still all
relevant:
http://blog.ffwll.ch/2016/01/vt-switching-with-atomic-modeset.html
Note that if all you ever run is the same compositor (and no fbdev or
anything) this isn't a problem, as long as you teach your compositor to
clean up it's own mess on restart.
We also bikesheded the name a bit, and figured instead of a cap it's
better to just have a unref_fb ioctl. And there's also no depency to
atomic.
-Daniel
>
> BR,
> -R
>
> > Well, basic igt testcases would be lovely, too. We have some to exercise
> > rmfb behaviour, so should be easy to adapt them.
> > -Daniel
> >
> >> ---
> >> drivers/gpu/drm/drm_framebuffer.c | 2 +-
> >> drivers/gpu/drm/drm_ioctl.c | 9 +
> >> include/drm/drm_file.h| 8
> >> include/uapi/drm/drm.h| 7 +++
> >> 4 files changed, 25 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/gpu/drm/drm_framebuffer.c
> >> b/drivers/gpu/drm/drm_framebuffer.c
> >> index e4909ae..c5127dd0 100644
> >> --- a/drivers/gpu/drm/drm_framebuffer.c
> >> +++ b/drivers/gpu/drm/drm_framebuffer.c
> >> @@ -383,7 +383,7 @@ int drm_mode_rmfb(struct drm_device *dev,
> >>* so run this in a separate stack as there's no way to correctly
> >>* handle this after the fb is already removed from the lookup table.
> >>*/
> >> - if (drm_framebuffer_read_refcount(fb) > 1) {
> >> + if (drm_framebuffer_read_refcount(fb) > 1 &&
> >> !file_priv->atomic_rmfb) {
> >> struct drm_mode_rmfb_work arg;
> >>
> >> INIT_WORK_ONSTACK(&arg.work, drm_mode_rmfb_work_fn);
> >> diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> >> index a7c61c2..b42348f 100644
> >> --- a/drivers/gpu/drm/drm_ioctl.c
> >> +++ b/drivers/gpu/drm/drm_ioctl.c
> >> @@ -318,6 +318,15 @@ drm_setclientcap(struct drm_device *dev, void *data,
> >> struct drm_file *file_priv)
> >> file_priv->atomic = req->value;
> >> file_priv->universal_planes = req->value;
> >> break;
> >> + case DRM_CLIENT_CAP_ATOMIC_RMFB:
> >> + if (!drm_core_check_feature(dev, DRIVER_ATOMIC))
> >> + return -EINVAL;
> >> + if (req->value > 1)
> >> + return -EINVAL;
> >> + file_priv->atomic = req->value;
> >> + file_priv->universal_planes = req->value;
> >> + file_priv->atomic_rmfb = req->value;
> >> + break;
> >> default:
> >> return -EINVAL;
> >> }
> >> diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
> >> index 5dd27ae..2a41c29 100644
> >> --- a/include/drm/drm_file.h
> >> +++ b/include/drm/drm_file.h
> >> @@ -181,6 +181,14 @@ struct drm_file {
> >> unsigned atomic:1;
> >>
> >> /**
> >> + * @atomic_rmfb:
> >> + *
> >> + * True if client wants new semantics for rmfb,
Re: DVI output on i.MX51 EVP board not working?
On Sat, Apr 01, 2017 at 06:40:52PM -0300, Fabio Estevam wrote: > Hi Wladimir, > > On Fri, Mar 31, 2017 at 2:36 AM, Wladimir J. van der Laan > wrote: > > > - Went as far back as kernel v4.0, even to v3.12 or so (commit 493a863, > > "ARM: > > dts: imx51-babbage: Make DVI and WVGA panel functional"). No difference. > > So nothing to > > bisect, unfortunately. > > It was a long time I worked on this commit and it worked well for me > on an old DVI monitor. An extra data point: I tried with an older monitor (max 1280x1024) w/ DVI to DVI cable, exactly the same behavior: u-boot shows output but "no signal" when kernel boots. I was not able to go all the way back though, and only tested this with mainline. > I will try to locate such monitor in the office next week and try it again. Thanks! Regards, Wladimir ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/4] drm: Add drm_object lease infrastructure
On Sat, Apr 01, 2017 at 10:08:39AM -0700, Keith Packard wrote:
> This provides new data structures to hold "lease" information about
> drm mode setting objects, and provides for creating new drm_masters
> which have access to a subset of the available drm resources.
>
> An 'owner' is a drm_master which is not leasing the objects from
> another drm_master, and hence 'owns' them. This sits at the top of a
> tree of drm_masters.
>
> A 'lessee' is a drm_master which is leasing objects from some other
> drm_master. Each lessee holds the set of objects which it is leasing
> from the lessor.
>
> A 'lessor' is a drm_master which is leasing objects to another
> drm_master.
>
> The set of objects any drm_master 'controls' is limited to the set of
> objects it leases (for lessees) or all objects (for owners),
> optionally minus the set of objects it has leased to other
> drm_masters.
Still not sure we want to restrict objects on the lessor side. Feels like
unecessary complexity (i.e. more bugs in kernel, that's never good), and
at best only needed for lessors who can't keep track of stuff. I'm also
not sure whether we really want sub-leases in v1, that's easy to add later
on, but for now just complicates stuff. Main compositor should be a full
master, VR can be the first lease level, we don't need more I think for
now?
> Objects not controlled by a drm_master cannot be modified through the
> various state manipulating ioctls, and any state reported back to user
> space will be edited to make them appear idle and/or unusable. For
> instance, connectors always report 'disconnected', while encoders
> report no possible crtcs or clones.
>
> The full list of lessees leasing objects from an owner (either
> directly, or indirectly through another lessee), can be searched from
> an idr in the drm_master of the owner.
>
> Signed-off-by: Keith Packard
[snip]
> diff --git a/include/drm/drm_auth.h b/include/drm/drm_auth.h
> index 610223b0481b..e0e2af09d3af 100644
> --- a/include/drm/drm_auth.h
> +++ b/include/drm/drm_auth.h
> @@ -50,10 +50,38 @@ struct drm_master {
> struct idr magic_map;
> struct drm_lock_data lock;
> void *driver_priv;
> +
> + /* Tree of display resource leases, each of which is a drm_master struct
> + * All of these get activated simultaneously, so drm_device master
> points
&drm_device.master to do a reference in kernel-doc. Please feed this to
kernel-doc in general and make sure the links all point at the right
stuff, and it's all parsed.
Cheers, Daniel
> + * at the top of the tree (for which lessor is NULL)
> + */
> +
> + /** Lease holder */
/** @lessor: Lease holder. */
> + struct drm_master *lessor;
> +
> + /** id for lessees. Owners always have id 0 */
> + int lessee_id;
> +
> + /** other lessees of the same master */
> + struct list_head lessee_list;
> +
> + /** drm_masters leasing from this one */
> + struct list_head lessees;
> +
> + /** Objects leased to this drm_master. */
> + struct idr leases;
> +
> + /** All lessees under this owner (only used where lessor == NULL) */
> + struct idr lessee_idr;
> +
> + /** Indicates that the leased objects should be hidden from the lessor
> */
> + bool mask_lease;
> };
>
> struct drm_master *drm_master_get(struct drm_master *master);
> void drm_master_put(struct drm_master **master);
> bool drm_is_current_master(struct drm_file *fpriv);
>
> +struct drm_master *drm_master_create(struct drm_device *dev);
> +
> #endif
> diff --git a/include/drm/drm_lease.h b/include/drm/drm_lease.h
> new file mode 100644
> index ..e02adf3e42fd
> --- /dev/null
> +++ b/include/drm/drm_lease.h
> @@ -0,0 +1,51 @@
> +/*
> + * Copyright © 2017 Keith Packard
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation, either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful, but
> + * WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * General Public License for more details.
> + */
> +
> +#ifndef _DRM_LEASE_H_
> +#define _DRM_LEASE_H_
> +
> +struct drm_file;
> +struct drm_device;
> +
> +struct drm_master *drm_lease_owner(struct drm_master *master);
> +
> +struct drm_master *drm_lessee_find(struct drm_master *top, int lessee_id);
> +
> +void drm_lease_destroy(struct drm_master *lessee);
> +
> +struct drm_mode_object *drm_lease_find(struct drm_master *master, int id);
> +
> +/**
> + * drm_lease_check - check drm_mode_object lease status
> + * @master: the drm_master
> + * @id: the object id
> + *
> + * Checks if the specified master holds a lease on the object
> + * and also whether it has been leased to some lessee of the
> + * specified m
Re: [PATCH 4/4] drm: Add four ioctls for managing drm mode object leases
On Sat, Apr 01, 2017 at 10:08:41AM -0700, Keith Packard wrote:
> drm_mode_create_lease
>
> Creates a lease for a list of drm mode objects, returning an
> fd for the new drm_master and a 64-bit identifier for the lessee
>
> drm_mode_list_lesees
>
> List the identifiers of the lessees from a particular lessor
>
> drm_mode_get_lease
>
> List the leased objects for a particular lessee
Should we just use fd for this? Essentially lessors would be required to
keep track of all their pending leases, and just dup() them over to the
client. Would reduce the uapi scope a bit, and if a lessor can't keep
track of it's leases there's a problem.
> drm_mode_change_lease
>
> Adjust the terms of a lease, adding or removing resources or
> switching from masking to non-masking.
For this one here we could pass the fd of the lease as the argument. I
also still think that for v1 we just want revoke and otherwise invariant
leases. Makes things simpler.
>
> This should suffice to at least create, query and manage available
> leases.
>
> Signed-off-by: Keith Packard
> ---
> drivers/gpu/drm/drm_ioctl.c | 4 +
> drivers/gpu/drm/drm_lease.c | 309
>
> include/drm/drm_lease.h | 12 ++
> include/uapi/drm/drm.h | 4 +
> include/uapi/drm/drm_mode.h | 78 +++
> 5 files changed, 407 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> index fed22c2b98b6..0f9e3c0fe2ac 100644
> --- a/drivers/gpu/drm/drm_ioctl.c
> +++ b/drivers/gpu/drm/drm_ioctl.c
> @@ -636,6 +636,10 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
> DRM_IOCTL_DEF(DRM_IOCTL_MODE_ATOMIC, drm_mode_atomic_ioctl,
> DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
> DRM_IOCTL_DEF(DRM_IOCTL_MODE_CREATEPROPBLOB, drm_mode_createblob_ioctl,
> DRM_CONTROL_ALLOW|DRM_UNLOCKED),
> DRM_IOCTL_DEF(DRM_IOCTL_MODE_DESTROYPROPBLOB,
> drm_mode_destroyblob_ioctl, DRM_CONTROL_ALLOW|DRM_UNLOCKED),
> + DRM_IOCTL_DEF(DRM_IOCTL_MODE_CREATE_LEASE, drm_mode_create_lease_ioctl,
> DRM_ANY_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
> + DRM_IOCTL_DEF(DRM_IOCTL_MODE_LIST_LESSEES, drm_mode_list_lessees_ioctl,
> DRM_ANY_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
> + DRM_IOCTL_DEF(DRM_IOCTL_MODE_GET_LEASE, drm_mode_get_lease_ioctl,
> DRM_ANY_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
> + DRM_IOCTL_DEF(DRM_IOCTL_MODE_CHANGE_LEASE, drm_mode_change_lease_ioctl,
> DRM_ANY_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
> };
>
> #define DRM_CORE_IOCTL_COUNT ARRAY_SIZE( drm_ioctls )
> diff --git a/drivers/gpu/drm/drm_lease.c b/drivers/gpu/drm/drm_lease.c
> index 782005c7706d..39131860bcd3 100644
> --- a/drivers/gpu/drm/drm_lease.c
> +++ b/drivers/gpu/drm/drm_lease.c
> @@ -483,3 +483,312 @@ void drm_lease_destroy(struct drm_master *master)
>
> DRM_DEBUG_LEASE("drm_lease_destroy done %d\n", master->lessee_id);
> }
> +
> +/**
> + * drm_mode_create_lease_ioctl - create a new lease
> + * @dev: the drm device
> + * @data: pointer to struct drm_mode_create_lease
> + * @file_priv: the file being manipulated
> + *
> + * The master associated with the specified file will have a lease
> + * created containing the objects specified in the ioctl structure.
> + * A file descriptor will be allocated for that and returned to the
> + * application.
> + */
> +int drm_mode_create_lease_ioctl(struct drm_device *dev,
> + void *data, struct drm_file *lessor_priv)
> +{
> + struct drm_mode_create_lease *cl = data;
> + size_t object_count;
> + size_t o;
> + int ret = 0;
> + struct idr leases;
> + struct drm_master *lessor = lessor_priv->master;
> + struct drm_master *lessee = NULL;
> + struct file *lessee_file = NULL;
> + struct file *lessor_file = lessor_priv->filp;
> + struct drm_file *lessee_priv;
> + int fd = -1;
> +
> + object_count = cl->object_count;
> + idr_init(&leases);
> +
> + fd = get_unused_fd_flags(cl->flags & (O_CLOEXEC | O_NONBLOCK));
> +
> + DRM_DEBUG_LEASE("Creating new lease\n");
> +
> + /* Lookup the mode objects and add their IDs to the lease request */
> + for (o = 0; o < object_count; o++) {
> + __u32 object_id;
> +
> + if (copy_from_user(&object_id,
> +u64_to_user_ptr(cl->object_ids) + o * sizeof
> (__u32),
> +sizeof (__u32))) {
> + ret = -EFAULT;
> + goto bail;
> + }
> + DRM_DEBUG_LEASE("Adding object %d to lease\n", object_id);
> +
> + ret = idr_alloc(&leases, (void *) 1, object_id, object_id + 1,
> GFP_KERNEL);
> + if (ret < 0) {
> + DRM_DEBUG_LEASE("Object %d cannot be inserted into
> leases (%d)\n",
> + object_id, ret);
> + goto bail;
> + }
> + }
> +
> + mut
Re: [PATCH 3/4] drm: Check mode object lease status in all master ioctl paths
On Sat, Apr 01, 2017 at 10:08:40AM -0700, Keith Packard wrote:
> Attempts to modify un-leased objects are rejected with an error.
> Information returned about unleased objects is modified to make them
> appear unusable and/or disconnected.
>
> Signed-off-by: Keith Packard
Just a merge-technical idea to make this easier to change and less painful
to rebase until we've locked down the semantics properly. And also because
I expect we'll need v2 of this uapi soon or later anyway:
I think it'd be good if we could consolidate all the lease checking into
drm_mode_object_find (respectively __drm_mode_object_find). We'd need to
wire up the fpriv to be able to do that, but we could upstream that patch
right away before anything else. That should take care of most of the
checks in this patch here.
There's a few things on top:
- filtering the various bitmasks. I think you have most, but we could
perhaps upstream the helpers for these.
- filtering object lists (essentially getresources and getplanes ioctls).
- filtering implicit objects in the legacy ioctl. E.g. page_flip done
through atomic doesn't just need the CRTC id, but also the id of the
primary plane plus of the FB_ID atomic property. Similarly for all the
other legacy ioctls. I think we want to make sure there's no difference
here in behaviour.
Especially for the last one it might be simplest to outright disallow all
legacy ioctl and require that sub-drm_master nodes only get access to the
read-only GET* ioctl (they get that anyway, even when they're not the
current master), plus atomic. Makes it a _lot_ easier to implement.
Downside is that amdgpu _really_ needs to land atomic asap :-)
> ---
> drivers/gpu/drm/drm_atomic.c | 3 +++
> drivers/gpu/drm/drm_auth.c| 2 +-
> drivers/gpu/drm/drm_color_mgmt.c | 3 +++
> drivers/gpu/drm/drm_connector.c | 52
> ++-
> drivers/gpu/drm/drm_crtc.c| 15 ---
> drivers/gpu/drm/drm_encoder.c | 18 +++---
> drivers/gpu/drm/drm_mode_object.c | 3 +++
> drivers/gpu/drm/drm_plane.c | 36 +++
> include/drm/drm_lease.h | 4 +++
> include/drm/drm_mode_object.h | 1 +
> 10 files changed, 108 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index fdfb1ec17e66..a3cb95f7f1c1 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -2134,6 +2134,9 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
> goto out;
> }
>
> + if ((ret = drm_lease_check(file_priv->master, obj->id)) < 0)
> + goto out;
> +
> if (!obj->properties) {
> drm_mode_object_unreference(obj);
> ret = -ENOENT;
> diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c
> index 1db4f63860d1..44c99d12f4c1 100644
> --- a/drivers/gpu/drm/drm_auth.c
> +++ b/drivers/gpu/drm/drm_auth.c
> @@ -303,7 +303,7 @@ void drm_master_release(struct drm_file *file_priv)
> */
> bool drm_is_current_master(struct drm_file *fpriv)
> {
> - return fpriv->is_master && fpriv->master == fpriv->minor->dev->master;
> + return fpriv->is_master && drm_lease_owner(fpriv->master) ==
> fpriv->minor->dev->master;
This feels like it should be part of the earlier patch to make
sub-drm_master objects for leasing. In that patch we should also make sure
that all the current docs about drm_master are updated correctly (but
maybe only later on, when we get towards merging this). This change here
is pretty important wrt set/drop_master ioctl behaviour and leases.
Cheers, Daniel
> }
> EXPORT_SYMBOL(drm_is_current_master);
>
> diff --git a/drivers/gpu/drm/drm_color_mgmt.c
> b/drivers/gpu/drm/drm_color_mgmt.c
> index 6543ebde501a..f8d7a499cf95 100644
> --- a/drivers/gpu/drm/drm_color_mgmt.c
> +++ b/drivers/gpu/drm/drm_color_mgmt.c
> @@ -206,6 +206,9 @@ int drm_mode_gamma_set_ioctl(struct drm_device *dev,
> goto out;
> }
>
> + if ((ret = drm_lease_check(file_priv->master, crtc->base.id)) < 0)
> + goto out;
> +
> if (crtc->funcs->gamma_set == NULL) {
> ret = -ENOSYS;
> goto out;
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 7a7019ac9388..a95db57dd966 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -1079,6 +1079,7 @@ int drm_mode_getconnector(struct drm_device *dev, void
> *data,
> struct drm_mode_modeinfo u_mode;
> struct drm_mode_modeinfo __user *mode_ptr;
> uint32_t __user *encoder_ptr;
> + bool leased;
>
> if (!drm_core_check_feature(dev, DRIVER_MODESET))
> return -EINVAL;
> @@ -1093,9 +1094,16 @@ int drm_mode_getconnector(struct drm_device *dev, void
> *data,
> goto out_unlock;
> }
>
> - for (i = 0;
[Bug 100465] Hard lockup with radeonsi driver on FirePro W600, W9000 and W9100
https://bugs.freedesktop.org/show_bug.cgi?id=100465 --- Comment #6 from joro-2013 --- Yeah, i know. But the behaviour of not writing to kern.log but just completely locking up appeared after said patch. -- 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 100531] [regression] Broken graphics in several games
https://bugs.freedesktop.org/show_bug.cgi?id=100531 --- Comment #2 from Gregor Münch --- Created attachment 130641 --> https://bugs.freedesktop.org/attachment.cgi?id=130641&action=edit blue shadows in Warhammer -- 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 100531] [regression] Broken graphics in several games
https://bugs.freedesktop.org/show_bug.cgi?id=100531 --- Comment #1 from Gregor Münch --- Created attachment 130640 --> https://bugs.freedesktop.org/attachment.cgi?id=130640&action=edit broken car reflections in rocket league -- 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 100531] [regression] Broken graphics in several games
https://bugs.freedesktop.org/show_bug.cgi?id=100531 Bug ID: 100531 Summary: [regression] Broken graphics in several games Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel@lists.freedesktop.org Reporter: gr.mue...@gmail.com QA Contact: dri-devel@lists.freedesktop.org Created attachment 130639 --> https://bugs.freedesktop.org/attachment.cgi?id=130639&action=edit No textures for Lara... Saw this in TotalWar: Warhammer, Rocket League, Tomb Raider, Dirt: Showdown Radeon HD 7970 5abf60076ce42f3b061e149944a6b4c4ed2c5aa4 is the first bad commit commit 5abf60076ce42f3b061e149944a6b4c4ed2c5aa4 Author: Marek Olšák Date: Sat Oct 15 15:27:18 2016 +0200 radeonsi/gfx9: image descriptor changes in mutable fields Reviewed-by: Nicolai Hähnle :04 04 18ee069c1eebf2e3788a87cc937d60a52246f7a4 b9e22831b6ed61d93ca34fab67b80b19ad1b0a01 M src git bisect log git bisect start # bad: [03a67fbbf7847cbdcc26b3bd86ee43e09a55cce9] radv: fix order of the guardband register emission. git bisect bad 03a67fbbf7847cbdcc26b3bd86ee43e09a55cce9 # good: [57595cb0739d50a3fbd0841d7475bd775f3e24f3] anv/genX: Solve the vkCreateGraphicsPipelines crash git bisect good 57595cb0739d50a3fbd0841d7475bd775f3e24f3 # good: [9319ef96fd5c2489754eae1b058e4087d7259341] anv/blorp: Use anv_get_layerCount everywhere git bisect good 9319ef96fd5c2489754eae1b058e4087d7259341 # good: [c8ffec4f4b895fdac0f36895393d100cff7c2ac1] radeonsi/gfx9: FMASK image descriptor changes git bisect good c8ffec4f4b895fdac0f36895393d100cff7c2ac1 # bad: [18e2aa063ca8e2aeb22a72253891e6f8f5d0d96b] gbm/dri: Check dri extension version before flush after unmap git bisect bad 18e2aa063ca8e2aeb22a72253891e6f8f5d0d96b # bad: [9f5dbbe030a069b9c362a48fdcd23d4d6221894f] gallivm: fix a maybe-uninitialized warning git bisect bad 9f5dbbe030a069b9c362a48fdcd23d4d6221894f # bad: [7695ea0c02166c7173437f120cbf8dceeec7fc37] radeonsi/gfx9: add linear address computations for texture transfers git bisect bad 7695ea0c02166c7173437f120cbf8dceeec7fc37 # bad: [6e0d64712aa3fdf07060eeda52417143514004e5] radeonsi/gfx9: use ACQUIRE_MEM git bisect bad 6e0d64712aa3fdf07060eeda52417143514004e5 # bad: [354285afa08f48d0aab232820698aacc54e347f7] radeonsi/gfx9: fix textureSize/imageSize for 1D textures git bisect bad 354285afa08f48d0aab232820698aacc54e347f7 # bad: [fc3c503b5d7fc9843220c8d89c6394f145f096af] radeonsi/gfx9: enable clamping for Z UNORM formats promoted to Z32F git bisect bad fc3c503b5d7fc9843220c8d89c6394f145f096af # bad: [5abf60076ce42f3b061e149944a6b4c4ed2c5aa4] radeonsi/gfx9: image descriptor changes in mutable fields git bisect bad 5abf60076ce42f3b061e149944a6b4c4ed2c5aa4 # first bad commit: [5abf60076ce42f3b061e149944a6b4c4ed2c5aa4] radeonsi/gfx9: image descriptor changes in mutable fields -- 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: [RFC] drm: atomic-rmfb semantics
On Sun, Apr 2, 2017 at 8:46 AM, Daniel Vetter wrote:
> On Sat, Apr 01, 2017 at 03:11:36PM -0400, Rob Clark wrote:
>> We possibly missed the boat on redefining rmfb semantics for atomic
>> userspace to something more sane, unless perhaps the few existing atomic
>> userspaces (CrOS?) could confirm that this change won't cause problems
>> (in which case we could just call this a bug-fix, drop the cap, and
>> delete some code?).
>>
>> The old semantics of rmfb shutting down the display is kind of pointless
>> in an atomic world, and it is more awkward for userspace that creates
>> and destroys the fb every frame, since they need to defer the rmfb.
>> Since we have better ways for userspace to shut down the display pipe
>> and the legacy behaviour of rmfb is awkward, provide a way for atomic
>> userspace to simply make rmfb an unref.
>>
>> Signed-off-by: Rob Clark
>
> We can't change existing semantics, because we reuse atomic paths for
> legacy clients. But I think this here is real good. Please come up with
> the userspace side in any of the atomic compositors we have, and this is
> good to merge.
So, since this is done in rmfb ioctl fxn, I don't think it effects
internal use. It is really just making rmfb ioctl into an unref.
But, I'm thinking we should leave the fb on the file_priv->fbs list so
it gets cleaned up (and legacy behaviour of shutting down pipe is
preserved) at lastclose time..
And a small related change in drm_framebuffer_free() to make sure it
is removed from file_priv->fbs list.
BR,
-R
> Well, basic igt testcases would be lovely, too. We have some to exercise
> rmfb behaviour, so should be easy to adapt them.
> -Daniel
>
>> ---
>> drivers/gpu/drm/drm_framebuffer.c | 2 +-
>> drivers/gpu/drm/drm_ioctl.c | 9 +
>> include/drm/drm_file.h| 8
>> include/uapi/drm/drm.h| 7 +++
>> 4 files changed, 25 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/drm_framebuffer.c
>> b/drivers/gpu/drm/drm_framebuffer.c
>> index e4909ae..c5127dd0 100644
>> --- a/drivers/gpu/drm/drm_framebuffer.c
>> +++ b/drivers/gpu/drm/drm_framebuffer.c
>> @@ -383,7 +383,7 @@ int drm_mode_rmfb(struct drm_device *dev,
>>* so run this in a separate stack as there's no way to correctly
>>* handle this after the fb is already removed from the lookup table.
>>*/
>> - if (drm_framebuffer_read_refcount(fb) > 1) {
>> + if (drm_framebuffer_read_refcount(fb) > 1 && !file_priv->atomic_rmfb) {
>> struct drm_mode_rmfb_work arg;
>>
>> INIT_WORK_ONSTACK(&arg.work, drm_mode_rmfb_work_fn);
>> diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
>> index a7c61c2..b42348f 100644
>> --- a/drivers/gpu/drm/drm_ioctl.c
>> +++ b/drivers/gpu/drm/drm_ioctl.c
>> @@ -318,6 +318,15 @@ drm_setclientcap(struct drm_device *dev, void *data,
>> struct drm_file *file_priv)
>> file_priv->atomic = req->value;
>> file_priv->universal_planes = req->value;
>> break;
>> + case DRM_CLIENT_CAP_ATOMIC_RMFB:
>> + if (!drm_core_check_feature(dev, DRIVER_ATOMIC))
>> + return -EINVAL;
>> + if (req->value > 1)
>> + return -EINVAL;
>> + file_priv->atomic = req->value;
>> + file_priv->universal_planes = req->value;
>> + file_priv->atomic_rmfb = req->value;
>> + break;
>> default:
>> return -EINVAL;
>> }
>> diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
>> index 5dd27ae..2a41c29 100644
>> --- a/include/drm/drm_file.h
>> +++ b/include/drm/drm_file.h
>> @@ -181,6 +181,14 @@ struct drm_file {
>> unsigned atomic:1;
>>
>> /**
>> + * @atomic_rmfb:
>> + *
>> + * True if client wants new semantics for rmfb, ie. simply dropping
>> + * refcnt without tearing down the display.
>> + */
>> + unsigned atomic_rmfb:1;
>> +
>> + /**
>>* @is_master:
>>*
>>* This client is the creator of @master. Protected by struct
>> diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
>> index b2c5284..4063cc8 100644
>> --- a/include/uapi/drm/drm.h
>> +++ b/include/uapi/drm/drm.h
>> @@ -678,6 +678,13 @@ struct drm_get_cap {
>> */
>> #define DRM_CLIENT_CAP_ATOMIC3
>>
>> +/**
>> + * DRM_CLIENT_CAP_ATOMIC_RMFB
>> + *
>> + * If set to 1, the DRM core will not shutdown display pipe on rmfb ioctl.
>> + */
>> +#define DRM_CLIENT_CAP_ATOMIC_RMFB 4
>> +
>> /** DRM_IOCTL_SET_CLIENT_CAP ioctl argument type */
>> struct drm_set_client_cap {
>> __u64 capability;
>> --
>> 2.9.3
>>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 98897] Macbook pro 11,5 screen flicker when AC adapter plugged in
https://bugs.freedesktop.org/show_bug.cgi?id=98897 --- Comment #25 from extr15 --- (In reply to berg from comment #20) > Created attachment 128481 [details] [review] > Setting correct core and memory clock for M370X in MBP 11,5 > > No screen flickering after testing out this patch I made on the v4.9 branch. > I confirmed the GPU configuration on this page > https://en.wikipedia.org/wiki/AMD_Radeon_Rx_300_series. Set mclk and sclk > accordingly; assuming that mclk is for memory and sclk is for the GPU clock. > > Noticeably everything is running very nicely. No strange behaviour so far > and both GPU and CPU temps are OK. > > In addition. My CPU turbo boost is also working, which it previously wasn't > on 3.8.6. Test at your own risk. hi berg, thanks for your attachment. I am new to linux kernel, and I don't how to apply your attachment, i.e. how to compile a single radeon.ko ? I find a radeon.ko under "/lib/modules/4.8.0-36-generic/kernel/drivers/gpu/drm/radeon", so I want to compile it, likes here: https://bugzilla.kernel.org/show_bug.cgi?id=105051#c37 I modify si_dpm.c and write a Makefile: obj-m += si_dpm.o all: make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules clean: make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean but when make I get: /si_dpm.c:24:18: fatal error: drmP.h: No such file or directory compilation terminated. so could you tell me how to compile a single .ko or if any tutorial I can follow, or I have to compile all the kernel? thanks! -- 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: [RFC] drm: atomic-rmfb semantics
On Sat, Apr 01, 2017 at 03:11:36PM -0400, Rob Clark wrote:
> We possibly missed the boat on redefining rmfb semantics for atomic
> userspace to something more sane, unless perhaps the few existing atomic
> userspaces (CrOS?) could confirm that this change won't cause problems
> (in which case we could just call this a bug-fix, drop the cap, and
> delete some code?).
>
> The old semantics of rmfb shutting down the display is kind of pointless
> in an atomic world, and it is more awkward for userspace that creates
> and destroys the fb every frame, since they need to defer the rmfb.
> Since we have better ways for userspace to shut down the display pipe
> and the legacy behaviour of rmfb is awkward, provide a way for atomic
> userspace to simply make rmfb an unref.
>
> Signed-off-by: Rob Clark
We can't change existing semantics, because we reuse atomic paths for
legacy clients. But I think this here is real good. Please come up with
the userspace side in any of the atomic compositors we have, and this is
good to merge.
Well, basic igt testcases would be lovely, too. We have some to exercise
rmfb behaviour, so should be easy to adapt them.
-Daniel
> ---
> drivers/gpu/drm/drm_framebuffer.c | 2 +-
> drivers/gpu/drm/drm_ioctl.c | 9 +
> include/drm/drm_file.h| 8
> include/uapi/drm/drm.h| 7 +++
> 4 files changed, 25 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_framebuffer.c
> b/drivers/gpu/drm/drm_framebuffer.c
> index e4909ae..c5127dd0 100644
> --- a/drivers/gpu/drm/drm_framebuffer.c
> +++ b/drivers/gpu/drm/drm_framebuffer.c
> @@ -383,7 +383,7 @@ int drm_mode_rmfb(struct drm_device *dev,
>* so run this in a separate stack as there's no way to correctly
>* handle this after the fb is already removed from the lookup table.
>*/
> - if (drm_framebuffer_read_refcount(fb) > 1) {
> + if (drm_framebuffer_read_refcount(fb) > 1 && !file_priv->atomic_rmfb) {
> struct drm_mode_rmfb_work arg;
>
> INIT_WORK_ONSTACK(&arg.work, drm_mode_rmfb_work_fn);
> diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> index a7c61c2..b42348f 100644
> --- a/drivers/gpu/drm/drm_ioctl.c
> +++ b/drivers/gpu/drm/drm_ioctl.c
> @@ -318,6 +318,15 @@ drm_setclientcap(struct drm_device *dev, void *data,
> struct drm_file *file_priv)
> file_priv->atomic = req->value;
> file_priv->universal_planes = req->value;
> break;
> + case DRM_CLIENT_CAP_ATOMIC_RMFB:
> + if (!drm_core_check_feature(dev, DRIVER_ATOMIC))
> + return -EINVAL;
> + if (req->value > 1)
> + return -EINVAL;
> + file_priv->atomic = req->value;
> + file_priv->universal_planes = req->value;
> + file_priv->atomic_rmfb = req->value;
> + break;
> default:
> return -EINVAL;
> }
> diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
> index 5dd27ae..2a41c29 100644
> --- a/include/drm/drm_file.h
> +++ b/include/drm/drm_file.h
> @@ -181,6 +181,14 @@ struct drm_file {
> unsigned atomic:1;
>
> /**
> + * @atomic_rmfb:
> + *
> + * True if client wants new semantics for rmfb, ie. simply dropping
> + * refcnt without tearing down the display.
> + */
> + unsigned atomic_rmfb:1;
> +
> + /**
>* @is_master:
>*
>* This client is the creator of @master. Protected by struct
> diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
> index b2c5284..4063cc8 100644
> --- a/include/uapi/drm/drm.h
> +++ b/include/uapi/drm/drm.h
> @@ -678,6 +678,13 @@ struct drm_get_cap {
> */
> #define DRM_CLIENT_CAP_ATOMIC3
>
> +/**
> + * DRM_CLIENT_CAP_ATOMIC_RMFB
> + *
> + * If set to 1, the DRM core will not shutdown display pipe on rmfb ioctl.
> + */
> +#define DRM_CLIENT_CAP_ATOMIC_RMFB 4
> +
> /** DRM_IOCTL_SET_CLIENT_CAP ioctl argument type */
> struct drm_set_client_cap {
> __u64 capability;
> --
> 2.9.3
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: DRM Display driver for Intel FPGA Video and Image Processing Suite
On Fri, Mar 31, 2017 at 09:08:37AM +, Ong, Hean Loong wrote: > Hi, > > I would like to upstream the attached Intel FPGA Video and Image > Processing Suite. The attached patch supports the Intel Arria10 devkit > and its variants. The purpose of the patch is to enable the FPGA driven > display designed from the Intel Quartus FPGA design suite. For my understanding of the hw: Does this fpga thing have a real output, or is it a virtual thing? It kinda looks very much like a virtual output ... > The driver is required as part of the Intel Arria10 devkit reference > design. The driver was tested on: > - The Open Embedded Angstrom Distro. > - The matchbox-terminal and window-manager was used for functional > testing Please use igt to validate your driver, running a desktop isn't really a full work-out. See https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#testing-and-validation > > Current the intention of the driver is meant to validate the FPGA > designs on the Arria10 devkit for Display Port connecter. We have not > verified its performance of or stability in 3D acceleration or other > non Intel FPGA hardware For next time around, pls submit is plain patch, not attached. You might need to ask intel IT to adjust your outlook setttings to make sure it goes through. Bunch of comments below. Also, do you want to maintain this as part of the "small drivers in drm-misc" effort? See: https://01.org/linuxgraphics/gfx-docs/maintainer-tools/drm-misc.html#small-drivers Note that it's no longer an expirement, we're accepting new drivers (but the patch to change that hasn't gone through the autobuilders yet, hence docs are a bit stale). Bunch of comments below. Overall looks like a nice simple&clean driver. Cheers, Daniel > > BR > > Hean Loong > From 0de293e3646a1780ed603cf8e1f2a19d9aebbe83 Mon Sep 17 00:00:00 2001 > From: Ong, Hean Loong > Date: Thu, 30 Mar 2017 18:02:22 +0800 > Subject: [PATCHv0] Intel FPGA Video and Image Processing Suite Frame Buffer > II driver > > Signed-off-by: Ong, Hean Loong > --- > drivers/gpu/drm/Kconfig |2 + > drivers/gpu/drm/Makefile |1 + > drivers/gpu/drm/ivip/Kconfig | 22 > drivers/gpu/drm/ivip/Makefile |9 ++ > drivers/gpu/drm/ivip/intel_vip_conn.c | 145 ++ > drivers/gpu/drm/ivip/intel_vip_core.c | 215 > + > drivers/gpu/drm/ivip/intel_vip_crtc.c | 161 > drivers/gpu/drm/ivip/intel_vip_drv.h | 55 + > drivers/gpu/drm/ivip/intel_vip_of.c | 146 ++ > 9 files changed, 756 insertions(+), 0 deletions(-) > create mode 100644 drivers/gpu/drm/ivip/Kconfig > create mode 100644 drivers/gpu/drm/ivip/Makefile > create mode 100644 drivers/gpu/drm/ivip/intel_vip_conn.c > create mode 100644 drivers/gpu/drm/ivip/intel_vip_core.c > create mode 100644 drivers/gpu/drm/ivip/intel_vip_crtc.c > create mode 100644 drivers/gpu/drm/ivip/intel_vip_drv.h > create mode 100644 drivers/gpu/drm/ivip/intel_vip_of.c > > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig > index ebfe840..c487507 100644 > --- a/drivers/gpu/drm/Kconfig > +++ b/drivers/gpu/drm/Kconfig > @@ -167,6 +167,8 @@ source "drivers/gpu/drm/nouveau/Kconfig" > > source "drivers/gpu/drm/i915/Kconfig" > > +source "drivers/gpu/drm/ivip/Kconfig" > + > config DRM_VGEM > tristate "Virtual GEM provider" > depends on DRM > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile > index b9ae428..945cf53 100644 > --- a/drivers/gpu/drm/Makefile > +++ b/drivers/gpu/drm/Makefile > @@ -52,6 +52,7 @@ obj-$(CONFIG_DRM_AMDGPU)+= amd/amdgpu/ > obj-$(CONFIG_DRM_MGA)+= mga/ > obj-$(CONFIG_DRM_I810) += i810/ > obj-$(CONFIG_DRM_I915) += i915/ > +obj-$(CONFIG_DRM_IVIP) += ivip/ > obj-$(CONFIG_DRM_MGAG200) += mgag200/ > obj-$(CONFIG_DRM_VC4) += vc4/ > obj-$(CONFIG_DRM_CIRRUS_QEMU) += cirrus/ > diff --git a/drivers/gpu/drm/ivip/Kconfig b/drivers/gpu/drm/ivip/Kconfig > new file mode 100644 > index 000..ddf3cb5 > --- /dev/null > +++ b/drivers/gpu/drm/ivip/Kconfig > @@ -0,0 +1,22 @@ > +config DRM_IVIP > +tristate "Intel FGPA Video and Image Processing" > +depends on DRM > +select DRM_GEM_CMA_HELPER > +select DRM_KMS_HELPER > +select DRM_KMS_FB_HELPER > +select DRM_KMS_CMA_HELPER > +help > +Choose this option if you have a Intel FPGA Arria 10 system > +and above with a Display Port IP. This does not support > legacy > +Intel FPGA Cyclone V display port. Currently only single > frame > +buffer is supported. Note that ACPI and X_86 architecture is > yet > +to be supported. This config option seems defunct, only IVIP_OF seems to do anything. Please merge. > + > +config DRM_IVIP_OF > +tristate "Intel FGPA Video and Image Processing Open Firmware > S
Re: [RFC PATCH xserver] modesetting: re-set the crtc's mode when link-status goes BAD
On Fri, Mar 31, 2017 at 05:22:09PM -0700, Eric Anholt wrote: > Manasi Navare writes: > > > On Fri, Mar 31, 2017 at 01:08:41PM -0700, Eric Anholt wrote: > >> Manasi Navare writes: > >> > >> > On Thu, Mar 30, 2017 at 05:37:55PM -0700, Eric Anholt wrote: > >> >> Martin Peres writes: > >> >> > >> >> > On 26/01/17 14:37, Martin Peres wrote: > >> >> >> Despite all the careful planing of the kernel, a link may become > >> >> >> insufficient to handle the currently-set mode. At this point, the > >> >> >> kernel should mark this particular configuration as being broken > >> >> >> and potentially prune the mode before setting the offending > >> >> >> connector's > >> >> >> link-status to BAD and send the userspace a hotplug event. This may > >> >> >> happen right after a modeset or later on. > >> >> >> > >> >> >> When available, we should use the link-status information to reset > >> >> >> the wanted mode. > >> >> >> > >> >> >> Signed-off-by: Martin Peres > >> >> > > >> >> > The relevant kernel patches have landed in drm-tip about a month ago. > >> >> > > >> >> > Eric, would you mind providing feedback on or merging this patch? > >> >> > >> >> The later discussion has sounded like the kernel will (always) prune the > >> >> mode when we re-query, meaning that it doesn't make any sense to try to > >> >> re-set to the old mode. Is this not the case? > >> > > >> > > >> > No the kernel will simply send a hotplug with link status as bad > >> > and then after that point its userspace driver's responsibility > >> > to check if link status is BAD, retry the same mode and if it fails > >> > then re probe. > >> > >> So the kernel will sometimes allow the same mode to be re-set with the > >> same bpp? > > > > So when userspace driver re-sets the same mode, the kernel will call the > > mode valid function where it will see it can allow the sam mode perhaps > > at a lower bpp now since the link parameters are lowered. > > So the mode which failed at 30 bpp, might still work at 18bpp and is > > better going to a lower resolution. > > The question was whether the kernel will ever allow the same mode at the > same bpp, since that's what this patch tries to do. Yes, this can happen. Doing a full modeset with recomputing clocks and everything behind userspace's back might not be something the kernel driver can pull of with a reasonable amount of effort, hence why we punt to userspace. The interface spec makes this a CAN, not WILL, to allow less unreasonable hw to handle these cases directly in the kernel driver. E.g. plain link-retraining is handled in i915.ko still. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] drm: atomic-rmfb semantics
On Sat, Apr 1, 2017 at 3:11 PM, Rob Clark wrote:
> We possibly missed the boat on redefining rmfb semantics for atomic
> userspace to something more sane, unless perhaps the few existing atomic
> userspaces (CrOS?) could confirm that this change won't cause problems
> (in which case we could just call this a bug-fix, drop the cap, and
> delete some code?).
>
> The old semantics of rmfb shutting down the display is kind of pointless
> in an atomic world, and it is more awkward for userspace that creates
> and destroys the fb every frame, since they need to defer the rmfb.
> Since we have better ways for userspace to shut down the display pipe
> and the legacy behaviour of rmfb is awkward, provide a way for atomic
> userspace to simply make rmfb an unref.
>
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/drm_framebuffer.c | 2 +-
> drivers/gpu/drm/drm_ioctl.c | 9 +
> include/drm/drm_file.h| 8
> include/uapi/drm/drm.h| 7 +++
> 4 files changed, 25 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_framebuffer.c
> b/drivers/gpu/drm/drm_framebuffer.c
> index e4909ae..c5127dd0 100644
> --- a/drivers/gpu/drm/drm_framebuffer.c
> +++ b/drivers/gpu/drm/drm_framebuffer.c
> @@ -383,7 +383,7 @@ int drm_mode_rmfb(struct drm_device *dev,
> * so run this in a separate stack as there's no way to correctly
> * handle this after the fb is already removed from the lookup table.
> */
> - if (drm_framebuffer_read_refcount(fb) > 1) {
> + if (drm_framebuffer_read_refcount(fb) > 1 && !file_priv->atomic_rmfb)
> {
oh, ignore the fact that this patch as-is would leak.. RFC cobbled
together after a red-eye flight, the fact that it compiles is an
accomplishment ;-)
(but I still want to hear what folks think of the idea)
BR,
-R
> struct drm_mode_rmfb_work arg;
>
> INIT_WORK_ONSTACK(&arg.work, drm_mode_rmfb_work_fn);
> diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> index a7c61c2..b42348f 100644
> --- a/drivers/gpu/drm/drm_ioctl.c
> +++ b/drivers/gpu/drm/drm_ioctl.c
> @@ -318,6 +318,15 @@ drm_setclientcap(struct drm_device *dev, void *data,
> struct drm_file *file_priv)
> file_priv->atomic = req->value;
> file_priv->universal_planes = req->value;
> break;
> + case DRM_CLIENT_CAP_ATOMIC_RMFB:
> + if (!drm_core_check_feature(dev, DRIVER_ATOMIC))
> + return -EINVAL;
> + if (req->value > 1)
> + return -EINVAL;
> + file_priv->atomic = req->value;
> + file_priv->universal_planes = req->value;
> + file_priv->atomic_rmfb = req->value;
> + break;
> default:
> return -EINVAL;
> }
> diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
> index 5dd27ae..2a41c29 100644
> --- a/include/drm/drm_file.h
> +++ b/include/drm/drm_file.h
> @@ -181,6 +181,14 @@ struct drm_file {
> unsigned atomic:1;
>
> /**
> +* @atomic_rmfb:
> +*
> +* True if client wants new semantics for rmfb, ie. simply dropping
> +* refcnt without tearing down the display.
> +*/
> + unsigned atomic_rmfb:1;
> +
> + /**
> * @is_master:
> *
> * This client is the creator of @master. Protected by struct
> diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
> index b2c5284..4063cc8 100644
> --- a/include/uapi/drm/drm.h
> +++ b/include/uapi/drm/drm.h
> @@ -678,6 +678,13 @@ struct drm_get_cap {
> */
> #define DRM_CLIENT_CAP_ATOMIC 3
>
> +/**
> + * DRM_CLIENT_CAP_ATOMIC_RMFB
> + *
> + * If set to 1, the DRM core will not shutdown display pipe on rmfb ioctl.
> + */
> +#define DRM_CLIENT_CAP_ATOMIC_RMFB 4
> +
> /** DRM_IOCTL_SET_CLIENT_CAP ioctl argument type */
> struct drm_set_client_cap {
> __u64 capability;
> --
> 2.9.3
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 94679] DAL DCE 10 missing CEA interlaced modes
https://bugs.freedesktop.org/show_bug.cgi?id=94679 Andy Furniss changed: What|Removed |Added Priority|medium |low Severity|normal |enhancement --- Comment #2 from Andy Furniss --- OK, fair enough, I guess very few would ever make use like this anyway. >From a UK resident POV, interlace is likely to be around for plenty of time to come, as we get DVB 1080i (or p) for FTA TV. Whether it's better than (realtime) s/w or GPU - a bit but not vastly. Current GPU does artifact a bit and doesn't do diagonal interpolation so it's a bit jaggy on the right scene. yadif is probably better, but it's not motion adaptive like my TV is, so a bit softer (though sometimes that can be good at hiding artifacts). I use a desktop PC - so have enough CPU and GPU power not to really need anything else. I suppose someone with a weaker set up may benefit - but now I'm just making up untested hypotheticals. They would still need enough (single thread) CPU perf to interlace aware convert 420 to 422 and run ffmpeg tinterlacex2 filter. So no real need for me, other than always wanting as many options available as possible, maybe one day I will upgrade my TV to one that has the best de-interlacer in the world, or maybe not :-) -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[radeon-alex:drm-next-4.12-wip 190/320] drivers/gpu/drm/amd/amdgpu/amdgpu.h:981:28: error: 'NGG_BUF_MAX' undeclared here (not in a function)
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-4.12-wip
head: aaee136fb4cee7136f1436bc5303d2dcff3bba5c
commit: bce23e00f3369ce8c32c90f087e37c01f83002d1 [190/320] drm/amdgpu: add NGG
parameters
config: alpha-allyesconfig (attached as .config)
compiler: alpha-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout bce23e00f3369ce8c32c90f087e37c01f83002d1
# save the attached .config to linux build tree
make.cross ARCH=alpha
All errors (new ones prefixed by >>):
In file included from arch/alpha/include/asm/pgtable.h:18:0,
from include/linux/mm.h:68,
from include/linux/scatterlist.h:7,
from include/linux/dma-mapping.h:10,
from include/drm/drmP.h:37,
from drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c:26:
>> arch/alpha/include/uapi/asm/setup.h:27:18: error: expected identifier before
>> '(' token
#define ZERO_PGE (PAGE_OFFSET+KERNEL_START_PHYS+0x0A000)
^
arch/alpha/include/uapi/asm/setup.h:37:17: note: in expansion of macro
'ZERO_PGE'
#define PARAM ZERO_PGE
^~~~
drivers/gpu/drm/amd/amdgpu/amdgpu.h:976:2: note: in expansion of macro
'PARAM'
PARAM,
^
In file included from drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c:27:0:
>> drivers/gpu/drm/amd/amdgpu/amdgpu.h:981:28: error: 'NGG_BUF_MAX' undeclared
>> here (not in a function)
struct amdgpu_ngg_buf buf[NGG_BUF_MAX];
^~~
vim +/NGG_BUF_MAX +981 drivers/gpu/drm/amd/amdgpu/amdgpu.h
970 };
971
972 enum {
973 PRIM = 0,
974 POS,
975 CNTL,
> 976 PARAM,
977 NGG_BUF_MAX
978 };
979
980 struct amdgpu_ngg {
> 981 struct amdgpu_ngg_buf buf[NGG_BUF_MAX];
982 uint32_tgds_reserve_addr;
983 uint32_tgds_reserve_size;
984 boolinit;
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 100530] Linking of etnaviv_cmd_stream_test is broken
https://bugs.freedesktop.org/show_bug.cgi?id=100530 Bug ID: 100530 Summary: Linking of etnaviv_cmd_stream_test is broken Product: DRI Version: XOrg git Hardware: All OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: libdrm Assignee: dri-devel@lists.freedesktop.org Reporter: berndku...@hotmail.com Created attachment 130638 --> https://bugs.freedesktop.org/attachment.cgi?id=130638&action=edit Patch Buildroot autobuilders detected a broken link command for etnaviv_cmd_stream_test http://autobuild.buildroot.net/results/68a/68af62f4ab6944d326468818562c05fd5cc55b03/build-end.log /home/test/autobuild/run/instance-1/output/host/usr/lib/gcc/arm-buildroot-linux-uclibcgnueabi/5.4.0/../../../../arm-buildroot-linux-uclibcgnueabi/bin/ld: warning: libdrm.so.2, needed by ../../etnaviv/.libs/libdrm_etnaviv.so, not found (try using -rpath or -rpath-link) ../../etnaviv/.libs/libdrm_etnaviv.so: undefined reference to `drmCommandWriteRead' ../../etnaviv/.libs/libdrm_etnaviv.so: undefined reference to `drmCommandWrite' ../../etnaviv/.libs/libdrm_etnaviv.so: undefined reference to `drmPrimeHandleToFD' ../../etnaviv/.libs/libdrm_etnaviv.so: undefined reference to `drmHashDelete' ../../etnaviv/.libs/libdrm_etnaviv.so: undefined reference to `drmMsg' ../../etnaviv/.libs/libdrm_etnaviv.so: undefined reference to `drmIoctl' ../../etnaviv/.libs/libdrm_etnaviv.so: undefined reference to `drmHashLookup' ../../etnaviv/.libs/libdrm_etnaviv.so: undefined reference to `drmHashCreate' ../../etnaviv/.libs/libdrm_etnaviv.so: undefined reference to `drmHashInsert' ../../etnaviv/.libs/libdrm_etnaviv.so: undefined reference to `drmHashDestroy' ../../etnaviv/.libs/libdrm_etnaviv.so: undefined reference to `drmPrimeFDToHandle' collect2: error: ld returned 1 exit status make[4]: *** [etnaviv_cmd_stream_test] Error 1 The attached patch fixes the problem. -- 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
