https://bugzilla.kernel.org/show_bug.cgi?id=16065
--- Comment #14 from Kaloyan Dimitrov 2012-07-25 06:31:16
---
For me not, it is handled
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the ass
Fix build error on IA64:
ERROR: "mxm_wmi_supported" [drivers/gpu/drm/nouveau/nouveau.ko] undefined!
Signed-off-by: Fengguang Wu
---
include/linux/mxm-wmi.h |8
1 file changed, 8 insertions(+)
diff --git a/include/linux/mxm-wmi.h b/include/linux/mxm-wmi.h
index 617a295..f6a6214 100
I'm not sure if this is the best way, however it does fix the last 2
allmodconfig errors on IA64:
ERROR: "wmi_has_guid" [drivers/gpu/drm/nouveau/nouveau.ko] undefined!
ERROR: "wmi_evaluate_method" [drivers/gpu/drm/nouveau/nouveau.ko] undefined!
Signed-off-by: Fengguang Wu
---
drivers/gpu/drm/no
Hi Dave,
First pile of fixes for 3.6 already, and I'm afraid it's a bit larger than
what I'd wish for. But I've moved all the feature-y stuff to -next, so
this really is all -fixes. Most of it is handling fallout from the hw
context stuff, discovered now that mesa git has started using them for
re
Last known good: 3.4.4
First bad: 3.5.0
When booting 3.5.0 resolution (in console, and after in KDE) is set to
1024x768 (60Hz). In 3.4.4 was correct: 1440x900 (60Hz).
Dmesg from 3.5.0:
http://mrutecki.pl/download/kernel/3.5/swinka/dmesg-3.5.0.txt
Dmesg from 3.4.4:
http://mrutecki.pl/download/ke
On Wed, Jul 25, 2012 at 10:20:47AM +0200, Maciej Rutecki wrote:
> Last known good: 3.4.4
> First bad: 3.5.0
>
> When booting 3.5.0 resolution (in console, and after in KDE) is set to
> 1024x768 (60Hz). In 3.4.4 was correct: 1440x900 (60Hz).
Can you please attach the output of xrandr --verbose fo
On Wed, Jul 25, 2012 at 10:17:33AM +0200, Daniel Vetter wrote:
> Hi Dave,
>
> First pile of fixes for 3.6 already, and I'm afraid it's a bit larger than
> what I'd wish for. But I've moved all the feature-y stuff to -next, so
> this really is all -fixes. Most of it is handling fallout from the hw
On środa, 25 lipca 2012 o 10:29:26 Daniel Vetter wrote:
> On Wed, Jul 25, 2012 at 10:20:47AM +0200, Maciej Rutecki wrote:
> > Last known good: 3.4.4
> > First bad: 3.5.0
> >
> > When booting 3.5.0 resolution (in console, and after in KDE) is set to
> > 1024x768 (60Hz). In 3.4.4 was correct: 1440x9
On Wed, Jul 25, 2012 at 10:54:25AM +0200, Maciej Rutecki wrote:
> On środa, 25 lipca 2012 o 10:29:26 Daniel Vetter wrote:
> > On Wed, Jul 25, 2012 at 10:20:47AM +0200, Maciej Rutecki wrote:
> > > Last known good: 3.4.4
> > > First bad: 3.5.0
> > >
> > > When booting 3.5.0 resolution (in console, a
On środa, 25 lipca 2012 o 11:29:28 Daniel Vetter wrote:
> On Wed, Jul 25, 2012 at 10:54:25AM +0200, Maciej Rutecki wrote:
> > On środa, 25 lipca 2012 o 10:29:26 Daniel Vetter wrote:
> > > On Wed, Jul 25, 2012 at 10:20:47AM +0200, Maciej Rutecki wrote:
> > > > Last known good: 3.4.4
> > > > First ba
On Wed, Jul 25, 2012 at 12:57 PM, Maciej Rutecki
wrote:
> On środa, 25 lipca 2012 o 11:29:28 Daniel Vetter wrote:
>> On Wed, Jul 25, 2012 at 10:54:25AM +0200, Maciej Rutecki wrote:
>> > On środa, 25 lipca 2012 o 10:29:26 Daniel Vetter wrote:
>> > > On Wed, Jul 25, 2012 at 10:20:47AM +0200, Maciej
From: Alan Cox
Otherwise our initial behaviour is "randomly save a bogus PLL
choice" as far as I can see.
Signed-off-by: Alan Cox
---
drivers/gpu/drm/i915/intel_display.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_
From: Alan Cox
Signed-off-by: Alan Cox
---
drivers/gpu/drm/i915/intel_sdvo.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
b/drivers/gpu/drm/i915/intel_sdvo.c
index 26a6a4d..d172e98 100644
--- a/drivers/gpu/drm/i915/intel_sdvo.c
+
From: Alan Cox
drv_priv->gmbus is an array. Comparing it with NULL is somewhat less useful
than a chocolate teapot.
Possibly we should be testing bus != NULL each iteration of the loop
instead ?
gcc could help by warning too!
Signed-off-by: Alan Cox
---
drivers/gpu/drm/i915/intel_i2c.c |
https://bugs.freedesktop.org/show_bug.cgi?id=52467
Alex Deucher changed:
What|Removed |Added
Attachment #64640|text/x-log |text/plain
mime type|
> - select ACPI_WMI if ACPI
> + select ACPI_WMI if ACPI && !IA64
> select MXM_WMI if ACPI
Sorry, the MXM_WMI line should also be changed. Although MXM_WMI
depends on ACPI_WMI, "select" is dumb and will ignore that dependency..
Thanks,
Fengguang
---
From: Fengguang Wu
Date: Wed, 25
https://bugs.freedesktop.org/show_bug.cgi?id=52467
--- Comment #5 from Alexandre Demers 2012-07-25
16:31:41 PDT ---
I would consider having a look at bug 43655, it might be related. Could you try
workaround proposed in comment 8 (bug 43655#c8) or comment 13 (bug 43655#c13)?
--
Configure bugmai
From: Alex Deucher
The IntegratedSystemInfo table changed versions
on TN. Update the SS override lookup to handle it.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_atombios.c | 49 ++---
1 files changed, 37 insertions(+), 12 deletions(-)
diff --git a
From: Alex Deucher
The IntegratedSystemInfo table changed versions
on TN. Update the SS override lookup to handle it.
v2: fix copy-paste typo.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_atombios.c | 49 ++---
1 files changed, 37 insertions(+), 12
From: Alex Deucher
Add a new header that defines the AMD ACPI interface used
for laptops, PowerXpress, and chipset specific functionality
and update the current code to use it.
Todo:
- properly verify the ACPI interfaces
- hook up and handle ACPI notifications
- make PX code more robust
- implem
https://bugs.freedesktop.org/show_bug.cgi?id=45018
--- Comment #68 from Alexandre Demers 2012-07-25
18:11:54 PDT ---
I was thinking about it yesterday: is it possible that we are not tracking
something in the virtual addresse spaces that we should be? That could explain
why we are getting messag
On Wed, Jul 25, 2012 at 10:46:49AM +0200, Ortwin Glück wrote:
> > Does it work if you boot without X and modprobe nouveau manually? If it
> > does,
> > can you disable page flipping in xorg.conf (Option "PageFlip" "0" in nouveau
> > device section) and recheck with X?
>
> It happens long before X
https://bugs.freedesktop.org/show_bug.cgi?id=52467
--- Comment #6 from sowad...@miner.mst.edu 2012-07-25 20:24:04 PDT ---
I am not using grub2, so I do not believe that the workaround in BUG 43655 are
relevant. I do not have these lines in my grub.conf
--
Configure bugmail: https://bugs.freedesk
https://bugs.freedesktop.org/show_bug.cgi?id=52467
--- Comment #7 from sowad...@miner.mst.edu 2012-07-25 20:39:10 PDT ---
Possible duplicate of BUG 42373?
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the a
https://bugs.freedesktop.org/show_bug.cgi?id=52467
sowad...@miner.mst.edu changed:
What|Removed |Added
Version|XOrg CVS|unspecified
--
Configure bugmai
Yet again the too close relationship between the fb helper and the
crtc helper code strikes. This time around the fb helper resets all
encoder->crtc pointers to NULL before starting to set up it's own
mode. Which is total bullocks, because this will clobber the existing
output routing, which the ne
Hi Linus,
one of the smaller drm -next pulls in ages!
Ben (nouveau) has a rewrite in progress but we decided to leave it stew
for another cycle, so just some fixes from him.
radeon: lots of documentation work, fixes, more ring and locking changes,
pcie gen2, more dp fixes,
i915: haswell featur
https://bugs.freedesktop.org/show_bug.cgi?id=43655
--- Comment #14 from Alexandre Demers 2012-07-26
05:33:08 PDT ---
May well be the same as bug 42373. I'll try to find a way to dig this following
42373 repro steps.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
---
https://bugs.freedesktop.org/show_bug.cgi?id=52467
Bug #: 52467
Summary: Radeon HD6450 KMS garbled screen on boot.
Classification: Unclassified
Product: DRI
Version: XOrg CVS
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
https://bugs.freedesktop.org/show_bug.cgi?id=52467
--- Comment #1 from sowadski at miner.mst.edu 2012-07-25 02:33:03 PDT ---
Created attachment 64638
--> https://bugs.freedesktop.org/attachment.cgi?id=64638
DMESG after booting with screen corruption
--
Configure bugmail: https://bugs.freedeskt
https://bugs.freedesktop.org/show_bug.cgi?id=52467
--- Comment #2 from sowadski at miner.mst.edu 2012-07-25 02:33:44 PDT ---
Created attachment 64639
--> https://bugs.freedesktop.org/attachment.cgi?id=64639
DMESG after restarting X a couple time to fix the issue
--
Configure bugmail: https://b
https://bugs.freedesktop.org/show_bug.cgi?id=52467
--- Comment #3 from sowadski at miner.mst.edu 2012-07-25 02:34:18 PDT ---
Created attachment 64640
--> https://bugs.freedesktop.org/attachment.cgi?id=64640
Xorg log after issue is gone
--
Configure bugmail: https://bugs.freedesktop.org/userpre
https://bugs.freedesktop.org/show_bug.cgi?id=52467
--- Comment #4 from sowadski at miner.mst.edu 2012-07-25 02:43:09 PDT ---
Created attachment 64641
--> https://bugs.freedesktop.org/attachment.cgi?id=64641
Picture of screen corruption
--
Configure bugmail: https://bugs.freedesktop.org/userpre
We were configuring SR7 very strangely for 16bpp and didn't properly
differenciate between depth 15 and 16. This fixes it (and both
appear to work at least on ppc)
Signed-off-by: Benjamin Herrenschmidt
---
drivers/gpu/drm/cirrus/cirrus_mode.c |5 +++--
1 file changed, 3 insertions(+), 2 dele
Qemu has an odd behaviour with the access to HDR (could be a qemu
bug, I'm investigating separately, but it affects current qemu's
so we should try to work around it).
Basically the internal counter that counts the reads of the 3c6
register in order to give you access to the HDR on the 5th access
fbset can pass var->bits_per_pixel = 15 when doing fbset -depth 15,
so we need to "correct" that to bpp 16 / depth 15.
Additionally, we make it possible to pass 15 as an argument to
drm_fb_helper_single_fb_probe() which will similarily select
a bpp of 15 and a depth of 15.
Signed-off-by: Benjamin
The real HW limit that prevents from using 32bpp is a pitch
limit of 4095 bytes. 32bpp is otherwise supported and works.
This fixes the checks in the code to check the right thing
(so that a userspace request to set a mode with a supported
bpp but a too large pitch will fail appropriately).
Addit
On the pseries machine type, qemu puts a default mode in the
device-tree based on the user request (-g option) which the
firmware uses to setup the boot screen.
Currently cirrusdrmfb ignores this and always ends up using
1280x1024. This adds support for retrieving this information
and using it to
This adds a "preferred" argument to drm_add_modes_noedid() which
allow drivers such as cirrusdrmfb to select a preferred mode based
on firmware configuration
Signed-off-by: Benjamin Herrenschmidt
---
drivers/gpu/drm/cirrus/cirrus_mode.c |8 +++-
drivers/gpu/drm/drm_crtc_helper.c|
https://bugzilla.kernel.org/show_bug.cgi?id=16065
--- Comment #14 from Kaloyan Dimitrov 2012-07-25
06:31:16 ---
For me not, it is handled
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the ass
Fix build error on IA64:
ERROR: "mxm_wmi_supported" [drivers/gpu/drm/nouveau/nouveau.ko] undefined!
Signed-off-by: Fengguang Wu
---
include/linux/mxm-wmi.h |8
1 file changed, 8 insertions(+)
diff --git a/include/linux/mxm-wmi.h b/include/linux/mxm-wmi.h
index 617a295..f6a6214 100
I'm not sure if this is the best way, however it does fix the last 2
allmodconfig errors on IA64:
ERROR: "wmi_has_guid" [drivers/gpu/drm/nouveau/nouveau.ko] undefined!
ERROR: "wmi_evaluate_method" [drivers/gpu/drm/nouveau/nouveau.ko] undefined!
Signed-off-by: Fengguang Wu
---
drivers/gpu/drm/no
Hi Dave,
First pile of fixes for 3.6 already, and I'm afraid it's a bit larger than
what I'd wish for. But I've moved all the feature-y stuff to -next, so
this really is all -fixes. Most of it is handling fallout from the hw
context stuff, discovered now that mesa git has started using them for
re
Last known good: 3.4.4
First bad: 3.5.0
When booting 3.5.0 resolution (in console, and after in KDE) is set to
1024x768 (60Hz). In 3.4.4 was correct: 1440x900 (60Hz).
Dmesg from 3.5.0:
http://mrutecki.pl/download/kernel/3.5/swinka/dmesg-3.5.0.txt
Dmesg from 3.4.4:
http://mrutecki.pl/download/ke
On Wed, Jul 25, 2012 at 10:20:47AM +0200, Maciej Rutecki wrote:
> Last known good: 3.4.4
> First bad: 3.5.0
>
> When booting 3.5.0 resolution (in console, and after in KDE) is set to
> 1024x768 (60Hz). In 3.4.4 was correct: 1440x900 (60Hz).
Can you please attach the output of xrandr --verbose fo
On Wed, Jul 25, 2012 at 10:17:33AM +0200, Daniel Vetter wrote:
> Hi Dave,
>
> First pile of fixes for 3.6 already, and I'm afraid it's a bit larger than
> what I'd wish for. But I've moved all the feature-y stuff to -next, so
> this really is all -fixes. Most of it is handling fallout from the hw
On ?roda, 25 lipca 2012 o 10:29:26 Daniel Vetter wrote:
> On Wed, Jul 25, 2012 at 10:20:47AM +0200, Maciej Rutecki wrote:
> > Last known good: 3.4.4
> > First bad: 3.5.0
> >
> > When booting 3.5.0 resolution (in console, and after in KDE) is set to
> > 1024x768 (60Hz). In 3.4.4 was correct: 1440x9
On Wed, Jul 25, 2012 at 10:54:25AM +0200, Maciej Rutecki wrote:
> On ?roda, 25 lipca 2012 o 10:29:26 Daniel Vetter wrote:
> > On Wed, Jul 25, 2012 at 10:20:47AM +0200, Maciej Rutecki wrote:
> > > Last known good: 3.4.4
> > > First bad: 3.5.0
> > >
> > > When booting 3.5.0 resolution (in console, a
On ?roda, 25 lipca 2012 o 11:29:28 Daniel Vetter wrote:
> On Wed, Jul 25, 2012 at 10:54:25AM +0200, Maciej Rutecki wrote:
> > On ?roda, 25 lipca 2012 o 10:29:26 Daniel Vetter wrote:
> > > On Wed, Jul 25, 2012 at 10:20:47AM +0200, Maciej Rutecki wrote:
> > > > Last known good: 3.4.4
> > > > First ba
On Wed, Jul 25, 2012 at 12:57 PM, Maciej Rutecki
wrote:
> On ?roda, 25 lipca 2012 o 11:29:28 Daniel Vetter wrote:
>> On Wed, Jul 25, 2012 at 10:54:25AM +0200, Maciej Rutecki wrote:
>> > On ?roda, 25 lipca 2012 o 10:29:26 Daniel Vetter wrote:
>> > > On Wed, Jul 25, 2012 at 10:20:47AM +0200, Maciej
From: Alan Cox
Otherwise our initial behaviour is "randomly save a bogus PLL
choice" as far as I can see.
Signed-off-by: Alan Cox
---
drivers/gpu/drm/i915/intel_display.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_
From: Alan Cox
Signed-off-by: Alan Cox
---
drivers/gpu/drm/i915/intel_sdvo.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
b/drivers/gpu/drm/i915/intel_sdvo.c
index 26a6a4d..d172e98 100644
--- a/drivers/gpu/drm/i915/intel_sdvo.c
+
From: Alan Cox
drv_priv->gmbus is an array. Comparing it with NULL is somewhat less useful
than a chocolate teapot.
Possibly we should be testing bus != NULL each iteration of the loop
instead ?
gcc could help by warning too!
Signed-off-by: Alan Cox
---
drivers/gpu/drm/i915/intel_i2c.c |
https://bugs.freedesktop.org/show_bug.cgi?id=52467
Alex Deucher changed:
What|Removed |Added
Attachment #64640|text/x-log |text/plain
mime type|
> - select ACPI_WMI if ACPI
> + select ACPI_WMI if ACPI && !IA64
> select MXM_WMI if ACPI
Sorry, the MXM_WMI line should also be changed. Although MXM_WMI
depends on ACPI_WMI, "select" is dumb and will ignore that dependency..
Thanks,
Fengguang
---
From: Fengguang Wu
Date: Wed, 25
https://bugs.freedesktop.org/show_bug.cgi?id=52467
--- Comment #5 from Alexandre Demers
2012-07-25 16:31:41 PDT ---
I would consider having a look at bug 43655, it might be related. Could you try
workaround proposed in comment 8 (bug 43655#c8) or comment 13 (bug 43655#c13)?
--
Configure bugmai
From: Alex Deucher
The IntegratedSystemInfo table changed versions
on TN. Update the SS override lookup to handle it.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_atombios.c | 49 ++---
1 files changed, 37 insertions(+), 12 deletions(-)
diff --git a
From: Alex Deucher
The IntegratedSystemInfo table changed versions
on TN. Update the SS override lookup to handle it.
v2: fix copy-paste typo.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_atombios.c | 49 ++---
1 files changed, 37 insertions(+), 12
From: Alex Deucher
Add a new header that defines the AMD ACPI interface used
for laptops, PowerXpress, and chipset specific functionality
and update the current code to use it.
Todo:
- properly verify the ACPI interfaces
- hook up and handle ACPI notifications
- make PX code more robust
- implem
On Wed, Jul 25, 2012 at 10:46:49AM +0200, Ortwin Gl?ck wrote:
> > Does it work if you boot without X and modprobe nouveau manually? If it
> > does,
> > can you disable page flipping in xorg.conf (Option "PageFlip" "0" in nouveau
> > device section) and recheck with X?
>
> It happens long before X
Yet again the too close relationship between the fb helper and the
crtc helper code strikes. This time around the fb helper resets all
encoder->crtc pointers to NULL before starting to set up it's own
mode. Which is total bullocks, because this will clobber the existing
output routing, which the ne
> Does it work if you boot without X and modprobe nouveau manually? If it does,
> can you disable page flipping in xorg.conf (Option "PageFlip" "0" in nouveau
> device section) and recheck with X?
It happens long before X, when the nouveau module is loaded.
> Does it work if you disable accelerat
62 matches
Mail list logo
