On 05/31/2018 07:56 PM, Jani Nikula wrote:
Use intel_pch_type() also for mapping the no PCH case (PCH id 0) to
PCH_NONE to simplify code.
Also make sure that intel_pch_type() knows all the PCH ids returned by
intel_virt_detect_pch(). Loudly fail if this isn't the case; this
shouldn't happen
On 05/31/2018 07:56 PM, Jani Nikula wrote:
Virtualized non-PCH systems such as Broxton or Geminilake should use
PCH_NONE to indicate no PCH rather than PCH_NOP. The latter is a
specific case to indicate a PCH system without south display.
Reported-by: Colin Xu
Cc: Colin Xu
Reviewed-by: Ville
== Series Details ==
Series: drm/i915: Assert we idle in the kernel context
URL : https://patchwork.freedesktop.org/series/44052/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4268_full -> Patchwork_9165_full =
== Summary - WARNING ==
Minor unknown changes coming with
== Series Details ==
Series: drm/i915: Assert we idle in the kernel context
URL : https://patchwork.freedesktop.org/series/44052/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4268 -> Patchwork_9165 =
== Summary - SUCCESS ==
No regressions found.
External URL:
== Series Details ==
Series: drm/i915: Assert we idle in the kernel context
URL : https://patchwork.freedesktop.org/series/44052/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
3ee19b0cecdd drm/i915: Assert we idle in the kernel context
-:9: WARNING:COMMIT_LOG_LONG_LINE:
Now that we always switch to the kernel context upon idling, we can
make that assertion.
References: 4dfacb0bcbee ("drm/i915: Switch to kernel context before idling at
runtime")
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_gem.c | 31
== Series Details ==
Series: series starting with [01/11] drm/i915: Be irqsafe inside reset (rev3)
URL : https://patchwork.freedesktop.org/series/44041/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4268_full -> Patchwork_9163_full =
== Summary - FAILURE ==
Serious
Quoting Singh, Satyeshwar (2018-05-31 22:17:25)
> Hi Chris,
> Isn't this dependent upon the workload submitted to the GuC? Meaning we have
> one workload that refused to be preempted (really long shader for example)
> but it went away on its own. Other workloads that come in later are
>
Hi Chris,
Isn't this dependent upon the workload submitted to the GuC? Meaning we have
one workload that refused to be preempted (really long shader for example) but
it went away on its own. Other workloads that come in later are preemptible.
However, if we turn off preemption permanently, then
On 5/31/2018 1:47 PM, Chris Wilson wrote:
If we fail to tell the GuC to perform preemption, we get stuck
attempting to continually retry inject_preempt_context() until we
eventually timeout and reset the GPU (approximately emitting the same
warning 1000 times). Bail after the first failure, emit
== Series Details ==
Series: drm/i915/guc: Disable preemption if it fails
URL : https://patchwork.freedesktop.org/series/44045/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4268 -> Patchwork_9164 =
== Summary - WARNING ==
Minor unknown changes coming with
On 31/05/18 21:46, Michel Thierry wrote:
On 5/31/2018 12:56 PM, Lionel Landwerlin wrote:
One thing we didn't really understand about the OA report is that the
ContextID field (dword 2) is copy of the context descriptor (dword 1).
On Gen8->10 and without using GuC we didn't notice the issue
On 31/05/18 21:33, Michel Thierry wrote:
On 5/31/2018 12:56 PM, Lionel Landwerlin wrote:
We currently using GuC as a proxy to the hardware. When Guc is used in
such mode, it consumes the bit 20 of the hw_id to indicate that the
workload was submitted by proxy.
So far we probably haven't seen
== Series Details ==
Series: drm/i915/guc: Disable preemption if it fails
URL : https://patchwork.freedesktop.org/series/44045/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
815a8c14e179 drm/i915/guc: Disable preemption if it fails
-:15: WARNING:COMMIT_LOG_LONG_LINE: Possible
== Series Details ==
Series: series starting with [01/11] drm/i915: Be irqsafe inside reset (rev3)
URL : https://patchwork.freedesktop.org/series/44041/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4268 -> Patchwork_9163 =
== Summary - SUCCESS ==
No regressions found.
If we fail to tell the GuC to perform preemption, we get stuck
attempting to continually retry inject_preempt_context() until we
eventually timeout and reset the GPU (approximately emitting the same
warning 1000 times). Bail after the first failure, emit the WARN and
stop trying to do any further
On 5/31/2018 12:56 PM, Lionel Landwerlin wrote:
One thing we didn't really understand about the OA report is that the
ContextID field (dword 2) is copy of the context descriptor (dword 1).
On Gen8->10 and without using GuC we didn't notice the issue because
we only checked the 21bits of the
== Series Details ==
Series: series starting with [01/11] drm/i915: Be irqsafe inside reset (rev3)
URL : https://patchwork.freedesktop.org/series/44041/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
4f0a70687283 drm/i915: Be irqsafe inside reset
80c4b2f2bb87
== Series Details ==
Series: series starting with [01/11] drm/i915: Be irqsafe inside reset (rev2)
URL : https://patchwork.freedesktop.org/series/44041/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4268 -> Patchwork_9162 =
== Summary - SUCCESS ==
No regressions found.
On 5/31/2018 12:56 PM, Lionel Landwerlin wrote:
We currently using GuC as a proxy to the hardware. When Guc is used in
such mode, it consumes the bit 20 of the hw_id to indicate that the
workload was submitted by proxy.
So far we probably haven't seen the issue because we need to allocate
Currently the async submission backends (guc and execlists) hold a extra
reference to the requests being processed as they are not serialised with
request retirement. If we instead, prevent the request being dropped
from the engine timeline until after submission has finished processing
the
== Series Details ==
Series: series starting with [01/11] drm/i915: Be irqsafe inside reset (rev2)
URL : https://patchwork.freedesktop.org/series/44041/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
df8d5c388e8c drm/i915: Be irqsafe inside reset
827a42f841af
== Series Details ==
Series: drm/i915/perf: fix context filtering with GuC & ICL
URL : https://patchwork.freedesktop.org/series/44043/
State : failure
== Summary ==
Applying: drm/i915: drop one bit on the hw_id when using guc
error: sha1 information is lacking or useless
Back in commit 27af5eea54d1 ("drm/i915: Move execlists irq handler to a
bottom half"), we came to the conclusion that running our CSB processing
and ELSP submission from inside the irq handler was a bad idea. A really
bad idea as we could impose nearly 1s latency on other users of the
system, on
Hi all,
Here are a couple of fixes due to something that was overlooked on the
context id in the OA reports. I assumed it was constructed by the OA
unit but after discussion with HW people, the value turns out to be
copied from the context descriptor.
We had a test catching this in CI but only
One thing we didn't really understand about the OA report is that the
ContextID field (dword 2) is copy of the context descriptor (dword 1).
On Gen8->10 and without using GuC we didn't notice the issue because
we only checked the 21bits of the ContextID field in the OA reports
which matches
We currently using GuC as a proxy to the hardware. When Guc is used in
such mode, it consumes the bit 20 of the hw_id to indicate that the
workload was submitted by proxy.
So far we probably haven't seen the issue because we need to allocate
1048576+ contexts to hit this issue. Still, we should
== Series Details ==
Series: series starting with [01/11] drm/i915: Be irqsafe inside reset
URL : https://patchwork.freedesktop.org/series/44041/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4268 -> Patchwork_9160 =
== Summary - FAILURE ==
Serious unknown changes
Quoting Chris Wilson (2018-05-31 10:30:13)
> Quoting Ville Syrjala (2018-05-29 19:33:15)
> > From: Ville Syrjälä
> >
> > When we're trying to reinstate the colorkey we might fail on account of
> > the plane still being enable with a configuration that prevent the
> > use of colorkey. This
== Series Details ==
Series: series starting with [01/11] drm/i915: Be irqsafe inside reset
URL : https://patchwork.freedesktop.org/series/44041/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
1ba6410ddc51 drm/i915: Be irqsafe inside reset
14fd12cfeba8 drm/i915/execlists: Reset
Our long standing defense against a single client from flooding the
system with requests (causing mempressure and stalls across the whole
system) is to retire the old request on every allocation. (By retiring
the oldest, we try to keep returning requests back to the system in a
steady flow.) This
Following the removal of the last workarounds, the only CSB mmio access
is for the old vGPU interface. The mmio registers presented by vGPU do
not require forcewake and can be treated as ordinary volatile memory,
i.e. they behave just like the HWSP access just at a different location.
We can
In the next patch, we will begin processing the CSB from inside the
interrupt handler. This means that updating the execlists->port[] will
no longer be locked by the tasklet but by the engine->timeline.lock
instead. Pull dequeue and submit under the same lock for protection.
(An alternative,
In the next patch, we will move ownership of the fence reference to the
submission backend and will want to drop its final reference when
retiring it from the submission backend. We will also need a catch up
when parking the engine to cleanup any residual entries in the engine
timeline. In short,
As we want to be able to call i915_reset_engine and co from a softirq or
timer context, we need to be irqsafe at all timers. So we have to forgo
the simple spin_lock_irq for the full spin_lock_irqsave.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 6 --
1 file changed, 4
This is the same as the last posting, but hopefully now all the ground
work is inplace that we get through CI cleanly (gem_eio is the bane of
my existence).
The goal of the patchset is to eliminate high latencies caused by
execlists_submission_tasklet being deferred to ksoftirqd and scheduled
as
Currently the async submission backends (guc and execlists) hold a extra
reference to the requests being processed as they are not serialised with
request retirement. If we instead, prevent the request being dropped
from the engine timeline until after submission has finished processing
the
In the next patch, we will start to defer retiring the request from the
engine list if it is still active on the submission backend. To preserve
the semantics that after wait-for-idle completes the system is idle and
fully retired, we need to therefore wait for the backends to idle before
calling
We can avoid the mmio read of the CSB pointers after reset based on the
knowledge that the HW always start writing at entry 0 in the CSB buffer.
We need to reset our CSB head tracking after GPU reset (and on
sanitization after resume) so that we are expecting to read from entry
0.
Signed-off-by:
Back in commit 27af5eea54d1 ("drm/i915: Move execlists irq handler to a
bottom half"), we came to the conclusion that running our CSB processing
and ELSP submission from inside the irq handler was a bad idea. A really
bad idea as we could impose nearly 1s latency on other users of the
system, on
In the following patch, we will process the CSB interrupt under the
timeline.lock and not under the tasklet lock. This also means that we
will need to protect access to common variables such as
execlists->csb_head with the timeline.lock during reset.
Signed-off-by: Chris Wilson
---
In the next patch, we will process the CSB events directly from the CS
interrupt handler, being called for each interrupt. Hence, we will no
longer have the need for a loop until the has-interrupt bit is clear,
and in the meantime can remove that small optimisation.
Signed-off-by: Chris Wilson
Quoting Patchwork (2018-05-31 11:04:13)
> igt@gem_eio@suspend:
> shard-snb: PASS -> INCOMPLETE (fdo#105411) +1
I was concerned by this since gem_eio targets the code being changed. In
particular, I was concerned that this was bringing back the snb gem_eio
nightmare (where we
Quoting Chris Wilson (2018-05-31 19:13:32)
> Quoting Michal Wajdeczko (2018-05-28 18:16:18)
> > SOFT_SCRATCH(15) is used by GuC for sending MMIO GuC events to host and
> > those events are now handled by intel_guc_to_host_event_handler_mmio().
> >
> > We should not try to read it on MMIO action
Quoting Michal Wajdeczko (2018-05-28 18:16:18)
> SOFT_SCRATCH(15) is used by GuC for sending MMIO GuC events to host and
> those events are now handled by intel_guc_to_host_event_handler_mmio().
>
> We should not try to read it on MMIO action error as 1) we may be using
> different set of
== Series Details ==
Series: series starting with [1/4] drm/i915: fix guest virtual PCH detection on
non-PCH systems
URL : https://patchwork.freedesktop.org/series/44023/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4265_full -> Patchwork_9158_full =
== Summary - WARNING
glk is failing gem_tiled_blits which is very odd as it doesn't use
fencing and so the tiling is all internal to the GPU. From the small
number of examples seen so far, it looks like just a single bit is being
flipped. Let's dump some values to see if it there is a larger pattern
here.
Furthermore
Quoting Antonio Argenziano (2018-05-30 18:42:28)
>
>
> On 30/05/18 03:33, Chris Wilson wrote:
> > Check twice for the signal interrupting the execbuf, because the real
> > world is messy.
> >
> > References: https://bugs.freedesktop.org/show_bug.cgi?id=106695
> > Signed-off-by: Chris Wilson
>
On Thu, May 31, 2018 at 02:56:24PM +0300, Jani Nikula wrote:
> Setting PCH type to PCH_NOP before checking whether we actually have a
> PCH ends up returning true for HAS_PCH_SPLIT() on all non-PCH split
> platforms. Fix this by using PCH_NOP only for platforms that actually
> have a PCH.
>
> Cc:
== Series Details ==
Series: series starting with [1/4] drm/i915: fix guest virtual PCH detection on
non-PCH systems (rev2)
URL : https://patchwork.freedesktop.org/series/44023/
State : failure
== Summary ==
Applying: drm/i915: fix guest virtual PCH detection on non-PCH systems
Applying:
On Thu, May 31, 2018 at 02:56:21PM +0300, Jani Nikula wrote:
> Virtualized non-PCH systems such as Broxton or Geminilake should use
> PCH_NONE to indicate no PCH rather than PCH_NOP. The latter is a
> specific case to indicate a PCH system without south display.
Then let's go ahead and document
== Series Details ==
Series: series starting with [1/4] drm/i915: fix guest virtual PCH detection on
non-PCH systems
URL : https://patchwork.freedesktop.org/series/44023/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4265 -> Patchwork_9158 =
== Summary - WARNING ==
On 31/05/2018 09:22, Chris Wilson wrote:
During testing we encounter a conflict between SUSPEND_TEST_DEVICES and
disabling reset (gem_eio/suspend). This results in the device continuing
on without being reset, but since it has gone through HW sanitization to
account for the suspend/resume
Quoting Matthew Auld (2018-05-31 15:43:14)
> On 31 May 2018 at 12:35, Chris Wilson wrote:
> > From: Jon Bloomfield
> >
> > We can set a bit inside the ppGTT PTE to indicate a page is read-only;
> > writes from the GPU will be discarded. We can use this to protect pages
> > and in particular
Quoting Antonio Argenziano (2018-05-31 15:42:03)
>
>
> On 30/05/18 12:52, Chris Wilson wrote:
> > Quoting Antonio Argenziano (2018-05-30 18:30:36)
> >>
> >>
> >> On 30/05/18 03:33, Chris Wilson wrote:
> >>> After hitting the SIGINT from execbuf, wait until the next timer signal
> >>> before
On 31 May 2018 at 12:35, Chris Wilson wrote:
> From: Jon Bloomfield
>
> We can set a bit inside the ppGTT PTE to indicate a page is read-only;
> writes from the GPU will be discarded. We can use this to protect pages
> and in particular support read-only userptr mappings (necessary for
>
On 30/05/18 12:52, Chris Wilson wrote:
Quoting Antonio Argenziano (2018-05-30 18:30:36)
On 30/05/18 03:33, Chris Wilson wrote:
After hitting the SIGINT from execbuf, wait until the next timer signal
before trying again. This aligns the start of the ioctl to the timer,
hopefully maximising
:
https://github.com/0day-ci/linux/commits/Chris-Wilson/drm-i915-Remove-stale-asserts-from-i915_gem_find_active_request/20180531-202540
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: i386-randconfig-x006-201821 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
On 31/05/2018 01:26, Rodrigo Vivi wrote:
> On Wed, May 30, 2018 at 06:29:36PM +0300, Ville Syrjälä wrote:
>> On Thu, May 24, 2018 at 11:57:17AM +0200, Neil Armstrong wrote:
>>> This patchs adds the cec_notifier feature to the intel_hdmi part
>>> of the i915 DRM driver. It uses the HDMI DRM
On 30/05/2018 17:29, Ville Syrjälä wrote:
> On Thu, May 24, 2018 at 11:57:17AM +0200, Neil Armstrong wrote:
>> This patchs adds the cec_notifier feature to the intel_hdmi part
>> of the i915 DRM driver. It uses the HDMI DRM connector name to differentiate
>> between each HDMI ports.
>> The changes
== Series Details ==
Series: series starting with [1/4] drm/i915: fix guest virtual PCH detection on
non-PCH systems
URL : https://patchwork.freedesktop.org/series/44023/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4264 -> Patchwork_9157 =
== Summary - FAILURE ==
:
https://github.com/0day-ci/linux/commits/Chris-Wilson/drm-i915-Remove-stale-asserts-from-i915_gem_find_active_request/20180531-202540
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-randconfig-x019-201821 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
== Series Details ==
Series: series starting with [1/5] drm/i915/gtt: Add read only pages to
gen8_pte_encode
URL : https://patchwork.freedesktop.org/series/44022/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4264 -> Patchwork_9156 =
== Summary - FAILURE ==
Serious
== Series Details ==
Series: series starting with [1/5] drm/i915/gtt: Add read only pages to
gen8_pte_encode
URL : https://patchwork.freedesktop.org/series/44022/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
401a4686bb18 drm/i915/gtt: Add read only pages to gen8_pte_encode
== Series Details ==
Series: series starting with [1/3] drm/i915/gtt: Add read only pages to
gen8_pte_encode
URL : https://patchwork.freedesktop.org/series/44008/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4263_full -> Patchwork_9155_full =
== Summary - FAILURE ==
Use intel_pch_type() also for mapping the no PCH case (PCH id 0) to
PCH_NONE to simplify code.
Also make sure that intel_pch_type() knows all the PCH ids returned by
intel_virt_detect_pch(). Loudly fail if this isn't the case; this
shouldn't happen anyway.
Cc: Colin Xu
Reviewed-by: Ville
HAS_PCH_NOP() implies a PCH platform without south display, not generic
disabled display. Prefer num_pipes == 0 for PCH independent checks.
Cc: Ville Syrjala
Reviewed-by: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_bios.c | 2 +-
drivers/gpu/drm/i915/intel_i2c.c |
Setting PCH type to PCH_NOP before checking whether we actually have a
PCH ends up returning true for HAS_PCH_SPLIT() on all non-PCH split
platforms. Fix this by using PCH_NOP only for platforms that actually
have a PCH.
Cc: Ville Syrjala
Reviewed-by: Ville Syrjälä
Signed-off-by: Jani Nikula
Virtualized non-PCH systems such as Broxton or Geminilake should use
PCH_NONE to indicate no PCH rather than PCH_NOP. The latter is a
specific case to indicate a PCH system without south display.
Reported-by: Colin Xu
Cc: Colin Xu
Reviewed-by: Ville Syrjälä
Signed-off-by: Jani Nikula
---
Just a resend of [1] with patch 4 dropped.
BR,
Jani.
[1] 20180531055524.21855-1-jani.nikula@intel.com">http://mid.mail-archive.com/20180531055524.21855-1-jani.nikula@intel.com
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
On Thu, May 31, 2018 at 08:55:24AM +0300, Jani Nikula wrote:
> Setting PCH type to PCH_NOP before checking whether we actually have a
> PCH ends up returning true for HAS_PCH_SPLIT() on all non-PCH split
> platforms. Fix this by using PCH_NOP only for platforms that actually
> have a PCH.
>
> Cc:
On gen8 and onwards, we can mark GPU accesses through the ppGTT as being
read-only, that is cause any GPU write onto that page to be discarded
(not triggering a fault). This is all that we need to finally support
the read-only flag for userptr!
Testcase: igt/gem_userptr_blits/readonly*
From: Jon Bloomfield
Hook up the flags to allow read-only ppGTT mappings for gen8+
Signed-off-by: Jon Bloomfield
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
Cc: Matthew Auld
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 45 -
From: Jon Bloomfield
We can set a bit inside the ppGTT PTE to indicate a page is read-only;
writes from the GPU will be discarded. We can use this to protect pages
and in particular support read-only userptr mappings (necessary for
importing PROT_READ vma).
Signed-off-by: Jon Bloomfield
If the user created a read-only object, they should not be allowed to
circumvent the write protection using the pwrite ioctl.
Signed-off-by: Chris Wilson
Cc: Jon Bloomfield
Cc: Joonas Lahtinen
Cc: Matthew Auld
---
drivers/gpu/drm/i915/i915_gem.c | 6 ++
1 file changed, 6 insertions(+)
If the user has created a read-only object, they should not be allowed
to circumvent the write protection by using a GGTT mmapping. Deny it.
Also most machines do not support read-only GGTT PTEs, so again we have
to reject attempted writes. Fortunately, this is known a priori, so we
can at least
On Thu, May 31, 2018 at 08:55:23AM +0300, Jani Nikula wrote:
> HAS_PCH_NOP() implies a PCH platform without south display, not generic
> disabled display. Prefer num_pipes == 0 for PCH independent checks.
>
> Cc: Ville Syrjala
> Cc: Chris Wilson
> Signed-off-by: Jani Nikula
>
> ---
>
> I'm
On Thu, 2018-05-31 at 10:19 +0100, Chris Wilson wrote:
> From: Jon Bloomfield
>
> Hook up the flags to allow read-only ppGTT mappings for gen8+
>
> Signed-off-by: Jon Bloomfield
> Signed-off-by: Chris Wilson
> Cc: Joonas Lahtinen
> Cc: Matthew Auld
Reviewed-by: Joonas Lahtinen
Regards,
On Thu, 2018-05-31 at 10:19 +0100, Chris Wilson wrote:
> From: Jon Bloomfield
>
> We can set a bit inside the ppGTT PTE to indicate a page is read-only;
> writes from the GPU will be discarded. We can use this to protect pages
> and in particular support read-only userptr mappings (necessary for
From: Tvrtko Ursulin
There is a chance new kernel or new firmware fixed the CPU0 hotplug hang
issue. Remove the skip to check if that's true.
Signed-off-by: Tvrtko Ursulin
---
tests/perf_pmu.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/tests/perf_pmu.c b/tests/perf_pmu.c
index
== Series Details ==
Series: series starting with [1/4] drm/i915: Switch to kernel context before
idling at runtime
URL : https://patchwork.freedesktop.org/series/44004/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4262_full -> Patchwork_9154_full =
== Summary - WARNING
Quoting Chris Wilson (2018-05-31 10:19:23)
> On gen8 and onwards, we can mark GPU accesses through the ppGTT as being
> read-only, that is cause any GPU write onto that page to be discarded
> (not triggering a fault). This is all that we need to finally support
> the read-only flag for userptr!
== Series Details ==
Series: series starting with [1/3] drm/i915/gtt: Add read only pages to
gen8_pte_encode
URL : https://patchwork.freedesktop.org/series/44008/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4263 -> Patchwork_9155 =
== Summary - WARNING ==
Minor
== Series Details ==
Series: series starting with [1/3] drm/i915/gtt: Add read only pages to
gen8_pte_encode
URL : https://patchwork.freedesktop.org/series/44008/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
15543653a61b drm/i915/gtt: Add read only pages to gen8_pte_encode
Quoting Ville Syrjala (2018-05-29 19:33:15)
> From: Ville Syrjälä
>
> When we're trying to reinstate the colorkey we might fail on account of
> the plane still being enable with a configuration that prevent the
> use of colorkey. This happens easily with NV12 since the plane scaler
> required by
On gen8 and onwards, we can mark GPU accesses through the ppGTT as being
read-only, that is cause any GPU write onto that page to be discarded
(not triggering a fault). This is all that we need to finally support
the read-only flag for userptr!
Testcase: igt/gem_userptr_blits/readonly*
From: Jon Bloomfield
We can set a bit inside the ppGTT PTE to indicate a page is read-only;
writes from the GPU will be discarded. We can use this to protect pages
and in particular support read-only userptr mappings (necessary for
importing PROT_READ vma).
Signed-off-by: Jon Bloomfield
From: Jon Bloomfield
Hook up the flags to allow read-only ppGTT mappings for gen8+
Signed-off-by: Jon Bloomfield
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
Cc: Matthew Auld
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 45 -
drivers/gpu/drm/i915/i915_gem_gtt.h
== Series Details ==
Series: series starting with [1/4] drm/i915: Switch to kernel context before
idling at runtime
URL : https://patchwork.freedesktop.org/series/44004/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4262 -> Patchwork_9154 =
== Summary - SUCCESS ==
No
== Series Details ==
Series: series starting with [1/4] drm/i915: Switch to kernel context before
idling at runtime
URL : https://patchwork.freedesktop.org/series/44004/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm/i915: Switch to kernel context before idling at
During testing we encounter a conflict between SUSPEND_TEST_DEVICES and
disabling reset (gem_eio/suspend). This results in the device continuing
on without being reset, but since it has gone through HW sanitization to
account for the suspend/resume cycle, we have to assume the device has
been
We can reduce our exposure to random neutrinos by resting on the kernel
context having flushed out the user contexts to system memory and
beyond. The corollary is that we then we require two passes through the
idle handler to go to sleep, which on a truly idle system involves an
extra pass through
During suspend we want to flush out all active contexts and their
rendering. To do so we queue a request from the kernel's context, once
we know that request is done, we know the GPU is completely idle. To
speed up that switch bump the GPU clocks.
Switching to the kernel context prior to idling
As we reset the GPU on suspend/resume, we also do need to reset the
engine state tracking so call into the engine backends. This is
especially important so that we can also sanitize the state tracking
across resume.
References: https://bugs.freedesktop.org/show_bug.cgi?id=106702
Signed-off-by:
Hi Dave,
Finally got my send-mail script sorted out. A few bugfixes for drm-next.
drm-misc-next-fixes-2018-05-31:
drm-misc-next-fixes for v4.18:
Driver changes:
- Plug small memory leak in vc4. (anholt)
- Depend on MMU in v3d. (arnd)
The following changes since commit
On Mon, May 21, 2018 at 06:23:58PM +0530, Ramalingam C wrote:
> Implements the HDMI adaptation specific HDCP2.2 operations.
>
> Basically these are DDC read and write for authenticating through
> HDCP2.2 messages.
>
> v2:
> Rebased.
> v3:
> No Changes.
> v4:
> No more special handling of
On Mon, May 21, 2018 at 06:23:57PM +0530, Ramalingam C wrote:
> Implements the DP adaptation specific HDCP2.2 functions.
>
> These functions perform the DPCD read and write for communicating the
> HDCP2.2 auth message back and forth.
>
> Note: Chris Wilson suggested alternate method for waiting
== Series Details ==
Series: series starting with [1/5] drm/i915: fix guest virtual PCH detection on
non-PCH systems
URL : https://patchwork.freedesktop.org/series/43986/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4261_full -> Patchwork_9153_full =
== Summary - FAILURE
On Mon, May 21, 2018 at 06:23:44PM +0530, Ramalingam C wrote:
> Implements the enable and disable functions for HDCP2.2 encryption
> of the PORT.
>
> v2:
> intel_wait_for_register is used instead of wait_for. [Chris Wilson]
> v3:
> No Changes.
> v4:
> Debug msg is added for timeout at
On Mon, May 21, 2018 at 06:23:41PM +0530, Ramalingam C wrote:
> Adds the wrapper for all mei hdcp2.2 service functions.
>
> v2:
> Rebased.
> v3:
> cldev is moved from mei_hdcp_data to hdcp.
> v4:
> %s/hdcp2_store_paring_info/hdcp2_store_pairing_info
>
> Signed-off-by: Ramalingam C
This
1 - 100 of 102 matches
Mail list logo
