Re: [Intel-gfx] [PATCH] drm/i915: there's no cxsr on ilk
On Wed, May 30, 2012 at 12:19:22PM -0300, Eugeni Dodonov wrote: On 05/30/2012 12:15 PM, Daniel Vetter wrote: Already discovered in commit 5a117db77e47e3946d1aaa7ce8deafafd9d76746 Author: Eugeni Dodonoveugeni.dodo...@intel.com Date: Thu Jan 5 09:34:29 2012 -0200 drm/i915: there is no pipe CxSR on ironlake but we've failed to rip out the code from the ironlake specific code. Cc: Eugeni Dodonoveugeni.dodo...@intel.com Signed-Off-by: Daniel Vetterdaniel.vet...@ffwll.ch Reviewed-by: Eugeni Dodonov eugeni.dodo...@intel.com Queued for -next, thanks for the review. -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 14/14] drm/i915: s/mdelay/msleep/ in the sdvo detect function
On Thu, May 24, 2012 at 09:26:49PM +0200, Daniel Vetter wrote: A 30 ms delay is simply way too big to waste cpu cycles on. Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch I've queued this patch here for -next with Chris' irc ack added. -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: compute the target_clock for edp directly
On Wed, 30 May 2012 15:34:20 +0200, Daniel Vetter daniel.vet...@ffwll.ch
wrote:
Instead of abusing into mode-clock, because we should touch that
one at all. First prep step to constify the mode argument to the
intel_dp_mode_fixup function.
The next patch will stop us from modifying mode-clock.
Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_display.c | 16
drivers/gpu/drm/i915/intel_dp.c | 12
drivers/gpu/drm/i915/intel_drv.h |2 ++
3 files changed, 22 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 9147894..a5d06ed 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4431,16 +4431,8 @@ static int ironlake_crtc_mode_set(struct drm_crtc
*crtc,
/* CPU eDP doesn't require FDI link, so just set DP M/N
according to current link config */
if (is_cpu_edp) {
- target_clock = mode-clock;
intel_edp_link_config(edp_encoder, lane, link_bw);
} else {
- /* [e]DP over FDI requires target mode clock
-instead of link clock */
- if (is_dp)
- target_clock = mode-clock;
- else
- target_clock = adjusted_mode-clock;
-
/* FDI is a binary signal running at ~2.7GHz, encoding
* each output octet as 10 bits. The actual frequency
* is stored as a divider into a 100MHz clock, and the
@@ -4451,6 +4443,14 @@ static int ironlake_crtc_mode_set(struct drm_crtc
*crtc,
link_bw = intel_fdi_link_freq(dev) * MHz(100)/KHz(1)/10;
}
+ /* [e]DP over FDI requires target mode clock instead of link clock. */
+ if (edp_encoder)
+ target_clock = intel_edp_target_clock(edp_encoder, mode);
Given the edp_encoder, we know that adjusted_mode contains either the
fixed_panel clock or the original clock depending on whether a fixed
mode was found. So the layering violation could be dropped here in
favour of target_clock = adjusted_mode-clok.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: compute the target_clock for edp directly
On Thu, May 31, 2012 at 10:49:59AM +0100, Chris Wilson wrote:
On Wed, 30 May 2012 15:34:20 +0200, Daniel Vetter daniel.vet...@ffwll.ch
wrote:
Instead of abusing into mode-clock, because we should touch that
one at all. First prep step to constify the mode argument to the
intel_dp_mode_fixup function.
The next patch will stop us from modifying mode-clock.
Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_display.c | 16
drivers/gpu/drm/i915/intel_dp.c | 12
drivers/gpu/drm/i915/intel_drv.h |2 ++
3 files changed, 22 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 9147894..a5d06ed 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4431,16 +4431,8 @@ static int ironlake_crtc_mode_set(struct drm_crtc
*crtc,
/* CPU eDP doesn't require FDI link, so just set DP M/N
according to current link config */
if (is_cpu_edp) {
- target_clock = mode-clock;
intel_edp_link_config(edp_encoder, lane, link_bw);
} else {
- /* [e]DP over FDI requires target mode clock
- instead of link clock */
- if (is_dp)
- target_clock = mode-clock;
- else
- target_clock = adjusted_mode-clock;
-
/* FDI is a binary signal running at ~2.7GHz, encoding
* each output octet as 10 bits. The actual frequency
* is stored as a divider into a 100MHz clock, and the
@@ -4451,6 +4443,14 @@ static int ironlake_crtc_mode_set(struct drm_crtc
*crtc,
link_bw = intel_fdi_link_freq(dev) * MHz(100)/KHz(1)/10;
}
+ /* [e]DP over FDI requires target mode clock instead of link clock. */
+ if (edp_encoder)
+ target_clock = intel_edp_target_clock(edp_encoder, mode);
Given the edp_encoder, we know that adjusted_mode contains either the
fixed_panel clock or the original clock depending on whether a fixed
mode was found. So the layering violation could be dropped here in
favour of target_clock = adjusted_mode-clok.
It's not that simple. Assuming I understand this maze correctly, we're
dealing with 3 different clocks.
- The dp link clock, both the old and new code store that in
adjusted_mode-clock at the end of intel_dp_mode_fixup.
- The dotclock of the scanned-out region, i.e. what we have in mode-clock
before any fixup happens. No one cares about that one because we don't
need to program that anywhere (the panel fitter doesn't need it to do
it's job).
- The dotclock of the displayed mode, i.e. what comes out after the panel
fitting. The old code stored that in mode-clock (simply because that
was available I guess). The new code recomputes it (which is rather
simple because we only use the panel fitter for laptop panels and not to
e.g. upscale progressive content to a 1080i TV which can't display
1080p).
If I understand things correctly, we need to program the link clock into
the pch pll, but the fdi clock actually wants the dotclock of the
displayed mode. We store the later in target_clock in ilk_crtc_mode_set.
Obviously, given the complexity and the rampant bad naming schemes for
the involved variables I'm pretty sure I'm still getting this wrong
somewhere ...
Cheers, Daniel
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: compute the target_clock for edp directly
On Thu, 31 May 2012 12:03:53 +0200, Daniel Vetter dan...@ffwll.ch wrote:
On Thu, May 31, 2012 at 10:49:59AM +0100, Chris Wilson wrote:
On Wed, 30 May 2012 15:34:20 +0200, Daniel Vetter daniel.vet...@ffwll.ch
wrote:
Instead of abusing into mode-clock, because we should touch that
one at all. First prep step to constify the mode argument to the
intel_dp_mode_fixup function.
The next patch will stop us from modifying mode-clock.
Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_display.c | 16
drivers/gpu/drm/i915/intel_dp.c | 12
drivers/gpu/drm/i915/intel_drv.h |2 ++
3 files changed, 22 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 9147894..a5d06ed 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4431,16 +4431,8 @@ static int ironlake_crtc_mode_set(struct drm_crtc
*crtc,
/* CPU eDP doesn't require FDI link, so just set DP M/N
according to current link config */
if (is_cpu_edp) {
- target_clock = mode-clock;
intel_edp_link_config(edp_encoder, lane, link_bw);
} else {
- /* [e]DP over FDI requires target mode clock
-instead of link clock */
- if (is_dp)
- target_clock = mode-clock;
- else
- target_clock = adjusted_mode-clock;
-
/* FDI is a binary signal running at ~2.7GHz, encoding
* each output octet as 10 bits. The actual frequency
* is stored as a divider into a 100MHz clock, and the
@@ -4451,6 +4443,14 @@ static int ironlake_crtc_mode_set(struct drm_crtc
*crtc,
link_bw = intel_fdi_link_freq(dev) * MHz(100)/KHz(1)/10;
}
+ /* [e]DP over FDI requires target mode clock instead of link clock. */
+ if (edp_encoder)
+ target_clock = intel_edp_target_clock(edp_encoder, mode);
Given the edp_encoder, we know that adjusted_mode contains either the
fixed_panel clock or the original clock depending on whether a fixed
mode was found. So the layering violation could be dropped here in
favour of target_clock = adjusted_mode-clok.
It's not that simple. Assuming I understand this maze correctly, we're
dealing with 3 different clocks.
- The dp link clock, both the old and new code store that in
adjusted_mode-clock at the end of intel_dp_mode_fixup.
Right, missed that adjusted_mode-clock was rewritten in dp_mode_fixup.
In fact, wouldn't that make the better export from intel_dp?
target_clock = intel_dp_link_clock(adjusted_mode);
with a judicious adjusted_mode-private_flags |= INTEL_DP_LINK_BW_2_7/1_8?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] drm/i915: l3 parity sysfs interface
On Fri, May 25, 2012 at 04:56:25PM -0700, Ben Widawsky wrote: Dumb binary interfaces which allow root-only updates of the cache remapping registers. As mentioned in a previous patch, software using this interface needs to know about HW limits, and other programming considerations as the kernel interface does no checking for these things on the root-only interface. v1: Drop extra posting reads (Chris) Return negative values in the sysfs interfaces on errors (Chris) v2: Return -EINVAL for offset % 4 (Jesse) Move schizo userspace check out (Jesse) Cleaner sysfs item initializers (Daniel) Signed-off-by: Ben Widawsky b...@bwidawsk.net I've queued this series for -next. Although you haven't fixed up the one issue in patch 2 I've noticed and I also don't see my bikeshed for this patch (despite that you claim to have done so). Whatever, I'll follow up with patches. -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: compute the target_clock for edp directly
On Thu, May 31, 2012 at 11:31:50AM +0100, Chris Wilson wrote:
On Thu, 31 May 2012 12:03:53 +0200, Daniel Vetter dan...@ffwll.ch wrote:
On Thu, May 31, 2012 at 10:49:59AM +0100, Chris Wilson wrote:
On Wed, 30 May 2012 15:34:20 +0200, Daniel Vetter
daniel.vet...@ffwll.ch wrote:
Instead of abusing into mode-clock, because we should touch that
one at all. First prep step to constify the mode argument to the
intel_dp_mode_fixup function.
The next patch will stop us from modifying mode-clock.
Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_display.c | 16
drivers/gpu/drm/i915/intel_dp.c | 12
drivers/gpu/drm/i915/intel_drv.h |2 ++
3 files changed, 22 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 9147894..a5d06ed 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4431,16 +4431,8 @@ static int ironlake_crtc_mode_set(struct
drm_crtc *crtc,
/* CPU eDP doesn't require FDI link, so just set DP M/N
according to current link config */
if (is_cpu_edp) {
- target_clock = mode-clock;
intel_edp_link_config(edp_encoder, lane, link_bw);
} else {
- /* [e]DP over FDI requires target mode clock
- instead of link clock */
- if (is_dp)
- target_clock = mode-clock;
- else
- target_clock = adjusted_mode-clock;
-
/* FDI is a binary signal running at ~2.7GHz, encoding
* each output octet as 10 bits. The actual frequency
* is stored as a divider into a 100MHz clock, and the
@@ -4451,6 +4443,14 @@ static int ironlake_crtc_mode_set(struct
drm_crtc *crtc,
link_bw = intel_fdi_link_freq(dev) * MHz(100)/KHz(1)/10;
}
+ /* [e]DP over FDI requires target mode clock instead of link
clock. */
+ if (edp_encoder)
+ target_clock = intel_edp_target_clock(edp_encoder,
mode);
Given the edp_encoder, we know that adjusted_mode contains either the
fixed_panel clock or the original clock depending on whether a fixed
mode was found. So the layering violation could be dropped here in
favour of target_clock = adjusted_mode-clok.
It's not that simple. Assuming I understand this maze correctly, we're
dealing with 3 different clocks.
- The dp link clock, both the old and new code store that in
adjusted_mode-clock at the end of intel_dp_mode_fixup.
Right, missed that adjusted_mode-clock was rewritten in dp_mode_fixup.
In fact, wouldn't that make the better export from intel_dp?
target_clock = intel_dp_link_clock(adjusted_mode);
with a judicious adjusted_mode-private_flags |= INTEL_DP_LINK_BW_2_7/1_8?
I've considered this but then freaked out thinking about hunting down all
the places we use adjusted_mode-clock and checking whether I need to
change something ... So I've opted for the more minimal mode-clock
grep.
Call me a wimp, but before I try to slaugther that dragon I'd like to have
a more clear understanding of how this actually works and what it best
should look like.
-Daniel
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/crt: Do not rely upon the HPD presence pin
Whilst most monitors do wire up the HPD presence pin, it seems quite a
few KVM do not. Therefore if we simply rely on the HPD pin being
asserted to indicate a connected monitor we fail miserable, so fall back
to performing a DCC query for the EDID.
Reported-and-tested-by: Matthieu LAVIE boiteamad...@hotmail.com
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50501
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/intel_crt.c |8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index f0223d0..804611e 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -453,13 +453,15 @@ intel_crt_detect(struct drm_connector *connector, bool
force)
struct intel_load_detect_pipe tmp;
if (I915_HAS_HOTPLUG(dev)) {
+ /* We can not rely on the HPD pin always being correctly wired
+* up, for example many KVM do not pass it through, and so
+* only trust an assertion that the monitor is connected.
+*/
if (intel_crt_detect_hotplug(connector)) {
DRM_DEBUG_KMS(CRT detected via hotplug\n);
return connector_status_connected;
- } else {
+ } else
DRM_DEBUG_KMS(CRT not detected via hotplug\n);
- return connector_status_disconnected;
- }
}
if (intel_crt_detect_ddc(connector))
--
1.7.10
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/crt: Do not rely upon the HPD presence pin
On Thu, May 31, 2012 at 01:08:53PM +0100, Chris Wilson wrote: Whilst most monitors do wire up the HPD presence pin, it seems quite a few KVM do not. Therefore if we simply rely on the HPD pin being asserted to indicate a connected monitor we fail miserable, so fall back to performing a DCC query for the EDID. Reported-and-tested-by: Matthieu LAVIE boiteamad...@hotmail.com Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50501 Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk *sigh* Picked up for -fixes, thanks for the patch. -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/3] drm/i915: ivybridge_handle_parity_error should be static
Notice by Fengguang Wu's automatic sparse checker.
Reported-by: Fengguang Wu w...@linux.intel.com
Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_irq.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 4a45752..53356f4 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -462,7 +462,7 @@ static void ivybridge_parity_work(struct work_struct *work)
kfree(parity_event[1]);
}
-void ivybridge_handle_parity_error(struct drm_device *dev)
+static void ivybridge_handle_parity_error(struct drm_device *dev)
{
drm_i915_private_t *dev_priv = (drm_i915_private_t *) dev-dev_private;
unsigned long flags;
--
1.7.9
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Lots of i915/drm spew on 3.4
2012/5/30 Dave Jones da...@redhat.com: On Wed, May 30, 2012 at 05:58:48PM -0400, Dave Jones wrote: On Wed, May 30, 2012 at 11:51:54PM +0200, Daniel Vetter wrote: On Wed, May 30, 2012 at 11:31 PM, Dave Jones da...@redhat.com wrote: On this hardware: 00:02.0 VGA compatible controller: Intel Corporation 82945G/GZ Integrated Graphics Controller (rev 02) I get this every boot with Linus current tree (up to af56e0aa35f3ae2a4c1a6d1000702df1dd78cb76) Just a quick question, is this a regression? seems so, I don't see it on 3.3 If so, can you please attach the output of xrandr --verbose from a noisy and a quite kernel (otherwise just please attach it from this noisy kernel). this machine runs headless, so has no X installed right now, I'll get it in a while. Attached. Just a little more information: you have a lot of connector properties because for some reason the driver thinks you have TV1, TV2 and TV3. Each TV connector has a lot of properties... With kernel 3.3 you have only TV1 and TV2. Maybe instead of increasing the maximum property count we should try to investigate why there's a new TV connector in the new kernel (and maybe this is also not a bug/regression...). -- Paulo Zanoni ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] drm/i915: l3 parity sysfs interface
On Thu, 31 May 2012 12:45:56 +0200 Daniel Vetter dan...@ffwll.ch wrote: On Fri, May 25, 2012 at 04:56:25PM -0700, Ben Widawsky wrote: Dumb binary interfaces which allow root-only updates of the cache remapping registers. As mentioned in a previous patch, software using this interface needs to know about HW limits, and other programming considerations as the kernel interface does no checking for these things on the root-only interface. v1: Drop extra posting reads (Chris) Return negative values in the sysfs interfaces on errors (Chris) v2: Return -EINVAL for offset % 4 (Jesse) Move schizo userspace check out (Jesse) Cleaner sysfs item initializers (Daniel) Signed-off-by: Ben Widawsky b...@bwidawsk.net I've queued this series for -next. Although you haven't fixed up the one issue in patch 2 I've noticed and I also don't see my bikeshed for this patch (despite that you claim to have done so). Whatever, I'll follow up with patches. -Daniel Thanks for moving the patches forward, I'll review your fixes to them shortly. The fixes are somewhere; I am not sure how they got lost. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915: ivybridge_handle_parity_error should be static
On Thu, 31 May 2012 14:57:41 +0200 Daniel Vetter daniel.vet...@ffwll.ch wrote: Notice by Fengguang Wu's automatic sparse checker. Reported-by: Fengguang Wu w...@linux.intel.com Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch Reviewed-by: Ben Widawsky b...@bwidawsk.net ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915: simplify sysfs setup code
On Thu, 31 May 2012 14:57:43 +0200 Daniel Vetter daniel.vet...@ffwll.ch wrote: Positively checking for the required feature/gen is simpler than build a cascade of negative we need to bail checks. And the later won't scale if we add more stuff that doesn't fit in nicely. Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch Reviewed-by: Ben Widawsky b...@bwidawsk.net Again, not sure what happened. The fixed patch exists somewhere. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 14/14] drm/i915: s/mdelay/msleep/ in the sdvo detect function
On Thu, May 31, 2012 at 9:24 PM, Singh, Satyeshwar satyeshwar.si...@intel.com wrote: Is there a reason for the 30 ms delay in the first place? git blame says there is, it supposedely fixes a bug with tv detection. -Daniel -- Daniel Vetter daniel.vet...@ffwll.ch - +41 (0) 79 364 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: extract object unplug code from busy/wait_timeout ioctl
On Wed, 30 May 2012 23:15:39 +0200, Daniel Vetter dan...@ffwll.ch wrote: On Wed, May 30, 2012 at 01:41:28PM -0700, Ben Widawsky wrote: On Wed, 30 May 2012 20:21:33 +0200 Daniel Vetter daniel.vet...@ffwll.ch wrote: I've tested this by pimping the i-g-t test some more and also checking the polling behviour of the wait_rendering_timeout ioctl versus what busy_ioctl returns. Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch --- drivers/gpu/drm/i915/i915_gem.c | 61 ++ 1 files changed, 29 insertions(+), 32 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index d2eaa00..521e294 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -2000,6 +2000,31 @@ i915_gem_object_wait_rendering(struct drm_i915_gem_object *obj) } /** + * Ensures that an object will eventually get non-busy by flushing any required + * write domains, emitting any outstanding lazy request and retiring and + * completed requests. The unplug moniker is stolen from the linux block layer. + */ I'd prefer something like, unbusy but whatever. Considered and I've thought that's not a proper word. And unbusy isn't quite correct either, because this only ensures that the object will get unbusy eventually, if you keep on calling this function (due to the retire_request in there). And _eventually_unbusy_object sounds horrible to me. I admit that unplug is a misdenomer, too, but I lack good ideas. i965_gem_object_check_retired()? Just about anything would be better than unplug. pgpa7dorwrqKj.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
