Re: [Intel-gfx] [RFC] VGA hotplug support for i915 kms
On Fri, 2009-01-16 at 14:42 +0100, Jakob Bornecrantz wrote: Jesse Barnes wrote: On Wednesday, January 14, 2009 2:14 pm Jesse Barnes wrote: Here's a work in progress VGA hotplug patch that I've been testing on my GM45. I've only tested VGA interrupts so far, but other ports may work or should be easy to enable. When a hotplug interrupt is received, the i915 interrupt handler kicks off a work queue which ends up sending a uevent. I've deliberately done nothing else; I figure userspace should decide what to do with the event (ignore it, probe outputs, set up a cloned or extended configuration, etc.). Thoughts or comments? The passing of the DRM device struct to the work function is pretty ugly at this point, and could be improved, and whether hotplug detection is enabled should probably be configurable since it depends on the outputs being powered enough to detect events. Here's a slightly less revolting version. I removed all the global variables, and moved to using the system wide work queue rather than an i915 specific one, so things are much cleaner clearer. Comments? Userspace will still need to call getresources after receiving a hotplug event, but I think that's better than trying to do something by default in the kernel. When we only run fbcon we might not be blessed with a clever userspace that can add a new monitor to the fb config. Maybe we should run some sort of detection code in the intel fb code. Our experience with trying to do something sensible when we notice new things plugged in in the early randr 1.2 days was that it was a terrible idea that made users hate us. I suspect it would be even worse if we tried it in the kernel. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [RFC] VGA hotplug support for i915 kms
Jesse Barnes wrote: On Wednesday, January 14, 2009 2:14 pm Jesse Barnes wrote: Here's a work in progress VGA hotplug patch that I've been testing on my GM45. I've only tested VGA interrupts so far, but other ports may work or should be easy to enable. When a hotplug interrupt is received, the i915 interrupt handler kicks off a work queue which ends up sending a uevent. I've deliberately done nothing else; I figure userspace should decide what to do with the event (ignore it, probe outputs, set up a cloned or extended configuration, etc.). Thoughts or comments? The passing of the DRM device struct to the work function is pretty ugly at this point, and could be improved, and whether hotplug detection is enabled should probably be configurable since it depends on the outputs being powered enough to detect events. Here's a slightly less revolting version. I removed all the global variables, and moved to using the system wide work queue rather than an i915 specific one, so things are much cleaner clearer. Comments? Userspace will still need to call getresources after receiving a hotplug event, but I think that's better than trying to do something by default in the kernel. When we only run fbcon we might not be blessed with a clever userspace that can add a new monitor to the fb config. Maybe we should run some sort of detection code in the intel fb code. That is my only comment and it is a minor one, so the patch is Acked-By: Jakob Bornecrantz ja...@vmware.com Cheers Jakob. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [RFC] VGA hotplug support for i915 kms
On Friday, January 16, 2009 5:42 am Jakob Bornecrantz wrote: Jesse Barnes wrote: On Wednesday, January 14, 2009 2:14 pm Jesse Barnes wrote: Here's a work in progress VGA hotplug patch that I've been testing on my GM45. I've only tested VGA interrupts so far, but other ports may work or should be easy to enable. When a hotplug interrupt is received, the i915 interrupt handler kicks off a work queue which ends up sending a uevent. I've deliberately done nothing else; I figure userspace should decide what to do with the event (ignore it, probe outputs, set up a cloned or extended configuration, etc.). Thoughts or comments? The passing of the DRM device struct to the work function is pretty ugly at this point, and could be improved, and whether hotplug detection is enabled should probably be configurable since it depends on the outputs being powered enough to detect events. Here's a slightly less revolting version. I removed all the global variables, and moved to using the system wide work queue rather than an i915 specific one, so things are much cleaner clearer. Comments? Userspace will still need to call getresources after receiving a hotplug event, but I think that's better than trying to do something by default in the kernel. When we only run fbcon we might not be blessed with a clever userspace that can add a new monitor to the fb config. Maybe we should run some sort of detection code in the intel fb code. That is my only comment and it is a minor one, so the patch is Acked-By: Jakob Bornecrantz ja...@vmware.com Thanks for looking, and yeah that's a good point. We might be able to check if the fbcon is the currently active config, and update it. I'll see about that... We could probably make the default kernel config more explicit too, so it's easier to follow the panic, sysrq, and lastclose paths. -- Jesse Barnes, Intel Open Source Technology Center -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [RFC] VGA hotplug support for i915 kms
On Wednesday, January 14, 2009 2:14 pm Jesse Barnes wrote:
Here's a work in progress VGA hotplug patch that I've been testing on my
GM45. I've only tested VGA interrupts so far, but other ports may work or
should be easy to enable. When a hotplug interrupt is received, the i915
interrupt handler kicks off a work queue which ends up sending a uevent.
I've deliberately done nothing else; I figure userspace should decide what
to do with the event (ignore it, probe outputs, set up a cloned or extended
configuration, etc.).
Thoughts or comments? The passing of the DRM device struct to the work
function is pretty ugly at this point, and could be improved, and whether
hotplug detection is enabled should probably be configurable since it
depends on the outputs being powered enough to detect events.
Here's a slightly less revolting version. I removed all the global variables,
and moved to using the system wide work queue rather than an i915 specific one,
so things are much cleaner clearer.
Comments? Userspace will still need to call getresources after receiving a
hotplug event, but I think that's better than trying to do something by default
in the kernel.
--
Jesse Barnes, Intel Open Source Technology Center
diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
index 5aa6780..3e60996 100644
--- a/drivers/gpu/drm/drm_sysfs.c
+++ b/drivers/gpu/drm/drm_sysfs.c
@@ -461,6 +461,7 @@ void drm_sysfs_hotplug_event(struct drm_device *dev)
kobject_uevent_env(dev-primary-kdev.kobj, KOBJ_CHANGE, envp);
}
+EXPORT_SYMBOL(drm_sysfs_hotplug_event);
/**
* drm_sysfs_device_add - adds a class device to sysfs for a character driver
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 0beb084..ddca00a 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -976,13 +976,6 @@ static int i915_load_modeset_init(struct drm_device *dev)
if (ret)
goto destroy_ringbuffer;
- /* FIXME: re-add hotplug support */
-#if 0
- ret = drm_hotplug_init(dev);
- if (ret)
- goto destroy_ringbuffer;
-#endif
-
/* Always safe in the mode setting case. */
/* FIXME: do pre/post-mode set stuff in core KMS code */
dev-vblank_disable_allowed = 1;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 563de18..d3e7201 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -147,6 +147,9 @@ typedef struct drm_i915_private {
u32 irq_mask_reg;
u32 pipestat[2];
+ u32 hotplug_supported_mask;
+ struct work_struct hotplug_work;
+
int tex_lru_log_granularity;
int allow_batchbuffer;
struct mem_block *agp_heap;
@@ -761,6 +764,7 @@ extern int i915_wait_ring(struct drm_device * dev, int n,
const char *caller);
IS_I945GM(dev) || IS_I965GM(dev) || IS_GM45(dev))
#define I915_NEED_GFX_HWS(dev) (IS_G33(dev) || IS_GM45(dev) || IS_G4X(dev))
+#define I915_HAS_PORT(dev) (IS_I945G(dev) || IS_I965G(dev))
#define SUPPORTS_INTEGRATED_HDMI(dev) (IS_G4X(dev))
#define PRIMARY_RINGBUFFER_SIZE (128*1024)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 6290219..bc929ea 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -48,10 +48,6 @@
/** Interrupts that we mask and unmask at runtime. */
#define I915_INTERRUPT_ENABLE_VAR (I915_USER_INTERRUPT)
-/** These are all of the interrupts used by the driver */
-#define I915_INTERRUPT_ENABLE_MASK (I915_INTERRUPT_ENABLE_FIX | \
- I915_INTERRUPT_ENABLE_VAR)
-
#define I915_PIPE_VBLANK_STATUS(PIPE_START_VBLANK_INTERRUPT_STATUS |\
PIPE_VBLANK_INTERRUPT_STATUS)
@@ -174,6 +170,19 @@ u32 i915_get_vblank_counter(struct drm_device *dev, int
pipe)
return count;
}
+/*
+ * Handle hotplug events outside the interrupt handler proper.
+ */
+static void i915_hotplug_work_func(struct work_struct *work)
+{
+ drm_i915_private_t *dev_priv = container_of(work, drm_i915_private_t,
+ hotplug_work);
+ struct drm_device *dev = dev_priv-dev;
+
+ /* Just fire off a uevent and let userspace tell us what to do */
+ drm_sysfs_hotplug_event(dev);
+}
+
irqreturn_t i915_driver_irq_handler(DRM_IRQ_ARGS)
{
struct drm_device *dev = (struct drm_device *) arg;
@@ -231,6 +240,20 @@ irqreturn_t i915_driver_irq_handler(DRM_IRQ_ARGS)
ret = IRQ_HANDLED;
+ /* Consume port. Then clear IIR or we'll miss events */
+ if ((I915_HAS_PORT(dev))
+ (iir I915_DISPLAY_PORT_INTERRUPT)) {
+ u32 hotplug_status = I915_READ(PORT_HOTPLUG_STAT);
+
+ DRM_DEBUG(hotplug event received, stat 0x%08x\n,
+
Re: [Intel-gfx] [RFC] VGA hotplug support for i915 kms
On Thu, 2009-01-15 at 14:18 -0800, Jesse Barnes wrote: Here's a slightly less revolting version. I removed all the global variables, and moved to using the system wide work queue rather than an i915 specific one, so things are much cleaner clearer. This looks good to me. I can hook up the uevent bits up in the X server and see how far that takes us. -- keith.pack...@intel.com signature.asc Description: This is a digitally signed message part -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [RFC] VGA hotplug support for i915 kms
On Thursday, January 15, 2009 4:55 pm Keith Packard wrote:
On Thu, 2009-01-15 at 14:18 -0800, Jesse Barnes wrote:
Here's a slightly less revolting version. I removed all the global
variables, and moved to using the system wide work queue rather than an
i915 specific one, so things are much cleaner clearer.
This looks good to me. I can hook up the uevent bits up in the X server
and see how far that takes us.
Cool, that should be fun. Here's a WIP KMS buffer resize patch too. It's
still untested and should share more code with the UXA bits you just added...
And then there's rotation to fix/validate...
--
Jesse Barnes, Intel Open Source Technology Center
diff --git a/src/drmmode_display.c b/src/drmmode_display.c
index 4994251..b06b6a7 100644
--- a/src/drmmode_display.c
+++ b/src/drmmode_display.c
@@ -185,7 +185,7 @@ drmmode_set_mode_major(xf86CrtcPtr crtc, DisplayModePtr
mode,
fb_id = drmmode-fb_id;
if (drmmode_crtc-rotate_fb_id)
fb_id = drmmode_crtc-rotate_fb_id;
- ErrorF(fb id is %d\n, fb_id);
+
ret = drmModeSetCrtc(drmmode-fd, drmmode_crtc-mode_crtc-crtc_id,
fb_id, x, y, output_ids, output_count, kmode);
if (ret)
@@ -323,7 +323,8 @@ drmmode_crtc_shadow_create(xf86CrtcPtr crtc, void *data,
int width, int height)
}
static void
-drmmode_crtc_shadow_destroy(xf86CrtcPtr crtc, PixmapPtr rotate_pixmap, void
*data)
+drmmode_crtc_shadow_destroy(xf86CrtcPtr crtc, PixmapPtr rotate_pixmap,
+ void *data)
{
if (rotate_pixmap)
FreeScratchPixmapHeader(rotate_pixmap);
@@ -353,13 +354,7 @@ static const xf86CrtcFuncsRec drmmode_crtc_funcs = {
.shadow_create = drmmode_crtc_shadow_create,
.shadow_allocate = drmmode_crtc_shadow_allocate,
.shadow_destroy = drmmode_crtc_shadow_destroy,
-#if 0
- .gamma_set = i830_crtc_gamma_set,
- .shadow_create = i830_crtc_shadow_create,
- .shadow_allocate = i830_crtc_shadow_allocate,
- .shadow_destroy = i830_crtc_shadow_destroy,
- .set_cursor_colors = i830_crtc_set_cursor_colors,
-#endif
+
.destroy = NULL, /* XXX */
};
@@ -474,26 +469,50 @@ drmmode_output_destroy(xf86OutputPtr output)
output-driver_private = NULL;
}
+static drmModePropertyPtr
+drmmode_output_find_dpms_prop(xf86OutputPtr output)
+{
+ drmmode_output_private_ptr drmmode_output = output-driver_private;
+ drmModeConnectorPtr koutput = drmmode_output-mode_output;
+ drmmode_ptr drmmode = drmmode_output-drmmode;
+ drmModePropertyPtr prop;
+ int i;
+
+ /* Find the DPMS property on this output */
+ for (i = 0; i koutput-count_props; i++) {
+ prop = drmModeGetProperty(drmmode-fd, koutput-props[i]);
+ if (!prop)
+ continue;
+
+ if (!strcmp(prop-name, DPMS))
+ return prop;
+ drmModeFreeProperty(prop);
+ }
+
+ return NULL;
+}
+
static void
drmmode_output_dpms(xf86OutputPtr output, int mode)
{
- return;
+ drmmode_output_private_ptr drmmode_output = output-driver_private;
+ drmModeConnectorPtr koutput = drmmode_output-mode_output;
+ drmmode_ptr drmmode = drmmode_output-drmmode;
+ drmModePropertyPtr prop;
+
+ prop = drmmode_output_find_dpms_prop(output);
+ if (!prop)
+ return;
+
+ drmModeConnectorSetProperty(drmmode-fd, koutput-connector_id,
+ prop-prop_id, mode);
+ drmModeFreeProperty(prop);
}
static const xf86OutputFuncsRec drmmode_output_funcs = {
.dpms = drmmode_output_dpms,
-#if 0
-
- .save = drmmode_crt_save,
- .restore = drmmode_crt_restore,
- .mode_fixup = drmmode_crt_mode_fixup,
- .prepare = drmmode_output_prepare,
- .mode_set = drmmode_crt_mode_set,
- .commit = drmmode_output_commit,
-#endif
.detect = drmmode_output_detect,
.mode_valid = drmmode_output_mode_valid,
-
.get_modes = drmmode_output_get_modes,
.destroy = drmmode_output_destroy
};
@@ -544,7 +563,7 @@ drmmode_output_init(ScrnInfoPtr pScrn, drmmode_ptr drmmode,
int num)
snprintf(name, 32, %s%d, output_names[koutput-connector_type],
koutput-connector_type_id);
- output = xf86OutputCreate (pScrn, drmmode_output_funcs, name);
+ output = xf86OutputCreate(pScrn, drmmode_output_funcs, name);
if (!output) {
drmModeFreeEncoder(kencoder);
drmModeFreeConnector(koutput);
@@ -609,19 +628,10 @@ Bool drmmode_pre_init(ScrnInfoPtr pScrn, drmmode_ptr
drmmode, char *busId,
for (i = 0; i drmmode-mode_res-count_connectors; i++)
drmmode_output_init(pScrn, drmmode, i);
- xf86InitialConfiguration(pScrn, FALSE);
-
- return TRUE;
-}
+ xf86InitialConfiguration(pScrn, TRUE);
-#if 0
-Bool
