[PATCH] drm/i915: Revive combination mode for backlight control
On Fri, 11 Mar 2011 02:23:08 +0100 (CET), "Indan Zupancic" wrote: > Some nitpicks below. I know you're just restoring the original code, > but if we improve it we can as well do it now. Let's pend these changes until after 2.6.38; the backlight code is fragile enough without trying to 'clean it up' at this point in the release cycle. -- keith.packard at intel.com -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20110310/70877185/attachment-0001.pgp>
[Bug 35194] New: [r600g] Evergreen - failed to map bo
https://bugs.freedesktop.org/show_bug.cgi?id=35194 Summary: [r600g] Evergreen - failed to map bo Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: rubenf3000 at gmail.com Created an attachment (id=44337) --> (https://bugs.freedesktop.org/attachment.cgi?id=44337) output generated with MESA_GLSL=dump The game "Back to the Future: the game" crashes at many points with the message: radeon_bo_fixed_map failed to map bo EE radeon_bo.c:120 radeon_bo - failed to map bo It usually happens at random moments, altough there are specific actions that trigger the crash reliably. It works correctly using llvmpipe. The "failed to map" message originates in the function "radeon_bo_fixed_map" in "mesa/src/gallium/winsys/r600/drm/radeon_bo.c", when doing a call to mmap; upon debugging, I found it fails with ENOMEM, despite having more than enough free RAM available at the time (it only allocates half a megabyte, and I had almost 1GB of free RAM at the moment of crashing) Upon further inspection, I found that, at the moment of the crash, the game had almost exactly 1 gigabyte of buffer objects mmap'd; could it have something to do with my card having 1GB of video RAM? seems unlikely, since mmap maps to system memory. Graphics Card: ATI Technologies Inc Juniper [Radeon HD 5750 Series] CPU: Intel Core Duo 1.8 Ghz, 2.5 GB RAM Linux kernel 2.6.37, libdrm 2.4.24 Latest Mesa git -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 35144] r300g should advertise GL_ARB_half_float_vertex on rv350
https://bugs.freedesktop.org/show_bug.cgi?id=35144 Marek Ol??k changed: What|Removed |Added Status|NEW |RESOLVED Resolution||NOTABUG --- Comment #3 from Marek Ol??k 2011-03-10 21:33:39 PST --- I am closing this bug. Let me know if you need any of those extensions. RV350 is too slow for unigine anyway. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 32945] [RADEON:KMS:R300G] HiZ: Weird behavior with 3 pipes
https://bugs.freedesktop.org/show_bug.cgi?id=32945 --- Comment #24 from Marek Ol??k 2011-03-10 19:40:15 PST --- (In reply to comment #23) > Created an attachment (id=44333) View: https://bugs.freedesktop.org/attachment.cgi?id=44333 Review: https://bugs.freedesktop.org/review?bug=32945=44333 > Possible fix > > The attached patch fixes the issue with shadowtex for me. Sven, can you try it > and also see if doom3 is still OK with it ? > > With 3 pipes values are NPOT, so align() is not suitable in some places I > think. Pushed, thanks a lot! -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] drm/i915: Revive combination mode for backlight control
On Thu, Mar 10, 2011 at 5:23 PM, Indan Zupancic wrote: > > After this patch, combined with my new patch > > "drm/i915: Fix DPMS and suspend interaction for intel_panel.c" > > all known backlight problems should be fixed. Btw, can you repost that one as a new email (and cc keithp too)? I think it got hidden in the other thread by different subject line. Jesse, did you take a look at that one? It was in the thread with a subject like "[PATCH] fix backlight brightness on intel LVDS panel after reopening lid". Search for When suspending intel_panel_disable_backlight() is never called, but intel_panel_enable_backlight() is called at resume. With the effect that if the brightness was ever changed after screen blanking, the wrong brightness gets restored at resume time. in your mailbox. Linus
[Bug 34137] Kernel null pointer dereference with 2.6.38_rc4, pageflip, Radeon 6310, KDE
https://bugs.freedesktop.org/show_bug.cgi?id=34137 --- Comment #1 from Dave Airlie 2011-03-10 16:07:15 PST --- does this patch help? http://people.freedesktop.org/~airlied/scratch/0001-radeon-add-pageflip-hooks-for-fusion.patch -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
vblank problem (and proposed fix) on crtc > 1
On Don, 2011-03-10 at 07:32 -0600, Ilija Hadzic wrote:
>
> On Thu, 10 Mar 2011, Michel [ISO-8859-1] Dnzer wrote:
>
> > I'm afraid I don't really like this. Apart from the ugly bogus error
> > message, the probes could fail for other reasons, e.g. at some point we
> > might want to return an error when the ioctl is called for a CRTC which
> > is currently disabled, to avoid the hang you were getting for CRTC 1.
>
> Your example actually speaks in favor of probing. Let's say that the
> future kernel starts returning an error for disabled CRTC and you don't do
> any probing. DDX will start calling vblank waits on disabled CRTC (just
> like it's doing now) and spam the kernel with errors.
No, userspace shouldn't call the ioctl for a disabled CRTC during normal
operation, that would be a bug of its own. However, a CRTC could be
disabled during the probe but get enabled later, e.g. due to
hot-plugging a display.
> > Dave's drm-next tree actually has a new DRM_IOCTL_GET_CAP ioctl, which
> > could be used for detecting this capability. It might even be possible
> > to handle old kernels transparently in drmWaitVBlank(), but I'm not sure
> > offhand if that would be better overall than doing it in the driver
> > code.
>
> This argument is self defeating. The purpose of the probing is to check
> for the old kernel. If I have DRM_IOCTL_GET_CAP, that means that I have a
> new kernel so probing will just work. If I have an old kernel then I don't
> have DRM_IOCTL_GET_CAP ioctl, so attemting to use it will result in an
> error from the kernel anyway. It makes no sense to me to cause an error
> in one ioctl so that you would prevent an error in other ioctl.
The difference is that there should be no bogus error message in dmesg,
avoiding spurious bug reports.
> >> + if (info->high_crtc_works) {
> >> + high_crtc = (crtc << DRM_VBLANK_HIGH_CRTC_SHIFT) &
> >> + DRM_VBLANK_HIGH_CRTC_MASK;
> >> + } else vbl.request.type |= DRM_VBLANK_SECONDARY;
> >
> > Waiting on a random other CRTC makes no sense. If you know you can't
> > wait on the given CRTC, don't wait at all.
> >
>
> It's not random CRTC, but it's what today's DDX and DRM call "secondary"
> CRTC. I intentionally did this for two reasons. First, this is the
> behavior that is identical to what we see today, and I prefer to preserve
> the same behavior if either component is old (DDX or kernel), rather than
> have different behavior for different combinations of old/new.
I don't see the value in conserving fundamentally broken behaviour.
> The second reason is pragmatic, if you want to not call wait_vblank at
> all and make sure you are safe to whatever the code above you is doing
> and not return an error you have to make up the sequence numbers and
> timestamps (and probably keep track of them) and that's much more
> radical modification to the DDX.
You could probably always return 0, or previous value + 1 or whatever,
that's no more wrong than the values from a different CRTC.
> >> + vbl.request.sequence = 0;
> >> + if (drmWaitVBlank(info->dri2.drm_fd, )) {
> >> + xf86DrvMsg(pScrn->scrnIndex, X_WARNING, "Kernel rejects
> >> VBLANK request on CRTC %d\n", c);
> >> + info->high_crtc_works = FALSE;
> >
> > Should break out of the for loop at this point.
>
> This was also intentional. I want to see in Xorg log file the full list of
> crtcs that rejected the vblank wait request. It comes handy for analyzing
> the problems and/or bugs.
Then at the very least the claim that 'an error message will appear in
the kernel only once at start up time' is wrong, there will actually be
four of them on old kernels.
--
Earthling Michel D?nzer |http://www.vmware.com
Libre software enthusiast | Debian, X and DRI developer
[Bug 35187] New: r600g : PIPE_CAP_ARRAY_TEXTURES not manage
https://bugs.freedesktop.org/show_bug.cgi?id=35187 Summary: r600g : PIPE_CAP_ARRAY_TEXTURES not manage Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: minor Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: xoddark at gmail.com When I lunch hugin i have this warning in console (one time) : EE r600_pipe.c:325 r600_get_param - r600: unknown param 36 Apparently param 36 is PIPE_CAP_ARRAY_TEXTURES. Environment : - ubuntu 10.10 with kernel 2.6.37.1 - git version of drm, mesa and xf86-video-ati -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] drm/i915: fix corruptions on i8xx due to relaxed fencing
Am Do, 10.03.2011, 11:36 schrieb Indan Zupancic: > On Thu, March 10, 2011 08:52, Daniel Vetter wrote: >> [Aside: This only happens if you have new enough userspace that supports >> relaxed tiling. Old userspace and new kernels are _not_ broken.] > > Yes, I noticed it got reverted when digging into git log, but the > commit message only said it broke gen4+, not how gen2 should be > unbroken after the revert. > > Which versions fix this, just for reference? git master branch of libdrm and xf86-video-intel newer than 2011-02-22. -Daniel
[PATCH] drm/i915: Revive combination mode for backlight control
This reverts commit 951f3512dba5bd44cda3e5ee22b4b522e4bb09fb
drm/i915: Do not handle backlight combination mode specially
since this commit introduced other regressions due to untouched LBPC
register, e.g. the backlight dimmed after resume.
In addition to the revert, this patch includes a fix for the original
issue (weird backlight levels) by removing the wrong bit shift for
computing the current backlight level.
Also, including typo fixes (lpbc -> lbpc).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=34524
Acked-by: Indan Zupancic
Cc:
Signed-off-by: Takashi Iwai
---
drivers/gpu/drm/i915/i915_reg.h| 10 ++
drivers/gpu/drm/i915/intel_panel.c | 36
2 files changed, 46 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 3e6f486..2abe240 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1553,7 +1553,17 @@
/* Backlight control */
#define BLC_PWM_CTL0x61254
+#define BACKLIGHT_MODULATION_FREQ_SHIFT (17)
#define BLC_PWM_CTL2 0x61250 /* 965+ only */
+#define BLM_COMBINATION_MODE (1 << 30)
+/*
+ * This is the most significant 15 bits of the number of backlight cycles in a
+ * complete cycle of the modulated backlight control.
+ *
+ * The actual value is this field multiplied by two.
+ */
+#define BACKLIGHT_MODULATION_FREQ_MASK (0x7fff << 17)
+#define BLM_LEGACY_MODE (1 << 16)
/*
* This is the number of cycles out of the backlight modulation cycle for which
* the backlight is on.
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_panel.c
index d860abe..f8f86e5 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -30,6 +30,8 @@
#include "intel_drv.h"
+#define PCI_LBPC 0xf4 /* legacy/combination backlight modes */
+
void
intel_fixed_panel_mode(struct drm_display_mode *fixed_mode,
struct drm_display_mode *adjusted_mode)
@@ -110,6 +112,19 @@ done:
dev_priv->pch_pf_size = (width << 16) | height;
}
+static int is_backlight_combination_mode(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev->dev_private;
+
+ if (INTEL_INFO(dev)->gen >= 4)
+ return I915_READ(BLC_PWM_CTL2) & BLM_COMBINATION_MODE;
+
+ if (IS_GEN2(dev))
+ return I915_READ(BLC_PWM_CTL) & BLM_LEGACY_MODE;
+
+ return 0;
+}
+
static u32 i915_read_blc_pwm_ctl(struct drm_i915_private *dev_priv)
{
u32 val;
@@ -166,6 +181,9 @@ u32 intel_panel_get_max_backlight(struct drm_device *dev)
if (INTEL_INFO(dev)->gen < 4)
max &= ~1;
}
+
+ if (is_backlight_combination_mode(dev))
+ max *= 0xff;
}
DRM_DEBUG_DRIVER("max backlight PWM = %d\n", max);
@@ -183,6 +201,14 @@ u32 intel_panel_get_backlight(struct drm_device *dev)
val = I915_READ(BLC_PWM_CTL) & BACKLIGHT_DUTY_CYCLE_MASK;
if (IS_PINEVIEW(dev))
val >>= 1;
+
+ if (is_backlight_combination_mode(dev)){
+ u8 lbpc;
+
+ val &= ~1;
+ pci_read_config_byte(dev->pdev, PCI_LBPC, );
+ val *= lbpc;
+ }
}
DRM_DEBUG_DRIVER("get backlight PWM = %d\n", val);
@@ -205,6 +231,16 @@ void intel_panel_set_backlight(struct drm_device *dev, u32
level)
if (HAS_PCH_SPLIT(dev))
return intel_pch_panel_set_backlight(dev, level);
+
+ if (is_backlight_combination_mode(dev)){
+ u32 max = intel_panel_get_max_backlight(dev);
+ u8 lbpc;
+
+ lbpc = level * 0xfe / max + 1;
+ level /= lbpc;
+ pci_write_config_byte(dev->pdev, PCI_LBPC, lbpc);
+ }
+
tmp = I915_READ(BLC_PWM_CTL);
if (IS_PINEVIEW(dev)) {
tmp &= ~(BACKLIGHT_DUTY_CYCLE_MASK - 1);
--
1.7.4.1
[PATCH] fix backlight brightness on intel LVDS panel after reopening lid
At Thu, 10 Mar 2011 11:06:28 +0100 (CET),
Indan Zupancic wrote:
>
> On Thu, March 10, 2011 09:25, Takashi Iwai wrote:
> > At Thu, 10 Mar 2011 08:49:37 +0100,
> > Takashi Iwai wrote:
> >>
> >> At Thu, 10 Mar 2011 06:50:09 +0100 (CET),
> >> Indan Zupancic wrote:
> >> >
> >> > Hello,
> >> >
> >> > On Fri, March 4, 2011 19:47, Linus Torvalds wrote:
> >> > > Alex, can you confirm that the revert of 951f3512dba5 plus the
> >> > > one-liner patch from Takashi that Indan quoted also works for you?
> >> > >
> >> > > Linus
> >> > >
> >> > > On Thu, Mar 3, 2011 at 10:53 PM, Indan Zupancic
> >> > > wrote:
> >> > >>
> >> > >> So please revert my patch and apply Takashi Iwai's, which fixes the
> >> > >> most immediate bug without changing anything else. This should go
> >> > >> in stable too.
> >> > >
> >> >
> >> > I found another backlight bug:
> >> >
> >> > When suspending intel_panel_disable_backlight() is never called,
> >> > but intel_panel_enable_backlight() is called at resume. With the
> >> > effect that if the brightness was ever changed after screen
> >> > blanking, the wrong brightness gets restored.
> >> >
> >> > This explains the weird behaviour I've seen. I didn't see it with
> >> > combination mode, because then the brightness is always the same
> >> > (zero or the maximum, the BIOS only uses LBPC on my system.) I'll
> >> > send a patch in a moment.
> >> >
> >> > Alternative for reverting the combination mode removal (I can also
> >> > redo the patch against the revert and Takashi's patch, if that's
> >> > preferred):
> >> >
> >> > --
> >> >
> >> > drm/i915: Do handle backlight combination mode specially
> >> >
> >> > Add back the combination mode check, but with slightly cleaner code
> >> > and the weirdness removed: No val >>= 1, but also no val &= ~1. The
> >> > old code probably confused bit 0 with BLM_LEGACY_MODE, which is bit 16.
> >> > The other change is clearer calculations: Just check for zero level
> >> > explicitly instead of avoiding the divide-by-zero.
> >> >
> >> > Signed-off-by: Indan Zupancic
> >> >
> >> > ---
> >> >
> >> > diff --git a/drivers/gpu/drm/i915/intel_panel.c
> >> > b/drivers/gpu/drm/i915/intel_panel.c
> >> > index d860abe..b05631a 100644
> >> > --- a/drivers/gpu/drm/i915/intel_panel.c
> >> > +++ b/drivers/gpu/drm/i915/intel_panel.c
> >> > @@ -30,6 +30,10 @@
> >> >
> >> > #include "intel_drv.h"
> >> >
> >> > +#define PCI_LBPC 0xf4 /* legacy/combination backlight modes */
> >> > +#define BLM_COMBINATION_MODE (1 << 30)
> >> > +#define BLM_LEGACY_MODE (1 << 16)
> >> > +
> >> > void
> >> > intel_fixed_panel_mode(struct drm_display_mode *fixed_mode,
> >> > struct drm_display_mode *adjusted_mode)
> >> > @@ -110,6 +114,22 @@ done:
> >> > dev_priv->pch_pf_size = (width << 16) | height;
> >> > }
> >> >
> >> > +/*
> >> > + * What about gen 3? If there are no gen 3 systems with ASLE,
> >> > + * then it doesn't matter, as we don't need to change the
> >> > + * brightness. But then the gen 2 check can be removed too.
> >> > + */
> >> > +static int is_backlight_combination_mode(struct drm_device *dev)
> >> > +{
> >> > +struct drm_i915_private *dev_priv = dev->dev_private;
> >> > +
> >> > +if (INTEL_INFO(dev)->gen >= 4)
> >> > +return I915_READ(BLC_PWM_CTL2) & BLM_COMBINATION_MODE;
> >> > +if (IS_GEN2(dev))
> >> > +return I915_READ(BLC_PWM_CTL) & BLM_LEGACY_MODE;
> >> > +return 0;
> >> > +}
> >> > +
> >> > static u32 i915_read_blc_pwm_ctl(struct drm_i915_private *dev_priv)
> >> > {
> >> > u32 val;
> >> > @@ -163,9 +183,12 @@ u32 intel_panel_get_max_backlight(struct drm_device
> >> > *dev)
> >> > max >>= 17;
> >> > } else {
> >> > max >>= 16;
> >> > +/* Ignore BLM_LEGACY_MODE bit */
> >> > if (INTEL_INFO(dev)->gen < 4)
> >> > max &= ~1;
> >> > }
> >> > +if (is_backlight_combination_mode(dev))
> >> > +max *= 0xff;
> >> > }
> >> >
> >> > DRM_DEBUG_DRIVER("max backlight PWM = %d\n", max);
> >> > @@ -183,6 +206,12 @@ u32 intel_panel_get_backlight(struct drm_device
> >> > *dev)
> >> > val = I915_READ(BLC_PWM_CTL) &
> >> > BACKLIGHT_DUTY_CYCLE_MASK;
> >> > if (IS_PINEVIEW(dev))
> >> > val >>= 1;
> >> > +if (is_backlight_combination_mode(dev)){
> >> > +u8 lbpc;
> >> > +
> >> > +pci_read_config_byte(dev->pdev, PCI_LBPC,
> >> > );
> >> > +val *= lbpc;
> >> > +}
> >> > }
> >> >
> >> > DRM_DEBUG_DRIVER("get backlight PWM = %d\n", val);
> >> > @@ -205,6 +234,15 @@ void intel_panel_set_backlight(struct drm_device
> >> > *dev, u32 level)
> >> >
> >> > if
[PATCH] fix backlight brightness on intel LVDS panel after reopening lid
At Thu, 10 Mar 2011 09:45:18 +0100 (CET),
Indan Zupancic wrote:
>
> On Thu, March 10, 2011 08:49, Takashi Iwai wrote:
> > At Thu, 10 Mar 2011 06:50:09 +0100 (CET),
> > Indan Zupancic wrote:
> >>
> >> Hello,
> >>
> >> On Fri, March 4, 2011 19:47, Linus Torvalds wrote:
> >> > Alex, can you confirm that the revert of 951f3512dba5 plus the
> >> > one-liner patch from Takashi that Indan quoted also works for you?
> >> >
> >> > Linus
> >> >
> >> > On Thu, Mar 3, 2011 at 10:53 PM, Indan Zupancic wrote:
> >> >>
> >> >> So please revert my patch and apply Takashi Iwai's, which fixes the
> >> >> most immediate bug without changing anything else. This should go
> >> >> in stable too.
> >> >
> >>
> >> I found another backlight bug:
> >>
> >> When suspending intel_panel_disable_backlight() is never called,
> >> but intel_panel_enable_backlight() is called at resume. With the
> >> effect that if the brightness was ever changed after screen
> >> blanking, the wrong brightness gets restored.
> >>
> >> This explains the weird behaviour I've seen. I didn't see it with
> >> combination mode, because then the brightness is always the same
> >> (zero or the maximum, the BIOS only uses LBPC on my system.) I'll
> >> send a patch in a moment.
> >>
> >> Alternative for reverting the combination mode removal (I can also
> >> redo the patch against the revert and Takashi's patch, if that's
> >> preferred):
> >>
> >> --
> >>
> >> drm/i915: Do handle backlight combination mode specially
> >>
> >> Add back the combination mode check, but with slightly cleaner code
> >> and the weirdness removed: No val >>= 1, but also no val &= ~1. The
> >> old code probably confused bit 0 with BLM_LEGACY_MODE, which is bit 16.
> >> The other change is clearer calculations: Just check for zero level
> >> explicitly instead of avoiding the divide-by-zero.
> >>
> >> Signed-off-by: Indan Zupancic
> >>
> >> ---
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_panel.c
> >> b/drivers/gpu/drm/i915/intel_panel.c
> >> index d860abe..b05631a 100644
> >> --- a/drivers/gpu/drm/i915/intel_panel.c
> >> +++ b/drivers/gpu/drm/i915/intel_panel.c
> >> @@ -30,6 +30,10 @@
> >>
> >> #include "intel_drv.h"
> >>
> >> +#define PCI_LBPC 0xf4 /* legacy/combination backlight modes */
> >> +#define BLM_COMBINATION_MODE (1 << 30)
> >> +#define BLM_LEGACY_MODE (1 << 16)
> >> +
> >> void
> >> intel_fixed_panel_mode(struct drm_display_mode *fixed_mode,
> >> struct drm_display_mode *adjusted_mode)
> >> @@ -110,6 +114,22 @@ done:
> >>dev_priv->pch_pf_size = (width << 16) | height;
> >> }
> >>
> >> +/*
> >> + * What about gen 3? If there are no gen 3 systems with ASLE,
> >> + * then it doesn't matter, as we don't need to change the
> >> + * brightness. But then the gen 2 check can be removed too.
> >> + */
> >> +static int is_backlight_combination_mode(struct drm_device *dev)
> >> +{
> >> + struct drm_i915_private *dev_priv = dev->dev_private;
> >> +
> >> + if (INTEL_INFO(dev)->gen >= 4)
> >> + return I915_READ(BLC_PWM_CTL2) & BLM_COMBINATION_MODE;
> >> + if (IS_GEN2(dev))
> >> + return I915_READ(BLC_PWM_CTL) & BLM_LEGACY_MODE;
> >> + return 0;
> >> +}
> >> +
> >> static u32 i915_read_blc_pwm_ctl(struct drm_i915_private *dev_priv)
> >> {
> >>u32 val;
> >> @@ -163,9 +183,12 @@ u32 intel_panel_get_max_backlight(struct drm_device
> >> *dev)
> >>max >>= 17;
> >>} else {
> >>max >>= 16;
> >> + /* Ignore BLM_LEGACY_MODE bit */
> >>if (INTEL_INFO(dev)->gen < 4)
> >>max &= ~1;
> >>}
> >> + if (is_backlight_combination_mode(dev))
> >> + max *= 0xff;
> >>}
> >>
> >>DRM_DEBUG_DRIVER("max backlight PWM = %d\n", max);
> >> @@ -183,6 +206,12 @@ u32 intel_panel_get_backlight(struct drm_device *dev)
> >>val = I915_READ(BLC_PWM_CTL) & BACKLIGHT_DUTY_CYCLE_MASK;
> >>if (IS_PINEVIEW(dev))
> >>val >>= 1;
> >> + if (is_backlight_combination_mode(dev)){
> >> + u8 lbpc;
> >> +
> >> + pci_read_config_byte(dev->pdev, PCI_LBPC, );
> >> + val *= lbpc;
> >> + }
> >>}
> >>
> >>DRM_DEBUG_DRIVER("get backlight PWM = %d\n", val);
> >> @@ -205,6 +234,15 @@ void intel_panel_set_backlight(struct drm_device
> >> *dev, u32 level)
> >>
> >>if (HAS_PCH_SPLIT(dev))
> >>return intel_pch_panel_set_backlight(dev, level);
> >> +
> >> + if (level && is_backlight_combination_mode(dev)){
> >> + u32 max = intel_panel_get_max_backlight(dev);
> >> + u8 lpbc;
> >> +
> >> + lpbc = level * 0xff / max;
> >> + level /= lpbc;
> >
> > Hmm, I don't think this calculation is correct. This would result
> > in level of opregion over its limit. For example, assume the level
> > max = 100, so total max = 25500. Passing level=150 here will
vblank problem (and proposed fix) on crtc > 1
On Mit, 2011-03-09 at 11:33 -0600, Ilija Hadzic wrote:
>
> So what I did is to actually probe the kernel at screen init time.
> When the screen is initialized, the DDX checks if the GPU has more than
> two CRTCs and tries a dummy vblank wait on all crtcs > 1. If any
> of them fails, it falls back to the old method of using only
> primary/secondary flag.
I'm afraid I don't really like this. Apart from the ugly bogus error
message, the probes could fail for other reasons, e.g. at some point we
might want to return an error when the ioctl is called for a CRTC which
is currently disabled, to avoid the hang you were getting for CRTC 1.
Dave's drm-next tree actually has a new DRM_IOCTL_GET_CAP ioctl, which
could be used for detecting this capability. It might even be possible
to handle old kernels transparently in drmWaitVBlank(), but I'm not sure
offhand if that would be better overall than doing it in the driver
code.
Some detailed technical comments:
> diff --git a/src/radeon_dri2.c b/src/radeon_dri2.c
> index 66df03c..c45abe6 100644
> --- a/src/radeon_dri2.c
> +++ b/src/radeon_dri2.c
> @@ -1145,8 +1193,15 @@ static int radeon_dri2_schedule_swap(ClientPtr client,
> DrawablePtr draw,
> vbl.request.type = DRM_VBLANK_ABSOLUTE | DRM_VBLANK_EVENT;
> if (flip == 0)
> vbl.request.type |= DRM_VBLANK_NEXTONMISS;
> -if (crtc > 0)
> +if (crtc == 1)
> vbl.request.type |= DRM_VBLANK_SECONDARY;
> +else if (crtc > 1) {
> + if (info->high_crtc_works) {
> + high_crtc = (crtc << DRM_VBLANK_HIGH_CRTC_SHIFT) &
> + DRM_VBLANK_HIGH_CRTC_MASK;
> + } else vbl.request.type |= DRM_VBLANK_SECONDARY;
Waiting on a random other CRTC makes no sense. If you know you can't
wait on the given CRTC, don't wait at all.
> @@ -1261,6 +1319,22 @@ radeon_dri2_screen_init(ScreenPtr pScreen)
> xf86DrvMsg(pScrn->scrnIndex, X_WARNING, "You need a newer kernel
> for sync extension\n");
> }
>
> +if (info->drmmode.mode_res->count_crtcs > 2) {
> + xf86DrvMsg(pScrn->scrnIndex, X_INFO, "GPU with %d CRTCs found,
> probing VBLANKs on CRTC>1\n",
> + info->drmmode.mode_res->count_crtcs);
> + info->high_crtc_works = TRUE;
> + for (c=2; cdrmmode.mode_res->count_crtcs; c++) {
> + vbl.request.type = DRM_VBLANK_RELATIVE;
> + vbl.request.type |= (c << DRM_VBLANK_HIGH_CRTC_SHIFT) &
> DRM_VBLANK_HIGH_CRTC_MASK;
> + vbl.request.sequence = 0;
> + if (drmWaitVBlank(info->dri2.drm_fd, )) {
> + xf86DrvMsg(pScrn->scrnIndex, X_WARNING, "Kernel rejects
> VBLANK request on CRTC %d\n", c);
> + info->high_crtc_works = FALSE;
Should break out of the for loop at this point.
> + }
> + }
> + if (info->high_crtc_works) xf86DrvMsg(pScrn->scrnIndex, X_INFO,
> "VBLANK request accepted on all CRTCs\n");
The statement guarded by the if condition needs to go on a new line, and
please don't add trailing whitespace. Also, again, please match the
indentation of the surrounding code.
--
Earthling Michel D?nzer |http://www.vmware.com
Libre software enthusiast | Debian, X and DRI developer
[Bug 32945] [RADEON:KMS:R300G] HiZ: Weird behavior with 3 pipes
https://bugs.freedesktop.org/show_bug.cgi?id=32945 --- Comment #23 from Nicolas Peninguy 2011-03-10 13:13:28 PST --- Created an attachment (id=44333) View: https://bugs.freedesktop.org/attachment.cgi?id=44333 Review: https://bugs.freedesktop.org/review?bug=32945=44333 Possible fix The attached patch fixes the issue with shadowtex for me. Sven, can you try it and also see if doom3 is still OK with it ? With 3 pipes values are NPOT, so align() is not suitable in some places I think. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
vblank problem (and proposed fix) on crtc > 1
On Thu, 10 Mar 2011, Michel [ISO-8859-1] D?nzer wrote: > No, userspace shouldn't call the ioctl for a disabled CRTC during normal > operation, that would be a bug of its own. Well, that's exactly what DDX is doing today. Try this experiment: open a terminal window and run glxgears in it and observer the frame rate synced up to your monitor. Then in another terminal window type 'xset dpms force off' (or go to dpms off state any other way you want). The screen goes blank (disabled CRTC). Wait a while and then move your mouse to exit the disabled state. Notice the low frame rate reported by glxgears in one line. That's because glxSwapBuffers was blocked while screen was in power-down state. Now I don't know if this behavior is intentional (I know your opinion based on the above), but it looks logical to me: if the screen is off and GLX attempts to wait on it, it gets what it deserves. If this is the real intent, then kernel returning error on disabled screen would break it (the application would just start to "rush" through rendering at max speed and eat up the I/O and CPU bandwidth for something that you can't see on the screen). Anyway, this is a topic for a separate thread. I tend to agree that one day maybe the error is returned for some other reason (where your example may have been a bad one) so I will look into DRM_IOCTL_GET_CAP. > > The difference is that there should be no bogus error message in dmesg, > avoiding spurious bug reports. > That I agree and if GET_CAP ioctl is appropriate here, I'll change to that. There will still be an error message in the kernel at probing time, but hopefully a more meaningfull one. I guess the Xorg log message should then be something along the "you need a newer kernel" lines. Agreed ? >> the same behavior if either component is old (DDX or kernel), rather than >> have different behavior for different combinations of old/new. > > I don't see the value in conserving fundamentally broken behaviour. > There is even less value in introducing a wider variety of broken behaviors. Returning immediately, would cause the application to rush at full speed through buffer swaps and eat up the CPU and I/O bandwidth. It think that there are equal number of ppl. who would argue for that as those who would argue for the opposite. > > You could probably always return 0, or previous value + 1 or whatever, > that's no more wrong than the values from a different CRTC. > What I could do doesn't matter that much, because whatever I do would not result it fully functional system unless both the DDX and the kernel match in capabilities. So I go for the one that is less likely to introduce new bugs or unpredictable behavior. > > Then at the very least the claim that 'an error message will appear in > the kernel only once at start up time' is wrong, there will actually be > four of them on old kernels. > More precisely: num_crtcs - 2 times. Use word 'once' used in a liberal sense ;-) it doesn't happen repetatively during the normal operation. At least, if I can use DRM_IOCTL_GET_CAP (which I still have to check), the message will be more meaningful.
[Bug 35183] New: system freezes with 2.6.38-rc kernel and kms pageflip enabled
https://bugs.freedesktop.org/show_bug.cgi?id=35183 Summary: system freezes with 2.6.38-rc kernel and kms pageflip enabled Product: DRI Version: unspecified Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: aaalmosss at gmail.com The system freezes completely after a few 3d operations (like changing the desktop in compiz a couple of times). No error message appears in dmesg or syslog. Tried both rc7 and rc8 and the drm-radeon-testing branch. If I disable kms pageflip in xorg.conf, the system seems stable. I also tried setting radeon.agpmode=-1, but didn't help. Hardware: radeon 9600xt (rv350 agp) software: latest debian unstable (libdrm2 2.4.23, xserver-xorg 7.6, xserver-xorg-video-radeon 6.14.0) Considering that most distributions use compositing wm by default, and kms pageflip is also enabled by default, this seems like a serious problem. Bugs 21472, 34137, 34643 might be related, but I'm not sure. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 32312] [RADEON:KMS:R600G] openvg rendering is broken
https://bugs.freedesktop.org/show_bug.cgi?id=32312 --- Comment #8 from Sergey Kondakov 2011-03-10 12:25:14 PST --- yes, still no text in "text" demo. and it's that way for both r600g & r300g even if i execute with LIBGL_ALWAYS_SOFTWARE=1. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] drm/i915: Revive combination mode for backlight control
On Thu, 10 Mar 2011 14:02:12 +0100, Takashi Iwai wrote: > This reverts commit 951f3512dba5bd44cda3e5ee22b4b522e4bb09fb > > drm/i915: Do not handle backlight combination mode specially > > since this commit introduced other regressions due to untouched LBPC > register, e.g. the backlight dimmed after resume. > > In addition to the revert, this patch includes a fix for the original > issue (weird backlight levels) by removing the wrong bit shift for > computing the current backlight level. > Also, including typo fixes (lpbc -> lbpc). > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=34524 > Acked-by: Indan Zupancic > Cc: > Signed-off-by: Takashi Iwai This looks good, and ensures that LBPC ranges from 0 - 0xfe as required. The one thing we want is a comment that explains > + val &= ~1; The reason for this is that some ancient platforms wire this bit to be "go to max backlight", or at least that's why this was in the 2D driver from which this code was derived. Reviewed-by: Keith Packard Reviewed-by: Jesse Barnes -- keith.packard at intel.com -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20110310/8cb1e902/attachment.pgp>
[PATCH] drm/i915: fix corruptions on i8xx due to relaxed fencing
On Thu, March 10, 2011 08:52, Daniel Vetter wrote: > Am Do, 10.03.2011, 06:06 schrieb Indan Zupancic: >> This isn't in rc8, can someone make sure it gets into 2.6.38-rc9/2.6.38? > > The patch unfortunately broke gen4+ (more precisely: the unwritten abi > guarantee that userspace can tile buffers that don't have a complete last > tile row, as long as it promises not to touch it). Hence it got reverted. > It was just a enforcement check to prevent broken userspace from fooling > itself. The proper fix is to upgrade your userspace (libdrm + > xf86-video-intel). > > [Aside: This only happens if you have new enough userspace that supports > relaxed tiling. Old userspace and new kernels are _not_ broken.] Yes, I noticed it got reverted when digging into git log, but the commit message only said it broke gen4+, not how gen2 should be unbroken after the revert. Which versions fix this, just for reference? I got libdrm 2.4.23 and xf86-video-intel 2.14.0. (As a side note, do you have version checking on the kernel side? If so, you could return 0 for the relaxed fencing feature check if the driver is the wrong version.) To keep things manageable I either upgrade the kernel, or userspace, but never both at once. It seems that that doesn't work with graphics. Thanks, Indan
[Bug 30832] Radeon S-Video Out has become black and white. Works fine in 2.6.37
https://bugzilla.kernel.org/show_bug.cgi?id=30832 --- Comment #3 from Arbit Rabbit 2011-03-10 11:26:46 --- Created an attachment (id=50572) --> (https://bugzilla.kernel.org/attachment.cgi?id=50572) Complete 2.6.37 kernel log -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 30832] Radeon S-Video Out has become black and white. Works fine in 2.6.37
https://bugzilla.kernel.org/show_bug.cgi?id=30832 --- Comment #2 from Arbit Rabbit 2011-03-10 11:26:04 --- Created an attachment (id=50562) --> (https://bugzilla.kernel.org/attachment.cgi?id=50562) Complete 2.6.38-rc6 kernel log -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] fix backlight brightness on intel LVDS panel after reopening lid
On Thu, March 10, 2011 09:25, Takashi Iwai wrote:
> At Thu, 10 Mar 2011 08:49:37 +0100,
> Takashi Iwai wrote:
>>
>> At Thu, 10 Mar 2011 06:50:09 +0100 (CET),
>> Indan Zupancic wrote:
>> >
>> > Hello,
>> >
>> > On Fri, March 4, 2011 19:47, Linus Torvalds wrote:
>> > > Alex, can you confirm that the revert of 951f3512dba5 plus the
>> > > one-liner patch from Takashi that Indan quoted also works for you?
>> > >
>> > > Linus
>> > >
>> > > On Thu, Mar 3, 2011 at 10:53 PM, Indan Zupancic wrote:
>> > >>
>> > >> So please revert my patch and apply Takashi Iwai's, which fixes the
>> > >> most immediate bug without changing anything else. This should go
>> > >> in stable too.
>> > >
>> >
>> > I found another backlight bug:
>> >
>> > When suspending intel_panel_disable_backlight() is never called,
>> > but intel_panel_enable_backlight() is called at resume. With the
>> > effect that if the brightness was ever changed after screen
>> > blanking, the wrong brightness gets restored.
>> >
>> > This explains the weird behaviour I've seen. I didn't see it with
>> > combination mode, because then the brightness is always the same
>> > (zero or the maximum, the BIOS only uses LBPC on my system.) I'll
>> > send a patch in a moment.
>> >
>> > Alternative for reverting the combination mode removal (I can also
>> > redo the patch against the revert and Takashi's patch, if that's
>> > preferred):
>> >
>> > --
>> >
>> > drm/i915: Do handle backlight combination mode specially
>> >
>> > Add back the combination mode check, but with slightly cleaner code
>> > and the weirdness removed: No val >>= 1, but also no val &= ~1. The
>> > old code probably confused bit 0 with BLM_LEGACY_MODE, which is bit 16.
>> > The other change is clearer calculations: Just check for zero level
>> > explicitly instead of avoiding the divide-by-zero.
>> >
>> > Signed-off-by: Indan Zupancic
>> >
>> > ---
>> >
>> > diff --git a/drivers/gpu/drm/i915/intel_panel.c
>> > b/drivers/gpu/drm/i915/intel_panel.c
>> > index d860abe..b05631a 100644
>> > --- a/drivers/gpu/drm/i915/intel_panel.c
>> > +++ b/drivers/gpu/drm/i915/intel_panel.c
>> > @@ -30,6 +30,10 @@
>> >
>> > #include "intel_drv.h"
>> >
>> > +#define PCI_LBPC 0xf4 /* legacy/combination backlight modes */
>> > +#define BLM_COMBINATION_MODE (1 << 30)
>> > +#define BLM_LEGACY_MODE (1 << 16)
>> > +
>> > void
>> > intel_fixed_panel_mode(struct drm_display_mode *fixed_mode,
>> > struct drm_display_mode *adjusted_mode)
>> > @@ -110,6 +114,22 @@ done:
>> >dev_priv->pch_pf_size = (width << 16) | height;
>> > }
>> >
>> > +/*
>> > + * What about gen 3? If there are no gen 3 systems with ASLE,
>> > + * then it doesn't matter, as we don't need to change the
>> > + * brightness. But then the gen 2 check can be removed too.
>> > + */
>> > +static int is_backlight_combination_mode(struct drm_device *dev)
>> > +{
>> > + struct drm_i915_private *dev_priv = dev->dev_private;
>> > +
>> > + if (INTEL_INFO(dev)->gen >= 4)
>> > + return I915_READ(BLC_PWM_CTL2) & BLM_COMBINATION_MODE;
>> > + if (IS_GEN2(dev))
>> > + return I915_READ(BLC_PWM_CTL) & BLM_LEGACY_MODE;
>> > + return 0;
>> > +}
>> > +
>> > static u32 i915_read_blc_pwm_ctl(struct drm_i915_private *dev_priv)
>> > {
>> >u32 val;
>> > @@ -163,9 +183,12 @@ u32 intel_panel_get_max_backlight(struct drm_device
>> > *dev)
>> >max >>= 17;
>> >} else {
>> >max >>= 16;
>> > + /* Ignore BLM_LEGACY_MODE bit */
>> >if (INTEL_INFO(dev)->gen < 4)
>> >max &= ~1;
>> >}
>> > + if (is_backlight_combination_mode(dev))
>> > + max *= 0xff;
>> >}
>> >
>> >DRM_DEBUG_DRIVER("max backlight PWM = %d\n", max);
>> > @@ -183,6 +206,12 @@ u32 intel_panel_get_backlight(struct drm_device *dev)
>> >val = I915_READ(BLC_PWM_CTL) & BACKLIGHT_DUTY_CYCLE_MASK;
>> >if (IS_PINEVIEW(dev))
>> >val >>= 1;
>> > + if (is_backlight_combination_mode(dev)){
>> > + u8 lbpc;
>> > +
>> > + pci_read_config_byte(dev->pdev, PCI_LBPC, );
>> > + val *= lbpc;
>> > + }
>> >}
>> >
>> >DRM_DEBUG_DRIVER("get backlight PWM = %d\n", val);
>> > @@ -205,6 +234,15 @@ void intel_panel_set_backlight(struct drm_device
>> > *dev, u32 level)
>> >
>> >if (HAS_PCH_SPLIT(dev))
>> >return intel_pch_panel_set_backlight(dev, level);
>> > +
>> > + if (level && is_backlight_combination_mode(dev)){
>> > + u32 max = intel_panel_get_max_backlight(dev);
>> > + u8 lpbc;
>> > +
>> > + lpbc = level * 0xff / max;
>> > + level /= lpbc;
>>
>> Hmm, I don't think this calculation is correct. This would result
>> in level of opregion over its limit. For example, assume the level
>> max = 100, so total max = 25500. Passing level=150 here will be:
>>
>>
[Bug 25710] [DRI1 & DRI2] sauerbraten: lines around textures
https://bugs.freedesktop.org/show_bug.cgi?id=25710 Marek Ol??k changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Comment #2 from Marek Ol??k 2011-03-10 10:58:02 PST --- Closing because r300c is no longer supported. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 25709] [DRI1 & DRI2] sauerbraten: broken water rendering
https://bugs.freedesktop.org/show_bug.cgi?id=25709 Marek Ol??k changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Comment #2 from Marek Ol??k 2011-03-10 10:57:28 PST --- Closing because r300c is no longer supported. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 23545] [r300c/UMS] flashing textures in some maps of sauerbraten game
https://bugs.freedesktop.org/show_bug.cgi?id=23545 Marek Ol??k changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||WONTFIX --- Comment #14 from Marek Ol??k 2011-03-10 10:54:50 PST --- I think so too. Closing because r300c/UMS is no longer supported. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 23545] [r300c/UMS] flashing textures in some maps of sauerbraten game
https://bugs.freedesktop.org/show_bug.cgi?id=23545 --- Comment #13 from ?lmos 2011-03-10 10:48:24 PST --- According to my test on an rv350, r300g of mesa 7.10 seems to be free of this bug. If r300c is no longer relevant, this report should be closed. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 25709] [DRI1 & DRI2] sauerbraten: broken water rendering
https://bugs.freedesktop.org/show_bug.cgi?id=25709 --- Comment #1 from ?lmos 2011-03-10 10:46:39 PST --- According to my test on an rv350, r300g of mesa 7.10 seems to be free of this bug. If r300c is no longer relevant, this report should be closed. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 25710] [DRI1 & DRI2] sauerbraten: lines around textures
https://bugs.freedesktop.org/show_bug.cgi?id=25710 --- Comment #1 from ?lmos 2011-03-10 10:46:15 PST --- According to my test on an rv350, r300g of mesa 7.10 seems to be free of this bug. If r300c is no longer relevant, this report should be closed. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] fix backlight brightness on intel LVDS panel after reopening lid
On Thu, March 10, 2011 08:49, Takashi Iwai wrote:
> At Thu, 10 Mar 2011 06:50:09 +0100 (CET),
> Indan Zupancic wrote:
>>
>> Hello,
>>
>> On Fri, March 4, 2011 19:47, Linus Torvalds wrote:
>> > Alex, can you confirm that the revert of 951f3512dba5 plus the
>> > one-liner patch from Takashi that Indan quoted also works for you?
>> >
>> > Linus
>> >
>> > On Thu, Mar 3, 2011 at 10:53 PM, Indan Zupancic wrote:
>> >>
>> >> So please revert my patch and apply Takashi Iwai's, which fixes the
>> >> most immediate bug without changing anything else. This should go
>> >> in stable too.
>> >
>>
>> I found another backlight bug:
>>
>> When suspending intel_panel_disable_backlight() is never called,
>> but intel_panel_enable_backlight() is called at resume. With the
>> effect that if the brightness was ever changed after screen
>> blanking, the wrong brightness gets restored.
>>
>> This explains the weird behaviour I've seen. I didn't see it with
>> combination mode, because then the brightness is always the same
>> (zero or the maximum, the BIOS only uses LBPC on my system.) I'll
>> send a patch in a moment.
>>
>> Alternative for reverting the combination mode removal (I can also
>> redo the patch against the revert and Takashi's patch, if that's
>> preferred):
>>
>> --
>>
>> drm/i915: Do handle backlight combination mode specially
>>
>> Add back the combination mode check, but with slightly cleaner code
>> and the weirdness removed: No val >>= 1, but also no val &= ~1. The
>> old code probably confused bit 0 with BLM_LEGACY_MODE, which is bit 16.
>> The other change is clearer calculations: Just check for zero level
>> explicitly instead of avoiding the divide-by-zero.
>>
>> Signed-off-by: Indan Zupancic
>>
>> ---
>>
>> diff --git a/drivers/gpu/drm/i915/intel_panel.c
>> b/drivers/gpu/drm/i915/intel_panel.c
>> index d860abe..b05631a 100644
>> --- a/drivers/gpu/drm/i915/intel_panel.c
>> +++ b/drivers/gpu/drm/i915/intel_panel.c
>> @@ -30,6 +30,10 @@
>>
>> #include "intel_drv.h"
>>
>> +#define PCI_LBPC 0xf4 /* legacy/combination backlight modes */
>> +#define BLM_COMBINATION_MODE (1 << 30)
>> +#define BLM_LEGACY_MODE (1 << 16)
>> +
>> void
>> intel_fixed_panel_mode(struct drm_display_mode *fixed_mode,
>> struct drm_display_mode *adjusted_mode)
>> @@ -110,6 +114,22 @@ done:
>> dev_priv->pch_pf_size = (width << 16) | height;
>> }
>>
>> +/*
>> + * What about gen 3? If there are no gen 3 systems with ASLE,
>> + * then it doesn't matter, as we don't need to change the
>> + * brightness. But then the gen 2 check can be removed too.
>> + */
>> +static int is_backlight_combination_mode(struct drm_device *dev)
>> +{
>> +struct drm_i915_private *dev_priv = dev->dev_private;
>> +
>> +if (INTEL_INFO(dev)->gen >= 4)
>> +return I915_READ(BLC_PWM_CTL2) & BLM_COMBINATION_MODE;
>> +if (IS_GEN2(dev))
>> +return I915_READ(BLC_PWM_CTL) & BLM_LEGACY_MODE;
>> +return 0;
>> +}
>> +
>> static u32 i915_read_blc_pwm_ctl(struct drm_i915_private *dev_priv)
>> {
>> u32 val;
>> @@ -163,9 +183,12 @@ u32 intel_panel_get_max_backlight(struct drm_device
>> *dev)
>> max >>= 17;
>> } else {
>> max >>= 16;
>> +/* Ignore BLM_LEGACY_MODE bit */
>> if (INTEL_INFO(dev)->gen < 4)
>> max &= ~1;
>> }
>> +if (is_backlight_combination_mode(dev))
>> +max *= 0xff;
>> }
>>
>> DRM_DEBUG_DRIVER("max backlight PWM = %d\n", max);
>> @@ -183,6 +206,12 @@ u32 intel_panel_get_backlight(struct drm_device *dev)
>> val = I915_READ(BLC_PWM_CTL) & BACKLIGHT_DUTY_CYCLE_MASK;
>> if (IS_PINEVIEW(dev))
>> val >>= 1;
>> +if (is_backlight_combination_mode(dev)){
>> +u8 lbpc;
>> +
>> +pci_read_config_byte(dev->pdev, PCI_LBPC, );
>> +val *= lbpc;
>> +}
>> }
>>
>> DRM_DEBUG_DRIVER("get backlight PWM = %d\n", val);
>> @@ -205,6 +234,15 @@ void intel_panel_set_backlight(struct drm_device *dev,
>> u32 level)
>>
>> if (HAS_PCH_SPLIT(dev))
>> return intel_pch_panel_set_backlight(dev, level);
>> +
>> +if (level && is_backlight_combination_mode(dev)){
>> +u32 max = intel_panel_get_max_backlight(dev);
>> +u8 lpbc;
>> +
>> +lpbc = level * 0xff / max;
>> +level /= lpbc;
>
> Hmm, I don't think this calculation is correct. This would result
> in level of opregion over its limit. For example, assume the level
> max = 100, so total max = 25500. Passing level=150 here will be:
>
> lbpc = 150 * 0xff / 25500 = 1.5 = 1
> level = 150 / 1 = 150, which is over limit.
>
> More worse, lbpc can be zero when level is below 100 in the case
> above...
Yes, you're right. It seems that any simplification I try to do
creates a
[Bug 35150] Starcraft 2 on wine on evergreen doesn't show login screen
https://bugs.freedesktop.org/show_bug.cgi?id=35150 Jerome Glisse changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #8 from Jerome Glisse 2011-03-10 09:34:43 PST --- So beside being slow it works ? Closing bug then -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] fix backlight brightness on intel LVDS panel after reopening lid
At Thu, 10 Mar 2011 08:49:37 +0100,
Takashi Iwai wrote:
>
> At Thu, 10 Mar 2011 06:50:09 +0100 (CET),
> Indan Zupancic wrote:
> >
> > Hello,
> >
> > On Fri, March 4, 2011 19:47, Linus Torvalds wrote:
> > > Alex, can you confirm that the revert of 951f3512dba5 plus the
> > > one-liner patch from Takashi that Indan quoted also works for you?
> > >
> > > Linus
> > >
> > > On Thu, Mar 3, 2011 at 10:53 PM, Indan Zupancic wrote:
> > >>
> > >> So please revert my patch and apply Takashi Iwai's, which fixes the
> > >> most immediate bug without changing anything else. This should go
> > >> in stable too.
> > >
> >
> > I found another backlight bug:
> >
> > When suspending intel_panel_disable_backlight() is never called,
> > but intel_panel_enable_backlight() is called at resume. With the
> > effect that if the brightness was ever changed after screen
> > blanking, the wrong brightness gets restored.
> >
> > This explains the weird behaviour I've seen. I didn't see it with
> > combination mode, because then the brightness is always the same
> > (zero or the maximum, the BIOS only uses LBPC on my system.) I'll
> > send a patch in a moment.
> >
> > Alternative for reverting the combination mode removal (I can also
> > redo the patch against the revert and Takashi's patch, if that's
> > preferred):
> >
> > --
> >
> > drm/i915: Do handle backlight combination mode specially
> >
> > Add back the combination mode check, but with slightly cleaner code
> > and the weirdness removed: No val >>= 1, but also no val &= ~1. The
> > old code probably confused bit 0 with BLM_LEGACY_MODE, which is bit 16.
> > The other change is clearer calculations: Just check for zero level
> > explicitly instead of avoiding the divide-by-zero.
> >
> > Signed-off-by: Indan Zupancic
> >
> > ---
> >
> > diff --git a/drivers/gpu/drm/i915/intel_panel.c
> > b/drivers/gpu/drm/i915/intel_panel.c
> > index d860abe..b05631a 100644
> > --- a/drivers/gpu/drm/i915/intel_panel.c
> > +++ b/drivers/gpu/drm/i915/intel_panel.c
> > @@ -30,6 +30,10 @@
> >
> > #include "intel_drv.h"
> >
> > +#define PCI_LBPC 0xf4 /* legacy/combination backlight modes */
> > +#define BLM_COMBINATION_MODE (1 << 30)
> > +#define BLM_LEGACY_MODE (1 << 16)
> > +
> > void
> > intel_fixed_panel_mode(struct drm_display_mode *fixed_mode,
> >struct drm_display_mode *adjusted_mode)
> > @@ -110,6 +114,22 @@ done:
> > dev_priv->pch_pf_size = (width << 16) | height;
> > }
> >
> > +/*
> > + * What about gen 3? If there are no gen 3 systems with ASLE,
> > + * then it doesn't matter, as we don't need to change the
> > + * brightness. But then the gen 2 check can be removed too.
> > + */
> > +static int is_backlight_combination_mode(struct drm_device *dev)
> > +{
> > + struct drm_i915_private *dev_priv = dev->dev_private;
> > +
> > + if (INTEL_INFO(dev)->gen >= 4)
> > + return I915_READ(BLC_PWM_CTL2) & BLM_COMBINATION_MODE;
> > + if (IS_GEN2(dev))
> > + return I915_READ(BLC_PWM_CTL) & BLM_LEGACY_MODE;
> > + return 0;
> > +}
> > +
> > static u32 i915_read_blc_pwm_ctl(struct drm_i915_private *dev_priv)
> > {
> > u32 val;
> > @@ -163,9 +183,12 @@ u32 intel_panel_get_max_backlight(struct drm_device
> > *dev)
> > max >>= 17;
> > } else {
> > max >>= 16;
> > + /* Ignore BLM_LEGACY_MODE bit */
> > if (INTEL_INFO(dev)->gen < 4)
> > max &= ~1;
> > }
> > + if (is_backlight_combination_mode(dev))
> > + max *= 0xff;
> > }
> >
> > DRM_DEBUG_DRIVER("max backlight PWM = %d\n", max);
> > @@ -183,6 +206,12 @@ u32 intel_panel_get_backlight(struct drm_device *dev)
> > val = I915_READ(BLC_PWM_CTL) & BACKLIGHT_DUTY_CYCLE_MASK;
> > if (IS_PINEVIEW(dev))
> > val >>= 1;
> > + if (is_backlight_combination_mode(dev)){
> > + u8 lbpc;
> > +
> > + pci_read_config_byte(dev->pdev, PCI_LBPC, );
> > + val *= lbpc;
> > + }
> > }
> >
> > DRM_DEBUG_DRIVER("get backlight PWM = %d\n", val);
> > @@ -205,6 +234,15 @@ void intel_panel_set_backlight(struct drm_device *dev,
> > u32 level)
> >
> > if (HAS_PCH_SPLIT(dev))
> > return intel_pch_panel_set_backlight(dev, level);
> > +
> > + if (level && is_backlight_combination_mode(dev)){
> > + u32 max = intel_panel_get_max_backlight(dev);
> > + u8 lpbc;
> > +
> > + lpbc = level * 0xff / max;
> > + level /= lpbc;
>
> Hmm, I don't think this calculation is correct. This would result
> in level of opregion over its limit. For example, assume the level
> max = 100, so total max = 25500. Passing level=150 here will be:
>
> lbpc = 150 * 0xff / 25500 = 1.5 = 1
> level = 150 / 1 = 150, which is over limit.
>
> More worse, lbpc can be zero when
[PATCH] drm/i915: fix corruptions on i8xx due to relaxed fencing
Am Do, 10.03.2011, 06:06 schrieb Indan Zupancic: > This isn't in rc8, can someone make sure it gets into 2.6.38-rc9/2.6.38? The patch unfortunately broke gen4+ (more precisely: the unwritten abi guarantee that userspace can tile buffers that don't have a complete last tile row, as long as it promises not to touch it). Hence it got reverted. It was just a enforcement check to prevent broken userspace from fooling itself. The proper fix is to upgrade your userspace (libdrm + xf86-video-intel). [Aside: This only happens if you have new enough userspace that supports relaxed tiling. Old userspace and new kernels are _not_ broken.] Cheers, Daniel
[PATCH] fix backlight brightness on intel LVDS panel after reopening lid
At Thu, 10 Mar 2011 06:50:09 +0100 (CET),
Indan Zupancic wrote:
>
> Hello,
>
> On Fri, March 4, 2011 19:47, Linus Torvalds wrote:
> > Alex, can you confirm that the revert of 951f3512dba5 plus the
> > one-liner patch from Takashi that Indan quoted also works for you?
> >
> > Linus
> >
> > On Thu, Mar 3, 2011 at 10:53 PM, Indan Zupancic wrote:
> >>
> >> So please revert my patch and apply Takashi Iwai's, which fixes the
> >> most immediate bug without changing anything else. This should go
> >> in stable too.
> >
>
> I found another backlight bug:
>
> When suspending intel_panel_disable_backlight() is never called,
> but intel_panel_enable_backlight() is called at resume. With the
> effect that if the brightness was ever changed after screen
> blanking, the wrong brightness gets restored.
>
> This explains the weird behaviour I've seen. I didn't see it with
> combination mode, because then the brightness is always the same
> (zero or the maximum, the BIOS only uses LBPC on my system.) I'll
> send a patch in a moment.
>
> Alternative for reverting the combination mode removal (I can also
> redo the patch against the revert and Takashi's patch, if that's
> preferred):
>
> --
>
> drm/i915: Do handle backlight combination mode specially
>
> Add back the combination mode check, but with slightly cleaner code
> and the weirdness removed: No val >>= 1, but also no val &= ~1. The
> old code probably confused bit 0 with BLM_LEGACY_MODE, which is bit 16.
> The other change is clearer calculations: Just check for zero level
> explicitly instead of avoiding the divide-by-zero.
>
> Signed-off-by: Indan Zupancic
>
> ---
>
> diff --git a/drivers/gpu/drm/i915/intel_panel.c
> b/drivers/gpu/drm/i915/intel_panel.c
> index d860abe..b05631a 100644
> --- a/drivers/gpu/drm/i915/intel_panel.c
> +++ b/drivers/gpu/drm/i915/intel_panel.c
> @@ -30,6 +30,10 @@
>
> #include "intel_drv.h"
>
> +#define PCI_LBPC 0xf4 /* legacy/combination backlight modes */
> +#define BLM_COMBINATION_MODE (1 << 30)
> +#define BLM_LEGACY_MODE (1 << 16)
> +
> void
> intel_fixed_panel_mode(struct drm_display_mode *fixed_mode,
> struct drm_display_mode *adjusted_mode)
> @@ -110,6 +114,22 @@ done:
> dev_priv->pch_pf_size = (width << 16) | height;
> }
>
> +/*
> + * What about gen 3? If there are no gen 3 systems with ASLE,
> + * then it doesn't matter, as we don't need to change the
> + * brightness. But then the gen 2 check can be removed too.
> + */
> +static int is_backlight_combination_mode(struct drm_device *dev)
> +{
> + struct drm_i915_private *dev_priv = dev->dev_private;
> +
> + if (INTEL_INFO(dev)->gen >= 4)
> + return I915_READ(BLC_PWM_CTL2) & BLM_COMBINATION_MODE;
> + if (IS_GEN2(dev))
> + return I915_READ(BLC_PWM_CTL) & BLM_LEGACY_MODE;
> + return 0;
> +}
> +
> static u32 i915_read_blc_pwm_ctl(struct drm_i915_private *dev_priv)
> {
> u32 val;
> @@ -163,9 +183,12 @@ u32 intel_panel_get_max_backlight(struct drm_device *dev)
> max >>= 17;
> } else {
> max >>= 16;
> + /* Ignore BLM_LEGACY_MODE bit */
> if (INTEL_INFO(dev)->gen < 4)
> max &= ~1;
> }
> + if (is_backlight_combination_mode(dev))
> + max *= 0xff;
> }
>
> DRM_DEBUG_DRIVER("max backlight PWM = %d\n", max);
> @@ -183,6 +206,12 @@ u32 intel_panel_get_backlight(struct drm_device *dev)
> val = I915_READ(BLC_PWM_CTL) & BACKLIGHT_DUTY_CYCLE_MASK;
> if (IS_PINEVIEW(dev))
> val >>= 1;
> + if (is_backlight_combination_mode(dev)){
> + u8 lbpc;
> +
> + pci_read_config_byte(dev->pdev, PCI_LBPC, );
> + val *= lbpc;
> + }
> }
>
> DRM_DEBUG_DRIVER("get backlight PWM = %d\n", val);
> @@ -205,6 +234,15 @@ void intel_panel_set_backlight(struct drm_device *dev,
> u32 level)
>
> if (HAS_PCH_SPLIT(dev))
> return intel_pch_panel_set_backlight(dev, level);
> +
> + if (level && is_backlight_combination_mode(dev)){
> + u32 max = intel_panel_get_max_backlight(dev);
> + u8 lpbc;
> +
> + lpbc = level * 0xff / max;
> + level /= lpbc;
Hmm, I don't think this calculation is correct. This would result
in level of opregion over its limit. For example, assume the level
max = 100, so total max = 25500. Passing level=150 here will be:
lbpc = 150 * 0xff / 25500 = 1.5 = 1
level = 150 / 1 = 150, which is over limit.
More worse, lbpc can be zero when level is below 100 in the case
above...
thanks,
Takashi
vblank problem (and proposed fix) on crtc > 1
On Thu, 10 Mar 2011, Michel [ISO-8859-1] D?nzer wrote:
>
> I'm afraid I don't really like this. Apart from the ugly bogus error
> message, the probes could fail for other reasons, e.g. at some point we
> might want to return an error when the ioctl is called for a CRTC which
> is currently disabled, to avoid the hang you were getting for CRTC 1.
>
Your example actually speaks in favor of probing. Let's say that the
future kernel starts returning an error for disabled CRTC and you don't do
any probing. DDX will start calling vblank waits on disabled CRTC (just
like it's doing now) and spam the kernel with errors. With probing, error
will happen only once at screen init time.
> Dave's drm-next tree actually has a new DRM_IOCTL_GET_CAP ioctl, which
> could be used for detecting this capability. It might even be possible
> to handle old kernels transparently in drmWaitVBlank(), but I'm not sure
> offhand if that would be better overall than doing it in the driver
> code.
>
This argument is self defeating. The purpose of the probing is to check
for the old kernel. If I have DRM_IOCTL_GET_CAP, that means that I have a
new kernel so probing will just work. If I have an old kernel then I don't
have DRM_IOCTL_GET_CAP ioctl, so attemting to use it will result in an
error from the kernel anyway. It makes no sense to me to cause an error
in one ioctl so that you would prevent an error in other ioctl.
>> + if (info->high_crtc_works) {
>> + high_crtc = (crtc << DRM_VBLANK_HIGH_CRTC_SHIFT) &
>> + DRM_VBLANK_HIGH_CRTC_MASK;
>> + } else vbl.request.type |= DRM_VBLANK_SECONDARY;
>
> Waiting on a random other CRTC makes no sense. If you know you can't
> wait on the given CRTC, don't wait at all.
>
It's not random CRTC, but it's what today's DDX and DRM call "secondary"
CRTC. I intentionally did this for two reasons. First, this is the
behavior that is identical to what we see today, and I prefer to preserve
the same behavior if either component is old (DDX or kernel), rather than
have different behavior for different combinations of old/new. The second
reason is pragmatic, if you want to not call wait_vblank at all and make
sure you are safe to whatever the code above you is doing and not
return an error you have to make up the sequence numbers and timestamps
(and probably keep track of them) and that's much more radical
modification to the DDX. So I figured this would be conservative.
>> + vbl.request.sequence = 0;
>> + if (drmWaitVBlank(info->dri2.drm_fd, )) {
>> + xf86DrvMsg(pScrn->scrnIndex, X_WARNING, "Kernel rejects
>> VBLANK request on CRTC %d\n", c);
>> + info->high_crtc_works = FALSE;
>
> Should break out of the for loop at this point.
>
This was also intentional. I want to see in Xorg log file the full list of
crtcs that rejected the vblank wait request. It comes handy for analyzing
the problems and/or bugs.
[PATCH] fix backlight brightness on intel LVDS panel after reopening lid
drm/i915: Fix DPMS and suspend interaction for intel_panel.c
When suspending intel_panel_disable_backlight() is never called,
but intel_panel_enable_backlight() is called at resume. With the
effect that if the brightness was ever changed after screen
blanking, the wrong brightness gets restored at resume time.
Nothing guarantees that those calls will be balanced, so having
backlight_enabled makes no sense, as the real state can change
without the panel code noticing. So keep things as stateless as
possible.
Signed-off-by: Indan Zupancic
---
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 456f404..4a3d9ed 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -333,7 +333,6 @@ typedef struct drm_i915_private {
/* LVDS info */
int backlight_level; /* restore backlight to this value */
- bool backlight_enabled;
struct drm_display_mode *panel_fixed_mode;
struct drm_display_mode *lfp_lvds_vbt_mode; /* if any */
struct drm_display_mode *sdvo_lvds_vbt_mode; /* if any */
@@ -1220,10 +1219,6 @@ void i915_debugfs_cleanup(struct drm_minor *minor);
extern int i915_save_state(struct drm_device *dev);
extern int i915_restore_state(struct drm_device *dev);
-/* i915_suspend.c */
-extern int i915_save_state(struct drm_device *dev);
-extern int i915_restore_state(struct drm_device *dev);
-
/* intel_i2c.c */
extern int intel_setup_gmbus(struct drm_device *dev);
extern void intel_teardown_gmbus(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 49fb54f..1b5a32d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5924,8 +5924,6 @@ static void intel_setup_outputs(struct drm_device *dev)
encoder->base.possible_clones =
intel_encoder_clones(dev, encoder->clone_mask);
}
-
- intel_panel_setup_backlight(dev);
}
static void intel_user_framebuffer_destroy(struct drm_framebuffer *fb)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 2c43104..70e8b82 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -257,7 +257,6 @@ extern void intel_pch_panel_fitting(struct drm_device *dev,
extern u32 intel_panel_get_max_backlight(struct drm_device *dev);
extern u32 intel_panel_get_backlight(struct drm_device *dev);
extern void intel_panel_set_backlight(struct drm_device *dev, u32 level);
-extern void intel_panel_setup_backlight(struct drm_device *dev);
extern void intel_panel_enable_backlight(struct drm_device *dev);
extern void intel_panel_disable_backlight(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_panel.c
index d860abe..b05631a 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -217,12 +255,11 @@ void intel_panel_set_backlight(struct drm_device *dev,
u32 level)
void intel_panel_disable_backlight(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
+ u32 level = intel_panel_get_backlight(dev);
- if (dev_priv->backlight_enabled) {
- dev_priv->backlight_level = intel_panel_get_backlight(dev);
- dev_priv->backlight_enabled = false;
- }
-
+ if (level == 0)
+ return;
+ dev_priv->backlight_level = level;
intel_panel_set_backlight(dev, 0);
}
@@ -230,17 +267,9 @@ void intel_panel_enable_backlight(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
+ if (intel_panel_get_backlight(dev))
+ return;
if (dev_priv->backlight_level == 0)
dev_priv->backlight_level = intel_panel_get_max_backlight(dev);
-
intel_panel_set_backlight(dev, dev_priv->backlight_level);
- dev_priv->backlight_enabled = true;
-}
-
-void intel_panel_setup_backlight(struct drm_device *dev)
-{
- struct drm_i915_private *dev_priv = dev->dev_private;
-
- dev_priv->backlight_level = intel_panel_get_backlight(dev);
- dev_priv->backlight_enabled = dev_priv->backlight_level != 0;
}
[PATCH] fix backlight brightness on intel LVDS panel after reopening lid
Hello,
On Fri, March 4, 2011 19:47, Linus Torvalds wrote:
> Alex, can you confirm that the revert of 951f3512dba5 plus the
> one-liner patch from Takashi that Indan quoted also works for you?
>
> Linus
>
> On Thu, Mar 3, 2011 at 10:53 PM, Indan Zupancic wrote:
>>
>> So please revert my patch and apply Takashi Iwai's, which fixes the
>> most immediate bug without changing anything else. This should go
>> in stable too.
>
I found another backlight bug:
When suspending intel_panel_disable_backlight() is never called,
but intel_panel_enable_backlight() is called at resume. With the
effect that if the brightness was ever changed after screen
blanking, the wrong brightness gets restored.
This explains the weird behaviour I've seen. I didn't see it with
combination mode, because then the brightness is always the same
(zero or the maximum, the BIOS only uses LBPC on my system.) I'll
send a patch in a moment.
Alternative for reverting the combination mode removal (I can also
redo the patch against the revert and Takashi's patch, if that's
preferred):
--
drm/i915: Do handle backlight combination mode specially
Add back the combination mode check, but with slightly cleaner code
and the weirdness removed: No val >>= 1, but also no val &= ~1. The
old code probably confused bit 0 with BLM_LEGACY_MODE, which is bit 16.
The other change is clearer calculations: Just check for zero level
explicitly instead of avoiding the divide-by-zero.
Signed-off-by: Indan Zupancic
---
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_panel.c
index d860abe..b05631a 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -30,6 +30,10 @@
#include "intel_drv.h"
+#define PCI_LBPC 0xf4 /* legacy/combination backlight modes */
+#define BLM_COMBINATION_MODE (1 << 30)
+#define BLM_LEGACY_MODE (1 << 16)
+
void
intel_fixed_panel_mode(struct drm_display_mode *fixed_mode,
struct drm_display_mode *adjusted_mode)
@@ -110,6 +114,22 @@ done:
dev_priv->pch_pf_size = (width << 16) | height;
}
+/*
+ * What about gen 3? If there are no gen 3 systems with ASLE,
+ * then it doesn't matter, as we don't need to change the
+ * brightness. But then the gen 2 check can be removed too.
+ */
+static int is_backlight_combination_mode(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev->dev_private;
+
+ if (INTEL_INFO(dev)->gen >= 4)
+ return I915_READ(BLC_PWM_CTL2) & BLM_COMBINATION_MODE;
+ if (IS_GEN2(dev))
+ return I915_READ(BLC_PWM_CTL) & BLM_LEGACY_MODE;
+ return 0;
+}
+
static u32 i915_read_blc_pwm_ctl(struct drm_i915_private *dev_priv)
{
u32 val;
@@ -163,9 +183,12 @@ u32 intel_panel_get_max_backlight(struct drm_device *dev)
max >>= 17;
} else {
max >>= 16;
+ /* Ignore BLM_LEGACY_MODE bit */
if (INTEL_INFO(dev)->gen < 4)
max &= ~1;
}
+ if (is_backlight_combination_mode(dev))
+ max *= 0xff;
}
DRM_DEBUG_DRIVER("max backlight PWM = %d\n", max);
@@ -183,6 +206,12 @@ u32 intel_panel_get_backlight(struct drm_device *dev)
val = I915_READ(BLC_PWM_CTL) & BACKLIGHT_DUTY_CYCLE_MASK;
if (IS_PINEVIEW(dev))
val >>= 1;
+ if (is_backlight_combination_mode(dev)){
+ u8 lbpc;
+
+ pci_read_config_byte(dev->pdev, PCI_LBPC, );
+ val *= lbpc;
+ }
}
DRM_DEBUG_DRIVER("get backlight PWM = %d\n", val);
@@ -205,6 +234,15 @@ void intel_panel_set_backlight(struct drm_device *dev, u32
level)
if (HAS_PCH_SPLIT(dev))
return intel_pch_panel_set_backlight(dev, level);
+
+ if (level && is_backlight_combination_mode(dev)){
+ u32 max = intel_panel_get_max_backlight(dev);
+ u8 lpbc;
+
+ lpbc = level * 0xff / max;
+ level /= lpbc;
+ pci_write_config_byte(dev->pdev, PCI_LBPC, lpbc);
+ }
tmp = I915_READ(BLC_PWM_CTL);
if (IS_PINEVIEW(dev)) {
tmp &= ~(BACKLIGHT_DUTY_CYCLE_MASK - 1);
[PATCH] drm/i915: fix corruptions on i8xx due to relaxed fencing
Hi,
On Wed, February 23, 2011 08:10, Daniel Vetter wrote:
> Am Mi, 23.02.2011, 07:59 schrieb Indan Zupancic:
>> On Tue, February 22, 2011 18:25, Daniel Vetter wrote:
>>> It looks like gen2 has a peculiar interleaved 2-row inter-tile
>>> layout. Probably inherited from i81x which had 2kb tiles (which
>>> naturally fit an even-number-of-tile-rows scheme to fit onto 4kb
>>> pages). There is no other mention of this in any docs (also not
>>> in the Intel internal documention according to Chris Wilson).
>>>
>>> Problem manifests itself in corruptions in the second half of the
>>> last tile row (if the bo has an odd number of tiles). Which can
>>> only happen with relaxed tiling (introduced in a00b10c360b35d6431a9).
>>>
>>> So reject set_tiling calls that don't satisfy this constrain to
>>> prevent broken userspace from causing havoc. While at it, also
>>> check the size for newer chipsets.
>>>
>>> LKML: https://lkml.org/lkml/2011/2/19/5
>>> Reported-by: Indan Zupancic
>>> Signed-off-by: Daniel Vetter
>>> ---
>>> drivers/gpu/drm/i915/i915_gem_tiling.c | 16 +++-
>>> 1 files changed, 15 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/i915_gem_tiling.c
>>> b/drivers/gpu/drm/i915/i915_gem_tiling.c
>>> index 22a32b9..79a04fd 100644
>>> --- a/drivers/gpu/drm/i915/i915_gem_tiling.c
>>> +++ b/drivers/gpu/drm/i915/i915_gem_tiling.c
>>> @@ -184,7 +184,7 @@ i915_gem_detect_bit_6_swizzle(struct drm_device
>>> *dev)
>>> static bool
>>> i915_tiling_ok(struct drm_device *dev, int stride, int size, int
>>> tiling_mode)
>>> {
>>> - int tile_width;
>>> + int tile_width, tile_height;
>>>
>>> /* Linear is always fine */
>>> if (tiling_mode == I915_TILING_NONE)
>>> @@ -215,6 +215,20 @@ i915_tiling_ok(struct drm_device *dev, int stride,
>>> int size, int
>>> tiling_mode)
>>> }
>>> }
>>>
>>> + if (IS_GEN2(dev) ||
>>> + (tiling_mode == I915_TILING_Y && HAS_128_BYTE_Y_TILING(dev)))
>>> + tile_height = 32;
>>> + else
>>> + tile_height = 8;
>>> + /* i8xx is strange: It has 2 interleaved rows of tiles, so needs an
>>> even
>>> +* number of tile rows. */
>>> + if (IS_GEN2(dev))
>>> + tile_height *= 2;
>>> +
>>> + /* Size needs to be aligned to a full tile row */
>>> + if (size & (tile_height * stride - 1))
>>> + return false;
>>> +
>>> /* 965+ just needs multiples of tile width */
>>> if (INTEL_INFO(dev)->gen >= 4) {
>>> if (stride & (tile_width - 1))
>>
>> Tested-by: Indan Zupancic
>>
>> I tested with this patch and without the other ones you send and the
>> corruption is indeed gone.
>>
>> Not sure why you dropped lkml from CC, now people who stuble upon it
>> don't see the ending...
>
> Random incoherency in my brain. Re-added to cc.
This isn't in rc8, can someone make sure it gets into 2.6.38-rc9/2.6.38?
Thanks,
Indan
[Bug 30651] [RADEON:KMS:R600G] gl output in mplayer have no colors if used with a fragment program with additional lookup and bicubic B-spline filtering
https://bugs.freedesktop.org/show_bug.cgi?id=30651 --- Comment #6 from Sergey Kondakov 2011-03-10 03:24:51 PST --- yes, thanks. the green thing is gone with yuv=6 but 1) yuv=4 on r600g still have no colours even though with r300g they are ok 2) still there is an overbright glitch in some white places in some videos with yuv=6. but again, it may be a mplayer bug since it present with r300g too (but not software rasterizer), i'm not sure. so, it's back to beginning. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 30832] Radeon S-Video Out has become black and white. Works fine in 2.6.37
https://bugzilla.kernel.org/show_bug.cgi?id=30832 Arbit Rabbit changed: What|Removed |Added Kernel Version|2.6.38.6|2.6.38-rc6 -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 35150] Starcraft 2 on wine on evergreen doesn't show login screen
https://bugs.freedesktop.org/show_bug.cgi?id=35150 --- Comment #7 from David Mills 2011-03-10 01:23:40 PST --- Thanks, some googleing already pointed me to libtc_dxtn and the enviroment variable. OK, enabling S3TC got the textures to rendre (more or less) OK. Still some texture tearing but that should be expected ATM. The game still runs slideshow slow however (even though the interface in itself is super fluid). I'll look into what exactly is causing that later on, my gut says software fallback, but I don't have a mesa-hardened gut yet ;) (got to go work a bit). Thanks for your help. David -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 35150] Starcraft 2 on wine on evergreen doesn't show login screen
https://bugs.freedesktop.org/show_bug.cgi?id=35150 --- Comment #6 from Tobias Jakobi 2011-03-10 01:03:49 PST --- (In reply to comment #4) > A google says this might be S3TC related, so I'll try re-compiling with > support > enabled to test. I find it strange that SC2 was marked as supported up until > December on RadeonProgram in that case though. Recompiling mesa? Won't have any effect, since libtxc_dxtn is dynamically loaded when it is found. Don't just believe everything that is said on Phoronix ;) *g* -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 35150] Starcraft 2 on wine on evergreen doesn't show login screen
https://bugs.freedesktop.org/show_bug.cgi?id=35150 --- Comment #5 from Tobias Jakobi 2011-03-10 01:01:30 PST --- You need a 32-bit (!) compile of libtxc_dxtn. Use for example Marek's maintained version of the library from here: http://cgit.freedesktop.org/~mareko/libtxc_dxtn/ -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 30832] Radeon S-Video Out has become black and white. Works fine in 2.6.37
https://bugzilla.kernel.org/show_bug.cgi?id=30832 Rafael J. Wysocki changed: What|Removed |Added CC||florian at mickler.org, ||maciej.rutecki at gmail.com, ||rjw at sisk.pl Blocks||27352 -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 35150] Starcraft 2 on wine on evergreen doesn't show login screen
https://bugs.freedesktop.org/show_bug.cgi?id=35150 --- Comment #4 from David Mills 2011-03-10 00:57:23 PST --- OK, I've recompiled using the latest gallium (20110309) Starcraft 2 starts, but most/all textures aren't shown (this counts for cinematics, the interface background and in game) Wine is giving the following errors which seem to correspond: err:d3d_surface:surface_allocate_surface > GL_INVALID_VALUE (0x501) from glTexImage2D @ ../../../wine/dlls/wined3d/surface.c / 1095 ---SNIP--- err:d3d_surface:surface_upload_data > GL_INVALID_ENUM (0x500) from glCompressedTexSubImage2DARB @ ../../../wine/dlls/wined3d/surface.c / 994 The above repeated many times. Cinematics/ingame graphics are also very slow (as in slide show) but that might just be a symptom of what is causing the texture problems. A google says this might be S3TC related, so I'll try re-compiling with support enabled to test. I find it strange that SC2 was marked as supported up until December on RadeonProgram in that case though. The could very well be pebkac, so any hints / links / man pages are welcome. I'll post an update to show what I've found David -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 35051] [RADEON:KMS:R600G] wine Counter Strike Source Crashes at Startup
https://bugs.freedesktop.org/show_bug.cgi?id=35051 --- Comment #6 from Tobias Jakobi 2011-03-10 00:37:09 PST --- Radeon HD 4770 [RV740] with the latest d-r-t -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Re: [PATCH] drm/i915: fix corruptions on i8xx due to relaxed fencing
Am Do, 10.03.2011, 06:06 schrieb Indan Zupancic: This isn't in rc8, can someone make sure it gets into 2.6.38-rc9/2.6.38? The patch unfortunately broke gen4+ (more precisely: the unwritten abi guarantee that userspace can tile buffers that don't have a complete last tile row, as long as it promises not to touch it). Hence it got reverted. It was just a enforcement check to prevent broken userspace from fooling itself. The proper fix is to upgrade your userspace (libdrm + xf86-video-intel). [Aside: This only happens if you have new enough userspace that supports relaxed tiling. Old userspace and new kernels are _not_ broken.] Cheers, Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] fix backlight brightness on intel LVDS panel after reopening lid
At Thu, 10 Mar 2011 08:49:37 +0100,
Takashi Iwai wrote:
At Thu, 10 Mar 2011 06:50:09 +0100 (CET),
Indan Zupancic wrote:
Hello,
On Fri, March 4, 2011 19:47, Linus Torvalds wrote:
Alex, can you confirm that the revert of 951f3512dba5 plus the
one-liner patch from Takashi that Indan quoted also works for you?
Linus
On Thu, Mar 3, 2011 at 10:53 PM, Indan Zupancic in...@nul.nu wrote:
So please revert my patch and apply Takashi Iwai's, which fixes the
most immediate bug without changing anything else. This should go
in stable too.
I found another backlight bug:
When suspending intel_panel_disable_backlight() is never called,
but intel_panel_enable_backlight() is called at resume. With the
effect that if the brightness was ever changed after screen
blanking, the wrong brightness gets restored.
This explains the weird behaviour I've seen. I didn't see it with
combination mode, because then the brightness is always the same
(zero or the maximum, the BIOS only uses LBPC on my system.) I'll
send a patch in a moment.
Alternative for reverting the combination mode removal (I can also
redo the patch against the revert and Takashi's patch, if that's
preferred):
--
drm/i915: Do handle backlight combination mode specially
Add back the combination mode check, but with slightly cleaner code
and the weirdness removed: No val = 1, but also no val = ~1. The
old code probably confused bit 0 with BLM_LEGACY_MODE, which is bit 16.
The other change is clearer calculations: Just check for zero level
explicitly instead of avoiding the divide-by-zero.
Signed-off-by: Indan Zupancic in...@nul.nu
---
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_panel.c
index d860abe..b05631a 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -30,6 +30,10 @@
#include intel_drv.h
+#define PCI_LBPC 0xf4 /* legacy/combination backlight modes */
+#define BLM_COMBINATION_MODE (1 30)
+#define BLM_LEGACY_MODE (1 16)
+
void
intel_fixed_panel_mode(struct drm_display_mode *fixed_mode,
struct drm_display_mode *adjusted_mode)
@@ -110,6 +114,22 @@ done:
dev_priv-pch_pf_size = (width 16) | height;
}
+/*
+ * What about gen 3? If there are no gen 3 systems with ASLE,
+ * then it doesn't matter, as we don't need to change the
+ * brightness. But then the gen 2 check can be removed too.
+ */
+static int is_backlight_combination_mode(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+
+ if (INTEL_INFO(dev)-gen = 4)
+ return I915_READ(BLC_PWM_CTL2) BLM_COMBINATION_MODE;
+ if (IS_GEN2(dev))
+ return I915_READ(BLC_PWM_CTL) BLM_LEGACY_MODE;
+ return 0;
+}
+
static u32 i915_read_blc_pwm_ctl(struct drm_i915_private *dev_priv)
{
u32 val;
@@ -163,9 +183,12 @@ u32 intel_panel_get_max_backlight(struct drm_device
*dev)
max = 17;
} else {
max = 16;
+ /* Ignore BLM_LEGACY_MODE bit */
if (INTEL_INFO(dev)-gen 4)
max = ~1;
}
+ if (is_backlight_combination_mode(dev))
+ max *= 0xff;
}
DRM_DEBUG_DRIVER(max backlight PWM = %d\n, max);
@@ -183,6 +206,12 @@ u32 intel_panel_get_backlight(struct drm_device *dev)
val = I915_READ(BLC_PWM_CTL) BACKLIGHT_DUTY_CYCLE_MASK;
if (IS_PINEVIEW(dev))
val = 1;
+ if (is_backlight_combination_mode(dev)){
+ u8 lbpc;
+
+ pci_read_config_byte(dev-pdev, PCI_LBPC, lbpc);
+ val *= lbpc;
+ }
}
DRM_DEBUG_DRIVER(get backlight PWM = %d\n, val);
@@ -205,6 +234,15 @@ void intel_panel_set_backlight(struct drm_device *dev,
u32 level)
if (HAS_PCH_SPLIT(dev))
return intel_pch_panel_set_backlight(dev, level);
+
+ if (level is_backlight_combination_mode(dev)){
+ u32 max = intel_panel_get_max_backlight(dev);
+ u8 lpbc;
+
+ lpbc = level * 0xff / max;
+ level /= lpbc;
Hmm, I don't think this calculation is correct. This would result
in level of opregion over its limit. For example, assume the level
max = 100, so total max = 25500. Passing level=150 here will be:
lbpc = 150 * 0xff / 25500 = 1.5 = 1
level = 150 / 1 = 150, which is over limit.
More worse, lbpc can be zero when level is below 100 in the case
above...
That is, Chris' original code in that portion was correct:
if (is_backlight_combination_mode(dev)){
u32 max = intel_panel_get_max_backlight(dev);
u8 lpbc;
lpbc = level * 0xfe / max
[Bug 35051] [RADEON:KMS:R600G] wine Counter Strike Source Crashes at Startup
https://bugs.freedesktop.org/show_bug.cgi?id=35051 --- Comment #6 from Tobias Jakobi liquid.a...@gmx.net 2011-03-10 00:37:09 PST --- Radeon HD 4770 [RV740] with the latest d-r-t -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] fix backlight brightness on intel LVDS panel after reopening lid
On Thu, March 10, 2011 08:49, Takashi Iwai wrote:
At Thu, 10 Mar 2011 06:50:09 +0100 (CET),
Indan Zupancic wrote:
Hello,
On Fri, March 4, 2011 19:47, Linus Torvalds wrote:
Alex, can you confirm that the revert of 951f3512dba5 plus the
one-liner patch from Takashi that Indan quoted also works for you?
Linus
On Thu, Mar 3, 2011 at 10:53 PM, Indan Zupancic in...@nul.nu wrote:
So please revert my patch and apply Takashi Iwai's, which fixes the
most immediate bug without changing anything else. This should go
in stable too.
I found another backlight bug:
When suspending intel_panel_disable_backlight() is never called,
but intel_panel_enable_backlight() is called at resume. With the
effect that if the brightness was ever changed after screen
blanking, the wrong brightness gets restored.
This explains the weird behaviour I've seen. I didn't see it with
combination mode, because then the brightness is always the same
(zero or the maximum, the BIOS only uses LBPC on my system.) I'll
send a patch in a moment.
Alternative for reverting the combination mode removal (I can also
redo the patch against the revert and Takashi's patch, if that's
preferred):
--
drm/i915: Do handle backlight combination mode specially
Add back the combination mode check, but with slightly cleaner code
and the weirdness removed: No val = 1, but also no val = ~1. The
old code probably confused bit 0 with BLM_LEGACY_MODE, which is bit 16.
The other change is clearer calculations: Just check for zero level
explicitly instead of avoiding the divide-by-zero.
Signed-off-by: Indan Zupancic in...@nul.nu
---
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_panel.c
index d860abe..b05631a 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -30,6 +30,10 @@
#include intel_drv.h
+#define PCI_LBPC 0xf4 /* legacy/combination backlight modes */
+#define BLM_COMBINATION_MODE (1 30)
+#define BLM_LEGACY_MODE (1 16)
+
void
intel_fixed_panel_mode(struct drm_display_mode *fixed_mode,
struct drm_display_mode *adjusted_mode)
@@ -110,6 +114,22 @@ done:
dev_priv-pch_pf_size = (width 16) | height;
}
+/*
+ * What about gen 3? If there are no gen 3 systems with ASLE,
+ * then it doesn't matter, as we don't need to change the
+ * brightness. But then the gen 2 check can be removed too.
+ */
+static int is_backlight_combination_mode(struct drm_device *dev)
+{
+struct drm_i915_private *dev_priv = dev-dev_private;
+
+if (INTEL_INFO(dev)-gen = 4)
+return I915_READ(BLC_PWM_CTL2) BLM_COMBINATION_MODE;
+if (IS_GEN2(dev))
+return I915_READ(BLC_PWM_CTL) BLM_LEGACY_MODE;
+return 0;
+}
+
static u32 i915_read_blc_pwm_ctl(struct drm_i915_private *dev_priv)
{
u32 val;
@@ -163,9 +183,12 @@ u32 intel_panel_get_max_backlight(struct drm_device
*dev)
max = 17;
} else {
max = 16;
+/* Ignore BLM_LEGACY_MODE bit */
if (INTEL_INFO(dev)-gen 4)
max = ~1;
}
+if (is_backlight_combination_mode(dev))
+max *= 0xff;
}
DRM_DEBUG_DRIVER(max backlight PWM = %d\n, max);
@@ -183,6 +206,12 @@ u32 intel_panel_get_backlight(struct drm_device *dev)
val = I915_READ(BLC_PWM_CTL) BACKLIGHT_DUTY_CYCLE_MASK;
if (IS_PINEVIEW(dev))
val = 1;
+if (is_backlight_combination_mode(dev)){
+u8 lbpc;
+
+pci_read_config_byte(dev-pdev, PCI_LBPC, lbpc);
+val *= lbpc;
+}
}
DRM_DEBUG_DRIVER(get backlight PWM = %d\n, val);
@@ -205,6 +234,15 @@ void intel_panel_set_backlight(struct drm_device *dev,
u32 level)
if (HAS_PCH_SPLIT(dev))
return intel_pch_panel_set_backlight(dev, level);
+
+if (level is_backlight_combination_mode(dev)){
+u32 max = intel_panel_get_max_backlight(dev);
+u8 lpbc;
+
+lpbc = level * 0xff / max;
+level /= lpbc;
Hmm, I don't think this calculation is correct. This would result
in level of opregion over its limit. For example, assume the level
max = 100, so total max = 25500. Passing level=150 here will be:
lbpc = 150 * 0xff / 25500 = 1.5 = 1
level = 150 / 1 = 150, which is over limit.
More worse, lbpc can be zero when level is below 100 in the case
above...
Yes, you're right. It seems that any simplification I try to do
creates a new bug.
Do you have any bright idea why the old code did val = ~1; too?
It seems obvious it's related to val = 1, but...
Thanks,
Indan
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
[Bug 35150] Starcraft 2 on wine on evergreen doesn't show login screen
https://bugs.freedesktop.org/show_bug.cgi?id=35150 --- Comment #4 from David Mills d.mills-...@guesny.net 2011-03-10 00:57:23 PST --- OK, I've recompiled using the latest gallium (20110309) Starcraft 2 starts, but most/all textures aren't shown (this counts for cinematics, the interface background and in game) Wine is giving the following errors which seem to correspond: err:d3d_surface:surface_allocate_surface GL_INVALID_VALUE (0x501) from glTexImage2D @ ../../../wine/dlls/wined3d/surface.c / 1095 ---SNIP--- err:d3d_surface:surface_upload_data GL_INVALID_ENUM (0x500) from glCompressedTexSubImage2DARB @ ../../../wine/dlls/wined3d/surface.c / 994 The above repeated many times. Cinematics/ingame graphics are also very slow (as in slide show) but that might just be a symptom of what is causing the texture problems. A google says this might be S3TC related, so I'll try re-compiling with support enabled to test. I find it strange that SC2 was marked as supported up until December on RadeonProgram in that case though. The could very well be pebkac, so any hints / links / man pages are welcome. I'll post an update to show what I've found David -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 35150] Starcraft 2 on wine on evergreen doesn't show login screen
https://bugs.freedesktop.org/show_bug.cgi?id=35150 --- Comment #5 from Tobias Jakobi liquid.a...@gmx.net 2011-03-10 01:01:30 PST --- You need a 32-bit (!) compile of libtxc_dxtn. Use for example Marek's maintained version of the library from here: http://cgit.freedesktop.org/~mareko/libtxc_dxtn/ -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 35150] Starcraft 2 on wine on evergreen doesn't show login screen
https://bugs.freedesktop.org/show_bug.cgi?id=35150 --- Comment #7 from David Mills d.mills-...@guesny.net 2011-03-10 01:23:40 PST --- Thanks, some googleing already pointed me to libtc_dxtn and the enviroment variable. OK, enabling S3TC got the textures to rendre (more or less) OK. Still some texture tearing but that should be expected ATM. The game still runs slideshow slow however (even though the interface in itself is super fluid). I'll look into what exactly is causing that later on, my gut says software fallback, but I don't have a mesa-hardened gut yet ;) (got to go work a bit). Thanks for your help. David -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] fix backlight brightness on intel LVDS panel after reopening lid
On Thu, March 10, 2011 09:25, Takashi Iwai wrote:
At Thu, 10 Mar 2011 08:49:37 +0100,
Takashi Iwai wrote:
At Thu, 10 Mar 2011 06:50:09 +0100 (CET),
Indan Zupancic wrote:
Hello,
On Fri, March 4, 2011 19:47, Linus Torvalds wrote:
Alex, can you confirm that the revert of 951f3512dba5 plus the
one-liner patch from Takashi that Indan quoted also works for you?
Linus
On Thu, Mar 3, 2011 at 10:53 PM, Indan Zupancic in...@nul.nu wrote:
So please revert my patch and apply Takashi Iwai's, which fixes the
most immediate bug without changing anything else. This should go
in stable too.
I found another backlight bug:
When suspending intel_panel_disable_backlight() is never called,
but intel_panel_enable_backlight() is called at resume. With the
effect that if the brightness was ever changed after screen
blanking, the wrong brightness gets restored.
This explains the weird behaviour I've seen. I didn't see it with
combination mode, because then the brightness is always the same
(zero or the maximum, the BIOS only uses LBPC on my system.) I'll
send a patch in a moment.
Alternative for reverting the combination mode removal (I can also
redo the patch against the revert and Takashi's patch, if that's
preferred):
--
drm/i915: Do handle backlight combination mode specially
Add back the combination mode check, but with slightly cleaner code
and the weirdness removed: No val = 1, but also no val = ~1. The
old code probably confused bit 0 with BLM_LEGACY_MODE, which is bit 16.
The other change is clearer calculations: Just check for zero level
explicitly instead of avoiding the divide-by-zero.
Signed-off-by: Indan Zupancic in...@nul.nu
---
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_panel.c
index d860abe..b05631a 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -30,6 +30,10 @@
#include intel_drv.h
+#define PCI_LBPC 0xf4 /* legacy/combination backlight modes */
+#define BLM_COMBINATION_MODE (1 30)
+#define BLM_LEGACY_MODE (1 16)
+
void
intel_fixed_panel_mode(struct drm_display_mode *fixed_mode,
struct drm_display_mode *adjusted_mode)
@@ -110,6 +114,22 @@ done:
dev_priv-pch_pf_size = (width 16) | height;
}
+/*
+ * What about gen 3? If there are no gen 3 systems with ASLE,
+ * then it doesn't matter, as we don't need to change the
+ * brightness. But then the gen 2 check can be removed too.
+ */
+static int is_backlight_combination_mode(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+
+ if (INTEL_INFO(dev)-gen = 4)
+ return I915_READ(BLC_PWM_CTL2) BLM_COMBINATION_MODE;
+ if (IS_GEN2(dev))
+ return I915_READ(BLC_PWM_CTL) BLM_LEGACY_MODE;
+ return 0;
+}
+
static u32 i915_read_blc_pwm_ctl(struct drm_i915_private *dev_priv)
{
u32 val;
@@ -163,9 +183,12 @@ u32 intel_panel_get_max_backlight(struct drm_device
*dev)
max = 17;
} else {
max = 16;
+ /* Ignore BLM_LEGACY_MODE bit */
if (INTEL_INFO(dev)-gen 4)
max = ~1;
}
+ if (is_backlight_combination_mode(dev))
+ max *= 0xff;
}
DRM_DEBUG_DRIVER(max backlight PWM = %d\n, max);
@@ -183,6 +206,12 @@ u32 intel_panel_get_backlight(struct drm_device *dev)
val = I915_READ(BLC_PWM_CTL) BACKLIGHT_DUTY_CYCLE_MASK;
if (IS_PINEVIEW(dev))
val = 1;
+ if (is_backlight_combination_mode(dev)){
+ u8 lbpc;
+
+ pci_read_config_byte(dev-pdev, PCI_LBPC, lbpc);
+ val *= lbpc;
+ }
}
DRM_DEBUG_DRIVER(get backlight PWM = %d\n, val);
@@ -205,6 +234,15 @@ void intel_panel_set_backlight(struct drm_device
*dev, u32 level)
if (HAS_PCH_SPLIT(dev))
return intel_pch_panel_set_backlight(dev, level);
+
+ if (level is_backlight_combination_mode(dev)){
+ u32 max = intel_panel_get_max_backlight(dev);
+ u8 lpbc;
+
+ lpbc = level * 0xff / max;
+ level /= lpbc;
Hmm, I don't think this calculation is correct. This would result
in level of opregion over its limit. For example, assume the level
max = 100, so total max = 25500. Passing level=150 here will be:
lbpc = 150 * 0xff / 25500 = 1.5 = 1
level = 150 / 1 = 150, which is over limit.
More worse, lbpc can be zero when level is below 100 in the case
above...
That is, Chris' original code in that portion was correct:
if (is_backlight_combination_mode(dev)){
u32 max = intel_panel_get_max_backlight(dev);
u8 lpbc;
lpbc = level * 0xfe / max + 1;
Re: [PATCH] drm/i915: fix corruptions on i8xx due to relaxed fencing
On Thu, March 10, 2011 08:52, Daniel Vetter wrote: Am Do, 10.03.2011, 06:06 schrieb Indan Zupancic: This isn't in rc8, can someone make sure it gets into 2.6.38-rc9/2.6.38? The patch unfortunately broke gen4+ (more precisely: the unwritten abi guarantee that userspace can tile buffers that don't have a complete last tile row, as long as it promises not to touch it). Hence it got reverted. It was just a enforcement check to prevent broken userspace from fooling itself. The proper fix is to upgrade your userspace (libdrm + xf86-video-intel). [Aside: This only happens if you have new enough userspace that supports relaxed tiling. Old userspace and new kernels are _not_ broken.] Yes, I noticed it got reverted when digging into git log, but the commit message only said it broke gen4+, not how gen2 should be unbroken after the revert. Which versions fix this, just for reference? I got libdrm 2.4.23 and xf86-video-intel 2.14.0. (As a side note, do you have version checking on the kernel side? If so, you could return 0 for the relaxed fencing feature check if the driver is the wrong version.) To keep things manageable I either upgrade the kernel, or userspace, but never both at once. It seems that that doesn't work with graphics. Thanks, Indan ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 30651] [RADEON:KMS:R600G] gl output in mplayer have no colors if used with a fragment program with additional lookup and bicubic B-spline filtering
https://bugs.freedesktop.org/show_bug.cgi?id=30651 --- Comment #6 from Sergey Kondakov virtuous...@gmail.com 2011-03-10 03:24:51 PST --- yes, thanks. the green thing is gone with yuv=6 but 1) yuv=4 on r600g still have no colours even though with r300g they are ok 2) still there is an overbright glitch in some white places in some videos with yuv=6. but again, it may be a mplayer bug since it present with r300g too (but not software rasterizer), i'm not sure. so, it's back to beginning. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 30832] Radeon S-Video Out has become black and white. Works fine in 2.6.37
https://bugzilla.kernel.org/show_bug.cgi?id=30832 --- Comment #2 from Arbit Rabbit arbitrab...@runbox.com 2011-03-10 11:26:04 --- Created an attachment (id=50562) -- (https://bugzilla.kernel.org/attachment.cgi?id=50562) Complete 2.6.38-rc6 kernel log -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 30832] Radeon S-Video Out has become black and white. Works fine in 2.6.37
https://bugzilla.kernel.org/show_bug.cgi?id=30832 --- Comment #3 from Arbit Rabbit arbitrab...@runbox.com 2011-03-10 11:26:46 --- Created an attachment (id=50572) -- (https://bugzilla.kernel.org/attachment.cgi?id=50572) Complete 2.6.37 kernel log -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: vblank problem (and proposed fix) on crtc 1
On Mit, 2011-03-09 at 11:33 -0600, Ilija Hadzic wrote:
So what I did is to actually probe the kernel at screen init time.
When the screen is initialized, the DDX checks if the GPU has more than
two CRTCs and tries a dummy vblank wait on all crtcs 1. If any
of them fails, it falls back to the old method of using only
primary/secondary flag.
I'm afraid I don't really like this. Apart from the ugly bogus error
message, the probes could fail for other reasons, e.g. at some point we
might want to return an error when the ioctl is called for a CRTC which
is currently disabled, to avoid the hang you were getting for CRTC 1.
Dave's drm-next tree actually has a new DRM_IOCTL_GET_CAP ioctl, which
could be used for detecting this capability. It might even be possible
to handle old kernels transparently in drmWaitVBlank(), but I'm not sure
offhand if that would be better overall than doing it in the driver
code.
Some detailed technical comments:
diff --git a/src/radeon_dri2.c b/src/radeon_dri2.c
index 66df03c..c45abe6 100644
--- a/src/radeon_dri2.c
+++ b/src/radeon_dri2.c
@@ -1145,8 +1193,15 @@ static int radeon_dri2_schedule_swap(ClientPtr client,
DrawablePtr draw,
vbl.request.type = DRM_VBLANK_ABSOLUTE | DRM_VBLANK_EVENT;
if (flip == 0)
vbl.request.type |= DRM_VBLANK_NEXTONMISS;
-if (crtc 0)
+if (crtc == 1)
vbl.request.type |= DRM_VBLANK_SECONDARY;
+else if (crtc 1) {
+ if (info-high_crtc_works) {
+ high_crtc = (crtc DRM_VBLANK_HIGH_CRTC_SHIFT)
+ DRM_VBLANK_HIGH_CRTC_MASK;
+ } else vbl.request.type |= DRM_VBLANK_SECONDARY;
Waiting on a random other CRTC makes no sense. If you know you can't
wait on the given CRTC, don't wait at all.
@@ -1261,6 +1319,22 @@ radeon_dri2_screen_init(ScreenPtr pScreen)
xf86DrvMsg(pScrn-scrnIndex, X_WARNING, You need a newer kernel
for sync extension\n);
}
+if (info-drmmode.mode_res-count_crtcs 2) {
+ xf86DrvMsg(pScrn-scrnIndex, X_INFO, GPU with %d CRTCs found,
probing VBLANKs on CRTC1\n,
+ info-drmmode.mode_res-count_crtcs);
+ info-high_crtc_works = TRUE;
+ for (c=2; cinfo-drmmode.mode_res-count_crtcs; c++) {
+ vbl.request.type = DRM_VBLANK_RELATIVE;
+ vbl.request.type |= (c DRM_VBLANK_HIGH_CRTC_SHIFT)
DRM_VBLANK_HIGH_CRTC_MASK;
+ vbl.request.sequence = 0;
+ if (drmWaitVBlank(info-dri2.drm_fd, vbl)) {
+ xf86DrvMsg(pScrn-scrnIndex, X_WARNING, Kernel rejects
VBLANK request on CRTC %d\n, c);
+ info-high_crtc_works = FALSE;
Should break out of the for loop at this point.
+ }
+ }
+ if (info-high_crtc_works) xf86DrvMsg(pScrn-scrnIndex, X_INFO,
VBLANK request accepted on all CRTCs\n);
The statement guarded by the if condition needs to go on a new line, and
please don't add trailing whitespace. Also, again, please match the
indentation of the surrounding code.
--
Earthling Michel Dänzer |http://www.vmware.com
Libre software enthusiast | Debian, X and DRI developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] fix backlight brightness on intel LVDS panel after reopening lid
At Thu, 10 Mar 2011 09:45:18 +0100 (CET),
Indan Zupancic wrote:
On Thu, March 10, 2011 08:49, Takashi Iwai wrote:
At Thu, 10 Mar 2011 06:50:09 +0100 (CET),
Indan Zupancic wrote:
Hello,
On Fri, March 4, 2011 19:47, Linus Torvalds wrote:
Alex, can you confirm that the revert of 951f3512dba5 plus the
one-liner patch from Takashi that Indan quoted also works for you?
Linus
On Thu, Mar 3, 2011 at 10:53 PM, Indan Zupancic in...@nul.nu wrote:
So please revert my patch and apply Takashi Iwai's, which fixes the
most immediate bug without changing anything else. This should go
in stable too.
I found another backlight bug:
When suspending intel_panel_disable_backlight() is never called,
but intel_panel_enable_backlight() is called at resume. With the
effect that if the brightness was ever changed after screen
blanking, the wrong brightness gets restored.
This explains the weird behaviour I've seen. I didn't see it with
combination mode, because then the brightness is always the same
(zero or the maximum, the BIOS only uses LBPC on my system.) I'll
send a patch in a moment.
Alternative for reverting the combination mode removal (I can also
redo the patch against the revert and Takashi's patch, if that's
preferred):
--
drm/i915: Do handle backlight combination mode specially
Add back the combination mode check, but with slightly cleaner code
and the weirdness removed: No val = 1, but also no val = ~1. The
old code probably confused bit 0 with BLM_LEGACY_MODE, which is bit 16.
The other change is clearer calculations: Just check for zero level
explicitly instead of avoiding the divide-by-zero.
Signed-off-by: Indan Zupancic in...@nul.nu
---
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_panel.c
index d860abe..b05631a 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -30,6 +30,10 @@
#include intel_drv.h
+#define PCI_LBPC 0xf4 /* legacy/combination backlight modes */
+#define BLM_COMBINATION_MODE (1 30)
+#define BLM_LEGACY_MODE (1 16)
+
void
intel_fixed_panel_mode(struct drm_display_mode *fixed_mode,
struct drm_display_mode *adjusted_mode)
@@ -110,6 +114,22 @@ done:
dev_priv-pch_pf_size = (width 16) | height;
}
+/*
+ * What about gen 3? If there are no gen 3 systems with ASLE,
+ * then it doesn't matter, as we don't need to change the
+ * brightness. But then the gen 2 check can be removed too.
+ */
+static int is_backlight_combination_mode(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+
+ if (INTEL_INFO(dev)-gen = 4)
+ return I915_READ(BLC_PWM_CTL2) BLM_COMBINATION_MODE;
+ if (IS_GEN2(dev))
+ return I915_READ(BLC_PWM_CTL) BLM_LEGACY_MODE;
+ return 0;
+}
+
static u32 i915_read_blc_pwm_ctl(struct drm_i915_private *dev_priv)
{
u32 val;
@@ -163,9 +183,12 @@ u32 intel_panel_get_max_backlight(struct drm_device
*dev)
max = 17;
} else {
max = 16;
+ /* Ignore BLM_LEGACY_MODE bit */
if (INTEL_INFO(dev)-gen 4)
max = ~1;
}
+ if (is_backlight_combination_mode(dev))
+ max *= 0xff;
}
DRM_DEBUG_DRIVER(max backlight PWM = %d\n, max);
@@ -183,6 +206,12 @@ u32 intel_panel_get_backlight(struct drm_device *dev)
val = I915_READ(BLC_PWM_CTL) BACKLIGHT_DUTY_CYCLE_MASK;
if (IS_PINEVIEW(dev))
val = 1;
+ if (is_backlight_combination_mode(dev)){
+ u8 lbpc;
+
+ pci_read_config_byte(dev-pdev, PCI_LBPC, lbpc);
+ val *= lbpc;
+ }
}
DRM_DEBUG_DRIVER(get backlight PWM = %d\n, val);
@@ -205,6 +234,15 @@ void intel_panel_set_backlight(struct drm_device
*dev, u32 level)
if (HAS_PCH_SPLIT(dev))
return intel_pch_panel_set_backlight(dev, level);
+
+ if (level is_backlight_combination_mode(dev)){
+ u32 max = intel_panel_get_max_backlight(dev);
+ u8 lpbc;
+
+ lpbc = level * 0xff / max;
+ level /= lpbc;
Hmm, I don't think this calculation is correct. This would result
in level of opregion over its limit. For example, assume the level
max = 100, so total max = 25500. Passing level=150 here will be:
lbpc = 150 * 0xff / 25500 = 1.5 = 1
level = 150 / 1 = 150, which is over limit.
More worse, lbpc can be zero when level is below 100 in the case
above...
Yes, you're right. It seems that any simplification I try to do
creates a new bug.
Do you have any bright idea why the old code did val = ~1; too?
It seems obvious it's related to val = 1, but...
I guess it's for the case
Re: [PATCH] fix backlight brightness on intel LVDS panel after reopening lid
At Thu, 10 Mar 2011 11:06:28 +0100 (CET),
Indan Zupancic wrote:
On Thu, March 10, 2011 09:25, Takashi Iwai wrote:
At Thu, 10 Mar 2011 08:49:37 +0100,
Takashi Iwai wrote:
At Thu, 10 Mar 2011 06:50:09 +0100 (CET),
Indan Zupancic wrote:
Hello,
On Fri, March 4, 2011 19:47, Linus Torvalds wrote:
Alex, can you confirm that the revert of 951f3512dba5 plus the
one-liner patch from Takashi that Indan quoted also works for you?
Linus
On Thu, Mar 3, 2011 at 10:53 PM, Indan Zupancic in...@nul.nu wrote:
So please revert my patch and apply Takashi Iwai's, which fixes the
most immediate bug without changing anything else. This should go
in stable too.
I found another backlight bug:
When suspending intel_panel_disable_backlight() is never called,
but intel_panel_enable_backlight() is called at resume. With the
effect that if the brightness was ever changed after screen
blanking, the wrong brightness gets restored.
This explains the weird behaviour I've seen. I didn't see it with
combination mode, because then the brightness is always the same
(zero or the maximum, the BIOS only uses LBPC on my system.) I'll
send a patch in a moment.
Alternative for reverting the combination mode removal (I can also
redo the patch against the revert and Takashi's patch, if that's
preferred):
--
drm/i915: Do handle backlight combination mode specially
Add back the combination mode check, but with slightly cleaner code
and the weirdness removed: No val = 1, but also no val = ~1. The
old code probably confused bit 0 with BLM_LEGACY_MODE, which is bit 16.
The other change is clearer calculations: Just check for zero level
explicitly instead of avoiding the divide-by-zero.
Signed-off-by: Indan Zupancic in...@nul.nu
---
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_panel.c
index d860abe..b05631a 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -30,6 +30,10 @@
#include intel_drv.h
+#define PCI_LBPC 0xf4 /* legacy/combination backlight modes */
+#define BLM_COMBINATION_MODE (1 30)
+#define BLM_LEGACY_MODE (1 16)
+
void
intel_fixed_panel_mode(struct drm_display_mode *fixed_mode,
struct drm_display_mode *adjusted_mode)
@@ -110,6 +114,22 @@ done:
dev_priv-pch_pf_size = (width 16) | height;
}
+/*
+ * What about gen 3? If there are no gen 3 systems with ASLE,
+ * then it doesn't matter, as we don't need to change the
+ * brightness. But then the gen 2 check can be removed too.
+ */
+static int is_backlight_combination_mode(struct drm_device *dev)
+{
+struct drm_i915_private *dev_priv = dev-dev_private;
+
+if (INTEL_INFO(dev)-gen = 4)
+return I915_READ(BLC_PWM_CTL2) BLM_COMBINATION_MODE;
+if (IS_GEN2(dev))
+return I915_READ(BLC_PWM_CTL) BLM_LEGACY_MODE;
+return 0;
+}
+
static u32 i915_read_blc_pwm_ctl(struct drm_i915_private *dev_priv)
{
u32 val;
@@ -163,9 +183,12 @@ u32 intel_panel_get_max_backlight(struct drm_device
*dev)
max = 17;
} else {
max = 16;
+/* Ignore BLM_LEGACY_MODE bit */
if (INTEL_INFO(dev)-gen 4)
max = ~1;
}
+if (is_backlight_combination_mode(dev))
+max *= 0xff;
}
DRM_DEBUG_DRIVER(max backlight PWM = %d\n, max);
@@ -183,6 +206,12 @@ u32 intel_panel_get_backlight(struct drm_device
*dev)
val = I915_READ(BLC_PWM_CTL)
BACKLIGHT_DUTY_CYCLE_MASK;
if (IS_PINEVIEW(dev))
val = 1;
+if (is_backlight_combination_mode(dev)){
+u8 lbpc;
+
+pci_read_config_byte(dev-pdev, PCI_LBPC,
lbpc);
+val *= lbpc;
+}
}
DRM_DEBUG_DRIVER(get backlight PWM = %d\n, val);
@@ -205,6 +234,15 @@ void intel_panel_set_backlight(struct drm_device
*dev, u32 level)
if (HAS_PCH_SPLIT(dev))
return intel_pch_panel_set_backlight(dev, level);
+
+if (level is_backlight_combination_mode(dev)){
+u32 max = intel_panel_get_max_backlight(dev);
+u8 lpbc;
+
+lpbc = level * 0xff / max;
+level /= lpbc;
Hmm, I don't think this calculation is correct. This would result
in level of opregion over its limit. For example, assume the level
max = 100, so total max = 25500. Passing
[PATCH] drm/i915: Revive combination mode for backlight control
This reverts commit 951f3512dba5bd44cda3e5ee22b4b522e4bb09fb
drm/i915: Do not handle backlight combination mode specially
since this commit introduced other regressions due to untouched LBPC
register, e.g. the backlight dimmed after resume.
In addition to the revert, this patch includes a fix for the original
issue (weird backlight levels) by removing the wrong bit shift for
computing the current backlight level.
Also, including typo fixes (lpbc - lbpc).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=34524
Acked-by: Indan Zupancic in...@nul.nu
Cc: sta...@kernel.org
Signed-off-by: Takashi Iwai ti...@suse.de
---
drivers/gpu/drm/i915/i915_reg.h| 10 ++
drivers/gpu/drm/i915/intel_panel.c | 36
2 files changed, 46 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 3e6f486..2abe240 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1553,7 +1553,17 @@
/* Backlight control */
#define BLC_PWM_CTL0x61254
+#define BACKLIGHT_MODULATION_FREQ_SHIFT (17)
#define BLC_PWM_CTL2 0x61250 /* 965+ only */
+#define BLM_COMBINATION_MODE (1 30)
+/*
+ * This is the most significant 15 bits of the number of backlight cycles in a
+ * complete cycle of the modulated backlight control.
+ *
+ * The actual value is this field multiplied by two.
+ */
+#define BACKLIGHT_MODULATION_FREQ_MASK (0x7fff 17)
+#define BLM_LEGACY_MODE (1 16)
/*
* This is the number of cycles out of the backlight modulation cycle for which
* the backlight is on.
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_panel.c
index d860abe..f8f86e5 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -30,6 +30,8 @@
#include intel_drv.h
+#define PCI_LBPC 0xf4 /* legacy/combination backlight modes */
+
void
intel_fixed_panel_mode(struct drm_display_mode *fixed_mode,
struct drm_display_mode *adjusted_mode)
@@ -110,6 +112,19 @@ done:
dev_priv-pch_pf_size = (width 16) | height;
}
+static int is_backlight_combination_mode(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+
+ if (INTEL_INFO(dev)-gen = 4)
+ return I915_READ(BLC_PWM_CTL2) BLM_COMBINATION_MODE;
+
+ if (IS_GEN2(dev))
+ return I915_READ(BLC_PWM_CTL) BLM_LEGACY_MODE;
+
+ return 0;
+}
+
static u32 i915_read_blc_pwm_ctl(struct drm_i915_private *dev_priv)
{
u32 val;
@@ -166,6 +181,9 @@ u32 intel_panel_get_max_backlight(struct drm_device *dev)
if (INTEL_INFO(dev)-gen 4)
max = ~1;
}
+
+ if (is_backlight_combination_mode(dev))
+ max *= 0xff;
}
DRM_DEBUG_DRIVER(max backlight PWM = %d\n, max);
@@ -183,6 +201,14 @@ u32 intel_panel_get_backlight(struct drm_device *dev)
val = I915_READ(BLC_PWM_CTL) BACKLIGHT_DUTY_CYCLE_MASK;
if (IS_PINEVIEW(dev))
val = 1;
+
+ if (is_backlight_combination_mode(dev)){
+ u8 lbpc;
+
+ val = ~1;
+ pci_read_config_byte(dev-pdev, PCI_LBPC, lbpc);
+ val *= lbpc;
+ }
}
DRM_DEBUG_DRIVER(get backlight PWM = %d\n, val);
@@ -205,6 +231,16 @@ void intel_panel_set_backlight(struct drm_device *dev, u32
level)
if (HAS_PCH_SPLIT(dev))
return intel_pch_panel_set_backlight(dev, level);
+
+ if (is_backlight_combination_mode(dev)){
+ u32 max = intel_panel_get_max_backlight(dev);
+ u8 lbpc;
+
+ lbpc = level * 0xfe / max + 1;
+ level /= lbpc;
+ pci_write_config_byte(dev-pdev, PCI_LBPC, lbpc);
+ }
+
tmp = I915_READ(BLC_PWM_CTL);
if (IS_PINEVIEW(dev)) {
tmp = ~(BACKLIGHT_DUTY_CYCLE_MASK - 1);
--
1.7.4.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915: fix corruptions on i8xx due to relaxed fencing
Am Do, 10.03.2011, 11:36 schrieb Indan Zupancic: On Thu, March 10, 2011 08:52, Daniel Vetter wrote: [Aside: This only happens if you have new enough userspace that supports relaxed tiling. Old userspace and new kernels are _not_ broken.] Yes, I noticed it got reverted when digging into git log, but the commit message only said it broke gen4+, not how gen2 should be unbroken after the revert. Which versions fix this, just for reference? git master branch of libdrm and xf86-video-intel newer than 2011-02-22. -Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: vblank problem (and proposed fix) on crtc 1
On Thu, 10 Mar 2011, Michel [ISO-8859-1] D�nzer wrote:
I'm afraid I don't really like this. Apart from the ugly bogus error
message, the probes could fail for other reasons, e.g. at some point we
might want to return an error when the ioctl is called for a CRTC which
is currently disabled, to avoid the hang you were getting for CRTC 1.
Your example actually speaks in favor of probing. Let's say that the
future kernel starts returning an error for disabled CRTC and you don't do
any probing. DDX will start calling vblank waits on disabled CRTC (just
like it's doing now) and spam the kernel with errors. With probing, error
will happen only once at screen init time.
Dave's drm-next tree actually has a new DRM_IOCTL_GET_CAP ioctl, which
could be used for detecting this capability. It might even be possible
to handle old kernels transparently in drmWaitVBlank(), but I'm not sure
offhand if that would be better overall than doing it in the driver
code.
This argument is self defeating. The purpose of the probing is to check
for the old kernel. If I have DRM_IOCTL_GET_CAP, that means that I have a
new kernel so probing will just work. If I have an old kernel then I don't
have DRM_IOCTL_GET_CAP ioctl, so attemting to use it will result in an
error from the kernel anyway. It makes no sense to me to cause an error
in one ioctl so that you would prevent an error in other ioctl.
+ if (info-high_crtc_works) {
+ high_crtc = (crtc DRM_VBLANK_HIGH_CRTC_SHIFT)
+ DRM_VBLANK_HIGH_CRTC_MASK;
+ } else vbl.request.type |= DRM_VBLANK_SECONDARY;
Waiting on a random other CRTC makes no sense. If you know you can't
wait on the given CRTC, don't wait at all.
It's not random CRTC, but it's what today's DDX and DRM call secondary
CRTC. I intentionally did this for two reasons. First, this is the
behavior that is identical to what we see today, and I prefer to preserve
the same behavior if either component is old (DDX or kernel), rather than
have different behavior for different combinations of old/new. The second
reason is pragmatic, if you want to not call wait_vblank at all and make
sure you are safe to whatever the code above you is doing and not
return an error you have to make up the sequence numbers and timestamps
(and probably keep track of them) and that's much more radical
modification to the DDX. So I figured this would be conservative.
+ vbl.request.sequence = 0;
+ if (drmWaitVBlank(info-dri2.drm_fd, vbl)) {
+ xf86DrvMsg(pScrn-scrnIndex, X_WARNING, Kernel rejects VBLANK
request on CRTC %d\n, c);
+ info-high_crtc_works = FALSE;
Should break out of the for loop at this point.
This was also intentional. I want to see in Xorg log file the full list of
crtcs that rejected the vblank wait request. It comes handy for analyzing
the problems and/or bugs.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: vblank problem (and proposed fix) on crtc 1
On Don, 2011-03-10 at 07:32 -0600, Ilija Hadzic wrote:
On Thu, 10 Mar 2011, Michel [ISO-8859-1] Dnzer wrote:
I'm afraid I don't really like this. Apart from the ugly bogus error
message, the probes could fail for other reasons, e.g. at some point we
might want to return an error when the ioctl is called for a CRTC which
is currently disabled, to avoid the hang you were getting for CRTC 1.
Your example actually speaks in favor of probing. Let's say that the
future kernel starts returning an error for disabled CRTC and you don't do
any probing. DDX will start calling vblank waits on disabled CRTC (just
like it's doing now) and spam the kernel with errors.
No, userspace shouldn't call the ioctl for a disabled CRTC during normal
operation, that would be a bug of its own. However, a CRTC could be
disabled during the probe but get enabled later, e.g. due to
hot-plugging a display.
Dave's drm-next tree actually has a new DRM_IOCTL_GET_CAP ioctl, which
could be used for detecting this capability. It might even be possible
to handle old kernels transparently in drmWaitVBlank(), but I'm not sure
offhand if that would be better overall than doing it in the driver
code.
This argument is self defeating. The purpose of the probing is to check
for the old kernel. If I have DRM_IOCTL_GET_CAP, that means that I have a
new kernel so probing will just work. If I have an old kernel then I don't
have DRM_IOCTL_GET_CAP ioctl, so attemting to use it will result in an
error from the kernel anyway. It makes no sense to me to cause an error
in one ioctl so that you would prevent an error in other ioctl.
The difference is that there should be no bogus error message in dmesg,
avoiding spurious bug reports.
+ if (info-high_crtc_works) {
+ high_crtc = (crtc DRM_VBLANK_HIGH_CRTC_SHIFT)
+ DRM_VBLANK_HIGH_CRTC_MASK;
+ } else vbl.request.type |= DRM_VBLANK_SECONDARY;
Waiting on a random other CRTC makes no sense. If you know you can't
wait on the given CRTC, don't wait at all.
It's not random CRTC, but it's what today's DDX and DRM call secondary
CRTC. I intentionally did this for two reasons. First, this is the
behavior that is identical to what we see today, and I prefer to preserve
the same behavior if either component is old (DDX or kernel), rather than
have different behavior for different combinations of old/new.
I don't see the value in conserving fundamentally broken behaviour.
The second reason is pragmatic, if you want to not call wait_vblank at
all and make sure you are safe to whatever the code above you is doing
and not return an error you have to make up the sequence numbers and
timestamps (and probably keep track of them) and that's much more
radical modification to the DDX.
You could probably always return 0, or previous value + 1 or whatever,
that's no more wrong than the values from a different CRTC.
+ vbl.request.sequence = 0;
+ if (drmWaitVBlank(info-dri2.drm_fd, vbl)) {
+ xf86DrvMsg(pScrn-scrnIndex, X_WARNING, Kernel rejects
VBLANK request on CRTC %d\n, c);
+ info-high_crtc_works = FALSE;
Should break out of the for loop at this point.
This was also intentional. I want to see in Xorg log file the full list of
crtcs that rejected the vblank wait request. It comes handy for analyzing
the problems and/or bugs.
Then at the very least the claim that 'an error message will appear in
the kernel only once at start up time' is wrong, there will actually be
four of them on old kernels.
--
Earthling Michel Dänzer |http://www.vmware.com
Libre software enthusiast | Debian, X and DRI developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 35150] Starcraft 2 on wine on evergreen doesn't show login screen
https://bugs.freedesktop.org/show_bug.cgi?id=35150 Jerome Glisse gli...@freedesktop.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #8 from Jerome Glisse gli...@freedesktop.org 2011-03-10 09:34:43 PST --- So beside being slow it works ? Closing bug then -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 25710] [DRI1 DRI2] sauerbraten: lines around textures
https://bugs.freedesktop.org/show_bug.cgi?id=25710 --- Comment #1 from Álmos aaalmo...@gmail.com 2011-03-10 10:46:15 PST --- According to my test on an rv350, r300g of mesa 7.10 seems to be free of this bug. If r300c is no longer relevant, this report should be closed. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 25709] [DRI1 DRI2] sauerbraten: broken water rendering
https://bugs.freedesktop.org/show_bug.cgi?id=25709 --- Comment #1 from Álmos aaalmo...@gmail.com 2011-03-10 10:46:39 PST --- According to my test on an rv350, r300g of mesa 7.10 seems to be free of this bug. If r300c is no longer relevant, this report should be closed. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 23545] [r300c/UMS] flashing textures in some maps of sauerbraten game
https://bugs.freedesktop.org/show_bug.cgi?id=23545 --- Comment #13 from Álmos aaalmo...@gmail.com 2011-03-10 10:48:24 PST --- According to my test on an rv350, r300g of mesa 7.10 seems to be free of this bug. If r300c is no longer relevant, this report should be closed. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 25709] [DRI1 DRI2] sauerbraten: broken water rendering
https://bugs.freedesktop.org/show_bug.cgi?id=25709 Marek Olšák mar...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Comment #2 from Marek Olšák mar...@gmail.com 2011-03-10 10:57:28 PST --- Closing because r300c is no longer supported. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 25710] [DRI1 DRI2] sauerbraten: lines around textures
https://bugs.freedesktop.org/show_bug.cgi?id=25710 Marek Olšák mar...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Comment #2 from Marek Olšák mar...@gmail.com 2011-03-10 10:58:02 PST --- Closing because r300c is no longer supported. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: vblank problem (and proposed fix) on crtc 1
On Thu, 10 Mar 2011, Michel [ISO-8859-1] D?nzer wrote: No, userspace shouldn't call the ioctl for a disabled CRTC during normal operation, that would be a bug of its own. Well, that's exactly what DDX is doing today. Try this experiment: open a terminal window and run glxgears in it and observer the frame rate synced up to your monitor. Then in another terminal window type 'xset dpms force off' (or go to dpms off state any other way you want). The screen goes blank (disabled CRTC). Wait a while and then move your mouse to exit the disabled state. Notice the low frame rate reported by glxgears in one line. That's because glxSwapBuffers was blocked while screen was in power-down state. Now I don't know if this behavior is intentional (I know your opinion based on the above), but it looks logical to me: if the screen is off and GLX attempts to wait on it, it gets what it deserves. If this is the real intent, then kernel returning error on disabled screen would break it (the application would just start to rush through rendering at max speed and eat up the I/O and CPU bandwidth for something that you can't see on the screen). Anyway, this is a topic for a separate thread. I tend to agree that one day maybe the error is returned for some other reason (where your example may have been a bad one) so I will look into DRM_IOCTL_GET_CAP. The difference is that there should be no bogus error message in dmesg, avoiding spurious bug reports. That I agree and if GET_CAP ioctl is appropriate here, I'll change to that. There will still be an error message in the kernel at probing time, but hopefully a more meaningfull one. I guess the Xorg log message should then be something along the you need a newer kernel lines. Agreed ? the same behavior if either component is old (DDX or kernel), rather than have different behavior for different combinations of old/new. I don't see the value in conserving fundamentally broken behaviour. There is even less value in introducing a wider variety of broken behaviors. Returning immediately, would cause the application to rush at full speed through buffer swaps and eat up the CPU and I/O bandwidth. It think that there are equal number of ppl. who would argue for that as those who would argue for the opposite. You could probably always return 0, or previous value + 1 or whatever, that's no more wrong than the values from a different CRTC. What I could do doesn't matter that much, because whatever I do would not result it fully functional system unless both the DDX and the kernel match in capabilities. So I go for the one that is less likely to introduce new bugs or unpredictable behavior. Then at the very least the claim that 'an error message will appear in the kernel only once at start up time' is wrong, there will actually be four of them on old kernels. More precisely: num_crtcs - 2 times. Use word 'once' used in a liberal sense ;-) it doesn't happen repetatively during the normal operation. At least, if I can use DRM_IOCTL_GET_CAP (which I still have to check), the message will be more meaningful. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915: Revive combination mode for backlight control
On Thu, 10 Mar 2011 14:02:12 +0100, Takashi Iwai ti...@suse.de wrote: This reverts commit 951f3512dba5bd44cda3e5ee22b4b522e4bb09fb drm/i915: Do not handle backlight combination mode specially since this commit introduced other regressions due to untouched LBPC register, e.g. the backlight dimmed after resume. In addition to the revert, this patch includes a fix for the original issue (weird backlight levels) by removing the wrong bit shift for computing the current backlight level. Also, including typo fixes (lpbc - lbpc). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=34524 Acked-by: Indan Zupancic in...@nul.nu Cc: sta...@kernel.org Signed-off-by: Takashi Iwai ti...@suse.de This looks good, and ensures that LBPC ranges from 0 - 0xfe as required. The one thing we want is a comment that explains + val = ~1; The reason for this is that some ancient platforms wire this bit to be go to max backlight, or at least that's why this was in the 2D driver from which this code was derived. Reviewed-by: Keith Packard kei...@keithp.com Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org -- keith.pack...@intel.com pgpKhf3aaWCKj.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 32312] [RADEON:KMS:R600G] openvg rendering is broken
https://bugs.freedesktop.org/show_bug.cgi?id=32312 --- Comment #8 from Sergey Kondakov virtuous...@gmail.com 2011-03-10 12:25:14 PST --- yes, still no text in text demo. and it's that way for both r600g r300g even if i execute with LIBGL_ALWAYS_SOFTWARE=1. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 35183] New: system freezes with 2.6.38-rc kernel and kms pageflip enabled
https://bugs.freedesktop.org/show_bug.cgi?id=35183 Summary: system freezes with 2.6.38-rc kernel and kms pageflip enabled Product: DRI Version: unspecified Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: aaalmo...@gmail.com The system freezes completely after a few 3d operations (like changing the desktop in compiz a couple of times). No error message appears in dmesg or syslog. Tried both rc7 and rc8 and the drm-radeon-testing branch. If I disable kms pageflip in xorg.conf, the system seems stable. I also tried setting radeon.agpmode=-1, but didn't help. Hardware: radeon 9600xt (rv350 agp) software: latest debian unstable (libdrm2 2.4.23, xserver-xorg 7.6, xserver-xorg-video-radeon 6.14.0) Considering that most distributions use compositing wm by default, and kms pageflip is also enabled by default, this seems like a serious problem. Bugs 21472, 34137, 34643 might be related, but I'm not sure. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 32945] [RADEON:KMS:R300G] HiZ: Weird behavior with 3 pipes
https://bugs.freedesktop.org/show_bug.cgi?id=32945 --- Comment #23 from Nicolas Peninguy npenin...@gmail.com 2011-03-10 13:13:28 PST --- Created an attachment (id=44333) View: https://bugs.freedesktop.org/attachment.cgi?id=44333 Review: https://bugs.freedesktop.org/review?bug=32945attachment=44333 Possible fix The attached patch fixes the issue with shadowtex for me. Sven, can you try it and also see if doom3 is still OK with it ? With 3 pipes values are NPOT, so align() is not suitable in some places I think. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 35187] New: r600g : PIPE_CAP_ARRAY_TEXTURES not manage
https://bugs.freedesktop.org/show_bug.cgi?id=35187 Summary: r600g : PIPE_CAP_ARRAY_TEXTURES not manage Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: minor Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: xodd...@gmail.com When I lunch hugin i have this warning in console (one time) : EE r600_pipe.c:325 r600_get_param - r600: unknown param 36 Apparently param 36 is PIPE_CAP_ARRAY_TEXTURES. Environment : - ubuntu 10.10 with kernel 2.6.37.1 - git version of drm, mesa and xf86-video-ati -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 34137] Kernel null pointer dereference with 2.6.38_rc4, pageflip, Radeon 6310, KDE
https://bugs.freedesktop.org/show_bug.cgi?id=34137 --- Comment #1 from Dave Airlie airl...@freedesktop.org 2011-03-10 16:07:15 PST --- does this patch help? http://people.freedesktop.org/~airlied/scratch/0001-radeon-add-pageflip-hooks-for-fusion.patch -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915: Revive combination mode for backlight control
Hi,
Some nitpicks below. I know you're just restoring the original code,
but if we improve it we can as well do it now.
On Thu, March 10, 2011 14:02, Takashi Iwai wrote:
This reverts commit 951f3512dba5bd44cda3e5ee22b4b522e4bb09fb
drm/i915: Do not handle backlight combination mode specially
since this commit introduced other regressions due to untouched LBPC
register, e.g. the backlight dimmed after resume.
The regression was that, if ALSE was used, the maximum brightness
would be the brightness at boot, because LBPC isn't touched and
the BIOS restores it at boot. So the sympom would be less brightness
levels or lower maximum brightness.
Systems with no ASLE support work fine because there the code is only
used to save and restore the PWM register. LBPC is saved and restored
by the BIOS.
The backlight dimming after resume/blanking was the original bug
caused by the bogus val =1 shift.
In addition to the revert, this patch includes a fix for the original
issue (weird backlight levels) by removing the wrong bit shift for
computing the current backlight level.
Also, including typo fixes (lpbc - lbpc).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=34524
Acked-by: Indan Zupancic in...@nul.nu
Cc: sta...@kernel.org
Signed-off-by: Takashi Iwai ti...@suse.de
---
drivers/gpu/drm/i915/i915_reg.h| 10 ++
drivers/gpu/drm/i915/intel_panel.c | 36
2 files changed, 46 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 3e6f486..2abe240 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1553,7 +1553,17 @@
/* Backlight control */
#define BLC_PWM_CTL 0x61254
+#define BACKLIGHT_MODULATION_FREQ_SHIFT(17)
This one isn't used anywhere.
#define BLC_PWM_CTL2 0x61250 /* 965+ only */
+#define BLM_COMBINATION_MODE (1 30)
+/*
+ * This is the most significant 15 bits of the number of backlight cycles in
a
+ * complete cycle of the modulated backlight control.
+ *
+ * The actual value is this field multiplied by two.
+ */
+#define BACKLIGHT_MODULATION_FREQ_MASK (0x7fff 17)
This one isn't used and the comment is misleading, I think.
+#define BLM_LEGACY_MODE(1 16)
/*
* This is the number of cycles out of the backlight modulation cycle for
which
* the backlight is on.
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_panel.c
index d860abe..f8f86e5 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -30,6 +30,8 @@
#include intel_drv.h
+#define PCI_LBPC 0xf4 /* legacy/combination backlight modes */
+
I'd either put all the defines in i915_reg.h, or have all combination
mode specific defines here. Though I guess LBPC is an odd one.
void
intel_fixed_panel_mode(struct drm_display_mode *fixed_mode,
struct drm_display_mode *adjusted_mode)
@@ -110,6 +112,19 @@ done:
dev_priv-pch_pf_size = (width 16) | height;
}
+static int is_backlight_combination_mode(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+
+ if (INTEL_INFO(dev)-gen = 4)
+ return I915_READ(BLC_PWM_CTL2) BLM_COMBINATION_MODE;
+
+ if (IS_GEN2(dev))
+ return I915_READ(BLC_PWM_CTL) BLM_LEGACY_MODE;
+
+ return 0;
+}
+
static u32 i915_read_blc_pwm_ctl(struct drm_i915_private *dev_priv)
{
u32 val;
@@ -166,6 +181,9 @@ u32 intel_panel_get_max_backlight(struct drm_device *dev)
if (INTEL_INFO(dev)-gen 4)
max = ~1;
I'd add a comment that this is to clear the BLM_LEGACY_MODE bit.
}
+
+ if (is_backlight_combination_mode(dev))
+ max *= 0xff;
}
DRM_DEBUG_DRIVER(max backlight PWM = %d\n, max);
@@ -183,6 +201,14 @@ u32 intel_panel_get_backlight(struct drm_device *dev)
val = I915_READ(BLC_PWM_CTL) BACKLIGHT_DUTY_CYCLE_MASK;
if (IS_PINEVIEW(dev))
val = 1;
+
+ if (is_backlight_combination_mode(dev)){
+ u8 lbpc;
+
+ val = ~1;
+ pci_read_config_byte(dev-pdev, PCI_LBPC, lbpc);
+ val *= lbpc;
+ }
}
DRM_DEBUG_DRIVER(get backlight PWM = %d\n, val);
@@ -205,6 +231,16 @@ void intel_panel_set_backlight(struct drm_device *dev,
u32 level)
if (HAS_PCH_SPLIT(dev))
return intel_pch_panel_set_backlight(dev, level);
+
+ if (is_backlight_combination_mode(dev)){
+ u32 max = intel_panel_get_max_backlight(dev);
+ u8 lbpc;
+
+ lbpc = level * 0xfe / max + 1;
+ level /= lbpc;
+ pci_write_config_byte(dev-pdev,
Re: [PATCH] drm/i915: Revive combination mode for backlight control
On Thu, Mar 10, 2011 at 5:23 PM, Indan Zupancic in...@nul.nu wrote: After this patch, combined with my new patch drm/i915: Fix DPMS and suspend interaction for intel_panel.c all known backlight problems should be fixed. Btw, can you repost that one as a new email (and cc keithp too)? I think it got hidden in the other thread by different subject line. Jesse, did you take a look at that one? It was in the thread with a subject like [PATCH] fix backlight brightness on intel LVDS panel after reopening lid. Search for When suspending intel_panel_disable_backlight() is never called, but intel_panel_enable_backlight() is called at resume. With the effect that if the brightness was ever changed after screen blanking, the wrong brightness gets restored at resume time. in your mailbox. Linus ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915: Revive combination mode for backlight control
On Thu, March 10, 2011 20:36, Keith Packard wrote: On Thu, 10 Mar 2011 14:02:12 +0100, Takashi Iwai ti...@suse.de wrote: +val = ~1; The reason for this is that some ancient platforms wire this bit to be go to max backlight, or at least that's why this was in the 2D driver from which this code was derived. If that is the case, then shouldn't it be at the end, after val *= lbpc? I know it doesn't make much difference, as multiplying with an even number always gives an even result, but it would make the intention clearer and give a more precise result. What about gen 3? Does it support combination mode too? If you can confirm that there are no gen 2 systems with ASLE support, we can remove the gen 2 check and only touch the PWM register, as the ASLE code is the only one that changes the brightness. The panel code only saves and restores it, and LBPC is saved and restored by the BIOS already. Then those weird gen 2 quirks can be removed. (Something for 2.6.39 perhaps.) It's sad that something as simple as backlight control needs so much code. Greetings, Indan ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
drm/i915: Fix DPMS and suspend interaction for intel_panel.c
drm/i915: Fix DPMS and suspend interaction for intel_panel.c
When suspending intel_panel_disable_backlight() is never called,
but intel_panel_enable_backlight() is called at resume. With the
effect that if the brightness was ever changed after screen
blanking, the wrong brightness gets restored at resume time.
Nothing guarantees that those calls will be balanced, so having
backlight_enabled makes no sense, as the real state can change
without the panel code noticing. So keep things as stateless as
possible.
Signed-off-by: Indan Zupancic in...@nul.nu
---
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 456f404..4a3d9ed 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -333,7 +333,6 @@ typedef struct drm_i915_private {
/* LVDS info */
int backlight_level; /* restore backlight to this value */
- bool backlight_enabled;
struct drm_display_mode *panel_fixed_mode;
struct drm_display_mode *lfp_lvds_vbt_mode; /* if any */
struct drm_display_mode *sdvo_lvds_vbt_mode; /* if any */
@@ -1220,10 +1219,6 @@ void i915_debugfs_cleanup(struct drm_minor *minor);
extern int i915_save_state(struct drm_device *dev);
extern int i915_restore_state(struct drm_device *dev);
-/* i915_suspend.c */
-extern int i915_save_state(struct drm_device *dev);
-extern int i915_restore_state(struct drm_device *dev);
-
/* intel_i2c.c */
extern int intel_setup_gmbus(struct drm_device *dev);
extern void intel_teardown_gmbus(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 49fb54f..1b5a32d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5924,8 +5924,6 @@ static void intel_setup_outputs(struct drm_device *dev)
encoder-base.possible_clones =
intel_encoder_clones(dev, encoder-clone_mask);
}
-
- intel_panel_setup_backlight(dev);
}
static void intel_user_framebuffer_destroy(struct drm_framebuffer *fb)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 2c43104..70e8b82 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -257,7 +257,6 @@ extern void intel_pch_panel_fitting(struct drm_device *dev,
extern u32 intel_panel_get_max_backlight(struct drm_device *dev);
extern u32 intel_panel_get_backlight(struct drm_device *dev);
extern void intel_panel_set_backlight(struct drm_device *dev, u32 level);
-extern void intel_panel_setup_backlight(struct drm_device *dev);
extern void intel_panel_enable_backlight(struct drm_device *dev);
extern void intel_panel_disable_backlight(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_panel.c
index d860abe..b05631a 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -217,12 +255,11 @@ void intel_panel_set_backlight(struct drm_device *dev,
u32 level)
void intel_panel_disable_backlight(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
+ u32 level = intel_panel_get_backlight(dev);
- if (dev_priv-backlight_enabled) {
- dev_priv-backlight_level = intel_panel_get_backlight(dev);
- dev_priv-backlight_enabled = false;
- }
-
+ if (level == 0)
+ return;
+ dev_priv-backlight_level = level;
intel_panel_set_backlight(dev, 0);
}
@@ -230,17 +267,9 @@ void intel_panel_enable_backlight(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
+ if (intel_panel_get_backlight(dev))
+ return;
if (dev_priv-backlight_level == 0)
dev_priv-backlight_level = intel_panel_get_max_backlight(dev);
-
intel_panel_set_backlight(dev, dev_priv-backlight_level);
- dev_priv-backlight_enabled = true;
-}
-
-void intel_panel_setup_backlight(struct drm_device *dev)
-{
- struct drm_i915_private *dev_priv = dev-dev_private;
-
- dev_priv-backlight_level = intel_panel_get_backlight(dev);
- dev_priv-backlight_enabled = dev_priv-backlight_level != 0;
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 32945] [RADEON:KMS:R300G] HiZ: Weird behavior with 3 pipes
https://bugs.freedesktop.org/show_bug.cgi?id=32945 --- Comment #24 from Marek Olšák mar...@gmail.com 2011-03-10 19:40:15 PST --- (In reply to comment #23) Created an attachment (id=44333) View: https://bugs.freedesktop.org/attachment.cgi?id=44333 Review: https://bugs.freedesktop.org/review?bug=32945attachment=44333 Possible fix The attached patch fixes the issue with shadowtex for me. Sven, can you try it and also see if doom3 is still OK with it ? With 3 pipes values are NPOT, so align() is not suitable in some places I think. Pushed, thanks a lot! -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[git pull] drm single fix
Hi Linus, Fixes an oops caused by the intersection of two new features being empty. The following changes since commit 9179746652faf0aba07b8b7f770dcf29892a24c6: Merge branch 'media_fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6 (2011-03-10 13:22:10 -0800) are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-fixes Dave Airlie (1): drm/radeon: add pageflip hooks for fusion drivers/gpu/drm/radeon/radeon_asic.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 35194] New: [r600g] Evergreen - failed to map bo
https://bugs.freedesktop.org/show_bug.cgi?id=35194 Summary: [r600g] Evergreen - failed to map bo Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: rubenf3...@gmail.com Created an attachment (id=44337) -- (https://bugs.freedesktop.org/attachment.cgi?id=44337) output generated with MESA_GLSL=dump The game Back to the Future: the game crashes at many points with the message: radeon_bo_fixed_map failed to map bo EE radeon_bo.c:120 radeon_bo - failed to map bo It usually happens at random moments, altough there are specific actions that trigger the crash reliably. It works correctly using llvmpipe. The failed to map message originates in the function radeon_bo_fixed_map in mesa/src/gallium/winsys/r600/drm/radeon_bo.c, when doing a call to mmap; upon debugging, I found it fails with ENOMEM, despite having more than enough free RAM available at the time (it only allocates half a megabyte, and I had almost 1GB of free RAM at the moment of crashing) Upon further inspection, I found that, at the moment of the crash, the game had almost exactly 1 gigabyte of buffer objects mmap'd; could it have something to do with my card having 1GB of video RAM? seems unlikely, since mmap maps to system memory. Graphics Card: ATI Technologies Inc Juniper [Radeon HD 5750 Series] CPU: Intel Core Duo 1.8 Ghz, 2.5 GB RAM Linux kernel 2.6.37, libdrm 2.4.24 Latest Mesa git -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm/i915: Fix DPMS and suspend interaction for intel_panel.c
[Removed stable-kernel from Cc] At Fri, 11 Mar 2011 02:35:45 +0100 (CET), Indan Zupancic wrote: drm/i915: Fix DPMS and suspend interaction for intel_panel.c When suspending intel_panel_disable_backlight() is never called, but intel_panel_enable_backlight() is called at resume. With the effect that if the brightness was ever changed after screen blanking, the wrong brightness gets restored at resume time. Nothing guarantees that those calls will be balanced, so having backlight_enabled makes no sense, as the real state can change without the panel code noticing. So keep things as stateless as possible. Signed-off-by: Indan Zupancic in...@nul.nu Indan, when you need a patch to be added to stable kernel, just put Cc to stable kernel around your sign-off line. Then Greg will pick it up automatically once when the patch is merged to Linus tree. Anyway, the patch looks good to me. A nice clean-up. Reviewed-by: Takashi Iwai ti...@suse.de thanks, Takashi ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915: Revive combination mode for backlight control
On Fri, 11 Mar 2011 02:23:08 +0100 (CET), Indan Zupancic in...@nul.nu wrote: Some nitpicks below. I know you're just restoring the original code, but if we improve it we can as well do it now. Let's pend these changes until after 2.6.38; the backlight code is fragile enough without trying to 'clean it up' at this point in the release cycle. -- keith.pack...@intel.com pgp2x3VpOBcHF.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
