[Bug 76082] Metro Last Light fail to start

for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140325/37fb78c7/attachment.html>

[PATCH 4/5] i915: Convert last uses of __FUNCTION__ to __func__

On Tue, Mar 25, 2014 at 12:35:06PM -0700, Joe Perches wrote: > Just about all of these have been converted to __func__, > so convert the last uses. > > Signed-off-by: Joe Perches Pulled into drm-intel, should land in 3.15. Thanks, Daniel > --- > drivers/gpu/drm/i915/dvo_ns2501.c | 15

[Intel-gfx] [PATCH 1/3] drm/i915: Don't set mode_config's cursor size

On Tue, Mar 25, 2014 at 7:51 PM, Damien Lespiau wrote: > On Tue, Mar 25, 2014 at 07:23:26PM +0100, Daniel Vetter wrote: >> Or we simply do this per-pixel format with one for each framebuffer plane, >> i.e. >> >> struct drm_get_plane_fb_limits { >> uint32_t plane_id; /* in */ >>

[Bug 76564] [AMD Fusion E-350] HDMI refresh rates doesn't match expectations

nt to take a second look at this and try to compare the settings fglrx and radeon uses for the same mode. -- 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/20140325/e1b25102/attachment.html>

[PATCH] drm/bridge: PTN3460 needs DRM_KMS_HELPER

2014-03-25 20:06 GMT+09:00 Arnd Bergmann : > The recently added PTN3460 device driver uses interfaces that > are provided by the KMS helper infrastructure, so we should > explicitly select that to avoid this linker error: > > ERROR: "drm_helper_probe_single_connector_modes" >

[Bug 76564] [AMD Fusion E-350] HDMI refresh rates doesn't match expectations

did the test and attached a new log file that shows the pll information. -- 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/20

dma-buf and ->dev refcount fun

On Tue, Mar 25, 2014 at 7:40 PM, David Herrmann wrote: > Hi > > On Tue, Mar 25, 2014 at 9:01 AM, Daniel Vetter wrote: >> Besides the issue at hand though I think drivers need to make sure >> that the device they use for attaching does outlive the dma-buf. Which >> for real hotpluggin probably

another interesting lock recursion!

On Tue, Mar 25, 2014 at 6:24 PM, Daniel Vetter wrote: > On Tue, Mar 25, 2014 at 6:53 AM, Dave Airlie wrote: >> So with runtime pm on nouveau, if the card gets powered down, and then >> you access a connector via sysfs, >> >> drm_sysfs.c:status_show locks the connector and calls into the driver,

[PATCH v2 4/4] Documentation: drm: describing plane alpha and color blending property

From: Sagar Kamble v2: Added description for "src-color" and "constant-alpha" property. Cc: Rob Landley Cc: Dave Airlie Cc: Daniel Vetter Cc: Laurent Pinchart Cc: David Herrmann Cc: Alex Deucher Cc: "Ville Syrj?l?"

[PATCH v2 2/4] drm: Added plane alpha and color blending property

From: Sagar Kamble This patch creates a generic blending bitmask property modeled after glBlendFunc. Drivers may support subset of these values. v2: Removing blend properties that are not applicable [Damien's Review Comments]. Adding DRM_MODE_PROP_32BIT_PAIR

[PATCH v2 1/4] drm: Adding new flag to restrict bitmask drm properties as 32 bit type and 32 bit value pair

From: Sagar Kamble With this patch new flag DRM_MODE_PROP_32BIT_PAIR is added that will help make use of 64 bit value of bitmask property as two 32 bit values. Cc: airlied at linux.ie Cc: dri-devel at lists.freedesktop.org Cc: linux-kernel at vger.kernel.org

[Bug 76564] [AMD Fusion E-350] HDMI refresh rates doesn't match expectations

he display mode. See radeon_compute_pll_avivo() in radeon_display.c -- 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/20140325/e8a543

[Bug 76501] fences regression

: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140325/cf56cf69/attachment.html>

[Intel-gfx] [PATCH 1/3] drm/i915: Don't set mode_config's cursor size

On Tue, Mar 25, 2014 at 07:23:26PM +0100, Daniel Vetter wrote: > On Tue, Mar 25, 2014 at 04:57:04PM +, Damien Lespiau wrote: > > On Tue, Mar 25, 2014 at 04:38:24PM +, Chris Wilson wrote: > > > For the record, > > > > > > 16:30 < agd5f> ickle, our GPUs don't have selectable cursor sizes >

[Intel-gfx] [PATCH 1/3] drm/i915: Don't set mode_config's cursor size

On Tue, Mar 25, 2014 at 04:57:04PM +, Damien Lespiau wrote: > On Tue, Mar 25, 2014 at 04:38:24PM +, Chris Wilson wrote: > > For the record, > > > > 16:30 < agd5f> ickle, our GPUs don't have selectable cursor sizes > > 16:31 < agd5f> so on the newer ones, xf86-video-modesetting, etc. would

[Bug 76564] [AMD Fusion E-350] HDMI refresh rates doesn't match expectations

ause: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140325/ad84fb03/attachment.html>

[RFC] dma-buf: Implement test module

> > There are two things that don't work too well with this. First this > causes the build to break if the build machine doesn't have the new > public header (include/uapi/linux/dma-buf.h) installed yet. So the only > way to make this work would be by building the kernel once with SAMPLES >

[Intel-gfx] [PATCH 1/3] drm/i915: Don't set mode_config's cursor size

On Tue, Mar 25, 2014 at 07:23:26PM +0100, Daniel Vetter wrote: > Or we simply do this per-pixel format with one for each framebuffer plane, > i.e. > > struct drm_get_plane_fb_limits { > uint32_t plane_id; /* in */ > uint32_t fourcc; /* in */ > struct drm_plane_limits

3.14-rc7 crashes in drm ([PATCH] a crash in mga_driver_irq_uninstall)

On Mon, 24 Mar 2014, Daniel Vetter wrote: > >> Like I've said the entire teardown sequence for legacy drm drivers is > >> terminally busted, so the only hope we have is to reapply this missing > >> duct-tape which made your X crash. But if that itself isn't a regression > >> there's no way to

[Linaro-mm-sig] [PATCH] dma-buf: add meta data attachment

Hi all, On 2014? 03? 24? 16:35, Daniel Vetter wrote: > Hi all, > > Adding piles more people. > > For the first case of caching the iommu mapping there's different > answers, depening upon the exact case: > > 1) You need to fix your userspace to not constantly re-establish the sharing. > > 2)

[RFC] dma-buf: Implement test module

next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140325/319b0d46/attachment.sig>

[PATCH RFC v2 2/6] drm/i2c: tda998x: Move tda998x to a couple encoder/connector

On Mon, 24 Mar 2014 23:39:01 +0100 Laurent Pinchart wrote: > Hi Jean-Fran?ois, Hi Laurent, > Thank you for the patch. > > On Friday 21 March 2014 09:17:32 Jean-Francois Moine wrote: > > The 'slave encoder' structure of the tda998x driver asks for glue > > between the DRM driver and the

another interesting lock recursion!

So with runtime pm on nouveau, if the card gets powered down, and then you access a connector via sysfs, drm_sysfs.c:status_show locks the connector and calls into the driver, the driver then does a runtime_get_sync, which causes resume to happen which causes modesetting to reset the mode, which

exynos-drm HDMI PHY configuration values

Hi Sean, In your commit "drm/exynos: hdmi: support extra resolutions using drm_display_mode timings" you added several more HDMI PHY configs to exynos-drm. Thanks for that. Can you explain where these magic numbers came from? I'm interested in adding 85.5MHz for 1366x768 support. Thanks,

[PATCH 00/11] A few patches around DRM logging

2014-03-25 0:53 GMT+09:00 Damien Lespiau : > As patch 8/11 explains, I noticed that we where evaluating the arguments to > drm_ut_debug_printk() even when drm.debug was 0, doing some work for no good > reason. By pulling the test on drm_debug before calling drm_ut_debug_printk(), > we skip those

[PATCH] drm/ttm: remove fence_lock

Hey, op 21-03-14 14:04, Thomas Hellstrom schreef: > On 03/21/2014 01:12 PM, Maarten Lankhorst wrote: >> Hey, >> >> op 21-03-14 09:27, Thomas Hellstrom schreef: >>> On 03/21/2014 12:55 AM, Dave Airlie wrote: On Fri, Oct 19, 2012 at 3:04 AM, Jerome Glisse wrote: > On Thu, Oct 18,

[PATCH v2 2/3] drm/panel: add ld9040 driver

The patch adds LD9040 parallel RGB panel driver with SPI control interface. The driver uses drm_panel framework. Signed-off-by: Andrzej Hajda --- v2: removed useless include --- drivers/gpu/drm/panel/Kconfig| 6 + drivers/gpu/drm/panel/Makefile | 1 +

[Bug 75992] Display freezes & corruption with an r7 260x on 3.14-rc6

he bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140325/6b8907b7/attachment-0001.html>

[PATCH] drm/udl: take reference to device struct for dma-bufs

From: Dave Airlie this stops the device from being deleted before all the dma-bufs on it are freed, this fixes an oops when you unplug a udl device while it has imported a buffer from another device. Signed-off-by: Dave Airlie --- drivers/gpu/drm/udl/udl_gem.c | 11

[PATCH 16/16] drm/vmwgfx: Bump driver minor and date

/vmwgfx/vmwgfx_drv.h index 8c6b71f..6b252a8 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h @@ -40,9 +40,9 @@ #include #include "vmwgfx_fence.h" -#define VMWGFX_DRIVER_DATE "20140228" +#define VMWGFX_DRIVER_DATE "20140325"

[PATCH 15/16] drm/vmwgfx: Enable render nodes

Signed-off-by: Thomas Hellstrom Reviewed-by: Brian Paul --- drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 43 +-- 1 file changed, 21 insertions(+), 22 deletions(-) diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c index

[PATCH 14/16] drm/vmwgfx: Tighten the security around buffer maps

Make sure only buffer objects that are referenced by the client can be mapped. Signed-off-by: Thomas Hellstrom Reviewed-by: Brian Paul --- drivers/gpu/drm/vmwgfx/vmwgfx_resource.c |9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git

[PATCH 13/16] drm/ttm: Add a ttm_ref_object_exists function

A function to be used to check whether a caller has put a ref object (opened) a struct ttm_base_object Signed-off-by: Thomas Hellstrom Reviewed-by: Brian Paul --- drivers/gpu/drm/ttm/ttm_object.c | 46 ++ include/drm/ttm/ttm_object.h |4 2

[PATCH 12/16] drm/vmwgfx: Tighten security around surface sharing

If using legacy (non-prime) surface sharing, only allow surfaces to be shared between clients with the same master. This will block malicious clients from peeking at contents at surfaces from other (possibly vt-switched) masters. Signed-off-by: Thomas Hellstrom Reviewed-by: Brian Paul ---

[PATCH 11/16] drm/vmwgfx: Allow prime fds in the surface reference ioctls

Allow prime fds and at the same time block legacy handles for render-nodes in the surface reference ioctls. This means these ioctls can be used directly from prime-aware clients, and that they can be called from render-nodes. Signed-off-by: Thomas Hellstrom Reviewed-by: Brian Paul ---

[PATCH 10/16] drm/vmwgfx: Drop authentication requirement on UNREF ioctls

These ioctls will anyway only succeed if the client previously opened referenced the object. Furthermore, closing the client would implicitly execute the same action. This prevents clients from blocking on UNREF if their master dropped, and will allow masters to UNREF after dropping master

[PATCH 09/16] drm/vmwgfx: Reinstate and tighten security around legacy master model

The following restrictions affect clients connecting using legacy nodes: *) Masters that have dropped master privilieges are not considered authenticated until they regain master privileges. *) Clients whose master have dropped master privileges block interruptibly on ioctls requiring

[PATCH 08/16] drm/vmwgfx: Use a per-device semaphore for reservation protection

Don't use a per-master semaphore (ttm lock) for reservation protection, but rather a per-device semaphore. This is needed since clients connecting using render nodes aren't master aware. The ttm lock used should probably be replaced with a reader-write semaphore once the function

[PATCH 07/16] drm: Add a function to get the ioctl flags

Signed-off-by: Thomas Hellstrom Reviewed-by: Brian Paul --- drivers/gpu/drm/drm_drv.c | 18 ++ include/drm/drmP.h|1 + 2 files changed, 19 insertions(+) diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c index cf2dfb7..03711d0 100644 ---

[PATCH 06/16] drm: Protect the master management with a drm_device::master_mutex

The master management was previously protected by the drm_device::struct_mutex. In order to avoid locking order violations in a reworked dropped master security check in the vmwgfx driver, break it out into a separate master_mutex. Signed-off-by: Thomas Hellstrom Reviewed-by: Brian Paul ---

[PATCH 05/16] drm: Remove the minor master list

It doesn't appear to be used anywhere. Signed-off-by: Thomas Hellstrom Reviewed-by: David Herrmann --- drivers/gpu/drm/drm_stub.c |5 - include/drm/drmP.h |2 -- 2 files changed, 7 deletions(-) diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c index

[PATCH 04/16] drm: Improve on minor type helpers v2

Add a drm_is_legacy() helper, constify argument to drm_is_render_client(), and use / change helpers where appropriate. v2: s/drm_is_legacy/drm_is_legacy_client/ and adapt to new code context. Signed-off-by: Thomas Hellstrom Reviewed-by: Brian Paul --- drivers/gpu/drm/drm_crtc.c |4 ++--

[PATCH 03/16] drm: Make control nodes master-less v3

Like for render-nodes, there is no point in maintaining the master concept for control nodes, so set the struct drm_file::master pointer to NULL. At the same time, make sure DRM_MASTER | DRM_CONTROL_ALLOW ioctls are always allowed when called through the control node. Previously the caller also

[PATCH 02/16] drm: Break out ioctl permission check to a separate function v2

Helps reviewing and understanding these checks. v2: Remove misplaced newlines. Signed-off-by: Thomas Hellstrom Reviewed-by: David Herrmann --- drivers/gpu/drm/drm_drv.c | 113 ++--- 1 file changed, 75 insertions(+), 38 deletions(-) diff --git

[PATCH 01/16] drm: Have the crtc code only reference master from legacy nodes v2

control- and render nodes are intended to be master-less. v2: Replace tests for !legacy with tests for !mode_group for readability. Signed-off-by: Thomas Hellstrom Reviewed-by: David Herrmann --- drivers/gpu/drm/drm_crtc.c | 14 -- 1 file changed, 8 insertions(+), 6 deletions(-)

[PATCH 00/16] vmwgfx render-node support

Hi! Some of the patches are already reviewed on dri-devel, but included for completeness. Patch 6 and 7 are drm patches and in particular patch 6 might be good to have an extra pair of eyes on. Thanks, Thomas

dma-buf and ->dev refcount fun

So I've got a reproducable oops with udl sharing from i915, start X, connect UDL, randr it into position, rip out udl device, kill X, we get an oops when dma_unmap_sg in i915_gem_unmap_dma_buf gets called, attachment->dev is pointing to a freed structure, now the drm + udl driver points dev->dev

[PATCH] drm: Try to acquire modeset lock on panic or sysrq

On Tue, Mar 25, 2014 at 01:25:15PM +0100, Thierry Reding wrote: > From: Thierry Reding > > Commit 62ff94a54921 "drm/crtc-helper: remove LOCKING from kerneldoc" > causes drm_helper_crtc_in_use() and drm_helper_encoder_in_use() to > complain loudly during a kernel panic or sysrq processing. This

[DRM] drm_get_connector_name internal static string buffer causes a race

On Tue, Mar 25, 2014 at 11:23:46AM +, Dmitry Malkin wrote: > Hi, > will you accept bash scripts for reloading driver/X/FLR for intel-gpu-tools > to uncover exists and future bugs besides those patches? i-g-t/tests/drv_module_reload we have already, so basic coverage is there. It it's run in

[pull] radeon drm-next-3.15

Hi Dave, this is the third pull request for 3.15 radeon changes. Highlights this time: - More DP work from Alex, especially making use of the new DP aux helpers - Marek's 1D and linear tiling fixes for CIK The following changes since commit 63ac07cdee6e1f2bf748ac3f28662e3c01a72496:

[PATCH] drm: Try to acquire modeset lock on panic or sysrq

From: Thierry Reding Commit 62ff94a54921 "drm/crtc-helper: remove LOCKING from kerneldoc" causes drm_helper_crtc_in_use() and drm_helper_encoder_in_use() to complain loudly during a kernel panic or sysrq processing. This is caused by nobody acquiring the modeset lock in these

[PATCH 3/3] ARM: dts: exynos4210-universal_c210: add proper panel node

This patch replaces panel bindings for panel initialized by boot loader with bindings to proper ld9040 panel. Signed-off-by: Andrzej Hajda --- arch/arm/boot/dts/exynos4210-universal_c210.dts | 71 +++-- 1 file changed, 54 insertions(+), 17 deletions(-) diff --git

[PATCH 2/3] drm/panel: add ld9040 driver

The patch adds LD9040 parallel RGB panel driver with SPI control interface. The driver uses drm_panel framework. Signed-off-by: Andrzej Hajda --- drivers/gpu/drm/panel/Kconfig| 6 + drivers/gpu/drm/panel/Makefile | 1 + drivers/gpu/drm/panel/panel-ld9040.c | 377

[PATCH 1/3] panel/ld9040: add DT bindings

The patch adds bindings for ld9040 panel. Bindings describe panel resources, boot delays, display timings and physical size. Signed-off-by: Andrzej Hajda --- .../devicetree/bindings/panel/samsung,ld9040.txt | 66 ++ 1 file changed, 66 insertions(+) create mode 100644

[PATCH 0/3] DRM: Add LD9040 panel support

Hi, This patchset adds LD9040 panel support with DT bindings. It also adds support for this panel to Exynos4210-universal_c210 board. Regards Andrzej Andrzej Hajda (3): panel/ld9040: add DT bindings drm/panel: add ld9040 driver ARM: dts: exynos4210-universal_c210: add proper panel node

[Bug 75992] Display freezes & corruption with an r7 260x on 3.14-rc6

-- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140325/4f355a19/attachment.html>

[DRM] drm_get_connector_name internal static string buffer causes a race

On Mon, 24 Mar 2014, Daniel Vetter wrote: > On Mon, Mar 24, 2014 at 12:06:21PM +, Dmitry Malkin wrote: >> >> Hello guys, >> >> I've been playing with reloading intel gfx driver (i915) in a cycle, >> for a while, and at some point I've found a non-deterministic kernel >> crash with a

[PATCH 4/5] i915: Convert last uses of __FUNCTION__ to __func__

Just about all of these have been converted to __func__, so convert the last uses. Signed-off-by: Joe Perches --- drivers/gpu/drm/i915/dvo_ns2501.c | 15 ++- 1 file changed, 6 insertions(+), 9 deletions(-) diff --git a/drivers/gpu/drm/i915/dvo_ns2501.c

[PATCH 0/5] Convert last few uses of __FUNCTION__ to __func__

Outside of staging, there aren't any more uses of __FUNCTION__ now... Joe Perches (5): powerpc: Convert last uses of __FUNCTION__ to __func__ x86: Convert last uses of __FUNCTION__ to __func__ block: Convert last uses of __FUNCTION__ to __func__ i915: Convert last uses of __FUNCTION__ to

[PATCH] drm/bridge: PTN3460 needs DRM_KMS_HELPER

The recently added PTN3460 device driver uses interfaces that are provided by the KMS helper infrastructure, so we should explicitly select that to avoid this linker error: ERROR: "drm_helper_probe_single_connector_modes" [drivers/gpu/drm/bridge/ptn3460.ko] undefined! ERROR:

[PATCH v4] drm/i2c: tda998x: Deprecate "nxp,tda998x" in favour of "nxp,tda9989"

The tda998x driver accepts only 3 chips from the TDA998x family. To avoid confusion with the other TDA998x chips, this patch changes the driver compatible string to "nxp,tda9989". As the previous compatible string is not used in any DT, no compatibility is offered. Signed-off-by: Jean-Francois

dma-buf and ->dev refcount fun

On Tue, Mar 25, 2014 at 10:40:45AM +0100, David Herrmann wrote: > Hi > > On Tue, Mar 25, 2014 at 9:01 AM, Daniel Vetter wrote: > > Besides the issue at hand though I think drivers need to make sure > > that the device they use for attaching does outlive the dma-buf. Which > > for real hotpluggin

[Linaro-mm-sig] [PATCH] dma-buf: add meta data attachment

On Tue, Mar 25, 2014 at 06:21:34PM +0900, Seung-Woo Kim wrote: > Hi all, > > On 2014? 03? 24? 16:35, Daniel Vetter wrote: > > Hi all, > > > > Adding piles more people. > > > > For the first case of caching the iommu mapping there's different > > answers, depening upon the exact case: > > > > 1)

[PATCH 08/11] drm: Pull the test on drm_debug in the logging macros

On Mon, 24 Mar 2014, Damien Lespiau wrote: > In the logging code, we are currently checking is we need to output in s/is/if/ > drm_ut_debug_printk(). This is too late. The problem is that when we write > something like: > > DRM_DEBUG_DRIVER("ELD on [CONNECTOR:%d:%s], [ENCODER:%d:%s]\n", >

another interesting lock recursion!

On Tue, Mar 25, 2014 at 08:05:30PM +1000, Dave Airlie wrote: > On Tue, Mar 25, 2014 at 6:24 PM, Daniel Vetter wrote: > > On Tue, Mar 25, 2014 at 6:53 AM, Dave Airlie wrote: > >> So with runtime pm on nouveau, if the card gets powered down, and then > >> you access a connector via sysfs, > >> >

[PATCH 08/11] drm: Pull the test on drm_debug in the logging macros

On Tue, Mar 25, 2014 at 11:56:24AM +0200, Jani Nikula wrote: > On Mon, 24 Mar 2014, Damien Lespiau wrote: > > In the logging code, we are currently checking is we need to output in > > s/is/if/ > > > drm_ut_debug_printk(). This is too late. The problem is that when we write > > something like:

[DRM] drm_get_connector_name internal static string buffer causes a race

On Tue, Mar 25, 2014 at 08:08:23AM +, Dmitry Malkin wrote: > Hello, Daniel, > > Thank you for response. I've got a couple questions for you: > > 0. What do you think about making integration test with continuous reloading > i915 driver and X server (with FLR between iteration)? > Simplified

[RFCv3 08/14] drm: Replace crtc fb with primary plane fb (v2)

On Mon, Mar 24, 2014 at 06:20:35PM -0700, Matt Roper wrote: > On Wed, Mar 19, 2014 at 12:57:21PM +0100, Daniel Vetter wrote: > > On Tue, Mar 18, 2014 at 05:22:53PM -0700, Matt Roper wrote: > > > Now that CRTC's have a primary plane, there's no need to track the > > > framebuffer in the CRTC.

[DRM] drm_get_connector_name internal static string buffer causes a race

Hi, will you accept bash scripts for reloading driver/X/FLR for intel-gpu-tools to uncover exists and future bugs besides those patches? From: Daniel Vetter on behalf of Daniel Vetter Sent: Tuesday, March 25, 2014 2:43 PM To: Dmitry

[Bug 76501] fences regression

scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140325/032bfee1/attachment.html>

[Bug 76501] fences regression

that bug visibly. -- 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/20140325/5533cf2b/attachment.html>

[Bug 76501] fences regression

art -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140325/837b7223/attachment.html>

dma-buf and ->dev refcount fun

Hi On Tue, Mar 25, 2014 at 9:01 AM, Daniel Vetter wrote: > Besides the issue at hand though I think drivers need to make sure > that the device they use for attaching does outlive the dma-buf. Which > for real hotpluggin probably means that drivers need to drop all > attachment on unplug (the

[PATCH] nouveau: safen up nouveau_device list usage against concurrent access

Here's a test program I just whipped up that demonstrates (some of) the issues in the old code. This segfaults in either nouveau_bo_wrap or nouveau_bo_new, or sometimes nouveau_bo_wrap fails to find the handle. With the patch, it hasn't failed yet. Ben -- review please? (Or someone else...)

[PATCH 06/11] staging: imx-drm: Replace DRM_LOG_KMS() by DRM_DEBUG_KMS()

Am Montag, den 24.03.2014, 15:53 + schrieb Damien Lespiau: > There are only a few users of the DRM_LOG_KMS() macro. We can simplify > the DRM code a bit by replacing them by DRM_DEBUG_KMS(). > > Cc: Philipp Zabel > Cc: Lucas Stach > Signed-off-by: Damien Lespiau Acked-by: Philipp Zabel

3.14-rc7 crashes in drm ([PATCH] a crash in mga_driver_irq_uninstall)

On Tue, Mar 25, 2014 at 12:11 AM, Andreas Mohr wrote: > On Mon, Mar 24, 2014 at 10:46:49PM +0100, Daniel Vetter wrote: >> On Mon, Mar 24, 2014 at 9:40 PM, Mikulas Patocka >> wrote: >> > If someone understands the locking issues I pointed out above, it could be >> > easy to fix. >> >> The

dma-buf and ->dev refcount fun

On 03/25/2014 09:01 AM, Daniel Vetter wrote: > On Tue, Mar 25, 2014 at 4:53 AM, Dave Airlie wrote: >> So I've got a reproducable oops with udl sharing from i915, >> >> start X, connect UDL, randr it into position, rip out udl device, kill X, >> >> we get an oops when dma_unmap_sg in

another interesting lock recursion!

On Tue, Mar 25, 2014 at 6:53 AM, Dave Airlie wrote: > So with runtime pm on nouveau, if the card gets powered down, and then > you access a connector via sysfs, > > drm_sysfs.c:status_show locks the connector and calls into the driver, > the driver then does a runtime_get_sync, which causes

dma-buf and ->dev refcount fun

On Tue, Mar 25, 2014 at 4:53 AM, Dave Airlie wrote: > So I've got a reproducable oops with udl sharing from i915, > > start X, connect UDL, randr it into position, rip out udl device, kill X, > > we get an oops when dma_unmap_sg in i915_gem_unmap_dma_buf gets > called, attachment->dev is pointing

[DRM] drm_get_connector_name internal static string buffer causes a race

Hello, Daniel, Thank you for response. I've got a couple questions for you: 0. What do you think about making integration test with continuous reloading i915 driver and X server (with FLR between iteration)? Simplified example for ubuntu (root required): #!/bin/bash service lightdm stop rmmod

[PATCH 00/11] A few patches around DRM logging

g/imx-drm/ipuv3-plane.c | 2 +- > include/drm/drmP.h| 106 > +++--- > 11 files changed, 98 insertions(+), 136 deletions(-) > > -- > 1.8.3.1 > > -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140325/3ad2b851/attachment.html>

[Bug 66731] ACPI + kworker high CPU usage

https://bugzilla.kernel.org/show_bug.cgi?id=66731 Eric Blackwell changed: What|Removed |Added Component|Video(DRI - non Intel) |Other Product|Drivers

[Bug 76577] egl_dri2.c:507:27: error: 'EGL_OPENGL_ES3_BIT_KHR' undeclared (first use in this function)

. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140325/c08010ff/attachment.html>

[Bug 76577] egl_dri2.c:507:27: error: 'EGL_OPENGL_ES3_BIT_KHR' undeclared (first use in this function)

vel/attachments/20140325/18a5eede/attachment-0001.html>

[Bug 76577] New: egl_dri2.c:507:27: error: 'EGL_OPENGL_ES3_BIT_KHR' undeclared (first use in this function)

for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140325/51919ef9/attachment.html>

[PATCH 12/12] drm/nouveau: support for probing GK20A

we? If so the commit message in 11/12 is misleading. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140

3.14-rc7 crashes in drm ([PATCH] a crash in mga_driver_irq_uninstall)

Hi, On Mon, Mar 24, 2014 at 10:46:49PM +0100, Daniel Vetter wrote: > On Mon, Mar 24, 2014 at 9:40 PM, Mikulas Patocka > wrote: > > If someone understands the locking issues I pointed out above, it could be > > easy to fix. > > The locking issue isn't your problem, the real issue is that

[PATCH 11/12] drm/nouveau: support GK20A in nouveau_accel_init()

s any display hardware". In that case the comment here doesn't make much sense. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140325/1f743847/attachment.sig>

[PATCH 09/12] drm/nouveau/graph: pad firmware code at load time

. Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140325/589a12af/attachment.sig>

[PATCH 08/12] drm/nouveau/graph: enable when using external firmware

On Mon, Mar 24, 2014 at 05:42:30PM +0900, Alexandre Courbot wrote: [...] > diff --git a/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c > b/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c > index 6ef8bf181b2d..f997a18f5760 100644 > --- a/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c > +++

[PATCH RFC v2 2/6] drm/i2c: tda998x: Move tda998x to a couple encoder/connector

Hi Jean-Fran?ois, Thank you for the patch. On Friday 21 March 2014 09:17:32 Jean-Francois Moine wrote: > The 'slave encoder' structure of the tda998x driver asks for glue > between the DRM driver and the encoder/connector structures. > > This patch changes the driver to a normal DRM

[PATCH 06/12] drm/nouveau/ibus: add GK20A support

On Mon, Mar 24, 2014 at 05:42:28PM +0900, Alexandre Courbot wrote: [...] > diff --git a/drivers/gpu/drm/nouveau/core/subdev/ibus/nvea.c > b/drivers/gpu/drm/nouveau/core/subdev/ibus/nvea.c [...] > +#include > + > +struct nvea_ibus_priv { > + struct nouveau_ibus base; > +}; > + > +static void

[PATCH 05/12] drm/nouveau/fifo: add GK20A support

On Mon, Mar 24, 2014 at 05:42:27PM +0900, Alexandre Courbot wrote: > GK20A's FIFO is compatible with NVE0, but only features 128 channels and > 1 runlist. > > Signed-off-by: Alexandre Courbot > --- > drivers/gpu/drm/nouveau/Makefile | 1 + >

[PATCH 03/12] drm/nouveau/bar: only ioremap BAR3 if it exists

On Mon, Mar 24, 2014 at 05:42:25PM +0900, Alexandre Courbot wrote: > Some chips that use system memory exclusively (e.g. GK20A) do not > expose 2 BAR regions. For them only BAR1 exists, and it should be used > for USERD mapping. Do not map BAR3 if its resource does not exist. > > Signed-off-by:

[PATCH 04/12] drm/nouveau/bar/nvc0: support chips without BAR3

On Mon, Mar 24, 2014 at 05:42:26PM +0900, Alexandre Courbot wrote: [...] > diff --git a/drivers/gpu/drm/nouveau/core/subdev/bar/nvc0.c > b/drivers/gpu/drm/nouveau/core/subdev/bar/nvc0.c [...] > static int > -nvc0_bar_ctor(struct nouveau_object *parent, struct nouveau_object *engine, > -