Re: [Intel-gfx] [PATCH] drm/i915: remove redundant fbc warnings

[Zanoni, Paulo R]

Em Ter, 2016-07-05 às 10:28 +0100, Matthew Auld escreveu:
> The fbc enabled/active sanity checks are already done in
> __intel_fbc_disable so no need to do them again.
> 
> Signed-off-by: Matthew Auld 

Reviewed-by: Paulo Zanoni 

> ---
>  drivers/gpu/drm/i915/intel_fbc.c | 5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_fbc.c
> b/drivers/gpu/drm/i915/intel_fbc.c
> index 067b6f5..e77104d 100644
> --- a/drivers/gpu/drm/i915/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/intel_fbc.c
> @@ -1163,11 +1163,8 @@ void intel_fbc_disable(struct intel_crtc
> *crtc)
>   return;
>  
>   mutex_lock(&fbc->lock);
> - if (fbc->crtc == crtc) {
> - WARN_ON(!fbc->enabled);
> - WARN_ON(fbc->active);
> + if (fbc->crtc == crtc)
>   __intel_fbc_disable(dev_priv);
> - }
>   mutex_unlock(&fbc->lock);
>  
>   cancel_work_sync(&fbc->work.work);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v6 3/3] drm/doc/rfc: VM_BIND uapi definition

[Zanoni, Paulo R]

On Sat, 2022-06-25 at 18:49 -0700, Niranjana Vishwanathapura wrote:
> VM_BIND and related uapi definitions
> 
> v2: Reduce the scope to simple Mesa use case.
> v3: Expand VM_UNBIND documentation and add
> I915_GEM_VM_BIND/UNBIND_FENCE_VALID
> and I915_GEM_VM_BIND_TLB_FLUSH flags.
> v4: Remove I915_GEM_VM_BIND_TLB_FLUSH flag and add additional
> documentation for vm_bind/unbind.
> v5: Remove TLB flush requirement on VM_UNBIND.
> Add version support to stage implementation.
> v6: Define and use drm_i915_gem_timeline_fence structure for
> all timeline fences.
> v7: Rename I915_PARAM_HAS_VM_BIND to I915_PARAM_VM_BIND_VERSION.
> Update documentation on async vm_bind/unbind and versioning.
> Remove redundant vm_bind/unbind FENCE_VALID flag, execbuf3
> batch_count field and I915_EXEC3_SECURE flag.
> 
> Signed-off-by: Niranjana Vishwanathapura 
> Reviewed-by: Daniel Vetter 
> ---
>  Documentation/gpu/rfc/i915_vm_bind.h | 280 +++
>  1 file changed, 280 insertions(+)
>  create mode 100644 Documentation/gpu/rfc/i915_vm_bind.h
> 
> diff --git a/Documentation/gpu/rfc/i915_vm_bind.h 
> b/Documentation/gpu/rfc/i915_vm_bind.h
> new file mode 100644
> index ..a93e08bceee6
> --- /dev/null
> +++ b/Documentation/gpu/rfc/i915_vm_bind.h
> @@ -0,0 +1,280 @@
> +/* SPDX-License-Identifier: MIT */
> +/*
> + * Copyright © 2022 Intel Corporation
> + */
> +
> +/**
> + * DOC: I915_PARAM_VM_BIND_VERSION
> + *
> + * VM_BIND feature version supported.
> + * See typedef drm_i915_getparam_t param.
> + *
> + * Specifies the VM_BIND feature version supported.
> + * The following versions of VM_BIND have been defined:
> + *
> + * 0: No VM_BIND support.
> + *
> + * 1: In VM_UNBIND calls, the UMD must specify the exact mappings created
> + *previously with VM_BIND, the ioctl will not support unbinding multiple
> + *mappings or splitting them. Similarly, VM_BIND calls will not replace
> + *any existing mappings.
> + *
> + * 2: The restrictions on unbinding partial or multiple mappings is
> + *lifted, Similarly, binding will replace any mappings in the given 
> range.
> + *
> + * See struct drm_i915_gem_vm_bind and struct drm_i915_gem_vm_unbind.
> + */
> +#define I915_PARAM_VM_BIND_VERSION   57
> +
> +/**
> + * DOC: I915_VM_CREATE_FLAGS_USE_VM_BIND
> + *
> + * Flag to opt-in for VM_BIND mode of binding during VM creation.
> + * See struct drm_i915_gem_vm_control flags.
> + *
> + * The older execbuf2 ioctl will not support VM_BIND mode of operation.
> + * For VM_BIND mode, we have new execbuf3 ioctl which will not accept any
> + * execlist (See struct drm_i915_gem_execbuffer3 for more details).
> + */
> +#define I915_VM_CREATE_FLAGS_USE_VM_BIND (1 << 0)
> +
> +/* VM_BIND related ioctls */
> +#define DRM_I915_GEM_VM_BIND 0x3d
> +#define DRM_I915_GEM_VM_UNBIND   0x3e
> +#define DRM_I915_GEM_EXECBUFFER3 0x3f
> +
> +#define DRM_IOCTL_I915_GEM_VM_BIND   DRM_IOWR(DRM_COMMAND_BASE + 
> DRM_I915_GEM_VM_BIND, struct drm_i915_gem_vm_bind)
> +#define DRM_IOCTL_I915_GEM_VM_UNBIND DRM_IOWR(DRM_COMMAND_BASE + 
> DRM_I915_GEM_VM_UNBIND, struct drm_i915_gem_vm_bind)
> +#define DRM_IOCTL_I915_GEM_EXECBUFFER3   
> DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_EXECBUFFER3, struct 
> drm_i915_gem_execbuffer3)
> +
> +/**
> + * struct drm_i915_gem_timeline_fence - An input or output timeline fence.
> + *
> + * The operation will wait for input fence to signal.
> + *
> + * The returned output fence will be signaled after the completion of the
> + * operation.
> + */
> +struct drm_i915_gem_timeline_fence {
> + /** @handle: User's handle for a drm_syncobj to wait on or signal. */
> + __u32 handle;
> +
> + /**
> +  * @flags: Supported flags are:
> +  *
> +  * I915_TIMELINE_FENCE_WAIT:
> +  * Wait for the input fence before the operation.
> +  *
> +  * I915_TIMELINE_FENCE_SIGNAL:
> +  * Return operation completion fence as output.
> +  */
> + __u32 flags;
> +#define I915_TIMELINE_FENCE_WAIT(1 << 0)
> +#define I915_TIMELINE_FENCE_SIGNAL  (1 << 1)
> +#define __I915_TIMELINE_FENCE_UNKNOWN_FLAGS (-(I915_TIMELINE_FENCE_SIGNAL << 
> 1))
> +
> + /**
> +  * @value: A point in the timeline.
> +  * Value must be 0 for a binary drm_syncobj. A Value of 0 for a
> +  * timeline drm_syncobj is invalid as it turns a drm_syncobj into a
> +  * binary one.
> +  */
> + __u64 value;
> +};
> +
> +/**
> + * struct drm_i915_gem_vm_bind - VA to object mapping to bind.
> + *
> + * This structure is passed to VM_BIND ioctl and specifies the mapping of GPU
> + * virtual address (VA) range to the section of an object that should be 
> bound
> + * in the device page table of the specified address space (VM).
> + * The VA range specified must be unique (ie., not currently bound) and can
> + * be mapped to whole object or a section of the object (partial binding).
> + * Multiple 

Re: [Intel-gfx] [PATCH v6 1/3] drm/doc/rfc: VM_BIND feature design document

[Zanoni, Paulo R]

On Sat, 2022-06-25 at 18:49 -0700, Niranjana Vishwanathapura wrote:
> VM_BIND design document with description of intended use cases.
> 
> v2: Reduce the scope to simple Mesa use case.
> v3: Expand documentation on dma-resv usage, TLB flushing and
> execbuf3.
> v4: Remove vm_bind tlb flush request support.
> v5: Update TLB flushing documentation.
> v6: Update out of order completion documentation.
> 
> Signed-off-by: Niranjana Vishwanathapura 
> ---
>  Documentation/gpu/rfc/i915_vm_bind.rst | 246 +
>  Documentation/gpu/rfc/index.rst|   4 +
>  2 files changed, 250 insertions(+)
>  create mode 100644 Documentation/gpu/rfc/i915_vm_bind.rst
> 
> diff --git a/Documentation/gpu/rfc/i915_vm_bind.rst 
> b/Documentation/gpu/rfc/i915_vm_bind.rst
> new file mode 100644
> index ..032ee32b885c
> --- /dev/null
> +++ b/Documentation/gpu/rfc/i915_vm_bind.rst
> @@ -0,0 +1,246 @@
> +==
> +I915 VM_BIND feature design and use cases
> +==
> +
> +VM_BIND feature
> +
> +DRM_I915_GEM_VM_BIND/UNBIND ioctls allows UMD to bind/unbind GEM buffer
> +objects (BOs) or sections of a BOs at specified GPU virtual addresses on a
> +specified address space (VM). These mappings (also referred to as persistent
> +mappings) will be persistent across multiple GPU submissions (execbuf calls)
> +issued by the UMD, without user having to provide a list of all required
> +mappings during each submission (as required by older execbuf mode).
> +
> +The VM_BIND/UNBIND calls allow UMDs to request a timeline out fence for
> +signaling the completion of bind/unbind operation.
> +
> +VM_BIND feature is advertised to user via I915_PARAM_HAS_VM_BIND.

I915_PARAM_VM_BIND_VERSION


> +User has to opt-in for VM_BIND mode of binding for an address space (VM)
> +during VM creation time via I915_VM_CREATE_FLAGS_USE_VM_BIND extension.
> +
> +VM_BIND/UNBIND ioctl calls executed on different CPU threads concurrently are
> +not ordered. Furthermore, parts of the VM_BIND/UNBIND operations can be done
> +asynchronously, when valid out fence is specified.
> +
> +VM_BIND features include:
> +
> +* Multiple Virtual Address (VA) mappings can map to the same physical pages
> +  of an object (aliasing).
> +* VA mapping can map to a partial section of the BO (partial binding).
> +* Support capture of persistent mappings in the dump upon GPU error.
> +* Support for userptr gem objects (no special uapi is required for this).
> +
> +TLB flush consideration
> +
> +The i915 driver flushes the TLB for each submission and when an object's
> +pages are released. The VM_BIND/UNBIND operation will not do any additional
> +TLB flush. Any VM_BIND mapping added will be in the working set for 
> subsequent
> +submissions on that VM and will not be in the working set for currently 
> running
> +batches (which would require additional TLB flushes, which is not supported).
> +
> +Execbuf ioctl in VM_BIND mode
> +---
> +A VM in VM_BIND mode will not support older execbuf mode of binding.
> +The execbuf ioctl handling in VM_BIND mode differs significantly from the
> +older execbuf2 ioctl (See struct drm_i915_gem_execbuffer2).
> +Hence, a new execbuf3 ioctl has been added to support VM_BIND mode. (See
> +struct drm_i915_gem_execbuffer3). The execbuf3 ioctl will not accept any
> +execlist. Hence, no support for implicit sync. It is expected that the below
> +work will be able to support requirements of object dependency setting in all
> +use cases:
> +
> +"dma-buf: Add an API for exporting sync files"
> +(https://lwn.net/Articles/859290/)
> +
> +The new execbuf3 ioctl only works in VM_BIND mode and the VM_BIND mode only
> +works with execbuf3 ioctl for submission. All BOs mapped on that VM (through
> +VM_BIND call) at the time of execbuf3 call are deemed required for that
> +submission.
> +
> +The execbuf3 ioctl directly specifies the batch addresses instead of as
> +object handles as in execbuf2 ioctl. The execbuf3 ioctl will also not
> +support many of the older features like in/out/submit fences, fence array,
> +default gem context and many more (See struct drm_i915_gem_execbuffer3).

Just as a note: both Iris and Vulkan use some of these features, so
some rework will be required. From what I can see, all current behavior
we depend on will be supported in some way or another, so hopefully
we'll be fine.


> +
> +In VM_BIND mode, VA allocation is completely managed by the user instead of
> +the i915 driver. Hence all VA assignment, eviction are not applicable in
> +VM_BIND mode. Also, for determining object activeness, VM_BIND mode will not
> +be using the i915_vma active reference tracking. It will instead use dma-resv
> +object for that (See `VM_BIND dma_resv usage`_).
> +
> +So, a lot of existing code supporting execbuf2 ioctl, like relocations, VA
> +evictions, vma lookup table, implicit sync, vma a

Re: [Intel-gfx] [PATCH v6 3/3] drm/doc/rfc: VM_BIND uapi definition

[Zanoni, Paulo R]

On Wed, 2022-06-29 at 23:08 -0700, Niranjana Vishwanathapura wrote:
> On Wed, Jun 29, 2022 at 05:33:49PM -0700, Zanoni, Paulo R wrote:
> > On Sat, 2022-06-25 at 18:49 -0700, Niranjana Vishwanathapura wrote:
> > > VM_BIND and related uapi definitions
> > > 
> > > v2: Reduce the scope to simple Mesa use case.
> > > v3: Expand VM_UNBIND documentation and add
> > > I915_GEM_VM_BIND/UNBIND_FENCE_VALID
> > > and I915_GEM_VM_BIND_TLB_FLUSH flags.
> > > v4: Remove I915_GEM_VM_BIND_TLB_FLUSH flag and add additional
> > > documentation for vm_bind/unbind.
> > > v5: Remove TLB flush requirement on VM_UNBIND.
> > > Add version support to stage implementation.
> > > v6: Define and use drm_i915_gem_timeline_fence structure for
> > > all timeline fences.
> > > v7: Rename I915_PARAM_HAS_VM_BIND to I915_PARAM_VM_BIND_VERSION.
> > > Update documentation on async vm_bind/unbind and versioning.
> > > Remove redundant vm_bind/unbind FENCE_VALID flag, execbuf3
> > > batch_count field and I915_EXEC3_SECURE flag.
> > > 
> > > Signed-off-by: Niranjana Vishwanathapura 
> > > 
> > > Reviewed-by: Daniel Vetter 
> > > ---
> > >  Documentation/gpu/rfc/i915_vm_bind.h | 280 +++
> > >  1 file changed, 280 insertions(+)
> > >  create mode 100644 Documentation/gpu/rfc/i915_vm_bind.h
> > > 
> > > diff --git a/Documentation/gpu/rfc/i915_vm_bind.h 
> > > b/Documentation/gpu/rfc/i915_vm_bind.h
> > > new file mode 100644
> > > index ..a93e08bceee6
> > > --- /dev/null
> > > +++ b/Documentation/gpu/rfc/i915_vm_bind.h
> > > @@ -0,0 +1,280 @@
> > > +/* SPDX-License-Identifier: MIT */
> > > +/*
> > > + * Copyright © 2022 Intel Corporation
> > > + */
> > > +
> > > +/**
> > > + * DOC: I915_PARAM_VM_BIND_VERSION
> > > + *
> > > + * VM_BIND feature version supported.
> > > + * See typedef drm_i915_getparam_t param.
> > > + *
> > > + * Specifies the VM_BIND feature version supported.
> > > + * The following versions of VM_BIND have been defined:
> > > + *
> > > + * 0: No VM_BIND support.
> > > + *
> > > + * 1: In VM_UNBIND calls, the UMD must specify the exact mappings created
> > > + *previously with VM_BIND, the ioctl will not support unbinding 
> > > multiple
> > > + *mappings or splitting them. Similarly, VM_BIND calls will not 
> > > replace
> > > + *any existing mappings.
> > > + *
> > > + * 2: The restrictions on unbinding partial or multiple mappings is
> > > + *lifted, Similarly, binding will replace any mappings in the given 
> > > range.
> > > + *
> > > + * See struct drm_i915_gem_vm_bind and struct drm_i915_gem_vm_unbind.
> > > + */
> > > +#define I915_PARAM_VM_BIND_VERSION   57
> > > +
> > > +/**
> > > + * DOC: I915_VM_CREATE_FLAGS_USE_VM_BIND
> > > + *
> > > + * Flag to opt-in for VM_BIND mode of binding during VM creation.
> > > + * See struct drm_i915_gem_vm_control flags.
> > > + *
> > > + * The older execbuf2 ioctl will not support VM_BIND mode of operation.
> > > + * For VM_BIND mode, we have new execbuf3 ioctl which will not accept any
> > > + * execlist (See struct drm_i915_gem_execbuffer3 for more details).
> > > + */
> > > +#define I915_VM_CREATE_FLAGS_USE_VM_BIND (1 << 0)
> > > +
> > > +/* VM_BIND related ioctls */
> > > +#define DRM_I915_GEM_VM_BIND 0x3d
> > > +#define DRM_I915_GEM_VM_UNBIND   0x3e
> > > +#define DRM_I915_GEM_EXECBUFFER3 0x3f
> > > +
> > > +#define DRM_IOCTL_I915_GEM_VM_BIND   DRM_IOWR(DRM_COMMAND_BASE + 
> > > DRM_I915_GEM_VM_BIND, struct drm_i915_gem_vm_bind)
> > > +#define DRM_IOCTL_I915_GEM_VM_UNBIND DRM_IOWR(DRM_COMMAND_BASE + 
> > > DRM_I915_GEM_VM_UNBIND, struct drm_i915_gem_vm_bind)
> > > +#define DRM_IOCTL_I915_GEM_EXECBUFFER3   
> > > DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_EXECBUFFER3, struct 
> > > drm_i915_gem_execbuffer3)
> > > +
> > > +/**
> > > + * struct drm_i915_gem_timeline_fence - An input or output timeline 
> > > fence.
> > > + *
> > > + * The operation will wait for input fence to signal.
> > > + *
> > > + * The returned output fence will be signaled after the completion of the
> > > + * o

Re: [Intel-gfx] [PATCH v6 3/3] drm/doc/rfc: VM_BIND uapi definition

[Zanoni, Paulo R]

On Thu, 2022-06-30 at 09:18 -0700, Niranjana Vishwanathapura wrote:
> On Wed, Jun 29, 2022 at 11:39:52PM -0700, Zanoni, Paulo R wrote:
> > On Wed, 2022-06-29 at 23:08 -0700, Niranjana Vishwanathapura wrote:
> > > On Wed, Jun 29, 2022 at 05:33:49PM -0700, Zanoni, Paulo R wrote:
> > > > On Sat, 2022-06-25 at 18:49 -0700, Niranjana Vishwanathapura wrote:
> > > > > VM_BIND and related uapi definitions
> > > > > 
> > > > > v2: Reduce the scope to simple Mesa use case.
> > > > > v3: Expand VM_UNBIND documentation and add
> > > > > I915_GEM_VM_BIND/UNBIND_FENCE_VALID
> > > > > and I915_GEM_VM_BIND_TLB_FLUSH flags.
> > > > > v4: Remove I915_GEM_VM_BIND_TLB_FLUSH flag and add additional
> > > > > documentation for vm_bind/unbind.
> > > > > v5: Remove TLB flush requirement on VM_UNBIND.
> > > > > Add version support to stage implementation.
> > > > > v6: Define and use drm_i915_gem_timeline_fence structure for
> > > > > all timeline fences.
> > > > > v7: Rename I915_PARAM_HAS_VM_BIND to I915_PARAM_VM_BIND_VERSION.
> > > > > Update documentation on async vm_bind/unbind and versioning.
> > > > > Remove redundant vm_bind/unbind FENCE_VALID flag, execbuf3
> > > > > batch_count field and I915_EXEC3_SECURE flag.
> > > > > 
> > > > > Signed-off-by: Niranjana Vishwanathapura 
> > > > > 
> > > > > Reviewed-by: Daniel Vetter 
> > > > > ---
> > > > >  Documentation/gpu/rfc/i915_vm_bind.h | 280 
> > > > > +++
> > > > >  1 file changed, 280 insertions(+)
> > > > >  create mode 100644 Documentation/gpu/rfc/i915_vm_bind.h
> > > > > 
> > > > > diff --git a/Documentation/gpu/rfc/i915_vm_bind.h 
> > > > > b/Documentation/gpu/rfc/i915_vm_bind.h
> > > > > new file mode 100644
> > > > > index ..a93e08bceee6
> > > > > --- /dev/null
> > > > > +++ b/Documentation/gpu/rfc/i915_vm_bind.h
> > > > > @@ -0,0 +1,280 @@
> > > > > +/* SPDX-License-Identifier: MIT */
> > > > > +/*
> > > > > + * Copyright © 2022 Intel Corporation
> > > > > + */
> > > > > +
> > > > > +/**
> > > > > + * DOC: I915_PARAM_VM_BIND_VERSION
> > > > > + *
> > > > > + * VM_BIND feature version supported.
> > > > > + * See typedef drm_i915_getparam_t param.
> > > > > + *
> > > > > + * Specifies the VM_BIND feature version supported.
> > > > > + * The following versions of VM_BIND have been defined:
> > > > > + *
> > > > > + * 0: No VM_BIND support.
> > > > > + *
> > > > > + * 1: In VM_UNBIND calls, the UMD must specify the exact mappings 
> > > > > created
> > > > > + *previously with VM_BIND, the ioctl will not support unbinding 
> > > > > multiple
> > > > > + *mappings or splitting them. Similarly, VM_BIND calls will not 
> > > > > replace
> > > > > + *any existing mappings.
> > > > > + *
> > > > > + * 2: The restrictions on unbinding partial or multiple mappings is
> > > > > + *lifted, Similarly, binding will replace any mappings in the 
> > > > > given range.
> > > > > + *
> > > > > + * See struct drm_i915_gem_vm_bind and struct drm_i915_gem_vm_unbind.
> > > > > + */
> > > > > +#define I915_PARAM_VM_BIND_VERSION   57
> > > > > +
> > > > > +/**
> > > > > + * DOC: I915_VM_CREATE_FLAGS_USE_VM_BIND
> > > > > + *
> > > > > + * Flag to opt-in for VM_BIND mode of binding during VM creation.
> > > > > + * See struct drm_i915_gem_vm_control flags.
> > > > > + *
> > > > > + * The older execbuf2 ioctl will not support VM_BIND mode of 
> > > > > operation.
> > > > > + * For VM_BIND mode, we have new execbuf3 ioctl which will not 
> > > > > accept any
> > > > > + * execlist (See struct drm_i915_gem_execbuffer3 for more details).
> > > > > + */
> > > > > +#define I915_VM_CREATE_FLAGS_USE_VM_BIND (1 << 0)
> > > > > +
> > > > > +/* VM_BIND related ioctls */
> > > > > +#d

Re: [Intel-gfx] [RFC v3 1/3] drm/doc/rfc: VM_BIND feature design document

[Zanoni, Paulo R]

On Tue, 2022-05-17 at 11:32 -0700, Niranjana Vishwanathapura wrote:
> VM_BIND design document with description of intended use cases.
> 
> v2: Add more documentation and format as per review comments
> from Daniel.
> 
> Signed-off-by: Niranjana Vishwanathapura 
> ---
> 
> diff --git a/Documentation/gpu/rfc/i915_vm_bind.rst 
> b/Documentation/gpu/rfc/i915_vm_bind.rst
> new file mode 100644
> index ..f1be560d313c
> --- /dev/null
> +++ b/Documentation/gpu/rfc/i915_vm_bind.rst
> @@ -0,0 +1,304 @@
> +==
> +I915 VM_BIND feature design and use cases
> +==
> +
> +VM_BIND feature
> +
> +DRM_I915_GEM_VM_BIND/UNBIND ioctls allows UMD to bind/unbind GEM buffer
> +objects (BOs) or sections of a BOs at specified GPU virtual addresses on a
> +specified address space (VM). These mappings (also referred to as persistent
> +mappings) will be persistent across multiple GPU submissions (execbuff calls)
> +issued by the UMD, without user having to provide a list of all required
> +mappings during each submission (as required by older execbuff mode).
> +
> +VM_BIND/UNBIND ioctls will support 'in' and 'out' fences to allow userpace
> +to specify how the binding/unbinding should sync with other operations
> +like the GPU job submission. These fences will be timeline 'drm_syncobj's
> +for non-Compute contexts (See struct drm_i915_vm_bind_ext_timeline_fences).
> +For Compute contexts, they will be user/memory fences (See struct
> +drm_i915_vm_bind_ext_user_fence).
> +
> +VM_BIND feature is advertised to user via I915_PARAM_HAS_VM_BIND.
> +User has to opt-in for VM_BIND mode of binding for an address space (VM)
> +during VM creation time via I915_VM_CREATE_FLAGS_USE_VM_BIND extension.
> +
> +VM_BIND/UNBIND ioctl will immediately start binding/unbinding the mapping in 
> an
> +async worker. The binding and unbinding will work like a special GPU engine.
> +The binding and unbinding operations are serialized and will wait on 
> specified
> +input fences before the operation and will signal the output fences upon the
> +completion of the operation. Due to serialization, completion of an operation
> +will also indicate that all previous operations are also complete.
> +
> +VM_BIND features include:
> +
> +* Multiple Virtual Address (VA) mappings can map to the same physical pages
> +  of an object (aliasing).
> +* VA mapping can map to a partial section of the BO (partial binding).
> +* Support capture of persistent mappings in the dump upon GPU error.
> +* TLB is flushed upon unbind completion. Batching of TLB flushes in some
> +  use cases will be helpful.
> +* Asynchronous vm_bind and vm_unbind support with 'in' and 'out' fences.
> +* Support for userptr gem objects (no special uapi is required for this).
> +
> +Execbuff ioctl in VM_BIND mode
> +---
> +The execbuff ioctl handling in VM_BIND mode differs significantly from the
> +older method. A VM in VM_BIND mode will not support older execbuff mode of
> +binding. In VM_BIND mode, execbuff ioctl will not accept any execlist. Hence,
> +no support for implicit sync. It is expected that the below work will be able
> +to support requirements of object dependency setting in all use cases:
> +
> +"dma-buf: Add an API for exporting sync files"
> +(https://lwn.net/Articles/859290/)

I would really like to have more details here. The link provided points
to new ioctls and we're not very familiar with those yet, so I think
you should really clarify the interaction between the new additions
here. Having some sample code would be really nice too.

For Mesa at least (and I believe for the other drivers too) we always
have a few exported buffers in every execbuf call, and we rely on the
implicit synchronization provided by execbuf to make sure everything
works. The execbuf ioctl also has some code to flush caches during
implicit synchronization AFAIR, so I would guess we rely on it too and
whatever else the Kernel does. Is that covered by the new ioctls?

In addition, as far as I remember, one of the big improvements of
vm_bind was that it would help reduce ioctl latency and cpu overhead.
But if making execbuf faster comes at the cost of requiring additional
ioctls calls for implicit synchronization, which is required on ever
execbuf call, then I wonder if we'll even get any faster at all.
Comparing old execbuf vs plain new execbuf without the new required
ioctls won't make sense.

But maybe I'm wrong and we won't need to call these new ioctls around
every single execbuf ioctl we submit? Again, more clarification and
some code examples here would be really nice. This is a big change on
an important part of the API, we should clarify the new expected usage.

> +
> +This also means, we need an execbuff extension to pass in the batch
> +buffer addresses (See struct drm_i915_gem_execbuffer_ext_batch_addresses).
> +
> +If at all execlist support in execbuff ioctl is

Re: [Intel-gfx] [RFC v3 3/3] drm/doc/rfc: VM_BIND uapi definition

[Zanoni, Paulo R]

On Tue, 2022-05-17 at 11:32 -0700, Niranjana Vishwanathapura wrote:
> VM_BIND and related uapi definitions
> 
> v2: Ensure proper kernel-doc formatting with cross references.
> Also add new uapi and documentation as per review comments
> from Daniel.
> 
> Signed-off-by: Niranjana Vishwanathapura 
> ---
>  Documentation/gpu/rfc/i915_vm_bind.h | 399 +++
>  1 file changed, 399 insertions(+)
>  create mode 100644 Documentation/gpu/rfc/i915_vm_bind.h
> 
> diff --git a/Documentation/gpu/rfc/i915_vm_bind.h 
> b/Documentation/gpu/rfc/i915_vm_bind.h
> new file mode 100644
> index ..589c0a009107
> --- /dev/null
> +++ b/Documentation/gpu/rfc/i915_vm_bind.h
> @@ -0,0 +1,399 @@
> +/* SPDX-License-Identifier: MIT */
> +/*
> + * Copyright © 2022 Intel Corporation
> + */
> +
> +/**
> + * DOC: I915_PARAM_HAS_VM_BIND
> + *
> + * VM_BIND feature availability.
> + * See typedef drm_i915_getparam_t param.
> + */
> +#define I915_PARAM_HAS_VM_BIND   57
> +
> +/**
> + * DOC: I915_VM_CREATE_FLAGS_USE_VM_BIND
> + *
> + * Flag to opt-in for VM_BIND mode of binding during VM creation.
> + * See struct drm_i915_gem_vm_control flags.
> + *
> + * A VM in VM_BIND mode will not support the older execbuff mode of binding.
> + * In VM_BIND mode, execbuff ioctl will not accept any execlist (ie., the
> + * &drm_i915_gem_execbuffer2.buffer_count must be 0).
> + * Also, &drm_i915_gem_execbuffer2.batch_start_offset and
> + * &drm_i915_gem_execbuffer2.batch_len must be 0.
> + * DRM_I915_GEM_EXECBUFFER_EXT_BATCH_ADDRESSES extension must be provided
> + * to pass in the batch buffer addresses.
> + *
> + * Additionally, I915_EXEC_NO_RELOC, I915_EXEC_HANDLE_LUT and
> + * I915_EXEC_BATCH_FIRST of &drm_i915_gem_execbuffer2.flags must be 0
> + * (not used) in VM_BIND mode. I915_EXEC_USE_EXTENSIONS flag must always be
> + * set (See struct drm_i915_gem_execbuffer_ext_batch_addresses).
> + * The buffers_ptr, buffer_count, batch_start_offset and batch_len fields
> + * of struct drm_i915_gem_execbuffer2 are also not used and must be 0.
> + */

From that description, it seems we have:

struct drm_i915_gem_execbuffer2 {
__u64 buffers_ptr;  -> must be 0 (new)
__u32 buffer_count; -> must be 0 (new)
__u32 batch_start_offset;   -> must be 0 (new)
__u32 batch_len;-> must be 0 (new)
__u32 DR1;  -> must be 0 (old)
__u32 DR4;  -> must be 0 (old)
__u32 num_cliprects; (fences)   -> must be 0 since using extensions
__u64 cliprects_ptr; (fences, extensions) -> contains an actual pointer!
__u64 flags;-> some flags must be 0 (new)
__u64 rsvd1; (context info) -> repurposed field (old)
__u64 rsvd2;-> unused
};

Based on that, why can't we just get drm_i915_gem_execbuffer3 instead
of adding even more complexity to an already abused interface? While
the Vulkan-like extension thing is really nice, I don't think what
we're doing here is extending the ioctl usage, we're completely
changing how the base struct should be interpreted based on how the VM
was created (which is an entirely different ioctl).

From Rusty Russel's API Design grading, drm_i915_gem_execbuffer2 is
already at -6 without these changes. I think after vm_bind we'll need
to create a -11 entry just to deal with this ioctl.


+#define I915_VM_CREATE_FLAGS_USE_VM_BIND   (1 << 0)
+
+/**
+ * DOC: I915_CONTEXT_CREATE_FLAGS_LONG_RUNNING
+ *
+ * Flag to declare context as long running.
+ * See struct drm_i915_gem_context_create_ext flags.
+ *
+ * Usage of dma-fence expects that they complete in reasonable amount of time.
+ * Compute on the other hand can be long running. Hence it is not appropriate
+ * for compute contexts to export request completion dma-fence to user.
+ * The dma-fence usage will be limited to in-kernel consumption only.
+ * Compute contexts need to use user/memory fence.
+ *
+ * So, long running contexts do not support output fences. Hence,
+ * I915_EXEC_FENCE_OUT (See &drm_i915_gem_execbuffer2.flags and
+ * I915_EXEC_FENCE_SIGNAL (See &drm_i915_gem_exec_fence.flags) are expected
+ * to be not used.
+ *
+ * DRM_I915_GEM_WAIT ioctl call is also not supported for objects mapped
+ * to long running contexts.
+ */
+#define I915_CONTEXT_CREATE_FLAGS_LONG_RUNNING   (1u << 2)
+
+/* VM_BIND related ioctls */
+#define DRM_I915_GEM_VM_BIND   0x3d
+#define DRM_I915_GEM_VM_UNBIND 0x3e
+#define DRM_I915_GEM_WAIT_USER_FENCE   0x3f
+
+#define DRM_IOCTL_I915_GEM_VM_BIND DRM_IOWR(DRM_COMMAND_BASE + 
DRM_I915_GEM_VM_BIND, struct drm_i915_gem_vm_bind)
+#define DRM_IOCTL_I915_GEM_VM_UNBIND   DRM_IOWR(DRM_COMMAND_BASE + 
DRM_I915_GEM_VM_UNBIND, struct drm_i915_gem_vm_bind)
+#define DRM_IOCTL_I915_GEM_WAIT_USER_FENCE DRM_IOWR(DRM_COMMAND_BASE + 
DRM_I915_GEM_WAIT_USER_FENCE, struct drm_i915_gem_wait_user_fence)
+

Re: [Intel-gfx] [PATCH] drm/i915/gen9: Give one extra block per line for SKL plane WM calculations

[Zanoni, Paulo R]

Em Qui, 2016-08-04 às 16:51 -0700, Matt Roper escreveu:
> On Thu, Aug 04, 2016 at 07:36:15PM -0400, Lyude wrote:
> > 
> > Reviewed-by: Lyude 
> 
> Merged to dinq.  Thanks for the quick review.

Regression? This patch makes my SKL machine fail any modesets. I now
boot to a blinking screen where X keeps trying to start and fails.

Xorg.0.log gives me:
[   273.512] (EE) modeset(0): failed to set mode: Invalid argument


On the dmesg side, these are the more suspicious messages:

[  273.583659] [drm:skl_compute_plane_wm] Requested display
configuration exceeds system watermark limitations
[  273.583663] [drm:skl_compute_plane_wm] Plane 1.0: blocks required =
4/0, lines required = 1/31


I tried applying Lyude's series to nightly to see if it fixes
something, but it looks like patch 2 doesn't apply.

> 
> 
> Matt
> 
> > 
> > 
> > On Thu, 2016-08-04 at 14:08 -0700, Matt Roper wrote:
> > > 
> > > The bspec was updated a couple weeks ago to add an extra block
> > > per
> > > line
> > > to plane watermark calculations for linear pixel formats.
> > > 
> > > Bspec update 115327 description:
> > >   "Gen9+ - Updated the plane blocks per line calculation for
> > > linear
> > >   cases. Adds +1 for all linear cases to handle the non-block
> > > aligned
> > >   stride cases."
> > > 
> > > Cc: Lyude 
> > > Signed-off-by: Matt Roper 
> > > ---
> > >  drivers/gpu/drm/i915/intel_pm.c | 2 ++
> > >  1 file changed, 2 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > > b/drivers/gpu/drm/i915/intel_pm.c
> > > index 4317cdf..6bd352a 100644
> > > --- a/drivers/gpu/drm/i915/intel_pm.c
> > > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > > @@ -3352,6 +3352,8 @@ static uint32_t skl_wm_method2(uint32_t
> > > pixel_rate, uint32_t pipe_htotal,
> > >   plane_bytes_per_line *= 4;
> > >   plane_blocks_per_line =
> > > DIV_ROUND_UP(plane_bytes_per_line, 512);
> > >   plane_blocks_per_line /= 4;
> > > + } else if (tiling == DRM_FORMAT_MOD_NONE) {
> > > + plane_blocks_per_line =
> > > DIV_ROUND_UP(plane_bytes_per_line, 512) + 1;
> > >   } else {
> > >   plane_blocks_per_line =
> > > DIV_ROUND_UP(plane_bytes_per_line, 512);
> > >   }
> > -- 
> > Cheers,
> > Lyude
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/gen9: Give one extra block per line for SKL plane WM calculations

[Zanoni, Paulo R]

Em Seg, 2016-08-08 às 18:25 +, Zanoni, Paulo R escreveu:
> Em Qui, 2016-08-04 às 16:51 -0700, Matt Roper escreveu:
> > 
> > On Thu, Aug 04, 2016 at 07:36:15PM -0400, Lyude wrote:
> > > 
> > > 
> > > Reviewed-by: Lyude 
> > 
> > Merged to dinq.  Thanks for the quick review.
> 
> Regression? This patch makes my SKL machine fail any modesets. I now
> boot to a blinking screen where X keeps trying to start and fails.
> 
> Xorg.0.log gives me:
> [   273.512] (EE) modeset(0): failed to set mode: Invalid argument
> 
> 
> On the dmesg side, these are the more suspicious messages:
> 
> [  273.583659] [drm:skl_compute_plane_wm] Requested display
> configuration exceeds system watermark limitations
> [  273.583663] [drm:skl_compute_plane_wm] Plane 1.0: blocks required
> =
> 4/0, lines required = 1/31
> 
> 
> I tried applying Lyude's series to nightly to see if it fixes
> something, but it looks like patch 2 doesn't apply.

The patches do apply, I was confused by the email threading and mixed
patch 6 v9 with patch 2. Lyude's series fix the regression :).

> 
> > 
> > 
> > 
> > Matt
> > 
> > > 
> > > 
> > > 
> > > On Thu, 2016-08-04 at 14:08 -0700, Matt Roper wrote:
> > > > 
> > > > 
> > > > The bspec was updated a couple weeks ago to add an extra block
> > > > per
> > > > line
> > > > to plane watermark calculations for linear pixel formats.
> > > > 
> > > > Bspec update 115327 description:
> > > >   "Gen9+ - Updated the plane blocks per line calculation for
> > > > linear
> > > >   cases. Adds +1 for all linear cases to handle the non-block
> > > > aligned
> > > >   stride cases."
> > > > 
> > > > Cc: Lyude 
> > > > Signed-off-by: Matt Roper 
> > > > ---
> > > >  drivers/gpu/drm/i915/intel_pm.c | 2 ++
> > > >  1 file changed, 2 insertions(+)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > > > b/drivers/gpu/drm/i915/intel_pm.c
> > > > index 4317cdf..6bd352a 100644
> > > > --- a/drivers/gpu/drm/i915/intel_pm.c
> > > > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > > > @@ -3352,6 +3352,8 @@ static uint32_t skl_wm_method2(uint32_t
> > > > pixel_rate, uint32_t pipe_htotal,
> > > >     plane_bytes_per_line *= 4;
> > > >     plane_blocks_per_line =
> > > > DIV_ROUND_UP(plane_bytes_per_line, 512);
> > > >     plane_blocks_per_line /= 4;
> > > > +   } else if (tiling == DRM_FORMAT_MOD_NONE) {
> > > > +   plane_blocks_per_line =
> > > > DIV_ROUND_UP(plane_bytes_per_line, 512) + 1;
> > > >     } else {
> > > >     plane_blocks_per_line =
> > > > DIV_ROUND_UP(plane_bytes_per_line, 512);
> > > >     }
> > > -- 
> > > Cheers,
> > >   Lyude
> > 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/gen9: Give one extra block per line for SKL plane WM calculations

[Zanoni, Paulo R]

Em Seg, 2016-08-08 às 19:35 +0100, Chris Wilson escreveu:
> On Mon, Aug 08, 2016 at 06:25:49PM +0000, Zanoni, Paulo R wrote:
> > 
> > Em Qui, 2016-08-04 às 16:51 -0700, Matt Roper escreveu:
> > > 
> > > On Thu, Aug 04, 2016 at 07:36:15PM -0400, Lyude wrote:
> > > > 
> > > > 
> > > > Reviewed-by: Lyude 
> > > 
> > > Merged to dinq.  Thanks for the quick review.
> > 
> > Regression? This patch makes my SKL machine fail any modesets. I
> > now
> > boot to a blinking screen where X keeps trying to start and fails.
> 
> -intel has been fixing up failed multi-CRTC modesets since seemingly
> forever on skl, that fail due to WM being exceeded. And why would
> modesetting even be trying to use a non-tiled framebuffer?

I'm just using my distro's default driver, and Debian uses modesetting
now.

I did switch to xf86-video-intel and I found something interesting: the
machine boots correctly, but then if I stop+restart lightdm, I get a
black screen. The difference here is that X doesn't abort, it tries to
keep working despite the black screen:

[46.483] (EE) intel(0): failed to set mode: Invalid argument [22]
[46.485] (II) intel(0): EDID vendor "SDC", prod id 16970
[46.485] (II) intel(0): Printing DDC gathered Modelines:
[46.485] (II) intel(0): Modeline "3200x1800"x0.0  361.31  3200 3248
3280 3316  1800 1802 1807 1816 -hsync -vsync (109.0 kHz eP)
[46.485] (II) intel(0): Modeline "3200x1800"x0.0  361.31  3200 3248
3280 3680  1800 1802 1807 2045 -hsync -vsync (98.2 kHz e)
[46.794] (--) intel(0): HDMI max TMDS frequency 225000KHz
[46.969] (EE) intel(0): failed to set mode: Invalid argument [22]

And dmesg has the same message as when using xf86-video-modesetting:

[   46.928018] [drm:skl_compute_plane_wm] Requested display
configuration exceeds system watermark limitations
[   46.928021] [drm:skl_compute_plane_wm] Plane 1.0: blocks required =
4/0, lines required = 1/31

Notice that this is the distro's driver version:
2:2.99.917+git20160706-1

So it looks like switching back to xf86-video-intel won't be a perfect
fix.

Anyway, while using the DDX to work around Kernel bugs may have some
benefits, it's probably best to try to push for an appropriate Kernel
fix, especially now that xf86-video-modesetting is gaining some market
share...

> -Chris
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v10] drm/i915/skl: Add support for the SAGV, fix underrun hangs

[Zanoni, Paulo R]

Em Ter, 2016-08-09 às 14:44 +0200, Maarten Lankhorst escreveu:
> Hey,
> 
> Op 08-08-16 om 23:03 schreef Lyude:
> > 
> > Since the watermark calculations for Skylake are still broken,
> > we're apt
> > to hitting underruns very easily under multi-monitor
> > configurations.
> > While it would be lovely if this was fixed, it's not. Another
> > problem
> > that's been coming from this however, is the mysterious issue of
> > underruns causing full system hangs. An easy way to reproduce this
> > with
> > a skylake system:
> > 
> > - Get a laptop with a skylake GPU, and hook up two external
> > monitors to
> >   it
> > - Move the cursor from the built-in LCD to one of the external
> > displays
> >   as quickly as you can
> > - You'll get a few pipe underruns, and eventually the entire system
> > will
> >   just freeze.
> > 
> > After doing a lot of investigation and reading through the bspec, I
> > found the existence of the SAGV, which is responsible for adjusting
> > the
> > system agent voltage and clock frequencies depending on how much
> > power
> > we need. According to the bspec:
> > 
> > "The display engine access to system memory is blocked during the
> >  adjustment time. SAGV defaults to enabled. Software must use the
> >  GT-driver pcode mailbox to disable SAGV when the display engine is
> > not
> >  able to tolerate the blocking time."
> > 
> > The rest of the bspec goes on to explain that software can simply
> > leave
> > the SAGV enabled, and disable it when we use interlaced pipes/have
> > more
> > then one pipe active.
> > 
> > Sure enough, with this patchset the system hangs resulting from
> > pipe
> > underruns on Skylake have completely vanished on my T460s.
> > Additionally,
> > the bspec mentions turning off the SAGV with more then one
> > pipe enabled
> > as a workaround for display underruns. While this patch doesn't
> > entirely
> > fix that, it looks like it does improve the situation a little bit
> > so
> > it's likely this is going to be required to make watermarks on
> > Skylake
> > fully functional.
> 
> I think this patch goes with v9 6/6 and v8 2-5/6. If you're only
> updating a single patch it might be better to send it in reply to the
> original patch.
> 
> I'm testing the whole series on my prerelease skylake, and running
> into this:
> 
> [ 2794.933149] kms_cursor_legacy: starting subtest 2x-flip-vs-cursor-
> legacy
> [ 2795.813970] [drm:skl_disable_sagv [i915]] *ERROR* Request to
> disable SAGV timed out
> 
> Value returned from skl_do_sagv_disable is always 0 for me, even when
> I bump the timeout to 15.

Yesterday I started testing this series, and I also noticed some visual
corruption: while browsing moderately-heavy websites on a maximized
Firefox, I could see the desktop background sort of "blinking" in the
screen (the background was not supposed to be visible). It looks like
the problem was introduced by patch 4, but I can't be 100% sure since
sometimes it's a little harder to reproduce it. Still, this is better
than the current "X doesn't work" state that we have without the
series.

> 
> ~Maarten
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] drm/i915/fbc: disable FBC on FIFO underruns

[Zanoni, Paulo R]

Em Sáb, 2016-08-13 às 10:05 +0100, Chris Wilson escreveu:
> On Fri, Aug 12, 2016 at 11:24:59PM +, Pandiyan, Dhinakaran wrote:
> Do we know why we get black screens in this scenario?

I don't know exactly, but I can speculate that it's probably because
the display engine fails to decompress the framebuffer and gets
completely lost on when the data ends, so it gives up and shows black.

> > 
> > > 
> > > +/**
> > > + * intel_fbc_handle_fifo_underrun - disable FBC when we get a
> > > FIFO underrun
> > > + * @dev_priv: i915 device instance
> > > + *
> > > + * Without FBC, most underruns are harmless and don't really
> > > cause too many
> > > + * problems, except for an annoying message on dmesg. With FBC,
> > > underruns can
> > > + * become black screens or even worse, especially when paired
> > > with bad
> > > + * watermarks. So in order for us to be on the safe side,
> > > completely disable FBC
> > > + * in case we ever detect a FIFO underrun on any pipe. An
> > > underrun on any pipe
> > > + * already suggests that watermarks may be bad, so try to be as
> > > safe as
> > > + * possible.
> > > + */
> > > +void intel_fbc_handle_fifo_underrun(struct drm_i915_private
> > > *dev_priv)
> > > +{
> > > + struct intel_fbc *fbc = &dev_priv->fbc;
> > > +
> > > + if (!fbc_supported(dev_priv))
> > > + return;
> > > +
> > 
> > Should we bail out if fbc is not enabled?

No. Even if FBC is disabled or deactivated we need to make sure the
code doesn't decide to enable/activate FBC later, and simply disabling
it now won't prevent it from being reactivated on the next modesets.

> > Also, can we just disable fbc if we see an underrun instead of
> > using a
> > new flag to prevent activation?

No, for the same reason as above: we don't want the code to decide to
enable/activate FBC later.

> 
> The information that is crucially absent in the function name, and
> its
> kerneldoc, is that this function is run from hardirq context. There
> isn't
> much you are allowed to do here but schedule work.

You're right. I'll rename the function and improve the doc.

> -Chris
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 11/25] drm/i915/fbc: fix the FBC state checking code

[Zanoni, Paulo R]

Em Seg, 2016-08-15 às 21:55 +0100, Chris Wilson escreveu:
> On Tue, Jan 19, 2016 at 11:35:44AM -0200, Paulo Zanoni wrote:
> > 
> > We'll now call intel_fbc_pre_update instead of intel_fbc_deactivate
> > during atomic commits. This will continue to guarantee that we
> > deactivate FBC and it will also update the state checking
> > structures
> > at the correct time. Then, later, at the point where we were
> > calling
> > intel_fbc_update, we'll only need to call intel_fbc_post_update.
> > 
> > Also add the proper warnings in case we don't have the appropriate
> > locks. Daniel mentioned the warnings will have to be removed for
> > async
> > commits, but let's keep them here while we can.
> > 
> > Signed-off-by: Paulo Zanoni 
> > ---
> >  drivers/gpu/drm/i915/intel_display.c | 11 +--
> >  drivers/gpu/drm/i915/intel_drv.h |  8 +---
> >  drivers/gpu/drm/i915/intel_fbc.c | 33 ++
> > ---
> >  3 files changed, 28 insertions(+), 24 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index baab41046..baa4cc9 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> 
> > 
> > @@ -11733,7 +11733,7 @@ static int intel_crtc_page_flip(struct
> > drm_crtc *crtc,
> >       to_intel_plane(primary)-
> > >frontbuffer_bit);
> >     mutex_unlock(&dev->struct_mutex);
> >  
> > -   intel_fbc_deactivate(intel_crtc);
> > +   intel_fbc_pre_update(intel_crtc);
> >     intel_frontbuffer_flip_prepare(dev,
> >        to_intel_plane(primary)-
> > >frontbuffer_bit);
> >  
> > +void intel_fbc_pre_update(struct intel_crtc *crtc)
> >  {
> >     struct drm_i915_private *dev_priv = crtc->base.dev-
> > >dev_private;
> >     struct intel_fbc *fbc = &dev_priv->fbc;
> >  
> > -   WARN_ON(!mutex_is_locked(&fbc->lock));
> > +   if (!fbc_supported(dev_priv))
> > +   return;
> > +
> > +   mutex_lock(&fbc->lock);
> >  
> >     if (!multiple_pipes_ok(dev_priv)) {
> >     set_no_fbc_reason(dev_priv, "more than one pipe
> > active");
> > @@ -907,15 +915,17 @@ static void intel_fbc_pre_update(struct
> > intel_crtc *crtc)
> >     }
> >  
> >     if (!fbc->enabled || fbc->crtc != crtc)
> > -   return;
> > +   goto unlock;
> >  
> >     intel_fbc_update_state_cache(crtc);
> >  
> >  deactivate:
> >     __intel_fbc_deactivate(dev_priv);
> > +unlock:
> > +   mutex_unlock(&fbc->lock);
> >  }
> 
> 
> So this change is broken as intel_fbc_pre_update() depends upon state
> derived from the pinned framebuffer object but is being called by
> intel_crtc_page_flip() before that object is pinned with
> intel_pin_and_fence_fb - i.e. state such as the gtt_offset or the
> fence
> for the object are incorrect, and even trying to look at them can
> cause
> an oops.

Nope:
$ git show
1eb52238a5f5b6a3f497b47e6da39ccfebe6b878:drivers/gpu/drm/i915/intel_dis
play.c

Back when the commit was merged, the pre_update() call was done after
pin_and_fence_fb(). It looks like some later commit introduced the
problem you point.

Still, looks like we have code to fix.

> -Chris
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Call intel_fbc_pre_update() after pinning the new pageflip

[Zanoni, Paulo R]

Em Ter, 2016-08-16 às 08:43 +0100, Chris Wilson escreveu:
> intel_fbc_pre_update() depends upon the new state being already
> pinned
> in place in the Global GTT (primarily for both fencing which wants
> both
> an offset and a fence register, if assigned). This requires the call
> to
> intel_fbc_pre_update() be after intel_pin_and_fence_fb() - but commit
> 5a21b6650a23 ("drm/i915: Revert async unpin and nonblocking atomic
> commit") seems to have returned the code to a different state.
> 
> Fixes 5a21b6650a23 ("drm/i915: Revert async unpin and
> nonblocking...")

I think it actually fixes e8216e502acaad129210c3c8b30cb4ab41e70239
("drm/i915/fbc: call intel_fbc_pre_update earlier during page flips").

> Signed-off-by: Chris Wilson 
> Cc: Daniel Vetter 
> Cc: "Zanoni, Paulo R" 
> Cc: Ville Syrjälä 
> Cc: Maarten Lankhorst 
> Cc: Patrik Jakobsson 
> Cc: drm-intel-fi...@lists.freedesktop.org
> ---
>  drivers/gpu/drm/i915/intel_display.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 37d71d5d2369..916ce7b2d4d7 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -12061,9 +12061,6 @@ static int intel_crtc_page_flip(struct
> drm_crtc *crtc,
>   crtc->primary->fb = fb;
>   update_state_fb(crtc->primary);
>  
> - intel_fbc_pre_update(intel_crtc, intel_crtc->config,
> -  to_intel_plane_state(primary->state));
> -
>   work->pending_flip_obj = i915_gem_object_get(obj);
>  
>   ret = i915_mutex_lock_interruptible(dev);
> @@ -12109,6 +12106,9 @@ static int intel_crtc_page_flip(struct
> drm_crtc *crtc,
>   work->gtt_offset += intel_crtc->dspaddr_offset;
>   work->rotation = crtc->primary->state->rotation;
>  
> + intel_fbc_pre_update(intel_crtc, intel_crtc->config,
> +  to_intel_plane_state(primary->state));
> +

After you reported the problem yesterday I wrote almost the exact same
patch and just didn't submit it because I didn't have time to test it.
I also added a little comment on top of the call to try to prevent us
from further regressions:

/* There's the potential that the next frame will not be compatible
with FBC, so we want to call pre_update() before the actual page flip.
The problem is that pre_update() caches some information about the fb
object, so we want to do this only after the object is pinned. Let's be
on the safe side and do this immediately before scheduling the
flip. */

With or without this or some other comment:
Reviewed-by: Paulo Zanoni 

>   if (mmio_flip) {
>   INIT_WORK(&work->mmio_work,
> intel_mmio_flip_work_func);
>  
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Call intel_fbc_pre_update() after pinning the new pageflip

[Zanoni, Paulo R]

Em Qua, 2016-08-17 às 20:49 +0100, Chris Wilson escreveu:
> On Wed, Aug 17, 2016 at 04:41:44PM -0300, Paulo Zanoni wrote:
> > 
> > From: Chris Wilson 
> > 
> > intel_fbc_pre_update() depends upon the new state being already
> > pinned
> > in place in the Global GTT (primarily for both fencing which wants
> > both
> > an offset and a fence register, if assigned). This requires the
> > call to
> > intel_fbc_pre_update() be after intel_pin_and_fence_fb() - but
> > commit
> > e8216e502aca ("drm/i915/fbc: call intel_fbc_pre_update earlier
> > during
> > page flips") moved the code way too much up in its attempt to call
> > it
> > before the page flip.
> > 
> > v2 (from Paulo):
> >  - Point the original bad commit.
> >  - Add a comment to maybe prevent further regressions.
> > 
> > Fixes: e8216e502aca ("drm/i915/fbc: call intel_fbc_pre_update
> > earlier...")
> > Signed-off-by: Chris Wilson 
> > Signed-off-by: Paulo Zanoni 
> > Cc: Daniel Vetter 
> > Cc: Ville Syrjälä 
> > Cc: Maarten Lankhorst 
> > Cc: Patrik Jakobsson 
> > Cc: drm-intel-fi...@lists.freedesktop.org
> 
> If you had just claimed this as your own, I could have reviewed it ;)

I don't want to steal your patch, you submitted it first, so you should
get the credit.

I thought about adding my R-B, but then I remembered reading somewhere
that having my Signed-off-by was enough and implicitly meant a R-B.
Anyway, feel free to add:
Reviewed-by: Paulo Zanoni  (v1)

I suppose it would also make sense for you to add R-B: Chris (v2) since
I modified the original.

Also, feel free to merge this.

> -Chris
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Mark up the GTT flush following WC writes as ORIGIN_CPU

[Zanoni, Paulo R]

Em Qua, 2016-08-17 às 19:20 +0100, Chris Wilson escreveu:
> Similarly to invalidating beforehand, if the object is mmapped via
> I915_MMAP_WC we cannot track writes through the I915_GEM_DOMAIN_GTT.
> At
> the conclusion of the write, i915_gem_object_flush_gtt_writes() we
> also
> need to treat the origin carefully in case it may have been
> untracked.
> 
> See also commit aeecc9696aa0 ("drm/i915: use ORIGIN_CPU for
> frontbuffer
> invalidation on WC mmaps").

This patch doesn't apply cleanly to drm-intel-nightly. I reviewed it
based on the current state of my tree, and it makes sense to me, so
unless your tree as super significant changes in this area:

Reviewed-by: Paulo Zanoni 

> 
> Signed-off-by: Chris Wilson 
> Cc: Daniel Vetter 
> Cc: Paulo Zanoni 
> ---
>  drivers/gpu/drm/i915/i915_gem.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem.c
> b/drivers/gpu/drm/i915/i915_gem.c
> index 161efa96aeda..d07ff0138deb 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -3105,7 +3105,7 @@ i915_gem_object_flush_gtt_write_domain(struct
> drm_i915_gem_object *obj)
>   if (INTEL_GEN(dev_priv) >= 6 && !HAS_LLC(dev_priv))
>   POSTING_READ(RING_ACTHD(dev_priv-
> >engine[RCS].mmio_base));
>  
> - intel_fb_obj_flush(obj, false, ORIGIN_GTT);
> + intel_fb_obj_flush(obj, false, write_origin(obj,
> I915_GEM_DOMAIN_GTT));
>  
>   obj->base.write_domain = 0;
>   trace_i915_gem_object_change_domain(obj,
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] drm/i915/fbc: Allow on unfenced surfaces, for recent gen

[Zanoni, Paulo R]

Em Qui, 2016-08-18 às 09:21 +0100, Chris Wilson escreveu:
> Only fbc1 is tied to using a fence. Later iterations of fbc are more
> flexible and allow operation on unfenced frontbuffers.

But then we'll lose GTT tracking - which we currently rely on - and I'm
87.5% sure we'll need to implement some workarounds we skipped.

> 
> Signed-off-by: Chris Wilson 
> Cc: Daniel Vetter 
> Cc: "Zanoni, Paulo R" 
> ---
>  drivers/gpu/drm/i915/intel_fbc.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_fbc.c
> b/drivers/gpu/drm/i915/intel_fbc.c
> index 57e1ca624d73..9534f90c6551 100644
> --- a/drivers/gpu/drm/i915/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/intel_fbc.c
> @@ -789,8 +789,10 @@ static bool intel_fbc_can_activate(struct
> intel_crtc *crtc)
>    */
>   if (cache->fb.tiling_mode != I915_TILING_X ||
>   cache->fb.fence_reg == I915_FENCE_REG_NONE) {
> - fbc->no_fbc_reason = "framebuffer not tiled or
> fenced";
> - return false;
> + if (INTEL_GEN(dev_priv) < 5) {
> + fbc->no_fbc_reason = "framebuffer not tiled
> or fenced";
> + return false;
> + }
>   }
>   if (INTEL_INFO(dev_priv)->gen <= 4 && !IS_G4X(dev_priv) &&
>   cache->plane.rotation != DRM_ROTATE_0) {
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] drm/i915/fbc: Allow on unfenced surfaces, for recent gen

[Zanoni, Paulo R]

Em Qui, 2016-08-18 às 09:21 +0100, Chris Wilson escreveu:
> Only fbc1 is tied to using a fence. Later iterations of fbc are more
> flexible and allow operation on unfenced frontbuffers.
> 
> Signed-off-by: Chris Wilson 
> Cc: Daniel Vetter 
> Cc: "Zanoni, Paulo R" 

Hi

I see this patch was applied. Now, on my Skylake machine, if I boot
with i915.enable_fbc=1 I'll get FIFO underruns under fbcon. Just
booting already gives me a FIFO underrun message, and then if I "sudo
systemctl stop lightdm" I'll get a constantly-blinking screen.

Of course, applying the patch that disables FBC after a FIFO underrun
will help stopping the ever-blinking fbcon, but I think we should try
to avoid the underruns in the places we know we can, and leave the
"disable FBC on FIFO underruns" just for the cases we're not expecting.

Also, please remember that I mentioned there are FBC workarounds for
untiled that we still don't implement. IMHO this argument alone should
have prevented this patch from being merged...

Based on that, can we please revert this patch? I'm afraid some people
would consider these underruns as blockers to enabling FBC, so it's
probably better to enable FBC only on X tiled for now, and leave this
for when we know how to prevent the underrun.

Thanks,
Paulo

> ---
>  drivers/gpu/drm/i915/intel_fbc.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_fbc.c
> b/drivers/gpu/drm/i915/intel_fbc.c
> index 57e1ca624d73..9534f90c6551 100644
> --- a/drivers/gpu/drm/i915/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/intel_fbc.c
> @@ -789,8 +789,10 @@ static bool intel_fbc_can_activate(struct
> intel_crtc *crtc)
>    */
>   if (cache->fb.tiling_mode != I915_TILING_X ||
>   cache->fb.fence_reg == I915_FENCE_REG_NONE) {
> - fbc->no_fbc_reason = "framebuffer not tiled or
> fenced";
> - return false;
> + if (INTEL_GEN(dev_priv) < 5) {
> + fbc->no_fbc_reason = "framebuffer not tiled
> or fenced";
> + return false;
> + }
>   }
>   if (INTEL_INFO(dev_priv)->gen <= 4 && !IS_G4X(dev_priv) &&
>   cache->plane.rotation != DRM_ROTATE_0) {
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] drm/i915/fbc: Allow on unfenced surfaces, for recent gen

[Zanoni, Paulo R]

Em Qua, 2016-08-24 às 07:43 +0100, Chris Wilson escreveu:
> On Mon, Aug 22, 2016 at 09:39:17PM -0300, Paulo Zanoni wrote:
> > 
> > 2016-08-18 5:21 GMT-03:00 Chris Wilson :
> > > 
> > > Only fbc1 is tied to using a fence. Later iterations of fbc are
> > > more
> > > flexible and allow operation on unfenced frontbuffers.
> > > 
> > > Signed-off-by: Chris Wilson 
> > > Cc: Daniel Vetter 
> > > Cc: "Zanoni, Paulo R" 
> > 
> > Hi
> > 
> > I see this patch was applied. Now, on my Skylake machine, if I boot
> > with i915.enable_fbc=1 I'll get FIFO underruns under fbcon. Just
> > booting already gives me a FIFO underrun message, and then if I
> > "sudo
> > systemctl stop lightdm" I'll get a constantly-blinking screen.
> > 
> > Of course, applying the patch that disables FBC after a FIFO
> > underrun
> > will help stopping the ever-blinking fbcon, but I think we should
> > try
> > to avoid the underruns in the places we know we can, and leave the
> > "disable FBC on FIFO underruns" just for the cases we're not
> > expecting.
> > 
> > Also, please remember that I mentioned there are FBC workarounds
> > for
> > untiled that we still don't implement (although when I re-read my
> > email it may sound like I suggested the workarounds are for non-GTT
> > tracking). IMHO this argument alone should
> > have prevented this patch from being merged...
> > 
> > Based on that, can we please revert this patch? I'm afraid some
> > people
> > would consider these underruns as blockers to enabling FBC, so it's
> > probably better to enable FBC only on X tiled for now, and leave
> > this
> > for when we know how to prevent the underrun (possibly by
> > implementing
> > the missing WAs).
> 
> Sure you can disable FBC - just note that typically framebuffers will
> be
> unfenced.

So we need to investigate why the underruns are happening and implement
the missing workarounds. But IMHO while that's still not happening, tem
porarily reverting the patch seems to be the way to keep the codebase
sane.

> -Chris
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2] drm/i915/dp: Switch to using the DRM function for reading DP link status

[Zanoni, Paulo R]

Em Qua, 2016-08-17 às 12:02 -0700, Dhinakaran Pandiyan escreveu:
> Since a DRM function that reads link DP link status is available,
> let's
> use that instead of the i915 clone.

One could describe the i915 function as a convenient wrapper instead of
a clone, since it allows passing just intel_dp as an argument and
already does the length checking, allowing callers to stay under 80
columns :). So perhaps you could have given more arguments on why the
codebase will benefit from this change.

I'm not sure whether I think the code will be better or worse with this
change, but the patch does what it says, so:
Reviewed-by: Paulo Zanoni 

> 

> 
> drm_dp_dpcd_read_link_status() returns a negative error code if the
> number
> of bytes read is not DP_LINK_STATUS_SIZE, drm_dp_dpcd_access() does
> the
> length check.
> 
> Signed-off-by: Dhinakaran Pandiyan 
> 
> v2: Eliminated redundant DP_LINK_STATUS_SIZE length check.

On our driver we usually put version information above the signatures
and tags.

> ---
>  drivers/gpu/drm/i915/intel_dp.c   | 15 ++-
>  drivers/gpu/drm/i915/intel_dp_link_training.c |  8 ++--
>  drivers/gpu/drm/i915/intel_drv.h  |  2 --
>  3 files changed, 8 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c
> b/drivers/gpu/drm/i915/intel_dp.c
> index 8fe2afa..8eff57e 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -2863,17 +2863,6 @@ static void chv_dp_post_pll_disable(struct
> intel_encoder *encoder)
>   chv_phy_post_pll_disable(encoder);
>  }
>  
> -/*
> - * Fetch AUX CH registers 0x202 - 0x207 which contain
> - * link status information
> - */
> -bool
> -intel_dp_get_link_status(struct intel_dp *intel_dp, uint8_t
> link_status[DP_LINK_STATUS_SIZE])
> -{
> - return drm_dp_dpcd_read(&intel_dp->aux, DP_LANE0_1_STATUS,
> link_status,
> - DP_LINK_STATUS_SIZE) ==
> DP_LINK_STATUS_SIZE;
> -}
> -
>  /* These are source-specific values. */
>  uint8_t
>  intel_dp_voltage_max(struct intel_dp *intel_dp)
> @@ -3896,8 +3885,8 @@ intel_dp_check_link_status(struct intel_dp
> *intel_dp)
>  
>   WARN_ON(!drm_modeset_is_locked(&dev-
> >mode_config.connection_mutex));
>  
> - if (!intel_dp_get_link_status(intel_dp, link_status)) {
> - DRM_ERROR("Failed to get link status\n");
> + if (drm_dp_dpcd_read_link_status(&intel_dp->aux,
> link_status) <= 0) {
> + DRM_ERROR("failed to get link status\n");


You just made me run "grep DRM_ERROR * | cut -d'"' -f2 | sort" in order
to check how consistent we are regarding error message capitalization
:).

    return;
>   }
>  
> diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c
> b/drivers/gpu/drm/i915/intel_dp_link_training.c
> index 60fb39c..8e60e7c 100644
> --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
> +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
> @@ -150,7 +150,9 @@ intel_dp_link_training_clock_recovery(struct
> intel_dp *intel_dp)
>   uint8_t link_status[DP_LINK_STATUS_SIZE];
>  
>   drm_dp_link_train_clock_recovery_delay(intel_dp-
> >dpcd);
> - if (!intel_dp_get_link_status(intel_dp,
> link_status)) {
> +
> + if (drm_dp_dpcd_read_link_status(&intel_dp->aux,
> link_status)
> +  <= 0) {
>   DRM_ERROR("failed to get link status\n");
>   break;
>   }
> @@ -258,7 +260,9 @@
> intel_dp_link_training_channel_equalization(struct intel_dp
> *intel_dp)
>   }
>  
>   drm_dp_link_train_channel_eq_delay(intel_dp->dpcd);
> - if (!intel_dp_get_link_status(intel_dp,
> link_status)) {
> +
> + if (drm_dp_dpcd_read_link_status(&intel_dp->aux,
> link_status)
> +  <= 0) {
>   DRM_ERROR("failed to get link status\n");
>   break;
>   }
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index b1fc67e..a3a2cb9 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1394,8 +1394,6 @@ intel_dp_pre_emphasis_max(struct intel_dp
> *intel_dp, uint8_t voltage_swing);
>  void intel_dp_compute_rate(struct intel_dp *intel_dp, int
> port_clock,
>      uint8_t *link_bw, uint8_t *rate_select);
>  bool intel_dp_source_supports_hbr2(struct intel_dp *intel_dp);
> -bool
> -intel_dp_get_link_status(struct intel_dp *intel_dp, uint8_t
> link_status[DP_LINK_STATUS_SIZE]);
>  
>  static inline unsigned int intel_dp_unused_lane_mask(int lane_count)
>  {
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [CI] Revert "drm/i915/fbc: Allow on unfenced surfaces, for recent gen"

[Zanoni, Paulo R]

Em Qua, 2016-08-24 às 19:00 +0100, Chris Wilson escreveu:
> This reverts commit 8678fdaf396c ("drm/i915/fbc: Allow on unfenced
> surfaces,
> for recent gen") as Skylake has issues with unfenced FBC tracking
> (and
> yes Skylake doesn't even enable FBC yet)

But it used to work if you had i915.enable_fbc=1 after your latest
fixes :)

> . Paulo would like to do a full
> review of all existing workarounds to see if any more are missing
> prior
> to allowing FBC on unfenced surfaces

We are missing at least one workaround for this, and it's described in
the FBC_CTL page of BSpec for SKL, bit 31 description: we need to
calculate the compressed buffer stride and program it to a register.

I didin't say I would do the review of all existing workarounds, just
that someone needs to do this before enabling FBC on non-X-tiled
buffers since I recall skipping the implementation of workarounds that
didn't apply to X-tiling. Maybe the one I mentioned was the only one,
maybe not.

Also, our test suite only tests X tiling, and the
kms_frontbuffer_tracking/fbc-tilingchange will need to be updated.

> . In the meantime lets hope that all
> framebuffers are idle and naturally fit within the mappable aperture.

What exactly do you mean with the sentence above? Is there some other
bug you spotted? Please share the information.

> 
> Requested-by: Paulo Zanoni 
> Fixes: 8678fdaf396c ("drm/i915/fbc: Allow on unfenced surfaces...");
> Cc: Paulo Zanoni 
> ---
>  drivers/gpu/drm/i915/intel_fbc.c | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_fbc.c
> b/drivers/gpu/drm/i915/intel_fbc.c
> index bf8b22ad9aed..faa67624e1ed 100644
> --- a/drivers/gpu/drm/i915/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/intel_fbc.c
> @@ -799,10 +799,8 @@ static bool intel_fbc_can_activate(struct
> intel_crtc *crtc)
>    */
>   if (cache->fb.tiling_mode != I915_TILING_X ||
>   cache->fb.fence_reg == I915_FENCE_REG_NONE) {
> - if (INTEL_GEN(dev_priv) < 5) {
> - fbc->no_fbc_reason = "framebuffer not tiled
> or fenced";
> - return false;
> - }
> + fbc->no_fbc_reason = "framebuffer not tiled or
> fenced";
> + return false;
>   }
>   if (INTEL_INFO(dev_priv)->gen <= 4 && !IS_G4X(dev_priv) &&
>   cache->plane.rotation != DRM_ROTATE_0) {
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/7] drm/i915/hsw+: set intel_crtc active once pipe is active

[Zanoni, Paulo R]

Em Seg, 2016-08-29 às 18:05 +0530, Kumar, Mahesh escreveu:
> Set the intel_crtc->active flag after pipe/crtc is actually active in
> haswell_crtc_enable function.

Why?

Can you please elaborate more on why this change is needed, what are
the benefits it brings, what are the problems it solves and why is the
current code bad or wrong? Please explain all this in the commit
message, not just as an email reply.

In other words: if I'm bisecting a theoretical bug and then suddenly
conclude that this patch is the problem, how will I know what's going
to break once I revert this patch?

Thanks,
Paulo

> 
> Signed-off-by: Kumar, Mahesh 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index e4e6141..7258883 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -5427,8 +5427,6 @@ static void haswell_crtc_enable(struct
> intel_crtc_state *pipe_config,
>  
>   intel_color_set_csc(&pipe_config->base);
>  
> - intel_crtc->active = true;
> -
>   if (intel_crtc->config->has_pch_encoder)
>   intel_set_cpu_fifo_underrun_reporting(dev_priv,
> pipe, false);
>   else
> @@ -5475,6 +5473,8 @@ static void haswell_crtc_enable(struct
> intel_crtc_state *pipe_config,
>   assert_vblank_disabled(crtc);
>   drm_crtc_vblank_on(crtc);
>  
> + intel_crtc->active = true;
> +
>   intel_encoders_enable(crtc, pipe_config, old_state);
>  
>   if (intel_crtc->config->has_pch_encoder) {
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] FOR_UPSTREAM [VPG]: drm/i915/skl+: Implement Transition WM

[Zanoni, Paulo R]

Hi

Em Seg, 2016-08-29 às 18:05 +0530, Kumar, Mahesh escreveu:
> This patch enables Transition WM for SKL+ platforms.
> 
> Transition WM are used if IPC is enabled, to decide, number of blocks
> to be fetched before reducing the priority of display to fetch from
> memory.
> 
> Signed-off-by: Kumar, Mahesh 
> ---
>  drivers/gpu/drm/i915/intel_pm.c | 57
> ++---
>  1 file changed, 53 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c
> b/drivers/gpu/drm/i915/intel_pm.c
> index 9f69050..f4f387f 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -2861,6 +2861,8 @@ bool ilk_disable_lp_wm(struct drm_device *dev)
>  #define SKL_DDB_SIZE 896 /* in blocks */
>  #define BXT_DDB_SIZE 512
>  #define SKL_SAGV_BLOCK_TIME  30 /* µs */
> +#define SKL_TRANS_WM_AMOUNT  10
> +#define SKL_TRANS_WM_MIN 14

As far as I understood (and maybe I'm wrong), SKL_TRANS_WM_AMOUNT is a
tunable value, so it depends on a lot of variable factors. Why does
this patch use 10 instead of every other possible value?

Thanks,
Paulo


>  
>  /*
>   * Return the index of a plane in the SKL DDB and wm result
> arrays.  Primary
> @@ -3579,6 +3581,41 @@ static uint32_t
> skl_adjusted_plane_pixel_rate(const struct intel_crtc_state *cst
>   return pixel_rate;
>  }
>  
> +static void skl_compute_plane_trans_wm(const struct drm_i915_private
> *dev_priv,
> + struct skl_pipe_wm *pipe_wm,
> + struct intel_plane_state
> *intel_pstate,
> + uint32_t y_tile_min,
> + bool y_tile)
> +{
> + struct drm_plane_state *pstate = &intel_pstate->base;
> + int id = skl_wm_plane_id(to_intel_plane(pstate->plane));
> + uint16_t *out_blocks = &pipe_wm->trans_wm.plane_res_b[id];
> + uint8_t *out_lines = &pipe_wm->trans_wm.plane_res_l[id];
> + uint16_t res_blocks = pipe_wm->wm[0].plane_res_b[id];
> + uint32_t trans_min = 0, trans_offset_blocks;
> + uint16_t trans_y_tile_min = 0;
> + uint16_t trans_res_blocks;
> +
> +
> + if (IS_GEN9(dev_priv))
> + trans_min = SKL_TRANS_WM_MIN;
> +
> + trans_offset_blocks = trans_min + SKL_TRANS_WM_AMOUNT;
> +
> + if (y_tile) {
> + trans_y_tile_min = 2 * y_tile_min;
> + trans_res_blocks = max(trans_y_tile_min, res_blocks)
> +
> + trans_offset_blocks;
> + } else {
> + trans_res_blocks = res_blocks + trans_offset_blocks;
> + /* WA BUG:1938466 add one block for non y-tile
> planes */
> + trans_res_blocks += 1;
> + }
> +
> + *out_blocks = trans_res_blocks;
> + *out_lines = 0;
> +}
> +
>  static int skl_compute_plane_wm(const struct drm_i915_private
> *dev_priv,
>   struct intel_crtc_state *cstate,
>   struct intel_plane_state
> *intel_pstate,
> @@ -3600,6 +3637,8 @@ static int skl_compute_plane_wm(const struct
> drm_i915_private *dev_priv,
>   struct skl_wm_level *result = &pipe_wm->wm[level];
>   uint16_t *out_blocks = &result->plane_res_b[id];
>   uint8_t *out_lines = &result->plane_res_l[id];
> + uint32_t y_tile_minimum = 0;
> + bool y_tile = false;
>  
>   if (latency == 0 || !cstate->base.active || !intel_pstate-
> >base.visible)
>   return 0;
> @@ -3627,7 +3666,6 @@ static int skl_compute_plane_wm(const struct
> drm_i915_private *dev_priv,
>   if (fb->modifier[0] == I915_FORMAT_MOD_Y_TILED ||
>   fb->modifier[0] == I915_FORMAT_MOD_Yf_TILED) {
>   uint32_t min_scanlines = 4;
> - uint32_t y_tile_minimum;
>   if (intel_rotation_90_or_270(pstate->rotation)) {
>   int cpp = (fb->pixel_format ==
> DRM_FORMAT_NV12) ?
>   drm_format_plane_cpp(fb-
> >pixel_format, 1) :
> @@ -3646,6 +3684,7 @@ static int skl_compute_plane_wm(const struct
> drm_i915_private *dev_priv,
>   }
>   y_tile_minimum = plane_blocks_per_line *
> min_scanlines;
>   selected_result = max(method2, y_tile_minimum);
> + y_tile = true;
>   } else {
>   linetime_us = DIV_ROUND_UP(width * 1000,
>   skl_pipe_pixel_rate(cstate));
> @@ -3669,6 +3708,9 @@ static int skl_compute_plane_wm(const struct
> drm_i915_private *dev_priv,
>   *out_blocks = res_blocks;
>   *out_lines = res_lines;
>  
> + if (level == 0)
> + skl_compute_plane_trans_wm(dev_priv, pipe_wm,
> intel_pstate,
> + y_tile_minimum,
> y_tile);
>   return 0;
>  }
>  
> @@ -3738,11 +3780,13 @@ skl_compute_linetime_wm(struct
> intel_crtc_state *cstate)
>  }
>  
>  static void skl_compute_transition_wm(struct intel_crtc_state
> *cstate,
> -  

Re: [Intel-gfx] [PATCH] FOR_UPSTREAM [VPG]: drm/i915/skl+: Implement Transition WM

[Zanoni, Paulo R]

Em Ter, 2016-08-30 às 19:32 +, Zanoni, Paulo R escreveu:
> Hi
> 
> Em Seg, 2016-08-29 às 18:05 +0530, Kumar, Mahesh escreveu:
> > 
> > This patch enables Transition WM for SKL+ platforms.
> > 
> > Transition WM are used if IPC is enabled, to decide, number of
> > blocks
> > to be fetched before reducing the priority of display to fetch from
> > memory.
> > 
> > Signed-off-by: Kumar, Mahesh 
> > ---
> >  drivers/gpu/drm/i915/intel_pm.c | 57
> > ++---
> >  1 file changed, 53 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index 9f69050..f4f387f 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -2861,6 +2861,8 @@ bool ilk_disable_lp_wm(struct drm_device
> > *dev)
> >  #define SKL_DDB_SIZE   896 /* in blocks */
> >  #define BXT_DDB_SIZE   512
> >  #define SKL_SAGV_BLOCK_TIME30 /* µs */
> > +#define SKL_TRANS_WM_AMOUNT10
> > +#define SKL_TRANS_WM_MIN   14
> 
> As far as I understood (and maybe I'm wrong), SKL_TRANS_WM_AMOUNT is
> a
> tunable value, so it depends on a lot of variable factors. Why does
> this patch use 10 instead of every other possible value?

I kept investigating and it seems that the current recommendation is
still that transition watermarks stay disabled for SKL and KBL.

> 
> Thanks,
> Paulo
> 
> 
> > 
> >  
> >  /*
> >   * Return the index of a plane in the SKL DDB and wm result
> > arrays.  Primary
> > @@ -3579,6 +3581,41 @@ static uint32_t
> > skl_adjusted_plane_pixel_rate(const struct intel_crtc_state *cst
> >     return pixel_rate;
> >  }
> >  
> > +static void skl_compute_plane_trans_wm(const struct
> > drm_i915_private
> > *dev_priv,
> > +   struct skl_pipe_wm
> > *pipe_wm,
> > +   struct intel_plane_state
> > *intel_pstate,
> > +   uint32_t y_tile_min,
> > +   bool y_tile)
> > +{
> > +   struct drm_plane_state *pstate = &intel_pstate->base;
> > +   int id = skl_wm_plane_id(to_intel_plane(pstate->plane));
> > +   uint16_t *out_blocks = &pipe_wm->trans_wm.plane_res_b[id];
> > +   uint8_t *out_lines = &pipe_wm->trans_wm.plane_res_l[id];
> > +   uint16_t res_blocks = pipe_wm->wm[0].plane_res_b[id];
> > +   uint32_t trans_min = 0, trans_offset_blocks;
> > +   uint16_t trans_y_tile_min = 0;
> > +   uint16_t trans_res_blocks;
> > +
> > +
> > +   if (IS_GEN9(dev_priv))
> > +   trans_min = SKL_TRANS_WM_MIN;
> > +
> > +   trans_offset_blocks = trans_min + SKL_TRANS_WM_AMOUNT;
> > +
> > +   if (y_tile) {
> > +   trans_y_tile_min = 2 * y_tile_min;
> > +   trans_res_blocks = max(trans_y_tile_min,
> > res_blocks)
> > +
> > +   trans_offset_blocks;
> > +   } else {
> > +   trans_res_blocks = res_blocks +
> > trans_offset_blocks;
> > +   /* WA BUG:1938466 add one block for non y-tile
> > planes */
> > +   trans_res_blocks += 1;
> > +   }
> > +
> > +   *out_blocks = trans_res_blocks;
> > +   *out_lines = 0;
> > +}
> > +
> >  static int skl_compute_plane_wm(const struct drm_i915_private
> > *dev_priv,
> >     struct intel_crtc_state *cstate,
> >     struct intel_plane_state
> > *intel_pstate,
> > @@ -3600,6 +3637,8 @@ static int skl_compute_plane_wm(const struct
> > drm_i915_private *dev_priv,
> >     struct skl_wm_level *result = &pipe_wm->wm[level];
> >     uint16_t *out_blocks = &result->plane_res_b[id];
> >     uint8_t *out_lines = &result->plane_res_l[id];
> > +   uint32_t y_tile_minimum = 0;
> > +   bool y_tile = false;
> >  
> >     if (latency == 0 || !cstate->base.active || !intel_pstate-
> > > 
> > > base.visible)
> >     return 0;
> > @@ -3627,7 +3666,6 @@ static int skl_compute_plane_wm(const struct
> > drm_i915_private *dev_priv,
> >     if (fb->modifier[0] == I915_FORMAT_MOD_Y_TILED ||
> >     fb->modifier[0] == I915_FORMAT_MOD_Yf_TILED) {
> >     uint32_t min_scanlines = 4;
> > -   uint32_t y_tile_minimum;
> >     if (intel_rotation_90_or_270(pstate->rotation)) {
> >     

Re: [Intel-gfx] Skylake graphics regression: projector failure with 4.8-rc3

[Zanoni, Paulo R]

Hi

Em Qua, 2016-08-31 às 14:43 -0700, James Bottomley escreveu:
> On Wed, 2016-08-31 at 11:23 -0700, James Bottomley wrote:
> > 
> > On Fri, 2016-08-26 at 09:10 -0400, James Bottomley wrote:
> > > 
> > > We seem to have an xrandr regression with skylake now.  What's
> > > happening is that I can get output on to a projector, but the 
> > > system is losing video when I change the xrandr sessions (like 
> > > going from a --above b to a --same-as b).  The main screen goes 
> > > blank, which is basically a reboot situation.  Unfortunately, I 
> > > can't seem to get the logs out of systemd to see if there was a 
> > > dump to dmesg (the system was definitely responding).
> > > 
> > > I fell back to 4.6.2 which worked perfectly, so this is
> > > definitely 
> > > some sort of regression.  I'll be able to debug more fully when
> > > I 
> > > get back home from the Linux Security Summit.
> > 
> > I'm home now.  Unfortunately, my monitor isn't as problematic as
> > the
> > projector, but by flipping between various modes and separating and
> > overlaying the panels with --above and --same-as (xrandr), I can
> > eventually get it to the point where the main LCD panel goes black 
> > and can only be restarted by specifying a different mode.
> > 
> > This seems to be associated with these lines in the X
> > 
> > [ 14714.389] (EE) intel(0): failed to set mode: Invalid argument
> > [22]
> > 
> > But the curious thing is that even if this fails with the error 
> > message once, it may succeed a second time, so it looks to be a 
> > transient error translation problem from the kernel driver.
> > 
> > I've attached the full log below.
> > 
> > This is only with a VGA output.  I currently don't have a HDMI 
> > dongle, but I'm in the process of acquiring one.
> 
> After more playing around, I'm getting thousands of these in the
> kernel
> log (possibly millions: the log wraps very fast):
> 
> [23504.873606] [drm:intel_dp_start_link_train [i915]] *ERROR* failed
> to train DP, aborting
> 
> And then finally it gives up with 
> 
> [25023.770951] [drm:intel_cpu_fifo_underrun_irq_handler [i915]]
> *ERROR* CPU pipe B FIFO underrun
> [25561.926075] [drm:intel_cpu_fifo_underrun_irq_handler [i915]]
> *ERROR* CPU pipe A FIFO underrun
> 
> And the crtc for the VGA output becomes non-responsive to any
> configuration command.  This requires a reboot and sometimes a UEFI
> variable reset before it comes back.

Please see this discussion:
https://patchwork.freedesktop.org/patch/103237/

Do you have this patch on your tree? Does the problem go away if you
revert it?

Thanks,
Paulo

> 
> James
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] FOR_UPSTREAM [VPG]: drm/i915/skl+: Implement Transition WM

[Zanoni, Paulo R]

Em Sex, 2016-09-02 às 17:16 +0530, Mahesh Kumar escreveu:
> Hi,
> 
> On Wednesday 31 August 2016 07:17 PM, Zanoni, Paulo R wrote:
> > 
> > Em Ter, 2016-08-30 às 19:32 +, Zanoni, Paulo R escreveu:
> > > 
> > > Hi
> > > 
> > > Em Seg, 2016-08-29 às 18:05 +0530, Kumar, Mahesh escreveu:
> > > > 
> > > > This patch enables Transition WM for SKL+ platforms.
> > > > 
> > > > Transition WM are used if IPC is enabled, to decide, number of
> > > > blocks
> > > > to be fetched before reducing the priority of display to fetch
> > > > from
> > > > memory.
> > > > 
> > > > Signed-off-by: Kumar, Mahesh 
> > > > ---
> > > >   drivers/gpu/drm/i915/intel_pm.c | 57
> > > > ++---
> > > >   1 file changed, 53 insertions(+), 4 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > > > b/drivers/gpu/drm/i915/intel_pm.c
> > > > index 9f69050..f4f387f 100644
> > > > --- a/drivers/gpu/drm/i915/intel_pm.c
> > > > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > > > @@ -2861,6 +2861,8 @@ bool ilk_disable_lp_wm(struct drm_device
> > > > *dev)
> > > >   #define SKL_DDB_SIZE  896 /* in blocks
> > > > */
> > > >   #define BXT_DDB_SIZE  512
> > > >   #define SKL_SAGV_BLOCK_TIME   30 /* µs */
> > > > +#define SKL_TRANS_WM_AMOUNT10
> > > > +#define SKL_TRANS_WM_MIN   14
> > > As far as I understood (and maybe I'm wrong), SKL_TRANS_WM_AMOUNT
> > > is
> > > a
> > > tunable value, so it depends on a lot of variable factors. Why
> > > does
> > > this patch use 10 instead of every other possible value?
> This value 10 was driven by experiments in other OS with the help of
> SV 
> team.
> I'm trying to get more information regarding this from HW/SV team.
> we can update this value later if required, what is your thought on
> this?
> > 
> > I kept investigating and it seems that the current recommendation
> > is
> > still that transition watermarks stay disabled for SKL and KBL.
> 
> My earlier impression from Bspec was transition WM's should be
> disabled 
> in SKL A/B stepping only. But from the latest discussion with HW
> team,
> it seems transition WM must be disabled for all SKL stepping.
> SV team recommendation is, It should be enabled with IPC for BXT/APL 
> systems, So will update the patch with IS_BXT() check.

BSpec says transition watermarks should be disabled for GEN9:ALL.

Arthur, can you please comment on this?

> 
> thanks,
> 
> Regards,
> -Mahesh
> > 
> > 
> > > 
> > > Thanks,
> > > Paulo
> > > 
> > > 
> > > > 
> > > >   
> > > >   /*
> > > >    * Return the index of a plane in the SKL DDB and wm result
> > > > arrays.  Primary
> > > > @@ -3579,6 +3581,41 @@ static uint32_t
> > > > skl_adjusted_plane_pixel_rate(const struct intel_crtc_state
> > > > *cst
> > > >     return pixel_rate;
> > > >   }
> > > >   
> > > > +static void skl_compute_plane_trans_wm(const struct
> > > > drm_i915_private
> > > > *dev_priv,
> > > > +   struct skl_pipe_wm
> > > > *pipe_wm,
> > > > +   struct
> > > > intel_plane_state
> > > > *intel_pstate,
> > > > +   uint32_t y_tile_min,
> > > > +   bool y_tile)
> > > > +{
> > > > +   struct drm_plane_state *pstate = &intel_pstate->base;
> > > > +   int id = skl_wm_plane_id(to_intel_plane(pstate-
> > > > >plane));
> > > > +   uint16_t *out_blocks = &pipe_wm-
> > > > >trans_wm.plane_res_b[id];
> > > > +   uint8_t *out_lines = &pipe_wm-
> > > > >trans_wm.plane_res_l[id];
> > > > +   uint16_t res_blocks = pipe_wm->wm[0].plane_res_b[id];
> > > > +   uint32_t trans_min = 0, trans_offset_blocks;
> > > > +   uint16_t trans_y_tile_min = 0;
> > > > +   uint16_t trans_res_blocks;
> > > > +
> > > > +
> > > > +   if (IS_GEN9(dev_priv))
> > > > +   trans_min = SKL_TRANS_WM_MIN;
> >

Re: [Intel-gfx] [PATCH] drm/i915/fbc: disable FBC on FIFO underruns

[Zanoni, Paulo R]

Em Sex, 2016-09-02 às 05:58 +, Pandiyan, Dhinakaran escreveu:
> On Mon, 2016-08-15 at 19:36 -0300, Paulo Zanoni wrote:
> > 
> > Ever since I started working on FBC I was already aware that FBC
> > can
> > really amplify the FIFO underrun symptoms. On systems where FIFO
> > underruns were harmless error messages, enabling FBC would cause
> > the
> > underruns to give black screens.
> > 
> > We recently tried to enable FBC on Haswell and got reports of a
> > system
> > that would hang after some hours of uptime, and the first bad
> > commit
> > was the one that enabled FBC. We also observed that this system had
> > FIFO underrun error messages on its dmesg. Although we don't have
> > any
> > evidence that fixing the underruns would solve the bug and make FBC
> > work properly on this machine, IMHO it's better if we minimize the
> > amount of possible problems by just giving up FBC whenever we
> > detect
> > an underrun.
> > 
> > v2: New version, different implementation and commit message.
> > v3: Clarify the fact that we run from an IRQ handler (Chris).
> > 
> > Cc: Stefan Richter 
> > Cc: Lyude 
> > Cc: stevenhoney...@gmail.com 
> > Signed-off-by: Paulo Zanoni 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.h|  3 ++
> >  drivers/gpu/drm/i915/intel_drv.h   |  1 +
> >  drivers/gpu/drm/i915/intel_fbc.c   | 61
> > ++
> >  drivers/gpu/drm/i915/intel_fifo_underrun.c |  2 +
> >  4 files changed, 67 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 35caa9b..baa9c66 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -941,6 +941,9 @@ struct intel_fbc {
> >     bool enabled;
> >     bool active;
> >  
> > +   bool underrun_detected;
> > +   struct work_struct underrun_work;
> > +
> >     struct intel_fbc_state_cache {
> >     struct {
> >     unsigned int mode_flags;
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index 1c700b0..50c1eb0 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -1494,6 +1494,7 @@ void intel_fbc_invalidate(struct
> > drm_i915_private *dev_priv,
> >  void intel_fbc_flush(struct drm_i915_private *dev_priv,
> >      unsigned int frontbuffer_bits, enum
> > fb_op_origin origin);
> >  void intel_fbc_cleanup_cfb(struct drm_i915_private *dev_priv);
> > +void intel_fbc_handle_fifo_underrun_irq(struct drm_i915_private
> > *dev_priv);
> >  
> >  /* intel_hdmi.c */
> >  void intel_hdmi_init(struct drm_device *dev, i915_reg_t hdmi_reg,
> > enum port port);
> > diff --git a/drivers/gpu/drm/i915/intel_fbc.c
> > b/drivers/gpu/drm/i915/intel_fbc.c
> > index e122052..950aed5 100644
> > --- a/drivers/gpu/drm/i915/intel_fbc.c
> > +++ b/drivers/gpu/drm/i915/intel_fbc.c
> > @@ -750,6 +750,13 @@ static bool intel_fbc_can_activate(struct
> > intel_crtc *crtc)
> >     struct intel_fbc *fbc = &dev_priv->fbc;
> >     struct intel_fbc_state_cache *cache = &fbc->state_cache;
> >  
> > +   /* We don't need to use a state cache here since this
> > information is
> > +    * global for every CRTC. */
> > +   if (fbc->underrun_detected) {
> > +   fbc->no_fbc_reason = "underrun detected";
> > +   return false;
> > +   }
> > +
> >     if (!cache->plane.visible) {
> >     fbc->no_fbc_reason = "primary plane not visible";
> >     return false;
> > @@ -1193,6 +1200,59 @@ void intel_fbc_global_disable(struct
> > drm_i915_private *dev_priv)
> >     cancel_work_sync(&fbc->work.work);
> >  }
> >  
> > +static void intel_fbc_underrun_work_fn(struct work_struct *work)
> > +{
> > +   struct drm_i915_private *dev_priv =
> > +   container_of(work, struct drm_i915_private,
> > fbc.underrun_work);
> > +   struct intel_fbc *fbc = &dev_priv->fbc;
> > +
> > +   mutex_lock(&fbc->lock);
> > +
> > +   /* Maybe we were scheduled twice. */
> > +   if (fbc->underrun_detected)
> > +   goto out;
> 
> If the underrun happens very early after boot (likely during
> modeset),
> the user might end up seeing just FBC enable and disable messages in
> dmesg without knowing it (or why it) was deactivated.
> 
> For e.g.,
> 
> [ 1855.552489] [drm:intel_fbc_enable] Enabling FBC on pipe A
> [ 1856.854239] [drm:__intel_fbc_disable] Disabling FBC on pipe A
> [ 1857.753383] [drm:intel_fbc_alloc_cfb] Reducing the compressed
> framebuffer size. This may lead to less power savings than a
> non-reduced-size. Try to increase stolen memory size if available in
> BIOS.
> [ 1857.753384] [drm:intel_fbc_alloc_cfb] reserved 10368000 bytes of
> contiguous stolen space for FBC, threshold: 4
> [ 1857.753384] [drm:intel_fbc_enable] Enabling FBC on pipe A
> 
> I find this noise misleading because FBC is not going to be activated
> at
> all.

You have a point here, good catch. I was trying to avoid having two
checks (one for enabling, one for a

Re: [Intel-gfx] [PATCH RESEND i-g-t 1/2] tests/kms_frontbuffer_tracking: Skip if CRTC not selected

[Zanoni, Paulo R]

Em Qua, 2017-04-26 às 15:40 -0300, Gabriel Krisman Bertazi escreveu:
> Paulo Zanoni  writes:
> 
> > 
> > Em Qui, 2017-04-20 às 11:11 -0300, Gabriel Krisman Bertazi
> > escreveu:
> > > 
> > > After Linux commit f7e9b004b8a3 ("drm/i915/fbc: inline
> > > intel_fbc_can_choose()"), no_fbc_reason will be updated to a new
> > > error
> > > message if we don't have a plane in the new state, which should
> > > make
> > > the
> > > test skip, but the test code doesn't catch that message and tries
> > > to
> > 
> > What was the previous message that was making the test skip? I was
> > not
> > expecting that patch would affect kms_frontbuffer_tracking
> > behavior.
> 
> The previous message was "FBC disabled: not enough stolen
> memory".  You
> got me wondering if we should even enter that function if
> intel_fbc_alloc_cfb failed.  The patch I mentioned starts triggering
> the
> failure because it changes the error message even if we never enter
> the
> for_each_new_plane_in_state loop in intel_fbc_choose_crtc.
> 
> Does that makes sense?  Let me take another look at the code and see
> what I can come up with.

I think I understand the problem now. My problem with the current
approach is that it changes the kms_frontbuffer_tracking behavior for
more cases than the one affected by this bug, so there's a risk we're
going to end up skipping when we should really be failing. Any case
where we end up not finding a suitable CRTC will be skipped, instead of
only skipping where we can't find a suitable CRTC due to not having
enough stolen memory.

I was already planning on maybe switching opt.small_modes to default as
true. This should help not only on cases where there's not enough
stolen memory, but also on cases where the monitor resolution is too
big for FBC. This would fix the bug.

The reason why I still didn't switch opt.small_modes to true by default
is because I didn't check if doing this will introduce any other
unintended regressions. It shouldn't, but we'll never know until we
actually try. Maybe we should check this with the CI team.

For our CI machines specifically, I think we should also consider just
going to their BIOSes and increasing the amount of stolen memory. We
really want to try to minimize the amount of SKIPs in cases where we
could be testing stuff, so increasing the amount of stolen memory
really sounds the ideal solution for CI.

So 3 possible solutions (and maybe we should do them all):

- Switch opt.small_modes to true by default, and check if this exposes
new problems.
- Increase the amount of stolen memory for CI machines.
- Somehow go back to the previous behavior where the Kernel tells us
that it tried to enable FBC but there's not enough stolen memory.

Thanks,
Paulo

> 
> 
> > 
> > 
> > > 
> > > execute the test, triggering a test failure.
> > 
> > Anyway, I'm trying to understand the situation here. I'm not sure
> > if
> > this fix is correct, I'm wondering if it's a problem in how the
> > Kernel
> > sets the messages. Please explain in more details why this patch
> > does
> > what it does.
> > 
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Screen update issue (drm/i915/fbc: enable FBC by default on HSW and BDW)

[Zanoni, Paulo R]

Em Qua, 2016-06-08 às 22:35 +0100, Steven Honeyman escreveu:
> Hi,

Hi

CC'ing the mailing list.

> 
> With commit a98ee79317b4091cafb502b4ffdbbbe1335e298c to enable FBC by
> default, I get a strange issue with screen update/refresh (sorry if
> my
> terminology is off - I'm not a graphics dev!).
> Here's how it went (all in the past few hours):
> 
> Kernel 4.5.5 (before the patch) - everything OK.
> Kernel 4.6.2 - In a terminal window (openbox+roxterm or tilda, if
> that
> matters), the screen only updated approx 1 or 2 times per second when
> typing (e.g. hold a key and they appear in chunks of 15-20!). Holding
> a key and moving the mouse, appears fine.
> Kernel 4.6.1 - (same as 4.6.2, but I had to try)
> Kernel 4.7-rc2 - Same refresh/update problem, but this time moving
> the
> mouse had no effect.
> Spent 5 mins googling, found your patch, applied i915.enable_fbc=0
> and
> 4.7-rc2 behaves as it should.
> 
> So in response to your suggestions for debugging this made in the
> commit message, I swapped out the boot parameter for drm.debug=0xe,
> but apart from the stuff at startup I got nothing extra after
> reproducing the problem.
> Your suggestions make it sound like you might expect something
> 'major'
> to go wrong, infrequently... however this is always apparent, and
> (fairly) minor.
> 
> Hardware is a Dell E6540, Haswell i5 with Intel graphics. FHD eDP
> panel + external FHD DVI screen.
> Please let me know if there's any other info you want.

Please boot with i915.enable_fbc=1 drm.debug=0xe, reproduce the problem
and check if there is any dmesg line mentioning "FIFO underruns".

Also, which distro version are you using? Are you using xf86-video-
intel? Maybe also grab /var/log/Xorg.0.log.

Perhaps it would be better if you open a bug on bugs.freedesktop.org,
attach the relevant information, and provide me the link to the bug
report. It's better to track bugs there.

Anyway, I should submit a patch reverting FBC on stable Kernels.

Thanks,
Paulo

> 
> 
> Thanks,
> Steven
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] i915/fbc: Disable on HSW by default for now

[Zanoni, Paulo R]

Em Qui, 2016-06-09 às 11:58 -0400, Lyude escreveu:
> From https://bugs.freedesktop.org/show_bug.cgi?id=96461 :
> 
> This was kind of a difficult bug to track down. If you're using a
> Haswell system running GNOME and you have fbc completely enabled and
> working, playing videos can result in video artifacts. Steps to
> reproduce:
> 
> - Run GNOME
> - Ensure FBC is enabled and active
> - Download a movie, I used the ogg version of Big Buck Bunny for this
> - Run `gst-launch-1.0 filesrc location='some_movie.ogg' ! decodebin !
>   glimagesink` in a terminal
> - Watch for about over a minute, you'll see small horizontal lines go
>   down the screen.

If you "dmesg | grep -i underrun", do you see anything (even if it
doesn't happen during the moments of corruption)?

Does the problem still happen if you apply these patches?
 - https://patchwork.freedesktop.org/patch/79567/
 - https://patchwork.freedesktop.org/patch/80857/
 - https://patchwork.freedesktop.org/patch/92634/

> 
> For the time being, disable FBC for Haswell by default.

In case we want to improve the commit message:

We also got reports from Steven Honeyman on openbox+roxterm, and from
Stefan Richter.

Anyway, there's a regression that needs to be fixed, so:

Reviewed-by: Paulo Zanoni 

We can always try again later.

> 
> Signed-off-by: Lyude 
> Cc: sta...@vger.kernel.org
> ---
>  drivers/gpu/drm/i915/intel_fbc.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_fbc.c
> b/drivers/gpu/drm/i915/intel_fbc.c
> index 0f0492f..28f4407 100644
> --- a/drivers/gpu/drm/i915/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/intel_fbc.c
> @@ -823,8 +823,7 @@ static bool intel_fbc_can_choose(struct
> intel_crtc *crtc)
>  {
>   struct drm_i915_private *dev_priv = crtc->base.dev-
> >dev_private;
>   struct intel_fbc *fbc = &dev_priv->fbc;
> - bool enable_by_default = IS_HASWELL(dev_priv) ||
> -  IS_BROADWELL(dev_priv);
> + bool enable_by_default = IS_BROADWELL(dev_priv);
>  
>   if (intel_vgpu_active(dev_priv->dev)) {
>   fbc->no_fbc_reason = "VGPU is active";
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/fbc: disable FBC on FIFO underruns

[Zanoni, Paulo R]

Em Seg, 2016-06-13 às 13:47 +0200, Stefan Richter escreveu:
> On Jun 10 Paulo Zanoni wrote:
> > 
> > Since my test machines don't produce FIFO underrun errors, I tested
> > this by
> > creating a debugfs file that just calls
> > intel_fbc_handle_fifo_underrun(). I'd
> > appreciate some Tested-by tags, if possible.
> Since May 8 I have been using 4.6.0-rc6 patched with
> drm-intel-nightly_2016y-05m-06d-14h-29m-58s (from what I understand,
> something close to what is now in mainline), and fbc disabled on the
> kernel commandline.  I have not rebooted since May 8.

Ok, so you're saying that if you boot this Kernel with i915.fbc=1, you
won't get any FIFO underrun messages, but the system is still going to
freeze somehow?

If that's the case, then this patch won't help.

> 
> For that kernel, i915.enable_fbc=0 is both required and sufficient to
> prevent freezes at random points in time (as reported).  The
> drm-intel-nightly_2016y-05m-06d-14h-29m-58s patch on the other hand
> has the
> effect that there are never any FIFO underruns logged anymore.
> 
> If there are no FIFO underruns reported in dmesg, your underrun
> detection routine would never hit, would it?

You're right, there's no need to test on this case.

> 
> If you nevertheless think it's worth trying, should I test it on top
> of
> 4.7-rc3 or on current drm-intel-nightly?
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/fbc: FBC causes display flicker when VT-d is enabled on Skylake

[Zanoni, Paulo R]

Em Sex, 2016-06-17 às 17:39 +0100, Chris Wilson escreveu:
> Erratum SKL075: Display Flicker May Occur When Both VT-d And FBC Are
> Enabled
> 
> "Display flickering may occur when both FBC (Frame Buffer
> Compression)
> and VT - d (Intel® Virtualization Technology for Directed I/O) are
> enabled
> and in use by the display controller."

Ouch...

> 
> Signed-off-by: Chris Wilson 
> Cc: Paulo Zanoni 
> ---
>  drivers/gpu/drm/i915/intel_fbc.c | 18 ++
>  1 file changed, 18 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_fbc.c
> b/drivers/gpu/drm/i915/intel_fbc.c
> index fddba1eed5ad..e47785467220 100644
> --- a/drivers/gpu/drm/i915/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/intel_fbc.c
> @@ -1230,6 +1230,18 @@ void intel_fbc_init_pipe_state(struct
> drm_i915_private *dev_priv)
>   dev_priv->fbc.visible_pipes_mask |= (1 <<
> crtc->pipe);
>  }
>  
> +static bool need_vtd_wa(struct drm_i915_private *dev_priv)

Notice we have a function with the exact same name in intel_display.c.

> +{
> +#ifdef CONFIG_INTEL_IOMMU
> + if (!intel_iommu_gfx_mapped)
> + return false;
> +
> + if (INTEL_GEN(dev_priv) == 9)
> + return true;
> +#endif
> + return false;
> +}
> +
>  /**
>   * intel_fbc_init - Initialize FBC
>   * @dev_priv: the i915 device
> @@ -1247,6 +1259,12 @@ void intel_fbc_init(struct drm_i915_private
> *dev_priv)
>   fbc->active = false;
>   fbc->work.scheduled = false;
>  
> + if (need_vtd_wa(dev_priv)) {
> + struct intel_device_info *info =
> + (struct intel_device_info *)&dev_priv->info;
> + info->has_fbc = false;
> + }

I just find this piece above a little not-so-beautiful and possibly
confusing for people debugging failures and/or IGT. Alternatives:

1 - Move the check to intel_fbc_can_choose(), so we can give a nice
no_fbc_reason. Problem: this would not be as efficient as what you
wrote.

2 - Move the check to intel_sanitize_fbc_option(), which is reviewed
but not merged yet. Problem: same as 1.

3 - Patch fbc_supported() and make the line below call fbc_supported()
instead of HAS_FBC(). Problem: we call it many times.

4 - Create dev_priv->fbc.is_supported (or some other meaningful name),
set it at init time, and make fbc_supported() use it (or just replace
fbc_supported() calls with the variable check).

All solutions above would probably require some adjustments to debugfs
and/or IGT (which relies on debugfs), but at least they wouldn't
surprise users or IGT runners with "why does it say SKL is not
supported by FBC?".

> +
>   if (!HAS_FBC(dev_priv)) {
>   fbc->no_fbc_reason = "unsupported by this chipset";
>   return;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] i915/fbc: Disable on HSW by default for now

[Zanoni, Paulo R]

Em Sex, 2016-06-10 às 08:44 +0200, Stefan Richter escreveu:
> On Jun 09 Zanoni, Paulo R wrote:
> > 
> > Em Qui, 2016-06-09 às 11:58 -0400, Lyude escreveu:
> > > 
> > > From https://bugs.freedesktop.org/show_bug.cgi?id=96461 :
> > > 
> > > This was kind of a difficult bug to track down. If you're using a
> > > Haswell system running GNOME and you have fbc completely enabled
> > > and
> > > working, playing videos can result in video artifacts.
> [...]
> > 
> > > 
> > > For the time being, disable FBC for Haswell by default.  
> > In case we want to improve the commit message:
> > 
> > We also got reports from Steven Honeyman on openbox+roxterm, and
> > from
> > Stefan Richter.
> Perhaps also worth mentioning in the changelog:
> Stefan Richter reported kernel freezes (no video artifacts) when fbc
> is on.
> (E3-1245 v3 with HD P4600; openbox and some KDE and LXDE
> applications,
> thread begins at https://lkml.org/lkml/2016/4/26/813)

Patch merged with small additions to the commit message.

Thanks everybody involved,
Paulo

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3] drm/i915/fbc: FBC causes display flicker when VT-d is enabled on Skylake

[Zanoni, Paulo R]

Em Ter, 2016-06-21 às 08:25 +0100, Chris Wilson escreveu:
> Erratum SKL075: Display Flicker May Occur When Both VT-d And FBC Are
> Enabled
> 
> "Display flickering may occur when both FBC (Frame Buffer
> Compression)
> and VT - d (Intel® Virtualization Technology for Directed I/O) are
> enabled
> and in use by the display controller."
> 
> Ville found the w/a name in the database:
> WaFbcTurnOffFbcWhenHyperVisorIsUsed:skl
> 
> v2: Log when the quirk is applied.
> v3: Ensure i915.enable_fbc is false when !HAS_FBC()
> 
> Signed-off-by: Chris Wilson 
> Cc: Paulo Zanoni 
> Cc: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/i915_drv.h  |  2 ++
>  drivers/gpu/drm/i915/intel_fbc.c | 19 +++
>  2 files changed, 21 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> b/drivers/gpu/drm/i915/i915_drv.h
> index 89298d3ad94b..f1e9fd07d441 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2586,6 +2586,8 @@ struct drm_i915_cmd_table {
>  #define INTEL_GEN(p) (INTEL_INFO(p)->gen)
>  #define INTEL_DEVID(p)   (INTEL_INFO(p)->device_id)
>  
> +#define mkwrite_intel_info(p) ((struct intel_device_info
> *)INTEL_INFO(p))

So why don't we un-const struct intel_device_info?

> +
>  #define REVID_FOREVER0xff
>  #define INTEL_REVID(p)   (__I915__(p)->drm.pdev->revision)
>  
> diff --git a/drivers/gpu/drm/i915/intel_fbc.c
> b/drivers/gpu/drm/i915/intel_fbc.c
> index ac26aa8be9d0..fd5865d80bec 100644
> --- a/drivers/gpu/drm/i915/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/intel_fbc.c
> @@ -1238,12 +1238,28 @@ static int intel_sanitize_fbc_option(struct
> drm_i915_private *dev_priv)
>   if (i915.enable_fbc >= 0)
>   return !!i915.enable_fbc;
>  
> + if (!HAS_FBC(dev_priv))
> + return 0;
> +
>   if (IS_BROADWELL(dev_priv))
>   return 1;
>  
>   return 0;
>  }
>  
> +static bool need_fbc_wa(struct drm_i915_private *dev_priv)
> +{
> +#ifdef CONFIG_INTEL_IOMMU
> + /* WaFbcTurnOffFbcWhenHyperVisorIsUsed:skl */
> + if (intel_iommu_gfx_mapped 

The doc says: "Workaround: Disable FBC when VT-d superpage is used.".
My iommu-fu is not strong enough for me to be 100% sure that the
variable above corresponds to that. I'll just have to take your word
here.


> && IS_SKYLAKE(dev_priv)) {

The WA also applies to BXT, and pre-prod KBL, so I suppose at least a
check for BXT would be good.

> + DRM_INFO("Disabling framebuffer compression (FBC) to
> prevent screen flicker with VT-d enabled\n");
> + return true;
> + }
> +#endif
> +
> + return false;
> +}
> +
>  /**
>   * intel_fbc_init - Initialize FBC
>   * @dev_priv: the i915 device
> @@ -1261,6 +1277,9 @@ void intel_fbc_init(struct drm_i915_private
> *dev_priv)
>   fbc->active = false;
>   fbc->work.scheduled = false;
>  
> + if (need_fbc_wa(dev_priv))
> + mkwrite_intel_info(dev_priv)->has_fbc = false;
> +
>   i915.enable_fbc = intel_sanitize_fbc_option(dev_priv);
>   DRM_DEBUG_KMS("Sanitized enable_fbc value: %d\n",
> i915.enable_fbc);
>  
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3] drm/i915/fbc: FBC causes display flicker when VT-d is enabled on Skylake

[Zanoni, Paulo R]

Em Qua, 2016-06-22 às 21:34 +0100, Chris Wilson escreveu:
> On Tue, Jun 21, 2016 at 03:31:25PM +0200, Daniel Vetter wrote:
> > 
> > On Tue, Jun 21, 2016 at 08:25:27AM +0100, Chris Wilson wrote:
> > > 
> > > Erratum SKL075: Display Flicker May Occur When Both VT-d And FBC
> > > Are Enabled
> > > 
> > > "Display flickering may occur when both FBC (Frame Buffer
> > > Compression)
> > > and VT - d (Intel® Virtualization Technology for Directed I/O)
> > > are enabled
> > > and in use by the display controller."
> > > 
> > > Ville found the w/a name in the database:
> > > WaFbcTurnOffFbcWhenHyperVisorIsUsed:skl
> > > 
> > > v2: Log when the quirk is applied.
> > > v3: Ensure i915.enable_fbc is false when !HAS_FBC()
> > > 
> > > Signed-off-by: Chris Wilson 
> > > Cc: Paulo Zanoni 
> > > Cc: Ville Syrjälä 
> > Do we know whether this helps on other machines too? I can imagine
> > that
> > the additional lookup latency just plain wreaks havoc everywhere
> > ...
> Yeah, they do tend to play into fifo trouble. Could find anything
> though. But I think we have enough evidence to suggest acking this
> w/a
> and moving forward if we find any others...

From the HSD, it looks like this problem would lead to an underrun, so
the "disable FBC if we ever get an underrun" would at least help
diminish the damage in case the WA is actually valid for the previous
gens.

> -Chris
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [V2 PATCH 2/2] drm/i915: start adding dp mst audio

[Zanoni, Paulo R]

Em Qui, 2015-11-19 às 13:07 +0200, Ander Conselvan De Oliveira
escreveu:
> (Cc'ing Paulo for the audio power domain question)
> 
> On Wed, 2015-11-11 at 13:33 +0800, libin.y...@linux.intel.com wrote:
> > From: Libin Yang 
> > 
> > This patch adds support for DP MST audio in i915.
> > 
> > Enable audio codec when DP MST is enabled if has_audio flag is set.
> > Disable audio codec when DP MST is disabled if has_audio flag is
> > set.
> > 
> > Signed-off-by: Libin Yang 
> > Signed-off-by: Dave Airlie 
> > ---
> >  drivers/gpu/drm/i915/i915_debugfs.c | 14 ++
> >  drivers/gpu/drm/i915/intel_audio.c  |  9 ++---
> >  drivers/gpu/drm/i915/intel_dp_mst.c | 25 +
> >  3 files changed, 45 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> > b/drivers/gpu/drm/i915/i915_debugfs.c
> > index 5659d4c..38c7a5d 100644
> > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > @@ -2873,6 +2873,18 @@ static void intel_dp_info(struct seq_file
> > *m,
> >     intel_panel_info(m, &intel_connector->panel);
> >  }
> >  
> > +static void intel_dp_mst_info(struct seq_file *m,
> > +     struct intel_connector *intel_connector)
> > +{
> > +   struct intel_encoder *intel_encoder = intel_connector-
> > >encoder;
> > +   struct intel_dp_mst_encoder *intel_mst =
> > +   enc_to_mst(&intel_encoder->base);
> > +   struct intel_digital_port *intel_dig_port = intel_mst-
> > >primary;
> > +   struct intel_dp *intel_dp = &intel_dig_port->dp;
> > +
> > +   seq_printf(m, "\taudio support: %s\n",
> > drm_dp_mst_port_has_audio(&intel_dp->mst_mgr, intel_connector-
> > >port) ? "yes" :
> > "no");
> 
> Too much going on in just one line. You can replace the ternary
> operator with
> yesno(). You could also add a has_audio bool:
> 
> bool has_audio = drm_dp_mst_port_has_audio(...);
> seq_printf(..., yesno(has_audio));
> 
> 
> > +}
> > +
> >  static void intel_hdmi_info(struct seq_file *m,
> >     struct intel_connector
> > *intel_connector)
> >  {
> > @@ -2916,6 +2928,8 @@ static void intel_connector_info(struct
> > seq_file *m,
> >     intel_hdmi_info(m, intel_connector);
> >     else if (intel_encoder->type == INTEL_OUTPUT_LVDS)
> >     intel_lvds_info(m, intel_connector);
> > +   else if (intel_encoder->type ==
> > INTEL_OUTPUT_DP_MST)
> > +   intel_dp_mst_info(m, intel_connector);
> >     }
> >  
> >     seq_printf(m, "\tmodes:\n");
> > diff --git a/drivers/gpu/drm/i915/intel_audio.c
> > b/drivers/gpu/drm/i915/intel_audio.c
> > index 63d4706..07b2aa6 100644
> > --- a/drivers/gpu/drm/i915/intel_audio.c
> > +++ b/drivers/gpu/drm/i915/intel_audio.c
> > @@ -262,7 +262,8 @@ static void hsw_audio_codec_disable(struct
> > intel_encoder
> > *encoder)
> >     tmp |= AUD_CONFIG_N_PROG_ENABLE;
> >     tmp &= ~AUD_CONFIG_UPPER_N_MASK;
> >     tmp &= ~AUD_CONFIG_LOWER_N_MASK;
> > -   if (intel_pipe_has_type(intel_crtc,
> > INTEL_OUTPUT_DISPLAYPORT))
> > +   if (intel_pipe_has_type(intel_crtc,
> > INTEL_OUTPUT_DISPLAYPORT) ||
> > +   intel_pipe_has_type(intel_crtc,
> > INTEL_OUTPUT_DP_MST))
> 
> The second line should be aligned with '('.
> 
> >     tmp |= AUD_CONFIG_N_VALUE_INDEX;
> >     I915_WRITE(HSW_AUD_CFG(pipe), tmp);
> >  
> > @@ -478,7 +479,8 @@ static void ilk_audio_codec_enable(struct
> > drm_connector
> > *connector,
> >     tmp &= ~AUD_CONFIG_N_VALUE_INDEX;
> >     tmp &= ~AUD_CONFIG_N_PROG_ENABLE;
> >     tmp &= ~AUD_CONFIG_PIXEL_CLOCK_HDMI_MASK;
> > -   if (intel_pipe_has_type(intel_crtc,
> > INTEL_OUTPUT_DISPLAYPORT))
> > +   if (intel_pipe_has_type(intel_crtc,
> > INTEL_OUTPUT_DISPLAYPORT) ||
> > +   intel_pipe_has_type(intel_crtc,
> > INTEL_OUTPUT_DP_MST))
> 
> Same here.
> 
> >     tmp |= AUD_CONFIG_N_VALUE_INDEX;
> >     else
> >     tmp |=
> > audio_config_hdmi_pixel_clock(adjusted_mode);
> > @@ -516,7 +518,8 @@ void intel_audio_codec_enable(struct
> > intel_encoder
> > *intel_encoder)
> >  
> >     /* ELD Conn_Type */
> >     connector->eld[5] &= ~(3 << 2);
> > -   if (intel_pipe_has_type(crtc, INTEL_OUTPUT_DISPLAYPORT))
> > +   if (intel_pipe_has_type(crtc, INTEL_OUTPUT_DISPLAYPORT) ||
> > +   intel_pipe_has_type(crtc, INTEL_OUTPUT_DP_MST))
> >     connector->eld[5] |= (1 << 2);
> 
> And here.
> 
> >  
> >     connector->eld[6] = drm_av_sync_delay(connector,
> > adjusted_mode) / 2;
> > diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
> > b/drivers/gpu/drm/i915/intel_dp_mst.c
> > index 0639275..4ded0fb 100644
> > --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> > +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> > @@ -78,6 +78,8 @@ static bool intel_dp_mst_compute_config(struct
> > intel_encoder
> > *encoder,
> >     return false;
> >     }
> >  
> > +   if (drm_dp_mst_port_has_audio(&intel_dp->mst_mgr, found-
> > >port))
> > +   pipe_config->has_audio = 

Re: [Intel-gfx] [PATCH 00/11] Yet another FBC series, v3 part 2 v2

[Zanoni, Paulo R]

Em Qua, 2015-12-02 às 12:37 +, Chris Wilson escreveu:
> On Wed, Dec 02, 2015 at 10:15:16AM -0200, Paulo Zanoni wrote:
> > Hi
> > 
> > This series includes the implementation for the review feedback
> > given by Chris.
> > I also removed the patch that transformed our 50ms timeout into a
> > vblank-based
> > timeout due to performance concerns. The only patch that still
> > needs review is
> > patch 6.
> > 
> > Thanks,
> > Paulo
> > 
> > Paulo Zanoni (11):
> >   drm/i915: fix the CFB size check
> >   drm/i915: set dev_priv->fbc.crtc before scheduling the enable
> > work
> >   drm/i915: pass the crtc as an argument to intel_fbc_update()
> >   drm/i915: introduce is_active/activate/deactivate to the FBC
> > terminology
> >   drm/i915: introduce intel_fbc_{enable,disable}
> >   drm/i915: alloc/free the FBC CFB during enable/disable
> >   drm/i915: check for FBC planes in the same place as the pipes
> >   drm/i915: use a single intel_fbc_work struct
> >   drm/i915: kill fbc.uncompressed_size
> >   drm/i915: get rid of FBC {,de}activation messages
> >   drm/i915: only recompress FBC after flushing a drawing operation
> 
> My r-b still stand.

What about patch 6? Any concerns or additional requests?

Thanks,
Paulo

> -Chris
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [maintainer-tools PATCH 2/2] dim: add a QUICKSTART section to dim.rst

[Zanoni, Paulo R]

Em Sex, 2015-12-04 às 10:40 +0200, Jani Nikula escreveu:
> On Thu, 03 Dec 2015, Paulo Zanoni  wrote:
> > Because just running dim help doesn't give you the greater picture
> > of
> > the workflow. All the text here is based on an email written by
> > Daniel
> > Vetter, so the credits go to him. Any mistakes were introduced by
> > me.
> 
> We could bikeshed the text ad infinitum, but this is better than
> nothing, and can be improved upon. LGTM.
> 
> BR,
> Jani.
> 
> PS. I did reply with "reviewed-by" on the previous patch, but we
> haven't
> really tracked those for maintainer tools. Just getting an ack/lgtm
> is
> enough.

Pushed both patches. Daniel also Acked the patches on IRC last Friday.

Thanks for the reviews!

> 
> 
> > 
> > Credits-to: Daniel Vetter 
> > Signed-off-by: Paulo Zanoni 
> > ---
> >  dim.rst | 58
> > ++
> >  1 file changed, 58 insertions(+)
> > 
> > diff --git a/dim.rst b/dim.rst
> > index d5ec5c8..567bcb8 100644
> > --- a/dim.rst
> > +++ b/dim.rst
> > @@ -309,6 +309,64 @@ DIM_TEMPLATE_SIGNATURE
> >  --
> >  Path to a file containing a signature template for pull request
> > mails.
> >  
> > +QUICKSTART
> > +==
> > +
> > +For getting started grab the latest drm (drm-intel-maintainer)
> > script from::
> > +
> > +http://cgit.freedesktop.org/drm-intel/tree/dim?h=maintainer-to
> > ols
> > +
> > +There's also a sample config file for ~/.dimrc::
> > +
> > +http://cgit.freedesktop.org/drm-intel/tree/dimrc.sample?h=main
> > tainer-tools
> > +
> > +Plus, there's bash completion in the same directory if you feel
> > like using that.
> > +Run::
> > +
> > +$ dim help
> > +
> > +for tons of details about this thing works. Adjust your .dimrc to
> > match your
> > +setup and then run::
> > +
> > +$ dim setup
> > +
> > +This will also check out the latest maintainer-tools branches, so
> > please replace
> > +the dim you just downloaded with a symlink after this step. And by
> > the way, if
> > +you have improvements for dim, please submit them to intel-gfx.
> > +
> > +You should now have a main repository for patch application. The
> > directory
> > +corresponding to this repository is defined by DIM_DRM_INTEL in
> > your .dimrc.
> > +You should also have directories called maintainer-tools, drm-
> > intel-nightly (for
> > +rebuilding the tree), and drm-intel-rerere for some dim-internal
> > book-keeping.
> > +
> > +Applying patches to dinq is done in the main repository with::
> > +
> > +$ cat patch.mbox | dim apply-queued
> > +
> > +This works like a glorified version of git apply-mbox and does
> > basic patch
> > +checking and adds stuff like patchwork links of the merged patch.
> > It is
> > +preferred to use the patch email file instead of the original
> > patch file since
> > +it contains some interesting headers like the message ID. When
> > you're happy
> > +(remember that with a shared tree any mistake is permanent and
> > there's no
> > +rebasing) push out the new tree with::
> > +
> > +$ dim push-queued
> > +
> > +This will also rebuild a new drm-intel-nightly integration tree.
> > If that fails,
> > +ask maintainers for help with resolving conflicts. One thing to
> > note here is
> > +that the script syncs saved git rerere conflict resolutions
> > around. One does the
> > +resolution, everyone has it. The drawback is, someone screws up
> > the conflict
> > +resolution, everyone has it...
> > +
> > +Note that every two weeks Daniel cuts a new drm-intel-next by
> > tagging what's in
> > +drm-intel-next-queued. To increase the chances that the tree isn't
> > totally
> > +broken, only push bug fixes for serious problems on Thu/Fri (and
> > weekend) every
> > +second week (at the moment the release cycle is aligned with odd
> > work weeks, but
> > +just check out when the last tagged happened).
> > +
> > +If you need to push something to drm-intel-fixes or
> > +drm-intel-next-fixes, please quickly coordinate with Jani.
> > +
> >  CONTRIBUTING
> >  
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH igt 2/2] kms_frontbuffer_tracking: standardize the used FB sizes

[Zanoni, Paulo R]

Em Sex, 2015-12-04 às 16:28 +0100, Daniel Vetter escreveu:
> On Wed, Dec 02, 2015 at 10:47:01AM -0200, Paulo Zanoni wrote:
> > We want to make sure that both tiled and untiled buffers have the
> > same
> > size for the same width/height/format. This will allow better
> > control
> > over the failure paths exercised by our tests: when we try to flip
> > from tiled to untiled, we'll be sure that we won't execute the
> > error
> > path that checks for buffer sizes.
> > 
> > v2: Use the new igt_calc_fb_size() instead of implementing our own
> > size calculation (Daniel).
> > 
> > Signed-off-by: Paulo Zanoni 
> > ---
> >  tests/kms_frontbuffer_tracking.c | 51 ++
> > --
> >  1 file changed, 34 insertions(+), 17 deletions(-)
> > 
> > diff --git a/tests/kms_frontbuffer_tracking.c
> > b/tests/kms_frontbuffer_tracking.c
> > index 81703ec..3db95d2 100644
> > --- a/tests/kms_frontbuffer_tracking.c
> > +++ b/tests/kms_frontbuffer_tracking.c
> > @@ -479,10 +479,28 @@ static bool init_modeset_cached_params(void)
> >     return true;
> >  }
> >  
> > +static int format_get_bpp(uint32_t format)
> 
> Ah, missed one: igt_drm_format_to_bpp please, and if it doesn't cover
> them all we
> need to fix that asap.

I'm not sure if this is a good idea. Not every DRM format has a
matching cairo format, and it seems the whole igt_fb code is built
based on this assumption. On a quick look, it really seems that both
kms_render.c and kms_atomic.c will break if I add ARGB2101010 with a
matching CAIRO_INVALID (since they call igt_get_all_formats() and use
cairo).

I know, you can question the use of ARGB2101010 by
kms_frontbuffer_tracking (we don't use it anymore, the format is there
as an artifact of an older attempt when I initially added support for
multiple formats), but that doesn't solve the bigger problem that we
can't easily expand igt_drm_format_to_bpp().

If you still insist, the big plan should be to make sure that both
igt_fb and the libs can properly handle the cases where a DRM format
doesn't have a matching cairo format, but I don't want to block my
current tasks on this. So I'd vote to merge my patches as-is for now.

What do you think?

> -Daniel
> 
> > +{
> > +   switch (format) {
> > +   case DRM_FORMAT_RGB565:
> > +   return 16;
> > +   case DRM_FORMAT_XRGB:
> > +   case DRM_FORMAT_ARGB:
> > +   case DRM_FORMAT_ARGB2101010:
> > +   case DRM_FORMAT_XRGB2101010:
> > +   return 32;
> > +   default:
> > +   igt_assert(false);
> > +   }
> > +}
> > +
> >  static void create_fb(enum pixel_format pformat, int width, int
> > height,
> >       uint64_t tiling, int plane, struct igt_fb
> > *fb)
> >  {
> >     uint32_t format;
> > +   unsigned int size, stride;
> > +   int bpp;
> > +   uint64_t tiling_for_size;
> >  
> >     switch (pformat) {
> >     case FORMAT_RGB888:
> > @@ -512,7 +530,21 @@ static void create_fb(enum pixel_format
> > pformat, int width, int height,
> >     igt_assert(false);
> >     }
> >  
> > -   igt_create_fb(drm.fd, width, height, format, tiling, fb);
> > +   /* We want all frontbuffers with the same
> > width/height/format to have
> > +    * the same size regardless of tiling since we want to
> > properly exercise
> > +    * the Kernel's specific tiling-checking code paths
> > without accidentally
> > +    * hitting size-checking ones first. */
> > +   bpp = format_get_bpp(format);
> > +   if (plane == PLANE_CUR)
> > +   tiling_for_size = LOCAL_DRM_FORMAT_MOD_NONE;
> > +   else
> > +   tiling_for_size = LOCAL_I915_FORMAT_MOD_X_TILED;
> > +
> > +   igt_calc_fb_size(drm.fd, width, height, bpp,
> > tiling_for_size, &size,
> > +    &stride);
> > +
> > +   igt_create_fb_with_bo_size(drm.fd, width, height, format,
> > tiling, fb,
> > +      size, stride);
> >  }
> >  
> >  static uint32_t pick_color(struct igt_fb *fb, enum color ecolor)
> > @@ -1094,21 +1126,6 @@ static void *busy_thread_func(void *data)
> >     pthread_exit(0);
> >  }
> >  
> > -static int fb_get_bpp(struct igt_fb *fb)
> > -{
> > -   switch (fb->drm_format) {
> > -   case DRM_FORMAT_RGB565:
> > -   return 16;
> > -   case DRM_FORMAT_XRGB:
> > -   case DRM_FORMAT_ARGB:
> > -   case DRM_FORMAT_ARGB2101010:
> > -   case DRM_FORMAT_XRGB2101010:
> > -   return 32;
> > -   default:
> > -   igt_assert(false);
> > -   }
> > -}
> > -
> >  static void start_busy_thread(struct igt_fb *fb)
> >  {
> >     int rc;
> > @@ -1121,7 +1138,7 @@ static void start_busy_thread(struct igt_fb
> > *fb)
> >     busy_thread.width = fb->width;
> >     busy_thread.height = fb->height;
> >     busy_thread.color = pick_color(fb, COLOR_PRIM_BG);
> > -   busy_thread.bpp = fb_get_bpp(fb);
> > +   busy_thread.bpp = format_get_bpp(fb->drm_format);
> >  
> >     rc = pthread_create(&busy_thread.thread, NULL,
> > busy_thread_func, NULL);
> >     igt_assert_eq(rc, 0);
> > -- 
> > 2.6.2
> > 
> > _

Re: [Intel-gfx] [PATCH i-g-t] RFC: split PM workarounds into separate lib

[Zanoni, Paulo R]

Em Ter, 2015-12-08 às 10:50 +0200, David Weinehall escreveu:
> Since the defaults for some external power management related
> settings
> prevents us from testing our power management functionality properly,
> we have to work around it. Currently this is done from the individual
> test cases, but this is sub-optimal.  This patch moves the PM-related
> workarounds into a separate library, and adds some code to restore
> the
> previous settings for the SATA link power management while at it.
> 
> This patch should be seen as a RFC; there might be other workarounds
> for external issues that should be moved into the library, and if
> those
> workarounds aren't related to power management it might be better to
> choose a different name for the library.

I didn't deeply look the implementation, but you have my Acked-by on
the idea.

You may also consider adding a function to just run "sudo powertop --
auto-tune" in addition to the other things, but you can't undo this
later.

But in the end, it all depends on your machine. A bad machine will
never reach the deepest expected PC states. That's the problem when
automating things...

Since you're interested in PM, you may also want to look at:
http://patchwork.freedesktop.org/patch/66392/
maybe there's some code there that you may want to take.

> 
> David Weinehall (1):
>   lib/pm_workarounds: Lib for PM workarounds
> 
>  lib/Makefile.sources |   2 +
>  lib/igt.h|   1 +
>  lib/igt_aux.c|  15 +---
>  lib/pm_workarounds.c | 233
> +++
>  lib/pm_workarounds.h |  31 +++
>  tests/pm_lpsp.c  |  25 +-
>  tests/pm_rpm.c   |  29 ++-
>  7 files changed, 279 insertions(+), 57 deletions(-)
>  create mode 100644 lib/pm_workarounds.c
>  create mode 100644 lib/pm_workarounds.h
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC 00/22] Add support for GuC-based SLPC

[Zanoni, Paulo R]

Em Qua, 2016-01-20 às 18:26 -0800, tom.orou...@intel.com escreveu:
> From: Tom O'Rourke 
> 
> SLPC (Single Loop Power Controller) is a replacement for
> some host-based power management features.  The SLPC
> implemenation runs in firmware on GuC.
> 
> This series is a first request for comments.  This series
> is not expected to be merged.  After changes based on
> comments, a later patch series will be sent for merging.
>  
> This series has been tested with SKL guc firmware
> versions 4.3 and 4.7.  The graphics power management
> features in SLPC in those versions are DFPS (Dynamic FPS),
> Turbo, and DCC (Duty Cycle Control).  DFPS adjusts
> requested graphics frequency to maintain target framerate.
> Turbo adjusts requested graphics frequency to maintain
> target GT busyness.  DCC adjusts requested graphics
> frequency and stalls guc-scheduler to maintain actual
> graphics frequency in efficient range.
> 
> Patch 1/22 is included ihere for convenience and should be
> part of an earlier series.  SLPC assumes guc firmware has
> been loaded and GuC submission is enabled.
> 
> Patch 22/22 sets the flag to enable SLPC on SKL.  Without
> this patch, the previous patches should have no effect.
> 
> VIZ-6773, VIZ-6889

Hi

Some high-level comments for the whole series:

In many places there are 8 spaces instead of tabs.

There are also some lines containing just a tab character.

Lots of Yoda conditions: if (constant == variable).

Some functions would get much simpler if they had early returns.

I certainly wouldn't complain if you also extracted the relevant
rps/powersave code out of intel_pm.c to its own file with a nice
documentation. Of course, this could be done after the series.

Lots of ignored return values. It seems the inner functions all check
for errors and return them to their callers, but the top-most functions
added by the series just ignore the errors. See my previous comment on
patch 14 about this for suggestions.

There are no checks for GuC version here. We know that the SLPC ABI is
not stable and can change in new firmware versions, so I expect the
SLPC code to only run if it finds the specific _whitelisted_ GuC
versions. No "if (version >= num) use_slpc=true;", please.

I'm not 100% sure, but from what I could understand, it seems I'll get
a broken machine with no RPS at all if I don't have the GuC firmware
files - or if the GuC version is not the expected. IMHO this is a
regression since I currently don't have any firmware files and my SKL
machine works.

I see most of the functions are protected by "HAS_SLPC". Usually
HAS_SOMETHING is used for hardware features and is expected to be
constant on platforms. I suggest you to add a possible driver parameter
such as i915.enable_slpc, and also add a new "intel_slpc_enabled()" or
"intel_using_slpc()" function and replace all the HAS_SLPC checks with
these. This way, we'll be able to easily disable SLPC in case we don't
want it (such as due to a regression) or if there's no firmware or
incorrect firmware version, and revert back to the old (current)
behavior of driver-based turbo. The only HAS_SLPC check should be
during SLPC initialization. Having an easy way to enable/disable SLPC
will also be immensely helpful when we start running workloads to
decide if we want to enable it.

You could even go further and make the i915.enable_slpc param be a mask
where it's possible to select each sub-feature individually (dfps,
turbo, dcc).

Some of the checks for shared_data_obj could also become calls to an
inline function with a nice name such as intel_slpc_enabled() or
something else.

I see there's a specific pattern on the places that call
host2guc_action(). Perhaps we could move that common code to its own
function? It would also be nice to add a name to the 0xFF mask that we
return - and that gets ignored at the end of the call chains.

Patch 5 needs a commit message. Actually, when reviewing patch 4 I
thought it had broken RC6, until I saw patch 5, so maybe you could just
squash both commits into one.

On patch 13, those defines such as MAX_INTEL_PIPES are weird and
confusing (why do we check if they were already defined?), especially
since we already have I915_MAX_PIPES. And the only value that is
actually used is MAX_NUM_OF_PIPE. I would vote for you to only keep
this define, and prefix it with SLPC, such as SLPC_NUM_OF_PIPES (or any
other better name).

On patches 14/15, is mode->vrefresh accurate enough? Don't we want the
more-precise "clock/(htotal*vtotal)" value?

On patch 17. I'm not an expert here, but I'm not sure if we can call
kmap_atomic and then do those seq_printf calls without kunmap. 

Thanks,
Paulo

> 
> Dave Gordon (1):
>   drm/i915: Enable GuC submission, where supported
> 
> Sagar Arun Kamble (4):
>   drm/i915/slpc: Enable/Disable RC6 in SLPC flows
>   drm/i915/slpc: Add Display mode event related data structures
>   drm/i915/slpc: Notification of Display mode change
>   drm/i915/slpc: Notification of Refresh Rate change
> 
> To

Re: [Intel-gfx] [RFC 00/22] Add support for GuC-based SLPC

[Zanoni, Paulo R]

Em Ter, 2016-02-09 às 12:33 +0530, Kamble, Sagar A escreveu:
> Hi Paulo,
> 
> Thanks for comments.
> 1. Will make change related to #define for number of pipes and
> remove 
> the unnecessary ones.
> 2. vrefresh is almost same as "clock/(htotal*vtotal) if we round up 
> later. Will keep it vrefresh for now.

I was under the impression that the VSyncFTUsec field wanted the more
precise solution. Maybe Tom or someone else could clarify this to us.

> 
> Thanks
> Sagar
> 
> 
> On 2/4/2016 1:55 AM, Zanoni, Paulo R wrote:
> > Em Qua, 2016-01-20 às 18:26 -0800, tom.orou...@intel.com escreveu:
> > > From: Tom O'Rourke 
> > > 
> > > SLPC (Single Loop Power Controller) is a replacement for
> > > some host-based power management features.  The SLPC
> > > implemenation runs in firmware on GuC.
> > > 
> > > This series is a first request for comments.  This series
> > > is not expected to be merged.  After changes based on
> > > comments, a later patch series will be sent for merging.
> > >   
> > > This series has been tested with SKL guc firmware
> > > versions 4.3 and 4.7.  The graphics power management
> > > features in SLPC in those versions are DFPS (Dynamic FPS),
> > > Turbo, and DCC (Duty Cycle Control).  DFPS adjusts
> > > requested graphics frequency to maintain target framerate.
> > > Turbo adjusts requested graphics frequency to maintain
> > > target GT busyness.  DCC adjusts requested graphics
> > > frequency and stalls guc-scheduler to maintain actual
> > > graphics frequency in efficient range.
> > > 
> > > Patch 1/22 is included ihere for convenience and should be
> > > part of an earlier series.  SLPC assumes guc firmware has
> > > been loaded and GuC submission is enabled.
> > > 
> > > Patch 22/22 sets the flag to enable SLPC on SKL.  Without
> > > this patch, the previous patches should have no effect.
> > > 
> > > VIZ-6773, VIZ-6889
> > Hi
> > 
> > Some high-level comments for the whole series:
> > 
> > In many places there are 8 spaces instead of tabs.
> > 
> > There are also some lines containing just a tab character.
> > 
> > Lots of Yoda conditions: if (constant == variable).
> > 
> > Some functions would get much simpler if they had early returns.
> > 
> > I certainly wouldn't complain if you also extracted the relevant
> > rps/powersave code out of intel_pm.c to its own file with a nice
> > documentation. Of course, this could be done after the series.
> > 
> > Lots of ignored return values. It seems the inner functions all
> > check
> > for errors and return them to their callers, but the top-most
> > functions
> > added by the series just ignore the errors. See my previous comment
> > on
> > patch 14 about this for suggestions.
> > 
> > There are no checks for GuC version here. We know that the SLPC ABI
> > is
> > not stable and can change in new firmware versions, so I expect the
> > SLPC code to only run if it finds the specific _whitelisted_ GuC
> > versions. No "if (version >= num) use_slpc=true;", please.
> > 
> > I'm not 100% sure, but from what I could understand, it seems I'll
> > get
> > a broken machine with no RPS at all if I don't have the GuC
> > firmware
> > files - or if the GuC version is not the expected. IMHO this is a
> > regression since I currently don't have any firmware files and my
> > SKL
> > machine works.
> > 
> > I see most of the functions are protected by "HAS_SLPC". Usually
> > HAS_SOMETHING is used for hardware features and is expected to be
> > constant on platforms. I suggest you to add a possible driver
> > parameter
> > such as i915.enable_slpc, and also add a new "intel_slpc_enabled()"
> > or
> > "intel_using_slpc()" function and replace all the HAS_SLPC checks
> > with
> > these. This way, we'll be able to easily disable SLPC in case we
> > don't
> > want it (such as due to a regression) or if there's no firmware or
> > incorrect firmware version, and revert back to the old (current)
> > behavior of driver-based turbo. The only HAS_SLPC check should be
> > during SLPC initialization. Having an easy way to enable/disable
> > SLPC
> > will also be immensely helpful when we start running workloads to
> > decide if we want to enable it.
> > 
> > You could even go further and make the i915.enable_slpc param be a
> > mask
&

Re: [Intel-gfx] [PATCH v4 8/8] drm/i915: Remove vblank wait from hsw_enable_ips.

[Zanoni, Paulo R]

Em Qua, 2016-02-10 às 13:49 +0100, Maarten Lankhorst escreveu:
> intel_post_plane_update did an extra vblank wait that's no longer
> needed when enabling ips.
> 
> Signed-off-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 6bb1f5dbc7a0..19a8d376d63e 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -4569,9 +4569,6 @@ void hsw_enable_ips(struct intel_crtc *crtc)
>   if (!crtc->config->ips_enabled)
>   return;
>  
> - /* We can only enable IPS after we enable a plane and wait
> for a vblank */

Perhaps we can keep the comment, but change it into something like:

/* We can only enable IPS after we enable a plane and wait for a
vblank, but we don't need the wait here because of XYZ. */

> - intel_wait_for_vblank(dev, crtc->pipe);
> -
>   assert_plane_enabled(dev_priv, crtc->plane);
>   if (IS_BROADWELL(dev)) {
>   mutex_lock(&dev_priv->rps.hw_lock);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v4 6/8] drm/i915: Nuke fbc members from intel_crtc->atomic, v2.

[Zanoni, Paulo R]

Em Qua, 2016-02-10 às 13:49 +0100, Maarten Lankhorst escreveu:
> Factor out intel_fbc_supports_rotation

^ not anymore


>  and use it in
> pre_plane_update as well. This leaves intel_crtc->atomic
> empty, so remove it too.
> 
> Changes since v1:
> - Add a intel_fbc_supports_rotation helper.

Changes since v2:
- No more need for rotation special-casing.

(I suppose you also have to edit the commit title to be v3)

> 
> Signed-off-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 58 +-
> --
>  drivers/gpu/drm/i915/intel_drv.h | 15 --
>  2 files changed, 20 insertions(+), 53 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 54be8a255f1f..00cb261c6787 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -4782,11 +4782,9 @@ static void intel_post_plane_update(struct
> intel_crtc_state *old_crtc_state)
>  {
>   struct intel_crtc *crtc = to_intel_crtc(old_crtc_state-
> >base.crtc);
>   struct drm_atomic_state *old_state = old_crtc_state-
> >base.state;
> - struct intel_crtc_atomic_commit *atomic = &crtc->atomic;
>   struct intel_crtc_state *pipe_config =
>   to_intel_crtc_state(crtc->base.state);
>   struct drm_device *dev = crtc->base.dev;
> - struct drm_i915_private *dev_priv = dev->dev_private;
>   struct drm_plane *primary = crtc->base.primary;
>   struct drm_plane_state *old_pri_state =
>   drm_atomic_get_existing_plane_state(old_state,
> primary);
> @@ -4798,22 +4796,19 @@ static void intel_post_plane_update(struct
> intel_crtc_state *old_crtc_state)
>   if (pipe_config->wm_changed && pipe_config->base.active)
>   intel_update_watermarks(&crtc->base);
>  
> - if (atomic->update_fbc)
> - intel_fbc_post_update(crtc);
> -
>   if (old_pri_state) {

For a code reader that is not very familiar with all the atomic history
and its details, it's not trivial to conclude that "if
(drm_atomic_get_existing_plane_state(primary))", then we're updating
the primary plane on this atomic commit. And before this patch, it's
much much easier to conclude that update_fbc will be true when an
atomic update is touching the primary plane because that's explicitly
stated by the cod.

So although "let's kill this redundant struct" sounds good, it seems to
me that code clarity is going away with this patch, so I wonder if the
benefits of the patch outweigh the downsides. Isn't there something
else we could do about this, such as some renaming, or adding some
function aliases or just extra commenting?

>   struct intel_plane_state *primary_state =
>   to_intel_plane_state(primary->state);
>   struct intel_plane_state *old_primary_state =
>   to_intel_plane_state(old_pri_state);
>  
> + intel_fbc_post_update(crtc);
> +
>   if (primary_state->visible &&
>   (needs_modeset(&pipe_config->base) ||
>    !old_primary_state->visible))
>   intel_post_enable_primary(&crtc->base);
>   }
> -
> - memset(atomic, 0, sizeof(*atomic));
>  }
>  
>  static void intel_pre_plane_update(struct intel_crtc_state
> *old_crtc_state)
> @@ -4821,7 +4816,6 @@ static void intel_pre_plane_update(struct
> intel_crtc_state *old_crtc_state)
>   struct intel_crtc *crtc = to_intel_crtc(old_crtc_state-
> >base.crtc);
>   struct drm_device *dev = crtc->base.dev;
>   struct drm_i915_private *dev_priv = dev->dev_private;
> - struct intel_crtc_atomic_commit *atomic = &crtc->atomic;
>   struct intel_crtc_state *pipe_config =
>   to_intel_crtc_state(crtc->base.state);
>   struct drm_atomic_state *old_state = old_crtc_state-
> >base.state;
> @@ -4830,17 +4824,17 @@ static void intel_pre_plane_update(struct
> intel_crtc_state *old_crtc_state)
>   drm_atomic_get_existing_plane_state(old_state,
> primary);
>   bool modeset = needs_modeset(&pipe_config->base);
>  
> - if (atomic->update_fbc)
> - intel_fbc_pre_update(crtc);
> -
>   if (old_pri_state) {
>   struct intel_plane_state *primary_state =
>   to_intel_plane_state(primary->state);
>   struct intel_plane_state *old_primary_state =
>   to_intel_plane_state(old_pri_state);
> + bool turn_off = old_primary_state->visible &&
> + (modeset || !primary_state->visible); 

Not really related to the patch, but ok to keep since it's trivial...

> +
> + intel_fbc_pre_update(crtc);
>  
> - if (old_primary_state->visible &&
> - (modeset || !primary_state->visible))
> + if (turn_off)
>   intel_pre_disable_primary(&crtc->base);
>   }
>  
> @@ -11822,27 +11816,17 @@ int intel_plane_atomic_calc_ch

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Change i915.enable_psr parameter to use per platform default.

[Zanoni, Paulo R]

Em Ter, 2016-02-16 às 12:27 +0200, Jani Nikula escreveu:
> On Fri, 12 Feb 2016, Rodrigo Vivi  wrote:
> > This will give us flexibility to enable PSR by default
> > independently so
> > issues and corner cases in one platform won't affect others were we
> > have
> > it working properly.
> > 
> > Cc: Paulo Zanoni 
> > Signed-off-by: Rodrigo Vivi 
> > ---
> >  drivers/gpu/drm/i915/i915_params.c | 5 +++--
> >  drivers/gpu/drm/i915/intel_psr.c   | 5 +
> >  2 files changed, 8 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_params.c
> > b/drivers/gpu/drm/i915/i915_params.c
> > index 8b9f368..1b40ee6 100644
> > --- a/drivers/gpu/drm/i915/i915_params.c
> > +++ b/drivers/gpu/drm/i915/i915_params.c
> > @@ -38,7 +38,7 @@ struct i915_params i915 __read_mostly = {
> >     .enable_execlists = -1,
> >     .enable_hangcheck = true,
> >     .enable_ppgtt = -1,
> > -   .enable_psr = 0,
> > +   .enable_psr = -1,
> >     .preliminary_hw_support =
> > IS_ENABLED(CONFIG_DRM_I915_PRELIMINARY_HW_SUPPORT),
> >     .disable_power_well = -1,
> >     .enable_ips = 1,
> > @@ -128,7 +128,8 @@ MODULE_PARM_DESC(enable_execlists,
> >  
> >  module_param_named_unsafe(enable_psr, i915.enable_psr, int, 0600);
> >  MODULE_PARM_DESC(enable_psr, "Enable PSR "
> > -    "(0=disabled [default], 1=enabled - link mode
> > chosen per-platform, 2=force link-standby mode, 3=force link-off
> > mode)");
> > +    "(0=disabled, 1=enabled - link mode chosen per-
> > platform, 2=force link-standby mode, 3=force link-off mode) "
> > +    "Default: -1 (use per-chip default)");
> >  
> >  module_param_named_unsafe(preliminary_hw_support,
> > i915.preliminary_hw_support, int, 0600);
> >  MODULE_PARM_DESC(preliminary_hw_support,
> > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > b/drivers/gpu/drm/i915/intel_psr.c
> > index 4ab7579..655bdf6 100644
> > --- a/drivers/gpu/drm/i915/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > @@ -778,6 +778,11 @@ void intel_psr_init(struct drm_device *dev)
> >     dev_priv->psr_mmio_base = IS_HASWELL(dev_priv) ?
> >     HSW_EDP_PSR_BASE : BDW_EDP_PSR_BASE;
> >  
> > +   /* Per platform default */
> > +   if (i915.enable_psr == -1) {
> > +   i915.enable_psr = 0;
> > +   }
> 
> I don't like changing module parameters in-kernel, because them
> changing
> may be surprising to the user (and possibly developers debugging
> issues). We do this anyway, but AFAICT only for read only
> parameters. It's perhaps less surprising in that case.
> 
> Now, i915.enable_psr has permissions 0600, so you can change it
> dynamically through sysfs. Maybe it's a good debugging thing, I don't
> know. But I also notice some parts of the PSR functionality (link
> standby) can only be forced with i915.enable_psr during module load,
> and
> not dynamically.
> 
> So I think you need to either a) change enable_psr permission to 0400
> and give up the ability to dynamically toggle the feature, or b) fix
> up
> the current link standby force and not change the parameter value
> in-kernel in this patch.

Just as a reminder: igt relies on the 0600 permissions so it can run
PSR tests even while PSR is disabled by default. This was done because
we're trying to fix the features, so removing them from QA/CI testing
would only allow people to introduce unnoticed regressions. When I did
this, I was also expecting that at some point our pre-merge testing
would be running a huge chunk of IGT.

> 
> BR,
> Jani.
> 
> 
> > +
> >     /* Set link_standby x link_off defaults */
> >     if (IS_HASWELL(dev) || IS_BROADWELL(dev))
> >     /* HSW and BDW require workarounds that we don't
> > implement. */
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v4 1/8] drm/i915: Pass crtc state to modeset_get_crtc_power_domains.

[Zanoni, Paulo R]

Em Qua, 2016-02-10 às 13:49 +0100, Maarten Lankhorst escreveu:
> Use our newly created encoder_mask to iterate over the encoders.

As someone who was not paying attention to the discussion of the
previous patches related to this, I think it would be really good if
your commit message could tell me why we should use the newly created
encoder_mask instead of the current patch. What's bad about the current
version? Please sell me your patch. If you think the answer is trivial,
remember that it's not trivial to many people, and that random people
may find this patch through git-bisect and have to judge its
importance. Also, an explanation really helps the reviewers :)

The patch looks correct, so if you improve the commit message:
Reviewed-by: Paulo Zanoni 

> 
> Signed-off-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 33 +-
> ---
>  1 file changed, 21 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 30d4db0d776f..b479ba6238d7 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -5301,31 +5301,37 @@ intel_display_port_aux_power_domain(struct
> intel_encoder *intel_encoder)
>   }
>  }
>  
> -static unsigned long get_crtc_power_domains(struct drm_crtc *crtc)
> +static unsigned long get_crtc_power_domains(struct drm_crtc *crtc,
> + struct intel_crtc_state
> *crtc_state)
>  {
>   struct drm_device *dev = crtc->dev;
> - struct intel_encoder *intel_encoder;
> + struct drm_encoder *encoder;
>   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
>   enum pipe pipe = intel_crtc->pipe;
>   unsigned long mask;
> - enum transcoder transcoder = intel_crtc->config-
> >cpu_transcoder;
> + enum transcoder transcoder = crtc_state->cpu_transcoder;
>  
> - if (!crtc->state->active)
> + if (!crtc_state->base.active)
>   return 0;
>  
>   mask = BIT(POWER_DOMAIN_PIPE(pipe));
>   mask |= BIT(POWER_DOMAIN_TRANSCODER(transcoder));
> - if (intel_crtc->config->pch_pfit.enabled ||
> - intel_crtc->config->pch_pfit.force_thru)
> + if (crtc_state->pch_pfit.enabled ||
> + crtc_state->pch_pfit.force_thru)
>   mask |= BIT(POWER_DOMAIN_PIPE_PANEL_FITTER(pipe));
>  
> - for_each_encoder_on_crtc(dev, crtc, intel_encoder)
> + drm_for_each_encoder_mask(encoder, dev, crtc_state-
> >base.encoder_mask) {
> + struct intel_encoder *intel_encoder =
> to_intel_encoder(encoder);
> +
>   mask |=
> BIT(intel_display_port_power_domain(intel_encoder));
> + }
>  
>   return mask;
>  }
>  
> -static unsigned long modeset_get_crtc_power_domains(struct drm_crtc
> *crtc)
> +static unsigned long
> +modeset_get_crtc_power_domains(struct drm_crtc *crtc,
> +    struct intel_crtc_state *crtc_state)
>  {
>   struct drm_i915_private *dev_priv = crtc->dev->dev_private;
>   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> @@ -5333,7 +5339,8 @@ static unsigned long
> modeset_get_crtc_power_domains(struct drm_crtc *crtc)
>   unsigned long domains, new_domains, old_domains;
>  
>   old_domains = intel_crtc->enabled_power_domains;
> - intel_crtc->enabled_power_domains = new_domains =
> get_crtc_power_domains(crtc);
> + intel_crtc->enabled_power_domains = new_domains =
> + get_crtc_power_domains(crtc, crtc_state);
>  
>   domains = new_domains & ~old_domains;
>  
> @@ -5365,7 +5372,8 @@ static void
> modeset_update_crtc_power_domains(struct drm_atomic_state *state)
>   for_each_crtc_in_state(state, crtc, crtc_state, i) {
>   if (needs_modeset(crtc->state))
>   put_domains[to_intel_crtc(crtc)->pipe] =
> - modeset_get_crtc_power_domains(crtc)
> ;
> + modeset_get_crtc_power_domains(crtc,
> + to_intel_crtc_state(crtc-
> >state));
>   }
>  
>   if (dev_priv->display.modeset_commit_cdclk &&
> @@ -13486,7 +13494,8 @@ static int intel_atomic_commit(struct
> drm_device *dev,
>   }
>  
>   if (update_pipe) {
> - put_domains =
> modeset_get_crtc_power_domains(crtc);
> + put_domains =
> modeset_get_crtc_power_domains(crtc,
> +   to_intel_crtc_state(cr
> tc->state));
>  
>   /* make sure intel_modeset_check_state runs
> */
>   hw_check = true;
> @@ -15830,7 +15839,7 @@ intel_modeset_setup_hw_state(struct
> drm_device *dev)
>   for_each_intel_crtc(dev, crtc) {
>   unsigned long put_domains;
>  
> - put_domains = modeset_get_crtc_power_domains(&crtc-
> >base);
> + put_domains = modeset_get_crtc_power_domains(&crtc-
> >base, crtc->config);
>   

Re: [Intel-gfx] [PATCH v4 2/8] drm/i915: Unify power domain handling.

[Zanoni, Paulo R]

Em Qua, 2016-02-10 às 13:49 +0100, Maarten Lankhorst escreveu:
> Right now there's separate power domain handling for update_pipe and
> modesets. Unify this and only grab POWER_DOMAIN_MODESET once.

I would have split this in two separate commits: one for
POWER_DOMAIN_MODESET, and the other for killing
intel_modeset_update_crtc_power_domains. Let's hope no one bisects
anything to this patch :)

With or without the split:
Reviewed-by: Paulo Zanoni 

> 
> Signed-off-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 69 +-
> --
>  1 file changed, 24 insertions(+), 45 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index b479ba6238d7..804f2c6f260d 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -5359,32 +5359,6 @@ static void modeset_put_power_domains(struct
> drm_i915_private *dev_priv,
>   intel_display_power_put(dev_priv, domain);
>  }
>  
> -static void modeset_update_crtc_power_domains(struct
> drm_atomic_state *state)
> -{
> - struct intel_atomic_state *intel_state =
> to_intel_atomic_state(state);
> - struct drm_device *dev = state->dev;
> - struct drm_i915_private *dev_priv = dev->dev_private;
> - unsigned long put_domains[I915_MAX_PIPES] = {};
> - struct drm_crtc_state *crtc_state;
> - struct drm_crtc *crtc;
> - int i;
> -
> - for_each_crtc_in_state(state, crtc, crtc_state, i) {
> - if (needs_modeset(crtc->state))
> - put_domains[to_intel_crtc(crtc)->pipe] =
> - modeset_get_crtc_power_domains(crtc,
> - to_intel_crtc_state(crtc-
> >state));
> - }
> -
> - if (dev_priv->display.modeset_commit_cdclk &&
> - intel_state->dev_cdclk != dev_priv->cdclk_freq)
> - dev_priv->display.modeset_commit_cdclk(state);
> -
> - for (i = 0; i < I915_MAX_PIPES; i++)
> - if (put_domains[i])
> - modeset_put_power_domains(dev_priv,
> put_domains[i]);
> -}
> -
>  static int intel_compute_max_dotclk(struct drm_i915_private
> *dev_priv)
>  {
>   int max_cdclk_freq = dev_priv->max_cdclk_freq;
> @@ -13422,6 +13396,7 @@ static int intel_atomic_commit(struct
> drm_device *dev,
>   struct drm_crtc *crtc;
>   int ret = 0, i;
>   bool hw_check = intel_state->modeset;
> + unsigned long put_domains[I915_MAX_PIPES] = {};
>  
>   ret = intel_atomic_prepare_commit(dev, state, async);
>   if (ret) {
> @@ -13437,11 +13412,22 @@ static int intel_atomic_commit(struct
> drm_device *dev,
>      sizeof(intel_state->min_pixclk));
>   dev_priv->active_crtcs = intel_state->active_crtcs;
>   dev_priv->atomic_cdclk_freq = intel_state->cdclk;
> +
> + intel_display_power_get(dev_priv,
> POWER_DOMAIN_MODESET);
>   }
>  
>   for_each_crtc_in_state(state, crtc, crtc_state, i) {
>   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
>  
> + if (needs_modeset(crtc->state) ||
> + to_intel_crtc_state(crtc->state)->update_pipe) {
> + hw_check = true;
> +
> + put_domains[to_intel_crtc(crtc)->pipe] =
> + modeset_get_crtc_power_domains(crtc,
> + to_intel_crtc_state(crtc-
> >state));
> + }
> +
>   if (!needs_modeset(crtc->state))
>   continue;
>  
> @@ -13474,7 +13460,10 @@ static int intel_atomic_commit(struct
> drm_device *dev,
>   intel_shared_dpll_commit(state);
>  
>   drm_atomic_helper_update_legacy_modeset_state(state-
> >dev, state);
> - modeset_update_crtc_power_domains(state);
> +
> + if (dev_priv->display.modeset_commit_cdclk &&
> + intel_state->dev_cdclk != dev_priv->cdclk_freq)
> + dev_priv-
> >display.modeset_commit_cdclk(state);
>   }
>  
>   /* Now enable the clocks, plane, pipe, and connectors that
> we set up. */
> @@ -13483,24 +13472,12 @@ static int intel_atomic_commit(struct
> drm_device *dev,
>   bool modeset = needs_modeset(crtc->state);
>   bool update_pipe = !modeset &&
>   to_intel_crtc_state(crtc->state)-
> >update_pipe;
> - unsigned long put_domains = 0;
> -
> - if (modeset)
> - intel_display_power_get(dev_priv,
> POWER_DOMAIN_MODESET);
>  
>   if (modeset && crtc->state->active) {
>   update_scanline_offset(to_intel_crtc(crtc));
>   dev_priv->display.crtc_enable(crtc);
>   }
>  
> - if (update_pipe) {
> - put_domains =
> modeset_get_crtc_power_domains(crtc,
> -   to_intel_crtc_state(cr
> tc

Re: [Intel-gfx] [PATCH v4 3/8] drm/i915: Kill off intel_crtc->atomic.wait_vblank, v4.

[Zanoni, Paulo R]

Em Qua, 2016-02-10 às 13:49 +0100, Maarten Lankhorst escreveu:
> Currently we perform our own wait in post_plane_update,
> but the atomic core performs another one in wait_for_vblanks.
> This means that 2 vblanks are done when a fb is changed,
> which is a bit overkill.
> 
> Merge them by creating a helper function that takes a crtc mask
> for the planes to wait on.
> 
> The broadwell vblank workaround may look gone entirely but this is
> not the case. pipe_config->wm_changed is set to true
> when any plane is turned on, which forces a vblank wait.
> 
> Changes since v1:
> - Removing the double vblank wait on broadwell moved to its own
> commit.
> Changes since v2:
> - Move out POWER_DOMAIN_MODESET handling to its own commit.
> Changes since v3:
> - Do not wait for vblank on legacy cursor updates. (Ville)
> - Move broadwell vblank workaround comment to page_flip_finished.
> (Ville)
> Changes since v4:
> - Compile fix, legacy_cursor_flip -> *_update.
> 
> Signed-off-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/i915/intel_atomic.c  |  1 +
>  drivers/gpu/drm/i915/intel_display.c | 86
> +++-
>  drivers/gpu/drm/i915/intel_drv.h |  2 +-
>  3 files changed, 67 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_atomic.c
> b/drivers/gpu/drm/i915/intel_atomic.c
> index 4625f8a9ba12..8e579a8505ac 100644
> --- a/drivers/gpu/drm/i915/intel_atomic.c
> +++ b/drivers/gpu/drm/i915/intel_atomic.c
> @@ -97,6 +97,7 @@ intel_crtc_duplicate_state(struct drm_crtc *crtc)
>   crtc_state->disable_lp_wm = false;
>   crtc_state->disable_cxsr = false;
>   crtc_state->wm_changed = false;
> + crtc_state->fb_changed = false;
>  
>   return &crtc_state->base;
>  }
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 804f2c6f260d..4d4dddc1f970 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -4785,9 +4785,6 @@ static void intel_post_plane_update(struct
> intel_crtc *crtc)
>   to_intel_crtc_state(crtc->base.state);
>   struct drm_device *dev = crtc->base.dev;
>  
> - if (atomic->wait_vblank)
> - intel_wait_for_vblank(dev, crtc->pipe);
> -
>   intel_frontbuffer_flip(dev, atomic->fb_bits);
>  
>   crtc->wm.cxsr_allowed = true;
> @@ -10902,6 +10899,12 @@ static bool page_flip_finished(struct
> intel_crtc *crtc)
>   return true;
>  
>   /*
> +  * BDW signals flip done immediately if the plane
> +  * is disabled, even if the plane enable is already
> +  * armed to occur at the next vblank :(
> +  */

Having this comment here is just... weird. I think it removes a lot of
the context that was present before.

> +
> + /*
>    * A DSPSURFLIVE check isn't enough in case the mmio and CS
> flips
>    * used the same base address. In that case the mmio flip
> might
>    * have completed, but the CS hasn't even executed the flip
> yet.
> @@ -11778,6 +11781,9 @@ int intel_plane_atomic_calc_changes(struct
> drm_crtc_state *crtc_state,
>   if (!was_visible && !visible)
>   return 0;
>  
> + if (fb != old_plane_state->base.fb)
> + pipe_config->fb_changed = true;
> +
>   turn_off = was_visible && (!visible || mode_changed);
>   turn_on = visible && (!was_visible || mode_changed);
>  
> @@ -11793,8 +11799,6 @@ int intel_plane_atomic_calc_changes(struct
> drm_crtc_state *crtc_state,
>  
>   /* must disable cxsr around plane enable/disable */
>   if (plane->type != DRM_PLANE_TYPE_CURSOR) {
> - if (is_crtc_enabled)
> - intel_crtc->atomic.wait_vblank =
> true;
>   pipe_config->disable_cxsr = true;
>   }

We could have killed the brackets here :)

>   } else if (intel_wm_need_update(plane, plane_state)) {
> @@ -11810,14 +11814,6 @@ int intel_plane_atomic_calc_changes(struct
> drm_crtc_state *crtc_state,
>   intel_crtc->atomic.post_enable_primary = turn_on;
>   intel_crtc->atomic.update_fbc = true;
>  
> - /*
> -  * BDW signals flip done immediately if the plane
> -  * is disabled, even if the plane enable is already
> -  * armed to occur at the next vblank :(
> -  */
> - if (turn_on && IS_BROADWELL(dev))
> - intel_crtc->atomic.wait_vblank = true;
> -
>   break;
>   case DRM_PLANE_TYPE_CURSOR:
>   break;
> @@ -11831,12 +11827,10 @@ int intel_plane_atomic_calc_changes(struct
> drm_crtc_state *crtc_state,
>   if (IS_IVYBRIDGE(dev) &&
>   needs_scaling(to_intel_plane_state(plane_state))
> &&
>   !needs_scaling(old_plane_state)) {
> - to_intel_crtc_state(crtc_state)-
> >disable_lp_wm = true;
> - } else if (turn_off && !mode_changed) {
> -   

Re: [Intel-gfx] [PATCH v4 1/8] drm/i915: Pass crtc state to modeset_get_crtc_power_domains.

[Zanoni, Paulo R]

Em Qui, 2016-02-18 às 10:51 +0100, Maarten Lankhorst escreveu:
> Op 17-02-16 om 18:54 schreef Zanoni, Paulo R:
> > Em Qua, 2016-02-10 às 13:49 +0100, Maarten Lankhorst escreveu:
> > > Use our newly created encoder_mask to iterate over the encoders.
> > As someone who was not paying attention to the discussion of the
> > previous patches related to this, I think it would be really good
> > if
> > your commit message could tell me why we should use the newly
> > created
> > encoder_mask instead of the current patch. What's bad about the
> > current
> > version? Please sell me your patch. If you think the answer is
> > trivial,
> > remember that it's not trivial to many people, and that random
> > people
> > may find this patch through git-bisect and have to judge its
> > importance. Also, an explanation really helps the reviewers :)
> > 
> > The patch looks correct, so if you improve the commit message:
> > Reviewed-by: Paulo Zanoni 
> 
> Does this sound good?
> 
> Use our newly created encoder_mask to iterate over the encoders.
> This makes it possible to get the crtc power domains from the
> crtc_state at any time, without any locks or having to look at
> the legacy state.

But we were already not grabbing any locks. Is this a bug fix? It would
be good to point it if it's an actual fix.

Anyway, it's definitely better now :)

> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v4 3/8] drm/i915: Kill off intel_crtc->atomic.wait_vblank, v4.

[Zanoni, Paulo R]

Em Qui, 2016-02-18 às 14:22 +0100, Maarten Lankhorst escreveu:
> Op 17-02-16 om 22:20 schreef Zanoni, Paulo R:
> > Em Qua, 2016-02-10 às 13:49 +0100, Maarten Lankhorst escreveu:
> > > Currently we perform our own wait in post_plane_update,
> > > but the atomic core performs another one in wait_for_vblanks.
> > > This means that 2 vblanks are done when a fb is changed,
> > > which is a bit overkill.
> > > 
> > > Merge them by creating a helper function that takes a crtc mask
> > > for the planes to wait on.
> > > 
> > > The broadwell vblank workaround may look gone entirely but this
> > > is
> > > not the case. pipe_config->wm_changed is set to true
> > > when any plane is turned on, which forces a vblank wait.
> > > 
> > > Changes since v1:
> > > - Removing the double vblank wait on broadwell moved to its own
> > > commit.
> > > Changes since v2:
> > > - Move out POWER_DOMAIN_MODESET handling to its own commit.
> > > Changes since v3:
> > > - Do not wait for vblank on legacy cursor updates. (Ville)
> > > - Move broadwell vblank workaround comment to page_flip_finished.
> > > (Ville)
> > > Changes since v4:
> > > - Compile fix, legacy_cursor_flip -> *_update.
> > > 
> > > Signed-off-by: Maarten Lankhorst  > > om>
> > > ---
> > >  drivers/gpu/drm/i915/intel_atomic.c  |  1 +
> > >  drivers/gpu/drm/i915/intel_display.c | 86
> > > +++-
> > >  drivers/gpu/drm/i915/intel_drv.h |  2 +-
> > >  3 files changed, 67 insertions(+), 22 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_atomic.c
> > > b/drivers/gpu/drm/i915/intel_atomic.c
> > > index 4625f8a9ba12..8e579a8505ac 100644
> > > --- a/drivers/gpu/drm/i915/intel_atomic.c
> > > +++ b/drivers/gpu/drm/i915/intel_atomic.c
> > > @@ -97,6 +97,7 @@ intel_crtc_duplicate_state(struct drm_crtc
> > > *crtc)
> > >   crtc_state->disable_lp_wm = false;
> > >   crtc_state->disable_cxsr = false;
> > >   crtc_state->wm_changed = false;
> > > + crtc_state->fb_changed = false;
> > >  
> > >   return &crtc_state->base;
> > >  }
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > > b/drivers/gpu/drm/i915/intel_display.c
> > > index 804f2c6f260d..4d4dddc1f970 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -4785,9 +4785,6 @@ static void intel_post_plane_update(struct
> > > intel_crtc *crtc)
> > >   to_intel_crtc_state(crtc->base.state);
> > >   struct drm_device *dev = crtc->base.dev;
> > >  
> > > - if (atomic->wait_vblank)
> > > - intel_wait_for_vblank(dev, crtc->pipe);
> > > -
> > >   intel_frontbuffer_flip(dev, atomic->fb_bits);
> > >  
> > >   crtc->wm.cxsr_allowed = true;
> > > @@ -10902,6 +10899,12 @@ static bool page_flip_finished(struct
> > > intel_crtc *crtc)
> > >   return true;
> > >  
> > >   /*
> > > +  * BDW signals flip done immediately if the plane
> > > +  * is disabled, even if the plane enable is already
> > > +  * armed to occur at the next vblank :(
> > > +  */
> > Having this comment here is just... weird. I think it removes a lot
> > of
> > the context that was present before.
> > 
> > > +
> > > + /*
> > >    * A DSPSURFLIVE check isn't enough in case the mmio and
> > > CS
> > > flips
> > >    * used the same base address. In that case the mmio
> > > flip
> > > might
> > >    * have completed, but the CS hasn't even executed the
> > > flip
> > > yet.
> > > @@ -11778,6 +11781,9 @@ int
> > > intel_plane_atomic_calc_changes(struct
> > > drm_crtc_state *crtc_state,
> > >   if (!was_visible && !visible)
> > >   return 0;
> > >  
> > > + if (fb != old_plane_state->base.fb)
> > > + pipe_config->fb_changed = true;
> > > +
> > >   turn_off = was_visible && (!visible || mode_changed);
> > >   turn_on = visible && (!was_visible || mode_changed);
> > >  
> > > @@ -11793,8 +11799,6 @@ int
> > > intel_plane_atomic_calc_changes(struct
> > > drm_crtc_state *crtc_state,
> > >  
> > >   /* must dis

Re: [Intel-gfx] [PATCH v4 3/8] drm/i915: Kill off intel_crtc->atomic.wait_vblank, v4.

[Zanoni, Paulo R]

Em Qui, 2016-02-18 às 15:46 +0100, Maarten Lankhorst escreveu:
> Op 18-02-16 om 15:14 schreef Zanoni, Paulo R:
> > Em Qui, 2016-02-18 às 14:22 +0100, Maarten Lankhorst escreveu:
> > > Op 17-02-16 om 22:20 schreef Zanoni, Paulo R:
> > > > Em Qua, 2016-02-10 às 13:49 +0100, Maarten Lankhorst escreveu:
> > > > > Currently we perform our own wait in post_plane_update,
> > > > > but the atomic core performs another one in wait_for_vblanks.
> > > > > This means that 2 vblanks are done when a fb is changed,
> > > > > which is a bit overkill.
> > > > > 
> > > > > Merge them by creating a helper function that takes a crtc
> > > > > mask
> > > > > for the planes to wait on.
> > > > > 
> > > > > The broadwell vblank workaround may look gone entirely but
> > > > > this
> > > > > is
> > > > > not the case. pipe_config->wm_changed is set to true
> > > > > when any plane is turned on, which forces a vblank wait.
> > > > > 
> > > > > Changes since v1:
> > > > > - Removing the double vblank wait on broadwell moved to its
> > > > > own
> > > > > commit.
> > > > > Changes since v2:
> > > > > - Move out POWER_DOMAIN_MODESET handling to its own commit.
> > > > > Changes since v3:
> > > > > - Do not wait for vblank on legacy cursor updates. (Ville)
> > > > > - Move broadwell vblank workaround comment to
> > > > > page_flip_finished.
> > > > > (Ville)
> > > > > Changes since v4:
> > > > > - Compile fix, legacy_cursor_flip -> *_update.
> > > > > 
> > > > > Signed-off-by: Maarten Lankhorst  > > > > el.c
> > > > > om>
> > > > > ---
> > > > >  drivers/gpu/drm/i915/intel_atomic.c  |  1 +
> > > > >  drivers/gpu/drm/i915/intel_display.c | 86
> > > > > +++-
> > > > >  drivers/gpu/drm/i915/intel_drv.h |  2 +-
> > > > >  3 files changed, 67 insertions(+), 22 deletions(-)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/i915/intel_atomic.c
> > > > > b/drivers/gpu/drm/i915/intel_atomic.c
> > > > > index 4625f8a9ba12..8e579a8505ac 100644
> > > > > --- a/drivers/gpu/drm/i915/intel_atomic.c
> > > > > +++ b/drivers/gpu/drm/i915/intel_atomic.c
> > > > > @@ -97,6 +97,7 @@ intel_crtc_duplicate_state(struct drm_crtc
> > > > > *crtc)
> > > > >   crtc_state->disable_lp_wm = false;
> > > > >   crtc_state->disable_cxsr = false;
> > > > >   crtc_state->wm_changed = false;
> > > > > + crtc_state->fb_changed = false;
> > > > >  
> > > > >   return &crtc_state->base;
> > > > >  }
> > > > > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > > > > b/drivers/gpu/drm/i915/intel_display.c
> > > > > index 804f2c6f260d..4d4dddc1f970 100644
> > > > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > > > @@ -4785,9 +4785,6 @@ static void
> > > > > intel_post_plane_update(struct
> > > > > intel_crtc *crtc)
> > > > >   to_intel_crtc_state(crtc->base.state);
> > > > >   struct drm_device *dev = crtc->base.dev;
> > > > >  
> > > > > - if (atomic->wait_vblank)
> > > > > - intel_wait_for_vblank(dev, crtc->pipe);
> > > > > -
> > > > >   intel_frontbuffer_flip(dev, atomic->fb_bits);
> > > > >  
> > > > >   crtc->wm.cxsr_allowed = true;
> > > > > @@ -10902,6 +10899,12 @@ static bool
> > > > > page_flip_finished(struct
> > > > > intel_crtc *crtc)
> > > > >   return true;
> > > > >  
> > > > >   /*
> > > > > +  * BDW signals flip done immediately if the plane
> > > > > +  * is disabled, even if the plane enable is already
> > > > > +  * armed to occur at the next vblank :(
> > > > > +  */
> > > > Having this comment here is just... weird. I think it removes a
> > > > lot
> > > > of
&

Re: [Intel-gfx] [PATCH v4 6/8] drm/i915: Nuke fbc members from intel_crtc->atomic, v2.

[Zanoni, Paulo R]

Em Seg, 2016-02-15 às 15:31 +0100, Maarten Lankhorst escreveu:
> Op 12-02-16 om 14:56 schreef Zanoni, Paulo R:
> > Em Qua, 2016-02-10 às 13:49 +0100, Maarten Lankhorst escreveu:
> > > Factor out intel_fbc_supports_rotation
> > ^ not anymore
> > 
> > 
> > >  and use it in
> > > pre_plane_update as well. This leaves intel_crtc->atomic
> > > empty, so remove it too.
> > > 
> > > Changes since v1:
> > > - Add a intel_fbc_supports_rotation helper.
> > Changes since v2:
> > - No more need for rotation special-casing.
> > 
> > (I suppose you also have to edit the commit title to be v3)
> > 
> > > Signed-off-by: Maarten Lankhorst  > > om>
> > > ---
> > >  drivers/gpu/drm/i915/intel_display.c | 58 +-
> > > 
> > > --
> > >  drivers/gpu/drm/i915/intel_drv.h | 15 --
> > >  2 files changed, 20 insertions(+), 53 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > > b/drivers/gpu/drm/i915/intel_display.c
> > > index 54be8a255f1f..00cb261c6787 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -4782,11 +4782,9 @@ static void intel_post_plane_update(struct
> > > intel_crtc_state *old_crtc_state)
> > >  {
> > >   struct intel_crtc *crtc = to_intel_crtc(old_crtc_state-
> > > > base.crtc);
> > >   struct drm_atomic_state *old_state = old_crtc_state-
> > > > base.state;
> > > - struct intel_crtc_atomic_commit *atomic = &crtc->atomic;
> > >   struct intel_crtc_state *pipe_config =
> > >   to_intel_crtc_state(crtc->base.state);
> > >   struct drm_device *dev = crtc->base.dev;
> > > - struct drm_i915_private *dev_priv = dev->dev_private;
> > >   struct drm_plane *primary = crtc->base.primary;
> > >   struct drm_plane_state *old_pri_state =
> > >   drm_atomic_get_existing_plane_state(old_state,
> > > primary);
> > > @@ -4798,22 +4796,19 @@ static void
> > > intel_post_plane_update(struct
> > > intel_crtc_state *old_crtc_state)
> > >   if (pipe_config->wm_changed && pipe_config->base.active)
> > >   intel_update_watermarks(&crtc->base);
> > >  
> > > - if (atomic->update_fbc)
> > > - intel_fbc_post_update(crtc);
> > > -
> > >   if (old_pri_state) {
> > For a code reader that is not very familiar with all the atomic
> > history
> > and its details, it's not trivial to conclude that "if
> > (drm_atomic_get_existing_plane_state(primary))", then we're
> > updating
> > the primary plane on this atomic commit. And before this patch,
> > it's
> > much much easier to conclude that update_fbc will be true when an
> > atomic update is touching the primary plane because that's
> > explicitly
> > stated by the cod.
> > 
> > So although "let's kill this redundant struct" sounds good, it
> > seems to
> > me that code clarity is going away with this patch, so I wonder if
> > the
> > benefits of the patch outweigh the downsides. Isn't there something
> > else we could do about this, such as some renaming, or adding some
> > function aliases or just extra commenting?
> > 
> > >   struct intel_plane_state *primary_state =
> > >   to_intel_plane_state(primary->state);
> > >   struct intel_plane_state *old_primary_state =
> > >   to_intel_plane_state(old_pri_state);
> > >  
> > > + intel_fbc_post_update(crtc);
> > > +
> > >   if (primary_state->visible &&
> > >   (needs_modeset(&pipe_config->base) ||
> > >    !old_primary_state->visible))
> > >   intel_post_enable_primary(&crtc->base);
> > >   }
> > > -
> > > - memset(atomic, 0, sizeof(*atomic));
> > >  }
> > >  
> > >  static void intel_pre_plane_update(struct intel_crtc_state
> > > *old_crtc_state)
> > > @@ -4821,7 +4816,6 @@ static void intel_pre_plane_update(struct
> > > intel_crtc_state *old_crtc_state)
> > >   struct intel_crtc *crtc = to_intel_crtc(old_crtc_state-
> > > > base.crtc);
> > >   struct drm_device *dev = crtc->base.dev;
> > >   struct drm_i915_private *dev_priv = dev->dev_pr

Re: [Intel-gfx] [PATCH v4 7/8] drm/i915: Do not compute watermarks on a noop.

[Zanoni, Paulo R]

Em Qua, 2016-02-10 às 13:49 +0100, Maarten Lankhorst escreveu:
> No atomic state should be included after all validation when nothing
> has
> changed. During modeset all active planes will be added to the state,
> while disabled planes won't change their state.

As someone who is also not super familiar with the new watermarks code,
I really really wish I had a more detailed commit message to allow me
to understand your train of thought. I'll ask some questions below to
validate my understanding.

> 
> Signed-off-by: Maarten Lankhorst 
> Cc: Matt Roper 
> ---
>  drivers/gpu/drm/i915/intel_display.c |  3 +-
>  drivers/gpu/drm/i915/intel_drv.h | 13 
>  drivers/gpu/drm/i915/intel_pm.c  | 61 +-
> --
>  3 files changed, 51 insertions(+), 26 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 00cb261c6787..6bb1f5dbc7a0 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -11910,7 +11910,8 @@ static int intel_crtc_atomic_check(struct
> drm_crtc *crtc,
>   }
>  
>   ret = 0;
> - if (dev_priv->display.compute_pipe_wm) {
> + if (dev_priv->display.compute_pipe_wm &&
> + (mode_changed || pipe_config->update_pipe || crtc_state-
> >planes_changed)) {
>   ret = dev_priv->display.compute_pipe_wm(intel_crtc,
> state);
>   if (ret)
>   return ret;

Can't this chunk be on its own separate commit? I'm not sure why the
rest of the commit is related to this change.

It seems the rest of the commit is aimed reducing the number of planes
we have to lock, not about not computing WMs if nothing in the pipe has
changed.

> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 8effb9ece21e..144597ac74e3 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1583,6 +1583,19 @@ intel_atomic_get_crtc_state(struct
> drm_atomic_state *state,
>  
>   return to_intel_crtc_state(crtc_state);
>  }
> +
> +static inline struct intel_plane_state *
> +intel_atomic_get_existing_plane_state(struct drm_atomic_state
> *state,
> +   struct intel_plane *plane)
> +{
> + struct drm_plane_state *plane_state;
> +
> + plane_state = drm_atomic_get_existing_plane_state(state,
> &plane->base);
> +
> + return to_intel_plane_state(plane_state);
> +}
> +
> +

Two newlines above.

It seems you'll be able to simplify a lot of stuff with this new
function. I'm looking forward to review that patch :)


>  int intel_atomic_setup_scalers(struct drm_device *dev,
>   struct intel_crtc *intel_crtc,
>   struct intel_crtc_state *crtc_state);
> diff --git a/drivers/gpu/drm/i915/intel_pm.c
> b/drivers/gpu/drm/i915/intel_pm.c
> index 379eabe093cb..8fb8c6891ae6 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -2010,11 +2010,18 @@ static void ilk_compute_wm_level(const struct
> drm_i915_private *dev_priv,
>   cur_latency *= 5;
>   }
>  
> - result->pri_val = ilk_compute_pri_wm(cstate, pristate,
> -  pri_latency, level);
> - result->spr_val = ilk_compute_spr_wm(cstate, sprstate,
> spr_latency);
> - result->cur_val = ilk_compute_cur_wm(cstate, curstate,
> cur_latency);
> - result->fbc_val = ilk_compute_fbc_wm(cstate, pristate,
> result->pri_val);
> + if (pristate) {
> + result->pri_val = ilk_compute_pri_wm(cstate,
> pristate,
> +  pri_latency,
> level);
> + result->fbc_val = ilk_compute_fbc_wm(cstate,
> pristate, result->pri_val);
> + }
> +
> + if (sprstate)
> + result->spr_val = ilk_compute_spr_wm(cstate,
> sprstate, spr_latency);
> +
> + if (curstate)
> + result->cur_val = ilk_compute_cur_wm(cstate,
> curstate, cur_latency);
> +
>   result->enable = true;
>  }
>  
> @@ -2287,7 +2294,6 @@ static int ilk_compute_pipe_wm(struct
> intel_crtc *intel_crtc,
>   const struct drm_i915_private *dev_priv = dev->dev_private;
>   struct intel_crtc_state *cstate = NULL;
>   struct intel_plane *intel_plane;
> - struct drm_plane_state *ps;
>   struct intel_plane_state *pristate = NULL;
>   struct intel_plane_state *sprstate = NULL;
>   struct intel_plane_state *curstate = NULL;
> @@ -2306,30 +2312,37 @@ static int ilk_compute_pipe_wm(struct
> intel_crtc *intel_crtc,
>   memset(pipe_wm, 0, sizeof(*pipe_wm));
>  
>   for_each_intel_plane_on_crtc(dev, intel_crtc, intel_plane) {
> - ps = drm_atomic_get_plane_state(state,
> - &intel_plane->base);
> - if (IS_ERR(ps))
> - return PTR_ERR(ps);
> + struct intel_plane_state *ps;
> +
> + ps = intel_atomic_get_existing_plane_stat

Re: [Intel-gfx] [PATCH 4/6] drm/i915: Make the LPT iclkip 20MHz case more generic

[Zanoni, Paulo R]

Em Qua, 2016-02-17 às 21:41 +0200, ville.syrj...@linux.intel.com
escreveu:
> From: Ville Syrjälä 
> 
> The reason for spcial casing 20MHz in the iclkip calculations is that
> it would overflow the 7 bit divisor value. Let's rewrite the special
> case to check for just that, and bump up auxdiv when needed. This
> makes
> the code work for freqeuencies close to but not exactly 20MHz. The
> real
> lower limit for auxdiv=0 is actually:
> 17280/(0x7f+2)*64)=~20930 kHz, and below that we must resort to
> auxdiv=1.
> 
> Actually this is all very theoretical since we limit the dotclock to
> min 25MHz with CRT on all platforms. 25Mhz is actually the documented
> limit in Bspec, so it seems we ought to never need to worry about the
> auxdiv=1 case. But no harm in having it.

I like the patch and it looks correct. The main "advantage" of the
previous version is that it matched the spec exactly, so future code
readers may be confused now. Maybe a little comment more explicitly
explaining why it doesn't match the spec now would help: possibly some
shorter version of your commit message, with the typos fixed.

Anyway, git-bisect should be enough and I'm fine even without the
comment:
Reviewed-by: Paulo Zanoni 

> 
> Cc: Paulo Zanoni 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 40 +-
> --
>  1 file changed, 19 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index a3c959cd8b3b..5e7b22a31098 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -3957,37 +3957,35 @@ static void lpt_disable_iclkip(struct
> drm_i915_private *dev_priv)
>  /* Program iCLKIP clock to the desired frequency */
>  static void lpt_program_iclkip(struct drm_crtc *crtc)
>  {
> - struct drm_device *dev = crtc->dev;
> - struct drm_i915_private *dev_priv = dev->dev_private;
> + struct drm_i915_private *dev_priv = to_i915(crtc->dev);
>   int clock = to_intel_crtc(crtc)->config-
> >base.adjusted_mode.crtc_clock;
>   u32 divsel, phaseinc, auxdiv, phasedir = 0;
>   u32 temp;
>  
>   lpt_disable_iclkip(dev_priv);
>  
> - /* 20MHz is a corner case which is out of range for the 7-
> bit divisor */
> - if (clock == 2) {
> - auxdiv = 1;
> - divsel = 0x41;
> - phaseinc = 0x20;
> - } else {
> - /* The iCLK virtual clock root frequency is in MHz,
> -  * but the adjusted_mode->crtc_clock in in KHz. To
> get the
> -  * divisors, it is necessary to divide one by
> another, so we
> -  * convert the virtual clock precision to KHz here
> for higher
> -  * precision.
> -  */
> + /* The iCLK virtual clock root frequency is in MHz,
> +  * but the adjusted_mode->crtc_clock in in KHz. To get the
> +  * divisors, it is necessary to divide one by another, so we
> +  * convert the virtual clock precision to KHz here for
> higher
> +  * precision.
> +  */
> + for (auxdiv = 0; auxdiv < 2; auxdiv++) {
>   u32 iclk_virtual_root_freq = 172800 * 1000;
>   u32 iclk_pi_range = 64;
> - u32 desired_divisor, msb_divisor_value, pi_value;
> + u32 desired_divisor;
>  
> - desired_divisor =
> DIV_ROUND_CLOSEST(iclk_virtual_root_freq, clock);
> - msb_divisor_value = desired_divisor / iclk_pi_range;
> - pi_value = desired_divisor % iclk_pi_range;
> + desired_divisor =
> DIV_ROUND_CLOSEST(iclk_virtual_root_freq,
> + clock <<
> auxdiv);
> + divsel = (desired_divisor / iclk_pi_range) - 2;
> + phaseinc = desired_divisor % iclk_pi_range;
>  
> - auxdiv = 0;
> - divsel = msb_divisor_value - 2;
> - phaseinc = pi_value;
> + /*
> +  * Near 20MHz is a corner case which is
> +  * out of range for the 7-bit divisor
> +  */
> + if (divsel <= 0x7f)
> + break;
>   }
>  
>   /* This should not happen with any sane values */
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/fbc: enable FBC by default on HSW and BDW

[Zanoni, Paulo R]

Em Qua, 2016-02-17 às 08:40 +, Patchwork escreveu:
> == Summary ==
> 
> Series 3500v1 drm/i915/fbc: enable FBC by default on HSW and BDW
> http://patchwork.freedesktop.org/api/1.0/series/3500/revisions/1/mbox
> /
> 
> Test pm_rpm:
> Subgroup basic-pci-d3-state:
> pass   -> DMESG-WARN (bsw-nuc-2)

https://bugs.freedesktop.org/show_bug.cgi?id=94163

I asked Daniel if this needed additional acks/reviews due to potential
controversy, but he said I can merge the patch.

Patch merged. Thanks for all the reviews leading to this :)

> Subgroup basic-rte:
> dmesg-warn -> PASS   (bsw-nuc-2)
> 
> bsw-nuc-
> 2total:165  pass:134  dwarn:2   dfail:0   fail:0   skip:29 
> byt-
> nuc  total:165  pass:140  dwarn:1   dfail:0   fail:0   skip:2
> 4 
> ilk-
> hp8440p  total:165  pass:116  dwarn:0   dfail:0   fail:1   skip:4
> 8 
> 
> Results at /archive/results/CI_IGT_test/Patchwork_1419/
> 
> bd0b1a9aa8b7fdb2e06a5cbf1756ef93de2fa3fd drm-intel-nightly: 2016y-
> 02m-16d-17h-53m-05s UTC integration manifest
> d6b61af1225d72afe8e72e8faf1140435266f8e7 drm/i915/fbc: enable FBC by
> default on HSW and BDW
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v6 3/8] drm/i915: Kill off intel_crtc->atomic.wait_vblank, v6.

[Zanoni, Paulo R]

Em Qua, 2016-02-24 às 11:24 +0100, Maarten Lankhorst escreveu:
> Currently we perform our own wait in post_plane_update,
> but the atomic core performs another one in wait_for_vblanks.
> This means that 2 vblanks are done when a fb is changed,
> which is a bit overkill.
> 
> Merge them by creating a helper function that takes a crtc mask
> for the planes to wait on.
> 
> The broadwell vblank workaround may look gone entirely but this is
> not the case. pipe_config->wm_changed is set to true
> when any plane is turned on, which forces a vblank wait.
> 
> Changes since v1:
> - Removing the double vblank wait on broadwell moved to its own
> commit.
> Changes since v2:
> - Move out POWER_DOMAIN_MODESET handling to its own commit.
> Changes since v3:
> - Do not wait for vblank on legacy cursor updates. (Ville)
> - Move broadwell vblank workaround comment to page_flip_finished.
> (Ville)
> Changes since v4:
> - Compile fix, legacy_cursor_flip -> *_update.
> Changes since v5:
> - Kill brackets.
> - Add WARN_ON when wait_for_vblanks fails.
> - Remove extra newlines.
> - Split the checks whether vblank is needed to a separate function,
>   with comments why a vblank is needed.
> Signed-off-by: Maarten Lankhorst 

Reviewed-by: Paulo Zanoni 

> ---
> v5 was skipped, previous version was v5 because it had the compile
> fix.
> 
> diff --git a/drivers/gpu/drm/i915/intel_atomic.c
> b/drivers/gpu/drm/i915/intel_atomic.c
> index 4625f8a9ba12..8e579a8505ac 100644
> --- a/drivers/gpu/drm/i915/intel_atomic.c
> +++ b/drivers/gpu/drm/i915/intel_atomic.c
> @@ -97,6 +97,7 @@ intel_crtc_duplicate_state(struct drm_crtc *crtc)
>   crtc_state->disable_lp_wm = false;
>   crtc_state->disable_cxsr = false;
>   crtc_state->wm_changed = false;
> + crtc_state->fb_changed = false;
>  
>   return &crtc_state->base;
>  }
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 2107e324cd9e..9f32cb0bf978 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -4792,9 +4792,6 @@ static void intel_post_plane_update(struct
> intel_crtc *crtc)
>   to_intel_crtc_state(crtc->base.state);
>   struct drm_device *dev = crtc->base.dev;
>  
> - if (atomic->wait_vblank)
> - intel_wait_for_vblank(dev, crtc->pipe);
> -
>   intel_frontbuffer_flip(dev, atomic->fb_bits);
>  
>   crtc->wm.cxsr_allowed = true;
> @@ -10957,6 +10954,12 @@ static bool page_flip_finished(struct
> intel_crtc *crtc)
>   return true;
>  
>   /*
> +  * BDW signals flip done immediately if the plane
> +  * is disabled, even if the plane enable is already
> +  * armed to occur at the next vblank :(
> +  */
> +
> + /*
>    * A DSPSURFLIVE check isn't enough in case the mmio and CS
> flips
>    * used the same base address. In that case the mmio flip
> might
>    * have completed, but the CS hasn't even executed the flip
> yet.
> @@ -11833,6 +11836,9 @@ int intel_plane_atomic_calc_changes(struct
> drm_crtc_state *crtc_state,
>   if (!was_visible && !visible)
>   return 0;
>  
> + if (fb != old_plane_state->base.fb)
> + pipe_config->fb_changed = true;
> +
>   turn_off = was_visible && (!visible || mode_changed);
>   turn_on = visible && (!was_visible || mode_changed);
>  
> @@ -11847,11 +11853,8 @@ int intel_plane_atomic_calc_changes(struct
> drm_crtc_state *crtc_state,
>   pipe_config->wm_changed = true;
>  
>   /* must disable cxsr around plane enable/disable */
> - if (plane->type != DRM_PLANE_TYPE_CURSOR) {
> - if (is_crtc_enabled)
> - intel_crtc->atomic.wait_vblank =
> true;
> + if (plane->type != DRM_PLANE_TYPE_CURSOR)
>   pipe_config->disable_cxsr = true;
> - }
>   } else if (intel_wm_need_update(plane, plane_state)) {
>   pipe_config->wm_changed = true;
>   }
> @@ -11865,14 +11868,6 @@ int intel_plane_atomic_calc_changes(struct
> drm_crtc_state *crtc_state,
>   intel_crtc->atomic.post_enable_primary = turn_on;
>   intel_crtc->atomic.update_fbc = true;
>  
> - /*
> -  * BDW signals flip done immediately if the plane
> -  * is disabled, even if the plane enable is already
> -  * armed to occur at the next vblank :(
> -  */
> - if (turn_on && IS_BROADWELL(dev))
> - intel_crtc->atomic.wait_vblank = true;
> -
>   break;
>   case DRM_PLANE_TYPE_CURSOR:
>   break;
> @@ -11885,13 +11880,11 @@ int intel_plane_atomic_calc_changes(struct
> drm_crtc_state *crtc_state,
>    */
>   if (IS_IVYBRIDGE(dev) &&
>   needs_scaling(to_intel_plane_state(plane_state))
> &&
> - !needs_scaling(old_plane_state)) {
> -  

Re: [Intel-gfx] [PATCH v4.1 6/8] drm/i915: Nuke fbc members from intel_crtc->atomic, v3.

[Zanoni, Paulo R]

Em Seg, 2016-02-29 às 10:58 +0100, Maarten Lankhorst escreveu:
> Whenever there's an update to the primary plane,
> fbc_pre_update and fbc_post_update are called. Kill off
> intel_crtc->atomic.update_fbc and now that intel_crtc->atomic
> is empty, kill it off too.
> 
> Changes since v1:
> - Add a intel_fbc_supports_rotation helper.
> Changes sinec v2:
> - Remove intel_fbc_supports_rotation_helper.
> - Remove unrelated changes.
> 
> Signed-off-by: Maarten Lankhorst 
> ---
> This version doesn't change intel_fbc_enable any more!

Ok, so I decided to test this.

First of all, patch 05 needs a rebase too. I did my own local rebase
and I suppose I got things right.

Second, after I did actual testing, I discovered that, contrary to my
previous belief, "old_pri_state" will also be valid when we're only
changing the sprite or cursor planes. So if we apply this patch, we'll
be calling pre_update+enable+post_update for every plane/cursor
enable/disable operation, which is not what we want since these are
unnecessary calls, as FBC only deals with the primary plane. I think we
need to fix this.

The tests I've been using to check this were:
- kms_frontbuffer_tracking/fbc-1p-primscrn-cur-indfb-onoff
- kms_frontbuffer_tracking/fbc-1p-primscrn-spr-indfb-onoff


> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 78f72bef25aa..c8404092aee9 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -4789,11 +4789,9 @@ static void intel_post_plane_update(struct
> intel_crtc_state *old_crtc_state)
>  {
>   struct intel_crtc *crtc = to_intel_crtc(old_crtc_state-
> >base.crtc);
>   struct drm_atomic_state *old_state = old_crtc_state-
> >base.state;
> - struct intel_crtc_atomic_commit *atomic = &crtc->atomic;
>   struct intel_crtc_state *pipe_config =
>   to_intel_crtc_state(crtc->base.state);
>   struct drm_device *dev = crtc->base.dev;
> - struct drm_i915_private *dev_priv = dev->dev_private;
>   struct drm_plane *primary = crtc->base.primary;
>   struct drm_plane_state *old_pri_state =
>   drm_atomic_get_existing_plane_state(old_state,
> primary);
> @@ -4805,22 +4803,19 @@ static void intel_post_plane_update(struct
> intel_crtc_state *old_crtc_state)
>   if (pipe_config->wm_changed && pipe_config->base.active)
>   intel_update_watermarks(&crtc->base);
>  
> - if (atomic->update_fbc)
> - intel_fbc_post_update(crtc);
> -
>   if (old_pri_state) {
>   struct intel_plane_state *primary_state =
>   to_intel_plane_state(primary->state);
>   struct intel_plane_state *old_primary_state =
>   to_intel_plane_state(old_pri_state);
>  
> + intel_fbc_post_update(crtc);
> +
>   if (primary_state->visible &&
>   (needs_modeset(&pipe_config->base) ||
>    !old_primary_state->visible))
>   intel_post_enable_primary(&crtc->base);
>   }
> -
> - memset(atomic, 0, sizeof(*atomic));
>  }
>  
>  static void intel_pre_plane_update(struct intel_crtc_state
> *old_crtc_state)
> @@ -4828,7 +4823,6 @@ static void intel_pre_plane_update(struct
> intel_crtc_state *old_crtc_state)
>   struct intel_crtc *crtc = to_intel_crtc(old_crtc_state-
> >base.crtc);
>   struct drm_device *dev = crtc->base.dev;
>   struct drm_i915_private *dev_priv = dev->dev_private;
> - struct intel_crtc_atomic_commit *atomic = &crtc->atomic;
>   struct intel_crtc_state *pipe_config =
>   to_intel_crtc_state(crtc->base.state);
>   struct drm_atomic_state *old_state = old_crtc_state-
> >base.state;
> @@ -4837,15 +4831,14 @@ static void intel_pre_plane_update(struct
> intel_crtc_state *old_crtc_state)
>   drm_atomic_get_existing_plane_state(old_state,
> primary);
>   bool modeset = needs_modeset(&pipe_config->base);
>  
> - if (atomic->update_fbc)
> - intel_fbc_pre_update(crtc);
> -
>   if (old_pri_state) {
>   struct intel_plane_state *primary_state =
>   to_intel_plane_state(primary->state);
>   struct intel_plane_state *old_primary_state =
>   to_intel_plane_state(old_pri_state);
>  
> + intel_fbc_pre_update(crtc);
> +
>   if (old_primary_state->visible &&
>   (modeset || !primary_state->visible))
>   intel_pre_disable_primary(&crtc->base);
> @@ -11877,27 +11870,17 @@ int intel_plane_atomic_calc_changes(struct
> drm_crtc_state *crtc_state,
>   if (visible || was_visible)
>   pipe_config->fb_bits |= to_intel_plane(plane)-
> >frontbuffer_bit;
>  
> - switch (plane->type) {
> - case DRM_PLANE_TYPE_PRIMARY:
> - intel_crtc->atomic.update_fbc = true;
> -
> - break;
> - case DRM_PLANE_TYPE_CURSOR:
> - brea

Re: [Intel-gfx] [PATCH v1.1 1/2] drm/i915: Allow preservation of watermarks, v2.

[Zanoni, Paulo R]

Em Qua, 2016-03-02 às 12:38 +0100, Maarten Lankhorst escreveu:
> As Paulo has noted we can help bisectability by separating computing
> watermarks on a noop in 2 separate commits.
> 
> This patch no longer clears the crtc watermark state, but
> recalculates
> it completely. Regardless whether a level is used the full values for
> each level are calculated. If a level is invalid wm[level].enable is
> unset.
> 
> Changes since v1:
> - Only call ilk_validate_wm_level when level <= usable_level.

LGTM.

Reviewed-by: Paulo Zanoni 

> 
> Signed-off-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/i915/intel_pm.c | 23 +--
>  1 file changed, 13 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c
> b/drivers/gpu/drm/i915/intel_pm.c
> index 61dcac9dea37..4c21b98e5a5c 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -2300,7 +2300,7 @@ static int ilk_compute_pipe_wm(struct
> intel_crtc *intel_crtc,
>   struct intel_plane_state *pristate = NULL;
>   struct intel_plane_state *sprstate = NULL;
>   struct intel_plane_state *curstate = NULL;
> - int level, max_level = ilk_wm_max_level(dev);
> + int level, max_level = ilk_wm_max_level(dev), usable_level;
>   struct ilk_wm_maximums max;
>  
>   cstate = intel_atomic_get_crtc_state(state, intel_crtc);
> @@ -2308,7 +2308,6 @@ static int ilk_compute_pipe_wm(struct
> intel_crtc *intel_crtc,
>   return PTR_ERR(cstate);
>  
>   pipe_wm = &cstate->wm.optimal.ilk;
> - memset(pipe_wm, 0, sizeof(*pipe_wm));
>  
>   for_each_intel_plane_on_crtc(dev, intel_crtc, intel_plane) {
>   ps = drm_atomic_get_plane_state(state,
> @@ -2330,13 +2329,15 @@ static int ilk_compute_pipe_wm(struct
> intel_crtc *intel_crtc,
>   (drm_rect_width(&sprstate->dst) !=
> drm_rect_width(&sprstate->src) >> 16 ||
>   drm_rect_height(&sprstate->dst) !=
> drm_rect_height(&sprstate->src) >> 16);
>  
> + usable_level = max_level;
> +
>   /* ILK/SNB: LP2+ watermarks only w/o sprites */
>   if (INTEL_INFO(dev)->gen <= 6 && sprstate->visible)
> - max_level = 1;
> + usable_level = 1;
>  
>   /* ILK/SNB/IVB: LP1+ watermarks only w/o scaling */
>   if (pipe_wm->sprites_scaled)
> - max_level = 0;
> + usable_level = 0;
>  
>   ilk_compute_wm_level(dev_priv, intel_crtc, 0, cstate,
>    pristate, sprstate, curstate, &pipe_wm-
> >wm[0]);
> @@ -2350,20 +2351,22 @@ static int ilk_compute_pipe_wm(struct
> intel_crtc *intel_crtc,
>   ilk_compute_wm_reg_maximums(dev, 1, &max);
>  
>   for (level = 1; level <= max_level; level++) {
> - struct intel_wm_level wm = {};
> + struct intel_wm_level *wm = &pipe_wm->wm[level];
>  
>   ilk_compute_wm_level(dev_priv, intel_crtc, level,
> cstate,
> -  pristate, sprstate, curstate,
> &wm);
> +  pristate, sprstate, curstate,
> wm);
>  
>   /*
>    * Disable any watermark level that exceeds the
>    * register maximums since such watermarks are
>    * always invalid.
>    */
> - if (!ilk_validate_wm_level(level, &max, &wm))
> - break;
> -
> - pipe_wm->wm[level] = wm;
> + if (level > usable_level) {
> + wm->enable = false;
> + } else if (!ilk_validate_wm_level(level, &max, wm))
> {
> + wm->enable = false;
> + usable_level = level;
> + }
>   }
>  
>   return 0;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Only recalculate wm's for planes part of the state, v2.

[Zanoni, Paulo R]

Em Ter, 2016-03-01 às 14:28 -0800, Matt Roper escreveu:
> On Tue, Mar 01, 2016 at 11:07:22AM +0100, Maarten Lankhorst wrote:
> > Only planes that are part of the state should be used for
> > recalculating
> > watermarks. For planes not part of the state the previous patch
> > allows
> > us to re-use the old values since they're calculated even for
> > levels
> > that are not actively used.
> > 
> > Changes since v1:
> > - Remove big if from intel_crtc_atomic_check.
> > - Remove extra newline.
> > - Remove memset in ilk_compute_pipe_wm.
> > 
> > Signed-off-by: Maarten Lankhorst  > >
> > Cc: Matt Roper 
> 
> I haven't thought through this too carefully yet, but off the top of
> my
> head I'm not sure if this will work for SKL once we transition it to
> also use a more atomic style.  Changes to other state might result in
> changes to DDB allocation, making our previously-calculated values
> invalid.
> 
> I think this is okay for the current code (where only ILK is atomic),
> so
> 
> Acknowledged-by: Matt Roper 
> 
> for the time being.  I'll be back to looking at SKL-style watermarks
> in
> the next day or two and I might have to backtrack somewhat in cases
> where a DDB partitioning changes results in a full recompute, but I
> need
> to think through the details a bit more about how best to handle
> that.

I spent some time looking at that early return from invalid pipe
watermarks, but I suppose that return means we'll completely discard
anything just computed by the function, right?

The patch seems to do what it says on the box, so if we assume we
actually want the patch:
Reviewed-by: Paulo Zanoni 

I'll let you and Matt decide whether we actually want the patch or not.



> Matt
> 
> 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.h  |  3 +-
> >  drivers/gpu/drm/i915/intel_display.c |  2 +-
> >  drivers/gpu/drm/i915/intel_drv.h | 12 
> >  drivers/gpu/drm/i915/intel_pm.c  | 59 --
> > --
> >  4 files changed, 47 insertions(+), 29 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 671295523317..4b8f446cdf44 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -629,8 +629,7 @@ struct drm_i915_display_funcs {
> >       int target, int refclk,
> >       struct dpll *match_clock,
> >       struct dpll *best_clock);
> > -   int (*compute_pipe_wm)(struct intel_crtc *crtc,
> > -      struct drm_atomic_state *state);
> > +   int (*compute_pipe_wm)(struct intel_crtc_state *cstate);
> >     int (*compute_intermediate_wm)(struct drm_device *dev,
> >        struct intel_crtc
> > *intel_crtc,
> >        struct intel_crtc_state
> > *newstate);
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 79bf527e0a73..20a4cb3f69d1 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -11994,7 +11994,7 @@ static int intel_crtc_atomic_check(struct
> > drm_crtc *crtc,
> >  
> >     ret = 0;
> >     if (dev_priv->display.compute_pipe_wm) {
> > -   ret = dev_priv-
> > >display.compute_pipe_wm(intel_crtc, state);
> > +   ret = dev_priv-
> > >display.compute_pipe_wm(pipe_config);
> >     if (ret) {
> >     DRM_DEBUG_KMS("Target pipe watermarks are
> > invalid\n");
> >     return ret;
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index 5daf53c080e1..03b7d031e910 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -1630,6 +1630,18 @@ intel_atomic_get_crtc_state(struct
> > drm_atomic_state *state,
> >  
> >     return to_intel_crtc_state(crtc_state);
> >  }
> > +
> > +static inline struct intel_plane_state *
> > +intel_atomic_get_existing_plane_state(struct drm_atomic_state
> > *state,
> > +     struct intel_plane *plane)
> > +{
> > +   struct drm_plane_state *plane_state;
> > +
> > +   plane_state = drm_atomic_get_existing_plane_state(state,
> > &plane->base);
> > +
> > +   return to_intel_plane_state(plane_state);
> > +}
> > +
> >  int intel_atomic_setup_scalers(struct drm_device *dev,
> >     struct intel_crtc *intel_crtc,
> >     struct intel_crtc_state *crtc_state);
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index 1b8ba777d2b3..dc1e1683f4a3 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -1996,11 +1996,18 @@ static void ilk_compute_wm_level(const
> > struct drm_i915_private *dev_priv,
> >     cur_latency *= 5;
> >     }
> >  
> > -   result->pri_val = ilk_compute_pri_wm(cstate, pristate,
> > -    pri_latency, level);
> > -   result->s

Re: [Intel-gfx] [PATCH i-g-t] kms_frontbuffer_tracking: Remove hardcoded PIPE_A

[Zanoni, Paulo R]

Em Sex, 2016-03-04 às 12:02 +0200, Gabriel Feceoru escreveu:
> Use the pipe which is given from the possible_crcs for that connected
> port
> instead.
> 
> On BSW there are constrains for the crtc<-->connector, this fix make
> this test
> passing on BSW.
> 
> Signed-off-by: Gabriel Feceoru 

Patch pushed. Thanks for catching this!

> ---
>  tests/kms_frontbuffer_tracking.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/tests/kms_frontbuffer_tracking.c
> b/tests/kms_frontbuffer_tracking.c
> index 634c98b..afdb394 100644
> --- a/tests/kms_frontbuffer_tracking.c
> +++ b/tests/kms_frontbuffer_tracking.c
> @@ -1432,7 +1432,8 @@ static void setup_crcs(void)
>  {
>   enum pixel_format f;
>  
> - pipe_crc = igt_pipe_crc_new(0, INTEL_PIPE_CRC_SOURCE_AUTO);
> + int crtc_idx = kmstest_get_crtc_idx(drm.res,
> prim_mode_params.crtc_id);
> + pipe_crc = igt_pipe_crc_new(crtc_idx,
> INTEL_PIPE_CRC_SOURCE_AUTO);
>  
>   setup_sink_crc();
>  
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Nuke fbc members from intel_crtc->atomic, v4.

[Zanoni, Paulo R]

Em Qua, 2016-03-09 às 10:35 +0100, Maarten Lankhorst escreveu:
> Whenever there's an update to the primary plane,
> fbc_pre_update and fbc_post_update are called. Kill off
> intel_crtc->atomic.update_fbc and now that intel_crtc->atomic
> is empty, kill it off too.
> 
> Changes since v1:
> - Add a intel_fbc_supports_rotation helper.
> Changes since v2:
> - Remove intel_fbc_supports_rotation_helper.
> - Remove unrelated changes.
> Changes since v3:
> - Rebase
> 
> Signed-off-by: Maarten Lankhorst 

Looks like the WM fixes indeed solved the problems I pointed in my
previous review, so:

Reviewed-by: Paulo Zanoni 

> ---
>  drivers/gpu/drm/i915/intel_display.c | 51 +++---
> --
>  drivers/gpu/drm/i915/intel_drv.h | 15 ---
>  2 files changed, 16 insertions(+), 50 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 2d31755608ce..6e6d8b342517 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -4912,11 +4912,9 @@ static void intel_post_plane_update(struct
> intel_crtc_state *old_crtc_state)
>  {
>   struct intel_crtc *crtc = to_intel_crtc(old_crtc_state-
> >base.crtc);
>   struct drm_atomic_state *old_state = old_crtc_state-
> >base.state;
> - struct intel_crtc_atomic_commit *atomic = &crtc->atomic;
>   struct intel_crtc_state *pipe_config =
>   to_intel_crtc_state(crtc->base.state);
>   struct drm_device *dev = crtc->base.dev;
> - struct drm_i915_private *dev_priv = dev->dev_private;
>   struct drm_plane *primary = crtc->base.primary;
>   struct drm_plane_state *old_pri_state =
>   drm_atomic_get_existing_plane_state(old_state,
> primary);
> @@ -4928,22 +4926,19 @@ static void intel_post_plane_update(struct
> intel_crtc_state *old_crtc_state)
>   if (pipe_config->wm_changed && pipe_config->base.active)
>   intel_update_watermarks(&crtc->base);
>  
> - if (atomic->update_fbc)
> - intel_fbc_post_update(crtc);
> -
>   if (old_pri_state) {
>   struct intel_plane_state *primary_state =
>   to_intel_plane_state(primary->state);
>   struct intel_plane_state *old_primary_state =
>   to_intel_plane_state(old_pri_state);
>  
> + intel_fbc_post_update(crtc);
> +
>   if (primary_state->visible &&
>   (needs_modeset(&pipe_config->base) ||
>    !old_primary_state->visible))
>   intel_post_enable_primary(&crtc->base);
>   }
> -
> - memset(atomic, 0, sizeof(*atomic));
>  }
>  
>  static void intel_pre_plane_update(struct intel_crtc_state
> *old_crtc_state)
> @@ -4951,7 +4946,6 @@ static void intel_pre_plane_update(struct
> intel_crtc_state *old_crtc_state)
>   struct intel_crtc *crtc = to_intel_crtc(old_crtc_state-
> >base.crtc);
>   struct drm_device *dev = crtc->base.dev;
>   struct drm_i915_private *dev_priv = dev->dev_private;
> - struct intel_crtc_atomic_commit *atomic = &crtc->atomic;
>   struct intel_crtc_state *pipe_config =
>   to_intel_crtc_state(crtc->base.state);
>   struct drm_atomic_state *old_state = old_crtc_state-
> >base.state;
> @@ -4960,15 +4954,14 @@ static void intel_pre_plane_update(struct
> intel_crtc_state *old_crtc_state)
>   drm_atomic_get_existing_plane_state(old_state,
> primary);
>   bool modeset = needs_modeset(&pipe_config->base);
>  
> - if (atomic->update_fbc)
> - intel_fbc_pre_update(crtc);
> -
>   if (old_pri_state) {
>   struct intel_plane_state *primary_state =
>   to_intel_plane_state(primary->state);
>   struct intel_plane_state *old_primary_state =
>   to_intel_plane_state(old_pri_state);
>  
> + intel_fbc_pre_update(crtc);
> +
>   if (old_primary_state->visible &&
>   (modeset || !primary_state->visible))
>   intel_pre_disable_primary(&crtc->base);
> @@ -12027,27 +12020,17 @@ int intel_plane_atomic_calc_changes(struct
> drm_crtc_state *crtc_state,
>   if (visible || was_visible)
>   pipe_config->fb_bits |= to_intel_plane(plane)-
> >frontbuffer_bit;
>  
> - switch (plane->type) {
> - case DRM_PLANE_TYPE_PRIMARY:
> - intel_crtc->atomic.update_fbc = true;
> -
> - break;
> - case DRM_PLANE_TYPE_CURSOR:
> - break;
> - case DRM_PLANE_TYPE_OVERLAY:
> - /*
> -  * WaCxSRDisabledForSpriteScaling:ivb
> -  *
> -  * cstate->update_wm was already set above, so this
> flag will
> -  * take effect when we commit and program
> watermarks.
> -  */
> - if (IS_IVYBRIDGE(dev) &&
> - needs_scaling(to_intel_plane_state(plane_state))
> &&
> - !needs_s

Re: [Intel-gfx] [PATCH v7 0/8] GEN-9 Arbitrated Bandwidth WM WA's & IPC

[Zanoni, Paulo R]

Em Qui, 2016-12-08 às 17:00 +0100, Daniel Vetter escreveu:
> On Wed, Dec 07, 2016 at 05:35:09PM -0200, Paulo Zanoni wrote:
> > 
> > Em Qui, 2016-12-01 às 21:19 +0530, Mahesh Kumar escreveu:
> > > 
> > > This series implements following set of functionality
> > >   Implement IPC WA's for Broxton/KBL
> > >   Enable IPC in supported platforms
> > >   Convert WM calculation to fixed point calculation
> > >   Calculation of System memory Bandwidth for SKL/KBL/BXT
> > >   Implementation of Arbitrated memory Bandwidth related WM WA's
> > 
> > Pushed patches 1, 2, 3, 5 and 6, with small bikesheds applied.
> > Thanks
> > for the patches!
> > 
> > (actually I had a little problem with dim, so right now only dinq
> > has
> > the patches, drm-tip doesn't, soon they will appear)
> 
> Hm, what did go boom with dim?

This was my first commit/push since the change. I had followed the
instructions on your email (including the dim setup stage), and then
when I did "dim push-queued" it complained that I didn't have the audio
remotes in my tree. After the error message I was not sure what was the
correct way to proceed.

I suppose we could change dim setup so that it really adds every single
remote that's needed? Also, why doesn't it just add the remotes itself?

>  If the pushing worked, then you can re-run
> just the drm-tip rebuilding with
> 
> $ dim rebuild-tip

Good to know, thanks for that.

> 
> Might also be worth it to upgrade to latest dim, we've dropped a few
> bugfixes in the branch push/pull logic in a few places since the big
> conversion, you might hit them.

I always upgrade to the latest version before using it.

> 
> If all this doesn't help, pls ping me on irc with a pastebin of
> what's
> going on. For testing you can always run

I sent you an email yesterday with the error message pasted... Maybe
you'll find it soon :).


> 
> $ dim pq
> 
> To repush dinq - dim will complain if you'll do a non-ff push and
> abort,
> so it's safe.
> -Daniel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t 1/2] kms_pipe_crc_basic: Only test one pipe in the basic set

[Zanoni, Paulo R]

Em Seg, 2016-04-25 às 10:45 +0100, Tvrtko Ursulin escreveu:
> On 25/04/16 09:51, Daniel Vetter wrote:
> > 
> > On Fri, Apr 22, 2016 at 04:11:11PM +0100, Chris Wilson wrote:
> > > 
> > > On Fri, Apr 22, 2016 at 03:41:55PM +0100, Tvrtko Ursulin wrote:
> > > > 
> > > > From: Tvrtko Ursulin 
> > > > 
> > > > I would argue it is enough to test one pipe in the BAT set.
> > > > 
> > > > Signed-off-by: Tvrtko Ursulin 
> > > > ---
> > > >   tests/kms_pipe_crc_basic.c | 23 +--
> > > >   1 file changed, 13 insertions(+), 10 deletions(-)
> > > > 
> > > > diff --git a/tests/kms_pipe_crc_basic.c
> > > > b/tests/kms_pipe_crc_basic.c
> > > > index 4de53bc77a3a..291775934758 100644
> > > > --- a/tests/kms_pipe_crc_basic.c
> > > > +++ b/tests/kms_pipe_crc_basic.c
> > > > @@ -180,6 +180,9 @@ static void test_read_crc(data_t *data, int
> > > > pipe, unsigned flags)
> > > > 
> > > >   data_t data = {0, };
> > > > 
> > > > +#define test_prefix(i) ((i) == 0 ? "basic-" : "")
> > > > +#define pipe_name(i) ((i) + 'A')
> > > > +
> > > >   igt_main
> > > >   {
> > > >     igt_skip_on_simulation();
> > > > @@ -196,39 +199,39 @@ igt_main
> > > >     igt_display_init(&data.display, data.drm_fd);
> > > >     }
> > > > 
> > > > -   igt_subtest("bad-pipe")
> > > > +   igt_subtest("basic-bad-pipe")
> > > >     test_bad_command(&data, "pipe D none");
> > > > 
> > > > -   igt_subtest("bad-source")
> > > > +   igt_subtest("basic-bad-source")
> > > >     test_bad_command(&data, "pipe A foo");
> > > > 
> > > > -   igt_subtest("bad-nb-words-1")
> > > > +   igt_subtest("basic-bad-nb-words-1")
> > > >     test_bad_command(&data, "pipe foo");
> > > > 
> > > > -   igt_subtest("bad-nb-words-3")
> > > > +   igt_subtest("basic-bad-nb-words-3")
> > > >     test_bad_command(&data, "pipe A none
> > > > option");
> > > > 
> > > >     for (int i = 0; i < 3; i++) {
> > > > -   igt_subtest_f("read-crc-pipe-%c", 'A'+i)
> > > > +   igt_subtest_f("%sread-crc-pipe-%c",
> > > > test_prefix(i), pipe_name(i))
> > > So the CRC is the backchannel through which we measure the output
> > > on the
> > > screen matches expectations. Do any of the following belong in
> > > the basic
> > > test set? Having demonstrated that the CRC is functional, all the
> > > rest
> > > are components of other tests - and if a bug if found in any of
> > > the
> > > other basic tests, one can run the entire kms_pipe_crc to sanity
> > > check
> > > the test suite itself.
> > The reason I wanted to include kms_pipe_crc_basic was not to
> > validate the
> > kernel driver (it's a side-effect), but to make sure the CRC
> > support is
> > really stable. Otherwise we can't rely on a full BAT run at all.
> Okay, so these patches are more about defining on what full BAT is,
> not 
> trying to break full BAT.
> 
> > 
> > And yes every single subtest (including testing on all the pipes)
> > included
> > in there is for a bug in the CRC code that actually happened.
> > 
> > I know that we're not there yet with CI, and we don't yet run all
> > the nice
> > kms_*crc tests we have. But imo this is crucial prep work for that,
> > and
> > we really shouldn't reduce test coverage in this area. Same reason
> > we have
> > 1 edp sink crc testcase, essentially it's to make sure that we have
> > a
> > reasonable basis to run the full test set.
> > 
> > Imo BAT should guarantee two things:
> > - no insta-fireworks
> > - all the validation stuff actually works and running more tests
> > will give
> >    you valid results
> > 
> > From the above reasons I'm against this patch.
> My general idea was that the per-patch BAT (todays basic set) could
> get 
> away with running on one pipe, and then the overnight one (which we
> do 
> not have yet) would run the more extensive set.
> 
> So even if BAT runs everything on pipe A, it is still self-
> validating. 
> It is not that some tests would run on pipe A and some on all pipes, 
> that at least was the idea.
> 
> Motivation simply was that the current BAT run did 80 backlight on-
> off 
> cycles on my BDW RVP and just waiting for eDP to turn on 80 times
> takes 
> ~50 seconds in total. The test runtime was around eight minutes here.
> 
> When I turned off legacy fbdev that went to ~4 minutes. And then
> with 
> these two (and other two) patches I shaved off 1-2 minute more.

One of the things about our driver is that it tries to be very very
conservative regarding the eDP timings, leading to waits longer than
necessary for pretty much everyone. We tried to optimize this in the
past, but due to the fact that we have a single code base to support
every product released since gen 2, pretty much any sort of
optimization attempt tends to break someone's machine because maybe
they have a bad BIOS or a bad VBT or a bad panel or something else. Now
that this problem is impacting our ability to run tests, maybe it is
time to start th

Re: [Intel-gfx] [PATCH 07/12] drm/i915: Add and initialize lspcon connector

[Zanoni, Paulo R]

Em Seg, 2016-04-04 às 17:31 +0530, Shashank Sharma escreveu:
> lspcon is a device which acts as DP in some cases
> and as HDMI in some. Here is how:
> - lspcon needs DP(aux) for all the i2c_ove_aux read/write
>   transitions so it needs to have some DP level initializations
> - lspcon is detected by userspace/sink as HDMI device, so
>   it needs to be detectd as HDMI device.
> 
> This patch adds a custom connector for lspcon device, which
> can pick and chose what it wants from existing functionality.
> 
> This patch also adds functions to initialize dp and hdmi connectors
> and structures to the minimum required levels, and then play around.

Hi

I realized I only said this in private discussions, but never in the
mailing list, so let's bring it to the list so more people can join:

My problem with this approach of adding a new connector is the amount
of duplicated code it brings. Considering our constant never-ending
code churn, added with the current plans to rework major pieces of the
DP code, I would estimate that this lspcon connector code would very
quickly get out-of-sync and, as a consequence, broken, due to the fact
that it's very likely that someone would forget to patch the lspcon
connector during reworks of DP/HDMI connectors. So my current
suggestion would be to just add the necessary LSPCON bits to the HDMI
and DP detection functions instead of adding a whole new connector.
Maybe we could even merge/integrate the DP and HDMI connector functions
since in the end both functions are probing the same port, and if one
connector is found, the other connector is certainly not present.

I can also provide are more technical lower-level review of the code
itself, but I think we should focus the discussion in the high level
design for now.

Thanks,
Paulo

> 
> Signed-off-by: Shashank Sharma 
> ---
>  drivers/gpu/drm/i915/intel_dp.c | 31 +++
>  drivers/gpu/drm/i915/intel_drv.h|  4 ++
>  drivers/gpu/drm/i915/intel_hdmi.c   | 17 
>  drivers/gpu/drm/i915/intel_lspcon.c | 79
> +
>  4 files changed, 131 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c
> b/drivers/gpu/drm/i915/intel_dp.c
> index ba4da0c..f3df1c6 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -5900,6 +5900,37 @@ fail:
>   return false;
>  }
>  
> +int intel_dp_init_minimum(struct intel_digital_port *intel_dig_port,
> + struct intel_connector *intel_connector)
> +{
> + int ret;
> + enum port port = intel_dig_port->port;
> + struct intel_dp *intel_dp = &intel_dig_port->dp;
> + struct drm_device *dev = intel_dig_port->base.base.dev;
> + struct drm_i915_private *dev_priv = dev->dev_private;
> +
> + intel_dig_port->dp.output_reg = DDI_BUF_CTL(port);
> + if (WARN(intel_dig_port->max_lanes < 1,
> +  "Not enough lanes (%d) for DP on port %c\n",
> +  intel_dig_port->max_lanes, port_name(port)))
> + return -EINVAL;
> +
> + intel_dp->pps_pipe = INVALID_PIPE;
> + intel_dp->get_aux_clock_divider = skl_get_aux_clock_divider;
> + intel_dp->get_aux_send_ctl = skl_get_aux_send_ctl;
> + intel_dp->prepare_link_retrain =
> intel_ddi_prepare_link_retrain;
> + intel_dp->DP = I915_READ(intel_dp->output_reg);
> + intel_dp->attached_connector = intel_connector;
> + INIT_DELAYED_WORK(&intel_dp->panel_vdd_work,
> +   edp_panel_vdd_work);
> +
> + ret = intel_dp_aux_init(intel_dp, intel_connector);
> + if (ret)
> + DRM_ERROR("Aux init for LSPCON failed\n");
> +
> + return ret;
> +}
> +
>  void
>  intel_dp_init(struct drm_device *dev,
>     i915_reg_t output_reg, enum port port)
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 6e309ea..d38db7d 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1332,6 +1332,8 @@ void intel_dp_compute_rate(struct intel_dp
> *intel_dp, int port_clock,
>  bool intel_dp_source_supports_hbr2(struct intel_dp *intel_dp);
>  bool
>  intel_dp_get_link_status(struct intel_dp *intel_dp, uint8_t
> link_status[DP_LINK_STATUS_SIZE]);
> +int intel_dp_init_minimum(struct intel_digital_port *intel_dig_port,
> + struct intel_connector *intel_connector);
>  
>  /* intel_dp_mst.c */
>  int intel_dp_mst_encoder_init(struct intel_digital_port
> *intel_dig_port, int conn_id);
> @@ -1397,6 +1399,8 @@ void intel_fbc_cleanup_cfb(struct
> drm_i915_private *dev_priv);
>  void intel_hdmi_init(struct drm_device *dev, i915_reg_t hdmi_reg,
> enum port port);
>  void intel_hdmi_init_connector(struct intel_digital_port
> *intel_dig_port,
>      struct intel_connector
> *intel_connector);
> +int intel_hdmi_init_minimum(struct intel_digital_port
> *intel_dig_port,
> + struct intel_connector
> *intel_connector);
>  struct intel_hdmi *enc_to_intel_hdmi(stru

Re: [Intel-gfx] [PATCH 10/12] drm/i915: Add lspcon core functions

[Zanoni, Paulo R]

Em Ter, 2016-05-03 às 21:44 +0530, Sharma, Shashank escreveu:
> 
> On 5/3/2016 9:39 PM, Ville Syrjälä wrote:
> > 
> > On Tue, May 03, 2016 at 09:18:49PM +0530, Sharma, Shashank wrote:
> > > 
> > > Regards
> > > Shashank
> > > 
> > > On 5/2/2016 7:21 PM, Ville Syrjälä wrote:
> > > > 
> > > > On Mon, Apr 04, 2016 at 05:31:46PM +0530, Shashank Sharma
> > > > wrote:
> > > > > 
> > > > > This patch adds lspcon's internal functions, which work
> > > > > on the probe layer, and indicate the working status of
> > > > > lspcon, which are mostly:
> > > > > 
> > > > > probe: A lspcon device is probed only once, during boot
> > > > > time, as its always present with the device, next to port.
> > > > > So the i2c_over_aux channel is alwyas read/writeable if DC is
> > > > > powered on. If VBT says that this port contains lspcon, we
> > > > > check and probe the HW to verify and initialize it.
> > > > > 
> > > > > get_mode: This function indicates the current mode of
> > > > > operation
> > > > > of lspcon (ls or pcon mode)
> > > > > 
> > > > > change_mode: This function can change the lspcon's mode of
> > > > > operation to desired mode.
> > > > > 
> > > > > Signed-off-by: Shashank Sharma 
> > > > > Signed-off-by: Akashdeep Sharma 
> > > > > ---
> > > > >    drivers/gpu/drm/i915/intel_lspcon.c | 145
> > > > > 
> > > > >    1 file changed, 145 insertions(+)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/i915/intel_lspcon.c
> > > > > b/drivers/gpu/drm/i915/intel_lspcon.c
> > > > > index c3c1cd2..617fe3f 100644
> > > > > --- a/drivers/gpu/drm/i915/intel_lspcon.c
> > > > > +++ b/drivers/gpu/drm/i915/intel_lspcon.c
> > > > > @@ -61,6 +61,144 @@ static struct intel_lspcon
> > > > >       return
> > > > > enc_to_lspcon(&intel_attached_encoder(connector)->base);
> > > > >    }
> > > > > 
> > > > > +enum lspcon_mode lspcon_get_current_mode(struct intel_lspcon
> > > > > *lspcon)
> > > > > +{
> > > > > + u8 data;
> > > > > + int err = 0;
> > > > > + struct intel_digital_port *dig_port =
> > > > > lspcon_to_dig_port(lspcon);
> > > > > + struct i2c_adapter *adapter = &dig_port->dp.aux.ddc;
> > > > > +
> > > > > + /* Read Status: i2c over aux */
> > > > > + err = drm_dp_dual_mode_ioa_read(adapter, &data,
> > > > > + LSPCON_MODE_CHECK_OFFSET, sizeof(data));
> > > > > + if (err < 0) {
> > > > > + DRM_ERROR("LSPCON read mode ioa (0x80, 0x41)
> > > > > failed\n");
> > > > > + return lspcon_mode_invalid;
> > > > > + }
> > > > > +
> > > > > + DRM_DEBUG_DRIVER("LSPCON mode (0x80, 0x41) = %x\n",
> > > > > (unsigned int)data);
> > > > > + return data & LSPCON_MODE_MASK ? lspcon_mode_pcon :
> > > > > lspcon_mode_ls;
> > > > > +}
> > > > > +
> > > > > +int lspcon_change_mode(struct intel_lspcon *lspcon,
> > > > > + enum lspcon_mode mode, bool force)
> > > > > +{
> > > > > + u8 data;
> > > > > + int err;
> > > > > + int time_out = 200;
> > > > > + enum lspcon_mode current_mode;
> > > > > + struct intel_digital_port *dig_port =
> > > > > lspcon_to_dig_port(lspcon);
> > > > > +
> > > > > + current_mode = lspcon_get_current_mode(lspcon);
> > > > > + if (current_mode == lspcon_mode_invalid) {
> > > > > + DRM_ERROR("Failed to get current LSPCON
> > > > > mode\n");
> > > > > + return -EFAULT;
> > > > > + }
> > > > > +
> > > > > + if (current_mode == mode && !force) {
> > > > > + DRM_DEBUG_DRIVER("Current mode = desired
> > > > > LSPCON mode\n");
> > > > > + return 0;
> > > > > + }
> > > > > +
> > > > > + if (mode == lspcon_mode_ls)
> > > > > + data = ~LSPCON_MODE_MASK;
> > > > > + else
> > > > > + data = LSPCON_MODE_MASK;
> > > > > +
> > > > > + /* Change mode */
> > > > > + err = drm_dp_dual_mode_ioa_write(&dig_port-
> > > > > >dp.aux.ddc, &data,
> > > > > + LSPCON_MODE_CHANGE_OFFSET,
> > > > > sizeof(data));
> > > > > + if (err < 0) {
> > > > > + DRM_ERROR("LSPCON mode change failed\n");
> > > > > + return err;
> > > > > + }
> > > > > +
> > > > > + /*
> > > > > + * Confirm mode change by reading the status bit.
> > > > > + * Sometimes, it takes a while to change the mode,
> > > > > + * so wait and retry until time out or done.
> > > > > + */
> > > > > + while (time_out) {
> > > > > + current_mode =
> > > > > lspcon_get_current_mode(lspcon);
> > > > > + if (current_mode != mode) {
> > > > > + mdelay(10);
> > > > > + time_out -= 10;
> > > > > + } else {
> > > > > + lspcon->mode_of_op = mode;
> > > > > + DRM_DEBUG_DRIVER("LSPCON mode
> > > > > changed to %s\n",
> > > > > + mode == lspcon_mode_ls ?
> > > > > "LS" : "PCON");
> > > > > + return 0;
> > > > > + }
> > 

Re: [Intel-gfx] Regression of v4.6-rc vs. v4.5 bisected: a98ee79317b4 "drm/i915/fbc: enable FBC by default on HSW and BDW"

[Zanoni, Paulo R]

Em Qui, 2016-05-05 às 19:45 +0200, Stefan Richter escreveu:
> On Apr 30 Stefan Richter wrote:
> > 
> > On Apr 29 Stefan Richter wrote:
> > > 
> > > On Apr 26 Stefan Richter wrote:  
> > > > 
> > > > v4.6-rc solidly hangs after a short while after boot, login to
> > > > X11, and
> > > > doing nothing much remarkable on the just brought up X desktop.
> > > > 
> > > > Hardware: x86-64, E3-1245 v3 (Haswell),
> > > >   mainboard Supermicro X10SAE,
> > > >   using integrated Intel graphics (HD P4600, i915
> > > > driver),
> > > >   C226 PCH's AHCI and USB 2/3, ASMedia ASM1062 AHCI,
> > > >   Intel LAN (i217, igb driver),
> > > >   several IEEE 1394 controllers, some of them behind
> > > >   PCIe bridges (IDT, PLX) or PCIe-to-PCI bridges (TI,
> > > > Tundra)
> > > >   and one PCI-to-CardBus bridge (Ricoh)
> > > > 
> > > > kernel.org kernel, Gentoo Linux userland
> > > > 
> > > > 1. known good:  v4.5-rc5 (gcc 4.9.3)
> > > >    known bad:   v4.6-rc2 (gcc 4.9.3), only tried one time
> > > > 
> > > > 2. known good:  v4.5.2 (gcc 5.2.0)
> > > >    known bad:   v4.6-rc5 (gcc 5.2.0), only tried one time
> > > > 
> > > > I will send my linux-4.6-rc5/.config in a follow-up message.  
> >  .config: http://www.spinics.net/lists/kernel/msg2243444.html
> >    lspci: http://www.spinics.net/lists/kernel/msg2243447.html
> > 
> > Some userland package versions, in case these have any bearing:
> > x11-base/xorg-drivers-1.17
> > x11-base/xorg-server-1.17.4
> > x11-bas/xorg-x11-7.4-r2
> Furthermore, there is a single display hooked up via DisplayPort.
> 
> > 
> > > 
> > > After it proved impossible to capture an oops through netconsole,
> > > I
> > > started git bisect.  This will apparently take almost a week, as
> > > git
> > > estimated 13 bisection steps and I will be allowing about 12
> > > hours of
> > > uptime as a sign for a good kernel.  (In my four or five tests of
> > > bad
> > > kernels before I started bisection, they hung after 3
> > > minutes...5.5 hours
> > > uptime, with no discernible difference in workload.  Maybe 12 h
> > > cutoff is
> > > even too short...)  
> I took at least 18 hours uptime (usually 24 hours) as a sign for good
> kernels.  During the bisection, bad kernels hung after 3 h, 2 h, 9
> min,
> 45 min, and 4 min uptime.  Thus I arrived at a98ee79317b4
> "drm/i915/fbc:
> enable FBC by default on HSW and BDW" as the point where the hangs
> are
> introduced.
> 
> Quoting the changelog of the commit:

Thanks for following the instructions on the commit message! :)

> 
> Oh, and in case you - the person reading this commit message -
> found
> this commit through git bisect, please do the following:
>  - Check your dmesg and see if there are error messages
> mentioning
>    underruns around the time your problem started happening.
> 
> Well, I always had the followings lines in dmesg:
> [drm:intel_set_cpu_fifo_underrun_reporting] *ERROR* uncleared fifo
> underrun on pipe A
> [drm:intel_cpu_fifo_underrun_irq_handler] *ERROR* CPU pipe A FIFO
> underrun

Oh, well... I had a patch that would just disable FBC in case we saw a
FIFO underrun, but it was rejected. Maybe this is the time to think
about it again? Otherwise, I can't think of much besides disabling FBC
on HSW until all the underruns and watermarks regressions are fixed
forever.

> 
> I always got these when I switch on the DisplayPort attached monitor.
> Recently I changed userland from kdm to sddm and noticed that I
> apparently get these when sddm shuts down.  I am not aware of whether
> or not this also already happened with kdm.
> 
> However, "around the time your problem started happening" there is
> nothing in dmesg, because "your problem" is a complete hang without
> possibility of disk IO and without netconsole output.
> 
>  - Download intel-gpu-tools, compile it, and run:
>    $ sudo ./tests/kms_frontbuffer_tracking --run-subtest '*fbc-*' 
> 2>&1 | tee fbc.txt
>    Then send us the fbc.txt file, especially if you get a
> failure.
>    This will really maximize your chances of getting the bug
> fixed
>    quickly.
> 
> Do you need this while FBC is enabled, or can I run it while FBC is
> disabled?

FBC enabled. Considering your description, my hope is that maybe some
specific subtest will be able to hang your machine, so testing this
again will require only running the specific subtest instead of waiting
18 hours.

> 
>  - Try to find a reliable way to reproduce the problem, and tell
> us.
> 
> The reliable way is to just wait for the kernel to hang after about
> 3 minutes to 5.5 hours.  I have not identified any special activity
> which would trigger the hang.
> 
>  - Boot with drm.debug=0xe, reproduce the problem, then send us
> the
>    dmesg file.
> 
> I can try this, but I am skeptical about getting any useful kernel
> messages from before the hang.

Agree.

> 
> PS:
> I am mentioning the following just in case that it has any
> relation

Re: [Intel-gfx] Regression of v4.6-rc vs. v4.5 bisected: a98ee79317b4 "drm/i915/fbc: enable FBC by default on HSW and BDW"

[Zanoni, Paulo R]

Em Sex, 2016-05-06 às 00:54 +0200, Stefan Richter escreveu:
> On May 05 Zanoni, Paulo R wrote:
> > 
> > Em Qui, 2016-05-05 às 19:45 +0200, Stefan Richter escreveu:
> > > 
> > > Oh, and in case you - the person reading this commit message
> > > - found
> > > this commit through git bisect, please do the following:
> > >  - Check your dmesg and see if there are error messages
> > > mentioning
> > >    underruns around the time your problem started happening.
> > > 
> > > Well, I always had the followings lines in dmesg:
> > > [drm:intel_set_cpu_fifo_underrun_reporting] *ERROR* uncleared
> > > fifo underrun on pipe A
> > > [drm:intel_cpu_fifo_underrun_irq_handler] *ERROR* CPU pipe A FIFO
> > > underrun  
> > Oh, well... I had a patch that would just disable FBC in case we
> > saw a
> > FIFO underrun, but it was rejected. Maybe this is the time to think
> > about it again? Otherwise, I can't think of much besides disabling
> > FBC
> > on HSW until all the underruns and watermarks regressions are fixed
> > forever.
> Just to be clear though, I know that these messages are emitted when
> the
> monitor is switched on, and when sddm is being shut down --- but I do
> not
> know whether there is any sort of underrun when I get the FBC related
> freeze (since I just don't get any kernel messages at that point).

The fact that underruns have occurred earlier is enough to know that
something is wrong (most probably, bad watermarks): we stop reporting
underruns once we get the first one. In addition, we already know that
FBC has the tendency to amplify apparently-harmless FIFO underruns into
black screens, and I wouldn't be surprised to learn that it could also
cause full machine lockups.

> 
> Is there a chance that a serial console would fare better than
> netconsole?  This board and another PC in its vicinity have got
> onboard
> serial ports but I don't have cables at the moment.

In the past, for some specific cases not related to FBC, I had more
luck with serial console than with netconsole. But if this is really
caused by FBC and watermarks, I don't think you'll be able to grab any
specific message at the time of the machine hang. OTOH, if something
actually shows up, it could help invalidate our current assumption of
the relationship between the problem and FBC and underruns.

> 
> > 
> > > 
> > >  - Download intel-gpu-tools, compile it, and run:
> > >    $ sudo ./tests/kms_frontbuffer_tracking --run-subtest
> > > '*fbc-*' 2>&1 | tee fbc.txt  
> > >    Then send us the fbc.txt file, especially if you get a
> > > failure.
> > >    This will really maximize your chances of getting the bug
> > > fixed
> > >    quickly.
> > > 
> > > Do you need this while FBC is enabled, or can I run it while FBC
> > > is
> > > disabled?  
> > FBC enabled. Considering your description, my hope is that maybe
> > some
> > specific subtest will be able to hang your machine, so testing this
> > again will require only running the specific subtest instead of
> > waiting
> > 18 hours.
> The kms_frontbuffer_tracking runs from which I posted output two
> hours
> ago did not trigger a lockup.
> 
> (I ran them while X11 was shut down because otherwise
> kms_frontbuffer_tracking would skip all tests with "Can't become DRM
> master, please check if no other DRM client is running.")

Yes, this is the correct way.

> 
> > 
> > > 
> > > PS:
> > > I am mentioning the following just in case that it has any
> > > relationship
> > > with the FBC related kernel freezes.  Maybe it doesn't...  There
> > > is
> > > another recent regression on this PC, but I have not yet figured
> > > out
> > > whether it was introduced by any particular kernel version.  The
> > > regression is:  When switching from X11 to text console by
> > > [Ctrl][Alt][Fx]
> > > or by shutting down sddm, I often only get a blank screen.  I
> > > suspect
> > > that this regression was introduced when I replaced kdm by sddm,
> > > but
> > > I am not sure about that.  
> > Maybe there is some relationship, since this operation involves a
> > mode
> > change. You can also try checking dmesg to see if there are
> > underruns
> > right when you do the change.
> Yes, this is accompanied by
> [drm:intel_set_cpu_fifo_underrun_reporting] *ERROR* uncleared fifo
> underrun on pipe A
> [drm:intel_cpu_fifo_underrun_irq_handler] *ERROR* CPU pipe A FIFO
> underrun  
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v4 1/4] drm: Add helper for DP++ adaptors

[Zanoni, Paulo R]

Em Ter, 2016-05-03 às 20:56 +0300, ville.syrj...@linux.intel.com
escreveu:
> From: Ville Syrjälä 
> 
> Add a helper which aids in the identification of DP dual mode
> (aka. DP++) adaptors. There are several types of adaptors
> specified: type 1 DVI, type 1 HDMI, type 2 DVI, type 2 HDMI
> 
> Type 1 adaptors have a max TMDS clock limit of 165MHz, type 2
> adaptors
> may go as high as 300MHz and they provide a register informing the
> source device what the actual limit is. Supposedly also type 1
> adaptors
> may optionally implement this register. This TMDS clock limit is the
> main reason why we need to identify these adaptors.
> 
> Type 1 adaptors provide access to their internal registers and the
> sink
> DDC bus through I2C. Type 2 adaptors provide this access both via I2C
> and I2C-over-AUX. A type 2 source device may choose to implement
> either
> of these methods. If a source device implements the I2C-over-AUX
> method, then the driver will obviously need specific support for such
> adaptors since the port is driven like an HDMI port, but DDC
> communication happes over the AUX channel.
> 
> This helper should be enough to identify the adaptor type (some
> type 1 DVI adaptors may be a slight exception) and the maximum TMDS
> clock limit. Another feature that may be available is control over
> the TMDS output buffers on the adaptor, possibly allowing for some
> power saving when the TMDS link is down.
> 
> Other user controllable features that may be available in the
> adaptors
> are downstream i2c bus speed control when using i2c-over-aux, and
> some control over the CEC pin. I chose not to provide any helper
> functions for those since I have no use for them in i915 at this
> time.
> The rest of the registers in the adaptor are mostly just information,
> eg. IEEE OUI, hardware and firmware revision, etc.
> 
> v2: Pass adaptor type to helper functions to ease driver
> implementation
> Fix a bunch of typoes (Paulo)
> Add DRM_DP_DUAL_MODE_UNKNOWN for the case where we don't (yet)
> know
> the type (Paulo)
> Reject 0x00 and 0xff DP_DUAL_MODE_MAX_TMDS_CLOCK values (Paulo)
> Adjust drm_dp_dual_mode_detect() type2 vs. type1 detection to
> ease future LSPCON enabling
> Remove the unused DP_DUAL_MODE_LAST_RESERVED define
> v3: Fix kernel doc function argument descriptions (Jani)
> s/NONE/UNKNOWN/ in drm_dp_dual_mode_detect() docs
> Add kernel doc for enum drm_dp_dual_mode_type
> Actually build the docs
> Fix more typoes
> v4: Adjust code indentation of type2 adaptor detection (Shashank)
> Add debug messages for failurs cases (Shashank)
> 
> Cc: sta...@vger.kernel.org
> Cc: Tore Anderson 
> Cc: Paulo Zanoni 
> Cc: Shashank Sharma 
> Cc: Daniel Vetter 
> Cc: Shashank Sharma 
> Signed-off-by: Ville Syrjälä 
> ---
>  Documentation/DocBook/gpu.tmpl|   6 +
>  drivers/gpu/drm/Makefile  |   2 +-
>  drivers/gpu/drm/drm_dp_dual_mode_helper.c | 365
> ++
>  include/drm/drm_dp_dual_mode_helper.h |  92 
>  4 files changed, 464 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/gpu/drm/drm_dp_dual_mode_helper.c
>  create mode 100644 include/drm/drm_dp_dual_mode_helper.h
> 
> diff --git a/Documentation/DocBook/gpu.tmpl
> b/Documentation/DocBook/gpu.tmpl
> index 1464fb2f3c46..c248124357df 100644
> --- a/Documentation/DocBook/gpu.tmpl
> +++ b/Documentation/DocBook/gpu.tmpl
> @@ -1623,6 +1623,12 @@ void intel_crt_init(struct drm_device *dev)
>  !Edrivers/gpu/drm/drm_dp_helper.c
>  
>  
> +  Display Port Dual Mode Adaptor Helper Functions
> Reference
> +!Pdrivers/gpu/drm/drm_dp_dual_mode_helper.c dp dual mode helpers
> +!Iinclude/drm/drm_dp_dual_mode_helper.h
> +!Edrivers/gpu/drm/drm_dp_dual_mode_helper.c
> +
> +
>    Display Port MST Helper Functions Reference
>  !Pdrivers/gpu/drm/drm_dp_mst_topology.c dp mst helper
>  !Iinclude/drm/drm_dp_mst_helper.h
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 1a26b4eb1ce0..29f2ee9b9534 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -23,7 +23,7 @@ drm-$(CONFIG_AGP) += drm_agpsupport.o
>  
>  drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o
> drm_probe_helper.o \
>   drm_plane_helper.o drm_dp_mst_topology.o
> drm_atomic_helper.o \
> - drm_kms_helper_common.o
> + drm_kms_helper_common.o drm_dp_dual_mode_helper.o
>  
>  drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
>  drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o
> diff --git a/drivers/gpu/drm/drm_dp_dual_mode_helper.c
> b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
> new file mode 100644
> index ..6842178474ba
> --- /dev/null
> +++ b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
> @@ -0,0 +1,365 @@
> +/*
> + * Copyright © 2016 Intel Corporation
> + *
> + * Permission is hereby granted, free of charge, to any person
> obtaining a
> + * copy of this softwa

Re: [Intel-gfx] [PATCH 2/8] drm/i915: introduce intel_has_sagv()

[Zanoni, Paulo R]

Em Sex, 2016-09-09 às 11:06 +0300, Jani Nikula escreveu:
> On Thu, 08 Sep 2016, Lyude Paul  wrote:
> > 
> > On Thu, 2016-09-08 at 11:59 +0300, Jani Nikula wrote:
> > > 
> > > On Wed, 07 Sep 2016, Lyude  wrote:
> > > > 
> > > > 
> > > > On Tue, 2016-09-06 at 21:52 -0300, Paulo Zanoni wrote:
> > > > > 
> > > > > +static bool
> > > > > +intel_has_sagv(struct drm_i915_private *dev_priv)
> > > > > +{
> > > > > + return IS_SKYLAKE(dev_priv);
> > > > > +}
> > > > > +
> > > > 
> > > > Not sure I agree on this one. Even if a system is skylake or
> > > > kabylake,
> > > > there's a couple of very early skylake machines that don't
> > > > actually
> > > > have an SAGV on them. Hence the I915_SAGV_NOT_CONTROLLED value
> > > > we set
> > > > if we get mailbox errors.
> > > 
> > > If by "very early" you mean pre-production, we don't care.

Ok, so I'd like some clarification regarding this from the maintainers.
I always thought we didn't really care, but do this:

$ git grep _REVID_

If we don't care, why do we have this? Newer platforms also have this.
And many of these REVID checks are only pre-prod.

> > 
> > The problem is if we don't handle that case though then a couple of
> > the machines in CI start failing tests since all of the SAGV
> > mailbox
> > commands don't end up working :(
> 
> Regardless of whose CI you refer to, no pre-production machines
> should
> be used for CI. Which machines are these?

I suppose he's talking about our CI.

> 
> Can we be sure all production machines have SAGV?

Our specs don't mention anything regarding this. I'll have to ask for
clarification, but I don't think it will be a good idea to remove the
code if CI starts complaining.

> 
> BR,
> Jani.
> 
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/8] drm/i915: SAGV is not SKL-only, so rename a few things

[Zanoni, Paulo R]

Em Qua, 2016-09-07 às 12:05 -0400, Lyude escreveu:
> My only thought is that it seems like we prefix functions skl_, kbl_,
> etc. just to indicate which generation introduced the feature. Skl
> uses
> quite a few sandybridge and haswell functions. If this is a little
> closer to what most intel devs would expect the naming to be though
> then:

We actually have both schemes, but my understanding is that
firstplatform_something is more used when we actually need 2+ functions
(like i9xx_crtc_enable and then ilk_crtc_enable), and we usually have
something like intel_something calling firstplatform_something, or just
dev_priv->something() calling the firstplatform_something vfunc. But my
understanding may be wrong.

Anyway, I just did the rename because skl_has_sagv() would be super
confusing (returns true on KBL). I'm happy to accept suggestions here
that would avoid the renaming I did.

> 
> Reviewed-by: Lyude 
> 
> going through the other patches now as well
> 
> On Tue, 2016-09-06 at 21:52 -0300, Paulo Zanoni wrote:
> > 
> > The plan is to introduce intel_has_sagv() and then use it to
> > discover
> > which platforms actually support it.
> > 
> > I thought about keeping the functions with their current skl names,
> > but found two problems: (i) skl_has_sagv() would become a very
> > confusing name, and (ii) intel_atomic_commit_tail() doesn't seem to
> > be
> > calling any functions whose name start with a platform name, so the
> > "intel_" naming scheme seems make more sense than the
> > "firstplatorm_"
> > naming scheme here.
> > 
> > Signed-off-by: Paulo Zanoni 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.h  | 10 +-
> >  drivers/gpu/drm/i915/intel_display.c |  8 
> >  drivers/gpu/drm/i915/intel_drv.h |  6 +++---
> >  drivers/gpu/drm/i915/intel_pm.c  | 26 +---
> > --
> >  4 files changed, 25 insertions(+), 25 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 053a347..503c69d 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -1972,11 +1972,11 @@ struct drm_i915_private {
> >     struct vlv_s0ix_state vlv_s0ix_state;
> >  
> >     enum {
> > -   I915_SKL_SAGV_UNKNOWN = 0,
> > -   I915_SKL_SAGV_DISABLED,
> > -   I915_SKL_SAGV_ENABLED,
> > -   I915_SKL_SAGV_NOT_CONTROLLED
> > -   } skl_sagv_status;
> > +   I915_SAGV_UNKNOWN = 0,
> > +   I915_SAGV_DISABLED,
> > +   I915_SAGV_ENABLED,
> > +   I915_SAGV_NOT_CONTROLLED
> > +   } sagv_status;
> >  
> >     struct {
> >     /*
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 6b4d7ac..4dd4961 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -14379,8 +14379,8 @@ static void intel_atomic_commit_tail(struct
> > drm_atomic_state *state)
> >      * SKL workaround: bspec recommends we disable the
> > SAGV when we
> >      * have more then one pipe enabled
> >      */
> > -   if (IS_SKYLAKE(dev_priv) &&
> > !skl_can_enable_sagv(state))
> > -   skl_disable_sagv(dev_priv);
> > +   if (IS_SKYLAKE(dev_priv) &&
> > !intel_can_enable_sagv(state))
> > +   intel_disable_sagv(dev_priv);
> >  
> >     intel_modeset_verify_disabled(dev);
> >     }
> > @@ -14438,8 +14438,8 @@ static void intel_atomic_commit_tail(struct
> > drm_atomic_state *state)
> >     }
> >  
> >     if (IS_SKYLAKE(dev_priv) && intel_state->modeset &&
> > -   skl_can_enable_sagv(state))
> > -   skl_enable_sagv(dev_priv);
> > +   intel_can_enable_sagv(state))
> > +   intel_enable_sagv(dev_priv);
> >  
> >     drm_atomic_helper_commit_hw_done(state);
> >  
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index d084c1b..bb55b61 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -1741,9 +1741,9 @@ void ilk_wm_get_hw_state(struct drm_device
> > *dev);
> >  void skl_wm_get_hw_state(struct drm_device *dev);
> >  void skl_ddb_get_hw_state(struct drm_i915_private *dev_priv,
> >       struct skl_ddb_allocation *ddb /* out
> > */);
> > -bool skl_can_enable_sagv(struct drm_atomic_state *state);
> > -int skl_enable_sagv(struct drm_i915_private *dev_priv);
> > -int skl_disable_sagv(struct drm_i915_private *dev_priv);
> > +bool intel_can_enable_sagv(struct drm_atomic_state *state);
> > +int intel_enable_sagv(struct drm_i915_private *dev_priv);
> > +int intel_disable_sagv(struct drm_i915_private *dev_priv);
> >  bool skl_ddb_allocation_equals(const struct skl_ddb_allocation
> > *old,
> >        const struct skl_ddb_allocation
> > *new,
> >        enum pipe pipe);
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > b/drivers/gpu/drm/i915/i

Re: [Intel-gfx] [CI 10/21] drm/i915: Mark up all locked waiters

[Zanoni, Paulo R]

Hi

Em Sex, 2016-09-09 às 14:11 +0100, Chris Wilson escreveu:
> In the next patch we want to handle reset directly by a locked waiter
> in
> order to avoid issues with returning before the reset is handled. To
> handle the reset, we must first know whether we hold the
> struct_mutex.
> If we do not hold the struct_mtuex we can not perform the reset, but
> we do
> not block the reset worker either (and so we can just continue to
> wait for
> request completion) - otherwise we must relinquish the mutex.
> 
> Signed-off-by: Chris Wilson 
> Reviewed-by: Mika Kuoppala 
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c  |  4 +++-
>  drivers/gpu/drm/i915/i915_gem.c  |  7 +--
>  drivers/gpu/drm/i915/i915_gem_evict.c|  8 ++--
>  drivers/gpu/drm/i915/i915_gem_gtt.c  |  2 +-
>  drivers/gpu/drm/i915/i915_gem_request.c  | 15 ---
>  drivers/gpu/drm/i915/i915_gem_request.h  | 11 ---
>  drivers/gpu/drm/i915/i915_gem_shrinker.c |  2 +-
>  drivers/gpu/drm/i915/intel_ringbuffer.c  |  3 ++-
>  8 files changed, 38 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 620e7daa133b..64702cc68e3a 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -4803,7 +4803,9 @@ i915_drop_caches_set(void *data, u64 val)
>   return ret;
>  
>   if (val & DROP_ACTIVE) {
> - ret = i915_gem_wait_for_idle(dev_priv,
> I915_WAIT_INTERRUPTIBLE);
> + ret = i915_gem_wait_for_idle(dev_priv,
> +  I915_WAIT_INTERRUPTIBLE
> |
> +  I915_WAIT_LOCKED);
>   if (ret)
>   goto unlock;
>   }
> diff --git a/drivers/gpu/drm/i915/i915_gem.c
> b/drivers/gpu/drm/i915/i915_gem.c
> index 4617250c3000..23069a2d2850 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -2802,7 +2802,8 @@ __i915_gem_object_sync(struct
> drm_i915_gem_request *to,
>  
>   if (!i915.semaphores) {
>   ret = i915_wait_request(from,
> - from->i915-
> >mm.interruptible,
> + from->i915->mm.interruptible 
> |
> + I915_WAIT_LOCKED,
>   NULL,
>   NO_WAITBOOST);
>   if (ret)
> @@ -4304,7 +4305,9 @@ int i915_gem_suspend(struct drm_device *dev)
>   if (ret)
>   goto err;
>  
> - ret = i915_gem_wait_for_idle(dev_priv,
> I915_WAIT_INTERRUPTIBLE);
> + ret = i915_gem_wait_for_idle(dev_priv,
> +  I915_WAIT_INTERRUPTIBLE |
> +  I915_WAIT_LOCKED);
>   if (ret)
>   goto err;
>  
> diff --git a/drivers/gpu/drm/i915/i915_gem_evict.c
> b/drivers/gpu/drm/i915/i915_gem_evict.c
> index 103085246975..5b6f81c1dbca 100644
> --- a/drivers/gpu/drm/i915/i915_gem_evict.c
> +++ b/drivers/gpu/drm/i915/i915_gem_evict.c
> @@ -170,7 +170,9 @@ search_again:
>   if (ret)
>   return ret;
>  
> - ret = i915_gem_wait_for_idle(dev_priv,
> I915_WAIT_INTERRUPTIBLE);
> + ret = i915_gem_wait_for_idle(dev_priv,
> +  I915_WAIT_INTERRUPTIBLE |
> +  I915_WAIT_LOCKED);
>   if (ret)
>   return ret;
>  
> @@ -275,7 +277,9 @@ int i915_gem_evict_vm(struct i915_address_space
> *vm, bool do_idle)
>   return ret;
>   }
>  
> - ret = i915_gem_wait_for_idle(dev_priv,
> I915_WAIT_INTERRUPTIBLE);
> + ret = i915_gem_wait_for_idle(dev_priv,
> +  I915_WAIT_INTERRUPTIBLE
> |
> +  I915_WAIT_LOCKED);
>   if (ret)
>   return ret;
>  
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
> b/drivers/gpu/drm/i915/i915_gem_gtt.c
> index 9bcac52b8268..f3c6876da521 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> @@ -2683,7 +2683,7 @@ void i915_gem_gtt_finish_object(struct
> drm_i915_gem_object *obj)
>   struct i915_ggtt *ggtt = &dev_priv->ggtt;
>  
>   if (unlikely(ggtt->do_idle_maps)) {
> - if (i915_gem_wait_for_idle(dev_priv, 0)) {
> + if (i915_gem_wait_for_idle(dev_priv,
> I915_WAIT_LOCKED)) {
>   DRM_ERROR("Failed to wait for idle; VT'd may
> hang.\n");
>   /* Wait a bit, in hopes it avoids the hang
> */
>   udelay(10);
> diff --git a/drivers/gpu/drm/i915/i915_gem_request.c
> b/drivers/gpu/drm/i915/i915_gem_request.c
> index f4c15f319d08..5f89801e6a16 100644
> --- a/drivers/gpu/drm/i915/i915_gem_request.c
> +++ b/drivers/gpu/drm/i915/i915_gem_request.c
> @@ -260,7 +260,9 @@ static int i915

Re: [Intel-gfx] [PATCH] drm/i915/fbc: disable FBC on FIFO underruns

[Zanoni, Paulo R]

Em Seg, 2016-09-12 às 21:25 +0100, Chris Wilson escreveu:
> On Mon, Sep 12, 2016 at 05:02:56PM -0300, Paulo Zanoni wrote:
> > 
> > Ever since I started working on FBC I was already aware that FBC
> > can
> > really amplify the FIFO underrun symptoms. On systems where FIFO
> > underruns were harmless error messages, enabling FBC would cause
> > the
> > underruns to give black screens.
> > 
> > We recently tried to enable FBC on Haswell and got reports of a
> > system
> > that would hang after some hours of uptime, and the first bad
> > commit
> > was the one that enabled FBC. We also observed that this system had
> > FIFO underrun error messages on its dmesg. Although we don't have
> > any
> > evidence that fixing the underruns would solve the bug and make FBC
> > work properly on this machine, IMHO it's better if we minimize the
> > amount of possible problems by just giving up FBC whenever we
> > detect
> > an underrun.
> > 
> > v2: New version, different implementation and commit message.
> > v3: Clarify the fact that we run from an IRQ handler (Chris).
> > v4: Also add the underrun_detected check at can_choose() to avoid
> > misleading dmesg messages (DK).
> > 
> > Cc: Stefan Richter 
> > Cc: Lyude 
> > Cc: stevenhoney...@gmail.com 
> > Cc: Dhinakaran Pandiyan 
> > Signed-off-by: Paulo Zanoni 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.h|  3 ++
> >  drivers/gpu/drm/i915/intel_drv.h   |  1 +
> >  drivers/gpu/drm/i915/intel_fbc.c   | 66
> > ++
> >  drivers/gpu/drm/i915/intel_fifo_underrun.c |  2 +
> >  4 files changed, 72 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 1e2dda8..2025f42 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -971,6 +971,9 @@ struct intel_fbc {
> >     bool enabled;
> >     bool active;
> >  
> > +   bool underrun_detected;
> > +   struct work_struct underrun_work;
> > +
> >     struct intel_fbc_state_cache {
> >     struct {
> >     unsigned int mode_flags;
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index abe7a4d..0d05712 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -1508,6 +1508,7 @@ void intel_fbc_invalidate(struct
> > drm_i915_private *dev_priv,
> >  void intel_fbc_flush(struct drm_i915_private *dev_priv,
> >      unsigned int frontbuffer_bits, enum
> > fb_op_origin origin);
> >  void intel_fbc_cleanup_cfb(struct drm_i915_private *dev_priv);
> > +void intel_fbc_handle_fifo_underrun_irq(struct drm_i915_private
> > *dev_priv);
> >  
> >  /* intel_hdmi.c */
> >  void intel_hdmi_init(struct drm_device *dev, i915_reg_t hdmi_reg,
> > enum port port);
> > diff --git a/drivers/gpu/drm/i915/intel_fbc.c
> > b/drivers/gpu/drm/i915/intel_fbc.c
> > index 5dcb81a..4b91af1 100644
> > --- a/drivers/gpu/drm/i915/intel_fbc.c
> > +++ b/drivers/gpu/drm/i915/intel_fbc.c
> > @@ -774,6 +774,13 @@ static bool intel_fbc_can_activate(struct
> > intel_crtc *crtc)
> >     struct intel_fbc *fbc = &dev_priv->fbc;
> >     struct intel_fbc_state_cache *cache = &fbc->state_cache;
> >  
> > +   /* We don't need to use a state cache here since this
> > information is
> > +    * global for every CRTC. */
> 
>* global for all CRTC.
>*/
> 
> "global for every CRTC" is confusing, as it says to me that is a
> separate global variable for each CRTC. But what you mean is that
> there
> is one variable that reflects all CRTC.

Makes sense.

> 
> > 
> > +   if (fbc->underrun_detected) {
> > +   fbc->no_fbc_reason = "underrun detected";
> > +   return false;
> > +   }
> > +
> >     if (!cache->plane.visible) {
> >     fbc->no_fbc_reason = "primary plane not visible";
> >     return false;
> > @@ -859,6 +866,11 @@ static bool intel_fbc_can_choose(struct
> > intel_crtc *crtc)
> >     return false;
> >     }
> >  
> > +   if (fbc->underrun_detected) {
> > +   fbc->no_fbc_reason = "underrun detected";
> > +   return false;
> > +   }
> > +
> >     if (fbc_on_pipe_a_only(dev_priv) && crtc->pipe != PIPE_A)
> > {
> >     fbc->no_fbc_reason = "no enabled pipes can have
> > FBC";
> >     return false;
> > @@ -1221,6 +1233,59 @@ void intel_fbc_global_disable(struct
> > drm_i915_private *dev_priv)
> >     cancel_work_sync(&fbc->work.work);
> >  }
> >  
> > +static void intel_fbc_underrun_work_fn(struct work_struct *work)
> > +{
> > +   struct drm_i915_private *dev_priv =
> > +   container_of(work, struct drm_i915_private,
> > fbc.underrun_work);
> > +   struct intel_fbc *fbc = &dev_priv->fbc;
> > +
> > +   mutex_lock(&fbc->lock);
> > +
> > +   /* Maybe we were scheduled twice. */
> > +   if (fbc->underrun_detected)
> > +   goto out;
> > +
> > +   DRM_DEBUG_KMS("Disabling FBC due to FIFO underrun.\n");
> > +   fbc->unde

Re: [Intel-gfx] [PATCH 3/8] drm/i915/kbl: KBL also needs to run the SAGV code

[Zanoni, Paulo R]

Em Qua, 2016-09-07 às 12:17 -0400, Lyude escreveu:
> I'm not sure that kbl has this either. The kbl machine I've been
> working with thus-far has passed a few modesetting stress tests with
> the chameleon, and I don't have anything trying to control sagv stuff
> on it.
> 
> This being said though the sagv for skylake did happen to get added
> right before release and wasn't in any SDPs, so even so we should
> keep
> our eyes out when kbl starts shipping…

I got confirmation from the Hardware guys that KBL does need to run the
SAGV code, and it has the same latency as SKL. Also, all SKL production
steppings need to run the SAGV code.

> 
> On Wed, 2016-09-07 at 19:11 +0300, Ville Syrjälä wrote:
> > 
> > On Tue, Sep 06, 2016 at 09:52:14PM -0300, Paulo Zanoni wrote:
> > > 
> > > 
> > > According to BSpec, it's the "core CPUs" that need the code,
> > > which
> > > means SKL and KBL, but not BXT.
> > > 
> > > I don't have a KBL to test this patch on it.
> > 
> > IIRC bspec doesn't specify the sagv latency for anything but
> > SKL, and the relevant w/a was only listed for SKL as well. So not
> > sure
> > this is correct.
> > 
> > > 
> > > 
> > > 
> > > Signed-off-by: Paulo Zanoni 
> > > ---
> > >  drivers/gpu/drm/i915/intel_pm.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > > b/drivers/gpu/drm/i915/intel_pm.c
> > > index af75011..baacd95 100644
> > > --- a/drivers/gpu/drm/i915/intel_pm.c
> > > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > > @@ -2887,7 +2887,7 @@ skl_wm_plane_id(const struct intel_plane
> > > *plane)
> > >  static bool
> > >  intel_has_sagv(struct drm_i915_private *dev_priv)
> > >  {
> > > - return IS_SKYLAKE(dev_priv);
> > > + return IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv);
> > >  }
> > >  
> > >  /*
> > > -- 
> > > 2.7.4
> > > 
> > > ___
> > > Intel-gfx mailing list
> > > Intel-gfx@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 5/8] drm/i915/gen9: minimum scanlines for Y tile is not always 4

[Zanoni, Paulo R]

Em Qua, 2016-09-07 às 19:03 -0400, Lyude escreveu:
> On Tue, 2016-09-06 at 21:52 -0300, Paulo Zanoni wrote:
> > 
> > During watermarks calculations, this value is used in 3 different
> > places. Only one of them was not using a hardcoded 4. Move the code
> > up
> > so everybody can benefit from the actual value.
> > 
> > This should only help on situations with Y tiling + 90/270 rotation
> > +
> > 1 or 2 bpp or NV12.
> > 
> > Signed-off-by: Paulo Zanoni 
> > ---
> >  drivers/gpu/drm/i915/intel_pm.c | 56 +++--
> > 
> >  1 file changed, 32 insertions(+), 24 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index f8ac928..5a23a91 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -3499,7 +3499,8 @@ static uint32_t skl_wm_method1(uint32_t
> > pixel_rate, uint8_t cpp, uint32_t latenc
> >  
> >  static uint32_t skl_wm_method2(uint32_t pixel_rate, uint32_t
> > pipe_htotal,
> >        uint32_t horiz_pixels, uint8_t cpp,
> > -      uint64_t tiling, uint32_t latency)
> > +      uint64_t tiling, uint32_t latency,
> > +      uint32_t y_min_scanlines)
> >  {
> >     uint32_t ret;
> >     uint32_t plane_bytes_per_line, plane_blocks_per_line;
> > @@ -3512,9 +3513,9 @@ static uint32_t skl_wm_method2(uint32_t
> > pixel_rate, uint32_t pipe_htotal,
> >  
> >     if (tiling == I915_FORMAT_MOD_Y_TILED ||
> >     tiling == I915_FORMAT_MOD_Yf_TILED) {
> > -   plane_bytes_per_line *= 4;
> > +   plane_bytes_per_line *= y_min_scanlines;
> >     plane_blocks_per_line =
> > DIV_ROUND_UP(plane_bytes_per_line, 512);
> > -   plane_blocks_per_line /= 4;
> > +   plane_blocks_per_line /= y_min_scanlines;
> >     } else if (tiling == DRM_FORMAT_MOD_NONE) {
> >     plane_blocks_per_line =
> > DIV_ROUND_UP(plane_bytes_per_line, 512) + 1;
> >     } else {
> > @@ -3571,6 +3572,7 @@ static int skl_compute_plane_wm(const struct
> > drm_i915_private *dev_priv,
> >     uint8_t cpp;
> >     uint32_t width = 0, height = 0;
> >     uint32_t plane_pixel_rate;
> > +   uint32_t y_min_scanlines;
> >  
> >     if (latency == 0 || !cstate->base.active || !intel_pstate-
> > > 
> > > base.visible) {
> >     *enabled = false;
> > @@ -3586,38 +3588,44 @@ static int skl_compute_plane_wm(const
> > struct
> > drm_i915_private *dev_priv,
> >     cpp = drm_format_plane_cpp(fb->pixel_format, 0);
> >     plane_pixel_rate = skl_adjusted_plane_pixel_rate(cstate,
> > intel_pstate);
> >  
> > +   if (intel_rotation_90_or_270(pstate->rotation)) {
> > +   int cpp = (fb->pixel_format == DRM_FORMAT_NV12) ?
> > +   drm_format_plane_cpp(fb->pixel_format, 1)
> > :
> > +   drm_format_plane_cpp(fb->pixel_format, 0);
> > +
> > +   switch (cpp) {
> > +   case 1:
> > +   y_min_scanlines = 16;
> > +   break;
> > +   case 2:
> > +   y_min_scanlines = 8;
> > +   break;
> > +   default:
> > +   WARN(1, "Unsupported pixel depth for
> > rotation");
> 
> This looks like it's leftover from the code that you moved around,
> but
> we should be erroring out here and returning -EINVAL here so the
> modeset actually fails.

Good catch. I'll do this as a separate patch since it's a separate fix.

> 
> > 
> > +   case 4:
> > +   y_min_scanlines = 4;
> > +   break;
> > +   }
> > +   } else {
> > +   y_min_scanlines = 4;
> > +   }
> > +
> >     method1 = skl_wm_method1(plane_pixel_rate, cpp, latency);
> >     method2 = skl_wm_method2(plane_pixel_rate,
> >      cstate-
> > > 
> > > base.adjusted_mode.crtc_htotal,
> >      width,
> >      cpp,
> >      fb->modifier[0],
> > -    latency);
> > +    latency,
> > +    y_min_scanlines);
> >  
> >     plane_bytes_per_line = width * cpp;
> >     plane_blocks_per_line = DIV_ROUND_UP(plane_bytes_per_line,
> > 512);
> >  
> >     if (fb->modifier[0] == I915_FORMAT_MOD_Y_TILED ||
> >     fb->modifier[0] == I915_FORMAT_MOD_Yf_TILED) {
> > -   uint32_t min_scanlines = 4;
> > -   uint32_t y_tile_minimum;
> > -   if (intel_rotation_90_or_270(pstate->rotation)) {
> > -   int cpp = (fb->pixel_format ==
> > DRM_FORMAT_NV12) ?
> > -   drm_format_plane_cpp(fb-
> > > 
> > > pixel_format, 1) :
> > -   drm_format_plane_cpp(fb-
> > > 
> > > pixel_format, 0);
> > -
> > -   switch (cpp) {
> > -   case 1:
> > -   min_scanlines = 16;
> > -   break;
> > -

Re: [Intel-gfx] [PATCH] drm/i915: Only expand COND once in wait_for()

[Zanoni, Paulo R]

Em Ter, 2016-09-13 às 20:40 +0100, Chris Wilson escreveu:
> I was looking at some wait_for() timeouts on a slow system, with lots
> of
> debug enabled (KASAN, lockdep, mmio_debug). Thinking that we were
> mishandling the timeout, I tried to ensure that we loop at least once
> after first testing COND. However, the double test of COND either
> side
> of the timeout check makes that unlikely. But we can do an equivalent
> loop, that keeps the COND check after testing for timeout (required
> so
> that we are not preempted between testing COND and then testing for a
> timeout) without expanding COND twice.
> 
> The advantage of only expanding COND once is a dramatic reduction in
> code size:
> 
>    text      data bss dec hex
> 1308733      5184    1152 1315069  1410fd 
> before
> 1305341      5184    1152 1311677  1403bd 
> after
> 
> Signed-off-by: Chris Wilson 
> Cc: Tvrtko Ursulin 
> Cc: Ville Syrjälä 
> Cc: Daniel Vetter 
> ---
>  drivers/gpu/drm/i915/intel_drv.h | 13 -
>  1 file changed, 8 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index cb99a2540863..597899d71df9 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -52,13 +52,16 @@
>   */
>  #define _wait_for(COND, US, W) ({ \
>   unsigned long timeout__ = jiffies + usecs_to_jiffies(US) +
> 1;\
> - int ret__ = 0;  
>   \
> - while (!(COND)) {   
> \
> - if (time_after(jiffies, timeout__)) {   
>   \
> - if (!(COND))
> \
> - ret__ = -ETIMEDOUT; 
> \
> + int ret__;

ret__ starts "uninitialized".

>   \
> + for (;;) {  
> \
> + if (time_after(jiffies, timeout__)) 
> \
> + ret__ = -ETIMEDOUT; 

If we didn't hit the timeout, it's still "uninitialized".

>   \
> + if (COND) { 
> \
> + ret__ = 0;  

If the condition was not met, it's still "uninitialized".

>   \
>   break;  
>   \
>   }   
> \
> + if (ret__)  

But we read its "uninitialized" value here.

But why isn't the compiler complaining about this? Am I failing to see
something here?

If my analysis is correct, all you need to do is to keep ret__ being
initialized to zero. At least for clarity of the future code readers in
case it's expected to be auto-initialized to zero due to some weird
rule about compound statements or something.

With the ret__ initialization to zero:
Reviewed-by: Paulo Zanoni 

>   \
> + break;  
>   \
>   if ((W) && drm_can_sleep()) {   
>   \
>   usleep_range((W), (W)*2);   
> \
>   } else {
> \
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 0/9] SKL/KBL watermark fixes, v2

[Zanoni, Paulo R]

Em Qua, 2016-09-14 às 12:34 +0300, Jani Nikula escreveu:
> On Wed, 14 Sep 2016, Paulo Zanoni  wrote:
> > 
> > Hi
> > 
> > Here's the series with the reviews implemented. There's a new
> > patch,
> > based on the additional issue spotted by Lyude.
> 
> There's a bunch of cc: stable patches mixed with non cc: stable
> patches
> in the series. Do the cc: stable fixes work and backport cleanly
> without
> the the other non cc: stable patches? If not, can you arrange the
> series
> to not depend on the other patches?

Yeah, my bad. I was just pasting the output of "dim fixes" without
considering this aspect. I think the best thing is probably to backport
everything to stable and hope it works, considering the current
complaints we're seeing about screen flickering on SKL. Agree?

I suppose I don't need to resend the series just for these new tags.
I'll add them when it's time to merge.

> 
> BR,
> Jani.
> 
> 
> > 
> > 
> > Thanks for all the reviews,
> > Paulo
> > 
> > Paulo Zanoni (9):
> >   drm/i915: SAGV is not SKL-only, so rename a few things
> >   drm/i915: introduce intel_has_sagv()
> >   drm/i915/kbl: KBL also needs to run the SAGV code
> >   drm/i915/gen9: fix the WaWmMemoryReadLatency implementation
> >   drm/i915/gen9: minimum scanlines for Y tile is not always 4
> >   drm/i915/gen9: fix plane_blocks_per_line on watermarks
> > calculations
> >   drm/i915/gen9: fix the watermark res_blocks value
> >   drm/i915/gen9: implement missing case for SKL watermarks
> > calculation
> >   drm/i915/gen9: fail the modeset instead of WARNing on unsuported
> > config
> > 
> >  drivers/gpu/drm/i915/i915_drv.h  |  10 +-
> >  drivers/gpu/drm/i915/intel_display.c |   9 +-
> >  drivers/gpu/drm/i915/intel_drv.h |   6 +-
> >  drivers/gpu/drm/i915/intel_pm.c  | 186 ---
> > 
> >  4 files changed, 118 insertions(+), 93 deletions(-)
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/8] drm/i915/kbl: KBL also needs to run the SAGV code

[Zanoni, Paulo R]

Em Qua, 2016-09-14 às 12:59 +0300, Jani Nikula escreveu:
> On Tue, 13 Sep 2016, "Zanoni, Paulo R" 
> wrote:
> > 
> > I got confirmation from the Hardware guys that KBL does need to run
> > the
> > SAGV code, and it has the same latency as SKL. Also, all SKL
> > production
> > steppings need to run the SAGV code.
> 
> Can you get confirmation what's the first shipped production
> stepping?

https://01.org/sites/default/files/documentation/intel-gfx-prm-osrc-skl
-vol04-configurations.pdf#page=15

But I have to admit that I still have pre-prod machines and it would be
very convenient to me if they keep working :)

> 
> BR,
> Jani.
> 
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Only expand COND once in wait_for()

[Zanoni, Paulo R]

Em Qua, 2016-09-14 às 10:22 +0100, Chris Wilson escreveu:
> On Tue, Sep 13, 2016 at 08:40:19PM +0100, Chris Wilson wrote:
> > 
> > I was looking at some wait_for() timeouts on a slow system, with
> > lots of
> > debug enabled (KASAN, lockdep, mmio_debug). Thinking that we were
> > mishandling the timeout, I tried to ensure that we loop at least
> > once
> > after first testing COND. However, the double test of COND either
> > side
> > of the timeout check makes that unlikely. But we can do an
> > equivalent
> > loop, that keeps the COND check after testing for timeout (required
> > so
> > that we are not preempted between testing COND and then testing for
> > a
> > timeout) without expanding COND twice.
> > 
> > The advantage of only expanding COND once is a dramatic reduction
> > in
> > code size:
> > 
> >    text    data bss dec hex
> > 1308733    5184    1152 1315069  1410fd
> > before
> > 1305341    5184    1152 1311677  1403bd
> > after
> > 
> > Signed-off-by: Chris Wilson 
> > Cc: Tvrtko Ursulin 
> > Cc: Ville Syrjälä 
> > Cc: Daniel Vetter 
> > ---
> >  drivers/gpu/drm/i915/intel_drv.h | 13 -
> >  1 file changed, 8 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index cb99a2540863..597899d71df9 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -52,13 +52,16 @@
> >   */
> >  #define _wait_for(COND, US, W) ({ \
> >     unsigned long timeout__ = jiffies + usecs_to_jiffies(US) +
> > 1;  \
> > -   int ret__ = 0;  
> > \
> > -   while (!(COND)) {   
> > \
> > -   if (time_after(jiffies, timeout__)) {   
> > \
> > -   if (!(COND))
> > \
> > -   ret__ = -ETIMEDOUT; 
> > \
> > +   int ret__;  
> > \
> 
> Ok, this is the magic. Missed initializer, gcc goes wild trimming
> undefined code. Patch is completely bogus.

IMHO, expanding a macro argument only once is an improvement on its
own, even if the resulting binary is not smaller, since it makes the
code a little safer.

> -Chris
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3 2/9] drm/i915/skl+: use linetime latency instead of ddb size

[Zanoni, Paulo R]

Em Seg, 2016-09-19 às 15:19 -0300, Paulo Zanoni escreveu:
> Em Sex, 2016-09-09 às 13:30 +0530, Kumar, Mahesh escreveu:
> > 
> > From: Mahesh Kumar 
> > 
> > This patch make changes to use linetime latency instead of
> > allocated
> > DDB size during plane watermark calculation in switch case, This is
> > required to implement new DDB allocation algorithm.
> > 
> > In New Algorithm DDB is allocated based on WM values, because of
> > which
> > number of DDB blocks will not be available during WM calculation,
> > So this "linetime latency" is suggested by SV/HW team to use during
> > switch-case for WM blocks selection.
> 
> Why is this not part of BSpec? If there's some problem with the
> current
> algorithm and we need a new one, why is it not part of our spec?
> 
> > 
> > 
> > Changes since v1:
> >  - Rebase on top of Paulo's patch series
> > 
> > Signed-off-by: Mahesh Kumar 
> > ---
> >  drivers/gpu/drm/i915/intel_pm.c | 7 ++-
> >  1 file changed, 6 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index 3fdec4d..cfd9b7d1 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -3622,10 +3622,15 @@ static int skl_compute_plane_wm(const
> > struct
> > drm_i915_private *dev_priv,
> >     fb->modifier[0] == I915_FORMAT_MOD_Yf_TILED) {
> >     selected_result = max(method2, y_tile_minimum);
> >     } else {
> > +   uint32_t linetime_us = 0;
> > +
> > +   linetime_us = DIV_ROUND_UP(width * 1000,
> > +   skl_pipe_pixel_rate(cstate));

Also, shouldn't this be width * 8 * 1000?

> > +
> >     if ((cpp * cstate->base.adjusted_mode.crtc_htotal
> > /
> > 512 < 1) &&
> >     (plane_bytes_per_line / 512 < 1))
> >     selected_result = method2;
> > -   else if ((ddb_allocation / plane_blocks_per_line)
> > >=
> > 1)
> > +   if (latency >= linetime_us)
> >     selected_result = min(method1, method2);
> >     else
> >     selected_result = method1;
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] drm/i915/gen9: fix watermarks when using the pipe scaler

[Zanoni, Paulo R]

Em Sex, 2016-10-07 às 17:13 -0300, Paulo Zanoni escreveu:
> Luckily, the necessary adjustments for when we're using the scaler
> are
> exactly the same as the ones needed on ILK+, so just reuse the
> function we already have.

Now that I sent it, I realized that I should just have inverted the
patch order so patch 1 could be Cc:stable to ease backporting...

> 
> Signed-off-by: Paulo Zanoni 
> ---
>  drivers/gpu/drm/i915/intel_pm.c | 10 ++
>  1 file changed, 2 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c
> b/drivers/gpu/drm/i915/intel_pm.c
> index 3a6df2f..62d730d 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3470,12 +3470,6 @@ skl_allocate_pipe_ddb(struct intel_crtc_state
> *cstate,
>   return 0;
>  }
>  
> -static uint32_t skl_pipe_pixel_rate(const struct intel_crtc_state
> *config)
> -{
> - /* TODO: Take into account the scalers once we support them
> */
> - return config->base.adjusted_mode.crtc_clock;
> -}
> -
>  /*
>   * The max latency should be 257 (max the punit can code is 255 and
> we add 2us
>   * for the read latency) and cpp should always be <= 8, so that
> @@ -3526,7 +3520,7 @@ static uint32_t
> skl_adjusted_plane_pixel_rate(const struct intel_crtc_state *cst
>    * Adjusted plane pixel rate is just the pipe's adjusted
> pixel rate
>    * with additional adjustments for plane-specific scaling.
>    */
> - adjusted_pixel_rate = skl_pipe_pixel_rate(cstate);
> + adjusted_pixel_rate = ilk_pipe_pixel_rate(cstate);
>   downscale_amount = skl_plane_downscale_amount(pstate);
>  
>   pixel_rate = adjusted_pixel_rate * downscale_amount >> 16;
> @@ -3744,7 +3738,7 @@ skl_compute_linetime_wm(struct intel_crtc_state
> *cstate)
>   if (!cstate->base.active)
>   return 0;
>  
> - pixel_rate = skl_pipe_pixel_rate(cstate);
> + pixel_rate = ilk_pipe_pixel_rate(cstate);
>  
>   if (WARN_ON(pixel_rate == 0))
>   return 0;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm/i915/gen9: unconditionally apply the memory bandwidth WA

[Zanoni, Paulo R]

Em Seg, 2016-10-10 às 16:34 -0400, Lyude Paul escreveu:
> Was there a new workaround added recently? Or was this something I
> just
> missed when writing the original code for this

It's listed on the public spec:
https://01.org/sites/default/files/docum
entation/intel-gfx-prm-osrc-skl-vol12-display.pdf

Pages 210 - 211.

> 
> On Mon, 2016-10-10 at 17:30 -0300, Paulo Zanoni wrote:
> > 
> > Mahesh Kumar is already working on a proper implementation for the
> > workaround, but while we still don't have it, let's just
> > unconditionally apply the workaround for everybody and we hope we
> > can
> > close all those numerous bugzilla tickets. Also, I'm not sure how
> > easy
> > it will be to backport the final implementation to the stable
> > Kernels,
> > and this patch here is probably easier to backport.
> > 
> > At the present moment I still don't have confirmation that this
> > patch
> > fixes any of the bugs listed below, but we should definitely try
> > testing all of them again.
> > 
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94337
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94605
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94884
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95010
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96226
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96828
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97450
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97830
> > Cc: sta...@vger.kernel.org
> > Cc: Mahesh Kumar 
> > Cc: Lyude 
> > Cc: Dhinakaran Pandiyan 
> > Signed-off-by: Paulo Zanoni 
> > ---
> >  drivers/gpu/drm/i915/intel_pm.c | 49
> > ++---
> >  1 file changed, 41 insertions(+), 8 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index 62d730d..159831d 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -2879,6 +2879,21 @@ skl_wm_plane_id(const struct intel_plane
> > *plane)
> >     }
> >  }
> >  
> > +/*
> > + * FIXME: We still don't have the proper code detect if we need to
> > apply the WA,
> > + * so assume we'll always need it in order to avoid underruns.
> > + */
> > +static bool intel_needs_memory_bw_wa(struct intel_atomic_state
> > *state)
> > +{
> > +   struct drm_i915_private *dev_priv = to_i915(state-
> > > 
> > > base.dev);
> > +
> > +   if (IS_SKYLAKE(dev_priv) || IS_BROXTON(dev_priv) ||
> > +   IS_KABYLAKE(dev_priv))
> > +   return true;
> > +
> > +   return false;
> > +}
> > +
> >  static bool
> >  intel_has_sagv(struct drm_i915_private *dev_priv)
> >  {
> > @@ -2999,9 +3014,10 @@ bool intel_can_enable_sagv(struct
> > drm_atomic_state *state)
> >     struct drm_device *dev = state->dev;
> >     struct drm_i915_private *dev_priv = to_i915(dev);
> >     struct intel_atomic_state *intel_state =
> > to_intel_atomic_state(state);
> > -   struct drm_crtc *crtc;
> > +   struct intel_crtc *crtc;
> > +   struct intel_plane *plane;
> >     enum pipe pipe;
> > -   int level, plane;
> > +   int level, id, latency;
> >  
> >     if (!intel_has_sagv(dev_priv))
> >     return false;
> > @@ -3019,27 +3035,36 @@ bool intel_can_enable_sagv(struct
> > drm_atomic_state *state)
> >  
> >     /* Since we're now guaranteed to only have one active
> > CRTC... */
> >     pipe = ffs(intel_state->active_crtcs) - 1;
> > -   crtc = dev_priv->pipe_to_crtc_mapping[pipe];
> > +   crtc = to_intel_crtc(dev_priv-
> > >pipe_to_crtc_mapping[pipe]);
> >  
> > -   if (crtc->state->mode.flags & DRM_MODE_FLAG_INTERLACE)
> > +   if (crtc->base.state->mode.flags &
> > DRM_MODE_FLAG_INTERLACE)
> >     return false;
> >  
> > -   for_each_plane(dev_priv, pipe, plane) {
> > +   for_each_intel_plane_on_crtc(dev, crtc, plane) {
> > +   id = skl_wm_plane_id(plane);
> > +
> >     /* Skip this plane if it's not enabled */
> > -   if (intel_state->wm_results.plane[pipe][plane][0]
> > ==
> > 0)
> > +   if (intel_state->wm_results.plane[pipe][id][0] ==
> > 0)
> >     continue;
> >  
> >     /* Find the highest enabled wm level for this
> > plane
> > */
> >     for (level = ilk_wm_max_level(dev);
> > -    intel_state-
> > > 
> > > wm_results.plane[pipe][plane][level] == 0; --level)
> > +    intel_state-
> > >wm_results.plane[pipe][id][level]
> > == 0; --level)
> >      { }
> >  
> > +   latency = dev_priv->wm.skl_latency[level];
> > +
> > +   if (intel_needs_memory_bw_wa(intel_state) &&
> > +   plane->base.state->fb->modifier[0] ==
> > +   I915_FORMAT_MOD_X_TILED)
> > +   latency += 15;
> > +
> >     /*
> >      * If any of the planes on this pipe don't enable
> > wm
> > levels
> >      * that incur memory latencies higher then 30µs we
> > can't enable
> >  

Re: [Intel-gfx] [PATCH 1/4] drm/i915/fbc: update busy_bits even for GTT and flip flushes

[Zanoni, Paulo R]

Em Ter, 2016-03-22 às 12:13 +0100, Daniel Vetter escreveu:
> On Mon, Mar 21, 2016 at 04:26:54PM -0300, Paulo Zanoni wrote:
> > 
> > We ignore ORIGIN_GTT because the hardware tracking can recognize
> > GTT
> > writes and take care of them. We also ignore ORIGIN_FLIP because we
> > deal with flips without relying on the frontbuffer tracking
> > infrastructure. On the other hand, a flush is a flush and means
> > we're
> > good to go, so we need to update busy_bits in order to reflect
> > that,
> > even if we're not going to do anything else about it.
> > 
> > How to reproduce the bug fixed by this patch:
> >  - boot SKL up to the desktop environment
> >  - stop the display manager
> >  - run any of the igt/kms_frontbuffer_tracking/*fbc*onoff* subtests
> >  - the tests will fail
> > 
> > The steps above will create the right conditions for us to lose
> > track
> > of busy_bits. If you, for example, run the full set of FBC tests,
> > the
> > onoff subtests will succeed.
> > 
> > Also notice that the "bug" is that we'll just keep FBC disabled on
> > cases where it could be enabled, so it's not something the users
> > can
> > perceive, it just affects power consumption numbers on properly
> > configured machines.
> > 
> > Signed-off-by: Paulo Zanoni 
> Is this covered by your nasty igt test suite? Kernel side looks good,
> so
> with appropriate Testcase: tag added:

I mentioned the tests in the middle of the commit message, but forgot
the Testcase tags. I'll add them.

> 
> Reviewed-by: Daniel Vetter 

Thanks!

> 
> > 
> > ---
> >  drivers/gpu/drm/i915/intel_fbc.c | 7 ---
> >  1 file changed, 4 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_fbc.c
> > b/drivers/gpu/drm/i915/intel_fbc.c
> > index 2e571f5..b8ba79c 100644
> > --- a/drivers/gpu/drm/i915/intel_fbc.c
> > +++ b/drivers/gpu/drm/i915/intel_fbc.c
> > @@ -996,13 +996,13 @@ void intel_fbc_flush(struct drm_i915_private
> > *dev_priv,
> >     if (!fbc_supported(dev_priv))
> >     return;
> >  
> > -   if (origin == ORIGIN_GTT || origin == ORIGIN_FLIP)
> > -   return;
> > -
> >     mutex_lock(&fbc->lock);
> >  
> >     fbc->busy_bits &= ~frontbuffer_bits;
> >  
> > +   if (origin == ORIGIN_GTT || origin == ORIGIN_FLIP)
> > +   goto out;
> > +
> >     if (!fbc->busy_bits && fbc->enabled &&
> >     (frontbuffer_bits &
> > intel_fbc_get_frontbuffer_bit(fbc))) {
> >     if (fbc->active)
> > @@ -1011,6 +1011,7 @@ void intel_fbc_flush(struct drm_i915_private
> > *dev_priv,
> >     __intel_fbc_post_update(fbc->crtc);
> >     }
> >  
> > +out:
> >     mutex_unlock(&fbc->lock);
> >  }
> >  
> > -- 
> > 2.7.0
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC xf86-video-intel] sna: Call dirtyfb for all non-tear-free cases

[Zanoni, Paulo R]

Em Ter, 2016-03-22 às 12:31 +0100, Daniel Vetter escreveu:
> On Mon, Mar 21, 2016 at 04:26:55PM -0300, Paulo Zanoni wrote:
> > 
> > The sna_mode_wants_tear_free() function tries to detect FBC and PSR
> > based on Kernel module parameters. Currently it fails to detect FBC
> > due to the default enable_fbc value being -1. While this can easily
> > be
> > fixed in the Kernel, I had a conversation with Daniel and he
> > expressed
> > unhappiness with that solution, claiming that yet another different
> > code path just for a feature that should be transparent is not a
> > good
> > way to go, and that we should do proper frontbuffer rendering.
> > 
> > So with this patch, we'll have the DDX issuing dirtyfb calls even
> > if
> > TearFree is not enabled, fixing FBC when i915.enable_fbc=-1.
> > 
> > This fixes a bug that happens on SKL with FBC enabled: if you run
> > lightdm, your login/password won't appear as you type on your
> > keyboard. You have to move the mouse over the input box for them to
> > be
> > displayed.
> > 
> > Cc: Chris Wilson 
> > Signed-off-by: Paulo Zanoni 
> I thought we need this anyway to get the kernel to allow fbc, since
> SNA
> ends up mmap some of the drm_framebuffer. Even when they're not
> frontbuffers.

If we merge patch 2/4, we won't need this one since TearFree will be in
use, and it seems TearFree doesn't touch frontbuffers, so we'll always
get the flush calls during page flips.

> -Daniel
> 
> > 
> > ---
> >  src/sna/sna_driver.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/src/sna/sna_driver.c b/src/sna/sna_driver.c
> > index b245594..84e8e55 100644
> > --- a/src/sna/sna_driver.c
> > +++ b/src/sna/sna_driver.c
> > @@ -654,7 +654,7 @@ static Bool sna_pre_init(ScrnInfoPtr scrn, int
> > probe)
> >     }
> >     scrn->currentMode = scrn->modes;
> >  
> > -   if (!setup_tear_free(sna) &&
> > sna_mode_wants_tear_free(sna))
> > +   if (!setup_tear_free(sna))
> >     sna->kgem.needs_dirtyfb = sna->kgem.has_dirtyfb;
> >  
> >     xf86SetGamma(scrn, zeros);
> > -- 
> > 2.7.0
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/4] drm/i915: opt-out CPU and WC mmaps from FBC

[Zanoni, Paulo R]

Em Ter, 2016-03-22 às 12:29 +0100, Daniel Vetter escreveu:
> On Mon, Mar 21, 2016 at 04:26:57PM -0300, Paulo Zanoni wrote:
> > 
> > FBC and the frontbuffer tracking infrastructure were designed
> > assuming
> > that user space applications would follow a specific set of rules
> > regarding frontbuffer management and mmapping. I recently
> > discovered
> > that current user space is not exactly following these rules: my
> > investigation led me to the conclusion that the generic backend
> > from
> > SNA - used by SKL and the other new platforms without a specific
> > backend - is not issuing sw_finish/dirty_fb IOCTLs when using the
> > CPU
> > and WC mmaps. I discovered this when running lightdm: I would type
> > the
> > password and nothing would appear on the screen unless I moved the
> > mouse over the place where the letters were supposed to appear.
> > 
> > Since we can't detect whether the current DRM master is a well-
> > behaved
> > application or not, let's use the sledgehammer approach and assume
> > that every user space client on every gen is bad by disabling FBC
> > when
> > the frontbuffer is CPU/WC mmapped.  This will allow us to enable
> > FBC
> > on SKL, moving its FBC-related power savings from "always 0%" to ">
> > 0%
> > in some cases".
> > 
> > There's also some additional code to disable the workaround for
> > frontbuffers that ever received a sw_finish or dirty_fb IOCTL,
> > since
> > the current bad user space never issues those calls. This should
> > help
> > for some specific cases and our IGT tests, but won't be enough for
> > a
> > new xf86-video-intel using TearFree.
> > 
> > Notice that we may need an equivalent commit for PSR too. We also
> > need
> > to investigate whether PSR needs to be disabled on GTT mmaps: if
> > that's the case, we'll have problems since we seem to always have
> > GTT
> > mmaps on our current user space, so we would end up keeping PSR
> > disabled forever.
> > 
> > v2:
> >   - Rename some things.
> >   - Disable the WA on sw_finish/dirty_fb (Daniel).
> >   - Fix NULL obj checking.
> >   - Restric to Gen 9.
> > 
> > Cc: Rodrigo Vivi 
> > Cc: Daniel Vetter 
> > Cc: Chris Wilson 
> > Signed-off-by: Paulo Zanoni 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.h  |  9 +
> >  drivers/gpu/drm/i915/i915_gem.c  | 19 +++---
> >  drivers/gpu/drm/i915/intel_display.c |  1 +
> >  drivers/gpu/drm/i915/intel_drv.h |  3 +++
> >  drivers/gpu/drm/i915/intel_fbc.c | 33
> > 
> >  drivers/gpu/drm/i915/intel_frontbuffer.c | 31
> > ++
> >  6 files changed, 89 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index efca534..45e31d2 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -873,6 +873,13 @@ enum fb_op_origin {
> >     ORIGIN_DIRTYFB,
> >  };
> >  
> > +enum fb_mmap_wa_flags {
> > +   FB_MMAP_WA_CPU =1 << 0,
> > +   FB_MMAP_WA_GTT =1 << 1,
> > +   FB_MMAP_WA_DISABLE =    1 << 2,
> > +   FB_MMAP_WA_FLAG_COUNT = 3,
> > +};
> > +

I'll do the change to macros you/Jani mentioned in the other emails.

> >  struct intel_fbc {
> >     /* This is always the inner lock when overlapping with
> > struct_mutex and
> >      * it's the outer lock when overlapping with stolen_lock.
> > */
> > @@ -910,6 +917,7 @@ struct intel_fbc {
> >     unsigned int stride;
> >     int fence_reg;
> >     unsigned int tiling_mode;
> > +   unsigned int mmap_wa_flags;
> >     } fb;
> >     } state_cache;
> >  
> > @@ -2143,6 +2151,7 @@ struct drm_i915_gem_object {
> >     unsigned int cache_dirty:1;
> >  
> >     unsigned int frontbuffer_bits:INTEL_FRONTBUFFER_BITS;
> > +   unsigned int fb_mmap_wa_flags:FB_MMAP_WA_FLAG_COUNT;
> >  
> >     unsigned int pin_display;
> >  
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c
> > b/drivers/gpu/drm/i915/i915_gem.c
> > index 8588c83..d44f27e 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -1692,6 +1692,8 @@ i915_gem_sw_finish_ioctl(struct drm_device
> > *dev, void *data,
> >     goto unlock;
> >     }
> >  
> > +   intel_fb_obj_mmap_wa(obj, FB_MMAP_WA_DISABLE);
> > +
> >     /* Pinned buffers may be scanout, so flush the cache */
> >     if (obj->pin_display)
> >     i915_gem_object_flush_cpu_write_domain(obj);
> > @@ -1724,7 +1726,7 @@ i915_gem_mmap_ioctl(struct drm_device *dev,
> > void *data,
> >     struct drm_file *file)
> >  {
> >     struct drm_i915_gem_mmap *args = data;
> > -   struct drm_gem_object *obj;
> > +   struct drm_i915_gem_object *obj;
> >     unsigned long addr;
> >  
> >     if (args->flags & ~(I915_MMAP_WC))
> > @@ -1733,19 +1735,19 @@ i915_gem_mmap_ioctl(struct drm_device *dev,
> > void *data,
> >     if (args->flags & I915_MMAP_WC && !cpu_has_

Re: [Intel-gfx] [PATCH 4/4] drm/i915/fbc: enable FBC on SKL too

[Zanoni, Paulo R]

Em Ter, 2016-03-22 às 12:16 +0100, Daniel Vetter escreveu:
> On Mon, Mar 21, 2016 at 04:26:58PM -0300, Paulo Zanoni wrote:
> > 
> > Now that we're more protected against user space doing frontbuffer
> > mmap rendering, the last - how many times did I say this before? -
> > SKL problem seems to be solved. So let's give it a try.
> > 
> > If you reached this commit through git bisect or if you just want
> > more
> > information about FBC, please see:
> > commit a98ee79317b4091cafb502b4ffdbbbe1335e298c
> > Author: Paulo Zanoni 
> > Date:   Tue Feb 16 18:47:21 2016 -0200
> > drm/i915/fbc: enable FBC by default on HSW and BDW
> > 
> > Signed-off-by: Paulo Zanoni 
> > ---
> >  drivers/gpu/drm/i915/intel_fbc.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_fbc.c
> > b/drivers/gpu/drm/i915/intel_fbc.c
> > index 718ac38..67f8810 100644
> > --- a/drivers/gpu/drm/i915/intel_fbc.c
> > +++ b/drivers/gpu/drm/i915/intel_fbc.c
> > @@ -1270,7 +1270,8 @@ void intel_fbc_init(struct drm_i915_private
> > *dev_priv)
> >      * know what's going on. */
> >     if (i915.enable_fbc < 0) {
> >     i915.enable_fbc = IS_HASWELL(dev_priv) ||
> > -     IS_BROADWELL(dev_priv);
> > +     IS_BROADWELL(dev_priv) ||
> > +     IS_SKYLAKE(dev_priv);
> Can we just future-proof this and enable on everything gen8+ where we
> have
> fbc? Apparently bsw/bxt simply lack this ...

This can be done, but I'm not sure if it's a good idea, given FBC's
never-ending history of platform-specific workarounds. We'd force
people to have to have FBC working right from the start. Hmmm, that
could actually be a good thing, enforcing people to make features work.

> -Daniel
> 
> > 
> >     DRM_DEBUG_KMS("Sanitized enable_fbc value: %d\n",
> >       i915.enable_fbc);
> >     }
> > -- 
> > 2.7.0
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC xf86-video-intel] sna: Call dirtyfb for all non-tear-free cases

[Zanoni, Paulo R]

Em Qua, 2016-03-23 às 09:50 +0100, Daniel Vetter escreveu:
> On Tue, Mar 22, 2016 at 09:35:36PM +0000, Zanoni, Paulo R wrote:
> > 
> > Em Ter, 2016-03-22 às 12:31 +0100, Daniel Vetter escreveu:
> > > 
> > > On Mon, Mar 21, 2016 at 04:26:55PM -0300, Paulo Zanoni wrote:
> > > > 
> > > > 
> > > > The sna_mode_wants_tear_free() function tries to detect FBC and
> > > > PSR
> > > > based on Kernel module parameters. Currently it fails to detect
> > > > FBC
> > > > due to the default enable_fbc value being -1. While this can
> > > > easily
> > > > be
> > > > fixed in the Kernel, I had a conversation with Daniel and he
> > > > expressed
> > > > unhappiness with that solution, claiming that yet another
> > > > different
> > > > code path just for a feature that should be transparent is not
> > > > a
> > > > good
> > > > way to go, and that we should do proper frontbuffer rendering.
> > > > 
> > > > So with this patch, we'll have the DDX issuing dirtyfb calls
> > > > even
> > > > if
> > > > TearFree is not enabled, fixing FBC when i915.enable_fbc=-1.
> > > > 
> > > > This fixes a bug that happens on SKL with FBC enabled: if you
> > > > run
> > > > lightdm, your login/password won't appear as you type on your
> > > > keyboard. You have to move the mouse over the input box for
> > > > them to
> > > > be
> > > > displayed.
> > > > 
> > > > Cc: Chris Wilson 
> > > > Signed-off-by: Paulo Zanoni 
> > > I thought we need this anyway to get the kernel to allow fbc,
> > > since
> > > SNA
> > > ends up mmap some of the drm_framebuffer. Even when they're not
> > > frontbuffers.
> > If we merge patch 2/4, we won't need this one since TearFree will
> > be in
> > use, and it seems TearFree doesn't touch frontbuffers, so we'll
> > always
> > get the flush calls during page flips.
> I'd thought that TearFree would still do rendering with the cpu
> sometimes,
> but only always to the back buffer. So we'd still have cpu mmaps, and
> hence the kernel w/a would still potentially kick in and prevent fbc.
> So
> that's not the case then, and we get fbc reliably with the kernel
> patch,
> even without this patch?

Oh, you're right. But at least we won't have bugs, and we'll have FBC
on things like xf86-video-modesetting, which some distros seem to
already be using for SKL.

Well, now that I think a little more about this, maybe we could add
little hack to DDX so it does a single sw_finish/dirty_fb call to
TearFree framebuffers upon creation so the workaround gets disabled...
Hmm..

> -Daniel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v5 8/8] drm/i915: Remove vblank wait from hsw_enable_ips, v2.

[Zanoni, Paulo R]

Em Qua, 2016-03-23 às 14:33 +0100, Maarten Lankhorst escreveu:
> intel_post_plane_update did an extra vblank wait that's no longer
> needed when enabling ips.
> 
> Changes since v1:
> - Add comment explaining why vblank wait is performed. (Paulo)
> 
> Signed-off-by: Maarten Lankhorst 
> ---
> Noticed this one still in my branch, does this look ok?
> 
> ~Maarten
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index dc920cfc3fd7..6dcc159ce6ac 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -4454,8 +4454,11 @@ void hsw_enable_ips(struct intel_crtc *crtc)
>   if (!crtc->config->ips_enabled)
>   return;
>  
> - /* We can only enable IPS after we enable a plane and wait
> for a vblank */
> - intel_wait_for_vblank(dev, crtc->pipe);
> + /*
> +  * We can only enable IPS after we enable a plane and wait
> for a vblank
> +  * This function is called from post_plane_update, which is
> run after
> +  * a vblank wait.
> +  */

There are actually other callers, such as intel_dp.c, but I suppose
they are correct since they can only be called when the planes are
already enabled, so:

Reviewed-by: Paulo Zanoni 

>  
>   assert_plane_enabled(dev_priv, crtc->plane);
>   if (IS_BROADWELL(dev)) {
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2] drm/i915: Disable FDI RX before DDI_BUF_CTL

[Zanoni, Paulo R]

Em Ter, 2016-03-01 às 16:16 +0200, ville.syrj...@linux.intel.com
escreveu:
> From: Ville Syrjälä 
> 
> Bspec is confused w.r.t. the HSW/BDW FDI disable sequence. It lists
> FDI RX disable both as step 13 and step 18 in the sequence. But I dug
> up an old BUN mail from Art that moved the FDI RX disable to happen
> before DDI_BUF_CTL disable. That BUN did not renumber the steps and
> just
> added a note:
> "Workaround: Disable PCH FDI Receiver before disabling DDI_BUF_CTL."
> 
> The BUN described the symptoms of the fixed issue as:
> "PCH display underflow and a black screen on the analog CRT port that
> happened after a FDI re-train"
> 
> I suppose later someone tried to renumber the steps to match, but
> forgot
> to remove the FDI RX disable from its old position in the sequence.
> 
> They also forgot to update the note describing what should be done in
> case of an FDI training failure. Currently it says:
> "To retry FDI training, follow the Disable Sequence steps to Disable
> FDI,
> but skip the steps related to clocks and PLLs (16, 19, and 20), ..."
> 
> It should really say "17, 20, and 21" with the current sequence
> because
> those are the steps that deal with PLLs and whatnot, after step 13
> became
> FDI RX disable. And had the step 18 FDI RX disable been removed, as I
> suspect it should have, the note should actually say "17, 19, and
> 20".
> 
> So, let's move the FDI RX disable to happen before DDI_BUF_CTL
> disable,
> as that would appear to be the correct order based on the BUN.
> 
> Note that Art has since unconfused the spec, and so this patch should
> now match the steps listed in the spec.

The sentence above basically says: "forget all the previous paragraphs
of this commit message since they're just history and go read BSpec
since it's now correct" :)

> 
> v2: Add a note that the spec is now correct

With or without changes:
Reviewed-by: Paulo Zanoni 


> 
> Cc: Paulo Zanoni 
> Cc: Art Runyan 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/intel_ddi.c | 18 --
>  1 file changed, 12 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 21a9b83f3bfc..fc4ca50f7159 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -629,6 +629,10 @@ void hsw_fdi_link_train(struct drm_crtc *crtc)
>   break;
>   }
>  
> + rx_ctl_val &= ~FDI_RX_ENABLE;
> + I915_WRITE(FDI_RX_CTL(PIPE_A), rx_ctl_val);
> + POSTING_READ(FDI_RX_CTL(PIPE_A));
> +
>   temp = I915_READ(DDI_BUF_CTL(PORT_E));
>   temp &= ~DDI_BUF_CTL_ENABLE;
>   I915_WRITE(DDI_BUF_CTL(PORT_E), temp);
> @@ -643,10 +647,6 @@ void hsw_fdi_link_train(struct drm_crtc *crtc)
>  
>   intel_wait_ddi_buf_idle(dev_priv, PORT_E);
>  
> - rx_ctl_val &= ~FDI_RX_ENABLE;
> - I915_WRITE(FDI_RX_CTL(PIPE_A), rx_ctl_val);
> - POSTING_READ(FDI_RX_CTL(PIPE_A));
> -
>   /* Reset FDI_RX_MISC pwrdn lanes */
>   temp = I915_READ(FDI_RX_MISC(PIPE_A));
>   temp &= ~(FDI_RX_PWRDN_LANE1_MASK |
> FDI_RX_PWRDN_LANE0_MASK);
> @@ -3078,12 +3078,18 @@ void intel_ddi_fdi_disable(struct drm_crtc
> *crtc)
>   struct intel_encoder *intel_encoder =
> intel_ddi_get_crtc_encoder(crtc);
>   uint32_t val;
>  
> - intel_ddi_post_disable(intel_encoder);
> -
> + /*
> +  * Bspec lists this as both step 13 (before DDI_BUF_CTL
> disable)
> +  * and step 18 (after clearing PORT_CLK_SEL). Based on a
> BUN,
> +  * step 13 is the correct place for it. Step 18 is where it
> was
> +  * originally before the BUN.
> +  */
>   val = I915_READ(FDI_RX_CTL(PIPE_A));
>   val &= ~FDI_RX_ENABLE;
>   I915_WRITE(FDI_RX_CTL(PIPE_A), val);
>  
> + intel_ddi_post_disable(intel_encoder);
> +
>   val = I915_READ(FDI_RX_MISC(PIPE_A));
>   val &= ~(FDI_RX_PWRDN_LANE1_MASK | FDI_RX_PWRDN_LANE0_MASK);
>   val |= FDI_RX_PWRDN_LANE1_VAL(2) |
> FDI_RX_PWRDN_LANE0_VAL(2);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2] drm/i915: Disable FDI RX before DDI_BUF_CTL

[Zanoni, Paulo R]

Em Qua, 2016-03-23 às 23:57 +0200, Ville Syrjälä escreveu:
> On Wed, Mar 23, 2016 at 09:14:34PM +0000, Zanoni, Paulo R wrote:
> > 
> > Em Ter, 2016-03-01 às 16:16 +0200, ville.syrj...@linux.intel.com
> > escreveu:
> > > 
> > > From: Ville Syrjälä 
> > > 
> > > Bspec is confused w.r.t. the HSW/BDW FDI disable sequence. It
> > > lists
> > > FDI RX disable both as step 13 and step 18 in the sequence. But I
> > > dug
> > > up an old BUN mail from Art that moved the FDI RX disable to
> > > happen
> > > before DDI_BUF_CTL disable. That BUN did not renumber the steps
> > > and
> > > just
> > > added a note:
> > > "Workaround: Disable PCH FDI Receiver before disabling
> > > DDI_BUF_CTL."
> > > 
> > > The BUN described the symptoms of the fixed issue as:
> > > "PCH display underflow and a black screen on the analog CRT port
> > > that
> > > happened after a FDI re-train"
> > > 
> > > I suppose later someone tried to renumber the steps to match, but
> > > forgot
> > > to remove the FDI RX disable from its old position in the
> > > sequence.
> > > 
> > > They also forgot to update the note describing what should be
> > > done in
> > > case of an FDI training failure. Currently it says:
> > > "To retry FDI training, follow the Disable Sequence steps to
> > > Disable
> > > FDI,
> > > but skip the steps related to clocks and PLLs (16, 19, and 20),
> > > ..."
> > > 
> > > It should really say "17, 20, and 21" with the current sequence
> > > because
> > > those are the steps that deal with PLLs and whatnot, after step
> > > 13
> > > became
> > > FDI RX disable. And had the step 18 FDI RX disable been removed,
> > > as I
> > > suspect it should have, the note should actually say "17, 19, and
> > > 20".
> > > 
> > > So, let's move the FDI RX disable to happen before DDI_BUF_CTL
> > > disable,
> > > as that would appear to be the correct order based on the BUN.
> > > 
> > > Note that Art has since unconfused the spec, and so this patch
> > > should
> > > now match the steps listed in the spec.
> > The sentence above basically says: "forget all the previous
> > paragraphs
> > of this commit message since they're just history and go read BSpec
> > since it's now correct" :)
> Hmm, yeah I guess I was a bit lazy here. I suppose rewriting it a bit
> would be warranted. Maybe something like this?
> 
> "HSW/BDW FDI disable sequence was revised such that FDI RX should
> be disabled already before disabling DDI_BUF_CTL. Let's do that.
> 
> Note that the numbering of the FDI disable sequence steps in Bspec
> was confusing for the longest time. Basically the numbering was only
> partially updated to account for the new sequence, and thus some
> parts of the text still referred to things by the old numbers.
> Art has fixed that up, and the sequence is now clear."
> 
> I could toss in a References: to this mail thread in case someone is
> more interested in the acheological details.
> 
> 
> One slight concern is that the PRMs aren't uptodate. The HSW one
> has the BUN w/a note without the renumbering so it's actually
> technically correct. The BDW one has the renumbering which means
> it has the incorrect note about which steps to skip the retrying
> the FDI training. Rodrigo, do we have some way to get that refreshed?

This would be an argument in favor of keeping your old commit message,
actually (or writing a third version).

The R-B stands both with the new and the old message, so I'll just
trust you'll decide whatever seems better, even if you decide to change
again, so feel free to merge.

> 
> > 
> > 
> > > 
> > > 
> > > v2: Add a note that the spec is now correct
> > With or without changes:
> > Reviewed-by: Paulo Zanoni 
> > 
> > 
> > > 
> > > 
> > > Cc: Paulo Zanoni 
> > > Cc: Art Runyan 
> > > Signed-off-by: Ville Syrjälä 
> > > ---
> > >  drivers/gpu/drm/i915/intel_ddi.c | 18 --
> > >  1 file changed, 12 insertions(+), 6 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> > > b/drivers/gpu/drm/i915/intel_ddi.c
> > > index 21a9b83f3bfc..fc4ca50f7159 100644
> > > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > > +++ b/drivers/gpu/dr

Re: [Intel-gfx] [PATCH 3/4] drm/i915: opt-out CPU and WC mmaps from FBC

[Zanoni, Paulo R]

Em Qui, 2016-03-24 às 19:31 +, Chris Wilson escreveu:
> On Thu, Mar 24, 2016 at 04:16:11PM -0300, Paulo Zanoni wrote:
> > 
> > FBC and the frontbuffer tracking infrastructure were designed
> > assuming
> > that user space applications would follow a specific set of rules
> > regarding frontbuffer management and mmapping. I recently
> > discovered
> > that current user space is not exactly following these rules: my
> > investigation led me to the conclusion that the generic backend
> > from
> > SNA - used by SKL and the other new platforms without a specific
> > backend - is not issuing sw_finish/dirty_fb IOCTLs when using the
> > CPU
> > and WC mmaps. I discovered this when running lightdm: I would type
> > the
> > password and nothing would appear on the screen unless I moved the
> > mouse over the place where the letters were supposed to appear.
> Yes, that is a kernel bug. The protocol we said the kernel would
> follow
> is to disable FBC/WC when userspace marks the object for writing by
> the
> CPU and would only reestablish FBC/WC upon dirtyfb.

But on WC mmaps we mark the object for writing by the GTT instead of
the CPU, and while the tracking engine is able to see "normal" GTT mmap
writes, it's not able to see WC mmap writes, so we established that
we'd call dirtyfb after frontbuffer drawing through WC mmaps, which is
something that the DDX never implemented. This was discussed on #intel-
gfx on Nov 5 2014, and also possibly other places, but I can't find the
logs. Daniel also confirmed this to me again on private IRC on Jun 16
2015. So I still don't understand why this is a Kernel bug instead of a
DDX bug.

> -Chris
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/4] drm/i915: opt-out CPU and WC mmaps from FBC

[Zanoni, Paulo R]

Em Qui, 2016-03-24 às 21:03 +, ch...@chris-wilson.co.uk escreveu:
> On Thu, Mar 24, 2016 at 08:53:21PM +0000, Zanoni, Paulo R wrote:
> > 
> > Em Qui, 2016-03-24 às 19:31 +, Chris Wilson escreveu:
> > > 
> > > On Thu, Mar 24, 2016 at 04:16:11PM -0300, Paulo Zanoni wrote:
> > > > 
> > > > 
> > > > FBC and the frontbuffer tracking infrastructure were designed
> > > > assuming
> > > > that user space applications would follow a specific set of
> > > > rules
> > > > regarding frontbuffer management and mmapping. I recently
> > > > discovered
> > > > that current user space is not exactly following these rules:
> > > > my
> > > > investigation led me to the conclusion that the generic backend
> > > > from
> > > > SNA - used by SKL and the other new platforms without a
> > > > specific
> > > > backend - is not issuing sw_finish/dirty_fb IOCTLs when using
> > > > the
> > > > CPU
> > > > and WC mmaps. I discovered this when running lightdm: I would
> > > > type
> > > > the
> > > > password and nothing would appear on the screen unless I moved
> > > > the
> > > > mouse over the place where the letters were supposed to appear.
> > > Yes, that is a kernel bug. The protocol we said the kernel would
> > > follow
> > > is to disable FBC/WC when userspace marks the object for writing
> > > by
> > > the
> > > CPU and would only reestablish FBC/WC upon dirtyfb.
> > But on WC mmaps we mark the object for writing by the GTT instead
> > of
> > the CPU, and while the tracking engine is able to see "normal" GTT
> > mmap
> > writes, it's not able to see WC mmap writes, so we established that
> > we'd call dirtyfb after frontbuffer drawing through WC mmaps, which
> > is
> > something that the DDX never implemented. This was discussed on
> > #intel-
> > gfx on Nov 5 2014, and also possibly other places, but I can't find
> > the
> > logs. Daniel also confirmed this to me again on private IRC on Jun
> > 16
> > 2015. So I still don't understand why this is a Kernel bug instead
> > of a
> > DDX bug.
> Because we said that once invalidated, it would not be restored until
> dirtyfb. The kernel is not doing that. Your patch does not do that.
> To
> be even close, you should be setting the origin flag based on the
> existence
> of wc mmaping for the object inside set-to-gtt-domain. Otherwise, you
> are not implementing even close to the protocol you say you are. That
> is
> invalidate on set-domain, flush on dirtyfb.

I don't recall this being said in the earlier conversations, but now
that you point it, it can be done. Also, we recently pinged/emailed you
many times about this problem, so I wonder why it took you so long to
point this...

> 
> The kernel's bug is that is not cancelling FBC. Userspace's bug is
> not
> signalling when to reenable it.

So at least you agree user space was missing something :)

> -Chris
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/4] drm/i915: opt-out CPU and WC mmaps from FBC

[Zanoni, Paulo R]

Em Qui, 2016-03-24 às 21:20 +, ch...@chris-wilson.co.uk escreveu:
> On Thu, Mar 24, 2016 at 09:03:59PM +, ch...@chris-wilson.co.uk
> wrote:
> > 
> > On Thu, Mar 24, 2016 at 08:53:21PM +0000, Zanoni, Paulo R wrote:
> > > 
> > > Em Qui, 2016-03-24 às 19:31 +, Chris Wilson escreveu:
> > > > 
> > > > On Thu, Mar 24, 2016 at 04:16:11PM -0300, Paulo Zanoni wrote:
> > > > > 
> > > > > 
> > > > > FBC and the frontbuffer tracking infrastructure were designed
> > > > > assuming
> > > > > that user space applications would follow a specific set of
> > > > > rules
> > > > > regarding frontbuffer management and mmapping. I recently
> > > > > discovered
> > > > > that current user space is not exactly following these rules:
> > > > > my
> > > > > investigation led me to the conclusion that the generic
> > > > > backend
> > > > > from
> > > > > SNA - used by SKL and the other new platforms without a
> > > > > specific
> > > > > backend - is not issuing sw_finish/dirty_fb IOCTLs when using
> > > > > the
> > > > > CPU
> > > > > and WC mmaps. I discovered this when running lightdm: I would
> > > > > type
> > > > > the
> > > > > password and nothing would appear on the screen unless I
> > > > > moved the
> > > > > mouse over the place where the letters were supposed to
> > > > > appear.
> > > > Yes, that is a kernel bug. The protocol we said the kernel
> > > > would
> > > > follow
> > > > is to disable FBC/WC when userspace marks the object for
> > > > writing by
> > > > the
> > > > CPU and would only reestablish FBC/WC upon dirtyfb.
> > > But on WC mmaps we mark the object for writing by the GTT instead
> > > of
> > > the CPU, and while the tracking engine is able to see "normal"
> > > GTT mmap
> > > writes, it's not able to see WC mmap writes, so we established
> > > that
> > > we'd call dirtyfb after frontbuffer drawing through WC mmaps,
> > > which is
> > > something that the DDX never implemented. This was discussed on
> > > #intel-
> > > gfx on Nov 5 2014, and also possibly other places, but I can't
> > > find the
> > > logs. Daniel also confirmed this to me again on private IRC on
> > > Jun 16
> > > 2015. So I still don't understand why this is a Kernel bug
> > > instead of a
> > > DDX bug.
> > Because we said that once invalidated, it would not be restored
> > until
> > dirtyfb. The kernel is not doing that. Your patch does not do that.
> > To
> > be even close, you should be setting the origin flag based on the
> > existence
> > of wc mmaping for the object inside set-to-gtt-domain. Otherwise,
> > you
> > are not implementing even close to the protocol you say you are.
> > That is
> > invalidate on set-domain, flush on dirtyfb.
> > 
> > The kernel's bug is that is not cancelling FBC. Userspace's bug is
> > not
> > signalling when to reenable it.
> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> b/drivers/gpu/drm/i915/i915_drv.h
> index 8dec2e8..0314346 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2145,6 +2145,7 @@ struct drm_i915_gem_object {
> unsigned int cache_dirty:1;
>  
> unsigned int frontbuffer_bits:INTEL_FRONTBUFFER_BITS;
> +   unsigned int has_wc_mmap:1;
>  
> /** Count of VMA actually bound by this object */
> unsigned int bind_count;
> diff --git a/drivers/gpu/drm/i915/i915_gem.c
> b/drivers/gpu/drm/i915/i915_gem.c
> index 05ae706..29ca96d 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -1310,6 +1310,13 @@ unlock:
> return ret;
>  }
>  
> +static enum fb_op_origin
> +write_origin(struct drm_i915_gem_object *obj, unsigned domain)
> +{
> +   return domain == I915_GEM_DOMAIN_GTT && !obj->has_wc_mmap ?
> + ORIGIN_GTT : ORIGIN_CPU;

What if I have both a WC mmap and a GTT mmap, and I'm actually using
the GTT mmap now? My set_domain call will be treated as WC mmap usage,
while in fact it should be treated as GTT usage. Is there a way to
differentiate between them with the current set_domain API?


> +}
> +
>  /**
>   * Called when user space prepares t

Re: [Intel-gfx] [PATCH 1/4] drm: Add helper for DP++ adaptors

[Zanoni, Paulo R]

Em Ter, 2016-02-23 às 18:46 +0200, ville.syrj...@linux.intel.com
escreveu:
> From: Ville Syrjälä 
> 
> Add a helper which aids in he identification of DP dual mode (aka.
> DP++)
> adaptors. There are several types of adaptors specified:
> type 1 DVI, type 1 HDMI, type 2 DVI, type 2 HDMI
> 
> Type 1 adaptors have a max TMDS clock limit of 165MHz, type 2
> adaptors
> may go as high as 300MHz and they provide a register informing the
> source device what the actual limit is. Supposedly also type 1
> adaptors
> may optionally implement this register. This TMDS clock limit is the
> main reason why we need to identify these adaptors.
> 
> Type 1 adaptors provide access to their internal registers and the
> sink
> DDC bus through I2C. Type 2 adaptors provide this access both via I2C
> and I2C-over-AUX. A type 2 source device may choose to implement
> either
> or both of these methods. If a source device implements only the
> I2C-over-AUX method, then the driver will obviously need specific
> support for such adaptors since the port is driven like an HDMI port,
> but DDC communication happes over the AUX channel.
> 
> This helper should be enough to identify the adaptor type (some
> type 1 DVI adaptors may be a slight exception) and the maximum TMDS
> clock limit. Another feature that may be available is control over
> the TMDS output buffers on the adaptor, possibly allowing for some
> power saving when the TMDS link is down.
> 
> Other user controllable features that may be available in the
> adaptors
> are downstream i2c bus speed control when using i2c-over-aux, and
> some control over the CEC pin. I chose not to provide any helper
> functions for those since I have no use for them in i915 at this
> time.
> The rest of the registers in the adaptor are mostly just information,
> eg. IEEE OUI, hardware and firmware revision, etc.

Please run a spell checker and do some proof-reading both in the commit
message and in the code comments. Multiple instances of "sizo",
"Hoever", "adator", "Identyfy", etc. I also spotted some typos in the
next commits.



> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/Makefile  |   2 +-
>  drivers/gpu/drm/drm_dp_dual_mode_helper.c | 328
> ++
>  include/drm/drm_dp_dual_mode_helper.h |  80 
>  3 files changed, 409 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/gpu/drm/drm_dp_dual_mode_helper.c
>  create mode 100644 include/drm/drm_dp_dual_mode_helper.h
> 
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 6eb94fc561dc..8ef50f36 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -23,7 +23,7 @@ drm-$(CONFIG_AGP) += drm_agpsupport.o
>  
>  drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o
> drm_probe_helper.o \
>   drm_plane_helper.o drm_dp_mst_topology.o
> drm_atomic_helper.o \
> - drm_kms_helper_common.o
> + drm_kms_helper_common.o drm_dp_dual_mode_helper.o
>  
>  drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
>  drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o
> diff --git a/drivers/gpu/drm/drm_dp_dual_mode_helper.c
> b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
> new file mode 100644
> index ..bfe511c09568
> --- /dev/null
> +++ b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
> @@ -0,0 +1,328 @@
> +/*
> + * Copyright © 2016 Intel Corporation
> + *
> + * Permission is hereby granted, free of charge, to any person
> obtaining a
> + * copy of this software and associated documentation files (the
> "Software"),
> + * to deal in the Software without restriction, including without
> limitation
> + * the rights to use, copy, modify, merge, publish, distribute,
> sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom
> the
> + * Software is furnished to do so, subject to the following
> conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO
> EVENT SHALL
> + * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM,
> DAMAGES OR
> + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
> OTHERWISE,
> + * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
> USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/**
> + * DOC: DP dual mode (aka. DP++) adaptor helpers
> + *
> + * Helper functions to deal with DP dual mode adaptors.
> + *
> + * Type 1:
> + * Adaptor registers (if any) and the sink DDC bus may be accessed
> via I2C.
> + *
> + * Type 2:
> + * Adaptor registers and sink DDC bus can be acces

Re: [Intel-gfx] [PATCH v2 3/4] drm/i915: Enable/disable TMDS output buffers in DP++ adaptor as needed

[Zanoni, Paulo R]

Em Qui, 2016-02-25 às 14:51 +0200, ville.syrj...@linux.intel.com
escreveu:
> From: Ville Syrjälä 
> 
> To save a bit of power, let's try to turn off the TMDS output buffers
> in DP++ adaptors when we're not driving the port.
> 
> v2: Let's not forget DDI, toss in a debug message while at it
> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/intel_ddi.c  | 12 
>  drivers/gpu/drm/i915/intel_drv.h  |  2 ++
>  drivers/gpu/drm/i915/intel_hdmi.c | 31
> +--
>  3 files changed, 43 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 21a9b83f3bfc..458c41788b80 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -2301,6 +2301,12 @@ static void intel_ddi_pre_enable(struct
> intel_encoder *intel_encoder)
>   enum port port = intel_ddi_get_encoder_port(intel_encoder);
>   int type = intel_encoder->type;
>  
> + if (type == INTEL_OUTPUT_HDMI) {
> + struct intel_hdmi *intel_hdmi =
> enc_to_intel_hdmi(encoder);
> +
> + intel_dp_dual_mode_set_tmds_output(intel_hdmi,
> true);
> + }
> +
>   intel_prepare_ddi_buffer(intel_encoder);
>  
>   if (type == INTEL_OUTPUT_EDP) {
> @@ -2367,6 +2373,12 @@ static void intel_ddi_post_disable(struct
> intel_encoder *intel_encoder)
>   DPLL_CTRL2_DDI_CLK_OFF(port)
> ));
>   else if (INTEL_INFO(dev)->gen < 9)
>   I915_WRITE(PORT_CLK_SEL(port), PORT_CLK_SEL_NONE);
> +
> + if (type == INTEL_OUTPUT_HDMI) {
> + struct intel_hdmi *intel_hdmi =
> enc_to_intel_hdmi(encoder);
> +
> + intel_dp_dual_mode_set_tmds_output(intel_hdmi,
> false);
> + }
>  }
>  
>  static void intel_enable_ddi(struct intel_encoder *intel_encoder)
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 944eacbfb6a9..2e4fa4337c59 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -706,6 +706,7 @@ struct intel_hdmi {
>   int ddc_bus;
>   struct {
>   int max_tmds_clock;
> + bool tmds_output_control;
>   } dp_dual_mode;
>   bool limited_color_range;
>   bool color_range_auto;
> @@ -1355,6 +1356,7 @@ void intel_hdmi_init_connector(struct
> intel_digital_port *intel_dig_port,
>  struct intel_hdmi *enc_to_intel_hdmi(struct drm_encoder *encoder);
>  bool intel_hdmi_compute_config(struct intel_encoder *encoder,
>      struct intel_crtc_state
> *pipe_config);
> +void intel_dp_dual_mode_set_tmds_output(struct intel_hdmi *hdmi,
> bool enable);
>  
>  
>  /* intel_lvds.c */
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index 1e8cfdb18dc7..4b528a669f8e 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -837,6 +837,20 @@ static void hsw_set_infoframes(struct
> drm_encoder *encoder,
>   intel_hdmi_set_hdmi_infoframe(encoder, adjusted_mode);
>  }
>  
> +void intel_dp_dual_mode_set_tmds_output(struct intel_hdmi *hdmi,
> bool enable)
> +{
> + if (hdmi->dp_dual_mode.tmds_output_control) {

Or you could just do an early return here and save an indentation level
:)

> + struct drm_i915_private *dev_priv =
> to_i915(intel_hdmi_to_dev(hdmi));
> + struct i2c_adapter *adapter =
> + intel_gmbus_get_adapter(dev_priv, hdmi-
> >ddc_bus);
> +
> + DRM_DEBUG_KMS("%s DP dual mode adaptor TMDS
> output\n",
> +   enable ? "Enabling" : "Disabling");
> +
> + drm_dp_dual_mode_set_tmds_output(adapter, enable);
> + }
> +}
> +
>  static void intel_hdmi_prepare(struct intel_encoder *encoder)
>  {
>   struct drm_device *dev = encoder->base.dev;
> @@ -846,6 +860,8 @@ static void intel_hdmi_prepare(struct
> intel_encoder *encoder)
>   const struct drm_display_mode *adjusted_mode = &crtc-
> >config->base.adjusted_mode;
>   u32 hdmi_val;
>  
> + intel_dp_dual_mode_set_tmds_output(intel_hdmi, true);
> +
>   hdmi_val = SDVO_ENCODING_HDMI;
>   if (!HAS_PCH_SPLIT(dev) && crtc->config-
> >limited_color_range)
>   hdmi_val |= HDMI_COLOR_RANGE_16_235;
> @@ -1144,6 +1160,8 @@ static void intel_disable_hdmi(struct
> intel_encoder *encoder)
>   }
>  
>   intel_hdmi->set_infoframes(&encoder->base, false, NULL);
> +
> + intel_dp_dual_mode_set_tmds_output(intel_hdmi, false);
>  }
>  
>  static void g4x_disable_hdmi(struct intel_encoder *encoder)
> @@ -1369,6 +1387,7 @@ intel_hdmi_unset_edid(struct drm_connector
> *connector)
>   intel_hdmi->rgb_quant_range_selectable = false;
>  
>   intel_hdmi->dp_dual_mode.max_tmds_clock = 0;
> + intel_hdmi->dp_dual_mode.tmds_output_control = false;
>  
>   kfree(to_intel_connector(connector)->detect_edid);
>   to_intel_connector(connector)->detect_edi

Re: [Intel-gfx] [PATCH 4/4] drm/i915: Determine DP++ type 1 DVI adaptor presence based on VBT

[Zanoni, Paulo R]

Em Ter, 2016-02-23 às 18:46 +0200, ville.syrj...@linux.intel.com
escreveu:
> From: Ville Syrjälä 
> 
> DP dual mode type 1 DVI adaptors aren't required to implement any
> registers, so it's a bit hard to detect them. The best way would
> be to check the state of the CONFIG1 pin, but we have no way to
> do that. So as a last resort, check the VBT to see if the HDMI
> port is in fact a dual mode capable DP port.
> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/intel_bios.h |  3 +++
>  drivers/gpu/drm/i915/intel_dp.c   | 28 
>  drivers/gpu/drm/i915/intel_drv.h  |  1 +
>  drivers/gpu/drm/i915/intel_hdmi.c | 23 +--
>  4 files changed, 53 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_bios.h
> b/drivers/gpu/drm/i915/intel_bios.h
> index 350d4e0f75a4..50d1659efe47 100644
> --- a/drivers/gpu/drm/i915/intel_bios.h
> +++ b/drivers/gpu/drm/i915/intel_bios.h
> @@ -730,6 +730,7 @@ struct bdb_psr {
>  #define   DEVICE_TYPE_INT_TV 0x1009
>  #define   DEVICE_TYPE_HDMI   0x60D2
>  #define   DEVICE_TYPE_DP 0x68C6
> +#define   DEVICE_TYPE_DP_DUAL_MODE   0x60D6
>  #define   DEVICE_TYPE_eDP0x78C6
>  
>  #define  DEVICE_TYPE_CLASS_EXTENSION (1 << 15)
> @@ -764,6 +765,8 @@ struct bdb_psr {
>    DEVICE_TYPE_DISPLAYPORT_OUTPUT | \
>    DEVICE_TYPE_ANALOG_OUTPUT)
>  
> +#define DEVICE_TYPE_DP_DUAL_MODE_BITS ~DEVICE_TYPE_NOT_HDMI_OUTPUT
> +
>  /* define the DVO port for HDMI output type */
>  #define  DVO_B   1
>  #define  DVO_C   2
> diff --git a/drivers/gpu/drm/i915/intel_dp.c
> b/drivers/gpu/drm/i915/intel_dp.c
> index cbc06596659a..f3edacf517ac 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -5104,6 +5104,34 @@ bool intel_dp_is_edp(struct drm_device *dev,
> enum port port)
>   return false;
>  }
>  
> +bool intel_dp_is_dual_mode(struct drm_i915_private *dev_priv, enum
> port port)
> +{
> + const union child_device_config *p_child;
> + int i;
> + static const short port_mapping[] = {
> + [PORT_B] = DVO_PORT_DPB,
> + [PORT_C] = DVO_PORT_DPC,
> + [PORT_D] = DVO_PORT_DPD,
> + [PORT_E] = DVO_PORT_DPE,
> + };
> +
> + if (port == PORT_A || port >= ARRAY_SIZE(port_mapping))
> + return false;
> +
> + if (!dev_priv->vbt.child_dev_num)
> + return false;
> +
> + for (i = 0; i < dev_priv->vbt.child_dev_num; i++) {
> + p_child = &dev_priv->vbt.child_dev[i];
> +
> + if (p_child->common.dvo_port == port_mapping[port]
> &&
> + (p_child->common.device_type &
> DEVICE_TYPE_DP_DUAL_MODE_BITS) ==
> + (DEVICE_TYPE_DP_DUAL_MODE &
> DEVICE_TYPE_DP_DUAL_MODE_BITS))
> + return true;
> + }

Some thoughts:

This is going to be implemented for all VBT versions. Since there's no
real history about anything before version 155, is this really what we
want? A huge part of the "we don't trust the VBT" culture we have on
our team is because of those old versions being completely unreliable.
If this is the case, we could make this implementation just be a small
patch in parse_ddi_port(). I'm kinda afraid we may somehow break old
machines yet again.

- Instead of creating these complicated bit masks, why don't we just
specifically check "if bit 2 and bit 4 are enabled, we're using an
adaptor"? Much simpler IMHO.

- Jani's recent patch suggests you may want to move this function to
intel_bios.c in order to avoid including intel_vbt_defs.h from
intel_hdmi.c. Anyway, you'll have to rebase.

> + return false;
> +}
> +
>  void
>  intel_dp_add_properties(struct intel_dp *intel_dp, struct
> drm_connector *connector)
>  {
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 3ca29a181e64..c7d1ea4dbe42 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1248,6 +1248,7 @@ int intel_dp_sink_crc(struct intel_dp
> *intel_dp, u8 *crc);
>  bool intel_dp_compute_config(struct intel_encoder *encoder,
>    struct intel_crtc_state *pipe_config);
>  bool intel_dp_is_edp(struct drm_device *dev, enum port port);
> +bool intel_dp_is_dual_mode(struct drm_i915_private *dev_priv, enum
> port port);
>  enum irqreturn intel_dp_hpd_pulse(struct intel_digital_port
> *intel_dig_port,
>     bool long_hpd);
>  void intel_edp_backlight_on(struct intel_dp *intel_dp);
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index 660a65f48fd8..1476f3afb7e2 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -1390,14 +1390,33 @@ intel_hdmi_unset_edid(struct drm_connector
> *connector)
>  }
>  
>  static void
> -intel_hdmi_dp_dual_mode_detect(struct drm_connector *connector)
> +intel_

Re: [Intel-gfx] [PATCH 4/4] drm/i915: Determine DP++ type 1 DVI adaptor presence based on VBT

[Zanoni, Paulo R]

Em Sex, 2016-04-01 às 17:45 +0300, Ville Syrjälä escreveu:
> On Thu, Mar 31, 2016 at 10:06:37PM +0000, Zanoni, Paulo R wrote:
> > 
> > Em Ter, 2016-02-23 às 18:46 +0200, ville.syrj...@linux.intel.com
> > escreveu:
> > > 
> > > From: Ville Syrjälä 
> > > 
> > > DP dual mode type 1 DVI adaptors aren't required to implement any
> > > registers, so it's a bit hard to detect them. The best way would
> > > be to check the state of the CONFIG1 pin, but we have no way to
> > > do that. So as a last resort, check the VBT to see if the HDMI
> > > port is in fact a dual mode capable DP port.
> > > 
> > > Signed-off-by: Ville Syrjälä 
> > > ---
> > >  drivers/gpu/drm/i915/intel_bios.h |  3 +++
> > >  drivers/gpu/drm/i915/intel_dp.c   | 28
> > > 
> > >  drivers/gpu/drm/i915/intel_drv.h  |  1 +
> > >  drivers/gpu/drm/i915/intel_hdmi.c | 23 +--
> > >  4 files changed, 53 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_bios.h
> > > b/drivers/gpu/drm/i915/intel_bios.h
> > > index 350d4e0f75a4..50d1659efe47 100644
> > > --- a/drivers/gpu/drm/i915/intel_bios.h
> > > +++ b/drivers/gpu/drm/i915/intel_bios.h
> > > @@ -730,6 +730,7 @@ struct bdb_psr {
> > >  #define   DEVICE_TYPE_INT_TV 0x1009
> > >  #define   DEVICE_TYPE_HDMI   0x60D2
> > >  #define   DEVICE_TYPE_DP 0x68C6
> > > +#define   DEVICE_TYPE_DP_DUAL_MODE   0x60D6
> > >  #define   DEVICE_TYPE_eDP0x78C6
> > >  
> > >  #define  DEVICE_TYPE_CLASS_EXTENSION (1 << 15)
> > > @@ -764,6 +765,8 @@ struct bdb_psr {
> > >    DEVICE_TYPE_DISPLAYPORT_OUTPUT | \
> > >    DEVICE_TYPE_ANALOG_OUTPUT)
> > >  
> > > +#define DEVICE_TYPE_DP_DUAL_MODE_BITS
> > > ~DEVICE_TYPE_NOT_HDMI_OUTPUT
> > > +
> > >  /* define the DVO port for HDMI output type */
> > >  #define  DVO_B   1
> > >  #define  DVO_C   2
> > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > > b/drivers/gpu/drm/i915/intel_dp.c
> > > index cbc06596659a..f3edacf517ac 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > @@ -5104,6 +5104,34 @@ bool intel_dp_is_edp(struct drm_device
> > > *dev,
> > > enum port port)
> > >   return false;
> > >  }
> > >  
> > > +bool intel_dp_is_dual_mode(struct drm_i915_private *dev_priv,
> > > enum
> > > port port)
> > > +{
> > > + const union child_device_config *p_child;
> > > + int i;
> > > + static const short port_mapping[] = {
> > > + [PORT_B] = DVO_PORT_DPB,
> > > + [PORT_C] = DVO_PORT_DPC,
> > > + [PORT_D] = DVO_PORT_DPD,
> > > + [PORT_E] = DVO_PORT_DPE,
> > > + };
> > > +
> > > + if (port == PORT_A || port >= ARRAY_SIZE(port_mapping))
> > > + return false;
> > > +
> > > + if (!dev_priv->vbt.child_dev_num)
> > > + return false;
> > > +
> > > + for (i = 0; i < dev_priv->vbt.child_dev_num; i++) {
> > > + p_child = &dev_priv->vbt.child_dev[i];
> > > +
> > > + if (p_child->common.dvo_port ==
> > > port_mapping[port]
> > > &&
> > > + (p_child->common.device_type &
> > > DEVICE_TYPE_DP_DUAL_MODE_BITS) ==
> > > + (DEVICE_TYPE_DP_DUAL_MODE &
> > > DEVICE_TYPE_DP_DUAL_MODE_BITS))
> > > + return true;
> > > + }
> > Some thoughts:
> > 
> > This is going to be implemented for all VBT versions. Since there's
> > no
> > real history about anything before version 155, is this really what
> > we
> > want? A huge part of the "we don't trust the VBT" culture we have
> > on
> > our team is because of those old versions being completely
> > unreliable.
> > If this is the case, we could make this implementation just be a
> > small
> > patch in parse_ddi_port(). I'm kinda afraid we may somehow break
> > old
> > machines yet again.
> I don't think it matters much. ILK being the oldest platform with
> DP++
> capable of >165MHz, and at least my ILK here already has VBT version
> 163. Also this device type stuff was there before 155 already. And
> the is_edp() thing ha

Re: [Intel-gfx] [PATCH 0/4] Enable FBC on SKL, v3

[Zanoni, Paulo R]

Em Qua, 2016-04-06 às 10:36 +0530, Thulasimani, Sivakumar escreveu:
> dont want to hijack thread but wanted to point out a possible
> regression 
> in the
> previous patches of this series.
> 
> intel_fbc_can_choose: returns true for gen 4/5/6/7. (possible bug)

How? It will check for i915.enable_fbc, which will have been sanitized
to zero on these platforms. Aren't you explicitly enabling FBC on these
platforms by using i915.enable_fbc=1?

> 
> so intel_crtc_state->enable_fbc = true; will be executed for first
> crtc
> everytime intel_fbc_choose_crtc is called. Although there is check to
> handle fbc already enabled, it may fail when we fbc is disabled and
> we are working on non supported panel.
> 
> regards,
> Sivakumar
> 
> On 4/5/2016 2:47 AM, Paulo Zanoni wrote:
> > 
> > Now with the suggestion from Chris instead of the old workaround.
> > We don't need
> > new DDX patches anymore, but now we need new IGT patches.
> > 
> > Chris Wilson (1):
> >    drm/i915: use ORIGIN_CPU for frontbuffer invalidation on WC
> > mmaps
> > 
> > Paulo Zanoni (3):
> >    drm/i915/fbc: update busy_bits even for GTT and flip flushes
> >    drm/i915/fbc: sanitize i915.enable_fbc during FBC init
> >    drm/i915/fbc: enable FBC on gen 9+ too
> > 
> >   drivers/gpu/drm/i915/i915_drv.h  |  1 +
> >   drivers/gpu/drm/i915/i915_gem.c  | 14 +++---
> >   drivers/gpu/drm/i915/intel_fbc.c | 27 ---
> >   3 files changed, 28 insertions(+), 14 deletions(-)
> > 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/5] drm/i915: Add sys FBC toggle interface

[Zanoni, Paulo R]

Em Ter, 2016-04-12 às 12:18 -0700, Alexandra Yates escreveu:
> This interface allows an immediate enabling of FBC feature. What
> allow us
> to see immediately the FBC

There's no way to guarantee the user will immediately see any FBC
savings. FBC depends on a lot of conditions (e.g., X tiling, correct
pipe, correct buffer size and placement, correct pixel format, correct
mode, gpu idleness, etc), so users may see no power saving changes by
toggling the powertop buttons for FBC and incorrectly assume that FBC
saves no power, while they are just in a state that doesn't immediately
allow FBC to be activated. Do we plan to provide easily-accessible
documentation explaining such things?

>  power management savings and will allow us to
> expose this through sysfs interface for powertop to leverage its
> functionality.
> 
> Signed-off-by: Alexandra Yates 
> ---
>  drivers/gpu/drm/i915/i915_drv.h  |  1 +
>  drivers/gpu/drm/i915/i915_sysfs.c| 77
> 
>  drivers/gpu/drm/i915/intel_display.c | 15 +--
>  drivers/gpu/drm/i915/intel_drv.h |  4 +-
>  drivers/gpu/drm/i915/intel_fbc.c | 29 +++---
>  5 files changed, 115 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> b/drivers/gpu/drm/i915/i915_drv.h
> index c96da4d..0f3a37f 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -936,6 +936,7 @@ struct intel_fbc {
>   } work;
>  
>   const char *no_fbc_reason;
> + bool sysfs_set;
>  };
>  
>  /**
> diff --git a/drivers/gpu/drm/i915/i915_sysfs.c
> b/drivers/gpu/drm/i915/i915_sysfs.c
> index 208c6ec..50d45ef 100644
> --- a/drivers/gpu/drm/i915/i915_sysfs.c
> +++ b/drivers/gpu/drm/i915/i915_sysfs.c
> @@ -107,6 +107,65 @@ show_media_rc6_ms(struct device *kdev, struct
> device_attribute *attr, char *buf)
>  }
>  
>  static ssize_t
> +show_fbc(struct device *kdev, struct device_attribute *attr, char
> *buf)
> +{
> + struct drm_minor *dminor = dev_to_drm_minor(kdev);
> + struct drm_device *dev = dminor->dev;
> + struct drm_i915_private *dev_priv = dev->dev_private;
> + ssize_t ret;
> +
> + mutex_lock(&dev_priv->fbc.lock);
> + ret = snprintf(buf, PAGE_SIZE, "%s\n", dev_priv->fbc.enabled 
> ?
> + "enabled":"disabled");

Whenever this was discussed, I actually thought this interface would
expose "is support for the FBC feature enabled in the Kernel?" instead
of "is FBC currently software-enabled on a CRTC?". For completeness,
notice that a third option would be "is FBC currently enabled in
hardware?". Why did you pick the current approach instead of the
others?

> + mutex_unlock(&dev_priv->fbc.lock);

Locking/unlocking doesn't help much here.

> + return ret;
> +}
> +
> +static ssize_t
> +toggle_fbc(struct device *kdev, struct device_attribute *attr,
> + const char *buf, size_t count)
> +{
> + struct drm_minor *dminor = dev_to_drm_minor(kdev);
> + struct drm_device *dev = dminor->dev;
> + struct intel_connector *connector;
> + struct intel_encoder *encoder;
> + struct intel_crtc *crtc = NULL;
> + u32 val;
> + ssize_t ret;
> + bool sysfs_set = true;
> +
> + ret = kstrtou32(buf, 0, &val);
> + if (ret)
> + return ret;
> +
> + for_each_intel_connector(dev, connector) {
> + if (!connector->base.encoder)
> + continue;
> + encoder = to_intel_encoder(connector->base.encoder);
> + crtc = to_intel_crtc(encoder->base.crtc);
> + }

Why are we picking a random connected CRTC? There's no guarantee it
supports FBC, nor that it even has a mode.

> +
> + if (!crtc)
> + return -ENODEV;
> + switch (val) {
> + case 0:
> + ret = intel_fbc_disable(crtc, sysfs_set);
> + if (ret)
> + return ret;
> + break;
> + case 1:
> + ret = intel_fbc_enable(crtc, sysfs_set);

The current FBC code was designed in a way where the appropriate CRTC
is chosen during the atomic commits, and then later
intel_fbc_{en,dis}able is called. This change is bypassing
intel_fbc_can_choose(), and creating a new - and unplanned for - use
case where FBC can be toggled without a modeset. While we could make
this work somehow, we'd be adding additional complexity (aka possible
bugs) just to enable users to switch their machines to unsafe defaults
using powertop (and maybe reaching wrong conclusions due to the lack of
guarantee that FBC will be enabled in hardware), so I'm not sure the
benefits outweigh the maintenance costs.

So my suggestion would be to make the sysfs interface just toggle
i915.enable_fbc, which would require a modeset for things to actually
take place. I thought this was the original plan.

By the way, aren't you hitting the WARNs from
intel_fbc_update_state_cache() with the current code?


> + if (ret)
> + return ret;
> +

Re: [Intel-gfx] [PATCH 0/5] PowerManagement Toggle for PowerTOP

[Zanoni, Paulo R]

Em Ter, 2016-04-12 às 12:18 -0700, Alexandra Yates escreveu:
> This project is explained in detail on the HAS
> https://docs.google.com/a/intel.com/document/d/1E-en_xqfHgCnhD1Tes3f0
> 8UYrOc-etv2W-pU0ZErKdE/edit?usp=sharing  
> 
> Summary: 
> Permits the user to identify and toggle values for PSR, FBC, RC6,
> DRRS, and IPS
> under /sys/class/drm/card0/power/.  By enabling these features I'm
> looking to
> empower our customers, such as, power team, chrome OS, and platform
> integration teams
> to debug graphics power management features. 
> 
> From the current patchset PSR, FBC, RC6, and, DRRS are complete and
> past BAT, modset,
> and suspend/resume tests.  For IPS I'm looking for feedback since IPS
> seems to change
> during runtime dynamically.  Additionally, as a future project IPS
> would be better 
> served if it is implemented by using the atomic check, pre-commit,
> commit, post-commit,
> a good example of this is the PSR enable/disable implementation.
> 
> For this project to be completed needs to have in place the following
> components:
> (Need to be developed)
> * IPS toggle interface flesh-out
> * Tests added to intel-gpu-tools repo
> * Documentation for all sysfs added interfaces
> * PowerTOP component named: GFX-TOP. With the following requirements:
>   * It would be available only to developers
>   * It would allow the developers to toggle the interfaces from
>     the PowerTOP user interface.  
>   * It would show the Power Consumption impact of toggling on and
> off
>     these settings.  
>  

A small suggestion:

In the past, I've seen people testing i915.ko power saving features
just by "toggling" the features through the i915 module parameters
without doing anything else. In most of these cases, the machine was
not properly configured for power savings, so the conclusion was often
that the feature didn't save any power. While this was true (toggling
the feature didn't save any power), these people would have reached
different conclusions if they had, for example, changed their disk
power management policies. Do we have any sort of plan to try to
educate the powertop/gfxtop users regarding these things?

Maybe the powertop/gfxtop interface could expose some very-easy-to-
reach text explaining these things.


> Your review of this patchset is intended to contribute to its full
> maturity so that when we reach the PowerTOP development all pieces
> would
> be ready for commit.  
> 
> Thank you in advance,
> 
> Alexandra Yates (5):
>   drm/i915: Add sys PSR toggle interface
>   drm/i915: Add sys FBC toggle interface
>   drm/i915: Add sys RC6 toggle interface
>   drm/i915: Add sys drrs toggle interface
>   drm-i915: Add sys IPS toggle interface
> 
>  drivers/gpu/drm/i915/i915_debugfs.c  |   5 +-
>  drivers/gpu/drm/i915/i915_drv.c  |   5 +-
>  drivers/gpu/drm/i915/i915_drv.h  |  12 ++
>  drivers/gpu/drm/i915/i915_sysfs.c| 362
> ++-
>  drivers/gpu/drm/i915/intel_color.c   |  12 +-
>  drivers/gpu/drm/i915/intel_ddi.c |  15 +-
>  drivers/gpu/drm/i915/intel_display.c |  55 --
>  drivers/gpu/drm/i915/intel_dp.c  |  48 +++--
>  drivers/gpu/drm/i915/intel_drv.h |  21 +-
>  drivers/gpu/drm/i915/intel_fbc.c |  29 ++-
>  drivers/gpu/drm/i915/intel_pm.c  |  53 -
>  drivers/gpu/drm/i915/intel_psr.c |  36 +++-
>  12 files changed, 588 insertions(+), 65 deletions(-)
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/5] drm/i915: Add sys PSR toggle interface

[Zanoni, Paulo R]

Em Ter, 2016-04-12 às 12:18 -0700, Alexandra Yates escreveu:
> This interface allows an immediate enabling of PSR feature. What
> allow us
> to see immediately the PSR savings and will allow us to expose this
> through sysfs interface for powertop to leverage its functionality.
> 
> Signed-off-by: Alexandra Yates 
> ---
>  drivers/gpu/drm/i915/i915_drv.h   |  1 +
>  drivers/gpu/drm/i915/i915_sysfs.c | 79
> +++
>  drivers/gpu/drm/i915/intel_ddi.c  |  6 ++-
>  drivers/gpu/drm/i915/intel_dp.c   | 11 --
>  drivers/gpu/drm/i915/intel_drv.h  |  4 +-
>  drivers/gpu/drm/i915/intel_psr.c  | 36 ++
>  6 files changed, 122 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> b/drivers/gpu/drm/i915/i915_drv.h
> index f5c91b0..c96da4d 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -976,6 +976,7 @@ struct i915_psr {
>   bool psr2_support;
>   bool aux_frame_sync;
>   bool link_standby;
> + bool sysfs_set;
>  };
>  
>  enum intel_pch {
> diff --git a/drivers/gpu/drm/i915/i915_sysfs.c
> b/drivers/gpu/drm/i915/i915_sysfs.c
> index 2d576b7..208c6ec 100644
> --- a/drivers/gpu/drm/i915/i915_sysfs.c
> +++ b/drivers/gpu/drm/i915/i915_sysfs.c
> @@ -106,12 +106,84 @@ show_media_rc6_ms(struct device *kdev, struct
> device_attribute *attr, char *buf)
>   return snprintf(buf, PAGE_SIZE, "%u\n", rc6_residency);
>  }
>  
> +static ssize_t
> +show_psr(struct device *kdev, struct device_attribute *attr, char
> *buf)
> +{
> + struct drm_minor *dminor = dev_to_drm_minor(kdev);
> + struct drm_device *dev = dminor->dev;
> + struct drm_i915_private *dev_priv = dev->dev_private;
> + ssize_t ret;
> +
> + mutex_lock(&dev_priv->psr.lock);
> + ret = snprintf(buf, PAGE_SIZE, "%s\n", dev_priv->psr.enabled 
> ?
> + "enabled":"disabled");
> + mutex_unlock(&dev_priv->psr.lock);
> + return ret;
> +}
> +
> +static ssize_t
> +toggle_psr(struct device *kdev, struct device_attribute *attr,
> + const char *buf, size_t count)
> +{
> + struct drm_minor *dminor = dev_to_drm_minor(kdev);
> + struct drm_device *dev = dminor->dev;
> + struct intel_connector *connector;
> + struct intel_encoder *encoder;
> + struct intel_crtc *crtc = NULL;
> + u32 val;
> + ssize_t ret;
> + struct intel_dp *intel_dp = NULL;
> + bool sysfs_set = true;
> +
> + ret = kstrtou32(buf, 0, &val);
> + if (ret)
> + return ret;
> +
> + for_each_intel_connector(dev, connector) {
> + if (!connector->base.encoder)
> + continue;
> + encoder = to_intel_encoder(connector->base.encoder);
> + crtc = to_intel_crtc(encoder->base.crtc);
> + intel_dp = enc_to_intel_dp(&encoder->base);
> + }

Same problem here: no guarantee that the encoder is DP, nor that it
supports PSR, nor that it is enabled and has a mode set.

> +
> + if (!crtc)
> + return -ENODEV;
> + switch (val) {
> + case 0:
> + ret = intel_psr_disable(intel_dp, sysfs_set);
> + if (ret)
> + return ret;
> + break;
> + case 1:
> + ret = intel_psr_enable(intel_dp, sysfs_set);
> + if (ret)
> + return ret;
> + break;
> + default:
> + return -EINVAL;
> +
> + }
> + return count;
> +}
> +
> +static DEVICE_ATTR(psr_enable, S_IRUGO | S_IWUSR, show_psr,
> toggle_psr);
>  static DEVICE_ATTR(rc6_enable, S_IRUGO, show_rc6_mask, NULL);
>  static DEVICE_ATTR(rc6_residency_ms, S_IRUGO, show_rc6_ms, NULL);
>  static DEVICE_ATTR(rc6p_residency_ms, S_IRUGO, show_rc6p_ms, NULL);
>  static DEVICE_ATTR(rc6pp_residency_ms, S_IRUGO, show_rc6pp_ms,
> NULL);
>  static DEVICE_ATTR(media_rc6_residency_ms, S_IRUGO,
> show_media_rc6_ms, NULL);
>  
> +static struct attribute *psr_attrs[] = {
> + &dev_attr_psr_enable.attr,
> + NULL
> +};
> +
> +static struct attribute_group psr_attr_group = {
> + .name = power_group_name,
> + .attrs = psr_attrs
> +};
> +
>  static struct attribute *rc6_attrs[] = {
>   &dev_attr_rc6_enable.attr,
>   &dev_attr_rc6_residency_ms.attr,
> @@ -596,6 +668,12 @@ void i915_setup_sysfs(struct drm_device *dev)
>   int ret;
>  
>  #ifdef CONFIG_PM
> + if (HAS_PSR(dev)) {
> + ret = sysfs_merge_group(&dev->primary->kdev->kobj,
> + &psr_attr_group);
> + if (ret)
> + DRM_ERROR("PSR sysfs setup failed\n");
> + }
>   if (HAS_RC6(dev)) {
>   ret = sysfs_merge_group(&dev->primary->kdev->kobj,
>   &rc6_attr_group);
> @@ -652,6 +730,7 @@ void i915_teardown_sysfs(struct drm_device *dev)
>   device_remove_bin_file(dev->primary->kdev,  &dpf_attrs_1);
>   device_remove_bin_file(dev->primary->kdev,  &dpf_at