[PATCH] drm/nouveau: Use drm_vblank_on/off consistently
On 06/15/2015 08:07 AM, Daniel Vetter wrote:
> In
>
> commit 9cba5efab5a8145ae6c52ea273553f069c294482
> Author: Mario Kleiner
> Date: Tue Jul 29 02:36:44 2014 +0200
>
> drm/nouveau: Dis/Enable vblank irqs during suspend/resume
>
> drm_vblank_on/off calls where added around suspend/resume to make sure
> vblank stay doesn't go boom over that transition. But nouveau already
> used drm_vblank_pre/post_modeset over modesets. Instead use
> drm_vblank_on/off everyhwere. The slight change here is that after
> _off drm_vblank_get will refuse to work right away, but nouveau
> doesn't seem to depend upon that anywhere outside of the pageflip
> paths.
>
> The longer-term plan here is to switch all kms drivers to
> drm_vblank_on/off so that common code like pending event cleanup can
> be done there, while drm_vblank_pre/post_modeset will be purely
> drm internal for the old UMS ioctl.
>
> Note that the drm_vblank_off still seems required in the suspend path
> since nouveau doesn't explicitly disable crtcs. But on the resume side
> drm_helper_resume_force_mode should end up calling drm_vblank_on
> through the nouveau crtc hooks already. Hence remove the call in the
> resume code.
>
> v2: Don't forget about nv50+, reported by Mario.
>
> Tested-by: Mario Kleiner
> Cc: Mario Kleiner
> Cc: Ben Skeggs
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/nouveau/dispnv04/crtc.c | 4 ++--
> drivers/gpu/drm/nouveau/nouveau_display.c | 6 +-
> drivers/gpu/drm/nouveau/nv50_display.c| 8
> 3 files changed, 11 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
> b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
> index 3d96b49fe662..dab24066fa21 100644
> --- a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
> +++ b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
> @@ -708,7 +708,7 @@ static void nv_crtc_prepare(struct drm_crtc *crtc)
> if (nv_two_heads(dev))
> NVSetOwner(dev, nv_crtc->index);
>
> - drm_vblank_pre_modeset(dev, nv_crtc->index);
> + drm_vblank_off(dev, nv_crtc->index);
> funcs->dpms(crtc, DRM_MODE_DPMS_OFF);
>
> NVBlankScreen(dev, nv_crtc->index, true);
> @@ -740,7 +740,7 @@ static void nv_crtc_commit(struct drm_crtc *crtc)
> #endif
>
> funcs->dpms(crtc, DRM_MODE_DPMS_ON);
> - drm_vblank_post_modeset(dev, nv_crtc->index);
> + drm_vblank_on(dev, nv_crtc->index);
> }
>
> static void nv_crtc_destroy(struct drm_crtc *crtc)
> diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c
> b/drivers/gpu/drm/nouveau/nouveau_display.c
> index 8670d90cdc11..9d2d647da3aa 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_display.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_display.c
> @@ -584,7 +584,7 @@ nouveau_display_resume(struct drm_device *dev, bool
> runtime)
> {
> struct nouveau_drm *drm = nouveau_drm(dev);
> struct drm_crtc *crtc;
> - int ret, head;
> + int ret;
>
> /* re-pin fb/cursors */
> list_for_each_entry(crtc, &dev->mode_config.crtc_list, head) {
> @@ -620,10 +620,6 @@ nouveau_display_resume(struct drm_device *dev, bool
> runtime)
> nv_crtc->lut.depth = 0;
> }
>
> - /* Make sure that drm and hw vblank irqs get resumed if needed. */
> - for (head = 0; head < dev->mode_config.num_crtc; head++)
> - drm_vblank_on(dev, head);
> -
> /* This should ensure we don't hit a locking problem when someone
>* wakes us up via a connector. We should never go into suspend
>* while the display is on anyways.
> diff --git a/drivers/gpu/drm/nouveau/nv50_display.c
> b/drivers/gpu/drm/nouveau/nv50_display.c
> index 7da7958556a3..a16c37d8f7e1 100644
> --- a/drivers/gpu/drm/nouveau/nv50_display.c
> +++ b/drivers/gpu/drm/nouveau/nv50_display.c
> @@ -997,6 +997,10 @@ nv50_crtc_cursor_show_hide(struct nouveau_crtc *nv_crtc,
> bool show, bool update)
> static void
> nv50_crtc_dpms(struct drm_crtc *crtc, int mode)
> {
> + if (mode == DRM_MODE_DPMS_ON)
> + drm_crtc_vblank_on(crtc);
> + else
> + drm_crtc_vblank_off(crtc);
> }
>
> static void
> @@ -1036,6 +1040,8 @@ nv50_crtc_prepare(struct drm_crtc *crtc)
> }
>
> nv50_crtc_cursor_show_hide(nv_crtc, false, false);
> +
> + drm_crtc_vblank_on(crtc);
> }
>
> static void
> @@ -1045,6 +1051,8 @@ nv50_crtc_commit(struct drm_crtc *crtc)
> struct nv50_mast *mast = nv50_mast(crtc->dev);
> u32 *push;
>
> + drm_crtc_vblank_on(crtc);
> +
> push = evo_wait(mast, 32);
> if (push) {
> if (nv50_vers(mast) < G82_DISP_CORE_CHANNEL_DMA) {
>
This is
Reviewed-and-tested-by: Mario Kleiner
-mario
[Bug 91001] lock-ups with video playback in mpv and vlc with vdpau enabled
https://bugs.freedesktop.org/show_bug.cgi?id=91001 --- Comment #1 from Michel Dänzer --- Does this only happen with particular video formats? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150617/3025d040/attachment.html>
[Bug 91001] lock-ups with video playback in mpv and vlc with vdpau enabled
https://bugs.freedesktop.org/show_bug.cgi?id=91001 --- Comment #2 from Arthur Marsh --- It appears to be a problem with H264 formats. Not seeing the problem with a raw .ts file. would mediainfo provide suitable format information for each file if I can run some more tests, or would another program provide better information on the video file encoding? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150617/fa7df903/attachment.html>
[Bug 82428] [radeonsi,R9 270X] System lockup when using mplayer/mpv with VDPAU
https://bugs.freedesktop.org/show_bug.cgi?id=82428 --- Comment #12 from Yuriy Kolesnikov --- Created attachment 116549 --> https://bugs.freedesktop.org/attachment.cgi?id=116549&action=edit kernel trace -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150617/b44e28b9/attachment.html>
[Bug 82428] [radeonsi,R9 270X] System lockup when using mplayer/mpv with VDPAU
https://bugs.freedesktop.org/show_bug.cgi?id=82428 Yuriy Kolesnikov changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #13 from Yuriy Kolesnikov --- Same hardware, same situation. Random lockups when I start to play video with VDPAU acceleration. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150617/e27c335c/attachment.html>
[Bug 82428] [radeonsi,R9 270X] System lockup when using mplayer/mpv with VDPAU
https://bugs.freedesktop.org/show_bug.cgi?id=82428 --- Comment #14 from Yuriy Kolesnikov --- OS: ArchLinux ffmpeg 1:2.7-1 libvdpau 1.1-1 mesa 10.6.0-1 mesa-vdpau 10.6.0-1 mplayer 37379-3 vdpauinfo 1.0-1 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150617/8fd47e40/attachment.html>
[Bug 82428] [radeonsi,R9 270X] System lockup when using mplayer/mpv with VDPAU
https://bugs.freedesktop.org/show_bug.cgi?id=82428 --- Comment #15 from Andy Furniss --- Can you reproduce this with mpv? What do you need to do with mplayer to produce - how often/when does it crash eg. at start or after a while. If you can't reproduce with mpv eg. mpv --hwdec=vdpau --vo=vdpau . I already have a bug open that could be a better match. Also does the kernel output vary between crashes? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150617/a5c6c5a8/attachment.html>
[Bug 82428] [radeonsi,R9 270X] System lockup when using mplayer/mpv with VDPAU
https://bugs.freedesktop.org/show_bug.cgi?id=82428 --- Comment #16 from Andy Furniss --- (In reply to Andy Furniss from comment #15) > Can you reproduce this with mpv? > > What do you need to do with mplayer to produce - how often/when does it > crash eg. at start or after a while. > > If you can't reproduce with mpv eg. > > mpv --hwdec=vdpau --vo=vdpau . > > I already have a bug open that could be a better match. > > Also does the kernel output vary between crashes? Oops I see you already said "when I start to play" - this is my bug - https://bugs.freedesktop.org/show_bug.cgi?id=83998 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150617/66f97aa8/attachment-0001.html>
[Bug 82428] [radeonsi,R9 270X] System lockup when using mplayer/mpv with VDPAU
https://bugs.freedesktop.org/show_bug.cgi?id=82428 Christian König changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #17 from Christian König --- (In reply to Yuriy Kolesnikov from comment #13) > Same hardware, same situation. Random lockups when I start to play video > with VDPAU acceleration. Witch is clearly a different bug than described in this report. Please open up a new bug report. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150617/64ff5f58/attachment.html>
[PATCH 0/2] RFC: Secure Memory Allocation Framework
The outcome of the previous RFC about how do secure data path was the need
of a secure memory allocator (https://lkml.org/lkml/2015/5/5/551)
SMAF goal is to provide a framework that allow allocating and securing
memory by using dma_buf. Each platform have it own way to perform those two
features so SMAF design allow to register helper modules to perform them.
To be sure to select the best allocation method for devices SMAF implement
deferred allocation mechanism: memory allocation is only done when the first
device effectively required it.
Allocator modules have to implement a match() to let SMAF know if they are
compatibles with devices needs.
This patch set provide an example of allocator module which use
dma_{alloc/free/mmap}_attrs() and check if at least one device have
coherent_dma_mask set to DMA_BIT_MASK(32) in match function.
I have named smaf-cma.c like it is done for drm_gem_cma_helper.c even if
a better name could be found for this file.
Secure modules are responsibles of granting and revoking devices access rights
on the memory. Secure module is also called to check if CPU map memory into
kernel and user address spaces.
An example of secure module implementation can be found here:
http://git.linaro.org/people/benjamin.gaignard/optee-sdp.git
This code isn't yet part of the patch set because it depends on generic TEE
which is still under discussion (https://lwn.net/Articles/644646/)
For allocation part of SMAF code I get inspirated by Sumit Semwal work about
constraint aware allocator.
Benjamin Gaignard (2):
create SMAF module
SMAF: add CMA allocator
drivers/Kconfig| 2 +
drivers/Makefile | 1 +
drivers/smaf/Kconfig | 11 +
drivers/smaf/Makefile | 2 +
drivers/smaf/smaf-cma.c| 198
drivers/smaf/smaf-core.c | 674 +
include/linux/smaf-allocator.h | 43 +++
include/linux/smaf-secure.h| 62
include/uapi/linux/smaf.h | 48 +++
9 files changed, 1041 insertions(+)
create mode 100644 drivers/smaf/Kconfig
create mode 100644 drivers/smaf/Makefile
create mode 100644 drivers/smaf/smaf-cma.c
create mode 100644 drivers/smaf/smaf-core.c
create mode 100644 include/linux/smaf-allocator.h
create mode 100644 include/linux/smaf-secure.h
create mode 100644 include/uapi/linux/smaf.h
--
1.9.1
[PATCH 1/2] create SMAF module
Secure Memory Allocation Framework goal is to be able
to allocate memory that can be securing.
There is so much ways to allocate and securing memory that SMAF
doesn't do it by itself but need help of additional modules.
To be sure to use the correct allocation method SMAF implement
deferred allocation (i.e. allocate memory when only really needed)
Allocation modules (smaf-alloctor.h):
SMAF could manage with multiple allocation modules at same time.
To select the good one SMAF call match() to be sure that a module
can allocate memory for a given list of devices. It is to the module
to check if the devices are compatible or not with it allocation
method.
Securing module (smaf-secure.h):
The way of how securing memory it is done is platform specific.
Secure module is responsible of grant/revoke memory access.
Signed-off-by: Benjamin Gaignard
---
drivers/Kconfig| 2 +
drivers/Makefile | 1 +
drivers/smaf/Kconfig | 5 +
drivers/smaf/Makefile | 1 +
drivers/smaf/smaf-core.c | 674 +
include/linux/smaf-allocator.h | 43 +++
include/linux/smaf-secure.h| 62
include/uapi/linux/smaf.h | 48 +++
8 files changed, 836 insertions(+)
create mode 100644 drivers/smaf/Kconfig
create mode 100644 drivers/smaf/Makefile
create mode 100644 drivers/smaf/smaf-core.c
create mode 100644 include/linux/smaf-allocator.h
create mode 100644 include/linux/smaf-secure.h
create mode 100644 include/uapi/linux/smaf.h
diff --git a/drivers/Kconfig b/drivers/Kconfig
index c0cc96b..2421fcb 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -182,4 +182,6 @@ source "drivers/thunderbolt/Kconfig"
source "drivers/android/Kconfig"
+source "drivers/smaf/Kconfig"
+
endmenu
diff --git a/drivers/Makefile b/drivers/Makefile
index 46d2554..0cca66e 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -165,3 +165,4 @@ obj-$(CONFIG_RAS) += ras/
obj-$(CONFIG_THUNDERBOLT) += thunderbolt/
obj-$(CONFIG_CORESIGHT)+= hwtracing/coresight/
obj-$(CONFIG_ANDROID) += android/
+obj-$(CONFIG_SMAF) += smaf/
diff --git a/drivers/smaf/Kconfig b/drivers/smaf/Kconfig
new file mode 100644
index 000..d36651a
--- /dev/null
+++ b/drivers/smaf/Kconfig
@@ -0,0 +1,5 @@
+config SMAF
+ tristate "Secure Memory Allocation Framework"
+ depends on DMA_SHARED_BUFFER
+ help
+ Choose this option to enable Secure Memory Allocation Framework
diff --git a/drivers/smaf/Makefile b/drivers/smaf/Makefile
new file mode 100644
index 000..40cd882
--- /dev/null
+++ b/drivers/smaf/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_SMAF) += smaf-core.o
diff --git a/drivers/smaf/smaf-core.c b/drivers/smaf/smaf-core.c
new file mode 100644
index 000..b1e787e
--- /dev/null
+++ b/drivers/smaf/smaf-core.c
@@ -0,0 +1,674 @@
+/*
+ * smaf.c
+ *
+ * Copyright (C) Linaro SA 2015
+ * Author: Benjamin Gaignard for Linaro.
+ * License terms: GNU General Public License (GPL), version 2
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct smaf_handle {
+ struct dma_buf *dmabuf;
+ struct smaf_allocator *allocator;
+ struct dma_buf *db_alloc;
+ size_t length;
+ unsigned int flags;
+ int fd;
+ bool is_secure;
+ void *secure_ctx;
+};
+
+/**
+ * struct smaf_device - smaf device node private data
+ * @misc_dev: the misc device
+ * @head: list of allocator
+ * @lock: list and secure pointer mutex
+ * @secure:pointer to secure functions helpers
+ */
+struct smaf_device {
+ struct miscdevice misc_dev;
+ struct list_head head;
+ /* list and secure pointer lock*/
+ struct mutex lock;
+ struct smaf_secure *secure;
+};
+
+static struct smaf_device smaf_dev;
+
+/**
+ * smaf_allow_cpu_access return true if CPU can access to memory
+ * if their is no secure module associated to SMAF assume that CPU can get
+ * access to the memory.
+ */
+static bool smaf_allow_cpu_access(struct smaf_handle *handle,
+ unsigned long flags)
+{
+ if (!handle->is_secure)
+ return true;
+
+ if (!smaf_dev.secure)
+ return true;
+
+ if (!smaf_dev.secure->allow_cpu_access)
+ return true;
+
+ return smaf_dev.secure->allow_cpu_access(handle->secure_ctx, flags);
+}
+
+static int smaf_grant_access(struct smaf_handle *handle, struct device *dev,
+dma_addr_t addr, size_t size,
+enum dma_data_direction dir)
+{
+ if (!handle->is_secure)
+ return 0;
+
+ if (!smaf_dev.secure)
+ return -EINVAL;
+
+ if (!smaf_dev.secure->grant_access)
+ return -EINVAL;
+
+ return smaf_dev.secure->grant_access(handle->secure_ctx,
+
[PATCH 2/2] SMAF: add CMA allocator
SMAF CMA allocator implement helpers functions to allow SMAF
to allocate contiguous memory.
match() each if at least one of the attached devices have coherent_dma_mask
set to DMA_BIT_MASK(32).
For allocation it use dma_alloc_attrs() with DMA_ATTR_WRITE_COMBINE and not
dma_alloc_writecombine to be compatible with ARM 64bits architecture
Signed-off-by: Benjamin Gaignard
---
drivers/smaf/Kconfig| 6 ++
drivers/smaf/Makefile | 1 +
drivers/smaf/smaf-cma.c | 198
3 files changed, 205 insertions(+)
create mode 100644 drivers/smaf/smaf-cma.c
diff --git a/drivers/smaf/Kconfig b/drivers/smaf/Kconfig
index d36651a..058ec4c 100644
--- a/drivers/smaf/Kconfig
+++ b/drivers/smaf/Kconfig
@@ -3,3 +3,9 @@ config SMAF
depends on DMA_SHARED_BUFFER
help
Choose this option to enable Secure Memory Allocation Framework
+
+config SMAF_CMA
+ tristate "SMAF CMA allocator"
+ depends on SMAF && HAVE_DMA_ATTRS
+ help
+ Choose this option to enable CMA allocation within SMAF
diff --git a/drivers/smaf/Makefile b/drivers/smaf/Makefile
index 40cd882..05bab01 100644
--- a/drivers/smaf/Makefile
+++ b/drivers/smaf/Makefile
@@ -1 +1,2 @@
obj-$(CONFIG_SMAF) += smaf-core.o
+obj-$(CONFIG_SMAF_CMA) += smaf-cma.o
diff --git a/drivers/smaf/smaf-cma.c b/drivers/smaf/smaf-cma.c
new file mode 100644
index 000..b3ebd57
--- /dev/null
+++ b/drivers/smaf/smaf-cma.c
@@ -0,0 +1,198 @@
+/*
+ * smaf-cma.c
+ *
+ * Copyright (C) Linaro SA 2015
+ * Author: Benjamin Gaignard for Linaro.
+ * License terms: GNU General Public License (GPL), version 2
+ */
+
+#include
+#include
+#include
+#include
+
+struct smaf_cma_buffer_info {
+ struct device *dev;
+ size_t size;
+ void *vaddr;
+ dma_addr_t paddr;
+};
+
+/**
+ * find_matching_device - iterate over the attached devices to find one
+ * with coherent_dma_mask correctly set to DMA_BIT_MASK(32).
+ * Matching device (if any) will be used to aim CMA area.
+ */
+static struct device *find_matching_device(struct dma_buf *dmabuf)
+{
+ struct dma_buf_attachment *attach_obj;
+
+ list_for_each_entry(attach_obj, &dmabuf->attachments, node) {
+ if (attach_obj->dev->coherent_dma_mask == DMA_BIT_MASK(32))
+ return attach_obj->dev;
+ }
+
+ return NULL;
+}
+
+/**
+ * smaf_cma_match - return true if at least one device has been found
+ */
+static bool smaf_cma_match(struct dma_buf *dmabuf)
+{
+ return !!find_matching_device(dmabuf);
+}
+
+static void smaf_cma_release(struct dma_buf *dmabuf)
+{
+ struct smaf_cma_buffer_info *info = dmabuf->priv;
+ DEFINE_DMA_ATTRS(attrs);
+
+ dma_set_attr(DMA_ATTR_WRITE_COMBINE, &attrs);
+
+ dma_free_attrs(info->dev, info->size, info->vaddr, info->paddr, &attrs);
+
+ kfree(info);
+}
+
+static struct sg_table *smaf_cma_map(struct dma_buf_attachment *attachment,
+enum dma_data_direction direction)
+{
+ struct smaf_cma_buffer_info *info = attachment->dmabuf->priv;
+ struct sg_table *sgt;
+ int ret;
+
+ sgt = kzalloc(sizeof(*sgt), GFP_KERNEL);
+ if (!sgt)
+ return NULL;
+
+ ret = dma_get_sgtable(info->dev, sgt, info->vaddr,
+ info->paddr, info->size);
+ if (ret < 0)
+ goto out;
+
+ sg_dma_address(sgt->sgl) = info->paddr;
+ return sgt;
+
+out:
+ kfree(sgt);
+ return NULL;
+}
+
+static void smaf_cma_unmap(struct dma_buf_attachment *attachment,
+ struct sg_table *sgt,
+ enum dma_data_direction direction)
+{
+ /* do nothing */
+}
+
+static int smaf_cma_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma)
+{
+ struct smaf_cma_buffer_info *info = dmabuf->priv;
+ int ret;
+ DEFINE_DMA_ATTRS(attrs);
+
+ dma_set_attr(DMA_ATTR_WRITE_COMBINE, &attrs);
+
+ if (info->size < vma->vm_end - vma->vm_start)
+ return -EINVAL;
+
+ vma->vm_flags |= VM_IO | VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP;
+ ret = dma_mmap_attrs(info->dev, vma, info->vaddr, info->paddr,
+info->size, &attrs);
+
+ return ret;
+}
+
+static void *smaf_cma_vmap(struct dma_buf *dmabuf)
+{
+ struct smaf_cma_buffer_info *info = dmabuf->priv;
+
+ return info->vaddr;
+}
+
+static void *smaf_kmap_atomic(struct dma_buf *dmabuf, unsigned long offset)
+{
+ struct smaf_cma_buffer_info *info = dmabuf->priv;
+
+ return (void *)info->paddr + offset;
+}
+
+static struct dma_buf_ops smaf_cma_ops = {
+ .map_dma_buf = smaf_cma_map,
+ .unmap_dma_buf = smaf_cma_unmap,
+ .mmap = smaf_cma_mmap,
+ .release = smaf_cma_release,
+ .kmap_atomic = smaf_kmap_atomic,
+ .kmap = smaf_kmap_atomic,
+ .vmap = smaf_cma_vmap,
+};
+
+static struct dma_buf *smaf_cma_allocate(struct
4.1-rc7: Xorg broken after resume on thinkpad T40p, radeon problem?
Hi! Video is broken on thinkpad T40p after resume from suspend. (In X only, text console still works.) Maybe this is related? [ 5430.193071] radeon :01:00.0: putting AGP V2 device into 4x mode [ 5430.193107] radeon :01:00.0: GTT: 256M 0xD000 - 0xDFFF [ 5430.214670] radeon :01:00.0: WB disabled [ 5430.214675] radeon :01:00.0: fence driver on ring 0 use gpu addr 0xd000 and cpu addr 0xf841a000 [ 5430.214721] [drm] radeon: ring at 0xD0001000 [ 5430.370867] [drm:r100_ring_test] *ERROR* radeon: ring test failed (scratch(0x15E8)=0xCAFEDEAD) [ 5430.370869] [drm:r100_cp_init] *ERROR* radeon: cp isn't working (-22). [ 5430.370872] radeon :01:00.0: failed initializing CP (-22). Hibernation works well here, including X. (Which has small glitch with mouse cursor being corrupted until it is changed by application). Any ideas? Pavel [0.00] Initializing cgroup subsys cpu [0.00] Linux version 4.1.0-rc7+ (pavel at amd) (gcc version 4.9.2 (Debian 4.9.2-10) ) #89 SMP Wed Jun 17 10:27:56 CEST 2015 [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009efff] usable [0.00] BIOS-e820: [mem 0x0009f000-0x0009] reserved [0.00] BIOS-e820: [mem 0x000d2000-0x000d3fff] reserved ... [ 5427.867556] PM: Syncing filesystems ... done. [ 5428.043929] PM: Preparing system for mem sleep [ 5428.044503] Freezing user space processes ... (elapsed 0.219 seconds) done. [ 5428.264427] Freezing remaining freezable tasks ... (elapsed 0.007 seconds) done. [ 5428.272397] PM: Entering mem sleep [ 5428.272445] Suspending console(s) (use no_console_suspend to debug) [ 5428.468800] wlan1: deauthenticating from 00:11:95:05:30:d7 by local choice (Reason: 3=DEAUTH_LEAVING) [ 5428.529996] parport_pc 00:07: disabled [ 5428.530278] serial 00:06: disabled [ 5428.530637] sd 0:0:0:0: [sda] Synchronizing SCSI cache [ 5428.530909] sd 0:0:0:0: [sda] Stopping disk [ 5428.530986] cfg80211: Calling CRDA to update world regulatory domain [ 5428.531296] serial 00:06: System wakeup disabled by ACPI [ 5428.585816] pci :00:1e.0: System wakeup enabled by ACPI [ 5428.588374] radeon :01:00.0: Refused to change power state, currently in D0 [ 5428.960707] PM: suspend of devices complete after 687.029 msecs [ 5428.960711] PM: suspend devices took 0.688 seconds [ 5428.963240] PM: late suspend of devices complete after 2.522 msecs [ 5428.965743] pci:00: System wakeup enabled by ACPI [ 5428.965965] uhci_hcd :00:1d.1: System wakeup enabled by ACPI [ 5429.044103] uhci_hcd :00:1d.0: System wakeup enabled by ACPI [ 5429.044148] PM: noirq suspend of devices complete after 80.904 msecs [ 5429.044391] ACPI: Preparing to enter system sleep state S3 [ 5429.428156] ACPI : EC: EC stopped [ 5429.428158] PM: Saving platform NVS memory [ 5429.428203] Disabling non-boot CPUs ... [ 5429.428203] ACPI: Low-level resume complete [ 5429.428203] ACPI : EC: EC started [ 5429.428203] PM: Restoring platform NVS memory [ 5429.428357] ACPI: Waking up from system sleep state S3 [ 5430.188112] uhci_hcd :00:1d.0: System wakeup disabled by ACPI [ 5430.188223] uhci_hcd :00:1d.1: System wakeup disabled by ACPI [ 5430.188273] pci:00: System wakeup disabled by ACPI [ 5430.188675] PM: noirq resume of devices complete after 80.536 msecs [ 5430.192180] PM: early resume of devices complete after 2.138 msecs [ 5430.192754] usb usb2: root hub lost power or was reset [ 5430.192796] usb usb3: root hub lost power or was reset [ 5430.192835] usb usb4: root hub lost power or was reset [ 5430.192986] [drm] AGP mode requested: 4 [ 5430.192990] agpgart-intel :00:00.0: AGP 2.0 bridge [ 5430.193015] agpgart-intel :00:00.0: putting AGP V2 device into 4x mode [ 5430.193071] radeon :01:00.0: putting AGP V2 device into 4x mode [ 5430.193107] radeon :01:00.0: GTT: 256M 0xD000 - 0xDFFF [ 5430.214670] radeon :01:00.0: WB disabled [ 5430.214675] radeon :01:00.0: fence driver on ring 0 use gpu addr 0xd000 and cpu addr 0xf841a000 [ 5430.214721] [drm] radeon: ring at 0xD0001000 [ 5430.370867] [drm:r100_ring_test] *ERROR* radeon: ring test failed (scratch(0x15E8)=0xCAFEDEAD) [ 5430.370869] [drm:r100_cp_init] *ERROR* radeon: cp isn't working (-22). [ 5430.370872] radeon :01:00.0: failed initializing CP (-22). [ 5430.858899] pci :00:1e.0: System wakeup disabled by ACPI [ 5430.865104] rtc_cmos 00:02: System wakeup disabled by ACPI [ 5430.866275] serial 00:06: activated [ 5430.867674] parport_pc 00:07: activated [ 5430.871577] sd 0:0:0:0: [sda] Starting disk [ 5431.032503] ata2.00: ACPI cmd ef/03:42:00:00:00:a0 (SET FEATURES) filtered out [ 5431.032507] ata2.00: ACPI cmd ef/03:0c:00:00:00:a0 (SET FEATURES) filtered out [ 5431.032712] ata2.00: ACPI cmd e3/00:1f:00:00:00:a0
4.1-rc7: Xorg broken after resume on thinkpad T40p, radeon problem?
On Wed 2015-06-17 14:43:47, Pavel Machek wrote: > Hi! > > Video is broken on thinkpad T40p after resume from suspend. (In X > only, text console still works.) > > Maybe this is related? > > [ 5430.193071] radeon :01:00.0: putting AGP V2 device into 4x mode > [ 5430.193107] radeon :01:00.0: GTT: 256M 0xD000 - 0xDFFF > [ 5430.214670] radeon :01:00.0: WB disabled > [ 5430.214675] radeon :01:00.0: fence driver on ring 0 use gpu addr > 0xd000 and cpu addr 0xf841a000 > [ 5430.214721] [drm] radeon: ring at 0xD0001000 > [ 5430.370867] [drm:r100_ring_test] *ERROR* radeon: ring test failed > (scratch(0x15E8)=0xCAFEDEAD) > [ 5430.370869] [drm:r100_cp_init] *ERROR* radeon: cp isn't working (-22). > [ 5430.370872] radeon :01:00.0: failed initializing CP (-22). > > Hibernation works well here, including X. (Which has small glitch with > mouse cursor being corrupted until it is changed by application). > 3.16.0-4-686-pae Debian 3.16.7-cktt11-1 kernel seems to have same problem, with same scratch(0x15E8)=0xCAFEDEAD message... so this is not "new" problem... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[PATCH v10 00/17] drm/exynos: atomic modesetting support
Hi Gustavo, On 2015ë 06ì 17ì¼ 05:35, Gustavo Padovan wrote: > HI Inki, > > 2015-06-15 Inki Dae : > >> Hi Gustavo, >> >> On 2015ë 06ì 02ì¼ 00:04, Gustavo Padovan wrote: >>> From: Gustavo Padovan >>> >>> Hi, >>> >>> Here goes the full support for atomic modesetting on exynos. I've >>> split the patches in the various phases of atomic support. >>> >>> v2: fixes comments by Joonyoung >>> - remove unused var in patch 09 >>> - use ->disable instead of outdated ->dpms in hdmi code >>> - remove WARN_ON from crtc enable/disable >>> >>> v3: fixes comment by Joonyoung >>> - move the removal of drm_helper_disable_unused_functions() to >>> separated patch >>> >>> v4: add patches that remove unnecessary calls to disable_plane() >>> >>> v5: fixes NULL CRTC crash on planes updates (reported by Inki and Tobias) >>> >>> v6: rebase on latest exynos_drm_next >>> >>> v7: fix comments by Joonyoung >>> - fix two checkpatch errors >>> - remove extra crtc->commit() call >>> - check for null fb on exynos_check_plane() >>> >>> v8: fix comments by Joonyoung >>> - fix merge error >>> - move drm_crtc_vblank_get to the commit that introduces atomic >>> pageflip >>> - remove .prepare() in the apropiated patch >>> - add a new patch to move exynos_drm_crtc_disable() >>> >>> v9: * fix comments by Joonyoung >>> - also remove encoder .prepare() >>> - do not shift exynos_update_plane() parameters >>> - remove unused .mode_set() and .mode_set_base() >>> * add specific exynos .atomic_commit() >>> * add split of exynos_crtc->ops->dpms() into enable() and disable() >>> * add other atomic clean ups >>> >>> v10: * fix comments by Joonyoung >>> - add more comments on exynos_atomic_commit() >>> - make exynos_crtc's .enable and .disable void >> >> I found out one issue that refresh rate gets low with display extension >> mode test. >> >> I tested it with two crtc drivers - vidi and fimd on Trats2 board. Here >> is how to test it, >> >> #echo 1 > /sys/devices/platform/exynos-drm-vidi/connection >> # modetest -M exynos -v -s 31 at 29:720x1280 -s 23 at 21:640x480 >> setting mode 720x1280-60Hz at XR24 on connectors 31, crtc 29 >> setting mode 640x480-75Hz at XR24 on connectors 23, crtc 21 >> freq: 20.00Hz >> freq: 20.00Hz >> >> As you can see, refresh rate is 20. >> >> Below is the result without atomic patch series, >> # modetest -M exynos -v -s 31 at 29:720x1280 -s 23 at 21:640x480 >> setting mode 720x1280-60Hz at XR24 on connectors 31, crtc 29 >> setting mode 640x480-75Hz at XR24 on connectors 23, crtc 21 >> freq: 60.18Hz >> freq: 49.09Hz >> >> I can see 60Hz for FIMD and 49Hz for vidi. > > I gave this a try and figured out that this might be a vidi specific > problem. If I try VIDI and FIMD I get the same results as you but with > Mixer and FIMD(the setup I actually use to test) everything works fine. Hm... Did Mixer and FIMD combination really work correctly with extension mode? > So somehow my patches caused a regression on vidi that I'm still > ivestigating. I think this issue is because page flip operations are performed in atomic: if I see correctly, when page flip is requested by modetest, the call flow is as follows, drm_atomic_helper_page_flip drm_atomic_async_commit exynos_atomic_commit ... drm_atomic_helper_wait_for_vblanks ... However, the function, drm_atomic_helper_wait_for_vblanks called by exynos_atomic_commit, waits for the vblank completion of each crtc driver . See wait_event_timeout function call in drm_atomic_helper_wait_for_vblanks function. This means that a page flip request of a crtc driver cannot be performed until the vblank completion of another crtc driver. I think you should have implemented exynos_atomic_commit function asynchronously, not synchronously like you did. So it seems that this function should be re-implemented. If my analysis is correct and you cannot post the change set within this week, I'm not sure whether the atomic patch series should go to mainline. Anyway, I will decide it and have a pull-request at the end of this week at least. Thanks, Inki Dae > > Gustavo > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" > in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
4.1-rc7: Xorg broken after resume on thinkpad T40p, radeon problem?
On 17.06.2015 14:49, Pavel Machek wrote: > On Wed 2015-06-17 14:43:47, Pavel Machek wrote: >> Hi! >> >> Video is broken on thinkpad T40p after resume from suspend. (In X >> only, text console still works.) >> >> Maybe this is related? >> >> [ 5430.193071] radeon :01:00.0: putting AGP V2 device into 4x mode >> [ 5430.193107] radeon :01:00.0: GTT: 256M 0xD000 - 0xDFFF >> [ 5430.214670] radeon :01:00.0: WB disabled >> [ 5430.214675] radeon :01:00.0: fence driver on ring 0 use gpu addr >> 0xd000 and cpu addr 0xf841a000 >> [ 5430.214721] [drm] radeon: ring at 0xD0001000 >> [ 5430.370867] [drm:r100_ring_test] *ERROR* radeon: ring test failed >> (scratch(0x15E8)=0xCAFEDEAD) >> [ 5430.370869] [drm:r100_cp_init] *ERROR* radeon: cp isn't working (-22). >> [ 5430.370872] radeon :01:00.0: failed initializing CP (-22). >> >> Hibernation works well here, including X. (Which has small glitch with >> mouse cursor being corrupted until it is changed by application). >> > 3.16.0-4-686-pae Debian 3.16.7-cktt11-1 kernel seems to have same > problem, with same scratch(0x15E8)=0xCAFEDEAD message... so this is > not "new" problem... > > Pavel Looks like CP init doesn't work. Well is there any kernel where that did worked? If yes it might be a good idea to bisect to narrow down the problem. Regards, Christian.
4.1-rc7: Xorg broken after resume on thinkpad T40p, radeon problem?
On Wed 2015-06-17 15:07:41, Christian König wrote: > On 17.06.2015 14:49, Pavel Machek wrote: > >On Wed 2015-06-17 14:43:47, Pavel Machek wrote: > >>Hi! > >> > >>Video is broken on thinkpad T40p after resume from suspend. (In X > >>only, text console still works.) > >> > >>Maybe this is related? > >> > >>[ 5430.193071] radeon :01:00.0: putting AGP V2 device into 4x mode > >>[ 5430.193107] radeon :01:00.0: GTT: 256M 0xD000 - 0xDFFF > >>[ 5430.214670] radeon :01:00.0: WB disabled > >>[ 5430.214675] radeon :01:00.0: fence driver on ring 0 use gpu addr > >>0xd000 and cpu addr 0xf841a000 > >>[ 5430.214721] [drm] radeon: ring at 0xD0001000 > >>[ 5430.370867] [drm:r100_ring_test] *ERROR* radeon: ring test failed > >>(scratch(0x15E8)=0xCAFEDEAD) > >>[ 5430.370869] [drm:r100_cp_init] *ERROR* radeon: cp isn't working (-22). > >>[ 5430.370872] radeon :01:00.0: failed initializing CP (-22). > >> > >>Hibernation works well here, including X. (Which has small glitch with > >>mouse cursor being corrupted until it is changed by application). > >> > >3.16.0-4-686-pae Debian 3.16.7-cktt11-1 kernel seems to have same > >problem, with same scratch(0x15E8)=0xCAFEDEAD message... so this is > >not "new" problem... > > > Looks like CP init doesn't work. Well is there any kernel where that did > worked? Unfortunately, not as far as I know. > If yes it might be a good idea to bisect to narrow down the problem. No such luck. I may try something like "3.0" if we are really desperate (2.6.X kernels probably won't won't boot with recent userland), but I suspect it just never worked. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
4.1-rc7: Xorg broken after resume on thinkpad T40p, radeon problem?
On 17.06.2015 15:21, Pavel Machek wrote: > On Wed 2015-06-17 15:07:41, Christian König wrote: >> On 17.06.2015 14:49, Pavel Machek wrote: >>> On Wed 2015-06-17 14:43:47, Pavel Machek wrote: Hi! Video is broken on thinkpad T40p after resume from suspend. (In X only, text console still works.) Maybe this is related? [ 5430.193071] radeon :01:00.0: putting AGP V2 device into 4x mode [ 5430.193107] radeon :01:00.0: GTT: 256M 0xD000 - 0xDFFF [ 5430.214670] radeon :01:00.0: WB disabled [ 5430.214675] radeon :01:00.0: fence driver on ring 0 use gpu addr 0xd000 and cpu addr 0xf841a000 [ 5430.214721] [drm] radeon: ring at 0xD0001000 [ 5430.370867] [drm:r100_ring_test] *ERROR* radeon: ring test failed (scratch(0x15E8)=0xCAFEDEAD) [ 5430.370869] [drm:r100_cp_init] *ERROR* radeon: cp isn't working (-22). [ 5430.370872] radeon :01:00.0: failed initializing CP (-22). Hibernation works well here, including X. (Which has small glitch with mouse cursor being corrupted until it is changed by application). >>> 3.16.0-4-686-pae Debian 3.16.7-cktt11-1 kernel seems to have same >>> problem, with same scratch(0x15E8)=0xCAFEDEAD message... so this is >>> not "new" problem... >>> >> Looks like CP init doesn't work. Well is there any kernel where that did >> worked? > Unfortunately, not as far as I know. In this case we probably can't help in any way, it's most likely some special handling required for exactly this configuration that isn't document anymore anywhere (Well, we are talking about hardware that is more than a decade old). Sorry that I don't have any better news, Christian. > >> If yes it might be a good idea to bisect to narrow down the problem. > No such luck. I may try something like "3.0" if we are really > desperate (2.6.X kernels probably won't won't boot with recent > userland), but I suspect it just never worked. > > Pavel
4.1-rc7: Xorg broken after resume on thinkpad T40p, radeon problem?
On Wed, 2015-06-17 at 15:21 +0200, Pavel Machek wrote:
> On Wed 2015-06-17 15:07:41, Christian König wrote:
> > On 17.06.2015 14:49, Pavel Machek wrote:
> > >On Wed 2015-06-17 14:43:47, Pavel Machek wrote:
> > >>Hi!
> > >>
> > >>Video is broken on thinkpad T40p after resume from suspend. (In X
> > >>only, text console still works.)
> > >>
> > >>Maybe this is related?
> > >>
> > >>[ 5430.193071] radeon :01:00.0: putting AGP V2 device into 4x mode
> > >>[ 5430.193107] radeon :01:00.0: GTT: 256M 0xD000 - 0xDFFF
> > >>[ 5430.214670] radeon :01:00.0: WB disabled
> > >>[ 5430.214675] radeon :01:00.0: fence driver on ring 0 use gpu addr
> > >>0xd000 and cpu addr 0xf841a000
> > >>[ 5430.214721] [drm] radeon: ring at 0xD0001000
> > >>[ 5430.370867] [drm:r100_ring_test] *ERROR* radeon: ring test failed
> > >>(scratch(0x15E8)=0xCAFEDEAD)
> > >>[ 5430.370869] [drm:r100_cp_init] *ERROR* radeon: cp isn't working (-22).
> > >>[ 5430.370872] radeon :01:00.0: failed initializing CP (-22).
> > >>
> > >>Hibernation works well here, including X. (Which has small glitch with
> > >>mouse cursor being corrupted until it is changed by application).
> > >>
> > >3.16.0-4-686-pae Debian 3.16.7-cktt11-1 kernel seems to have same
> > >problem, with same scratch(0x15E8)=0xCAFEDEAD message... so this is
> > >not "new" problem...
> > >
>
> > Looks like CP init doesn't work. Well is there any kernel where that did
> > worked?
>
> Unfortunately, not as far as I know.
>
> > If yes it might be a good idea to bisect to narrow down the problem.
>
> No such luck. I may try something like "3.0" if we are really
> desperate (2.6.X kernels probably won't won't boot with recent
> userland), but I suspect it just never worked.
The above looks very much like the issue that made me write commit
45171002b01b ("radeon: add AGPMode 1 quirk for RV250"). See
https://bugzilla.redhat.com/show_bug.cgi?id=531825 for a lot of
background.
Does booting with radeon.agpmode=1 survive a suspend and resume cycle?
Hope this helps,
Paul Bolle
4.1-rc7: Xorg broken after resume on thinkpad T40p, radeon problem?
Hi!
> > Unfortunately, not as far as I know.
> >
> > > If yes it might be a good idea to bisect to narrow down the problem.
> >
> > No such luck. I may try something like "3.0" if we are really
> > desperate (2.6.X kernels probably won't won't boot with recent
> > userland), but I suspect it just never worked.
>
> The above looks very much like the issue that made me write commit
> 45171002b01b ("radeon: add AGPMode 1 quirk for RV250"). See
> https://bugzilla.redhat.com/show_bug.cgi?id=531825 for a lot of
> background.
>
> Does booting with radeon.agpmode=1 survive a suspend and resume cycle?
Yes, that option helps. Thanks!
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
4.1-rc7: Xorg broken after resume on thinkpad T40p, radeon problem?
On Wed, 2015-06-17 at 16:10 +0200, Pavel Machek wrote:
> > The above looks very much like the issue that made me write commit
> > 45171002b01b ("radeon: add AGPMode 1 quirk for RV250"). See
> > https://bugzilla.redhat.com/show_bug.cgi?id=531825 for a lot of
> > background.
> >
> > Does booting with radeon.agpmode=1 survive a suspend and resume cycle?
>
> Yes, that option helps. Thanks!
Then I suggest you add another quirk for your T40p (after testing
agpmode 2 also). Because this all seems to be caused by a broken BIOS,
and/or broken AGP thingy, and/or broken RV250 (or the interaction of
these things or whatever). Maddening stuff, impossible to debug.
Good luck,
Paul Bolle
[PATCH v10 00/17] drm/exynos: atomic modesetting support
Hi Inki, 2015-06-17 Inki Dae : > Hi Gustavo, > > On 2015ë 06ì 17ì¼ 05:35, Gustavo Padovan wrote: > > HI Inki, > > > > 2015-06-15 Inki Dae : > > > >> Hi Gustavo, > >> > >> On 2015ë 06ì 02ì¼ 00:04, Gustavo Padovan wrote: > >>> From: Gustavo Padovan > >>> > >>> Hi, > >>> > >>> Here goes the full support for atomic modesetting on exynos. I've > >>> split the patches in the various phases of atomic support. > >>> > >>> v2: fixes comments by Joonyoung > >>> - remove unused var in patch 09 > >>> - use ->disable instead of outdated ->dpms in hdmi code > >>> - remove WARN_ON from crtc enable/disable > >>> > >>> v3: fixes comment by Joonyoung > >>> - move the removal of drm_helper_disable_unused_functions() to > >>> separated patch > >>> > >>> v4: add patches that remove unnecessary calls to disable_plane() > >>> > >>> v5: fixes NULL CRTC crash on planes updates (reported by Inki and Tobias) > >>> > >>> v6: rebase on latest exynos_drm_next > >>> > >>> v7: fix comments by Joonyoung > >>> - fix two checkpatch errors > >>> - remove extra crtc->commit() call > >>> - check for null fb on exynos_check_plane() > >>> > >>> v8: fix comments by Joonyoung > >>> - fix merge error > >>> - move drm_crtc_vblank_get to the commit that introduces atomic > >>> pageflip > >>> - remove .prepare() in the apropiated patch > >>> - add a new patch to move exynos_drm_crtc_disable() > >>> > >>> v9: * fix comments by Joonyoung > >>> - also remove encoder .prepare() > >>> - do not shift exynos_update_plane() parameters > >>> - remove unused .mode_set() and .mode_set_base() > >>> * add specific exynos .atomic_commit() > >>> * add split of exynos_crtc->ops->dpms() into enable() and disable() > >>> * add other atomic clean ups > >>> > >>> v10: * fix comments by Joonyoung > >>> - add more comments on exynos_atomic_commit() > >>> - make exynos_crtc's .enable and .disable void > >> > >> I found out one issue that refresh rate gets low with display extension > >> mode test. > >> > >> I tested it with two crtc drivers - vidi and fimd on Trats2 board. Here > >> is how to test it, > >> > >> #echo 1 > /sys/devices/platform/exynos-drm-vidi/connection > >> # modetest -M exynos -v -s 31 at 29:720x1280 -s 23 at 21:640x480 > >> setting mode 720x1280-60Hz at XR24 on connectors 31, crtc 29 > >> setting mode 640x480-75Hz at XR24 on connectors 23, crtc 21 > >> freq: 20.00Hz > >> freq: 20.00Hz > >> > >> As you can see, refresh rate is 20. > >> > >> Below is the result without atomic patch series, > >> # modetest -M exynos -v -s 31 at 29:720x1280 -s 23 at 21:640x480 > >> setting mode 720x1280-60Hz at XR24 on connectors 31, crtc 29 > >> setting mode 640x480-75Hz at XR24 on connectors 23, crtc 21 > >> freq: 60.18Hz > >> freq: 49.09Hz > >> > >> I can see 60Hz for FIMD and 49Hz for vidi. > > > > I gave this a try and figured out that this might be a vidi specific > > problem. If I try VIDI and FIMD I get the same results as you but with > > Mixer and FIMD(the setup I actually use to test) everything works fine. > > Hm... Did Mixer and FIMD combination really work correctly with > extension mode? Yes. collabora at singularity:~$ modetest -M exynos -s 31:1920x1080 -v -s 25:1366x768 setting mode 1920x1080-60Hz at XR24 on connectors 31, crtc 29 setting mode 1366x768-60Hz at XR24 on connectors 25, crtc 23 freq: 55.82Hz freq: 55.38Hz freq: 55.30Hz freq: 55.38Hz freq: 55.30Hz freq: 55.38Hz freq: 55.30Hz freq: 55.38Hz freq: 55.30Hz freq: 55.38Hz > > > So somehow my patches caused a regression on vidi that I'm still > > ivestigating. > > I think this issue is because page flip operations are performed in > atomic: if I see correctly, when page flip is requested by modetest, the > call flow is as follows, > > drm_atomic_helper_page_flip > drm_atomic_async_commit > exynos_atomic_commit > ... > drm_atomic_helper_wait_for_vblanks > ... > > However, the function, drm_atomic_helper_wait_for_vblanks called by > exynos_atomic_commit, waits for the vblank completion of each crtc > driver . See wait_event_timeout function call in > drm_atomic_helper_wait_for_vblanks function. > > This means that a page flip request of a crtc driver cannot be performed > until the vblank completion of another crtc driver. I think you should > have implemented exynos_atomic_commit function asynchronously, not > synchronously like you did. So it seems that this function should be > re-implemented. I have a patch for it already. I'll resend a v2 of my last series. > > If my analysis is correct and you cannot post the change set within this > week, I'm not sure whether the atomic patch series should go to > mainline. Anyway, I will decide it and have a pull-request at the end of > this week at least. We have about 3 months to fix this, until v4.2 is out, n
inverted brightness for HP notebook
Hi, Jani Nikula linux.intel.com> writes: > On Thu, 13 Nov 2014, olivier.fambon free.fr wrote: >> $ lspci | grep VGA >> 00:02.0 VGA compatible controller: Intel Corporation ValleyView Gen7 (rev 0e) >> $ sudo lspci -v -s 00:02 >> 00:02.0 VGA compatible controller: Intel Corporation ValleyView Gen7 (rev 0e) (prog-if 00 [VGA controller]) >> Subsystem: Hewlett-Packard Company Device 2213 >> Flags: bus master, fast devsel, latency 0, IRQ 107 >> Memory at 9000 (32-bit, non-prefetchable) [size=4M] >> Memory at 8000 (32-bit, prefetchable) [size=256M] >> I/O ports at 3050 [size=8] >> Expansion ROM at [disabled] >> Capabilities: [d0] Power Management version 2 >> Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit- >> Capabilities: [b0] Vendor Specific Information: Len=07 >> Kernel driver in use: i915 >> => requires the following to make brightness control keys work as expected >> $ cat /etc/modprobe.d/i915.conf >> options i915 invert_brightness=1 As there's a specific broadwell i915 module, you have to adapt as follows: options i915_bdw invert_brightness=1 > I highly doubt this. This might be true for some gen4 models, but not > Valleyview. The above mentioned i915_bdw option fixes the backlight inversion on my HP 250 G3 (same lspci output as in original post) So long. Max
[Bug 91009] [radeonsi, R9 270X] Random system lockup when start to play H.264 video in mplayer with VDPAU
https://bugs.freedesktop.org/show_bug.cgi?id=91009 Bug ID: 91009 Summary: [radeonsi, R9 270X] Random system lockup when start to play H.264 video in mplayer with VDPAU Product: Mesa Version: 10.6 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel at lists.freedesktop.org Reporter: yurikoles at gmail.com QA Contact: dri-devel at lists.freedesktop.org Created attachment 116559 --> https://bugs.freedesktop.org/attachment.cgi?id=116559&action=edit dmesg As I can count, it's happens about every 10-15 start of VDPAU decoding, kernel traces vary. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150617/23ac1841/attachment.html>
[Bug 91009] [radeonsi, R9 270X] Random system lockup when start to play H.264 video in mplayer with VDPAU
https://bugs.freedesktop.org/show_bug.cgi?id=91009 --- Comment #1 from Yuriy Kolesnikov --- Created attachment 116560 --> https://bugs.freedesktop.org/attachment.cgi?id=116560&action=edit dmesg2 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150617/8e395723/attachment.html>
[Bug 91009] [radeonsi, R9 270X] Random system lockup when start to play H.264 video in mplayer with VDPAU
https://bugs.freedesktop.org/show_bug.cgi?id=91009 Yuriy Kolesnikov changed: What|Removed |Added CC||yurikoles at gmail.com --- Comment #2 from Yuriy Kolesnikov --- Created attachment 116561 --> https://bugs.freedesktop.org/attachment.cgi?id=116561&action=edit dmesg3 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150617/e1274daa/attachment.html>
[Bug 91009] [radeonsi, R9 270X] Random system lockup when start to play H.264 video in mplayer with VDPAU
https://bugs.freedesktop.org/show_bug.cgi?id=91009 --- Comment #3 from Christian König --- Well the dmesg you have attached so far doesn't show any problem with the GFX driver, but rather an kernel oops completely unrelated to GFX. Are you sure the problem is limited to VDPAU or do you have attached the wrong logs? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150617/da6cd5ea/attachment.html>
[Bug 91009] [radeonsi, R9 270X] Random system lockup when start to play H.264 video in mplayer with VDPAU
https://bugs.freedesktop.org/show_bug.cgi?id=91009 --- Comment #4 from Yuriy Kolesnikov --- I'm only sure that this _when_ this is happening: when I start to play video with VDPAU. And there was no other oopses in near past. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150617/d2de76ca/attachment.html>
[Bug 90997] [apitrace] GPU lockup with Dishonored and Gallium Nine
https://bugs.freedesktop.org/show_bug.cgi?id=90997 --- Comment #3 from sarnex --- The hang still occurs on LLVM 3.5.2 and 3.6.1. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150617/d0ca867b/attachment-0001.html>
[Bug 100071] New: Crash on several PRIME radeon usage
https://bugzilla.kernel.org/show_bug.cgi?id=100071 Bug ID: 100071 Summary: Crash on several PRIME radeon usage Product: Drivers Version: 2.5 Kernel Version: 4.0.4 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri at kernel-bugs.osdl.org Reporter: higuita at gmx.net Regression: No I have a lenovo thinkpad S440 with this hardware: $ lspci | grep "Display\|VGA" 00:02.0 VGA compatible controller: Intel Corporation Haswell-ULT Integrated Graphics Controller (rev 09) 06:00.0 Display controller: Advanced Micro Devices, Inc. [AMD/ATI] Sun XT [Radeon HD 8670A/8670M/8690M] (rev ff) i'm using ubuntu 15.04, but with the kernek 4.0.4. i'm using Mesa 10.5.2 I use this to setup the PRIME: xrandr --setprovideroffloadsink radeon Intel xcompmgr & and i start the warthunder game (closed source, bug free game) using this DRI_PRIME=1 ./aces All works fine, but after about 2 to 4 start game/exit cycles i usually have a crash that will lock the X, around the place where one should get the login screen here is the dmesg log: Jun 16 13:25:22 danielleite kernel: [ 44.018512] [drm] ib test on ring 2 succeeded in 0 usecs Jun 16 13:25:22 danielleite kernel: [ 44.018526] [drm] ib test on ring 3 succeeded in 0 usecs Jun 16 13:25:22 danielleite kernel: [ 44.018539] [drm] ib test on ring 4 succeeded in 0 usecs Jun 16 14:13:22 danielleite kernel: [ 2926.554564] BUG: unable to handle kernel paging request at 140c Jun 16 14:13:22 danielleite kernel: [ 2926.554589] IP: [] radeon_ttm_tt_create+0xaf/0xe0 [radeon] Jun 16 14:13:22 danielleite kernel: [ 2926.554628] PGD c61db067 PUD c61e7067 PMD 0 Jun 16 14:13:22 danielleite kernel: [ 2926.554643] Oops: [#1] SMP Jun 16 14:13:22 danielleite kernel: [ 2926.554653] Modules linked in: xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ipt_REJECT nf_reject_ipv4 xt_tcpudp bridge stp llc ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter ip_tables x_tables binfmt_misc rfcomm bnep ax88179_178a usbnet arc4 intel_rapl iosf_mbi x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel iwlmvm kvm mac80211 iwlwifi joydev serio_raw snd_hda_codec_hdmi rtsx_pci_ms cfg80211 lpc_ich memstick snd_hda_codec_conexant uvcvideo snd_hda_codec_generic videobuf2_vmalloc videobuf2_memops videobuf2_core btusb v4l2_common snd_usb_audio videodev thinkpad_acpi snd_hda_intel bluetooth snd_hda_controller snd_usbmidi_lib media snd_hda_codec nvram snd_hwdep snd_pcm snd_seq_midi snd_seq_midi_event mei_me mei shpchp snd_rawmidi snd_seq snd_seq_device snd_timer snd soundcore intel_smartconnect mac_hid parport_pc ppdev lp parport autofs4 btrfs xor raid6_pq dm_crypt hid_generic usbhid hid rtsx_pci_sdmmc crct10dif_pclmul crc32_pclmul ghash_clmulni_intel amdkfd amd_iommu_v2 aesni_intel aes_x86_64 lrw gf128mul radeon glue_helper ablk_helper cryptd i915 psmouse ahci libahci ttm i2c_algo_bit drm_kms_helper drm r8169 rtsx_pci mii video Jun 16 14:13:22 danielleite kernel: [ 2926.555023] CPU: 3 PID: 2576 Comm: aces Not tainted 4.0.4-040004-generic #201505171336 Jun 16 14:13:22 danielleite kernel: [ 2926.555046] Hardware name: LENOVO 20AYA05KPG/20AYA05KPG, BIOS J3ET59WW (1.59 ) 07/15/2014 Jun 16 14:13:22 danielleite kernel: [ 2926.555068] task: 8801fbe6bc00 ti: 8800b71a task.ti: 8800b71a Jun 16 14:13:22 danielleite kernel: [ 2926.555088] RIP: 0010:[] [] radeon_ttm_tt_create+0xaf/0xe0 [radeon] Jun 16 14:13:22 danielleite kernel: [ 2926.555124] RSP: 0018:8800b71a39c8 EFLAGS: 00010202 Jun 16 14:13:22 danielleite kernel: [ 2926.555138] RAX: 125c RBX: 8802205cac00 RCX: Jun 16 14:13:22 danielleite kernel: [ 2926.555157] RDX: 0001 RSI: 0001 RDI: 8802205cac00 Jun 16 14:13:22 danielleite kernel: [ 2926.555177] RBP: 8800b71a39f8 R08: 0001 R09: ea0007b2d700 Jun 16 14:13:22 danielleite kernel: [ 2926.555196] R10: c04cf7cc R11: 8802211a1a38 R12: 8800b1cac1f0 Jun 16 14:13:22 danielleite kernel: [ 2926.555215] R13: R14: 0001 R15: 0001 Jun 16 14:13:22 danielleite kernel: [ 2926.555234] FS: 7f7c42151700() GS:88022f2c() knlGS: Jun 16 14:13:22 danielleite kernel: [ 2926.555256] CS: 0010 DS: ES: CR0: 80050033 Jun 16 14:13:22 danielleite kernel: [ 2926.555271] CR2: 140c CR3: b1c0b000 CR4: 001407e0 Jun 16 14:13:22 danielleite kernel: [ 2926.555290] Stack: Jun 16 14:13:22 danielleite kernel: [ 2926.555296] 8800 8802205cac00 8800b1cac1f0 8800b71a3c10 Jun 16 14:13:22 danielleite kernel: [ 2926.555318]
[Intel-gfx] [PATCH 6/8] pwm: crc: Add Crystalcove (CRC) PWM driver
On Wed, May 20, 2015 at 8:39 PM, Shobhit Kumar wrote:
> On Thu, May 7, 2015 at 12:49 PM, Shobhit Kumar wrote:
>> On Wed, May 6, 2015 at 5:44 PM, Thierry Reding
>> wrote:
>>> On Tue, May 05, 2015 at 03:08:36PM +0530, Shobhit Kumar wrote:
The Crystalcove PMIC controls PWM signals and this driver exports that
>>>
>>> You say signal_s_ here, but you only expose a single PWM device. Does
>>> the PMIC really control more than one? If it isn't, this should probably
>>> become: "controls a PWM output and this driver...".
>>
>> Actually it does support 3 of them but on the platform only one is
>> being used and I exported only that as of now. Probably I should
>> expand a little in the commit message indicating this. will re-post
>> after fixing based on your other comments.
>
> Updates pending due to personal leave. Can be expected next week.
Folks, really sorry, been busy with lot of unexpected and unavoidable
stuff. Working on getting the patches right. Expect them this week.
>>>
capability as a PWM chip driver. This is platform device implementtaion
>>>
>>> "implementation"
>>>
of the drivers/mfd cell device for CRC PMIC
>>>
>>> Sentences should end with a full stop.
>>>
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index b1541f4..954da3e 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -183,6 +183,13 @@ config PWM_LPC32XX
To compile this driver as a module, choose M here: the module
will be called pwm-lpc32xx.
+config PWM_CRC
+ bool "Intel Crystalcove (CRC) PWM support"
+ depends on X86 && INTEL_SOC_PMIC
+ help
+ Generic PWM framework driver for Crystalcove (CRC) PMIC based PWM
+ control.
+
>>>
>>> This is badly sorted. Please keep the list sorted alphabetically.
>>>
config PWM_LPSS
tristate "Intel LPSS PWM support"
depends on X86
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index ec50eb5..3d38fed 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -35,3 +35,4 @@ obj-$(CONFIG_PWM_TIPWMSS) += pwm-tipwmss.o
obj-$(CONFIG_PWM_TWL)+= pwm-twl.o
obj-$(CONFIG_PWM_TWL_LED)+= pwm-twl-led.o
obj-$(CONFIG_PWM_VT8500) += pwm-vt8500.o
+obj-$(CONFIG_PWM_CRC)+= pwm-crc.o
>>>
>>> This too.
>>>
diff --git a/drivers/pwm/pwm-crc.c b/drivers/pwm/pwm-crc.c
new file mode 100644
index 000..987f3b4
--- /dev/null
+++ b/drivers/pwm/pwm-crc.c
@@ -0,0 +1,171 @@
+/*
+ * pwm-crc.c - Intel Crystal Cove PWM Driver
>>>
>>> I think you can safely remove this line. You already know what file it
>>> is when you open it in your editor, and the description is in the
>>> MODULE_DESCRIPTION string already.
>>>
+ *
+ * Copyright (C) 2015 Intel Corporation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version
+ * 2 as published by the Free Software Foundation.
+ *
+ * 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.
+ *
+ * Author: Shobhit Kumar
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#define PWM0_CLK_DIV 0x4B
+#define PWM_OUTPUT_ENABLE (1<<7)
>>>
>>> Should have spaces around <<.
>>>
+#define PWM_DIV_CLK_0 0x00 /* DIVIDECLK = BASECLK */
+#define PWM_DIV_CLK_100 0x63 /* DIVIDECLK = BASECLK/100 */
+#define PWM_DIV_CLK_128 0x7F /* DIVIDECLK = BASECLK/128 */
+
+#define PWM0_DUTY_CYCLE 0x4E
+#define BACKLIGHT_EN 0x51
+
+#define PWM_MAX_LEVEL0xFF
+
+#define PWM_BASE_CLK 6000/* 6 MHz */
>>>
>>> This number is actually 6 KHz. I think it'd be better if you stuck with
>>> one unit here. Or perhaps there's some other reason why you can't use
>>> 600 here instead?
>>>
+#define PWM_MAX_PERIOD_NS21333 /* 46.875KHz */
+
+/**
+ * struct crystalcove_pwm - Crystal Cove PWM controller
+ * @chip: the abstract pwm_chip structure.
+ * @regmap: the regmap from the parent device.
+ */
+struct crystalcove_pwm {
+ struct pwm_chip chip;
+ struct platform_device *pdev;
>>>
>>> I think I had at some point requested that you get rid of this and use
>>> the chip.dev member instead. There's no kerneldoc for it and it isn't
>>> (well, almost, see below) used anywhere else, so perhaps you forgot to
>>> remove it here?
>>>
+ struct regmap *regmap;
+};
+
+static inline struct crystalcove_pw
[PATCH v2 00/32] acpi-video: Rewrite backlight interface selection logic
On Wed, Jun 17, 2015 at 5:39 AM, Darren Hart wrote: > On Tue, Jun 16, 2015 at 01:22:40AM +0200, Rafael Wysocki wrote: >> On Friday, June 12, 2015 01:23:19 PM Hans de Goede wrote: >> > Hi All, >> > >> > Here is v2 of my rewrite / cleanup of the acpi-video (and platform/x86) >> > backlight interface selection logic. >> > >> > The major change in v2 of this set are 2 changes to the patch titled >> > "acpi-video-detect: video: Make video_detect code part of the video >> > module": >> > >> > 1) The __setup call for the acpi_backlight= handling is moved to >> >acpi/util.c as __setup may only be used by code which is always builtin >> > 2) video.c is renamed to acpi_video.c so that it can be combined with >> >video_detect.c into video.ko >> > >> > These 2 changes result in the backlight kernel commandline options after >> > this >> > patch-set being 100% compatible with the old options, with the exception of >> > the removal of the video.use_native_backlight option as that now is folded >> > into acpi_backlight=[video|vendor|native|none] rather then having 2 options >> > which influence each other in interesting ways. >> > >> > Besides that there is a small change to the dell-laptop port to the new API >> > removing an unnecessary #ifdef ACPI. >> >> I tried to queue this series up for 4.2, but patch [06/32] didn't apply for >> me, >> so I decided to apply another patch I've got recently instead and which is >> now >> in my linux-next branch. >> >> Can you please rebase the series on top of linux-pm.git/linux-next and >> resend it? > > Rafael, do you intent to carry this entire series and submit via linux-pm? Yes, I do. Thanks, Rafael
[PATCH] nvidia/noveau: Fix color mask
The expression (~0 >> x) will always yield all-ones, because the right
shift is an arithmetic right shift that will always shift ones in.
Accordingly ~(~0 >> x) will always be zero.
Hence 'mask' will always be zero in this case.
Fix this by forcing a logical right shift instead of an arithmetic
right shift by using an unsigned int constant.
Signed-off-by: Michael Buesch
---
This patch is untested, because I do not have the hardware.
Index: linux/drivers/gpu/drm/nouveau/nv50_fbcon.c
===
--- linux.orig/drivers/gpu/drm/nouveau/nv50_fbcon.c
+++ linux/drivers/gpu/drm/nouveau/nv50_fbcon.c
@@ -96,7 +96,7 @@ nv50_fbcon_imageblit(struct fb_info *inf
struct nouveau_drm *drm = nouveau_drm(nfbdev->dev);
struct nouveau_channel *chan = drm->channel;
uint32_t width, dwords, *data = (uint32_t *)image->data;
- uint32_t mask = ~(~0 >> (32 - info->var.bits_per_pixel));
+ uint32_t mask = ~(~0U >> (32 - info->var.bits_per_pixel));
uint32_t *palette = info->pseudo_palette;
int ret;
Index: linux/drivers/gpu/drm/nouveau/nvc0_fbcon.c
===
--- linux.orig/drivers/gpu/drm/nouveau/nvc0_fbcon.c
+++ linux/drivers/gpu/drm/nouveau/nvc0_fbcon.c
@@ -96,7 +96,7 @@ nvc0_fbcon_imageblit(struct fb_info *inf
struct nouveau_drm *drm = nouveau_drm(nfbdev->dev);
struct nouveau_channel *chan = drm->channel;
uint32_t width, dwords, *data = (uint32_t *)image->data;
- uint32_t mask = ~(~0 >> (32 - info->var.bits_per_pixel));
+ uint32_t mask = ~(~0U >> (32 - info->var.bits_per_pixel));
uint32_t *palette = info->pseudo_palette;
int ret;
Index: linux/drivers/video/fbdev/nvidia/nv_accel.c
===
--- linux.orig/drivers/video/fbdev/nvidia/nv_accel.c
+++ linux/drivers/video/fbdev/nvidia/nv_accel.c
@@ -351,7 +351,7 @@ static void nvidiafb_mono_color_expand(s
const struct fb_image *image)
{
struct nvidia_par *par = info->par;
- u32 fg, bg, mask = ~(~0 >> (32 - info->var.bits_per_pixel));
+ u32 fg, bg, mask = ~(~0U >> (32 - info->var.bits_per_pixel));
u32 dsize, width, *data = (u32 *) image->data, tmp;
int j, k = 0;
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150617/e8ad8533/attachment-0001.sig>
[PATCH] Fixes: 9697dffb098d ("drm: Turn off Legacy Context Functions")
Commit 9697dffb098d ("drm: Turn off Legacy Context Functions")
added checks for legacy features to several functions in the
drm driver. It is now possible for the void functions changed by
this commit to return an int error code. This patch updates
the function definitions to return int. This fixes the build warnings:
warning: âreturnâ with a value, in function returning void
return -EINVAL
Signed-off-by: Eddie Kovsky
---
drivers/gpu/drm/drm_context.c | 12 +---
drivers/gpu/drm/drm_legacy.h | 6 +++---
2 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_context.c b/drivers/gpu/drm/drm_context.c
index f3ea657f6574..3c2f4a76f934 100644
--- a/drivers/gpu/drm/drm_context.c
+++ b/drivers/gpu/drm/drm_context.c
@@ -51,7 +51,7 @@ struct drm_ctx_list {
* in drm_device::ctx_idr, while holding the drm_device::struct_mutex
* lock.
*/
-void drm_legacy_ctxbitmap_free(struct drm_device * dev, int ctx_handle)
+int drm_legacy_ctxbitmap_free(struct drm_device * dev, int ctx_handle)
{
if (!drm_core_check_feature(dev, DRIVER_KMS_LEGACY_CONTEXT) &&
drm_core_check_feature(dev, DRIVER_MODESET))
@@ -60,6 +60,8 @@ void drm_legacy_ctxbitmap_free(struct drm_device * dev, int
ctx_handle)
mutex_lock(&dev->struct_mutex);
idr_remove(&dev->ctx_idr, ctx_handle);
mutex_unlock(&dev->struct_mutex);
+
+ return 0;
}
/**
@@ -107,7 +109,7 @@ int drm_legacy_ctxbitmap_init(struct drm_device * dev)
* Free all idr members using drm_ctx_sarea_free helper function
* while holding the drm_device::struct_mutex lock.
*/
-void drm_legacy_ctxbitmap_cleanup(struct drm_device * dev)
+int drm_legacy_ctxbitmap_cleanup(struct drm_device * dev)
{
if (!drm_core_check_feature(dev, DRIVER_KMS_LEGACY_CONTEXT) &&
drm_core_check_feature(dev, DRIVER_MODESET))
@@ -116,6 +118,8 @@ void drm_legacy_ctxbitmap_cleanup(struct drm_device * dev)
mutex_lock(&dev->struct_mutex);
idr_destroy(&dev->ctx_idr);
mutex_unlock(&dev->struct_mutex);
+
+ return 0;
}
/**
@@ -127,7 +131,7 @@ void drm_legacy_ctxbitmap_cleanup(struct drm_device * dev)
* @file. Note that after this call returns, new contexts might be added if
* the file is still alive.
*/
-void drm_legacy_ctxbitmap_flush(struct drm_device *dev, struct drm_file *file)
+int drm_legacy_ctxbitmap_flush(struct drm_device *dev, struct drm_file *file)
{
struct drm_ctx_list *pos, *tmp;
@@ -150,6 +154,8 @@ void drm_legacy_ctxbitmap_flush(struct drm_device *dev,
struct drm_file *file)
}
mutex_unlock(&dev->ctxlist_mutex);
+
+ return 0;
}
/*@}*/
diff --git a/drivers/gpu/drm/drm_legacy.h b/drivers/gpu/drm/drm_legacy.h
index c1dc61473db5..26c16220e475 100644
--- a/drivers/gpu/drm/drm_legacy.h
+++ b/drivers/gpu/drm/drm_legacy.h
@@ -43,9 +43,9 @@ struct drm_file;
#define DRM_RESERVED_CONTEXTS 1
int drm_legacy_ctxbitmap_init(struct drm_device *dev);
-void drm_legacy_ctxbitmap_cleanup(struct drm_device *dev);
-void drm_legacy_ctxbitmap_free(struct drm_device *dev, int ctx_handle);
-void drm_legacy_ctxbitmap_flush(struct drm_device *dev, struct drm_file *file);
+int drm_legacy_ctxbitmap_cleanup(struct drm_device *dev);
+int drm_legacy_ctxbitmap_free(struct drm_device *dev, int ctx_handle);
+int drm_legacy_ctxbitmap_flush(struct drm_device *dev, struct drm_file *file);
int drm_legacy_resctx(struct drm_device *d, void *v, struct drm_file *f);
int drm_legacy_addctx(struct drm_device *d, void *v, struct drm_file *f);
--
2.4.3
[PATCH] drm: bridge/dw_hdmi: Filter modes > 165MHz for DVI
If you plug in a DVI monitor to your HDMI port, you need to filter out
clocks > 165MHz. That's because 165MHz is the maximum clock rate that
we can run single-link DVI at.
If you want to run high resolutions to DVI, you'd need some type of an
active adapter that pretended that it was HDMI, interpreted the
signal, and produced a new dual link DVI signal at a lower clock rate.
Signed-off-by: Doug Anderson
---
Note: this patch was tested against a 3.14 kernel with backports. It
was only compile tested against linuxnext, but the code is
sufficiently similar that I'm convinced it will work there.
drivers/gpu/drm/bridge/dw_hdmi.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c b/drivers/gpu/drm/bridge/dw_hdmi.c
index 816d104..48b8532 100644
--- a/drivers/gpu/drm/bridge/dw_hdmi.c
+++ b/drivers/gpu/drm/bridge/dw_hdmi.c
@@ -1421,8 +1421,12 @@ dw_hdmi_connector_mode_valid(struct drm_connector
*connector,
{
struct dw_hdmi *hdmi = container_of(connector,
struct dw_hdmi, connector);
+ struct hdmi_vmode *vmode = &hdmi->hdmi_data.video_mode;
enum drm_mode_status mode_status = MODE_OK;
+ if (mode->clock > 165000 && vmode->mdvi)
+ return MODE_BAD;
+
if (hdmi->plat_data->mode_valid)
mode_status = hdmi->plat_data->mode_valid(connector, mode);
--
2.4.3.573.g4eafbef
[PATCH] nvidia/noveau: Fix color mask
On Wed, Jun 17, 2015 at 1:05 PM, Michael Büsch wrote:
> The expression (~0 >> x) will always yield all-ones, because the right
> shift is an arithmetic right shift that will always shift ones in.
> Accordingly ~(~0 >> x) will always be zero.
> Hence 'mask' will always be zero in this case.
>
> Fix this by forcing a logical right shift instead of an arithmetic
> right shift by using an unsigned int constant.
>
> Signed-off-by: Michael Buesch
Confirmed that this does indeed happen with
#include
int main(int argc, char *argv[]) {
unsigned mask = ~(~0 >> (32 - (argv[1][0] - '0')));
printf("%08x\n", mask);
}
I guess fbdev/nvidia/nv_accel.c was the source of all this, as the
code is identical, and it probably came first.
FWIW this is
Reviewed-by: Ilia Mirkin
>
> ---
>
> This patch is untested, because I do not have the hardware.
>
>
> Index: linux/drivers/gpu/drm/nouveau/nv50_fbcon.c
> ===
> --- linux.orig/drivers/gpu/drm/nouveau/nv50_fbcon.c
> +++ linux/drivers/gpu/drm/nouveau/nv50_fbcon.c
> @@ -96,7 +96,7 @@ nv50_fbcon_imageblit(struct fb_info *inf
> struct nouveau_drm *drm = nouveau_drm(nfbdev->dev);
> struct nouveau_channel *chan = drm->channel;
> uint32_t width, dwords, *data = (uint32_t *)image->data;
> - uint32_t mask = ~(~0 >> (32 - info->var.bits_per_pixel));
> + uint32_t mask = ~(~0U >> (32 - info->var.bits_per_pixel));
> uint32_t *palette = info->pseudo_palette;
> int ret;
>
> Index: linux/drivers/gpu/drm/nouveau/nvc0_fbcon.c
> ===
> --- linux.orig/drivers/gpu/drm/nouveau/nvc0_fbcon.c
> +++ linux/drivers/gpu/drm/nouveau/nvc0_fbcon.c
> @@ -96,7 +96,7 @@ nvc0_fbcon_imageblit(struct fb_info *inf
> struct nouveau_drm *drm = nouveau_drm(nfbdev->dev);
> struct nouveau_channel *chan = drm->channel;
> uint32_t width, dwords, *data = (uint32_t *)image->data;
> - uint32_t mask = ~(~0 >> (32 - info->var.bits_per_pixel));
> + uint32_t mask = ~(~0U >> (32 - info->var.bits_per_pixel));
> uint32_t *palette = info->pseudo_palette;
> int ret;
>
> Index: linux/drivers/video/fbdev/nvidia/nv_accel.c
> ===
> --- linux.orig/drivers/video/fbdev/nvidia/nv_accel.c
> +++ linux/drivers/video/fbdev/nvidia/nv_accel.c
> @@ -351,7 +351,7 @@ static void nvidiafb_mono_color_expand(s
>const struct fb_image *image)
> {
> struct nvidia_par *par = info->par;
> - u32 fg, bg, mask = ~(~0 >> (32 - info->var.bits_per_pixel));
> + u32 fg, bg, mask = ~(~0U >> (32 - info->var.bits_per_pixel));
> u32 dsize, width, *data = (u32 *) image->data, tmp;
> int j, k = 0;
>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
[Intel-gfx] [BUG, bisect] Re: drm/i915: WARN_ON(dev_priv->mm.busy)
Jani, On Mon, Jun 15, 2015 at 02:40:42PM +0300, Jani Nikula wrote: > On Mon, 15 Jun 2015, Ville Syrjälä wrote: > > On Mon, Jun 15, 2015 at 01:25:38AM -0700, Jeremiah Mahler wrote: > >> Daniel, > >> > >> On Mon, Jun 15, 2015 at 08:57:47AM +0200, Daniel Vetter wrote: > >> > Can you please retest with > >> > > >> > commit 0aedb1626566efd72b369c01992ee7413c82a0c5 > >> > Author: Ville Syrjälä > >> > Date: Thu May 28 18:32:36 2015 +0300 > >> > > >> > drm/i915: Don't skip request retirement if the active list is empty > >> > > >> > Thanks, Daniel > >> > > >> > >> The bug is still present with that patch applied. And it is still > >> present up to linux-next 20150611. > > > > The patch was misapplied, so what's in the tree at the moment isn't what > > I sent to the list. > > This should be rectified in current drm-intel-nightly branch of > [1]. Jeremiah, please give that a try. > > BR, > Jani. > > > [1] http://cgit.freedesktop.org/drm-intel > > > > > > -- > > Ville Syrjälä > > Intel OTC > > -- > Jani Nikula, Intel Open Source Technology Center I tested drm-intel-nightly and all the warnings appear to be resolved in there. So when these get to -next it should be good. -- - Jeremiah Mahler
[PATCH] drm: bridge/dw_hdmi: Filter modes > 165MHz for DVI
Russell,
On Wed, Jun 17, 2015 at 4:30 PM, Russell King - ARM Linux
wrote:
> On Wed, Jun 17, 2015 at 04:14:07PM -0700, Doug Anderson wrote:
>> If you plug in a DVI monitor to your HDMI port, you need to filter out
>> clocks > 165MHz. That's because 165MHz is the maximum clock rate that
>> we can run single-link DVI at.
>>
>> If you want to run high resolutions to DVI, you'd need some type of an
>> active adapter that pretended that it was HDMI, interpreted the
>> signal, and produced a new dual link DVI signal at a lower clock rate.
>>
>> Signed-off-by: Doug Anderson
>> ---
>> Note: this patch was tested against a 3.14 kernel with backports. It
>> was only compile tested against linuxnext, but the code is
>> sufficiently similar that I'm convinced it will work there.
>
> Really? I have to wonder what your testing was...
>
> hdmi->vic = drm_match_cea_mode(mode);
>
> if (!hdmi->vic) {
> dev_dbg(hdmi->dev, "Non-CEA mode used in HDMI\n");
> hdmi->hdmi_data.video_mode.mdvi = true;
> } else {
> dev_dbg(hdmi->dev, "CEA mode used vic=%d\n", hdmi->vic);
> hdmi->hdmi_data.video_mode.mdvi = false;
> }
>
> mdvi indicates whether the _currently set mode_ is a CEA mode or not (imho,
> it's mis-named). It doesn't indicate whether we have a HDMI display device
> or a DVI display device connected, which seems to be what you want to use
> it for below.
>
> To sort that, what you need to do is detect a HDMI display device using
> drm_detect_hdmi_monitor() on the EDID received from the device before
> parsing the modes, and save that value in a dw_hdmi struct member, and
> I'd suggest that it's a top-level struct member, not buried in 'hdmi_data'
> or 'video_mode'.
OK, so clearly my patch won't work against mainline. I guess it's a
good thing that I pointed out that it was only tested locally (would
have been better to test against mainline, but I don't think that's so
easy since there are several unlanded patches in mainline for
Rockchip).
As pointed out by others at , locally
our kernel has a slightly older version of
, which would change mdvi to be
as needed.
...so I guess my change is blocked on someone reviewing/landing that
series. If that series is rejected (or is changed sufficiently so
that mdvi no longer is set via drm_detect_hdmi_monitor() then my patch
will need to be re-spun.
-Doug
