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 Mon, 2013-04-08 at 13:37 -0400, j.gli...@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, X
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
https://bugs.freedesktop.org/show_bug.cgi?id=26891
--- Comment #61 from Ludovic Watteaux ---
Work again on Linux 3.9.0-rc6 without patch.
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@li
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
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
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/
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
---
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/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
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
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(+)
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
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=26891
Alex Deucher changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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_
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
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
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
https://bugs.freedesktop.org/show_bug.cgi?id=62959
--- Comment #23 from Alex Deucher ---
(In reply to comment #22)
> It seems running kernel 3.9-rc6 with attachment 72794 [details] [review]
> with latest mesa (UMAD fixed on Cayman, thanks to commit pushed by Marek)
> allowed me to run all r600 pi
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, 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
https://bugs.freedesktop.org/show_bug.cgi?id=62997
--- Comment #7 from Alex Deucher ---
This may be related to bug 62959. Does attachment 72794 (kernel patch) fix the
issue?
--
You are receiving this mail because:
You are the assignee for the bug.
__
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
https://bugs.freedesktop.org/show_bug.cgi?id=63090
--- Comment #1 from ryszardz...@yahoo.com ---
I have same platform as Arkadiusz [E-350] and I can confirm his results of 53
frames/s.
software used:
Kernel 3.9-rc6 + drm uvd patches
libdrm Git 08.04.2013
xorg-server 1.13.3
Mesa Git 08.04.2013 +
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
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=63090
Christian König changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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
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 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
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 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:
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
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:
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
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 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
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
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
>
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
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=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
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
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
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
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 #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
> 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
https://bugs.freedesktop.org/show_bug.cgi?id=57567
Alex Deucher changed:
What|Removed |Added
Attachment #77602|0 |1
is obsolete|
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
> 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
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
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
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.
___
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.
__
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.
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
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
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 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 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 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: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 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
(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>
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/5037c893/attachment.html>
ceiving 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/98e9f20d/attachment-0001.html>
t; test now.
--
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/8aec4514/attachment.html>
d
relaunch the piglit run.
--
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/a8266236/attachment.html>
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/3398fa7e/attachment.html>
It is better to remove "occured" from messages.
Signed-off-by: Masanari Iida
---
drivers/gpu/drm/exynos/exynos_drm_gsc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
index 7841c3b..898b3
https://bugzilla.kernel.org/show_bug.cgi?id=10319
Zhang Rui changed:
What|Removed |Added
Blocks||56331
--
Configure bugmail: https://bugz
https://bugzilla.kernel.org/show_bug.cgi?id=12434
Zhang Rui changed:
What|Removed |Added
Blocks||56331
--
Configure bugmail: https://bugz
https://bugzilla.kernel.org/show_bug.cgi?id=12778
yury changed:
What|Removed |Added
Status|NEEDINFO|CLOSED
Resolution|
https://bugzilla.kernel.org/show_bug.cgi?id=13170
Zhang Rui changed:
What|Removed |Added
Blocks||56331
--
Configure bugmail: https://bugz
https://bugzilla.kernel.org/show_bug.cgi?id=13446
Zhang Rui changed:
What|Removed |Added
Blocks||56331
--
Configure bugmail: https://bugz
https://bugzilla.kernel.org/show_bug.cgi?id=13880
Zhang Rui changed:
What|Removed |Added
Blocks||56331
--
Configure bugmail: https://bugz
https://bugzilla.kernel.org/show_bug.cgi?id=14993
Zhang Rui changed:
What|Removed |Added
Blocks||56331
--
Configure bugmail: https://bugz
https://bugzilla.kernel.org/show_bug.cgi?id=15120
Zhang Rui changed:
What|Removed |Added
Blocks||56331
--
Configure bugmail: https://bugz
https://bugzilla.kernel.org/show_bug.cgi?id=16560
Zhang Rui changed:
What|Removed |Added
Blocks||56331
--
Configure bugmail: https://bugz
https://bugzilla.kernel.org/show_bug.cgi?id=20432
Zhang Rui changed:
What|Removed |Added
Blocks||56331
--
Configure bugmail: https://bugz
https://bugzilla.kernel.org/show_bug.cgi?id=21002
Zhang Rui changed:
What|Removed |Added
Blocks||56331
--
Configure bugmail: https://bugz
https://bugzilla.kernel.org/show_bug.cgi?id=22022
Zhang Rui changed:
What|Removed |Added
Blocks||56331
--
Configure bugmail: https://bugz
https://bugzilla.kernel.org/show_bug.cgi?id=42627
Zhang Rui changed:
What|Removed |Added
Blocks||56331
--
Configure bugmail: https://bugz
https://bugzilla.kernel.org/show_bug.cgi?id=43276
Zhang Rui changed:
What|Removed |Added
Blocks||56331
--
Configure bugmail: https://bugz
https://bugzilla.kernel.org/show_bug.cgi?id=43741
Zhang Rui changed:
What|Removed |Added
Blocks||56331
--
Configure bugmail: https://bugz
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
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 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
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>
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
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
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/
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
---
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/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
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
1 - 100 of 147 matches
Mail list logo
