Re: [PATCH v6 12/14] drm/bridge: imx: Add LDB support for i.MX8qxp

[kernel test robot]

Hi Liu,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on shawnguo/for-next]
[also build test ERROR on robh/for-next drm-intel/for-linux-next 
drm-tip/drm-tip drm-exynos/exynos-drm-next tegra-drm/drm/tegra/for-next 
linus/master v5.12-rc3 next-20210319]
[cannot apply to drm/drm-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Liu-Ying/Add-some-DRM-bridge-drivers-support-for-i-MX8qm-qxp-SoCs/20210317-115847
base:   https://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git 
for-next
config: x86_64-allyesconfig (attached as .config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce (this is a W=1 build):
# 
https://github.com/0day-ci/linux/commit/482264f815494bc2e90bde5f7b47a60331b81817
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Liu-Ying/Add-some-DRM-bridge-drivers-support-for-i-MX8qm-qxp-SoCs/20210317-115847
git checkout 482264f815494bc2e90bde5f7b47a60331b81817
# save the attached .config to linux build tree
make W=1 ARCH=x86_64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All errors (new ones prefixed by >>):

   drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c:65:16: warning: 'struct 
phy_configure_opts_lvds' declared inside parameter list will not be visible 
outside of this definition or declaration
  65 | struct phy_configure_opts_lvds *phy_cfg)
 |^~~
   drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c: In function 
'imx8qxp_ldb_set_phy_cfg':
>> drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c:67:9: error: dereferencing 
>> pointer to incomplete type 'struct phy_configure_opts_lvds'
  67 |  phy_cfg->bits_per_lane_and_dclk_cycle = 7;
 | ^~
   drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c: In function 
'imx8qxp_ldb_bridge_atomic_check':
>> drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c:94:49: error: 'union 
>> phy_configure_opts' has no member named 'lvds'
  94 |  struct phy_configure_opts_lvds *phy_cfg = 
 | ^
>> drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c:102:57: error: passing argument 
>> 4 of 'imx8qxp_ldb_set_phy_cfg' from incompatible pointer type 
>> [-Werror=incompatible-pointer-types]
 102 |  imx8qxp_ldb_set_phy_cfg(imx8qxp_ldb, di_clk, is_split, phy_cfg);
 | ^~~
 | |
 | struct 
phy_configure_opts_lvds *
   drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c:65:41: note: expected 'struct 
phy_configure_opts_lvds *' but argument is of type 'struct 
phy_configure_opts_lvds *'
  65 | struct phy_configure_opts_lvds *phy_cfg)
 | ^~~
   drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c: In function 
'imx8qxp_ldb_bridge_mode_set':
   drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c:136:49: error: 'union 
phy_configure_opts' has no member named 'lvds'
 136 |  struct phy_configure_opts_lvds *phy_cfg = 
 | ^
   drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c:162:57: error: passing argument 
4 of 'imx8qxp_ldb_set_phy_cfg' from incompatible pointer type 
[-Werror=incompatible-pointer-types]
 162 |  imx8qxp_ldb_set_phy_cfg(imx8qxp_ldb, di_clk, is_split, phy_cfg);
 | ^~~
 | |
 | struct 
phy_configure_opts_lvds *
   drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c:65:41: note: expected 'struct 
phy_configure_opts_lvds *' but argument is of type 'struct 
phy_configure_opts_lvds *'
  65 | struct phy_configure_opts_lvds *phy_cfg)
 | ^~~
   cc1: some warnings being treated as errors


vim +67 drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c

62  
63  static void imx8qxp_ldb_set_phy_cfg(struct imx8qxp_ldb *imx8qxp_ldb,
64  unsigned long di_clk, bool is_split,
65  struct phy_configure_opts_lvds 
*phy_cfg)
66  {
  > 67  phy_cfg->bits_per_lane_and_dclk_cycle = 7;
68  phy_cfg->lanes = 4;
69  
70  if (is_split) {
71  phy_cfg->differential_clk_rate = di_clk / 2;
72  phy_cfg->is_slave = !imx8qxp_ldb->companion;
73  } else {
  

Re: [PATCH 1/5] drm/fourcc: Add 16 bpc fixed point framebuffer formats.

[Ville Syrjälä]

On Fri, Mar 19, 2021 at 10:45:10PM +0100, Mario Kleiner wrote:
> On Fri, Mar 19, 2021 at 10:16 PM Ville Syrjälä
>  wrote:
> >
> > On Fri, Mar 19, 2021 at 10:03:13PM +0100, Mario Kleiner wrote:
> > > These are 16 bits per color channel unsigned normalized formats.
> > > They are supported by at least AMD display hw, and suitable for
> > > direct scanout of Vulkan swapchain images in the format
> > > VK_FORMAT_R16G16B16A16_UNORM.
> > >
> > > Signed-off-by: Mario Kleiner 
> > > ---
> > >  drivers/gpu/drm/drm_fourcc.c  | 4 
> > >  include/uapi/drm/drm_fourcc.h | 7 +++
> > >  2 files changed, 11 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> > > index 03262472059c..ce13d2be5d7b 100644
> > > --- a/drivers/gpu/drm/drm_fourcc.c
> > > +++ b/drivers/gpu/drm/drm_fourcc.c
> > > @@ -203,6 +203,10 @@ const struct drm_format_info *__drm_format_info(u32 
> > > format)
> > >   { .format = DRM_FORMAT_ARGB16161616F,   .depth = 0,  
> > > .num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = 
> > > true },
> > >   { .format = DRM_FORMAT_ABGR16161616F,   .depth = 0,  
> > > .num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = 
> > > true },
> > >   { .format = DRM_FORMAT_AXBXGXRX106106106106, .depth = 0, 
> > > .num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = 
> > > true },
> > > + { .format = DRM_FORMAT_XRGB16161616,.depth = 0,  
> > > .num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1 },
> > > + { .format = DRM_FORMAT_XBGR16161616,.depth = 0,  
> > > .num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1 },
> > > + { .format = DRM_FORMAT_ARGB16161616,.depth = 0,  
> > > .num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = 
> > > true },
> > > + { .format = DRM_FORMAT_ABGR16161616,.depth = 0,  
> > > .num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = 
> > > true },
> > >   { .format = DRM_FORMAT_RGB888_A8,   .depth = 32, 
> > > .num_planes = 2, .cpp = { 3, 1, 0 }, .hsub = 1, .vsub = 1, .has_alpha = 
> > > true },
> > >   { .format = DRM_FORMAT_BGR888_A8,   .depth = 32, 
> > > .num_planes = 2, .cpp = { 3, 1, 0 }, .hsub = 1, .vsub = 1, .has_alpha = 
> > > true },
> > >   { .format = DRM_FORMAT_XRGB_A8, .depth = 32, 
> > > .num_planes = 2, .cpp = { 4, 1, 0 }, .hsub = 1, .vsub = 1, .has_alpha = 
> > > true },
> > > diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> > > index f76de49c768f..f7156322aba5 100644
> > > --- a/include/uapi/drm/drm_fourcc.h
> > > +++ b/include/uapi/drm/drm_fourcc.h
> > > @@ -168,6 +168,13 @@ extern "C" {
> > >  #define DRM_FORMAT_RGBA1010102   fourcc_code('R', 'A', '3', '0') /* 
> > > [31:0] R:G:B:A 10:10:10:2 little endian */
> > >  #define DRM_FORMAT_BGRA1010102   fourcc_code('B', 'A', '3', '0') /* 
> > > [31:0] B:G:R:A 10:10:10:2 little endian */
> > >
> > > +/* 64 bpp RGB */
> > > +#define DRM_FORMAT_XRGB16161616  fourcc_code('X', 'R', '4', '8') /* 
> > > [63:0] x:R:G:B 16:16:16:16 little endian */
> > > +#define DRM_FORMAT_XBGR16161616  fourcc_code('X', 'B', '4', '8') /* 
> > > [63:0] x:B:G:R 16:16:16:16 little endian */
> > > +
> > > +#define DRM_FORMAT_ARGB16161616  fourcc_code('A', 'R', '4', '8') /* 
> > > [63:0] A:R:G:B 16:16:16:16 little endian */
> > > +#define DRM_FORMAT_ABGR16161616  fourcc_code('A', 'B', '4', '8') /* 
> > > [63:0] A:B:G:R 16:16:16:16 little endian */
> >
> > These look reasonable enough to me. IIRC we should be able to expose
> > them on some recent Intel hw as well.
> >
> > Reviewed-by: Ville Syrjälä 
> >
> 
> Thanks Ville!
> 
> Indeed i looked over the Intel PRM's, and while fp16 support seems to
> be rather recent (Gen8? Gen9? Gen10? Can't remember atm.), iirc, I
> found references to rgb16 fixed point back to gen5 / Ironlake.

fp16 has been around since forever (gen4+)
uint16 is much more recent, IIRC is something ~glk+

> That
> would be pretty cool! The precision limit for the encoders on Intel is
> also 12 bpc atm., right?

Yes.

-- 
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/rockchip: Remove unused variable

[Laurent Pinchart]

Hi Maxime,

Thank you for the patch.

On Fri, Mar 19, 2021 at 04:29:20PM +0100, Maxime Ripard wrote:
> Commit 977697e20b3d ("drm/atomic: Pass the full state to planes atomic
> disable and update") added the old_state variable instead of what used
> to be a parameter, but it also removed the sole user of that variable in
> the vop_plane_atomic_update function leading to an usused variable.
> Remove it.
> 
> Fixes: 977697e20b3d ("drm/atomic: Pass the full state to planes atomic 
> disable and update")
> Reported-by: Stephen Rothwell 
> Signed-off-by: Maxime Ripard 

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> index 81c70d7a0471..64469439ddf2 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> @@ -879,8 +879,6 @@ static void vop_plane_atomic_disable(struct drm_plane 
> *plane,
>  static void vop_plane_atomic_update(struct drm_plane *plane,
>   struct drm_atomic_state *state)
>  {
> - struct drm_plane_state *old_state = 
> drm_atomic_get_old_plane_state(state,
> -
> plane);
>   struct drm_plane_state *new_state = 
> drm_atomic_get_new_plane_state(state,
>  
> plane);
>   struct drm_crtc *crtc = new_state->crtc;

-- 
Regards,

Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [v1] drm/msm/disp/dpu1: fix display underruns during modeset.

[Doug Anderson]

Hi,

On Fri, Mar 19, 2021 at 5:54 AM Kalyan Thota  wrote:
>
> During crtc disable, display perf structures are reset to 0
> which includes state varibles which are immutable. On crtc
> enable, we use the same structures and they don't refelect
> the actual values
>
> 1) Fix is to avoid updating the state structures during disable.
> 2) Reset the perf structures during atomic check when there is no
> modeset enable.
>
> Signed-off-by: Kalyan Thota 
> ---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 1 -
>  drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c  | 1 +
>  2 files changed, 1 insertion(+), 1 deletion(-)

I think Stephen was the one who originally noticed this and reported it, so:

Reported-by: Stephen Boyd 

Seems to work for me. I got into the state where it was doing a
modeset at reboot (could see the underflow color for a period of time
when this happened). I added your patch and it looks better.

Tested-by: Douglas Anderson 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 4/4] drm/i915: Implement SINGLE_TIMELINE with a syncobj

[Jason Ekstrand]

I'd love to delete the SINGLE_TIMELINE API because it leaks an
implementation detail of contexts through to the API and is something
that userspace can do itself, trivially.  Unfortunately, it's used by
the media driver so we can't do that.  We can, however, do the next-best
thing which is to embed a syncobj in the context and do exactly what
we'd expect from userspace internally.

This has a couple of advantages.  One is that we're no longer leaking a
detail of the current execlist scheduler which will be problematic when
we try to add GuC scheduling.  Second is that, together with deleting
the CLONE_CONTEXT API, we should now have a 1:1 mapping between
intel_context and intel_timeline which should make some of our locking
mess a bit easier.

Signed-off-by: Jason Ekstrand 
Cc: Maarten Lankhorst 
Cc: Matthew Brost 
---
 drivers/gpu/drm/i915/gem/i915_gem_context.c   | 47 ---
 .../gpu/drm/i915/gem/i915_gem_context_types.h |  8 +++-
 .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 15 ++
 3 files changed, 32 insertions(+), 38 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index f88bac19333ec..e094f4a1ca4cd 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -67,6 +67,8 @@
 #include 
 #include 
 
+#include 
+
 #include "gt/gen6_ppgtt.h"
 #include "gt/intel_context.h"
 #include "gt/intel_engine_heartbeat.h"
@@ -224,10 +226,6 @@ static void intel_context_set_gem(struct intel_context *ce,
ce->vm = vm;
}
 
-   GEM_BUG_ON(ce->timeline);
-   if (ctx->timeline)
-   ce->timeline = intel_timeline_get(ctx->timeline);
-
if (ctx->sched.priority >= I915_PRIORITY_NORMAL &&
intel_engine_has_timeslices(ce->engine))
__set_bit(CONTEXT_USE_SEMAPHORES, >flags);
@@ -344,8 +342,8 @@ void i915_gem_context_release(struct kref *ref)
mutex_destroy(>engines_mutex);
mutex_destroy(>lut_mutex);
 
-   if (ctx->timeline)
-   intel_timeline_put(ctx->timeline);
+   if (ctx->syncobj)
+   drm_syncobj_put(ctx->syncobj);
 
put_pid(ctx->pid);
mutex_destroy(>mutex);
@@ -790,33 +788,11 @@ static void __assign_ppgtt(struct i915_gem_context *ctx,
i915_vm_close(vm);
 }
 
-static void __set_timeline(struct intel_timeline **dst,
-  struct intel_timeline *src)
-{
-   struct intel_timeline *old = *dst;
-
-   *dst = src ? intel_timeline_get(src) : NULL;
-
-   if (old)
-   intel_timeline_put(old);
-}
-
-static void __apply_timeline(struct intel_context *ce, void *timeline)
-{
-   __set_timeline(>timeline, timeline);
-}
-
-static void __assign_timeline(struct i915_gem_context *ctx,
- struct intel_timeline *timeline)
-{
-   __set_timeline(>timeline, timeline);
-   context_apply_all(ctx, __apply_timeline, timeline);
-}
-
 static struct i915_gem_context *
 i915_gem_create_context(struct drm_i915_private *i915, unsigned int flags)
 {
struct i915_gem_context *ctx;
+   int ret;
 
if (flags & I915_CONTEXT_CREATE_FLAGS_SINGLE_TIMELINE &&
!HAS_EXECLISTS(i915))
@@ -845,16 +821,13 @@ i915_gem_create_context(struct drm_i915_private *i915, 
unsigned int flags)
}
 
if (flags & I915_CONTEXT_CREATE_FLAGS_SINGLE_TIMELINE) {
-   struct intel_timeline *timeline;
-
-   timeline = intel_timeline_create(>gt);
-   if (IS_ERR(timeline)) {
+   ret = drm_syncobj_create(>syncobj,
+DRM_SYNCOBJ_CREATE_SIGNALED,
+NULL);
+   if (ret) {
context_close(ctx);
-   return ERR_CAST(timeline);
+   return ERR_PTR(ret);
}
-
-   __assign_timeline(ctx, timeline);
-   intel_timeline_put(timeline);
}
 
trace_i915_context_create(ctx);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h 
b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
index 676592e27e7d2..8a5fdd163b79d 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
@@ -83,7 +83,13 @@ struct i915_gem_context {
struct i915_gem_engines __rcu *engines;
struct mutex engines_mutex; /* guards writes to engines */
 
-   struct intel_timeline *timeline;
+   /**
+* @syncobj: Shared timeline syncobj
+*
+* When the SHARED_TIMELINE flag is set on context creation, this
+* provides automatic implicit synchronization across all engines.
+*/
+   struct drm_syncobj *syncobj;
 
/**
 * @vm: unique address space (GTT)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 

[PATCH 2/4] drm/i915: Drop I915_CONTEXT_PARAM_NO_ZEROMAP

[Jason Ekstrand]

The idea behind this param is to support OpenCL drivers with relocations
because OpenCL reserves 0x0 for NULL and, if we placed memory there, it
would confuse CL kernels.  It was originally sent out as part of a patch
series including libdrm [1] and Beignet [2] support.  However, the
libdrm and Beignet patches never landed in their respective upstream
projects so this API has never been used.  It's never been used in Mesa
or any other driver, either.

Dropping this API allows us to delete a small bit of code.

[1]: https://lists.freedesktop.org/archives/intel-gfx/2015-May/067030.html
[2]: https://lists.freedesktop.org/archives/intel-gfx/2015-May/067031.html

Signed-off-by: Jason Ekstrand 
---
 drivers/gpu/drm/i915/gem/i915_gem_context.c  | 16 ++--
 .../gpu/drm/i915/gem/i915_gem_context_types.h|  1 -
 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c   |  8 
 include/uapi/drm/i915_drm.h  |  4 
 4 files changed, 6 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index c528db3b7dcf4..d28ac79de7573 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1904,15 +1904,6 @@ static int ctx_setparam(struct drm_i915_file_private 
*fpriv,
int ret = 0;
 
switch (args->param) {
-   case I915_CONTEXT_PARAM_NO_ZEROMAP:
-   if (args->size)
-   ret = -EINVAL;
-   else if (args->value)
-   set_bit(UCONTEXT_NO_ZEROMAP, >user_flags);
-   else
-   clear_bit(UCONTEXT_NO_ZEROMAP, >user_flags);
-   break;
-
case I915_CONTEXT_PARAM_NO_ERROR_CAPTURE:
if (args->size)
ret = -EINVAL;
@@ -1962,6 +1953,7 @@ static int ctx_setparam(struct drm_i915_file_private 
*fpriv,
ret = set_persistence(ctx, args);
break;
 
+   case I915_CONTEXT_PARAM_NO_ZEROMAP:
case I915_CONTEXT_PARAM_BAN_PERIOD:
case I915_CONTEXT_PARAM_RINGSIZE:
default:
@@ -2342,11 +2334,6 @@ int i915_gem_context_getparam_ioctl(struct drm_device 
*dev, void *data,
return -ENOENT;
 
switch (args->param) {
-   case I915_CONTEXT_PARAM_NO_ZEROMAP:
-   args->size = 0;
-   args->value = test_bit(UCONTEXT_NO_ZEROMAP, >user_flags);
-   break;
-
case I915_CONTEXT_PARAM_GTT_SIZE:
args->size = 0;
rcu_read_lock();
@@ -2394,6 +2381,7 @@ int i915_gem_context_getparam_ioctl(struct drm_device 
*dev, void *data,
args->value = i915_gem_context_is_persistent(ctx);
break;
 
+   case I915_CONTEXT_PARAM_NO_ZEROMAP:
case I915_CONTEXT_PARAM_BAN_PERIOD:
case I915_CONTEXT_PARAM_RINGSIZE:
default:
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h 
b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
index 1449f54924e03..676592e27e7d2 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
@@ -129,7 +129,6 @@ struct i915_gem_context {
 * @user_flags: small set of booleans controlled by the user
 */
unsigned long user_flags;
-#define UCONTEXT_NO_ZEROMAP0
 #define UCONTEXT_NO_ERROR_CAPTURE  1
 #define UCONTEXT_BANNABLE  2
 #define UCONTEXT_RECOVERABLE   3
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 21676baca8f58..96403130a373d 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -286,7 +286,6 @@ struct i915_execbuffer {
struct intel_context *reloc_context;
 
u64 invalid_flags; /** Set of execobj.flags that are invalid */
-   u32 context_flags; /** Set of execobj.flags to insert from the ctx */
 
u64 batch_len; /** Length of batch within object */
u32 batch_start_offset; /** Location within object of batch */
@@ -528,9 +527,6 @@ eb_validate_vma(struct i915_execbuffer *eb,
entry->flags |= EXEC_OBJECT_NEEDS_GTT | 
__EXEC_OBJECT_NEEDS_MAP;
}
 
-   if (!(entry->flags & EXEC_OBJECT_PINNED))
-   entry->flags |= eb->context_flags;
-
return 0;
 }
 
@@ -737,10 +733,6 @@ static int eb_select_context(struct i915_execbuffer *eb)
if (rcu_access_pointer(ctx->vm))
eb->invalid_flags |= EXEC_OBJECT_NEEDS_GTT;
 
-   eb->context_flags = 0;
-   if (test_bit(UCONTEXT_NO_ZEROMAP, >user_flags))
-   eb->context_flags |= __EXEC_OBJECT_NEEDS_BIAS;
-
return 0;
 }
 
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index a80eb2bcd22bc..4c4b9254def1b 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ 

[PATCH 3/4] drm/i915: Drop the CONTEXT_CLONE API

[Jason Ekstrand]

This API allows one context to grab bits out of another context upon
creation.  It can be used as a short-cut for setparam(getparam()) for
things like I915_CONTEXT_PARAM_VM.  However, it's never been used by any
real userspace.  It's used by a few IGT tests and that's it.  Since it
doesn't add any real value (most of the stuff you can CLONE you can copy
in other ways), drop it.

There is one thing that this API allows you to clone which you cannot
clone via getparam/setparam: timelines.  However, timelines are an
implementation detail of i915 and not really something that needs to be
exposed to userspace.  Also, sharing timelines between contexts isn't
obviously useful and supporting it has the potential to complicate i915
internally.  It also doesn't add any functionality that the client can't
get in other ways.  If a client really wants a shared timeline, they can
use a syncobj and set it as an in and out fence on every submit.

Signed-off-by: Jason Ekstrand 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/gem/i915_gem_context.c | 199 +---
 include/uapi/drm/i915_drm.h |  16 +-
 2 files changed, 6 insertions(+), 209 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index d28ac79de7573..f88bac19333ec 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1983,207 +1983,14 @@ static int create_setparam(struct i915_user_extension 
__user *ext, void *data)
return ctx_setparam(arg->fpriv, arg->ctx, );
 }
 
-static int clone_engines(struct i915_gem_context *dst,
-struct i915_gem_context *src)
+static int invalid_ext(struct i915_user_extension __user *ext, void *data)
 {
-   struct i915_gem_engines *clone, *e;
-   bool user_engines;
-   unsigned long n;
-
-   e = __context_engines_await(src, _engines);
-   if (!e)
-   return -ENOENT;
-
-   clone = alloc_engines(e->num_engines);
-   if (!clone)
-   goto err_unlock;
-
-   for (n = 0; n < e->num_engines; n++) {
-   struct intel_engine_cs *engine;
-
-   if (!e->engines[n]) {
-   clone->engines[n] = NULL;
-   continue;
-   }
-   engine = e->engines[n]->engine;
-
-   /*
-* Virtual engines are singletons; they can only exist
-* inside a single context, because they embed their
-* HW context... As each virtual context implies a single
-* timeline (each engine can only dequeue a single request
-* at any time), it would be surprising for two contexts
-* to use the same engine. So let's create a copy of
-* the virtual engine instead.
-*/
-   if (intel_engine_is_virtual(engine))
-   clone->engines[n] =
-   intel_execlists_clone_virtual(engine);
-   else
-   clone->engines[n] = intel_context_create(engine);
-   if (IS_ERR_OR_NULL(clone->engines[n])) {
-   __free_engines(clone, n);
-   goto err_unlock;
-   }
-
-   intel_context_set_gem(clone->engines[n], dst);
-   }
-   clone->num_engines = n;
-   i915_sw_fence_complete(>fence);
-
-   /* Serialised by constructor */
-   engines_idle_release(dst, rcu_replace_pointer(dst->engines, clone, 1));
-   if (user_engines)
-   i915_gem_context_set_user_engines(dst);
-   else
-   i915_gem_context_clear_user_engines(dst);
-   return 0;
-
-err_unlock:
-   i915_sw_fence_complete(>fence);
-   return -ENOMEM;
-}
-
-static int clone_flags(struct i915_gem_context *dst,
-  struct i915_gem_context *src)
-{
-   dst->user_flags = src->user_flags;
-   return 0;
-}
-
-static int clone_schedattr(struct i915_gem_context *dst,
-  struct i915_gem_context *src)
-{
-   dst->sched = src->sched;
-   return 0;
-}
-
-static int clone_sseu(struct i915_gem_context *dst,
- struct i915_gem_context *src)
-{
-   struct i915_gem_engines *e = i915_gem_context_lock_engines(src);
-   struct i915_gem_engines *clone;
-   unsigned long n;
-   int err;
-
-   /* no locking required; sole access under constructor*/
-   clone = __context_engines_static(dst);
-   if (e->num_engines != clone->num_engines) {
-   err = -EINVAL;
-   goto unlock;
-   }
-
-   for (n = 0; n < e->num_engines; n++) {
-   struct intel_context *ce = e->engines[n];
-
-   if (clone->engines[n]->engine->class != ce->engine->class) {
-   /* Must have compatible engine maps! */
-   err = -EINVAL;
-   

[PATCH 1/4] drm/i915: Drop I915_CONTEXT_PARAM_RINGSIZE

[Jason Ekstrand]

This reverts commit 88be76cdafc7e60e2e4ed883bfe7e8dd7f35fa3a.  This API
has never been used by any real userspace.

Signed-off-by: Jason Ekstrand 
---
 drivers/gpu/drm/i915/Makefile |   1 -
 drivers/gpu/drm/i915/gem/i915_gem_context.c   | 112 ++
 drivers/gpu/drm/i915/gt/intel_context_param.c |  63 --
 drivers/gpu/drm/i915/gt/intel_context_param.h |  14 ---
 include/uapi/drm/i915_drm.h   |  20 +---
 5 files changed, 12 insertions(+), 198 deletions(-)
 delete mode 100644 drivers/gpu/drm/i915/gt/intel_context_param.c
 delete mode 100644 drivers/gpu/drm/i915/gt/intel_context_param.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 921db06232c35..6825988f0328f 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -87,7 +87,6 @@ gt-y += \
gt/gen8_ppgtt.o \
gt/intel_breadcrumbs.o \
gt/intel_context.o \
-   gt/intel_context_param.o \
gt/intel_context_sseu.o \
gt/intel_engine_cs.o \
gt/intel_engine_heartbeat.o \
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 4d2f40cf237bd..c528db3b7dcf4 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -69,7 +69,6 @@
 
 #include "gt/gen6_ppgtt.h"
 #include "gt/intel_context.h"
-#include "gt/intel_context_param.h"
 #include "gt/intel_engine_heartbeat.h"
 #include "gt/intel_engine_user.h"
 #include "gt/intel_execlists_submission.h" /* virtual_engine */
@@ -744,32 +743,25 @@ __context_engines_await(const struct i915_gem_context 
*ctx,
return engines;
 }
 
-static int
+static void
 context_apply_all(struct i915_gem_context *ctx,
- int (*fn)(struct intel_context *ce, void *data),
+ void (*fn)(struct intel_context *ce, void *data),
  void *data)
 {
struct i915_gem_engines_iter it;
struct i915_gem_engines *e;
struct intel_context *ce;
-   int err = 0;
 
e = __context_engines_await(ctx, NULL);
-   for_each_gem_engine(ce, e, it) {
-   err = fn(ce, data);
-   if (err)
-   break;
-   }
+   for_each_gem_engine(ce, e, it)
+   fn(ce, data);
i915_sw_fence_complete(>fence);
-
-   return err;
 }
 
-static int __apply_ppgtt(struct intel_context *ce, void *vm)
+static void __apply_ppgtt(struct intel_context *ce, void *vm)
 {
i915_vm_put(ce->vm);
ce->vm = i915_vm_get(vm);
-   return 0;
 }
 
 static struct i915_address_space *
@@ -809,10 +801,9 @@ static void __set_timeline(struct intel_timeline **dst,
intel_timeline_put(old);
 }
 
-static int __apply_timeline(struct intel_context *ce, void *timeline)
+static void __apply_timeline(struct intel_context *ce, void *timeline)
 {
__set_timeline(>timeline, timeline);
-   return 0;
 }
 
 static void __assign_timeline(struct i915_gem_context *ctx,
@@ -1328,63 +1319,6 @@ static int set_ppgtt(struct drm_i915_file_private 
*file_priv,
return err;
 }
 
-static int __apply_ringsize(struct intel_context *ce, void *sz)
-{
-   return intel_context_set_ring_size(ce, (unsigned long)sz);
-}
-
-static int set_ringsize(struct i915_gem_context *ctx,
-   struct drm_i915_gem_context_param *args)
-{
-   if (!HAS_LOGICAL_RING_CONTEXTS(ctx->i915))
-   return -ENODEV;
-
-   if (args->size)
-   return -EINVAL;
-
-   if (!IS_ALIGNED(args->value, I915_GTT_PAGE_SIZE))
-   return -EINVAL;
-
-   if (args->value < I915_GTT_PAGE_SIZE)
-   return -EINVAL;
-
-   if (args->value > 128 * I915_GTT_PAGE_SIZE)
-   return -EINVAL;
-
-   return context_apply_all(ctx,
-__apply_ringsize,
-__intel_context_ring_size(args->value));
-}
-
-static int __get_ringsize(struct intel_context *ce, void *arg)
-{
-   long sz;
-
-   sz = intel_context_get_ring_size(ce);
-   GEM_BUG_ON(sz > INT_MAX);
-
-   return sz; /* stop on first engine */
-}
-
-static int get_ringsize(struct i915_gem_context *ctx,
-   struct drm_i915_gem_context_param *args)
-{
-   int sz;
-
-   if (!HAS_LOGICAL_RING_CONTEXTS(ctx->i915))
-   return -ENODEV;
-
-   if (args->size)
-   return -EINVAL;
-
-   sz = context_apply_all(ctx, __get_ringsize, NULL);
-   if (sz < 0)
-   return sz;
-
-   args->value = sz;
-   return 0;
-}
-
 int
 i915_gem_user_to_context_sseu(struct intel_gt *gt,
  const struct drm_i915_gem_context_param_sseu 
*user,
@@ -1925,19 +1859,17 @@ set_persistence(struct i915_gem_context *ctx,
return __context_set_persistence(ctx, args->value);
 }
 
-static int __apply_priority(struct intel_context *ce, void *arg)

[PATCH 0/4] drm/i915: uAPI clean-ups part 2

[Jason Ekstrand]

This patch series is the second installment of my quest to clean up the
i915 uAPI.  The first three patches delete interfaces which have only ever
been used by i-g-t and never any real userspace.  In the case of NO_ZEROMAP,
it's unclear exactly how this happened.  There were userspace patches for
it back in the day, they just never landed.  For the others, there was
never any userspace beyond i-g-t and they never should have landed in the
first place.

The last patch moves the SINGLE_TIMELINE API to an emulation using syncobj
to help simplify some of our locking infrastructure.

Test-with: 20210319223233.2982842-1-ja...@jlekstrand.net

Jason Ekstrand (4):
  drm/i915: Drop I915_CONTEXT_PARAM_RINGSIZE
  drm/i915: Drop I915_CONTEXT_PARAM_NO_ZEROMAP
  drm/i915: Drop the CONTEXT_CLONE API
  drm/i915: Implement SINGLE_TIMELINE with a syncobj

 drivers/gpu/drm/i915/Makefile |   1 -
 drivers/gpu/drm/i915/gem/i915_gem_context.c   | 372 ++
 .../gpu/drm/i915/gem/i915_gem_context_types.h |   9 +-
 .../gpu/drm/i915/gem/i915_gem_execbuffer.c|  23 +-
 drivers/gpu/drm/i915/gt/intel_context_param.c |  63 ---
 drivers/gpu/drm/i915/gt/intel_context_param.h |  14 -
 include/uapi/drm/i915_drm.h   |  40 +-
 7 files changed, 55 insertions(+), 467 deletions(-)
 delete mode 100644 drivers/gpu/drm/i915/gt/intel_context_param.c
 delete mode 100644 drivers/gpu/drm/i915/gt/intel_context_param.h

-- 
2.29.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/5] drm/fourcc: Add 16 bpc fixed point framebuffer formats.

[Mario Kleiner]

On Fri, Mar 19, 2021 at 10:16 PM Ville Syrjälä
 wrote:
>
> On Fri, Mar 19, 2021 at 10:03:13PM +0100, Mario Kleiner wrote:
> > These are 16 bits per color channel unsigned normalized formats.
> > They are supported by at least AMD display hw, and suitable for
> > direct scanout of Vulkan swapchain images in the format
> > VK_FORMAT_R16G16B16A16_UNORM.
> >
> > Signed-off-by: Mario Kleiner 
> > ---
> >  drivers/gpu/drm/drm_fourcc.c  | 4 
> >  include/uapi/drm/drm_fourcc.h | 7 +++
> >  2 files changed, 11 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> > index 03262472059c..ce13d2be5d7b 100644
> > --- a/drivers/gpu/drm/drm_fourcc.c
> > +++ b/drivers/gpu/drm/drm_fourcc.c
> > @@ -203,6 +203,10 @@ const struct drm_format_info *__drm_format_info(u32 
> > format)
> >   { .format = DRM_FORMAT_ARGB16161616F,   .depth = 0,  
> > .num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = 
> > true },
> >   { .format = DRM_FORMAT_ABGR16161616F,   .depth = 0,  
> > .num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = 
> > true },
> >   { .format = DRM_FORMAT_AXBXGXRX106106106106, .depth = 0, 
> > .num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = 
> > true },
> > + { .format = DRM_FORMAT_XRGB16161616,.depth = 0,  
> > .num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1 },
> > + { .format = DRM_FORMAT_XBGR16161616,.depth = 0,  
> > .num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1 },
> > + { .format = DRM_FORMAT_ARGB16161616,.depth = 0,  
> > .num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = 
> > true },
> > + { .format = DRM_FORMAT_ABGR16161616,.depth = 0,  
> > .num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = 
> > true },
> >   { .format = DRM_FORMAT_RGB888_A8,   .depth = 32, 
> > .num_planes = 2, .cpp = { 3, 1, 0 }, .hsub = 1, .vsub = 1, .has_alpha = 
> > true },
> >   { .format = DRM_FORMAT_BGR888_A8,   .depth = 32, 
> > .num_planes = 2, .cpp = { 3, 1, 0 }, .hsub = 1, .vsub = 1, .has_alpha = 
> > true },
> >   { .format = DRM_FORMAT_XRGB_A8, .depth = 32, 
> > .num_planes = 2, .cpp = { 4, 1, 0 }, .hsub = 1, .vsub = 1, .has_alpha = 
> > true },
> > diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> > index f76de49c768f..f7156322aba5 100644
> > --- a/include/uapi/drm/drm_fourcc.h
> > +++ b/include/uapi/drm/drm_fourcc.h
> > @@ -168,6 +168,13 @@ extern "C" {
> >  #define DRM_FORMAT_RGBA1010102   fourcc_code('R', 'A', '3', '0') /* 
> > [31:0] R:G:B:A 10:10:10:2 little endian */
> >  #define DRM_FORMAT_BGRA1010102   fourcc_code('B', 'A', '3', '0') /* 
> > [31:0] B:G:R:A 10:10:10:2 little endian */
> >
> > +/* 64 bpp RGB */
> > +#define DRM_FORMAT_XRGB16161616  fourcc_code('X', 'R', '4', '8') /* 
> > [63:0] x:R:G:B 16:16:16:16 little endian */
> > +#define DRM_FORMAT_XBGR16161616  fourcc_code('X', 'B', '4', '8') /* 
> > [63:0] x:B:G:R 16:16:16:16 little endian */
> > +
> > +#define DRM_FORMAT_ARGB16161616  fourcc_code('A', 'R', '4', '8') /* 
> > [63:0] A:R:G:B 16:16:16:16 little endian */
> > +#define DRM_FORMAT_ABGR16161616  fourcc_code('A', 'B', '4', '8') /* 
> > [63:0] A:B:G:R 16:16:16:16 little endian */
>
> These look reasonable enough to me. IIRC we should be able to expose
> them on some recent Intel hw as well.
>
> Reviewed-by: Ville Syrjälä 
>

Thanks Ville!

Indeed i looked over the Intel PRM's, and while fp16 support seems to
be rather recent (Gen8? Gen9? Gen10? Can't remember atm.), iirc, I
found references to rgb16 fixed point back to gen5 / Ironlake. That
would be pretty cool! The precision limit for the encoders on Intel is
also 12 bpc atm., right?

-mario

> --
> Ville Syrjälä
> Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/amd/display: Set AMDGPU_DM_DEFAULT_MIN_BACKLIGHT to 0

[Alex Deucher]

On Fri, Mar 19, 2021 at 5:31 PM Evan Benn  wrote:
>
> On Sat, 20 Mar 2021 at 02:10, Harry Wentland  wrote:
> > On 2021-03-19 10:22 a.m., Alex Deucher wrote:
> > > On Fri, Mar 19, 2021 at 3:23 AM Evan Benn  wrote:
> > >>
> > >> AMDGPU_DM_DEFAULT_MIN_BACKLIGHT was set to the value of 12
> > >> to ensure no display backlight will flicker at low user brightness
> > >> settings. However this value is quite bright, so for devices that do not
> > >> implement the ACPI ATIF
> > >> ATIF_FUNCTION_QUERY_BRIGHTNESS_TRANSFER_CHARACTERISTICS
> > >> functionality the user cannot set the brightness to a low level even if
> > >> the display would support such a low PWM.
> > >>
> > >> This ATIF feature is not implemented on for example AMD grunt 
> > >> chromebooks.
> > >>
> > >> Signed-off-by: Evan Benn 
> > >>
> > >> ---
> > >> I could not find a justification for the reason for the value. It has
> > >> caused some noticable regression for users: 
> > >> https://bugzilla.kernel.org/show_bug.cgi?id=203439>>>
> > >> Maybe this can be either user controlled or userspace configured, but
> > >> preventing users from turning their backlight dim seems wrong.
> > >
> > > My understanding is that some panels flicker if you set the min to a
> > > value too low.  This was a safe minimum if the platform didn't specify
> > > it's own safe minimum.  I think we'd just be trading one bug for
> > > another (flickering vs not dim enough).  Maybe a whitelist or
> > > blacklist would be a better solution?
> > >
> >
> > Yeah, this is a NACK from me as-is for the reasons Alex described.
>
> Thanks Harry + Alex,
>
> I agree this solution is not the best.
>
> >
> > I agree a whitelist approach might be best.
>
> Do you have any idea what an allowlist could be keyed on?
> Is the flickering you observed here a function of the panel or the gpu
> or some other component?
> Maybe we could move the minimum level into the logic for that hardware.
>

Maybe the panel string from the EDID?  Either that or something from
dmi data?  Harry would probably have a better idea.

Alex

> >
> > Is this fix perhaps for OLED panels? If so we could use a different
> > min-value for OLED panels that don't do PWM, but use 12 for everything else.
>
> All the chromebooks I have worked with LCD + LED backlight have been
> fine with a backlight set to 0.
> We do have OLED panels too, but I'm not aware of what they do.
>
> > Harry
> >
> > > Alex
> > >
> > >
> > >>
> > >> Also reviewed here: 
> > >> https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/2748377>>>
> > >>   drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +-
> > >>   1 file changed, 1 insertion(+), 1 deletion(-)
> > >>
> > >> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
> > >> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > >> index 573cf17262da..0129bd69b94e 100644
> > >> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > >> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > >> @@ -3151,7 +3151,7 @@ static int amdgpu_dm_mode_config_init(struct 
> > >> amdgpu_device *adev)
> > >>  return 0;
> > >>   }
> > >>
> > >> -#define AMDGPU_DM_DEFAULT_MIN_BACKLIGHT 12
> > >> +#define AMDGPU_DM_DEFAULT_MIN_BACKLIGHT 0
> > >>   #define AMDGPU_DM_DEFAULT_MAX_BACKLIGHT 255
> > >>   #define AUX_BL_DEFAULT_TRANSITION_TIME_MS 50
> > >>
> > >> --
> > >> 2.31.0.291.g576ba9dcdaf-goog
> > >>
> > >> ___
> > >> 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: [PATCH] drm/atomic: Add the crtc to affected crtc only if uapi.enable = true

[Ville Syrjälä]

On Fri, Mar 19, 2021 at 02:26:24PM -0700, Navare, Manasi wrote:
> On Fri, Mar 19, 2021 at 11:12:41PM +0200, Ville Syrjälä wrote:
> > On Fri, Mar 19, 2021 at 01:54:13PM -0700, Navare, Manasi wrote:
> > > On Fri, Mar 19, 2021 at 04:56:24PM +0200, Ville Syrjälä wrote:
> > > > On Thu, Mar 18, 2021 at 04:01:26PM -0700, Navare, Manasi wrote:
> > > > > So basically we see this warning only in case of bigjoiner when
> > > > > drm_atomic_check gets called without setting the state->allow_modeset 
> > > > > flag.
> > > > 
> > > > Considering the code is 'WARN(!state->allow_modeset, ...' that
> > > > fact should be rather obvious.
> > > > 
> > > > > 
> > > > > So do you think that in i915, in intel_atomic_check_bigjoiner() we 
> > > > > should only
> > > > > steal the crtc when allow_modeset flag is set in state?
> > > > 
> > > > No. If you fully read drm_atomic_check_only() you will observe
> > > > that it will reject any commit w/ allow_modeset==false which 
> > > > needs a modeset. And it does that before the WARN.
> > > > 
> > > > So you're barking up the wrong tree here. The problem I think
> > > > is that you're just computing requested_crtcs wrong.
> > > 
> > > So here in this case, requested CRTC = 0x1 since it requests modeset on 
> > > CRTC 0
> > > Now in teh atomic check, it steals the slave CRTC 1 and hence affected 
> > > CRTC comes out
> > > as 0x3 and hence the mismatch.
> > 
> > Hmm. How can it be 0x3 if we filtered out the uapi.enable==false case?
> > 
> 
> Yes if I add that condition like in this patch then it correctly calculates
> the affected crtc bitmask as only 0x1 since it doesnt include the slave crtc.
> So with this patch, requested crtc = 0x 1, affected crtc = 0x1
> 
> If this looks good then this fixes our bigjoiner warnings.
> Does this patch look good to you as is then?

I think you still need to fix the requested_crtcs calculation.

-- 
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[pull] amdgpu, amdkfd, radeon drm-next-5.13

[Alex Deucher]

Hi Dave, Daniel,

New stuff for 5.13.

The following changes since commit 6e80fb8ab04f6c4f377e2fd422bdd1855beb7371:

  drm/amdgpu: Set reference clock to 100Mhz on Renoir (v2) (2021-02-18 16:43:09 
-0500)

are available in the Git repository at:

  https://gitlab.freedesktop.org/agd5f/linux.git 
tags/amd-drm-next-5.13-2021-03-19

for you to fetch changes up to 50487c677b9362a7df761f225b15f95a2157783d:

  drm/amdkfd: Bump KFD API version (2021-03-19 16:38:42 -0400)


amd-drm-next-5.13-2021-03-19:

amdgpu:
- Debugfs cleanup
- Various cleanups and spelling fixes
- Flexible array cleanups
- Initial AMD Freesync HDMI
- Display fixes
- 10bpc dithering improvements
- Display ASSR support
- Clean up and unify powerplay and swsmu interfaces
- Vangogh fixes
- Add SMU gfx busy queues for RV/PCO
- PCIE DPM fixes
- S0ix fixes
- GPU metrics data fixes
- DCN secure display support
- Backlight type override
- Add initial support for Aldebaran
- RAS fixes
- Prime fixes for A+A systems
- Reset fixes
- Initial resource cursor support
- Drop legacy IO BAR requirements
- Various power fixes

amdkfd:
- MMU notifier fixes
- APU fixes

radeon:
- Debugfs cleanups
- Flexible array cleanups

UAPI:
- amdgpu: Add a new INFO ioctl interface to query video capabilities
  rather than hardcoding them in userspace.  This allows us to provide
  fine grained asic capabilities (e.g., if a particular part is
  bandwidth limited, we can limit the capabilities).  Proposed userspace:
  https://gitlab.freedesktop.org/leoliu/drm/-/commits/info_video_caps
  https://gitlab.freedesktop.org/leoliu/mesa/-/commits/info_video_caps
- amdkfd: bump the driver version.  There was a problem with reporting
  some RAS features on older versions of the driver. Proposed userspace:
  
https://github.com/RadeonOpenCompute/ROCT-Thunk-Interface/commit/7cdd63475c36bb9f49bb960f90f9a8cdb7e80a21


Alex Deucher (21):
  drm/amdgpu: add asic callback for querying video codec info (v3)
  drm/amdgpu: add video decode/encode cap tables and asic callbacks (v3)
  drm/amdgpu: add INFO ioctl support for querying video caps (v4)
  drm/amdgpu: bump driver version for new video codec INFO ioctl query
  drm/amdgpu/codec: drop the internal codec index
  drm/amdgpu/pm: make unsupported power profile messages debug
  drm/amdgpu/swsmu/vangogh: Only use RLCPowerNotify msg for disable
  drm/amdgpu: Only check for S0ix if AMD_PMC is configured
  drm/amdgpu: enable BACO runpm by default on sienna cichlid and navy 
flounder
  drm/amdgpu: enable TMZ by default on Raven asics
  drm/amdgpu/dc: fill in missing call to atom cmd table for pll adjust v2
  drm/amdgpu/display: simplify backlight setting
  drm/amdgpu/display: don't assert in set backlight function
  drm/amdgpu/display: handle aux backlight in backlight_get_brightness
  drm/amdgpu: add mmhub client ids for aldebaran
  drm/amdgpu: fix S0ix handling when the CONFIG_AMD_PMC=m
  drm/amdgpu/powerplay/smu10: add support for gpu busy query (v2)
  drm/amdgpu/smu8: return an error rather than 50% if busy query fails
  drm/amdgpu: drop legacy IO bar support
  drm/amdgpu: drop extraneous hw_status update
  drm/amdgpu/display: properly guard dc_dsc_stream_bandwidth_in_kbps

Alex Sierra (4):
  drm/amdgpu: UTLC1 RB SDMA timeout on Aldebaran
  drm/amdgpu: enable 48-bit IH timestamp counter
  drm/amdgpu: update mmhub client ids for Aldebaran
  drm/amdgpu: use pd addr based on gart level page table

Amber Lin (1):
  drm/amdgpu: Aldebaran doesn't use semaphore

Anson Jacob (5):
  Revert "drm/amd/display: reuse current context instead of recreating one"
  drm/amdkfd: Fix UBSAN shift-out-of-bounds warning
  Revert "drm/amd/display: remove duplicate include in amdgpu_dm.c"
  drm/amd/display: remove duplicate include in amdgpu_dm.c
  drm/amd/display: Fix UBSAN warning for not a valid value for type '_Bool'

Anthony Koo (5):
  drm/amd/display: [FW Promotion] Release 0.0.52
  drm/amd/display: [FW Promotion] Release 0.0.53
  drm/amd/display: [FW Promotion] Release 0.0.54
  drm/amd/display: [FW Promotion] Release 0.0.55
  drm/amd/display: [FW Promotion] Release 0.0.56

Anthony Wang (2):
  drm/amd/display: disable seamless boot for DP MST
  drm/amd/display: enable audio on DP seamless boot

Aric Cyr (10):
  drm/amd/display: 3.2.123
  drm/amd/display: Don't optimize bandwidth before disabling planes
  drm/amd/display: reduce scope for local var
  drm/amd/display: 3.2.124
  drm/amd/display: 3.2.125
  drm/amd/display: 3.2.126
  drm/amd/display: 3.2.126.1
  drm/amd/display: System black screen hangs on driver load
  drm/amd/display: DCHUB underflow counter increasing in some scenarios
  drm/amd/display: 3.2.127

Arnd Bergmann (1):
  drm/amd/display: 

Re: [PATCH] drm/atomic: Add the crtc to affected crtc only if uapi.enable = true

[Navare, Manasi]

On Fri, Mar 19, 2021 at 11:12:41PM +0200, Ville Syrjälä wrote:
> On Fri, Mar 19, 2021 at 01:54:13PM -0700, Navare, Manasi wrote:
> > On Fri, Mar 19, 2021 at 04:56:24PM +0200, Ville Syrjälä wrote:
> > > On Thu, Mar 18, 2021 at 04:01:26PM -0700, Navare, Manasi wrote:
> > > > So basically we see this warning only in case of bigjoiner when
> > > > drm_atomic_check gets called without setting the state->allow_modeset 
> > > > flag.
> > > 
> > > Considering the code is 'WARN(!state->allow_modeset, ...' that
> > > fact should be rather obvious.
> > > 
> > > > 
> > > > So do you think that in i915, in intel_atomic_check_bigjoiner() we 
> > > > should only
> > > > steal the crtc when allow_modeset flag is set in state?
> > > 
> > > No. If you fully read drm_atomic_check_only() you will observe
> > > that it will reject any commit w/ allow_modeset==false which 
> > > needs a modeset. And it does that before the WARN.
> > > 
> > > So you're barking up the wrong tree here. The problem I think
> > > is that you're just computing requested_crtcs wrong.
> > 
> > So here in this case, requested CRTC = 0x1 since it requests modeset on 
> > CRTC 0
> > Now in teh atomic check, it steals the slave CRTC 1 and hence affected CRTC 
> > comes out
> > as 0x3 and hence the mismatch.
> 
> Hmm. How can it be 0x3 if we filtered out the uapi.enable==false case?
> 

Yes if I add that condition like in this patch then it correctly calculates
the affected crtc bitmask as only 0x1 since it doesnt include the slave crtc.
So with this patch, requested crtc = 0x 1, affected crtc = 0x1

If this looks good then this fixes our bigjoiner warnings.
Does this patch look good to you as is then?

Manasi

> > Now what is not clear to me is that if a full modeset was not required
> > why did i915 still steal that slave CRTC?
> > 
> > Manasi
> > 
> > > 
> > > > If we add this check there then the affected crtc wont count the slave 
> > > > crtc
> > > > and we wont get this warning.
> > > > 
> > > > Ville, Danvet?
> > > > 
> > > > Manasi
> > > > 
> > > > 
> > > > On Tue, Mar 16, 2021 at 10:35:09PM +0100, Daniel Vetter wrote:
> > > > > On Tue, Mar 9, 2021 at 10:14 AM Pekka Paalanen  
> > > > > wrote:
> > > > > >
> > > > > > On Mon, 8 Mar 2021 16:52:58 -0800
> > > > > > "Navare, Manasi"  wrote:
> > > > > >
> > > > > > > On Thu, Mar 04, 2021 at 10:42:23AM +0200, Pekka Paalanen wrote:
> > > > > > > > On Wed, 3 Mar 2021 12:44:33 -0800
> > > > > > > > "Navare, Manasi"  wrote:
> > > > > > > >
> > > > > > > > > On Wed, Mar 03, 2021 at 10:47:44AM +0200, Pekka Paalanen 
> > > > > > > > > wrote:
> > > > > > > > > > On Tue,  2 Mar 2021 12:41:32 -0800
> > > > > > > > > > Manasi Navare  wrote:
> > > > > > > > > >
> > > > > > > > > > > In case of a modeset where a mode gets split across 
> > > > > > > > > > > mutiple CRTCs
> > > > > > > > > > > in the driver specific implementation (bigjoiner in i915) 
> > > > > > > > > > > we wrongly count
> > > > > > > > > > > the affected CRTCs based on the drm_crtc_mask and 
> > > > > > > > > > > indicate the stolen CRTC as
> > > > > > > > > > > an affected CRTC in atomic_check_only().
> > > > > > > > > > > This triggers a warning since affected CRTCs doent match 
> > > > > > > > > > > requested CRTC.
> > > > > > > > > > >
> > > > > > > > > > > To fix this in such bigjoiner configurations, we should 
> > > > > > > > > > > only
> > > > > > > > > > > increment affected crtcs if that CRTC is enabled in UAPI 
> > > > > > > > > > > not
> > > > > > > > > > > if it is just used internally in the driver to split the 
> > > > > > > > > > > mode.
> > > > > > > > > >
> > > > > > > > > > Hi,
> > > > > > > > > >
> > > > > > > > > > I think that makes sense to me. Stealing CRTCs that are not 
> > > > > > > > > > currently
> > > > > > > > > > used by the userspace (display server) should be ok, as 
> > > > > > > > > > long as that
> > > > > > > > > > is completely invisible to userspace: meaning that it does 
> > > > > > > > > > not cause
> > > > > > > > > > userspace to unexpectedly e.g. receive or miss per-crtc 
> > > > > > > > > > atomic
> > > > > > > > > > completion events.
> > > > > > > > >
> > > > > > > > > Yes since we are only doing atomic_check_only() here, the 
> > > > > > > > > stolen
> > > > > > > >
> > > > > > > > But the real not-test-only commit will follow if this test-only 
> > > > > > > > commit
> > > > > > > > succeeds, and keeping the guarantees for the real commit are 
> > > > > > > > important.
> > > > > > >
> > > > > > > Hmm well after the actual real commit, since the second crtc is 
> > > > > > > stolen
> > > > > > > even though it is not being used for the display output, it is
> > > > > > > used for joiner so the uapi.enable will be true after the real 
> > > > > > > commit.
> > > > > > >
> > > > > > > so actually the assertion would fail in this case.
> > > > > > >
> > > > > > > @Ville @Danvet any suggestions here in that case?
> > > > > 
> > > > > That is very bad. We can't frob uapi state like that. I think that
> 

Re: [PATCH 1/5] drm/fourcc: Add 16 bpc fixed point framebuffer formats.

[Ville Syrjälä]

On Fri, Mar 19, 2021 at 10:03:13PM +0100, Mario Kleiner wrote:
> These are 16 bits per color channel unsigned normalized formats.
> They are supported by at least AMD display hw, and suitable for
> direct scanout of Vulkan swapchain images in the format
> VK_FORMAT_R16G16B16A16_UNORM.
> 
> Signed-off-by: Mario Kleiner 
> ---
>  drivers/gpu/drm/drm_fourcc.c  | 4 
>  include/uapi/drm/drm_fourcc.h | 7 +++
>  2 files changed, 11 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> index 03262472059c..ce13d2be5d7b 100644
> --- a/drivers/gpu/drm/drm_fourcc.c
> +++ b/drivers/gpu/drm/drm_fourcc.c
> @@ -203,6 +203,10 @@ const struct drm_format_info *__drm_format_info(u32 
> format)
>   { .format = DRM_FORMAT_ARGB16161616F,   .depth = 0,  
> .num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true 
> },
>   { .format = DRM_FORMAT_ABGR16161616F,   .depth = 0,  
> .num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true 
> },
>   { .format = DRM_FORMAT_AXBXGXRX106106106106, .depth = 0, 
> .num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true 
> },
> + { .format = DRM_FORMAT_XRGB16161616,.depth = 0,  
> .num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1 },
> + { .format = DRM_FORMAT_XBGR16161616,.depth = 0,  
> .num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1 },
> + { .format = DRM_FORMAT_ARGB16161616,.depth = 0,  
> .num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true 
> },
> + { .format = DRM_FORMAT_ABGR16161616,.depth = 0,  
> .num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true 
> },
>   { .format = DRM_FORMAT_RGB888_A8,   .depth = 32, 
> .num_planes = 2, .cpp = { 3, 1, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true 
> },
>   { .format = DRM_FORMAT_BGR888_A8,   .depth = 32, 
> .num_planes = 2, .cpp = { 3, 1, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true 
> },
>   { .format = DRM_FORMAT_XRGB_A8, .depth = 32, 
> .num_planes = 2, .cpp = { 4, 1, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true 
> },
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index f76de49c768f..f7156322aba5 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -168,6 +168,13 @@ extern "C" {
>  #define DRM_FORMAT_RGBA1010102   fourcc_code('R', 'A', '3', '0') /* 
> [31:0] R:G:B:A 10:10:10:2 little endian */
>  #define DRM_FORMAT_BGRA1010102   fourcc_code('B', 'A', '3', '0') /* 
> [31:0] B:G:R:A 10:10:10:2 little endian */
>  
> +/* 64 bpp RGB */
> +#define DRM_FORMAT_XRGB16161616  fourcc_code('X', 'R', '4', '8') /* 
> [63:0] x:R:G:B 16:16:16:16 little endian */
> +#define DRM_FORMAT_XBGR16161616  fourcc_code('X', 'B', '4', '8') /* 
> [63:0] x:B:G:R 16:16:16:16 little endian */
> +
> +#define DRM_FORMAT_ARGB16161616  fourcc_code('A', 'R', '4', '8') /* 
> [63:0] A:R:G:B 16:16:16:16 little endian */
> +#define DRM_FORMAT_ABGR16161616  fourcc_code('A', 'B', '4', '8') /* 
> [63:0] A:B:G:R 16:16:16:16 little endian */

These look reasonable enough to me. IIRC we should be able to expose
them on some recent Intel hw as well.

Reviewed-by: Ville Syrjälä 

-- 
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/atomic: Add the crtc to affected crtc only if uapi.enable = true

[Ville Syrjälä]

On Fri, Mar 19, 2021 at 01:54:13PM -0700, Navare, Manasi wrote:
> On Fri, Mar 19, 2021 at 04:56:24PM +0200, Ville Syrjälä wrote:
> > On Thu, Mar 18, 2021 at 04:01:26PM -0700, Navare, Manasi wrote:
> > > So basically we see this warning only in case of bigjoiner when
> > > drm_atomic_check gets called without setting the state->allow_modeset 
> > > flag.
> > 
> > Considering the code is 'WARN(!state->allow_modeset, ...' that
> > fact should be rather obvious.
> > 
> > > 
> > > So do you think that in i915, in intel_atomic_check_bigjoiner() we should 
> > > only
> > > steal the crtc when allow_modeset flag is set in state?
> > 
> > No. If you fully read drm_atomic_check_only() you will observe
> > that it will reject any commit w/ allow_modeset==false which 
> > needs a modeset. And it does that before the WARN.
> > 
> > So you're barking up the wrong tree here. The problem I think
> > is that you're just computing requested_crtcs wrong.
> 
> So here in this case, requested CRTC = 0x1 since it requests modeset on CRTC 0
> Now in teh atomic check, it steals the slave CRTC 1 and hence affected CRTC 
> comes out
> as 0x3 and hence the mismatch.

Hmm. How can it be 0x3 if we filtered out the uapi.enable==false case?

> Now what is not clear to me is that if a full modeset was not required
> why did i915 still steal that slave CRTC?
> 
> Manasi
> 
> > 
> > > If we add this check there then the affected crtc wont count the slave 
> > > crtc
> > > and we wont get this warning.
> > > 
> > > Ville, Danvet?
> > > 
> > > Manasi
> > > 
> > > 
> > > On Tue, Mar 16, 2021 at 10:35:09PM +0100, Daniel Vetter wrote:
> > > > On Tue, Mar 9, 2021 at 10:14 AM Pekka Paalanen  
> > > > wrote:
> > > > >
> > > > > On Mon, 8 Mar 2021 16:52:58 -0800
> > > > > "Navare, Manasi"  wrote:
> > > > >
> > > > > > On Thu, Mar 04, 2021 at 10:42:23AM +0200, Pekka Paalanen wrote:
> > > > > > > On Wed, 3 Mar 2021 12:44:33 -0800
> > > > > > > "Navare, Manasi"  wrote:
> > > > > > >
> > > > > > > > On Wed, Mar 03, 2021 at 10:47:44AM +0200, Pekka Paalanen wrote:
> > > > > > > > > On Tue,  2 Mar 2021 12:41:32 -0800
> > > > > > > > > Manasi Navare  wrote:
> > > > > > > > >
> > > > > > > > > > In case of a modeset where a mode gets split across mutiple 
> > > > > > > > > > CRTCs
> > > > > > > > > > in the driver specific implementation (bigjoiner in i915) 
> > > > > > > > > > we wrongly count
> > > > > > > > > > the affected CRTCs based on the drm_crtc_mask and indicate 
> > > > > > > > > > the stolen CRTC as
> > > > > > > > > > an affected CRTC in atomic_check_only().
> > > > > > > > > > This triggers a warning since affected CRTCs doent match 
> > > > > > > > > > requested CRTC.
> > > > > > > > > >
> > > > > > > > > > To fix this in such bigjoiner configurations, we should only
> > > > > > > > > > increment affected crtcs if that CRTC is enabled in UAPI not
> > > > > > > > > > if it is just used internally in the driver to split the 
> > > > > > > > > > mode.
> > > > > > > > >
> > > > > > > > > Hi,
> > > > > > > > >
> > > > > > > > > I think that makes sense to me. Stealing CRTCs that are not 
> > > > > > > > > currently
> > > > > > > > > used by the userspace (display server) should be ok, as long 
> > > > > > > > > as that
> > > > > > > > > is completely invisible to userspace: meaning that it does 
> > > > > > > > > not cause
> > > > > > > > > userspace to unexpectedly e.g. receive or miss per-crtc atomic
> > > > > > > > > completion events.
> > > > > > > >
> > > > > > > > Yes since we are only doing atomic_check_only() here, the stolen
> > > > > > >
> > > > > > > But the real not-test-only commit will follow if this test-only 
> > > > > > > commit
> > > > > > > succeeds, and keeping the guarantees for the real commit are 
> > > > > > > important.
> > > > > >
> > > > > > Hmm well after the actual real commit, since the second crtc is 
> > > > > > stolen
> > > > > > even though it is not being used for the display output, it is
> > > > > > used for joiner so the uapi.enable will be true after the real 
> > > > > > commit.
> > > > > >
> > > > > > so actually the assertion would fail in this case.
> > > > > >
> > > > > > @Ville @Danvet any suggestions here in that case?
> > > > 
> > > > That is very bad. We can't frob uapi state like that. I think that
> > > > calls for even more checks to make sure kms drivers who try to play
> > > > clever games don't get it wrong, so we probably need to check uapi
> > > > enable and active state in another mask before/after ->atomic_check
> > > > too. Or something like that.
> > > > 
> > > > > Hi,
> > > > >
> > > > > that is not what I was talking about, but sounds like you found a
> > > > > different problem. It seems like the problem you are talking about
> > > > > would be guaranteed to be hit if bigjoiner was used. Have you not
> > > > > tested this?
> > > > >
> > > > > However, I was talking about the real commit itself, not what happens
> > > > > on commits after it, see below.
> > > > >
> > > > > > > > crtc 

[PATCH 5/5] drm/amd/display: Enable support for 16 bpc fixed-point framebuffers.

[Mario Kleiner]

This is intended to enable direct high-precision scanout and pageflip
of Vulkan swapchain images in format VK_FORMAT_R16G16B16A16_UNORM.

Expose DRM_FORMAT_XRGB16161616, DRM_FORMAT_ARGB16161616,
DRM_FORMAT_XBGR16161616 and DRM_FORMAT_ABGR16161616 as 16 bpc
unsigned normalized formats. These allow to take full advantage
of the maximum precision of the display hardware, ie. currently
up to 12 bpc.

Searching through old AMD M56, M76 and RV630 hw programming docs
suggests that these 16 bpc formats are supported by all DCE and
DCN display engines, so we can expose the formats unconditionally.

Successfully tested on AMD Polaris11 DCE-11.2 an RavenRidge DCN-1.0
with a HDR-10 monitor over 10 bpc DP output with spatial dithering
enabled by the driver. Picture looks good, and my photometer
measurement procedure confirms an effective 12 bpc color
reproduction.

Signed-off-by: Mario Kleiner 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 94cd5ddd67ef..1a6e90e20f10 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -4563,6 +4563,14 @@ fill_dc_plane_info_and_addr(struct amdgpu_device *adev,
case DRM_FORMAT_ABGR16161616F:
plane_info->format = SURFACE_PIXEL_FORMAT_GRPH_ABGR16161616F;
break;
+   case DRM_FORMAT_XRGB16161616:
+   case DRM_FORMAT_ARGB16161616:
+   plane_info->format = SURFACE_PIXEL_FORMAT_GRPH_ARGB16161616;
+   break;
+   case DRM_FORMAT_XBGR16161616:
+   case DRM_FORMAT_ABGR16161616:
+   plane_info->format = SURFACE_PIXEL_FORMAT_GRPH_ABGR16161616;
+   break;
default:
DRM_ERROR(
"Unsupported screen format %s\n",
@@ -6541,6 +6549,10 @@ static const uint32_t rgb_formats[] = {
DRM_FORMAT_XBGR2101010,
DRM_FORMAT_ARGB2101010,
DRM_FORMAT_ABGR2101010,
+   DRM_FORMAT_XRGB16161616,
+   DRM_FORMAT_XBGR16161616,
+   DRM_FORMAT_ARGB16161616,
+   DRM_FORMAT_ABGR16161616,
DRM_FORMAT_XBGR,
DRM_FORMAT_ABGR,
DRM_FORMAT_RGB565,
-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 4/5] drm/amd/display: Make assert in DCE's program_bit_depth_reduction more lenient.

[Mario Kleiner]

This is needed to avoid warnings with linebuffer depth 36 bpp.
Testing on a Polaris11, DCE-11.2 on a 10 bit HDR-10 monitor
showed no obvious problems, and this 12 bpc limit is consistent
with what other function in the DCE bit depth reduction path use.

Signed-off-by: Mario Kleiner 
---
 drivers/gpu/drm/amd/display/dc/dce/dce_transform.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_transform.c 
b/drivers/gpu/drm/amd/display/dc/dce/dce_transform.c
index 92b53a30d954..d9fd4ec60588 100644
--- a/drivers/gpu/drm/amd/display/dc/dce/dce_transform.c
+++ b/drivers/gpu/drm/amd/display/dc/dce/dce_transform.c
@@ -794,7 +794,7 @@ static void program_bit_depth_reduction(
enum dcp_out_trunc_round_mode trunc_mode;
bool spatial_dither_enable;
 
-   ASSERT(depth < COLOR_DEPTH_121212); /* Invalid clamp bit depth */
+   ASSERT(depth <= COLOR_DEPTH_121212); /* Invalid clamp bit depth */
 
spatial_dither_enable = bit_depth_params->flags.SPATIAL_DITHER_ENABLED;
/* Default to 12 bit truncation without rounding */
@@ -854,7 +854,7 @@ static void dce60_program_bit_depth_reduction(
enum dcp_out_trunc_round_mode trunc_mode;
bool spatial_dither_enable;
 
-   ASSERT(depth < COLOR_DEPTH_121212); /* Invalid clamp bit depth */
+   ASSERT(depth <= COLOR_DEPTH_121212); /* Invalid clamp bit depth */
 
spatial_dither_enable = bit_depth_params->flags.SPATIAL_DITHER_ENABLED;
/* Default to 12 bit truncation without rounding */
-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/5] drm/amd/display: Increase linebuffer pixel depth to 36bpp.

[Mario Kleiner]

Testing with the photometer shows that at least Raven Ridge DCN-1.0
does not achieve more than 10 bpc effective output precision with a
16 bpc unorm surface of type SURFACE_PIXEL_FORMAT_GRPH_ABGR16161616,
unless linebuffer depth is increased from LB_PIXEL_DEPTH_30BPP to
LB_PIXEL_DEPTH_36BPP. Otherwise precision gets truncated somewhere
to 10 bpc effective depth.

Strangely this increase was not needed on Polaris11 DCE-11.2 during
testing to get 12 bpc effective precision. It also is not needed for
fp16 framebuffers.

Tested on DCN-1.0 and DCE-11.2.

Signed-off-by: Mario Kleiner 
---
 drivers/gpu/drm/amd/display/dc/core/dc_resource.c  | 7 +--
 drivers/gpu/drm/amd/display/dc/dce/dce_transform.c | 6 --
 drivers/gpu/drm/amd/display/dc/dce110/dce110_transform_v.c | 3 ++-
 drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dpp.c   | 3 ++-
 drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c  | 2 +-
 drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dpp.c   | 3 ++-
 drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c | 2 +-
 drivers/gpu/drm/amd/display/dc/dcn30/dcn30_dpp.c   | 3 ++-
 8 files changed, 19 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c 
b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
index f1aed40b3124..51e91b546d69 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
@@ -1167,9 +1167,12 @@ bool resource_build_scaling_params(struct pipe_ctx 
*pipe_ctx)
 
/**
 * Setting line buffer pixel depth to 24bpp yields banding
-* on certain displays, such as the Sharp 4k
+* on certain displays, such as the Sharp 4k. 36bpp is needed
+* to support SURFACE_PIXEL_FORMAT_GRPH_ARGB16161616 and
+* SURFACE_PIXEL_FORMAT_GRPH_ABGR16161616 with actual > 10 bpc
+* precision on at least DCN display engines.
 */
-   pipe_ctx->plane_res.scl_data.lb_params.depth = LB_PIXEL_DEPTH_30BPP;
+   pipe_ctx->plane_res.scl_data.lb_params.depth = LB_PIXEL_DEPTH_36BPP;
pipe_ctx->plane_res.scl_data.lb_params.alpha_en = 
plane_state->per_pixel_alpha;
 
pipe_ctx->plane_res.scl_data.recout.x += timing->h_border_left;
diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_transform.c 
b/drivers/gpu/drm/amd/display/dc/dce/dce_transform.c
index 151dc7bf6d23..92b53a30d954 100644
--- a/drivers/gpu/drm/amd/display/dc/dce/dce_transform.c
+++ b/drivers/gpu/drm/amd/display/dc/dce/dce_transform.c
@@ -1647,7 +1647,8 @@ void dce_transform_construct(
xfm_dce->lb_pixel_depth_supported =
LB_PIXEL_DEPTH_18BPP |
LB_PIXEL_DEPTH_24BPP |
-   LB_PIXEL_DEPTH_30BPP;
+   LB_PIXEL_DEPTH_30BPP |
+   LB_PIXEL_DEPTH_36BPP;
 
xfm_dce->lb_bits_per_entry = LB_BITS_PER_ENTRY;
xfm_dce->lb_memory_size = LB_TOTAL_NUMBER_OF_ENTRIES; /*0x6B0*/
@@ -1675,7 +1676,8 @@ void dce60_transform_construct(
xfm_dce->lb_pixel_depth_supported =
LB_PIXEL_DEPTH_18BPP |
LB_PIXEL_DEPTH_24BPP |
-   LB_PIXEL_DEPTH_30BPP;
+   LB_PIXEL_DEPTH_30BPP |
+   LB_PIXEL_DEPTH_36BPP;
 
xfm_dce->lb_bits_per_entry = LB_BITS_PER_ENTRY;
xfm_dce->lb_memory_size = LB_TOTAL_NUMBER_OF_ENTRIES; /*0x6B0*/
diff --git a/drivers/gpu/drm/amd/display/dc/dce110/dce110_transform_v.c 
b/drivers/gpu/drm/amd/display/dc/dce110/dce110_transform_v.c
index 29438c6050db..45bca0db5e5e 100644
--- a/drivers/gpu/drm/amd/display/dc/dce110/dce110_transform_v.c
+++ b/drivers/gpu/drm/amd/display/dc/dce110/dce110_transform_v.c
@@ -708,7 +708,8 @@ bool dce110_transform_v_construct(
xfm_dce->lb_pixel_depth_supported =
LB_PIXEL_DEPTH_18BPP |
LB_PIXEL_DEPTH_24BPP |
-   LB_PIXEL_DEPTH_30BPP;
+   LB_PIXEL_DEPTH_30BPP |
+   LB_PIXEL_DEPTH_36BPP;
 
xfm_dce->prescaler_on = true;
xfm_dce->lb_bits_per_entry = LB_BITS_PER_ENTRY;
diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dpp.c 
b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dpp.c
index a77e7bd3b8d5..91fdfcd8a14e 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dpp.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dpp.c
@@ -568,7 +568,8 @@ void dpp1_construct(
dpp->lb_pixel_depth_supported =
LB_PIXEL_DEPTH_18BPP |
LB_PIXEL_DEPTH_24BPP |
-   LB_PIXEL_DEPTH_30BPP;
+   LB_PIXEL_DEPTH_30BPP |
+   LB_PIXEL_DEPTH_36BPP;
 
dpp->lb_bits_per_entry = LB_BITS_PER_ENTRY;
dpp->lb_memory_size = LB_TOTAL_NUMBER_OF_ENTRIES; /*0x1404*/
diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c 
b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
index 

[PATCH 1/5] drm/fourcc: Add 16 bpc fixed point framebuffer formats.

[Mario Kleiner]

These are 16 bits per color channel unsigned normalized formats.
They are supported by at least AMD display hw, and suitable for
direct scanout of Vulkan swapchain images in the format
VK_FORMAT_R16G16B16A16_UNORM.

Signed-off-by: Mario Kleiner 
---
 drivers/gpu/drm/drm_fourcc.c  | 4 
 include/uapi/drm/drm_fourcc.h | 7 +++
 2 files changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 03262472059c..ce13d2be5d7b 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -203,6 +203,10 @@ const struct drm_format_info *__drm_format_info(u32 format)
{ .format = DRM_FORMAT_ARGB16161616F,   .depth = 0,  
.num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true },
{ .format = DRM_FORMAT_ABGR16161616F,   .depth = 0,  
.num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true },
{ .format = DRM_FORMAT_AXBXGXRX106106106106, .depth = 0, 
.num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true },
+   { .format = DRM_FORMAT_XRGB16161616,.depth = 0,  
.num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1 },
+   { .format = DRM_FORMAT_XBGR16161616,.depth = 0,  
.num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1 },
+   { .format = DRM_FORMAT_ARGB16161616,.depth = 0,  
.num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true },
+   { .format = DRM_FORMAT_ABGR16161616,.depth = 0,  
.num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true },
{ .format = DRM_FORMAT_RGB888_A8,   .depth = 32, 
.num_planes = 2, .cpp = { 3, 1, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true },
{ .format = DRM_FORMAT_BGR888_A8,   .depth = 32, 
.num_planes = 2, .cpp = { 3, 1, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true },
{ .format = DRM_FORMAT_XRGB_A8, .depth = 32, 
.num_planes = 2, .cpp = { 4, 1, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true },
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index f76de49c768f..f7156322aba5 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -168,6 +168,13 @@ extern "C" {
 #define DRM_FORMAT_RGBA1010102 fourcc_code('R', 'A', '3', '0') /* [31:0] 
R:G:B:A 10:10:10:2 little endian */
 #define DRM_FORMAT_BGRA1010102 fourcc_code('B', 'A', '3', '0') /* [31:0] 
B:G:R:A 10:10:10:2 little endian */
 
+/* 64 bpp RGB */
+#define DRM_FORMAT_XRGB16161616fourcc_code('X', 'R', '4', '8') /* 
[63:0] x:R:G:B 16:16:16:16 little endian */
+#define DRM_FORMAT_XBGR16161616fourcc_code('X', 'B', '4', '8') /* 
[63:0] x:B:G:R 16:16:16:16 little endian */
+
+#define DRM_FORMAT_ARGB16161616fourcc_code('A', 'R', '4', '8') /* 
[63:0] A:R:G:B 16:16:16:16 little endian */
+#define DRM_FORMAT_ABGR16161616fourcc_code('A', 'B', '4', '8') /* 
[63:0] A:B:G:R 16:16:16:16 little endian */
+
 /*
  * Floating point 64bpp RGB
  * IEEE 754-2008 binary16 half-precision float
-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/5] drm/amd/display: Add support for SURFACE_PIXEL_FORMAT_GRPH_ABGR16161616.

[Mario Kleiner]

Add the necessary format definition, bandwidth and pixel size mappings,
prescaler setup, and pixelformat selection, following the logic
already present for SURFACE_PIXEL_FORMAT_GRPH_ARGB16161616.

The new SURFACE_PIXEL_FORMAT_GRPH_ABGR16161616 is implemented as the
old SURFACE_PIXEL_FORMAT_GRPH_ARGB16161616 format, but with swapped
red <-> green color channel, by use of the hardware xbar.

Please note that on the DCN 1/2/3 display engines, the pixelformat
in hubp and dpp setup for the old SURFACE_PIXEL_FORMAT_GRPH_ARGB16161616
and the new SURFACE_PIXEL_FORMAT_GRPH_ABGR16161616 was changed from
format id 22 to id 26. See amd/include/navi10_enum.h for the meaning
of the id's.

For format 22, the display engine read the framebuffer in 16 bpc format,
but truncated to the 12 bpc actually supported by later pipeline stages.
However, the engine took the 12 LSB of each color component for
truncation, which is incompatible with rendering at least under Vulkan,
where content is 16 bit wide, and a 12 MSB alignment would be appropriate,
if any. Format 20 for ARGB16161616_12MSB does work, but even better, we
can choose format 26 for ARGB16161616_UNORM, keeping all 16 bits around
until later stages of the display pipeline.

This allows to directly consume what the rendering hw produces under
Vulkan for swapchain format VK_FORMAT_R16G16B16A16_UNORM, as tested
with a patched version of the current AMD open-source amdvlk driver
which maps swapchain format VK_FORMAT_R16G16B16A16_UNORM onto
DRM_FORMAT_XBGR16161616.

The old id 22 would cause colorful pixeltrash to be displayed instead.

Tested under DCN-1.0 and DCE-11.2.

Signed-off-by: Mario Kleiner 
---
 drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c| 2 ++
 drivers/gpu/drm/amd/display/dc/calcs/dcn_calcs.c| 2 ++
 drivers/gpu/drm/amd/display/dc/core/dc_resource.c   | 2 ++
 drivers/gpu/drm/amd/display/dc/dc_hw_types.h| 2 ++
 drivers/gpu/drm/amd/display/dc/dce/dce_mem_input.c  | 2 ++
 drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c | 1 +
 drivers/gpu/drm/amd/display/dc/dce110/dce110_mem_input_v.c  | 1 +
 drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dpp.c| 6 --
 drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hubbub.c | 1 +
 drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hubp.c   | 4 +++-
 drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dpp.c| 3 ++-
 drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hubbub.c | 1 +
 drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hubp.c   | 4 +++-
 drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c   | 1 +
 drivers/gpu/drm/amd/display/dc/dcn30/dcn30_dpp.c| 3 ++-
 15 files changed, 29 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c 
b/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c
index e633f8a51edb..4e3664db7456 100644
--- a/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c
+++ b/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c
@@ -2827,6 +2827,7 @@ static void populate_initial_data(
data->bytes_per_pixel[num_displays + 4] = 4;
break;
case SURFACE_PIXEL_FORMAT_GRPH_ARGB16161616:
+   case SURFACE_PIXEL_FORMAT_GRPH_ABGR16161616:
case SURFACE_PIXEL_FORMAT_GRPH_ABGR16161616F:
data->bytes_per_pixel[num_displays + 4] = 8;
break;
@@ -2930,6 +2931,7 @@ static void populate_initial_data(
data->bytes_per_pixel[num_displays + 4] = 4;
break;
case SURFACE_PIXEL_FORMAT_GRPH_ARGB16161616:
+   case SURFACE_PIXEL_FORMAT_GRPH_ABGR16161616:
case SURFACE_PIXEL_FORMAT_GRPH_ABGR16161616F:
data->bytes_per_pixel[num_displays + 4] = 8;
break;
diff --git a/drivers/gpu/drm/amd/display/dc/calcs/dcn_calcs.c 
b/drivers/gpu/drm/amd/display/dc/calcs/dcn_calcs.c
index d4df4da5b81a..0e18df1283b6 100644
--- a/drivers/gpu/drm/amd/display/dc/calcs/dcn_calcs.c
+++ b/drivers/gpu/drm/amd/display/dc/calcs/dcn_calcs.c
@@ -236,6 +236,7 @@ static enum dcn_bw_defs tl_pixel_format_to_bw_defs(enum 
surface_pixel_format for
case SURFACE_PIXEL_FORMAT_GRPH_ABGR2101010_XR_BIAS:
return dcn_bw_rgb_sub_32;
case SURFACE_PIXEL_FORMAT_GRPH_ARGB16161616:
+   case SURFACE_PIXEL_FORMAT_GRPH_ABGR16161616:
case SURFACE_PIXEL_FORMAT_GRPH_ARGB16161616F:
case SURFACE_PIXEL_FORMAT_GRPH_ABGR16161616F:
return dcn_bw_rgb_sub_64;
@@ -375,6 +376,7 @@ static void pipe_ctx_to_e2e_pipe_params (
input->src.viewport_height_c   = input->src.viewport_height / 2;
break;
case SURFACE_PIXEL_FORMAT_GRPH_ARGB16161616:
+   case SURFACE_PIXEL_FORMAT_GRPH_ABGR16161616:
case SURFACE_PIXEL_FORMAT_GRPH_ARGB16161616F:

16 bpc fixed point (RGBA16) framebuffer support for core and AMD.

[Mario Kleiner]

Hi,

this patch series adds the fourcc's for 16 bit fixed point unorm
framebuffers to the core, and then an implementation for AMD gpu's
with DisplayCore.

This is intended to allow for pageflipping to, and direct scanout of,
Vulkan swapchain images in the format VK_FORMAT_R16G16B16A16_UNORM.
I have patched AMD's GPUOpen amdvlk OSS driver to enable this format
for swapchains, mapping to DRM_FORMAT_XBGR16161616:
Link: 
https://github.com/kleinerm/pal/commit/a25d4802074b13a8d5f7edc96ae45469ecbac3c4

My main motivation for this is squeezing every bit of precision
out of the hardware for scientific and medical research applications,
where fp16 in the unorm range is limited to ~11 bpc effective linear
precision in the upper half [0.5;1.0] of the unorm range, although
the hardware could do at least 12 bpc.

It has been successfully tested on AMD RavenRidge (DCN-1), and with
Polaris11 (DCE-11.2). Up to two displays were active on RavenRidge
(DP 2560x1440@144Hz + HDMI 2560x1440@120Hz), the maximum supported
on my hw, both running at 10 bpc DP output depth.

Up to three displays were active on the Polaris (DP 2560x1440@144Hz +
2560x1440@100Hz USB-C DP-altMode-to-HDMI converter + eDP 2880x1800@60Hz
Apple Retina panel), all running at 10 bpc output depth.

No malfunctions, visual artifacts or other oddities were observed
(apart from an adventureous mess of cables and adapters on my desk),
suggesting it works.

I used my automatic photometer measurement procedure to verify the
effective output precision of 10 bpc DP native signal + spatial
dithering in the gpu as enabled by the amdgpu driver. Results show
the expected 12 bpc precision i hoped for -- the current upper limit
for AMD display hw afaik.

So it seems to work in the way i hoped :).

Some open questions wrt. AMD DC, to be addressed in this patch series, or 
follow up
patches if neccessary:

- For the atomic check for plane scaling, the current patch will
apply the same hw limits as for other rgb fixed point fb's, e.g.,
for 8 bpc rgb8. Is this correct? Or would we need to use the fp16
limits, because this is also a 64 bpp format? Or something new
entirely?

- I haven't added the new fourcc to the DCC tables yet. Should i?

- I had to change an assert for DCE to allow 36bpp linebuffers (patch 4/5).
It looks to me as if that assert was inconsistent with other places
in the driver where COLOR_DEPTH121212 is supported, and looking at
the code, the change seems harmless. At least on DCE-11.2 the change
didn't cause any noticeable (by myself) or measurable (by my equipment)
problems on any of the 3 connected displays.

- Related to that change, while i needed to increase lb pixelsize to 36bpp
to get > 10 bpc effective precision on DCN, i didn't need to do that
on DCE. Also no change of lb pixelsize was needed on either DCN or DCe
to get > 10 bpc precision for fp16 framebuffers, so something seems to
behave differently for floating point 16 vs. fixed point 16. This all
seems to suggest one could leave lb pixelsize at the old 30 bpp value
on at least DCE-11.2 and still get the > 10 bpc precision if one wanted
to avoid the changes of patch 4/5.

Thanks,
-mario


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/atomic: Add the crtc to affected crtc only if uapi.enable = true

[Navare, Manasi]

On Fri, Mar 19, 2021 at 04:56:24PM +0200, Ville Syrjälä wrote:
> On Thu, Mar 18, 2021 at 04:01:26PM -0700, Navare, Manasi wrote:
> > So basically we see this warning only in case of bigjoiner when
> > drm_atomic_check gets called without setting the state->allow_modeset flag.
> 
> Considering the code is 'WARN(!state->allow_modeset, ...' that
> fact should be rather obvious.
> 
> > 
> > So do you think that in i915, in intel_atomic_check_bigjoiner() we should 
> > only
> > steal the crtc when allow_modeset flag is set in state?
> 
> No. If you fully read drm_atomic_check_only() you will observe
> that it will reject any commit w/ allow_modeset==false which 
> needs a modeset. And it does that before the WARN.
> 
> So you're barking up the wrong tree here. The problem I think
> is that you're just computing requested_crtcs wrong.

So here in this case, requested CRTC = 0x1 since it requests modeset on CRTC 0
Now in teh atomic check, it steals the slave CRTC 1 and hence affected CRTC 
comes out
as 0x3 and hence the mismatch.
Now what is not clear to me is that if a full modeset was not required
why did i915 still steal that slave CRTC?

Manasi

> 
> > If we add this check there then the affected crtc wont count the slave crtc
> > and we wont get this warning.
> > 
> > Ville, Danvet?
> > 
> > Manasi
> > 
> > 
> > On Tue, Mar 16, 2021 at 10:35:09PM +0100, Daniel Vetter wrote:
> > > On Tue, Mar 9, 2021 at 10:14 AM Pekka Paalanen  
> > > wrote:
> > > >
> > > > On Mon, 8 Mar 2021 16:52:58 -0800
> > > > "Navare, Manasi"  wrote:
> > > >
> > > > > On Thu, Mar 04, 2021 at 10:42:23AM +0200, Pekka Paalanen wrote:
> > > > > > On Wed, 3 Mar 2021 12:44:33 -0800
> > > > > > "Navare, Manasi"  wrote:
> > > > > >
> > > > > > > On Wed, Mar 03, 2021 at 10:47:44AM +0200, Pekka Paalanen wrote:
> > > > > > > > On Tue,  2 Mar 2021 12:41:32 -0800
> > > > > > > > Manasi Navare  wrote:
> > > > > > > >
> > > > > > > > > In case of a modeset where a mode gets split across mutiple 
> > > > > > > > > CRTCs
> > > > > > > > > in the driver specific implementation (bigjoiner in i915) we 
> > > > > > > > > wrongly count
> > > > > > > > > the affected CRTCs based on the drm_crtc_mask and indicate 
> > > > > > > > > the stolen CRTC as
> > > > > > > > > an affected CRTC in atomic_check_only().
> > > > > > > > > This triggers a warning since affected CRTCs doent match 
> > > > > > > > > requested CRTC.
> > > > > > > > >
> > > > > > > > > To fix this in such bigjoiner configurations, we should only
> > > > > > > > > increment affected crtcs if that CRTC is enabled in UAPI not
> > > > > > > > > if it is just used internally in the driver to split the mode.
> > > > > > > >
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > I think that makes sense to me. Stealing CRTCs that are not 
> > > > > > > > currently
> > > > > > > > used by the userspace (display server) should be ok, as long as 
> > > > > > > > that
> > > > > > > > is completely invisible to userspace: meaning that it does not 
> > > > > > > > cause
> > > > > > > > userspace to unexpectedly e.g. receive or miss per-crtc atomic
> > > > > > > > completion events.
> > > > > > >
> > > > > > > Yes since we are only doing atomic_check_only() here, the stolen
> > > > > >
> > > > > > But the real not-test-only commit will follow if this test-only 
> > > > > > commit
> > > > > > succeeds, and keeping the guarantees for the real commit are 
> > > > > > important.
> > > > >
> > > > > Hmm well after the actual real commit, since the second crtc is stolen
> > > > > even though it is not being used for the display output, it is
> > > > > used for joiner so the uapi.enable will be true after the real commit.
> > > > >
> > > > > so actually the assertion would fail in this case.
> > > > >
> > > > > @Ville @Danvet any suggestions here in that case?
> > > 
> > > That is very bad. We can't frob uapi state like that. I think that
> > > calls for even more checks to make sure kms drivers who try to play
> > > clever games don't get it wrong, so we probably need to check uapi
> > > enable and active state in another mask before/after ->atomic_check
> > > too. Or something like that.
> > > 
> > > > Hi,
> > > >
> > > > that is not what I was talking about, but sounds like you found a
> > > > different problem. It seems like the problem you are talking about
> > > > would be guaranteed to be hit if bigjoiner was used. Have you not
> > > > tested this?
> > > >
> > > > However, I was talking about the real commit itself, not what happens
> > > > on commits after it, see below.
> > > >
> > > > > > > crtc is completely invisible to the userspace and hence that is
> > > > > > > indicated by uapi.enable which is not true for this stolen
> > > > > > > crtc. However if allow modeset flag set, then it will do a full
> > > > > > > modeset and indicate the uapi.enable for this stolen crtc as well
> > > > > > > since that cannot be used for other modeset requested by 
> > > > > > > userspace.
> > > > > > >
> > > > > > > >
> 

Re: [PATCH 2/3] drm/connector: Add helper to compare HDR metadata

[Harry Wentland]

On 2021-03-19 8:49 a.m., Maxime Ripard wrote:

All the drivers that support the HDR metadata property have a similar
function to compare the metadata from one connector state to the next,
and force a mode change if they differ.

All these functions run pretty much the same code, so let's turn it into
an helper that can be shared across those drivers.

Signed-off-by: Maxime Ripard 


Patches 1 & 2 are
Reviewed-by: Harry Wentland 

Harry


---
  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 21 +-
  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 17 +--
  drivers/gpu/drm/drm_connector.c   | 28 +++
  drivers/gpu/drm/i915/display/intel_atomic.c   | 13 +
  include/drm/drm_connector.h   |  2 ++
  5 files changed, 33 insertions(+), 48 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 06908a3cee0f..4eb5201e566a 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -5924,25 +5924,6 @@ static int fill_hdr_info_packet(const struct 
drm_connector_state *state,
return 0;
  }
  
-static bool

-is_hdr_metadata_different(const struct drm_connector_state *old_state,
- const struct drm_connector_state *new_state)
-{
-   struct drm_property_blob *old_blob = old_state->hdr_output_metadata;
-   struct drm_property_blob *new_blob = new_state->hdr_output_metadata;
-
-   if (old_blob != new_blob) {
-   if (old_blob && new_blob &&
-   old_blob->length == new_blob->length)
-   return memcmp(old_blob->data, new_blob->data,
- old_blob->length);
-
-   return true;
-   }
-
-   return false;
-}
-
  static int
  amdgpu_dm_connector_atomic_check(struct drm_connector *conn,
 struct drm_atomic_state *state)
@@ -5960,7 +5941,7 @@ amdgpu_dm_connector_atomic_check(struct drm_connector 
*conn,
if (!crtc)
return 0;
  
-	if (is_hdr_metadata_different(old_con_state, new_con_state)) {

+   if (!drm_connector_atomic_hdr_metadata_equal(old_con_state, 
new_con_state)) {
struct dc_info_packet hdr_infopacket;
  
  		ret = fill_hdr_info_packet(new_con_state, _infopacket);

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index f24bbb840dbf..f871e33c2fc9 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -2395,21 +2395,6 @@ static int dw_hdmi_connector_get_modes(struct 
drm_connector *connector)
return ret;
  }
  
-static bool hdr_metadata_equal(const struct drm_connector_state *old_state,

-  const struct drm_connector_state *new_state)
-{
-   struct drm_property_blob *old_blob = old_state->hdr_output_metadata;
-   struct drm_property_blob *new_blob = new_state->hdr_output_metadata;
-
-   if (!old_blob || !new_blob)
-   return old_blob == new_blob;
-
-   if (old_blob->length != new_blob->length)
-   return false;
-
-   return !memcmp(old_blob->data, new_blob->data, old_blob->length);
-}
-
  static int dw_hdmi_connector_atomic_check(struct drm_connector *connector,
  struct drm_atomic_state *state)
  {
@@ -2423,7 +2408,7 @@ static int dw_hdmi_connector_atomic_check(struct 
drm_connector *connector,
if (!crtc)
return 0;
  
-	if (!hdr_metadata_equal(old_state, new_state)) {

+   if (!drm_connector_atomic_hdr_metadata_equal(old_state, new_state)) {
crtc_state = drm_atomic_get_crtc_state(state, crtc);
if (IS_ERR(crtc_state))
return PTR_ERR(crtc_state);
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index e25248e23e18..d781a3a1e9bf 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -2170,6 +2170,34 @@ int 
drm_connector_attach_hdr_output_metadata_property(struct drm_connector *conn
  }
  EXPORT_SYMBOL(drm_connector_attach_hdr_output_metadata_property);
  
+/**

+ * drm_connector_atomic_hdr_metadata_equal - checks if the hdr metadata changed
+ * @old_state: old connector state to compare
+ * @new_state: new connector state to compare
+ *
+ * This is used by HDR-enabled drivers to test whether the HDR metadata
+ * have changed between two different connector state (and thus probably
+ * requires a full blown mode change).
+ *
+ * Returns:
+ * True if the metadata are equal, False otherwise
+ */
+bool drm_connector_atomic_hdr_metadata_equal(struct drm_connector_state 
*old_state,
+struct drm_connector_state 
*new_state)
+{
+   struct drm_property_blob *old_blob = old_state->hdr_output_metadata;
+   

Re: [PATCH] drm/radeon/ttm: Fix memory leak userptr pages

[Felix Kuehling]

This caused a regression in kfdtest in a large-buffer stress test after 
memory allocation for user pages fails:


[17359.536303] amdgpu: init_user_pages: Failed to get user pages: -16
[17359.543746] BUG: kernel NULL pointer dereference, address: 
[17359.551494] #PF: supervisor read access in kernel mode
[17359.557375] #PF: error_code(0x) - not-present page
[17359.563247] PGD 0 P4D 0
[17359.566514] Oops:  [#1] SMP PTI
[17359.570728] CPU: 8 PID: 5944 Comm: kfdtest Not tainted 5.11.0-kfd-fkuehlin 
#193
[17359.578760] Hardware name: ASUS All Series/X99-E WS/USB 3.1, BIOS 3201 
06/17/2016
[17359.586971] RIP: 0010:amdgpu_ttm_backend_unbind+0x52/0x110 [amdgpu]
[17359.594075] Code: 48 39 c6 74 1b 8b 53 0c 48 8d bd 80 a1 ff ff e8 24 62 00 00 85 
c0 0f 85 ab 00 00 00 c6 43 54 00 5b 5d c3 48 8b 46 10 8b 4e 50 <48> 8b 30 48 85 
f6 74 ba 8b 50 0c 48 8b bf 80 a1 ff ff 83 e1 01 45
[17359.614340] RSP: 0018:a4764971fc98 EFLAGS: 00010206
[17359.620315] RAX:  RBX: 950e8d4edf00 RCX: 
[17359.628204] RDX:  RSI: 950e8d4edf00 RDI: 950eadec5e80
[17359.636084] RBP: 950eadec5e80 R08:  R09: 
[17359.643958] R10: 0246 R11: 0001 R12: 950c03377800
[17359.651833] R13: 950eadec5e80 R14: 950c03377858 R15: 
[17359.659701] FS:  7febb20cb740() GS:950ebfc0() 
knlGS:
[17359.668528] CS:  0010 DS:  ES:  CR0: 80050033
[17359.675012] CR2:  CR3: 0006d700e005 CR4: 001706e0
[17359.682883] Call Trace:
[17359.686063]  amdgpu_ttm_backend_destroy+0x12/0x70 [amdgpu]
[17359.692349]  ttm_bo_cleanup_memtype_use+0x37/0x60 [ttm]
[17359.698307]  ttm_bo_release+0x278/0x5e0 [ttm]
[17359.703385]  amdgpu_bo_unref+0x1a/0x30 [amdgpu]
[17359.708701]  amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu+0x7e5/0x910 [amdgpu]
[17359.716307]  kfd_ioctl_alloc_memory_of_gpu+0x11a/0x220 [amdgpu]
[17359.723036]  kfd_ioctl+0x223/0x400 [amdgpu]
[17359.728017]  ? kfd_dev_is_large_bar+0x90/0x90 [amdgpu]
[17359.734152]  __x64_sys_ioctl+0x8b/0xd0
[17359.738796]  do_syscall_64+0x2d/0x40
[17359.743259]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[17359.749205] RIP: 0033:0x7febb083b6d7
[17359.753681] Code: b3 66 90 48 8b 05 b1 47 2d 00 64 c7 00 26 00 00 00 48 c7 c0 ff 
ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff 
ff 73 01 c3 48 8b 0d 81 47 2d 00 f7 d8 64 89 01 48
[17359.774340] RSP: 002b:7ffdb5522cd8 EFLAGS: 0202 ORIG_RAX: 
0010
[17359.782668] RAX: ffda RBX: 0001 RCX: 7febb083b6d7
[17359.790566] RDX: 7ffdb5522d60 RSI: c0284b16 RDI: 0003
[17359.798459] RBP: 7ffdb5522d10 R08: 7ffdb5522dd0 R09: c404
[17359.806352] R10:  R11: 0202 R12: 559416e4e2aa
[17359.814251] R13:  R14: 0021 R15: 
[17359.822140] Modules linked in: ip6table_filter ip6_tables iptable_filter 
amdgpu x86_pkg_temp_thermal drm_ttm_helper ttm iommu_v2 gpu_sched ip_tables 
x_tables
[17359.837776] CR2: 
[17359.841888] ---[ end trace a6f27d64475b28c8 ]---
[17359.847318] RIP: 0010:amdgpu_ttm_backend_unbind+0x52/0x110 [amdgpu]
[17359.854479] Code: 48 39 c6 74 1b 8b 53 0c 48 8d bd 80 a1 ff ff e8 24 62 00 00 85 
c0 0f 85 ab 00 00 00 c6 43 54 00 5b 5d c3 48 8b 46 10 8b 4e 50 <48> 8b 30 48 85 
f6 74 ba 8b 50 0c 48 8b bf 80 a1 ff ff 83 e1 01 45
[17359.874929] RSP: 0018:a4764971fc98 EFLAGS: 00010206
[17359.881014] RAX:  RBX: 950e8d4edf00 RCX: 
[17359.889007] RDX:  RSI: 950e8d4edf00 RDI: 950eadec5e80
[17359.897008] RBP: 950eadec5e80 R08:  R09: 
[17359.905020] R10: 0246 R11: 0001 R12: 950c03377800
[17359.913034] R13: 950eadec5e80 R14: 950c03377858 R15: 
[17359.921050] FS:  7febb20cb740() GS:950ebfc0() 
knlGS:
[17359.930047] CS:  0010 DS:  ES:  CR0: 80050033
[17359.936674] CR2:  CR3: 0006d700e005 CR4: 001706e0

Reverting this patch fixes the problem for me.

Regards,
  Felix

On 2021-03-18 10:57 p.m., Alex Deucher wrote:

Applied.  Thanks!

Alex

On Thu, Mar 18, 2021 at 5:00 AM Koenig, Christian
 wrote:

Reviewed-by: Christian König 

Von: Daniel Gomez 
Gesendet: Donnerstag, 18. März 2021 09:32
Cc: dag...@gmail.com ; Daniel Gomez ; Deucher, Alexander 
; Koenig, Christian ; David Airlie ; Daniel 
Vetter ; amd-...@lists.freedesktop.org ; dri-devel@lists.freedesktop.org 
; linux-ker...@vger.kernel.org 
Betreff: [PATCH] drm/radeon/ttm: Fix memory leak userptr pages

If userptr pages have been pinned but not bounded,
they remain uncleared.

Signed-off-by: Daniel Gomez 
---
  drivers/gpu/drm/radeon/radeon_ttm.c | 5 +++--
  1 file 

Re: [PATCH] drm/fourcc: add Vivante TS modifiers

[Simon Ser]

On Friday, March 19th, 2021 at 8:06 PM, Lucas Stach  
wrote:

> +/*
> + * Vivante TS (tile-status) buffer modifiers. They can be combined with all 
> of
> + * the color buffer tiling modifiers defined above. When TS is present it's a
> + * separate buffer containing the clear/compression status of each tile. The
> + * modifiers are defined as VIVANTE_MOD_TS_c_s, where c is the color buffer 
> tile
> + * size in bytes covered by one entry in the status buffer and s is the 
> number
> + * of status bits per entry.
> + * We reserve the top 8bits of the Vivante modifier space for TS modifiers, 
> as
> + * future cores might add some more TS layout variations.
> + */
> +#define VIVANTE_MOD_TS_64_4   (1ULL << 48)
> +#define VIVANTE_MOD_TS_64_2   (2ULL << 48)
> +#define VIVANTE_MOD_TS_128_4  (3ULL << 48)
> +#define VIVANTE_MOD_TS_256_4  (4ULL << 48)
> +#define VIVANTE_MOD_TS_MASK   (0xffULL  << 48)

Hm, I think it's the first time we have values you can OR with modifiers to
get a new modifiers. This sounds a little bit dangerous, because all of the
fields don't get through the fourcc_mod_code mask.

Maybe it would be better to define something like this:

#define DRM_FORMAT_MOD_VIVANTE_TS(color_tiling, ts) \
fourcc_mod_code(VIVANTE, (color_tiling & 0xFF) | (ts & 0xFF << 48))

And then have defines for all of the possible values for color tiling and ts?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/fourcc: add Vivante TS modifiers

[Daniel Vetter]

On Fri, Mar 19, 2021 at 8:06 PM Lucas Stach  wrote:
>
> Vivante TS (tile-status) buffer modifiers. They can be combined with all of
> the Vivante color buffer tiling modifiers, so they are kind of a modifier
> modifier. If a TS modifier is present we have a additional plane for the
> TS buffer and the modifier defines the layout of this TS buffer.
>
> Signed-off-by: Lucas Stach 
> ---
>  include/uapi/drm/drm_fourcc.h | 16 
>  1 file changed, 16 insertions(+)
>
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index f76de49c768f..76df2a932637 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -623,6 +623,22 @@ extern "C" {
>   */
>  #define DRM_FORMAT_MOD_VIVANTE_SPLIT_SUPER_TILED fourcc_mod_code(VIVANTE, 4)
>
> +/*
> + * Vivante TS (tile-status) buffer modifiers. They can be combined with all 
> of
> + * the color buffer tiling modifiers defined above. When TS is present it's a
> + * separate buffer containing the clear/compression status of each tile. The
> + * modifiers are defined as VIVANTE_MOD_TS_c_s, where c is the color buffer 
> tile
> + * size in bytes covered by one entry in the status buffer and s is the 
> number
> + * of status bits per entry.

Might be worth it to go into alignment/rounding/stride requirements
here too, if you know them. Either way lgtm.

Acked-by: Daniel Vetter 

> + * We reserve the top 8bits of the Vivante modifier space for TS modifiers, 
> as
> + * future cores might add some more TS layout variations.
> + */
> +#define VIVANTE_MOD_TS_64_4   (1ULL << 48)
> +#define VIVANTE_MOD_TS_64_2   (2ULL << 48)
> +#define VIVANTE_MOD_TS_128_4  (3ULL << 48)
> +#define VIVANTE_MOD_TS_256_4  (4ULL << 48)
> +#define VIVANTE_MOD_TS_MASK   (0xffULL  << 48)
> +
>  /* NVIDIA frame buffer modifiers */
>
>  /*
> --
> 2.29.2
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel



--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 212077] AMD GPU discrete card memory at highest frequency even while not in use

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=212077

--- Comment #12 from Bat Malin (bat_ma...@abv.bg) ---
Old Kernel e.g. 5.10.23 initializes this 
1.038643] [drm] DM_PPLIB: values for Engine clock
[1.038645] [drm] DM_PPLIB:   214000
[1.038646] [drm] DM_PPLIB:   603000
[1.038646] [drm] DM_PPLIB:   958000
[1.038647] [drm] DM_PPLIB:   106
[1.038647] [drm] DM_PPLIB:   1128000
[1.038647] [drm] DM_PPLIB:   1182000
[1.038648] [drm] DM_PPLIB:   123
[1.038648] [drm] DM_PPLIB:   1275000
[1.038649] [drm] DM_PPLIB: Validation clocks:
[1.038649] [drm] DM_PPLIB:engine_max_clock: 127500
[1.038649] [drm] DM_PPLIB:memory_max_clock: 175000
[1.038650] [drm] DM_PPLIB:level   : 8
[1.038651] [drm] DM_PPLIB: values for Memory clock
[1.038651] [drm] DM_PPLIB:   30
[1.038651] [drm] DM_PPLIB:   625000
[1.038652] [drm] DM_PPLIB:   175
[1.038652] [drm] DM_PPLIB: Validation clocks:
[1.038652] [drm] DM_PPLIB:engine_max_clock: 127500
[1.038653] [drm] DM_PPLIB:memory_max_clock: 175000
[1.038653] [drm] DM_PPLIB:level   : 8
 and for the integrated card- 
[1.469248] [drm] DM_PPLIB: values for F clock
[1.469250] [drm] DM_PPLIB:   40 in kHz, 2874 in mV
[1.469251] [drm] DM_PPLIB:   933000 in kHz, 3224 in mV
[1.469252] [drm] DM_PPLIB:   1067000 in kHz, 3924 in mV
[1.469253] [drm] DM_PPLIB:   120 in kHz, 4074 in mV
[1.469256] [drm] DM_PPLIB: values for DCF clock
[1.469257] [drm] DM_PPLIB:   30 in kHz, 2874 in mV
[1.469258] [drm] DM_PPLIB:   60 in kHz, 3224 in mV
[1.469259] [drm] DM_PPLIB:   626000 in kHz, 3924 in mV
[1.469260] [drm] DM_PPLIB:   654000 in kHz, 4074 in mV
[1.469553] [drm] Display Core initialized with v3.2.104!


The new one 5.11.7 only for integrated card
[1.992374] kernel: [drm] DM_PPLIB: values for F clock
[1.992377] kernel: [drm] DM_PPLIB: 40 in kHz, 2874 in mV
[1.992379] kernel: [drm] DM_PPLIB: 933000 in kHz, 3224 in mV
[1.992381] kernel: [drm] DM_PPLIB: 1067000 in kHz, 3924 in mV
[1.992382] kernel: [drm] DM_PPLIB: 120 in kHz, 4074 in mV
[1.992385] kernel: [drm] DM_PPLIB: values for DCF clock
[1.992387] kernel: [drm] DM_PPLIB: 30 in kHz, 2874 in mV
[1.992388] kernel: [drm] DM_PPLIB: 60 in kHz, 3224 in mV
[1.992390] kernel: [drm] DM_PPLIB: 626000 in kHz, 3924 in mV
[1.992391] kernel: [drm] DM_PPLIB: 654000 in kHz, 4074 in mV
So I think this is related as the new kernel driver can`t initialize the values
for the discrete card.
Please fix.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 06/19] drm/amd/display/dc/calcs/dce_calcs: Move some large variables from the stack to the heap

[Alex Deucher]

On Fri, Mar 19, 2021 at 2:47 PM Christian König
 wrote:
>
>
>
> Am 19.03.21 um 19:26 schrieb Harry Wentland:
> > On 2021-03-19 2:13 p.m., Alex Deucher wrote:
> >> + Harry, Nick
> >>
> >> On Fri, Mar 19, 2021 at 4:24 AM Lee Jones  wrote:
> >>>
> >>> Fixes the following W=1 kernel build warning(s):
> >>>
> >>>   drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dce_calcs.c: In
> >>> function ‘calculate_bandwidth’:
> >>> drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dce_calcs.c:2016:1:
> >>> warning: the frame size of 1216 bytes is larger than 1024 bytes
> >>> [-Wframe-larger-than=]
> >>>
> >>> Cc: Harry Wentland 
> >>> Cc: Leo Li 
> >>> Cc: Alex Deucher 
> >>> Cc: "Christian König" 
> >>> Cc: David Airlie 
> >>> Cc: Daniel Vetter 
> >>> Cc: Colin Ian King 
> >>> Cc: amd-...@lists.freedesktop.org
> >>> Cc: dri-devel@lists.freedesktop.org
> >>> Signed-off-by: Lee Jones 
> >>> ---
> >>>   .../gpu/drm/amd/display/dc/calcs/dce_calcs.c  | 32
> >>> ---
> >>>   1 file changed, 28 insertions(+), 4 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c
> >>> b/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c
> >>> index e633f8a51edb6..9d8f2505a61c2 100644
> >>> --- a/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c
> >>> +++ b/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c
> >>> @@ -98,16 +98,16 @@ static void calculate_bandwidth(
> >>>  int32_t num_cursor_lines;
> >>>
> >>>  int32_t i, j, k;
> >>> -   struct bw_fixed yclk[3];
> >>> -   struct bw_fixed sclk[8];
> >>> +   struct bw_fixed *yclk;
> >>> +   struct bw_fixed *sclk;
> >>>  bool d0_underlay_enable;
> >>>  bool d1_underlay_enable;
> >>>  bool fbc_enabled;
> >>>  bool lpt_enabled;
> >>>  enum bw_defines sclk_message;
> >>>  enum bw_defines yclk_message;
> >>> -   enum bw_defines tiling_mode[maximum_number_of_surfaces];
> >>> -   enum bw_defines surface_type[maximum_number_of_surfaces];
> >>> +   enum bw_defines *tiling_mode;
> >>> +   enum bw_defines *surface_type;
> >>>  enum bw_defines voltage;
> >>>  enum bw_defines pipe_check;
> >>>  enum bw_defines hsr_check;
> >>> @@ -122,6 +122,22 @@ static void calculate_bandwidth(
> >>>  int32_t number_of_displays_enabled_with_margin = 0;
> >>>  int32_t number_of_aligned_displays_with_no_margin = 0;
> >>>
> >>> +   yclk = kcalloc(3, sizeof(*yclk), GFP_KERNEL);
> >>> +   if (!yclk)
> >>> +   return;
> >>> +
> >>> +   sclk = kcalloc(8, sizeof(*sclk), GFP_KERNEL);
> >>> +   if (!sclk)
> >>> +   goto free_yclk;
> >>> +
> >>> +   tiling_mode = kcalloc(maximum_number_of_surfaces,
> >>> sizeof(*tiling_mode), GFP_KERNEL);
> >>> +   if (!tiling_mode)
> >>> +   goto free_sclk;
> >>> +
> >>> +   surface_type = kcalloc(maximum_number_of_surfaces,
> >>> sizeof(*surface_type), GFP_KERNEL);
> >>> +   if (!surface_type)
> >>> +   goto free_tiling_mode;
> >>> +
> >>
> >>
> >> Harry or Nick can correct me if I'm wrong, but for this patch and the
> >> next one, I think this can be called from an atomic context.
> >>
> >
> > From what I can see this doesn't seem the case. If I'm missing
> > something someone please correct me.
>
> Have you taken into account that using FP functions require atomic
> context as well?
>
> We had quite a bunch of problems with that and had to replace some
> GFP_KERNEL with GFP_ATOMIC in the DC code because of this.
>
> Could of course be that this code here isn't affected by that, but
> better save than sorry.

DCE hardware uses fixed point math so that should be ok.  It's just
the newer DCN hardware that requires FP.

Alex


>
> Christian.
>
> >
> > This and the next (06/19) patch are both
> > Reviewed-by: Harry Wentland 
> >
> > Harry
> >
> >> Alex
> >>
> >>>  yclk[low] = vbios->low_yclk;
> >>>  yclk[mid] = vbios->mid_yclk;
> >>>  yclk[high] = vbios->high_yclk;
> >>> @@ -2013,6 +2029,14 @@ static void calculate_bandwidth(
> >>>  }
> >>>  }
> >>>  }
> >>> +
> >>> +   kfree(surface_type);
> >>> +free_tiling_mode:
> >>> +   kfree(tiling_mode);
> >>> +free_yclk:
> >>> +   kfree(yclk);
> >>> +free_sclk:
> >>> +   kfree(sclk);
> >>>   }
> >>>
> >>> /***
> >>> --
> >>> 2.27.0
> >>>
> >>> ___
> >>> 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: [PATCH 2/2] drm/etnaviv: User FOLL_LONGTERM in userptr

[Daniel Vetter]

On Mon, Mar 01, 2021 at 02:26:01AM -0800, John Hubbard wrote:
> On 3/1/21 01:52, Daniel Vetter wrote:
> > There's no mmu notifier or anything like that, releasing this pin is
> > entirely up to userspace. Hence FOLL_LONGTERM.
> > 
> > No cc: stable for this patch since a lot of the infrastructure around
> > FOLL_LONGETRM (like not allowing it for pages currently sitting in
> 
>   ^FOLL_LONGTERM
> 
> > ZONE_MOVEABLE before they're migrated) is still being worked on. So
> > not big benefits yet.
> 
> Yes. Great write-up, that's very clear, and it's exactly where we're at.
> 
> Reviewed-by: John Hubbard 

Both patches pushed to drm-misc-fixes. 2nd one maybe not required there,
but easier due to conflicts.

Thanks for the review.
-Daniel

> 
> 
> thanks,
> -- 
> John Hubbard
> NVIDIA
> 
> > 
> > Cc: John Hubbard 
> > Signed-off-by: Daniel Vetter 
> > Cc: Lucas Stach 
> > Cc: Russell King 
> > Cc: Christian Gmeiner 
> > Cc: etna...@lists.freedesktop.org
> > ---
> >   drivers/gpu/drm/etnaviv/etnaviv_gem.c | 3 ++-
> >   1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.c 
> > b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> > index a9e696d05b33..db69f19ab5bc 100644
> > --- a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> > +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> > @@ -689,7 +689,8 @@ static int etnaviv_gem_userptr_get_pages(struct 
> > etnaviv_gem_object *etnaviv_obj)
> > struct page **pages = pvec + pinned;
> > ret = pin_user_pages_fast(ptr, num_pages,
> > - FOLL_WRITE | FOLL_FORCE, pages);
> > + FOLL_WRITE | FOLL_FORCE | 
> > FOLL_LONGTERM,
> > + pages);
> > if (ret < 0) {
> > unpin_user_pages(pvec, pinned);
> > kvfree(pvec);
> > 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] drm/etnaviv: Use FOLL_FORCE for userptr

[Lucas Stach]

Am Freitag, dem 19.03.2021 um 20:09 +0100 schrieb Daniel Vetter:
> On Mon, Mar 01, 2021 at 10:52:53AM +0100, Daniel Vetter wrote:
> > Nothing checks userptr.ro except this call to pup_fast, which means
> > there's nothing actually preventing userspace from writing to this.
> > Which means you can just read-only mmap any file you want, userptr it
> > and then write to it with the gpu. Not good.
> > 
> > The right way to handle this is FOLL_WRITE | FOLL_FORCE, which will
> > break any COW mappings and update tracking for MAY_WRITE mappings so
> > there's no exploit and the vm isn't confused about what's going on.
> > For any legit use case there's no difference from what userspace can
> > observe and do.
> > 
> > Cc: sta...@vger.kernel.org
> > Cc: John Hubbard 
> > Signed-off-by: Daniel Vetter 
> > Cc: Lucas Stach 
> > Cc: Russell King 
> > Cc: Christian Gmeiner 
> > Cc: etna...@lists.freedesktop.org
> 
> Can I please have an ack on this so I can apply it? It's stuck.

Reviewed-by: Lucas Stach 

> Thanks, Daniel
> 
> > ---
> >  drivers/gpu/drm/etnaviv/etnaviv_gem.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.c 
> > b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> > index 6d38c5c17f23..a9e696d05b33 100644
> > --- a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> > +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> > @@ -689,7 +689,7 @@ static int etnaviv_gem_userptr_get_pages(struct 
> > etnaviv_gem_object *etnaviv_obj)
> >     struct page **pages = pvec + pinned;
> >  
> > 
> > 
> > 
> >     ret = pin_user_pages_fast(ptr, num_pages,
> > - !userptr->ro ? FOLL_WRITE : 0, pages);
> > + FOLL_WRITE | FOLL_FORCE, pages);
> >     if (ret < 0) {
> >     unpin_user_pages(pvec, pinned);
> >     kvfree(pvec);
> > -- 
> > 2.30.0
> > 
> 


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] drm/etnaviv: Use FOLL_FORCE for userptr

[Daniel Vetter]

On Mon, Mar 01, 2021 at 10:52:53AM +0100, Daniel Vetter wrote:
> Nothing checks userptr.ro except this call to pup_fast, which means
> there's nothing actually preventing userspace from writing to this.
> Which means you can just read-only mmap any file you want, userptr it
> and then write to it with the gpu. Not good.
> 
> The right way to handle this is FOLL_WRITE | FOLL_FORCE, which will
> break any COW mappings and update tracking for MAY_WRITE mappings so
> there's no exploit and the vm isn't confused about what's going on.
> For any legit use case there's no difference from what userspace can
> observe and do.
> 
> Cc: sta...@vger.kernel.org
> Cc: John Hubbard 
> Signed-off-by: Daniel Vetter 
> Cc: Lucas Stach 
> Cc: Russell King 
> Cc: Christian Gmeiner 
> Cc: etna...@lists.freedesktop.org

Can I please have an ack on this so I can apply it? It's stuck.

Thanks, Daniel

> ---
>  drivers/gpu/drm/etnaviv/etnaviv_gem.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.c 
> b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> index 6d38c5c17f23..a9e696d05b33 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> @@ -689,7 +689,7 @@ static int etnaviv_gem_userptr_get_pages(struct 
> etnaviv_gem_object *etnaviv_obj)
>   struct page **pages = pvec + pinned;
>  
>   ret = pin_user_pages_fast(ptr, num_pages,
> -   !userptr->ro ? FOLL_WRITE : 0, pages);
> +   FOLL_WRITE | FOLL_FORCE, pages);
>   if (ret < 0) {
>   unpin_user_pages(pvec, pinned);
>   kvfree(pvec);
> -- 
> 2.30.0
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/ttm: stop warning on TT shrinker failure

[Daniel Vetter]

On Fri, Mar 19, 2021 at 07:53:48PM +0100, Christian König wrote:
> Am 19.03.21 um 18:52 schrieb Daniel Vetter:
> > On Fri, Mar 19, 2021 at 03:08:57PM +0100, Christian König wrote:
> > > Don't print a warning when we fail to allocate a page for swapping things 
> > > out.
> > > 
> > > Also rely on memalloc_nofs_save/memalloc_nofs_restore instead of GFP_NOFS.
> > Uh this part doesn't make sense. Especially since you only do it for the
> > debugfs file, not in general. Which means you've just completely broken
> > the shrinker.
> 
> Are you sure? My impression is that GFP_NOFS should now work much more out
> of the box with the memalloc_nofs_save()/memalloc_nofs_restore().

Yeah, if you'd put it in the right place :-)

But also -mm folks are very clear that memalloc_no*() family is for dire
situation where there's really no other way out. For anything where you
know what you're doing, you really should use explicit gfp flags.

> > If this is just to paper over the seq_printf doing the wrong allocations,
> > then just move that out from under the fs_reclaim_acquire/release part.
> 
> No, that wasn't the problem.
> 
> We have just seen to many failures to allocate pages for swapout and I think
> that would improve this because in a lot of cases we can then immediately
> swap things out instead of having to rely on upper layers.

Yeah, you broke it. Now the real shrinker is running with GFP_KERNEL,
because your memalloc_no is only around the debugfs function. And ofc it's
much easier to allocate with GFP_KERNEL, right until you deadlock :-)

Shrinking is hard, there's no easy way out here.

Cheers, Daniel

> 
> Regards,
> Christian.
> 
> 
> > 
> > __GFP_NOWARN should be there indeed I think.
> > -Daniel
> > 
> > > Signed-off-by: Christian König 
> > > ---
> > >   drivers/gpu/drm/ttm/ttm_tt.c | 5 -
> > >   1 file changed, 4 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
> > > index 2f0833c98d2c..86fa3e82dacc 100644
> > > --- a/drivers/gpu/drm/ttm/ttm_tt.c
> > > +++ b/drivers/gpu/drm/ttm/ttm_tt.c
> > > @@ -369,7 +369,7 @@ static unsigned long ttm_tt_shrinker_scan(struct 
> > > shrinker *shrink,
> > >   };
> > >   int ret;
> > > - ret = ttm_bo_swapout(, GFP_NOFS);
> > > + ret = ttm_bo_swapout(, GFP_KERNEL | __GFP_NOWARN);
> > >   return ret < 0 ? SHRINK_EMPTY : ret;
> > >   }
> > > @@ -389,10 +389,13 @@ static unsigned long ttm_tt_shrinker_count(struct 
> > > shrinker *shrink,
> > >   static int ttm_tt_debugfs_shrink_show(struct seq_file *m, void *data)
> > >   {
> > >   struct shrink_control sc = { .gfp_mask = GFP_KERNEL };
> > > + unsigned int flags;
> > >   fs_reclaim_acquire(GFP_KERNEL);
> > > + flags = memalloc_nofs_save();
> > >   seq_printf(m, "%lu/%lu\n", ttm_tt_shrinker_count(_shrinker, 
> > > ),
> > >  ttm_tt_shrinker_scan(_shrinker, ));
> > > + memalloc_nofs_restore(flags);
> > >   fs_reclaim_release(GFP_KERNEL);
> > >   return 0;
> > > -- 
> > > 2.25.1
> > > 
> > > ___
> > > dri-devel mailing list
> > > dri-devel@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/fourcc: add Vivante TS modifiers

[Lucas Stach]

Vivante TS (tile-status) buffer modifiers. They can be combined with all of
the Vivante color buffer tiling modifiers, so they are kind of a modifier
modifier. If a TS modifier is present we have a additional plane for the
TS buffer and the modifier defines the layout of this TS buffer.

Signed-off-by: Lucas Stach 
---
 include/uapi/drm/drm_fourcc.h | 16 
 1 file changed, 16 insertions(+)

diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index f76de49c768f..76df2a932637 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -623,6 +623,22 @@ extern "C" {
  */
 #define DRM_FORMAT_MOD_VIVANTE_SPLIT_SUPER_TILED fourcc_mod_code(VIVANTE, 4)
 
+/*
+ * Vivante TS (tile-status) buffer modifiers. They can be combined with all of
+ * the color buffer tiling modifiers defined above. When TS is present it's a
+ * separate buffer containing the clear/compression status of each tile. The
+ * modifiers are defined as VIVANTE_MOD_TS_c_s, where c is the color buffer 
tile
+ * size in bytes covered by one entry in the status buffer and s is the number
+ * of status bits per entry.
+ * We reserve the top 8bits of the Vivante modifier space for TS modifiers, as
+ * future cores might add some more TS layout variations.
+ */
+#define VIVANTE_MOD_TS_64_4   (1ULL << 48)
+#define VIVANTE_MOD_TS_64_2   (2ULL << 48)
+#define VIVANTE_MOD_TS_128_4  (3ULL << 48)
+#define VIVANTE_MOD_TS_256_4  (4ULL << 48)
+#define VIVANTE_MOD_TS_MASK   (0xffULL  << 48)
+
 /* NVIDIA frame buffer modifiers */
 
 /*
-- 
2.29.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/etnaviv: rework linear window offset calculation

[Lucas Stach]

The current calculation based on the required_dma mask can be significantly
off, so that the linear window only overlaps a small part of the DRAM
address space. This can lead to the command buffer being unmappable, which
is obviously bad.

Rework the linear window offset calculation to be based on the command buffer
physical address, making sure that the command buffer is always mappable.

Signed-off-by: Lucas Stach 
---
 drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 52 +--
 1 file changed, 26 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c 
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index f3df93350893..affefb7aa58f 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -27,10 +27,6 @@
 #include "state_hi.xml.h"
 #include "cmdstream.xml.h"
 
-#ifndef PHYS_OFFSET
-#define PHYS_OFFSET 0
-#endif
-
 static const struct platform_device_id gpu_ids[] = {
{ .name = "etnaviv-gpu,2d" },
{ },
@@ -724,6 +720,7 @@ static void etnaviv_gpu_hw_init(struct etnaviv_gpu *gpu)
 int etnaviv_gpu_init(struct etnaviv_gpu *gpu)
 {
struct etnaviv_drm_private *priv = gpu->drm->dev_private;
+   dma_addr_t cmdbuf_paddr;
int ret, i;
 
ret = pm_runtime_get_sync(gpu->dev);
@@ -766,28 +763,6 @@ int etnaviv_gpu_init(struct etnaviv_gpu *gpu)
if (ret)
goto fail;
 
-   /*
-* Set the GPU linear window to be at the end of the DMA window, where
-* the CMA area is likely to reside. This ensures that we are able to
-* map the command buffers while having the linear window overlap as
-* much RAM as possible, so we can optimize mappings for other buffers.
-*
-* For 3D cores only do this if MC2.0 is present, as with MC1.0 it leads
-* to different views of the memory on the individual engines.
-*/
-   if (!(gpu->identity.features & chipFeatures_PIPE_3D) ||
-   (gpu->identity.minor_features0 & chipMinorFeatures0_MC20)) {
-   u32 dma_mask = (u32)dma_get_required_mask(gpu->dev);
-   if (dma_mask < PHYS_OFFSET + SZ_2G)
-   priv->mmu_global->memory_base = PHYS_OFFSET;
-   else
-   priv->mmu_global->memory_base = dma_mask - SZ_2G + 1;
-   } else if (PHYS_OFFSET >= SZ_2G) {
-   dev_info(gpu->dev, "Need to move linear window on MC1.0, 
disabling TS\n");
-   priv->mmu_global->memory_base = PHYS_OFFSET;
-   gpu->identity.features &= ~chipFeatures_FAST_CLEAR;
-   }
-
/*
 * If the GPU is part of a system with DMA addressing limitations,
 * request pages for our SHM backend buffers from the DMA32 zone to
@@ -804,6 +779,31 @@ int etnaviv_gpu_init(struct etnaviv_gpu *gpu)
goto fail;
}
 
+   /*
+* Set the GPU linear window to cover the cmdbuf region, as the GPU
+* won't be able to start execution otherwise. The alignment to 128M is
+* chosen arbitrarily but helps in debugging, as the MMU offset
+* calculations are much more straight forward this way.
+*
+* On MC1.0 cores the linear window offset is ignored by the TS engine,
+* leading to inconsistent memory views. Avoid using the offset on those
+* cores if possible, otherwise disable the TS feature.
+*/
+   cmdbuf_paddr = ALIGN_DOWN(etnaviv_cmdbuf_get_pa(>buffer), SZ_128M);
+
+   if (!(gpu->identity.features & chipFeatures_PIPE_3D) ||
+   (gpu->identity.minor_features0 & chipMinorFeatures0_MC20)) {
+   if (cmdbuf_paddr >= SZ_2G)
+   priv->mmu_global->memory_base = SZ_2G;
+   else
+   priv->mmu_global->memory_base = cmdbuf_paddr;
+   } else if (cmdbuf_paddr + SZ_128M >= SZ_2G) {
+   dev_info(gpu->dev,
+"Need to move linear window on MC1.0, disabling TS\n");
+   gpu->identity.features &= ~chipFeatures_FAST_CLEAR;
+   priv->mmu_global->memory_base = SZ_2G;
+   }
+
/* Setup event management */
spin_lock_init(>event_spinlock);
init_completion(>event_free);
-- 
2.29.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2] drm/etnaviv: add HWDB entry for GC7000 rev 6204

[Lucas Stach]

From: Sascha Hauer 

This is the 3D GPU found on the i.MX8MP SoC. The feature bits are
taken from the NXP downstream kernel driver 6.4.3.p1.305572.

Signed-off-by: Sascha Hauer 
Signed-off-by: Lucas Stach 
---
 drivers/gpu/drm/etnaviv/etnaviv_hwdb.c | 31 ++
 1 file changed, 31 insertions(+)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_hwdb.c 
b/drivers/gpu/drm/etnaviv/etnaviv_hwdb.c
index 167971a09be7..dfc0f536b3b9 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_hwdb.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_hwdb.c
@@ -37,6 +37,37 @@ static const struct etnaviv_chip_identity 
etnaviv_chip_identities[] = {
.minor_features10 = 0x0,
.minor_features11 = 0x0,
},
+   {
+   .model = 0x7000,
+   .revision = 0x6204,
+   .product_id = ~0U,
+   .customer_id = ~0U,
+   .eco_id = 0,
+   .stream_count = 16,
+   .register_max = 64,
+   .thread_count = 512,
+   .shader_core_count = 2,
+   .vertex_cache_size = 16,
+   .vertex_output_buffer_size = 1024,
+   .pixel_pipes = 1,
+   .instruction_count = 512,
+   .num_constants = 320,
+   .buffer_size = 0,
+   .varyings_count = 16,
+   .features = 0xe0287c8d,
+   .minor_features0 = 0xc1589eff,
+   .minor_features1 = 0xfefbfad9,
+   .minor_features2 = 0xeb9d4fbf,
+   .minor_features3 = 0xedfffced,
+   .minor_features4 = 0xdb0dafc7,
+   .minor_features5 = 0x3b5ac333,
+   .minor_features6 = 0xfcce6000,
+   .minor_features7 = 0xfffbfa6f,
+   .minor_features8 = 0x00e10ef3,
+   .minor_features9 = 0x04c8003c,
+   .minor_features10 = 0x4060,
+   .minor_features11 = 0x0024,
+   },
{
.model = 0x7000,
.revision = 0x6214,
-- 
2.29.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/ttm: stop warning on TT shrinker failure

[Christian König]

Am 19.03.21 um 18:52 schrieb Daniel Vetter:

On Fri, Mar 19, 2021 at 03:08:57PM +0100, Christian König wrote:

Don't print a warning when we fail to allocate a page for swapping things out.

Also rely on memalloc_nofs_save/memalloc_nofs_restore instead of GFP_NOFS.

Uh this part doesn't make sense. Especially since you only do it for the
debugfs file, not in general. Which means you've just completely broken
the shrinker.


Are you sure? My impression is that GFP_NOFS should now work much more 
out of the box with the memalloc_nofs_save()/memalloc_nofs_restore().



If this is just to paper over the seq_printf doing the wrong allocations,
then just move that out from under the fs_reclaim_acquire/release part.


No, that wasn't the problem.

We have just seen to many failures to allocate pages for swapout and I 
think that would improve this because in a lot of cases we can then 
immediately swap things out instead of having to rely on upper layers.


Regards,
Christian.




__GFP_NOWARN should be there indeed I think.
-Daniel


Signed-off-by: Christian König 
---
  drivers/gpu/drm/ttm/ttm_tt.c | 5 -
  1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index 2f0833c98d2c..86fa3e82dacc 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -369,7 +369,7 @@ static unsigned long ttm_tt_shrinker_scan(struct shrinker 
*shrink,
};
int ret;
  
-	ret = ttm_bo_swapout(, GFP_NOFS);

+   ret = ttm_bo_swapout(, GFP_KERNEL | __GFP_NOWARN);
return ret < 0 ? SHRINK_EMPTY : ret;
  }
  
@@ -389,10 +389,13 @@ static unsigned long ttm_tt_shrinker_count(struct shrinker *shrink,

  static int ttm_tt_debugfs_shrink_show(struct seq_file *m, void *data)
  {
struct shrink_control sc = { .gfp_mask = GFP_KERNEL };
+   unsigned int flags;
  
  	fs_reclaim_acquire(GFP_KERNEL);

+   flags = memalloc_nofs_save();
seq_printf(m, "%lu/%lu\n", ttm_tt_shrinker_count(_shrinker, ),
   ttm_tt_shrinker_scan(_shrinker, ));
+   memalloc_nofs_restore(flags);
fs_reclaim_release(GFP_KERNEL);
  
  	return 0;

--
2.25.1

___
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: [PATCH 06/19] drm/amd/display/dc/calcs/dce_calcs: Move some large variables from the stack to the heap

[Christian König]

Am 19.03.21 um 19:26 schrieb Harry Wentland:

On 2021-03-19 2:13 p.m., Alex Deucher wrote:

+ Harry, Nick

On Fri, Mar 19, 2021 at 4:24 AM Lee Jones  wrote:


Fixes the following W=1 kernel build warning(s):

  drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dce_calcs.c: In 
function ‘calculate_bandwidth’:
drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dce_calcs.c:2016:1: 
warning: the frame size of 1216 bytes is larger than 1024 bytes 
[-Wframe-larger-than=]


Cc: Harry Wentland 
Cc: Leo Li 
Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Colin Ian King 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
  .../gpu/drm/amd/display/dc/calcs/dce_calcs.c  | 32 
---

  1 file changed, 28 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c 
b/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c

index e633f8a51edb6..9d8f2505a61c2 100644
--- a/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c
+++ b/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c
@@ -98,16 +98,16 @@ static void calculate_bandwidth(
 int32_t num_cursor_lines;

 int32_t i, j, k;
-   struct bw_fixed yclk[3];
-   struct bw_fixed sclk[8];
+   struct bw_fixed *yclk;
+   struct bw_fixed *sclk;
 bool d0_underlay_enable;
 bool d1_underlay_enable;
 bool fbc_enabled;
 bool lpt_enabled;
 enum bw_defines sclk_message;
 enum bw_defines yclk_message;
-   enum bw_defines tiling_mode[maximum_number_of_surfaces];
-   enum bw_defines surface_type[maximum_number_of_surfaces];
+   enum bw_defines *tiling_mode;
+   enum bw_defines *surface_type;
 enum bw_defines voltage;
 enum bw_defines pipe_check;
 enum bw_defines hsr_check;
@@ -122,6 +122,22 @@ static void calculate_bandwidth(
 int32_t number_of_displays_enabled_with_margin = 0;
 int32_t number_of_aligned_displays_with_no_margin = 0;

+   yclk = kcalloc(3, sizeof(*yclk), GFP_KERNEL);
+   if (!yclk)
+   return;
+
+   sclk = kcalloc(8, sizeof(*sclk), GFP_KERNEL);
+   if (!sclk)
+   goto free_yclk;
+
+   tiling_mode = kcalloc(maximum_number_of_surfaces, 
sizeof(*tiling_mode), GFP_KERNEL);

+   if (!tiling_mode)
+   goto free_sclk;
+
+   surface_type = kcalloc(maximum_number_of_surfaces, 
sizeof(*surface_type), GFP_KERNEL);

+   if (!surface_type)
+   goto free_tiling_mode;
+



Harry or Nick can correct me if I'm wrong, but for this patch and the
next one, I think this can be called from an atomic context.



From what I can see this doesn't seem the case. If I'm missing 
something someone please correct me.


Have you taken into account that using FP functions require atomic 
context as well?


We had quite a bunch of problems with that and had to replace some 
GFP_KERNEL with GFP_ATOMIC in the DC code because of this.


Could of course be that this code here isn't affected by that, but 
better save than sorry.


Christian.



This and the next (06/19) patch are both
Reviewed-by: Harry Wentland 

Harry


Alex


 yclk[low] = vbios->low_yclk;
 yclk[mid] = vbios->mid_yclk;
 yclk[high] = vbios->high_yclk;
@@ -2013,6 +2029,14 @@ static void calculate_bandwidth(
 }
 }
 }
+
+   kfree(surface_type);
+free_tiling_mode:
+   kfree(tiling_mode);
+free_yclk:
+   kfree(yclk);
+free_sclk:
+   kfree(sclk);
  }

/***
--
2.27.0

___
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: [PATCH 06/19] drm/amd/display/dc/calcs/dce_calcs: Move some large variables from the stack to the heap

[Alex Deucher]

On Fri, Mar 19, 2021 at 2:26 PM Harry Wentland  wrote:
>
> On 2021-03-19 2:13 p.m., Alex Deucher wrote:
> > + Harry, Nick
> >
> > On Fri, Mar 19, 2021 at 4:24 AM Lee Jones  wrote:
> >>
> >> Fixes the following W=1 kernel build warning(s):
> >>
> >>   drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dce_calcs.c: In function 
> >> ‘calculate_bandwidth’:
> >>   drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dce_calcs.c:2016:1: 
> >> warning: the frame size of 1216 bytes is larger than 1024 bytes 
> >> [-Wframe-larger-than=]
> >>
> >> Cc: Harry Wentland 
> >> Cc: Leo Li 
> >> Cc: Alex Deucher 
> >> Cc: "Christian König" 
> >> Cc: David Airlie 
> >> Cc: Daniel Vetter 
> >> Cc: Colin Ian King 
> >> Cc: amd-...@lists.freedesktop.org
> >> Cc: dri-devel@lists.freedesktop.org
> >> Signed-off-by: Lee Jones 
> >> ---
> >>   .../gpu/drm/amd/display/dc/calcs/dce_calcs.c  | 32 ---
> >>   1 file changed, 28 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c 
> >> b/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c
> >> index e633f8a51edb6..9d8f2505a61c2 100644
> >> --- a/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c
> >> +++ b/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c
> >> @@ -98,16 +98,16 @@ static void calculate_bandwidth(
> >>  int32_t num_cursor_lines;
> >>
> >>  int32_t i, j, k;
> >> -   struct bw_fixed yclk[3];
> >> -   struct bw_fixed sclk[8];
> >> +   struct bw_fixed *yclk;
> >> +   struct bw_fixed *sclk;
> >>  bool d0_underlay_enable;
> >>  bool d1_underlay_enable;
> >>  bool fbc_enabled;
> >>  bool lpt_enabled;
> >>  enum bw_defines sclk_message;
> >>  enum bw_defines yclk_message;
> >> -   enum bw_defines tiling_mode[maximum_number_of_surfaces];
> >> -   enum bw_defines surface_type[maximum_number_of_surfaces];
> >> +   enum bw_defines *tiling_mode;
> >> +   enum bw_defines *surface_type;
> >>  enum bw_defines voltage;
> >>  enum bw_defines pipe_check;
> >>  enum bw_defines hsr_check;
> >> @@ -122,6 +122,22 @@ static void calculate_bandwidth(
> >>  int32_t number_of_displays_enabled_with_margin = 0;
> >>  int32_t number_of_aligned_displays_with_no_margin = 0;
> >>
> >> +   yclk = kcalloc(3, sizeof(*yclk), GFP_KERNEL);
> >> +   if (!yclk)
> >> +   return;
> >> +
> >> +   sclk = kcalloc(8, sizeof(*sclk), GFP_KERNEL);
> >> +   if (!sclk)
> >> +   goto free_yclk;
> >> +
> >> +   tiling_mode = kcalloc(maximum_number_of_surfaces, 
> >> sizeof(*tiling_mode), GFP_KERNEL);
> >> +   if (!tiling_mode)
> >> +   goto free_sclk;
> >> +
> >> +   surface_type = kcalloc(maximum_number_of_surfaces, 
> >> sizeof(*surface_type), GFP_KERNEL);
> >> +   if (!surface_type)
> >> +   goto free_tiling_mode;
> >> +
> >
> >
> > Harry or Nick can correct me if I'm wrong, but for this patch and the
> > next one, I think this can be called from an atomic context.
> >
>
>  From what I can see this doesn't seem the case. If I'm missing
> something someone please correct me.
>
> This and the next (06/19) patch are both
> Reviewed-by: Harry Wentland 

Thanks.  I've applied them.

Alex


>
> Harry
>
> > Alex
> >
> >>  yclk[low] = vbios->low_yclk;
> >>  yclk[mid] = vbios->mid_yclk;
> >>  yclk[high] = vbios->high_yclk;
> >> @@ -2013,6 +2029,14 @@ static void calculate_bandwidth(
> >>  }
> >>  }
> >>  }
> >> +
> >> +   kfree(surface_type);
> >> +free_tiling_mode:
> >> +   kfree(tiling_mode);
> >> +free_yclk:
> >> +   kfree(yclk);
> >> +free_sclk:
> >> +   kfree(sclk);
> >>   }
> >>
> >>   
> >> /***
> >> --
> >> 2.27.0
> >>
> >> ___
> >> 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: [PATCH 06/19] drm/amd/display/dc/calcs/dce_calcs: Move some large variables from the stack to the heap

[Harry Wentland]

On 2021-03-19 2:13 p.m., Alex Deucher wrote:

+ Harry, Nick

On Fri, Mar 19, 2021 at 4:24 AM Lee Jones  wrote:


Fixes the following W=1 kernel build warning(s):

  drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dce_calcs.c: In function 
‘calculate_bandwidth’:
  drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dce_calcs.c:2016:1: warning: 
the frame size of 1216 bytes is larger than 1024 bytes [-Wframe-larger-than=]

Cc: Harry Wentland 
Cc: Leo Li 
Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Colin Ian King 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
  .../gpu/drm/amd/display/dc/calcs/dce_calcs.c  | 32 ---
  1 file changed, 28 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c 
b/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c
index e633f8a51edb6..9d8f2505a61c2 100644
--- a/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c
+++ b/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c
@@ -98,16 +98,16 @@ static void calculate_bandwidth(
 int32_t num_cursor_lines;

 int32_t i, j, k;
-   struct bw_fixed yclk[3];
-   struct bw_fixed sclk[8];
+   struct bw_fixed *yclk;
+   struct bw_fixed *sclk;
 bool d0_underlay_enable;
 bool d1_underlay_enable;
 bool fbc_enabled;
 bool lpt_enabled;
 enum bw_defines sclk_message;
 enum bw_defines yclk_message;
-   enum bw_defines tiling_mode[maximum_number_of_surfaces];
-   enum bw_defines surface_type[maximum_number_of_surfaces];
+   enum bw_defines *tiling_mode;
+   enum bw_defines *surface_type;
 enum bw_defines voltage;
 enum bw_defines pipe_check;
 enum bw_defines hsr_check;
@@ -122,6 +122,22 @@ static void calculate_bandwidth(
 int32_t number_of_displays_enabled_with_margin = 0;
 int32_t number_of_aligned_displays_with_no_margin = 0;

+   yclk = kcalloc(3, sizeof(*yclk), GFP_KERNEL);
+   if (!yclk)
+   return;
+
+   sclk = kcalloc(8, sizeof(*sclk), GFP_KERNEL);
+   if (!sclk)
+   goto free_yclk;
+
+   tiling_mode = kcalloc(maximum_number_of_surfaces, sizeof(*tiling_mode), 
GFP_KERNEL);
+   if (!tiling_mode)
+   goto free_sclk;
+
+   surface_type = kcalloc(maximum_number_of_surfaces, 
sizeof(*surface_type), GFP_KERNEL);
+   if (!surface_type)
+   goto free_tiling_mode;
+



Harry or Nick can correct me if I'm wrong, but for this patch and the
next one, I think this can be called from an atomic context.



From what I can see this doesn't seem the case. If I'm missing 
something someone please correct me.


This and the next (06/19) patch are both
Reviewed-by: Harry Wentland 

Harry


Alex


 yclk[low] = vbios->low_yclk;
 yclk[mid] = vbios->mid_yclk;
 yclk[high] = vbios->high_yclk;
@@ -2013,6 +2029,14 @@ static void calculate_bandwidth(
 }
 }
 }
+
+   kfree(surface_type);
+free_tiling_mode:
+   kfree(tiling_mode);
+free_yclk:
+   kfree(yclk);
+free_sclk:
+   kfree(sclk);
  }

  
/***
--
2.27.0

___
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: [PATCH 08/19] drm/amd/display/dc/dce80/dce80_resource: Make local functions static

[Harry Wentland]

On 2021-03-19 4:24 a.m., Lee Jones wrote:

Fixes the following W=1 kernel build warning(s):

  drivers/gpu/drm/amd/amdgpu/../display/dc/dce80/dce80_resource.c:527:17: 
warning: no previous prototype for ‘dce80_aux_engine_create’ 
[-Wmissing-prototypes]
  drivers/gpu/drm/amd/amdgpu/../display/dc/dce80/dce80_resource.c:565:20: 
warning: no previous prototype for ‘dce80_i2c_hw_create’ [-Wmissing-prototypes]
  drivers/gpu/drm/amd/amdgpu/../display/dc/dce80/dce80_resource.c:581:20: 
warning: no previous prototype for ‘dce80_i2c_sw_create’ [-Wmissing-prototypes]
  drivers/gpu/drm/amd/amdgpu/../display/dc/dce80/dce80_resource.c:715:22: 
warning: no previous prototype for ‘dce80_link_encoder_create’ 
[-Wmissing-prototypes]
  drivers/gpu/drm/amd/amdgpu/../display/dc/dce80/dce80_resource.c:754:22: 
warning: no previous prototype for ‘dce80_clock_source_create’ 
[-Wmissing-prototypes]
  drivers/gpu/drm/amd/amdgpu/../display/dc/dce80/dce80_resource.c:778:6: 
warning: no previous prototype for ‘dce80_clock_source_destroy’ 
[-Wmissing-prototypes]
  drivers/gpu/drm/amd/amdgpu/../display/dc/dce80/dce80_resource.c:868:6: 
warning: no previous prototype for ‘dce80_validate_bandwidth’ 
[-Wmissing-prototypes]
  drivers/gpu/drm/amd/amdgpu/../display/dc/dce80/dce80_resource.c:913:16: 
warning: no previous prototype for ‘dce80_validate_global’ 
[-Wmissing-prototypes]

Cc: Harry Wentland 
Cc: Leo Li 
Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Anthony Koo 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones 


Reviewed-by: Harry Wentland 

Harry


---
  .../drm/amd/display/dc/dce80/dce80_resource.c| 16 
  1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dce80/dce80_resource.c 
b/drivers/gpu/drm/amd/display/dc/dce80/dce80_resource.c
index 612450f992782..725d92e40cd30 100644
--- a/drivers/gpu/drm/amd/display/dc/dce80/dce80_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dce80/dce80_resource.c
@@ -526,7 +526,7 @@ static struct output_pixel_processor *dce80_opp_create(
return >base;
  }
  
-struct dce_aux *dce80_aux_engine_create(

+static struct dce_aux *dce80_aux_engine_create(
struct dc_context *ctx,
uint32_t inst)
  {
@@ -564,7 +564,7 @@ static const struct dce_i2c_mask i2c_masks = {
I2C_COMMON_MASK_SH_LIST_DCE_COMMON_BASE(_MASK)
  };
  
-struct dce_i2c_hw *dce80_i2c_hw_create(

+static struct dce_i2c_hw *dce80_i2c_hw_create(
struct dc_context *ctx,
uint32_t inst)
  {
@@ -580,7 +580,7 @@ struct dce_i2c_hw *dce80_i2c_hw_create(
return dce_i2c_hw;
  }
  
-struct dce_i2c_sw *dce80_i2c_sw_create(

+static struct dce_i2c_sw *dce80_i2c_sw_create(
struct dc_context *ctx)
  {
struct dce_i2c_sw *dce_i2c_sw =
@@ -714,7 +714,7 @@ static const struct encoder_feature_support 
link_enc_feature = {
.flags.bits.IS_TPS3_CAPABLE = true
  };
  
-struct link_encoder *dce80_link_encoder_create(

+static struct link_encoder *dce80_link_encoder_create(
const struct encoder_init_data *enc_init_data)
  {
struct dce110_link_encoder *enc110 =
@@ -753,7 +753,7 @@ static struct panel_cntl *dce80_panel_cntl_create(const 
struct panel_cntl_init_d
return _cntl->base;
  }
  
-struct clock_source *dce80_clock_source_create(

+static struct clock_source *dce80_clock_source_create(
struct dc_context *ctx,
struct dc_bios *bios,
enum clock_source_id id,
@@ -777,7 +777,7 @@ struct clock_source *dce80_clock_source_create(
return NULL;
  }
  
-void dce80_clock_source_destroy(struct clock_source **clk_src)

+static void dce80_clock_source_destroy(struct clock_source **clk_src)
  {
kfree(TO_DCE110_CLK_SRC(*clk_src));
*clk_src = NULL;
@@ -867,7 +867,7 @@ static void dce80_resource_destruct(struct 
dce110_resource_pool *pool)
}
  }
  
-bool dce80_validate_bandwidth(

+static bool dce80_validate_bandwidth(
struct dc *dc,
struct dc_state *context,
bool fast_validate)
@@ -912,7 +912,7 @@ static bool dce80_validate_surface_sets(
return true;
  }
  
-enum dc_status dce80_validate_global(

+static enum dc_status dce80_validate_global(
struct dc *dc,
struct dc_state *context)
  {



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 08/19] drm/amd/display/dc/dce80/dce80_resource: Make local functions static

[Alex Deucher]

On Fri, Mar 19, 2021 at 4:24 AM Lee Jones  wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
>  drivers/gpu/drm/amd/amdgpu/../display/dc/dce80/dce80_resource.c:527:17: 
> warning: no previous prototype for ‘dce80_aux_engine_create’ 
> [-Wmissing-prototypes]
>  drivers/gpu/drm/amd/amdgpu/../display/dc/dce80/dce80_resource.c:565:20: 
> warning: no previous prototype for ‘dce80_i2c_hw_create’ 
> [-Wmissing-prototypes]
>  drivers/gpu/drm/amd/amdgpu/../display/dc/dce80/dce80_resource.c:581:20: 
> warning: no previous prototype for ‘dce80_i2c_sw_create’ 
> [-Wmissing-prototypes]
>  drivers/gpu/drm/amd/amdgpu/../display/dc/dce80/dce80_resource.c:715:22: 
> warning: no previous prototype for ‘dce80_link_encoder_create’ 
> [-Wmissing-prototypes]
>  drivers/gpu/drm/amd/amdgpu/../display/dc/dce80/dce80_resource.c:754:22: 
> warning: no previous prototype for ‘dce80_clock_source_create’ 
> [-Wmissing-prototypes]
>  drivers/gpu/drm/amd/amdgpu/../display/dc/dce80/dce80_resource.c:778:6: 
> warning: no previous prototype for ‘dce80_clock_source_destroy’ 
> [-Wmissing-prototypes]
>  drivers/gpu/drm/amd/amdgpu/../display/dc/dce80/dce80_resource.c:868:6: 
> warning: no previous prototype for ‘dce80_validate_bandwidth’ 
> [-Wmissing-prototypes]
>  drivers/gpu/drm/amd/amdgpu/../display/dc/dce80/dce80_resource.c:913:16: 
> warning: no previous prototype for ‘dce80_validate_global’ 
> [-Wmissing-prototypes]
>
> Cc: Harry Wentland 
> Cc: Leo Li 
> Cc: Alex Deucher 
> Cc: "Christian König" 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Anthony Koo 
> Cc: amd-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Lee Jones 

Applied.  Thanks!

Alex


> ---
>  .../drm/amd/display/dc/dce80/dce80_resource.c| 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dce80/dce80_resource.c 
> b/drivers/gpu/drm/amd/display/dc/dce80/dce80_resource.c
> index 612450f992782..725d92e40cd30 100644
> --- a/drivers/gpu/drm/amd/display/dc/dce80/dce80_resource.c
> +++ b/drivers/gpu/drm/amd/display/dc/dce80/dce80_resource.c
> @@ -526,7 +526,7 @@ static struct output_pixel_processor *dce80_opp_create(
> return >base;
>  }
>
> -struct dce_aux *dce80_aux_engine_create(
> +static struct dce_aux *dce80_aux_engine_create(
> struct dc_context *ctx,
> uint32_t inst)
>  {
> @@ -564,7 +564,7 @@ static const struct dce_i2c_mask i2c_masks = {
> I2C_COMMON_MASK_SH_LIST_DCE_COMMON_BASE(_MASK)
>  };
>
> -struct dce_i2c_hw *dce80_i2c_hw_create(
> +static struct dce_i2c_hw *dce80_i2c_hw_create(
> struct dc_context *ctx,
> uint32_t inst)
>  {
> @@ -580,7 +580,7 @@ struct dce_i2c_hw *dce80_i2c_hw_create(
> return dce_i2c_hw;
>  }
>
> -struct dce_i2c_sw *dce80_i2c_sw_create(
> +static struct dce_i2c_sw *dce80_i2c_sw_create(
> struct dc_context *ctx)
>  {
> struct dce_i2c_sw *dce_i2c_sw =
> @@ -714,7 +714,7 @@ static const struct encoder_feature_support 
> link_enc_feature = {
> .flags.bits.IS_TPS3_CAPABLE = true
>  };
>
> -struct link_encoder *dce80_link_encoder_create(
> +static struct link_encoder *dce80_link_encoder_create(
> const struct encoder_init_data *enc_init_data)
>  {
> struct dce110_link_encoder *enc110 =
> @@ -753,7 +753,7 @@ static struct panel_cntl *dce80_panel_cntl_create(const 
> struct panel_cntl_init_d
> return _cntl->base;
>  }
>
> -struct clock_source *dce80_clock_source_create(
> +static struct clock_source *dce80_clock_source_create(
> struct dc_context *ctx,
> struct dc_bios *bios,
> enum clock_source_id id,
> @@ -777,7 +777,7 @@ struct clock_source *dce80_clock_source_create(
> return NULL;
>  }
>
> -void dce80_clock_source_destroy(struct clock_source **clk_src)
> +static void dce80_clock_source_destroy(struct clock_source **clk_src)
>  {
> kfree(TO_DCE110_CLK_SRC(*clk_src));
> *clk_src = NULL;
> @@ -867,7 +867,7 @@ static void dce80_resource_destruct(struct 
> dce110_resource_pool *pool)
> }
>  }
>
> -bool dce80_validate_bandwidth(
> +static bool dce80_validate_bandwidth(
> struct dc *dc,
> struct dc_state *context,
> bool fast_validate)
> @@ -912,7 +912,7 @@ static bool dce80_validate_surface_sets(
> return true;
>  }
>
> -enum dc_status dce80_validate_global(
> +static enum dc_status dce80_validate_global(
> struct dc *dc,
> struct dc_state *context)
>  {
> --
> 2.27.0
>
> ___
> 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: [PATCH V2] drm/bridge: lvds-codec: Add support for pixel data sampling edge select

[Marek Vasut]

On 1/24/21 6:04 PM, Marek Vasut wrote:

On 12/24/20 7:18 AM, Marek Vasut wrote:

The OnSemi FIN3385 Parallel-to-LVDS encoder has a dedicated input line to
select input pixel data sampling edge. Add DT property "pixelclk-active",
same as the one used by display timings, and configure bus flags based on
this DT property.


Bump ?


Any news on this patch ?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 06/19] drm/amd/display/dc/calcs/dce_calcs: Move some large variables from the stack to the heap

[Alex Deucher]

+ Harry, Nick

On Fri, Mar 19, 2021 at 4:24 AM Lee Jones  wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
>  drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dce_calcs.c: In function 
> ‘calculate_bandwidth’:
>  drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dce_calcs.c:2016:1: warning: 
> the frame size of 1216 bytes is larger than 1024 bytes [-Wframe-larger-than=]
>
> Cc: Harry Wentland 
> Cc: Leo Li 
> Cc: Alex Deucher 
> Cc: "Christian König" 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Colin Ian King 
> Cc: amd-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Lee Jones 
> ---
>  .../gpu/drm/amd/display/dc/calcs/dce_calcs.c  | 32 ---
>  1 file changed, 28 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c 
> b/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c
> index e633f8a51edb6..9d8f2505a61c2 100644
> --- a/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c
> +++ b/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c
> @@ -98,16 +98,16 @@ static void calculate_bandwidth(
> int32_t num_cursor_lines;
>
> int32_t i, j, k;
> -   struct bw_fixed yclk[3];
> -   struct bw_fixed sclk[8];
> +   struct bw_fixed *yclk;
> +   struct bw_fixed *sclk;
> bool d0_underlay_enable;
> bool d1_underlay_enable;
> bool fbc_enabled;
> bool lpt_enabled;
> enum bw_defines sclk_message;
> enum bw_defines yclk_message;
> -   enum bw_defines tiling_mode[maximum_number_of_surfaces];
> -   enum bw_defines surface_type[maximum_number_of_surfaces];
> +   enum bw_defines *tiling_mode;
> +   enum bw_defines *surface_type;
> enum bw_defines voltage;
> enum bw_defines pipe_check;
> enum bw_defines hsr_check;
> @@ -122,6 +122,22 @@ static void calculate_bandwidth(
> int32_t number_of_displays_enabled_with_margin = 0;
> int32_t number_of_aligned_displays_with_no_margin = 0;
>
> +   yclk = kcalloc(3, sizeof(*yclk), GFP_KERNEL);
> +   if (!yclk)
> +   return;
> +
> +   sclk = kcalloc(8, sizeof(*sclk), GFP_KERNEL);
> +   if (!sclk)
> +   goto free_yclk;
> +
> +   tiling_mode = kcalloc(maximum_number_of_surfaces, 
> sizeof(*tiling_mode), GFP_KERNEL);
> +   if (!tiling_mode)
> +   goto free_sclk;
> +
> +   surface_type = kcalloc(maximum_number_of_surfaces, 
> sizeof(*surface_type), GFP_KERNEL);
> +   if (!surface_type)
> +   goto free_tiling_mode;
> +


Harry or Nick can correct me if I'm wrong, but for this patch and the
next one, I think this can be called from an atomic context.

Alex

> yclk[low] = vbios->low_yclk;
> yclk[mid] = vbios->mid_yclk;
> yclk[high] = vbios->high_yclk;
> @@ -2013,6 +2029,14 @@ static void calculate_bandwidth(
> }
> }
> }
> +
> +   kfree(surface_type);
> +free_tiling_mode:
> +   kfree(tiling_mode);
> +free_yclk:
> +   kfree(yclk);
> +free_sclk:
> +   kfree(sclk);
>  }
>
>  
> /***
> --
> 2.27.0
>
> ___
> 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: [RESEND 00/53] Rid GPU from W=1 warnings

[Daniel Vetter]

On Fri, Mar 19, 2021 at 08:24:07AM +, Lee Jones wrote:
> On Thu, 18 Mar 2021, Daniel Vetter wrote:
> 
> > On Wed, Mar 17, 2021 at 9:32 PM Daniel Vetter  wrote:
> > >
> > > On Wed, Mar 17, 2021 at 9:17 AM Lee Jones  wrote:
> > > >
> > > > On Thu, 11 Mar 2021, Lee Jones wrote:
> > > >
> > > > > On Thu, 11 Mar 2021, Daniel Vetter wrote:
> > > > >
> > > > > > On Mon, Mar 08, 2021 at 09:19:32AM +, Lee Jones wrote:
> > > > > > > On Fri, 05 Mar 2021, Roland Scheidegger wrote:
> > > > > > >
> > > > > > > > The vmwgfx ones look all good to me, so for
> > > > > > > > 23-53: Reviewed-by: Roland Scheidegger 
> > > > > > > > That said, they were already signed off by Zack, so not sure 
> > > > > > > > what
> > > > > > > > happened here.
> > > > > > >
> > > > > > > Yes, they were accepted at one point, then dropped without a 
> > > > > > > reason.
> > > > > > >
> > > > > > > Since I rebased onto the latest -next, I had to pluck them back 
> > > > > > > out of
> > > > > > > a previous one.
> > > > > >
> > > > > > They should show up in linux-next again. We merge patches for next 
> > > > > > merge
> > > > > > window even during the current merge window, but need to make sure 
> > > > > > they
> > > > > > don't pollute linux-next. Occasionally the cut off is wrong so 
> > > > > > patches
> > > > > > show up, and then get pulled again.
> > > > > >
> > > > > > Unfortunately especially the 5.12 merge cycle was very wobbly due 
> > > > > > to some
> > > > > > confusion here. But your patches should all be in linux-next again 
> > > > > > (they
> > > > > > are queued up for 5.13 in drm-misc-next, I checked that).
> > > > > >
> > > > > > Sorry for the confusion here.
> > > > >
> > > > > Oh, I see.  Well so long as they don't get dropped, I'll be happy.
> > > > >
> > > > > Thanks for the explanation Daniel
> > > >
> > > > After rebasing today, all of my GPU patches have remained.  Would
> > > > someone be kind enough to check that everything is still in order
> > > > please?
> > >
> > > It's still broken somehow. I've kiced Maxime and Maarten again,
> > > they're also on this thread.
> > 
> > You're patches have made it into drm-next meanwhile, so they should
> > show up in linux-next through that tree at least. Except if that one
> > also has some trouble.
> 
> Thanks for letting me know.
> 
> I see some patches made it back in, others didn't.
> 
> I'll resend the stragglers - bear with.

The vmwgfx ones should all be back, the others I guess just werent ever
applied. I'll vacuum them all up if you resend. Apologies for the wobbly
ride.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/ttm: stop warning on TT shrinker failure

[Daniel Vetter]

On Fri, Mar 19, 2021 at 03:08:57PM +0100, Christian König wrote:
> Don't print a warning when we fail to allocate a page for swapping things out.
> 
> Also rely on memalloc_nofs_save/memalloc_nofs_restore instead of GFP_NOFS.

Uh this part doesn't make sense. Especially since you only do it for the
debugfs file, not in general. Which means you've just completely broken
the shrinker.

If this is just to paper over the seq_printf doing the wrong allocations,
then just move that out from under the fs_reclaim_acquire/release part.

__GFP_NOWARN should be there indeed I think.
-Daniel

> 
> Signed-off-by: Christian König 
> ---
>  drivers/gpu/drm/ttm/ttm_tt.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
> index 2f0833c98d2c..86fa3e82dacc 100644
> --- a/drivers/gpu/drm/ttm/ttm_tt.c
> +++ b/drivers/gpu/drm/ttm/ttm_tt.c
> @@ -369,7 +369,7 @@ static unsigned long ttm_tt_shrinker_scan(struct shrinker 
> *shrink,
>   };
>   int ret;
>  
> - ret = ttm_bo_swapout(, GFP_NOFS);
> + ret = ttm_bo_swapout(, GFP_KERNEL | __GFP_NOWARN);
>   return ret < 0 ? SHRINK_EMPTY : ret;
>  }
>  
> @@ -389,10 +389,13 @@ static unsigned long ttm_tt_shrinker_count(struct 
> shrinker *shrink,
>  static int ttm_tt_debugfs_shrink_show(struct seq_file *m, void *data)
>  {
>   struct shrink_control sc = { .gfp_mask = GFP_KERNEL };
> + unsigned int flags;
>  
>   fs_reclaim_acquire(GFP_KERNEL);
> + flags = memalloc_nofs_save();
>   seq_printf(m, "%lu/%lu\n", ttm_tt_shrinker_count(_shrinker, ),
>  ttm_tt_shrinker_scan(_shrinker, ));
> + memalloc_nofs_restore(flags);
>   fs_reclaim_release(GFP_KERNEL);
>  
>   return 0;
> -- 
> 2.25.1
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 14/19] drm/nouveau/dispnv50/headc57d: Make local function 'headc57d_olut' static

[Lyude Paul]

Reviewed-by: Lyude Paul 

On Fri, 2021-03-19 at 08:24 +, Lee Jones wrote:
> Fixes the following W=1 kernel build warning(s):
> 
>  drivers/gpu/drm/nouveau/dispnv50/headc57d.c:173:1: warning: no previous
> prototype for ‘headc57d_olut’ [-Wmissing-prototypes]
> 
> Cc: Ben Skeggs 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Lyude Paul 
> Cc: dri-devel@lists.freedesktop.org
> Cc: nouv...@lists.freedesktop.org
> Signed-off-by: Lee Jones 
> ---
>  drivers/gpu/drm/nouveau/dispnv50/headc57d.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/nouveau/dispnv50/headc57d.c
> b/drivers/gpu/drm/nouveau/dispnv50/headc57d.c
> index fd51527b56b83..bdcfd240d61c8 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/headc57d.c
> +++ b/drivers/gpu/drm/nouveau/dispnv50/headc57d.c
> @@ -169,7 +169,7 @@ headc57d_olut_load(struct drm_color_lut *in, int size,
> void __iomem *mem)
> writew(readw(mem - 4), mem + 4);
>  }
>  
> -bool
> +static bool
>  headc57d_olut(struct nv50_head *head, struct nv50_head_atom *asyh, int size)
>  {
> if (size != 0 && size != 256 && size != 1024)

-- 
Sincerely,
   Lyude Paul (she/her)
   Software Engineer at Red Hat
   
Note: I deal with a lot of emails and have a lot of bugs on my plate. If you've
asked me a question, are waiting for a review/merge on a patch, etc. and I
haven't responded in a while, please feel free to send me another email to check
on my status. I don't bite!

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/ttm: stop warning on TT shrinker failure

[Deucher, Alexander]

[AMD Official Use Only - Internal Distribution Only]

+ Leo

From: amd-gfx  on behalf of Christian 
König 
Sent: Friday, March 19, 2021 10:08 AM
To: Liu, Leo ; amd-...@lists.freedesktop.org 
; dri-devel@lists.freedesktop.org 

Subject: [PATCH] drm/ttm: stop warning on TT shrinker failure

Don't print a warning when we fail to allocate a page for swapping things out.

Also rely on memalloc_nofs_save/memalloc_nofs_restore instead of GFP_NOFS.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/ttm/ttm_tt.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index 2f0833c98d2c..86fa3e82dacc 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -369,7 +369,7 @@ static unsigned long ttm_tt_shrinker_scan(struct shrinker 
*shrink,
 };
 int ret;

-   ret = ttm_bo_swapout(, GFP_NOFS);
+   ret = ttm_bo_swapout(, GFP_KERNEL | __GFP_NOWARN);
 return ret < 0 ? SHRINK_EMPTY : ret;
 }

@@ -389,10 +389,13 @@ static unsigned long ttm_tt_shrinker_count(struct 
shrinker *shrink,
 static int ttm_tt_debugfs_shrink_show(struct seq_file *m, void *data)
 {
 struct shrink_control sc = { .gfp_mask = GFP_KERNEL };
+   unsigned int flags;

 fs_reclaim_acquire(GFP_KERNEL);
+   flags = memalloc_nofs_save();
 seq_printf(m, "%lu/%lu\n", ttm_tt_shrinker_count(_shrinker, ),
ttm_tt_shrinker_scan(_shrinker, ));
+   memalloc_nofs_restore(flags);
 fs_reclaim_release(GFP_KERNEL);

 return 0;
--
2.25.1

___
amd-gfx mailing list
amd-...@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfxdata=04%7C01%7Calexander.deucher%40amd.com%7C70aef4974dfe465a06a308d8eae08eb3%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637517597539809703%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=kvyinv9FPakf76dvXF0pzfeCpclxAo3L4Ufkf6%2B6%2FCc%3Dreserved=0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] gpu/drm/msm: fix shutdown hook in case GPU components failed to bind

[Fabio Estevam]

On Fri, Mar 19, 2021 at 12:13 PM Fabio Estevam  wrote:

> Thanks for the feedback.
> I will follow the same approach for fixing the suspend/resume path then.
>
> Let me test it and then I will re-submit Dmitry's patch and the one
> for suspend/resume as part of a patch series.

This approach works here for the suspend/resume path too.

I have just submitted the series, thanks.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/2] drm/msm: Fix suspend/resume on i.MX5

[Fabio Estevam]

When putting iMX5 into suspend, the following flow is
observed:

[   70.023427] [] (msm_atomic_commit_tail) from []
(commit_tail+0x9c/0x18c)
[   70.031890] [] (commit_tail) from []
(drm_atomic_helper_commit+0x1a0/0x1d4)
[   70.040627] [] (drm_atomic_helper_commit) from
[] (drm_atomic_helper_disable_all+0x1c4/0x1d4)
[   70.050913] [] (drm_atomic_helper_disable_all) from
[] (drm_atomic_helper_suspend+0xb8/0x170)
[   70.061198] [] (drm_atomic_helper_suspend) from
[] (drm_mode_config_helper_suspend+0x24/0x58)

In the i.MX5 case, priv->kms is not populated (as i.MX5 does not use any
of the Qualcomm display controllers), causing a NULL pointer
dereference in msm_atomic_commit_tail():

[   24.268964] 8<--- cut here ---
[   24.274602] Unable to handle kernel NULL pointer dereference at
virtual address 
[   24.283434] pgd = (ptrval)
[   24.286387] [] *pgd=ca212831
[   24.290788] Internal error: Oops: 17 [#1] SMP ARM
[   24.295609] Modules linked in:
[   24.298777] CPU: 0 PID: 197 Comm: init Not tainted 5.11.0-rc2-next-20210111 
#333
[   24.306276] Hardware name: Freescale i.MX53 (Device Tree Support)
[   24.312442] PC is at msm_atomic_commit_tail+0x54/0xb9c
[   24.317743] LR is at commit_tail+0xa4/0x1b0

Fix the problem by calling drm_mode_config_helper_suspend/resume()
only when priv->kms is available.

Fixes: ca8199f13498 ("drm/msm/dpu: ensure device suspend happens during PM 
sleep")
Signed-off-by: Fabio Estevam 
---
 drivers/gpu/drm/msm/msm_drv.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index fd2ac54caf9f..a5c6b8c23336 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -1072,6 +1072,10 @@ static int __maybe_unused msm_pm_resume(struct device 
*dev)
 static int __maybe_unused msm_pm_prepare(struct device *dev)
 {
struct drm_device *ddev = dev_get_drvdata(dev);
+   struct msm_drm_private *priv = ddev ? ddev->dev_private : NULL;
+
+   if (!priv || !priv->kms)
+   return 0;
 
return drm_mode_config_helper_suspend(ddev);
 }
@@ -1079,6 +1083,10 @@ static int __maybe_unused msm_pm_prepare(struct device 
*dev)
 static void __maybe_unused msm_pm_complete(struct device *dev)
 {
struct drm_device *ddev = dev_get_drvdata(dev);
+   struct msm_drm_private *priv = ddev ? ddev->dev_private : NULL;
+
+   if (!priv || !priv->kms)
+   return;
 
drm_mode_config_helper_resume(ddev);
 }
-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/2] drm/msm: fix shutdown hook in case GPU components failed to bind

[Fabio Estevam]

From: Dmitry Baryshkov 

If GPU components have failed to bind, shutdown callback would fail with
the following backtrace. Add safeguard check to stop that oops from
happening and allow the board to reboot.

[   66.617046] Unable to handle kernel NULL pointer dereference at virtual 
address 
[   66.626066] Mem abort info:
[   66.628939]   ESR = 0x9606
[   66.632088]   EC = 0x25: DABT (current EL), IL = 32 bits
[   66.637542]   SET = 0, FnV = 0
[   66.640688]   EA = 0, S1PTW = 0
[   66.643924] Data abort info:
[   66.646889]   ISV = 0, ISS = 0x0006
[   66.650832]   CM = 0, WnR = 0
[   66.653890] user pgtable: 4k pages, 48-bit VAs, pgdp=000107f81000
[   66.660505] [] pgd=000100bb2003, p4d=000100bb2003, 
pud=000100897003, pmd=
[   66.671398] Internal error: Oops: 9606 [#1] PREEMPT SMP
[   66.677115] Modules linked in:
[   66.680261] CPU: 6 PID: 352 Comm: reboot Not tainted 
5.11.0-rc2-00309-g79e3faa756b2 #38
[   66.688473] Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT)
[   66.695347] pstate: 6045 (nZCv daif +PAN -UAO -TCO BTYPE=--)
[   66.701507] pc : msm_atomic_commit_tail+0x78/0x4e0
[   66.706437] lr : commit_tail+0xa4/0x184
[   66.710381] sp : 8000108f3af0
[   66.713791] x29: 8000108f3af0 x28: 418c44337000
[   66.719242] x27:  x26: 418c40a24490
[   66.724693] x25: d3a842a4f1a0 x24: 0008
[   66.730146] x23: d3a84313f030 x22: 418c444ce000
[   66.735598] x21: 418c408a4980 x20: 
[   66.741049] x19:  x18: 800010710fbc
[   66.746500] x17: 000c x16: 0001
[   66.751954] x15: 00010008 x14: 0068
[   66.757405] x13: 0001 x12: 
[   66.762855] x11: 0001 x10: 09b0
[   66.768306] x9 : d3a843192000 x8 : 418c44337000
[   66.773757] x7 :  x6 : a401b34e
[   66.779210] x5 : 00ff x4 : 
[   66.784660] x3 :  x2 : 418c444ce000
[   66.790111] x1 : d3a841dce530 x0 : 418c444cf000
[   66.795563] Call trace:
[   66.798075]  msm_atomic_commit_tail+0x78/0x4e0
[   66.802633]  commit_tail+0xa4/0x184
[   66.806217]  drm_atomic_helper_commit+0x160/0x390
[   66.811051]  drm_atomic_commit+0x4c/0x60
[   66.815082]  drm_atomic_helper_disable_all+0x1f4/0x210
[   66.820355]  drm_atomic_helper_shutdown+0x80/0x130
[   66.825276]  msm_pdev_shutdown+0x14/0x20
[   66.829303]  platform_shutdown+0x28/0x40
[   66.80]  device_shutdown+0x158/0x330
[   66.837357]  kernel_restart+0x40/0xa0
[   66.841122]  __do_sys_reboot+0x228/0x250
[   66.845148]  __arm64_sys_reboot+0x28/0x34
[   66.849264]  el0_svc_common.constprop.0+0x74/0x190
[   66.854187]  do_el0_svc+0x24/0x90
[   66.857595]  el0_svc+0x14/0x20
[   66.860739]  el0_sync_handler+0x1a4/0x1b0
[   66.864858]  el0_sync+0x174/0x180
[   66.868269] Code: 1ac020a0 2a000273 eb02007f 5401 (f9400285)
[   66.874525] ---[ end trace 20dedb2a3229fec8 ]---

Fixes: 9d5cbf5fe46e ("drm/msm: add shutdown support for display 
platform_driver")
Signed-off-by: Dmitry Baryshkov 
Signed-off-by: Fabio Estevam 
---
 drivers/gpu/drm/msm/msm_drv.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 94525ac76d4e..fd2ac54caf9f 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -1311,6 +1311,10 @@ static int msm_pdev_remove(struct platform_device *pdev)
 static void msm_pdev_shutdown(struct platform_device *pdev)
 {
struct drm_device *drm = platform_get_drvdata(pdev);
+   struct msm_drm_private *priv = drm ? drm->dev_private : NULL;
+
+   if (!priv || !priv->kms)
+   return;
 
drm_atomic_helper_shutdown(drm);
 }
-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: bridge: adv7511: Support I2S IEC958 encoded PCM format

[Robert Foss]

Hey Sia,

Thanks for the patch, it looks good to me.

Reviewed-by: Robert Foss 

On Fri, 12 Mar 2021 at 10:09, Sia Jee Heng  wrote:
>
> Support IEC958 encoded PCM format for ADV7511 so that ADV7511 HDMI
> audio driver can accept the IEC958 data from the I2S input.
>
> Signed-off-by: Sia Jee Heng 
> ---
>  drivers/gpu/drm/bridge/adv7511/adv7511.h   | 1 +
>  drivers/gpu/drm/bridge/adv7511/adv7511_audio.c | 6 ++
>  2 files changed, 7 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511.h 
> b/drivers/gpu/drm/bridge/adv7511/adv7511.h
> index a9bb734366ae..05e3abb5a0c9 100644
> --- a/drivers/gpu/drm/bridge/adv7511/adv7511.h
> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511.h
> @@ -191,6 +191,7 @@
>  #define ADV7511_I2S_FORMAT_I2S 0
>  #define ADV7511_I2S_FORMAT_RIGHT_J 1
>  #define ADV7511_I2S_FORMAT_LEFT_J  2
> +#define ADV7511_I2S_IEC958_DIRECT  3
>
>  #define ADV7511_PACKET(p, x)   ((p) * 0x20 + (x))
>  #define ADV7511_PACKET_SDP(x)  ADV7511_PACKET(0, x)
> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c 
> b/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c
> index 45838bd08d37..61f4a38e7d2b 100644
> --- a/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c
> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c
> @@ -101,6 +101,10 @@ static int adv7511_hdmi_hw_params(struct device *dev, 
> void *data,
> case 20:
> len = ADV7511_I2S_SAMPLE_LEN_20;
> break;
> +   case 32:
> +   if (fmt->bit_fmt != SNDRV_PCM_FORMAT_IEC958_SUBFRAME_LE)
> +   return -EINVAL;
> +   fallthrough;
> case 24:
> len = ADV7511_I2S_SAMPLE_LEN_24;
> break;
> @@ -112,6 +116,8 @@ static int adv7511_hdmi_hw_params(struct device *dev, 
> void *data,
> case HDMI_I2S:
> audio_source = ADV7511_AUDIO_SOURCE_I2S;
> i2s_format = ADV7511_I2S_FORMAT_I2S;
> +   if (fmt->bit_fmt == SNDRV_PCM_FORMAT_IEC958_SUBFRAME_LE)
> +   i2s_format = ADV7511_I2S_IEC958_DIRECT;
> break;
> case HDMI_RIGHT_J:
> audio_source = ADV7511_AUDIO_SOURCE_I2S;
>
> base-commit: de066e116306baf3a6a62691ac63cfc0b1dabddb
> --
> 2.18.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/i915/display/vlv_dsi: Do no shut down displays on reboot if a DSI panel is used

[Hans de Goede]

Hi,

On 3/1/21 4:43 PM, Hans de Goede wrote:
> After the recently added commit fe0f1e3bfdfe ("drm/i915: Shut down
> displays gracefully on reboot"), the DSI panel on a Cherry Trail based
> Predia Basic tablet would no longer properly light up after reboot.
> 
> The backlight still turns back on after reboot, but the LCD shows an
> all black display. The display is also all black during the time that
> EFI / the GOP is managing it, so e.g. the grub menu also is not visible.
> 
> In this scenario the panel is initialized so that it appears to be working
> and the fastboot code skips doing a modeset. Forcing a modeset by doing a
> chvt to a text-console over ssh followed by echo-ing 1 and then 0 to
> /sys/class/graphics/fb0/blank causes the panel to work again.
> 
> Add a QUIRK_SKIP_SHUTDOWN quirk which turns i915_driver_shutdown() into
> a no-op when set; and set this on vlv/chv devices when a DSI panel is
> detected, to work around this.
> 
> Admittedly this is a bit of a big hammer, but these platforms have been
> around for quite some time now and they have always worked fine without
> the new behavior to shutdown everything on shutdown/reboot. This approach
> simply disables the recently introduced new shutdown behavior in this
> specific case where it is known to cause problems. Which is a nice and
> simple way to deal with this.
> 
> Signed-off-by: Hans de Goede 

Ping? Since sending this patch I've been seeing the issue addressed by
this on variour other CHT based devices too.

So we have various devices suffering from a black screen after reboot
now. This is pretty serious usability regression.

As such it would be good to get this reviewed, or another fix proposed.

Regards,

Hans



> ---
>  drivers/gpu/drm/i915/display/vlv_dsi.c | 3 +++
>  drivers/gpu/drm/i915/i915_drv.c| 3 +++
>  drivers/gpu/drm/i915/i915_drv.h| 1 +
>  3 files changed, 7 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/vlv_dsi.c 
> b/drivers/gpu/drm/i915/display/vlv_dsi.c
> index f94025ec603a..792ef868b6af 100644
> --- a/drivers/gpu/drm/i915/display/vlv_dsi.c
> +++ b/drivers/gpu/drm/i915/display/vlv_dsi.c
> @@ -1949,6 +1949,9 @@ void vlv_dsi_init(struct drm_i915_private *dev_priv)
>  
>   vlv_dsi_add_properties(intel_connector);
>  
> + /* Some BIOS-es fail to re-init the DSI panel on reboot if we turn it 
> off */
> + dev_priv->quirks |= QUIRK_SKIP_SHUTDOWN;
> +
>   return;
>  
>  err_cleanup_connector:
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 8e9cb44e66e5..92f2af55af6d 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1048,6 +1048,9 @@ static void intel_shutdown_encoders(struct 
> drm_i915_private *dev_priv)
>  
>  void i915_driver_shutdown(struct drm_i915_private *i915)
>  {
> + if (i915->quirks & QUIRK_SKIP_SHUTDOWN)
> + return;
> +
>   disable_rpm_wakeref_asserts(>runtime_pm);
>  
>   i915_gem_suspend(i915);
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 26d69d06aa6d..272cd7cb22d4 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -517,6 +517,7 @@ struct i915_psr {
>  #define QUIRK_PIN_SWIZZLED_PAGES (1<<5)
>  #define QUIRK_INCREASE_T12_DELAY (1<<6)
>  #define QUIRK_INCREASE_DDI_DISABLED_TIME (1<<7)
> +#define QUIRK_SKIP_SHUTDOWN (1<<8)
>  
>  struct intel_fbdev;
>  struct intel_fbc_work;
> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/rockchip: Remove unused variable

[Maxime Ripard]

Commit 977697e20b3d ("drm/atomic: Pass the full state to planes atomic
disable and update") added the old_state variable instead of what used
to be a parameter, but it also removed the sole user of that variable in
the vop_plane_atomic_update function leading to an usused variable.
Remove it.

Fixes: 977697e20b3d ("drm/atomic: Pass the full state to planes atomic disable 
and update")
Reported-by: Stephen Rothwell 
Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 81c70d7a0471..64469439ddf2 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -879,8 +879,6 @@ static void vop_plane_atomic_disable(struct drm_plane 
*plane,
 static void vop_plane_atomic_update(struct drm_plane *plane,
struct drm_atomic_state *state)
 {
-   struct drm_plane_state *old_state = 
drm_atomic_get_old_plane_state(state,
-  
plane);
struct drm_plane_state *new_state = 
drm_atomic_get_new_plane_state(state,
   
plane);
struct drm_crtc *crtc = new_state->crtc;
-- 
2.30.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] gpu/drm/msm: fix shutdown hook in case GPU components failed to bind

[Rob Clark]

On Fri, Mar 19, 2021 at 8:13 AM Fabio Estevam  wrote:
>
> Hi Rob,
>
> On Fri, Mar 19, 2021 at 11:44 AM Rob Clark  wrote:
>
> > I think that might not help if something fails to probe due to (for
> > example) a missing dependency, so !priv->kms is probably a better
> > check to cover both cases.  But the 2nd patch makes a good point, that
> > the suspend/resume path probably needs the same treatment
>
> Thanks for the feedback.
> I will follow the same approach for fixing the suspend/resume path then.
>
> Let me test it and then I will re-submit Dmitry's patch and the one
> for suspend/resume as part of a patch series.

Thanks,

BR,
-R
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] gpu/drm/msm: fix shutdown hook in case GPU components failed to bind

[Fabio Estevam]

Hi Rob,

On Fri, Mar 19, 2021 at 11:44 AM Rob Clark  wrote:

> I think that might not help if something fails to probe due to (for
> example) a missing dependency, so !priv->kms is probably a better
> check to cover both cases.  But the 2nd patch makes a good point, that
> the suspend/resume path probably needs the same treatment

Thanks for the feedback.
I will follow the same approach for fixing the suspend/resume path then.

Let me test it and then I will re-submit Dmitry's patch and the one
for suspend/resume as part of a patch series.

Thanks
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/amd/display: Set AMDGPU_DM_DEFAULT_MIN_BACKLIGHT to 0

[Harry Wentland]

On 2021-03-19 10:22 a.m., Alex Deucher wrote:

On Fri, Mar 19, 2021 at 3:23 AM Evan Benn  wrote:


AMDGPU_DM_DEFAULT_MIN_BACKLIGHT was set to the value of 12
to ensure no display backlight will flicker at low user brightness
settings. However this value is quite bright, so for devices that do not
implement the ACPI ATIF
ATIF_FUNCTION_QUERY_BRIGHTNESS_TRANSFER_CHARACTERISTICS
functionality the user cannot set the brightness to a low level even if
the display would support such a low PWM.

This ATIF feature is not implemented on for example AMD grunt chromebooks.

Signed-off-by: Evan Benn 

---
I could not find a justification for the reason for the value. It has
caused some noticable regression for users: 
https://bugzilla.kernel.org/show_bug.cgi?id=203439>>>
Maybe this can be either user controlled or userspace configured, but
preventing users from turning their backlight dim seems wrong.


My understanding is that some panels flicker if you set the min to a
value too low.  This was a safe minimum if the platform didn't specify
it's own safe minimum.  I think we'd just be trading one bug for
another (flickering vs not dim enough).  Maybe a whitelist or
blacklist would be a better solution?



Yeah, this is a NACK from me as-is for the reasons Alex described.

I agree a whitelist approach might be best.

Is this fix perhaps for OLED panels? If so we could use a different 
min-value for OLED panels that don't do PWM, but use 12 for everything else.


Harry


Alex




Also reviewed here: 
https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/2748377>>>
  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 573cf17262da..0129bd69b94e 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -3151,7 +3151,7 @@ static int amdgpu_dm_mode_config_init(struct 
amdgpu_device *adev)
 return 0;
  }

-#define AMDGPU_DM_DEFAULT_MIN_BACKLIGHT 12
+#define AMDGPU_DM_DEFAULT_MIN_BACKLIGHT 0
  #define AMDGPU_DM_DEFAULT_MAX_BACKLIGHT 255
  #define AUX_BL_DEFAULT_TRANSITION_TIME_MS 50

--
2.31.0.291.g576ba9dcdaf-goog

___
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: [PATCH] drm/gma500: use NULL instead of using plain integer as pointer

[Patrik Jakobsson]

On Wed, Mar 17, 2021 at 9:27 AM Yang Li  wrote:
>
> This fixes the following sparse warnings:
> drivers/gpu/drm/gma500/psb_drv.c:303:56: warning: Using plain integer as
> NULL pointer
>
> Reported-by: Abaci Robot 
> Signed-off-by: Yang Li 

Applied to drm-misc-next

Thanks
Patrik

> ---
>  drivers/gpu/drm/gma500/psb_drv.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/gma500/psb_drv.c 
> b/drivers/gpu/drm/gma500/psb_drv.c
> index 0bcab06..c2aab62 100644
> --- a/drivers/gpu/drm/gma500/psb_drv.c
> +++ b/drivers/gpu/drm/gma500/psb_drv.c
> @@ -303,7 +303,7 @@ static int psb_driver_load(struct drm_device *dev, 
> unsigned long flags)
>
> ret = -ENOMEM;
>
> -   dev_priv->mmu = psb_mmu_driver_init(dev, 1, 0, 0);
> +   dev_priv->mmu = psb_mmu_driver_init(dev, 1, 0, NULL);
> if (!dev_priv->mmu)
> goto out_err;
>
> --
> 1.8.3.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/3] drm/connector: Add helper to compare HDR metadata

[kernel test robot]

Hi Maxime,

I love your patch! Yet something to improve:

[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on drm-tip/drm-tip linus/master v5.12-rc3 next-20210319]
[cannot apply to anholt/for-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Maxime-Ripard/drm-connector-Create-a-helper-to-attach-the-hdr_output_metadata-property/20210319-205157
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: sparc64-randconfig-r035-20210318 (attached as .config)
compiler: sparc64-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# 
https://github.com/0day-ci/linux/commit/e12a697958cd6235d678394450f4cb7dbf958ed5
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Maxime-Ripard/drm-connector-Create-a-helper-to-attach-the-hdr_output_metadata-property/20210319-205157
git checkout e12a697958cd6235d678394450f4cb7dbf958ed5
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
ARCH=sparc64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All errors (new ones prefixed by >>):

   drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c: In function 
'amdgpu_dm_commit_cursors':
   drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:7678:44: 
warning: variable 'new_plane_state' set but not used [-Wunused-but-set-variable]
7678 |  struct drm_plane_state *old_plane_state, *new_plane_state;
 |^~~
   drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c: In function 
'amdgpu_dm_atomic_commit_tail':
>> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:8327:4: error: 
>> implicit declaration of function 'is_hdr_metadata_different' 
>> [-Werror=implicit-function-declaration]
8327 |is_hdr_metadata_different(old_con_state, new_con_state);
 |^
   cc1: some warnings being treated as errors

Kconfig warnings: (for reference only)
   WARNING: unmet direct dependencies detected for FRAME_POINTER
   Depends on DEBUG_KERNEL && (M68K || UML || SUPERH) || 
ARCH_WANT_FRAME_POINTERS || MCOUNT
   Selected by
   - LATENCYTOP && DEBUG_KERNEL && STACKTRACE_SUPPORT && PROC_FS && !MIPS && 
!PPC && !S390 && !MICROBLAZE && !ARM && !ARC && !X86
   - LOCKDEP && DEBUG_KERNEL && LOCK_DEBUGGING_SUPPORT && !MIPS && !PPC && !ARM 
&& !S390 && !MICROBLAZE && !ARC && !X86


vim +/is_hdr_metadata_different +8327 
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c

e7b07ceef2a650 Harry Wentland  2017-08-10  8293  
02d6a6fcdf68c4 David Francis   2018-12-18  8294 /* Handle connector 
state changes */
c2cea7063b85fc Leo (Sunpeng  Li2017-10-12  8295)
for_each_oldnew_connector_in_state(state, connector, old_con_state, 
new_con_state, i) {
54d76575246798 Leo (Sunpeng  Li2017-10-12  8296)struct 
dm_connector_state *dm_new_con_state = to_dm_connector_state(new_con_state);
54d76575246798 Leo (Sunpeng  Li2017-10-12  8297)struct 
dm_connector_state *dm_old_con_state = to_dm_connector_state(old_con_state);
54d76575246798 Leo (Sunpeng  Li2017-10-12  8298)struct 
amdgpu_crtc *acrtc = to_amdgpu_crtc(dm_new_con_state->base.crtc);
efc8278eecfd5e Anson Jacob 2021-02-18  8299 struct 
dc_surface_update dummy_updates[MAX_SURFACES];
19afd79951e630 Nathan Chancellor   2019-02-01  8300 struct 
dc_stream_update stream_update;
b232d4ed92eafb Nicholas Kazlauskas 2019-05-28  8301 struct 
dc_info_packet hdr_packet;
e7b07ceef2a650 Harry Wentland  2017-08-10  8302 struct 
dc_stream_status *status = NULL;
b232d4ed92eafb Nicholas Kazlauskas 2019-05-28  8303 bool 
abm_changed, hdr_changed, scaling_changed;
e7b07ceef2a650 Harry Wentland  2017-08-10  8304  
efc8278eecfd5e Anson Jacob 2021-02-18  8305 
memset(_updates, 0, sizeof(dummy_updates));
19afd79951e630 Nathan Chancellor   2019-02-01  8306 
memset(_update, 0, sizeof(stream_update));
19afd79951e630 Nathan Chancellor   2019-02-01  8307  
44d09c6a577c8e Harry Wentland  2018-03-15  8308 if (acrtc) {
0bc9706db3a35b Leo (Sunpeng  Li2017-10-12  8309)
new_crtc_state = drm_atomic_get_new_crtc_state(state, >base);
44d09c6a577c8e Harry Wentland

Re: [PATCH] drm/atomic: Add the crtc to affected crtc only if uapi.enable = true

[Ville Syrjälä]

On Thu, Mar 18, 2021 at 04:01:26PM -0700, Navare, Manasi wrote:
> So basically we see this warning only in case of bigjoiner when
> drm_atomic_check gets called without setting the state->allow_modeset flag.

Considering the code is 'WARN(!state->allow_modeset, ...' that
fact should be rather obvious.

> 
> So do you think that in i915, in intel_atomic_check_bigjoiner() we should only
> steal the crtc when allow_modeset flag is set in state?

No. If you fully read drm_atomic_check_only() you will observe
that it will reject any commit w/ allow_modeset==false which 
needs a modeset. And it does that before the WARN.

So you're barking up the wrong tree here. The problem I think
is that you're just computing requested_crtcs wrong.

> If we add this check there then the affected crtc wont count the slave crtc
> and we wont get this warning.
> 
> Ville, Danvet?
> 
> Manasi
> 
> 
> On Tue, Mar 16, 2021 at 10:35:09PM +0100, Daniel Vetter wrote:
> > On Tue, Mar 9, 2021 at 10:14 AM Pekka Paalanen  wrote:
> > >
> > > On Mon, 8 Mar 2021 16:52:58 -0800
> > > "Navare, Manasi"  wrote:
> > >
> > > > On Thu, Mar 04, 2021 at 10:42:23AM +0200, Pekka Paalanen wrote:
> > > > > On Wed, 3 Mar 2021 12:44:33 -0800
> > > > > "Navare, Manasi"  wrote:
> > > > >
> > > > > > On Wed, Mar 03, 2021 at 10:47:44AM +0200, Pekka Paalanen wrote:
> > > > > > > On Tue,  2 Mar 2021 12:41:32 -0800
> > > > > > > Manasi Navare  wrote:
> > > > > > >
> > > > > > > > In case of a modeset where a mode gets split across mutiple 
> > > > > > > > CRTCs
> > > > > > > > in the driver specific implementation (bigjoiner in i915) we 
> > > > > > > > wrongly count
> > > > > > > > the affected CRTCs based on the drm_crtc_mask and indicate the 
> > > > > > > > stolen CRTC as
> > > > > > > > an affected CRTC in atomic_check_only().
> > > > > > > > This triggers a warning since affected CRTCs doent match 
> > > > > > > > requested CRTC.
> > > > > > > >
> > > > > > > > To fix this in such bigjoiner configurations, we should only
> > > > > > > > increment affected crtcs if that CRTC is enabled in UAPI not
> > > > > > > > if it is just used internally in the driver to split the mode.
> > > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > I think that makes sense to me. Stealing CRTCs that are not 
> > > > > > > currently
> > > > > > > used by the userspace (display server) should be ok, as long as 
> > > > > > > that
> > > > > > > is completely invisible to userspace: meaning that it does not 
> > > > > > > cause
> > > > > > > userspace to unexpectedly e.g. receive or miss per-crtc atomic
> > > > > > > completion events.
> > > > > >
> > > > > > Yes since we are only doing atomic_check_only() here, the stolen
> > > > >
> > > > > But the real not-test-only commit will follow if this test-only commit
> > > > > succeeds, and keeping the guarantees for the real commit are 
> > > > > important.
> > > >
> > > > Hmm well after the actual real commit, since the second crtc is stolen
> > > > even though it is not being used for the display output, it is
> > > > used for joiner so the uapi.enable will be true after the real commit.
> > > >
> > > > so actually the assertion would fail in this case.
> > > >
> > > > @Ville @Danvet any suggestions here in that case?
> > 
> > That is very bad. We can't frob uapi state like that. I think that
> > calls for even more checks to make sure kms drivers who try to play
> > clever games don't get it wrong, so we probably need to check uapi
> > enable and active state in another mask before/after ->atomic_check
> > too. Or something like that.
> > 
> > > Hi,
> > >
> > > that is not what I was talking about, but sounds like you found a
> > > different problem. It seems like the problem you are talking about
> > > would be guaranteed to be hit if bigjoiner was used. Have you not
> > > tested this?
> > >
> > > However, I was talking about the real commit itself, not what happens
> > > on commits after it, see below.
> > >
> > > > > > crtc is completely invisible to the userspace and hence that is
> > > > > > indicated by uapi.enable which is not true for this stolen
> > > > > > crtc. However if allow modeset flag set, then it will do a full
> > > > > > modeset and indicate the uapi.enable for this stolen crtc as well
> > > > > > since that cannot be used for other modeset requested by userspace.
> > > > > >
> > > > > > >
> > > > > > > Can that also be asserted somehow, or does this already do that?
> > > > > >
> > > > > > Not clear what you want the assertion for? Could you elaborate
> > > > >
> > > > > As assertion that when the real atomic commit happens and then
> > > > > completion events are fired, they match exactly the affected crtcs 
> > > > > mask.
> > >
> > > This is my concern and a question, although like I say below, only
> > > tangential to this patch.
> > >
> > > However, as this patch aims to allow bigjoiner usage, naturally the
> > > question will arise whether the completion events then match what
> > > userspace expects 

Re: [PATCH 13/30] drm/bridge/analogix/dp_core: Unregister DP AUX channel on error in analogix_dp_probe()

[Robert Foss]

Hey Lyude,

Thanks for the patch, it looks good to me.

Reviewed-by: Robert Foss 

On Fri, 19 Feb 2021 at 22:58, Lyude Paul  wrote:
>
> Just another drive-by fix I noticed while going through the tree to cleanup
> DP aux adapter registration - make sure we unregister the DP AUX dev if
> analogix_dp_probe() fails.
>
> Signed-off-by: Lyude Paul 
> ---
>  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> index aa1bb86293fd..f115233b1cb9 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> @@ -1782,6 +1782,7 @@ int analogix_dp_bind(struct analogix_dp_device *dp, 
> struct drm_device *drm_dev)
>
>  err_disable_pm_runtime:
> pm_runtime_disable(dp->dev);
> +   drm_dp_aux_unregister(>aux);
>
> return ret;
>  }
> --
> 2.29.2
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] gpu/drm/msm: fix shutdown hook in case GPU components failed to bind

[Rob Clark]

On Fri, Mar 19, 2021 at 5:09 AM Fabio Estevam  wrote:
>
> Hi Dmitry,
>
> On Mon, Mar 1, 2021 at 6:41 PM Dmitry Baryshkov
>  wrote:
>
> > diff --git a/drivers/gpu/drm/msm/msm_atomic.c 
> > b/drivers/gpu/drm/msm/msm_atomic.c
> > index 6a326761dc4a..2fd0cf6421ad 100644
> > --- a/drivers/gpu/drm/msm/msm_atomic.c
> > +++ b/drivers/gpu/drm/msm/msm_atomic.c
> > @@ -207,7 +207,12 @@ void msm_atomic_commit_tail(struct drm_atomic_state 
> > *state)
> > struct msm_kms *kms = priv->kms;
> > struct drm_crtc *async_crtc = NULL;
> > unsigned crtc_mask = get_crtc_mask(state);
> > -   bool async = kms->funcs->vsync_time &&
> > +   bool async;
> > +
> > +   if (!kms)
> > +   return;
> > +
> > +   async = kms->funcs->vsync_time &&
> > can_do_async(state, _crtc);
>
> I also see the same issue on a i.MX53:
> https://lists.freedesktop.org/archives/freedreno/2021-January/009369.html
>
> Then I got a different suggestion from Rob. Please check:
>
> https://www.spinics.net/lists/dri-devel/msg286648.html
> and
> https://www.spinics.net/lists/dri-devel/msg286649.html
>
> Does this series fix the issue in your platform too?

I think that might not help if something fails to probe due to (for
example) a missing dependency, so !priv->kms is probably a better
check to cover both cases.  But the 2nd patch makes a good point, that
the suspend/resume path probably needs the same treatment

BR,
-R
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 12/30] drm/bridge/analogix/anx6345: Cleanup on errors in anx6345_bridge_attach()

[Robert Foss]

Hey Lyude,

Thanks for the patch, it looks good to me.

Reviewed-by: Robert Foss 

On Fri, 19 Feb 2021 at 22:58, Lyude Paul  wrote:
>
> Another drive-by fix I found when fixing DP AUX adapter across the kernel
> tree - make sure we don't leak resources (and by proxy-AUX adapters) on
> failures in anx6345_bridge_attach() by unrolling on errors.
>
> Signed-off-by: Lyude Paul 
> ---
>  drivers/gpu/drm/bridge/analogix/analogix-anx6345.c | 11 ---
>  1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c 
> b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> index 6258f16da0e8..aa6cda458eb9 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> @@ -550,7 +550,7 @@ static int anx6345_bridge_attach(struct drm_bridge 
> *bridge,
>  DRM_MODE_CONNECTOR_eDP);
> if (err) {
> DRM_ERROR("Failed to initialize connector: %d\n", err);
> -   return err;
> +   goto aux_unregister;
> }
>
> drm_connector_helper_add(>connector,
> @@ -562,16 +562,21 @@ static int anx6345_bridge_attach(struct drm_bridge 
> *bridge,
>bridge->encoder);
> if (err) {
> DRM_ERROR("Failed to link up connector to encoder: %d\n", 
> err);
> -   return err;
> +   goto connector_cleanup;
> }
>
> err = drm_connector_register(>connector);
> if (err) {
> DRM_ERROR("Failed to register connector: %d\n", err);
> -   return err;
> +   goto connector_cleanup;
> }
>
> return 0;
> +connector_cleanup:
> +   drm_connector_cleanup(>connector);
> +aux_unregister:
> +   drm_dp_aux_unregister(>aux);
> +   return err;
>  }
>
>  static void anx6345_bridge_detach(struct drm_bridge *bridge)
> --
> 2.29.2
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 11/30] drm/bridge/analogix/anx6345: Don't link encoder until after connector registration

[Robert Foss]

Hey Lyude,

Thanks for the patch, it looks good to me.

Reviewed-by: Robert Foss 

On Fri, 19 Feb 2021 at 22:58, Lyude Paul  wrote:
>
> Another case of linking an encoder to a connector after the connector's
> been registered. The proper place to do this is before connector
> registration, so let's fix that.
>
> Signed-off-by: Lyude Paul 
> ---
>  drivers/gpu/drm/bridge/analogix/analogix-anx6345.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c 
> b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> index 8e016ba7c54a..6258f16da0e8 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> @@ -556,12 +556,6 @@ static int anx6345_bridge_attach(struct drm_bridge 
> *bridge,
> drm_connector_helper_add(>connector,
>  _connector_helper_funcs);
>
> -   err = drm_connector_register(>connector);
> -   if (err) {
> -   DRM_ERROR("Failed to register connector: %d\n", err);
> -   return err;
> -   }
> -
> anx6345->connector.polled = DRM_CONNECTOR_POLL_HPD;
>
> err = drm_connector_attach_encoder(>connector,
> @@ -571,6 +565,12 @@ static int anx6345_bridge_attach(struct drm_bridge 
> *bridge,
> return err;
> }
>
> +   err = drm_connector_register(>connector);
> +   if (err) {
> +   DRM_ERROR("Failed to register connector: %d\n", err);
> +   return err;
> +   }
> +
> return 0;
>  }
>
> --
> 2.29.2
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 10/30] drm/bridge/analogix/anx6345: Add missing drm_dp_aux_unregister() call

[Robert Foss]

Hey Lyude,

Thanks for the patch, it looks good to me.

Reviewed-by: Robert Foss 

On Fri, 19 Feb 2021 at 22:58, Lyude Paul  wrote:
>
> Another driver I found that seems to forget to unregister it's DP AUX
> device. Let's fix this by adding anx6345_bridge_detach().
>
> Signed-off-by: Lyude Paul 
> ---
>  drivers/gpu/drm/bridge/analogix/analogix-anx6345.c | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c 
> b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> index d9164fab044d..8e016ba7c54a 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> @@ -574,6 +574,11 @@ static int anx6345_bridge_attach(struct drm_bridge 
> *bridge,
> return 0;
>  }
>
> +static void anx6345_bridge_detach(struct drm_bridge *bridge)
> +{
> +   drm_dp_aux_unregister(_to_anx6345(bridge)->aux);
> +}
> +
>  static enum drm_mode_status
>  anx6345_bridge_mode_valid(struct drm_bridge *bridge,
>   const struct drm_display_info *info,
> @@ -624,6 +629,7 @@ static void anx6345_bridge_enable(struct drm_bridge 
> *bridge)
>
>  static const struct drm_bridge_funcs anx6345_bridge_funcs = {
> .attach = anx6345_bridge_attach,
> +   .detach = anx6345_bridge_detach,
> .mode_valid = anx6345_bridge_mode_valid,
> .disable = anx6345_bridge_disable,
> .enable = anx6345_bridge_enable,
> --
> 2.29.2
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 09/30] drm/bridge/analogix/anx78xx: Cleanup on error in anx78xx_bridge_attach()

[Robert Foss]

Hey Lyude,

Thanks for the patch, it looks good to me.

Reviewed-by: Robert Foss 

On Fri, 19 Feb 2021 at 22:56, Lyude Paul  wrote:
>
> Just another issue I noticed while correcting usages of
> drm_dp_aux_init()/drm_dp_aux_register() around the tree. If any of the
> steps in anx78xx_bridge_attach() fail, we end up leaking resources. So,
> let's fix that (and fix leaking a DP AUX adapter in the process) by
> unrolling on errors.
>
> Signed-off-by: Lyude Paul 
> ---
>  drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c | 11 ---
>  1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c 
> b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
> index 338dd8531d4b..f20558618220 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
> @@ -918,7 +918,7 @@ static int anx78xx_bridge_attach(struct drm_bridge 
> *bridge,
>  DRM_MODE_CONNECTOR_DisplayPort);
> if (err) {
> DRM_ERROR("Failed to initialize connector: %d\n", err);
> -   return err;
> +   goto aux_unregister;
> }
>
> drm_connector_helper_add(>connector,
> @@ -930,16 +930,21 @@ static int anx78xx_bridge_attach(struct drm_bridge 
> *bridge,
>bridge->encoder);
> if (err) {
> DRM_ERROR("Failed to link up connector to encoder: %d\n", 
> err);
> -   return err;
> +   goto connector_cleanup;
> }
>
> err = drm_connector_register(>connector);
> if (err) {
> DRM_ERROR("Failed to register connector: %d\n", err);
> -   return err;
> +   goto connector_cleanup;
> }
>
> return 0;
> +connector_cleanup:
> +   drm_connector_cleanup(>connector);
> +aux_unregister:
> +   drm_dp_aux_unregister(>aux);
> +   return err;
>  }
>
>  static void anx78xx_bridge_detach(struct drm_bridge *bridge)
> --
> 2.29.2
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 08/30] drm/bridge/analogix/anx78xx: Setup encoder before registering connector

[Robert Foss]

Hey Lyude,

Thanks for the patch, it looks good to me.

Reviewed-by: Robert Foss 

On Fri, 19 Feb 2021 at 22:56, Lyude Paul  wrote:
>
> Since encoder mappings for connectors are exposed to userspace, we should
> be attaching the encoder before exposing the connector to userspace. Just a
> drive-by fix for an issue I noticed while fixing up usages of
> drm_dp_aux_init()/drm_dp_aux_register() across the tree.
>
> Signed-off-by: Lyude Paul 
> ---
>  drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c 
> b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
> index ec4607dc01eb..338dd8531d4b 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
> @@ -924,12 +924,6 @@ static int anx78xx_bridge_attach(struct drm_bridge 
> *bridge,
> drm_connector_helper_add(>connector,
>  _connector_helper_funcs);
>
> -   err = drm_connector_register(>connector);
> -   if (err) {
> -   DRM_ERROR("Failed to register connector: %d\n", err);
> -   return err;
> -   }
> -
> anx78xx->connector.polled = DRM_CONNECTOR_POLL_HPD;
>
> err = drm_connector_attach_encoder(>connector,
> @@ -939,6 +933,12 @@ static int anx78xx_bridge_attach(struct drm_bridge 
> *bridge,
> return err;
> }
>
> +   err = drm_connector_register(>connector);
> +   if (err) {
> +   DRM_ERROR("Failed to register connector: %d\n", err);
> +   return err;
> +   }
> +
> return 0;
>  }
>
> --
> 2.29.2
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 07/30] drm/bridge/analogix/anx78xx: Add missing drm_dp_aux_unregister() call

[Robert Foss]

Hey Lyude,

Thanks for the patch, it looks good to me.

Reviewed-by: Robert Foss 

On Fri, 19 Feb 2021 at 22:56, Lyude Paul  wrote:
>
> Surprisingly, this bridge actually registers it's AUX adapter at the
> correct time already. Nice job! However, it does forget to actually
> unregister the AUX adapter, so let's add a bridge function to handle that.
>
> Signed-off-by: Lyude Paul 
> ---
>  drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c 
> b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
> index 81debd02c169..ec4607dc01eb 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
> @@ -942,6 +942,11 @@ static int anx78xx_bridge_attach(struct drm_bridge 
> *bridge,
> return 0;
>  }
>
> +static void anx78xx_bridge_detach(struct drm_bridge *bridge)
> +{
> +   drm_dp_aux_unregister(_to_anx78xx(bridge)->aux);
> +}
> +
>  static enum drm_mode_status
>  anx78xx_bridge_mode_valid(struct drm_bridge *bridge,
>   const struct drm_display_info *info,
> @@ -1013,6 +1018,7 @@ static void anx78xx_bridge_enable(struct drm_bridge 
> *bridge)
>
>  static const struct drm_bridge_funcs anx78xx_bridge_funcs = {
> .attach = anx78xx_bridge_attach,
> +   .detach = anx78xx_bridge_detach,
> .mode_valid = anx78xx_bridge_mode_valid,
> .disable = anx78xx_bridge_disable,
> .mode_set = anx78xx_bridge_mode_set,
> --
> 2.29.2
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 04/30] drm/bridge/tc358767: Don't register DP AUX channel until bridge is attached

[Robert Foss]

Hey Lyude,

This patch looks good to me.

Reviewed-by: Robert Foss 

On Fri, 19 Feb 2021 at 22:56, Lyude Paul  wrote:
>
> Since this is a bridge, we don't start out with a respective DRM device.
> Likewise this means we don't have a connector, which also means that we
> should be following drm_dp_aux_register()'s documentation advice and not
> call drm_dp_aux_register() until we have a matching connector. Instead,
> call drm_dp_aux_init() in tc_probe() and wait until tc_bridge_attach() to
> register our AUX channel. We also add tc_bridge_detach() to handle
> unregistering the AUX adapter once the bridge has been disconnected.
>
> Signed-off-by: Lyude Paul 
> ---
>  drivers/gpu/drm/bridge/tc358767.c | 20 +++-
>  1 file changed, 15 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/tc358767.c 
> b/drivers/gpu/drm/bridge/tc358767.c
> index 34a3e4e9f717..da89922721ed 100644
> --- a/drivers/gpu/drm/bridge/tc358767.c
> +++ b/drivers/gpu/drm/bridge/tc358767.c
> @@ -1414,11 +1414,15 @@ static int tc_bridge_attach(struct drm_bridge *bridge,
> if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)
> return 0;
>
> +   ret = drm_dp_aux_register(>aux);
> +   if (ret < 0)
> +   return ret;
> +
> /* Create DP/eDP connector */
> drm_connector_helper_add(>connector, _connector_helper_funcs);
> ret = drm_connector_init(drm, >connector, _connector_funcs, 
> tc->bridge.type);
> if (ret)
> -   return ret;
> +   goto aux_unregister;
>
> /* Don't poll if don't have HPD connected */
> if (tc->hpd_pin >= 0) {
> @@ -1438,10 +1442,19 @@ static int tc_bridge_attach(struct drm_bridge *bridge,
> drm_connector_attach_encoder(>connector, tc->bridge.encoder);
>
> return 0;
> +aux_unregister:
> +   drm_dp_aux_unregister(>aux);
> +   return ret;
> +}
> +
> +static void tc_bridge_detach(struct drm_bridge *bridge)
> +{
> +   drm_dp_aux_unregister(_to_tc(bridge)->aux);
>  }
>
>  static const struct drm_bridge_funcs tc_bridge_funcs = {
> .attach = tc_bridge_attach,
> +   .detach = tc_bridge_detach,
> .mode_valid = tc_mode_valid,
> .mode_set = tc_bridge_mode_set,
> .enable = tc_bridge_enable,
> @@ -1680,9 +1693,7 @@ static int tc_probe(struct i2c_client *client, const 
> struct i2c_device_id *id)
> tc->aux.name = "TC358767 AUX i2c adapter";
> tc->aux.dev = tc->dev;
> tc->aux.transfer = tc_aux_transfer;
> -   ret = drm_dp_aux_register(>aux);
> -   if (ret)
> -   return ret;
> +   drm_dp_aux_init(>aux);
>
> tc->bridge.funcs = _bridge_funcs;
> if (tc->hpd_pin >= 0)
> @@ -1702,7 +1713,6 @@ static int tc_remove(struct i2c_client *client)
> struct tc_data *tc = i2c_get_clientdata(client);
>
> drm_bridge_remove(>bridge);
> -   drm_dp_aux_unregister(>aux);
>
> return 0;
>  }
> --
> 2.29.2
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/amd/display: Set AMDGPU_DM_DEFAULT_MIN_BACKLIGHT to 0

[Alex Deucher]

On Fri, Mar 19, 2021 at 3:23 AM Evan Benn  wrote:
>
> AMDGPU_DM_DEFAULT_MIN_BACKLIGHT was set to the value of 12
> to ensure no display backlight will flicker at low user brightness
> settings. However this value is quite bright, so for devices that do not
> implement the ACPI ATIF
> ATIF_FUNCTION_QUERY_BRIGHTNESS_TRANSFER_CHARACTERISTICS
> functionality the user cannot set the brightness to a low level even if
> the display would support such a low PWM.
>
> This ATIF feature is not implemented on for example AMD grunt chromebooks.
>
> Signed-off-by: Evan Benn 
>
> ---
> I could not find a justification for the reason for the value. It has
> caused some noticable regression for users: 
> https://bugzilla.kernel.org/show_bug.cgi?id=203439
>
> Maybe this can be either user controlled or userspace configured, but
> preventing users from turning their backlight dim seems wrong.

My understanding is that some panels flicker if you set the min to a
value too low.  This was a safe minimum if the platform didn't specify
it's own safe minimum.  I think we'd just be trading one bug for
another (flickering vs not dim enough).  Maybe a whitelist or
blacklist would be a better solution?

Alex


>
> Also reviewed here: 
> https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/2748377
>
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 573cf17262da..0129bd69b94e 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -3151,7 +3151,7 @@ static int amdgpu_dm_mode_config_init(struct 
> amdgpu_device *adev)
> return 0;
>  }
>
> -#define AMDGPU_DM_DEFAULT_MIN_BACKLIGHT 12
> +#define AMDGPU_DM_DEFAULT_MIN_BACKLIGHT 0
>  #define AMDGPU_DM_DEFAULT_MAX_BACKLIGHT 255
>  #define AUX_BL_DEFAULT_TRANSITION_TIME_MS 50
>
> --
> 2.31.0.291.g576ba9dcdaf-goog
>
> ___
> 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

[PATCH] drm/ttm: stop warning on TT shrinker failure

[Christian König]

Don't print a warning when we fail to allocate a page for swapping things out.

Also rely on memalloc_nofs_save/memalloc_nofs_restore instead of GFP_NOFS.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/ttm/ttm_tt.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index 2f0833c98d2c..86fa3e82dacc 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -369,7 +369,7 @@ static unsigned long ttm_tt_shrinker_scan(struct shrinker 
*shrink,
};
int ret;
 
-   ret = ttm_bo_swapout(, GFP_NOFS);
+   ret = ttm_bo_swapout(, GFP_KERNEL | __GFP_NOWARN);
return ret < 0 ? SHRINK_EMPTY : ret;
 }
 
@@ -389,10 +389,13 @@ static unsigned long ttm_tt_shrinker_count(struct 
shrinker *shrink,
 static int ttm_tt_debugfs_shrink_show(struct seq_file *m, void *data)
 {
struct shrink_control sc = { .gfp_mask = GFP_KERNEL };
+   unsigned int flags;
 
fs_reclaim_acquire(GFP_KERNEL);
+   flags = memalloc_nofs_save();
seq_printf(m, "%lu/%lu\n", ttm_tt_shrinker_count(_shrinker, ),
   ttm_tt_shrinker_scan(_shrinker, ));
+   memalloc_nofs_restore(flags);
fs_reclaim_release(GFP_KERNEL);
 
return 0;
-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 04/19] include: drm: drm_atomic: Make use of 'new_plane_state'

[Ville Syrjälä]

On Fri, Mar 19, 2021 at 08:24:13AM +, Lee Jones wrote:
> In the macro for_each_oldnew_plane_in_state() 'new_plane_state' is provided
> as a container for state->planes[i].new_state, but is not utilised in
> some use-cases, so we fake-use it instead.
> 
> Fixes the following W=1 kernel build warning(s):
> 
>  drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c: In function 
> ‘amdgpu_dm_commit_cursors’:
>  drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:7649:44: 
> warning: variable ‘new_plane_state’ set but not used 
> [-Wunused-but-set-variable]
> 
> Cc: Maarten Lankhorst 
> Cc: Maxime Ripard 
> Cc: Thomas Zimmermann 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Rob Clark 
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Lee Jones 
> ---
>  include/drm/drm_atomic.h | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
> index ac5a28eff2c86..259e6970dc836 100644
> --- a/include/drm/drm_atomic.h
> +++ b/include/drm/drm_atomic.h
> @@ -871,7 +871,8 @@ void drm_state_dump(struct drm_device *dev, struct 
> drm_printer *p);
>((plane) = (__state)->planes[__i].ptr, \
> (void)(plane) /* Only to avoid 
> unused-but-set-variable warning */, \
> (old_plane_state) = 
> (__state)->planes[__i].old_state,\
> -   (new_plane_state) = 
> (__state)->planes[__i].new_state, 1))
> +   (new_plane_state) = 
> (__state)->planes[__i].new_state, \
> +   (void)(new_plane_state) /* Only to avoid 
> unused-but-set-variable warning */, 1))

In this case you can just switch the code to use
for_each_old_plane_in_state() instead.

>  
>  /**
>   * for_each_oldnew_plane_in_state_reverse - iterate over all planes in an 
> atomic
> -- 
> 2.27.0
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 212361] New: WARNING: CPU: 0 PID: 411 at drivers/gpu/drm/amd/amdgpu/../display/dc/clk_mgr/dcn21/rn_clk_mgr.c:833 rn_clk_mgr_construct+0x2dd/0x440 [amdgpu]

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=212361

Bug ID: 212361
   Summary: WARNING: CPU: 0 PID: 411 at
drivers/gpu/drm/amd/amdgpu/../display/dc/clk_mgr/dcn21
/rn_clk_mgr.c:833 rn_clk_mgr_construct+0x2dd/0x440
[amdgpu]
   Product: Drivers
   Version: 2.5
Kernel Version: 5.12.0-rc3-00070-g8b12a62a4e3e
  Hardware: x86-64
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-...@kernel-bugs.osdl.org
  Reporter: gdam...@gmail.com
Regression: No

I'm getting the following on a AMD Ryzen 5 PRO 4650G with Radeon Graphics

[   10.537847] amdgpu :30:00.0: amdgpu: RAS: optional ras ta ucode is not
available
[   10.545573] amdgpu :30:00.0: amdgpu: RAP: optional rap ta ucode is not
available
[   10.545575] amdgpu :30:00.0: amdgpu: SECUREDISPLAY: securedisplay ta
ucode is not available
[   10.545794] amdgpu :30:00.0: amdgpu: SMU is initialized successfully!
[   10.547115] [drm] kiq ring mec 2 pipe 1 q 0
[   10.547613] [ cut here ]
[   10.547613] WARNING: CPU: 0 PID: 411 at
drivers/gpu/drm/amd/amdgpu/../display/dc/clk_mgr/dcn21/rn_clk_mgr.c:833
rn_clk_mgr_construct+0x2dd/0x440 [amdgpu]
[   10.547778] Modules linked in: iptable_mangle(+) iptable_nat nf_nat
nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 iptable_filter bpfilter ccm
algif_aead des_generic libdes ecb algif_skcipher cmac md4 algif_hash af_alg
amdgpu(+) iwlmvm btrfs mac80211 raid1 dm_raid raid456 async_raid6_recov
async_memcpy async_pq async_xor async_tx md_mod blake2b_generic xor libarc4
iwlwifi drm_ttm_helper ttm gpu_sched i2c_algo_bit drm_kms_helper syscopyarea
sysfillrect sysimgblt intel_rapl_msr intel_rapl_common fb_sys_fops cec kvm_amd
cfg80211 kvm snd_hda_codec_realtek dm_thin_pool snd_hda_codec_generic
snd_hda_codec_hdmi dm_persistent_data ledtrig_audio snd_hda_intel dm_bio_prison
snd_intel_dspcfg dm_bufio snd_hda_codec libcrc32c raid6_pq r8169 bridge
snd_hwdep snd_hda_core wmi_bmof realtek mdio_devres snd_pcm hid_logitech_hidpp
of_mdio fixed_phy libphy snd_timer drm irqbypass mousedev snd joydev rapl
sp5100_tco rfkill k10temp pcspkr i2c_piix4 soundcore wmi pinctrl_amd tpm_tis
stp gpio_amdpt tpm_tis_core
[   10.547820]  acpi_cpufreq llc mac_hid fuse pkcs8_key_parser crypto_user
agpgart ip_tables x_tables ext4 crc32c_generic crc16 mbcache jbd2 dm_crypt cbc
hid_logitech_dj encrypted_keys trusted hid_generic usbhid uas usb_storage
dm_mod crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel
aesni_intel xhci_pci ccp xhci_pci_renesas crypto_simd cryptd xhci_hcd tpm_crb
tpm rng_core hid_lenovo hid vfat fat
[   10.547840] CPU: 0 PID: 411 Comm: systemd-udevd Not tainted
5.12.0-rc3-00070-g8b12a62a4e3e #22
[   10.547842] Hardware name: Micro-Star International Co., Ltd. MS-7C94/MAG
B550M MORTAR WIFI (MS-7C94), BIOS 1.20 08/03/2020
[   10.547843] RIP: 0010:rn_clk_mgr_construct+0x2dd/0x440 [amdgpu]
[   10.547992] Code: ff ff b8 03 00 00 00 41 8b 8c c5 80 00 00 00 41 89 c1 89
c7 85 c9 74 0c 41 8b 94 c5 84 00 00 00 85 d2 75 75 48 83 e8 01 73 dd <0f> 0b e9
31 fe ff ff 48 c7 c6 00 5f 56 c1 b9 14 00 00 00 48 89 c7
[   10.547993] RSP: 0018:a0c281663650 EFLAGS: 00010297
[   10.547995] RAX:  RBX: 91210c244840 RCX:
0640
[   10.547996] RDX:  RSI: a0c281663678 RDI:

[   10.547997] RBP: 91210a12ca00 R08:  R09:

[   10.547997] R10: 7fc9117f R11: 91210c250800 R12:
912109495540
[   10.547998] R13: a0c281663678 R14: 91210415 R15:
fff0
[   10.547999] FS:  7ff7a5594a40() GS:9127ef20()
knlGS:
[   10.548000] CS:  0010 DS:  ES:  CR0: 80050033
[   10.548001] CR2: 00c000b87c80 CR3: 0001023ce000 CR4:
00350ef0
[   10.548002] Call Trace:
[   10.548006]  dc_clk_mgr_create+0x178/0x260 [amdgpu]
[   10.548154]  dc_create+0x256/0x7c0 [amdgpu]
[   10.548342]  ? amdgpu_cgs_create_device+0x23/0x50 [amdgpu]
[   10.548543]  ? kmem_cache_alloc_trace+0x169/0x2d0
[   10.548547]  amdgpu_dm_init.isra.0+0x1bd/0x250 [amdgpu]
[   10.548766]  ? wake_up_klogd.part.0+0x4f/0x70
[   10.548769]  ? vprintk_emit+0xf4/0x1a0
[   10.548774]  dm_hw_init+0xe/0x20 [amdgpu]
[   10.549001]  amdgpu_device_init.cold+0x1758/0x1b21 [amdgpu]
[   10.549214]  amdgpu_driver_load_kms+0x64/0x260 [amdgpu]
[   10.549330]  amdgpu_pci_probe+0x11f/0x1b0 [amdgpu]
[   10.549442]  local_pci_probe+0x42/0x80
[   10.549445]  ? pci_match_device+0xd7/0x100
[   10.549447]  pci_device_probe+0xfa/0x1b0
[   10.549449]  really_probe+0xf2/0x440
[   10.549453]  driver_probe_device+0xe1/0x150
[   10.549455]  device_driver_attach+0xa1/0xb0
[   10.549456]  __driver_attach+0x8a/0x150
[   10.549458]  ? 

[PATCH] drm/tegra: sor: Grab runtime PM reference across reset

[Thierry Reding]

From: Thierry Reding 

The SOR resets are exclusively shared with the SOR power domain. This
means that exclusive access can only be granted temporarily and in order
for that to work, a rigorous sequence must be observed. To ensure that a
single consumer gets exclusive access to a reset, each consumer must
implement a rigorous protocol using the reset_control_acquire() and
reset_control_release() functions.

However, these functions alone don't provide any guarantees at the
system level. Drivers need to ensure that the only a single consumer has
access to the reset at the same time. In order for the SOR to be able to
exclusively access its reset, it must therefore ensure that the SOR
power domain is not powered off by holding on to a runtime PM reference
to that power domain across the reset assert/deassert operation.

This used to work fine by accident, but was revealed when recently more
devices started to rely on the SOR power domain.

Fixes: 11c632e1cfd3 ("drm/tegra: sor: Implement acquire/release for reset")
Reported-by: Jonathan Hunter 
Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/tegra/sor.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/tegra/sor.c b/drivers/gpu/drm/tegra/sor.c
index f02a035dda45..7b88261f57bb 100644
--- a/drivers/gpu/drm/tegra/sor.c
+++ b/drivers/gpu/drm/tegra/sor.c
@@ -3115,6 +3115,12 @@ static int tegra_sor_init(struct host1x_client *client)
 * kernel is possible.
 */
if (sor->rst) {
+   err = pm_runtime_resume_and_get(sor->dev);
+   if (err < 0) {
+   dev_err(sor->dev, "failed to get runtime PM: %d\n", 
err);
+   return err;
+   }
+
err = reset_control_acquire(sor->rst);
if (err < 0) {
dev_err(sor->dev, "failed to acquire SOR reset: %d\n",
@@ -3148,6 +3154,7 @@ static int tegra_sor_init(struct host1x_client *client)
}
 
reset_control_release(sor->rst);
+   pm_runtime_put(sor->dev);
}
 
err = clk_prepare_enable(sor->clk_safe);
-- 
2.30.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/tilcdc: fix LCD pixel clock setting

[Jyri Sarha]

On 2021-03-18 23:47, Dario Binacchi wrote:

Il 17/03/2021 09:19 Tomi Valkeinen  ha scritto:


On 14/03/2021 17:13, Dario Binacchi wrote:
> As reported by TI spruh73x RM, the LCD pixel clock (LCD_PCLK) frequency
> is obtained by dividing LCD_CLK, the LCD controller reference clock,
> for CLKDIV:
>
> LCD_PCLK = LCD_CLK / CLKDIV
>
> where CLKDIV must be greater than 1.
>
> Therefore LCD_CLK must be set to 'req_rate * CLKDIV' instead of req_rate

The above doesn't make sense, the code already sets LCD_CLK to 
'req_rate

* clkdiv', not req_rate.

> and the real LCD_CLK rate must be compared with 'req_rate * CLKDIV' and
> not with req_rate.

This is true, the code looks at the wrong value.

> Passing req_rate instead of 'req_rate * CLKDIV' to the tilcdc_pclk_diff
> routine caused it to fail even if LCD_CLK was properly set.
>
> Signed-off-by: Dario Binacchi 
>
> ---
>
>   drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 9 +
>   1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c 
b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> index 30213708fc99..02f56c9a5da5 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> @@ -203,7 +203,7 @@ static void tilcdc_crtc_set_clk(struct drm_crtc *crtc)
>struct drm_device *dev = crtc->dev;
>struct tilcdc_drm_private *priv = dev->dev_private;
>struct tilcdc_crtc *tilcdc_crtc = to_tilcdc_crtc(crtc);
> -  unsigned long clk_rate, real_rate, req_rate;
> +  unsigned long clk_rate, real_rate, req_rate, clk_div_rate;
>unsigned int clkdiv;
>int ret;
>
> @@ -211,10 +211,11 @@ static void tilcdc_crtc_set_clk(struct drm_crtc *crtc)
>
>/* mode.clock is in KHz, set_rate wants parameter in Hz */
>req_rate = crtc->mode.clock * 1000;
> -
> -  ret = clk_set_rate(priv->clk, req_rate * clkdiv);
> +  /* LCD clock divisor input rate */
> +  clk_div_rate = req_rate * clkdiv;

"clk_div_rate" sounds a bit odd to me. Why not lcd_fck_rate, as that's
the name used later? Or lcd_clk_rate. Or maybe lcd_clk_req_rate...


I prefer lcd_clk_rate.

How about adding an additional patch that changes the variable names to 
make

the code more readable?

req_rate -> lcd_pclk_rate
clk_rate -> real_lcd_clk_rate

And add a comment to the function which highlights the relationship
LCD_CLK = LCD_PCLK * CLDIV ?



What about renaming current req_rate to pclk_rate (for pixel clock 
rate), and calling pclk_rate * clkdiv = req_rate, as that is the rate we 
need to request from the input clock? Adding lcd to local variable names 
here is quite redundant after all. In any case req_rate is bit 
misleading name here and probably part of the reason why the bug exists 
in the first place.


Best regards,
Jyri





> +  ret = clk_set_rate(priv->clk, clk_div_rate);
>clk_rate = clk_get_rate(priv->clk);
> -  if (ret < 0 || tilcdc_pclk_diff(req_rate, clk_rate) > 5) {
> +  if (ret < 0 || tilcdc_pclk_diff(clk_div_rate, clk_rate) > 5) {
>/*
> * If we fail to set the clock rate (some architectures don't
> * use the common clock framework yet and may not implement
>

I think this fix is fine, but looking at the current code, it's 
calling

tilcdc_pclk_diff(), but doesn't actually provide pixel clocks to the
function, but fclk.


Yes, I agree.

Thanks and regards,
Dario



  Tomi

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[v1] drm/msm/disp/dpu1: fix display underruns during modeset.

[Kalyan Thota]

During crtc disable, display perf structures are reset to 0
which includes state varibles which are immutable. On crtc
enable, we use the same structures and they don't refelect
the actual values

1) Fix is to avoid updating the state structures during disable.
2) Reset the perf structures during atomic check when there is no
modeset enable.

Signed-off-by: Kalyan Thota 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 1 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c  | 1 +
 2 files changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
index 37c8270..b4cd479 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
@@ -382,7 +382,6 @@ int dpu_core_perf_crtc_update(struct drm_crtc *crtc,
} else {
DPU_DEBUG("crtc=%d disable\n", crtc->base.id);
memset(old, 0, sizeof(*old));
-   memset(new, 0, sizeof(*new));
update_bus = true;
update_clk = true;
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 9a80981..a821e2c 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -912,6 +912,7 @@ static int dpu_crtc_atomic_check(struct drm_crtc *crtc,
if (!state->enable || !state->active) {
DPU_DEBUG("crtc%d -> enable %d, active %d, skip atomic_check\n",
crtc->base.id, state->enable, state->active);
+   memset(>new_perf, 0, sizeof(cstate->new_perf));
goto end;
}
 
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/3] drm/connector: Create a helper to attach the hdr_output_metadata property

[Maxime Ripard]

All the drivers that implement HDR output call pretty much the same
function to initialise the hdr_output_metadata property, and while the
creation of that property is in a helper, every driver uses the same
code to attach it.

Provide a helper for it as well

Signed-off-by: Maxime Ripard 
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  4 +---
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c |  3 +--
 drivers/gpu/drm/drm_connector.c   | 21 +++
 drivers/gpu/drm/i915/display/intel_hdmi.c |  3 +--
 include/drm/drm_connector.h   |  1 +
 5 files changed, 25 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 22124f76d0b5..06908a3cee0f 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -7017,9 +7017,7 @@ void amdgpu_dm_connector_init_helper(struct 
amdgpu_display_manager *dm,
if (connector_type == DRM_MODE_CONNECTOR_HDMIA ||
connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
connector_type == DRM_MODE_CONNECTOR_eDP) {
-   drm_object_attach_property(
-   >base.base,
-   dm->ddev->mode_config.hdr_output_metadata_property, 0);
+   
drm_connector_attach_hdr_output_metadata_property(>base);
 
if (!aconnector->mst_port)

drm_connector_attach_vrr_capable_property(>base);
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index dda4fa9a1a08..f24bbb840dbf 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -2492,8 +2492,7 @@ static int dw_hdmi_connector_create(struct dw_hdmi *hdmi)
drm_connector_attach_max_bpc_property(connector, 8, 16);
 
if (hdmi->version >= 0x200a && hdmi->plat_data->use_drm_infoframe)
-   drm_object_attach_property(>base,
-   
connector->dev->mode_config.hdr_output_metadata_property, 0);
+   drm_connector_attach_hdr_output_metadata_property(connector);
 
drm_connector_attach_encoder(connector, hdmi->bridge.encoder);
 
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 98b6ec45ef96..e25248e23e18 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -2149,6 +2149,27 @@ int drm_connector_attach_max_bpc_property(struct 
drm_connector *connector,
 }
 EXPORT_SYMBOL(drm_connector_attach_max_bpc_property);
 
+/**
+ * drm_connector_attach_hdr_output_metadata_property - attach 
"HDR_OUTPUT_METADA" property
+ * @connector: connector to attach the property on.
+ *
+ * This is used to allow the userspace to send HDR Metadata to the
+ * driver.
+ *
+ * Returns:
+ * Zero on success, negative errno on failure.
+ */
+int drm_connector_attach_hdr_output_metadata_property(struct drm_connector 
*connector)
+{
+   struct drm_device *dev = connector->dev;
+   struct drm_property *prop = 
dev->mode_config.hdr_output_metadata_property;
+
+   drm_object_attach_property(>base, prop, 0);
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_connector_attach_hdr_output_metadata_property);
+
 /**
  * drm_connector_set_vrr_capable_property - sets the variable refresh rate
  * capable property for a connector
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index c5959590562b..52c051efb7b7 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -2958,8 +2958,7 @@ intel_hdmi_add_properties(struct intel_hdmi *intel_hdmi, 
struct drm_connector *c
drm_connector_attach_content_type_property(connector);
 
if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
-   drm_object_attach_property(>base,
-   
connector->dev->mode_config.hdr_output_metadata_property, 0);
+   drm_connector_attach_hdr_output_metadata_property(connector);
 
if (!HAS_GMCH(dev_priv))
drm_connector_attach_max_bpc_property(connector, 8, 12);
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 1922b278ffad..32172dab8427 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1671,6 +1671,7 @@ int drm_connector_attach_scaling_mode_property(struct 
drm_connector *connector,
   u32 scaling_mode_mask);
 int drm_connector_attach_vrr_capable_property(
struct drm_connector *connector);
+int drm_connector_attach_hdr_output_metadata_property(struct drm_connector 
*connector);
 int drm_mode_create_aspect_ratio_property(struct drm_device *dev);
 int drm_mode_create_hdmi_colorspace_property(struct drm_connector *connector);
 int drm_mode_create_dp_colorspace_property(struct drm_connector *connector);
-- 

[PATCH 2/3] drm/connector: Add helper to compare HDR metadata

[Maxime Ripard]

All the drivers that support the HDR metadata property have a similar
function to compare the metadata from one connector state to the next,
and force a mode change if they differ.

All these functions run pretty much the same code, so let's turn it into
an helper that can be shared across those drivers.

Signed-off-by: Maxime Ripard 
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 21 +-
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 17 +--
 drivers/gpu/drm/drm_connector.c   | 28 +++
 drivers/gpu/drm/i915/display/intel_atomic.c   | 13 +
 include/drm/drm_connector.h   |  2 ++
 5 files changed, 33 insertions(+), 48 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 06908a3cee0f..4eb5201e566a 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -5924,25 +5924,6 @@ static int fill_hdr_info_packet(const struct 
drm_connector_state *state,
return 0;
 }
 
-static bool
-is_hdr_metadata_different(const struct drm_connector_state *old_state,
- const struct drm_connector_state *new_state)
-{
-   struct drm_property_blob *old_blob = old_state->hdr_output_metadata;
-   struct drm_property_blob *new_blob = new_state->hdr_output_metadata;
-
-   if (old_blob != new_blob) {
-   if (old_blob && new_blob &&
-   old_blob->length == new_blob->length)
-   return memcmp(old_blob->data, new_blob->data,
- old_blob->length);
-
-   return true;
-   }
-
-   return false;
-}
-
 static int
 amdgpu_dm_connector_atomic_check(struct drm_connector *conn,
 struct drm_atomic_state *state)
@@ -5960,7 +5941,7 @@ amdgpu_dm_connector_atomic_check(struct drm_connector 
*conn,
if (!crtc)
return 0;
 
-   if (is_hdr_metadata_different(old_con_state, new_con_state)) {
+   if (!drm_connector_atomic_hdr_metadata_equal(old_con_state, 
new_con_state)) {
struct dc_info_packet hdr_infopacket;
 
ret = fill_hdr_info_packet(new_con_state, _infopacket);
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index f24bbb840dbf..f871e33c2fc9 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -2395,21 +2395,6 @@ static int dw_hdmi_connector_get_modes(struct 
drm_connector *connector)
return ret;
 }
 
-static bool hdr_metadata_equal(const struct drm_connector_state *old_state,
-  const struct drm_connector_state *new_state)
-{
-   struct drm_property_blob *old_blob = old_state->hdr_output_metadata;
-   struct drm_property_blob *new_blob = new_state->hdr_output_metadata;
-
-   if (!old_blob || !new_blob)
-   return old_blob == new_blob;
-
-   if (old_blob->length != new_blob->length)
-   return false;
-
-   return !memcmp(old_blob->data, new_blob->data, old_blob->length);
-}
-
 static int dw_hdmi_connector_atomic_check(struct drm_connector *connector,
  struct drm_atomic_state *state)
 {
@@ -2423,7 +2408,7 @@ static int dw_hdmi_connector_atomic_check(struct 
drm_connector *connector,
if (!crtc)
return 0;
 
-   if (!hdr_metadata_equal(old_state, new_state)) {
+   if (!drm_connector_atomic_hdr_metadata_equal(old_state, new_state)) {
crtc_state = drm_atomic_get_crtc_state(state, crtc);
if (IS_ERR(crtc_state))
return PTR_ERR(crtc_state);
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index e25248e23e18..d781a3a1e9bf 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -2170,6 +2170,34 @@ int 
drm_connector_attach_hdr_output_metadata_property(struct drm_connector *conn
 }
 EXPORT_SYMBOL(drm_connector_attach_hdr_output_metadata_property);
 
+/**
+ * drm_connector_atomic_hdr_metadata_equal - checks if the hdr metadata changed
+ * @old_state: old connector state to compare
+ * @new_state: new connector state to compare
+ *
+ * This is used by HDR-enabled drivers to test whether the HDR metadata
+ * have changed between two different connector state (and thus probably
+ * requires a full blown mode change).
+ *
+ * Returns:
+ * True if the metadata are equal, False otherwise
+ */
+bool drm_connector_atomic_hdr_metadata_equal(struct drm_connector_state 
*old_state,
+struct drm_connector_state 
*new_state)
+{
+   struct drm_property_blob *old_blob = old_state->hdr_output_metadata;
+   struct drm_property_blob *new_blob = new_state->hdr_output_metadata;
+
+   if (!old_blob || !new_blob)

[PATCH 3/3] drm/vc4: Add HDR metadata property to the VC5 HDMI connectors

[Maxime Ripard]

From: Dave Stevenson 

Now that we can export deeper colour depths, add in the signalling
for HDR metadata.

Signed-off-by: Dave Stevenson 
Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/vc4/vc4_hdmi.c | 53 ++
 drivers/gpu/drm/vc4/vc4_hdmi.h |  3 ++
 2 files changed, 56 insertions(+)

diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index eee9751009c2..c8846cf9dd24 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -214,6 +214,31 @@ static int vc4_hdmi_connector_get_modes(struct 
drm_connector *connector)
return ret;
 }
 
+static int vc4_hdmi_connector_atomic_check(struct drm_connector *connector,
+ struct drm_atomic_state *state)
+{
+   struct drm_connector_state *old_state =
+   drm_atomic_get_old_connector_state(state, connector);
+   struct drm_connector_state *new_state =
+   drm_atomic_get_new_connector_state(state, connector);
+   struct drm_crtc *crtc = new_state->crtc;
+
+   if (!crtc)
+   return 0;
+
+   if (!drm_connector_atomic_hdr_metadata_equal(old_state, new_state)) {
+   struct drm_crtc_state *crtc_state;
+
+   crtc_state = drm_atomic_get_crtc_state(state, crtc);
+   if (IS_ERR(crtc_state))
+   return PTR_ERR(crtc_state);
+
+   crtc_state->mode_changed = true;
+   }
+
+   return 0;
+}
+
 static void vc4_hdmi_connector_reset(struct drm_connector *connector)
 {
struct vc4_hdmi_connector_state *old_state =
@@ -263,6 +288,7 @@ static const struct drm_connector_funcs 
vc4_hdmi_connector_funcs = {
 
 static const struct drm_connector_helper_funcs vc4_hdmi_connector_helper_funcs 
= {
.get_modes = vc4_hdmi_connector_get_modes,
+   .atomic_check = vc4_hdmi_connector_atomic_check,
 };
 
 static int vc4_hdmi_connector_init(struct drm_device *dev,
@@ -299,6 +325,9 @@ static int vc4_hdmi_connector_init(struct drm_device *dev,
connector->interlace_allowed = 1;
connector->doublescan_allowed = 0;
 
+   if (vc4_hdmi->variant->supports_hdr)
+   drm_connector_attach_hdr_output_metadata_property(connector);
+
drm_connector_attach_encoder(connector, encoder);
 
return 0;
@@ -432,6 +461,25 @@ static void vc4_hdmi_set_audio_infoframe(struct 
drm_encoder *encoder)
vc4_hdmi_write_infoframe(encoder, );
 }
 
+static void vc4_hdmi_set_hdr_infoframe(struct drm_encoder *encoder)
+{
+   struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
+   struct drm_connector *connector = _hdmi->connector;
+   struct drm_connector_state *conn_state = connector->state;
+   union hdmi_infoframe frame;
+
+   if (!vc4_hdmi->variant->supports_hdr)
+   return;
+
+   if (!conn_state->hdr_output_metadata)
+   return;
+
+   if (drm_hdmi_infoframe_set_hdr_metadata(, conn_state))
+   return;
+
+   vc4_hdmi_write_infoframe(encoder, );
+}
+
 static void vc4_hdmi_set_infoframes(struct drm_encoder *encoder)
 {
struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
@@ -444,6 +492,8 @@ static void vc4_hdmi_set_infoframes(struct drm_encoder 
*encoder)
 */
if (vc4_hdmi->audio.streaming)
vc4_hdmi_set_audio_infoframe(encoder);
+
+   vc4_hdmi_set_hdr_infoframe(encoder);
 }
 
 static void vc4_hdmi_encoder_post_crtc_disable(struct drm_encoder *encoder,
@@ -2101,6 +2151,7 @@ static const struct vc4_hdmi_variant bcm2835_variant = {
.phy_rng_enable = vc4_hdmi_phy_rng_enable,
.phy_rng_disable= vc4_hdmi_phy_rng_disable,
.channel_map= vc4_hdmi_channel_map,
+   .supports_hdr   = false,
 };
 
 static const struct vc4_hdmi_variant bcm2711_hdmi0_variant = {
@@ -2128,6 +2179,7 @@ static const struct vc4_hdmi_variant 
bcm2711_hdmi0_variant = {
.phy_rng_enable = vc5_hdmi_phy_rng_enable,
.phy_rng_disable= vc5_hdmi_phy_rng_disable,
.channel_map= vc5_hdmi_channel_map,
+   .supports_hdr   = true,
 };
 
 static const struct vc4_hdmi_variant bcm2711_hdmi1_variant = {
@@ -2155,6 +2207,7 @@ static const struct vc4_hdmi_variant 
bcm2711_hdmi1_variant = {
.phy_rng_enable = vc5_hdmi_phy_rng_enable,
.phy_rng_disable= vc5_hdmi_phy_rng_disable,
.channel_map= vc5_hdmi_channel_map,
+   .supports_hdr   = true,
 };
 
 static const struct of_device_id vc4_hdmi_dt_match[] = {
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h b/drivers/gpu/drm/vc4/vc4_hdmi.h
index 3cebd1fd00fc..060bcaefbeb5 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.h
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
@@ -99,6 +99,9 @@ struct vc4_hdmi_variant {
 
/* Callback to get channel map */
u32 (*channel_map)(struct vc4_hdmi *vc4_hdmi, u32 channel_mask);
+
+   /* 

Re: [PATCH 3/3] drm/ttm: switch to per device LRU lock

[Christian König]

Am 19.03.21 um 05:32 schrieb Huang Rui:

On Thu, Mar 18, 2021 at 08:47:19PM +0800, Christian König wrote:

Instead of having a global lock.

Signed-off-by: Christian König 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c |  8 ++---
  drivers/gpu/drm/qxl/qxl_release.c  |  5 +--
  drivers/gpu/drm/ttm/ttm_bo.c   | 49 --
  drivers/gpu/drm/ttm/ttm_device.c   | 12 +++
  drivers/gpu/drm/ttm/ttm_execbuf_util.c |  8 ++---
  drivers/gpu/drm/ttm/ttm_resource.c |  9 +++--
  include/drm/ttm/ttm_bo_driver.h|  4 +--
  include/drm/ttm/ttm_device.h   |  4 +--
  8 files changed, 43 insertions(+), 56 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index 9d19078246c8..ae18c0e32347 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -638,15 +638,15 @@ void amdgpu_vm_move_to_lru_tail(struct amdgpu_device 
*adev,
struct amdgpu_vm_bo_base *bo_base;
  
  	if (vm->bulk_moveable) {

-   spin_lock(_glob.lru_lock);
+   spin_lock(>mman.bdev.lru_lock);

Could you please explain why do you want to instead of the global lock?


Potentially less contention.

But you are right mentioning this in the commit message is a good idea.

Regards,
Christian.



Thanks,
Ray


ttm_bo_bulk_move_lru_tail(>lru_bulk_move);
-   spin_unlock(_glob.lru_lock);
+   spin_unlock(>mman.bdev.lru_lock);
return;
}
  
  	memset(>lru_bulk_move, 0, sizeof(vm->lru_bulk_move));
  
-	spin_lock(_glob.lru_lock);

+   spin_lock(>mman.bdev.lru_lock);
list_for_each_entry(bo_base, >idle, vm_status) {
struct amdgpu_bo *bo = bo_base->bo;
  
@@ -660,7 +660,7 @@ void amdgpu_vm_move_to_lru_tail(struct amdgpu_device *adev,

>shadow->tbo.mem,
>lru_bulk_move);
}
-   spin_unlock(_glob.lru_lock);
+   spin_unlock(>mman.bdev.lru_lock);
  
  	vm->bulk_moveable = true;

  }
diff --git a/drivers/gpu/drm/qxl/qxl_release.c 
b/drivers/gpu/drm/qxl/qxl_release.c
index f5845c96d414..b19f2f00b215 100644
--- a/drivers/gpu/drm/qxl/qxl_release.c
+++ b/drivers/gpu/drm/qxl/qxl_release.c
@@ -426,16 +426,13 @@ void qxl_release_fence_buffer_objects(struct qxl_release 
*release)
   release->id | 0xf000, release->base.seqno);
trace_dma_fence_emit(>base);
  
-	spin_lock(_glob.lru_lock);

-
list_for_each_entry(entry, >bos, head) {
bo = entry->bo;
  
  		dma_resv_add_shared_fence(bo->base.resv, >base);

-   ttm_bo_move_to_lru_tail(bo, >mem, NULL);
+   ttm_bo_move_to_lru_tail_unlocked(bo);
dma_resv_unlock(bo->base.resv);
}
-   spin_unlock(_glob.lru_lock);
ww_acquire_fini(>ticket);
  }
  
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c

index 3673157527ff..2d2ac532987e 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -243,9 +243,9 @@ static int ttm_bo_individualize_resv(struct 
ttm_buffer_object *bo)
 * reference it any more. The only tricky case is the trylock on
 * the resv object while holding the lru_lock.
 */
-   spin_lock(_glob.lru_lock);
+   spin_lock(>bdev->lru_lock);
bo->base.resv = >base._resv;
-   spin_unlock(_glob.lru_lock);
+   spin_unlock(>bdev->lru_lock);
}
  
  	return r;

@@ -304,7 +304,7 @@ static int ttm_bo_cleanup_refs(struct ttm_buffer_object *bo,
  
  		if (unlock_resv)

dma_resv_unlock(bo->base.resv);
-   spin_unlock(_glob.lru_lock);
+   spin_unlock(>bdev->lru_lock);
  
  		lret = dma_resv_wait_timeout_rcu(resv, true, interruptible,

 30 * HZ);
@@ -314,7 +314,7 @@ static int ttm_bo_cleanup_refs(struct ttm_buffer_object *bo,
else if (lret == 0)
return -EBUSY;
  
-		spin_lock(_glob.lru_lock);

+   spin_lock(>bdev->lru_lock);
if (unlock_resv && !dma_resv_trylock(bo->base.resv)) {
/*
 * We raced, and lost, someone else holds the 
reservation now,
@@ -324,7 +324,7 @@ static int ttm_bo_cleanup_refs(struct ttm_buffer_object *bo,
 * delayed destruction would succeed, so just return 
success
 * here.
 */
-   spin_unlock(_glob.lru_lock);
+   spin_unlock(>bdev->lru_lock);
return 0;
}
ret = 0;
@@ -333,13 +333,13 @@ static int ttm_bo_cleanup_refs(struct ttm_buffer_object 
*bo,
if (ret || unlikely(list_empty(>ddestroy))) {

Re: [PATCH] gpu/drm/msm: fix shutdown hook in case GPU components failed to bind

[Fabio Estevam]

Hi Dmitry,

On Mon, Mar 1, 2021 at 6:41 PM Dmitry Baryshkov
 wrote:

> diff --git a/drivers/gpu/drm/msm/msm_atomic.c 
> b/drivers/gpu/drm/msm/msm_atomic.c
> index 6a326761dc4a..2fd0cf6421ad 100644
> --- a/drivers/gpu/drm/msm/msm_atomic.c
> +++ b/drivers/gpu/drm/msm/msm_atomic.c
> @@ -207,7 +207,12 @@ void msm_atomic_commit_tail(struct drm_atomic_state 
> *state)
> struct msm_kms *kms = priv->kms;
> struct drm_crtc *async_crtc = NULL;
> unsigned crtc_mask = get_crtc_mask(state);
> -   bool async = kms->funcs->vsync_time &&
> +   bool async;
> +
> +   if (!kms)
> +   return;
> +
> +   async = kms->funcs->vsync_time &&
> can_do_async(state, _crtc);

I also see the same issue on a i.MX53:
https://lists.freedesktop.org/archives/freedreno/2021-January/009369.html

Then I got a different suggestion from Rob. Please check:

https://www.spinics.net/lists/dri-devel/msg286648.html
and
https://www.spinics.net/lists/dri-devel/msg286649.html

Does this series fix the issue in your platform too?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/3] drm/ttm: move swapout logic around v2

[Christian König]

General question for the audience: Is there any way to silence the build 
bot here?


This is a well known false positive.

Regards,
Christian.

Am 18.03.21 um 19:13 schrieb kernel test robot:

Hi "Christian,

I love your patch! Yet something to improve:

[auto build test ERROR on drm-tip/drm-tip]
[also build test ERROR on next-20210318]
[cannot apply to drm-intel/for-linux-next drm-exynos/exynos-drm-next 
linus/master v5.12-rc3]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Christian-K-nig/drm-ttm-move-swapout-logic-around-v2/20210318-204848
base:   git://anongit.freedesktop.org/drm/drm-tip drm-tip
config: x86_64-randconfig-a005-20210318 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project 
6db3ab2903f42712f44000afb5aa467efbd25f35)
reproduce (this is a W=1 build):
 wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
 chmod +x ~/bin/make.cross
 # install x86_64 cross compiling tool for clang build
 # apt-get install binutils-x86-64-linux-gnu
 # 
https://github.com/0day-ci/linux/commit/a454d56ea061b53d24a62a700743e4508dd6c9b1
 git remote add linux-review https://github.com/0day-ci/linux
 git fetch --no-tags linux-review 
Christian-K-nig/drm-ttm-move-swapout-logic-around-v2/20210318-204848
 git checkout a454d56ea061b53d24a62a700743e4508dd6c9b1
 # save the attached .config to linux build tree
 COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All errors (new ones prefixed by >>):


drivers/gpu/drm/ttm/ttm_device.c:109:5: error: conflicting types for 
'ttm_global_swapout'

int ttm_global_swapout(struct ttm_operation_ctx *ctx, gfp_t gfp_flags)
^
include/drm/ttm/ttm_device.h:300:6: note: previous declaration is here
long ttm_global_swapout(struct ttm_operation_ctx *ctx, gfp_t gfp_flags);
 ^
1 error generated.


vim +/ttm_global_swapout +109 drivers/gpu/drm/ttm/ttm_device.c

104 
105 /**
106  * A buffer object shrink method that tries to swap out the first
107  * buffer object on the global::swap_lru list.
108  */
  > 109  int ttm_global_swapout(struct ttm_operation_ctx *ctx, gfp_t 
gfp_flags)
110 {
111 struct ttm_global *glob = _glob;
112 struct ttm_buffer_object *bo;
113 unsigned i;
114 int ret;
115 
116 spin_lock(>lru_lock);
117 for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
118 list_for_each_entry(bo, >swap_lru[i], swap) {
119 uint32_t num_pages = bo->ttm->num_pages;
120 
121 ret = ttm_bo_swapout(bo, ctx, gfp_flags);
122 /* ttm_bo_swapout has dropped the lru_lock */
123 if (!ret)
124 return num_pages;
125 if (ret != -EBUSY)
126 return ret;
127 }
128 }
129 spin_unlock(>lru_lock);
130 return 0;
131 }
132 EXPORT_SYMBOL(ttm_global_swapout);
133 

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/tegra: dc: Restore coupling of display controllers

[Dmitry Osipenko]

19.03.2021 10:06, Thierry Reding пишет:
> From: Thierry Reding 
> 
> Coupling of display controllers used to rely on runtime PM to take the
> companion controller out of reset. Commit fd67e9c6ed5a ("drm/tegra: Do
> not implement runtime PM") accidentally broke this when runtime PM was
> removed.
> 
> Restore this functionality by reusing the hierarchical host1x client
> suspend/resume infrastructure that's similar to runtime PM and which
> perfectly fits this use-case.
> 
> Fixes: fd67e9c6ed5a ("drm/tegra: Do not implement runtime PM")
> Reported-by: Dmitry Osipenko 
> Signed-off-by: Thierry Reding 

Hi,

This bug was originally reported by Paul Fertser, I redirected it to you.

Reported-by: Paul Fertser 

Formally, the stable kernel needs to be CCed since we want to have this
patch applied to the stable kernels.

Cc: sta...@vger.kernel.org

Otherwise this is good to me, thank you!

Tested-by: Dmitry Osipenko 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 30/30] drm/dp_mst: Convert drm_dp_mst_topology.c to drm_err()/drm_dbg*()

[Robert Foss]

Hey Lyude,

Thanks for the patch

On Fri, 19 Feb 2021 at 23:03, Lyude Paul  wrote:
>
> And finally, convert all of the code in drm_dp_mst_topology.c over to using
> drm_err() and drm_dbg*(). Note that this refactor would have been a lot
> more complicated to have tried writing a coccinelle script for, so this
> whole thing was done by hand.
>
> Signed-off-by: Lyude Paul 
> ---
>  drivers/gpu/drm/drm_dp_mst_topology.c | 369 +-
>  1 file changed, 187 insertions(+), 182 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index fb66df39e0bb..f66232954689 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -286,7 +286,8 @@ static void drm_dp_encode_sideband_msg_hdr(struct 
> drm_dp_sideband_msg_hdr *hdr,
> *len = idx;
>  }
>
> -static bool drm_dp_decode_sideband_msg_hdr(struct drm_dp_sideband_msg_hdr 
> *hdr,
> +static bool drm_dp_decode_sideband_msg_hdr(const struct 
> drm_dp_mst_topology_mgr *mgr,
> +  struct drm_dp_sideband_msg_hdr 
> *hdr,
>u8 *buf, int buflen, u8 *hdrlen)
>  {
> u8 crc4;
> @@ -303,7 +304,7 @@ static bool drm_dp_decode_sideband_msg_hdr(struct 
> drm_dp_sideband_msg_hdr *hdr,
> crc4 = drm_dp_msg_header_crc4(buf, (len * 2) - 1);
>
> if ((crc4 & 0xf) != (buf[len - 1] & 0xf)) {
> -   DRM_DEBUG_KMS("crc4 mismatch 0x%x 0x%x\n", crc4, buf[len - 
> 1]);
> +   drm_dbg_kms(mgr->dev, "crc4 mismatch 0x%x 0x%x\n", crc4, 
> buf[len - 1]);
> return false;
> }
>
> @@ -789,7 +790,8 @@ static bool drm_dp_sideband_append_payload(struct 
> drm_dp_sideband_msg_rx *msg,
> return true;
>  }
>
> -static bool drm_dp_sideband_parse_link_address(struct drm_dp_sideband_msg_rx 
> *raw,
> +static bool drm_dp_sideband_parse_link_address(const struct 
> drm_dp_mst_topology_mgr *mgr,
> +  struct drm_dp_sideband_msg_rx 
> *raw,
>struct 
> drm_dp_sideband_msg_reply_body *repmsg)
>  {
> int idx = 1;
> @@ -1014,7 +1016,8 @@ drm_dp_sideband_parse_query_stream_enc_status(
> return true;
>  }
>
> -static bool drm_dp_sideband_parse_reply(struct drm_dp_sideband_msg_rx *raw,
> +static bool drm_dp_sideband_parse_reply(const struct drm_dp_mst_topology_mgr 
> *mgr,
> +   struct drm_dp_sideband_msg_rx *raw,
> struct drm_dp_sideband_msg_reply_body 
> *msg)
>  {
> memset(msg, 0, sizeof(*msg));
> @@ -1030,7 +1033,7 @@ static bool drm_dp_sideband_parse_reply(struct 
> drm_dp_sideband_msg_rx *raw,
>
> switch (msg->req_type) {
> case DP_LINK_ADDRESS:
> -   return drm_dp_sideband_parse_link_address(raw, msg);
> +   return drm_dp_sideband_parse_link_address(mgr, raw, msg);
> case DP_QUERY_PAYLOAD:
> return drm_dp_sideband_parse_query_payload_ack(raw, msg);
> case DP_REMOTE_DPCD_READ:
> @@ -1053,14 +1056,16 @@ static bool drm_dp_sideband_parse_reply(struct 
> drm_dp_sideband_msg_rx *raw,
> case DP_QUERY_STREAM_ENC_STATUS:
> return drm_dp_sideband_parse_query_stream_enc_status(raw, 
> msg);
> default:
> -   DRM_ERROR("Got unknown reply 0x%02x (%s)\n", msg->req_type,
> - drm_dp_mst_req_type_str(msg->req_type));
> +   drm_err(mgr->dev, "Got unknown reply 0x%02x (%s)\n",
> +   msg->req_type, 
> drm_dp_mst_req_type_str(msg->req_type));
> return false;
> }
>  }
>
> -static bool drm_dp_sideband_parse_connection_status_notify(struct 
> drm_dp_sideband_msg_rx *raw,
> -  struct 
> drm_dp_sideband_msg_req_body *msg)
> +static bool
> +drm_dp_sideband_parse_connection_status_notify(const struct 
> drm_dp_mst_topology_mgr *mgr,
> +  struct drm_dp_sideband_msg_rx 
> *raw,
> +  struct 
> drm_dp_sideband_msg_req_body *msg)
>  {
> int idx = 1;
>
> @@ -1082,12 +1087,14 @@ static bool 
> drm_dp_sideband_parse_connection_status_notify(struct drm_dp_sideban
> idx++;
> return true;
>  fail_len:
> -   DRM_DEBUG_KMS("connection status reply parse length fail %d %d\n", 
> idx, raw->curlen);
> +   drm_dbg_kms(mgr->dev, "connection status reply parse length fail %d 
> %d\n",
> +   idx, raw->curlen);
> return false;
>  }
>
> -static bool drm_dp_sideband_parse_resource_status_notify(struct 
> drm_dp_sideband_msg_rx *raw,
> -  struct 
> drm_dp_sideband_msg_req_body *msg)
> +static bool drm_dp_sideband_parse_resource_status_notify(const 

Re: [PATCH 28/30] drm/dp: Convert drm_dp_helper.c to using drm_err/drm_dbg_*()

[Robert Foss]

Hey Lyude,

Thanks for the patch.

On Fri, 19 Feb 2021 at 23:03, Lyude Paul  wrote:
>
> Now that we've added a back-pointer to drm_device to drm_dp_aux, made
> drm_dp_aux available to any functions in drm_dp_helper.c which need to
> print to the kernel log, and ensured all of our logging uses a consistent
> format, let's do the final step of the conversion and actually move
> everything over to using drm_err() and drm_dbg_*().
>
> This was done by using the following cocci script:
>
>   @@
>   expression list expr;
>   @@
>
>   (
>   - DRM_DEBUG_KMS(expr);
>   + drm_dbg_kms(aux->drm_dev, expr);
>   |
>   - DRM_DEBUG_DP(expr);
>   + drm_dbg_dp(aux->drm_dev, expr);
>   |
>   - DRM_DEBUG_ATOMIC(expr);
>   + drm_dbg_atomic(aux->drm_dev, expr);
>   |
>   - DRM_DEBUG_KMS_RATELIMITED(expr);
>   + drm_dbg_kms_ratelimited(aux->drm_dev, expr);
>   |
>   - DRM_ERROR(expr);
>   + drm_err(aux->drm_dev, expr);
>   )
>
> Followed by correcting the resulting line-wrapping in the results by hand.
>
> Signed-off-by: Lyude Paul 
> ---
>  drivers/gpu/drm/drm_dp_helper.c | 122 
>  1 file changed, 60 insertions(+), 62 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index b5e2671baf22..0a787ddf39fd 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -139,8 +139,8 @@ void drm_dp_link_train_clock_recovery_delay(const struct 
> drm_dp_aux *aux,
>  DP_TRAINING_AUX_RD_MASK;
>
> if (rd_interval > 4)
> -   DRM_DEBUG_KMS("%s: AUX interval %lu, out of range (max 4)\n",
> - aux->name, rd_interval);
> +   drm_dbg_kms(aux->drm_dev, "%s: AUX interval %lu, out of range 
> (max 4)\n",
> +   aux->name, rd_interval);
>
> if (rd_interval == 0 || dpcd[DP_DPCD_REV] >= DP_DPCD_REV_14)
> rd_interval = 100;
> @@ -155,8 +155,8 @@ static void __drm_dp_link_train_channel_eq_delay(const 
> struct drm_dp_aux *aux,
>  unsigned long rd_interval)
>  {
> if (rd_interval > 4)
> -   DRM_DEBUG_KMS("%s: AUX interval %lu, out of range (max 4)\n",
> - aux->name, rd_interval);
> +   drm_dbg_kms(aux->drm_dev, "%s: AUX interval %lu, out of range 
> (max 4)\n",
> +   aux->name, rd_interval);
>
> if (rd_interval == 0)
> rd_interval = 400;
> @@ -220,11 +220,12 @@ drm_dp_dump_access(const struct drm_dp_aux *aux,
> const char *arrow = request == DP_AUX_NATIVE_READ ? "->" : "<-";
>
> if (ret > 0)
> -   DRM_DEBUG_DP("%s: 0x%05x AUX %s (ret=%3d) %*ph\n",
> -aux->name, offset, arrow, ret, min(ret, 20), 
> buffer);
> +   drm_dbg_dp(aux->drm_dev, "%s: 0x%05x AUX %s (ret=%3d) %*ph\n",
> +  aux->name, offset, arrow, ret, min(ret, 20),
> +  buffer);

checkpatch --strict is unhappy with this chunk

ERROR: code indent should use tabs where possible
#75: FILE: drivers/gpu/drm/drm_dp_helper.c:224:
+^I^I   aux->name, offset, arrow, ret, min(ret, 20),$

ERROR: code indent should use tabs where possible
#76: FILE: drivers/gpu/drm/drm_dp_helper.c:225:


> else
> -   DRM_DEBUG_DP("%s: 0x%05x AUX %s (ret=%3d)\n",
> -aux->name, offset, arrow, ret);
> +   drm_dbg_dp(aux->drm_dev, "%s: 0x%05x AUX %s (ret=%3d)\n",
> +  aux->name, offset, arrow, ret);

checkpatch --strict is unhappy with this chunk

ERROR: code indent should use tabs where possible
#81: FILE: drivers/gpu/drm/drm_dp_helper.c:228:
+^I^I   aux->name, offset, arrow, ret);$


>  }
>
>  /**
> @@ -287,8 +288,8 @@ static int drm_dp_dpcd_access(struct drm_dp_aux *aux, u8 
> request,
> err = ret;
> }
>
> -   DRM_DEBUG_KMS("%s: Too many retries, giving up. First error: %d\n",
> - aux->name, err);
> +   drm_dbg_kms(aux->drm_dev, "%s: Too many retries, giving up. First 
> error: %d\n",
> +   aux->name, err);
> ret = err;
>
>  unlock:
> @@ -524,44 +525,44 @@ bool drm_dp_send_real_edid_checksum(struct drm_dp_aux 
> *aux,
>
> if (drm_dp_dpcd_read(aux, DP_DEVICE_SERVICE_IRQ_VECTOR,
>  _test_req, 1) < 1) {
> -   DRM_ERROR("%s: DPCD failed read at register 0x%x\n",
> - aux->name, DP_DEVICE_SERVICE_IRQ_VECTOR);
> +   drm_err(aux->drm_dev, "%s: DPCD failed read at register 
> 0x%x\n",
> +   aux->name, DP_DEVICE_SERVICE_IRQ_VECTOR);
> return false;
> }
> auto_test_req &= DP_AUTOMATED_TEST_REQUEST;
>
> if (drm_dp_dpcd_read(aux, DP_TEST_REQUEST, _edid_read, 1) < 1) {
> -   DRM_ERROR("%s: 

Re: [PATCH 27/30] drm/dp_mst: Pass drm_dp_mst_topology_mgr to drm_dp_get_vc_payload_bw()

[Robert Foss]

Hey Lyude,

Thanks for the patch.

On Fri, 19 Feb 2021 at 23:03, Lyude Paul  wrote:
>
> Since this is one of the few functions in drm_dp_mst_topology.c that
> doesn't have any way of getting access to a drm_device, let's pass the
> drm_dp_mst_topology_mgr down to this function so that it can use
> drm_dbg_kms().
>
> Signed-off-by: Lyude Paul 
> ---
>  drivers/gpu/drm/drm_dp_mst_topology.c   | 7 +--
>  drivers/gpu/drm/i915/display/intel_dp_mst.c | 3 ++-
>  include/drm/drm_dp_mst_helper.h | 3 ++-
>  3 files changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index cf4f2f85711e..fb66df39e0bb 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -3631,6 +3631,7 @@ static int drm_dp_send_up_ack_reply(struct 
> drm_dp_mst_topology_mgr *mgr,
>
>  /**
>   * drm_dp_get_vc_payload_bw - get the VC payload BW for an MST link
> + * @mgr: The _dp_mst_topology_mgr to use
>   * @link_rate: link rate in 10kbits/s units
>   * @link_lane_count: lane count
>   *
> @@ -3639,7 +3640,8 @@ static int drm_dp_send_up_ack_reply(struct 
> drm_dp_mst_topology_mgr *mgr,
>   * convert the number of PBNs required for a given stream to the number of
>   * timeslots this stream requires in each MTP.
>   */
> -int drm_dp_get_vc_payload_bw(int link_rate, int link_lane_count)
> +int drm_dp_get_vc_payload_bw(const struct drm_dp_mst_topology_mgr *mgr,
> +int link_rate, int link_lane_count)
>  {
> if (link_rate == 0 || link_lane_count == 0)
> DRM_DEBUG_KMS("invalid link rate/lane count: (%d / %d)\n",
> @@ -3704,7 +3706,8 @@ int drm_dp_mst_topology_mgr_set_mst(struct 
> drm_dp_mst_topology_mgr *mgr, bool ms
> goto out_unlock;
> }
>
> -   mgr->pbn_div = 
> drm_dp_get_vc_payload_bw(drm_dp_bw_code_to_link_rate(mgr->dpcd[1]),
> +   mgr->pbn_div = drm_dp_get_vc_payload_bw(mgr,
> +   
> drm_dp_bw_code_to_link_rate(mgr->dpcd[1]),
> mgr->dpcd[2] & 
> DP_MAX_LANE_COUNT_MASK);
> if (mgr->pbn_div == 0) {
> ret = -EINVAL;
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c 
> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index 8e316146b6d1..60ca0fa32d15 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> @@ -70,7 +70,8 @@ static int intel_dp_mst_compute_link_config(struct 
> intel_encoder *encoder,
> slots = drm_dp_atomic_find_vcpi_slots(state, 
> _dp->mst_mgr,
>   connector->port,
>   crtc_state->pbn,
> - 
> drm_dp_get_vc_payload_bw(crtc_state->port_clock,
> + 
> drm_dp_get_vc_payload_bw(_dp->mst_mgr,
> + 
>  crtc_state->port_clock,
>   
>  crtc_state->lane_count));

checkpatch --strict is unhappy about this chunk

WARNING: line length of 102 exceeds 100 columns
#61: FILE: drivers/gpu/drm/i915/display/intel_dp_mst.c:73:
+   crtc_state->port_clock,

Maybe the results of drm_dp_get_vc_payload_bw() can be but in a
temporary variable.

> if (slots == -EDEADLK)
> return slots;
> diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
> index bd1c39907b92..20dc705642bd 100644
> --- a/include/drm/drm_dp_mst_helper.h
> +++ b/include/drm/drm_dp_mst_helper.h
> @@ -783,7 +783,8 @@ drm_dp_mst_detect_port(struct drm_connector *connector,
>
>  struct edid *drm_dp_mst_get_edid(struct drm_connector *connector, struct 
> drm_dp_mst_topology_mgr *mgr, struct drm_dp_mst_port *port);
>
> -int drm_dp_get_vc_payload_bw(int link_rate, int link_lane_count);
> +int drm_dp_get_vc_payload_bw(const struct drm_dp_mst_topology_mgr *mgr,
> +int link_rate, int link_lane_count);
>
>  int drm_dp_calc_pbn_mode(int clock, int bpp, bool dsc);
>
> --
> 2.29.2
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 18/30] drm/print: Fixup DRM_DEBUG_KMS_RATELIMITED()

[Robert Foss]

Hey Lyude,

Thanks for the patch,

On Fri, 19 Feb 2021 at 22:59, Lyude Paul  wrote:
>
> Since we're about to move drm_dp_helper.c over to drm_dbg_*(), we'll want
> to make sure that we can also add ratelimited versions of these macros in
> order to retain some of the previous debugging output behavior we had.
>
> However, as I was preparing to do this I noticed that the current
> rate limited macros we have are kind of bogus. It looks like when I wrote
> these, I didn't notice that we'd always be calling __ratelimit() even if
> the debugging message we'd be printing would normally be filtered out due
> to the relevant DRM debugging category being disabled.
>
> So, let's fix this by making sure to check drm_debug_enabled() in our
> ratelimited macros before calling __ratelimit(), and start using
> drm_dev_printk() in order to print debugging messages since that will save
> us from doing a redundant drm_debug_enabled() check. And while we're at it,
> let's move the code for this into another macro that we can reuse for
> defining new ratelimited DRM debug macros more easily.
>
> Signed-off-by: Lyude Paul 
> ---
>  include/drm/drm_print.h | 20 
>  1 file changed, 12 insertions(+), 8 deletions(-)
>
> diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
> index f32d179e139d..3a0c3fe4d292 100644
> --- a/include/drm/drm_print.h
> +++ b/include/drm/drm_print.h
> @@ -524,16 +524,20 @@ void __drm_err(const char *format, ...);
>  #define DRM_DEBUG_DP(fmt, ...) \
> __drm_dbg(DRM_UT_DP, fmt, ## __VA_ARGS__)
>
> -
> -#define DRM_DEBUG_KMS_RATELIMITED(fmt, ...)\
> -({ \
> -   static DEFINE_RATELIMIT_STATE(_rs,  \
> - DEFAULT_RATELIMIT_INTERVAL,   \
> - DEFAULT_RATELIMIT_BURST); \
> -   if (__ratelimit(&_rs))  \
> -   drm_dev_dbg(NULL, DRM_UT_KMS, fmt, ##__VA_ARGS__);  \
> +#define __DRM_DEFINE_DBG_RATELIMITED(category, drm, fmt, ...)
> \
> +({   
> \
> +   static DEFINE_RATELIMIT_STATE(rs_, DEFAULT_RATELIMIT_INTERVAL, 
> DEFAULT_RATELIMIT_BURST); \
> +   const struct drm_device *drm_ = (drm);
>\
> + 
> \
> +   if (drm_debug_enabled(DRM_UT_ ## category) && __ratelimit(_))  
>\
> +   drm_dev_printk(drm_ ? drm_->dev : NULL, KERN_DEBUG, fmt, ## 
> __VA_ARGS__);\
>  })

checkpatch --strict is unhappy about the tabs/spaces in this patch


ERROR: code indent should use tabs where possible
#48: FILE: include/drm/drm_print.h:531:
+
   \$

WARNING: please, no spaces at the start of a line
#48: FILE: include/drm/drm_print.h:531:
+
   \$


>
> +#define drm_dbg_kms_ratelimited(drm, fmt, ...) \
> +   __DRM_DEFINE_DBG_RATELIMITED(KMS, drm, fmt, ## __VA_ARGS__)
> +
> +#define DRM_DEBUG_KMS_RATELIMITED(fmt, ...) drm_dbg_kms_ratelimited(NULL, 
> fmt, ## __VA_ARGS__)
> +
>  /*
>   * struct drm_device based WARNs
>   *
> --
> 2.29.2
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 00/18] drm/vc4: hdmi: Add Support for the YUV output

[Maxime Ripard]

Hi Jernej,

On Thu, Mar 18, 2021 at 07:16:33PM +0100, Jernej Škrabec wrote:
> Dne sreda, 17. marec 2021 ob 16:43:34 CET je Maxime Ripard napisal(a):
> > Hi,
> > 
> > Here's an attempt at support the HDMI YUV output on the BCM2711 SoC found on
> > the RaspberryPi4.
> > 
> > I took the same approach than what dw-hdmi did already, turning a bunch of
> > functions found in that driver into helpers since they were fairly generic.
> > 
> > However, it feels a bit clunky overall and there's a few rough edges that
> > should be addressed in a generic manner:
> > 
> >   - while the format negociation makes sense for a bridge, it feels a bit
> > over-engineered for a simple encoder where that setting could be a 
> simple
> > switch (and possibly a property?)
> 
> Property could work, but possible values should be then limited to cross 
> section of HW and connected display capabilities.

That's a good point. I'm not sure if the userspace should expect the
list of values of an enum to change under its feet

> > - more importantly, whether we're choosing an YUV output or not is
> >   completely hidden away from the userspace even though it might
> >   have some effect on > the visual quality output (thinking about
> >   YUV420 and YUV422 here mostly).
> 
> IMO driver should select highest achievable quality. So in case of
> YUV420 and YUV422, later should be selected. This should be the case
> even if the property is implemented.

Well, it depends on the hardware capability. On RPi4 in some situations
(high bpc count), we can't output anything else than YUV422. I'd expect
to have some way for the userspace to know at least. And then, for
subsampling formats it's fairly easy to tell which is the highest
achievable quality, but it would be pretty hard for YUV444 vs RGB?

Maxime


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: i915: Fix a typo

[Jani Nikula]

On Fri, 19 Mar 2021, Bhaskar Chowdhury  wrote:
> s/nothign/nothing/
>
> Signed-off-by: Bhaskar Chowdhury 

Thanks, pushed.

BR,
Jani.

> ---
>  drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c 
> b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> index f6ad257a260e..14d784a6fae5 100644
> --- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> +++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> @@ -4185,7 +4185,7 @@ static void icl_pll_disable(struct drm_i915_private 
> *dev_priv,
>   /*
>* DVFS pre sequence would be here, but in our driver the cdclk code
>* paths should already be setting the appropriate voltage, hence we do
> -  * nothign here.
> +  * nothing here.
>*/
>
>   val = intel_de_read(dev_priv, enable_reg);
> --
> 2.26.2
>

-- 
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 02/18] drm/bridge: Add HDMI output fmt helper

[Maxime Ripard]

On Fri, Mar 19, 2021 at 10:44:56AM +0100, Neil Armstrong wrote:
> On 18/03/2021 19:31, Jernej Škrabec wrote:
> > Dne sreda, 17. marec 2021 ob 17:08:07 CET je Neil Armstrong napisal(a):
> >> On 17/03/2021 16:43, Maxime Ripard wrote:
> >>> The atomic_get_output_bus_fmts bridge callback is there to list the
> >>> available formats for output by decreasing order of preference.
> >>>
> >>> On HDMI controllers, we have a fairly static list that will depend on
> >>> what the HDMI sink is capable of and the BPC our controller can output.
> >>>
> >>> The dw-hdmi driver already has that code done in a fairly generic
> >>> manner, so let's turn that code into an helper for all the HDMI
> >>> controllers to reuse.
> >>
> >> This code was based on the capabilities of the DW-HDMI IP, copying it as-is
> >> doesn't make much sense, we should be able to filter out formats the HDMI 
> >> IP
> >> doesn't support.
> > 
> > HDMI standard has pretty strict requirements which formats should be 
> > supported, so cores should have very similar capabilities.
> 
> Yes for output formats (we still may need to filter out 420, 422 for example),
> 
> No for input formats, since it depends entirely on the capability of the 
> transceiver
> in terms of format conversion.

Yeah, of course, that's why I only moved the output part to a generic helper :)

We indeed might need to provide additional filtering to the output though

Maxime


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 14/19] drm/nouveau/dispnv50/headc57d: Make local function 'headc57d_olut' static

[Karol Herbst]

On Fri, Mar 19, 2021 at 9:25 AM Lee Jones  wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
>  drivers/gpu/drm/nouveau/dispnv50/headc57d.c:173:1: warning: no previous 
> prototype for ‘headc57d_olut’ [-Wmissing-prototypes]
>
> Cc: Ben Skeggs 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Lyude Paul 
> Cc: dri-devel@lists.freedesktop.org
> Cc: nouv...@lists.freedesktop.org
> Signed-off-by: Lee Jones 
> ---
>  drivers/gpu/drm/nouveau/dispnv50/headc57d.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/dispnv50/headc57d.c 
> b/drivers/gpu/drm/nouveau/dispnv50/headc57d.c
> index fd51527b56b83..bdcfd240d61c8 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/headc57d.c
> +++ b/drivers/gpu/drm/nouveau/dispnv50/headc57d.c
> @@ -169,7 +169,7 @@ headc57d_olut_load(struct drm_color_lut *in, int size, 
> void __iomem *mem)
> writew(readw(mem - 4), mem + 4);
>  }
>
> -bool
> +static bool
>  headc57d_olut(struct nv50_head *head, struct nv50_head_atom *asyh, int size)
>  {
> if (size != 0 && size != 256 && size != 1024)
> --
> 2.27.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

Reviewed-by: Karol Herbst 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 12/19] drm/nouveau/dispnv04/crtc: Demote non-conforming kernel-doc headers

[Karol Herbst]

On Fri, Mar 19, 2021 at 9:25 AM Lee Jones  wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
>  drivers/gpu/drm/nouveau/dispnv04/crtc.c:462: warning: Function parameter or 
> member 'crtc' not described in 'nv_crtc_mode_set_regs'
>  drivers/gpu/drm/nouveau/dispnv04/crtc.c:462: warning: Function parameter or 
> member 'mode' not described in 'nv_crtc_mode_set_regs'
>  drivers/gpu/drm/nouveau/dispnv04/crtc.c:640: warning: Function parameter or 
> member 'crtc' not described in 'nv_crtc_mode_set'
>  drivers/gpu/drm/nouveau/dispnv04/crtc.c:640: warning: Function parameter or 
> member 'mode' not described in 'nv_crtc_mode_set'
>  drivers/gpu/drm/nouveau/dispnv04/crtc.c:640: warning: Function parameter or 
> member 'adjusted_mode' not described in 'nv_crtc_mode_set'
>  drivers/gpu/drm/nouveau/dispnv04/crtc.c:640: warning: Function parameter or 
> member 'x' not described in 'nv_crtc_mode_set'
>  drivers/gpu/drm/nouveau/dispnv04/crtc.c:640: warning: Function parameter or 
> member 'y' not described in 'nv_crtc_mode_set'
>  drivers/gpu/drm/nouveau/dispnv04/crtc.c:640: warning: Function parameter or 
> member 'old_fb' not described in 'nv_crtc_mode_set'
>
> Cc: Ben Skeggs 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: dri-devel@lists.freedesktop.org
> Cc: nouv...@lists.freedesktop.org
> Signed-off-by: Lee Jones 
> ---
>  drivers/gpu/drm/nouveau/dispnv04/crtc.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/dispnv04/crtc.c 
> b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
> index f9e962fd94d0d..f9a276ea5a9e0 100644
> --- a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
> +++ b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
> @@ -449,7 +449,7 @@ nv_crtc_mode_set_vga(struct drm_crtc *crtc, struct 
> drm_display_mode *mode)
> regp->Attribute[NV_CIO_AR_CSEL_INDEX] = 0x00;
>  }
>
> -/**
> +/*
>   * Sets up registers for the given mode/adjusted_mode pair.
>   *
>   * The clocks, CRTCs and outputs attached to this CRTC must be off.
> @@ -625,7 +625,7 @@ nv_crtc_swap_fbs(struct drm_crtc *crtc, struct 
> drm_framebuffer *old_fb)
> return ret;
>  }
>
> -/**
> +/*
>   * Sets up registers for the given mode/adjusted_mode pair.
>   *
>   * The clocks, CRTCs and outputs attached to this CRTC must be off.
> --
> 2.27.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>

Reviewed-by: Karol Herbst 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 17/19] drm/nouveau/nouveau_ioc32: File headers are not good candidates for kernel-doc

[Karol Herbst]

On Fri, Mar 19, 2021 at 9:25 AM Lee Jones  wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
>  drivers/gpu/drm/nouveau/nouveau_ioc32.c:2: warning: Cannot understand  * 
> file mga_ioc32.c
>
> Cc: Ben Skeggs 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: dri-devel@lists.freedesktop.org
> Cc: nouv...@lists.freedesktop.org
> Signed-off-by: Lee Jones 
> ---
>  drivers/gpu/drm/nouveau/nouveau_ioc32.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_ioc32.c 
> b/drivers/gpu/drm/nouveau/nouveau_ioc32.c
> index adf01ca9e035d..8ddf9b2325a42 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_ioc32.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_ioc32.c
> @@ -1,4 +1,4 @@
> -/**
> +/*
>   * \file mga_ioc32.c
>   *
>   * 32-bit ioctl compatibility routines for the MGA DRM.
> --
> 2.27.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>

Reviewed-by: Karol Herbst 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 19/19] drm/nouveau/nouveau_ioc32: Demote kernel-doc abuse to standard comment block

[Karol Herbst]

On Fri, Mar 19, 2021 at 9:25 AM Lee Jones  wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
>  drivers/gpu/drm/nouveau/nouveau_ioc32.c:52: warning: Function parameter or 
> member 'filp' not described in 'nouveau_compat_ioctl'
>  drivers/gpu/drm/nouveau/nouveau_ioc32.c:52: warning: Function parameter or 
> member 'cmd' not described in 'nouveau_compat_ioctl'
>  drivers/gpu/drm/nouveau/nouveau_ioc32.c:52: warning: Function parameter or 
> member 'arg' not described in 'nouveau_compat_ioctl'
>
> Cc: Ben Skeggs 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: dri-devel@lists.freedesktop.org
> Cc: nouv...@lists.freedesktop.org
> Signed-off-by: Lee Jones 
> ---
>  drivers/gpu/drm/nouveau/nouveau_ioc32.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_ioc32.c 
> b/drivers/gpu/drm/nouveau/nouveau_ioc32.c
> index 8ddf9b2325a42..2af3615c5205c 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_ioc32.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_ioc32.c
> @@ -38,7 +38,7 @@
>
>  #include "nouveau_ioctl.h"
>
> -/**
> +/*
>   * Called whenever a 32-bit process running under a 64-bit kernel
>   * performs an ioctl on /dev/dri/card.
>   *
> --
> 2.27.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>

Reviewed-by: Karol Herbst 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 10/19] drm/nouveau/nouveau_bo: Remove unused variables 'dev'

[Karol Herbst]

On Fri, Mar 19, 2021 at 9:25 AM Lee Jones  wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
>  drivers/gpu/drm/nouveau/nouveau_bo.c: In function ‘nouveau_ttm_tt_populate’:
>  drivers/gpu/drm/nouveau/nouveau_bo.c:1228:17: warning: variable ‘dev’ set 
> but not used [-Wunused-but-set-variable]
>  drivers/gpu/drm/nouveau/nouveau_bo.c: In function 
> ‘nouveau_ttm_tt_unpopulate’:
>  drivers/gpu/drm/nouveau/nouveau_bo.c:1252:17: warning: variable ‘dev’ set 
> but not used [-Wunused-but-set-variable]
>
> Cc: Ben Skeggs 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Sumit Semwal 
> Cc: "Christian König" 
> Cc: Jeremy Kolb 
> Cc: dri-devel@lists.freedesktop.org
> Cc: nouv...@lists.freedesktop.org
> Cc: linux-me...@vger.kernel.org
> Cc: linaro-mm-...@lists.linaro.org
> Signed-off-by: Lee Jones 
> ---
>  drivers/gpu/drm/nouveau/nouveau_bo.c | 4 
>  1 file changed, 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
> b/drivers/gpu/drm/nouveau/nouveau_bo.c
> index 281e9ed139895..913035ab85ec2 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> @@ -1250,7 +1250,6 @@ nouveau_ttm_tt_populate(struct ttm_device *bdev,
>  {
> struct ttm_tt *ttm_dma = (void *)ttm;
> struct nouveau_drm *drm;
> -   struct device *dev;
> bool slave = !!(ttm->page_flags & TTM_PAGE_FLAG_SG);
>
> if (ttm_tt_is_populated(ttm))
> @@ -1263,7 +1262,6 @@ nouveau_ttm_tt_populate(struct ttm_device *bdev,
> }
>
> drm = nouveau_bdev(bdev);
> -   dev = drm->dev->dev;
>
> return ttm_pool_alloc(>ttm.bdev.pool, ttm, ctx);
>  }
> @@ -1273,14 +1271,12 @@ nouveau_ttm_tt_unpopulate(struct ttm_device *bdev,
>   struct ttm_tt *ttm)
>  {
> struct nouveau_drm *drm;
> -   struct device *dev;
> bool slave = !!(ttm->page_flags & TTM_PAGE_FLAG_SG);
>
> if (slave)
> return;
>
> drm = nouveau_bdev(bdev);
> -   dev = drm->dev->dev;
>
> return ttm_pool_free(>ttm.bdev.pool, ttm);
>  }
> --
> 2.27.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

Reviewed-by: Karol Herbst 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 15/19] drm/nouveau/nv50_display: Remove superfluous prototype for local static functions

[Karol Herbst]

On Fri, Mar 19, 2021 at 9:25 AM Lee Jones  wrote:
>
> Fixes the following build error:
>
>  drivers/gpu/drm/nouveau/dispnv50/disp.c:2530:1: error: conflicting types for 
> ‘nv50_display_fini’
>  In file included from drivers/gpu/drm/nouveau/dispnv50/disp.c:71:
>  drivers/gpu/drm/nouveau/nv50_display.h:36:6: note: previous declaration of 
> ‘nv50_display_fini’ was her
>  In file included from drivers/gpu/drm/nouveau/dispnv50/disp.c:71:
>  drivers/gpu/drm/nouveau/nv50_display.h:35:6: note: previous declaration of 
> ‘nv50_display_init’ was here
>  drivers/gpu/drm/nouveau/dispnv50/disp.c:2581:1: error: static declaration of 
> ‘nv50_display_destroy’ follows non-static declaration
>  In file included from drivers/gpu/drm/nouveau/dispnv50/disp.c:71:
>  drivers/gpu/drm/nouveau/nv50_display.h:34:6: note: previous declaration of 
> ‘nv50_display_destroy’ was here
>
> Cc: Ben Skeggs 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: dri-devel@lists.freedesktop.org
> Cc: nouv...@lists.freedesktop.org
> Signed-off-by: Lee Jones 
> ---
>  drivers/gpu/drm/nouveau/nv50_display.h | 3 ---
>  1 file changed, 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nv50_display.h 
> b/drivers/gpu/drm/nouveau/nv50_display.h
> index fbd3b15583bc8..2421401d12636 100644
> --- a/drivers/gpu/drm/nouveau/nv50_display.h
> +++ b/drivers/gpu/drm/nouveau/nv50_display.h
> @@ -31,7 +31,4 @@
>  #include "nouveau_reg.h"
>
>  int  nv50_display_create(struct drm_device *);
> -void nv50_display_destroy(struct drm_device *);
> -int  nv50_display_init(struct drm_device *);
> -void nv50_display_fini(struct drm_device *);
>  #endif /* __NV50_DISPLAY_H__ */
> --
> 2.27.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

Reviewed-by: Karol Herbst 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 09/19] drm/nouveau/nvkm/engine/gr/gf100: Demote non-conformant kernel-doc header

[Karol Herbst]

On Fri, Mar 19, 2021 at 9:25 AM Lee Jones  wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
>  drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c:992: warning: Function 
> parameter or member 'gr' not described in 'gf100_gr_wait_idle'
>
> Cc: Ben Skeggs 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: dri-devel@lists.freedesktop.org
> Cc: nouv...@lists.freedesktop.org
> Signed-off-by: Lee Jones 
> ---
>  drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c 
> b/drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c
> index 397ff4fe9df89..69e6008f99196 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c
> @@ -982,7 +982,7 @@ gf100_gr_zbc_init(struct gf100_gr *gr)
> }
>  }
>
> -/**
> +/*
>   * Wait until GR goes idle. GR is considered idle if it is disabled by the
>   * MC (0x200) register, or GR is not busy and a context switch is not in
>   * progress.
> --
> 2.27.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>

Reviewed-by: Karol Herbst 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 05/19] drm/nouveau/nvkm/subdev/volt/gk20a: Demote non-conformant kernel-doc headers

[Karol Herbst]

On Fri, Mar 19, 2021 at 9:24 AM Lee Jones  wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
>  drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c:53: warning: Function 
> parameter or member 'speedo' not described in 'gk20a_volt_get_cvb_voltage'
>  drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c:53: warning: Function 
> parameter or member 's_scale' not described in 'gk20a_volt_get_cvb_voltage'
>  drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c:53: warning: Function 
> parameter or member 'coef' not described in 'gk20a_volt_get_cvb_voltage'
>  drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c:69: warning: Function 
> parameter or member 'speedo' not described in 'gk20a_volt_get_cvb_t_voltage'
>  drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c:69: warning: Function 
> parameter or member 'temp' not described in 'gk20a_volt_get_cvb_t_voltage'
>  drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c:69: warning: Function 
> parameter or member 's_scale' not described in 'gk20a_volt_get_cvb_t_voltage'
>  drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c:69: warning: Function 
> parameter or member 't_scale' not described in 'gk20a_volt_get_cvb_t_voltage'
>  drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c:69: warning: Function 
> parameter or member 'coef' not described in 'gk20a_volt_get_cvb_t_voltage'
>
> Cc: Ben Skeggs 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: dri-devel@lists.freedesktop.org
> Cc: nouv...@lists.freedesktop.org
> Signed-off-by: Lee Jones 
> ---
>  drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c 
> b/drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c
> index 8c2faa9645111..ccac88da88648 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c
> @@ -45,7 +45,7 @@ static const struct cvb_coef gk20a_cvb_coef[] = {
> /* 852 */ { 1608418, -21643, -269, 0,763,  -48},
>  };
>
> -/**
> +/*
>   * cvb_mv = ((c2 * speedo / s_scale + c1) * speedo / s_scale + c0)
>   */
>  static inline int
> @@ -58,7 +58,7 @@ gk20a_volt_get_cvb_voltage(int speedo, int s_scale, const 
> struct cvb_coef *coef)
> return mv;
>  }
>
> -/**
> +/*
>   * cvb_t_mv =
>   * ((c2 * speedo / s_scale + c1) * speedo / s_scale + c0) +
>   * ((c3 * speedo / s_scale + c4 + c5 * T / t_scale) * T / t_scale)
> --
> 2.27.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>

Reviewed-by: Karol Herbst 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 01/19] drm/nouveau/nvkm/subdev/bios/init: Demote obvious abuse of kernel-doc

[Karol Herbst]

Reviewed-by: Karol Herbst 

On Fri, Mar 19, 2021 at 9:24 AM Lee Jones  wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
>  drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c:584: warning: Function 
> parameter or member 'init' not described in 'init_reserved'
>  drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c:611: warning: Function 
> parameter or member 'init' not described in 'init_done'
>  drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c:622: warning: Function 
> parameter or member 'init' not described in 'init_io_restrict_prog'
>  drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c:659: warning: Function 
> parameter or member 'init' not described in 'init_repeat'
>  drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c:685: warning: Function 
> parameter or member 'init' not described in 'init_io_restrict_pll'
>  drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c:725: warning: Function 
> parameter or member 'init' not described in 'init_end_repeat'
>
> NB: Trimmed for brevity (lots of these!)
>
> Cc: Ben Skeggs 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: dri-devel@lists.freedesktop.org
> Cc: nouv...@lists.freedesktop.org
> Signed-off-by: Lee Jones 
> ---
>  .../gpu/drm/nouveau/nvkm/subdev/bios/init.c   | 204 ++
>  1 file changed, 68 insertions(+), 136 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c 
> b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c
> index 9de74f41dcd2a..5a91dc4e5c8ec 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c
> @@ -575,9 +575,8 @@ init_tmds_reg(struct nvbios_init *init, u8 tmds)
>   * init opcode handlers
>   
> */
>
> -/**
> +/*
>   * init_reserved - stub for various unknown/unused single-byte opcodes
> - *
>   */
>  static void
>  init_reserved(struct nvbios_init *init)
> @@ -602,9 +601,8 @@ init_reserved(struct nvbios_init *init)
> init->offset += length;
>  }
>
> -/**
> +/*
>   * INIT_DONE - opcode 0x71
> - *
>   */
>  static void
>  init_done(struct nvbios_init *init)
> @@ -613,9 +611,8 @@ init_done(struct nvbios_init *init)
> init->offset = 0x;
>  }
>
> -/**
> +/*
>   * INIT_IO_RESTRICT_PROG - opcode 0x32
> - *
>   */
>  static void
>  init_io_restrict_prog(struct nvbios_init *init)
> @@ -650,9 +647,8 @@ init_io_restrict_prog(struct nvbios_init *init)
> trace("}]\n");
>  }
>
> -/**
> +/*
>   * INIT_REPEAT - opcode 0x33
> - *
>   */
>  static void
>  init_repeat(struct nvbios_init *init)
> @@ -676,9 +672,8 @@ init_repeat(struct nvbios_init *init)
> init->repeat = repeat;
>  }
>
> -/**
> +/*
>   * INIT_IO_RESTRICT_PLL - opcode 0x34
> - *
>   */
>  static void
>  init_io_restrict_pll(struct nvbios_init *init)
> @@ -716,9 +711,8 @@ init_io_restrict_pll(struct nvbios_init *init)
> trace("}]\n");
>  }
>
> -/**
> +/*
>   * INIT_END_REPEAT - opcode 0x36
> - *
>   */
>  static void
>  init_end_repeat(struct nvbios_init *init)
> @@ -732,9 +726,8 @@ init_end_repeat(struct nvbios_init *init)
> }
>  }
>
> -/**
> +/*
>   * INIT_COPY - opcode 0x37
> - *
>   */
>  static void
>  init_copy(struct nvbios_init *init)
> @@ -759,9 +752,8 @@ init_copy(struct nvbios_init *init)
> init_wrvgai(init, port, index, data);
>  }
>
> -/**
> +/*
>   * INIT_NOT - opcode 0x38
> - *
>   */
>  static void
>  init_not(struct nvbios_init *init)
> @@ -771,9 +763,8 @@ init_not(struct nvbios_init *init)
> init_exec_inv(init);
>  }
>
> -/**
> +/*
>   * INIT_IO_FLAG_CONDITION - opcode 0x39
> - *
>   */
>  static void
>  init_io_flag_condition(struct nvbios_init *init)
> @@ -788,9 +779,8 @@ init_io_flag_condition(struct nvbios_init *init)
> init_exec_set(init, false);
>  }
>
> -/**
> +/*
>   * INIT_GENERIC_CONDITION - opcode 0x3a
> - *
>   */
>  static void
>  init_generic_condition(struct nvbios_init *init)
> @@ -840,9 +830,8 @@ init_generic_condition(struct nvbios_init *init)
> }
>  }
>
> -/**
> +/*
>   * INIT_IO_MASK_OR - opcode 0x3b
> - *
>   */
>  static void
>  init_io_mask_or(struct nvbios_init *init)
> @@ -859,9 +848,8 @@ init_io_mask_or(struct nvbios_init *init)
> init_wrvgai(init, 0x03d4, index, data &= ~(1 << or));
>  }
>
> -/**
> +/*
>   * INIT_IO_OR - opcode 0x3c
> - *
>   */
>  static void
>  init_io_or(struct nvbios_init *init)
> @@ -878,9 +866,8 @@ init_io_or(struct nvbios_init *init)
> init_wrvgai(init, 0x03d4, index, data | (1 << or));
>  }
>
> -/**
> +/*
>   * INIT_ANDN_REG - opcode 0x47
> - *
>   */
>  static void
>  init_andn_reg(struct nvbios_init *init)
> @@ -895,9 +882,8 @@ init_andn_reg(struct nvbios_init *init)
> init_mask(init, reg, mask, 0);
>  }
>
> -/**
> +/*
>   * INIT_OR_REG - opcode 0x48
> - *
>   */
>  static void
>  init_or_reg(struct nvbios_init *init)
> @@ -912,9 +898,8 @@ init_or_reg(struct nvbios_init *init)
> init_mask(init, reg, 0, mask);
>  }
>
> -/**
> +/*
> 

[PATCH V3] drm/ast: Disable fast reset after DRAM initial

[KuoHsiang Chou]

[Bug][AST2500]

V1:
When AST2500 acts as stand-alone VGA so that DRAM and DVO initialization
have to be achieved by VGA driver with P2A (PCI to AHB) enabling.
However, HW suggests disable Fast reset mode after DRAM initializaton,
because fast reset mode is mainly designed for ARM ICE debugger.
Once Fast reset is checked as enabling, WDT (Watch Dog Timer) should be
first enabled to avoid system deadlock before disable fast reset mode.

V2:
Use to_pci_dev() to get revision of PCI configuration.

V3:
If SCU00 is not unlocked, just enter its password again.
It is unnecessary to clear AHB lock condition and restore WDT default
setting again, before Fast-reset clearing.

Signed-off-by: KuoHsiang Chou 
---
 drivers/gpu/drm/ast/ast_drv.h  |  1 +
 drivers/gpu/drm/ast/ast_main.c |  5 +++
 drivers/gpu/drm/ast/ast_post.c | 68 +-
 3 files changed, 48 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
index da6dfb677540..a2cf5fef2399 100644
--- a/drivers/gpu/drm/ast/ast_drv.h
+++ b/drivers/gpu/drm/ast/ast_drv.h
@@ -320,6 +320,7 @@ bool ast_is_vga_enabled(struct drm_device *dev);
 void ast_post_gpu(struct drm_device *dev);
 u32 ast_mindwm(struct ast_private *ast, u32 r);
 void ast_moutdwm(struct ast_private *ast, u32 r, u32 v);
+void ast_patch_ahb_2500(struct ast_private *ast);
 /* ast dp501 */
 void ast_set_dp501_video_output(struct drm_device *dev, u8 mode);
 bool ast_backup_fw(struct drm_device *dev, u8 *addr, u32 size);
diff --git a/drivers/gpu/drm/ast/ast_main.c b/drivers/gpu/drm/ast/ast_main.c
index 3775fe26f792..0e4dfcc25623 100644
--- a/drivers/gpu/drm/ast/ast_main.c
+++ b/drivers/gpu/drm/ast/ast_main.c
@@ -69,6 +69,7 @@ static void ast_detect_config_mode(struct drm_device *dev, 
u32 *scu_rev)
 {
struct device_node *np = dev->pdev->dev.of_node;
struct ast_private *ast = to_ast_private(dev);
+   struct pci_dev *pdev = to_pci_dev(dev->dev);
uint32_t data, jregd0, jregd1;

/* Defaults */
@@ -96,6 +97,10 @@ static void ast_detect_config_mode(struct drm_device *dev, 
u32 *scu_rev)
jregd0 = ast_get_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xd0, 0xff);
jregd1 = ast_get_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xd1, 0xff);
if (!(jregd0 & 0x80) || !(jregd1 & 0x10)) {
+   /* Patch AST2500 */
+   if (((pdev->revision & 0xF0) == 0x40) && ((jregd0 & 0xC0) == 0))
+   ast_patch_ahb_2500(ast);
+
/* Double check it's actually working */
data = ast_read32(ast, 0xf004);
if (data != 0x) {
diff --git a/drivers/gpu/drm/ast/ast_post.c b/drivers/gpu/drm/ast/ast_post.c
index 8902c2f84bf9..4f194c5fd2c2 100644
--- a/drivers/gpu/drm/ast/ast_post.c
+++ b/drivers/gpu/drm/ast/ast_post.c
@@ -2026,6 +2026,30 @@ static bool ast_dram_init_2500(struct ast_private *ast)
return true;
 }

+void ast_patch_ahb_2500(struct ast_private *ast)
+{
+   u32 data;
+
+   /* Clear bus lock condition */
+   ast_moutdwm(ast, 0x1e60, 0xAEED1A03);
+   ast_moutdwm(ast, 0x1e600084, 0x0001);
+   ast_moutdwm(ast, 0x1e600088, 0x);
+   ast_moutdwm(ast, 0x1e6e2000, 0x1688A8A8);
+   data = ast_mindwm(ast, 0x1e6e2070);
+   if (data & 0x0800) {/* 
check fast reset */
+
+   ast_moutdwm(ast, 0x1E785004, 0x0010);
+   ast_moutdwm(ast, 0x1E785008, 0x4755);
+   ast_moutdwm(ast, 0x1E78500c, 0x0033);
+   udelay(1000);
+   }
+   do {
+   ast_moutdwm(ast, 0x1e6e2000, 0x1688A8A8);
+   data = ast_mindwm(ast, 0x1e6e2000);
+   }   while (data != 1);
+   ast_moutdwm(ast, 0x1e6e207c, 0x0800);   /* clear fast reset */
+}
+
 void ast_post_chip_2500(struct drm_device *dev)
 {
struct ast_private *ast = to_ast_private(dev);
@@ -2033,39 +2057,31 @@ void ast_post_chip_2500(struct drm_device *dev)
u8 reg;

reg = ast_get_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xd0, 0xff);
-   if ((reg & 0x80) == 0) {/* vga only */
+   if ((reg & 0xC0) == 0) {/* vga only */
/* Clear bus lock condition */
-   ast_moutdwm(ast, 0x1e60, 0xAEED1A03);
-   ast_moutdwm(ast, 0x1e600084, 0x0001);
-   ast_moutdwm(ast, 0x1e600088, 0x);
-   ast_moutdwm(ast, 0x1e6e2000, 0x1688A8A8);
-   ast_write32(ast, 0xf004, 0x1e6e);
-   ast_write32(ast, 0xf000, 0x1);
-   ast_write32(ast, 0x12000, 0x1688a8a8);
-   while (ast_read32(ast, 0x12000) != 0x1)
-   ;
-
-   ast_write32(ast, 0x1, 0xfc600309);
-   while (ast_read32(ast, 0x1) != 0x1)
-   ;
+   ast_patch_ahb_2500(ast);
+
+   /* Disable watchdog */
+   ast_moutdwm(ast,