[Intel-gfx] vesafb, intel_drv and gm45

2011-03-15 Thread Suresh Kumar
[Continuing from IRC] Hello all, I have GM45 mobile chipset (PCI_CHIP_GM45_GM/0x2A42). And running Xorg 1.6.5, Intel driver 2.7.0 and kernel 2.6.29. I need to use vesafb (bootsplash depends on it), and for some (legacy code) reasons I can't immediately migrate the system to newer kernel (or start

Re: [Intel-gfx] [PATCH] ACPI/Intel: Rework Opregion support

2011-03-15 Thread Indan Zupancic
On Wed, March 16, 2011 03:17, Alex Deucher wrote: > It's not HDCP, encrypted bluray is the main issue. And while > there are hacks for bluray around already, contractual obligations > don't care whether existing hacks are available or not. So the contract says to keep it secret, not to make it se

Re: [Intel-gfx] [PATCH] ACPI/Intel: Rework Opregion support

2011-03-15 Thread Dave Airlie
> > Read the changelog and thread on the patch that disabled this logic, the > failure (or at least inconsistent behaviour with the expectations of the > HP BIOS authors) appears to be in how we initialise ACPI on the HP > machines that causes the initial value of lid state to be incorrect. Since >

Re: [Intel-gfx] [PATCH] ACPI/Intel: Rework Opregion support

2011-03-15 Thread Indan Zupancic
On Tue, March 15, 2011 17:06, Alex Deucher wrote: > On Tue, Mar 15, 2011 at 7:46 AM, Indan Zupancic wrote: >> They don't give their Linux devs any Fusion hardware, nor do they >> open the UVD spec, but at least they release info like this. > > They do give us fusion hw; before launch even. That's

Re: [Intel-gfx] [PATCH] drm/i915: Re-enable rc6 w/fix

2011-03-15 Thread Florian Mickler
On Tue, 15 Mar 2011 07:59:48 + Chris Wilson wrote: > > Resolve https://bugzilla.kernel.org/show_bug.cgi?id=28582 > > I understood the convention (to aide those running external scripts) was > either Bugzilla: or References: Thx for considering those poor souls that try to follow up on all t

[Intel-gfx] [PATCH] drm/i915: report correct frequencies on SNB

2011-03-15 Thread Jesse Barnes
Fix up the debug file to report the right frequencies. On SNB, we program the PCU with a frequency ratio, which is multiplied by 100MHz on the CPU side. But GFX only runs at half that, so report it as such to avoid confusion. Signed-off-by: Jesse Barnes --- drivers/gpu/drm/i915/i915_debugfs.c

Re: [Intel-gfx] [PATCH] drm/i915: Re-enable rc6 w/fix

2011-03-15 Thread Daniel Vetter
On Tue, Mar 15, 2011 at 07:59:48AM +, Chris Wilson wrote: > I think I should update the comments to reflect what the spec says about > LOAD_REGISTER_IMM (even though I trust Daniel to have accurately > determined their impact on gen2/3)... The spec implies that the variable > length nature of t

Re: [Intel-gfx] [PATCH] drm: Hold the mode mutex whilst probing for sysfs status

2011-03-15 Thread Jesse Barnes
On Tue, 15 Mar 2011 11:40:00 + Chris Wilson wrote: > As detect will use hw registers and may modify structures, it needs to be > serialised by use of the dev->mode_config.mutex. Make it so. > > Otherwise, we may cause random crashes as the sysfs file is queried > whilst a concurrent hotplug

Re: [Intel-gfx] [PATCH] ACPI/Intel: Rework Opregion support

2011-03-15 Thread Matthew Garrett
On Tue, Mar 15, 2011 at 02:40:59PM +0100, Olivier Galibert wrote: > On Tue, Mar 15, 2011 at 01:32:40PM +, Matthew Garrett wrote: > > Opregion is one mechanism to provide VBT - it doesn't define it. > > Then let me repeat that I haven't seen anything in the VBT tables of > the gma500-using netb

Re: [Intel-gfx] [PATCH] ACPI/Intel: Rework Opregion support

2011-03-15 Thread Olivier Galibert
On Tue, Mar 15, 2011 at 01:32:40PM +, Matthew Garrett wrote: > Opregion is one mechanism to provide VBT - it doesn't define it. Then let me repeat that I haven't seen anything in the VBT tables of the gma500-using netbook I have that didn't seem to be parsed correctly by the current gpu/drm/i9

Re: [Intel-gfx] [PATCH] ACPI/Intel: Rework Opregion support

2011-03-15 Thread Olivier Galibert
On Tue, Mar 15, 2011 at 01:52:26AM +, Matthew Garrett wrote: > Now that we've got multiple consumers it's probably not helpful to move > the (potentially chip-specific) VBT handling to general code. We've got > zero documentation on how GMA500 handles VBT, and not a great deal more > for i91

Re: [Intel-gfx] [PATCH] ACPI/Intel: Rework Opregion support

2011-03-15 Thread Matthew Garrett
On Tue, Mar 15, 2011 at 02:30:55PM +0100, Olivier Galibert wrote: > On Tue, Mar 15, 2011 at 01:52:26AM +, Matthew Garrett wrote: > > Now that we've got multiple consumers it's probably not helpful to move > > the (potentially chip-specific) VBT handling to general code. We've got > > zero doc

Re: [Intel-gfx] [PATCH] drm: Hold the mode mutex whilst probing for sysfs status

2011-03-15 Thread Julien Cristau
On Tue, Mar 15, 2011 at 11:40:00 +, Chris Wilson wrote: > [Digression: what is upowerd doing reading those power hungry files?] > Apparently, checking "docked" status every 30 seconds, by reading the status of drm outputs. Where "docked" means "more than one output connected". Yes, it's sil

Re: [Intel-gfx] [PATCH] ACPI/Intel: Rework Opregion support

2011-03-15 Thread Indan Zupancic
On Tue, March 15, 2011 12:27, Peter Stuge wrote: > coreboot has existed for about eleven years and some 250 mainboards of > varying shapes and sizes (from laptop to server) are supported, but it's I've been wanting to get rid of BIOSes and use Coreboot for ages, but the amount of hassle needed to

[Intel-gfx] [PATCH] drm: Hold the mode mutex whilst probing for sysfs status

2011-03-15 Thread Chris Wilson
As detect will use hw registers and may modify structures, it needs to be serialised by use of the dev->mode_config.mutex. Make it so. Otherwise, we may cause random crashes as the sysfs file is queried whilst a concurrent hotplug poll is being run. For example: [ 1189.189626] BUG: unable to hand

Re: [Intel-gfx] [PATCH] ACPI/Intel: Rework Opregion support

2011-03-15 Thread Indan Zupancic
On Tue, March 15, 2011 09:37, Chris Wilson wrote: > On Tue, 15 Mar 2011 02:18:02 +0100 (CET), "Indan Zupancic" > wrote: >> Hello, >> >> Some nitpicks below. >> >> On Mon, March 14, 2011 18:59, Chris Wilson wrote: >> > Note: neither the opregion_dev interface or the alse_set_* properly report >> >

[Intel-gfx] Linux 2.6.37-2, 2.14.0-4: BUG: unable to handle kernel NULL pointer dereference at 00000100; IP: [] intel_tv_detect_type+0xa2/0x203 [i915]

2011-03-15 Thread Paul Menzel
Dear Intel driver folks, using Debian Sid/unstable with linux-image-2.6.37-2-686 2.6.37-2 [1] xserver-xorg-video-intel 2:2.14.0-4 [2] I noticed the following Linux kernel Oops today when shutting down the system. Mar 15 03:43:23 hostname kernel: [ 1189.189626] BUG: unab

Re: [Intel-gfx] [PATCH] drm/i915: Re-enable rc6 w/fix

2011-03-15 Thread Chris Wilson
On Tue, 15 Mar 2011 00:12:51 -0700, Ben Widawsky wrote: > On Mon, Mar 14, 2011 at 10:00:20PM -0700, Ben Widawsky wrote: > > On Mon, Mar 14, 2011 at 09:55:01PM -0700, Ben Widawsky wrote: > > > This fixes a race condition with MI_SET_CONTEXT and setting of the > > > PWRCTXA register. If PWRCTXA ends

Re: [Intel-gfx] [PATCH] ACPI/Intel: Rework Opregion support

2011-03-15 Thread Chris Wilson
On Tue, 15 Mar 2011 02:18:02 +0100 (CET), "Indan Zupancic" wrote: > Hello, > > Some nitpicks below. > > On Mon, March 14, 2011 18:59, Chris Wilson wrote: > > Note: neither the opregion_dev interface or the alse_set_* properly report > > failures. As such we have a slight change in behaviour on I

Re: [Intel-gfx] [PATCH] drm/i915: Re-enable rc6 w/fix

2011-03-15 Thread Chris Wilson
On Mon, 14 Mar 2011 21:55:01 -0700, Ben Widawsky wrote: > This fixes a race condition with MI_SET_CONTEXT and setting of the > PWRCTXA register. If PWRCTXA ends up getting set before MI_SET_CONTEXT > completes, it's possible that the system will enter rc6, and try to > return to the default render

Re: [Intel-gfx] [PATCH] drm/i915: Re-enable rc6 w/fix

2011-03-15 Thread Ben Widawsky
On Mon, Mar 14, 2011 at 10:00:20PM -0700, Ben Widawsky wrote: > On Mon, Mar 14, 2011 at 09:55:01PM -0700, Ben Widawsky wrote: > > This fixes a race condition with MI_SET_CONTEXT and setting of the > > PWRCTXA register. If PWRCTXA ends up getting set before MI_SET_CONTEXT > > completes, it's possibl