[Intel-gfx] Thinkpad T420 and single/dual channel lvds

2012-03-14 Thread Helge Bahmann
Hi everyone,

Booting a Thinkpad T420 with the lid closed results and opening it subsequently 
results in an 
unusable picture on the panel (and no amount of resetting makes it usable): The 
even pixels show 
the nominal content of the framebuffer (with the right half missing) whlie the 
odd pixels show a 
red-/blueish flicker.

A little bit of investigation revealed that with the lid closed on boot, the 
panel ends up driven in 
lvds single channel mode, which the panel probably does not like. It appears 
that the i915 driver 
relies on the BIOS setting up the PCH_LVDS register for dual channel and will 
otherwise not ever 
consider switching.

While the following hack makes my display work, it is quite obviously not the 
right thing to do -- 
could you investigate if there is a proper way to determine whether the panel 
is supposed to be 
driven dual channel?

Best regards
Helge

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index f851db7..2e51dc3 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -364,8 +364,8 @@ static const intel_limit_t *intel_ironlake_limit(struct 
drm_crtc *crtc,
const intel_limit_t *limit;
 
if (intel_pipe_has_type(crtc, INTEL_OUTPUT_LVDS)) {
-   if ((I915_READ(PCH_LVDS)  LVDS_CLKB_POWER_MASK) ==
-   LVDS_CLKB_POWER_UP) {
+   if (1 || ((I915_READ(PCH_LVDS)  LVDS_CLKB_POWER_MASK) ==
+   LVDS_CLKB_POWER_UP)) {
/* LVDS dual channel */
if (refclk == 10)
limit = intel_limits_ironlake_dual_lvds_100m;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH] xf86-video-intel: Add support for toshiba backlight interface

2012-03-14 Thread Akio Idehara
xfce4-power-manager cannot control backlight brightness via
toshiba backlight sysfs interface.
The reason is that xf86-video-intel doesn't treat it.
This patch adds support for toshiba backlight sysfs interface.

This was tested on a Toshiba Portege R500.

Signed-off-by: Akio Idehara zbe64...@gmail.com
---
 src/intel_display.c   |1 +
 src/sna/sna_display.c |1 +
 2 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/src/intel_display.c b/src/intel_display.c
index 11d0e2b..8eb8df8 100644
--- a/src/intel_display.c
+++ b/src/intel_display.c
@@ -131,6 +131,7 @@ static const char *backlight_interfaces[] = {
fujitsu-laptop,
sony,
samsung,
+   toshiba,
acpi_video1, /* finally fallback to the generic acpi drivers */
acpi_video0,
intel_backlight,
diff --git a/src/sna/sna_display.c b/src/sna/sna_display.c
index 9401ca4..10c67f7 100644
--- a/src/sna/sna_display.c
+++ b/src/sna/sna_display.c
@@ -109,6 +109,7 @@ static const char *backlight_interfaces[] = {
fujitsu-laptop,
sony,
samsung,
+   toshiba,
acpi_video1, /* finally fallback to the generic acpi drivers */
acpi_video0,
NULL,
-- 
1.7.7.6

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] black screen after desktop loading on Lenovo L520

2012-03-14 Thread antonio grande
I have seen in this mailing list that someone have my same problem
(with the same hw). Anyone resolved this problem?
My OS is Archlinux with linux kernel version 3.2.6.
The only solution I've found is to run only the textual 
environment with framebuffer. Antonio Grande

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] Thinkpad T420 and single/dual channel lvds

2012-03-14 Thread Takashi Iwai
At Wed, 14 Mar 2012 10:45:06 -0400,
Adam Jackson wrote:
 
 [1  multipart/signed (7bit)]
 [1.1  text/plain; UTF-8 (quoted-printable)]
 On Wed, 2012-03-14 at 13:37 +0100, Helge Bahmann wrote:
  Hi everyone,
  
  Booting a Thinkpad T420 with the lid closed results and opening it 
  subsequently results in an 
  unusable picture on the panel (and no amount of resetting makes it usable): 
  The even pixels show 
  the nominal content of the framebuffer (with the right half missing) whlie 
  the odd pixels show a 
  red-/blueish flicker.
  
  A little bit of investigation revealed that with the lid closed on boot, 
  the panel ends up driven in 
  lvds single channel mode, which the panel probably does not like. It 
  appears that the i915 driver 
  relies on the BIOS setting up the PCH_LVDS register for dual channel and 
  will otherwise not ever 
  consider switching.
  
  While the following hack makes my display work, it is quite obviously not 
  the right thing to do -- 
  could you investigate if there is a proper way to determine whether the 
  panel is supposed to be 
  driven dual channel?
 
 Nice find!
 
 There may or may not be a bit for this in the VBT in the BIOS.  But the
 more reliably correct thing I suspect would be to just look at the
 preferred mode for the panel and assume it's dual-link LVDS if the pixel
 clock is 112MHz, since that's the crossover frequency.

Coincidently, we hit the same issue with a HP laptop, and wondered how
is the best way to fix.  I hoped BIOS could handle better,
i.e. setting the power bits no matter whether the lid is opened or
not.  But it doesn't set unless the lid is once opened.

(Interestingly, the bits remain even if you close the lid again before
 booting.  Just opening once seems triggering the probing of LVDS
 panel in BIOS and let it setting the right values.)

FWIW, when I check ironalke_crtc_mode_set(), the clock of the HD+
LVDS mode (1600x900) is 107800 (refclk 12), while a similar
machine with a HD panel (1366x768) shows 76300.  So, I'm not sure
whether 112MHz could be a right threshold.


thanks,

Takashi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] Thinkpad T420 and single/dual channel lvds

2012-03-14 Thread Adam Jackson
On Wed, 2012-03-14 at 17:44 +0100, Takashi Iwai wrote:
 At Wed, 14 Mar 2012 10:45:06 -0400,
 Adam Jackson wrote:
  There may or may not be a bit for this in the VBT in the BIOS.  But the
  more reliably correct thing I suspect would be to just look at the
  preferred mode for the panel and assume it's dual-link LVDS if the pixel
  clock is 112MHz, since that's the crossover frequency.
 
 Coincidently, we hit the same issue with a HP laptop, and wondered how
 is the best way to fix.  I hoped BIOS could handle better,
 i.e. setting the power bits no matter whether the lid is opened or
 not.  But it doesn't set unless the lid is once opened.
 
 (Interestingly, the bits remain even if you close the lid again before
  booting.  Just opening once seems triggering the probing of LVDS
  panel in BIOS and let it setting the right values.)
 
 FWIW, when I check ironalke_crtc_mode_set(), the clock of the HD+
 LVDS mode (1600x900) is 107800 (refclk 12), while a similar
 machine with a HD panel (1366x768) shows 76300.  So, I'm not sure
 whether 112MHz could be a right threshold.

Hm, fair point.

Would be interesting to compare the VBTs between the two boots.  The
lvds_fp_timing struct might actually have the data we want here
regardless of how the machine booted.

- ajax


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PULL] drm-intel-fixes

2012-03-14 Thread Keith Packard

Jesse sent me a couple of trivial sprite plane fixes.

The following changes since commit 91982b58d35720b75b894c60e1e3133daa455b53:

  drm/gma500: Fix Cedarview boot failures in 3.3-rc (2012-03-05 14:08:31 +)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/keithp/linux drm-intel-fixes

for you to fetch changes up to b250da79a0c972ef7f6d58ebd1083cab066e6c82:

  drm/i915: support 32 bit BGR formats in sprite planes (2012-03-07 10:52:13 
-0800)


Jesse Barnes (2):
  drm/i915: fix color order for BGR formats on SNB
  drm/i915: support 32 bit BGR formats in sprite planes

 drivers/gpu/drm/i915/i915_reg.h  |2 +-
 drivers/gpu/drm/i915/intel_display.c |1 +
 drivers/gpu/drm/i915/intel_sprite.c  |6 +++---
 3 files changed, 5 insertions(+), 4 deletions(-)

-- 
keith.pack...@intel.com


pgpcqsugaguPS.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] Graphics switching and LVDS detection

2012-03-14 Thread Andreas Heider
Hello everyone,

I'm working on graphics switching for Apple Macbook Pros and still have
a few unresolved issues connected to the i915 driver and would be happy
if someone could help me with a few hints how to solve them in a clean
way.

Switching works by just switching the display lines with a mux (There
are three connections that can be switched individually, DDC, internal
display, external display). At boot the dedicated card (nvidia, I'm
using nouveau) is connected to everything. 

The intel card is a: 00:02.0 VGA compatible controller: Intel
Corporation Core Processor Integrated Graphics Controller (rev 12), and
the laptop display is connected via LVDS.

The main problem is that during boot there is nothing connected to the
intel card, and there is no vbios/VBT so it shuts down LVDS.

Vga_switcheroo switcheroo provides a callback reprobe for this
situation, which tells the video driver that the mux was switched and it
should look for new displays. I implemented support for it analogously
to how it is implemented in nouveau, you can find the patch here:
http://andreas.meetr.de/intel/0001-Add-support-for-vga_switcheroo-reprobe.patch

With this patch switching works fine with external displays connected
via DP, but the internal display is black as the LVDS output is
disabled.

It's possible to manually switch the mux in grub so the intel card is
connected during boot, in which case the internal display works fine.
But due to other reasons (flickering and black display during boot,
messed up mux state) this is only useful as a temporary hack. But it
shows that the problem is indeed the display not being connected.

At the moment I'm just forcing the LVDS connector on, which kind of
works. The text console is broken after a switch (panel fades to white)
which is not surprising, but X runs fine. My current changes are at
http://andreas.meetr.de/intel/force_lvds.patch Please note that this by
far isn't finished yet but I figured it's better to include it in this
mail instead of just describing it.

You can find dmesg output with drm.debug=0x14 here:
http://andreas.meetr.de/intel/dmesg.intel.white (intel disconnected at
boot, broken white text console)
http://andreas.meetr.de/intel/dmesg.intel.switch (intel connected at
boot, working text console)

Search for i915: reprobe to get to the interesting part. I'm
especially wondering why it doesn't like the edid mode: 

[   23.007673] [drm:drm_mode_debug_printmodeline], Modeline
26:1680x1050 0 119000 1680 1728 1760 1840 1050 1053 1059 1080 0x48 0xa
[   23.007680] [drm:drm_mode_prune_invalid], Not using 1680x1050 mode 12

How could this be implemented in a clean way? Of course forcing LVDS on
should become a parameter, but i'm not sure how to handle initially not
having any idea what the mode should be and then adapting to the new
mode after reprobe.

Is there a way to change the mode of the framebuffer console upon
reprobe?

Thanks,
Andreas

P.s.: When I boot with the display connected to the intel card and
switch to nouveau, I at least get a usable fbcon at a lower resolution.
I'm not sure why that is the case, but I guess it's due to information
from the vbios or because the nvidia card was already used in grub.

P.p.s: I don't think there is any vbios information available for the
intel card at all.

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx