Another week, another -rc. This should be the last for the 37 series,
so I still expect the merge window to open early January when people
are hopefully back to working order after having eaten (and drunk) too
much.

The -rc8 release shouldn't be all that exciting. The most noticeable
is probably the fact that hopefully the "blank screen" problem with
intel graphics is fixed. But on the whole, it's all just a collection
of random fixes all over.

The diffstat doesn't look very interesting, and the appended shortlog
probably does give about as much information as you'd want.

Go wild, and ring in the new year with a new kernel.

                      Linus

---
Aaro Koskinen (1):
      gpiolib: gpio_request_one(): add missing gpio_free()

Ahmed S. Darwish (1):
      RAMOOPS: Don't overflow over non-allocated regions

Alex Deucher (7):
      drm/radeon/kms: disable ss fixed ref divide
      drm/radeon/kms: disable the r600 cb offset checker for linear surfaces
      drm/radeon/kms/evergreen: flush hdp cache when flushing gart tlb
      drm/radeon/kms: fix evergreen asic reset
      drm/radeon/kms/evergreen: reset the grbm blocks at resume and init
      drm/radeon/kms: reorder display resume to avoid problems
      drm/radeon/kms: fix bug in r600_gpu_is_lockup

Andreas Mohr (1):
      net: Add USB PID for new MOSCHIP USB ethernet controller MCS7832 variant

Andres Salomon (3):
      MAINTAINERS: update geode entry
      cs5535-gpio: don't apply errata #36 to edge detect GPIOs
      cs5535-gpio: handle GPIO regs where higher (clear) bits are set

Andrey Vagin (1):
      ipv6: delete expired route in ip6_pmtu_deliver

Arnaldo Carvalho de Melo (1):
      perf buildid-list: Fix error return for success

Arnaud Ebalard (1):
      asix: add USB ID for Logitec LAN-GTJ U2A

Axel Lin (1):
      backlight: cr_bllcd.c: fix a memory leak

Baruch Siach (1):
      [media] mx2_camera: fix pixel clock polarity configuration

Ben Hutchings (4):
      bonding/vlan: Remove ...
[ message continues ]

There's also the issue with oopsing when physically removing the battery
from the system. I have a proposed fix but no acks/nacks from ACPI guys
yet:

https://patchwork.kernel.org/patch/418751/

-- 
Regards/Gruss,
Boris.
--

[ message continues ]

The commit causing this problem has been reverted:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=cde44d1740...

Which means that the problem it attepmted to address is back.

Thanks,
Rafael
--

[ message continues ]

Right.
After discussion with Len, we agreed that the real problem is that we
should not probe/unprobe power_supply class device in
acpi_battery_update.
And we also agreed on reverting that commit for now, and rewriting the
battery driver, sometime in Q1 2011, with the problem fixed.
Sorry that I didn't update this in the mailing list.

thanks,


--

[ message continues ]

I booted -rc8 and found that my video worked for only a few seconds,
then it goes blank.  -rc7 and -rc6 do the same.  -rc5 is OK.

The only significant difference that I can see in the kernel message log
is this:

from 2.6.37-rc5:

[drm] initialized overlay support
i2c i2c-3: master_xfer[0] W, addr=0x50, len=1
i2c i2c-3: master_xfer[1] R, addr=0x50, len=1
i2c i2c-3: master_xfer[0] W, addr=0x50, len=1
i2c i2c-3: master_xfer[1] R, addr=0x50, len=128
fbcon: inteldrmfb (fb0) is primary device
Console: switching to colour frame buffer device 160x64
fb0: inteldrmfb frame buffer device
drm: registered panic notifier
[drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0

and from 2.6.37-rc6:

[drm] initialized overlay support
No connectors reported connected with modes
[drm] Cannot find any crtc or sizes - going 1024x768
fbcon: inteldrmfb (fb0) is primary device
Console: switching to colour frame buffer device 128x48
fb0: inteldrmfb frame buffer device
drm: registered panic notifier
[drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0


Full kernel boot logs are in http://www.xenotime.net/linux/logs/
(2637-rc5.notimes and 2637-rc6.notimes).

The 2.6.37-rc5 kernel config file is attached.  It is close to an
allmodconfig.

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
desserts:  http://www.xenotime.net/linux/recipes/
[ message continues ]

Hmm. I suspect that difference should have gone away with commit
92971021c6328 (Revert "drm: Don't try and disable an encoder that was
never enabled"), but clearly that didn't fix your blank screen.

Does reverting commit 448f53a1ede54eb854d036abf54573281412d650
("drm/i915/bios: Reverse order of 100/120 Mhz SSC clocks") fix it for
you? It does for some people..

Chris - why did that lvds_ssc_freq thing suddenly start mattering? Can
we please just disable spread-spectrum entirely? Or perhaps only if we
notice that it was enabled already? Or something?

                         Linus
--

[ message continues ]

On Wed, 29 Dec 2010 11:40:04 -0800

Randy, Jeff and Alex, does the below help at all?  If so, it may be the
minimal fix we want for 2.6.37.

diff --git a/drivers/gpu/drm/i915/intel_bios.c b/drivers/gpu/drm/i915/intel_bios
index 2b20786..d27d016 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -263,6 +263,9 @@ parse_general_features(struct drm_i915_private *dev_priv,
                dev_priv->int_tv_support = general->int_tv_support;
                dev_priv->int_crt_support = general->int_crt_support;
                dev_priv->lvds_use_ssc = general->enable_ssc;
+               /* force disable until we can parse this correctly */
+               if (IS_GEN5(dev) || IS_GEN6(dev))
+                       dev_priv->lvds_use_ssc = 0;
 
                if (dev_priv->lvds_use_ssc) {
                        if (IS_I85X(dev))


-- 
Jesse Barnes, Intel Open Source Technology Center
--

[ message continues ]

I also encountered the black screen problem after commit 448f53a1. I can
confirm that the above patch solves the problem.

François Valenduc
--

[ message continues ]

Doesn't change anything here. Display stays blank.
--

[ message continues ]

On Wed, 29 Dec 2010 22:11:09 +0100


No, we enabled it previously, but it apparently doesn't work on all
platforms, probably because we're either looking in the wrong place for
the bit that tells us to enable it or not, or we're getting the wrong
frequency on some platforms.  Probably both (the VBIOS guys work
closely with the Windows driver team that consumes this data, and don't

Sounds like your problem is separate from SSC then, more likely related
to panel power or backlight control.  Have you tried bisecting for the
problem between 2.6.35 and 2.6.36?

-- 
Jesse Barnes, Intel Open Source Technology Center
--

[ message continues ]

Nevermind, I just checked out the bug, looks like it is panel power
related.  Can you try this patch?

If it doesn't work, can you send me the output of intel_reg_dumper from
before you turn off the display and after you try to turn it back on?

Thanks,
-- 
Jesse Barnes, Intel Open Source Technology Center

diff --git a/drivers/gpu/drm/i915/intel_lvds.c b/drivers/gpu/drm/i915/intel_lvds.c
index aa23070..830e3b0 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -82,8 +82,6 @@ static void intel_lvds_enable(struct intel_lvds *intel_lvds)
 		lvds_reg = LVDS;
 	}
 
-	I915_WRITE(lvds_reg, I915_READ(lvds_reg) | LVDS_PORT_EN);
-
 	if (intel_lvds->pfit_dirty) {
 		/*
 		 * Enable automatic panel scaling so that non-native modes
@@ -104,7 +102,7 @@ static void intel_lvds_enable(struct intel_lvds *intel_lvds)
 	}
 
 	I915_WRITE(ctl_reg, I915_READ(ctl_reg) | POWER_TARGET_ON);
-	POSTING_READ(lvds_reg);
+	POSTING_READ(ctl_reg);
 
 	intel_panel_set_backlight(dev, dev_priv->backlight_level);
 }
@@ -136,8 +134,7 @@ static void intel_lvds_disable(struct intel_lvds *intel_lvds)
 		intel_lvds->pfit_dirty = true;
 	}
 
-	I915_WRITE(lvds_reg, I915_READ(lvds_reg) & ~LVDS_PORT_EN);
-	POSTING_READ(lvds_reg);
+	POSTING_READ(ctl_reg);
 }
 
 static void intel_lvds_dpms(struct drm_encoder *encoder, int mode)
--

[ message continues ]

See the links below (sorry, they files are a bit large):

Before running "xset dpms force standby":

  http://vin-soft.org/~raa/public/test/intel_gpu_dump-before

After running "sleep 3"

  http://vin-soft.org/~raa/public/test/intel_gpu_dump-after-suspend

After running "xset dpms force on"

  http://vin-soft.org/~raa/public/test/intel_gpu_dump-after-xset-on

After closing and opening the lid (displays backlight is back)

  http://vin-soft.org/~raa/public/test/intel_gpu_dump-after-lid
--

[ message continues ]

On Thu, 30 Dec 2010 00:09:56 +0100

I need the intel_reg_dumper output, not intel_gpu_dump. :)

-- 
Jesse Barnes, Intel Open Source Technology Center
--

[ message continues ]

Hmm, there is no intel_reg_dumper in intel-gpu-tools-1.0.2, which is
the latest on http://xorg.freedesktop.org/archive/individual/app/,
so I assumed you just mistyped the name. Is it in git only? ...
Yeah, look like it is in git only, which I have problems to compile
(I have a bit of obsoleted system).
--

[ message continues ]

Is there any other way to get at the dump? Because it looks like
it is plainly impossible to build the tools. A lot of dependencies,
all really hard to get at on Ubuntu Jaunty.
--

[ message continues ]

On Thu, 30 Dec 2010 00:35:15 +0100

That's the easiest way; I think there are existing packages available
as well, but you may have to check Karmic or newer.

-- 
Jesse Barnes, Intel Open Source Technology Center
--

[ message continues ]

Never mind. I'm lazy (that's not to say someone is too).

I redid the test:

Before running "xset dpms force standby":

 http://vin-soft.org/~raa/public/test/intel_reg_dumper-before

After running "sleep 3"

 http://vin-soft.org/~raa/public/test/intel_reg_dumper-suspend

After running "xset dpms force on; sleep 3"

 http://vin-soft.org/~raa/public/test/intel_reg_dumper-xset-on

After closing and opening the lid (displays backlight is back)

 http://vin-soft.org/~raa/public/test/intel_reg_dumper-lid
--

[ message continues ]

No. I assumed the bisection in the bug

  https://bugzilla.kernel.org/show_bug.cgi?id=22672

was for the same problem as mine. It probably is not...
I'm running a bisect right now.
--

[ message continues ]

Ugh, looks like I have confused things horribly.  Sorry about this.

2.6.37-rc8 with no patches works for me.  My original report was incorrect --
I was using -rc7 when I thought I was using -rc8.  :(

Regrets,
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
desserts:  http://www.xenotime.net/linux/recipes/
--

[ message continues ]

Can you confirm that the above doesn't break your setup just in case we
need to apply it?

Thanks,
-- 
Jesse Barnes, Intel Open Source Technology Center
--

[ message continues ]

Yes, confirmed, my test platform still works with this patch applied.

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
desserts:  http://www.xenotime.net/linux/recipes/
--

[ message continues ]

It appeared to be the easiest fix for the machines I had to hand and was
confirmed by several people with identical machines. However, it
definitely caused a regression for working panels and therefore it will
be reverted. 
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
--

[ message continues ]

Hi,


confirmed, at least my blank screen is gone with this -rc8. Thank you all.

ciao,
Domenico
--

[ message continues ]

I still see blank screen on thinkpad x60... but so do I on 2.6.36 with
same config, so maybe it is just tricky to configure?
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--

[ message continues ]

Old bug? I thought we had KMS on 945 pretty well understood by now. Care
to attach the dmesg with drm.debug=0xe? And to check against linus/master
for the most recent regression fixes.
Thanks,
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
--

[ message continues ]

dmesg is attached (delme.gz), as is config.

And yes, I did git pull few minutes ago... 
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[ message continues ]

Disable CONFIG_FB_VESA or remove the vga= line from the commandline for a
first test.

Dave.
--

[ message continues ]