Re: [Intel-gfx] [PATCH] drm/i915: Enable aspect/centering panel fitting for Ironlake.
On 2010.08.05 09:05:15 +0100, Chris Wilson wrote: Please illuminate the poor ignorant fool (that's me) what the requirements for eDP are. Even better in patch form. ;-) Does eDP require panel fitting always? yeah, you can see recently added panel fitting support for eDP, it should be same as LVDS actually. I think if you duplicate intel_pch_lvds_mode_fixup() for eDP, that should also work. ;) -- Open Source Technology Center, Intel ltd. $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827 signature.asc Description: Digital signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Enable aspect/centering panel fitting for Ironlake.
v2: Hook in DP paths to keep FULLSCREEN panel fitting on eDP.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Zhenyu Wang zhen...@linux.intel.com
---
drivers/gpu/drm/i915/Makefile|1 +
drivers/gpu/drm/i915/i915_drv.h |2 +
drivers/gpu/drm/i915/intel_display.c | 16 ++---
drivers/gpu/drm/i915/intel_dp.c | 20 ++-
drivers/gpu/drm/i915/intel_drv.h |7 ++
drivers/gpu/drm/i915/intel_lvds.c| 32 +++---
drivers/gpu/drm/i915/intel_panel.c | 111 ++
7 files changed, 143 insertions(+), 46 deletions(-)
create mode 100644 drivers/gpu/drm/i915/intel_panel.c
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 384fd45..5c8e534 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -19,6 +19,7 @@ i915-y := i915_drv.o i915_dma.o i915_irq.o i915_mem.o \
intel_hdmi.o \
intel_sdvo.o \
intel_modes.o \
+ intel_panel.o \
intel_i2c.o \
intel_fb.o \
intel_tv.o \
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index ad8dab5..6da15d8 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -610,6 +610,8 @@ typedef struct drm_i915_private {
struct sdvo_device_mapping sdvo_mappings[2];
/* indicate whether the LVDS_BORDER should be enabled or not */
unsigned int lvds_border_bits;
+ /* Panel fitter placement and size for Ironlake+ */
+ u32 pch_pf_pos, pch_pf_size;
struct drm_crtc *plane_to_crtc_mapping[2];
struct drm_crtc *pipe_to_crtc_mapping[2];
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 07f893f..9b5fab4 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1914,15 +1914,13 @@ static void ironlake_crtc_dpms(struct drm_crtc *crtc,
int mode)
/* Enable panel fitting for LVDS */
if (intel_pipe_has_type(crtc, INTEL_OUTPUT_LVDS)
|| HAS_eDP || intel_pch_has_edp(crtc)) {
- temp = I915_READ(pf_ctl_reg);
- I915_WRITE(pf_ctl_reg, temp | PF_ENABLE |
PF_FILTER_MED_3x3);
-
- /* currently full aspect */
- I915_WRITE(pf_win_pos, 0);
-
- I915_WRITE(pf_win_size,
- (dev_priv-panel_fixed_mode-hdisplay 16)
|
- (dev_priv-panel_fixed_mode-vdisplay));
+ if (dev_priv-pch_pf_size) {
+ temp = I915_READ(pf_ctl_reg);
+ I915_WRITE(pf_ctl_reg, temp | PF_ENABLE |
PF_FILTER_MED_3x3);
+ I915_WRITE(pf_win_pos, dev_priv-pch_pf_pos);
+ I915_WRITE(pf_win_size, dev_priv-pch_pf_size);
+ } else
+ I915_WRITE(pf_ctl_reg, temp ~PF_ENABLE);
}
/* Enable CPU pipe */
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index c4c5868..cee5d9c 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -523,21 +523,9 @@ intel_dp_mode_fixup(struct drm_encoder *encoder, struct
drm_display_mode *mode,
if ((IS_eDP(intel_dp) || IS_PCH_eDP(intel_dp))
dev_priv-panel_fixed_mode) {
- struct drm_display_mode *fixed_mode =
dev_priv-panel_fixed_mode;
-
- adjusted_mode-hdisplay = fixed_mode-hdisplay;
- adjusted_mode-hsync_start = fixed_mode-hsync_start;
- adjusted_mode-hsync_end = fixed_mode-hsync_end;
- adjusted_mode-htotal = fixed_mode-htotal;
-
- adjusted_mode-vdisplay = fixed_mode-vdisplay;
- adjusted_mode-vsync_start = fixed_mode-vsync_start;
- adjusted_mode-vsync_end = fixed_mode-vsync_end;
- adjusted_mode-vtotal = fixed_mode-vtotal;
-
- adjusted_mode-clock = fixed_mode-clock;
- drm_mode_set_crtcinfo(adjusted_mode, CRTC_INTERLACE_HALVE_V);
-
+ intel_fixed_panel_mode(dev_priv-panel_fixed_mode,
adjusted_mode);
+ intel_pch_panel_fitting(dev, DRM_MODE_SCALE_FULLSCREEN,
+ mode, adjusted_mode);
/*
* the mode-clock is used to calculate the DataLink M/N
* of the pipe. For the eDP the fixed clock should be used.
@@ -572,8 +560,10 @@ intel_dp_mode_fixup(struct drm_encoder *encoder, struct
drm_display_mode *mode,
count %d clock %d\n,
intel_dp-link_bw, intel_dp-lane_count,
adjusted_mode-clock);
+
return true;
}
+
return false;
}
diff --git
Re: [Intel-gfx] 845 help
On 2010/08/01 20:49 (GMT+0200) Rüdiger Härtel composed: I have a 845GL graphics chip and the driver reports nearly every time I use my copmuter that the GPU has hung up and acceleration is disabled. After this happend a restart of X - which happens when I log off and on again - is not possible anymore. Is there any information I can provide to help finding the circumstances that lead to this behaviour? My system: http://www.smolts.org/show?uuid=pub_663f9f31-d4fc-4845-8d9b-04636d8df99d I have two 11.3 845G/GL rev01 systems, one from Dell/Foxconn, the other from Intel. On the latter, I just did startx/end (KDE4) session more than 20 times trying (with panning) to get vertical and horizontal DPI to match (instead of 121X120). /etc/X11/xinit/xinitrc: http://fm.no-ip.com/Tmp/Linux/Xorg/xinitrc-113-t2240-1600x1200v1920 /etc/X11/xorg.conf: http://fm.no-ip.com/Tmp/Linux/Xorg/xorg.conf.0e-113-t2240-1600x1200v1920 ~/.xinitrc: http://fm.no-ip.com/Tmp/Linux/Xorg/dotxinitrc-113-t2240-845G-1600x1200v1920-120x120 On the other, repeated startx/killall startkde3 seems to be no problem either, with no ~/.xinitrc, stock /etc/X11/xinit/xinitrc and this xorg.conf: http://fm.no-ip.com/Tmp/Linux/Xorg/xorg.conf.17-113-gx260-845G-1600x1200x120 -- The wise are known for their understanding, and pleasant words are persuasive. Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://fm.no-ip.com/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/opregion: Use ASLE response codes defined in 0.1
Within i915_opregion.c there are two blocks of semantically identical
ASLE response codes defined. Only one of those matches the ACPI IGD
OpRegion Specification 0.1, use those.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Matthew Garrett mj...@srcf.ucam.org
---
drivers/gpu/drm/i915/i915_opregion.c | 10 +++---
1 files changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_opregion.c
b/drivers/gpu/drm/i915/i915_opregion.c
index 8fcc75c..ce402b2 100644
--- a/drivers/gpu/drm/i915/i915_opregion.c
+++ b/drivers/gpu/drm/i915/i915_opregion.c
@@ -114,10 +114,6 @@ struct opregion_asle {
#define ASLE_REQ_MSK 0xf
/* response bits of ASLE irq request */
-#define ASLE_ALS_ILLUM_FAIL(210)
-#define ASLE_BACKLIGHT_FAIL(212)
-#define ASLE_PFIT_FAIL (214)
-#define ASLE_PWM_FREQ_FAIL (216)
#define ASLE_ALS_ILLUM_FAILED (110)
#define ASLE_BACKLIGHT_FAILED (112)
#define ASLE_PFIT_FAILED (114)
@@ -155,11 +151,11 @@ static u32 asle_set_backlight(struct drm_device *dev, u32
bclp)
u32 max_backlight, level, shift;
if (!(bclp ASLE_BCLP_VALID))
- return ASLE_BACKLIGHT_FAIL;
+ return ASLE_BACKLIGHT_FAILED;
bclp = ASLE_BCLP_MSK;
if (bclp 0 || bclp 255)
- return ASLE_BACKLIGHT_FAIL;
+ return ASLE_BACKLIGHT_FAILED;
blc_pwm_ctl = I915_READ(BLC_PWM_CTL);
blc_pwm_ctl2 = I915_READ(BLC_PWM_CTL2);
@@ -211,7 +207,7 @@ static u32 asle_set_pfit(struct drm_device *dev, u32 pfit)
/* Panel fitting is currently controlled by the X code, so this is a
noop until modesetting support works fully */
if (!(pfit ASLE_PFIT_VALID))
- return ASLE_PFIT_FAIL;
+ return ASLE_PFIT_FAILED;
return 0;
}
--
1.7.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/opregion: Use ASLE response codes defined in 0.1
On Thu, Aug 05, 2010 at 12:54:49PM +0100, Chris Wilson wrote: Within i915_opregion.c there are two blocks of semantically identical ASLE response codes defined. Only one of those matches the ACPI IGD OpRegion Specification 0.1, use those. Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk Cc: Matthew Garrett mj...@srcf.ucam.org Acked-by: Matthew Garrett m...@redhat.com -- Matthew Garrett | mj...@srcf.ucam.org ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] how get drm-intel-next into a stable kernel
On Thu, 05 Aug 2010 16:38:55 +0100 Sergio Monteiro Basto ser...@sergiomb.no-ip.org wrote: Hi, Have some kind of howto doc ?, about merging, testing os using drm-intel-next with a stable kernel, lets say kernel-2.6.35. Short answer: you don't. The drm-intel-next branch is a full kernel tree by itself, and I wouldn't recommend copying files from a drm-intel-next checkout into a stable kernel. Longer answer: drm-intel-next bits are targeted at the next kernel release. When important fixes from drm-intel-next land in Linus's tree, you can request that they be back ported to the stable tree by sending a note to sta...@kernel.org with the commit id(s). They have to meet the stable criteria though; I think the kernel has a doc on what makes something eligible for stable inclusion. -- Jesse Barnes, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] how get drm-intel-next into a stable kernel
On Thu, Aug 05, 2010 at 10:54:09AM -0700, Jesse Barnes wrote: Longer answer: drm-intel-next bits are targeted at the next kernel release. When important fixes from drm-intel-next land in Linus's tree, you can request that they be back ported to the stable tree by sending a note to sta...@kernel.org with the commit id(s). They have to meet the stable criteria though; I think the kernel has a doc on what makes something eligible for stable inclusion. Yes we do, see the file, Documenation/stable_kernel_rules.txt thanks, greg k-h ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] hotplug CRT detection
On Thu, 2010-08-05 at 11:53 +1000, Dave Airlie wrote: So I've been reviewing the i915/ironlake CRT detect code and am a bit confused. I though on the i945 and above that we had proper CRT hotplug detection with an IRQ, that didn't require any polling. Now looking at the code when we do a CRT detect, the first thing we do is try the hotplug method, however on ILK/SNB this is crap and requires powering off the ADPA, which turns off the monitor, if that fails we fallback to DDC probing which is pretty non-destructive. I get the feeling the whole hotplug detect code is pointless if the hardware is already meant to send us an IRQ when something happens, Yeah, same. The bit about GM45 needing to do it twice in a row is probably the only exception. - 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
Re: [Intel-gfx] how get drm-intel-next into a stable kernel
Any suggestions of patches to test for those of us still experiencing eDP problems? I've seen a bunch fly by the list, but it's been unclear to me which were supposed to address what issues, or how successful any of them were. I was able to get 2.6.34 to work on my Dell E6510 by reverting 885a5fb5b120a5c7e0b3baad7b0feb5a89f76c18 as suggested in http://lists.freedesktop.org/archives/intel-gfx/2010-May/006948.html This no longer works on 2.6.35 (black screen after starting X). Even with that patch reverted on 2.6.34, I still ran into problems after suspend: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/596080 I can hibernate as a work-around, but that often takes several minutes. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] how get drm-intel-next into a stable kernel
Le 05/08/2010 20:47, Timothy B. Terriberry a écrit : This no longer works on 2.6.35 (black screen after starting X). Could be https://bugzilla.kernel.org/show_bug.cgi?id=16496 ? Brice ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] how get drm-intel-next into a stable kernel
Brice Goglin wrote: Le 05/08/2010 20:47, Timothy B. Terriberry a écrit : This no longer works on 2.6.35 (black screen after starting X). Could be https://bugzilla.kernel.org/show_bug.cgi?id=16496 ? Reverting that patch (or, more accurately, just deleting the redundant backlight_off call) does indeed solve the problem when initially starting X. So now it's just the suspend issue. Same behavior as 2.6.34: when resuming, the display is off, and switching VTs, etc., won't turn it on. What does work, if I type very carefully, is hibernating and then resuming. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] how get drm-intel-next into a stable kernel
On Thu, 2010-08-05 at 12:47 -0700, Timothy B. Terriberry wrote: So now it's just the suspend issue. Same behavior as 2.6.34: when resuming, the display is off, and switching VTs, etc., won't turn it on. What does work, if I type very carefully, is hibernating and then resuming. Suspend just supposed to work with drm-intel-next and is not (yet) in stables kernel. As workaround (a good one). I boot with option acpi_sleep=s3_bios, and remove /usr/lib64/pm-utils/sleep.d/99video . which works very well with my E6410. -- Sérgio M. B. smime.p7s Description: S/MIME cryptographic signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Enable aspect/centering panel fitting for Ironlake.
On 2010.08.05 11:25:26 +0100, Chris Wilson wrote: v2: Hook in DP paths to keep FULLSCREEN panel fitting on eDP. Looks fine to me. Reviewed-by: Zhenyu Wang zhen...@linux.intel.com -- Open Source Technology Center, Intel ltd. $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827 signature.asc Description: Digital signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
