On Tue, 2013-04-09 at 18:42 -0400, Steven Rostedt wrote:
> What about setting an age as soon as it starts the process
> of grabbing one of these locks? And it keeps the age until it
> successfully grabs and releases all the locks again. It wont reset if
> it
> had to drop the locks and start over.
Am Montag, den 08.04.2013, 13:37 -0400 schrieb j.gli...@gmail.com:
> From: Jerome Glisse
Could you add the commit adding these definitions to the commit message,
please?
> Signed-off-by: Jerome Glisse
> ---
> include/drm/radeon_drm.h | 61
>
>
On Wed, Apr 10, 2013 at 12:27 AM, Steven Rostedt wrote:
> 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,
drm_framebuffer_lookup() does a kref_get() for the framebuffer if it finds one
corresponding to the fb id passed to it. Use drm_framebuffer_reference() instead
for clarity since it's the function used in other places to take a reference.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/drm_crtc.
On Wed, Apr 10, 2013 at 02:29:39PM +0530, Archit Taneja wrote:
> drm_framebuffer_lookup() does a kref_get() for the framebuffer if it finds one
> corresponding to the fb id passed to it. Use drm_framebuffer_reference()
> instead
> for clarity since it's the function used in other places to take a
On Tue, Apr 09, 2013 at 06:28:08PM -0400, Steven Rostedt wrote:
> 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
On Mon, Apr 08, 2013 at 01:50:26PM +0200, Daniel Vetter wrote:
> On Mon, Apr 08, 2013 at 12:39:24PM +0200, Peter Zijlstra wrote:
> > On Thu, 2013-04-04 at 18:56 +0200, Daniel Vetter wrote:
> > > Presuming I'm still following we should be able to fix this with the
> > > new sleep state TASK_DEADLOCK
On Wed, Apr 10, 2013 at 01:59:02PM +0200, Richard Cochran wrote:
> On Tue, Apr 09, 2013 at 09:51:30PM +0200, Daniel Vetter wrote:
> > 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 disabl
Hi Dave,
On 2013-03-13 10:57, Tomi Valkeinen wrote:
> Hi Dave,
>
> I'm writing this mail to get some ideas how we should manage OMAP's
> display drivers in the future.
>
> As a short intro, we have the following players around:
>
> omapdss - omapdss handles the DSS (display subsystem) hardware.
On Tue, 9 Apr 2013, Patrik Jakobsson wrote:
> 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.
>
On Tue, Apr 09, 2013 at 09:51:30PM +0200, Daniel Vetter wrote:
> 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
From: Xiong Zhou
Last version of this patch is not clear enough and X86 duplicated.
This patch fixes build failure of v3.9-rc5 and rc6.
When config ACPI_VIDEO as m, DRM_GMA500 as y, here comes the failure.
GMA5/600 needs acpi_video just like nouveau.
And some tab type fix by the way.
Failure me
https://bugs.freedesktop.org/show_bug.cgi?id=62959
--- Comment #29 from Alex Deucher ---
Do either of Jerome's patches help?
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedeskt
https://bugs.freedesktop.org/show_bug.cgi?id=62959
--- Comment #30 from Alexandre Demers ---
(In reply to comment #29)
> Do either of Jerome's patches help?
Didn't have time to test them yesterday, I'll try them probably at the end of
the day.
--
You are receiving this mail because:
You are th
https://bugs.freedesktop.org/show_bug.cgi?id=57567
--- Comment #32 from Alex Deucher ---
Created attachment 77743
--> https://bugs.freedesktop.org/attachment.cgi?id=77743&action=edit
additional fix
Try this one in addition to the previous two (apply all 3).
--
You are receiving this mail bec
https://bugs.freedesktop.org/show_bug.cgi?id=57567
--- Comment #33 from Vladimir ---
Tried all three patches, still same, shifted after 3.8-ati reboot.
and same as 3.8 after cold start.
btw, am I supposed to apply it against 3.9-rc5 or 3.9-rc6, or it doesn't matter
?
--
You are receiving this
https://bugs.freedesktop.org/show_bug.cgi?id=57567
--- Comment #34 from Alex Deucher ---
(In reply to comment #33)
> btw, am I supposed to apply it against 3.9-rc5 or 3.9-rc6, or it doesn't
> matter ?
Doesn't matter.
--
You are receiving this mail because:
You are the assignee for the bug.
___
https://bugs.freedesktop.org/show_bug.cgi?id=57567
--- Comment #35 from Alex Deucher ---
Are there any "frame never updated!" messages in your dmesg with the patches
applied?
--
You are receiving this mail because:
You are the assignee for the bug.
__
On Wed, Apr 10, 2013 at 2:37 PM, Xiong Zhou wrote:
> From: Xiong Zhou
>
> Last version of this patch is not clear enough and X86 duplicated.
>
> This patch fixes build failure of v3.9-rc5 and rc6.
> When config ACPI_VIDEO as m, DRM_GMA500 as y, here comes the failure.
> GMA5/600 needs acpi_video
https://bugs.freedesktop.org/show_bug.cgi?id=57567
--- Comment #36 from Vladimir ---
Created attachment 77761
--> https://bugs.freedesktop.org/attachment.cgi?id=77761&action=edit
dmesg with 3 patches
Looks like there is none.
dmesg from boot with sshifted screen.
--
You are receiving this m
https://bugs.freedesktop.org/show_bug.cgi?id=57567
--- Comment #37 from Alex Deucher ---
When the display is shifted, does a dpms cycle fix it?
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-de
This is what's in store for gma500 and to be included in drm-next. I'd greatly
appreciate review of these patches (and testing if possible). Most of them are
cleanups and the rest are fixes and features for restoring our state after
suspend / hibernate. There still seems to be issues with hibernati
From: Wang YanQing
commit f9f23a77f07506a32d9dc1d925bf85c0e7507b66(gma500: remove no_fb bits)
remove all the drm_psb_no_fb relations code in gma500 except this line code,
so remove it also.
Signed-off-by: Wang YanQing
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/gma500/psb_drv.h |1
From: Alexandru Gheorghiu
Replaced calls kzalloc followed by memcpy with call to kmemdup.
Patch found using coccinelle.
Signed-off-by: Alexandru Gheorghiu
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/gma500/intel_bios.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff -
From: Syam Sidhardhan
The use of pointer sender should be after the NULL check.
Signed-off-by: Syam Sidhardhan
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/gma500/mdfld_dsi_output.c |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/gma500/mdf
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/gma500/psb_intel_display.c | 54 ++--
1 file changed, 2 insertions(+), 52 deletions(-)
diff --git a/drivers/gpu/drm/gma500/psb_intel_display.c
b/drivers/gpu/drm/gma500/psb_intel_display.c
index 9edb190..414df48 100644
i9xx_clock() and i8xx_clock() did the same calc and psb_intel_clock() just
called i9xx_clock() so just move it all into psb_intel_clock().
The same calculation is duplicated in cdv_intel_display.c as well so maybe we
can share it later on.
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/gma
This makes it easier to read. We do the same for cdv so it becomes more
consistent as well.
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/gma500/psb_intel_display.c | 66 +---
1 file changed, 20 insertions(+), 46 deletions(-)
diff --git a/drivers/gpu/drm/gma500/p
psb_intel_crtc_gamma_set() and psb_intel_crtc_destroy() aren't used outside of
psb_intel_display.c right now so no need to expose them.
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/gma500/psb_intel_display.c |4 ++--
drivers/gpu/drm/gma500/psb_intel_display.h |3 ---
2 files chang
Remove unused defines that we'll never use and fix naming in some include guards
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/gma500/intel_bios.h|6 +++---
drivers/gpu/drm/gma500/psb_intel_display.c |2 --
drivers/gpu/drm/gma500/psb_intel_drv.h |8
drivers
From: Kero van Gelder
Both VGA and HDMI connectors are available on my Asus EeePC X101CH.
This patch will cause output to be shown on either when plugged in.
For both, it shows the leftmost 800x600, of the 1024x600 on LVDS.
Signed-off-by: Kero van Gelder
Signed-off-by: Patrik Jakobsson
---
dr
By having 'drm' and 'fb' in the fb screeninfo id, pm-utils will leave us
alone. Otherwise we'll have quirks up to our ears and resume will break.
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/gma500/framebuffer.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/driver
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/gma500/gtt.c | 45 ++
drivers/gpu/drm/gma500/gtt.h |2 +-
2 files changed, 38 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/gma500/gtt.c b/drivers/gpu/drm/gma500/gtt.c
index 04a371a..2f
This patch activates the rebuilding of the gtt. Currently we reinitialize the
gtt by inserting the stolen pages again and map the rest to our scratch page.
Then we go about restoring the needed ranges. This is a bit overkill but right
now we don't have that much to restore so better safe than sorry
Currently we do whatever is done during suspend/resume but we might need some
more work for hibernation so keep them in separate functions.
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/gma500/power.c | 15 +++
drivers/gpu/drm/gma500/power.h |3 +++
drivers/gpu/drm/gm
The state of the SDVO chip is more difficult to save than the LVDS so we do a
full mode set on the crtc to get SDVO operational again. The SDVOB/C register is
also stored just in case we have special bits set in the future.
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/gma500/psb_intel_sdv
From: Xiong Zhou
Last version of this patch is not clear enough and X86 duplicated.
This patch fixes build failure of v3.9-rc5 and rc6.
When config ACPI_VIDEO as m, DRM_GMA500 as y, here comes the failure.
GMA5/600 needs acpi_video just like nouveau.
And some tab type fix by the way.
Failure me
https://bugs.freedesktop.org/show_bug.cgi?id=57567
--- Comment #38 from Vladimir ---
How to do dpms cycle ?
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lis
https://bugs.freedesktop.org/show_bug.cgi?id=57567
--- Comment #39 from Alex Deucher ---
(In reply to comment #38)
> How to do dpms cycle ?
On the console, just wait for the screen to blank. In X:
xset dpms force off
will force a dpms cycle.
--
You are receiving this mail because:
You are the
https://bugs.freedesktop.org/show_bug.cgi?id=63396
Priority: medium
Bug ID: 63396
Assignee: dri-devel@lists.freedesktop.org
Summary: Xorg crashes in radeon_get_pixmap_bo on exporting
graph at 1200 dpi in Mathematica
Severity:
https://bugs.freedesktop.org/show_bug.cgi?id=63396
--- Comment #1 from aux...@gmail.com ---
Created attachment 77766
--> https://bugs.freedesktop.org/attachment.cgi?id=77766&action=edit
Xorg.log
--
You are receiving this mail because:
You are the assignee for the bug.
_
https://bugs.freedesktop.org/show_bug.cgi?id=63396
--- Comment #2 from aux...@gmail.com ---
There might be some connection, other than the way of triggering, with bug
63393.
--
You are receiving this mail because:
You are the assignee for the bug.
___
https://bugs.freedesktop.org/show_bug.cgi?id=57567
--- Comment #40 from Alexandre Demers ---
(In reply to comment #39)
> (In reply to comment #38)
> > How to do dpms cycle ?
>
> On the console, just wait for the screen to blank. In X:
> xset dpms force off
> will force a dpms cycle.
That would
On Wed, Apr 10, 2013 at 7:27 PM, Richard Cochran
wrote:
> On Wed, Apr 10, 2013 at 02:07:24PM +0200, Daniel Vetter wrote:
>>
>> It's written against drm-intel-next-queued at
>>
>> http://cgit.freedesktop.org/~danvet/drm-intel
>>
>> I've thought that it should apply pretty cleanly against older kern
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
https://bugs.freedesktop.org/show_bug.cgi?id=57567
--- Comment #41 from Alex Deucher ---
(In reply to comment #40)
> (In reply to comment #39)
> > (In reply to comment #38)
> > > How to do dpms cycle ?
> >
> > On the console, just wait for the screen to blank. In X:
> > xset dpms force off
> >
https://bugs.freedesktop.org/show_bug.cgi?id=57567
--- Comment #42 from Alexandre Demers ---
(In reply to comment #41)
> (In reply to comment #40)
> > (In reply to comment #39)
> > > (In reply to comment #38)
> > > > How to do dpms cycle ?
> > >
> > > On the console, just wait for the screen to
https://bugs.freedesktop.org/show_bug.cgi?id=57567
--- Comment #43 from Vladimir ---
Exactly same happens here
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://
https://bugs.freedesktop.org/show_bug.cgi?id=57919
--- Comment #14 from Thilo Cestonaro ---
Sadly I must say, that this patch changes the behave in no way, too. :( ...
It's still flickering and showing theses glitches as in the video.
Could I add any debug output, any printks which would help t
https://bugs.freedesktop.org/show_bug.cgi?id=57567
--- Comment #44 from Alex Deucher ---
Does disabling acceleration help?
Option "NoAccel" "True"
In the device section of you xorg.conf
--
You are receiving this mail because:
You are the assignee for the bug.
_
https://bugs.freedesktop.org/show_bug.cgi?id=57919
--- Comment #15 from Thilo Cestonaro ---
The first is already part of the kernel, so it's the kernel + the second patch.
Greetings
Thilo
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=57567
--- Comment #45 from Alexandre Demers ---
(In reply to comment #44)
> Does disabling acceleration help?
>
> Option "NoAccel" "True"
>
> In the device section of you xorg.conf
I was able to log in, launch "xset dpms force off". My screen turned
From: Jerome Glisse
v2: sync with radeon-next tree for 3.10
http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.10-wip
Signed-off-by: Jerome Glisse
---
include/drm/radeon_drm.h | 81
1 file changed, 81 insertions(+)
diff --git a/include
From: Jerome Glisse
v2: Only writte tile index if flags for it is set
v3: Remove useless allow2d scanout flags
v4: Split radeon_drm.h update to its own patch
v5: update against lastest next tree for radeon
Signed-off-by: Jerome Glisse
---
radeon/radeon_surface.c | 658 +
https://bugs.freedesktop.org/show_bug.cgi?id=62959
--- Comment #31 from Alexandre Demers ---
(In reply to comment #29)
> Do either of Jerome's patches help?
Applied both, ran 2 times r600.test and everything went fine. I'll test with
only one patch applied at a time later today.
--
You are rec
https://bugs.freedesktop.org/show_bug.cgi?id=62959
--- Comment #32 from Marek Olšák ---
Attachment 77608 fixes the lockups, which suggests the DRM driver doesn't
actually flush caches when it should.
--
You are receiving this mail because:
You are the assignee for the bug.
_
On Wed, Apr 10, 2013 at 02:07:24PM +0200, Daniel Vetter wrote:
>
> It's written against drm-intel-next-queued at
>
> http://cgit.freedesktop.org/~danvet/drm-intel
>
> I've thought that it should apply pretty cleanly against older kernels,
> too. Apparently it conflicts a bit in intel_modeset_set
On Tue, Apr 9, 2013 at 10:51 PM, Daniel Vetter wrote:
> v2: Try harder not to create a big patch (Chris).
>
Tested the patch applied to 3.9-rc6. Atleast on my machine that
helped, although once I managed to get the error (but not warning and
call trace as before):
[drm:i9xx_crtc_mode_set] *ERROR*
On Wed, Apr 10, 2013 at 9:32 PM, Tomas Melin wrote:
> On Tue, Apr 9, 2013 at 10:51 PM, Daniel Vetter wrote:
>> v2: Try harder not to create a big patch (Chris).
>>
> Tested the patch applied to 3.9-rc6. Atleast on my machine that
> helped, although once I managed to get the error (but not warning
> 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
> 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
ts.freedesktop.org/archives/dri-devel/attachments/20130410/137ba3dd/attachment.html>
or the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130410/79738ad4/attachment.html>
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.
#x27;m launching a new run in a moment.
--
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/20130410/3c640add/attachment.html>
en (second 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/20130410/d5c4e076/attachment.html>
nt was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130410/3f27c46e/attachment.html>
On Tue, 2013-04-09 at 18:42 -0400, Steven Rostedt wrote:
> What about setting an age as soon as it starts the process
> of grabbing one of these locks? And it keeps the age until it
> successfully grabs and releases all the locks again. It wont reset if
> it
> had to drop the locks and start over.
On Wed, Apr 10, 2013 at 12:27 AM, Steven Rostedt wrote:
> 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,
drm_framebuffer_lookup() does a kref_get() for the framebuffer if it finds one
corresponding to the fb id passed to it. Use drm_framebuffer_reference() instead
for clarity since it's the function used in other places to take a reference.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/drm_crtc.
On Wed, Apr 10, 2013 at 02:29:39PM +0530, Archit Taneja wrote:
> drm_framebuffer_lookup() does a kref_get() for the framebuffer if it finds one
> corresponding to the fb id passed to it. Use drm_framebuffer_reference()
> instead
> for clarity since it's the function used in other places to take a
On Tue, Apr 09, 2013 at 06:28:08PM -0400, Steven Rostedt wrote:
> 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
On Mon, Apr 08, 2013 at 01:50:26PM +0200, Daniel Vetter wrote:
> On Mon, Apr 08, 2013 at 12:39:24PM +0200, Peter Zijlstra wrote:
> > On Thu, 2013-04-04 at 18:56 +0200, Daniel Vetter wrote:
> > > Presuming I'm still following we should be able to fix this with the
> > > new sleep state TASK_DEADLOCK
On Wed, Apr 10, 2013 at 01:59:02PM +0200, Richard Cochran wrote:
> On Tue, Apr 09, 2013 at 09:51:30PM +0200, Daniel Vetter wrote:
> > 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 disabl
patches via fbdev tree, if that's
better. There aren't too many of them for 3.10.
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130410/52857bed/attachment.pgp>
On Tue, 9 Apr 2013, Patrik Jakobsson wrote:
> 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.
>
On Tue, Apr 09, 2013 at 09:51:30PM +0200, Daniel Vetter wrote:
> 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
From: Xiong Zhou
Last version of this patch is not clear enough and X86 duplicated.
This patch fixes build failure of v3.9-rc5 and rc6.
When config ACPI_VIDEO as m, DRM_GMA500 as y, here comes the failure.
GMA5/600 needs acpi_video just like nouveau.
And some tab type fix by the way.
Failure me
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130410/2e08e7d2/attachment.html>
l because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130410/252a806c/attachment-0001.html>
is 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/20130410/76851605/attachment.html>
iving 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/20130410/4f67565c/attachment.html>
gnee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130410/ac75bfba/attachment.html>
---
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130410/a12de0af/attachment.html>
On Wed, Apr 10, 2013 at 2:37 PM, Xiong Zhou wrote:
> From: Xiong Zhou
>
> Last version of this patch is not clear enough and X86 duplicated.
>
> This patch fixes build failure of v3.9-rc5 and rc6.
> When config ACPI_VIDEO as m, DRM_GMA500 as y, here comes the failure.
> GMA5/600 needs acpi_video
ng 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/20130410/61f7f9bd/attachment.html>
...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130410/6acff822/attachment.html>
This is what's in store for gma500 and to be included in drm-next. I'd greatly
appreciate review of these patches (and testing if possible). Most of them are
cleanups and the rest are fixes and features for restoring our state after
suspend / hibernate. There still seems to be issues with hibernati
From: Wang YanQing
commit f9f23a77f07506a32d9dc1d925bf85c0e7507b66(gma500: remove no_fb bits)
remove all the drm_psb_no_fb relations code in gma500 except this line code,
so remove it also.
Signed-off-by: Wang YanQing
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/gma500/psb_drv.h |1
From: Alexandru Gheorghiu
Replaced calls kzalloc followed by memcpy with call to kmemdup.
Patch found using coccinelle.
Signed-off-by: Alexandru Gheorghiu
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/gma500/intel_bios.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff -
From: Syam Sidhardhan
The use of pointer sender should be after the NULL check.
Signed-off-by: Syam Sidhardhan
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/gma500/mdfld_dsi_output.c |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/gma500/mdf
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/gma500/psb_intel_display.c | 54 ++--
1 file changed, 2 insertions(+), 52 deletions(-)
diff --git a/drivers/gpu/drm/gma500/psb_intel_display.c
b/drivers/gpu/drm/gma500/psb_intel_display.c
index 9edb190..414df48 100644
i9xx_clock() and i8xx_clock() did the same calc and psb_intel_clock() just
called i9xx_clock() so just move it all into psb_intel_clock().
The same calculation is duplicated in cdv_intel_display.c as well so maybe we
can share it later on.
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/gma
This makes it easier to read. We do the same for cdv so it becomes more
consistent as well.
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/gma500/psb_intel_display.c | 66 +---
1 file changed, 20 insertions(+), 46 deletions(-)
diff --git a/drivers/gpu/drm/gma500/p
psb_intel_crtc_gamma_set() and psb_intel_crtc_destroy() aren't used outside of
psb_intel_display.c right now so no need to expose them.
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/gma500/psb_intel_display.c |4 ++--
drivers/gpu/drm/gma500/psb_intel_display.h |3 ---
2 files chang
Remove unused defines that we'll never use and fix naming in some include guards
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/gma500/intel_bios.h|6 +++---
drivers/gpu/drm/gma500/psb_intel_display.c |2 --
drivers/gpu/drm/gma500/psb_intel_drv.h |8
drivers
From: Kero van Gelder
Both VGA and HDMI connectors are available on my Asus EeePC X101CH.
This patch will cause output to be shown on either when plugged in.
For both, it shows the leftmost 800x600, of the 1024x600 on LVDS.
Signed-off-by: Kero van Gelder
Signed-off-by: Patrik Jakobsson
---
dr
By having 'drm' and 'fb' in the fb screeninfo id, pm-utils will leave us
alone. Otherwise we'll have quirks up to our ears and resume will break.
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/gma500/framebuffer.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/driver
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/gma500/gtt.c | 45 ++
drivers/gpu/drm/gma500/gtt.h |2 +-
2 files changed, 38 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/gma500/gtt.c b/drivers/gpu/drm/gma500/gtt.c
index 04a371a..2f
1 - 100 of 124 matches
Mail list logo
