[Intel-gfx] [PATCH] Replace x allocator functions with direct libc calls
The server no longer supports the allocator wrapping functions.
Signed-off-by: Keith Packard kei...@keithp.com
---
src/drmmode_display.c | 20 +-
src/i810_dga.c |4 +-
src/i810_dri.c | 50
src/i810_driver.c | 12 +-
src/i810_hwmc.c| 10
src/i810_video.c | 26
src/i830_batchbuffer.c |2 +-
src/i830_dri.c | 36 +-
src/i830_driver.c | 12 +-
src/i830_hwmc.c|4 +-
src/i830_uxa.c | 10
src/i830_video.c | 22 ++--
src/xvmc/I810XvMC.c|2 +-
src/xvmc/i965_xvmc.c |2 +-
src/xvmc/intel_xvmc.c |2 +-
src/xvmc/xvmc_vld.c|2 +-
uxa/uxa-accel.c| 14 ++--
uxa/uxa-glyphs.c |8 +++---
uxa/uxa.c |8 +++---
19 files changed, 123 insertions(+), 123 deletions(-)
diff --git a/src/drmmode_display.c b/src/drmmode_display.c
index d4cf367..885cd0d 100644
--- a/src/drmmode_display.c
+++ b/src/drmmode_display.c
@@ -342,7 +342,7 @@ drmmode_set_mode_major(xf86CrtcPtr crtc, DisplayModePtr
mode,
crtc-y = y;
crtc-rotation = rotation;
- output_ids = xcalloc(sizeof(uint32_t), xf86_config-num_output);
+ output_ids = calloc(sizeof(uint32_t), xf86_config-num_output);
if (!output_ids) {
ret = FALSE;
goto done;
@@ -812,18 +812,18 @@ drmmode_output_destroy(xf86OutputPtr output)
drmModeFreePropertyBlob(drmmode_output-edid_blob);
for (i = 0; i drmmode_output-num_props; i++) {
drmModeFreeProperty(drmmode_output-props[i].mode_prop);
- xfree(drmmode_output-props[i].atoms);
+ free(drmmode_output-props[i].atoms);
}
- xfree(drmmode_output-props);
+ free(drmmode_output-props);
drmModeFreeConnector(drmmode_output-mode_output);
drmmode_output-mode_output = NULL;
if (drmmode_output-private_data) {
- xfree(drmmode_output-private_data);
+ free(drmmode_output-private_data);
drmmode_output-private_data = NULL;
}
if (drmmode_output-backlight_iface)
drmmode_backlight_set(output,
drmmode_output-backlight_active_level);
- xfree(drmmode_output);
+ free(drmmode_output);
output-driver_private = NULL;
}
@@ -914,7 +914,7 @@ drmmode_output_create_resources(xf86OutputPtr output)
drmModePropertyPtr drmmode_prop;
int i, j, err;
-drmmode_output-props = xcalloc(mode_output-count_props,
sizeof(drmmode_prop_rec));
+drmmode_output-props = calloc(mode_output-count_props,
sizeof(drmmode_prop_rec));
if (!drmmode_output-props)
return;
@@ -939,7 +939,7 @@ drmmode_output_create_resources(xf86OutputPtr output)
INT32 range[2];
p-num_atoms = 1;
- p-atoms = xcalloc(p-num_atoms, sizeof(Atom));
+ p-atoms = calloc(p-num_atoms, sizeof(Atom));
if (!p-atoms)
continue;
p-atoms[0] = MakeAtom(drmmode_prop-name,
strlen(drmmode_prop-name), TRUE);
@@ -961,7 +961,7 @@ drmmode_output_create_resources(xf86OutputPtr output)
}
} else if (drmmode_prop-flags DRM_MODE_PROP_ENUM) {
p-num_atoms = drmmode_prop-count_enums + 1;
- p-atoms = xcalloc(p-num_atoms, sizeof(Atom));
+ p-atoms = calloc(p-num_atoms, sizeof(Atom));
if (!p-atoms)
continue;
p-atoms[0] = MakeAtom(drmmode_prop-name,
strlen(drmmode_prop-name), TRUE);
@@ -1206,7 +1206,7 @@ drmmode_output_init(ScrnInfoPtr scrn, drmmode_ptr
drmmode, int num)
return;
}
- drmmode_output = xcalloc(sizeof(drmmode_output_private_rec), 1);
+ drmmode_output = calloc(sizeof(drmmode_output_private_rec), 1);
if (!drmmode_output) {
xf86OutputDestroy(output);
drmModeFreeConnector(koutput);
@@ -1220,7 +1220,7 @@ drmmode_output_init(ScrnInfoPtr scrn, drmmode_ptr
drmmode, int num)
*/
drmmode_output-private_data = NULL;
if (koutput-connector_type == DRM_MODE_CONNECTOR_LVDS) {
- drmmode_output-private_data = xcalloc(
+ drmmode_output-private_data = calloc(
sizeof(struct fixed_panel_lvds), 1);
if (!drmmode_output-private_data)
xf86DrvMsg(scrn-scrnIndex, X_ERROR,
diff --git a/src/i810_dga.c b/src/i810_dga.c
index 3f53057..52a01b7 100644
--- a/src/i810_dga.c
+++ b/src/i810_dga.c
@@ -84,10 +84,10 @@ I810DGAInit(ScreenPtr pScreen)
while (pMode) {
- newmodes = xrealloc(modes, (num + 1) * sizeof(DGAModeRec));
+ newmodes = realloc(modes, (num + 1) * sizeof(DGAModeRec));
if (!newmodes) {
-xfree(modes);
+free(modes
Re: [Intel-gfx] CUDA port for intel graphics
On Wed, 23 Jun 2010 00:14:39 -0700, Gregory Diamos gregory.dia...@gatech.edu wrote: 1. Is there an interface for writing directly to the GPU ring buffer that is exposed by the driver? If not, would it be straightforward to add such an interface? Take a look at 'drm' in the mesa git repository; that contains a library (libdrm) which provides to ability to execute arbitrary commands in the GPU with in-kernel memory management. This is used by the X 2D driver, the Mesa GL driver and the VaAPI library. git clone git://anongit.freedesktop.org/git/mesa/drm 2. Are there any restrictions (security, DRM, etc) for loading/executing binaries on the media pipeline? Nope. You need permission to open the device, which is currently managed by having a connection to the X server, so for now you'd have to be running under X. There's no requirement to deal with X other than authenticating access to the device though. It would be useful to fix this so that arbitrary programs could use the GPU without needing to be authenticated through the window system. 3. How modular is the driver? Is there an interface for user-level applications to issue hardware commands in a way that is isolated and time-shared with commands from the graphics driver? If not, would it be straightforward to modify the driver to disable the graphics components of the driver and retain only an interface for passing commands to the device? Yes, that's precisely what the DRM infrastructure provides -- the ability to execute arbitrary commands on the hardware from multiple programs at the same time. 4. How is memory sharing between the CPU and GPU handled? Is it possible to map memory from the CPU's address space into the GPU's address space? Sorry if this is already documented somewhere, I might have missed it. As above, the kernel is used to manage memory objects and the driver knows how to deal with the lack of hardware cache coherency with help From the application. -- keith.pack...@intel.com pgp2IgAoX7BoD.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] Destroy screen pixmap on screen close.
On Fri, 02 Jul 2010 09:24:07 +0100, Chris Wilson ch...@chris-wilson.co.uk wrote: This looks like the responsibility of miCloseScreen(). Are we failing to chain up properly? I don't think miCloseScreen (or fbCloseScreen) can do this -- before we're called, rendering may not have been finished, after we're called, the acceleration code is shut down and pixmaps cannot be freed. -- keith.pack...@intel.com pgpD1SJAXrNIk.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: be sure panel is powered up in eDP configs
On Wed, 14 Jul 2010 15:40:56 -0700, Jesse Barnes jbar...@virtuousgeek.org wrote: Fixes https://bugs.freedesktop.org/show_bug.cgi?id=28739. We need to enable power to the panel with the AUX VDD bit in order to properly detect the eDP attached panel, and we also need to turn the panel on in case it was off when we started (as happens at resume time). But this patch raises a couple of questions: 1) why does the first panel on sequence time out? 2) why do I need to unlock the panel protected regs? Keith, I think this is your code, any ideas? I just wrote the DP code, not the eDP code. I haven't any idea why the panel on sequence is timing out, although I note that you unlock the panel regs after turning it on... -- keith.pack...@intel.com pgp7W7pOMmyVP.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] Move registration of vsync fd from pre-init to screen-init
On Wed, 18 Aug 2010 10:28:24 +0100, Chris Wilson ch...@chris-wilson.co.uk wrote: Marty Jack reported an issue he found where the page-flipping handler was being lost on server reset. This results in the swap completion notification being lost, with the sporadic hang of full screen applications like Compiz, flash and even glxgears! Fixes: Bug 29584 - Server in compute loop https://bugs.freedesktop.org/show_bug.cgi?id=29584 There are also several possibly related bugs with similar symptoms, i.e. OpenGL applications hanging on missed swap notifications. Reported-by: Marty Jack marty...@comcast.net Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk Cc: Keith Packard kei...@keithp.com Reviewed-by: Keith Packard kei...@keithp.com -- keith.pack...@intel.com pgpD06RpFALGL.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] glx: Fix use after free in DrawableGone
On Thu, 23 Sep 2010 09:04:11 -0400, Kristian Høgsberg k...@bitplanet.net wrote: Signed-off-by: Kristian Høgsberg k...@bitplanet.net --- Chris Wilson points out that we were still accessing c-next after free. Here's an updated version that fixes that. I've merged this patch (and attempted to collect all of the *-by: lines). I liked 'next' better than 'tmp' as a name, so Kristian ends up with the credit. -- keith.pack...@intel.com pgpPsVUQTSVO3.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: vblank status not valid while training display port
While the display port is in training mode, vblank interrupts don't
occur. Because we have to wait for the display port output to turn on
before starting the training sequence, enable the output in 'normal'
mode so that we can tell when a vblank has occurred, then start the
training sequence.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/intel_dp.c | 19 +--
1 files changed, 9 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 1a51ee0..9ab8708 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1138,18 +1138,14 @@ static bool
intel_dp_set_link_train(struct intel_dp *intel_dp,
uint32_t dp_reg_value,
uint8_t dp_train_pat,
- uint8_t train_set[4],
- bool first)
+ uint8_t train_set[4])
{
struct drm_device *dev = intel_dp-base.enc.dev;
struct drm_i915_private *dev_priv = dev-dev_private;
- struct intel_crtc *intel_crtc = to_intel_crtc(intel_dp-base.enc.crtc);
int ret;
I915_WRITE(intel_dp-output_reg, dp_reg_value);
POSTING_READ(intel_dp-output_reg);
- if (first)
- intel_wait_for_vblank(dev, intel_crtc-pipe);
intel_dp_aux_native_write_1(intel_dp,
DP_TRAINING_PATTERN_SET,
@@ -1174,10 +1170,15 @@ intel_dp_link_train(struct intel_dp *intel_dp)
uint8_t voltage;
bool clock_recovery = false;
bool channel_eq = false;
- bool first = true;
int tries;
u32 reg;
uint32_t DP = intel_dp-DP;
+ struct intel_crtc *intel_crtc = to_intel_crtc(intel_dp-base.enc.crtc);
+
+ /* Enable output, wait for it to become active */
+ I915_WRITE(intel_dp-output_reg, intel_dp-DP);
+ POSTING_READ(intel_dp-output_reg);
+ intel_wait_for_vblank(dev, intel_crtc-pipe);
/* Write the link configuration data */
intel_dp_aux_native_write(intel_dp, DP_LINK_BW_SET,
@@ -1210,9 +1211,8 @@ intel_dp_link_train(struct intel_dp *intel_dp)
reg = DP | DP_LINK_TRAIN_PAT_1;
if (!intel_dp_set_link_train(intel_dp, reg,
-DP_TRAINING_PATTERN_1, train_set,
first))
+DP_TRAINING_PATTERN_1, train_set))
break;
- first = false;
/* Set training pattern 1 */
udelay(100);
@@ -1266,8 +1266,7 @@ intel_dp_link_train(struct intel_dp *intel_dp)
/* channel eq pattern */
if (!intel_dp_set_link_train(intel_dp, reg,
-DP_TRAINING_PATTERN_2, train_set,
-false))
+DP_TRAINING_PATTERN_2, train_set))
break;
udelay(400);
--
1.7.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: Use pipe state to tell when pipe is off
Instead of waiting for the display line value to settle, we can simply
wait for the pipe configuration register 'state' bit to turn off.
Contrarywise, disabling the plane will not cause the display line
value to stop changing, so instead we wait for the vblank interrupt
bit to get set. And, we only do this when we're not about to wait for
the pipe to turn off.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/intel_display.c | 62 +-
drivers/gpu/drm/i915/intel_drv.h |1 -
2 files changed, 38 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index b5bf51a..9792285 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1013,8 +1013,8 @@ void intel_wait_for_vblank(struct drm_device *dev, int
pipe)
DRM_DEBUG_KMS(vblank wait timed out\n);
}
-/**
- * intel_wait_for_vblank_off - wait for vblank after disabling a pipe
+/*
+ * intel_wait_for_pipe_off - wait for pipe to turn off
* @dev: drm device
* @pipe: pipe to wait for
*
@@ -1022,25 +1022,39 @@ void intel_wait_for_vblank(struct drm_device *dev, int
pipe)
* spinning on the vblank interrupt status bit, since we won't actually
* see an interrupt when the pipe is disabled.
*
- * So this function waits for the display line value to settle (it
- * usually ends up stopping at the start of the next frame).
+ * On Gen4 and above:
+ * wait for the pipe register state bit to turn off
+ *
+ * Otherwise:
+ * wait for the display line value to settle (it usually
+ * ends up stopping at the start of the next frame).
+ *
*/
-void intel_wait_for_vblank_off(struct drm_device *dev, int pipe)
+static void intel_wait_for_pipe_off(struct drm_device *dev, int pipe)
{
struct drm_i915_private *dev_priv = dev-dev_private;
- int pipedsl_reg = (pipe == 0 ? PIPEADSL : PIPEBDSL);
- unsigned long timeout = jiffies + msecs_to_jiffies(100);
- u32 last_line;
-
- /* Wait for the display line to settle */
- do {
- last_line = I915_READ(pipedsl_reg) DSL_LINEMASK;
- mdelay(5);
- } while (((I915_READ(pipedsl_reg) DSL_LINEMASK) != last_line)
-time_after(timeout, jiffies));
-
- if (time_after(jiffies, timeout))
- DRM_DEBUG_KMS(vblank wait timed out\n);
+
+ if (INTEL_INFO(dev)-gen = 4) {
+ int pipeconf_reg = (pipe == 0 ? PIPEACONF : PIPEBCONF);
+
+ /* Wait for the Pipe State to go off */
+ if (wait_for((I915_READ(pipeconf_reg) I965_PIPECONF_ACTIVE)
== 0,
+100, 0))
+ DRM_DEBUG_KMS(pipe_off wait timed out\n);
+ } else {
+ u32 last_line;
+ int pipedsl_reg = (pipe == 0 ? PIPEADSL : PIPEBDSL);
+ unsigned long timeout = jiffies + msecs_to_jiffies(100);
+
+ /* Wait for the display line to settle */
+ do {
+ last_line = I915_READ(pipedsl_reg) DSL_LINEMASK;
+ mdelay(5);
+ } while (((I915_READ(pipedsl_reg) DSL_LINEMASK) != last_line)
+time_after(timeout, jiffies));
+ if (time_after(jiffies, timeout))
+ DRM_DEBUG_KMS(pipe_off wait timed out\n);
+ }
}
/* Parameters have changed, update FBC info */
@@ -2328,13 +2342,13 @@ static void i9xx_crtc_dpms(struct drm_crtc *crtc, int
mode)
I915_READ(dspbase_reg);
}
- /* Wait for vblank for the disable to take effect */
- intel_wait_for_vblank_off(dev, pipe);
-
/* Don't disable pipe A or pipe A PLLs if needed */
if (pipeconf_reg == PIPEACONF
- (dev_priv-quirks QUIRK_PIPEA_FORCE))
+ (dev_priv-quirks QUIRK_PIPEA_FORCE)) {
+ /* Wait for vblank for the disable to take effect */
+ intel_wait_for_vblank(dev, pipe);
goto skip_pipe_off;
+ }
/* Next, disable display pipes */
temp = I915_READ(pipeconf_reg);
@@ -2343,8 +2357,8 @@ static void i9xx_crtc_dpms(struct drm_crtc *crtc, int
mode)
I915_READ(pipeconf_reg);
}
- /* Wait for vblank for the disable to take effect. */
- intel_wait_for_vblank_off(dev, pipe);
+ /* Wait for the pipe to turn off */
+ intel_wait_for_pipe_off(dev, pipe);
temp = I915_READ(dpll_reg);
if ((temp DPLL_VCO_ENABLE) != 0) {
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index ad312ca..8828b3a 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -229,7 +229,6 @@ extern struct
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Use pipe state to tell when pipe is off
On Sun, 3 Oct 2010 08:10:48 -0700, Jesse Barnes jbar...@virtuousgeek.org wrote: Do these fixes help with the DP issues you've been seeing, Keith? Seems like the first one shouldn't change behavior since we ought to time out on waiting on vblank in that case, and the timeout is the same as the msleep we used to use. The first one changes when the monitor sees the training message -- before the change, the training message would get sent before waiting for the vblank, and could potentially mess up the monitor synchronization with signals. I tested this by turning an external DP monitor on/off repeatedly without X running. Before the patch, the monitor would fail to sync once in a while. With the patch, I haven't seen it fail. That's not to say that it has actually fixed anything, just that it seems better. The best feature of the patch is that it shortens the time it takes to light up a DP pipe -- the code was always hitting the timeout instead of seeing a vblank signal, so we'd get a 50ms delay instead of a couple of ms. The second one looks like a good change, but really the pipe off change is separate from the plane disable bug fix. Yeah, yeah, I know. I should have split the patch into two pieces... With these two patches in place, I'm not getting any timeouts while waiting for vblank, which seems like a useful result, and should make mode setting a tiny bit faster as well. I've got a couple more changes to work on today: 1) re-train the monitor when it gets unplugged and then plugged back in. Right now, if you kick the cable out, you're stuck fumbling around in the dark trying to run 'xrandr' again. 2) send hotplug notification through the X server, at least for the 'reliable' hotplug signals. Right now, when you run 'xrandr' after changing connections, gnome sees the connection status change event and 'does stuff', which frequently collides with the 'xrandr' command you're running. This is very confusing to users. -- keith.pack...@intel.com pgpUSvOvFplN3.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: mark display port DPMS state as 'ON' when enabling output
The display port DPMS state is tracked internally in the display port driver so that when a hotplug event comes along, the driver can know whether to try retraining the link. This doesn't work well if the driver never sets the DPMS state to ON when the output is enabled. Signed-off-by: Keith Packard kei...@keithp.com --- drivers/gpu/drm/i915/intel_dp.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 9ab8708..8602143 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -881,6 +881,7 @@ static void intel_dp_commit(struct drm_encoder *encoder) } if (IS_eDP(intel_dp) || IS_PCH_eDP(intel_dp)) ironlake_edp_backlight_on(dev); + intel_dp-dpms_mode = DRM_MODE_DPMS_ON; } static void -- 1.7.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] intel: Listen for hotplug uevents
From: Adam Jackson a...@redhat.com
This connects the kernel uevent indicating monitor hotplugging to the
RandR notification events so that X applications can be notified
automatically when monitors are connected or disconnected.
This also adds a configuration option to disable hotplug events.
Signed-off-by: Keith Packard kei...@keithp.com
---
configure.ac |5 ++
src/Makefile.am|4 +-
src/intel.h| 11 +
src/intel_driver.c | 114
4 files changed, 132 insertions(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index e066b3d..58fa929 100644
--- a/configure.ac
+++ b/configure.ac
@@ -47,6 +47,11 @@ AC_PROG_LIBTOOL
PKG_CHECK_MODULES(GEN4ASM, [intel-gen4asm = 1.0], [gen4asm=yes], [gen4asm=no])
AM_CONDITIONAL(HAVE_GEN4ASM, test x$gen4asm = xyes)
+PKG_CHECK_MODULES(UDEV, [libudev], [udev=yes], [udev=no])
+if test x$udev = xyes; then
+ AC_DEFINE(HAVE_UDEV,1,[Enable udev-based monitor hotplug detection])
+fi
+
AH_TOP([#include xorg-server.h])
# Define a configure option for an alternate module directory
diff --git a/src/Makefile.am b/src/Makefile.am
index b0a1cf7..ab70207 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -26,13 +26,13 @@ SUBDIRS = xvmc render_program legacy
# _ladir passes a dummy rpath to libtool so the thing will actually link
# TODO: -nostdlib/-Bstatic/-lgcc platform magic, not installing the .a, etc.
-AM_CFLAGS = @CWARNFLAGS@ @XORG_CFLAGS@ @DRM_CFLAGS@ @DRI_CFLAGS@ \
+AM_CFLAGS = @CWARNFLAGS@ @XORG_CFLAGS@ @UDEV_CFLAGS@ @DRM_CFLAGS@ @DRI_CFLAGS@
\
@PCIACCESS_CFLAGS@ -I$(top_srcdir)/uxa
-I$(top_srcdir)/src/render_program
intel_drv_la_LTLIBRARIES = intel_drv.la
intel_drv_la_LDFLAGS = -module -avoid-version
intel_drv_ladir = @moduledir@/drivers
-intel_drv_la_LIBADD = -lm @DRM_LIBS@ -ldrm_intel ../uxa/libuxa.la
legacy/liblegacy.la
+intel_drv_la_LIBADD = @UDEV_LIBS@ -lm @DRM_LIBS@ -ldrm_intel ../uxa/libuxa.la
legacy/liblegacy.la
intel_drv_la_LIBADD += @PCIACCESS_LIBS@
NULL:=#
diff --git a/src/intel.h b/src/intel.h
index b816aeb..a80b214 100644
--- a/src/intel.h
+++ b/src/intel.h
@@ -34,6 +34,10 @@ SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
*
*/
+#ifdef HAVE_CONFIG_H
+#include config.h
+#endif
+
#if 0
#define I830DEBUG
#endif
@@ -47,6 +51,7 @@ SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
#ifndef _I830_H_
#define _I830_H_
+
#include xf86_OSproc.h
#include compiler.h
#include xf86PciInfo.h
@@ -70,6 +75,10 @@ SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
#include intel_driver.h
+#if HAVE_UDEV
+#include libudev.h
+#endif
+
#include uxa.h
/* XXX
* The X server gained an *almost* identical implementation in 1.9.
@@ -435,6 +444,8 @@ typedef struct intel_screen_private {
*/
Bool fallback_debug;
unsigned debug_flush;
+ struct udev_monitor *uevent_monitor;
+ InputHandlerProc uevent_handler;
} intel_screen_private;
enum {
diff --git a/src/intel_driver.c b/src/intel_driver.c
index 4391672..63b26a4 100644
--- a/src/intel_driver.c
+++ b/src/intel_driver.c
@@ -107,6 +107,7 @@ typedef enum {
OPTION_DEBUG_FLUSH_BATCHES,
OPTION_DEBUG_FLUSH_CACHES,
OPTION_DEBUG_WAIT,
+ OPTION_HOTPLUG,
} I830Opts;
static OptionInfoRec I830Options[] = {
@@ -125,6 +126,7 @@ static OptionInfoRec I830Options[] = {
{OPTION_DEBUG_FLUSH_BATCHES, DebugFlushBatches, OPTV_BOOLEAN, {0}, FALSE},
{OPTION_DEBUG_FLUSH_CACHES, DebugFlushCaches, OPTV_BOOLEAN, {0}, FALSE},
{OPTION_DEBUG_WAIT, DebugWait, OPTV_BOOLEAN, {0}, FALSE},
+ {OPTION_HOTPLUG,HotPlug, OPTV_BOOLEAN, {0},TRUE},
{-1,NULL, OPTV_NONE, {0},FALSE}
};
/* *INDENT-ON* */
@@ -801,6 +803,110 @@ intel_flush_callback(CallbackListPtr *list,
}
}
+#if HAVE_UDEV
+static void
+I830HandleUEvents(int fd, void *closure)
+{
+ScrnInfoPtr scrn = closure;
+ intel_screen_private *intel = intel_get_screen_private(scrn);
+struct udev_device *dev;
+const char *hotplug;
+struct stat s;
+dev_t udev_devnum;
+
+dev = udev_monitor_receive_device(intel-uevent_monitor);
+if (!dev)
+ return;
+
+udev_devnum = udev_device_get_devnum(dev);
+fstat(intel-drmSubFD, s);
+/*
+ * Check to make sure this event is directed at our
+ * device (by comparing dev_t values), then make
+ * sure it's a hotplug event (HOTPLUG=1)
+ */
+
+hotplug = udev_device_get_property_value(dev, HOTPLUG);
+
+if (memcmp(s.st_rdev, udev_devnum, sizeof (dev_t)) == 0
+ hotplug atoi(hotplug) == 1)
+ RRGetInfo(screenInfo.screens[scrn-scrnIndex], TRUE);
+
+udev_device_unref(dev);
+}
+
+static void
+I830UeventInit(ScrnInfoPtr scrn)
+{
+intel_screen_private *intel = intel_get_screen_private(scrn);
+struct udev *u;
+struct udev_monitor *mon;
+Bool hotplug;
+MessageType from = X_CONFIG
Re: [Intel-gfx] [PATCH] drm/i915: mark display port DPMS state as ON when enabling output
On Sun, 03 Oct 2010 22:05:13 +0100, Chris Wilson ch...@chris-wilson.co.uk wrote: It appears that all users (crtc and encoders) are tracking dpms_mode, in one form or another. Should we move this to core? Sounds like a good idea. Would you prefer to do that yourself? Is there any hardware that requires notification even when there is no change? I don't know, but it seems unlikely. -- keith.pack...@intel.com pgpTjTKpQiADE.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] intel: Listen for hotplug uevents (V2)
From: Adam Jackson a...@redhat.com
This connects the kernel uevent indicating monitor hotplugging to the
RandR notification events so that X applications can be notified
automatically when monitors are connected or disconnected.
This also adds a configuration option to disable hotplug events.
V2: missed a #ifdef HAVE_UDEV around some udev-specific declarations
Signed-off-by: Keith Packard kei...@keithp.com
---
configure.ac |5 ++
src/Makefile.am|4 +-
src/intel.h| 12 +
src/intel_driver.c | 114
4 files changed, 133 insertions(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index e066b3d..58fa929 100644
--- a/configure.ac
+++ b/configure.ac
@@ -47,6 +47,11 @@ AC_PROG_LIBTOOL
PKG_CHECK_MODULES(GEN4ASM, [intel-gen4asm = 1.0], [gen4asm=yes], [gen4asm=no])
AM_CONDITIONAL(HAVE_GEN4ASM, test x$gen4asm = xyes)
+PKG_CHECK_MODULES(UDEV, [libudev], [udev=yes], [udev=no])
+if test x$udev = xyes; then
+ AC_DEFINE(HAVE_UDEV,1,[Enable udev-based monitor hotplug detection])
+fi
+
AH_TOP([#include xorg-server.h])
# Define a configure option for an alternate module directory
diff --git a/src/Makefile.am b/src/Makefile.am
index b0a1cf7..ab70207 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -26,13 +26,13 @@ SUBDIRS = xvmc render_program legacy
# _ladir passes a dummy rpath to libtool so the thing will actually link
# TODO: -nostdlib/-Bstatic/-lgcc platform magic, not installing the .a, etc.
-AM_CFLAGS = @CWARNFLAGS@ @XORG_CFLAGS@ @DRM_CFLAGS@ @DRI_CFLAGS@ \
+AM_CFLAGS = @CWARNFLAGS@ @XORG_CFLAGS@ @UDEV_CFLAGS@ @DRM_CFLAGS@ @DRI_CFLAGS@
\
@PCIACCESS_CFLAGS@ -I$(top_srcdir)/uxa
-I$(top_srcdir)/src/render_program
intel_drv_la_LTLIBRARIES = intel_drv.la
intel_drv_la_LDFLAGS = -module -avoid-version
intel_drv_ladir = @moduledir@/drivers
-intel_drv_la_LIBADD = -lm @DRM_LIBS@ -ldrm_intel ../uxa/libuxa.la
legacy/liblegacy.la
+intel_drv_la_LIBADD = @UDEV_LIBS@ -lm @DRM_LIBS@ -ldrm_intel ../uxa/libuxa.la
legacy/liblegacy.la
intel_drv_la_LIBADD += @PCIACCESS_LIBS@
NULL:=#
diff --git a/src/intel.h b/src/intel.h
index b816aeb..1234b94 100644
--- a/src/intel.h
+++ b/src/intel.h
@@ -34,6 +34,10 @@ SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
*
*/
+#ifdef HAVE_CONFIG_H
+#include config.h
+#endif
+
#if 0
#define I830DEBUG
#endif
@@ -70,6 +74,10 @@ SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
#include intel_driver.h
+#if HAVE_UDEV
+#include libudev.h
+#endif
+
#include uxa.h
/* XXX
* The X server gained an *almost* identical implementation in 1.9.
@@ -435,6 +443,10 @@ typedef struct intel_screen_private {
*/
Bool fallback_debug;
unsigned debug_flush;
+#if HAVE_UDEV
+ struct udev_monitor *uevent_monitor;
+ InputHandlerProc uevent_handler;
+#endif
} intel_screen_private;
enum {
diff --git a/src/intel_driver.c b/src/intel_driver.c
index 4391672..63b26a4 100644
--- a/src/intel_driver.c
+++ b/src/intel_driver.c
@@ -107,6 +107,7 @@ typedef enum {
OPTION_DEBUG_FLUSH_BATCHES,
OPTION_DEBUG_FLUSH_CACHES,
OPTION_DEBUG_WAIT,
+ OPTION_HOTPLUG,
} I830Opts;
static OptionInfoRec I830Options[] = {
@@ -125,6 +126,7 @@ static OptionInfoRec I830Options[] = {
{OPTION_DEBUG_FLUSH_BATCHES, DebugFlushBatches, OPTV_BOOLEAN, {0}, FALSE},
{OPTION_DEBUG_FLUSH_CACHES, DebugFlushCaches, OPTV_BOOLEAN, {0}, FALSE},
{OPTION_DEBUG_WAIT, DebugWait, OPTV_BOOLEAN, {0}, FALSE},
+ {OPTION_HOTPLUG,HotPlug, OPTV_BOOLEAN, {0},TRUE},
{-1,NULL, OPTV_NONE, {0},FALSE}
};
/* *INDENT-ON* */
@@ -801,6 +803,110 @@ intel_flush_callback(CallbackListPtr *list,
}
}
+#if HAVE_UDEV
+static void
+I830HandleUEvents(int fd, void *closure)
+{
+ScrnInfoPtr scrn = closure;
+ intel_screen_private *intel = intel_get_screen_private(scrn);
+struct udev_device *dev;
+const char *hotplug;
+struct stat s;
+dev_t udev_devnum;
+
+dev = udev_monitor_receive_device(intel-uevent_monitor);
+if (!dev)
+ return;
+
+udev_devnum = udev_device_get_devnum(dev);
+fstat(intel-drmSubFD, s);
+/*
+ * Check to make sure this event is directed at our
+ * device (by comparing dev_t values), then make
+ * sure it's a hotplug event (HOTPLUG=1)
+ */
+
+hotplug = udev_device_get_property_value(dev, HOTPLUG);
+
+if (memcmp(s.st_rdev, udev_devnum, sizeof (dev_t)) == 0
+ hotplug atoi(hotplug) == 1)
+ RRGetInfo(screenInfo.screens[scrn-scrnIndex], TRUE);
+
+udev_device_unref(dev);
+}
+
+static void
+I830UeventInit(ScrnInfoPtr scrn)
+{
+intel_screen_private *intel = intel_get_screen_private(scrn);
+struct udev *u;
+struct udev_monitor *mon;
+Bool hotplug;
+MessageType from = X_CONFIG;
+
+if (!xf86GetOptValBool(intel-Options, OPTION_HOTPLUG, hotplug)) {
+ from = X_DEFAULT
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Use pipe state to tell when pipe is off
On Mon, 4 Oct 2010 06:33:01 +1000, Dave Airlie airl...@gmail.com wrote: don't you do this already? both radeon/nouveau handle DP replug fine, I thought Intel would have been where I stole the code from. There was a one-line bug. Patch already posted. -- keith.pack...@intel.com pgpVBHm0wwS9e.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: avoid struct mutex output_poll mutex lock loop on unload
Cancel the output polling work proc before acquiring the struct mutex
to avoid acquiring the work proc mutex with the struct mutex
held. This avoids inverting the lock order seen when the work proc
runs.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/intel_display.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 9792285..a4cc072 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6052,9 +6052,9 @@ void intel_modeset_cleanup(struct drm_device *dev)
struct drm_crtc *crtc;
struct intel_crtc *intel_crtc;
+ drm_kms_helper_poll_fini(dev);
mutex_lock(dev-struct_mutex);
- drm_kms_helper_poll_fini(dev);
intel_fbdev_fini(dev);
list_for_each_entry(crtc, dev-mode_config.crtc_list, head) {
--
1.7.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Free hardware status page on unload when physically mapped
A physically mapped hardware status page is allocated at driver load time but was never freed. Call the existing code to free this page at driver unload time on hardware which uses this kind. Signed-off-by: Keith Packard kei...@keithp.com --- drivers/gpu/drm/i915/i915_dma.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c index 9d67b48..98bf1f0 100644 --- a/drivers/gpu/drm/i915/i915_dma.c +++ b/drivers/gpu/drm/i915/i915_dma.c @@ -2305,6 +2305,9 @@ int i915_driver_unload(struct drm_device *dev) intel_cleanup_overlay(dev); } + if (!I915_NEED_GFX_HWS(dev)) + i915_free_hws(dev); + intel_teardown_mchbar(dev); pci_dev_put(dev_priv-bridge_dev); -- 1.7.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Fix restore of 965 fence regs since the register tracing change.
We were reading our 64-bit value in I915_READ64 and returning 32 bits
of it. The restoration of fence regs at resume then had a zero end
value, and the fence had no effect.
Version 2: Split register access functions into per-size versions
Sharing code between different sizes seemed reasonable when we only
needed a single copy, but as 64-bit access requires its own version,
it makes sense to just split them out for each size.
Signed-off-by: Eric Anholt e...@anholt.net
Signed-off-by: Keith Packard kei...@keithp.com
---
On Thu, 18 Nov 2010 10:05:00 +0800, Eric Anholt e...@anholt.net wrote:
#define I915_READ8(reg) i915_read(dev_priv, (reg), 1)
#define I915_WRITE8(reg, val)i915_write(dev_priv, (reg), (val), 1)
#define I915_WRITE64(reg, val) i915_write(dev_priv, (reg), (val), 8)
-#define I915_READ64(reg) i915_read(dev_priv, (reg), 8)
+#define I915_READ64(reg) i915_read64(dev_priv, (reg))
Now that we've got two functions for this, it seems like it would be
better to just create per-size versions in both directions, otherwise
changes to the 8/16/32 bit version are unlikely to get propagated to the
64-bit version.
drivers/gpu/drm/i915/i915_drv.h | 106 ++
1 files changed, 61 insertions(+), 45 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 73a41f7..f83e712 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1237,14 +1237,14 @@ extern void intel_overlay_print_error_state(struct
seq_file *m, struct intel_ove
LOCK_TEST_WITH_RETURN(dev, file_priv); \
} while (0)
-#define I915_READ(reg) i915_read(dev_priv, (reg), 4)
-#define I915_WRITE(reg, val) i915_write(dev_priv, (reg), (val), 4)
-#define I915_READ16(reg) i915_read(dev_priv, (reg), 2)
-#define I915_WRITE16(reg, val) i915_write(dev_priv, (reg), (val), 2)
-#define I915_READ8(reg)i915_read(dev_priv, (reg), 1)
-#define I915_WRITE8(reg, val) i915_write(dev_priv, (reg), (val), 1)
-#define I915_WRITE64(reg, val) i915_write(dev_priv, (reg), (val), 8)
-#define I915_READ64(reg) i915_read(dev_priv, (reg), 8)
+#define I915_READ(reg) i915_read32(dev_priv, (reg))
+#define I915_WRITE(reg, val) i915_write32(dev_priv, (reg), (val))
+#define I915_READ16(reg) i915_read16(dev_priv, (reg))
+#define I915_WRITE16(reg, val) i915_write16(dev_priv, (reg), (val))
+#define I915_READ8(reg)i915_read8(dev_priv, (reg))
+#define I915_WRITE8(reg, val) i915_write8(dev_priv, (reg), (val))
+#define I915_WRITE64(reg, val) i915_write64(dev_priv, (reg), (val))
+#define I915_READ64(reg) i915_read64(dev_priv, (reg))
#define I915_READ_NOTRACE(reg) readl(dev_priv-regs + (reg))
#define I915_WRITE_NOTRACE(reg, val) writel(val, dev_priv-regs + (reg))
@@ -1254,27 +1254,32 @@ extern void intel_overlay_print_error_state(struct
seq_file *m, struct intel_ove
#define POSTING_READ(reg) (void)I915_READ_NOTRACE(reg)
#define POSTING_READ16(reg)(void)I915_READ16_NOTRACE(reg)
-static inline u32 i915_read(struct drm_i915_private *dev_priv, u32 reg, int
len)
+static inline u8 i915_read8(struct drm_i915_private *dev_priv, u32 reg)
{
- u64 val = 0;
-
- switch (len) {
- case 8:
- val = readq(dev_priv-regs + reg);
- break;
- case 4:
- val = readl(dev_priv-regs + reg);
- break;
- case 2:
- val = readw(dev_priv-regs + reg);
- break;
- case 1:
- val = readb(dev_priv-regs + reg);
- break;
- }
- trace_i915_reg_rw('R', reg, val, len);
-
- return val;
+ u8 val = readb(dev_priv-regs + reg);
+ trace_i915_reg_rw('R', reg, val, 1);
+ return val;
+}
+
+static inline u16 i915_read16(struct drm_i915_private *dev_priv, u32 reg)
+{
+ u16 val = readw(dev_priv-regs + reg);
+ trace_i915_reg_rw('R', reg, val, 2);
+ return val;
+}
+
+static inline u32 i915_read32(struct drm_i915_private *dev_priv, u32 reg)
+{
+ u32 val = readl(dev_priv-regs + reg);
+ trace_i915_reg_rw('R', reg, val, 4);
+ return val;
+}
+
+static inline u64 i915_read64(struct drm_i915_private *dev_priv, u32 reg)
+{
+ u64 val = readq(dev_priv-regs + reg);
+ trace_i915_reg_rw('R', reg, val, 8);
+ return val;
}
/* On SNB platform, before reading ring registers forcewake bit
@@ -1295,24 +1300,35 @@ static inline u32 i915_safe_read(struct
drm_i915_private *dev_priv, u32 reg)
}
static inline void
-i915_write(struct drm_i915_private *dev_priv, u32 reg, u64 val, int len)
+i915_write8(struct drm_i915_private *dev_priv, u32 reg, u8 val)
+{
+ /* Trace down the write operation before the real write */
+ trace_i915_reg_rw('W', reg, val, 1);
+ writeb(val, dev_priv-regs + reg);
+}
+
+static inline void
+i915_write16(struct
Re: [Intel-gfx] [PATCH] Dont use hardware acceleration on Sandybridge rev 07 hardware or earlier.
On Sat, 20 Nov 2010 16:17:40 +0100, Matthias Hopf mh...@suse.de wrote: I know, I know. The patch is (one of) the results of the Novell-HP-Intel workshop in Taipei this week. It turned out that rev07 is too unstable. Keith and Eric can probably comment on this. Better than I can. There's a work-around in the kernel for pre rev-8 hardware that ensures every time the blt ring is advanced by the CPU, the first command executes a batch buffer. So the hardware is obviously quite broken. This workaround doesn't work perfectly, and the GPU will still lock up when executing commands out of the blt ring from time to time. As pre rev-8 hardware is all pre-production, the workarounds should be removed From the driver and all acceleration disabled. -- keith.pack...@intel.com pgpPqpg9aeZpm.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] i915: display doesn't get on back after returning from standby in 2.6.27-rc*
On Fri, 26 Nov 2010 11:45:38 +0300, Dan Carpenter erro...@gmail.com wrote: Where are the patches? I pulled drm-next but I don't see them. Looks like he hasn't merged them. I'm building drm-intel-next with this and another patch. I've pushed my bits to git://people.freedesktop.org/~keithp/linux-2.6 drm-intel-next and will re-post my patches shortly. -- keith.pack...@intel.com pgp9ImK9mlBnC.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm: Set connector DPMS status to ON in drm_crtc_helper_set_config
When setting a new crtc configuration, force the DPMS state of all
connectors to ON. Otherwise, they'll be left at OFF and a future mode set
that disables the specified connector will not turn the connector off.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/drm_crtc_helper.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index f7af91c..232ee93 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -471,6 +471,7 @@ int drm_crtc_helper_set_config(struct drm_mode_set *set)
int count = 0, ro, fail = 0;
struct drm_crtc_helper_funcs *crtc_funcs;
int ret = 0;
+ int i;
DRM_DEBUG_KMS(\n);
@@ -666,6 +667,12 @@ int drm_crtc_helper_set_config(struct drm_mode_set *set)
if (ret != 0)
goto fail;
}
+ DRM_DEBUG_KMS(Setting connector DPMS state to on\n);
+ for (i = 0; i set-num_connectors; i++) {
+ DRM_DEBUG_KMS(\t[CONNECTOR:%d:%s] set DPMS on\n,
set-connectors[i]-base.id,
+ drm_get_connector_name(set-connectors[i]));
+ set-connectors[i]-dpms = DRM_MODE_DPMS_ON;
+ }
kfree(save_connectors);
kfree(save_encoders);
--
1.7.2.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm: record monitor status in output_poll_execute
In order to correctly report monitor connected status changes, the previous monitor status must be recorded in the connector-status value instead of being discarded. Signed-off-by: Keith Packard kei...@keithp.com --- drivers/gpu/drm/drm_crtc_helper.c |7 --- 1 files changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/drm_crtc_helper.c b/drivers/gpu/drm/drm_crtc_helper.c index 232ee93..7ca5935 100644 --- a/drivers/gpu/drm/drm_crtc_helper.c +++ b/drivers/gpu/drm/drm_crtc_helper.c @@ -848,7 +848,7 @@ static void output_poll_execute(struct work_struct *work) struct delayed_work *delayed_work = to_delayed_work(work); struct drm_device *dev = container_of(delayed_work, struct drm_device, mode_config.output_poll_work); struct drm_connector *connector; - enum drm_connector_status old_status, status; + enum drm_connector_status old_status; bool repoll = false, changed = false; if (!drm_kms_helper_poll) @@ -873,8 +873,9 @@ static void output_poll_execute(struct work_struct *work) !(connector-polled DRM_CONNECTOR_POLL_HPD)) continue; - status = connector-funcs-detect(connector, false); - if (old_status != status) + connector-status = connector-funcs-detect(connector, false); + DRM_DEBUG_KMS(connector status updated to %d\n, connector-status); + if (old_status != connector-status) changed = true; } -- 1.7.2.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm: record monitor status in output_poll_execute
On Sun, 5 Dec 2010 13:27:43 +0100, Florian Mickler flor...@mickler.org wrote: On Fri, 26 Nov 2010 10:45:59 -0800 Keith Packard kei...@keithp.com wrote: In order to correctly report monitor connected status changes, the previous monitor status must be recorded in the connector-status value instead of being discarded. Signed-off-by: Keith Packard kei...@keithp.com Keith, am I right to assume that these address https://bugzilla.kernel.org/show_bug.cgi?id=22672 and probably: https://bugzilla.kernel.org/show_bug.cgi?id=23472 Yes, this is part of the patch for that. The other piece is in the 2D driver which has a matching bug. That patch is already on master. -- keith.pack...@intel.com pgpM9kFt2qKdC.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm: record monitor status in output_poll_execute
On Wed, 08 Dec 2010 17:08:04 +, Chris Wilson ch...@chris-wilson.co.uk wrote: On Wed, 8 Dec 2010 17:34:24 +0100, Florian Mickler flor...@mickler.org wrote: Does that mean that the kernel regression will not be fixed/worked-around for old userspace? I think there is some confusion in that I believe there is more than one backlight bug at play here. The kernel and user space fixes addressed the same technical problem (failing to note that mode setting turned on the devices), but the symptoms that this caused were different; in kernel mode, the result would be that monitors would be left turned on when user space asked that they be turned off (and left pointing at random memory too, which was amusing). I think that the backlight issue was caused by the user-space bug though. -- keith.pack...@intel.com pgp4vwYhcKF1G.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: Aggressively disable vblanks
On Mon, 20 Dec 2010 14:00:54 -0500, Andy Lutomirski l...@mit.edu wrote: Enabling and disabling the vblank interrupt (on devices that support it) is cheap. So disable it quickly after each interrupt. So, the concern (and reason for the original design) was that you might lose count of vblank interrupts as vblanks are counted differently while off than while on. If vblank interrupts get enabled near the interrupt time, is it possible that you'll end up off by one somehow? Leaving them enabled for 'a while' was supposed to reduce the impact of this potential error. -- keith.pack...@intel.com pgp1WPigkwuSH.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: Aggressively disable vblanks
On Mon, 20 Dec 2010 22:34:12 -0500, Andrew Lutomirski l...@mit.edu wrote: But five seconds is a *long* time, and anything short enough that the interrupt actually gets turned off in normal use risks the same race. Right, so eliminating any race seems like the basic requirement. Can that be done? -- keith.pack...@intel.com pgp31LH1iDy70.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: no LVDS on Intel SandyBridge SDVs
On Tue, 21 Dec 2010 11:36:44 +, Chris Wilson ch...@chris-wilson.co.uk wrote: I think once upon a time I found a reliable method in the docs: intel_lvds_ddc_probe(). However that only seemed to work over GMBUS... That probably depends on the panel having DDC, which many don't, right? Maybe we can assume the SDV panels do? -- keith.pack...@intel.com pgpq3HsNiLePt.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: no LVDS on Intel SandyBridge SDVs
On Tue, 21 Dec 2010 19:55:15 +, Chris Wilson ch...@chris-wilson.co.uk wrote: The test we do is simply whether the LVDS i2c pins are addressable. That requires differentiating between an IO error and a NAK, which at present is only possible using GMBUS. The reference to this method I found in the BIOS writers' guide, but of course that doesn't actually explain how it works (especially the significance of address 0xa0). I can't see how that would work without an i2c receiver on the DDC bus... But, then, I've been surprised by DDC in the past, so perhaps it's worth a test on a device that has LVDS but does not have EDID. -- keith.pack...@intel.com pgpHpRYzb44Jw.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Recognise non-VGA display devices
On Thu, 20 Jan 2011 15:07:07 +, Chris Wilson ch...@chris-wilson.co.uk
wrote:
+ if (dev_priv-is_vga) {
+ /* If we have 1 VGA cards with a single output,
+ * then disable the radeon VGA resources.
+ */
Why does this say 'radeon'?
--
keith.pack...@intel.com
pgp42d1EEvhI4.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Difference in dot clock between xserver 1.5.2 and 1.9.4 - intel driver
On Mon, 28 Feb 2011 03:54:24 -0800 (PST), SD sd.dom...@yahoo.com wrote: (II) intel(0): using SSC reference clock of 96 MHz That's the spread-spectrum clock reference value; it forms the basis From which the actual dot clock is computed using a PLL. It is *not* the actual dot clock. [ 135.556] (II) intel(0): clock: 65.0 MHz Image Size: 304 x 228 mm And there's the actual dot clock. And in MHz can be only dot clock, but if I use 1024x768x60Hz = ~ 47.2 MHz and we need to multiply on 3 (subpixels), it will be ~140 MHz I know that 96 in xserver 1.5.2 is not 140 but it is much closer to it, then 65. You don't multiply by three; each channel has it's own wire in LVDS. But, you have to add space for the retrace intervals. The standard VESA mode for 1024x768x60 uses a 65MHz dot clock. Why in xserver 1.5.2 intel driver shows 96 MHz but in 1.9.4 it does only 65 MHz. And can it be the reason why my LCD shows picture like it use less then 50Hz vsync. I'll bet both are using the same timings, but you can check for yourself with the 'xrandr' utility: $ xrandr --verbose ... 1440x900 (0x45) 74.1MHz -HSync -VSync *current +preferred h: width 1440 start 1464 end 1480 total 1600 skew0 clock 46.3KHz v: height 900 start 903 end 909 total 926 clock 50.0Hz ... The mode marked '*current' is what the system is currently using. You can help figure out what the problem is by running the 'intel_reg_dumper' utility on both distributions. That's available from: git://anongit.freedesktop.org/git/xorg/app/intel-gpu-tools Doing a 'diff' on the output of this under the two operating systems will show every change in programming for your machine. -- keith.pack...@intel.com pgpUMQwVUe5HL.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/8] drm/i915: Remove surplus POSTING_READs before wait_for_vblank
On Fri, 18 Mar 2011 08:02:03 +, Chris Wilson ch...@chris-wilson.co.uk wrote: ... as wait_for_vblank (and friends) will do a flush of the MMIO writes anyway. This one seems reasonable. Reviewed-by: Keith Packard kei...@keithp.com -- keith.pack...@intel.com pgppxraae0dbT.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/8] drm/i915: skip redundant operations whilst enabling pipes and planes
On Fri, 18 Mar 2011 08:02:04 +, Chris Wilson ch...@chris-wilson.co.uk wrote: If the pipe or plane is already enabled, then we do not need to enable it again and can skip the delay. This should mention that you're also skipping the operation on disable. Otherwise, Reviewed-by: Keith Packard kei...@keithp.com -- keith.pack...@intel.com pgpXxntWc3ylI.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/8] drm/i915: Flush the plane enable using the DSPCNTR latch
This comment is misleading -- the patch replaces a call to intel_wait_for_vblank with a call to intel_flush_display_plane. From my reading of the docs, enable requires two actions: 1) DSPACNTR with enable going from 0-1 2) wait for vblank At disable, three actions are required: 1) DSPACNTR with enable going from 1-0 2) DSPASURF(965+)/DSPAADDR(otherwise) write to trigger the register updates 3) wait for vblank -- keith.pack...@intel.com pgpNHt2Wh8Qu0.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/8] drm: Fix use-after-free in drm_gem_vm_close()
On Fri, 18 Mar 2011 08:02:08 +, Chris Wilson ch...@chris-wilson.co.uk wrote: As we may release the last reference, we need to store the device in a local variable in order to unlock afterwards. Reviewed-by: Keith Packard kei...@keithp.com -- keith.pack...@intel.com pgpHcqpgV3keH.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/8] drm/i915: Re-enable self-refresh
On Fri, 18 Mar 2011 08:02:09 +, Chris Wilson ch...@chris-wilson.co.uk wrote: A broken implementation of is_pot() prevented the detection of when a singular pipe was enabled. - return mask (mask -mask) == 0; + return mask (mask -mask) == mask; I think the form mask (mask (mask - 1)) == 0 is easier to reason about. But, your fix is also correct as it finds the lowest bit set in 'mask' and checks to see if that is the same as mask. Reviewed-by: Keith Packard kei...@keithp.com -- keith.pack...@intel.com pgpK3403Fm1hC.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/15] drm/i915: Enable use of GPU semaphores to sync page-flips on SNB
Might be nice to have the patch message mention that the bulk of this patch is simply renaming and moving i915_gem_execbuffer_sync_rings. In fact, doing this in two patches would make the actual change a whole lot easier to find. -- keith.pack...@intel.com pgpogFDNCbIgt.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/4] drm/i915: save/restore DSPARB only for chips before gen4 but not for G33
On Wed, 23 Mar 2011 10:21:07 +0800, Zhenyu Wang zhen...@linux.intel.com wrote: DSPARB is reserved on G33 and not available on Gen6. Does this fix a reported problem? Or just spec compliance? -- keith.pack...@intel.com pgpSsTjeknBqr.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] xf86-video-intel: 3 commits - src/intel_display.c src/intel_dri.c src/intel.h
On Thu, 24 Mar 2011 02:02:56 +0100, Julien Cristau jcris...@debian.org wrote:
Hi Keith,
a couple suggestions below from a quick look over these patches.
Thanks for your review!
static void
intel_vblank_handler(int fd, unsigned int frame, unsigned int tv_sec,
- unsigned int tv_usec, DRI2FrameEventPtr event)
+ unsigned int tv_usec, void *event)
This seems to just revert a change from the previous commit?
Sadly, yes -- intel_vblank_handler gets stuffed into the
event_context.vblank_handler callback slot which uses 'void *' in the
function signature. As DRI2FrameEventPtr is a private type, we can't go
fix the public drmEventContext type to match.
A cleaner patch sequence would have removed the change from both
patches. Oops!
+ i830_dri2_add_frame_event(flip_info);
+
if (!i830_dri_add_frame_event(flip_info))
return FALSE;
?
...
+ i830_dri2_add_frame_event(swap_info);
+
if (!i830_dri2_add_frame_event(swap_info)
goto blit_fallback;
?
Good catch. Not quite that easy to fix; the swap_info needs to be freed,
and a partial add_frame_event must clean up after itself.
diff --git a/src/intel_dri.c b/src/intel_dri.c
index 3b80823..f7a4fc4 100644
--- a/src/intel_dri.c
+++ b/src/intel_dri.c
@@ -625,8 +625,10 @@ i830_dri2_add_frame_event(DRI2FrameEventPtr frame_event)
if (!AddResource(frame_event-client_id, frame_event_client_type,
frame_event))
return FALSE;
- if (!AddResource(frame_event-drawable_id, frame_event_drawable_type,
frame_event))
+ if (!AddResource(frame_event-drawable_id, frame_event_drawable_type,
frame_event)) {
+ FreeResourceByType(frame_event-client_id,
frame_event_client_type, TRUE);
return FALSE;
+ }
return TRUE;
}
@@ -705,7 +707,10 @@ I830DRI2ScheduleFlip(struct intel_screen_private *intel,
flip_info-event_data = data;
flip_info-frame = target_msc;
- i830_dri2_add_frame_event(flip_info);
+ if (!i830_dri2_add_frame_event(flip_info)) {
+ free(flip_info);
+ return FALSE;
+ }
/* Page flip the full screen buffer */
back_priv = back-driverPrivate;
@@ -958,7 +963,10 @@ I830DRI2ScheduleSwap(ClientPtr client, DrawablePtr draw,
DRI2BufferPtr front,
I830DRI2ReferenceBuffer(front);
I830DRI2ReferenceBuffer(back);
- i830_dri2_add_frame_event(swap_info);
+ if (!i830_dri2_add_frame_event(swap_info)) {
+ free(swap_info);
+ goto blit_fallback;
+ }
/* Get current count */
vbl.request.type = DRM_VBLANK_RELATIVE;
--
keith.pack...@intel.com
pgp0FnlpYONkN.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/lvds: Always return connected in the absence of better information
Reviewed-by: Keith Packard kei...@keithp.com -- keith.pack...@intel.com pgpS0hlmwj2Q7.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] xf86-video-intel: 3 commits - src/intel_display.c src/intel_dri.c src/intel.h
On Thu, 24 Mar 2011 19:31:03 +0100, Julien Cristau jcris...@debian.org wrote:
This will cause a double free as the blit_fallback path does it too.
Argh! So we need to check before we reference the buffers and set
swap_info to NULL. This code is too twisty...
@@ -955,11 +960,16 @@ I830DRI2ScheduleSwap(ClientPtr client, DrawablePtr draw,
DRI2BufferPtr front,
swap_info-event_data = data;
swap_info-front = front;
swap_info-back = back;
+
+ if (!i830_dri2_add_frame_event(swap_info)) {
+ free(swap_info);
+ swap_info = NULL;
+ goto blit_fallback;
+ }
+
I830DRI2ReferenceBuffer(front);
I830DRI2ReferenceBuffer(back);
- i830_dri2_add_frame_event(swap_info);
-
/* Get current count */
vbl.request.type = DRM_VBLANK_RELATIVE;
if (pipe 0)
--
keith.pack...@intel.com
pgpIBpvlcMprb.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] xf86-video-intel: 3 commits - src/intel_display.c src/intel_dri.c src/intel.h
On Fri, 25 Mar 2011 00:57:10 +0100, Julien Cristau jcris...@debian.org wrote: With that change, Reviewed-by: Julien Cristau jcris...@debian.org Thanks for catching my bugs before they caused any damage... Pushed. ec133ab..7ccbec8 master - master -- keith.pack...@intel.com pgpJ72WCEledy.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Reset GMBUS controller after NAK
On Wed, 30 Mar 2011 17:59:51 +0100, Chris Wilson ch...@chris-wilson.co.uk wrote: I'm not even sure we need the first posting read. Maybe it should be a wait_for(I915_READ(GMBUS1 + reg_offset) GMBUS_SW_CLR_INT, 100) to be clearer that we are simply giving the hardware the chance to assert the bit and reset before re-enabling. Doesn't look like the hardware actually delays in setting this bit, so your original sequence should be correct. Of course, a comment indicating that you're toggling the SW_CLR_INT bit to reset the bus might be nice. No, GMBUS0 is not read until the very first phase of the data cycle. And the very first thing we do in the next xfer is a write to GMBUS0 of the port settings. I just thought that explicitly marking the GMBUS controller as disabled when not in use by us would lead to less confusion in future. Sounds reasonable. I'd love to have seen a comment in the code and in the patch... -- keith.pack...@intel.com pgpTjMSsYvxW6.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915/crt: Remove 0xa0 probe for CRT
On Mon, 4 Apr 2011 07:26:44 +0100, Chris Wilson ch...@chris-wilson.co.uk wrote: Following the fix to reset the GMBUS controller after a NAK, we finally utilize the 0xa0 probe for a CRT connection. And discover that it is useless as it simply detects the presence of the controller and not the actual monitor. Given that we already probe 0x50 prior to performing the EDID retrieval, we can simply remove the redundant probe to 0xa0. I don't understand -- are you saying that there is additional hardware somewhere in the machine responding to I2C transactions on the monitor's DDC bus? And if so, how was this extra transaction breaking things? The GMBUS reset patch should only have an effect when there are failed transactions, not successful ones, and then it should only cause future transactions to fail, not succeed. Besides, the 0xA0 transaction looks like the first one on the bus. -- keith.pack...@intel.com pgpuoh7uXJOug.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915/crt: Explicitly return false if connected to a digital monitor
On Mon, 4 Apr 2011 07:26:45 +0100, Chris Wilson ch...@chris-wilson.co.uk wrote: Rather than proceed on to the next test, return the result from detecting a connection but to a digital panel and include some debug output as to why. I'm worried that this will falsely reject some monitors with broken EDID information. -- keith.pack...@intel.com pgppZGr7ezmYv.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915/crt: Remove 0xa0 probe for CRT
On Tue, 5 Apr 2011 10:19:16 +1000, Dave Airlie airl...@gmail.com wrote: On Tue, Apr 5, 2011 at 2:26 AM, Keith Packard kei...@keithp.com wrote: On Mon, 04 Apr 2011 16:29:55 +0100, Chris Wilson ch...@chris-wilson.co.uk wrote: Yes. I'm saying that that the controller accepts a write to port 0xa0. So it's the GMBUS controller itself then, I guess. Weird. Let me see if I understand how it used to work and why fixing the GMBUS reset causes it to break in this case. I could be missing something here, but aren't i2c addresses 8-bit in this case? 7-bit addr + direction bit, which means 0xa0 isn't valid i2c address, since in Linux the read/write bits are specified separately. Could this be is a mis-translation of some X server code? The X server stuck the direction bit in the LSB of the I2C address and required that the drivers shift the register up and add the direction bit manually (yes, a terrible API). This is starting to make a lot more sense now. 0xa0 == 0x50 1. -- keith.pack...@intel.com pgp4hpjbXLeX3.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915/crt: Remove 0xa0 probe for CRT
On Mon, 4 Apr 2011 07:26:44 +0100, Chris Wilson ch...@chris-wilson.co.uk wrote: Following the fix to reset the GMBUS controller after a NAK, we finally utilize the 0xa0 probe for a CRT connection. And discover that it is useless as it simply detects the presence of the controller and not the actual monitor. Given that we already probe 0x50 prior to performing the EDID retrieval, we can simply remove the redundant probe to 0xa0. This looks like a revert of 6ec3d0c0e9c0c605696e91048eebaca7b0c36695. I'd rather see it as that than a new patch. -- keith.pack...@intel.com pgpWuEExTVjlR.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/5] drm/i915/crt: Explicitly return false if connected to a digital monitor
On Tue, 5 Apr 2011 10:24:15 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
Rather than proceed on and return false by default, return the result
from detecting a connection but to a digital panel and include some
debug output as to why.
This comment does not match the patch anymore; there is no new return
point, just an added comment (which doesn't even need to be in an else
block now).
+ } else {
+ DRM_DEBUG_KMS(CRT not detected via DDC:0x50 [EDID
reports a digital panel]\n);
--
keith.pack...@intel.com
pgpFLXWUxM0mo.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/5] drm/i915/gmbus: Reset the controller on initialisation
On Tue, 5 Apr 2011 10:24:18 +0100, Chris Wilson ch...@chris-wilson.co.uk wrote: Toggle the Software Clear Interrupt bit which resets the controller to clear any prior BUS_ERROR condition before we begin to use the controller in earnest. We do this in two places now, do we want to share the code? + int reg_offset; + + reg_offset = 0; if (HAS_PCH_SPLIT(dev)) - I915_WRITE(PCH_GMBUS0, 0); - else - I915_WRITE(GMBUS0, 0); + reg_offset = PCH_GMBUS0 - GMBUS0; + + /* First reset the controller by toggling the Sw Clear Interrupt. */ + I915_WRITE(GMBUS1 + reg_offset, GMBUS_SW_CLR_INT); + I915_WRITE(GMBUS1 + reg_offset, 0); + + /* Then mark the controller as disabled. */ + I915_WRITE(GMBUS0 + reg_offset, 0); That's really ugly register addressing, but it looks like a common idiom in this file... -- keith.pack...@intel.com pgpSLIU6yencK.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/5] drm/i915: Initialise g4x watermarks for disabled pipes
On Tue, 05 Apr 2011 22:12:19 +0100, Chris Wilson ch...@chris-wilson.co.uk wrote: Indeed, I started by setting them to zero in the caller. Decided that there was some precedent to use the guard_size as the minimum value for unused planes (and so perhaps the unused planes on the unused pipes) and so it was then natural to do it inside g4x_compute_wm. I guess it all depends on how many FIFOs are split between the pipes. Using guard_size, I believe, should be safest. guard_size is probably better than random stack stuff. Any opinion on whether this should be done in g4x_update_wm instead of g4x_compute_wm0? -- keith.pack...@intel.com pgp0GEXlB17OK.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Clear any errors recorded before i915.ko is loaded
On Tue, 5 Apr 2011 23:00:46 +0100, Chris Wilson ch...@chris-wilson.co.uk wrote: This looks like it fixes two bugs: 1) What if there is an error recorded before we start and so we immediately service an IIR/EIR upon intalling the IRQ. Did we generate that error during initialisation or was that SEP? Now we do stuff before we even install the IRQ so there is a possibility that we zap one of our own. How will processing a pre-existing error condition cause trouble? Does EIR even persist between phases to cause these issues in the first place? Yeah, seems like a bit of testing might be able to check this fairly quickly. -- keith.pack...@intel.com pgp2xYmIcDwzI.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/5] drm/i915: Initialise g4x watermarks for disabled pipes
On Wed, 06 Apr 2011 09:02:22 +0100, Chris Wilson ch...@chris-wilson.co.uk wrote: Looks like we can now indeed merge g4x_compute_wm0 and ironlake_compute_wm0 and ignore the off-values for gen5+. They do seem surprisingly similar at this point... So fix the use of uninitialised values for -fixes and remove the redundant copy in -next? Sounds good. -- keith.pack...@intel.com pgpCYhMCN9hqy.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Sanitize the output registers after resume
On Tue, 12 Apr 2011 18:06:51 +0100, Chris Wilson ch...@chris-wilson.co.uk wrote: This patch rearranges the code we already have to clear up the conflicting state upon init and calls it from reset (which is called after we have lost control of the hardware, i.e. along both the boot and resume paths) instead. Note that intel_sanitize_modesetting does not do anything on PCH hardware yet. Otherwise, this looks like a reasonable plan. Reviewed-by: Keith Packard kei...@keithp.com -- keith.pack...@intel.com pgpiMvU9734pI.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] force wake reference counting (another try)
On Tue, 12 Apr 2011 18:31:51 -0700, Ben Widawsky b...@bwidawsk.net wrote: I think we have no other option since the first thing that i915_driver_irq_handler() does is read IIR, which according to the limited knowledge I have requires forcewake. I think the eventual plan will be to figure out if there are any frequently used registers which *don't* require forcewake. -- keith.pack...@intel.com pgpZdQ5lMaR4C.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/13] drm/i915: Rename agp_type to cache_level
On Thu, 14 Apr 2011 10:03:35 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
... to clarify just how we use it inside the driver. We still need to
translate through agp_type for interface into the fake AGP driver.
agp_type has some really confusing semantics...
- obj-agp_type = AGP_USER_MEMORY;
+ obj-cache_level = I915_CACHE_NONE;
AGP_USER_MEMORY is indeed uncached, so this is correct.
+/* XXX kill agp_type! */
+static uint32_t cache_level_to_agp_type(struct drm_device *dev,
+ enum i915_cache_level cache_level)
This should be unsigned int to match the users of this value
+ switch (cache_level) {
+ case I915_CACHE_LLC_MLC:
+ if (INTEL_INFO(dev)-gen = 6)
+ return AGP_USER_CACHED_MEMORY_LLC_MLC;
I like to see a comment here:
+ /* Fall through ... */
+ case I915_CACHE_LLC:
+ return AGP_USER_CACHED_MEMORY;
+ default:
+ case I915_CACHE_NONE:
+ return AGP_USER_MEMORY;
+ }
list_for_each_entry(obj, dev_priv-mm.gtt_list, gtt_list) {
+ int agp_type = cache_level_to_agp_type(dev, obj-cache_level);
+
This should be 'unsigned int' to match the signature of
intel_gtt_insert_sg_entries and intel_gtt_insert_pages.
--
keith.pack...@intel.com
pgpjSJeaPoFev.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm/i915: Attach a fb to the load-detect pipe
On Tue, 19 Apr 2011 21:32:02 +0100, Chris Wilson ch...@chris-wilson.co.uk wrote: We need to ensure that we feed valid memory into the display plane attached to the pipe when switching the pipe on. Otherwise, the display engine may read through an invalid PTE and so throw an PGTBL_ER exception. This seems to rewrite most of the load detection code, but doesn't justify that rewrite in comments (either commit or in-line). You'll need to break this up so that we can actually see what is changing. -- keith.pack...@intel.com pgpMiffuFj5GY.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/dp: Be paranoid in case we disable a DP before it is attached
On Wed, 20 Apr 2011 16:42:08 +0100, Chris Wilson ch...@chris-wilson.co.uk wrote: Given that the hardware may be left in a random condition by the BIOS, it is conceivable that we then attempt to clear the DP_PIPEB_SELECT bit without us ever enabling/attaching the DP encoder to a pipe. Thus causing a NULL deference when we attempt to wait for a vblank on that crtc. Is this because we're assuming that the only way DP_PIPEB_SELECT could have been set is by our driver? That does seem like a bad assumption on our part. - intel_wait_for_vblank(dev, intel_crtc-pipe); + intel_wait_for_crtc_vblank_safe(intel_dp-base.base.crtc); I actually think that simply placing the in-line function here in the code is clearer -- it makes it obvious that we aren't counting on there being a crtc assigned to this output. -- keith.pack...@intel.com pgp6Z6raKpoA8.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/6] drm/i915: Simplify return value from intel_get_load_detect_pipe
On Wed, 20 Apr 2011 10:22:17 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
+
+ if (!drm_crtc_helper_set_mode(crtc, mode, 0, 0, crtc-fb)) {
+ DRM_DEBUG_KMS(failed to set mode on load-detect
pipe\n);
+ return false;
+ }
This seems like a bug-fix, separate from the API change.
--
keith.pack...@intel.com
pgpWcrq8xCAcd.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/6] drm/i915: Don't store temporary load-detect variables in the generic encoder
On Wed, 20 Apr 2011 10:22:18 +0100, Chris Wilson ch...@chris-wilson.co.uk wrote: Keep all the state required for undoing and restoring the previous pipe configuration together in a single struct passed from intel_get_load_detect_pipe() to intel_release_load_detect_pipe() rather than stuffing them inside the common encoder structure. Reviewed-by: Keith Packard kei...@keithp.com -- keith.pack...@intel.com pgpIyuZ6gZHYI.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/6] drm/i915: Pass the saved adjusted_mode when adding to the load-detect crtc
On Wed, 20 Apr 2011 10:22:20 +0100, Chris Wilson ch...@chris-wilson.co.uk wrote: Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk Reviewed-by: Keith Packard kei...@keithp.com (this might be separately tested to see if it might fix some TV load detection issues?) -- keith.pack...@intel.com pgpnWymRFWXkU.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/6] drm/i915: Pass the saved adjusted_mode when adding to the load-detect crtc
On Wed, 20 Apr 2011 20:38:54 +0100, Chris Wilson ch...@chris-wilson.co.uk wrote: On Wed, 20 Apr 2011 11:23:01 -0700, Keith Packard kei...@keithp.com wrote: On Wed, 20 Apr 2011 10:22:20 +0100, Chris Wilson ch...@chris-wilson.co.uk wrote: Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk Reviewed-by: Keith Packard kei...@keithp.com (this might be separately tested to see if it might fix some TV load detection issues?) It is an old bug along a dead code path. It can simply be squashed with the next patch that removes it entirely, if you prefer. Right, I didn't look forward to see that it was in 're-use existing pipe' path which has been dead for a long time now. -- keith.pack...@intel.com pgpoydphRoD5z.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/6] drm/i915: Attach a fb to the load-detect pipe
On Wed, 20 Apr 2011 19:55:10 +0100, Chris Wilson ch...@chris-wilson.co.uk wrote: I'll spin up a patch for a temporary buffer and see what you think. Ok. I'd love to be able to use that code path all of the time, but I don't like the thought of the cost of a temporary allocation every time you do load detection. -- keith.pack...@intel.com pgptX1TbfuxdV.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Pending i915 fixes
On Thu, 21 Apr 2011 22:18:15 +0100, Chris Wilson ch...@chris-wilson.co.uk wrote: Whilst this may appear to be a big batch, it is actually only a few bug fixes from the last couple of weeks broken down into small steps. Do you think any of these are needed in .39? -- keith.pack...@intel.com pgpAZG9Gv4Qio.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: fix intel_crtc_get_clock pipe reads after cleanup
On Fri, 22 Apr 2011 22:22:28 +0100, Chris Wilson ch...@chris-wilson.co.uk wrote: fp = FP0(pipe); else fp = FP1(pipe); + fp = I915_READ(fp); Please use different variables for the offset vs the value... -- keith.pack...@intel.com pgpaGbAUtaJf4.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] fix interrupt request miss problem in bsd ring for g4x
On Tue, 26 Apr 2011 18:12:52 +0800, Feng, Boqun boqun.f...@intel.com wrote: Signed-off-by: Feng, Boqun boqun.f...@intel.com Please add a description here of what the bug was and how this fixes it. -- keith.pack...@intel.com pgph19eyUhT0a.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/16] drm/i915: add PantherPoint PCH ID
On Tue, 26 Apr 2011 16:38:45 -0700, Jesse Barnes jbar...@virtuousgeek.org wrote: We can treat PantherPoint as CougarPoint as far as display goes. I'll note in passing that pch_type is never set to PCH_IBX explicitly, which only works because PCH_IBX is zero. -- keith.pack...@intel.com pgpz4oSyZkoyH.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 11/16] drm/i915: manual FDI training for Ivy Bridge
On Tue, 26 Apr 2011 16:38:49 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
A0 stepping chips need to use manual training, but the bits have all
moved. So fix things up so we can at least train FDI for VGA links.
This patch should be before the auto-train patch so that we don't have
a broken driver between them.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_reg.h | 10 +++
drivers/gpu/drm/i915/intel_display.c | 129
+-
2 files changed, 136 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index b77bd49..03c99ed 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3105,7 +3105,15 @@
#define FDI_TX_ENHANCE_FRAME_ENABLE(118)
/* Ironlake: hardwired to 1 */
#define FDI_TX_PLL_ENABLE (114)
+
+/* Ivybridge has different bits for lolz */
+#define FDI_LINK_TRAIN_PATTERN_1_IVB (08)
+#define FDI_LINK_TRAIN_PATTERN_2_IVB (18)
+#define FDI_LINK_TRAIN_PATTERN_IDLE_IVB(28)
+#define FDI_LINK_TRAIN_NONE_IVB(38)
+
/* both Tx and Rx */
+#define FDI_LINK_TRAIN_AUTO (110)
#define FDI_SCRAMBLING_ENABLE (07)
#define FDI_SCRAMBLING_DISABLE (17)
/* Ivybridge */
@@ -3117,6 +3125,8 @@
#define FDI_RX_CTL(pipe) _PIPE(pipe, _FDI_RXA_CTL, _FDI_RXB_CTL)
#define FDI_RX_ENABLE (131)
/* train, dp width same as FDI_TX */
+#define FDI_FS_ERRC_ENABLE (127)
+#define FDI_FE_ERRC_ENABLE (126)
#define FDI_DP_PORT_WIDTH_X8 (719)
#define FDI_8BPC (016)
#define FDI_10BPC (116)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index db46e4f..866abe5 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2047,8 +2047,13 @@ static void intel_fdi_normal_train(struct drm_crtc
*crtc)
/* enable normal train */
reg = FDI_TX_CTL(pipe);
temp = I915_READ(reg);
- temp = ~FDI_LINK_TRAIN_NONE;
- temp |= FDI_LINK_TRAIN_NONE | FDI_TX_ENHANCE_FRAME_ENABLE;
+ if (IS_GEN6(dev)) {
+ temp = ~FDI_LINK_TRAIN_NONE;
+ temp |= FDI_LINK_TRAIN_NONE | FDI_TX_ENHANCE_FRAME_ENABLE;
+ } else if (IS_IVYBRIDGE(dev)) {
+ temp = ~FDI_LINK_TRAIN_NONE_IVB;
+ temp |= FDI_LINK_TRAIN_NONE_IVB | FDI_TX_ENHANCE_FRAME_ENABLE;
+ }
I915_WRITE(reg, temp);
reg = FDI_RX_CTL(pipe);
@@ -2065,6 +2070,11 @@ static void intel_fdi_normal_train(struct drm_crtc
*crtc)
/* wait one idle pattern time */
POSTING_READ(reg);
udelay(1000);
+
+ /* IVB wants error correction enabled */
+ if (IS_IVYBRIDGE(dev))
+ I915_WRITE(reg, I915_READ(reg) | FDI_FS_ERRC_ENABLE |
+FDI_FE_ERRC_ENABLE);
}
/* The FDI link training functions for ILK/Ibexpeak. */
@@ -2292,6 +2302,115 @@ static void gen6_fdi_link_train(struct drm_crtc *crtc)
DRM_DEBUG_KMS(FDI train done.\n);
}
+/* Manual link training for Ivy Bridge A0 parts */
+static void ivb_manual_fdi_link_train(struct drm_crtc *crtc)
+{
+ struct drm_device *dev = crtc-dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ int pipe = intel_crtc-pipe;
+ u32 reg, temp, i;
+
+ /* Train 1: umask FDI RX Interrupt symbol_lock and bit_lock bit
+for train result */
+ reg = FDI_RX_IMR(pipe);
+ temp = I915_READ(reg);
+ temp = ~FDI_RX_SYMBOL_LOCK;
+ temp = ~FDI_RX_BIT_LOCK;
+ I915_WRITE(reg, temp);
+
+ POSTING_READ(reg);
+ udelay(150);
+
+ /* enable CPU FDI TX and PCH FDI RX */
+ reg = FDI_TX_CTL(pipe);
+ temp = I915_READ(reg);
+ temp = ~(7 19);
+ temp |= (intel_crtc-fdi_lanes - 1) 19;
+ temp = ~(FDI_LINK_TRAIN_AUTO | FDI_LINK_TRAIN_NONE_IVB);
+ temp |= FDI_LINK_TRAIN_PATTERN_1_IVB;
+ temp = ~FDI_LINK_TRAIN_VOL_EMP_MASK;
+ temp |= FDI_LINK_TRAIN_400MV_0DB_SNB_B;
+ I915_WRITE(reg, temp | FDI_TX_ENABLE);
+
+ reg = FDI_RX_CTL(pipe);
+ temp = I915_READ(reg);
+ temp = ~FDI_LINK_TRAIN_AUTO;
+ temp = ~FDI_LINK_TRAIN_PATTERN_MASK_CPT;
+ temp |= FDI_LINK_TRAIN_PATTERN_1_CPT;
+ I915_WRITE(reg, temp | FDI_RX_ENABLE);
+
+ POSTING_READ(reg);
+ udelay(150);
+
+ for (i = 0; i 4; i++ ) {
+ reg = FDI_TX_CTL(pipe);
+ temp = I915_READ(reg);
+ temp = ~FDI_LINK_TRAIN_VOL_EMP_MASK;
+ temp |= snb_b_fdi_train_param[i];
+ I915_WRITE(reg, temp);
+
+ POSTING_READ(reg);
+ udelay(500);
+
+ reg = FDI_RX_IIR(pipe);
+ temp = I915_READ(reg);
+ DRM_DEBUG_KMS(FDI_RX_IIR
Re: [Intel-gfx] [PATCH 1/2] drm/i915:merge ring_put/get_irq into bsd_ring_put/get_irq
On Wed, 27 Apr 2011 15:41:18 +0800, Feng, Boqun boqun.f...@intel.com wrote: Remove ring_put_irq/ring_get_irq:drivers/gpu/drm/i915/intel_ringbuffer.c , they are only used by bsd_ring_put_irq/bsd_ring_get_irq. Expand the code in bsd_ring_put_irq/bsd_ring_get_irq. Why is this change useful? -- keith.pack...@intel.com pgpHOOQFp5LL8.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915:merge ring_put/get_irq into bsd_ring_put/get_irq
On Thu, 28 Apr 2011 10:06:51 +0800, Feng, Boqun boqun.f...@intel.com wrote: I have discussed this with Chris in my earlier patch. This change is a clean-up, since ring_put_irq and ring_get_irq are only used by bsd_ring_put_irq and bsd_ring_get_irq. And once this change is made, it is more clear to see the difference between g4x and ironlake BSD interrupt control interface, because they are handled in a single function and they are different at the interrupt mask reg addresss as well as the interrupt flag please put important details like that in the commit message; having some way to evaluate the utility of the patch is very important for something which doesn't actually change how the code works. -- keith.pack...@intel.com pgpuVK3a9n7El.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/19] drm/i915: make FDI training a display function
On Thu, 28 Apr 2011 15:12:47 -0700, Jesse Barnes jbar...@virtuousgeek.org wrote: Rather than branching in ironlake_pch_enable, add a new train_fdi function to the display function pointer struct and use it instead. Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org Reviewed-by: Keith Packard kei...@keithp.com -- keith.pack...@intel.com pgpkV3NopGSL6.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/19] drm/i915: split irq handling into per-chipset functions
On Thu, 28 Apr 2011 15:12:48 -0700, Jesse Barnes jbar...@virtuousgeek.org wrote: Set the IRQ handling functions in driver load so they'll just be used directly, rather than branching over most of the code in the chipset functions. Reviewed-by: Keith Packard kei...@keithp.com -- keith.pack...@intel.com pgp2AbBeCyLbw.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/19] drm/i915: split enable/disable vblank code into chipset specific functions
On Thu, 28 Apr 2011 15:12:49 -0700, Jesse Barnes jbar...@virtuousgeek.org wrote: This makes the Ironlake+ code trivial and generally simplifies things. Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org Reviewed-by: Keith Packard kei...@keithp.com -- keith.pack...@intel.com pgpmUuBtFRc86.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/19] drm/i915: add IS_GEN7 macro to cover Ivy Bridge and later
On Thu, 28 Apr 2011 15:12:50 -0700, Jesse Barnes jbar...@virtuousgeek.org wrote: Note: IS_GEN* are for render related checks. Display and other checks should use IS_MOBILE, IS_$CHIPSET or test for specific features. Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org Reviewed-by: Keith Packard kei...@keithp.com -- keith.pack...@intel.com pgpsB6S4fLOTt.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 05/19] drm/i915: add IS_IVYBRIDGE macro for checks
On Thu, 28 Apr 2011 15:12:51 -0700, Jesse Barnes jbar...@virtuousgeek.org wrote: I don't see a patch in this series that sets this value from the PCI ids. Is that still pending? -- keith.pack...@intel.com pgpfAzxA46ANr.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 06/19] drm/i915: Ivy Bridge has split display and pipe control
On Thu, 28 Apr 2011 15:12:52 -0700, Jesse Barnes jbar...@virtuousgeek.org wrote: Ivy Bridge has a similar split display controller to Sandy Bridge, so use HAS_PCH_SPLIT. And gen7 also has the pipe control instruction, so use HAS_PIPE_CONTROL as well. Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org Reviewed-by: Keith Packard kei...@keithp.com -- keith.pack...@intel.com pgp0rmuIHa20e.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/19] drm/i915: add swizzle/tiling support for Ivy Bridge
On Thu, 28 Apr 2011 15:12:53 -0700, Jesse Barnes jbar...@virtuousgeek.org wrote: Treat it like Ironlake and Sandy Bridge. Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org Should use gen = 5? -- keith.pack...@intel.com pgptprXAz4FhS.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 08/19] drm/i915: manual FDI training for Ivy Bridge
On Thu, 28 Apr 2011 15:12:54 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
+ if (IS_GEN6(dev)) {
+ temp = ~FDI_LINK_TRAIN_NONE;
+ temp |= FDI_LINK_TRAIN_NONE | FDI_TX_ENHANCE_FRAME_ENABLE;
+ } else if (IS_IVYBRIDGE(dev)) {
+ temp = ~FDI_LINK_TRAIN_NONE_IVB;
+ temp |= FDI_LINK_TRAIN_NONE_IVB | FDI_TX_ENHANCE_FRAME_ENABLE;
+ }
This seems inconsistent using IS_GEN6 for SNB and IS_IVYBRIDGE for IVB?
--
keith.pack...@intel.com
pgphLRgI1zdSN.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 09/19] drm/i915: automatic FDI training support for Ivy Bridge
On Thu, 28 Apr 2011 15:12:55 -0700, Jesse Barnes jbar...@virtuousgeek.org wrote: Ivy Bridge supports auto-training on the CPU side, so add a separate training function to handle it. Let's leave this out of the kernel until we have hardware that actually uses it. -- keith.pack...@intel.com pgpBSTIApdDAP.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 10/19] drm/i915: treat Ivy Bridge watermarks like Sandy Bridge
On Thu, 28 Apr 2011 15:12:56 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
- if (IS_GEN6(dev)) {
+ if (IS_GEN6(dev) || IS_IVYBRIDGE(dev)) {
IS_GEN6 for SNB and IS_IVYBRIDGE for IVB? More consistency, please.
--
keith.pack...@intel.com
pgpPesA8nYOAV.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 11/19] drm/i915: interrupt vblank support for Ivy Bridge
On Thu, 28 Apr 2011 15:12:57 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
- if (IS_G4X(dev) || IS_GEN5(dev) || IS_GEN6(dev)) {
+ if (IS_G4X(dev) || IS_GEN5(dev) || IS_GEN6(dev) || IS_IVYBRIDGE(dev)) {
IS_G4X || gen = 5 ?
Otherwise, this looks good (seems like it's just bit shuffling from SNB, right?)
--
keith.pack...@intel.com
pgpa3ZrGnial9.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 13/19] drm/i915: untested DP support for Ivy Bridge
On Thu, 28 Apr 2011 15:12:59 -0700, Jesse Barnes jbar...@virtuousgeek.org wrote: Treat it like Sandy Bridge in a few places. gen = 6? -- keith.pack...@intel.com pgpqFHB2q8tev.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 14/19] drm/i915: ring support for Ivy Bridge
On Thu, 28 Apr 2011 15:13:00 -0700, Jesse Barnes jbar...@virtuousgeek.org wrote: Use Sandy Bridge paths in a few places. gen = 6 ? -- keith.pack...@intel.com pgp6Bmd9mjsyL.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 17/19] drm/i915: add Ivy Bridge PCI IDs and driver feature structs
On Thu, 28 Apr 2011 15:13:03 -0700, Jesse Barnes jbar...@virtuousgeek.org wrote: There are several variants, set feature bits appropriately for both mobile and desktop parts. Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org Reviewed-by: Keith Packard kei...@keithp.com -- keith.pack...@intel.com pgpgD7gICZi93.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 18/19] drm/i915: set IBX pch type explicitly
On Thu, 28 Apr 2011 15:13:04 -0700, Jesse Barnes jbar...@virtuousgeek.org wrote: This is a little less confusing than relying on the implicit zeroing of the dev_priv. Thanks. Reviewed-by: Keith Packard kei...@keithp.com -- keith.pack...@intel.com pgpFuOeuyyxOq.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 13/19] drm/i915: untested DP support for Ivy Bridge
On Sun, 01 May 2011 17:26:11 +0100, Chris Wilson ch...@chris-wilson.co.uk wrote: Perhaps if you do the s/IS_GEN6/IS_SNADYBRIDGE/ fixes first it will become much clearer? :) The only question is one of regressions; getting the cleanups tested in isolation from the IVB patches. That seems do-able for the 2.6.40 merge window. -- keith.pack...@intel.com pgpwscQGrJcxa.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/13] drm/i915: Introduce i915_gem_object_finish_gtt()
On Thu, 14 Apr 2011 10:03:38 +0100, Chris Wilson ch...@chris-wilson.co.uk wrote: + obj-base.write_domain = ~I915_GEM_DOMAIN_GTT; + obj-base.write_domain = ~I915_GEM_DOMAIN_GTT; I'll bet you want to modify the read_domain as well. -- keith.pack...@intel.com pgp2NzoJuMYNT.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/13] drm/i915: Mark the cursor and the overlay as being part of the display planes
On Thu, 14 Apr 2011 10:03:41 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5360,7 +5360,7 @@ static int intel_crtc_cursor_set(struct drm_crtc *crtc,
goto fail_locked;
}
- ret = i915_gem_object_set_to_gtt_domain(obj, 0);
+ ret = i915_gem_object_set_to_display_plane(obj, NULL);
if (ret) {
DRM_ERROR(failed to move cursor bo into the GTT\n);
goto fail_unpin;
diff --git a/drivers/gpu/drm/i915/intel_overlay.c
b/drivers/gpu/drm/i915/intel_overlay.c
index a670c00..e0903c5 100644
--- a/drivers/gpu/drm/i915/intel_overlay.c
+++ b/drivers/gpu/drm/i915/intel_overlay.c
@@ -777,7 +777,7 @@ static int intel_overlay_do_put_image(struct
intel_overlay *overlay,
if (ret != 0)
return ret;
- ret = i915_gem_object_set_to_gtt_domain(new_bo, 0);
+ ret = i915_gem_object_set_to_display_plane(new_bo, NULL);
set_to_display_plane has a comment stating that it is always called from
a non - interruptible context and uses a non-interruptible flush wait as
a result.
I think we would want these new code paths to allow for interrupting the
operation?
--
keith.pack...@intel.com
pgprlfmVfc54N.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 11/13] drm/i915: Prevent mmap access through the GTT of snooped pages
On Thu, 14 Apr 2011 10:03:45 +0100, Chris Wilson ch...@chris-wilson.co.uk wrote: The docs have a dire warning not to attempt to access snooped (the old style of cache sharing on pre-SandyBridge chipsets) pages through the GTT. Prevent userspace from doing so by sending them a SIGBUS if they try. There is not plan for the user mode driver to use snooped access on pre-SNB chipsets. So, the kernel should not try to support this in any way. -- keith.pack...@intel.com pgpdz0M6DwHkc.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 12/13] drm/i915: Prevent mixing of snooped and tiling modes for old chipsets
On Thu, 14 Apr 2011 10:03:46 +0100, Chris Wilson ch...@chris-wilson.co.uk wrote: Older chipsets do not support snooping (i.e. cache sharing between the CPU and GPU) on tiled surfaces. So prevent userspace from being silly should we one day expose the ability to change cache levels from userspace. We will not need this as there is no plan to have user-mode use snooped access on older chipsets. -- keith.pack...@intel.com pgpzTi8PYFYpz.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/13] drm/i915: Mark the cursor and the overlay as being part of the display planes
On Wed, 04 May 2011 19:28:35 +0100, Chris Wilson ch...@chris-wilson.co.uk wrote: to simply mark the device as uninterruptible for the duration. The code now does the latter. I'm good with that plan during modesetting, the question is whether the new users of this function should allow for interrupts. -- keith.pack...@intel.com pgp0sGb2sH6mM.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 08/17] drm/i915: Move the tracking of dpms_mode down into crtc enable/disable
On Thu, 21 Apr 2011 22:18:23 +0100, Chris Wilson ch...@chris-wilson.co.uk wrote: As we failed to update the dpms_mode after modeset, where it is presumed to have been changed to DRM_MODE_DPMS_ON by the upper layers the dpms state on the crtc became inconsistent with its actual active state. This notably confused code and left the pipe active when it was meant to be disabled, leading to PGTBL_ER if the fb was subsequently moved. As we use the dpms_mode state for restoring the crtc after load-detection, we can not simply remove it in favour of simply using the active state. I don't understand this comment -- this patch changes the code so that dpms_mode exactly tracks active, instead of tracking the desired DPMS state. -- keith.pack...@intel.com pgpmO4PZ7f7fx.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Clear any errors recorded before i915.ko is loaded
On Tue, 5 Apr 2011 23:00:46 +0100, Chris Wilson ch...@chris-wilson.co.uk wrote: Something to think about... Missing SoB here... -- keith.pack...@intel.com pgpnCoAAssejC.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] Sandy Bridge graphics programmers reference manuals available now
Angela Gill (Visual Computing Group) and I (Keith Packard, Open Source Technology Center) are pleased to announce that HD Graphics Programmer's Reference Manuals for 2011 Intel Core Processor Family (Sandy Bridge) are now available at: http://intellinuxgraphics.org/documentation.html Many thanks to the VCG doc team for getting these documents prepared for distribution to the open source community. -- keith.pack...@intel.com pgpRFDninAJUf.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/7] drm/i915: color range only works on pre-ILK
On Tue, 19 Apr 2011 12:12:35 -0700, Jesse Barnes jbar...@virtuousgeek.org wrote: ILK+ provides this feature in the transcoder and pipe configuration instead. This doesn't seem to add in a new implementation of this feature for ILK, just stops using the pre-ILK version on ILK. Please explain how this is sufficient? -- keith.pack...@intel.com pgpiMAS3f1ghH.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/7] drm/i915: split out Ironlake pipe bpp picking code
On Tue, 19 Apr 2011 12:12:38 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Figuring out which pipe bpp to use is a bit painful. It depends on both
the encoder and display configuration attached to a pipe. For instance,
to drive a 24bpp framebuffer out to an 18bpp panel, we need to use 6bpc
on the pipe but also enable dithering. But driving that same
framebuffer to a DisplayPort output on another pipe means using 8bpc and
no dithering.
So split out and enhance the code to handle the various cases, returning
an appropriate pipe bpp as well as whether dithering should be enabled.
Save the resulting pipe bpp in the intel_crtc struct for use by encoders
in calculating bandwidth requirements (defaults to 24bpp on pre-ILK).
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_display.c | 181
++
drivers/gpu/drm/i915/intel_drv.h |1 +
2 files changed, 140 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 8ef0c39..e81e418 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4232,6 +4232,120 @@ static inline bool intel_panel_use_ssc(struct
drm_i915_private *dev_priv)
return dev_priv-lvds_use_ssc i915_panel_use_ssc;
}
+/**
+ * intel_choose_pipe_bpp - figure out what color depth the pipe should send
+ * @crtc: CRTC structure
+ *
+ * A pipe may be connected to one or more outputs. Based on the depth of the
+ * attached framebuffer, choose a good color depth to use on the pipe.
+ *
+ * If possible, match the pipe depth to the fb depth. In some cases, this
+ * isn't ideal, because the connected output supports a lesser or restricted
+ * set of depths. Resolve that here:
+ *LVDS typically supports only 6bpc, so clamp down in that case
+ *HDMI supports only 8bpc or 12bpc, so clamp to 8bpc with dither for
10bpc
+ *Displays may support a restricted set as well, check EDID and clamp as
+ * appropriate.
+ *
+ * RETURNS:
+ * Dithering requirement (i.e. false if display bpc and pipe bpc match,
+ * true if they don't match).
+ */
+static bool intel_choose_pipe_bpp(struct drm_crtc *crtc, unsigned int
*pipe_bpp)
Should mention dithering in the name, perhaps
choose_pipe_bpp_and_dithering or some such? Perhaps returning the
dithering in another by-reference parameter?
+{
+ struct drm_device *dev = crtc-dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ struct drm_encoder *encoder;
+ struct drm_connector *connector;
+ unsigned int display_bpc = UINT_MAX, fb_bpc, bpc;
+
+ fb_bpc = crtc-fb-depth / 3;
+
+ /* Walk the encoders connectors on this crtc, get min bpc */
Don't you want the max bpc?
+
+ /*
+ * We could just drive the pipe at the highest bpc all the time and
+ * enable dithering as needed, but that costs bandwidth. So choose
+ * the minimum value that expresses the full color range of the fb but
+ * also stays within the max display bpc discovered above.
+ */
+
+ switch (crtc-fb-depth) {
+ case 8:
+ case 15:
+ case 16:
+ bpc = 6; /* min is 18bpp */
+ break;
+ case 24:
+ bpc = min((unsigned int)8, display_bpc);
+ break;
+ case 30:
+ bpc = min((unsigned int)10, display_bpc);
+ break;
+ case 48:
+ bpc = min((unsigned int)12, display_bpc);
+ break;
+ default:
+ DRM_DEBUG(unsupported depth, assuming 24 bits\n);
+ bpc = min((unsigned int)8, display_bpc);
+ break;
+ }
Hrm. 8-bit through a colormap should probably use 8 bpc? We can probably
ignore 15/16-bit direct color (which might want 8bpc as well).
The simple fix would be to use 8bpc on 8bpp and otherwise leave things alone.
--
keith.pack...@intel.com
pgpYjBXugATo2.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: Select correct pipe during TV detect
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/intel_tv.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
index 6b22c1d..876064c 100644
--- a/drivers/gpu/drm/i915/intel_tv.c
+++ b/drivers/gpu/drm/i915/intel_tv.c
@@ -1236,6 +1236,8 @@ intel_tv_detect_type (struct intel_tv *intel_tv,
struct drm_connector *connector)
{
struct drm_encoder *encoder = intel_tv-base.base;
+ struct drm_crtc *crtc = encoder-crtc;
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
struct drm_device *dev = encoder-dev;
struct drm_i915_private *dev_priv = dev-dev_private;
unsigned long irqflags;
@@ -1258,6 +1260,10 @@ intel_tv_detect_type (struct intel_tv *intel_tv,
/* Poll for TV detection */
tv_ctl = ~(TV_ENC_ENABLE | TV_TEST_MODE_MASK);
tv_ctl |= TV_TEST_MODE_MONITOR_DETECT;
+ if (intel_crtc-pipe == 1)
+ tv_ctl |= TV_ENC_PIPEB_SELECT;
+ else
+ tv_ctl = ~TV_ENC_PIPEB_SELECT;
tv_dac = ~(TVDAC_SENSE_MASK | DAC_A_MASK | DAC_B_MASK | DAC_C_MASK);
tv_dac |= (TVDAC_STATE_CHG_EN |
--
1.7.5.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: TVDAC_STATE_CHG does not indicate successful load-detect
Do not use this bit to indicate that load detection has completed,
instead just wait for vblank, at which point the load registers will
have been updated.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/intel_tv.c | 40 +++---
1 files changed, 20 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
index 876064c..b371863 100644
--- a/drivers/gpu/drm/i915/intel_tv.c
+++ b/drivers/gpu/drm/i915/intel_tv.c
@@ -1283,26 +1283,26 @@ intel_tv_detect_type (struct intel_tv *intel_tv,
to_intel_crtc(intel_tv-base.base.crtc)-pipe);
type = -1;
- if (wait_for((tv_dac = I915_READ(TV_DAC)) TVDAC_STATE_CHG, 20) == 0) {
- DRM_DEBUG_KMS(TV detected: %x, %x\n, tv_ctl, tv_dac);
- /*
-* A B C
-* 0 1 1 Composite
-* 1 0 X svideo
-* 0 0 0 Component
-*/
- if ((tv_dac TVDAC_SENSE_MASK) == (TVDAC_B_SENSE |
TVDAC_C_SENSE)) {
- DRM_DEBUG_KMS(Detected Composite TV connection\n);
- type = DRM_MODE_CONNECTOR_Composite;
- } else if ((tv_dac (TVDAC_A_SENSE|TVDAC_B_SENSE)) ==
TVDAC_A_SENSE) {
- DRM_DEBUG_KMS(Detected S-Video TV connection\n);
- type = DRM_MODE_CONNECTOR_SVIDEO;
- } else if ((tv_dac TVDAC_SENSE_MASK) == 0) {
- DRM_DEBUG_KMS(Detected Component TV connection\n);
- type = DRM_MODE_CONNECTOR_Component;
- } else {
- DRM_DEBUG_KMS(Unrecognised TV connection\n);
- }
+ tv_dac = I915_READ(TV_DAC);
+ DRM_DEBUG_KMS(TV detected: %x, %x\n, tv_ctl, tv_dac);
+ /*
+* A B C
+* 0 1 1 Composite
+* 1 0 X svideo
+* 0 0 0 Component
+*/
+ if ((tv_dac TVDAC_SENSE_MASK) == (TVDAC_B_SENSE | TVDAC_C_SENSE)) {
+ DRM_DEBUG_KMS(Detected Composite TV connection\n);
+ type = DRM_MODE_CONNECTOR_Composite;
+ } else if ((tv_dac (TVDAC_A_SENSE|TVDAC_B_SENSE)) == TVDAC_A_SENSE) {
+ DRM_DEBUG_KMS(Detected S-Video TV connection\n);
+ type = DRM_MODE_CONNECTOR_SVIDEO;
+ } else if ((tv_dac TVDAC_SENSE_MASK) == 0) {
+ DRM_DEBUG_KMS(Detected Component TV connection\n);
+ type = DRM_MODE_CONNECTOR_Component;
+ } else {
+ DRM_DEBUG_KMS(Unrecognised TV connection\n);
+ type = -1;
}
I915_WRITE(TV_DAC, save_tv_dac ~TVDAC_STATE_CHG_EN);
--
1.7.5.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/16] drm/i915: Refactor pwrite/pread to use single copy of get_user_pages
On Thu, 12 May 2011 22:17:10 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
+ pages = kmalloc(n*sizeof(struct page *),
+ GFP_KERNEL | __GFP_NORETRY | __GFP_NOWARN);
+ if (pages == NULL) {
+ pages = drm_malloc_ab(n, sizeof(struct page *));
+ if (pages == NULL) {
+ *pages_out = NULL;
+ *num_pages = 0;
+ return -ENOMEM;
+ }
+ }
Please use drm_malloc_ab here unconditionally; you've got a potential
multiplication overflow, and drm_malloc_ab already uses kmalloc for
small amounts anyways.
Otherwise, this looks good to me.
--
keith.pack...@intel.com
pgpTToZHp28Kg.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/16] drm/i915: s/addr ~PAGE_MASK/offset_in_page(addr)/
On Thu, 12 May 2011 22:17:11 +0100, Chris Wilson ch...@chris-wilson.co.uk wrote: Convert our open coded offset_in_page() to the common macro. Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk Reviewed-by: Keith Packard kei...@keithp.com -- keith.pack...@intel.com pgpjf0bivf3pS.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 09/16] drm/i915/gmbus: Reset the controller on initialisation
On Thu, 12 May 2011 22:17:17 +0100, Chris Wilson ch...@chris-wilson.co.uk wrote: Toggle the Software Clear Interrupt bit which resets the controller to clear any prior BUS_ERROR condition before we begin to use the controller in earnest. Looks reasonable, except for the bad register offsets (see reply to previous patch). I fear this code wasn't tested at all; it shouldn't have worked. -- keith.pack...@intel.com pgpBK6TSJRZ6A.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 05/16] drm/i915/tv: Use a direct pointer for tv_mode
On Thu, 12 May 2011 22:17:13 +0100, Chris Wilson ch...@chris-wilson.co.uk wrote: Instead of scanning through the static array using strcmp to find our matching tv_mode, just keep a direct link around. The historical reason for the strcmp was to match the connection property tv format, but now that property is translated for us into an index by the drm core. Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk Cc: Mathew McKernan matmcker...@rauland.com.au Nice cleanup. Note that I cannot test this patch because TV out does not work on the 965GM or GM45 machines that I have. Reviewed-by: Keith Packard kei...@keithp.com -- keith.pack...@intel.com pgp0mLAXjByJB.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 11/16] drm/i915: not finding a fence is a non-recoverable condition
On Thu, 12 May 2011 22:17:19 +0100, Chris Wilson ch...@chris-wilson.co.uk wrote: - return -ENOSPC; + return -EDEADLK; Would be nice to have the kernel print out a debugging message at this point -- the only way to hit this is from a bug in user or kernel code. -- keith.pack...@intel.com pgpsazRCqPvPN.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
