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
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 fus
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
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 fus
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
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 o
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
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 o
Hello,
Some nitpicks below.
On Mon, March 14, 2011 18:59, Chris Wilson wrote:
> From: Matthew Garrett
>
> The Integrated Graphics Device opregion specification defines a mechanism
> for the OS and system firmware to collaborate on various graphics-related
> functionality. This is currently imple
Hello,
Some nitpicks below.
On Mon, March 14, 2011 18:59, Chris Wilson wrote:
> From: Matthew Garrett
>
> The Integrated Graphics Device opregion specification defines a mechanism
> for the OS and system firmware to collaborate on various graphics-related
> functionality. This is currently imple
On Fri, March 11, 2011 18:27, Jesse Barnes wrote:
> 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,
>
On Fri, March 11, 2011 18:27, Jesse Barnes wrote:
> 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,
>
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
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 descri
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
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
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 fro
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
> ++
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 pa
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
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 descri
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
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
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 fro
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
> ++
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 pa
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 use
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,
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
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
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 wrot
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 fr
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 use
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,
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
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
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 wrot
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 fr
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:
>>
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:
>>
Hello,
On Wed, February 23, 2011 02:09, Linus Torvalds wrote:
> On Tue, Feb 22, 2011 at 2:31 PM, Tino Keitel wrote:
>>
>> I just tried 2.6.38-rc6 on my ThinkPad X61s without any other DRM
>> related patches, and my backlight issue is gone.
>
> I applied Indan's fix in -rc6 (commit 951f3512dba5),
Hello,
On Wed, February 23, 2011 02:09, Linus Torvalds wrote:
> On Tue, Feb 22, 2011 at 2:31 PM, Tino Keitel wrote:
>>
>> I just tried 2.6.38-rc6 on my ThinkPad X61s without any other DRM
>> related patches, and my backlight issue is gone.
>
> I applied Indan's fix in -rc6 (commit 951f3512dba5),
On Fri, February 25, 2011 11:18, Alex Riesen wrote:
> On Fri, Feb 25, 2011 at 00:29, Indan Zupancic wrote:
>>>> https://lkml.org/lkml/2011/2/23/34
>>>
>>> This is just the discussion about the problem described in the ticket.
>>> It does not even men
On Fri, February 25, 2011 11:18, Alex Riesen wrote:
> On Fri, Feb 25, 2011 at 00:29, Indan Zupancic wrote:
>>>> https://lkml.org/lkml/2011/2/23/34
>>>
>>> This is just the discussion about the problem described in the ticket.
>>> It does not even men
On Thu, February 24, 2011 20:04, Alex Riesen wrote:
> On Thu, Feb 24, 2011 at 10:18, Indan Zupancic wrote:
>>>>
>>>> As it turns out this is a bug in the userspace components of the stack for
>>>> gen2 hardware, with lax kernel side enforcement. Daniel has a
On Thu, February 24, 2011 20:04, Alex Riesen wrote:
> On Thu, Feb 24, 2011 at 10:18, Indan Zupancic wrote:
>>>>
>>>> As it turns out this is a bug in the userspace components of the stack for
>>>> gen2 hardware, with lax kernel side enforcement. Daniel has a
On Thu, February 24, 2011 09:27, Alex Riesen wrote:
> On Thu, Feb 24, 2011 at 01:13, Chris Wilson
> wrote:
>> On Wed, 23 Feb 2011 15:58:02 -0800, Linus Torvalds > linux-foundation.org>
>> wrote:
>>> >
>>> > See bug https://bugzilla.kernel.org/show_bug.cgi?id=27572
>>>
>>> Any update on that one?
On Thu, February 24, 2011 09:27, Alex Riesen wrote:
> On Thu, Feb 24, 2011 at 01:13, Chris Wilson wrote:
>> On Wed, 23 Feb 2011 15:58:02 -0800, Linus Torvalds
>>
>> wrote:
>>> >
>>> > See bug https://bugzilla.kernel.org/show_bug.cgi?id=27572
>>>
>>> Any update on that one?
>>
>> No, reverting th
ced 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
>
On Tue, February 22, 2011 22:04, Jesse Barnes wrote:
> On Sat, 19 Feb 2011 15:07:49 -0800
> Linus Torvalds wrote:
>
>> On Sat, Feb 19, 2011 at 4:26 AM, Alex Riesen wrote:
>> > On Sat, Feb 19, 2011 at 13:11, Alex Riesen wrote:
>> >>> Lastly, could you verify that my patch at
>> >>> https://lkml.
ced 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
>
On Tue, February 22, 2011 22:04, Jesse Barnes wrote:
> On Sat, 19 Feb 2011 15:07:49 -0800
> Linus Torvalds wrote:
>
>> On Sat, Feb 19, 2011 at 4:26 AM, Alex Riesen wrote:
>> > On Sat, Feb 19, 2011 at 13:11, Alex Riesen wrote:
>> >>> Lastly, could you verify that my patch at
>> >>> https://lkml.
On Tue, February 22, 2011 04:25, Indan Zupancic wrote:
> Hi,
>
> On Sun, February 20, 2011 14:21, Daniel Vetter wrote:
>> Well, don't start jumping around, yet. These patches are just to rule out
>> some theories. Now: Is it fixed with just the 2nd patch alone or do yo
Hi,
On Sun, February 20, 2011 14:21, Daniel Vetter wrote:
> Well, don't start jumping around, yet. These patches are just to rule out
> some theories. Now: Is it fixed with just the 2nd patch alone or do you need
> both
> patches? This is very important, so please test extensively whether there a
On Tue, February 22, 2011 04:25, Indan Zupancic wrote:
> Hi,
>
> On Sun, February 20, 2011 14:21, Daniel Vetter wrote:
>> Well, don't start jumping around, yet. These patches are just to rule out
>> some theories. Now: Is it fixed with just the 2nd patch alone or do yo
Hi,
On Sun, February 20, 2011 14:21, Daniel Vetter wrote:
> Well, don't start jumping around, yet. These patches are just to rule out
> some theories. Now: Is it fixed with just the 2nd patch alone or do you need
> both
> patches? This is very important, so please test extensively whether there a
Hi Peter,
The new corruption is "fixed" with daniel's patch from
https://lkml.org/lkml/2011/2/20/25
On Mon, February 21, 2011 05:10, Peter Stuge wrote:
> Indan Zupancic wrote:
>> > Confirm I also have this issue on my X40, but there are other bugs
>> > that ar
Hi,
Feel free to ignore this post, it's a it of rambling.
On Sun, February 20, 2011 11:55, Daniel Vetter wrote:
> I've just noticed that one of the patches (the 2nd one) doesn't work
> as advertised. Please retest with the attached one.
I was wondering why that was, so I looked a bit closer:
Ol
Hi,
On Sun, February 20, 2011 14:21, Daniel Vetter wrote:
> Well, don't start jumping around, yet. These patches are just to rule
> out some theories.
I know, that's why I said I don't mind testing other patches.
> Now: Is it fixed with just the 2nd patch alone or do you
> need both patches? Thi
Hi Peter,
The new corruption is "fixed" with daniel's patch from
https://lkml.org/lkml/2011/2/20/25
On Mon, February 21, 2011 05:10, Peter Stuge wrote:
> Indan Zupancic wrote:
>> > Confirm I also have this issue on my X40, but there are other bugs
>> > that ar
Hi,
Feel free to ignore this post, it's a it of rambling.
On Sun, February 20, 2011 11:55, Daniel Vetter wrote:
> I've just noticed that one of the patches (the 2nd one) doesn't work
> as advertised. Please retest with the attached one.
I was wondering why that was, so I looked a bit closer:
Ol
Hi,
On Sun, February 20, 2011 14:21, Daniel Vetter wrote:
> Well, don't start jumping around, yet. These patches are just to rule
> out some theories.
I know, that's why I said I don't mind testing other patches.
> Now: Is it fixed with just the 2nd patch alone or do you
> need both patches? Thi
Hi,
Good news:
On Sun, February 20, 2011 11:55, Daniel Vetter wrote:
>> > I've created two quick patches to check a few theories, please test them
>> > (both patches independently and both together). Patches attached.
>>
>> Tried with both applied, doesn't change anything.
>
> I've just noticed t
Hi Daniel,
On Sun, February 20, 2011 10:20, Daniel Vetter wrote:
> On Sun, Feb 20, 2011 at 03:20:15AM +0100, Indan Zupancic wrote:
>> Sorry, I plainly forgot to mention that. I'm on my Thinkpad X40 with gen 2
>> hardware, 855GM.
>
> Ah, craptastic i855gm. Is this with
Hi,
Good news:
On Sun, February 20, 2011 11:55, Daniel Vetter wrote:
>> > I've created two quick patches to check a few theories, please test them
>> > (both patches independently and both together). Patches attached.
>>
>> Tried with both applied, doesn't change anything.
>
> I've just noticed t
Hi Daniel,
On Sun, February 20, 2011 10:20, Daniel Vetter wrote:
> On Sun, Feb 20, 2011 at 03:20:15AM +0100, Indan Zupancic wrote:
>> Sorry, I plainly forgot to mention that. I'm on my Thinkpad X40 with gen 2
>> hardware, 855GM.
>
> Ah, craptastic i855gm. Is this with
Hi Peter,
On Sun, February 20, 2011 04:51, Peter Stuge wrote:
> Confirm I also have this issue on my X40, but there are other bugs
> that are much more significant so I haven't bothered mentioning this.
What issues? If it's backlight related, try my patch at:
http://lkml.org/lkml/2011/2/16/447
O
Huh, no idea why it didn't go to Daniel the first time, Squirrelmail never
did that before.
On Sun, February 20, 2011 03:20, Indan Zupancic wrote:
> Hi,
>
> On Sat, February 19, 2011 19:25, Daniel Vetter wrote:
>> Hi Indan,
>>
>> Please provide the usual details ab
Hi,
On Sat, February 19, 2011 19:25, Daniel Vetter wrote:
> Hi Indan,
>
> Please provide the usual details about your system (especially what gpu
> this is on). Also, screenshots of what typical corruptions look like can
> help a lot in tracking down such things.
Sorry, I plainly forgot to mentio
Hi Peter,
On Sun, February 20, 2011 04:51, Peter Stuge wrote:
> Confirm I also have this issue on my X40, but there are other bugs
> that are much more significant so I haven't bothered mentioning this.
What issues? If it's backlight related, try my patch at:
http://lkml.org/lkml/2011/2/16/447
O
Huh, no idea why it didn't go to Daniel the first time, Squirrelmail never
did that before.
On Sun, February 20, 2011 03:20, Indan Zupancic wrote:
> Hi,
>
> On Sat, February 19, 2011 19:25, Daniel Vetter wrote:
>> Hi Indan,
>>
>> Please provide the usual details ab
Hi,
On Sat, February 19, 2011 19:25, Daniel Vetter wrote:
> Hi Indan,
>
> Please provide the usual details about your system (especially what gpu
> this is on). Also, screenshots of what typical corruptions look like can
> help a lot in tracking down such things.
Sorry, I plainly forgot to mentio
Hello,
Since 2.6.38-rc I get screen corruption (mostly horizontal grabage stripes on
the right side of the screen). After a long time bisecting the offending commit
ends up being:
commit a00b10c360b35d6431a94cbf130a4e162870d661
Author: Chris Wilson
Date: Fri Sep 24 21:15:47 2010 +0100
drm
Hello,
Since 2.6.38-rc I get screen corruption (mostly horizontal grabage stripes on
the right side of the screen). After a long time bisecting the offending commit
ends up being:
commit a00b10c360b35d6431a94cbf130a4e162870d661
Author: Chris Wilson
Date: Fri Sep 24 21:15:47 2010 +0100
drm
On Thu, February 17, 2011 23:13, Tino Keitel wrote:
> with kernel 2.6.37, the display brightness of my ThinkPad X61s was
> always reduced after lid open, resume from suspend etc. With this
> patch on top of 2.6.38-rc5, the problem is gone. Thanks.
Tino, I think Alex's patch only hides the proble
On Thu, February 17, 2011 23:13, Tino Keitel wrote:
> with kernel 2.6.37, the display brightness of my ThinkPad X61s was
> always reduced after lid open, resume from suspend etc. With this
> patch on top of 2.6.38-rc5, the problem is gone. Thanks.
Tino, I think Alex's patch only hides the proble
ation see the below links. This fixes bugs:
http://bugzilla.kernel.org/show_bug.cgi?id=23472
http://bugzilla.kernel.org/show_bug.cgi?id=25072
Signed-off-by: Indan Zupancic
---
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 5cfc689..af2fc32 100644
-
ation see the below links. This fixes bugs:
http://bugzilla.kernel.org/show_bug.cgi?id=23472
http://bugzilla.kernel.org/show_bug.cgi?id=25072
Signed-off-by: Indan Zupancic
---
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 5cfc689..af2fc32 100644
-
On Wed, January 12, 2011 13:07, Chris Wilson wrote:
>
> Sure, s/intel_panel_get_max_backlight/intel_panel_get_backlight/ and we
> get the behaviour we both want - preserving the current backlight unless
> none is set.
Indeed, I hadn't noticed that shortcut. That's a lot nicer than my ifdefery.
>
On Wed, January 12, 2011 13:07, Chris Wilson wrote:
>
> Sure, s/intel_panel_get_max_backlight/intel_panel_get_backlight/ and we
> get the behaviour we both want - preserving the current backlight unless
> none is set.
Indeed, I hadn't noticed that shortcut. That's a lot nicer than my ifdefery.
>
Hello,
On Tue, January 11, 2011 18:39, Chris Wilson wrote:
> On Tue, 11 Jan 2011 18:19:17 +0100, Michal Hocko wrote:
>> [Let's CC Indan - author of the bugzilla patches]
>>
>> On Thu 06-01-11 11:48:16, Michal Hocko wrote:
>> > Hi,
>> >
>> > On Tue 04-01-11 17:15:45, Linus Torvalds wrote:
>> > [..
Hello,
On Tue, January 11, 2011 18:39, Chris Wilson wrote:
> On Tue, 11 Jan 2011 18:19:17 +0100, Michal Hocko wrote:
>> [Let's CC Indan - author of the bugzilla patches]
>>
>> On Thu 06-01-11 11:48:16, Michal Hocko wrote:
>> > Hi,
>> >
>> > On Tue 04-01-11 17:15:45, Linus Torvalds wrote:
>> > [..
82 matches
Mail list logo