Re: [PATCH v6 12/12] drm/xe: Increase the XE_PL_TT watermark
On Wed, 2024-07-03 at 17:38 +0200, Thomas Hellström wrote: > The XE_PL_TT watermark was set to 50% of system memory. > The idea behind that was unclear since the net effect is that > TT memory will be evicted to TTM_PL_SYSTEM memory if that > watermark is exceeded, requiring PPGTT rebinds and dma > remapping. But there is no similar watermark for TTM_PL_SYSTEM > memory. > > The TTM functionality that tries to swap out system memory to > shmem objects if a 50% limit of total system memory is reached > is orthogonal to this, and with the shrinker added, it's no > longer in effect. > > Replace the 50% TTM_PL_TT limit with a 100% limit, in effect > allowing all graphics memory to be bound to the device unless it > has been swapped out by the shrinker. Sorry if I missed some patch changing it but I did not found in this series anything changing the 50% limit in ttm_global_init(). When I debugged some Vulkan tests allocate a lot of memory, the reason that KMD was not allocating memory wash this ttm_global limit that is shared with all devices using TTM. > > Signed-off-by: Thomas Hellström > --- > drivers/gpu/drm/xe/xe_ttm_sys_mgr.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/xe/xe_ttm_sys_mgr.c > b/drivers/gpu/drm/xe/xe_ttm_sys_mgr.c > index 9844a8edbfe1..d38b91872da3 100644 > --- a/drivers/gpu/drm/xe/xe_ttm_sys_mgr.c > +++ b/drivers/gpu/drm/xe/xe_ttm_sys_mgr.c > @@ -108,9 +108,8 @@ int xe_ttm_sys_mgr_init(struct xe_device *xe) > u64 gtt_size; > > si_meminfo(&si); > + /* Potentially restrict amount of TT memory here. */ > gtt_size = (u64)si.totalram * si.mem_unit; > - /* TTM limits allocation of all TTM devices by 50% of system memory */ > - gtt_size /= 2; > > man->use_tt = true; > man->func = &xe_ttm_sys_mgr_func;
Re: [PATCH] drm/xe: Use write-back caching mode for system memory on DGFX
On Wed, 2024-06-19 at 18:39 +0200, Thomas Hellström wrote:
> The caching mode for buffer objects with VRAM as a possible
> placement was forced to write-combined, regardless of placement.
>
> However, write-combined system memory is expensive to allocate and
> even though it is pooled, the pool is expensive to shrink, since
> it involves global CPU TLB flushes.
>
> Moreover write-combined system memory from TTM is only reliably
> available on x86 and DGFX doesn't have an x86 restriction.
>
> So regardless of the cpu caching mode selected for a bo,
> internally use write-back caching mode for system memory on DGFX.
>
> Coherency is maintained, but user-space clients may perceive a
> difference in cpu access speeds.
No regression on Mesa with this, so:
Acked-by: José Roberto de Souza
>
> Signed-off-by: Thomas Hellström
> Fixes: 622f709ca629 ("drm/xe/uapi: Add support for CPU caching mode")
> Cc: Pallavi Mishra
> Cc: Matthew Auld
> Cc: dri-devel@lists.freedesktop.org
> Cc: Joonas Lahtinen
> Cc: Effie Yu
> Cc: Matthew Brost
> Cc: Maarten Lankhorst
> Cc: Jose Souza
> Cc: Michal Mrozek
> Cc: # v6.8+
> ---
> drivers/gpu/drm/xe/xe_bo.c | 47 +++-
> drivers/gpu/drm/xe/xe_bo_types.h | 3 +-
> include/uapi/drm/xe_drm.h| 8 +-
> 3 files changed, 37 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/xe/xe_bo.c b/drivers/gpu/drm/xe/xe_bo.c
> index 65c696966e96..31192d983d9e 100644
> --- a/drivers/gpu/drm/xe/xe_bo.c
> +++ b/drivers/gpu/drm/xe/xe_bo.c
> @@ -343,7 +343,7 @@ static struct ttm_tt *xe_ttm_tt_create(struct
> ttm_buffer_object *ttm_bo,
> struct xe_device *xe = xe_bo_device(bo);
> struct xe_ttm_tt *tt;
> unsigned long extra_pages;
> - enum ttm_caching caching;
> + enum ttm_caching caching = ttm_cached;
> int err;
>
> tt = kzalloc(sizeof(*tt), GFP_KERNEL);
> @@ -357,26 +357,35 @@ static struct ttm_tt *xe_ttm_tt_create(struct
> ttm_buffer_object *ttm_bo,
> extra_pages = DIV_ROUND_UP(xe_device_ccs_bytes(xe, bo->size),
> PAGE_SIZE);
>
> - switch (bo->cpu_caching) {
> - case DRM_XE_GEM_CPU_CACHING_WC:
> - caching = ttm_write_combined;
> - break;
> - default:
> - caching = ttm_cached;
> - break;
> - }
> -
> - WARN_ON((bo->flags & XE_BO_FLAG_USER) && !bo->cpu_caching);
> -
> /*
> - * Display scanout is always non-coherent with the CPU cache.
> - *
> - * For Xe_LPG and beyond, PPGTT PTE lookups are also non-coherent and
> - * require a CPU:WC mapping.
> + * DGFX system memory is always WB / ttm_cached, since
> + * other caching modes are only supported on x86. DGFX
> + * GPU system memory accesses are always coherent with the
> + * CPU.
>*/
> - if ((!bo->cpu_caching && bo->flags & XE_BO_FLAG_SCANOUT) ||
> - (xe->info.graphics_verx100 >= 1270 && bo->flags &
> XE_BO_FLAG_PAGETABLE))
> - caching = ttm_write_combined;
> + if (!IS_DGFX(xe)) {
> + switch (bo->cpu_caching) {
> + case DRM_XE_GEM_CPU_CACHING_WC:
> + caching = ttm_write_combined;
> + break;
> + default:
> + caching = ttm_cached;
> + break;
> + }
> +
> + WARN_ON((bo->flags & XE_BO_FLAG_USER) && !bo->cpu_caching);
> +
> + /*
> + * Display scanout is always non-coherent with the CPU cache.
> + *
> + * For Xe_LPG and beyond, PPGTT PTE lookups are also
> + * non-coherent and require a CPU:WC mapping.
> + */
> + if ((!bo->cpu_caching && bo->flags & XE_BO_FLAG_SCANOUT) ||
> + (xe->info.graphics_verx100 >= 1270 &&
> + bo->flags & XE_BO_FLAG_PAGETABLE))
> + caching = ttm_write_combined;
> + }
>
> if (bo->flags & XE_BO_FLAG_NEEDS_UC) {
> /*
> diff --git a/drivers/gpu/drm/xe/xe_bo_types.h
> b/drivers/gpu/drm/xe/xe_bo_types.h
> index 86422e113d39..10450f1fbbde 100644
> --- a/drivers/gpu/drm/xe/xe_bo_types.h
> +++ b/drivers/gpu/drm/xe/xe_bo_types.h
> @@ -66,7 +66,8 @@ struct xe_bo {
>
> /**
>* @cpu_caching: CPU caching mode. Currently only used for userspace
> - * objects.
> + * objects. Exceptions are system memory on DGFX, which is always
> + * WB.
>*/
> u16 cpu_caching;
>
> diff --git a/include/uapi/drm/xe_drm.h b/include/uapi/drm/xe_drm.h
> index 93e00be44b2d..1189b3044723 100644
> --- a/include/uapi/drm/xe_drm.h
> +++ b/include/uapi/drm/xe_drm.h
> @@ -783,7 +783,13 @@ struct drm_xe_gem_create {
> #define DRM_XE_GEM_CPU_CACHING_WC 2
> /**
>* @cpu_caching: The CPU caching mode to select for this object. If
> - * mmaping the object the mode selected here will
Re: [PATCH] drm/i915: Add some boring kerneldoc
On Mon, 2024-02-19 at 13:25 +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Tooling appears very strict so lets pacify it by adding some comments,
> even if fields are completely self-explanatory.
>
Reviewed-by: José Roberto de Souza
> Signed-off-by: Tvrtko Ursulin
> Fixes: b11236486749 ("drm/i915: Add GuC submission interface version query")
> Reported-by: Stephen Rothwell
> Cc: Jose Souza
> ---
> include/uapi/drm/i915_drm.h | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> index bd87386a8243..2ee338860b7e 100644
> --- a/include/uapi/drm/i915_drm.h
> +++ b/include/uapi/drm/i915_drm.h
> @@ -3572,9 +3572,13 @@ struct drm_i915_query_memory_regions {
> * struct drm_i915_query_guc_submission_version - query GuC submission
> interface version
> */
> struct drm_i915_query_guc_submission_version {
> + /** @branch: Firmware branch version. */
> __u32 branch;
> + /** @major: Firmware major version. */
> __u32 major;
> + /** @minor: Firmware minor version. */
> __u32 minor;
> + /** @patch: Firmware patch version. */
> __u32 patch;
> };
>
Re: [PATCH v2] drm/i915: Add GuC submission interface version query
On Fri, 2024-02-09 at 09:06 +, Tvrtko Ursulin wrote:
> On 08/02/2024 17:55, Souza, Jose wrote:
> > On Thu, 2024-02-08 at 07:19 -0800, José Roberto de Souza wrote:
> > > On Thu, 2024-02-08 at 14:59 +, Tvrtko Ursulin wrote:
> > > > On 08/02/2024 14:30, Souza, Jose wrote:
> > > > > On Thu, 2024-02-08 at 08:25 +, Tvrtko Ursulin wrote:
> > > > > > From: Tvrtko Ursulin
> > > > > >
> > > > > > Add a new query to the GuC submission interface version.
> > > > > >
> > > > > > Mesa intends to use this information to check for old firmware
> > > > > > versions
> > > > > > with a known bug where using the render and compute command
> > > > > > streamers
> > > > > > simultaneously can cause GPU hangs due issues in firmware
> > > > > > scheduling.
> > > > > >
> > > > > > Based on patches from Vivaik and Joonas.
> > > > > >
> > > > > > Compile tested only.
> > > > > >
> > > > > > v2:
> > > > > >* Added branch version.
> > > > >
> > > > > Reviewed-by: José Roberto de Souza
> > > > > Tested-by: José Roberto de Souza
> > > > > UMD: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25233
> > > >
> > > > Thanks, but please we also need to close down on the branch number
> > > > situation. I.e. be sure what is the failure mode in shipping Mesa with
> > > > the change as it stands in the MR linked. What platforms could start
> > > > failing and when, depending on GuC FW release eventualities.
> > >
> > > yes, I have asked John Harrison for a documentation link about the
> > > firmware versioning.
> >
> > Got the documentation link, MR updated.
> > Will ask for reviews in Mesa side.
>
> Is it then understood and accepted that should GuC ever update the
> branch number on any given platform, that platform, for all deployed
> Mesa's in the field, will automatically revert to no async queues and so
> cause a silent performance regression?
yes, understood and accepted.
The Mesa MR is now reviewed, thank you Sagar.
>
> Regards,
>
> Tvrtko
>
> >
> > >
> > > >
> > > > Regards,
> > > >
> > > > Tvrtko
> > > >
> > > > > > Signed-off-by: Tvrtko Ursulin
> > > > > > Cc: Kenneth Graunke
> > > > > > Cc: Jose Souza
> > > > > > Cc: Sagar Ghuge
> > > > > > Cc: Paulo Zanoni
> > > > > > Cc: John Harrison
> > > > > > Cc: Rodrigo Vivi
> > > > > > Cc: Jani Nikula
> > > > > > Cc: Tvrtko Ursulin
> > > > > > Cc: Vivaik Balasubrawmanian
> > > > > > Cc: Joonas Lahtinen
> > > > > > ---
> > > > > >drivers/gpu/drm/i915/i915_query.c | 33
> > > > > > +++
> > > > > >include/uapi/drm/i915_drm.h | 12 +++
> > > > > >2 files changed, 45 insertions(+)
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/i915/i915_query.c
> > > > > > b/drivers/gpu/drm/i915/i915_query.c
> > > > > > index 00871ef99792..d4dba1240b40 100644
> > > > > > --- a/drivers/gpu/drm/i915/i915_query.c
> > > > > > +++ b/drivers/gpu/drm/i915/i915_query.c
> > > > > > @@ -551,6 +551,38 @@ static int query_hwconfig_blob(struct
> > > > > > drm_i915_private *i915,
> > > > > > return hwconfig->size;
> > > > > >}
> > > > > >
> > > > > > +static int
> > > > > > +query_guc_submission_version(struct drm_i915_private *i915,
> > > > > > +struct drm_i915_query_item *query)
> > > > > > +{
> > > > > > + struct drm_i915_query_guc_submission_version __user *query_ptr =
> > > > > > +
> > > > > > u64_to_user_ptr(query->data_ptr);
> > > > > > + struct drm_i915_query_guc_submission_version ver;
> > > > > > + struct intel_guc *guc = &to_gt(i915)->uc.guc;
> > > > > > + const size_t size = sizeof(v
Re: [PATCH v2] drm/i915: Add GuC submission interface version query
On Thu, 2024-02-08 at 07:19 -0800, José Roberto de Souza wrote:
> On Thu, 2024-02-08 at 14:59 +, Tvrtko Ursulin wrote:
> > On 08/02/2024 14:30, Souza, Jose wrote:
> > > On Thu, 2024-02-08 at 08:25 +, Tvrtko Ursulin wrote:
> > > > From: Tvrtko Ursulin
> > > >
> > > > Add a new query to the GuC submission interface version.
> > > >
> > > > Mesa intends to use this information to check for old firmware versions
> > > > with a known bug where using the render and compute command streamers
> > > > simultaneously can cause GPU hangs due issues in firmware scheduling.
> > > >
> > > > Based on patches from Vivaik and Joonas.
> > > >
> > > > Compile tested only.
> > > >
> > > > v2:
> > > > * Added branch version.
> > >
> > > Reviewed-by: José Roberto de Souza
> > > Tested-by: José Roberto de Souza
> > > UMD: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25233
> >
> > Thanks, but please we also need to close down on the branch number
> > situation. I.e. be sure what is the failure mode in shipping Mesa with
> > the change as it stands in the MR linked. What platforms could start
> > failing and when, depending on GuC FW release eventualities.
>
> yes, I have asked John Harrison for a documentation link about the firmware
> versioning.
Got the documentation link, MR updated.
Will ask for reviews in Mesa side.
>
> >
> > Regards,
> >
> > Tvrtko
> >
> > > > Signed-off-by: Tvrtko Ursulin
> > > > Cc: Kenneth Graunke
> > > > Cc: Jose Souza
> > > > Cc: Sagar Ghuge
> > > > Cc: Paulo Zanoni
> > > > Cc: John Harrison
> > > > Cc: Rodrigo Vivi
> > > > Cc: Jani Nikula
> > > > Cc: Tvrtko Ursulin
> > > > Cc: Vivaik Balasubrawmanian
> > > > Cc: Joonas Lahtinen
> > > > ---
> > > > drivers/gpu/drm/i915/i915_query.c | 33 +++
> > > > include/uapi/drm/i915_drm.h | 12 +++
> > > > 2 files changed, 45 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/i915_query.c
> > > > b/drivers/gpu/drm/i915/i915_query.c
> > > > index 00871ef99792..d4dba1240b40 100644
> > > > --- a/drivers/gpu/drm/i915/i915_query.c
> > > > +++ b/drivers/gpu/drm/i915/i915_query.c
> > > > @@ -551,6 +551,38 @@ static int query_hwconfig_blob(struct
> > > > drm_i915_private *i915,
> > > > return hwconfig->size;
> > > > }
> > > >
> > > > +static int
> > > > +query_guc_submission_version(struct drm_i915_private *i915,
> > > > +struct drm_i915_query_item *query)
> > > > +{
> > > > + struct drm_i915_query_guc_submission_version __user *query_ptr =
> > > > +
> > > > u64_to_user_ptr(query->data_ptr);
> > > > + struct drm_i915_query_guc_submission_version ver;
> > > > + struct intel_guc *guc = &to_gt(i915)->uc.guc;
> > > > + const size_t size = sizeof(ver);
> > > > + int ret;
> > > > +
> > > > + if (!intel_uc_uses_guc_submission(&to_gt(i915)->uc))
> > > > + return -ENODEV;
> > > > +
> > > > + ret = copy_query_item(&ver, size, size, query);
> > > > + if (ret != 0)
> > > > + return ret;
> > > > +
> > > > + if (ver.branch || ver.major || ver.minor || ver.patch)
> > > > + return -EINVAL;
> > > > +
> > > > + ver.branch = 0;
> > > > + ver.major = guc->submission_version.major;
> > > > + ver.minor = guc->submission_version.minor;
> > > > + ver.patch = guc->submission_version.patch;
> > > > +
> > > > + if (copy_to_user(query_ptr, &ver, size))
> > > > + return -EFAULT;
> > > > +
> > > > + return 0;
> > > > +}
> > > > +
> > > > static int (* const i915_query_funcs[])(struct drm_i915_private
> > > > *dev_priv,
> > > > struct drm_i915_query_item
> > > > *query_item) = {
> > > > query_topology
Re: [PATCH v2] drm/i915: Add GuC submission interface version query
On Thu, 2024-02-08 at 14:59 +, Tvrtko Ursulin wrote:
> On 08/02/2024 14:30, Souza, Jose wrote:
> > On Thu, 2024-02-08 at 08:25 +, Tvrtko Ursulin wrote:
> > > From: Tvrtko Ursulin
> > >
> > > Add a new query to the GuC submission interface version.
> > >
> > > Mesa intends to use this information to check for old firmware versions
> > > with a known bug where using the render and compute command streamers
> > > simultaneously can cause GPU hangs due issues in firmware scheduling.
> > >
> > > Based on patches from Vivaik and Joonas.
> > >
> > > Compile tested only.
> > >
> > > v2:
> > > * Added branch version.
> >
> > Reviewed-by: José Roberto de Souza
> > Tested-by: José Roberto de Souza
> > UMD: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25233
>
> Thanks, but please we also need to close down on the branch number
> situation. I.e. be sure what is the failure mode in shipping Mesa with
> the change as it stands in the MR linked. What platforms could start
> failing and when, depending on GuC FW release eventualities.
yes, I have asked John Harrison for a documentation link about the firmware
versioning.
>
> Regards,
>
> Tvrtko
>
> > > Signed-off-by: Tvrtko Ursulin
> > > Cc: Kenneth Graunke
> > > Cc: Jose Souza
> > > Cc: Sagar Ghuge
> > > Cc: Paulo Zanoni
> > > Cc: John Harrison
> > > Cc: Rodrigo Vivi
> > > Cc: Jani Nikula
> > > Cc: Tvrtko Ursulin
> > > Cc: Vivaik Balasubrawmanian
> > > Cc: Joonas Lahtinen
> > > ---
> > > drivers/gpu/drm/i915/i915_query.c | 33 +++
> > > include/uapi/drm/i915_drm.h | 12 +++
> > > 2 files changed, 45 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_query.c
> > > b/drivers/gpu/drm/i915/i915_query.c
> > > index 00871ef99792..d4dba1240b40 100644
> > > --- a/drivers/gpu/drm/i915/i915_query.c
> > > +++ b/drivers/gpu/drm/i915/i915_query.c
> > > @@ -551,6 +551,38 @@ static int query_hwconfig_blob(struct
> > > drm_i915_private *i915,
> > > return hwconfig->size;
> > > }
> > >
> > > +static int
> > > +query_guc_submission_version(struct drm_i915_private *i915,
> > > + struct drm_i915_query_item *query)
> > > +{
> > > + struct drm_i915_query_guc_submission_version __user *query_ptr =
> > > + u64_to_user_ptr(query->data_ptr);
> > > + struct drm_i915_query_guc_submission_version ver;
> > > + struct intel_guc *guc = &to_gt(i915)->uc.guc;
> > > + const size_t size = sizeof(ver);
> > > + int ret;
> > > +
> > > + if (!intel_uc_uses_guc_submission(&to_gt(i915)->uc))
> > > + return -ENODEV;
> > > +
> > > + ret = copy_query_item(&ver, size, size, query);
> > > + if (ret != 0)
> > > + return ret;
> > > +
> > > + if (ver.branch || ver.major || ver.minor || ver.patch)
> > > + return -EINVAL;
> > > +
> > > + ver.branch = 0;
> > > + ver.major = guc->submission_version.major;
> > > + ver.minor = guc->submission_version.minor;
> > > + ver.patch = guc->submission_version.patch;
> > > +
> > > + if (copy_to_user(query_ptr, &ver, size))
> > > + return -EFAULT;
> > > +
> > > + return 0;
> > > +}
> > > +
> > > static int (* const i915_query_funcs[])(struct drm_i915_private
> > > *dev_priv,
> > > struct drm_i915_query_item
> > > *query_item) = {
> > > query_topology_info,
> > > @@ -559,6 +591,7 @@ static int (* const i915_query_funcs[])(struct
> > > drm_i915_private *dev_priv,
> > > query_memregion_info,
> > > query_hwconfig_blob,
> > > query_geometry_subslices,
> > > + query_guc_submission_version,
> > > };
> > >
> > > int i915_query_ioctl(struct drm_device *dev, void *data, struct
> > > drm_file *file)
> > > diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> > > index 550c496ce76d..84fb7f7ea834 100644
> > > --- a/include/uapi/drm/i915_drm.h
> > > +++ b/include/uapi/drm/i915_drm.h
> > > @@ -3038,6 +3038,7 @@ struct drm_i915_query_item {
> > &g
Re: [PATCH v2] drm/i915: Add GuC submission interface version query
On Thu, 2024-02-08 at 08:25 +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Add a new query to the GuC submission interface version.
>
> Mesa intends to use this information to check for old firmware versions
> with a known bug where using the render and compute command streamers
> simultaneously can cause GPU hangs due issues in firmware scheduling.
>
> Based on patches from Vivaik and Joonas.
>
> Compile tested only.
>
> v2:
> * Added branch version.
Reviewed-by: José Roberto de Souza
Tested-by: José Roberto de Souza
UMD: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25233
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Kenneth Graunke
> Cc: Jose Souza
> Cc: Sagar Ghuge
> Cc: Paulo Zanoni
> Cc: John Harrison
> Cc: Rodrigo Vivi
> Cc: Jani Nikula
> Cc: Tvrtko Ursulin
> Cc: Vivaik Balasubrawmanian
> Cc: Joonas Lahtinen
> ---
> drivers/gpu/drm/i915/i915_query.c | 33 +++
> include/uapi/drm/i915_drm.h | 12 +++
> 2 files changed, 45 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_query.c
> b/drivers/gpu/drm/i915/i915_query.c
> index 00871ef99792..d4dba1240b40 100644
> --- a/drivers/gpu/drm/i915/i915_query.c
> +++ b/drivers/gpu/drm/i915/i915_query.c
> @@ -551,6 +551,38 @@ static int query_hwconfig_blob(struct drm_i915_private
> *i915,
> return hwconfig->size;
> }
>
> +static int
> +query_guc_submission_version(struct drm_i915_private *i915,
> + struct drm_i915_query_item *query)
> +{
> + struct drm_i915_query_guc_submission_version __user *query_ptr =
> + u64_to_user_ptr(query->data_ptr);
> + struct drm_i915_query_guc_submission_version ver;
> + struct intel_guc *guc = &to_gt(i915)->uc.guc;
> + const size_t size = sizeof(ver);
> + int ret;
> +
> + if (!intel_uc_uses_guc_submission(&to_gt(i915)->uc))
> + return -ENODEV;
> +
> + ret = copy_query_item(&ver, size, size, query);
> + if (ret != 0)
> + return ret;
> +
> + if (ver.branch || ver.major || ver.minor || ver.patch)
> + return -EINVAL;
> +
> + ver.branch = 0;
> + ver.major = guc->submission_version.major;
> + ver.minor = guc->submission_version.minor;
> + ver.patch = guc->submission_version.patch;
> +
> + if (copy_to_user(query_ptr, &ver, size))
> + return -EFAULT;
> +
> + return 0;
> +}
> +
> static int (* const i915_query_funcs[])(struct drm_i915_private *dev_priv,
> struct drm_i915_query_item *query_item)
> = {
> query_topology_info,
> @@ -559,6 +591,7 @@ static int (* const i915_query_funcs[])(struct
> drm_i915_private *dev_priv,
> query_memregion_info,
> query_hwconfig_blob,
> query_geometry_subslices,
> + query_guc_submission_version,
> };
>
> int i915_query_ioctl(struct drm_device *dev, void *data, struct drm_file
> *file)
> diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> index 550c496ce76d..84fb7f7ea834 100644
> --- a/include/uapi/drm/i915_drm.h
> +++ b/include/uapi/drm/i915_drm.h
> @@ -3038,6 +3038,7 @@ struct drm_i915_query_item {
>* - %DRM_I915_QUERY_MEMORY_REGIONS (see struct
> drm_i915_query_memory_regions)
>* - %DRM_I915_QUERY_HWCONFIG_BLOB (see `GuC HWCONFIG blob uAPI`)
>* - %DRM_I915_QUERY_GEOMETRY_SUBSLICES (see struct
> drm_i915_query_topology_info)
> + * - %DRM_I915_QUERY_GUC_SUBMISSION_VERSION (see struct
> drm_i915_query_guc_submission_version)
>*/
> __u64 query_id;
> #define DRM_I915_QUERY_TOPOLOGY_INFO 1
> @@ -3046,6 +3047,7 @@ struct drm_i915_query_item {
> #define DRM_I915_QUERY_MEMORY_REGIONS4
> #define DRM_I915_QUERY_HWCONFIG_BLOB 5
> #define DRM_I915_QUERY_GEOMETRY_SUBSLICES6
> +#define DRM_I915_QUERY_GUC_SUBMISSION_VERSION7
> /* Must be kept compact -- no holes and well documented */
>
> /**
> @@ -3591,6 +3593,16 @@ struct drm_i915_query_memory_regions {
> struct drm_i915_memory_region_info regions[];
> };
>
> +/**
> +* struct drm_i915_query_guc_submission_version - query GuC submission
> interface version
> +*/
> +struct drm_i915_query_guc_submission_version {
> + __u32 branch;
> + __u32 major;
> + __u32 minor;
> + __u32 patch;
> +};
> +
> /**
> * DOC: GuC HWCONFIG blob uAPI
> *
Re: [RFC] drm/i915: Add GuC submission interface version query
On Wed, 2024-02-07 at 11:52 -0800, John Harrison wrote:
> On 2/7/2024 11:43, Souza, Jose wrote:
> > On Wed, 2024-02-07 at 11:34 -0800, John Harrison wrote:
> > > On 2/7/2024 10:49, Tvrtko Ursulin wrote:
> > > > On 07/02/2024 18:12, John Harrison wrote:
> > > > > On 2/7/2024 03:56, Tvrtko Ursulin wrote:
> > > > > > From: Tvrtko Ursulin
> > > > > >
> > > > > > Add a new query to the GuC submission interface version.
> > > > > >
> > > > > > Mesa intends to use this information to check for old firmware
> > > > > > versions
> > > > > > with a known bug where using the render and compute command
> > > > > > streamers
> > > > > > simultaneously can cause GPU hangs due issues in firmware
> > > > > > scheduling.
> > > > > >
> > > > > > Based on patches from Vivaik and Joonas.
> > > > > >
> > > > > > There is a little bit of an open around the width required for
> > > > > > versions.
> > > > > > While the GuC FW iface tells they are u8, i915 GuC code uses u32:
> > > > > >
> > > > > > #define CSS_SW_VERSION_UC_MAJOR (0xFF << 16)
> > > > > > #define CSS_SW_VERSION_UC_MINOR (0xFF << 8)
> > > > > > #define CSS_SW_VERSION_UC_PATCH (0xFF << 0)
> > > > > > ...
> > > > > > struct intel_uc_fw_ver {
> > > > > > u32 major;
> > > > > > u32 minor;
> > > > > > u32 patch;
> > > > > > u32 build;
> > > > > > };
> > > > > This is copied from generic code which supports firmwares other than
> > > > > GuC. Only GuC promises to use 8-bit version components. Other
> > > > > firmwares very definitely do not. There is no open.
> > > > Ack.
> > > >
> > > > > > So we could make the query u8, and refactor the struct
> > > > > > intel_uc_fw_ver
> > > > > > to use u8, or not. To avoid any doubts on why are we assigning u32
> > > > > > to
> > > > > > u8 I simply opted to use u64. Which avoids the need to add any
> > > > > > padding
> > > > > > too.
> > > > > I don't follow how potential 8 vs 32 confusion means jump to 64?!
> > > > Suggestion was to use u8 in the uapi in order to align with GuC FW ABI
> > > > (or however it's called), in which case there would be:
> > > >
> > > > ver.major = guc->submission_version.major;
> > > >
> > > > which would be:
> > > >
> > > > (u8) = (u32)
> > > >
> > > > And I was anticipating someone not liking that either. Using too wide
> > > > u64 simply avoids the need to add a padding element to the uapi struct.
> > > >
> > > > If you are positive we need to include a branch number, even though it
> > > > does not seem to be implemented in the code even(*) then I can make
> > > > uapi 4x u32 and achieve the same.
> > > It's not implemented in the code because we've never had to, and it is
> > > yet another train wreck waiting to happen. There are a bunch of issues
> > > at different levels that need to be resolved. But that is all in the
> > > kernel and/or firmware and so can be added by a later kernel update when
> > > necessary. However, if the UMDs are not already taking it into account
> > > or its not even in the UAPI, then we can't back fill in the kernel
> > > later, we are just broken.
> > This sounds to me like a firmware version for internal testing or for
> > pre-production HW, would any branched firmware be released to customers?
> See comments below. Branching is about back porting critical fixes to
> older releases. I.e. supporting LTS releases. There is absolutely
> nothing internal only or testing related about branching.
>
> Just because we haven't had to do so yet doesn't mean we won't need to
> do so tomorrow.
>
> John.
>
> >
> > > > (*)
> > > > static void uc_unpack_css_version(struct intel_uc_fw_ver *ver, u32
> > > > css_value)
> > > > {
> > > > /* Get version numbers from the CSS header */
> > > > ver-
Re: [RFC] drm/i915: Add GuC submission interface version query
On Wed, 2024-02-07 at 11:34 -0800, John Harrison wrote:
> On 2/7/2024 10:49, Tvrtko Ursulin wrote:
> > On 07/02/2024 18:12, John Harrison wrote:
> > > On 2/7/2024 03:56, Tvrtko Ursulin wrote:
> > > > From: Tvrtko Ursulin
> > > >
> > > > Add a new query to the GuC submission interface version.
> > > >
> > > > Mesa intends to use this information to check for old firmware versions
> > > > with a known bug where using the render and compute command streamers
> > > > simultaneously can cause GPU hangs due issues in firmware scheduling.
> > > >
> > > > Based on patches from Vivaik and Joonas.
> > > >
> > > > There is a little bit of an open around the width required for
> > > > versions.
> > > > While the GuC FW iface tells they are u8, i915 GuC code uses u32:
> > > >
> > > > #define CSS_SW_VERSION_UC_MAJOR (0xFF << 16)
> > > > #define CSS_SW_VERSION_UC_MINOR (0xFF << 8)
> > > > #define CSS_SW_VERSION_UC_PATCH (0xFF << 0)
> > > > ...
> > > > struct intel_uc_fw_ver {
> > > > u32 major;
> > > > u32 minor;
> > > > u32 patch;
> > > > u32 build;
> > > > };
> > > This is copied from generic code which supports firmwares other than
> > > GuC. Only GuC promises to use 8-bit version components. Other
> > > firmwares very definitely do not. There is no open.
> >
> > Ack.
> >
> > > >
> > > > So we could make the query u8, and refactor the struct intel_uc_fw_ver
> > > > to use u8, or not. To avoid any doubts on why are we assigning u32 to
> > > > u8 I simply opted to use u64. Which avoids the need to add any padding
> > > > too.
> > > I don't follow how potential 8 vs 32 confusion means jump to 64?!
> >
> > Suggestion was to use u8 in the uapi in order to align with GuC FW ABI
> > (or however it's called), in which case there would be:
> >
> > ver.major = guc->submission_version.major;
> >
> > which would be:
> >
> > (u8) = (u32)
> >
> > And I was anticipating someone not liking that either. Using too wide
> > u64 simply avoids the need to add a padding element to the uapi struct.
> >
> > If you are positive we need to include a branch number, even though it
> > does not seem to be implemented in the code even(*) then I can make
> > uapi 4x u32 and achieve the same.
> It's not implemented in the code because we've never had to, and it is
> yet another train wreck waiting to happen. There are a bunch of issues
> at different levels that need to be resolved. But that is all in the
> kernel and/or firmware and so can be added by a later kernel update when
> necessary. However, if the UMDs are not already taking it into account
> or its not even in the UAPI, then we can't back fill in the kernel
> later, we are just broken.
This sounds to me like a firmware version for internal testing or for
pre-production HW, would any branched firmware be released to customers?
>
> >
> > (*)
> > static void uc_unpack_css_version(struct intel_uc_fw_ver *ver, u32
> > css_value)
> > {
> > /* Get version numbers from the CSS header */
> > ver->major = FIELD_GET(CSS_SW_VERSION_UC_MAJOR, css_value);
> > ver->minor = FIELD_GET(CSS_SW_VERSION_UC_MINOR, css_value);
> > ver->patch = FIELD_GET(CSS_SW_VERSION_UC_PATCH, css_value);
> > }
> >
> > No branch field in the CSS header?
> I think there is, it's just not officially implemented yet.
>
> >
> > And Why is UMD supposed to reject a non-zero branch? Like how would
> > 1.1.3.0 be fine and 1.1.3.1 be bad? I don't get it. But anyway, I can
> > respin if you definitely confirm.
> Because that is backwards. The branch number goes at the front.
>
> So, for example (using made up numbers, I don't recall offhand what
> versions we have where) say we currently have 0.1.3.0 in tip and 0.1.1.0
> in the last LTS. We then need to ship a critical security fix and back
> port it to the LTS. Tip becomes 0.1.3.1 but the LTS can't become 0.1.1.1
> because that version already exists in the history of tip and does not
> contain the fix. So the LTS gets branched to 1.1.0.0. We then have both
> branches potentially moving forwards with completely independent versioning.
>
> Exactly the same as 5.8.x, 5.9,y, 6.0.z, etc in the Linux kernel
> versioning. You cannot make any assumptions about what might be in
> 1.4.5.6 compared to 0.1.2.3. 1.4.5.6 could actually 0.1.0.3 with a stack
> of security fixes but none of the features, workarounds or bug fixes
> that are in 0.1.2.3.
>
> Hence, if the branch number changes then all bets are off. You have to
> start over and reject anything you do not explicitly know about.
>
> This is why we were saying that exposing version numbers to UMDs breaks
> down horribly as soon as we have to start branching. There is no clean
> or simple way to do this.
>
> John.
>
>
> >
> > Regards,
> >
> > Tvrtko
> >
> > > >
> > > > Compile tested only.
> > > >
> > > > Signed-off-by: Tvrtko Ursulin
> > > > Cc: Kenneth Graunke
>
Re: [Intel-xe] [PATCH 0/2] drm/xe: Fix unprotected rebind_list accesses
On Wed, 2023-05-10 at 16:19 +0200, Thomas Hellström wrote: > Each VM has two rebind lists, one protected by the VM resv, the other > one protected essentially by the VM notifier.list_lock. This series > intends to fix two points of illegal access. > > Patch 1 fixes an access of VM rebind_lists' link without the VM resv held. > Patch 2 fixes an issue where the VMA may not be removed from the > VM notifier.rebind_list on VMA destruction. Tested-by: José Roberto de Souza This improved overall stability and fixed the 'list_add corruption' errors, thank you. > > Thomas Hellström (2): > drm/xe: Fix unlocked access of the vma::rebind_link > drm/xe: Properly remove the vma from the vm::notifer::rebind_list when > destroyed > > drivers/gpu/drm/xe/xe_vm.c | 23 --- > 1 file changed, 16 insertions(+), 7 deletions(-) >
Re: [Intel-xe] [PATCH] drm/xe/display: Do not use i915 frontbuffer tracking implementation
On Mon, 2023-03-06 at 15:16 +0100, Maarten Lankhorst wrote:
> As a fallback if we decide not to merge the frontbuffer tracking, allow
> i915 to keep its own implementation, and do the right thing in Xe.
>
> The frontbuffer tracking for Xe is still done per-fb, while i915 can
> keep doing the weird intel_frontbuffer + i915_active thing without
> blocking Xe.
Please also disable PSR and FBC with this or at least add a way for users to
disable those features.
Without frontbuffer tracker those two features will break in some cases.
>
> Signed-off-by: Maarten Lankhorst
> ---
> .../gpu/drm/i915/display/intel_display_types.h | 12
> drivers/gpu/drm/i915/display/intel_drrs.c | 1 +
> drivers/gpu/drm/i915/display/intel_fb.c | 8 +---
> drivers/gpu/drm/i915/display/intel_fbdev.c | 2 +-
> .../gpu/drm/i915/display/intel_frontbuffer.c| 17 +
> .../gpu/drm/i915/display/intel_frontbuffer.h| 12 ++--
> drivers/gpu/drm/i915/display/intel_psr.c| 1 +
> .../gpu/drm/i915/display/skl_universal_plane.c | 2 ++
> 8 files changed, 45 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index f2918bb07107..a4a57aa24422 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -133,7 +133,11 @@ struct intel_fb_view {
>
> struct intel_framebuffer {
> struct drm_framebuffer base;
> +#ifdef I915
> struct intel_frontbuffer *frontbuffer;
> +#else
> + atomic_t bits;
> +#endif
>
> /* Params to remap the FB pages and program the plane registers in each
> view. */
> struct intel_fb_view normal_view;
> @@ -2074,10 +2078,18 @@ static inline u32 intel_plane_ggtt_offset(const
> struct intel_plane_state *plane_
> #endif
> }
>
> +#ifdef I915
> static inline struct intel_frontbuffer *
> to_intel_frontbuffer(struct drm_framebuffer *fb)
> {
> return fb ? to_intel_framebuffer(fb)->frontbuffer : NULL;
> }
> +#else
> +static inline struct intel_framebuffer *
> +to_intel_frontbuffer(struct drm_framebuffer *fb)
> +{
> + return fb ? to_intel_framebuffer(fb) : NULL;
> +}
> +#endif
>
> #endif /* __INTEL_DISPLAY_TYPES_H__ */
> diff --git a/drivers/gpu/drm/i915/display/intel_drrs.c
> b/drivers/gpu/drm/i915/display/intel_drrs.c
> index 5b9e3814..3503d112387d 100644
> --- a/drivers/gpu/drm/i915/display/intel_drrs.c
> +++ b/drivers/gpu/drm/i915/display/intel_drrs.c
> @@ -9,6 +9,7 @@
> #include "intel_de.h"
> #include "intel_display_types.h"
> #include "intel_drrs.h"
> +#include "intel_frontbuffer.h"
> #include "intel_panel.h"
>
> /**
> diff --git a/drivers/gpu/drm/i915/display/intel_fb.c
> b/drivers/gpu/drm/i915/display/intel_fb.c
> index 8c357a4098f6..e67c71f9b29d 100644
> --- a/drivers/gpu/drm/i915/display/intel_fb.c
> +++ b/drivers/gpu/drm/i915/display/intel_fb.c
> @@ -1846,6 +1846,8 @@ static void intel_user_framebuffer_destroy(struct
> drm_framebuffer *fb)
> #ifdef I915
> if (intel_fb_uses_dpt(fb))
> intel_dpt_destroy(intel_fb->dpt_vm);
> +
> + intel_frontbuffer_put(intel_fb->frontbuffer);
> #else
> if (intel_fb_obj(fb)->flags & XE_BO_CREATE_PINNED_BIT) {
> struct xe_bo *bo = intel_fb_obj(fb);
> @@ -1857,8 +1859,6 @@ static void intel_user_framebuffer_destroy(struct
> drm_framebuffer *fb)
> }
> #endif
>
> - intel_frontbuffer_put(intel_fb->frontbuffer);
> -
> kfree(intel_fb);
> }
>
> @@ -1966,9 +1966,9 @@ int intel_framebuffer_init(struct intel_framebuffer
> *intel_fb,
> obj->flags |= XE_BO_SCANOUT_BIT;
> }
> ttm_bo_unreserve(&obj->ttm);
> -#endif
>
> atomic_set(&intel_fb->bits, 0);
> +#endif
>
> if (!drm_any_plane_has_format(&dev_priv->drm,
> mode_cmd->pixel_format,
> @@ -2085,7 +2085,9 @@ int intel_framebuffer_init(struct intel_framebuffer
> *intel_fb,
> return 0;
>
> err:
> +#ifdef I915
> intel_frontbuffer_put(intel_fb->frontbuffer);
> +#endif
> return ret;
> }
>
> diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c
> b/drivers/gpu/drm/i915/display/intel_fbdev.c
> index 75d8029185f0..2682b26b511f 100644
> --- a/drivers/gpu/drm/i915/display/intel_fbdev.c
> +++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
> @@ -82,7 +82,7 @@ struct intel_fbdev {
>
> static struct intel_frontbuffer *to_frontbuffer(struct intel_fbdev *ifbdev)
> {
> - return ifbdev->fb->frontbuffer;
> + return to_intel_frontbuffer(&ifbdev->fb->base);
> }
>
> static void intel_fbdev_invalidate(struct intel_fbdev *ifbdev)
> diff --git a/drivers/gpu/drm/i915/display/intel_frontbuffer.c
> b/drivers/gpu/drm/i915/display/intel_frontbuffer.c
> index 17a7aa8b28c2..64fe73d2ac4d 100644
> --- a/drivers/gpu/drm/i915/display/intel_frontbuffer.c
> +++ b/drivers/gpu/drm/i915/display/i
Re: [PATCH] drm: i915: fix a possible refcount leak in intel_dp_add_mst_connector()
On Mon, 2022-05-16 at 15:19 +0800, Hangyu Hua wrote:
> If drm_connector_init fails, intel_connector_free will be called to take
> care of proper free. So it is necessary to drop the refcount of port
> before intel_connector_free.
Reviewed-by: José Roberto de Souza
>
> Fixes: 091a4f91942a ("drm/i915: Handle drm-layer errors in
> intel_dp_add_mst_connector")
> Signed-off-by: Hangyu Hua
> ---
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index e30e698aa684..f7d46ea3afb9 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> @@ -841,6 +841,7 @@ static struct drm_connector
> *intel_dp_add_mst_connector(struct drm_dp_mst_topolo
> ret = drm_connector_init(dev, connector, &intel_dp_mst_connector_funcs,
>DRM_MODE_CONNECTOR_DisplayPort);
> if (ret) {
> + drm_dp_mst_put_port_malloc(port);
> intel_connector_free(intel_connector);
> return NULL;
> }
Re: [PATCH] drm/i915/pvc: Add recommended MMIO setting
On Mon, 2022-06-13 at 09:53 -0700, Matt Roper wrote:
> As with past platforms, the bspec's performance tuning guide provides
> recommended MMIO settings. Although not technically "workarounds" we
> apply these through the workaround framework to ensure that they're
> re-applied at the proper times (e.g., on engine resets) and that any
> conflicts with real workarounds are flagged.
Reviewed-by: José Roberto de Souza
>
> Bspec: 72161
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/gt/intel_gt_regs.h | 5 +
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 9 +
> 2 files changed, 14 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> index 226557018037..07ef111947b8 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> @@ -981,6 +981,11 @@
> #define XEHP_L3SCQREG7 _MMIO(0xb188)
> #define BLEND_FILL_CACHING_OPT_DIS REG_BIT(3)
>
> +#define XEHPC_L3SCRUB_MMIO(0xb18c)
> +#define SCRUB_CL_DWNGRADE_SHARED REG_BIT(12)
> +#define SCRUB_RATE_PER_BANK_MASK REG_GENMASK(2, 0)
> +#define SCRUB_RATE_4B_PER_CLK
> REG_FIELD_PREP(SCRUB_RATE_PER_BANK_MASK, 0x6)
> +
> #define L3SQCREG1_CCS0 _MMIO(0xb200)
> #define FLUSHALLNONCOH REG_BIT(5)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index 1e982ac931dc..c4af51144216 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -2679,6 +2679,15 @@ general_render_compute_wa_init(struct intel_engine_cs
> *engine, struct i915_wa_li
> {
> struct drm_i915_private *i915 = engine->i915;
>
> + if (IS_PONTEVECCHIO(i915)) {
> + /*
> + * The following is not actually a "workaround" but rather
> + * a recommended tuning setting documented in the bspec's
> + * performance guide section.
> + */
> + wa_write(wal, XEHPC_L3SCRUB, SCRUB_CL_DWNGRADE_SHARED |
> SCRUB_RATE_4B_PER_CLK);
> + }
> +
> if (IS_XEHPSDV(i915)) {
> /* Wa_1409954639 */
> wa_masked_en(wal,
Re: [PATCH] drm/i915/pvc: GuC depriv applies to PVC
On Thu, 2022-06-02 at 16:30 -0700, Matt Roper wrote:
> We missed this setting in the initial device info patch's definition of
> XE_HPC_FEATURES.
Reviewed-by: José Roberto de Souza
>
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/i915_pci.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index 047a6e326031..a5a1a7647320 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -1089,6 +1089,7 @@ static const struct intel_device_info ats_m_info = {
> XE_HP_FEATURES, \
> .dma_mask_size = 52, \
> .has_3d_pipeline = 0, \
> + .has_guc_deprivilege = 1, \
> .has_l3_ccs_read = 1, \
> .has_one_eu_per_fuse_bit = 1
>
Re: [PATCH] drm/i915: Add extra registers to GPU error dump
On Wed, 2022-06-01 at 14:06 -0700, Matt Roper wrote:
> From: Stuart Summers
>
> Our internal teams have identified a few additional engine registers
> that are worth inspecting in error state dumps during development &
> debug. Let's capture and print them as part of our error dump.
>
> For simplicity we'll just dump these registers on gen11 and beyond.
> Most of these registers have existed since earlier platforms (e.g., gen6
> or gen7) but were initially introduced only for a subset of the
> platforms' engines; gen11 seems to be where they became available on all
> engines.
Reviewed-by: José Roberto de Souza
>
> Signed-off-by: Stuart Summers
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/gt/intel_engine_regs.h | 5 +
> drivers/gpu/drm/i915/i915_gpu_error.c | 19 +++
> drivers/gpu/drm/i915/i915_gpu_error.h | 7 +++
> 3 files changed, 31 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_regs.h
> b/drivers/gpu/drm/i915/gt/intel_engine_regs.h
> index 44de10cf7837..889f0df3940b 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_regs.h
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_regs.h
> @@ -8,6 +8,7 @@
>
> #include "i915_reg_defs.h"
>
> +#define RING_EXCC(base) _MMIO((base) + 0x28)
> #define RING_TAIL(base) _MMIO((base) + 0x30)
> #define TAIL_ADDR 0x0018
> #define RING_HEAD(base) _MMIO((base) + 0x34)
> @@ -133,6 +134,8 @@
> (REG_FIELD_PREP(BLIT_CCTL_DST_MOCS_MASK, (dst) << 1) | \
>REG_FIELD_PREP(BLIT_CCTL_SRC_MOCS_MASK, (src) << 1))
>
> +#define RING_CSCMDOP(base) _MMIO((base) + 0x20c)
> +
> /*
> * CMD_CCTL read/write fields take a MOCS value and _not_ a table index.
> * The lsb of each can be considered a separate enabling bit for encryption.
> @@ -149,6 +152,7 @@
>REG_FIELD_PREP(CMD_CCTL_READ_OVERRIDE_MASK, (read) << 1))
>
> #define RING_PREDICATE_RESULT(base) _MMIO((base) + 0x3b8) /* gen12+
> */
> +
> #define MI_PREDICATE_RESULT_2(base) _MMIO((base) + 0x3bc)
> #define LOWER_SLICE_ENABLED(1 << 0)
> #define LOWER_SLICE_DISABLED (0 << 0)
> @@ -172,6 +176,7 @@
> #defineCTX_CTRL_ENGINE_CTX_SAVE_INHIBIT REG_BIT(2)
> #defineCTX_CTRL_INHIBIT_SYN_CTX_SWITCH REG_BIT(3)
> #defineGEN12_CTX_CTRL_OAR_CONTEXT_ENABLE REG_BIT(8)
> +#define RING_CTX_SR_CTL(base)_MMIO((base) + 0x244)
> #define RING_SEMA_WAIT_POLL(base)_MMIO((base) + 0x24c)
> #define GEN8_RING_PDP_UDW(base, n) _MMIO((base) + 0x270 + (n) * 8
> + 4)
> #define GEN8_RING_PDP_LDW(base, n) _MMIO((base) + 0x270 + (n) * 8)
> diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
> b/drivers/gpu/drm/i915/i915_gpu_error.c
> index 0512c66fa4f3..bff8a111424a 100644
> --- a/drivers/gpu/drm/i915/i915_gpu_error.c
> +++ b/drivers/gpu/drm/i915/i915_gpu_error.c
> @@ -581,6 +581,15 @@ static void error_print_engine(struct
> drm_i915_error_state_buf *m,
> err_printf(m, " RC PSMI: 0x%08x\n", ee->rc_psmi);
> err_printf(m, " FAULT_REG: 0x%08x\n", ee->fault_reg);
> }
> + if (GRAPHICS_VER(m->i915) >= 11) {
> + err_printf(m, " NOPID: 0x%08x\n", ee->nopid);
> + err_printf(m, " EXCC: 0x%08x\n", ee->excc);
> + err_printf(m, " CMD_CCTL: 0x%08x\n", ee->cmd_cctl);
> + err_printf(m, " CSCMDOP: 0x%08x\n", ee->cscmdop);
> + err_printf(m, " CTX_SR_CTL: 0x%08x\n", ee->ctx_sr_ctl);
> + err_printf(m, " DMA_FADDR_HI: 0x%08x\n", ee->dma_faddr_hi);
> + err_printf(m, " DMA_FADDR_LO: 0x%08x\n", ee->dma_faddr_lo);
> + }
> if (HAS_PPGTT(m->i915)) {
> err_printf(m, " GFX_MODE: 0x%08x\n", ee->vm_info.gfx_mode);
>
> @@ -1224,6 +1233,16 @@ static void engine_record_registers(struct
> intel_engine_coredump *ee)
> ee->ipehr = ENGINE_READ(engine, IPEHR);
> }
>
> + if (GRAPHICS_VER(i915) >= 11) {
> + ee->cmd_cctl = ENGINE_READ(engine, RING_CMD_CCTL);
> + ee->cscmdop = ENGINE_READ(engine, RING_CSCMDOP);
> + ee->ctx_sr_ctl = ENGINE_READ(engine, RING_CTX_SR_CTL);
> + ee->dma_faddr_hi = ENGINE_READ(engine, RING_DMA_FADD_UDW);
> + ee->dma_faddr_lo = ENGINE_READ(engine, RING_DMA_FADD);
> + ee->nopid = ENGINE_READ(engine, RING_NOPID);
> + ee->excc = ENGINE_READ(engine, RING_EXCC);
> + }
> +
> intel_engine_get_instdone(engine, &ee->instdone);
>
> ee->instpm = ENGINE_READ(engine, RING_INSTPM);
> diff --git a/drivers/gpu/drm/i915/i915_gpu_error.h
> b/drivers/gpu/drm/i915/i915_gpu_error.h
> index a611abacd9c2..55a143b92d10 100644
> --- a/drivers/gpu/drm/i915/i915_gpu_error.h
> +++ b/drivers/gpu/d
Re: [PATCH v3 1/3] drm/print: Add drm_debug_once* macros
On Tue, 2022-05-10 at 21:33 +0300, Jouni Högander wrote:
> Add drm_debug_once* macros to allow printing out one time debug
> messages which can be still controlled via drm.debug parameter.
Reviewed-by: José Roberto de Souza
>
> Cc: José Roberto de Souza
> Cc: Mika Kahola
> Cc: Mark Pearson
> Signed-off-by: Jouni Högander
> ---
> include/drm/drm_print.h | 29 +
> 1 file changed, 29 insertions(+)
>
> diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
> index 22fabdeed297..e339f47eeb6d 100644
> --- a/include/drm/drm_print.h
> +++ b/include/drm/drm_print.h
> @@ -476,6 +476,35 @@ void drm_dev_dbg(const struct device *dev, enum
> drm_debug_category category,
> #define drm_dbg_drmres(drm, fmt, ...)
> \
> drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_DRMRES, fmt,
> ##__VA_ARGS__)
>
> +#define drm_dev_dbg_once(dev, cat, fmt, ...) \
> +({ \
> + static bool __print_once __read_mostly; \
> + if (!__print_once) {\
> + __print_once = true;\
> + drm_dev_dbg(dev, cat, fmt, ##__VA_ARGS__); \
> + } \
> +})
> +
> +#define drm_dbg_once_core(drm, fmt, ...)
> \
> + drm_dev_dbg_once((drm) ? (drm)->dev : NULL, DRM_UT_CORE, fmt,
> ##__VA_ARGS__)
> +#define drm_dbg_once(drm, fmt, ...)
> \
> + drm_dev_dbg_once((drm) ? (drm)->dev : NULL, DRM_UT_DRIVER, fmt,
> ##__VA_ARGS__)
> +#define drm_dbg_once_kms(drm, fmt, ...)
> \
> + drm_dev_dbg_once((drm) ? (drm)->dev : NULL, DRM_UT_KMS, fmt,
> ##__VA_ARGS__)
> +#define drm_dbg_once_prime(drm, fmt, ...)
> \
> + drm_dev_dbg_once((drm) ? (drm)->dev : NULL, DRM_UT_PRIME, fmt,
> ##__VA_ARGS__)
> +#define drm_dbg_once_atomic(drm, fmt, ...)
> \
> + drm_dev_dbg_once((drm) ? (drm)->dev : NULL, DRM_UT_ATOMIC, fmt,
> ##__VA_ARGS__)
> +#define drm_dbg_once_vbl(drm, fmt, ...)
> \
> + drm_dev_dbg_once((drm) ? (drm)->dev : NULL, DRM_UT_VBL, fmt,
> ##__VA_ARGS__)
> +#define drm_dbg_once_state(drm, fmt, ...)
> \
> + drm_dev_dbg_once((drm) ? (drm)->dev : NULL, DRM_UT_STATE, fmt,
> ##__VA_ARGS__)
> +#define drm_dbg_once_lease(drm, fmt, ...)
> \
> + drm_dev_dbg_once((drm) ? (drm)->dev : NULL, DRM_UT_LEASE, fmt,
> ##__VA_ARGS__)
> +#define drm_dbg_once_dp(drm, fmt, ...)
> \
> + drm_dev_dbg_once((drm) ? (drm)->dev : NULL, DRM_UT_DP, fmt,
> ##__VA_ARGS__)
> +#define drm_dbg_once_drmres(drm, fmt, ...)
> \
> + drm_dev_dbg_once((drm) ? (drm)->dev : NULL, DRM_UT_DRMRES, fmt,
> ##__VA_ARGS__)
>
> /*
> * printk based logging
Re: [PATCH v3 3/3] drm/i915: Ensure damage clip area is within pipe area
On Tue, 2022-05-10 at 21:33 +0300, Jouni Högander wrote:
> Current update area calculation is not handling situation where
> e.g. cursor plane is fully or partially outside pipe area.
>
> Fix this by checking damage area against pipe_src area using
> drm_rect_intersect.
>
> v2: Set x1 and x2 in damaged_area initialization
> v3: Move drm_rect_intersect into clip_area_update
>
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5440
> Cc: José Roberto de Souza
> Cc: Mika Kahola
> Cc: Mark Pearson
> Signed-off-by: Jouni Högander
> ---
> drivers/gpu/drm/i915/display/intel_psr.c | 24 +---
> 1 file changed, 17 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index 3561c218cfb1..f4b4c1c83d2b 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -1618,8 +1618,12 @@ static void psr2_man_trk_ctl_calc(struct
> intel_crtc_state *crtc_state,
> }
>
> static void clip_area_update(struct drm_rect *overlap_damage_area,
> - struct drm_rect *damage_area)
> + struct drm_rect *damage_area,
> + struct drm_rect *draw_area)
s/draw_area/pipe_src?
> {
> + if (!drm_rect_intersect(damage_area, draw_area))
> + return;
> +
> if (overlap_damage_area->y1 == -1) {
> overlap_damage_area->y1 = damage_area->y1;
> overlap_damage_area->y2 = damage_area->y2;
> @@ -1709,7 +1713,8 @@ int intel_psr2_sel_fetch_update(struct
> intel_atomic_state *state,
>*/
> for_each_oldnew_intel_plane_in_state(state, plane, old_plane_state,
>new_plane_state, i) {
> - struct drm_rect src, damaged_area = { .y1 = -1 };
> + struct drm_rect src, damaged_area = { .x1 = 0, .y1 = -1,
> + .x2 = INT_MAX };
> struct drm_atomic_helper_damage_iter iter;
> struct drm_rect clip;
>
> @@ -1736,20 +1741,23 @@ int intel_psr2_sel_fetch_update(struct
> intel_atomic_state *state,
> if (old_plane_state->uapi.visible) {
> damaged_area.y1 = old_plane_state->uapi.dst.y1;
> damaged_area.y2 = old_plane_state->uapi.dst.y2;
> - clip_area_update(&pipe_clip, &damaged_area);
> + clip_area_update(&pipe_clip, &damaged_area,
> + &crtc_state->pipe_src);
> }
>
> if (new_plane_state->uapi.visible) {
> damaged_area.y1 = new_plane_state->uapi.dst.y1;
> damaged_area.y2 = new_plane_state->uapi.dst.y2;
> - clip_area_update(&pipe_clip, &damaged_area);
> + clip_area_update(&pipe_clip, &damaged_area,
> + &crtc_state->pipe_src);
> }
> continue;
> } else if (new_plane_state->uapi.alpha !=
> old_plane_state->uapi.alpha) {
> /* If alpha changed mark the whole plane area as
> damaged */
> damaged_area.y1 = new_plane_state->uapi.dst.y1;
> damaged_area.y2 = new_plane_state->uapi.dst.y2;
> - clip_area_update(&pipe_clip, &damaged_area);
> + clip_area_update(&pipe_clip, &damaged_area,
> + &crtc_state->pipe_src);
> continue;
> }
>
> @@ -1760,7 +1768,8 @@ int intel_psr2_sel_fetch_update(struct
> intel_atomic_state *state,
> &new_plane_state->uapi);
> drm_atomic_for_each_plane_damage(&iter, &clip) {
> if (drm_rect_intersect(&clip, &src))
> - clip_area_update(&damaged_area, &clip);
> + clip_area_update(&damaged_area, &clip,
> + &crtc_state->pipe_src);
> }
>
> if (damaged_area.y1 == -1)
> @@ -1768,7 +1777,8 @@ int intel_psr2_sel_fetch_update(struct
> intel_atomic_state *state,
>
> damaged_area.y1 += new_plane_state->uapi.dst.y1 - src.y1;
> damaged_area.y2 += new_plane_state->uapi.dst.y1 - src.y1;
> - clip_area_update(&pipe_clip, &damaged_area);
> +
> + clip_area_update(&pipe_clip, &damaged_area,
> &crtc_state->pipe_src);
white space ^
with those nits:
Reviewed-by: José Roberto de Souza
> }
>
> /*
Re: [PATCH v3 2/3] drm/i915/psr: Use full update In case of area calculation fails
On Tue, 2022-05-10 at 21:33 +0300, Jouni Högander wrote:
> Currently we have some corner cases where area calculation fails. For
> these sel fetch area calculation ends up having update area as y1 = 0,
> y2 = 4. Instead of these values safer option is full update.
>
> One of such for example is big fb with offset. We don't have usable
> offset in psr2_sel_fetch_update. Currently it's open what is the
> proper way to fix this corner case. Use full update for now.
>
> v2: Commit message modified
> v3: Print out debug info once when area calculation fails
>
> Cc: José Roberto de Souza
> Cc: Mika Kahola
> Cc: Mark Pearson
> Signed-off-by: Jouni Högander
> ---
> drivers/gpu/drm/i915/display/intel_psr.c | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index 06db407e2749..3561c218cfb1 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -1685,6 +1685,7 @@ static bool psr2_sel_fetch_pipe_state_supported(const
> struct intel_crtc_state *c
> int intel_psr2_sel_fetch_update(struct intel_atomic_state *state,
> struct intel_crtc *crtc)
> {
> + struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> struct intel_crtc_state *crtc_state =
> intel_atomic_get_new_crtc_state(state, crtc);
> struct drm_rect pipe_clip = { .x1 = 0, .y1 = -1, .x2 = INT_MAX, .y2 =
> -1 };
> struct intel_plane_state *new_plane_state, *old_plane_state;
> @@ -1770,6 +1771,17 @@ int intel_psr2_sel_fetch_update(struct
> intel_atomic_state *state,
> clip_area_update(&pipe_clip, &damaged_area);
> }
>
> + /*
> + * TODO: For now we are just using full update in case
> + * selective fetch area calculation fails. To optimize this we
> + * should identify cases where this happens and fix the area
> + * calculation for those.
> + */
> + if (pipe_clip.y1 == -1) {
> + drm_dbg_once_kms(&dev_priv->drm, "No selective fetch area,
> using full update");
The debug message is misleading, a better message would be: Selective fetch
area calculation failed in pipeA.
with that:
Reviewed-by: José Roberto de Souza
> + full_update = true;
> + }
> +
> if (full_update)
> goto skip_sel_fetch_set_loop;
>
Re: [PATCH 11/11] drm/i915/pvc: read fuses for link copy engines
On Mon, 2022-05-02 at 09:34 -0700, Matt Roper wrote:
> From: Lucas De Marchi
>
> The new Link Copy engines in PVC may be fused off according to the
> mslice_mask. Each bit of the MEML3_EN_MASK we read from the
> GEN10_MIRROR_FUSE3 register disables a pair of link copy engines.
Reviewed-by: José Roberto de Souza
>
> Bspec: 44483
> Cc: Matt Roper
> Signed-off-by: Lucas De Marchi
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/gt/intel_engine_cs.c | 28 +++
> 1 file changed, 28 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> index c6e93db134b1..d10cdeff5072 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> @@ -686,6 +686,33 @@ static void engine_mask_apply_compute_fuses(struct
> intel_gt *gt)
> }
> }
>
> +static void engine_mask_apply_copy_fuses(struct intel_gt *gt)
> +{
> + struct drm_i915_private *i915 = gt->i915;
> + struct intel_gt_info *info = >->info;
> + unsigned long meml3_mask;
> + u8 quad;
> +
> + meml3_mask = intel_uncore_read(gt->uncore, GEN10_MIRROR_FUSE3);
> + meml3_mask = REG_FIELD_GET(GEN12_MEML3_EN_MASK, meml3_mask);
> +
> + /*
> + * Link Copy engines may be fused off according to meml3_mask. Each
> + * bit is a quad that houses 2 Link Copy and two Sub Copy engines.
> + */
> + for_each_clear_bit(quad, &meml3_mask, GEN12_MAX_MSLICES) {
> + intel_engine_mask_t mask = GENMASK(BCS1 + quad * 2 + 1,
> +BCS1 + quad * 2);
> +
> + if (mask & info->engine_mask) {
> + drm_dbg(&i915->drm, "bcs%u fused off\n", quad * 2 + 1);
> + drm_dbg(&i915->drm, "bcs%u fused off\n", quad * 2 + 2);
> +
> + info->engine_mask &= ~mask;
> + }
> + }
> +}
> +
> /*
> * Determine which engines are fused off in our particular hardware.
> * Note that we have a catch-22 situation where we need to be able to access
> @@ -768,6 +795,7 @@ static intel_engine_mask_t init_engine_mask(struct
> intel_gt *gt)
> GEM_BUG_ON(vebox_mask != VEBOX_MASK(gt));
>
> engine_mask_apply_compute_fuses(gt);
> + engine_mask_apply_copy_fuses(gt);
>
> return info->engine_mask;
> }
Re: [PATCH 06/11] drm/i915/pvc: Reduce stack usage in reset selftest with extra blitter engine
On Mon, 2022-05-02 at 09:34 -0700, Matt Roper wrote:
> From: John Harrison
>
> PVC adds extra blitter engines (in the following patch). The reset
> selftest has a local array on the stack which is sized by the number
> of engines. The increase pushes the size of this array to the point
> where it trips the 'stack too large' compile warning. This patch takes
> the allocation of the stack and makes it dynamic instead.
Reviewed-by: José Roberto de Souza
>
> Signed-off-by: John Harrison
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
> b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
> index 83ff4c2e57c5..3b9d82276db2 100644
> --- a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
> +++ b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
> @@ -979,6 +979,7 @@ static int __igt_reset_engines(struct intel_gt *gt,
> enum intel_engine_id id, tmp;
> struct hang h;
> int err = 0;
> + struct active_engine *threads;
>
> /* Check that issuing a reset on one engine does not interfere
>* with any other engine.
> @@ -996,8 +997,11 @@ static int __igt_reset_engines(struct intel_gt *gt,
> h.ctx->sched.priority = 1024;
> }
>
> + threads = kzalloc(sizeof(*threads) * I915_NUM_ENGINES, GFP_KERNEL);
> + if (!threads)
> + return -ENOMEM;
> +
> for_each_engine(engine, gt, id) {
> - struct active_engine threads[I915_NUM_ENGINES] = {};
> unsigned long device = i915_reset_count(global);
> unsigned long count = 0, reported;
> bool using_guc = intel_engine_uses_guc(engine);
> @@ -1016,7 +1020,7 @@ static int __igt_reset_engines(struct intel_gt *gt,
> break;
> }
>
> - memset(threads, 0, sizeof(threads));
> + memset(threads, 0, sizeof(*threads) * I915_NUM_ENGINES);
> for_each_engine(other, gt, tmp) {
> struct task_struct *tsk;
>
> @@ -1236,6 +1240,7 @@ static int __igt_reset_engines(struct intel_gt *gt,
> break;
> }
> }
> + kfree(threads);
>
> if (intel_gt_is_wedged(gt))
> err = -EIO;
Re: [Intel-gfx] [PATCH 07/11] drm/i915/pvc: Engines definitions for new copy engines
On Mon, 2022-05-02 at 09:34 -0700, Matt Roper wrote:
> This patch adds the basic definitions needed to support
> new copy engines. Also updating the cmd_info to accommodate
> new engines, as the engine id's of legacy engines have been
> changed.
Reviewed-by: José Roberto de Souza
>
> Original-author: CQ Tang
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/gt/intel_engine_cs.c| 56
> drivers/gpu/drm/i915/gt/intel_engine_types.h | 10 +++-
> drivers/gpu/drm/i915/gt/intel_gt_regs.h | 8 +++
> drivers/gpu/drm/i915/gvt/cmd_parser.c| 2 +-
> drivers/gpu/drm/i915/i915_reg.h | 8 +++
> 5 files changed, 82 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> index 14c6ddbbfde8..4532c3ea9ace 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> @@ -71,6 +71,62 @@ static const struct engine_info intel_engines[] = {
> { .graphics_ver = 6, .base = BLT_RING_BASE }
> },
> },
> + [BCS1] = {
> + .class = COPY_ENGINE_CLASS,
> + .instance = 1,
> + .mmio_bases = {
> + { .graphics_ver = 12, .base = XEHPC_BCS1_RING_BASE }
> + },
> + },
> + [BCS2] = {
> + .class = COPY_ENGINE_CLASS,
> + .instance = 2,
> + .mmio_bases = {
> + { .graphics_ver = 12, .base = XEHPC_BCS2_RING_BASE }
> + },
> + },
> + [BCS3] = {
> + .class = COPY_ENGINE_CLASS,
> + .instance = 3,
> + .mmio_bases = {
> + { .graphics_ver = 12, .base = XEHPC_BCS3_RING_BASE }
> + },
> + },
> + [BCS4] = {
> + .class = COPY_ENGINE_CLASS,
> + .instance = 4,
> + .mmio_bases = {
> + { .graphics_ver = 12, .base = XEHPC_BCS4_RING_BASE }
> + },
> + },
> + [BCS5] = {
> + .class = COPY_ENGINE_CLASS,
> + .instance = 5,
> + .mmio_bases = {
> + { .graphics_ver = 12, .base = XEHPC_BCS5_RING_BASE }
> + },
> + },
> + [BCS6] = {
> + .class = COPY_ENGINE_CLASS,
> + .instance = 6,
> + .mmio_bases = {
> + { .graphics_ver = 12, .base = XEHPC_BCS6_RING_BASE }
> + },
> + },
> + [BCS7] = {
> + .class = COPY_ENGINE_CLASS,
> + .instance = 7,
> + .mmio_bases = {
> + { .graphics_ver = 12, .base = XEHPC_BCS7_RING_BASE }
> + },
> + },
> + [BCS8] = {
> + .class = COPY_ENGINE_CLASS,
> + .instance = 8,
> + .mmio_bases = {
> + { .graphics_ver = 12, .base = XEHPC_BCS8_RING_BASE }
> + },
> + },
> [VCS0] = {
> .class = VIDEO_DECODE_CLASS,
> .instance = 0,
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
> b/drivers/gpu/drm/i915/gt/intel_engine_types.h
> index 298f2cc7a879..356c15cdccf0 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
> @@ -35,7 +35,7 @@
> #define OTHER_CLASS 4
> #define COMPUTE_CLASS5
> #define MAX_ENGINE_CLASS 5
> -#define MAX_ENGINE_INSTANCE 7
> +#define MAX_ENGINE_INSTANCE 8
>
> #define I915_MAX_SLICES 3
> #define I915_MAX_SUBSLICES 8
> @@ -107,6 +107,14 @@ struct i915_ctx_workarounds {
> enum intel_engine_id {
> RCS0 = 0,
> BCS0,
> + BCS1,
> + BCS2,
> + BCS3,
> + BCS4,
> + BCS5,
> + BCS6,
> + BCS7,
> + BCS8,
> VCS0,
> VCS1,
> VCS2,
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> index a0a49c16babd..aa2c0974b02c 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> @@ -1476,6 +1476,14 @@
> #define GEN11_KCR (19)
> #define GEN11_GTPM (16)
> #define GEN11_BCS (15)
> +#define XEHPC_BCS1 (14)
> +#define XEHPC_BCS2 (13)
> +#define XEHPC_BCS3 (12)
> +#define XEHPC_BCS4 (11)
> +#define XEHPC_BCS5 (10)
> +#define XEHPC_BCS6 (9)
> +#define XEHPC_BCS7 (8)
> +#define XEHPC_BCS8 (23)
> #define GEN12_CCS3 (7)
> #define GEN12_CCS2 (6)
> #define GEN12_CCS1 (5)
> diff --git a/drivers/gpu/drm/i915/gvt/cmd_parser.c
> b/drivers/gpu/drm/i915/gvt/cmd_parser.c
> index b9eb75a2b400..0ba2a
Re: [Intel-gfx] [PATCH 09/11] drm/i915/pvc: Reset support for new copy engines
On Mon, 2022-05-02 at 09:34 -0700, Matt Roper wrote:
> This patch adds the reset support for new copy engines
> in PVC.
Reviewed-by: José Roberto de Souza
>
> Bspec: 52549
> Original-author: CQ Tang
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/gt/intel_engine_cs.c | 8 +
> drivers/gpu/drm/i915/gt/intel_gt_regs.h | 44 +--
> 2 files changed, 34 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> index 4532c3ea9ace..c6e93db134b1 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> @@ -390,6 +390,14 @@ static u32 get_reset_domain(u8 ver, enum intel_engine_id
> id)
> static const u32 engine_reset_domains[] = {
> [RCS0] = GEN11_GRDOM_RENDER,
> [BCS0] = GEN11_GRDOM_BLT,
> + [BCS1] = XEHPC_GRDOM_BLT1,
> + [BCS2] = XEHPC_GRDOM_BLT2,
> + [BCS3] = XEHPC_GRDOM_BLT3,
> + [BCS4] = XEHPC_GRDOM_BLT4,
> + [BCS5] = XEHPC_GRDOM_BLT5,
> + [BCS6] = XEHPC_GRDOM_BLT6,
> + [BCS7] = XEHPC_GRDOM_BLT7,
> + [BCS8] = XEHPC_GRDOM_BLT8,
> [VCS0] = GEN11_GRDOM_MEDIA,
> [VCS1] = GEN11_GRDOM_MEDIA2,
> [VCS2] = GEN11_GRDOM_MEDIA3,
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> index fe09288a3145..98ede9c93f00 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> @@ -597,24 +597,32 @@
> /* GEN11 changed all bit defs except for FULL & RENDER */
> #define GEN11_GRDOM_FULL GEN6_GRDOM_FULL
> #define GEN11_GRDOM_RENDER GEN6_GRDOM_RENDER
> -#define GEN11_GRDOM_BLT(1 << 2)
> -#define GEN11_GRDOM_GUC(1 << 3)
> -#define GEN11_GRDOM_MEDIA (1 << 5)
> -#define GEN11_GRDOM_MEDIA2 (1 << 6)
> -#define GEN11_GRDOM_MEDIA3 (1 << 7)
> -#define GEN11_GRDOM_MEDIA4 (1 << 8)
> -#define GEN11_GRDOM_MEDIA5 (1 << 9)
> -#define GEN11_GRDOM_MEDIA6 (1 << 10)
> -#define GEN11_GRDOM_MEDIA7 (1 << 11)
> -#define GEN11_GRDOM_MEDIA8 (1 << 12)
> -#define GEN11_GRDOM_VECS (1 << 13)
> -#define GEN11_GRDOM_VECS2 (1 << 14)
> -#define GEN11_GRDOM_VECS3 (1 << 15)
> -#define GEN11_GRDOM_VECS4 (1 << 16)
> -#define GEN11_GRDOM_SFC0 (1 << 17)
> -#define GEN11_GRDOM_SFC1 (1 << 18)
> -#define GEN11_GRDOM_SFC2 (1 << 19)
> -#define GEN11_GRDOM_SFC3 (1 << 20)
> +#define XEHPC_GRDOM_BLT8 REG_BIT(31)
> +#define XEHPC_GRDOM_BLT7 REG_BIT(30)
> +#define XEHPC_GRDOM_BLT6 REG_BIT(29)
> +#define XEHPC_GRDOM_BLT5 REG_BIT(28)
> +#define XEHPC_GRDOM_BLT4 REG_BIT(27)
> +#define XEHPC_GRDOM_BLT3 REG_BIT(26)
> +#define XEHPC_GRDOM_BLT2 REG_BIT(25)
> +#define XEHPC_GRDOM_BLT1 REG_BIT(24)
> +#define GEN11_GRDOM_SFC3 REG_BIT(20)
> +#define GEN11_GRDOM_SFC2 REG_BIT(19)
> +#define GEN11_GRDOM_SFC1 REG_BIT(18)
> +#define GEN11_GRDOM_SFC0 REG_BIT(17)
> +#define GEN11_GRDOM_VECS4 REG_BIT(16)
> +#define GEN11_GRDOM_VECS3 REG_BIT(15)
> +#define GEN11_GRDOM_VECS2 REG_BIT(14)
> +#define GEN11_GRDOM_VECS REG_BIT(13)
> +#define GEN11_GRDOM_MEDIA8 REG_BIT(12)
> +#define GEN11_GRDOM_MEDIA7 REG_BIT(11)
> +#define GEN11_GRDOM_MEDIA6 REG_BIT(10)
> +#define GEN11_GRDOM_MEDIA5 REG_BIT(9)
> +#define GEN11_GRDOM_MEDIA4 REG_BIT(8)
> +#define GEN11_GRDOM_MEDIA3 REG_BIT(7)
> +#define GEN11_GRDOM_MEDIA2 REG_BIT(6)
> +#define GEN11_GRDOM_MEDIA REG_BIT(5)
> +#define GEN11_GRDOM_GUCREG_BIT(3)
> +#define GEN11_GRDOM_BLTREG_BIT(2)
> #define GEN11_VCS_SFC_RESET_BIT(instance) (GEN11_GRDOM_SFC0 <<
> ((instance) >> 1))
> #define GEN11_VECS_SFC_RESET_BIT(instance) (GEN11_GRDOM_SFC0 << (instance))
>
Re: [Intel-gfx] [PATCH 10/11] drm/i915/pvc: skip all copy engines from aux table invalidate
On Mon, 2022-05-02 at 09:34 -0700, Matt Roper wrote:
> From: Lucas De Marchi
>
> As we have more copy engines now, mask all of them from aux table
> invalidate.
Reviewed-by: José Roberto de Souza
>
> Cc: Prathap Kumar Valsan
> Signed-off-by: Lucas De Marchi
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> index 0de17b568b41..f262aed94ef3 100644
> --- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> @@ -275,7 +275,7 @@ int gen12_emit_flush_xcs(struct i915_request *rq, u32
> mode)
> if (!HAS_FLAT_CCS(rq->engine->i915) &&
> (rq->engine->class == VIDEO_DECODE_CLASS ||
>rq->engine->class == VIDEO_ENHANCEMENT_CLASS)) {
> - aux_inv = rq->engine->mask & ~BIT(BCS0);
> + aux_inv = rq->engine->mask & ~GENMASK(BCS8, BCS0);
> if (aux_inv)
> cmd += 4;
> }
Re: [PATCH 1/3] drm: Add infrastructure to allow seamless mode switches
On Tue, 2022-04-26 at 21:08 +0300, Ville Syrjälä wrote:
> On Thu, Apr 21, 2022 at 12:22:03PM -0700, José Roberto de Souza wrote:
> > Intel hardware supports change between modes with different refresh
> > rates without any glitches or visual artifacts, that feature is called
> > seamless DRRS.
> >
> > So far i915 driver was automatically changing between preferred panel
> > mode and lower refresh rate mode based on idleness but ChromeOS
> > compositor team is requesting to be in control of the mode switch.
> > So for a certain types of content it can switch to mode with a lower
> > refresh rate without user noticing a thing and saving power.
> >
> > This seamless mode switch will be triggered when user-space dispatch
> > a atomic commit with the new mode and clears the
> > DRM_MODE_ATOMIC_ALLOW_MODESET flag.
> >
> > A driver that don't implement atomic_seamless_mode_switch_check
> > function will continue to fail in the atomic check phase with
> > "[CRTC:%d:%s] requires full modeset" debug message.
> > While a driver that implements it and support the seamless change
> > between old and new mode will return 0 otherwise it should return the
> > appropried errno.
> >
> > So here adding basic drm infrastructure to that be supported by i915
> > and other drivers.
>
> I don't see the need for any extra infrastructure for this.
>
> I think we just need:
> - fix the fastset code to not suck
How would it know that only mode changed and not all other things that causes
mode_changed to be set?
For example: intel_digital_connector_atomic_check()
> - reprogram M/N during fastset
> - calculate eDP link params using panel's highest refresh rate mode
> to make sure we get the same link params for all refresh rates
>
> >
> > Cc: Vidya Srinivas
> > Cc: Sean Paul
> > Cc: Ville Syrjälä
> > Signed-off-by: José Roberto de Souza
> > ---
> > drivers/gpu/drm/drm_atomic.c | 1 +
> > drivers/gpu/drm/drm_atomic_helper.c | 16 +++
> > drivers/gpu/drm/drm_atomic_state_helper.c | 1 +
> > include/drm/drm_crtc.h| 25 +++
> > 4 files changed, 43 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index 58c0283fb6b0c..21525f9f4b4c1 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -437,6 +437,7 @@ static void drm_atomic_crtc_print_state(struct
> > drm_printer *p,
> > drm_printf(p, "\tself_refresh_active=%d\n", state->self_refresh_active);
> > drm_printf(p, "\tplanes_changed=%d\n", state->planes_changed);
> > drm_printf(p, "\tmode_changed=%d\n", state->mode_changed);
> > + drm_printf(p, "\tseamless_mode_changed=%d\n",
> > state->seamless_mode_changed);
> > drm_printf(p, "\tactive_changed=%d\n", state->active_changed);
> > drm_printf(p, "\tconnectors_changed=%d\n", state->connectors_changed);
> > drm_printf(p, "\tcolor_mgmt_changed=%d\n", state->color_mgmt_changed);
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > b/drivers/gpu/drm/drm_atomic_helper.c
> > index 9603193d2fa13..e6f3a966f7b86 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -631,6 +631,22 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
> > drm_dbg_atomic(dev, "[CRTC:%d:%s] mode changed\n",
> >crtc->base.id, crtc->name);
> > new_crtc_state->mode_changed = true;
> > +
> > + if (!state->allow_modeset &&
> > + crtc->funcs->atomic_seamless_mode_switch_check) {
> > + ret =
> > crtc->funcs->atomic_seamless_mode_switch_check(state, crtc);
> > + if (ret == -EOPNOTSUPP) {
> > + drm_dbg_atomic(dev, "[CRTC:%d:%s]
> > Seamless mode switch not supported\n",
> > + crtc->base.id,
> > crtc->name);
> > + return ret;
> > + }
> > +
> > + if (ret < 0)
> > + return ret;
> > +
> > + new_crtc_state->seamless_mode_changed = true;
> > + new_crtc_state->mode_changed = false;
> > + }
> > }
> >
> > if (old_crtc_state->enable != new_crtc_state->enable) {
> > diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c
> > b/drivers/gpu/drm/drm_atomic_state_helper.c
> > index 3b6d3bdbd0996..c093073ea6e11 100644
> > --- a/drivers/gpu/drm/drm_atomic_state_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_state_helper.c
> > @@ -142,6 +142,7 @@ void __drm_atomic_helper_crtc_duplicate_state(struct
> > drm_crtc *crtc,
> > if (state->gamma_lut)
> > drm_property_blob_get(state->gamma_lut);
> > state->mode_changed = false;
> > + state->seamless_mode_changed = f
Re: [Intel-gfx] [PATCH 2/3] drm/i915/display: Replace crtc_state's has_drrs by drrs_downclock_mode
On Mon, 2022-04-25 at 14:55 +0300, Jani Nikula wrote:
> On Thu, 21 Apr 2022, José Roberto de Souza wrote:
> > Will be adding some additional control options to DRRS that will
> > require to have the DRRS downclock mode stored in the crtc_state.
> >
> > So to optimize memory usage a bit here using it to replace has_drrs
> > as we can check if the drrs_downclock_mode pointer is different than
> > null to have the same behavior has has_drrs.
> >
> > Cc: Vidya Srinivas
> > Cc: Sean Paul
> > Cc: Ville Syrjälä
> > Signed-off-by: José Roberto de Souza
> > ---
> > drivers/gpu/drm/i915/display/intel_display.c | 4 ++--
> > drivers/gpu/drm/i915/display/intel_display_debugfs.c | 4 ++--
> > drivers/gpu/drm/i915/display/intel_display_types.h | 4 +++-
> > drivers/gpu/drm/i915/display/intel_dp.c | 2 +-
> > drivers/gpu/drm/i915/display/intel_drrs.c| 4 ++--
> > 5 files changed, 10 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index 0ddfce21a828d..a5f5caeced9a0 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -5360,7 +5360,7 @@ static void intel_dump_pipe_config(const struct
> > intel_crtc_state *pipe_config,
> >
> > drm_dbg_kms(&dev_priv->drm, "ips: %i, double wide: %i, drrs: %i\n",
> > pipe_config->ips_enabled, pipe_config->double_wide,
> > - pipe_config->has_drrs);
> > + CRTC_STATE_HAS_DRRS(pipe_config));
>
> I'll mostly let Ville comment on the series, but that macro is an
> eyesore and also just out of place in intel_display_types.h. Please make
> it a proper function intel_drrs_something_something() in
> intel_drrs.[ch].
Okay in making this a function but I don't have a good name for it neither.
intel_crtc_state_has_drrs() is worst than current name of the macro.
>
> BR,
> Jani.
>
> >
> > intel_dpll_dump_hw_state(dev_priv, &pipe_config->dpll_hw_state);
> >
> > @@ -7088,7 +7088,7 @@ static void intel_crtc_copy_fastset(const struct
> > intel_crtc_state *old_crtc_stat
> > new_crtc_state->fdi_m_n = old_crtc_state->fdi_m_n;
> > new_crtc_state->dp_m_n = old_crtc_state->dp_m_n;
> > new_crtc_state->dp_m2_n2 = old_crtc_state->dp_m2_n2;
> > - new_crtc_state->has_drrs = old_crtc_state->has_drrs;
> > + new_crtc_state->drrs_downclock_mode =
> > old_crtc_state->drrs_downclock_mode;
> > }
> >
> > static int intel_crtc_add_planes_to_state(struct intel_atomic_state *state,
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > index 452d773fd4e34..f9720562336da 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > @@ -1096,7 +1096,7 @@ static int i915_drrs_status(struct seq_file *m, void
> > *unused)
> >
> > /* DRRS Supported */
> > seq_printf(m, "\tDRRS Enabled: %s\n",
> > - str_yes_no(crtc_state->has_drrs));
> > + str_yes_no(CRTC_STATE_HAS_DRRS(crtc_state)));
> >
> > seq_printf(m, "\tDRRS Active: %s\n",
> >str_yes_no(intel_drrs_is_active(crtc)));
> > @@ -1786,7 +1786,7 @@ static int i915_drrs_ctl_set(void *data, u64 val)
> > crtc_state = to_intel_crtc_state(crtc->base.state);
> >
> > if (!crtc_state->hw.active ||
> > - !crtc_state->has_drrs)
> > + !CRTC_STATE_HAS_DRRS(crtc_state))
> > goto out;
> >
> > commit = crtc_state->uapi.commit;
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> > b/drivers/gpu/drm/i915/display/intel_display_types.h
> > index cfd042117b109..f0b3cfd3138ce 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> > +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> > @@ -1056,7 +1056,7 @@ struct intel_crtc_state {
> >
> > /* m2_n2 for eDP downclock */
> > struct intel_link_m_n dp_m2_n2;
> > - bool has_drrs;
> > + const struct drm_display_mode *drrs_downclock_mode;
> >
> > /* PSR is supported but might not be enabled due the lack of enabled
> > planes */
> > bool has_psr;
> > @@ -1264,6 +1264,8 @@ enum drrs_refresh_rate {
> > DRRS_REFRESH_RATE_LOW,
> > };
> >
> > +#define CRTC_STATE_HAS_DRRS(crtc_state)
> > (!!((crtc_state)->drrs_downclock_mode))
> > +
> > #define INTEL_PIPE_CRC_ENTRIES_NR 128
> > struct intel_pipe_crc {
> > spinlock_t lock;
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index d55acc4a028a8..feea172dd2753 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -1881,7 +1881,7 @@ intel_dp_drrs_compute_config(struct intel_connector
> > *conne
Re: [PATCH 2/2] drm/i915: Add logical mapping for video decode engines
On Wed, 2022-03-16 at 16:45 -0700, Lucas De Marchi wrote:
> From: Matthew Brost
>
> Add logical mapping for VDBOXs. This mapping is required for
> split-frame workloads, which otherwise fail with
>
> -F8C53528: [GUC] 0441-INVALID_ENGINE_SUBMIT_MASK
>
> ... if the application is using the logical id to reorder the engines and
> then using it for the batch buffer submission. It's not a big problem on
> media version 11 and 12 as they have only 2 instances of VCS and the
> logical to physical mapping is monotonically increasing - if the
> application is not using the logical id.
>
> Changing it for the previous platforms allows the media driver
> implementation for the next ones (12.50 and above) to be the same,
> checking the logical id. It should also not introduce any bug for the
> old versions of userspace not checking the id.
>
> The mapping added here is the complete map needed by XEHPSDV. Previous
> platforms with only 2 instances will just use a partial map and should
> still work.
>
> Cc: Matt Roper
> Signed-off-by: Matthew Brost
> [ Extend the mapping to media versions 11 and 12 and give proper
> justification in the commit message why ]
> Signed-off-by: Lucas De Marchi
> ---
> drivers/gpu/drm/i915/gt/intel_engine_cs.c | 22 +-
> 1 file changed, 17 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> index 8080479f27aa..afa2e61cf729 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> @@ -731,12 +731,24 @@ static void populate_logical_ids(struct intel_gt *gt,
> u8 *logical_ids,
>
> static void setup_logical_ids(struct intel_gt *gt, u8 *logical_ids, u8 class)
> {
> - int i;
> - u8 map[MAX_ENGINE_INSTANCE + 1];
> + /*
> + * Logical to physical mapping is needed for proper support
> + * to split-frame feature.
> + */
> + if (MEDIA_VER(gt->i915) >= 11 && class == VIDEO_DECODE_CLASS) {
> + static const u8 map[] = { 0, 2, 4, 6, 1, 3, 5, 7 };
You can drop the static.
Other than that LGTM.
Reviewed-by: José Roberto de Souza
>
> - for (i = 0; i < MAX_ENGINE_INSTANCE + 1; ++i)
> - map[i] = i;
> - populate_logical_ids(gt, logical_ids, class, map, ARRAY_SIZE(map));
> + populate_logical_ids(gt, logical_ids, class,
> + map, ARRAY_SIZE(map));
> + } else {
> + int i;
> + u8 map[MAX_ENGINE_INSTANCE + 1];
> +
> + for (i = 0; i < MAX_ENGINE_INSTANCE + 1; ++i)
> + map[i] = i;
> + populate_logical_ids(gt, logical_ids, class,
> + map, ARRAY_SIZE(map));
> + }
> }
>
> /**
Re: [PATCH 1/2] drm/i915: Fix renamed struct field
On Wed, 2022-03-16 at 16:45 -0700, Lucas De Marchi wrote:
> Earlier versions of commit a5b7ef27da60 ("drm/i915: Add struct to hold
> IP version") named "ver" as "arch" and then when it was renamed it
> missed the rename on MEDIA_VER_FULL() since it it's currently not used.
Reviewed-by: José Roberto de Souza
>
> Fixes: a5b7ef27da60 ("drm/i915: Add struct to hold IP version")
> Cc: José Roberto de Souza
> Cc: Matt Roper
> Signed-off-by: Lucas De Marchi
> ---
> drivers/gpu/drm/i915/i915_drv.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 26df561a4e94..7458b107a1d6 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -922,7 +922,7 @@ static inline struct intel_gt *to_gt(struct
> drm_i915_private *i915)
> (GRAPHICS_VER(i915) >= (from) && GRAPHICS_VER(i915) <= (until))
>
> #define MEDIA_VER(i915) (INTEL_INFO(i915)->media.ver)
> -#define MEDIA_VER_FULL(i915) IP_VER(INTEL_INFO(i915)->media.arch, \
> +#define MEDIA_VER_FULL(i915) IP_VER(INTEL_INFO(i915)->media.ver, \
> INTEL_INFO(i915)->media.rel)
> #define IS_MEDIA_VER(i915, from, until) \
> (MEDIA_VER(i915) >= (from) && MEDIA_VER(i915) <= (until))
Re: [PATCH 1/3] drm/i915: Report steering details in debugfs
On Mon, 2022-03-14 at 16:42 -0700, Matt Roper wrote:
> Add a new 'steering' node in each gt's debugfs directory that tells
> whether we're using explicit steering for various types of MCR ranges
> and, if so, what MMIO ranges it applies to.
>
> We're going to be transitioning away from implicit steering, even for
> slice/dss steering soon, so the information reported here will become
> increasingly valuable once that happens.
>
> Cc: Daniele Ceraolo Spurio
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/gt/intel_gt.c | 46 +
> drivers/gpu/drm/i915/gt/intel_gt.h | 2 +
> drivers/gpu/drm/i915/gt/intel_gt_debugfs.c | 13 ++
> drivers/gpu/drm/i915/gt/intel_gt_types.h| 5 +++
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 8 +++-
> 5 files changed, 73 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
> b/drivers/gpu/drm/i915/gt/intel_gt.c
> index 8a2483ccbfb9..041add4019fc 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt.c
> @@ -96,6 +96,12 @@ int intel_gt_assign_ggtt(struct intel_gt *gt)
> return gt->ggtt ? 0 : -ENOMEM;
> }
>
> +const char *intel_steering_types[] = {
missing static as kernel test bot reported.
with that fixed: Reviewed-by: José Roberto de Souza
> + "L3BANK",
> + "MSLICE",
> + "LNCF",
> +};
> +
> static const struct intel_mmio_range icl_l3bank_steering_table[] = {
> { 0x00B100, 0x00B3FF },
> {},
> @@ -932,6 +938,46 @@ u32 intel_gt_read_register(struct intel_gt *gt,
> i915_reg_t reg)
> return intel_uncore_read(gt->uncore, reg);
> }
>
> +static void report_steering_type(struct drm_printer *p,
> + struct intel_gt *gt,
> + enum intel_steering_type type,
> + bool dump_table)
> +{
> + const struct intel_mmio_range *entry;
> + u8 slice, subslice;
> +
> + BUILD_BUG_ON(ARRAY_SIZE(intel_steering_types) != NUM_STEERING_TYPES);
> +
> + if (!gt->steering_table[type]) {
> + drm_printf(p, "%s steering: uses default steering\n",
> +intel_steering_types[type]);
> + return;
> + }
> +
> + intel_gt_get_valid_steering(gt, type, &slice, &subslice);
> + drm_printf(p, "%s steering: sliceid=0x%x, subsliceid=0x%x\n",
> +intel_steering_types[type], slice, subslice);
> +
> + if (!dump_table)
> + return;
> +
> + for (entry = gt->steering_table[type]; entry->end; entry++)
> + drm_printf(p, "\t0x%06x - 0x%06x\n", entry->start, entry->end);
> +}
> +
> +void intel_gt_report_steering(struct drm_printer *p, struct intel_gt *gt,
> + bool dump_table)
> +{
> + drm_printf(p, "Default steering: sliceid=0x%x, subsliceid=0x%x\n",
> +gt->default_steering.groupid,
> +gt->default_steering.instanceid);
> +
> + if (HAS_MSLICES(gt->i915)) {
> + report_steering_type(p, gt, MSLICE, dump_table);
> + report_steering_type(p, gt, LNCF, dump_table);
> + }
> +}
> +
> void intel_gt_info_print(const struct intel_gt_info *info,
>struct drm_printer *p)
> {
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt.h
> b/drivers/gpu/drm/i915/gt/intel_gt.h
> index 0f571c8ee22b..3edece1865e4 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt.h
> @@ -87,6 +87,8 @@ static inline bool intel_gt_needs_read_steering(struct
> intel_gt *gt,
> u32 intel_gt_read_register_fw(struct intel_gt *gt, i915_reg_t reg);
> u32 intel_gt_read_register(struct intel_gt *gt, i915_reg_t reg);
>
> +void intel_gt_report_steering(struct drm_printer *p, struct intel_gt *gt,
> + bool dump_table);
> void intel_gt_info_print(const struct intel_gt_info *info,
>struct drm_printer *p);
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
> b/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
> index f103664b71d4..6f45b131a001 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
> @@ -6,6 +6,7 @@
> #include
>
> #include "i915_drv.h"
> +#include "intel_gt.h"
> #include "intel_gt_debugfs.h"
> #include "intel_gt_engines_debugfs.h"
> #include "intel_gt_pm_debugfs.h"
> @@ -57,10 +58,22 @@ static int __intel_gt_debugfs_reset_store(void *data, u64
> val)
> DEFINE_SIMPLE_ATTRIBUTE(reset_fops, __intel_gt_debugfs_reset_show,
> __intel_gt_debugfs_reset_store, "%llu\n");
>
> +static int steering_show(struct seq_file *m, void *data)
> +{
> + struct drm_printer p = drm_seq_file_printer(m);
> + struct intel_gt *gt = m->private;
> +
> + intel_gt_report_steering(&p, gt, true);
> +
> + return 0;
> +}
> +DEFINE_INTEL_GT_DEBUGFS_ATTRIBUTE(steering);
> +
> static void gt_debugfs_register(struct intel_gt *gt, struc
Re: [Intel-gfx] [PATCH] drm/i915: Reduce stack usage in debugfs due to SSEU
On Mon, 2022-03-14 at 19:08 -0700, Matt Roper wrote:
> From: John Harrison
>
> sseu_dev_info is already a pretty large structure which will likely
> continue to grow when future platforms increase potential DSS and EU
> counts. Let's switch the stack placement of this structure in debugfs
> with a dynamic allocation.
>
Reviewed-by: José Roberto de Souza
> Signed-off-by: John Harrison
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/gt/intel_sseu_debugfs.c | 22 +---
> 1 file changed, 14 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_sseu_debugfs.c
> b/drivers/gpu/drm/i915/gt/intel_sseu_debugfs.c
> index 6b944de48666..2d5d011e01db 100644
> --- a/drivers/gpu/drm/i915/gt/intel_sseu_debugfs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_sseu_debugfs.c
> @@ -248,7 +248,7 @@ int intel_sseu_status(struct seq_file *m, struct intel_gt
> *gt)
> {
> struct drm_i915_private *i915 = gt->i915;
> const struct intel_gt_info *info = >->info;
> - struct sseu_dev_info sseu;
> + struct sseu_dev_info *sseu;
> intel_wakeref_t wakeref;
>
> if (GRAPHICS_VER(i915) < 8)
> @@ -258,23 +258,29 @@ int intel_sseu_status(struct seq_file *m, struct
> intel_gt *gt)
> i915_print_sseu_info(m, true, HAS_POOLED_EU(i915), &info->sseu);
>
> seq_puts(m, "SSEU Device Status\n");
> - memset(&sseu, 0, sizeof(sseu));
> - intel_sseu_set_info(&sseu, info->sseu.max_slices,
> +
> + sseu = kzalloc(sizeof(*sseu), GFP_KERNEL);
> + if (!sseu)
> + return -ENOMEM;
> +
> + intel_sseu_set_info(sseu, info->sseu.max_slices,
> info->sseu.max_subslices,
> info->sseu.max_eus_per_subslice);
>
> with_intel_runtime_pm(&i915->runtime_pm, wakeref) {
> if (IS_CHERRYVIEW(i915))
> - cherryview_sseu_device_status(gt, &sseu);
> + cherryview_sseu_device_status(gt, sseu);
> else if (IS_BROADWELL(i915))
> - bdw_sseu_device_status(gt, &sseu);
> + bdw_sseu_device_status(gt, sseu);
> else if (GRAPHICS_VER(i915) == 9)
> - gen9_sseu_device_status(gt, &sseu);
> + gen9_sseu_device_status(gt, sseu);
> else if (GRAPHICS_VER(i915) >= 11)
> - gen11_sseu_device_status(gt, &sseu);
> + gen11_sseu_device_status(gt, sseu);
> }
>
> - i915_print_sseu_info(m, false, HAS_POOLED_EU(i915), &sseu);
> + i915_print_sseu_info(m, false, HAS_POOLED_EU(i915), sseu);
> +
> + kfree(sseu);
>
> return 0;
> }
Re: [PATCH] drm/i915/psr: Disable PSR2 selective fetch for all TGL steps
On Mon, 2022-02-07 at 16:38 -0500, Lyude Paul wrote:
> As we've unfortunately started to come to expect from PSR on Intel
> platforms, PSR2 selective fetch is not at all ready to be enabled on
> Tigerlake as it results in severe flickering issues - at least on this
> ThinkPad X1 Carbon 9th generation. The easiest way I've found of
> reproducing these issues is to just move the cursor around the left border
> of the screen (suspicious…).
Where is the bug for that? Where is the logs?
We can't go from enabled to disabled without any debug and because of a single
device.
In the mean time you have the option to set the i915 parameter to disable it.
>
> So, fix people's displays again and turn PSR2 selective fetch off for all
> steppings of Tigerlake. This can be re-enabled again if someone from Intel
> finds the time to fix this functionality on OEM machines.
>
> Signed-off-by: Lyude Paul
> Fixes: 7f6002e58025 ("drm/i915/display: Enable PSR2 selective fetch by
> default")
> Cc: Gwan-gyeong Mun
> Cc: Ville Syrjälä
> Cc: José Roberto de Souza
> Cc: Jani Nikula
> Cc: Rodrigo Vivi
> Cc: intel-...@lists.freedesktop.org
> Cc: # v5.16+
> ---
> drivers/gpu/drm/i915/display/intel_psr.c | 10 +++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index a1a663f362e7..25c16abcd9cd 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -737,10 +737,14 @@ static bool intel_psr2_sel_fetch_config_valid(struct
> intel_dp *intel_dp,
> return false;
> }
>
> - /* Wa_14010254185 Wa_14010103792 */
> - if (IS_TGL_DISPLAY_STEP(dev_priv, STEP_A0, STEP_C0)) {
> + /*
> + * There's two things stopping this from being enabled on TGL:
> + * For steps A0-C0: workarounds Wa_14010254185 Wa_14010103792 are
> missing
> + * For all steps: PSR2 selective fetch causes screen flickering
> + */
> + if (IS_TIGERLAKE(dev_priv)) {
> drm_dbg_kms(&dev_priv->drm,
> - "PSR2 sel fetch not enabled, missing the
> implementation of WAs\n");
> + "PSR2 sel fetch not enabled, currently broken on
> TGL\n");
> return false;
> }
>
Re: [Intel-gfx] [PATCH v3 3/3] drm/i915: Do not spam log with missing arch support
On Mon, 2022-01-31 at 08:59 -0800, Lucas De Marchi wrote:
> Following what was done in drm_cache.c, when the stub for
> remap_io_mapping() was added in commit 67c430bbaae1 ("drm/i915: Skip
> remap_io_mapping() for non-x86 platforms"), it included a log message
> with pr_err(). However just the warning is already enough and switching
> to WARN_ONCE() allows us to keep the log message while avoiding log
> spam.
Reviewed-by: José Roberto de Souza
But same suggestion as the first patch in this series about drm_WARN_ONCE().
>
> Signed-off-by: Lucas De Marchi
> ---
>
> v3: No changes from previous version, just submitting to the right
> mailing list
>
> drivers/gpu/drm/i915/i915_mm.h | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_mm.h b/drivers/gpu/drm/i915/i915_mm.h
> index 3ad22bbe80eb..04c8974d822b 100644
> --- a/drivers/gpu/drm/i915/i915_mm.h
> +++ b/drivers/gpu/drm/i915/i915_mm.h
> @@ -23,8 +23,7 @@ int remap_io_mapping(struct vm_area_struct *vma,
>unsigned long addr, unsigned long pfn, unsigned long size,
>struct io_mapping *iomap)
> {
> - pr_err("Architecture has no %s() and shouldn't be calling this
> function\n", __func__);
> - WARN_ON_ONCE(1);
> + WARN_ONCE(1, "Architecture has no drm_cache.c support\n");
> return 0;
> }
> #endif
Re: [PATCH v3 1/3] drm: Stop spamming log with drm_cache message
On Mon, 2022-01-31 at 08:59 -0800, Lucas De Marchi wrote:
> Only x86 and in some cases PPC have support added in drm_cache.c for the
> clflush class of functions. However warning once is sufficient to taint
> the log instead of spamming it with "Architecture has no drm_cache.c
> support" every few millisecond. Switch to WARN_ONCE() so we still get
> the log message, but only once, together with the warning. E.g:
>
> [ cut here ]
> Architecture has no drm_cache.c support
> WARNING: CPU: 80 PID: 888 at drivers/gpu/drm/drm_cache.c:139
> drm_clflush_sg+0x40/0x50 [drm]
> ...
>
> v2 (Jani): use WARN_ONCE() and keep the message previously on pr_err()
Reviewed-by: José Roberto de Souza
But while at it, why not add a drm_device parameter to this function so we can
use drm_WARN_ONCE()?
Anyways, it is better than before.
>
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Thomas Zimmermann
> Cc: David Airlie
> Cc: Daniel Vetter
> Signed-off-by: Lucas De Marchi
> ---
>
> v3: No changes from previous version, just submitting to the right
> mailing list
>
> drivers/gpu/drm/drm_cache.c | 9 +++--
> 1 file changed, 3 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_cache.c b/drivers/gpu/drm/drm_cache.c
> index f19d9acbe959..2c3fa5677f7e 100644
> --- a/drivers/gpu/drm/drm_cache.c
> +++ b/drivers/gpu/drm/drm_cache.c
> @@ -112,8 +112,7 @@ drm_clflush_pages(struct page *pages[], unsigned long
> num_pages)
> kunmap_atomic(page_virtual);
> }
> #else
> - pr_err("Architecture has no drm_cache.c support\n");
> - WARN_ON_ONCE(1);
> + WARN_ONCE(1, "Architecture has no drm_cache.c support\n");
> #endif
> }
> EXPORT_SYMBOL(drm_clflush_pages);
> @@ -143,8 +142,7 @@ drm_clflush_sg(struct sg_table *st)
> if (wbinvd_on_all_cpus())
> pr_err("Timed out waiting for cache flush\n");
> #else
> - pr_err("Architecture has no drm_cache.c support\n");
> - WARN_ON_ONCE(1);
> + WARN_ONCE(1, "Architecture has no drm_cache.c support\n");
> #endif
> }
> EXPORT_SYMBOL(drm_clflush_sg);
> @@ -177,8 +175,7 @@ drm_clflush_virt_range(void *addr, unsigned long length)
> if (wbinvd_on_all_cpus())
> pr_err("Timed out waiting for cache flush\n");
> #else
> - pr_err("Architecture has no drm_cache.c support\n");
> - WARN_ON_ONCE(1);
> + WARN_ONCE(1, "Architecture has no drm_cache.c support\n");
> #endif
> }
> EXPORT_SYMBOL(drm_clflush_virt_range);
Re: [PATCH v3 2/3] drm/i915: Fix header test for !CONFIG_X86
On Mon, 2022-01-31 at 08:59 -0800, Lucas De Marchi wrote:
> Architectures others than x86 have a stub implementation calling
> WARN_ON_ONCE(). The appropriate headers need to be included, otherwise
> the header-test target will fail with:
>
> HDRTEST drivers/gpu/drm/i915/i915_mm.h
> In file included from :
> ./drivers/gpu/drm/i915/i915_mm.h: In function ‘remap_io_mapping’:
> ./drivers/gpu/drm/i915/i915_mm.h:26:2: error: implicit declaration of
> function ‘WARN_ON_ONCE’ [-Werror=implicit-function-declaration]
>26 | WARN_ON_ONCE(1);
> | ^~~~
>
> v2: Do not include since call to pr_err() has been
> removed
Reviewed-by: José Roberto de Souza
>
> Fixes: 67c430bbaae1 ("drm/i915: Skip remap_io_mapping() for non-x86
> platforms")
> Cc: Siva Mullati
> Signed-off-by: Lucas De Marchi
> ---
>
> v3: No changes from previous version, just submitting to the right
> mailing list
>
> drivers/gpu/drm/i915/i915_mm.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_mm.h b/drivers/gpu/drm/i915/i915_mm.h
> index 76f1d53bdf34..3ad22bbe80eb 100644
> --- a/drivers/gpu/drm/i915/i915_mm.h
> +++ b/drivers/gpu/drm/i915/i915_mm.h
> @@ -6,6 +6,7 @@
> #ifndef __I915_MM_H__
> #define __I915_MM_H__
>
> +#include
> #include
>
> struct vm_area_struct;
Re: [PATCH v3 3/5] drm/i915/panelreplay: Initializaton and compute config for panel replay
On Tue, 2022-01-04 at 21:21 +0530, Manna, Animesh wrote:
> Hi,
>
> > -Original Message-
> > From: Souza, Jose
> > Sent: Wednesday, November 24, 2021 1:19 AM
> > To: dri-devel@lists.freedesktop.org; Manna, Animesh
> > ; intel-...@lists.freedesktop.org
> > Cc: Mun, Gwan-gyeong ; Nikula, Jani
> > ; Kahola, Mika ; Navare,
> > Manasi D
> > Subject: Re: [PATCH v3 3/5] drm/i915/panelreplay: Initializaton and compute
> > config for panel replay
> >
> > On Sun, 2021-10-10 at 17:40 +0530, Animesh Manna wrote:
> > > As panel replay feature similar to PSR feature of EDP panel, so
> > > currently utilized existing psr framework for panel replay.
> > >
> > > v1: RFC version.
> > > v2: optimized code, pr_enabled and pr_dpcd variable removed. [Jose]
> > > v3:
> > > - code comments improved. [Jani]
> > > - dpcd_readb used instead of dpcd_read. [Jani]
> > > - panel-repaplay init/compute functions moved inside respective psr
> > > function. [Jani]
> > >
> > > Signed-off-by: Animesh Manna
> > > ---
> > > .../drm/i915/display/intel_display_types.h| 2 +
> > > drivers/gpu/drm/i915/display/intel_dp.c | 43 +
> > > drivers/gpu/drm/i915/display/intel_psr.c | 48 +++
> > > drivers/gpu/drm/i915/display/intel_psr.h | 3 ++
> > > 4 files changed, 87 insertions(+), 9 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> > > b/drivers/gpu/drm/i915/display/intel_display_types.h
> > > index 39e11eaec1a3..48f7d676ed2c 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> > > +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> > > @@ -1070,6 +1070,7 @@ struct intel_crtc_state {
> > > bool req_psr2_sdp_prior_scanline;
> > > u32 dc3co_exitline;
> > > u16 su_y_granularity;
> > > + bool has_panel_replay;
> >
> > We can drop this and reuse current ones ones, see bellow.
> >
> > > struct drm_dp_vsc_sdp psr_vsc;
> > >
> > > /*
> > > @@ -1531,6 +1532,7 @@ struct intel_psr {
> > > bool irq_aux_error;
> > > u16 su_w_granularity;
> > > u16 su_y_granularity;
> > > + bool sink_panel_replay_support;
> >
> > move this closer to has_psr and set both when it is panel replay.
> > otherwise psr functions will not be executed for panel replay, see
> > CAN_PSR().
>
> AFIU Panel replay do not have any dependency with PSR.
> So that’s why I have created separate function for panel replay which is
> doing similar thing whatever needed for panel replay.
> For example intel_panel_replay_compute_config() can be independent of
> intel_psr_compute_config().
> Do you see any dependency with PSR for panel replay?
There is no dependency but panel replay is PSR for DP so we should re-use PSR
code as much as possible.
eDP + sink_support = PSR
DP + sink_support = panel replay
So we can reuse has_psr and all other stuff.
>
> >
> > > u32 dc3co_exitline;
> > > u32 dc3co_exit_delay;
> > > struct delayed_work dc3co_work;
> > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > > b/drivers/gpu/drm/i915/display/intel_dp.c
> > > index 10fda20a5bd8..f58a7b72be14 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > > @@ -1587,12 +1587,22 @@ static void
> > intel_dp_compute_vsc_colorimetry(const struct intel_crtc_state *crtc
> > > struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> > > struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> > >
> > > - /*
> > > - * Prepare VSC Header for SU as per DP 1.4 spec, Table 2-118
> > > - * VSC SDP supporting 3D stereo, PSR2, and Pixel Encoding/
> > > - * Colorimetry Format indication.
> > > - */
> > > - vsc->revision = 0x5;
> > > + if (crtc_state->has_panel_replay) {
> > > + /*
> > > + * Prepare VSC Header for SU as per DP 2.0 spec, Table 2-223
> > > + * VSC SDP supporting 3D stereo, Panel Replay, and Pixel
> > > + * Encoding/Colorimetry Format indication.
> > > + */
> > > + vsc->revision = 0x7;
> > > + } else {
> > > + /*
> > > + * Prepare VSC Header for SU as per DP 1.4 spec, Table 2-118
> > > + * VSC SDP supporting 3D stereo, PSR2, and Pi
Re: [Intel-gfx] [PATCH] drm/i915: replace X86_FEATURE_PAT with pat_enabled()
On Wed, 2021-12-01 at 16:30 -0800, Lucas De Marchi wrote: > PAT can be disabled on boot with "nopat" in the command line. Replace > one x86-ism with another, which is slightly more correct to prepare for > supporting other architectures. Reviewed-by: José Roberto de Souza > > Cc: Matt Roper > Signed-off-by: Lucas De Marchi > --- > drivers/gpu/drm/i915/gem/i915_gem_mman.c | 8 > drivers/gpu/drm/i915/gem/i915_gem_pages.c | 3 +-- > 2 files changed, 5 insertions(+), 6 deletions(-) > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c > b/drivers/gpu/drm/i915/gem/i915_gem_mman.c > index 65fc6ff5f59d..c0c509e5c0ae 100644 > --- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c > +++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c > @@ -72,7 +72,7 @@ i915_gem_mmap_ioctl(struct drm_device *dev, void *data, > if (args->flags & ~(I915_MMAP_WC)) > return -EINVAL; > > - if (args->flags & I915_MMAP_WC && !boot_cpu_has(X86_FEATURE_PAT)) > + if (args->flags & I915_MMAP_WC && !pat_enabled()) > return -ENODEV; > > obj = i915_gem_object_lookup(file, args->handle); > @@ -736,7 +736,7 @@ i915_gem_dumb_mmap_offset(struct drm_file *file, > > if (HAS_LMEM(to_i915(dev))) > mmap_type = I915_MMAP_TYPE_FIXED; > - else if (boot_cpu_has(X86_FEATURE_PAT)) > + else if (pat_enabled()) > mmap_type = I915_MMAP_TYPE_WC; > else if (!i915_ggtt_has_aperture(&to_i915(dev)->ggtt)) > return -ENODEV; > @@ -792,7 +792,7 @@ i915_gem_mmap_offset_ioctl(struct drm_device *dev, void > *data, > break; > > case I915_MMAP_OFFSET_WC: > - if (!boot_cpu_has(X86_FEATURE_PAT)) > + if (!pat_enabled()) > return -ENODEV; > type = I915_MMAP_TYPE_WC; > break; > @@ -802,7 +802,7 @@ i915_gem_mmap_offset_ioctl(struct drm_device *dev, void > *data, > break; > > case I915_MMAP_OFFSET_UC: > - if (!boot_cpu_has(X86_FEATURE_PAT)) > + if (!pat_enabled()) > return -ENODEV; > type = I915_MMAP_TYPE_UC; > break; > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c > b/drivers/gpu/drm/i915/gem/i915_gem_pages.c > index 49c6e55c68ce..89b70f5cde7a 100644 > --- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c > +++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c > @@ -424,8 +424,7 @@ void *i915_gem_object_pin_map(struct drm_i915_gem_object > *obj, > goto err_unpin; > } > > - if (GEM_WARN_ON(type == I915_MAP_WC && > - !static_cpu_has(X86_FEATURE_PAT))) > + if (GEM_WARN_ON(type == I915_MAP_WC && !pat_enabled())) > ptr = ERR_PTR(-ENODEV); > else if (i915_gem_object_has_struct_page(obj)) > ptr = i915_gem_object_map_page(obj, type);
Re: [PATCH v3 3/5] drm/i915/panelreplay: Initializaton and compute config for panel replay
On Sun, 2021-10-10 at 17:40 +0530, Animesh Manna wrote:
> As panel replay feature similar to PSR feature of EDP panel, so currently
> utilized existing psr framework for panel replay.
>
> v1: RFC version.
> v2: optimized code, pr_enabled and pr_dpcd variable removed. [Jose]
> v3:
> - code comments improved. [Jani]
> - dpcd_readb used instead of dpcd_read. [Jani]
> - panel-repaplay init/compute functions moved inside respective psr
> function. [Jani]
>
> Signed-off-by: Animesh Manna
> ---
> .../drm/i915/display/intel_display_types.h| 2 +
> drivers/gpu/drm/i915/display/intel_dp.c | 43 +
> drivers/gpu/drm/i915/display/intel_psr.c | 48 +++
> drivers/gpu/drm/i915/display/intel_psr.h | 3 ++
> 4 files changed, 87 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 39e11eaec1a3..48f7d676ed2c 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -1070,6 +1070,7 @@ struct intel_crtc_state {
> bool req_psr2_sdp_prior_scanline;
> u32 dc3co_exitline;
> u16 su_y_granularity;
> + bool has_panel_replay;
We can drop this and reuse current ones ones, see bellow.
> struct drm_dp_vsc_sdp psr_vsc;
>
> /*
> @@ -1531,6 +1532,7 @@ struct intel_psr {
> bool irq_aux_error;
> u16 su_w_granularity;
> u16 su_y_granularity;
> + bool sink_panel_replay_support;
move this closer to has_psr and set both when it is panel replay.
otherwise psr functions will not be executed for panel replay, see CAN_PSR().
> u32 dc3co_exitline;
> u32 dc3co_exit_delay;
> struct delayed_work dc3co_work;
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 10fda20a5bd8..f58a7b72be14 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -1587,12 +1587,22 @@ static void intel_dp_compute_vsc_colorimetry(const
> struct intel_crtc_state *crtc
> struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
>
> - /*
> - * Prepare VSC Header for SU as per DP 1.4 spec, Table 2-118
> - * VSC SDP supporting 3D stereo, PSR2, and Pixel Encoding/
> - * Colorimetry Format indication.
> - */
> - vsc->revision = 0x5;
> + if (crtc_state->has_panel_replay) {
> + /*
> + * Prepare VSC Header for SU as per DP 2.0 spec, Table 2-223
> + * VSC SDP supporting 3D stereo, Panel Replay, and Pixel
> + * Encoding/Colorimetry Format indication.
> + */
> + vsc->revision = 0x7;
> + } else {
> + /*
> + * Prepare VSC Header for SU as per DP 1.4 spec, Table 2-118
> + * VSC SDP supporting 3D stereo, PSR2, and Pixel Encoding/
> + * Colorimetry Format indication.
> + */
> + vsc->revision = 0x5;
> + }
> +
> vsc->length = 0x13;
>
> /* DP 1.4a spec, Table 2-120 */
> @@ -1701,6 +1711,21 @@ void intel_dp_compute_psr_vsc_sdp(struct intel_dp
> *intel_dp,
> vsc->revision = 0x4;
> vsc->length = 0xe;
> }
> + } else if (intel_dp->psr.enabled && !intel_dp_is_edp(intel_dp)) {
> + if (intel_dp->psr.colorimetry_support &&
> + intel_dp_needs_vsc_sdp(crtc_state, conn_state)) {
> + /* [Panel Replay with colorimetry info] */
> + intel_dp_compute_vsc_colorimetry(crtc_state, conn_state,
> + vsc);
> + } else {
> + /*
> + * [Panel Replay without colorimetry info]
> + * Prepare VSC Header for SU as per DP 2.0 spec, Table
> 2-223
> + * VSC SDP supporting 3D stereo + Panel Replay.
> + */
> + vsc->revision = 0x6;
> + vsc->length = 0x10;
> + }
> } else {
> /*
>* [PSR1]
> @@ -2749,10 +2774,10 @@ static ssize_t intel_dp_vsc_sdp_pack(const struct
> drm_dp_vsc_sdp *vsc,
> sdp->sdp_header.HB3 = vsc->length; /* Number of Valid Data Bytes */
>
> /*
> - * Only revision 0x5 supports Pixel Encoding/Colorimetry Format as
> - * per DP 1.4a spec.
> + * Revision 0x5 and 0x7 supports Pixel Encoding/Colorimetry Format as
> + * per DP 1.4a spec and DP 2.0 spec respectively.
>*/
> - if (vsc->revision != 0x5)
> + if (vsc->revision != 0x5 || vsc->revision != 0x7)
> goto out;
>
> /* VSC SDP Payload for DB16 through DB18 */
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> b/dr
Re: [PATCH v3 1/5] drm/i915/panelreplay: dpcd register definition for panelreplay
On Sun, 2021-10-10 at 17:40 +0530, Animesh Manna wrote: > DPCD register definition added to check and enable panel replay > capability of the sink. > > Signed-off-by: Animesh Manna > --- > include/drm/drm_dp_helper.h | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h > index b52df4db3e8f..8a2b929c3f88 100644 > --- a/include/drm/drm_dp_helper.h > +++ b/include/drm/drm_dp_helper.h > @@ -541,6 +541,9 @@ struct drm_panel; > /* DFP Capability Extension */ > #define DP_DFP_CAPABILITY_EXTENSION_SUPPORT 0x0a3 /* 2.0 */ > > +#define DP_PANEL_REPLAY_CAP 0x0b0 > +# define PANEL_REPLAY_SUPPORT (1 << 0) Missing bit 1, that is very important when panel do not support selective update panel replay needs to act like PSR1 when it is sets it needs to act like PSR2. > + > /* Link Configuration */ > #define DP_LINK_BW_SET 0x100 > # define DP_LINK_RATE_TABLE 0x00/* eDP 1.4 */ > @@ -709,6 +712,9 @@ struct drm_panel; > #define DP_BRANCH_DEVICE_CTRL0x1a1 > # define DP_BRANCH_DEVICE_IRQ_HPD(1 << 0) > > +#define PANEL_REPLAY_CONFIG 0x1b0 > +# define PANEL_REPLAY_ENABLE(1 << 0) All other bits are also important, for the errors ones we have PSR counter parts and your are missing the error status register. > + > #define DP_PAYLOAD_ALLOCATE_SET 0x1c0 > #define DP_PAYLOAD_ALLOCATE_START_TIME_SLOT 0x1c1 > #define DP_PAYLOAD_ALLOCATE_TIME_SLOT_COUNT 0x1c2
Re: [PATCH v3 5/5] drm/i915/dg2: extend Wa_1409120013 to DG2
On Tue, 2021-11-16 at 09:48 -0800, Matt Roper wrote:
> From: Matt Atwood
>
> Extend existing workaround 1409120013 to DG2.
>
> Cc: José Roberto de Souza
> Signed-off-by: Matt Atwood
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/intel_pm.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 89dc7f69baf3..e721c421cc58 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -7444,9 +7444,9 @@ static void icl_init_clock_gating(struct
> drm_i915_private *dev_priv)
>
> static void gen12lp_init_clock_gating(struct drm_i915_private *dev_priv)
> {
> - /* Wa_1409120013:tgl,rkl,adl-s,dg1 */
> + /* Wa_1409120013:tgl,rkl,adl-s,dg1,dg2 */
I'm not finding this workaround in the DG2 WA spec page, maybe it was removed
because it is not necessary anymore?
> if (IS_TIGERLAKE(dev_priv) || IS_ROCKETLAKE(dev_priv) ||
> - IS_ALDERLAKE_S(dev_priv) || IS_DG1(dev_priv))
> + IS_ALDERLAKE_S(dev_priv) || IS_DG1(dev_priv) || IS_DG2(dev_priv))
> intel_uncore_write(&dev_priv->uncore, ILK_DPFC_CHICKEN,
> DPFC_CHICKEN_COMP_DUMMY_PIXEL);
>
Re: [PATCH v3] drm/i915/bdb: Fix version check
On Thu, 2021-09-30 at 15:46 +0200, Lukasz Majczak wrote:
> With patch "drm/i915/vbt: Fix backlight parsing for VBT 234+"
> the size of bdb_lfp_backlight_data structure has been increased,
> causing if-statement in the parse_lfp_backlight function
> that comapres this structure size to the one retrieved from BDB,
> always to fail for older revisions.
> This patch calculates expected size of the structure for a given
> BDB version and compares it with the value gathered from BDB.
> Tested on Chromebook Pixelbook (Nocturne) (reports bdb->version = 221)
Reviewed-by: José Roberto de Souza
>
> Tested-by: Lukasz Majczak
> Signed-off-by: Lukasz Majczak
> ---
> drivers/gpu/drm/i915/display/intel_bios.c | 22 ++-
> drivers/gpu/drm/i915/display/intel_vbt_defs.h | 5 +
> 2 files changed, 21 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
> b/drivers/gpu/drm/i915/display/intel_bios.c
> index 3c25926092de..f9776ca85de3 100644
> --- a/drivers/gpu/drm/i915/display/intel_bios.c
> +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> @@ -451,13 +451,23 @@ parse_lfp_backlight(struct drm_i915_private *i915,
> }
>
> i915->vbt.backlight.type = INTEL_BACKLIGHT_DISPLAY_DDI;
> - if (bdb->version >= 191 &&
> - get_blocksize(backlight_data) >= sizeof(*backlight_data)) {
> - const struct lfp_backlight_control_method *method;
> + if (bdb->version >= 191) {
> + size_t exp_size;
>
> - method = &backlight_data->backlight_control[panel_type];
> - i915->vbt.backlight.type = method->type;
> - i915->vbt.backlight.controller = method->controller;
> + if (bdb->version >= 236)
> + exp_size = sizeof(struct bdb_lfp_backlight_data);
> + else if (bdb->version >= 234)
> + exp_size = EXP_BDB_LFP_BL_DATA_SIZE_REV_234;
> + else
> + exp_size = EXP_BDB_LFP_BL_DATA_SIZE_REV_191;
> +
> + if (get_blocksize(backlight_data) >= exp_size) {
> + const struct lfp_backlight_control_method *method;
> +
> + method = &backlight_data->backlight_control[panel_type];
> + i915->vbt.backlight.type = method->type;
> + i915->vbt.backlight.controller = method->controller;
> + }
> }
>
> i915->vbt.backlight.pwm_freq_hz = entry->pwm_freq_hz;
> diff --git a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> index 330077c2e588..a2108a8f544d 100644
> --- a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> +++ b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> @@ -814,6 +814,11 @@ struct lfp_brightness_level {
> u16 reserved;
> } __packed;
>
> +#define EXP_BDB_LFP_BL_DATA_SIZE_REV_191 \
> + offsetof(struct bdb_lfp_backlight_data, brightness_level)
> +#define EXP_BDB_LFP_BL_DATA_SIZE_REV_234 \
> + offsetof(struct bdb_lfp_backlight_data, brightness_precision_bits)
> +
> struct bdb_lfp_backlight_data {
> u8 entry_size;
> struct lfp_backlight_data_entry data[16];
Re: [PATCH v2] drm/i915/bdb: Fix version check
On Thu, 2021-09-23 at 18:49 +0200, Lukasz Majczak wrote:
> With patch "drm/i915/vbt: Fix backlight parsing for VBT 234+"
> the size of bdb_lfp_backlight_data structure has been increased,
> causing if-statement in the parse_lfp_backlight function
> that comapres this structure size to the one retrieved from BDB,
> always to fail for older revisions.
> This patch calculates expected size of the structure for a given
> BDB version and compares it with the value gathered from BDB.
> Tested on Chromebook Pixelbook (Nocturne) (reports bdb->version = 221)
Fixes: d381baad29b4 ("drm/i915/vbt: Fix backlight parsing for VBT 234+")
>
> Tested-by: Lukasz Majczak
> Signed-off-by: Lukasz Majczak
> ---
> drivers/gpu/drm/i915/display/intel_bios.c | 11 +--
> drivers/gpu/drm/i915/display/intel_vbt_defs.h | 5 +
> 2 files changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
> b/drivers/gpu/drm/i915/display/intel_bios.c
> index 3c25926092de..90eae6da12e0 100644
> --- a/drivers/gpu/drm/i915/display/intel_bios.c
> +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> @@ -428,6 +428,7 @@ parse_lfp_backlight(struct drm_i915_private *i915,
> const struct lfp_backlight_data_entry *entry;
> int panel_type = i915->vbt.panel_type;
> u16 level;
> + size_t exp_size;
>
> backlight_data = find_section(bdb, BDB_LVDS_BACKLIGHT);
> if (!backlight_data)
> @@ -450,9 +451,15 @@ parse_lfp_backlight(struct drm_i915_private *i915,
> return;
> }
>
> + if (bdb->version <= 234)
> + exp_size = EXP_BDB_LFP_BL_DATA_SIZE_REV_234;
> + else if (bdb->version > 234 && bdb->version <= 236)
> + exp_size = EXP_BDB_LFP_BL_DATA_SIZE_REV_236;
> + else
> + exp_size = sizeof(struct bdb_lfp_backlight_data);
Usually we go by the newest(IP version, platform...) to the oldest:
if (bdb->version >= 236)
exp_size = sizeof(struct bdb_lfp_backlight_data);
else if (bdb->version >= 234)
exp_size = offsetof(struct bdb_lfp_backlight_data,
brightness_precision_bits);
else
exp_size = offsetof(struct bdb_lfp_backlight_data, brightness_level);
backlight_control was added in version 191 so no need to set exp_size for older
versions.
> +
> i915->vbt.backlight.type = INTEL_BACKLIGHT_DISPLAY_DDI;
> - if (bdb->version >= 191 &&
> - get_blocksize(backlight_data) >= sizeof(*backlight_data)) {
> + if (bdb->version >= 191 && get_blocksize(backlight_data) >= exp_size) {
> const struct lfp_backlight_control_method *method;
>
> method = &backlight_data->backlight_control[panel_type];
> diff --git a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> index 330077c2e588..ba9990e5983c 100644
> --- a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> +++ b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> @@ -814,6 +814,11 @@ struct lfp_brightness_level {
> u16 reserved;
> } __packed;
>
> +#define EXP_BDB_LFP_BL_DATA_SIZE_REV_234 \
> + offsetof(struct bdb_lfp_backlight_data, brightness_level)
version 234 starts at brightness_level but the size of 234 data must be
included to the size, so it should be:
offsetof(struct bdb_lfp_backlight_data, brightness_precision_bits).
> +#define EXP_BDB_LFP_BL_DATA_SIZE_REV_236 \
> + offsetof(struct bdb_lfp_backlight_data, brightness_precision_bits)
> +
> struct bdb_lfp_backlight_data {
> u8 entry_size;
> struct lfp_backlight_data_entry data[16];
Re: [PATCH v1] drm/i915/bdb: Fix version check
On Mon, 2021-09-20 at 16:11 +0200, Lukasz Majczak wrote:
> With patch "drm/i915/vbt: Fix backlight parsing for VBT 234+"
> the size of bdb_lfp_backlight_data structure has been increased,
> causing if-statement in the parse_lfp_backlight function
> that comapres this structure size to the one retrieved from BDB,
> always to fail for older revisions.
> This patch fixes it by comparing a total size of all fileds from
> the structure (present before the change) with the value gathered from BDB.
> Tested on Chromebook Pixelbook (Nocturne) (reports bdb->version = 221)
>
> Cc: # 5.4+
> Tested-by: Lukasz Majczak
> Signed-off-by: Lukasz Majczak
> ---
> drivers/gpu/drm/i915/display/intel_bios.c | 4 +++-
> drivers/gpu/drm/i915/display/intel_vbt_defs.h | 5 +
> 2 files changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
> b/drivers/gpu/drm/i915/display/intel_bios.c
> index 3c25926092de..052a19b455d1 100644
> --- a/drivers/gpu/drm/i915/display/intel_bios.c
> +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> @@ -452,7 +452,9 @@ parse_lfp_backlight(struct drm_i915_private *i915,
>
> i915->vbt.backlight.type = INTEL_BACKLIGHT_DISPLAY_DDI;
> if (bdb->version >= 191 &&
> - get_blocksize(backlight_data) >= sizeof(*backlight_data)) {
> + get_blocksize(backlight_data) >=
> (sizeof(backlight_data->entry_size) +
> + sizeof(backlight_data->data) +
> + sizeof(backlight_data->level))) {
Missing sizeof(backlight_data->backlight_control) but this is getting very
verbose.
Would be better have a expected size variable set each version set in the
beginning of this function.
something like:
switch (bdb->version) {
case 191:
expected_size = x;
break;
case 234:
expected_size = x;
break;
case 236:
default:
expected_size = x;
}
> const struct lfp_backlight_control_method *method;
>
> method = &backlight_data->backlight_control[panel_type];
> diff --git a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> index 330077c2e588..fff456bf8783 100644
> --- a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> +++ b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> @@ -814,6 +814,11 @@ struct lfp_brightness_level {
> u16 reserved;
> } __packed;
>
> +/*
> + * Changing struct bdb_lfp_backlight_data might affect its
> + * size comparation to the value hold in BDB.
> + * (e.g. in parse_lfp_backlight())
> + */
This is true for all the blocks so I don't think we need this comment.
> struct bdb_lfp_backlight_data {
> u8 entry_size;
> struct lfp_backlight_data_entry data[16];
Re: [Intel-gfx] [PATCH] drm/damage_helper: Fix handling of cursor dirty buffers
On Wed, 2021-08-18 at 11:54 +0200, Daniel Vetter wrote:
> On Tue, Aug 17, 2021 at 04:26:04PM -0700, José Roberto de Souza wrote:
> > Cursors don't have a framebuffer so the fb comparisson was always
> > failing and atomic state was being committed without any plane state.
> >
> > So here checking if objects match when checking cursors.
>
> This looks extremely backwards ... what exactly is this fixing? If this
> isn't based on a real world compositor usage but some igt, then I'd say
> the igt here is very wrong.
Yes it is IGT.
Writing to cursor buffer current in the screen and calling drmModeDirtyFB()
causes a empty atomic commit by drm_atomic_helper_dirtyfb().
> -Daniel
>
> > Fixes: b9fc5e01d1ce ("drm: Add helper to implement legacy dirtyfb")
> > Cc: Daniel Vetter
> > Cc: Rob Clark
> > Cc: Deepak Rawat
> > Cc: Gwan-gyeong Mun
> > Signed-off-by: José Roberto de Souza
> > ---
> > drivers/gpu/drm/drm_damage_helper.c | 8 +++-
> > 1 file changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_damage_helper.c
> > b/drivers/gpu/drm/drm_damage_helper.c
> > index 8eeff0c7bdd47..595187d97c131 100644
> > --- a/drivers/gpu/drm/drm_damage_helper.c
> > +++ b/drivers/gpu/drm/drm_damage_helper.c
> > @@ -157,12 +157,18 @@ int drm_atomic_helper_dirtyfb(struct drm_framebuffer
> > *fb,
> > retry:
> > drm_for_each_plane(plane, fb->dev) {
> > struct drm_plane_state *plane_state;
> > + bool match;
> >
> > ret = drm_modeset_lock(&plane->mutex, state->acquire_ctx);
> > if (ret)
> > goto out;
> >
> > - if (plane->state->fb != fb) {
> > + match = plane->state->fb == fb;
> > + /* Check if objs match to handle dirty buffers of cursors */
> > + if (plane->type == DRM_PLANE_TYPE_CURSOR && plane->state->fb)
> > + match |= fb->obj[0] == plane->state->fb->obj[0];
> > +
> > + if (!match) {
> > drm_modeset_unlock(&plane->mutex);
> > continue;
> > }
> > --
> > 2.32.0
> >
>
Re: [PATCH 1/3] drm/plane: remove drm_helper_get_plane_damage_clips
On Wed, 2021-07-21 at 15:30 +0200, Daniel Vetter wrote:
> It's not used. Drivers should instead use the helpers anyway.
>
> Currently both vbox and i915 hand-roll this and it's not the greatest.
> vbox looks buggy, and i915 does a bit much that helpers would take
> care of I think.
>
> Also improve the kerneldocs while we're at it.
Reviewed-by: José Roberto de Souza
>
> Cc: Ville Syrjälä
> Cc: Gwan-gyeong Mun
> Cc: José Roberto de Souza
> Cc: Hans de Goede
> Signed-off-by: Daniel Vetter
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Thomas Zimmermann
> Cc: David Airlie
> Cc: Daniel Vetter
> ---
> drivers/gpu/drm/drm_damage_helper.c | 2 +-
> include/drm/drm_damage_helper.h | 17 -
> include/drm/drm_plane.h | 10 +++---
> include/drm/drm_rect.h | 3 +++
> 4 files changed, 11 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_damage_helper.c
> b/drivers/gpu/drm/drm_damage_helper.c
> index 3a4126dc2520..eb69b7123af5 100644
> --- a/drivers/gpu/drm/drm_damage_helper.c
> +++ b/drivers/gpu/drm/drm_damage_helper.c
> @@ -282,7 +282,7 @@ drm_atomic_helper_damage_iter_init(struct
> drm_atomic_helper_damage_iter *iter,
> if (!state || !state->crtc || !state->fb || !state->visible)
> return;
>
> - iter->clips = drm_helper_get_plane_damage_clips(state);
> + iter->clips = (struct drm_rect *)drm_plane_get_damage_clips(state);
> iter->num_clips = drm_plane_get_damage_clips_count(state);
>
> /* Round down for x1/y1 and round up for x2/y2 to catch all pixels */
> diff --git a/include/drm/drm_damage_helper.h b/include/drm/drm_damage_helper.h
> index 40c34a5bf149..1ae8bce6a5ce 100644
> --- a/include/drm/drm_damage_helper.h
> +++ b/include/drm/drm_damage_helper.h
> @@ -82,21 +82,4 @@ bool drm_atomic_helper_damage_merged(const struct
> drm_plane_state *old_state,
>struct drm_plane_state *state,
>struct drm_rect *rect);
>
> -/**
> - * drm_helper_get_plane_damage_clips - Returns damage clips in &drm_rect.
> - * @state: Plane state.
> - *
> - * Returns plane damage rectangles in internal &drm_rect. Currently &drm_rect
> - * can be obtained by simply typecasting &drm_mode_rect. This is because both
> - * are signed 32 and during drm_atomic_check_only() it is verified that
> damage
> - * clips are inside fb.
> - *
> - * Return: Clips in plane fb_damage_clips blob property.
> - */
> -static inline struct drm_rect *
> -drm_helper_get_plane_damage_clips(const struct drm_plane_state *state)
> -{
> - return (struct drm_rect *)drm_plane_get_damage_clips(state);
> -}
> -
> #endif
> diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
> index 1294610e84f4..7f7d5148310c 100644
> --- a/include/drm/drm_plane.h
> +++ b/include/drm/drm_plane.h
> @@ -186,6 +186,9 @@ struct drm_plane_state {
>* since last plane update) as an array of &drm_mode_rect in framebuffer
>* coodinates of the attached framebuffer. Note that unlike plane src,
>* damage clips are not in 16.16 fixed point.
> + *
> + * See drm_plane_get_damage_clips() and
> + * drm_plane_get_damage_clips_count() for accessing these.
>*/
> struct drm_property_blob *fb_damage_clips;
>
> @@ -914,9 +917,10 @@ drm_plane_get_damage_clips_count(const struct
> drm_plane_state *state)
> * drm_plane_get_damage_clips - Returns damage clips.
> * @state: Plane state.
> *
> - * Note that this function returns uapi type &drm_mode_rect. Drivers might
> - * instead be interested in internal &drm_rect which can be obtained by
> calling
> - * drm_helper_get_plane_damage_clips().
> + * Note that this function returns uapi type &drm_mode_rect. Drivers might
> want
> + * to use the helper functions drm_atomic_helper_damage_iter_init() and
> + * drm_atomic_helper_damage_iter_next() or drm_atomic_helper_damage_merged()
> if
> + * the driver can only handle a single damage region at most.
> *
> * Return: Damage clips in plane fb_damage_clips blob property.
> */
> diff --git a/include/drm/drm_rect.h b/include/drm/drm_rect.h
> index 39f2deee709c..6f6e19bd4dac 100644
> --- a/include/drm/drm_rect.h
> +++ b/include/drm/drm_rect.h
> @@ -39,6 +39,9 @@
> * @x2: horizontal ending coordinate (exclusive)
> * @y1: vertical starting coordinate (inclusive)
> * @y2: vertical ending coordinate (exclusive)
> + *
> + * Note that this must match the layout of struct drm_mode_rect or the damage
> + * helpers like drm_atomic_helper_damage_iter_init() break.
> */
> struct drm_rect {
> int x1, y1, x2, y2;
Re: [PATCH 3/3] drm/plane: Move drm_plane_enable_fb_damage_clips into core
On Wed, 2021-07-21 at 15:30 +0200, Daniel Vetter wrote:
> We're trying to have a fairly strict split between core functionality
> that defines the uapi, including the docs, and the helper functions to
> implement it.
>
> Move drm_plane_enable_fb_damage_clips and associated kerneldoc into
> drm_plane from drm_damage_helper.c to fix this.
Reviewed-by: José Roberto de Souza
>
> Cc: Ville Syrjälä
> Cc: Gwan-gyeong Mun
> Cc: José Roberto de Souza
> Cc: Hans de Goede
> Signed-off-by: Daniel Vetter
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Thomas Zimmermann
> Cc: David Airlie
> Cc: Daniel Vetter
> ---
> Documentation/gpu/drm-kms.rst | 4 +--
> drivers/gpu/drm/drm_damage_helper.c | 54 -
> drivers/gpu/drm/drm_plane.c | 54 +
> include/drm/drm_damage_helper.h | 1 -
> include/drm/drm_plane.h | 3 +-
> 5 files changed, 58 insertions(+), 58 deletions(-)
>
> diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
> index 87e5023e3f55..7399f497e7e2 100644
> --- a/Documentation/gpu/drm-kms.rst
> +++ b/Documentation/gpu/drm-kms.rst
> @@ -508,8 +508,8 @@ Plane Composition Properties
> Damage Tracking Properties
> --
>
> -.. kernel-doc:: drivers/gpu/drm/drm_damage_helper.c
> - :doc: overview
> +.. kernel-doc:: drivers/gpu/drm/drm_plane.c
> + :doc: damage tracking
>
> Color Management Properties
> ---
> diff --git a/drivers/gpu/drm/drm_damage_helper.c
> b/drivers/gpu/drm/drm_damage_helper.c
> index eb69b7123af5..245959dad7bb 100644
> --- a/drivers/gpu/drm/drm_damage_helper.c
> +++ b/drivers/gpu/drm/drm_damage_helper.c
> @@ -34,44 +34,6 @@
> #include
> #include
>
> -/**
> - * DOC: overview
> - *
> - * FB_DAMAGE_CLIPS is an optional plane property which provides a means to
> - * specify a list of damage rectangles on a plane in framebuffer coordinates
> of
> - * the framebuffer attached to the plane. In current context damage is the
> area
> - * of plane framebuffer that has changed since last plane update (also called
> - * page-flip), irrespective of whether currently attached framebuffer is
> same as
> - * framebuffer attached during last plane update or not.
> - *
> - * FB_DAMAGE_CLIPS is a hint to kernel which could be helpful for some
> drivers
> - * to optimize internally especially for virtual devices where each
> framebuffer
> - * change needs to be transmitted over network, usb, etc.
> - *
> - * Since FB_DAMAGE_CLIPS is a hint so it is an optional property. User-space
> can
> - * ignore damage clips property and in that case driver will do a full plane
> - * update. In case damage clips are provided then it is guaranteed that the
> area
> - * inside damage clips will be updated to plane. For efficiency driver can do
> - * full update or can update more than specified in damage clips. Since
> driver
> - * is free to read more, user-space must always render the entire visible
> - * framebuffer. Otherwise there can be corruptions. Also, if a user-space
> - * provides damage clips which doesn't encompass the actual damage to
> - * framebuffer (since last plane update) can result in incorrect rendering.
> - *
> - * FB_DAMAGE_CLIPS is a blob property with the layout of blob data is simply
> an
> - * array of &drm_mode_rect. Unlike plane &drm_plane_state.src coordinates,
> - * damage clips are not in 16.16 fixed point. Similar to plane src in
> - * framebuffer, damage clips cannot be negative. In damage clip, x1/y1 are
> - * inclusive and x2/y2 are exclusive. While kernel does not error for
> overlapped
> - * damage clips, it is strongly discouraged.
> - *
> - * Drivers that are interested in damage interface for plane should enable
> - * FB_DAMAGE_CLIPS property by calling drm_plane_enable_fb_damage_clips().
> - * Drivers implementing damage can use drm_atomic_helper_damage_iter_init()
> and
> - * drm_atomic_helper_damage_iter_next() helper iterator function to get
> damage
> - * rectangles clipped to &drm_plane_state.src.
> - */
> -
> static void convert_clip_rect_to_rect(const struct drm_clip_rect *src,
> struct drm_mode_rect *dest,
> uint32_t num_clips, uint32_t src_inc)
> @@ -87,22 +49,6 @@ static void convert_clip_rect_to_rect(const struct
> drm_clip_rect *src,
> }
> }
>
> -/**
> - * drm_plane_enable_fb_damage_clips - Enables plane fb damage clips property.
> - * @plane: Plane on which to enable damage clips property.
> - *
> - * This function lets driver to enable the damage clips property on a plane.
> - */
> -void drm_plane_enable_fb_damage_clips(struct drm_plane *plane)
> -{
> - struct drm_device *dev = plane->dev;
> - struct drm_mode_config *config = &dev->mode_config;
> -
> - drm_object_attach_property(&plane->base, config->prop_fb_damage_clips,
> -0);
> -}
> -EXPORT_SYMBOL(drm_
Re: [PATCH 2/3] drm/plane: check that fb_damage is set up when used
On Wed, 2021-07-21 at 15:30 +0200, Daniel Vetter wrote:
> There's two stages of manual upload/invalidate displays:
> - just handling dirtyfb and uploading the entire fb all the time
> - looking at damage clips
>
> In the latter case we support it through fbdev emulation (with
> fb_defio), atomic property, and with the dirtfy clip rects.
>
> Make sure at least the atomic property is set up as the main official
> interface for this. Ideally we'd also check that
> drm_atomic_helper_dirtyfb() is used and that fbdev defio is set up,
> but that's quite a bit harder to do. Ideas very much welcome.
>
> From a cursor audit drivers seem to be getting this right mostly, but
> better to make sure. At least no one is bypassing the accessor
> function.
>
> Cc: Ville Syrjälä
> Cc: Gwan-gyeong Mun
> Cc: José Roberto de Souza
> Cc: Hans de Goede
> Signed-off-by: Daniel Vetter
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Thomas Zimmermann
> Cc: David Airlie
> Cc: Daniel Vetter
> ---
> drivers/gpu/drm/drm_plane.c | 42 +
> include/drm/drm_plane.h | 36 ---
> 2 files changed, 46 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> index b373958ecb30..40f099c67a8d 100644
> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c
> @@ -1397,6 +1397,48 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
> return ret;
> }
>
> +/**
> + * drm_plane_get_damage_clips_count - Returns damage clips count.
> + * @state: Plane state.
> + *
> + * Simple helper to get the number of &drm_mode_rect clips set by user-space
> + * during plane update.
> + *
> + * Return: Number of clips in plane fb_damage_clips blob property.
> + */
> +unsigned int
> +drm_plane_get_damage_clips_count(const struct drm_plane_state *state)
> +{
> + return (state && state->fb_damage_clips) ?
> + state->fb_damage_clips->length/sizeof(struct drm_mode_rect) : 0;
> +}
> +EXPORT_SYMBOL(drm_plane_get_damage_clips_count);
> +
> +/**
> + * drm_plane_get_damage_clips - Returns damage clips.
> + * @state: Plane state.
> + *
> + * Note that this function returns uapi type &drm_mode_rect. Drivers might
> want
> + * to use the helper functions drm_atomic_helper_damage_iter_init() and
> + * drm_atomic_helper_damage_iter_next() or drm_atomic_helper_damage_merged()
> if
> + * the driver can only handle a single damage region at most.
> + *
> + * Return: Damage clips in plane fb_damage_clips blob property.
> + */
> +struct drm_mode_rect *
> +drm_plane_get_damage_clips(const struct drm_plane_state *state)
> +{
> + struct drm_mode_config *config = &state->plane->dev->mode_config;
> +
> + /* check that drm_plane_enable_fb_damage_clips() was called */
> + WARN_ON_ONCE(!drm_mode_obj_find_prop_id(&state->plane->base,
> +
> config->prop_fb_damage_clips->base.id));
Changing to drm_warn_once()
Reviewed-by: José Roberto de Souza
> +
> + return (struct drm_mode_rect *)((state && state->fb_damage_clips) ?
> + state->fb_damage_clips->data : NULL);
> +}
> +EXPORT_SYMBOL(drm_plane_get_damage_clips);
> +
> struct drm_property *
> drm_create_scaling_filter_prop(struct drm_device *dev,
> unsigned int supported_filters)
> diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
> index 7f7d5148310c..a2684aab8372 100644
> --- a/include/drm/drm_plane.h
> +++ b/include/drm/drm_plane.h
> @@ -897,39 +897,11 @@ static inline struct drm_plane *drm_plane_find(struct
> drm_device *dev,
>
> bool drm_any_plane_has_format(struct drm_device *dev,
> u32 format, u64 modifier);
> -/**
> - * drm_plane_get_damage_clips_count - Returns damage clips count.
> - * @state: Plane state.
> - *
> - * Simple helper to get the number of &drm_mode_rect clips set by user-space
> - * during plane update.
> - *
> - * Return: Number of clips in plane fb_damage_clips blob property.
> - */
> -static inline unsigned int
> -drm_plane_get_damage_clips_count(const struct drm_plane_state *state)
> -{
> - return (state && state->fb_damage_clips) ?
> - state->fb_damage_clips->length/sizeof(struct drm_mode_rect) : 0;
> -}
> +unsigned int
> +drm_plane_get_damage_clips_count(const struct drm_plane_state *state);
>
> -/**
> - * drm_plane_get_damage_clips - Returns damage clips.
> - * @state: Plane state.
> - *
> - * Note that this function returns uapi type &drm_mode_rect. Drivers might
> want
> - * to use the helper functions drm_atomic_helper_damage_iter_init() and
> - * drm_atomic_helper_damage_iter_next() or drm_atomic_helper_damage_merged()
> if
> - * the driver can only handle a single damage region at most.
> - *
> - * Return: Damage clips in plane fb_damage_clips blob property.
> - */
> -static inline struct drm_mode_rect *
> -drm_plane_get_damage_clips(const struct d
Re: [PATCH v2 2/2] drm/dp_mst: Avoid to mess up payload table by ports in stale topology
On Wed, 2021-06-16 at 11:55 +0800, Wayne Lin wrote:
> [Why]
> After unplug/hotplug hub from the system, userspace might start to
> clear stale payloads gradually. If we call drm_dp_mst_deallocate_vcpi()
> to release stale VCPI of those ports which are not relating to current
> topology, we have chane to wrongly clear active payload table entry for
> current topology.
>
> E.g.
> We have allocated VCPI 1 in current payload table and we call
> drm_dp_mst_deallocate_vcpi() to clean VCPI 1 in stale topology. In
> drm_dp_mst_deallocate_vcpi(), it will call drm_dp_mst_put_payload_id()
> tp put VCPI 1 and which means ID 1 is available again. Thereafter, if we
> want to allocate a new payload stream, it will find ID 1 is available by
> drm_dp_mst_assign_payload_id(). However, ID 1 is being used
>
> [How]
> Check target sink is relating to current topology or not before doing
> any payload table update.
> Searching upward to find the target sink's relevant root branch device.
> If the found root branch device is not the same root of current
> topology, don't update payload table.
>
> Changes since v1:
> * Change debug macro to use drm_dbg_kms() instead
> * Amend the commit message to add Cc tag.
>
> Signed-off-by: Wayne Lin
> Cc: sta...@vger.kernel.org
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 29 +++
> 1 file changed, 29 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index b41b837db66d..9ac148efd9e4 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -94,6 +94,9 @@ static int drm_dp_mst_register_i2c_bus(struct
> drm_dp_mst_port *port);
> static void drm_dp_mst_unregister_i2c_bus(struct drm_dp_mst_port *port);
> static void drm_dp_mst_kick_tx(struct drm_dp_mst_topology_mgr *mgr);
>
> +static bool drm_dp_mst_port_downstream_of_branch(struct drm_dp_mst_port
> *port,
> + struct drm_dp_mst_branch
> *branch);
> +
> #define DBG_PREFIX "[dp_mst]"
>
> #define DP_STR(x) [DP_ ## x] = #x
> @@ -3366,6 +3369,7 @@ int drm_dp_update_payload_part1(struct
> drm_dp_mst_topology_mgr *mgr)
> struct drm_dp_mst_port *port;
> int i, j;
> int cur_slots = 1;
> + bool skip;
>
> mutex_lock(&mgr->payload_lock);
> for (i = 0; i < mgr->max_payloads; i++) {
> @@ -3380,6 +3384,14 @@ int drm_dp_update_payload_part1(struct
> drm_dp_mst_topology_mgr *mgr)
> port = container_of(vcpi, struct drm_dp_mst_port,
> vcpi);
>
> + mutex_lock(&mgr->lock);
> + skip = !drm_dp_mst_port_downstream_of_branch(port,
> mgr->mst_primary);
> + mutex_unlock(&mgr->lock);
> +
> + if (skip) {
> + drm_dbg_kms("Virtual channel %d is not in
> current topology\n", i);
Missing dev/drm parameter and breaking the build.
> + continue;
> + }
> /* Validated ports don't matter if we're releasing
>* VCPI
>*/
> @@ -3479,6 +3491,7 @@ int drm_dp_update_payload_part2(struct
> drm_dp_mst_topology_mgr *mgr)
> struct drm_dp_mst_port *port;
> int i;
> int ret = 0;
> + bool skip;
>
> mutex_lock(&mgr->payload_lock);
> for (i = 0; i < mgr->max_payloads; i++) {
> @@ -3488,6 +3501,13 @@ int drm_dp_update_payload_part2(struct
> drm_dp_mst_topology_mgr *mgr)
>
> port = container_of(mgr->proposed_vcpis[i], struct
> drm_dp_mst_port, vcpi);
>
> + mutex_lock(&mgr->lock);
> + skip = !drm_dp_mst_port_downstream_of_branch(port,
> mgr->mst_primary);
> + mutex_unlock(&mgr->lock);
> +
> + if (skip)
> + continue;
> +
> drm_dbg_kms(mgr->dev, "payload %d %d\n", i,
> mgr->payloads[i].payload_state);
> if (mgr->payloads[i].payload_state == DP_PAYLOAD_LOCAL) {
> ret = drm_dp_create_payload_step2(mgr, port,
> mgr->proposed_vcpis[i]->vcpi, &mgr->payloads[i]);
> @@ -4574,9 +4594,18 @@ EXPORT_SYMBOL(drm_dp_mst_reset_vcpi_slots);
> void drm_dp_mst_deallocate_vcpi(struct drm_dp_mst_topology_mgr *mgr,
> struct drm_dp_mst_port *port)
> {
> + bool skip;
> +
> if (!port->vcpi.vcpi)
> return;
>
> + mutex_lock(&mgr->lock);
> + skip = !drm_dp_mst_port_downstream_of_branch(port, mgr->mst_primary);
> + mutex_unlock(&mgr->lock);
> +
> + if (skip)
> + return;
> +
> drm_dp_mst_put_payload_id(mgr, port->vcpi.vcpi);
> port->vcpi.num_slots = 0;
> port->vcpi.pbn = 0;
Re: [Intel-gfx] [PATCH 1/2] drm: Rename DP_PSR_SELECTIVE_UPDATE to better mach eDP spec
On Fri, 2021-04-23 at 12:25 +0200, Maarten Lankhorst wrote: > Op 22-04-2021 om 13:00 schreef Mun, Gwan-gyeong: > > The changed name looks more accurate to the edp 1.4b spec. > > Looks good to me. > > > > Reviewed-by: Gwan-gyeong Mun > > > > On Wed, 2021-04-21 at 15:02 -0700, José Roberto de Souza wrote: > > > DP_PSR_EN_CFG bit 5 aka "Selective Update Region Scan Line Capture > > > Indication" in eDP spec has a ambiguous name, so renaming to better > > > match specification. > > > > > > While at it, replacing bit shit by BIT() macro and adding the version > > > some registers were added to eDP specification. > > > > > > Cc: > > > Cc: Rodrigo Vivi > > > Cc: Jani Nikula > > > Cc: Gwan-gyeong Mun > > > Signed-off-by: José Roberto de Souza > > > --- > > > include/drm/drm_dp_helper.h | 16 > > > 1 file changed, 8 insertions(+), 8 deletions(-) > > > > > > diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h > > > index 1e85c2021f2f..d6f6a084a190 100644 > > > --- a/include/drm/drm_dp_helper.h > > > +++ b/include/drm/drm_dp_helper.h > > > @@ -687,14 +687,14 @@ struct drm_device; > > > #define DP_DSC_ENABLE 0x160 /* DP 1.4 */ > > > # define DP_DECOMPRESSION_EN (1 << 0) > > > > > > -#define DP_PSR_EN_CFG 0x170 /* XXX 1.2? */ > > > -# define DP_PSR_ENABLE (1 << 0) > > > -# define DP_PSR_MAIN_LINK_ACTIVE (1 << 1) > > > -# define DP_PSR_CRC_VERIFICATION (1 << 2) > > > -# define DP_PSR_FRAME_CAPTURE (1 << 3) > > > -# define DP_PSR_SELECTIVE_UPDATE (1 << 4) > > > -# define DP_PSR_IRQ_HPD_WITH_CRC_ERRORS (1 << 5) > > > -# define DP_PSR_ENABLE_PSR2 (1 << 6) /* eDP 1.4a */ > > > +#define DP_PSR_EN_CFG 0x170 /* XXX 1.2? */ > > > +# define DP_PSR_ENABLE BIT(0) > > > +# define DP_PSR_MAIN_LINK_ACTIVE BIT(1) > > > +# define DP_PSR_CRC_VERIFICATION BIT(2) > > > +# define DP_PSR_FRAME_CAPTURE BIT(3) > > > +# define DP_PSR_SU_REGION_SCANLINE_CAPTURE BIT(4) /* eDP 1.4a */ > > > +# define DP_PSR_IRQ_HPD_WITH_CRC_ERRORSBIT(5) /* eDP > > > 1.4a */ > > > +# define DP_PSR_ENABLE_PSR2BIT(6) /* eDP 1.4a */ > > > > > > #define DP_ADAPTER_CTRL 0x1a0 > > > # define DP_ADAPTER_CTRL_FORCE_LOAD_SENSE (1 << 0) > > ___ > > Intel-gfx mailing list > > intel-...@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx > > This should probably go throuh drm-misc-next, I don't see the next patch > depending on this? The patch depending on this change will be sent right after this one is merged. > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 15/19] drm/i915: WA for zero memory channel
On Mon, 2021-04-12 at 10:05 +0100, Matthew Auld wrote:
> From: José Roberto de Souza
>
> Commit c457d9cf256e ("drm/i915: Make sure we have enough memory
> bandwidth on ICL") assumes that we always have a non-zero
> dram_info->channels and uses it as a divisor. We need num memory
> channels to be at least 1 for sane bw limits checking, even when PCode
> returns 0, so lets force it to 1 in this case.
Missing my sob.
>
> Cc: Stanislav Lisovskiy
> Cc: Rodrigo Vivi
> Cc: Ville Syrjälä
> Signed-off-by: Daniele Ceraolo Spurio
> Signed-off-by: Lucas De Marchi
> ---
> drivers/gpu/drm/i915/display/intel_bw.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
> b/drivers/gpu/drm/i915/display/intel_bw.c
> index 584ab5ce4106..c5f70f3e930e 100644
> --- a/drivers/gpu/drm/i915/display/intel_bw.c
> +++ b/drivers/gpu/drm/i915/display/intel_bw.c
> @@ -175,6 +175,7 @@ static int icl_get_bw_info(struct drm_i915_private
> *dev_priv, const struct intel
> "Failed to get memory subsystem information,
> ignoring bandwidth limits");
> return ret;
> }
> + num_channels = max_t(u8, 1, num_channels);
>
>
>
>
> deinterleave = DIV_ROUND_UP(num_channels, is_y_tile ? 4 : 2);
> dclk_max = icl_sagv_max_dclk(&qi);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 1/5] drm: Add function to convert rect in 16.16 fixed format to regular format
On Tue, 2020-12-15 at 16:44 +0200, Ville Syrjälä wrote:
> On Mon, Dec 14, 2020 at 09:49:08AM -0800, José Roberto de Souza wrote:
> > Much more clear to read one function call than four lines doing this
> > conversion.
> >
> > Cc: dri-devel@lists.freedesktop.org
> > Cc: Gwan-gyeong Mun
> > Signed-off-by: José Roberto de Souza
> > ---
> > drivers/gpu/drm/drm_rect.c | 15 +++
> > include/drm/drm_rect.h | 2 ++
> > 2 files changed, 17 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_rect.c b/drivers/gpu/drm/drm_rect.c
> > index 0460e874896e..24345704b353 100644
> > --- a/drivers/gpu/drm/drm_rect.c
> > +++ b/drivers/gpu/drm/drm_rect.c
> > @@ -373,3 +373,18 @@ void drm_rect_rotate_inv(struct drm_rect *r,
> > }
> > }
> > EXPORT_SYMBOL(drm_rect_rotate_inv);
> > +
> > +/**
> > + * drm_rect_convert_16_16_to_regular - Convert a rect in 16.16 fixed point
> > form
> > + * to regular form.
> > + * @in: rect in 16.16 fixed point form
> > + * @out: rect to be stored the converted value
> > + */
> > +void drm_rect_convert_16_16_to_regular(struct drm_rect *in, struct
> > drm_rect *out)
> > +{
> > + out->x1 = in->x1 >> 16;
> > + out->y1 = in->y1 >> 16;
> > + out->x2 = in->x2 >> 16;
> > + out->y2 = in->y2 >> 16;
> > +}
>
> That's not the same as what we do in most places. We truncate
> the width/height, not x2/y2. Doing it on x2/y2 may increase
> the width/height.
>
> So I suggest something more like:
>
> static inline void drm_rect_fp_to_int(struct drm_rect *r)
> {
> drm_rect_init(r, r->x1 >> 16, r->y1 >> 16,
> drm_rect_width(r) >> 16,
> drm_rect_height(r) >> 16);
> }
>
> to match the current way of doing things.
Okay, but most use cases takes drm_plane_state.src and converts and sets it in
another rect, so will modify it to have two parameters.
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 1/5] drm: Add function to convert rect in 16.16 fixed format to regular format
On Tue, 2020-12-15 at 12:52 +, Mun, Gwan-gyeong wrote:
> On Mon, 2020-12-14 at 09:49 -0800, José Roberto de Souza wrote:
> > Much more clear to read one function call than four lines doing this
> > conversion.
> >
> > Cc: dri-devel@lists.freedesktop.org
> > Cc: Gwan-gyeong Mun
> > Signed-off-by: José Roberto de Souza
> > ---
> > drivers/gpu/drm/drm_rect.c | 15 +++
> > include/drm/drm_rect.h | 2 ++
> > 2 files changed, 17 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_rect.c b/drivers/gpu/drm/drm_rect.c
> > index 0460e874896e..24345704b353 100644
> > --- a/drivers/gpu/drm/drm_rect.c
> > +++ b/drivers/gpu/drm/drm_rect.c
> > @@ -373,3 +373,18 @@ void drm_rect_rotate_inv(struct drm_rect *r,
> > }
> > }
> > EXPORT_SYMBOL(drm_rect_rotate_inv);
> > +
> > +/**
> > + * drm_rect_convert_16_16_to_regular - Convert a rect in 16.16 fixed
> > point form
> > + * to regular form.
> > + * @in: rect in 16.16 fixed point form
> > + * @out: rect to be stored the converted value
> > + */
> > +void drm_rect_convert_16_16_to_regular(struct drm_rect *in, struct
> > drm_rect *out)
> > +{
> > + out->x1 = in->x1 >> 16;
> > + out->y1 = in->y1 >> 16;
> > + out->x2 = in->x2 >> 16;
> > + out->y2 = in->y2 >> 16;
> > +}
> > +EXPORT_SYMBOL(drm_rect_convert_16_16_to_regular);
> > diff --git a/include/drm/drm_rect.h b/include/drm/drm_rect.h
> > index e7f4d24cdd00..2ef8180416cd 100644
> > --- a/include/drm/drm_rect.h
> > +++ b/include/drm/drm_rect.h
> > @@ -223,5 +223,7 @@ void drm_rect_rotate(struct drm_rect *r,
> > void drm_rect_rotate_inv(struct drm_rect *r,
> > int width, int height,
> > unsigned int rotation);
> > +void drm_rect_convert_16_16_to_regular(struct drm_rect *in,
> > + struct drm_rect *out);
> >
> Hi,
> if it's purpose is just converting 16.16 fp to integer, how about you
> have function prototype like this?
> extern inline struct drm_rect
> drm_rect_convert_16_16_fp_to_integer(struct drm_rect in)
I prefer have a function call as this can be reused in several places, so the
binaries size can decrease a bit.
Also pointers are better, compiler can decide to not inline the function above
and it would need to allocate in stack 2 drm_rects for every call.
>
> And if there are no use case on drm core or other drivers except i915
> display yet,
> before adding this function to drm core, how about you add this
> function code to i915 first?
There is plenty of users in other drivers, just not doing in this series.
>
> Br,
> G.G.
> > #endif
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/damage_helper: Check if damage clips has valid values
On Sun, 2020-12-13 at 17:22 +, Simon Ser wrote:
> Can you add some drm_dbg_atomic logs when the damage is invalid, to make it
> easier for user-space to understand why an atomic commit failed?
sure, this is enough? will wait for a couple of more days before send another
version.
diff --git a/drivers/gpu/drm/drm_damage_helper.c
b/drivers/gpu/drm/drm_damage_helper.c
index 9adb369440ba..b598b137d27f 100644
--- a/drivers/gpu/drm/drm_damage_helper.c
+++ b/drivers/gpu/drm/drm_damage_helper.c
@@ -33,6 +33,7 @@
#include
#include
#include
+#include
/**
* DOC: overview
@@ -152,16 +153,25 @@ int drm_atomic_helper_check_plane_damage(struct
drm_atomic_state *state,
for (; num_clips; num_clips--, damaged_clips++) {
if (damaged_clips->x1 < 0 || damaged_clips->x2 < 0 ||
- damaged_clips->y1 < 0 || damaged_clips->y2 < 0)
+ damaged_clips->y1 < 0 || damaged_clips->y2 < 0) {
+ drm_dbg_atomic(state->dev,
+ "Invalid damage clip, negative
coordinate\n");
return -EINVAL;
+ }
if (damaged_clips->x2 < damaged_clips->x1 ||
- damaged_clips->y2 < damaged_clips->y1)
+ damaged_clips->y2 < damaged_clips->y1) {
+ drm_dbg_atomic(state->dev,
+ "Invalid damage clip, negative width or
height\n");
return -EINVAL;
+ }
if ((damaged_clips->x2 - damaged_clips->x1) > w ||
- (damaged_clips->y2 - damaged_clips->y1) > h)
+ (damaged_clips->y2 - damaged_clips->y1) > h) {
+ drm_dbg_atomic(state->dev,
+ "Invalid damage clip, width or height
larger than plane\n");
return -EINVAL;
+ }
}
return 0;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915/edp/jsl: Update vswing table for HBR and HBR2
Please fix the checkpatch errors, you can run it locally by running "dim
checkpatch drm-tip/drm-tip..HEAD", search for instructions of how to fetch
and setup dim.
Also no need to CC drm-devel for patches that only touches i915, drm-devel is
for drivers that don't have it's own list and for changes in drm
subsystem that affects all other drm based drivers.
On Wed, 2020-10-14 at 20:29 +0530, Tejas Upadhyay wrote:
> JSL has update in vswing table for eDP.
>
> BSpec: 21257
>
> Cc: Souza Jose
> Signed-off-by: Tejas Upadhyay
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 87 +++-
> 1 file changed, 85 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index bb0b9930958f..7ab694c6d8df 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -582,6 +582,34 @@ static const struct cnl_ddi_buf_trans
> ehl_combo_phy_ddi_translations_dp[] = {
> { 0x6, 0x7F, 0x3F, 0x00, 0x00 },/* 900 900 0.0 */
> };
>
>
> +static const struct cnl_ddi_buf_trans
> jsl_combo_phy_ddi_translations_edp_hbr[] = {
> + /* NT mV Trans mV db*/
> + { 0x8, 0x7F, 0x3F, 0x00, 0x00 },/* 200 200 0.0 */
> + { 0x8, 0x7F, 0x38, 0x00, 0x07 },/* 200 250 1.9 */
> + { 0x1, 0x7F, 0x33, 0x00, 0x0C },/* 200 300 3.5 */
> + { 0xA, 0x35, 0x36, 0x00, 0x09 },/* 200 350 4.9 */
> + { 0x8, 0x7F, 0x3F, 0x00, 0x00 },/* 250 250 0.0 */
> + { 0x1, 0x7F, 0x38, 0x00, 0x07 },/* 250 300 1.6 */
> + { 0xA, 0x35, 0x35, 0x00, 0x0A },/* 250 350 2.9 */
> + { 0x1, 0x7F, 0x3F, 0x00, 0x00 },/* 300 300 0.0 */
> + { 0xA, 0x35, 0x38, 0x00, 0x07 },/* 300 350 1.3 */
> + { 0xA, 0x35, 0x3F, 0x00, 0x00 },/* 350 350 0.0 */
> +};
> +
> +static const struct cnl_ddi_buf_trans
> jsl_combo_phy_ddi_translations_edp_hbr2[] = {
> + /* NT mV Trans mV db*/
> + { 0x8, 0x7F, 0x3F, 0x00, 0x00 },/* 200 200 0.0 */
> + { 0x8, 0x7F, 0x3F, 0x00, 0x00 },/* 200 250 1.9 */
> + { 0x1, 0x7F, 0x3D, 0x00, 0x02 },/* 200 300 3.5 */
> + { 0xA, 0x35, 0x38, 0x00, 0x07 },/* 200 350 4.9 */
> + { 0x8, 0x7F, 0x3F, 0x00, 0x00 },/* 250 250 0.0 */
> + { 0x1, 0x7F, 0x3F, 0x00, 0x00 },/* 250 300 1.6 */
> + { 0xA, 0x35, 0x3A, 0x00, 0x05 },/* 250 350 2.9 */
> + { 0x1, 0x7F, 0x3F, 0x00, 0x00 },/* 300 300 0.0 */
> + { 0xA, 0x35, 0x38, 0x00, 0x07 },/* 300 350 1.3 */
> + { 0xA, 0x35, 0x3F, 0x00, 0x00 },/* 350 350 0.0 */
> +};
> +
> struct icl_mg_phy_ddi_buf_trans {
> u32 cri_txdeemph_override_11_6;
> u32 cri_txdeemph_override_5_0;
> @@ -1162,6 +1190,57 @@ ehl_get_combo_buf_trans(struct intel_encoder *encoder,
> return ehl_get_combo_buf_trans_dp(encoder, crtc_state,
> n_entries);
> }
>
>
> +static const struct cnl_ddi_buf_trans *
> +jsl_get_combo_buf_trans_hdmi(struct intel_encoder *encoder,
> + const struct intel_crtc_state *crtc_state,
> + int *n_entries)
> +{
> + *n_entries = ARRAY_SIZE(icl_combo_phy_ddi_translations_hdmi);
> + return icl_combo_phy_ddi_translations_hdmi;
> +}
> +
> +static const struct cnl_ddi_buf_trans *
> +jsl_get_combo_buf_trans_dp(struct intel_encoder *encoder,
> + const struct intel_crtc_state *crtc_state,
> + int *n_entries)
> +{
> + *n_entries = ARRAY_SIZE(icl_combo_phy_ddi_translations_dp_hbr2);
> + return icl_combo_phy_ddi_translations_dp_hbr2;
> +}
> +
> +static const struct cnl_ddi_buf_trans *
> +jsl_get_combo_buf_trans_edp(struct intel_encoder *encoder,
> +const struct intel_crtc_state *crtc_state,
> +int *n_entries)
> +{
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> +
> + if (dev_priv->vbt.edp.low_vswing) {
> + if (crtc_state->port_clock > 27) {
> + *n_entries =
> ARRAY_SIZE(jsl_combo_phy_ddi_translations_edp_hbr2);
> + return jsl_combo_phy_ddi_translations_edp_hbr2;
> + } else {
> + *n_entries =
> ARRAY_SIZE(jsl_combo_phy_ddi_translations_edp_hbr);
> + return jsl_com
Re: [Intel-gfx] [PATCH] drm/i915/ehl: Remove require_force_probe protection
On Tue, 2020-10-06 at 10:55 -0700, Vivi, Rodrigo wrote: > > > On Oct 6, 2020, at 10:48 AM, Chris Wilson wrote: > > > > Quoting Souza, Jose (2020-10-06 18:46:45) > > > +Rodrigo and Jani > > > > > > On Tue, 2020-10-06 at 14:56 +, Kamati Srinivas wrote: > > > > Removing force probe protection from EHL platform. Did > > > > not observe warnings, errors, flickering or any visual > > > > defects while doing ordinary tasks like browsing and > > > > editing documents in a two monitor setup. > > > > > > One of the requirements was also to have CI BAT all green and shards as > > > green is possible but EHL don't show up in CI results, we actually have > > > one > > > single EHL machine in CI but I guess it is not able to run all tests that > > > shards do: > > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9097/filelist.html > > > > https://intel-gfx-ci.01.org/tree/drm-tip/drmtip-alt.html > > we are really close to that point. We just need to fix some w/a and rc6 issues > before applying this change. > > > -Chris > Huum okay we have drm-tip results for EHL but if someone sends a patch that breaks EHL it will not be caught in pre-merge testing. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/i915/ehl: Remove require_force_probe protection
+Rodrigo and Jani
On Tue, 2020-10-06 at 14:56 +, Kamati Srinivas wrote:
> Removing force probe protection from EHL platform. Did
> not observe warnings, errors, flickering or any visual
> defects while doing ordinary tasks like browsing and
> editing documents in a two monitor setup.
One of the requirements was also to have CI BAT all green and shards as green
is possible but EHL don't show up in CI results, we actually have one
single EHL machine in CI but I guess it is not able to run all tests that
shards do:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9097/filelist.html
>
> Signed-off-by: Kamati Srinivas
> ---
> drivers/gpu/drm/i915/i915_pci.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index 366ddfc8df6b..aa9c17a6851c 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -841,7 +841,6 @@ static const struct intel_device_info icl_info = {
> static const struct intel_device_info ehl_info = {
> GEN11_FEATURES,
> PLATFORM(INTEL_ELKHARTLAKE),
> - .require_force_probe = 1,
> .platform_engine_mask = BIT(RCS0) | BIT(BCS0) | BIT(VCS0) | BIT(VECS0),
> .ppgtt_size = 36,
> };
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/i915/edp/jsl: Update vswing table for HBR and HBR2
On Tue, 2020-09-29 at 23:30 +0300, Ville Syrjälä wrote: > On Tue, Sep 29, 2020 at 08:20:22PM +0000, Souza, Jose wrote: > > On Tue, 2020-09-29 at 23:02 +0300, Ville Syrjälä wrote: > > > On Tue, Sep 29, 2020 at 07:33:45PM +, Souza, Jose wrote: > > > > On Tue, 2020-09-29 at 17:41 +0530, Tejas Upadhyay wrote: > > > > > JSL has update in vswing table for eDP > > > > > > > > Would be nice to mention in the commit description why PCH is being > > > > used, that would avoid Ville's question. > > > > > > If the thing has nothing to do PCH then it should not use the PCH type > > > for the the check. Instead we should just do the EHL/JSL split. > > > > In the first version Matt Roper suggested to use PCH to differentiate > > between EHL and JSL, Jani also agreed with this solution.This 2 PCHs can > > only be > > associate with EHL and JSL respectively, so no downsides here. > > The downside is that the code makes no sense on the first glance. > It's going to generate a "wtf?" exception in the brain and require > me to take a second look to figure what is going on. Exception > handling is expensive and shouldn't be needed in cases where it's > trivial to make the code 100% obvious. > Adding a comment on the top of jsl_get_combo_buf_trans() would help? Otherwise Tejas you will need to rework this then. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/i915/edp/jsl: Update vswing table for HBR and HBR2
On Tue, 2020-09-29 at 23:02 +0300, Ville Syrjälä wrote:
> On Tue, Sep 29, 2020 at 07:33:45PM +0000, Souza, Jose wrote:
> > On Tue, 2020-09-29 at 17:41 +0530, Tejas Upadhyay wrote:
> > > JSL has update in vswing table for eDP
> >
> > Would be nice to mention in the commit description why PCH is being used,
> > that would avoid Ville's question.
>
> If the thing has nothing to do PCH then it should not use the PCH type
> for the the check. Instead we should just do the EHL/JSL split.
In the first version Matt Roper suggested to use PCH to differentiate between
EHL and JSL, Jani also agreed with this solution.This 2 PCHs can only be
associate with EHL and JSL respectively, so no downsides here.
>
> > > BSpec: 21257
> > >
> > > Changes since V1 :
> > > - IS_ELKHARTLAKE and IS_JASPERLAKE is replaced with
> > > HAS_PCH_MCC(EHL) and HAS_PCH_JSP(JSL) respectively
> > > - Reverted EHL/JSL PCI ids split change
> > >
> > > Signed-off-by: Tejas Upadhyay <
> > > tejaskumarx.surendrakumar.upadh...@intel.com
> > >
> > >
> > > ---
> > > drivers/gpu/drm/i915/display/intel_ddi.c | 67 ++--
> > > 1 file changed, 64 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> > > b/drivers/gpu/drm/i915/display/intel_ddi.c
> > > index 4d06178cd76c..e6e93d01d0ce 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> > > @@ -582,6 +582,34 @@ static const struct cnl_ddi_buf_trans
> > > ehl_combo_phy_ddi_translations_dp[] = {
> > > { 0x6, 0x7F, 0x3F, 0x00, 0x00 },/* 900 900 0.0 */
> > > };
> > >
> > > +static const struct cnl_ddi_buf_trans
> > > jsl_combo_phy_ddi_translations_edp_hbr[] = {
> > > + /* NT mV Trans mV db*/
> > > + { 0x8, 0x7F, 0x3F, 0x00, 0x00 },/* 200 200 0.0 */
> > > + { 0x8, 0x7F, 0x38, 0x00, 0x07 },/* 200 250 1.9 */
> > > + { 0x1, 0x7F, 0x33, 0x00, 0x0C },/* 200 300 3.5 */
> > > + { 0xA, 0x35, 0x36, 0x00, 0x09 },/* 200 350 4.9 */
> > > + { 0x8, 0x7F, 0x3F, 0x00, 0x00 },/* 250 250 0.0 */
> > > + { 0x1, 0x7F, 0x38, 0x00, 0x07 },/* 250 300 1.6 */
> > > + { 0xA, 0x35, 0x35, 0x00, 0x0A },/* 250 350 2.9 */
> > > + { 0x1, 0x7F, 0x3F, 0x00, 0x00 },/* 300 300 0.0 */
> > > + { 0xA, 0x35, 0x38, 0x00, 0x07 },/* 300 350 1.3 */
> > > + { 0xA, 0x35, 0x3F, 0x00, 0x00 },/* 350 350 0.0 */
> > > +};
> > > +
> > > +static const struct cnl_ddi_buf_trans
> > > jsl_combo_phy_ddi_translations_edp_hbr2[] = {
> > > + /* NT mV Trans mV db*/
> > > + { 0x8, 0x7F, 0x3F, 0x00, 0x00 },/* 200 200 0.0 */
> > > + { 0x8, 0x7F, 0x3F, 0x00, 0x00 },/* 200 250 1.9 */
> > > + { 0x1, 0x7F, 0x3D, 0x00, 0x02 },/* 200 300 3.5 */
> > > + { 0xA, 0x35, 0x38, 0x00, 0x07 },/* 200 350 4.9 */
> > > + { 0x8, 0x7F, 0x3F, 0x00, 0x00 },/* 250 250 0.0 */
> > > + { 0x1, 0x7F, 0x3F, 0x00, 0x00 },/* 250 300 1.6 */
> > > + { 0xA, 0x35, 0x3A, 0x00, 0x05 },/* 250 350 2.9 */
> > > + { 0x1, 0x7F, 0x3F, 0x00, 0x00 },/* 300 300 0.0 */
> > > + { 0xA, 0x35, 0x38, 0x00, 0x07 },/* 300 350 1.3 */
> > > + { 0xA, 0x35, 0x3F, 0x00, 0x00 },/* 350 350 0.0 */
> > > +};
> >
> > Tables matches specification.
> >
> > > +
> > > struct icl_mg_phy_ddi_buf_trans {
> > > u32 cri_txdeemph_override_11_6;
> > > u32 cri_txdeemph_override_5_0;
> > > @@ -1069,7 +1097,6 @@ icl_get_mg_buf_trans(struct intel_encoder *encoder,
> > > int type, int rate,
> > > *n_entries = ARRAY_SIZE(icl_mg_phy_ddi_translations_rbr_hbr);
> > > return icl_mg_phy_ddi_translations_rbr_hbr;
> > > }
> > > -
> >
> > Probably not intentional.
> >
> > Reviewed-by: José Roberto de Souza <
> > jose.so...@intel.com
> > >
> >
> > Will push with this line fixed as soon as CI finish testing.
> >
> >
> > > static const struct cnl_ddi_buf_trans *
> > > ehl_get_combo_buf_trans(struct intel_encoder
Re: [PATCH v2] drm/i915/edp/jsl: Update vswing table for HBR and HBR2
On Tue, 2020-09-29 at 17:41 +0530, Tejas Upadhyay wrote:
> JSL has update in vswing table for eDP
Would be nice to mention in the commit description why PCH is being used, that
would avoid Ville's question.
>
> BSpec: 21257
>
> Changes since V1 :
> - IS_ELKHARTLAKE and IS_JASPERLAKE is replaced with
> HAS_PCH_MCC(EHL) and HAS_PCH_JSP(JSL) respectively
> - Reverted EHL/JSL PCI ids split change
>
> Signed-off-by: Tejas Upadhyay <
> tejaskumarx.surendrakumar.upadh...@intel.com
> >
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 67 ++--
> 1 file changed, 64 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 4d06178cd76c..e6e93d01d0ce 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -582,6 +582,34 @@ static const struct cnl_ddi_buf_trans
> ehl_combo_phy_ddi_translations_dp[] = {
> { 0x6, 0x7F, 0x3F, 0x00, 0x00 },/* 900 900 0.0 */
> };
>
> +static const struct cnl_ddi_buf_trans
> jsl_combo_phy_ddi_translations_edp_hbr[] = {
> + /* NT mV Trans mV db*/
> + { 0x8, 0x7F, 0x3F, 0x00, 0x00 },/* 200 200 0.0 */
> + { 0x8, 0x7F, 0x38, 0x00, 0x07 },/* 200 250 1.9 */
> + { 0x1, 0x7F, 0x33, 0x00, 0x0C },/* 200 300 3.5 */
> + { 0xA, 0x35, 0x36, 0x00, 0x09 },/* 200 350 4.9 */
> + { 0x8, 0x7F, 0x3F, 0x00, 0x00 },/* 250 250 0.0 */
> + { 0x1, 0x7F, 0x38, 0x00, 0x07 },/* 250 300 1.6 */
> + { 0xA, 0x35, 0x35, 0x00, 0x0A },/* 250 350 2.9 */
> + { 0x1, 0x7F, 0x3F, 0x00, 0x00 },/* 300 300 0.0 */
> + { 0xA, 0x35, 0x38, 0x00, 0x07 },/* 300 350 1.3 */
> + { 0xA, 0x35, 0x3F, 0x00, 0x00 },/* 350 350 0.0 */
> +};
> +
> +static const struct cnl_ddi_buf_trans
> jsl_combo_phy_ddi_translations_edp_hbr2[] = {
> + /* NT mV Trans mV db*/
> + { 0x8, 0x7F, 0x3F, 0x00, 0x00 },/* 200 200 0.0 */
> + { 0x8, 0x7F, 0x3F, 0x00, 0x00 },/* 200 250 1.9 */
> + { 0x1, 0x7F, 0x3D, 0x00, 0x02 },/* 200 300 3.5 */
> + { 0xA, 0x35, 0x38, 0x00, 0x07 },/* 200 350 4.9 */
> + { 0x8, 0x7F, 0x3F, 0x00, 0x00 },/* 250 250 0.0 */
> + { 0x1, 0x7F, 0x3F, 0x00, 0x00 },/* 250 300 1.6 */
> + { 0xA, 0x35, 0x3A, 0x00, 0x05 },/* 250 350 2.9 */
> + { 0x1, 0x7F, 0x3F, 0x00, 0x00 },/* 300 300 0.0 */
> + { 0xA, 0x35, 0x38, 0x00, 0x07 },/* 300 350 1.3 */
> + { 0xA, 0x35, 0x3F, 0x00, 0x00 },/* 350 350 0.0 */
> +};
Tables matches specification.
> +
> struct icl_mg_phy_ddi_buf_trans {
> u32 cri_txdeemph_override_11_6;
> u32 cri_txdeemph_override_5_0;
> @@ -1069,7 +1097,6 @@ icl_get_mg_buf_trans(struct intel_encoder *encoder, int
> type, int rate,
> *n_entries = ARRAY_SIZE(icl_mg_phy_ddi_translations_rbr_hbr);
> return icl_mg_phy_ddi_translations_rbr_hbr;
> }
> -
Probably not intentional.
Reviewed-by: José Roberto de Souza
Will push with this line fixed as soon as CI finish testing.
> static const struct cnl_ddi_buf_trans *
> ehl_get_combo_buf_trans(struct intel_encoder *encoder, int type, int rate,
> int *n_entries)
> @@ -1098,6 +1125,34 @@ ehl_get_combo_buf_trans(struct intel_encoder *encoder,
> int type, int rate,
> }
> }
>
> +static const struct cnl_ddi_buf_trans *
> +jsl_get_combo_buf_trans(struct intel_encoder *encoder, int type, int rate,
> + int *n_entries)
> +{
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> +
> + switch (type) {
> + case INTEL_OUTPUT_HDMI:
> + *n_entries = ARRAY_SIZE(icl_combo_phy_ddi_translations_hdmi);
> + return icl_combo_phy_ddi_translations_hdmi;
> + case INTEL_OUTPUT_EDP:
> + if (dev_priv->vbt.edp.low_vswing) {
> + if (rate > 27) {
> + *n_entries =
> ARRAY_SIZE(jsl_combo_phy_ddi_translations_edp_hbr2);
> + return jsl_combo_phy_ddi_translations_edp_hbr2;
> + } else {
> + *n_entries =
> ARRAY_SIZE(jsl_combo_phy_ddi_translations_edp_hbr);
> + return jsl_combo_phy_ddi_translations_edp_hbr;
> + }
> + }
> + /* fall through */
> + default:
> + /* All combo DP and eDP ports that do not support low_vswing */
> + *n_entries = ARRAY_SIZE(icl_combo_phy_ddi_translations_dp_hbr2);
> + return icl_combo_phy_ddi_translations_dp_hbr2;
> +
Re: [PATCH] drm/i915/display: fix uninitialized variable
Just merged the first patch that fixed this issue, thanks anyways.
2034c2129bc4a91d471815d4dc7a2a69eaa5338d - drm/i915/display: Ensure that ret is
always initialized in icl_combo_phy_verify_state
On Tue, 2020-08-25 at 16:20 -0700, t...@redhat.com wrote:
> From: Tom Rix <
> t...@redhat.com
> >
>
> clang static analysis flags this error
>
> intel_combo_phy.c:268:7: warning: The left expression of the
> compound assignment is an uninitialized value.
> The computed value will also be garbage
> ret &= check_phy_reg(...
> ~~~ ^
>
> ret has no initial values, in icl_combo_phy_verify_state() ret is
> set by the next statment and then updated by similar &= logic.
>
> Because the check_phy_req() are only register reads, reorder the
> statements.
>
> Fixes: 239bef676d8e ("drm/i915/display: Implement new combo phy
> initialization step")
> Signed-off-by: Tom Rix <
> t...@redhat.com
> >
> ---
> drivers/gpu/drm/i915/display/intel_combo_phy.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_combo_phy.c
> b/drivers/gpu/drm/i915/display/intel_combo_phy.c
> index 6968de4f3477..7622ef66c987 100644
> --- a/drivers/gpu/drm/i915/display/intel_combo_phy.c
> +++ b/drivers/gpu/drm/i915/display/intel_combo_phy.c
> @@ -264,6 +264,8 @@ static bool icl_combo_phy_verify_state(struct
> drm_i915_private *dev_priv,
> if (!icl_combo_phy_enabled(dev_priv, phy))
> return false;
>
> + ret = cnl_verify_procmon_ref_values(dev_priv, phy);
> +
> if (INTEL_GEN(dev_priv) >= 12) {
> ret &= check_phy_reg(dev_priv, phy, ICL_PORT_TX_DW8_LN0(phy),
>ICL_PORT_TX_DW8_ODCC_CLK_SEL |
> @@ -276,8 +278,6 @@ static bool icl_combo_phy_verify_state(struct
> drm_i915_private *dev_priv,
>DCC_MODE_SELECT_CONTINUOSLY);
> }
>
> - ret = cnl_verify_procmon_ref_values(dev_priv, phy);
> -
> if (phy_is_master(dev_priv, phy)) {
> ret &= check_phy_reg(dev_priv, phy, ICL_PORT_COMP_DW8(phy),
>IREFGEN, IREFGEN);
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm] intel: sync i915_pciids.h with kernel
On Thu, 2020-08-20 at 10:46 +0200, Adam Miszczak wrote:
> Add DG1 and clean-up VLV PCI IDs.
>
> Align with kernel commits:
> f2bde2546b81 ("drm/i915: Remove dubious Valleyview PCI IDs")
> fd38cdb81105 ("drm/i915/dg1: Add DG1 PCI IDs")
>
Reviewed-by: José Roberto de Souza
But the current process for libdrm patches is to open a merge request in
Freedesktop gitlab, when you do CC me.
> Signed-off-by: Adam Miszczak <
> adam.miszc...@linux.intel.com
> >
> Cc: José Roberto de Souza <
> jose.so...@intel.com
> >
> ---
> intel/i915_pciids.h | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/intel/i915_pciids.h b/intel/i915_pciids.h
> index d6cb2899..8e7ae30e 100644
> --- a/intel/i915_pciids.h
> +++ b/intel/i915_pciids.h
> @@ -258,9 +258,7 @@
> INTEL_VGA_DEVICE(0x0f30, info), \
> INTEL_VGA_DEVICE(0x0f31, info), \
> INTEL_VGA_DEVICE(0x0f32, info), \
> - INTEL_VGA_DEVICE(0x0f33, info), \
> - INTEL_VGA_DEVICE(0x0157, info), \
> - INTEL_VGA_DEVICE(0x0155, info)
> + INTEL_VGA_DEVICE(0x0f33, info)
>
> #define INTEL_BDW_ULT_GT1_IDS(info) \
> INTEL_VGA_DEVICE(0x1606, info), /* GT1 ULT */ \
> @@ -618,4 +616,8 @@
> INTEL_VGA_DEVICE(0x4C90, info), \
> INTEL_VGA_DEVICE(0x4C9A, info)
>
> +/* DG1 */
> +#define INTEL_DG1_IDS(info) \
> + INTEL_VGA_DEVICE(0x4905, info)
> +
> #endif /* _I915_PCIIDS_H */
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 1/3] drm/edid: Allow looking for ext blocks starting from a specified index
On Thu, 2020-07-02 at 17:40 +0300, Ville Syrjälä wrote:
> On Tue, Jun 30, 2020 at 11:42:36PM +0000, Souza, Jose wrote:
> > On Wed, 2020-05-27 at 16:03 +0300, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > Apparently EDIDs with multiple DispID ext blocks is a thing, so prepare
> > > for iterating through multiple ext blocks of the same type by
> > > passing the starting ext block index to drm_find_edid_extension(). Well
> > > also have drm_find_edid_extension() update the index to point to the
> > > next ext block on success. Thus we should be able to call
> > > drm_find_edid_extension() in loop.
> > >
> > > Signed-off-by: Ville Syrjälä
> > > ---
> > > drivers/gpu/drm/drm_edid.c | 30 +-
> > > 1 file changed, 21 insertions(+), 9 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > > index d8372d63851b..f2531d51dfa2 100644
> > > --- a/drivers/gpu/drm/drm_edid.c
> > > +++ b/drivers/gpu/drm/drm_edid.c
> > > @@ -3188,7 +3188,8 @@ add_detailed_modes(struct drm_connector *connector,
> > > struct edid *edid,
> > > /*
> > > * Search EDID for CEA extension block.
> > > */
> > > -static u8 *drm_find_edid_extension(const struct edid *edid, int ext_id)
> > > +static u8 *drm_find_edid_extension(const struct edid *edid,
> > > +int ext_id, int *ext_index)
> > > {
> > > u8 *edid_ext = NULL;
> > > int i;
> > > @@ -3198,23 +3199,26 @@ static u8 *drm_find_edid_extension(const struct
> > > edid *edid, int ext_id)
> > > return NULL;
> > >
> > > /* Find CEA extension */
> > > - for (i = 0; i < edid->extensions; i++) {
> > > + for (i = *ext_index; i < edid->extensions; i++) {
> > > edid_ext = (u8 *)edid + EDID_LENGTH * (i + 1);
> > > if (edid_ext[0] == ext_id)
> > > break;
> > > }
> > >
> > > - if (i == edid->extensions)
> > > + if (i >= edid->extensions)
> > > return NULL;
> > >
> > > + *ext_index = i + 1;
> > > +
> > > return edid_ext;
> > > }
> > >
> >
> > I would add something like drm_find_edid_n_extension() with the
> > implementation above and then implement drm_find_edid_extension() calling
> > drm_find_edid_n_extension() but it is just one caller that is not using
> > ext_index so LGTM.
> >
> > >
> > > static u8 *drm_find_displayid_extension(const struct edid *edid,
> > > - int *length, int *idx)
> > > + int *length, int *idx,
> > > + int *ext_index)
> > > {
> > > - u8 *displayid = drm_find_edid_extension(edid, DISPLAYID_EXT);
> > > + u8 *displayid = drm_find_edid_extension(edid, DISPLAYID_EXT, ext_index);
> > > struct displayid_hdr *base;
> > > int ret;
> > >
> > > @@ -3241,14 +3245,18 @@ static u8 *drm_find_cea_extension(const struct
> > > edid *edid)
> > > struct displayid_block *block;
> > > u8 *cea;
> > > u8 *displayid;
> > > + int ext_index;
> > >
> > > /* Look for a top level CEA extension block */
> > > - cea = drm_find_edid_extension(edid, CEA_EXT);
> > > + ext_index = 0;
> >
> > In 2 places ext_index is initialized in the variable declaration and in 2
> > other places is not, all of it could be done in the declaration
>
> No, in this case we need to reset it back to 0 when the start looking
> for the DispID ext block (as opposed to the CEA ext block). So I figured
> it's cleaner if both initialize it to 0 the same way. All the other
> places need just the one initialization.
>
> Eventually I think I'd like some kind of for_each_ext_block() to make
> this stuff less crap...
Okay makes sense.
Reviewed-by: José Roberto de Souza
>
> > or if you
> > really want to leave the context close to the users, initialize it in the
> > "for (;;)" in the next patch.
> >
> > With the change above:
> >
> > Reviewed-by: José Roberto de Souza
> >
> > > + cea = drm_find_edid_extension(edid, CEA_EXT, &ext_index);
> > > if (cea)
> > > return cea;
> > >
> > > /* CEA blocks can also be found embedded in a DisplayID block */
> >
Re: [PATCH 3/3] drm/edid: Clean up some curly braces
On Wed, 2020-05-27 at 16:03 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Drop some pointless curly braces, and add some across the
> else when the if has them too.
Reviewed-by: José Roberto de Souza
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_edid.c | 9 -
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index dcb23563d29d..8a951e2bfb41 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -5836,22 +5836,21 @@ static void drm_parse_tiled_block(struct
> drm_connector *connector,
> DRM_DEBUG_KMS("vend %c%c%c\n", tile->topology_id[0],
> tile->topology_id[1], tile->topology_id[2]);
>
> tg = drm_mode_get_tile_group(connector->dev, tile->topology_id);
> - if (!tg) {
> + if (!tg)
> tg = drm_mode_create_tile_group(connector->dev,
> tile->topology_id);
> - }
> if (!tg)
> return;
>
> if (connector->tile_group != tg) {
> /* if we haven't got a pointer,
> take the reference, drop ref to old tile group */
> - if (connector->tile_group) {
> + if (connector->tile_group)
> drm_mode_put_tile_group(connector->dev,
> connector->tile_group);
> - }
> connector->tile_group = tg;
> - } else
> + } else {
> /* if same tile group, then release the ref we just took. */
> drm_mode_put_tile_group(connector->dev, tg);
> + }
> }
>
> static void drm_displayid_parse_tiled(struct drm_connector *connector,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 2/3] drm/edid: Iterate through all DispID ext blocks
On Wed, 2020-05-27 at 16:03 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Apparently there are EDIDs in the wild with multiple DispID extension
> blocks. Iterate through them all.
>
> In one particular case the tile information is specicied in the
> second DispID ext block, and since the current parser only looks
> at the first DispID ext block we don't notice that we're dealing
> with a tiled display.
>
> While at it change a few functions to return void since we have
> no use for the errno.
With the change in the previous patch:
Reviewed-by: José Roberto de Souza
>
> References: https://gitlab.freedesktop.org/drm/intel/-/issues/27
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_edid.c | 84 +-
> 1 file changed, 38 insertions(+), 46 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index f2531d51dfa2..dcb23563d29d 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -3248,6 +3248,7 @@ static u8 *drm_find_cea_extension(const struct edid
> *edid)
> int ext_index;
>
> /* Look for a top level CEA extension block */
> + /* FIXME: make callers iterate through multiple CEA ext blocks? */
> ext_index = 0;
> cea = drm_find_edid_extension(edid, CEA_EXT, &ext_index);
> if (cea)
> @@ -3255,20 +3256,20 @@ static u8 *drm_find_cea_extension(const struct edid
> *edid)
>
> /* CEA blocks can also be found embedded in a DisplayID block */
> ext_index = 0;
> - displayid = drm_find_displayid_extension(edid, &length, &idx,
> - &ext_index);
> - if (!displayid)
> - return NULL;
> + for (;;) {
> + displayid = drm_find_displayid_extension(edid, &length, &idx,
> + &ext_index);
> + if (!displayid)
> + return NULL;
>
> - idx += sizeof(struct displayid_hdr);
> - for_each_displayid_db(displayid, block, idx, length) {
> - if (block->tag == DATA_BLOCK_CTA) {
> - cea = (u8 *)block;
> - break;
> + idx += sizeof(struct displayid_hdr);
> + for_each_displayid_db(displayid, block, idx, length) {
> + if (block->tag == DATA_BLOCK_CTA)
> + return (u8 *)block;
> }
> }
>
> - return cea;
> + return NULL;
> }
>
> static __always_inline const struct drm_display_mode *cea_mode_for_vic(u8
> vic)
> @@ -5205,19 +5206,22 @@ static int add_displayid_detailed_modes(struct
> drm_connector *connector,
> int num_modes = 0;
> int ext_index = 0;
>
> - displayid = drm_find_displayid_extension(edid, &length, &idx,
> - &ext_index);
> - if (!displayid)
> - return 0;
> -
> - idx += sizeof(struct displayid_hdr);
> - for_each_displayid_db(displayid, block, idx, length) {
> - switch (block->tag) {
> - case DATA_BLOCK_TYPE_1_DETAILED_TIMING:
> - num_modes += add_displayid_detailed_1_modes(connector,
> block);
> + for (;;) {
> + displayid = drm_find_displayid_extension(edid, &length, &idx,
> + &ext_index);
> + if (!displayid)
> break;
> +
> + idx += sizeof(struct displayid_hdr);
> + for_each_displayid_db(displayid, block, idx, length) {
> + switch (block->tag) {
> + case DATA_BLOCK_TYPE_1_DETAILED_TIMING:
> + num_modes +=
> add_displayid_detailed_1_modes(connector, block);
> + break;
> + }
> }
> }
> +
> return num_modes;
> }
>
> @@ -5797,8 +5801,8 @@ drm_hdmi_vendor_infoframe_from_display_mode(struct
> hdmi_vendor_infoframe *frame,
> }
> EXPORT_SYMBOL(drm_hdmi_vendor_infoframe_from_display_mode);
>
> -static int drm_parse_tiled_block(struct drm_connector *connector,
> - const struct displayid_block *block)
> +static void drm_parse_tiled_block(struct drm_connector *connector,
> + const struct displayid_block *block)
> {
> const struct displayid_tiled_block *tile = (struct
> displayid_tiled_block *)block;
> u16 w, h;
> @@ -5836,7 +5840,7 @@ static int drm_parse_tiled_block(struct drm_connector
> *connector,
> tg = drm_mode_create_tile_group(connector->dev,
> tile->topology_id);
> }
> if (!tg)
> - return -ENOMEM;
> + return;
>
> if (connector->tile_group != tg) {
> /* if we haven't got a pointer,
> @@ -5848,14 +5852,12 @@ static int drm_parse_tiled_block(struct drm_connector
> *connector,
> } else
>
Re: [Intel-gfx] [PATCH 1/3] drm/edid: Allow looking for ext blocks starting from a specified index
On Wed, 2020-05-27 at 16:03 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Apparently EDIDs with multiple DispID ext blocks is a thing, so prepare
> for iterating through multiple ext blocks of the same type by
> passing the starting ext block index to drm_find_edid_extension(). Well
> also have drm_find_edid_extension() update the index to point to the
> next ext block on success. Thus we should be able to call
> drm_find_edid_extension() in loop.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_edid.c | 30 +-
> 1 file changed, 21 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index d8372d63851b..f2531d51dfa2 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -3188,7 +3188,8 @@ add_detailed_modes(struct drm_connector *connector,
> struct edid *edid,
> /*
> * Search EDID for CEA extension block.
> */
> -static u8 *drm_find_edid_extension(const struct edid *edid, int ext_id)
> +static u8 *drm_find_edid_extension(const struct edid *edid,
> +int ext_id, int *ext_index)
> {
> u8 *edid_ext = NULL;
> int i;
> @@ -3198,23 +3199,26 @@ static u8 *drm_find_edid_extension(const struct edid
> *edid, int ext_id)
> return NULL;
>
> /* Find CEA extension */
> - for (i = 0; i < edid->extensions; i++) {
> + for (i = *ext_index; i < edid->extensions; i++) {
> edid_ext = (u8 *)edid + EDID_LENGTH * (i + 1);
> if (edid_ext[0] == ext_id)
> break;
> }
>
> - if (i == edid->extensions)
> + if (i >= edid->extensions)
> return NULL;
>
> + *ext_index = i + 1;
> +
> return edid_ext;
> }
>
I would add something like drm_find_edid_n_extension() with the implementation
above and then implement drm_find_edid_extension() calling
drm_find_edid_n_extension() but it is just one caller that is not using
ext_index so LGTM.
>
> static u8 *drm_find_displayid_extension(const struct edid *edid,
> - int *length, int *idx)
> + int *length, int *idx,
> + int *ext_index)
> {
> - u8 *displayid = drm_find_edid_extension(edid, DISPLAYID_EXT);
> + u8 *displayid = drm_find_edid_extension(edid, DISPLAYID_EXT, ext_index);
> struct displayid_hdr *base;
> int ret;
>
> @@ -3241,14 +3245,18 @@ static u8 *drm_find_cea_extension(const struct edid
> *edid)
> struct displayid_block *block;
> u8 *cea;
> u8 *displayid;
> + int ext_index;
>
> /* Look for a top level CEA extension block */
> - cea = drm_find_edid_extension(edid, CEA_EXT);
> + ext_index = 0;
In 2 places ext_index is initialized in the variable declaration and in 2 other
places is not, all of it could be done in the declaration or if you
really want to leave the context close to the users, initialize it in the "for
(;;)" in the next patch.
With the change above:
Reviewed-by: José Roberto de Souza
> + cea = drm_find_edid_extension(edid, CEA_EXT, &ext_index);
> if (cea)
> return cea;
>
> /* CEA blocks can also be found embedded in a DisplayID block */
> - displayid = drm_find_displayid_extension(edid, &length, &idx);
> + ext_index = 0;
> + displayid = drm_find_displayid_extension(edid, &length, &idx,
> + &ext_index);
> if (!displayid)
> return NULL;
>
> @@ -5195,8 +5203,10 @@ static int add_displayid_detailed_modes(struct
> drm_connector *connector,
> int length, idx;
> struct displayid_block *block;
> int num_modes = 0;
> + int ext_index = 0;
>
> - displayid = drm_find_displayid_extension(edid, &length, &idx);
> + displayid = drm_find_displayid_extension(edid, &length, &idx,
> + &ext_index);
> if (!displayid)
> return 0;
>
> @@ -5870,11 +5880,13 @@ void drm_update_tile_info(struct drm_connector
> *connector,
> const struct edid *edid)
> {
> const void *displayid = NULL;
> + int ext_index = 0;
> int length, idx;
> int ret;
>
> connector->has_tile = false;
> - displayid = drm_find_displayid_extension(edid, &length, &idx);
> + displayid = drm_find_displayid_extension(edid, &length, &idx,
> + &ext_index);
> if (!displayid) {
> /* drop reference to any tile group we had */
> goto out_drop_ref;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 2/3] drm/dp_mst: Sanitize mgr->qlock locking in drm_dp_mst_wait_tx_reply()
On Thu, 2020-06-04 at 00:10 +0300, Imre Deak wrote:
> Make the locking look symmetric with the unlocking.
>
Reviewed-by: José Roberto de Souza
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 1bdf3cfeeebb..5bc72e800b85 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -1183,7 +1183,7 @@ static int drm_dp_mst_wait_tx_reply(struct
> drm_dp_mst_branch *mstb,
> ret = wait_event_timeout(mgr->tx_waitq,
>check_txmsg_state(mgr, txmsg),
>(4 * HZ));
> - mutex_lock(&mstb->mgr->qlock);
> + mutex_lock(&mgr->qlock);
> if (ret > 0) {
> if (txmsg->state == DRM_DP_SIDEBAND_TX_TIMEOUT) {
> ret = -EIO;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 1/3] drm/i915/dp_mst: Fix disabling MST on a port
On Thu, 2020-06-04 at 00:10 +0300, Imre Deak wrote:
> Currently MST on a port can get enabled/disabled from the hotplug work
> and get disabled from the short pulse work in a racy way. Fix this by
> relying on the MST state checking in the hotplug work and just schedule
> a hotplug work from the short pulse handler if some problem happened
> during the MST interrupt handling.
Nice
>
> This removes the explicit MST disabling in case of an AUX failure, but
> if AUX fails, then probably the detection will also fail during the
> scheduled hotplug work and it's not guaranteed that we'll see
> intermittent errors anyway.
>
> While at it also simplify the error checking of the MST interrupt
> handler.
>
Reviewed-by: José Roberto de Souza
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 33 +++--
> 1 file changed, 4 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 55fda074c0ad..befbcacddaa1 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -5604,7 +5604,7 @@ intel_dp_check_mst_status(struct intel_dp *intel_dp)
> }
> }
>
> - return need_retrain;
> + return need_retrain ? -EINVAL : 0;
> }
>
> static bool
> @@ -7255,35 +7255,10 @@ intel_dp_hpd_pulse(struct intel_digital_port
> *intel_dig_port, bool long_hpd)
> }
>
> if (intel_dp->is_mst) {
> - switch (intel_dp_check_mst_status(intel_dp)) {
> - case -EINVAL:
> - /*
> - * If we were in MST mode, and device is not
> - * there, get out of MST mode
> - */
> - drm_dbg_kms(&i915->drm,
> - "MST device may have disappeared %d vs
> %d\n",
> - intel_dp->is_mst,
> - intel_dp->mst_mgr.mst_state);
> - intel_dp->is_mst = false;
> - drm_dp_mst_topology_mgr_set_mst(&intel_dp->mst_mgr,
> - intel_dp->is_mst);
> -
> - return IRQ_NONE;
> - case 1:
> - return IRQ_NONE;
> - default:
> - break;
> - }
> - }
> -
> - if (!intel_dp->is_mst) {
> - bool handled;
> -
> - handled = intel_dp_short_pulse(intel_dp);
> -
> - if (!handled)
> + if (intel_dp_check_mst_status(intel_dp) < 0)
> return IRQ_NONE;
> + } else if (!intel_dp_short_pulse(intel_dp)) {
> + return IRQ_NONE;
> }
>
> return IRQ_HANDLED;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: 5.6 DP-MST regression: 1 of 2 monitors on TB3 (DP-MST) dock no longer light up
Hi Hans
Just commenting in the "[3.309061] [drm:intel_dump_pipe_config
[i915]] MST master transcoder: " message, it is the expected
behaviour for anything older than Tigerlake, from TGL+ this will be set
in MST mode.
On Wed, 2020-02-26 at 18:52 +0100, Hans de Goede wrote:
> Hi,
>
> On 2/26/20 5:05 PM, Alex Deucher wrote:
> > On Wed, Feb 26, 2020 at 10:43 AM Hans de Goede > > wrote:
> > > Hi,
> > >
> > > On 2/26/20 4:29 PM, Alex Deucher wrote:
> > > > On Wed, Feb 26, 2020 at 10:16 AM Hans de Goede <
> > > > hdego...@redhat.com> wrote:
> > > > > Hi Lyude and everyone else,
> > > > >
> > > > > Lyude I'm mailing you about this because you have done a lot
> > > > > of
> > > > > work on DP MST, but if this rings a bell to anyone else feel
> > > > > free to weigh in on this.
> > > >
> > > > Might be a duplicate of:
> > > > https://gitlab.freedesktop.org/drm/amd/issues/1052
> > >
> > > Looks like you are right, reverting the commit which the bisect
> > > from that issue points to:
> > >
> > > cd82d82cbc04 ("drm/dp_mst: Add branch bandwidth validation to MST
> > > atomic check")
> > >
> > > Fixes the issue for me. I will add a comment to the issue.
> > >
> > > Note I'm using integrated Intel gfx, so that means that this
> > > issue
> > > definitely is not amdgpu specific.
> > >
> >
> > I'm not too familiar with the mst code, but I wonder if we were
> > exceeding the bandwidth limits in some setups and it just happened
> > to
> > work, but now that we enforcing them, they don't which is correct,
> > but
> > a regression from some users' perspective?
>
> I seriously doubt that is the case according to:
> https://support.lenovo.com/nl/en/solutions/pd029622
>
> The gen 2 tb3 dock can handle 2 external
> displays at 3840*2160@60Hz together with the internal
> panel being on and both my external displays run at
> 1920x1080@60 so I'm consuming less then half of the
> maximum bandwidth.
>
> There definitely is a bug somewhere in the
> cd82d82cbc04 ("drm/dp_mst: Add branch bandwidth validation to MST
> atomic check")
> commit (or somewhere else and triggered by that commit).
>
> Regards,
>
> Hans
>
>
>
>
>
>
>
> > Alex
> >
> >
> > > Regards,
> > >
> > > Hans
> > >
> > >
> > >
> > >
> > > > > I'm currently using a Lenovo X1 7th gen + a Lenovo TB3 gen 2
> > > > > dock
> > > > > as my daily rider for testing purposes. When 5.6-rc1 came out
> > > > > I
> > > > > noticed that only 1 of the 2 1920x1080@60 monitors on the
> > > > > dock
> > > > > lights up.
> > > > >
> > > > > There are no kernel errors in the logs, but mutter/gnome-
> > > > > shell says:
> > > > >
> > > > > gnome-shell[1316]: Failed to post KMS update: Page flip of 93
> > > > > failed
> > > > >
> > > > > With 93 being the crtc-id of the crtc used for the monitor
> > > > > which is
> > > > > displaying black. Since then I've waited for 5.6-rc3 hoping
> > > > > that a
> > > > > fix was already queued up, but 5.6-rc3 still has this
> > > > > problem.
> > > > >
> > > > > gnome-shell does behave as if all monitors are connected, so
> > > > > the
> > > > > monitor is seen, but we are failing to actually send any
> > > > > frames
> > > > > to it.
> > > > >
> > > > > I've put a log collected with drm.debug=0x104 here:
> > > > > https://fedorapeople.org/~jwrdegoede/drm-debug.log
> > > > >
> > > > > This message stands out as pointing to the likely cause of
> > > > > this problem:
> > > > >
> > > > > [3.309061] [drm:intel_dump_pipe_config [i915]] MST master
> > > > > transcoder:
> > > > >
> > > > > Regards,
> > > > >
> > > > > Hans
> > > > >
> > > > > ___
> > > > > dri-devel mailing list
> > > > > dri-devel@lists.freedesktop.org
> > > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 3/4] drm/i915/display: Remove useless call intel_dp_mst_encoder_cleanup()
On Thu, 2020-01-30 at 19:16 +0200, Ville Syrjälä wrote:
> On Thu, Jan 16, 2020 at 05:58:36PM -0800, José Roberto de Souza
> wrote:
> > This is a eDP function and it will always returns true for non-eDP
> > ports.
> >
> > Signed-off-by: José Roberto de Souza
> > ---
> > drivers/gpu/drm/i915/display/intel_dp.c | 1 -
> > 1 file changed, 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index 4074d83b1a5f..a50b5b6dd009 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -7537,7 +7537,6 @@ intel_dp_init_connector(struct
> > intel_digital_port *intel_dig_port,
> >
> > if (!intel_edp_init_connector(intel_dp, intel_connector)) {
> > intel_dp_aux_fini(intel_dp);
> > - intel_dp_mst_encoder_cleanup(intel_dig_port);
>
> This makes the unwind look incomplete to the causual reader. The
> cleanup
> function does both anyway so cross checking is harder if they're not
> consistent. So not sure I like it. Hmm. The ordering of these two
> also
> looks off here.
>
> Maybe nicer to just move the whole onion to the end of function
> (we alredy have one layer there)?
If I need to rework the 4/4 patch I will do that, otherwise I will just
ignore this patch.
Please check my answer to your comment.
>
> > goto fail;
> > }
> >
> > --
> > 2.25.0
> >
> > ___
> > Intel-gfx mailing list
> > intel-...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/mst: Fix possible NULL pointer dereference in drm_dp_mst_process_up_req()
On Thu, 2020-01-30 at 10:49 +, Lisovskiy, Stanislav wrote:
> On Wed, 2020-01-29 at 15:24 -0800, José Roberto de Souza wrote:
> > According to DP specification, DP_SINK_EVENT_NOTIFY is also a
> > broadcast message but as this function only handles
> > DP_CONNECTION_STATUS_NOTIFY I will only make the static
> > analyzer that caught this issue happy by not calling
> > drm_dp_get_mst_branch_device_by_guid() with a NULL guid, causing
> > drm_dp_mst_process_up_req() to return in the "if (!mstb)" right
> > bellow.
> >
> > Fixes: 9408cc94eb04 ("drm/dp_mst: Handle UP requests
> > asynchronously")
> > Cc: Lyude Paul
> > Cc: Sean Paul
> > Signed-off-by: José Roberto de Souza
> > ---
> > drivers/gpu/drm/drm_dp_mst_topology.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > index 23cf46bfef74..a811247cecfe 100644
> > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > @@ -3829,7 +3829,8 @@ drm_dp_mst_process_up_req(struct
> > drm_dp_mst_topology_mgr *mgr,
> > else if (msg->req_type == DP_RESOURCE_STATUS_NOTIFY)
> > guid = msg->u.resource_stat.guid;
> >
> > - mstb = drm_dp_get_mst_branch_device_by_guid(mgr, guid);
> > + if (guid)
> > + mstb =
> > drm_dp_get_mst_branch_device_by_guid(mgr, guid);
> > } else {
> > mstb = drm_dp_get_mst_branch_device(mgr, hdr->lct, hdr-
> > > rad);
> > }
>
> Been fixing something similar in dp mst topology a while ago, was
> also
> similar NULL pointer dereference. Fix seems to be correct, however I
> would still have a look at least, how it affects overall logic then.
> I mean now we don't call drm_dp_get_mst_branch_device_by_guid if guid
> is NULL - that's ok, however it means that mstb will not get
> initialized and how this is going to affect the code flow then?
>
> SHould we may be still try to initialize mstb somehow and check
> guid actually inside of this drm_dp_get_mst_branch_device_by_guid
> function? Or call drm_dp_get_mst_branch_device?
>
> I'm not stating anything here, just asking question to
> make the overall picture bit more clear.
Well it do not matters if it set mstb if on the next block it will only
handle messages of DP_CONNECTION_STATUS_NOTIFY type but for sure we
should handle this two other message types.
>
> Anyways, even wrong logic to me is better than crashing so,
>
> Reviewed-by: Stanislav Lisovskiy
Thanks
>
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/4] drm/i915/display: Set TRANS_DDI_MODE_SELECT to default value when disabling TRANS_DDI
On Thu, 2020-01-30 at 19:25 +0200, Ville Syrjälä wrote:
> On Thu, Jan 16, 2020 at 05:58:37PM -0800, José Roberto de Souza
> wrote:
> > TGL timeouts when disabling MST transcoder and fifo underruns over
> > MST
> > transcoders are fixed when setting TRANS_DDI_MODE_SELECT to 0(HDMI
> > mode) during the disable sequence.
> >
> > Although BSpec disable sequence don't require this step it is a
> > harmless change and it is also done by Windows driver.
> > Anyhow HW team was notified about that but it can take some time to
> > documentation to be updated.
> >
> > A case that always lead to those issues is:
> > - do a modeset enabling pipe A and pipe B in the same MST stream
> > leaving A as master
> > - disable pipe A, promote B as master doing a full modeset in A
> > - enable pipe A, changing the master transcoder back to A(doing a
> > full modeset in B)
> > - Pow: underruns and timeouts
> >
> > The transcoders involved will only work again when complete
> > disabled
> > and their power wells turned off causing a reset in their
> > registers.
> >
> > Cc: Ville Syrjälä
> > Cc: Matt Roper
> > Signed-off-by: José Roberto de Souza
> > ---
> > drivers/gpu/drm/i915/display/intel_ddi.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> > b/drivers/gpu/drm/i915/display/intel_ddi.c
> > index 32ea3c7e8b62..82e90f271974 100644
> > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> > @@ -1997,6 +1997,7 @@ void intel_ddi_disable_transcoder_func(const
> > struct intel_crtc_state *crtc_state
> >
> > val = I915_READ(TRANS_DDI_FUNC_CTL(cpu_transcoder));
> > val &= ~TRANS_DDI_FUNC_ENABLE;
> > + val &= ~TRANS_DDI_MODE_SELECT_MASK;
>
> Feels a bit early since IIRC we still leave a bunch of other stuff
> enabled/selected here. In fact we don't seem to be clearing the DDI
> select
> anywhere at all? That one I would be more suspicious of than the
> mode.
> But maybe we should just clear both somewhere? I would suggest it
> should
> be when we clear the port select finally.
We are clearing DDI select, in our code it is named as
TGL_TRANS_DDI_PORT_MASK/TRANS_DDI_PORT_MASK.
For TGL in MST mode we clear DDI select in the block below for MST
slaves and then in intel_ddi_post_disable_dp() for MST master as
instructed by Display port sequences.
>
> >
> > if (INTEL_GEN(dev_priv) >= 12) {
> > if (!intel_dp_mst_is_master_trans(crtc_state))
> > --
> > 2.25.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] drm/i915/dc3co: Avoid full modeset when EXITLINE needs to be changed
On Wed, 2020-01-22 at 18:49 +0530, Anshuman Gupta wrote:
> On 2020-01-21 at 12:13:14 -0800, José Roberto de Souza wrote:
> > A recent change in BSpec allow us to change EXTLINE while
> > transcoder
> > is enabled so this allow us to change it even when doing the first
> > fastset after taking over previous hardware state set by BIOS.
> > BIOS don't enable PSR, so if sink supports PSR it will be enabled
> > on
> > the first fastset, so moving the EXTLINE compute and set to PSR
> > flows
> > allow us to simplfy a bunch of code.
> >
> > This will save a lot of time in all the IGT tests that uses CRC, as
> > when PSR2 is enabled CRCs are not generated, so we switch to PSR1,
> > so
> > the previous code would compute dc3co_exitline=0 causing a full
> > modeset that would shutdown pipe, enable and train link.
> >
> > v2: only programming EXTLINE when DC3CO is enabled
> >
> > BSpec: 49196
> > Cc: Imre Deak
> > Cc: Anshuman Gupta
> > Signed-off-by: José Roberto de Souza
> > ---
> > drivers/gpu/drm/i915/display/intel_ddi.c | 86
> >
> > drivers/gpu/drm/i915/display/intel_display.c | 1 -
> > drivers/gpu/drm/i915/display/intel_psr.c | 46 +++
> > 3 files changed, 46 insertions(+), 87 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> > b/drivers/gpu/drm/i915/display/intel_ddi.c
> > index bbf1c0a243a2..e52c3cae2965 100644
> > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> > @@ -3344,86 +3344,6 @@ static void
> > intel_ddi_disable_fec_state(struct intel_encoder *encoder,
> > POSTING_READ(intel_dp->regs.dp_tp_ctl);
> > }
> >
> > -static void
> > -tgl_clear_psr2_transcoder_exitline(const struct intel_crtc_state
> > *cstate)
> > -{
> > - struct drm_i915_private *dev_priv = to_i915(cstate->uapi.crtc-
> > >dev);
> > - u32 val;
> > -
> > - if (!cstate->dc3co_exitline)
> > - return;
> > -
> > - val = I915_READ(EXITLINE(cstate->cpu_transcoder));
> > - val &= ~(EXITLINE_MASK | EXITLINE_ENABLE);
> > - I915_WRITE(EXITLINE(cstate->cpu_transcoder), val);
> > -}
> > -
> > -static void
> > -tgl_set_psr2_transcoder_exitline(const struct intel_crtc_state
> > *cstate)
> > -{
> > - u32 val, exit_scanlines;
> > - struct drm_i915_private *dev_priv = to_i915(cstate->uapi.crtc-
> > >dev);
> > -
> > - if (!cstate->dc3co_exitline)
> > - return;
> > -
> > - exit_scanlines = cstate->dc3co_exitline;
> > - exit_scanlines <<= EXITLINE_SHIFT;
> > - val = I915_READ(EXITLINE(cstate->cpu_transcoder));
> > - val &= ~(EXITLINE_MASK | EXITLINE_ENABLE);
> > - val |= exit_scanlines;
> > - val |= EXITLINE_ENABLE;
> > - I915_WRITE(EXITLINE(cstate->cpu_transcoder), val);
> > -}
> > -
> > -static void tgl_dc3co_exitline_compute_config(struct intel_encoder
> > *encoder,
> > - struct intel_crtc_state
> > *cstate)
> > -{
> > - u32 exit_scanlines;
> > - struct drm_i915_private *dev_priv = to_i915(cstate->uapi.crtc-
> > >dev);
> > - u32 crtc_vdisplay = cstate->hw.adjusted_mode.crtc_vdisplay;
> > -
> > - cstate->dc3co_exitline = 0;
> > -
> > - if (!(dev_priv->csr.allowed_dc_mask & DC_STATE_EN_DC3CO))
> > - return;
> > -
> > - /* B.Specs:49196 DC3CO only works with pipeA and DDIA.*/
> > - if (to_intel_crtc(cstate->uapi.crtc)->pipe != PIPE_A ||
> > - encoder->port != PORT_A)
> > - return;
> > -
> > - if (!cstate->has_psr2 || !cstate->hw.active)
> > - return;
> > -
> > - /*
> > -* DC3CO Exit time 200us B.Spec 49196
> > -* PSR2 transcoder Early Exit scanlines = ROUNDUP(200 / line
> > time) + 1
> > -*/
> > - exit_scanlines =
> > - intel_usecs_to_scanlines(&cstate->hw.adjusted_mode,
> > 200) + 1;
> > -
> > - if (WARN_ON(exit_scanlines > crtc_vdisplay))
> > - return;
> > -
> > - cstate->dc3co_exitline = crtc_vdisplay - exit_scanlines;
> > - DRM_DEBUG_KMS("DC3CO exit scanlines %d\n", cstate-
> > >dc3co_exitline);
> > -}
> > -
> > -static void tgl_dc3co_exitline_get_config(struct intel_crtc_state
> > *crtc_state)
> > -{
> > - u32 val;
> > - struct drm_i915_private *dev_priv = to_i915(crtc_state-
> > >uapi.crtc->dev);
> > -
> > - if (INTEL_GEN(dev_priv) < 12)
> > - return;
> > -
> > - val = I915_READ(EXITLINE(crtc_state->cpu_transcoder));
> > -
> > - if (val & EXITLINE_ENABLE)
> > - crtc_state->dc3co_exitline = val & EXITLINE_MASK;
> > -}
> > -
> > static void tgl_ddi_pre_enable_dp(struct intel_encoder *encoder,
> > const struct intel_crtc_state
> > *crtc_state,
> > const struct drm_connector_state
> > *conn_state)
> > @@ -3436,7 +3356,6 @@ static void tgl_ddi_pre_enable_dp(struct
> > intel_encoder *encoder,
> > int level = intel_ddi_dp_level(intel_dp);
> > enum transcoder transcoder = crtc_state->cpu_transcoder;
> >
> > - tgl_set_psr2_transcoder_exitline(crtc_s
Re: Requesting commit access to libdrm
On Sun, 2019-12-29 at 16:22 +, Eric Engestrom wrote: > On Monday, 2019-12-16 16:51:28 +0000, Souza, Jose wrote: > > Hello > > > > I have being contributing to i915 for the past 2 years and part of > > my > > work is update the PCI ids of Intel devices in libdrm. > > Being able to push my reviewed patches would be really helpful, > > please > > consider this request. > > This is somewhat orthogonal to your access request, but libdrm now > uses > Merge Requests ( > https://gitlab.freedesktop.org/mesa/drm/merge_requests), > which means if you post a change and it's been reviewed, any one of > the > 100+ members can click the "merge" button for you, so not having > access > yourself shouldn't be an issue, especially with the number of Intel > devs > who do have access. So CONTRIBUTING.rst should be updated with that new option but I bet most of the devs will keep only checking the mail list. > > (It also means changes are tested (although mostly build-tested for > now) > before they are merged, which reduces the frequency of breakages, > especially subtle ones.) > > You can still request access if you want by opening an issue > (https://gitlab.freedesktop.org/mesa/drm/issues/new), but since you > have > very few commits you'll need approval from another member; I suggest > you > cc Lucas (@demarchi) & Rodrigo (@vivijim) by tagging them in your > issue. That should also be in CONTRIBUTING.rst > > Hope this helps :) I will talk with Lucas and Rodrigo, thanks for bringing light to the new process Thanks > > Cheers, > Eric ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm] intel: sync i915_pciids.h with kernel
On Thu, 2019-12-12 at 09:17 -0800, Matt Roper wrote:
> On Tue, Dec 10, 2019 at 12:06:11PM -0800, José Roberto de Souza
> wrote:
> > It is missing the new EHL/JSL PCI ids added in commit
> > 651cc835d5f6 ("drm/i915: Add new EHL/JSL PCI ids")
> >
> > Cc: James Ausmus
> > Cc: Matt Roper
> > Signed-off-by: José Roberto de Souza
>
> Matches the kernel and the bspec.
>
> Reviewed-by: Matt Roper
Thanks for the review.
I just requested libdrm commit access in the mean time could someone
push this?
Thanks
>
> > ---
> > intel/i915_pciids.h | 7 +--
> > 1 file changed, 5 insertions(+), 2 deletions(-)
> >
> > diff --git a/intel/i915_pciids.h b/intel/i915_pciids.h
> > index b1f66b11..3e26a917 100644
> > --- a/intel/i915_pciids.h
> > +++ b/intel/i915_pciids.h
> > @@ -579,12 +579,15 @@
> > INTEL_VGA_DEVICE(0x8A51, info), \
> > INTEL_VGA_DEVICE(0x8A5D, info)
> >
> > -/* EHL */
> > +/* EHL/JSL */
> > #define INTEL_EHL_IDS(info) \
> > INTEL_VGA_DEVICE(0x4500, info), \
> > INTEL_VGA_DEVICE(0x4571, info), \
> > INTEL_VGA_DEVICE(0x4551, info), \
> > - INTEL_VGA_DEVICE(0x4541, info)
> > + INTEL_VGA_DEVICE(0x4541, info), \
> > + INTEL_VGA_DEVICE(0x4E71, info), \
> > + INTEL_VGA_DEVICE(0x4E61, info), \
> > + INTEL_VGA_DEVICE(0x4E51, info)
> >
> > /* TGL */
> > #define INTEL_TGL_12_IDS(info) \
> > --
> > 2.24.0
> >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Requesting commit access to libdrm
Hello I have being contributing to i915 for the past 2 years and part of my work is update the PCI ids of Intel devices in libdrm. Being able to push my reviewed patches would be really helpful, please consider this request. Thanks ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 5/5] drm/i915: Introduce intel_plane_state_reset()
On Thu, 2019-11-07 at 16:24 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> For the sake of symmetry with the crtc stuff let's add
> a helper to reset the plane state to sane default values.
> For the moment this only gets caller from the plane init.
>
Reviewed-by: José Roberto de Souza
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_atomic_plane.c | 15
> +--
> 1 file changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> index 42b3b3449d2e..9429b8e17270 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> @@ -41,6 +41,16 @@
> #include "intel_pm.h"
> #include "intel_sprite.h"
>
> +static void intel_plane_state_reset(struct intel_plane_state
> *plane_state,
> + struct intel_plane *plane)
> +{
> + memset(plane_state, 0, sizeof(*plane_state));
> +
> + __drm_atomic_helper_plane_state_reset(&plane_state->uapi,
> &plane->base);
> +
> + plane_state->scaler_id = -1;
> +}
> +
> struct intel_plane *intel_plane_alloc(void)
> {
> struct intel_plane_state *plane_state;
> @@ -56,8 +66,9 @@ struct intel_plane *intel_plane_alloc(void)
> return ERR_PTR(-ENOMEM);
> }
>
> - __drm_atomic_helper_plane_reset(&plane->base, &plane_state-
> >uapi);
> - plane_state->scaler_id = -1;
> + intel_plane_state_reset(plane_state, plane);
> +
> + plane->base.state = &plane_state->uapi;
>
> return plane;
> }
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 4/5] drm/i915: Introduce intel_crtc_state_reset()
On Thu, 2019-11-07 at 16:24 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We have a few places where we want to reset a crtc state to its
> default values. Let's add a helper for that. We'll need the new
> __drm_atomic_helper_crtc_state_reset() helper for this to allow
> us to just reset the state itself without clobbering the
> crtc->state pointer.
>
> And while at it let's zero out the whole thing, except a few
> choice member which we'll mark as "invalid". And thanks to this
> we can now nuke intel_crtc_init_scalers().
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 47 +-
> --
> 1 file changed, 22 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index e6291841053f..fd4120533c3f 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -164,7 +164,6 @@ static void vlv_prepare_pll(struct intel_crtc
> *crtc,
> const struct intel_crtc_state
> *pipe_config);
> static void chv_prepare_pll(struct intel_crtc *crtc,
> const struct intel_crtc_state
> *pipe_config);
> -static void intel_crtc_init_scalers(struct intel_crtc_state
> *crtc_state);
> static void skylake_pfit_enable(const struct intel_crtc_state
> *crtc_state);
> static void ironlake_pfit_disable(const struct intel_crtc_state
> *old_crtc_state);
> static void ironlake_pfit_enable(const struct intel_crtc_state
> *crtc_state);
> @@ -10655,8 +10654,6 @@ static bool haswell_get_pipe_config(struct
> intel_crtc *crtc,
> u64 power_domain_mask;
> bool active;
>
> - intel_crtc_init_scalers(pipe_config);
> -
> pipe_config->master_transcoder = INVALID_TRANSCODER;
>
> power_domain = POWER_DOMAIN_PIPE(crtc->pipe);
> @@ -11704,6 +11701,20 @@ static void ironlake_pch_clock_get(struct
> intel_crtc *crtc,
>&pipe_config->fdi_m_n);
> }
>
> +static void intel_crtc_state_reset(struct intel_crtc_state
> *crtc_state,
> +struct intel_crtc *crtc)
> +{
> + memset(crtc_state, 0, sizeof(*crtc_state));
> +
> + __drm_atomic_helper_crtc_state_reset(&crtc_state->uapi, &crtc-
> >base);
> +
> + crtc_state->cpu_transcoder = INVALID_TRANSCODER;
> + crtc_state->master_transcoder = INVALID_TRANSCODER;
At least master_transcoder is set to invalid again but we can remove
the redundant sets later
Reviewed-by: José Roberto de Souza
> + crtc_state->hsw_workaround_pipe = INVALID_PIPE;
> + crtc_state->output_format = INTEL_OUTPUT_FORMAT_INVALID;
> + crtc_state->scaler_state.scaler_id = -1;
> +}
> +
> /* Returns the currently programmed mode of the given encoder. */
> struct drm_display_mode *
> intel_encoder_current_mode(struct intel_encoder *encoder)
> @@ -11729,7 +11740,7 @@ intel_encoder_current_mode(struct
> intel_encoder *encoder)
> return NULL;
> }
>
> - crtc_state->uapi.crtc = &crtc->base;
> + intel_crtc_state_reset(crtc_state, crtc);
>
> if (!dev_priv->display.get_pipe_config(crtc, crtc_state)) {
> kfree(crtc_state);
> @@ -13577,18 +13588,14 @@ verify_crtc_state(struct intel_crtc *crtc,
> struct drm_device *dev = crtc->base.dev;
> struct drm_i915_private *dev_priv = to_i915(dev);
> struct intel_encoder *encoder;
> - struct intel_crtc_state *pipe_config;
> - struct drm_atomic_state *state;
> + struct intel_crtc_state *pipe_config = old_crtc_state;
> + struct drm_atomic_state *state = old_crtc_state->uapi.state;
> bool active;
>
> - state = old_crtc_state->uapi.state;
> __drm_atomic_helper_crtc_destroy_state(&old_crtc_state->uapi);
> intel_crtc_free_hw_state(old_crtc_state);
> -
> - pipe_config = old_crtc_state;
> - memset(pipe_config, 0, sizeof(*pipe_config));
> - pipe_config->uapi.crtc = &crtc->base;
> - pipe_config->uapi.state = state;
> + intel_crtc_state_reset(old_crtc_state, crtc);
> + old_crtc_state->uapi.state = state;
>
> DRM_DEBUG_KMS("[CRTC:%d:%s]\n", crtc->base.base.id, crtc-
> >base.name);
>
> @@ -15745,15 +15752,6 @@ intel_cursor_plane_create(struct
> drm_i915_private *dev_priv,
> return ERR_PTR(ret);
> }
>
> -static void intel_crtc_init_scalers(struct intel_crtc_state
> *crtc_state)
> -{
> - struct intel_crtc_scaler_state *scaler_state =
> - &crtc_state->scaler_state;
> -
> - memset(scaler_state, 0, sizeof(*scaler_state));
> - scaler_state->scaler_id = -1;
> -}
> -
> #define INTEL_CRTC_FUNCS \
> .gamma_set = drm_atomic_helper_legacy_gamma_set, \
> .set_config = drm_atomic_helper_set_config, \
> @@ -15836,9 +15834,9 @@ static struct intel_crtc
> *intel_crtc_alloc(void)
> return ERR_PTR(-ENOMEM);
> }
>
> - __drm_atomic_helper_crtc_reset(&crtc->base,
Re: [Intel-gfx] [PATCH 2/5] drm/i915: s/intel_crtc/crtc/ in intel_crtc_init()
On Thu, 2019-11-07 at 16:24 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Let's get rid of the redundant intel_ prefix on our variables.
>
Reviewed-by: José Roberto de Souza
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 32 ++--
>
> 1 file changed, 16 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 551de2baa569..8b889c9f29b5 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -15838,14 +15838,14 @@ static const struct drm_crtc_funcs
> i8xx_crtc_funcs = {
> static int intel_crtc_init(struct drm_i915_private *dev_priv, enum
> pipe pipe)
> {
> const struct drm_crtc_funcs *funcs;
> - struct intel_crtc *intel_crtc;
> + struct intel_crtc *crtc;
> struct intel_crtc_state *crtc_state = NULL;
> struct intel_plane *primary = NULL;
> struct intel_plane *cursor = NULL;
> int sprite, ret;
>
> - intel_crtc = kzalloc(sizeof(*intel_crtc), GFP_KERNEL);
> - if (!intel_crtc)
> + crtc = kzalloc(sizeof(*crtc), GFP_KERNEL);
> + if (!crtc)
> return -ENOMEM;
>
> crtc_state = kzalloc(sizeof(*crtc_state), GFP_KERNEL);
> @@ -15853,15 +15853,15 @@ static int intel_crtc_init(struct
> drm_i915_private *dev_priv, enum pipe pipe)
> ret = -ENOMEM;
> goto fail;
> }
> - __drm_atomic_helper_crtc_reset(&intel_crtc->base, &crtc_state-
> >uapi);
> - intel_crtc->config = crtc_state;
> + __drm_atomic_helper_crtc_reset(&crtc->base, &crtc_state->uapi);
> + crtc->config = crtc_state;
>
> primary = intel_primary_plane_create(dev_priv, pipe);
> if (IS_ERR(primary)) {
> ret = PTR_ERR(primary);
> goto fail;
> }
> - intel_crtc->plane_ids_mask |= BIT(primary->id);
> + crtc->plane_ids_mask |= BIT(primary->id);
>
> for_each_sprite(dev_priv, pipe, sprite) {
> struct intel_plane *plane;
> @@ -15871,7 +15871,7 @@ static int intel_crtc_init(struct
> drm_i915_private *dev_priv, enum pipe pipe)
> ret = PTR_ERR(plane);
> goto fail;
> }
> - intel_crtc->plane_ids_mask |= BIT(plane->id);
> + crtc->plane_ids_mask |= BIT(plane->id);
> }
>
> cursor = intel_cursor_plane_create(dev_priv, pipe);
> @@ -15879,7 +15879,7 @@ static int intel_crtc_init(struct
> drm_i915_private *dev_priv, enum pipe pipe)
> ret = PTR_ERR(cursor);
> goto fail;
> }
> - intel_crtc->plane_ids_mask |= BIT(cursor->id);
> + crtc->plane_ids_mask |= BIT(cursor->id);
>
> if (HAS_GMCH(dev_priv)) {
> if (IS_CHERRYVIEW(dev_priv) ||
> @@ -15900,32 +15900,32 @@ static int intel_crtc_init(struct
> drm_i915_private *dev_priv, enum pipe pipe)
> funcs = &ilk_crtc_funcs;
> }
>
> - ret = drm_crtc_init_with_planes(&dev_priv->drm, &intel_crtc-
> >base,
> + ret = drm_crtc_init_with_planes(&dev_priv->drm, &crtc->base,
> &primary->base, &cursor->base,
> funcs, "pipe %c",
> pipe_name(pipe));
> if (ret)
> goto fail;
>
> - intel_crtc->pipe = pipe;
> + crtc->pipe = pipe;
>
> /* initialize shared scalers */
> - intel_crtc_init_scalers(intel_crtc, crtc_state);
> + intel_crtc_init_scalers(crtc, crtc_state);
>
> BUG_ON(pipe >= ARRAY_SIZE(dev_priv->pipe_to_crtc_mapping) ||
> dev_priv->pipe_to_crtc_mapping[pipe] != NULL);
> - dev_priv->pipe_to_crtc_mapping[pipe] = intel_crtc;
> + dev_priv->pipe_to_crtc_mapping[pipe] = crtc;
>
> if (INTEL_GEN(dev_priv) < 9) {
> enum i9xx_plane_id i9xx_plane = primary->i9xx_plane;
>
> BUG_ON(i9xx_plane >= ARRAY_SIZE(dev_priv-
> >plane_to_crtc_mapping) ||
> dev_priv->plane_to_crtc_mapping[i9xx_plane] !=
> NULL);
> - dev_priv->plane_to_crtc_mapping[i9xx_plane] =
> intel_crtc;
> + dev_priv->plane_to_crtc_mapping[i9xx_plane] = crtc;
> }
>
> - intel_color_init(intel_crtc);
> + intel_color_init(crtc);
>
> - WARN_ON(drm_crtc_index(&intel_crtc->base) != intel_crtc->pipe);
> + WARN_ON(drm_crtc_index(&crtc->base) != crtc->pipe);
>
> return 0;
>
> @@ -15935,7 +15935,7 @@ static int intel_crtc_init(struct
> drm_i915_private *dev_priv, enum pipe pipe)
>* crtcs/planes already initialized.
>*/
> kfree(crtc_state);
> - kfree(intel_crtc);
> + kfree(crtc);
>
> return ret;
> }
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/5] drm/i915: Introduce intel_crtc_{alloc,free}()
On Thu, 2019-11-07 at 16:24 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We already have alloc/free helpers for planes, add the same for
> crtcs. The main benefit is we get to move all the annoying state
> initialization out of the main crtc_init() flow.
>
Reviewed-by: José Roberto de Souza
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 74 ++--
>
> 1 file changed, 36 insertions(+), 38 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 8b889c9f29b5..e6291841053f 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -164,8 +164,7 @@ static void vlv_prepare_pll(struct intel_crtc
> *crtc,
> const struct intel_crtc_state
> *pipe_config);
> static void chv_prepare_pll(struct intel_crtc *crtc,
> const struct intel_crtc_state
> *pipe_config);
> -static void intel_crtc_init_scalers(struct intel_crtc *crtc,
> - struct intel_crtc_state
> *crtc_state);
> +static void intel_crtc_init_scalers(struct intel_crtc_state
> *crtc_state);
> static void skylake_pfit_enable(const struct intel_crtc_state
> *crtc_state);
> static void ironlake_pfit_disable(const struct intel_crtc_state
> *old_crtc_state);
> static void ironlake_pfit_enable(const struct intel_crtc_state
> *crtc_state);
> @@ -10656,7 +10655,7 @@ static bool haswell_get_pipe_config(struct
> intel_crtc *crtc,
> u64 power_domain_mask;
> bool active;
>
> - intel_crtc_init_scalers(crtc, pipe_config);
> + intel_crtc_init_scalers(pipe_config);
>
> pipe_config->master_transcoder = INVALID_TRANSCODER;
>
> @@ -15746,25 +15745,12 @@ intel_cursor_plane_create(struct
> drm_i915_private *dev_priv,
> return ERR_PTR(ret);
> }
>
> -static void intel_crtc_init_scalers(struct intel_crtc *crtc,
> - struct intel_crtc_state
> *crtc_state)
> +static void intel_crtc_init_scalers(struct intel_crtc_state
> *crtc_state)
> {
> struct intel_crtc_scaler_state *scaler_state =
> &crtc_state->scaler_state;
> - struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> - int i;
> -
> - crtc->num_scalers = RUNTIME_INFO(dev_priv)->num_scalers[crtc-
> >pipe];
> - if (!crtc->num_scalers)
> - return;
> -
> - for (i = 0; i < crtc->num_scalers; i++) {
> - struct intel_scaler *scaler = &scaler_state-
> >scalers[i];
> -
> - scaler->in_use = 0;
> - scaler->mode = 0;
> - }
>
> + memset(scaler_state, 0, sizeof(*scaler_state));
> scaler_state->scaler_id = -1;
> }
>
> @@ -15835,27 +15821,49 @@ static const struct drm_crtc_funcs
> i8xx_crtc_funcs = {
> .disable_vblank = i8xx_disable_vblank,
> };
>
> -static int intel_crtc_init(struct drm_i915_private *dev_priv, enum
> pipe pipe)
> +static struct intel_crtc *intel_crtc_alloc(void)
> {
> - const struct drm_crtc_funcs *funcs;
> + struct intel_crtc_state *crtc_state;
> struct intel_crtc *crtc;
> - struct intel_crtc_state *crtc_state = NULL;
> - struct intel_plane *primary = NULL;
> - struct intel_plane *cursor = NULL;
> - int sprite, ret;
>
> crtc = kzalloc(sizeof(*crtc), GFP_KERNEL);
> if (!crtc)
> - return -ENOMEM;
> + return ERR_PTR(-ENOMEM);
>
> crtc_state = kzalloc(sizeof(*crtc_state), GFP_KERNEL);
> if (!crtc_state) {
> - ret = -ENOMEM;
> - goto fail;
> + kfree(crtc);
> + return ERR_PTR(-ENOMEM);
> }
> +
> __drm_atomic_helper_crtc_reset(&crtc->base, &crtc_state->uapi);
> + intel_crtc_init_scalers(crtc_state);
> +
> crtc->config = crtc_state;
>
> + return crtc;
> +}
> +
> +static void intel_crtc_free(struct intel_crtc *crtc)
> +{
> + intel_crtc_destroy_state(&crtc->base, crtc->base.state);
> + kfree(crtc);
> +}
> +
> +static int intel_crtc_init(struct drm_i915_private *dev_priv, enum
> pipe pipe)
> +{
> + struct intel_plane *primary, *cursor;
> + const struct drm_crtc_funcs *funcs;
> + struct intel_crtc *crtc;
> + int sprite, ret;
> +
> + crtc = intel_crtc_alloc();
> + if (IS_ERR(crtc))
> + return PTR_ERR(crtc);
> +
> + crtc->pipe = pipe;
> + crtc->num_scalers = RUNTIME_INFO(dev_priv)->num_scalers[pipe];
> +
> primary = intel_primary_plane_create(dev_priv, pipe);
> if (IS_ERR(primary)) {
> ret = PTR_ERR(primary);
> @@ -15906,11 +15914,6 @@ static int intel_crtc_init(struct
> drm_i915_private *dev_priv, enum pipe pipe)
> if (ret)
> goto fail;
>
> - crtc->pipe = pipe;
> -
> - /* initialize shared scalers */
> - intel_crtc_init_scalers(crtc, crtc_state);
> -
> BUG_ON(pipe >= ARRAY_SIZE(dev_priv->pipe_t
Re: [PATCH] drm/crtc-helper: drm_connector_get_single_encoder prototype is missing
On Tue, 2019-11-19 at 13:58 +0100, Benjamin Gaignard wrote:
> Include drm_crtc_helper_internal.h to provide
> drm_connector_get_single_encoder
> prototype.
>
> Fixes: a92462d6bf493 ("drm/connector: Share with non-atomic drivers
> the function to get the single encoder")
drm_connector_get_single_encoder() is implemented before the use in
this file so it is not broken, no need of a fixes tag.
Reviewed-by: José Roberto de Souza
>
> Cc: José Roberto de Souza
>
> Signed-off-by: Benjamin Gaignard
> ---
> drivers/gpu/drm/drm_crtc_helper.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_crtc_helper.c
> b/drivers/gpu/drm/drm_crtc_helper.c
> index 499b05aaccfc..93a4eec429e8 100644
> --- a/drivers/gpu/drm/drm_crtc_helper.c
> +++ b/drivers/gpu/drm/drm_crtc_helper.c
> @@ -48,6 +48,8 @@
> #include
> #include
>
> +#include "drm_crtc_helper_internal.h"
> +
> /**
> * DOC: overview
> *
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [CI,1/2] drm/connector: Share with non-atomic drivers the function to get the single encoder
On Mon, 2019-09-16 at 12:39 -0700, Manasi Navare wrote: > On Mon, Sep 16, 2019 at 07:34:32PM +0000, Souza, Jose wrote: > > Someone with drm-misc commit access could push this? > > > > Sure will push this series. Thanks Manasi > > Manasi > > > Thanks > > > > On Sun, 2019-09-15 at 11:36 +, Patchwork wrote: > > > == Series Details == > > > > > > Series: series starting with [CI,1/2] drm/connector: Share with > > > non- > > > atomic drivers the function to get the single encoder > > > URL : https://patchwork.freedesktop.org/series/66701/ > > > State : success > > > > > > == Summary == > > > > > > CI Bug Log - changes from CI_DRM_6894_full -> > > > Patchwork_14412_full > > > > > > > > > Summary > > > --- > > > > > > **SUCCESS** > > > > > > No regressions found. > > > > > > > > > > > > Known issues > > > > > > > > > Here are the changes found in Patchwork_14412_full that come > > > from > > > known issues: > > > > > > ### IGT changes ### > > > > > > Issues hit > > > > > > * igt@gem_exec_schedule@preempt-contexts-bsd2: > > > - shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#109276]) > > > +14 > > > similar issues > > >[1]: > > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-iclb1/igt@gem_exec_sched...@preempt-contexts-bsd2.html > > >[2]: > > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-iclb7/igt@gem_exec_sched...@preempt-contexts-bsd2.html > > > > > > * igt@gem_exec_schedule@preemptive-hang-bsd: > > > - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#111325]) > > > +3 > > > similar issues > > >[3]: > > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-iclb6/igt@gem_exec_sched...@preemptive-hang-bsd.html > > >[4]: > > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-iclb4/igt@gem_exec_sched...@preemptive-hang-bsd.html > > > > > > * igt@i915_pm_rpm@modeset-stress-extra-wait: > > > - shard-glk: [PASS][5] -> [DMESG-WARN][6] > > > ([fdo#105763] > > > / [fdo#106538]) > > >[5]: > > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-glk7/igt@i915_pm_...@modeset-stress-extra-wait.html > > >[6]: > > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-glk8/igt@i915_pm_...@modeset-stress-extra-wait.html > > > > > > * igt@i915_suspend@fence-restore-tiled2untiled: > > > - shard-apl: [PASS][7] -> [DMESG-WARN][8] > > > ([fdo#108566]) > > > +3 similar issues > > >[7]: > > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-apl1/igt@i915_susp...@fence-restore-tiled2untiled.html > > >[8]: > > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-apl7/igt@i915_susp...@fence-restore-tiled2untiled.html > > > > > > * igt@kms_cursor_crc@pipe-b-cursor-alpha-transparent: > > > - shard-snb: [PASS][9] -> [SKIP][10] ([fdo#109271]) > > >[9]: > > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-snb5/igt@kms_cursor_...@pipe-b-cursor-alpha-transparent.html > > >[10]: > > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-snb7/igt@kms_cursor_...@pipe-b-cursor-alpha-transparent.html > > > > > > * igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy: > > > - shard-hsw: [PASS][11] -> [FAIL][12] ([fdo#105767]) > > >[11]: > > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-hsw6/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-legacy.html > > >[12]: > > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-hsw1/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-legacy.html > > > > > > * igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: > > > - shard-glk: [PASS][13] -> [FAIL][14] ([fdo#105363]) > > >[13]: > > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-glk8/igt@kms_f...@2x-flip-vs-expired-vblank-interruptible.html > > >[14]: > > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-glk2/igt@kms_f...@2x-flip-vs-expired-vblank-interruptible.h
Re: ✓ Fi.CI.IGT: success for series starting with [CI,1/2] drm/connector: Share with non-atomic drivers the function to get the single encoder
Someone with drm-misc commit access could push this? Thanks On Sun, 2019-09-15 at 11:36 +, Patchwork wrote: > == Series Details == > > Series: series starting with [CI,1/2] drm/connector: Share with non- > atomic drivers the function to get the single encoder > URL : https://patchwork.freedesktop.org/series/66701/ > State : success > > == Summary == > > CI Bug Log - changes from CI_DRM_6894_full -> Patchwork_14412_full > > > Summary > --- > > **SUCCESS** > > No regressions found. > > > > Known issues > > > Here are the changes found in Patchwork_14412_full that come from > known issues: > > ### IGT changes ### > > Issues hit > > * igt@gem_exec_schedule@preempt-contexts-bsd2: > - shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#109276]) +14 > similar issues >[1]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-iclb1/igt@gem_exec_sched...@preempt-contexts-bsd2.html >[2]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-iclb7/igt@gem_exec_sched...@preempt-contexts-bsd2.html > > * igt@gem_exec_schedule@preemptive-hang-bsd: > - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#111325]) +3 > similar issues >[3]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-iclb6/igt@gem_exec_sched...@preemptive-hang-bsd.html >[4]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-iclb4/igt@gem_exec_sched...@preemptive-hang-bsd.html > > * igt@i915_pm_rpm@modeset-stress-extra-wait: > - shard-glk: [PASS][5] -> [DMESG-WARN][6] ([fdo#105763] > / [fdo#106538]) >[5]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-glk7/igt@i915_pm_...@modeset-stress-extra-wait.html >[6]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-glk8/igt@i915_pm_...@modeset-stress-extra-wait.html > > * igt@i915_suspend@fence-restore-tiled2untiled: > - shard-apl: [PASS][7] -> [DMESG-WARN][8] ([fdo#108566]) > +3 similar issues >[7]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-apl1/igt@i915_susp...@fence-restore-tiled2untiled.html >[8]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-apl7/igt@i915_susp...@fence-restore-tiled2untiled.html > > * igt@kms_cursor_crc@pipe-b-cursor-alpha-transparent: > - shard-snb: [PASS][9] -> [SKIP][10] ([fdo#109271]) >[9]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-snb5/igt@kms_cursor_...@pipe-b-cursor-alpha-transparent.html >[10]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-snb7/igt@kms_cursor_...@pipe-b-cursor-alpha-transparent.html > > * igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy: > - shard-hsw: [PASS][11] -> [FAIL][12] ([fdo#105767]) >[11]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-hsw6/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-legacy.html >[12]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-hsw1/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-legacy.html > > * igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: > - shard-glk: [PASS][13] -> [FAIL][14] ([fdo#105363]) >[13]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-glk8/igt@kms_f...@2x-flip-vs-expired-vblank-interruptible.html >[14]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-glk2/igt@kms_f...@2x-flip-vs-expired-vblank-interruptible.html > > * igt@kms_flip@basic-flip-vs-modeset: > - shard-apl: [PASS][15] -> [INCOMPLETE][16] > ([fdo#103927]) >[15]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-apl7/igt@kms_f...@basic-flip-vs-modeset.html >[16]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-apl3/igt@kms_f...@basic-flip-vs-modeset.html > > * igt@kms_flip@flip-vs-expired-vblank-interruptible: > - shard-apl: [PASS][17] -> [FAIL][18] ([fdo#105363]) >[17]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-apl1/igt@kms_f...@flip-vs-expired-vblank-interruptible.html >[18]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-apl3/igt@kms_f...@flip-vs-expired-vblank-interruptible.html > > * igt@kms > _frontbuffer_tracking@fbcpsr-1p-primscrn-pri-indfb-draw-pwrite: > - shard-iclb: [PASS][19] -> [FAIL][20] ([fdo#103167]) +7 > similar issues >[19]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-iclb8/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-indfb-draw-pwrite.html >[20]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-iclb2/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-indfb-draw-pwrite.html > > * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes: > - shard-skl: [PASS][21] -> [INCOMPLETE][22] > ([fdo#104108]) >[21]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/s
Re: [PATCH 1/2] drm/connector: Share with non-atomic drivers the function to get the single encoder
On Wed, 2019-09-11 at 21:10 +0300, Ville Syrjälä wrote:
> On Wed, Sep 11, 2019 at 10:56:02AM -0700, José Roberto de Souza
> wrote:
> > This 3 non-atomic drivers all have the same function getting the
> > only encoder available in the connector, also atomic drivers have
> > this fallback. So moving it a common place and sharing between
> > atomic
> > and non-atomic drivers.
> >
> > While at it I also removed the mention of
> > drm_atomic_helper_best_encoder() that was renamed in
> > commit 297e30b5d9b6 ("drm/atomic-helper: Unexport
> > drm_atomic_helper_best_encoder").
> >
> > Suggested-by: Ville Syrjälä
> > Cc: Ville Syrjälä
> > Cc: Daniel Vetter
> > Cc: Laurent Pinchart
> > Cc: dri-devel@lists.freedesktop.org
> > Cc: intel-...@lists.freedesktop.org
> > Signed-off-by: José Roberto de Souza
> > ---
> > drivers/gpu/drm/ast/ast_mode.c | 12
> > drivers/gpu/drm/drm_atomic_helper.c | 15 ++-
> > drivers/gpu/drm/drm_connector.c | 11 +++
> > drivers/gpu/drm/drm_crtc_helper.c| 8 +++-
> > drivers/gpu/drm/drm_crtc_internal.h | 2 ++
> > drivers/gpu/drm/mgag200/mgag200_mode.c | 11 ---
> > drivers/gpu/drm/udl/udl_connector.c | 8
> > include/drm/drm_modeset_helper_vtables.h | 6 +++---
> > 8 files changed, 25 insertions(+), 48 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/ast/ast_mode.c
> > b/drivers/gpu/drm/ast/ast_mode.c
> > index d349c721501c..eef95e1af06b 100644
> > --- a/drivers/gpu/drm/ast/ast_mode.c
> > +++ b/drivers/gpu/drm/ast/ast_mode.c
> > @@ -687,17 +687,6 @@ static void ast_encoder_destroy(struct
> > drm_encoder *encoder)
> > kfree(encoder);
> > }
> >
> > -
> > -static struct drm_encoder *ast_best_single_encoder(struct
> > drm_connector *connector)
> > -{
> > - int enc_id = connector->encoder_ids[0];
> > - /* pick the encoder ids */
> > - if (enc_id)
> > - return drm_encoder_find(connector->dev, NULL, enc_id);
> > - return NULL;
> > -}
> > -
> > -
> > static const struct drm_encoder_funcs ast_enc_funcs = {
> > .destroy = ast_encoder_destroy,
> > };
> > @@ -847,7 +836,6 @@ static void ast_connector_destroy(struct
> > drm_connector *connector)
> > static const struct drm_connector_helper_funcs
> > ast_connector_helper_funcs = {
> > .mode_valid = ast_mode_valid,
> > .get_modes = ast_get_modes,
> > - .best_encoder = ast_best_single_encoder,
> > };
> >
> > static const struct drm_connector_funcs ast_connector_funcs = {
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > b/drivers/gpu/drm/drm_atomic_helper.c
> > index 4706439fb490..9d7e4da6c292 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -97,17 +97,6 @@ drm_atomic_helper_plane_changed(struct
> > drm_atomic_state *state,
> > }
> > }
> >
> > -/*
> > - * For connectors that support multiple encoders, either the
> > - * .atomic_best_encoder() or .best_encoder() operation must be
> > implemented.
> > - */
> > -static struct drm_encoder *
> > -pick_single_encoder_for_connector(struct drm_connector *connector)
> > -{
> > - WARN_ON(connector->encoder_ids[1]);
> > - return drm_encoder_find(connector->dev, NULL, connector-
> > >encoder_ids[0]);
> > -}
> > -
> > static int handle_conflicting_encoders(struct drm_atomic_state
> > *state,
> >bool
> > disable_conflicting_encoders)
> > {
> > @@ -135,7 +124,7 @@ static int handle_conflicting_encoders(struct
> > drm_atomic_state *state,
> > else if (funcs->best_encoder)
> > new_encoder = funcs->best_encoder(connector);
> > else
> > - new_encoder =
> > pick_single_encoder_for_connector(connector);
> > + new_encoder =
> > drm_connector_get_single_encoder(connector);
> >
> > if (new_encoder) {
> > if (encoder_mask &
> > drm_encoder_mask(new_encoder)) {
> > @@ -359,7 +348,7 @@ update_connector_routing(struct
> > drm_atomic_state *state,
> > else if (funcs->best_encoder)
> > new_encoder = funcs->best_encoder(connector);
> > else
> > - new_encoder =
> > pick_single_encoder_for_connector(connector);
> > + new_encoder =
> > drm_connector_get_single_encoder(connector);
> >
> > if (!new_encoder) {
> > DRM_DEBUG_ATOMIC("No suitable encoder found for
> > [CONNECTOR:%d:%s]\n",
> > diff --git a/drivers/gpu/drm/drm_connector.c
> > b/drivers/gpu/drm/drm_connector.c
> > index 4c766624b20d..3e2a632cf861 100644
> > --- a/drivers/gpu/drm/drm_connector.c
> > +++ b/drivers/gpu/drm/drm_connector.c
> > @@ -2334,3 +2334,14 @@ struct drm_tile_group
> > *drm_mode_create_tile_group(struct drm_device *dev,
> > return tg;
> > }
> > EXPORT_SYMBOL(drm_mode_create_tile_group);
> > +
> > +/*
> > + * For connectors that support multiple encoders, either the
> > + * .atomic_best_encoder() or .best_encoder() operati
Re: [PATCH v2] drm/connector: Allow max possible encoders to attach to a connector
On Fri, 2019-09-06 at 14:27 +0300, Ville Syrjälä wrote:
> On Thu, Sep 05, 2019 at 02:09:27PM -0700, José Roberto de Souza
> wrote:
> > From: Dhinakaran Pandiyan
> >
> > Currently we restrict the number of encoders that can be linked to
> > a connector to 3, increase it to match the maximum number of
> > encoders
> > that can be initialized(32).
> >
> > To more effiently do that lets switch from an array of encoder ids
> > to
> > bitmask.
> >
> > Also removing the best_encoder hook from the drivers that only have
> > one encoder per connector(this ones have one encoder in the whole
> > driver), pick_single_encoder_for_connector() will do the same job
> > with no functional change.
>
> I don't think non-atomic drivers have that fallback in place.
> They probable should...
Nice catch, thanks I will bring it back as it was removed from non-
atomic drivers.
>
> Apart from that lgtm
> Reviewed-by: Ville Syrjälä
>
> > v2: Fixing missed return on amdgpu_dm_connector_to_encoder()
> >
> > Suggested-by: Ville Syrjälä
> > Cc: Ville Syrjälä
> > Cc: Alex Deucher
> > Cc: dri-devel@lists.freedesktop.org
> > Cc: intel-...@lists.freedesktop.org
> > Cc: nouv...@lists.freedesktop.org
> > Cc: amd-...@lists.freedesktop.org
> > Signed-off-by: Dhinakaran Pandiyan
> > Signed-off-by: José Roberto de Souza
> > ---
> > .../gpu/drm/amd/amdgpu/amdgpu_connectors.c| 23 +-
> > drivers/gpu/drm/amd/amdgpu/dce_virtual.c | 5 ++-
> > .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 6 +++-
> > drivers/gpu/drm/ast/ast_mode.c| 12 ---
> > drivers/gpu/drm/drm_atomic_helper.c | 9 --
> > drivers/gpu/drm/drm_client_modeset.c | 3 +-
> > drivers/gpu/drm/drm_connector.c | 31 +
> > --
> > drivers/gpu/drm/drm_probe_helper.c| 3 +-
> > drivers/gpu/drm/mgag200/mgag200_mode.c| 11 ---
> > drivers/gpu/drm/nouveau/dispnv04/disp.c | 2 +-
> > drivers/gpu/drm/nouveau/dispnv50/disp.c | 2 +-
> > drivers/gpu/drm/nouveau/nouveau_connector.c | 7 ++---
> > drivers/gpu/drm/radeon/radeon_connectors.c| 27 ++-
> > -
> > drivers/gpu/drm/udl/udl_connector.c | 8 -
> > include/drm/drm_connector.h | 18 +--
> > 15 files changed, 53 insertions(+), 114 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> > index ece55c8fa673..d8729285f731 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> > @@ -217,11 +217,10 @@ amdgpu_connector_update_scratch_regs(struct
> > drm_connector *connector,
> > struct drm_encoder *encoder;
> > const struct drm_connector_helper_funcs *connector_funcs =
> > connector->helper_private;
> > bool connected;
> > - int i;
> >
> > best_encoder = connector_funcs->best_encoder(connector);
> >
> > - drm_connector_for_each_possible_encoder(connector, encoder, i)
> > {
> > + drm_connector_for_each_possible_encoder(connector, encoder) {
> > if ((encoder == best_encoder) && (status ==
> > connector_status_connected))
> > connected = true;
> > else
> > @@ -236,9 +235,8 @@ amdgpu_connector_find_encoder(struct
> > drm_connector *connector,
> >int encoder_type)
> > {
> > struct drm_encoder *encoder;
> > - int i;
> >
> > - drm_connector_for_each_possible_encoder(connector, encoder, i)
> > {
> > + drm_connector_for_each_possible_encoder(connector, encoder) {
> > if (encoder->encoder_type == encoder_type)
> > return encoder;
> > }
> > @@ -347,10 +345,9 @@ static struct drm_encoder *
> > amdgpu_connector_best_single_encoder(struct drm_connector
> > *connector)
> > {
> > struct drm_encoder *encoder;
> > - int i;
> >
> > /* pick the first one */
> > - drm_connector_for_each_possible_encoder(connector, encoder, i)
> > + drm_connector_for_each_possible_encoder(connector, encoder)
> > return encoder;
> >
> > return NULL;
> > @@ -1065,9 +1062,8 @@ amdgpu_connector_dvi_detect(struct
> > drm_connector *connector, bool force)
> > /* find analog encoder */
> > if (amdgpu_connector->dac_load_detect) {
> > struct drm_encoder *encoder;
> > - int i;
> >
> > - drm_connector_for_each_possible_encoder(connector,
> > encoder, i) {
> > + drm_connector_for_each_possible_encoder(connector,
> > encoder) {
> > if (encoder->encoder_type !=
> > DRM_MODE_ENCODER_DAC &&
> > encoder->encoder_type !=
> > DRM_MODE_ENCODER_TVDAC)
> > continue;
> > @@ -1117,9 +1113,8 @@ amdgpu_connector_dvi_encoder(struct
> > drm_connector *connector)
> > {
> > struct amdgpu_connector *amdgpu_connector =
> > to_amdgpu_connector(connector);
> >
Re: [PATCH libdrm] intel: sync i915_pciids.h with kernel
On Fri, 2019-08-30 at 13:32 -0700, Anusha Srivatsa wrote:
> Add the new CML PCI IDS.
>
> Align with kernel commit:
> bfc4c359b2822 ("drm/i915/cml: Add Missing PCI IDs")
>
> This is in sync with kernel header as of:
> 0747590267e7 ("drm-tip: 2019y-08m-30d-18h-03m-18s UTC integration
> manifest")
>
Reviewed-by: José Roberto de Souza
> Cc: José Roberto de Souza
> Signed-off-by: Anusha Srivatsa
> ---
> intel/i915_pciids.h | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/intel/i915_pciids.h b/intel/i915_pciids.h
> index a70c982d..b1f66b11 100644
> --- a/intel/i915_pciids.h
> +++ b/intel/i915_pciids.h
> @@ -466,7 +466,10 @@
> INTEL_VGA_DEVICE(0x9BC5, info), \
> INTEL_VGA_DEVICE(0x9BC8, info), \
> INTEL_VGA_DEVICE(0x9BC4, info), \
> - INTEL_VGA_DEVICE(0x9BC2, info)
> + INTEL_VGA_DEVICE(0x9BC2, info), \
> + INTEL_VGA_DEVICE(0x9BC6, info), \
> + INTEL_VGA_DEVICE(0x9BE6, info), \
> + INTEL_VGA_DEVICE(0x9BF6, info)
>
> #define INTEL_KBL_IDS(info) \
> INTEL_KBL_GT1_IDS(info), \
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Use EOPNOTSUPP, not ENOTSUPP
On Wed, 2019-09-04 at 16:39 +0200, Daniel Vetter wrote:
> - it's what we recommend in our docs:
>
> https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#recommended-ioctl-return-values
>
> - it's the overwhelmingly used error code for "operation not
> supported", at least in drm core (slightly less so in drivers):
>
> $ git grep EOPNOTSUP -- drivers/gpu/drm/*c | wc -l
> 83
> $ git grep ENOTSUP -- drivers/gpu/drm/*c | wc -l
> 5
>
> - include/linux/errno.h makes it fairly clear that these are for
> nfsv3
> (plus they also have error codes above 512, which is the block with
> some special behaviour ...)
>
> /* Defined for the NFSv3 protocol */
>
> If the above isn't reflecting current practice, then I guess we
> should
> at least update the docs.
Hopefully this will not break any userspace
Reviewed-by: José Roberto de Souza
>
> Cc: José Roberto de Souza
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Sean Paul
> Cc: Alex Deucher
> Cc: Andres Rodriguez
> Cc: Noralf Trønnes
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_edid.c | 6 +++---
> drivers/gpu/drm/drm_mipi_dbi.c | 2 +-
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 82a4ceed3fcf..12c783f4d956 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -3719,7 +3719,7 @@ cea_db_offsets(const u8 *cea, int *start, int
> *end)
> if (*end < 4 || *end > 127)
> return -ERANGE;
> } else {
> - return -ENOTSUPP;
> + return -EOPNOTSUPP;
> }
>
> return 0;
> @@ -4188,7 +4188,7 @@ int drm_edid_to_sad(struct edid *edid, struct
> cea_sad **sads)
>
> if (cea_revision(cea) < 3) {
> DRM_DEBUG_KMS("SAD: wrong CEA revision\n");
> - return -ENOTSUPP;
> + return -EOPNOTSUPP;
> }
>
> if (cea_db_offsets(cea, &start, &end)) {
> @@ -4249,7 +4249,7 @@ int drm_edid_to_speaker_allocation(struct edid
> *edid, u8 **sadb)
>
> if (cea_revision(cea) < 3) {
> DRM_DEBUG_KMS("SAD: wrong CEA revision\n");
> - return -ENOTSUPP;
> + return -EOPNOTSUPP;
> }
>
> if (cea_db_offsets(cea, &start, &end)) {
> diff --git a/drivers/gpu/drm/drm_mipi_dbi.c
> b/drivers/gpu/drm/drm_mipi_dbi.c
> index c4ee2709a6f3..f8154316a3b0 100644
> --- a/drivers/gpu/drm/drm_mipi_dbi.c
> +++ b/drivers/gpu/drm/drm_mipi_dbi.c
> @@ -955,7 +955,7 @@ static int mipi_dbi_typec1_command(struct
> mipi_dbi *dbi, u8 *cmd,
> int ret;
>
> if (mipi_dbi_command_is_read(dbi, *cmd))
> - return -ENOTSUPP;
> + return -EOPNOTSUPP;
>
> MIPI_DBI_DEBUG_COMMAND(*cmd, parameters, num);
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/kms: Catch mode_object lifetime errors
On Sat, 2019-06-29 at 17:39 +0200, Daniel Vetter wrote:
> On Fri, Jun 28, 2019 at 7:24 PM Sean Paul wrote:
> > On Fri, Jun 14, 2019 at 08:17:23AM +0200, Daniel Vetter wrote:
> > > Only dynamic mode objects, i.e. those which are refcounted and
> > > have a free
> > > callback, can be added while the overall drm_device is visible to
> > > userspace. All others must be added before drm_dev_register and
> > > removed after drm_dev_unregister.
> > >
> > > Small issue around drivers still using the load/unload callbacks,
> > > we
> > > need to make sure we set dev->registered so that load/unload code
> > > in
> > > these callbacks doesn't trigger false warnings. Only a small
> > > adjustement in drm_dev_register was needed.
> > >
> > > Motivated by some irc discussions about object ids of dynamic
> > > objects
> > > like blobs become invalid, and me going on a bit an audit spree.
> > >
> >
> > Seems like a very worthwhile change, any idea how many drivers are
> > going
> > to be sad after this change?
>
> None I think/hope, really just defense WARN_ON just in case. The main
> ones that would be sad are all the ones that have a ->load callback,
> but I'm taking care of them. Everyone else does things correctly and
> calls drm_dev_register last in their probe function (or around where
> they set up fbdev, which is also register the driver at least to the
> fbdev world, so really the same).
>
> > > Signed-off-by: Daniel Vetter
> > > ---
> > > drivers/gpu/drm/drm_drv.c | 4 ++--
> > > drivers/gpu/drm/drm_mode_object.c | 4
> > > 2 files changed, 6 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_drv.c
> > > b/drivers/gpu/drm/drm_drv.c
> > > index cb6f0245de7c..48c84e3e1931 100644
> > > --- a/drivers/gpu/drm/drm_drv.c
> > > +++ b/drivers/gpu/drm/drm_drv.c
> > > @@ -997,14 +997,14 @@ int drm_dev_register(struct drm_device
> > > *dev, unsigned long flags)
> > > if (ret)
> > > goto err_minors;
> > >
> > > - dev->registered = true;
> > > -
> > > if (dev->driver->load) {
> > > ret = dev->driver->load(dev, flags);
> > > if (ret)
> > > goto err_minors;
> > > }
> > >
> > > + dev->registered = true;
> > > +
> > > if (drm_core_check_feature(dev, DRIVER_MODESET))
> > > drm_modeset_register_all(dev);
> > >
> > > diff --git a/drivers/gpu/drm/drm_mode_object.c
> > > b/drivers/gpu/drm/drm_mode_object.c
> > > index 1c6e51135962..c355ba8e6d5d 100644
> > > --- a/drivers/gpu/drm/drm_mode_object.c
> > > +++ b/drivers/gpu/drm/drm_mode_object.c
> > > @@ -42,6 +42,8 @@ int __drm_mode_object_add(struct drm_device
> > > *dev, struct drm_mode_object *obj,
> > > {
> > > int ret;
> > >
> > > + WARN_ON(dev->registered && !obj_free_cb);
Getting warnings on i915 with MST, we add fake MST connectors when a
sink with MST support is connected;
intel_dp_add_mst_connector()->drm_connector_attach_max_bpc_property()
Not sure how to fix that, add a global i915 device property like we do
for "audio" and "Broadcast RGB" don't look the right approach here.
Any tips?
We definitely need a platform with a MST sink on our CI.
> >
> > These should probably have a comment above them giving some
> > guidance to the
> > driver developer.
> >
> > With some comments, this is:
>
> What comment do you expect here? drm_dev_register explains what you
> should do already, and I expect driver developers to find that one
> pretty quickly. From there: "This should be done last in the device
> initialization sequence to make sure userspace can't access an
> inconsistent state."
> -Daniel
>
> > Reviewed-by: Sean Paul
> >
> >
> > > +
> > > mutex_lock(&dev->mode_config.idr_mutex);
> > > ret = idr_alloc(&dev->mode_config.object_idr, register_obj
> > > ? obj : NULL,
> > > 1, 0, GFP_KERNEL);
> > > @@ -102,6 +104,8 @@ void drm_mode_object_register(struct
> > > drm_device *dev,
> > > void drm_mode_object_unregister(struct drm_device *dev,
> > > struct drm_mode_object *object)
> > > {
> > > + WARN_ON(dev->registered && !object->free_cb);
> > > +
> > > mutex_lock(&dev->mode_config.idr_mutex);
> > > if (object->id) {
> > > idr_remove(&dev->mode_config.object_idr, object-
> > > >id);
> > > --
> > > 2.20.1
> > >
> > > ___
> > > dri-devel mailing list
> > > dri-devel@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> >
> > --
> > Sean Paul, Software Engineer, Google / Chromium OS
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/connector: Allow max possible encoders to attach to a connector (rev2)
On Fri, 2019-08-16 at 21:29 +, Patchwork wrote: > == Series Details == > > Series: drm/connector: Allow max possible encoders to attach to a > connector (rev2) > URL : https://patchwork.freedesktop.org/series/62743/ > State : warning > > == Summary == > > $ dim sparse origin/drm-tip > Sparse version: v0.6.0 > Commit: drm/connector: Allow max possible encoders to attach to a > connector > + ^ > + } > +drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:4802:1: > warning: control reaches end of non-void function [-Wreturn-type] > +drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c: In > function ‘amdgpu_dm_connector_to_encoder’: Missed a "return NULL;" that will not be reached. Will fix that in the next version after get some comments. > > ___ > Intel-gfx mailing list > intel-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm 3/3] intel: Add support for EHL
Series is Reviewed-by: José Roberto de Souza
On Mon, 2019-07-15 at 11:53 -0700, Lucas De Marchi wrote:
> From: Rodrigo Vivi
>
> Add the PCI ID import for EHL.
>
> Cc: Rodrigo Vivi
> Signed-off-by: James Ausmus
> Signed-off-by: Lucas De Marchi
> ---
> intel/intel_chipset.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/intel/intel_chipset.c b/intel/intel_chipset.c
> index 157c2c7d..f6e37ee7 100644
> --- a/intel/intel_chipset.c
> +++ b/intel/intel_chipset.c
> @@ -36,6 +36,7 @@ static const struct pci_device {
> } pciids[] = {
> /* Keep ids sorted by gen; latest gen first */
> INTEL_TGL_12_IDS(12),
> + INTEL_EHL_IDS(11),
> INTEL_ICL_11_IDS(11),
> INTEL_CNL_IDS(10),
> INTEL_CFL_IDS(9),
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm] intel: sync i915_pciids.h with kernel
On Fri, 2019-03-22 at 13:35 -0700, Anusha wrote:
> Straight copy from the kernel file.
>
> Add PCI IDs for CML, add additional PCI ID
> for ICL.
>
> Align with kernel commits:
>
> a7b4deeb02b97 ("drm/i915/cml: Add CML PCI IDS")
> 9a751b999d17a ("drm/i915: Add new ICL PCI ID")
>
> v2: Do a copy from kernel header (Jose)
> - Change commit message (Lucas)
>
> v3: Add corresponding kernel commit IDs (Antonio)
Not sure if libdrm have a style rule but in i915 we use 12 digits for
the commit hash, other than that:
Reviewed-by: José Roberto de Souza
>
> Cc: Antonio Argenziano
> Cc: José Roberto de Souza
> Cc: Lucas De Marchi
> Signed-off-by: Anusha Srivatsa
> ---
> intel/i915_pciids.h | 31 +--
> 1 file changed, 29 insertions(+), 2 deletions(-)
>
> diff --git a/intel/i915_pciids.h b/intel/i915_pciids.h
> index d2fad7b0..291b5e3f 100644
> --- a/intel/i915_pciids.h
> +++ b/intel/i915_pciids.h
> @@ -373,6 +373,30 @@
> #define INTEL_AML_CFL_GT2_IDS(info) \
> INTEL_VGA_DEVICE(0x87CA, info)
>
> +/* CML GT1 */
> +#define INTEL_CML_GT1_IDS(info) \
> + INTEL_VGA_DEVICE(0x9B21, info), \
> + INTEL_VGA_DEVICE(0x9BAA, info), \
> + INTEL_VGA_DEVICE(0x9BAB, info), \
> + INTEL_VGA_DEVICE(0x9BAC, info), \
> + INTEL_VGA_DEVICE(0x9BA0, info), \
> + INTEL_VGA_DEVICE(0x9BA5, info), \
> + INTEL_VGA_DEVICE(0x9BA8, info), \
> + INTEL_VGA_DEVICE(0x9BA4, info), \
> + INTEL_VGA_DEVICE(0x9BA2, info)
> +
> +/* CML GT2 */
> +#define INTEL_CML_GT2_IDS(info) \
> + INTEL_VGA_DEVICE(0x9B41, info), \
> + INTEL_VGA_DEVICE(0x9BCA, info), \
> + INTEL_VGA_DEVICE(0x9BCB, info), \
> + INTEL_VGA_DEVICE(0x9BCC, info), \
> + INTEL_VGA_DEVICE(0x9BC0, info), \
> + INTEL_VGA_DEVICE(0x9BC5, info), \
> + INTEL_VGA_DEVICE(0x9BC8, info), \
> + INTEL_VGA_DEVICE(0x9BC4, info), \
> + INTEL_VGA_DEVICE(0x9BC2, info)
> +
> #define INTEL_KBL_IDS(info) \
> INTEL_KBL_GT1_IDS(info), \
> INTEL_KBL_GT2_IDS(info), \
> @@ -436,7 +460,9 @@
> INTEL_WHL_U_GT1_IDS(info), \
> INTEL_WHL_U_GT2_IDS(info), \
> INTEL_WHL_U_GT3_IDS(info), \
> - INTEL_AML_CFL_GT2_IDS(info)
> + INTEL_AML_CFL_GT2_IDS(info), \
> + INTEL_CML_GT1_IDS(info), \
> + INTEL_CML_GT2_IDS(info)
>
> /* CNL */
> #define INTEL_CNL_IDS(info) \
> @@ -469,6 +495,7 @@
> INTEL_VGA_DEVICE(0x8A57, info), \
> INTEL_VGA_DEVICE(0x8A56, info), \
> INTEL_VGA_DEVICE(0x8A71, info), \
> - INTEL_VGA_DEVICE(0x8A70, info)
> + INTEL_VGA_DEVICE(0x8A70, info), \
> + INTEL_VGA_DEVICE(0x8A53, info)
>
> #endif /* _I915_PCIIDS_H */
signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/5] drm: Add helpers to kick off PSR enable/disable
On Thu, 2019-02-28 at 16:09 -0500, Sean Paul wrote: > From: Sean Paul > > This patch adds a new drm helper library to help drivers implement > PSR. Drivers choosing to use it will register connectors with > PSR-capable displays connected and will receive callbacks when it's > time > to enter or exit PSR. This helpers should target connector not the entire driver, a modification in any sink would cause a PSR exit in all PSR panels. Also do atomic commit in drm_psr_helper_flush() that is called from another atomic commit sounds wrong. During the atomic checks it should probably just set enable and active states of drm_crtc_state and the CRTC would be active when committing changes. > > In its current form, it has a timer which will trigger after a > driver-specified amount of inactivity. When the timer triggers, the > helpers will save the current atomic state and issue a new state > which > has the PSR-enabled pipes turned off. On the next update, the drm > core > will poke the PSR helpers to restore the saved state to the driver > before > servicing said update. > > From the driver's perspective, this works like a regular > disable/enable > cycle. The driver need only check the 'psr_transition' state in > connector_state and keep the panel turned on when in .disable(), > while > everything else will cycle off as normal. If drivers want more > control, > they can use the psr_transition state to enter a low-power state to > minimize PSR exit time. > > While this carries the PSR moniker, it is not specific to the > DisplayPort technology. This can be used for power savings with other > types of self refresh, such as MIPI command mode. > > Cc: Zain Wang > Cc: Tomasz Figa > Signed-off-by: Sean Paul > --- > Documentation/gpu/drm-kms-helpers.rst | 9 + > drivers/gpu/drm/Makefile | 2 +- > drivers/gpu/drm/drm_atomic_helper.c | 34 +++ > drivers/gpu/drm/drm_atomic_uapi.c | 5 + > drivers/gpu/drm/drm_fb_helper.c | 9 + > drivers/gpu/drm/drm_framebuffer.c | 18 ++ > drivers/gpu/drm/drm_psr_helper.c | 343 > ++ > include/drm/drm_connector.h | 22 ++ > include/drm/drm_crtc.h| 11 + > include/drm/drm_mode_config.h | 6 + > include/drm/drm_psr_helper.h | 24 ++ > 11 files changed, 482 insertions(+), 1 deletion(-) > create mode 100644 drivers/gpu/drm/drm_psr_helper.c > create mode 100644 include/drm/drm_psr_helper.h > > diff --git a/Documentation/gpu/drm-kms-helpers.rst > b/Documentation/gpu/drm-kms-helpers.rst > index 17ca7f8bf3d3..d218a113bd52 100644 > --- a/Documentation/gpu/drm-kms-helpers.rst > +++ b/Documentation/gpu/drm-kms-helpers.rst > @@ -107,6 +107,15 @@ fbdev Helper Functions Reference > .. kernel-doc:: drivers/gpu/drm/drm_fb_helper.c > :export: > > +Panel Self Refresh Helper Reference > +=== > + > +.. kernel-doc:: drivers/gpu/drm/drm_psr_helper.c > + :doc: overview > + > +.. kernel-doc:: drivers/gpu/drm/drm_psr_helper.c > + :export: > + > Framebuffer CMA Helper Functions Reference > == > > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile > index 1ac55c65eac0..bff80fb946c7 100644 > --- a/drivers/gpu/drm/Makefile > +++ b/drivers/gpu/drm/Makefile > @@ -19,7 +19,7 @@ drm-y := drm_auth.o drm_bufs.o > drm_cache.o \ > drm_plane.o drm_color_mgmt.o drm_print.o \ > drm_dumb_buffers.o drm_mode_config.o drm_vblank.o \ > drm_syncobj.o drm_lease.o drm_writeback.o drm_client.o > \ > - drm_atomic_uapi.o > + drm_atomic_uapi.o drm_psr_helper.o > > drm-$(CONFIG_DRM_LIB_RANDOM) += lib/drm_random.o > drm-$(CONFIG_DRM_VM) += drm_vm.o > diff --git a/drivers/gpu/drm/drm_atomic_helper.c > b/drivers/gpu/drm/drm_atomic_helper.c > index c53ecbd9abdd..f5284d55f170 100644 > --- a/drivers/gpu/drm/drm_atomic_helper.c > +++ b/drivers/gpu/drm/drm_atomic_helper.c > @@ -30,6 +30,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -2746,6 +2747,10 @@ int drm_atomic_helper_update_plane(struct > drm_plane *plane, > struct drm_plane_state *plane_state; > int ret = 0; > > + ret = drm_psr_helper_flush(plane->dev, ctx); > + if (ret) > + return ret; > + > state = drm_atomic_state_alloc(plane->dev); > if (!state) > return -ENOMEM; > @@ -2797,6 +2802,10 @@ int drm_atomic_helper_disable_plane(struct > drm_plane *plane, > struct drm_plane_state *plane_state; > int ret = 0; > > + ret = drm_psr_helper_flush(plane->dev, ctx); > + if (ret) > + return ret; > + > state = drm_atomic_state_alloc(plane->dev); > if (!state) > return -ENOMEM; > @@ -2934,11 +2943,16 @@ int drm_atomic_helper_set_config(struct > drm_mode_set *set, > struct drm_crtc *crtc = set->crtc; > int ret = 0;
Re: [PATCH] drm: Fix documentation generation for DP_DPCD_QUIRK_NO_PSR
On Wed, 2018-12-05 at 12:30 -0800, Dhinakaran Pandiyan wrote:
> On Wed, 2018-12-05 at 10:48 -0800, José Roberto de Souza wrote:
> > The DP_DPCD_QUIRK_NO_PSR comment is missing colon causing this
> > warning when generating kernel documentation.
> >
> > ./include/drm/drm_dp_helper.h:1374: warning: Incorrect use of
> > kernel-
> > doc format: * @DP_DPCD_QUIRK_NO_PSR
> >
> Cc: dri-devel@lists.freedesktop.org
> Reviewed-by: Dhinakaran Pandiyan
Thanks for the review, merged.
> > Fixes: 7c5c641a930e (drm/i915: Disable PSR in Apple panels)
> > Cc: Dhinakaran Pandiyan
> > Signed-off-by: José Roberto de Souza
> > ---
> > include/drm/drm_dp_helper.h | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/include/drm/drm_dp_helper.h
> > b/include/drm/drm_dp_helper.h
> > index 18cfde45b8ed..c223c87ef119 100644
> > --- a/include/drm/drm_dp_helper.h
> > +++ b/include/drm/drm_dp_helper.h
> > @@ -1370,7 +1370,7 @@ enum drm_dp_quirk {
> > */
> > DP_DPCD_QUIRK_CONSTANT_N,
> > /**
> > -* @DP_DPCD_QUIRK_NO_PSR
> > +* @DP_DPCD_QUIRK_NO_PSR:
> > *
> > * The device does not support PSR even if reports that it
> > supports or
> > * driver still need to implement proper handling for such
> > device.
signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 08/11] drm/i915/psr: Check if source supports sink specific SU granularity
On Mon, 2018-12-03 at 15:12 -0800, Pandiyan, Dhinakaran wrote:
> On Mon, 2018-12-03 at 14:45 -0800, Souza, Jose wrote:
> > On Mon, 2018-12-03 at 12:59 -0800, Dhinakaran Pandiyan wrote:
> > > On Thu, 2018-11-29 at 18:25 -0800, José Roberto de Souza wrote:
> > > > According to eDP spec, sink can required specific selective
> > > > update
> > > > granularity that source must comply.
> > > > Here caching the value if required and checking if source
> > > > supports
> > > > it.
> > > >
> > > > Cc: Rodrigo Vivi
> > > > Cc: Dhinakaran Pandiyan
> > > > Signed-off-by: José Roberto de Souza
> > > > ---
> > > > drivers/gpu/drm/i915/i915_drv.h | 1 +
> > > > drivers/gpu/drm/i915/intel_psr.c | 21 -
> > > > 2 files changed, 21 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > > b/drivers/gpu/drm/i915/i915_drv.h
> > > > index 43ac6873a2bb..0727d8051dd3 100644
> > > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > > @@ -507,6 +507,7 @@ struct i915_psr {
> > > > ktime_t last_exit;
> > > > bool sink_not_reliable;
> > > > bool irq_aux_error;
> > > > + u16 su_x_granularity;
> > > > };
> > > >
> > > > enum intel_pch {
> > > > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > > > b/drivers/gpu/drm/i915/intel_psr.c
> > > > index 282ff1bc68a7..f9eccaac850a 100644
> > > > --- a/drivers/gpu/drm/i915/intel_psr.c
> > > > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > > > @@ -261,6 +261,23 @@ static u8
> > > > intel_dp_get_sink_sync_latency(struct
> > > > intel_dp *intel_dp)
> > > > return val;
> > > > }
> > > >
> > > > +static u16 intel_dp_get_su_x_granulartiy(struct intel_dp
> > > > *intel_dp)
> > > > +{
> > > > + u16 val;
> > > > + ssize_t r;
> > > > +
> > > > + if (!(intel_dp->psr_dpcd[1] &
> > > > DP_PSR2_SU_GRANULARITY_REQUIRED))
> > > > {
> > > > + /* Returning the default X granularity */
> > > > + return 4;
> > > > + }
> > >
> > > nit: Braces not needed, you could move the comment a line above.
> > >
> > > A value of 0 in this DPCD indicates there is no granularity
> > > requirement, why assume 4?
> >
> > Like you said bellow, 4 is the default granularity if this is not
> > set.
> >
> The spec states 0 means no granularity requirements, return 1 here?
A value of 0 indicates that no X-coordinate granularity requirement
exists other than
the standard restrictions, wherein the:
Starting X-coordinate must be evenly divisible by 16
Rectangle width must be evenly divisible by 4
>
> > > > +
> > > > + r = drm_dp_dpcd_read(&intel_dp->aux,
> > > > DP_PSR2_SU_X_GRANULARITY,
> > > > &val, 2);
> > > > + if (r != 2)
> > > > + DRM_WARN("Unable to read
> > > > DP_PSR2_SU_X_GRANULARITY\n");
> > >
> > > Please change this to the warning level that we use elsewhere for
> > > aux
> > > failures.
> >
> > So changing to DRM_DEBUG_KMS()
> >
> > > If I'm reading the spec correctly, a value of 0 in this DPCD
> > > means
> > > the
> > > sink expects a granularity of 4, so returning 0 would be
> > > incorrect.
> > >
> > > > +
> > > > + return val;
> > >
> > > Assume the default value of 4 if aux read fails (after printing
> > > an
> > > error)
> > >
> >
> > Done
> >
> >
> > > > +}
> > > > +
> > > > void intel_psr_init_dpcd(struct intel_dp *intel_dp)
> > > > {
> > > > struct drm_i915_private *dev_priv =
> > > > @@ -315,6 +332,8 @@ void intel_psr_init_dpcd(struct intel_dp
> > > > *intel_dp)
> > > > if (dev_priv->psr.sink_psr2_support) {
> > > > dev_priv->psr.colorimetry_support =
> > > > intel_dp_get_colorimetry_status
> > > > (intel_d
> > > > p);
> > > > + dev_priv->psr.su_x_granularity =
> > > > + intel_dp_get_su_x_granulartiy(i
> > > > ntel_dp)
> > > > ;
> > > > }
> > > > }
> > > > }
> > > > @@ -546,7 +565,7 @@ static bool intel_psr2_config_valid(struct
> > > > intel_dp *intel_dp,
> > > > * at each 4 lines with height of 4 lines, what eDP
> > > > states
> > > > * that sink should support.
> > > > */
> > > > - if (crtc_hdisplay % 4) {
> > > > + if (crtc_hdisplay % dev_priv->psr.su_x_granularity) {
> > > > DRM_DEBUG_KMS("PSR2 not enabled, default SU
> > > > granularity
> > > > not match\n");
> > > > return false;
> > > > }
signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 01/11] drm/i915: Disable PSR in Apple panels
On Mon, 2018-12-03 at 14:45 -0800, Dhinakaran Pandiyan wrote:
> On Mon, 2018-12-03 at 12:14 -0800, Souza, Jose wrote:
> > On Fri, 2018-11-30 at 15:35 -0800, Dhinakaran Pandiyan wrote:
> > > On Thu, 2018-11-29 at 18:25 -0800, José Roberto de Souza wrote:
> > > > i915 yet don't support PSR in Apple panels, so lets keep it
> > > > disabled
> > > > while we work on that.
> > > >
> > > > v2: Renamed DP_DPCD_QUIRK_PSR_NOT_CURRENTLY_SUPPORTED to
> > > > DP_DPCD_QUIRK_NO_PSR (Ville)
> > > >
> > > > Fixes: 598c6cfe0690 (drm/i915/psr: Enable PSR1 on gen-9+ HW)
> > > > Cc: Ville Syrjälä
> > > > Cc: Rodrigo Vivi
> > > > Cc: Dhinakaran Pandiyan
> > > > Signed-off-by: José Roberto de Souza
> > > > ---
> > > > drivers/gpu/drm/drm_dp_helper.c | 2 ++
> > > > drivers/gpu/drm/i915/intel_psr.c | 6 ++
> > > > include/drm/drm_dp_helper.h | 1 +
> > > > 3 files changed, 9 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_dp_helper.c
> > > > b/drivers/gpu/drm/drm_dp_helper.c
> > > > index 2d6c491a0542..b00fd5ced0a0 100644
> > > > --- a/drivers/gpu/drm/drm_dp_helper.c
> > > > +++ b/drivers/gpu/drm/drm_dp_helper.c
> > > > @@ -1273,6 +1273,8 @@ static const struct dpcd_quirk
> > > > dpcd_quirk_list[] = {
> > > > { OUI(0x00, 0x22, 0xb9), DEVICE_ID_ANY, true,
> > > > BIT(DP_DPCD_QUIRK_CONSTANT_N) },
> > > > /* LG LP140WF6-SPM1 eDP panel */
> > > > { OUI(0x00, 0x22, 0xb9), DEVICE_ID('s', 'i', 'v', 'a',
> > > > 'r',
> > > > 'T'), false, BIT(DP_DPCD_QUIRK_CONSTANT_N) },
> > > > + /* Apple panels needs some additional handling to
> > > > support PSR
> > > > */
> > > > + { OUI(0x00, 0x10, 0xfa), DEVICE_ID_ANY, false,
> > > > BIT(DP_DPCD_QUIRK_NO_PSR) }
> > > > };
> > > >
> > > > #undef OUI
> > > > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > > > b/drivers/gpu/drm/i915/intel_psr.c
> > > > index 2084784f320d..40ca6cc43cc4 100644
> > > > --- a/drivers/gpu/drm/i915/intel_psr.c
> > > > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > > > @@ -278,6 +278,12 @@ void intel_psr_init_dpcd(struct intel_dp
> > > > *intel_dp)
> > > > DRM_DEBUG_KMS("Panel lacks power state control,
> > > > PSR
> > > > cannot be enabled\n");
> > > > return;
> > > > }
> > > > +
> > > > + if (drm_dp_has_quirk(&intel_dp->desc,
> > > > DP_DPCD_QUIRK_NO_PSR)) {
> > > > + DRM_DEBUG_KMS("PSR support not currently
> > > > available for
> > > > this panel\n");
> > > > + return;
> > > > + }
> > > > +
> > > > dev_priv->psr.sink_support = true;
> > > > dev_priv->psr.sink_sync_latency =
> > > > intel_dp_get_sink_sync_latency(intel_dp);
> > > > diff --git a/include/drm/drm_dp_helper.h
> > > > b/include/drm/drm_dp_helper.h
> > > > index 5736c942c85b..047314ce25d6 100644
> > > > --- a/include/drm/drm_dp_helper.h
> > > > +++ b/include/drm/drm_dp_helper.h
> > > > @@ -1365,6 +1365,7 @@ enum drm_dp_quirk {
> > > > * to 16 bits. So will give a constant value (0x8000)
> > > > for
> > > > compatability.
> > > > */
> > > > DP_DPCD_QUIRK_CONSTANT_N,
> > >
> > > nit: Documentation missing here. I guess we need something along
> > > the
> > > lines of "PSR not supported" without referring to the specific DP
> > > device. With that,
> > > Reviewed-by: Dhinakaran Pandiyan
> >
> > Adding here:
> >
> > /**
> > * @DP_DPCD_QUIRK_NO_PSR
> > *
> > * The device don't properly support PSR even if reports that
> nit: "device does not support"
Thanks
> > it
> > * supports or driver still need to implement proper handling
> ^needs
> > for such
> > * device.
> > */
> >
> > >
> > > > + DP_DPCD_QUIRK_NO_PSR,
> > > > };
> > > >
> > > > /**
signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 08/11] drm/i915/psr: Check if source supports sink specific SU granularity
On Mon, 2018-12-03 at 12:59 -0800, Dhinakaran Pandiyan wrote:
> On Thu, 2018-11-29 at 18:25 -0800, José Roberto de Souza wrote:
> > According to eDP spec, sink can required specific selective update
> > granularity that source must comply.
> > Here caching the value if required and checking if source supports
> > it.
> >
> > Cc: Rodrigo Vivi
> > Cc: Dhinakaran Pandiyan
> > Signed-off-by: José Roberto de Souza
> > ---
> > drivers/gpu/drm/i915/i915_drv.h | 1 +
> > drivers/gpu/drm/i915/intel_psr.c | 21 -
> > 2 files changed, 21 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 43ac6873a2bb..0727d8051dd3 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -507,6 +507,7 @@ struct i915_psr {
> > ktime_t last_exit;
> > bool sink_not_reliable;
> > bool irq_aux_error;
> > + u16 su_x_granularity;
> > };
> >
> > enum intel_pch {
> > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > b/drivers/gpu/drm/i915/intel_psr.c
> > index 282ff1bc68a7..f9eccaac850a 100644
> > --- a/drivers/gpu/drm/i915/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > @@ -261,6 +261,23 @@ static u8
> > intel_dp_get_sink_sync_latency(struct
> > intel_dp *intel_dp)
> > return val;
> > }
> >
> > +static u16 intel_dp_get_su_x_granulartiy(struct intel_dp
> > *intel_dp)
> > +{
> > + u16 val;
> > + ssize_t r;
> > +
> > + if (!(intel_dp->psr_dpcd[1] & DP_PSR2_SU_GRANULARITY_REQUIRED))
> > {
> > + /* Returning the default X granularity */
> > + return 4;
> > + }
> nit: Braces not needed, you could move the comment a line above.
>
> A value of 0 in this DPCD indicates there is no granularity
> requirement, why assume 4?
Like you said bellow, 4 is the default granularity if this is not set.
>
> > +
> > + r = drm_dp_dpcd_read(&intel_dp->aux, DP_PSR2_SU_X_GRANULARITY,
> > &val, 2);
> > + if (r != 2)
> > + DRM_WARN("Unable to read DP_PSR2_SU_X_GRANULARITY\n");
> Please change this to the warning level that we use elsewhere for aux
> failures.
So changing to DRM_DEBUG_KMS()
>
> If I'm reading the spec correctly, a value of 0 in this DPCD means
> the
> sink expects a granularity of 4, so returning 0 would be incorrect.
>
> > +
> > + return val;
> Assume the default value of 4 if aux read fails (after printing an
> error)
>
Done
> > +}
> > +
> > void intel_psr_init_dpcd(struct intel_dp *intel_dp)
> > {
> > struct drm_i915_private *dev_priv =
> > @@ -315,6 +332,8 @@ void intel_psr_init_dpcd(struct intel_dp
> > *intel_dp)
> > if (dev_priv->psr.sink_psr2_support) {
> > dev_priv->psr.colorimetry_support =
> > intel_dp_get_colorimetry_status(intel_d
> > p);
> > + dev_priv->psr.su_x_granularity =
> > + intel_dp_get_su_x_granulartiy(intel_dp)
> > ;
> > }
> > }
> > }
> > @@ -546,7 +565,7 @@ static bool intel_psr2_config_valid(struct
> > intel_dp *intel_dp,
> > * at each 4 lines with height of 4 lines, what eDP states
> > * that sink should support.
> > */
> > - if (crtc_hdisplay % 4) {
> > + if (crtc_hdisplay % dev_priv->psr.su_x_granularity) {
> > DRM_DEBUG_KMS("PSR2 not enabled, default SU granularity
> > not match\n");
> > return false;
> > }
signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 07/11] drm/i915/psr: Check if resolution is supported by default SU granularity
On Fri, 2018-11-30 at 16:37 -0800, Dhinakaran Pandiyan wrote:
> On Thu, 2018-11-29 at 18:25 -0800, José Roberto de Souza wrote:
> > Selective updates have a default granularity requirements as stated
> > by eDP spec
> Needs reference to the location in the spec.
Done
>
> > , so check if HW can match those requirements before
> > enable PSR2.
> typo: enabling*
Done
>
> > Cc: Dhinakaran Pandiyan
> > Cc: Rodrigo Vivi
> > Signed-off-by: José Roberto de Souza
> > ---
> > drivers/gpu/drm/i915/intel_psr.c | 12
> > 1 file changed, 12 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > b/drivers/gpu/drm/i915/intel_psr.c
> > index c4a8f476eea9..282ff1bc68a7 100644
> > --- a/drivers/gpu/drm/i915/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > @@ -539,6 +539,18 @@ static bool intel_psr2_config_valid(struct
> > intel_dp *intel_dp,
> > return false;
> > }
> >
> > + /* HW will always send full lines in SU blocks, so X will
> s/X/starting X coordinate
>
> > +* always be 0 and we only need to check the width to validate
> > +* horizontal granularity.
> > +* About vertical granularity HW works by SU blocks starting
> > +* at each 4 lines with height of 4 lines, what eDP states
> > +* that sink should support.
> How about rewriting this as -
> "HW sends SU blocks of size four scan lines, which means the starting
> X
> coordinate and Y granularity requirements will always be met. We only
> need to validate the SU block width is a multiple of 4."?
>
>
Sounds better, thanks
>
>
> > +*/
> > + if (crtc_hdisplay % 4) {
> > + DRM_DEBUG_KMS("PSR2 not enabled, default SU granularity
> > not match\n");
> "PSR2 not enabled, hdisplay(%d) not multiple of 4\n"
Done.
>
> With nits addressed,
>
> Reviewed-by: Dhinakaran Pandiyan
>
Thanks
> > + return false;
> > + }
> > +
> > return true;
> > }
> >
signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 03/11] drm/i915/psr: Set PSR CRC verification bit in sink inside PSR1 block
On Fri, 2018-11-30 at 15:54 -0800, Dhinakaran Pandiyan wrote:
> On Thu, 2018-11-29 at 18:25 -0800, José Roberto de Souza wrote:
> > As we have a else block for the 'if (dev_priv->psr.psr2_enabled) {'
> > and this bit is only set for PSR1 move it to that block to make it
> > more easy to read.
> >
> > Cc: Dhinakaran Pandiyan
> > Cc: Rodrigo Vivi
> > Signed-off-by: José Roberto de Souza
> > ---
> > drivers/gpu/drm/i915/intel_psr.c | 5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > b/drivers/gpu/drm/i915/intel_psr.c
> > index 8515f4a6f4f1..b04472e637c8 100644
> > --- a/drivers/gpu/drm/i915/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > @@ -398,10 +398,11 @@ static void intel_psr_enable_sink(struct
> > intel_dp *intel_dp)
> > } else {
> > if (dev_priv->psr.link_standby)
> > dpcd_val |= DP_PSR_MAIN_LINK_ACTIVE;
> > +
> > + if (INTEL_GEN(dev_priv) >= 8)
> > + dpcd_val |= DP_PSR_CRC_VERIFICATION;
> > }
> >
> > - if (!dev_priv->psr.psr2_enabled && INTEL_GEN(dev_priv) >= 8)
> > - dpcd_val |= DP_PSR_CRC_VERIFICATION;
> > drm_dp_dpcd_writeb(&intel_dp->aux, DP_PSR_EN_CFG, dpcd_val);
> >
> > drm_dp_dpcd_writeb(&intel_dp->aux, DP_SET_POWER,
> > DP_SET_POWER_D0);
>
> Do we need this DPCD write? The panel should already be awake by this
> point, I think it's worth removing it if there's no regression.
>
> Your change in this patch looks good, so
> Reviewed-by: Dhinakaran Pandiyan
>
Added to the list to things to TODO.
Thanks for the review.
>
>
>
signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 01/11] drm/i915: Disable PSR in Apple panels
On Fri, 2018-11-30 at 15:35 -0800, Dhinakaran Pandiyan wrote:
> On Thu, 2018-11-29 at 18:25 -0800, José Roberto de Souza wrote:
> > i915 yet don't support PSR in Apple panels, so lets keep it
> > disabled
> > while we work on that.
> >
> > v2: Renamed DP_DPCD_QUIRK_PSR_NOT_CURRENTLY_SUPPORTED to
> > DP_DPCD_QUIRK_NO_PSR (Ville)
> >
> > Fixes: 598c6cfe0690 (drm/i915/psr: Enable PSR1 on gen-9+ HW)
> > Cc: Ville Syrjälä
> > Cc: Rodrigo Vivi
> > Cc: Dhinakaran Pandiyan
> > Signed-off-by: José Roberto de Souza
> > ---
> > drivers/gpu/drm/drm_dp_helper.c | 2 ++
> > drivers/gpu/drm/i915/intel_psr.c | 6 ++
> > include/drm/drm_dp_helper.h | 1 +
> > 3 files changed, 9 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_dp_helper.c
> > b/drivers/gpu/drm/drm_dp_helper.c
> > index 2d6c491a0542..b00fd5ced0a0 100644
> > --- a/drivers/gpu/drm/drm_dp_helper.c
> > +++ b/drivers/gpu/drm/drm_dp_helper.c
> > @@ -1273,6 +1273,8 @@ static const struct dpcd_quirk
> > dpcd_quirk_list[] = {
> > { OUI(0x00, 0x22, 0xb9), DEVICE_ID_ANY, true,
> > BIT(DP_DPCD_QUIRK_CONSTANT_N) },
> > /* LG LP140WF6-SPM1 eDP panel */
> > { OUI(0x00, 0x22, 0xb9), DEVICE_ID('s', 'i', 'v', 'a', 'r',
> > 'T'), false, BIT(DP_DPCD_QUIRK_CONSTANT_N) },
> > + /* Apple panels needs some additional handling to support PSR
> > */
> > + { OUI(0x00, 0x10, 0xfa), DEVICE_ID_ANY, false,
> > BIT(DP_DPCD_QUIRK_NO_PSR) }
> > };
> >
> > #undef OUI
> > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > b/drivers/gpu/drm/i915/intel_psr.c
> > index 2084784f320d..40ca6cc43cc4 100644
> > --- a/drivers/gpu/drm/i915/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > @@ -278,6 +278,12 @@ void intel_psr_init_dpcd(struct intel_dp
> > *intel_dp)
> > DRM_DEBUG_KMS("Panel lacks power state control, PSR
> > cannot be enabled\n");
> > return;
> > }
> > +
> > + if (drm_dp_has_quirk(&intel_dp->desc, DP_DPCD_QUIRK_NO_PSR)) {
> > + DRM_DEBUG_KMS("PSR support not currently available for
> > this panel\n");
> > + return;
> > + }
> > +
> > dev_priv->psr.sink_support = true;
> > dev_priv->psr.sink_sync_latency =
> > intel_dp_get_sink_sync_latency(intel_dp);
> > diff --git a/include/drm/drm_dp_helper.h
> > b/include/drm/drm_dp_helper.h
> > index 5736c942c85b..047314ce25d6 100644
> > --- a/include/drm/drm_dp_helper.h
> > +++ b/include/drm/drm_dp_helper.h
> > @@ -1365,6 +1365,7 @@ enum drm_dp_quirk {
> > * to 16 bits. So will give a constant value (0x8000) for
> > compatability.
> > */
> > DP_DPCD_QUIRK_CONSTANT_N,
>
> nit: Documentation missing here. I guess we need something along the
> lines of "PSR not supported" without referring to the specific DP
> device. With that,
> Reviewed-by: Dhinakaran Pandiyan
Adding here:
/**
* @DP_DPCD_QUIRK_NO_PSR
*
* The device don't properly support PSR even if reports that
it
* supports or driver still need to implement proper handling
for such
* device.
*/
>
>
> > + DP_DPCD_QUIRK_NO_PSR,
> > };
> >
> > /**
signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 8/9] drm/i915/psr: Set the right frames values
On Thu, 2018-11-29 at 15:10 -0800, Rodrigo Vivi wrote: > On Mon, Nov 26, 2018 at 04:37:09PM -0800, José Roberto de Souza > wrote: > > EDP_PSR2_IDLE_FRAMES_TO_DEEP_SLEEP() was being set with the number > > of > > frames that it should wait to enter PSR, what is wrong. > > Here it is setting this field with the highest value to avoid PSR2 > > exits frequently, as when HW exit deep sleep it needs to go to idle > > state causing a PSR exit for then waiting a few frames before > > activate PSR2 again. > > This will result in more power saving as the sleep state also > > provide > > some power savings by doing selective updates instead of full > > screen > > updates. > > > > About EDP_PSR2_FRAMES_BEFORE_ACTIVATE() it is the number of frames > > (not idle frames) that PSR2 hardware will wait to activate PSR2, so > > lets keep using the sink sync latency. > > > > Cc: Rodrigo Vivi > > Cc: Dhinakaran Pandiyan > > Signed-off-by: José Roberto de Souza > > --- > > drivers/gpu/drm/i915/intel_psr.c | 12 +--- > > 1 file changed, 5 insertions(+), 7 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/intel_psr.c > > b/drivers/gpu/drm/i915/intel_psr.c > > index ba7bbe3f8df2..6fd793fec5e9 100644 > > --- a/drivers/gpu/drm/i915/intel_psr.c > > +++ b/drivers/gpu/drm/i915/intel_psr.c > > @@ -482,13 +482,13 @@ static void hsw_activate_psr2(struct intel_dp > > *intel_dp) > > struct i915_psr *psr = &dev_priv->psr; > > u32 val; > > > > - /* Let's use 6 as the minimum to cover all known cases > > including the > > -* off-by-one issue that HW has in some cases. > > + /* sink_sync_latency of 8 means source has to wait for more > > than 8 > > +* frames, we'll go with 9 frames for now > > */ > > - int idle_frames = max(6, dev_priv->vbt.psr.idle_frames); > > Too many changes in a single patch that I couldn't understand why we > are removing the minimal of 6 that was our safe net. The vbt idle_frames should not be used for PSR2 as PSR2 just wait for X frames(idle or not) to activate PSR2 so just rely in sink sync_latency should be enough but I can bring it back for safety. > > > + val = EDP_PSR2_FRAMES_BEFORE_ACTIVATE(psr->sink_sync_latency + > > 1); > > > > - idle_frames = max(idle_frames, psr->sink_sync_latency + 1); > > - val = EDP_PSR2_IDLE_FRAMES_TO_DEEP_SLEEP(idle_frames); > > + /* Avoid deep sleep as much as possible to avoid PSR2 idle > > state */ > > + val |= EDP_PSR2_IDLE_FRAMES_TO_DEEP_SLEEP(15); > > > > /* FIXME: selective update is probably totally broken because > > it doesn't > > * mesh at all with our frontbuffer tracking. And the hw alone > > isn't > > @@ -497,8 +497,6 @@ static void hsw_activate_psr2(struct intel_dp > > *intel_dp) > > if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv)) > > val |= EDP_Y_COORDINATE_ENABLE; > > > > - val |= EDP_PSR2_FRAMES_BEFORE_ACTIVATE(psr->sink_sync_latency + > > 1); > > - > > if (dev_priv->vbt.psr.tp2_tp3_wakeup_time_us >= 0 && > > dev_priv->vbt.psr.tp2_tp3_wakeup_time_us <= 50) > > val |= EDP_PSR2_TP2_TIME_50us; > > -- > > 2.19.2 > > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel signature.asc Description: This is a digitally signed message part ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 7/9] drm/i915/psr: Rename PSR2 macros to better match meaning
On Thu, 2018-11-29 at 15:25 -0800, Dhinakaran Pandiyan wrote:
> On Thu, 2018-11-29 at 15:07 -0800, Rodrigo Vivi wrote:
> > On Mon, Nov 26, 2018 at 04:37:08PM -0800, José Roberto de Souza
> > wrote:
> > > The first 8 bits of PSR2_CTL have 2 fields to set frames count,
> > > the
> > > first one is to set how many idle frames PSR2 HW needs to wait
> > > before
> > > enter in deep sleep and the second one it is how many frames(it
> > > don't
> > > need to be idle frames) PSR2 HW will wait before start the PSR
> > > activation sequence.
> > > The previous names was really misleading and caused wrong values
> The idea was to setup a conservative configuration for PSR2 until we
> were ready to enable the feature and some testing was done. Not sure
> why you think the values are wrong.
>
> > > being
> > > set so better rename to make it clear.
> >
> > I honestly prefer the old names for 2 reasons:
> >
> > - they are shorter
> > - they follow the exact name we have on spec
> +1 for the above reason.
Okay droping this patch.
>
> > > Also taking the oportunity to improve those macros.
> > >
> > > Cc: Rodrigo Vivi
> > > Cc: Dhinakaran Pandiyan
> > > Signed-off-by: José Roberto de Souza
> > > ---
> > > drivers/gpu/drm/i915/i915_reg.h | 35 --
> > > --
> > > drivers/gpu/drm/i915/intel_psr.c | 7 ---
> > > 2 files changed, 22 insertions(+), 20 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > > b/drivers/gpu/drm/i915/i915_reg.h
> > > index 47baf2fe8f71..73046bb9ec7c 100644
> > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > @@ -4203,23 +4203,24 @@ enum {
> > > #define EDP_PSR_DEBUG_MASK_DISP_REG_WRITE(1 << 16) /*
> > > Reserved in ICL+ */
> > > #define EDP_PSR_DEBUG_EXIT_ON_PIXEL_UNDERRUN (1 << 15) /* SKL+
> > > */
> > >
> > > -#define EDP_PSR2_CTL _MMIO(0x6f900)
> > > -#define EDP_PSR2_ENABLE(1 << 31)
> > > -#define EDP_SU_TRACK_ENABLE(1 << 30)
> > > -#define EDP_Y_COORDINATE_VALID (1 << 26) /* GLK and CNL+ */
> > > -#define EDP_Y_COORDINATE_ENABLE(1 << 25) /* GLK and
> > > CNL+ */
> > > -#define EDP_MAX_SU_DISABLE_TIME(t) ((t) << 20)
> > > -#define EDP_MAX_SU_DISABLE_TIME_MASK (0x1f << 20)
> > > -#define EDP_PSR2_TP2_TIME_500us(0 << 8)
> > > -#define EDP_PSR2_TP2_TIME_100us(1 << 8)
> > > -#define EDP_PSR2_TP2_TIME_2500us (2 << 8)
> > > -#define EDP_PSR2_TP2_TIME_50us (3 << 8)
> > > -#define EDP_PSR2_TP2_TIME_MASK (3 << 8)
> > > -#define EDP_PSR2_FRAME_BEFORE_SU_SHIFT 4
> > > -#define EDP_PSR2_FRAME_BEFORE_SU_MASK (0xf << 4)
> > > -#define EDP_PSR2_FRAME_BEFORE_SU(a)((a) << 4)
> > > -#define EDP_PSR2_IDLE_FRAME_MASK 0xf
> > > -#define EDP_PSR2_IDLE_FRAME_SHIFT 0
> > > +#define EDP_PSR2_CTL _MMIO(0
> > > x6f900)
> > > +#define EDP_PSR2_ENABLE(1 <<
> > > 31)
> > > +#define EDP_SU_TRACK_ENABLE(1 <<
> > > 30)
> > > +#define EDP_Y_COORDINATE_VALID (1 << 26) /*
> > > GLK and CNL+ */
> > > +#define EDP_Y_COORDINATE_ENABLE(1 <<
> > > 25) /*
> > > GLK and CNL+ */
> > > +#define EDP_MAX_SU_DISABLE_TIME(t) ((t) <<
> > > 20)
> > > +#define EDP_MAX_SU_DISABLE_TIME_MASK (0x1f
> > > << 20)
> > > +#define EDP_PSR2_TP2_TIME_500us(0 <<
> > > 8)
> > > +#define EDP_PSR2_TP2_TIME_100us(1 <<
> > > 8)
> > > +#define EDP_PSR2_TP2_TIME_2500us (2 <<
> > > 8)
> > > +#define EDP_PSR2_TP2_TIME_50us (3 << 8)
> > > +#define EDP_PSR2_TP2_TIME_MASK (3 << 8)
> > > +#define EDP_PSR2_FRAMES_BEFORE_ACTIVATE_SHIFT (4)
> > > +#define EDP_PSR2_FRAMES_BEFORE_ACTIVATE_MASK (0xf <<
> > > EDP_PSR2_FRAMES_BEFORE_ACTIVATE_SHIFT)
> > > +#define EDP_PSR2_FRAMES_BEFORE_ACTIVATE(n) (((n)
> > > << EDP_PSR2_FRAMES_BEFORE_ACTIVATE_SHIFT) &
> > > EDP_PSR2_FRAMES_BEFORE_ACTIVATE_MASK)
> > > +#define EDP_PSR2_IDLE_FRAMES_TO_DEEP_SLEEP_MASK(0xf)
> > > +#define EDP_PSR2_IDLE_FRAMES_TO_DEEP_SLEEP_SHIFT (0)
> > > +#define EDP_PSR2_IDLE_FRAMES_TO_DEEP_SLEEP(n) (((n)
> > > << EDP_PSR2_IDLE_FRAMES_TO_DEEP_SLEEP_SHIFT) &
> > > EDP_PSR2_IDLE_FRAMES_TO_DEEP_SLEEP_MASK)
> > >
> > > #define _PSR_EVENT_TRANS_A 0x60848
> > > #define _PSR_EVENT_TRANS_B 0x61848
> > > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > > b/drivers/gpu/drm/i915/intel_psr.c
> > > index 9215c9052381..ba7bbe3f8df2 100644
> > > --- a/drivers/gpu/drm/i915/intel_psr.c
> > > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > > @@ -479,6 +479,7 @@ static void hsw_activate_psr1(struct intel_dp
> > > *intel_dp)
> > > static void hsw_activate_psr2(struct intel_dp *intel_dp
Re: [PATCH 6/9] drm/i915/psr: Check if source supports sink specific SU granularity
On Thu, 2018-11-29 at 15:03 -0800, Rodrigo Vivi wrote:
> On Mon, Nov 26, 2018 at 04:37:07PM -0800, José Roberto de Souza
> wrote:
> > According to eDP spec, sink can required specific selective update
> > granularity that source must comply.
> > Here caching the value if required and checking source supports it.
> >
> > Cc: Rodrigo Vivi
> > Cc: Dhinakaran Pandiyan
> > Signed-off-by: José Roberto de Souza
> > ---
> > drivers/gpu/drm/i915/i915_drv.h | 1 +
> > drivers/gpu/drm/i915/intel_psr.c | 32
> >
> > 2 files changed, 33 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index f763b30f98d9..cbcd85af95bf 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -506,6 +506,7 @@ struct i915_psr {
> > ktime_t last_exit;
> > bool sink_not_reliable;
> > bool irq_aux_error;
> > + u16 su_x_granularity;
> > };
> >
> > enum intel_pch {
> > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > b/drivers/gpu/drm/i915/intel_psr.c
> > index 7607a58a6ec0..9215c9052381 100644
> > --- a/drivers/gpu/drm/i915/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > @@ -257,6 +257,21 @@ static u8
> > intel_dp_get_sink_sync_latency(struct intel_dp *intel_dp)
> > return val;
> > }
> >
> > +static u16 intel_dp_get_su_x_granulartiy(struct intel_dp
> > *intel_dp)
> > +{
> > + u16 val = 0;
> > + ssize_t r;
> > +
> > + if (!(intel_dp->psr_dpcd[1] & DP_PSR2_SU_GRANULARITY_REQUIRED))
> > + return val;
> > +
> > + r = drm_dp_dpcd_read(&intel_dp->aux, DP_PSR2_SU_X_GRANULARITY,
> > &val, 2);
> > + if (r != 2)
> > + DRM_WARN("Unable to read DP_PSR2_SU_X_GRANULARITY\n");
> > +
> > + return val;
> > +}
> > +
> > void intel_psr_init_dpcd(struct intel_dp *intel_dp)
> > {
> > struct drm_i915_private *dev_priv =
> > @@ -311,6 +326,8 @@ void intel_psr_init_dpcd(struct intel_dp
> > *intel_dp)
> > if (dev_priv->psr.sink_psr2_support) {
> > dev_priv->psr.colorimetry_support =
> > intel_dp_get_colorimetry_status(intel_d
> > p);
> > + dev_priv->psr.su_x_granularity =
> > + intel_dp_get_su_x_granulartiy(intel_dp)
> > ;
> > }
> > }
> > }
> > @@ -525,6 +542,21 @@ static bool intel_psr2_config_valid(struct
> > intel_dp *intel_dp,
> > return false;
> > }
> >
> > + if (dev_priv->psr.su_x_granularity) {
> > + /*
> > +* HW will always send full lines in SU blocks, so X
> > will
> > +* always be 0 and we only need to check the width to
> > validate
> > +* horizontal granularity.
> > +* About vertical granularity HW works by SU blocks
> > starting
> > +* at each 4 lines with height of 4 lines, what eDP
> > states
> > +* that sink should support.
> > +*/
> > + if (crtc_hdisplay % dev_priv->psr.su_x_granularity) {
> > + DRM_DEBUG_KMS("PSR2 not enabled, HW can not
> > match sink SU granularity requirement\n");
> > + return false;
>
> I wonder if regardless this bit we still need to do a sort of
> check anyway because spec states:
>
> "
> Sets the grid pattern granularity in the X direction.
> A value of 0 indicates that no X-coordinate granularity requirement
> exists other than
> the standard restrictions, wherein the:
> •
> Starting X-coordinate must be evenly divisible by 16
> •
> Rectangle width must be evenly divisible by 4
> "
Hum, the x will always be 0 so it will always be divisible by 16 but
the width could not be divisible by 4 in the odd resolutions. I will
add this check, thanks.
>
> Also, why we are just checking X granularity and not Y? (0074h)
>
> (maybe it would be useful to introduce along with previous patch
> that I had just reviewed)
It is in the comment above but coping from eDP spec:
A value of 00h, 01h, 02h, or 04h should be supported by the Sink device
to ensure
interoperability with various Source devices. A value of 08h or 10h may
be considered
for system-specific implementations.
Our height is multiple of 4 so we are safe even if sink have a y
granularity set.
>
> > + }
> > + }
> > +
> > return true;
> > }
> >
> > --
> > 2.19.2
> >
signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/9] drm/i915/icl: Do not change reserved registers related to PSR2
On Thu, 2018-11-29 at 14:15 -0800, Rodrigo Vivi wrote:
> On Mon, Nov 26, 2018 at 04:37:05PM -0800, José Roberto de Souza
> wrote:
> > For ICL the bit 12 of CHICKEN_TRANS is reserved so we should not
> > touch it and as by default VSC_DATA_SEL_SOFTWARE_CONTROL is already
> > unset in gen10 + GLK we can just drop it and fix for both gens.
> >
> > Cc: Dhinakaran Pandiyan
> > Cc: Rodrigo Vivi
> > Signed-off-by: José Roberto de Souza
>
> Ok, this patch seems right according to spec.
>
> Reviewed-by: Rodrigo Vivi
>
> But I wonder now if we need intel_psr_setup_vsc() at all for
> platforms different than gen9.
>
> Because description of this bit is:
> This field enables the programmable header for the PSR2 VSC packet.
>
> Without the programmable version I would assume display
> engine is now responsible for setting header entirely?
As this was in a chicken register in gen 9 my guess is that it was
fixed on newer gens and as it is required for PSR2 we don't need to
manually enable it in driver but Art could confirm it.
>
> Art?
>
> > ---
> > drivers/gpu/drm/i915/intel_psr.c | 11 ---
> > 1 file changed, 4 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > b/drivers/gpu/drm/i915/intel_psr.c
> > index 607c3ec41679..7607a58a6ec0 100644
> > --- a/drivers/gpu/drm/i915/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > @@ -635,17 +635,14 @@ static void intel_psr_enable_source(struct
> > intel_dp *intel_dp,
> > if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv))
> > hsw_psr_setup_aux(intel_dp);
> >
> > - if (dev_priv->psr.psr2_enabled) {
> > + if (dev_priv->psr.psr2_enabled && (IS_GEN9(dev_priv) &&
> > + !IS_GEMINILAKE(dev_priv))) {
> > i915_reg_t reg = gen9_chicken_trans_reg(dev_priv,
> > cpu_transcoder)
> > ;
> > u32 chicken = I915_READ(reg);
> >
> > - if (IS_GEN9(dev_priv) && !IS_GEMINILAKE(dev_priv))
> > - chicken |= (PSR2_VSC_ENABLE_PROG_HEADER
> > - | PSR2_ADD_VERTICAL_LINE_COUNT);
> > -
> > - else
> > - chicken &= ~VSC_DATA_SEL_SOFTWARE_CONTROL;
> > + chicken |= PSR2_VSC_ENABLE_PROG_HEADER |
> > + PSR2_ADD_VERTICAL_LINE_COUNT;
> > I915_WRITE(reg, chicken);
> > }
> >
> > --
> > 2.19.2
> >
signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
