On 2018-03-06 02:51 AM, Daniel Vetter wrote:
> On Fri, Feb 23, 2018 at 11:26:41AM -0500, Harry Wentland wrote:
>> On 2018-02-22 04:42 PM, Ville Syrjala wrote:
>>> From: Ville Syrjälä
>>>
>>> The documentation for the ctm matrix suggests a two's complement
>>> format, but at least the i915 implemen
On 6 March 2018 at 13:54, Ville Syrjälä wrote:
> On Tue, Mar 06, 2018 at 01:35:11PM +, Emil Velikov wrote:
>> Hi Ville,
>>
>> On 2 March 2018 at 13:25, Ville Syrjala
>> wrote:
>> > From: Ville Syrjälä
>> >
>> > Creating a property that doesn't have a name makes no sense to me. Don't
>> > al
== Series Details ==
Series: drm/i915: Disable pipe CRC before disabling the pipe. (rev2)
URL : https://patchwork.freedesktop.org/series/39454/
State : success
== Summary ==
Series 39454v2 drm/i915: Disable pipe CRC before disabling the pipe.
https://patchwork.freedesktop.org/api/1.0/series/39
Hi,
On Mon, Mar 05, 2018 at 07:14:16PM +0100, Maarten Lankhorst wrote:
> Only try to set those values if the properties are supported.
> This fixes the kms_chameium tests to run on vc4 again.
>
> Reported-by: Maxime Ripard
> Cc: Paul Kocialkowski
> Cc: Eric Anholt
> Cc: Boris Brezillon
> Sign
On 2018-03-06 05:35 AM, Daniel Vetter wrote:
> On Mon, Mar 05, 2018 at 05:44:16PM -0500, Harry Wentland wrote:
>> On 2018-03-05 04:33 PM, Alex Deucher wrote:
>>> On Mon, Mar 5, 2018 at 4:15 PM, Ville Syrjälä
>>> wrote:
On Mon, Mar 05, 2018 at 12:59:00PM -0800, Eric Anholt wrote:
> Ville S
Header intel_ringbuffer.h is using definitions from i915_reg.h
but forget to include it. Remove this hidden dependency by
explicitly include missing header.
Signed-off-by: Michal Wajdeczko
Cc: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_ringbuffer.h | 1 +
1 file changed, 1
Definitions in i915_pmu.h header depend on other types and
declarations that were not explicitly included. Fix that by
adding related headers and forward declarations.
While here, change license text to SPDX format.
Signed-off-by: Michal Wajdeczko
Cc: Chris Wilson
Cc: Tvrtko Ursulin
---
driver
Function i915_gem_batch_pool_init() failed to follow obj-verb
naming schema. Fix that by swapping function parameters.
While here, change license text to SPDX format.
Signed-off-by: Michal Wajdeczko
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_batch_pool.c | 30 ++-
Error state management code was moved into separate .c unit
but we didn't move related definitions into own header.
Signed-off-by: Michal Wajdeczko
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h | 330 +--
drivers/gpu/drm/i915/i915_gpu_error.c | 1 +
dr
Quoting Michal Wajdeczko (2018-03-06 16:15:25)
> Function i915_gem_batch_pool_init() failed to follow obj-verb
> naming schema. Fix that by swapping function parameters.
> While here, change license text to SPDX format.
>
> Signed-off-by: Michal Wajdeczko
> Cc: Chris Wilson
Since this is peculi
On 2018-03-06 07:18 AM, Ville Syrjälä wrote:
> On Tue, Mar 06, 2018 at 10:31:27AM +0100, Daniel Vetter wrote:
>> On Tue, Feb 27, 2018 at 02:57:00PM +0200, Ville Syrjala wrote:
>>> From: Ville Syrjälä
>>>
>>> edid and display_info are protected by mode_config.mutex. Add lockdep
>>> asserts to make
On Tue, 06 Mar 2018 17:20:18 +0100, Chris Wilson
wrote:
Quoting Michal Wajdeczko (2018-03-06 16:15:25)
Function i915_gem_batch_pool_init() failed to follow obj-verb
naming schema. Fix that by swapping function parameters.
While here, change license text to SPDX format.
Signed-off-by: Michal
On 06/03/2018 16:15, Michal Wajdeczko wrote:
Definitions in i915_pmu.h header depend on other types and
declarations that were not explicitly included. Fix that by
adding related headers and forward declarations.
Oopsie.
While here, change license text to SPDX format.
Signed-off-by: Michal
On 06/03/2018 16:15, Michal Wajdeczko wrote:
Header intel_ringbuffer.h is using definitions from i915_reg.h
but forget to include it. Remove this hidden dependency by
explicitly include missing header.
Signed-off-by: Michal Wajdeczko
Cc: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/
From: Ville Syrjälä
If the property already has the enum value WARN and bail.
Replacing enum values doesn't make sense to me.
Throw out the pointless list_empty() while at it.
Cc: Daniel Vetter
Suggested-by: Daniel Vetter
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_property.c | 11
From: Ville Syrjälä
Enum values >63 with a bitmask property is a programmer error. WARN
when someone is attempting this.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_property.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_property.c b/driv
From: Ville Syrjälä
Trying to add enum values to non-enum/bitmask properties is a
programmer mistake. WARN to make sure the developers notice
their mistake.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_property.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/d
From: Ville Syrjälä
DRM_MODE_PROP_PENDING is not used anywhere (except printed out
by libdrm proptest/modetest).
This seems to be yet another thing blindly copied from xrandr.
Quoting from the protocol spec:
"If 'pending' is TRUE, changes made to property values with
RRChangeOutputProperty will
From: Ville Syrjälä
Pimp drm_property_type_valid() to check for more fails with the
property flags. Also make the check before adding the property,
and bail out if things look bad.
Since we're now chekcing for more than the type let's also
change the function name to drm_property_flags_valid().
From: Ville Syrjälä
The property flags are part of the uabi and we have 32 bits for them.
Pass them around as u32 internally as well, instead of a signed int.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_property.c | 41 +
include/drm/drm_propert
On Tue, Mar 06, 2018 at 11:23:23AM -0500, Harry Wentland wrote:
> On 2018-03-06 07:18 AM, Ville Syrjälä wrote:
> > On Tue, Mar 06, 2018 at 10:31:27AM +0100, Daniel Vetter wrote:
> >> On Tue, Feb 27, 2018 at 02:57:00PM +0200, Ville Syrjala wrote:
> >>> From: Ville Syrjälä
> >>>
> >>> edid and displ
== Series Details ==
Series: series starting with [1/6] drm: Reject replacing property enum values
URL : https://patchwork.freedesktop.org/series/39465/
State : success
== Summary ==
Series 39465v1 series starting with [1/6] drm: Reject replacing property enum
values
https://patchwork.freedes
Quoting Michal Wajdeczko (2018-03-06 16:15:26)
> Header intel_ringbuffer.h is using definitions from i915_reg.h
> but forget to include it. Remove this hidden dependency by
> explicitly include missing header.
>
> Signed-off-by: Michal Wajdeczko
> Cc: Chris Wilson
> Cc: Tvrtko Ursulin
> ---
>
== Series Details ==
Series: drm/i915/guc: Removed unused GuC parameters. (rev3)
URL : https://patchwork.freedesktop.org/series/39154/
State : warning
== Summary ==
Possible new issues:
Test kms_cursor_crc:
Subgroup cursor-128x128-suspend:
pass -> DMESG-WARN
On Tue, Mar 06, 2018 at 06:48:44PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> If the property already has the enum value WARN and bail.
> Replacing enum values doesn't make sense to me.
>
> Throw out the pointless list_empty() while at it.
>
> Cc: Daniel Vetter
> Suggested-by: Danie
On Tue, Mar 06, 2018 at 06:48:45PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Trying to add enum values to non-enum/bitmask properties is a
> programmer mistake. WARN to make sure the developers notice
> their mistake.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Daniel Vetter
> -
On Tue, Mar 06, 2018 at 06:48:46PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Enum values >63 with a bitmask property is a programmer error. WARN
> when someone is attempting this.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_property.c
== Series Details ==
Series: drm/i915: expose RCS topology to userspace
URL : https://patchwork.freedesktop.org/series/39446/
State : failure
== Summary ==
Possible new issues:
Test pm_sseu:
Subgroup full-enable:
pass -> FAIL (shard-apl)
Known is
On Tue, Mar 06, 2018 at 06:48:47PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> DRM_MODE_PROP_PENDING is not used anywhere (except printed out
> by libdrm proptest/modetest).
>
> This seems to be yet another thing blindly copied from xrandr.
> Quoting from the protocol spec:
> "If 'pend
On Tue, Mar 06, 2018 at 06:48:48PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The property flags are part of the uabi and we have 32 bits for them.
> Pass them around as u32 internally as well, instead of a signed int.
>
> Signed-off-by: Ville Syrjälä
u32 vs uint32_t (in struct drm_
On Tue, Mar 06, 2018 at 06:48:49PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Pimp drm_property_type_valid() to check for more fails with the
> property flags. Also make the check before adding the property,
> and bail out if things look bad.
>
> Since we're now chekcing for more than
On 2018-03-06 12:13 PM, Daniel Vetter wrote:
> On Tue, Mar 06, 2018 at 11:23:23AM -0500, Harry Wentland wrote:
>> On 2018-03-06 07:18 AM, Ville Syrjälä wrote:
>>> On Tue, Mar 06, 2018 at 10:31:27AM +0100, Daniel Vetter wrote:
On Tue, Feb 27, 2018 at 02:57:00PM +0200, Ville Syrjala wrote:
>>>
From: Matt Atwood
DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed bit scheme from 8
bits to 7 bits in DPCD 0x000e. The 8th bit describes a new feature, for
panels that use this new feature, this would cause a wait interval for
clock recovery of at least 512 ms, much higher then spec maximum
== Series Details ==
Series: series starting with [1/2] drm/i915: Stop kicking the signaling thread
on seqno wraparound
URL : https://patchwork.freedesktop.org/series/39448/
State : warning
== Summary ==
Possible new issues:
Test kms_chv_cursor_fail:
Subgroup pipe-a-128x128-left
On Tue, Mar 06, 2018 at 07:42:53AM +0100, Daniel Vetter wrote:
> On Tue, Mar 6, 2018 at 12:20 AM, Sean Paul wrote:
> > On Mon, Mar 5, 2018 at 12:10 AM, Daniel Vetter wrote:
> >> On Fri, Mar 02, 2018 at 04:22:15PM -0500, Sean Paul wrote:
> >>> On Wed, Feb 28, 2018 at 3:34 PM, Sean Paul wrote:
> >
On Tue, Mar 06, 2018 at 02:01:21PM -0500, Sean Paul wrote:
> On Tue, Mar 06, 2018 at 07:42:53AM +0100, Daniel Vetter wrote:
> > On Tue, Mar 6, 2018 at 12:20 AM, Sean Paul wrote:
> > > On Mon, Mar 5, 2018 at 12:10 AM, Daniel Vetter wrote:
> > >> On Fri, Mar 02, 2018 at 04:22:15PM -0500, Sean Paul
Quoting Patchwork (2018-03-06 18:53:28)
> == Series Details ==
>
> Series: series starting with [1/2] drm/i915: Stop kicking the signaling
> thread on seqno wraparound
> URL : https://patchwork.freedesktop.org/series/39448/
> State : warning
>
> == Summary ==
>
> Possible new issues:
>
On Tue, Mar 06, 2018 at 09:07:52PM +0200, Ville Syrjälä wrote:
> On Tue, Mar 06, 2018 at 02:01:21PM -0500, Sean Paul wrote:
> > On Tue, Mar 06, 2018 at 07:42:53AM +0100, Daniel Vetter wrote:
> > > On Tue, Mar 6, 2018 at 12:20 AM, Sean Paul wrote:
> > > > On Mon, Mar 5, 2018 at 12:10 AM, Daniel Vet
On Mon, Mar 05, 2018 at 05:28:12PM -0800, Rodrigo Vivi wrote:
> No functional change since WA is already applied.
> But since it has different names on different databases,
> let's document it here to avoid future confusion.
>
> Cc: Radhakrishna Sripada
> Signed-off-by: Rodrigo Vivi
Reviewed-by:
On Tue, Mar 06, 2018 at 11:22:16AM +0100, Maarten Lankhorst wrote:
> Op 05-03-18 om 19:50 schreef Rodrigo Vivi:
> > On Mon, Mar 05, 2018 at 01:36:08PM +0100, Maarten Lankhorst wrote:
> >> If i915.enable_fbc is cleared at runtime, but FBC was previously enabled
> >> then we don't disable FBC until t
== Series Details ==
Series: drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4
URL : https://patchwork.freedesktop.org/series/39473/
State : success
== Summary ==
Series 39473v1 drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP
1.4
https://patchwork.freedeskt
Op 06-03-18 om 21:02 schreef Rodrigo Vivi:
> On Tue, Mar 06, 2018 at 11:22:16AM +0100, Maarten Lankhorst wrote:
>> Op 05-03-18 om 19:50 schreef Rodrigo Vivi:
>>> On Mon, Mar 05, 2018 at 01:36:08PM +0100, Maarten Lankhorst wrote:
If i915.enable_fbc is cleared at runtime, but FBC was previously
When PSR/PSR2/GTC is enabled hardware can do AUX transactions by it
self, so lets use the mutex register that is available in gen9+ to
avoid concurrent access by hardware and driver.
Older gen handling will be done separated.
Reference:
https://01.org/sites/default/files/documentation/intel-gfx-p
In fact, apply the Cannonlake resolution check for all >= Gen-10 platforms
to be safe.
v3: Update GLK too. (Ville)
Longer variable names.
if-else in place of ternary operator.
v2: Use local variables for resolution limits and print them (Ville)
Cc: Ville Syrjälä
Cc: Rodrigo Vivi
Cc: Eli
On Tue, Mar 06, 2018 at 12:33:55PM -0800, Dhinakaran Pandiyan wrote:
> In fact, apply the Cannonlake resolution check for all >= Gen-10 platforms
> to be safe.
>
> v3: Update GLK too. (Ville)
> Longer variable names.
> if-else in place of ternary operator.
> v2: Use local variables for res
== Series Details ==
Series: drm/i915: Disable pipe CRC before disabling the pipe. (rev2)
URL : https://patchwork.freedesktop.org/series/39454/
State : failure
== Summary ==
Possible new issues:
Test kms_busy:
Subgroup extended-pageflip-hang-oldfb-render-a:
pass
On Tue, 2018-03-06 at 22:38 +0200, Ville Syrjälä wrote:
> On Tue, Mar 06, 2018 at 12:33:55PM -0800, Dhinakaran Pandiyan wrote:
> > In fact, apply the Cannonlake resolution check for all >= Gen-10 platforms
> > to be safe.
> >
> > v3: Update GLK too. (Ville)
> > Longer variable names.
> >
== Series Details ==
Series: drm/i915/skl+: Add and enable DP AUX CH mutex (rev2)
URL : https://patchwork.freedesktop.org/series/39067/
State : warning
== Summary ==
Series 39067v2 drm/i915/skl+: Add and enable DP AUX CH mutex
https://patchwork.freedesktop.org/api/1.0/series/39067/revisions/2/
== Series Details ==
Series: drm/i915/psr: Update PSR2 resolution check for Cannonlake (rev3)
URL : https://patchwork.freedesktop.org/series/39238/
State : success
== Summary ==
Series 39238v3 drm/i915/psr: Update PSR2 resolution check for Cannonlake
https://patchwork.freedesktop.org/api/1.0/s
On Tue, Mar 06, 2018 at 08:45:44PM +, Pandiyan, Dhinakaran wrote:
>
>
>
> On Tue, 2018-03-06 at 22:38 +0200, Ville Syrjälä wrote:
> > On Tue, Mar 06, 2018 at 12:33:55PM -0800, Dhinakaran Pandiyan wrote:
> > > In fact, apply the Cannonlake resolution check for all >= Gen-10 platforms
> > > to
On Tue, 2018-03-06 at 23:24 +0200, Ville Syrjälä wrote:
> On Tue, Mar 06, 2018 at 08:45:44PM +, Pandiyan, Dhinakaran wrote:
> >
> >
> >
> > On Tue, 2018-03-06 at 22:38 +0200, Ville Syrjälä wrote:
> > > On Tue, Mar 06, 2018 at 12:33:55PM -0800, Dhinakaran Pandiyan wrote:
> > > > In fact, app
== Series Details ==
Series: series starting with [1/6] drm: Reject replacing property enum values
URL : https://patchwork.freedesktop.org/series/39465/
State : warning
== Summary ==
Possible new issues:
Test kms_chv_cursor_fail:
Subgroup pipe-a-64x64-top-edge:
dm
== Series Details ==
Series: drm/i915/cnp: Document WaSouthDisplayDisablePWMCGEGating
URL : https://patchwork.freedesktop.org/series/39410/
State : success
== Summary ==
Series 39410v1 drm/i915/cnp: Document WaSouthDisplayDisablePWMCGEGating
https://patchwork.freedesktop.org/api/1.0/series/394
On 02/03/18 08:14, Mika Kuoppala wrote:
From: Oscar Mateo
Gen11 has up to 4 VCS and up to 2 VECS engines, this patch adds mmio
base definitions for all of them.
Bspec: 20944
Bspec: 7021
v2: Set the correct mmio_base in intel_engines_init_mmio; updating the
base mmio values any later would c
== Series Details ==
Series: drm/i915/cnl: document WaVFUnitClockGatingDisable
URL : https://patchwork.freedesktop.org/series/39409/
State : success
== Summary ==
Series 39409v1 drm/i915/cnl: document WaVFUnitClockGatingDisable
https://patchwork.freedesktop.org/api/1.0/series/39409/revisions/1
On 3/2/2018 8:14 AM, Mika Kuoppala wrote:
From: Daniele Ceraolo Spurio
Starting from Gen11 the context descriptor format has been updated in
the HW. The hw_id field has been considerably reduced in size and engine
class and instance fields have been added.
There is a slight name clashing iss
On Tue, Mar 06, 2018 at 11:24:15PM +0200, Ville Syrjälä wrote:
> On Tue, Mar 06, 2018 at 08:45:44PM +, Pandiyan, Dhinakaran wrote:
> >
> >
> >
> > On Tue, 2018-03-06 at 22:38 +0200, Ville Syrjälä wrote:
> > > On Tue, Mar 06, 2018 at 12:33:55PM -0800, Dhinakaran Pandiyan wrote:
> > > > In fac
On Tue, Mar 06, 2018 at 11:56:35AM -0800, Radhakrishna Sripada wrote:
> On Mon, Mar 05, 2018 at 05:28:12PM -0800, Rodrigo Vivi wrote:
> > No functional change since WA is already applied.
> > But since it has different names on different databases,
> > let's document it here to avoid future confusi
On Mon, Mar 05, 2018 at 05:40:01PM -0800, Rafael Antognolli wrote:
> On Mon, Mar 05, 2018 at 05:20:00PM -0800, Rodrigo Vivi wrote:
> > No functional change. WA is already properly applied.
> > but in different databases it has different names.
> > Let's document all of them to avoid future confusio
== Series Details ==
Series: drm/i915/cnl: Add Wa_2201832410
URL : https://patchwork.freedesktop.org/series/39408/
State : success
== Summary ==
Series 39408v1 drm/i915/cnl: Add Wa_2201832410
https://patchwork.freedesktop.org/api/1.0/series/39408/revisions/1/mbox/
fi-bdw-5557u total:288
On Tue, Mar 06, 2018 at 12:11:03PM -0800, José Roberto de Souza wrote:
> When PSR/PSR2/GTC is enabled hardware can do AUX transactions by it
> self, so lets use the mutex register that is available in gen9+ to
> avoid concurrent access by hardware and driver.
> Older gen handling will be done separ
On Tue, Mar 06, 2018 at 09:12:02PM +0100, Maarten Lankhorst wrote:
> Op 06-03-18 om 21:02 schreef Rodrigo Vivi:
> > On Tue, Mar 06, 2018 at 11:22:16AM +0100, Maarten Lankhorst wrote:
> >> Op 05-03-18 om 19:50 schreef Rodrigo Vivi:
> >>> On Mon, Mar 05, 2018 at 01:36:08PM +0100, Maarten Lankhorst wr
On Tue, Mar 06, 2018 at 10:37:48AM -0800, matthew.s.atw...@intel.com wrote:
> From: Matt Atwood
>
> DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed bit scheme from 8
> bits to 7 bits in DPCD 0x000e. The 8th bit describes a new feature, for
> panels that use this new feature, this would cause
This is the third iteration of the work previously posted here:
(v1) https://lists.freedesktop.org/archives/intel-gfx/2018-January/153156.html
(v2)
https://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg208170.html
The high level goal of this work is to allow non-cgroup-controller pa
Wraps task_dfl_cgroup() to also take a reference to the cgroup.
Cc: Tejun Heo
Cc: cgro...@vger.kernel.org
Signed-off-by: Matt Roper
---
include/linux/cgroup.h | 23 +++
1 file changed, 23 insertions(+)
diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h
index a3604
Non-controller kernel subsystems may base access restrictions for
cgroup-related syscalls/ioctls on a process' access to the cgroup.
Let's make it easy for other parts of the kernel to check these cgroup
permissions.
Cc: Tejun Heo
Cc: cgro...@vger.kernel.org
Signed-off-by: Matt Roper
---
includ
There are cases where other parts of the kernel may wish to store data
associated with individual cgroups without building a full cgroup
controller. Let's add interfaces to allow them to register and lookup
this private data for individual cgroups.
A kernel system (e.g., a driver) that wishes to
Update i915_context_status to include priority information.
v2:
- Clarify that the offset is based on cgroup (Chris)
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/i
Introduce a new DRM_IOCTL_I915_CGROUP_SETPARAM ioctl that will allow
userspace to set i915-specific parameters for individual cgroups. i915
cgroup data will be registered and later looked up via the new
cgroup_priv infrastructure.
v2:
- Large rebase/rewrite for new cgroup_priv interface
Signed-
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 system-lev
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
---
tools/Makefile.sources | 1 +
tool
drv_cgroup exercises both valid and invalid usage of the i915 cgroup
parameter ioctl.
Signed-off-by: Matt Roper
---
tests/Makefile.sources | 1 +
tests/drv_cgroup.c | 236 +
2 files changed, 237 insertions(+)
create mode 100644 tests/drv_cgr
On Mon, 2018-03-05 at 03:12 -0800, Piorkowski, Piotr wrote:
> On Fri, 2018-03-02 at 12:53 +0530, Sagar Arun Kamble wrote:
> >
> >
> > On 3/2/2018 12:44 AM, John Spotswood wrote:
> > >
> > > On Thu, 2018-03-01 at 17:35 +0530, Sagar Arun Kamble wrote:
> > > >
> > > > On 3/1/2018 1:32 PM, Chris Wi
== Series Details ==
Series: DRM/i915 cgroup integration
URL : https://patchwork.freedesktop.org/series/39489/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: cgroup: Allow registration and lookup of cgroup private data
Okay!
Commit: cgroup: Introduce task_get_dfl_cgroup()
O
== Series Details ==
Series: DRM/i915 cgroup integration
URL : https://patchwork.freedesktop.org/series/39489/
State : success
== Summary ==
Series 39489v1 DRM/i915 cgroup integration
https://patchwork.freedesktop.org/api/1.0/series/39489/revisions/1/mbox/
Known issues:
Test kms_pipe_cr
On Tue, 2018-03-06 at 15:24 -0800, Rodrigo Vivi wrote:
> On Tue, Mar 06, 2018 at 10:37:48AM -0800, matthew.s.atw...@intel.com wrote:
> > From: Matt Atwood
> >
> > DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed bit scheme from 8
> > bits to 7 bits in DPCD 0x000e. The 8th bit describes a n
On Tue, 2018-03-06 at 16:48 -0800, Dhinakaran Pandiyan wrote:
>
>
> On Tue, 2018-03-06 at 15:24 -0800, Rodrigo Vivi wrote:
> > On Tue, Mar 06, 2018 at 10:37:48AM -0800, matthew.s.atw...@intel.com wrote:
> > > From: Matt Atwood
> > >
> > > DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed
== Series Details ==
Series: drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4
URL : https://patchwork.freedesktop.org/series/39473/
State : success
== Summary ==
Possible new issues:
Test kms_busy:
Subgroup extended-modeset-hang-newfb-render-b:
== Series Details ==
Series: drm/i915/psr: Update PSR2 resolution check for Cannonlake (rev3)
URL : https://patchwork.freedesktop.org/series/39238/
State : success
== Summary ==
Possible new issues:
Test kms_busy:
Subgroup extended-modeset-hang-newfb-render-b:
dme
On Wed, Mar 07, 2018 at 12:24:46AM +, Pandiyan, Dhinakaran wrote:
>
>
>
> On Tue, 2018-03-06 at 15:24 -0800, Rodrigo Vivi wrote:
> > On Tue, Mar 06, 2018 at 10:37:48AM -0800, matthew.s.atw...@intel.com wrote:
> > > From: Matt Atwood
> > >
> > > DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec
== Series Details ==
Series: drm/i915/cnp: Document WaSouthDisplayDisablePWMCGEGating
URL : https://patchwork.freedesktop.org/series/39410/
State : warning
== Summary ==
Possible new issues:
Test kms_busy:
Subgroup extended-modeset-hang-newfb-render-b:
dmesg-warn
On Tue, 2018-03-06 at 17:36 -0800, Manasi Navare wrote:
> On Wed, Mar 07, 2018 at 12:24:46AM +, Pandiyan, Dhinakaran wrote:
> >
> >
> >
> > On Tue, 2018-03-06 at 15:24 -0800, Rodrigo Vivi wrote:
> > > On Tue, Mar 06, 2018 at 10:37:48AM -0800, matthew.s.atw...@intel.com
> > > wrote:
> > >
== Series Details ==
Series: drm/i915/cnl: document WaVFUnitClockGatingDisable
URL : https://patchwork.freedesktop.org/series/39409/
State : success
== Summary ==
Possible new issues:
Test kms_busy:
Subgroup extended-modeset-hang-newfb-render-b:
dmesg-warn -> PASS
From: "Pandiyan, Dhinakaran"
i915_gem_obj_pin_to_display() calls frontbuffer_flush with origin set to
DIRTYFB. The callers however are at a vantage point to decide if hardware
frontbuffer tracking can do the flush for us. For example, legacy cursor
updates, like flips, write to MMIO registers, wh
From: Rodrigo Vivi
So far we are using frontbuffer tracking for everything
and ignoring that PSR has a HW capable HW tracking for many
modern usages of GPU on Core platforms and newer Atom ones.
One reason for that is that we were trying to keep same
infrastructure in place for VLV/CHV than the
DRM_IOCTL_MODE_CURSOR results in frontbuffer flush before the cursor
plane MMIOs are written to. But this flush should not be necessary for
PSR as hardware tracking triggers PSR exit when MMIOs are written. As
for FBC, the spec says "Flips or changes to plane size and panning" cause
FBC to be nuked
== Series Details ==
Series: drm/i915/cnl: Add Wa_2201832410
URL : https://patchwork.freedesktop.org/series/39408/
State : failure
== Summary ==
Possible new issues:
Test gem_exec_create:
Subgroup madvise:
pass -> INCOMPLETE (shard-snb)
Test kms_busy:
On Fri, 2018-02-16 at 08:54 +, Chris Wilson wrote:
> Quoting Dhinakaran Pandiyan (2018-02-16 04:33:19)
> > From: Rodrigo Vivi
> >
> > So far we are using frontbuffer tracking for everything
> > and ignoring that PSR has a HW capable HW tracking for many
> > modern usages of GPU on Core pla
== Series Details ==
Series: series starting with [v2,1/3] drm/i915/frontbuffer: Pull
frontbuffer_flush out of gem_obj_pin_to_display
URL : https://patchwork.freedesktop.org/series/39502/
State : success
== Summary ==
Series 39502v1 series starting with [v2,1/3] drm/i915/frontbuffer: Pull
fr
On Tue, 2018-02-27 at 16:14 -0800, Rodrigo Vivi wrote:
> From: Andy Lutomirski
>
> The current PSR code has a two call sites that each schedule delayed
> work to activate PSR. As far as I can tell, each call site intends
> to keep PSR inactive for the given amount of time and then allow it
>
== Series Details ==
Series: DRM/i915 cgroup integration
URL : https://patchwork.freedesktop.org/series/39489/
State : failure
== Summary ==
Possible new issues:
Test kms_draw_crc:
Subgroup draw-method-rgb565-pwrite-untiled:
pass -> DMESG-WARN (shard-hsw)
== Series Details ==
Series: series starting with [v2,1/3] drm/i915/frontbuffer: Pull
frontbuffer_flush out of gem_obj_pin_to_display
URL : https://patchwork.freedesktop.org/series/39502/
State : success
== Summary ==
Known issues:
Test kms_chv_cursor_fail:
Subgroup pipe-b-256x2
On Tue, 06 Mar 2018, Paulo Zanoni wrote:
> Em Ter, 2018-03-06 às 12:41 +0200, Jani Nikula escreveu:
>> We don't want to preserve the DDI A 4 lane bit on ICL.
>>
>
> Why not review https://patchwork.freedesktop.org/patch/206118/ instead?
> :)
Because Mahesh posted his version and I suck and miss
On 06/03/2018 17:33, Chris Wilson wrote:
Quoting Michal Wajdeczko (2018-03-06 16:15:26)
Header intel_ringbuffer.h is using definitions from i915_reg.h
but forget to include it. Remove this hidden dependency by
explicitly include missing header.
Signed-off-by: Michal Wajdeczko
Cc: Chris Wilson
101 - 194 of 194 matches
Mail list logo
