Re: [Intel-gfx] [PATCH i-g-t] igt/kms_rotation_crc: Add horizontal flip subtest.

>-Original Message- >From: Vivi, Rodrigo >Sent: Tuesday, December 19, 2017 1:50 PM >To: Srivatsa, Anusha >Cc: Daniel Vetter ; Strano, Luis ; >Latvala, Petri ; Lofstedt, Marta

Re: [Intel-gfx] [PATCH v4 7/7] drm/i915: Add YCBCR 4:2:0/4:4:4 support for LSPCON

Regards Shashank On 2/2/2018 12:39 AM, Ville Syrjälä wrote: On Tue, Jan 30, 2018 at 03:06:03PM +0530, Shashank Sharma wrote: From: "Sharma, Shashank" LSPCON chips can generate YCBCR outputs, if asked nicely :). In order to generate YCBCR 4:2:0 outputs, a source

Re: [Intel-gfx] [PATCH v4 1/7] drm/i915: Add CRTC output format YCBCR 4:2:0

Thanks for the comments, mine inline. Regards Shashank On 2/2/2018 12:39 AM, Ville Syrjälä wrote: On Tue, Jan 30, 2018 at 03:05:57PM +0530, Shashank Sharma wrote: From: "Sharma, Shashank" Currently, we are using a bool in CRTC state (state->ycbcr420), to indicate

Re: [Intel-gfx] [PATCH v7 3/6] drm/i915/guc: Implement dynamic GuC WOPCM offset and size

On 2/2/2018 3:21 AM, Yaodong Li wrote: On 02/01/2018 12:38 AM, Sagar Arun Kamble wrote: On 1/19/2018 6:59 AM, Jackie Li wrote: Hardware may have specific restrictions on GuC WOPCM size It would be good if you can tell about Gen9/CNL restriction briefly here. versus HuC firmware size.

Re: [Intel-gfx] i915 PSR test results and cursor lag

On Thu, Feb 1, 2018 at 9:20 PM, Chris Wilson wrote: > Quoting Andy Lutomirski (2018-02-01 21:04:30) >> I got this after a recent suspend/resume: >> >> Feb 01 09:44:34 laptop systemd-logind[2412]: Lid closed. >> Feb 01 09:44:34 laptop systemd-logind[2412]:

Re: [Intel-gfx] clang warning: implicit conversion in intel_ddi.c:1481

Hi Greg, On Thu, 1 Feb 2018, Greg KH wrote: > On Thu, Feb 01, 2018 at 06:33:30PM +0100, Ozan Alpay wrote: > > Dear Rodrigo Vivi, Ville Syrjälä, > > > > My name is Ozan Alpay, and I am a student mentored by Lukas Bulwahn. We > > intend to use static analysis tools on the kernel source to

Re: [Intel-gfx] clang warning: implicit conversion in intel_ddi.c:1481

01.02.2018, 21:03, "Greg KH" : > On Thu, Feb 01, 2018 at 06:33:30PM +0100, Ozan Alpay wrote: >>  Dear Rodrigo Vivi, Ville Syrjälä, >> >>  My name is Ozan Alpay, and I am a student mentored by Lukas Bulwahn. We Hi Ozan, why did you send e-mail to kernel development e-mail list?

[Intel-gfx] clang warning: implicit conversion in intel_ddi.c:1481

Dear Rodrigo Vivi, Ville Syrjälä, My name is Ozan Alpay, and I am a student mentored by Lukas Bulwahn. We intend to use static analysis tools on the kernel source to identify, analyze and report issues. As a very first step, we are looking into clang compiler warnings and will then move to

[Intel-gfx] [PULL] drm-intel-next-fixes

Hi Dave, I didn't send sooner because I wasn't happy with the CI results running on drm-intel-next-fixes, but now everything looks greener there. Here goes drm-intel-next-fixes-2018-02-01: Fixes for GPU hangs and other bugs around hangcheck and result; Fix for regression on suspend case with

Re: [Intel-gfx] [PATCH 08/27] drm/i915/icl: Ringbuffer interrupt handling

On 2/1/2018 3:58 PM, Belgaumkar, Vinay wrote: On 1/15/2018 2:38 AM, Tvrtko Ursulin wrote: On 11/01/2018 19:17, Daniele Ceraolo Spurio wrote: On 10/01/18 02:12, Chris Wilson wrote: Quoting Paulo Zanoni (2018-01-09 23:23:17) From: Tvrtko Ursulin Since it is

Re: [Intel-gfx] [PATCH 08/27] drm/i915/icl: Ringbuffer interrupt handling

On 1/15/2018 2:38 AM, Tvrtko Ursulin wrote: On 11/01/2018 19:17, Daniele Ceraolo Spurio wrote: On 10/01/18 02:12, Chris Wilson wrote: Quoting Paulo Zanoni (2018-01-09 23:23:17) From: Tvrtko Ursulin Since it is not possible to mask individual engine instances

[Intel-gfx] ✗ Fi.CI.IGT: failure for DRM management via cgroups (rev2)

== Series Details == Series: DRM management via cgroups (rev2) URL : https://patchwork.freedesktop.org/series/36837/ State : failure == Summary == Test perf_pmu: Subgroup busy-check-all-vecs0: pass -> DMESG-WARN (shard-hsw) Subgroup busy-start-rcs0:

Re: [Intel-gfx] [IGT PATCH RFC] tools: Introduce intel_cgroup tool

+cgroups list since this discussion goes back to the general design On Thu, Feb 01, 2018 at 08:27:33PM +, Chris Wilson wrote: > Quoting Matt Roper (2018-02-01 19:56:15) > > intel_cgroup is used to modify i915 cgroup parameters. At the moment only a > > single parameter is supported (GPU

Re: [Intel-gfx] [PATCH v7 2/6] drm/i915/guc: Rename guc_ggtt_offset to intel_guc_ggtt_offset

On 02/01/2018 02:35 PM, Chris Wilson wrote: Quoting Yaodong Li (2018-02-01 19:47:53) On 01/31/2018 11:38 PM, Chris Wilson wrote: Quoting Jackie Li (2018-01-19 01:29:28) GuC related exported functions should start with "intel_guc_" prefix and pass intel_guc as the first parameter since its

Re: [Intel-gfx] [PATCH v7 2/6] drm/i915/guc: Rename guc_ggtt_offset to intel_guc_ggtt_offset

Quoting Yaodong Li (2018-02-01 19:47:53) > > On 01/31/2018 11:38 PM, Chris Wilson wrote: > > Quoting Jackie Li (2018-01-19 01:29:28) > >> GuC related exported functions should start with "intel_guc_" > >> prefix and pass intel_guc as the first parameter since its guc > >> related. Current

Re: [Intel-gfx] [PATCH v7 5/6] drm/i915/guc: Check the locking status of GuC WOPCM registers

On 01/31/2018 11:41 PM, Chris Wilson wrote: - Fixed patch format issues Cc: Michal Wajdeczko Cc: Chris Wilson Cc: Joonas Lahtinen Signed-off-by: Jackie Li --- +static inline

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Enable inject_load_failure only in DEBUG config

== Series Details == Series: drm/i915: Enable inject_load_failure only in DEBUG config URL : https://patchwork.freedesktop.org/series/37495/ State : failure == Summary == Test perf: Subgroup oa-exponents: pass -> FAIL (shard-apl) fdo#102254 Subgroup

Re: [Intel-gfx] [PATCH v7 3/6] drm/i915/guc: Implement dynamic GuC WOPCM offset and size

On 02/01/2018 12:38 AM, Sagar Arun Kamble wrote: On 1/19/2018 6:59 AM, Jackie Li wrote: Hardware may have specific restrictions on GuC WOPCM size It would be good if you can tell about Gen9/CNL restriction briefly here. versus HuC firmware size. With static GuC WOPCM size, there's no way

Re: [Intel-gfx] [PATCH RFC v2 3/7] cgroup: Add interface to allow drivers to lookup process cgroup membership

On Thu, Feb 01, 2018 at 08:49:32PM +, Chris Wilson wrote: > Quoting Matt Roper (2018-02-01 19:53:11) ... > > +struct cgroup * > > +cgroup_for_driver_process(struct pid *pid) > > +{ > > + struct task_struct *task = pid_task(pid, PIDTYPE_PID); > > + > > + mutex_lock(_mutex); > > +

Re: [Intel-gfx] CI igt-all on drm-intel-next-fixes gem_exec_* and other gem_*

Quoting Rodrigo Vivi (2018-02-01 21:00:45) > Ok, things look much cleaner(greener) on last run after I rebased on > top of a more recent drm-next. > > https://intel-gfx-ci.01.org/tree/drm-intel-next-fixes/shards.html > > My only concern right now is this one: > >

Re: [Intel-gfx] i915 PSR test results and cursor lag

Quoting Andy Lutomirski (2018-02-01 21:04:30) > I got this after a recent suspend/resume: > > Feb 01 09:44:34 laptop systemd-logind[2412]: Lid closed. > Feb 01 09:44:34 laptop systemd-logind[2412]: device-enumerator: scan all dirs > Feb 01 09:44:34 laptop systemd-logind[2412]:

Re: [Intel-gfx] i915 PSR test results and cursor lag

On Thu, Feb 1, 2018 at 9:53 AM, Chris Wilson wrote: > Quoting Andy Lutomirski (2018-02-01 17:40:22) >> *However*, I do see one unfortunate side effect of turning on PSR. It >> seems that, when I move my cursor a little bit after a few seconds of >> doing nothing, there

Re: [Intel-gfx] CI igt-all on drm-intel-next-fixes gem_exec_* and other gem_*

Ok, things look much cleaner(greener) on last run after I rebased on top of a more recent drm-next. https://intel-gfx-ci.01.org/tree/drm-intel-next-fixes/shards.html My only concern right now is this one:

Re: [Intel-gfx] [PATCH RFC v2 3/7] cgroup: Add interface to allow drivers to lookup process cgroup membership

Quoting Matt Roper (2018-02-01 19:53:11) > Drivers will need to save/restore the appropriate cgroup data for the process > submitting a driver request. Add an interface for drivers to determine the > cgroup for the userspace process submitting a driver request. > > Cc: Tejun Heo

Re: [Intel-gfx] [PATCH 01/17] drm/i915/icl: add the main CDCLK functions

On Thu, Feb 01, 2018 at 06:08:29PM -0200, Paulo Zanoni wrote: > Em Seg, 2018-01-29 às 12:51 +0200, Imre Deak escreveu: > > On Tue, Jan 23, 2018 at 05:05:20PM -0200, Paulo Zanoni wrote: > > > This commit adds the basic CDCLK functions, but it's still missing > > > pieces of the display

Re: [Intel-gfx] i915 PSR test results and cursor lag

Quoting Kristian Høgsberg (2018-02-01 20:22:40) > On Thu, Feb 1, 2018 at 9:53 AM Chris Wilson > wrote: > > > Quoting Andy Lutomirski (2018-02-01 17:40:22) > > > *However*, I do see one unfortunate side effect of turning on PSR. It > > > seems that, when I move my

Re: [Intel-gfx] [IGT PATCH RFC] tools: Introduce intel_cgroup tool

Quoting Matt Roper (2018-02-01 19:56:15) > intel_cgroup is used to modify i915 cgroup parameters. At the moment only a > single parameter is supported (GPU priority offset). In the future the driver > may support additional parameters as well (e.g., limits on memory usage). > > Signed-off-by:

Re: [Intel-gfx] [PATCH RFC v2 7/7] drm/i915: Add context priority & priority offset to debugfs

Quoting Matt Roper (2018-02-01 19:53:15) > Update i915_context_status to include priority information. > > Signed-off-by: Matt Roper > --- > drivers/gpu/drm/i915/i915_debugfs.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git

Re: [Intel-gfx] i915 PSR test results and cursor lag

On Thu, Feb 1, 2018 at 9:53 AM Chris Wilson wrote: > Quoting Andy Lutomirski (2018-02-01 17:40:22) > > *However*, I do see one unfortunate side effect of turning on PSR. It > > seems that, when I move my cursor a little bit after a few seconds of > > doing nothing,

Re: [Intel-gfx] [PATCH RFC v2 6/7] drm/i915: Introduce 'priority offset' for GPU contexts

Quoting Matt Roper (2018-02-01 19:53:14) > There are cases where a system integrator may wish to raise/lower the > priority of GPU workloads being submitted by specific OS process(es), > independently of how the software self-classifies its own priority. > Exposing "priority offset" as an

Re: [Intel-gfx] [PATCH RFC v2 5/7] drm/i915: cgroup integration

Quoting Matt Roper (2018-02-01 19:53:13) > +#include > + > +#include "i915_drv.h" > + > +struct i915_cgroup_data { > + struct cgroup_driver_data base; > +}; > + > +static inline struct i915_cgroup_data * > +cgrp_to_i915(struct cgroup_driver_data *data) > +{ Document your requirement that

[Intel-gfx] ✗ Fi.CI.BAT: failure for tools: Introduce intel_cgroup tool

== Series Details == Series: tools: Introduce intel_cgroup tool URL : https://patchwork.freedesktop.org/series/37505/ State : failure == Summary == IGT patchset build failed on latest successful build a20a69e25a18ec63236633b804d89cc0c0cea259 overlay: fix invalid pointer access make

[Intel-gfx] ✓ Fi.CI.BAT: success for DRM management via cgroups (rev2)

== Series Details == Series: DRM management via cgroups (rev2) URL : https://patchwork.freedesktop.org/series/36837/ State : success == Summary == Series 36837v2 DRM management via cgroups https://patchwork.freedesktop.org/api/1.0/series/36837/revisions/2/mbox/ Test gem_exec_reloc:

Re: [Intel-gfx] [PATCH RFC v2 5/7] drm/i915: cgroup integration

Quoting Matt Roper (2018-02-01 19:53:13) > Register i915 as a consumer of the cgroup_driver framework and add an ioctl to > allow userspace to set i915-specific parameters associated with cgroups. > > Signed-off-by: Matt Roper > --- > drivers/gpu/drm/i915/Kconfig

Re: [Intel-gfx] [PATCH RFC v2 5/7] drm/i915: cgroup integration

Quoting Matt Roper (2018-02-01 19:53:13) > diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig > index dfd95889f4b7..1c6b53ee76cd 100644 > --- a/drivers/gpu/drm/i915/Kconfig > +++ b/drivers/gpu/drm/i915/Kconfig > @@ -23,6 +23,7 @@ config DRM_I915 > select SYNC_FILE >

Re: [Intel-gfx] [PATCH RFC v2 4/7] drm: Add helper to obtain cgroup of drm_file's owning process

Quoting Matt Roper (2018-02-01 19:53:12) > +/** > + * drm_file_get_cgroup - obtain cgroup for drm_file's owning process > + * @file_priv: DRM file > + * > + * Obtains the cgroup from a specific hierarchy that the drm_file's owning > + * process belongs to. The cgroup may be used to set

Re: [Intel-gfx] [PATCH 01/17] drm/i915/icl: add the main CDCLK functions

Em Sex, 2018-01-26 às 15:14 -0800, James Ausmus escreveu: > On Tue, Jan 23, 2018 at 05:05:20PM -0200, Paulo Zanoni wrote: > > This commit adds the basic CDCLK functions, but it's still missing > > pieces of the display initialization sequence. > > > > v2: > > - Implement the voltage levels. > >

Re: [Intel-gfx] [PATCH 01/17] drm/i915/icl: add the main CDCLK functions

Em Seg, 2018-01-29 às 12:51 +0200, Imre Deak escreveu: > On Tue, Jan 23, 2018 at 05:05:20PM -0200, Paulo Zanoni wrote: > > This commit adds the basic CDCLK functions, but it's still missing > > pieces of the display initialization sequence. > > > > v2: > > - Implement the voltage levels. > > -

Re: [Intel-gfx] [PATCH RFC v2 2/7] kernfs: Export kernfs_get_inode

Quoting Matt Roper (2018-02-01 19:53:10) > Drivers may wish to access a cgroup's inode to perform permission checks on > driver-specific operations. > > Cc: Tejun Heo > Cc: cgro...@vger.kernel.org > Signed-off-by: Matt Roper > --- > fs/kernfs/inode.c

[Intel-gfx] [IGT PATCH RFC] tools: Introduce intel_cgroup tool

intel_cgroup is used to modify i915 cgroup parameters. At the moment only a single parameter is supported (GPU priority offset). In the future the driver may support additional parameters as well (e.g., limits on memory usage). Signed-off-by: Matt Roper ---

[Intel-gfx] [PATCH RFC v2 4/7] drm: Add helper to obtain cgroup of drm_file's owning process

Signed-off-by: Matt Roper --- include/drm/drm_file.h| 20 kernel/cgroup/cgroup_driver.c | 12 ++-- 2 files changed, 30 insertions(+), 2 deletions(-) diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h index

[Intel-gfx] [PATCH RFC v2 7/7] drm/i915: Add context priority & priority offset to debugfs

Update i915_context_status to include priority information. Signed-off-by: Matt Roper --- drivers/gpu/drm/i915/i915_debugfs.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index

[Intel-gfx] [PATCH RFC v2 6/7] drm/i915: Introduce 'priority offset' for GPU contexts

There are cases where a system integrator may wish to raise/lower the priority of GPU workloads being submitted by specific OS process(es), independently of how the software self-classifies its own priority. Exposing "priority offset" as an i915-specific cgroup parameter will enable such

[Intel-gfx] [PATCH RFC v2 5/7] drm/i915: cgroup integration

Register i915 as a consumer of the cgroup_driver framework and add an ioctl to allow userspace to set i915-specific parameters associated with cgroups. Signed-off-by: Matt Roper --- drivers/gpu/drm/i915/Kconfig | 1 + drivers/gpu/drm/i915/Makefile | 1 +

[Intel-gfx] [PATCH RFC v2 3/7] cgroup: Add interface to allow drivers to lookup process cgroup membership

Drivers will need to save/restore the appropriate cgroup data for the process submitting a driver request. Add an interface for drivers to determine the cgroup for the userspace process submitting a driver request. Cc: Tejun Heo Cc: cgro...@vger.kernel.org Signed-off-by: Matt

[Intel-gfx] [PATCH RFC v2 2/7] kernfs: Export kernfs_get_inode

Drivers may wish to access a cgroup's inode to perform permission checks on driver-specific operations. Cc: Tejun Heo Cc: cgro...@vger.kernel.org Signed-off-by: Matt Roper --- fs/kernfs/inode.c | 1 + 1 file changed, 1 insertion(+) diff --git

[Intel-gfx] [PATCH RFC v2 1/7] cgroup: Allow drivers to store data associated with a cgroup

There are cases where drivers need to adjust behavior or control device-specific resources according to the type of clients (processes) submitting requests. Linux cgroups are a natural fit for this type of resource control and policy management, so we need a way for drivers to associate their own

[Intel-gfx] [PATCH RFC v2 0/7] DRM management via cgroups

This is a second iteration of the patches originally posted here: https://lists.freedesktop.org/archives/intel-gfx/2018-January/153156.html Please see the original cover letter to understand the general goal and justification for this work. This series makes the following important

Re: [Intel-gfx] [PATCH v7 2/6] drm/i915/guc: Rename guc_ggtt_offset to intel_guc_ggtt_offset

On 01/31/2018 11:38 PM, Chris Wilson wrote: Quoting Jackie Li (2018-01-19 01:29:28) GuC related exported functions should start with "intel_guc_" prefix and pass intel_guc as the first parameter since its guc related. Current guc_ggtt_offset() failed to follow this code convention. But it was

Re: [Intel-gfx] [PATCH v7 1/6] drm/i915/guc: Move GuC WOPCM related code into separate files

On 01/31/2018 11:37 PM, Chris Wilson wrote: Quoting Jackie Li (2018-01-19 01:29:27) intel_guc_reg.h should only include definition for GuC registers and related register bits. GuC WOPCM related values should not be defined in intel_guc_reg.h GuC registers does not include GuC WOPCM? The code

Re: [Intel-gfx] [PATCH v7 2/6] drm/i915/guc: Rename guc_ggtt_offset to intel_guc_ggtt_offset

diff --git a/drivers/gpu/drm/i915/intel_guc_ads.c b/drivers/gpu/drm/i915/intel_guc_ads.c index ac62753..7215594 100644 --- a/drivers/gpu/drm/i915/intel_guc_ads.c +++ b/drivers/gpu/drm/i915/intel_guc_ads.c @@ -113,17 +113,6 @@ int intel_guc_ads_create(struct intel_guc *guc)  

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v2] drm/i915/guc: Allow preempt-client to be NULL (rev3)

== Series Details == Series: series starting with [v2] drm/i915/guc: Allow preempt-client to be NULL (rev3) URL : https://patchwork.freedesktop.org/series/37395/ State : failure == Summary == Series 37395v3 series starting with [v2] drm/i915/guc: Allow preempt-client to be NULL

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v2,1/2] drm/i915/bxt, glk: Increase PCODE timeouts during CDCLK freq changing

On Tue, Jan 30, 2018 at 10:11:49PM +, Patchwork wrote: > == Series Details == > > Series: series starting with [v2,1/2] drm/i915/bxt, glk: Increase PCODE > timeouts during CDCLK freq changing > URL : https://patchwork.freedesktop.org/series/37344/ > State : failure > > == Summary == > >

Re: [Intel-gfx] [PATCH v4 1/7] drm/i915: Add CRTC output format YCBCR 4:2:0

On Tue, Jan 30, 2018 at 03:05:57PM +0530, Shashank Sharma wrote: > From: "Sharma, Shashank" > > Currently, we are using a bool in CRTC state (state->ycbcr420), > to indicate modeset, that the output format is YCBCR 4:2:0. Now in > order to support other YCBCR formats,

Re: [Intel-gfx] [PATCH v4 7/7] drm/i915: Add YCBCR 4:2:0/4:4:4 support for LSPCON

On Tue, Jan 30, 2018 at 03:06:03PM +0530, Shashank Sharma wrote: > From: "Sharma, Shashank" > > LSPCON chips can generate YCBCR outputs, if asked nicely :). > > In order to generate YCBCR 4:2:0 outputs, a source must: > - send YCBCR 4:4:4 signals to LSPCON > - program

[Intel-gfx] [PATCH v2] drm/i915: Move the scheduler feature bits into the purview of the engines

Rather than having the high level ioctl interface guess the underlying implementation details, having the implementation declare what capabilities it exports. We define an intel_driver_caps, similar to the intel_device_info, which instead of trying to describe the HW gives details on what the

Re: [Intel-gfx] [PATCH v2 2/3] drm/i915: Move the scheduler feature bits into the purview of the engines

Quoting Mika Kuoppala (2018-01-31 13:58:17) > Chris Wilson writes: > > > Rather than having the high level ioctl interface guess the underlying > > implementation details, having the implementation declare what > > capabilities it exports. We define an

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Enable inject_load_failure only in DEBUG config

== Series Details == Series: drm/i915: Enable inject_load_failure only in DEBUG config URL : https://patchwork.freedesktop.org/series/37495/ State : success == Summary == Series 37495v1 drm/i915: Enable inject_load_failure only in DEBUG config

Re: [Intel-gfx] [PATCH v2 1/2] drm/i915/bxt, glk: Increase PCODE timeouts during CDCLK freq changing

On Tue, Jan 30, 2018 at 04:29:38PM +0200, Imre Deak wrote: > Currently we see sporadic timeouts during CDCLK changing both on BXT and > GLK as reported by the Bugzilla: ticket. It's easy to reproduce this by > changing the frequency in a tight loop after blanking the display. The > upper bound for

Re: [Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/6] disable-gem-trace (rev2)

Quoting Patchwork (2018-02-01 17:52:06) > shard-apltotal:2838 pass:1750 dwarn:1 dfail:0 fail:23 skip:1064 > time:12757s > shard-hswtotal:2838 pass:1735 dwarn:1 dfail:0 fail:11 skip:1090 > time:12008s > shard-snbtotal:2838 pass:1328 dwarn:2 dfail:0 fail:10

Re: [Intel-gfx] clang warning: implicit conversion in intel_ddi.c:1481

On Thu, Feb 01, 2018 at 06:33:30PM +0100, Ozan Alpay wrote: > Dear Rodrigo Vivi, Ville Syrjälä, > > My name is Ozan Alpay, and I am a student mentored by Lukas Bulwahn. We > intend to use static analysis tools on the kernel source to identify, > analyze and report issues. As a very first step,

Re: [Intel-gfx] i915 PSR test results and cursor lag

Quoting Andy Lutomirski (2018-02-01 17:40:22) > *However*, I do see one unfortunate side effect of turning on PSR. It > seems that, when I move my cursor a little bit after a few seconds of > doing nothing, there seems to be a little bit of lag, as if either a > few frames are dropped at the

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/6] disable-gem-trace (rev2)

== Series Details == Series: series starting with [1/6] disable-gem-trace (rev2) URL : https://patchwork.freedesktop.org/series/37473/ State : success == Summary == Test kms_sysfs_edid_timing: warn -> PASS (shard-apl) fdo#100047 Test gem_eio: Subgroup

Re: [Intel-gfx] [PATCH] drm/i915: Enable inject_load_failure only in DEBUG config

Quoting Michal Wajdeczko (2018-02-01 17:45:52) > On Thu, 01 Feb 2018 18:42:00 +0100, Chris Wilson > wrote: > > > Quoting Michal Wajdeczko (2018-02-01 17:32:48) > >> We're using i915_inject_load_failure() to inject dummy > >> faults during driver load, but since this

Re: [Intel-gfx] [PATCH] drm/i915: Enable inject_load_failure only in DEBUG config

On Thu, 01 Feb 2018 18:42:00 +0100, Chris Wilson wrote: Quoting Michal Wajdeczko (2018-02-01 17:32:48) We're using i915_inject_load_failure() to inject dummy faults during driver load, but since this is debug utility we shouldn't expose it in default config as it

Re: [Intel-gfx] i915 PSR test results and cursor lag

On Thu, Feb 1, 2018 at 9:40 AM, Andy Lutomirski wrote: > Hi- > > As requested in your blog post, I tested PSR. I see something like > 2.69W with PSR off and 2.17W with PSR on. Screen blanking, > suspend/resume, and the contents of the screen all seem okay. This is > a Dell XPS

Re: [Intel-gfx] [PATCH] drm/i915: Enable inject_load_failure only in DEBUG config

Quoting Michal Wajdeczko (2018-02-01 17:32:48) > We're using i915_inject_load_failure() to inject dummy > faults during driver load, but since this is debug utility > we shouldn't expose it in default config as it consumes > both code and data. > > add/remove: 0/1 grow/shrink: 0/2 up/down: 0/-302

[Intel-gfx] i915 PSR test results and cursor lag

Hi- As requested in your blog post, I tested PSR. I see something like 2.69W with PSR off and 2.17W with PSR on. Screen blanking, suspend/resume, and the contents of the screen all seem okay. This is a Dell XPS 13 9350, i.e.: System Information Manufacturer: Dell Inc. Product

[Intel-gfx] [PATCH] drm/i915: Enable inject_load_failure only in DEBUG config

We're using i915_inject_load_failure() to inject dummy faults during driver load, but since this is debug utility we shouldn't expose it in default config as it consumes both code and data. add/remove: 0/1 grow/shrink: 0/2 up/down: 0/-302 (-302) Function old

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Fix plane regression

== Series Details == Series: drm/i915: Fix plane regression URL : https://patchwork.freedesktop.org/series/37492/ State : failure == Summary == Applying: drm/i915: Add .get_hw_state() method for planes error: sha1 information is lacking or useless (drivers/gpu/drm/i915/intel_display.c).

[Intel-gfx] [PATCH stable-4.14 0/3] drm/i915: Fix plane regression

From: Ville Syrjälä These backports fix a plane related regression causing a corrupted screen and bunch of WARNs from the kernel on some pre-i965 era hardware. Cc: # 4.14 Ville Syrjälä (3): drm/i915: Add .get_hw_state() method for

[Intel-gfx] [PATCH stable-4.14 3/3] drm/i915: Fix deadlock in i830_disable_pipe()

From: Ville Syrjälä i830_disable_pipe() gets called from the power well code, and thus we're already holding the power domain mutex. That means we can't call plane->get_hw_state() as it will also try to grab the same mutex and will thus deadlock. Replace the

[Intel-gfx] [PATCH stable-4.14 2/3] drm/i915: Redo plane sanitation during readout

From: Ville Syrjälä Unify the plane disabling during state readout by pulling the code into a new helper intel_plane_disable_noatomic(). We'll also read out the state of all planes, so that we know which planes really need to be diabled. Additonally we change the

[Intel-gfx] [PATCH stable-4.14 1/3] drm/i915: Add .get_hw_state() method for planes

From: Ville Syrjälä Add a .get_hw_state() method for planes, returning true or false depending on whether the plane is enabled. Use it to rewrite the plane enabled/disabled asserts in platform agnostic fashion. We do lose the pre-gen4 plane<->pipe mapping checks,

Re: [Intel-gfx] [PATCH] drm/i915: Add option to list load failure checkpoints

Quoting Michal Wajdeczko (2018-02-01 15:51:58) > I was assuming these steps: > > 1. add new failure checkpoint(s) to the code > 2. boot driver with inject modparam=-1 to list active checkpoints > 3. note the number of checkpoint that we want to trigger > 4. boot driver with inject modparam=n to

[Intel-gfx] [PATCH v11] drm/i915/icl: Gen11 forcewake support

From: Daniele Ceraolo Spurio The main difference with previous GENs is that starting from Gen11 each VCS and VECS engine has its own power well, which only exist if the related engine exists in the HW. The fallback forcewake request workaround is only needed on

Re: [Intel-gfx] [PATCH v10] drm/i915/icl: Gen11 forcewake support

On 2/1/2018 2:25 AM, Tvrtko Ursulin wrote: On 01/02/2018 00:52, Michel Thierry wrote: From: Daniele Ceraolo Spurio The main difference with previous GENs is that starting from Gen11 each VCS and VECS engine has its own power well, which only exist if the

Re: [Intel-gfx] [PATCH] drm/i915: Add option to list load failure checkpoints

On Thu, 01 Feb 2018 16:28:31 +0100, Chris Wilson wrote: Quoting Michal Wajdeczko (2018-02-01 14:47:05) On Wed, 31 Jan 2018 21:48:42 +0100, Chris Wilson wrote: > Quoting Michal Wajdeczko (2018-01-31 18:23:47) >> Our inject_load_failure

Re: [Intel-gfx] [PATCH] drm/i915: Add option to list load failure checkpoints

Quoting Michal Wajdeczko (2018-02-01 14:47:05) > On Wed, 31 Jan 2018 21:48:42 +0100, Chris Wilson > wrote: > > > Quoting Michal Wajdeczko (2018-01-31 18:23:47) > >> Our inject_load_failure functionality allows to insert one > >> failure during driver load, but it is

Re: [Intel-gfx] [PATCH 0/3] drm/i915/dp: refactoring + respect vbt max dp rate

On Thu, Feb 01, 2018 at 11:03:40AM +, Jani Nikula wrote: > Hi Rodrigo, this is what I had in mind for the DP CNL and VBT rate limiting, I > hope you don't mind me writing the patches. It was easier to express myself > in C > than English. of course I don't mind. Thanks for the clean version.

Re: [Intel-gfx] [PATCH 3/3] drm/i915/dp: limit DP link rate based on VBT on CNL+

On Thu, Feb 01, 2018 at 11:03:43AM +, Jani Nikula wrote: > We have the max DP link rate info available in VBT since BDB version > 216, included in child device config since commit c4fb60b9aba9 > ("drm/i915/bios: add DP max link rate to VBT child device > struct"). Parse it and use it. > > Cc:

Re: [Intel-gfx] [PATCH 2/3] drm/i915/dp: clean up source rate limiting for cnl

On Thu, Feb 01, 2018 at 11:03:42AM +, Jani Nikula wrote: > Make the limiting rate based instead of messing with the array size. > > Cc: Ville Syrjälä > Cc: Rodrigo Vivi > Cc: Dhinakaran Pandiyan >

Re: [Intel-gfx] [PATCH 1/3] drm/i915/dp: abstract rate array length limiting

On Thu, Feb 01, 2018 at 11:03:41AM +, Jani Nikula wrote: > This will be useful later on. Also move the functions around to not need > forward declarations in subsequent patches. No functional changes. > > Cc: Ville Syrjälä > Cc: Rodrigo Vivi

Re: [Intel-gfx] [PATCH 3/5] drm/i915/guc: Use correct error code for GuC initialization failure

On 2/1/2018 7:53 PM, Michal Wajdeczko wrote: On Thu, 01 Feb 2018 13:35:15 +0100, Chris Wilson wrote: Quoting Sagar Arun Kamble (2018-02-01 11:48:54) On 1/31/2018 11:02 PM, Michal Wajdeczko wrote: > Since commit 6ca9a2beb5 ("drm/i915: Unwind i915_gem_init()

Re: [Intel-gfx] [PATCH 1/5] drm/i915/uc: Add few more load failure checkpoints

Thanks for clarification. On 2/1/2018 7:57 PM, Michal Wajdeczko wrote: On Thu, 01 Feb 2018 12:43:29 +0100, Sagar Arun Kamble wrote: On 1/31/2018 11:02 PM, Michal Wajdeczko wrote: Additional load failure checkpoints added into uC initialization sequence should

Re: [Intel-gfx] [PATCH] drm/i915: Add option to list load failure checkpoints

On Wed, 31 Jan 2018 21:48:42 +0100, Chris Wilson wrote: Quoting Michal Wajdeczko (2018-01-31 18:23:47) Our inject_load_failure functionality allows to insert one failure during driver load, but it is hard to guess which number should passed as modparam to select

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Less verbose engine startup

== Series Details == Series: drm/i915: Less verbose engine startup URL : https://patchwork.freedesktop.org/series/37476/ State : success == Summary == Test kms_cursor_legacy: Subgroup flip-vs-cursor-crc-atomic: pass -> FAIL (shard-apl) fdo#102670 Test perf:

Re: [Intel-gfx] [PATCH] drm/atomic: Fix memleak on ERESTARTSYS during non-blocking commits

On 2018-02-01 05:30 AM, Maarten Lankhorst wrote: > Op 31-01-18 om 20:57 schreef Harry Wentland: >> On 2018-01-30 05:28 AM, Maarten Lankhorst wrote: >>> Op 29-01-18 om 16:41 schreef Leo Li: Updated IGT results seem sane: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7698/shards.html

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/6] disable-gem-trace (rev2)

== Series Details == Series: series starting with [1/6] disable-gem-trace (rev2) URL : https://patchwork.freedesktop.org/series/37473/ State : success == Summary == Series 37473v2 series starting with [1/6] disable-gem-trace

Re: [Intel-gfx] [PATCH 1/5] drm/i915/uc: Add few more load failure checkpoints

On Thu, 01 Feb 2018 12:43:29 +0100, Sagar Arun Kamble wrote: On 1/31/2018 11:02 PM, Michal Wajdeczko wrote: Additional load failure checkpoints added into uC initialization sequence should help us verify correctness of error handling. Signed-off-by: Michal

Re: [Intel-gfx] [PATCH 3/5] drm/i915/guc: Use correct error code for GuC initialization failure

On Thu, 01 Feb 2018 13:35:15 +0100, Chris Wilson wrote: Quoting Sagar Arun Kamble (2018-02-01 11:48:54) On 1/31/2018 11:02 PM, Michal Wajdeczko wrote: > Since commit 6ca9a2beb5 ("drm/i915: Unwind i915_gem_init() failure") > we believed that we correctly handle

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/dp: refactoring + respect vbt max dp rate

== Series Details == Series: drm/i915/dp: refactoring + respect vbt max dp rate URL : https://patchwork.freedesktop.org/series/37475/ State : success == Summary == Test gem_exec_schedule: Subgroup preempt-other-vebox: pass -> FAIL (shard-apl) fdo#102848

[Intel-gfx] [PATCH v2] drm/i915/selftests: Use a sacrificial context for hang testing

Avoid injecting hangs in to the i915->kernel_context in case the GPU reset leaves corruption in the context image in its wake (leading to continual failures and system hangs after the selftests are ostensibly complete). Use a sacrificial kernel_context instead. v2: Closing a context is tricky;

Re: [Intel-gfx] [RFC] drm/i915/pmu: Micro-optimize sampling loop

On 31/01/2018 16:07, Chris Wilson wrote: Quoting Tvrtko Ursulin (2018-01-31 16:02:38) From: Tvrtko Ursulin By carefully chosing slightly unsynchronized values for timer frequency and period, we can remove the multiplications from the sampling loop and replace them

[Intel-gfx] ✗ Fi.CI.IGT: warning for series starting with [1/6] disable-gem-trace

== Series Details == Series: series starting with [1/6] disable-gem-trace URL : https://patchwork.freedesktop.org/series/37473/ State : warning == Summary == Test gem_eio: Subgroup in-flight-contexts: fail -> PASS (shard-hsw) fdo#104676 Subgroup

Re: [Intel-gfx] [PATCH 1/7] drm/i915: Don't set cursor pipe select bits on g4x+

On Tue, 2018-01-30 at 22:38 +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > G4x cursor control registers still allow us to write to the pipe > select > bits even though cursors are supposed to be fixed to a specific pipe. > Bspec tells us that we should only

Re: [Intel-gfx] [PATCH 3/3] drm/i915/dp: limit DP link rate based on VBT on CNL+

On Thu, Feb 01, 2018 at 01:03:43PM +0200, Jani Nikula wrote: > We have the max DP link rate info available in VBT since BDB version > 216, included in child device config since commit c4fb60b9aba9 > ("drm/i915/bios: add DP max link rate to VBT child device > struct"). Parse it and use it. > > Cc:

Re: [Intel-gfx] [PATCH 4/5] drm/i915/guc: Don't try to create log runtime if there is no log

Quoting Michal Wajdeczko (2018-01-31 17:32:39) > In case of GuC initialization failure we may continue with driver > load, but we wrongly assume that GuC is fully functional. This > leads to the BUG as we attempt to access non-existing log vma. > > [26386.121085] BUG: unable to handle kernel NULL

Re: [Intel-gfx] [PATCH 3/5] drm/i915/guc: Use correct error code for GuC initialization failure

Quoting Sagar Arun Kamble (2018-02-01 11:48:54) > > > On 1/31/2018 11:02 PM, Michal Wajdeczko wrote: > > Since commit 6ca9a2beb5 ("drm/i915: Unwind i915_gem_init() failure") > > we believed that we correctly handle all errors encountered during > > GuC initialization, including special one that

[Intel-gfx] Enabling i915 Panel Self Refresh by default on some devices ?

Hi All, As you may have heard I've recently been working on improving Linux laptop battery life, specifically the OOTB experience without tweaking any options such as e.g. powertop --auto-tune would do, see: https://fedoraproject.org/wiki/Changes/ImprovedLaptopBatteryLife So far this is going

  1   2   >