[PATCH 2/2] drm/i915: use drm_mm_remove_node instead of put_block

On Mon, Jul 1, 2013 at 10:46 PM, Ben Widawsky wrote: >> > drm_mm_remove_node() does unlink the node but not remove it. Btw., I >> > have these fixes in my series, too. I will push it later and write the >> > git-link to #dri-devel. >> >> We have patches in-flight to convert over to embedded

MacBook Pro 10,1 + i915

Hi guys, I recently got the rMBP 10,1 model, it has two graphic cards: 00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09) 01:00.0 VGA compatible controller: NVIDIA Corporation GK107M [GeForce GT 650M Mac Edition] (rev a1) I'm running linux

[PATCH 2/2] drm/i915: use drm_mm_remove_node instead of put_block

On Mon, Jul 01, 2013 at 10:21:57PM +0200, David Herrmann wrote: > Hi > > On Mon, Jul 1, 2013 at 10:05 PM, Daniel Vetter > wrote: > > When converting to the preallocated drm_mm_node interfaces in > > > > commit dc9dd7a20fde95aa81a8307cde79c2dff9f83f3d > > Author: Chris Wilson > > Date: Fri

[PATCH] drm/i915: Don't try to tear down the stolen drm_mm if it's not there

Every other place properly checks whether we've managed to set up the stolen allocator at boot-up properly, with the exception of the cleanup code. Which results in an ugly *ERROR* Memory manager not clean. Delaying takedown at module unload time since the drm_mm isn't initialized at all. v2:

[PATCH 2/2] drm/i915: use drm_mm_remove_node instead of put_block

On Mon, Jul 01, 2013 at 09:16:56PM +0100, Chris Wilson wrote: > On Mon, Jul 01, 2013 at 10:05:54PM +0200, Daniel Vetter wrote: > > When converting to the preallocated drm_mm_node interfaces in > > > > commit dc9dd7a20fde95aa81a8307cde79c2dff9f83f3d > > Author: Chris Wilson > > Date: Fri Dec 7

[PATCH 2/2] drm/i915: use drm_mm_remove_node instead of put_block

Hi On Mon, Jul 1, 2013 at 10:05 PM, Daniel Vetter wrote: > When converting to the preallocated drm_mm_node interfaces in > > commit dc9dd7a20fde95aa81a8307cde79c2dff9f83f3d > Author: Chris Wilson > Date: Fri Dec 7 20:37:07 2012 + > > drm/i915: Preallocate the drm_mm_node prior to

[PATCH 3/6] drm: add unified vma offset manager

On Mon, Jul 01, 2013 at 09:54:17PM +0200, David Herrmann wrote: > On Mon, Jul 1, 2013 at 9:42 PM, Daniel Vetter wrote: > > On Mon, Jul 01, 2013 at 08:33:00PM +0200, David Herrmann wrote: > >> +/** drm_vma_offset_manager_destroy() > >> + * > >> + * Destroy an object manager which was previously

[PATCH 2/2] drm/i915: use drm_mm_remove_node instead of put_block

When converting to the preallocated drm_mm_node interfaces in commit dc9dd7a20fde95aa81a8307cde79c2dff9f83f3d Author: Chris Wilson Date: Fri Dec 7 20:37:07 2012 + drm/i915: Preallocate the drm_mm_node prior to manipulating the GTT drm_mm only the allocation side was converted, but

[PATCH 1/2] drm/mm: kill color_search_free/get_block

drm/i915 is the only user of the color allocation handling and switched to insert_node a while ago. So we can ditch this. Signed-off-by: Daniel Vetter --- include/drm/drm_mm.h | 31 --- 1 file changed, 31 deletions(-) diff --git a/include/drm/drm_mm.h

[pull] radeon drm-next-3.11

> -Original Message- > From: Markus Trippelsdorf [mailto:markus at trippelsdorf.de] > Sent: Monday, July 01, 2013 5:58 PM > To: alexdeucher at gmail.com > Cc: dri-devel at lists.freedesktop.org; airlied at gmail.com; Deucher, > Alexander > Subject: Re: [pull] radeon drm-next-3.11 > > On

[PATCH 3/3] drm/mm: WARN for unclean mm takedown

The usual drm driver has tons of different drm_mm memory managers so the drm error message in dmesg is pretty useless. WARN instead so that we have the full backtrace. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_mm.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

[PATCH 2/3] drm/i915: Don't try to tear down the stolen drm_mm if it's not there

Every other place properly checks whether we've managed to set up the stolen allocator at boot-up properly, with the exception of the cleanup code. Which results in an ugly *ERROR* Memory manager not clean. Delaying takedown at module unload time since the drm_mm isn't initialized at all. v2:

[PATCH 1/3] drm/mm: fix debug table BUG

In commit 3a359f0b21ab218c1bf7a6a1b638b6fd143d0b99 Author: Daniel Vetter Date: Sat Apr 20 12:08:11 2013 +0200 drm/mm: fix dump table BUG I've failed to fix both instances of the regression introduced in commit 9e8944ab564f2e3dde90a518cd32048c58918608 Author: Chris Wilson Date: Thu

[Bug 66473] New: hdmi oops with mem sleep

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

[PATCH 3/6] drm: add unified vma offset manager

Hi On Mon, Jul 1, 2013 at 9:42 PM, Daniel Vetter wrote: > On Mon, Jul 01, 2013 at 08:33:00PM +0200, David Herrmann wrote: >> If we want to map GPU memory into user-space, we need to linearize the >> addresses to not confuse mm-core. Currently, GEM and TTM both implement >> their own

[PATCH 0/6] DRM: Unified VMA Offset Manager

On Mon, Jul 01, 2013 at 08:32:57PM +0200, David Herrmann wrote: > Hi > > I picked up the initial work from Dave [1], fixed several bugs, rewrote the > drm_mm node handling and adjusted the different drivers. > The series tries to replace the VMA-offset managers from GEM and TTM with a > single

[PATCH 6/6] drm: provide generic drm_vma_node_unmap() helper

On Mon, Jul 01, 2013 at 08:33:03PM +0200, David Herrmann wrote: > Instead of unmapping the nodes in TTM and GEM users manually, we provide > a generic wrapper which does the correct thing for all vma-nodes. > > Signed-off-by: David Herrmann Nice. One nitpick below, otherwise: Reviewed-by:

[PATCH 3/6] drm: add unified vma offset manager

On Mon, Jul 01, 2013 at 08:33:00PM +0200, David Herrmann wrote: > If we want to map GPU memory into user-space, we need to linearize the > addresses to not confuse mm-core. Currently, GEM and TTM both implement > their own offset-managers to assign a pgoff to each object for user-space > CPU

[Bug 66425] "failed testing IB on ring 5" when suspending to disk

ted to this and it doesn't appear in the 3.9 kernels. -- 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/20130701/a84a225c/attachment.html>

[PATCH 2/6] drm: mm: add drm_mm_node_linked() helper

On Mon, Jul 01, 2013 at 08:32:59PM +0200, David Herrmann wrote: > This helper tests whether a given node is currently linked into a drm_mm > manager. We use the node->mm pointer for that as it is set for all linked > objects. > > We also reset node->mm whenever a node is removed. All such access

[PATCH 1/6] drm: make drm_mm_init() return void

On Mon, Jul 01, 2013 at 08:32:58PM +0200, David Herrmann wrote: > There is no reason to return "int" as this function never fails. > Furthermore, several drivers (ast, sis) already depend on this. > > Signed-off-by: David Herrmann Back when I've reworked drm_mm I was still a rookie and didn't

[PATCH 1/2] drm/mm: kill color_search_free/get_block

On Mon, Jul 01, 2013 at 10:05:53PM +0200, Daniel Vetter wrote: > drm/i915 is the only user of the color allocation handling and > switched to insert_node a while ago. So we can ditch this. > > Signed-off-by: Daniel Vetter If you build it, they will come. Lies! Reviewed-by: Chris Wilson -Chris

[PATCH 2/2] drm/i915: use drm_mm_remove_node instead of put_block

On Mon, Jul 01, 2013 at 10:05:54PM +0200, Daniel Vetter wrote: > When converting to the preallocated drm_mm_node interfaces in > > commit dc9dd7a20fde95aa81a8307cde79c2dff9f83f3d > Author: Chris Wilson > Date: Fri Dec 7 20:37:07 2012 + > > drm/i915: Preallocate the drm_mm_node prior

[PATCH 2/3] drm/i915: Don't try to tear down the stolen drm_mm if it's not there

On Mon, Jul 01, 2013 at 10:01:03PM +0200, Daniel Vetter wrote: > Every other place properly checks whether we've managed to set > up the stolen allocator at boot-up properly, with the exception > of the cleanup code. Which results in an ugly > > *ERROR* Memory manager not clean. Delaying takedown

[PATCH v2 3/3] drm: fix error routines in drm_open_helper

> Chris Wilson, Intel Open Source Technology Centre > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130701/ac7b09d9/attachment.html>

[PATCH 6/6] drm: provide generic drm_vma_node_unmap() helper

Instead of unmapping the nodes in TTM and GEM users manually, we provide a generic wrapper which does the correct thing for all vma-nodes. Signed-off-by: David Herrmann --- drivers/gpu/drm/i915/i915_gem.c | 6 +- drivers/gpu/drm/ttm/ttm_bo.c| 8 +--- include/drm/drm_vma_manager.h

[PATCH 5/6] drm: ttm: convert to unified vma offset manager

Use the new vma-manager infrastructure. This doesn't change any implementation details as the vma-offset-manager is nearly copied 1-to-1 from TTM. Even though the vma-manager uses its own locks, we still need bo->vm_lock to prevent bos from being destroyed before we can get a reference during

[PATCH 4/6] drm: gem: convert to new unified vma manager

Use the new vma manager instead of the old hashtable. Also convert all drivers to use the new convenience helpers. This drops all the (map_list.hash.key << PAGE_SHIFT) non-sense. Locking and access-management is exactly the same as before with an additional lock inside of the vma-manager, which

[PATCH 3/6] drm: add unified vma offset manager

If we want to map GPU memory into user-space, we need to linearize the addresses to not confuse mm-core. Currently, GEM and TTM both implement their own offset-managers to assign a pgoff to each object for user-space CPU access. GEM uses a hash-table, TTM uses an rbtree. This patch provides a

[PATCH 2/6] drm: mm: add drm_mm_node_linked() helper

This helper tests whether a given node is currently linked into a drm_mm manager. We use the node->mm pointer for that as it is set for all linked objects. We also reset node->mm whenever a node is removed. All such access is currently safe as everyone calls kfree() on the object directly after

[PATCH 1/6] drm: make drm_mm_init() return void

There is no reason to return "int" as this function never fails. Furthermore, several drivers (ast, sis) already depend on this. Signed-off-by: David Herrmann --- drivers/gpu/drm/drm_gem.c| 8 ++-- drivers/gpu/drm/drm_mm.c | 4 +--- drivers/gpu/drm/ttm/ttm_bo.c

[PATCH 0/6] DRM: Unified VMA Offset Manager

Hi I picked up the initial work from Dave [1], fixed several bugs, rewrote the drm_mm node handling and adjusted the different drivers. The series tries to replace the VMA-offset managers from GEM and TTM with a single unified implementation. It uses the TTM RBTree idea to allow sub-mappings

[PATCH v2 3/3] drm: fix error routines in drm_open_helper

Hello Chris, On 2013? 07? 01? 19:57, Chris Wilson wrote: > On Mon, Jul 01, 2013 at 07:49:10PM +0900, Seung-Woo Kim wrote: >> + >> +out_close: >> +if (dev->driver->postclose) >> +dev->driver->postclose(dev, priv); >> +out_free: >> kfree(priv); >> filp->private_data =

[Intel-gfx] [PATCH 3/3] drm/mm: WARN for unclean mm takedown

On Mon, 1 Jul 2013 22:01:04 +0200 Daniel Vetter wrote: > The usual drm driver has tons of different drm_mm memory managers so > the drm error message in dmesg is pretty useless. WARN instead so > that we have the full backtrace. > > Signed-off-by: Daniel Vetter I've written this patch myself

armada_drm clock selection - try 2

On Mon, Jul 1, 2013 at 3:48 PM, Sebastian Hesselbarth wrote: > I guess "extclk0" and "extclk1" should be sufficient for clock names. > Also, they are not dedicated as you can have CRTC0 and CRTC1 use e.g. > extclk0 simultaneously. See below for .is_dedicated in general. Maybe we can find better

[PATCH v2 3/3] drm: fix error routines in drm_open_helper

From: YoungJun Cho There are wrong cases to handle error in drm_open_helper(). The priv->minor, assigned by idr_find() which can return NULL, should be checked whether it is NULL or not before referencing it. And if an error occurs after executing dev->driver->open() which

[PATCH v2 1/3] drm: fix print format of sequence in trace point

seq of a trace point is unsigned int but print format was %d. So it fixes the format as %u. Signed-off-by: Seung-Woo Kim Signed-off-by: Kyungmin Park --- change from v1 - remove wrong commit messageas Chris commented drivers/gpu/drm/drm_trace.h |6 +++--- 1 files changed, 3 insertions(+),

[patch] drm/radeon: forever loop on error in radeon_do_test_moves()

The error path does this: for (--i; i >= 0; --i) { which is a forever loop because "i" is unsigned. Signed-off-by: Dan Carpenter diff --git a/drivers/gpu/drm/radeon/radeon_test.c b/drivers/gpu/drm/radeon/radeon_test.c index f4d6bce..12e8099 100644 ---

[patch -next] drm/radeon/dpm/btc: off by one in btc_set_mc_special_registers()

It should be ">=" instead of ">" here. The table->mc_reg_address[] array has SMC_EVERGREEN_MC_REGISTER_ARRAY_SIZE (16) elements. Signed-off-by: Dan Carpenter diff --git a/drivers/gpu/drm/radeon/btc_dpm.c b/drivers/gpu/drm/radeon/btc_dpm.c index bab0185..55491e7 100644 ---

[PATCH RFC 1/3] DRM: Armada: Add Armada DRM driver

On Mon, Jul 1, 2013 at 5:26 PM, Dave Airlie wrote: >> Of course, I share the idea of true, full-blown of_drm_something >> helpers. But the DT patch, is not an improvement but a real fix as in >> "make DRM not break on some platforms". From that on, I can start >> digging into DRM API and improve

[PATCH 1/3] drm: fix print format of sequence in trace point

Hello Chris, Thank you for reviewing. On 2013? 07? 01? 19:23, Chris Wilson wrote: > On Mon, Jul 01, 2013 at 07:06:31PM +0900, Seung-Woo Kim wrote: >> seq of a trace point is unsigned int but print format was %d. So >> it fixes the format as %u even the format can be not used. > > I don't

[PATCH 3/3] drm: fix error routines in drm_open_helper

From: YoungJun Cho There are wrong cases to handle error in drm_open_helper(). The priv->minor, assigned by idr_find() which can return NULL, should be checked whether it is NULL or not before referencing it. And if an error occurs after executing dev->driver->open() which

[PATCH 2/3] drm: move edid null check to the first part of drm_edid_block_valid

If raw_edid is null, it will crash, so checking in bad label is meaningless. Signed-off-by: Seung-Woo Kim Signed-off-by: Kyungmin Park --- drivers/gpu/drm/drm_edid.c |5 - 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/drm_edid.c

[PATCH 1/3] drm: fix print format of sequence in trace point

seq of a trace point is unsigned int but print format was %d. So it fixes the format as %u even the format can be not used. Signed-off-by: Seung-Woo Kim Signed-off-by: Kyungmin Park --- drivers/gpu/drm/drm_trace.h |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git

[PATCH 0/3] drm: minor cleanups

This patch series fixes minor code issues including wrong trace point foramts, meaningless null checking, and possible resource leak in error cases. This is based drm-next branch. Seung-Woo Kim (2): drm: fix print format of sequence in trace point drm: move edid null check to the first part

[Bug 65310] [regression] failure in building nvc0_vbo.lo: /tmp/cclDjdRp.s:1270: Error: missing or invalid displacement expression `-8589934576

-- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130701/00ac8086/attachment.html>

[PATCH RFC 1/3] DRM: Armada: Add Armada DRM driver

On Mon, Jul 1, 2013 at 4:52 AM, Sebastian Hesselbarth wrote: > On 07/01/13 02:01, Dave Airlie wrote: >> >> how about instead of writing: >> "However, at least I've taken the time to_think_ about what I'm doing >> and realise that there_is_ scope here for the DRM core to improve, >> >> rather

[pull] radeon drm-next-3.11

From: Alex Deucher Hi Dave, A few more patches for 3.11: - add debugfs interface to check current DPM state - Fix a bug that caused problems with DPM on BTC+ asics. The following changes since commit f7d452f4fd5d86f764807a1234a407deb5b105ef: Merge branch

[PATCH] drm/exynos: add error check routine in exynos_drm_open

From: YoungJun Cho When the exynos_drm_subdrv_open() returns error, the file_priv should be released and file->driver_priv set to NULL. Signed-off-by: YoungJun Cho Signed-off-by: Kyungmin Park --- drivers/gpu/drm/exynos/exynos_drm_drv.c |9 - 1 file changed,

[PATCH 2/3] drm: move edid null check to the first part of drm_edid_block_valid

On Mon, Jul 1, 2013 at 12:21 PM, Chris Wilson wrote: > On Mon, Jul 01, 2013 at 07:06:32PM +0900, Seung-Woo Kim wrote: >> If raw_edid is null, it will crash, so checking in bad label is >> meaningless. > > It would be an error on part of the caller, but the defense looks sane. > As the function

[PATCH 02/24] drm/rcar-du: Use devm_ioremap_resource()

Hi Sergei, On Thursday 27 June 2013 17:04:45 Sergei Shtylyov wrote: > On 27-06-2013 13:49, Laurent Pinchart wrote: > > Replace the devm_request_mem_region() and devm_ioremap_nocache() calls > > with devm_ioremap_resource(). > > > > Signed-off-by: Laurent Pinchart > >

armada_drm clock selection - try 2

Hi Russell, Here is a new patch which should incorporate all your previous feedback. Now each variant passes clock info to the main driver via a new armada_clk_info structure. A helper function in the core lets each variant find the best clock. As you suggested we first try external

[PATCH] drm: Convert drm class driver from legacy pm ops to dev_pm_ops

Convert drivers/gpu/drm class to use dev_pm_ops for power management and remove Legacy PM ops hooks. With this change, drm class registers suspend/resume callbacks via class->pm (dev_pm_ops) instead of Legacy class->suspend/resume. When __device_suspend() runs call-backs, it will find class->pm

[Bug 57875] Second Life viewer bad rendering with git-ec83535

ttp://lists.freedesktop.org/archives/dri-devel/attachments/20130701/12346430/attachment.html>

[Bug 63520] r300g regression (RV380): Strange rendering of light sources in Penumbra (bisected)

ttp://lists.freedesktop.org/archives/dri-devel/attachments/20130701/2f3658f8/attachment.html>

[PATCH 0/6] DRM: Unified VMA Offset Manager

On Mon, Jul 1, 2013 at 2:32 PM, David Herrmann wrote: > Hi > > I picked up the initial work from Dave [1], fixed several bugs, rewrote the > drm_mm node handling and adjusted the different drivers. > The series tries to replace the VMA-offset managers from GEM and TTM with a > single unified

[PATCH] drm/qxl: make dynamic resizing work properly.

From: Dave Airlie qxl has a feature to allow the userspace driver do arbitrary resizes when the viewer resizes, this fixes it by removing unnecessary code from the kernel side. Signed-off-by: Dave Airlie --- drivers/gpu/drm/qxl/qxl_display.c | 58

[PATCH] drm/exynos: Add missing includes

From: Mark Brown Ensure that all externally accessed functions are correctly prototyped when defined in each file by making sure the headers with the protoypes are included in the file with the definition. Signed-off-by: Mark Brown ---

[PATCH 2/2] drm/i915: use drm_mm_remove_node instead of put_block

On Mon, Jul 01, 2013 at 10:39:03PM +0200, Daniel Vetter wrote: > On Mon, Jul 01, 2013 at 10:21:57PM +0200, David Herrmann wrote: > > Hi > > > > On Mon, Jul 1, 2013 at 10:05 PM, Daniel Vetter > > wrote: > > > When converting to the preallocated drm_mm_node interfaces in > > > > > > commit

[Bug 66425] "failed testing IB on ring 5" when suspending to disk

org/archives/dri-devel/attachments/20130701/f6c72282/attachment.html>

[PATCH 2/2] drm/exynos: initialize the buf_num in vp_video_buffer

From: YoungJun Cho The buf_num in vp_video_buffer() should be 1 or 2, but it is not initialized, and only set to 2 in NV12M or NV12MT cases. So this patch initializes the buf_num with 1 as default. Signed-off-by: YoungJun Cho Signed-off-by: Seung-Woo Kim Signed-off-by:

[PATCH 1/2] drm/exynos: remove dead code in vidi_power_on

From: YoungJun Cho The type of input parameter enable is bool, so it does not need to check whether true or false. Signed-off-by: YoungJun Cho Signed-off-by: Kyungmin Park --- drivers/gpu/drm/exynos/exynos_drm_vidi.c |3 --- 1 file changed, 3 deletions(-) diff

[PATCH v2 3/3] drm: fix error routines in drm_open_helper

On Mon, Jul 01, 2013 at 08:14:42PM +0900, Seung-Woo Kim wrote: > Hello Chris, > > On 2013? 07? 01? 19:57, Chris Wilson wrote: > > On Mon, Jul 01, 2013 at 07:49:10PM +0900, Seung-Woo Kim wrote: > >> + > >> +out_close: > >> + if (dev->driver->postclose) > >> + dev->driver->postclose(dev,

[PATCH RFC 1/3] DRM: Armada: Add Armada DRM driver

On 07/01/13 11:42, Daniel Vetter wrote: > On Mon, Jul 01, 2013 at 10:52:03AM +0200, Sebastian Hesselbarth wrote: >> at least on this point I do share Russell's impression. I've sent >> bunch of patches improving TDA998x and DRM+DT: >> - TDA998x irq handling - ignored >> - TDA998x sync fix -

[Bug 63520] r300g regression (RV380): Strange rendering of light sources in Penumbra (bisected)

attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130701/5d0e1668/attachment.html>

[PATCH] drm/nouveau: fix locking in nouveau_crtc_page_flip

This is a bit messed up because chan->cli->mutex is a different class, depending on whether it is the global drm client or not. This is because the global cli->mutex lock can be taken for eviction, so locking it before pinning the buffer objects may result in a deadlock. The locking order from

[PATCH v2 3/3] drm: fix error routines in drm_open_helper

On Mon, Jul 01, 2013 at 07:49:10PM +0900, Seung-Woo Kim wrote: > + > +out_close: > + if (dev->driver->postclose) > + dev->driver->postclose(dev, priv); > +out_free: > kfree(priv); > filp->private_data = NULL; > return ret; Looks like we are also missing: if

[PATCH]

[Bug 66452] New: JUNIPER UVD accelerated playback of WMV3 streams does not work

org/archives/dri-devel/attachments/20130701/a9ba1f26/attachment.html>

[PATCH v2 1/3] drm: fix print format of sequence in trace point

On Mon, Jul 01, 2013 at 07:44:14PM +0900, Seung-Woo Kim wrote: > seq of a trace point is unsigned int but print format was %d. So > it fixes the format as %u. > > Signed-off-by: Seung-Woo Kim > Signed-off-by: Kyungmin Park Reviewed-by: Chris Wilson -Chris -- Chris Wilson, Intel Open Source

[PATCH RFC 1/3] DRM: Armada: Add Armada DRM driver

On Mon, Jul 01, 2013 at 10:52:03AM +0200, Sebastian Hesselbarth wrote: > On 07/01/13 02:01, Dave Airlie wrote: > >how about instead of writing: > >"However, at least I've taken the time to_think_ about what I'm doing > >and realise that there_is_ scope here for the DRM core to improve, > >rather

[PATCH 1/3] drm: fix print format of sequence in trace point

On Mon, Jul 01, 2013 at 07:28:49PM +0900, Seung-Woo Kim wrote: > Hello Chris, > > Thank you for reviewing. > > On 2013? 07? 01? 19:23, Chris Wilson wrote: > > On Mon, Jul 01, 2013 at 07:06:31PM +0900, Seung-Woo Kim wrote: > >> seq of a trace point is unsigned int but print format was %d. So > >>

[Bug 66450] New: JUNIPER UVD accelerated playback of MPEG 1/2 streams does not work

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/20130701/ae5ef02c/attachment.html>

[PATCH 1/3] drm: fix print format of sequence in trace point

On Mon, Jul 01, 2013 at 07:06:31PM +0900, Seung-Woo Kim wrote: > seq of a trace point is unsigned int but print format was %d. So > it fixes the format as %u even the format can be not used. I don't understand what you mean here. The patch itself looks fine. > Signed-off-by: Seung-Woo Kim >

[PATCH 2/3] drm: move edid null check to the first part of drm_edid_block_valid

On Mon, Jul 01, 2013 at 07:06:32PM +0900, Seung-Woo Kim wrote: > If raw_edid is null, it will crash, so checking in bad label is > meaningless. It would be an error on part of the caller, but the defense looks sane. As the function is a bool, I would have preferred it returned true/false, but

[PATCH 3/3] drm: fix error routines in drm_open_helper

On Mon, Jul 01, 2013 at 07:06:33PM +0900, Seung-Woo Kim wrote: > From: YoungJun Cho > > There are wrong cases to handle error in drm_open_helper(). > The priv->minor, assigned by idr_find() which can return NULL, > should be checked whether it is NULL or not before referencing it. > And if an

[PATCH] drm/exynos: fix not to remain exynos_gem_obj as a leak

From: YoungJun Cho The exynos_drm_gem_create() only calls drm_gem_object_release() when exynos_drm_alloc_buf() is failed, and exynos_gem_obj remains as a leak, which is allocated in exynos_drm_gem_init(). So this patch fixes it not to remain as a leak. Signed-off-by:

linux-next: Tree for Jul 1 [ drm-intel-next: Several call-traces ]

On Mon, Jul 1, 2013 at 10:52 AM, Daniel Vetter wrote: > On Mon, Jul 1, 2013 at 10:49 AM, Sedat Dilek wrote: >> On Mon, Jul 1, 2013 at 9:59 AM, Stephen Rothwell >> wrote: >>> Hi all, >>> >>> Changes since 20130628: >>> >>> The regulator tree gained a build failure so I used the version from

linux-next: Tree for Jul 1 [ drm-intel-next: Several call-traces ]

On Mon, Jul 1, 2013 at 10:49 AM, Sedat Dilek wrote: > On Mon, Jul 1, 2013 at 9:59 AM, Stephen Rothwell > wrote: >> Hi all, >> >> Changes since 20130628: >> >> The regulator tree gained a build failure so I used the version from >> next-20130628. >> >> The trivial tree gained a conflict against

[PATCH RFC 1/3] DRM: Armada: Add Armada DRM driver

On 07/01/13 02:01, Dave Airlie wrote: > how about instead of writing: > "However, at least I've taken the time to_think_ about what I'm doing > and realise that there_is_ scope here for the DRM core to improve, > rather than burying this stuff deep inside my driver like everyone else > has.

linux-next: Tree for Jul 1 [ drm-intel-next: Several call-traces ]

On Mon, Jul 1, 2013 at 9:59 AM, Stephen Rothwell wrote: > Hi all, > > Changes since 20130628: > > The regulator tree gained a build failure so I used the version from > next-20130628. > > The trivial tree gained a conflict against the fbdev tree. > > The arm-soc tree gained a conflict against

[PATCH RFC 1/3] DRM: Armada: Add Armada DRM driver

On Mon, Jul 1, 2013 at 10:17 AM, Russell King - ARM Linux wrote: > On Mon, Jul 01, 2013 at 10:01:30AM +1000, Dave Airlie wrote: >> OMG I'm working in a subsystem where stuff is being developed, with only >> a few resources! I know my full time job isn't maintaining a 500,000 >> line subsystem, >>

[PATCH RFC 1/3] DRM: Armada: Add Armada DRM driver

On Sun, Jun 30, 2013 at 10:52 PM, Russell King - ARM Linux wrote: > On Sun, Jun 30, 2013 at 01:59:41PM +0200, Daniel Vetter wrote: >> On Sat, Jun 29, 2013 at 11:53:22PM +0100, Russell King wrote: >> > +static uint32_t armada_drm_crtc_calculate_csc(struct armada_crtc *dcrtc) >> > +{ >> > +

[RFC 2/6] x86: provide platform-devices for boot-framebuffers

On 06/28/2013 04:11 AM, David Herrmann wrote: > Hi > > On Wed, Jun 26, 2013 at 10:49 PM, Stephen Warren > wrote: >> On 06/24/2013 04:27 PM, David Herrmann wrote: >>> The current situation regarding boot-framebuffers (VGA, VESA/VBE, EFI) on >>> x86 causes troubles when loading multiple fbdev

[Bug 66337] evergreen_compute.c:559:26: error: 'kernel' undeclared (first use in this function) shader->active_kernel = kernel;

when opencl is disabled. -- 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/20130701/75020fd5/attachment.html>

unsubscribe

to or from this e-mail address may be stored on the Infosys e-mail system. ***INFOSYS End of Disclaimer INFOSYS*** -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130701/003fb

[Bug 66425] New: "failed testing IB on ring 5" when suspending to disk

orting Kernel driver in use: radeon Kernel modules: radeon -- 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/20130701/1fbddb47/attachment.html>

[PATCH RFC 1/3] DRM: Armada: Add Armada DRM driver

On Mon, Jul 01, 2013 at 10:01:30AM +1000, Dave Airlie wrote: > OMG I'm working in a subsystem where stuff is being developed, with only > a few resources! I know my full time job isn't maintaining a 500,000 > line subsystem, > and the sub maintainers and developers do a great job refactoring >

[Bug 65310] [regression] failure in building nvc0_vbo.lo: /tmp/cclDjdRp.s:1270: Error: missing or invalid displacement expression `-8589934576

ttp://lists.freedesktop.org/archives/dri-devel/attachments/20130701/cabf4c07/attachment.html>

[PATCH] drm/exynos: add error check routine in exynos_drm_open

From: YoungJun Cho yj44@samsung.com When the exynos_drm_subdrv_open() returns error, the file_priv should be released and file-driver_priv set to NULL. Signed-off-by: YoungJun Cho yj44@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com ---

Re: linux-next: Tree for Jul 1 [ drm-intel-next: Several call-traces ]

On Mon, Jul 1, 2013 at 10:49 AM, Sedat Dilek sedat.di...@gmail.com wrote: On Mon, Jul 1, 2013 at 9:59 AM, Stephen Rothwell s...@canb.auug.org.au wrote: Hi all, Changes since 20130628: The regulator tree gained a build failure so I used the version from next-20130628. The trivial tree

Re: [PATCH RFC 1/3] DRM: Armada: Add Armada DRM driver

On Mon, Jul 01, 2013 at 10:52:03AM +0200, Sebastian Hesselbarth wrote: On 07/01/13 02:01, Dave Airlie wrote: how about instead of writing: However, at least I've taken the time to_think_ about what I'm doing and realise that there_is_ scope here for the DRM core to improve, rather than

[PATCH]

___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/nouveau: fix locking in nouveau_crtc_page_flip

This is a bit messed up because chan-cli-mutex is a different class, depending on whether it is the global drm client or not. This is because the global cli-mutex lock can be taken for eviction, so locking it before pinning the buffer objects may result in a deadlock. The locking order from outer

[PATCH 0/3] drm: minor cleanups

This patch series fixes minor code issues including wrong trace point foramts, meaningless null checking, and possible resource leak in error cases. This is based drm-next branch. Seung-Woo Kim (2): drm: fix print format of sequence in trace point drm: move edid null check to the first part

[PATCH 1/3] drm: fix print format of sequence in trace point

seq of a trace point is unsigned int but print format was %d. So it fixes the format as %u even the format can be not used. Signed-off-by: Seung-Woo Kim sw0312@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- drivers/gpu/drm/drm_trace.h |6 +++--- 1 files changed, 3

[PATCH 2/3] drm: move edid null check to the first part of drm_edid_block_valid

If raw_edid is null, it will crash, so checking in bad label is meaningless. Signed-off-by: Seung-Woo Kim sw0312@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- drivers/gpu/drm/drm_edid.c |5 - 1 files changed, 4 insertions(+), 1 deletions(-) diff --git

[PATCH 3/3] drm: fix error routines in drm_open_helper

From: YoungJun Cho yj44@samsung.com There are wrong cases to handle error in drm_open_helper(). The priv-minor, assigned by idr_find() which can return NULL, should be checked whether it is NULL or not before referencing it. And if an error occurs after executing dev-driver-open() which

Re: [PATCH 3/3] drm: fix error routines in drm_open_helper

On Mon, Jul 01, 2013 at 07:06:33PM +0900, Seung-Woo Kim wrote: From: YoungJun Cho yj44@samsung.com There are wrong cases to handle error in drm_open_helper(). The priv-minor, assigned by idr_find() which can return NULL, should be checked whether it is NULL or not before referencing it.

Re: [PATCH 2/3] drm: move edid null check to the first part of drm_edid_block_valid

On Mon, Jul 01, 2013 at 07:06:32PM +0900, Seung-Woo Kim wrote: If raw_edid is null, it will crash, so checking in bad label is meaningless. It would be an error on part of the caller, but the defense looks sane. As the function is a bool, I would have preferred it returned true/false, but your

  1   2   >