Quoting Yaodong Li (2018-03-23 19:33:15)
> As I said, I agree that we would likely solve the enable_guc=1 then
> enable_guc=3 case with these changes which I think this the the only benefit
> that we can get from the starting from the top way.
> But my point is just like the from the bottom way, yo
On Thu, Mar 22, 2018 at 07:40:03PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We want to get rid of plane->fb on atomic drivers. Stop looking at it.
Would it be more precise to use "plane->crtc" in both subject and commit
log? Other than that:
Acked-by: Shawn Guo
>
> v2: Use old_
Quoting Matt Roper (2018-03-23 17:46:16)
> On Fri, Mar 23, 2018 at 02:15:38PM +0200, Joonas Lahtinen wrote:
> > Quoting Matt Roper (2018-03-17 02:08:57)
> > > This is the fourth iteration of the work previously posted here:
> > > (v1)
> > > https://lists.freedesktop.org/archives/intel-gfx/2018-J
On Mon, Mar 26, 2018 at 09:42:52AM +0300, Joonas Lahtinen wrote:
> Quoting Daniel Vetter (2018-03-23 18:39:04)
> > On Fri, Mar 23, 2018 at 06:22:46PM +0200, Jani Nikula wrote:
> > > There was some discussion on the dim-tools list about splitting the
> > > dri-devel list to drm core and drivers list
On Mon, 26 Mar 2018, Daniel Vetter wrote:
> And as mentioned I think dri-drivers isn't big enough to be
> sustainable on its own.
It certainly is big enough to be disruptive to my inbox, and I don't
seem to be alone.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
___
On Mon, Mar 26, 2018 at 10:00 AM, Jani Nikula wrote:
> On Mon, 26 Mar 2018, Daniel Vetter wrote:
>> And as mentioned I think dri-drivers isn't big enough to be
>> sustainable on its own.
>
> It certainly is big enough to be disruptive to my inbox, and I don't
> seem to be alone.
If you want to m
We want to use some of the properties of the perf stream to program
the hardware in a later commit.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/i915_perf.c | 10 ++
2 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/driv
Hi,
This series is kind of an optimization we can make on Gen7.5 for
dealing with the perf stream in the case where we measure workloads at
boundaries of the command stream (much like what i965
INTEL_performance_query does in Mesa).
Along the way to implement this, quite a few cleanups manifested
We've been a bit loose about this opening parameter. We should only
add the flag for writing OA reports when the value of this parameter
is != 0.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_perf.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gp
In commit d79651522e89c "drm/i915: Enable i915 perf stream for Haswell
OA unit" the enable/disable vfunc hadn't appear yet and the same
function would deal with enabling/disabling the OA unit.
This was split later on for gen8 but the gen7 retained some code that
isn't actually useful anymore.
Sig
We initialize the OA buffer everytime we enable the OA unit (first call in
gen[78]_oa_enable), so we don't need to initialize when preparing the metric
set.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_drv.h | 17 -
drivers/gpu/drm/i915/i915_perf.c | 7 ++-
This was added by mistake in commit 28964cf25e "drm/i915/perf: disable NOA
logic when not used".
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_perf.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 86c1
If 2 processes race to open the perf stream, it's possible that one of them
will see that OA buffer has already been allocated, while a previous process
is still finishing to reprogram the hardware (on gen8+).
The opening sequence has been reworked a few times and we probably lost
track of the ord
The way our hardware is designed doesn't seem to let us use the
MI_RECORD_PERF_COUNT command without setting up a circular buffer.
In the case where the user didn't request OA reports to be available
through the i915 perf stream, we can set the OA buffer to the minimum
size to avoid consuming memo
This will allow use to program the hardware based on the stream's
properties in a later commit.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_drv.h | 3 ++-
drivers/gpu/drm/i915/i915_perf.c | 12 +++-
2 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/drive
We want to allow a user to configure the OA hardware so that
MI_RECORD_PERF_COUNT is functional but without having to deal with the
OA buffer.
This is an interesting optimization we can apply on Gen7.5 has the OA
unit perfectly clocks off if you've configured it to filter on a
particular context i
We had a generic field name used across 2 registers but it feels like
it's clearer we make it obvious what register this field belongs to.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_perf.c | 7 ---
drivers/gpu/drm/i915/i915_reg.h | 6 +++---
2 files changed, 7 insertions
This will make it easier to spot issues related to config
creation/usage.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_perf.c | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf
Here is pull request with patch usage:
https://github.com/intel/compute-runtime/pull/29
This patch is required to control data port coherency depending on incoming
workload into OpenCL API (fine-grain SVM requirement).
-Original Message-
From: Joonas Lahtinen [mailto:joonas.lahti...@li
== Series Details ==
Series: drm/i915/perf: optimize perf stream usage on Gen7.5
URL : https://patchwork.freedesktop.org/series/40656/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
9b2b2bce30f9 drm/i915/perf: pass stream to enable metric set vfuncs
2c159dc9b427 drm/i915/perf: c
== Series Details ==
Series: drm/i915/perf: optimize perf stream usage on Gen7.5
URL : https://patchwork.freedesktop.org/series/40656/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm/i915/perf: pass stream to enable metric set vfuncs
Okay!
Commit: drm/i915/perf: check th
On Fri, Mar 23, 2018 at 01:00:35PM -0700, Yaodong Li wrote:
> On 03/23/2018 05:34 AM, Michał Winiarski wrote:
> > We need GuC to load HuC, but it's also possible for GuC to operate on
> > its own. We don't know what the size of HuC FW may be, so, not wanting
> > to make any platform-specific hardco
On 3/23/2018 8:44 PM, Michal Wajdeczko wrote:
In function gem_init_hw() we are calling uc_init_hw() but in case
of error later in function, we missed to call matching uc_fini_hw()
Signed-off-by: Michal Wajdeczko
Cc: Sagar Arun Kamble
Cc: Chris Wilson
Looks good.
Reviewed-by: Sagar Arun Kam
== Series Details ==
Series: drm/i915/perf: optimize perf stream usage on Gen7.5
URL : https://patchwork.freedesktop.org/series/40656/
State : success
== Summary ==
Series 40656v1 drm/i915/perf: optimize perf stream usage on Gen7.5
https://patchwork.freedesktop.org/api/1.0/series/40656/revisio
On 3/23/2018 8:44 PM, Michal Wajdeczko wrote:
We should not leave GuC submission enabled after sanitize,
as we are going to reset all GuC/HuC hardware.
Signed-off-by: Michal Wajdeczko
Cc: Sagar Arun Kamble
Cc: Chris Wilson
Either we need now destroy the doorbells cleanly or remove the below
From: Tvrtko Ursulin
Realtime scheduling interferes with execlists submission (tasklet) so try
to simplify the PWM loop in a few ways:
* Drop RT.
* Longer batches for smaller systematic error.
* More truthful test duration calculation.
* Less clock queries.
* No self-adjust - instead just r
== Series Details ==
Series: drm/i915/perf: optimize perf stream usage on Gen7.5
URL : https://patchwork.freedesktop.org/series/40656/
State : failure
== Summary ==
Possible new issues:
Test perf:
Subgroup missing-sample-flags:
pass -> FAIL (shard-apl)
Quoting Tvrtko Ursulin (2018-03-26 11:57:58)
> * No self-adjust - instead just report the achieved cycle and let the
>parent check against it.
Sniff, I was rather proud of our achievement. I had it in mind as a
template for future autocalibration routines. Is it really useless
overengineering
On 3/23/2018 8:44 PM, Michal Wajdeczko wrote:
Today uc_fini_hw is subset of uc_sanitize, but remaining
code in sanitize function is also desired for uc_fini_hw.
Instead of duplicating the code, just call uc_sanitize,
but leave as separate function to maintain symmetry with
uc_init_hw.
Signed-o
Quoting Jeff McGee (2018-03-22 15:14:01)
> On Tue, Mar 20, 2018 at 05:17:34PM -0700, Jeff McGee wrote:
> > On Tue, Mar 20, 2018 at 12:18:48AM +, Chris Wilson wrote:
> > > Catch up with the inflight CSB events, after disabling the tasklet
> > > before deciding which request was truly guilty of h
On 26 March 2018 at 10:08, Lionel Landwerlin
wrote:
> In commit d79651522e89c "drm/i915: Enable i915 perf stream for Haswell
> OA unit" the enable/disable vfunc hadn't appear yet and the same
> function would deal with enabling/disabling the OA unit.
>
> This was split later on for gen8 but the ge
In preparation to more carefully handling incomplete preemption during
reset by execlists, we move the existing code wholesale to the backends
under a couple of new reset vfuncs.
Signed-off-by: Chris Wilson
Cc: Michał Winiarski
CC: Michel Thierry
Cc: Jeff McGee
Reviewed-by: Jeff McGee
---
dr
Following the discussion of how should the timer be controlled, I wired
up one option which ended up with passing control to the caller letting
us use the forced-preemption for interactive uses (delay by more than a
frame and you get a fast reset!) as well whatever userspace desires.
-Chris
__
EGL_NV_realtime_priority?
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_context.c | 22 ++
drivers/gpu/drm/i915/i915_gem_context.h | 13 +
drivers/gpu/drm/i915/i915_request.c | 8 ++--
drivers/gpu/drm/i915/intel_lrc.c| 2 +-
inclu
As a complement to inject_preempt_context(), follow up with the function
to handle its completion. This will be useful should we wish to extend
the duties of the preempt-context for execlists.
Signed-off-by: Chris Wilson
Cc: Jeff McGee
Cc: Michał Winiarski
Reviewed-by: Jeff McGee
---
drivers/
If the request is still waiting on external fences, it has not yet been
submitted to the HW queue and so we can forgo kicking the submission
tasklet when re-evaluating its priority.
This should have no impact other than reducing the number of tasklet
wakeups under signal heavy workloads (e.g. swit
Catch up with the inflight CSB events, after disabling the tasklet
before deciding which request was truly guilty of hanging the GPU.
Signed-off-by: Chris Wilson
Cc: Michał Winiarski
CC: Michel Thierry
Cc: Jeff McGee
---
drivers/gpu/drm/i915/intel_lrc.c | 140 ++---
Use a liberal timeout of 20ms to ensure that the rendering for an
interactive pageflip is started in a timely fashion, and that
user interaction is not blocked by GPU, or CPU, hogs. This is at the cost
of resetting whoever was blocking the preemption, likely leading to that
context/process being ba
The choice of preemption timeout is determined by the context from which
we trigger the preemption, as such allow the caller to specify the
desired timeout.
Effectively the other choice would be to use the shortest timeout along
the dependency chain. However, given that we would have already
trigg
Install a timer when trying to preempt on behalf of an important
context such that if the active context does not honour the preemption
request within the desired timeout, then we reset the GPU to allow the
important context to run.
(Open: should not the timer be started from receiving the high pr
When cancelling the requests and clearing out the ports following a
successful preemption completion, also clear the active flag. I had
assumed that all preemptions would be followed by an immediate dequeue
(preserving the active user flag), but under rare circumstances we may
be triggering a preem
In the next patch, we will make the execlists reset prepare callback
take into account preemption by flushing the context-switch handler.
This is not applicable to the GuC submission backend, so split the two
into their own backend callbacks.
Signed-off-by: Chris Wilson
Cc: Michał Winiarski
CC:
For the off-chance we have an interrupt posted and haven't processed the
CSB.
v2: Include tasklet enable/disable state for good measure.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_engine_cs.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/
On 26 March 2018 at 10:08, Lionel Landwerlin
wrote:
> If 2 processes race to open the perf stream, it's possible that one of them
> will see that OA buffer has already been allocated, while a previous process
> is still finishing to reprogram the hardware (on gen8+).
But we grab the perf.lock whi
On 26 March 2018 at 10:08, Lionel Landwerlin
wrote:
> This was added by mistake in commit 28964cf25e "drm/i915/perf: disable NOA
> logic when not used".
>
> Signed-off-by: Lionel Landwerlin
Reviewed-by: Matthew Auld
___
Intel-gfx mailing list
Intel-gfx
== Series Details ==
Series: series starting with [01/11] drm/i915/execlists: Avoid kicking the
submission too early for rescheduling
URL : https://patchwork.freedesktop.org/series/40665/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
6cd6e46a6275 drm/i915/execlists: Avoid kick
On 26 March 2018 at 10:08, Lionel Landwerlin
wrote:
> We had a generic field name used across 2 registers but it feels like
> it's clearer we make it obvious what register this field belongs to.
>
> Signed-off-by: Lionel Landwerlin
Reviewed-by: Matthew Auld
__
From: Ville Syrjälä
We want to get rid of plane->crtc on atomic drivers. Stop looking at it.
v2: Use old_state->crtc (Maarten)
v3: s/fb/crtc/ in commit message to actually match the patch (Shawn)
Cc: Shawn Guo
Cc: Maarten Lankhorst
Signed-off-by: Ville Syrjälä
Acked-by: Shawn Guo
---
drive
== Series Details ==
Series: series starting with [01/11] drm/i915/execlists: Avoid kicking the
submission too early for rescheduling
URL : https://patchwork.freedesktop.org/series/40665/
State : success
== Summary ==
Series 40665v1 series starting with [01/11] drm/i915/execlists: Avoid kicki
== Series Details ==
Series: drm: Eliminate plane->fb/crtc usage for atomic drivers (rev5)
URL : https://patchwork.freedesktop.org/series/40478/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
eec2e4920fa9 Revert "drm/atomic-helper: Fix leak in disable_all"
885b9185b11c drm/atomi
On 26/03/2018 12:17, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-03-26 11:57:58)
* No self-adjust - instead just report the achieved cycle and let the
parent check against it.
Sniff, I was rather proud of our achievement. I had it in mind as a
template for future autocalibration ro
== Series Details ==
Series: drm: Eliminate plane->fb/crtc usage for atomic drivers (rev5)
URL : https://patchwork.freedesktop.org/series/40478/
State : success
== Summary ==
Series 40478v5 drm: Eliminate plane->fb/crtc usage for atomic drivers
https://patchwork.freedesktop.org/api/1.0/series/
On 26/03/18 13:00, Matthew Auld wrote:
On 26 March 2018 at 10:08, Lionel Landwerlin
wrote:
If 2 processes race to open the perf stream, it's possible that one of them
will see that OA buffer has already been allocated, while a previous process
is still finishing to reprogram the hardware (on ge
On 26/03/18 10:08, Lionel Landwerlin wrote:
The way our hardware is designed doesn't seem to let us use the
MI_RECORD_PERF_COUNT command without setting up a circular buffer.
In the case where the user didn't request OA reports to be available
through the i915 perf stream, we can set the OA buff
On Fri, 23 Mar 2018, Paulo Zanoni wrote:
> Protect the macro parameters with parens in order to avoid priority
> issues on macro evaluation when the macro argument is not a single
> operand.
>
> This is not a problem today, but it could be in the future. I found
> this while reviewing a patch that
No significant changes from either context offsets, nor report
formats, nor register whitelist.
v2: Also drop slice/unslice clock ratio changes (Matt)
Signed-off-by: Lionel Landwerlin
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/Makefile | 3 +-
drivers/gpu/drm/i915/i915_oa_icl.c
Make the code a bit more concise.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_perf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 30444bb3aaa1..c27a5dfd44bd 100644
--- a/drivers/gp
Hi,
Adding a patch to the previous series to read the timestamp frequency
on ICL which is required for the perf support. I'm sure I saw this
patch written by somebody before but I can't find it back :( Please
manifest yourself if you did write that patch, it should be attributed
to its rightful au
We're missing this value which is needed for i915/perf support.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_reg.h | 6
drivers/gpu/drm/i915/intel_device_info.c | 48
2 files changed, 43 insertions(+), 11 deletions(-)
diff --git
On Mon, 26 Mar 2018, Patchwork wrote:
> == Series Details ==
>
> Series: Add NV12 support (rev4)
> URL : https://patchwork.freedesktop.org/series/39670/
> State : warning
>
> == Summary ==
>
> $ dim checkpatch origin/drm-tip
> 0503b1db737a drm/i915/skl+: rename skl_wm_values struct to skl_ddb_va
== Series Details ==
Series: drm/i915/perf: enable perf support on ICL (rev2)
URL : https://patchwork.freedesktop.org/series/39689/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
778ddd601367 drm/i915/icl: read timestamp frequency information
-:19: WARNING:LONG_LINE: line over 1
== Series Details ==
Series: drm/i915/perf: enable perf support on ICL (rev2)
URL : https://patchwork.freedesktop.org/series/39689/
State : success
== Summary ==
Series 39689v2 drm/i915/perf: enable perf support on ICL
https://patchwork.freedesktop.org/api/1.0/series/39689/revisions/2/mbox/
-
On Thu, 22 Mar 2018, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Interface to get GFX shmem usage stats per process
> URL : https://patchwork.freedesktop.org/series/40464/
> State : warning
>
> == Summary ==
>
> $ dim checkpatch origin/drm-tip
I don't mind the foo == NULL comp
== Series Details ==
Series: series starting with [01/11] drm/i915/execlists: Avoid kicking the
submission too early for rescheduling
URL : https://patchwork.freedesktop.org/series/40665/
State : failure
== Summary ==
Possible new issues:
Test gem_ctx_param:
Subgroup invalid-par
We've always been blatantly ignoring mmu_notifier.h:
* Invalidation of multiple concurrent ranges may be
* optionally permitted by the driver. Either way the
* establishment of sptes is forbidden in the range passed to
* invalidate_range_begin/end for the whole duration of the
* invalidate_ra
On Fri, Mar 23, 2018 at 02:47:23PM +, Michal Wajdeczko wrote:
> Instead of returning small data in response status dword,
> GuC may append longer data as response message payload.
> If caller provides response buffer, we will copy received
> data and use number of received data dwords as new su
== Series Details ==
Series: drm/i915/userptr: Wrap mmu_notifier inside its own rw_semaphore
URL : https://patchwork.freedesktop.org/series/40676/
State : success
== Summary ==
Series 40676v1 drm/i915/userptr: Wrap mmu_notifier inside its own rw_semaphore
https://patchwork.freedesktop.org/api/
On Mon, 26 Mar 2018, Michał Winiarski wrote:
> On Fri, Mar 23, 2018 at 02:47:23PM +, Michal Wajdeczko wrote:
>> Instead of returning small data in response status dword,
>> GuC may append longer data as response message payload.
>> If caller provides response buffer, we will copy received
>> d
== Series Details ==
Series: drm: Eliminate plane->fb/crtc usage for atomic drivers (rev5)
URL : https://patchwork.freedesktop.org/series/40478/
State : success
== Summary ==
Known issues:
Test kms_flip:
Subgroup 2x-dpms-vs-vblank-race:
fail -> PASS (s
On 26/03/2018 15:59, Chris Wilson wrote:
We've always been blatantly ignoring mmu_notifier.h:
* Invalidation of multiple concurrent ranges may be
* optionally permitted by the driver. Either way the
* establishment of sptes is forbidden in the range passed to
* invalidate_range_begin/en
== Series Details ==
Series: drm/i915/perf: enable perf support on ICL (rev2)
URL : https://patchwork.freedesktop.org/series/39689/
State : warning
== Summary ==
Possible new issues:
Test kms_cursor_legacy:
Subgroup short-flip-before-cursor-toggle:
pass -> S
WaProgramMgsrForCorrectSliceSpecificMmioReads dictate that before any MMIO
read into Slice/Subslice specific registers, MCR packet control
register(0xFDC) needs to be programmed to point to any enabled
slice/subslice pair. Otherwise, incorrect value will be returned.
However, that means each subse
L3Bank could be fused off in hardware for debug purpose, and it
is possible that subslice is enabled while its corresponding L3Bank pairs
are disabled. In such case, if MCR packet control register(0xFDC) is
programed to point to a disabled bank pair, a MMIO read into L3Bank range
will return 0 inst
Quoting Tvrtko Ursulin (2018-03-26 16:59:20)
>
> On 26/03/2018 15:59, Chris Wilson wrote:
> > We've always been blatantly ignoring mmu_notifier.h:
> >
> > * Invalidation of multiple concurrent ranges may be
> > * optionally permitted by the driver. Either way the
> > * establishment of spte
On Mon, 26 Mar 2018 17:29:32 +0200, Michał Winiarski
wrote:
On Fri, Mar 23, 2018 at 02:47:23PM +, Michal Wajdeczko wrote:
Instead of returning small data in response status dword,
GuC may append longer data as response message payload.
If caller provides response buffer, we will copy rec
On Mon, 26 Mar 2018 17:35:00 +0200, Jani Nikula
wrote:
On Mon, 26 Mar 2018, Michał Winiarski wrote:
On Fri, Mar 23, 2018 at 02:47:23PM +, Michal Wajdeczko wrote:
Instead of returning small data in response status dword,
GuC may append longer data as response message payload.
If caller
== Series Details ==
Series: drm/i915/userptr: Wrap mmu_notifier inside its own rw_semaphore
URL : https://patchwork.freedesktop.org/series/40676/
State : failure
== Summary ==
Possible new issues:
Test drv_module_reload:
Subgroup basic-no-display:
pass -> D
On 26/03/2018 17:12, Yunwei Zhang wrote:
WaProgramMgsrForCorrectSliceSpecificMmioReads dictate that before any MMIO
read into Slice/Subslice specific registers, MCR packet control
register(0xFDC) needs to be programmed to point to any enabled
slice/subslice pair. Otherwise, incorrect value will
On 26/03/2018 17:12, Yunwei Zhang wrote:
L3Bank could be fused off in hardware for debug purpose, and it
is possible that subslice is enabled while its corresponding L3Bank pairs
are disabled. In such case, if MCR packet control register(0xFDC) is
programed to point to a disabled bank pair, a MM
On 26/03/2018 12:50, Chris Wilson wrote:
EGL_NV_realtime_priority?
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_context.c | 22 ++
drivers/gpu/drm/i915/i915_gem_context.h | 13 +
drivers/gpu/drm/i915/i915_request.c | 8 ++--
driver
== Series Details ==
Series: series starting with [v4,1/2] drm/i915/cnl: Implement
WaProgramMgsrForCorrectSliceSpecificMmioReads (rev3)
URL : https://patchwork.freedesktop.org/series/40503/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
530daf66ff2f drm/i915/cnl: Implement
WaP
== Series Details ==
Series: series starting with [v4,1/2] drm/i915/cnl: Implement
WaProgramMgsrForCorrectSliceSpecificMmioReads (rev3)
URL : https://patchwork.freedesktop.org/series/40503/
State : success
== Summary ==
Series 40503v3 series starting with [v4,1/2] drm/i915/cnl: Implement
WaP
On Fri, Mar 23, 2018 at 11:53:47PM -, Patchwork wrote:
> == Series Details ==
>
> Series: drm/scdc-helper: Convert errors into debug messages
> URL : https://patchwork.freedesktop.org/series/40591/
> State : failure
>
> == Summary ==
>
> Possible new issues:
>
> Test kms_chv_cursor_f
== Series Details ==
Series: drm/i915: Reword warning for missing cases (rev2)
URL : https://patchwork.freedesktop.org/series/39821/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
82628817d5f1 drm/i915: Reword warning for missing cases
-:41: CHECK:MACRO_ARG_REUSE: Macro argument
On Sat, Mar 24, 2018 at 08:35:43AM +0530, Sharma, Shashank wrote:
> Reviewed-by: Shashank Sharma
Thanks. Pushed to drm-misc-next.
>
> Regards
> Shashank
> On 3/23/2018 11:55 PM, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Since we may attempt to reconfigure SCDC when the sink has alre
== Series Details ==
Series: drm/i915: Reword warning for missing cases (rev2)
URL : https://patchwork.freedesktop.org/series/39821/
State : success
== Summary ==
Series 39821v2 drm/i915: Reword warning for missing cases
https://patchwork.freedesktop.org/api/1.0/series/39821/revisions/2/mbox/
On 26 March 2018 at 10:08, Lionel Landwerlin
wrote:
> We want to use some of the properties of the perf stream to program
> the hardware in a later commit.
>
> Signed-off-by: Lionel Landwerlin
> ---
> drivers/gpu/drm/i915/i915_drv.h | 2 +-
> drivers/gpu/drm/i915/i915_perf.c | 10 ++
>
On 26 March 2018 at 10:08, Lionel Landwerlin
wrote:
> We've been a bit loose about this opening parameter. We should only
> add the flag for writing OA reports when the value of this parameter
> is != 0.
>
> Signed-off-by: Lionel Landwerlin
> ---
> drivers/gpu/drm/i915/i915_perf.c | 3 ++-
> 1 f
On 26 March 2018 at 20:21, Matthew Auld wrote:
> On 26 March 2018 at 10:08, Lionel Landwerlin
> wrote:
>> We want to use some of the properties of the perf stream to program
>> the hardware in a later commit.
>>
>> Signed-off-by: Lionel Landwerlin
>> ---
>> drivers/gpu/drm/i915/i915_drv.h | 2
On 26 March 2018 at 10:08, Lionel Landwerlin
wrote:
> This will allow use to program the hardware based on the stream's
> properties in a later commit.
I couldn't see where we need this? Regardless, operating on the stream
itself makes more sense to me.
>
> Signed-off-by: Lionel Landwerlin
> --
On Mon, Mar 26, 2018 at 05:28:58PM +0100, Chris Wilson wrote:
> Quoting Tvrtko Ursulin (2018-03-26 16:59:20)
> >
> > On 26/03/2018 15:59, Chris Wilson wrote:
> > > We've always been blatantly ignoring mmu_notifier.h:
> > >
> > > * Invalidation of multiple concurrent ranges may be
> > > * opti
On 26 March 2018 at 10:08, Lionel Landwerlin
wrote:
> This will make it easier to spot issues related to config
> creation/usage.
>
> Signed-off-by: Lionel Landwerlin
s/open perf open/perf open/ ?
Reviewed-by: Matthew Auld
___
Intel-gfx mailing list
GuC may return additional data in the response message.
Format and meaning of this data is action specific. We will
use this non-negative data as a new success return value.
Currently used actions don't return data that way yet.
v2: fix prohibited space after '~' (Michel)
update commit message
On platforms with CTB based GuC communications, we will handle
GuC events in a different way. Let's make event handler a virtual
function to allow easy switch between those variants.
Credits-to: Oscar Mateo
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Oscar Mateo
Reviewed-by:
With this series we will be able to receive more data from the Guc.
New Guc firmwares will be required to actually use that feature.
v4: respin series after 1/2 year break
v5: updated after review comments
Michal Wajdeczko (12):
drm/i915/guc: Add documentation for MMIO based communication
dr
Instead of returning small data in response status dword,
GuC may append longer data as response message payload.
If caller provides response buffer, we will copy received
data and use number of received data dwords as new success
return value. We will WARN if response from GuC does not
match calle
As we are going to extend our use of MMIO based communication,
try to explain its mechanics and update corresponding definitions.
v2: fix checkpatch MACRO_ARG_REUSE
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Sagar Arun Kamble
Cc: Kelvin Gardiner
Reviewed-by: Michel Thierry
This is a preparation step for the upcoming patches.
We already can return some small data decoded from the command
status, but we will need more in the future.
v2: add explicit response buf size
v3: squash with helper patch
Signed-off-by: Michal Wajdeczko
Cc: Oscar Mateo
Cc: Michel Thierry
Cc
We're using data encoded in the status MMIO as return value from send
function, but GuC may also write more data in remaining MMIO regs.
Let's copy content of these registers to the buffer provided by caller.
v2: new line (Michel)
v3: updated commit message
Signed-off-by: Michal Wajdeczko
Cc: Da
Signed-off-by: Michal Wajdeczko
---
drivers/gpu/drm/i915/i915_params.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_params.h
b/drivers/gpu/drm/i915/i915_params.h
index c963603..53037b5 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/
1 - 100 of 148 matches
Mail list logo
