>-Original Message-
>From: Kulkarni, Vandita
>Sent: Monday, March 25, 2019 4:57 PM
>To: intel-gfx@lists.freedesktop.org
>Cc: Nikula, Jani ; Shankar, Uma ;
>Chauhan, Madhav ; Deak, Imre
>; Syrjala, Ville ; Kulkarni,
>Vandita
>
>Subject: [v3 2/2] drm/i915/icl: Fix port disable sequence for
On Monday, March 25, 2019 3:58:59 AM PDT Chris Wilson wrote:
> iris currently uses two distinct GEM contexts to have distinct logical
> HW contexts for the compute and render pipelines. However, using two
> distinct GEM contexts implies that they are distinct timelines, yet as
> they are a single G
Hello Chris Wilson,
The patch f40a7b7558ef: "drm/i915: Initial selftests for exercising
eviction" from Feb 13, 2017, leads to the following static checker
warning:
drivers/gpu/drm/i915/selftests/i915_gem_evict.c:193 igt_overcommit()
warn: passing a valid pointer to 'PTR_ERR'
driv
The live_context() function returns error pointers. It never returns
NULL.
Fixes: 9c1477e83e62 ("drm/i915/selftests: Exercise adding requests to a full
GGTT")
Signed-off-by: Dan Carpenter
---
drivers/gpu/drm/i915/selftests/i915_gem_evict.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Hi Daniele,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on next-20190325]
[cannot apply to v5.1-rc2]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url
Hi Daniele,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on next-20190325]
[cannot apply to v5.1-rc2]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url
On Fri, 2019-03-22 at 07:06 +, Chris Wilson wrote:
> Quoting José Roberto de Souza (2019-03-22 00:42:59)
> > There is some kms_frontbuffer_tracking failures due FBC being
> > disabled with the reason "framebuffer not tiled or fenced".
> > Although the test is setting up everything correctly to
Em seg, 2019-03-25 às 14:49 -0700, Daniele Ceraolo Spurio escreveu:
> Save the HW capabilities to avoid having to jump back to dev_priv
> every time.
>
Reviewed-by: Paulo Zanoni
> Signed-off-by: Daniele Ceraolo Spurio
> Cc: Paulo Zanoni
> Cc: Chris Wilson
> ---
> drivers/gpu/drm/i915/i915_d
Em seg, 2019-03-25 às 14:49 -0700, Daniele Ceraolo Spurio escreveu:
> We have several cases where we don't have forcewake (older gens, GVT and
> planned display-only uncore), so, instead of checking every time against
> the various condition, save the info in a flag and use that.
>
> Note that thi
By the time skl_ddi_clock_get() is called - and thus
skl_calc_wrpll_link() - we've just got the hw state from the pll
registers. We don't need to read them again: we can rather reuse what
was cached in the dpll_hw_state.
v2: rename state variable to pll_state, make argument const in
skl_calc_w
Quoting Paulo Zanoni (2019-03-25 22:41:55)
> Em seg, 2019-03-25 às 14:49 -0700, Daniele Ceraolo Spurio escreveu:
> > diff --git a/drivers/gpu/drm/i915/intel_uncore.c
> > b/drivers/gpu/drm/i915/intel_uncore.c
> > index 1816eeae3ba9..3f74889c4212 100644
> > --- a/drivers/gpu/drm/i915/intel_uncore.c
Em seg, 2019-03-25 às 14:49 -0700, Daniele Ceraolo Spurio escreveu:
> They now work on uncore, so use raw_uncore_ prefix. Also move them to
> uncore.h
>
> Signed-off-by: Daniele Ceraolo Spurio
> Cc: Paulo Zanoni
> Cc: Chris Wilson
> ---
> drivers/gpu/drm/i915/i915_drv.h | 32 ++
Quoting Daniele Ceraolo Spurio (2019-03-25 21:49:40)
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
> b/drivers/gpu/drm/i915/intel_ringbuffer.h
> index a02c92dac5da..e58d6f04177b 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.h
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
> @@ -29
Quoting Daniele Ceraolo Spurio (2019-03-25 21:49:38)
> +static inline void intel_uncore_rmw_or_fw(struct intel_uncore *uncore,
> + i915_reg_t reg, u32 or_val)
> +{
> + intel_uncore_write_fw(uncore, reg,
> + intel_uncore_read_
A few advantages:
- Prepares us for the planned split of display uncore from GT uncore
- Improves our engine-centric view of the world in the engine code
and allows us to avoid jumping back to dev_priv.
- Allows us to wrap accesses to engine register in nice macros that
automatically pick th
The intel_uncore structure is the owner of register access, so
subclass the function to it.
While at it, use a local uncore var and switch to the new read/write
functions where it makes sense.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Paulo Zanoni
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i91
Remove a bit of pointer dancing in the reg access path.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Paulo Zanoni
Cc: Chris Wilson
---
drivers/gpu/drm/i915/intel_drv.h| 17 -
drivers/gpu/drm/i915/intel_uncore.c | 16 +---
drivers/gpu/drm/i915/intel_uncore.h | 3 ++
The intel_uncore structure is the owner of register access, so
subclass the function to it.
While at it, use a local uncore var and switch to the new read/write
functions where it makes sense.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Paulo Zanoni
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i91
The full read/write ops can now work on the intel_uncore struct.
Introduce intel_uncore_read/write functions working on intel_uncore
and switch the I915_READ/WRITE macro to internally call those.
v2: no change
v3: add intel_uncore_read/write functions (Chris), update commit msg
Signed-off-by: Dan
Save the HW capabilities to avoid having to jump back to dev_priv
every time.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Paulo Zanoni
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.c | 4 +-
drivers/gpu/drm/i915/intel_display.c | 2 +-
drivers/gpu/drm/i915/intel_han
Continuation of the crusade to make the uncore code self-contained.
The first few patches are mostly what's left of the previous series,
while the later ones swap dev_priv out in a few more places.
The last patch is a bit more aggressive and introduces some new
wrappers to read/write engine regist
They now work on uncore, so use raw_uncore_ prefix. Also move them to
uncore.h
Signed-off-by: Daniele Ceraolo Spurio
Cc: Paulo Zanoni
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h | 32 ++-
drivers/gpu/drm/i915/i915_vgpu.c| 6 ++--
drivers/gpu/drm/i915/intel_unc
The intel_uncore structure is the owner of FW, so subclass the
function to it.
While at it, use a local uncore var and switch to the new read/write
functions where it makes sense.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Paulo Zanoni
Cc: Chris Wilson
---
drivers/gpu/drm/i915/gvt/mmio_context
We have several cases where we don't have forcewake (older gens, GVT and
planned display-only uncore), so, instead of checking every time against
the various condition, save the info in a flag and use that.
Note that this patch also change the behavior for gen5 with vpgu
enabled, but this is not a
---
drivers/gpu/drm/drm_debugfs.c | 2 +-
drivers/gpu/drm/drm_drv.c | 12
drivers/gpu/drm/drm_prime.c | 2 +-
3 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index f8468eae0503..f7044ff82f9c 100644
-
From: Daniele Ceraolo Spurio
We're already updating the engine_mask to reflect what's in the HW, so
we can just get the info from there. A couple of macros have been added
to facilitate this.
v2: Appease checkpatch
Suggested-by: Chris Wilson
Signed-off-by: Daniele Ceraolo Spurio
Cc: Chris Wil
== Series Details ==
Series: drm: connector firmware nodes
URL : https://patchwork.freedesktop.org/series/58531/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5810_full -> Patchwork_12592_full
Summary
---
**FAILURE**
On Fri, 2019-03-22 at 15:14 +0200, Ville Syrjälä wrote:
> On Thu, Mar 21, 2019 at 02:44:31PM -0700, Radhakrishna Sripada wrote:
> > Fixes the clock-gating issue when pipe scaling is enabled.
> > (Lineage #2006604312)
> >
> > V2: Fix typo in headline(Chris)
> > Handle the non double buffered na
On Fri, 22 Mar 2019 09:29:58 +0100, Chris Wilson
wrote:
Quoting Daniele Ceraolo Spurio (2019-03-22 00:24:31)
We're already updating the engine_mask to reflect what's in the HW, so
we can just get the info from there. A couple of macros have been added
to facilitate this.
Suggested-by: Chris
On 13/11/2018 22:28, Jani Nikula wrote:
On Tue, 13 Nov 2018, Tvrtko Ursulin wrote:
On 13/11/2018 11:40, Jani Nikula wrote:
On Mon, 12 Nov 2018, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Introduce subplatform mask to eliminate throughout the code devid checking
sprinkle, mostly courtesy o
From: Tvrtko Ursulin
After the removal of engine global seqnos and the corresponding
intel_engine_notify tracepoints the script needs to be adjusted to cope
with the new state of things.
To keep working it switches over using the dma_fence:dma_fence_signaled:
tracepoint and keeps one extra inter
On Tue, Mar 19, 2019 at 02:14:18PM +0530, Uma Shankar wrote:
> Add register definitions for ICL Plane Degamma.
>
> Signed-off-by: Uma Shankar
Haven't reviewed the series in detail yet, just a couple drive-by
comment below.
> ---
> drivers/gpu/drm/i915/i915_reg.h | 42
> +++
On 3/25/2019 6:22 PM, Tvrtko Ursulin wrote:
Hi Toni,
On 24/03/2019 13:02, Ye, Tony wrote:
The kernel was designed for Gen11 and the author didn't guarantee it
could work on APL. And the binary was built with iga64 with "-p=11"
option. If you try to build it with "-p=9" you will get "error:
On Fri, 2019-03-22 at 19:42 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Looks like EDID_QUIRK_FIRST_DETAILED_PREFERRED never did anything.
> Its counterpart in f86EdidModes.c is properly hooked up but somehow
> that functionality was lost when it was copied into the kernel.
>
> The con
== Series Details ==
Series: Revert "drm/i915: Introduce private PAT management" (rev4)
URL : https://patchwork.freedesktop.org/series/58421/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: Revert "drm/i915: Introduce private PAT management"
-drivers/gp
== Series Details ==
Series: Revert "drm/i915: Introduce private PAT management" (rev4)
URL : https://patchwork.freedesktop.org/series/58421/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
6d96174da189 Revert "drm/i915: Introduce private PAT management"
-:277: WARNING:LONG_LINE_
== Series Details ==
Series: Revert "drm/i915: Introduce private PAT management" (rev4)
URL : https://patchwork.freedesktop.org/series/58421/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5811 -> Patchwork_12593
Summary
---
== Series Details ==
Series: drm: connector firmware nodes
URL : https://patchwork.freedesktop.org/series/58531/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5810 -> Patchwork_12592
Summary
---
**SUCCESS**
No reg
On Fri, 22 Mar 2019, Jani Nikula wrote:
> Iterate over child devices instead of ports in parse_ddi_ports() to
> initialize dri_port_info. We'll eventually need to decide some stuff
> based on the child device order, which may be different from the port
> order.
>
> As a bonus, this allows better a
If the system firmware supplies nodes that represent the connectors,
they need to be associated with the connector entries.
ACPI tables at least always supply a device node for every connector
on integrated video hardware - this is explained in ACPI
specification's ch. "Appendix B Video Extension"
Hi,
If the system firmware supplies device nodes representing the
display connectors on integrated video hardware, those nodes should
probable always be associated with the display connector entries
(struct drm_connector).
With the USB Type-C DisplayPort alt mode, we will need a way to inform
the
On Intel platforms we know that the ACPI connector device
node order will follow the order the driver (i915) decides.
The decision is made using the custom Intel ACPI OpRegion
(intel_opregion.c), though the driver does not actually know
that the values it sends to ACPI there are used for
associatin
== Series Details ==
Series: Revert "drm/i915: Introduce private PAT management" (rev3)
URL : https://patchwork.freedesktop.org/series/58421/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5810 -> Patchwork_12591
Summary
---
Hi Dave & Daniel,
First batch of features for 5.2, tagged last week.
Most notably there are a lot of Icelake fixes that finally lead to removal
of alpha_support protection for it. We're also adding Cometlake PCI IDs
(Gen9 ~= Coffeelake), so those platforms should be supported.
Then we have HDCP
== Series Details ==
Series: Revert "drm/i915: Introduce private PAT management" (rev3)
URL : https://patchwork.freedesktop.org/series/58421/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: Revert "drm/i915: Introduce private PAT management"
-drivers/gp
== Series Details ==
Series: Revert "drm/i915: Introduce private PAT management" (rev3)
URL : https://patchwork.freedesktop.org/series/58421/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
ba742ee0d434 Revert "drm/i915: Introduce private PAT management"
-:277: WARNING:LONG_LINE_
== Series Details ==
Series: series starting with [v3,1/2] drm/i915/icl: Ungate ddi clocks before IO
enable
URL : https://patchwork.freedesktop.org/series/58527/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5810 -> Patchwork_12590
This reverts commit 4395890a48551982549d222d1923e2833dac47cf.
It's been over a year since this was merged, and the actual users of
intel_ppat_get / intel_ppat_put never materialized.
Time to remove it!
v2: Unbreak suspend (Chris)
Fixes: 4395890a4855 ("drm/i915: Introduce private PAT management"
On Sun, Mar 24, 2019 at 01:47:08PM +, Chris Wilson wrote:
> Quoting Michał Winiarski (2019-03-22 16:20:37)
> > static int gen8_gmch_probe(struct i915_ggtt *ggtt)
> > @@ -3517,14 +3327,6 @@ void i915_gem_restore_gtt_mappings(struct
> > drm_i915_private *dev_priv)
> > i915_ggtt_invalida
Re-enable clock gating of DDI clocks.
v2: Fix the default ddi clk state for mipi-dsi (Imre)
Fixes: 1026bea00381 (drm/i915/icl: Ungate DSI clocks)
Signed-off-by: Vandita Kulkarni
---
drivers/gpu/drm/i915/icl_dsi.c | 2 +-
drivers/gpu/drm/i915/intel_ddi.c | 6 +++---
2 files changed, 4 insertio
IO enable sequencing needs ddi clocks enabled.
These clocks will be gated at a later point in
the enable sequence.
v2: Fix the commit header (Uma)
v3: Remove the redundant read (Ville)
Signed-off-by: Vandita Kulkarni
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/icl_dsi.c | 6 ++
1 fil
The kms_flip test relies on VBlank support, and this situation may
exclude some virtual drivers to take advantage of this set of tests.
This commit adds a mechanism that checks if a module has VBlank. If the
target module has VBlank support, kms_flip will run all the VBlank
tests; otherwise, the VB
Hi Daniel, Dave,
Here is a PR for drm-misc-fixes.
Thanks!
Maxime
drm-misc-fixes-2019-03-25:
- A bunch of fixes to cleanup path in meson
- Fix the DMT TDMS clock filtering on meson
- Fix an issue with NV12 buffers on rockchip when scaling is active
- Fix a couple of use-after-free
The following c
Hi Chris,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v5.1-rc2 next-20190325]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux
iris currently uses two distinct GEM contexts to have distinct logical
HW contexts for the compute and render pipelines. However, using two
distinct GEM contexts implies that they are distinct timelines, yet as
they are a single GL context that implies they belong to a single
timeline from the clie
For use in GPU recovery and pipeline construction.
---
include/drm-uapi/i915_drm.h | 389 +---
1 file changed, 317 insertions(+), 72 deletions(-)
diff --git a/include/drm-uapi/i915_drm.h b/include/drm-uapi/i915_drm.h
index d2792ab3640..59baacd265d 100644
--- a/incl
We want to opt out of the automatic GPU recovery and replay performed by
the kernel of a guilty context after a GPU reset as our incremental
batch construction very often implies that subsequent batches are a GPU
reset are incomplete and will trigger fresh GPU hangs. As we are aware
of how we need
On 25/03/2019 09:03, Chris Wilson wrote:
The headline change is the wholehearted decision to allow the user to
establish an ctx->engines mapping of [rcs0, rcs0] to mean two logically
distinct pipelines to the same engine. An example of this use case is in
iris which constructs two GEM contexts i
On Thu, Mar 21, 2019 at 6:08 PM Sean Paul wrote:
>
>
> Hi Da.*,
> Here's the first 5.2 PR from -misc. There's a bit of everything in the PR,
> enjoy!
Pulled, thanks.
-Daniel
> drm-misc-next-2019-03-21:
> drm-misc-next for 5.2:
>
> UAPI Changes:
> - Add Colorspace connector property (Uma)
> - fou
Ping?
On 26/02/2019 14:29, Lionel Landwerlin wrote:
Hi all,
This third iteration adds an i915 perf revision number through
getparam so that application can more easily find out what feature of
i915-perf are available.
The patches containing uAPI updates have been updated to indicate what
versi
Hi Toni,
On 24/03/2019 13:02, Ye, Tony wrote:
The kernel was design for Gen11 and the author didn't guarantee it could
work on APL. And the binary was built with iga64 with "-p=11" option. If
you try to build it with "-p=9" you will get "error: NoPreempt not
supported on given platform".
As t
On 22/03/2019 23:41, Carlos Santa wrote:
From: Michel Thierry
*** General ***
Watchdog timeout (or "media engine reset") is a feature that allows
userland applications to enable hang detection on individual batch buffers.
The detection mechanism itself is mostly bound to the hardware and the
== Series Details ==
Series: drm/i915: Fix an error code in i915_gem_context_open()
URL : https://patchwork.freedesktop.org/series/58518/
State : failure
== Summary ==
Applying: drm/i915: Fix an error code in i915_gem_context_open()
Using index info to reconstruct a base tree...
M driver
On Mon, 25 Mar 2019, "Sharma, Swati2" wrote:
> On 20-Mar-19 6:11 PM, Jani Nikula wrote:
>> On Wed, 20 Mar 2019, "Sharma, Swati2" wrote:
>>> On 15-Mar-19 3:17 PM, Nikula, Jani wrote:
On Fri, 15 Mar 2019, swati2.sha...@intel.com wrote:
> From: Swati Sharma
>
> Added state checker
On Mon, 25 Mar 2019, "Sharma, Swati2" wrote:
> On 20-Mar-19 6:11 PM, Jani Nikula wrote:
>> On Wed, 20 Mar 2019, "Sharma, Swati2" wrote:
>>> On 15-Mar-19 3:17 PM, Nikula, Jani wrote:
On Fri, 15 Mar 2019, swati2.sha...@intel.com wrote:
> From: Swati Sharma
>
> Added state checker
== Series Details ==
Series: series starting with [01/22] drm/i915: Report the correct errno from
i915_gem_context_open()
URL : https://patchwork.freedesktop.org/series/58517/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5808 -> Patchwork_12588
==
Quoting Dan Carpenter (2019-03-25 09:23:49)
> If gem_context_register() fails then "ctx" is a valid pointer, not an
> error pointer. We should just return "err".
>
> Fixes: 3aa9945a528e ("drm/i915: Separate GEM context construction and
> registration to userspace")
> Signed-off-by: Dan Carpenter
== Series Details ==
Series: series starting with [01/22] drm/i915: Report the correct errno from
i915_gem_context_open()
URL : https://patchwork.freedesktop.org/series/58517/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Report the correct
On 25/03/2019 09:03, Chris Wilson wrote:
Fixup the errno as we adjusted the error path to receive the errno and
not computed itself from ERR_PTR(ctx) anymore.
drivers/gpu/drm/i915/i915_gem_context.c:793 i915_gem_context_open() warn:
passing a valid pointer to 'PTR_ERR'
Fixes: 3aa9945a528e ("d
If gem_context_register() fails then "ctx" is a valid pointer, not an
error pointer. We should just return "err".
Fixes: 3aa9945a528e ("drm/i915: Separate GEM context construction and
registration to userspace")
Signed-off-by: Dan Carpenter
---
drivers/gpu/drm/i915/i915_gem_context.c | 2 +-
1
== Series Details ==
Series: series starting with [01/22] drm/i915: Report the correct errno from
i915_gem_context_open()
URL : https://patchwork.freedesktop.org/series/58517/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
a06b0f01cad0 drm/i915: Report the correct errno from i9
== Series Details ==
Series: series starting with [v2] dma-fence: Propagate errors to
dma-fence-array container (rev2)
URL : https://patchwork.freedesktop.org/series/58460/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5808 -> Patchwork_12587
=
Some users require that when a master batch is executed on one particular
engine, a companion batch is run simultaneously on a specific slave
engine. For this purpose, we introduce virtual engine bonding, allowing
maps of master:slaves to be constructed to constrain which physical
engines a virtual
Split out the powermanagement portion (GT wakeref, suspend/resume) of
GEM from i915_gem.c into its own file.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/Makefile | 2 +
drivers/gpu/drm/i915/i915_gem.c | 335 +
drivers/gpu/drm/i915/i915_gem
Circumvent the dance we currently perform to find the preempt_client and
lookup its HW context for this engine, as we know we have already pinned
the preempt_context on the engine.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_guc_submission.c | 2 +-
1 file changed, 1 insertion(+),
Having transitioned GEM over to using intel_context as its primary means
of tracking the GEM context and engine combined and using
i915_request_create(), we can move the older i915_request_alloc()
helper function into selftests/
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/Makefile
We want to pass in a intel_context into intel_context_pin() and that
requires us to first be able to lookup the intel_context!
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gvt/scheduler.c | 7 +++-
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 11 +--
drivers/gpu/drm/i915/i915_
In order to separate the reservation phase of building a request from
its emission phase, we need to pull some of the request alloc activities
from deep inside i915_request to the surface, GEM_EXECBUFFER.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 106 ++
If we introduce a new mutex for the exclusive use of GEM's runtime power
management, we can remove its requirement of holding the struct_mutex.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c | 9 +--
drivers/gpu/drm/i915/i915_drv.h | 3 +-
drivers/g
In the next patch, we require the engine vfuncs setup prior to
initialising the pinned kernel contexts, so split the vfunc setup from
the engine initialisation and call it earlier.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 6 +
drivers/gpu/drm/i915/intel_engine
There is a desire to split a task onto two engines and have them run at
the same time, e.g. scanline interleaving to spread the workload evenly.
Through the use of the out-fence from the first execbuf, we can
coordinate secondary execbuf to only become ready simultaneously with
the first, so that w
Simply the setup slightly for the sseu selftests to use the actual
kernel_context.
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/selftests/i915_gem_context.c | 17 -
1 file changed, 4 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_contex
OUr eventual goal is to rid request construction of struct_mutex, with
the short term step of lifting the struct_mutex requirements into the
higher levels (i.e. the caller must ensure that the context is already
pinned into the GTT). In this patch, we pin GVT's shadow context upon
allocation and so
Start acquiring the logical intel_context and using that as our primary
means for request allocation. This is the initial step to allow us to
avoid requiring struct_mutex for request allocation along the
perma-pinned kernel context, but it also provides a foundation for
breaking up the complex requ
Fixup the errno as we adjusted the error path to receive the errno and
not computed itself from ERR_PTR(ctx) anymore.
drivers/gpu/drm/i915/i915_gem_context.c:793 i915_gem_context_open() warn:
passing a valid pointer to 'PTR_ERR'
Fixes: 3aa9945a528e ("drm/i915: Separate GEM context construction a
We switched to a tree of per-engine HW context to accommodate the
introduction of virtual engines. However, we plan to also support
multiple instances of the same engine within the GEM context, defeating
our use of the engine as a key to looking up the HW context. Just
allocate a logical per-engine
In the next patch, we will want to configure the slave request
depending on which physical engine the master request is executed on.
For this, we introduce a callback from the execute fence to convey this
information.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i
Over the last few years, we have debated how to extend the user API to
support an increase in the number of engines, that may be sparse and
even be heterogeneous within a class (not all video decoders created
equal). We settled on using (class, instance) tuples to identify a
specific engine, with a
We want to use intel_engine_mask_t inside i915_request.h, which means
extracting it from the general header file mess and placing it inside a
types.h. A knock on effect is that the compiler wants to warn about
type-contraction of ALL_ENGINES into intel_engine_maskt_t, so prepare
for the worst.
v2:
Having allowed the user to define a set of engines that they will want
to only use, we go one step further and allow them to bind those engines
into a single virtual instance. Submitting a batch to the virtual engine
will then forward it to any one of the set in a manner as best to
distribute load.
The headline change is the wholehearted decision to allow the user to
establish an ctx->engines mapping of [rcs0, rcs0] to mean two logically
distinct pipelines to the same engine. An example of this use case is in
iris which constructs two GEM contexts in order to have two distinct
logical ccontex
Transition from calling the lower level intel_runtime_pm functions to
using the GEM runtime_pm functions (i915_gem_unpark, i915_gem_park) now
that they are decoupled from struct_mutex. This has the small advantage
of reducing our overhead for request emission and ensuring that GEM
state is locked a
Move the intel_context_instance() to the caller so that we can decouple
ourselves from one context instance per engine.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_context.c | 88 +++
drivers/gpu/drm/i915/intel_context.c | 26 --
drivers/gpu/d
A usecase arose out of handling context recovery in mesa, whereby they
wish to recreate a context with fresh logical state but preserving all
other details of the original. Currently, they create a new context and
iterate over which bits they want to copy across, but it would much more
convenient i
Combine the (i915_gem_context, intel_engine) into a single parameter,
the intel_context for convenience and later simplification.
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/selftests/i915_gem_context.c | 64 +++
1 file changed, 36 insertions(+), 28 deletions(-)
diff --git
On Mon, Mar 18, 2019 at 12:06:13AM +0100, Ahmed S. Darwish wrote:
>
> => Now that the dust has settled, here's a summary of this huge
>50-email thread (thanks Daniel, Noralf, John, everyone!).
>
> => Parts of this document are a direct rewording of Daniel's replies,
>so I took the liberty
On 20-Mar-19 6:11 PM, Jani Nikula wrote:
On Wed, 20 Mar 2019, "Sharma, Swati2" wrote:
On 15-Mar-19 3:17 PM, Nikula, Jani wrote:
On Fri, 15 Mar 2019, swati2.sha...@intel.com wrote:
From: Swati Sharma
Added state checker to validate gamma_lut values. This
reads hardware state, and compares th
When one of the array of fences is signaled, propagate its errors to the
parent fence-array (keeping the first error to be raised).
v2: Opencode cmpxchg_local to avoid compiler freakout.
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Gustavo Padovan
---
drivers/dma-buf/dma-fence-array.c | 1
On Fri, Mar 22, 2019 at 03:37:47PM -0700, Lucas De Marchi wrote:
> By the time skl_ddi_clock_get() is called - and thus
> skl_calc_wrpll_link() - we've just got the hw state from the pll
> registers. We don't need to read them again: we can rather reuse what
> was cached in the dpll_hw_state.
>
>
On Sat, Mar 23, 2019 at 01:55:34AM +0200, Ville Syrjälä wrote:
> On Fri, Mar 22, 2019 at 09:08:35PM +, Chris Wilson wrote:
> > Quoting Ville Syrjala (2019-03-22 18:08:03)
> > > From: Ville Syrjälä
> > >
> > > The AGPBUSY thing doesn't work on i945gm anymore. This means
> > > the gmch is incap
1 - 100 of 101 matches
Mail list logo
