[Bug 35051] [RADEON:KMS:R600G] wine Counter Strike Source Crashes at Startup
https://bugs.freedesktop.org/show_bug.cgi?id=35051 --- Comment #7 from Brian Paterni 2011-03-11 17:59:30 PST --- (In reply to comment #1) > The "Inconsistency detected by ld.so: ..." line in > the log looks suspicious, although it's unclear to me if it's related to the > cause of the crash. I wonder if that line has something to do with the libc6 (2.13-0exp3) I have installed from Debian's experimental repos... > Normally when source engine games crash they write a > minidump in "dumps" in your Steam directory, you can open those with winedbg > to > get a backtrace. The dbghelp FIXME and ld.so message make me suspect it might > have failed to produce a usable minidump this time though. I believe you are correct, Steam is writing minidumps in dumps/, but winedbg doesn't appear to be of any help. Though 'bt' does report "Exception c005" if that is of any significance? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[ANNOUNCE] cpupowerutils - cpufrequtils extended with quite some features
On Fri, Mar 11, 2011 at 11:46 AM, Thomas Renninger wrote: > Why is there need for another tool? > --- > > CPU power consumption vs performance tuning is not about > CPU frequency switching anymore for quite some time. > Deep sleep states, traditional dynamic frequency scaling and > hidden turbo/boost frequencies are tight close together and > depend on each other. The first two exist on different architectures > like PPC, Itanium and ARM the latter only on X86. > On X86 the APU (CPU+GPU) will only run most efficiently if CPU > and GPU has proper power management in place. > > Users and Developers want to have *one* tool to get an overview what their > system supports and to monitor and debug CPU power management in detail. > > The tool should compile and work on as much architectures as > possible. > Hi Thomas, Do you think handling really vendor specific "boosts" like EeePC's SHE is in cpupower scope ? Still, it would not solve the issue of setting SHE mode in a standard way, or associating it with a governor. Thanks, -- Corentin Chary http://xf.iksaif.net
[Bug 35045] BUG at ttm_bo.c:272! (ttm_bo_ref_bug -> ttm_bo_list_ref_sub+0x28/0x30)
https://bugs.freedesktop.org/show_bug.cgi?id=35045 --- Comment #2 from Kevin DeKorte 2011-03-11 15:39:30 PST --- Created an attachment (id=44375) --> (https://bugs.freedesktop.org/attachment.cgi?id=44375) Screen shot of crash on display -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 35045] BUG at ttm_bo.c:272! (ttm_bo_ref_bug -> ttm_bo_list_ref_sub+0x28/0x30)
https://bugs.freedesktop.org/show_bug.cgi?id=35045 --- Comment #1 from Kevin DeKorte 2011-03-11 15:37:01 PST --- Similar crash in gnome using git versions of D-R-T, drm, mesa and DDX as of 3/11/2011. Screen shot attached. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 30922] New: [radeon] Noisy fan with Radeon R600 and Toshiba Satellite L500-164
https://bugzilla.kernel.org/show_bug.cgi?id=30922 Summary: [radeon] Noisy fan with Radeon R600 and Toshiba Satellite L500-164 Product: Drivers Version: 2.5 Kernel Version: 2.6.38-rc8 (at least since 2.6.35) Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) AssignedTo: drivers_video-dri at kernel-bugs.osdl.org ReportedBy: denisw at online.de Regression: No When I use my Toshiba Satellite L500-164 laptop (AMD/ATI Radeon HD 4650) with the radeon KMS driver, the GPU fan spins up very quickly (and loudly) after booting and makes no attempt at spinning down subsequently (I need to fully reboot for this to happen). The resulting noise makes the driver unusable for me currently, which is unfortunate as it works perfectly otherwise. I have tested this with every kernel version since I have this laptop, that is, 2.6.35, 2.6.36, 2.6.37 (different distributions each), and 2.6.38-rc8 mainline. I don't know if it is helpful in any way, but I have looked to see if the machine has any external thermal sensors attached to the GPU (using lm_sensors and by looking into sysfs), but only the Intel Core sensors (coretemp) have been found. I assume that means that the GPU has an internal thermal sensor, but I don't know. With the propietary fglrx driver, fan speed control works just fine. If you need any further information, just ask. -- 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 35226] New: [regression] build failure in git/master: r600_dri.so.tmp: undefined reference to `_mesa_rgba_logicop_enabled'
https://bugs.freedesktop.org/show_bug.cgi?id=35226 Summary: [regression] build failure in git/master: r600_dri.so.tmp: undefined reference to `_mesa_rgba_logicop_enabled' Product: Mesa Version: git Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: critical Priority: medium Component: Drivers/DRI/R600 AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: David.Ronis at McGill.CA I ran make distclean, pulled the git/master, ran autogen.sh, configure and make. The build dies with: mklib: Making Linux shared library: r600_dri.so.tmp /usr/bin/g++ -march=native -msse2 -mfpmath=sse -O3 -ffast-math -funroll-loops -fomit-frame-pointer -floop-interchange -floop-strip-mine -floop-block -Wall -Wmissing-prototypes -std=c99 -ffast-math -fno-strict-aliasing -fPIC -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -fvisibility=hidden -DHAVE_LIBDRM_RADEON=1 -I/usr/include/libdrm -DFEATURE_GL=1 -o r600_dri.so.test ../../../../../src/mesa/drivers/dri/common/dri_test.o r600_dri.so.tmp ../../../../../src/mesa/libmesa.a -ldrm -lexpat -lm -lpthread -ldl -ldrm_radeon r600_dri.so.tmp: undefined reference to `_mesa_rgba_logicop_enabled' collect2: ld returned 1 exit status -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[ANNOUNCE] cpupowerutils - cpufrequtils extended with quite some features
Hi, cpupowerutils is based on the well known cpufrequtils project. Where do I find it? --- A git repository is hosted on gitorious: git://gitorious.org/cpupowerutils/cpupowerutils.git Be careful, it's not the default, but the cpupowerutils branch! You can also directly download a tarball of the cpupowerutils branch: wget http://gitorious.org/cpupowerutils/cpupowerutils/archive- tarball/cpupowerutils cpupowerutils.tar.gz How to make it run -- You need the pcitutils package (or whatever provides libpci) at runtime and pcitutils-devel package (or whatever provides /usr/include/pci/pci.h) at compile time. Also a gcc version that provides cpuid.h is needed, but it's in there for some time already afaik. Don't forget to use the right branch if you use the git repo: git branch --track cpupowerutils origin/cpupowerutils git checkout cpupowerutils make # There is nothing for choosing lib vs lib64, default is # /usr/lib,therefore you might need: libdir=/usr/lib64 make install-lib ldconfig ./cpupower There is one known compile warning in get_cpu_topology, it's on the ToDo list. Why is there need for another tool? --- CPU power consumption vs performance tuning is not about CPU frequency switching anymore for quite some time. Deep sleep states, traditional dynamic frequency scaling and hidden turbo/boost frequencies are tight close together and depend on each other. The first two exist on different architectures like PPC, Itanium and ARM the latter only on X86. On X86 the APU (CPU+GPU) will only run most efficiently if CPU and GPU has proper power management in place. Users and Developers want to have *one* tool to get an overview what their system supports and to monitor and debug CPU power management in detail. The tool should compile and work on as much architectures as possible. What is this tool doing? It provides all features cpufrequtils does. It got enhanced with cpuidle and turbo/boost mode (on X86) statistics. On AMD the exact amount of supported boost states and their frequencies are shown. On Intel only turbo/boost support is shown. It got enhanced with a generic HW monitor tool (cpupower monitor). The generic HW monitor tool is the most powerful enhancement. It is a framework to monitor kernel or HW power statistics. It's easy to extend with additional, architecture or processor model specific counters. It's based on turbostat which got merged into the kernel recently: tools/power/x86/turbostat In fact turbostat functionality is integrated as three separate monitors implementing the cpupower monitor API: - Nehalem - SandyBridge - Mperf While Nehalem and SandyBridge HW sleep counters are Intel specific, the mperf functionality is now available on other HW than Intel, supporting the needed registers (Functionality includes: average frequency including turbo/boost frequency, C0 vs Cx idle count). Additionally there is a monitor to collect kernel idle statistics and display them (separate or together) in the same format. This works on all architectures using the cpuidle kernel framework including different ARM architectures and there were patches for powerpc (not in the mainline kernel yet). This allows to compare kernel and HW statistics on specific workloads and figure out how the HW performs compared to OS behavior. Additionally there is an AMD Liano (fam 12h) and Ontario (fam 14h) family specific monitor. This one shows different Package Core (!PC0, PC1, PC7) sleep state statistics directly read out from HW, similar to Nehalem and SandyBridge coutners. The registers are accessed via PCI and therefore can still be read out while cores have been offlined. The Liano/Ontario monitor has one special counter: NBP1 (North Bridge P1). This one always returns 0 or 1, depending on whether the North Bridge P1 power state got entered at least once during measure time. Being able to enter NBP1 state also depends on graphics power management. Therefore this counter can be used to verify whether the graphics' driver power management is working as expected. (E.g. this counter proves that radeon KMS graphics drivers are missing functionality and NBP1 will only be entered when using the fglrx driver). Some examples - On a somewhat older Intel machine where turbostat complaints about: /archteam/trenn/packages/turbostat/turbostat No invariant TSC You still get mperf statistics (here core 1 is 100% utilized): /archteam/trenn/git/latest_cpupowerutils/cpufrequtils/cpupower monitor |Mperf || Idle_Stats CPU | C0 | Cx | Freq || POLL | C1 | C2 | C3 0| 3.71| 96.29| 2833|| 0.00| 0.00| 0.02| 96.32 1| 100.0| -0.00| 2833|| 0.00| 0.00| 0.00| 0.00 2| 9.06| 90.94| 1983|| 0.00| 7.69| 6.98| 76.45 3| 7.43| 92.57| 2039|| 0.00| 2.60| 12.62| 77.52 Hm, mperf (C0 vs Cx) implementation also depends on a correct working TSC, but shows
[Bug 32945] [RADEON:KMS:R300G] HiZ: Weird behavior with 3 pipes
https://bugs.freedesktop.org/show_bug.cgi?id=32945 Marek Ol??k changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #26 from Marek Ol??k 2011-03-11 11:33:40 PST --- (In reply to comment #25) > Cool! This does indeed fix things! Alright, closing. -- 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
On Fri, Mar 11, 2011 at 02:08:46AM +0100, Indan Zupancic wrote: > On Thu, March 10, 2011 14:31, Daniel Vetter wrote: > > Am Do, 10.03.2011, 11:36 schrieb Indan Zupancic: > >> Which versions fix this, just for reference? > > > > git master branch of libdrm and xf86-video-intel newer than 2011-02-22. > > Thank you. If there will be no new releases of those packages within > a couple weeks it might be better to temporarily add those checks back > for gen 2 only, I think. Otherwise there will be a period where people > who update regularly will have screen corruption, with no easy way of > fixing it. I think this would avoid a few unnecessary bugreports. The > check can be removed in 2.6.39-rc1, if you want I'll remind you about > it too. Well, libdrm is already released (2.4.24) and for the ddx there's an rc (2.4.901) out there. So that should be sufficient. -Daniel -- Daniel Vetter Mail: daniel at ffwll.ch Mobile: +41 (0)79 365 57 48
[PATCH] drm/i915: Revive combination mode for backlight control
On Fri, March 11, 2011 08:26, Takashi Iwai wrote: > At Fri, 11 Mar 2011 02:23:08 +0100 (CET), > Indan Zupancic wrote: >> >> 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. > > Well, Linus already merged my patch quickly. So, we can improve the > readability as an additional patch, but I think it's likely a 2.6.39 > material. > > All you comments below look reasonable. Could you send a new patch? Well, my main concern was the slightly incorrect commit message, but oh well, too late for that now. I'll probably send a patch after 2.6.38 is released. Greetings, Indan
drm/i915: Fix DPMS and suspend interaction for intel_panel.c
On Fri, March 11, 2011 09:07, Chris Wilson wrote: >> 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. > > The problem is wider than described since the BIOS/ACPI may modify > the registers without notifying the driver, and we fail to honour > any user requests whilst the panel is off. Also, there is the greater > of problem that the PWM registers simply have no effect on many > machines, and we need to make an ACPI call to adjust the backlight. Actually, that makes more sense than what ASLE does: There you have to make an ACPI call which generates the ASLE interrupt and lets the driver change it, while the BIOS already knows how to change the backlight, as it does it at boot. Is the PWM totally ignored, or only when non-zero? Otherwise you may need to clear bit 31 in BLC_PWM_CLT2 instead. That might be a better way to enable/disable the backlight for gen >= 4 hardware anyway, as you don't need to store the current backlight anymore. But this is 2.6.39 material for sure. > However, this behaviour has been there since the inception, we can > wait until the next merge cycle. I think it was introduced in 2.6.37, at least that when the backlight problems started for me. In my opinion this is a patch that fixes a bug by making the code simpler, so I would merge it this cycle. I am uncertain whether this bug is important enough to get fixed in stable too though. Maybe once it has proven itself in 2.6.38 for a while. If you want to fix it the next cycle then that's fine too, but only delays things. I think at this point the backlight problems are known well enough that the fix is obvious and low risk enough, but I've sent too hasty patches before. Greetings, Indan
drm/i915: Fix DPMS and suspend interaction for intel_panel.c
On Fri, March 11, 2011 08:23, Takashi Iwai wrote: > [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 > > 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. Ah, okay. I'll do that in the future. Reading through Documentation/stable_kernel_rules.txt I'm not sure if this patch applies. It does fix a bug that bothers me personally, but otherwise it's not very important. > Anyway, the patch looks good to me. A nice clean-up. That was a nice side effect. I like it when fixing code makes it cleaner. Unfortunately it didn't work for the LBPC thing, but here it does. My combination removal patch hid this bug accidentally because PWM was kept at max, it was the main reason I thought something was horribly wrong with the LBPC fiddling. But it was just improper state tracking, fixed by this patch, and my combination removal patch was bogus. Oh well. > Reviewed-by: Takashi Iwai > > > thanks, > > Takashi > Greetings, Indan
drm/i915: Fix DPMS and suspend interaction for intel_panel.c
On 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
Chris is right that we don't always control the backlight brightness
directly, so we'll want a more complete solution at any rate.
I don't think this one is urgent enough to send upstream now, and it
would be good to make a couple of other fixes as well, while you're
fixing things up. :) Comments below.
> -/* i915_suspend.c */
> -extern int i915_save_state(struct drm_device *dev);
> -extern int i915_restore_state(struct drm_device *dev);
> -
Looks like a spurious cleanup hunk, should be a separate hunk (possibly
along with other save/restore state cleanups, like removing all the
ILK+ code that probably won't work well :).
> -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;
> }
This is getting pretty messy. Your patch is a step in the right
direction, but I think we may as well go further:
- suspend/resume of backlight state belongs in the backlight class
driver
- that driver should call into the registered i915 backlight handler
if i915 is controlling it natively (PWM native, combo, legacy)
- we need a backlight driver struct with function pointers for the
various calls, so we can split out the PCH functions from the rest;
might be good to separate native, combo, and legacy that way as
well; even if results in some code duplication it might make each
easier to read and less likely to break others when we make changes
Any thoughts about that? I think Chris and Matthew have been talking
about it as well, so I'd be curious what our backlight final solution
ought to be.
Thanks,
Jesse
[Bug 25709] [DRI1 & DRI2] sauerbraten: broken water rendering
On 10 March 2011 19:57, wrote: > 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. BTW, then r300c should be patched to warn about this in Xorg.*.log... My 2 cents
[Bug 33648] Black line in Lightsmark with Z compression enabled (RV530)
https://bugs.freedesktop.org/show_bug.cgi?id=33648 --- Comment #5 from Sven Arvidsson 2011-03-11 08:50:41 PST --- Created an attachment (id=44363) --> (https://bugs.freedesktop.org/attachment.cgi?id=44363) Lightsmark with upper part of the screen corrupt RV570 here, and Lightsmark seems to be the last app with hyper z. The upper part of the screen is corrupt when hz is enabled. When RADEON_DEBUG=nozmask is used, the problem almost goes away, there's still some corruption in the upper right corner though. With RADEON_DEBUG=nohiz I'm only getting the black line you guys described. -- 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 #25 from Sven Arvidsson 2011-03-11 08:47:47 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. Cool! This does indeed fix things! The only remaining app with HiZ problems here is Lightsmark, but it seems to be a general problem tracked in bug 33648. -- 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
At Fri, 11 Mar 2011 02:23:08 +0100 (CET),
Indan Zupancic wrote:
>
> 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.
Well, Linus already merged my patch quickly. So, we can improve the
readability as an additional patch, but I think it's likely a 2.6.39
material.
All you comments below look reasonable. Could you send a new patch?
thanks,
Takashi
> 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
> > 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)
>
> 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;
> > +
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 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 thanks, Takashi
drm/i915: Fix DPMS and suspend interaction for intel_panel.c
On 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. The problem is wider than described since the BIOS/ACPI may modify the registers without notifying the driver, and we fail to honour any user requests whilst the panel is off. Also, there is the greater of problem that the PWM registers simply have no effect on many machines, and we need to make an ACPI call to adjust the backlight. However, this behaviour has been there since the inception, we can wait until the next merge cycle. -Chris -- Chris Wilson, Intel Open Source Technology Centre
[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(-)
[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 #2 from Chi-Thanh Christopher Nguyen 2011-03-11 04:26:36 PST --- Yes, thank you. With the patch the problem is fixed. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 35183] system freezes with 2.6.38-rc kernel and kms pageflip enabled
https://bugs.freedesktop.org/show_bug.cgi?id=35183 --- Comment #2 from Dave Airlie 2011-03-11 03:14:56 PST --- Created an attachment (id=44345) View: https://bugs.freedesktop.org/attachment.cgi?id=44345 Review: https://bugs.freedesktop.org/review?bug=35183=44345 initial minimal patch to fix hangs. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 35183] system freezes with 2.6.38-rc kernel and kms pageflip enabled
https://bugs.freedesktop.org/show_bug.cgi?id=35183 --- Comment #1 from Dave Airlie 2011-03-11 03:10:42 PST --- I've debugged this and I'm hoping I have a fix, hopefully I can get a cleaned up patch in 5mins - tomorrow. (this is mainly to stop anyone else getting into this) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
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
---
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] 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 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
[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
> 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_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, );
> + 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 =
[PATCH] drm/i915: fix corruptions on i8xx due to relaxed fencing
On Thu, March 10, 2011 14:31, Daniel Vetter wrote: > Am Do, 10.03.2011, 11:36 schrieb Indan Zupancic: >> Which versions fix this, just for reference? > > git master branch of libdrm and xf86-video-intel newer than 2011-02-22. Thank you. If there will be no new releases of those packages within a couple weeks it might be better to temporarily add those checks back for gen 2 only, I think. Otherwise there will be a period where people who update regularly will have screen corruption, with no easy way of fixing it. I think this would avoid a few unnecessary bugreports. The check can be removed in 2.6.39-rc1, if you want I'll remind you about it too. Greetings, Indan
[Bug 32688] [RADEON:KMS:R300G] some games have a wireframe or outline visible
https://bugs.freedesktop.org/show_bug.cgi?id=32688 --- Comment #3 from Fabio Pedretti 2011-03-11 00:29:49 PST --- I have a similar problem with sauerbraten on my RV530, with both r300 and r300g, see also bug #25710. -- 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 #3 from Fabio Pedretti 2011-03-11 00:24:13 PST --- Note that the same problem also affects r300g but I think this is already reported as bug #32688. -- 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 #3 from Fabio Pedretti fabio@libero.it 2011-03-11 00:24:13 PST --- Note that the same problem also affects r300g but I think this is already reported as bug #32688. -- 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 32688] [RADEON:KMS:R300G] some games have a wireframe or outline visible
https://bugs.freedesktop.org/show_bug.cgi?id=32688 --- Comment #3 from Fabio Pedretti fabio@libero.it 2011-03-11 00:29:49 PST --- I have a similar problem with sauerbraten on my RV530, with both r300 and r300g, see also bug #25710. -- 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
On Fri, March 11, 2011 08:23, Takashi Iwai wrote: [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. Ah, okay. I'll do that in the future. Reading through Documentation/stable_kernel_rules.txt I'm not sure if this patch applies. It does fix a bug that bothers me personally, but otherwise it's not very important. Anyway, the patch looks good to me. A nice clean-up. That was a nice side effect. I like it when fixing code makes it cleaner. Unfortunately it didn't work for the LBPC thing, but here it does. My combination removal patch hid this bug accidentally because PWM was kept at max, it was the main reason I thought something was horribly wrong with the LBPC fiddling. But it was just improper state tracking, fixed by this patch, and my combination removal patch was bogus. Oh well. Reviewed-by: Takashi Iwai ti...@suse.de thanks, Takashi Greetings, Indan ___ 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
On Fri, March 11, 2011 09:07, Chris Wilson wrote: 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. The problem is wider than described since the BIOS/ACPI may modify the registers without notifying the driver, and we fail to honour any user requests whilst the panel is off. Also, there is the greater of problem that the PWM registers simply have no effect on many machines, and we need to make an ACPI call to adjust the backlight. Actually, that makes more sense than what ASLE does: There you have to make an ACPI call which generates the ASLE interrupt and lets the driver change it, while the BIOS already knows how to change the backlight, as it does it at boot. Is the PWM totally ignored, or only when non-zero? Otherwise you may need to clear bit 31 in BLC_PWM_CLT2 instead. That might be a better way to enable/disable the backlight for gen = 4 hardware anyway, as you don't need to store the current backlight anymore. But this is 2.6.39 material for sure. However, this behaviour has been there since the inception, we can wait until the next merge cycle. I think it was introduced in 2.6.37, at least that when the backlight problems started for me. In my opinion this is a patch that fixes a bug by making the code simpler, so I would merge it this cycle. I am uncertain whether this bug is important enough to get fixed in stable too though. Maybe once it has proven itself in 2.6.38 for a while. If you want to fix it the next cycle then that's fine too, but only delays things. I think at this point the backlight problems are known well enough that the fix is obvious and low risk enough, but I've sent too hasty patches before. Greetings, Indan ___ 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, March 11, 2011 08:26, Takashi Iwai wrote: At Fri, 11 Mar 2011 02:23:08 +0100 (CET), Indan Zupancic wrote: 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. Well, Linus already merged my patch quickly. So, we can improve the readability as an additional patch, but I think it's likely a 2.6.39 material. All you comments below look reasonable. Could you send a new patch? Well, my main concern was the slightly incorrect commit message, but oh well, too late for that now. I'll probably send a patch after 2.6.38 is released. Greetings, Indan ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 35183] system freezes with 2.6.38-rc kernel and kms pageflip enabled
https://bugs.freedesktop.org/show_bug.cgi?id=35183 --- Comment #1 from Dave Airlie airl...@freedesktop.org 2011-03-11 03:10:42 PST --- I've debugged this and I'm hoping I have a fix, hopefully I can get a cleaned up patch in 5mins - tomorrow. (this is mainly to stop anyone else getting into this) -- 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 #2 from Chi-Thanh Christopher Nguyen chith...@gentoo.org 2011-03-11 04:26:36 PST --- Yes, thank you. With the patch the problem is fixed. -- 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 30922] New: [radeon] Noisy fan with Radeon R600 and Toshiba Satellite L500-164
https://bugzilla.kernel.org/show_bug.cgi?id=30922 Summary: [radeon] Noisy fan with Radeon R600 and Toshiba Satellite L500-164 Product: Drivers Version: 2.5 Kernel Version: 2.6.38-rc8 (at least since 2.6.35) Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) AssignedTo: drivers_video-...@kernel-bugs.osdl.org ReportedBy: den...@online.de Regression: No When I use my Toshiba Satellite L500-164 laptop (AMD/ATI Radeon HD 4650) with the radeon KMS driver, the GPU fan spins up very quickly (and loudly) after booting and makes no attempt at spinning down subsequently (I need to fully reboot for this to happen). The resulting noise makes the driver unusable for me currently, which is unfortunate as it works perfectly otherwise. I have tested this with every kernel version since I have this laptop, that is, 2.6.35, 2.6.36, 2.6.37 (different distributions each), and 2.6.38-rc8 mainline. I don't know if it is helpful in any way, but I have looked to see if the machine has any external thermal sensors attached to the GPU (using lm_sensors and by looking into sysfs), but only the Intel Core sensors (coretemp) have been found. I assume that means that the GPU has an internal thermal sensor, but I don't know. With the propietary fglrx driver, fan speed control works just fine. If you need any further information, just ask. -- 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 32945] [RADEON:KMS:R300G] HiZ: Weird behavior with 3 pipes
https://bugs.freedesktop.org/show_bug.cgi?id=32945 --- Comment #25 from Sven Arvidsson s...@whiz.se 2011-03-11 08:47:47 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. Cool! This does indeed fix things! The only remaining app with HiZ problems here is Lightsmark, but it seems to be a general problem tracked in bug 33648. -- 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 33648] Black line in Lightsmark with Z compression enabled (RV530)
https://bugs.freedesktop.org/show_bug.cgi?id=33648 --- Comment #5 from Sven Arvidsson s...@whiz.se 2011-03-11 08:50:41 PST --- Created an attachment (id=44363) -- (https://bugs.freedesktop.org/attachment.cgi?id=44363) Lightsmark with upper part of the screen corrupt RV570 here, and Lightsmark seems to be the last app with hyper z. The upper part of the screen is corrupt when hz is enabled. When RADEON_DEBUG=nozmask is used, the problem almost goes away, there's still some corruption in the upper right corner though. With RADEON_DEBUG=nohiz I'm only getting the black line you guys described. -- 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
On Fri, 11 Mar 2011 02:35:45 +0100 (CET)
Indan Zupancic in...@nul.nu 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
Chris is right that we don't always control the backlight brightness
directly, so we'll want a more complete solution at any rate.
I don't think this one is urgent enough to send upstream now, and it
would be good to make a couple of other fixes as well, while you're
fixing things up. :) Comments below.
-/* i915_suspend.c */
-extern int i915_save_state(struct drm_device *dev);
-extern int i915_restore_state(struct drm_device *dev);
-
Looks like a spurious cleanup hunk, should be a separate hunk (possibly
along with other save/restore state cleanups, like removing all the
ILK+ code that probably won't work well :).
-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;
}
This is getting pretty messy. Your patch is a step in the right
direction, but I think we may as well go further:
- suspend/resume of backlight state belongs in the backlight class
driver
- that driver should call into the registered i915 backlight handler
if i915 is controlling it natively (PWM native, combo, legacy)
- we need a backlight driver struct with function pointers for the
various calls, so we can split out the PCH functions from the rest;
might be good to separate native, combo, and legacy that way as
well; even if results in some code duplication it might make each
easier to read and less likely to break others when we make changes
Any thoughts about that? I think Chris and Matthew have been talking
about it as well, so I'd be curious what our backlight final solution
ought to be.
Thanks,
Jesse
___
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 Marek Olšák mar...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #26 from Marek Olšák mar...@gmail.com 2011-03-11 11:33:40 PST --- (In reply to comment #25) Cool! This does indeed fix things! Alright, closing. -- 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 35226] New: [regression] build failure in git/master: r600_dri.so.tmp: undefined reference to `_mesa_rgba_logicop_enabled'
https://bugs.freedesktop.org/show_bug.cgi?id=35226 Summary: [regression] build failure in git/master: r600_dri.so.tmp: undefined reference to `_mesa_rgba_logicop_enabled' Product: Mesa Version: git Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: critical Priority: medium Component: Drivers/DRI/R600 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: david.ro...@mcgill.ca I ran make distclean, pulled the git/master, ran autogen.sh, configure and make. The build dies with: mklib: Making Linux shared library: r600_dri.so.tmp /usr/bin/g++ -march=native -msse2 -mfpmath=sse -O3 -ffast-math -funroll-loops -fomit-frame-pointer -floop-interchange -floop-strip-mine -floop-block -Wall -Wmissing-prototypes -std=c99 -ffast-math -fno-strict-aliasing -fPIC -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -fvisibility=hidden -DHAVE_LIBDRM_RADEON=1 -I/usr/include/libdrm -DFEATURE_GL=1 -o r600_dri.so.test ../../../../../src/mesa/drivers/dri/common/dri_test.o r600_dri.so.tmp ../../../../../src/mesa/libmesa.a -ldrm -lexpat -lm -lpthread -ldl -ldrm_radeon r600_dri.so.tmp: undefined reference to `_mesa_rgba_logicop_enabled' collect2: ld returned 1 exit status -- 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 35045] BUG at ttm_bo.c:272! (ttm_bo_ref_bug - ttm_bo_list_ref_sub+0x28/0x30)
https://bugs.freedesktop.org/show_bug.cgi?id=35045 --- Comment #1 from Kevin DeKorte kdeko...@yahoo.com 2011-03-11 15:37:01 PST --- Similar crash in gnome using git versions of D-R-T, drm, mesa and DDX as of 3/11/2011. Screen shot attached. -- 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 35045] BUG at ttm_bo.c:272! (ttm_bo_ref_bug - ttm_bo_list_ref_sub+0x28/0x30)
https://bugs.freedesktop.org/show_bug.cgi?id=35045 --- Comment #2 from Kevin DeKorte kdeko...@yahoo.com 2011-03-11 15:39:30 PST --- Created an attachment (id=44375) -- (https://bugs.freedesktop.org/attachment.cgi?id=44375) Screen shot of crash on display -- 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
On Fri, March 11, 2011 18:27, Jesse Barnes wrote:
On Fri, 11 Mar 2011 02:35:45 +0100 (CET)
Indan Zupancic in...@nul.nu 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
Chris is right that we don't always control the backlight brightness
directly, so we'll want a more complete solution at any rate.
Well, not having control basically means not caching any register
values, or as little as possible. For gen =4 there's the top bit
of BLC_PWM_CTL2, so the brightness handling can be cleanly separated
from the panel disabling/enabling. For older gens we need to save
the brightness and then set it to zero, as happens now.
For brightness control we only need to set the new brightness on
systems with ASLE.
I don't think this one is urgent enough to send upstream now, and it
would be good to make a couple of other fixes as well, while you're
fixing things up. :) Comments below.
It's not urgent, it's just a bugfix. I did my best to resist the
urge to do other cleanups as well, so close to the release cycle.
From my point of view it's sad that 2.6.37 was released with buggy
backlight handling, and it would be sad if it wasn't fixed in 2.6.38.
But I think this is only because I have a gen 2 and the check for
combination mode for gen 2 was added in 2.6.37, everyone else already
had the buggy backlight behaviour for ages. Without the check gen 2
works correctly because the PWM value never changes, only LBPC, and
the driver didn't touch LBPC.
-/* i915_suspend.c */
-extern int i915_save_state(struct drm_device *dev);
-extern int i915_restore_state(struct drm_device *dev);
-
Looks like a spurious cleanup hunk, should be a separate hunk (possibly
along with other save/restore state cleanups, like removing all the
ILK+ code that probably won't work well :).
Wild guess: ILK+ means Ironlake+?
But indeed, though as the duplicate declaration is in the diff context
it seemed safe enough at the time. ;-)
-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;
}
This is getting pretty messy.
That functions was added in the 2.6.38 cycle I think, in an attempt
to fix the backlight problems.
Your patch is a step in the right
direction, but I think we may as well go further:
- suspend/resume of backlight state belongs in the backlight class
driver
There is no backlight suspend/resume handling, the panel just gets
enabled at resume. The registers save/restore is done i915_suspend.c,
where it belongs. The current bugginess is not only for suspend, but
for any two DPMS on calls without a disable in between. Try
xset dpms force off
xset dpms force on
..change brightness..
xset dpms force on
I think you'll get the old brightness.
- that driver should call into the registered i915 backlight handler
if i915 is controlling it natively (PWM native, combo, legacy)
Brightness setting is only needed for ASLE, otherwise it's never set
by the driver. So in the end most complexity is only there because of
one combination: ASLE + legacy combination mode.
- we need a backlight driver struct with function pointers for the
various calls, so we can split out the PCH functions from the rest;
might be good to separate native, combo, and legacy that way as
well; even if results in some code duplication it might make each
easier to read and less likely to break others when we make changes
Problem is, are we sure that systems don't change from legacy combination
mode to BLC_PWM_CTL only? Otherwise you have to check every time.
I must admit I'm not sure what the backlight hierarchy is, but I don't
think the intel_panel.c code has much to do with it: It has nothing to
do with backlight key events and doesn't handle them. All it does is
enabling or disabling the panel for DPMS. The only thing that needs to
set the backlight is intel_opregion.c when ASLE is used, and that bit
should indeed go somewhere else.
So if I'd clean up the code, I think this is what I would try first:
Rip out all brightness control out of intel_panel.c and replace it
with a generic, minimal register saving for disabling the panel, with
all system specific info (which registers to use, masks, etc.) stored
in struct intel_device_info.
All the extra complexity comes from ASLE. As you wrote the
[Bug 35051] [RADEON:KMS:R600G] wine Counter Strike Source Crashes at Startup
https://bugs.freedesktop.org/show_bug.cgi?id=35051 --- Comment #7 from Brian Paterni bpate...@gmail.com 2011-03-11 17:59:30 PST --- (In reply to comment #1) The Inconsistency detected by ld.so: ... line in the log looks suspicious, although it's unclear to me if it's related to the cause of the crash. I wonder if that line has something to do with the libc6 (2.13-0exp3) I have installed from Debian's experimental repos... Normally when source engine games crash they write a minidump in dumps in your Steam directory, you can open those with winedbg to get a backtrace. The dbghelp FIXME and ld.so message make me suspect it might have failed to produce a usable minidump this time though. I believe you are correct, Steam is writing minidumps in dumps/, but winedbg doesn't appear to be of any help. Though 'bt' does report Exception c005 if that is of any significance? -- 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
