I was reviewing some old unassigned variable warnings from static
> > analysis by Coverity and found an issue introduced with the following
> > commit:
> >
> > commit aa7ffc01d254c91a36bf854d57a14049c6134c72
> > Author: Jesse Barnes
> > Date: Fri May 14 15:41
wing some old unassigned variable warnings from static
> > analysis by Coverity and found an issue introduced with the following
> > commit:
> >
> > commit aa7ffc01d254c91a36bf854d57a14049c6134c72
> > Author: Jesse Barnes
> > Date: Fri May 14 15:41:14 2010
LGTM.
Reviewed-by: Jesse Barnes
On Thu, Nov 14, 2019 at 9:07 AM Matt Roper wrote:
>
> Newer VBT versions will add an alternate way to read panel DTD
> information, so let's split parsing of the general panel information
> from the timing data in preparation.
>
> Cc: Ja
On Jan 12, 2017 8:04 AM, "Chris Wilson" wrote:
On Thu, Jan 12, 2017 at 05:48:49PM +0200, Mika Kuoppala wrote:
> Chris Wilson writes:
>
> > On Mon, Jan 09, 2017 at 06:52:53PM +0200, Mika Kuoppala wrote:
> >> +static int i915_gem_context_enable_svm(struct i915_gem_context *ctx)
> >> +{
> >> + int
On Wed, 2016-08-17 at 12:37 +0300, Joonas Lahtinen wrote:
> On ma, 2016-08-15 at 09:26 -0700, Jesse Barnes wrote:
> >
> > On Mon, 2016-08-15 at 15:34 +0300, Mika Kuoppala wrote:
> > >
> > >
> > > No idea yet why we would need to limit for rcs only.
&
On Mon, 2016-08-15 at 15:34 +0300, Mika Kuoppala wrote:
> Chris Wilson writes:
>
> >
> > On Mon, Aug 15, 2016 at 02:48:06PM +0300, Mika Kuoppala wrote:
> > >
> > > From: Jesse Barnes
> > >
> > > We just need to pass in an address to exec
On Mon, 2016-08-15 at 13:56 +0100, Chris Wilson wrote:
> On Mon, Aug 15, 2016 at 03:25:43PM +0300, Mika Kuoppala wrote:
> >
> > Chris Wilson writes:
> >
> > >
> > > On Mon, Aug 15, 2016 at 02:48:04PM +0300, Mika Kuoppala wrote:
> > > >
On 03/17/2016 05:31 AM, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: add another virtual PCH bridge for passthrough support
> URL : https://patchwork.freedesktop.org/series/4539/
> State : warning
>
> == Summary ==
>
> Series 4539v1 drm/i915: add another virtual PCH bridge for
Some configs use the P2X type but some use a P3X type PCH, so add that
to the detect_pch function so things work correctly.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_drv.c | 1 +
drivers/gpu/drm/i915/i915_drv.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu
On 03/11/2016 08:28 AM, John Harrison wrote:
> On 23/02/2016 21:06, Jesse Barnes wrote:
>> On 02/18/2016 06:27 AM, john.c.harri...@intel.com wrote:
>>> From: John Harrison
>>> struct drm_info_node *node = m->private;
>>> @@ -5424,6 +5587,12 @@
On 02/26/2016 07:55 AM, John Harrison wrote:
> On 23/02/2016 20:42, Jesse Barnes wrote:
>> On 02/18/2016 06:27 AM, john.c.harri...@intel.com wrote:
>>> From: John Harrison
>>>
>>> Added trace points to the scheduler to track all the various events,
>>>
t struct i915_debugfs_files {
> {"i915_gem_drop_caches", &i915_drop_caches_fops},
> {"i915_error_state", &i915_error_state_fops},
> {"i915_next_seqno", &i915_next_seqno_fops},
> + {"i915_sc
;
> +bool i915_scheduler_file_queue_is_full(struct drm_file *file);
>
> #endif /* _I915_SCHEDULER_H_ */
>
Just to clarify and make sure I understood the previous stuff: a queued execbuf
that has not yet been dispatched does not reserve and pin pages right? That
occurs at ac
On 02/18/2016 06:27 AM, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> Added trace points to the scheduler to track all the various events,
> node state transitions and other interesting things that occur.
>
> v2: Updated for new request completion tracking implementation.
>
> v3: U
;
> +__entry->seqno = node->params.request->seqno;
> +__entry->status = node->status;
> +),
> +
> + TP_printk("ring=%d, uniq=%d, seqno=%d, status=%d",
> + __entr
nable_scheduler)
> return i915_scheduler_queue_execbuffer_bypass(qe);
>
> node = kmalloc(sizeof(*node), GFP_KERNEL);
>
I did a double take here; maybe a comment along the lines of "if the scheduler
is disabled, queue the buffer immediately" would help, and something similar
for where the if (1) is added temporarily.
Doesn't matter too much though.
Reviewed-by: Jesse Barnes
Thanks,
Jesse
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
struct drm_i915_gem_request *req);
>
Maybe Chris remembers the history here; I think the wraparound idle goes all
the way back to Eric's original work with wrapping (something we had a lot of
trouble with early on iirc).
My only suggestion here is to add wrappers for a new __intel_ring
ev_private;
> + struct i915_scheduler *scheduler = dev_priv->scheduler;
> +
> + if (scheduler->flags[ring->id] & i915_sf_interrupts_enabled) {
> + ring->irq_put(ring);
> + scheduler->flags[
On 02/20/2016 01:22 AM, Chris Wilson wrote:
> On Fri, Feb 19, 2016 at 11:28:05AM -0800, Jesse Barnes wrote:
>> On 02/18/2016 06:26 AM, john.c.harri...@intel.com wrote:
>>> From: John Harrison
>>>
>>> MMIO flips are the preferred mechanism now
>
> Because
On 02/19/2016 11:53 AM, Ville Syrjälä wrote:
> On Fri, Feb 19, 2016 at 11:28:05AM -0800, Jesse Barnes wrote:
>> On 02/18/2016 06:26 AM, john.c.harri...@intel.com wrote:
>>> From: John Harrison
>>>
>>> MMIO flips are the preferred mechanism now but more imp
her threads a chance to run,
> + * and then retry the failing operation in its entirety.
>*/
> + /*FALLTHRU*/
> case 0:
> case -ERESTARTSYS:
> case -EINTR:
>
Reviewed-by: Jesse Barnes
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
i915/i915_gem.c
> @@ -1489,6 +1489,9 @@ static void i915_gem_request_retire(struct
> drm_i915_gem_request *request)
> fence_signal_locked(&request->fence);
> }
>
> + if (request->scheduler_qe)
> + i915_scheduler_clean_node(request->scheduler_qe);
ode->params.batch_obj = NULL;
> }
>
> + /* Release the locked buffers: */
> + for (i = 0; i < node->num_objs; i++)
> + drm_gem_object_unreference(&node->saved_objects[i].obj->base);
> + kfree(node->saved_objects);
>
ms->request);
>
> - ret = dev_priv->gt.execbuf_final(params);
> + qe = container_of(params, typeof(*qe), params);
> + ret = i915_scheduler_queue_execbuffer(qe);
> if (ret)
> return ret;
>
> - /*
> - * Free everything that was stored in the QE structur
_mode != dev_priv->relative_constants_mode) {
> @@ -1006,13 +1010,18 @@ int intel_execlists_submission_final(struct
> i915_execbuffer_params *params)
>
> ret = ring->emit_bb_start(req, exec_start, params->dispatch_flags);
> if (ret)
> - return ret;
> + goto err;
>
> trace_i915_gem_ring_dispatch(req, params->dispatch_flags);
>
> i915_gem_execbuffer_retire_commands(params);
>
> return 0;
> +
> +err:
> + intel_ring_reserved_space_cancel(params->request->ringbuf);
> +
> + return ret;
> }
>
> void intel_execlists_retire_requests(struct intel_engine_cs *ring)
>
I had to double check that it was ok to cancel space if the reserve failed (I
guess it is), so seems ok.
Reviewed-by: Jesse Barnes
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
return true;
> + else if (i915_scheduler_is_enabled(ring->dev))
> + return true;
> else if (obj->base.dma_buf &&
>!reservation_object_test_signaled_rcu(obj->base.dma_buf->resv,
>
Arithmetic on sequence numbers is unreliable with a scheduler. */
> + WARN_ON(i915_scheduler_is_enabled(signaller->dev));
> +
> /* Throughout all of the GEM code, seqno passed implies our current
>* seqno is >= the last seqno exec
ruct drm_i915_gem_object,
> - ring_list[ring->id]);
> -
> + list_for_each_entry_safe(obj, obj_next, &ring->active_list,
> ring_list[ring->id]) {
> if (!list_empty(&obj->last_read_req[ring->id]->list))
> - b
On 01/11/2016 02:10 PM, Chris Wilson wrote:
> On Mon, Jan 11, 2016 at 06:42:37PM +, john.c.harri...@intel.com wrote:
>> From: John Harrison
>>
>> A major point of the GPU scheduler is that it re-orders batch buffers
>> after they have been submitted to the driver. This leads to requests
>> com
> params->args_batch_start_offset;
>
> - ret = ring->emit_bb_start(params->request, exec_start,
> params->dispatch_flags);
> + ret = ring->emit_bb_start(req, exec_start, params->dispatch_flags);
> if (ret)
> return ret;
>
> - trace_i915_gem_ring_dispatch(params->request, params->dispatch_flags);
> + trace_i915_gem_ring_dispatch(req, params->dispatch_flags);
>
> i915_gem_execbuffer_retire_commands(params);
>
>
Reviewed-by: Jesse Barnes
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
4);
> if (ret)
> return ret;
> @@ -931,14 +954,14 @@ int intel_execlists_submission(struct
> i915_execbuffer_params *params,
> intel_logical_ring_emit(ringbuf, MI_NOOP);
> intel_logical_ring_emit(ringbuf, MI_LOAD_REGISTER_IMM(1));
> intel_logical_ring_emit(ringbuf, INSTPM);
> - intel_logical_ring_emit(ringbuf, instp_mask << 16 | instp_mode);
> + intel_logical_ring_emit(ringbuf, params->instp_mask << 16 |
> params->instp_mode);
> intel_logical_ring_advance(ringbuf);
>
> - dev_priv->relative_constants_mode = instp_mode;
> + dev_priv->relative_constants_mode = params->instp_mode;
> }
>
> exec_start = params->batch_obj_vm_offset +
> - args->batch_start_offset;
> + params->args_batch_start_offset;
>
> ret = ring->emit_bb_start(params->request, exec_start,
> params->dispatch_flags);
> if (ret)
> diff --git a/drivers/gpu/drm/i915/intel_lrc.h
> b/drivers/gpu/drm/i915/intel_lrc.h
> index 4e60d54..8d9bad7 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.h
> +++ b/drivers/gpu/drm/i915/intel_lrc.h
> @@ -93,6 +93,7 @@ struct i915_execbuffer_params;
> int intel_execlists_submission(struct i915_execbuffer_params *params,
> struct drm_i915_gem_execbuffer2 *args,
> struct list_head *vmas);
> +int intel_execlists_submission_final(struct i915_execbuffer_params *params);
> u32 intel_execlists_ctx_id(struct drm_i915_gem_object *ctx_obj);
>
> void intel_lrc_irq_handler(struct intel_engine_cs *ring);
Just a nitpick on naming; I think prepare/commit might be better than
submit/submit_final. But you don't have to respin just for that.
Reviewed-by: Jesse Barnes
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
it into two functions here... */
> +
> + /*
> + * Unconditionally invalidate gpu caches and ensure that we do flush
> + * any residual writes from the previous batch.
> + */
> + ret = logical_ring_invalidate_all_caches(params->request);
> + if (ret
On 01/26/2016 09:00 AM, Daniel Vetter wrote:
> On Tue, Jan 26, 2016 at 07:45:42AM -0800, Jesse Barnes wrote:
>> On 01/22/2016 09:00 AM, Daniel Vetter wrote:
>>> On Wed, Jan 20, 2016 at 06:26:02PM -0800, tom.orou...@intel.com wrote:
>>>> From: Tom O'Rourke
On 01/22/2016 09:00 AM, Daniel Vetter wrote:
> On Wed, Jan 20, 2016 at 06:26:02PM -0800, tom.orou...@intel.com wrote:
>> From: Tom O'Rourke
>>
>> SLPC (Single Loop Power Controller) is a replacement for
>> some host-based power management features. The SLPC
>> implemenation runs in firmware on Gu
On 01/21/2016 12:08 AM, Daniel Vetter wrote:
> On Wed, Jan 20, 2016 at 06:49:49PM +, Belgaumkar, Vinay wrote:
>> Hi Chris,
>> These tests were developed for testing buffered SVM(using userptr
>> and soft pinning API). I think Dan wanted me to rename the tests to
>> gem_softpin, sinc
On 01/19/2016 02:28 AM, Daniel Stone wrote:
>> > We aren't just talking about a few fbs here, we already see more than
>> > 100 fbs active during complex situations. Potentially doubling this
>> > number is surely a significant increase in memory usage, both from the
>> > manage
Fixup some fallout from the connector probing changes so testdisplay -m
will pick up newly hotplugged displays correctly.
Signed-off-by: Jesse Barnes mode_valid = 0;
return;
}
@@ -456,7 +463,7 @@ set_stereo_mode(struct connector *c)
* Each connector has a corresponding
On 01/11/2016 11:10 AM, John Harrison wrote:
> On 08/01/2016 22:46, Chris Wilson wrote:
>> On Fri, Jan 08, 2016 at 06:47:26PM +, john.c.harri...@intel.com wrote:
>>> +void i915_gem_request_notify(struct intel_engine_cs *ring, bool
>>> fence_locked)
>>> +{
>>> +struct drm_i915_gem_request *
On 01/11/2016 11:03 AM, John Harrison wrote:
> On 08/01/2016 22:05, Chris Wilson wrote:
>> On Fri, Jan 08, 2016 at 06:47:24PM +, john.c.harri...@intel.com wrote:
>>> From: John Harrison
>>>
>>> The fence object used inside the request structure requires a sequence
>>> number. Although this is
;
>
> - if (!i915_gem_request_completed(req, true))
> + if (!i915_gem_request_completed(req))
> gen6_rps_boost(to_i915(req->ring->dev), NULL,
> req->emitted_jiffies);
>
> @@ -7186,7 +7186,7 @@ void intel_queue_rps_b
On 01/11/2016 11:03 AM, John Harrison wrote:
> On 08/01/2016 21:59, Chris Wilson wrote:
>> On Fri, Jan 08, 2016 at 06:47:22PM +, john.c.harri...@intel.com wrote:
>>> From: John Harrison
>>>
>>> There is a construct in the linux kernel called 'struct fence' that is
>>> intended to keep track of
e GPU idle), without granting boost
> credits to clients that are throttling themselves (such as compositors).
>
> Signed-off-by: Chris Wilson
> Cc: "Zou, Nanhai"
> Cc: Jesse Barnes
> Reviewed-by: Jesse Barnes
> ---
> drivers/gpu/drm/i915/i915_gem.c | 16
On 01/08/2016 01:47 PM, Chris Wilson wrote:
> On Mon, Jan 04, 2016 at 01:16:54PM -0800, Jesse Barnes wrote:
>> On 01/04/2016 12:57 PM, Chris Wilson wrote:
>>> On Mon, Jan 04, 2016 at 09:20:44AM -0800, Jesse Barnes wrote:
>>>> So this one has my ack.
>>
On 01/06/2016 11:15 AM, Janne Heikkinen wrote:
> I've got Bay Trail based Asus X553MA and I've been experiencing daily hangs
> with kernels beginning from 4.2-rc1. I haven't had any problems with 4.1.x
> kernels and using 4.1.13 I've gotten constant 5+ day uptimes since November
> (I had to at leas
On 01/04/2016 11:39 AM, Chris Wilson wrote:
> On Mon, Jan 04, 2016 at 05:43:10PM +, Dave Gordon wrote:
>> On 23/12/15 21:02, Chris Wilson wrote:
>>> On Wed, Dec 23, 2015 at 07:33:53PM +, Dave Gordon wrote:
There are quite a number of places where the driver tests whether
a given c
On 12/11/2015 03:33 AM, Chris Wilson wrote:
> + * Note that this effectively effectively stalls the read by the time
> + * it takes to do a memory transaction, which more or less ensures
> + * that the write from the GPU has sufficient time to invalidate
> + * the CPU cacheline.
On 01/04/2016 12:57 PM, Chris Wilson wrote:
> On Mon, Jan 04, 2016 at 09:20:44AM -0800, Jesse Barnes wrote:
>> So this one has my ack.
>
> This series makes a number of fundamental mistakes in seqno-interrupt
> handling, so no.
Well unless you can enumerate the issues in enoug
On 12/17/2015 09:43 AM, Jesse Barnes wrote:
> On 12/11/2015 05:11 AM, john.c.harri...@intel.com wrote:
>> From: John Harrison
>>
>> There is a construct in the linux kernel called 'struct fence' that is
>> intended to keep track of work that is executed on
On 12/11/2015 05:11 AM, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> There is a construct in the linux kernel called 'struct fence' that is
> intended to keep track of work that is executed on hardware. I.e. it
> solves the basic problem that the drivers 'struct
> drm_i915_gem_reque
On 12/11/2015 05:11 AM, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> The fence object used inside the request structure requires a sequence
> number. Although this is not used by the i915 driver itself, it could
> potentially be used by non-i915 code if the fence is passed outside o
} else {
> - s.buf[s.count] = 0;
> - pr_cont("%s", s.buf + i);
> - }
> - }
> +void sync_dump_timeline(struct sync_timeline *timeline)
> +{
> + struct seq_file s = {
> + .buf = sync_dump_buf,
> + .size = sizeof(sync_dump_buf) - 1,
> + };
> +
> + pr_info("timeline: %p\n", timeline);
> + sync_print_obj(&s, timeline);
> +
> + sync_dump_dfs(&s, NULL);
> }
>
> #endif
>
I guess the Android guys might have feedback here, but it seems fine to me.
Reviewed-by: Jesse Barnes
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
On 12/11/2015 05:11 AM, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> The sync framework is now used by the i915 driver. Therefore it can be
> moved out of staging and into the regular tree. Also, the public
> interfaces can actually be made public and exported.
>
> v3: New patch fo
spin_unlock_irqrestore(&obj->child_list_lock, flags);
> }
> @@ -153,11 +159,7 @@ static void sync_print_fence(struct seq_file *s, struct
> sync_fence *fence)
> sync_status_str(atomic_read(&fence->status)));
>
> for (i = 0; i < fence->num_fences; ++i) {
> - struct sync_pt *pt =
> - container_of(fence->cbs[i].sync_pt,
> - struct sync_pt, base);
> -
> - sync_print_pt(s, pt, true);
> + sync_print_pt(s, fence->cbs[i].sync_pt, true);
> }
>
> spin_lock_irqsave(&fence->wq.lock, flags);
>
Reviewed-by: Jesse Barnes
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Maarten Lankhorst
> Signed-off-by: Tvrtko Ursulin
> Cc: Maarten Lankhorst
> Cc: Daniel Vetter
> Cc: Jesse Barnes
> Cc: de...@driverdev.osuosl.org
> Cc: Riley Andrews
> Cc: Greg Kroah-Hartman
> Cc: Arve Hjønnevåg
> ---
> drivers/staging/android/sync.c
writes and omitted the media
> domain.
>
> This asymmetry might have caused unstable behaviour on
> media ring access.
>
> Fix is to take media engine forcewake symmetrically to writes.
>
> References: https://bugs.freedesktop.org/show_bug.cgi?id=88012
> Cc: Deepak S
> C
On 12/12/2015 07:16 AM, Emil Velikov wrote:
> On 11 December 2015 at 21:55, Jesse Barnes wrote:
>> Pick up context flags, softpin, etc.
>>
>> Signed-off-by: Jesse Barnes
>> ---
>> include/drm/i915_drm.h | 57
>> ++
Pick up context flags, softpin, etc.
Signed-off-by: Jesse Barnes
---
include/drm/i915_drm.h | 57 ++
1 file changed, 48 insertions(+), 9 deletions(-)
diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index ded43b1..4ce1fe9 100644
--- a
dle(dev_priv);
> else
> gen6_set_rps(dev_priv->dev, dev_priv->rps.idle_freq);
>
Hah and a consistency fix snuck in there... nice.
Reviewed-by: Jesse Barnes
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
e GPU idle), without granting boost
> credits to clients that are throttling themselves (such as compositors).
>
> Signed-off-by: Chris Wilson
> Cc: "Zou, Nanhai"
> Cc: Jesse Barnes
> ---
> drivers/gpu/drm/i915/i915_gem.c | 16
> 1 file changed
ing even further.
>
> Signed-off-by: Chris Wilson
> Cc: "Goel, Akash"
> Cc: Daniel Vetter
> Cc: Jesse Barnes
> Cc: sta...@vger.kernel.org
> ---
> drivers/gpu/drm/i915/intel_fbdev.c | 18 +++---
> 1 file changed, 11 insertions(+), 7 deletions(-)
locate it. If we inherit the fb from
> the BIOS, we do not own the pinned vma (except for the reference we add
> in this patch for our access via info->screen_base).
>
> v3: Finish balancing the vma pinning for the normal !preallocated case.
>
> Signed-off-by: Chris Wilson
>
able binding.
>
> Signed-off-by: Chris Wilson
> Cc: "Goel, Akash"
> Cc: Daniel Vetter
> Cc: Jesse Barnes
> Cc: sta...@vger.kernel.org
> ---
> drivers/gpu/drm/i915/i915_drv.h| 1 +
> drivers/gpu/drm/i915/i915_gem.c| 43
> ++
On 11/19/2015 01:35 AM, Chris Wilson wrote:
> On Thu, Nov 19, 2015 at 10:14:08AM +0100, Daniel Vetter wrote:
>> On Wed, Nov 18, 2015 at 03:08:47PM -0800, Jesse Barnes wrote:
>>> On 11/17/2015 08:37 AM, Daniel Vetter wrote:
>>>> On Fri, Oct 30, 2015 at 04:58:41PM +
On 11/17/2015 08:37 AM, Daniel Vetter wrote:
> On Fri, Oct 30, 2015 at 04:58:41PM +, Chris Wilson wrote:
>> On Fri, Oct 30, 2015 at 05:14:21PM +0100, Daniel Vetter wrote:
>>> On Fri, Oct 23, 2015 at 06:43:32PM +0100, Chris Wilson wrote:
When accessing through the GTT from one CPU whilst co
s/gpu/drm/i915/intel_drv.h
> index 71a2e18..a97908a 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -938,6 +938,8 @@ void intel_crt_init(struct drm_device *dev);
>
>
> /* intel_ddi.c */
> +void intel_ddi_clk_select(struct intel_en
e now leak an extra rpm reference.
>
> So fix things by throwing intel_runtime_pm_disable() to the bin, so
> that the only leaked reference comes from the init power domain.
>
> Cc: Maarten Lankhorst
> Cc: Daniel Stone
> Cc: Jesse Barnes
> Fixes: 292b990e86ab ("drm/i915: Up
async_cookie_t cookie)
> drm_fb_helper_initial_config(&ifbdev->helper, ifbdev->preferred_bpp);
> }
>
> +void intel_fbdev_initial_config_async(struct drm_device *dev)
> +{
> + async_schedule(intel_fbdev_initial_config, to_i915(dev));
> +}
> +
> void intel_fbdev_fini(struct drm_device *dev)
> {
> struct drm_i915_private *dev_priv = dev->dev_private;
>
Reviewed-by: Jesse Barnes
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
On 11/06/2015 05:38 AM, Chris Wilson wrote:
> On Thu, Nov 05, 2015 at 10:17:56AM -0800, Jesse Barnes wrote:
>> On 11/05/2015 09:51 AM, Kristian Høgsberg wrote:
>>> On Tue, Oct 6, 2015 at 3:53 AM, Chris Wilson
>>> wrote:
>>>> Userspace can pass in an offset
On 11/05/2015 09:51 AM, Kristian Høgsberg wrote:
> On Tue, Oct 6, 2015 at 3:53 AM, Chris Wilson wrote:
>> 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 ha
On 11/03/2015 04:44 AM, Maarten Lankhorst wrote:
> Hey,
>
> Op 03-11-15 om 12:32 schreef Jani Nikula:
>> On Tue, 03 Nov 2015, Ville Syrjälä wrote:
>>> On Tue, Nov 03, 2015 at 08:31:41AM +0100, Maarten Lankhorst wrote:
Those platforms have the same bug as haswell, and the same fix applies to
On 11/04/2015 12:26 PM, Zanoni, Paulo R wrote:
> Em Qua, 2015-11-04 às 14:19 -0600, Jason Wessel escreveu:
>> On 11/04/2015 02:13 PM, Jesse Barnes wrote:
>>> On 11/04/2015 11:10 AM, Paulo Zanoni wrote:
>>>> From our maintainer Daniel Vetter a few days ago:
>>&g
C, and
> why other features such as PSR, DRRS, IPS and RPM are not also
> checking for in_dbg_master(). IMHO we should either remove the code as
> suggested by Daniel or we add some nice comments explaining why is FBC
> so special.
>
> v2: Rebase due to new patch order.
>
On 11/03/2015 12:07 PM, Dave Airlie wrote:
> We have a major process failure in place here, and shoving more code
> in the backend and hoping it somehow magically fixes itself between
> drm-intel-next and merging to Linus's tree is clearly not working for
> the past 6 months at least. I'm really un
unlucky, it's still required.
> - */
> - DRM_DEBUG_KMS("162MHz cpu eDP clock, might need ilk devA
> w/a\n");
> dpa_ctl |= DP_PLL_FREQ_162MHZ;
> intel_dp->DP |= DP_PLL_FREQ_162MHZ;
> } else {
>
Re
he rug.
> + */
> + intel_set_cpu_fifo_underrun_reporting(dev_priv, !pipe, false);
> + intel_set_pch_fifo_underrun_reporting(dev_priv, !pipe, false);
> + }
> +
> /* Only ilk+ has port A */
> - if (dport->port == PORT_A) {
> +
+
> temp &= ~SDVO_PIPE_B_SELECT;
> temp |= SDVO_ENABLE;
> intel_sdvo_write_sdvox(intel_sdvo, temp);
>
> temp &= ~SDVO_ENABLE;
> intel_sdvo_write_sdvox(intel_sdvo, temp);
> +
> + intel_wait_for_vblank_if_active(dev_priv->dev, PIPE_A);
> + intel_set_cpu_fifo_underrun_reporting(dev_priv, PIPE_A, true);
> + intel_set_pch_fifo_underrun_reporting(dev_priv, PIPE_A, true);
> }
> }
>
>
Reviewed-by: Jesse Barnes
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
around: Clear the timing override chicken bit again. */
> reg = TRANS_CHICKEN2(pipe);
> val = I915_READ(reg);
>
Reviewed-by: Jesse Barnes
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
struct drm_crtc *crtc)
> for_each_encoder_on_crtc(dev, crtc, encoder)
> if (encoder->post_disable)
> encoder->post_disable(encoder);
> +
> + if (intel_crtc->config->has_pch_encoder
enum transcoder transcoder = intel_crtc->config->cpu_transcoder;
>
> if (!crtc->state->active)
> return 0;
>
> - transcoder = intel_pipe_to_cpu_transcoder(dev->dev_private, pipe);
> -
> mask = B
encoder->disable(encoder);
> @@ -5104,9 +5109,6 @@ static void haswell_crtc_disable(struct drm_crtc *crtc)
> drm_crtc_vblank_off(crtc);
> assert_vblank_disabled(crtc);
>
> - if (intel_crtc->config->has_pch_encoder)
> -
assert_vblank_disabled(crtc);
>
> - if (intel_crtc->config->has_pch_encoder)
> - intel_set_pch_fifo_underrun_reporting(dev_priv, pipe, false);
> -
> intel_disable_pipe(intel_crtc);
>
> ironlake_pfit_disable(intel_crtc, false);
>
Reviewed-by: Jesse Barnes
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
temp |= TRANS_DP_VSYNC_ACTIVE_HIGH;
>
> switch (intel_trans_dp_port_sel(crtc)) {
>
God I wish we'd rename these structs a bit... "adjusted" and
"crtc->mode" don't really communicate much.
Reviewed-by: Jesse Barnes
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
index 9ec4716..7367e1a 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -455,16 +455,22 @@
> # define DP_EDP_14 0x03
>
> #define DP_EDP_GENERAL_CAP_1 0x701
> +#define DP_EDP_TCON_BACKLIGHT_ADJUSTMENT_CAPABLE (1 << 0)
> +#define DP_EDP_BACKLIGHT_AUX_ENABLE_CAPABLE (1 << 2)
>
> #define DP_EDP_BACKLIGHT_ADJUSTMENT_CAP 0x702
> +#define DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAPABLE (1 << 1)
> +#define DP_EDP_BACKLIGHT_BRIGHTNESS_BYTE_COUNT(1 << 2)
>
> #define DP_EDP_GENERAL_CAP_2 0x703
>
> #define DP_EDP_GENERAL_CAP_3 0x704/* eDP 1.4 */
>
> #define DP_EDP_DISPLAY_CONTROL_REGISTER 0x720
> +#define DP_EDP_BACKLIGHT_ENABLE (1 << 0)
>
> #define DP_EDP_BACKLIGHT_MODE_SET_REGISTER 0x721
> +#define DP_EDP_BACKLIGHT_BRIGHTNESS_CTL_MODE_DPCD_MASK 0x2
>
> #define DP_EDP_BACKLIGHT_BRIGHTNESS_MSB 0x722
> #define DP_EDP_BACKLIGHT_BRIGHTNESS_LSB 0x723
I don't have the spec for this but assume you've tested it. The code looks ok,
my only worry is that some eDP panels might return a DPCD backlight capability
but then just ignore the writes. But I guess we'll find that out soon enough
if we land this.
So:
Acked-by: Jesse Barnes
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
On 10/26/2015 11:58 PM, David Weinehall wrote:
> On Fri, Oct 23, 2015 at 12:39:31PM -0700, Jesse Barnes wrote:
>> On 10/22/2015 01:35 PM, ville.syrj...@linux.intel.com wrote:
>>> From: Ville Syrjälä
>>>
>>> Do a dry run with rtcwake first to determine if the s
On 10/22/2015 01:35 PM, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Do a dry run with rtcwake first to determine if the system even supports
> the intended suspend state. If not, skip the test.
>
> Fixes a bunch of stuff on my BYT FFRD8 that doesn't support S3.
>
> Signed-off
RITE(reg, 0);
> + I915_WRITE(reg, I915_READ(reg) & ~DISPLAY_PLANE_ENABLE);
> I915_WRITE(DSPSURF(plane), 0);
> POSTING_READ(reg);
> return;
For some reason this rings a bell. Paulo did you work on someth
hsw_unclaimed_reg_debug(dev_priv, reg, false, true); \
> @@ -985,7 +985,7 @@ gen9_write##x(struct drm_i915_private *dev_priv, off_t
> reg, u##x val, \
> enum forcewake_domains fw_engine; \
> GEN6_WRITE_HEADER; \
> hsw_unclaimed_reg_debug(dev_priv, reg, false,
e {
> - lvds_encoder->reg = LVDS;
> - }
> + lvds_encoder->reg = lvds_reg;
>
> /* create the scaling mode property */
> drm_mode_create_scaling_mode_property(dev);
> @@ -1140,7 +1139,6 @@ void intel_lvds_init(struct drm_device *dev)
> i
gt; if (IS_VALLEYVIEW(dev)) {
> enum pipe pipe = vlv_power_sequencer_pipe(intel_dp);
> + u32 pp_ctrl_reg, pp_div_reg;
> + u32 pp_div;
>
> pp_ctrl_reg = VLV_PIPE_PP_CONTROL(pipe);
> pp_div_reg = VLV_PIPE_PP_DIVISOR(pipe);
> @@ -5526,7 +5526,6 @@ static void intel_dp_set_drrs_state(struct drm_device
> *dev, int refresh_rate)
> struct intel_dp *intel_dp = dev_priv->drrs.dp;
> struct intel_crtc_state *config = NULL;
> struct intel_crtc *intel_crtc = NULL;
> - u32 reg, val;
> enum drrs_refresh_rate_type index = DRRS_HIGH_RR;
>
> if (refresh_rate <= 0) {
> @@ -5588,9 +5587,10 @@ static void intel_dp_set_drrs_state(struct drm_device
> *dev, int refresh_rate)
> DRM_ERROR("Unsupported refreshrate type\n");
> }
> } else if (INTEL_INFO(dev)->gen > 6) {
> - reg = PIPECONF(intel_crtc->config->cpu_transcoder);
> - val = I915_READ(reg);
> + u32 reg = PIPECONF(intel_crtc->config->cpu_transcoder);
> + u32 val;
>
> + val = I915_READ(reg);
> if (index > DRRS_HIGH_RR) {
> if (IS_VALLEYVIEW(dev))
> val |= PIPECONF_EDP_RR_MODE_SWITCH_VLV;
>
Reviewed-by: Jesse Barnes
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
or (i = 0; i < 7; i++)
> + I915_WRITE(SWF1(i), dev_priv->regfile.saveSWF1[i]);
> + } else if (HAS_GMCH_DISPLAY(dev_priv)) {
> + for (i = 0; i < 16; i++) {
> + I915_WRITE(SWF0(i), dev_priv->regfile.saveSWF0[i]);
> + I915
> g4x_flip_count_after_eq(I915_READ(PIPE_FLIPCOUNT_G4X(crtc->pipe)),
> crtc->unpin_work->flip_count);
> }
>
> @@ -11374,7 +11374,7 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc,
> intel_crtc->reset_
else
> mask = SDE_GMBUS_CPT | SDE_AUX_MASK_CPT;
>
> - GEN5_ASSERT_IIR_IS_ZERO(SDEIIR);
> + gen5_assert_iir_is_zero(dev_priv, SDEIIR);
> I915_WRITE(SDEIMR, ~mask);
> }
>
>
Reviewed-by: Jesse Barnes
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
(3f << 0)
> +#define DATA_TYPE_MASK (0x3f << 0)
> /* data type values, see include/video/mipi_display.h */
>
> #define _MIPIA_GEN_FIFO_STAT (dev_priv->mipi_mmio_base + 0xb074)
>
Hah! Maybe they're su
fine DPLL_CTRL2_DDI_CLK_SEL(clk, port) (clk<<((port)*3+1))
> +#define DPLL_CTRL2_DDI_CLK_SEL(clk, port) ((clk)<<((port)*3+1))
> #define DPLL_CTRL2_DDI_SEL_OVERRIDE(port) (1<<((port)*3))
>
> /* DPLL Status */
> @@ -7384,23 +7384,23 @@ enum skl_disp_power_wells {
> #define DPLL3_CFGCR1 0x6C050
> #define DPLL_CFGCR1_FREQ_ENABLE (1<<31)
> #define DPLL_CFGCR1_DCO_FRACTION_MASK (0x7fff<<9)
> -#define DPLL_CFGCR1_DCO_FRACTION(x) (x<<9)
> +#define DPLL_CFGCR1_DCO_FRACTION(x) ((x)<<9)
> #define DPLL_CFGCR1_DCO_INTEGER_MASK(0x1ff)
>
> #define DPLL1_CFGCR2 0x6C044
> #define DPLL2_CFGCR2 0x6C04C
> #define DPLL3_CFGCR2 0x6C054
> #define DPLL_CFGCR2_QDIV_RATIO_MASK (0xff<<8)
> -#define DPLL_CFGCR2_QDIV_RATIO(x) (x<<8)
> -#define DPLL_CFGCR2_QDIV_MODE(x)(x<<7)
> +#define DPLL_CFGCR2_QDIV_RATIO(x) ((x)<<8)
> +#define DPLL_CFGCR2_QDIV_MODE(x)((x)<<7)
> #define DPLL_CFGCR2_KDIV_MASK (3<<5)
> -#define DPLL_CFGCR2_KDIV(x) (x<<5)
> +#define DPLL_CFGCR2_KDIV(x) ((x)<<5)
> #define DPLL_CFGCR2_KDIV_5 (0<<5)
> #define DPLL_CFGCR2_KDIV_2 (1<<5)
> #define DPLL_CFGCR2_KDIV_3 (2<<5)
> #define DPLL_CFGCR2_KDIV_1 (3<<5)
> #define DPLL_CFGCR2_PDIV_MASK (7<<2)
> -#define DPLL_CFGCR2_PDIV(x) (x<<2)
> +#define DPLL_CFGCR2_PDIV(x) ((x)<<2)
> #define DPLL_CFGCR2_PDIV_1 (0<<2)
> #define DPLL_CFGCR2_PDIV_2 (1<<2)
> #define DPLL_CFGCR2_PDIV_3 (2<<2)
>
Reviewed-by: Jesse Barnes
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> - I915_WRITE(GMBUS0 + reg_offset, 0);
> + I915_WRITE(GMBUS0, 0);
> ret = ret ?: i;
> goto out;
>
> @@ -570,9 +562,9 @@ clear_err:
>* of resetting the GMBUS controller and so clearing the
>* BUS_ERROR raised by the slave's NAK.
>*/
> - I915_WRITE(GMBUS1 + reg_offset, GMBUS_SW_CLR_INT);
> - I915_WRITE(GMBUS1 + reg_offset, 0);
> - I915_WRITE(GMBUS0 + reg_offset, 0);
> + I915_WRITE(GMBUS1, GMBUS_SW_CLR_INT);
> + I915_WRITE(GMBUS1, 0);
> + I915_WRITE(GMBUS0, 0);
>
> DRM_DEBUG_KMS("GMBUS [%s] NAK for addr: %04x %c(%d)\n",
>adapter->name, msgs[i].addr,
> @@ -595,7 +587,7 @@ clear_err:
> timeout:
> DRM_INFO("GMBUS [%s] timed out, falling back to bit banging on pin
> %d\n",
>bus->adapter.name, bus->reg0 & 0xff);
> - I915_WRITE(GMBUS0 + reg_offset, 0);
> + I915_WRITE(GMBUS0, 0);
>
> /* Hardware may not support GMBUS over these pins? Try GPIO bitbanging
> instead. */
> bus->force_bit = 1;
>
Reviewed-by: Jesse Barnes
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
i >> 2), *data);
> + data++;
> }
> + for (; i < VIDEO_DIP_VSC_DATA_SIZE; i += 4)
> + I915_WRITE(HSW_TVIDEO_DIP_VSC_DATA(cpu_transcoder,
> +i >> 2), 0);
>
> I915_WRITE(ctl_reg, VIDEO_DIP_ENABLE_VSC_HSW);
> POSTING_READ(ctl_reg);
>
Since you fixed the macro to use a *4 for the reg index, it might be
clearer to fix up the loop to just use i++ instead? I guess you'd then
have to divide the condition, so meh (or maybe we need a DWORDS(bytes)
macro!). Either way:
Reviewed-by: Jesse Barnes
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
On 10/09/2015 02:07 AM, David Woodhouse wrote:
> On Fri, 2015-10-09 at 10:47 +0200, Daniel Vetter wrote:
>> On Fri, Oct 09, 2015 at 08:56:24AM +0100, David Woodhouse wrote:
>>> On Fri, 2015-10-09 at 09:28 +0200, Daniel Vetter wrote:
Hm if this still works the same way as on older platform
On 10/09/2015 06:29 AM, David Woodhouse wrote:
> On Fri, 2015-09-04 at 09:59 -0700, Jesse Barnes wrote:
>>
>> @@ -2286,6 +2287,10 @@ struct drm_i915_gem_request {
>> /** Execlists no. of times this request has been sent to the ELSP */
>> int elsp_submitt
t since fbdev is not very
> + * important and we should probably use that space with FBC or other
> + * features. */
> + if (size * 2 < dev_priv->gtt.stolen_usable_size)
> + obj = i915_gem_object_create_stolen(dev, size);
> if (obj == NULL)
>
ross suspend/resume as
>> intel_fbdev_set_suspend() does a full clear over the whole scanout.
>>
>> v2: rebased on latest nightly (Wayne)
>>
>> Signed-off-by: Chris Wilson
>> Cc: "Goel, Akash"
>> Cc: Daniel Vetter
>> Cc: Jesse Barnes
&
1 - 100 of 3350 matches
Mail list logo
