Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
接近 2 年 前同步成功

通知 170
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 15 8月, 2017 1 次提交
  3. 28 2月, 2017 1 次提交
  5. 19 1月, 2017 1 次提交
  7. 11 1月, 2017 1 次提交
  9. 03 11月, 2016 1 次提交
  11. 29 10月, 2016 5 次提交
  13. 14 10月, 2016 1 次提交
  15. 15 8月, 2016 1 次提交
  17. 05 8月, 2016 1 次提交
  19. 04 8月, 2016 1 次提交
  21. 03 8月, 2016 3 次提交
  23. 20 7月, 2016 1 次提交
  25. 05 7月, 2016 1 次提交
  27. 14 6月, 2016 1 次提交
    • A
      drm/i915:bxt: Enable Pooled EU support · 33e141ed
      由 arun.siluvery@linux.intel.com 提交于 
      This mode allows to assign EUs to pools which can process work collectively.
The command to enable this mode should be issued as part of context initialization.

The pooled mode is global, once enabled it has to stay the same across all
contexts until HW reset hence this is sent in auxiliary golden context batch.
Thanks to Mika for the preliminary review and comments.

v2: explain why this is enabled in golden context, use feature flag while
enabling the support (Chris)

v3: Include only kernel support as userspace support is not available yet.

User space clients need to know when the pooled EU feature is present
and enabled on the hardware so that they can adapt work submissions.
Create a new device info flag for this purpose.

Set has_pooled_eu to true in the Broxton static device info - Broxton
supports the feature in hardware and the driver will enable it by
default.

We need to add getparam ioctls to enable userspace to query availability of
this feature and to retrieve min. no of eus in a pool but we will expose
them once userspace support is available. Opensource users for this feature
are mesa, libva and beignet.

Beignet team is currently working on adding userspace support.

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v2)
Cc: Winiarski, Michal <michal.winiarski@intel.com>
Cc: Zou, Nanhai <nanhai.zou@intel.com>
Cc: Yang, Rong R <rong.r.yang@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Armin Reese <armin.c.reese@intel.com>
Cc: Tim Gore <tim.gore@intel.com>
Signed-off-by: NJeff McGee <jeff.mcgee@intel.com>
Signed-off-by: NArun Siluvery <arun.siluvery@linux.intel.com>
Reviewed-by: NMichał Winiarski <michal.winiarski@intel.com>
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      33e141ed
  29. 09 5月, 2016 1 次提交
  31. 28 4月, 2016 1 次提交
  33. 25 4月, 2016 1 次提交
  35. 16 3月, 2016 2 次提交
  37. 12 12月, 2015 1 次提交
    • D
      drm/i915: mark GEM object pages dirty when mapped & written by the CPU · 033908ae
      由 Dave Gordon 提交于 
      In various places, a single page of a (regular) GEM object is mapped into
CPU address space and updated. In each such case, either the page or the
the object should be marked dirty, to ensure that the modifications are
not discarded if the object is evicted under memory pressure.

The typical sequence is:
	va = kmap_atomic(i915_gem_object_get_page(obj, pageno));
	*(va+offset) = ...
	kunmap_atomic(va);

Here we introduce i915_gem_object_get_dirty_page(), which performs the
same operation as i915_gem_object_get_page() but with the side-effect
of marking the returned page dirty in the pagecache.  This will ensure
that if the object is subsequently evicted (due to memory pressure),
the changes are written to backing store rather than discarded.

Note that it works only for regular (shmfs-backed) GEM objects, but (at
least for now) those are the only ones that are updated in this way --
the objects in question are contexts and batchbuffers, which are always
shmfs-backed.

Separate patches deal with the cases where whole objects are (or may
be) dirtied.

v3: Mark two more pages dirty in the page-boundary-crossing
    cases of the execbuffer relocation code [Chris Wilson]
Signed-off-by: NDave Gordon <david.s.gordon@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1449773486-30822-2-git-send-email-david.s.gordon@intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      033908ae
  39. 21 7月, 2015 2 次提交
    • A
      drm/i915: Add provision to extend Golden context batch · 84e81020
      由 Arun Siluvery 提交于 
      The Golden batch carries 3D state at the beginning so that HW starts with
a known state. It is carried as a binary blob which is auto-generated from
source. The idea was it would be easier to maintain and keep the complexity
out of the kernel which makes sense as we don't really touch it. However if
you really need to update it then you need to update generator source and
keep the binary blob in sync with it.

There is a need to patch this in bxt to send one additional command to enable
a feature. A solution was to patch the binary data with some additional
data structures (included as part of auto-generator source) but it was
unnecessarily complicated.

Chris suggested the idea of having a secondary batch and execute two batch
buffers. It has clear advantages as we needn't touch the base golden batch,
can customize secondary/auxiliary batch depending on Gen and can be carried
in the driver with no dependencies.

This patch adds support for this auxiliary batch which is inserted at the
end of golden batch and is completely independent from it. Thanks to Mika
for the preliminary review.

v2: Strictly conform to the batch size requirements to cover Gen2 and
add comments to clarify overflow check in macro (Chris, Mika).

v3: aux_batch_offset was declared as u64, change it to u32 (Chris)
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Armin Reese <armin.c.reese@intel.com>
Signed-off-by: NArun Siluvery <arun.siluvery@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      84e81020
    • M
      drm/i915: Do kunmap if renderstate parsing fails · dd72bde0
      由 Mika Kuoppala 提交于 
      Kunmap the renderstate page on error path.
Reviewed-by: NArun Siluvery <arun.siluvery@linux.intel.com>
Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      dd72bde0
  41. 23 6月, 2015 7 次提交
  43. 03 12月, 2014 1 次提交
  45. 04 11月, 2014 1 次提交
  47. 03 9月, 2014 1 次提交
    • O
      drm/i915/bdw: Render state init for Execlists · 564ddb2f
      由 Oscar Mateo 提交于 
      The batchbuffer that sets the render context state is submitted
in a different way, and from different places.

We needed to make both the render state preparation and free functions
outside accesible, and namespace accordingly. This mess is so that all
LR, LRC and Execlists functionality can go together in intel_lrc.c: we
can fix all of this later on, once the interfaces are clear.

v2: Create a separate ctx->rcs_initialized for the Execlists case, as
suggested by Chris Wilson.
Signed-off-by: NOscar Mateo <oscar.mateo@intel.com>

v3: Setup ring status page in lr_context_deferred_create when the
default context is being created. This means that the render state
init for the default context is no longer a special case.  Execute
deferred creation of the default context at the end of
logical_ring_init to allow the render state commands to be submitted.
Fix style errors reported by checkpatch. Rebased.
Signed-off-by: NThomas Daniel <thomas.daniel@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      564ddb2f
  49. 22 7月, 2014 1 次提交
    • H
      drm/i915: fix freeze with blank screen booting highmem · 88b98287
      由 Hugh Dickins 提交于 
      x86_64 boots and displays fine, but booting x86_32 with CONFIG_HIGHMEM
has frozen with a blank screen throughout 3.16-rc on this ThinkPad T420s,
with i915 generation 6 graphics.

Fix 9d0a6fa6 ("drm/i915: add render state initialization"): kunmap()
takes struct page * argument, not virtual address.  Which the compiler
kindly points out, if you use the appropriate u32 *batch, instead of
silencing it with a void *.

Why did bisection lead decisively to nearby 229b0489 ("drm/i915:
add null render states for gen6, gen7 and gen8")?  Because the u32
deposited at that virtual address by the previous stub failed the
PageHighMem test, and so did no harm.
Signed-off-by: NHugh Dickins <hughd@google.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      88b98287
  51. 17 6月, 2014 1 次提交