== Series Details ==
Series: drm/i915/psr: Nuke PSR support for VLV and CHV (rev2)
URL : https://patchwork.freedesktop.org/series/42915/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4171_full -> Patchwork_8985_full =
== Summary - FAILURE ==
Serious unknown changes comin
== Series Details ==
Series: drm/i915/psr: Nuke PSR support for VLV and CHV (rev2)
URL : https://patchwork.freedesktop.org/series/42915/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4171 -> Patchwork_8985 =
== Summary - WARNING ==
Minor unknown changes coming with Patch
== Series Details ==
Series: drm/i915/psr: Nuke PSR support for VLV and CHV (rev2)
URL : https://patchwork.freedesktop.org/series/42915/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm/i915/psr: Nuke PSR support for VLV and CHV
-drivers/gpu/drm/i915/selftests/../i915_drv.
PSR hardware and hence the driver code for VLV and CHV deviates a lot from
their DDI counterparts. While the feature has been disabled for a long time
now, retaining support for these platforms is a maintenance burden. There
have been multiple refactoring commits to just keep the existing code for
On 5/11/2018 5:33 AM, Ville Syrjälä wrote:
On Wed, May 09, 2018 at 06:25:32PM -0700, Abhay Kumar wrote:
From: Ville Syrjälä
CDCLK has to be at least twice the BLCK regardless of audio. Audio
driver has to probe using this hook and increase the clock even in
absence of any display.
v2: Use a
On Fri, 2018-05-11 at 12:51 -0700, Dhinakaran Pandiyan wrote:
> By moving the check from psr_compute_config() to psr_init_dpcd(), we
> get
> to set the dev_priv->psr.sink_support flag only when the panel is
> capable of changing power state. An additional benefit is that the
> check
> will be perfo
== Series Details ==
Series: series starting with [1/6] drm/i915/psr: Avoid DPCD reads when panel
does not support PSR
URL : https://patchwork.freedesktop.org/series/43077/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4171_full -> Patchwork_8984_full =
== Summary - WARNIN
== Series Details ==
Series: series starting with [1/6] drm/i915/psr: Avoid DPCD reads when panel
does not support PSR
URL : https://patchwork.freedesktop.org/series/43077/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4171 -> Patchwork_8984 =
== Summary - SUCCESS ==
No
Maarten Lankhorst writes:
> Hey,
>
> Another pull request for drm-misc-next. Previous one was not applied yet,
> but only sending delta since last request:
> https://lists.freedesktop.org/archives/dri-devel/2018-May/175722.html
Note, I think this PR has a UABI regression in it:
https://patchwor
Noticed that we assume the best case of 0 latency when the DPCD read
fails, reasonable pessimism is safer.
eDP spec does say that if latency is greater than 8, the panel
supplier needs to provide it. I didn't see anything specific in the VBT
for this, so let's go with 8 frames as a fallback.
Cc:
intel_dp->psr_dpcd already has the required values.
Cc: Jose Roberto de Souza
Signed-off-by: Dhinakaran Pandiyan
---
drivers/gpu/drm/i915/intel_psr.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr
By moving the check from psr_compute_config() to psr_init_dpcd(), we get
to set the dev_priv->psr.sink_support flag only when the panel is
capable of changing power state. An additional benefit is that the check
will be performed only at init time instead of every atomic_check.
This should change
While touching the code around this, I noticed that absence of ALPM
capability does not stop us from enabling PSR2. But, the spec
unambiguously states that ALPM is required for PSR2 and so does this
commit that introduced this code
drm/i915/psr: enable ALPM for psr2
As per edp1.4 spec , alpm
Ville noticed that we are unncessarily reading DPCD's after knowing
panel did not support PSR. Looks like this check that was present
earlier got removed unintentionally, let's put it back.
While we do this, add the PSR version number in the debug print.
Cc: Ville Syrjälä
Signed-off-by: Dhinakar
Entry corresponding to 220 us setup time was missing. I am not aware of
any specific bug this fixes, but this could potentially result in enabling
PSR on a panel with a higher setup time requirement than supported by the
hardware.
I verified the value is present in eDP spec versions 1.3, 1.4 and 1
== Series Details ==
Series: tests/gem_eio: Only wait-for-idle inside trigger_reset()
URL : https://patchwork.freedesktop.org/series/43073/
State : success
== Summary ==
= CI Bug Log - changes from IGT_4475_full -> IGTPW_1348_full =
== Summary - WARNING ==
Minor unknown changes coming with
On Fri, 2018-05-11 at 18:03 +, Souza, Jose wrote:
> On Thu, 2018-05-10 at 17:54 -0700, Dhinakaran Pandiyan wrote:
> >
> > Entry corresponding to 220 us setup time was missing. I am not
> > aware
> > of
> > any specific bug this fixes, but this could potentially result in
> > enabling
> > PSR o
== Series Details ==
Series: tests/gem_eio: Only wait-for-idle inside trigger_reset()
URL : https://patchwork.freedesktop.org/series/43073/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4171 -> IGTPW_1348 =
== Summary - WARNING ==
Minor unknown changes coming with IGTPW_
Quoting Lionel Landwerlin (2018-05-11 18:41:28)
> On 11/05/18 16:51, Chris Wilson wrote:
>
> But I can't even startup a gdm on that machine with drm-tip. So maybe
> there is some much more broken...
>
> Don't leave us in suspense...
>
>
> https://bugs.debian.org/cgi-bin/bugr
On Thu, 2018-05-10 at 17:54 -0700, Dhinakaran Pandiyan wrote:
> Entry corresponding to 220 us setup time was missing. I am not aware
> of
> any specific bug this fixes, but this could potentially result in
> enabling
> PSR on a panel with a higher setup time requirement than supported by
> the
> ha
trigger_reset() imposes a tight time constraint (2s) so that we verify
that the reset itself completes quickly. In the middle of this check, we
call gem_quiescent_gpu() which may invoke an rcu_barrier() or two to
clear out the freed memory (DROP_FREED). Those barriers may have
unbounded latency pus
== Series Details ==
Series: drm/i915/gen11: Preempt-to-idle support in execlists. (rev3)
URL : https://patchwork.freedesktop.org/series/40747/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4169_full -> Patchwork_8983_full =
== Summary - FAILURE ==
Serious unknown change
On 11/05/18 16:51, Chris Wilson wrote:
But I can't even startup a gdm on that machine with drm-tip. So maybe
there is some much more broken...
Don't leave us in suspense...
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=890614
Not our bug :)
__
On 05/10/2018 02:59 PM, Oscar Mateo wrote:
Stop reading some now deprecated interrupt registers in both
debugfs and error state. Instead, read the new equivalents in the
Gen11 interrupt repartitioning scheme.
Note that the equivalent to the PM ISR & IIR cannot be read without
affecting the cur
On Fri, 2018-05-11 at 15:24 +0300, Ville Syrjälä wrote:
> On Wed, May 09, 2018 at 02:54:01PM -0700, Dhinakaran Pandiyan wrote:
> >
> > By moving the check from psr_compute_config() to psr_init_dpcd(),
> > we get
> > to set the dev_priv->psr.sink_support flag only when the panel is
> > capable of c
== Series Details ==
Series: drm/i915/gen11: Preempt-to-idle support in execlists. (rev3)
URL : https://patchwork.freedesktop.org/series/40747/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4169 -> Patchwork_8983 =
== Summary - SUCCESS ==
No regressions found.
Externa
== Series Details ==
Series: drm/i915/oa: Disable OA on Haswell
URL : https://patchwork.freedesktop.org/series/43056/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4168_full -> Patchwork_8982_full =
== Summary - WARNING ==
Minor unknown changes coming with Patchwork_8982
Quoting Lionel Landwerlin (2018-05-11 17:10:49)
> On 11/05/18 15:11, Lionel Landwerlin wrote:
> > On 11/05/18 14:52, Chris Wilson wrote:
> >> Before we unpin the buffer used for OA reports and return it to the
> >> system, we need to be sure that the HW has finished writing into it.
> >> For lack o
== Series Details ==
Series: drm/i915/gen11: Preempt-to-idle support in execlists. (rev3)
URL : https://patchwork.freedesktop.org/series/40747/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm/i915/gen11: Preempt-to-idle support in execlists.
-drivers/gpu/drm/i915/selftest
== Series Details ==
Series: drm/i915/gen11: Preempt-to-idle support in execlists. (rev3)
URL : https://patchwork.freedesktop.org/series/40747/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
3492dcf9f1e4 drm/i915/gen11: Preempt-to-idle support in execlists.
-:132: CHECK:COMPARIS
On 11/05/18 15:11, Lionel Landwerlin wrote:
On 11/05/18 14:52, Chris Wilson wrote:
Before we unpin the buffer used for OA reports and return it to the
system, we need to be sure that the HW has finished writing into it.
For lack of a better idea, poll OACONTROL to check it is switched off.
Refe
Quoting Lionel Landwerlin (2018-05-11 16:58:27)
> On 11/05/18 16:51, Chris Wilson wrote:
> > Quoting Lionel Landwerlin (2018-05-11 16:43:02)
> >> On 11/05/18 15:18, Chris Wilson wrote:
> >>> Quoting Lionel Landwerlin (2018-05-11 15:14:13)
> My understanding of the virtual memory addressing fro
On 11/05/18 16:51, Chris Wilson wrote:
Quoting Lionel Landwerlin (2018-05-11 16:43:02)
On 11/05/18 15:18, Chris Wilson wrote:
Quoting Lionel Landwerlin (2018-05-11 15:14:13)
My understanding of the virtual memory addressing from the GPU is limited...
But how can the GPU poke at the kernel's al
On Fri, Apr 06, 2018 at 10:35:00PM +0300, Ville Syrjälä wrote:
> On Fri, Apr 06, 2018 at 07:14:51PM +, Deepak Singh Rawat wrote:
> > This makes sense once we got rid of plane->fb
> >
> > Will this go to drm-next?
>
> The plan is to push to drm-misc-next once we get all
> the ducks in a row.
>
Quoting Lionel Landwerlin (2018-05-11 16:43:02)
> On 11/05/18 15:18, Chris Wilson wrote:
> > Quoting Lionel Landwerlin (2018-05-11 15:14:13)
> >> My understanding of the virtual memory addressing from the GPU is
> >> limited...
> >> But how can the GPU poke at the kernel's allocated data?
> >> I t
== Series Details ==
Series: drm/i915/oa: Check that OA is disabled before unpinning
URL : https://patchwork.freedesktop.org/series/43055/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4168_full -> Patchwork_8981_full =
== Summary - WARNING ==
Minor unknown changes comin
The review of v2 changes touched issues which were addressed in a different way
than planned in that review:
1. Context status processing
While the review went towards finding common path to new preemption flag
combinations and existing cases, I decided to split the two ways, because
the !(status
The patch adds support of preempt-to-idle requesting by setting a proper
bit within Execlist Control Register, and receiving preemption result from
Context Status Buffer.
Preemption in previous gens required a special batch buffer to be executed,
so the Command Streamer never preempted to idle dir
Quoting Chris Wilson (2018-05-11 13:11:47)
> The original switch to use CSB from the HWSP was plagued by the effort
> of read ordering on VT-d; we would read the WRITE pointer from the HWSP
> before it had completed writing the CSB contents. The mystery comes down
> to the lack of rmb() for correct
On 11/05/18 15:18, Chris Wilson wrote:
Quoting Lionel Landwerlin (2018-05-11 15:14:13)
My understanding of the virtual memory addressing from the GPU is limited...
But how can the GPU poke at the kernel's allocated data?
I thought we mapped into the GPU's address space only what is allocated
thr
On 5/11/2018 5:43 AM, Mika Kuoppala wrote:
Chris Wilson writes:
Quoting Mika Kuoppala (2018-05-11 10:56:49)
Michel Thierry writes:
Factor in clear values wherever required while updating destination
min/max.
References: HSDES#160184
Signed-off-by: Michel Thierry
Cc: mesa-...@lists.fr
== Series Details ==
Series: drm/i915/oa: Disable OA on Haswell
URL : https://patchwork.freedesktop.org/series/43056/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4168 -> Patchwork_8982 =
== Summary - WARNING ==
Minor unknown changes coming with Patchwork_8982 need to b
On 11/05/18 15:34, Chris Wilson wrote:
Quoting Lionel Landwerlin (2018-05-11 15:28:24)
On 11/05/18 15:18, Chris Wilson wrote:
Quoting Lionel Landwerlin (2018-05-11 15:14:13)
My understanding of the virtual memory addressing from the GPU is limited...
But how can the GPU poke at the kernel's al
Quoting Lionel Landwerlin (2018-05-11 15:28:24)
> On 11/05/18 15:18, Chris Wilson wrote:
> > Quoting Lionel Landwerlin (2018-05-11 15:14:13)
> >> My understanding of the virtual memory addressing from the GPU is
> >> limited...
> >> But how can the GPU poke at the kernel's allocated data?
> >> I t
On 11/05/18 15:18, Chris Wilson wrote:
Quoting Lionel Landwerlin (2018-05-11 15:14:13)
My understanding of the virtual memory addressing from the GPU is limited...
But how can the GPU poke at the kernel's allocated data?
I thought we mapped into the GPU's address space only what is allocated
thr
Quoting Lionel Landwerlin (2018-05-11 15:14:13)
> My understanding of the virtual memory addressing from the GPU is limited...
> But how can the GPU poke at the kernel's allocated data?
> I thought we mapped into the GPU's address space only what is allocated
> through gem.
Correct. The HW should
== Series Details ==
Series: drm/i915/oa: Check that OA is disabled before unpinning
URL : https://patchwork.freedesktop.org/series/43055/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4168 -> Patchwork_8981 =
== Summary - SUCCESS ==
No regressions found.
External URL
My understanding of the virtual memory addressing from the GPU is limited...
But how can the GPU poke at the kernel's allocated data?
I thought we mapped into the GPU's address space only what is allocated
through gem.
-
Lionel
On 11/05/18 14:56, Chris Wilson wrote:
We observe that the OA arc
On 11/05/18 14:52, Chris Wilson wrote:
Before we unpin the buffer used for OA reports and return it to the
system, we need to be sure that the HW has finished writing into it.
For lack of a better idea, poll OACONTROL to check it is switched off.
References: https://bugs.freedesktop.org/show_bug
We observe that the OA architecture is clobbering random memory. Disable
it until this can be resolved.
References: https://bugs.freedesktop.org/show_bug.cgi?id=106379
Signed-off-by: Chris Wilson
Cc: Lionel Landwerlin
Cc: Matthew Auld
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: Jani Nikula
Cc:
== Series Details ==
Series: series starting with [1/3] drm/i915/execlists: Use rmb() to order CSB
reads
URL : https://patchwork.freedesktop.org/series/43051/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4166_full -> Patchwork_8980_full =
== Summary - WARNING ==
Minor
Before we unpin the buffer used for OA reports and return it to the
system, we need to be sure that the HW has finished writing into it.
For lack of a better idea, poll OACONTROL to check it is switched off.
References: https://bugs.freedesktop.org/show_bug.cgi?id=106379
Signed-off-by: Chris Wilso
Oscar Mateo writes:
> List of GT workarounds for Icelake that we have been carrying in internal.
> Applied lots of review comments from Mika and stamped rv-b's from him and
> Rodrigo.
>
> Oscar Mateo (22):
> drm/i915/icl: Introduce initial Icelake Workarounds
> drm/i915/icl: Enable Sampler DF
Chris Wilson writes:
> Quoting Mika Kuoppala (2018-05-08 13:03:13)
>> Not all architectures guarantee that uncached read will
>> flush the write combining buffer. So marking it explicitly
>> is recommended [1].
>>
>> However we know the architecture we are operating on
>> and can avoid wmb as th
== Series Details ==
Series: series starting with [1/3] drm/i915/execlists: Use rmb() to order CSB
reads
URL : https://patchwork.freedesktop.org/series/43051/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4166 -> Patchwork_8980 =
== Summary - WARNING ==
Minor unknown ch
Hi,
On Thu, 10 May 2018 16:31:13 +0200, Piotr Piorkowski
wrote:
From: Piotr Piórkowski
Currently we are using modparam as placeholder for GuC log level.
Stop doing this and keep runtime GuC level in intel_guc_log struct.
Signed-off-by: Piotr Piórkowski
Cc: Michal Wajdeczko
Cc: Michał W
Chris Wilson writes:
> Quoting Mika Kuoppala (2018-05-11 10:56:49)
>> Michel Thierry writes:
>>
>> > Factor in clear values wherever required while updating destination
>> > min/max.
>> >
>> > References: HSDES#160184
>> > Signed-off-by: Michel Thierry
>> > Cc: mesa-...@lists.freedesktop.o
== Series Details ==
Series: series starting with [1/3] drm/i915/execlists: Use rmb() to order CSB
reads
URL : https://patchwork.freedesktop.org/series/43051/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
a46b4fd07172 drm/i915/execlists: Use rmb() to order CSB reads
-:32: WARN
Oscar Mateo writes:
> Inherit workarounds from previous platforms that are still valid for
> Icelake.
>
> v2: GEN7_ROW_CHICKEN2 is masked
> v3:
> - Since it has been fixed already in upstream, removed the TODO
> comment about WA_SET_BIT for WaInPlaceDecompressionHang.
> - Squashed with th
On Wed, May 09, 2018 at 06:25:32PM -0700, Abhay Kumar wrote:
> From: Ville Syrjälä
>
> CDCLK has to be at least twice the BLCK regardless of audio. Audio
> driver has to probe using this hook and increase the clock even in
> absence of any display.
>
> v2: Use atomic refcount for get_power, put_
On Wed, May 09, 2018 at 02:54:01PM -0700, Dhinakaran Pandiyan wrote:
> By moving the check from psr_compute_config() to psr_init_dpcd(), we get
> to set the dev_priv->psr.sink_support flag only when the panel is
> capable of changing power state. An additional benefit is that the check
> will be pe
Quoting Mika Kuoppala (2018-05-11 10:56:49)
> Michel Thierry writes:
>
> > Factor in clear values wherever required while updating destination
> > min/max.
> >
> > References: HSDES#160184
> > Signed-off-by: Michel Thierry
> > Cc: mesa-...@lists.freedesktop.org
> > Cc: Mika Kuoppala
> > Cc:
Quoting Chris Wilson (2018-05-11 13:11:47)
> The original switch to use CSB from the HWSP was plagued by the effort
s/effort/effect/
> of read ordering on VT-d; we would read the WRITE pointer from the HWSP
> before it had completed writing the CSB contents. The mystery comes down
> to the lack
We assume that the CSB is written using the normal ringbuffer
coherency protocols, as outlined in kernel/events/ring_buffer.c:
* (HW) (DRIVER)
*
* if (LOAD ->data_tail) {LOAD ->data_head
* (A) smp_rmb()
In the previous patch (to include a rmb() after readig the CSB WRITE
pointer from the HWSP) we believe we have fixed the underlying bug, and
so can re-enable using the HWSP on Cannolake.
This reverts commit 61bf9719fa17 ("drm/i915/cnl: Use mmio access to
context status buffer").
References: https
The original switch to use CSB from the HWSP was plagued by the effort
of read ordering on VT-d; we would read the WRITE pointer from the HWSP
before it had completed writing the CSB contents. The mystery comes down
to the lack of rmb() for correct ordering with respect to the writes
from HW, and w
== Series Details ==
Series: drm/i915/selftests: scrub 64K (rev2)
URL : https://patchwork.freedesktop.org/series/43023/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4166_full -> Patchwork_8979_full =
== Summary - WARNING ==
Minor unknown changes coming with Patchwork_89
Chris Wilson writes:
> In the previous patch (to include a rmb() after readig the CSB WRITE
> pointer from the HWSP) we believe we have fixed the underlying bug, and
> so can re-enable using the HWSP on Cannolake.
>
> This reverts commit 61bf9719fa17 ("drm/i915/cnl: Use mmio access to
> context s
Chris Wilson writes:
> We assume that the CSB is written using the normal ringbuffer
> coherency protocols, as outlined in kernel/events/ring_buffer.c:
>
> * (HW) (DRIVER)
> *
> * if (LOAD ->data_tail) {LOAD ->data_head
> *
On 11/05/2018 10:33, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-05-11 10:21:05)
On 11/05/2018 10:04, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-05-11 09:31:52)
On 11/05/2018 08:11, Chris Wilson wrote:
A little tool I've been meaning to write for a while... Convert the
.wsim int
== Series Details ==
Series: drm/i915/selftests: scrub 64K (rev2)
URL : https://patchwork.freedesktop.org/series/43023/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4166 -> Patchwork_8979 =
== Summary - WARNING ==
Minor unknown changes coming with Patchwork_8979 need to
Quoting Matthew Auld (2018-05-11 10:51:40)
> We write all 4K page entries, even when using 64K pages. In order to
> verify that the HW isn't cheating by using the 4K PTE instead of the 64K
> PTE, we want to remove all the surplus entries. If the HW skipped the
> 64K PTE, it will read/write into the
Michel Thierry writes:
> Factor in clear values wherever required while updating destination
> min/max.
>
> References: HSDES#160184
> Signed-off-by: Michel Thierry
> Cc: mesa-...@lists.freedesktop.org
> Cc: Mika Kuoppala
> Cc: Oscar Mateo
Reviewed-by: Mika Kuoppala
_
We write all 4K page entries, even when using 64K pages. In order to
verify that the HW isn't cheating by using the 4K PTE instead of the 64K
PTE, we want to remove all the surplus entries. If the HW skipped the
64K PTE, it will read/write into the scratch page instead - which we
detect as missing
Quoting Tvrtko Ursulin (2018-05-11 10:21:05)
>
> On 11/05/2018 10:04, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2018-05-11 09:31:52)
> >>
> >> On 11/05/2018 08:11, Chris Wilson wrote:
> >>> A little tool I've been meaning to write for a while... Convert the
> >>> .wsim into their dag and fin
On 11/05/2018 10:04, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-05-11 09:31:52)
On 11/05/2018 08:11, Chris Wilson wrote:
A little tool I've been meaning to write for a while... Convert the
.wsim into their dag and find the longest chains and evaluate them on an
simulated machine.
Very
Quoting Tvrtko Ursulin (2018-05-11 09:31:52)
>
> On 11/05/2018 08:11, Chris Wilson wrote:
> > A little tool I've been meaning to write for a while... Convert the
> > .wsim into their dag and find the longest chains and evaluate them on an
> > simulated machine.
>
> Very cool!
>
> But I think you
> -Original Message-
> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> Sent: Friday, May 11, 2018 1:50 PM
> To: Srinivas, Vidya ; intel-
> g...@lists.freedesktop.org
> Subject: Re: [PATCH v8 3/6] drm/i915: Add skl_check_nv12_surface for NV12
>
> Op 11-05-18 om 23:33
On 11/05/2018 09:31, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-05-11 09:25:00)
On 10/05/2018 18:40, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-05-10 18:26:31)
On 10/05/2018 17:25, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-05-10 17:09:14)
On 09/05/2018 15:27, Chris Wil
There are two issues with ratelimiting as far a I can see:
1. Messages may be lost even if their amount fit burst limit;
2. "suppressed" message may not be printed if there is no call to
___ratelimit() after interval ends.
I address (1) issue in the second patch.
While the (2) issue will requir
Currently ratelimit_state is protected with spin_lock. If the .lock is
taken at the moment of ___ratelimit() call, the message is suppressed to
make ratelimiting robust.
That results in the following issue issue:
CPU0 CPU1
-- ---
On 11/05/2018 08:11, Chris Wilson wrote:
A little tool I've been meaning to write for a while... Convert the
.wsim into their dag and find the longest chains and evaluate them on an
simulated machine.
Very cool!
But I think you need to handle the 's' command which appears in the
interesting
Quoting Tvrtko Ursulin (2018-05-11 09:25:00)
>
> On 10/05/2018 18:40, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2018-05-10 18:26:31)
> >>
> >> On 10/05/2018 17:25, Chris Wilson wrote:
> >>> Quoting Tvrtko Ursulin (2018-05-10 17:09:14)
>
> On 09/05/2018 15:27, Chris Wilson wrote:
>
A little tool I've been meaning to write for a while... Convert the
.wsim into their dag and find the longest chains and evaluate them on an
simulated machine.
v2: Implement barriers to handle sync commands
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
benchmarks/Makefile.sources | 1 +
On 10/05/2018 18:40, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-05-10 18:26:31)
On 10/05/2018 17:25, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-05-10 17:09:14)
On 09/05/2018 15:27, Chris Wilson wrote:
Bypass using the tasklet to submit the first request to HW, as the
tasklet ma
Op 11-05-18 om 23:33 schreef Vidya Srinivas:
> From: Maarten Lankhorst
>
> We skip src trunction/adjustments for
> NV12 case and handle the sizes directly.
> Without this, pipe fifo underruns are seen on APL/KBL.
>
> v2: For NV12, making the src coordinates multiplier of 4
>
> v3: Moving all the s
Hey,
Another pull request for drm-misc-next. Previous one was not applied yet,
but only sending delta since last request:
https://lists.freedesktop.org/archives/dri-devel/2018-May/175722.html
drm-misc-next-2018-05-11-1:
drm-misc-next for v4.18:
UAPI Changes:
- Aspect ratio support for 64:27 and
Op 09-05-18 om 22:24 schreef Daniel Vetter:
> On Tue, May 08, 2018 at 04:39:45PM +0530, Nautiyal, Ankit K wrote:
>> From: "Sharma, Shashank"
>>
>> HDMI 2.0/CEA-861-F introduces two new aspect ratios:
>> - 64:27
>> - 256:135
>>
>> This patch:
>> - Adds new DRM flags for to represent these new aspe
A little tool I've been meaning to write for a while... Convert the
.wsim into their dag and find the longest chains and evaluate them on an
simulated machine.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
benchmarks/Makefile.sources | 1 +
benchmarks/sim_wsim.c | 434 +
89 matches
Mail list logo
