[RFC] drm: drm_lock possible error
drm_lock() does:
for (;;) {
__set_current_state(TASK_INTERRUPTIBLE);
...
if (drm_lock_take(&master->lock, lock->context)) {
< schedule() here
master->lock.file_priv = file_priv;
master->lock.lock_time = jiffies;
atomic_inc(&dev->counts[_DRM_STAT_LOCKS]);
break; /* Got lock */
}
...
}
If a preempt occurs in marked line, the task already holds the lock but
set to interruptible, then nobody can wakeup the task (except signal) and
other tasks can't get the lock again. Am I missing anything?
Signed-off-by: Shaohua Li
diff --git a/drivers/gpu/drm/drm_lock.c b/drivers/gpu/drm/drm_lock.c
index e2f70a5..32fbca0 100644
--- a/drivers/gpu/drm/drm_lock.c
+++ b/drivers/gpu/drm/drm_lock.c
@@ -76,6 +76,7 @@ int drm_lock(struct drm_device *dev, void *data, struct
drm_file *file_priv)
master->lock.user_waiters++;
spin_unlock_bh(&master->lock.spinlock);
+ preempt_disable();
for (;;) {
__set_current_state(TASK_INTERRUPTIBLE);
if (!master->lock.hw_lock) {
@@ -90,18 +91,21 @@ int drm_lock(struct drm_device *dev, void *data, struct
drm_file *file_priv)
atomic_inc(&dev->counts[_DRM_STAT_LOCKS]);
break; /* Got lock */
}
+ preempt_enable_no_resched();
/* Contention */
schedule();
+ preempt_disable();
if (signal_pending(current)) {
ret = -EINTR;
break;
}
}
+ __set_current_state(TASK_RUNNING);
+ preempt_enable();
spin_lock_bh(&master->lock.spinlock);
master->lock.user_waiters--;
spin_unlock_bh(&master->lock.spinlock);
- __set_current_state(TASK_RUNNING);
remove_wait_queue(&master->lock.lock_queue, &entry);
DRM_DEBUG("%d %s\n", lock->context,
--
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
A question about the default mode in xserver
Hi, Kaleb From the git log I know that the two files of vesamodes/extramodes are created by you. And the default modes will be generated by two scripts. In the two files there define the parameters for the different modelines. For example: hdisplay, vdisplay, htotal, vtotal, pclk. My question is how we can get the parameters for the modeline. Do they come from the spec? Or are they generated by CVT/GTF algorithm? Thanks. Best regards Yakui -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] i915: add page flipping support
On Tue, 21 Apr 2009 19:48:39 -0700 Eric Anholt wrote: > On Tue, 2009-04-14 at 15:22 -0700, Jesse Barnes wrote: > > Add a new page flipping ioctl to the i915 driver, using KMS > > functionality. > > > > Internally, the new flip ioctl will use the mode_set_base function, > > which will simply update the front buffer pointer, taking care to > > pin the new buffer and unpin the old one. This means userspace > > needs to create an FB id for the new front buffer prior to calling > > in. > > > > The flip will take place at the next vblank period automatically > > (since the display base regs are double buffered), and any drawing > > to a buffer with a pending flip will be blocked at execbuf time > > until the next vblank interrupt fires and runs its completion > > handler. > > What's ensuring that the rendering is complete before you queue the > flip to the new buffer? The lock breaking in list walking at idle is > also making me uncomfortable. Well we move it to the GTT domain before trying to flip it, is that not sufficient? As for the lock breaking, I may have screwed something up with that change (there was code motion so I had to re-patch that part), so please take a close look, there may be a better way to clean it up. -- Jesse Barnes, Intel Open Source Technology Center -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] i915: add page flipping support
On Tue, 2009-04-14 at 15:22 -0700, Jesse Barnes wrote:
> Add a new page flipping ioctl to the i915 driver, using KMS
> functionality.
>
> Internally, the new flip ioctl will use the mode_set_base function,
> which will simply update the front buffer pointer, taking care to pin
> the new buffer and unpin the old one. This means userspace needs to
> create an FB id for the new front buffer prior to calling in.
>
> The flip will take place at the next vblank period automatically (since
> the display base regs are double buffered), and any drawing to a
> buffer with a pending flip will be blocked at execbuf time until the
> next vblank interrupt fires and runs its completion handler.
What's ensuring that the rendering is complete before you queue the flip
to the new buffer? The lock breaking in list walking at idle is also
making me uncomfortable.
> diff --git a/drivers/gpu/drm/i915/i915_dma.c
> b/drivers/gpu/drm/i915/i915_dma.c index c23b3a9..5273ce0 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -871,6 +871,127 @@ static int i915_set_status_page(struct drm_device
> *dev, void *data, return 0;
> }
>
> +bool
> +i915_gem_flip_pending(struct drm_gem_object *obj)
> +{
> + struct drm_device *dev = obj->dev;
> + drm_i915_private_t *dev_priv = dev->dev_private;
> + struct drm_i915_gem_object *obj_priv = obj->driver_private;
> + unsigned long flags;
> + bool pending;
> +
> + spin_lock_irqsave(&dev_priv->vblank_lock, flags);
> + pending = !list_empty(&obj_priv->vblank_head);
> + spin_unlock_irqrestore(&dev_priv->vblank_lock, flags);
> +
> + return pending;
> +}
> +
> +static int i915_gem_page_flip(struct drm_device *dev, void *data,
> + struct drm_file *file_priv)
> +{
> + struct drm_i915_gem_page_flip *flip_data = data;
> + drm_i915_private_t *dev_priv = dev->dev_private;
> + struct drm_mode_object *drm_obj;
> + struct drm_crtc *crtc;
> + struct intel_crtc *intel_crtc;
> + struct intel_framebuffer *intel_fb;
> + struct drm_framebuffer *old_fb;
> + struct drm_i915_gem_object *obj_priv;
> + unsigned long flags;
> + unsigned int pipe;
> + int ret = 0, seqno;
> + struct drm_crtc_helper_funcs *crtc_funcs;
> +
> + if (!(drm_core_check_feature(dev, DRIVER_MODESET)))
> + return -ENODEV;
> +
> + /*
> + * Reject unknown flags so future userspace knows what we
> (don't)
> + * support
> + */
> + if (flip_data->flags & (~I915_PAGE_FLIP_WAIT)) {
> + DRM_ERROR("bad page flip flags\n");
> + return -EINVAL;
> + }
> +
> + mutex_lock(&dev->struct_mutex);
> +
> + /* Find the CRTC & FB ids */
> + drm_obj = drm_mode_object_find(dev, flip_data->crtc_id,
> +DRM_MODE_OBJECT_CRTC);
> + if (!drm_obj) {
> + DRM_DEBUG("unknown crtc %d\n", flip_data->crtc_id);
> + ret = -EINVAL;
> + goto out_unlock;
> + }
> + crtc = obj_to_crtc(drm_obj);
> + if (!crtc->enabled) {
> + DRM_ERROR("crtc %d not enabled\n", flip_data->crtc_id);
> + ret = -EINVAL;
> + goto out_unlock;
> + }
> + old_fb = crtc->fb;
> + intel_crtc = to_intel_crtc(crtc);
> + pipe = intel_crtc->pipe;
> +
> + drm_obj = drm_mode_object_find(dev, flip_data->fb_id,
> +DRM_MODE_OBJECT_FB);
> + if (!drm_obj) {
> + DRM_DEBUG("unknown fb %d\n", flip_data->fb_id);
> + ret = -EINVAL;
> + goto out_unlock;
> + }
> + crtc->fb = obj_to_fb(drm_obj);
> + intel_fb = to_intel_framebuffer(crtc->fb);
> + obj_priv = intel_fb->obj->driver_private;
> +
> + if (i915_gem_flip_pending(intel_fb->obj))
> + wait_for_completion(&obj_priv->vblank);
> +
> + /* Sanity check tiling */
> + if (obj_priv->tiling_mode != I915_TILING_NONE &&
> + obj_priv->tiling_mode != I915_TILING_X) {
> + DRM_ERROR("can only flip non-tiled or X tiled
> pages\n");
> + ret = -EINVAL;
> + goto out_unlock;
> + }
> +
> + /* Get vblank ref for completion handling */
> + ret = drm_vblank_get(dev, pipe);
> + if (ret) {
> + DRM_ERROR("failed to take vblank ref\n");
> + goto out_unlock;
> + }
> +
> + mutex_unlock(&dev->struct_mutex);
> +
> + crtc_funcs = crtc->helper_private;
> + crtc_funcs->mode_set_base(crtc, 0, 0, old_fb);
> + seqno = i915_add_request(dev, 0);
> +
> + /*
> + * This is a bit racy; the flip above may have already happened
> + * by the time we get here. If that happens, the new back
> buffer
> + * won't be available for rendering for one extra frame, since
> + * the vblank list won't have the object.
> + */
> + spin_lock_irqsave(&dev_priv->vblank_lock, flags);
> + list_add_tail(&obj_priv->vblank_head,
> &dev_
Re: A17 tiling series V2
On Wed, 2009-04-08 at 19:41 +0100, Chris Wilson wrote:
> On Wed, 2009-04-08 at 11:05 -0700, Eric Anholt wrote:
> > Here's the pair of patches I've got to make A17-afflicted machines do
> > tiling.
> > I've created regression tests for swapping tiled objects and for pread on
> > tiled objects, and I'm at 1/10 failures in intel-gpu-tools, or 0/10 if I
> > disable BO reuse (appears to be a bug in fencing on objects getting reused
> > as tiled after being linear). 3D performance is back to normal on my
> > affected 945GM, and no_rast=true glxgears looks good.
>
> Sounds like this patch should do the trick...
I don't think that's what's going on with the issue I was seeing, since
strides are all the same, and it's an untiled -> tiled transition
failing (I think). But I can't say for sure.
On first glance, this patch tricked me because I was assuming that
i915_gem_tiling_ok was "did the tiling mode we choose end up being OK
for this bo", not "is the current GTT location OK for the new tiling
mode that we know for sure is OK?". I'm tempted to rename it.
Given that the current driver stack doesn't do any tiled -> tiled
transitions, I'm thinking of holding off on this one until the next
merge window. Any strong objections?
> >From 1c5d1156f0f467568b1eab18a33dd9edc3579ce5 Mon Sep 17 00:00:00 2001
> From: Chris Wilson
> Date: Wed, 11 Feb 2009 10:45:16 +
> Subject: [PATCH] drm/i915: Clear fence register on tiling stride change.
>
> The fence register value also depends upon the stride of the object, so
> we
> need to clear the fence if that is changed as well.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/i915_drv.h|1 +
> drivers/gpu/drm/i915/i915_gem.c| 37 +-
> drivers/gpu/drm/i915/i915_gem_tiling.c | 54
> ++-
> 3 files changed, 75 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> b/drivers/gpu/drm/i915/i915_drv.h
> index 3784cfc..833ad26 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -628,6 +628,7 @@ void i915_gem_object_unpin(struct drm_gem_object
> *obj);
> int i915_gem_object_unbind(struct drm_gem_object *obj);
> void i915_gem_lastclose(struct drm_device *dev);
> uint32_t i915_get_gem_seqno(struct drm_device *dev);
> +int i915_gem_object_put_fence_reg(struct drm_gem_object *obj);
> void i915_gem_retire_requests(struct drm_device *dev);
> void i915_gem_retire_work_handler(struct work_struct *work);
> void i915_gem_clflush_object(struct drm_gem_object *obj);
> diff --git a/drivers/gpu/drm/i915/i915_gem.c
> b/drivers/gpu/drm/i915/i915_gem.c
> index 5848c1d..43c71de 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -2019,7 +2019,6 @@ static void i830_write_fence_reg(struct
> drm_i915_fence_reg *reg)
> val |= I830_FENCE_REG_VALID;
>
> I915_WRITE(FENCE_REG_830_0 + (regnum * 4), val);
> -
> }
>
> /**
> @@ -2211,6 +2210,42 @@ i915_gem_clear_fence_reg(struct drm_gem_object
> *obj)
> }
>
> /**
> + * i915_gem_object_put_fence_reg - waits on outstanding fenced access
> + * to the buffer to finish, and then resets the fence register.
> + * @obj: tiled object holding a fence register.
> + *
> + * Zeroes out the fence register itself and clears out the associated
> + * data structures in dev_priv and obj_priv.
> + */
> +int
> +i915_gem_object_put_fence_reg(struct drm_gem_object *obj)
> +{
> + struct drm_device *dev = obj->dev;
> + struct drm_i915_gem_object *obj_priv = obj->driver_private;
> +
> + if (obj_priv->fence_reg == I915_FENCE_REG_NONE)
> + return 0;
> +
> + /* On the i915, GPU access to tiled buffers is via a fence,
> + * therefore we must wait for any outstanding access to complete
> + * before clearing the fence.
> + */
> + if (!IS_I965G(dev)) {
> + int ret;
> +
> + i915_gem_object_flush_gpu_write_domain(obj);
> + i915_gem_object_flush_gtt_write_domain(obj);
> + ret = i915_gem_object_wait_rendering(obj);
> + if (ret != 0)
> + return ret;
> + }
> +
> + i915_gem_clear_fence_reg (obj);
> +
> + return 0;
> +}
> +
> +/**
> * Finds free space in the GTT aperture and binds the object there.
> */
> static int
> diff --git a/drivers/gpu/drm/i915/i915_gem_tiling.c
> b/drivers/gpu/drm/i915/i915_gem_tiling.c
> index 6be3f92..373e457 100644
> --- a/drivers/gpu/drm/i915/i915_gem_tiling.c
> +++ b/drivers/gpu/drm/i915/i915_gem_tiling.c
> @@ -255,6 +255,21 @@ i915_tiling_ok(struct drm_device *dev, int stride,
> int size, int tiling_mode)
> return true;
> }
>
> +static bool
> +i915_gem_object_tiling_ok (struct drm_gem_object *obj, int tiling_mode)
> +{
> + struct drm_i915_gem_object *obj_priv = obj->driver_private;
> +
> + if (obj_priv->gtt_space == NULL)
> + return true;
> +
> + if (tiling_mode == I915_TILIN
Re: [PATCH] fix unpaired i915 device mutex
On Sat, 2009-04-18 at 10:43 +0800, Wu Fengguang wrote:
> Signed-off-by: Wu Fengguang
> ---
> drivers/gpu/drm/i915/i915_gem.c |4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
Fixed up commit message and applied.
> --- mm.orig/drivers/gpu/drm/i915/i915_gem.c
> +++ mm/drivers/gpu/drm/i915/i915_gem.c
> @@ -4087,8 +4087,10 @@ i915_gem_entervt_ioctl(struct drm_device
> dev_priv->mm.suspended = 0;
>
> ret = i915_gem_init_ringbuffer(dev);
> - if (ret != 0)
> + if (ret != 0) {
> + mutex_unlock(&dev->struct_mutex);
> return ret;
> + }
>
> spin_lock(&dev_priv->mm.active_list_lock);
> BUG_ON(!list_empty(&dev_priv->mm.active_list));
--
Eric Anholt
e...@anholt.net eric.anh...@intel.com
signature.asc
Description: This is a digitally signed message part
--
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Segmentation fault in modetest program.
hi,
i've attached a small patch that should fix a small memory allocation
issue when called without arguments.
a!
--
aszlig
Universaldilettant
RedMoonStudios
Don't deallocate the connector before reading props.
--- tests/modetest/modetest.c 2009-03-19 00:51:13.0 +0100
+++ tests/modetest/modetest.c 2009-04-21 21:46:31.655625014 +0200
@@ -199,10 +199,10 @@
for (j = 0; j < connector->count_modes; j++)
dump_mode(&connector->modes[j]);
- drmModeFreeConnector(connector);
-
printf(" props:\n");
dump_props(connector);
+
+ drmModeFreeConnector(connector);
}
printf("\n");
}
signature.asc
Description: Digital signature
--
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/i915: Remove duplicated code
On Tue, 2009-04-21 at 09:29 +0200, Jonas Bonn wrote:
> It looks like some code got left behind while generalizing. This patch
> removes the old, non-general version and fixes up the generalized version
> so that it does what its supposed to.
NAK.
There is SDVOB, and SDVOC.
To detect SDVOB, you look in SDVOB.
To detect SDVOC, you look in SDVOB on old hardware, and SDVOC on new
hardware.
> Signed-off-by: Jonas Bonn
> ---
> drivers/gpu/drm/i915/intel_display.c | 10 ++
> 1 files changed, 2 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index c2c8e95..3811992 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -1838,12 +1838,6 @@ static void intel_setup_outputs(struct drm_device *dev)
> int found;
> u32 reg;
>
> - if (I915_READ(SDVOB) & SDVO_DETECTED) {
> - found = intel_sdvo_init(dev, SDVOB);
> - if (!found && SUPPORTS_INTEGRATED_HDMI(dev))
> - intel_hdmi_init(dev, SDVOB);
> - }
> -
> /* Before G4X SDVOC doesn't have its own detect register */
> if (IS_G4X(dev))
> reg = SDVOC;
> @@ -1851,9 +1845,9 @@ static void intel_setup_outputs(struct drm_device *dev)
> reg = SDVOB;
>
> if (I915_READ(reg) & SDVO_DETECTED) {
> - found = intel_sdvo_init(dev, SDVOC);
> + found = intel_sdvo_init(dev, reg);
> if (!found && SUPPORTS_INTEGRATED_HDMI(dev))
> - intel_hdmi_init(dev, SDVOC);
> + intel_hdmi_init(dev, reg);
> }
> } else
> intel_dvo_init(dev);
--
Eric Anholt
e...@anholt.net eric.anh...@intel.com
signature.asc
Description: This is a digitally signed message part
--
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 20935] Perfomance regresion in r300_dri version 7.3 (7.2 is twice faster)
http://bugs.freedesktop.org/show_bug.cgi?id=20935 --- Comment #1 from Maciej Cencora 2009-04-21 12:30:01 PST --- This is probably the same bug as mentioned here http://marc.info/?l=mesa3d-dev&m=124026675231694&w=2 Currently I'm trying to find a solution that doesn't lockup GPU. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 20954] mesa/drm(git): kernel panic with radeon driver (Radeon 9500 Pro)
http://bugs.freedesktop.org/show_bug.cgi?id=20954 --- Comment #5 from Rafael Antonio Porras Samaniego 2009-04-21 11:59:48 PST --- Created an attachment (id=25010) --> (http://bugs.freedesktop.org/attachment.cgi?id=25010) Proposed patch to avoid null pointer use. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 13130] "Scheduling while atomic" on SysRq-G (inteldrmfb)
http://bugzilla.kernel.org/show_bug.cgi?id=13130 --- Comment #7 from Andrew Morton 2009-04-21 17:05:34 --- (In reply to comment #6) > Is there a registry or something we should use instead? powerpc put a comment into the main table in sysrq.c. That works nicely. -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 13130] "Scheduling while atomic" on SysRq-G (inteldrmfb)
http://bugzilla.kernel.org/show_bug.cgi?id=13130 --- Comment #6 from Jesse Barnes 2009-04-21 15:56:24 --- (In reply to comment #5) > well... _why_ do we want it to work? It's only a debug thing and shouldn't > be needed at all once the driver is finished? Oh not at all; it's also about debugging bad userspace programs that mess with the display but don't crash gracefully (which would automatically restore the display). Maybe they hang or just display a mess and you want your console back. > And if there _is_ a legitimate long-term need for it then it surely should not > be implemented way down > inside one specific driver? It could probably be made drm generic, but so far i915 is the only in-tree driver using the DRM mode setting code. We could factor it out when the radeon stuff lands I guess. > I'm surprised that anyone even found out that sysrq-g exists - I didn't know, > and the chances are good that we'll later steal `g' from you and we won't find > out > for weeks :( Is there a registry or something we should use instead? I saw a few instances of sysrqs being registered in subsystems or arches, but I think I picked one that's free (and somewhat sensible)... > Yes, a schedule_work() thing will probably be OK, although there's a new class > of deadlock around that, so some care will be needed. > > This'll be our fourth sysrq-uses-schedule_work instance (at least). I guess > we > should > add a sysrq_key_op.call_in_process_context and centralise the implementation.. Sounds good. I'll add it to my TODO list. Thanks. -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 21241] Suse11: Blank screen
http://bugs.freedesktop.org/show_bug.cgi?id=21241 --- Comment #7 from Alex Deucher 2009-04-21 07:54:52 PST --- Also, can you attach the working log from this system with Ubuntu-8.10. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 21241] Suse11: Blank screen
http://bugs.freedesktop.org/show_bug.cgi?id=21241 Alex Deucher changed: What|Removed |Added Summary|Suse11: Cannot enable DRI, |Suse11: Blank screen |AIGLX error: Calling driver | |entry point failed. | --- Comment #6 from Alex Deucher 2009-04-21 07:54:04 PST --- So you have a blank screen; you should have said so. The AIGLX error is unrelated. Does X come up if you specify a mode in your config other than 1600x1200? http://wiki.debian.org/XStrikeForce/HowToRandR12 Does disabling the DRI help? Option "DRI" "False" -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 21241] Suse11: Cannot enable DRI, AIGLX error: Calling driver entry point failed.
http://bugs.freedesktop.org/show_bug.cgi?id=21241 --- Comment #5 from samit vats 2009-04-21 07:07:54 PST --- 1) on startx, screen goes blank (error message in Xorg0.log : AIGLX error: Calling driver entry point failed) so unable to debug with LIBGL_DEBUG=verbose glxinfo 2) For the same build driver works fine for Ubuntu-8.10. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Move bo from VRAM to SYSTEM when you need to go through TT
Jerome Glisse wrote:
> On Tue, 2009-04-21 at 14:42 +0200, Thomas Hellstrom wrote:
>
>> Jerome Glisse wrote:
>>
>>> Hi Thomas,
>>>
>>> I am not sure of the correct solution for moving a bo from
>>> VRAM to SYSTEM when you need to go through TT, here are
>>> solution i thought of and why they are wrong:
>>>
>>> (in driver callback move i get bo & newmem with bo being
>>> in vram and newmem being SYSTEM)
>>>
>>> 1) ttm_bo_move_buffer(bo, TT, ...);
>>> 2) move_null(bo, new_mem);
>>>
>>> Problem:
>>> 1) Will find space in tt and create a new node it will
>>>then call handle move mem which will allocate pages
>>>& bind to tt and callback into the driver move which
>>>will emit blit to do the actual copy
>>>It will also create a ghost object for holding the
>>>vram node until blit is done.
>>> 2) According to openchrome implementation i should bug
>>>if old_mem->mm_node != NULL which is at this point
>>>the case as mm_node is now a node of tt allocated
>>>memory and i can't free this node as i need to
>>>wait for the blit to finish
>>>
>>>
>>> 1) ttm_bo_move_buffer(bo, TT, ...);
>>> 2) ttm_bo_move_accel_cleanup(bo, ?syncobj?, new_mem);
>>>
>>> I think it's the right solution so there is 2 ghost
>>> object created but i am wondering if i have right
>>> to do it.
>>> 1) create ghost holding vram node
>>> 2) will create another ghost holding the tt node
>>>but the sync obj i provide should be the same
>>>as for the ghost of 1. I could know the syncobj
>>>and use it but does it sounds like what i want
>>>to do ?
>>>
>>> Cheers,
>>> Jerome
>>>
>>>
>>>
>> Jerome,
>>
>> Below is what Moorestown/Poulsbo does for the same thing.
>> However, the Moorestown / Poulsbo MMU can deal with cached page table
>> entries,
>> so depending on whether or not the Radeon can do that, you might want to
>> adjust
>> tmp_mem.caching flags.
>> The ttm_bo_handle_move_mem function may also need some patching to avoid
>> calling
>> ttm_tt_set_placement_caching for the new ttm, and instead let the driver
>> move code do that.
>>
>> static int psb_move_blit(struct ttm_buffer_object *bo,
>> bool evict, bool no_wait,
>> struct ttm_mem_reg *new_mem)
>> {
>> struct drm_psb_private *dev_priv =
>> container_of(bo->bdev, struct drm_psb_private, bdev);
>> struct drm_device *dev = dev_priv->dev;
>> struct ttm_mem_reg *old_mem = &bo->mem;
>> struct ttm_fence_object *fence;
>> int dir = 0;
>> int ret;
>>
>> if ((old_mem->mem_type == new_mem->mem_type) &&
>> (new_mem->mm_node->start <
>> old_mem->mm_node->start + old_mem->mm_node->size)) {
>> dir = 1;
>> }
>>
>> psb_emit_2d_copy_blit(dev,
>> old_mem->mm_node->start << PAGE_SHIFT,
>> new_mem->mm_node->start << PAGE_SHIFT,
>> new_mem->num_pages, dir);
>>
>> ret = ttm_fence_object_create(&dev_priv->fdev, 0,
>> _PSB_FENCE_TYPE_EXE,
>> TTM_FENCE_FLAG_EMIT,
>> &fence);
>> if (unlikely(ret != 0)) {
>> psb_idle_2d(dev);
>> if (fence)
>> ttm_fence_object_unref(&fence);
>> }
>>
>> ret = ttm_bo_move_accel_cleanup(bo, (void *) fence,
>> (void *) (unsigned long)
>> _PSB_FENCE_TYPE_EXE,
>> evict, no_wait, new_mem);
>> if (fence)
>> ttm_fence_object_unref(&fence);
>> return ret;
>> }
>>
>> /*
>> * Flip destination ttm into GATT,
>> * then blit and subsequently move out again.
>> */
>>
>> static int psb_move_flip(struct ttm_buffer_object *bo,
>> bool evict, bool interruptible, bool no_wait,
>> struct ttm_mem_reg *new_mem)
>> {
>> struct ttm_bo_device *bdev = bo->bdev;
>> struct ttm_mem_reg tmp_mem;
>> int ret;
>>
>> tmp_mem = *new_mem;
>> tmp_mem.mm_node = NULL;
>> tmp_mem.proposed_flags = TTM_PL_FLAG_TT;
>>
>> ret = ttm_bo_mem_space(bo, &tmp_mem, interruptible, no_wait);
>> if (ret)
>> return ret;
>> ret = ttm_tt_bind(bo->ttm, &tmp_mem);
>> if (ret)
>> goto out_cleanup;
>> ret = psb_move_blit(bo, true, no_wait, &tmp_mem);
>> if (ret)
>> goto out_cleanup;
>>
>> ret = ttm_bo_move_ttm(bo, evict, no_wait, new_mem);
>> out_cleanup:
>> if (tmp_mem.mm_node) {
>> spin_lock(&bdev->lru_lock);
>> drm_mm_put_block(tmp_mem.mm_node);
>> tmp_mem.mm_node = NULL;
>> spin_unlock(&bdev->lru_lock);
>> }
>> return ret;
>> }
>>
>>
>>
>
> Shouldn't out_cleanup only happen on error so
> we don't put block tt otherwise next operation
> might alloc this tt while move is not yet
> done. Or is tmp_mem.mm_node set to null somewhere
> in ttm ?
>
>
Jerome,
This is actually a synchronous operation which is indicated by the
"true" argument to the evict parameter in psb_move_blit, so at
out_cleanu
Re: Move bo from VRAM to SYSTEM when you need to go through TT
On Tue, 2009-04-21 at 14:42 +0200, Thomas Hellstrom wrote:
> Jerome Glisse wrote:
> > Hi Thomas,
> >
> > I am not sure of the correct solution for moving a bo from
> > VRAM to SYSTEM when you need to go through TT, here are
> > solution i thought of and why they are wrong:
> >
> > (in driver callback move i get bo & newmem with bo being
> > in vram and newmem being SYSTEM)
> >
> > 1) ttm_bo_move_buffer(bo, TT, ...);
> > 2) move_null(bo, new_mem);
> >
> > Problem:
> > 1) Will find space in tt and create a new node it will
> >then call handle move mem which will allocate pages
> >& bind to tt and callback into the driver move which
> >will emit blit to do the actual copy
> >It will also create a ghost object for holding the
> >vram node until blit is done.
> > 2) According to openchrome implementation i should bug
> >if old_mem->mm_node != NULL which is at this point
> >the case as mm_node is now a node of tt allocated
> >memory and i can't free this node as i need to
> >wait for the blit to finish
> >
> >
> > 1) ttm_bo_move_buffer(bo, TT, ...);
> > 2) ttm_bo_move_accel_cleanup(bo, ?syncobj?, new_mem);
> >
> > I think it's the right solution so there is 2 ghost
> > object created but i am wondering if i have right
> > to do it.
> > 1) create ghost holding vram node
> > 2) will create another ghost holding the tt node
> >but the sync obj i provide should be the same
> >as for the ghost of 1. I could know the syncobj
> >and use it but does it sounds like what i want
> >to do ?
> >
> > Cheers,
> > Jerome
> >
> >
> Jerome,
>
> Below is what Moorestown/Poulsbo does for the same thing.
> However, the Moorestown / Poulsbo MMU can deal with cached page table
> entries,
> so depending on whether or not the Radeon can do that, you might want to
> adjust
> tmp_mem.caching flags.
> The ttm_bo_handle_move_mem function may also need some patching to avoid
> calling
> ttm_tt_set_placement_caching for the new ttm, and instead let the driver
> move code do that.
>
> static int psb_move_blit(struct ttm_buffer_object *bo,
> bool evict, bool no_wait,
> struct ttm_mem_reg *new_mem)
> {
> struct drm_psb_private *dev_priv =
> container_of(bo->bdev, struct drm_psb_private, bdev);
> struct drm_device *dev = dev_priv->dev;
> struct ttm_mem_reg *old_mem = &bo->mem;
> struct ttm_fence_object *fence;
> int dir = 0;
> int ret;
>
> if ((old_mem->mem_type == new_mem->mem_type) &&
> (new_mem->mm_node->start <
> old_mem->mm_node->start + old_mem->mm_node->size)) {
> dir = 1;
> }
>
> psb_emit_2d_copy_blit(dev,
> old_mem->mm_node->start << PAGE_SHIFT,
> new_mem->mm_node->start << PAGE_SHIFT,
> new_mem->num_pages, dir);
>
> ret = ttm_fence_object_create(&dev_priv->fdev, 0,
> _PSB_FENCE_TYPE_EXE,
> TTM_FENCE_FLAG_EMIT,
> &fence);
> if (unlikely(ret != 0)) {
> psb_idle_2d(dev);
> if (fence)
> ttm_fence_object_unref(&fence);
> }
>
> ret = ttm_bo_move_accel_cleanup(bo, (void *) fence,
> (void *) (unsigned long)
> _PSB_FENCE_TYPE_EXE,
> evict, no_wait, new_mem);
> if (fence)
> ttm_fence_object_unref(&fence);
> return ret;
> }
>
> /*
> * Flip destination ttm into GATT,
> * then blit and subsequently move out again.
> */
>
> static int psb_move_flip(struct ttm_buffer_object *bo,
> bool evict, bool interruptible, bool no_wait,
> struct ttm_mem_reg *new_mem)
> {
> struct ttm_bo_device *bdev = bo->bdev;
> struct ttm_mem_reg tmp_mem;
> int ret;
>
> tmp_mem = *new_mem;
> tmp_mem.mm_node = NULL;
> tmp_mem.proposed_flags = TTM_PL_FLAG_TT;
>
> ret = ttm_bo_mem_space(bo, &tmp_mem, interruptible, no_wait);
> if (ret)
> return ret;
> ret = ttm_tt_bind(bo->ttm, &tmp_mem);
> if (ret)
> goto out_cleanup;
> ret = psb_move_blit(bo, true, no_wait, &tmp_mem);
> if (ret)
> goto out_cleanup;
>
> ret = ttm_bo_move_ttm(bo, evict, no_wait, new_mem);
> out_cleanup:
> if (tmp_mem.mm_node) {
> spin_lock(&bdev->lru_lock);
> drm_mm_put_block(tmp_mem.mm_node);
> tmp_mem.mm_node = NULL;
> spin_unlock(&bdev->lru_lock);
> }
> return ret;
> }
>
>
Shouldn't out_cleanup only happen on error so
we don't put block tt otherwise next operation
might alloc this tt while move is not yet
done. Or is tmp_mem.mm_node set to null somewhere
in ttm ?
Also strangely i am getting a vram object with
mm_node = NULL in driver callback function.
Cheers,
Jerome
--
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, an
Re: Move bo from VRAM to SYSTEM when you need to go through TT
Jerome Glisse wrote:
> Hi Thomas,
>
> I am not sure of the correct solution for moving a bo from
> VRAM to SYSTEM when you need to go through TT, here are
> solution i thought of and why they are wrong:
>
> (in driver callback move i get bo & newmem with bo being
> in vram and newmem being SYSTEM)
>
> 1) ttm_bo_move_buffer(bo, TT, ...);
> 2) move_null(bo, new_mem);
>
> Problem:
> 1) Will find space in tt and create a new node it will
>then call handle move mem which will allocate pages
>& bind to tt and callback into the driver move which
>will emit blit to do the actual copy
>It will also create a ghost object for holding the
>vram node until blit is done.
> 2) According to openchrome implementation i should bug
>if old_mem->mm_node != NULL which is at this point
>the case as mm_node is now a node of tt allocated
>memory and i can't free this node as i need to
>wait for the blit to finish
>
>
> 1) ttm_bo_move_buffer(bo, TT, ...);
> 2) ttm_bo_move_accel_cleanup(bo, ?syncobj?, new_mem);
>
> I think it's the right solution so there is 2 ghost
> object created but i am wondering if i have right
> to do it.
> 1) create ghost holding vram node
> 2) will create another ghost holding the tt node
>but the sync obj i provide should be the same
>as for the ghost of 1. I could know the syncobj
>and use it but does it sounds like what i want
>to do ?
>
> Cheers,
> Jerome
>
>
Jerome,
Below is what Moorestown/Poulsbo does for the same thing.
However, the Moorestown / Poulsbo MMU can deal with cached page table
entries,
so depending on whether or not the Radeon can do that, you might want to
adjust
tmp_mem.caching flags.
The ttm_bo_handle_move_mem function may also need some patching to avoid
calling
ttm_tt_set_placement_caching for the new ttm, and instead let the driver
move code do that.
static int psb_move_blit(struct ttm_buffer_object *bo,
bool evict, bool no_wait,
struct ttm_mem_reg *new_mem)
{
struct drm_psb_private *dev_priv =
container_of(bo->bdev, struct drm_psb_private, bdev);
struct drm_device *dev = dev_priv->dev;
struct ttm_mem_reg *old_mem = &bo->mem;
struct ttm_fence_object *fence;
int dir = 0;
int ret;
if ((old_mem->mem_type == new_mem->mem_type) &&
(new_mem->mm_node->start <
old_mem->mm_node->start + old_mem->mm_node->size)) {
dir = 1;
}
psb_emit_2d_copy_blit(dev,
old_mem->mm_node->start << PAGE_SHIFT,
new_mem->mm_node->start << PAGE_SHIFT,
new_mem->num_pages, dir);
ret = ttm_fence_object_create(&dev_priv->fdev, 0,
_PSB_FENCE_TYPE_EXE,
TTM_FENCE_FLAG_EMIT,
&fence);
if (unlikely(ret != 0)) {
psb_idle_2d(dev);
if (fence)
ttm_fence_object_unref(&fence);
}
ret = ttm_bo_move_accel_cleanup(bo, (void *) fence,
(void *) (unsigned long)
_PSB_FENCE_TYPE_EXE,
evict, no_wait, new_mem);
if (fence)
ttm_fence_object_unref(&fence);
return ret;
}
/*
* Flip destination ttm into GATT,
* then blit and subsequently move out again.
*/
static int psb_move_flip(struct ttm_buffer_object *bo,
bool evict, bool interruptible, bool no_wait,
struct ttm_mem_reg *new_mem)
{
struct ttm_bo_device *bdev = bo->bdev;
struct ttm_mem_reg tmp_mem;
int ret;
tmp_mem = *new_mem;
tmp_mem.mm_node = NULL;
tmp_mem.proposed_flags = TTM_PL_FLAG_TT;
ret = ttm_bo_mem_space(bo, &tmp_mem, interruptible, no_wait);
if (ret)
return ret;
ret = ttm_tt_bind(bo->ttm, &tmp_mem);
if (ret)
goto out_cleanup;
ret = psb_move_blit(bo, true, no_wait, &tmp_mem);
if (ret)
goto out_cleanup;
ret = ttm_bo_move_ttm(bo, evict, no_wait, new_mem);
out_cleanup:
if (tmp_mem.mm_node) {
spin_lock(&bdev->lru_lock);
drm_mm_put_block(tmp_mem.mm_node);
tmp_mem.mm_node = NULL;
spin_unlock(&bdev->lru_lock);
}
return ret;
}
--
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Move bo from VRAM to SYSTEM when you need to go through TT
Hi Thomas, I am not sure of the correct solution for moving a bo from VRAM to SYSTEM when you need to go through TT, here are solution i thought of and why they are wrong: (in driver callback move i get bo & newmem with bo being in vram and newmem being SYSTEM) 1) ttm_bo_move_buffer(bo, TT, ...); 2) move_null(bo, new_mem); Problem: 1) Will find space in tt and create a new node it will then call handle move mem which will allocate pages & bind to tt and callback into the driver move which will emit blit to do the actual copy It will also create a ghost object for holding the vram node until blit is done. 2) According to openchrome implementation i should bug if old_mem->mm_node != NULL which is at this point the case as mm_node is now a node of tt allocated memory and i can't free this node as i need to wait for the blit to finish 1) ttm_bo_move_buffer(bo, TT, ...); 2) ttm_bo_move_accel_cleanup(bo, ?syncobj?, new_mem); I think it's the right solution so there is 2 ghost object created but i am wondering if i have right to do it. 1) create ghost holding vram node 2) will create another ghost holding the tt node but the sync obj i provide should be the same as for the ghost of 1. I could know the syncobj and use it but does it sounds like what i want to do ? Cheers, Jerome -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/i915: Remove duplicated code
It looks like some code got left behind while generalizing. This patch
removes the old, non-general version and fixes up the generalized version
so that it does what its supposed to.
Signed-off-by: Jonas Bonn
---
drivers/gpu/drm/i915/intel_display.c | 10 ++
1 files changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index c2c8e95..3811992 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1838,12 +1838,6 @@ static void intel_setup_outputs(struct drm_device *dev)
int found;
u32 reg;
- if (I915_READ(SDVOB) & SDVO_DETECTED) {
- found = intel_sdvo_init(dev, SDVOB);
- if (!found && SUPPORTS_INTEGRATED_HDMI(dev))
- intel_hdmi_init(dev, SDVOB);
- }
-
/* Before G4X SDVOC doesn't have its own detect register */
if (IS_G4X(dev))
reg = SDVOC;
@@ -1851,9 +1845,9 @@ static void intel_setup_outputs(struct drm_device *dev)
reg = SDVOB;
if (I915_READ(reg) & SDVO_DETECTED) {
- found = intel_sdvo_init(dev, SDVOC);
+ found = intel_sdvo_init(dev, reg);
if (!found && SUPPORTS_INTEGRATED_HDMI(dev))
- intel_hdmi_init(dev, SDVOC);
+ intel_hdmi_init(dev, reg);
}
} else
intel_dvo_init(dev);
--
1.6.0.4
--
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/i915: Determine type before initialising connector
drm_connector_init sets both the connector type and the connector type_id
on the newly initialised connector. As the connector type_id is coupled to
the connector type, the connector type cannot simply be modified on an
initialised connector.
This patch changes the order of operations on intel_sdvo_init so that the
type is determined before the connector is intialised.
This fixes a bug whereby the name card0-VGA-1 would be allocted to both a
CRT and an SDVO connector since the SDVO connector would be initialised
with type 'unknown' and hence have its type_id assigned from the wrong pool.
Signed-off-by: Jonas Bonn
---
drivers/gpu/drm/i915/intel_sdvo.c | 29 ++---
1 files changed, 10 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
b/drivers/gpu/drm/i915/intel_sdvo.c
index 9913651..605b402 100644
--- a/drivers/gpu/drm/i915/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/intel_sdvo.c
@@ -1676,17 +1676,9 @@ bool intel_sdvo_init(struct drm_device *dev, int
output_device)
return false;
}
- connector = &intel_output->base;
-
- drm_connector_init(dev, connector, &intel_sdvo_connector_funcs,
- DRM_MODE_CONNECTOR_Unknown);
- drm_connector_helper_add(connector, &intel_sdvo_connector_helper_funcs);
sdvo_priv = (struct intel_sdvo_priv *)(intel_output + 1);
intel_output->type = INTEL_OUTPUT_SDVO;
- connector->interlace_allowed = 0;
- connector->doublescan_allowed = 0;
-
/* setup the DDC bus. */
if (output_device == SDVOB)
i2cbus = intel_i2c_create(dev, GPIOE, "SDVOCTRL_E for SDVOB");
@@ -1694,7 +1686,7 @@ bool intel_sdvo_init(struct drm_device *dev, int
output_device)
i2cbus = intel_i2c_create(dev, GPIOE, "SDVOCTRL_E for SDVOC");
if (!i2cbus)
- goto err_connector;
+ goto err_inteloutput;
sdvo_priv->i2c_bus = i2cbus;
@@ -1710,7 +1702,6 @@ bool intel_sdvo_init(struct drm_device *dev, int
output_device)
intel_output->i2c_bus = i2cbus;
intel_output->dev_priv = sdvo_priv;
-
/* Read the regs to test if we can talk to the device */
for (i = 0; i < 0x40; i++) {
if (!intel_sdvo_read_byte(intel_output, i, &ch[i])) {
@@ -1729,7 +1720,6 @@ bool intel_sdvo_init(struct drm_device *dev, int
output_device)
else
sdvo_priv->controlled_output = SDVO_OUTPUT_TMDS1;
- connector->display_info.subpixel_order = SubPixelHorizontalRGB;
encoder_type = DRM_MODE_ENCODER_TMDS;
connector_type = DRM_MODE_CONNECTOR_DVID;
@@ -1747,7 +1737,6 @@ bool intel_sdvo_init(struct drm_device *dev, int
output_device)
else if (sdvo_priv->caps.output_flags & SDVO_OUTPUT_SVID0)
{
sdvo_priv->controlled_output = SDVO_OUTPUT_SVID0;
- connector->display_info.subpixel_order = SubPixelHorizontalRGB;
encoder_type = DRM_MODE_ENCODER_TVDAC;
connector_type = DRM_MODE_CONNECTOR_SVIDEO;
sdvo_priv->is_tv = true;
@@ -1756,28 +1745,24 @@ bool intel_sdvo_init(struct drm_device *dev, int
output_device)
else if (sdvo_priv->caps.output_flags & SDVO_OUTPUT_RGB0)
{
sdvo_priv->controlled_output = SDVO_OUTPUT_RGB0;
- connector->display_info.subpixel_order = SubPixelHorizontalRGB;
encoder_type = DRM_MODE_ENCODER_DAC;
connector_type = DRM_MODE_CONNECTOR_VGA;
}
else if (sdvo_priv->caps.output_flags & SDVO_OUTPUT_RGB1)
{
sdvo_priv->controlled_output = SDVO_OUTPUT_RGB1;
- connector->display_info.subpixel_order = SubPixelHorizontalRGB;
encoder_type = DRM_MODE_ENCODER_DAC;
connector_type = DRM_MODE_CONNECTOR_VGA;
}
else if (sdvo_priv->caps.output_flags & SDVO_OUTPUT_LVDS0)
{
sdvo_priv->controlled_output = SDVO_OUTPUT_LVDS0;
- connector->display_info.subpixel_order = SubPixelHorizontalRGB;
encoder_type = DRM_MODE_ENCODER_LVDS;
connector_type = DRM_MODE_CONNECTOR_LVDS;
}
else if (sdvo_priv->caps.output_flags & SDVO_OUTPUT_LVDS1)
{
sdvo_priv->controlled_output = SDVO_OUTPUT_LVDS1;
- connector->display_info.subpixel_order = SubPixelHorizontalRGB;
encoder_type = DRM_MODE_ENCODER_LVDS;
connector_type = DRM_MODE_CONNECTOR_LVDS;
}
@@ -1795,9 +1780,16 @@ bool intel_sdvo_init(struct drm_device *dev, int
output_device)
goto err_i2c;
}
+ connector = &intel_output->base;
+ drm_connector_init(dev, connector, &intel_sdvo_connector_funcs,
+ connector_type);
+ drm_connector_helper_add(connector, &intel_sdvo_connector_helper_f
[PATCH] drm/i915: Remove duplicated code
It looks like some code got left behind while generalizing. This patch
removes the old, non-general version and fixes up the generalized version
so that it does what its supposed to.
Signed-off-by: Jonas Bonn
---
drivers/gpu/drm/i915/intel_display.c | 10 ++
1 files changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index c2c8e95..3811992 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1838,12 +1838,6 @@ static void intel_setup_outputs(struct drm_device *dev)
int found;
u32 reg;
- if (I915_READ(SDVOB) & SDVO_DETECTED) {
- found = intel_sdvo_init(dev, SDVOB);
- if (!found && SUPPORTS_INTEGRATED_HDMI(dev))
- intel_hdmi_init(dev, SDVOB);
- }
-
/* Before G4X SDVOC doesn't have its own detect register */
if (IS_G4X(dev))
reg = SDVOC;
@@ -1851,9 +1845,9 @@ static void intel_setup_outputs(struct drm_device *dev)
reg = SDVOB;
if (I915_READ(reg) & SDVO_DETECTED) {
- found = intel_sdvo_init(dev, SDVOC);
+ found = intel_sdvo_init(dev, reg);
if (!found && SUPPORTS_INTEGRATED_HDMI(dev))
- intel_hdmi_init(dev, SDVOC);
+ intel_hdmi_init(dev, reg);
}
} else
intel_dvo_init(dev);
--
1.6.0.4
--
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Intel i915 fixes
I sent these two patches last week, but I had the wrong subject line on them so I am afraid that they may have gone unnoticed by the right people. This is a resend of these two patches, just to make sure that they are not missed. Sorry for the noise. /Jonas -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/i915: Determine type before initialising connector
drm_connector_init sets both the connector type and the connector type_id
on the newly initialised connector. As the connector type_id is coupled to
the connector type, the connector type cannot simply be modified on an
initialised connector.
This patch changes the order of operations on intel_sdvo_init so that the
type is determined before the connector is intialised.
This fixes a bug whereby the name card0-VGA-1 would be allocted to both a
CRT and an SDVO connector since the SDVO connector would be initialised
with type 'unknown' and hence have its type_id assigned from the wrong pool.
Signed-off-by: Jonas Bonn
---
drivers/gpu/drm/i915/intel_sdvo.c | 29 ++---
1 files changed, 10 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
b/drivers/gpu/drm/i915/intel_sdvo.c
index 9913651..605b402 100644
--- a/drivers/gpu/drm/i915/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/intel_sdvo.c
@@ -1676,17 +1676,9 @@ bool intel_sdvo_init(struct drm_device *dev, int
output_device)
return false;
}
- connector = &intel_output->base;
-
- drm_connector_init(dev, connector, &intel_sdvo_connector_funcs,
- DRM_MODE_CONNECTOR_Unknown);
- drm_connector_helper_add(connector, &intel_sdvo_connector_helper_funcs);
sdvo_priv = (struct intel_sdvo_priv *)(intel_output + 1);
intel_output->type = INTEL_OUTPUT_SDVO;
- connector->interlace_allowed = 0;
- connector->doublescan_allowed = 0;
-
/* setup the DDC bus. */
if (output_device == SDVOB)
i2cbus = intel_i2c_create(dev, GPIOE, "SDVOCTRL_E for SDVOB");
@@ -1694,7 +1686,7 @@ bool intel_sdvo_init(struct drm_device *dev, int
output_device)
i2cbus = intel_i2c_create(dev, GPIOE, "SDVOCTRL_E for SDVOC");
if (!i2cbus)
- goto err_connector;
+ goto err_inteloutput;
sdvo_priv->i2c_bus = i2cbus;
@@ -1710,7 +1702,6 @@ bool intel_sdvo_init(struct drm_device *dev, int
output_device)
intel_output->i2c_bus = i2cbus;
intel_output->dev_priv = sdvo_priv;
-
/* Read the regs to test if we can talk to the device */
for (i = 0; i < 0x40; i++) {
if (!intel_sdvo_read_byte(intel_output, i, &ch[i])) {
@@ -1729,7 +1720,6 @@ bool intel_sdvo_init(struct drm_device *dev, int
output_device)
else
sdvo_priv->controlled_output = SDVO_OUTPUT_TMDS1;
- connector->display_info.subpixel_order = SubPixelHorizontalRGB;
encoder_type = DRM_MODE_ENCODER_TMDS;
connector_type = DRM_MODE_CONNECTOR_DVID;
@@ -1747,7 +1737,6 @@ bool intel_sdvo_init(struct drm_device *dev, int
output_device)
else if (sdvo_priv->caps.output_flags & SDVO_OUTPUT_SVID0)
{
sdvo_priv->controlled_output = SDVO_OUTPUT_SVID0;
- connector->display_info.subpixel_order = SubPixelHorizontalRGB;
encoder_type = DRM_MODE_ENCODER_TVDAC;
connector_type = DRM_MODE_CONNECTOR_SVIDEO;
sdvo_priv->is_tv = true;
@@ -1756,28 +1745,24 @@ bool intel_sdvo_init(struct drm_device *dev, int
output_device)
else if (sdvo_priv->caps.output_flags & SDVO_OUTPUT_RGB0)
{
sdvo_priv->controlled_output = SDVO_OUTPUT_RGB0;
- connector->display_info.subpixel_order = SubPixelHorizontalRGB;
encoder_type = DRM_MODE_ENCODER_DAC;
connector_type = DRM_MODE_CONNECTOR_VGA;
}
else if (sdvo_priv->caps.output_flags & SDVO_OUTPUT_RGB1)
{
sdvo_priv->controlled_output = SDVO_OUTPUT_RGB1;
- connector->display_info.subpixel_order = SubPixelHorizontalRGB;
encoder_type = DRM_MODE_ENCODER_DAC;
connector_type = DRM_MODE_CONNECTOR_VGA;
}
else if (sdvo_priv->caps.output_flags & SDVO_OUTPUT_LVDS0)
{
sdvo_priv->controlled_output = SDVO_OUTPUT_LVDS0;
- connector->display_info.subpixel_order = SubPixelHorizontalRGB;
encoder_type = DRM_MODE_ENCODER_LVDS;
connector_type = DRM_MODE_CONNECTOR_LVDS;
}
else if (sdvo_priv->caps.output_flags & SDVO_OUTPUT_LVDS1)
{
sdvo_priv->controlled_output = SDVO_OUTPUT_LVDS1;
- connector->display_info.subpixel_order = SubPixelHorizontalRGB;
encoder_type = DRM_MODE_ENCODER_LVDS;
connector_type = DRM_MODE_CONNECTOR_LVDS;
}
@@ -1795,9 +1780,16 @@ bool intel_sdvo_init(struct drm_device *dev, int
output_device)
goto err_i2c;
}
+ connector = &intel_output->base;
+ drm_connector_init(dev, connector, &intel_sdvo_connector_funcs,
+ connector_type);
+ drm_connector_helper_add(connector, &intel_sdvo_connector_helper_f
Intel i915 DRM fixes
I sent these patches last week, but as I had the wrong subject line on them (DRM instead of DRM/i915), I'm afraid they may have gone unnoticed. Here's a resend just to make sure that they're seen by the right people. Regards, Jonas Bonn South Pole Consulting AB www.southpoleconsulting.com -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
