Re: [Intel-gfx] Computation of return value being discarded in get_cpu_power() in drivers/platform/x86/intel_ips.c

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:14 2

Re: [Intel-gfx] Computation of return value being discarded in get_cpu_power() in drivers/platform/x86/intel_ips.c

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:1

Re: [Intel-gfx] [PATCH v4 1/2] drm/i915/vbt: Parse panel options separately from timing data

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: Jani Ni

Re: [Intel-gfx] [RFC PATCH 2/3] drm/i915: IOMMU based SVM implementation v16

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

Re: [Intel-gfx] [PATCH RFC 3/4] drm/i915: add SVM execbuf ioctl v10

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. &

Re: [Intel-gfx] [PATCH RFC 3/4] drm/i915: add SVM execbuf ioctl v10

On Mon, 2016-08-15 at 15:34 +0300, Mika Kuoppala wrote: > Chris Wilson <ch...@chris-wilson.co.uk> writes: > > > > > On Mon, Aug 15, 2016 at 02:48:06PM +0300, Mika Kuoppala wrote: > > > > > > From: Jesse Barnes <jbar...@virtuousgeek.org> > >

Re: [Intel-gfx] [PATCH RFC 1/4] drm/i915: add create_context2 ioctl

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 <ch...@chris-wilson.co.uk> writes: > > > > > > > > On Mon, Aug 15, 2016 at 02:48:04PM +0300, Mika Kuoppa

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: add another virtual PCH bridge for passthrough support

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

[Intel-gfx] [PATCH] drm/i915: add another virtual PCH bridge for passthrough support

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 <jbar...@virtuousgeek.org> --- drivers/gpu/drm/i915/i915_drv.c | 1 + drivers/gpu/drm/i915/i915_drv.h | 1 + 2 files changed, 2 inse

Re: [Intel-gfx] [PATCH v5 26/35] drm/i915: Added debugfs interface to scheduler tuning parameters

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 <john.c.harri...@intel.com> >>> struct drm_info_node *node = m->private; >>&g

Re: [Intel-gfx] [PATCH v5 24/35] drm/i915: Added trace points to scheduler

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 <john.c.harri...@intel.com> >>> >>> Added trace points to the scheduler to tr

Re: [Intel-gfx] [PATCH v5 26/35] drm/i915: Added debugfs interface to scheduler tuning parameters

node *node = m->private; > @@ -5424,6 +5587,12 @@ static const struct i915_debugfs_files { > {"i915_gem_drop_caches", _drop_caches_fops}, > {"i915_error_state", _error_state_fops}, > {"i915_next_seqno", _next_seqno_fops}, > +

Re: [Intel-gfx] [PATCH v5 25/35] drm/i915: Added scheduler queue throttling by DRM file handle

*completed, bool *busy); > +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?

Re: [Intel-gfx] [PATCH v5 24/35] drm/i915: Added trace points to scheduler

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

Re: [Intel-gfx] [PATCH v5 24/35] drm/i915: Added trace points to scheduler

__entry->seqno = node->params.request->seqno; > +__entry->status = node->status; > +), > + > + TP_printk("ring=%d, uniq=%d, seqno=%d, status=%d", > +

Re: [Intel-gfx] [PATCH v5 21/35] drm/i915: Added a module parameter to allow the scheduler to be disabled

ble_scheduler*/) > + if (!i915.enable_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,

Re: [Intel-gfx] [PATCH v5 22/35] drm/i915: Support for 'unflushed' ring idle

_all_caches(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

Re: [Intel-gfx] [PATCH v5 20/35] drm/i915: Add scheduler hook to GPU reset

e_cs *ring) > +{ > + struct drm_i915_private *dev_priv = ring->dev->dev_private; > + struct i915_scheduler *scheduler = dev_priv->scheduler; > + > + if (scheduler->flags[ring->id] & i915_sf_interrupts_enabled) { > + ring->irq_put(ring); > + s

Re: [Intel-gfx] [PATCH v5 09/35] drm/i915: Force MMIO flips when scheduler enabled

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 <john.c.harri...@intel.com> >>> >>> MMIO flips are the prefer

Re: [Intel-gfx] [PATCH v5 09/35] drm/i915: Force MMIO flips when scheduler enabled

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 <john.c.harri...@intel.com> >>> >>> MMIO flips are the preferre

Re: [Intel-gfx] [PATCH v5 18/35] drm/i915: Added scheduler support to page fault handler

onse is to give other 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 <jbar...@

Re: [Intel-gfx] [PATCH v5 16/35] drm/i915: Hook scheduler node clean up into retire requests

qe) > + i915_scheduler_clean_node(request->scheduler_qe); > + > i915_gem_request_unreference(request); > } > > Reviewed-by: Jesse Barnes <jbar...@virtuousgeek.org> ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v5 15/35] drm/i915: Added tracking/locking of batch buffer objects

e) > node->params.batch_obj = NULL; > } > > + /* Release the locked buffers: */ > + for (i = 0; i < node->num_objs; i++) > + drm_gem_object_unreference(>saved_objects[i].obj->base); > + kfree(node->saved_objects); > + node->sa

Re: [Intel-gfx] [PATCH v5 13/35] drm/i915: Redirect execbuffer_final() via scheduler

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; > > - /* > -

Re: [Intel-gfx] [PATCH v5 14/35] drm/i915: Keep the reserved space mechanism happy

p;& > params->instp_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 (r

Re: [Intel-gfx] [PATCH v5 09/35] drm/i915: Force MMIO flips when scheduler enabled

;base.dma_buf->resv, > false)) > Why can't we use mmio flips unconditionally? Maarten or Ville? Reviewed-by: Jesse Barnes <jbar...@virtuousgeek.org> ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v5 08/35] drm/i915: Disable hardware semaphores when GPU scheduler is enabled

our current >* seqno is >= the last seqno executed. However for hardware the >* comparison is strictly greater than. > I'd rather get rid of this altogether, but I guess we'll need it for the older gens. Another option would be to make the sync_to hook NULL in the scheduler case, though I guess the failure mode is less desirable there. Reviewed-by: Jesse Barnes <jbar...@virtuousgeek.org> ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v5 07/35] drm/i915: Prepare retire_requests to handle out-of-order seqnos

struct drm_i915_gem_object, > - ring_list[ring->id]); > - > + list_for_each_entry_safe(obj, obj_next, >active_list, > ring_list[ring->id]) { > if (!list_empty(>last_read_req[ring->id]->list)) > - br

Re: [Intel-gfx] [PATCH v4 04/38] drm/i915: Split i915_dem_do_execbuffer() in half

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 <jbar...@virtuousgeek.org> ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v4 08/38] drm/i915: Prepare retire_requests to handle out-of-order seqnos

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.

Re: [Intel-gfx] [PATCH v4 03/38] drm/i915: Prelude to splitting i915_gem_do_execbuffer in two

arams->request); > + if (ret) > + return ret; > + > if (ring == _priv->ring[RCS] && > instp_mode != dev_priv->relative_constants_mode) { > ret = intel_logical_ring_begin(params->request, 4); > @@ -937,7 +946,6 @@ int intel_execlists_submission(struct > i915_execbuffer_params *params, > > trace_i915_gem_ring_dispatch(params->request, params->dispatch_flags); > > - i915_gem_execbuffer_move_to_active(vmas, params->request); > i915_gem_execbuffer_retire_commands(params); > > return 0; > Do we need to do anything if the cache invalidation fails like move the buffers back off the active list? The order changed here, so I'm wondering. If that's not a problem, then: Reviewed-by: Jesse Barnes <jbar...@virtuousgeek.org> ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v4 05/38] drm/i915: Cache request pointer in *_submission_final()

5_execbuffer_params *params) > exec_start = params->batch_obj_vm_offset + > 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 <jbar...@virtuousgeek.org> ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC 00/22] Add support for GuC-based SLPC

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 >>

Re: [Intel-gfx] [RFC 00/22] Add support for GuC-based SLPC

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 <Tom.O

Re: [Intel-gfx] [RFC] drm/i915: Render decompression support for Gen9 and above

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 >> >

Re: [Intel-gfx] [PATCH igt] igt/gem_softpin: Remove false dependencies on esoteric features

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,

[Intel-gfx] [PATCH i-g-t] lib/igt_kms, tests/testdisplay: allow probing of new connector modes

Fixup some fallout from the connector probing changes so testdisplay -m will pick up newly hotplugged displays correctly. Signed-off-by: Jesse Barnes <jbar...@virtuousgeek.org. --- lib/igt_kms.c | 53 - lib/igt_kms.h |

Re: [Intel-gfx] [PATCH 2/7] drm/i915: Removed now redudant parameter to i915_gem_request_completed()

st *req = boost->req; > > - 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 @@ vo

Re: [Intel-gfx] [PATCH 5/7] drm/i915: Interrupt driven fences

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

Re: [Intel-gfx] [PATCH 3/7] drm/i915: Add per context timelines to fence object

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

Re: [Intel-gfx] [PATCH 1/7] drm/i915: Convert requests to use struct fence

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

Re: [Intel-gfx] [PATCH 036/190] drm/i915: Restore waitboost credit to the synchronous waiter

the GPU idle), without granting boost > credits to clients that are throttling themselves (such as compositors). > > Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk> > Cc: "Zou, Nanhai" <nanhai....@intel.com> > Cc: Jesse Barnes <jbar...@virtuousgeek.o

Re: [Intel-gfx] [PATCH 05/13] drm/i915: Convert requests to use struct fence

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. >

Re: [Intel-gfx] drm/i915: Agressive downclocking on Baytrail

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

Re: [Intel-gfx] [PATCH 05/13] drm/i915: Convert requests to use struct fence

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 en

Re: [Intel-gfx] [PATCH v2, 2/4] drm/i915: simplify testing for the global default context

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

Re: [Intel-gfx] [PATCH 21/32] drm/i915: Broadwell execlists needs exactly the same seqno w/a as legacy

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

Re: [Intel-gfx] [PATCH 05/13] drm/i915: Convert requests to use struct fence

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 <john.c.harri...@intel.com> >> >> There is a construct in the linux kernel called 'struct fence' that is >> intended to keep track of work

Re: [Intel-gfx] [PATCH] drm/i915/vlv: Take forcewake on media engine writes

ine 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: Deepa

Re: [Intel-gfx] [PATCH 01/13] staging/android/sync: Support sync points created from dma-fences

{ > struct sync_pt *pt = > container_of(pos, struct sync_pt, child_list); > - sync_print_pt(s, pt, false); > + sync_print_pt(s, >base, false); > } > spin_unlock_irqrestore(>child_list_lock, flags); > } > @@ -153,11 +159,7 @@

Re: [Intel-gfx] [PATCH 05/13] drm/i915: Convert requests to use struct fence

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

Re: [Intel-gfx] [PATCH 07/13] drm/i915: Add per context timelines to fence object

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

Re: [Intel-gfx] [PATCH 02/13] staging/android/sync: add sync_fence_create_dma

ack my Maarten. > > Signed-off-by: Maarten Lankhorst <maarten.lankho...@canonical.com> > Signed-off-by: Tvrtko Ursulin <tvrtko.ursu...@intel.com> > Cc: Maarten Lankhorst <maarten.lankho...@linux.intel.com> > Cc: Daniel Vetter <dan...@ffwll.ch> > Cc: Jesse Ba

Re: [Intel-gfx] [PATCH 03/13] staging/android/sync: Move sync framework out of staging

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

Re: [Intel-gfx] [PATCH 04/13] android/sync: Improved debug dump to dmesg

HUNK] = c; > - } 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(, timeline); > + > + sync_dump_dfs(, NULL); > } > > #endif > I guess the Android guys might have feedback here, but it seems fine to me. Reviewed-by: Jesse Barnes <jbar...@virtuousgeek.org> ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] intel: merge latest i915_drm.h

On 12/12/2015 07:16 AM, Emil Velikov wrote: > On 11 December 2015 at 21:55, Jesse Barnes <jbar...@virtuousgeek.org> wrote: >> Pick up context flags, softpin, etc. >> >> Signed-off-by: Jesse Barnes <jbar...@virtuousgeek.org> >&

[Intel-gfx] [PATCH] intel: merge latest i915_drm.h

Pick up context flags, softpin, etc. Signed-off-by: Jesse Barnes <jbar...@virtuousgeek.org> --- 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

Re: [Intel-gfx] [PATCH] drm/i915: Flush the RPS bottom-half when the GPU idles

gt; vlv_set_rps_idle(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 <jbar...@virtuousgeek.org> ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Restore waitboost credit to the synchronous waiter

the GPU idle), without granting boost > credits to clients that are throttling themselves (such as compositors). > > Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk> > Cc: "Zou, Nanhai" <nanhai@intel.com> > Cc: Jesse Barnes <jesse.bar...@intel.c

Re: [Intel-gfx] [PATCH v2 1/2] drm/i915: Set the map-and-fenceable flag for preallocated objects

able binding. > > Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk> > Cc: "Goel, Akash" <akash.g...@intel.com> > Cc: Daniel Vetter <daniel.vet...@ffwll.ch> > Cc: Jesse Barnes <jbar...@virtuousgeek.org> > Cc: sta...@vger.kernel.org > --- >

Re: [Intel-gfx] [PATCH v4] drm/i915: Pin the ifbdev for the info->system_base GGTT mmapping

ing even further. > > Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk> > Cc: "Goel, Akash" <akash.g...@intel.com> > Cc: Daniel Vetter <daniel.vet...@ffwll.ch> > Cc: Jesse Barnes <jbar...@virtuousgeek.org> > Cc: sta...@vger.kernel.org &

Re: [Intel-gfx] [PATCH v3] drm/i915: Pin the ifbdev for the info->system_base GGTT mmapping

Wilson <ch...@chris-wilson.co.uk> > Cc: "Goel, Akash" <akash.g...@intel.com> > Cc: Daniel Vetter <daniel.vet...@ffwll.ch> > Cc: Jesse Barnes <jbar...@virtuousgeek.org> > Cc: sta...@vger.kernel.org > --- > drivers/gpu/drm/i915/intel_fbdev.c | 23 ++

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Serialise updates to GGTT with access through GGTT on Braswell

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:

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Serialise updates to GGTT with access through GGTT on Braswell

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

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Kill intel_runtime_pm_disable()

t; do, we 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 <maarten.lankho...@linux.intel.com> > Cc: Daniel Stone <dani...@

Re: [Intel-gfx] [PATCH] drm/i915: Try to fix MST for SKL

ain(intel_dp); > diff --git a/drivers/gpu/drm/i915/intel_drv.h > b/drivers/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);

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Add soft-pinning API for execbuffer

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 <ch...@chris-wilson.co.uk> >>> wrote: >

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Move the fbdev async_schedule() into intel_fbdev.c

ntel_fbdev_initial_config(void *data, > async_cookie_t cookie) > drm_fb_helper_initial_config(>helper, ifbdev->preferred_bpp); > } > > +void intel_fbdev_initial_config_async(struct drm_device *dev) > +{ > + async_schedule(intel_fbdev_initial_config, to_i91

Re: [Intel-gfx] [PATCH v2 02/14] drm/i915: Extend DSL readout fix to BDW and SKL.

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

Re: [Intel-gfx] [PATCH 12/13] drm/i915: remove in_dbg_master check from intel_fbc.c

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

Re: [Intel-gfx] [PATCH 12/13] drm/i915: remove in_dbg_master check from intel_fbc.c

t problem caused by FBC, 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 n

Re: [Intel-gfx] skylake + drm-next - warn city

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

Re: [Intel-gfx] [PATCH 01/14] drm/i915: Don't use intel_pipe_to_cpu_transcoder() when there's a pipe config around

ev_private, pipe); > - > mask = BIT(POWER_DOMAIN_PIPE(pipe)); > mask |= BIT(POWER_DOMAIN_TRANSCODER(transcoder)); > if (intel_crtc->config->pch_pfit.enabled || > Reviewed-by: Jesse Barnes <jbar...@virtuousgeek.org> ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 09/14] drm/i915: Hide underruns from eDP PLL and port enable on ILK

* enable case. Just sweep it all under the rug. > + */ > + intel_set_cpu_fifo_underrun_reporting(dev_priv, !pipe, false); > + intel_set_pch_fifo_underrun_reporting(dev_priv, !pipe, false); > + } > + > /* Only ilk+

Re: [Intel-gfx] [PATCH 07/14] drm/i915: Check for CPT and not !IBX in ironlake_disable_pch_transcoder()

AS_PCH_IBX(dev)) { > + if (HAS_PCH_CPT(dev)) { > /* Workaround: Clear the timing override chicken bit again. */ > reg = TRANS_CHICKEN2(pipe); > val = I915_READ(reg); > Reviewed-by: Jesse Barnes <jbar...@virtuousgeek.org>

Re: [Intel-gfx] [PATCH 05/14] drm/i915: Re-enable PCH FIO underrun reporting after pipe has been disabled

nfig->has_pch_encoder) > + intel_set_pch_fifo_underrun_reporting(dev_priv, TRANSCODER_A, > + true); > } > > static void i9xx_pfit_enable(struct intel_crtc *crtc) > Reviewed-by: Jesse Barnes <jbar...@virtuousgeek.org> ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 11/14] drm/i915: Remove ILK-A eDP PLL workaround notes

A w/a for the > - * 162MHz clock. If we're really 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; >

Re: [Intel-gfx] [PATCH 04/14] drm/i915: Enable PCH FIFO underruns later on HSW+

nfig->has_pch_encoder) > - intel_set_pch_fifo_underrun_reporting(dev_priv, TRANSCODER_A, > - false); > intel_disable_pipe(intel_crtc); > > if (intel_crtc->config->dp_encoder_is_mst) > Reviewed-by: Jesse Barnes <jbar...@virtuousgeek.org> ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 03/14] drm/i915: Enable PCH FIFO underruns later on ILK/SNB/IVB

e(encoder); > > drm_crtc_vblank_off(crtc); > 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_

Re: [Intel-gfx] [PATCH 02/14] drm/i915: Set sync polarity from adjusted mode for TRANS_DP_CTL

djusted_mode->flags & DRM_MODE_FLAG_PVSYNC) > 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 comm

Re: [Intel-gfx] [PATCH 08/14] drm/i915: Disable FIFO underrun reporting around IBX transcoder B workaround

pch_fifo_underrun_reporting(dev_priv, PIPE_A, false); > + > temp &= ~SDVO_PIPE_B_SELECT; > temp |= SDVO_ENABLE; > intel_sdvo_write_sdvox(intel_sdvo, temp); > > temp &= ~SDVO_ENABLE; > intel_sdvo_write_sdvo

Re: [Intel-gfx] [PATCH 1/1] drm/i915: Add Backlight Control using DPCD for eDP connectors

,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 <jbar...@virtuousgeek.org> ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t 2/4] lib: Skip suspend/hibernate tests if the system doesn't support them

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ä <ville.syrj...@linux.intel.com> >>> >>> Do a dry run wit

Re: [Intel-gfx] [PATCH i-g-t 2/4] lib: Skip suspend/hibernate tests if the system doesn't support them

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

Re: [Intel-gfx] [PATCH] drm/i915: respect previous reg values on primary plane disable

|| !fb) { > - I915_WRITE(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 yo

Re: [Intel-gfx] [PATCH 25/43] drm/i915: Include gpio_mmio_base in GMBUS reg defines

ret = -ETIMEDOUT; > } > - 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 <jbar...@virtuousgeek.org> ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 27/43] drm/i915: Fix a few bad hex numbers in register defines

E_SHIFT 0 > -#define DATA_TYPE_MASK (3f << 0) > +#define DATA_TYPE_MASK (0x3f << 0) > /* data type values, see include/video/mipi_display.h */ > > #define _MIPIA_GEN_FIFO_STAT (dev_priv->m

Re: [Intel-gfx] [PATCH 24/43] drm/i915: Parametrize HSW video DIP data registers

I915_WRITE(HSW_TVIDEO_DIP_VSC_DATA(cpu_transcoder, > +i >> 2), *data); > + data++; > } > + for (; i < VIDEO_DIP_VSC_DATA_SIZE; i += 4) > + I915_WRITE(HSW_TVIDEO_DIP_VSC_DATA(cpu_transcode

Re: [Intel-gfx] [PATCH 26/43] drm/i915: Protect register macro arguments

define DPLL_CTRL2_DDI_CLK_SEL_SHIFT(port)((port)*3+1) > -#define 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)) > >

Re: [Intel-gfx] [PATCH 29/43] drm/i915: s/PIPE_FRMCOUNT_GM45/PIPE_FRMCOUNT_G4X/ etc.

page_flip(struct drm_crtc *crtc, > intel_crtc->reset_counter = > atomic_read(_priv->gpu_error.reset_counter); > > if (INTEL_INFO(dev)->gen >= 5 || IS_G4X(dev)) > - work->flip_count = I915_READ(PIPE_FLIPCOUNT_GM45(pipe)) + 1; > + work->flip_count = I915_READ(PIPE_FLIPCOUNT_G4X(pipe)) + 1; > > if (IS_VALLEYVIEW(dev)) { > ring = _priv->ring[BCS]; > Reviewed-by: Jesse Barnes <jbar...@virtuousgeek.org> ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 28/43] drm/i915: Turn GEN5_ASSERT_IIR_IS_ZERO() into a function

c void ibx_irq_postinstall(struct drm_device *dev) > 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 <jbar...@virtuousgeek.org> ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 30/43] drm/i915: Parametrize and fix SWF registers

f (IS_GEN2(dev_priv)) { > + for (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), d

Re: [Intel-gfx] [PATCH v2 31/43] drm/i915: Throw out some useless variables

er(struct notifier_block > *this, unsigned long code, > > 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_P

Re: [Intel-gfx] [PATCH 32/43] drm/i915: Clean up LVDS register handling

PCH_LVDS; > - } else { > - 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_

Re: [Intel-gfx] [PATCH 33/43] drm/i915: Remove dev_priv argument from NEEDS_FORCE_WAKE

GEN6_WRITE_HEADER; \ > hsw_unclaimed_reg_debug(dev_priv, reg, false, true); \ > - if (!SKL_NEEDS_FORCE_WAKE((dev_priv), (reg)) || \ > + if (!SKL_NEEDS_FORCE_WAKE(reg) || \ > is_gen9_shadowed(dev_priv, reg)) \ > fw_engine = 0; \ > else if (FORCEWAKE_GEN9_RENDER_RANGE_OFFSET(reg)) \ > Reviewed-by: Jesse Barnes <jbar...@virtuousgeek.org> ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 7/9] drm/i915: add fences to the request struct

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

Re: [Intel-gfx] [PATCH 6/9] drm/i915: driver based PASID handling

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

Re: [Intel-gfx] [PATCH] drm/i915: Pin the ifbdev for the info->system_base GGTT mmapping

t; The effect is most pronounced across 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 <ch...@chris-wilson.co.uk> >> Cc: "Goel, Ak

Re: [Intel-gfx] [PATCH 3/7] drm/i915: don't allocate fbcon from stolen memory if it's too big

't use it 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) >

Re: [Intel-gfx] [PATCH 6/9] drm/i915: driver based PASID handling

On 10/07/2015 06:00 AM, David Woodhouse wrote: > On Fri, 2015-09-04 at 09:59 -0700, Jesse Barnes wrote: >> + >> + ret = handle_mm_fault(mm, vma, address, >> + desc.wr_req ? FAULT_FLAG_WRITE : 0); >> +

  1   2   3   4   5   6   7   8   9   10   >