Bug#597358: xserver-xorg-video-radeon: Screen brightness flickers when KMS is enabled
On 07.09.2011 13:36, Jonathan Nieder wrote: Hi, Aaron Small wrote[1]: When KMS is enabled, the screen is mostly correct all the time, but the brightness for either the entire screen, or one horizontal line flickers, maybe two to three times per second. Sometimes the change in brightness is just noticeable, and sometimes it is strong enough to look like a horizontal line the full width of the display becomes white. Alex Deucher wrote: Can you try this set of kernel patches? [...] Yes, it will affect all radeons, but in practice it's should really only change things on avivo hw (r5xx+) due to the limited number of post dividers on pre-avivo hardware. It's the same algo that was used originally on all radeons, before I added the newer algo; the only tweak is that we prefer higher post dividers rather than lower ones. In practice, it seems the older one works better. I've tested them on a variety of monitors on all my radeon cards (r1xx-evergreen families). Additionally these patches have fixed several bugs where the newer algo did not work properly. Aaron Small wrote (after testing on top of master): Yes, these patches fix the problem. Stefan, do these three patches look like reasonable candidates for the linux-2.6.32.y-drm33.z tree? They are straightforward backports of patches from mainline (so please feel free to skip the patches and cherry-pick them for yourself :)). This series doesn't include drm/radeon/kms: remove new pll algo because in 2.6.33 the newer algo hadn't been introduced yet. Aaron, if you get a chance to test this series on top of the squeeze kernel, that would be interesting of course. :) Alex Deucher (2): drm/radeon/kms: prefer high post dividers in legacy pll algo drm/radeon/kms: remove some pll algo flags Dan Carpenter (1): drm: radeon: fix sign bug drivers/gpu/drm/radeon/atombios_crtc.c | 14 +- drivers/gpu/drm/radeon/radeon_display.c | 36 ++- drivers/gpu/drm/radeon/radeon_legacy_crtc.c |5 --- drivers/gpu/drm/radeon/radeon_mode.h| 12 ++-- 4 files changed, 12 insertions(+), 55 deletions(-) Looking forward to your thoughts, Jonathan [1] http://bugs.debian.org/597358 Hi Jonathan, only having looked at them very briefly, the first two look quite reasonable. The last one remove some pll algo flags I would want to look at more closely. Just as it is at least bigger from the amount of modifications. Other question would be whether it is required or just cleaning up things. So in general,looks ok. Just need a bit time to look closer into it. And I am travelling at the moment which slows things a bit. -Stefan -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e67dbc3.4090...@canonical.com
Re: [PATCH] drm/i915: disable FBC when more than one pipe is active
On 10/13/2010 04:35 AM, Ben Hutchings wrote:
From: Jesse Barnes jbar...@virtuousgeek.org
commit 9c928d168d4030a230a7a5ee1764721d173f1153 upstream.
We're really supposed to do this to avoid trouble with underflows when
multiple planes are active.
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=26987.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
Tested-by: fangxun xunx.f...@intel.com
Signed-off-by: Eric Anholt e...@anholt.net
[bwh: Backport to DRM 2.6.33 - drop debugfs integration.]
Signed-off-by: Ben Hutchings b...@decadent.org.uk
Looks simple enough, the remaining DRM_DEBUG_KMS looks a bit odd in the patch
but cannot do any harm.
ACK
---
drivers/gpu/drm/i915/intel_display.c | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 26e7d22..1a671b7 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1160,8 +1160,12 @@ static void intel_update_fbc(struct drm_crtc *crtc,
struct drm_framebuffer *fb = crtc-fb;
struct intel_framebuffer *intel_fb;
struct drm_i915_gem_object *obj_priv;
+ struct drm_crtc *tmp_crtc;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
int plane = intel_crtc-plane;
+ int crtcs_enabled = 0;
+
+ DRM_DEBUG_KMS(\n);
if (!i915_powersave)
return;
@@ -1181,10 +1185,20 @@ static void intel_update_fbc(struct drm_crtc *crtc,
* If FBC is already on, we just have to verify that we can
* keep it that way...
* Need to disable if:
+ * - more than one pipe is active
* - changing FBC params (stride, fence, mode)
* - new fb is too large to fit in compressed buffer
* - going to an unsupported config (interlace, pixel multiply, etc.)
*/
+ list_for_each_entry(tmp_crtc, dev-mode_config.crtc_list, head) {
+ if (tmp_crtc-enabled)
+ crtcs_enabled++;
+ }
+ DRM_DEBUG_KMS(%d pipes active\n, crtcs_enabled);
+ if (crtcs_enabled 1) {
+ DRM_DEBUG_KMS(more than one pipe active, disabling
compression\n);
+ goto out_disable;
+ }
if (intel_fb-obj-size dev_priv-cfb_size) {
DRM_DEBUG_KMS(framebuffer too large, disabling
compression\n);
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4cb5664a.6030...@canonical.com
Re: [PATCH] drm/radeon/kms: fix macbookpro connector quirk
On 10/13/2010 04:36 AM, Ben Hutchings wrote: From: Alex Deucher alexdeuc...@gmail.com commit e1e8a5dd4faf356b5d31c620c5787eaa83ee831d upstream. Signed-off-by: Alex Deucher alexdeuc...@gmail.com Signed-off-by: Dave Airlie airl...@redhat.com Signed-off-by: Ben Hutchings b...@decadent.org.uk --- drivers/gpu/drm/radeon/radeon_atombios.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_atombios.c b/drivers/gpu/drm/radeon/radeon_atombios.c index f0ea7f8..1fff955 100644 --- a/drivers/gpu/drm/radeon/radeon_atombios.c +++ b/drivers/gpu/drm/radeon/radeon_atombios.c @@ -264,6 +264,8 @@ static bool radeon_atom_apply_quirks(struct drm_device *dev, if ((supported_device == ATOM_DEVICE_CRT1_SUPPORT) || (supported_device == ATOM_DEVICE_DFP2_SUPPORT)) return false; + if (supported_device == ATOM_DEVICE_CRT2_SUPPORT) + *line_mux = 0x90; } /* ASUS HD 3600 XT board lists the DVI port as HDMI */ Ack -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4cb56660.90...@canonical.com
Re: [PATCH] drm/nouveau: Fix fbcon corruption with font width not divisible by 8
On 10/13/2010 04:37 AM, Ben Hutchings wrote:
From: Marcin Kościelnicki koria...@0x04.net
commit c82b88d578847909797945824851a6a9a84f9c20 upstream.
NV50 is nice and has a switch that autoaligns stuff for us. Pre-NV50,
we need to align input bitmap width manually.
Signed-off-by: Marcin Kościelnicki koria...@0x04.net
Signed-off-by: Francisco Jerez curroje...@riseup.net
Signed-off-by: Ben Skeggs bske...@redhat.com
Signed-off-by: Ben Hutchings b...@decadent.org.uk
---
drivers/gpu/drm/nouveau/nv04_fbcon.c |6 +++---
drivers/gpu/drm/nouveau/nv50_fbcon.c |2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
ACK
diff --git a/drivers/gpu/drm/nouveau/nv04_fbcon.c
b/drivers/gpu/drm/nouveau/nv04_fbcon.c
index 3da90c2..813b25c 100644
--- a/drivers/gpu/drm/nouveau/nv04_fbcon.c
+++ b/drivers/gpu/drm/nouveau/nv04_fbcon.c
@@ -118,8 +118,8 @@ nv04_fbcon_imageblit(struct fb_info *info, const struct
fb_image *image)
return;
}
- width = ALIGN(image-width, 32);
- dsize = (width * image-height) 5;
+ width = ALIGN(image-width, 8);
+ dsize = ALIGN(width * image-height, 32) 5;
if (info-fix.visual == FB_VISUAL_TRUECOLOR ||
info-fix.visual == FB_VISUAL_DIRECTCOLOR) {
@@ -136,8 +136,8 @@ nv04_fbcon_imageblit(struct fb_info *info, const struct
fb_image *image)
((image-dx + image-width) 0x));
OUT_RING(chan, bg);
OUT_RING(chan, fg);
- OUT_RING(chan, (image-height 16) | image-width);
OUT_RING(chan, (image-height 16) | width);
+ OUT_RING(chan, (image-height 16) | image-width);
OUT_RING(chan, (image-dy 16) | (image-dx 0x));
while (dsize) {
diff --git a/drivers/gpu/drm/nouveau/nv50_fbcon.c
b/drivers/gpu/drm/nouveau/nv50_fbcon.c
index 993c712..25a3cd8 100644
--- a/drivers/gpu/drm/nouveau/nv50_fbcon.c
+++ b/drivers/gpu/drm/nouveau/nv50_fbcon.c
@@ -233,7 +233,7 @@ nv50_fbcon_accel_init(struct fb_info *info)
BEGIN_RING(chan, NvSub2D, 0x0808, 3);
OUT_RING(chan, 0);
OUT_RING(chan, 0);
- OUT_RING(chan, 0);
+ OUT_RING(chan, 1);
BEGIN_RING(chan, NvSub2D, 0x081c, 1);
OUT_RING(chan, 1);
BEGIN_RING(chan, NvSub2D, 0x0840, 4);
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4cb56cdb.5050...@canonical.com
Re: [PATCH] drm/nouveau: Fix fbcon corruption with font width not divisible by 8
Patch depends on this simple change which I pulled into the drm33 tree: Author: Matt Turner matts...@gmail.com Date: Wed Feb 24 23:27:10 2010 -0500 drm/nouveau: use ALIGN instead of open coding it CC: Ben Skeggs bske...@redhat.com Signed-off-by: Matt Turner matts...@gmail.com Signed-off-by: Ben Skeggs bske...@redhat.com diff --git a/drivers/gpu/drm/nouveau/nv04_fbcon.c b/drivers/gpu/drm/nouveau/nv04 index fd01caa..3da90c2 100644 --- a/drivers/gpu/drm/nouveau/nv04_fbcon.c +++ b/drivers/gpu/drm/nouveau/nv04_fbcon.c @@ -118,7 +118,7 @@ nv04_fbcon_imageblit(struct fb_info *info, const struct fb_i return; } - width = (image-width + 31) ~31; + width = ALIGN(image-width, 32); dsize = (width * image-height) 5; if (info-fix.visual == FB_VISUAL_TRUECOLOR || diff --git a/drivers/gpu/drm/nouveau/nv50_fbcon.c b/drivers/gpu/drm/nouveau/nv50 index 0f57cdf..993c712 100644 --- a/drivers/gpu/drm/nouveau/nv50_fbcon.c +++ b/drivers/gpu/drm/nouveau/nv50_fbcon.c @@ -109,7 +109,7 @@ nv50_fbcon_imageblit(struct fb_info *info, const struct fb_i return; } - width = (image-width + 31) ~31; + width = ALIGN(image-width, 32); dwords = (width * image-height) 5; BEGIN_RING(chan, NvSub2D, 0x0814, 2); diff --git a/drivers/gpu/drm/nouveau/nv50_instmem.c b/drivers/gpu/drm/nouveau/nv index f0dc4e3..de1f5b0 100644 --- a/drivers/gpu/drm/nouveau/nv50_instmem.c +++ b/drivers/gpu/drm/nouveau/nv50_instmem.c @@ -390,7 +390,7 @@ nv50_instmem_populate(struct drm_device *dev, struct nouveau if (gpuobj-im_backing) return -EINVAL; - *sz = (*sz + (NV50_INSTMEM_PAGE_SIZE-1)) ~(NV50_INSTMEM_PAGE_SIZE-1); + *sz = ALIGN(*sz, NV50_INSTMEM_PAGE_SIZE); if (*sz == 0) return -EINVAL; -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4cb57aa0.7080...@canonical.com
Re: [Lucid] Preparing the next drm33 stable update
On 10/13/2010 04:32 AM, Ben Hutchings wrote: On Tue, 2010-10-12 at 16:16 +0200, Stefan Bader wrote: I started queuing up drm patches for doing a stable update to the drm33 tree (which eventually should go into Lucid). Right now there are 4 relatively straight forward changes that went into .32.y and .35.y, the on that Ben pointed out and another one that fixes a somewhat nasty bug reported to us. This last one is a bit more intrusive but looks more or less ok from glancing at it and it feels like regressions should be quite obvious, if they happen. Any comments as well as nominations for other drm patches are welcome. -Stefan http://kernel.ubuntu.com/git?p=smb/linux-2.6.32.y-drm33.z.git;a=shortlog;h=refs/heads/drm-next We have a few additional fixes which I'll send as replies to this: drm/i915: disable FBC when more than one pipe is active (Closes: #589077) radeon: Fix MacBook Pro connector quirk (Closes: #585943) nouveau: Fix fbcon corruption with font width not divisible by 8 (Closes: #583162) I also intend to apply these radeon changes from Alex Deucher once Linus has pulled them: http://people.freedesktop.org/~agd5f/pll_fixes/. The Debian bug report is #597358. Ben. I am a bit concerned about the pll_fixes. Overall it seems to simplify things quite a bit but it modifies a large portion of code which effects basically all calculations and that feels a bit scary. I would rather wait a bit, even when those have hit Linus tree and maybe it makes sense to ask for Alex opinion on the suitability as stable material. Stefan -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4cb57ed6.6050...@canonical.com
Re: [RFC] Process for maintaining stable updates for drm for Lucid
On 08/30/2010 06:40 PM, Ben Hutchings wrote: On Mon, Aug 30, 2010 at 11:52:10AM +0200, Stefan Bader wrote: On 08/30/2010 02:27 AM, Ben Hutchings wrote: On Sun, 2010-08-29 at 16:26 -0700, Brad Figg wrote: On 08/29/2010 02:17 PM, Ben Hutchings wrote: [...] I'm interested in cooperating in this. I have prepared a git branch with drm changes from 2.6.34.3 up to 2.6.34.6 as a basis for Debian kernel updates. I can make that public and post the patches for review if you want to consider pulling that. [...] We surely are interested in looking through 2.6.34.y drm patches to see which ones we think look good. If you already got a tree prepared there, lets have a look together. I have pushed my branch to: git://git.debian.org/kernel/linux-2.6.git#linux-2.6.32-drm33 (gitweb: http://git.debian.org/?p=kernel/linux-2.6.git;a=shortlog;h=refs/heads/linux-2.6.32-drm33) [...] - patches need to be tested to fix the reported issues - we should prefer patches from upstream - if backports are required or the patch only is relevant to .33, we should require/ask for an ack from a subsystem maintainer. - we probably should require (as upstream stable does) that patches are self contained and small. Otherwise someone will come up with a giant backport just because it fixes and issue. - maybe some sort of review mechanism like Greg does would be useful [...] I agree with all of the above. Ben. Ok cool. Just to summarize, these seem to be the only drm patches which are currently in your tree and not in our 2.6.32-drm33: [-+] drm/radeon/kms: add additional quirk for Acer rv620 laptop [-+] drm/i915: fixup pageflip ringbuffer commands for i8xx [-+] drm/i915: i8xx also doesn't like multiple oustanding pageflips [-+] drm/i915/edp: Flush the write before waiting for PLLs [-+] drm/radeon/kms: disable MSI on IGP chips [-+] drm/radeon/kms: don't enable MSIs on AGP boards [-+] drm/radeon/kms: fix typo in radeon_compute_pll_gain [-+] drm/radeon/kms/DCE3+: switch pads to ddc mode when going i2c [-+] drm/radeon/kms: fix sideport detection on newer rs880 boards [-+] drm: stop information leak of old kernel stack. Does this look complete? Thanks, Stefan -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c7d16b2.2070...@canonical.com
Re: [RFC] Process for maintaining stable updates for drm for Lucid
On 08/30/2010 02:27 AM, Ben Hutchings wrote: On Sun, 2010-08-29 at 16:26 -0700, Brad Figg wrote: On 08/29/2010 02:17 PM, Ben Hutchings wrote: On Thu, Aug 26, 2010 at 10:04:16AM -0500, Steve Conklin wrote: The Lucid kernel consists of the 2.6.32 kernel plus the DRM tree from 2.6.33. Now that GregKH has announced the end of stable updates for the 2.6.33 kernel, the Ubuntu kernel stable maintenance team has been discussing the best way to continue to maintain a set of stable updates for the 2.6.33 DRM. I have prepared a wiki page based on our discussions, and would now like to open discussion to the Ubuntu kernel team mailing list. I'm interested in cooperating in this. I have prepared a git branch with drm changes from 2.6.34.3 up to 2.6.34.6 as a basis for Debian kernel updates. I can make that public and post the patches for review if you want to consider pulling that. Ben. Ben, What are your thoughts on taking drm patches once the 2.6.34 stable tree closes? I think we should keep taking applicable patches from the oldest active stable series after 2.6.33, possibly adding intermediate patches that they depend on (example: da7be68, backported to 2.6.34.6, depends on c414a11, not present in 2.6.33.y). The Debian kernel update policy is: http://wiki.debian.org/DebianKernelPatchAcceptanceGuidelines. Ben. We surely are interested in looking through 2.6.34.y drm patches to see which ones we think look good. If you already got a tree prepared there, lets have a look together. Our policies for patches are close there and also close to what upstream stable has. While 2.6.33.y existed we chose to require people to submit it to upstream stable as this ensured at least that subsystem maintainers would be involved in the review and could intervene if things would not be applicable. And sending patches to upstream stable also ensures fixes would go upstream (if still being applicable). So the big question is how we go forward now that .33 and .34 have gone out of support upstream? Some thoughts I have here are: - patches need to be tested to fix the reported issues - we should prefer patches from upstream - if backports are required or the patch only is relevant to .33, we should require/ask for an ack from a subsystem maintainer. - we probably should require (as upstream stable does) that patches are self contained and small. Otherwise someone will come up with a giant backport just because it fixes and issue. - maybe some sort of review mechanism like Greg does would be useful We had been talking about the idea of looking at upstream stable patches for drm in general. Though our feeling was that the more into the future we go, the less applicable are patches there in general. And even if they apply, they might depend on changes not present and thus break things. So we basically need a way to proceed in a manner that allows us to get fixes while trying to keep regressions out. Ideally we would have subsystem maintainers support by having them add comments about .33 compliance when submitting to upstream stable. But I guess that is too much to ask for. I think we (Debian and Ubuntu) can gain a lot from working together on this. And Ben, feel free to bring up anything that you think won't work for Debian or things you think would be better. We basically want to have an upstream stable LTS for drm in .33 while not having the benefit of having the same upstream support as Greg does (maybe yet). Stefan -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c7b7f4a.6060...@canonical.com
Re: DRM stable updates beyond 2.6.33.6
On 08/08/2010 07:25 AM, Ben Hutchings wrote: David, As you know, Debian and Ubuntu (and others?) opted to use 2.6.32 as the basis for a stable release but to take DRM from 2.6.33. Now that the stable 2.6.33 series is over, we need some other means to communicate the most important bug fixes for DRM that should go into these distributions. Do you have any suggestions for how we should to this? Could you maintain a drm-2.6.33 branch? Ben. Hi Ben, actually I am already maintaining a branch which combines the 2.6.32.y tree with a 2.6.33 base of drm which I now moved forward to have .34 patches of drm included. I intended to go ahead like Greg does for .27 and get as much of the later stable patches back into that tree. If I miss something, please let me know. -Stefan http://git.kernel.org/?p=linux/kernel/git/smb/linux-2.6.32.y-drm33.z.git;a=summary -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c5fb0f1.4040...@canonical.com
Re: Kernel packagers' list
Tim Gardner wrote: Ben Hutchings wrote: Following on from discussions at the Linux Plumbers Conference, I'd like to remind you all of the kernel packagers' list: kernel-packag...@vger.kernel.org http://vger.kernel.org/vger-lists.html#kernel-packagers It is currently inactive but could be useful for cross-distro cooperation on packaging. Ben. I've subscribed to kernel-packag...@vger.kernel.org. Finally came back to do so, too. -- When all other means of communication fail, try words! -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
