The subject should probably have "drm/i915/bios" or "drm/i915/vbt".
On Wed, 06 Mar 2019, Thomas Preston wrote:
> We rely on VBT DDI port info for eDP detection on GEN9 platforms and
> above. This breaks GEN9 platforms which don't have VBT because port A
> eDP now defaults to false. Fix this by d
On 06/03/2019 14:24, Chris Wilson wrote:
To facilitate the next patch to allow preemptible kernels not to incur
the wrath of hangcheck, we need to ensure that we can still suspend and
shutdown. That is we will not be able to rely on hangcheck to terminate
a blocking kernel and instead must manua
Hi Sean and Joonas,
Here's a pull request for HDR format enabling in i915. Can this be pulled to
drm-misc-next and dinq?
Cheers,
Maarten
topic/hdr-formats-2019-03-07:
Add support for Y21x and Y41x to drm core and i915, and P01x support to i915.
The following changes since commit 4b057e73f28f1df
On Wed, 06 Mar 2019, Ville Syrjälä wrote:
> On Wed, Mar 06, 2019 at 05:34:15PM +0200, Jani Nikula wrote:
>> For the time being this is only for completeness and better debug
>> logging of DSI ports.
>>
>> Signed-off-by: Jani Nikula
>> ---
>> drivers/gpu/drm/i915/i915_drv.h | 1 +
>> drivers/
Hi,
Thanks for looking at this.
On 07/03/2019 08:18, Jani Nikula wrote:
The subject should probably have "drm/i915/bios" or "drm/i915/vbt".
Noted
On Wed, 06 Mar 2019, Thomas Preston wrote:
We rely on VBT DDI port info for eDP detection on GEN9 platforms and
above. This breaks GEN9 platfo
On Thu, 07 Mar 2019, Thomas Preston wrote:
> Hi,
> Thanks for looking at this.
>
> On 07/03/2019 08:18, Jani Nikula wrote:
>>
>> The subject should probably have "drm/i915/bios" or "drm/i915/vbt".
>>
>
> Noted
>
>> On Wed, 06 Mar 2019, Thomas Preston wrote:
>>> We rely on VBT DDI port info for
Pretend that we have only 1 DBuf slice and that 1 slice is always
enabled, until we have a proper way for on-demand toggling of the second
slice. Currently we'll try to incorrectly enable DBuf even when all
pipes are disabled and we are already runtime suspended (as the computed
number of DBuf sli
To facilitate the next patch to allow preemptible kernels not to incur
the wrath of hangcheck, we need to ensure that we can still suspend and
shutdown. That is we will not be able to rely on hangcheck to terminate
a blocking kernel and instead must manually do so ourselves. The
advantage is that w
Currently we use HZ/5 for detecting a dead gpu on startup, and we will
wish to reuse this value for detecting a dead gpu on suspend, so convert
it into a macro for later convenience.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem.c | 4 +++-
drivers/gpu/drm/i91
On 07/03/2019 10:34, Jani Nikula wrote:
On Wed, 06 Mar 2019, Thomas Preston wrote:
We rely on VBT DDI port info for eDP detection on GEN9 platforms and
above. This breaks GEN9 platforms which don't have VBT because port A
eDP now defaults to false. Fix this by defaulting to true when VBT is
mis
Quoting Chris Wilson (2019-03-07 10:45:30)
> To facilitate the next patch to allow preemptible kernels not to incur
> the wrath of hangcheck, we need to ensure that we can still suspend and
> shutdown. That is we will not be able to rely on hangcheck to terminate
> a blocking kernel and instead mus
On 07/03/2019 10:45, Chris Wilson wrote:
Currently we use HZ/5 for detecting a dead gpu on startup, and we will
wish to reuse this value for detecting a dead gpu on suspend, so convert
it into a macro for later convenience.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/
== Series Details ==
Series: series starting with [1/2] drm/i915: Make I915_GEM_IDLE_TIMEOUT into a
macro
URL : https://patchwork.freedesktop.org/series/57690/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5713 -> Patchwork_12402
==
On Thu, 07 Mar 2019, Thomas Preston wrote:
> Would you like me to resubmit with the suggested changes?
Nah, we can tweak the commit message while applying.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-g
On 06/03/2019 14:25, Chris Wilson wrote:
Continuing the decluttering of i915_gem.c
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel
On 06/03/2019 14:24, Chris Wilson wrote:
We can reduce the switch-to-kernel-context selftest to operate as a loop
and so trivially test another state transition (that of idle->busy).
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/selftests/i915_gem_context.c | 80 ---
1 fi
On 06/03/2019 14:25, Chris Wilson wrote:
Continuing the decluttering of i915_gem.c
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel
On 06/03/2019 14:25, Chris Wilson wrote:
Continuing the decluttering of i915_gem.c
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-
On 06/03/2019 14:24, Chris Wilson wrote:
When the system idles, we switch to the kernel context as a defensive
measure (no users are harmed if the kernel context is lost). Currently,
we issue a switch to kernel context and then come back later to see if
the kernel context is still current and th
Quoting Tvrtko Ursulin (2019-03-07 12:40:43)
>
> On 06/03/2019 14:24, Chris Wilson wrote:
> > We can reduce the switch-to-kernel-context selftest to operate as a loop
> > and so trivially test another state transition (that of idle->busy).
> >
> > Signed-off-by: Chris Wilson
> > ---
> > - er
On 06/03/2019 14:24, Chris Wilson wrote:
We load a context (the kernel context) on both module load and resume in
order to initialise some logical state onto the GPU. We can use the same
routine for both operations, which will become more useful as we
refactor rc6/rps enabling.
Signed-off-by: C
On 07/03/2019 13:17, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-03-07 12:40:43)
On 06/03/2019 14:24, Chris Wilson wrote:
We can reduce the switch-to-kernel-context selftest to operate as a loop
and so trivially test another state transition (that of idle->busy).
Signed-off-by: Chris Wi
Quoting Tvrtko Ursulin (2019-03-07 13:07:18)
>
> On 06/03/2019 14:24, Chris Wilson wrote:
> > +static bool switch_to_kernel_context_sync(struct drm_i915_private *i915)
> > +{
> > + if (i915_gem_switch_to_kernel_context(i915))
> > + return false;
>
> Is it worth still trying to idl
== Series Details ==
Series: series starting with [1/2] drm/i915: Make I915_GEM_IDLE_TIMEOUT into a
macro
URL : https://patchwork.freedesktop.org/series/57690/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5713 -> Patchwork_12402
==
== Series Details ==
Series: drm/i915/ddi: Fix default eDP detection on port A (rev2)
URL : https://patchwork.freedesktop.org/series/57663/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5713 -> Patchwork_12403
Summary
-
== Series Details ==
Series: drm/i915/icl: Prevent incorrect DBuf enabling (rev2)
URL : https://patchwork.freedesktop.org/series/57687/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5714 -> Patchwork_12404
Summary
---
On Thu, Mar 07, 2019 at 03:46:23PM +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915/icl: Prevent incorrect DBuf enabling (rev2)
> URL : https://patchwork.freedesktop.org/series/57687/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_5714 -> Patchwork_
On 07/03/2019 10:34, Jani Nikula wrote:
There are dangers with default VBTs too. They might contain incorrect
information about the specific board you have. You'll also have to set
up the opregion, not just VBT.
I'm afraid I can't help you there. You already know where to look to see
how the ker
== Series Details ==
Series: drm/i915/ddi: Fix default eDP detection on port A (rev3)
URL : https://patchwork.freedesktop.org/series/57663/
State : failure
== Summary ==
Applying: drm/i915/ddi: Fix default eDP detection on port A
error: patch failed: drivers/gpu/drm/i915/intel_opregion.c:971
e
== Series Details ==
Series: series starting with [1/2] drm/i915: Make I915_GEM_IDLE_TIMEOUT into a
macro (rev2)
URL : https://patchwork.freedesktop.org/series/57690/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5714 -> Patchwork_12405
===
To exercise the new I915_CONTEXT_PARAM_ENGINES and interactions with
gem_execbuf().
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Andi Shyti
---
tests/Makefile.sources | 1 +
tests/i915/gem_ctx_engines.c | 277 +++
tests/meson.build| 1
On 07/03/2019 13:29, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-03-07 13:07:18)
On 06/03/2019 14:24, Chris Wilson wrote:
+static bool switch_to_kernel_context_sync(struct drm_i915_private *i915)
+{
+ if (i915_gem_switch_to_kernel_context(i915))
+ return false;
Is it wo
On Thu, 2019-03-07 at 10:48 +0100, Maarten Lankhorst wrote:
> Hi Sean and Joonas,
>
> Here's a pull request for HDR format enabling in i915. Can this be pulled to
> drm-misc-next and dinq?
Could you also add Kevin Strasser's patch for FP16 formats? For that
matter I'd like to see FP32 added too,
== Series Details ==
Series: drm/i915/ddi: Fix default eDP detection on port A (rev2)
URL : https://patchwork.freedesktop.org/series/57663/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5713_full -> Patchwork_12403_full
Sum
On 06/03/2019 14:24, Chris Wilson wrote:
Currently we assume that we know the order in which requests run and so
can determine if we need to reissue a switch-to-kernel-context prior to
idling. That assumption does not hold for the future, so instead of
tracking which barriers have been used, sim
On Wed, Mar 06, 2019 at 06:20:08PM -0800, Dhinakaran Pandiyan wrote:
> On Wed, 2019-03-06 at 10:07 -0800, Rodrigo Vivi wrote:
> > On Tue, Mar 05, 2019 at 01:46:56PM -0800, Anusha wrote:
> > > From: Anusha Srivatsa
> > >
> > > Comet Lake PCH is based off of Cannon Point(CNP).
> > > Add PCI ID for
On 06/03/2019 14:24, Chris Wilson wrote:
We can no longer assume execution ordering, and in particular we cannot
assume which context will execute last. One side-effect of this is that
we cannot determine if the kernel-context is resident on the GPU, so
remove the routines that claimed to do so.
This patch series adds new tests to validate Display C states.
DC states like DC5 and DC6 are validated during PSR entry/exit
and during DPMS on/off cycle.
Sending new revision of patch series after addressing review comments and
other relevant changes.
1. Changing the name of test from pm_dc to
From: Jyoti Yadav
This patch add subtest to check DC6 entry on PSR for the supported
platforms.
v2: Rename the subtest with more meaningful name.
v3: Rebased.
v4: Rebased, to fix compilation error in psr_enable().
Addressed review comment by fixing typo in comment description
of DC6 PSR
From: Jyoti Yadav
Currently this test validates DC5 upon PSR entry for supported platforms.
Added new file for compilation inside Makefile and Meson.
v2: Used the debugfs entry for DC counters instead of Registers.
Used shorter names for variables.
Introduced timeout to read DC counters.
From: Jyoti Yadav
Added new subtest for DC5 entry during DPMS on/off cycle.
During DPMS on/off cycle DC5 counter is incremented.
v2: Rename the subtest with meaningful name.
v3: Rebased.
v4: Addressed review comments by removing leftover code
cleanup().
v5: Addressed the review comment by re
From: Jyoti Yadav
It will be used by new test pm_dc.c which will validate Display C States.
So moving the same to igt_pm library.
v2: Simplify the comment section.
v3: Remove . from the subject line.
v4: Rebased, resolve conflicts in pm_rpm.c
Included patch set version change log.
v5: Listin
From: Jyoti Yadav
Added new subtest for DC6 entry during DPMS on/off cycle.
During DPMS on/off cycle DC6 counter is incremented.
v2: Renamed the subtest name.
v3: Rebased.
v4: Addressed review comment by replacing igt_display_init() to
igt_display_require(), changes got done in patch set 2.
On Thu, Mar 07, 2019 at 10:48:24AM +0100, Maarten Lankhorst wrote:
> Hi Sean and Joonas,
>
> Here's a pull request for HDR format enabling in i915. Can this be pulled to
> drm-misc-next and dinq?
>
> Cheers,
> Maarten
>
> topic/hdr-formats-2019-03-07:
Mentioned on IRC, but will do so here as w
On Thu, Mar 07, 2019 at 12:32:35PM +0200, Imre Deak wrote:
> Pretend that we have only 1 DBuf slice and that 1 slice is always
> enabled, until we have a proper way for on-demand toggling of the second
> slice. Currently we'll try to incorrectly enable DBuf even when all
> pipes are disabled and w
== Series Details ==
Series: series starting with [1/2] drm/i915: Make I915_GEM_IDLE_TIMEOUT into a
macro (rev2)
URL : https://patchwork.freedesktop.org/series/57690/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5714_full -> Patchwork_12405_full
=
Reviewed-by: Lyude Paul
Does this patch/any of the other patches in this series need pushing?
On Fri, 2019-03-01 at 16:33 -0800, José Roberto de Souza wrote:
> Atomic state needs to be put even if the commit was successful.
>
> Fixes: dba14b27dd3c ("drm/i915: Reinitialize sink scrambling/TMDS c
On Thu, Mar 07, 2019 at 12:18:15PM +0200, Jani Nikula wrote:
> On Wed, 06 Mar 2019, Ville Syrjälä wrote:
> > On Wed, Mar 06, 2019 at 05:34:15PM +0200, Jani Nikula wrote:
> >> For the time being this is only for completeness and better debug
> >> logging of DSI ports.
> >>
> >> Signed-off-by: Jani
Adding the call to prepare for guc reset along with engine
reset. intel_uc_reset_prepare() calls to disable guc communication
and to sanitize.
Cc: Daniele Ceraolo Spurio
Cc: Michal Wajdeczko
Signed-off-by: Sujaritha Sundaresan
---
drivers/gpu/drm/i915/i915_reset.c | 2 ++
1 file changed, 2 ins
Some devices will not expose a mappable aperture anymore so we need to
return an appropriate value in that case.
Signed-off-by: Antonio Argenziano
Cc: Matthew Auld
Cc: Daniele Ceraolo Spurio
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 3 ++-
1 file changed, 2 insertions(+), 1 dele
Extend the API to return the mappable aperture size directly in the
I915_GEM_GET_APERTURE IOCTL.
Signed-off-by: Antonio Argenziano
Cc: Matthew Auld
Cc: Daniele Ceraolo Spurio
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 2 ++
include/uapi/drm/i915_drm.h | 5 +
2 files change
== Series Details ==
Series: series starting with [RFC,1/2] drm/i915: Return mappable aperture size
URL : https://patchwork.freedesktop.org/series/57705/
State : failure
== Summary ==
CALLscripts/checksyscalls.sh
DESCEND objtool
CHK include/generated/compile.h
CC [M] drivers/gp
== Series Details ==
Series: series starting with [1/1] drm/i915/guc: Preparing for GuC reset along
with engine reset
URL : https://patchwork.freedesktop.org/series/57704/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5715 -> Patchwork_12407
==
On Thu, Mar 07, 2019 at 09:59:39AM -0800, Rodrigo Vivi wrote:
> On Thu, Mar 07, 2019 at 12:32:35PM +0200, Imre Deak wrote:
> > Pretend that we have only 1 DBuf slice and that 1 slice is always
> > enabled, until we have a proper way for on-demand toggling of the second
> > slice. Currently we'll t
On Tue, 2019-03-05 at 15:21 -0800, Rodrigo Vivi wrote:
> On Tue, Mar 05, 2019 at 02:11:53PM -0800, José Roberto de Souza
> wrote:
> > Now with the watermarks fixes merged, Icelake is stable enough to
> > have the alpha support protection flag removed.
> >
> > We have a few ICL machines in our CI a
On Tue, 2019-03-05 at 22:47 -0800, José Roberto de Souza wrote:
> Other features like PSR2 also needs to be disabled while getting CRC
> so lets rename ips_force_disable to crc_enabled, drop all this checks
> for pipe A and HSW and BDW and make it generic and
> hsw_compute_ips_config() will take ca
On Tue, 2019-03-05 at 22:47 -0800, José Roberto de Souza wrote:
> If has_psr is set it means that CRTC has a EDP panel attached so it
> can be dropped, also has_psr is better than check for EDP output
> alone as it will avoid set mode_changed when PSR is not supported in
> panel or with current mod
On Wed, 2019-03-06 at 22:52 +0200, Ville Syrjälä wrote:
> On Wed, Mar 06, 2019 at 09:30:57PM +0200, Gwan-gyeong Mun wrote:
> > This patch checks a support of YCBCR420 outputs on an encoder
> > level.
> > If the input mode is YCBCR420-only mode then it prepares DP as an
> > YCBCR420
> > output, else
On Wed, 2019-03-06 at 23:04 +0200, Ville Syrjälä wrote:
> On Wed, Mar 06, 2019 at 09:31:01PM +0200, Gwan-gyeong Mun wrote:
> > All of the link bandwidth and Data M/N calculations were assumed a
> > bpp as
> > RGB format. But When we are using YCbCr 4:2:0 output format on DP,
> > we should change bp
This patch checks a support of YCBCR420 outputs on an encoder level.
If the input mode is YCBCR420-only mode then it prepares DP as an YCBCR420
output, else it continues with RGB output mode.
It set output_format to INTEL_OUTPUT_FORMAT_YCBCR420 in order to using
a pipe scaler as RGB to YCbCr 4:4:4.
When YCBCR 4:2:0 outputs is used for DP, we should program YCBCR 4:2:0 to
MSA and VSC SDP.
As per DP 1.4a spec section 2.2.4.3 [MSA Field for Indication of Color
Encoding Format and Content Color Gamut] while sending YCBCR 420 signals
we should program MSA MISC1 fields which indicate VSC SDP for t
SDP VSC Header and Data Block follow DP 1.4a spec, section 2.2.5.7.5,
chapter "VSC SDP Payload for Pixel Encoding/Colorimetry Format".
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Maarten Lankhorst
---
include/drm/drm_dp_helper.h | 17 +
1 file changed, 17 insertions(+)
diff --g
On Gen 11 platform, to enable resolutions like 5K@120 (or higher) we need
to use DSC (DP 1.4) or YCbCr4:2:0 (DP 1.3 or 1.4) on DP.
In order to support YCbCr4:2:0 on DP we need to program YCBCR 4:2:0
to MSA and VSC SDP.
This patches are RFC patches that add a VSC structure for handling
Pixel Encodi
All of the link bandwidth and Data M/N calculations were assumed a bpp as
RGB format. But When we are using YCbCr 4:2:0 output format on DP,
we should change bpp calculations as YCbCr 4:2:0 format.
The pipe_bpp value was assumed RGB format, therefore, it was multiplied
with 3. But YCbCr 4:2:0 requi
Bspec describes that GEN10 only supports capability of YUV 4:2:0 output to
HDMI port and GEN11 supports capability of YUV 4:2:0 output to both DP and
HDMI ports.
v2: Minor style fix.
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_dp.c | 3 +++
1 fi
Function intel_pixel_encoding_setup_vsc handles vsc header and data block
setup for pixel encoding / colorimetry format.
Setup VSC header and data block in function intel_pixel_encoding_setup_vsc
for pixel encoding / colorimetry format as per dp 1.4a spec,
section 2.2.5.7.1, table 2-119: VSC SDP H
On Tue, 2019-03-05 at 22:47 -0800, José Roberto de Souza wrote:
> When PSR2 is active aka after the number of frames programmed in
> PSR2_CTL 'Frames Before SU Entry' hardware stops to generate CRC
> interruptions causing IGT tests to fail due timeout.
s/interruptions/interrupts
I suppose there ar
A new PCI ID for ICL was added to BSpec, lets keep it in tight sync
as ICL is not protected by the alpha support flag anymore.
BSepc: 21141
Cc: Rodrigo Vivi
Signed-off-by: José Roberto de Souza
---
include/drm/i915_pciids.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/drm/i915_pc
Lets keep it sorted to make easy to spot missing PCI IDs.
Cc: Rodrigo Vivi
Signed-off-by: José Roberto de Souza
---
include/drm/i915_pciids.h | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h
index d2fad7b0
On Tue, 2019-03-05 at 22:47 -0800, José Roberto de Souza wrote:
> All of this checks are redudant and can be removed as the if bellow
below*
> already takes care when there is no changes in the state.
>
> Cc: Dhinakaran Pandiyan
> Reviewed-by: Rodrigo Vivi
> Signed-off-by: José Roberto de Souza
We can reduce the switch-to-kernel-context selftest to operate as a loop
and so trivially test another state transition (that of idle->busy).
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
.../gpu/drm/i915/selftests/i915_gem_context.c | 80 ---
1 file changed, 35 in
On Tue, 2019-03-05 at 22:47 -0800, José Roberto de Souza wrote:
> If PSR is active when pipe CRC is enabled the CRC calculations will
> be inhibit by the transition to low power states that PSR brings.
The MMIO write to enable CRCs should bring the hardware out from PSR,
but I can imagine some init
On Tue, 2019-03-05 at 22:47 -0800, José Roberto de Souza wrote:
> The support for PSR2 was polished, IGT tests for PSR2 was added and
> it was tested performing regular user workloads like browsing,
> editing documents and compiling Linux, so it is time to enable it by
> default and enjoy even more
== Series Details ==
Series: drm/i915/dp: Preliminary support for DP YCbCr4:2:0 outputs (rev5)
URL : https://patchwork.freedesktop.org/series/56059/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5716 -> Patchwork_12409
Summ
== Series Details ==
Series: series starting with [1/2] drm/i915: Sort ICL PCI IDs
URL : https://patchwork.freedesktop.org/series/57707/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5716 -> Patchwork_12410
Summary
---
On Thu, 2019-03-07 at 13:25 -0800, Dhinakaran Pandiyan wrote:
> On Tue, 2019-03-05 at 22:47 -0800, José Roberto de Souza wrote:
> > If PSR is active when pipe CRC is enabled the CRC calculations will
> > be inhibit by the transition to low power states that PSR brings.
> The MMIO write to enable CR
Quoting Antonio Argenziano (2019-03-07 19:11:15)
> Some devices will not expose a mappable aperture anymore so we need to
> return an appropriate value in that case.
>
> Signed-off-by: Antonio Argenziano
>
> Cc: Matthew Auld
> Cc: Daniele Ceraolo Spurio
> Cc: Chris Wilson
> ---
> drivers/gpu
On Thu, 2019-03-07 at 13:33 -0800, Dhinakaran Pandiyan wrote:
> On Tue, 2019-03-05 at 22:47 -0800, José Roberto de Souza wrote:
> > The support for PSR2 was polished, IGT tests for PSR2 was added and
> > it was tested performing regular user workloads like browsing,
> > editing documents and compil
On 07/03/19 13:59, Chris Wilson wrote:
Quoting Antonio Argenziano (2019-03-07 19:11:15)
Some devices will not expose a mappable aperture anymore so we need to
return an appropriate value in that case.
Signed-off-by: Antonio Argenziano
Cc: Matthew Auld
Cc: Daniele Ceraolo Spurio
Cc: Chris
Quoting Tvrtko Ursulin (2019-03-07 17:06:58)
>
> On 07/03/2019 13:29, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-03-07 13:07:18)
> >>
> >> On 06/03/2019 14:24, Chris Wilson wrote:
> >>> +static bool switch_to_kernel_context_sync(struct drm_i915_private *i915)
> >>> +{
> >>> + if (i91
Quoting Tvrtko Ursulin (2019-03-07 13:19:52)
>
> On 06/03/2019 14:24, Chris Wilson wrote:
> > @@ -4720,19 +4729,10 @@ static int __intel_engines_record_defaults(struct
> > drm_i915_private *i915)
> > err_active:
> > /*
> >* If we have to abandon now, we expect the engines to be id
On Thu, 2019-03-07 at 13:57 -0800, Souza, Jose wrote:
> On Thu, 2019-03-07 at 13:25 -0800, Dhinakaran Pandiyan wrote:
> > On Tue, 2019-03-05 at 22:47 -0800, José Roberto de Souza wrote:
> > > If PSR is active when pipe CRC is enabled the CRC calculations
> > > will
> > > be inhibit by the transitio
Quoting Antonio Argenziano (2019-03-07 22:21:17)
>
>
> On 07/03/19 13:59, Chris Wilson wrote:
> > Quoting Antonio Argenziano (2019-03-07 19:11:15)
> >> Some devices will not expose a mappable aperture anymore so we need to
> >> return an appropriate value in that case.
> >>
> >> Signed-off-by: An
On Thu, 2019-03-07 at 12:26 -0800, Dhinakaran Pandiyan wrote:
> On Tue, 2019-03-05 at 22:47 -0800, José Roberto de Souza wrote:
> > If has_psr is set it means that CRTC has a EDP panel attached so it
> > can be dropped, also has_psr is better than check for EDP output
> > alone as it will avoid set
== Series Details ==
Series: series starting with [1/1] drm/i915/guc: Preparing for GuC reset along
with engine reset
URL : https://patchwork.freedesktop.org/series/57704/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5715_full -> Patchwork_12407_full
On Thu, 2019-03-07 at 14:53 -0800, Souza, Jose wrote:
> On Thu, 2019-03-07 at 12:26 -0800, Dhinakaran Pandiyan wrote:
> > On Tue, 2019-03-05 at 22:47 -0800, José Roberto de Souza wrote:
> > > If has_psr is set it means that CRTC has a EDP panel attached so
> > > it
> > > can be dropped, also has_ps
On Thu, 2019-03-07 at 12:18 -0800, Dhinakaran Pandiyan wrote:
> On Tue, 2019-03-05 at 22:47 -0800, José Roberto de Souza wrote:
> > Other features like PSR2 also needs to be disabled while getting
> > CRC
> > so lets rename ips_force_disable to crc_enabled, drop all this
> > checks
> > for pipe A a
On Thu, 2019-03-07 at 12:47 -0800, Dhinakaran Pandiyan wrote:
> On Tue, 2019-03-05 at 22:47 -0800, José Roberto de Souza wrote:
> > When PSR2 is active aka after the number of frames programmed in
> > PSR2_CTL 'Frames Before SU Entry' hardware stops to generate CRC
> > interruptions causing IGT tes
== Series Details ==
Series: drm/i915/dp: Preliminary support for DP YCbCr4:2:0 outputs (rev5)
URL : https://patchwork.freedesktop.org/series/56059/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5716_full -> Patchwork_12409_full
== Series Details ==
Series: drm/i915/selftests: Improve switch-to-kernel-context checking
URL : https://patchwork.freedesktop.org/series/57708/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5717 -> Patchwork_12411
Summary
On Thu, Mar 07, 2019 at 02:08:10PM +0800, Zhenyu Wang wrote:
>
> Hi,
>
> Here's gvt-fixes for 5.1-rc1.
I'm kind of confused here. this should be -next-fixes right?
$ dim apply-pull drm-intel-next-fixes
Pulling https://github.com/intel/gvt-linux.git tags/gvt-fixes-2019-03-07 ...
From https://gi
On Thu, 2019-03-07 at 14:30 -0800, Dhinakaran Pandiyan wrote:
> On Thu, 2019-03-07 at 13:57 -0800, Souza, Jose wrote:
> > On Thu, 2019-03-07 at 13:25 -0800, Dhinakaran Pandiyan wrote:
> > > On Tue, 2019-03-05 at 22:47 -0800, José Roberto de Souza wrote:
> > > > If PSR is active when pipe CRC is ena
== Series Details ==
Series: series starting with [1/2] drm/i915: Sort ICL PCI IDs
URL : https://patchwork.freedesktop.org/series/57707/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5716_full -> Patchwork_12410_full
Summar
Forcing a specific CRTC to the eDP connector was causing the
intel_psr_fastset_force() to mark mode_chaged in the wrong and
disabled CRTC causing no update in the PSR state.
Looks like our internal state track do not clear output_types and
has_psr in the disabled CRTCs, not sure if this is the exp
In any commit, intel_modeset_pipe_config() will initialilly clear
and then recalculate most of the pipe states but it leave intel
specific color features states in reset state.
If after intel_pipe_config_compare() is detected that a fastset is
possible it will mark update_pipe as true and unsed mo
When PSR2 is active aka after the number of frames programmed in
PSR2_CTL 'Frames Before SU Entry' hardware stops to generate CRC
interrupts causing IGT tests to fail due timeout.
This same behavior don't happen with PSR1, as soon as pipe CRC is
enabled it blocks PSR1 activation so CRC calculation
The support for PSR2 was polished, IGT tests for PSR2 was added and
it was tested performing regular user workloads like browsing,
editing documents and compiling Linux, so it is time to enable it by
default and enjoy even more power-savings.
Cc: Rodrigo Vivi
Reviewed-by: Dhinakaran Pandiyan
Rev
All of this checks are redudant and can be removed as the if bellow
already takes care when there is no changes in the state.
Reviewed-by: Rodrigo Vivi
Reviewed-by: Dhinakaran Pandiyan
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/intel_psr.c | 12
1 file changed,
Other features like PSR2 also needs to be disabled while getting CRC
so lets rename ips_force_disable to crc_enabled, drop all this checks
for pipe A and HSW and BDW and make it generic and
hsw_compute_ips_config() will take care of all the checks removed
from here.
v2: Renaming and parameter chan
Now we are checking sink capabilities when probing PSR DPCD register
and then dynamically checking in if new state is compatible with PSR
in, so this FIXME can be dropped.
Reviewed-by: Dhinakaran Pandiyan
Cc: Dhinakaran Pandiyan
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/int
1 - 100 of 116 matches
Mail list logo
