[Intel-gfx] ✓ Fi.CI.IGT: success for ICP initial support (rev2)

== Series Details == Series: ICP initial support (rev2) URL : https://patchwork.freedesktop.org/series/36350/ State : success == Summary == Test kms_flip: Subgroup 2x-vblank-vs-dpms-suspend: skip -> PASS (shard-hsw) Subgroup plain-flip-fb-recreate:

[Intel-gfx] ✗ Fi.CI.BAT: warning for DRM management via cgroups

== Series Details == Series: DRM management via cgroups URL : https://patchwork.freedesktop.org/series/36837/ State : warning == Summary == Series 36837v1 DRM management via cgroups https://patchwork.freedesktop.org/api/1.0/series/36837/revisions/1/mbox/ Test core_auth: Subgroup

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Implement display w/a #1143

== Series Details == Series: drm/i915: Implement display w/a #1143 URL : https://patchwork.freedesktop.org/series/36813/ State : failure == Summary == Test kms_frontbuffer_tracking: Subgroup fbc-1p-offscren-pri-shrfb-draw-render: fail -> PASS (shard-snb)

[Intel-gfx] [PATCH RFC 9/9] drm/i915: Add context priority to debugfs

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

[Intel-gfx] [PATCH RFC 8/9] drm/i915: Allow default context priority to be set via cgroup parameter

GPU contexts are usually created with "normal" priority as a starting point and then may be adjusted from their either via explicit methods (context_set_param) or implicit methods (boosts/penalization due to runtime behavior). Let's allow a system integrator to override this starting GPU priority

[Intel-gfx] [PATCH RFC 2/9] cgroup: Add notifier call chain for cgroup destruction

Drivers or other kernel subsystems may allow subsystem-specific policy and configuration to be applied to cgroups. If these subsystems track private data on a per-cgroup basis, they need a way to be notified about cgroup destruction so that they can clean up their own internal data for that

[Intel-gfx] [PATCH RFC 5/9] drm: Introduce DRM_IOCTL_CGROUP_SETPARAM

cgroups are a convenient mechanism for system integrators to organize processes into a logical hierarchy for system configuration purposes. cgroups can be used to control resources (memory, cpu time share, etc.) or apply other types of subsystem-specific policy (network priorty, BPF programs,

[Intel-gfx] [PATCH RFC 6/9] drm: Add cgroup helper library

Most DRM drivers will want to handle the CGROUP_SETPARAM ioctl by looking up a driver-specific per-cgroup data structure (or allocating a new one) and storing the supplied parameter value into the data structure (possibly after doing some checking and sanitization on the provided value). Let's

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

Cc: Tejun Heo Cc: cgro...@vger.kernel.org Signed-off-by: Matt Roper --- include/drm/drm_file.h | 28 1 file changed, 28 insertions(+) diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h index

[Intel-gfx] [PATCH RFC 1/9] 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 3/9] cgroup: Export cgroup_on_dfl() to drivers

Drivers may wish to limit their own cgroup operations to cgroups in the cgroup-v2 hierarchy. Let's make this helper function usable outside the cgroup core code. Cc: Tejun Heo Cc: cgro...@vger.kernel.org Signed-off-by: Matt Roper ---

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

cgroups are core kernel mechanism that allows a system integrator / system administrator to collect OS processes into a hierarchy of groups according to their intended role in the overall system; resource management and policy configuration can then be applied to each cgroup independently. The

[Intel-gfx] [PATCH RFC 4/9] cgroup: Export task_cgroup_from_root() and cgroup_mutex for drivers

Drivers that handle processes on a per-cgroup basis need to be able to lookup the cgroup that a process belongs to. Cc: Tejun Heo Cc: cgro...@vger.kernel.org Signed-off-by: Matt Roper --- include/linux/cgroup.h | 5 -

[Intel-gfx] ✓ Fi.CI.BAT: success for scripts/trace.pl: Re-order calculations and fixups

== Series Details == Series: scripts/trace.pl: Re-order calculations and fixups URL : https://patchwork.freedesktop.org/series/36829/ State : success == Summary == IGT patchset tested on top of latest successful build 94bd67c5d6184c435c2fed0bfb39d75b3138b7a8 tools/intel_vbt_decode: update vbt

Re: [Intel-gfx] [PATCH 02/15] drm/i915/skl+: refactor WM calculation for NV12

Hi Mahesh, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on drm-intel/for-linux-next] [also build test WARNING on v4.15-rc8 next-20180119] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [01/10] drm/i915/cnl: Add Cannonlake PCI IDs for another SKU.

== Series Details == Series: series starting with [01/10] drm/i915/cnl: Add Cannonlake PCI IDs for another SKU. URL : https://patchwork.freedesktop.org/series/36828/ State : success == Summary == Series 36828v1 series starting with [01/10] drm/i915/cnl: Add Cannonlake PCI IDs for another

[Intel-gfx] [PATCH i-g-t 4/4] scripts/trace.pl: Simplify 'end' & 'notify' generation

From: John Harrison Delay the auto-generation of end/notify values until the point where everything is known. As opposed to potentially generating them multiple times with differing values. Signed-off-by: John Harrison Cc: Tvrtko Ursulin

[Intel-gfx] [PATCH i-g-t 3/4] scripts/trace.pl: Calculate stats only after all munging

From: John Harrison There are various statistics being calculated multiple times in multiple places while the log file is being read in. Some of these are then re-calculated when the database is munged to correct various issues with the logs. This patch consolidates

[Intel-gfx] [PATCH i-g-t 2/4] scripts/trace.pl: Sort order

From: John Harrison Add an extra level to the databse key sort so that the ordering is deterministic. If the time stamp matches, it now compares the key itself as well (context/seqno). This makes it much easier to determine if a change has actually broken anything.

[Intel-gfx] [PATCH i-g-t 1/4] scripts/trace.pl: More hash key optimisations

From: John Harrison Cache the key count value rather than querying the hash every time. Also assert that the database does not magically change size after the fixups. Signed-off-by: John Harrison Cc: Tvrtko Ursulin

[Intel-gfx] [PATCH i-g-t 0/4] scripts/trace.pl: Re-order calculations and fixups

From: John Harrison The trace.pl script calculates a bunch of statistics. It also re-generates some timestamp values to correct issues with the log being processed. These operations were all mixed up together thus some were done multiple times (with different results

[Intel-gfx] [PATCH 05/10] drm/i915/cnl: Add right GMBUS pin number for HDMI on Port F.

On CNP Pin 3 is for misc of Port F usage depending on the configuration. For CNL that uses Port F, pin 3 is the one. v2: Make it more generic and update commit message. Cc: Anusha Srivatsa Cc: Lucas De Marchi Cc: Manasi Navare

[Intel-gfx] [PATCH 07/10] drm/i915/cnl: Add HPD support for Port F.

On CNP boards that are using DDI F, bit 25 (SDE_PORTE_HOTPLUG_SPT) is representing the Digital Port F hotplug line when the Digital Port F hotplug detect input is enabled. v2: Reuse all existent structure instead of adding a new HPD_PORT_F pointing to pin of port E. v3: Use IS_CNL_WITH_PORT_F so

[Intel-gfx] [PATCH 02/10] drm/i915/cnl: Add AUX-F support

On some Cannonlake SKUs we have a dedicated Aux for port F, that is only the full split between port A and port E. There is still no Aux E for Port E, as in previous platforms, because port_E still means shared lanes with port A. v2: Rebase. v3: Add couple missed PORT_F cases on intel_dp. v4:

[Intel-gfx] [PATCH 03/10] drm/i915/cnl: Fix _CNL_PORT_TX_DW2_LN0_F definition.

This was wrong since its introduction on commit '04416108ccea ("drm/i915/cnl: Add registers related to voltage swing sequences.")' But since no Port F was needed so far we don't need to propagate fixes back there. Cc: Lucas De Marchi Cc: Manasi Navare

[Intel-gfx] [PATCH 10/10] drm/i915/cnl: Don't try to manage Port F power wells on all CNL.

SKUs that lacks on the full port F split will just time out when touching this power well bits, causing a noisy warn. This macro style is a deviation from the original definition in use for other platforms, but it at least avoid code duplication. Other smart alternatives like providing a joint

[Intel-gfx] [PATCH 08/10] drm/i915/cnl: Enable DDI-F on Cannonlake.

Now let's finish the Port-F support by adding the proper port F detection, irq and power well support. v2: Rebase v3: Use BIT_ULL v4: Cover missed case on ddi init. v5: Update commit message. v6: Rebase on top of display headers rework. Cc: Manasi Navare Cc: Ville

[Intel-gfx] [PATCH 01/10] drm/i915/cnl: Add Cannonlake PCI IDs for another SKU.

The only difference is that this SKUs has the full Port A/E split named as Port F. But since SKUs differences don't matter on the platform definition group and ids, let's merge all off them together. v2: Really include the PCI IDs to the picidlist[]; v3: Add the PCI Id for another SKU (Anusha).

[Intel-gfx] [PATCH 09/10] drm/i915/cnl: Fix DP max rate for Cannonlake with port F.

On CNL SKUs that uses port F, max DP rate is 8.1G for all ports when we have the elevated voltage. v2: Make commit message more generic. Cc: Lucas De Marchi Cc: Manasi Navare Signed-off-by: Rodrigo Vivi ---

[Intel-gfx] [PATCH 04/10] drm/i915: Fix DPLCLKA_CFGCR0 bits for Port F.

Since when it got introduced with commit '555e38d27317 ("drm/i915/cnl: DDI - PLL mapping")' the support for Port F was wrong, because Port F bits are far from bits used for A to E. Since Port F is not used so far we don't need to propagate Fixes back there. v2: Reuse _SHIFT definition to avoid

[Intel-gfx] [PATCH 06/10] drm/i915: For HPD connected port use hpd_pin instead of port.

Let's try to simplify this mapping to hpd_pin -> bit instead using port. So for CNL with port F where we have this port using hdp_pin and bits of other ports we don't need to duplicated the mapping. But for now this is only a re-org with no functional change expected. Cc: Lucas De Marchi

[Intel-gfx] ✗ Fi.CI.BAT: failure for igt/gen7_forcewake_mt: Make the mmio register as volatile

== Series Details == Series: igt/gen7_forcewake_mt: Make the mmio register as volatile URL : https://patchwork.freedesktop.org/series/36826/ State : failure == Summary == IGT patchset tested on top of latest successful build 94bd67c5d6184c435c2fed0bfb39d75b3138b7a8 tools/intel_vbt_decode:

[Intel-gfx] [PATCH igt] igt/gen7_forcewake_mt: Make the mmio register as volatile

Prevent the compiler from caching reads/writes to the hw register as we do want to perform mmio. Signed-off-by: Chris Wilson --- tests/gen7_forcewake_mt.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/tests/gen7_forcewake_mt.c

Re: [Intel-gfx] [PATCH v3] drm/i915/icl: Set graphics mode register for gen11

On 19/01/18 11:30, Kelvin Gardiner wrote: This patch clears a single bit. The bit is 0 by default but expected not to be set. Explicitly clearing the bit in this patch is intended to indicate some thinking has occurred, and that we want this bit cleared and we are not just excepting the

Re: [Intel-gfx] [PATCH 5/5] drm/i915: Estimate and update missed vblanks.

On Fri, Jan 19, 2018 at 09:42:14PM +, Pandiyan, Dhinakaran wrote: > On Thu, 2018-01-18 at 23:26 -0800, Rodrigo Vivi wrote: > > On Fri, Jan 12, 2018 at 09:57:07PM +, Dhinakaran Pandiyan wrote: > > > The frame counter may have got reset between disabling and enabling vblank > > > interrupts

Re: [Intel-gfx] [PATCH 4/5] drm/vblank: Restoring vblank counts after device PM events.

On Fri, Jan 19, 2018 at 10:02:12PM +, Pandiyan, Dhinakaran wrote: > > > > On Fri, 2018-01-19 at 00:01 -0800, Rodrigo Vivi wrote: > > On Fri, Jan 12, 2018 at 09:57:06PM +, Dhinakaran Pandiyan wrote: > > > The HW frame counter can get reset if device enters a low power state > > > after

Re: [Intel-gfx] [PATCH 4/5] drm/vblank: Restoring vblank counts after device PM events.

On Fri, 2018-01-19 at 00:01 -0800, Rodrigo Vivi wrote: > On Fri, Jan 12, 2018 at 09:57:06PM +, Dhinakaran Pandiyan wrote: > > The HW frame counter can get reset if device enters a low power state after > > vblank interrupts were disabled. This messes up any following vblank count > > update

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/2] drm/i915: Track the number of times we have woken the GPU up

== Series Details == Series: series starting with [1/2] drm/i915: Track the number of times we have woken the GPU up URL : https://patchwork.freedesktop.org/series/36802/ State : failure == Summary == Warning: bzip CI_DRM_3658/shard-glkb6/results22.json.bz2 wasn't in correct JSON format

Re: [Intel-gfx] [PATCH 5/5] drm/i915: Estimate and update missed vblanks.

On Thu, 2018-01-18 at 23:26 -0800, Rodrigo Vivi wrote: > On Fri, Jan 12, 2018 at 09:57:07PM +, Dhinakaran Pandiyan wrote: > > The frame counter may have got reset between disabling and enabling vblank > > interrupts due to DMC putting the hardware to DC5/6 state if PSR was > > active. The

Re: [Intel-gfx] [PATCH 1/5] drm/vblank: Fix return type for drm_vblank_count()

On Thu, 2018-01-18 at 23:36 -0800, Rodrigo Vivi wrote: > On Fri, Jan 12, 2018 at 09:57:03PM +, Dhinakaran Pandiyan wrote: > > drm_vblank_count() has a u32 type returning what is a 64-bit vblank count. > > The effect of this is when drm_wait_vblank_ioctl() tries to widen the user > > space

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Shrink the request kmem_cache on allocation error

== Series Details == Series: drm/i915: Shrink the request kmem_cache on allocation error URL : https://patchwork.freedesktop.org/series/36800/ State : success == Summary == Warning: bzip CI_DRM_3658/shard-glkb6/results22.json.bz2 wasn't in correct JSON format Test kms_frontbuffer_tracking:

Re: [Intel-gfx] [PATCH 2/6] drm/i915: Allow clients to query own per-engine busyness

Quoting Tvrtko Ursulin (2018-01-19 13:45:24) > + case I915_CONTEXT_GET_ENGINE_BUSY: > + engine = intel_engine_lookup_user(i915, args->class, > + args->instance); > + if (!engine) { > + ret =

Re: [Intel-gfx] [PATCH v5 1/6] drm/i915: Track per-context engine busyness

Quoting Tvrtko Ursulin (2018-01-19 16:26:16) > From: Tvrtko Ursulin > > Some customers want to know how much of the GPU time are their clients > using in order to make dynamic load balancing decisions. > > With the hooks already in place which track the overall engine

Re: [Intel-gfx] [PATCH] drm/i915: vbt defs typo fixes

On Fri, 2018-01-19 at 10:17 +0200, Jani Nikula wrote: > On Thu, 18 Jan 2018, Adam Jackson wrote: > > On Thu, 2018-01-18 at 17:06 +0200, Jani Nikula wrote: > > > No more sing-a-ling. > > > > > > Reported-by: Adam Jackson > > > > Why'd you omit the typos I

Re: [Intel-gfx] [RFC] drm/i915/guc: Keep GuC log disabled by default

Quoting Michał Winiarski (2018-01-19 13:36:27) > On Fri, Jan 19, 2018 at 12:49:26PM +, Michal Wajdeczko wrote: > > It looks that GuC log functionality is not fully functional yet and > > causes issues when enabled by auto(-1) modparam on debug builds. > > > > [ 30.062893]

Re: [Intel-gfx] [PATCH] drm/i915: Implement display w/a #1143

Yes, this applies to CFL also. CFL follows on from KBL and doesn't have any display changes, so for the workarounds you can translate KBL:All to CFL:All. There is a note about that. -Original Message- From: Vivi, Rodrigo Sent: Friday, 19 January, 2018 12:08 PM To: Ville Syrjala

Re: [Intel-gfx] [PATCH 07/27] drm/i915/icl: Interrupt handling

Quoting Paulo Zanoni (2018-01-19 18:10:51) > Em Sex, 2018-01-19 às 17:30 +, Tvrtko Ursulin escreveu: > > On 10/01/2018 10:16, Joonas Lahtinen wrote: > > > If these are in a later patch, should be squashed here. > > > > It might be possible in some cases, or it might be quite challenging > >

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: expose RCS topology to userspace

== Series Details == Series: drm/i915: expose RCS topology to userspace URL : https://patchwork.freedesktop.org/series/36793/ State : success == Summary == Warning: bzip CI_DRM_3658/shard-glkb6/results22.json.bz2 wasn't in correct JSON format Test perf: Subgroup oa-exponents:

Re: [Intel-gfx] [PATCH 0/8] ICP initial support

Em Qui, 2018-01-11 às 16:00 -0200, Paulo Zanoni escreveu: > Hi > > This series adds the initial support for ICP. No conflicts with the > other > series. Patches 1 and 2 are parts of other series that we've already > been > discussing on this mailing list, but I put them here so CI can do the >

Re: [Intel-gfx] [PATCH] drm/i915: Implement display w/a #1143

On Fri, Jan 19, 2018 at 06:45:49PM +, Ville Syrjala wrote: > From: Ville Syrjälä > > Apparently SKL/KBL need some manual help to get the > programmed HDMI vswing to stick. Implement the relevant > workaround (display w/a #1143). > > Note that the relevant

Re: [Intel-gfx] [PATCH 6/8] drm/i915/icp: Add backlight Support for ICP

On Fri, Jan 19, 2018 at 06:48:12PM +, Paulo Zanoni wrote: > From: Anusha Srivatsa > > ICP has two backlight controllers - similar to previous platforms like > BXT -, but we only use one controller for now, so we can just reuse > the CNP code. > > v2: Remove the

[Intel-gfx] ✓ Fi.CI.BAT: success for ICP initial support (rev2)

== Series Details == Series: ICP initial support (rev2) URL : https://patchwork.freedesktop.org/series/36350/ State : success == Summary == Series 36350v2 ICP initial support https://patchwork.freedesktop.org/api/1.0/series/36350/revisions/2/mbox/ Test debugfs_test: Subgroup

Re: [Intel-gfx] [PATCH 6/8] drm/i915/icp: Add backlight Support for ICP

On Fri, Jan 19, 2018 at 10:48 AM, Paulo Zanoni wrote: > > From: Anusha Srivatsa > > ICP has two backlight controllers - similar to previous platforms like > BXT -, but we only use one controller for now, so we can just reuse > the CNP code. >

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/guc: Keep GuC log disabled by default

== Series Details == Series: drm/i915/guc: Keep GuC log disabled by default URL : https://patchwork.freedesktop.org/series/36796/ State : failure == Summary == Warning: bzip CI_DRM_3658/shard-glkb6/results22.json.bz2 wasn't in correct JSON format Test pm_rps: Subgroup reset:

[Intel-gfx] [PATCH v3] drm/i915/icl: Set graphics mode register for gen11

This patch clears a single bit. The bit is 0 by default but expected not to be set. Explicitly clearing the bit in this patch is intended to indicate some thinking has occurred, and that we want this bit cleared and we are not just excepting the default value. v2 (from Paulo): fix indentation.

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Implement display w/a #1143

== Series Details == Series: drm/i915: Implement display w/a #1143 URL : https://patchwork.freedesktop.org/series/36813/ State : success == Summary == Series 36813v1 drm/i915: Implement display w/a #1143 https://patchwork.freedesktop.org/api/1.0/series/36813/revisions/1/mbox/ Test

[Intel-gfx] [PATCH 6/8] drm/i915/icp: Add backlight Support for ICP

From: Anusha Srivatsa ICP has two backlight controllers - similar to previous platforms like BXT -, but we only use one controller for now, so we can just reuse the CNP code. v2: Remove the usage of ICP_SECOND_PPS_BACKLIGHT register.(Jani) Reuse CNP code since it is

[Intel-gfx] [PATCH] drm/i915: Implement display w/a #1143

From: Ville Syrjälä Apparently SKL/KBL need some manual help to get the programmed HDMI vswing to stick. Implement the relevant workaround (display w/a #1143). Note that the relevant chicken bits live in a transcoder register even though the bits affect a specific

Re: [Intel-gfx] [PATCH 6/8] drm/i915/icp: Add backlight Support for ICP

>-Original Message- >From: Zanoni, Paulo R >Sent: Friday, January 19, 2018 10:25 AM >To: Vivi, Rodrigo ; Srivatsa, Anusha > >Cc: Ausmus, James ; Nikula, Jani >;

Re: [Intel-gfx] [PATCH 6/8] drm/i915/icp: Add backlight Support for ICP

Em Sex, 2018-01-19 às 09:56 -0800, Rodrigo Vivi escreveu: > On Fri, Jan 19, 2018 at 05:26:02PM +, Anusha Srivatsa wrote: > > On Fri, Jan 19, 2018 at 02:40:41PM -0200, Paulo Zanoni wrote: > > > Em Qui, 2018-01-11 às 15:57 -0800, Rodrigo Vivi escreveu: > > > > On Thu, Jan 11, 2018 at 09:48:57PM

Re: [Intel-gfx] [PATCH 6/8] drm/i915/icp: Add backlight Support for ICP

On Fri, Jan 19, 2018 at 09:26:02AM -0800, Anusha Srivatsa wrote: > On Fri, Jan 19, 2018 at 02:40:41PM -0200, Paulo Zanoni wrote: > > Em Qui, 2018-01-11 às 15:57 -0800, Rodrigo Vivi escreveu: > > > On Thu, Jan 11, 2018 at 09:48:57PM +, James Ausmus wrote: > > > > On Thu, Jan 11, 2018 at

Re: [Intel-gfx] [PATCH 07/27] drm/i915/icl: Interrupt handling

Em Sex, 2018-01-19 às 17:30 +, Tvrtko Ursulin escreveu: > On 10/01/2018 10:16, Joonas Lahtinen wrote: > > On Tue, 2018-01-09 at 21:23 -0200, Paulo Zanoni wrote: > > > From: Tvrtko Ursulin > > > > > > v2: Rebase. > > > > > > v3: > > >* Remove DPF, it has been

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Avoid leaking lpe audio platdev.data

== Series Details == Series: drm/i915: Avoid leaking lpe audio platdev.data URL : https://patchwork.freedesktop.org/series/35151/ State : failure == Summary == Test perf: Subgroup buffer-fill: pass -> FAIL (shard-apl) fdo#103755 Subgroup

Re: [Intel-gfx] [PATCH 6/8] drm/i915/icp: Add backlight Support for ICP

On Fri, Jan 19, 2018 at 05:26:02PM +, Anusha Srivatsa wrote: > On Fri, Jan 19, 2018 at 02:40:41PM -0200, Paulo Zanoni wrote: > > Em Qui, 2018-01-11 às 15:57 -0800, Rodrigo Vivi escreveu: > > > On Thu, Jan 11, 2018 at 09:48:57PM +, James Ausmus wrote: > > > > On Thu, Jan 11, 2018 at

Re: [Intel-gfx] [PATCH 07/27] drm/i915/icl: Interrupt handling

On 10/01/2018 10:16, Joonas Lahtinen wrote: On Tue, 2018-01-09 at 21:23 -0200, Paulo Zanoni wrote: From: Tvrtko Ursulin v2: Rebase. v3: * Remove DPF, it has been removed from SKL+. * Fix -internal rebase wrt. execlists interrupt handling. v4: Rebase. v5:

Re: [Intel-gfx] [PATCH 6/8] drm/i915/icp: Add backlight Support for ICP

On Fri, Jan 19, 2018 at 02:40:41PM -0200, Paulo Zanoni wrote: > Em Qui, 2018-01-11 às 15:57 -0800, Rodrigo Vivi escreveu: > > On Thu, Jan 11, 2018 at 09:48:57PM +, James Ausmus wrote: > > > On Thu, Jan 11, 2018 at 04:00:08PM -0200, Paulo Zanoni wrote: > > > > From: Anusha Srivatsa

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Downgrade incorrect engine constructor usage warnings to development

On 1/19/2018 2:00 AM, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Render engine constructor helpers must only be called from the render engine constructors, but there is no need to burden the production binaries with warnings which can only be triggered during

Re: [Intel-gfx] [RFC] perf: Allow fine-grained PMU access control

Hi, On 19/01/2018 16:45, Peter Zijlstra wrote: On Thu, Jan 18, 2018 at 06:40:07PM +, Tvrtko Ursulin wrote: From: Tvrtko Ursulin For situations where sysadmins might want to allow different level of of access control for different PMUs, we start creating per-PMU

[Intel-gfx] ✗ Fi.CI.BAT: failure for Per-context and per-client engine busyness (rev3)

== Series Details == Series: Per-context and per-client engine busyness (rev3) URL : https://patchwork.freedesktop.org/series/32645/ State : failure == Summary == Series 32645v3 Per-context and per-client engine busyness https://patchwork.freedesktop.org/api/1.0/series/32645/revisions/3/mbox/

Re: [Intel-gfx] [RFC] perf: Allow fine-grained PMU access control

On Thu, Jan 18, 2018 at 06:40:07PM +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > For situations where sysadmins might want to allow different level of > of access control for different PMUs, we start creating per-PMU > perf_event_paranoid controls in sysfs.

Re: [Intel-gfx] [PATCH 6/8] drm/i915/icp: Add backlight Support for ICP

Em Qui, 2018-01-11 às 15:57 -0800, Rodrigo Vivi escreveu: > On Thu, Jan 11, 2018 at 09:48:57PM +, James Ausmus wrote: > > On Thu, Jan 11, 2018 at 04:00:08PM -0200, Paulo Zanoni wrote: > > > From: Anusha Srivatsa > > > > > > ICP has two backlight controllers -

[Intel-gfx] [PATCH v5 1/6] drm/i915: Track per-context engine busyness

From: Tvrtko Ursulin Some customers want to know how much of the GPU time are their clients using in order to make dynamic load balancing decisions. With the hooks already in place which track the overall engine busyness, we can extend that slightly to split that time

Re: [Intel-gfx] [PATCH v5] drm/i915/icl: Enhanced execution list support

On 19/01/18 05:05, Mika Kuoppala wrote: Daniele Ceraolo Spurio writes: From: Thomas Daniel Enhanced Execlists is an upgraded version of execlists which supports up to 8 ports. The lrcs to be submitted are written to a submit queue,

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Track the number of times we have woken the GPU up

== Series Details == Series: series starting with [1/2] drm/i915: Track the number of times we have woken the GPU up URL : https://patchwork.freedesktop.org/series/36802/ State : success == Summary == Series 36802v1 series starting with [1/2] drm/i915: Track the number of times we have

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Shrink the request kmem_cache on allocation error

== Series Details == Series: drm/i915: Shrink the request kmem_cache on allocation error URL : https://patchwork.freedesktop.org/series/36800/ State : success == Summary == Series 36800v1 drm/i915: Shrink the request kmem_cache on allocation error

Re: [Intel-gfx] [PATCH v2] drm/i915/edp: Do not do link training fallback or prune modes on EDP

On Thu, Oct 12, 2017 at 12:13:38PM -0700, Manasi Navare wrote: > In case of eDP because the panel has a fixed mode, the link rate > and lane count at which it is trained corresponds to the link BW > required to support the native resolution of the panel. In case of > panles with lower resolutions

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: add support for specifying DMC firmware override by module param (rev2)

== Series Details == Series: drm/i915: add support for specifying DMC firmware override by module param (rev2) URL : https://patchwork.freedesktop.org/series/34157/ State : failure == Summary == Test gem_eio: Subgroup in-flight-suspend: pass -> FAIL

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Fix up the CCS code (rev3)

== Series Details == Series: drm/i915: Fix up the CCS code (rev3) URL : https://patchwork.freedesktop.org/series/29308/ State : failure == Summary == Applying: drm/i915: Add a comment exlaining CCS hsub/vsub Applying: drm/i915: Nuke a pointless unreachable() Using index info to reconstruct a

[Intel-gfx] ✗ Fi.CI.BAT: failure for Per-context and per-client engine busyness (rev2)

== Series Details == Series: Per-context and per-client engine busyness (rev2) URL : https://patchwork.freedesktop.org/series/32645/ State : failure == Summary == CHK include/config/kernel.release CHK include/generated/uapi/linux/version.h CHK include/generated/utsrelease.h

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: expose RCS topology to userspace

== Series Details == Series: drm/i915: expose RCS topology to userspace URL : https://patchwork.freedesktop.org/series/36793/ State : success == Summary == Series 36793v1 drm/i915: expose RCS topology to userspace https://patchwork.freedesktop.org/api/1.0/series/36793/revisions/1/mbox/ Test

[Intel-gfx] [PATCH 2/2] drm/i915: Shrink the GEM kmem_caches upon idling

When we finally decide the gpu is idle, that is a good time to shrink our kmem_caches. v3: Defer until an rcu grace period after we idle. Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_gem.c | 65

[Intel-gfx] [PATCH 1/2] drm/i915: Track the number of times we have woken the GPU up

By counting the number of times we have woken up, we have a very simple means of defining an epoch, which will come in handy if we want to perform deferred tasks at the end of an epoch (i.e. while we are going to sleep) without imposing on the next activity cycle. Signed-off-by: Chris Wilson

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc: Keep GuC log disabled by default

== Series Details == Series: drm/i915/guc: Keep GuC log disabled by default URL : https://patchwork.freedesktop.org/series/36796/ State : success == Summary == Series 36796v1 drm/i915/guc: Keep GuC log disabled by default

Re: [Intel-gfx] [PATCH v10 6/6] drm/i915: expose rcs topology through query uAPI

On 19/01/18 14:24, Tvrtko Ursulin wrote: On 19/01/2018 13:22, Lionel Landwerlin wrote: With the introduction of asymmetric slices in CNL, we cannot rely on the previous SUBSLICE_MASK getparam to tell userspace what subslices are available. Here we introduce a more detailed way of querying the

[Intel-gfx] [CI] drm/i915: Shrink the request kmem_cache on allocation error

If we fail to allocate a new request, make sure we recover the pages that are in the process of being freed by inserting an RCU barrier. v2: Comment before the shrink and barrier in the error path. Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin

[Intel-gfx] [PATCH v2 1/8] drm/i915: Add a comment exlaining CCS hsub/vsub

From: Ville Syrjälä Let's document why we claim hsub==8,vsub==16 for CCS. v2: Replace my explanation with Jason's Cc: Daniel Vetter Cc: Ben Widawsky Cc: Jason Ekstrand Cc: Daniel Stone

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/3] drm/i915: Downgrade incorrect engine constructor usage warnings to development

== Series Details == Series: series starting with [1/3] drm/i915: Downgrade incorrect engine constructor usage warnings to development URL : https://patchwork.freedesktop.org/series/36771/ State : failure == Summary == Test perf: Subgroup oa-exponents: fail ->

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Avoid leaking lpe audio platdev.data

== Series Details == Series: drm/i915: Avoid leaking lpe audio platdev.data URL : https://patchwork.freedesktop.org/series/35151/ State : success == Summary == Series 35151v1 drm/i915: Avoid leaking lpe audio platdev.data

Re: [Intel-gfx] [PATCH v10 6/6] drm/i915: expose rcs topology through query uAPI

On 19/01/2018 13:22, Lionel Landwerlin wrote: With the introduction of asymmetric slices in CNL, we cannot rely on the previous SUBSLICE_MASK getparam to tell userspace what subslices are available. Here we introduce a more detailed way of querying the Gen's GPU topology that doesn't aggregate

Re: [Intel-gfx] [PATCH v2] drm/i915: Check for fused or unused pipes

On Mon, 18 Dec 2017, Mika Kahola wrote: > We may have fused or unused pipes in our system. Let's check that the pipe > in question is within limits of accessible pipes. In case, that we are not > able to access the pipe, we return early with a warning. > > v2: Rephrasing of

Re: [Intel-gfx] [RFC] drm/i915/guc: Keep GuC log disabled by default

On Fri, 19 Jan 2018, Michał Winiarski wrote: > On Fri, Jan 19, 2018 at 12:49:26PM +, Michal Wajdeczko wrote: >> It looks that GuC log functionality is not fully functional yet and >> causes issues when enabled by auto(-1) modparam on debug builds. This could use a

Re: [Intel-gfx] [PATCH] drm/i915: Avoid leaking lpe audio platdev.data

On Sat, 09 Dec 2017, Chris Wilson wrote: > The struct platform_device memdups the provided data pointer requiring > us to free the template we construct during lpe_audio_platdev_create(): > > unreferenced object 0x88026eafe400 (size 512): > comm "insmod", pid 6850,

Re: [Intel-gfx] [PATCH v5] drm/i915/icl: Enhanced execution list support

Daniele Ceraolo Spurio writes: > From: Thomas Daniel > > Enhanced Execlists is an upgraded version of execlists which supports > up to 8 ports. The lrcs to be submitted are written to a submit queue, > which is then loaded on the HW.

[Intel-gfx] [PATCH v10 2/6] drm/i915/debugfs: reuse max slice/subslices already stored in sseu

Now that we have that information in topology fields, let's just reused it. v2: Style tweaks (Tvrtko) Signed-off-by: Lionel Landwerlin Reviewed-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_debugfs.c | 27 +++

[Intel-gfx] [PATCH 4/6] drm/i915: Update client name on context create

From: Tvrtko Ursulin Some clients have the DRM fd passed to them over a socket by the X server. Grab the real client and pid when they create their first context and update the exposed data for more useful enumeration. Signed-off-by: Tvrtko Ursulin

Re: [Intel-gfx] [RFC 6/6] drm/i915/pmu: Add running counter

Quoting Tvrtko Ursulin (2018-01-19 11:45:24) > > On 18/01/2018 11:57, Chris Wilson wrote: > > Quoting Tvrtko Ursulin (2018-01-18 10:41:36) > >> From: Tvrtko Ursulin > >> > >> We add a PMU counter to expose the number of requests currently executing > >> on the GPU. > >>

[Intel-gfx] [PATCH 2/6] drm/i915: Allow clients to query own per-engine busyness

From: Tvrtko Ursulin Some customers want to know how much of the GPU time are their clients using in order to make dynamic load balancing decisions. With the accounting infrastructure in place in the previous patch, we add a new context param

[Intel-gfx] [PATCH 6/6] drm/i915: Add sysfs toggle to enable per-client engine stats

From: Tvrtko Ursulin By default we are not collecting any per-engine and per-context statistcs. Add a new sysfs toggle to enable this facility: $ echo 1 >/sys/class/drm/card0/clients/enable_stats v2: Rebase. Signed-off-by: Tvrtko Ursulin

[Intel-gfx] [PATCH v2 0/6] Per-context and per-client engine busyness

From: Tvrtko Ursulin I have sent this as part of a larger series back in October '17. First part of it is implementing a customer requirement to be able to query engine utilization on their own contexts. This is done in patch 2, which falls under the standard open

[Intel-gfx] [PATCH 1/6] drm/i915: Track per-context engine busyness

From: Tvrtko Ursulin Some customers want to know how much of the GPU time are their clients using in order to make dynamic load balancing decisions. With the hooks already in place which track the overall engine busyness, we can extend that slightly to split that time

  1   2   >