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 +
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
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 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
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
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 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:
>
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
-- ---
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
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
> -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
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
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 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
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
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
_
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
== 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
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
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
> *
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
== 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
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
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
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
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:
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
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_
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
== 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
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
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
== 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
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
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
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
== 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
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:
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
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
== 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
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
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: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: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
== 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 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
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 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
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
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
== 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
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
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.
>
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
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 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
== 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
== 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
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/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
== 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
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
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 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 :)
__
== 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
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
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
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
== 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_
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 IGT_4475_full -> IGTPW_1348_full =
== Summary - WARNING ==
Minor unknown changes coming with
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
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
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
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
== 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
== 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
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
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
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
== 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.
== 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 : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4171_full -> Patchwork_8985_full =
== Summary - FAILURE ==
Serious unknown changes comin
89 matches
Mail list logo
