Linux 3.0-rc4

[Melchior FRANZ]

* Nick Bowler -- Tuesday 21 June 2011:
> We're at -rc4 now, but it seems that the following patch (drm/i915: add
> missing intel_enable_plane() call to i9xx_crtc_mode_set()) has not made
> it in yet?
> 
>   http://permalink.gmane.org/gmane.linux.kernel/1148279
> 
> The i915 driver has been broken since 3.0-rc1 without this fix,
> which has been available for 3 weeks now.

Keith has suggested a better fix (https://lkml.org/lkml/2011/6/6/560),
but for some reason it still hasn't made it into the kernel.

m.

Re: Linux 3.0-rc4

[Melchior FRANZ]

* Nick Bowler -- Tuesday 21 June 2011:
 We're at -rc4 now, but it seems that the following patch (drm/i915: add
 missing intel_enable_plane() call to i9xx_crtc_mode_set()) has not made
 it in yet?
 
   http://permalink.gmane.org/gmane.linux.kernel/1148279
 
 The i915 driver has been broken since 3.0-rc1 without this fix,
 which has been available for 3 weeks now.

Keith has suggested a better fix (https://lkml.org/lkml/2011/6/6/560),
but for some reason it still hasn't made it into the kernel.

m.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Regression: Borked display on second output with Intel G45 in 3.0-rc2

[Melchior FRANZ]

* Nick Bowler -- Monday 06 June 2011:
> After upgrading to 3.0-rc2, my second display is no longer working
> correctly on a desktop with an Intel G45 graphics chip.
[...]
> What I do know is that the problem was originally introduced by
> 49183b2818de ("drm/i915: Only enable the plane after setting the fb
> base (pre-ILK)").  It was subsequently fixed by 982b2035d9d7 ("Revert
> "drm/i915: Only enable the plane after setting the fb base (pre-ILK)"").
> The problem was reintroduced by 98b98d316349 ("Merge branch 'drm-core-next'
> of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6").

That's apparently the bug that I've submitted a patch for on 2011/5/31:
https://lkml.org/lkml/2011/5/31/393
I assume/hope it's still in someone's queue.

m.

[PATCH] drm/i915: add missing intel_enable_plane() call to i9xx_crtc_mode_set()

[Melchior FRANZ]

From: Melchior FRANZ <mfr...@aon.at>

Fix garbled up virtual linux console on Acer TM 5735Z-452G32Mnss
(colored stripes, unreadable text) by adding the intel_enable_plane()
call also to i9xx_crtc_mode_set(), which didn't inherit it from
intel_crtc_mode_set() like its twin ironlake_crtc_mode_set().

Signed-off-by: Melchior FRANZ 
---

The bug was originally introduced with 49183b2818 and fixed with
982b2035d9, but re-introduced by a recent drm/i915 branch merge.


diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index f553ddf..5d20579 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4735,6 +4735,8 @@ static int i9xx_crtc_mode_set(struct drm_crtc *crtc,

I915_WRITE(DSPCNTR(plane), dspcntr);
POSTING_READ(DSPCNTR(plane));
+   if (!HAS_PCH_SPLIT(dev))
+   intel_enable_plane(dev_priv, plane, pipe);

ret = intel_pipe_set_base(crtc, x, y, old_fb);

[PATCH] drm/i915: add missing intel_enable_plane() call to i9xx_crtc_mode_set()

[Melchior FRANZ]

From: Melchior FRANZ mfr...@aon.at

Fix garbled up virtual linux console on Acer TM 5735Z-452G32Mnss
(colored stripes, unreadable text) by adding the intel_enable_plane()
call also to i9xx_crtc_mode_set(), which didn't inherit it from
intel_crtc_mode_set() like its twin ironlake_crtc_mode_set().

Signed-off-by: Melchior FRANZ mfr...@aon.at
---

The bug was originally introduced with 49183b2818 and fixed with
982b2035d9, but re-introduced by a recent drm/i915 branch merge.


diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index f553ddf..5d20579 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4735,6 +4735,8 @@ static int i9xx_crtc_mode_set(struct drm_crtc *crtc,
 
I915_WRITE(DSPCNTR(plane), dspcntr);
POSTING_READ(DSPCNTR(plane));
+   if (!HAS_PCH_SPLIT(dev))
+   intel_enable_plane(dev_priv, plane, pipe);
 
ret = intel_pipe_set_base(crtc, x, y, old_fb);
 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[3.0-rc1 regression] (was: Re: [2.6.39 regression] i915/kms: garbled screen because of 49183b281)

[Melchior FRANZ]

* Melchior FRANZ -- Thursday 12 May 2011:
> > Chris Wilson (4):
> >   drm/i915: Only enable the plane after setting the fb base (pre-ILK)
> 
> This patch introduces a bug on my infamous "Acer Travelmate
> 5735Z-452G32Mnss": when KMS takes over, the frame buffer contents
> get completely garbled up on screen, with colored stripes and
> unreadable text (photo on request). Only when X11 is started, the
> screen gets restored again. Closing and re-opening the lid partly
> cures the mess, too: it makes the font readable, though horizontally
> stretched.
> 
> Reverting 49183b2818de6899383bb82bc032f9344d6791ff fixes the
> bug.

This got fixed after my bug report, but now it's back with exactly
the same description. Bisection result to come ...

m.

[3.0-rc1 regression] (was: Re: [2.6.39 regression] i915/kms: garbled screen because of 49183b281)

[Melchior FRANZ]

* Melchior FRANZ -- Thursday 12 May 2011:
  Chris Wilson (4):
drm/i915: Only enable the plane after setting the fb base (pre-ILK)
 
 This patch introduces a bug on my infamous Acer Travelmate
 5735Z-452G32Mnss: when KMS takes over, the frame buffer contents
 get completely garbled up on screen, with colored stripes and
 unreadable text (photo on request). Only when X11 is started, the
 screen gets restored again. Closing and re-opening the lid partly
 cures the mess, too: it makes the font readable, though horizontally
 stretched.
 
 Reverting 49183b2818de6899383bb82bc032f9344d6791ff fixes the
 bug.

This got fixed after my bug report, but now it's back with exactly
the same description. Bisection result to come ...

m.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

i915/kms/backlight-combo mode problem

[Melchior FRANZ]

Hey,

* Michael Chang -- Tuesday 17 May 2011:
> If you change brightness from lowest to highest, the LPBC value changes
> this way
> 
> Highest  Lowest
> 0x10 ,   0x19 ..   0xe5

Yes. (Though it's 0x01, not 0x10.)

---0xFF  ... initial value and after closing/reopening lid
|  0xE5   \  ... dark
|  0xCC   |
|  0xB2   |
 (1)|  0x99   |
|  0x7F   |_key adjustable range
|  0x66   |
|  0x4C   |
|  0x33   |
-->0x19   |
   0x01   /  ... bright
   0x00  ... also bright, only settable with setpci


(1) is the jump that resurrects the backlight from darkness by
pressing the "brightness down" key

And again, if fully turned up via keys (and therefore at 0x01),
then setting to 0xff with setpci doesn't turn it off. At all other
key steps it does.  :-)



> If above is true, then you have a very particular notebook that
> reverse the sense of the LPBC values   I don't know who ever came
> across such device. wow.

Maybe they screwed it up and therefore sold it with Linux ("linpus")
and a custom driver preinstalled ...



> Regarding that your brightness control key,  due to that it is
> controlled by acer_wmi and likely that BIOS aware this, it would do
> brightness in a reversed way.

acer_wmi doesn't do the brightness adjustment. But maybe under "linpus"
some variant of it did. (BTW: there are two keys on this notebook that
aren't handled by the kernel, by X11 or even acer_wmi. There are just no
events for them. Looks like another ACER brain damage err.. "capability". :-)

m.

i915/kms/backlight-combo mode problem

[Melchior FRANZ]

* Michael Chang -- Tuesday 17 May 2011:
[LBPC]
> You can know your LPBC value by:
>   $ lspci -xxx -s 00:02.0 | awk '/^f0:/ {print $6}'
> 
> And alter it's value via setpci (assuming set it to max)
>   $ setpci -s 00:02.0 F4.B=ff
> 
> I assume you've tried this .. as you report setpci works for you. :)

Ahh, yes, indeed. This lspci line (almost) always shows a value that
corresponds with the actual backlight brightness, and both lines work
with and without acpi_osi=Linux. (Whereas adjustment via keys only works
*with* acpi_osi=Linux.)  (Tested with 2.6.39-rc7/bd1a643e10)



> Could you help to get the LPBC value in the initial dark condition? If
> it's not corresponds to 255, maybe something sneaks and changes it but
> not logged.

Initially (with acpi_osi=Linux) LPBC=0xff. After "brightness down"
it's 0x19, and after then pressing "brightness up" it's 0x01. The lowest
value I can achieve after pressing "brightness down" a few times is 0xe5,
the highest is 0x01. Neither 0xff nor 0x00 can be reached via keys, but
can (most of the time -- see below!) be set with the setpci line and give
the expected results, backlight off and fully on. ("display toggle" has
no effect on LBPC, btw.) 

Setting 0xFF doesn't always turn the backlight off, though! If LBPC is
at the (key) maximum 0x01, then setting 0xFF via setpci changes only the
LBPC value as shown by lspci, but the backlight isn't actually turned off!
If I then press "backlight darker" once (LBPC=0x19), then setting 0xFF
via setpci works again.



>  1. $ dmesg -c
>  2. Close the lid
>  3. Open the lid
>  4. $ dmesg > dmesg.lid

The results are:

[  188.571040] [drm:intel_panel_set_backlight], set backlight PWM = 736950
[  188.571048] [drm:is_backlight_combination_mode], BLM_COMBINATION_MODE = 
1073741824
[  188.571054] [drm:is_backlight_combination_mode], BLM_COMBINATION_MODE = 
1073741824
[  188.571059] [drm:intel_panel_get_max_backlight], max backlight PWM = 736950
[  188.571064] [drm:intel_panel_set_backlight], set backlight max = 736950
[  188.571069] [drm:intel_panel_set_backlight], set backlight lbpc = 255
[  188.571075] [drm:intel_panel_set_backlight], set backlight tmp(1) = 189399040
[  188.571080] [drm:intel_panel_set_backlight], set backlight tmp(2) = 189399040
[  188.571084] [drm:intel_panel_set_backlight], 
[  188.571088] [drm:intel_opregion_asle_intr], non asle set request??
[  188.571093] set backlight level = 2890

The backlight is off now, as always after closing/reopening the lid,
and LPBC=0xff.

m.



PS: I'd be willing to join an irc.freenode.net channel in case you or
anyone else wants quicker ("live") responses to such queries.

Re: i915/kms/backlight-combo mode problem

[Melchior FRANZ]

* Michael Chang -- Tuesday 17 May 2011:
[LBPC]
 You can know your LPBC value by:
   $ lspci -xxx -s 00:02.0 | awk '/^f0:/ {print $6}'
 
 And alter it's value via setpci (assuming set it to max)
   $ setpci -s 00:02.0 F4.B=ff
 
 I assume you've tried this .. as you report setpci works for you. :)

Ahh, yes, indeed. This lspci line (almost) always shows a value that
corresponds with the actual backlight brightness, and both lines work
with and without acpi_osi=Linux. (Whereas adjustment via keys only works
*with* acpi_osi=Linux.)  (Tested with 2.6.39-rc7/bd1a643e10)



 Could you help to get the LPBC value in the initial dark condition? If
 it's not corresponds to 255, maybe something sneaks and changes it but
 not logged.

Initially (with acpi_osi=Linux) LPBC=0xff. After brightness down
it's 0x19, and after then pressing brightness up it's 0x01. The lowest
value I can achieve after pressing brightness down a few times is 0xe5,
the highest is 0x01. Neither 0xff nor 0x00 can be reached via keys, but
can (most of the time -- see below!) be set with the setpci line and give
the expected results, backlight off and fully on. (display toggle has
no effect on LBPC, btw.) 

Setting 0xFF doesn't always turn the backlight off, though! If LBPC is
at the (key) maximum 0x01, then setting 0xFF via setpci changes only the
LBPC value as shown by lspci, but the backlight isn't actually turned off!
If I then press backlight darker once (LBPC=0x19), then setting 0xFF
via setpci works again.



  1. $ dmesg -c
  2. Close the lid
  3. Open the lid
  4. $ dmesg  dmesg.lid

The results are:

[  188.571040] [drm:intel_panel_set_backlight], set backlight PWM = 736950
[  188.571048] [drm:is_backlight_combination_mode], BLM_COMBINATION_MODE = 
1073741824
[  188.571054] [drm:is_backlight_combination_mode], BLM_COMBINATION_MODE = 
1073741824
[  188.571059] [drm:intel_panel_get_max_backlight], max backlight PWM = 736950
[  188.571064] [drm:intel_panel_set_backlight], set backlight max = 736950
[  188.571069] [drm:intel_panel_set_backlight], set backlight lbpc = 255
[  188.571075] [drm:intel_panel_set_backlight], set backlight tmp(1) = 189399040
[  188.571080] [drm:intel_panel_set_backlight], set backlight tmp(2) = 189399040
[  188.571084] [drm:intel_panel_set_backlight], 
[  188.571088] [drm:intel_opregion_asle_intr], non asle set request??
[  188.571093] set backlight level = 2890

The backlight is off now, as always after closing/reopening the lid,
and LPBC=0xff.

m.



PS: I'd be willing to join an irc.freenode.net channel in case you or
anyone else wants quicker (live) responses to such queries.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: i915/kms/backlight-combo mode problem

[Melchior FRANZ]

Hey,

* Michael Chang -- Tuesday 17 May 2011:
 If you change brightness from lowest to highest, the LPBC value changes
 this way
 
 Highest  Lowest
 0x10 ,   0x19 ..   0xe5

Yes. (Though it's 0x01, not 0x10.)

---0xFF  ... initial value and after closing/reopening lid
|  0xE5   \  ... dark
|  0xCC   |
|  0xB2   |
 (1)|  0x99   |
|  0x7F   |_key adjustable range
|  0x66   |
|  0x4C   |
|  0x33   |
--0x19   |
   0x01   /  ... bright
   0x00  ... also bright, only settable with setpci


(1) is the jump that resurrects the backlight from darkness by
pressing the brightness down key

And again, if fully turned up via keys (and therefore at 0x01),
then setting to 0xff with setpci doesn't turn it off. At all other
key steps it does.  :-)



 If above is true, then you have a very particular notebook that
 reverse the sense of the LPBC values   I don't know who ever came
 across such device. wow.

Maybe they screwed it up and therefore sold it with Linux (linpus)
and a custom driver preinstalled ...



 Regarding that your brightness control key,  due to that it is
 controlled by acer_wmi and likely that BIOS aware this, it would do
 brightness in a reversed way.

acer_wmi doesn't do the brightness adjustment. But maybe under linpus
some variant of it did. (BTW: there are two keys on this notebook that
aren't handled by the kernel, by X11 or even acer_wmi. There are just no
events for them. Looks like another ACER brain damage err.. capability. :-)

m.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

i915/kms/backlight-combo mode problem

[Melchior FRANZ]

* Takashi Iwai -- Sunday 15 May 2011:
> IIRC, you reported that the backlight gets normal when you revert my
> commit in 2.6.38.x.  So, this was regarded as a regression at first.

Yes. And it *is* a regression, which is the whole point of my
initial complaint, as reported by Maciej in 
https://bugzilla.kernel.org/show_bug.cgi?id=31522



> But, one question remains: whether the backlight level control worked
> with the reverted kernel?

Good point. Turns out it didn't work with 2.6.38-rc8 either. But it
did work at some time before. (I use this notebook mainly as a
terminal ATM, so I didn't care much for backlight level. This came
up later during investigation.)

So the only thing that 2.6.38 broke was that the backlight
was initially off. Adjustment had already been broken before
(and works now again; sigh ... confused? I am! :-).



> If you can still change the level without
> LBPC, the former analysis was incorrect.

I don't even know what an LBPC is, other than a variable named like that.
So I'd need a hint for how to test that.



> Also, with the latest 2.6.38.x, you found that the backlight gets back
> when you adjust the level down.

When I reported this, it was about 2.6.39-* and HEAD, not stable
versions. But I tried now, and openSuSE's 2.6.38.6 behaves the same.



> Another question now is what happens if you again turn it up to the
> max level.  Is the backlight still on?

Yes. If the backlight was on at one point, then increasing the level
to maximum never turned if off.



> If the backlight is kept on even with the max level, it implies that
> the problem is only the initial value; once when set correctly, it'll
> work fine after that.

Yes, that's the case. (Except that after closing the lid it's off again.)

m.

Re: i915/kms/backlight-combo mode problem

[Melchior FRANZ]

* Takashi Iwai -- Sunday 15 May 2011:
 IIRC, you reported that the backlight gets normal when you revert my
 commit in 2.6.38.x.  So, this was regarded as a regression at first.

Yes. And it *is* a regression, which is the whole point of my
initial complaint, as reported by Maciej in 
https://bugzilla.kernel.org/show_bug.cgi?id=31522



 But, one question remains: whether the backlight level control worked
 with the reverted kernel?

Good point. Turns out it didn't work with 2.6.38-rc8 either. But it
did work at some time before. (I use this notebook mainly as a
terminal ATM, so I didn't care much for backlight level. This came
up later during investigation.)

So the only thing that 2.6.38 broke was that the backlight
was initially off. Adjustment had already been broken before
(and works now again; sigh ... confused? I am! :-).



 If you can still change the level without
 LBPC, the former analysis was incorrect.

I don't even know what an LBPC is, other than a variable named like that.
So I'd need a hint for how to test that.



 Also, with the latest 2.6.38.x, you found that the backlight gets back
 when you adjust the level down.

When I reported this, it was about 2.6.39-* and HEAD, not stable
versions. But I tried now, and openSuSE's 2.6.38.6 behaves the same.



 Another question now is what happens if you again turn it up to the
 max level.  Is the backlight still on?

Yes. If the backlight was on at one point, then increasing the level
to maximum never turned if off.



 If the backlight is kept on even with the max level, it implies that
 the problem is only the initial value; once when set correctly, it'll
 work fine after that.

Yes, that's the case. (Except that after closing the lid it's off again.)

m.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

i915/kms/backlight-combo mode problem

[Melchior FRANZ]

Hey,

* Michael Chang -- Friday 13 May 2011:
> But there's more questions in my mind, made me feel not
> able to proceed any further.. :(

No problem. The reason for inconsistencies in my reports is
simply that I've realized some properties only later. So here's
a new error description, based on ddb503b42960, which is current
HEAD.


On this "Acer Travelmate 5735Z-452G32Mnss" the following happens
since after 2.6.37-rc8, with acpi_osi=Linux:

- the backlight goes dark as soon as KMS takes over early in the
  boot process (the screen contents aren't corrupted, though, and
  under appropriate lighting conditions I can even see the
  (very dark) uncorrupted contents.)

- when I press the "backlight darker" key, the backlight is turned
  on. (No other key does that AFAICS, including "display toggle"
  and "backlight brighter.)

Everything works correctly after that, including backlight adjustment,
BUT:

 - when I close the lid and open it again, the backlight stays black
   again, just like before. Backlight adjustment turns it on, and
   now even the "brighter" key does it sometimes, but not always.)



> 1. is_backlight_combination_mode() really returns 0x4 ..?

[2.6.39 regression] i915/kms: garbled screen because of 49183b281 (was: Re: Linux 2.6.39-rc7)

[Melchior FRANZ]

* Chris Wilson -- Thursday 12 May 2011:
> So we think that enabling the plane at this point is masking a bug in our
> modeset, or that some side-effect of writing those registers or waiting
> for that vblank has a vital latching or delay that we have not accounted
> for.

Attached are the requested register dumps:

  intel_reg_dump__nomodeset.gz
  \___no kms -- no corruption

  intel_reg_dump__bad.gz
  \___with kms -- corrupted screen contents with staircase
  shaped and horizontally stretched scan lines. Unreadable.

  intel_reg_dump__lid.gz
  \___after closing and reopening lid. The text is now readable,
  but horizontally stretched. It looks like there's a dark
  pixel between any pair of legitimate font pixels.

  intel_reg_dump__x11.gz
   \___after starting x11. Now both the x11 screen and virtual
   terminals look right.


(BTW: there's also still the problem that the backlight remains off
until I press the "screen darker" key. Maybe this problem is related?
https://bugzilla.kernel.org/show_bug.cgi?id=31522).

m.
-- next part --
A non-text attachment was scrubbed...
Name: intel_reg_dump__nomodeset.gz
Type: application/x-gzip
Size: 2315 bytes
Desc: not available
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: intel_reg_dump__bad.gz
Type: application/x-gzip
Size: 2344 bytes
Desc: not available
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: intel_reg_dump__lid.gz
Type: application/x-gzip
Size: 2342 bytes
Desc: not available
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: intel_reg_dump__x11.gz
Type: application/x-gzip
Size: 2568 bytes
Desc: not available
URL: 

Re: [2.6.39 regression] i915/kms: garbled screen because of 49183b281 (was: Re: Linux 2.6.39-rc7)

[Melchior FRANZ]

* Chris Wilson -- Thursday 12 May 2011:
 So we think that enabling the plane at this point is masking a bug in our
 modeset, or that some side-effect of writing those registers or waiting
 for that vblank has a vital latching or delay that we have not accounted
 for.

Attached are the requested register dumps:

  intel_reg_dump__nomodeset.gz
  \___no kms -- no corruption

  intel_reg_dump__bad.gz
  \___with kms -- corrupted screen contents with staircase
  shaped and horizontally stretched scan lines. Unreadable.

  intel_reg_dump__lid.gz
  \___after closing and reopening lid. The text is now readable,
  but horizontally stretched. It looks like there's a dark
  pixel between any pair of legitimate font pixels.

  intel_reg_dump__x11.gz
   \___after starting x11. Now both the x11 screen and virtual
   terminals look right.


(BTW: there's also still the problem that the backlight remains off
until I press the screen darker key. Maybe this problem is related?
https://bugzilla.kernel.org/show_bug.cgi?id=31522).

m.


intel_reg_dump__nomodeset.gz
Description: GNU Zip compressed data


intel_reg_dump__bad.gz
Description: GNU Zip compressed data


intel_reg_dump__lid.gz
Description: GNU Zip compressed data


intel_reg_dump__x11.gz
Description: GNU Zip compressed data
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[2.6.39 regression] i915/kms: garbled screen because of 49183b281 (was: Re: Linux 2.6.39-rc7)

[Melchior FRANZ]

* Linus Torvalds -- Tuesday 10 May 2011:
> But please do test, just to make sure that 39-final is good.

> Chris Wilson (4):
>   drm/i915: Only enable the plane after setting the fb base (pre-ILK)

This patch introduces a bug on my infamous "Acer Travelmate
5735Z-452G32Mnss": when KMS takes over, the frame buffer contents
get completely garbled up on screen, with colored stripes and
unreadable text (photo on request). Only when X11 is started, the
screen gets restored again. Closing and re-opening the lid partly
cures the mess, too: it makes the font readable, though horizontally
stretched.

Reverting 49183b2818de6899383bb82bc032f9344d6791ff fixes the
bug.

m.





drm.debug=0x02

[2.604831] [drm] Initialized drm 1.1.0 20060810
[2.648409] i915 :00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[2.648415] i915 :00:02.0: setting latency timer to 64
[2.708949] [drm:intel_opregion_setup], graphic opregion physical addr: 
0x7ba8c018
[2.708987] [drm:intel_opregion_setup], Public ACPI methods supported
[2.708989] [drm:intel_opregion_setup], SWSCI supported
[2.708991] [drm:intel_opregion_setup], ASLE supported
[2.709047] i915 :00:02.0: irq 44 for MSI/MSI-X
[2.709053] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[2.709054] [drm] Driver supports precise vblank timestamp query.
[2.735626] [drm:init_status_page], render ring hws offset: 0x
[2.735747] [drm:init_status_page], bsd ring hws offset: 0x00021000
[2.735852] [drm:intel_parse_bios], Using VBT from OpRegion: $VBT CANTIGA
d
[2.779279] [drm:intel_panel_get_backlight], get backlight PWM = 0
[2.779287] vgaarb: device changed decodes: 
PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
[2.779616] [drm:intel_panel_set_backlight], set backlight PWM = 0
[2.779619] [drm:intel_panel_get_max_backlight], max backlight PWM = 736950
[2.779626] [drm:intel_opregion_asle_intr], non asle set request??
[3.022059] [drm:gm45_get_vblank_counter], trying to get vblank count for 
disabled pipe A
[3.022065] [drm:gm45_get_vblank_counter], trying to get vblank count for 
disabled pipe A
[3.074270] checking generic (8000 3ff) vs hw (8000 1000)
[3.074274] fb: conflicting fb hw usage inteldrmfb vs VESA VGA - removing 
generic driver
[3.074293] Console: switching to colour dummy device 80x25
[3.074806] fbcon: inteldrmfb (fb0) is primary device
[3.109085] [drm:intel_panel_get_max_backlight], max backlight PWM = 736950
[3.109087] [drm:intel_panel_set_backlight], set backlight PWM = 736950
[3.109090] [drm:intel_panel_get_max_backlight], max backlight PWM = 736950
[3.109098] [drm:intel_opregion_asle_intr], non asle set request??
[3.109111] Console: switching to colour frame buffer device 170x48
[3.111779] fb0: inteldrmfb frame buffer device
[3.111780] drm: registered panic notifier
[3.158015] scsi 4:0:0:0: Direct-Access Generic- Multi-Card   1.00 
PQ: 0 ANSI: 0 CCS
[3.413081] acpi device:07: registered as cooling_device2
[3.413431] input: Video Bus as 
/devices/LNXSYSTM:00/device:00/PNP0A08:00/LNXVIDEO:01/input/input6
[3.413532] ACPI: Video Device [OVGA] (multi-head: yes  rom: no  post: no)
[3.413982] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on minor 0
[4.059019] sd 4:0:0:0: [sdb] 15720448 512-byte logical blocks: (8.04 
GB/7.49 GiB)
[4.059746] sd 4:0:0:0: [sdb] Write Protect is off
[4.059750] sd 4:0:0:0: [sdb] Mode Sense: 03 00 00 00
[4.059752] sd 4:0:0:0: [sdb] Assuming drive cache: write through
[4.061879] sd 4:0:0:0: [sdb] Assuming drive cache: write through
[4.066269]  sdb: sdb1
[4.067995] sd 4:0:0:0: [sdb] Assuming drive cache: write through
[4.068056] sd 4:0:0:0: [sdb] Attached SCSI removable disk
[5.016884] md: linear personality registered for level -1
[   94.800469] [drm:intel_panel_get_max_backlight], max backlight PWM = 736950
[   94.800473] [drm:intel_panel_set_backlight], set backlight PWM = 72250
[   94.800477] [drm:intel_panel_get_max_backlight], max backlight PWM = 736950
[   94.800482] [drm:intel_opregion_asle_intr], non asle set request??
[   94.800485] [drm:intel_opregion_asle_intr], non asle set request??

[2.6.39 regression] i915/kms: garbled screen because of 49183b281 (was: Re: Linux 2.6.39-rc7)

[Melchior FRANZ]

* Linus Torvalds -- Tuesday 10 May 2011:
 But please do test, just to make sure that 39-final is good.

 Chris Wilson (4):
   drm/i915: Only enable the plane after setting the fb base (pre-ILK)

This patch introduces a bug on my infamous Acer Travelmate
5735Z-452G32Mnss: when KMS takes over, the frame buffer contents
get completely garbled up on screen, with colored stripes and
unreadable text (photo on request). Only when X11 is started, the
screen gets restored again. Closing and re-opening the lid partly
cures the mess, too: it makes the font readable, though horizontally
stretched.

Reverting 49183b2818de6899383bb82bc032f9344d6791ff fixes the
bug.

m.





drm.debug=0x02

[2.604831] [drm] Initialized drm 1.1.0 20060810
[2.648409] i915 :00:02.0: PCI INT A - GSI 16 (level, low) - IRQ 16
[2.648415] i915 :00:02.0: setting latency timer to 64
[2.708949] [drm:intel_opregion_setup], graphic opregion physical addr: 
0x7ba8c018
[2.708987] [drm:intel_opregion_setup], Public ACPI methods supported
[2.708989] [drm:intel_opregion_setup], SWSCI supported
[2.708991] [drm:intel_opregion_setup], ASLE supported
[2.709047] i915 :00:02.0: irq 44 for MSI/MSI-X
[2.709053] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[2.709054] [drm] Driver supports precise vblank timestamp query.
[2.735626] [drm:init_status_page], render ring hws offset: 0x
[2.735747] [drm:init_status_page], bsd ring hws offset: 0x00021000
[2.735852] [drm:intel_parse_bios], Using VBT from OpRegion: $VBT CANTIGA
d
[2.779279] [drm:intel_panel_get_backlight], get backlight PWM = 0
[2.779287] vgaarb: device changed decodes: 
PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
[2.779616] [drm:intel_panel_set_backlight], set backlight PWM = 0
[2.779619] [drm:intel_panel_get_max_backlight], max backlight PWM = 736950
[2.779626] [drm:intel_opregion_asle_intr], non asle set request??
[3.022059] [drm:gm45_get_vblank_counter], trying to get vblank count for 
disabled pipe A
[3.022065] [drm:gm45_get_vblank_counter], trying to get vblank count for 
disabled pipe A
[3.074270] checking generic (8000 3ff) vs hw (8000 1000)
[3.074274] fb: conflicting fb hw usage inteldrmfb vs VESA VGA - removing 
generic driver
[3.074293] Console: switching to colour dummy device 80x25
[3.074806] fbcon: inteldrmfb (fb0) is primary device
[3.109085] [drm:intel_panel_get_max_backlight], max backlight PWM = 736950
[3.109087] [drm:intel_panel_set_backlight], set backlight PWM = 736950
[3.109090] [drm:intel_panel_get_max_backlight], max backlight PWM = 736950
[3.109098] [drm:intel_opregion_asle_intr], non asle set request??
[3.109111] Console: switching to colour frame buffer device 170x48
[3.111779] fb0: inteldrmfb frame buffer device
[3.111780] drm: registered panic notifier
[3.158015] scsi 4:0:0:0: Direct-Access Generic- Multi-Card   1.00 
PQ: 0 ANSI: 0 CCS
[3.413081] acpi device:07: registered as cooling_device2
[3.413431] input: Video Bus as 
/devices/LNXSYSTM:00/device:00/PNP0A08:00/LNXVIDEO:01/input/input6
[3.413532] ACPI: Video Device [OVGA] (multi-head: yes  rom: no  post: no)
[3.413982] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on minor 0
[4.059019] sd 4:0:0:0: [sdb] 15720448 512-byte logical blocks: (8.04 
GB/7.49 GiB)
[4.059746] sd 4:0:0:0: [sdb] Write Protect is off
[4.059750] sd 4:0:0:0: [sdb] Mode Sense: 03 00 00 00
[4.059752] sd 4:0:0:0: [sdb] Assuming drive cache: write through
[4.061879] sd 4:0:0:0: [sdb] Assuming drive cache: write through
[4.066269]  sdb: sdb1
[4.067995] sd 4:0:0:0: [sdb] Assuming drive cache: write through
[4.068056] sd 4:0:0:0: [sdb] Attached SCSI removable disk
[5.016884] md: linear personality registered for level -1
[   94.800469] [drm:intel_panel_get_max_backlight], max backlight PWM = 736950
[   94.800473] [drm:intel_panel_set_backlight], set backlight PWM = 72250
[   94.800477] [drm:intel_panel_get_max_backlight], max backlight PWM = 736950
[   94.800482] [drm:intel_opregion_asle_intr], non asle set request??
[   94.800485] [drm:intel_opregion_asle_intr], non asle set request??
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

i915/kms/backlight-combo mode problem

[Melchior FRANZ]

* Michael Chang -- Tuesday 10 May 2011:
> Could you please try this patch and get the log ? We wonder why
> is_backlight_combination_mode () returns false.

This information was already buried in the bugzilla thread:

  https://bugzilla.kernel.org/show_bug.cgi?id=31522
  "It turned out that on this machine INTEL_INFO(dev)->gen equals 4,
  and is_backlight_combination_mode() returns 0x4000."


But to say it again in your words:   :-)

  [drm:is_backlight_combination_mode], BLM_COMBINATION_MODE = 1073741824  
(0x4000)

6x during boot-up, and several times later when changing the backlight
brightness.


This was with 8b061610dac3a3b89770c85ad63b481a47b0c38e. And now
I have a little shocker for you (and me): because this was a
vanilla kernel (apart from these debug messages), the screen went
black again, like I knew it. But pressing the "brightness down"
key turns the backlight on! I can't believe that I haven't tested
that. I guess I've only tried "brightness up" and "display toggle".
Those don't turn backlight on. Or maybe somethine else relevant
meanwhile changed in the i915 drivers. (I've regularly been
updating to HEAD.)  

So, the problem was just the initial state all the time?

m.

Re: i915/kms/backlight-combo mode problem

[Melchior FRANZ]

* Michael Chang -- Tuesday 10 May 2011:
 Could you please try this patch and get the log ? We wonder why
 is_backlight_combination_mode () returns false.

This information was already buried in the bugzilla thread:

  https://bugzilla.kernel.org/show_bug.cgi?id=31522
  It turned out that on this machine INTEL_INFO(dev)-gen equals 4,
  and is_backlight_combination_mode() returns 0x4000.


But to say it again in your words:   :-)

  [drm:is_backlight_combination_mode], BLM_COMBINATION_MODE = 1073741824  
(0x4000)

6x during boot-up, and several times later when changing the backlight
brightness.


This was with 8b061610dac3a3b89770c85ad63b481a47b0c38e. And now
I have a little shocker for you (and me): because this was a
vanilla kernel (apart from these debug messages), the screen went
black again, like I knew it. But pressing the brightness down
key turns the backlight on! I can't believe that I haven't tested
that. I guess I've only tried brightness up and display toggle.
Those don't turn backlight on. Or maybe somethine else relevant
meanwhile changed in the i915 drivers. (I've regularly been
updating to HEAD.)  

So, the problem was just the initial state all the time?

m.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

i915/kms/backlight-combo mode problem

[Melchior FRANZ]

* Joey Lee -- Monday 09 May 2011:
> The following is debug patch, and please add kernel parameter
> drm.debug=0x02 :

The result is with acpi_osi=Linux:


boot phase:
[3.310274] [drm:intel_panel_get_backlight], get backlight val = 2890
[3.310280] [drm:intel_panel_get_backlight], get backlight PWM = 2890
[3.310615] [drm:intel_panel_get_backlight], get backlight val = 2890
[3.310617] [drm:intel_panel_get_backlight], get backlight PWM = 2890
[3.310619] [drm:intel_panel_set_backlight], set backlight PWM = 0
[3.310622] [drm:intel_panel_set_backlight], set backlight tmp(1) = 189401930
[3.310624] [drm:intel_panel_set_backlight], set backlight tmp(2) = 189399040
[3.310626] [drm:intel_panel_set_backlight], set backlight level = 0

[3.641522] [drm:intel_panel_set_backlight], set backlight PWM = 2890
[3.641525] [drm:intel_panel_set_backlight], set backlight tmp(1) = 189399040
[3.641527] [drm:intel_panel_set_backlight], set backlight tmp(2) = 189399040
[3.641529] [drm:intel_panel_set_backlight], set backlight level = 2890

[   11.410563] video LNXVIDEO:01: Restoring backlight state



brightness up:
   [no output]



brightness down:
[  152.697127] [drm:intel_panel_get_max_backlight], max backlight PWM = 2890
[  152.697136] [drm:intel_panel_set_backlight], set backlight PWM = 283
[  152.697141] [drm:intel_panel_set_backlight], set backlight tmp(1) = 189401930
[  152.697146] [drm:intel_panel_set_backlight], set backlight tmp(2) = 189399040
[  152.697150] [drm:intel_panel_set_backlight], set backlight level = 283

[  166.720631] [drm:intel_panel_get_max_backlight], max backlight PWM = 2890
[  166.720640] [drm:intel_panel_set_backlight], set backlight PWM = 578
[  166.720645] [drm:intel_panel_set_backlight], set backlight tmp(1) = 189399323
[  166.720649] [drm:intel_panel_set_backlight], set backlight tmp(2) = 189399040
[  166.720654] [drm:intel_panel_set_backlight], set backlight level = 578

[  178.091776] [drm:intel_panel_get_max_backlight], max backlight PWM = 2890
[  178.091784] [drm:intel_panel_set_backlight], set backlight PWM = 861
[  178.091789] [drm:intel_panel_set_backlight], set backlight tmp(1) = 189399618
[  178.091793] [drm:intel_panel_set_backlight], set backlight tmp(2) = 189399040
[  178.091797] [drm:intel_panel_set_backlight], set backlight level = 861

[  188.888370] [drm:intel_panel_get_max_backlight], max backlight PWM = 2890
[  188.888379] [drm:intel_panel_set_backlight], set backlight PWM = 1156
[  188.888383] [drm:intel_panel_set_backlight], set backlight tmp(1) = 189399901
[  188.888388] [drm:intel_panel_set_backlight], set backlight tmp(2) = 189399040
[  188.888392] [drm:intel_panel_set_backlight], set backlight level = 1156

[  196.411657] [drm:intel_panel_get_max_backlight], max backlight PWM = 2890
[  196.411665] [drm:intel_panel_set_backlight], set backlight PWM = 1439
[  196.411670] [drm:intel_panel_set_backlight], set backlight tmp(1) = 189400196
[  196.411674] [drm:intel_panel_set_backlight], set backlight tmp(2) = 189399040
[  196.411678] [drm:intel_panel_set_backlight], set backlight level = 1439

[  201.256229] [drm:intel_panel_get_max_backlight], max backlight PWM = 2890
[  201.256238] [drm:intel_panel_set_backlight], set backlight PWM = 1734
[  201.256243] [drm:intel_panel_set_backlight], set backlight tmp(1) = 189400479
[  201.256247] [drm:intel_panel_set_backlight], set backlight tmp(2) = 189399040
[  201.256252] [drm:intel_panel_set_backlight], set backlight level = 1734

[  206.939838] [drm:intel_panel_get_max_backlight], max backlight PWM = 2890
[  206.939846] [drm:intel_panel_set_backlight], set backlight PWM = 2017
[  206.939851] [drm:intel_panel_set_backlight], set backlight tmp(1) = 189400774
[  206.939856] [drm:intel_panel_set_backlight], set backlight tmp(2) = 189399040
[  206.939860] [drm:intel_panel_set_backlight], set backlight level = 2017

[  213.779732] [drm:intel_panel_get_max_backlight], max backlight PWM = 2890
[  213.779740] [drm:intel_panel_set_backlight], set backlight PWM = 2312
[  213.779744] [drm:intel_panel_set_backlight], set backlight tmp(1) = 189401057
[  213.779749] [drm:intel_panel_set_backlight], set backlight tmp(2) = 189399040
[  213.779753] [drm:intel_panel_set_backlight], set backlight level = 2312

[  222.583806] [drm:intel_panel_get_max_backlight], max backlight PWM = 2890
[  222.583814] [drm:intel_panel_set_backlight], set backlight PWM = 2595
[  222.583819] [drm:intel_panel_set_backlight], set backlight tmp(1) = 189401352
[  222.583824] [drm:intel_panel_set_backlight], set backlight tmp(2) = 189399040
[  222.583828] [drm:intel_panel_set_backlight], set backlight level = 2595

[  229.345860] [drm:intel_panel_get_max_backlight], max backlight PWM = 2890
[  229.345870] [drm:intel_panel_set_backlight], set backlight PWM = 2595
[  229.345874] [drm:intel_panel_set_backlight], set backlight tmp(1) = 189401635
[  229.345879] [drm:intel_panel_set_backlight], set backlight tmp(2) = 189399040
[  

Re: i915/kms/backlight-combo mode problem

[Melchior FRANZ]

* Joey Lee -- Monday 09 May 2011:
 The following is debug patch, and please add kernel parameter
 drm.debug=0x02 :

The result is with acpi_osi=Linux:


boot phase:
[3.310274] [drm:intel_panel_get_backlight], get backlight val = 2890
[3.310280] [drm:intel_panel_get_backlight], get backlight PWM = 2890
[3.310615] [drm:intel_panel_get_backlight], get backlight val = 2890
[3.310617] [drm:intel_panel_get_backlight], get backlight PWM = 2890
[3.310619] [drm:intel_panel_set_backlight], set backlight PWM = 0
[3.310622] [drm:intel_panel_set_backlight], set backlight tmp(1) = 189401930
[3.310624] [drm:intel_panel_set_backlight], set backlight tmp(2) = 189399040
[3.310626] [drm:intel_panel_set_backlight], set backlight level = 0

[3.641522] [drm:intel_panel_set_backlight], set backlight PWM = 2890
[3.641525] [drm:intel_panel_set_backlight], set backlight tmp(1) = 189399040
[3.641527] [drm:intel_panel_set_backlight], set backlight tmp(2) = 189399040
[3.641529] [drm:intel_panel_set_backlight], set backlight level = 2890

[   11.410563] video LNXVIDEO:01: Restoring backlight state



brightness up:
   [no output]



brightness down:
[  152.697127] [drm:intel_panel_get_max_backlight], max backlight PWM = 2890
[  152.697136] [drm:intel_panel_set_backlight], set backlight PWM = 283
[  152.697141] [drm:intel_panel_set_backlight], set backlight tmp(1) = 189401930
[  152.697146] [drm:intel_panel_set_backlight], set backlight tmp(2) = 189399040
[  152.697150] [drm:intel_panel_set_backlight], set backlight level = 283

[  166.720631] [drm:intel_panel_get_max_backlight], max backlight PWM = 2890
[  166.720640] [drm:intel_panel_set_backlight], set backlight PWM = 578
[  166.720645] [drm:intel_panel_set_backlight], set backlight tmp(1) = 189399323
[  166.720649] [drm:intel_panel_set_backlight], set backlight tmp(2) = 189399040
[  166.720654] [drm:intel_panel_set_backlight], set backlight level = 578

[  178.091776] [drm:intel_panel_get_max_backlight], max backlight PWM = 2890
[  178.091784] [drm:intel_panel_set_backlight], set backlight PWM = 861
[  178.091789] [drm:intel_panel_set_backlight], set backlight tmp(1) = 189399618
[  178.091793] [drm:intel_panel_set_backlight], set backlight tmp(2) = 189399040
[  178.091797] [drm:intel_panel_set_backlight], set backlight level = 861

[  188.888370] [drm:intel_panel_get_max_backlight], max backlight PWM = 2890
[  188.888379] [drm:intel_panel_set_backlight], set backlight PWM = 1156
[  188.888383] [drm:intel_panel_set_backlight], set backlight tmp(1) = 189399901
[  188.888388] [drm:intel_panel_set_backlight], set backlight tmp(2) = 189399040
[  188.888392] [drm:intel_panel_set_backlight], set backlight level = 1156

[  196.411657] [drm:intel_panel_get_max_backlight], max backlight PWM = 2890
[  196.411665] [drm:intel_panel_set_backlight], set backlight PWM = 1439
[  196.411670] [drm:intel_panel_set_backlight], set backlight tmp(1) = 189400196
[  196.411674] [drm:intel_panel_set_backlight], set backlight tmp(2) = 189399040
[  196.411678] [drm:intel_panel_set_backlight], set backlight level = 1439

[  201.256229] [drm:intel_panel_get_max_backlight], max backlight PWM = 2890
[  201.256238] [drm:intel_panel_set_backlight], set backlight PWM = 1734
[  201.256243] [drm:intel_panel_set_backlight], set backlight tmp(1) = 189400479
[  201.256247] [drm:intel_panel_set_backlight], set backlight tmp(2) = 189399040
[  201.256252] [drm:intel_panel_set_backlight], set backlight level = 1734

[  206.939838] [drm:intel_panel_get_max_backlight], max backlight PWM = 2890
[  206.939846] [drm:intel_panel_set_backlight], set backlight PWM = 2017
[  206.939851] [drm:intel_panel_set_backlight], set backlight tmp(1) = 189400774
[  206.939856] [drm:intel_panel_set_backlight], set backlight tmp(2) = 189399040
[  206.939860] [drm:intel_panel_set_backlight], set backlight level = 2017

[  213.779732] [drm:intel_panel_get_max_backlight], max backlight PWM = 2890
[  213.779740] [drm:intel_panel_set_backlight], set backlight PWM = 2312
[  213.779744] [drm:intel_panel_set_backlight], set backlight tmp(1) = 189401057
[  213.779749] [drm:intel_panel_set_backlight], set backlight tmp(2) = 189399040
[  213.779753] [drm:intel_panel_set_backlight], set backlight level = 2312

[  222.583806] [drm:intel_panel_get_max_backlight], max backlight PWM = 2890
[  222.583814] [drm:intel_panel_set_backlight], set backlight PWM = 2595
[  222.583819] [drm:intel_panel_set_backlight], set backlight tmp(1) = 189401352
[  222.583824] [drm:intel_panel_set_backlight], set backlight tmp(2) = 189399040
[  222.583828] [drm:intel_panel_set_backlight], set backlight level = 2595

[  229.345860] [drm:intel_panel_get_max_backlight], max backlight PWM = 2890
[  229.345870] [drm:intel_panel_set_backlight], set backlight PWM = 2595
[  229.345874] [drm:intel_panel_set_backlight], set backlight tmp(1) = 189401635
[  229.345879] [drm:intel_panel_set_backlight], set backlight tmp(2) = 189399040
[  229.345883] 

i915/kms/backlight-combo mode problem

[Melchior FRANZ]

* Joey Lee -- Sunday 08 May 2011:
> ? ??2011-05-07 ? 22:22 +0200?Melchior FRANZ ???
> > It has turned out that acpi key events seem to be handled correctly
> > and even the state of /sys/class/backlight/acer-wmi/brightness is
> 
> That's interesting for acer-wmi generated brightness interface when this
> machine declare acpi brightness interface in DSDT.

I'm sorry to give contradicting info. Yesterday I saw a subdir acer-wmi
(or acer_wmi) in /sys/class/backlight/ during one of my tests (with/without
acer_wmi, with/without acpi_osi=Linux). Now I left acpi_osi=Linux
away and allow acer_wmi, and it's subdir acpi_video0. Next time I'll
make notes.



> Does it work to you direct control brightness by access
> by /sys/class/backlight/acer-wmi/brightness ?

No. A number written to this virtual file is accepted and remembered,
but it doesn't actually change the brightness. It takes setpci to do
that. 



> As I remember, use setpci to control brightness is not recommended
> because BIOS or ACPI will also touch brightness level. That will be
> better control brightness by the function that was provided by BIOS. 
> e.g. ACPI or WMI interface, or direct control by EC.

Well, sounds plausible. And I wouldn't do it if it weren't the only
way at the moment.  :-)



> That means that will be better fix your Fn key control brightness like
> before, you just need press Fn key to change brightness and don't need
> have any workaround.

OK. I have added a lot of debug messages to intel_panel.c yesterday.
All it told me was that it seems to work correctly wiht acpi_osi=Linux.
Except that it doesn't actually change the brightness. Without acpi_osi
the functions aren't called at all and none of my messages showed up.



> Looks like current status is we try to fix bko#31522 but the patch
> causes your brightness no work by press Fn key even with acpi_osi=Linux.
> Does it right?

The history is: with acpi_osi=Linux everything worked with 2.6.38-rc8.
With 2.6.38 the screen stayed black. The patch that only ignored lbpc=0
worked (IIRC) including key adjustment. Later patches broke keys.



>   replace acpi_osi=Linux by acpi_osi="!Windows 2006"
> 
> Does it also works to you for backlight control?

No, doesn't work.

m.

Re: i915/kms/backlight-combo mode problem

[Melchior FRANZ]

* Joey Lee -- Sunday 08 May 2011:
 於 六，2011-05-07 於 22:22 +0200，Melchior FRANZ 提到：
  It has turned out that acpi key events seem to be handled correctly
  and even the state of /sys/class/backlight/acer-wmi/brightness is
 
 That's interesting for acer-wmi generated brightness interface when this
 machine declare acpi brightness interface in DSDT.

I'm sorry to give contradicting info. Yesterday I saw a subdir acer-wmi
(or acer_wmi) in /sys/class/backlight/ during one of my tests (with/without
acer_wmi, with/without acpi_osi=Linux). Now I left acpi_osi=Linux
away and allow acer_wmi, and it's subdir acpi_video0. Next time I'll
make notes.



 Does it work to you direct control brightness by access
 by /sys/class/backlight/acer-wmi/brightness ?

No. A number written to this virtual file is accepted and remembered,
but it doesn't actually change the brightness. It takes setpci to do
that. 


 
 As I remember, use setpci to control brightness is not recommended
 because BIOS or ACPI will also touch brightness level. That will be
 better control brightness by the function that was provided by BIOS. 
 e.g. ACPI or WMI interface, or direct control by EC.

Well, sounds plausible. And I wouldn't do it if it weren't the only
way at the moment.  :-)



 That means that will be better fix your Fn key control brightness like
 before, you just need press Fn key to change brightness and don't need
 have any workaround.

OK. I have added a lot of debug messages to intel_panel.c yesterday.
All it told me was that it seems to work correctly wiht acpi_osi=Linux.
Except that it doesn't actually change the brightness. Without acpi_osi
the functions aren't called at all and none of my messages showed up.



 Looks like current status is we try to fix bko#31522 but the patch
 causes your brightness no work by press Fn key even with acpi_osi=Linux.
 Does it right?

The history is: with acpi_osi=Linux everything worked with 2.6.38-rc8.
With 2.6.38 the screen stayed black. The patch that only ignored lbpc=0
worked (IIRC) including key adjustment. Later patches broke keys.



   replace acpi_osi=Linux by acpi_osi=!Windows 2006
 
 Does it also works to you for backlight control?

No, doesn't work.

m.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

i915/kms/backlight-combo mode problem

[Melchior FRANZ]

* Melchior FRANZ -- Friday 06 May 2011:
> last patch prevents the backlight from being turned off, but it also
> breaks the brightness adjustment keys at runtime with acpi_osi=Linux.

It has turned out that acpi key events seem to be handled correctly
and even the state of /sys/class/backlight/acer-wmi/brightness is
updated accordingly. The only problem is that this maintained
brightness state isn't applied to the actual backlight. It remains
at highest level. Google pointed me to this workaround for another
Acer notebook:

  
https://help.ubuntu.com/community/AspireTimeline/Fixes#Alternative%20fix%20for%2010.10

This uses the acpid to write the brightness value to the display
using setpci. And this works on my notebook as well (Acer Travelmate
5735Z-452G32Mnss). Not pretty but better than nothing. Is Acer
not able to build proper notebooks? Or is it a kernel bug?

m.

Re: i915/kms/backlight-combo mode problem

[Melchior FRANZ]

* Melchior FRANZ -- Friday 06 May 2011:
 last patch prevents the backlight from being turned off, but it also
 breaks the brightness adjustment keys at runtime with acpi_osi=Linux.

It has turned out that acpi key events seem to be handled correctly
and even the state of /sys/class/backlight/acer-wmi/brightness is
updated accordingly. The only problem is that this maintained
brightness state isn't applied to the actual backlight. It remains
at highest level. Google pointed me to this workaround for another
Acer notebook:

  
https://help.ubuntu.com/community/AspireTimeline/Fixes#Alternative%20fix%20for%2010.10

This uses the acpid to write the brightness value to the display
using setpci. And this works on my notebook as well (Acer Travelmate
5735Z-452G32Mnss). Not pretty but better than nothing. Is Acer
not able to build proper notebooks? Or is it a kernel bug?

m.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

i915/kms/backlight-combo mode problem

[Melchior FRANZ]

* Joey Lee -- Friday 06 May 2011:
> ? ??2011-05-06 ? 10:52 +0200?Melchior FRANZ ???
> > ... and changing backlight brightness worked with acpi_osi=Linux, too.
> > Unfortunately, that does no longer work now, although I haven't changed
> > anything. Pressing the brightness buttons causes some ACPI debug output,
> > but it doesn't adjust anything.

> hmm Takashi's patch works before, but doesn't work now?

Argh ... sorry Takashi. Joey is right. I thought I had tested that,
but apparently not. Indeed, your last patch prevents the backlight
from being turned off, but it also breaks the brightness adjustment
keys at runtime with acpi_osi=Linux. And without that it doesn't
work, anyway, just like before. I'll add some more debug messages ...



> Does that because my new patch for bko#34142 ? Could you please add
> acer-wmi to /etc/modprobe.d/blacklist then reboot machine ?

Done. No, your patch is not involved. But backing out Takashi's
patch and re-applying confirmed that it's that patch.

m.

Re: i915/kms/backlight-combo mode problem

[Melchior FRANZ]

* Melchior FRANZ -- Thursday 05 May 2011:
 This revised patch works correctly for me.

... and changing backlight brightness worked with acpi_osi=Linux, too.
Unfortunately, that does no longer work now, although I haven't changed
anything. Pressing the brightness buttons causes some ACPI debug output,
but it doesn't adjust anything.

m. 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: i915/kms/backlight-combo mode problem

[Melchior FRANZ]

* Joey Lee -- Friday 06 May 2011:
 於 五，2011-05-06 於 10:52 +0200，Melchior FRANZ 提到：
  ... and changing backlight brightness worked with acpi_osi=Linux, too.
  Unfortunately, that does no longer work now, although I haven't changed
  anything. Pressing the brightness buttons causes some ACPI debug output,
  but it doesn't adjust anything.

 hmm Takashi's patch works before, but doesn't work now?

Argh ... sorry Takashi. Joey is right. I thought I had tested that,
but apparently not. Indeed, your last patch prevents the backlight
from being turned off, but it also breaks the brightness adjustment
keys at runtime with acpi_osi=Linux. And without that it doesn't
work, anyway, just like before. I'll add some more debug messages ...



 Does that because my new patch for bko#34142 ? Could you please add
 acer-wmi to /etc/modprobe.d/blacklist then reboot machine ?

Done. No, your patch is not involved. But backing out Takashi's
patch and re-applying confirmed that it's that patch.

m.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

i915/kms/backlight-combo mode problem (was: Re: Linux 2.6.39-rc5)

[Melchior FRANZ]

* Takashi Iwai -- Thursday 05 May 2011:
> Try the fixed patch below.

> ---
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 456f404..4c6e187 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -332,6 +332,7 @@ typedef struct drm_i915_private {
>   struct intel_overlay *overlay;
>  
>   /* LVDS info */
> + int backlight_combination_mode; /* 0=unknown, -1=no, 1=yes */
>   int backlight_level;  /* restore backlight to this value */
>   bool backlight_enabled;
>   struct drm_display_mode *panel_fixed_mode;
> diff --git a/drivers/gpu/drm/i915/intel_panel.c 
> b/drivers/gpu/drm/i915/intel_panel.c
> index f8f86e5..5a6be04 100644
> --- a/drivers/gpu/drm/i915/intel_panel.c
> +++ b/drivers/gpu/drm/i915/intel_panel.c
> @@ -115,14 +115,24 @@ done:
>  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;
> + int combo_mode;
> + u8 lbpc;
> +
> + if (dev_priv->backlight_combination_mode)
> + return dev_priv->backlight_combination_mode > 0;
> +
> + pci_read_config_byte(dev->pdev, PCI_LBPC, );
> + if (!lbpc)
> + combo_mode = 0;
> + else if (INTEL_INFO(dev)->gen >= 4)
> + combo_mode = I915_READ(BLC_PWM_CTL2) & BLM_COMBINATION_MODE;
> + else if (IS_GEN2(dev))
> + combo_mode = I915_READ(BLC_PWM_CTL) & BLM_LEGACY_MODE;
> + else
> + combo_mode = 0;
> +
> + dev_priv->backlight_combination_mode = combo_mode ? 1 : -1;
> + return combo_mode;
>  }
>  
>  static u32 i915_read_blc_pwm_ctl(struct drm_i915_private *dev_priv)

The first patch had a problem. Without the lbpc check for zero the backlight
still stayed off and could only be activated with the brightness-down key.
This revised patch works correctly for me. Thanks!

m.

Re: i915/kms/backlight-combo mode problem (was: Re: Linux 2.6.39-rc5)

[Melchior FRANZ]

* Takashi Iwai -- Thursday 05 May 2011:
 Try the fixed patch below.

 ---
 diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
 index 456f404..4c6e187 100644
 --- a/drivers/gpu/drm/i915/i915_drv.h
 +++ b/drivers/gpu/drm/i915/i915_drv.h
 @@ -332,6 +332,7 @@ typedef struct drm_i915_private {
   struct intel_overlay *overlay;
  
   /* LVDS info */
 + int backlight_combination_mode; /* 0=unknown, -1=no, 1=yes */
   int backlight_level;  /* restore backlight to this value */
   bool backlight_enabled;
   struct drm_display_mode *panel_fixed_mode;
 diff --git a/drivers/gpu/drm/i915/intel_panel.c 
 b/drivers/gpu/drm/i915/intel_panel.c
 index f8f86e5..5a6be04 100644
 --- a/drivers/gpu/drm/i915/intel_panel.c
 +++ b/drivers/gpu/drm/i915/intel_panel.c
 @@ -115,14 +115,24 @@ done:
  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;
 + int combo_mode;
 + u8 lbpc;
 +
 + if (dev_priv-backlight_combination_mode)
 + return dev_priv-backlight_combination_mode  0;
 +
 + pci_read_config_byte(dev-pdev, PCI_LBPC, lbpc);
 + if (!lbpc)
 + combo_mode = 0;
 + else if (INTEL_INFO(dev)-gen = 4)
 + combo_mode = I915_READ(BLC_PWM_CTL2)  BLM_COMBINATION_MODE;
 + else if (IS_GEN2(dev))
 + combo_mode = I915_READ(BLC_PWM_CTL)  BLM_LEGACY_MODE;
 + else
 + combo_mode = 0;
 +
 + dev_priv-backlight_combination_mode = combo_mode ? 1 : -1;
 + return combo_mode;
  }
  
  static u32 i915_read_blc_pwm_ctl(struct drm_i915_private *dev_priv)

The first patch had a problem. Without the lbpc check for zero the backlight
still stayed off and could only be activated with the brightness-down key.
This revised patch works correctly for me. Thanks!

m.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

i915/kms/backlight-combo mode problem (was: Re: Linux 2.6.39-rc5)

[Melchior FRANZ]

* Takashi Iwai -- Monday 02 May 2011:
* > At Sat, 30 Apr 2011 13:34:51 +0200, Melchior FRANZ wrote:
> > * Takashi Iwai -- Saturday 30 April 2011:
> > > acpi_osi quirk should be better added statically, then.
> > 
> > No, I guess the problem here is that acer_wmi doesn't support this
> > machine yet.

> Hm, but the backlight control is done via the standard ACPI, no?

I have no idea. If I were an expert, I would just have sent a
patch, not a bug report. And I prefer fixes to "quirks".  :-P



> BTW, did you try my previous patch?

Works. I hadn't tested it before, because you seemed to wait
for the opinion of some Intel people, and so did I. But thanks
for that code!

m.

Re: i915/kms/backlight-combo mode problem (was: Re: Linux 2.6.39-rc5)

[Melchior FRANZ]

* Takashi Iwai -- Monday 02 May 2011:
*  At Sat, 30 Apr 2011 13:34:51 +0200, Melchior FRANZ wrote:
  * Takashi Iwai -- Saturday 30 April 2011:
   acpi_osi quirk should be better added statically, then.
  
  No, I guess the problem here is that acer_wmi doesn't support this
  machine yet.

 Hm, but the backlight control is done via the standard ACPI, no?

I have no idea. If I were an expert, I would just have sent a
patch, not a bug report. And I prefer fixes to quirks.  :-P



 BTW, did you try my previous patch?

Works. I hadn't tested it before, because you seemed to wait
for the opinion of some Intel people, and so did I. But thanks
for that code!

m.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

i915/kms/backlight-combo mode problem (was: Re: Linux 2.6.39-rc5)

[Melchior FRANZ]

Dropping Linus from the CC.


* Takashi Iwai -- Saturday 30 April 2011:
* * At Sat, 30 Apr 2011 10:32:04 +0200, Melchior FRANZ wrote:
> > Yes, backlight adjustment generally works on this notebook, but only
> > with "acpi_osi=Linux" on the command line.
> 
> acpi_osi quirk should be better added statically, then.

No, I guess the problem here is that acer_wmi doesn't support this
machine yet. I told the ACER WMI maintainer and sent a DSDT image,
but this message was thoroughly ignored.


  $ dmesg|grep -i acer
  [0.00] DMI: Acer TM5735/BA51_MV, BIOS V1.04 09/23/2010
  [   71.850534] acer_wmi: Acer Laptop ACPI-WMI Extras
  [   72.350278] acer_wmi: Unable to detect available WMID devices

  Machine: Acer Travelmate 5735Z-452G32Mnss

m.

i915/kms/backlight-combo mode problem (was: Re: Linux 2.6.39-rc5)

[Melchior FRANZ]

* Takashi Iwai -- Saturday 30 April 2011:
> I remember vaguely that the value zero could be interpreted as the max.

> Also, with the patch, does the backlight level can be adjusted
> correctly to different values?  I wonder whether LBPC adjustment
> really works or not on your machine.

> + if (!lbpc)
> + lbpc = 0xff; /* max value */

This change does *not* work on my machine. The screen stays black
again.

Yes, backlight adjustment generally works on this notebook, but only
with "acpi_osi=Linux" on the command line.

m.

Re: i915/kms/backlight-combo mode problem (was: Re: Linux 2.6.39-rc5)

[Melchior FRANZ]

* Takashi Iwai -- Saturday 30 April 2011:
 I remember vaguely that the value zero could be interpreted as the max.

 Also, with the patch, does the backlight level can be adjusted
 correctly to different values?  I wonder whether LBPC adjustment
 really works or not on your machine.

 + if (!lbpc)
 + lbpc = 0xff; /* max value */

This change does *not* work on my machine. The screen stays black
again.

Yes, backlight adjustment generally works on this notebook, but only
with acpi_osi=Linux on the command line.

m.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: i915/kms/backlight-combo mode problem (was: Re: Linux 2.6.39-rc5)

[Melchior FRANZ]

Dropping Linus from the CC.


* Takashi Iwai -- Saturday 30 April 2011:
* * At Sat, 30 Apr 2011 10:32:04 +0200, Melchior FRANZ wrote:
  Yes, backlight adjustment generally works on this notebook, but only
  with acpi_osi=Linux on the command line.
 
 acpi_osi quirk should be better added statically, then.

No, I guess the problem here is that acer_wmi doesn't support this
machine yet. I told the ACER WMI maintainer and sent a DSDT image,
but this message was thoroughly ignored.


  $ dmesg|grep -i acer
  [0.00] DMI: Acer TM5735/BA51_MV, BIOS V1.04 09/23/2010
  [   71.850534] acer_wmi: Acer Laptop ACPI-WMI Extras
  [   72.350278] acer_wmi: Unable to detect available WMID devices
  
  Machine: Acer Travelmate 5735Z-452G32Mnss

m.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

i915/kms/backlight-combo mode problem (was: Re: Linux 2.6.39-rc5)

[Melchior FRANZ]

* Takashi Iwai -- Friday 29 April 2011:
[https://bugzilla.kernel.org/show_bug.cgi?id=31522]
> Looking at bugzilla, the problem seems like the case lbpc=0.
> What about the patch below instead?

> - val *= lbpc;
> + if (lbpc)
> + val *= lbpc;

Yes, that works as well. (I had assumed that this was the problem,
but wasn't sure if a zero was even a legitimate value, or rather
a sign for a problem or wrong assumption elsewhere.)

m.

i915/kms/backlight-combo mode problem (was: Re: Linux 2.6.39-rc5)

[Melchior FRANZ]

* Takashi Iwai -- Friday 29 April 2011:
> Melchior FRANZ wrote:
> > The bug was introduced with commit ba3820ade317ee36e496b9b40d2ec3987dd4aef0
> > [...] when using KMS my notebook's[2] screen remains dark, because the
> > backlight isn't turned on.

> Could you check whether the patch below changes the behavior?
> If this cures, it means that the backlight-combo mode doesn't work on
> your machine.

Yes, that works. (Test was with fafc9929c668f8bae6dd1f109f33a86d2cb3c460,
which is current HEAD.)

m.

Linux 2.6.39-rc5

[Melchior FRANZ]

* Linus Torvalds -- Wednesday 27 April 2011:
> Go forth and test,

Doesn't work on my notebook with i915/KMS. But then again, neither did
2.6.38 or any of its stable releases. The last working version was
2.6.38-rc8. The problem has been reported[1], but the bug got closed
in the wrong assumption that the bug is fixed. I reported that, too.
No reactions to that.

The bug was introduced with commit ba3820ade317ee36e496b9b40d2ec3987dd4aef0
by Takashi Iwai. The result is that when using KMS my notebook's[2] screen
remains dark, because the backlight isn't turned on.

Reverting commit ba3820ade317ee36e496b9b40d2ec3987dd4aef0 makes my
notebook work correctly again as it used to in 2.6.38-rc8 and before.

m.



[1] https://bugzilla.kernel.org/show_bug.cgi?id=31522
[2] Acer TravelMate 5735Z-452G32Mnss, using Intel GM45

Re: Linux 2.6.39-rc5

[Melchior FRANZ]

* Linus Torvalds -- Wednesday 27 April 2011:
 Go forth and test,

Doesn't work on my notebook with i915/KMS. But then again, neither did
2.6.38 or any of its stable releases. The last working version was
2.6.38-rc8. The problem has been reported[1], but the bug got closed
in the wrong assumption that the bug is fixed. I reported that, too.
No reactions to that.

The bug was introduced with commit ba3820ade317ee36e496b9b40d2ec3987dd4aef0
by Takashi Iwai. The result is that when using KMS my notebook's[2] screen
remains dark, because the backlight isn't turned on.

Reverting commit ba3820ade317ee36e496b9b40d2ec3987dd4aef0 makes my
notebook work correctly again as it used to in 2.6.38-rc8 and before.

m.



[1] https://bugzilla.kernel.org/show_bug.cgi?id=31522
[2] Acer TravelMate 5735Z-452G32Mnss, using Intel GM45
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

i915/kms/backlight-combo mode problem (was: Re: Linux 2.6.39-rc5)

[Melchior FRANZ]

* Takashi Iwai -- Friday 29 April 2011:
 Melchior FRANZ wrote:
  The bug was introduced with commit ba3820ade317ee36e496b9b40d2ec3987dd4aef0
  [...] when using KMS my notebook's[2] screen remains dark, because the
  backlight isn't turned on.

 Could you check whether the patch below changes the behavior?
 If this cures, it means that the backlight-combo mode doesn't work on
 your machine.

Yes, that works. (Test was with fafc9929c668f8bae6dd1f109f33a86d2cb3c460,
which is current HEAD.)

m.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: i915/kms/backlight-combo mode problem (was: Re: Linux 2.6.39-rc5)

[Melchior FRANZ]

* Takashi Iwai -- Friday 29 April 2011:
[https://bugzilla.kernel.org/show_bug.cgi?id=31522]
 Looking at bugzilla, the problem seems like the case lbpc=0.
 What about the patch below instead?

 - val *= lbpc;
 + if (lbpc)
 + val *= lbpc;

Yes, that works as well. (I had assumed that this was the problem,
but wasn't sure if a zero was even a legitimate value, or rather
a sign for a problem or wrong assumption elsewhere.)

m.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

i915 completely unusable in 2.6.38.x

[Melchior FRANZ]

* Melchior FRANZ -- Tuesday 26 April 2011:
> [https://bugzilla.kernel.org/show_bug.cgi?id=31522]

I've replied to this error message, but here again for this audience:
The commit that broke all 2.6.38.* releases for my machine is this:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=ba3820ade317ee36e496b9b40d2ec3987dd4aef0
(Takashi Iwai: "drm/i915: Revive combination mode for backlight
control").

In 'is_backlight_combination_mode()' INTEL_INFO(dev)->gen
equals 4, and the function returns 0x4000 in "combination mode".
In 'intel_panel_get_backlight()' this happens:


  val = I915_READ(BLC_PWM_CTL) & BACKLIGHT_DUTY_CYCLE_MASK; // val = 0x0b4a
  if (IS_PINEVIEW(dev)) // false
  val >>= 1;

  if (is_backlight_combination_mode(dev)){
  u8 lbpc;

  val &= ~1;// val = 0x0b4a
  pci_read_config_byte(dev->pdev, PCI_LBPC, ); // lbpc = 0
  val *= lbpc;  // val = 0
  }


The backlight remains off and does also not react to the "brighter" key
event.

Reverting the patch fixes my system, obviously.

m.

Re: i915 completely unusable in 2.6.38.x

[Melchior FRANZ]

* Melchior FRANZ -- Tuesday 26 April 2011:
 [https://bugzilla.kernel.org/show_bug.cgi?id=31522]

I've replied to this error message, but here again for this audience:
The commit that broke all 2.6.38.* releases for my machine is this:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=ba3820ade317ee36e496b9b40d2ec3987dd4aef0
(Takashi Iwai: drm/i915: Revive combination mode for backlight
control).

In 'is_backlight_combination_mode()' INTEL_INFO(dev)-gen
equals 4, and the function returns 0x4000 in combination mode.
In 'intel_panel_get_backlight()' this happens:


  val = I915_READ(BLC_PWM_CTL)  BACKLIGHT_DUTY_CYCLE_MASK; // val = 0x0b4a
  if (IS_PINEVIEW(dev)) // false
  val = 1;

  if (is_backlight_combination_mode(dev)){
  u8 lbpc;

  val = ~1;// val = 0x0b4a
  pci_read_config_byte(dev-pdev, PCI_LBPC, lbpc); // lbpc = 0
  val *= lbpc;  // val = 0
  }


The backlight remains off and does also not react to the brighter key
event.

Reverting the patch fixes my system, obviously.

m.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

i915/kms regression after 2.6.38-rc8

[Melchior FRANZ]

* Chris Wilson -- Wednesday 16 March 2011:
> There's only one patch directly related to i915, so you could begin there.

I'll try later. Was just too obvious for now.  :-}



> Useful information to include is a dmesg (particularly one with
> drm.debug=0xe kernel parameters) and lspci

OK, thanks for that info. Attached.



> (though google says you have a gm45).

I didn't look it up before, I just trusted the kernel with its "i915".
But you are probably right, this Acer TravelMate 5735Z-452G32Mnss is
supposed to have an "Intel Graphics Media Accelerator 4500MHD". 

m.
-- next part --
A non-text attachment was scrubbed...
Name: acer_5735z_i915_blackout.log.gz
Type: application/x-gzip
Size: 16849 bytes
Desc: not available
URL: 

Re: i915/kms regression after 2.6.38-rc8

[Melchior FRANZ]

* Chris Wilson -- Wednesday 16 March 2011:
 There's only one patch directly related to i915, so you could begin there.

I'll try later. Was just too obvious for now.  :-}



 Useful information to include is a dmesg (particularly one with
 drm.debug=0xe kernel parameters) and lspci

OK, thanks for that info. Attached.



 (though google says you have a gm45).

I didn't look it up before, I just trusted the kernel with its i915.
But you are probably right, this Acer TravelMate 5735Z-452G32Mnss is
supposed to have an Intel Graphics Media Accelerator 4500MHD. 

m.


acer_5735z_i915_blackout.log.gz
Description: GNU Zip compressed data
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel