Re: [Intel-gfx] [PATCH 1/2] drm/i915: timespec_sub should already be normalized
On Tue, Jul 29, 2014 at 01:14:29PM -0700, Ben Widawsky wrote: So don't bother checking it again. This was introduced: commit b361237bcc7cea1d99f770490120d8bc2aed Author: Chris Wilson ch...@chris-wilson.co.uk Date: Fri Aug 24 09:35:08 2012 +0100 drm/i915: Juggle code order to ease flow of the next patch Cc: Chris Wilson ch...@chris-wilson.co.uk Signed-off-by: Ben Widawsky b...@bwidawsk.net Ah, it is not so much that the timeout may be unnormalized, but that it *may* be negative. -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 2/2] drm/i915: Embellish wait_end trace
On Tue, Jul 29, 2014 at 01:14:30PM -0700, Ben Widawsky wrote: This adds two new data points to the trace event, wait time, and whether or not the event slept. Both of these should already be obtainable through various means. This patch just makes the data more accessible. Right, the key point is that since the advent of the wait_begin/_end pair is that we now allow concurrent non-blocking waits. Wait is obtainable with the current code by matching seqnos in begin/end. In simple cases where begin/ends are always paired, this is trivial. However, if you queue up multiple begins/ends, it can get confusing. We're already calculating wait time, so it's trivially added here. This patch also provides the slightly more accurate wait_time as opposed to the timestamps from the tracepoint. It's observable, but just noise. The second bit of information, whether or not the operation slept is helpful in determining where time went. This is probably also obtainable through the scheduler events. However, we have the information easily at our fingertips, we may as well give it out. This results in an event which looks like: gem_gtt_hog 409 [000]32.012641: i915:i915_gem_request_wait_end: dev=0, ring=3, seqno=4294963203, duration=0.000368225 (slept=yes) While here, rename sleep_time to wait_time since the verb sleep hasn't been true for a long time (several conditions exist where it won't sleep). Signed-off-by: Ben Widawsky b...@bwidawsk.net Other than the debate in the earlier patch, this looks fine. -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 1/2] drm/i915: timespec_sub should already be normalized
On Wed, Jul 30, 2014 at 07:15:05AM +0100, Chris Wilson wrote: On Tue, Jul 29, 2014 at 01:14:29PM -0700, Ben Widawsky wrote: So don't bother checking it again. This was introduced: commit b361237bcc7cea1d99f770490120d8bc2aed Author: Chris Wilson ch...@chris-wilson.co.uk Date: Fri Aug 24 09:35:08 2012 +0100 drm/i915: Juggle code order to ease flow of the next patch Cc: Chris Wilson ch...@chris-wilson.co.uk Signed-off-by: Ben Widawsky b...@bwidawsk.net Ah, it is not so much that the timeout may be unnormalized, but that it *may* be negative. -Chris -- Chris Wilson, Intel Open Source Technology Centre From looking at the code, I thought it didn't matter (ie. I thought it dtrt regardless of negative). However, I just wrote a little test, and you are correct. It is needed. Sorry about that. -- Ben Widawsky, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Embellish wait_end trace
On Wed, Jul 30, 2014 at 07:19:26AM +0100, Chris Wilson wrote: On Tue, Jul 29, 2014 at 01:14:30PM -0700, Ben Widawsky wrote: This adds two new data points to the trace event, wait time, and whether or not the event slept. Both of these should already be obtainable through various means. This patch just makes the data more accessible. Right, the key point is that since the advent of the wait_begin/_end pair is that we now allow concurrent non-blocking waits. Wait is obtainable with the current code by matching seqnos in begin/end. In simple cases where begin/ends are always paired, this is trivial. However, if you queue up multiple begins/ends, it can get confusing. We're already calculating wait time, so it's trivially added here. This patch also provides the slightly more accurate wait_time as opposed to the timestamps from the tracepoint. It's observable, but just noise. The second bit of information, whether or not the operation slept is helpful in determining where time went. This is probably also obtainable through the scheduler events. However, we have the information easily at our fingertips, we may as well give it out. This results in an event which looks like: gem_gtt_hog 409 [000]32.012641: i915:i915_gem_request_wait_end: dev=0, ring=3, seqno=4294963203, duration=0.000368225 (slept=yes) While here, rename sleep_time to wait_time since the verb sleep hasn't been true for a long time (several conditions exist where it won't sleep). Signed-off-by: Ben Widawsky b...@bwidawsk.net Other than the debate in the earlier patch, this looks fine. -Chris I actually don't think wait_begin is a terribly interesting event after this patch BTW, but I didn't want to rock the boat too much. If you agree, I can send that one as well. -- Ben Widawsky, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Embellish wait_end trace
On Tue, Jul 29, 2014 at 11:33:43PM -0700, Ben Widawsky wrote: On Wed, Jul 30, 2014 at 07:19:26AM +0100, Chris Wilson wrote: On Tue, Jul 29, 2014 at 01:14:30PM -0700, Ben Widawsky wrote: This adds two new data points to the trace event, wait time, and whether or not the event slept. Both of these should already be obtainable through various means. This patch just makes the data more accessible. Right, the key point is that since the advent of the wait_begin/_end pair is that we now allow concurrent non-blocking waits. Wait is obtainable with the current code by matching seqnos in begin/end. In simple cases where begin/ends are always paired, this is trivial. However, if you queue up multiple begins/ends, it can get confusing. We're already calculating wait time, so it's trivially added here. This patch also provides the slightly more accurate wait_time as opposed to the timestamps from the tracepoint. It's observable, but just noise. The second bit of information, whether or not the operation slept is helpful in determining where time went. This is probably also obtainable through the scheduler events. However, we have the information easily at our fingertips, we may as well give it out. This results in an event which looks like: gem_gtt_hog 409 [000]32.012641: i915:i915_gem_request_wait_end: dev=0, ring=3, seqno=4294963203, duration=0.000368225 (slept=yes) While here, rename sleep_time to wait_time since the verb sleep hasn't been true for a long time (several conditions exist where it won't sleep). Signed-off-by: Ben Widawsky b...@bwidawsk.net Other than the debate in the earlier patch, this looks fine. -Chris I actually don't think wait_begin is a terribly interesting event after this patch BTW, but I didn't want to rock the boat too much. If you agree, I can send that one as well. The only advantage is that wait_begin is before the wait, which may be significant - espcially in a time based profile. -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/8] drm: Move -old_fb from crtc to plane
On Tue, Jul 29, 2014 at 04:46:11PM -0700, Matt Roper wrote:
On Tue, Jul 29, 2014 at 11:32:19PM +0200, Daniel Vetter wrote:
Atomic implemenations for legacy ioctls must be able to drop locks.
Which doesn't cause havoc since we only do that while constructing
the new state, so no driver or hardware state change has happened.
The only troubling bit is the fb refcounting the core does - if
someone else has snuck in then it might potentially unref an
outdated framebuffer. To fix that move the old_fb temporary storage
into struct drm_plane for all ioctls, so that the atomic helpers can
update it.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/drm_crtc.c | 40
include/drm/drm_crtc.h | 8
2 files changed, 28 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index c09374038f9a..bacf565449d5 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1200,19 +1200,21 @@ EXPORT_SYMBOL(drm_plane_index);
*/
void drm_plane_force_disable(struct drm_plane *plane)
{
- struct drm_framebuffer *old_fb = plane-fb;
int ret;
- if (!old_fb)
+ if (!plane-fb)
return;
+ plane-old_fb = plane-fb;
ret = plane-funcs-disable_plane(plane);
if (ret) {
DRM_ERROR(failed to disable plane with busy fb\n);
+ plane-old_fb = NULL;
return;
}
/* disconnect the plane from the fb and crtc: */
- __drm_framebuffer_unreference(old_fb);
+ __drm_framebuffer_unreference(plane-old_fb);
+ plane-old_fb = NULL;
plane-fb = NULL;
plane-crtc = NULL;
}
@@ -2188,7 +2190,7 @@ static int setplane_internal(struct drm_plane *plane,
uint32_t src_w, uint32_t src_h)
{
struct drm_device *dev = plane-dev;
- struct drm_framebuffer *old_fb = NULL;
+ struct drm_framebuffer *old_fb;
I think there may be cases where old_fb gets unref'd without ever being
set if we drop the NULL assignment. E.g., if the possible_crtcs test or
the format test fail, we jump down to out and then test the value +
unref which could be garbage.
Oops, totally missed that. And somehow also missed the gcc warning about
unitialized usage of old_fb - that one was the reason why I've dropped the
initializer. Looks like I've failed.
Would it be simpler to just drm_modeset_lock_all() unconditionally at
the start of the function and then just unlock after the unrefs at the
end of the function so that we don't need a local old_fb?
Yeah considered that and since you're suggesting this too I'll do it.
Trying hard to not grab locks for the error case is fairly pointless
optimization.
int ret = 0;
unsigned int fb_width, fb_height;
int i;
@@ -2196,14 +2198,16 @@ static int setplane_internal(struct drm_plane
*plane,
/* No fb means shut it down */
if (!fb) {
drm_modeset_lock_all(dev);
- old_fb = plane-fb;
+ plane-old_fb = plane-fb;
ret = plane-funcs-disable_plane(plane);
if (!ret) {
plane-crtc = NULL;
plane-fb = NULL;
} else {
- old_fb = NULL;
+ plane-old_fb = NULL;
}
+ old_fb = plane-old_fb;
+ plane-old_fb = NULL;
drm_modeset_unlock_all(dev);
goto out;
}
@@ -2245,7 +2249,7 @@ static int setplane_internal(struct drm_plane *plane,
}
drm_modeset_lock_all(dev);
- old_fb = plane-fb;
+ plane-old_fb = plane-fb;
ret = plane-funcs-update_plane(plane, crtc, fb,
crtc_x, crtc_y, crtc_w, crtc_h,
src_x, src_y, src_w, src_h);
@@ -2254,8 +2258,10 @@ static int setplane_internal(struct drm_plane *plane,
plane-fb = fb;
fb = NULL;
} else {
- old_fb = NULL;
+ plane-old_fb = NULL;
}
+ old_fb = plane-old_fb;
+ plane-old_fb = NULL;
drm_modeset_unlock_all(dev);
out:
@@ -2369,7 +2375,7 @@ int drm_mode_set_config_internal(struct drm_mode_set
*set)
* crtcs. Atomic modeset will have saner semantics ...
*/
list_for_each_entry(tmp, crtc-dev-mode_config.crtc_list, head)
- tmp-old_fb = tmp-primary-fb;
+ tmp-primary-old_fb = tmp-primary-fb;
fb = set-fb;
@@ -2382,8 +2388,9 @@ int drm_mode_set_config_internal(struct drm_mode_set
*set)
list_for_each_entry(tmp, crtc-dev-mode_config.crtc_list, head) {
if (tmp-primary-fb)
drm_framebuffer_reference(tmp-primary-fb);
- if (tmp-old_fb)
- drm_framebuffer_unreference(tmp-old_fb);
+ if (tmp-primary-old_fb)
Re: [Intel-gfx] [PATCH] drm/i915: vma/ppgtt lifetime rules
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
Vetter
Sent: Tuesday, July 29, 2014 8:20 PM
To: Ben Widawsky
Cc: Thierry, Michel; intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH] drm/i915: vma/ppgtt lifetime rules
On Tue, Jul 29, 2014 at 11:44:51AM -0700, Ben Widawsky wrote:
On Tue, Jul 29, 2014 at 11:32:07AM -0700, Ben Widawsky wrote:
On Tue, Jul 29, 2014 at 11:08:05AM +0100, Michel Thierry wrote:
VMAs should take a reference of the address space they use.
Now, when the fd is closed, it will release the ref that the context
was
holding, but it will still be referenced by any vmas that are still
active.
ppgtt_release() should then only be called when the last thing
referencing
it releases the ref, and it can just call the base cleanup and free
the
ppgtt.
Signed-off-by: Michel Thierry michel.thie...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_gem.c | 8
drivers/gpu/drm/i915/i915_gem_context.c | 23
+++
drivers/gpu/drm/i915/i915_gem_gtt.c | 5 +
4 files changed, 18 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index 2acc03f..a879a93 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2495,7 +2495,9 @@ void i915_gem_object_ggtt_unpin(struct
drm_i915_gem_object *obj);
/* i915_gem_context.c */
#define ctx_to_ppgtt(ctx) container_of((ctx)-vm, struct
i915_hw_ppgtt, base)
+#define vm_to_ppgtt(vm) container_of(vm, struct i915_hw_ppgtt,
base)
int __must_check i915_gem_context_init(struct drm_device *dev);
+void ppgtt_release(struct kref *kref);
void i915_gem_context_fini(struct drm_device *dev);
void i915_gem_context_reset(struct drm_device *dev);
int i915_gem_context_open(struct drm_device *dev, struct drm_file
*file);
diff --git a/drivers/gpu/drm/i915/i915_gem.c
b/drivers/gpu/drm/i915/i915_gem.c
index dcd8d7b..25a32b9 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4499,12 +4499,20 @@ struct i915_vma
*i915_gem_obj_to_vma(struct drm_i915_gem_object *obj,
void i915_gem_vma_destroy(struct i915_vma *vma)
{
+ struct i915_address_space *vm = NULL;
+ struct i915_hw_ppgtt *ppgtt = NULL;
WARN_ON(vma-node.allocated);
/* Keep the vma as a placeholder in the execbuffer
reservation lists
*/
if (!list_empty(vma-exec_list))
return;
+ vm = vma-vm;
+ ppgtt = vm_to_ppgtt(vm);
+
+ if (ppgtt)
+ kref_put(ppgtt-ref, ppgtt_release);
+
list_del(vma-vma_link);
kfree(vma);
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 5b5af6c..59272f9 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -108,30 +108,13 @@ static void do_ppgtt_cleanup(struct
i915_hw_ppgtt *ppgtt)
return;
}
- /*
-* Make sure vmas are unbound before we take down the drm_mm
-*
-* FIXME: Proper refcounting should take care of this, this
shouldn't
be
-* needed at all.
-*/
- if (!list_empty(vm-active_list)) {
- struct i915_vma *vma;
-
- list_for_each_entry(vma, vm-active_list, mm_list)
- if (WARN_ON(list_empty(vma-vma_link) ||
-
list_is_singular(vma-vma_link)))
- break;
-
- i915_gem_evict_vm(ppgtt-base, true);
- } else {
- i915_gem_retire_requests(dev);
- i915_gem_evict_vm(ppgtt-base, false);
- }
+ /* vmas should already be unbound */
+ WARN_ON(!list_empty(vm-active_list));
ppgtt-base.cleanup(ppgtt-base);
}
-static void ppgtt_release(struct kref *kref)
+void ppgtt_release(struct kref *kref)
{
struct i915_hw_ppgtt *ppgtt =
container_of(kref, struct i915_hw_ppgtt, ref);
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 1411613..90c3d0f 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2159,10 +2159,15 @@
i915_gem_obj_lookup_or_create_vma(struct drm_i915_gem_object *obj,
struct i915_address_space *vm)
{
struct i915_vma *vma;
+ struct i915_hw_ppgtt *ppgtt = NULL;
vma = i915_gem_obj_to_vma(obj, vm);
if (!vma)
vma
Re: [Intel-gfx] [PATCH 7/8] drm/irq: Implement a generic vblank_wait function
On Wed, Jul 30, 2014 at 11:59:33AM +0900, Michel Dänzer wrote:
On 30.07.2014 06:32, Daniel Vetter wrote:
As usual in both a crtc index and a struct drm_crtc * version.
The function assumes that no one drivers their display below 10Hz, and
it will complain if the vblank wait takes longer than that.
v2: Also check dev-max_vblank_counter since some drivers register a
fake get_vblank_counter function.
What does that refer to? Can't find any other reference to
max_vblank_counter in the patch.
Oops, that was from an intermediate version. The v3: text somehow got lost
where I've switched the code from directly calling the -get_counter
callback to using drm_vblank_counter, which will dtrt even when there's
not hw counter available. Will augment the commit message.
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 0de123afdb34..76024fdde452 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -999,6 +999,51 @@ void drm_crtc_vblank_put(struct drm_crtc *crtc)
EXPORT_SYMBOL(drm_crtc_vblank_put);
/**
+ * drm_vblank_wait - wait for one vblank
+ * @dev: DRM device
+ * @crtc: crtc index
+ *
+ * This waits for one vblank to pass on @crtc, using the irq driver
interfaces.
+ * It is a failure to call this when the vblank irq for @crtc is disable,
e.g.
Spelling: 'disabled'
+ * due to lack of driver support or because the crtc is off.
+ */
+void drm_vblank_wait(struct drm_device *dev, int crtc)
+{
+ int ret;
+ u32 last;
+
+ ret = drm_vblank_get(dev, crtc);
+ if (WARN_ON(ret))
+ return;
+
+ last = drm_vblank_count(dev, crtc);
+
+#define C (last != drm_vblank_count(dev, crtc))
+ ret = wait_event_timeout(dev-vblank[crtc].queue,
+C, msecs_to_jiffies(100));
+
+ WARN_ON(ret == 0);
+#undef C
What's the point of the C macro?
Usually the conditions tend to overflow the 80 char limit, so I've adopted
that pattern of extracting it into a local #define. I think it'll fit
here, so will roll in.
+ drm_vblank_put(dev, crtc);
+}
+EXPORT_SYMBOL(drm_vblank_wait);
+
+/**
+ * drm_crtc_vblank_wait - wait for one vblank
+ * @crtc: DRM crtc
+ *
+ * This waits for one vblank to pass on @crtc, using the irq driver
interfaces.
+ * It is a failure to call this when the vblank irq for @crtc is disable,
e.g.
Same typo as above.
+ * due to lack of driver support or because the crtc is off.
+ */
+void drm_crtc_vblank_wait(struct drm_crtc *crtc)
+{
+ drm_vblank_wait(crtc-dev, drm_crtc_index(crtc));
+}
+EXPORT_SYMBOL(drm_crtc_vblank_wait);
+
+/**
Maybe the function names should be *_vblank_wait_next() or something to
clarify the purpose and reduce potential confusion versus drm_wait_vblank().
Yeah that name is just transferred from the i915 driver. What about
drm_wait_one_vblank()/drm_crtc_wait_one_vblank()? At least to my ear
vblank_wait_next sounds backwards.
Looks good to me other than that.
If you're ok with the name suggestion I'll polish resend, thanks for the
comments.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm: Add drm_plane/connector_index
In the atomic state we'll have an array of states for crtcs, planes
and connectors and need to be able to at them by their index. We
already have a drm_crtc_index function so add the missing ones for
planes and connectors.
If it later on turns out that the list walking is too expensive we can
add the index to the relevant modeset objects.
Rob Clark doesn't like the loops too much, but we can always add an
obj-idx parameter later on. And for now reiterating is actually safer
since nowadays we have hotpluggable connectors (thanks to DP MST).
v2: Fix embarrassing copypasta fail in kerneldoc and header
declarations, spotted by Matt Roper.
Cc: Matt Roper matthew.d.ro...@intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/drm_crtc.c | 46 ++
include/drm/drm_crtc.h | 2 ++
2 files changed, 48 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 805240b11229..ff1f2f46ef1d 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -937,6 +937,29 @@ void drm_connector_cleanup(struct drm_connector *connector)
EXPORT_SYMBOL(drm_connector_cleanup);
/**
+ * drm_connector_index - find the index of a registered connector
+ * @connector: connector to find index for
+ *
+ * Given a registered connector, return the index of that connector within a
DRM
+ * device's list of connectors.
+ */
+unsigned int drm_connector_index(struct drm_connector *connector)
+{
+ unsigned int index = 0;
+ struct drm_connector *tmp;
+
+ list_for_each_entry(tmp, connector-dev-mode_config.connector_list,
head) {
+ if (tmp == connector)
+ return index;
+
+ index++;
+ }
+
+ BUG();
+}
+EXPORT_SYMBOL(drm_connector_index);
+
+/**
* drm_connector_register - register a connector
* @connector: the connector to register
*
@@ -1239,6 +1262,29 @@ void drm_plane_cleanup(struct drm_plane *plane)
EXPORT_SYMBOL(drm_plane_cleanup);
/**
+ * drm_plane_index - find the index of a registered plane
+ * @plane: plane to find index for
+ *
+ * Given a registered plane, return the index of that CRTC within a DRM
+ * device's list of planes.
+ */
+unsigned int drm_plane_index(struct drm_plane *plane)
+{
+ unsigned int index = 0;
+ struct drm_plane *tmp;
+
+ list_for_each_entry(tmp, plane-dev-mode_config.plane_list, head) {
+ if (tmp == plane)
+ return index;
+
+ index++;
+ }
+
+ BUG();
+}
+EXPORT_SYMBOL(drm_plane_index);
+
+/**
* drm_plane_force_disable - Forcibly disable a plane
* @plane: plane to disable
*
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index f1105d0da059..3bd60313250c 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -903,6 +903,7 @@ int drm_connector_register(struct drm_connector *connector);
void drm_connector_unregister(struct drm_connector *connector);
extern void drm_connector_cleanup(struct drm_connector *connector);
+extern unsigned int drm_connector_index(struct drm_connector *connector);
/* helper to unplug all connectors from sysfs for device */
extern void drm_connector_unplug_all(struct drm_device *dev);
@@ -942,6 +943,7 @@ extern int drm_plane_init(struct drm_device *dev,
const uint32_t *formats, uint32_t format_count,
bool is_primary);
extern void drm_plane_cleanup(struct drm_plane *plane);
+extern unsigned int drm_plane_index(struct drm_plane *plane);
extern void drm_plane_force_disable(struct drm_plane *plane);
extern int drm_crtc_check_viewport(const struct drm_crtc *crtc,
int x, int y,
--
2.0.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/8] drm/irq: Implement a generic vblank_wait function
On 30.07.2014 17:22, Daniel Vetter wrote:
On Wed, Jul 30, 2014 at 11:59:33AM +0900, Michel Dänzer wrote:
On 30.07.2014 06:32, Daniel Vetter wrote:
+ * due to lack of driver support or because the crtc is off.
+ */
+void drm_crtc_vblank_wait(struct drm_crtc *crtc)
+{
+ drm_vblank_wait(crtc-dev, drm_crtc_index(crtc));
+}
+EXPORT_SYMBOL(drm_crtc_vblank_wait);
+
+/**
Maybe the function names should be *_vblank_wait_next() or something to
clarify the purpose and reduce potential confusion versus drm_wait_vblank().
Yeah that name is just transferred from the i915 driver. What about
drm_wait_one_vblank()/drm_crtc_wait_one_vblank()?
I don't care that much :), go ahead.
--
Earthling Michel Dänzer| http://www.amd.com
Libre software enthusiast |Mesa and X developer
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm: Handle legacy per-crtc locking with full acquire ctx
So drivers using the atomic interfaces expect that they can acquire
additional locks internal to the driver as-needed. Examples would be
locks to protect shared state like shared display PLLs.
Unfortunately the legacy ioctls assume that all locking is fully done
by the drm core. Now for those paths which grab all locks we already
have to keep around an acquire context in dev-mode_config. Helper
functions that implement legacy interfaces in terms of atomic support
can therefore grab this acquire contexts and reuse it.
The only interfaces left are the cursor and pageflip ioctls. So add
functions to grab the crtc lock these need using an acquire context
and preserve it for atomic drivers to reuse.
v2:
- Fixup commentskerneldoc.
- Drop the WARNING from modeset_lock_all_crtcs since that can be used
in legacy paths with crtc locking.
v3: Fix a type on the kerneldoc Dave spotted.
Cc: Dave Airlie airl...@redhat.com
Reviewed-by: Dave Airlie airl...@redhat.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/drm_crtc.c | 8 ++--
drivers/gpu/drm/drm_modeset_lock.c | 84 ++
include/drm/drm_crtc.h | 6 +++
include/drm/drm_modeset_lock.h | 5 +++
4 files changed, 99 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index d90374e6a8cb..cb741cd8bfe9 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -2714,7 +2714,7 @@ static int drm_mode_cursor_common(struct drm_device *dev,
if (crtc-cursor)
return drm_mode_cursor_universal(crtc, req, file_priv);
- drm_modeset_lock(crtc-mutex, NULL);
+ drm_modeset_lock_crtc(crtc);
if (req-flags DRM_MODE_CURSOR_BO) {
if (!crtc-funcs-cursor_set !crtc-funcs-cursor_set2) {
ret = -ENXIO;
@@ -2738,7 +2738,7 @@ static int drm_mode_cursor_common(struct drm_device *dev,
}
}
out:
- drm_modeset_unlock(crtc-mutex);
+ drm_modeset_unlock_crtc(crtc);
return ret;
@@ -4474,7 +4474,7 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
if (!crtc)
return -ENOENT;
- drm_modeset_lock(crtc-mutex, NULL);
+ drm_modeset_lock_crtc(crtc);
if (crtc-primary-fb == NULL) {
/* The framebuffer is currently unbound, presumably
* due to a hotplug event, that userspace has not
@@ -4558,7 +4558,7 @@ out:
drm_framebuffer_unreference(fb);
if (old_fb)
drm_framebuffer_unreference(old_fb);
- drm_modeset_unlock(crtc-mutex);
+ drm_modeset_unlock_crtc(crtc);
return ret;
}
diff --git a/drivers/gpu/drm/drm_modeset_lock.c
b/drivers/gpu/drm/drm_modeset_lock.c
index 73e6534fd0aa..4753c8bd5ab5 100644
--- a/drivers/gpu/drm/drm_modeset_lock.c
+++ b/drivers/gpu/drm/drm_modeset_lock.c
@@ -130,6 +130,90 @@ void drm_modeset_unlock_all(struct drm_device *dev)
EXPORT_SYMBOL(drm_modeset_unlock_all);
/**
+ * drm_modeset_lock_crtc - lock crtc with hidden acquire ctx
+ * @crtc: drm crtc
+ *
+ * This function locks the given crtc using a hidden acquire context. This is
+ * necessary so that drivers internally using the atomic interfaces can grab
+ * further locks with the lock acquire context.
+ */
+void drm_modeset_lock_crtc(struct drm_crtc *crtc)
+{
+ struct drm_modeset_acquire_ctx *ctx;
+ int ret;
+
+ ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
+ if (WARN_ON(!ctx))
+ return;
+
+ drm_modeset_acquire_init(ctx, 0);
+
+retry:
+ ret = drm_modeset_lock(crtc-mutex, ctx);
+ if (ret)
+ goto fail;
+
+ WARN_ON(crtc-acquire_ctx);
+
+ /* now we hold the locks, so now that it is safe, stash the
+* ctx for drm_modeset_unlock_crtc():
+*/
+ crtc-acquire_ctx = ctx;
+
+ return;
+
+fail:
+ if (ret == -EDEADLK) {
+ drm_modeset_backoff(ctx);
+ goto retry;
+ }
+}
+EXPORT_SYMBOL(drm_modeset_lock_crtc);
+
+/**
+ * drm_modeset_legacy_acquire_ctx - find acquire ctx for legacy ioctls
+ * crtc: drm crtc
+ *
+ * Legacy ioctl operations like cursor updates or page flips only have per-crtc
+ * locking, and store the acquire ctx in the corresponding crtc. All other
+ * legacy operations take all locks and use a global acquire context. This
+ * function grabs the right one.
+ */
+struct drm_modeset_acquire_ctx *
+drm_modeset_legacy_acquire_ctx(struct drm_crtc *crtc)
+{
+ if (crtc-acquire_ctx)
+ return crtc-acquire_ctx;
+
+ WARN_ON(!crtc-dev-mode_config.acquire_ctx);
+
+ return crtc-dev-mode_config.acquire_ctx;
+}
+EXPORT_SYMBOL(drm_modeset_legacy_acquire_ctx);
+
+/**
+ * drm_modeset_unlock_crtc - drop crtc lock
+ * @crtc: drm crtc
+ *
+ * This drops the crtc lock acquire with drm_modeset_lock_crtc() and all other
+ * locks acquired through the hidden
[Intel-gfx] [PATCH] drm: Move -old_fb from crtc to plane
Atomic implemenations for legacy ioctls must be able to drop locks.
Which doesn't cause havoc since we only do that while constructing
the new state, so no driver or hardware state change has happened.
The only troubling bit is the fb refcounting the core does - if
someone else has snuck in then it might potentially unref an
outdated framebuffer. To fix that move the old_fb temporary storage
into struct drm_plane for all ioctls, so that the atomic helpers can
update it.
v2: Fix up the error case handling as suggested by Matt Roper and just
grab locks uncoditionally - there's no point in optimizing the locking
for when userspace gets it wrong.
Cc: Matt Roper matthew.d.ro...@intel.com
Cc: Dave Airlie airl...@redhat.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/drm_crtc.c | 46 --
include/drm/drm_crtc.h | 8
2 files changed, 28 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index cb741cd8bfe9..c8f9911bd238 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1200,19 +1200,21 @@ EXPORT_SYMBOL(drm_plane_index);
*/
void drm_plane_force_disable(struct drm_plane *plane)
{
- struct drm_framebuffer *old_fb = plane-fb;
int ret;
- if (!old_fb)
+ if (!plane-fb)
return;
+ plane-old_fb = plane-fb;
ret = plane-funcs-disable_plane(plane);
if (ret) {
DRM_ERROR(failed to disable plane with busy fb\n);
+ plane-old_fb = NULL;
return;
}
/* disconnect the plane from the fb and crtc: */
- __drm_framebuffer_unreference(old_fb);
+ __drm_framebuffer_unreference(plane-old_fb);
+ plane-old_fb = NULL;
plane-fb = NULL;
plane-crtc = NULL;
}
@@ -2188,23 +2190,21 @@ static int setplane_internal(struct drm_plane *plane,
uint32_t src_w, uint32_t src_h)
{
struct drm_device *dev = plane-dev;
- struct drm_framebuffer *old_fb = NULL;
int ret = 0;
unsigned int fb_width, fb_height;
int i;
+ drm_modeset_lock_all(dev);
/* No fb means shut it down */
if (!fb) {
- drm_modeset_lock_all(dev);
- old_fb = plane-fb;
+ plane-old_fb = plane-fb;
ret = plane-funcs-disable_plane(plane);
if (!ret) {
plane-crtc = NULL;
plane-fb = NULL;
} else {
- old_fb = NULL;
+ plane-old_fb = NULL;
}
- drm_modeset_unlock_all(dev);
goto out;
}
@@ -2244,8 +2244,7 @@ static int setplane_internal(struct drm_plane *plane,
goto out;
}
- drm_modeset_lock_all(dev);
- old_fb = plane-fb;
+ plane-old_fb = plane-fb;
ret = plane-funcs-update_plane(plane, crtc, fb,
crtc_x, crtc_y, crtc_w, crtc_h,
src_x, src_y, src_w, src_h);
@@ -2254,15 +2253,16 @@ static int setplane_internal(struct drm_plane *plane,
plane-fb = fb;
fb = NULL;
} else {
- old_fb = NULL;
+ plane-old_fb = NULL;
}
- drm_modeset_unlock_all(dev);
out:
if (fb)
drm_framebuffer_unreference(fb);
- if (old_fb)
- drm_framebuffer_unreference(old_fb);
+ if (plane-old_fb)
+ drm_framebuffer_unreference(plane-old_fb);
+ plane-old_fb = NULL;
+ drm_modeset_unlock_all(dev);
return ret;
@@ -2369,7 +2369,7 @@ int drm_mode_set_config_internal(struct drm_mode_set *set)
* crtcs. Atomic modeset will have saner semantics ...
*/
list_for_each_entry(tmp, crtc-dev-mode_config.crtc_list, head)
- tmp-old_fb = tmp-primary-fb;
+ tmp-primary-old_fb = tmp-primary-fb;
fb = set-fb;
@@ -2382,8 +2382,9 @@ int drm_mode_set_config_internal(struct drm_mode_set *set)
list_for_each_entry(tmp, crtc-dev-mode_config.crtc_list, head) {
if (tmp-primary-fb)
drm_framebuffer_reference(tmp-primary-fb);
- if (tmp-old_fb)
- drm_framebuffer_unreference(tmp-old_fb);
+ if (tmp-primary-old_fb)
+ drm_framebuffer_unreference(tmp-primary-old_fb);
+ tmp-primary-old_fb = NULL;
}
return ret;
@@ -4458,7 +4459,7 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
{
struct drm_mode_crtc_page_flip *page_flip = data;
struct drm_crtc *crtc;
- struct drm_framebuffer *fb = NULL, *old_fb = NULL;
+ struct drm_framebuffer *fb = NULL;
struct drm_pending_vblank_event *e = NULL;
[Intel-gfx] [PATCH] drm/irq: Implement a generic vblank_wait function
As usual in both a crtc index and a struct drm_crtc * version.
The function assumes that no one drivers their display below 10Hz, and
it will complain if the vblank wait takes longer than that.
v2: Also check dev-max_vblank_counter since some drivers register a
fake get_vblank_counter function.
v3: Use drm_vblank_count instead of calling the low-level
-get_vblank_counter callback. That way we'll get the sw-cooked
counter for platforms without proper vblank support and so can ditch
the max_vblank_counter check again.
v4: Review from Michel Dänzer:
- Restore lost notes about v3:
- Spelling in kerneldoc.
- Inline wait_event condition.
- s/vblank_wait/wait_one_vblank/
Cc: Michel Dänzer mic...@daenzer.net
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/drm_irq.c | 44
include/drm/drmP.h| 2 ++
2 files changed, 46 insertions(+)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 0de123afdb34..2605a5923fdb 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -999,6 +999,50 @@ void drm_crtc_vblank_put(struct drm_crtc *crtc)
EXPORT_SYMBOL(drm_crtc_vblank_put);
/**
+ * drm_wait_one_vblank - wait for one vblank
+ * @dev: DRM device
+ * @crtc: crtc index
+ *
+ * This waits for one vblank to pass on @crtc, using the irq driver interfaces.
+ * It is a failure to call this when the vblank irq for @crtc is disabled, e.g.
+ * due to lack of driver support or because the crtc is off.
+ */
+void drm_wait_one_vblank(struct drm_device *dev, int crtc)
+{
+ int ret;
+ u32 last;
+
+ ret = drm_vblank_get(dev, crtc);
+ if (WARN_ON(ret))
+ return;
+
+ last = drm_vblank_count(dev, crtc);
+
+ ret = wait_event_timeout(dev-vblank[crtc].queue,
+last != drm_vblank_count(dev, crtc),
+msecs_to_jiffies(100));
+
+ WARN_ON(ret == 0);
+
+ drm_vblank_put(dev, crtc);
+}
+EXPORT_SYMBOL(drm_wait_one_vblank);
+
+/**
+ * drm_crtc_wait_one_vblank - wait for one vblank
+ * @crtc: DRM crtc
+ *
+ * This waits for one vblank to pass on @crtc, using the irq driver interfaces.
+ * It is a failure to call this when the vblank irq for @crtc is disabled, e.g.
+ * due to lack of driver support or because the crtc is off.
+ */
+void drm_crtc_wait_one_vblank(struct drm_crtc *crtc)
+{
+ drm_wait_one_vblank(crtc-dev, drm_crtc_index(crtc));
+}
+EXPORT_SYMBOL(drm_crtc_wait_one_vblank);
+
+/**
* drm_vblank_off - disable vblank events on a CRTC
* @dev: DRM device
* @crtc: CRTC in question
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 06a673894c47..ee4c321455e8 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1355,6 +1355,8 @@ extern int drm_vblank_get(struct drm_device *dev, int
crtc);
extern void drm_vblank_put(struct drm_device *dev, int crtc);
extern int drm_crtc_vblank_get(struct drm_crtc *crtc);
extern void drm_crtc_vblank_put(struct drm_crtc *crtc);
+extern void drm_wait_one_vblank(struct drm_device *dev, int crtc);
+extern void drm_crtc_wait_one_vblank(struct drm_crtc *crtc);
extern void drm_vblank_off(struct drm_device *dev, int crtc);
extern void drm_vblank_on(struct drm_device *dev, int crtc);
extern void drm_crtc_vblank_off(struct drm_crtc *crtc);
--
2.0.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Use generic vblank wait
This has the upside that it will no longer steal interrupts from the
interrutp handler on pre-g4x. Furthermore this will now scream properly
on all platforms if we don't have hw counters enabled.
v2: Adjust to the new names.
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_display.c | 41 +---
1 file changed, 1 insertion(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 1edfd1ae5b37..540fc762179f 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -891,17 +891,6 @@ enum transcoder intel_pipe_to_cpu_transcoder(struct
drm_i915_private *dev_priv,
return intel_crtc-config.cpu_transcoder;
}
-static void g4x_wait_for_vblank(struct drm_device *dev, int pipe)
-{
- struct drm_i915_private *dev_priv = dev-dev_private;
- u32 frame, frame_reg = PIPE_FRMCOUNT_GM45(pipe);
-
- frame = I915_READ(frame_reg);
-
- if (wait_for(I915_READ_NOTRACE(frame_reg) != frame, 50))
- WARN(1, vblank wait timed out\n);
-}
-
/**
* intel_wait_for_vblank - wait for vblank on a given pipe
* @dev: drm device
@@ -912,35 +901,7 @@ static void g4x_wait_for_vblank(struct drm_device *dev,
int pipe)
*/
void intel_wait_for_vblank(struct drm_device *dev, int pipe)
{
- struct drm_i915_private *dev_priv = dev-dev_private;
- int pipestat_reg = PIPESTAT(pipe);
-
- if (IS_G4X(dev) || INTEL_INFO(dev)-gen = 5) {
- g4x_wait_for_vblank(dev, pipe);
- return;
- }
-
- /* Clear existing vblank status. Note this will clear any other
-* sticky status fields as well.
-*
-* This races with i915_driver_irq_handler() with the result
-* that either function could miss a vblank event. Here it is not
-* fatal, as we will either wait upon the next vblank interrupt or
-* timeout. Generally speaking intel_wait_for_vblank() is only
-* called during modeset at which time the GPU should be idle and
-* should *not* be performing page flips and thus not waiting on
-* vblanks...
-* Currently, the result of us stealing a vblank from the irq
-* handler is that a single frame will be skipped during swapbuffers.
-*/
- I915_WRITE(pipestat_reg,
- I915_READ(pipestat_reg) | PIPE_VBLANK_INTERRUPT_STATUS);
-
- /* Wait for vblank interrupt bit to set */
- if (wait_for(I915_READ(pipestat_reg)
-PIPE_VBLANK_INTERRUPT_STATUS,
-50))
- DRM_DEBUG_KMS(vblank wait timed out\n);
+ drm_wait_one_vblank(dev, pipe);
}
static bool pipe_dsl_stopped(struct drm_device *dev, enum pipe pipe)
--
2.0.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] Displayport compliance testing
On Tue, Jul 29, 2014 at 06:53:57PM -0300, Paulo Zanoni wrote: 2014-07-22 18:11 GMT-03:00 Jesse Barnes jbar...@virtuousgeek.org: On Tue, 22 Jul 2014 22:53:44 +0200 Daniel Vetter dan...@ffwll.ch wrote: On Tue, Jul 22, 2014 at 10:48 PM, Jesse Barnes jbar...@virtuousgeek.org wrote: Are you saying you'll reject this approach entirely? I'm saying that I don't see terrible lot of value in adding a bunch of code for a sticker, and that we should look into making it actually useful by testing the paths that end-users end up using. And we have to keep this working once it's merged. But if it doesn't make sense to make this sticker useful while still being able to get it then I'll reconsider. Yeah I think it depends on the test. We're supposed to go through existing paths for testing e.g. link training with different params (though with a fixed fb and mode), so getting coverage there is something we want regardless. But getting something like probing covered as part of the compliance testing may be something else entirely... I was finally able to take some time to read the spec, and I agree that the hybrid approach looks like the way to go. Some tests require specifically-crafted FBs, while some other tests cause real hotplug events to be sent from the sink. If there's an unknown/unspecified user-space running when the tests are happening, who knows how it is going to react? Of course, for tests that can be implemented directly inside the Kernel still using the standard code paths, we should do it in the Kernel. One possible approach that I thought would be the following: - Each DP encoder provides its own debugfs file for DP test compiance (e.g., /sys/kernel/debug/dri/0/i915_ddi_b_dp_test_compliance). - If the file is not open, any requests for tests that require special actions from our driver - outside of the normal behavior - will be NACKed. Yeah that sounds like a reasonable safety measure to make sure we don't do stupid things (e.g. malicious DP connector trying to break into the kernel). - If the file is open, we ACK test requests and print special strings to the debugfs file telling the user-space app what it's supposed to do. We could use simple strings like set the preferred mode, set failsafe mode, set mode using FB test pattern Y, etc. A stringly typed protocol :) We need to check how much work this is, since we'll probably need to implement polling. Otoh we've just done that for the crc interfaces, so shouldn't be too much fuzz. If userspace needs to do special dp aux transactions I still think we should simply expose a proper dp aux interface, similar to i2c. - The user-space app needs to be the DRM master, open the debugfs file, parse the operations it prints and act accordingly, and listen to the hotplug events sent by the Kernel. - If some special corner quirky case needs to be done (e.g., train link with a specific number of lanes), the Kernel should store this information at struct intel_dp, and then when a modeset is done on this encoder, we check if the debugfs file is open (i.e., we're doing compliance testing) and then we use the specified configuration. With this, we can probably avoid special uevents or debug-only connector/encoder properties. - The user-space app could be part of intel-gpu-tools. Anyway, this is just an alternate idea to Daniel's suggestion, and many other possible implementation ideas would work for me. Todd, what is your opinion? Well I've only tossed out a rough idea that we should try to use the same paths for validation as userspace is using in general. Sounds like you have some good ideas how to get there in practice. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 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] i915 / 3.15 intermittently boots into blank screeen
On Wed, Jul 30, 2014 at 12:01:38AM +0200, Jan Niggemann wrote: Am 29.07.2014 23:35, schrieb Daniel Vetter: On Tue, Jul 29, 2014 at 11:09 PM, Jan Niggemann j...@hz6.de wrote: Am 18.07.2014 18:25, schrieb Daniel Vetter: On Fri, Jul 18, 2014 at 4:49 PM, Jan Niggemann j...@hz6.de wrote: Am 18.07.2014 15:27, schrieb Daniel Vetter: On Thu, Jul 17, 2014 at 10:31:30PM +0200, Jan Niggemann wrote: I'm experiencing an issue with 3.15.5 on my Lenovo T400: Since 3.15 (or 3.14, can't say for sure), the boot starts normally, but the first mode change doesn't occur, resulting in a black screen with backlight on. The system is entirely unresponsive and I can only press the power button until to switch it off. I think the only way to move forward here is to double-check that 3.14 works and 3.15 is broken by recompiling with the same .config (occasionally config changes cause regressions). And then do a full git bisect to find the offending commit. thank you for the feedback. I still have all my custom built kernels, I will test 3.14.0 through 3.14.8 to make sure those were OK and report back. You only need to test 3.14.0, since the backported fixes only contain a very small subset of all patches for 3.15. So it's more efficient to then switch to git bisect between 3.14 and 3.15 directly (after you've confirmed that 3.15.0 is indeed busted). I familiarized with git bisect, that was something I had never used before. I started it with git bisect start v3.15 v3.14 -- drivers/gpu/drm/i915 This lead me to this: cfa7c862982b431add7f2b362526bf31372fc7b0 is the first bad commit commit cfa7c862982b431add7f2b362526bf31372fc7b0 Author: Daniel Vetter daniel.vet...@ffwll.ch Date: Tue Apr 29 11:53:58 2014 +0200 drm/i915: Sanitize the enable_ppgtt module option once Otherwise we'll end up spamming dmesg on every context creation on snb with vt-d enabled. This regression was introduced in commit 246cbfb5fb9a1ca0997fbb135464c1ff5bb9c549 Author: Ben Widawsky benjamin.widaw...@intel.com Date: Fri Dec 6 14:11:14 2013 -0800 drm/i915: Reorganize intel_enable_ppgtt As the i915.enable_ppgtt is read-only it cannot be changed after the module is loaded and so we can perform an early sanitization of the values. v2: - Add comment and pimp commit message (Chris) - Use the param consistently (Jani) v3: - Fix init sequence on pre-gen6 by moving the sanitize_ppgtt call to gtt_init. Fixes boot hangs on pre-gen6. - Add a debug output for the sanitize ppgtt mode. References: https://lkml.org/lkml/2014/4/17/599 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77916 Cc: Alessandro Suardi alessandro.sua...@gmail.com Cc: Ben Widawsky b...@bwidawsk.net Cc: Chris Wilson ch...@chris-wilson.co.uk Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch Signed-off-by: Jani Nikula jani.nik...@intel.com :04 04 5488e397a1aaa28dca4a252452e9463b0a8f8d10 214c8e98b3c72844e48ab7aef02cba7daf139fab M drivers I realized that the issue does always show, contrary to the subject initially chosen. Unfortunately I can't say anything else, but maybe this will help you experts spot the issue. If I can help more, be it with testing or anything else, just let me know. Hm, I'm not aware of this breaking any gm45 machines, mine here is still happy. Can you please make sure that you don't have any i915 module options set anywhere, either on the kernel cmdline, modeprobe config files in /etc or anywhere else? My kernel cmdline doesn't have anything, but /etc/modprobe.d/i915-kms.conf exists. Its content is this single line: options i915 modeset=1 Can't remember if I created that (it's from 2010) or if it's Debian default... grep -Ri i915 /etc/ doesn't show anything else. grep 915 config-3.15 CONFIG_DRM_I915=m CONFIG_DRM_I915_KMS=y CONFIG_DRM_I915_FBDEV=y # CONFIG_DRM_I915_PRELIMINARY_HW_SUPPORT is not set # CONFIG_DRM_I915_UMS is not set CONFIG_SND_HDA_I915=y Would it help if I included the driver instead of building a module? Shouldn't change anything really, and config all looks sane. Can you please retest with latest upstream (3.16 or even drm-intel-nightly)? Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 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] [RFC] Move BDW workarounds to ring init fn
On Tue, Jul 29, 2014 at 11:27:55PM +0100, Siluvery, Arun wrote: On 28/07/2014 18:26, Ville Syrjälä wrote: On Mon, Jul 28, 2014 at 05:31:45PM +0100, arun.siluv...@linux.intel.com wrote: From: Arun Siluvery arun.siluv...@linux.intel.com This patch moves BDW workarounds from init_clock_gating() to render ring init fn otherwise they are lost when gpu is reset. In case of execlists, some of the workarounds modify registers that are part of register state context which doesn't get initialized until init_clock_gating(); this results in default context with incorrect values as it is restored and saved before updated by workarounds. I don't think it has to do with execlists. Many of the registers are part of the context image even in ring buffer mode AFAIK. Open issue: For Wa4x4STCOptimizationDisable, we set CACHE_MODE_1[6:6] = 1 At the time when HW contexts are enabled after rings are initialized with default context this workaround is valid but followed by a context switch this is getting reset, please see below log snippet. This is a bit weird. The default context should have restore inhibit==1 so it shouldn't clobber the CACHE_MODE_1 register. There was a specific magic dance you're supposed to do when accessing such registers with mmio, but here we do the write even before the first context switch. Apparently there was some kind of problem with CACHE_MODE_0 on snb too: commit 3a69ddd6f872180b6f61fda87152b37202118fbc Author: Kenneth Graunke kenn...@whitecape.org Date: Fri Apr 27 12:44:41 2012 -0700 drm/i915: Set the Stencil Cache eviction policy to non-LRA mode. but IIRC I wasn't able to reproduce it when I tried. Similar to this register I am also applying this in render ring init fn. Maybe we need to delay these register writes until we've switched to the default context? In its current state (WAs applied in init_clock_gating()) we are writing these registers after switching to default context. When a new hw context is created does all the registers part of context start with default values or they sample the current state? and at what point this sampling takes place? We load each uninitialized context with restore inhibit=true so AFAIK the current register values should stay intact. As a test I have updated CACHE_MODE_1 after mi_set_context() then the workaround was valid with every context switch but I think it may not be the right way otherwise we will have to update other WA registers also at this point with every context switch. Maybe there's something special about the very first context switch? Though I don't see why that would be the case. regards Arun ... [5.978209] [drm:i915_pages_create_for_stolen] offset=0x0, size=8294400 [5.978213] [drm:intel_alloc_plane_obj] plane fb obj 8801472e [5.978215] [drm:i915_gem_setup_global_gtt] reserving preallocated space: 0 + 7e9000 [5.978216] [drm:i915_gem_setup_global_gtt] clearing unused GTT space: [7e9000, f000] [5.979613] [drm:i915_gem_init] CACHE_MODE_1: 0x0180 [5.981372] [drm:gen8_ppgtt_init] Allocated 4 pages for page directories (0 wasted) [5.981373] [drm:gen8_ppgtt_init] Allocated 2048 pages for page tables (0 wasted) [5.981376] [drm:i915_gem_context_init] HW context support initialized [5.981462] [drm:i915_gem_init_hw] CACHE_MODE_1: 0x0180 [5.981467] [drm:i915_gem_init_rings] CACHE_MODE_1: 0x0180 [5.981704] [drm:bdw_init_workarounds] CACHE_MODE_1: 0x01C0 [5.981716] [drm:init_status_page] bsd ring hws offset: 0x0081e000 [5.981792] [drm:init_status_page] blitter ring hws offset: 0x0083f000 [5.981910] [drm:init_status_page] video enhancement ring hws offset: 0x0086 [5.982001] [drm:i915_gem_init_hw] CACHE_MODE_1: 0x01C0 [5.982104] [drm:i915_gem_context_enable] Switch render ring to default_context [5.982106] [drm:i915_gem_render_state_init] render ring: Render state init [5.982120] [drm:do_switch] render ring, CACHE_MODE_1: 0x01C0, uninitialized: 1 [5.982121] [drm:i915_gem_context_enable] Switch bsd ring to default_context [5.982122] [drm:do_switch] bsd ring, CACHE_MODE_1: 0x01C0, uninitialized: 0 [5.982123] [drm:i915_gem_context_enable] Switch blitter ring to default_context [5.982126] [drm:do_switch] blitter ring, CACHE_MODE_1: 0x01C0, uninitialized: 0 [5.982126] [drm:i915_gem_context_enable] Switch video enhancement ring to default_context [5.982128] [drm:do_switch] video enhancement ring, CACHE_MODE_1: 0x01C0, uninitialized: 0 [5.982133] [drm:i915_gem_init] CACHE_MODE_1: 0x01C0 [5.982258] [drm:intel_init_clock_gating] ... [ 10.037019] [drm:do_switch] blitter ring, CACHE_MODE_1: 0x0180, uninitialized: 0 ... [ 10.488145] [drm:do_switch] render ring,
Re: [Intel-gfx] [Xen-devel] [Announcement] Updates to XenGT - a Mediated Graphics Passthrough Solution from Intel
On 07/29/2014 06:09 PM, Dario Faggioli wrote: Perhaps the info is available somewhere already (in which case, sorry), but what's the (if any) upstreaming plan/status/ETA? I think this info could well be part of these updates. :-) Thanks for your opinion :-) We plan to start the upstreaming work in this quarter. For your information, Wei's IOREQ server enhancement(aka Extend ioreq-server to support page write protection) is actually part of the upstreaming effort. Patches for different components will be sent out later. Thanks and Regards, Dario -- Thanks, Jike ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/irq: Implement a generic vblank_wait function
On 30.07.2014 18:25, Daniel Vetter wrote: As usual in both a crtc index and a struct drm_crtc * version. The function assumes that no one drivers their display below 10Hz, and it will complain if the vblank wait takes longer than that. v2: Also check dev-max_vblank_counter since some drivers register a fake get_vblank_counter function. v3: Use drm_vblank_count instead of calling the low-level -get_vblank_counter callback. That way we'll get the sw-cooked counter for platforms without proper vblank support and so can ditch the max_vblank_counter check again. v4: Review from Michel Dänzer: - Restore lost notes about v3: - Spelling in kerneldoc. - Inline wait_event condition. - s/vblank_wait/wait_one_vblank/ Cc: Michel Dänzer mic...@daenzer.net Cc: Ville Syrjälä ville.syrj...@linux.intel.com Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch Reviewed-by: Michel Dänzer michel.daen...@amd.com -- Earthling Michel Dänzer| http://www.amd.com Libre software enthusiast |Mesa and X developer ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: Move i915_gem_chipset_flush to where it belongs
Include depency hell ftw! So need to move this into a real function.
Also fix up the header include order in i915_drv.h: The rule is to
always include core headers first, then local stuff.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_drv.h | 7 ---
drivers/gpu/drm/i915/i915_gem_gtt.c | 6 ++
drivers/gpu/drm/i915/i915_gem_gtt.h | 2 ++
3 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a89eb87e4af6..c783cfe5515d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2541,13 +2541,6 @@ int __must_check i915_gem_evict_something(struct
drm_device *dev,
int i915_gem_evict_vm(struct i915_address_space *vm, bool do_idle);
int i915_gem_evict_everything(struct drm_device *dev);
-/* belongs in i915_gem_gtt.h */
-static inline void i915_gem_chipset_flush(struct drm_device *dev)
-{
- if (INTEL_INFO(dev)-gen 6)
- intel_gtt_chipset_flush();
-}
-
/* i915_gem_stolen.c */
int i915_gem_init_stolen(struct drm_device *dev);
int i915_gem_stolen_setup_compression(struct drm_device *dev, int size, int
fb_cpp);
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 58c8f99680a6..9c9fac190ad4 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2031,6 +2031,12 @@ static void gen6_gmch_remove(struct i915_address_space
*vm)
teardown_scratch_page(vm-dev);
}
+void i915_gem_chipset_flush(struct drm_device *dev)
+{
+ if (INTEL_INFO(dev)-gen 6)
+ intel_gtt_chipset_flush();
+}
+
static int i915_gmch_probe(struct drm_device *dev,
size_t *gtt_total,
size_t *stolen,
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index c2ff69e1f781..00148266ee6f 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -292,4 +292,6 @@ void i915_gem_restore_gtt_mappings(struct drm_device *dev);
int __must_check i915_gem_gtt_prepare_object(struct drm_i915_gem_object *obj);
void i915_gem_gtt_finish_object(struct drm_i915_gem_object *obj);
+void i915_gem_chipset_flush(struct drm_device *dev);
+
#endif
--
2.0.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: Some cleanups for the ppgtt lifetime handling
So when reviewing Michel's patch I've noticed a few things and cleaned
them up:
- The early checks in ppgtt_release are now redundant: The inactive
list should always be empty now, so we can ditch these checks. Even
for the aliasing ppgtt (though that's a different confusion) since
we tear that down after all the objects are gone.
- The ppgtt handling functions are splattered all over. Consolidate
them in i915_gem_gtt.c, give them OCD prefixes and add wrappers for
get/put.
- There was a bit a confusion in ppgtt_release about whether it cares
about the active or inactive list. It should care about them both,
so augment the WARNINGs to check for both.
There's still create_vm_for_ctx left to do, put that is blocked on the
removal of ppgtt-ctx. Once that's done we can rename it to
i915_ppgtt_create and move it to its siblings for handling ppgtts.
Cc: Michel Thierry michel.thie...@intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_drv.h | 1 -
drivers/gpu/drm/i915/i915_gem.c | 2 +-
drivers/gpu/drm/i915/i915_gem_context.c | 35 -
drivers/gpu/drm/i915/i915_gem_gtt.c | 17 ++--
drivers/gpu/drm/i915/i915_gem_gtt.h | 12 ++-
5 files changed, 31 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 5fe3b1dfc34c..a89eb87e4af6 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2497,7 +2497,6 @@ void i915_gem_object_ggtt_unpin(struct
drm_i915_gem_object *obj);
#define ctx_to_ppgtt(ctx) container_of((ctx)-vm, struct i915_hw_ppgtt, base)
#define vm_to_ppgtt(vm) container_of(vm, struct i915_hw_ppgtt, base)
int __must_check i915_gem_context_init(struct drm_device *dev);
-void ppgtt_release(struct kref *kref);
void i915_gem_context_fini(struct drm_device *dev);
void i915_gem_context_reset(struct drm_device *dev);
int i915_gem_context_open(struct drm_device *dev, struct drm_file *file);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 25a32b9c9b4b..1a46be5d2979 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4511,7 +4511,7 @@ void i915_gem_vma_destroy(struct i915_vma *vma)
ppgtt = vm_to_ppgtt(vm);
if (ppgtt)
- kref_put(ppgtt-ref, ppgtt_release);
+ i915_ppgtt_put(ppgtt);
list_del(vma-vma_link);
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index ae706cba05ae..603a227e3aaa 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -96,33 +96,6 @@
#define GEN6_CONTEXT_ALIGN (6410)
#define GEN7_CONTEXT_ALIGN 4096
-static void do_ppgtt_cleanup(struct i915_hw_ppgtt *ppgtt)
-{
- struct drm_device *dev = ppgtt-base.dev;
- struct drm_i915_private *dev_priv = dev-dev_private;
- struct i915_address_space *vm = ppgtt-base;
-
- if (ppgtt == dev_priv-mm.aliasing_ppgtt ||
- (list_empty(vm-active_list) list_empty(vm-inactive_list))) {
- ppgtt-base.cleanup(ppgtt-base);
- return;
- }
-
- /* vmas should already be unbound */
- WARN_ON(!list_empty(vm-active_list));
-
- ppgtt-base.cleanup(ppgtt-base);
-}
-
-void ppgtt_release(struct kref *kref)
-{
- struct i915_hw_ppgtt *ppgtt =
- container_of(kref, struct i915_hw_ppgtt, ref);
-
- do_ppgtt_cleanup(ppgtt);
- kfree(ppgtt);
-}
-
static size_t get_context_alignment(struct drm_device *dev)
{
if (IS_GEN6(dev))
@@ -172,7 +145,7 @@ void i915_gem_context_free(struct kref *ctx_ref)
}
if (ppgtt)
- kref_put(ppgtt-ref, ppgtt_release);
+ i915_ppgtt_put(ppgtt);
if (ctx-legacy_hw_ctx.rcs_state)
drm_gem_object_unreference(ctx-legacy_hw_ctx.rcs_state-base);
list_del(ctx-link);
@@ -219,7 +192,7 @@ create_vm_for_ctx(struct drm_device *dev, struct
intel_context *ctx)
if (!ppgtt)
return ERR_PTR(-ENOMEM);
- ret = i915_gem_init_ppgtt(dev, ppgtt);
+ ret = i915_ppgtt_init(dev, ppgtt);
if (ret) {
kfree(ppgtt);
return ERR_PTR(ret);
@@ -231,7 +204,7 @@ create_vm_for_ctx(struct drm_device *dev, struct
intel_context *ctx)
static struct intel_context *
__create_hw_context(struct drm_device *dev,
- struct drm_i915_file_private *file_priv)
+ struct drm_i915_file_private *file_priv)
{
struct drm_i915_private *dev_priv = dev-dev_private;
struct intel_context *ctx;
@@ -339,7 +312,7 @@ i915_gem_create_context(struct drm_device *dev,
/* For platforms which only have aliasing PPGTT, we fake the
* address space and refcounting. */
ctx-vm = dev_priv-mm.aliasing_ppgtt-base;
-
Re: [Intel-gfx] [PATCH 1/2] drm/i915/hdmi: call intel_hdmi_prepare for CHV
On Wed, Jul 30, 2014 at 10:43:48AM +0800, libin.y...@intel.com wrote: From: Libin Yang libin.y...@intel.com call the intel_hdmi_prepare() in chv_hdmi_pre_enable() for hdmi audio. Signed-off-by: Libin Yang libin.y...@intel.com I've just merged a similar patch from Ville, please check that it works. -Daniel --- drivers/gpu/drm/i915/intel_hdmi.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c index 5f8f4ca..5a65e0c 100644 --- a/drivers/gpu/drm/i915/intel_hdmi.c +++ b/drivers/gpu/drm/i915/intel_hdmi.c @@ -1374,6 +1374,7 @@ static void chv_hdmi_pre_enable(struct intel_encoder *encoder) int data, i; u32 val; + intel_hdmi_prepare(encoder); mutex_lock(dev_priv-dpio_lock); /* Deassert soft data lane reset*/ -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 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: HDMI pixel replication modes now hactive of 720 for pixel replication
On Tue, Jul 29, 2014 at 02:58:23PM -0700, clinton.a.tay...@intel.com wrote:
From: Clint Taylor clinton.a.tay...@intel.com
CEA SD interlaced modes use a horizontal 720 pixels that are pixel replicated
to 1440. The current driver reports 1440 pixel to the OS and does not set
pixel replicated modes.
Please wrap lines. Also the subject reads confusing to my non-native
speaker ears. Dunno what exactly you want to say in there.
Signed-off-by: Clint Taylor clinton.a.tay...@intel.com
Patches touching drm core must be submitted to dri-devel, too. Please
resend.
-Daniel
---
drivers/gpu/drm/drm_edid.c| 68
++---
drivers/gpu/drm/i915/intel_hdmi.c | 13 +++
2 files changed, 47 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index dfa9769..5233f4c 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -632,26 +632,26 @@ static const struct drm_display_mode edid_cea_modes[] =
{
DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
DRM_MODE_FLAG_INTERLACE),
.vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
- /* 6 - 1440x480i@60Hz */
- { DRM_MODE(1440x480i, DRM_MODE_TYPE_DRIVER, 27000, 1440, 1478,
+ /* 6 - 720(1440)x480i@60Hz */
+ { DRM_MODE(720x480i, DRM_MODE_TYPE_DRIVER, 27000, 720, 1478,
1602, 1716, 0, 480, 488, 494, 525, 0,
DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_DBLCLK),
.vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_4_3, },
- /* 7 - 1440x480i@60Hz */
- { DRM_MODE(1440x480i, DRM_MODE_TYPE_DRIVER, 27000, 1440, 1478,
+ /* 7 - 720(1440)x480i@60Hz */
+ { DRM_MODE(720x480i, DRM_MODE_TYPE_DRIVER, 27000, 720, 1478,
1602, 1716, 0, 480, 488, 494, 525, 0,
DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_DBLCLK),
.vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
- /* 8 - 1440x240@60Hz */
- { DRM_MODE(1440x240, DRM_MODE_TYPE_DRIVER, 27000, 1440, 1478,
+ /* 8 - 720(1440)x240@60Hz */
+ { DRM_MODE(720x240, DRM_MODE_TYPE_DRIVER, 27000, 720, 1478,
1602, 1716, 0, 240, 244, 247, 262, 0,
DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
DRM_MODE_FLAG_DBLCLK),
.vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_4_3, },
- /* 9 - 1440x240@60Hz */
- { DRM_MODE(1440x240, DRM_MODE_TYPE_DRIVER, 27000, 1440, 1478,
+ /* 9 - 720(1440)x240@60Hz */
+ { DRM_MODE(720x240, DRM_MODE_TYPE_DRIVER, 27000, 720, 1478,
1602, 1716, 0, 240, 244, 247, 262, 0,
DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
DRM_MODE_FLAG_DBLCLK),
@@ -714,26 +714,26 @@ static const struct drm_display_mode edid_cea_modes[] =
{
DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
DRM_MODE_FLAG_INTERLACE),
.vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
- /* 21 - 1440x576i@50Hz */
- { DRM_MODE(1440x576i, DRM_MODE_TYPE_DRIVER, 27000, 1440, 1464,
+ /* 21 - 720(1440)x576i@50Hz */
+ { DRM_MODE(720x576i, DRM_MODE_TYPE_DRIVER, 27000, 720, 1464,
1590, 1728, 0, 576, 580, 586, 625, 0,
DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_DBLCLK),
.vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_4_3, },
- /* 22 - 1440x576i@50Hz */
- { DRM_MODE(1440x576i, DRM_MODE_TYPE_DRIVER, 27000, 1440, 1464,
+ /* 22 - 720(1440)x576i@50Hz */
+ { DRM_MODE(720x576i, DRM_MODE_TYPE_DRIVER, 27000, 720, 1464,
1590, 1728, 0, 576, 580, 586, 625, 0,
DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_DBLCLK),
.vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
- /* 23 - 1440x288@50Hz */
- { DRM_MODE(1440x288, DRM_MODE_TYPE_DRIVER, 27000, 1440, 1464,
+ /* 23 - 720(1440)x288@50Hz */
+ { DRM_MODE(720x288, DRM_MODE_TYPE_DRIVER, 27000, 720, 1464,
1590, 1728, 0, 288, 290, 293, 312, 0,
DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
DRM_MODE_FLAG_DBLCLK),
.vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_4_3, },
- /* 24 - 1440x288@50Hz */
- { DRM_MODE(1440x288, DRM_MODE_TYPE_DRIVER, 27000, 1440, 1464,
+ /* 24 - 720(1440)x288@50Hz */
+ { DRM_MODE(720x288, DRM_MODE_TYPE_DRIVER, 27000, 720, 1464,
1590, 1728, 0, 288, 290, 293, 312, 0,
DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Some cleanups for the ppgtt lifetime handling
On Wed, Jul 30, 2014 at 12:44:05PM +0200, Daniel Vetter wrote: So when reviewing Michel's patch I've noticed a few things and cleaned them up: - The early checks in ppgtt_release are now redundant: The inactive list should always be empty now, so we can ditch these checks. Even for the aliasing ppgtt (though that's a different confusion) since we tear that down after all the objects are gone. - The ppgtt handling functions are splattered all over. Consolidate them in i915_gem_gtt.c, give them OCD prefixes and add wrappers for get/put. - There was a bit a confusion in ppgtt_release about whether it cares about the active or inactive list. It should care about them both, so augment the WARNINGs to check for both. There's still create_vm_for_ctx left to do, put that is blocked on the removal of ppgtt-ctx. Once that's done we can rename it to i915_ppgtt_create and move it to its siblings for handling ppgtts. Cc: Michel Thierry michel.thie...@intel.com Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch --- drivers/gpu/drm/i915/i915_drv.h | 1 - drivers/gpu/drm/i915/i915_gem.c | 2 +- drivers/gpu/drm/i915/i915_gem_context.c | 35 - drivers/gpu/drm/i915/i915_gem_gtt.c | 17 ++-- drivers/gpu/drm/i915/i915_gem_gtt.h | 12 ++- 5 files changed, 31 insertions(+), 36 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 5fe3b1dfc34c..a89eb87e4af6 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -2497,7 +2497,6 @@ void i915_gem_object_ggtt_unpin(struct drm_i915_gem_object *obj); #define ctx_to_ppgtt(ctx) container_of((ctx)-vm, struct i915_hw_ppgtt, base) #define vm_to_ppgtt(vm) container_of(vm, struct i915_hw_ppgtt, base) int __must_check i915_gem_context_init(struct drm_device *dev); -void ppgtt_release(struct kref *kref); void i915_gem_context_fini(struct drm_device *dev); void i915_gem_context_reset(struct drm_device *dev); int i915_gem_context_open(struct drm_device *dev, struct drm_file *file); diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index 25a32b9c9b4b..1a46be5d2979 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -4511,7 +4511,7 @@ void i915_gem_vma_destroy(struct i915_vma *vma) ppgtt = vm_to_ppgtt(vm); if (ppgtt) - kref_put(ppgtt-ref, ppgtt_release); + i915_ppgtt_put(ppgtt); Move the if(ppgtt) into i915_ppgtt_put(). And trust in the gcc DCE. For get, do if (ppgtt)...; return ppgtt. And trust gcc. Doing that can make callers much neater. -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
[Intel-gfx] [PATCH] drm/i915: Some cleanups for the ppgtt lifetime handling
So when reviewing Michel's patch I've noticed a few things and cleaned
them up:
- The early checks in ppgtt_release are now redundant: The inactive
list should always be empty now, so we can ditch these checks. Even
for the aliasing ppgtt (though that's a different confusion) since
we tear that down after all the objects are gone.
- The ppgtt handling functions are splattered all over. Consolidate
them in i915_gem_gtt.c, give them OCD prefixes and add wrappers for
get/put.
- There was a bit a confusion in ppgtt_release about whether it cares
about the active or inactive list. It should care about them both,
so augment the WARNINGs to check for both.
There's still create_vm_for_ctx left to do, put that is blocked on the
removal of ppgtt-ctx. Once that's done we can rename it to
i915_ppgtt_create and move it to its siblings for handling ppgtts.
v2: Move the ppgtt checks into the inline get/put functions as
suggested by Chris.
Cc: Michel Thierry michel.thie...@intel.com
Cc: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_drv.h | 1 -
drivers/gpu/drm/i915/i915_gem.c | 3 +--
drivers/gpu/drm/i915/i915_gem_context.c | 36 -
drivers/gpu/drm/i915/i915_gem_gtt.c | 18 ++---
drivers/gpu/drm/i915/i915_gem_gtt.h | 14 -
5 files changed, 33 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 5fe3b1dfc34c..a89eb87e4af6 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2497,7 +2497,6 @@ void i915_gem_object_ggtt_unpin(struct
drm_i915_gem_object *obj);
#define ctx_to_ppgtt(ctx) container_of((ctx)-vm, struct i915_hw_ppgtt, base)
#define vm_to_ppgtt(vm) container_of(vm, struct i915_hw_ppgtt, base)
int __must_check i915_gem_context_init(struct drm_device *dev);
-void ppgtt_release(struct kref *kref);
void i915_gem_context_fini(struct drm_device *dev);
void i915_gem_context_reset(struct drm_device *dev);
int i915_gem_context_open(struct drm_device *dev, struct drm_file *file);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 25a32b9c9b4b..38328429b567 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4510,8 +4510,7 @@ void i915_gem_vma_destroy(struct i915_vma *vma)
vm = vma-vm;
ppgtt = vm_to_ppgtt(vm);
- if (ppgtt)
- kref_put(ppgtt-ref, ppgtt_release);
+ i915_ppgtt_put(ppgtt);
list_del(vma-vma_link);
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index ae706cba05ae..899c6a7a5920 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -96,33 +96,6 @@
#define GEN6_CONTEXT_ALIGN (6410)
#define GEN7_CONTEXT_ALIGN 4096
-static void do_ppgtt_cleanup(struct i915_hw_ppgtt *ppgtt)
-{
- struct drm_device *dev = ppgtt-base.dev;
- struct drm_i915_private *dev_priv = dev-dev_private;
- struct i915_address_space *vm = ppgtt-base;
-
- if (ppgtt == dev_priv-mm.aliasing_ppgtt ||
- (list_empty(vm-active_list) list_empty(vm-inactive_list))) {
- ppgtt-base.cleanup(ppgtt-base);
- return;
- }
-
- /* vmas should already be unbound */
- WARN_ON(!list_empty(vm-active_list));
-
- ppgtt-base.cleanup(ppgtt-base);
-}
-
-void ppgtt_release(struct kref *kref)
-{
- struct i915_hw_ppgtt *ppgtt =
- container_of(kref, struct i915_hw_ppgtt, ref);
-
- do_ppgtt_cleanup(ppgtt);
- kfree(ppgtt);
-}
-
static size_t get_context_alignment(struct drm_device *dev)
{
if (IS_GEN6(dev))
@@ -171,8 +144,7 @@ void i915_gem_context_free(struct kref *ctx_ref)
ppgtt = ctx_to_ppgtt(ctx);
}
- if (ppgtt)
- kref_put(ppgtt-ref, ppgtt_release);
+ i915_ppgtt_put(ppgtt);
if (ctx-legacy_hw_ctx.rcs_state)
drm_gem_object_unreference(ctx-legacy_hw_ctx.rcs_state-base);
list_del(ctx-link);
@@ -219,7 +191,7 @@ create_vm_for_ctx(struct drm_device *dev, struct
intel_context *ctx)
if (!ppgtt)
return ERR_PTR(-ENOMEM);
- ret = i915_gem_init_ppgtt(dev, ppgtt);
+ ret = i915_ppgtt_init(dev, ppgtt);
if (ret) {
kfree(ppgtt);
return ERR_PTR(ret);
@@ -231,7 +203,7 @@ create_vm_for_ctx(struct drm_device *dev, struct
intel_context *ctx)
static struct intel_context *
__create_hw_context(struct drm_device *dev,
- struct drm_i915_file_private *file_priv)
+ struct drm_i915_file_private *file_priv)
{
struct drm_i915_private *dev_priv = dev-dev_private;
struct intel_context *ctx;
@@ -339,7 +311,7 @@ i915_gem_create_context(struct drm_device *dev,
/*
Re: [Intel-gfx] [PATCH 16/40] drm/i915: Add chv_power_wells[]
On Fri, Jul 11, 2014 at 02:09:40PM +, Barbalho, Rafael wrote:
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
Of ville.syrj...@linux.intel.com
Sent: Saturday, June 28, 2014 12:04 AM
To: intel-gfx@lists.freedesktop.org
Subject: [Intel-gfx] [PATCH 16/40] drm/i915: Add chv_power_wells[]
From: Ville Syrjälä ville.syrj...@linux.intel.com
Add chv_power_wells[] so we can start to build up the power well support
for chv. Just the always on well there initialy.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_pm.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_pm.c
b/drivers/gpu/drm/i915/intel_pm.c
index 898654f..e2b956e 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -6498,6 +6498,15 @@ static struct i915_power_well vlv_power_wells[] =
{
},
};
+static struct i915_power_well chv_power_wells[] = {
+ {
+ .name = always-on,
+ .always_on = 1,
+ .domains = VLV_ALWAYS_ON_POWER_DOMAINS,
+ .ops = i9xx_always_on_power_well_ops,
+ },
+};
+
static struct i915_power_well *lookup_power_well(struct drm_i915_private
*dev_priv,
enum punit_power_well
power_well_id)
{
@@ -6534,6 +6543,8 @@ int intel_power_domains_init(struct
drm_i915_private *dev_priv)
} else if (IS_BROADWELL(dev_priv-dev)) {
set_power_wells(power_domains, bdw_power_wells);
hsw_pwr = power_domains;
+ } else if (IS_CHERRYVIEW(dev_priv-dev)) {
+ set_power_wells(power_domains, chv_power_wells);
} else if (IS_VALLEYVIEW(dev_priv-dev)) {
set_power_wells(power_domains, vlv_power_wells);
} else {
--
1.8.5.5
Tested-by: Rafael Barbalho rafael.barba...@intel.com
Ok, pulled this one in too to undo my giant merge fumble. My apologies to
everyone for the mess.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Remove context pointer from ppgtt struct
After new vma/ppgtt lifetime rules, the ppgtt can outlive the context
it was created for.
- Renamed create_vm_for_ctx to i915_ppgtt_create as ctx/ppgtt are no
longer referenced.
- Updated per_file_stats to cope with this change.
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Signed-off-by: Michel Thierry michel.thie...@intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 6 +++---
drivers/gpu/drm/i915/i915_gem_context.c | 5 ++---
drivers/gpu/drm/i915/i915_gem_gtt.h | 2 --
3 files changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 96612a5..35c0f09 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -322,7 +322,7 @@ static int per_file_stats(int id, void *ptr, void *data)
if (USES_FULL_PPGTT(obj-base.dev)) {
list_for_each_entry(vma, obj-vma_list, vma_link) {
- struct i915_hw_ppgtt *ppgtt;
+ struct intel_context *ctx;
if (!drm_mm_node_allocated(vma-node))
continue;
@@ -332,8 +332,8 @@ static int per_file_stats(int id, void *ptr, void *data)
continue;
}
- ppgtt = container_of(vma-vm, struct i915_hw_ppgtt,
base);
- if (ppgtt-ctx ppgtt-ctx-file_priv !=
stats-file_priv)
+ ctx = container_of(vma-vm, struct intel_context, vm);
+ if (ctx ctx-file_priv != stats-file_priv)
continue;
if (obj-ring) /* XXX per-vma statistic */
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 3e7cb50..43da325 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -210,7 +210,7 @@ i915_gem_alloc_context_obj(struct drm_device *dev, size_t
size)
}
static struct i915_hw_ppgtt *
-create_vm_for_ctx(struct drm_device *dev, struct intel_context *ctx)
+i915_ppgtt_create(struct drm_device *dev)
{
struct i915_hw_ppgtt *ppgtt;
int ret;
@@ -225,7 +225,6 @@ create_vm_for_ctx(struct drm_device *dev, struct
intel_context *ctx)
return ERR_PTR(ret);
}
- ppgtt-ctx = ctx;
return ppgtt;
}
@@ -315,7 +314,7 @@ i915_gem_create_context(struct drm_device *dev,
}
if (create_vm) {
- struct i915_hw_ppgtt *ppgtt = create_vm_for_ctx(dev, ctx);
+ struct i915_hw_ppgtt *ppgtt = i915_ppgtt_create(dev);
if (IS_ERR_OR_NULL(ppgtt)) {
DRM_DEBUG_DRIVER(PPGTT setup failed (%ld)\n,
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index 8d6f7c1..dd70b0f 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -258,8 +258,6 @@ struct i915_hw_ppgtt {
dma_addr_t *gen8_pt_dma_addr[4];
};
- struct intel_context *ctx;
-
int (*enable)(struct i915_hw_ppgtt *ppgtt);
int (*switch_mm)(struct i915_hw_ppgtt *ppgtt,
struct intel_engine_cs *ring,
--
2.0.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Remove context pointer from ppgtt struct
On Wed, Jul 30, 2014 at 12:25:20PM +0100, Michel Thierry wrote:
After new vma/ppgtt lifetime rules, the ppgtt can outlive the context
it was created for.
- Renamed create_vm_for_ctx to i915_ppgtt_create as ctx/ppgtt are no
longer referenced.
- Updated per_file_stats to cope with this change.
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Signed-off-by: Michel Thierry michel.thie...@intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 6 +++---
drivers/gpu/drm/i915/i915_gem_context.c | 5 ++---
drivers/gpu/drm/i915/i915_gem_gtt.h | 2 --
3 files changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 96612a5..35c0f09 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -322,7 +322,7 @@ static int per_file_stats(int id, void *ptr, void *data)
if (USES_FULL_PPGTT(obj-base.dev)) {
list_for_each_entry(vma, obj-vma_list, vma_link) {
- struct i915_hw_ppgtt *ppgtt;
+ struct intel_context *ctx;
if (!drm_mm_node_allocated(vma-node))
continue;
@@ -332,8 +332,8 @@ static int per_file_stats(int id, void *ptr, void *data)
continue;
}
- ppgtt = container_of(vma-vm, struct i915_hw_ppgtt,
base);
- if (ppgtt-ctx ppgtt-ctx-file_priv !=
stats-file_priv)
+ ctx = container_of(vma-vm, struct intel_context, vm);
That doesn't really work.
-Daniel
+ if (ctx ctx-file_priv != stats-file_priv)
continue;
if (obj-ring) /* XXX per-vma statistic */
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 3e7cb50..43da325 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -210,7 +210,7 @@ i915_gem_alloc_context_obj(struct drm_device *dev, size_t
size)
}
static struct i915_hw_ppgtt *
-create_vm_for_ctx(struct drm_device *dev, struct intel_context *ctx)
+i915_ppgtt_create(struct drm_device *dev)
{
struct i915_hw_ppgtt *ppgtt;
int ret;
@@ -225,7 +225,6 @@ create_vm_for_ctx(struct drm_device *dev, struct
intel_context *ctx)
return ERR_PTR(ret);
}
- ppgtt-ctx = ctx;
return ppgtt;
}
@@ -315,7 +314,7 @@ i915_gem_create_context(struct drm_device *dev,
}
if (create_vm) {
- struct i915_hw_ppgtt *ppgtt = create_vm_for_ctx(dev, ctx);
+ struct i915_hw_ppgtt *ppgtt = i915_ppgtt_create(dev);
if (IS_ERR_OR_NULL(ppgtt)) {
DRM_DEBUG_DRIVER(PPGTT setup failed (%ld)\n,
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index 8d6f7c1..dd70b0f 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -258,8 +258,6 @@ struct i915_hw_ppgtt {
dma_addr_t *gen8_pt_dma_addr[4];
};
- struct intel_context *ctx;
-
int (*enable)(struct i915_hw_ppgtt *ppgtt);
int (*switch_mm)(struct i915_hw_ppgtt *ppgtt,
struct intel_engine_cs *ring,
--
2.0.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 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 32/40] drm/i915: Hack to tie both common lanes together on chv
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
Of ville.syrj...@linux.intel.com
Sent: Saturday, June 28, 2014 12:04 AM
To: intel-gfx@lists.freedesktop.org
Subject: [Intel-gfx] [PATCH 32/40] drm/i915: Hack to tie both common lanes
together on chv
From: Ville Syrjälä ville.syrj...@linux.intel.com
It looks like frobbing the cmnreset line on pne PHY disturbs the other
PHY on chv. The result is a black screen. On HDMI it's just a flash of
black, but DP usually falls over and can't get back up.
As a workaround set up the power domains so that both common lane
wells power up and down together. I also tried leaving the cmnreset
deasserted even the if the power well goes down but that didn't seem
acceptable to the PHY.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
I think we need to talk to the SoC people to figure out why we need to this.
But otherwise
it's for me.
Reviewed-by: Rafael Barbalho rafael.barba...@intel.com
---
drivers/gpu/drm/i915/intel_pm.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c
b/drivers/gpu/drm/i915/intel_pm.c
index 158c3f5..879d14c 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -6776,13 +6776,23 @@ static struct i915_power_well chv_power_wells[]
= {
#endif
{
.name = dpio-common-bc,
- .domains = CHV_DPIO_CMN_BC_POWER_DOMAINS,
+ /*
+ * XXX: cmnreset for one PHY seems to disturb the other.
+ * As a workaround keep both powered on at the same
+ * time for now.
+ */
+ .domains = CHV_DPIO_CMN_BC_POWER_DOMAINS |
CHV_DPIO_CMN_D_POWER_DOMAINS,
.data = PUNIT_POWER_WELL_DPIO_CMN_BC,
.ops = chv_dpio_cmn_power_well_ops,
},
{
.name = dpio-common-d,
- .domains = CHV_DPIO_CMN_D_POWER_DOMAINS,
+ /*
+ * XXX: cmnreset for one PHY seems to disturb the other.
+ * As a workaround keep both powered on at the same
+ * time for now.
+ */
+ .domains = CHV_DPIO_CMN_BC_POWER_DOMAINS |
CHV_DPIO_CMN_D_POWER_DOMAINS,
.data = PUNIT_POWER_WELL_DPIO_CMN_D,
.ops = chv_dpio_cmn_power_well_ops,
},
--
1.8.5.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 33/40] drm/i915: Polish the chv cmnlane resrt macros
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
Of ville.syrj...@linux.intel.com
Sent: Saturday, June 28, 2014 12:04 AM
To: intel-gfx@lists.freedesktop.org
Subject: [Intel-gfx] [PATCH 33/40] drm/i915: Polish the chv cmnlane resrt
macros
From: Ville Syrjälä ville.syrj...@linux.intel.com
Replace the semi-funky cmnlane assert/deassert macros with something a
bit more conventional. Also protect the macro arguments properly (also
for PHY_POWERGOOD()).
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 7 ++-
drivers/gpu/drm/i915/intel_pm.c | 8
2 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h
b/drivers/gpu/drm/i915/i915_reg.h
index 60dd19c..85b59c4 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1717,12 +1717,9 @@ enum punit_power_well {
#define DPIO_PHY_STATUS (VLV_DISPLAY_BASE +
0x6240)
#define DPLL_PORTD_READY_MASK (0xf)
#define DISPLAY_PHY_CONTROL (VLV_DISPLAY_BASE + 0x60100)
-#define PHY_COM_LANE_RESET_DEASSERT(phy, val) \
- ((phy == DPIO_PHY0) ? (val | 1) : (val | 2))
-#define PHY_COM_LANE_RESET_ASSERT(phy, val) \
- ((phy == DPIO_PHY0) ? (val ~1) : (val ~2))
+#define PHY_COM_LANE_RESET_DEASSERT(phy) (1 (phy))
#define DISPLAY_PHY_STATUS (VLV_DISPLAY_BASE + 0x60104)
-#define PHY_POWERGOOD(phy) ((phy == DPIO_PHY0) ? (131) :
(130))
+#define PHY_POWERGOOD(phy) (((phy) == DPIO_PHY0) ? (131) :
(130))
/*
* The i830 generation, in LVDS mode, defines P1 as the bit number set
within
diff --git a/drivers/gpu/drm/i915/intel_pm.c
b/drivers/gpu/drm/i915/intel_pm.c
index 879d14c..f193d95 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -6280,8 +6280,8 @@ static void
chv_dpio_cmn_power_well_enable(struct drm_i915_private *dev_priv,
if (wait_for(I915_READ(DISPLAY_PHY_STATUS)
PHY_POWERGOOD(phy), 1))
DRM_ERROR(Display PHY %d is not power up\n, phy);
- I915_WRITE(DISPLAY_PHY_CONTROL,
-PHY_COM_LANE_RESET_DEASSERT(phy,
I915_READ(DISPLAY_PHY_CONTROL)));
+ I915_WRITE(DISPLAY_PHY_CONTROL,
I915_READ(DISPLAY_PHY_CONTROL) |
+PHY_COM_LANE_RESET_DEASSERT(phy));
}
static void chv_dpio_cmn_power_well_disable(struct drm_i915_private
*dev_priv,
@@ -6301,8 +6301,8 @@ static void
chv_dpio_cmn_power_well_disable(struct drm_i915_private *dev_priv,
assert_pll_disabled(dev_priv, PIPE_C);
}
- I915_WRITE(DISPLAY_PHY_CONTROL,
-PHY_COM_LANE_RESET_ASSERT(phy,
I915_READ(DISPLAY_PHY_CONTROL)));
+ I915_WRITE(DISPLAY_PHY_CONTROL,
I915_READ(DISPLAY_PHY_CONTROL)
+~PHY_COM_LANE_RESET_DEASSERT(phy));
vlv_set_power_well(dev_priv, power_well, false);
}
--
1.8.5.5
Reviewed-by: Rafael Barbalho rafael.barba...@intel.com
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
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: Add support for Video Burst Mode for MIPI DSI
On Sat, 2014-07-12 at 17:17 +0530, Shobhit Kumar wrote:
Signed-off-by: Shobhit Kumar shobhit.ku...@intel.com
---
drivers/gpu/drm/i915/intel_bios.h | 3 ++-
drivers/gpu/drm/i915/intel_dsi.c | 22 ++---
drivers/gpu/drm/i915/intel_dsi.h | 2 ++
drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 38
--
drivers/gpu/drm/i915/intel_dsi_pll.c | 9 +++
5 files changed, 57 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_bios.h
b/drivers/gpu/drm/i915/intel_bios.h
index b986677..905999b 100644
--- a/drivers/gpu/drm/i915/intel_bios.h
+++ b/drivers/gpu/drm/i915/intel_bios.h
@@ -802,7 +802,8 @@ struct mipi_config {
u16 rsvd4;
- u8 rsvd5[5];
+ u8 rsvd5;
+ u32 target_burst_mode_freq;
u32 dsi_ddr_clk;
u32 bridge_ref_clk;
diff --git a/drivers/gpu/drm/i915/intel_dsi.c
b/drivers/gpu/drm/i915/intel_dsi.c
index 98c78ab..732d96b 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -449,9 +449,11 @@ static u16 txclkesc(u32 divider, unsigned int us)
}
/* return pixels in terms of txbyteclkhs */
-static u16 txbyteclkhs(u16 pixels, int bpp, int lane_count)
+static u16 txbyteclkhs(u16 pixels, int bpp, int lane_count,
+u16 burst_mode_ratio)
{
- return DIV_ROUND_UP(DIV_ROUND_UP(pixels * bpp, 8), lane_count);
+ return DIV_ROUND_UP(DIV_ROUND_UP(pixels * bpp * burst_mode_ratio,
+ 8 * 100), lane_count);
}
static void set_dsi_timings(struct drm_encoder *encoder,
@@ -477,10 +479,12 @@ static void set_dsi_timings(struct drm_encoder *encoder,
vbp = mode-vtotal - mode-vsync_end;
/* horizontal values are in terms of high speed byte clock */
- hactive = txbyteclkhs(hactive, bpp, lane_count);
- hfp = txbyteclkhs(hfp, bpp, lane_count);
- hsync = txbyteclkhs(hsync, bpp, lane_count);
- hbp = txbyteclkhs(hbp, bpp, lane_count);
+ hactive = txbyteclkhs(hactive, bpp, lane_count,
+ intel_dsi-burst_mode_ratio);
+ hfp = txbyteclkhs(hfp, bpp, lane_count, intel_dsi-burst_mode_ratio);
+ hsync = txbyteclkhs(hsync, bpp, lane_count,
+ intel_dsi-burst_mode_ratio);
+ hbp = txbyteclkhs(hbp, bpp, lane_count, intel_dsi-burst_mode_ratio);
I915_WRITE(MIPI_HACTIVE_AREA_COUNT(pipe), hactive);
I915_WRITE(MIPI_HFP_COUNT(pipe), hfp);
@@ -567,12 +571,14 @@ static void intel_dsi_prepare(struct intel_encoder
*intel_encoder)
intel_dsi-video_mode_format == VIDEO_MODE_BURST) {
I915_WRITE(MIPI_HS_TX_TIMEOUT(pipe),
txbyteclkhs(adjusted_mode-htotal, bpp,
-intel_dsi-lane_count) + 1);
+intel_dsi-lane_count,
+intel_dsi-burst_mode_ratio) + 1);
} else {
I915_WRITE(MIPI_HS_TX_TIMEOUT(pipe),
txbyteclkhs(adjusted_mode-vtotal *
adjusted_mode-htotal,
-bpp, intel_dsi-lane_count) + 1);
+bpp, intel_dsi-lane_count,
+intel_dsi-burst_mode_ratio) + 1);
}
I915_WRITE(MIPI_LP_RX_TIMEOUT(pipe), intel_dsi-lp_rx_timeout);
I915_WRITE(MIPI_TURN_AROUND_TIMEOUT(pipe), intel_dsi-turn_arnd_val);
diff --git a/drivers/gpu/drm/i915/intel_dsi.h
b/drivers/gpu/drm/i915/intel_dsi.h
index e0c16b0..a34ffa4 100644
--- a/drivers/gpu/drm/i915/intel_dsi.h
+++ b/drivers/gpu/drm/i915/intel_dsi.h
@@ -116,6 +116,8 @@ struct intel_dsi {
u16 clk_hs_to_lp_count;
u16 init_count;
+ u32 pclk;
+ u16 burst_mode_ratio;
/* all delays in ms */
u16 backlight_off_delay;
diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
index 47c7584..1f5abb4 100644
--- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
@@ -271,6 +271,8 @@ static bool generic_init(struct intel_dsi_device *dsi)
u32 ths_prepare_ns, tclk_trail_ns;
u32 tclk_prepare_clkzero, ths_prepare_hszero;
u32 lp_to_hs_switch, hs_to_lp_switch;
+ u32 pclk, computed_ddr;
+ u16 burst_mode_ratio;
DRM_DEBUG_KMS(\n);
@@ -284,8 +286,6 @@ static bool generic_init(struct intel_dsi_device *dsi)
else if (intel_dsi-pixel_format == VID_MODE_FORMAT_RGB565)
bits_per_pixel = 16;
- bitrate = (mode-clock * bits_per_pixel) / intel_dsi-lane_count;
-
intel_dsi-operation_mode = mipi_config-is_cmd_mode;
intel_dsi-video_mode_format = mipi_config-video_transfer_mode;
intel_dsi-escape_clk_div = mipi_config-byte_clk_sel;
@@ -297,6
Re: [Intel-gfx] [RFC v2 2/3] drm/i915: duplicate i915_gem_ring_dispatch trace and add ctx parameter
I would also like a better ctx identifier than its pointer. Using the pointer for tracking objects makes it more difficult to read traces (although it is easy for scripts). I use the VM pointer to track the ppgtt; that pointer is also printed by several other traces, including the ppgtt init/release ones that I've submitted for comments in this series. However, I don't mind changing the way we identify the ctx as long as I still have access to the VM pointer. I'll have a look at the possible ways of identifying the ctx and I'll try to find a better solution than the current one. I've looked for other ways to identify the ctx, but I could't find anything more readable than a pointer. The best alternative in my opinion is to use the user_handle, but that is dependent on the file_priv so it is not enough on its own. Coupling the user_handle with the file_priv pointer doesn't seem like a good idea, so I still think that using the ctx pointer or the vm pointer is the best way to identify the ctx at the moment. Did you have something in mind that I've missed? Thanks, Daniele ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 31/40] drm/i916: Init chv workarounds at render ring init
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
Of ville.syrj...@linux.intel.com
Sent: Saturday, June 28, 2014 12:04 AM
To: intel-gfx@lists.freedesktop.org
Subject: [Intel-gfx] [PATCH 31/40] drm/i916: Init chv workarounds at render
ring init
From: Ville Syrjälä ville.syrj...@linux.intel.com
My bsw is an unhappy camper if we delay the workaround init until
init_clock_gating(). Move a bunch of it to the render ring init.
FIXME: need to do this for all platforms since some of the registers
also get clobbered at reset. Just need to figure out which
registers those actually are. This patch is based on a
slightly educated guess, but verifying on actual hw would
be a good idea. Also should maybe move the init_clock_gating
earlier too since we set up a bunch of clock gating stuff
there that might be important for a properly working GT.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_pm.c | 40
+++--
drivers/gpu/drm/i915/intel_ringbuffer.c | 40
+
2 files changed, 48 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c
b/drivers/gpu/drm/i915/intel_pm.c
index 346dced..158c3f5 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5720,6 +5720,10 @@ static void valleyview_init_clock_gating(struct
drm_device *dev)
* in the reporting of vblank events.
*/
I915_WRITE(VLV_GUNIT_CLOCK_GATE, GCFG_DIS);
+
+ /* WaDisableDopClockGating:chv (pre-production hw) */
+ I915_WRITE(GEN6_UCGCTL1, I915_READ(GEN6_UCGCTL1) |
+GEN6_EU_TCUNIT_CLOCK_GATE_DISABLE);
}
Did you really mean to add a cherryview workaround to valleyview?
static void cherryview_init_clock_gating(struct drm_device *dev)
@@ -5730,49 +5734,21 @@ static void cherryview_init_clock_gating(struct
drm_device *dev)
I915_WRITE(MI_ARB_VLV,
MI_ARB_DISPLAY_TRICKLE_FEED_DISABLE);
- /* WaDisablePartialInstShootdown:chv */
- I915_WRITE(GEN8_ROW_CHICKEN,
-
_MASKED_BIT_ENABLE(PARTIAL_INSTRUCTION_SHOOTDOWN_DISABLE));
-
- /* WaDisableThreadStallDopClockGating:chv */
- I915_WRITE(GEN8_ROW_CHICKEN,
-_MASKED_BIT_ENABLE(STALL_DOP_GATING_DISABLE));
-
- /* WaVSRefCountFullforceMissDisable:chv */
- /* WaDSRefCountFullforceMissDisable:chv */
- I915_WRITE(GEN7_FF_THREAD_MODE,
-I915_READ(GEN7_FF_THREAD_MODE)
-~(GEN8_FF_DS_REF_CNT_FFME |
GEN7_FF_VS_REF_CNT_FFME));
-
- /* WaDisableSemaphoreAndSyncFlipWait:chv */
- I915_WRITE(GEN6_RC_SLEEP_PSMI_CONTROL,
-
_MASKED_BIT_ENABLE(GEN8_RC_SEMA_IDLE_MSG_DISABLE));
-
/* WaDisableCSUnitClockGating:chv */
I915_WRITE(GEN6_UCGCTL1, I915_READ(GEN6_UCGCTL1) |
GEN6_CSUNIT_CLOCK_GATE_DISABLE);
+ /* WaDisableDopClockGating:chv (pre-production hw) */
Shouldn't this be WaDisableTCUnitClock gating?
+ I915_WRITE(GEN6_UCGCTL1, I915_READ(GEN6_UCGCTL1) |
+GEN6_EU_TCUNIT_CLOCK_GATE_DISABLE);
+
/* WaDisableSDEUnitClockGating:chv */
I915_WRITE(GEN8_UCGCTL6, I915_READ(GEN8_UCGCTL6) |
GEN8_SDEUNIT_CLOCK_GATE_DISABLE);
- /* WaDisableSamplerPowerBypass:chv (pre-production hw) */
- I915_WRITE(HALF_SLICE_CHICKEN3,
-
_MASKED_BIT_ENABLE(GEN8_SAMPLER_POWER_BYPASS_DIS));
-
/* WaDisableGunitClockGating:chv (pre-production hw) */
I915_WRITE(VLV_GUNIT_CLOCK_GATE,
I915_READ(VLV_GUNIT_CLOCK_GATE) |
GINT_DIS);
-
- /* WaDisableFfDopClockGating:chv (pre-production hw) */
- I915_WRITE(GEN6_RC_SLEEP_PSMI_CONTROL,
-
_MASKED_BIT_ENABLE(GEN8_FF_DOP_CLOCK_GATE_DISABLE));
-
- /* WaDisableDopClockGating:chv (pre-production hw) */
- I915_WRITE(GEN7_ROW_CHICKEN2,
-_MASKED_BIT_ENABLE(DOP_CLOCK_GATING_DISABLE));
- I915_WRITE(GEN6_UCGCTL1, I915_READ(GEN6_UCGCTL1) |
-GEN6_EU_TCUNIT_CLOCK_GATE_DISABLE);
}
static void g4x_init_clock_gating(struct drm_device *dev)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index ceb1295..9e81c28 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -615,6 +615,43 @@ err:
return ret;
}
I think we can share the cherryview_init_workarounds functions with broadwell
and just call it gen8_init_workarounds with a bit of code to just enable the
cheryview functions. I'll mark down the workarounds that are shared and the ones
that are not. It will also simplify the bdw clock gating init functions.
+static void cherryview_init_workarounds(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+
+ /* WaDisablePartialInstShootdown:chv */
Applies
Re: [Intel-gfx] [PATCH 31/40] drm/i916: Init chv workarounds at render ring init
On Wed, Jul 30, 2014 at 12:35:49PM +, Barbalho, Rafael wrote: -Original Message- From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of ville.syrj...@linux.intel.com Sent: Saturday, June 28, 2014 12:04 AM To: intel-gfx@lists.freedesktop.org Subject: [Intel-gfx] [PATCH 31/40] drm/i916: Init chv workarounds at render ring init From: Ville Syrjälä ville.syrj...@linux.intel.com My bsw is an unhappy camper if we delay the workaround init until init_clock_gating(). Move a bunch of it to the render ring init. FIXME: need to do this for all platforms since some of the registers also get clobbered at reset. Just need to figure out which registers those actually are. This patch is based on a slightly educated guess, but verifying on actual hw would be a good idea. Also should maybe move the init_clock_gating earlier too since we set up a bunch of clock gating stuff there that might be important for a properly working GT. Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com --- drivers/gpu/drm/i915/intel_pm.c | 40 +++-- drivers/gpu/drm/i915/intel_ringbuffer.c | 40 + 2 files changed, 48 insertions(+), 32 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 346dced..158c3f5 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -5720,6 +5720,10 @@ static void valleyview_init_clock_gating(struct drm_device *dev) * in the reporting of vblank events. */ I915_WRITE(VLV_GUNIT_CLOCK_GATE, GCFG_DIS); + + /* WaDisableDopClockGating:chv (pre-production hw) */ + I915_WRITE(GEN6_UCGCTL1, I915_READ(GEN6_UCGCTL1) | + GEN6_EU_TCUNIT_CLOCK_GATE_DISABLE); } Did you really mean to add a cherryview workaround to valleyview? Nope. Not sure what happened with this patch. Maybe it's best to wait and see what Arun comes up for BDW and once that's sorted we deal with CHV (and all the other platforms). static void cherryview_init_clock_gating(struct drm_device *dev) @@ -5730,49 +5734,21 @@ static void cherryview_init_clock_gating(struct drm_device *dev) I915_WRITE(MI_ARB_VLV, MI_ARB_DISPLAY_TRICKLE_FEED_DISABLE); - /* WaDisablePartialInstShootdown:chv */ - I915_WRITE(GEN8_ROW_CHICKEN, - _MASKED_BIT_ENABLE(PARTIAL_INSTRUCTION_SHOOTDOWN_DISABLE)); - - /* WaDisableThreadStallDopClockGating:chv */ - I915_WRITE(GEN8_ROW_CHICKEN, - _MASKED_BIT_ENABLE(STALL_DOP_GATING_DISABLE)); - - /* WaVSRefCountFullforceMissDisable:chv */ - /* WaDSRefCountFullforceMissDisable:chv */ - I915_WRITE(GEN7_FF_THREAD_MODE, - I915_READ(GEN7_FF_THREAD_MODE) - ~(GEN8_FF_DS_REF_CNT_FFME | GEN7_FF_VS_REF_CNT_FFME)); - - /* WaDisableSemaphoreAndSyncFlipWait:chv */ - I915_WRITE(GEN6_RC_SLEEP_PSMI_CONTROL, - _MASKED_BIT_ENABLE(GEN8_RC_SEMA_IDLE_MSG_DISABLE)); - /* WaDisableCSUnitClockGating:chv */ I915_WRITE(GEN6_UCGCTL1, I915_READ(GEN6_UCGCTL1) | GEN6_CSUNIT_CLOCK_GATE_DISABLE); + /* WaDisableDopClockGating:chv (pre-production hw) */ Shouldn't this be WaDisableTCUnitClock gating? + I915_WRITE(GEN6_UCGCTL1, I915_READ(GEN6_UCGCTL1) | + GEN6_EU_TCUNIT_CLOCK_GATE_DISABLE); + /* WaDisableSDEUnitClockGating:chv */ I915_WRITE(GEN8_UCGCTL6, I915_READ(GEN8_UCGCTL6) | GEN8_SDEUNIT_CLOCK_GATE_DISABLE); - /* WaDisableSamplerPowerBypass:chv (pre-production hw) */ - I915_WRITE(HALF_SLICE_CHICKEN3, - _MASKED_BIT_ENABLE(GEN8_SAMPLER_POWER_BYPASS_DIS)); - /* WaDisableGunitClockGating:chv (pre-production hw) */ I915_WRITE(VLV_GUNIT_CLOCK_GATE, I915_READ(VLV_GUNIT_CLOCK_GATE) | GINT_DIS); - - /* WaDisableFfDopClockGating:chv (pre-production hw) */ - I915_WRITE(GEN6_RC_SLEEP_PSMI_CONTROL, - _MASKED_BIT_ENABLE(GEN8_FF_DOP_CLOCK_GATE_DISABLE)); - - /* WaDisableDopClockGating:chv (pre-production hw) */ - I915_WRITE(GEN7_ROW_CHICKEN2, - _MASKED_BIT_ENABLE(DOP_CLOCK_GATING_DISABLE)); - I915_WRITE(GEN6_UCGCTL1, I915_READ(GEN6_UCGCTL1) | - GEN6_EU_TCUNIT_CLOCK_GATE_DISABLE); } static void g4x_init_clock_gating(struct drm_device *dev) diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c index ceb1295..9e81c28 100644 --- a/drivers/gpu/drm/i915/intel_ringbuffer.c +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c @@ -615,6 +615,43 @@ err: return ret; } I think we can share the cherryview_init_workarounds functions with broadwell and just call it gen8_init_workarounds with a bit of code to just enable the cheryview functions. I'll mark down the workarounds
[Intel-gfx] [PATCH v2 2/2] drm/i915: fix VDD state tracking after system resume
Just like during booting the BIOS can leave the VDD bit enabled after
system resume. So apply the same state sanitization there too. This
fixes a problem where after resume the port power domain refcount gets
unbalanced.
Reported-and-tested-by: Jarkko Nikula jarkko.nik...@linux.intel.com
Signed-off-by: Imre Deak imre.d...@intel.com
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_display.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 1edfd1a..fdb5657 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12977,6 +12977,12 @@ void intel_modeset_setup_hw_state(struct drm_device
*dev,
/* HW state is read out, now we need to sanitize this mess. */
list_for_each_entry(encoder, dev-mode_config.encoder_list,
base.head) {
+ /*
+* Do the following only during resume, since at driver
+* loading it's done early when initializing the encoder.
+*/
+ if (force_restore)
+ intel_edp_panel_vdd_sanitize(encoder);
intel_sanitize_encoder(encoder);
}
--
1.8.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/2] drm/i915: factor out intel_edp_panel_vdd_sanitize
This will be needed by an upcoming patch too that needs to sanitize the
VDD state during resume. The additional async disabling is only needed
for the resume path, here it doesn't make a difference since we enable
VDD right after the sanitize call.
v2:
- don't set intel_dp ptr for non-eDP encoders (Ville)
Signed-off-by: Imre Deak imre.d...@intel.com
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_dp.c | 60
drivers/gpu/drm/i915/intel_drv.h | 1 +
2 files changed, 44 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index ea6ff71..71294b5 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1285,6 +1285,19 @@ static void edp_panel_vdd_work(struct work_struct
*__work)
drm_modeset_unlock(dev-mode_config.connection_mutex);
}
+static void edp_panel_vdd_schedule_off(struct intel_dp *intel_dp)
+{
+ unsigned long delay;
+
+ /*
+* Queue the timer to fire a long time from now (relative to the power
+* down delay) to keep the panel power up across a sequence of
+* operations.
+*/
+ delay = msecs_to_jiffies(intel_dp-panel_power_cycle_delay * 5);
+ schedule_delayed_work(intel_dp-panel_vdd_work, delay);
+}
+
static void edp_panel_vdd_off(struct intel_dp *intel_dp, bool sync)
{
if (!is_edp(intel_dp))
@@ -1294,17 +1307,10 @@ static void edp_panel_vdd_off(struct intel_dp
*intel_dp, bool sync)
intel_dp-want_panel_vdd = false;
- if (sync) {
+ if (sync)
edp_panel_vdd_off_sync(intel_dp);
- } else {
- /*
-* Queue the timer to fire a long
-* time from now (relative to the power down delay)
-* to keep the panel power up across a sequence of operations
-*/
- schedule_delayed_work(intel_dp-panel_vdd_work,
-
msecs_to_jiffies(intel_dp-panel_power_cycle_delay * 5));
- }
+ else
+ edp_panel_vdd_schedule_off(intel_dp);
}
void intel_edp_panel_on(struct intel_dp *intel_dp)
@@ -4441,6 +4447,32 @@ intel_dp_drrs_init(struct intel_digital_port
*intel_dig_port,
return downclock_mode;
}
+void intel_edp_panel_vdd_sanitize(struct intel_encoder *intel_encoder)
+{
+ struct drm_device *dev = intel_encoder-base.dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ struct intel_dp *intel_dp;
+ enum intel_display_power_domain power_domain;
+
+ if (intel_encoder-type != INTEL_OUTPUT_EDP)
+ return;
+
+ intel_dp = enc_to_intel_dp(intel_encoder-base);
+ if (!edp_have_panel_vdd(intel_dp))
+ return;
+ /*
+* The VDD bit needs a power domain reference, so if the bit is
+* already enabled when we boot or resume, grab this reference and
+* schedule a vdd off, so we don't hold on to the reference
+* indefinitely.
+*/
+ DRM_DEBUG_KMS(VDD left on by BIOS, adjusting state tracking\n);
+ power_domain = intel_display_port_power_domain(intel_encoder);
+ intel_display_power_get(dev_priv, power_domain);
+
+ edp_panel_vdd_schedule_off(intel_dp);
+}
+
static bool intel_edp_init_connector(struct intel_dp *intel_dp,
struct intel_connector *intel_connector,
struct edp_power_seq *power_seq)
@@ -4461,13 +4493,7 @@ static bool intel_edp_init_connector(struct intel_dp
*intel_dp,
if (!is_edp(intel_dp))
return true;
- /* The VDD bit needs a power domain reference, so if the bit is already
-* enabled when we boot, grab this reference. */
- if (edp_have_panel_vdd(intel_dp)) {
- enum intel_display_power_domain power_domain;
- power_domain = intel_display_port_power_domain(intel_encoder);
- intel_display_power_get(dev_priv, power_domain);
- }
+ intel_edp_panel_vdd_sanitize(intel_encoder);
/* Cache DPCD and EDID for edp. */
intel_edp_panel_vdd_on(intel_dp);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index bdcc4a1..28d185d 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -909,6 +909,7 @@ bool intel_dp_hpd_pulse(struct intel_digital_port
*intel_dig_port,
void intel_edp_backlight_on(struct intel_dp *intel_dp);
void intel_edp_backlight_off(struct intel_dp *intel_dp);
void intel_edp_panel_vdd_on(struct intel_dp *intel_dp);
+void intel_edp_panel_vdd_sanitize(struct intel_encoder *intel_encoder);
void intel_edp_panel_on(struct intel_dp *intel_dp);
void intel_edp_panel_off(struct intel_dp *intel_dp);
void intel_edp_psr_enable(struct intel_dp *intel_dp);
--
1.8.4
[Intel-gfx] [PATCH] drm: Docbook fixes
Bunch of small leftovers spotted by looking at the make htmldocs output. I've left out dp mst, there's too much amiss there. Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch --- drivers/gpu/drm/drm_crtc.c | 5 +++-- drivers/gpu/drm/drm_edid.c | 2 +- drivers/gpu/drm/drm_modeset_lock.c | 2 +- 3 files changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c index 315770b7e65f..d4a1fab92562 100644 --- a/drivers/gpu/drm/drm_crtc.c +++ b/drivers/gpu/drm/drm_crtc.c @@ -3425,9 +3425,10 @@ EXPORT_SYMBOL(drm_property_create_enum); * @flags: flags specifying the property type * @name: name of the property * @props: enumeration lists with property bitflags - * @num_values: number of pre-defined values + * @num_props: size of the @props array + * @supported_bits: bitmask of all supported enumeration values * - * This creates a new generic drm property which can then be attached to a drm + * This creates a new bitmask drm property which can then be attached to a drm * object with drm_object_attach_property. The returned property object must be * freed with drm_property_destroy. * diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index 1dbf3bc4c6a3..f905c63c0f68 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c @@ -3433,10 +3433,10 @@ EXPORT_SYMBOL(drm_rgb_quant_range_selectable); /** * drm_assign_hdmi_deep_color_info - detect whether monitor supports * hdmi deep color modes and update drm_display_info if so. - * * @edid: monitor EDID information * @info: Updated with maximum supported deep color bpc and color format *if deep color supported. + * @connector: DRM connector, used only for debug output * * Parse the CEA extension according to CEA-861-B. * Return true if HDMI deep color supported, false if not or unknown. diff --git a/drivers/gpu/drm/drm_modeset_lock.c b/drivers/gpu/drm/drm_modeset_lock.c index 5280b64a0230..8749fc06570e 100644 --- a/drivers/gpu/drm/drm_modeset_lock.c +++ b/drivers/gpu/drm/drm_modeset_lock.c @@ -199,7 +199,7 @@ EXPORT_SYMBOL(drm_modeset_lock_crtc); /** * drm_modeset_legacy_acquire_ctx - find acquire ctx for legacy ioctls - * crtc: drm crtc + * @crtc: drm crtc * * Legacy ioctl operations like cursor updates or page flips only have per-crtc * locking, and store the acquire ctx in the corresponding crtc. All other -- 2.0.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/2] drm/i915: fix VDD state tracking after system resume
On Wed, Jul 30, 2014 at 03:57:32PM +0300, Imre Deak wrote:
Just like during booting the BIOS can leave the VDD bit enabled after
system resume. So apply the same state sanitization there too. This
fixes a problem where after resume the port power domain refcount gets
unbalanced.
Reported-and-tested-by: Jarkko Nikula jarkko.nik...@linux.intel.com
Signed-off-by: Imre Deak imre.d...@intel.com
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_display.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 1edfd1a..fdb5657 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12977,6 +12977,12 @@ void intel_modeset_setup_hw_state(struct drm_device
*dev,
/* HW state is read out, now we need to sanitize this mess. */
list_for_each_entry(encoder, dev-mode_config.encoder_list,
base.head) {
+ /*
+ * Do the following only during resume, since at driver
+ * loading it's done early when initializing the encoder.
+ */
+ if (force_restore)
+ intel_edp_panel_vdd_sanitize(encoder);
This should be put into an encoder-reset callback.
-Daniel
intel_sanitize_encoder(encoder);
}
--
1.8.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 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 v2 1/2] drm/i915: factor out intel_edp_panel_vdd_sanitize
On Wed, Jul 30, 2014 at 03:57:31PM +0300, Imre Deak wrote:
This will be needed by an upcoming patch too that needs to sanitize the
VDD state during resume. The additional async disabling is only needed
for the resume path, here it doesn't make a difference since we enable
VDD right after the sanitize call.
v2:
- don't set intel_dp ptr for non-eDP encoders (Ville)
Signed-off-by: Imre Deak imre.d...@intel.com
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
Queued for -next, thanks for the patch.
-Daniel
---
drivers/gpu/drm/i915/intel_dp.c | 60
drivers/gpu/drm/i915/intel_drv.h | 1 +
2 files changed, 44 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index ea6ff71..71294b5 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1285,6 +1285,19 @@ static void edp_panel_vdd_work(struct work_struct
*__work)
drm_modeset_unlock(dev-mode_config.connection_mutex);
}
+static void edp_panel_vdd_schedule_off(struct intel_dp *intel_dp)
+{
+ unsigned long delay;
+
+ /*
+ * Queue the timer to fire a long time from now (relative to the power
+ * down delay) to keep the panel power up across a sequence of
+ * operations.
+ */
+ delay = msecs_to_jiffies(intel_dp-panel_power_cycle_delay * 5);
+ schedule_delayed_work(intel_dp-panel_vdd_work, delay);
+}
+
static void edp_panel_vdd_off(struct intel_dp *intel_dp, bool sync)
{
if (!is_edp(intel_dp))
@@ -1294,17 +1307,10 @@ static void edp_panel_vdd_off(struct intel_dp
*intel_dp, bool sync)
intel_dp-want_panel_vdd = false;
- if (sync) {
+ if (sync)
edp_panel_vdd_off_sync(intel_dp);
- } else {
- /*
- * Queue the timer to fire a long
- * time from now (relative to the power down delay)
- * to keep the panel power up across a sequence of operations
- */
- schedule_delayed_work(intel_dp-panel_vdd_work,
-
msecs_to_jiffies(intel_dp-panel_power_cycle_delay * 5));
- }
+ else
+ edp_panel_vdd_schedule_off(intel_dp);
}
void intel_edp_panel_on(struct intel_dp *intel_dp)
@@ -4441,6 +4447,32 @@ intel_dp_drrs_init(struct intel_digital_port
*intel_dig_port,
return downclock_mode;
}
+void intel_edp_panel_vdd_sanitize(struct intel_encoder *intel_encoder)
+{
+ struct drm_device *dev = intel_encoder-base.dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ struct intel_dp *intel_dp;
+ enum intel_display_power_domain power_domain;
+
+ if (intel_encoder-type != INTEL_OUTPUT_EDP)
+ return;
+
+ intel_dp = enc_to_intel_dp(intel_encoder-base);
+ if (!edp_have_panel_vdd(intel_dp))
+ return;
+ /*
+ * The VDD bit needs a power domain reference, so if the bit is
+ * already enabled when we boot or resume, grab this reference and
+ * schedule a vdd off, so we don't hold on to the reference
+ * indefinitely.
+ */
+ DRM_DEBUG_KMS(VDD left on by BIOS, adjusting state tracking\n);
+ power_domain = intel_display_port_power_domain(intel_encoder);
+ intel_display_power_get(dev_priv, power_domain);
+
+ edp_panel_vdd_schedule_off(intel_dp);
+}
+
static bool intel_edp_init_connector(struct intel_dp *intel_dp,
struct intel_connector *intel_connector,
struct edp_power_seq *power_seq)
@@ -4461,13 +4493,7 @@ static bool intel_edp_init_connector(struct intel_dp
*intel_dp,
if (!is_edp(intel_dp))
return true;
- /* The VDD bit needs a power domain reference, so if the bit is already
- * enabled when we boot, grab this reference. */
- if (edp_have_panel_vdd(intel_dp)) {
- enum intel_display_power_domain power_domain;
- power_domain = intel_display_port_power_domain(intel_encoder);
- intel_display_power_get(dev_priv, power_domain);
- }
+ intel_edp_panel_vdd_sanitize(intel_encoder);
/* Cache DPCD and EDID for edp. */
intel_edp_panel_vdd_on(intel_dp);
diff --git a/drivers/gpu/drm/i915/intel_drv.h
b/drivers/gpu/drm/i915/intel_drv.h
index bdcc4a1..28d185d 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -909,6 +909,7 @@ bool intel_dp_hpd_pulse(struct intel_digital_port
*intel_dig_port,
void intel_edp_backlight_on(struct intel_dp *intel_dp);
void intel_edp_backlight_off(struct intel_dp *intel_dp);
void intel_edp_panel_vdd_on(struct intel_dp *intel_dp);
+void intel_edp_panel_vdd_sanitize(struct intel_encoder *intel_encoder);
void intel_edp_panel_on(struct intel_dp *intel_dp);
void intel_edp_panel_off(struct intel_dp
Re: [Intel-gfx] [PATCH 08/12] drm/i915: Improve reliability for Displayport link training
2014-07-14 16:10 GMT-03:00 Todd Previte tprev...@gmail.com:
Link training for Displayport can fail in many ways and at multiple different
points
during the training process. Previously, errors were logged but no additional
action
was taken based on them. Consequently, training attempts could continue even
after
errors have occured that would prevent successful link training. This patch
updates
the link training functions and where/how they're used to be more intelligent
about
failures and to stop trying to train the link when it's a lost cause.
I agree we need to do something about this problem, but I'm not sure
how this patch improves the situation. Can you please describe more
how exactly the changes you did are getting us towards the solution of
the problem? Of course, the points where you start signaling
previously-unsignaled errors are obviously an improvement.
Anyway, this patch should probably be split in 3:
- A patch to add the boolean return values and change
intel_dp_check_link_status() + intel_enable_dp() +
intel_ddi_pre_enable().
- A patch to signal dpcd error cases we were previously ignoring.
- A patch to that changes how intel_dp_start_link_train() and
intel_dp_stop_link_train() currently behave (the gotos replacing
break statements).
Se below for better explanations.
The big problem here is that these encoder callbacks never fail, so
there's not really much to do after we detect a sink failure.
In the current code (without your patch), we already clearly signal
the link training failures with debug+error messages, so the new debug
messages at places linke intel_enable_dp() are not much of an
improvement. Also, we already run intel_dp_set_idle_link_train() at
the end of intel_dp_complete_link_train(), and we do additional things
such as calling intel_dp_stop_link_train(). And I guess we do the
non-DDI equivalent steps at some point too, so I'm not sure how
jumping straight to intel_dp_set_idle_link_train() helps, since we do
it anyway as part of the normal sequence. Also, our mode set sequence
is currently completely followed - even though the sink fails to
understand what we throw at it - and I'm always afraid of not
following the sequence exactly as described in the spec, since it
could lead to unpredicted bugs (we had this problem dozens of times in
the past).
I think the real cool solution would be to retry link training with
different parameters (different clock and number of lanes), but I
imagine this would require a lot of code refactoring since we probably
need to go back to the compute_config stages of the modeset sequence.
Or maybe just finding a way to tell the user-space modesetting app
that it has a black screen would already be helpful.
Other people may think that the real-real long-term solution would be
to fix our code so it never fails link training or gives black screens
:)
Some more below:
Signed-off-by: Todd Previte tprev...@gmail.com
---
drivers/gpu/drm/i915/intel_ddi.c | 23 +--
drivers/gpu/drm/i915/intel_dp.c | 89
+---
drivers/gpu/drm/i915/intel_drv.h | 7 ++--
3 files changed, 90 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c
b/drivers/gpu/drm/i915/intel_ddi.c
index ded6013..c0727b8 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1246,6 +1246,7 @@ static void intel_ddi_pre_enable(struct intel_encoder
*intel_encoder)
struct intel_crtc *crtc = to_intel_crtc(encoder-crtc);
enum port port = intel_ddi_get_encoder_port(intel_encoder);
int type = intel_encoder-type;
+ uint8_t fail_code = 0;
if (crtc-config.has_audio) {
DRM_DEBUG_DRIVER(Audio on pipe %c on DDI\n,
@@ -1274,10 +1275,19 @@ static void intel_ddi_pre_enable(struct intel_encoder
*intel_encoder)
intel_dp-DP |= DDI_PORT_WIDTH(intel_dp-lane_count);
intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
- intel_dp_start_link_train(intel_dp);
- intel_dp_complete_link_train(intel_dp);
+ if (!intel_dp_start_link_train(intel_dp)) {
+ fail_code = 1;
+ goto failed;
+ }
+ if (!intel_dp_complete_link_train(intel_dp)) {
+ fail_code = 2;
+ goto failed;
+ }
if (port != PORT_A)
- intel_dp_stop_link_train(intel_dp);
+ if (!intel_dp_stop_link_train(intel_dp)) {
+ fail_code = 3;
+ goto failed;
+ }
} else if (type == INTEL_OUTPUT_HDMI) {
struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(encoder);
@@ -1285,6 +1295,13 @@ static void intel_ddi_pre_enable(struct intel_encoder
*intel_encoder)
Re: [Intel-gfx] [PATCH 7/8] drm/irq: Implement a generic vblank_wait function
On Wed, Jul 30, 2014 at 05:32:28PM +0900, Michel Dänzer wrote:
On 30.07.2014 17:22, Daniel Vetter wrote:
On Wed, Jul 30, 2014 at 11:59:33AM +0900, Michel Dänzer wrote:
On 30.07.2014 06:32, Daniel Vetter wrote:
+ * due to lack of driver support or because the crtc is off.
+ */
+void drm_crtc_vblank_wait(struct drm_crtc *crtc)
+{
+ drm_vblank_wait(crtc-dev, drm_crtc_index(crtc));
+}
+EXPORT_SYMBOL(drm_crtc_vblank_wait);
+
+/**
Maybe the function names should be *_vblank_wait_next() or something to
clarify the purpose and reduce potential confusion versus
drm_wait_vblank().
Yeah that name is just transferred from the i915 driver. What about
drm_wait_one_vblank()/drm_crtc_wait_one_vblank()?
I don't care that much :), go ahead.
Just my two cents: our downstream kernel has a helper somewhat like this
which waits for a specified number of frames (apparently this is useful
for some panels that require up to 5 or 6 frames before they display the
correct image on screen). So perhaps something like this could work:
void drm_wait_vblank_count(struct drm_device *dev, unsigned int crtc,
unsigned int count)
{
u32 last;
int ret;
ret = drm_vblank_get(dev, crtc);
if (WARN_ON(ret))
return;
while (count--) {
last = drm_vblank_count(dev, crtc);
...
}
drm_vblank_put(dev, crtc);
}
Then implement drm_wait_vblank() (or drm_wait_one_vblank()) on top of
that as a special case. Of course one could equally well implement
drm_wait_vblank_count() on top of your drm_wait_{one_,}vblank().
I couldn't think of a safe way to make the above work without the
loop...
Thierry
pgp9VsIm6JPov.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Remove context pointer from ppgtt struct
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
Vetter
Sent: Wednesday, July 30, 2014 12:59 PM
To: Thierry, Michel
Cc: intel-gfx@lists.freedesktop.org; Daniel Vetter
Subject: Re: [Intel-gfx] [PATCH] drm/i915: Remove context pointer from
ppgtt struct
On Wed, Jul 30, 2014 at 12:25:20PM +0100, Michel Thierry wrote:
After new vma/ppgtt lifetime rules, the ppgtt can outlive the context
it was created for.
- Renamed create_vm_for_ctx to i915_ppgtt_create as ctx/ppgtt are no
longer referenced.
- Updated per_file_stats to cope with this change.
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Signed-off-by: Michel Thierry michel.thie...@intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 6 +++---
drivers/gpu/drm/i915/i915_gem_context.c | 5 ++---
drivers/gpu/drm/i915/i915_gem_gtt.h | 2 --
3 files changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 96612a5..35c0f09 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -322,7 +322,7 @@ static int per_file_stats(int id, void *ptr, void
*data)
if (USES_FULL_PPGTT(obj-base.dev)) {
list_for_each_entry(vma, obj-vma_list, vma_link) {
- struct i915_hw_ppgtt *ppgtt;
+ struct intel_context *ctx;
if (!drm_mm_node_allocated(vma-node))
continue;
@@ -332,8 +332,8 @@ static int per_file_stats(int id, void *ptr, void
*data)
continue;
}
- ppgtt = container_of(vma-vm, struct
i915_hw_ppgtt, base);
- if (ppgtt-ctx ppgtt-ctx-file_priv != stats-
file_priv)
+ ctx = container_of(vma-vm, struct intel_context,
vm);
That doesn't really work.
-Daniel
Indeed, sorry about that. I'm sending v2.
+ if (ctx ctx-file_priv != stats-file_priv)
continue;
if (obj-ring) /* XXX per-vma statistic */
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 3e7cb50..43da325 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -210,7 +210,7 @@ i915_gem_alloc_context_obj(struct drm_device
*dev, size_t size)
}
static struct i915_hw_ppgtt *
-create_vm_for_ctx(struct drm_device *dev, struct intel_context *ctx)
+i915_ppgtt_create(struct drm_device *dev)
{
struct i915_hw_ppgtt *ppgtt;
int ret;
@@ -225,7 +225,6 @@ create_vm_for_ctx(struct drm_device *dev, struct
intel_context *ctx)
return ERR_PTR(ret);
}
- ppgtt-ctx = ctx;
return ppgtt;
}
@@ -315,7 +314,7 @@ i915_gem_create_context(struct drm_device *dev,
}
if (create_vm) {
- struct i915_hw_ppgtt *ppgtt = create_vm_for_ctx(dev, ctx);
+ struct i915_hw_ppgtt *ppgtt = i915_ppgtt_create(dev);
if (IS_ERR_OR_NULL(ppgtt)) {
DRM_DEBUG_DRIVER(PPGTT setup failed (%ld)\n,
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index 8d6f7c1..dd70b0f 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -258,8 +258,6 @@ struct i915_hw_ppgtt {
dma_addr_t *gen8_pt_dma_addr[4];
};
- struct intel_context *ctx;
-
int (*enable)(struct i915_hw_ppgtt *ppgtt);
int (*switch_mm)(struct i915_hw_ppgtt *ppgtt,
struct intel_engine_cs *ring,
--
2.0.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
smime.p7s
Description: S/MIME cryptographic signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Remove context pointer from ppgtt struct
After new vma/ppgtt lifetime rules, the ppgtt can outlive the context
it was created for.
- Renamed create_vm_for_ctx to i915_ppgtt_create as ctx/ppgtt are no
longer referenced.
- Updated per_file_stats to cope with this change.
v2: Get the right context for this ppgtt.
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Signed-off-by: Michel Thierry michel.thie...@intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 25 -
drivers/gpu/drm/i915/i915_gem_context.c | 5 ++---
drivers/gpu/drm/i915/i915_gem_gtt.h | 2 --
3 files changed, 26 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 9e737b7..0f34d6a 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -308,6 +308,27 @@ struct file_stats {
size_t active, inactive;
};
+static struct intel_context *
+i915_get_ppgtt_context(struct drm_i915_file_private *file_priv,
+ struct i915_hw_ppgtt *ppgtt)
+{
+ struct drm_i915_private *dev_priv = file_priv-dev_priv;
+ struct intel_context *ctx;
+ struct i915_hw_ppgtt *ctx_ppgtt;
+
+ list_for_each_entry(ctx, dev_priv-context_list, link) {
+ if (ctx-legacy_hw_ctx.rcs_state == NULL)
+ continue;
+ else {
+ ctx_ppgtt = ctx_to_ppgtt(ctx);
+ if (ppgtt == ctx_ppgtt)
+ return ctx;
+ }
+ }
+
+ return NULL;
+}
+
static int per_file_stats(int id, void *ptr, void *data)
{
struct drm_i915_gem_object *obj = ptr;
@@ -322,6 +343,7 @@ static int per_file_stats(int id, void *ptr, void *data)
if (USES_FULL_PPGTT(obj-base.dev)) {
list_for_each_entry(vma, obj-vma_list, vma_link) {
+ struct intel_context *ctx;
struct i915_hw_ppgtt *ppgtt;
if (!drm_mm_node_allocated(vma-node))
@@ -333,7 +355,8 @@ static int per_file_stats(int id, void *ptr, void *data)
}
ppgtt = container_of(vma-vm, struct i915_hw_ppgtt,
base);
- if (ppgtt-ctx ppgtt-ctx-file_priv !=
stats-file_priv)
+ ctx = i915_get_ppgtt_context(stats-file_priv, ppgtt);
+ if (ctx ctx-file_priv != stats-file_priv)
continue;
if (obj-ring) /* XXX per-vma statistic */
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 4cfb03a..0d741f2 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -182,7 +182,7 @@ i915_gem_alloc_context_obj(struct drm_device *dev, size_t
size)
}
static struct i915_hw_ppgtt *
-create_vm_for_ctx(struct drm_device *dev, struct intel_context *ctx)
+i915_ppgtt_create(struct drm_device *dev)
{
struct i915_hw_ppgtt *ppgtt;
int ret;
@@ -197,7 +197,6 @@ create_vm_for_ctx(struct drm_device *dev, struct
intel_context *ctx)
return ERR_PTR(ret);
}
- ppgtt-ctx = ctx;
return ppgtt;
}
@@ -287,7 +286,7 @@ i915_gem_create_context(struct drm_device *dev,
}
if (create_vm) {
- struct i915_hw_ppgtt *ppgtt = create_vm_for_ctx(dev, ctx);
+ struct i915_hw_ppgtt *ppgtt = i915_ppgtt_create(dev);
if (IS_ERR_OR_NULL(ppgtt)) {
DRM_DEBUG_DRIVER(PPGTT setup failed (%ld)\n,
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index 57d4013..b8806e9 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -258,8 +258,6 @@ struct i915_hw_ppgtt {
dma_addr_t *gen8_pt_dma_addr[4];
};
- struct intel_context *ctx;
-
int (*enable)(struct i915_hw_ppgtt *ppgtt);
int (*switch_mm)(struct i915_hw_ppgtt *ppgtt,
struct intel_engine_cs *ring,
--
2.0.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/8] drm/irq: Implement a generic vblank_wait function
On Tue, Jul 29, 2014 at 11:32:22PM +0200, Daniel Vetter wrote: [...] diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c [...] + ret = wait_event_timeout(dev-vblank[crtc].queue, + C, msecs_to_jiffies(100)); 100 milliseconds looks like a very arbitrary choice. Theoretically we support things like crtc-mode.vrefresh = 5, so I wonder if we should parameterize this on the refresh rate, or simply increase it further? Thierry pgptRWcbrOSF0.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 09/12] drm/i915: Update intel_dp_check_link_status() for Displayport compliance testing
2014-07-14 16:10 GMT-03:00 Todd Previte tprev...@gmail.com:
Move the DPCD read to the top and check for an interrupt from the sink to
catch
Displayport automated testing requests necessary to support Displayport
compliance
testing. The checks for active connectors and link status are moved below the
check for the interrupt.
Adds a check at the top to verify that the device is connected. This is
necessary
for DP compliance testing to ensure that test requests are captured and
acknowledged.
If a test request is present during a connected-disconnected transition,
the test code will attempt to execute even though the connection has been
disabled,
resulting in a faied test.
The problem here we that we just got an interrupt, so I am not sure if
we should believe what's in intel_dp-attached_connector-base.status:
doesn't it reflect the old state that we had before we got the
interrupt? I'm not sure if this information could be wrong. Can you
please elaborate on that?
The rest of the patch seems correct.
Signed-off-by: Todd Previte tprev...@gmail.com
---
drivers/gpu/drm/i915/intel_dp.c | 32 ++--
1 file changed, 18 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 1c6ee34..65830e9 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3600,22 +3600,13 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
u8 sink_irq_vector;
u8 link_status[DP_LINK_STATUS_SIZE];
- /* FIXME: This access isn't protected by any locks. */
- if (!intel_encoder-connectors_active)
- return;
-
- if (WARN_ON(!intel_encoder-base.crtc))
+ /* Bail if not connected */
+ if (intel_dp-attached_connector-base.status !=
connector_status_connected)
return;
- /* Try to read receiver status if the link appears to be up */
- if (!intel_dp_get_link_status(intel_dp, link_status)) {
- return;
- }
-
- /* Now read the DPCD to see if it's actually running */
- if (!intel_dp_get_dpcd(intel_dp)) {
+ /* Attempt to read the DPCD */
+ if (!intel_dp_get_dpcd(intel_dp))
return;
- }
/* Try to read the source of the interrupt */
if (intel_dp-dpcd[DP_DPCD_REV] = 0x11
@@ -3625,12 +3616,25 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
DP_DEVICE_SERVICE_IRQ_VECTOR,
sink_irq_vector);
- if (sink_irq_vector DP_AUTOMATED_TEST_REQUEST)
+ if (sink_irq_vector DP_AUTOMATED_TEST_REQUEST) {
+ DRM_DEBUG_KMS(Displayport: Received automated test
request\n);
intel_dp_handle_test_request(intel_dp);
+ }
if (sink_irq_vector (DP_CP_IRQ | DP_SINK_SPECIFIC_IRQ))
DRM_DEBUG_DRIVER(CP or sink specific irq
unhandled\n);
}
+ /* FIXME: This access isn't protected by any locks. */
+ if (!intel_encoder-connectors_active)
+ return;
+
+ if (WARN_ON(!intel_encoder-base.crtc))
+ return;
+
+ /* Try to read receiver status if the link appears to be up */
+ if (!intel_dp_get_link_status(intel_dp, link_status))
+ return;
+
if (!drm_dp_channel_eq_ok(link_status, intel_dp-lane_count)) {
DRM_DEBUG_KMS(%s: channel EQ not ok, retraining\n,
intel_encoder-base.name);
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Paulo Zanoni
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/8] drm/irq: Implement a generic vblank_wait function
On Wed, Jul 30, 2014 at 04:20:25PM +0200, Thierry Reding wrote:
On Wed, Jul 30, 2014 at 05:32:28PM +0900, Michel Dänzer wrote:
On 30.07.2014 17:22, Daniel Vetter wrote:
On Wed, Jul 30, 2014 at 11:59:33AM +0900, Michel Dänzer wrote:
On 30.07.2014 06:32, Daniel Vetter wrote:
+ * due to lack of driver support or because the crtc is off.
+ */
+void drm_crtc_vblank_wait(struct drm_crtc *crtc)
+{
+ drm_vblank_wait(crtc-dev, drm_crtc_index(crtc));
+}
+EXPORT_SYMBOL(drm_crtc_vblank_wait);
+
+/**
Maybe the function names should be *_vblank_wait_next() or something to
clarify the purpose and reduce potential confusion versus
drm_wait_vblank().
Yeah that name is just transferred from the i915 driver. What about
drm_wait_one_vblank()/drm_crtc_wait_one_vblank()?
I don't care that much :), go ahead.
Just my two cents: our downstream kernel has a helper somewhat like this
which waits for a specified number of frames (apparently this is useful
for some panels that require up to 5 or 6 frames before they display the
correct image on screen). So perhaps something like this could work:
void drm_wait_vblank_count(struct drm_device *dev, unsigned int crtc,
unsigned int count)
{
u32 last;
int ret;
ret = drm_vblank_get(dev, crtc);
if (WARN_ON(ret))
return;
while (count--) {
last = drm_vblank_count(dev, crtc);
...
}
drm_vblank_put(dev, crtc);
}
Would be nicer to wait for an absolute vblank count instead IMO. Or
if you want to pass a relative count in just convert it to an absolute
count first and wait for it (taking wraparound into account obviously).
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 12/12] drm/i915: Add a delay in Displayport AUX transactions for compliance testing
2014-07-15 12:34 GMT-03:00 Todd Previte tprev...@gmail.com:
Daniel Vetter dan...@ffwll.ch
Tuesday, July 15, 2014 12:46 AM
On Mon, Jul 14, 2014 at 12:10:47PM -0700, Todd Previte wrote:
The Displayport Link Layer Compliance Testing Specification 1.2 rev 1.1
specifies that
repeated AUX transactions after a failure (NACK, DEFER or no response) must
have
a minimum delay of 400us before the resend can occur. Tests 4.2.1.1 and
4.2.1.2 are two
tests that require this specifically.
Signed-off-by: Todd Previte tprev...@gmail.com tprev...@gmail.com
Since this is a minimal timeout ... shouldn't we put it into the dp
helpers instead?
-Daniel
This delay catches the case where the sink device either does not respond
at all or responds with an invalid AUX transaction. These are lower level
errors than the DRM helper functions are supposed to handle. I mistakenly
mentioned NACK/DEFER in the commit message - that's not an accurate
description of what this patch does. I will fix the commit message for v3
of this patch.
I agree your patch idea seems to be correct, but you should probably also
do a little review of drm_dp_dpcd_access() since it also retries everything
7 times and already has 400ms sleep.
Just one minor comment: why not use usleep_range() instead of udelay()?
-T
---
drivers/gpu/drm/i915/intel_dp.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 0e207aaf..f0664cd 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -573,8 +573,12 @@ intel_dp_aux_ch(struct intel_dp *intel_dp,
DP_AUX_CH_CTL_RECEIVE_ERROR);
if (status (DP_AUX_CH_CTL_TIME_OUT_ERROR |
- DP_AUX_CH_CTL_RECEIVE_ERROR))
+ DP_AUX_CH_CTL_RECEIVE_ERROR)) {
+ /* DP compliance requires 400us delay for
errors/timeouts
+(DP CTS 1.2 Core Rev 1.1, 4.2.1.1 4.2.1.2)
*/
+ udelay(400);
continue;
+ }
if (status DP_AUX_CH_CTL_DONE)
break;
}
--
1.9.1
___
Intel-gfx mailing
listIntel-gfx@lists.freedesktop.orghttp://lists.freedesktop.org/mailman/listinfo/intel-gfx
Todd Previte tprev...@gmail.com
Monday, July 14, 2014 12:10 PM
The Displayport Link Layer Compliance Testing Specification 1.2 rev 1.1
specifies that
repeated AUX transactions after a failure (NACK, DEFER or no response)
must have
a minimum delay of 400us before the resend can occur. Tests 4.2.1.1 and
4.2.1.2 are two
tests that require this specifically.
Signed-off-by: Todd Previte tprev...@gmail.com tprev...@gmail.com
---
drivers/gpu/drm/i915/intel_dp.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c
b/drivers/gpu/drm/i915/intel_dp.c
index 0e207aaf..f0664cd 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -573,8 +573,12 @@ intel_dp_aux_ch(struct intel_dp *intel_dp,
DP_AUX_CH_CTL_RECEIVE_ERROR);
if (status (DP_AUX_CH_CTL_TIME_OUT_ERROR |
- DP_AUX_CH_CTL_RECEIVE_ERROR))
+ DP_AUX_CH_CTL_RECEIVE_ERROR)) {
+ /* DP compliance requires 400us delay for errors/timeouts
+ (DP CTS 1.2 Core Rev 1.1, 4.2.1.1 4.2.1.2) */
+ udelay(400);
continue;
+ }
if (status DP_AUX_CH_CTL_DONE)
break;
}
Todd Previte tprev...@gmail.com
Monday, July 14, 2014 12:10 PM
V2:
- Addressed review feedback from the mailing list
- Broke up patches into smaller, easily managed chunks
- Reordered the patches such that they can be applied in order
- Fixed checkpatch.pl errors across the patchset
- Updated and enhanced functionality for the EDID test function
- Completely revamped the mode set operations for compliance testing
--
Sent with Postbox http://www.getpostbox.com
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Paulo Zanoni
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/12] drm/i915: Add automated testing support for Displayport compliance testing
2014-07-14 16:10 GMT-03:00 Todd Previte tprev...@gmail.com:
Add the skeleton framework for supporting automation for Displayport
compliance testing. This patch
adds the necessary framework for the source device to appropriately responded
to test automation
requests from a sink device.
Signed-off-by: Todd Previte tprev...@gmail.com
---
drivers/gpu/drm/i915/intel_dp.c | 84
-
1 file changed, 82 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index b5ec489..0d11145 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3328,11 +3328,91 @@ intel_dp_get_sink_irq(struct intel_dp *intel_dp, u8
*sink_irq_vector)
sink_irq_vector, 1) == 1;
}
+/* Displayport compliance testing - Link training */
+static uint8_t
+intel_dp_autotest_link_training(struct intel_dp *intel_dp)
+{
+ uint8_t test_result = DP_TEST_NAK;
+ return test_result;
+}
+
+/* Displayport compliance testing - Video pattern testing */
+static uint8_t
+intel_dp_autotest_video_pattern(struct intel_dp *intel_dp)
+{
+ uint8_t test_result = DP_TEST_NAK;
+ return test_result;
+}
+
+/* Displayport compliance testing - EDID operations */
+static uint8_t
+intel_dp_autotest_edid(struct intel_dp *intel_dp)
+{
+ uint8_t test_result = DP_TEST_NAK;
+ return test_result;
+}
+
+/* Displayport compliance testing - PHY pattern testing */
+static uint8_t
+intel_dp_autotest_phy_pattern(struct intel_dp *intel_dp)
+{
+ uint8_t test_result = DP_TEST_NAK;
+ return test_result;
+}
+
+/* Displayport compliance testing - Fast AUX transactions (optional) */
+static uint8_t
+intel_dp_autotest_faux_pattern(struct intel_dp *intel_dp)
+{
+ uint8_t test_result = DP_TEST_NAK;
+ DRM_DEBUG_KMS(Displayport: Fast AUX (FAUX) not supported\n);
+ return test_result;
+}
+
static void
intel_dp_handle_test_request(struct intel_dp *intel_dp)
{
- /* NAK by default */
- drm_dp_dpcd_writeb(intel_dp-aux, DP_TEST_RESPONSE, DP_TEST_NAK);
+ uint8_t response = DP_TEST_NAK;
+ uint8_t rxdata = 0;
+ int ret = 0;
+
+ DRM_DEBUG_KMS(Displayport: Received automated test request\n);
+ /* Read DP_TEST_REQUEST register to identify the requested test */
+ ret = drm_dp_dpcd_read(intel_dp-aux, DP_TEST_REQUEST, rxdata, 1);
+
+ /* Determine which test has been requested */
+ switch (rxdata) {
+ /* ACK/NAK response based on test function response
+ Unimplemented/unsupported tests will NAK */
+ case DP_TEST_LINK_TRAINING:
+ DRM_DEBUG_KMS(Displayport: Executing LINK_TRAINING
request\n);
+ response = intel_dp_autotest_link_training(intel_dp);
+ break;
+ case DP_TEST_LINK_VIDEO_PATTERN:
+ DRM_DEBUG_KMS(Displayport: Executing TEST_PATTERN
request\n);
+ response = intel_dp_autotest_video_pattern(intel_dp);
+ break;
+ case DP_TEST_LINK_EDID_READ:
+ DRM_DEBUG_KMS(Displayport: Executing EDID request\n);
+ response = intel_dp_autotest_edid(intel_dp);
+ break;
+ case DP_TEST_LINK_PHY_TEST_PATTERN:
+ DRM_DEBUG_KMS(Displayport: Executing PHY_PATTERN request\n);
+ response = intel_dp_autotest_phy_pattern(intel_dp);
+ break;
+ /* FAUX is optional in DP 1.2*/
+ case DP_TEST_LINK_FAUX_PATTERN:
+ DRM_DEBUG_KMS(Displayport: Executing FAUX_PATTERN
request\n);
+ response = intel_dp_autotest_faux_pattern(intel_dp);
+ break;
+ /* Unsupported test case or something went wrong */
+ default:
+ /* Log error here for unhandled test request */
+ DRM_DEBUG_KMS(Displayport: Unhandled test request\n);
+ break;
+ }
+ /* Send the response from the test result */
+ ret = drm_dp_dpcd_write(intel_dp-aux, DP_TEST_RESPONSE, response,
1);
Just one more idea: we could count amount of time passed during the
test execution, since the spec defines some timeouts.
}
/*
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Paulo Zanoni
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v3] drm/i915: Add correct hw/sw config check for DSI encoder
Check in vlv_crtc_clock_get if DPLL is enabled before calling dpio read.
It will not be enabled for DSI and avoid dpio read WARN dumps.
Absence of -get_config was causing other WARN dumps as well. Update
dpll_hw_state as well correctly
v2: Address review comments by Daniel
- Check if DPLL is enabled rather than checking pipe output type
- set adjusted_mode-flags to 0 in compute_config rather than using
pipe_config-quirks
- Add helper function in intel_dsi_pll.c and use that in intel_dsi.c
- updated dpll_hw_state correctly
- Updated commit message and title
v3: Address review comments by Imre
- Proper masking of P1, M1 fields while computing divisors
- assert in case of bpp mismatch
- guard for divide by 0 while computing pclk
- Use ARRAY_SIZE instead of direct calculation
Signed-off-by: Shobhit Kumar shobhit.ku...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 4 ++
drivers/gpu/drm/i915/intel_dsi.c | 21 +-
drivers/gpu/drm/i915/intel_dsi.h | 1 +
drivers/gpu/drm/i915/intel_dsi_pll.c | 81
4 files changed, 106 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index f3d6cc3..883af0b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6195,6 +6195,10 @@ static void vlv_crtc_clock_get(struct intel_crtc *crtc,
u32 mdiv;
int refclk = 10;
+ /* In case of MIPI DPLL will not even be used */
+ if (!(pipe_config-dpll_hw_state.dpll DPLL_VCO_ENABLE))
+ return;
+
mutex_lock(dev_priv-dpio_lock);
mdiv = vlv_dpio_read(dev_priv, pipe, VLV_PLL_DW3(pipe));
mutex_unlock(dev_priv-dpio_lock);
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 09e1caf..670c29a 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -92,6 +92,9 @@ static bool intel_dsi_compute_config(struct intel_encoder
*encoder,
if (fixed_mode)
intel_fixed_panel_mode(fixed_mode, adjusted_mode);
+ /* DSI uses short packets for sync events, so clear mode flags for DSI
*/
+ adjusted_mode-flags = 0;
+
if (intel_dsi-dev.dev_ops-mode_fixup)
return intel_dsi-dev.dev_ops-mode_fixup(intel_dsi-dev,
mode, adjusted_mode);
@@ -179,6 +182,10 @@ static void intel_dsi_pre_enable(struct intel_encoder
*encoder)
tmp |= DPLL_REFA_CLK_ENABLE_VLV;
I915_WRITE(DPLL(pipe), tmp);
+ /* update the hw state for DPLL */
+ intel_crtc-config.dpll_hw_state.dpll = DPLL_INTEGRATED_CLOCK_VLV |
+ DPLL_REFA_CLK_ENABLE_VLV;
+
tmp = I915_READ(DSPCLK_GATE_D);
tmp |= DPOUNIT_CLOCK_GATE_DISABLE;
I915_WRITE(DSPCLK_GATE_D, tmp);
@@ -359,9 +366,21 @@ static bool intel_dsi_get_hw_state(struct intel_encoder
*encoder,
static void intel_dsi_get_config(struct intel_encoder *encoder,
struct intel_crtc_config *pipe_config)
{
+ u32 pclk;
DRM_DEBUG_KMS(\n);
- /* XXX: read flags, set to adjusted_mode */
+ /*
+* DPLL_MD is not used in case of DSI, reading will get some default
value
+* set dpll_md = 0
+*/
+ pipe_config-dpll_hw_state.dpll_md = 0;
+
+ pclk = vlv_get_dsi_pclk(encoder, pipe_config-pipe_bpp);
+ if (!pclk)
+ return;
+
+ pipe_config-adjusted_mode.crtc_clock = pclk;
+ pipe_config-port_clock = pclk;
}
static enum drm_mode_status
diff --git a/drivers/gpu/drm/i915/intel_dsi.h b/drivers/gpu/drm/i915/intel_dsi.h
index 31db33d..fd51867 100644
--- a/drivers/gpu/drm/i915/intel_dsi.h
+++ b/drivers/gpu/drm/i915/intel_dsi.h
@@ -132,6 +132,7 @@ static inline struct intel_dsi *enc_to_intel_dsi(struct
drm_encoder *encoder)
extern void vlv_enable_dsi_pll(struct intel_encoder *encoder);
extern void vlv_disable_dsi_pll(struct intel_encoder *encoder);
+extern u32 vlv_get_dsi_pclk(struct intel_encoder *encoder, int pipe_bpp);
extern struct intel_dsi_dev_ops vbt_generic_dsi_display_ops;
diff --git a/drivers/gpu/drm/i915/intel_dsi_pll.c
b/drivers/gpu/drm/i915/intel_dsi_pll.c
index ba79ec1..d8bb1ea 100644
--- a/drivers/gpu/drm/i915/intel_dsi_pll.c
+++ b/drivers/gpu/drm/i915/intel_dsi_pll.c
@@ -298,3 +298,84 @@ void vlv_disable_dsi_pll(struct intel_encoder *encoder)
mutex_unlock(dev_priv-dpio_lock);
}
+
+static void assert_bpp_mismatch(int pixel_format, int pipe_bpp)
+{
+ int bpp;
+
+ switch (pixel_format) {
+ default:
+ case VID_MODE_FORMAT_RGB888:
+ case VID_MODE_FORMAT_RGB666_LOOSE:
+ bpp = 24;
+ break;
+ case VID_MODE_FORMAT_RGB666:
+ bpp = 18;
+ break;
+ case VID_MODE_FORMAT_RGB565:
+
Re: [Intel-gfx] [PATCH 7/8] drm/irq: Implement a generic vblank_wait function
On Wed, Jul 30, 2014 at 04:24:06PM +0200, Thierry Reding wrote: On Tue, Jul 29, 2014 at 11:32:22PM +0200, Daniel Vetter wrote: [...] diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c [...] + ret = wait_event_timeout(dev-vblank[crtc].queue, +C, msecs_to_jiffies(100)); 100 milliseconds looks like a very arbitrary choice. Theoretically we support things like crtc-mode.vrefresh = 5, so I wonder if we should parameterize this on the refresh rate, or simply increase it further? Once we have 10Hz panels I think we can pump/fix this. In i915 we've used 50ms everywhere, and never hit this. Except when driver bugs, ofc. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 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 7/8] drm/irq: Implement a generic vblank_wait function
On Wed, Jul 30, 2014 at 05:36:21PM +0300, Ville Syrjälä wrote:
On Wed, Jul 30, 2014 at 04:20:25PM +0200, Thierry Reding wrote:
On Wed, Jul 30, 2014 at 05:32:28PM +0900, Michel Dänzer wrote:
On 30.07.2014 17:22, Daniel Vetter wrote:
On Wed, Jul 30, 2014 at 11:59:33AM +0900, Michel Dänzer wrote:
On 30.07.2014 06:32, Daniel Vetter wrote:
+ * due to lack of driver support or because the crtc is off.
+ */
+void drm_crtc_vblank_wait(struct drm_crtc *crtc)
+{
+ drm_vblank_wait(crtc-dev, drm_crtc_index(crtc));
+}
+EXPORT_SYMBOL(drm_crtc_vblank_wait);
+
+/**
Maybe the function names should be *_vblank_wait_next() or something to
clarify the purpose and reduce potential confusion versus
drm_wait_vblank().
Yeah that name is just transferred from the i915 driver. What about
drm_wait_one_vblank()/drm_crtc_wait_one_vblank()?
I don't care that much :), go ahead.
Just my two cents: our downstream kernel has a helper somewhat like this
which waits for a specified number of frames (apparently this is useful
for some panels that require up to 5 or 6 frames before they display the
correct image on screen). So perhaps something like this could work:
void drm_wait_vblank_count(struct drm_device *dev, unsigned int crtc,
unsigned int count)
{
u32 last;
int ret;
ret = drm_vblank_get(dev, crtc);
if (WARN_ON(ret))
return;
while (count--) {
last = drm_vblank_count(dev, crtc);
...
}
drm_vblank_put(dev, crtc);
}
Would be nicer to wait for an absolute vblank count instead IMO. Or
if you want to pass a relative count in just convert it to an absolute
count first and wait for it (taking wraparound into account obviously).
Yeah I've conisidered to to a generic version, but don't though about all
the ways I'll get wrap-around wrong and decided that we better postpone
this until there's a real need. We can easily extract it later on ...
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 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 7/8] drm/irq: Implement a generic vblank_wait function
On Wed, Jul 30, 2014 at 05:06:38PM +0200, Daniel Vetter wrote: On Wed, Jul 30, 2014 at 04:24:06PM +0200, Thierry Reding wrote: On Tue, Jul 29, 2014 at 11:32:22PM +0200, Daniel Vetter wrote: [...] diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c [...] + ret = wait_event_timeout(dev-vblank[crtc].queue, + C, msecs_to_jiffies(100)); 100 milliseconds looks like a very arbitrary choice. Theoretically we support things like crtc-mode.vrefresh = 5, so I wonder if we should parameterize this on the refresh rate, or simply increase it further? Once we have 10Hz panels I think we can pump/fix this. In i915 we've used 50ms everywhere, and never hit this. Except when driver bugs, ofc. Okay, fair enough. Thierry pgpgmkMWqLs7t.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Xen-devel] [Announcement] Updates to XenGT - a Mediated Graphics Passthrough Solution from Intel
On ven, 2014-07-25 at 16:31 +0800, Jike Song wrote: The new source codes are available at the updated github repos: Linux: https://github.com/01org/XenGT-Preview-kernel.git Xen: https://github.com/01org/XenGT-Preview-xen.git Qemu: https://github.com/01org/XenGT-Preview-qemu.git Perhaps the info is available somewhere already (in which case, sorry), but what's the (if any) upstreaming plan/status/ETA? I think this info could well be part of these updates. :-) Thanks and Regards, Dario -- This happens because I choose it to happen! (Raistlin Majere) - Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems RD Ltd., Cambridge (UK) signature.asc Description: This is a digitally signed message part ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH -next] drm/i915: Remove duplicated include from intel_dsi_panel_vbt.c
From: Wei Yongjun yongjun_...@trendmicro.com.cn Remove duplicated include. Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn --- drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c index 47c7584..1439516 100644 --- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c +++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c @@ -31,7 +31,6 @@ #include linux/slab.h #include video/mipi_display.h #include asm/intel-mid.h -#include video/mipi_display.h #include i915_drv.h #include intel_drv.h #include intel_dsi.h ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/8] drm/irq: Implement a generic vblank_wait function
On Wed, Jul 30, 2014 at 05:36:21PM +0300, Ville Syrjälä wrote:
On Wed, Jul 30, 2014 at 04:20:25PM +0200, Thierry Reding wrote:
On Wed, Jul 30, 2014 at 05:32:28PM +0900, Michel Dänzer wrote:
On 30.07.2014 17:22, Daniel Vetter wrote:
On Wed, Jul 30, 2014 at 11:59:33AM +0900, Michel Dänzer wrote:
On 30.07.2014 06:32, Daniel Vetter wrote:
+ * due to lack of driver support or because the crtc is off.
+ */
+void drm_crtc_vblank_wait(struct drm_crtc *crtc)
+{
+ drm_vblank_wait(crtc-dev, drm_crtc_index(crtc));
+}
+EXPORT_SYMBOL(drm_crtc_vblank_wait);
+
+/**
Maybe the function names should be *_vblank_wait_next() or something to
clarify the purpose and reduce potential confusion versus
drm_wait_vblank().
Yeah that name is just transferred from the i915 driver. What about
drm_wait_one_vblank()/drm_crtc_wait_one_vblank()?
I don't care that much :), go ahead.
Just my two cents: our downstream kernel has a helper somewhat like this
which waits for a specified number of frames (apparently this is useful
for some panels that require up to 5 or 6 frames before they display the
correct image on screen). So perhaps something like this could work:
void drm_wait_vblank_count(struct drm_device *dev, unsigned int crtc,
unsigned int count)
{
u32 last;
int ret;
ret = drm_vblank_get(dev, crtc);
if (WARN_ON(ret))
return;
while (count--) {
last = drm_vblank_count(dev, crtc);
...
}
drm_vblank_put(dev, crtc);
}
Would be nicer to wait for an absolute vblank count instead IMO. Or
if you want to pass a relative count in just convert it to an absolute
count first and wait for it (taking wraparound into account obviously).
Hmm... would something like this work?
target = drm_vblank_count(dev, crtc) + count;
ret = wait_event_timeout(...,
drm_vblank_count(dev, crtc) == target,
...);
That should properly take into account wrap-around given that both sites
use drm_vblank_count().
Thierry
pgp5HZDUPJIB7.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 08/12] drm/i915: Improve reliability for Displayport link training
On Wed, Jul 30, 2014 at 11:07:34AM -0300, Paulo Zanoni wrote: 2014-07-14 16:10 GMT-03:00 Todd Previte tprev...@gmail.com: Link training for Displayport can fail in many ways and at multiple different points during the training process. Previously, errors were logged but no additional action was taken based on them. Consequently, training attempts could continue even after errors have occured that would prevent successful link training. This patch updates the link training functions and where/how they're used to be more intelligent about failures and to stop trying to train the link when it's a lost cause. I agree we need to do something about this problem, but I'm not sure how this patch improves the situation. Can you please describe more how exactly the changes you did are getting us towards the solution of the problem? Of course, the points where you start signaling previously-unsignaled errors are obviously an improvement. Anyway, this patch should probably be split in 3: - A patch to add the boolean return values and change intel_dp_check_link_status() + intel_enable_dp() + intel_ddi_pre_enable(). - A patch to signal dpcd error cases we were previously ignoring. - A patch to that changes how intel_dp_start_link_train() and intel_dp_stop_link_train() currently behave (the gotos replacing break statements). Se below for better explanations. The big problem here is that these encoder callbacks never fail, so there's not really much to do after we detect a sink failure. In the current code (without your patch), we already clearly signal the link training failures with debug+error messages, so the new debug messages at places linke intel_enable_dp() are not much of an improvement. Also, we already run intel_dp_set_idle_link_train() at the end of intel_dp_complete_link_train(), and we do additional things such as calling intel_dp_stop_link_train(). And I guess we do the non-DDI equivalent steps at some point too, so I'm not sure how jumping straight to intel_dp_set_idle_link_train() helps, since we do it anyway as part of the normal sequence. Also, our mode set sequence is currently completely followed - even though the sink fails to understand what we throw at it - and I'm always afraid of not following the sequence exactly as described in the spec, since it could lead to unpredicted bugs (we had this problem dozens of times in the past). I think the real cool solution would be to retry link training with different parameters (different clock and number of lanes), but I imagine this would require a lot of code refactoring since we probably need to go back to the compute_config stages of the modeset sequence. Or maybe just finding a way to tell the user-space modesetting app that it has a black screen would already be helpful. Other people may think that the real-real long-term solution would be to fix our code so it never fails link training or gives black screens :) DP spec says that we need to be able to retrain. My rough idea was that we set some flags in pipe config (or wire up return values) which signals that we need to rerun the modeset (including compute_config and all that). To keep the link bw/count limits around we could add some flags to the pipe config or something (and not completely clear it ofc). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Add a bit of locking to intel_dp_hpd_pulse()
From: Ville Syrjälä ville.syrj...@linux.intel.com
-hpd_pulse() is called from a workqueue via an interrupt so it happens
asynchronously with modesets. Grab the connection_mutex in
intel_dp_hpd_pulse() to avoid disturbing on angoing modeset with
parallel hpd processing.
On my IVB turning off the port during a modeset could result in a
hpd which would then proceed to link train while the modeset was
still happening. Suffice to say that didn't go so well.
Cc: Dave Airlie airl...@redhat.com
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_dp.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 87d0489..cd63e74 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4051,6 +4051,8 @@ intel_dp_hpd_pulse(struct intel_digital_port
*intel_dig_port, bool long_hpd)
DRM_DEBUG_KMS(got hpd irq on port %d - %s\n, intel_dig_port-port,
long_hpd ? long : short);
+ drm_modeset_lock(dev-mode_config.connection_mutex, NULL);
+
if (long_hpd) {
if (!ibx_digital_port_connected(dev_priv, intel_dig_port))
goto mst_fail;
@@ -4079,6 +4081,7 @@ intel_dp_hpd_pulse(struct intel_digital_port
*intel_dig_port, bool long_hpd)
intel_dp_check_link_status(intel_dp);
}
}
+ drm_modeset_unlock(dev-mode_config.connection_mutex);
return false;
mst_fail:
/* if we were in MST mode, and device is not there get out of MST mode
*/
@@ -4087,6 +4090,7 @@ mst_fail:
intel_dp-is_mst = false;
drm_dp_mst_topology_mgr_set_mst(intel_dp-mst_mgr,
intel_dp-is_mst);
}
+ drm_modeset_unlock(dev-mode_config.connection_mutex);
return true;
}
--
1.8.5.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Remove context pointer from ppgtt struct
On Wed, Jul 30, 2014 at 03:21:54PM +0100, Michel Thierry wrote:
After new vma/ppgtt lifetime rules, the ppgtt can outlive the context
it was created for.
- Renamed create_vm_for_ctx to i915_ppgtt_create as ctx/ppgtt are no
longer referenced.
- Updated per_file_stats to cope with this change.
v2: Get the right context for this ppgtt.
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Signed-off-by: Michel Thierry michel.thie...@intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 25 -
drivers/gpu/drm/i915/i915_gem_context.c | 5 ++---
drivers/gpu/drm/i915/i915_gem_gtt.h | 2 --
3 files changed, 26 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 9e737b7..0f34d6a 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -308,6 +308,27 @@ struct file_stats {
size_t active, inactive;
};
+static struct intel_context *
+i915_get_ppgtt_context(struct drm_i915_file_private *file_priv,
+ struct i915_hw_ppgtt *ppgtt)
+{
+ struct drm_i915_private *dev_priv = file_priv-dev_priv;
+ struct intel_context *ctx;
+ struct i915_hw_ppgtt *ctx_ppgtt;
+
+ list_for_each_entry(ctx, dev_priv-context_list, link) {
+ if (ctx-legacy_hw_ctx.rcs_state == NULL)
+ continue;
+ else {
+ ctx_ppgtt = ctx_to_ppgtt(ctx);
More cans of worms: You can't actually do that because we don't actually
store a ppgtt in ctx-vm, at least not always. That should be replaceable
with a ctx-ppgtt pointer, but there's more.
I think I'll take a look at this myself and do some untangling ...
-Daniel
+ if (ppgtt == ctx_ppgtt)
+ return ctx;
+ }
+ }
+
+ return NULL;
+}
+
static int per_file_stats(int id, void *ptr, void *data)
{
struct drm_i915_gem_object *obj = ptr;
@@ -322,6 +343,7 @@ static int per_file_stats(int id, void *ptr, void *data)
if (USES_FULL_PPGTT(obj-base.dev)) {
list_for_each_entry(vma, obj-vma_list, vma_link) {
+ struct intel_context *ctx;
struct i915_hw_ppgtt *ppgtt;
if (!drm_mm_node_allocated(vma-node))
@@ -333,7 +355,8 @@ static int per_file_stats(int id, void *ptr, void *data)
}
ppgtt = container_of(vma-vm, struct i915_hw_ppgtt,
base);
- if (ppgtt-ctx ppgtt-ctx-file_priv !=
stats-file_priv)
+ ctx = i915_get_ppgtt_context(stats-file_priv, ppgtt);
+ if (ctx ctx-file_priv != stats-file_priv)
continue;
if (obj-ring) /* XXX per-vma statistic */
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 4cfb03a..0d741f2 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -182,7 +182,7 @@ i915_gem_alloc_context_obj(struct drm_device *dev, size_t
size)
}
static struct i915_hw_ppgtt *
-create_vm_for_ctx(struct drm_device *dev, struct intel_context *ctx)
+i915_ppgtt_create(struct drm_device *dev)
{
struct i915_hw_ppgtt *ppgtt;
int ret;
@@ -197,7 +197,6 @@ create_vm_for_ctx(struct drm_device *dev, struct
intel_context *ctx)
return ERR_PTR(ret);
}
- ppgtt-ctx = ctx;
return ppgtt;
}
@@ -287,7 +286,7 @@ i915_gem_create_context(struct drm_device *dev,
}
if (create_vm) {
- struct i915_hw_ppgtt *ppgtt = create_vm_for_ctx(dev, ctx);
+ struct i915_hw_ppgtt *ppgtt = i915_ppgtt_create(dev);
if (IS_ERR_OR_NULL(ppgtt)) {
DRM_DEBUG_DRIVER(PPGTT setup failed (%ld)\n,
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index 57d4013..b8806e9 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -258,8 +258,6 @@ struct i915_hw_ppgtt {
dma_addr_t *gen8_pt_dma_addr[4];
};
- struct intel_context *ctx;
-
int (*enable)(struct i915_hw_ppgtt *ppgtt);
int (*switch_mm)(struct i915_hw_ppgtt *ppgtt,
struct intel_engine_cs *ring,
--
2.0.3
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 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 5/8] drm: trylock modest locking for fbdev panics
On Tue, Jul 29, 2014 at 11:32:20PM +0200, Daniel Vetter wrote:
In the fbdev code we want to do trylocks only to avoid deadlocks and
other ugly issues. Thus far we've only grabbed the overall modeset
lock, but that already failed to exclude a pile of potential
concurrent operations. With proper atomic support this will be worse.
So add a trylock mode to the modeset locking code which attempts all
locks only with trylocks, if possible. We need to track this in the
locking functions themselves and can't restrict this to drivers since
driver-private w/w mutexes must be treated the same way.
There's still the issue that other driver private locks aren't handled
here at all, but well can't have everything. With this we will at
least not regress, even once atomic allows lots of concurrent kms
activity.
Aside: We should move the acquire context to stack-based allocation in
the callers to get rid of that awful WARN_ON(kmalloc_failed) control
flow which just blows up when memory is short. But that's material for
separate patches.
v2:
- Fix logic inversion fumble in the fb helper.
- Add proper kerneldoc.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/drm_fb_helper.c| 10 +++
drivers/gpu/drm/drm_modeset_lock.c | 56
++
include/drm/drm_modeset_lock.h | 6
3 files changed, 55 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 3144db9dc0f1..841e039ba028 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -419,11 +419,11 @@ static bool drm_fb_helper_force_kernel_mode(void)
if (dev-switch_power_state == DRM_SWITCH_POWER_OFF)
continue;
- /* NOTE: we use lockless flag below to avoid grabbing other
- * modeset locks. So just trylock the underlying mutex
- * directly:
+ /*
+ * NOTE: Use trylock mode to avoid deadlocks and sleeping in
+ * panic context.
*/
- if (!mutex_trylock(dev-mode_config.mutex)) {
+ if (__drm_modeset_lock_all(dev, true) != 0) {
error = true;
continue;
}
Can we succeed locking config-mutex and connection_mutex inside
__drm_modeset_lock_all(), but then fail to lock one of the CRTC mutexes
in drm_modeset_lock_all_crtcs()? If so, __drm_modeset_lock_all() will
return -EBUSY, but not drop the locks it acquired, and then it seems
like we can return from the function here without ever dropping locks.
Matt
@@ -432,7 +432,7 @@ static bool drm_fb_helper_force_kernel_mode(void)
if (ret)
error = true;
- mutex_unlock(dev-mode_config.mutex);
+ drm_modeset_unlock_all(dev);
}
return error;
}
diff --git a/drivers/gpu/drm/drm_modeset_lock.c
b/drivers/gpu/drm/drm_modeset_lock.c
index 4d2aa549c614..acfe187609b0 100644
--- a/drivers/gpu/drm/drm_modeset_lock.c
+++ b/drivers/gpu/drm/drm_modeset_lock.c
@@ -57,26 +57,37 @@
/**
- * drm_modeset_lock_all - take all modeset locks
- * @dev: drm device
+ * __drm_modeset_lock_all - internal helper to grab all modeset locks
+ * @dev: DRM device
+ * @trylock: trylock mode for atomic contexts
*
- * This function takes all modeset locks, suitable where a more fine-grained
- * scheme isn't (yet) implemented. Locks must be dropped with
- * drm_modeset_unlock_all.
+ * This is a special version of drm_modeset_lock_all() which can also be
used in
+ * atomic contexts. Then @trylock must be set to true.
+ *
+ * Returns:
+ * 0 on success or negative error code on failure.
*/
-void drm_modeset_lock_all(struct drm_device *dev)
+int __drm_modeset_lock_all(struct drm_device *dev,
+bool trylock)
{
struct drm_mode_config *config = dev-mode_config;
struct drm_modeset_acquire_ctx *ctx;
int ret;
- ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
- if (WARN_ON(!ctx))
- return;
+ ctx = kzalloc(sizeof(*ctx),
+ trylock ? GFP_ATOMIC : GFP_KERNEL);
+ if (!ctx)
+ return -ENOMEM;
- mutex_lock(config-mutex);
+ if (trylock) {
+ if (!mutex_trylock(config-mutex))
+ return -EBUSY;
+ } else {
+ mutex_lock(config-mutex);
+ }
drm_modeset_acquire_init(ctx, 0);
+ ctx-trylock_only = trylock;
retry:
ret = drm_modeset_lock(config-connection_mutex, ctx);
@@ -95,13 +106,29 @@ retry:
drm_warn_on_modeset_not_all_locked(dev);
- return;
+ return 0;
fail:
if (ret == -EDEADLK) {
drm_modeset_backoff(ctx);
goto retry;
}
+
+ return ret;
+}
+EXPORT_SYMBOL(__drm_modeset_lock_all);
+
+/**
+ *
Re: [Intel-gfx] [PATCH 5/8] drm: trylock modest locking for fbdev panics
On Wed, Jul 30, 2014 at 08:56:07AM -0700, Matt Roper wrote:
On Tue, Jul 29, 2014 at 11:32:20PM +0200, Daniel Vetter wrote:
In the fbdev code we want to do trylocks only to avoid deadlocks and
other ugly issues. Thus far we've only grabbed the overall modeset
lock, but that already failed to exclude a pile of potential
concurrent operations. With proper atomic support this will be worse.
So add a trylock mode to the modeset locking code which attempts all
locks only with trylocks, if possible. We need to track this in the
locking functions themselves and can't restrict this to drivers since
driver-private w/w mutexes must be treated the same way.
There's still the issue that other driver private locks aren't handled
here at all, but well can't have everything. With this we will at
least not regress, even once atomic allows lots of concurrent kms
activity.
Aside: We should move the acquire context to stack-based allocation in
the callers to get rid of that awful WARN_ON(kmalloc_failed) control
flow which just blows up when memory is short. But that's material for
separate patches.
v2:
- Fix logic inversion fumble in the fb helper.
- Add proper kerneldoc.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/drm_fb_helper.c| 10 +++
drivers/gpu/drm/drm_modeset_lock.c | 56
++
include/drm/drm_modeset_lock.h | 6
3 files changed, 55 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c
b/drivers/gpu/drm/drm_fb_helper.c
index 3144db9dc0f1..841e039ba028 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -419,11 +419,11 @@ static bool drm_fb_helper_force_kernel_mode(void)
if (dev-switch_power_state == DRM_SWITCH_POWER_OFF)
continue;
- /* NOTE: we use lockless flag below to avoid grabbing other
-* modeset locks. So just trylock the underlying mutex
-* directly:
+ /*
+* NOTE: Use trylock mode to avoid deadlocks and sleeping in
+* panic context.
*/
- if (!mutex_trylock(dev-mode_config.mutex)) {
+ if (__drm_modeset_lock_all(dev, true) != 0) {
error = true;
continue;
}
Can we succeed locking config-mutex and connection_mutex inside
__drm_modeset_lock_all(), but then fail to lock one of the CRTC mutexes
in drm_modeset_lock_all_crtcs()? If so, __drm_modeset_lock_all() will
return -EBUSY, but not drop the locks it acquired, and then it seems
like we can return from the function here without ever dropping locks.
Well it's the panic code, so after this the machine is officially dead
anyway. The only thing left to do is get the dmesg out with as little risk
as possible.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 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] [v3] drm/i915: Add correct hw/sw config check for DSI encoder
On Wed, 2014-07-30 at 20:32 +0530, Shobhit Kumar wrote:
Check in vlv_crtc_clock_get if DPLL is enabled before calling dpio read.
It will not be enabled for DSI and avoid dpio read WARN dumps.
Absence of -get_config was causing other WARN dumps as well. Update
dpll_hw_state as well correctly
v2: Address review comments by Daniel
- Check if DPLL is enabled rather than checking pipe output type
- set adjusted_mode-flags to 0 in compute_config rather than using
pipe_config-quirks
- Add helper function in intel_dsi_pll.c and use that in intel_dsi.c
- updated dpll_hw_state correctly
- Updated commit message and title
v3: Address review comments by Imre
- Proper masking of P1, M1 fields while computing divisors
- assert in case of bpp mismatch
- guard for divide by 0 while computing pclk
- Use ARRAY_SIZE instead of direct calculation
Signed-off-by: Shobhit Kumar shobhit.ku...@intel.com
Reviewed-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 4 ++
drivers/gpu/drm/i915/intel_dsi.c | 21 +-
drivers/gpu/drm/i915/intel_dsi.h | 1 +
drivers/gpu/drm/i915/intel_dsi_pll.c | 81
4 files changed, 106 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index f3d6cc3..883af0b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6195,6 +6195,10 @@ static void vlv_crtc_clock_get(struct intel_crtc *crtc,
u32 mdiv;
int refclk = 10;
+ /* In case of MIPI DPLL will not even be used */
+ if (!(pipe_config-dpll_hw_state.dpll DPLL_VCO_ENABLE))
+ return;
+
mutex_lock(dev_priv-dpio_lock);
mdiv = vlv_dpio_read(dev_priv, pipe, VLV_PLL_DW3(pipe));
mutex_unlock(dev_priv-dpio_lock);
diff --git a/drivers/gpu/drm/i915/intel_dsi.c
b/drivers/gpu/drm/i915/intel_dsi.c
index 09e1caf..670c29a 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -92,6 +92,9 @@ static bool intel_dsi_compute_config(struct intel_encoder
*encoder,
if (fixed_mode)
intel_fixed_panel_mode(fixed_mode, adjusted_mode);
+ /* DSI uses short packets for sync events, so clear mode flags for DSI
*/
+ adjusted_mode-flags = 0;
+
if (intel_dsi-dev.dev_ops-mode_fixup)
return intel_dsi-dev.dev_ops-mode_fixup(intel_dsi-dev,
mode, adjusted_mode);
@@ -179,6 +182,10 @@ static void intel_dsi_pre_enable(struct intel_encoder
*encoder)
tmp |= DPLL_REFA_CLK_ENABLE_VLV;
I915_WRITE(DPLL(pipe), tmp);
+ /* update the hw state for DPLL */
+ intel_crtc-config.dpll_hw_state.dpll = DPLL_INTEGRATED_CLOCK_VLV |
+ DPLL_REFA_CLK_ENABLE_VLV;
+
tmp = I915_READ(DSPCLK_GATE_D);
tmp |= DPOUNIT_CLOCK_GATE_DISABLE;
I915_WRITE(DSPCLK_GATE_D, tmp);
@@ -359,9 +366,21 @@ static bool intel_dsi_get_hw_state(struct intel_encoder
*encoder,
static void intel_dsi_get_config(struct intel_encoder *encoder,
struct intel_crtc_config *pipe_config)
{
+ u32 pclk;
DRM_DEBUG_KMS(\n);
- /* XXX: read flags, set to adjusted_mode */
+ /*
+ * DPLL_MD is not used in case of DSI, reading will get some default
value
+ * set dpll_md = 0
+ */
+ pipe_config-dpll_hw_state.dpll_md = 0;
+
+ pclk = vlv_get_dsi_pclk(encoder, pipe_config-pipe_bpp);
+ if (!pclk)
+ return;
+
+ pipe_config-adjusted_mode.crtc_clock = pclk;
+ pipe_config-port_clock = pclk;
}
static enum drm_mode_status
diff --git a/drivers/gpu/drm/i915/intel_dsi.h
b/drivers/gpu/drm/i915/intel_dsi.h
index 31db33d..fd51867 100644
--- a/drivers/gpu/drm/i915/intel_dsi.h
+++ b/drivers/gpu/drm/i915/intel_dsi.h
@@ -132,6 +132,7 @@ static inline struct intel_dsi *enc_to_intel_dsi(struct
drm_encoder *encoder)
extern void vlv_enable_dsi_pll(struct intel_encoder *encoder);
extern void vlv_disable_dsi_pll(struct intel_encoder *encoder);
+extern u32 vlv_get_dsi_pclk(struct intel_encoder *encoder, int pipe_bpp);
extern struct intel_dsi_dev_ops vbt_generic_dsi_display_ops;
diff --git a/drivers/gpu/drm/i915/intel_dsi_pll.c
b/drivers/gpu/drm/i915/intel_dsi_pll.c
index ba79ec1..d8bb1ea 100644
--- a/drivers/gpu/drm/i915/intel_dsi_pll.c
+++ b/drivers/gpu/drm/i915/intel_dsi_pll.c
@@ -298,3 +298,84 @@ void vlv_disable_dsi_pll(struct intel_encoder *encoder)
mutex_unlock(dev_priv-dpio_lock);
}
+
+static void assert_bpp_mismatch(int pixel_format, int pipe_bpp)
+{
+ int bpp;
+
+ switch (pixel_format) {
+ default:
+ case VID_MODE_FORMAT_RGB888:
+ case VID_MODE_FORMAT_RGB666_LOOSE:
+ bpp = 24;
+
Re: [Intel-gfx] [PATCH] drm/i915: Rework GPU reset sequence to match driver load thaw
Hi Daniel, could you please be clearer on the change you mean. I think you mean something functionally equivalent to the code below, but done in a less hacky way. (This slight change has made no change to test results) Or is the idea to return at a different point to this? I couldn't find dev_priv-mm.reload_in_reset or similar in the code. The only thing I can find is error-reset_counter, which is used in check_wedge(). Bottom bit set means RESET_IN_PROGRESS, top bit means WEDGED --- a/drivers/gpu/drm/i915/intel_ringbuffer.c +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c @@ -1832,7 +1832,9 @@ int intel_ring_begin(struct intel_engine_cs *ring, ret = i915_gem_check_wedge(dev_priv-gpu_error, dev_priv-mm.interruptible); - if (ret) + + /* -EAGAIN means a reset is in progress, it is Ok to return */ + if (ret == -EAGAIN) + return 0; + if (ret) + return ret; ret = __intel_ring_prepare(ring, num_dwords * sizeof(uint32_t)); Alistair. -Original Message- From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of Daniel Vetter Sent: Tuesday, July 29, 2014 11:33 AM To: Chris Wilson; Daniel Vetter; Ben Widawsky; intel-gfx@lists.freedesktop.org Subject: Re: [Intel-gfx] [PATCH] drm/i915: Rework GPU reset sequence to match driver load thaw On Tue, Jul 29, 2014 at 08:36:33AM +0100, Chris Wilson wrote: On Mon, Jul 28, 2014 at 11:26:38AM +0200, Daniel Vetter wrote: Oh, I guess that's the tricky bit why the old approach never worked - because reset_in_progress is set we failed the context/ppgtt loading through the rings and screwed up. Problem with your approach is that we want to bail out here if a reset is in progress, so we can't just eat the EAGAIN. If we do that we potentially deadlock or overflow the ring. I think we need a different hack here, and a few layers down (i.e. at the place where we actually generate that offending -EAGAIN). - Around the re-init sequence in the reset function we set dev_priv-mm.reload_in_reset or similar . Since we hold dev-struct_mutex no one will see that, as long as we never leak it out of the critical section. - In the ring_begin code that checks for gpu hangs we ignore reset_in_progress if this bit is set. - Both places need fairly big comments to explain what exactly is going on. This is going from bad to worse. I think you can do better if you looked at the problem afresh. Well we can't really reset reset_in_progress at that point, since not all reset is done yet. Especially the modeset stuff. So I don't think that reordering the reset sequence would get us out of this ugly spot. And I don't see any other solution really. Do you? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] i915 / 3.15 intermittently boots into blank screeen
Am 30.07.2014 11:33, schrieb Daniel Vetter: On Wed, Jul 30, 2014 at 12:01:38AM +0200, Jan Niggemann wrote: Am 29.07.2014 23:35, schrieb Daniel Vetter: On Tue, Jul 29, 2014 at 11:09 PM, Jan Niggemann j...@hz6.de wrote: Am 18.07.2014 18:25, schrieb Daniel Vetter: On Fri, Jul 18, 2014 at 4:49 PM, Jan Niggemann j...@hz6.de wrote: Am 18.07.2014 15:27, schrieb Daniel Vetter: On Thu, Jul 17, 2014 at 10:31:30PM +0200, Jan Niggemann wrote: I'm experiencing an issue with 3.15.5 on my Lenovo T400: Since 3.15 (or 3.14, can't say for sure), the boot starts normally, but the first mode change doesn't occur, resulting in a black screen with backlight on. The system is entirely unresponsive and I can only press the power button until to switch it off. I think the only way to move forward here is to double-check that 3.14 works and 3.15 is broken by recompiling with the same .config (occasionally config changes cause regressions). And then do a full git bisect to find the offending commit. thank you for the feedback. I still have all my custom built kernels, I will test 3.14.0 through 3.14.8 to make sure those were OK and report back. You only need to test 3.14.0, since the backported fixes only contain a very small subset of all patches for 3.15. So it's more efficient to then switch to git bisect between 3.14 and 3.15 directly (after you've confirmed that 3.15.0 is indeed busted). I familiarized with git bisect, that was something I had never used before. I started it with git bisect start v3.15 v3.14 -- drivers/gpu/drm/i915 This lead me to this: cfa7c862982b431add7f2b362526bf31372fc7b0 is the first bad commit commit cfa7c862982b431add7f2b362526bf31372fc7b0 Author: Daniel Vetter daniel.vet...@ffwll.ch Date: Tue Apr 29 11:53:58 2014 +0200 drm/i915: Sanitize the enable_ppgtt module option once Otherwise we'll end up spamming dmesg on every context creation on snb with vt-d enabled. This regression was introduced in commit 246cbfb5fb9a1ca0997fbb135464c1ff5bb9c549 Author: Ben Widawsky benjamin.widaw...@intel.com Date: Fri Dec 6 14:11:14 2013 -0800 drm/i915: Reorganize intel_enable_ppgtt As the i915.enable_ppgtt is read-only it cannot be changed after the module is loaded and so we can perform an early sanitization of the values. v2: - Add comment and pimp commit message (Chris) - Use the param consistently (Jani) v3: - Fix init sequence on pre-gen6 by moving the sanitize_ppgtt call to gtt_init. Fixes boot hangs on pre-gen6. - Add a debug output for the sanitize ppgtt mode. References: https://lkml.org/lkml/2014/4/17/599 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77916 Cc: Alessandro Suardi alessandro.sua...@gmail.com Cc: Ben Widawsky b...@bwidawsk.net Cc: Chris Wilson ch...@chris-wilson.co.uk Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch Signed-off-by: Jani Nikula jani.nik...@intel.com :04 04 5488e397a1aaa28dca4a252452e9463b0a8f8d10 214c8e98b3c72844e48ab7aef02cba7daf139fab M drivers I realized that the issue does always show, contrary to the subject initially chosen. Unfortunately I can't say anything else, but maybe this will help you experts spot the issue. If I can help more, be it with testing or anything else, just let me know. Hm, I'm not aware of this breaking any gm45 machines, mine here is still happy. Can you please make sure that you don't have any i915 module options set anywhere, either on the kernel cmdline, modeprobe config files in /etc or anywhere else? My kernel cmdline doesn't have anything, but /etc/modprobe.d/i915-kms.conf exists. Its content is this single line: options i915 modeset=1 Can't remember if I created that (it's from 2010) or if it's Debian default... grep -Ri i915 /etc/ doesn't show anything else. grep 915 config-3.15 CONFIG_DRM_I915=m CONFIG_DRM_I915_KMS=y CONFIG_DRM_I915_FBDEV=y # CONFIG_DRM_I915_PRELIMINARY_HW_SUPPORT is not set # CONFIG_DRM_I915_UMS is not set CONFIG_SND_HDA_I915=y Would it help if I included the driver instead of building a module? Shouldn't change anything really, and config all looks sane. Didn't change anything indeed. Can you please retest with latest upstream (3.16 or even drm-intel-nightly)? Retested with drm-intel-nightly, this comes to a halt just before the first modeswitch. At least the screen didn't become blank - it displays: ACPI Warning: SystemIO range 0x1028-0x102f conflicts with OpRegion 0x1000-0x107f (\SB_.PCI0.LPC_.PMIO) (20140424/utaddress-258) ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver. ACPI Warning: SystemIO range 0x11b0-0x11bf conflicts with OpRegion 0x1180-0x11ff (\SB_.PCI0.LPC_.PMIO) (20140424/utaddress-258) ACPI: If an ACPI driver is available for this device, you should use it instead of
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Collect gtier properly on HSW.
2014-07-28 12:19 GMT-03:00 Rodrigo Vivi rodrigo.v...@intel.com:
GTIER and DEIER doesn't have same interface on HSW so this or operation
makes the information provided useless.
Cc: Paulo Zanoni paulo.r.zan...@intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_gpu_error.c | 16 ++--
2 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index ef38c3b..ccb97f1 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -314,6 +314,7 @@ struct drm_i915_error_state {
u32 eir;
u32 pgtbl_er;
u32 ier;
+ u32 gtier;
u32 ccid;
u32 derrmr;
u32 forcewake;
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 0b3f694..372fea3 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -359,6 +359,8 @@ int i915_error_state_to_str(struct
drm_i915_error_state_buf *m,
err_printf(m, PCI ID: 0x%04x\n, dev-pdev-device);
err_printf(m, EIR: 0x%08x\n, error-eir);
err_printf(m, IER: 0x%08x\n, error-ier);
+ if (IS_HASWELL(dev))
+ err_printf(m, GTIER: 0x%08x\n, error-gtier);
err_printf(m, PGTBL_ER: 0x%08x\n, error-pgtbl_er);
err_printf(m, FORCEWAKE: 0x%08x\n, error-forcewake);
err_printf(m, DERRMR: 0x%08x\n, error-derrmr);
@@ -1135,13 +1137,15 @@ static void i915_capture_reg_state(struct
drm_i915_private *dev_priv,
if (HAS_HW_CONTEXTS(dev))
error-ccid = I915_READ(CCID);
- if (HAS_PCH_SPLIT(dev))
+ if (IS_HASWELL(dev)) {
+ error-ier = I915_READ(DEIER);
+ error-gtier = I915_READ(GTIER);
+ } else if (HAS_PCH_SPLIT(dev)) {
error-ier = I915_READ(DEIER) | I915_READ(GTIER);
You did a change for HSW only, but we have these bits since Gen5. Why
don't you do this change for the whole HAS_PCH_SPLIT chunk instead of
adding a HSW-specific piece?
I am not a huge user of these error state files, I can't really think
why we would want to or the IER bits, so your patch looks correct to
me.
- else {
- if (IS_GEN2(dev))
- error-ier = I915_READ16(IER);
- else
- error-ier = I915_READ(IER);
+ } else if (IS_GEN2(dev)) {
+ error-ier = I915_READ16(IER);
+ } else {
+ error-ier = I915_READ(IER);
While reviewing your patch I also noticed that at the top of this
function we set error-ier for VLV, but then at this point we just
overwrite what was previously set. You could write another patch to
fix VLV too :)
}
/* 4: Everything else */
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Paulo Zanoni
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Fix DEIER and GTIER collecting for BDW.
2014-07-28 12:19 GMT-03:00 Rodrigo Vivi rodrigo.v...@intel.com:
BDW has many other Display Engine interrupts and GT interrupts registers.
Collecting it properly on gpu_error_state.
On debugfs all was properly listed already but besides we were also listing
old
DEIER and GTIER that doesn't exist on BDW anymore. This was causing
unclaimed register messages:
https://bugs.freedesktop.org/show_bug.cgi?id=81701
Cc: Paulo Zanoni paulo.r.zan...@intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 4 +++-
drivers/gpu/drm/i915/i915_gpu_error.c | 23 ---
3 files changed, 24 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 9e737b7..679cda6 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -783,7 +783,7 @@ static int i915_interrupt_info(struct seq_file *m, void
*data)
seq_printf(m, Pipe %c stat: %08x\n,
pipe_name(pipe),
I915_READ(PIPESTAT(pipe)));
- } else {
+ } else if (!IS_BROADWELL(dev)) {
seq_printf(m, North Display Interrupt enable:
%08x\n,
I915_READ(DEIER));
seq_printf(m, North Display Interrupt identity:
%08x\n,
This chunk is not needed since we already have a check for gen = 8
at the top.
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index ccb97f1..ee28cd7 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -314,7 +314,9 @@ struct drm_i915_error_state {
u32 eir;
u32 pgtbl_er;
u32 ier;
- u32 gtier;
+ u32 gtier[4];
+ u32 deier[3];
+ u32 de_misc_ier;
u32 ccid;
u32 derrmr;
u32 forcewake;
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 372fea3..f865d1d 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -358,9 +358,19 @@ int i915_error_state_to_str(struct
drm_i915_error_state_buf *m,
err_printf(m, Suspend count: %u\n, error-suspend_count);
err_printf(m, PCI ID: 0x%04x\n, dev-pdev-device);
err_printf(m, EIR: 0x%08x\n, error-eir);
- err_printf(m, IER: 0x%08x\n, error-ier);
+ if (IS_BROADWELL(dev)) {
+ for_each_pipe(i)
+ err_printf(m, DEIER pipe %c: 0x%08x\n, pipe_name(i),
+ error-deier[i]);
+ for (i = 0; i 4; i++)
+ err_printf(m, GTIER gt %d: 0x%08x\n, i,
+ error-gtier[i]);
+ err_printf(m, DE_MISC_IER: 0x%08x\n, error-de_misc_ier);
+ } else {
+ err_printf(m, IER: 0x%08x\n, error-ier);
+ }
if (IS_HASWELL(dev))
- err_printf(m, GTIER: 0x%08x\n, error-gtier);
+ err_printf(m, GTIER: 0x%08x\n, error-gtier[0]);
err_printf(m, PGTBL_ER: 0x%08x\n, error-pgtbl_er);
err_printf(m, FORCEWAKE: 0x%08x\n, error-forcewake);
err_printf(m, DERRMR: 0x%08x\n, error-derrmr);
@@ -1093,6 +1103,7 @@ static void i915_capture_reg_state(struct
drm_i915_private *dev_priv,
struct drm_i915_error_state *error)
{
struct drm_device *dev = dev_priv-dev;
+ int i;
/* General organization
* 1. Registers specific to a single generation
@@ -1139,7 +1150,13 @@ static void i915_capture_reg_state(struct
drm_i915_private *dev_priv,
if (IS_HASWELL(dev)) {
error-ier = I915_READ(DEIER);
- error-gtier = I915_READ(GTIER);
+ error-gtier[0] = I915_READ(GTIER);
+ } else if (IS_BROADWELL(dev)) {
+ for_each_pipe(i)
+ error-deier[i] = I915_READ(GEN8_DE_PIPE_IER(i));
for_each_pipe(i)
if (intel_display_power_enabled(dev_priv, POWER_DOMAIN_PIPE(i)))
error-deier[i] = I915_READ(GEN8_DE_PIPE_IER(i));
If the pipe's power well is disabled, the IER register is powered off
and we can get an unclaimed register errors too.
I also just noticed that this function contains the /* 4: Everything
else */ comment twice. You could remove one :)
+ for (i = 0; i 4; i++)
+ error-gtier[3] = I915_READ(GEN8_GT_IER(i));
+ error-de_misc_ier = I915_READ(GEN8_DE_MISC_IER);
} else if (HAS_PCH_SPLIT(dev)) {
error-ier = I915_READ(DEIER) | I915_READ(GTIER);
} else if (IS_GEN2(dev)) {
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Collect gtier properly on HSW.
On Wed, Jul 30, 2014 at 10:53 AM, Paulo Zanoni przan...@gmail.com wrote:
2014-07-28 12:19 GMT-03:00 Rodrigo Vivi rodrigo.v...@intel.com:
GTIER and DEIER doesn't have same interface on HSW so this or operation
makes the information provided useless.
Cc: Paulo Zanoni paulo.r.zan...@intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_gpu_error.c | 16 ++--
2 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index ef38c3b..ccb97f1 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -314,6 +314,7 @@ struct drm_i915_error_state {
u32 eir;
u32 pgtbl_er;
u32 ier;
+ u32 gtier;
u32 ccid;
u32 derrmr;
u32 forcewake;
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 0b3f694..372fea3 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -359,6 +359,8 @@ int i915_error_state_to_str(struct
drm_i915_error_state_buf *m,
err_printf(m, PCI ID: 0x%04x\n, dev-pdev-device);
err_printf(m, EIR: 0x%08x\n, error-eir);
err_printf(m, IER: 0x%08x\n, error-ier);
+ if (IS_HASWELL(dev))
+ err_printf(m, GTIER: 0x%08x\n, error-gtier);
err_printf(m, PGTBL_ER: 0x%08x\n, error-pgtbl_er);
err_printf(m, FORCEWAKE: 0x%08x\n, error-forcewake);
err_printf(m, DERRMR: 0x%08x\n, error-derrmr);
@@ -1135,13 +1137,15 @@ static void i915_capture_reg_state(struct
drm_i915_private *dev_priv,
if (HAS_HW_CONTEXTS(dev))
error-ccid = I915_READ(CCID);
- if (HAS_PCH_SPLIT(dev))
+ if (IS_HASWELL(dev)) {
+ error-ier = I915_READ(DEIER);
+ error-gtier = I915_READ(GTIER);
+ } else if (HAS_PCH_SPLIT(dev)) {
error-ier = I915_READ(DEIER) | I915_READ(GTIER);
You did a change for HSW only, but we have these bits since Gen5. Why
don't you do this change for the whole HAS_PCH_SPLIT chunk instead of
adding a HSW-specific piece?
I am not a huge user of these error state files, I can't really think
why we would want to or the IER bits, so your patch looks correct to
me.
I believe before HSW they had the same interface both DEIR and GTIER, but
since I'm splitting it for HSW you are right we can split everywhere else
with or without common interface.
- else {
- if (IS_GEN2(dev))
- error-ier = I915_READ16(IER);
- else
- error-ier = I915_READ(IER);
+ } else if (IS_GEN2(dev)) {
+ error-ier = I915_READ16(IER);
+ } else {
+ error-ier = I915_READ(IER);
While reviewing your patch I also noticed that at the top of this
function we set error-ier for VLV, but then at this point we just
overwrite what was previously set. You could write another patch to
fix VLV too :)
Yeah, it is messy... I'll also split for VLV and organize a bit to avoid
overwriting...
}
/* 4: Everything else */
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Paulo Zanoni
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Fix DEIER and GTIER collecting for BDW.
On Wed, Jul 30, 2014 at 11:09 AM, Paulo Zanoni przan...@gmail.com wrote:
2014-07-28 12:19 GMT-03:00 Rodrigo Vivi rodrigo.v...@intel.com:
BDW has many other Display Engine interrupts and GT interrupts registers.
Collecting it properly on gpu_error_state.
On debugfs all was properly listed already but besides we were also
listing old
DEIER and GTIER that doesn't exist on BDW anymore. This was causing
unclaimed register messages:
https://bugs.freedesktop.org/show_bug.cgi?id=81701
Cc: Paulo Zanoni paulo.r.zan...@intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 4 +++-
drivers/gpu/drm/i915/i915_gpu_error.c | 23 ---
3 files changed, 24 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 9e737b7..679cda6 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -783,7 +783,7 @@ static int i915_interrupt_info(struct seq_file *m,
void *data)
seq_printf(m, Pipe %c stat: %08x\n,
pipe_name(pipe),
I915_READ(PIPESTAT(pipe)));
- } else {
+ } else if (!IS_BROADWELL(dev)) {
seq_printf(m, North Display Interrupt enable:
%08x\n,
I915_READ(DEIER));
seq_printf(m, North Display Interrupt identity:
%08x\n,
This chunk is not needed since we already have a check for gen = 8
at the top.
oh, for a moment I thought it was messy as the other code and it was
writing twice...
mainly when you mentioned that you could reproduce the unclaimed when
reading debugfs...
but probably was related to the powerwell you mentioned below...
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index ccb97f1..ee28cd7 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -314,7 +314,9 @@ struct drm_i915_error_state {
u32 eir;
u32 pgtbl_er;
u32 ier;
- u32 gtier;
+ u32 gtier[4];
+ u32 deier[3];
+ u32 de_misc_ier;
u32 ccid;
u32 derrmr;
u32 forcewake;
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 372fea3..f865d1d 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -358,9 +358,19 @@ int i915_error_state_to_str(struct
drm_i915_error_state_buf *m,
err_printf(m, Suspend count: %u\n, error-suspend_count);
err_printf(m, PCI ID: 0x%04x\n, dev-pdev-device);
err_printf(m, EIR: 0x%08x\n, error-eir);
- err_printf(m, IER: 0x%08x\n, error-ier);
+ if (IS_BROADWELL(dev)) {
+ for_each_pipe(i)
+ err_printf(m, DEIER pipe %c: 0x%08x\n,
pipe_name(i),
+ error-deier[i]);
+ for (i = 0; i 4; i++)
+ err_printf(m, GTIER gt %d: 0x%08x\n, i,
+ error-gtier[i]);
+ err_printf(m, DE_MISC_IER: 0x%08x\n,
error-de_misc_ier);
+ } else {
+ err_printf(m, IER: 0x%08x\n, error-ier);
+ }
if (IS_HASWELL(dev))
- err_printf(m, GTIER: 0x%08x\n, error-gtier);
+ err_printf(m, GTIER: 0x%08x\n, error-gtier[0]);
err_printf(m, PGTBL_ER: 0x%08x\n, error-pgtbl_er);
err_printf(m, FORCEWAKE: 0x%08x\n, error-forcewake);
err_printf(m, DERRMR: 0x%08x\n, error-derrmr);
@@ -1093,6 +1103,7 @@ static void i915_capture_reg_state(struct
drm_i915_private *dev_priv,
struct drm_i915_error_state *error)
{
struct drm_device *dev = dev_priv-dev;
+ int i;
/* General organization
* 1. Registers specific to a single generation
@@ -1139,7 +1150,13 @@ static void i915_capture_reg_state(struct
drm_i915_private *dev_priv,
if (IS_HASWELL(dev)) {
error-ier = I915_READ(DEIER);
- error-gtier = I915_READ(GTIER);
+ error-gtier[0] = I915_READ(GTIER);
+ } else if (IS_BROADWELL(dev)) {
+ for_each_pipe(i)
+ error-deier[i] = I915_READ(GEN8_DE_PIPE_IER(i));
for_each_pipe(i)
if (intel_display_power_enabled(dev_priv, POWER_DOMAIN_PIPE(i)))
error-deier[i] = I915_READ(GEN8_DE_PIPE_IER(i));
If the pipe's power well is disabled, the IER register is powered off
and we can get an unclaimed register errors too.
thanks! I'll add it...
Also also need to be added to debugfs interface.
I also just noticed that this function contains the /* 4: Everything
else */ comment twice.
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Fix DEIER and GTIER collecting for BDW.
2014-07-30 15:20 GMT-03:00 Rodrigo Vivi rodrigo.v...@gmail.com:
On Wed, Jul 30, 2014 at 11:09 AM, Paulo Zanoni przan...@gmail.com wrote:
2014-07-28 12:19 GMT-03:00 Rodrigo Vivi rodrigo.v...@intel.com:
BDW has many other Display Engine interrupts and GT interrupts
registers.
Collecting it properly on gpu_error_state.
On debugfs all was properly listed already but besides we were also
listing old
DEIER and GTIER that doesn't exist on BDW anymore. This was causing
unclaimed register messages:
https://bugs.freedesktop.org/show_bug.cgi?id=81701
Cc: Paulo Zanoni paulo.r.zan...@intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 4 +++-
drivers/gpu/drm/i915/i915_gpu_error.c | 23 ---
3 files changed, 24 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 9e737b7..679cda6 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -783,7 +783,7 @@ static int i915_interrupt_info(struct seq_file *m,
void *data)
seq_printf(m, Pipe %c stat: %08x\n,
pipe_name(pipe),
I915_READ(PIPESTAT(pipe)));
- } else {
+ } else if (!IS_BROADWELL(dev)) {
seq_printf(m, North Display Interrupt enable:
%08x\n,
I915_READ(DEIER));
seq_printf(m, North Display Interrupt identity:
%08x\n,
This chunk is not needed since we already have a check for gen = 8
at the top.
oh, for a moment I thought it was messy as the other code and it was writing
twice...
mainly when you mentioned that you could reproduce the unclaimed when
reading debugfs...
but probably was related to the powerwell you mentioned below...
Yes, at i915_interrupt_info we also need to call intel_display_power_enabled().
I also won't complain if you fix i915_frequency_info on BDW :)
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index ccb97f1..ee28cd7 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -314,7 +314,9 @@ struct drm_i915_error_state {
u32 eir;
u32 pgtbl_er;
u32 ier;
- u32 gtier;
+ u32 gtier[4];
+ u32 deier[3];
+ u32 de_misc_ier;
u32 ccid;
u32 derrmr;
u32 forcewake;
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 372fea3..f865d1d 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -358,9 +358,19 @@ int i915_error_state_to_str(struct
drm_i915_error_state_buf *m,
err_printf(m, Suspend count: %u\n, error-suspend_count);
err_printf(m, PCI ID: 0x%04x\n, dev-pdev-device);
err_printf(m, EIR: 0x%08x\n, error-eir);
- err_printf(m, IER: 0x%08x\n, error-ier);
+ if (IS_BROADWELL(dev)) {
+ for_each_pipe(i)
+ err_printf(m, DEIER pipe %c: 0x%08x\n,
pipe_name(i),
+ error-deier[i]);
+ for (i = 0; i 4; i++)
+ err_printf(m, GTIER gt %d: 0x%08x\n, i,
+ error-gtier[i]);
+ err_printf(m, DE_MISC_IER: 0x%08x\n,
error-de_misc_ier);
+ } else {
+ err_printf(m, IER: 0x%08x\n, error-ier);
+ }
if (IS_HASWELL(dev))
- err_printf(m, GTIER: 0x%08x\n, error-gtier);
+ err_printf(m, GTIER: 0x%08x\n, error-gtier[0]);
err_printf(m, PGTBL_ER: 0x%08x\n, error-pgtbl_er);
err_printf(m, FORCEWAKE: 0x%08x\n, error-forcewake);
err_printf(m, DERRMR: 0x%08x\n, error-derrmr);
@@ -1093,6 +1103,7 @@ static void i915_capture_reg_state(struct
drm_i915_private *dev_priv,
struct drm_i915_error_state *error)
{
struct drm_device *dev = dev_priv-dev;
+ int i;
/* General organization
* 1. Registers specific to a single generation
@@ -1139,7 +1150,13 @@ static void i915_capture_reg_state(struct
drm_i915_private *dev_priv,
if (IS_HASWELL(dev)) {
error-ier = I915_READ(DEIER);
- error-gtier = I915_READ(GTIER);
+ error-gtier[0] = I915_READ(GTIER);
+ } else if (IS_BROADWELL(dev)) {
+ for_each_pipe(i)
+ error-deier[i] =
I915_READ(GEN8_DE_PIPE_IER(i));
for_each_pipe(i)
if (intel_display_power_enabled(dev_priv, POWER_DOMAIN_PIPE(i)))
error-deier[i] = I915_READ(GEN8_DE_PIPE_IER(i));
If the pipe's power well is disabled, the IER register is
[Intel-gfx] drm/i915: Wrong MCH_SSKPD value: 0x16040307
0) A ThinkPad X220 I use prints these messages at every boot and at every resume: [drm] Wrong MCH_SSKPD value: 0x16040307 [drm] This can cause pipe underruns and display issues. [drm] Please upgrade your BIOS to fix this. These messages can be seen for every kernel that's still in the logs (the oldest is v3.11 based). 1) I'm not sure whether I actually run into pipe underruns or display issues. Is there something specific I should look for? 2) Now it happens that this laptop already runs the latest BIOS. So, if I were to contact Lenovo to see if they could release a BIOS update to fix this, what should I ask them to do? Paul Bolle ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 29/40] drm/i915: Refactor Broadwell PIPE_CONTROL emission into a helper.
On Tue, Jul 29, 2014 at 08:01:53PM +0200, Daniel Vetter wrote:
On Tue, Jul 29, 2014 at 09:59:53AM -0700, Jesse Barnes wrote:
On Sat, 28 Jun 2014 02:04:20 +0300
ville.syrj...@linux.intel.com wrote:
From: Kenneth Graunke kenn...@whitecape.org
We'll want to reuse this for a workaround.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 36
-
1 file changed, 22 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 2faef26..97796b1 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -381,6 +381,27 @@ gen7_render_ring_flush(struct intel_engine_cs *ring,
}
static int
+gen8_emit_pipe_control(struct intel_engine_cs *ring,
+u32 flags, u32 scratch_addr)
+{
+ int ret;
+
+ ret = intel_ring_begin(ring, 6);
+ if (ret)
+ return ret;
+
+ intel_ring_emit(ring, GFX_OP_PIPE_CONTROL(6));
+ intel_ring_emit(ring, flags);
+ intel_ring_emit(ring, scratch_addr);
+ intel_ring_emit(ring, 0);
+ intel_ring_emit(ring, 0);
+ intel_ring_emit(ring, 0);
+ intel_ring_advance(ring);
+
+ return 0;
+}
+
+static int
gen8_render_ring_flush(struct intel_engine_cs *ring,
u32 invalidate_domains, u32 flush_domains)
{
@@ -405,20 +426,7 @@ gen8_render_ring_flush(struct intel_engine_cs *ring,
flags |= PIPE_CONTROL_GLOBAL_GTT_IVB;
}
- ret = intel_ring_begin(ring, 6);
- if (ret)
- return ret;
-
- intel_ring_emit(ring, GFX_OP_PIPE_CONTROL(6));
- intel_ring_emit(ring, flags);
- intel_ring_emit(ring, scratch_addr);
- intel_ring_emit(ring, 0);
- intel_ring_emit(ring, 0);
- intel_ring_emit(ring, 0);
- intel_ring_advance(ring);
-
- return 0;
-
+ return gen8_emit_pipe_control(ring, flags, scratch_addr);
}
static void ring_write_tail(struct intel_engine_cs *ring,
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
Aside: checkpatch complains about this since it makes it harder to grep
for dmesg noise. But I guess if 3 people here like it I should merge it
;-)
That reply was meant for 27/40, not this patch here ofc.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Align intel_dsi*.c files a bit
I'm not really that insisting on checkpath compliance, but ragged
function paramter alignment does get me. Please adjust your editor to
just do this for you.
Cc: Shobhit Kumar shobhit.ku...@intel.com
Cc: Imre Deak imre.d...@intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_dsi.c | 24
drivers/gpu/drm/i915/intel_dsi_cmd.c | 2 +-
drivers/gpu/drm/i915/intel_dsi_pll.c | 8
3 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index a98343bada5e..04756a2baa94 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -183,7 +183,7 @@ static void intel_dsi_pre_enable(struct intel_encoder
*encoder)
/* update the hw state for DPLL */
intel_crtc-config.dpll_hw_state.dpll = DPLL_INTEGRATED_CLOCK_VLV |
- DPLL_REFA_CLK_ENABLE_VLV;
+ DPLL_REFA_CLK_ENABLE_VLV;
tmp = I915_READ(DSPCLK_GATE_D);
tmp |= DPOUNIT_CLOCK_GATE_DISABLE;
@@ -258,8 +258,8 @@ static void intel_dsi_disable(struct intel_encoder *encoder)
temp = I915_READ(MIPI_CTRL(pipe));
temp = ~ESCAPE_CLOCK_DIVIDER_MASK;
I915_WRITE(MIPI_CTRL(pipe), temp |
- intel_dsi-escape_clk_div
- ESCAPE_CLOCK_DIVIDER_SHIFT);
+ intel_dsi-escape_clk_div
+ ESCAPE_CLOCK_DIVIDER_SHIFT);
I915_WRITE(MIPI_EOT_DISABLE(pipe), CLOCKSTOP);
@@ -300,7 +300,7 @@ static void intel_dsi_clear_device_ready(struct
intel_encoder *encoder)
usleep_range(1000, 1500);
if (wait_for(((I915_READ(MIPI_PORT_CTRL(pipe)) AFE_LATCHOUT)
- == 0x0), 30))
+ == 0x0), 30))
DRM_ERROR(DSI LP not going Low\n);
I915_WRITE(MIPI_DEVICE_READY(pipe), 0x00);
@@ -426,7 +426,7 @@ static u16 txbyteclkhs(u16 pixels, int bpp, int lane_count,
u16 burst_mode_ratio)
{
return DIV_ROUND_UP(DIV_ROUND_UP(pixels * bpp * burst_mode_ratio,
- 8 * 100), lane_count);
+8 * 100), lane_count);
}
static void set_dsi_timings(struct drm_encoder *encoder,
@@ -453,10 +453,10 @@ static void set_dsi_timings(struct drm_encoder *encoder,
/* horizontal values are in terms of high speed byte clock */
hactive = txbyteclkhs(hactive, bpp, lane_count,
- intel_dsi-burst_mode_ratio);
+ intel_dsi-burst_mode_ratio);
hfp = txbyteclkhs(hfp, bpp, lane_count, intel_dsi-burst_mode_ratio);
hsync = txbyteclkhs(hsync, bpp, lane_count,
- intel_dsi-burst_mode_ratio);
+ intel_dsi-burst_mode_ratio);
hbp = txbyteclkhs(hbp, bpp, lane_count, intel_dsi-burst_mode_ratio);
I915_WRITE(MIPI_HACTIVE_AREA_COUNT(pipe), hactive);
@@ -581,7 +581,7 @@ static void intel_dsi_prepare(struct intel_encoder
*intel_encoder)
* XXX: write MIPI_STOP_STATE_STALL?
*/
I915_WRITE(MIPI_HIGH_LOW_SWITCH_COUNT(pipe),
- intel_dsi-hs_to_lp_count);
+ intel_dsi-hs_to_lp_count);
/* XXX: low power clock equivalence in terms of byte clock. the number
* of byte clocks occupied in one low power clock. based on txbyteclkhs
@@ -606,10 +606,10 @@ static void intel_dsi_prepare(struct intel_encoder
*intel_encoder)
* 64 like 1366 x 768. Enable RANDOM resolution support for such
* panels by default */
I915_WRITE(MIPI_VIDEO_MODE_FORMAT(pipe),
- intel_dsi-video_frmt_cfg_bits |
- intel_dsi-video_mode_format |
- IP_TG_CONFIG |
- RANDOM_DPI_DISPLAY_RESOLUTION);
+ intel_dsi-video_frmt_cfg_bits |
+ intel_dsi-video_mode_format |
+ IP_TG_CONFIG |
+ RANDOM_DPI_DISPLAY_RESOLUTION);
}
static void intel_dsi_pre_pll_enable(struct intel_encoder *encoder)
diff --git a/drivers/gpu/drm/i915/intel_dsi_cmd.c
b/drivers/gpu/drm/i915/intel_dsi_cmd.c
index f5ac3cc65c4b..dc8763a3cca3 100644
--- a/drivers/gpu/drm/i915/intel_dsi_cmd.c
+++ b/drivers/gpu/drm/i915/intel_dsi_cmd.c
@@ -436,7 +436,7 @@ void wait_for_dsi_fifo_empty(struct intel_dsi *intel_dsi)
u32 mask;
mask = LP_CTRL_FIFO_EMPTY | HS_CTRL_FIFO_EMPTY |
- LP_DATA_FIFO_EMPTY | HS_DATA_FIFO_EMPTY;
+ LP_DATA_FIFO_EMPTY | HS_DATA_FIFO_EMPTY;
if (wait_for((I915_READ(MIPI_GEN_FIFO_STAT(pipe)) mask) == mask,
Re: [Intel-gfx] [v2] drm/i915: Add support for Video Burst Mode for MIPI DSI
On Wed, Jul 30, 2014 at 08:34:57PM +0530, Shobhit Kumar wrote:
v2: Updated the error log as suggested by Imre
Signed-off-by: Shobhit Kumar shobhit.ku...@intel.com
Reviewed-by: Imre Deak imre.d...@intel.com
Remaining patches merged, thanks.
-Daniel
---
drivers/gpu/drm/i915/intel_bios.h | 3 ++-
drivers/gpu/drm/i915/intel_dsi.c | 22 ++---
drivers/gpu/drm/i915/intel_dsi.h | 2 ++
drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 38
--
drivers/gpu/drm/i915/intel_dsi_pll.c | 9 +++
5 files changed, 57 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_bios.h
b/drivers/gpu/drm/i915/intel_bios.h
index b986677..905999b 100644
--- a/drivers/gpu/drm/i915/intel_bios.h
+++ b/drivers/gpu/drm/i915/intel_bios.h
@@ -802,7 +802,8 @@ struct mipi_config {
u16 rsvd4;
- u8 rsvd5[5];
+ u8 rsvd5;
+ u32 target_burst_mode_freq;
u32 dsi_ddr_clk;
u32 bridge_ref_clk;
diff --git a/drivers/gpu/drm/i915/intel_dsi.c
b/drivers/gpu/drm/i915/intel_dsi.c
index 670c29a..aea8f33 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -423,9 +423,11 @@ static u16 txclkesc(u32 divider, unsigned int us)
}
/* return pixels in terms of txbyteclkhs */
-static u16 txbyteclkhs(u16 pixels, int bpp, int lane_count)
+static u16 txbyteclkhs(u16 pixels, int bpp, int lane_count,
+u16 burst_mode_ratio)
{
- return DIV_ROUND_UP(DIV_ROUND_UP(pixels * bpp, 8), lane_count);
+ return DIV_ROUND_UP(DIV_ROUND_UP(pixels * bpp * burst_mode_ratio,
+ 8 * 100), lane_count);
}
static void set_dsi_timings(struct drm_encoder *encoder,
@@ -451,10 +453,12 @@ static void set_dsi_timings(struct drm_encoder *encoder,
vbp = mode-vtotal - mode-vsync_end;
/* horizontal values are in terms of high speed byte clock */
- hactive = txbyteclkhs(hactive, bpp, lane_count);
- hfp = txbyteclkhs(hfp, bpp, lane_count);
- hsync = txbyteclkhs(hsync, bpp, lane_count);
- hbp = txbyteclkhs(hbp, bpp, lane_count);
+ hactive = txbyteclkhs(hactive, bpp, lane_count,
+ intel_dsi-burst_mode_ratio);
+ hfp = txbyteclkhs(hfp, bpp, lane_count, intel_dsi-burst_mode_ratio);
+ hsync = txbyteclkhs(hsync, bpp, lane_count,
+ intel_dsi-burst_mode_ratio);
+ hbp = txbyteclkhs(hbp, bpp, lane_count, intel_dsi-burst_mode_ratio);
I915_WRITE(MIPI_HACTIVE_AREA_COUNT(pipe), hactive);
I915_WRITE(MIPI_HFP_COUNT(pipe), hfp);
@@ -541,12 +545,14 @@ static void intel_dsi_prepare(struct intel_encoder
*intel_encoder)
intel_dsi-video_mode_format == VIDEO_MODE_BURST) {
I915_WRITE(MIPI_HS_TX_TIMEOUT(pipe),
txbyteclkhs(adjusted_mode-htotal, bpp,
-intel_dsi-lane_count) + 1);
+intel_dsi-lane_count,
+intel_dsi-burst_mode_ratio) + 1);
} else {
I915_WRITE(MIPI_HS_TX_TIMEOUT(pipe),
txbyteclkhs(adjusted_mode-vtotal *
adjusted_mode-htotal,
-bpp, intel_dsi-lane_count) + 1);
+bpp, intel_dsi-lane_count,
+intel_dsi-burst_mode_ratio) + 1);
}
I915_WRITE(MIPI_LP_RX_TIMEOUT(pipe), intel_dsi-lp_rx_timeout);
I915_WRITE(MIPI_TURN_AROUND_TIMEOUT(pipe), intel_dsi-turn_arnd_val);
diff --git a/drivers/gpu/drm/i915/intel_dsi.h
b/drivers/gpu/drm/i915/intel_dsi.h
index fd51867..657eb5c 100644
--- a/drivers/gpu/drm/i915/intel_dsi.h
+++ b/drivers/gpu/drm/i915/intel_dsi.h
@@ -116,6 +116,8 @@ struct intel_dsi {
u16 clk_hs_to_lp_count;
u16 init_count;
+ u32 pclk;
+ u16 burst_mode_ratio;
/* all delays in ms */
u16 backlight_off_delay;
diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
index 47c7584..f6bdd44 100644
--- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
@@ -271,6 +271,8 @@ static bool generic_init(struct intel_dsi_device *dsi)
u32 ths_prepare_ns, tclk_trail_ns;
u32 tclk_prepare_clkzero, ths_prepare_hszero;
u32 lp_to_hs_switch, hs_to_lp_switch;
+ u32 pclk, computed_ddr;
+ u16 burst_mode_ratio;
DRM_DEBUG_KMS(\n);
@@ -284,8 +286,6 @@ static bool generic_init(struct intel_dsi_device *dsi)
else if (intel_dsi-pixel_format == VID_MODE_FORMAT_RGB565)
bits_per_pixel = 16;
- bitrate = (mode-clock * bits_per_pixel) / intel_dsi-lane_count;
-
intel_dsi-operation_mode =
Re: [Intel-gfx] [PATCH 26/40] drm/i915: Parametrize VLV_DDL registers
2014-06-27 20:04 GMT-03:00 ville.syrj...@linux.intel.com:
From: Ville Syrjälä ville.syrj...@linux.intel.com
The VLV/CHV DDL registers are uniform, and neatly enough the register
offsets are sane so we can easily unify them to a single set of defines
and just pass the pipe as the parameter to compute the register offset.
What the commit message doesn't tell is that now we will call
vlv_compute_drain_latency() for pipe C on CHV since I see CHV is
defined with num_pipes=3. I think this is quite an important detail,
since it's the only way this patch changes the behavior of the code.
If that is intentional and correct, then I suggest amending the commit
message, even maybe the patch title. Then you can add: Reviewed-by:
Paulo Zanoni paulo.r.zan...@intel.com.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 54
++---
drivers/gpu/drm/i915/intel_pm.c | 52 ++-
2 files changed, 36 insertions(+), 70 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 9fab647..60dd19c 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4018,47 +4018,19 @@ enum punit_power_well {
/* drain latency register values*/
#define DRAIN_LATENCY_PRECISION_32 32
#define DRAIN_LATENCY_PRECISION_64 64
-#define VLV_DDL1 (VLV_DISPLAY_BASE + 0x70050)
-#define DDL_CURSORA_PRECISION_64 (131)
-#define DDL_CURSORA_PRECISION_32 (031)
-#define DDL_CURSORA_SHIFT 24
-#define DDL_SPRITEB_PRECISION_64 (123)
-#define DDL_SPRITEB_PRECISION_32 (023)
-#define DDL_SPRITEB_SHIFT 16
-#define DDL_SPRITEA_PRECISION_64 (115)
-#define DDL_SPRITEA_PRECISION_32 (015)
-#define DDL_SPRITEA_SHIFT 8
-#define DDL_PLANEA_PRECISION_64(17)
-#define DDL_PLANEA_PRECISION_32(07)
-#define DDL_PLANEA_SHIFT 0
-
-#define VLV_DDL2 (VLV_DISPLAY_BASE + 0x70054)
-#define DDL_CURSORB_PRECISION_64 (131)
-#define DDL_CURSORB_PRECISION_32 (031)
-#define DDL_CURSORB_SHIFT 24
-#define DDL_SPRITED_PRECISION_64 (123)
-#define DDL_SPRITED_PRECISION_32 (023)
-#define DDL_SPRITED_SHIFT 16
-#define DDL_SPRITEC_PRECISION_64 (115)
-#define DDL_SPRITEC_PRECISION_32 (015)
-#define DDL_SPRITEC_SHIFT 8
-#define DDL_PLANEB_PRECISION_64(17)
-#define DDL_PLANEB_PRECISION_32(07)
-#define DDL_PLANEB_SHIFT 0
-
-#define VLV_DDL3 (VLV_DISPLAY_BASE + 0x70058)
-#define DDL_CURSORC_PRECISION_64 (131)
-#define DDL_CURSORC_PRECISION_32 (031)
-#define DDL_CURSORC_SHIFT 24
-#define DDL_SPRITEF_PRECISION_64 (123)
-#define DDL_SPRITEF_PRECISION_32 (023)
-#define DDL_SPRITEF_SHIFT 16
-#define DDL_SPRITEE_PRECISION_64 (115)
-#define DDL_SPRITEE_PRECISION_32 (015)
-#define DDL_SPRITEE_SHIFT 8
-#define DDL_PLANEC_PRECISION_64(17)
-#define DDL_PLANEC_PRECISION_32(07)
-#define DDL_PLANEC_SHIFT 0
+#define VLV_DDL(pipe) (VLV_DISPLAY_BASE + 0x70050 + 4 *
(pipe))
+#define DDL_CURSOR_PRECISION_64(131)
+#define DDL_CURSOR_PRECISION_32(031)
+#define DDL_CURSOR_SHIFT 24
+#define DDL_SPRITE1_PRECISION_64 (123)
+#define DDL_SPRITE1_PRECISION_32 (023)
+#define DDL_SPRITE1_SHIFT 16
+#define DDL_SPRITE0_PRECISION_64 (115)
+#define DDL_SPRITE0_PRECISION_32 (015)
+#define DDL_SPRITE0_SHIFT 8
+#define DDL_PLANE_PRECISION_64 (17)
+#define DDL_PLANE_PRECISION_32 (07)
+#define DDL_PLANE_SHIFT0
/* FIFO watermark sizes etc */
#define G4X_FIFO_LINE_SIZE 64
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index dc858b5..f0516a7 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -1275,35 +1275,29 @@ static bool vlv_compute_drain_latency(struct
drm_device *dev,
static void vlv_update_drain_latency(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
- int planea_prec, planea_dl, planeb_prec, planeb_dl;
- int cursora_prec, cursora_dl, cursorb_prec, cursorb_dl;
- int plane_prec_mult, cursor_prec_mult; /* Precision multiplier is
- either 16 or 32 */
-
- /* For plane A, Cursor A */
- if (vlv_compute_drain_latency(dev, 0, plane_prec_mult, planea_dl,
- cursor_prec_mult, cursora_dl)) {
- cursora_prec = (cursor_prec_mult ==
Re: [Intel-gfx] [PATCH] drm/i915: Rework GPU reset sequence to match driver load thaw
On Wed, Jul 30, 2014 at 04:59:33PM +, Mcaulay, Alistair wrote: Hi Daniel, could you please be clearer on the change you mean. I think you mean something functionally equivalent to the code below, but done in a less hacky way. (This slight change has made no change to test results) Or is the idea to return at a different point to this? I couldn't find dev_priv-mm.reload_in_reset or similar in the code. The only thing I can find is error-reset_counter, which is used in check_wedge(). Bottom bit set means RESET_IN_PROGRESS, top bit means WEDGED Well I've meant that you have to add a new dev_prive-mm.realod_in_reset. And the below won't work since in all other places but when doing a gpu reset we want the -EAGAIN to reach callers. Actually it's really important that if we have an -EGAIN we don't eat it. And I guess the check for mm.reload_in_reset should actually be in gem_check_wedged. -Daniel --- a/drivers/gpu/drm/i915/intel_ringbuffer.c +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c @@ -1832,7 +1832,9 @@ int intel_ring_begin(struct intel_engine_cs *ring, ret = i915_gem_check_wedge(dev_priv-gpu_error, dev_priv-mm.interruptible); -if (ret) + +/* -EAGAIN means a reset is in progress, it is Ok to return */ +if (ret == -EAGAIN) +return 0; +if (ret) +return ret; ret = __intel_ring_prepare(ring, num_dwords * sizeof(uint32_t)); Alistair. -Original Message- From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of Daniel Vetter Sent: Tuesday, July 29, 2014 11:33 AM To: Chris Wilson; Daniel Vetter; Ben Widawsky; intel-gfx@lists.freedesktop.org Subject: Re: [Intel-gfx] [PATCH] drm/i915: Rework GPU reset sequence to match driver load thaw On Tue, Jul 29, 2014 at 08:36:33AM +0100, Chris Wilson wrote: On Mon, Jul 28, 2014 at 11:26:38AM +0200, Daniel Vetter wrote: Oh, I guess that's the tricky bit why the old approach never worked - because reset_in_progress is set we failed the context/ppgtt loading through the rings and screwed up. Problem with your approach is that we want to bail out here if a reset is in progress, so we can't just eat the EAGAIN. If we do that we potentially deadlock or overflow the ring. I think we need a different hack here, and a few layers down (i.e. at the place where we actually generate that offending -EAGAIN). - Around the re-init sequence in the reset function we set dev_priv-mm.reload_in_reset or similar . Since we hold dev-struct_mutex no one will see that, as long as we never leak it out of the critical section. - In the ring_begin code that checks for gpu hangs we ignore reset_in_progress if this bit is set. - Both places need fairly big comments to explain what exactly is going on. This is going from bad to worse. I think you can do better if you looked at the problem afresh. Well we can't really reset reset_in_progress at that point, since not all reset is done yet. Especially the modeset stuff. So I don't think that reordering the reset sequence would get us out of this ugly spot. And I don't see any other solution really. Do you? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/7] drm/i915: Allow i915_gem_setup_global_gtt to fail
We already needs this just as a safety check in case the preallocation
reservation dance fails. But we definitely need this to be able to
move tha aliasing ppgtt setup back out of the context code to this
place, where it belongs.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_gem.c | 7 ++-
drivers/gpu/drm/i915/i915_gem_gtt.c | 16 ++--
drivers/gpu/drm/i915/i915_gem_gtt.h | 4 ++--
3 files changed, 18 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index f4e57fe05c6a..d8399ee622b9 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4762,7 +4762,12 @@ int i915_gem_init(struct drm_device *dev)
DRM_DEBUG_DRIVER(allow wake ack timed out\n);
}
- i915_gem_init_userptr(dev);
+ ret = i915_gem_init_userptr(dev);
+ if (ret) {
+ mutex_unlock(dev-struct_mutex);
+ return ret;
+ }
+
i915_gem_init_global_gtt(dev);
ret = i915_gem_context_init(dev);
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 3753bf184865..4fa7807ed4d5 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -1709,10 +1709,10 @@ static void i915_gtt_color_adjust(struct drm_mm_node
*node,
}
}
-void i915_gem_setup_global_gtt(struct drm_device *dev,
- unsigned long start,
- unsigned long mappable_end,
- unsigned long end)
+int i915_gem_setup_global_gtt(struct drm_device *dev,
+ unsigned long start,
+ unsigned long mappable_end,
+ unsigned long end)
{
/* Let GEM Manage all of the aperture.
*
@@ -1745,8 +1745,10 @@ void i915_gem_setup_global_gtt(struct drm_device *dev,
WARN_ON(i915_gem_obj_ggtt_bound(obj));
ret = drm_mm_reserve_node(ggtt_vm-mm, vma-node);
- if (ret)
- DRM_DEBUG_KMS(Reservation failed\n);
+ if (ret) {
+ DRM_DEBUG_KMS(Reservation failed: %i\n, ret);
+ return ret;
+ }
obj-has_global_gtt_mapping = 1;
}
@@ -1763,6 +1765,8 @@ void i915_gem_setup_global_gtt(struct drm_device *dev,
/* And finally clear the reserved guard page */
ggtt_vm-clear_range(ggtt_vm, end - PAGE_SIZE, PAGE_SIZE, true);
+
+ return 0;
}
void i915_gem_init_global_gtt(struct drm_device *dev)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index 0b04ef6167f8..bea3541d5525 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -271,8 +271,8 @@ struct i915_hw_ppgtt {
int i915_gem_gtt_init(struct drm_device *dev);
void i915_gem_init_global_gtt(struct drm_device *dev);
-void i915_gem_setup_global_gtt(struct drm_device *dev, unsigned long start,
- unsigned long mappable_end, unsigned long end);
+int i915_gem_setup_global_gtt(struct drm_device *dev, unsigned long start,
+ unsigned long mappable_end, unsigned long end);
bool intel_enable_ppgtt(struct drm_device *dev, bool full);
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 7/7] drm/i915: Drop create_vm argument to i915_gem_create_context
Now that all the flow is streamlined the rule is simple: We create
a new ppgtt for a new context when we have full ppgtt enabled.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_gem_context.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index c00e5d027774..655ed6228aab 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -229,8 +229,7 @@ err_out:
*/
static struct intel_context *
i915_gem_create_context(struct drm_device *dev,
- struct drm_i915_file_private *file_priv,
- bool create_vm)
+ struct drm_i915_file_private *file_priv)
{
const bool is_global_default_ctx = file_priv == NULL;
struct intel_context *ctx;
@@ -258,7 +257,7 @@ i915_gem_create_context(struct drm_device *dev,
}
}
- if (create_vm) {
+ if (USES_FULL_PPGTT(dev)) {
struct i915_hw_ppgtt *ppgtt = i915_ppgtt_create(dev, file_priv);
if (IS_ERR_OR_NULL(ppgtt)) {
@@ -337,7 +336,7 @@ int i915_gem_context_init(struct drm_device *dev)
}
}
- ctx = i915_gem_create_context(dev, NULL, USES_FULL_PPGTT(dev));
+ ctx = i915_gem_create_context(dev, NULL);
if (IS_ERR(ctx)) {
DRM_ERROR(Failed to create default global context (error
%ld)\n,
PTR_ERR(ctx));
@@ -438,7 +437,7 @@ int i915_gem_context_open(struct drm_device *dev, struct
drm_file *file)
idr_init(file_priv-context_idr);
mutex_lock(dev-struct_mutex);
- ctx = i915_gem_create_context(dev, file_priv, USES_FULL_PPGTT(dev));
+ ctx = i915_gem_create_context(dev, file_priv);
mutex_unlock(dev-struct_mutex);
if (IS_ERR(ctx)) {
@@ -696,7 +695,7 @@ int i915_gem_context_create_ioctl(struct drm_device *dev,
void *data,
if (ret)
return ret;
- ctx = i915_gem_create_context(dev, file_priv, USES_FULL_PPGTT(dev));
+ ctx = i915_gem_create_context(dev, file_priv);
mutex_unlock(dev-struct_mutex);
if (IS_ERR(ctx))
return PTR_ERR(ctx);
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/7] drm/i915: Only refcount ppgtt if it actually is one
This essentially unbreaks non-ppgtt operation where we'd scribble over
random memory.
While at it give the vm_to_ppgtt function a proper prefix and make it
a bit more paranoid.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_drv.h | 10 +-
drivers/gpu/drm/i915/i915_gem.c | 3 ++-
drivers/gpu/drm/i915/i915_gem_gtt.c | 3 ++-
3 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c783cfe5515d..fd3a99c5a1bd 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2460,6 +2460,15 @@ static inline bool i915_is_ggtt(struct
i915_address_space *vm)
return vm == ggtt;
}
+static inline struct i915_hw_ppgtt *
+i915_vm_to_ppgtt(struct i915_address_space *vm)
+{
+ WARN_ON(i915_is_ggtt(vm));
+
+ return container_of(vm, struct i915_hw_ppgtt, base);
+}
+
+
static inline bool i915_gem_obj_ggtt_bound(struct drm_i915_gem_object *obj)
{
return i915_gem_obj_bound(obj, obj_to_ggtt(obj));
@@ -2495,7 +2504,6 @@ void i915_gem_object_ggtt_unpin(struct
drm_i915_gem_object *obj);
/* i915_gem_context.c */
#define ctx_to_ppgtt(ctx) container_of((ctx)-vm, struct i915_hw_ppgtt, base)
-#define vm_to_ppgtt(vm) container_of(vm, struct i915_hw_ppgtt, base)
int __must_check i915_gem_context_init(struct drm_device *dev);
void i915_gem_context_fini(struct drm_device *dev);
void i915_gem_context_reset(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index b33a677b4b1e..c43ccfdf45a5 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4508,7 +4508,8 @@ void i915_gem_vma_destroy(struct i915_vma *vma)
vm = vma-vm;
- i915_ppgtt_put(vm_to_ppgtt(vm));
+ if (!i915_is_ggtt(vm))
+ i915_ppgtt_put(i915_vm_to_ppgtt(vm));
list_del(vma-vma_link);
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 83ee41e5c1c7..3753bf184865 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2204,7 +2204,8 @@ i915_gem_obj_lookup_or_create_vma(struct
drm_i915_gem_object *obj,
if (!vma)
vma = __i915_gem_vma_create(obj, vm);
- i915_ppgtt_get(vm_to_ppgtt(vm));
+ if (!i915_is_ggtt(vm))
+ i915_ppgtt_get(i915_vm_to_ppgtt(vm));
return vma;
}
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/7] drm/i915: Add proper prefix to obj_to_ggtt
Stuff in headers really aught to have this.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_drv.h | 11 ++-
drivers/gpu/drm/i915/i915_gem.c | 2 +-
2 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index fd3a99c5a1bd..0762e19f9bc6 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2451,7 +2451,7 @@ static inline bool i915_gem_obj_is_pinned(struct
drm_i915_gem_object *obj) {
}
/* Some GGTT VM helpers */
-#define obj_to_ggtt(obj) \
+#define i915_obj_to_ggtt(obj) \
(((struct drm_i915_private *)(obj)-base.dev-dev_private)-gtt.base)
static inline bool i915_is_ggtt(struct i915_address_space *vm)
{
@@ -2471,19 +2471,19 @@ i915_vm_to_ppgtt(struct i915_address_space *vm)
static inline bool i915_gem_obj_ggtt_bound(struct drm_i915_gem_object *obj)
{
- return i915_gem_obj_bound(obj, obj_to_ggtt(obj));
+ return i915_gem_obj_bound(obj, i915_obj_to_ggtt(obj));
}
static inline unsigned long
i915_gem_obj_ggtt_offset(struct drm_i915_gem_object *obj)
{
- return i915_gem_obj_offset(obj, obj_to_ggtt(obj));
+ return i915_gem_obj_offset(obj, i915_obj_to_ggtt(obj));
}
static inline unsigned long
i915_gem_obj_ggtt_size(struct drm_i915_gem_object *obj)
{
- return i915_gem_obj_size(obj, obj_to_ggtt(obj));
+ return i915_gem_obj_size(obj, i915_obj_to_ggtt(obj));
}
static inline int __must_check
@@ -2491,7 +2491,8 @@ i915_gem_obj_ggtt_pin(struct drm_i915_gem_object *obj,
uint32_t alignment,
unsigned flags)
{
- return i915_gem_object_pin(obj, obj_to_ggtt(obj), alignment, flags |
PIN_GLOBAL);
+ return i915_gem_object_pin(obj, i915_obj_to_ggtt(obj),
+ alignment, flags | PIN_GLOBAL);
}
static inline int
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index c43ccfdf45a5..f4e57fe05c6a 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5266,7 +5266,7 @@ struct i915_vma *i915_gem_obj_to_ggtt(struct
drm_i915_gem_object *obj)
return NULL;
vma = list_first_entry(obj-vma_list, typeof(*vma), vma_link);
- if (vma-vm != obj_to_ggtt(obj))
+ if (vma-vm != i915_obj_to_ggtt(obj))
return NULL;
return vma;
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 6/7] drm/i915: Only track real ppgtt for a context
There's a bit a confusion since we track the global gtt,
the aliasing and real ppgtt in the ctx-vm pointer. And not
all callers really bother to check for the different cases and just
presume that it points to a real ppgtt.
Now looking closely we don't actually need -vm to always point at an
address space - the only place that cares actually has fixup code
already to decide whether to look at the per-proces or the global
address space.
So switch to just tracking the ppgtt directly and ditch all the
extraneous code.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_debugfs.c| 2 +-
drivers/gpu/drm/i915/i915_drv.h| 3 +--
drivers/gpu/drm/i915/i915_gem_context.c| 28 +++-
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 5 +++--
drivers/gpu/drm/i915/i915_gpu_error.c | 10 +++---
5 files changed, 19 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 3bf1d20c598b..aaf07e230cb0 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1774,7 +1774,7 @@ static int per_file_ctx(int id, void *ptr, void *data)
{
struct intel_context *ctx = ptr;
struct seq_file *m = data;
- struct i915_hw_ppgtt *ppgtt = ctx_to_ppgtt(ctx);
+ struct i915_hw_ppgtt *ppgtt = ctx-ppgtt;
if (i915_gem_context_is_default(ctx))
seq_puts(m, default context:\n);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 0762e19f9bc6..3230b08aff13 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -616,7 +616,7 @@ struct intel_context {
uint8_t remap_slice;
struct drm_i915_file_private *file_priv;
struct i915_ctx_hang_stats hang_stats;
- struct i915_address_space *vm;
+ struct i915_hw_ppgtt *ppgtt;
struct {
struct drm_i915_gem_object *rcs_state;
@@ -2504,7 +2504,6 @@ i915_gem_object_ggtt_unbind(struct drm_i915_gem_object
*obj)
void i915_gem_object_ggtt_unpin(struct drm_i915_gem_object *obj);
/* i915_gem_context.c */
-#define ctx_to_ppgtt(ctx) container_of((ctx)-vm, struct i915_hw_ppgtt, base)
int __must_check i915_gem_context_init(struct drm_device *dev);
void i915_gem_context_fini(struct drm_device *dev);
void i915_gem_context_reset(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 7a455fcee3a7..c00e5d027774 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -136,15 +136,8 @@ void i915_gem_context_free(struct kref *ctx_ref)
{
struct intel_context *ctx = container_of(ctx_ref,
typeof(*ctx), ref);
- struct i915_hw_ppgtt *ppgtt = NULL;
- if (ctx-legacy_hw_ctx.rcs_state) {
- /* We refcount even the aliasing PPGTT to keep the code
symmetric */
- if (USES_PPGTT(ctx-legacy_hw_ctx.rcs_state-base.dev))
- ppgtt = ctx_to_ppgtt(ctx);
- }
-
- i915_ppgtt_put(ppgtt);
+ i915_ppgtt_put(ctx-ppgtt);
if (ctx-legacy_hw_ctx.rcs_state)
drm_gem_object_unreference(ctx-legacy_hw_ctx.rcs_state-base);
list_del(ctx-link);
@@ -240,7 +233,6 @@ i915_gem_create_context(struct drm_device *dev,
bool create_vm)
{
const bool is_global_default_ctx = file_priv == NULL;
- struct drm_i915_private *dev_priv = dev-dev_private;
struct intel_context *ctx;
int ret = 0;
@@ -274,15 +266,10 @@ i915_gem_create_context(struct drm_device *dev,
PTR_ERR(ppgtt));
ret = PTR_ERR(ppgtt);
goto err_unpin;
- } else
- ctx-vm = ppgtt-base;
- } else if (USES_PPGTT(dev)) {
- /* For platforms which only have aliasing PPGTT, we fake the
-* address space and refcounting. */
- ctx-vm = dev_priv-mm.aliasing_ppgtt-base;
- i915_ppgtt_get(dev_priv-mm.aliasing_ppgtt);
- } else
- ctx-vm = dev_priv-gtt.base;
+ }
+
+ ctx-ppgtt = ppgtt;
+ }
return ctx;
@@ -538,7 +525,6 @@ static int do_switch(struct intel_engine_cs *ring,
{
struct drm_i915_private *dev_priv = ring-dev-dev_private;
struct intel_context *from = ring-last_context;
- struct i915_hw_ppgtt *ppgtt = ctx_to_ppgtt(to);
u32 hw_flags = 0;
bool uninitialized = false;
int ret, i;
@@ -566,8 +552,8 @@ static int do_switch(struct intel_engine_cs *ring,
*/
from = ring-last_context;
- if (USES_FULL_PPGTT(ring-dev)) {
- ret = ppgtt-switch_mm(ppgtt, ring, false);
+ if (to-ppgtt) {
+
[Intel-gfx] [PATCH 5/7] drm/i915: Initialize the aliasing ppgtt as part of global gtt
Stuffing this into the context setup code doesn't make a lot of sense.
Also reusing the real ppgtt setup code makes even less sense since the
aliasing ppgtt isn't a real address space. Leaving all that stuff
unitialized will make sure that we catch any abusers promptly.
This is also a prep work to clean up the context-ppgtt link.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_gem_context.c | 13 +
drivers/gpu/drm/i915/i915_gem_gtt.c | 31 +--
2 files changed, 26 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 3b8367aa8404..7a455fcee3a7 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -276,17 +276,6 @@ i915_gem_create_context(struct drm_device *dev,
goto err_unpin;
} else
ctx-vm = ppgtt-base;
-
- /* This case is reserved for the global default context and
-* should only happen once. */
- if (is_global_default_ctx) {
- if (WARN_ON(dev_priv-mm.aliasing_ppgtt)) {
- ret = -EEXIST;
- goto err_unpin;
- }
-
- dev_priv-mm.aliasing_ppgtt = ppgtt;
- }
} else if (USES_PPGTT(dev)) {
/* For platforms which only have aliasing PPGTT, we fake the
* address space and refcounting. */
@@ -361,7 +350,7 @@ int i915_gem_context_init(struct drm_device *dev)
}
}
- ctx = i915_gem_create_context(dev, NULL, USES_PPGTT(dev));
+ ctx = i915_gem_create_context(dev, NULL, USES_FULL_PPGTT(dev));
if (IS_ERR(ctx)) {
DRM_ERROR(Failed to create default global context (error
%ld)\n,
PTR_ERR(ctx));
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 4fa7807ed4d5..cb9bb13ff20a 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -1191,23 +1191,27 @@ static int gen6_ppgtt_init(struct i915_hw_ppgtt *ppgtt)
return 0;
}
-int i915_ppgtt_init(struct drm_device *dev, struct i915_hw_ppgtt *ppgtt)
+int __hw_ppgtt_init(struct drm_device *dev, struct i915_hw_ppgtt *ppgtt)
{
struct drm_i915_private *dev_priv = dev-dev_private;
- int ret = 0;
ppgtt-base.dev = dev;
ppgtt-base.scratch = dev_priv-gtt.base.scratch;
if (INTEL_INFO(dev)-gen 8)
- ret = gen6_ppgtt_init(ppgtt);
+ return gen6_ppgtt_init(ppgtt);
else if (IS_GEN8(dev))
- ret = gen8_ppgtt_init(ppgtt, dev_priv-gtt.base.total);
+ return gen8_ppgtt_init(ppgtt, dev_priv-gtt.base.total);
else
BUG();
+}
+int i915_ppgtt_init(struct drm_device *dev, struct i915_hw_ppgtt *ppgtt)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ int ret = 0;
+ ret = __hw_ppgtt_init(dev, ppgtt);
if (!ret) {
- struct drm_i915_private *dev_priv = dev-dev_private;
kref_init(ppgtt-ref);
drm_mm_init(ppgtt-base.mm, ppgtt-base.start,
ppgtt-base.total);
@@ -1728,6 +1732,7 @@ int i915_gem_setup_global_gtt(struct drm_device *dev,
struct drm_mm_node *entry;
struct drm_i915_gem_object *obj;
unsigned long hole_start, hole_end;
+ int ret;
BUG_ON(mappable_end end);
@@ -1739,7 +1744,7 @@ int i915_gem_setup_global_gtt(struct drm_device *dev,
/* Mark any preallocated objects as occupied */
list_for_each_entry(obj, dev_priv-mm.bound_list, global_list) {
struct i915_vma *vma = i915_gem_obj_to_vma(obj, ggtt_vm);
- int ret;
+
DRM_DEBUG_KMS(reserving preallocated space: %lx + %zx\n,
i915_gem_obj_ggtt_offset(obj), obj-base.size);
@@ -1766,6 +1771,20 @@ int i915_gem_setup_global_gtt(struct drm_device *dev,
/* And finally clear the reserved guard page */
ggtt_vm-clear_range(ggtt_vm, end - PAGE_SIZE, PAGE_SIZE, true);
+ if (HAS_ALIASING_PPGTT(dev) USES_FULL_PPGTT(dev)) {
+ struct i915_hw_ppgtt *ppgtt;
+
+ ppgtt = kzalloc(sizeof(*ppgtt), GFP_KERNEL);
+ if (!ppgtt)
+ return -ENOMEM;
+
+ ret = __hw_ppgtt_init(dev, ppgtt);
+ if (!ret)
+ return ret;
+
+ dev_priv-mm.aliasing_ppgtt = ppgtt;
+ }
+
return 0;
}
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/7] drm/i915: Only track real ppgtt for a context
On Wed, Jul 30, 2014 at 09:42:03PM +0200, Daniel Vetter wrote:
There's a bit a confusion since we track the global gtt,
the aliasing and real ppgtt in the ctx-vm pointer. And not
all callers really bother to check for the different cases and just
presume that it points to a real ppgtt.
Now looking closely we don't actually need -vm to always point at an
address space - the only place that cares actually has fixup code
already to decide whether to look at the per-proces or the global
address space.
So switch to just tracking the ppgtt directly and ditch all the
extraneous code.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
Jesse looked up the Jira for this one for me, so
OTC-Jira: VIZ-3724
Cheers, Daniel
---
drivers/gpu/drm/i915/i915_debugfs.c| 2 +-
drivers/gpu/drm/i915/i915_drv.h| 3 +--
drivers/gpu/drm/i915/i915_gem_context.c| 28 +++-
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 5 +++--
drivers/gpu/drm/i915/i915_gpu_error.c | 10 +++---
5 files changed, 19 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 3bf1d20c598b..aaf07e230cb0 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1774,7 +1774,7 @@ static int per_file_ctx(int id, void *ptr, void *data)
{
struct intel_context *ctx = ptr;
struct seq_file *m = data;
- struct i915_hw_ppgtt *ppgtt = ctx_to_ppgtt(ctx);
+ struct i915_hw_ppgtt *ppgtt = ctx-ppgtt;
if (i915_gem_context_is_default(ctx))
seq_puts(m, default context:\n);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 0762e19f9bc6..3230b08aff13 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -616,7 +616,7 @@ struct intel_context {
uint8_t remap_slice;
struct drm_i915_file_private *file_priv;
struct i915_ctx_hang_stats hang_stats;
- struct i915_address_space *vm;
+ struct i915_hw_ppgtt *ppgtt;
struct {
struct drm_i915_gem_object *rcs_state;
@@ -2504,7 +2504,6 @@ i915_gem_object_ggtt_unbind(struct drm_i915_gem_object
*obj)
void i915_gem_object_ggtt_unpin(struct drm_i915_gem_object *obj);
/* i915_gem_context.c */
-#define ctx_to_ppgtt(ctx) container_of((ctx)-vm, struct i915_hw_ppgtt, base)
int __must_check i915_gem_context_init(struct drm_device *dev);
void i915_gem_context_fini(struct drm_device *dev);
void i915_gem_context_reset(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 7a455fcee3a7..c00e5d027774 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -136,15 +136,8 @@ void i915_gem_context_free(struct kref *ctx_ref)
{
struct intel_context *ctx = container_of(ctx_ref,
typeof(*ctx), ref);
- struct i915_hw_ppgtt *ppgtt = NULL;
- if (ctx-legacy_hw_ctx.rcs_state) {
- /* We refcount even the aliasing PPGTT to keep the code
symmetric */
- if (USES_PPGTT(ctx-legacy_hw_ctx.rcs_state-base.dev))
- ppgtt = ctx_to_ppgtt(ctx);
- }
-
- i915_ppgtt_put(ppgtt);
+ i915_ppgtt_put(ctx-ppgtt);
if (ctx-legacy_hw_ctx.rcs_state)
drm_gem_object_unreference(ctx-legacy_hw_ctx.rcs_state-base);
list_del(ctx-link);
@@ -240,7 +233,6 @@ i915_gem_create_context(struct drm_device *dev,
bool create_vm)
{
const bool is_global_default_ctx = file_priv == NULL;
- struct drm_i915_private *dev_priv = dev-dev_private;
struct intel_context *ctx;
int ret = 0;
@@ -274,15 +266,10 @@ i915_gem_create_context(struct drm_device *dev,
PTR_ERR(ppgtt));
ret = PTR_ERR(ppgtt);
goto err_unpin;
- } else
- ctx-vm = ppgtt-base;
- } else if (USES_PPGTT(dev)) {
- /* For platforms which only have aliasing PPGTT, we fake the
- * address space and refcounting. */
- ctx-vm = dev_priv-mm.aliasing_ppgtt-base;
- i915_ppgtt_get(dev_priv-mm.aliasing_ppgtt);
- } else
- ctx-vm = dev_priv-gtt.base;
+ }
+
+ ctx-ppgtt = ppgtt;
+ }
return ctx;
@@ -538,7 +525,6 @@ static int do_switch(struct intel_engine_cs *ring,
{
struct drm_i915_private *dev_priv = ring-dev-dev_private;
struct intel_context *from = ring-last_context;
- struct i915_hw_ppgtt *ppgtt = ctx_to_ppgtt(to);
u32 hw_flags = 0;
bool uninitialized = false;
int ret, i;
@@ -566,8 +552,8 @@ static int do_switch(struct intel_engine_cs *ring,
*/
from =
[Intel-gfx] [PATCH 1/2] drm/i915: Introduce FBC False Color for debug purposes.
With this bit enabled, HW changes the color when compressing frames for
debug purposes.
ALthough the simple way to enable a single bit is over intel_reg_write,
this value is overwriten on next update_fbc so depending on the workload
it is not possible to set this bit with intel-gpu-tools. So this patch
introduces a persistent way to enable false color over debugfs.
v2: Use DEFINE_SIMPLE_ATTRIBUTE as Daniel suggested
v3: (Ville) only do false color for IVB+ since according to spec bit is
MBZ before IVB.
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Cc: Ben Widawsky b...@bwidawsk.net
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 42 +
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_pm.c | 3 +++
4 files changed, 48 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 9e737b7..bcfdc00 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1433,6 +1433,47 @@ static int i915_fbc_status(struct seq_file *m, void
*unused)
return 0;
}
+static int i915_fbc_fc_get(void *data, u64 *val)
+{
+ struct drm_device *dev = data;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+
+ if (INTEL_INFO(dev)-gen 7)
+ return -ENODEV;
+
+ drm_modeset_lock_all(dev);
+ *val = dev_priv-fbc.false_color;
+ drm_modeset_unlock_all(dev);
+
+ return 0;
+}
+
+static int i915_fbc_fc_set(void *data, u64 val)
+{
+ struct drm_device *dev = data;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ u32 reg;
+
+ if (INTEL_INFO(dev)-gen 7)
+ return -ENODEV;
+
+ drm_modeset_lock_all(dev);
+
+ reg = I915_READ(ILK_DPFC_CONTROL);
+ dev_priv-fbc.false_color = val;
+
+ I915_WRITE(ILK_DPFC_CONTROL, val ?
+ (reg | FBC_CTL_FALSE_COLOR) :
+ (reg ~FBC_CTL_FALSE_COLOR));
+
+ drm_modeset_unlock_all(dev);
+ return 0;
+}
+
+DEFINE_SIMPLE_ATTRIBUTE(i915_fbc_fc_fops,
+ i915_fbc_fc_get, i915_fbc_fc_set,
+ %llu\n);
+
static int i915_ips_status(struct seq_file *m, void *unused)
{
struct drm_info_node *node = m-private;
@@ -3957,6 +3998,7 @@ static const struct i915_debugfs_files {
{i915_pri_wm_latency, i915_pri_wm_latency_fops},
{i915_spr_wm_latency, i915_spr_wm_latency_fops},
{i915_cur_wm_latency, i915_cur_wm_latency_fops},
+ {i915_fbc_false_color, i915_fbc_fc_fops},
};
void intel_display_crc_init(struct drm_device *dev)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 18c9ad8..3018bf5 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -636,6 +636,8 @@ struct i915_fbc {
struct drm_mm_node compressed_fb;
struct drm_mm_node *compressed_llb;
+ bool false_color;
+
struct intel_fbc_work {
struct delayed_work work;
struct drm_crtc *crtc;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 28e21ed..b5d295a 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1540,6 +1540,7 @@ enum punit_power_well {
/* Framebuffer compression for Ironlake */
#define ILK_DPFC_CB_BASE 0x43200
#define ILK_DPFC_CONTROL 0x43208
+#define FBC_CTL_FALSE_COLOR (110)
/* The bit 28-8 is reserved */
#define DPFC_RESERVED(0x1F00)
#define ILK_DPFC_RECOMP_CTL0x4320c
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 1ddd4df..338a80b 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -309,6 +309,9 @@ static void gen7_enable_fbc(struct drm_crtc *crtc)
dpfc_ctl |= IVB_DPFC_CTL_FENCE_EN;
+ if (dev_priv-fbc.false_color)
+ dpfc_ctl |= FBC_CTL_FALSE_COLOR;
+
I915_WRITE(ILK_DPFC_CONTROL, dpfc_ctl | DPFC_CTL_EN);
if (IS_IVYBRIDGE(dev)) {
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: FBC flush nuke for BDW
According to spec FBC on BDW and HSW are identical without any gaps. So let's copy the nuke and let FBC really start compressing stuff. Without this patch we can verify with false color that nothing is being compressed. With the nuke in place and false color it is possible to see false color debugs. Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com --- drivers/gpu/drm/i915/intel_ringbuffer.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c index b3d8f76..3e06a1b 100644 --- a/drivers/gpu/drm/i915/intel_ringbuffer.c +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c @@ -416,6 +416,9 @@ gen8_render_ring_flush(struct intel_engine_cs *ring, intel_ring_emit(ring, 0); intel_ring_advance(ring); + if (!invalidate_domains flush_domains) + return gen7_ring_fbc_flush(ring, FBC_REND_NUKE); + return 0; } @@ -2058,7 +2061,7 @@ static int gen6_ring_flush(struct intel_engine_cs *ring, } intel_ring_advance(ring); - if (IS_GEN7(dev) !invalidate flush) + if (INTEL_INFO(dev)-gen = 7 !invalidate flush) return gen7_ring_fbc_flush(ring, FBC_REND_CACHE_CLEAN); return 0; -- 1.9.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Add a bit of locking to intel_dp_hpd_pulse()
-hpd_pulse() is called from a workqueue via an interrupt so it happens asynchronously with modesets. Grab the connection_mutex in intel_dp_hpd_pulse() to avoid disturbing on angoing modeset with parallel hpd processing. Nope, not right, we need to lock just not that amount of stuff, since MST won't work anymore, since it relies on hpd irqs while other threads are holding the locks to talk to the remote devices. I also think we shouldn't be locking the the irq processing in intel_dp_check_link_status. On my IVB turning off the port during a modeset could result in a hpd which would then proceed to link train while the modeset was still happening. Suffice to say that didn't go so well. Does this not point to an ordering issue somewhere, we've turned off the port, but the device thinks the link should be trained but it currently isn't? maybe intel_dp_check_link_status needs to be smarter about something but we should be able to process the irqs fine without locking the modesetting locks. Or maybe we need to know that we don't want the link trained so don't retrain when the remote device signals a link status problem. Daniel, the only way intel_dp-is_mst can get reset is inside this path. Dave. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Skip Stolen Memory first page.
WA to skip the first page of stolen memory due to sporadic HW write on *CS Idle
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
drivers/gpu/drm/i915/i915_gem_stolen.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c
b/drivers/gpu/drm/i915/i915_gem_stolen.c
index 21c025a..3acefb3 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -290,6 +290,7 @@ int i915_gem_init_stolen(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
int bios_reserved = 0;
+ int initial_reserved = 0;
#ifdef CONFIG_INTEL_IOMMU
if (intel_iommu_gfx_mapped INTEL_INFO(dev)-gen 8) {
@@ -314,9 +315,13 @@ int i915_gem_init_stolen(struct drm_device *dev)
if (WARN_ON(bios_reserved dev_priv-gtt.stolen_size))
return 0;
+ /* WaSkipStolenMemoryFirstPage */
+ if (INTEL_INFO(dev)-gen = 8)
+ initial_reserved = 4096;
+
/* Basic memrange allocator for stolen space */
- drm_mm_init(dev_priv-mm.stolen, 0, dev_priv-gtt.stolen_size -
- bios_reserved);
+ drm_mm_init(dev_priv-mm.stolen, initial_reserved,
+ dev_priv-gtt.stolen_size - bios_reserved);
return 0;
}
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/8] drm/irq: Implement a generic vblank_wait function
On 31.07.2014 00:21, Thierry Reding wrote:
On Wed, Jul 30, 2014 at 05:36:21PM +0300, Ville Syrjälä wrote:
On Wed, Jul 30, 2014 at 04:20:25PM +0200, Thierry Reding wrote:
On Wed, Jul 30, 2014 at 05:32:28PM +0900, Michel Dänzer wrote:
On 30.07.2014 17:22, Daniel Vetter wrote:
On Wed, Jul 30, 2014 at 11:59:33AM +0900, Michel Dänzer wrote:
On 30.07.2014 06:32, Daniel Vetter wrote:
+ * due to lack of driver support or because the crtc is off.
+ */
+void drm_crtc_vblank_wait(struct drm_crtc *crtc)
+{
+ drm_vblank_wait(crtc-dev, drm_crtc_index(crtc));
+}
+EXPORT_SYMBOL(drm_crtc_vblank_wait);
+
+/**
Maybe the function names should be *_vblank_wait_next() or something to
clarify the purpose and reduce potential confusion versus
drm_wait_vblank().
Yeah that name is just transferred from the i915 driver. What about
drm_wait_one_vblank()/drm_crtc_wait_one_vblank()?
I don't care that much :), go ahead.
Just my two cents: our downstream kernel has a helper somewhat like this
which waits for a specified number of frames (apparently this is useful
for some panels that require up to 5 or 6 frames before they display the
correct image on screen). So perhaps something like this could work:
void drm_wait_vblank_count(struct drm_device *dev, unsigned int crtc,
unsigned int count)
{
u32 last;
int ret;
ret = drm_vblank_get(dev, crtc);
if (WARN_ON(ret))
return;
while (count--) {
last = drm_vblank_count(dev, crtc);
...
}
drm_vblank_put(dev, crtc);
}
Would be nicer to wait for an absolute vblank count instead IMO. Or
if you want to pass a relative count in just convert it to an absolute
count first and wait for it (taking wraparound into account obviously).
Hmm... would something like this work?
target = drm_vblank_count(dev, crtc) + count;
ret = wait_event_timeout(...,
drm_vblank_count(dev, crtc) == target,
...);
That should properly take into account wrap-around given that both sites
use drm_vblank_count().
I think it would be better to refactor drm_wait_vblank() than to
reinvent it.
--
Earthling Michel Dänzer| http://www.amd.com
Libre software enthusiast |Mesa and X developer
signature.asc
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/7] drm/i915: Initialize the aliasing ppgtt as part of global gtt
1386367941-7131-76-git-send-email-benjamin.widaw...@intel.com
On Wed, Jul 30, 2014 at 09:42:02PM +0200, Daniel Vetter wrote:
Stuffing this into the context setup code doesn't make a lot of sense.
Also reusing the real ppgtt setup code makes even less sense since the
aliasing ppgtt isn't a real address space. Leaving all that stuff
unitialized will make sure that we catch any abusers promptly.
This is also a prep work to clean up the context-ppgtt link.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_gem_context.c | 13 +
drivers/gpu/drm/i915/i915_gem_gtt.c | 31 +--
2 files changed, 26 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 3b8367aa8404..7a455fcee3a7 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -276,17 +276,6 @@ i915_gem_create_context(struct drm_device *dev,
goto err_unpin;
} else
ctx-vm = ppgtt-base;
-
- /* This case is reserved for the global default context and
- * should only happen once. */
- if (is_global_default_ctx) {
- if (WARN_ON(dev_priv-mm.aliasing_ppgtt)) {
- ret = -EEXIST;
- goto err_unpin;
- }
-
- dev_priv-mm.aliasing_ppgtt = ppgtt;
- }
} else if (USES_PPGTT(dev)) {
/* For platforms which only have aliasing PPGTT, we fake the
* address space and refcounting. */
@@ -361,7 +350,7 @@ int i915_gem_context_init(struct drm_device *dev)
}
}
- ctx = i915_gem_create_context(dev, NULL, USES_PPGTT(dev));
+ ctx = i915_gem_create_context(dev, NULL, USES_FULL_PPGTT(dev));
if (IS_ERR(ctx)) {
DRM_ERROR(Failed to create default global context (error
%ld)\n,
PTR_ERR(ctx));
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 4fa7807ed4d5..cb9bb13ff20a 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -1191,23 +1191,27 @@ static int gen6_ppgtt_init(struct i915_hw_ppgtt
*ppgtt)
return 0;
}
-int i915_ppgtt_init(struct drm_device *dev, struct i915_hw_ppgtt *ppgtt)
+int __hw_ppgtt_init(struct drm_device *dev, struct i915_hw_ppgtt *ppgtt)
{
struct drm_i915_private *dev_priv = dev-dev_private;
- int ret = 0;
ppgtt-base.dev = dev;
ppgtt-base.scratch = dev_priv-gtt.base.scratch;
if (INTEL_INFO(dev)-gen 8)
- ret = gen6_ppgtt_init(ppgtt);
+ return gen6_ppgtt_init(ppgtt);
else if (IS_GEN8(dev))
- ret = gen8_ppgtt_init(ppgtt, dev_priv-gtt.base.total);
+ return gen8_ppgtt_init(ppgtt, dev_priv-gtt.base.total);
else
BUG();
+}
+int i915_ppgtt_init(struct drm_device *dev, struct i915_hw_ppgtt *ppgtt)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ int ret = 0;
+ ret = __hw_ppgtt_init(dev, ppgtt);
if (!ret) {
- struct drm_i915_private *dev_priv = dev-dev_private;
kref_init(ppgtt-ref);
drm_mm_init(ppgtt-base.mm, ppgtt-base.start,
ppgtt-base.total);
@@ -1728,6 +1732,7 @@ int i915_gem_setup_global_gtt(struct drm_device *dev,
struct drm_mm_node *entry;
struct drm_i915_gem_object *obj;
unsigned long hole_start, hole_end;
+ int ret;
BUG_ON(mappable_end end);
@@ -1739,7 +1744,7 @@ int i915_gem_setup_global_gtt(struct drm_device *dev,
/* Mark any preallocated objects as occupied */
list_for_each_entry(obj, dev_priv-mm.bound_list, global_list) {
struct i915_vma *vma = i915_gem_obj_to_vma(obj, ggtt_vm);
- int ret;
+
DRM_DEBUG_KMS(reserving preallocated space: %lx + %zx\n,
i915_gem_obj_ggtt_offset(obj), obj-base.size);
@@ -1766,6 +1771,20 @@ int i915_gem_setup_global_gtt(struct drm_device *dev,
/* And finally clear the reserved guard page */
ggtt_vm-clear_range(ggtt_vm, end - PAGE_SIZE, PAGE_SIZE, true);
+ if (HAS_ALIASING_PPGTT(dev) USES_FULL_PPGTT(dev)) {
+ struct i915_hw_ppgtt *ppgtt;
+
+ ppgtt = kzalloc(sizeof(*ppgtt), GFP_KERNEL);
+ if (!ppgtt)
+ return -ENOMEM;
+
+ ret = __hw_ppgtt_init(dev, ppgtt);
+ if (!ret)
+ return ret;
+
+ dev_priv-mm.aliasing_ppgtt = ppgtt;
+ }
+
return 0;
}
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
Re: [Intel-gfx] [PATCH 5/7] drm/i915: Initialize the aliasing ppgtt as part of global gtt
On Wed, Jul 30, 2014 at 08:46:11PM -0700, Ben Widawsky wrote:
1386367941-7131-76-git-send-email-benjamin.widaw...@intel.com
and
1386367941-7131-81-git-send-email-benjamin.widaw...@intel.com
On Wed, Jul 30, 2014 at 09:42:02PM +0200, Daniel Vetter wrote:
Stuffing this into the context setup code doesn't make a lot of sense.
Also reusing the real ppgtt setup code makes even less sense since the
aliasing ppgtt isn't a real address space. Leaving all that stuff
unitialized will make sure that we catch any abusers promptly.
This is also a prep work to clean up the context-ppgtt link.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_gem_context.c | 13 +
drivers/gpu/drm/i915/i915_gem_gtt.c | 31
+--
2 files changed, 26 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 3b8367aa8404..7a455fcee3a7 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -276,17 +276,6 @@ i915_gem_create_context(struct drm_device *dev,
goto err_unpin;
} else
ctx-vm = ppgtt-base;
-
- /* This case is reserved for the global default context and
-* should only happen once. */
- if (is_global_default_ctx) {
- if (WARN_ON(dev_priv-mm.aliasing_ppgtt)) {
- ret = -EEXIST;
- goto err_unpin;
- }
-
- dev_priv-mm.aliasing_ppgtt = ppgtt;
- }
} else if (USES_PPGTT(dev)) {
/* For platforms which only have aliasing PPGTT, we fake the
* address space and refcounting. */
@@ -361,7 +350,7 @@ int i915_gem_context_init(struct drm_device *dev)
}
}
- ctx = i915_gem_create_context(dev, NULL, USES_PPGTT(dev));
+ ctx = i915_gem_create_context(dev, NULL, USES_FULL_PPGTT(dev));
if (IS_ERR(ctx)) {
DRM_ERROR(Failed to create default global context (error
%ld)\n,
PTR_ERR(ctx));
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 4fa7807ed4d5..cb9bb13ff20a 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -1191,23 +1191,27 @@ static int gen6_ppgtt_init(struct i915_hw_ppgtt
*ppgtt)
return 0;
}
-int i915_ppgtt_init(struct drm_device *dev, struct i915_hw_ppgtt *ppgtt)
+int __hw_ppgtt_init(struct drm_device *dev, struct i915_hw_ppgtt *ppgtt)
{
struct drm_i915_private *dev_priv = dev-dev_private;
- int ret = 0;
ppgtt-base.dev = dev;
ppgtt-base.scratch = dev_priv-gtt.base.scratch;
if (INTEL_INFO(dev)-gen 8)
- ret = gen6_ppgtt_init(ppgtt);
+ return gen6_ppgtt_init(ppgtt);
else if (IS_GEN8(dev))
- ret = gen8_ppgtt_init(ppgtt, dev_priv-gtt.base.total);
+ return gen8_ppgtt_init(ppgtt, dev_priv-gtt.base.total);
else
BUG();
+}
+int i915_ppgtt_init(struct drm_device *dev, struct i915_hw_ppgtt *ppgtt)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ int ret = 0;
+ ret = __hw_ppgtt_init(dev, ppgtt);
if (!ret) {
- struct drm_i915_private *dev_priv = dev-dev_private;
kref_init(ppgtt-ref);
drm_mm_init(ppgtt-base.mm, ppgtt-base.start,
ppgtt-base.total);
@@ -1728,6 +1732,7 @@ int i915_gem_setup_global_gtt(struct drm_device *dev,
struct drm_mm_node *entry;
struct drm_i915_gem_object *obj;
unsigned long hole_start, hole_end;
+ int ret;
BUG_ON(mappable_end end);
@@ -1739,7 +1744,7 @@ int i915_gem_setup_global_gtt(struct drm_device *dev,
/* Mark any preallocated objects as occupied */
list_for_each_entry(obj, dev_priv-mm.bound_list, global_list) {
struct i915_vma *vma = i915_gem_obj_to_vma(obj, ggtt_vm);
- int ret;
+
DRM_DEBUG_KMS(reserving preallocated space: %lx + %zx\n,
i915_gem_obj_ggtt_offset(obj), obj-base.size);
@@ -1766,6 +1771,20 @@ int i915_gem_setup_global_gtt(struct drm_device *dev,
/* And finally clear the reserved guard page */
ggtt_vm-clear_range(ggtt_vm, end - PAGE_SIZE, PAGE_SIZE, true);
+ if (HAS_ALIASING_PPGTT(dev) USES_FULL_PPGTT(dev)) {
+ struct i915_hw_ppgtt *ppgtt;
+
+ ppgtt = kzalloc(sizeof(*ppgtt), GFP_KERNEL);
+ if (!ppgtt)
+ return -ENOMEM;
+
+ ret = __hw_ppgtt_init(dev, ppgtt);
+ if (!ret)
+ return ret;
+
+ dev_priv-mm.aliasing_ppgtt = ppgtt;
+ }
+
return 0;
}
Re: [Intel-gfx] [PATCH 5/7] drm/i915: Initialize the aliasing ppgtt as part of global gtt
On Wed, Jul 30, 2014 at 08:47:03PM -0700, Ben Widawsky wrote:
On Wed, Jul 30, 2014 at 08:46:11PM -0700, Ben Widawsky wrote:
1386367941-7131-76-git-send-email-benjamin.widaw...@intel.com
and
1386367941-7131-81-git-send-email-benjamin.widaw...@intel.com
Oops, was looking at the wrong this actually. Ignore please.
On Wed, Jul 30, 2014 at 09:42:02PM +0200, Daniel Vetter wrote:
Stuffing this into the context setup code doesn't make a lot of sense.
Also reusing the real ppgtt setup code makes even less sense since the
aliasing ppgtt isn't a real address space. Leaving all that stuff
unitialized will make sure that we catch any abusers promptly.
This is also a prep work to clean up the context-ppgtt link.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_gem_context.c | 13 +
drivers/gpu/drm/i915/i915_gem_gtt.c | 31
+--
2 files changed, 26 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 3b8367aa8404..7a455fcee3a7 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -276,17 +276,6 @@ i915_gem_create_context(struct drm_device *dev,
goto err_unpin;
} else
ctx-vm = ppgtt-base;
-
- /* This case is reserved for the global default context and
- * should only happen once. */
- if (is_global_default_ctx) {
- if (WARN_ON(dev_priv-mm.aliasing_ppgtt)) {
- ret = -EEXIST;
- goto err_unpin;
- }
-
- dev_priv-mm.aliasing_ppgtt = ppgtt;
- }
} else if (USES_PPGTT(dev)) {
/* For platforms which only have aliasing PPGTT, we fake the
* address space and refcounting. */
@@ -361,7 +350,7 @@ int i915_gem_context_init(struct drm_device *dev)
}
}
- ctx = i915_gem_create_context(dev, NULL, USES_PPGTT(dev));
+ ctx = i915_gem_create_context(dev, NULL, USES_FULL_PPGTT(dev));
if (IS_ERR(ctx)) {
DRM_ERROR(Failed to create default global context (error
%ld)\n,
PTR_ERR(ctx));
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 4fa7807ed4d5..cb9bb13ff20a 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -1191,23 +1191,27 @@ static int gen6_ppgtt_init(struct i915_hw_ppgtt
*ppgtt)
return 0;
}
-int i915_ppgtt_init(struct drm_device *dev, struct i915_hw_ppgtt *ppgtt)
+int __hw_ppgtt_init(struct drm_device *dev, struct i915_hw_ppgtt *ppgtt)
{
struct drm_i915_private *dev_priv = dev-dev_private;
- int ret = 0;
ppgtt-base.dev = dev;
ppgtt-base.scratch = dev_priv-gtt.base.scratch;
if (INTEL_INFO(dev)-gen 8)
- ret = gen6_ppgtt_init(ppgtt);
+ return gen6_ppgtt_init(ppgtt);
else if (IS_GEN8(dev))
- ret = gen8_ppgtt_init(ppgtt, dev_priv-gtt.base.total);
+ return gen8_ppgtt_init(ppgtt, dev_priv-gtt.base.total);
else
BUG();
+}
+int i915_ppgtt_init(struct drm_device *dev, struct i915_hw_ppgtt *ppgtt)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ int ret = 0;
+ ret = __hw_ppgtt_init(dev, ppgtt);
if (!ret) {
- struct drm_i915_private *dev_priv = dev-dev_private;
kref_init(ppgtt-ref);
drm_mm_init(ppgtt-base.mm, ppgtt-base.start,
ppgtt-base.total);
@@ -1728,6 +1732,7 @@ int i915_gem_setup_global_gtt(struct drm_device
*dev,
struct drm_mm_node *entry;
struct drm_i915_gem_object *obj;
unsigned long hole_start, hole_end;
+ int ret;
BUG_ON(mappable_end end);
@@ -1739,7 +1744,7 @@ int i915_gem_setup_global_gtt(struct drm_device
*dev,
/* Mark any preallocated objects as occupied */
list_for_each_entry(obj, dev_priv-mm.bound_list, global_list) {
struct i915_vma *vma = i915_gem_obj_to_vma(obj, ggtt_vm);
- int ret;
+
DRM_DEBUG_KMS(reserving preallocated space: %lx + %zx\n,
i915_gem_obj_ggtt_offset(obj), obj-base.size);
@@ -1766,6 +1771,20 @@ int i915_gem_setup_global_gtt(struct drm_device
*dev,
/* And finally clear the reserved guard page */
ggtt_vm-clear_range(ggtt_vm, end - PAGE_SIZE, PAGE_SIZE, true);
+ if (HAS_ALIASING_PPGTT(dev) USES_FULL_PPGTT(dev)) {
+ struct i915_hw_ppgtt *ppgtt;
+
+ ppgtt = kzalloc(sizeof(*ppgtt), GFP_KERNEL);
+ if (!ppgtt)
+ return -ENOMEM;
+
+ ret = __hw_ppgtt_init(dev, ppgtt);
+
Re: [Intel-gfx] [PATCH] drm/i915: Skip Stolen Memory first page.
On Wed, Jul 30, 2014 at 10:47:46AM -0700, Rodrigo Vivi wrote:
WA to skip the first page of stolen memory due to sporadic HW write on *CS
Idle
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
drivers/gpu/drm/i915/i915_gem_stolen.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c
b/drivers/gpu/drm/i915/i915_gem_stolen.c
index 21c025a..3acefb3 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -290,6 +290,7 @@ int i915_gem_init_stolen(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
int bios_reserved = 0;
+ int initial_reserved = 0;
#ifdef CONFIG_INTEL_IOMMU
if (intel_iommu_gfx_mapped INTEL_INFO(dev)-gen 8) {
@@ -314,9 +315,13 @@ int i915_gem_init_stolen(struct drm_device *dev)
if (WARN_ON(bios_reserved dev_priv-gtt.stolen_size))
return 0;
+ /* WaSkipStolenMemoryFirstPage */
+ if (INTEL_INFO(dev)-gen = 8)
+ initial_reserved = 4096;
+
/* Basic memrange allocator for stolen space */
- drm_mm_init(dev_priv-mm.stolen, 0, dev_priv-gtt.stolen_size -
- bios_reserved);
+ drm_mm_init(dev_priv-mm.stolen, initial_reserved,
+ dev_priv-gtt.stolen_size - bios_reserved);
return 0;
}
Actually, you need to fix the size in the initialization:
drm_mm_init(stolen, 4096, dev_priv-gtt.stolen_size - bios_reserved - 4096);
Also, I think we have a bug here today, you need to
dev_priv-gtt.stolen_size -= ...
Or else we don't have the correct assertion in
i915_pages_create_for_stolen(). I didn't look carefully if it's safe to
currently do it, but it does seem wrong to me as it is.
With the first fix (I didn't verify that's the real workaround name),
Reviewed-by: Ben Widawsky b...@bwidawsk.net
--
Ben Widawsky, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Introduce FBC False Color for debug purposes.
On Wed, Jul 30, 2014 at 09:26:17AM -0700, Rodrigo Vivi wrote:
With this bit enabled, HW changes the color when compressing frames for
debug purposes.
ALthough the simple way to enable a single bit is over intel_reg_write,
this value is overwriten on next update_fbc so depending on the workload
it is not possible to set this bit with intel-gpu-tools. So this patch
introduces a persistent way to enable false color over debugfs.
v2: Use DEFINE_SIMPLE_ATTRIBUTE as Daniel suggested
v3: (Ville) only do false color for IVB+ since according to spec bit is
MBZ before IVB.
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Cc: Ben Widawsky b...@bwidawsk.net
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
I don't quite understand the motivation for a get() other than debugging
the interface itself (if your set is broken). If anything, get should
read back the register in case you're trying to debug funky colors, but
I am not strongly opinionated here.
Just to make sure, false color works on VLV/CHV (for the gen check)?
With the above address:
Reviewed-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_debugfs.c | 42
+
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_pm.c | 3 +++
4 files changed, 48 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 9e737b7..bcfdc00 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1433,6 +1433,47 @@ static int i915_fbc_status(struct seq_file *m, void
*unused)
return 0;
}
+static int i915_fbc_fc_get(void *data, u64 *val)
+{
+ struct drm_device *dev = data;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+
+ if (INTEL_INFO(dev)-gen 7)
+ return -ENODEV;
+
+ drm_modeset_lock_all(dev);
+ *val = dev_priv-fbc.false_color;
+ drm_modeset_unlock_all(dev);
+
+ return 0;
+}
+
+static int i915_fbc_fc_set(void *data, u64 val)
+{
+ struct drm_device *dev = data;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ u32 reg;
+
+ if (INTEL_INFO(dev)-gen 7)
+ return -ENODEV;
+
+ drm_modeset_lock_all(dev);
+
+ reg = I915_READ(ILK_DPFC_CONTROL);
+ dev_priv-fbc.false_color = val;
+
+ I915_WRITE(ILK_DPFC_CONTROL, val ?
+(reg | FBC_CTL_FALSE_COLOR) :
+(reg ~FBC_CTL_FALSE_COLOR));
+
+ drm_modeset_unlock_all(dev);
+ return 0;
+}
+
+DEFINE_SIMPLE_ATTRIBUTE(i915_fbc_fc_fops,
+ i915_fbc_fc_get, i915_fbc_fc_set,
+ %llu\n);
+
static int i915_ips_status(struct seq_file *m, void *unused)
{
struct drm_info_node *node = m-private;
@@ -3957,6 +3998,7 @@ static const struct i915_debugfs_files {
{i915_pri_wm_latency, i915_pri_wm_latency_fops},
{i915_spr_wm_latency, i915_spr_wm_latency_fops},
{i915_cur_wm_latency, i915_cur_wm_latency_fops},
+ {i915_fbc_false_color, i915_fbc_fc_fops},
};
void intel_display_crc_init(struct drm_device *dev)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 18c9ad8..3018bf5 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -636,6 +636,8 @@ struct i915_fbc {
struct drm_mm_node compressed_fb;
struct drm_mm_node *compressed_llb;
+ bool false_color;
+
struct intel_fbc_work {
struct delayed_work work;
struct drm_crtc *crtc;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 28e21ed..b5d295a 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1540,6 +1540,7 @@ enum punit_power_well {
/* Framebuffer compression for Ironlake */
#define ILK_DPFC_CB_BASE 0x43200
#define ILK_DPFC_CONTROL 0x43208
+#define FBC_CTL_FALSE_COLOR(110)
/* The bit 28-8 is reserved */
#define DPFC_RESERVED (0x1F00)
#define ILK_DPFC_RECOMP_CTL 0x4320c
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 1ddd4df..338a80b 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -309,6 +309,9 @@ static void gen7_enable_fbc(struct drm_crtc *crtc)
dpfc_ctl |= IVB_DPFC_CTL_FENCE_EN;
+ if (dev_priv-fbc.false_color)
+ dpfc_ctl |= FBC_CTL_FALSE_COLOR;
+
I915_WRITE(ILK_DPFC_CONTROL, dpfc_ctl | DPFC_CTL_EN);
if (IS_IVYBRIDGE(dev)) {
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ben Widawsky, Intel Open Source Technology Center
Re: [Intel-gfx] [PATCH] drm: Add rotation_property to mode_config and creating it
On 7/29/2014 4:00 PM, Daniel Vetter wrote: On Tue, Jul 29, 2014 at 12:40:29PM +0300, Ville Syrjälä wrote: On Mon, Jul 28, 2014 at 08:47:22PM +0200, Daniel Vetter wrote: On Mon, Jul 28, 2014 at 06:29:41PM +0300, Ville Syrjälä wrote: On Tue, Jul 15, 2014 at 05:43:37PM +0530, sonika.jin...@intel.com wrote: From: Sonika Jindal sonika.jin...@intel.com v2: Adding creation of rotation_property here. Signed-off-by: Sonika Jindal sonika.jin...@intel.com --- drivers/gpu/drm/drm_crtc.c |3 ++- include/drm/drm_crtc.h |1 + 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c index 787631e..49c0747 100644 --- a/drivers/gpu/drm/drm_crtc.c +++ b/drivers/gpu/drm/drm_crtc.c @@ -1299,7 +1299,8 @@ static int drm_mode_create_standard_plane_properties(struct drm_device *dev) type, drm_plane_type_enum_list, ARRAY_SIZE(drm_plane_type_enum_list)); dev-mode_config.plane_type_property = type; - + dev-mode_config.rotation_property = drm_mode_create_rotation_property(dev, + BIT(DRM_ROTATE_0) | BIT(DRM_ROTATE_180)); This might not make sense for other (!i915) hardware. And that's the reason why I had the driver create the property in the first place. I think Daniel was thinking that we might want to expose all the bits regardless of what the hardware supports, but I don't like that idea. There are other properties (eg. alpha blending, csc stuff, etc.) that have the same problem of hardware supporting only a (potentially small) subset of the possible values. I'd rather we didn't make life harder for userspace when the kernel can already report that certain values will never work. Well I'd like the property to be in some generic place so that fbcon can unroate and that with the atomic stuff we can have rotation support in the core structures. Which should help with argument checking. But for rotation I don't think we should set it up in generic code, but in i915. So the place where we keep it would be generic, the values would be the sames, but the allowed set would differ depending upon platform or driver. That would still fail if all the planes on the same device don't support the same rotation flags. Eg. on i915 we would have this problem if we exposed the old video overlay as a drm plane. And it wouldn't be the first piece of hardware where I've seen this kind of thing. Problem is still that I'd like to have a somewhat generic internal representation available. We could punt this to atomic though by adding a rotation field to the drm_plane_state structure. Which is more-or-less my plan, but wouldn't work with Rob's approach. Or we keep the property link only in drm_plane (and give drivers the freedom to set up the underlying enum however they want to), but I'm not sure whether our interfaces can cope with that. -Daniel Daniel, Ville So what is the suggestion for this property? Should I be moving it to somewhere else? -Sonika ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/12] Stop trying to out-guess mesa for BO allocation
Eric Anholt e...@anholt.net writes: Keith Packard kei...@keithp.com writes: I don't see anything indicating that this code path is only used by glamor. True. It's a fix for DRI3 for either UXA or none. Mesa allocates a single page for a 1x1 texture, but this code thinks that should take two pages causing a texture-to-pixmap operation to fail. In particular, gnome-shell fails without this patch. It's useful independent of this series, which is why I stuck it first. -- keith.pack...@intel.com pgpnuxq1KsyiP.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/12] Don't use GetScratchPixmapHeader for shadow pixmaps
Eric Anholt e...@anholt.net writes: This change appears to be unrelated, and possibly harmful (if X has dropped the last ref to the BO, but it's still the scanout buffer, a new allocation would now reuse the BO and scribble on scanout until the next modeset happens). Yeah, it's unrelated. intel_allocate_framebuffer calls disable_reuse, so there's no need to call it from these two other places. I'll split that change out into a separate patch with separate comment. Unrelated whitespace. There are a bunch of whitespace fixups; should I pull those into a separate patch or just leave them scattered in the first patch to change a file? -- keith.pack...@intel.com pgpius4ilGE8T.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 06/12] Remove glamor support from UXA acceleration
Eric Anholt e...@anholt.net writes: Something weird happened in this commit. uxa-glamor.h is removed from the repo, but the makefile only drops intel_glamor.h, which keeps getting used. I suspect make distcheck is broken. Yeah, almost certainly. In fact, after this patch, the driver does *not* build if you ask for glamor. intel_glamor.c is no longer built, but USE_GLAMOR might still be defined I think, and if so intel_glamor_flush() from it is still getting called. Right, the driver explicitly doesn't build with --enable-glamor after this patch. Cleaning it up so that it would build makes more of a mess though, so I just didn't worry about it as I was re-adding glamor when all of the USE_GLAMOR bits would be needed again. I can make it work if you like, but this patch and the re-enable glamor patch would both get larger. -- keith.pack...@intel.com pgp1tUlqhlD6b.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 08/12] Get rid of glamor stubs in intel_glamor.h
Eric Anholt e...@anholt.net writes: Keith Packard kei...@keithp.com writes: This eliminates the stubs in intel_glamor.h and replaces them with ifdefs instead. I don't feel strongly about this either way -- ifdefs are more traditional userland style, while stubs are more kernel style. Right, just trying to keep things all the same and #ifdef USE_GLAMOR seemed more common. Acked-by: Eric Anholt e...@anholt.net -- keith.pack...@intel.com pgp1ME88gbxeA.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Skip Stolen Memory first page.
On Wed, Jul 30, 2014 at 10:47:46AM -0700, Rodrigo Vivi wrote:
WA to skip the first page of stolen memory due to sporadic HW write on *CS
Idle
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
drivers/gpu/drm/i915/i915_gem_stolen.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c
b/drivers/gpu/drm/i915/i915_gem_stolen.c
index 21c025a..3acefb3 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -290,6 +290,7 @@ int i915_gem_init_stolen(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
int bios_reserved = 0;
+ int initial_reserved = 0;
start_reserved, end_reserved?
-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
