[Bug 63935] TURKS [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!

was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130527/3bceeb33/attachment.html>

[Bug 63935] TURKS [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!

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

[PATCH 3/3] drm: Drop all the stub gamma_get, gamma_set, load_lut functions from drivers

On Mon, May 27, 2013 at 08:19:58PM +0300, ville.syrjala at linux.intel.com wrote: > From: Ville Syrj?l? > > Many of the drivers didn't implement palette/gamma handling, but were forced > to provide stubs for the hooks to avoid drm_fb_helper from oopsing. Now that > the hooks are optional, we

[PATCH 3/3] drm: Drop all the stub gamma_get, gamma_set, load_lut functions from drivers

From: Ville Syrj?l? Many of the drivers didn't implement palette/gamma handling, but were forced to provide stubs for the hooks to avoid drm_fb_helper from oopsing. Now that the hooks are optional, we can eliminate all the stubs. Signed-off-by: Ville Syrj?l? ---

[PATCH 2/3] drm/fb-helper: Make load_lut and gamma_set/gamma_get hooks optional

From: Ville Syrj?l? Check whether the crtc provides the load_lut callback before calling it. This allows the driver to provide the hook only for those CRTCs that actually have the hardware support for it. Also check whether the driver provided the fb_helper

[PATCH v2 1/3] drm/fb-helper: Don't clobber the display palette when fbdev isn't bound

From: Ville Syrj?l? Perform the drm_fb_helper_is_bound() check to avoid clobbering the display palette of some other KMS client. While at it, fix up the locking by grabbing all modeset locks for the duration of the fb_setcmap operation. v2: Make a note of the

picking efifb driver over dri driver

Hi On Mon, May 27, 2013 at 5:42 PM, Christopher Harvey wrote: > I'm looking for the mechanism in the kernel that makes the decision to > load the efifb driver over a dri one. Any tips? I've got a machine here > that loads efifb and prevents dri drivers from loading. If you want to use efifb

[PATCH] drm/exynos: fix tests for valid FIMD window number

From: Krzysztof Kozlowski Valid values for FIMD windows are from 0 to WINDOWS_NR-1 inclusive (5 windows in total). The WINDOWS_NR is also a size of fimd_context.win_data array. However, early-return tests for wrong values of windows accepted a value of WINDOWS_NR which

Introduce a new helper framework for buffer synchronization

Hi all, I have been removed previous branch and added new one with more cleanup. This time, the fence helper doesn't include user side interfaces and cache operation relevant codes anymore because not only we are not sure that coupling those two things, synchronizing caches and buffer access

[PATCH] drm/tegra: add support for runtime pm

- as of now host1x and gr2d module's clocks are enabled in their driver's .probe and never disabled - this commit adds support for runtime pm in host1x and gr2d drivers - during boot-up clocks are enabled in .probe and disabled on its exit - when new work is submitted, clocks are enabled in submit

[PATCH 2/2] drm/fb-helper: Don't load the display palette if the CRTC is disabled

On Mon, May 27, 2013 at 06:44:57PM +0300, ville.syrjala at linux.intel.com wrote: > From: Ville Syrj?l? > > Often the hardware needs certain clocks running when accessing the > palette, so don't go poking at it if the CRTC is disabled. We still > call the fb_helper gamma_set hooks to update the

[PATCH 2/2] drm/fb-helper: Don't load the display palette if the CRTC is disabled

From: Ville Syrj?l? Often the hardware needs certain clocks running when accessing the palette, so don't go poking at it if the CRTC is disabled. We still call the fb_helper gamma_set hooks to update the driver's notion of what the palette should contain, so that

[PATCH 1/2] drm/fb-helper: Don't clobber the display palette when fbdev isn't bound

From: Ville Syrj?l? Perform the drm_fb_helper_is_bound() check to avoid clobbering the display palette of some other KMS client. Signed-off-by: Ville Syrj?l? --- drivers/gpu/drm/drm_fb_helper.c | 11 ++- 1 file changed, 10 insertions(+), 1 deletion(-)

drivers/gpu/drm/qxl/qxl_fb.c:162:15: error: variable ‘qxl_defio’

I've also encountered same problem, the solution for me is: --- linux-3.10-rc3.old/drivers/gpu/drm/qxl/Kconfig 2013-05-27 18:06:27.53400 +0400 +++ linux-3.10-rc3/drivers/gpu/drm/qxl/Kconfig 2013-05-27 15:19:59.3 +0400 @@ -1,6 +1,7 @@ config DRM_QXL tristate "QXL virtual

RE: drivers/gpu/drm/qxl/qxl_fb.c:162:15: error: variable ‘qxl_defio’

rg/archives/dri-devel/attachments/20130527/06088a73/attachment.html>

Introduce a new helper framework for buffer synchronization

On Mon, May 27, 2013 at 5:47 PM, Rob Clark wrote: > On Mon, May 27, 2013 at 6:38 AM, Inki Dae wrote: >> Hi all, >> >> I have been removed previous branch and added new one with more cleanup. >> This time, the fence helper doesn't include user side interfaces and cache >> operation relevant codes

[PATCH 2/2] drm/fb-helper: Don't load the display palette if the CRTC is disabled

On Mon, May 27, 2013 at 06:44:57PM +0300, ville.syrjala at linux.intel.com wrote: > From: Ville Syrj?l? > > Often the hardware needs certain clocks running when accessing the > palette, so don't go poking at it if the CRTC is disabled. We still > call the fb_helper gamma_set hooks to update the

[PATCH 1/2] drm/fb-helper: Don't clobber the display palette when fbdev isn't bound

On Mon, May 27, 2013 at 06:44:56PM +0300, ville.syrjala at linux.intel.com wrote: > From: Ville Syrj?l? > > Perform the drm_fb_helper_is_bound() check to avoid clobbering the > display palette of some other KMS client. > > Signed-off-by: Ville Syrj?l? You might want to mention that you're

[PATCH] drm/tegra: add support for runtime pm

>waiter->count, waiter->thresh); > - > } This feels hackish. But I can't see any better place to do this. Terje, Arto: any ideas how we can do this in a cleaner way? If there's nothing better then maybe moving the code into a separ

picking efifb driver over dri driver

On Mon, May 27, 2013 at 5:42 PM, Christopher Harvey wrote: > I'm looking for the mechanism in the kernel that makes the decision to > load the efifb driver over a dri one. Any tips? I've got a machine here > that loads efifb and prevents dri drivers from loading. Once the drm driver loads it

[Bug 65016] [radeonsi] X server segfaults at startup with mesa-9.1*

wering.h", line=56) at ErrorHandling.cpp:98 -- 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/20130527/1dd17080/attachment.html>

Introduce a new helper framework for buffer synchronization

Hey, Op 27-05-13 12:38, Inki Dae schreef: > Hi all, > > I have been removed previous branch and added new one with more cleanup. > This time, the fence helper doesn't include user side interfaces and cache > operation relevant codes anymore because not only we are not sure that > coupling those

radeon ucode updates

akes instead of old ones. -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 828 bytes Desc: This is a digitally signed message part URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20

[PATCH v3 2/3] mutex: add support for wound/wait style locks, v3

On Mon, May 27, 2013 at 4:47 PM, Daniel Vetter wrote: > On Mon, May 27, 2013 at 10:21 AM, Peter Zijlstra > wrote: >> On Wed, May 22, 2013 at 07:24:38PM +0200, Maarten Lankhorst wrote: >>> >> +static inline void ww_acquire_init(struct ww_acquire_ctx *ctx, >>> >> +

[PATCH v3 2/3] mutex: add support for wound/wait style locks, v3

On Mon, May 27, 2013 at 10:21 AM, Peter Zijlstra wrote: > On Wed, May 22, 2013 at 07:24:38PM +0200, Maarten Lankhorst wrote: >> >> +static inline void ww_acquire_init(struct ww_acquire_ctx *ctx, >> >> + struct ww_class *ww_class) >> >> +{ >> >> + ctx->task = current;

[PATCH 1/3] video: display_timing: add doubleclk flag

On 14:33 Mon 27 May , Lucas Stach wrote: > From: Steffen Trumtrar > > Signed-off-by: Steffen Trumtrar Acked-by: Jean-Christophe PLAGNIOL-VILLARD If you want to take it via dri I'm fine otherwise via fbdev Best Regards, J. > --- > include/video/display_timing.h |1 + > 1 file

[PATCH] qxl: fix Kconfig deps - select FB_DEFERRED_IO

Signed-off-by: Andrew Jones --- drivers/gpu/drm/qxl/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/qxl/Kconfig b/drivers/gpu/drm/qxl/Kconfig index 2f1a57e11140a..d6c12796023cd 100644 --- a/drivers/gpu/drm/qxl/Kconfig +++ b/drivers/gpu/drm/qxl/Kconfig @@ -4,6 +4,7 @@

[PATCH] drm/exynos: fix checks for valid mixer window

- if (win < 0 || win > MIXER_WIN_NR) { > + if (win < 0 || win >= MIXER_WIN_NR) { > DRM_ERROR("mixer window[%d] is wrong\n", win); > return; > } > -- > 1.7.4.1 > > ___ > 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/20130527/67eac6ba/attachment.html>

[Bug 65016] [radeonsi] X server segfaults at startup with mesa-9.1*

tachments/20130527/20fa6b16/attachment.html>

[PATCH] drm/exynos: fix checks for valid mixer window

From: Krzysztof Kozlowski Valid values for mixer window are from 0 to MIXER_WIN_NR-1 inclusive. Arrays in structures (e.g. mixer_context.win_data) have size of MIXER_WIN_NR so checks for wrong mixer window must be greater-equal. Signed-off-by: Krzysztof Kozlowski

[PATCH 3/3] drm_modes: videomode: add doubleclk flag

From: Steffen Trumtrar Signed-off-by: Steffen Trumtrar --- drivers/gpu/drm/drm_modes.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c index faa79df..875031d 100644 --- a/drivers/gpu/drm/drm_modes.c

[PATCH 2/3] video: of: display_timing: add doubleclk flag

From: Steffen Trumtrar Signed-off-by: Steffen Trumtrar --- Documentation/devicetree/bindings/video/display-timing.txt |1 + drivers/video/of_display_timing.c |2 ++ 2 files changed, 3 insertions(+) diff --git

[PATCH 1/3] video: display_timing: add doubleclk flag

From: Steffen Trumtrar Signed-off-by: Steffen Trumtrar --- include/video/display_timing.h |1 + 1 file changed, 1 insertion(+) diff --git a/include/video/display_timing.h b/include/video/display_timing.h index 5d0259b..28d9d0d 100644 ---

[PATCH] video: display_timing: make parameter const

From: Steffen Trumtrar As the device_node pointer is not changed in of_get_display_timing and parse_timing_property it can be a const pointer. Signed-off-by: Steffen Trumtrar --- drivers/video/of_display_timing.c |5 +++-- 1 file changed, 3 insertions(+), 2

[PATCH v3 2/3] mutex: add support for wound/wait style locks, v3

Op 27-05-13 13:15, Peter Zijlstra schreef: > On Mon, May 27, 2013 at 12:52:00PM +0200, Maarten Lankhorst wrote: >> The reason ttm needed it was because there was another lock that interacted >> with the ctx lock in a weird way. The ww lock it was using was inverted with >> another >> lock, so it

[PATCH v3 2/3] mutex: add support for wound/wait style locks, v3

On Mon, May 27, 2013 at 12:52:00PM +0200, Maarten Lankhorst wrote: > The reason ttm needed it was because there was another lock that interacted > with the ctx lock in a weird way. The ww lock it was using was inverted with > another > lock, so it had to grab that lock first, perform a trylock on

[PATCH v3 2/3] mutex: add support for wound/wait style locks, v3

Op 27-05-13 12:24, Peter Zijlstra schreef: > On Mon, May 27, 2013 at 12:01:50PM +0200, Maarten Lankhorst wrote: >>> Again, early.. monday.. would a trylock, even if successful still need >>> the ctx? >> No ctx for trylock is supported. You can still do a trylock while >> holding a context, but the

[PATCH v3 2/3] mutex: add support for wound/wait style locks, v3

On Mon, May 27, 2013 at 12:01:50PM +0200, Maarten Lankhorst wrote: > > Again, early.. monday.. would a trylock, even if successful still need > > the ctx? > No ctx for trylock is supported. You can still do a trylock while > holding a context, but the mutex won't be a part of the context. > Normal

[PATCH v3 2/3] mutex: add support for wound/wait style locks, v3

Op 27-05-13 10:21, Peter Zijlstra schreef: > On Wed, May 22, 2013 at 07:24:38PM +0200, Maarten Lankhorst wrote: +static inline void ww_acquire_init(struct ww_acquire_ctx *ctx, + struct ww_class *ww_class) +{ + ctx->task = current; + do {

[PATCH v3 2/3] mutex: add support for wound/wait style locks, v3

Op 27-05-13 11:13, Peter Zijlstra schreef: > On Mon, May 27, 2013 at 10:26:39AM +0200, Maarten Lankhorst wrote: >> Op 27-05-13 10:00, Peter Zijlstra schreef: >>> On Wed, May 22, 2013 at 07:24:38PM +0200, Maarten Lankhorst wrote: >> +- Functions to only acquire a single w/w mutex, which results

Introduce a new helper framework for buffer synchronization

On Mon, May 27, 2013 at 6:38 AM, Inki Dae wrote: > Hi all, > > I have been removed previous branch and added new one with more cleanup. > This time, the fence helper doesn't include user side interfaces and cache > operation relevant codes anymore because not only we are not sure that > coupling

picking efifb driver over dri driver

I'm looking for the mechanism in the kernel that makes the decision to load the efifb driver over a dri one. Any tips? I've got a machine here that loads efifb and prevents dri drivers from loading. thanks, Chris

[PATCH v3 2/3] mutex: add support for wound/wait style locks, v3

On Wed, May 22, 2013 at 06:49:04PM +0200, Daniel Vetter wrote: > - _slow functions can check whether all acquire locks have been > released and whether the caller is indeed blocking on the contending > lock. Not doing so could either result in needless spinning instead of > blocking (when blocking

[PATCH v3 2/3] mutex: add support for wound/wait style locks, v3

Op 27-05-13 10:00, Peter Zijlstra schreef: > On Wed, May 22, 2013 at 07:24:38PM +0200, Maarten Lankhorst wrote: +- Functions to only acquire a single w/w mutex, which results in the exact same + semantics as a normal mutex. These functions have the _single postfix. >>> This is

[PATCH v3 2/3] mutex: add support for wound/wait style locks, v3

On Wed, May 22, 2013 at 07:24:38PM +0200, Maarten Lankhorst wrote: > >> +- Functions to only acquire a single w/w mutex, which results in the > >> exact same > >> + semantics as a normal mutex. These functions have the _single postfix. > > This is missing rationale. > trylock_single is useful

[PATCH 3/6] gpu: host1x: Fix memory access in syncpt request

On 05/26/2013 01:15 PM, Thierry Reding wrote: > * PGP Signed by an unknown key > > On Fri, May 17, 2013 at 02:49:45PM +0300, Arto Merilainen wrote: >> This patch fixes a bad memory access in syncpoint request code. If >> no syncpoints were available, the code accessed unreserved memory >> area

[PATCH 2/6] gpu: host1x: Fix syncpoint wait return value

On 05/26/2013 01:12 PM, Thierry Reding wrote: > * PGP Signed by an unknown key > > On Fri, May 17, 2013 at 02:49:44PM +0300, Arto Merilainen wrote: >> Syncpoint wait returned EAGAIN if it was called with zero timeout. >> This patch modifies the function to return ETIMEDOUT. > > This description is

[PATCH 1/6] gpu: host1x: Fixes to host1x firewall

On 05/26/2013 01:02 PM, Thierry Reding wrote: > * PGP Signed by an unknown key > > On Fri, May 17, 2013 at 02:49:43PM +0300, Arto Merilainen wrote: >> From: Terje Bergstrom >> >> This patch adds several fixes to host1x firewall: >> - Host1x firewall does not survive if it expects a reloc, but

drm-openchrome status (or will it be in Kernel 3.10?)

> Sorry I didn't responded earlier. I was swamped at work with > projects and conferences. After I got back from my last conference > Xavier informed me about this email and we had a discussion about > merging. Currently we have a external tree which is two years old but > most of the work

[Bug 64257] RS880 issues with r600-llvm-compiler

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

[Bug 50091] [BISECTED]GeForce 6150SE: system hangs on X-server start with garbled screen

https://bugzilla.kernel.org/show_bug.cgi?id=50091 Joachim Namislow changed: What|Removed |Added CC||jfrieben at hotmail.com ---

[PATCH v3, part2 14/20] PCI, DRM: use hotplug-safe iterators to walk PCI buses

Enhance DRM drvier to use hotplug-safe iterators to walk PCI buses. Signed-off-by: Jiang Liu Cc: David Airlie Cc: dri-devel at lists.freedesktop.org Cc: linux-kernel at vger.kernel.org --- drivers/gpu/drm/drm_fops.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git

[Bug 64257] RS880 issues with r600-llvm-compiler

https://bugs.freedesktop.org/show_bug.cgi?id=64257 --- Comment #19 from Mike Lothian --- Created attachment 79821 --> https://bugs.freedesktop.org/attachment.cgi?id=79821=edit KWin with corruption OK I'm just back and I've recompiled everything from master - unfortunately things have

[Bug 63935] TURKS [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!

https://bugs.freedesktop.org/show_bug.cgi?id=63935 --- Comment #46 from Austin Lund --- The changes didn't make 3.10-rc3 (too soon?). Also, no answers yet for if the test for EFI booted macs it can be removed. -- You are receiving this mail because: You are the assignee for the bug.

drm-openchrome status (or will it be in Kernel 3.10?)

> > Dave what is the best way to push this code? I am in no rush so > > I like to do it the right way. We have scattered history in the external > > tree but I would not lose sleep over its lost. I could just post pieces > > of the code to this list for review. One choice is after all the

[REGRESSION] system does not resume from ram due to commit "drm/nv50/fifo: prevent races between clients updating playlists"

My NV96 does not resume from suspend to ram (the screen stays black, magic sysrq keys do work) with the current linus git kernel, i bisected it to the following commit. drm/nv50/fifo: prevent races between clients updating playlists b5096566f6e1ee2b88324772f020ae9bc0cfa9a0 It's not obvious to me

[PATCH 1/3] drm/gma500: Unpin framebuffer when destroying it

On Sun, May 26, 2013 at 10:31 PM, Patrik Jakobsson wrote: > On Sun, May 26, 2013 at 9:07 PM, Daniel Vetter wrote: >> On Sun, May 26, 2013 at 08:03:53PM +0200, Patrik Jakobsson wrote: >>> A framebuffer is pinned when it's set as pipe base, so we also need to >>> unpin it when it's destroyed. Some

[PATCH] drm/exynos: fix checks for valid mixer window

From: Krzysztof Kozlowski k.kozlow...@samsung.com Valid values for mixer window are from 0 to MIXER_WIN_NR-1 inclusive. Arrays in structures (e.g. mixer_context.win_data) have size of MIXER_WIN_NR so checks for wrong mixer window must be greater-equal. Signed-off-by: Krzysztof Kozlowski

Re: [PATCH] drm/exynos: fix checks for valid mixer window

Applied. Thanks, Inki Dae 2013/5/27 Seung-Woo Kim sw0312@samsung.com From: Krzysztof Kozlowski k.kozlow...@samsung.com Valid values for mixer window are from 0 to MIXER_WIN_NR-1 inclusive. Arrays in structures (e.g. mixer_context.win_data) have size of MIXER_WIN_NR so checks for wrong

Re: [PATCH 1/6] gpu: host1x: Fixes to host1x firewall

On 05/26/2013 01:02 PM, Thierry Reding wrote: * PGP Signed by an unknown key On Fri, May 17, 2013 at 02:49:43PM +0300, Arto Merilainen wrote: From: Terje Bergstrom tbergst...@nvidia.com This patch adds several fixes to host1x firewall: - Host1x firewall does not survive if it expects a reloc,

Re: [PATCH 2/6] gpu: host1x: Fix syncpoint wait return value

On 05/26/2013 01:12 PM, Thierry Reding wrote: * PGP Signed by an unknown key On Fri, May 17, 2013 at 02:49:44PM +0300, Arto Merilainen wrote: Syncpoint wait returned EAGAIN if it was called with zero timeout. This patch modifies the function to return ETIMEDOUT. This description is a bit

Re: [PATCH 3/6] gpu: host1x: Fix memory access in syncpt request

On 05/26/2013 01:15 PM, Thierry Reding wrote: * PGP Signed by an unknown key On Fri, May 17, 2013 at 02:49:45PM +0300, Arto Merilainen wrote: This patch fixes a bad memory access in syncpoint request code. If no syncpoints were available, the code accessed unreserved memory area causing

Re: [PATCH v3 2/3] mutex: add support for wound/wait style locks, v3

On Wed, May 22, 2013 at 07:24:38PM +0200, Maarten Lankhorst wrote: +- Functions to only acquire a single w/w mutex, which results in the exact same + semantics as a normal mutex. These functions have the _single postfix. This is missing rationale. trylock_single is useful when

Re: [PATCH v3 2/3] mutex: add support for wound/wait style locks, v3

On Wed, May 22, 2013 at 07:24:38PM +0200, Maarten Lankhorst wrote: +static inline void ww_acquire_init(struct ww_acquire_ctx *ctx, + struct ww_class *ww_class) +{ + ctx-task = current; + do { + ctx-stamp = atomic_long_inc_return(ww_class-stamp);

Re: [PATCH v3 2/3] mutex: add support for wound/wait style locks, v3

Op 27-05-13 10:00, Peter Zijlstra schreef: On Wed, May 22, 2013 at 07:24:38PM +0200, Maarten Lankhorst wrote: +- Functions to only acquire a single w/w mutex, which results in the exact same + semantics as a normal mutex. These functions have the _single postfix. This is missing rationale.

Re: [PATCH v3 2/3] mutex: add support for wound/wait style locks, v3

On Wed, May 22, 2013 at 06:49:04PM +0200, Daniel Vetter wrote: - _slow functions can check whether all acquire locks have been released and whether the caller is indeed blocking on the contending lock. Not doing so could either result in needless spinning instead of blocking (when blocking on

Re: [PATCH v3 2/3] mutex: add support for wound/wait style locks, v3

On Mon, May 27, 2013 at 10:26:39AM +0200, Maarten Lankhorst wrote: Op 27-05-13 10:00, Peter Zijlstra schreef: On Wed, May 22, 2013 at 07:24:38PM +0200, Maarten Lankhorst wrote: +- Functions to only acquire a single w/w mutex, which results in the exact same + semantics as a normal

Re: [PATCH v3 2/3] mutex: add support for wound/wait style locks, v3

Op 27-05-13 11:13, Peter Zijlstra schreef: On Mon, May 27, 2013 at 10:26:39AM +0200, Maarten Lankhorst wrote: Op 27-05-13 10:00, Peter Zijlstra schreef: On Wed, May 22, 2013 at 07:24:38PM +0200, Maarten Lankhorst wrote: +- Functions to only acquire a single w/w mutex, which results in the

Re: [PATCH v3 2/3] mutex: add support for wound/wait style locks, v3

Op 27-05-13 10:21, Peter Zijlstra schreef: On Wed, May 22, 2013 at 07:24:38PM +0200, Maarten Lankhorst wrote: +static inline void ww_acquire_init(struct ww_acquire_ctx *ctx, + struct ww_class *ww_class) +{ + ctx-task = current; + do { + ctx-stamp =

Re: [PATCH v3 2/3] mutex: add support for wound/wait style locks, v3

On Mon, May 27, 2013 at 12:01:50PM +0200, Maarten Lankhorst wrote: Again, early.. monday.. would a trylock, even if successful still need the ctx? No ctx for trylock is supported. You can still do a trylock while holding a context, but the mutex won't be a part of the context. Normal

RE: Introduce a new helper framework for buffer synchronization

Hi all, I have been removed previous branch and added new one with more cleanup. This time, the fence helper doesn't include user side interfaces and cache operation relevant codes anymore because not only we are not sure that coupling those two things, synchronizing caches and buffer access

Re: [PATCH v3 2/3] mutex: add support for wound/wait style locks, v3

Op 27-05-13 12:24, Peter Zijlstra schreef: On Mon, May 27, 2013 at 12:01:50PM +0200, Maarten Lankhorst wrote: Again, early.. monday.. would a trylock, even if successful still need the ctx? No ctx for trylock is supported. You can still do a trylock while holding a context, but the mutex

[PATCH] drm/exynos: fix tests for valid FIMD window number

From: Krzysztof Kozlowski k.kozlow...@samsung.com Valid values for FIMD windows are from 0 to WINDOWS_NR-1 inclusive (5 windows in total). The WINDOWS_NR is also a size of fimd_context.win_data array. However, early-return tests for wrong values of windows accepted a value of WINDOWS_NR which is

Re: [PATCH v3 2/3] mutex: add support for wound/wait style locks, v3

On Mon, May 27, 2013 at 12:52:00PM +0200, Maarten Lankhorst wrote: The reason ttm needed it was because there was another lock that interacted with the ctx lock in a weird way. The ww lock it was using was inverted with another lock, so it had to grab that lock first, perform a trylock on the

Re: [PATCH v3 2/3] mutex: add support for wound/wait style locks, v3

Op 27-05-13 13:15, Peter Zijlstra schreef: On Mon, May 27, 2013 at 12:52:00PM +0200, Maarten Lankhorst wrote: The reason ttm needed it was because there was another lock that interacted with the ctx lock in a weird way. The ww lock it was using was inverted with another lock, so it had to

[PATCH] video: display_timing: make parameter const

From: Steffen Trumtrar s.trumt...@pengutronix.de As the device_node pointer is not changed in of_get_display_timing and parse_timing_property it can be a const pointer. Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de --- drivers/video/of_display_timing.c |5 +++-- 1 file changed,

[PATCH 1/3] video: display_timing: add doubleclk flag

From: Steffen Trumtrar s.trumt...@pengutronix.de Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de --- include/video/display_timing.h |1 + 1 file changed, 1 insertion(+) diff --git a/include/video/display_timing.h b/include/video/display_timing.h index 5d0259b..28d9d0d 100644 ---

[PATCH 3/3] drm_modes: videomode: add doubleclk flag

From: Steffen Trumtrar s.trumt...@pengutronix.de Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de --- drivers/gpu/drm/drm_modes.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c index faa79df..875031d 100644 ---

[PATCH 2/3] video: of: display_timing: add doubleclk flag

From: Steffen Trumtrar s.trumt...@pengutronix.de Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de --- Documentation/devicetree/bindings/video/display-timing.txt |1 + drivers/video/of_display_timing.c |2 ++ 2 files changed, 3 insertions(+) diff --git

RE: drivers/gpu/drm/qxl/qxl_fb.c:162:15: error: variable ‘qxl_defio’

I've also encountered same problem, the solution for me is: --- linux-3.10-rc3.old/drivers/gpu/drm/qxl/Kconfig 2013-05-27 18:06:27.53400 +0400 +++ linux-3.10-rc3/drivers/gpu/drm/qxl/Kconfig 2013-05-27 15:19:59.3 +0400 @@ -1,6 +1,7 @@ config DRM_QXL tristate QXL virtual

drivers/gpu/drm/qxl/qxl_fb.c:162:15: error: variable ‘qxl_defio’

I've also encountered same problem, the solution for me is: --- linux-3.10-rc3.old/drivers/gpu/drm/qxl/Kconfig 2013-05-27 18:06:27.53400 +0400 +++ linux-3.10-rc3/drivers/gpu/drm/qxl/Kconfig 2013-05-27 15:19:59.3 +0400 @@ -1,6 +1,7 @@ config DRM_QXL tristate QXL virtual

Re: [PATCH v3 2/3] mutex: add support for wound/wait style locks, v3

On Mon, May 27, 2013 at 10:21 AM, Peter Zijlstra pet...@infradead.org wrote: On Wed, May 22, 2013 at 07:24:38PM +0200, Maarten Lankhorst wrote: +static inline void ww_acquire_init(struct ww_acquire_ctx *ctx, + struct ww_class *ww_class) +{ + ctx-task =

Re: [PATCH v3 2/3] mutex: add support for wound/wait style locks, v3

On Mon, May 27, 2013 at 4:47 PM, Daniel Vetter dan...@ffwll.ch wrote: On Mon, May 27, 2013 at 10:21 AM, Peter Zijlstra pet...@infradead.org wrote: On Wed, May 22, 2013 at 07:24:38PM +0200, Maarten Lankhorst wrote: +static inline void ww_acquire_init(struct ww_acquire_ctx *ctx, +

[Bug 65016] [radeonsi] X server segfaults at startup with mesa-9.1*

https://bugs.freedesktop.org/show_bug.cgi?id=65016 --- Comment #3 from Michel Dänzer mic...@daenzer.net --- (In reply to comment #3) - mesa 9.1.3, also tried earlier minor versions - llvm 3.3_rc2, llvm Git The radeonsi driver in Mesa 9.1.y cannot work with LLVM 3.3 or later but requires a

Re: Introduce a new helper framework for buffer synchronization

Hey, Op 27-05-13 12:38, Inki Dae schreef: Hi all, I have been removed previous branch and added new one with more cleanup. This time, the fence helper doesn't include user side interfaces and cache operation relevant codes anymore because not only we are not sure that coupling those two

picking efifb driver over dri driver

I'm looking for the mechanism in the kernel that makes the decision to load the efifb driver over a dri one. Any tips? I've got a machine here that loads efifb and prevents dri drivers from loading. thanks, Chris ___ dri-devel mailing list

Re: picking efifb driver over dri driver

On Mon, May 27, 2013 at 5:42 PM, Christopher Harvey char...@matrox.com wrote: I'm looking for the mechanism in the kernel that makes the decision to load the efifb driver over a dri one. Any tips? I've got a machine here that loads efifb and prevents dri drivers from loading. Once the drm

[PATCH 1/2] drm/fb-helper: Don't clobber the display palette when fbdev isn't bound

From: Ville Syrjälä ville.syrj...@linux.intel.com Perform the drm_fb_helper_is_bound() check to avoid clobbering the display palette of some other KMS client. Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com --- drivers/gpu/drm/drm_fb_helper.c | 11 ++- 1 file changed, 10

[PATCH 2/2] drm/fb-helper: Don't load the display palette if the CRTC is disabled

From: Ville Syrjälä ville.syrj...@linux.intel.com Often the hardware needs certain clocks running when accessing the palette, so don't go poking at it if the CRTC is disabled. We still call the fb_helper gamma_set hooks to update the driver's notion of what the palette should contain, so that

Re: [PATCH] drm/tegra: add support for runtime pm

On Mon, May 27, 2013 at 07:19:28PM +0530, Mayuresh Kulkarni wrote: - as of now host1x and gr2d module's clocks are enabled in their driver's .probe and never disabled - this commit adds support for runtime pm in host1x and gr2d drivers - during boot-up clocks are enabled in .probe and

Re: Introduce a new helper framework for buffer synchronization

On Mon, May 27, 2013 at 6:38 AM, Inki Dae inki@samsung.com wrote: Hi all, I have been removed previous branch and added new one with more cleanup. This time, the fence helper doesn't include user side interfaces and cache operation relevant codes anymore because not only we are not sure

Re: [PATCH 1/2] drm/fb-helper: Don't clobber the display palette when fbdev isn't bound

On Mon, May 27, 2013 at 06:44:56PM +0300, ville.syrj...@linux.intel.com wrote: From: Ville Syrjälä ville.syrj...@linux.intel.com Perform the drm_fb_helper_is_bound() check to avoid clobbering the display palette of some other KMS client. Signed-off-by: Ville Syrjälä

Re: [PATCH 2/2] drm/fb-helper: Don't load the display palette if the CRTC is disabled

On Mon, May 27, 2013 at 06:44:57PM +0300, ville.syrj...@linux.intel.com wrote: From: Ville Syrjälä ville.syrj...@linux.intel.com Often the hardware needs certain clocks running when accessing the palette, so don't go poking at it if the CRTC is disabled. We still call the fb_helper gamma_set

Re: [PATCH 2/2] drm/fb-helper: Don't load the display palette if the CRTC is disabled

On Mon, May 27, 2013 at 06:44:57PM +0300, ville.syrj...@linux.intel.com wrote: From: Ville Syrjälä ville.syrj...@linux.intel.com Often the hardware needs certain clocks running when accessing the palette, so don't go poking at it if the CRTC is disabled. We still call the fb_helper gamma_set

Re: Introduce a new helper framework for buffer synchronization

On Mon, May 27, 2013 at 5:47 PM, Rob Clark robdcl...@gmail.com wrote: On Mon, May 27, 2013 at 6:38 AM, Inki Dae inki@samsung.com wrote: Hi all, I have been removed previous branch and added new one with more cleanup. This time, the fence helper doesn't include user side interfaces and

Re: radeon ucode updates

On Wed, 2013-05-15 at 15:28 -0400, Alex Deucher wrote: Hi Ben, The attached patch adds the new radeon ucode required for the new hainan asic. Please apply to the firmware tree. Applied, thanks. Ben. -- Ben Hutchings Experience is what causes a person to make new mistakes instead of old

[PATCH v2 1/3] drm/fb-helper: Don't clobber the display palette when fbdev isn't bound

From: Ville Syrjälä ville.syrj...@linux.intel.com Perform the drm_fb_helper_is_bound() check to avoid clobbering the display palette of some other KMS client. While at it, fix up the locking by grabbing all modeset locks for the duration of the fb_setcmap operation. v2: Make a note of the

[PATCH 2/3] drm/fb-helper: Make load_lut and gamma_set/gamma_get hooks optional

From: Ville Syrjälä ville.syrj...@linux.intel.com Check whether the crtc provides the load_lut callback before calling it. This allows the driver to provide the hook only for those CRTCs that actually have the hardware support for it. Also check whether the driver provided the fb_helper

[PATCH 3/3] drm: Drop all the stub gamma_get, gamma_set, load_lut functions from drivers

From: Ville Syrjälä ville.syrj...@linux.intel.com Many of the drivers didn't implement palette/gamma handling, but were forced to provide stubs for the hooks to avoid drm_fb_helper from oopsing. Now that the hooks are optional, we can eliminate all the stubs. Signed-off-by: Ville Syrjälä

[Bug 65016] [radeonsi] X server segfaults at startup with mesa-9.1*

https://bugs.freedesktop.org/show_bug.cgi?id=65016 Alexander Tsoy alexan...@tsoy.me changed: What|Removed |Added Status|NEW |RESOLVED

  1   2   >