On Wed, Jul 17, 2013 at 09:44:00PM +, Deucher, Alexander wrote:
>> -Original Message-
>> From: Anthoine Bourgeois [mailto:anthoine.bourgeois at gmail.com]
>> Sent: Wednesday, July 17, 2013 5:23 PM
>> To: Deucher, Alexander; Koenig, Christian; Jerome Glisse
>> Cc: dri-devel at lists.free
On Wed, Jul 17, 2013 at 08:54:33PM +, Deucher, Alexander wrote:
>Good catch, I screwed up the ref divider calculation. How about the attached
>patch?
It works too. But here was my logic, tell me if I'm wrong:
The output frequency of the PLL is equal to the VCO frequency (FVCO)
divided by th
From: Matthew Garrett
We have to call acpi_video_init_brightness() even if we're not going
to initialise the backlight - Thinkpads seem to use this as the
trigger for enabling ACPI notifications rather than handling it in
firmware.
[rjw: Drop the brightness object created by
acpi_video_init_bri
From: Aaron Lu
Expose acpi_gbl_osi_data so that code outside of ACPICA can check
the value of the last successfull _OSI call. The definitions for
OSI versions are moved to actypes.h so that other components can
access them too.
Based on a patch from Matthew Garrett which in turn was based on
an
On Wed, Jul 17, 2013 at 09:44:00PM +, Deucher, Alexander wrote:
-Original Message-
From: Anthoine Bourgeois [mailto:anthoine.bourge...@gmail.com]
Sent: Wednesday, July 17, 2013 5:23 PM
To: Deucher, Alexander; Koenig, Christian; Jerome Glisse
Cc: dri-devel@lists.freedesktop.org
Subject
On Wed, Jul 17, 2013 at 08:54:33PM +, Deucher, Alexander wrote:
Good catch, I screwed up the ref divider calculation. How about the attached
patch?
It works too. But here was my logic, tell me if I'm wrong:
The output frequency of the PLL is equal to the VCO frequency (FVCO)
divided by t
This allows you to look at the current DPM state via
debugfs.
Due to the way the hardware works on these asics, there's
no way to look up exactly what power state we are in, so
we make the best guess we can based on the current sclk.
v2: fix sclk equation
Signed-off-by: Alex Deucher
Signed-off
On mer., 2013-07-17 at 10:51 -0500, Felipe Contreras wrote:
> On Sat, Jun 22, 2013 at 4:46 PM, Yves-Alexis Perez wrote:
> > Before Linux support for acpi_osi("Windows 2012") (and when booting with
> > acpi_osi="!Windows 2012"), brightness keys were handled by the kernel
> > just fine, whether in c
On Wed, 17 Jul 2013 11:50:11 -0600
Daniel Drake wrote:
> I am now facing a problem with i2c/TDA998x which Russell already noted:
>
> http://lists.freedesktop.org/archives/dri-devel/2013-June/039632.html
>What *can't* be done without a rewrite of the DRM slave encoder backend
>is to have
the
mean time, here is my work in progress. I'm still reading and
learning, so please don't do any detailed reviews yet :)
http://dev.laptop.org/~dsd/20130717/0001-dove-clk-dt-wip.patch
It includes the previous clock selection patch as this stuff is quite
closely bound with
On Wed, 2013-07-17 at 13:38 +0200, Rafael J. Wysocki wrote:
> On Wednesday, July 17, 2013 09:16:38 AM Igor Gnatenko wrote:
> > On Wed, 2013-07-17 at 00:01 +0200, Rafael J. Wysocki wrote:
> > > On Tuesday, July 16, 2013 05:08:16 PM Matthew Garrett wrote:
> > > > On Tue, 2013-07-16 at 17:32 +0400, Ig
On Wed, 2013-07-17 at 11:08 +0100, Show Liu wrote:
> This series patches extend Pawel's patches to
> Versatile Express HDLCD DVI output support.
> Before apply this patches, please apply Pawel's patches first.
> This series patches implements base on Linaro release 13.06 branch
> "ll_20130621.0".
This allows you to look at the current DPM state via
debugfs.
Due to the way the hardware works on these asics, there's
no way to look up exactly what power state we are in, so
we make the best guess we can based on the current sclk.
v2: fix sclk equation
Signed-off-by: Alex Deucher
Signed-off-
On Wed, Jul 17, 2013 at 9:54 PM, wrote:
> From: Alex Deucher
>
> Hi Dave,
>
> Just a few DPM fixes.
>
> The following changes since commit d1ce3d5496f2a7c90dd00a9133572f931d2acdcc:
>
> uvesafb: Really allow mtrr being 0, as documented and warn()ed (2013-07-16
> 10:24:28 +1000)
>
> are availab
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in
drivers/gpu/drm/i915/i915_gem.c between commit 5cef07e16283 ("drm/i915:
Move active/inactive lists to new mm") from the drm-intel tree and commit
"drivers-convert-shrinkers-to-new-count-scan-api-fix" from the akpm tree.
I fixe
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130717/10d0c0cc/attachment-0001.pgp>
t --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130717/008ad0ef/attachment.html>
> -Original Message-
> From: Anthoine Bourgeois [mailto:anthoine.bourgeois at gmail.com]
> Sent: Wednesday, July 17, 2013 5:23 PM
> To: Deucher, Alexander; Koenig, Christian; Jerome Glisse
> Cc: dri-devel at lists.freedesktop.org
> Subject: Re: [PATCH] drm/radeon/dpm: add debugfs support fo
f the debugging output patches.
Fixed my issues also.
Thanks for your great work.
--
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
K(0xf << 20)
> +# define SPLL_SW_LOLEN_SHIFT 20
> # define SPLL_DIVEN(1 << 24)
> # define SPLL_BYPASS_EN(1 << 25)
> # define SPLL_CHG_STATUS (1 << 29)
> --
> 1.8.1.5
>
-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-radeon-dpm-add-debugfs-support-for-RS780-RS880-v.patch
Type: application/octet-stream
Size: 4885 bytes
Desc: 0001-drm-radeon-dpm-add-debugfs-support-for-RS780-RS880-v.patch
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130717/e7ffdcc8/attachment-0001.obj>
f the debugging output patches.
Works fine for me.
--
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/20130717/8092f5e4/attachment.html>
https://bugs.freedesktop.org/show_bug.cgi?id=66942
--- Comment #9 from Alexandre Demers ---
(In reply to comment #8)
> Did you re-generate the initrd after installing the missing firmware?
>
> If the problem is the missing firmware, it should continue booting after
> three minutes or so. Have yo
On Wed, Jul 17, 2013 at 06:41:05PM +0200, David Herrmann wrote:
> Hi
>
> On Tue, Jul 16, 2013 at 9:12 AM, Daniel Vetter
> wrote:
> > No one outside of drm should use this, the official interfaces are
> > drm_gem_handle_create and drm_gem_handle_delete. The handle refcounting
> > is purely an imp
On Wed, Jul 17, 2013 at 06:38:35PM +0200, David Herrmann wrote:
> Hi
>
> On Tue, Jul 16, 2013 at 9:12 AM, Daniel Vetter
> wrote:
> > This is the 2nd attempt, I've always been a bit dissatisified with the
> > tricky nature of the first one:
> >
> > http://lists.freedesktop.org/archives/dri-devel/
output patches.
--
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/20130717/95067914/attachment.html>
On Wed, 17 Jul 2013 11:50:11 -0600
Daniel Drake wrote:
> I am now facing a problem with i2c/TDA998x which Russell already noted:
>
> http://lists.freedesktop.org/archives/dri-devel/2013-June/039632.html
>What *can't* be done without a rewrite of the DRM slave encoder backend
>is to have
Instead of unmapping the nodes in TTM and GEM users manually, we provide
a generic wrapper which does the correct thing for all vma-nodes.
v2: remove bdev->dev_mapping test in ttm_bo_unmap_virtual_unlocked() as
ttm_mem_io_free_vm() does nothing in that case (io_reserved_vm is 0).
Cc: Dave Airlie
Use the new vma-manager infrastructure. This doesn't change any
implementation details as the vma-offset-manager is nearly copied 1-to-1
from TTM.
Even though the vma-manager uses its own locks, we still need bo->vm_lock
to prevent bos from being destroyed before we can get a reference during
look
Use the new vma manager instead of the old hashtable. Also convert all
drivers to use the new convenience helpers. This drops all the
(map_list.hash.key << PAGE_SHIFT) non-sense.
Locking and access-management is exactly the same as before with an
additional lock inside of the vma-manager, which st
If we want to map GPU memory into user-space, we need to linearize the
addresses to not confuse mm-core. Currently, GEM and TTM both implement
their own offset-managers to assign a pgoff to each object for user-space
CPU access. GEM uses a hash-table, TTM uses an rbtree.
This patch provides a unif
Hi
This is v3 of the unified VMA offset manager. It merges the GEM and TTM mmap
offset managers into a unified implementation.
v2 is available here:
http://lists.freedesktop.org/archives/dri-devel/2013-July/041222.html
Changes since v2:
- also fix tegra to use the new manager
I intentionally
Hi
Any comments on this?
On Thu, Jul 4, 2013 at 2:25 PM, David Herrmann wrote:
> The current situation regarding boot-framebuffers (VGA, VESA/VBE, EFI) on
> x86 causes troubles when loading multiple fbdev drivers. The global
> "struct screen_info" does not provide any state-tracking about which
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in
drivers/gpu/drm/i915/i915_gem.c between commit 067556084a0e ("drm/i915:
Correct obj->mm_list link to dev_priv->dev_priv->mm.inactive_list") from
the drm-intel-fixes tree and commit 5cef07e16283 ("drm/i915: Move
active/inactiv
https://bugzilla.kernel.org/show_bug.cgi?id=60381
--- Comment #23 from rafael castillo ---
ok xonotic still crash play hell with the GPU but now it can resume after
failure and for things like gpu accel in browser or normal kwin usage seems
stable enough.
it seems only real 3d apps like games tr
https://bugzilla.kernel.org/show_bug.cgi?id=60381
--- Comment #22 from rafael castillo ---
Created attachment 106917
--> https://bugzilla.kernel.org/attachment.cgi?id=106917&action=edit
latest drm-fixes-3.11 dmesg
--
You are receiving this mail because:
You are watching the assignee of the bu
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in
drivers/gpu/drm/i915/i915_dma.c between commit 7dcd2677ea91 ("drm/i915:
fix long-standing SNB regression in power consumption after resume v2")
from the drm-intel-fixes tree and commit 59cdb63d529c ("drm/i915: kill
dev_priv->
Hi
On Tue, Jul 16, 2013 at 9:12 AM, Daniel Vetter
wrote:
> No one outside of drm should use this, the official interfaces are
> drm_gem_handle_create and drm_gem_handle_delete. The handle refcounting
> is purely an implementation detail of gem.
Yepp. Maybe we could even remove them as handle_re
Hi
On Tue, Jul 16, 2013 at 9:12 AM, Daniel Vetter
wrote:
> This is the 2nd attempt, I've always been a bit dissatisified with the
> tricky nature of the first one:
>
> http://lists.freedesktop.org/archives/dri-devel/2012-July/025451.html
>
> The issue is that the flink ioctl can race with callin
because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130717/c4972d45/attachment.html>
ri-devel/attachments/20130717/577f148e/attachment.html>
"last = " lines should still get printed.
--
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/20130717/7878e868/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20130717/496013c1/attachment.html>
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/20130717/ed78b33e/attachment.html>
---
arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts |6 +-
drivers/video/arm-hdlcd.c | 116 +---
drivers/video/vexpress-dvimode.c | 11 +++
drivers/video/vexpress-muxfpga.c |8 +-
include/linux/arm-hdlcd.h |6 +
---
drivers/video/Kconfig |2 ++
drivers/video/fbmon.c | 12 +---
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 2e14e0b..b0a0947 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -324,6 +324,7 @@ con
Hi All,
This series patches extend Pawel's patches to
Versatile Express HDLCD DVI output support.
Before apply this patches, please apply Pawel's patches first.
This series patches implements base on Linaro release 13.06 branch
"ll_20130621.0".
here is Pawel's patches
[1] http://lists.freedeskt
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130717/710a2fe3/attachment-0001.html>
u are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130717/e6dcbd39/attachment.html>
eg_block->usRegIndexTblSize)) /
sizeof(ATOM_INIT_REG_INDEX_FORMAT)) - 1;
--
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/20130717/1ab05f9b/attachment.html>
Chris Wilson writes:
> On Wed, Jul 17, 2013 at 03:07:17PM +0200, Egbert Eich wrote:
> > drm_gem_handle_create() should not have referenced an object when it's
> > creation has failed for some reason.
> >
> > Signed-off-by: Egbert Eich
>
> Nak. The unreference here is to free the locally c
part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130717/3a036243/attachment.html>
bed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130717/f1a5c82b/attachment.html>
xt part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130717/f56fa9d7/attachment.html>
When a BO gets pinned the placement may get changed. If the memory is
mapped into user space and user space has already accessed the mapped
range the page tables are set up but now point to the wrong memory.
Set bo.mdev->dev_mapping in mgag200_bo_create() to make sure that
ttm_bo_unmap_virtual() c
Hi all,
It's time to start nailing down the agenda for the Graphics and Display
microconference at the Linux Plumbers Conference 2013. For conference approval
and preliminary planning purposes, we have compiled a list of possible topics
for discussion. The overview and general list of topic ide
From: Aaron Lu
Expose acpi_gbl_osi_data so that code outside of ACPICA can check
the value of the last successfull _OSI call. The definitions for
OSI versions are moved to actypes.h so that other components can
access them too.
Based on a patch from Matthew Garrett which in turn was based on
an
From: Rafael J. Wysocki
According to Matthew Garrett, "Windows 8 leaves backlight control up
to individual graphics drivers rather than making ACPI calls itself.
There's plenty of evidence to suggest that the Intel driver for
Windows [8] doesn't use the ACPI interface, including the fact that
it'
From: Matthew Garrett
We have to call acpi_video_init_brightness() even if we're not going
to initialise the backlight - Thinkpads seem to use this as the
trigger for enabling ACPI notifications rather than handling it in
firmware.
[rjw: Drop the brightness object created by
acpi_video_init_bri
On Sunday, June 09, 2013 07:01:36 PM Matthew Garrett wrote:
> Windows 8 introduced new policy for backlight control by pushing it out to
> graphics drivers. This appears to have coincided with a range of vendors
> adding Windows 8 checks to their backlight control code which trigger either
> awkwar
="
--
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/20130717/2906ade2/attachment.html>
https://bugs.freedesktop.org/show_bug.cgi?id=67016
Priority: medium
Bug ID: 67016
Assignee: dri-devel@lists.freedesktop.org
Summary: Lockup on piglit test vs-textureSize-compare with AMD
6950
Severity: normal
Classificati
From: Alex Deucher
Hi Dave,
Take two. Just some DPM fixes.
The following changes since commit d1ce3d5496f2a7c90dd00a9133572f931d2acdcc:
uvesafb: Really allow mtrr being 0, as documented and warn()ed (2013-07-16
10:24:28 +1000)
are available in the git repository at:
git://people.freedes
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130717/45b8f3a1/attachment.html>
RL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130717/95854ba3/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20130717/3e243e5e/attachment-0001.html>
nts/20130717/a53fcac0/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20130717/6cc074c9/attachment.html>
nts/20130717/a3c5c3e3/attachment.html>
it a little
Does the attached patch help?
Alex
-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-radeon-dpm-atom-fix-broken-gcc-harder.patch
Type: text/x-patch
Size: 1997 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130717/5d620652/attachment.bin>
Dave hold off on this for now.
Alex
On Wed, Jul 17, 2013 at 4:24 PM, Andre Heider wrote:
> On Wed, Jul 17, 2013 at 9:54 PM, wrote:
>> From: Alex Deucher
>>
>> Hi Dave,
>>
>> Just a few DPM fixes.
>>
>> The following changes since commit d1ce3d5496f2a7c90dd00a9133572f931d2acdcc:
>>
>> uvesa
On Wed, 2013-07-17 at 13:38 +0200, Rafael J. Wysocki wrote:
> On Wednesday, July 17, 2013 09:16:38 AM Igor Gnatenko wrote:
> > On Wed, 2013-07-17 at 00:01 +0200, Rafael J. Wysocki wrote:
> > > On Tuesday, July 16, 2013 05:08:16 PM Matthew Garrett wrote:
> > > > On Tue, 2013-07-16 at 17:32 +0400, Ig
Hi Dave,
The SH Mobile DRM and R-Car DU DRM drivers fail to compile on v3.11-rc1 due to
usage of an API that has been removed. Could you please pull these fixes for
v3.11 ? The sooner would be the better, to avoid as many bisection issues as
possible.
The following changes since commit ad81f05
From: Alex Deucher
Hi Dave,
Just a few DPM fixes.
The following changes since commit d1ce3d5496f2a7c90dd00a9133572f931d2acdcc:
uvesafb: Really allow mtrr being 0, as documented and warn()ed (2013-07-16
10:24:28 +1000)
are available in the git repository at:
git://people.freedesktop.org/~
Hi
On Tue, Jul 16, 2013 at 3:14 PM, Daniel Vetter
wrote:
> We not only have debugfs files to do pretty much the equivalent of
> lsof, we also have an ioctl. Not that compared to lsof this dumps a
> wee bit more information, but we can still get at that from debugfs
> easily.
>
> I've dug around
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/20130717/f0105cc7/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=54381
--- Comment #12 from Andrew Stubbs ---
Created attachment 106911
--> https://bugzilla.kernel.org/attachment.cgi?id=106911&action=edit
dmesg data from ams
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=54381
--- Comment #11 from Andrew Stubbs ---
It's a Dell Precision M4600 sitting in the docking station.
Apologies for the random Ubuntu version numbers. Not appropriate here.
Unfortunately I don't actually know what kernel version I had before the
upg
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130717/3f3c2b45/attachment.html>
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/20130717/b1765964/attachment.html>
] radeon :01:00.0: GPU lockup (waiting for 0x0199
last fence id 0x0198)
--
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/20130717/b27342e4/attachment-0001.html>
This code was ported from the xorg mga driver.
Signed-off-by: Egbert Eich
---
drivers/gpu/drm/mgag200/mgag200_mode.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c
b/drivers/gpu/drm/mgag200/mgag200_mode.c
index 0bb0e1e..3faa
Matrox hardware only supports modes whose horizontal parameters are
multiples of 8. This rules out a mode like 1366x768 for example.
Signed-off-by: Egbert Eich
---
drivers/gpu/drm/mgag200/mgag200_mode.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.
Since there are only 32 (64) distinct color values for each color
in 16bpp Matrox hardware expects those in a 'dense' manner, ie in
the first 32 (64) entries of the respective color.
Signed-off-by: Egbert Eich
---
drivers/gpu/drm/mgag200/mgag200_mode.c | 23 +++
1 file change
From: Takashi Iwai
The framebuffer pitch calculation needs to be done differently for bpp == 24
- check xf86-video-mga for reference.
Signed-off-by: Egbert Eich
---
drivers/gpu/drm/mgag200/mgag200_mode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mgag20
Signed-off-by: Egbert Eich
---
drivers/gpu/drm/mgag200/mgag200_mode.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c
b/drivers/gpu/drm/mgag200/mgag200_mode.c
index 2fe1f64..020a623 100644
--- a/drivers/gpu/drm/mgag200/mgag200_mode.c
+++ b/drivers/gpu
Due to a missing initialization there was no way to map fbdev memory.
Thus for example using the Xserver with the fbdev driver failed.
This fix adds initialization for fix.smem_start and fix.smem_len
in the fb_info structure, which fixes this problem.
Signed-off-by: Egbert Eich
---
drivers/gpu/d
When a BO gets pinned the placement may get changed. If the memory is
mapped into user space and user space has already accessed the mapped
range the page tables are set up but now point to the wrong memory.
A call to ttm_bo_unmap_virtual() will invalidate all page tables of
all mappings of this BO
Signed-off-by: Egbert Eich
---
drivers/gpu/drm/mgag200/mgag200_mode.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c
b/drivers/gpu/drm/mgag200/mgag200_mode.c
index 251784a..2fe1f64 100644
--- a/drivers/gpu/drm/mgag200/mgag200_mode.
Signed-off-by: Egbert Eich
---
drivers/gpu/drm/mgag200/mgag200_ttm.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_ttm.c
b/drivers/gpu/drm/mgag200/mgag200_ttm.c
index 2606031..3a2e5e2 100644
--- a/drivers/gpu/drm/mgag200/mgag200_ttm.c
Signed-off-by: Egbert Eich
---
drivers/gpu/drm/mgag200/mgag200_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_main.c
b/drivers/gpu/drm/mgag200/mgag200_main.c
index d51096c..fe8ed66 100644
--- a/drivers/gpu/drm/mgag200/mgag200_main.c
+++
Signed-off-by: Egbert Eich
---
drivers/gpu/drm/mgag200/mgag200_ttm.c | 22 +-
1 file changed, 9 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_ttm.c
b/drivers/gpu/drm/mgag200/mgag200_ttm.c
index 6461fd2..2606031 100644
--- a/drivers/gpu/drm/mgag2
The fb id string was used in an error message right before it was set.
Reversing the order of the code fixes this.
Signed-off-by: Egbert Eich
---
drivers/gpu/drm/mgag200/mgag200_fb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_fb.c
b/d
drm_gem_handle_create() should not have referenced an object when it's
creation has failed for some reason.
Signed-off-by: Egbert Eich
---
drivers/gpu/drm/mgag200/mgag200_main.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_main.c
b/driver
Technically freeing mga_fb->base is the same as freeing mga_fb as 'base'
the first member of the data structure.
Still this makes it cleaner.
Signed-off-by: Egbert Eich
---
drivers/gpu/drm/mgag200/mgag200_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/
The allocated struct mgag200_bo was not freed in all error paths.
This patch consolidates error handling and fixes this.
Signed-off-by: Egbert Eich
---
drivers/gpu/drm/mgag200/mgag200_ttm.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mg
Some mmemory allocated in mgag200fb_create() was not properly
freed before the function returned with an error.
This patch takes care of this.
Signed-off-by: Egbert Eich
---
drivers/gpu/drm/mgag200/mgag200_fb.c | 21 -
1 file changed, 16 insertions(+), 5 deletions(-)
diff --
This set of patches contains several fixes and enhancements for the
MGAG200 KMS driver.
Egbert Eich (15):
drm/mgag200: Fix memleaks in error path in mgag200_fb_create()
drm/mgag200: Fix memleak in error path in mgag200_bo_create()
drm/mgag200: Free container instead of member in
mga_user
https://bugzilla.kernel.org/show_bug.cgi?id=54381
--- Comment #10 from Alex Deucher ---
Sounds like your oem has a rather strange setup. Please attach your dmesg
output.
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=54381
--- Comment #9 from Andrew Stubbs ---
Alternatively, would switching a monitor from DVI to VGA or HDMI help?
I currently have two DVI monitors, listed as "DisplayPort-1" and
"DisplayPort-2", and one laptop display, listed as "LVDS". No two monito
https://bugs.freedesktop.org/show_bug.cgi?id=66932
--- Comment #32 from queryv...@gmail.com ---
(In reply to comment #31)
> (In reply to comment #29)
> > Created attachment 82563 [details] [review] [review]
> > additional fix
> >
> > Try just this patch on top of attachment 82560 [details] [revie
1 - 100 of 238 matches
Mail list logo
