[Intel-gfx] [PATCH 2/2] drm/i915: Extend GET_APERTURE ioctl to report size of the stolen region
From: Ankitprasad Sharma
This patch extends the GET_APERTURE ioctl to add support
for getting total size and available size of the stolen region
as well as single largest block available in the stolen region.
Also adds debugfs support to retieve the size information of the
stolen area.
v2: respinned over Rodrigo's patch which extends the GET_APERTURE
too. Used drm_mm to get the size information of the stolen region
(Chris)
Added debugfs support for testing (Ankit)
v3: Rebased to the latest drm-intel-nightly (Ankit)
Signed-off-by: Ankitprasad Sharma
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c| 6 ++
drivers/gpu/drm/i915/i915_drv.h| 3 +++
drivers/gpu/drm/i915/i915_gem.c| 7 +++
drivers/gpu/drm/i915/i915_gem_stolen.c | 35 ++
include/uapi/drm/i915_drm.h| 15 +++
5 files changed, 66 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 49ec438..d12ef0a 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -534,6 +534,12 @@ static int i915_gem_aperture_info(struct seq_file *m, void
*data)
arg.fence_available_size);
seq_printf(m, "Single largest fence available: %llu bytes\n",
arg.fence_largest_size);
+ seq_printf(m, "Total size of the stolen region: %llu bytes\n",
+ arg.stolen_total_size);
+ seq_printf(m, "Available size of the stolen region: %llu bytes\n",
+ arg.stolen_available_size);
+ seq_printf(m, "Single largest area in the stolen region: %llu bytes\n",
+ arg.stolen_largest_size);
return 0;
}
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index ea9caf2..7cd1b2e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3101,6 +3101,9 @@ i915_gem_object_create_stolen_for_preallocated(struct
drm_device *dev,
u32 stolen_offset,
u32 gtt_offset,
u32 size);
+void i915_gem_stolen_size_info(struct drm_mm *mm, uint64_t *stolen_total,
+ uint64_t *stolen_free,
+ uint64_t *stolen_largest);
/* i915_gem_shrinker.c */
unsigned long i915_gem_shrink(struct drm_i915_private *dev_priv,
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index ccfc8d3..ec20c67 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -203,6 +203,7 @@ i915_gem_get_aperture_ioctl(struct drm_device *dev, void
*data,
struct list_head map_list;
const u32 map_limit = dev_priv->gtt.mappable_end;
size_t pinned, map_space, map_largest, fence_space, fence_largest;
+ uint64_t stolen_total, stolen_available, stolen_largest;
u32 last, size;
INIT_LIST_HEAD(&map_list);
@@ -260,6 +261,9 @@ skip_first:
fence_largest = size;
fence_space += size;
}
+
+ i915_gem_stolen_size_info(&dev_priv->mm.stolen, &stolen_total,
+ &stolen_available, &stolen_largest);
mutex_unlock(&dev->struct_mutex);
args->aper_size = dev_priv->gtt.base.total;
@@ -269,6 +273,9 @@ skip_first:
args->map_total_size = dev_priv->gtt.mappable_end;
args->fence_available_size = fence_space;
args->fence_largest_size = fence_largest;
+ args->stolen_total_size = stolen_total;
+ args->stolen_available_size = stolen_available;
+ args->stolen_largest_size = stolen_largest;
return 0;
}
diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c
b/drivers/gpu/drm/i915/i915_gem_stolen.c
index 348ed5a..08d983f 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -551,3 +551,38 @@ err_out:
drm_gem_object_unreference(&obj->base);
return NULL;
}
+
+void i915_gem_stolen_size_info(struct drm_mm *mm, uint64_t *stolen_total,
+ uint64_t *stolen_free,
+ uint64_t *stolen_largest)
+{
+ struct drm_mm_node *entry;
+ struct drm_mm_node *head_node = &mm->head_node;
+ uint64_t hole_size, hole_start, hole_end, largest_hole = 0;
+ uint64_t total_used = 0, total_free = 0;
+
+ if (head_node->hole_follows) {
+ hole_start = drm_mm_hole_node_start(head_node);
+ hole_end = drm_mm_hole_node_end(head_node);
+ hole_size = hole_end - hole_start;
+ total_free += hole_size;
+ if (largest_hole < hole_size)
+ largest_hole = hole_size;
+ }
+
+ drm_mm_for_each_node(entry, mm) {
+ total_used += entry->size;
+ if (entry->hol
[Intel-gfx] [PATCH 1/2] drm/i915: Extend GET_APERTURE ioctl to report available map space
From: Rodrigo Vivi
When constructing a batchbuffer, it is sometimes crucial to know the
largest hole into which we can fit a fenceable buffer (for example when
handling very large objects on gen2 and gen3). This depends on the
fragmentation of pinned buffers inside the aperture, a question only the
kernel can easily answer.
This patch extends the current DRM_I915_GEM_GET_APERTURE ioctl to
include a couple of new fields in its reply to userspace - the total
amount of space available in the mappable region of the aperture and
also the single largest block available.
This is not quite what userspace wants to answer the question of whether
this batch will fit as fences are also required to meet severe alignment
constraints within the batch. For this purpose, a third conservative
estimate of largest fence available is also provided. For when userspace
needs more than one batch, we also provide the culmulative space
available for fences such that it has some additional guidance to how
much space it could allocate to fences. Conservatism still wins.
The patch also adds a debugfs file for convenient testing and reporting.
v2: The first object cannot end at offset 0, so we can use last==0 to
detect the empty list.
v3: Expand all values to 64bit, just in case.
Report total mappable aperture size for userspace that cannot easily
determine it by inspecting the PCI device.
v4: (Rodrigo) Fixed rebase conflicts.
Signed-off-by: Chris Wilson
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_debugfs.c | 27 +
drivers/gpu/drm/i915/i915_gem.c | 116 ++--
include/uapi/drm/i915_drm.h | 25
3 files changed, 164 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 31d8768..49ec438 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -512,6 +512,32 @@ static int i915_gem_object_info(struct seq_file *m, void*
data)
return 0;
}
+static int i915_gem_aperture_info(struct seq_file *m, void *data)
+{
+ struct drm_info_node *node = m->private;
+ struct drm_i915_gem_get_aperture arg;
+ int ret;
+
+ ret = i915_gem_get_aperture_ioctl(node->minor->dev, &arg, NULL);
+ if (ret)
+ return ret;
+
+ seq_printf(m, "Total size of the GTT: %llu bytes\n",
+ arg.aper_size);
+ seq_printf(m, "Available space in the GTT: %llu bytes\n",
+ arg.aper_available_size);
+ seq_printf(m, "Available space in the mappable aperture: %llu bytes\n",
+ arg.map_available_size);
+ seq_printf(m, "Single largest space in the mappable aperture: %llu
bytes\n",
+ arg.map_largest_size);
+ seq_printf(m, "Available space for fences: %llu bytes\n",
+ arg.fence_available_size);
+ seq_printf(m, "Single largest fence available: %llu bytes\n",
+ arg.fence_largest_size);
+
+ return 0;
+}
+
static int i915_gem_gtt_info(struct seq_file *m, void *data)
{
struct drm_info_node *node = m->private;
@@ -5030,6 +5056,7 @@ static int i915_debugfs_create(struct dentry *root,
static const struct drm_info_list i915_debugfs_list[] = {
{"i915_capabilities", i915_capabilities, 0},
{"i915_gem_objects", i915_gem_object_info, 0},
+ {"i915_gem_aperture", i915_gem_aperture_info, 0},
{"i915_gem_gtt", i915_gem_gtt_info, 0},
{"i915_gem_pinned", i915_gem_gtt_info, 0, (void *) PINNED_LIST},
{"i915_gem_active", i915_gem_object_list_info, 0, (void *) ACTIVE_LIST},
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index a2a4a27..ccfc8d3 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -32,6 +32,7 @@
#include "i915_vgpu.h"
#include "i915_trace.h"
#include "intel_drv.h"
+#include
#include
#include
#include
@@ -143,6 +144,55 @@ int i915_mutex_lock_interruptible(struct drm_device *dev)
return 0;
}
+static inline bool
+i915_gem_object_is_inactive(struct drm_i915_gem_object *obj)
+{
+ return i915_gem_obj_bound_any(obj) && !obj->active;
+}
+
+static int obj_rank_by_ggtt(void *priv,
+ struct list_head *A,
+ struct list_head *B)
+{
+ struct drm_i915_gem_object *a = list_entry(A,typeof(*a), obj_exec_link);
+ struct drm_i915_gem_object *b = list_entry(B,typeof(*b), obj_exec_link);
+
+ return i915_gem_obj_ggtt_offset(a) - i915_gem_obj_ggtt_offset(b);
+}
+
+static u32 __fence_size(struct drm_i915_private *dev_priv, u32 start, u32 end)
+{
+ u32 size = end - start;
+ u32 fence_size;
+
+ if (INTEL_INFO(dev_priv)->gen < 4) {
+ u32 fence_max;
+ u32 fence_next;
+
+ if (IS_GEN3(dev_priv)) {
+ fence_max = I830_FENCE_MAX_SIZE_VAL << 20;
+
[Intel-gfx] [PATCH v3 0/2] Extending GET_APERTURE ioctl
From: Ankitprasad Sharma When constructing a batchbuffer, it is sometimes crucial to know the largest hole into which we can fit a fenceable buffer (for example when handling very large objects on gen2 and gen3). This depends on the fragmentation of pinned buffers inside the aperture, a question only the kernel can easily answer. This set of patches extends the current DRM_I915_GEM_GET_APERTURE ioctl to include a couple of new fields in its reply to userspace - the total amount of space available in the mappable region of the aperture and also the single largest block available. This is not quite what userspace wants to answer the question of whether this batch will fit as fences are also required to meet severe alignment constraints within the batch. For this purpose, a third conservative estimate of largest fence available is also provided. For when userspace needs more than one batch, we also provide the culmulative space available for fences such that it has some additional guidance to how much space it could allocate to fences. Conservatism still wins. The patches also support for getting total size and available size of the stolen region as well as single largest block available in the stolen region. It also adds a debugfs file for convenient testing and reporting. v2: Rebased to the latest drm-intel-nightly v3: Fixed compilation error Ankitprasad Sharma (1): drm/i915: Extend GET_APERTURE ioctl to report size of the stolen region Rodrigo Vivi (1): drm/i915: Extend GET_APERTURE ioctl to report available map space drivers/gpu/drm/i915/i915_debugfs.c| 33 + drivers/gpu/drm/i915/i915_drv.h| 3 + drivers/gpu/drm/i915/i915_gem.c| 123 +++-- drivers/gpu/drm/i915/i915_gem_stolen.c | 35 ++ include/uapi/drm/i915_drm.h| 40 +++ 5 files changed, 230 insertions(+), 4 deletions(-) -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/7] drm/i915: Convert execlist_submit_contexts() for requests
Yu Dai writes:
> On 07/07/2015 09:49 AM, Yu Dai wrote:
>> On 07/03/2015 07:09 AM, Mika Kuoppala wrote:
>> > Pass around requests to carry context deeper in callchain.
>> >
>> > Signed-off-by: Mika Kuoppala
>> > ---
>> > drivers/gpu/drm/i915/intel_lrc.c | 30 ++
>> > 1 file changed, 14 insertions(+), 16 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/intel_lrc.c
>> > b/drivers/gpu/drm/i915/intel_lrc.c
>> > index 9b928ab..583210d 100644
>> > --- a/drivers/gpu/drm/i915/intel_lrc.c
>> > +++ b/drivers/gpu/drm/i915/intel_lrc.c
>> > @@ -358,29 +358,29 @@ static int execlists_update_context(struct
>> > drm_i915_gem_object *ctx_obj,
>> >return 0;
>> > }
>> >
>> > -static void execlists_submit_contexts(struct intel_engine_cs *ring,
>> > -struct intel_context *to0, u32 tail0,
>> > -struct intel_context *to1, u32 tail1)
>> > +static void execlists_submit_requests(struct drm_i915_gem_request *rq0,
>> > +struct drm_i915_gem_request *rq1)
>> > {
>> > - struct drm_i915_gem_object *ctx_obj0 = to0->engine[ring->id].state;
>> > - struct intel_ringbuffer *ringbuf0 = to0->engine[ring->id].ringbuf;
>> > + struct intel_engine_cs *ring = rq0->ring;
>> > + struct drm_i915_gem_object *ctx_obj0 = rq0->ctx->engine[ring->id].state;
>> >struct drm_i915_gem_object *ctx_obj1 = NULL;
>> > - struct intel_ringbuffer *ringbuf1 = NULL;
>> >
>> >BUG_ON(!ctx_obj0);
>> >WARN_ON(!i915_gem_obj_is_pinned(ctx_obj0));
>> > - WARN_ON(!i915_gem_obj_is_pinned(ringbuf0->obj));
>> > + WARN_ON(!i915_gem_obj_is_pinned(rq0->ringbuf->obj));
>> >
>> > - execlists_update_context(ctx_obj0, ringbuf0->obj, to0->ppgtt, tail0);
>> > + execlists_update_context(ctx_obj1, rq0->ringbuf->obj,
>> Typo? Here it should be ctx_obj0.
>
> Never mind. Issue got fixed by patch 2/7.
> Alex
Well that will cause trouble for the bisecter :(
-Mika
>> > + rq0->ctx->ppgtt, rq0->tail);
>> > +
>> > + if (rq1) {
>> > + ctx_obj1 = rq1->ctx->engine[ring->id].state;
>> >
>> > - if (to1) {
>> > - ringbuf1 = to1->engine[ring->id].ringbuf;
>> > - ctx_obj1 = to1->engine[ring->id].state;
>> >BUG_ON(!ctx_obj1);
>> >WARN_ON(!i915_gem_obj_is_pinned(ctx_obj1));
>> > - WARN_ON(!i915_gem_obj_is_pinned(ringbuf1->obj));
>> > + WARN_ON(!i915_gem_obj_is_pinned(rq1->ringbuf->obj));
>> >
>> > - execlists_update_context(ctx_obj1, ringbuf1->obj, to1->ppgtt,
>> > tail1);
>> > + execlists_update_context(ctx_obj1, rq1->ringbuf->obj,
>> > + rq1->ctx->ppgtt, rq1->tail);
>> >}
>> >
>> >execlists_elsp_write(ring, ctx_obj0, ctx_obj1);
>> > @@ -443,9 +443,7 @@ static void execlists_context_unqueue(struct
>> > intel_engine_cs *ring)
>> >
>> >WARN_ON(req1 && req1->elsp_submitted);
>> >
>> > - execlists_submit_contexts(ring, req0->ctx, req0->tail,
>> > -req1 ? req1->ctx : NULL,
>> > -req1 ? req1->tail : 0);
>> > + execlists_submit_requests(req0, req1);
>> >
>> >req0->elsp_submitted++;
>> >if (req1)
>>
>
> ___
> 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] WARNING: CPU: 0 PID: 3634 at drivers/gpu/drm/drm_irq.c:1141 drm_wait_one_vblank
On Wed, Jul 08, 2015 at 08:40:17AM +0200, Michal Hocko wrote: > I have just tried to boot 4.2-rc1 and cannot seem to reproduce the issue > anymore. > > On Tue 07-07-15 10:43:58, Daniel Vetter wrote: > [...] > > Can you please > > boot with drm.debug=0xf (lots more nois in dmesg with this) and reproduce? > > I only need the last few pages before the WARNING backtrace, just to > > understand a bit better what's going on there. > > And 0xf debug level seem to paper over the problem because I do not see > the warning even with 4.1 where I am able to reproduce this reliably. > This suggests this is a timing sensitive issue. Ok that's starting to get nasty. Can you please test what happens when you boot with drm.vblankoffdelay=0 and whether drm.vblankoffdelay=1000 has an effect on reproduction rate? No debug output needed. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] WARNING: CPU: 0 PID: 3634 at drivers/gpu/drm/drm_irq.c:1141 drm_wait_one_vblank
On Wed 08-07-15 09:32:18, Daniel Vetter wrote: [...] > Ok that's starting to get nasty. Can you please test what happens when you > boot with drm.vblankoffdelay=0 and whether drm.vblankoffdelay=1000 has an > effect on reproduction rate? No debug output needed. No difference. See the kernel log from both runs attached. -- Michal Hocko SUSE Labs log.gz Description: application/gzip ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 02/20] drm: Don't update plane properties for atomic planes if it stays the same
Op 07-07-15 om 18:43 schreef Daniel Vetter:
> On Tue, Jul 07, 2015 at 05:08:34PM +0200, Maarten Lankhorst wrote:
>> Op 07-07-15 om 14:10 schreef Daniel Vetter:
>>> On Tue, Jul 07, 2015 at 12:20:10PM +0200, Maarten Lankhorst wrote:
Op 07-07-15 om 11:18 schreef Daniel Vetter:
> On Tue, Jul 07, 2015 at 09:08:13AM +0200, Maarten Lankhorst wrote:
>> This allows the first atomic call during hw init to be a real modeset,
>> which is useful for forcing a recalculation.
> fbcon is optional, you can't rely on anything being done in any specific
> way. What exactly do you need this for, what's the implications?
In the hw readout I noticed some warnings when I wasn't setting any mode
property in the readout.
I want the first function to be the modeset, so we have a sane base to
commit changes on.
Ideally this whole function would have a atomic counterpart which does it
in one go. :)
>>> Yeah. Otoh as soon as we have atomic modeset working we can replace all
>>> the legacy entry points with atomic helpers, and then even plane_disable
>>> will be a full atomic modeset.
>>>
>>> What did fall apart with just touching properties/planes now?
>> Also when i915 is fully atomic it calculates in intel_modeset_compute_config
>> if a modeset is needed after the first atomic call. Right now because
>> intel_modeset_compute_config is only called in set_config so this works as
>> expected.
>> Otherwise drm_plane_force_disable or rotate_0 will force a modeset,
>> and if the final mode is different this will introduce a double modeset.
> For expensive properties (i.e. a no-op changes causes something that takes
> time like modeset or vblank wait) we need to make sure we filter them out
> in atomic_check. Yeah not quite there yet with pure atomic, but meanwhile
> the existing legacy set_prop functions should all filter out no-op changes
> themselves. If we don't do that for rotation then that's a bug.
>
> Same for disabling planes harder, that shouldn't take time. Especially
> since fbcon only force-disable non-primary plane, and for driver load
> that's the exact thing we already do in the driver anyway.
Something like this?
---
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index a1d4e13f3908..2989232f4996 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -30,6 +30,7 @@
#include
#include
#include
+#include "drm_crtc_internal.h"
#include
/**
@@ -1716,7 +1717,12 @@ drm_atomic_helper_crtc_set_property(struct drm_crtc
*crtc,
{
struct drm_atomic_state *state;
struct drm_crtc_state *crtc_state;
- int ret = 0;
+ uint64_t retval;
+ int ret;
+
+ ret = drm_atomic_get_property(&crtc->base, property, &retval);
+ if (!ret && val == retval)
+ return 0;
state = drm_atomic_state_alloc(crtc->dev);
if (!state)
@@ -1776,7 +1782,12 @@ drm_atomic_helper_plane_set_property(struct drm_plane
*plane,
{
struct drm_atomic_state *state;
struct drm_plane_state *plane_state;
- int ret = 0;
+ uint64_t retval;
+ int ret;
+
+ ret = drm_atomic_get_property(&plane->base, property, &retval);
+ if (!ret && val == retval)
+ return 0;
state = drm_atomic_state_alloc(plane->dev);
if (!state)
@@ -1836,7 +1847,12 @@ drm_atomic_helper_connector_set_property(struct
drm_connector *connector,
{
struct drm_atomic_state *state;
struct drm_connector_state *connector_state;
- int ret = 0;
+ uint64_t retval;
+ int ret;
+
+ ret = drm_atomic_get_property(&connector->base, property, &retval);
+ if (!ret && val == retval)
+ return 0;
state = drm_atomic_state_alloc(connector->dev);
if (!state)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 424c83323aaa..5bab7bff8a15 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1327,7 +1327,8 @@ void drm_plane_force_disable(struct drm_plane *plane)
{
int ret;
- if (!plane->fb)
+ if ((plane->state && !plane->state->fb) ||
+ (!plane->state && !plane->fb))
return;
plane->old_fb = plane->fb;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 03/20] drm/i915: Fix noatomic crtc disabling.
On Tue, Jul 07, 2015 at 04:14:01PM +0200, Maarten Lankhorst wrote: > Op 07-07-15 om 14:39 schreef Patrik Jakobsson: > > On Tue, Jul 07, 2015 at 12:22:12PM +0200, Maarten Lankhorst wrote: > >> Op 07-07-15 om 11:18 schreef Daniel Vetter: > >>> On Tue, Jul 07, 2015 at 09:08:14AM +0200, Maarten Lankhorst wrote: > This should fix suspend on newer platforms. > >>> Which patch broke this? Also what is "newer platform" and what exactly got > >>> fixed? Please elaborate a bit more in your commit messages, they're too > >>> terse. > >> There were a lot of warnings about active mismatches and power well not > >> being idle on suspend. > >> > >> This should fix the power well by disabling the shared dpll and unsetting > >> crtc->active. > > This got broken by: > > > > commit eddfcbcdc27fbecb33bff098967bbdd7ca75bfa6 > > Author: Maarten Lankhorst > > Date: Mon Jun 15 12:33:53 2015 +0200 > > > > drm/i915: Update less state during modeset. > > > > No need to repeatedly call update_watermarks, or update_fbc. > > Down to a single call to update_watermarks in .crtc_enable > > > > Signed-off-by: Maarten Lankhorst > > Reviewed-by: Matt Roper > > Tested-by(IVB): Matt Roper > > Signed-off-by: Daniel Vetter > > > > Unfortunately the patch doesn't fix the CAT_ERR on resume I'm experiencing > > on > > SKL. An additional intel_update_watermarks() is needed to set DDB back to > > 0,0. > > Also this is required in *_crtc_disable() since we forget to do the same > > thing > > there. Not sure we also need to take care of disabling fbc at these places? > I would prefer to have this fix, and leave updating the watermark code out of > crtc disable. > > Does it work If you add a intel_update_watermarks to the noatomic function? No that doesn't help. The only other callsite I can find is __intel_set_mode() so I guess watermarks need updating there as well. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Handle HPD when it has actually occurred
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) Task id: 6740 -Summary- Platform Delta drm-intel-nightly Series Applied ILK 302/302 302/302 SNB 312/316 312/316 IVB 343/343 343/343 BYT -2 287/287 285/287 HSW 380/380 380/380 -Detailed- Platform Testdrm-intel-nightly Series Applied *BYT igt@gem_partial_pwrite_pread@reads PASS(1) FAIL(1) *BYT igt@gem_partial_pwrite_pread@reads-uncached PASS(1) FAIL(1) Note: You need to pay more attention to line start with '*' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 06/20] drm/i915: Allow fuzzy matching in pipe_config_compare.
Op 07-07-15 om 12:11 schreef Daniel Vetter:
> On Tue, Jul 07, 2015 at 09:08:17AM +0200, Maarten Lankhorst wrote:
>> Instead of doing ad-hoc checks we already have a way of checking
>> if the state is compatible or not. Use this to force a modeset.
>>
>> Only during modesets, or with PIPE_CONFIG_QUIRK_INHERITED_MODE
>> we should check if a full modeset is really needed.
>>
>> Fastboot will allow the adjust parameter to ignore some stuff
>> too, and it will fix up differences in state that are ignored
>> by the compare function.
>>
>> Signed-off-by: Maarten Lankhorst
>> ---
>> drivers/gpu/drm/i915/intel_display.c | 198
>> ---
>> 1 file changed, 139 insertions(+), 59 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_display.c
>> b/drivers/gpu/drm/i915/intel_display.c
>> index 8cd3a7eb1e30..eb7c2e2819b7 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -12277,19 +12277,6 @@ encoder_retry:
>> DRM_DEBUG_KMS("plane bpp: %i, pipe bpp: %i, dithering: %i\n",
>>base_bpp, pipe_config->pipe_bpp, pipe_config->dither);
>>
>> -/* Check if we need to force a modeset */
>> -if (pipe_config->has_audio !=
>> -to_intel_crtc_state(crtc->state)->has_audio) {
>> -pipe_config->base.mode_changed = true;
>> -ret = drm_atomic_add_affected_planes(state, crtc);
>> -}
>> -
>> -/*
>> - * Note we have an issue here with infoframes: current code
>> - * only updates them on the full mode set path per hw
>> - * requirements. So here we should be checking for any
>> - * required changes and forcing a mode set.
>> - */
>> fail:
>> return ret;
>> }
>> @@ -12392,27 +12379,124 @@ static bool intel_fuzzy_clock_check(int clock1,
>> int clock2)
>> base.head) \
>> if (mask & (1 <<(intel_crtc)->pipe))
>>
>> +
>> +static bool
>> +intel_compare_m_n(unsigned int m, unsigned int n,
>> + unsigned int m2, unsigned int n2)
>> +{
>> +if (m == m2 && n == n2)
>> +return true;
>> +
>> +if (!m || !n || !m2 || !n2)
>> +return false;
>> +
>> +if (m > m2) {
>> +while (m > m2) {
> I think we need to make sure we don't reduce precision by eating low bits,
> i.e.
> while (m > m2 && !(m & 1) && !(n & 1)) {
Could be useful, lets hope everyone rounds in the same way. :)
>> +m >>= 1;
>> +n >>= 1;
>> +}
>> +} else if (m < m2) {
>> +while (m < m2) {
>> +m2 >>= 1;
>> +n2 >>= 1;
>> +}
>> +}
>> +
>> +return m == m2 && n == n2;
>> +}
>> +
>> +static bool
>> +intel_compare_link_m_n(const struct intel_link_m_n *m_n,
>> + const struct intel_link_m_n *m2_n2)
> I think these need to take adjust as an agurment and check for exact match
> (not just matching ratio), like before.
I just implemented it, then remembered why I didn't.
It will cause a failure in intel_modeset_check_state.
>> +{
>> +if (m_n->tu == m2_n2->tu &&
>> +intel_compare_m_n(m_n->gmch_m, m_n->gmch_n,
>> + m2_n2->gmch_m, m2_n2->gmch_n) &&
>> +intel_compare_m_n(m_n->link_m, m_n->link_n,
>> + m2_n2->link_m, m2_n2->link_n))
>> +return true;
>> +
>> +return false;
>> +}
>> +
>> static bool
>> intel_pipe_config_compare(struct drm_device *dev,
>>struct intel_crtc_state *current_config,
>> - struct intel_crtc_state *pipe_config)
>> + struct intel_crtc_state *pipe_config,
>> + bool adjust)
>> {
>> +bool ret = true;
>> +
>> +#define INTEL_ERR_OR_DBG_KMS(fmt, ...) \
>> +do { \
>> +if (!adjust) \
>> +DRM_ERROR(fmt, ##__VA_ARGS__); \
>> +else \
>> +DRM_DEBUG_KMS(fmt, ##__VA_ARGS__); \
>> +} while (0)
>> +
>> #define PIPE_CONF_CHECK_X(name) \
>> if (current_config->name != pipe_config->name) { \
>> -DRM_ERROR("mismatch in " #name " " \
>> +INTEL_ERR_OR_DBG_KMS("mismatch in " #name " " \
>>"(expected 0x%08x, found 0x%08x)\n", \
>>current_config->name, \
>>pipe_config->name); \
>> -return false; \
>> +ret = false; \
>> }
>>
>> #define PIPE_CONF_CHECK_I(name) \
>> if (current_config->name != pipe_config->name) { \
>> -DRM_ERROR("mismatch in " #name " " \
>> +INTEL_ERR_OR_DBG_KMS("mismatch in " #name " " \
>>"(expected %i, found %i)\n", \
>>current_config->name, \
>>pipe_config->name); \
>> -return false; \
>> +ret = false; \
>> +}
>> +
>> +#define PIPE_CONF_CHECK_
Re: [Intel-gfx] [PATCH] drm/i915: Handle HPD when it has actually occurred
On Wed, Jul 08, 2015 at 10:40:18AM +0530, Jindal, Sonika wrote:
>
>
> On 7/7/2015 6:51 PM, Ville Syrjälä wrote:
> > On Tue, Jul 07, 2015 at 02:22:20PM +0530, Sonika Jindal wrote:
> >> Writing to PCH_PORT_HOTPLUG for each interrupt is not required.
> >> Handle it only if hpd has actually occurred like we handle other
> >> interrupts.
> >> v2: Make few variables local to if block (Ville)
> >> v3: Add check for ibx/cpt both (Ville).
> >> While at it, remove the redundant check for hotplug_trigger from
> >> pch_get_hpd_pins
> >>
> >> Signed-off-by: Sonika Jindal
> >> ---
> >> drivers/gpu/drm/i915/i915_irq.c | 32 +---
> >> 1 file changed, 17 insertions(+), 15 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/i915_irq.c
> >> b/drivers/gpu/drm/i915/i915_irq.c
> >> index a6fbe64..ba2c27c 100644
> >> --- a/drivers/gpu/drm/i915/i915_irq.c
> >> +++ b/drivers/gpu/drm/i915/i915_irq.c
> >> @@ -1266,9 +1266,6 @@ static void pch_get_hpd_pins(u32 *pin_mask, u32
> >> *long_mask,
> >>*pin_mask = 0;
> >>*long_mask = 0;
> >>
> >> - if (!hotplug_trigger)
> >> - return;
> >> -
> >
> > Looks like BXT still depends on that. So you should change that too,
> > or leave this in until someone else does it.
> No, for bxt, this function is called from bxt_hpd_handler which is
> called only when "tmp & BXT_DE_PORT_HOTPLUG_MASK" is non-zero.
> So, it this is fine for bxt.
Oh, right you are. No problem then.
>
> >
> >>for_each_hpd_pin(i) {
> >>if ((hpd[i] & hotplug_trigger) == 0)
> >>continue;
> >> @@ -1658,14 +1655,17 @@ static void ibx_irq_handler(struct drm_device
> >> *dev, u32 pch_iir)
> >>struct drm_i915_private *dev_priv = dev->dev_private;
> >>int pipe;
> >>u32 hotplug_trigger = pch_iir & SDE_HOTPLUG_MASK;
> >> - u32 dig_hotplug_reg;
> >> - u32 pin_mask, long_mask;
> >>
> >> - dig_hotplug_reg = I915_READ(PCH_PORT_HOTPLUG);
> >> - I915_WRITE(PCH_PORT_HOTPLUG, dig_hotplug_reg);
> >> + if (hotplug_trigger) {
> >> + u32 dig_hotplug_reg, pin_mask, long_mask;
> >>
> >> - pch_get_hpd_pins(&pin_mask, &long_mask, hotplug_trigger,
> >> dig_hotplug_reg, hpd_ibx);
> >> - intel_hpd_irq_handler(dev, pin_mask, long_mask);
> >> + dig_hotplug_reg = I915_READ(PCH_PORT_HOTPLUG);
> >> + I915_WRITE(PCH_PORT_HOTPLUG, dig_hotplug_reg);
> >> +
> >> + pch_get_hpd_pins(&pin_mask, &long_mask, hotplug_trigger,
> >> + dig_hotplug_reg, hpd_ibx);
> >
> > Indentation is fubar.
> This was to avoid 80 char limit.
You have it like this
+ pch_get_hpd_pins(&pin_mask, &long_mask, hotplug_trigger,
+ dig_hotplug_reg, hpd_ibx);
and it should look like this
+ pch_get_hpd_pins(&pin_mask, &long_mask, hotplug_trigger,
+dig_hotplug_reg, hpd_ibx);
that is the arguments on following lines should line up after the opening
'(' on the first line. Sane editors can do this automagically for you.
> >
> >> + intel_hpd_irq_handler(dev, pin_mask, long_mask);
> >> + }
> >>
> >>if (pch_iir & SDE_AUDIO_POWER_MASK) {
> >>int port = ffs((pch_iir & SDE_AUDIO_POWER_MASK) >>
> >> @@ -1757,14 +1757,16 @@ static void cpt_irq_handler(struct drm_device
> >> *dev, u32 pch_iir)
> >>struct drm_i915_private *dev_priv = dev->dev_private;
> >>int pipe;
> >>u32 hotplug_trigger = pch_iir & SDE_HOTPLUG_MASK_CPT;
> >> - u32 dig_hotplug_reg;
> >> - u32 pin_mask, long_mask;
> >>
> >> - dig_hotplug_reg = I915_READ(PCH_PORT_HOTPLUG);
> >> - I915_WRITE(PCH_PORT_HOTPLUG, dig_hotplug_reg);
> >> + if (hotplug_trigger) {
> >> + u32 dig_hotplug_reg, pin_mask, long_mask;
> >>
> >> - pch_get_hpd_pins(&pin_mask, &long_mask, hotplug_trigger,
> >> dig_hotplug_reg, hpd_cpt);
> >> - intel_hpd_irq_handler(dev, pin_mask, long_mask);
> >> + dig_hotplug_reg = I915_READ(PCH_PORT_HOTPLUG);
> >> + I915_WRITE(PCH_PORT_HOTPLUG, dig_hotplug_reg);
> >> + pch_get_hpd_pins(&pin_mask, &long_mask, hotplug_trigger,
> >> + dig_hotplug_reg, hpd_cpt);
> >
> > Ditto
> >
> This was to avoid 80 char limit.
>
> > With those fixed this is
> > Reviewed-by: Ville Syrjälä
> >
> >> + intel_hpd_irq_handler(dev, pin_mask, long_mask);
> >> + }
> >>
> >>if (pch_iir & SDE_AUDIO_POWER_MASK_CPT) {
> >>int port = ffs((pch_iir & SDE_AUDIO_POWER_MASK_CPT) >>
> >> --
> >> 1.7.10.4
> >>
> >> ___
> >> Intel-gfx mailing list
> >> Intel-gfx@lists.freedesktop.org
> >> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> >
--
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 v2 03/20] drm/i915: Fix noatomic crtc disabling.
Op 08-07-15 om 10:12 schreef Patrik Jakobsson:
> On Tue, Jul 07, 2015 at 04:14:01PM +0200, Maarten Lankhorst wrote:
>> Op 07-07-15 om 14:39 schreef Patrik Jakobsson:
>>> On Tue, Jul 07, 2015 at 12:22:12PM +0200, Maarten Lankhorst wrote:
Op 07-07-15 om 11:18 schreef Daniel Vetter:
> On Tue, Jul 07, 2015 at 09:08:14AM +0200, Maarten Lankhorst wrote:
>> This should fix suspend on newer platforms.
> Which patch broke this? Also what is "newer platform" and what exactly got
> fixed? Please elaborate a bit more in your commit messages, they're too
> terse.
There were a lot of warnings about active mismatches and power well not
being idle on suspend.
This should fix the power well by disabling the shared dpll and unsetting
crtc->active.
>>> This got broken by:
>>>
>>> commit eddfcbcdc27fbecb33bff098967bbdd7ca75bfa6
>>> Author: Maarten Lankhorst
>>> Date: Mon Jun 15 12:33:53 2015 +0200
>>>
>>> drm/i915: Update less state during modeset.
>>>
>>> No need to repeatedly call update_watermarks, or update_fbc.
>>> Down to a single call to update_watermarks in .crtc_enable
>>>
>>> Signed-off-by: Maarten Lankhorst
>>> Reviewed-by: Matt Roper
>>> Tested-by(IVB): Matt Roper
>>> Signed-off-by: Daniel Vetter
>>>
>>> Unfortunately the patch doesn't fix the CAT_ERR on resume I'm experiencing
>>> on
>>> SKL. An additional intel_update_watermarks() is needed to set DDB back to
>>> 0,0.
>>> Also this is required in *_crtc_disable() since we forget to do the same
>>> thing
>>> there. Not sure we also need to take care of disabling fbc at these places?
>> I would prefer to have this fix, and leave updating the watermark code out
>> of crtc disable.
>>
>> Does it work If you add a intel_update_watermarks to the noatomic function?
> No that doesn't help. The only other callsite I can find is __intel_set_mode()
> so I guess watermarks need updating there as well.
Did you add it after the line that sets crtc->active = false?
And the watermark update is forced by intel_crtc_atomic_check, if you need 2 wm
updates post disable
that seems like a bug..
In any case below should work then.
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 6ddb462b4124..c1f7dfb62909 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6179,6 +6179,9 @@ static void intel_crtc_disable_noatomic(struct drm_crtc
*crtc)
for_each_power_domain(domain, domains)
intel_display_power_put(dev_priv, domain);
intel_crtc->enabled_power_domains = 0;
+ intel_crtc->active = false;
+ intel_disable_shared_dpll(intel_crtc);
+ intel_update_watermarks(crtc);
}
/*
@@ -13158,7 +13161,8 @@ static int __intel_set_mode(struct drm_atomic_state
*state)
if (needs_modeset(crtc->state) && crtc->state->active) {
update_scanline_offset(to_intel_crtc(crtc));
dev_priv->display.crtc_enable(crtc);
- }
+ } else if (!crtc->state->active && crtc_state->active)
+ intel_update_watermarks(crtc);
drm_atomic_helper_commit_planes_on_crtc(crtc_state);
}
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 02/20] drm: Don't update plane properties for atomic planes if it stays the same
On Wed, Jul 08, 2015 at 10:00:22AM +0200, Maarten Lankhorst wrote:
> Op 07-07-15 om 18:43 schreef Daniel Vetter:
> > On Tue, Jul 07, 2015 at 05:08:34PM +0200, Maarten Lankhorst wrote:
> >> Op 07-07-15 om 14:10 schreef Daniel Vetter:
> >>> On Tue, Jul 07, 2015 at 12:20:10PM +0200, Maarten Lankhorst wrote:
> Op 07-07-15 om 11:18 schreef Daniel Vetter:
> > On Tue, Jul 07, 2015 at 09:08:13AM +0200, Maarten Lankhorst wrote:
> >> This allows the first atomic call during hw init to be a real modeset,
> >> which is useful for forcing a recalculation.
> > fbcon is optional, you can't rely on anything being done in any specific
> > way. What exactly do you need this for, what's the implications?
> In the hw readout I noticed some warnings when I wasn't setting any mode
> property in the readout.
> I want the first function to be the modeset, so we have a sane base to
> commit changes on.
> Ideally this whole function would have a atomic counterpart which does
> it in one go. :)
> >>> Yeah. Otoh as soon as we have atomic modeset working we can replace all
> >>> the legacy entry points with atomic helpers, and then even plane_disable
> >>> will be a full atomic modeset.
> >>>
> >>> What did fall apart with just touching properties/planes now?
> >> Also when i915 is fully atomic it calculates in
> >> intel_modeset_compute_config
> >> if a modeset is needed after the first atomic call. Right now because
> >> intel_modeset_compute_config is only called in set_config so this works as
> >> expected.
> >> Otherwise drm_plane_force_disable or rotate_0 will force a modeset,
> >> and if the final mode is different this will introduce a double modeset.
> > For expensive properties (i.e. a no-op changes causes something that takes
> > time like modeset or vblank wait) we need to make sure we filter them out
> > in atomic_check. Yeah not quite there yet with pure atomic, but meanwhile
> > the existing legacy set_prop functions should all filter out no-op changes
> > themselves. If we don't do that for rotation then that's a bug.
> >
> > Same for disabling planes harder, that shouldn't take time. Especially
> > since fbcon only force-disable non-primary plane, and for driver load
> > that's the exact thing we already do in the driver anyway.
>
> Something like this?
> ---
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index a1d4e13f3908..2989232f4996 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -30,6 +30,7 @@
> #include
> #include
> #include
> +#include "drm_crtc_internal.h"
> #include
>
> /**
> @@ -1716,7 +1717,12 @@ drm_atomic_helper_crtc_set_property(struct drm_crtc
> *crtc,
> {
> struct drm_atomic_state *state;
> struct drm_crtc_state *crtc_state;
> - int ret = 0;
> + uint64_t retval;
> + int ret;
> +
> + ret = drm_atomic_get_property(&crtc->base, property, &retval);
> + if (!ret && val == retval)
> + return 0;
>
> state = drm_atomic_state_alloc(crtc->dev);
> if (!state)
> @@ -1776,7 +1782,12 @@ drm_atomic_helper_plane_set_property(struct drm_plane
> *plane,
> {
> struct drm_atomic_state *state;
> struct drm_plane_state *plane_state;
> - int ret = 0;
> + uint64_t retval;
> + int ret;
> +
> + ret = drm_atomic_get_property(&plane->base, property, &retval);
> + if (!ret && val == retval)
> + return 0;
>
> state = drm_atomic_state_alloc(plane->dev);
> if (!state)
> @@ -1836,7 +1847,12 @@ drm_atomic_helper_connector_set_property(struct
> drm_connector *connector,
> {
> struct drm_atomic_state *state;
> struct drm_connector_state *connector_state;
> - int ret = 0;
> + uint64_t retval;
> + int ret;
> +
> + ret = drm_atomic_get_property(&connector->base, property, &retval);
> + if (!ret && val == retval)
> + return 0;
>
> state = drm_atomic_state_alloc(connector->dev);
> if (!state)
The reason I didn't do this is that a prop change might still result in no
hw state change (e.g. if you go automitic->explicit setting matching
automatic one). Hence I think we need to solve this in lower levels
anyway, i.e. in when computing the config. But it shouldn't cause trouble
yet.
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 424c83323aaa..5bab7bff8a15 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -1327,7 +1327,8 @@ void drm_plane_force_disable(struct drm_plane *plane)
> {
> int ret;
>
> - if (!plane->fb)
> + if ((plane->state && !plane->state->fb) ||
> + (!plane->state && !plane->fb))
> return;
Nah, atomic helpers should figure this out imo. Since if userspace does
the same (loop over all planes) then it won't go through force_disable.
-Daniel
>
> plane->old_fb = plane->fb;
>
--
Re: [Intel-gfx] [PATCH 1/3] drm/i915: Make fb user dirty operation to invalidate frontbuffer
On Tue, Jul 07, 2015 at 08:23:46PM +, Vivi, Rodrigo wrote:
> On Tue, 2015-07-07 at 13:24 +0200, Daniel Vetter wrote:
> > On Mon, Jul 06, 2015 at 11:19:03PM +, Vivi, Rodrigo wrote:
> > > On Mon, 2015-07-06 at 19:56 +0200, Daniel Vetter wrote:
> > > > On Mon, Jul 06, 2015 at 02:11:55PM -0300, Paulo Zanoni wrote:
> > > > > 2015-07-06 13:43 GMT-03:00 Vivi, Rodrigo :
> > > > > > On Fri, 2015-07-03 at 09:10 +0200, Daniel Vetter wrote:
> > > > > >> On Thu, Jul 02, 2015 at 04:41:32PM +, Vivi, Rodrigo wrote:
> > > > > >> > On Thu, 2015-07-02 at 13:03 -0300, Paulo Zanoni wrote:
> > > > > >> > > 2015-06-30 20:42 GMT-03:00 Rodrigo Vivi
> > > > > >> > > :
> > > > > >> > > > Let's do a frontbuffer invalidation on dirty fb.
> > > > > >> > > > To be used for DIRTYFB drm ioctl.
> > > > > >> > > >
> > > > > >> > > > This patch solves the biggest PSR known issue, that is
> > > > > >> > > > missed screen updates during boot, mainly when there is a
> > > > > >> > > > splash
> > > > > >> > > > screen involved like plymouth.
> > > > > >> > > >
> > > > > >> > > > Plymoth will do a modeset over ioctl that flushes frontbuffer
> > > > > >> > > > tracking and PSR gets back to work while it cannot track the
> > > > > >> > > > screen updates and exit properly. However plymouth also uses
> > > > > >> > > > a dirtyfb ioctl whenever updating the screen. So let's use it
> > > > > >> > > > to invalidate PSR back again.
> > > > > >> > > >
> > > > > >> > > > v2: Remove ORIGIN_FB_DIRTY and use ORIGIN_GTT instead since
> > > > > >> > > > dirty
> > > > > >> > > > callback is just called after few screen updates and not
> > > > > >> > > > on
> > > > > >> > > > everyone as pointed by Daniel.
> > > > > >> > > >
> > > > > >> > > > Cc: Daniel Vetter
> > > > > >> > > > Signed-off-by: Rodrigo Vivi
> > > > > >> > > > ---
> > > > > >> > > > drivers/gpu/drm/i915/intel_display.c | 18 ++
> > > > > >> > > > 1 file changed, 18 insertions(+)
> > > > > >> > > >
> > > > > >> > > > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > > > > >> > > > b/drivers/gpu/drm/i915/intel_display.c
> > > > > >> > > > index 724b0e3..b55b1b6 100644
> > > > > >> > > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > > > >> > > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > > > >> > > > @@ -14393,9 +14393,27 @@ static int
> > > > > >> > > > intel_user_framebuffer_create_handle(struct drm_framebuffer
> > > > > >> > > > *fb,
> > > > > >> > > > return drm_gem_handle_create(file, &obj->base,
> > > > > >> > > > handle);
> > > > > >> > > > }
> > > > > >> > > >
> > > > > >> > > > +static int intel_user_framebuffer_dirty(struct
> > > > > >> > > > drm_framebuffer *fb,
> > > > > >> > > > + struct
> > > > > >> > > > drm_file *file,
> > > > > >> > > > + unsigned
> > > > > >> > > > flags, unsigned color,
> > > > > >> > > > + struct
> > > > > >> > > > drm_clip_rect *clips,
> > > > > >> > > > + unsigned
> > > > > >> > > > num_clips)
> > > > > >> > >
> > > > > >> > > You don't need the white space on the lines above, just the
> > > > > >> > > tabs.
> > > > > >> > >
> > > > > >> > > > +{
> > > > > >> > > > + struct drm_device *dev = fb->dev;
> > > > > >> > > > + struct intel_framebuffer *intel_fb =
> > > > > >> > > > to_intel_framebuffer(fb);
> > > > > >> > > > + struct drm_i915_gem_object *obj = intel_fb->obj;
> > > > > >> > > > +
> > > > > >> > > > + mutex_lock(&dev->struct_mutex);
> > > > > >> > > > + intel_fb_obj_invalidate(obj, ORIGIN_GTT);
> > > > > >> > >
> > > > > >> > > As far as I understood from my brief investigation, the dirty
> > > > > >> > > IOCTL
> > > > > >> > > just says "hey, I'm done writing on the memory, you can flush
> > > > > >> > > things
> > > > > >> > > now", and if the user writes on the buffer again later, it
> > > > > >> > > will need
> > > > > >> > > to call the dirty IOCTL again. So shouldn't we call
> > > > > >> > > intel_fb_obj_flush(obj, false) here? It seems this was also
> > > > > >> > > pointed by
> > > > > >> > > Daniel on the first review. It would be better because it
> > > > > >> > > would allow
> > > > > >> > > us to actually keep PSR/FBC enabled.
> > > > > >> >
> > > > > >> > The flush caused by the dumb modeset ioctl is exactly what I
> > > > > >> > want to
> > > > > >> > revert here.
> > > > > >> >
> > > > > >> > Well, I just tested to double check here and flush makes me to
> > > > > >> > miss
> > > > > >> > screen updates. (triple checked with retired = true as well just
> > > > > >> > in
> > > > > >> > case)
> > > > > >> >
> > > > > >> > fbdev comes to place and invalidated frontbuffer, then plymouth
> > > > > >> > does a
> > > > > >> > flush that makes psr start working when it should continue
> > > > > >> > disabled.
> > > > > >> > Continue flushing it doesn't s
Re: [Intel-gfx] [PATCH v2 06/20] drm/i915: Allow fuzzy matching in pipe_config_compare.
On Wed, Jul 08, 2015 at 10:38:33AM +0200, Maarten Lankhorst wrote:
> Op 07-07-15 om 12:11 schreef Daniel Vetter:
> > On Tue, Jul 07, 2015 at 09:08:17AM +0200, Maarten Lankhorst wrote:
> >> @@ -12392,27 +12379,124 @@ static bool intel_fuzzy_clock_check(int clock1,
> >> int clock2)
> >>base.head) \
> >>if (mask & (1 <<(intel_crtc)->pipe))
> >>
> >> +
> >> +static bool
> >> +intel_compare_m_n(unsigned int m, unsigned int n,
> >> +unsigned int m2, unsigned int n2)
> >> +{
> >> + if (m == m2 && n == n2)
> >> + return true;
> >> +
> >> + if (!m || !n || !m2 || !n2)
> >> + return false;
> >> +
> >> + if (m > m2) {
> >> + while (m > m2) {
> > I think we need to make sure we don't reduce precision by eating low bits,
> > i.e.
> > while (m > m2 && !(m & 1) && !(n & 1)) {
> Could be useful, lets hope everyone rounds in the same way. :)
> >> + m >>= 1;
> >> + n >>= 1;
> >> + }
> >> + } else if (m < m2) {
> >> + while (m < m2) {
> >> + m2 >>= 1;
> >> + n2 >>= 1;
> >> + }
> >> + }
> >> +
> >> + return m == m2 && n == n2;
> >> +}
> >> +
> >> +static bool
> >> +intel_compare_link_m_n(const struct intel_link_m_n *m_n,
> >> + const struct intel_link_m_n *m2_n2)
> > I think these need to take adjust as an agurment and check for exact match
> > (not just matching ratio), like before.
> I just implemented it, then remembered why I didn't.
>
> It will cause a failure in intel_modeset_check_state.
That shouldn't happen. I guess the bug is that adjust doesn't live up to
it's name and doesn't copy the current value over to the new config if
they're compatible?
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
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 06/20] drm/i915: Allow fuzzy matching in pipe_config_compare.
Op 08-07-15 om 11:09 schreef Daniel Vetter:
> On Wed, Jul 08, 2015 at 10:38:33AM +0200, Maarten Lankhorst wrote:
>> Op 07-07-15 om 12:11 schreef Daniel Vetter:
>>> On Tue, Jul 07, 2015 at 09:08:17AM +0200, Maarten Lankhorst wrote:
@@ -12392,27 +12379,124 @@ static bool intel_fuzzy_clock_check(int clock1,
int clock2)
base.head) \
if (mask & (1 <<(intel_crtc)->pipe))
+
+static bool
+intel_compare_m_n(unsigned int m, unsigned int n,
+unsigned int m2, unsigned int n2)
+{
+ if (m == m2 && n == n2)
+ return true;
+
+ if (!m || !n || !m2 || !n2)
+ return false;
+
+ if (m > m2) {
+ while (m > m2) {
>>> I think we need to make sure we don't reduce precision by eating low bits,
>>> i.e.
>>> while (m > m2 && !(m & 1) && !(n & 1)) {
>> Could be useful, lets hope everyone rounds in the same way. :)
+ m >>= 1;
+ n >>= 1;
+ }
+ } else if (m < m2) {
+ while (m < m2) {
+ m2 >>= 1;
+ n2 >>= 1;
+ }
+ }
+
+ return m == m2 && n == n2;
+}
+
+static bool
+intel_compare_link_m_n(const struct intel_link_m_n *m_n,
+ const struct intel_link_m_n *m2_n2)
>>> I think these need to take adjust as an agurment and check for exact match
>>> (not just matching ratio), like before.
>> I just implemented it, then remembered why I didn't.
>>
>> It will cause a failure in intel_modeset_check_state.
> That shouldn't happen. I guess the bug is that adjust doesn't live up to
> it's name and doesn't copy the current value over to the new config if
> they're compatible?
It's a compare function, I didn't want to do adjustments in it and leaving it
as a multiple is harmless.
In case of gen >= 8 it might even fix itself through intel_dp_set_drrs_state.
~Maarten
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 07/20] drm/i915: Rework primary plane stuff slightly.
On Tue, Jul 07, 2015 at 04:02:32PM +0200, Maarten Lankhorst wrote:
> Op 07-07-15 om 13:16 schreef Daniel Vetter:
> > On Tue, Jul 07, 2015 at 09:08:18AM +0200, Maarten Lankhorst wrote:
> >> Make sure the primary plane is set up correctly. This is done by
> >> setting plane_state->src and plane_state->crtc.
> >>
> >> All non-primary planes get disabled.
> > Too terse commit message, fails to mention that this is about hw
> > readout completely. Also should mention that this removes the
> > initial_planes hack.
> >
> >> Signed-off-by: Maarten Lankhorst
> >> ---
> >> drivers/gpu/drm/i915/intel_atomic.c | 7 --
> >> drivers/gpu/drm/i915/intel_display.c | 167
> >> +--
> >> drivers/gpu/drm/i915/intel_drv.h | 2 -
> >> 3 files changed, 60 insertions(+), 116 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_atomic.c
> >> b/drivers/gpu/drm/i915/intel_atomic.c
> >> index 429677a111d5..b593612a917d 100644
> >> --- a/drivers/gpu/drm/i915/intel_atomic.c
> >> +++ b/drivers/gpu/drm/i915/intel_atomic.c
> >> @@ -98,13 +98,6 @@ int intel_atomic_check(struct drm_device *dev,
> >>return -EINVAL;
> >>}
> >>
> >> - if (crtc_state &&
> >> - crtc_state->quirks & PIPE_CONFIG_QUIRK_INITIAL_PLANES) {
> >> - ret = drm_atomic_add_affected_planes(state,
> >> &nuclear_crtc->base);
> >> - if (ret)
> >> - return ret;
> >> - }
> >> -
> >>ret = drm_atomic_helper_check_planes(dev, state);
> >>if (ret)
> >>return ret;
> >> diff --git a/drivers/gpu/drm/i915/intel_display.c
> >> b/drivers/gpu/drm/i915/intel_display.c
> >> index eb7c2e2819b7..fa1102392eca 100644
> >> --- a/drivers/gpu/drm/i915/intel_display.c
> >> +++ b/drivers/gpu/drm/i915/intel_display.c
> >> @@ -109,6 +109,7 @@ static void skl_init_scalers(struct drm_device *dev,
> >> struct intel_crtc *intel_cr
> >>struct intel_crtc_state *crtc_state);
> >> static int i9xx_get_refclk(const struct intel_crtc_state *crtc_state,
> >> int num_connectors);
> >> +static void intel_pre_disable_primary(struct drm_crtc *crtc);
> >>
> >> static struct intel_encoder *intel_find_encoder(struct intel_connector
> >> *connector, int pipe)
> >> {
> >> @@ -2582,11 +2583,12 @@ intel_find_initial_plane_obj(struct intel_crtc
> >> *intel_crtc,
> >> {
> >>struct drm_device *dev = intel_crtc->base.dev;
> >>struct drm_i915_private *dev_priv = dev->dev_private;
> >> - struct drm_crtc *c;
> >> - struct intel_crtc *i;
> >>struct drm_i915_gem_object *obj;
> >> - struct drm_plane *primary = intel_crtc->base.primary;
> >>struct drm_framebuffer *fb;
> >> + struct drm_plane *primary = intel_crtc->base.primary;
> >> + struct intel_plane *p;
> >> + struct intel_plane_state *plane_state =
> >> + to_intel_plane_state(primary->state);
> >>
> >>if (!plane_config->fb)
> >>return;
> >> @@ -2602,16 +2604,11 @@ intel_find_initial_plane_obj(struct intel_crtc
> >> *intel_crtc,
> >> * Failed to alloc the obj, check to see if we should share
> >> * an fb with another CRTC instead
> >> */
> >> - for_each_crtc(dev, c) {
> >> - i = to_intel_crtc(c);
> >> -
> >> - if (c == &intel_crtc->base)
> >> - continue;
> >> -
> >> - if (!i->active)
> >> + for_each_intel_plane(dev, p) {
> >> + if (p->base.type != DRM_PLANE_TYPE_PRIMARY)
> >>continue;
> >>
> >> - fb = c->primary->fb;
> >> + fb = p->base.state->fb;
> > This seems to break the sharing logic completely: We want to check primary
> > planes of all other crtcs to see whether we could merged the fb together.
> > We don't even read out plane state for non-primary planes, so the below fb
> > check will never be non-NULL.
> I thought this was about multiple planes sharing the same fb with same offset.
> And as such checking for the crtc is unnecessary, for the current crtc it
> will be be NULL here.
>
> This only reads out the current fb, not different ones.
>
> And sharing the same fb with other crtc's is done in intel_fbdev_init_bios.
This is about sharing the same fb but across different crtcs - bios never
enables more than the primary plane anyway. And you can't rely upon
fbdev_init_bios since that's not run at all when I915_FBDEV=n.
So yes with current code this loop here reconstruct the shared between
primary planes on different crtcs (if the stolen allocator tells us that
our range is occupied already). fbdev_init_bios just tries to create a
config matching the one the bios has set up (and then pick a suitable fb
for fbcon from the ones already allocated).
Maybe we should extract this as try_to_find_shared_fb or similar to make
the code self-explanatory?
>
> >>if (!fb)
> >>continue;
> >>
> >> @@ -2622,18 +2619,28 @@ intel_find_initial_plane_obj(struct intel_crtc
> >> *intel_crtc,
> >>}
> >>}
> >>
> >> +
Re: [Intel-gfx] [PATCH] drm/i915: Restore all GGTT VMAs on resume
On Mon, Jul 06, 2015 at 04:19:01PM +0100, Chris Wilson wrote: > On Mon, Jul 06, 2015 at 03:15:01PM +0100, Tvrtko Ursulin wrote: > > From: Tvrtko Ursulin > > > > When rotated and partial views were added no one spotted the resume > > path which assumes only one GGTT VMA per object and hence is now > > skipping rebind of alternative views. > > > > Signed-off-by: Tvrtko Ursulin > > Cc: Daniel Vetter > > Cc: Chris Wilson > > Cc: Joonas Lahtinen > > --- > > Similarly to my recent debugfs patch, it would seem quicker path could > > be to walk GGTT active & inactive lists, but I assume we want to call > > i915_gem_clflush_object only once per object which would make that > > problematic. Patch is missing offending commit that introduce this issue and which platforms are affected (I guess all due to partial view?). Also should be cc: stable I presume? Can you please supply this so I can ammend the commit message? Applied to -fixes meanwhile, thanks. -Daniel > > It's a bit easier because there are no active entries after suspend, and > we may not care too much for over clflushing. > > We should actually clear the GGTT of all but pinned entries on > hibernate (which would save a bunch of work on early resume), and there > are a bunch of non-objects inside the GGTT that should be evicted/restored > properly. (Would have been trivial had we made them all objects in the > first place.) > > The patch is in the right direction and the other issues are present > irrespective of this patch. > > I guess a begrudingly > Reviewed-by: Chris Wilson > -Chris > > -- > Chris Wilson, Intel Open Source Technology Centre -- Daniel Vetter Software Engineer, Intel Corporation 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: Update wa_ctx_emit() macro as per kernel coding guidelines
wa_ctx_emit() depends on the name of a local variable; if the name of that
variable is changed then we get compile errors. In this case it is unlikely
to be changed as this macro is only used in this set of functions but
Kernel coding guidelines doesn't recommend doing this. It was my mistake
as I should have corrected it at the beginning but missed so correct
this before there are more usages of this macro (Bob Beckett).
https://www.kernel.org/doc/Documentation/CodingStyle,
Chapter 12, "Things to avoid when using macros", point 2):
"
2) macros that depend on having a local variable with a magic name:
#define FOO(val) bar(index, val)
might look like a good thing, but it's confusing as hell when one reads the
code and it's prone to breakage from seemingly innocent changes.
"
v2: Optimization to avoid multiple evaluation of 'index' in the macro.
Since we invoke it multiple times, compiler, if it can, should be able to
coalesce
them into a single condition and remove multiple WARN_ON checks (Chris).
Suggested-by: Robert Beckett
Cc: Robert Beckett
Cc: Chris Wilson
Cc: Imre Deak
Signed-off-by: Arun Siluvery
---
drivers/gpu/drm/i915/intel_lrc.c | 79
1 file changed, 40 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 23ff018..b8a3482 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1087,12 +1087,13 @@ static int intel_logical_ring_workarounds_emit(struct
drm_i915_gem_request *req)
return 0;
}
-#define wa_ctx_emit(batch, cmd)
\
+#define wa_ctx_emit(batch, index, cmd) \
do {\
- if (WARN_ON(index >= (PAGE_SIZE / sizeof(uint32_t { \
+ int __index = (index)++;\
+ if (WARN_ON(__index >= (PAGE_SIZE / sizeof(uint32_t { \
return -ENOSPC; \
} \
- batch[index++] = (cmd); \
+ batch[__index] = (cmd); \
} while (0)
@@ -1118,29 +1119,29 @@ static inline int gen8_emit_flush_coherentl3_wa(struct
intel_engine_cs *ring,
{
uint32_t l3sqc4_flush = (0x4040 | GEN8_LQSC_FLUSH_COHERENT_LINES);
- wa_ctx_emit(batch, (MI_STORE_REGISTER_MEM_GEN8(1) |
- MI_SRM_LRM_GLOBAL_GTT));
- wa_ctx_emit(batch, GEN8_L3SQCREG4);
- wa_ctx_emit(batch, ring->scratch.gtt_offset + 256);
- wa_ctx_emit(batch, 0);
-
- wa_ctx_emit(batch, MI_LOAD_REGISTER_IMM(1));
- wa_ctx_emit(batch, GEN8_L3SQCREG4);
- wa_ctx_emit(batch, l3sqc4_flush);
-
- wa_ctx_emit(batch, GFX_OP_PIPE_CONTROL(6));
- wa_ctx_emit(batch, (PIPE_CONTROL_CS_STALL |
- PIPE_CONTROL_DC_FLUSH_ENABLE));
- wa_ctx_emit(batch, 0);
- wa_ctx_emit(batch, 0);
- wa_ctx_emit(batch, 0);
- wa_ctx_emit(batch, 0);
-
- wa_ctx_emit(batch, (MI_LOAD_REGISTER_MEM_GEN8(1) |
- MI_SRM_LRM_GLOBAL_GTT));
- wa_ctx_emit(batch, GEN8_L3SQCREG4);
- wa_ctx_emit(batch, ring->scratch.gtt_offset + 256);
- wa_ctx_emit(batch, 0);
+ wa_ctx_emit(batch, index, (MI_STORE_REGISTER_MEM_GEN8(1) |
+ MI_SRM_LRM_GLOBAL_GTT));
+ wa_ctx_emit(batch, index, GEN8_L3SQCREG4);
+ wa_ctx_emit(batch, index, ring->scratch.gtt_offset + 256);
+ wa_ctx_emit(batch, index, 0);
+
+ wa_ctx_emit(batch, index, MI_LOAD_REGISTER_IMM(1));
+ wa_ctx_emit(batch, index, GEN8_L3SQCREG4);
+ wa_ctx_emit(batch, index, l3sqc4_flush);
+
+ wa_ctx_emit(batch, index, GFX_OP_PIPE_CONTROL(6));
+ wa_ctx_emit(batch, index, (PIPE_CONTROL_CS_STALL |
+ PIPE_CONTROL_DC_FLUSH_ENABLE));
+ wa_ctx_emit(batch, index, 0);
+ wa_ctx_emit(batch, index, 0);
+ wa_ctx_emit(batch, index, 0);
+ wa_ctx_emit(batch, index, 0);
+
+ wa_ctx_emit(batch, index, (MI_LOAD_REGISTER_MEM_GEN8(1) |
+ MI_SRM_LRM_GLOBAL_GTT));
+ wa_ctx_emit(batch, index, GEN8_L3SQCREG4);
+ wa_ctx_emit(batch, index, ring->scratch.gtt_offset + 256);
+ wa_ctx_emit(batch, index, 0);
return index;
}
@@ -1201,7 +1202,7 @@ static int gen8_init_indirectctx_bb(struct
intel_engine_cs *ring,
uint32_t index = wa_ctx_start(wa_ctx, *offset, CACHELINE_DWORDS);
/* WaDisableCtxRestoreArbitration:bdw,chv */
- wa_ctx_emit(batch, MI_ARB_ON_OFF | MI_ARB_DISABLE);
+ wa_ctx_emit(batch, index, MI_ARB_ON_OFF | MI_ARB_DISABLE);
/* WaFlushCoherentL3CacheLinesAtContextSwitch:bdw */
if (IS_BR
Re: [Intel-gfx] [PATCH v2 06/20] drm/i915: Allow fuzzy matching in pipe_config_compare.
On Wed, Jul 08, 2015 at 11:18:27AM +0200, Maarten Lankhorst wrote:
> Op 08-07-15 om 11:09 schreef Daniel Vetter:
> > On Wed, Jul 08, 2015 at 10:38:33AM +0200, Maarten Lankhorst wrote:
> >> Op 07-07-15 om 12:11 schreef Daniel Vetter:
> >>> On Tue, Jul 07, 2015 at 09:08:17AM +0200, Maarten Lankhorst wrote:
> @@ -12392,27 +12379,124 @@ static bool intel_fuzzy_clock_check(int
> clock1, int clock2)
> base.head) \
> if (mask & (1 <<(intel_crtc)->pipe))
>
> +
> +static bool
> +intel_compare_m_n(unsigned int m, unsigned int n,
> + unsigned int m2, unsigned int n2)
> +{
> +if (m == m2 && n == n2)
> +return true;
> +
> +if (!m || !n || !m2 || !n2)
> +return false;
> +
> +if (m > m2) {
> +while (m > m2) {
> >>> I think we need to make sure we don't reduce precision by eating low bits,
> >>> i.e.
> >>> while (m > m2 && !(m & 1) && !(n & 1)) {
> >> Could be useful, lets hope everyone rounds in the same way. :)
> +m >>= 1;
> +n >>= 1;
> +}
> +} else if (m < m2) {
> +while (m < m2) {
> +m2 >>= 1;
> +n2 >>= 1;
> +}
> +}
> +
> +return m == m2 && n == n2;
> +}
> +
> +static bool
> +intel_compare_link_m_n(const struct intel_link_m_n *m_n,
> + const struct intel_link_m_n *m2_n2)
> >>> I think these need to take adjust as an agurment and check for exact match
> >>> (not just matching ratio), like before.
> >> I just implemented it, then remembered why I didn't.
> >>
> >> It will cause a failure in intel_modeset_check_state.
> > That shouldn't happen. I guess the bug is that adjust doesn't live up to
> > it's name and doesn't copy the current value over to the new config if
> > they're compatible?
> It's a compare function, I didn't want to do adjustments in it and leaving
> it as a multiple is harmless.
> In case of gen >= 8 it might even fix itself through intel_dp_set_drrs_state.
Well pass it the bool adjust like for config_compare. I think in general
(i.e. when it's not too much work, which isn't the case here) doing exact
matches for hw/sw state checks is the right approach.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
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 4/6] drm/i915: add FBC_IN_DBG_MASTER no_fbc_reason
On Tue, Jul 07, 2015 at 03:26:06PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> The poor in_dbg_master() check was the only one without a reason
> string. Give it a reason string so it won't feel excluded.
>
> Signed-off-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> drivers/gpu/drm/i915/intel_fbc.c | 6 +-
> 2 files changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 4ef1764..52d07fb 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -935,6 +935,7 @@ struct i915_fbc {
> FBC_MODULE_PARAM,
> FBC_CHIP_DEFAULT, /* disabled by default on this chip */
> FBC_ROTATION, /* rotation is not supported */
> + FBC_IN_DBG_MASTER, /* kernel debugger is active */
Oh dear this is dead code. kdbg uses the fbcon, which always uses
untiled, which means fbc will never be enabled. Also we have 0 users and 0
test coverage for kdbg on top of i915 (Jesse implemented it for fun years
back). Imo just remove all this code.
-Daniel
> } no_fbc_reason;
>
> bool (*fbc_enabled)(struct drm_i915_private *dev_priv);
> diff --git a/drivers/gpu/drm/i915/intel_fbc.c
> b/drivers/gpu/drm/i915/intel_fbc.c
> index 9ef5b6c..8d39893 100644
> --- a/drivers/gpu/drm/i915/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/intel_fbc.c
> @@ -471,6 +471,8 @@ const char *intel_no_fbc_reason_str(enum no_fbc_reason
> reason)
> return "disabled per chip default";
> case FBC_ROTATION:
> return "rotation unsupported";
> + case FBC_IN_DBG_MASTER:
> + return "Kernel debugger is active";
> default:
> MISSING_CASE(reason);
> return "unknown reason";
> @@ -755,8 +757,10 @@ static void __intel_fbc_update(struct drm_i915_private
> *dev_priv)
> }
>
> /* If the kernel debugger is active, always disable compression */
> - if (in_dbg_master())
> + if (in_dbg_master()) {
> + set_no_fbc_reason(dev_priv, FBC_IN_DBG_MASTER);
> goto out_disable;
> + }
>
> if (intel_fbc_setup_cfb(dev_priv, obj->base.size,
> drm_format_plane_cpp(fb->pixel_format, 0))) {
> --
> 2.1.4
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Update wa_ctx_emit() macro as per kernel coding guidelines
On Wed, Jul 08, 2015 at 10:27:05AM +0100, Arun Siluvery wrote: > wa_ctx_emit() depends on the name of a local variable; if the name of that > variable is changed then we get compile errors. In this case it is unlikely > to be changed as this macro is only used in this set of functions but > Kernel coding guidelines doesn't recommend doing this. It was my mistake > as I should have corrected it at the beginning but missed so correct > this before there are more usages of this macro (Bob Beckett). > > https://www.kernel.org/doc/Documentation/CodingStyle, > Chapter 12, "Things to avoid when using macros", point 2): > > " > 2) macros that depend on having a local variable with a magic name: > >#define FOO(val) bar(index, val) > > might look like a good thing, but it's confusing as hell when one reads the > code and it's prone to breakage from seemingly innocent changes. > " > > v2: Optimization to avoid multiple evaluation of 'index' in the macro. > Since we invoke it multiple times, compiler, if it can, should be able to > coalesce > them into a single condition and remove multiple WARN_ON checks (Chris). > > Suggested-by: Robert Beckett > Cc: Robert Beckett > Cc: Chris Wilson > Cc: Imre Deak > Signed-off-by: Arun Siluvery Simple mechanical change, Reviewed-by: Chris Wilson -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 0/6] FBC bikesheds
On Tue, Jul 07, 2015 at 08:53:23PM +0100, Chris Wilson wrote: > On Tue, Jul 07, 2015 at 03:26:02PM -0300, Paulo Zanoni wrote: > > From: Paulo Zanoni > > > > Before I continue sending fixes, let's just do some small adjustments to the > > codebase. I really think these changes make the code better to work with, > > but > > maybe not everybody agrees. Let's find out :) > > > > Paulo Zanoni (6): > > drm/i915: move FBC vfuncs to struct i915_fbc > > drm/i915: use dev_priv for the FBC functions > > drm/i915: use intel_crtc for the FBC functions > > drm/i915: add FBC_IN_DBG_MASTER no_fbc_reason > > drm/i915: extract FBC_MULTIPLE_PIPES check > > drm/i915: move set_no_fbc_reason() call out of intel_fbc_find_crtc() > > Reviewed-by: Chris Wilson All applied to dinq, thanks. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Adjust BXT HDMI port clock limits
On 7/6/2015 5:14 PM, ville.syrj...@linux.intel.com wrote: From: Ville Syrjälä Since commit e62925567c7926e78bc8ca976cde5c28ea265a49 Author: Vandana Kannan Date: Wed Jul 1 17:02:57 2015 +0530 drm/i915/bxt: BUNs related to port PLL BXT DPLL can now generate frequencies in the 216-223 MHz range. Adjust the HDMI port clock checks to account for the reduced range of invalid frequencies. Cc: Vandana Kannan Cc: Imre Deak Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_hdmi.c | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c index c7e912b..70bad5b 100644 --- a/drivers/gpu/drm/i915/intel_hdmi.c +++ b/drivers/gpu/drm/i915/intel_hdmi.c @@ -1174,9 +1174,12 @@ hdmi_port_clock_valid(struct intel_hdmi *hdmi, if (clock > hdmi_port_clock_limit(hdmi, respect_dvi_limit)) return MODE_CLOCK_HIGH; - /* CHV/BXT DPLL can't generate 216-240 MHz */ - if ((IS_CHERRYVIEW(dev) || IS_BROXTON(dev)) && - clock > 216000 && clock < 24) + /* BXT DPLL can't generate 223-240 MHz */ + if (IS_BROXTON(dev) && clock > 22 && clock < 24) + return MODE_CLOCK_RANGE; + BSpec needs an update based on this ? It shows " HDMI/DVI link rates: 0.2 to 3.0 GHz Non-SSC* *2.17 - 2.4 GHz not supported " - Vandana + /* CHV DPLL can't generate 216-240 MHz */ + if (IS_CHERRYVIEW(dev) && clock > 216000 && clock < 24) return MODE_CLOCK_RANGE; return MODE_OK; ___ 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: fbdev_set_par reliably invalidating frontbuffer
On Tue, Jul 07, 2015 at 04:28:56PM -0700, Rodrigo Vivi wrote:
> fbdev_set_par is called when fbcon is taking over control, but
> frontbuffer was being invalidated only on the first time when
> moving obj to GTT domain.
> However on the following calls write domain was already GTT
> so invalidate was never called again.
>
> The issue was mainly on boot with plymouth doing a splash screen
> when returning to the console frontbuffer wans't being invalidated
> causing missed screen updates with PSR enabled.
>
> Cc: Daniel Vetter
> Signed-off-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/intel_fbdev.c | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
> b/drivers/gpu/drm/i915/intel_fbdev.c
> index 2a1724e..a76cebc 100644
> --- a/drivers/gpu/drm/i915/intel_fbdev.c
> +++ b/drivers/gpu/drm/i915/intel_fbdev.c
> @@ -50,6 +50,7 @@ static int intel_fbdev_set_par(struct fb_info *info)
> struct drm_fb_helper *fb_helper = info->par;
> struct intel_fbdev *ifbdev =
> container_of(fb_helper, struct intel_fbdev, helper);
> + struct drm_i915_gem_object *obj = ifbdev->fb->obj;
> int ret;
>
> ret = drm_fb_helper_set_par(info);
> @@ -63,8 +64,13 @@ static int intel_fbdev_set_par(struct fb_info *info)
>* now until we solve this for real.
>*/
> mutex_lock(&fb_helper->dev->struct_mutex);
> - ret = i915_gem_object_set_to_gtt_domain(ifbdev->fb->obj,
> - true);
> + if (obj) {
> + if (obj->base.write_domain != I915_GEM_DOMAIN_GTT)
> + ret = i915_gem_object_set_to_gtt_domain(obj,
> + true);
> + else
> + intel_fb_obj_invalidate(obj, ORIGIN_GTT);
Unconditional intel_fb_obj_invalidate is what we need here really. And for
reference maybe mention the commit that fixed this for the set_domain
ioctl:
commit 031b698a77a70a6c394568034437b5486a44e868
Author: Daniel Vetter
Date: Fri Jun 26 19:35:16 2015 +0200
drm/i915: Unconditionally do fb tracking invalidate in set_domain
> + }
> mutex_unlock(&fb_helper->dev->struct_mutex);
> }
>
> --
> 2.1.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
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 3/7] drm/i915: PSR: dirty fb operation flushsing frontbuffer
On Tue, Jul 07, 2015 at 04:28:53PM -0700, Rodrigo Vivi wrote:
> Let's do a frontbuffer flush on dirty fb.
> To be used for DIRTYFB drm ioctl.
>
> This patch solves the biggest PSR known issue, that is
> missed screen updates during boot, mainly when there is a splash
> screen involved like Plymouth.
>
> Previously PSR was being invalidated by fbdev and Plymounth
> was taking control with PSR yet invalidated and could get screen
> updates normally. However with some atomic modeset changes
> Pymouth modeset over ioctl was now causing frontbuffer flushes
> making PSR gets back to work while it cannot track the
> screen updates and exit properly.
>
> By adding this flush on dirtyfb we properly track frontbuffer
> writes and properly exit PSR.
>
> Actually all mmap_wc users should call this dirty callback
> in order to have a proper frontbuffer tracking.
>
> In the future it can be extended to return 0 if the whole
> screen has being flushed or the number of rects flushed
> as Chris suggested.
>
> v2: Remove ORIGIN_FB_DIRTY and use ORIGIN_GTT instead since dirty
> callback is just called after few screen updates and not on
> everyone as pointed by Daniel.
>
> v3: Use flush instead of invalidate since flush means
> invalidate + flush and dirty means drawn had finished and
> it can be flushed.
>
> Cc: Chris Wilson
> Cc: Paulo Zanoni
> Cc: Daniel Vetter
> Signed-off-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/intel_display.c | 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 3c2425f..9a60d15 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -14383,9 +14383,27 @@ static int
> intel_user_framebuffer_create_handle(struct drm_framebuffer *fb,
> return drm_gem_handle_create(file, &obj->base, handle);
> }
>
> +static int intel_user_framebuffer_dirty(struct drm_framebuffer *fb,
> +struct drm_file *file,
> +unsigned flags, unsigned color,
> +struct drm_clip_rect *clips,
> +unsigned num_clips)
> +{
> + struct drm_device *dev = fb->dev;
> + struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb);
> + struct drm_i915_gem_object *obj = intel_fb->obj;
> +
> + mutex_lock(&dev->struct_mutex);
> + intel_fb_obj_flush(obj, false, ORIGIN_GTT);
> + mutex_unlock(&dev->struct_mutex);
There's some good discussion going on in some internal thread about what
to do with wc mmaps. The idea is to use the dirty ioctl to flush them, but
at least for fbc we already filter ORIGIN_GTT out, which means fbc won't
see the dirtyfb flushes for cpu wc mmaps. Should we have a ORIGIN_DIRTYFB,
which essentially just means "any kind of cpu frontbuffer rendering"?
Otoh we can make this change when Paulo implements the wc-mmap for
frontbuffers stuff.
-Daniel
> +
> + return 0;
> +}
> +
> static const struct drm_framebuffer_funcs intel_fb_funcs = {
> .destroy = intel_user_framebuffer_destroy,
> .create_handle = intel_user_framebuffer_create_handle,
> + .dirty = intel_user_framebuffer_dirty,
> };
>
> static
> --
> 2.1.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Restore all GGTT VMAs on resume
On 07/08/2015 10:32 AM, Daniel Vetter wrote: On Mon, Jul 06, 2015 at 04:19:01PM +0100, Chris Wilson wrote: On Mon, Jul 06, 2015 at 03:15:01PM +0100, Tvrtko Ursulin wrote: From: Tvrtko Ursulin When rotated and partial views were added no one spotted the resume path which assumes only one GGTT VMA per object and hence is now skipping rebind of alternative views. Signed-off-by: Tvrtko Ursulin Cc: Daniel Vetter Cc: Chris Wilson Cc: Joonas Lahtinen --- Similarly to my recent debugfs patch, it would seem quicker path could be to walk GGTT active & inactive lists, but I assume we want to call i915_gem_clflush_object only once per object which would make that problematic. Patch is missing offending commit that introduce this issue and which platforms are affected (I guess all due to partial view?). Also should be cc: stable I presume? Can you please supply this so I can ammend the commit message? Applied to -fixes meanwhile, thanks. Ha, "offending" commits. In the sense of that the bug only manifests when they are present they are either of these two: commit c5ad54cf7dd8922bd1cee2d5871aebf73dc9638e Author: Joonas Lahtinen Date: Wed May 6 14:36:09 2015 +0300 drm/i915: Use partial view in mmap fault handler commit 3b7a5119b5d2def1161226a4c6a643db537dff7e Author: Sonika Jindal Date: Fri Apr 10 14:37:29 2015 +0530 drm/i915/skl: Support for 90/270 rotation But they are just the tips of two longish streams of developments so they should not necessarily be viewed as offending towards the respective authors. They are just final feature enablements. All platforms are affected due to partial views I suppose, although I am not sure if they are actually used/triggered in the field. That's why I was not sure should stable be copied. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/6] drm/i915: add FBC_IN_DBG_MASTER no_fbc_reason
On Wed, Jul 08, 2015 at 11:38:02AM +0200, Daniel Vetter wrote:
> On Tue, Jul 07, 2015 at 03:26:06PM -0300, Paulo Zanoni wrote:
> > From: Paulo Zanoni
> >
> > The poor in_dbg_master() check was the only one without a reason
> > string. Give it a reason string so it won't feel excluded.
> >
> > Signed-off-by: Paulo Zanoni
> > ---
> > drivers/gpu/drm/i915/i915_drv.h | 1 +
> > drivers/gpu/drm/i915/intel_fbc.c | 6 +-
> > 2 files changed, 6 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 4ef1764..52d07fb 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -935,6 +935,7 @@ struct i915_fbc {
> > FBC_MODULE_PARAM,
> > FBC_CHIP_DEFAULT, /* disabled by default on this chip */
> > FBC_ROTATION, /* rotation is not supported */
> > + FBC_IN_DBG_MASTER, /* kernel debugger is active */
>
> Oh dear this is dead code. kdbg uses the fbcon, which always uses
> untiled, which means fbc will never be enabled. Also we have 0 users and 0
> test coverage for kdbg on top of i915 (Jesse implemented it for fun years
> back). Imo just remove all this code.
A good kdbg integration would allow us to do allsorts of kprobes
debugging and igt fun. Ok, we could probably use kprobes...
* hatches evil plan to learn kprobes
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Restore all GGTT VMAs on resume
On Wed, Jul 08, 2015 at 10:45:23AM +0100, Tvrtko Ursulin wrote: > > On 07/08/2015 10:32 AM, Daniel Vetter wrote: > >On Mon, Jul 06, 2015 at 04:19:01PM +0100, Chris Wilson wrote: > >>On Mon, Jul 06, 2015 at 03:15:01PM +0100, Tvrtko Ursulin wrote: > >>>From: Tvrtko Ursulin > >>> > >>>When rotated and partial views were added no one spotted the resume > >>>path which assumes only one GGTT VMA per object and hence is now > >>>skipping rebind of alternative views. > >>> > >>>Signed-off-by: Tvrtko Ursulin > >>>Cc: Daniel Vetter > >>>Cc: Chris Wilson > >>>Cc: Joonas Lahtinen > >>>--- > >>>Similarly to my recent debugfs patch, it would seem quicker path could > >>>be to walk GGTT active & inactive lists, but I assume we want to call > >>>i915_gem_clflush_object only once per object which would make that > >>>problematic. > > > >Patch is missing offending commit that introduce this issue and which > >platforms are affected (I guess all due to partial view?). Also should be > >cc: stable I presume? > > > >Can you please supply this so I can ammend the commit message? Applied to > >-fixes meanwhile, thanks. > > Ha, "offending" commits. In the sense of that the bug only manifests > when they are present they are either of these two: > > commit c5ad54cf7dd8922bd1cee2d5871aebf73dc9638e > Author: Joonas Lahtinen > Date: Wed May 6 14:36:09 2015 +0300 > > drm/i915: Use partial view in mmap fault handler > > commit 3b7a5119b5d2def1161226a4c6a643db537dff7e > Author: Sonika Jindal > Date: Fri Apr 10 14:37:29 2015 +0530 > > drm/i915/skl: Support for 90/270 rotation > > But they are just the tips of two longish streams of developments > so they should not necessarily be viewed as offending towards the respective > authors. They are just final feature enablements. > > All platforms are affected due to partial views I suppose, although I am not > sure if they are actually used/triggered in the field. That's why I was not > sure should stable be copied. Well commits are only in 4.2, so -fixes is ok. Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation 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 2/2] drm/i915: Use crtc_state->active in primary check_plane func
Op 07-07-15 om 11:15 schreef Daniel Vetter:
> Since
>
> commit 8c7b5ccb729870e606321b3703e2c2e698c49a95
> Author: Ander Conselvan de Oliveira
> Date: Tue Apr 21 17:13:19 2015 +0300
>
> drm/i915: Use atomic helpers for computing changed flags
>
> we compute the plane state for a modeset before actually committing
> any changes, which means crtc->active won't be correct yet. Looking at
> future work in the modeset conversion targetting 4.3 the only places
> where crtc_state->active isn't accurate is when disabling other CRTCs
> than the one the modeset is for (when stealing connectors). Which
> isn't the case here. And that's also confirmed by an audit, we do
> unconditionally update crtc_state->active for the current pipe.
>
> We also don't need to update any other plane check functions since we
> only ever add the primary state to the modeset update right now.
>
> Cc: Ander Conselvan de Oliveira
> Cc: Maarten Lankhorst
> Cc: Jani Nikula
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/intel_display.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 647b1404c441..ba9321998a41 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -13276,7 +13276,7 @@ intel_check_primary_plane(struct drm_plane *plane,
> if (ret)
> return ret;
>
> - if (intel_crtc->active) {
> + if (crtc_state->base.active) {
> struct intel_plane_state *old_state =
> to_intel_plane_state(plane->state);
>
I think this was probably a feature, not a bug. Since full atomic planes won't
be part of v4.2
both patches look ok to me.
Reviewed-by: Maarten Lankhorst
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Resign firmware loading for dmc
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) Task id: 6744 -Summary- Platform Delta drm-intel-nightly Series Applied ILK 302/302 302/302 SNB 312/316 312/316 IVB 343/343 343/343 BYT -2 287/287 285/287 HSW 380/380 380/380 -Detailed- Platform Testdrm-intel-nightly Series Applied *BYT igt@gem_partial_pwrite_pread@reads PASS(1) FAIL(1) *BYT igt@gem_tiled_partial_pwrite_pread@reads PASS(1) FAIL(1) Note: You need to pay more attention to line start with '*' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 14/18] drm/i915: object size needs to be u64
On 7/7/2015 9:08 PM, Chris Wilson wrote:
On Tue, Jul 07, 2015 at 04:44:30PM +0100, Michel Thierry wrote:
On 7/7/2015 4:27 PM, Chris Wilson wrote:
On Tue, Jul 07, 2015 at 04:14:59PM +0100, Michel Thierry wrote:
In a 48b world, users can try to allocate buffers bigger than 4GB; in
these cases it is important that size is a 64b variable.
Also added a warning for illegal bind with size = 0.
Signed-off-by: Michel Thierry
---
drivers/gpu/drm/i915/i915_gem.c | 5 +++--
drivers/gpu/drm/i915/i915_gem_gtt.c | 3 +++
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index a0bff41..ebfb789 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3718,7 +3718,8 @@ i915_gem_object_bind_to_vm(struct drm_i915_gem_object
*obj,
{
struct drm_device *dev = obj->base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
- u32 size, fence_size, fence_alignment, unfenced_alignment;
+ u32 fence_alignment, unfenced_alignment;
+ u64 size, fence_size;
u64 start =
flags & PIN_OFFSET_BIAS ? flags & PIN_OFFSET_MASK : 0;
u64 end =
@@ -3777,7 +3778,7 @@ i915_gem_object_bind_to_vm(struct drm_i915_gem_object
*obj,
* attempt to find space.
*/
if (size > end) {
- DRM_DEBUG("Attempting to bind an object (view type=%u) larger than the
aperture: size=%u > %s aperture=%llu\n",
+ DRM_DEBUG("Attempting to bind an object (view type=%u) larger than the
aperture: size=%llu > %s aperture=%llu\n",
ggtt_view ? ggtt_view->type : 0,
size,
flags & PIN_MAPPABLE ? "mappable" : "total",
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 449a245..900bce6 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -3312,6 +3312,9 @@ int i915_vma_bind(struct i915_vma *vma, enum
i915_cache_level cache_level,
if (WARN_ON(flags == 0))
return -EINVAL;
+ if (WARN_ON(vma->node.size == 0))
+ return -EINVAL;
This is superfluous. We don't allow size=0 object creation, and the test
is better (if at all) at vma_create, but what you mean here is
WARN_ON(!drm_mm_node_allocated()) which seems sensisble. And both of
these would be better as ENODEV so we don't confuse the user when they
get propagated back to userspace.
-Chris
My idea was to catch the node.size overflow if the variable is
inadvertently changed back to u32 (which has already happen in other
places).
Ok, that didn't come across when I just read node.size == 0 (what are
chances that node.size was exactly 2^32 and then truncated?)
Only a test explicitly looking for this kind of issues (I guess). In
that test, objects bigger than 2^32 were truncated, while objects
exactly 2^32 were hitting a WARN in the driver; alloc_pages wouldn't do
anything because node.size == 0, and then insert would complain no pages
existed.
vma->node should be fairly opaque, and if possible we want the checks in
drm_mm.c - if we can think of good tests for that layer.
Certainly drm_mm_reserve_node() probably wants a few sanity checks.
Though most of those should fall out when it can't do the reservation
the user requests.
Or change drm_mm_insert_node_in_range_generic() to warn when size==0?
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/2] I915 GEM context updates
On Wed, Jul 01, 2015 at 05:23:51PM +0200, Daniel Vetter wrote: > On Wed, Jul 1, 2015 at 2:21 PM, David Weinehall > wrote: > > On Tue, Jun 30, 2015 at 03:01:06PM +0100, Chris Wilson wrote: > >> On Tue, Jun 30, 2015 at 04:36:55PM +0300, David Weinehall wrote: > >> > On Tue, Jun 30, 2015 at 02:32:19PM +0100, Chris Wilson wrote: > >> > > On Tue, Jun 30, 2015 at 04:01:23PM +0300, David Weinehall wrote: > >> > > > On Tue, Jun 30, 2015 at 01:49:27PM +0100, Chris Wilson wrote: > >> > > > > On Tue, Jun 30, 2015 at 03:24:51PM +0300, David Weinehall wrote: > >> > > > > > This patch contains a few minor updates related to > >> > > > > > I915 GEM context. > >> > > > > > >> > > > > As a kernel API, this is absolutely awful. Can we please correct > >> > > > > it before > >> > > > > it is released? > >> > > > > >> > > > Daniel has already merged it and didn't have any objections, so > >> > > > you'll > >> > > > have to convince him, not me. > >> > > > > >> > > > If you believe it's awful, feel free to provide a better > >> > > > implementation. > >> > > > >> > > As I recall, I did. > >> > > >> > Hmmm, I must've missed your patch -- if so I apologise. What was the > >> > title of the post, and how come Daniel hasn't merged that one instead? > >> > >> I gave details on a comment to your patch, where I thought the api could > >> be improved. > > > > Yeah, I got the bits about you not liking the approach, but the things > > you write in this e-mail are the first suggestions that I find concrete > > enough for me to actually know what you want instead. > > Imo NONZEROMAP is still good to go, and good enough for > opencl/beignet. Allowing more fancy placement constraints might be > useful eventually, but thus far I haven't seen a compelling reason > really. Or not compelling enough at least. > > And I don't think there's a point in blocking beignet for something > too fancy. Hence this still has my Ack. It gets the (really specific) > job done for beignet, which seems good enough. OK, so where do we stand on this? Daniel is OK with the patch (and has merged the kernel side). The last post regarding this on the libdrm list is that Chris objects, meaning that no one is likely to pick up that patch and merge it to libdrm, meaning it's dead in the water until a follow-up comment. Regards, David ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Handle HPD when it has actually occurred
Writing to PCH_PORT_HOTPLUG for each interrupt is not required.
Handle it only if hpd has actually occurred like we handle other
interrupts.
v2: Make few variables local to if block (Ville)
v3: Add check for ibx/cpt both (Ville).
While at it, remove the redundant check for hotplug_trigger from
pch_get_hpd_pins
v4: Indentation (Ville)
Reviewed-by: Ville Syrjälä
Signed-off-by: Sonika Jindal
---
drivers/gpu/drm/i915/i915_irq.c | 32 +---
1 file changed, 17 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index a6fbe64..a897f68 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1266,9 +1266,6 @@ static void pch_get_hpd_pins(u32 *pin_mask, u32
*long_mask,
*pin_mask = 0;
*long_mask = 0;
- if (!hotplug_trigger)
- return;
-
for_each_hpd_pin(i) {
if ((hpd[i] & hotplug_trigger) == 0)
continue;
@@ -1658,14 +1655,17 @@ static void ibx_irq_handler(struct drm_device *dev, u32
pch_iir)
struct drm_i915_private *dev_priv = dev->dev_private;
int pipe;
u32 hotplug_trigger = pch_iir & SDE_HOTPLUG_MASK;
- u32 dig_hotplug_reg;
- u32 pin_mask, long_mask;
- dig_hotplug_reg = I915_READ(PCH_PORT_HOTPLUG);
- I915_WRITE(PCH_PORT_HOTPLUG, dig_hotplug_reg);
+ if (hotplug_trigger) {
+ u32 dig_hotplug_reg, pin_mask, long_mask;
- pch_get_hpd_pins(&pin_mask, &long_mask, hotplug_trigger,
dig_hotplug_reg, hpd_ibx);
- intel_hpd_irq_handler(dev, pin_mask, long_mask);
+ dig_hotplug_reg = I915_READ(PCH_PORT_HOTPLUG);
+ I915_WRITE(PCH_PORT_HOTPLUG, dig_hotplug_reg);
+
+ pch_get_hpd_pins(&pin_mask, &long_mask, hotplug_trigger,
+dig_hotplug_reg, hpd_ibx);
+ intel_hpd_irq_handler(dev, pin_mask, long_mask);
+ }
if (pch_iir & SDE_AUDIO_POWER_MASK) {
int port = ffs((pch_iir & SDE_AUDIO_POWER_MASK) >>
@@ -1757,14 +1757,16 @@ static void cpt_irq_handler(struct drm_device *dev, u32
pch_iir)
struct drm_i915_private *dev_priv = dev->dev_private;
int pipe;
u32 hotplug_trigger = pch_iir & SDE_HOTPLUG_MASK_CPT;
- u32 dig_hotplug_reg;
- u32 pin_mask, long_mask;
- dig_hotplug_reg = I915_READ(PCH_PORT_HOTPLUG);
- I915_WRITE(PCH_PORT_HOTPLUG, dig_hotplug_reg);
+ if (hotplug_trigger) {
+ u32 dig_hotplug_reg, pin_mask, long_mask;
- pch_get_hpd_pins(&pin_mask, &long_mask, hotplug_trigger,
dig_hotplug_reg, hpd_cpt);
- intel_hpd_irq_handler(dev, pin_mask, long_mask);
+ dig_hotplug_reg = I915_READ(PCH_PORT_HOTPLUG);
+ I915_WRITE(PCH_PORT_HOTPLUG, dig_hotplug_reg);
+ pch_get_hpd_pins(&pin_mask, &long_mask, hotplug_trigger,
+dig_hotplug_reg, hpd_cpt);
+ intel_hpd_irq_handler(dev, pin_mask, long_mask);
+ }
if (pch_iir & SDE_AUDIO_POWER_MASK_CPT) {
int port = ffs((pch_iir & SDE_AUDIO_POWER_MASK_CPT) >>
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Improve DP downstream HPD handling
On 7/7/2015 5:50 PM, Sivakumar Thulasimani wrote:
On 7/7/2015 5:24 PM, Ville Syrjälä wrote:
On Tue, Jul 07, 2015 at 02:37:46PM +0300, Ville Syrjälä wrote:
On Tue, Jul 07, 2015 at 04:45:11PM +0530, Sivakumar Thulasimani wrote:
On 7/7/2015 4:40 PM, Ville Syrjälä wrote:
On Tue, Jul 07, 2015 at 03:26:36PM +0530, Sivakumar Thulasimani
wrote:
On 7/6/2015 5:42 PM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä
DP dongles may signal downstream HPD via short HPD pulses. If we
know
the device has a HPD capable downstream port, make sure we kick
off the
full hotplug processing even for short HPDs.
Additonally setting the sink to DPMS off kills the downstream
HPD (at
least on my DP->VGA dongle), so skip the DPMS off for such dongles
when we turn off the port.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_dp.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c
b/drivers/gpu/drm/i915/intel_dp.c
index e88cec2..f424833 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2324,6 +2324,13 @@ static void intel_dp_get_config(struct
intel_encoder *encoder,
}
}
+static bool intel_dp_has_downstream_hpd(struct intel_dp
*intel_dp)
+{
+return intel_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT] &
DP_DWN_STRM_PORT_PRESENT &&
+intel_dp->dpcd[DP_DPCD_REV] >= 0x11 &&
+intel_dp->downstream_ports[0] & DP_DS_PORT_HPD;
+}
+
static void intel_disable_dp(struct intel_encoder *encoder)
{
struct intel_dp *intel_dp =
enc_to_intel_dp(&encoder->base);
@@ -2340,7 +2347,9 @@ static void intel_disable_dp(struct
intel_encoder *encoder)
* ensure that we have vdd while we switch off the
panel. */
intel_edp_panel_vdd_on(intel_dp);
intel_edp_backlight_off(intel_dp);
-intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
+/* Skip power down to keep downstream HPD working */
+if (!intel_dp_has_downstream_hpd(intel_dp))
+intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
intel_edp_panel_off(intel_dp);
/* disable the port before the pipe on g4x */
@@ -4944,6 +4953,13 @@ intel_dp_hpd_pulse(struct
intel_digital_port *intel_dig_port, bool long_hpd)
drm_modeset_lock(&dev->mode_config.connection_mutex, NULL);
intel_dp_check_link_status(intel_dp);
drm_modeset_unlock(&dev->mode_config.connection_mutex);
+
+/*
+ * Downstream HPD will generate a short HPD,
+ * so we want full hotplug processing here.
+ */
+if (intel_dp_has_downstream_hpd(intel_dp))
+goto put_power;
}
}
I am looking into compliance changes for DP and this seems a
relevant
change for compliance as well. but as per Link CTS 1.2 section
4.2.2.8,
we are supposed to read the sink_count and do full detection if
sink_count is >1. So instead of checking for DP_DS_PORT_HPD can
we just
check SINK_COUNT and do full detect ?
->detect() will be called from the hotplug work and that will
check SINK_COUNT.
No, the Compliance Sink tool, will not set the DP_DS_PORT_HPD
resulting
in detect not getting executed for
the short pulse generated. The spec requires the sink to set only the
sink count so it is not a must for
the sink to update the DP_DOWNSTREAM_PORT_0. so only a check for
SINK_COUNT will pass the
compliance test.
That seems stupid. If the downstream port isn't HPD capable then we
have
no reason to check SINK_COUNT after a short HPD as the short HPD
coudln't have been caused by a downstram HPD. Obviuously we still
check SINK_COUNT after a long HPD to figure out if anything is
connected
when the branch device itself gets connected to the source.
Actually that's not correct. We don't check SINK_COUNT unless the
downstream
port is HPD capable.
The spec says:
"If the DFP does not provide for means for plug/unplug detection, the
adaptor must set the SINK_COUNT field bits, as if those Sink devices
were
all permanently plugged."
So according to the there can't be any changes in SINK_COUNT if the
downstream port is not HPD capable.
yes, agree on the no changes for SINK_COUNT if HPD is 0. i'll check
with DP Compliance test
tomorrow and confirm the exact reason for its failure may be my
understanding of it was incorrect.
confirmed that the compliance sink is not setting HPD bit during detect.
so this looks to be a bug in
the sink tool. i'll file a bug with their team instead.
coming back to this patch, i will get back once i understand the complex
scenario of all short pulse
is treated as long pulse post this change, for example: we will do full
detection even if the sink requested
retraining of link.
--
regards,
Sivakumar
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Improve DP downstream HPD handling
On Wed, Jul 08, 2015 at 05:50:05PM +0530, Sivakumar Thulasimani wrote:
>
>
> On 7/7/2015 5:50 PM, Sivakumar Thulasimani wrote:
> >
> >
> > On 7/7/2015 5:24 PM, Ville Syrjälä wrote:
> >> On Tue, Jul 07, 2015 at 02:37:46PM +0300, Ville Syrjälä wrote:
> >>> On Tue, Jul 07, 2015 at 04:45:11PM +0530, Sivakumar Thulasimani wrote:
>
> On 7/7/2015 4:40 PM, Ville Syrjälä wrote:
> > On Tue, Jul 07, 2015 at 03:26:36PM +0530, Sivakumar Thulasimani
> > wrote:
> >> On 7/6/2015 5:42 PM, ville.syrj...@linux.intel.com wrote:
> >>> From: Ville Syrjälä
> >>>
> >>> DP dongles may signal downstream HPD via short HPD pulses. If we
> >>> know
> >>> the device has a HPD capable downstream port, make sure we kick
> >>> off the
> >>> full hotplug processing even for short HPDs.
> >>>
> >>> Additonally setting the sink to DPMS off kills the downstream
> >>> HPD (at
> >>> least on my DP->VGA dongle), so skip the DPMS off for such dongles
> >>> when we turn off the port.
> >>>
> >>> Signed-off-by: Ville Syrjälä
> >>> ---
> >>> drivers/gpu/drm/i915/intel_dp.c | 18 +-
> >>> 1 file changed, 17 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/intel_dp.c
> >>> b/drivers/gpu/drm/i915/intel_dp.c
> >>> index e88cec2..f424833 100644
> >>> --- a/drivers/gpu/drm/i915/intel_dp.c
> >>> +++ b/drivers/gpu/drm/i915/intel_dp.c
> >>> @@ -2324,6 +2324,13 @@ static void intel_dp_get_config(struct
> >>> intel_encoder *encoder,
> >>> }
> >>> }
> >>> +static bool intel_dp_has_downstream_hpd(struct intel_dp
> >>> *intel_dp)
> >>> +{
> >>> +return intel_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT] &
> >>> DP_DWN_STRM_PORT_PRESENT &&
> >>> +intel_dp->dpcd[DP_DPCD_REV] >= 0x11 &&
> >>> +intel_dp->downstream_ports[0] & DP_DS_PORT_HPD;
> >>> +}
> >>> +
> >>> static void intel_disable_dp(struct intel_encoder *encoder)
> >>> {
> >>> struct intel_dp *intel_dp =
> >>> enc_to_intel_dp(&encoder->base);
> >>> @@ -2340,7 +2347,9 @@ static void intel_disable_dp(struct
> >>> intel_encoder *encoder)
> >>> * ensure that we have vdd while we switch off the
> >>> panel. */
> >>> intel_edp_panel_vdd_on(intel_dp);
> >>> intel_edp_backlight_off(intel_dp);
> >>> -intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
> >>> +/* Skip power down to keep downstream HPD working */
> >>> +if (!intel_dp_has_downstream_hpd(intel_dp))
> >>> +intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
> >>> intel_edp_panel_off(intel_dp);
> >>> /* disable the port before the pipe on g4x */
> >>> @@ -4944,6 +4953,13 @@ intel_dp_hpd_pulse(struct
> >>> intel_digital_port *intel_dig_port, bool long_hpd)
> >>> drm_modeset_lock(&dev->mode_config.connection_mutex, NULL);
> >>> intel_dp_check_link_status(intel_dp);
> >>> drm_modeset_unlock(&dev->mode_config.connection_mutex);
> >>> +
> >>> +/*
> >>> + * Downstream HPD will generate a short HPD,
> >>> + * so we want full hotplug processing here.
> >>> + */
> >>> +if (intel_dp_has_downstream_hpd(intel_dp))
> >>> +goto put_power;
> >>> }
> >>> }
> >> I am looking into compliance changes for DP and this seems a
> >> relevant
> >> change for compliance as well. but as per Link CTS 1.2 section
> >> 4.2.2.8,
> >> we are supposed to read the sink_count and do full detection if
> >> sink_count is >1. So instead of checking for DP_DS_PORT_HPD can
> >> we just
> >> check SINK_COUNT and do full detect ?
> > ->detect() will be called from the hotplug work and that will
> > check SINK_COUNT.
> >
> No, the Compliance Sink tool, will not set the DP_DS_PORT_HPD
> resulting
> in detect not getting executed for
> the short pulse generated. The spec requires the sink to set only the
> sink count so it is not a must for
> the sink to update the DP_DOWNSTREAM_PORT_0. so only a check for
> SINK_COUNT will pass the
> compliance test.
> >>> That seems stupid. If the downstream port isn't HPD capable then we
> >>> have
> >>> no reason to check SINK_COUNT after a short HPD as the short HPD
> >>> coudln't have been caused by a downstram HPD. Obviuously we still
> >>> check SINK_COUNT after a long HPD to figure out if anything is
> >>> connected
> >>> when the branch device itself gets connected to the source.
> >> Actually that's not correct. We don't check SINK_COUNT unless the
> >> downstream
> >> port is HPD capable.
> >>
> >> The spec says:
> >> "If the DFP does not provide for means for plug/unplug detection, the
> >> adaptor must set th
Re: [Intel-gfx] [PATCH v2 07/20] drm/i915: Rework primary plane stuff slightly.
Op 08-07-15 om 11:27 schreef Daniel Vetter:
> On Tue, Jul 07, 2015 at 04:02:32PM +0200, Maarten Lankhorst wrote:
>> Op 07-07-15 om 13:16 schreef Daniel Vetter:
>>> On Tue, Jul 07, 2015 at 09:08:18AM +0200, Maarten Lankhorst wrote:
Make sure the primary plane is set up correctly. This is done by
setting plane_state->src and plane_state->crtc.
All non-primary planes get disabled.
>>> Too terse commit message, fails to mention that this is about hw
>>> readout completely. Also should mention that this removes the
>>> initial_planes hack.
>>>
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_atomic.c | 7 --
drivers/gpu/drm/i915/intel_display.c | 167
+--
drivers/gpu/drm/i915/intel_drv.h | 2 -
3 files changed, 60 insertions(+), 116 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_atomic.c
b/drivers/gpu/drm/i915/intel_atomic.c
index 429677a111d5..b593612a917d 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -98,13 +98,6 @@ int intel_atomic_check(struct drm_device *dev,
return -EINVAL;
}
- if (crtc_state &&
- crtc_state->quirks & PIPE_CONFIG_QUIRK_INITIAL_PLANES) {
- ret = drm_atomic_add_affected_planes(state,
&nuclear_crtc->base);
- if (ret)
- return ret;
- }
-
ret = drm_atomic_helper_check_planes(dev, state);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index eb7c2e2819b7..fa1102392eca 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -109,6 +109,7 @@ static void skl_init_scalers(struct drm_device *dev,
struct intel_crtc *intel_cr
struct intel_crtc_state *crtc_state);
static int i9xx_get_refclk(const struct intel_crtc_state *crtc_state,
int num_connectors);
+static void intel_pre_disable_primary(struct drm_crtc *crtc);
static struct intel_encoder *intel_find_encoder(struct intel_connector
*connector, int pipe)
{
@@ -2582,11 +2583,12 @@ intel_find_initial_plane_obj(struct intel_crtc
*intel_crtc,
{
struct drm_device *dev = intel_crtc->base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
- struct drm_crtc *c;
- struct intel_crtc *i;
struct drm_i915_gem_object *obj;
- struct drm_plane *primary = intel_crtc->base.primary;
struct drm_framebuffer *fb;
+ struct drm_plane *primary = intel_crtc->base.primary;
+ struct intel_plane *p;
+ struct intel_plane_state *plane_state =
+ to_intel_plane_state(primary->state);
if (!plane_config->fb)
return;
@@ -2602,16 +2604,11 @@ intel_find_initial_plane_obj(struct intel_crtc
*intel_crtc,
* Failed to alloc the obj, check to see if we should share
* an fb with another CRTC instead
*/
- for_each_crtc(dev, c) {
- i = to_intel_crtc(c);
-
- if (c == &intel_crtc->base)
- continue;
-
- if (!i->active)
+ for_each_intel_plane(dev, p) {
+ if (p->base.type != DRM_PLANE_TYPE_PRIMARY)
continue;
- fb = c->primary->fb;
+ fb = p->base.state->fb;
>>> This seems to break the sharing logic completely: We want to check primary
>>> planes of all other crtcs to see whether we could merged the fb together.
>>> We don't even read out plane state for non-primary planes, so the below fb
>>> check will never be non-NULL.
>> I thought this was about multiple planes sharing the same fb with same
>> offset.
>> And as such checking for the crtc is unnecessary, for the current crtc it
>> will be be NULL here.
>>
>> This only reads out the current fb, not different ones.
>>
>> And sharing the same fb with other crtc's is done in intel_fbdev_init_bios.
> This is about sharing the same fb but across different crtcs - bios never
> enables more than the primary plane anyway. And you can't rely upon
> fbdev_init_bios since that's not run at all when I915_FBDEV=n.
>
> So yes with current code this loop here reconstruct the shared between
> primary planes on different crtcs (if the stolen allocator tells us that
> our range is occupied already). fbdev_init_bios just tries to create a
> config matching the one the bios has set up (and then pick a suitable fb
> for fbcon from the ones already allocated).
>
> Maybe we should extract this as try_to_find_shared_fb or similar to make
> the code self-explanatory?
>
if (!fb)
continue;
@@ -2622,18 +2619,28 @@ intel_find_initial_plane_obj(stru
Re: [Intel-gfx] [PATCH] drm/i915: Don't forget to mark crtc as inactive after disable
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) Task id: 6745 -Summary- Platform Delta drm-intel-nightly Series Applied ILK -9 302/302 293/302 SNB -32 312/316 280/316 IVB -14 343/343 329/343 BYT 287/287 287/287 HSW 380/380 380/380 -Detailed- Platform Testdrm-intel-nightly Series Applied *ILK igt@kms_flip@blocking-absolute-wf_vblank-interruptible PASS(1) DMESG_WARN(1) (dmesg patch applied)WARNING:at_drivers/gpu/drm/i915/intel_display.c:#intel_disable_shared_dpll[i915]()@WARNING:.* at .* intel_disable_shared_dpll+0x *ILK igt@kms_flip@flip-vs-dpms-interruptible PASS(1) DMESG_WARN(1) (dmesg patch applied)WARNING:at_drivers/gpu/drm/i915/intel_display.c:#intel_disable_shared_dpll[i915]()@WARNING:.* at .* intel_disable_shared_dpll+0x *ILK igt@kms_flip@flip-vs-rmfb-interruptible PASS(1) DMESG_WARN(1) (dmesg patch applied)WARNING:at_drivers/gpu/drm/i915/intel_display.c:#intel_disable_shared_dpll[i915]()@WARNING:.* at .* intel_disable_shared_dpll+0x *ILK igt@kms_flip@nonexisting-fb PASS(1) DMESG_WARN(1) (dmesg patch applied)WARNING:at_drivers/gpu/drm/i915/intel_display.c:#intel_disable_shared_dpll[i915]()@WARNING:.* at .* intel_disable_shared_dpll+0x *ILK igt@kms_flip@rcs-wf_vblank-vs-dpms-interruptible PASS(1) DMESG_WARN(1) (dmesg patch applied)WARNING:at_drivers/gpu/drm/i915/intel_display.c:#intel_disable_shared_dpll[i915]()@WARNING:.* at .* intel_disable_shared_dpll+0x *ILK igt@kms_flip@vblank-vs-hang PASS(1) DMESG_WARN(1) (dmesg patch applied)WARNING:at_drivers/gpu/drm/i915/intel_display.c:#intel_disable_shared_dpll[i915]()@WARNING:.* at .* intel_disable_shared_dpll+0x *ILK igt@kms_flip@wf_vblank-ts-check PASS(1) DMESG_WARN(1) (dmesg patch applied)WARNING:at_drivers/gpu/drm/i915/intel_display.c:#intel_disable_shared_dpll[i915]()@WARNING:.* at .* intel_disable_shared_dpll+0x *ILK igt@kms_flip@wf_vblank-vs-modeset-interruptible PASS(1) DMESG_WARN(1) (dmesg patch applied)WARNING:at_drivers/gpu/drm/i915/intel_display.c:#intel_disable_shared_dpll[i915]()@WARNING:.* at .* intel_disable_shared_dpll+0x *ILK igt@kms_render@direct-render PASS(1) DMESG_WARN(1) (dmesg patch applied)WARNING:at_drivers/gpu/drm/i915/intel_display.c:#intel_disable_shared_dpll[i915]()@WARNING:.* at .* intel_disable_shared_dpll+0x *SNB igt@kms_cursor_crc@cursor-size-change PASS(1) DMESG_WARN(1) (dmesg patch applied)WARNING:at_drivers/gpu/drm/i915/intel_display.c:#intel_disable_shared_dpll[i915]()@WARNING:.* at .* intel_disable_shared_dpll+0x *SNB igt@kms_flip@bo-too-big PASS(1) DMESG_WARN(1) (dmesg patch applied)WARNING:at_drivers/gpu/drm/i915/intel_display.c:#intel_disable_shared_dpll[i915]()@WARNING:.* at .* intel_disable_shared_dpll+0x *SNB igt@kms_flip@bo-too-big-interruptible PASS(1) DMESG_WARN(1) (dmesg patch applied)WARNING:at_drivers/gpu/drm/i915/intel_display.c:#intel_disable_shared_dpll[i915]()@WARNING:.* at .* intel_disable_shared_dpll+0x *SNB igt@kms_flip@dpms-vs-vblank-race PASS(1) DMESG_WARN(1) (dmesg patch applied)WARNING:at_drivers/gpu/drm/i915/intel_display.c:#intel_disable_shared_dpll[i915]()@WARNING:.* at .* intel_disable_shared_dpll+0x *SNB igt@kms_flip@dpms-vs-vblank-race-interruptible PASS(1) DMESG_WARN(1) (dmesg patch applied)WARNING:at_drivers/gpu/drm/i915/intel_display.c:#intel_disable_shared_dpll[i915]()@WARNING:.* at .* intel_disable_shared_dpll+0x *SNB igt@kms_flip_event_leak PASS(1) DMESG_WARN(1) (dmesg patch applied)WARNING:at_drivers/gpu/drm/i915/intel_display.c:#intel_disable_shared_dpll[i915]()@WARNING:.* at .* intel_disable_shared_dpll+0x *SNB igt@kms_flip@flip-vs-dpms-off-vs-modeset PASS(1) DMESG_WARN(1) (dmesg patch applied)WARNING:at_drivers/gpu/drm/i915/intel_display.c:#intel_disable_shared_dpll[i915]()@WARNING:.* at .* intel_disable_shared_dpll+0x *SNB igt@kms_flip@flip-vs-dpms-off-vs-modeset-interruptible PASS(1) DMESG_WARN(1) (dmesg patch applied)WARNING:at_drivers/gpu/drm/i915/intel_display.c:#intel_disable_shared_dpll[i915]()@WARNING:.* at .* intel_disable_shared_dpll+0x *SNB igt@kms_flip@modeset-vs-vblank-race PASS(1) DMESG_WARN(1) (dmesg patch applied)WARNING:at_drivers/gpu/drm/i915/intel_display.c:#intel_disable_shared_dpll[i915]()@WARNING:.* at .* intel_disable_shared_dpll+0x *SNB igt@kms_flip@modeset-vs-vblank-race-interruptible PASS(1) DMESG_WARN(1) (dmesg patch applied)WARNING:at_
Re: [Intel-gfx] [PATCHv7] drm/i915: Added Programming of the MOCS
Chris Wilson writes:
> On Tue, Jul 07, 2015 at 10:13:01PM +0300, Francisco Jerez wrote:
>> From: Peter Antoine
>>
>> This change adds the programming of the MOCS registers to the gen 9+
>> platforms. This change set programs the MOCS register values to a set
>> of values that are defined to be optimal.
>
> If they were optimal why weren't they defaults? I'm not feeling very
> satisfied by this explanation.
>
Hah, yeah, they are definitely not optimal, it's just that I didn't feel
fully confident modifying the original message above Peter's Signed-off
line. How about we replace that sentence with: "The set of MOCS
configuration entries introduced by this patch is intended to be minimal
but sufficient to cover the needs of current userspace, it's expected to
be extended in the future based on the userspace demand for additional
caching configurations."
>> +/**
>> + * get_mocs_settings
>> + *
>> + * This function will return the values of the MOCS table that needs to
>> + * be programmed for the platform. It will return the values that need
>> + * to be programmed and if they need to be programmed.
>> + *
>> + * If the return values is false then the registers do not need programming.
>> + */
>> +static bool get_mocs_settings(struct drm_device *dev,
>> + struct drm_i915_mocs_table *table)
>> +{
>> +bool result = false;
>
> This looks easy enough to extend to get_mocs_settings(ctx, &table) and
> use CONTEXT_SET_PARAM to load a user defined mocs table. These defaults
> have the smell of policy in the era where even CPU PAT are becoming user
> defined (with per-process definitions). Is it worth shifting these to
> userspace? Having sane/safe defaults is good definitely.
>
Yeah, I also have the feeling that we may want to switch to some dynamic
set-up scheme in the future. With only three of the available 62
entries in use right now it's likely to take a *long* time until we run
out of entries from the global tables though, when (if) that happens we
can always switch to dynamic set-up via some new IOCTL without
disrupting older userspace relying on the fixed MOCS defaults.
Implementing dynamic set-up is less straightforward than it may seem
though, because only the MOCS tables for some of the engines are context
saved and restored automatically by the hardware, so the settings
specified by one context would partially leak into other applications,
unless we context-switch the remaining engines manually from the kernel.
> The changelog should be more explicit on what you mean by optimal and
> why other avenues are not pursued.
>
>> +/**
>> + * emit_mocs_control_table() - emit the mocs control table
>> + * @req:Request to set up the MOCS table for.
>> + * @table: The values to program into the control regs.
>> + * @reg_base: The base for the engine that needs to be programmed.
>> + *
>> + * This function simply emits a MI_LOAD_REGISTER_IMM command for the
>> + * given table starting at the given address.
>> + *
>> + * @return 0 on success, otherwise the error status.
>> + */
>> +static int emit_mocs_control_table(struct drm_i915_gem_request *req,
>> + const struct drm_i915_mocs_table *table,
>> + u32 reg_base)
>> +{
>> +struct intel_ringbuffer *ringbuf = req->ringbuf;
>> +unsigned int index;
>> +int ret;
>> +
>> +ret = intel_logical_ring_begin(req, 2 + 2 * GEN9_NUM_MOCS_ENTRIES);
>> +if (ret) {
>> +DRM_DEBUG("intel_logical_ring_begin failed %d\n", ret);
>> +return ret;
>> +}
>
> Much happier now. I don't have to jump back and forth to check you have
> reserved the correct amount of space.
>
> One last thing to do would be
>
> if (WARN_ON(table->size > GEN9_NUM_MOCS_ENTRIES))
> return -ENODEV;
>
> It's nice here as we have the two loops and this sanity check helps
> explain the relationship between those loops and the ring emission. But
> equally you may feel that doing that check in get_mocs_table() (or just
> after) is sufficient. It needs to be done somewhere though.
>
> (If you go with adding the sanity check here, it should also be done in
> emit_mocs_l3cc_table.)
OK, I'll fix that and resend.
Thanks!
>
> Considering that's my only real critique, pretty good!
> -Chris
>
> --
> Chris Wilson, Intel Open Source Technology Centre
signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Use crtc_state->active in primary check_plane func
On Wed, Jul 08, 2015 at 12:24:07PM +0200, Maarten Lankhorst wrote:
> Op 07-07-15 om 11:15 schreef Daniel Vetter:
> > Since
> >
> > commit 8c7b5ccb729870e606321b3703e2c2e698c49a95
> > Author: Ander Conselvan de Oliveira
> > Date: Tue Apr 21 17:13:19 2015 +0300
> >
> > drm/i915: Use atomic helpers for computing changed flags
> >
> > we compute the plane state for a modeset before actually committing
> > any changes, which means crtc->active won't be correct yet. Looking at
> > future work in the modeset conversion targetting 4.3 the only places
> > where crtc_state->active isn't accurate is when disabling other CRTCs
> > than the one the modeset is for (when stealing connectors). Which
> > isn't the case here. And that's also confirmed by an audit, we do
> > unconditionally update crtc_state->active for the current pipe.
> >
> > We also don't need to update any other plane check functions since we
> > only ever add the primary state to the modeset update right now.
> >
> > Cc: Ander Conselvan de Oliveira
> > Cc: Maarten Lankhorst
> > Cc: Jani Nikula
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/i915/intel_display.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 647b1404c441..ba9321998a41 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -13276,7 +13276,7 @@ intel_check_primary_plane(struct drm_plane *plane,
> > if (ret)
> > return ret;
> >
> > - if (intel_crtc->active) {
> > + if (crtc_state->base.active) {
> > struct intel_plane_state *old_state =
> > to_intel_plane_state(plane->state);
> >
> I think this was probably a feature, not a bug. Since full atomic planes
> won't be part of v4.2
> both patches look ok to me.
I wasn't sure - in dinq we didn't convert his as part of the patches which
switched to check state->active in check functions, but only later on was
removed in some seemingly unrelated refactor. Not sure why this didn't
blow up more ...
> Reviewed-by: Maarten Lankhorst
Both applied, thanks for review.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
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 1/2] drm/i915: Extend GET_APERTURE ioctl to report available map space
Hi,
On 07/08/2015 07:51 AM, ankitprasad.r.sha...@intel.com wrote:
From: Rodrigo Vivi
When constructing a batchbuffer, it is sometimes crucial to know the
largest hole into which we can fit a fenceable buffer (for example when
handling very large objects on gen2 and gen3). This depends on the
fragmentation of pinned buffers inside the aperture, a question only the
kernel can easily answer.
This patch extends the current DRM_I915_GEM_GET_APERTURE ioctl to
include a couple of new fields in its reply to userspace - the total
amount of space available in the mappable region of the aperture and
also the single largest block available.
Since whatever this returns is a transient number is this really that
useful? There are no guarantees that by the time caller tries to act on
it it will still be valid.
This is not quite what userspace wants to answer the question of whether
this batch will fit as fences are also required to meet severe alignment
constraints within the batch. For this purpose, a third conservative
estimate of largest fence available is also provided. For when userspace
needs more than one batch, we also provide the culmulative space
available for fences such that it has some additional guidance to how
much space it could allocate to fences. Conservatism still wins.
The patch also adds a debugfs file for convenient testing and reporting.
v2: The first object cannot end at offset 0, so we can use last==0 to
detect the empty list.
v3: Expand all values to 64bit, just in case.
Report total mappable aperture size for userspace that cannot easily
determine it by inspecting the PCI device.
v4: (Rodrigo) Fixed rebase conflicts.
Signed-off-by: Chris Wilson
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_debugfs.c | 27 +
drivers/gpu/drm/i915/i915_gem.c | 116 ++--
include/uapi/drm/i915_drm.h | 25
3 files changed, 164 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 31d8768..49ec438 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -512,6 +512,32 @@ static int i915_gem_object_info(struct seq_file *m, void*
data)
return 0;
}
+static int i915_gem_aperture_info(struct seq_file *m, void *data)
+{
+ struct drm_info_node *node = m->private;
+ struct drm_i915_gem_get_aperture arg;
+ int ret;
+
+ ret = i915_gem_get_aperture_ioctl(node->minor->dev, &arg, NULL);
+ if (ret)
+ return ret;
+
+ seq_printf(m, "Total size of the GTT: %llu bytes\n",
+ arg.aper_size);
+ seq_printf(m, "Available space in the GTT: %llu bytes\n",
+ arg.aper_available_size);
+ seq_printf(m, "Available space in the mappable aperture: %llu bytes\n",
+ arg.map_available_size);
+ seq_printf(m, "Single largest space in the mappable aperture: %llu
bytes\n",
+ arg.map_largest_size);
+ seq_printf(m, "Available space for fences: %llu bytes\n",
+ arg.fence_available_size);
+ seq_printf(m, "Single largest fence available: %llu bytes\n",
+ arg.fence_largest_size);
+
+ return 0;
+}
+
static int i915_gem_gtt_info(struct seq_file *m, void *data)
{
struct drm_info_node *node = m->private;
@@ -5030,6 +5056,7 @@ static int i915_debugfs_create(struct dentry *root,
static const struct drm_info_list i915_debugfs_list[] = {
{"i915_capabilities", i915_capabilities, 0},
{"i915_gem_objects", i915_gem_object_info, 0},
+ {"i915_gem_aperture", i915_gem_aperture_info, 0},
{"i915_gem_gtt", i915_gem_gtt_info, 0},
{"i915_gem_pinned", i915_gem_gtt_info, 0, (void *) PINNED_LIST},
{"i915_gem_active", i915_gem_object_list_info, 0, (void *) ACTIVE_LIST},
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index a2a4a27..ccfc8d3 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -32,6 +32,7 @@
#include "i915_vgpu.h"
#include "i915_trace.h"
#include "intel_drv.h"
+#include
#include
#include
#include
@@ -143,6 +144,55 @@ int i915_mutex_lock_interruptible(struct drm_device *dev)
return 0;
}
+static inline bool
+i915_gem_object_is_inactive(struct drm_i915_gem_object *obj)
+{
+ return i915_gem_obj_bound_any(obj) && !obj->active;
+}
+
+static int obj_rank_by_ggtt(void *priv,
+ struct list_head *A,
+ struct list_head *B)
+{
+ struct drm_i915_gem_object *a = list_entry(A,typeof(*a), obj_exec_link);
+ struct drm_i915_gem_object *b = list_entry(B,typeof(*b), obj_exec_link);
Nitpick - space after comma.
+
+ return i915_gem_obj_ggtt_offset(a) - i915_gem_obj_ggtt_offset(b);
+}
+
+static u32 __fence_size(struct drm_i915_private *dev_priv, u32 start,
Re: [Intel-gfx] [PATCHv7] drm/i915: Added Programming of the MOCS
On Wed, Jul 08, 2015 at 03:50:06PM +0300, Francisco Jerez wrote:
> Chris Wilson writes:
>
> > On Tue, Jul 07, 2015 at 10:13:01PM +0300, Francisco Jerez wrote:
> >> From: Peter Antoine
> >>
> >> This change adds the programming of the MOCS registers to the gen 9+
> >> platforms. This change set programs the MOCS register values to a set
> >> of values that are defined to be optimal.
> >
> > If they were optimal why weren't they defaults? I'm not feeling very
> > satisfied by this explanation.
> >
> Hah, yeah, they are definitely not optimal, it's just that I didn't feel
> fully confident modifying the original message above Peter's Signed-off
> line. How about we replace that sentence with: "The set of MOCS
> configuration entries introduced by this patch is intended to be minimal
> but sufficient to cover the needs of current userspace, it's expected to
> be extended in the future based on the userspace demand for additional
> caching configurations."
That's much clearer. However, one now wonders how it will change in the
future and whether we have sufficient future proofing. Do you mean that
there is a safe subset of the current tables with higher entries
reserved for future use (and perhaps a future param to tell userspace
when they can use them), or perhaps in the future we will allow
userspace to replace select MOCS tables.
Bikeshedding:
The set of MOCS configuration entries introduced by this patch is intended
to be minimal but sufficient to cover the needs of current userspace - i.e.
a good set of defaults. It is expected to be extended in the future to
provide further default values or to allow userspace to redefine its private
MOCS tables based on its demand for additional caching configurations.
In this setup, userspace should only utilize the first N entries, higher
entries are reserved for future use.
> >> +/**
> >> + * get_mocs_settings
> >> + *
> >> + * This function will return the values of the MOCS table that needs to
> >> + * be programmed for the platform. It will return the values that need
> >> + * to be programmed and if they need to be programmed.
> >> + *
> >> + * If the return values is false then the registers do not need
> >> programming.
> >> + */
> >> +static bool get_mocs_settings(struct drm_device *dev,
> >> +struct drm_i915_mocs_table *table)
> >> +{
> >> + bool result = false;
> >
> > This looks easy enough to extend to get_mocs_settings(ctx, &table) and
> > use CONTEXT_SET_PARAM to load a user defined mocs table. These defaults
> > have the smell of policy in the era where even CPU PAT are becoming user
> > defined (with per-process definitions). Is it worth shifting these to
> > userspace? Having sane/safe defaults is good definitely.
> >
>
> Yeah, I also have the feeling that we may want to switch to some dynamic
> set-up scheme in the future. With only three of the available 62
> entries in use right now it's likely to take a *long* time until we run
> out of entries from the global tables though, when (if) that happens we
> can always switch to dynamic set-up via some new IOCTL without
> disrupting older userspace relying on the fixed MOCS defaults.
>
> Implementing dynamic set-up is less straightforward than it may seem
> though, because only the MOCS tables for some of the engines are context
> saved and restored automatically by the hardware, so the settings
> specified by one context would partially leak into other applications,
> unless we context-switch the remaining engines manually from the kernel.
Sounds like we need a set of common unalterable mocs tables for the
shared configs, and limit userspace to doing interesting things on
select engines. :(
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: storm detection documentation update
On 7/7/2015 5:01 PM, Daniel Vetter wrote: On Tue, Jul 07, 2015 at 04:10:49PM +0530, Sivakumar Thulasimani wrote: From: "Thulasimani,Sivakumar" Update the hotplug documentation to explain that hotplug storm is not expected for Display port panels and hence is not handled in current code. Signed-off-by: Sivakumar Thulasimani --- drivers/gpu/drm/i915/intel_hotplug.c |4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_hotplug.c b/drivers/gpu/drm/i915/intel_hotplug.c index bac91a1..7dc5e6a 100644 --- a/drivers/gpu/drm/i915/intel_hotplug.c +++ b/drivers/gpu/drm/i915/intel_hotplug.c @@ -66,6 +66,10 @@ * while before being re-enabled. The intention is to mitigate issues raising * from broken hardware triggering massive amounts of interrupts and grinding * the system to a halt. + * + * Hotplug interrupt storm is not expected on Display port panel, hence the + * current code only handles disabling and later enabling of HPD interrupts + * for HDMI panels through the storm handling set of functions. This isn't accurate, we handle storms on everything _but_ DP (tv, vga, sdvo, ...). I'd go with * Hotplug interrupt storm is not expected on Display port panel, hence the * current code doesn't handle irq reenabling when a DP sink is connected * and the hpd is handled by the DP callbacks. But on DP+ ports * storms are still handled correctly in all other cases (e.g. due to HDMI * sinks). Could still be improved I think. -Daniel Sorry i don't get the "DP+" reference here. By DP+, do you mean dongles ? passive dongles will report them selves as HDMI to respective detect routines active dongles will be still treated as DP hence not handling HPD will apply to any display connected through active dongle as well. -- regards, Sivakumar ___ 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: Extend GET_APERTURE ioctl to report available map space
On Wed, Jul 08, 2015 at 02:13:43PM +0100, Tvrtko Ursulin wrote: > > Hi, > > On 07/08/2015 07:51 AM, ankitprasad.r.sha...@intel.com wrote: > >From: Rodrigo Vivi > > > >When constructing a batchbuffer, it is sometimes crucial to know the > >largest hole into which we can fit a fenceable buffer (for example when > >handling very large objects on gen2 and gen3). This depends on the > >fragmentation of pinned buffers inside the aperture, a question only the > >kernel can easily answer. > > > >This patch extends the current DRM_I915_GEM_GET_APERTURE ioctl to > >include a couple of new fields in its reply to userspace - the total > >amount of space available in the mappable region of the aperture and > >also the single largest block available. > > Since whatever this returns is a transient number is this really > that useful? There are no guarantees that by the time caller tries > to act on it it will still be valid. Yes. My use case is actually after a failure to capture debug information. I don't anticipate frequent calls to get_aperture (usually just a single call during early init). -Chrs -- 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: Extend GET_APERTURE ioctl to report available map space
On 07/08/2015 07:51 AM, ankitprasad.r.sha...@intel.com wrote:
From: Rodrigo Vivi
When constructing a batchbuffer, it is sometimes crucial to know the
largest hole into which we can fit a fenceable buffer (for example when
handling very large objects on gen2 and gen3). This depends on the
fragmentation of pinned buffers inside the aperture, a question only the
kernel can easily answer.
This patch extends the current DRM_I915_GEM_GET_APERTURE ioctl to
include a couple of new fields in its reply to userspace - the total
amount of space available in the mappable region of the aperture and
also the single largest block available.
This is not quite what userspace wants to answer the question of whether
this batch will fit as fences are also required to meet severe alignment
constraints within the batch. For this purpose, a third conservative
estimate of largest fence available is also provided. For when userspace
needs more than one batch, we also provide the culmulative space
available for fences such that it has some additional guidance to how
much space it could allocate to fences. Conservatism still wins.
The patch also adds a debugfs file for convenient testing and reporting.
v2: The first object cannot end at offset 0, so we can use last==0 to
detect the empty list.
v3: Expand all values to 64bit, just in case.
Report total mappable aperture size for userspace that cannot easily
determine it by inspecting the PCI device.
v4: (Rodrigo) Fixed rebase conflicts.
Signed-off-by: Chris Wilson
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_debugfs.c | 27 +
drivers/gpu/drm/i915/i915_gem.c | 116 ++--
include/uapi/drm/i915_drm.h | 25
3 files changed, 164 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 31d8768..49ec438 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -512,6 +512,32 @@ static int i915_gem_object_info(struct seq_file *m, void*
data)
return 0;
}
+static int i915_gem_aperture_info(struct seq_file *m, void *data)
+{
+ struct drm_info_node *node = m->private;
+ struct drm_i915_gem_get_aperture arg;
+ int ret;
+
+ ret = i915_gem_get_aperture_ioctl(node->minor->dev, &arg, NULL);
+ if (ret)
+ return ret;
+
+ seq_printf(m, "Total size of the GTT: %llu bytes\n",
+ arg.aper_size);
+ seq_printf(m, "Available space in the GTT: %llu bytes\n",
+ arg.aper_available_size);
+ seq_printf(m, "Available space in the mappable aperture: %llu bytes\n",
+ arg.map_available_size);
+ seq_printf(m, "Single largest space in the mappable aperture: %llu
bytes\n",
+ arg.map_largest_size);
+ seq_printf(m, "Available space for fences: %llu bytes\n",
+ arg.fence_available_size);
+ seq_printf(m, "Single largest fence available: %llu bytes\n",
+ arg.fence_largest_size);
+
+ return 0;
+}
+
static int i915_gem_gtt_info(struct seq_file *m, void *data)
{
struct drm_info_node *node = m->private;
@@ -5030,6 +5056,7 @@ static int i915_debugfs_create(struct dentry *root,
static const struct drm_info_list i915_debugfs_list[] = {
{"i915_capabilities", i915_capabilities, 0},
{"i915_gem_objects", i915_gem_object_info, 0},
+ {"i915_gem_aperture", i915_gem_aperture_info, 0},
{"i915_gem_gtt", i915_gem_gtt_info, 0},
{"i915_gem_pinned", i915_gem_gtt_info, 0, (void *) PINNED_LIST},
{"i915_gem_active", i915_gem_object_list_info, 0, (void *) ACTIVE_LIST},
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index a2a4a27..ccfc8d3 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -32,6 +32,7 @@
#include "i915_vgpu.h"
#include "i915_trace.h"
#include "intel_drv.h"
+#include
#include
#include
#include
@@ -143,6 +144,55 @@ int i915_mutex_lock_interruptible(struct drm_device *dev)
return 0;
}
+static inline bool
+i915_gem_object_is_inactive(struct drm_i915_gem_object *obj)
+{
+ return i915_gem_obj_bound_any(obj) && !obj->active;
+}
Oh and this function is not used.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915: Don't forget to mark crtc as inactive after disable
Watermark calculations depend on the intel_crtc->active flag to be set properly. Suspend/resume is broken on SKL and we also get DDB mismatches without this patch. The regression was introduced in: commit eddfcbcdc27fbecb33bff098967bbdd7ca75bfa6 Author: Maarten Lankhorst Date: Mon Jun 15 12:33:53 2015 +0200 drm/i915: Update less state during modeset. No need to repeatedly call update_watermarks, or update_fbc. Down to a single call to update_watermarks in .crtc_enable Signed-off-by: Maarten Lankhorst Reviewed-by: Matt Roper Tested-by(IVB): Matt Roper Signed-off-by: Daniel Vetter v2: Don't touch disable_shared_dpll() Signed-off-by: Patrik Jakobsson --- drivers/gpu/drm/i915/intel_display.c | 9 + 1 file changed, 9 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 3c2425f..b4f7a4f 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -5046,6 +5046,9 @@ static void ironlake_crtc_disable(struct drm_crtc *crtc) ironlake_fdi_pll_disable(intel_crtc); } + + intel_crtc->active = false; + intel_update_watermarks(crtc); } static void haswell_crtc_disable(struct drm_crtc *crtc) @@ -5091,6 +5094,9 @@ static void haswell_crtc_disable(struct drm_crtc *crtc) for_each_encoder_on_crtc(dev, crtc, encoder) if (encoder->post_disable) encoder->post_disable(encoder); + + intel_crtc->active = false; + intel_update_watermarks(crtc); } static void i9xx_pfit_enable(struct intel_crtc *crtc) @@ -6155,6 +6161,9 @@ static void i9xx_crtc_disable(struct drm_crtc *crtc) if (!IS_GEN2(dev)) intel_set_cpu_fifo_underrun_reporting(dev_priv, pipe, false); + + intel_crtc->active = false; + intel_update_watermarks(crtc); } static void intel_crtc_disable_noatomic(struct drm_crtc *crtc) -- 2.1.4 ___ 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: Extend GET_APERTURE ioctl to report size of the stolen region
Hi,
On 07/08/2015 07:51 AM, ankitprasad.r.sha...@intel.com wrote:
From: Ankitprasad Sharma
This patch extends the GET_APERTURE ioctl to add support
for getting total size and available size of the stolen region
as well as single largest block available in the stolen region.
Also adds debugfs support to retieve the size information of the
stolen area.
v2: respinned over Rodrigo's patch which extends the GET_APERTURE
too. Used drm_mm to get the size information of the stolen region
(Chris)
Added debugfs support for testing (Ankit)
v3: Rebased to the latest drm-intel-nightly (Ankit)
Signed-off-by: Ankitprasad Sharma
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c| 6 ++
drivers/gpu/drm/i915/i915_drv.h| 3 +++
drivers/gpu/drm/i915/i915_gem.c| 7 +++
drivers/gpu/drm/i915/i915_gem_stolen.c | 35 ++
include/uapi/drm/i915_drm.h| 15 +++
5 files changed, 66 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 49ec438..d12ef0a 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -534,6 +534,12 @@ static int i915_gem_aperture_info(struct seq_file *m, void
*data)
arg.fence_available_size);
seq_printf(m, "Single largest fence available: %llu bytes\n",
arg.fence_largest_size);
+ seq_printf(m, "Total size of the stolen region: %llu bytes\n",
+ arg.stolen_total_size);
+ seq_printf(m, "Available size of the stolen region: %llu bytes\n",
+ arg.stolen_available_size);
+ seq_printf(m, "Single largest area in the stolen region: %llu bytes\n",
+ arg.stolen_largest_size);
return 0;
}
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index ea9caf2..7cd1b2e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3101,6 +3101,9 @@ i915_gem_object_create_stolen_for_preallocated(struct
drm_device *dev,
u32 stolen_offset,
u32 gtt_offset,
u32 size);
+void i915_gem_stolen_size_info(struct drm_mm *mm, uint64_t *stolen_total,
+ uint64_t *stolen_free,
+ uint64_t *stolen_largest);
/* i915_gem_shrinker.c */
unsigned long i915_gem_shrink(struct drm_i915_private *dev_priv,
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index ccfc8d3..ec20c67 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -203,6 +203,7 @@ i915_gem_get_aperture_ioctl(struct drm_device *dev, void
*data,
struct list_head map_list;
const u32 map_limit = dev_priv->gtt.mappable_end;
size_t pinned, map_space, map_largest, fence_space, fence_largest;
+ uint64_t stolen_total, stolen_available, stolen_largest;
u32 last, size;
INIT_LIST_HEAD(&map_list);
@@ -260,6 +261,9 @@ skip_first:
fence_largest = size;
fence_space += size;
}
+
+ i915_gem_stolen_size_info(&dev_priv->mm.stolen, &stolen_total,
+ &stolen_available, &stolen_largest);
mutex_unlock(&dev->struct_mutex);
args->aper_size = dev_priv->gtt.base.total;
@@ -269,6 +273,9 @@ skip_first:
args->map_total_size = dev_priv->gtt.mappable_end;
args->fence_available_size = fence_space;
args->fence_largest_size = fence_largest;
+ args->stolen_total_size = stolen_total;
+ args->stolen_available_size = stolen_available;
+ args->stolen_largest_size = stolen_largest;
return 0;
}
diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c
b/drivers/gpu/drm/i915/i915_gem_stolen.c
index 348ed5a..08d983f 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -551,3 +551,38 @@ err_out:
drm_gem_object_unreference(&obj->base);
return NULL;
}
+
+void i915_gem_stolen_size_info(struct drm_mm *mm, uint64_t *stolen_total,
+ uint64_t *stolen_free,
+ uint64_t *stolen_largest)
+{
+ struct drm_mm_node *entry;
+ struct drm_mm_node *head_node = &mm->head_node;
+ uint64_t hole_size, hole_start, hole_end, largest_hole = 0;
+ uint64_t total_used = 0, total_free = 0;
+
+ if (head_node->hole_follows) {
+ hole_start = drm_mm_hole_node_start(head_node);
+ hole_end = drm_mm_hole_node_end(head_node);
+ hole_size = hole_end - hole_start;
+ total_free += hole_size;
+ if (largest_hole < hole_size)
+ largest_hole = hole_size;
Guaranteed it is the largest hole by this point,
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Extend GET_APERTURE ioctl to report available map space
On 07/08/2015 02:28 PM, Chris Wilson wrote: On Wed, Jul 08, 2015 at 02:13:43PM +0100, Tvrtko Ursulin wrote: Hi, On 07/08/2015 07:51 AM, ankitprasad.r.sha...@intel.com wrote: From: Rodrigo Vivi When constructing a batchbuffer, it is sometimes crucial to know the largest hole into which we can fit a fenceable buffer (for example when handling very large objects on gen2 and gen3). This depends on the fragmentation of pinned buffers inside the aperture, a question only the kernel can easily answer. This patch extends the current DRM_I915_GEM_GET_APERTURE ioctl to include a couple of new fields in its reply to userspace - the total amount of space available in the mappable region of the aperture and also the single largest block available. Since whatever this returns is a transient number is this really that useful? There are no guarantees that by the time caller tries to act on it it will still be valid. Yes. My use case is actually after a failure to capture debug information. I don't anticipate frequent calls to get_aperture (usually just a single call during early init). Should it better go to debugfs then? Regards, Tvrtko ___ 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: Extend GET_APERTURE ioctl to report available map space
On Wed, Jul 08, 2015 at 02:28:33PM +0100, Chris Wilson wrote: > On Wed, Jul 08, 2015 at 02:13:43PM +0100, Tvrtko Ursulin wrote: > > > > Hi, > > > > On 07/08/2015 07:51 AM, ankitprasad.r.sha...@intel.com wrote: > > >From: Rodrigo Vivi > > > > > >When constructing a batchbuffer, it is sometimes crucial to know the > > >largest hole into which we can fit a fenceable buffer (for example when > > >handling very large objects on gen2 and gen3). This depends on the > > >fragmentation of pinned buffers inside the aperture, a question only the > > >kernel can easily answer. > > > > > >This patch extends the current DRM_I915_GEM_GET_APERTURE ioctl to > > >include a couple of new fields in its reply to userspace - the total > > >amount of space available in the mappable region of the aperture and > > >also the single largest block available. > > > > Since whatever this returns is a transient number is this really > > that useful? There are no guarantees that by the time caller tries > > to act on it it will still be valid. > > Yes. My use case is actually after a failure to capture debug > information. I don't anticipate frequent calls to get_aperture (usually > just a single call during early init). Though that predates full-ppgtt (and even the recent aliasing-ppgtt split). Time to start thinking about doing something similar for contexts. -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/7] drm/i915: Add origin to frontbuffer tracking flush
2015-07-07 20:28 GMT-03:00 Rodrigo Vivi :
> This will be useful to PSR and FBC once we start making
> dirty fb calls to also flush frontbuffer.
>
> Cc: Daniel Vetter
> Cc: Paulo Zanoni
Reviewed-by: Paulo Zanoni
> Signed-off-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/i915_gem.c | 12 ++--
> drivers/gpu/drm/i915/intel_drv.h | 8
> drivers/gpu/drm/i915/intel_frontbuffer.c | 12 +++-
> 3 files changed, 17 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index a0bff41..2057e19 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -375,7 +375,7 @@ i915_gem_phys_pwrite(struct drm_i915_gem_object *obj,
> i915_gem_chipset_flush(dev);
>
> out:
> - intel_fb_obj_flush(obj, false);
> + intel_fb_obj_flush(obj, false, ORIGIN_CPU);
> return ret;
> }
>
> @@ -839,7 +839,7 @@ i915_gem_gtt_pwrite_fast(struct drm_device *dev,
> }
>
> out_flush:
> - intel_fb_obj_flush(obj, false);
> + intel_fb_obj_flush(obj, false, ORIGIN_GTT);
> out_unpin:
> i915_gem_object_ggtt_unpin(obj);
> out:
> @@ -1032,7 +1032,7 @@ out:
> if (needs_clflush_after)
> i915_gem_chipset_flush(dev);
>
> - intel_fb_obj_flush(obj, false);
> + intel_fb_obj_flush(obj, false, ORIGIN_CPU);
> return ret;
> }
>
> @@ -2375,7 +2375,7 @@ i915_gem_object_retire__write(struct
> drm_i915_gem_object *obj)
> RQ_BUG_ON(!(obj->active &
> intel_ring_flag(obj->last_write_req->ring)));
>
> i915_gem_request_assign(&obj->last_write_req, NULL);
> - intel_fb_obj_flush(obj, true);
> + intel_fb_obj_flush(obj, true, ORIGIN_CS);
> }
>
> static void
> @@ -3905,7 +3905,7 @@ i915_gem_object_flush_gtt_write_domain(struct
> drm_i915_gem_object *obj)
> old_write_domain = obj->base.write_domain;
> obj->base.write_domain = 0;
>
> - intel_fb_obj_flush(obj, false);
> + intel_fb_obj_flush(obj, false, ORIGIN_GTT);
>
> trace_i915_gem_object_change_domain(obj,
> obj->base.read_domains,
> @@ -3927,7 +3927,7 @@ i915_gem_object_flush_cpu_write_domain(struct
> drm_i915_gem_object *obj)
> old_write_domain = obj->base.write_domain;
> obj->base.write_domain = 0;
>
> - intel_fb_obj_flush(obj, false);
> + intel_fb_obj_flush(obj, false, ORIGIN_CPU);
>
> trace_i915_gem_object_change_domain(obj,
> obj->base.read_domains,
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 63d7d32..1f3f786 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -978,16 +978,16 @@ void intel_frontbuffer_flip_prepare(struct drm_device
> *dev,
> void intel_frontbuffer_flip_complete(struct drm_device *dev,
> unsigned frontbuffer_bits);
> void intel_frontbuffer_flush(struct drm_device *dev,
> -unsigned frontbuffer_bits);
> +unsigned frontbuffer_bits,
> +enum fb_op_origin origin);
> void intel_frontbuffer_flip(struct drm_device *dev,
> unsigned frontbuffer_bits);
> -
> unsigned int intel_fb_align_height(struct drm_device *dev,
>unsigned int height,
>uint32_t pixel_format,
>uint64_t fb_format_modifier);
> -void intel_fb_obj_flush(struct drm_i915_gem_object *obj, bool retire);
> -
> +void intel_fb_obj_flush(struct drm_i915_gem_object *obj, bool retire,
> + enum fb_op_origin origin);
> u32 intel_fb_stride_alignment(struct drm_device *dev, uint64_t fb_modifier,
> uint32_t pixel_format);
>
> diff --git a/drivers/gpu/drm/i915/intel_frontbuffer.c
> b/drivers/gpu/drm/i915/intel_frontbuffer.c
> index 6e90e2b..cb5a6f0 100644
> --- a/drivers/gpu/drm/i915/intel_frontbuffer.c
> +++ b/drivers/gpu/drm/i915/intel_frontbuffer.c
> @@ -105,6 +105,7 @@ void intel_fb_obj_invalidate(struct drm_i915_gem_object
> *obj,
> * intel_frontbuffer_flush - flush frontbuffer
> * @dev: DRM device
> * @frontbuffer_bits: frontbuffer plane tracking bits
> + * @origin: which operation caused the flush
> *
> * This function gets called every time rendering on the given planes has
> * completed and frontbuffer caching can be started again. Flushes will get
> @@ -113,7 +114,8 @@ void intel_fb_obj_invalidate(struct drm_i915_gem_object
> *obj,
> * Can be called without any locks held.
> */
> void intel_frontbuffer_flush(struct drm_device *dev,
> -unsigned frontbuffer_bits)
> +unsigned frontbuffer_bits,
> +enum fb_op_origin origin)
> {
>
Re: [Intel-gfx] [PATCHv7] drm/i915: Added Programming of the MOCS
Chris Wilson writes:
> On Wed, Jul 08, 2015 at 03:50:06PM +0300, Francisco Jerez wrote:
>> Chris Wilson writes:
>>
>> > On Tue, Jul 07, 2015 at 10:13:01PM +0300, Francisco Jerez wrote:
>> >> From: Peter Antoine
>> >>
>> >> This change adds the programming of the MOCS registers to the gen 9+
>> >> platforms. This change set programs the MOCS register values to a set
>> >> of values that are defined to be optimal.
>> >
>> > If they were optimal why weren't they defaults? I'm not feeling very
>> > satisfied by this explanation.
>> >
>> Hah, yeah, they are definitely not optimal, it's just that I didn't feel
>> fully confident modifying the original message above Peter's Signed-off
>> line. How about we replace that sentence with: "The set of MOCS
>> configuration entries introduced by this patch is intended to be minimal
>> but sufficient to cover the needs of current userspace, it's expected to
>> be extended in the future based on the userspace demand for additional
>> caching configurations."
>
> That's much clearer. However, one now wonders how it will change in the
> future and whether we have sufficient future proofing. Do you mean that
> there is a safe subset of the current tables with higher entries
> reserved for future use (and perhaps a future param to tell userspace
> when they can use them), or perhaps in the future we will allow
> userspace to replace select MOCS tables.
>
> Bikeshedding:
>
> The set of MOCS configuration entries introduced by this patch is intended
> to be minimal but sufficient to cover the needs of current userspace - i.e.
> a good set of defaults. It is expected to be extended in the future to
> provide further default values or to allow userspace to redefine its private
> MOCS tables based on its demand for additional caching configurations.
> In this setup, userspace should only utilize the first N entries, higher
> entries are reserved for future use.
>
Sounds good to me, I'll use your text and also add a comment on top of
the tables saying that currently undefined entries are implicitly
initialized to uncached for forwards compatibility, so that applications
written against newer kernel versions with extended MOCS tables
(i.e. providing more relaxed caching semantics for some of the undefined
entries) will still work when run on older kernels, if not blazingly
fast.
>> >> +/**
>> >> + * get_mocs_settings
>> >> + *
>> >> + * This function will return the values of the MOCS table that needs to
>> >> + * be programmed for the platform. It will return the values that need
>> >> + * to be programmed and if they need to be programmed.
>> >> + *
>> >> + * If the return values is false then the registers do not need
>> >> programming.
>> >> + */
>> >> +static bool get_mocs_settings(struct drm_device *dev,
>> >> + struct drm_i915_mocs_table *table)
>> >> +{
>> >> + bool result = false;
>> >
>> > This looks easy enough to extend to get_mocs_settings(ctx, &table) and
>> > use CONTEXT_SET_PARAM to load a user defined mocs table. These defaults
>> > have the smell of policy in the era where even CPU PAT are becoming user
>> > defined (with per-process definitions). Is it worth shifting these to
>> > userspace? Having sane/safe defaults is good definitely.
>> >
>>
>> Yeah, I also have the feeling that we may want to switch to some dynamic
>> set-up scheme in the future. With only three of the available 62
>> entries in use right now it's likely to take a *long* time until we run
>> out of entries from the global tables though, when (if) that happens we
>> can always switch to dynamic set-up via some new IOCTL without
>> disrupting older userspace relying on the fixed MOCS defaults.
>>
>> Implementing dynamic set-up is less straightforward than it may seem
>> though, because only the MOCS tables for some of the engines are context
>> saved and restored automatically by the hardware, so the settings
>> specified by one context would partially leak into other applications,
>> unless we context-switch the remaining engines manually from the kernel.
>
> Sounds like we need a set of common unalterable mocs tables for the
> shared configs, and limit userspace to doing interesting things on
> select engines. :(
> -Chris
>
> --
> Chris Wilson, Intel Open Source Technology Centre
signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Extend GET_APERTURE ioctl to report available map space
On Wed, Jul 08, 2015 at 02:36:08PM +0100, Tvrtko Ursulin wrote: > > On 07/08/2015 02:28 PM, Chris Wilson wrote: > >On Wed, Jul 08, 2015 at 02:13:43PM +0100, Tvrtko Ursulin wrote: > >> > >>Hi, > >> > >>On 07/08/2015 07:51 AM, ankitprasad.r.sha...@intel.com wrote: > >>>From: Rodrigo Vivi > >>> > >>>When constructing a batchbuffer, it is sometimes crucial to know the > >>>largest hole into which we can fit a fenceable buffer (for example when > >>>handling very large objects on gen2 and gen3). This depends on the > >>>fragmentation of pinned buffers inside the aperture, a question only the > >>>kernel can easily answer. > >>> > >>>This patch extends the current DRM_I915_GEM_GET_APERTURE ioctl to > >>>include a couple of new fields in its reply to userspace - the total > >>>amount of space available in the mappable region of the aperture and > >>>also the single largest block available. > >> > >>Since whatever this returns is a transient number is this really > >>that useful? There are no guarantees that by the time caller tries > >>to act on it it will still be valid. > > > >Yes. My use case is actually after a failure to capture debug > >information. I don't anticipate frequent calls to get_aperture (usually > >just a single call during early init). > > Should it better go to debugfs then? Hmm, I could accept that. In such a scenario, I would suggest we ignore the avail_aperture_space field all together, just report it as max (or whatever) and simply add fields for max stolen, max mappable, max ggtt (already present) and max ppgtt. (Rather than continue trying to kill multiple birds with one stone, where 99.9% of users don't want the overhead.) Move the current patch series into debugfs.c and just add the limits to get_aperture? -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/7] drm/i915: PSR: Flush means invalidate + flush
2015-07-07 20:28 GMT-03:00 Rodrigo Vivi :
> Since flush actually means invalidate + flush we need to force psr
> exit on PSR flush.
>
> On Core platforms there is no way to do the sw tracking so we
There is no way to do the _HW_ tracking?
> simulate it by fully disable psr and reschedule a enable back.
> So a good idea is to minimize sequential disable/enable in cases we
> know that HW tracking like when flush has been originated by a flip.
> Also flip had just invalidated it already.
>
> It also uses origin to minimize the a bit the amount of
> disable/enabled, mainly when flip already had invalidated.
>
> With this patch in place it is possible to do a flush on dirty areas
> properly in a following patch.
>
> Cc: Paulo Zanoni
> Cc: Daniel Vetter
> Signed-off-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/intel_drv.h | 3 +-
> drivers/gpu/drm/i915/intel_frontbuffer.c | 2 +-
> drivers/gpu/drm/i915/intel_psr.c | 51
> +---
> 3 files changed, 36 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 1f3f786..c5005f2 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1329,7 +1329,8 @@ void intel_psr_disable(struct intel_dp *intel_dp);
> void intel_psr_invalidate(struct drm_device *dev,
> unsigned frontbuffer_bits);
> void intel_psr_flush(struct drm_device *dev,
> -unsigned frontbuffer_bits);
> +unsigned frontbuffer_bits,
> +enum fb_op_origin origin);
> void intel_psr_init(struct drm_device *dev);
> void intel_psr_single_frame_update(struct drm_device *dev,
>unsigned frontbuffer_bits);
> diff --git a/drivers/gpu/drm/i915/intel_frontbuffer.c
> b/drivers/gpu/drm/i915/intel_frontbuffer.c
> index cb5a6f0..e73d2ff0 100644
> --- a/drivers/gpu/drm/i915/intel_frontbuffer.c
> +++ b/drivers/gpu/drm/i915/intel_frontbuffer.c
> @@ -128,7 +128,7 @@ void intel_frontbuffer_flush(struct drm_device *dev,
> return;
>
> intel_edp_drrs_flush(dev, frontbuffer_bits);
> - intel_psr_flush(dev, frontbuffer_bits);
> + intel_psr_flush(dev, frontbuffer_bits, origin);
> intel_fbc_flush(dev_priv, frontbuffer_bits);
> }
>
> diff --git a/drivers/gpu/drm/i915/intel_psr.c
> b/drivers/gpu/drm/i915/intel_psr.c
> index d79ba58..dd174ae 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -680,6 +680,7 @@ void intel_psr_invalidate(struct drm_device *dev,
> * intel_psr_flush - Flush PSR
> * @dev: DRM device
> * @frontbuffer_bits: frontbuffer plane tracking bits
> + * @origin: which operation caused the flush
> *
> * Since the hardware frontbuffer tracking has gaps we need to integrate
> * with the software frontbuffer tracking. This function gets called every
> @@ -689,7 +690,7 @@ void intel_psr_invalidate(struct drm_device *dev,
> * Dirty frontbuffers relevant to PSR are tracked in busy_frontbuffer_bits.
> */
> void intel_psr_flush(struct drm_device *dev,
> -unsigned frontbuffer_bits)
> +unsigned frontbuffer_bits, enum fb_op_origin origin)
> {
> struct drm_i915_private *dev_priv = dev->dev_private;
> struct drm_crtc *crtc;
> @@ -707,24 +708,38 @@ void intel_psr_flush(struct drm_device *dev,
> frontbuffer_bits &= INTEL_FRONTBUFFER_ALL_MASK(pipe);
> dev_priv->psr.busy_frontbuffer_bits &= ~frontbuffer_bits;
>
> - /*
> -* On Haswell sprite plane updates don't result in a psr invalidating
> -* signal in the hardware. Which means we need to manually fake this
> in
> -* software for all flushes, not just when we've seen a preceding
> -* invalidation through frontbuffer rendering.
> -*/
> - if (IS_HASWELL(dev) &&
> - (frontbuffer_bits & INTEL_FRONTBUFFER_SPRITE(pipe)))
> - intel_psr_exit(dev);
> + if (HAS_DDI(dev)) {
> + /*
> +* By definition every flush should mean invalidate + flush,
> +* however on core platforms let's minimize the
> +* disable/re-enable so we can avoid the invalidate when flip
> +* originated the flush.
> +*/
> + if (frontbuffer_bits && origin != ORIGIN_FLIP)
> + intel_psr_exit(dev);
>
> - /*
> -* On Valleyview and Cherryview we don't use hardware tracking so
> -* any plane updates or cursor moves don't result in a PSR
> -* invalidating. Which means we need to manually fake this in
> -* software for all flushes, not just when we've seen a preceding
> -* invalidation through frontbuffer rendering. */
> - if (frontbuffer_bits && !HAS_DDI(dev))
> - intel_psr_exit(dev);
> + /*
> +
Re: [Intel-gfx] [PATCH 3/7] drm/i915: PSR: dirty fb operation flushsing frontbuffer
2015-07-08 6:47 GMT-03:00 Daniel Vetter :
> On Tue, Jul 07, 2015 at 04:28:53PM -0700, Rodrigo Vivi wrote:
>> Let's do a frontbuffer flush on dirty fb.
>> To be used for DIRTYFB drm ioctl.
Just a notice: this commit will also be useful for FBC, so I hope that
marking the commit title as "PSR" won't confuse backporters.
>>
>> This patch solves the biggest PSR known issue, that is
>> missed screen updates during boot, mainly when there is a splash
>> screen involved like Plymouth.
Just a clarification: previously you claimed the flush would not solve
the problem, but you didn't have patch 2. Now with patch 2 + this one,
are we solving the biggest PSR problem?
>>
>> Previously PSR was being invalidated by fbdev and Plymounth
>> was taking control with PSR yet invalidated and could get screen
>> updates normally. However with some atomic modeset changes
>> Pymouth modeset over ioctl was now causing frontbuffer flushes
>> making PSR gets back to work while it cannot track the
>> screen updates and exit properly.
>>
>> By adding this flush on dirtyfb we properly track frontbuffer
>> writes and properly exit PSR.
>>
>> Actually all mmap_wc users should call this dirty callback
>> in order to have a proper frontbuffer tracking.
>>
>> In the future it can be extended to return 0 if the whole
>> screen has being flushed or the number of rects flushed
>> as Chris suggested.
>>
>> v2: Remove ORIGIN_FB_DIRTY and use ORIGIN_GTT instead since dirty
>> callback is just called after few screen updates and not on
>> everyone as pointed by Daniel.
>>
>> v3: Use flush instead of invalidate since flush means
>> invalidate + flush and dirty means drawn had finished and
>> it can be flushed.
>>
>> Cc: Chris Wilson
>> Cc: Paulo Zanoni
>> Cc: Daniel Vetter
>> Signed-off-by: Rodrigo Vivi
>> ---
>> drivers/gpu/drm/i915/intel_display.c | 18 ++
>> 1 file changed, 18 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_display.c
>> b/drivers/gpu/drm/i915/intel_display.c
>> index 3c2425f..9a60d15 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -14383,9 +14383,27 @@ static int
>> intel_user_framebuffer_create_handle(struct drm_framebuffer *fb,
>> return drm_gem_handle_create(file, &obj->base, handle);
>> }
>>
>> +static int intel_user_framebuffer_dirty(struct drm_framebuffer *fb,
>> +struct drm_file *file,
>> +unsigned flags, unsigned color,
>> +struct drm_clip_rect *clips,
>> +unsigned num_clips)
>> +{
>> + struct drm_device *dev = fb->dev;
>> + struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb);
>> + struct drm_i915_gem_object *obj = intel_fb->obj;
>> +
>> + mutex_lock(&dev->struct_mutex);
>> + intel_fb_obj_flush(obj, false, ORIGIN_GTT);
>> + mutex_unlock(&dev->struct_mutex);
>
> There's some good discussion going on in some internal thread about what
> to do with wc mmaps. The idea is to use the dirty ioctl to flush them, but
> at least for fbc we already filter ORIGIN_GTT out, which means fbc won't
> see the dirtyfb flushes for cpu wc mmaps. Should we have a ORIGIN_DIRTYFB,
> which essentially just means "any kind of cpu frontbuffer rendering"?
>
> Otoh we can make this change when Paulo implements the wc-mmap for
> frontbuffers stuff.
Yeah, I wanted to discuss that. But I'll do my own local experiments
first, and I can always add a patch on top of this one, so, with or
without changes:
Reviewed-by: Paulo Zanoni
> -Daniel
>
>> +
>> + return 0;
>> +}
>> +
>> static const struct drm_framebuffer_funcs intel_fb_funcs = {
>> .destroy = intel_user_framebuffer_destroy,
>> .create_handle = intel_user_framebuffer_create_handle,
>> + .dirty = intel_user_framebuffer_dirty,
>> };
>>
>> static
>> --
>> 2.1.0
>>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> ___
> 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] [PATCH 1/6] drm/i915/gen9: Removed csr-lock and csr-state
v1: As per review comments from Daniel, removed the csr-lock
and csr-state which was used before in dmc firmware loading.
Planning to have a single async task which will responsible
for firmware loading and register programming for dc5/dc6,
so removed csr-lock and csr-state from intel_csr structure.
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/i915_dma.c | 1 -
drivers/gpu/drm/i915/i915_drv.c | 6
drivers/gpu/drm/i915/i915_drv.h | 10 ---
drivers/gpu/drm/i915/intel_csr.c| 52 -
drivers/gpu/drm/i915/intel_drv.h| 3 --
drivers/gpu/drm/i915/intel_runtime_pm.c | 17 ++-
6 files changed, 3 insertions(+), 86 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index c5349fa..1ebf0e1 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -820,7 +820,6 @@ int i915_driver_load(struct drm_device *dev, unsigned long
flags)
spin_lock_init(&dev_priv->mmio_flip_lock);
mutex_init(&dev_priv->sb_lock);
mutex_init(&dev_priv->modeset_restore_lock);
- mutex_init(&dev_priv->csr_lock);
intel_pm_setup(dev);
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index e44dc0d..4d8d2d8 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1019,12 +1019,6 @@ static int skl_suspend_complete(struct drm_i915_private
*dev_priv)
{
/* Enabling DC6 is not a hard requirement to enter runtime D3 */
- /*
-* This is to ensure that CSR isn't identified as loaded before
-* CSR-loading program is called during runtime-resume.
-*/
- intel_csr_load_status_set(dev_priv, FW_UNINITIALIZED);
-
skl_uninit_cdclk(dev_priv);
return 0;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 1dbd957..b3a0fd6 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -737,12 +737,6 @@ struct intel_uncore {
#define for_each_fw_domain(domain__, dev_priv__, i__) \
for_each_fw_domain_mask(domain__, FORCEWAKE_ALL, dev_priv__, i__)
-enum csr_state {
- FW_UNINITIALIZED = 0,
- FW_LOADED,
- FW_FAILED
-};
-
struct intel_csr {
const char *fw_path;
__be32 *dmc_payload;
@@ -750,7 +744,6 @@ struct intel_csr {
uint32_t mmio_count;
uint32_t mmioaddr[8];
uint32_t mmiodata[8];
- enum csr_state state;
};
#define DEV_INFO_FOR_EACH_FLAG(func, sep) \
@@ -1689,9 +1682,6 @@ struct drm_i915_private {
struct intel_csr csr;
- /* Display CSR-related protection */
- struct mutex csr_lock;
-
struct intel_gmbus gmbus[GMBUS_NUM_PINS];
/** gmbus_mutex protects against concurrent usage of the single hw gmbus
diff --git a/drivers/gpu/drm/i915/intel_csr.c b/drivers/gpu/drm/i915/intel_csr.c
index 6d8a7bf..62fd1b0 100644
--- a/drivers/gpu/drm/i915/intel_csr.c
+++ b/drivers/gpu/drm/i915/intel_csr.c
@@ -32,13 +32,6 @@
* onwards to drive newly added DMC (Display microcontroller) in display
* engine to save and restore the state of display engine when it enter into
* low-power state and comes back to normal.
- *
- * Firmware loading status will be one of the below states: FW_UNINITIALIZED,
- * FW_LOADED, FW_FAILED.
- *
- * Once the firmware is written into the registers status will be moved from
- * FW_UNINITIALIZED to FW_LOADED and for any erroneous condition status will
- * be moved to FW_FAILED.
*/
#define I915_CSR_SKL "i915/skl_dmc_ver1.bin"
@@ -200,40 +193,6 @@ static char intel_get_substepping(struct drm_device *dev)
}
/**
- * intel_csr_load_status_get() - to get firmware loading status.
- * @dev_priv: i915 device.
- *
- * This function helps to get the firmware loading status.
- *
- * Return: Firmware loading status.
- */
-enum csr_state intel_csr_load_status_get(struct drm_i915_private *dev_priv)
-{
- enum csr_state state;
-
- mutex_lock(&dev_priv->csr_lock);
- state = dev_priv->csr.state;
- mutex_unlock(&dev_priv->csr_lock);
-
- return state;
-}
-
-/**
- * intel_csr_load_status_set() - help to set firmware loading status.
- * @dev_priv: i915 device.
- * @state: enumeration of firmware loading status.
- *
- * Set the firmware loading status.
- */
-void intel_csr_load_status_set(struct drm_i915_private *dev_priv,
- enum csr_state state)
-{
- mutex_lock(&dev_priv->csr_lock);
- dev_priv->csr.state = state;
- mutex_unlock(&dev_priv->csr_lock);
-}
-
-/**
* intel_csr_load_program() - write the firmware from memory to register.
* @dev: drm device.
*
@@ -252,7 +211,6 @@ void intel_csr_load_program(struct drm_device *dev)
return;
}
- mutex_lock(&dev_priv->csr_lock);
fw_size = dev_priv->csr.dmc_fw_size;
for (i = 0; i < fw_size; i++)
I915_WR
[Intel-gfx] [PATCH 2/6] drm/i915/gen9: Added a async work for fw-loading and dc5/dc6 programming
v1: As per review comments from Daniel, prevented entering in
dc5/dc6 while firmware loading in process. Now register programming
for dc5/dc6 always will happen followed by firmware loading. Added
a async work which is responsible for both loading the firmware
and register programming for dc5/dc6.
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/i915_drv.c | 1 +
drivers/gpu/drm/i915/i915_drv.h | 5
drivers/gpu/drm/i915/intel_csr.c| 3 ++
drivers/gpu/drm/i915/intel_runtime_pm.c | 51 ++---
4 files changed, 44 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 4d8d2d8..217efcb 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1019,6 +1019,7 @@ static int skl_suspend_complete(struct drm_i915_private
*dev_priv)
{
/* Enabling DC6 is not a hard requirement to enter runtime D3 */
+ flush_work(&dev_priv->csr.csr_work);
skl_uninit_cdclk(dev_priv);
return 0;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b3a0fd6..5ae45bd 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -738,6 +738,8 @@ struct intel_uncore {
for_each_fw_domain_mask(domain__, FORCEWAKE_ALL, dev_priv__, i__)
struct intel_csr {
+ bool dc_state_req;
+ struct work_struct csr_work;
const char *fw_path;
__be32 *dmc_payload;
uint32_t dmc_fw_size;
@@ -2621,6 +2623,9 @@ extern void i915_update_gfx_val(struct drm_i915_private
*dev_priv);
int vlv_force_gfx_clock(struct drm_i915_private *dev_priv, bool on);
void i915_firmware_load_error_print(const char *fw_path, int err);
+/* intel_csr.c */
+void intel_csr_setdc_work_fn(struct work_struct *__work);
+
/* intel_hotplug.c */
void intel_hpd_irq_handler(struct drm_device *dev, u32 pin_mask, u32
long_mask);
void intel_hpd_init(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_csr.c b/drivers/gpu/drm/i915/intel_csr.c
index 62fd1b0..f3b4a17 100644
--- a/drivers/gpu/drm/i915/intel_csr.c
+++ b/drivers/gpu/drm/i915/intel_csr.c
@@ -391,6 +391,7 @@ void intel_csr_ucode_init(struct drm_device *dev)
if (ret) {
i915_firmware_load_error_print(csr->fw_path, ret);
}
+ INIT_WORK(&csr->csr_work, intel_csr_setdc_work_fn);
}
/**
@@ -407,6 +408,8 @@ void intel_csr_ucode_fini(struct drm_device *dev)
if (!HAS_CSR(dev))
return;
+ flush_work(&dev_priv->csr.csr_work);
+
kfree(dev_priv->csr.dmc_payload);
}
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 0b81d6f..f261558 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -563,6 +563,37 @@ static void skl_disable_dc6(struct drm_i915_private
*dev_priv)
POSTING_READ(DC_STATE_EN);
}
+void intel_csr_setdc_work_fn(struct work_struct *__work)
+{
+ struct drm_i915_private *dev_priv =
+ container_of(__work, struct drm_i915_private, csr.csr_work);
+ struct intel_csr *csr = &dev_priv->csr;
+
+ if (csr->dc_state_req) {
+
+ /* TODO: Load the dmc firmware. */
+
+ if (IS_SKYLAKE(dev_priv->dev))
+ skl_enable_dc6(dev_priv);
+ else
+ gen9_enable_dc5(dev_priv);
+ } else {
+ if (IS_SKYLAKE(dev_priv->dev)) {
+ skl_disable_dc6(dev_priv);
+ /*
+* DDI buffer programming unnecessary during
+* driver-load/resume as it's already done during
+* modeset initialization then. It's also invalid
+* here as encoder list is still uninitialized.
+*/
+ if (!dev_priv->power_domains.initializing)
+ intel_prepare_ddi(dev_priv->dev);
+ } else {
+ gen9_disable_dc5(dev_priv);
+ }
+ }
+}
+
static void skl_set_power_well(struct drm_i915_private *dev_priv,
struct i915_power_well *power_well, bool enable)
{
@@ -612,18 +643,8 @@ static void skl_set_power_well(struct drm_i915_private
*dev_priv,
when request is to disable!\n");
if ((GEN9_ENABLE_DC5(dev) || SKL_ENABLE_DC6(dev)) &&
power_well->data == SKL_DISP_PW_2) {
- if (SKL_ENABLE_DC6(dev)) {
- skl_disable_dc6(dev_priv);
- /*
-* DDI buffer programming unnecessary
during driver-load/resume
-* as it's already done during modeset
[Intel-gfx] [PATCH 0/6] Redesign the dmc firmware loading.
v1: Based on review comments from Daniel following changes are done. - More focus is given for better synchronization. - Replaced async firmware loading by using request_firmawre() call. - Prevented entering in dc5/dc6 while firmware loading in process. Now register programming for dc5/dc6 always will happen followed by firmware loading. - Removed the csr-lock and csr-state which was used before. - Added a async work which is responsible for both loading the firmware and register programming for dc5/dc6. - Added flush_work() to explicitly synchronize the async work during suspend and driver unloading. - Corrected the sanity check for mmio address of csr (Requested by Imre). - Removed assert call of csr during disabling dc6 (Requested by Damien). Animesh Manna (6): drm/i915/gen9: Removed csr-lock and csr-state drm/i915/gen9: Added a async work for fw-loading and dc5/dc6 programming drm/i915/gen9: Replaced request_firmware_nowait() by request_firmware(). drm/i915/gen9: Added dmc_present flag to check firmware loading status. drm/i915/skl: Removed assert for csr-fw-loading during disabling dc6. drm/i915/gen9: Corrected the sanity check of mmio address range for csr. drivers/gpu/drm/i915/i915_dma.c | 1 - drivers/gpu/drm/i915/i915_drv.c | 10 +-- drivers/gpu/drm/i915/i915_drv.h | 16 ++-- drivers/gpu/drm/i915/intel_csr.c| 144 +++- drivers/gpu/drm/i915/intel_drv.h| 5 +- drivers/gpu/drm/i915/intel_runtime_pm.c | 62 +++--- 6 files changed, 92 insertions(+), 146 deletions(-) -- 2.0.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/6] drm/i915/gen9: Replaced request_firmware_nowait() by request_firmware().
v1: As per review comments from Daniel, replaced async firmware
loading with request_firmware() which will load the dmc firmware and
once firmware is loaded, dc5/dc6 register programming can be done
in the same thread.
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/i915_drv.c | 3 --
drivers/gpu/drm/i915/intel_csr.c| 79 -
drivers/gpu/drm/i915/intel_drv.h| 2 +-
drivers/gpu/drm/i915/intel_runtime_pm.c | 3 +-
4 files changed, 41 insertions(+), 46 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 217efcb..18aaaf6 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1066,10 +1066,7 @@ static int bxt_resume_prepare(struct drm_i915_private
*dev_priv)
static int skl_resume_prepare(struct drm_i915_private *dev_priv)
{
- struct drm_device *dev = dev_priv->dev;
-
skl_init_cdclk(dev_priv);
- intel_csr_load_program(dev);
return 0;
}
diff --git a/drivers/gpu/drm/i915/intel_csr.c b/drivers/gpu/drm/i915/intel_csr.c
index f3b4a17..8e9395f 100644
--- a/drivers/gpu/drm/i915/intel_csr.c
+++ b/drivers/gpu/drm/i915/intel_csr.c
@@ -192,14 +192,6 @@ static char intel_get_substepping(struct drm_device *dev)
return -ENODATA;
}
-/**
- * intel_csr_load_program() - write the firmware from memory to register.
- * @dev: drm device.
- *
- * CSR firmware is read from a .bin file and kept in internal memory one time.
- * Everytime display comes back from low power state this function is called to
- * copy the firmware from internal memory to registers.
- */
void intel_csr_load_program(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -222,9 +214,9 @@ void intel_csr_load_program(struct drm_device *dev)
}
}
-static void finish_csr_load(const struct firmware *fw, void *context)
+static void finish_csr_load(const struct firmware *fw,
+ struct drm_i915_private *dev_priv)
{
- struct drm_i915_private *dev_priv = context;
struct drm_device *dev = dev_priv->dev;
struct intel_css_header *css_header;
struct intel_package_header *package_header;
@@ -235,16 +227,15 @@ static void finish_csr_load(const struct firmware *fw,
void *context)
uint32_t dmc_offset = CSR_DEFAULT_FW_OFFSET, readcount = 0, nbytes;
uint32_t i;
__be32 *dmc_payload;
- bool fw_loaded = false;
if (!fw) {
i915_firmware_load_error_print(csr->fw_path, 0);
- goto out;
+ return;
}
if ((stepping == -ENODATA) || (substepping == -ENODATA)) {
DRM_ERROR("Unknown stepping info, firmware loading failed\n");
- goto out;
+ return;
}
/* Extract CSS Header information*/
@@ -253,7 +244,7 @@ static void finish_csr_load(const struct firmware *fw, void
*context)
(css_header->header_len * 4)) {
DRM_ERROR("Firmware has wrong CSS header length %u bytes\n",
(css_header->header_len * 4));
- goto out;
+ return;
}
readcount += sizeof(struct intel_css_header);
@@ -264,7 +255,7 @@ static void finish_csr_load(const struct firmware *fw, void
*context)
(package_header->header_len * 4)) {
DRM_ERROR("Firmware has wrong package header length %u bytes\n",
(package_header->header_len * 4));
- goto out;
+ return;
}
readcount += sizeof(struct intel_package_header);
@@ -284,7 +275,7 @@ static void finish_csr_load(const struct firmware *fw, void
*context)
}
if (dmc_offset == CSR_DEFAULT_FW_OFFSET) {
DRM_ERROR("Firmware not supported for %c stepping\n", stepping);
- goto out;
+ return;
}
readcount += dmc_offset;
@@ -293,7 +284,7 @@ static void finish_csr_load(const struct firmware *fw, void
*context)
if (sizeof(struct intel_dmc_header) != (dmc_header->header_len)) {
DRM_ERROR("Firmware has wrong dmc header length %u bytes\n",
(dmc_header->header_len));
- goto out;
+ return;
}
readcount += sizeof(struct intel_dmc_header);
@@ -301,7 +292,7 @@ static void finish_csr_load(const struct firmware *fw, void
*context)
if (dmc_header->mmio_count > ARRAY_SIZE(csr->mmioaddr)) {
DRM_ERROR("Firmware has wrong mmio count %u\n",
dmc_header->mmio_count);
- goto out;
+ return;
}
csr->mmio_count = dmc_header->mmio_count;
for (i = 0; i < dmc_header->mmio_count; i++) {
@@ -309,7 +300,7 @@ static void finish_csr_load(const struct firmware *fw, void
*context)
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Extend GET_APERTURE ioctl to report available map space
On 07/08/2015 02:53 PM, Chris Wilson wrote: On Wed, Jul 08, 2015 at 02:36:08PM +0100, Tvrtko Ursulin wrote: On 07/08/2015 02:28 PM, Chris Wilson wrote: On Wed, Jul 08, 2015 at 02:13:43PM +0100, Tvrtko Ursulin wrote: Hi, On 07/08/2015 07:51 AM, ankitprasad.r.sha...@intel.com wrote: From: Rodrigo Vivi When constructing a batchbuffer, it is sometimes crucial to know the largest hole into which we can fit a fenceable buffer (for example when handling very large objects on gen2 and gen3). This depends on the fragmentation of pinned buffers inside the aperture, a question only the kernel can easily answer. This patch extends the current DRM_I915_GEM_GET_APERTURE ioctl to include a couple of new fields in its reply to userspace - the total amount of space available in the mappable region of the aperture and also the single largest block available. Since whatever this returns is a transient number is this really that useful? There are no guarantees that by the time caller tries to act on it it will still be valid. Yes. My use case is actually after a failure to capture debug information. I don't anticipate frequent calls to get_aperture (usually just a single call during early init). Should it better go to debugfs then? Hmm, I could accept that. In such a scenario, I would suggest we ignore the avail_aperture_space field all together, just report it as max (or whatever) and simply add fields for max stolen, max mappable, max ggtt (already present) and max ppgtt. (Rather than continue trying to kill multiple birds with one stone, where 99.9% of users don't want the overhead.) Move the current patch series into debugfs.c and just add the limits to get_aperture? It would make a more sensible ioctl if you think we could get away with it. Hopefully no userspace tries to do anything smart with aper_available_size today? I see one IGT user, gem_ctx_exec, which probably isn't a blocker. In that case for stolen we would add: stolen_size = dev_priv->gtt.stolen_size stolen_available = stolen_size - bios_reserved (Bios_reserved would have to be stored in i915_gtt since it is currently local to i915_gem_init_stolen.) Plus the ones you listed, mappable_size and ppgtt_size. And the used/largest/fence/... ones go to debugfs. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/6] drm/i915/skl: Removed assert for csr-fw-loading during disabling dc6.
As during disabling dc6 no need to check for csr firmware loading status, so removed the assert call.(Requested by Damien.) Signed-off-by: Animesh Manna --- drivers/gpu/drm/i915/intel_runtime_pm.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c b/drivers/gpu/drm/i915/intel_runtime_pm.c index 01e046e..ba29bfc 100644 --- a/drivers/gpu/drm/i915/intel_runtime_pm.c +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c @@ -527,7 +527,6 @@ static void assert_can_disable_dc6(struct drm_i915_private *dev_priv) if (dev_priv->power_domains.initializing) return; - assert_csr_loaded(dev_priv); WARN(!(I915_READ(DC_STATE_EN) & DC_STATE_EN_UPTO_DC6), "DC6 already programmed to be disabled.\n"); } -- 2.0.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 6/6] drm/i915/gen9: Corrected the sanity check of mmio address range for csr.
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/intel_csr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_csr.c b/drivers/gpu/drm/i915/intel_csr.c
index d600640..f515d54 100644
--- a/drivers/gpu/drm/i915/intel_csr.c
+++ b/drivers/gpu/drm/i915/intel_csr.c
@@ -296,7 +296,7 @@ static void finish_csr_load(const struct firmware *fw,
}
csr->mmio_count = dmc_header->mmio_count;
for (i = 0; i < dmc_header->mmio_count; i++) {
- if (dmc_header->mmioaddr[i] < CSR_MMIO_START_RANGE &&
+ if (dmc_header->mmioaddr[i] < CSR_MMIO_START_RANGE ||
dmc_header->mmioaddr[i] > CSR_MMIO_END_RANGE) {
DRM_ERROR(" Firmware has wrong mmio address 0x%x\n",
dmc_header->mmioaddr[i]);
--
2.0.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/6] drm/i915/gen9: Added dmc_present flag to check firmware loading status.
Firmware loading can be optimized by setting the dmc_present flag
for the first time and later internallly stored firmware data
can be used.
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_csr.c | 24 +++-
2 files changed, 16 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 5ae45bd..4870666 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -746,6 +746,7 @@ struct intel_csr {
uint32_t mmio_count;
uint32_t mmioaddr[8];
uint32_t mmiodata[8];
+ bool dmc_present;
};
#define DEV_INFO_FOR_EACH_FLAG(func, sep) \
diff --git a/drivers/gpu/drm/i915/intel_csr.c b/drivers/gpu/drm/i915/intel_csr.c
index 8e9395f..d600640 100644
--- a/drivers/gpu/drm/i915/intel_csr.c
+++ b/drivers/gpu/drm/i915/intel_csr.c
@@ -333,6 +333,7 @@ static void finish_csr_load(const struct firmware *fw,
/* load csr program during system boot, as needed for DC states */
intel_csr_load_program(dev);
+ dev_priv->csr.dmc_present = true;
DRM_DEBUG_KMS("Finished loading %s\n", dev_priv->csr.fw_path);
}
@@ -352,18 +353,22 @@ void intel_display_load_csr(struct drm_i915_private
*dev_priv)
const struct firmware *fw;
int ret;
- /* CSR supported for platform, load firmware */
- ret = request_firmware(&fw, csr->fw_path,
- &dev_priv->dev->pdev->dev);
+ if (dev_priv->csr.dmc_present)
+ intel_csr_load_program(dev_priv->dev);
+ else {
+ /* CSR supported for platform, load firmware */
+ ret = request_firmware(&fw, csr->fw_path,
+ &dev_priv->dev->pdev->dev);
- DRM_DEBUG_KMS("Loading %s\n", csr->fw_path);
+ DRM_DEBUG_KMS("Loading %s\n", csr->fw_path);
- if (ret) {
- i915_firmware_load_error_print(csr->fw_path, ret);
- return;
+ if (ret) {
+ i915_firmware_load_error_print(csr->fw_path, ret);
+ return;
+ }
+ finish_csr_load(fw, dev_priv);
+ release_firmware(fw);
}
- finish_csr_load(fw, dev_priv);
- release_firmware(fw);
}
/**
@@ -408,6 +413,7 @@ void intel_csr_ucode_fini(struct drm_device *dev)
return;
flush_work(&dev_priv->csr.csr_work);
+ dev_priv->csr.dmc_present = false;
kfree(dev_priv->csr.dmc_payload);
}
--
2.0.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/7] drm/i915: PSR: Remove Low Power HW tracking mask.
2015-07-07 20:28 GMT-03:00 Rodrigo Vivi : > By Spec we should only mask memup and hotplug detection > for hardware tracking cases. However we always masked > LPSP because with power well always enabled on audio > PSR was never being activated and residency was always > zeroed. > > Apparently audio driver is tying power well management > and runtime PM for some reason. But with audio runtime > PM working or with audio completely out of picture > we should remove this mask, otherwise we have a high > risk of miss screen updates as faced by Matthew. > > WARNING: With this patch if snd_intel_hda driver is > running and not releasing power well properly PSR will > constant Exit and Performance Counter will be 0. > > But the best thing of this patch is that with one more > HW tracking working the risks of missed blank screen > are minimized at most. > > This affects just core platforms where PSR exit are also > helped by HW tracking: Haswell, Broadwell and Skylake > for now. > > v2: Fix commit message explanation. It has nothing to do > with runtime PM on i915 as previously advertised. > > Cc: Daniel Vetter > Cc: Matthew Garrett > Signed-off-by: Rodrigo Vivi > --- > drivers/gpu/drm/i915/intel_psr.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/intel_psr.c > b/drivers/gpu/drm/i915/intel_psr.c > index dd174ae..8507932 100644 > --- a/drivers/gpu/drm/i915/intel_psr.c > +++ b/drivers/gpu/drm/i915/intel_psr.c > @@ -400,7 +400,7 @@ void intel_psr_enable(struct intel_dp *intel_dp) > > /* Avoid continuous PSR exit by masking memup and hpd */ > I915_WRITE(EDP_PSR_DEBUG_CTL(dev), EDP_PSR_DEBUG_MASK_MEMUP | > - EDP_PSR_DEBUG_MASK_HPD | EDP_PSR_DEBUG_MASK_LPSP); > + EDP_PSR_DEBUG_MASK_HPD); As I mentioned earlier, we'll need IGT fixes for this one. One of the fixes will be to make the PSR tests enable Audio runtime PM - see the last review for pointers. The other fix will be that patch I sent to you on pastebin that fixes the assertions for PSR when we're using 2 pipes - because now 2 pipes will disable PSR. After the IGT fixes are submitted: Reviewed-by: Paulo Zanoni > > /* Enable PSR on the panel */ > hsw_psr_enable_sink(intel_dp); > -- > 2.1.0 > > ___ > 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 1/2] drm/i915: Extend GET_APERTURE ioctl to report available map space
On Wed, Jul 08, 2015 at 03:24:08PM +0100, Tvrtko Ursulin wrote: > > On 07/08/2015 02:53 PM, Chris Wilson wrote: > >On Wed, Jul 08, 2015 at 02:36:08PM +0100, Tvrtko Ursulin wrote: > >> > >>On 07/08/2015 02:28 PM, Chris Wilson wrote: > >>>On Wed, Jul 08, 2015 at 02:13:43PM +0100, Tvrtko Ursulin wrote: > > Hi, > > On 07/08/2015 07:51 AM, ankitprasad.r.sha...@intel.com wrote: > >From: Rodrigo Vivi > > > >When constructing a batchbuffer, it is sometimes crucial to know the > >largest hole into which we can fit a fenceable buffer (for example when > >handling very large objects on gen2 and gen3). This depends on the > >fragmentation of pinned buffers inside the aperture, a question only the > >kernel can easily answer. > > > >This patch extends the current DRM_I915_GEM_GET_APERTURE ioctl to > >include a couple of new fields in its reply to userspace - the total > >amount of space available in the mappable region of the aperture and > >also the single largest block available. > > Since whatever this returns is a transient number is this really > that useful? There are no guarantees that by the time caller tries > to act on it it will still be valid. > >>> > >>>Yes. My use case is actually after a failure to capture debug > >>>information. I don't anticipate frequent calls to get_aperture (usually > >>>just a single call during early init). > >> > >>Should it better go to debugfs then? > > > >Hmm, I could accept that. In such a scenario, I would suggest we ignore > >the avail_aperture_space field all together, just report it as max (or > >whatever) and simply add fields for max stolen, max mappable, max ggtt > >(already present) and max ppgtt. (Rather than continue trying to kill > >multiple birds with one stone, where 99.9% of users don't want the > >overhead.) > > > >Move the current patch series into debugfs.c and just add the limits to > >get_aperture? > > It would make a more sensible ioctl if you think we could get away > with it. Hopefully no userspace tries to do anything smart with > aper_available_size today? I see one IGT user, gem_ctx_exec, which > probably isn't a blocker. Now that you mention it, we lie anyway there. The idea behind gem_ctx_exec is try and guage how much remaining global gtt space we need to fill with context objects - but important reservations of global gtt aren't even subtracted from the avail aperture space. There's also a use in sna when we run very close to the limit, we double check if the available space is enough. That's semi-sensible, certainly for the gen2-3 system that hit it most. Ok, so we get to keep aper_available_size. -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 5/7] drm/i915: PSR: Increase idle_frames
2015-07-07 20:28 GMT-03:00 Rodrigo Vivi : > Idle frames the number of identical frames needed > before panel can enter PSR. > > There are some panels that requires up to minimum of 4 idle > frames available on the market. For these cases usually > VBT should be used to configure the number of idle frames, > but unfortunately this isn't always true and VBT isn't being > set at all. > > Let's trust VBT when it is set + 1 and use minimum of 4 + 1 > when VBT isn't set. "+1" covers the "of-by-one" case. Reviewed-by: Paulo Zanoni > > Signed-off-by: Rodrigo Vivi > --- > drivers/gpu/drm/i915/intel_psr.c | 7 +-- > 1 file changed, 5 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_psr.c > b/drivers/gpu/drm/i915/intel_psr.c > index 8507932..d40d6f4 100644 > --- a/drivers/gpu/drm/i915/intel_psr.c > +++ b/drivers/gpu/drm/i915/intel_psr.c > @@ -254,10 +254,13 @@ static void hsw_psr_enable_source(struct intel_dp > *intel_dp) > uint32_t max_sleep_time = 0x1f; > /* Lately it was identified that depending on panel idle frame count > * calculated at HW can be off by 1. So let's use what came > -* from VBT + 1 and at minimum 2 to be on the safe side. > +* from VBT + 1. > +* There are also other cases where panel demands at least 4 > +* but VBT is not being set. To cover these 2 cases lets use > +* at least 5 when VBT isn't set to be on the safest side. > */ > uint32_t idle_frames = dev_priv->vbt.psr.idle_frames ? > - dev_priv->vbt.psr.idle_frames + 1 : 2; > + dev_priv->vbt.psr.idle_frames + 1 : 5; > uint32_t val = 0x0; > const uint32_t link_entry_time = EDP_PSR_MIN_LINK_ENTRY_TIME_8_LINES; > > -- > 2.1.0 > > ___ > 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] [RFC] drm/i915: Caching seqno of most recently submitted request.
The hang checker needs to inspect whether or not the ring request list is empty
as well as if the given engine has reached or passed the most recently
submitted request. The problem with this is that the hang checker cannot grab
the struct_mutex, which is required in order to safely inspect requests since
requests might be deallocated during inspection. In the past we've had kernel
panics due to this very unsynchronized access in the hang checker.
One solution to this problem is to not inspect the requests directly since
we're only interested in the seqno of the most recently submitted request - not
the request itself. Instead the seqno of the most recently submitted request is
cached, which the hang checker then inspects, circumventing the issue of
synchronization from the hang checker entirely.
Signed-off-by: Tomas Elf
---
drivers/gpu/drm/i915/i915_gem.c | 24
drivers/gpu/drm/i915/i915_irq.c | 14 ++
drivers/gpu/drm/i915/intel_lrc.c| 1 +
drivers/gpu/drm/i915/intel_ringbuffer.c | 1 +
drivers/gpu/drm/i915/intel_ringbuffer.h | 7 +++
5 files changed, 39 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index a0bff41..98cd429 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2549,6 +2549,7 @@ void __i915_add_request(struct drm_i915_gem_request
*request,
request->batch_obj = obj;
request->emitted_jiffies = jiffies;
+ ring->last_cached_seqno = request->seqno;
list_add_tail(&request->list, &ring->request_list);
trace_i915_gem_request_add(request);
@@ -2784,6 +2785,8 @@ static void i915_gem_reset_ring_cleanup(struct
drm_i915_private *dev_priv,
i915_gem_request_retire(request);
}
+
+ ring->last_cached_seqno = 0;
}
void i915_gem_restore_fences(struct drm_device *dev)
@@ -2846,6 +2849,7 @@ i915_gem_retire_requests_ring(struct intel_engine_cs
*ring)
*/
while (!list_empty(&ring->request_list)) {
struct drm_i915_gem_request *request;
+ u32 req_seqno;
request = list_first_entry(&ring->request_list,
struct drm_i915_gem_request,
@@ -2854,7 +2858,26 @@ i915_gem_retire_requests_ring(struct intel_engine_cs
*ring)
if (!i915_gem_request_completed(request, true))
break;
+ req_seqno = request->seqno;
i915_gem_request_retire(request);
+
+ /*
+* It's ok to have a stale last_cached_seqno since the hang
+* checker does the same comparison as below and reaches the
+* same conclusion as we do here. If last_cached_seqno is stale
+* and the engine seqno passes last_cached_seqno the engine is
+* probably idle. Also, as long as newly queued requests
+* update last_cached_seqno in __i915_add_request() we won't
+* have to clear last_cached_seqno here. It's only when we
+* reach the last request in the list that we have to clear
+* last_cached_seqno. At that point it would not be ok to have
+* zero last_cached_seqno but at the same time have the request
+* queued up (pending removal) since then the hang checker
+* would see an inconsistent combination of request list state
+* and cached seqno.
+*/
+ if (req_seqno >= ring->last_cached_seqno)
+ ring->last_cached_seqno = 0;
}
/* Move any buffers on the active list that are no longer referenced
@@ -5209,6 +5232,7 @@ init_ring_lists(struct intel_engine_cs *ring)
{
INIT_LIST_HEAD(&ring->active_list);
INIT_LIST_HEAD(&ring->request_list);
+ ring->last_cached_seqno = 0;
}
void i915_init_vm(struct drm_i915_private *dev_priv,
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index a6fbe64..46ac99a 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2484,18 +2484,16 @@ static void gen8_disable_vblank(struct drm_device *dev,
int pipe)
spin_unlock_irqrestore(&dev_priv->irq_lock, irqflags);
}
-static struct drm_i915_gem_request *
-ring_last_request(struct intel_engine_cs *ring)
-{
- return list_entry(ring->request_list.prev,
- struct drm_i915_gem_request, list);
-}
-
static bool
ring_idle(struct intel_engine_cs *ring)
{
+ u32 current_seqno;
+
+ current_seqno = ring->get_seqno(ring, false);
+
return (list_empty(&ring->request_list) ||
- i915_gem_request_completed(ring_last_request(ring), false));
+ i915_seqno_passed(current_seqno,
+ ring->last_cached_seqno));
}
static bool
diff
[Intel-gfx] [PATCHv8] drm/i915: Added Programming of the MOCS
From: Peter Antoine
This change adds the programming of the MOCS registers to the gen 9+
platforms. The set of MOCS configuration entries introduced by this
patch is intended to be minimal but sufficient to cover the needs of
current userspace - i.e. a good set of defaults. It is expected to be
extended in the future to provide further default values or to allow
userspace to redefine its private MOCS tables based on its demand for
additional caching configurations. In this setup, userspace should
only utilize the first N entries, higher entries are reserved for
future use.
It creates a fixed register set that is programmed across the different
engines so that all engines have the same table. This is done as the
main RCS context only holds the registers for itself and the shared
L3 values. By trying to keep the registers consistent across the
different engines it should make the programming for the registers
consistent.
v2:
-'static const' for private data structures and style changes.(Matt Turner)
v3:
- Make the tables "slightly" more readable. (Damien Lespiau)
- Updated tables fix performance regression.
v4:
- Code formatting. (Chris Wilson)
- re-privatised mocs code. (Daniel Vetter)
v5:
- Changed the name of a function. (Chris Wilson)
v6:
- re-based
- Added Mesa table entry (skylake & broxton) (Francisco Jerez)
- Tidied up the readability defines (Francisco Jerez)
- NUMBER of entries defines wrong. (Jim Bish)
- Added comments to clear up the meaning of the tables (Jim Bish)
Signed-off-by: Peter Antoine
v7 (Francisco Jerez):
- Don't write L3-specific MOCS_ESC/SCC values into the e/LLC control
tables. Prefix L3-specific defines consistently with L3_ and
e/LLC-specific defines with LE_ to avoid this kind of confusion in
the future.
- Change L3CC WT define back to RESERVED (matches my hardware
documentation and the original patch, probably a misunderstanding
of my own previous comment).
- Drop Android tables, define new minimal tables more suitable for the
open source stack.
- Add comment that the MOCS tables are part of the kernel ABI.
- Move intel_logical_ring_begin() and _advance() calls one level down
(Chris Wilson).
- Minor formatting and style fixes.
v8 (Francisco Jerez):
- Add table size sanity check to emit_mocs_control/l3cc_table() (Chris
Wilson).
- Add comment about undefined entries being implicitly set to uncached
for forwards compatibility.
Signed-off-by: Francisco Jerez
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/i915_reg.h | 9 +
drivers/gpu/drm/i915/intel_lrc.c | 11 +-
drivers/gpu/drm/i915/intel_lrc.h | 1 +
drivers/gpu/drm/i915/intel_mocs.c | 337 ++
drivers/gpu/drm/i915/intel_mocs.h | 57 +++
6 files changed, 414 insertions(+), 2 deletions(-)
create mode 100644 drivers/gpu/drm/i915/intel_mocs.c
create mode 100644 drivers/gpu/drm/i915/intel_mocs.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index de21965..e52e012 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -36,6 +36,7 @@ i915-y += i915_cmd_parser.o \
i915_trace_points.o \
intel_hotplug.o \
intel_lrc.o \
+ intel_mocs.o \
intel_ringbuffer.o \
intel_uncore.o
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 2a29bcc..9b17260 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7906,4 +7906,13 @@ enum skl_disp_power_wells {
#define _PALETTE_A (dev_priv->info.display_mmio_offset + 0xa000)
#define _PALETTE_B (dev_priv->info.display_mmio_offset + 0xa800)
+/* MOCS (Memory Object Control State) registers */
+#define GEN9_LNCFCMOCS0(0xB020)/* L3 Cache Control
base */
+
+#define GEN9_GFX_MOCS_0(0xc800)/* Graphics MOCS base
register*/
+#define GEN9_MFX0_MOCS_0 (0xc900)/* Media 0 MOCS base register*/
+#define GEN9_MFX1_MOCS_0 (0xcA00)/* Media 1 MOCS base register*/
+#define GEN9_VEBOX_MOCS_0 (0xcB00)/* Video MOCS base register*/
+#define GEN9_BLT_MOCS_0(0xcc00)/* Blitter MOCS base
register*/
+
#endif /* _I915_REG_H_ */
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index d4f8b43..466d17c 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -135,6 +135,7 @@
#include
#include
#include "i915_drv.h"
+#include "intel_mocs.h"
#define GEN9_LR_CONTEXT_RENDER_SIZE (22 * PAGE_SIZE)
#define GEN8_LR_CONTEXT_RENDER_SIZE (20 * PAGE_SIZE)
@@ -772,8 +773,7 @@ static int logical_ring_prepare(struct drm_i915_gem_request
*req, int bytes)
*
* Return: non-zero if the ringbuffer is not ready to be written to.
*/
-static int intel_logical_ring_begin(struct drm_i915_gem_request *req,
- int num_dwords)
+int intel_logical_ring_begin(struct drm_i
Re: [Intel-gfx] [PATCHv8] drm/i915: Added Programming of the MOCS
On Wed, Jul 08, 2015 at 05:51:22PM +0300, Francisco Jerez wrote:
Just a few style nits, didn't look at the actual contents...
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 2a29bcc..9b17260 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7906,4 +7906,13 @@ enum skl_disp_power_wells {
> #define _PALETTE_A (dev_priv->info.display_mmio_offset + 0xa000)
> #define _PALETTE_B (dev_priv->info.display_mmio_offset + 0xa800)
>
> +/* MOCS (Memory Object Control State) registers */
> +#define GEN9_LNCFCMOCS0 (0xB020)/* L3 Cache Control
> base */
> +
> +#define GEN9_GFX_MOCS_0 (0xc800)/* Graphics MOCS base
> register*/
> +#define GEN9_MFX0_MOCS_0 (0xc900)/* Media 0 MOCS base register*/
> +#define GEN9_MFX1_MOCS_0 (0xcA00)/* Media 1 MOCS base register*/
> +#define GEN9_VEBOX_MOCS_0(0xcB00)/* Video MOCS base register*/
> +#define GEN9_BLT_MOCS_0 (0xcc00)/* Blitter MOCS base
> register*/
No need for all the parens.
> diff --git a/drivers/gpu/drm/i915/intel_lrc.h
> b/drivers/gpu/drm/i915/intel_lrc.h
> index e0299fb..64f89f99 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.h
> +++ b/drivers/gpu/drm/i915/intel_lrc.h
> @@ -42,6 +42,7 @@ int intel_logical_ring_reserve_space(struct
> drm_i915_gem_request *request);
> void intel_logical_ring_stop(struct intel_engine_cs *ring);
> void intel_logical_ring_cleanup(struct intel_engine_cs *ring);
> int intel_logical_rings_init(struct drm_device *dev);
> +int intel_logical_ring_begin(struct drm_i915_gem_request *req, int
> num_dwords);
>
> int logical_ring_flush_all_caches(struct drm_i915_gem_request *req);
> /**
> diff --git a/drivers/gpu/drm/i915/intel_mocs.c
> b/drivers/gpu/drm/i915/intel_mocs.c
> new file mode 100644
> index 000..130bcbe
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/intel_mocs.c
> @@ -0,0 +1,337 @@
> +/*
> + * Copyright (c) 2015 Intel Corporation
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions: *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> FROM,
> + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
> THE
> + * SOFTWARE.
> + */
> +
> +#include "intel_mocs.h"
> +#include "intel_lrc.h"
> +#include "intel_ringbuffer.h"
> +
> +/* structures required */
> +struct drm_i915_mocs_entry {
> + u32 control_value;
> + u16 l3cc_value;
> +};
> +
> +struct drm_i915_mocs_table {
> + u32 size;
> + const struct drm_i915_mocs_entry*table;
> +};
> +
> +/* Defines for the tables (XXX_MOCS_0 - XXX_MOCS_63) */
> +#define LE_CACHEABILITY(value) (value << 0)
> +#define LE_TGT_CACHE(value) (value << 2)
> +#define LE_LRUM(value) (value << 4)
> +#define LE_AOM(value)(value << 6)
> +#define LE_RSC(value)(value << 7)
> +#define LE_SCC(value)(value << 8)
> +#define LE_PFM(value)(value << 11)
> +#define LE_SCF(value)(value << 14)
> +
> +/* Defines for the tables (LNCFMOCS0 - LNCFMOCS31) - two entries per word */
> +#define L3_ESC(value)(value << 0)
> +#define L3_SCC(value)(value << 1)
> +#define L3_CACHEABILITY(value) (value << 4)
These should have parens arond (value) to avoid suprises if someone
passes in something more complicated than a single number.
> +
> +/* Helper defines */
> +#define GEN9_NUM_MOCS_ENTRIES(62) /* 62 out of 64 - 63 & 64 are
> reserved. */
> +
> +/* (e)LLC caching options */
> +#define LE_PAGETABLE (0)
> +#define LE_UC(1)
> +#define LE_WT(2)
> +#define LE_WB(3)
> +
> +/* L3 caching options */
> +#define L3_DIRECT(0)
> +#define L3_UC(1)
> +#define L3_RESERVED (2)
> +#define L3_WB(3)
> +
> +/* Target cache */
> +#define ELLC
Re: [Intel-gfx] [PATCH v4] drm/i915: Add soft-pinning API for execbuffer
> -Original Message-
> From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> Sent: Saturday, July 4, 2015 1:24 PM
> To: Kristian Høgsberg
> Cc: Daniel, Thomas; Belgaumkar, Vinay; intel-gfx@lists.freedesktop.org; Michal
> Winiarsky; Goel, Akash
> Subject: Re: [Intel-gfx] [PATCH v4] drm/i915: Add soft-pinning API for
> execbuffer
>
> On Fri, Jul 03, 2015 at 10:29:44PM -0700, Kristian Høgsberg wrote:
> > On Tue, Jun 30, 2015 at 7:13 AM, Thomas Daniel
> wrote:
> > > From: Chris Wilson
> > >
> > > Userspace can pass in an offset that it presumes the object is located
> > > at. The kernel will then do its utmost to fit the object into that
> > > location. The assumption is that userspace is handling its own object
> > > locations (for example along with full-ppgtt) and that the kernel will
> > > rarely have to make space for the user's requests.
> > >
> > > Signed-off-by: Chris Wilson
> > >
> > > v2: Fixed incorrect eviction found by Michal Winiarski - fix suggested by
> > > Chris
> > > Wilson. Fixed incorrect error paths causing crash found by Michal
> > > Winiarski.
> > > (Not published externally)
> > >
> > > v3: Rebased because of trivial conflict in object_bind_to_vm. Fixed
> > > eviction
> > > to allow eviction of soft-pinned objects when another soft-pinned object
> used
> > > by a subsequent execbuffer overlaps reported by Michal Winiarski.
> > > (Not published externally)
> > >
> > > v4: Moved soft-pinned objects to the front of ordered_vmas so that they
> > > are
> > > pinned first after an address conflict happens to avoid repeated
> > > conflicts in
> > > rare cases (Suggested by Chris Wilson). Expanded comment on
> > > drm_i915_gem_exec_object2.offset to cover this new API.
>
> Note this patch is outdated compared to the one I have in my tree. There
> are also requirements to improve drm_mm_reserve_node().
What requirements are these?
> > Can we add an I915_PARAM_HAS_EXEC_PINNED param for this feature?
>
> Yeah, it's not that difficult to test,
>
> static bool test_has_softpin(int fd)
> {
>struct drm_i915_gem_create create;
>struct drm_i915_gem_exec_object2 object;
>struct drm_i915_gem_pwrite pwrite;
>struct drm_i915_gem_execbuffer2 execbuf;
>uint32_t batch[2] = { 0xa << 23 };
>bool ret = false;
>
>if (DBG_NO_SOFTPIN)
> return DBG_NO_SOFTPIN < 0;
>
>if (gem_param(fd, I915_PARAM_HAS_ALIASING_PPGTT) < 2)
> return false;
>
>memset(&create, 0, sizeof(create));
>create.size = 4096;
>drmIoctl(fd, DRM_IOCTL_I915_GEM_CREATE, &create);
>
>memset(&pwrite, 0, sizeof(pwrite));
>pwrite.handle = create.handle;
>pwrite.offset = 0;
>pwrite.size = sizeof(batch);
>pwrite.data_ptr = (uintptr_t)batch;
>if (drmIoctl(fd, DRM_IOCTL_I915_GEM_PWRITE, &pwrite))
> goto fail;
>
>object.handle = create.handle;
>
>memset(&execbuf, 0, sizeof(execbuf));
>execbuf.buffers_ptr = (uintptr_t)&object;
>execbuf.buffer_count = 1;
>if (drmIoctl(fd, DRM_IOCTL_I915_GEM_EXECBUFFER2, &execbuf))
> goto fail;
>
>object.flags = EXEC_OBJECT_PINNED;
>ret = drmIoctl(fd, DRM_IOCTL_I915_GEM_EXECBUFFER2, &execbuf) == 0;
> fail:
>drmIoctl(fd, DRM_IOCTL_GEM_CLOSE, &create);
>
>return ret;
> }
>
> but compares to
>
> static bool test_has_softpin(int fd)
> {
>if (DBG_NO_SOFTPIN)
> return DBG_NO_SOFTPIN < 0;
>
>if (gem_param(fd, I915_PARAM_HAS_ALIASING_PPGTT) < 2)
> return false;
>
>return gem_param(fd, I915_PARAM_HAS_EXEC_SOFTPIN) > 0;
> }
>
> with a parameter. At some point, we probably want to add a GETPARAMV!
Yes, a parameter would be cleaner.
Thomas.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/7] drm/i915: fbdev restore mode needs to invalidate frontbuffer
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) Task id: 6749 -Summary- Platform Delta drm-intel-nightly Series Applied ILK 302/302 302/302 SNB 312/316 312/316 IVB 343/343 343/343 BYT -2 287/287 285/287 HSW 380/380 380/380 -Detailed- Platform Testdrm-intel-nightly Series Applied *BYT igt@gem_partial_pwrite_pread@reads-display PASS(1) FAIL(1) *BYT igt@gem_partial_pwrite_pread@reads-uncached PASS(1) FAIL(1) Note: You need to pay more attention to line start with '*' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCHv7] drm/i915: Added Programming of the MOCS
On 07/07/2015 20:13, Francisco Jerez wrote:
From: Peter Antoine
This change adds the programming of the MOCS registers to the gen 9+
platforms. This change set programs the MOCS register values to a set
of values that are defined to be optimal.
It creates a fixed register set that is programmed across the different
engines so that all engines have the same table. This is done as the
main RCS context only holds the registers for itself and the shared
L3 values. By trying to keep the registers consistent across the
different engines it should make the programming for the registers
consistent.
v2:
-'static const' for private data structures and style changes.(Matt Turner)
v3:
- Make the tables "slightly" more readable. (Damien Lespiau)
- Updated tables fix performance regression.
v4:
- Code formatting. (Chris Wilson)
- re-privatised mocs code. (Daniel Vetter)
v5:
- Changed the name of a function. (Chris Wilson)
v6:
- re-based
- Added Mesa table entry (skylake & broxton) (Francisco Jerez)
- Tidied up the readability defines (Francisco Jerez)
- NUMBER of entries defines wrong. (Jim Bish)
- Added comments to clear up the meaning of the tables (Jim Bish)
Signed-off-by: Peter Antoine
v7 (Francisco Jerez):
- Don't write L3-specific MOCS_ESC/SCC values into the e/LLC control
tables. Prefix L3-specific defines consistently with L3_ and
e/LLC-specific defines with LE_ to avoid this kind of confusion in
the future.
- Change L3CC WT define back to RESERVED (matches my hardware
documentation and the original patch, probably a misunderstanding
of my own previous comment).
- Drop Android tables, define new minimal tables more suitable for the
open source stack.
- Add comment that the MOCS tables are part of the kernel ABI.
- Move intel_logical_ring_begin() and _advance() calls one level down
(Chris Wilson).
- Minor formatting and style fixes.
Signed-off-by: Francisco Jerez
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/i915_reg.h | 9 ++
drivers/gpu/drm/i915/intel_lrc.c | 11 +-
drivers/gpu/drm/i915/intel_lrc.h | 1 +
drivers/gpu/drm/i915/intel_mocs.c | 324 ++
drivers/gpu/drm/i915/intel_mocs.h | 57 +++
6 files changed, 401 insertions(+), 2 deletions(-)
create mode 100644 drivers/gpu/drm/i915/intel_mocs.c
create mode 100644 drivers/gpu/drm/i915/intel_mocs.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index de21965..e52e012 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -36,6 +36,7 @@ i915-y += i915_cmd_parser.o \
i915_trace_points.o \
intel_hotplug.o \
intel_lrc.o \
+ intel_mocs.o \
intel_ringbuffer.o \
intel_uncore.o
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 2a29bcc..9b17260 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7906,4 +7906,13 @@ enum skl_disp_power_wells {
#define _PALETTE_A (dev_priv->info.display_mmio_offset + 0xa000)
#define _PALETTE_B (dev_priv->info.display_mmio_offset + 0xa800)
+/* MOCS (Memory Object Control State) registers */
+#define GEN9_LNCFCMOCS0(0xB020)/* L3 Cache Control
base */
+
+#define GEN9_GFX_MOCS_0(0xc800)/* Graphics MOCS base
register*/
+#define GEN9_MFX0_MOCS_0 (0xc900)/* Media 0 MOCS base register*/
+#define GEN9_MFX1_MOCS_0 (0xcA00)/* Media 1 MOCS base register*/
+#define GEN9_VEBOX_MOCS_0 (0xcB00)/* Video MOCS base register*/
+#define GEN9_BLT_MOCS_0(0xcc00)/* Blitter MOCS base
register*/
+
#endif /* _I915_REG_H_ */
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index d4f8b43..466d17c 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -135,6 +135,7 @@
#include
#include
#include "i915_drv.h"
+#include "intel_mocs.h"
#define GEN9_LR_CONTEXT_RENDER_SIZE (22 * PAGE_SIZE)
#define GEN8_LR_CONTEXT_RENDER_SIZE (20 * PAGE_SIZE)
@@ -772,8 +773,7 @@ static int logical_ring_prepare(struct drm_i915_gem_request
*req, int bytes)
*
* Return: non-zero if the ringbuffer is not ready to be written to.
*/
-static int intel_logical_ring_begin(struct drm_i915_gem_request *req,
- int num_dwords)
+int intel_logical_ring_begin(struct drm_i915_gem_request *req, int num_dwords)
{
struct drm_i915_private *dev_priv;
int ret;
@@ -1675,6 +1675,13 @@ static int gen8_init_rcs_context(struct
drm_i915_gem_request *req)
if (ret)
return ret;
+ /*
+* Failing to program the MOCS is non-fatal.The system will not
+* run at peak performance. So generate a warning and carry on.
+*/
+ if (intel_rcs_context_init_mocs(req) != 0)
+ DRM_ERROR("MOCS failed to program: expect
Re: [Intel-gfx] [PATCH] drm/i915: Handle HPD when it has actually occurred
On Wed, Jul 08, 2015 at 05:07:47PM +0530, Sonika Jindal wrote:
> Writing to PCH_PORT_HOTPLUG for each interrupt is not required.
> Handle it only if hpd has actually occurred like we handle other
> interrupts.
> v2: Make few variables local to if block (Ville)
> v3: Add check for ibx/cpt both (Ville).
> While at it, remove the redundant check for hotplug_trigger from
> pch_get_hpd_pins
> v4: Indentation (Ville)
>
> Reviewed-by: Ville Syrjälä
> Signed-off-by: Sonika Jindal
Queued for -next, thanks for the patch.
-Daniel
> ---
> drivers/gpu/drm/i915/i915_irq.c | 32 +---
> 1 file changed, 17 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index a6fbe64..a897f68 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -1266,9 +1266,6 @@ static void pch_get_hpd_pins(u32 *pin_mask, u32
> *long_mask,
> *pin_mask = 0;
> *long_mask = 0;
>
> - if (!hotplug_trigger)
> - return;
> -
> for_each_hpd_pin(i) {
> if ((hpd[i] & hotplug_trigger) == 0)
> continue;
> @@ -1658,14 +1655,17 @@ static void ibx_irq_handler(struct drm_device *dev,
> u32 pch_iir)
> struct drm_i915_private *dev_priv = dev->dev_private;
> int pipe;
> u32 hotplug_trigger = pch_iir & SDE_HOTPLUG_MASK;
> - u32 dig_hotplug_reg;
> - u32 pin_mask, long_mask;
>
> - dig_hotplug_reg = I915_READ(PCH_PORT_HOTPLUG);
> - I915_WRITE(PCH_PORT_HOTPLUG, dig_hotplug_reg);
> + if (hotplug_trigger) {
> + u32 dig_hotplug_reg, pin_mask, long_mask;
>
> - pch_get_hpd_pins(&pin_mask, &long_mask, hotplug_trigger,
> dig_hotplug_reg, hpd_ibx);
> - intel_hpd_irq_handler(dev, pin_mask, long_mask);
> + dig_hotplug_reg = I915_READ(PCH_PORT_HOTPLUG);
> + I915_WRITE(PCH_PORT_HOTPLUG, dig_hotplug_reg);
> +
> + pch_get_hpd_pins(&pin_mask, &long_mask, hotplug_trigger,
> + dig_hotplug_reg, hpd_ibx);
> + intel_hpd_irq_handler(dev, pin_mask, long_mask);
> + }
>
> if (pch_iir & SDE_AUDIO_POWER_MASK) {
> int port = ffs((pch_iir & SDE_AUDIO_POWER_MASK) >>
> @@ -1757,14 +1757,16 @@ static void cpt_irq_handler(struct drm_device *dev,
> u32 pch_iir)
> struct drm_i915_private *dev_priv = dev->dev_private;
> int pipe;
> u32 hotplug_trigger = pch_iir & SDE_HOTPLUG_MASK_CPT;
> - u32 dig_hotplug_reg;
> - u32 pin_mask, long_mask;
>
> - dig_hotplug_reg = I915_READ(PCH_PORT_HOTPLUG);
> - I915_WRITE(PCH_PORT_HOTPLUG, dig_hotplug_reg);
> + if (hotplug_trigger) {
> + u32 dig_hotplug_reg, pin_mask, long_mask;
>
> - pch_get_hpd_pins(&pin_mask, &long_mask, hotplug_trigger,
> dig_hotplug_reg, hpd_cpt);
> - intel_hpd_irq_handler(dev, pin_mask, long_mask);
> + dig_hotplug_reg = I915_READ(PCH_PORT_HOTPLUG);
> + I915_WRITE(PCH_PORT_HOTPLUG, dig_hotplug_reg);
> + pch_get_hpd_pins(&pin_mask, &long_mask, hotplug_trigger,
> + dig_hotplug_reg, hpd_cpt);
> + intel_hpd_irq_handler(dev, pin_mask, long_mask);
> + }
>
> if (pch_iir & SDE_AUDIO_POWER_MASK_CPT) {
> int port = ffs((pch_iir & SDE_AUDIO_POWER_MASK_CPT) >>
> --
> 1.7.10.4
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: storm detection documentation update
On Wed, Jul 08, 2015 at 06:54:06PM +0530, Sivakumar Thulasimani wrote: > > > On 7/7/2015 5:01 PM, Daniel Vetter wrote: > >On Tue, Jul 07, 2015 at 04:10:49PM +0530, Sivakumar Thulasimani wrote: > >>From: "Thulasimani,Sivakumar" > >> > >>Update the hotplug documentation to explain that hotplug storm > >>is not expected for Display port panels and hence is not handled > >>in current code. > >> > >>Signed-off-by: Sivakumar Thulasimani > >>--- > >> drivers/gpu/drm/i915/intel_hotplug.c |4 > >> 1 file changed, 4 insertions(+) > >> > >>diff --git a/drivers/gpu/drm/i915/intel_hotplug.c > >>b/drivers/gpu/drm/i915/intel_hotplug.c > >>index bac91a1..7dc5e6a 100644 > >>--- a/drivers/gpu/drm/i915/intel_hotplug.c > >>+++ b/drivers/gpu/drm/i915/intel_hotplug.c > >>@@ -66,6 +66,10 @@ > >> * while before being re-enabled. The intention is to mitigate issues > >> raising > >> * from broken hardware triggering massive amounts of interrupts and > >> grinding > >> * the system to a halt. > >>+ * > >>+ * Hotplug interrupt storm is not expected on Display port panel, hence the > >>+ * current code only handles disabling and later enabling of HPD interrupts > >>+ * for HDMI panels through the storm handling set of functions. > >This isn't accurate, we handle storms on everything _but_ DP (tv, vga, > >sdvo, ...). I'd go with > > > > * Hotplug interrupt storm is not expected on Display port panel, hence the > > * current code doesn't handle irq reenabling when a DP sink is connected > > * and the hpd is handled by the DP callbacks. But on DP+ ports > > * storms are still handled correctly in all other cases (e.g. due to HDMI > > * sinks). > > > >Could still be improved I think. > > > >-Daniel > > > Sorry i don't get the "DP+" reference here. By DP+, do you mean dongles ? > passive dongles will report them selves as HDMI to respective detect > routines > active dongles will be still treated as DP hence not handling HPD will apply > to any > display connected through active dongle as well. DP+ is DP with support for HDMI with level shifter cables (i.e. all the ports on intel chips). I just wanted to make it clear that storm handling doesn't work if we have a confirmed DP sink on the port, but will work in any other cases (nothing or HDMI sink or DVI or whatever connected). Like I said some room for improvement ;-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation 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 v4 14/18] drm/i915: object size needs to be u64
On Wed, Jul 08, 2015 at 12:22:58PM +0100, Michel Thierry wrote:
> On 7/7/2015 9:08 PM, Chris Wilson wrote:
> >On Tue, Jul 07, 2015 at 04:44:30PM +0100, Michel Thierry wrote:
> >>On 7/7/2015 4:27 PM, Chris Wilson wrote:
> >>>On Tue, Jul 07, 2015 at 04:14:59PM +0100, Michel Thierry wrote:
> In a 48b world, users can try to allocate buffers bigger than 4GB; in
> these cases it is important that size is a 64b variable.
>
> Also added a warning for illegal bind with size = 0.
>
> Signed-off-by: Michel Thierry
> ---
> drivers/gpu/drm/i915/i915_gem.c | 5 +++--
> drivers/gpu/drm/i915/i915_gem_gtt.c | 3 +++
> 2 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c
> b/drivers/gpu/drm/i915/i915_gem.c
> index a0bff41..ebfb789 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -3718,7 +3718,8 @@ i915_gem_object_bind_to_vm(struct
> drm_i915_gem_object *obj,
> {
> struct drm_device *dev = obj->base.dev;
> struct drm_i915_private *dev_priv = dev->dev_private;
> - u32 size, fence_size, fence_alignment, unfenced_alignment;
> + u32 fence_alignment, unfenced_alignment;
> + u64 size, fence_size;
> u64 start =
> flags & PIN_OFFSET_BIAS ? flags & PIN_OFFSET_MASK : 0;
> u64 end =
> @@ -3777,7 +3778,7 @@ i915_gem_object_bind_to_vm(struct
> drm_i915_gem_object *obj,
> * attempt to find space.
> */
> if (size > end) {
> - DRM_DEBUG("Attempting to bind an object (view type=%u) larger
> than the aperture: size=%u > %s aperture=%llu\n",
> + DRM_DEBUG("Attempting to bind an object (view type=%u) larger
> than the aperture: size=%llu > %s aperture=%llu\n",
> ggtt_view ? ggtt_view->type : 0,
> size,
> flags & PIN_MAPPABLE ? "mappable" : "total",
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
> b/drivers/gpu/drm/i915/i915_gem_gtt.c
> index 449a245..900bce6 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> @@ -3312,6 +3312,9 @@ int i915_vma_bind(struct i915_vma *vma, enum
> i915_cache_level cache_level,
> if (WARN_ON(flags == 0))
> return -EINVAL;
>
> + if (WARN_ON(vma->node.size == 0))
> + return -EINVAL;
> >>>
> >>>This is superfluous. We don't allow size=0 object creation, and the test
> >>>is better (if at all) at vma_create, but what you mean here is
> >>>WARN_ON(!drm_mm_node_allocated()) which seems sensisble. And both of
> >>>these would be better as ENODEV so we don't confuse the user when they
> >>>get propagated back to userspace.
> >>>-Chris
> >>>
> >>My idea was to catch the node.size overflow if the variable is
> >>inadvertently changed back to u32 (which has already happen in other
> >>places).
> >
> >Ok, that didn't come across when I just read node.size == 0 (what are
> >chances that node.size was exactly 2^32 and then truncated?)
> >
> Only a test explicitly looking for this kind of issues (I guess). In that
> test, objects bigger than 2^32 were truncated, while objects exactly 2^32
> were hitting a WARN in the driver; alloc_pages wouldn't do anything because
> node.size == 0, and then insert would complain no pages existed.
>
> >vma->node should be fairly opaque, and if possible we want the checks in
> >drm_mm.c - if we can think of good tests for that layer.
> >
> >Certainly drm_mm_reserve_node() probably wants a few sanity checks.
> >Though most of those should fall out when it can't do the reservation
> >the user requests.
> Or change drm_mm_insert_node_in_range_generic() to warn when size==0?
WARN_ON(vma->node.size != obj->base.size) ? Feel free to get the casting
right - I suck at implicit C integer conversion rules ...
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
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 1/7] drm/i915: Add origin to frontbuffer tracking flush
On Wed, Jul 08, 2015 at 10:41:58AM -0300, Paulo Zanoni wrote: > 2015-07-07 20:28 GMT-03:00 Rodrigo Vivi : > > This will be useful to PSR and FBC once we start making > > dirty fb calls to also flush frontbuffer. > > > > Cc: Daniel Vetter > > Cc: Paulo Zanoni > > Reviewed-by: Paulo Zanoni Queued for -next, thanks for the patch. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation 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 v4] drm/i915: Add soft-pinning API for execbuffer
On Wed, Jul 08, 2015 at 03:04:45PM +, Daniel, Thomas wrote: > > -Original Message- > > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] > > Sent: Saturday, July 4, 2015 1:24 PM > > To: Kristian Høgsberg > > Cc: Daniel, Thomas; Belgaumkar, Vinay; intel-gfx@lists.freedesktop.org; > > Michal > > Winiarsky; Goel, Akash > > Subject: Re: [Intel-gfx] [PATCH v4] drm/i915: Add soft-pinning API for > > execbuffer > > > > On Fri, Jul 03, 2015 at 10:29:44PM -0700, Kristian Høgsberg wrote: > > > On Tue, Jun 30, 2015 at 7:13 AM, Thomas Daniel > > wrote: > > > > From: Chris Wilson > > > > > > > > Userspace can pass in an offset that it presumes the object is located > > > > at. The kernel will then do its utmost to fit the object into that > > > > location. The assumption is that userspace is handling its own object > > > > locations (for example along with full-ppgtt) and that the kernel will > > > > rarely have to make space for the user's requests. > > > > > > > > Signed-off-by: Chris Wilson > > > > > > > > v2: Fixed incorrect eviction found by Michal Winiarski - fix suggested > > > > by Chris > > > > Wilson. Fixed incorrect error paths causing crash found by Michal > > > > Winiarski. > > > > (Not published externally) > > > > > > > > v3: Rebased because of trivial conflict in object_bind_to_vm. Fixed > > > > eviction > > > > to allow eviction of soft-pinned objects when another soft-pinned object > > used > > > > by a subsequent execbuffer overlaps reported by Michal Winiarski. > > > > (Not published externally) > > > > > > > > v4: Moved soft-pinned objects to the front of ordered_vmas so that they > > > > are > > > > pinned first after an address conflict happens to avoid repeated > > > > conflicts in > > > > rare cases (Suggested by Chris Wilson). Expanded comment on > > > > drm_i915_gem_exec_object2.offset to cover this new API. > > > > Note this patch is outdated compared to the one I have in my tree. There > > are also requirements to improve drm_mm_reserve_node(). > What requirements are these? I switched execbuffer to try reusing the last address by default (i.e. softpin everything) and the linear walk in reserve_node and evict_for_vma were major bottlenecks. Adding an interval-tree to drm_mm fixes the issue but also requires rewriting evict_for_vma. Plus using it by default highlighted a few errors in the failure handling. Also don't forget that softpinning requires us to be able to reuse the vm for all rings, i.e. we need the API fix to allow user contexts for rings other than RCS. -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: Don't clear all watermarks when updating.
Clearing the watermarks for all pipes/planes when updating the
watermarks for a single CRTC change seems like the wrong thing to
do here. As is, this code will update any pipe/plane watermarks
that need updating and leave the remaining set to zero. Later, the
watermark checks in check_wm_state() will flag these zero'd out pipe/plane
watermarks and throw errors.
By not clearing all pipe/plane watermark values, only those that
require changes are changed and the remaining stay unchanged.
Signed-off-by: Bob Paauwe
---
drivers/gpu/drm/i915/intel_pm.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index c2f8956..25fc319 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3734,8 +3734,6 @@ static void skl_update_wm(struct drm_crtc *crtc)
struct skl_pipe_wm pipe_wm = {};
struct intel_wm_config config = {};
- memset(results, 0, sizeof(*results));
-
skl_compute_wm_global_parameters(dev, &config);
if (!skl_update_pipe_wm(crtc, ¶ms, &config,
--
2.1.0
___
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: avoid leaking DMA mappings
We have 3 types of DMA mappings for GEM objects:
1. physically contiguous for stolen and for objects needing contiguous
memory
2. DMA-buf mappings imported via a DMA-buf attach operation
3. SG DMA mappings for shmem backed and userptr objects
For 1. and 2. the lifetime of the DMA mapping matches the lifetime of the
corresponding backing pages and so in practice we create/release the
mapping in the object's get_pages/put_pages callback.
For 3. the lifetime of the mapping matches that of any existing GPU binding
of the object, so we'll create the mapping when the object is bound to
the first vma and release the mapping when the object is unbound from its
last vma.
Since the object can be bound to multiple vmas, we can end up creating a
new DMA mapping in the 3. case even if the object already had one. This
is not allowed by the DMA API and can lead to leaked mapping data and
IOMMU memory space starvation in certain cases. For example HW IOMMU
drivers (intel_iommu) allocate a new range from their memory space
whenever a mapping is created, silently overriding a pre-existing
mapping.
Fix this by moving the creation/removal of DMA mappings to the object's
get_pages/put_pages callbacks. These callbacks already check for and do
an early return in case of any nested calls. This way objects of the 3.
case also become more like the other object types.
I noticed this issue by enabling DMA debugging, which got disabled after
a while due to its internal mapping tables getting full. It also reported
errors in connection to random other drivers that did a DMA mapping for
an address that was previously mapped by i915 but was never released.
Besides these diagnostic messages and the memory space starvation
problem for IOMMUs, I'm not aware of this causing a real issue.
The fix is based on a patch from Chris.
v2:
- move the DMA mapping create/remove calls to the get_pages/put_pages
callbacks instead of adding new callbacks for these (Chris)
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/i915_gem.c | 31 ---
drivers/gpu/drm/i915/i915_gem_userptr.c | 27 +--
2 files changed, 41 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 425ced6..aa71067 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2146,6 +2146,8 @@ i915_gem_object_put_pages_gtt(struct drm_i915_gem_object
*obj)
obj->base.read_domains = obj->base.write_domain =
I915_GEM_DOMAIN_CPU;
}
+ i915_gem_gtt_finish_object(obj);
+
if (i915_gem_object_needs_bit17_swizzle(obj))
i915_gem_object_save_bit_17_swizzle(obj);
@@ -2206,6 +2208,7 @@ i915_gem_object_get_pages_gtt(struct drm_i915_gem_object
*obj)
struct sg_page_iter sg_iter;
struct page *page;
unsigned long last_pfn = 0; /* suppress gcc warning */
+ int ret;
gfp_t gfp;
/* Assert that the object is not currently in any GPU domain. As it
@@ -2253,8 +2256,10 @@ i915_gem_object_get_pages_gtt(struct drm_i915_gem_object
*obj)
*/
i915_gem_shrink_all(dev_priv);
page = shmem_read_mapping_page(mapping, i);
- if (IS_ERR(page))
+ if (IS_ERR(page)) {
+ ret = PTR_ERR(page);
goto err_pages;
+ }
}
#ifdef CONFIG_SWIOTLB
if (swiotlb_nr_tbl()) {
@@ -2283,6 +2288,10 @@ i915_gem_object_get_pages_gtt(struct drm_i915_gem_object
*obj)
sg_mark_end(sg);
obj->pages = st;
+ ret = i915_gem_gtt_prepare_object(obj);
+ if (ret)
+ goto err_pages;
+
if (i915_gem_object_needs_bit17_swizzle(obj))
i915_gem_object_do_bit_17_swizzle(obj);
@@ -2307,10 +2316,10 @@ err_pages:
* space and so want to translate the error from shmemfs back to our
* usual understanding of ENOMEM.
*/
- if (PTR_ERR(page) == -ENOSPC)
- return -ENOMEM;
- else
- return PTR_ERR(page);
+ if (ret == -ENOSPC)
+ ret = -ENOMEM;
+
+ return ret;
}
/* Ensure that the associated pages are gathered from the backing storage
@@ -3288,10 +3297,8 @@ int i915_vma_unbind(struct i915_vma *vma)
/* Since the unbound list is global, only move to that list if
* no more VMAs exist. */
- if (list_empty(&obj->vma_list)) {
- i915_gem_gtt_finish_object(obj);
+ if (list_empty(&obj->vma_list))
list_move_tail(&obj->global_list, &dev_priv->mm.unbound_list);
- }
/* And finally now the object is completely decoupled from this vma,
* we can drop its hold on the backing storage and allow it to be
@@ -3819,22 +3826,16 @@ search_free:
[Intel-gfx] [PATCH 2/2] drm/i915: remove unused has_dma_mapping flag
After the previous patch this flag will check always clear, as it's
never set for shmem backed and userptr objects, so we can remove it.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/i915_drv.h| 2 --
drivers/gpu/drm/i915/i915_gem.c| 3 ---
drivers/gpu/drm/i915/i915_gem_dmabuf.c | 2 --
drivers/gpu/drm/i915/i915_gem_gtt.c| 9 ++---
drivers/gpu/drm/i915/i915_gem_stolen.c | 1 -
5 files changed, 2 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 093d642..152eedf 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2071,8 +2071,6 @@ struct drm_i915_gem_object {
unsigned int cache_level:3;
unsigned int cache_dirty:1;
- unsigned int has_dma_mapping:1;
-
unsigned int frontbuffer_bits:INTEL_FRONTBUFFER_BITS;
unsigned int pin_display;
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index aa71067..219d4d5 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -217,7 +217,6 @@ i915_gem_object_get_pages_phys(struct drm_i915_gem_object
*obj)
sg_dma_len(sg) = obj->base.size;
obj->pages = st;
- obj->has_dma_mapping = true;
return 0;
}
@@ -269,8 +268,6 @@ i915_gem_object_put_pages_phys(struct drm_i915_gem_object
*obj)
sg_free_table(obj->pages);
kfree(obj->pages);
-
- obj->has_dma_mapping = false;
}
static void
diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
index 7998da2..e9c2bfd 100644
--- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
@@ -256,7 +256,6 @@ static int i915_gem_object_get_pages_dmabuf(struct
drm_i915_gem_object *obj)
return PTR_ERR(sg);
obj->pages = sg;
- obj->has_dma_mapping = true;
return 0;
}
@@ -264,7 +263,6 @@ static void i915_gem_object_put_pages_dmabuf(struct
drm_i915_gem_object *obj)
{
dma_buf_unmap_attachment(obj->base.import_attach,
obj->pages, DMA_BIDIRECTIONAL);
- obj->has_dma_mapping = false;
}
static const struct drm_i915_gem_object_ops i915_gem_object_dmabuf_ops = {
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index b29b73f..44255a8 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -1802,9 +1802,6 @@ void i915_gem_suspend_gtt_mappings(struct drm_device *dev)
int i915_gem_gtt_prepare_object(struct drm_i915_gem_object *obj)
{
- if (obj->has_dma_mapping)
- return 0;
-
if (!dma_map_sg(&obj->base.dev->pdev->dev,
obj->pages->sgl, obj->pages->nents,
PCI_DMA_BIDIRECTIONAL))
@@ -2052,10 +2049,8 @@ void i915_gem_gtt_finish_object(struct
drm_i915_gem_object *obj)
interruptible = do_idling(dev_priv);
- if (!obj->has_dma_mapping)
- dma_unmap_sg(&dev->pdev->dev,
-obj->pages->sgl, obj->pages->nents,
-PCI_DMA_BIDIRECTIONAL);
+ dma_unmap_sg(&dev->pdev->dev, obj->pages->sgl, obj->pages->nents,
+PCI_DMA_BIDIRECTIONAL);
undo_idling(dev_priv, interruptible);
}
diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c
b/drivers/gpu/drm/i915/i915_gem_stolen.c
index de76d88..ed682a9 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -316,7 +316,6 @@ _i915_gem_object_create_stolen(struct drm_device *dev,
if (obj->pages == NULL)
goto cleanup;
- obj->has_dma_mapping = true;
i915_gem_object_pin_pages(obj);
obj->stolen = stolen;
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 02/20] drm: Don't update plane properties for atomic planes if it stays the same
Op 08-07-15 om 10:55 schreef Daniel Vetter:
> On Wed, Jul 08, 2015 at 10:00:22AM +0200, Maarten Lankhorst wrote:
>> Op 07-07-15 om 18:43 schreef Daniel Vetter:
>>> On Tue, Jul 07, 2015 at 05:08:34PM +0200, Maarten Lankhorst wrote:
Op 07-07-15 om 14:10 schreef Daniel Vetter:
> On Tue, Jul 07, 2015 at 12:20:10PM +0200, Maarten Lankhorst wrote:
>> Op 07-07-15 om 11:18 schreef Daniel Vetter:
>>> On Tue, Jul 07, 2015 at 09:08:13AM +0200, Maarten Lankhorst wrote:
This allows the first atomic call during hw init to be a real modeset,
which is useful for forcing a recalculation.
>>> fbcon is optional, you can't rely on anything being done in any specific
>>> way. What exactly do you need this for, what's the implications?
>> In the hw readout I noticed some warnings when I wasn't setting any mode
>> property in the readout.
>> I want the first function to be the modeset, so we have a sane base to
>> commit changes on.
>> Ideally this whole function would have a atomic counterpart which does
>> it in one go. :)
> Yeah. Otoh as soon as we have atomic modeset working we can replace all
> the legacy entry points with atomic helpers, and then even plane_disable
> will be a full atomic modeset.
>
> What did fall apart with just touching properties/planes now?
Also when i915 is fully atomic it calculates in
intel_modeset_compute_config
if a modeset is needed after the first atomic call. Right now because
intel_modeset_compute_config is only called in set_config so this works as
expected.
Otherwise drm_plane_force_disable or rotate_0 will force a modeset,
and if the final mode is different this will introduce a double modeset.
>>> For expensive properties (i.e. a no-op changes causes something that takes
>>> time like modeset or vblank wait) we need to make sure we filter them out
>>> in atomic_check. Yeah not quite there yet with pure atomic, but meanwhile
>>> the existing legacy set_prop functions should all filter out no-op changes
>>> themselves. If we don't do that for rotation then that's a bug.
>>>
>>> Same for disabling planes harder, that shouldn't take time. Especially
>>> since fbcon only force-disable non-primary plane, and for driver load
>>> that's the exact thing we already do in the driver anyway.
>> Something like this?
>> ---
>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
>> b/drivers/gpu/drm/drm_atomic_helper.c
>> index a1d4e13f3908..2989232f4996 100644
>> --- a/drivers/gpu/drm/drm_atomic_helper.c
>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
>> @@ -30,6 +30,7 @@
>> #include
>> #include
>> #include
>> +#include "drm_crtc_internal.h"
>> #include
>>
>> /**
>> @@ -1716,7 +1717,12 @@ drm_atomic_helper_crtc_set_property(struct drm_crtc
>> *crtc,
>> {
>> struct drm_atomic_state *state;
>> struct drm_crtc_state *crtc_state;
>> -int ret = 0;
>> +uint64_t retval;
>> +int ret;
>> +
>> +ret = drm_atomic_get_property(&crtc->base, property, &retval);
>> +if (!ret && val == retval)
>> +return 0;
>>
>> state = drm_atomic_state_alloc(crtc->dev);
>> if (!state)
>> @@ -1776,7 +1782,12 @@ drm_atomic_helper_plane_set_property(struct drm_plane
>> *plane,
>> {
>> struct drm_atomic_state *state;
>> struct drm_plane_state *plane_state;
>> -int ret = 0;
>> +uint64_t retval;
>> +int ret;
>> +
>> +ret = drm_atomic_get_property(&plane->base, property, &retval);
>> +if (!ret && val == retval)
>> +return 0;
>>
>> state = drm_atomic_state_alloc(plane->dev);
>> if (!state)
>> @@ -1836,7 +1847,12 @@ drm_atomic_helper_connector_set_property(struct
>> drm_connector *connector,
>> {
>> struct drm_atomic_state *state;
>> struct drm_connector_state *connector_state;
>> -int ret = 0;
>> +uint64_t retval;
>> +int ret;
>> +
>> +ret = drm_atomic_get_property(&connector->base, property, &retval);
>> +if (!ret && val == retval)
>> +return 0;
>>
>> state = drm_atomic_state_alloc(connector->dev);
>> if (!state)
> The reason I didn't do this is that a prop change might still result in no
> hw state change (e.g. if you go automitic->explicit setting matching
> automatic one). Hence I think we need to solve this in lower levels
> anyway, i.e. in when computing the config. But it shouldn't cause trouble
> yet.
Is that a ack or nack?
>> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
>> index 424c83323aaa..5bab7bff8a15 100644
>> --- a/drivers/gpu/drm/drm_crtc.c
>> +++ b/drivers/gpu/drm/drm_crtc.c
>> @@ -1327,7 +1327,8 @@ void drm_plane_force_disable(struct drm_plane *plane)
>> {
>> int ret;
>>
>> -if (!plane->fb)
>> +if ((plane->state && !plane->state->fb) ||
>> +(!plane->state && !plane->fb))
>> return;
> Nah, atomic helpers should figure this out imo. Since if userspace does
> the same (lo
Re: [Intel-gfx] [PATCH 6/7] drm/i915: Convert execlists_ctx_descriptor() for requests
On 07/03/2015 07:09 AM, Mika Kuoppala wrote:
Pass around requests to carry context deeper in callchain.
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_lrc.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index c3c029a..67ff460 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -261,10 +261,11 @@ u32 intel_execlists_ctx_id(struct drm_i915_gem_object
*ctx_obj)
return lrca >> 12;
}
-static uint64_t execlists_ctx_descriptor(struct intel_engine_cs *ring,
-struct drm_i915_gem_object *ctx_obj)
+static uint64_t execlists_ctx_descriptor(struct drm_i915_gem_request *rq)
{
GuC patch series tries to utilize this function. However, changing from
ring/context to request makes it unusable in the case where request is
not needed (not available). This context descriptor has nothing to do
with drm_i915_gem_request IMO. And it is waste of time to call it for
each batch submission. This value is fixed when context is pinned. Maybe
add a member ctx_desc into intel_context->engine; initialize the value
within intel_lr_context_pin; then use it whenever needed.
Thanks,
Alex
+ struct intel_engine_cs *ring = rq->ring;
struct drm_device *dev = ring->dev;
+ struct drm_i915_gem_object *ctx_obj = rq->ctx->engine[ring->id].state;
uint64_t desc;
uint64_t lrca = i915_gem_obj_ggtt_offset(ctx_obj);
@@ -299,21 +300,18 @@ static void execlists_elsp_write(struct drm_i915_gem_request *rq0,
struct intel_engine_cs *ring = rq0->ring;
struct drm_device *dev = ring->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
- struct drm_i915_gem_object *ctx_obj0 = rq0->ctx->engine[ring->id].state;
- struct drm_i915_gem_object *ctx_obj1 = rq1 ?
- rq1->ctx->engine[ring->id].state : NULL;
uint64_t temp = 0;
uint32_t desc[4];
/* XXX: You must always write both descriptors in the order below. */
- if (ctx_obj1)
- temp = execlists_ctx_descriptor(ring, ctx_obj1);
+ if (rq1)
+ temp = execlists_ctx_descriptor(rq1);
else
temp = 0;
desc[1] = (u32)(temp >> 32);
desc[0] = (u32)temp;
- temp = execlists_ctx_descriptor(ring, ctx_obj0);
+ temp = execlists_ctx_descriptor(rq0);
desc[3] = (u32)(temp >> 32);
desc[2] = (u32)temp;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 14/18] drm/i915: object size needs to be u64
On 7/8/2015 4:22 PM, Daniel Vetter wrote:
On Wed, Jul 08, 2015 at 12:22:58PM +0100, Michel Thierry wrote:
On 7/7/2015 9:08 PM, Chris Wilson wrote:
On Tue, Jul 07, 2015 at 04:44:30PM +0100, Michel Thierry wrote:
On 7/7/2015 4:27 PM, Chris Wilson wrote:
On Tue, Jul 07, 2015 at 04:14:59PM +0100, Michel Thierry wrote:
In a 48b world, users can try to allocate buffers bigger than 4GB; in
these cases it is important that size is a 64b variable.
Also added a warning for illegal bind with size = 0.
Signed-off-by: Michel Thierry
---
drivers/gpu/drm/i915/i915_gem.c | 5 +++--
drivers/gpu/drm/i915/i915_gem_gtt.c | 3 +++
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index a0bff41..ebfb789 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3718,7 +3718,8 @@ i915_gem_object_bind_to_vm(struct drm_i915_gem_object
*obj,
{
struct drm_device *dev = obj->base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
- u32 size, fence_size, fence_alignment, unfenced_alignment;
+ u32 fence_alignment, unfenced_alignment;
+ u64 size, fence_size;
u64 start =
flags & PIN_OFFSET_BIAS ? flags & PIN_OFFSET_MASK : 0;
u64 end =
@@ -3777,7 +3778,7 @@ i915_gem_object_bind_to_vm(struct drm_i915_gem_object
*obj,
* attempt to find space.
*/
if (size > end) {
- DRM_DEBUG("Attempting to bind an object (view type=%u) larger than the
aperture: size=%u > %s aperture=%llu\n",
+ DRM_DEBUG("Attempting to bind an object (view type=%u) larger than the
aperture: size=%llu > %s aperture=%llu\n",
ggtt_view ? ggtt_view->type : 0,
size,
flags & PIN_MAPPABLE ? "mappable" : "total",
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 449a245..900bce6 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -3312,6 +3312,9 @@ int i915_vma_bind(struct i915_vma *vma, enum
i915_cache_level cache_level,
if (WARN_ON(flags == 0))
return -EINVAL;
+ if (WARN_ON(vma->node.size == 0))
+ return -EINVAL;
This is superfluous. We don't allow size=0 object creation, and the test
is better (if at all) at vma_create, but what you mean here is
WARN_ON(!drm_mm_node_allocated()) which seems sensisble. And both of
these would be better as ENODEV so we don't confuse the user when they
get propagated back to userspace.
-Chris
My idea was to catch the node.size overflow if the variable is
inadvertently changed back to u32 (which has already happen in other
places).
Ok, that didn't come across when I just read node.size == 0 (what are
chances that node.size was exactly 2^32 and then truncated?)
Only a test explicitly looking for this kind of issues (I guess). In that
test, objects bigger than 2^32 were truncated, while objects exactly 2^32
were hitting a WARN in the driver; alloc_pages wouldn't do anything because
node.size == 0, and then insert would complain no pages existed.
vma->node should be fairly opaque, and if possible we want the checks in
drm_mm.c - if we can think of good tests for that layer.
Certainly drm_mm_reserve_node() probably wants a few sanity checks.
Though most of those should fall out when it can't do the reservation
the user requests.
Or change drm_mm_insert_node_in_range_generic() to warn when size==0?
WARN_ON(vma->node.size != obj->base.size) ? Feel free to get the casting
right - I suck at implicit C integer conversion rules ...
-Daniel
Thanks, if there's no objections, I'll change it to:
if (WARN_ON(vma->node.size != (u64)vma->obj->base.size))
return -ENODEV;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [drm-intel:drm-intel-next-queued 378/378] DockBook: Warning(drivers/gpu/drm/i915/intel_frontbuffer.c:146): No description found for parameter 'origin'
tree: git://anongit.freedesktop.org/drm-intel drm-intel-next-queued head: de152b627eb3018de91ec5c5a50b38e17d80a88b commit: de152b627eb3018de91ec5c5a50b38e17d80a88b [378/378] drm/i915: Add origin to frontbuffer tracking flush reproduce: make htmldocs All warnings (new ones prefixed by >>): Warning(include/drm/drm_crtc.h:1190): No description found for parameter 'dpms_property' Warning(include/drm/drm_crtc.h:1190): No description found for parameter 'path_property' Warning(include/drm/drm_crtc.h:1190): No description found for parameter 'tile_property' Warning(include/drm/drm_crtc.h:1190): No description found for parameter 'plane_type_property' Warning(include/drm/drm_crtc.h:1190): No description found for parameter 'rotation_property' Warning(include/drm/drm_crtc.h:1190): No description found for parameter 'prop_src_x' Warning(include/drm/drm_crtc.h:1190): No description found for parameter 'prop_src_y' Warning(include/drm/drm_crtc.h:1190): No description found for parameter 'prop_src_w' Warning(include/drm/drm_crtc.h:1190): No description found for parameter 'prop_src_h' Warning(include/drm/drm_crtc.h:1190): No description found for parameter 'prop_crtc_x' Warning(include/drm/drm_crtc.h:1190): No description found for parameter 'prop_crtc_y' Warning(include/drm/drm_crtc.h:1190): No description found for parameter 'prop_crtc_w' Warning(include/drm/drm_crtc.h:1190): No description found for parameter 'prop_crtc_h' Warning(include/drm/drm_crtc.h:1190): No description found for parameter 'prop_fb_id' Warning(include/drm/drm_crtc.h:1190): No description found for parameter 'prop_crtc_id' Warning(include/drm/drm_crtc.h:1190): No description found for parameter 'prop_active' Warning(include/drm/drm_crtc.h:1190): No description found for parameter 'prop_mode_id' Warning(include/drm/drm_crtc.h:1190): No description found for parameter 'dvi_i_subconnector_property' Warning(include/drm/drm_crtc.h:1190): No description found for parameter 'dvi_i_select_subconnector_property' Warning(include/drm/drm_crtc.h:1190): No description found for parameter 'tv_subconnector_property' Warning(include/drm/drm_crtc.h:1190): No description found for parameter 'tv_select_subconnector_property' Warning(include/drm/drm_crtc.h:1190): No description found for parameter 'tv_mode_property' Warning(include/drm/drm_crtc.h:1190): No description found for parameter 'tv_left_margin_property' Warning(include/drm/drm_crtc.h:1190): No description found for parameter 'tv_right_margin_property' Warning(include/drm/drm_crtc.h:1190): No description found for parameter 'tv_top_margin_property' Warning(include/drm/drm_crtc.h:1190): No description found for parameter 'tv_bottom_margin_property' Warning(include/drm/drm_crtc.h:1190): No description found for parameter 'tv_brightness_property' Warning(include/drm/drm_crtc.h:1190): No description found for parameter 'tv_contrast_property' Warning(include/drm/drm_crtc.h:1190): No description found for parameter 'tv_flicker_reduction_property' Warning(include/drm/drm_crtc.h:1190): No description found for parameter 'tv_overscan_property' Warning(include/drm/drm_crtc.h:1190): No description found for parameter 'tv_saturation_property' Warning(include/drm/drm_crtc.h:1190): No description found for parameter 'tv_hue_property' Warning(include/drm/drm_crtc.h:1190): No description found for parameter 'scaling_mode_property' Warning(include/drm/drm_crtc.h:1190): No description found for parameter 'aspect_ratio_property' Warning(include/drm/drm_crtc.h:1190): No description found for parameter 'dirty_info_property' Warning(include/drm/drm_crtc.h:1190): No description found for parameter 'suggested_x_property' Warning(include/drm/drm_crtc.h:1190): No description found for parameter 'suggested_y_property' Warning(include/drm/drm_crtc.h:1190): No description found for parameter 'allow_fb_modifiers' Warning(include/drm/drm_dp_helper.h:701): No description found for parameter 'i2c_nack_count' Warning(include/drm/drm_dp_helper.h:701): No description found for parameter 'i2c_defer_count' Warning(drivers/gpu/drm/drm_dp_mst_topology.c:2203): No description found for parameter 'connector' Warning(include/drm/drm_dp_mst_helper.h:97): No description found for parameter 'cached_edid' Warning(include/drm/drm_dp_mst_helper.h:466): No description found for parameter 'max_dpcd_transaction_bytes' Warning(include/drm/drm_dp_mst_helper.h:466): No description found for parameter 'sink_count' Warning(include/drm/drm_dp_mst_helper.h:466): No description found for parameter 'total_slots' Warning(include/drm/drm_dp_mst_helper.h:466): No description found for parameter 'avail_slots' Warning(include/drm/drm_dp_mst_helper.h:466): No description found for parameter 'total_pbn' Warning(include/drm/drm_dp_mst_helper.h:466): No description found for para
Re: [Intel-gfx] [PATCH v4 14/18] drm/i915: object size needs to be u64
On Wed, Jul 08, 2015 at 05:42:17PM +0100, Michel Thierry wrote: > >WARN_ON(vma->node.size != obj->base.size) ? Feel free to get the casting > >right - I suck at implicit C integer conversion rules ... > >-Daniel > > > Thanks, if there's no objections, I'll change it to: > > if (WARN_ON(vma->node.size != (u64)vma->obj->base.size)) > return -ENODEV; Are we still talking about i915_vma_bind()? Then vma->node.size != vma->obj.base.size anyway. -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 6/7] drm/i915: Convert execlists_ctx_descriptor() for requests
On 08/07/15 17:40, Yu Dai wrote:
On 07/03/2015 07:09 AM, Mika Kuoppala wrote:
Pass around requests to carry context deeper in callchain.
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_lrc.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c
b/drivers/gpu/drm/i915/intel_lrc.c
index c3c029a..67ff460 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -261,10 +261,11 @@ u32 intel_execlists_ctx_id(struct
drm_i915_gem_object *ctx_obj)
return lrca >> 12;
}
-static uint64_t execlists_ctx_descriptor(struct intel_engine_cs *ring,
- struct drm_i915_gem_object *ctx_obj)
+static uint64_t execlists_ctx_descriptor(struct drm_i915_gem_request
*rq)
{
GuC patch series tries to utilize this function. However, changing from
ring/context to request makes it unusable in the case where request is
not needed (not available). This context descriptor has nothing to do
with drm_i915_gem_request IMO. And it is waste of time to call it for
each batch submission. This value is fixed when context is pinned. Maybe
add a member ctx_desc into intel_context->engine; initialize the value
within intel_lr_context_pin; then use it whenever needed.
Thanks,
Alex
Yes, I've effectively reversed this in the next GuC submission series,
since we don't have a request during setup, and this function doesn't
actually need one either; it's only being used as a handle for
extracting the context and ring.
So in my version it will take an intel_context and a ring so it's up to
the caller to extract those from the drm_i915_gem_request (rq->ctx) and
(rq->ring) and pass them separately. Then the GuC can use it during
setup as well as at runtime :)
.Dave.
___
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: avoid leaking DMA mappings
On Wed, Jul 08, 2015 at 07:18:58PM +0300, Imre Deak wrote: > We have 3 types of DMA mappings for GEM objects: > 1. physically contiguous for stolen and for objects needing contiguous >memory > 2. DMA-buf mappings imported via a DMA-buf attach operation > 3. SG DMA mappings for shmem backed and userptr objects > > For 1. and 2. the lifetime of the DMA mapping matches the lifetime of the > corresponding backing pages and so in practice we create/release the > mapping in the object's get_pages/put_pages callback. > > For 3. the lifetime of the mapping matches that of any existing GPU binding > of the object, so we'll create the mapping when the object is bound to > the first vma and release the mapping when the object is unbound from its > last vma. > > Since the object can be bound to multiple vmas, we can end up creating a > new DMA mapping in the 3. case even if the object already had one. This > is not allowed by the DMA API and can lead to leaked mapping data and > IOMMU memory space starvation in certain cases. For example HW IOMMU > drivers (intel_iommu) allocate a new range from their memory space > whenever a mapping is created, silently overriding a pre-existing > mapping. > > Fix this by moving the creation/removal of DMA mappings to the object's > get_pages/put_pages callbacks. These callbacks already check for and do > an early return in case of any nested calls. This way objects of the 3. > case also become more like the other object types. > > I noticed this issue by enabling DMA debugging, which got disabled after > a while due to its internal mapping tables getting full. It also reported > errors in connection to random other drivers that did a DMA mapping for > an address that was previously mapped by i915 but was never released. > Besides these diagnostic messages and the memory space starvation > problem for IOMMUs, I'm not aware of this causing a real issue. > > The fix is based on a patch from Chris. You missed the bugfix from __i915_gem_object_init_pages() -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 v2] drm/i915: Don't forget to mark crtc as inactive after disable
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) Task id: 6751 -Summary- Platform Delta drm-intel-nightly Series Applied ILK 302/302 302/302 SNB 312/316 312/316 IVB 343/343 343/343 BYT -1 287/287 286/287 HSW 380/380 380/380 -Detailed- Platform Testdrm-intel-nightly Series Applied *BYT igt@gem_partial_pwrite_pread@reads-display PASS(1) FAIL(1) Note: You need to pay more attention to line start with '*' ___ 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: remove unused has_dma_mapping flag
On Wed, Jul 08, 2015 at 07:18:59PM +0300, Imre Deak wrote: > After the previous patch this flag will check always clear, as it's > never set for shmem backed and userptr objects, so we can remove it. > > Signed-off-by: Imre Deak Mentioned a trivial obj->get_page bugfix for __i915_gem_userptr_set_pages(), and then went on an archaelogical dig to understand why I didn't think of this earlier. Apparently, it just never occurred to me that I could remove this flag introduced for i915_gem_prime when we did the get_pages/put_pages support for it. Both patches (incl. the minor fix above for 1), Reviewed-by: Chris Wilson -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 v2 02/20] drm: Don't update plane properties for atomic planes if it stays the same
On Wed, Jul 08, 2015 at 06:35:47PM +0200, Maarten Lankhorst wrote:
> Op 08-07-15 om 10:55 schreef Daniel Vetter:
> > On Wed, Jul 08, 2015 at 10:00:22AM +0200, Maarten Lankhorst wrote:
> >> Op 07-07-15 om 18:43 schreef Daniel Vetter:
> >>> On Tue, Jul 07, 2015 at 05:08:34PM +0200, Maarten Lankhorst wrote:
> Op 07-07-15 om 14:10 schreef Daniel Vetter:
> > On Tue, Jul 07, 2015 at 12:20:10PM +0200, Maarten Lankhorst wrote:
> >> Op 07-07-15 om 11:18 schreef Daniel Vetter:
> >>> On Tue, Jul 07, 2015 at 09:08:13AM +0200, Maarten Lankhorst wrote:
> This allows the first atomic call during hw init to be a real
> modeset,
> which is useful for forcing a recalculation.
> >>> fbcon is optional, you can't rely on anything being done in any
> >>> specific
> >>> way. What exactly do you need this for, what's the implications?
> >> In the hw readout I noticed some warnings when I wasn't setting any
> >> mode property in the readout.
> >> I want the first function to be the modeset, so we have a sane base to
> >> commit changes on.
> >> Ideally this whole function would have a atomic counterpart which does
> >> it in one go. :)
> > Yeah. Otoh as soon as we have atomic modeset working we can replace all
> > the legacy entry points with atomic helpers, and then even plane_disable
> > will be a full atomic modeset.
> >
> > What did fall apart with just touching properties/planes now?
> Also when i915 is fully atomic it calculates in
> intel_modeset_compute_config
> if a modeset is needed after the first atomic call. Right now because
> intel_modeset_compute_config is only called in set_config so this works
> as expected.
> Otherwise drm_plane_force_disable or rotate_0 will force a modeset,
> and if the final mode is different this will introduce a double modeset.
> >>> For expensive properties (i.e. a no-op changes causes something that takes
> >>> time like modeset or vblank wait) we need to make sure we filter them out
> >>> in atomic_check. Yeah not quite there yet with pure atomic, but meanwhile
> >>> the existing legacy set_prop functions should all filter out no-op changes
> >>> themselves. If we don't do that for rotation then that's a bug.
> >>>
> >>> Same for disabling planes harder, that shouldn't take time. Especially
> >>> since fbcon only force-disable non-primary plane, and for driver load
> >>> that's the exact thing we already do in the driver anyway.
> >> Something like this?
> >> ---
> >> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> >> b/drivers/gpu/drm/drm_atomic_helper.c
> >> index a1d4e13f3908..2989232f4996 100644
> >> --- a/drivers/gpu/drm/drm_atomic_helper.c
> >> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> >> @@ -30,6 +30,7 @@
> >> #include
> >> #include
> >> #include
> >> +#include "drm_crtc_internal.h"
> >> #include
> >>
> >> /**
> >> @@ -1716,7 +1717,12 @@ drm_atomic_helper_crtc_set_property(struct drm_crtc
> >> *crtc,
> >> {
> >>struct drm_atomic_state *state;
> >>struct drm_crtc_state *crtc_state;
> >> - int ret = 0;
> >> + uint64_t retval;
> >> + int ret;
> >> +
> >> + ret = drm_atomic_get_property(&crtc->base, property, &retval);
> >> + if (!ret && val == retval)
> >> + return 0;
> >>
> >>state = drm_atomic_state_alloc(crtc->dev);
> >>if (!state)
> >> @@ -1776,7 +1782,12 @@ drm_atomic_helper_plane_set_property(struct
> >> drm_plane *plane,
> >> {
> >>struct drm_atomic_state *state;
> >>struct drm_plane_state *plane_state;
> >> - int ret = 0;
> >> + uint64_t retval;
> >> + int ret;
> >> +
> >> + ret = drm_atomic_get_property(&plane->base, property, &retval);
> >> + if (!ret && val == retval)
> >> + return 0;
> >>
> >>state = drm_atomic_state_alloc(plane->dev);
> >>if (!state)
> >> @@ -1836,7 +1847,12 @@ drm_atomic_helper_connector_set_property(struct
> >> drm_connector *connector,
> >> {
> >>struct drm_atomic_state *state;
> >>struct drm_connector_state *connector_state;
> >> - int ret = 0;
> >> + uint64_t retval;
> >> + int ret;
> >> +
> >> + ret = drm_atomic_get_property(&connector->base, property, &retval);
> >> + if (!ret && val == retval)
> >> + return 0;
> >>
> >>state = drm_atomic_state_alloc(connector->dev);
> >>if (!state)
> > The reason I didn't do this is that a prop change might still result in no
> > hw state change (e.g. if you go automitic->explicit setting matching
> > automatic one). Hence I think we need to solve this in lower levels
> > anyway, i.e. in when computing the config. But it shouldn't cause trouble
> > yet.
> Is that a ack or nack?
I think we shouldn't need this really for i915, and it might cover up
bugs. I prefer we just do the evade modeset logic you've implemented once
we switch over to atomic props. Since atm we only have atomic props which
get updated in pageflips we shouldn't have serious problems here
Re: [Intel-gfx] [PATCH 6/7] drm/i915: Convert execlists_ctx_descriptor() for requests
On Wed Jul 08 2015 at 18:04:44 +0100, Dave Gordon wrote:
> On 08/07/15 17:40, Yu Dai wrote:
> >On 07/03/2015 07:09 AM, Mika Kuoppala wrote:
> >>Pass around requests to carry context deeper in callchain.
> >>
> >>Signed-off-by: Mika Kuoppala
> >>---
> >> drivers/gpu/drm/i915/intel_lrc.c | 14 ++
> >> 1 file changed, 6 insertions(+), 8 deletions(-)
> >>
> >>diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> >>b/drivers/gpu/drm/i915/intel_lrc.c
> >>index c3c029a..67ff460 100644
> >>--- a/drivers/gpu/drm/i915/intel_lrc.c
> >>+++ b/drivers/gpu/drm/i915/intel_lrc.c
> >>@@ -261,10 +261,11 @@ u32 intel_execlists_ctx_id(struct
> >>drm_i915_gem_object *ctx_obj)
> >> return lrca >> 12;
> >> }
> >>-static uint64_t execlists_ctx_descriptor(struct intel_engine_cs *ring,
> >>- struct drm_i915_gem_object *ctx_obj)
> >>+static uint64_t execlists_ctx_descriptor(struct drm_i915_gem_request
> >>*rq)
> >> {
> >
> >GuC patch series tries to utilize this function. However, changing from
> >ring/context to request makes it unusable in the case where request is
> >not needed (not available). This context descriptor has nothing to do
> >with drm_i915_gem_request IMO. And it is waste of time to call it for
> >each batch submission. This value is fixed when context is pinned. Maybe
> >add a member ctx_desc into intel_context->engine; initialize the value
> >within intel_lr_context_pin; then use it whenever needed.
> >
> >Thanks,
> >Alex
>
> Yes, I've effectively reversed this in the next GuC submission
> series, since we don't have a request during setup, and this
> function doesn't actually need one either; it's only being used as a
> handle for extracting the context and ring.
>
> So in my version it will take an intel_context and a ring so it's up
> to the caller to extract those from the drm_i915_gem_request
> (rq->ctx) and (rq->ring) and pass them separately. Then the GuC can
> use it during setup as well as at runtime :)
>
I admit I went one step too far on this one in the series. The bspec says
the context ids created should be unique across all engines and all execlists.
I was concerned that our lrca only setup and resubmission for
pre-emption would break this rule. (and be the reason for skl hickups)
The bspec has a note about creating context id with ring/counter(seqno)/lrca
combination. Thus the request -> descriptor creation.
I didn't post that patch as it didn't cure the skl hang. But it made
debugging the context status queue easier as seqnos were part of
context_id.
-Mika
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/7] drm/i915: fbdev restore mode needs to invalidate frontbuffer
2015-07-07 20:28 GMT-03:00 Rodrigo Vivi :
> This fbdev restore mode was another corner case that was now
> calling frontbuffer flip and flush and making we miss
> screen updates with PSR enabled.
>
> So let's also add the invalidate hack here while we don't have
> a reliable dirty fbdev op.
So when I saw patches 6 and 7 I decided to investigate how fbcon
interacts with frontbuffer tracking. One thing that I notice is that,
without this patch, if I kill the display manager, I'll have a bunch
of flushes without an invalidate when returning to fbcon. And I
suppose we don't want PSR/FBC enabled on fbcon, so this patch seems to
fix a bug.
By the way, I think we can try to simulate this "kill display manager"
bug on IGT. We could try to close the DRM device and then check if
FBC/PSR stopped. I guess it's probably easier to create a new IGT test
for that.
More below.
>
> Signed-off-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/intel_fbdev.c | 11 +--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
> b/drivers/gpu/drm/i915/intel_fbdev.c
> index a76cebc..ae9b809 100644
> --- a/drivers/gpu/drm/i915/intel_fbdev.c
> +++ b/drivers/gpu/drm/i915/intel_fbdev.c
> @@ -831,11 +831,18 @@ void intel_fbdev_restore_mode(struct drm_device *dev)
> {
> int ret;
> struct drm_i915_private *dev_priv = dev->dev_private;
> + struct intel_fbdev *ifbdev = dev_priv->fbdev;
> + struct drm_fb_helper *fb_helper = &ifbdev->helper;
Can't this ifbdev->helper assignment segfault? Shouldn't we assign
this pointer just after the !ifbdev check below?
>
> - if (!dev_priv->fbdev)
> + if (!ifbdev)
> return;
>
> - ret =
> drm_fb_helper_restore_fbdev_mode_unlocked(&dev_priv->fbdev->helper);
> + ret = drm_fb_helper_restore_fbdev_mode_unlocked(&ifbdev->helper);
You could have used fb_helper here :)
> if (ret)
> DRM_DEBUG("failed to restore crtc mode\n");
My OCD tells me to request you to add the brackets on the "if" too.
Documentation/CodingStyle:168
> + else {
> + mutex_lock(&fb_helper->dev->struct_mutex);
> + intel_fb_obj_invalidate(ifbdev->fb->obj, ORIGIN_GTT);
> + mutex_unlock(&fb_helper->dev->struct_mutex);
> + }
> }
> --
> 2.1.0
>
> ___
> 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 v2 02/20] drm: Don't update plane properties for atomic planes if it stays the same
Op 08-07-15 om 19:52 schreef Daniel Vetter:
> On Wed, Jul 08, 2015 at 06:35:47PM +0200, Maarten Lankhorst wrote:
>> Op 08-07-15 om 10:55 schreef Daniel Vetter:
>>> On Wed, Jul 08, 2015 at 10:00:22AM +0200, Maarten Lankhorst wrote:
Op 07-07-15 om 18:43 schreef Daniel Vetter:
> On Tue, Jul 07, 2015 at 05:08:34PM +0200, Maarten Lankhorst wrote:
>> Op 07-07-15 om 14:10 schreef Daniel Vetter:
>>> On Tue, Jul 07, 2015 at 12:20:10PM +0200, Maarten Lankhorst wrote:
Op 07-07-15 om 11:18 schreef Daniel Vetter:
> On Tue, Jul 07, 2015 at 09:08:13AM +0200, Maarten Lankhorst wrote:
>> This allows the first atomic call during hw init to be a real
>> modeset,
>> which is useful for forcing a recalculation.
> fbcon is optional, you can't rely on anything being done in any
> specific
> way. What exactly do you need this for, what's the implications?
In the hw readout I noticed some warnings when I wasn't setting any
mode property in the readout.
I want the first function to be the modeset, so we have a sane base to
commit changes on.
Ideally this whole function would have a atomic counterpart which does
it in one go. :)
>>> Yeah. Otoh as soon as we have atomic modeset working we can replace all
>>> the legacy entry points with atomic helpers, and then even plane_disable
>>> will be a full atomic modeset.
>>>
>>> What did fall apart with just touching properties/planes now?
>> Also when i915 is fully atomic it calculates in
>> intel_modeset_compute_config
>> if a modeset is needed after the first atomic call. Right now because
>> intel_modeset_compute_config is only called in set_config so this works
>> as expected.
>> Otherwise drm_plane_force_disable or rotate_0 will force a modeset,
>> and if the final mode is different this will introduce a double modeset.
> For expensive properties (i.e. a no-op changes causes something that takes
> time like modeset or vblank wait) we need to make sure we filter them out
> in atomic_check. Yeah not quite there yet with pure atomic, but meanwhile
> the existing legacy set_prop functions should all filter out no-op changes
> themselves. If we don't do that for rotation then that's a bug.
>
> Same for disabling planes harder, that shouldn't take time. Especially
> since fbcon only force-disable non-primary plane, and for driver load
> that's the exact thing we already do in the driver anyway.
Something like this?
---
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index a1d4e13f3908..2989232f4996 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -30,6 +30,7 @@
#include
#include
#include
+#include "drm_crtc_internal.h"
#include
/**
@@ -1716,7 +1717,12 @@ drm_atomic_helper_crtc_set_property(struct drm_crtc
*crtc,
{
struct drm_atomic_state *state;
struct drm_crtc_state *crtc_state;
- int ret = 0;
+ uint64_t retval;
+ int ret;
+
+ ret = drm_atomic_get_property(&crtc->base, property, &retval);
+ if (!ret && val == retval)
+ return 0;
state = drm_atomic_state_alloc(crtc->dev);
if (!state)
@@ -1776,7 +1782,12 @@ drm_atomic_helper_plane_set_property(struct
drm_plane *plane,
{
struct drm_atomic_state *state;
struct drm_plane_state *plane_state;
- int ret = 0;
+ uint64_t retval;
+ int ret;
+
+ ret = drm_atomic_get_property(&plane->base, property, &retval);
+ if (!ret && val == retval)
+ return 0;
state = drm_atomic_state_alloc(plane->dev);
if (!state)
@@ -1836,7 +1847,12 @@ drm_atomic_helper_connector_set_property(struct
drm_connector *connector,
{
struct drm_atomic_state *state;
struct drm_connector_state *connector_state;
- int ret = 0;
+ uint64_t retval;
+ int ret;
+
+ ret = drm_atomic_get_property(&connector->base, property, &retval);
+ if (!ret && val == retval)
+ return 0;
state = drm_atomic_state_alloc(connector->dev);
if (!state)
>>> The reason I didn't do this is that a prop change might still result in no
>>> hw state change (e.g. if you go automitic->explicit setting matching
>>> automatic one). Hence I think we need to solve this in lower levels
>>> anyway, i.e. in when computing the config. But it shouldn't cause trouble
>>> yet.
>> Is that a ack or nack?
> I think we shouldn't need this really for i915, and it might cover up
> bugs. I prefer we just do the evade modeset logic you've implemented once
> we switch over to atomic props. Since atm we only have atomic props which
> get update
Re: [Intel-gfx] [PATCH 6/6] drm/i915/gen9: Corrected the sanity check of mmio address range for csr.
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) Task id: 6752 -Summary- Platform Delta drm-intel-nightly Series Applied ILK 302/302 302/302 SNB 312/316 312/316 IVB 343/343 343/343 BYT -2 287/287 285/287 HSW 380/380 380/380 -Detailed- Platform Testdrm-intel-nightly Series Applied *BYT igt@gem_partial_pwrite_pread@reads-display PASS(1) FAIL(1) *BYT igt@gem_tiled_partial_pwrite_pread@reads PASS(1) FAIL(1) Note: You need to pay more attention to line start with '*' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 02/20] drm: Don't update plane properties for atomic planes if it stays the same
On Wed, Jul 08, 2015 at 08:25:07PM +0200, Maarten Lankhorst wrote:
> Op 08-07-15 om 19:52 schreef Daniel Vetter:
> > On Wed, Jul 08, 2015 at 06:35:47PM +0200, Maarten Lankhorst wrote:
> >> Op 08-07-15 om 10:55 schreef Daniel Vetter:
> >>> On Wed, Jul 08, 2015 at 10:00:22AM +0200, Maarten Lankhorst wrote:
> Op 07-07-15 om 18:43 schreef Daniel Vetter:
> > On Tue, Jul 07, 2015 at 05:08:34PM +0200, Maarten Lankhorst wrote:
> >> Op 07-07-15 om 14:10 schreef Daniel Vetter:
> >>> On Tue, Jul 07, 2015 at 12:20:10PM +0200, Maarten Lankhorst wrote:
> Op 07-07-15 om 11:18 schreef Daniel Vetter:
> > On Tue, Jul 07, 2015 at 09:08:13AM +0200, Maarten Lankhorst wrote:
> >> This allows the first atomic call during hw init to be a real
> >> modeset,
> >> which is useful for forcing a recalculation.
> > fbcon is optional, you can't rely on anything being done in any
> > specific
> > way. What exactly do you need this for, what's the implications?
> In the hw readout I noticed some warnings when I wasn't setting any
> mode property in the readout.
> I want the first function to be the modeset, so we have a sane base
> to commit changes on.
> Ideally this whole function would have a atomic counterpart which
> does it in one go. :)
> >>> Yeah. Otoh as soon as we have atomic modeset working we can replace
> >>> all
> >>> the legacy entry points with atomic helpers, and then even
> >>> plane_disable
> >>> will be a full atomic modeset.
> >>>
> >>> What did fall apart with just touching properties/planes now?
> >> Also when i915 is fully atomic it calculates in
> >> intel_modeset_compute_config
> >> if a modeset is needed after the first atomic call. Right now because
> >> intel_modeset_compute_config is only called in set_config so this
> >> works as expected.
> >> Otherwise drm_plane_force_disable or rotate_0 will force a modeset,
> >> and if the final mode is different this will introduce a double
> >> modeset.
> > For expensive properties (i.e. a no-op changes causes something that
> > takes
> > time like modeset or vblank wait) we need to make sure we filter them
> > out
> > in atomic_check. Yeah not quite there yet with pure atomic, but
> > meanwhile
> > the existing legacy set_prop functions should all filter out no-op
> > changes
> > themselves. If we don't do that for rotation then that's a bug.
> >
> > Same for disabling planes harder, that shouldn't take time. Especially
> > since fbcon only force-disable non-primary plane, and for driver load
> > that's the exact thing we already do in the driver anyway.
> Something like this?
> ---
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index a1d4e13f3908..2989232f4996 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -30,6 +30,7 @@
> #include
> #include
> #include
> +#include "drm_crtc_internal.h"
> #include
>
> /**
> @@ -1716,7 +1717,12 @@ drm_atomic_helper_crtc_set_property(struct
> drm_crtc *crtc,
> {
> struct drm_atomic_state *state;
> struct drm_crtc_state *crtc_state;
> -int ret = 0;
> +uint64_t retval;
> +int ret;
> +
> +ret = drm_atomic_get_property(&crtc->base, property, &retval);
> +if (!ret && val == retval)
> +return 0;
>
> state = drm_atomic_state_alloc(crtc->dev);
> if (!state)
> @@ -1776,7 +1782,12 @@ drm_atomic_helper_plane_set_property(struct
> drm_plane *plane,
> {
> struct drm_atomic_state *state;
> struct drm_plane_state *plane_state;
> -int ret = 0;
> +uint64_t retval;
> +int ret;
> +
> +ret = drm_atomic_get_property(&plane->base, property, &retval);
> +if (!ret && val == retval)
> +return 0;
>
> state = drm_atomic_state_alloc(plane->dev);
> if (!state)
> @@ -1836,7 +1847,12 @@ drm_atomic_helper_connector_set_property(struct
> drm_connector *connector,
> {
> struct drm_atomic_state *state;
> struct drm_connector_state *connector_state;
> -int ret = 0;
> +uint64_t retval;
> +int ret;
> +
> +ret = drm_atomic_get_property(&connector->base, property,
> &retval);
> +if (!ret && val == retval)
> +return 0;
>
> state = drm_atomic_state_alloc(connector->dev);
> if (!state)
> >>> The reason I didn't do this is that a
[Intel-gfx] [PATCH 05/15] drm/i915: Add locking around chv_phy_control_init()
From: Ville Syrjälä
dev_priv->chv_phy_control is protected by the power_domains->lock
elsewhere, so also grab it when initializing chv_phy_control.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_runtime_pm.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 2142ae6..dab1da9 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -1678,7 +1678,9 @@ void intel_power_domains_init_hw(struct drm_i915_private
*dev_priv)
power_domains->initializing = true;
if (IS_CHERRYVIEW(dev)) {
+ mutex_lock(&power_domains->lock);
chv_phy_control_init(dev_priv);
+ mutex_unlock(&power_domains->lock);
} else if (IS_VALLEYVIEW(dev)) {
mutex_lock(&power_domains->lock);
vlv_cmnlane_wa(dev_priv);
--
2.3.6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 11/15] drm/i915: Enable DPIO SUS clock gating on CHV
From: Ville Syrjälä
CHV has supports some form of automagic clock gating for the
DPIO SUS clock. We can simply enable the magic bits and the
hardware should take care of the rest.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 4
drivers/gpu/drm/i915/intel_runtime_pm.c | 3 ++-
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index bcfcbb62..8010200 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1133,6 +1133,10 @@ enum skl_disp_power_wells {
#define CHV_CMN_DW28 0x8170
#define DPIO_CL1POWERDOWNEN (1 << 23)
#define DPIO_DYNPWRDOWNEN_CH0(1 << 22)
+#define DPIO_SUS_CLK_CONFIG_ON (0 << 0)
+#define DPIO_SUS_CLK_CONFIG_CLKREQ (1 << 0)
+#define DPIO_SUS_CLK_CONFIG_GATE (2 << 0)
+#define DPIO_SUS_CLK_CONFIG_GATE_CLKREQ (3 << 0)
#define CHV_CMN_DW30 0x8178
#define DPIO_LRC_BYPASS (1 << 3)
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 551cf08..37e4375 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -972,7 +972,8 @@ static void chv_dpio_cmn_power_well_enable(struct
drm_i915_private *dev_priv,
/* Enable dynamic power down */
tmp = vlv_dpio_read(dev_priv, pipe, CHV_CMN_DW28);
- tmp |= DPIO_DYNPWRDOWNEN_CH0 | DPIO_CL1POWERDOWNEN;
+ tmp |= DPIO_DYNPWRDOWNEN_CH0 | DPIO_CL1POWERDOWNEN |
+ DPIO_SUS_CLK_CONFIG_GATE_CLKREQ;
vlv_dpio_write(dev_priv, pipe, CHV_CMN_DW28, tmp);
if (power_well->data == PUNIT_POWER_WELL_DPIO_CMN_BC) {
--
2.3.6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 04/15] drm/i915: Move DPIO port init earlier
From: Ville Syrjälä
To implement DPIO lane power gating on CHV we're going to need to access
DPIO registers from the cmn power well enable hook. That gets called
rather early, so we need to move the DPIO port IOSF sideband port
assignment earlier as well.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_dma.c | 20
drivers/gpu/drm/i915/intel_display.c | 22 --
2 files changed, 20 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 5e63076..3e9e98a 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -783,6 +783,24 @@ static void intel_device_info_runtime_init(struct
drm_device *dev)
info->has_eu_pg ? "y" : "n");
}
+static void intel_init_dpio(struct drm_i915_private *dev_priv)
+{
+ if (!IS_VALLEYVIEW(dev_priv))
+ return;
+
+ /*
+* IOSF_PORT_DPIO is used for VLV x2 PHY (DP/HDMI B and C),
+* CHV x1 PHY (DP/HDMI D)
+* IOSF_PORT_DPIO_2 is used for CHV x2 PHY (DP/HDMI B and C)
+*/
+ if (IS_CHERRYVIEW(dev_priv)) {
+ DPIO_PHY_IOSF_PORT(DPIO_PHY0) = IOSF_PORT_DPIO_2;
+ DPIO_PHY_IOSF_PORT(DPIO_PHY1) = IOSF_PORT_DPIO;
+ } else {
+ DPIO_PHY_IOSF_PORT(DPIO_PHY0) = IOSF_PORT_DPIO;
+ }
+}
+
/**
* i915_driver_load - setup chip and create an initial config
* @dev: DRM device
@@ -983,6 +1001,8 @@ int i915_driver_load(struct drm_device *dev, unsigned long
flags)
intel_device_info_runtime_init(dev);
+ intel_init_dpio(dev_priv);
+
if (INTEL_INFO(dev)->num_pipes) {
ret = drm_vblank_init(dev, INTEL_INFO(dev)->num_pipes);
if (ret)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index db518a7..0473b38 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1590,26 +1590,6 @@ static void assert_pch_ports_disabled(struct
drm_i915_private *dev_priv,
assert_pch_hdmi_disabled(dev_priv, pipe, PCH_HDMID);
}
-static void intel_init_dpio(struct drm_device *dev)
-{
- struct drm_i915_private *dev_priv = dev->dev_private;
-
- if (!IS_VALLEYVIEW(dev))
- return;
-
- /*
-* IOSF_PORT_DPIO is used for VLV x2 PHY (DP/HDMI B and C),
-* CHV x1 PHY (DP/HDMI D)
-* IOSF_PORT_DPIO_2 is used for CHV x2 PHY (DP/HDMI B and C)
-*/
- if (IS_CHERRYVIEW(dev)) {
- DPIO_PHY_IOSF_PORT(DPIO_PHY0) = IOSF_PORT_DPIO_2;
- DPIO_PHY_IOSF_PORT(DPIO_PHY1) = IOSF_PORT_DPIO;
- } else {
- DPIO_PHY_IOSF_PORT(DPIO_PHY0) = IOSF_PORT_DPIO;
- }
-}
-
static void vlv_enable_pll(struct intel_crtc *crtc,
const struct intel_crtc_state *pipe_config)
{
@@ -15049,8 +15029,6 @@ void intel_modeset_init(struct drm_device *dev)
}
}
- intel_init_dpio(dev);
-
intel_shared_dpll_init(dev);
/* Just disable it once at startup */
--
2.3.6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 06/15] drm/i915: Move VLV/CHV prepare_pll later
From: Ville Syrjälä
With DPIO powergating active on CHV, we can't even access the DPIO PLL
registers until the lane power state overrides have been enabled. That
will happen from the encoder .pre_pll_enable() hook, so move
chv_prepare_pll() to happen after that point, which puts it just before
chv_enable_pll() actually.
Do the same for VLV to avoid accumulating weird differences between the
platforms. Both platforms seem happy with the new arrangement.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 14 +-
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 0473b38..666a236 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5979,13 +5979,6 @@ static void valleyview_crtc_enable(struct drm_crtc *crtc)
is_dsi = intel_pipe_has_type(intel_crtc, INTEL_OUTPUT_DSI);
- if (!is_dsi) {
- if (IS_CHERRYVIEW(dev))
- chv_prepare_pll(intel_crtc, intel_crtc->config);
- else
- vlv_prepare_pll(intel_crtc, intel_crtc->config);
- }
-
if (intel_crtc->config->has_dp_encoder)
intel_dp_set_m_n(intel_crtc, M1_N1);
@@ -6009,10 +6002,13 @@ static void valleyview_crtc_enable(struct drm_crtc
*crtc)
encoder->pre_pll_enable(encoder);
if (!is_dsi) {
- if (IS_CHERRYVIEW(dev))
+ if (IS_CHERRYVIEW(dev)) {
+ chv_prepare_pll(intel_crtc, intel_crtc->config);
chv_enable_pll(intel_crtc, intel_crtc->config);
- else
+ } else {
+ vlv_prepare_pll(intel_crtc, intel_crtc->config);
vlv_enable_pll(intel_crtc, intel_crtc->config);
+ }
}
for_each_encoder_on_crtc(dev, crtc, encoder)
--
2.3.6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 00/15] drm/i915: CHV DPIO power gating, take two
From: Ville Syrjälä Here's the new version of the CHV DPIO powergating feature. In short, it allows us to power off unused lanes in the display PHY. So should save some power when stuff is either disabled, or when running DP links with less than four lanes. My previous attempt [1] failed to actually enable the dynamic powerdown bits in the PHY, which meant it basically did nothing. Actually setting those bits has a pretty big effect on the hardware as CMN/TX/PCS registers stop working in powered down lanes. So dealing with that fact, and several nasty corner cases makes things a bit tricky in places. The series depends on my earlier DP pipe config cleanup [2] since we now depend on knowing which lanes are actually powered on when enabling/disabling DP ports. The entire thing is availabe from my github repo [3] where it's sitting on a few other patches, including my earlier DPLL cleanup series [4]. However there should be no real dependency on this other stuff apart from the already mentioned DP pipe config patches (which are also included in the branch). Deepak, perchance you would be willing to review this since you already reviwed my first attempt (and shot it full of holes)? Oh, and the first two patches aren't really about DPIO powergating. But I wanted to get them out and one of them does touch the same code so I figured I'd sneak them in. [1] http://lists.freedesktop.org/archives/intel-gfx/2015-April/064403.html [2] http://lists.freedesktop.org/archives/intel-gfx/2015-July/070780.html [3] git://github.com/vsyrjala/linux.git chv_dpio_powergating_4 [4] http://lists.freedesktop.org/archives/intel-gfx/2015-June/070036.html Ville Syrjälä (15): drm/i915: Always program m2 fractional value on CHV drm/i915: Always program unique transition scale for CHV drm/i915: Add encoder->post_pll_disable() hooks and move CHV clock buffer disables there drm/i915: Move DPIO port init earlier drm/i915: Add locking around chv_phy_control_init() drm/i915: Move VLV/CHV prepare_pll later drm/i915: Add vlv_dport_to_phy() drm/i915: Implement PHY lane power gating for CHV drm/i915: Trick CL2 into life on CHV when using pipe B with port B drm/i915: Force common lane on for the PPS kick on CHV drm/i915: Enable DPIO SUS clock gating on CHV drm/i915: Force CL2 off in CHV x1 PHY drm/i915: Clean up CHV lane soft reset programming drm/i915: Add some CHV DPIO lane power state asserts drm/i915: Add CHV PHY LDO power sanity checks drivers/gpu/drm/i915/i915_dma.c | 20 ++ drivers/gpu/drm/i915/i915_reg.h | 23 +++ drivers/gpu/drm/i915/intel_display.c| 54 + drivers/gpu/drm/i915/intel_dp.c | 315 +++-- drivers/gpu/drm/i915/intel_drv.h| 26 ++- drivers/gpu/drm/i915/intel_hdmi.c | 171 +++- drivers/gpu/drm/i915/intel_runtime_pm.c | 344 +--- 7 files changed, 721 insertions(+), 232 deletions(-) -- 2.3.6 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 03/15] drm/i915: Add encoder->post_pll_disable() hooks and move CHV clock buffer disables there
From: Ville Syrjälä
Move the CHV clock buffer disable from chv_disable_pll() to the new
encoder .post_pll_disable() hook. This is more symmetric since the
clock buffer enable happens from the .pre_pll_enable() hook.
We'll have more use for the new hook soon.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 15 ---
drivers/gpu/drm/i915/intel_dp.c | 23 +++
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_hdmi.c| 23 +++
4 files changed, 51 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 3df9cb2..db518a7 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1851,17 +1851,6 @@ static void chv_disable_pll(struct drm_i915_private
*dev_priv, enum pipe pipe)
val &= ~DPIO_DCLKP_EN;
vlv_dpio_write(dev_priv, pipe, CHV_CMN_DW14(port), val);
- /* disable left/right clock distribution */
- if (pipe != PIPE_B) {
- val = vlv_dpio_read(dev_priv, pipe, _CHV_CMN_DW5_CH0);
- val &= ~(CHV_BUFLEFTENA1_MASK | CHV_BUFRIGHTENA1_MASK);
- vlv_dpio_write(dev_priv, pipe, _CHV_CMN_DW5_CH0, val);
- } else {
- val = vlv_dpio_read(dev_priv, pipe, _CHV_CMN_DW1_CH1);
- val &= ~(CHV_BUFLEFTENA2_MASK | CHV_BUFRIGHTENA2_MASK);
- vlv_dpio_write(dev_priv, pipe, _CHV_CMN_DW1_CH1, val);
- }
-
mutex_unlock(&dev_priv->sb_lock);
}
@@ -6171,6 +6160,10 @@ static void i9xx_crtc_disable(struct drm_crtc *crtc)
i9xx_disable_pll(intel_crtc);
}
+ for_each_encoder_on_crtc(dev, crtc, encoder)
+ if (encoder->post_pll_disable)
+ encoder->post_pll_disable(encoder);
+
if (!IS_GEN2(dev))
intel_set_cpu_fifo_underrun_reporting(dev_priv, pipe, false);
}
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 32d7e43..40b8430 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2906,6 +2906,28 @@ static void chv_dp_pre_pll_enable(struct intel_encoder
*encoder)
mutex_unlock(&dev_priv->sb_lock);
}
+static void chv_dp_post_pll_disable(struct intel_encoder *encoder)
+{
+ struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+ enum pipe pipe = to_intel_crtc(encoder->base.crtc)->pipe;
+ u32 val;
+
+ mutex_lock(&dev_priv->sb_lock);
+
+ /* disable left/right clock distribution */
+ if (pipe != PIPE_B) {
+ val = vlv_dpio_read(dev_priv, pipe, _CHV_CMN_DW5_CH0);
+ val &= ~(CHV_BUFLEFTENA1_MASK | CHV_BUFRIGHTENA1_MASK);
+ vlv_dpio_write(dev_priv, pipe, _CHV_CMN_DW5_CH0, val);
+ } else {
+ val = vlv_dpio_read(dev_priv, pipe, _CHV_CMN_DW1_CH1);
+ val &= ~(CHV_BUFLEFTENA2_MASK | CHV_BUFRIGHTENA2_MASK);
+ vlv_dpio_write(dev_priv, pipe, _CHV_CMN_DW1_CH1, val);
+ }
+
+ mutex_unlock(&dev_priv->sb_lock);
+}
+
/*
* Native read with retry for link status and receiver capability reads for
* cases where the sink may still be asleep.
@@ -5931,6 +5953,7 @@ intel_dp_init(struct drm_device *dev, int output_reg,
enum port port)
intel_encoder->pre_enable = chv_pre_enable_dp;
intel_encoder->enable = vlv_enable_dp;
intel_encoder->post_disable = chv_post_disable_dp;
+ intel_encoder->post_pll_disable = chv_dp_post_pll_disable;
} else if (IS_VALLEYVIEW(dev)) {
intel_encoder->pre_pll_enable = vlv_dp_pre_pll_enable;
intel_encoder->pre_enable = vlv_pre_enable_dp;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 4f3b708..42fa135 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -148,6 +148,7 @@ struct intel_encoder {
void (*mode_set)(struct intel_encoder *intel_encoder);
void (*disable)(struct intel_encoder *);
void (*post_disable)(struct intel_encoder *);
+ void (*post_pll_disable)(struct intel_encoder *);
/* Read out the current hw state of this connector, returning true if
* the encoder is active. If the encoder is enabled it also set the pipe
* it is connected to in the pipe parameter. */
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 9f79afb..86b1a2c 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1678,6 +1678,28 @@ static void chv_hdmi_pre_pll_enable(struct intel_encoder
*encoder)
mutex_unlock(&dev_priv->sb_lock);
}
+static void chv_hdmi_post_pll_disable(struct intel_encoder *encoder)
+{
+ struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+ enum pipe pipe = t
