On Tue, 2013-07-16 at 01:53 +0200, Rafael J. Wysocki wrote:
> On Monday, July 15, 2013 05:06:09 PM Igor Gnatenko wrote:
> > On Sat, 2013-07-13 at 02:46 +0200, Rafael J. Wysocki wrote:
>
> [...]
>
> >
> > I can't build it. Where did I go wrong?
>
> Probably nowhere, you tried to build the ACPI
Hmm. I found regression in user-space. In GNOME (maybe and other DEs) we no
longer see switch status of backlight.
--
Igor Gnatenko
Fedora release 19 (Schrödinger’s Cat)
Linux 3.11.0-0.rc0.git7.1.fc20.x86_64
___
dri-devel mailing list
dri-devel@lists.
On Tue, 2013-07-16 at 17:32 +0400, Igor Gnatenko wrote:
> Hmm. I found regression in user-space. In GNOME (maybe and other DEs) we no
> longer see switch status of backlight.
Yeah, I can duplicate that. Rafael, we have to call
acpi_video_init_brightness() even if we're not going to initialise the
This allows you to look at the current DPM state via debugfs.
Signed-off-by: Anthoine Bourgeois
---
drivers/gpu/drm/radeon/radeon_asic.c | 1 +
drivers/gpu/drm/radeon/radeon_asic.h | 2 ++
drivers/gpu/drm/radeon/rs780_dpm.c | 28
3 files changed, 31 insertions(+)
d
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, Igor Gnatenko wrote:
> > > Hmm. I found regression in user-space. In GNOME (maybe and other DEs) we
> > > no longer see switch status of
2013/7/16 Deucher, Alexander
> > -Original Message-
> > From: Anthoine Bourgeois [mailto:anthoine.bourge...@gmail.com]
> > Sent: Tuesday, July 16, 2013 5:09 PM
> > To: Deucher, Alexander; Koenig, Christian; Jerome Glisse; Anthoine
> > Bourgeois
> > Cc: dri-devel@lists.freedesktop.org
> >
https://bugs.freedesktop.org/show_bug.cgi?id=66942
--- Comment #8 from Michel Dänzer ---
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 you waited that long?
--
You are rec
https://bugs.freedesktop.org/show_bug.cgi?id=66932
--- Comment #11 from Martin Andersson ---
Created attachment 82534
--> https://bugs.freedesktop.org/attachment.cgi?id=82534&action=edit
dmesg with mc reg dump
--
You are receiving this mail because:
You are the assignee for the bug.
_
On 15 July 2013 11:35, Michel Dänzer wrote:
> On Son, 2013-07-14 at 13:26 +0100, Sami Kerola wrote:
>>
>> Jul 14 12:51:31 kerolasa-home kernel: radeon :00:01.0: GPU lockup
>> CP stall for more than 1msec
>> Jul 14 12:51:31 kerolasa-home kernel: radeon :00:01.0: GPU lockup
>> (waiting f
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
---
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
---
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 +
On Mit, 2013-07-17 at 10:58 +0100, Sami Kerola wrote:
> On 15 July 2013 11:35, Michel Dänzer wrote:
> > On Son, 2013-07-14 at 13:26 +0100, Sami Kerola wrote:
> >>
> >> Jul 14 12:51:31 kerolasa-home kernel: radeon :00:01.0: GPU lockup
> >> CP stall for more than 1msec
> >> Jul 14 12:51:31 k
https://bugs.freedesktop.org/show_bug.cgi?id=66932
--- Comment #12 from Martin Andersson ---
Take this information with a grain of salt, since I'm testing stuff without
really knowing whats going on.
I found it interesting that the dmesg with the mc dump didn't print anything
from the first for
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, Igor Gnatenko wrote:
> > > > Hmm. I found regression in user-space. In
On Wednesday 17 July 2013 11:49:49 Pawel Moll wrote:
> 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 impl
https://bugzilla.kernel.org/show_bug.cgi?id=60381
--- Comment #21 from Arek Ruśniak ---
Created attachment 106902
--> https://bugzilla.kernel.org/attachment.cgi?id=106902&action=edit
dmesg drm-fixes-3.11+patch
It almost looks like the same as before. But You are dev here:) I'll try uvd
with th
On Wed, Jun 12, 2013 at 11:58:44AM +0200, Michel Dänzer wrote:
> From: Michel Dänzer
>
> It takes an unsigned value. This happens not to blow up on 64-bit
> architectures, but it does on 32-bit, causing
> drm_calc_vbltimestamp_from_scanoutpos() to calculate totally bogus
> timestamps for vblank e
https://bugs.freedesktop.org/show_bug.cgi?id=63599
--- Comment #20 from wojtek ---
yeah :)
with vramlimit=16 xeyes works perfect :).
KDM (4.10.5) is working (without artifacts).
kernel-3.11-rc1
from(http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-fixes-3.11)
I'll do more tests later
--
Y
https://bugs.freedesktop.org/show_bug.cgi?id=64913
--- Comment #16 from Krzysztof A. Sobiecki ---
I have done that and no one cared.
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.f
https://bugs.freedesktop.org/show_bug.cgi?id=63599
--- Comment #21 from Alex Deucher ---
That just disables the use of vram for exa pixmaps. You can accomplish the
same thing by adding:
Option "EXAPixmaps" "false"
to the device section of your xorg.conf
--
You are receiving this mail because:
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
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 --
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
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
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.
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
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/
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.
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
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
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
+++
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
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
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_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
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
https://bugs.freedesktop.org/show_bug.cgi?id=64913
--- Comment #17 from Alex Deucher ---
(In reply to comment #16)
> I have done that and no one cared.
Are you sure it went through? I don't don't see the patch in the archives:
http://lists.freedesktop.org/archives/mesa-dev/
--
You are receivi
https://bugs.freedesktop.org/show_bug.cgi?id=64913
--- Comment #18 from Krzysztof A. Sobiecki ---
(In reply to comment #17)
> (In reply to comment #16)
> > I have done that and no one cared.
>
> Are you sure it went through? I don't don't see the patch in the archives:
> http://lists.freedeskto
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 created resource before
returning the error
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 i
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
https://bugzilla.kernel.org/show_bug.cgi?id=54381
Andrew Stubbs changed:
What|Removed |Added
CC||a...@codesourcery.com
--- Comment #8 from
On Wed, 17 Jul 2013 10:22:58 +0400
Konstantin Khlebnikov wrote:
> This patch fixes regression in power consumtion of sandy bridge gpu, which
> exists since v3.6 Sometimes after resuming from s2ram gpu starts thinking that
> it's extremely busy. After that it never reaches rc6 state.
>
> Bug exis
https://bugs.freedesktop.org/show_bug.cgi?id=66713
Vadim Girlin changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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=67002
Priority: medium
Bug ID: 67002
Assignee: dri-devel@lists.freedesktop.org
Summary: evergreen: after resume from suspend-to-ram operation
is really slow with the latest DPM changes
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
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
https://bugs.freedesktop.org/show_bug.cgi?id=67002
jackdac...@gmail.com changed:
What|Removed |Added
Summary|evergreen: after resume |evergreen: after resume
https://bugs.freedesktop.org/show_bug.cgi?id=66967
--- Comment #1 from Tilman Sauerbeck ---
Ugh, I forgot to post the backtrace:
#0 0xf538fc5a in check_begin_texture_render (ctx=0x8bbe000, fb=0x17da4a80)
at ../../src/mesa/main/fbobject.c:1871
#1 0xf539007d in _mesa_BindFramebuffer (target=
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
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 #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://bugs.freedesktop.org/show_bug.cgi?id=66972
--- Comment #6 from Andre Heider ---
Created attachment 82547
--> https://bugs.freedesktop.org/attachment.cgi?id=82547&action=edit
dmesg with mc reg dump
3.11-rc1 + drm-fixes + patch from #5
--
You are receiving this mail because:
You are th
On Sat, Jun 22, 2013 at 4:46 PM, Yves-Alexis Perez wrote:
> On dim., 2013-06-09 at 19:01 -0400, Matthew Garrett wrote:
>> The first two patches in this series are picked from other patchesets aimed
>> at
>> solving similar problems. The last simply unregisters ACPI backlight control
>> on Windows
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
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 calling
https://bugs.freedesktop.org/show_bug.cgi?id=66972
Alex Deucher changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=66932
Alex Deucher changed:
What|Removed |Added
CC||a.hei...@gmail.com
--- Comment #13 from A
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_ref
https://bugs.freedesktop.org/show_bug.cgi?id=66945
Alex Deucher changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=66932
Alex Deucher changed:
What|Removed |Added
CC||t...@slackeee.de
--- Comment #14 from Ale
https://bugs.freedesktop.org/show_bug.cgi?id=66932
--- Comment #15 from Alex Deucher ---
Created attachment 82551
--> https://bugs.freedesktop.org/attachment.cgi?id=82551&action=edit
more debugging
Something appears to be corrupting that structure. Try this patch on top of
the previous one an
https://bugs.freedesktop.org/show_bug.cgi?id=66932
--- Comment #16 from Martin Andersson ---
Created attachment 82552
--> https://bugs.freedesktop.org/attachment.cgi?id=82552&action=edit
dmesg with more debugging
--
You are receiving this mail because:
You are the assignee for the bug.
__
https://bugs.freedesktop.org/show_bug.cgi?id=66932
--- Comment #17 from Andre Heider ---
Same here:
[7.563515] module_index = 2 num_entries = 13
[7.563516] 0: s1 = 0x0a2f prd = 0x04
[7.567599] switching from power state:
no more "s1 =" and not a single "last ="
--
You are receiving
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
https://bugs.freedesktop.org/show_bug.cgi?id=66932
--- Comment #18 from Andre Heider ---
Created attachment 82559
--> https://bugs.freedesktop.org/attachment.cgi?id=82559&action=edit
weird fix
This magically makes it work...
No more stalls, box drops from 125 watt to 62.
[7.923448] module
https://bugs.freedesktop.org/show_bug.cgi?id=66932
--- Comment #19 from Martin Andersson ---
I wasn't very clear in my #12 comment, but what I was trying to say it is
something fishy about "reg_block->asRegIndexBuf". It is defined in atombios.h
as:
ATOM_MEMORY_SETTING_DATA_BLOCK asRegDataBuf[1];
https://bugs.freedesktop.org/show_bug.cgi?id=66932
--- Comment #20 from Martin Andersson ---
Dammit copied the wrong line, but my point is still valid:
ATOM_INIT_REG_INDEX_FORMAT asRegIndexBuf[1];
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=66932
--- Comment #21 from Alex Deucher ---
(In reply to comment #19)
> I wasn't very clear in my #12 comment, but what I was trying to say it is
> something fishy about "reg_block->asRegIndexBuf". It is defined in
> atombios.h as:
> ATOM_MEMORY_SETTIN
https://bugs.freedesktop.org/show_bug.cgi?id=66932
--- Comment #22 from Alex Deucher ---
(In reply to comment #18)
> Created attachment 82559 [details] [review]
> weird fix
>
Hmmm, looks like a compiler bug. what compiler are you using?
--
You are receiving this mail because:
You are the ass
https://bugs.freedesktop.org/show_bug.cgi?id=66932
--- Comment #23 from Martin Andersson ---
(In reply to comment #21)
> (In reply to comment #19)
> > I wasn't very clear in my #12 comment, but what I was trying to say it is
> > something fishy about "reg_block->asRegIndexBuf". It is defined in
>
https://bugs.freedesktop.org/show_bug.cgi?id=66932
--- Comment #24 from Andre Heider ---
(In reply to comment #22)
> (In reply to comment #18)
> > Created attachment 82559 [details] [review] [review]
> > weird fix
> >
>
> Hmmm, looks like a compiler bug. what compiler are you using?
gcc versi
https://bugs.freedesktop.org/show_bug.cgi?id=66932
--- Comment #25 from Martin Andersson ---
The patch works for me as well
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedeskto
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
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
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
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
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
https://bugs.freedesktop.org/show_bug.cgi?id=66932
--- Comment #26 from Alex Deucher ---
(In reply to comment #24)
> (In reply to comment #22)
> > (In reply to comment #18)
> > > Created attachment 82559 [details] [review] [review] [review]
> > > weird fix
> > >
> >
> > Hmmm, looks like a compi
https://bugs.freedesktop.org/show_bug.cgi?id=66932
--- Comment #27 from Alex Deucher ---
Created attachment 82560
--> https://bugs.freedesktop.org/attachment.cgi?id=82560&action=edit
fix
I've attached a git version of Andre's patch. I think it should be fine. The
logic is preserved. Not sur
https://bugs.freedesktop.org/show_bug.cgi?id=66932
--- Comment #28 from Andre Heider ---
(In reply to comment #26)
> Also, even if the loop gets skipped, the "last = " lines should still get
> printed.
Oh right, that makes it even more weird...
--
You are receiving this mail because:
You are
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/201
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 implem
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/~
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
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, 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:
>>
>> uvesafb: Really allow mtrr being 0, as docum
https://bugs.freedesktop.org/show_bug.cgi?id=66932
--- Comment #29 from Alex Deucher ---
Created attachment 82563
--> https://bugs.freedesktop.org/attachment.cgi?id=82563&action=edit
additional fix
Try just this patch on top of attachment 82560. Do not apply any of the
debugging output patche
https://bugs.freedesktop.org/show_bug.cgi?id=66932
--- Comment #30 from Martin Andersson ---
(In reply to comment #29)
> Created attachment 82563 [details] [review]
> additional fix
>
> Try just this patch on top of attachment 82560 [details] [review]. Do not
> apply any of the debugging output
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
Good catch, I screwed up the ref divider calculation. How about the attached
patch?
Alex
> -Original Message-
> From: Anthoine Bourgeois [mailto:anthoine.bourge...@gmail.com]
> Sent: Wednesday, July 17, 2013 4:43 PM
> To: Deucher, Alexander; Koenig, Christian; Jerome Glisse; Anthoine
>
https://bugs.freedesktop.org/show_bug.cgi?id=66932
--- Comment #31 from t...@slackeee.de ---
(In reply to comment #29)
> Created attachment 82563 [details] [review]
> additional fix
>
> Try just this patch on top of attachment 82560 [details] [review]. Do not
> apply any of the debugging output
> -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: Re: [PATCH] drm/radeon/dpm: add debugfs support for
> RS
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
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
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
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
1 - 100 of 238 matches
Mail list logo
