se:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130409/df37a804/attachment.html>
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130409/6477bf17/attachment.html>
xt part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130409/e4dba931/attachment-0001.html>
On Tue, Apr 09, 2013 at 09:44:46AM +0200, Philipp Zabel wrote:
> Hi Greg,
>
> Am Montag, den 08.04.2013, 10:40 -0700 schrieb Greg Kroah-Hartman:
> > On Mon, Apr 08, 2013 at 06:04:31PM +0200, Philipp Zabel wrote:
> > > Hi,
> > >
> > > the following patches allow to use the integrated Television En
On Thu, Apr 04, 2013 at 06:56:58PM +0200, Daniel Vetter wrote:
>
> I think for starters we need to have a slightly more interesting example:
>
> 3 threads O, M, Y: O has the oldest ww_age/ticket, Y the youngest, M
> is in between.
> 2 ww_mutexes: A, B
>
> Y has already acquired ww_mutex A, M has
On Tue, Apr 02, 2013 at 06:59:14PM +0200, Peter Zijlstra wrote:
>
> So how about we call the thing something like:
>
> struct ww_mutex; /* wound/wait */
Reading this I can't help but think of Elmer Fudd saying "Round Robin"
as "Wound Wobin"
-- Steve
>
> int mutex_wound_lock(struct ww_mute
On Thu, Apr 04, 2013 at 06:41:02PM +0200, Peter Zijlstra wrote:
> On Thu, 2013-04-04 at 15:31 +0200, Daniel Vetter wrote:
> > The thing is now that you're not expected to hold these locks for a
> > long
> > time - if you need to synchronously stall while holding a lock
> > performance
> > will go d
On Thu, Apr 04, 2013 at 06:38:36PM +0200, Peter Zijlstra wrote:
> On Thu, 2013-04-04 at 15:31 +0200, Daniel Vetter wrote:
> > Hm, I guess your aim with the TASK_DEADLOCK wakeup is to bound the
> > wait
> > times of older task.
>
> No, imagine the following:
>
> struct ww_mutex A, B;
> struct mute
On Tue, Apr 9, 2013 at 8:35 AM, Xiong Zhou wrote:
> From: Xiong Zhou
>
> This patch fixes build failure of v3.9-rc5.
> When config ACPI_VIDEO as m, DRM_GMA500 as y, here comes the failure.
> gma5/600 needs acpi_video just like nouveau.
>
> Failure message:
> drivers/built-in.o: In function `psb_d
It will be only consistent once we've restored all the crtcs. Since a
bunch of other callers also want to just restore a single crtc, add a
boolean to disable checking only where it doesn't make sense.
Note that intel_modeset_setup_hw_state already has a call to
intel_modeset_check_state at the en
---
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130409/fe77f1c3/attachment.html>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130409/69fa2870/attachment.html>
On Mon, Apr 08, 2013 at 06:04:38PM +0200, Philipp Zabel wrote:
> This driver adds support for the Television Encoder integrated
> on i.MX53 SoCs (TVEv2).
>
> Currently only the VGA output mode is supported, which only uses
> the TVDAC to generate RGB levels. HSYNC and VSYNC signals are
> routed di
cause:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130409/49f68ecf/attachment.html>
https://bugs.freedesktop.org/show_bug.cgi?id=57567
--- Comment #31 from Alexandre Demers ---
(In reply to comment #30)
> Created attachment 77706 [details] [review]
> additional fix
>
> Apply this along with attachment 77705 [details] [review].
Using a Cayman 6950 with both patches didn't help
On Tue, Apr 09, 2013 at 03:21:35PM +0200, Richard Cochran wrote:
> On Tue, Apr 09, 2013 at 02:50:03PM +0200, Daniel Vetter wrote:
> >
> > This should be fixed with the above mentioned patch. The issue is that the
> > bios fumbles around with the output configuration behind our backs, so the
> > ne
https://bugs.freedesktop.org/show_bug.cgi?id=62959
--- Comment #28 from Alexandre Demers ---
Marek, you are right and I must have been "lucky" yesterday when I tested it. I
launched two runs, and hit two different hanging tests this time:
glean/polygonOffset (first run)
glean/pointAtten (second r
Hi Tom,
On Tuesday 09 April 2013 12:21:08 Tom Cooksey wrote:
> Hi All,
>
> Last year Laurent posted an RFC patch[i] to add support for exporting an
> fbdev framebuffer through dma_buf. Looking through the mailing list
> archives, it doesn't appear to have progressed beyond an RFC? What would be
>
Am 09.04.2013 16:26, schrieb Alex Deucher:
> On Tue, Apr 9, 2013 at 10:13 AM, Jerome Glisse wrote:
>> On Tue, Apr 9, 2013 at 8:44 AM, Christian K?nig
>> wrote:
>>> From: Christian K?nig
>>>
>>> Add new ioctl option and bumb minor version number.
>>
>> I already have the tiling patch that bump t
On Thu, Apr 04, 2013 at 06:56:58PM +0200, Daniel Vetter wrote:
>
> I think for starters we need to have a slightly more interesting example:
>
> 3 threads O, M, Y: O has the oldest ww_age/ticket, Y the youngest, M
> is in between.
> 2 ww_mutexes: A, B
>
> Y has already acquired ww_mutex A, M has
work around? When is it expected to have a fix for it?
Regards.
--
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/20130409/
On Thu, Apr 04, 2013 at 06:41:02PM +0200, Peter Zijlstra wrote:
> On Thu, 2013-04-04 at 15:31 +0200, Daniel Vetter wrote:
> > The thing is now that you're not expected to hold these locks for a
> > long
> > time - if you need to synchronously stall while holding a lock
> > performance
> > will go d
On Thu, Apr 04, 2013 at 06:38:36PM +0200, Peter Zijlstra wrote:
> On Thu, 2013-04-04 at 15:31 +0200, Daniel Vetter wrote:
> > Hm, I guess your aim with the TASK_DEADLOCK wakeup is to bound the
> > wait
> > times of older task.
>
> No, imagine the following:
>
> struct ww_mutex A, B;
> struct mute
https://bugs.freedesktop.org/show_bug.cgi?id=62959
--- Comment #27 from Alexandre Demers ---
(In reply to comment #26)
> It's not important for this bug if the test fails (I think it does), what's
> important is whether it hangs the machine or not.
That's what I meant. I'm launching a new run in
On Tue, Apr 02, 2013 at 06:59:14PM +0200, Peter Zijlstra wrote:
>
> So how about we call the thing something like:
>
> struct ww_mutex; /* wound/wait */
Reading this I can't help but think of Elmer Fudd saying "Round Robin"
as "Wound Wobin"
-- Steve
>
> int mutex_wound_lock(struct ww_mute
Currently we have a problem with this:
1. i915: create gem object
2. i915: export gem object to prime
3. radeon: import gem object
4. close prime fd
5. radeon: unref object
6. i915: unref object
i915 has an imported object reference in its file priv, that isn't
cleaned up properly until fd close.
Please don't bikeshed this with requirements to fix problems that
are there now anyways. This is the simplest patch to fix an obvious
problem, it doesn't fix all the other problems.
I should have merged this months ago, but people keep wanting a
superpatch to fix everything.
Dave.
__
When userspace calls SET_PLANE ioctl, drm core takes a reference of the fb and
passes control to the update_plane op defined by the drm driver.
In omapdrm, we have a worker thread which queues framebuffers objects received
from update_plane and displays them at the appropriate time.
It is possibl
https://bugs.freedesktop.org/show_bug.cgi?id=62959
--- Comment #26 from Marek Olšák ---
It's not important for this bug if the test fails (I think it does), what's
important is whether it hangs the machine or not.
--
You are receiving this mail because:
You are the assignee for the bug.
___
https://bugs.freedesktop.org/show_bug.cgi?id=62959
--- Comment #25 from Alexandre Demers ---
(In reply to comment #24)
> Alex, I'm sorry but your patch does not fix the lockups on my Cayman (HD
> 6950). :( The piglit test "initialized-fbo" can be used to reproduce the
> lockup.
Are all the previ
Commit 196e077dc165a307efbd9e7569f81bbdbcf18f65
"drm: don't add inferred modes for monitors that don't support them"
It remove the call add_inferred_modes when DRM_EDID_FEATURE_DEFAULT_GTF
in feature support field is zero, this remove all inferred modes
come from GTF or CVT range information, and
https://bugs.freedesktop.org/show_bug.cgi?id=62959
--- Comment #24 from Marek Olšák ---
Alex, I'm sorry but your patch does not fix the lockups on my Cayman (HD 6950).
:( The piglit test "initialized-fbo" can be used to reproduce the lockup.
--
You are receiving this mail because:
You are the a
On Tue, Apr 9, 2013 at 4:26 PM, Maarten Lankhorst
wrote:
> Op 09-04-13 16:16, Jerome Glisse schreef:
>> On Tue, Apr 9, 2013 at 7:37 AM, Maarten Lankhorst
>> wrote:
>>
>>> Signed-off-by: Maarten Lankhorst
>>>
>> Can userspace pin directly ? If so then that sounds as a bad idea.
>>
>> Reviewed-by:
> Hi Linus,
>
> just a spare semicolon in nouveau that caused some issues.
Okay an mgag200 fix I missed is also in there now.
The following changes since commit f011a08c804d50eeff4abf2d308cdce492f015aa:
Merge tag 'for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/sfr/next-fixes (2
Op 09-04-13 16:16, Jerome Glisse schreef:
> On Tue, Apr 9, 2013 at 7:37 AM, Maarten Lankhorst
> wrote:
>
>> Signed-off-by: Maarten Lankhorst
>>
> Can userspace pin directly ? If so then that sounds as a bad idea.
>
> Reviewed-by: Jerome Glisse
>
It's slightly better than before, it used to pin as
On Tue, Apr 09, 2013 at 09:44:46AM +0200, Philipp Zabel wrote:
> Hi Greg,
>
> Am Montag, den 08.04.2013, 10:40 -0700 schrieb Greg Kroah-Hartman:
> > On Mon, Apr 08, 2013 at 06:04:31PM +0200, Philipp Zabel wrote:
> > > Hi,
> > >
> > > the following patches allow to use the integrated Television En
https://bugs.freedesktop.org/show_bug.cgi?id=57567
--- Comment #30 from Alex Deucher ---
Created attachment 77706
--> https://bugs.freedesktop.org/attachment.cgi?id=77706&action=edit
additional fix
Apply this along with attachment 77705.
--
You are receiving this mail because:
You are the as
https://bugs.freedesktop.org/show_bug.cgi?id=57567
Alex Deucher changed:
What|Removed |Added
Attachment #77602|0 |1
is obsolete|
On Tue, Apr 9, 2013 at 3:17 PM, Rob Clark wrote:
>>> diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c
>>> b/drivers/gpu/drm/omapdrm/omap_plane.c
>>> index 2882cda..8d225d7 100644
>>> --- a/drivers/gpu/drm/omapdrm/omap_plane.c
>>> +++ b/drivers/gpu/drm/omapdrm/omap_plane.c
>>> @@ -247,6 +247,12 @
On Tue, Apr 09, 2013 at 02:50:03PM +0200, Daniel Vetter wrote:
>
> This should be fixed with the above mentioned patch. The issue is that the
> bios fumbles around with the output configuration behind our backs, so the
> new paranoid modeset code in 3.7+ freaks out about the state mismatch
> betwe
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130409/ab0fdd60/attachment.html>
Since atm we don't take a reference on the dma buf pointer when we add
it to the import lookup table the dma buf can vanish leaving the stale
pointer behind. This can in turn lead to returning stale GEM handles
when userspace imports a newly exported buffer.
Fix this by keeping a reference on the
In commit be8a42ae60 we inroduced a refcount problem, where on the
drm_gem_prime_fd_to_handle() error path we'll call dma_buf_put() for
self imported dma buffers.
Fix this by taking a reference on the dma buffer in the .gem_import
hook instead of assuming the caller had taken one. Besides fixing t
On Tue, Apr 09, 2013 at 01:37:40PM +0200, Maarten Lankhorst wrote:
> Prevents buffers from being pinned forever.
>
> Signed-off-by: Maarten Lankhorst
Did I mention in my review of Aaron's patch that is feels a bit inflexible
to move the dma_buf vtable to here and has a midlayer touch to it? Look
On Mon, 18 Mar 2013 09:32:51 +0100, Daniel Vetter wrote:
>
> On Sat, Mar 16, 2013 at 01:28:50PM +0100, Richard Cochran wrote:
>>
>> I have an Acer Aspire One netbook, and on it I get the following
>> warning when closing and opening the lid. I think this warning first
>> appeared in 3.7.
>>
>> Does
On Tue, Apr 09, 2013 at 05:56:02PM +0530, Archit Taneja wrote:
> When userspace calls SET_PLANE ioctl, drm core takes a reference of the fb and
> passes control to the update_plane op defined by the drm driver.
>
> In omapdrm, we have a worker thread which queues framebuffers objects received
> fr
> Since atm we don't take a reference on the dma buf pointer when we add
> it to the import lookup table the dma buf can vanish leaving the stale
> pointer behind. This can in turn lead to returning stale GEM handles
> when userspace imports a newly exported buffer.
I sent a bunch of patches to p
On Tue, Apr 09, 2013 at 02:54:34PM +0300, Tomas Melin wrote:
> On Mon, 18 Mar 2013 09:32:51 +0100, Daniel Vetter wrote:
> >
> > On Sat, Mar 16, 2013 at 01:28:50PM +0100, Richard Cochran wrote:
> >>
> >> I have an Acer Aspire One netbook, and on it I get the following
> >> warning when closing and o
From: Christian K?nig
Add new ioctl option and bumb minor version number.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_drv.c |2 +-
drivers/gpu/drm/radeon/radeon_kms.c | 17 +
include/uapi/drm/radeon_drm.h |2 ++
3 files changed, 20 insertion
From: Xiong Zhou
This patch fixes build failure of v3.9-rc5.
When config ACPI_VIDEO as m, DRM_GMA500 as y, here comes the failure.
gma5/600 needs acpi_video just like nouveau.
Failure message:
drivers/built-in.o: In function `psb_driver_load':
kernel-3.9-rc5/drivers/gpu/drm/gma500/psb_drv.c:340:
https://bugs.freedesktop.org/show_bug.cgi?id=63279
--- Comment #5 from Musikolo ---
Hi Tormod,
Thanks once again for your prompt response.
When say "it doesn't work", I mean the screen is scrambled and nothing is
distinguishable. As the telling goes, a picture is worth more than a thousand
word
https://bugs.freedesktop.org/show_bug.cgi?id=63279
--- Comment #4 from Musikolo ---
Created attachment 77694
--> https://bugs.freedesktop.org/attachment.cgi?id=77694&action=edit
My scrambled screen
--
You are receiving this mail because:
You are the assignee for the bug.
_
https://bugs.freedesktop.org/show_bug.cgi?id=63279
--- Comment #3 from Tormod Volden ---
Simply using EXA (and a 1.14 fix backported to 1.13) worked for me. Maybe more
is broken in 1.14. What exactly happens in your case? Please be more specific
than "does not work".
There is no schedule for suc
u 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/20130409/2cd7bb2f/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20130409/0bfb66ba/attachment.html>
Shouldn't happen, and we invert the struct_mutex with reservation here,
potentially leading to deadlocks. Once reservations become lockdep annotated,
lockdep will go splat on this.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/nouveau/nouveau_gem.c | 3 ++-
1 file changed, 2 insertions(+)
Add missing calls, and fix a leak from forgetting to call the unpin function.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/nouveau/nouveau_fbcon.c | 23 ++-
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
b/drive
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/nouveau/nouveau_abi16.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/nouveau/nouveau_abi16.c
b/drivers/gpu/drm/nouveau/nouveau_abi16.c
index 3b6dc88..9750bb9 100644
--- a/drivers/gpu/drm/nouveau/nouveau_abi16.c
+++ b/dri
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 1 +
drivers/gpu/drm/nouveau/nouveau_gem.h | 1 +
drivers/gpu/drm/nouveau/nouveau_prime.c | 9 -
3 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
b/drivers/gpu/drm/nouveau/nouveau_drm.c
ind
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/radeon/radeon_drv.c | 2 ++
drivers/gpu/drm/radeon/radeon_prime.c | 18 ++
2 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
b/drivers/gpu/drm/radeon/radeon_drv.c
index 66a7f
This allows importing bo's to own device to work without requiring that the
buffer is pinned in GART.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_prime.c | 41 ++---
1 file changed, 26 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/
Prevents buffers from being pinned forever.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_prime.c | 13 +++--
include/drm/drmP.h | 1 +
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 366
HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130409/f41dd152/attachment.html>
On Tue, Apr 9, 2013 at 8:35 AM, Xiong Zhou wrote:
> From: Xiong Zhou
>
> This patch fixes build failure of v3.9-rc5.
> When config ACPI_VIDEO as m, DRM_GMA500 as y, here comes the failure.
> gma5/600 needs acpi_video just like nouveau.
>
> Failure message:
> drivers/built-in.o: In function `psb_d
On Tue, Apr 9, 2013 at 1:10 PM, Christian K?nig
wrote:
> Am 09.04.2013 16:26, schrieb Alex Deucher:
>
>> On Tue, Apr 9, 2013 at 10:13 AM, Jerome Glisse wrote:
>>>
>>> On Tue, Apr 9, 2013 at 8:44 AM, Christian K?nig
>>> wrote:
From: Christian K?nig
Add new ioctl option and b
HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130409/959ef6c6/attachment.html>
ktop.org/archives/dri-devel/attachments/20130409/144f7d83/attachment.pgp>
ktop.org/archives/dri-devel/attachments/20130409/2626be5c/attachment.html>
It will be only consistent once we've restored all the crtcs. Since a
bunch of other callers also want to just restore a single crtc, add a
boolean to disable checking only where it doesn't make sense.
Note that intel_modeset_setup_hw_state already has a call to
intel_modeset_check_state at the en
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130409/82cb5565/attachment.html>
Hi All,
Last year Laurent posted an RFC patch[i] to add support for exporting an fbdev
framebuffer through
dma_buf. Looking through the mailing list archives, it doesn't appear to have
progressed beyond an
RFC? What would be needed to get this merged? It would be useful for our Mali
T6xx driver
https://bugs.freedesktop.org/show_bug.cgi?id=63279
--- Comment #2 from Musikolo ---
Hi Tormod,
Thanks for your prompt response and assistance.
I have tried the suggested options, but I'm still having the same issue, no
change at all.
- http://pastebin.com/yAgshj2V
Is there any other work arou
On Tue, Apr 09, 2013 at 03:21:35PM +0200, Richard Cochran wrote:
> On Tue, Apr 09, 2013 at 02:50:03PM +0200, Daniel Vetter wrote:
> >
> > This should be fixed with the above mentioned patch. The issue is that the
> > bios fumbles around with the output configuration behind our backs, so the
> > ne
On Tue, Apr 9, 2013 at 10:13 AM, Jerome Glisse wrote:
>
> On Tue, Apr 9, 2013 at 8:44 AM, Christian K?nig
> wrote:
>>
>> From: Christian K?nig
>>
>> Add new ioctl option and bumb minor version number.
>
>
> I already have the tiling patch that bump the version, but i think it's just
> a matter
On Tue, Apr 9, 2013 at 1:10 PM, Christian König wrote:
> Am 09.04.2013 16:26, schrieb Alex Deucher:
>
>> On Tue, Apr 9, 2013 at 10:13 AM, Jerome Glisse wrote:
>>>
>>> On Tue, Apr 9, 2013 at 8:44 AM, Christian König
>>> wrote:
From: Christian König
Add new ioctl option and bu
> return 0;
> --
> 1.8.2
>
> ___
> 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/20130409/4550f22b/attachment-0001.html>
EON_INFO_MAX_SH_PER_SE 0x13
> +/* query if a RADEON_CS_RING_* submission is supported */
> +#define RADEON_INFO_RING_WORKING 0x14
>
> struct drm_radeon_info {
> uint32_trequest;
> --
> 1.7.9.5
>
> ___
> 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/20130409/99739f55/attachment.html>
Hi Tom,
On Tuesday 09 April 2013 12:21:08 Tom Cooksey wrote:
> Hi All,
>
> Last year Laurent posted an RFC patch[i] to add support for exporting an
> fbdev framebuffer through dma_buf. Looking through the mailing list
> archives, it doesn't appear to have progressed beyond an RFC? What would be
>
Am 09.04.2013 16:26, schrieb Alex Deucher:
On Tue, Apr 9, 2013 at 10:13 AM, Jerome Glisse wrote:
On Tue, Apr 9, 2013 at 8:44 AM, Christian König wrote:
From: Christian König
Add new ioctl option and bumb minor version number.
I already have the tiling patch that bump the version, but i th
On Tue, Apr 09, 2013 at 02:50:03PM +0200, Daniel Vetter wrote:
>
> This should be fixed with the above mentioned patch. The issue is that the
> bios fumbles around with the output configuration behind our backs, so the
> new paranoid modeset code in 3.7+ freaks out about the state mismatch
> betwe
On Mon, 18 Mar 2013 09:32:51 +0100, Daniel Vetter wrote:
>
> On Sat, Mar 16, 2013 at 01:28:50PM +0100, Richard Cochran wrote:
>>
>> I have an Acer Aspire One netbook, and on it I get the following
>> warning when closing and opening the lid. I think this warning first
>> appeared in 3.7.
>>
>> Does
Commit 196e077dc165a307efbd9e7569f81bbdbcf18f65
"drm: don't add inferred modes for monitors that don't support them"
It remove the call add_inferred_modes when DRM_EDID_FEATURE_DEFAULT_GTF
in feature support field is zero, this remove all inferred modes
come from GTF or CVT range information, and
From: Xiong Zhou
This patch fixes build failure of v3.9-rc5.
When config ACPI_VIDEO as m, DRM_GMA500 as y, here comes the failure.
gma5/600 needs acpi_video just like nouveau.
Failure message:
drivers/built-in.o: In function `psb_driver_load':
kernel-3.9-rc5/drivers/gpu/drm/gma500/psb_drv.c:340:
Hi Greg,
Am Montag, den 08.04.2013, 10:40 -0700 schrieb Greg Kroah-Hartman:
> On Mon, Apr 08, 2013 at 06:04:31PM +0200, Philipp Zabel wrote:
> > Hi,
> >
> > the following patches allow to use the integrated Television Encoder
> > (TVEv2) on the i.MX53 SoC as VGA output encoder for the IPU. This i
:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130409/5b234fcf/attachment-0001.html>
On Mon, 2013-04-08 at 13:37 -0400, j.glisse at gmail.com wrote:
> From: Jerome Glisse
>
> Signed-off-by: Jerome Glisse
For the series:
Reviewed-by: Michel D?nzer
--
Earthling Michel D?nzer | http://www.amd.com
Libre software enthusiast | Debian
On Tue, Apr 9, 2013 at 8:53 AM, Daniel Vetter wrote:
> On Tue, Apr 09, 2013 at 05:56:02PM +0530, Archit Taneja wrote:
>> When userspace calls SET_PLANE ioctl, drm core takes a reference of the fb
>> and
>> passes control to the update_plane op defined by the drm driver.
>>
>> In omapdrm, we have
(drm->fence && nouveau_fence(drm)->suspend) {
> if (!nouveau_fence(drm)->suspend(drm))
> return -ENOMEM;
>
> ___
> 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/20130409/711f4be4/attachment.html>
Op 09-04-13 01:14, Ben Skeggs schreef:
> On Mon, Apr 8, 2013 at 10:04 PM, Maarten Lankhorst <
> maarten.lankhorst at canonical.com> wrote:
>
>> Seems to make suspend slightly more reliable on my system.
>>
> NACK.
>
> "Seems to", and "slightly" don't make a very good argument for this.
> Likely al
On Tue, Apr 9, 2013 at 8:26 AM, Archit Taneja wrote:
> When userspace calls SET_PLANE ioctl, drm core takes a reference of the fb and
> passes control to the update_plane op defined by the drm driver.
>
> In omapdrm, we have a worker thread which queues framebuffers objects received
> from update_
https://bugs.freedesktop.org/show_bug.cgi?id=62997
--- Comment #9 from udo ---
3.8.6 with and without patch had crashes of various kind. (hard freeze even!)
Now doing 3.8.5 without patch, waiting for the raid check to complete.
--
You are receiving this mail because:
You are the assignee for th
Hi Linus,
just a spare semicolon in nouveau that caused some issues.
Dave.
The following changes since commit f011a08c804d50eeff4abf2d308cdce492f015aa:
Merge tag 'for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/sfr/next-fixes (2013-04-08
16:10:43 -0700)
are available in the gi
On Tue, Apr 9, 2013 at 4:26 PM, Maarten Lankhorst
wrote:
> Op 09-04-13 16:16, Jerome Glisse schreef:
>> On Tue, Apr 9, 2013 at 7:37 AM, Maarten Lankhorst
>> wrote:
>>
>>> Signed-off-by: Maarten Lankhorst
>>>
>> Can userspace pin directly ? If so then that sounds as a bad idea.
>>
>> Reviewed-by:
Op 09-04-13 16:16, Jerome Glisse schreef:
> On Tue, Apr 9, 2013 at 7:37 AM, Maarten Lankhorst
> wrote:
>
>> Signed-off-by: Maarten Lankhorst
>>
> Can userspace pin directly ? If so then that sounds as a bad idea.
>
> Reviewed-by: Jerome Glisse
>
It's slightly better than before, it used to pin as
On Tue, Apr 9, 2013 at 10:13 AM, Jerome Glisse wrote:
>
> On Tue, Apr 9, 2013 at 8:44 AM, Christian König
> wrote:
>>
>> From: Christian König
>>
>> Add new ioctl option and bumb minor version number.
>
>
> I already have the tiling patch that bump the version, but i think it's just
> a matter
On Tue, Apr 9, 2013 at 7:37 AM, Maarten Lankhorst
wrote:
> Signed-off-by: Maarten Lankhorst
>
Can userspace pin directly ? If so then that sounds as a bad idea.
Reviewed-by: Jerome Glisse
> ---
> drivers/gpu/drm/radeon/radeon_drv.c | 2 ++
> drivers/gpu/drm/radeon/radeon_prime.c | 18 +++
On Tue, Apr 9, 2013 at 8:44 AM, Christian König wrote:
> From: Christian König
>
> Add new ioctl option and bumb minor version number.
>
I already have the tiling patch that bump the version, but i think it's
just a matter for Alex.
Reviewed-by: Jerome Glisse
>
> Signed-off-by: Christian Kön
https://bugs.freedesktop.org/show_bug.cgi?id=63090
Christian König changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On Tue, Apr 9, 2013 at 3:17 PM, Rob Clark wrote:
>>> diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c
>>> b/drivers/gpu/drm/omapdrm/omap_plane.c
>>> index 2882cda..8d225d7 100644
>>> --- a/drivers/gpu/drm/omapdrm/omap_plane.c
>>> +++ b/drivers/gpu/drm/omapdrm/omap_plane.c
>>> @@ -247,6 +247,12 @
https://bugs.freedesktop.org/show_bug.cgi?id=62997
--- Comment #8 from udo ---
Will start testing on 3.8.6 in a few minutes.
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedeskt
1 - 100 of 147 matches
Mail list logo
