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: 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
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->
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
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
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://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
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
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".
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
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, 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
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
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 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
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
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: 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 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 backlight.
>
> Yeah, I can duplicate that. Rafael, we have to call
sktop.org/archives/dri-devel/attachments/20130717/f9f8987e/attachment.html>
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/20130717/9fa08bc4/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=60381
--- Comment #17 from Alex Deucher ---
Created attachment 106898
--> https://bugzilla.kernel.org/attachment.cgi?id=106898&action=edit
debugging output
Can you attach a dmesg output with dpm enabled with this patch?
--
You are receiving this ma
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/20130717/baf9954f/attachment.html>
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/20130717/01034c3b/attachment-0001.html>
eiving 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/26f3b918/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=60381
--- Comment #18 from rafael castillo ---
I can`t reach X with that patch applied, ill try later with gcc 4.7 just to be
sure
--
You are receiving this mail because:
You are watching the assignee of the bug.
from #8, attached output from dmesg
with dpm=1 and aspm=0 after patch from #12
--
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/attachment
https://bugzilla.kernel.org/show_bug.cgi?id=60381
--- Comment #19 from rafael castillo ---
well compiling with 4.7 series i can reach X, i guess ill get another fun debug
for later, atacched dmesg
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=60381
--- Comment #20 from rafael castillo ---
Created attachment 106900
--> https://bugzilla.kernel.org/attachment.cgi?id=106900&action=edit
dmesg with patch applied
--
You are receiving this mail because:
You are watching the assignee of the bug.
31212 Jul 16 21:10 CAYMAN_smc.bin
--
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/eae7913a/attachment.html>
n does looks
like it's extensible enough for us not to have to worry too much.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130717/b3ec8d39/attachment.pgp>
xt part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130717/ef5d2794/attachment-0001.html>
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 exists since kernel v3.6, commit b4ae3f22d238617ca11610b29fde16cf8c0bc6e0
("drm/
radeon vramlimit=16 and Xorg
start (kdm).
--
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/b5747dca/attachment.html>
radeon vramlimit=32 and Xorg
start (kdm).
--
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/967b982a/attachment.html>
nt was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130717/7f1ab7dd/attachment.html>
On Wed, Jul 17, 2013 at 10:22:58AM +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
quot;dynamic". I try to implement
force_performance_level and in that case a r600_power_level_set_enter_index
doesn't seem to modify the register.
> There's no convenient way to look this up on rs780. I attempted to add
> support for it:
>
> http://people.freedesktop.org/~agd5f/0001-drm-radeon-dpm-add-debugfs-support-for-RS780-RS880.patch
> but the registers don't seem read back reliably when dpm is enabled so the
> output is bogus.
>
> Too bad :-(
Thanks,
Anthoine
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130717/6e5f3d4f/attachment.html>
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
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/e9848efe/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130717/bdde5539/attachment.html>
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
n HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130717/f5d52cd5/attachment.html>
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
later
--
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/98f201a0/attachment-0001.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20130717/403324c1/attachment.html>
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/20130717/104e7b9c/attachment.html>
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
+++
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
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
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
--
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/b30cbe19/attachment.html>
lt;http://lists.freedesktop.org/archives/dri-devel/attachments/20130717/75779996/attachment.html>
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
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||ams at codesourcery.com
--- Comment #8 fr
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
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20130717/458d4186/attachment.html>
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://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.
] 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 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>
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>
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
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 #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.
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
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>
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 callin
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20130717/6cc074c9/attachment.html>
nts/20130717/a3c5c3e3/attachment.html>
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
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20130717/3e243e5e/attachment-0001.html>
nts/20130717/a53fcac0/attachment.html>
RL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130717/95854ba3/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130717/45b8f3a1/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/20130717/2906ade2/attachment.html>
101 - 200 of 238 matches
Mail list logo
