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 wh
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
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 miss
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 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
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
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 {
+
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
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 betwe
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
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 is out of bound
for fimd_co
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
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 h
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 deletions(-)
diff --git a/drive
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
--- a/include/video/display_timing.h
+++ b/include/video
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
+++ b/drivers/gpu/drm/drm_mod
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 a/Documentation/devicetree/bindings/video/display-ti
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
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
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;
>
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,
>>> >> + struct
https://bugs.freedesktop.org/show_bug.cgi?id=65016
--- Comment #3 from Michel Dänzer ---
(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 snapshot of the git:/
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 tw
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
dri-devel@list
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 shou
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(-)
diff --git a/drivers/gpu/drm/drm_
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 if/when CRTC gets enabled,
the dr
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 dis
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 t
On Mon, May 27, 2013 at 06:44:56PM +0300, ville.syrj...@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 also fi
On Mon, May 27, 2013 at 06:44:57PM +0300, ville.syrj...@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 driv
On Mon, May 27, 2013 at 06:44:57PM +0300, ville.syrj...@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 driv
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
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
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 locking changes in the commit messa
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 gamma_set/gamma_get
hooks. It's a driv
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ä
---
drivers/gpu/drm/exynos/exynos_d
https://bugs.freedesktop.org/show_bug.cgi?id=65016
Alexander Tsoy changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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 over
On Mon, May 27, 2013 at 08:19:58PM +0300, ville.syrj...@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 can eli
https://bugs.freedesktop.org/show_bug.cgi?id=63935
zsolt barat changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://bugs.freedesktop.org/show_bug.cgi?id=63935
--- Comment #48 from Austin Lund ---
(In reply to comment #47)
>
> I can confirm that the patch works on boot, also on a mac 8,2 with drm-next
> and patches, but fails on suspend resume. It reappears on resume.
> Please reopen the bug.
I have a
https://bugs.freedesktop.org/show_bug.cgi?id=63935
--- Comment #49 from Erdem U. Altınyurt ---
Patch doesn't fix the issue on radeon HD 6850 (BARTS 0x1002:0x6739
0x174B:0xE174)
kernel 3.10-rc3 + SUMO_uvs.patch
(https://bugs.freedesktop.org/attachment.cgi?id=79663)
Still got
[drm:r600_uvd_init] *
https://bugs.freedesktop.org/show_bug.cgi?id=63935
--- Comment #50 from Erdem U. Altınyurt ---
Also patched SUMO2 patch from
http://lists.freedesktop.org/archives/dri-devel/2013-May/038894.html
'''Still no success!'''
Still got [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the
> -Original Message-
> From: Maarten Lankhorst [mailto:maarten.lankho...@canonical.com]
> Sent: Tuesday, May 28, 2013 12:23 AM
> To: Inki Dae
> Cc: 'Daniel Vetter'; 'Rob Clark'; 'linux-fbdev'; 'YoungJun Cho'; 'Kyungmin
> Park'; 'myungjoo.ham'; 'DRI mailing list'; linux-arm-
> ker...@lists
> -Original Message-
> From: linux-fbdev-ow...@vger.kernel.org [mailto:linux-fbdev-
> ow...@vger.kernel.org] On Behalf Of Rob Clark
> Sent: Tuesday, May 28, 2013 12:48 AM
> To: Inki Dae
> Cc: Maarten Lankhorst; Daniel Vetter; linux-fbdev; YoungJun Cho; Kyungmin
> Park; myungjoo.ham; DRI m
> -Original Message-
> From: daniel.vet...@ffwll.ch [mailto:daniel.vet...@ffwll.ch] On Behalf Of
> Daniel Vetter
> Sent: Tuesday, May 28, 2013 1:02 AM
> To: Rob Clark
> Cc: Inki Dae; Maarten Lankhorst; linux-fbdev; YoungJun Cho; Kyungmin Park;
> myungjoo.ham; DRI mailing list; linux-arm-k
- 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
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 @@ c
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 changed,
On 27.05.2013 18:45, Thierry Reding wrote:
> On Mon, May 27, 2013 at 07:19:28PM +0530, Mayuresh Kulkarni wrote:
>> +#ifdef CONFIG_PM_RUNTIME
>> +static int host1x_runtime_suspend(struct device *dev)
>> +{
>> +struct host1x *host;
>> +
>> +host = dev_get_drvdata(dev);
>> +if (IS_ERR_OR_N
> 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
https://bugzilla.kernel.org/show_bug.cgi?id=50091
Joachim Namislow changed:
What|Removed |Added
CC||jfrieben at hotmail.com
--- Commen
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130527/dc190c39/attachment.html>
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
Signed-off-by: Hyunhee Kim
Sig
- 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>
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 user
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
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 caus
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 wh
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
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 miss
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 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
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
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 {
+
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
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 betwe
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
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 is out of bound
for fimd_co
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
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 h
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 deletions(-)
diff --git a/drive
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
--- a/include/video/display_timing.h
+++ b/include/video
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
+++ b/drivers/gpu/drm/drm_mod
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 a/Documentation/devicetree/bindings/video/display-ti
top.org/archives/dri-devel/attachments/20130527/06088a73/attachment.html>
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
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;
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,
>>> >> + stru
tachments/20130527/20fa6b16/attachment.html>
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 tw
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
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 sho
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(-)
diff --git a/drivers/gpu/drm/drm_
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 if/when CRTC gets enabled,
the dr
way? If there's nothing
better then maybe moving the code into a separate function, say
host1x_waitlist_complete(), might make this less awkward?
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/20130527/8bb89d1a/attachment.pgp>
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 t
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 als
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
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
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
s 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
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 locking changes in the commit messa
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 gamma_set/gamma_get
hooks. It's a driv
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?
---
drivers/gpu/drm/exynos/exynos_d
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>
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 ove
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 can
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>
1 - 100 of 104 matches
Mail list logo
