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

[Lionel Landwerlin]

On 13/06/2022 21:02, Niranjana Vishwanathapura wrote:

On Mon, Jun 13, 2022 at 06:33:07AM -0700, Zeng, Oak wrote:



Regards,
Oak


-Original Message-
From: Intel-gfx  On Behalf 
Of Niranjana

Vishwanathapura
Sent: June 10, 2022 1:43 PM
To: Landwerlin, Lionel G 
Cc: Intel GFX ; Maling list - DRI 
developers de...@lists.freedesktop.org>; Hellstrom, Thomas 
;

Wilson, Chris P ; Vetter, Daniel
; Christian König 
Subject: Re: [Intel-gfx] [RFC v3 1/3] drm/doc/rfc: VM_BIND feature 
design

document

On Fri, Jun 10, 2022 at 11:18:14AM +0300, Lionel Landwerlin wrote:
>On 10/06/2022 10:54, Niranjana Vishwanathapura wrote:
>>On Fri, Jun 10, 2022 at 09:53:24AM +0300, Lionel Landwerlin wrote:
>>>On 09/06/2022 22:31, Niranjana Vishwanathapura wrote:
On Thu, Jun 09, 2022 at 05:49:09PM +0300, Lionel Landwerlin wrote:
>  On 09/06/2022 00:55, Jason Ekstrand wrote:
>
>    On Wed, Jun 8, 2022 at 4:44 PM Niranjana Vishwanathapura
>  wrote:
>
>  On Wed, Jun 08, 2022 at 08:33:25AM +0100, Tvrtko Ursulin 
wrote:

>  >
>  >
>  >On 07/06/2022 22:32, Niranjana Vishwanathapura wrote:
>  >>On Tue, Jun 07, 2022 at 11:18:11AM -0700, Niranjana
>Vishwanathapura
>  wrote:
>  >>>On Tue, Jun 07, 2022 at 12:12:03PM -0500, Jason
>Ekstrand wrote:
>   On Fri, Jun 3, 2022 at 6:52 PM Niranjana 
Vishwanathapura

>    wrote:
>  
>     On Fri, Jun 03, 2022 at 10:20:25AM +0300, Lionel
>Landwerlin
>  wrote:
>     >   On 02/06/2022 23:35, Jason Ekstrand wrote:
>     >
>     > On Thu, Jun 2, 2022 at 3:11 PM Niranjana
>Vishwanathapura
>     >  wrote:
>     >
>     >   On Wed, Jun 01, 2022 at 01:28:36PM -0700, 
Matthew

>  Brost wrote:
>     >   >On Wed, Jun 01, 2022 at 05:25:49PM +0300, 
Lionel

>  Landwerlin
>     wrote:
>     > >> On 17/05/2022 21:32, Niranjana Vishwanathapura
>  wrote:
>     > >> > +VM_BIND/UNBIND ioctl will immediately start
>     binding/unbinding
>     >   the mapping in an
>     > >> > +async worker. The binding and
>unbinding will
>  work like a
>     special
>     >   GPU engine.
>     > >> > +The binding and unbinding operations are
>  serialized and
>     will
>     >   wait on specified
>     > >> > +input fences before the operation
>and will signal
>  the
>     output
>     >   fences upon the
>     > >> > +completion of the operation. Due to
>  serialization,
>     completion of
>     >   an operation
>     > >> > +will also indicate that all
>previous operations
>  are also
>     > complete.
>     > >>
>     > >> I guess we should avoid saying "will
>immediately
>  start
>     > binding/unbinding" if
>     > >> there are fences involved.
>     > >>
>     > >> And the fact that it's happening in an async
>  worker seem to
>     imply
>     >   it's not
>     > >> immediate.
>     > >>
>     >
>     >   Ok, will fix.
>     >   This was added because in earlier design
>binding was
>  deferred
>     until
>     >   next execbuff.
>     >   But now it is non-deferred (immediate in
>that sense).
>  But yah,
>     this is
>     > confusing
>     >   and will fix it.
>     >
>     > >>
>     > >> I have a question on the behavior of the bind
>  operation when
>     no
>     >   input fence
>     > >> is provided. Let say I do :
>     > >>
>     > >> VM_BIND (out_fence=fence1)
>     > >>
>     > >> VM_BIND (out_fence=fence2)
>     > >>
>     > >> VM_BIND (out_fence=fence3)
>     > >>
>     > >>
>     > >> In what order are the fences going to
>be signaled?
>     > >>
>     > >> In the order of VM_BIND ioctls? Or out
>of order?
>     > >>
>     > >> Because you wrote "serialized I assume
>it's : in
>  order
>     > >>
>     >
>     >   Yes, in the order of VM_BIND/UNBIND
>ioctls. Note that
>  bind and
>     unbind
>     >   will use
>     >   the same queue and hence are ordered.
>   

Re: [PATCH v3 0/3] KUnit tests for drm_format_helper

[Thomas Zimmermann]

Hi Jose,

for the whole patchset:

Acked-by: Thomas Zimmermann 

One small detail on licensing: drm_format_helper.c is licensed under 
GPL2 or MIT. Maybe consider adding 'or MIT' to drm_format_helper_test.c 
as well.


Best regards
Thomas

Am 13.06.22 um 19:17 schrieb José Expósito:

Hello everyone,

Here is the v3 of the series, including the documentation, previously
sent as a standalone patch [1], and changes suggested during review.

Thanks a lot,
José Expósito

RFC -> v1: 
https://lore.kernel.org/dri-devel/20220530102017.471865-1-jose.exposit...@gmail.com/T/

  - Add .kunitconfig (Maxime Ripard)
  - Fix memory leak (Daniel Latypov)
  - Make config option generic (Javier Martinez Canillas):
DRM_FORMAR_HELPER_TEST -> DRM_KUNIT_TEST
  - Remove DISABLE_STRUCTLEAK_PLUGIN (Daniel Latypov)

v1 -> v2: 
https://lore.kernel.org/dri-devel/20220606095516.938934-1-jose.exposit...@gmail.com/T/

  Thomas Zimmermann:
  - Add DRM_RECT_INIT() macro
  - Move tests to drivers/gpu/drm/kunit
  - Improve test documentation

v2 -> v3: 
https://lore.kernel.org/dri-devel/20220612161248.271590-1-jose.exposit...@gmail.com/T/

  - Use designated initializer in DRM_RECT_INIT (Jani Nikula)
  - Simplify the "conversion_buf_size" helper

[1] 
https://lore.kernel.org/dri-devel/20220606180940.43371-1-jose.exposit...@gmail.com/T/

José Expósito (3):
   drm/rect: Add DRM_RECT_INIT() macro
   drm/format-helper: Add KUnit tests for drm_fb_xrgb_to_rgb332()
   drm/doc: Add KUnit documentation

  Documentation/gpu/drm-internals.rst   |  32 
  drivers/gpu/drm/Kconfig   |  16 ++
  drivers/gpu/drm/Makefile  |   1 +
  drivers/gpu/drm/kunit/.kunitconfig|   3 +
  drivers/gpu/drm/kunit/Makefile|   3 +
  .../gpu/drm/kunit/drm_format_helper_test.c| 160 ++
  include/drm/drm_rect.h|  16 ++
  7 files changed, 231 insertions(+)
  create mode 100644 drivers/gpu/drm/kunit/.kunitconfig
  create mode 100644 drivers/gpu/drm/kunit/Makefile
  create mode 100644 drivers/gpu/drm/kunit/drm_format_helper_test.c



--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev


OpenPGP_signature
Description: OpenPGP digital signature

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

[Tvrtko Ursulin]

On 14/06/2022 00:39, Matthew Brost wrote:

On Mon, Jun 13, 2022 at 07:09:06PM +0100, Tvrtko Ursulin wrote:


On 13/06/2022 18:49, Niranjana Vishwanathapura wrote:

On Mon, Jun 13, 2022 at 05:22:02PM +0100, Tvrtko Ursulin wrote:


On 13/06/2022 16:05, Niranjana Vishwanathapura wrote:

On Mon, Jun 13, 2022 at 09:24:18AM +0100, Tvrtko Ursulin wrote:


On 10/06/2022 17:14, Niranjana Vishwanathapura wrote:

On Fri, Jun 10, 2022 at 05:48:39PM +0300, Lionel Landwerlin wrote:

On 10/06/2022 13:37, Tvrtko Ursulin wrote:


On 10/06/2022 08:07, Niranjana Vishwanathapura wrote:

VM_BIND and related uapi definitions

Signed-off-by: Niranjana Vishwanathapura

---
   Documentation/gpu/rfc/i915_vm_bind.h | 490
+++
   1 file changed, 490 insertions(+)
   create mode 100644 Documentation/gpu/rfc/i915_vm_bind.h

diff --git
a/Documentation/gpu/rfc/i915_vm_bind.h
b/Documentation/gpu/rfc/i915_vm_bind.h
new file mode 100644
index ..9fc854969cfb
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_vm_bind.h
@@ -0,0 +1,490 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+/**
+ * DOC: I915_PARAM_HAS_VM_BIND
+ *
+ * VM_BIND feature availability.
+ * See typedef drm_i915_getparam_t param.
+ * bit[0]: If set, VM_BIND is supported, otherwise not.
+ * bits[8-15]: VM_BIND implementation version.
+ * version 0 will not have VM_BIND/UNBIND
timeline fence array support.
+ */
+#define I915_PARAM_HAS_VM_BIND    57
+
+/**
+ * DOC: I915_VM_CREATE_FLAGS_USE_VM_BIND
+ *
+ * Flag to opt-in for VM_BIND mode of binding during VM creation.
+ * See struct drm_i915_gem_vm_control flags.
+ *
+ * The older execbuf2 ioctl will not
support VM_BIND mode of operation.
+ * For VM_BIND mode, we have new execbuf3
ioctl which will not accept any
+ * execlist (See struct
drm_i915_gem_execbuffer3 for more details).
+ *
+ */
+#define I915_VM_CREATE_FLAGS_USE_VM_BIND    (1 << 0)
+
+/**
+ * DOC: I915_CONTEXT_CREATE_FLAGS_LONG_RUNNING
+ *
+ * Flag to declare context as long running.
+ * See struct drm_i915_gem_context_create_ext flags.
+ *
+ * Usage of dma-fence expects that they
complete in reasonable amount of time.
+ * Compute on the other hand can be long
running. Hence it is not appropriate
+ * for compute contexts to export request
completion dma-fence to user.
+ * The dma-fence usage will be limited to
in-kernel consumption only.
+ * Compute contexts need to use user/memory fence.
+ *
+ * So, long running contexts do not support output fences. Hence,
+ * I915_EXEC_FENCE_SIGNAL (See
&drm_i915_gem_exec_fence.flags) is expected
+ * to be not used. DRM_I915_GEM_WAIT ioctl
call is also not supported for
+ * objects mapped to long running contexts.
+ */
+#define I915_CONTEXT_CREATE_FLAGS_LONG_RUNNING   (1u << 2)
+
+/* VM_BIND related ioctls */
+#define DRM_I915_GEM_VM_BIND    0x3d
+#define DRM_I915_GEM_VM_UNBIND    0x3e
+#define DRM_I915_GEM_EXECBUFFER3    0x3f
+#define DRM_I915_GEM_WAIT_USER_FENCE    0x40
+
+#define DRM_IOCTL_I915_GEM_VM_BIND
DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_VM_BIND, struct
drm_i915_gem_vm_bind)
+#define DRM_IOCTL_I915_GEM_VM_UNBIND
DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_VM_UNBIND, struct
drm_i915_gem_vm_bind)
+#define DRM_IOCTL_I915_GEM_EXECBUFFER3
DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_EXECBUFFER3, struct
drm_i915_gem_execbuffer3)
+#define DRM_IOCTL_I915_GEM_WAIT_USER_FENCE
DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_WAIT_USER_FENCE, struct
drm_i915_gem_wait_user_fence)
+
+/**
+ * struct drm_i915_gem_vm_bind - VA to object mapping to bind.
+ *
+ * This structure is passed to VM_BIND
ioctl and specifies the mapping of GPU
+ * virtual address (VA) range to the
section of an object that should be bound
+ * in the device page table of the specified address space (VM).
+ * The VA range specified must be unique
(ie., not currently bound) and can
+ * be mapped to whole object or a section
of the object (partial binding).
+ * Multiple VA mappings can be created to
the same section of the object
+ * (aliasing).
+ *
+ * The @queue_idx specifies the queue to
use for binding. Same queue can be
+ * used for both VM_BIND and VM_UNBIND
calls. All submitted bind and unbind
+ * operations in a queue are performed in the order of submission.
+ *
+ * The @start, @offset and @length should
be 4K page aligned. However the DG2
+ * and XEHPSDV has 64K page size for device
local-memory and has compact page
+ * table. On those platforms, for binding
device local-memory objects, the
+ * @start should be 2M aligned, @offset and
@length should be 64K aligned.
+ * Also, on those platforms, it is not
allowed to bind an device local-memory
+ * object and a system memory object in a
single 2M section of VA range.
+ */
+struct drm_i915_gem_vm_bind {
+    /** @vm_id: VM (address space) id to bind */
+    __u32 vm_id;
+
+    /** @queue_idx: Index of queue for binding */
+    __u32 queue_idx;


I have a question here to which I did not find
an answer by browsing the old threads.

Queue ind

Re: [PATCH 09/19] drm/gma500: Unify *_intel_lvds_mode_fixup()

[Thomas Zimmermann]

Hi

Am 13.06.22 um 14:34 schrieb Patrik Jakobsson:

These functions mostly do the same thing so unify them. Change a check
of !IS_MRST() to IS_PSB() to not change the behaviour for CDV.

Signed-off-by: Patrik Jakobsson 
---
  drivers/gpu/drm/gma500/cdv_intel_lvds.c | 51 +--
  drivers/gpu/drm/gma500/gma_lvds.c   | 59 ++
  drivers/gpu/drm/gma500/gma_lvds.h   |  3 ++
  drivers/gpu/drm/gma500/oaktrail_lvds.c  |  2 +-
  drivers/gpu/drm/gma500/psb_intel_lvds.c | 65 +
  5 files changed, 65 insertions(+), 115 deletions(-)

diff --git a/drivers/gpu/drm/gma500/cdv_intel_lvds.c 
b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
index 61dc65964e21..65532308f1e7 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_lvds.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
@@ -39,55 +39,6 @@
  #define PSB_BACKLIGHT_PWM_CTL_SHIFT   (16)
  #define PSB_BACKLIGHT_PWM_POLARITY_BIT_CLEAR (0xFFFE)
  
-static bool cdv_intel_lvds_mode_fixup(struct drm_encoder *encoder,

- const struct drm_display_mode *mode,
- struct drm_display_mode *adjusted_mode)
-{
-   struct drm_device *dev = encoder->dev;
-   struct drm_psb_private *dev_priv = to_drm_psb_private(dev);
-   struct psb_intel_mode_device *mode_dev = &dev_priv->mode_dev;
-   struct drm_encoder *tmp_encoder;
-   struct drm_display_mode *panel_fixed_mode = mode_dev->panel_fixed_mode;
-
-   /* Should never happen!! */
-   list_for_each_entry(tmp_encoder, &dev->mode_config.encoder_list,
-   head) {
-   if (tmp_encoder != encoder
-   && tmp_encoder->crtc == encoder->crtc) {
-   pr_err("Can't enable LVDS and another encoder on the same 
pipe\n");
-   return false;
-   }
-   }
-
-   /*
-* If we have timings from the BIOS for the panel, put them in
-* to the adjusted mode.  The CRTC will be set up for this mode,
-* with the panel scaling set up to source from the H/VDisplay
-* of the original mode.
-*/
-   if (panel_fixed_mode != NULL) {
-   adjusted_mode->hdisplay = panel_fixed_mode->hdisplay;
-   adjusted_mode->hsync_start = panel_fixed_mode->hsync_start;
-   adjusted_mode->hsync_end = panel_fixed_mode->hsync_end;
-   adjusted_mode->htotal = panel_fixed_mode->htotal;
-   adjusted_mode->vdisplay = panel_fixed_mode->vdisplay;
-   adjusted_mode->vsync_start = panel_fixed_mode->vsync_start;
-   adjusted_mode->vsync_end = panel_fixed_mode->vsync_end;
-   adjusted_mode->vtotal = panel_fixed_mode->vtotal;
-   adjusted_mode->clock = panel_fixed_mode->clock;
-   drm_mode_set_crtcinfo(adjusted_mode,
- CRTC_INTERLACE_HALVE_V);
-   }
-
-   /*
-* XXX: It would be nice to support lower refresh rates on the
-* panels to reduce power consumption, and perhaps match the
-* user's requested refresh rate.
-*/
-
-   return true;
-}
-
  static void cdv_intel_lvds_prepare(struct drm_encoder *encoder)
  {
struct drm_device *dev = encoder->dev;
@@ -255,7 +206,7 @@ static int cdv_intel_lvds_set_property(struct drm_connector 
*connector,
  static const struct drm_encoder_helper_funcs
cdv_intel_lvds_helper_funcs = {
.dpms = gma_lvds_encoder_dpms,
-   .mode_fixup = cdv_intel_lvds_mode_fixup,
+   .mode_fixup = gma_lvds_mode_fixup,
.prepare = cdv_intel_lvds_prepare,
.mode_set = cdv_intel_lvds_mode_set,
.commit = cdv_intel_lvds_commit,
diff --git a/drivers/gpu/drm/gma500/gma_lvds.c 
b/drivers/gpu/drm/gma500/gma_lvds.c
index 19679ee36062..32ecf5835828 100644
--- a/drivers/gpu/drm/gma500/gma_lvds.c
+++ b/drivers/gpu/drm/gma500/gma_lvds.c
@@ -209,3 +209,62 @@ void gma_lvds_restore(struct drm_connector *connector)
}
  }
  
+bool gma_lvds_mode_fixup(struct drm_encoder *encoder,

+const struct drm_display_mode *mode,
+struct drm_display_mode *adjusted_mode)
+{
+   struct drm_device *dev = encoder->dev;
+   struct drm_psb_private *dev_priv = to_drm_psb_private(dev);
+   struct psb_intel_mode_device *mode_dev = &dev_priv->mode_dev;
+   struct gma_crtc *gma_crtc = to_gma_crtc(encoder->crtc);
+   struct drm_encoder *tmp_encoder;
+   struct drm_display_mode *panel_fixed_mode = mode_dev->panel_fixed_mode;
+
+   /* PSB requires the LVDS is on pipe B, MRST has only one pipe anyway */
+   if (IS_PSB(dev) && gma_crtc->pipe == 0) {
+   pr_err("Can't support LVDS on pipe A\n");
+   return false;
+   }
+   if (IS_MRST(dev) && gma_crtc->pipe != 0) {
+   pr_err("Must use PIPE A\n");
+   return false;
+   }


In my exp

Re: [PATCH 13/19] drm/gma500: Unify struct *_intel_lvds_helper_funcs

[Thomas Zimmermann]

Hi

Am 13.06.22 um 14:34 schrieb Patrik Jakobsson:

These now only contains generic gma functions so create
gma_lvds_helper_funcs that both PSB and CDV can use. Oaktrail still
needs the modeset callback refactored to align with PSB and CDV.

Signed-off-by: Patrik Jakobsson 
---
  drivers/gpu/drm/gma500/cdv_intel_lvds.c | 11 +--
  drivers/gpu/drm/gma500/gma_lvds.c   | 14 +++---
  drivers/gpu/drm/gma500/gma_lvds.h   |  5 ++---
  drivers/gpu/drm/gma500/psb_intel_lvds.c | 10 +-
  4 files changed, 15 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/gma500/cdv_intel_lvds.c 
b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
index ddfb976b6059..80ccc00c47e5 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_lvds.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
@@ -136,15 +136,6 @@ static int cdv_intel_lvds_set_property(struct 
drm_connector *connector,
return 0;
  }
  
-static const struct drm_encoder_helper_funcs

-   cdv_intel_lvds_helper_funcs = {
-   .dpms = gma_lvds_encoder_dpms,
-   .mode_fixup = gma_lvds_mode_fixup,
-   .prepare = gma_lvds_prepare,
-   .mode_set = gma_lvds_mode_set,
-   .commit = gma_lvds_commit,
-};
-
  static const struct drm_connector_helper_funcs
cdv_intel_lvds_connector_helper_funcs = {
.get_modes = cdv_intel_lvds_get_modes,
@@ -286,7 +277,7 @@ void cdv_intel_lvds_init(struct drm_device *dev,
gma_connector_attach_encoder(gma_connector, gma_encoder);
gma_encoder->type = INTEL_OUTPUT_LVDS;
  
-	drm_encoder_helper_add(encoder, &cdv_intel_lvds_helper_funcs);

+   drm_encoder_helper_add(encoder, &gma_lvds_helper_funcs);
drm_connector_helper_add(connector,
 &cdv_intel_lvds_connector_helper_funcs);
connector->display_info.subpixel_order = SubPixelHorizontalRGB;
diff --git a/drivers/gpu/drm/gma500/gma_lvds.c 
b/drivers/gpu/drm/gma500/gma_lvds.c
index 215bf8f7d41f..bf9fa5ebdbd3 100644
--- a/drivers/gpu/drm/gma500/gma_lvds.c
+++ b/drivers/gpu/drm/gma500/gma_lvds.c
@@ -299,9 +299,9 @@ void gma_lvds_commit(struct drm_encoder *encoder)
gma_lvds_set_power(dev, true);
  }
  
-void gma_lvds_mode_set(struct drm_encoder *encoder,

-  struct drm_display_mode *mode,
-  struct drm_display_mode *adjusted_mode)
+static void gma_lvds_mode_set(struct drm_encoder *encoder,
+ struct drm_display_mode *mode,
+ struct drm_display_mode *adjusted_mode)
  {
struct drm_device *dev = encoder->dev;
struct drm_psb_private *dev_priv = to_drm_psb_private(dev);
@@ -334,3 +334,11 @@ void gma_lvds_mode_set(struct drm_encoder *encoder,
REG_WRITE(PFIT_CONTROL, pfit_control);
  }
  
+const struct drm_encoder_helper_funcs gma_lvds_helper_funcs = {

+   .dpms = gma_lvds_encoder_dpms,
+   .mode_fixup = gma_lvds_mode_fixup,
+   .prepare = gma_lvds_prepare,
+   .mode_set = gma_lvds_mode_set,
+   .commit = gma_lvds_commit,
+};
+


Alternatively, you could use an initializer macro, such as

#define GMA_LVDS_HELPER_FUNCS \
  .dpms = ..
  .mode_fixup = ...
  ...

and use it to initialize the per-model model instances. This would allow 
to keep each instance as 'static const'.  The linker should be able to 
sort out duplicates.


Best regards
Thomas


diff --git a/drivers/gpu/drm/gma500/gma_lvds.h 
b/drivers/gpu/drm/gma500/gma_lvds.h
index ebba869a25b7..3c47bea859ad 100644
--- a/drivers/gpu/drm/gma500/gma_lvds.h
+++ b/drivers/gpu/drm/gma500/gma_lvds.h
@@ -34,8 +34,7 @@ bool gma_lvds_mode_fixup(struct drm_encoder *encoder,
 struct drm_display_mode *adjusted_mode);
  void gma_lvds_prepare(struct drm_encoder *encoder);
  void gma_lvds_commit(struct drm_encoder *encoder);
-void gma_lvds_mode_set(struct drm_encoder *encoder,
-  struct drm_display_mode *mode,
-  struct drm_display_mode *adjusted_mode);
+
+extern const struct drm_encoder_helper_funcs gma_lvds_helper_funcs;
  
  #endif

diff --git a/drivers/gpu/drm/gma500/psb_intel_lvds.c 
b/drivers/gpu/drm/gma500/psb_intel_lvds.c
index 553f6cb5f322..29a9b4ea5803 100644
--- a/drivers/gpu/drm/gma500/psb_intel_lvds.c
+++ b/drivers/gpu/drm/gma500/psb_intel_lvds.c
@@ -236,14 +236,6 @@ int psb_intel_lvds_set_property(struct drm_connector 
*connector,
return -1;
  }
  
-static const struct drm_encoder_helper_funcs psb_intel_lvds_helper_funcs = {

-   .dpms = gma_lvds_encoder_dpms,
-   .mode_fixup = gma_lvds_mode_fixup,
-   .prepare = gma_lvds_prepare,
-   .mode_set = gma_lvds_mode_set,
-   .commit = gma_lvds_commit,
-};
-
  const struct drm_connector_helper_funcs
psb_intel_lvds_connector_helper_funcs = {
.get_modes = psb_intel_lvds_get_modes,
@@ -329,7 +321,7 @@ void psb_intel_lvds_init(struct drm_device *dev,
gma_connect

[PATCH 2/2] ARM: dts: sun8i: Add R16 Vista E board from RenewWorldOutreach

[Suniel Mahesh]

The R16-Vista-E board from RenewWorldOutreach based on allwinner
R16(A33).

General features:
- 1GB RAM
- microSD slot
- Realtek Wifi
- 1 x USB 2.0
- HDMI IN
- HDMI OUT
- Audio out
- MIPI DSI
- TI DLPC3433

It has also connectors to connect an external mini keypad.

Signed-off-by: Suniel Mahesh 
---
 arch/arm/boot/dts/Makefile|   1 +
 arch/arm/boot/dts/sun8i-r16-renew-vista-e.dts | 361 ++
 2 files changed, 362 insertions(+)
 create mode 100644 arch/arm/boot/dts/sun8i-r16-renew-vista-e.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 184899808ee7..b5966c0742e1 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -1353,6 +1353,7 @@ dtb-$(CONFIG_MACH_SUN8I) += \
sun8i-r16-nintendo-nes-classic.dtb \
sun8i-r16-nintendo-super-nes-classic.dtb \
sun8i-r16-parrot.dtb \
+   sun8i-r16-renew-vista-e.dtb \
sun8i-r40-bananapi-m2-ultra.dtb \
sun8i-r40-oka40i-c.dtb \
sun8i-s3-elimo-initium.dtb \
diff --git a/arch/arm/boot/dts/sun8i-r16-renew-vista-e.dts 
b/arch/arm/boot/dts/sun8i-r16-renew-vista-e.dts
new file mode 100644
index ..a762fbd69773
--- /dev/null
+++ b/arch/arm/boot/dts/sun8i-r16-renew-vista-e.dts
@@ -0,0 +1,361 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2022 RenewWorldOutreach
+ * Copyright (C) 2022 Amarula Solutions(India)
+ */
+
+/dts-v1/;
+#include "sun8i-a33.dtsi"
+
+#include 
+#include 
+#include 
+
+/ {
+   model = "RenewWorldOutreach R16-Vista-E";
+   compatible = "renewworldoutreach,r16-vista-e", "allwinner,sun8i-a33";
+
+   aliases {
+   serial0 = &uart0;
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   gpio-keys-polled {
+   compatible = "gpio-keys-polled";
+   poll-interval = <100>;
+
+   ok {
+   label = "ok";
+   linux,code = ;
+   gpios = <&pio 4 0 GPIO_ACTIVE_LOW>;
+   };
+
+   left {
+   label = "left";
+   linux,code = ;
+   gpios = <&pio 4 1 GPIO_ACTIVE_LOW>;
+   };
+
+   right {
+   label = "right";
+   linux,code = ;
+   gpios = <&pio 4 2 GPIO_ACTIVE_LOW>;
+   };
+
+   up {
+   label = "up";
+   linux,code = ;
+   gpios = <&pio 4 3 GPIO_ACTIVE_LOW>;
+   };
+
+   down {
+   label = "down";
+   linux,code = ;
+   gpios = <&pio 4 4 GPIO_ACTIVE_LOW>;
+   };
+
+   back {
+   label = "back";
+   linux,code = ;
+   gpios = <&pio 4 5 GPIO_ACTIVE_LOW>;
+   };
+
+   power {
+   label = "power";
+   linux,code = ;
+   gpios = <&pio 4 6 GPIO_ACTIVE_LOW>;
+   };
+
+   vol-down {
+   label = "vol-down";
+   linux,code = ;
+   gpios = <&pio 7 3 GPIO_ACTIVE_LOW>;
+   };
+
+   vol-up {
+   label = "vol-up";
+   linux,code = ;
+   gpios = <&pio 7 9 GPIO_ACTIVE_LOW>;
+   };
+   };
+
+   leds {
+   compatible = "gpio-leds";
+
+   battery-led0 {
+   label = "renew-e:battery-led0";
+   gpios = <&r_pio 0 2 GPIO_ACTIVE_HIGH>;
+   };
+
+   battery-led1 {
+   label = "renew-e:battery-led1";
+   gpios = <&r_pio 0 3 GPIO_ACTIVE_HIGH>;
+   };
+
+   battery-led2 {
+   label = "renew-e:battery-led2";
+   gpios = <&r_pio 0 4 GPIO_ACTIVE_HIGH>;
+   };
+
+   battery-led3 {
+   label = "renew-e:battery-led3";
+   gpios = <&r_pio 0 5 GPIO_ACTIVE_HIGH>;
+   };
+
+   pad-intz {
+   label = "renew-e:pad-intz";
+   gpios = <&pio 4 16 GPIO_ACTIVE_HIGH>;
+   default-state = "on";
+   };
+
+   battery-led4 {
+   label = "renew-e:battery-led4";
+   gpios = <&r_pio 0 6 GPIO_ACTIVE_HIGH>;
+   };
+
+   volume-led0 {
+label = "renew-e:volume-led0";
+gpios = <&pio 7 2 GPIO_ACTIVE_HIGH>;
+};
+
+   volume-led1 {
+   label = "renew-e:volume-led1";
+   gpios = <&pio 6 13 GPIO_ACTIVE_

[PATCH 1/2] dt-bindings: arm: sunxi: Add binding for RenewWorldOutReach R16-Vista-E board

[Suniel Mahesh]

Add a binding for the RenewWorldOutReach R16-Vista-E board based on
allwinner R16.

Signed-off-by: Suniel Mahesh 
---
 Documentation/devicetree/bindings/arm/sunxi.yaml | 5 +
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml 
b/Documentation/devicetree/bindings/arm/sunxi.yaml
index 95278a6a9a8e..29c789969f1f 100644
--- a/Documentation/devicetree/bindings/arm/sunxi.yaml
+++ b/Documentation/devicetree/bindings/arm/sunxi.yaml
@@ -787,6 +787,11 @@ properties:
   - const: allwinner,r7-tv-dongle
   - const: allwinner,sun5i-a10s
 
+  - description: RenewWorldOutreach R16-Vista-E
+items:
+  - const: renewworldoutreach,r16-vista-e
+  - const: allwinner,sun8i-a33
+
   - description: RerVision H3-DVK
 items:
   - const: rervision,h3-dvk
-- 
2.25.1

[PATCH] drm/sun4i: dw-hdmi: Fix ddc-en GPIO consumer conflict

[Samuel Holland]

commit 6de79dd3a920 ("drm/bridge: display-connector: add ddc-en gpio
support") added a consumer for this GPIO in the HDMI connector device.
This new consumer conflicts with the pre-existing GPIO consumer in the
sun8i HDMI controller driver, which prevents the driver from probing:

  [4.983358] display-connector connector: GPIO lookup for consumer ddc-en
  [4.983364] display-connector connector: using device tree for GPIO lookup
  [4.983392] gpio-226 (ddc-en): gpiod_request: status -16
  [4.983399] sun8i-dw-hdmi 600.hdmi: Couldn't get ddc-en gpio
  [4.983618] sun4i-drm display-engine: failed to bind 600.hdmi (ops 
sun8i_dw_hdmi_ops [sun8i_drm_hdmi]): -16
  [4.984082] sun4i-drm display-engine: Couldn't bind all pipelines 
components
  [4.984171] sun4i-drm display-engine: adev bind failed: -16
  [4.984179] sun8i-dw-hdmi: probe of 600.hdmi failed with error -16

Both drivers have the same behavior: they leave the GPIO active for the
life of the device. Let's take advantage of the new implementation, and
drop the now-obsolete code from the HDMI controller driver.

Fixes: 6de79dd3a920 ("drm/bridge: display-connector: add ddc-en gpio support")
Signed-off-by: Samuel Holland 
---

 drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 54 ++-
 drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h |  2 -
 2 files changed, 4 insertions(+), 52 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c 
b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
index a8d75fd7e9f4..477cb6985b4d 100644
--- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
+++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
@@ -93,34 +93,10 @@ static u32 sun8i_dw_hdmi_find_possible_crtcs(struct 
drm_device *drm,
return crtcs;
 }
 
-static int sun8i_dw_hdmi_find_connector_pdev(struct device *dev,
-struct platform_device **pdev_out)
-{
-   struct platform_device *pdev;
-   struct device_node *remote;
-
-   remote = of_graph_get_remote_node(dev->of_node, 1, -1);
-   if (!remote)
-   return -ENODEV;
-
-   if (!of_device_is_compatible(remote, "hdmi-connector")) {
-   of_node_put(remote);
-   return -ENODEV;
-   }
-
-   pdev = of_find_device_by_node(remote);
-   of_node_put(remote);
-   if (!pdev)
-   return -ENODEV;
-
-   *pdev_out = pdev;
-   return 0;
-}
-
 static int sun8i_dw_hdmi_bind(struct device *dev, struct device *master,
  void *data)
 {
-   struct platform_device *pdev = to_platform_device(dev), *connector_pdev;
+   struct platform_device *pdev = to_platform_device(dev);
struct dw_hdmi_plat_data *plat_data;
struct drm_device *drm = data;
struct device_node *phy_node;
@@ -167,30 +143,16 @@ static int sun8i_dw_hdmi_bind(struct device *dev, struct 
device *master,
return dev_err_probe(dev, PTR_ERR(hdmi->regulator),
 "Couldn't get regulator\n");
 
-   ret = sun8i_dw_hdmi_find_connector_pdev(dev, &connector_pdev);
-   if (!ret) {
-   hdmi->ddc_en = gpiod_get_optional(&connector_pdev->dev,
- "ddc-en", GPIOD_OUT_HIGH);
-   platform_device_put(connector_pdev);
-
-   if (IS_ERR(hdmi->ddc_en)) {
-   dev_err(dev, "Couldn't get ddc-en gpio\n");
-   return PTR_ERR(hdmi->ddc_en);
-   }
-   }
-
ret = regulator_enable(hdmi->regulator);
if (ret) {
dev_err(dev, "Failed to enable regulator\n");
-   goto err_unref_ddc_en;
+   return ret;
}
 
-   gpiod_set_value(hdmi->ddc_en, 1);
-
ret = reset_control_deassert(hdmi->rst_ctrl);
if (ret) {
dev_err(dev, "Could not deassert ctrl reset control\n");
-   goto err_disable_ddc_en;
+   goto err_disable_regulator;
}
 
ret = clk_prepare_enable(hdmi->clk_tmds);
@@ -245,12 +207,8 @@ static int sun8i_dw_hdmi_bind(struct device *dev, struct 
device *master,
clk_disable_unprepare(hdmi->clk_tmds);
 err_assert_ctrl_reset:
reset_control_assert(hdmi->rst_ctrl);
-err_disable_ddc_en:
-   gpiod_set_value(hdmi->ddc_en, 0);
+err_disable_regulator:
regulator_disable(hdmi->regulator);
-err_unref_ddc_en:
-   if (hdmi->ddc_en)
-   gpiod_put(hdmi->ddc_en);
 
return ret;
 }
@@ -264,11 +222,7 @@ static void sun8i_dw_hdmi_unbind(struct device *dev, 
struct device *master,
sun8i_hdmi_phy_deinit(hdmi->phy);
clk_disable_unprepare(hdmi->clk_tmds);
reset_control_assert(hdmi->rst_ctrl);
-   gpiod_set_value(hdmi->ddc_en, 0);
regulator_disable(hdmi->regulator);
-
-   if (hdmi->ddc_en)
-   gpiod_put(hdmi->ddc_en);
 }
 
 static const struct component_ops sun8i_dw_hdmi_ops = {
diff --git a/drivers/gpu/drm/

Re: [PATCH 15/19] drm/gma500: Unify struct *_intel_lvds_connector_helper_funcs

[Thomas Zimmermann]

Hi Patrik

Am 13.06.22 um 14:34 schrieb Patrik Jakobsson:

These now only contains generic gma functions so create
gma_lvds_connector_helper_funcs that all chips can use.

Signed-off-by: Patrik Jakobsson 
---
  drivers/gpu/drm/gma500/cdv_intel_lvds.c | 10 +-
  drivers/gpu/drm/gma500/gma_lvds.c   | 12 +---
  drivers/gpu/drm/gma500/gma_lvds.h   |  4 +---
  drivers/gpu/drm/gma500/oaktrail_lvds.c  |  3 +--
  drivers/gpu/drm/gma500/psb_intel_lvds.c | 10 +-
  5 files changed, 13 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/gma500/cdv_intel_lvds.c 
b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
index a6f94572baaf..2ba635513401 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_lvds.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
@@ -111,13 +111,6 @@ static int cdv_intel_lvds_set_property(struct 
drm_connector *connector,
return 0;
  }
  
-static const struct drm_connector_helper_funcs

-   cdv_intel_lvds_connector_helper_funcs = {
-   .get_modes = gma_lvds_get_modes,
-   .mode_valid = gma_lvds_mode_valid,
-   .best_encoder = gma_best_encoder,
-};
-
  static const struct drm_connector_funcs cdv_intel_lvds_connector_funcs = {
.dpms = drm_helper_connector_dpms,
.fill_modes = drm_helper_probe_single_connector_modes,
@@ -253,8 +246,7 @@ void cdv_intel_lvds_init(struct drm_device *dev,
gma_encoder->type = INTEL_OUTPUT_LVDS;
  
  	drm_encoder_helper_add(encoder, &gma_lvds_helper_funcs);

-   drm_connector_helper_add(connector,
-&cdv_intel_lvds_connector_helper_funcs);
+   drm_connector_helper_add(connector, &gma_lvds_connector_helper_funcs);
connector->display_info.subpixel_order = SubPixelHorizontalRGB;
connector->interlace_allowed = false;
connector->doublescan_allowed = false;
diff --git a/drivers/gpu/drm/gma500/gma_lvds.c 
b/drivers/gpu/drm/gma500/gma_lvds.c
index 49c11b5337cb..3b48999105d1 100644
--- a/drivers/gpu/drm/gma500/gma_lvds.c
+++ b/drivers/gpu/drm/gma500/gma_lvds.c
@@ -94,8 +94,8 @@ static void gma_lvds_set_power(struct drm_device *dev, bool 
on)
gma_power_end(dev);
  }
  
-enum drm_mode_status gma_lvds_mode_valid(struct drm_connector *connector,

-struct drm_display_mode *mode)
+static enum drm_mode_status gma_lvds_mode_valid(struct drm_connector 
*connector,
+   struct drm_display_mode *mode)
  {
struct drm_device *dev = connector->dev;
struct drm_psb_private *dev_priv = to_drm_psb_private(dev);
@@ -345,7 +345,7 @@ const struct drm_encoder_helper_funcs gma_lvds_helper_funcs 
= {
  /*
   * Return the list of DDC modes if available, or the BIOS fixed mode 
otherwise.
   */
-int gma_lvds_get_modes(struct drm_connector *connector)
+static int gma_lvds_get_modes(struct drm_connector *connector)
  {
struct drm_device *dev = connector->dev;
struct drm_psb_private *dev_priv = to_drm_psb_private(dev);
@@ -368,3 +368,9 @@ int gma_lvds_get_modes(struct drm_connector *connector)
return 0;
  }
  
+const struct drm_connector_helper_funcs gma_lvds_connector_helper_funcs = {

+   .get_modes = gma_lvds_get_modes,
+   .mode_valid = gma_lvds_mode_valid,
+   .best_encoder = gma_best_encoder,
+};


Same suggestion as for pathc 13.

Best regards
Thomas


+
diff --git a/drivers/gpu/drm/gma500/gma_lvds.h 
b/drivers/gpu/drm/gma500/gma_lvds.h
index 70c416d8b7a7..5c7da22400fb 100644
--- a/drivers/gpu/drm/gma500/gma_lvds.h
+++ b/drivers/gpu/drm/gma500/gma_lvds.h
@@ -24,8 +24,6 @@ struct gma_lvds_priv {
  };
  
  u32 gma_lvds_get_max_backlight(struct drm_device *dev);

-enum drm_mode_status gma_lvds_mode_valid(struct drm_connector *connector,
-struct drm_display_mode *mode);
  void gma_lvds_encoder_dpms(struct drm_encoder *encoder, int mode);
  void gma_lvds_save(struct drm_connector *connector);
  void gma_lvds_restore(struct drm_connector *connector);
@@ -34,8 +32,8 @@ bool gma_lvds_mode_fixup(struct drm_encoder *encoder,
 struct drm_display_mode *adjusted_mode);
  void gma_lvds_prepare(struct drm_encoder *encoder);
  void gma_lvds_commit(struct drm_encoder *encoder);
-int gma_lvds_get_modes(struct drm_connector *connector);
  
  extern const struct drm_encoder_helper_funcs gma_lvds_helper_funcs;

+extern const struct drm_connector_helper_funcs gma_lvds_connector_helper_funcs;
  
  #endif

diff --git a/drivers/gpu/drm/gma500/oaktrail_lvds.c 
b/drivers/gpu/drm/gma500/oaktrail_lvds.c
index 85cab0f7028a..7724ebd71aa8 100644
--- a/drivers/gpu/drm/gma500/oaktrail_lvds.c
+++ b/drivers/gpu/drm/gma500/oaktrail_lvds.c
@@ -230,8 +230,7 @@ void oaktrail_lvds_init(struct drm_device *dev,
gma_encoder->type = INTEL_OUTPUT_LVDS;
  
  	drm_encoder_helper_add(encoder, &oaktrail_lvds_helper_funcs);

-   drm_connector_helper_add(connector,
-

Re: [PATCH 19/19] drm/gma500: Unify struct *_intel_lvds_connector_funcs

[Thomas Zimmermann]

Hi

Am 13.06.22 um 14:34 schrieb Patrik Jakobsson:

These now only contains generic drm/gma functions so create
gma_lvds_connector_funcs that all chips can use.

Signed-off-by: Patrik Jakobsson 
---
  drivers/gpu/drm/gma500/cdv_intel_lvds.c |  9 +
  drivers/gpu/drm/gma500/gma_lvds.c   | 15 +++
  drivers/gpu/drm/gma500/gma_lvds.h   |  4 +---
  drivers/gpu/drm/gma500/oaktrail_lvds.c  |  2 +-
  drivers/gpu/drm/gma500/psb_intel_lvds.c |  9 +
  5 files changed, 15 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/gma500/cdv_intel_lvds.c 
b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
index ccb489d6795b..0b8f818ca9b5 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_lvds.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
@@ -39,13 +39,6 @@
  #define PSB_BACKLIGHT_PWM_CTL_SHIFT   (16)
  #define PSB_BACKLIGHT_PWM_POLARITY_BIT_CLEAR (0xFFFE)
  
-static const struct drm_connector_funcs cdv_intel_lvds_connector_funcs = {

-   .dpms = drm_helper_connector_dpms,
-   .fill_modes = drm_helper_probe_single_connector_modes,
-   .set_property = gma_lvds_set_property,
-   .destroy = gma_lvds_destroy,
-};
-
  /*
   * Enumerate the child dev array parsed from VBT to check whether
   * the LVDS is present.
@@ -160,7 +153,7 @@ void cdv_intel_lvds_init(struct drm_device *dev,
}
  
  	ret = drm_connector_init_with_ddc(dev, connector,

- &cdv_intel_lvds_connector_funcs,
+ &gma_lvds_connector_funcs,
  DRM_MODE_CONNECTOR_LVDS,
  &ddc_bus->base);
if (ret)
diff --git a/drivers/gpu/drm/gma500/gma_lvds.c 
b/drivers/gpu/drm/gma500/gma_lvds.c
index e4278d26f811..612013baf7ad 100644
--- a/drivers/gpu/drm/gma500/gma_lvds.c
+++ b/drivers/gpu/drm/gma500/gma_lvds.c
@@ -374,7 +374,7 @@ const struct drm_connector_helper_funcs 
gma_lvds_connector_helper_funcs = {
.best_encoder = gma_best_encoder,
  };
  
-void gma_lvds_destroy(struct drm_connector *connector)

+static void gma_lvds_destroy(struct drm_connector *connector)
  {
struct gma_connector *gma_connector = to_gma_connector(connector);
struct gma_encoder *gma_encoder = gma_attached_encoder(connector);
@@ -389,9 +389,9 @@ void gma_lvds_destroy(struct drm_connector *connector)
kfree(gma_connector);
  }
  
-int gma_lvds_set_property(struct drm_connector *connector,

- struct drm_property *property,
- uint64_t value)
+static int gma_lvds_set_property(struct drm_connector *connector,
+struct drm_property *property,
+uint64_t value)
  {
struct drm_encoder *encoder = connector->encoder;
  
@@ -453,3 +453,10 @@ int gma_lvds_set_property(struct drm_connector *connector,

return 0;
  }
  
+const struct drm_connector_funcs gma_lvds_connector_funcs = {

+   .dpms = drm_helper_connector_dpms,
+   .fill_modes = drm_helper_probe_single_connector_modes,
+   .set_property = gma_lvds_set_property,
+   .destroy = gma_lvds_destroy,
+};


Again, same suggestion as for patch 13.


+
diff --git a/drivers/gpu/drm/gma500/gma_lvds.h 
b/drivers/gpu/drm/gma500/gma_lvds.h
index ea261a60e9ff..bcb2efa7a1b5 100644
--- a/drivers/gpu/drm/gma500/gma_lvds.h
+++ b/drivers/gpu/drm/gma500/gma_lvds.h
@@ -30,11 +30,9 @@ bool gma_lvds_mode_fixup(struct drm_encoder *encoder,
 struct drm_display_mode *adjusted_mode);
  void gma_lvds_prepare(struct drm_encoder *encoder);
  void gma_lvds_commit(struct drm_encoder *encoder);
-void gma_lvds_destroy(struct drm_connector *connector);
-int gma_lvds_set_property(struct drm_connector *connector,
- struct drm_property *property, uint64_t value);
  
  extern const struct drm_encoder_helper_funcs gma_lvds_helper_funcs;

  extern const struct drm_connector_helper_funcs 
gma_lvds_connector_helper_funcs;
+extern const struct drm_connector_funcs gma_lvds_connector_funcs;
  
  #endif

diff --git a/drivers/gpu/drm/gma500/oaktrail_lvds.c 
b/drivers/gpu/drm/gma500/oaktrail_lvds.c
index 7724ebd71aa8..ea2745116f92 100644
--- a/drivers/gpu/drm/gma500/oaktrail_lvds.c
+++ b/drivers/gpu/drm/gma500/oaktrail_lvds.c
@@ -217,7 +217,7 @@ void oaktrail_lvds_init(struct drm_device *dev,
encoder = &gma_encoder->base;
dev_priv->is_lvds_on = true;
ret = drm_connector_init(dev, connector,
-&psb_intel_lvds_connector_funcs,
+&gma_lvds_connector_funcs,
 DRM_MODE_CONNECTOR_LVDS);
if (ret)
goto err_free_connector;
diff --git a/drivers/gpu/drm/gma500/psb_intel_lvds.c 
b/drivers/gpu/drm/gma500/psb_intel_lvds.c
index df2e770c660a..4d9b9b45525f 100644
--- a/drivers/gpu/drm/gma500/psb_intel_lvds.c
+++ b/drivers/gpu/drm/gma500/psb_intel_lvds.c
@@ 

Re: [PATCH 00/19] drm/gma500: Unify most of the lvds code

[Thomas Zimmermann]

Hi Patrik,

I've send comments on a few patches. For the other patches, you can add

Acked-by: Thomas Zimmermann 

Best regards
Thomas

Am 13.06.22 um 14:34 schrieb Patrik Jakobsson:

Much of the lvds code for Poulsbo, Oaktrail and Cedarview are almost
identical so there is no need to keep three copies of it. Unify as much
as possible into one implementation. There are still things like the
init code that can be unified but that requires unifying other parts of
the driver first.

Patrik Jakobsson (19):
   drm/gma500: Unify *_lvds_get_max_backlight()
   drm/gma500: Unify *_lvds_set_backlight()
   drm/gma500: Unify *_lvds_set_power()
   drm/gma500: Unify *_lvds_mode_valid()
   drm/gma500: Unify *_lvds_encoder_dpms()
   drm/gma500: Unify *_intel_lvds_save()
   drm/gma500: Unify struct *_intel_lvds_priv
   drm/gma500: Unify *_intel_lvds_restore()
   drm/gma500: Unify *_intel_lvds_mode_fixup()
   drm/gma500: Unify *_intel_lvds_prepare()
   drm/gma500: Unify *_intel_lvds_commit()
   drm/gma500: Unify *_intel_lvds_mode_set()
   drm/gma500: Unify struct *_intel_lvds_helper_funcs
   drm/gma500: Unify *_intel_lvds_get_modes()
   drm/gma500: Unify struct *_intel_lvds_connector_helper_funcs
   drm/gma500: Use i2c_bus in gma_encoder for PSB
   drm/gma500: Unify *_intel_lvds_destroy()
   drm/gma500: Unify *_intel_lvds_set_property()
   drm/gma500: Unify struct *_intel_lvds_connector_funcs

  drivers/gpu/drm/gma500/Makefile |   1 +
  drivers/gpu/drm/gma500/cdv_intel_lvds.c | 390 +-
  drivers/gpu/drm/gma500/gma_lvds.c   | 462 +
  drivers/gpu/drm/gma500/gma_lvds.h   |  38 ++
  drivers/gpu/drm/gma500/oaktrail_lvds.c  | 112 +-
  drivers/gpu/drm/gma500/psb_drv.h|   1 -
  drivers/gpu/drm/gma500/psb_intel_drv.h  |   2 -
  drivers/gpu/drm/gma500/psb_intel_lvds.c | 507 +---
  8 files changed, 530 insertions(+), 983 deletions(-)
  create mode 100644 drivers/gpu/drm/gma500/gma_lvds.c
  create mode 100644 drivers/gpu/drm/gma500/gma_lvds.h



--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev


OpenPGP_signature
Description: OpenPGP digital signature

Re: [PATCH 0/6] drm: Add mouse cursor hotspot support to atomic KMS

[Pekka Paalanen]

On Mon, 13 Jun 2022 14:54:57 +
Zack Rusin  wrote:

> On Mon, 2022-06-13 at 17:25 +0300, Pekka Paalanen wrote:
> > On Mon, 13 Jun 2022 13:14:48 +
> > Zack Rusin  wrote:
> >   
> > > On Mon, 2022-06-13 at 10:33 +0300, Pekka Paalanen wrote:  
> > > > On Fri, 10 Jun 2022 14:24:01 +
> > > > Zack Rusin  wrote:
> > > > 
> > > > > On Fri, 2022-06-10 at 10:59 +0200, Daniel Vetter wrote:
> > > > > > ⚠ External Email
> > > > > > 
> > > > > > On Fri, Jun 10, 2022 at 10:41:05AM +0200, Daniel Vetter wrote:  
> > > > > > > Hi all,
> > > > > > > 
> > > > > > > Kinda top post because the thread is sprawling and I think we 
> > > > > > > need a
> > > > > > > summary/restart. I think there's at least 3 issues here:
> > > > > > > 
> > > > > > > - lack of hotspot property support, which means compositors can't 
> > > > > > > really
> > > > > > >   support hotspot with atomic. Which isn't entirely true, because 
> > > > > > > you
> > > > > > >   totally can use atomic for the primary planes/crtcs and the 
> > > > > > > legacy
> > > > > > >   cursor ioctls, but I understand that people might find that a 
> > > > > > > bit silly :-)
> > > > > > > 
> > > > > > >   Anyway this problme is solved by the patch set here, and I 
> > > > > > > think results
> > > > > > >   in some nice cleanups to boot.
> > > > > > > 
> > > > > > > - the fact that cursors for virtual drivers are not planes, but 
> > > > > > > really
> > > > > > >   special things. Which just breaks the universal plane kms uapi. 
> > > > > > > That
> > > > > > >   part isn't solved, and I do agree with Simon and Pekka that we 
> > > > > > > really
> > > > > > >   should solve this before we unleash even more compositors onto 
> > > > > > > the
> > > > > > >   atomic paths of virtual drivers.
> > > > > > > 
> > > > > > >   I think the simplest solution for this is:
> > > > > > >   1. add a new DRM_PLANE_TYPE_VIRTUAL_CURSOR, and set that for 
> > > > > > > these
> > > > > > >   special cursor planes on all virtual drivers
> > > > > > >   2. add the new "I understand virtual cursors planes" setparam, 
> > > > > > > filter
> > > > > > >   virtual cursor planes for userspace which doesn't set this 
> > > > > > > (like we do
> > > > > > >   right now if userspace doesn't set the universal plane mode)
> > > > > > >   3. backport the above patches to all stable kernels
> > > > > > >   4. make sure the hotspot property is only set on VIRTUAL_CURSOR 
> > > > > > > planes
> > > > > > >   and nothing else in the rebased patch series  
> > > > > > 
> > > > > > Simon also mentioned on irc that these special planes must not 
> > > > > > expose the
> > > > > > CRTC_X/Y property, since that doesn't really do much at all. Or is 
> > > > > > our
> > > > > > understanding of how this all works for commandeered cursors wrong? 
> > > > > >  
> > > > > 
> > > > > Yes, that's the part I don't understand. I don't think I see how the 
> > > > > CRTC_X|Y
> > > > > properties aren't used.
> > > > > 
> > > > > I think the confusion might stem from the fact that it appears that 
> > > > > the
> > > > > hypervisors/hosts are moving that plane, which is not the case. We 
> > > > > never move the
> > > > > plane itself, we redirect the mouse focus/movement, that's what's 
> > > > > reducing the
> > > > > latency but don't touch drm internals. I can't speak for every 
> > > > > virtualized stack,
> > > > > but what is happening on ours is that we set the image that's on the 
> > > > > cursor plane as
> > > > > the cursor on the machine that's running the guest. So when you move 
> > > > > the mouse
> > > > > across the screen as you enter the VM window the cursor plane isn't 
> > > > > touched, but the
> > > > > local machines cursor changes to what's inside the cursor plane. When 
> > > > > the mouse is
> > > > > clicked the mouse device in the guest generates the event with the 
> > > > > proper
> > > > > coordinates (hence we need the hotspot to route that event 
> > > > > correctly). That's when
> > > > > the guest reacts just like it would normally on native if a mouse 
> > > > > event was
> > > > > received.
> > > > > 
> > > > > The actual cursor plane might not be visible while this is happening 
> > > > > but even when
> > > > > it's not visible it's still at whatever crtc_x|y the guest thinks it 
> > > > > is. crtc_x|y
> > > > > are still only driven by the guests mouse device.
> > > > > 
> > > > > We control the mouse device and visibility of the cursor plane itself 
> > > > > based on
> > > > > what's happening in the system but I don't think that's that 
> > > > > different from a native
> > > > > system.
> > > > 
> > > > Sorry Zack, while I'm sure that is technically correct and very detaily
> > > > accurate, it's totally not any different to what we have been talking
> > > > about all along.
> > > > 
> > > > We care about how things look like to the end user, and not what
> > > > property values the guest KMS driver might have for each plane. The KMS
> > >

Re: [PATCH 02/64] drm/crtc: Introduce drmm_crtc_init_with_planes

[Maxime Ripard]

Hi Thomas,

On Mon, Jun 13, 2022 at 01:23:54PM +0200, Thomas Zimmermann wrote:
> Am 10.06.22 um 11:28 schrieb Maxime Ripard:
> > The DRM-managed function to register a CRTC is
> > drmm_crtc_alloc_with_planes(), which will allocate the underlying
> > structure and initialisation the CRTC.
> > 
> > However, we might want to separate the structure creation and the CRTC
> > initialisation, for example if the structure is shared across multiple
> > DRM entities, for example an encoder and a connector.
> > 
> > Let's create an helper to only initialise a CRTC that would be passed as
> > an argument.
> 
> Before I review all of thes patches, one question. it's yet not clear to me
> why drm_crtc_init_with_planes() wouldn't work. (I know we discussed this on
> IRC.)
> 
> If you're calling drmm_mode_config_init(), it will clean up all the CRTC,
> encoder connector, etc. data structures for you. For CRTC instances in
> kmalloced memory, wouldn't it be simpler to put the corresponding kfree into
> vc4_crtc_destroy()?

My intent was to remove as much of the lifetime handling and
memory-management from drivers as possible.

My feeling is that while the solution you suggest would definitely work,
it relies on drivers authors to know about this, and make the effort to
convert the drivers themselves. And then we would have to review that,
which we will probably miss (collectively), because it's a bit obscure.

While with either the drmm_alloc_* functions, or the new functions I
introduce there, we can just deprecate the old ones, create a TODO entry
and a coccinelle script and trust that it works properly.

Maxime

Re: [PATCH v2 1/7] usb: typec: mux: Allow muxes to specify mode-switch

[Heikki Krogerus]

On Thu, Jun 09, 2022 at 06:09:40PM +, Prashant Malani wrote:
> Loosen the typec_mux_match() requirements so that searches where an
> alt mode is not specified, but the target mux device lists the
> "mode-switch" property, return a success.
> 
> This is helpful in Type C port drivers which would like to get a pointer
> to the mux switch associated with a Type C port, but don't want to
> specify a particular alt mode.
> 
> Signed-off-by: Prashant Malani 

Reviewed-by: Heikki Krogerus 

> ---
> 
> Changes since v1:
> - No changes.
> 
>  drivers/usb/typec/mux.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/usb/typec/mux.c b/drivers/usb/typec/mux.c
> index fd55c2c516a5..464330776cd6 100644
> --- a/drivers/usb/typec/mux.c
> +++ b/drivers/usb/typec/mux.c
> @@ -281,9 +281,13 @@ static void *typec_mux_match(struct fwnode_handle 
> *fwnode, const char *id,
>   if (match)
>   goto find_mux;
>  
> - /* Accessory Mode muxes */
>   if (!desc) {
> - match = fwnode_property_present(fwnode, "accessory");
> + /*
> +  * Accessory Mode muxes & muxes which explicitly specify
> +  * the required identifier can avoid SVID matching.
> +  */
> + match = fwnode_property_present(fwnode, "accessory") ||
> + fwnode_property_present(fwnode, id);
>   if (match)
>   goto find_mux;
>   return NULL;
> -- 
> 2.36.1.476.g0c4daa206d-goog

-- 
heikki

Re: [PATCH] drm/bridge: anx7625: Zero error variable when panel bridge not present

[AngeloGioacchino Del Regno]

Il 13/06/22 18:37, Nícolas F. R. A. Prado ha scritto:

While parsing the DT, the anx7625 driver checks for the presence of a
panel bridge on endpoint 1. If it is missing, pdata->panel_bridge stores
the error pointer and the function returns successfully without first
cleaning that variable. This is an issue since other functions later
check for the presence of a panel bridge by testing the trueness of that
variable.

In order to ensure proper behavior, zero out pdata->panel_bridge before
returning when no panel bridge is found.

Fixes: 9e82ea0fb1df ("drm/bridge: anx7625: switch to devm_drm_of_get_bridge")
Signed-off-by: Nícolas F. R. A. Prado 



I would've preferred s/zero out/cleanup/g but it's also fine as you wrote it.
Besides, good catch!

Reviewed-by: AngeloGioacchino Del Regno 

Re: [Intel-gfx] [PATCH] drm/i915: Improve user experience and driver robustness under SIGINT or similar

[Tvrtko Ursulin]

Final call to raise objections.

Regards,

Tvrtko

On 07/06/2022 09:36, Tvrtko Ursulin wrote:


On 27/05/2022 13:07, Andrzej Hajda wrote:

On 27.05.2022 09:24, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

We have long standing customer complaints that pressing Ctrl-C (or to 
the

effect of) causes engine resets with otherwise well behaving programs.

Not only is logging engine resets during normal operation not desirable
since it creates support incidents, but more fundamentally we should 
avoid
going the engine reset path when we can since any engine reset 
introduces

a chance of harming an innocent context.

Reason for this undesirable behaviour is that the driver currently does
not distinguish between banned contexts and non-persistent contexts 
which

have been closed.

To fix this we add the distinction between the two reasons for revoking
contexts, which then allows the strict timeout only be applied to 
banned,

while innocent contexts (well behaving) can preempt cleanly and exit
without triggering the engine reset path.

Note that the added context exiting category applies both to closed non-
persistent context, and any exiting context when hangcheck has been
disabled by the user.

At the same time we rename the backend operation from 'ban' to 'revoke'
which more accurately describes the actual semantics. (There is no 
ban at

the backend level since banning is a concept driven by the scheduling
frontend. Backends are simply able to revoke a running context so that
is the more appropriate name chosen.)

Signed-off-by: Tvrtko Ursulin 
---
  drivers/gpu/drm/i915/gem/i915_gem_context.c   | 23 +++--
  drivers/gpu/drm/i915/gt/intel_context.c   | 24 ++
  drivers/gpu/drm/i915/gt/intel_context.h   | 25 +--
  drivers/gpu/drm/i915/gt/intel_context_types.h |  4 ++-
  .../drm/i915/gt/intel_execlists_submission.c  |  6 ++---
  .../gpu/drm/i915/gt/intel_ring_submission.c   |  7 +++---
  .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 15 ++-
  drivers/gpu/drm/i915/i915_request.c   |  2 +-
  8 files changed, 77 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c

index ab4c5ab28e4d..6b171c89b1b3 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1367,7 +1367,8 @@ static struct intel_engine_cs 
*active_engine(struct intel_context *ce)

  return engine;
  }
-static void kill_engines(struct i915_gem_engines *engines, bool ban)
+static void
+kill_engines(struct i915_gem_engines *engines, bool exit, bool 
persistent)

  {
  struct i915_gem_engines_iter it;
  struct intel_context *ce;
@@ -1381,9 +1382,15 @@ static void kill_engines(struct 
i915_gem_engines *engines, bool ban)

   */
  for_each_gem_engine(ce, engines, it) {
  struct intel_engine_cs *engine;
+    bool skip = false;
-    if (ban && intel_context_ban(ce, NULL))
-    continue;
+    if (exit)
+    skip = intel_context_set_exiting(ce);
+    else if (!persistent)
+    skip = intel_context_exit_nonpersistent(ce, NULL);
+
+    if (skip)
+    continue; /* Already marked. */


why not:
 if (exit && intel_context_set_exiting(ce))
 continue;
 else if (!persistent && intel_context_exit_nonpersistent(ce, NULL)
 continue;


Just so I can put the "already marked" comment on single line.



Anyway:
Reviewed-by: Andrzej Hajda 


Thanks!

John, Daniel - you had reservations against the older version of this 
patch AFAIR. This time round I believe I conceptually simplified it by 
doing a clean separation of contexts which should not be scheduled any 
more becuase they want it so, versus the ones we banned. That is, the 
patch stops abusing the banned status for contexts which haven't been 
(banned). This allows to only apply the strict preempt timeout to 
banned, while there is no reason to add any new timeout values for the 
rest.


Any objections to this version?

Regards,

Tvrtko



Regards
Andrzej


  /*
   * Check the current active state of this context; if we
@@ -1395,7 +1402,7 @@ static void kill_engines(struct 
i915_gem_engines *engines, bool ban)

  engine = active_engine(ce);
  /* First attempt to gracefully cancel the context */
-    if (engine && !__cancel_engine(engine) && ban)
+    if (engine && !__cancel_engine(engine) && (exit || 
!persistent))

  /*
   * If we are unable to send a preemptive pulse to bump
   * the context from the GPU, we have to resort to a full
@@ -1407,8 +1414,6 @@ static void kill_engines(struct 
i915_gem_engines *engines, bool ban)

  static void kill_context(struct i915_gem_context *ctx)
  {
-    bool ban = (!i915_gem_context_is_persistent(ctx) ||
-    !ctx->i915->params.enable_hangcheck);
  struct i915_gem_engines *pos, *next;
 

Re: [PATCH 0/8] drm: Clean up drm_crtc.h

[Jani Nikula]

On Mon, 13 Jun 2022, Ville Syrjala  wrote:
> From: Ville Syrjälä 
>
> Eliminate unnecessary includes from drm_crtc.h to avoid
> pointless rebuilds of the entire universe when touching
> some random header.
>
> I didn't really feel like splitting this up per-driver since
> that would have ended up being metric ton of one liners.
> I'm thinking the conflicts (if any) should be trivial enough
> to deal with even with bigger patches.
>
> Also the cc list would have been massive so didn't do it.
> Hopefully enough people actually read dri-devel...

Seems like a good idea to me. FWIW,

Acked-by: Jani Nikula 

Both the CI and the kernel bot found some issues, obviously those need
to be addressed, but otherwise I'd just rely on build results for
merging.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [PATCH v2 2/7] usb: typec: mux: Add CONFIG guards for functions

[Heikki Krogerus]

Hi,

On Thu, Jun 09, 2022 at 06:09:41PM +, Prashant Malani wrote:
> There are some drivers that can use the Type C mux API, but don't have
> to. Introduce CONFIG guards for the mux functions so that drivers can
> include the header file and not run into compilation errors on systems
> which don't have CONFIG_TYPEC enabled. When CONFIG_TYPEC is not enabled,
> the Type C mux functions will be stub versions of the original calls.
> 
> Reported-by: kernel test robot 
> Signed-off-by: Prashant Malani 
> ---
> 
> Changes since v1:
> - Added static inline to stub functions.
> - Updated function signature of stub functions from "struct typec_mux"
>   to "struct typec_mux_dev" in accordance with updates from commit
>   713fd49b430c ("usb: typec: mux: Introduce indirection")
> 
>  include/linux/usb/typec_mux.h | 38 +++
>  1 file changed, 38 insertions(+)
> 
> diff --git a/include/linux/usb/typec_mux.h b/include/linux/usb/typec_mux.h
> index ee57781dcf28..9eda6146fd26 100644
> --- a/include/linux/usb/typec_mux.h
> +++ b/include/linux/usb/typec_mux.h
> @@ -58,6 +58,8 @@ struct typec_mux_desc {
>   void *drvdata;
>  };
>  
> +#if IS_ENABLED(CONFIG_TYPEC) || IS_MODULE(CONFIG_TYPEC)
> +
>  struct typec_mux *fwnode_typec_mux_get(struct fwnode_handle *fwnode,
>  const struct typec_altmode_desc *desc);
>  void typec_mux_put(struct typec_mux *mux);
> @@ -76,4 +78,40 @@ void typec_mux_unregister(struct typec_mux_dev *mux);
>  void typec_mux_set_drvdata(struct typec_mux_dev *mux, void *data);
>  void *typec_mux_get_drvdata(struct typec_mux_dev *mux);
>  
> +#else
> +
> +static inline struct typec_mux *fwnode_typec_mux_get(struct fwnode_handle 
> *fwnode,
> +const struct typec_altmode_desc *desc)
> +{
> + return ERR_PTR(-EOPNOTSUPP);
> +}

The mux is optional resource for the drivers - fwnode_typec_mux_get()
returns NULL if there is no mux for the caller - so it's better to
just return NULL from this stub.

> +static inline void typec_mux_put(struct typec_mux *mux) {}
> +
> +static inline int typec_mux_set(struct typec_mux *mux, struct 
> typec_mux_state *state)
> +{
> + return -EOPNOTSUPP;
> +}

Return 0 in this case. That way this stub matches the function
behaviour:

...
if (IS_ERR_OR_NULL(mux))
return 0;
...

> +static inline struct typec_mux *
> +typec_mux_get(struct device *dev, const struct typec_altmode_desc *desc)
> +{
> + return ERR_PTR(-EOPNOTSUPP);
> +}

You don't need this one. Just leave the original outside of the ifdef.
It's already an inline wrapper function.

> +static inline struct typec_mux_dev *
> +typec_mux_register(struct device *parent, const struct typec_mux_desc *desc)
> +{
> + return ERR_PTR(-EOPNOTSUPP);
> +}
> +static inline void typec_mux_unregister(struct typec_mux_dev *mux) {}
> +
> +static inline void typec_mux_set_drvdata(struct typec_mux_dev *mux, void 
> *data) {}
> +static inline void *typec_mux_get_drvdata(struct typec_mux_dev *mux)
> +{
> + return ERR_PTR(-EOPNOTSUPP);
> +}
> +
> +#endif /* CONFIG_TYPEC */
> +
>  #endif /* __USB_TYPEC_MUX */

thanks,

-- 
heikki

Re: [PATCH v2 7/7] drm/bridge: anx7625: Add typec_mux_set callback function

[AngeloGioacchino Del Regno]

Il 09/06/22 20:09, Prashant Malani ha scritto:

From: Pin-Yen Lin 

Add the callback function when the driver receives state
changes of the Type-C port. The callback function configures the
crosspoint switch of the anx7625 bridge chip, which can change the
output pins of the signals according to the port state.

Signed-off-by: Pin-Yen Lin 
Signed-off-by: Prashant Malani 
---

Changes since v2:
- No changes.

  drivers/gpu/drm/bridge/analogix/anx7625.c | 58 +++
  drivers/gpu/drm/bridge/analogix/anx7625.h | 13 +
  2 files changed, 71 insertions(+)

diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c 
b/drivers/gpu/drm/bridge/analogix/anx7625.c
index d41a21103bd3..2c308d12fab2 100644
--- a/drivers/gpu/drm/bridge/analogix/anx7625.c
+++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
@@ -15,6 +15,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  
@@ -2582,9 +2583,66 @@ static void anx7625_runtime_disable(void *data)

pm_runtime_disable(data);
  }
  
+static void anx7625_set_crosspoint_switch(struct anx7625_data *ctx,

+ enum typec_orientation orientation)
+{
+   if (orientation == TYPEC_ORIENTATION_NORMAL) {
+   anx7625_reg_write(ctx, ctx->i2c.tcpc_client, TCPC_SWITCH_0,
+ SW_SEL1_SSRX_RX1 | SW_SEL1_DPTX0_RX2);
+   anx7625_reg_write(ctx, ctx->i2c.tcpc_client, TCPC_SWITCH_1,
+ SW_SEL2_SSTX_TX1 | SW_SEL2_DPTX1_TX2);
+   } else if (orientation == TYPEC_ORIENTATION_REVERSE) {
+   anx7625_reg_write(ctx, ctx->i2c.tcpc_client, TCPC_SWITCH_0,
+ SW_SEL1_SSRX_RX2 | SW_SEL1_DPTX0_RX1);
+   anx7625_reg_write(ctx, ctx->i2c.tcpc_client, TCPC_SWITCH_1,
+ SW_SEL2_SSTX_TX2 | SW_SEL2_DPTX1_TX1);
+   }
+}
+
+static void anx7625_typec_two_ports_update(struct anx7625_data *ctx)
+{
+   if (ctx->typec_ports[0].dp_connected && 
ctx->typec_ports[1].dp_connected)
+   /* Both ports available, do nothing to retain the current one. 
*/
+   return;
+   else if (ctx->typec_ports[0].dp_connected)
+   anx7625_set_crosspoint_switch(ctx, TYPEC_ORIENTATION_NORMAL);
+   else if (ctx->typec_ports[1].dp_connected)
+   anx7625_set_crosspoint_switch(ctx, TYPEC_ORIENTATION_REVERSE);
+}
+
  static int anx7625_typec_mux_set(struct typec_mux_dev *mux,
 struct typec_mux_state *state)
  {
+   struct anx7625_port_data *data = typec_mux_get_drvdata(mux);
+   struct anx7625_data *ctx = data->ctx;
+   struct device *dev = &ctx->client->dev;
+
+   bool old_dp_connected = (ctx->typec_ports[0].dp_connected ||
+ctx->typec_ports[1].dp_connected);


So the old connection state is "either port0 or port1 are currently 
connected"...


+   bool new_dp_connected;
+
+   if (ctx->num_typec_switches == 1)
+   return 0;
+
+   dev_dbg(dev, "mux_set dp_connected: c0=%d, c1=%d\n",
+   ctx->typec_ports[0].dp_connected, 
ctx->typec_ports[1].dp_connected);
+
+   data->dp_connected = (state->alt && state->alt->svid == USB_TYPEC_DP_SID 
&&
+ state->alt->mode == USB_TYPEC_DP_MODE);
+ > +new_dp_connected = (ctx->typec_ports[0].dp_connected ||
+   ctx->typec_ports[1].dp_connected);


...and the new connection state is the same as the old one, because I don't see
anything that could ever modify it in this function's flow, until reaching this
assignment.


+
+   /* dp on, power on first */
+   if (!old_dp_connected && new_dp_connected)
+   pm_runtime_get_sync(dev);


...so that will never happen...


+
+   anx7625_typec_two_ports_update(ctx);
+
+   /* dp off, power off last */
+   if (old_dp_connected && !new_dp_connected)
+   pm_runtime_put_sync(dev);


...and same here.

Regards,
Angelo

Re: [PATCH] drm/amdgpu: Fix GTT size reporting in amdgpu_ioctl

[Mike Lothian]

On Mon, 13 Jun 2022 at 10:11, Michel Dänzer  wrote:
>
> On 2022-06-11 09:19, Christian König wrote:
> > Am 10.06.22 um 15:54 schrieb Michel Dänzer:
> >> From: Michel Dänzer 
> >>
> >> The commit below changed the TTM manager size unit from pages to
> >> bytes, but failed to adjust the corresponding calculations in
> >> amdgpu_ioctl.
> >>
> >> Fixes: dfa714b88eb0 ("drm/amdgpu: remove GTT accounting v2")
> >> Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1930
> >> Bug: https://gitlab.freedesktop.org/mesa/mesa/-/issues/6642
> >> Signed-off-by: Michel Dänzer 
> >
> > Ah, WTF! You won't believe how long I have been searching for this one.
>
> Don't feel too bad, similar things have happened to me before. :) Even after 
> Marek's GitLab comment got me on the right track, it still took a fair amount 
> of trial, error & head scratching to put this one to bed.
>
>
> --
> Earthling Michel Dänzer|  https://redhat.com
> Libre software enthusiast  | Mesa and Xwayland developer

That's indeed fixed the Tomb Raider / vulkan issue

I'm still seeing some strange warnings and errors on Linus's tree so
I've updated https://gitlab.freedesktop.org/drm/amd/-/issues/1992
https://gitlab.freedesktop.org/drm/amd/-/issues/2034, I'm not sure if
that's Buddy allocator, TTM Bulk moves or a whole new issue

If it's not too late feel free to add my tested by

Re: [PATCH v2 6/7] drm/bridge: anx7625: Register Type-C mode switches

[AngeloGioacchino Del Regno]

Il 09/06/22 20:09, Prashant Malani ha scritto:

When the DT node has "switches" available, register a Type-C mode-switch
for each listed "switch". This allows the driver to receive state
information about what operating mode a Type-C port and its connected
peripherals are in, as well as status information (like VDOs) related to
that state.

The callback function is currently a stub, but subsequent patches will
implement the required functionality.

Signed-off-by: Prashant Malani 
---

Changes since v2:
- No changes.

  drivers/gpu/drm/bridge/analogix/anx7625.c | 73 +++
  drivers/gpu/drm/bridge/analogix/anx7625.h |  6 ++
  2 files changed, 79 insertions(+)

diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c 
b/drivers/gpu/drm/bridge/analogix/anx7625.c
index 07ed44c6b839..d41a21103bd3 100644
--- a/drivers/gpu/drm/bridge/analogix/anx7625.c
+++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
@@ -15,6 +15,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  
  #include 

@@ -2581,9 +2582,59 @@ static void anx7625_runtime_disable(void *data)
pm_runtime_disable(data);
  }
  
+static int anx7625_typec_mux_set(struct typec_mux_dev *mux,

+struct typec_mux_state *state)
+{
+   return 0;
+}
+
+static int anx7625_register_mode_switch(struct device *dev, struct device_node 
*node,
+   struct anx7625_data *ctx)
+{
+   struct anx7625_port_data *port_data;
+   struct typec_mux_desc mux_desc = {};
+   char name[32];
+   u32 port_num;
+   int ret;
+
+   ret = of_property_read_u32(node, "reg", &port_num);
+   if (ret)
+   return ret;
+
+   if (port_num >= ctx->num_typec_switches) {
+   dev_err(dev, "Invalid port number specified: %d\n", port_num);
+   return -EINVAL;
+   }
+
+   port_data = &ctx->typec_ports[port_num];
+   port_data->ctx = ctx;
+   mux_desc.fwnode = &node->fwnode;
+   mux_desc.drvdata = port_data;
+   snprintf(name, sizeof(name), "%s-%u", node->name, port_num);
+   mux_desc.name = name;
+   mux_desc.set = anx7625_typec_mux_set;
+
+   port_data->typec_mux = typec_mux_register(dev, &mux_desc);
+   if (IS_ERR(port_data->typec_mux)) {
+   ret = PTR_ERR(port_data->typec_mux);
+   dev_err(dev, "Mode switch register for port %d failed: %d", 
port_num, ret);
+   }


Please return 0 at the end of this function.

if (IS_ERR()) {
..code..
return ret;
}

return 0;
}


+
+   return ret;
+}
+
+static void anx7625_unregister_typec_switches(struct anx7625_data *ctx)
+{
+   int i;
+
+   for (i = 0; i < ctx->num_typec_switches; i++)
+   typec_mux_unregister(ctx->typec_ports[i].typec_mux);
+}
+
  static int anx7625_register_typec_switches(struct device *device, struct 
anx7625_data *ctx)
  {
struct device_node *of = NULL;
+   struct device_node *sw;
int ret = 0;
  
  	of = of_get_child_by_name(device->of_node, "switches");

@@ -2594,6 +2645,26 @@ static int anx7625_register_typec_switches(struct device 
*device, struct anx7625
if (ctx->num_typec_switches <= 0)
return -ENODEV;
  
+	ctx->typec_ports = devm_kzalloc(device,

+   ctx->num_typec_switches * sizeof(struct 
anx7625_port_data),
+   GFP_KERNEL);
+   if (!ctx->typec_ports)
+   return -ENOMEM;
+
+   /* Register switches for each connector. */
+   for_each_available_child_of_node(of, sw) {
+   if (!of_property_read_bool(sw, "mode-switch"))
+   continue;
+   ret = anx7625_register_mode_switch(device, sw, ctx);
+   if (ret) {
+   dev_err(device, "Failed to register mode switch: %d\n", 
ret);
+   break;
+   }
+   }
+
+   if (ret)
+   anx7625_unregister_typec_switches(ctx);
+
return ret;
  }
  
@@ -2759,6 +2830,8 @@ static int anx7625_i2c_remove(struct i2c_client *client)
  
  	drm_bridge_remove(&platform->bridge);
  
+	anx7625_unregister_typec_switches(platform);

+
if (platform->pdata.intp_irq)
destroy_workqueue(platform->workqueue);
  
diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.h b/drivers/gpu/drm/bridge/analogix/anx7625.h

index d5cbca708842..76cfc64f7574 100644
--- a/drivers/gpu/drm/bridge/analogix/anx7625.h
+++ b/drivers/gpu/drm/bridge/analogix/anx7625.h
@@ -443,6 +443,11 @@ struct anx7625_i2c_client {
struct i2c_client *tcpc_client;
  };
  
+struct anx7625_port_data {

+   struct typec_mux_dev *typec_mux;
+   struct anx7625_data *ctx;
+};
+
  struct anx7625_data {
struct anx7625_platform_data pdata;
struct platform_device *audio_pdev;
@@ -474,6 +479,7 @@ struct anx7625_data {
struct mipi_dsi_

Re: [PATCH v2 5/7] drm/bridge: anx7625: Register number of Type C switches

[AngeloGioacchino Del Regno]

Il 09/06/22 20:09, Prashant Malani ha scritto:

Parse the "switches" node, if available, and count and store the number
of Type-C switches within it. Since we currently don't do anything with
this info, no functional changes are expected from this change.

This patch sets a foundation for the actual registering of Type-C
switches with the Type-C connector class framework.

Signed-off-by: Prashant Malani 
---

Changes since v1:
- No changes.

  drivers/gpu/drm/bridge/analogix/anx7625.c | 20 
  drivers/gpu/drm/bridge/analogix/anx7625.h |  1 +
  2 files changed, 21 insertions(+)

diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c 
b/drivers/gpu/drm/bridge/analogix/anx7625.c
index 53a5da6c49dd..07ed44c6b839 100644
--- a/drivers/gpu/drm/bridge/analogix/anx7625.c
+++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
@@ -2581,6 +2581,22 @@ static void anx7625_runtime_disable(void *data)
pm_runtime_disable(data);
  }
  
+static int anx7625_register_typec_switches(struct device *device, struct anx7625_data *ctx)

+{
+   struct device_node *of = NULL;
+   int ret = 0;
+
+   of = of_get_child_by_name(device->of_node, "switches");
+   if (!of)
+   return -ENODEV;
+
+   ctx->num_typec_switches = of_get_child_count(of);
+   if (ctx->num_typec_switches <= 0)
+   return -ENODEV;
+
+   return ret;


You aren't using the `ret` variable for anything other than returning zero:
remove it and simply return 0 here.


+}
+
  static int anx7625_i2c_probe(struct i2c_client *client,
 const struct i2c_device_id *id)
  {
@@ -2686,6 +2702,10 @@ static int anx7625_i2c_probe(struct i2c_client *client,
if (platform->pdata.intp_irq)
queue_work(platform->workqueue, &platform->work);
  
+	ret = anx7625_register_typec_switches(dev, platform);

+   if (ret)
+   dev_info(dev, "Didn't register Type C switches, err: %d\n", 
ret);


Type-C switches are optional for this driver and this will print a sort of error
on boards that are *not* declaring any switches on purpose (because perhaps they
don't have any, or for any other reason).

Even though this is a dev_info and not a dev_err, it's still printing an 
alarming
(and useless, in the aforementioned case) message.

Please fix this.

Regards,
Angelo

Re: [PATCH v2 2/7] usb: typec: mux: Add CONFIG guards for functions

[AngeloGioacchino Del Regno]

Il 09/06/22 20:09, Prashant Malani ha scritto:

There are some drivers that can use the Type C mux API, but don't have
to. Introduce CONFIG guards for the mux functions so that drivers can
include the header file and not run into compilation errors on systems
which don't have CONFIG_TYPEC enabled. When CONFIG_TYPEC is not enabled,
the Type C mux functions will be stub versions of the original calls.

Reported-by: kernel test robot 
Signed-off-by: Prashant Malani 
---

Changes since v1:
- Added static inline to stub functions.
- Updated function signature of stub functions from "struct typec_mux"
   to "struct typec_mux_dev" in accordance with updates from commit
   713fd49b430c ("usb: typec: mux: Introduce indirection")

  include/linux/usb/typec_mux.h | 38 +++
  1 file changed, 38 insertions(+)

diff --git a/include/linux/usb/typec_mux.h b/include/linux/usb/typec_mux.h
index ee57781dcf28..9eda6146fd26 100644
--- a/include/linux/usb/typec_mux.h
+++ b/include/linux/usb/typec_mux.h
@@ -58,6 +58,8 @@ struct typec_mux_desc {
void *drvdata;
  };
  
+#if IS_ENABLED(CONFIG_TYPEC) || IS_MODULE(CONFIG_TYPEC)


IS_ENABLED(x) evaluates to 1 when (x == 'y' || x == 'm')
IS_MODULE(x) evaluates to 1 when  (x == 'm')

this means that a IS_ENABLED(CONFIG_TYPEC) check is enough, and
the latter is redundant.

Regards,
Angelo

Re: [PATCH v2 1/7] usb: typec: mux: Allow muxes to specify mode-switch

[AngeloGioacchino Del Regno]

Il 09/06/22 20:09, Prashant Malani ha scritto:

Loosen the typec_mux_match() requirements so that searches where an
alt mode is not specified, but the target mux device lists the
"mode-switch" property, return a success.

This is helpful in Type C port drivers which would like to get a pointer
to the mux switch associated with a Type C port, but don't want to
specify a particular alt mode.

Signed-off-by: Prashant Malani 
Reviewed-by: Heikki Krogerus 


Reviewed-by: AngeloGioacchino Del Regno 

Re: [PATCH 02/64] drm/crtc: Introduce drmm_crtc_init_with_planes

[Thomas Zimmermann]

Hi

Am 14.06.22 um 09:37 schrieb Maxime Ripard:

Hi Thomas,

On Mon, Jun 13, 2022 at 01:23:54PM +0200, Thomas Zimmermann wrote:

Am 10.06.22 um 11:28 schrieb Maxime Ripard:

The DRM-managed function to register a CRTC is
drmm_crtc_alloc_with_planes(), which will allocate the underlying
structure and initialisation the CRTC.

However, we might want to separate the structure creation and the CRTC
initialisation, for example if the structure is shared across multiple
DRM entities, for example an encoder and a connector.

Let's create an helper to only initialise a CRTC that would be passed as
an argument.


Before I review all of thes patches, one question. it's yet not clear to me
why drm_crtc_init_with_planes() wouldn't work. (I know we discussed this on
IRC.)

If you're calling drmm_mode_config_init(), it will clean up all the CRTC,
encoder connector, etc. data structures for you. For CRTC instances in
kmalloced memory, wouldn't it be simpler to put the corresponding kfree into
vc4_crtc_destroy()?


My intent was to remove as much of the lifetime handling and
memory-management from drivers as possible.

My feeling is that while the solution you suggest would definitely work,
it relies on drivers authors to know about this, and make the effort to
convert the drivers themselves. And then we would have to review that,
which we will probably miss (collectively), because it's a bit obscure.

While with either the drmm_alloc_* functions, or the new functions I
introduce there, we can just deprecate the old ones, create a TODO entry
and a coccinelle script and trust that it works properly.


Thanks for explaining the motivation.

I would not want to deprecate any of the existing functions, as they 
work for many drivers. The drmm_ functions add additional overhead that 
not everyone is willing to pay.


Best regards
Thomas



Maxime


--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev


OpenPGP_signature
Description: OpenPGP digital signature

Re: [PATCH v5] drm/msm/dp: force link training for display resolution change

[Stephen Boyd]

Quoting Kuogee Hsieh (2022-06-13 14:48:37)
> During display resolution changes display have to be disabled first
> followed by display enabling with new resolution. Display disable
> will turn off both pixel clock and main link clock so that main link
> have to be re-trained during display enable to have new video stream
> flow again. At current implementation, display enable function manually
> kicks up irq_hpd_handle which will read panel link status and start link
> training if link status is not in sync state. However, there is rare
> case that a particular panel links status keep staying in sync for
> some period of time after main link had been shut down previously at
> display disabled. Main link retraining will not be executed by
> irq_hdp_handle() if the link status read from panel shows it is in
> sync state. If this was happen, then video stream of newer display
> resolution will fail to be transmitted to panel due to main link is
> not in sync between host and panel. This patch force main link always
> be retrained during display enable procedure to prevent this rare
> failed case from happening. Also this implementation are more
> efficient than manual kicking off irq_hpd_handle function.

How is resolution change different from disabling and enabling the
display? The commit text talks about resolution changes, but the code
doesn't compare resolutions from before and after to know when to
retrain the link. Can the code be made to actually do what the commit
text says? It would be clearer if the code looked for actual resolution
changes instead of hooking the dp_bridge_enable() function.

>
> Changes in v2:
> -- set force_link_train flag on DP only (is_edp == false)
>
> Changes in v3:
> -- revise commit  text
> -- add Fixes tag
>
> Changes in v4:
> -- revise commit  text
>
> Changes in v5:
> -- fix spelling at commit text
>
> Fixes: 62671d2ef24b ("drm/msm/dp: fixes wrong connection state caused by 
> failure of link train")
> Signed-off-by: Kuogee Hsieh 
> ---
>  drivers/gpu/drm/msm/dp/dp_ctrl.c|  6 +++---
>  drivers/gpu/drm/msm/dp/dp_ctrl.h|  2 +-
>  drivers/gpu/drm/msm/dp/dp_display.c | 15 ---
>  3 files changed, 12 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c 
> b/drivers/gpu/drm/msm/dp/dp_ctrl.c
> index af7a80c..bea93eb 100644
> --- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
> +++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
> @@ -1551,7 +1551,7 @@ static int dp_ctrl_process_phy_test_request(struct 
> dp_ctrl_private *ctrl)
>
> ret = dp_ctrl_on_link(&ctrl->dp_ctrl);
> if (!ret)
> -   ret = dp_ctrl_on_stream(&ctrl->dp_ctrl);
> +   ret = dp_ctrl_on_stream(&ctrl->dp_ctrl, false);

Does this even matter if it's true or false? The 'sink_request' has
DP_TEST_LINK_PHY_TEST_PATTERN set from what I can tell, and then
dp_ctrl_on_stream() bails out before calling dp_ctrl_link_retrain()
anyway. It would be nice if we could split dp_ctrl_on_stream() so that
the part after the check for the sink request is a different function
that is called by dp_display.c and then this code can call the 'prepare'
function that does the first part. Then we can ignore the testing path
in the code, and possibly remove the conditional in dp_ctrl_on_stream()?

> else
> DRM_ERROR("failed to enable DP link controller\n");
>
> diff --git a/drivers/gpu/drm/msm/dp/dp_display.c 
> b/drivers/gpu/drm/msm/dp/dp_display.c
> index c388323..370348d 100644
> --- a/drivers/gpu/drm/msm/dp/dp_display.c
> +++ b/drivers/gpu/drm/msm/dp/dp_display.c
> @@ -872,7 +872,7 @@ static int dp_display_enable(struct dp_display_private 
> *dp, u32 data)
> return 0;
> }
>
> -   rc = dp_ctrl_on_stream(dp->ctrl);
> +   rc = dp_ctrl_on_stream(dp->ctrl, data);
> if (!rc)
> dp_display->power_on = true;
>
> @@ -1654,6 +1654,7 @@ void dp_bridge_enable(struct drm_bridge *drm_bridge)
> int rc = 0;
> struct dp_display_private *dp_display;
> u32 state;
> +   bool force_link_train = false;
>
> dp_display = container_of(dp, struct dp_display_private, dp_display);
> if (!dp_display->dp_mode.drm_mode.clock) {
> @@ -1688,10 +1689,14 @@ void dp_bridge_enable(struct drm_bridge *drm_bridge)
>
> state =  dp_display->hpd_state;
>
> -   if (state == ST_DISPLAY_OFF)
> +   if (state == ST_DISPLAY_OFF) {
> dp_display_host_phy_init(dp_display);
>
> -   dp_display_enable(dp_display, 0);
> +   if (!dp->is_edp)

I didn't see any answer to my question about why edp is special on v4.
Can you at least add a comment to the code about why edp doesn't need to
unconditionally retrain, but DP does?

> +   force_link_train = true;
> +   }
> +
> +   dp_display_enable(dp_display, force_link_train);
>
> rc = dp_display_post_enable(dp);
> if (rc) {

[PATCH v2 1/8] drm: Drop drm_edid.h from drm_crtc.h

[Ville Syrjala]

From: Ville Syrjälä 

drm_crtc.h has no need for drm_edid.h, so don't include it.
Avoids useless rebuilds of the entire universe when
touching drm_edid.h.

Quite a few placs do currently depend on drm_edid.h without
actually including it directly. All of those need to be fixed
up.

v2: Fix up i915 and msm some more

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/arm/malidp_mw.c | 1 +
 drivers/gpu/drm/aspeed/aspeed_gfx_out.c | 1 +
 drivers/gpu/drm/ast/ast_mode.c  | 1 +
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c  | 1 +
 drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c | 1 +
 drivers/gpu/drm/bridge/lontium-lt8912b.c| 1 +
 drivers/gpu/drm/bridge/parade-ps8640.c  | 1 +
 drivers/gpu/drm/bridge/simple-bridge.c  | 1 +
 drivers/gpu/drm/bridge/ti-tfp410.c  | 1 +
 drivers/gpu/drm/display/drm_dp_helper.c | 1 +
 drivers/gpu/drm/display/drm_dp_mst_topology.c   | 1 +
 drivers/gpu/drm/drm_client_modeset.c| 1 +
 drivers/gpu/drm/drm_kms_helper_common.c | 1 +
 drivers/gpu/drm/drm_modes.c | 1 +
 drivers/gpu/drm/exynos/exynos_mixer.c   | 1 +
 drivers/gpu/drm/gma500/cdv_intel_dp.c   | 1 +
 drivers/gpu/drm/gma500/oaktrail_hdmi.c  | 1 +
 drivers/gpu/drm/gma500/oaktrail_lvds.c  | 1 +
 drivers/gpu/drm/gma500/psb_intel_modes.c| 2 ++
 drivers/gpu/drm/gud/gud_connector.c | 1 +
 drivers/gpu/drm/i915/display/intel_bios.c   | 1 +
 drivers/gpu/drm/i915/display/intel_dp.c | 1 +
 drivers/gpu/drm/i915/display/intel_lspcon.c | 1 +
 drivers/gpu/drm/i915/display/intel_opregion.c   | 2 ++
 drivers/gpu/drm/imx/imx-ldb.c   | 1 +
 drivers/gpu/drm/imx/imx-tve.c   | 1 +
 drivers/gpu/drm/imx/parallel-display.c  | 1 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_writeback.c   | 2 ++
 drivers/gpu/drm/msm/hdmi/hdmi_bridge.c  | 1 +
 drivers/gpu/drm/omapdrm/dss/hdmi4.c | 1 +
 drivers/gpu/drm/omapdrm/dss/hdmi5.c | 1 +
 drivers/gpu/drm/panel/panel-edp.c   | 1 +
 drivers/gpu/drm/panel/panel-simple.c| 1 +
 drivers/gpu/drm/qxl/qxl_display.c   | 1 +
 drivers/gpu/drm/rcar-du/rcar_du_writeback.c | 1 +
 drivers/gpu/drm/rockchip/rk3066_hdmi.c  | 1 +
 drivers/gpu/drm/solomon/ssd130x.c   | 1 +
 drivers/gpu/drm/stm/ltdc.c  | 1 +
 drivers/gpu/drm/tiny/arcpgu.c   | 1 +
 drivers/gpu/drm/tiny/bochs.c| 1 +
 drivers/gpu/drm/tiny/cirrus.c   | 1 +
 drivers/gpu/drm/tiny/gm12u320.c | 1 +
 drivers/gpu/drm/udl/udl_connector.c | 1 +
 drivers/gpu/drm/vboxvideo/vbox_mode.c   | 1 +
 drivers/gpu/drm/virtio/virtgpu_display.c| 1 +
 drivers/gpu/drm/virtio/virtgpu_vq.c | 2 ++
 drivers/gpu/drm/vkms/vkms_output.c  | 1 +
 drivers/gpu/drm/vkms/vkms_writeback.c   | 1 +
 include/drm/drm_crtc.h  | 1 -
 49 files changed, 52 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/arm/malidp_mw.c b/drivers/gpu/drm/arm/malidp_mw.c
index 204c869d9fe2..43de2ac8f27e 100644
--- a/drivers/gpu/drm/arm/malidp_mw.c
+++ b/drivers/gpu/drm/arm/malidp_mw.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpu/drm/aspeed/aspeed_gfx_out.c 
b/drivers/gpu/drm/aspeed/aspeed_gfx_out.c
index 6759cb88415a..4f2187025a21 100644
--- a/drivers/gpu/drm/aspeed/aspeed_gfx_out.c
+++ b/drivers/gpu/drm/aspeed/aspeed_gfx_out.c
@@ -4,6 +4,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "aspeed_gfx.h"
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index db2010a55674..3eb9afecd9d4 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -36,6 +36,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 01c8b80e34ec..8aadcc0aa90b 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c 
b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
index 67f0f444b4e8..ba5f695703dc 100644
--- a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
+++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
@@ -43,6 +43,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpu/drm/bridge/lontium-lt8912b.c 
b/dri

[PATCH v2 2/8] drm: Drop drm_framebuffer.h from drm_crtc.h

[Ville Syrjala]

From: Ville Syrjälä 

drm_crtc.h has no need for drm_frambuffer.h, so don't include it.
Avoids useless rebuilds of the entire universe when
touching drm_framebuffer.h.

Quite a few placs do currently depend on drm_framebuffer.h without
actually including it directly. All of those need to be fixed
up.

v2: Fix up msm some more

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 1 +
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_trace.h  | 1 +
 drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c | 1 +
 drivers/gpu/drm/arm/hdlcd_crtc.c | 1 +
 drivers/gpu/drm/arm/malidp_crtc.c| 1 +
 drivers/gpu/drm/arm/malidp_mw.c  | 1 +
 drivers/gpu/drm/arm/malidp_planes.c  | 1 +
 drivers/gpu/drm/armada/armada_fb.h   | 2 ++
 drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c | 1 +
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c  | 1 +
 drivers/gpu/drm/drm_atomic.c | 1 +
 drivers/gpu/drm/drm_atomic_helper.c  | 1 +
 drivers/gpu/drm/drm_atomic_state_helper.c| 1 +
 drivers/gpu/drm/drm_atomic_uapi.c| 1 +
 drivers/gpu/drm/drm_crtc.c   | 1 +
 drivers/gpu/drm/drm_crtc_helper.c| 1 +
 drivers/gpu/drm/drm_damage_helper.c  | 1 +
 drivers/gpu/drm/drm_fb_helper.c  | 1 +
 drivers/gpu/drm/drm_gem_atomic_helper.c  | 1 +
 drivers/gpu/drm/drm_mipi_dbi.c   | 1 +
 drivers/gpu/drm/drm_mode_config.c| 1 +
 drivers/gpu/drm/drm_modeset_helper.c | 1 +
 drivers/gpu/drm/drm_writeback.c  | 1 +
 drivers/gpu/drm/exynos/exynos5433_drm_decon.c| 1 +
 drivers/gpu/drm/exynos/exynos7_drm_decon.c   | 1 +
 drivers/gpu/drm/exynos/exynos_drm_fb.c   | 1 +
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c| 1 +
 drivers/gpu/drm/exynos/exynos_drm_fimd.c | 1 +
 drivers/gpu/drm/exynos/exynos_drm_plane.c| 1 +
 drivers/gpu/drm/exynos/exynos_drm_vidi.c | 1 +
 drivers/gpu/drm/exynos/exynos_mixer.c| 1 +
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c  | 1 +
 drivers/gpu/drm/gma500/framebuffer.c | 1 +
 drivers/gpu/drm/gma500/gma_display.c | 1 +
 drivers/gpu/drm/gma500/oaktrail_crtc.c   | 1 +
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c  | 1 +
 drivers/gpu/drm/i915/display/intel_display_types.h   | 1 +
 drivers/gpu/drm/imx/dcss/dcss-plane.c| 1 +
 drivers/gpu/drm/imx/ipuv3-plane.c| 1 +
 drivers/gpu/drm/kmb/kmb_plane.c  | 1 +
 drivers/gpu/drm/logicvc/logicvc_layer.c  | 1 +
 drivers/gpu/drm/mcde/mcde_display.c  | 1 +
 drivers/gpu/drm/mediatek/mtk_disp_ovl.c  | 1 +
 drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 2 ++
 drivers/gpu/drm/mediatek/mtk_drm_plane.c | 1 +
 drivers/gpu/drm/meson/meson_overlay.c| 1 +
 drivers/gpu/drm/meson/meson_plane.c  | 1 +
 drivers/gpu/drm/mgag200/mgag200_mode.c   | 1 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 1 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c  | 2 ++
 drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c  | 1 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c  | 1 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c| 1 +
 drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c   | 1 +
 drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c   | 1 +
 drivers/gpu/drm/msm/disp/mdp_format.c| 2 ++
 drivers/gpu/drm/msm/msm_debugfs.c| 1 +
 drivers/gpu/drm/msm/msm_fb.c | 1 +
 drivers/gpu/drm/msm/msm_fbdev.c  | 1 +
 drivers/gpu/drm/mxsfb/mxsfb_kms.c| 1 +
 drivers/gpu/drm/omapdrm/omap_debugfs.c   | 1 +
 drivers/gpu/drm/omapdrm/omap_fb.c| 1 +
 drivers/gpu/drm/omapdrm/omap_fbdev.c | 1 +
 drivers/gpu/drm/omapdrm/omap_plane.c | 1 +
 drivers/gpu/drm/pl111/pl111_display.c| 1 +
 drivers/gpu/drm/pl111/pl111_drv.c| 1 +
 drivers/gpu/drm/pl111/pl111_versatile.c  | 2 ++
 drivers/gpu/drm/qxl/qxl_display.c| 1 +
 drivers/gpu/drm/qxl/qxl_draw.c   | 1 +
 drivers/gpu/drm/radeon/atombios_crtc.c   | 1 +
 drivers/gpu/drm/radeon/evergreen.c   | 1 +
 drivers/gpu/drm/radeon/r100.c| 1 +
 drivers/gpu/drm/radeon

Re: [PATCH 02/64] drm/crtc: Introduce drmm_crtc_init_with_planes

[Maxime Ripard]

On Tue, Jun 14, 2022 at 10:29:20AM +0200, Thomas Zimmermann wrote:
> Hi
> 
> Am 14.06.22 um 09:37 schrieb Maxime Ripard:
> > Hi Thomas,
> > 
> > On Mon, Jun 13, 2022 at 01:23:54PM +0200, Thomas Zimmermann wrote:
> > > Am 10.06.22 um 11:28 schrieb Maxime Ripard:
> > > > The DRM-managed function to register a CRTC is
> > > > drmm_crtc_alloc_with_planes(), which will allocate the underlying
> > > > structure and initialisation the CRTC.
> > > > 
> > > > However, we might want to separate the structure creation and the CRTC
> > > > initialisation, for example if the structure is shared across multiple
> > > > DRM entities, for example an encoder and a connector.
> > > > 
> > > > Let's create an helper to only initialise a CRTC that would be passed as
> > > > an argument.
> > > 
> > > Before I review all of thes patches, one question. it's yet not clear to 
> > > me
> > > why drm_crtc_init_with_planes() wouldn't work. (I know we discussed this 
> > > on
> > > IRC.)
> > > 
> > > If you're calling drmm_mode_config_init(), it will clean up all the CRTC,
> > > encoder connector, etc. data structures for you. For CRTC instances in
> > > kmalloced memory, wouldn't it be simpler to put the corresponding kfree 
> > > into
> > > vc4_crtc_destroy()?
> > 
> > My intent was to remove as much of the lifetime handling and
> > memory-management from drivers as possible.
> > 
> > My feeling is that while the solution you suggest would definitely work,
> > it relies on drivers authors to know about this, and make the effort to
> > convert the drivers themselves. And then we would have to review that,
> > which we will probably miss (collectively), because it's a bit obscure.
> > 
> > While with either the drmm_alloc_* functions, or the new functions I
> > introduce there, we can just deprecate the old ones, create a TODO entry
> > and a coccinelle script and trust that it works properly.
> 
> Thanks for explaining the motivation.
> 
> I would not want to deprecate any of the existing functions, as they work
> for many drivers. The drmm_ functions add additional overhead that not
> everyone is willing to pay.

I'm a bit confused. drm_crtc_init_with_planes() at the moment has:

* Note: consider using drmm_crtc_alloc_with_planes() instead of
* drm_crtc_init_with_planes() to let the DRM managed resource infrastructure
* take care of cleanup and deallocation.

Just like drm_encoder_init(), drm_simple_encoder_init() and
drm_universal_plane_init(), so all the functions we have a drmm_* helper
for.

And we have a TODO-list item that heavily hints at using them:
https://dri.freedesktop.org/docs/drm/gpu/todo.html#object-lifetime-fixes

So it looks like we're already well on the deprecation path?

Maxime


signature.asc
Description: PGP signature

Re: [PATCH v2 7/7] drm/bridge: anx7625: Add typec_mux_set callback function

[Pin-yen Lin]

Hi AngeloGioacchino,


On Tue, Jun 14, 2022 at 4:15 PM AngeloGioacchino Del Regno
 wrote:
>
> Il 09/06/22 20:09, Prashant Malani ha scritto:
> > From: Pin-Yen Lin 
> >
> > Add the callback function when the driver receives state
> > changes of the Type-C port. The callback function configures the
> > crosspoint switch of the anx7625 bridge chip, which can change the
> > output pins of the signals according to the port state.
> >
> > Signed-off-by: Pin-Yen Lin 
> > Signed-off-by: Prashant Malani 
> > ---
> >
> > Changes since v2:
> > - No changes.
> >
> >   drivers/gpu/drm/bridge/analogix/anx7625.c | 58 +++
> >   drivers/gpu/drm/bridge/analogix/anx7625.h | 13 +
> >   2 files changed, 71 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c 
> > b/drivers/gpu/drm/bridge/analogix/anx7625.c
> > index d41a21103bd3..2c308d12fab2 100644
> > --- a/drivers/gpu/drm/bridge/analogix/anx7625.c
> > +++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
> > @@ -15,6 +15,7 @@
> >   #include 
> >   #include 
> >   #include 
> > +#include 
> >   #include 
> >   #include 
> >
> > @@ -2582,9 +2583,66 @@ static void anx7625_runtime_disable(void *data)
> >   pm_runtime_disable(data);
> >   }
> >
> > +static void anx7625_set_crosspoint_switch(struct anx7625_data *ctx,
> > +   enum typec_orientation orientation)
> > +{
> > + if (orientation == TYPEC_ORIENTATION_NORMAL) {
> > + anx7625_reg_write(ctx, ctx->i2c.tcpc_client, TCPC_SWITCH_0,
> > +   SW_SEL1_SSRX_RX1 | SW_SEL1_DPTX0_RX2);
> > + anx7625_reg_write(ctx, ctx->i2c.tcpc_client, TCPC_SWITCH_1,
> > +   SW_SEL2_SSTX_TX1 | SW_SEL2_DPTX1_TX2);
> > + } else if (orientation == TYPEC_ORIENTATION_REVERSE) {
> > + anx7625_reg_write(ctx, ctx->i2c.tcpc_client, TCPC_SWITCH_0,
> > +   SW_SEL1_SSRX_RX2 | SW_SEL1_DPTX0_RX1);
> > + anx7625_reg_write(ctx, ctx->i2c.tcpc_client, TCPC_SWITCH_1,
> > +   SW_SEL2_SSTX_TX2 | SW_SEL2_DPTX1_TX1);
> > + }
> > +}
> > +
> > +static void anx7625_typec_two_ports_update(struct anx7625_data *ctx)
> > +{
> > + if (ctx->typec_ports[0].dp_connected && 
> > ctx->typec_ports[1].dp_connected)
> > + /* Both ports available, do nothing to retain the current 
> > one. */
> > + return;
> > + else if (ctx->typec_ports[0].dp_connected)
> > + anx7625_set_crosspoint_switch(ctx, TYPEC_ORIENTATION_NORMAL);
> > + else if (ctx->typec_ports[1].dp_connected)
> > + anx7625_set_crosspoint_switch(ctx, TYPEC_ORIENTATION_REVERSE);
> > +}
> > +
> >   static int anx7625_typec_mux_set(struct typec_mux_dev *mux,
> >struct typec_mux_state *state)
> >   {
> > + struct anx7625_port_data *data = typec_mux_get_drvdata(mux);
> > + struct anx7625_data *ctx = data->ctx;
> > + struct device *dev = &ctx->client->dev;
> > +
> > + bool old_dp_connected = (ctx->typec_ports[0].dp_connected ||
> > +  ctx->typec_ports[1].dp_connected);
>
> So the old connection state is "either port0 or port1 are currently 
> connected"...
>
> > + bool new_dp_connected;
> > +
> > + if (ctx->num_typec_switches == 1)
> > + return 0;
> > +
> > + dev_dbg(dev, "mux_set dp_connected: c0=%d, c1=%d\n",
> > + ctx->typec_ports[0].dp_connected, 
> > ctx->typec_ports[1].dp_connected);
> > +
> > + data->dp_connected = (state->alt && state->alt->svid == 
> > USB_TYPEC_DP_SID &&
> > +   state->alt->mode == USB_TYPEC_DP_MODE);
> > + > + new_dp_connected = (ctx->typec_ports[0].dp_connected ||
> > + ctx->typec_ports[1].dp_connected);
>
> ...and the new connection state is the same as the old one, because I don't 
> see
> anything that could ever modify it in this function's flow, until reaching 
> this
> assignment.

The typec mux driver data (`struct anx7625_port_data *data =
typec_mux_get_drvdata(mux)`) is set to one of the
`ctx->typec_ports[*]` in `anx7625_register_mode_switch` (see patch 6
of this series).

So, the `data->dp_connected = ...` assignment may change the new
connection state.

Best regards,
Pin-yen

>
> > +
> > + /* dp on, power on first */
> > + if (!old_dp_connected && new_dp_connected)
> > + pm_runtime_get_sync(dev);
>
> ...so that will never happen...
>
> > +
> > + anx7625_typec_two_ports_update(ctx);
> > +
> > + /* dp off, power off last */
> > + if (old_dp_connected && !new_dp_connected)
> > + pm_runtime_put_sync(dev);
>
> ...and same here.
>
> Regards,
> Angelo

[PATCH] drm/dp/mst: Read the extended DPCD capabilities during system resume

[Imre Deak]

The WD22TB4 Thunderbolt dock at least will revert its DP_MAX_LINK_RATE
from HBR3 to HBR2 after system suspend/resume if the DP_DP13_DPCD_REV
registers are not read subsequently also as required.

Fix this by reading DP_DP13_DPCD_REV registers as well, matching what is
done during connector detection. While at it also fix up the same call
in drm_dp_mst_dump_topology().

Cc: Lyude Paul 
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5292
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/display/drm_dp_mst_topology.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c 
b/drivers/gpu/drm/display/drm_dp_mst_topology.c
index 67b3b9697da7f..18f2b6075b780 100644
--- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
@@ -3860,9 +3860,7 @@ int drm_dp_mst_topology_mgr_resume(struct 
drm_dp_mst_topology_mgr *mgr,
if (!mgr->mst_primary)
goto out_fail;
 
-   ret = drm_dp_dpcd_read(mgr->aux, DP_DPCD_REV, mgr->dpcd,
-  DP_RECEIVER_CAP_SIZE);
-   if (ret != DP_RECEIVER_CAP_SIZE) {
+   if (drm_dp_read_dpcd_caps(mgr->aux, mgr->dpcd) < 0) {
drm_dbg_kms(mgr->dev, "dpcd read failed - undocked during 
suspend?\n");
goto out_fail;
}
@@ -4911,8 +4909,7 @@ void drm_dp_mst_dump_topology(struct seq_file *m,
u8 buf[DP_PAYLOAD_TABLE_SIZE];
int ret;
 
-   ret = drm_dp_dpcd_read(mgr->aux, DP_DPCD_REV, buf, 
DP_RECEIVER_CAP_SIZE);
-   if (ret) {
+   if (drm_dp_read_dpcd_caps(mgr->aux, buf) < 0) {
seq_printf(m, "dpcd read failed\n");
goto out;
}
-- 
2.30.2

[PATCH v3 2/8] drm: Drop drm_framebuffer.h from drm_crtc.h

[Ville Syrjala]

From: Ville Syrjälä 

drm_crtc.h has no need for drm_frambuffer.h, so don't include it.
Avoids useless rebuilds of the entire universe when
touching drm_framebuffer.h.

Quite a few placs do currently depend on drm_framebuffer.h without
actually including it directly. All of those need to be fixed
up.

v2: Fix up msm some more
v2: Deal with ingenic and shmobile as well

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 1 +
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_trace.h  | 1 +
 drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c | 1 +
 drivers/gpu/drm/arm/hdlcd_crtc.c | 1 +
 drivers/gpu/drm/arm/malidp_crtc.c| 1 +
 drivers/gpu/drm/arm/malidp_mw.c  | 1 +
 drivers/gpu/drm/arm/malidp_planes.c  | 1 +
 drivers/gpu/drm/armada/armada_fb.h   | 2 ++
 drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c | 1 +
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c  | 1 +
 drivers/gpu/drm/drm_atomic.c | 1 +
 drivers/gpu/drm/drm_atomic_helper.c  | 1 +
 drivers/gpu/drm/drm_atomic_state_helper.c| 1 +
 drivers/gpu/drm/drm_atomic_uapi.c| 1 +
 drivers/gpu/drm/drm_crtc.c   | 1 +
 drivers/gpu/drm/drm_crtc_helper.c| 1 +
 drivers/gpu/drm/drm_damage_helper.c  | 1 +
 drivers/gpu/drm/drm_fb_helper.c  | 1 +
 drivers/gpu/drm/drm_gem_atomic_helper.c  | 1 +
 drivers/gpu/drm/drm_mipi_dbi.c   | 1 +
 drivers/gpu/drm/drm_mode_config.c| 1 +
 drivers/gpu/drm/drm_modeset_helper.c | 1 +
 drivers/gpu/drm/drm_writeback.c  | 1 +
 drivers/gpu/drm/exynos/exynos5433_drm_decon.c| 1 +
 drivers/gpu/drm/exynos/exynos7_drm_decon.c   | 1 +
 drivers/gpu/drm/exynos/exynos_drm_fb.c   | 1 +
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c| 1 +
 drivers/gpu/drm/exynos/exynos_drm_fimd.c | 1 +
 drivers/gpu/drm/exynos/exynos_drm_plane.c| 1 +
 drivers/gpu/drm/exynos/exynos_drm_vidi.c | 1 +
 drivers/gpu/drm/exynos/exynos_mixer.c| 1 +
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c  | 1 +
 drivers/gpu/drm/gma500/framebuffer.c | 1 +
 drivers/gpu/drm/gma500/gma_display.c | 1 +
 drivers/gpu/drm/gma500/oaktrail_crtc.c   | 1 +
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c  | 1 +
 drivers/gpu/drm/i915/display/intel_display_types.h   | 1 +
 drivers/gpu/drm/imx/dcss/dcss-plane.c| 1 +
 drivers/gpu/drm/imx/ipuv3-plane.c| 1 +
 drivers/gpu/drm/ingenic/ingenic-drm-drv.c| 1 +
 drivers/gpu/drm/ingenic/ingenic-ipu.c| 1 +
 drivers/gpu/drm/kmb/kmb_plane.c  | 1 +
 drivers/gpu/drm/logicvc/logicvc_layer.c  | 1 +
 drivers/gpu/drm/mcde/mcde_display.c  | 1 +
 drivers/gpu/drm/mediatek/mtk_disp_ovl.c  | 1 +
 drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 2 ++
 drivers/gpu/drm/mediatek/mtk_drm_plane.c | 1 +
 drivers/gpu/drm/meson/meson_overlay.c| 1 +
 drivers/gpu/drm/meson/meson_plane.c  | 1 +
 drivers/gpu/drm/mgag200/mgag200_mode.c   | 1 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 1 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c  | 2 ++
 drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c  | 1 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c  | 1 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c| 1 +
 drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c   | 1 +
 drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c   | 1 +
 drivers/gpu/drm/msm/disp/mdp_format.c| 2 ++
 drivers/gpu/drm/msm/msm_debugfs.c| 1 +
 drivers/gpu/drm/msm/msm_fb.c | 1 +
 drivers/gpu/drm/msm/msm_fbdev.c  | 1 +
 drivers/gpu/drm/mxsfb/mxsfb_kms.c| 1 +
 drivers/gpu/drm/omapdrm/omap_debugfs.c   | 1 +
 drivers/gpu/drm/omapdrm/omap_fb.c| 1 +
 drivers/gpu/drm/omapdrm/omap_fbdev.c | 1 +
 drivers/gpu/drm/omapdrm/omap_plane.c | 1 +
 drivers/gpu/drm/pl111/pl111_display.c| 1 +
 drivers/gpu/drm/pl111/pl111_drv.c| 1 +
 drivers/gpu/drm/pl111/pl111_versatile.c  | 2 ++
 drivers/gpu/drm/qxl/qxl_display.c| 1 +
 drivers/gpu/drm/qxl/qxl_draw.c   | 1 +
 drivers/gpu/drm/radeon/atombios_crtc.c 

[PATCH v3 7/8] drm: Remove linux/media-bus-format.h from drm_crtc.h

[Ville Syrjala]

From: Ville Syrjälä 

drm_crtc.h has no need for linux/media-bus-format.h, so don't
include it. Avoids useless rebuilds of the entire universe when
touching linux/media-bus-format.h.

Quite a few placs do currently depend on linux/media-bus-format.h
without actually including it directly. All of those need to be
fixed up.

v2: Deal with ingenic as well

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c| 1 +
 drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c   | 1 +
 drivers/gpu/drm/bridge/chipone-icn6211.c  | 1 +
 drivers/gpu/drm/bridge/display-connector.c| 1 +
 drivers/gpu/drm/bridge/fsl-ldb.c  | 1 +
 drivers/gpu/drm/bridge/ite-it66121.c  | 1 +
 drivers/gpu/drm/bridge/lontium-lt8912b.c  | 1 +
 drivers/gpu/drm/bridge/lontium-lt9211.c   | 1 +
 drivers/gpu/drm/bridge/lontium-lt9611.c   | 1 +
 drivers/gpu/drm/bridge/nwl-dsi.c  | 1 +
 drivers/gpu/drm/bridge/sii902x.c  | 1 +
 drivers/gpu/drm/bridge/tc358767.c | 1 +
 drivers/gpu/drm/bridge/tc358775.c | 1 +
 drivers/gpu/drm/bridge/ti-dlpc3433.c  | 1 +
 drivers/gpu/drm/bridge/ti-sn65dsi83.c | 1 +
 drivers/gpu/drm/bridge/ti-tfp410.c| 1 +
 drivers/gpu/drm/drm_bridge.c  | 1 +
 drivers/gpu/drm/drm_of.c  | 1 +
 drivers/gpu/drm/imx/imx-ldb.c | 1 +
 drivers/gpu/drm/imx/parallel-display.c| 1 +
 drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 1 +
 drivers/gpu/drm/mediatek/mtk_dpi.c| 1 +
 drivers/gpu/drm/mxsfb/mxsfb_kms.c | 1 +
 drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c | 1 +
 drivers/gpu/drm/panel/panel-raydium-rm67191.c | 1 +
 drivers/gpu/drm/panel/panel-seiko-43wvf1g.c   | 1 +
 drivers/gpu/drm/panel/panel-simple.c  | 1 +
 drivers/gpu/drm/pl111/pl111_display.c | 1 +
 drivers/gpu/drm/rcar-du/rcar_lvds.c   | 1 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop2.c  | 1 +
 drivers/gpu/drm/rockchip/rockchip_rgb.c   | 1 +
 drivers/gpu/drm/stm/ltdc.c| 1 +
 drivers/gpu/drm/sun4i/sun4i_tcon.c| 1 +
 drivers/gpu/drm/tidss/tidss_dispc.c   | 1 +
 drivers/gpu/drm/vc4/vc4_dpi.c | 1 +
 include/drm/drm_crtc.h| 1 -
 36 files changed, 35 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
index cfe4fc69277e..58184cd6ab0b 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
@@ -8,6 +8,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c 
b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
index ba5f695703dc..ab63e7b11944 100644
--- a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
+++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpu/drm/bridge/chipone-icn6211.c 
b/drivers/gpu/drm/bridge/chipone-icn6211.c
index d25bc62bfebd..481c86b2406e 100644
--- a/drivers/gpu/drm/bridge/chipone-icn6211.c
+++ b/drivers/gpu/drm/bridge/chipone-icn6211.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpu/drm/bridge/display-connector.c 
b/drivers/gpu/drm/bridge/display-connector.c
index e4d52a7e31b7..9a12449ad7b8 100644
--- a/drivers/gpu/drm/bridge/display-connector.c
+++ b/drivers/gpu/drm/bridge/display-connector.c
@@ -6,6 +6,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpu/drm/bridge/fsl-ldb.c b/drivers/gpu/drm/bridge/fsl-ldb.c
index b2675c769a55..8d091521ccba 100644
--- a/drivers/gpu/drm/bridge/fsl-ldb.c
+++ b/drivers/gpu/drm/bridge/fsl-ldb.c
@@ -4,6 +4,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpu/drm/bridge/ite-it66121.c 
b/drivers/gpu/drm/bridge/ite-it66121.c
index 448c58e60c11..44278d54d35d 100644
--- a/drivers/gpu/drm/bridge/ite-it66121.c
+++ b/drivers/gpu/drm/bridge/ite-it66121.c
@@ -7,6 +7,7 @@
  *
  */
 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpu/drm/bridge/lontium-lt8912b.c 
b/drivers/gpu/drm/bridge/lontium-lt8912b.c
index 6a7a6983e796..28bad30dc4e5 100644
--- a/drivers/gpu/drm/bridge/lontium-lt8912b.c
+++ b/drivers/gpu/drm/bridge/lontium-lt8912b.c
@@ -7,6 +7,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
diff --git a/drivers/gpu/drm/bridge/lontium-lt9211.c 
b/drivers/gpu/drm/bridge/lontium-lt9211.c
index 84d764b4139b..

[PATCH v2 1/2] drm/bridge: ti-sn65dsi83: add more dev_err_probe

[Alexander Stein]

Add more warning/debug messages during probe. E.g. a single -EPROBE_DEFER
might have several causes, these messages help finding the origin.

Signed-off-by: Alexander Stein 
---
* New in v2

 drivers/gpu/drm/bridge/ti-sn65dsi83.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c 
b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
index b27c0d7c451a..a306150a8027 100644
--- a/drivers/gpu/drm/bridge/ti-sn65dsi83.c
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
@@ -677,7 +677,7 @@ static int sn65dsi83_probe(struct i2c_client *client,
ctx->enable_gpio = devm_gpiod_get_optional(ctx->dev, "enable",
   GPIOD_OUT_LOW);
if (IS_ERR(ctx->enable_gpio))
-   return PTR_ERR(ctx->enable_gpio);
+   return dev_err_probe(dev, PTR_ERR(ctx->enable_gpio), "failed to 
get enable GPIO\n");
 
usleep_range(1, 11000);
 
@@ -687,7 +687,7 @@ static int sn65dsi83_probe(struct i2c_client *client,
 
ctx->regmap = devm_regmap_init_i2c(client, &sn65dsi83_regmap_config);
if (IS_ERR(ctx->regmap))
-   return PTR_ERR(ctx->regmap);
+   return dev_err_probe(dev, PTR_ERR(ctx->regmap), "failed to get 
regmap\n");
 
dev_set_drvdata(dev, ctx);
i2c_set_clientdata(client, ctx);
-- 
2.25.1

[PATCH v2 2/2] drm/bridge: ti-sn65dsi83: Allow GPIO operations to sleep

[Alexander Stein]

There is no need to require non-sleeping GPIO access. Silence the
WARN_ON() if GPIO is using e.g. I2C expanders.

Signed-off-by: Alexander Stein 
---
Change in v2:
* None

 drivers/gpu/drm/bridge/ti-sn65dsi83.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c 
b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
index a306150a8027..dc26640e7d9b 100644
--- a/drivers/gpu/drm/bridge/ti-sn65dsi83.c
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
@@ -344,7 +344,7 @@ static void sn65dsi83_atomic_enable(struct drm_bridge 
*bridge,
}
 
/* Deassert reset */
-   gpiod_set_value(ctx->enable_gpio, 1);
+   gpiod_set_value_cansleep(ctx->enable_gpio, 1);
usleep_range(1000, 1100);
 
/* Get the LVDS format from the bridge state. */
@@ -500,7 +500,7 @@ static void sn65dsi83_atomic_disable(struct drm_bridge 
*bridge,
int ret;
 
/* Put the chip in reset, pull EN line low, and assure 10ms reset low 
timing. */
-   gpiod_set_value(ctx->enable_gpio, 0);
+   gpiod_set_value_cansleep(ctx->enable_gpio, 0);
usleep_range(1, 11000);
 
ret = regulator_disable(ctx->vcc);
-- 
2.25.1

Re: [PATCH] drm/msm/mdp4: Fix refcount leak in mdp4_modeset_init_intf

[Miaoqian Lin]

Hi, Abhinav

On 2022/6/11 7:20, Abhinav Kumar wrote:
>
>
> On 6/7/2022 4:08 AM, Miaoqian Lin wrote:
>> of_graph_get_remote_node() returns remote device node pointer with
>> refcount incremented, we should use of_node_put() on it
>> when not need anymore.
>> Add missing of_node_put() to avoid refcount leak.
>>
>> Fixes: 86418f90a4c1 ("drm: convert drivers to use of_graph_get_remote_node")
>> Signed-off-by: Miaoqian Lin 
>> ---
>>   drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c | 2 ++
>>   1 file changed, 2 insertions(+)
>>
>
> This patch itself looks fine and will cover the cases when there was an error 
> and we did not release the refcount.
>
> But, even in the normal cases I am not finding where we are releasing the 
> refcount for the panel_node.
>
> I dont see a of_node_put() on mdp4_lcdc_encoder->panel_node.
>
Thanks for your review.

I don't see it either. It's a bit messy because the reference assigned to 
mdp4_lcdc_encoder->panel_node and mdp4_lvds_connector->panel_node both.

> Am i missing something?
>
>> diff --git a/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c 
>> b/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
>> index fb48c8c19ec3..17cb1fc78379 100644
>> --- a/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
>> +++ b/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
>> @@ -216,6 +216,7 @@ static int mdp4_modeset_init_intf(struct mdp4_kms 
>> *mdp4_kms,
>>   encoder = mdp4_lcdc_encoder_init(dev, panel_node);
>>   if (IS_ERR(encoder)) {
>>   DRM_DEV_ERROR(dev->dev, "failed to construct LCDC encoder\n");
>> +    of_node_put(panel_node);
>>   return PTR_ERR(encoder);
>>   }
>>   @@ -225,6 +226,7 @@ static int mdp4_modeset_init_intf(struct mdp4_kms 
>> *mdp4_kms,
>>   connector = mdp4_lvds_connector_init(dev, panel_node, encoder);
>>   if (IS_ERR(connector)) {
>>   DRM_DEV_ERROR(dev->dev, "failed to initialize LVDS 
>> connector\n");
>> +    of_node_put(panel_node);
>>   return PTR_ERR(connector);
>>   }
>>   

Re: [PATCH] drm/msm/mdp4: Fix refcount leak in mdp4_modeset_init_intf

[Dmitry Baryshkov]

On 14/06/2022 13:07, Miaoqian Lin wrote:

Hi, Abhinav

On 2022/6/11 7:20, Abhinav Kumar wrote:



On 6/7/2022 4:08 AM, Miaoqian Lin wrote:

of_graph_get_remote_node() returns remote device node pointer with
refcount incremented, we should use of_node_put() on it
when not need anymore.
Add missing of_node_put() to avoid refcount leak.

Fixes: 86418f90a4c1 ("drm: convert drivers to use of_graph_get_remote_node")
Signed-off-by: Miaoqian Lin 
---
   drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c | 2 ++
   1 file changed, 2 insertions(+)



This patch itself looks fine and will cover the cases when there was an error 
and we did not release the refcount.

But, even in the normal cases I am not finding where we are releasing the 
refcount for the panel_node.

I dont see a of_node_put() on mdp4_lcdc_encoder->panel_node.


Thanks for your review.

I don't see it either. It's a bit messy because the reference assigned to 
mdp4_lcdc_encoder->panel_node and mdp4_lvds_connector->panel_node both.


I have a plan to rework mdp4 lcdc support once I get my ifc6410 lvds 
cable. Thus I think we can land this patch now and fix the mdp4 
lcdc/lvds code leaking the reference in the due time.





Am i missing something?


diff --git a/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c 
b/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
index fb48c8c19ec3..17cb1fc78379 100644
--- a/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
+++ b/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
@@ -216,6 +216,7 @@ static int mdp4_modeset_init_intf(struct mdp4_kms *mdp4_kms,
   encoder = mdp4_lcdc_encoder_init(dev, panel_node);
   if (IS_ERR(encoder)) {
   DRM_DEV_ERROR(dev->dev, "failed to construct LCDC encoder\n");
+    of_node_put(panel_node);
   return PTR_ERR(encoder);
   }
   @@ -225,6 +226,7 @@ static int mdp4_modeset_init_intf(struct mdp4_kms 
*mdp4_kms,
   connector = mdp4_lvds_connector_init(dev, panel_node, encoder);
   if (IS_ERR(connector)) {
   DRM_DEV_ERROR(dev->dev, "failed to initialize LVDS connector\n");
+    of_node_put(panel_node);
   return PTR_ERR(connector);
   }
   



--
With best wishes
Dmitry

Re: [PATCH 02/64] drm/crtc: Introduce drmm_crtc_init_with_planes

[Thomas Zimmermann]

Hi Maxime

Am 14.06.22 um 11:04 schrieb Maxime Ripard:

On Tue, Jun 14, 2022 at 10:29:20AM +0200, Thomas Zimmermann wrote:

Hi

Am 14.06.22 um 09:37 schrieb Maxime Ripard:

Hi Thomas,

On Mon, Jun 13, 2022 at 01:23:54PM +0200, Thomas Zimmermann wrote:

Am 10.06.22 um 11:28 schrieb Maxime Ripard:

The DRM-managed function to register a CRTC is
drmm_crtc_alloc_with_planes(), which will allocate the underlying
structure and initialisation the CRTC.

However, we might want to separate the structure creation and the CRTC
initialisation, for example if the structure is shared across multiple
DRM entities, for example an encoder and a connector.

Let's create an helper to only initialise a CRTC that would be passed as
an argument.


Before I review all of thes patches, one question. it's yet not clear to me
why drm_crtc_init_with_planes() wouldn't work. (I know we discussed this on
IRC.)

If you're calling drmm_mode_config_init(), it will clean up all the CRTC,
encoder connector, etc. data structures for you. For CRTC instances in
kmalloced memory, wouldn't it be simpler to put the corresponding kfree into
vc4_crtc_destroy()?


My intent was to remove as much of the lifetime handling and
memory-management from drivers as possible.

My feeling is that while the solution you suggest would definitely work,
it relies on drivers authors to know about this, and make the effort to
convert the drivers themselves. And then we would have to review that,
which we will probably miss (collectively), because it's a bit obscure.

While with either the drmm_alloc_* functions, or the new functions I
introduce there, we can just deprecate the old ones, create a TODO entry
and a coccinelle script and trust that it works properly.


Thanks for explaining the motivation.

I would not want to deprecate any of the existing functions, as they work
for many drivers. The drmm_ functions add additional overhead that not
everyone is willing to pay.


I'm a bit confused. drm_crtc_init_with_planes() at the moment has:

* Note: consider using drmm_crtc_alloc_with_planes() instead of
* drm_crtc_init_with_planes() to let the DRM managed resource infrastructure
* take care of cleanup and deallocation.

Just like drm_encoder_init(), drm_simple_encoder_init() and
drm_universal_plane_init(), so all the functions we have a drmm_* helper
for.

And we have a TODO-list item that heavily hints at using them:
https://dri.freedesktop.org/docs/drm/gpu/todo.html#object-lifetime-fixes

So it looks like we're already well on the deprecation path?


AFAIU that TODO item is about replacing devm_kzalloc() with 
drmm_kzalloc(). It's not about the plain init functions, such as 
drm_crtc_init_with_planes() or drm_universal_plane_init(). Many simple 
drivers allocate their modesetting pipeline's components first and then 
build the pipeline with the drm_ functions. I don't think we can take 
that away from them.


The concern I have is that we're adding lots of helpers for all kind of 
scenarios and end up with a lot of duplication (and fragmentation among 
drivers). For example, drmm_crtc_alloc_with_planes() really isn't much 
used by anything. [1] Same for drmm_universal_plane_alloc(). [2]


Instead of adding new helpers, it would be better to build upon 
drmm_crtc_alloc_with_planes(), drmm_univeral_plane_alloc(), etc.


For example, a good starting point would be vc4_plane_init(). It could 
alloc with drmm_univeral_plane_alloc(), which would replace 
devm_kzalloc() [3] and drm_univeral_plane_alloc() [4] in one step. From 
what I understand, that's what your patchset wants to do. But it looks 
like you're effectively open-coding drmm_universl_plane_alloc().


With vc4_plane_init() correctly managed, the next candidate could be 
vc4_crtc_init(). You probably want to pull vc4_plane_init() [5] into 
callers. to get it out of the way. If you move calls to devm_kzalloc() 
[6] and drm_crtc_init_with_planes() [7] closer together, you can replace 
them with drmm_crtc_alloc_with_planes().


Best regards
Thomas


[1] 
https://elixir.bootlin.com/linux/latest/C/ident/drmm_crtc_alloc_with_planes
[2] 
https://elixir.bootlin.com/linux/latest/A/ident/drmm_universal_plane_alloc
[3] 
https://elixir.bootlin.com/linux/v5.18.3/source/drivers/gpu/drm/vc4/vc4_plane.c#L1478
[4] 
https://elixir.bootlin.com/linux/v5.18.3/source/drivers/gpu/drm/vc4/vc4_plane.c#L1491
[5] 
https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/vc4/vc4_crtc.c#L1135
[6] 
https://elixir.bootlin.com/linux/v5.18.3/source/drivers/gpu/drm/vc4/vc4_crtc.c#L1176
[7] 
https://elixir.bootlin.com/linux/v5.18.3/source/drivers/gpu/drm/vc4/vc4_crtc.c#L1142






Maxime


--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev


OpenPGP_signature
Description: OpenPGP digital signature

[bug report] drm: Add support for the LogiCVC display controller

[Dan Carpenter]

Hello Paul Kocialkowski,

The patch efeeaefe9be5: "drm: Add support for the LogiCVC display
controller" from May 20, 2022, leads to the following Smatch static
checker warning:

drivers/gpu/drm/logicvc/logicvc_layer.c:320 
logicvc_layer_buffer_find_setup()
warn: impossible condition '(hoffset > (1))) << (16)) - 1)) => 
(0-u16max > u16max)'

drivers/gpu/drm/logicvc/logicvc_layer.c
258 int logicvc_layer_buffer_find_setup(struct logicvc_drm *logicvc,
259 struct logicvc_layer *layer,
260 struct drm_plane_state *state,
261 struct logicvc_layer_buffer_setup 
*setup)
262 {
263 struct drm_device *drm_dev = &logicvc->drm_dev;
264 struct drm_framebuffer *fb = state->fb;
265 /* All the supported formats have a single data plane. */
266 u32 layer_bytespp = fb->format->cpp[0];
267 u32 layer_stride = layer_bytespp * logicvc->config.row_stride;
268 u32 base_offset = layer->config.base_offset * layer_stride;
269 u32 buffer_offset = layer->config.buffer_offset * layer_stride;
270 u8 buffer_sel = 0;
271 u16 voffset = 0;
272 u16 hoffset = 0;
273 phys_addr_t fb_addr;
274 u32 fb_offset;
275 u32 gap;
276 
277 if (!logicvc->reserved_mem_base) {
278 drm_err(drm_dev, "No reserved memory base was 
registered!\n");
279 return -ENOMEM;
280 }
281 
282 fb_addr = drm_fb_cma_get_gem_addr(fb, state, 0);
283 if (fb_addr < logicvc->reserved_mem_base) {
284 drm_err(drm_dev,
285 "Framebuffer memory below reserved memory 
base!\n");
286 return -EINVAL;
287 }
288 
289 fb_offset = (u32) (fb_addr - logicvc->reserved_mem_base);
290 
291 if (fb_offset < base_offset) {
292 drm_err(drm_dev,
293 "Framebuffer offset below layer base 
offset!\n");
294 return -EINVAL;
295 }
296 
297 gap = fb_offset - base_offset;
298 
299 /* Use the possible video buffers selection. */
300 if (gap && buffer_offset) {
301 buffer_sel = gap / buffer_offset;
302 if (buffer_sel > LOGICVC_BUFFER_SEL_MAX)
303 buffer_sel = LOGICVC_BUFFER_SEL_MAX;
304 
305 gap -= buffer_sel * buffer_offset;
306 }
307 
308 /* Use the vertical offset. */
309 if (gap && layer_stride && logicvc->config.layers_configurable) 
{
310 voffset = gap / layer_stride;
311 if (voffset > LOGICVC_LAYER_VOFFSET_MAX)
312 voffset = LOGICVC_LAYER_VOFFSET_MAX;
313 
314 gap -= voffset * layer_stride;
315 }
316 
317 /* Use the horizontal offset. */
318 if (gap && layer_bytespp && 
logicvc->config.layers_configurable) {
319 hoffset = gap / layer_bytespp;

Can "gap / layer_bytespp" ever be more than USHRT_MAX?  Because if so
that won't fit into "hoffset"

--> 320 if (hoffset > LOGICVC_DIMENSIONS_MAX)
321 hoffset = LOGICVC_DIMENSIONS_MAX;
322 
323 gap -= hoffset * layer_bytespp;
324 }
325 
326 if (gap) {
327 drm_err(drm_dev,
328 "Unable to find layer %d buffer setup for 0x%x 
byte gap\n",
329 layer->index, fb_offset - base_offset);
330 return -EINVAL;
331 }
332 
333 drm_dbg_kms(drm_dev, "Found layer %d buffer setup for 0x%x byte 
gap:\n",
334 layer->index, fb_offset - base_offset);
335 
336 drm_dbg_kms(drm_dev, "- buffer_sel = 0x%x chunks of 0x%x 
bytes\n",
337 buffer_sel, buffer_offset);
338 drm_dbg_kms(drm_dev, "- voffset = 0x%x chunks of 0x%x bytes\n", 
voffset,
339 layer_stride);
340 drm_dbg_kms(drm_dev, "- hoffset = 0x%x chunks of 0x%x bytes\n", 
hoffset,
341 layer_bytespp);
342 
343 if (setup) {
344 setup->buffer_sel = buffer_sel;
345 setup->voffset = voffset;
346 setup->hoffset = hoffset;
347 }
348 
349 return 0;
350 }

regards,
dan carpenter

[PATCH] drm: logicvc: Fix uninitialized variable in probe

[Dan Carpenter]

The "regmap" is supposed to be initialized to NULL but it's used
without being initialized.

Fixes: efeeaefe9be5 ("drm: Add support for the LogiCVC display controller")
Signed-off-by: Dan Carpenter 
---
 drivers/gpu/drm/logicvc/logicvc_drm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/logicvc/logicvc_drm.c 
b/drivers/gpu/drm/logicvc/logicvc_drm.c
index df1805cf0f95..0b983a33f9ff 100644
--- a/drivers/gpu/drm/logicvc/logicvc_drm.c
+++ b/drivers/gpu/drm/logicvc/logicvc_drm.c
@@ -298,7 +298,7 @@ static int logicvc_drm_probe(struct platform_device *pdev)
struct logicvc_drm *logicvc;
struct device *dev = &pdev->dev;
struct drm_device *drm_dev;
-   struct regmap *regmap;
+   struct regmap *regmap = NULL;
struct resource res;
void __iomem *base;
int irq;
-- 
2.35.1

[PATCH] drm: logicvc: fix error code in logicvc_layer_init()

[Dan Carpenter]

Return -EINVAL if logicvc_layer_formats_lookup() fails.  Don't return
success.

Fixes: efeeaefe9be5 ("drm: Add support for the LogiCVC display controller")
Signed-off-by: Dan Carpenter 
---
 drivers/gpu/drm/logicvc/logicvc_layer.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/logicvc/logicvc_layer.c 
b/drivers/gpu/drm/logicvc/logicvc_layer.c
index bae1c7f99569..9c94b67afbed 100644
--- a/drivers/gpu/drm/logicvc/logicvc_layer.c
+++ b/drivers/gpu/drm/logicvc/logicvc_layer.c
@@ -489,6 +489,7 @@ static int logicvc_layer_init(struct logicvc_drm *logicvc,
if (!formats) {
drm_err(drm_dev, "Failed to lookup formats for layer #%d\n",
index);
+   ret = -EINVAL;
goto error;
}
 
-- 
2.35.1

Re: [PATCH 02/64] drm/crtc: Introduce drmm_crtc_init_with_planes

[Maxime Ripard]

On Tue, Jun 14, 2022 at 01:47:28PM +0200, Thomas Zimmermann wrote:
> Am 14.06.22 um 11:04 schrieb Maxime Ripard:
> > On Tue, Jun 14, 2022 at 10:29:20AM +0200, Thomas Zimmermann wrote:
> > > Am 14.06.22 um 09:37 schrieb Maxime Ripard:
> > > > Hi Thomas,
> > > > 
> > > > On Mon, Jun 13, 2022 at 01:23:54PM +0200, Thomas Zimmermann wrote:
> > > > > Am 10.06.22 um 11:28 schrieb Maxime Ripard:
> > > > > > The DRM-managed function to register a CRTC is
> > > > > > drmm_crtc_alloc_with_planes(), which will allocate the underlying
> > > > > > structure and initialisation the CRTC.
> > > > > > 
> > > > > > However, we might want to separate the structure creation and the 
> > > > > > CRTC
> > > > > > initialisation, for example if the structure is shared across 
> > > > > > multiple
> > > > > > DRM entities, for example an encoder and a connector.
> > > > > > 
> > > > > > Let's create an helper to only initialise a CRTC that would be 
> > > > > > passed as
> > > > > > an argument.
> > > > > 
> > > > > Before I review all of thes patches, one question. it's yet not clear 
> > > > > to me
> > > > > why drm_crtc_init_with_planes() wouldn't work. (I know we discussed 
> > > > > this on
> > > > > IRC.)
> > > > > 
> > > > > If you're calling drmm_mode_config_init(), it will clean up all the 
> > > > > CRTC,
> > > > > encoder connector, etc. data structures for you. For CRTC instances in
> > > > > kmalloced memory, wouldn't it be simpler to put the corresponding 
> > > > > kfree into
> > > > > vc4_crtc_destroy()?
> > > > 
> > > > My intent was to remove as much of the lifetime handling and
> > > > memory-management from drivers as possible.
> > > > 
> > > > My feeling is that while the solution you suggest would definitely work,
> > > > it relies on drivers authors to know about this, and make the effort to
> > > > convert the drivers themselves. And then we would have to review that,
> > > > which we will probably miss (collectively), because it's a bit obscure.
> > > > 
> > > > While with either the drmm_alloc_* functions, or the new functions I
> > > > introduce there, we can just deprecate the old ones, create a TODO entry
> > > > and a coccinelle script and trust that it works properly.
> > > 
> > > Thanks for explaining the motivation.
> > > 
> > > I would not want to deprecate any of the existing functions, as they work
> > > for many drivers. The drmm_ functions add additional overhead that not
> > > everyone is willing to pay.
> > 
> > I'm a bit confused. drm_crtc_init_with_planes() at the moment has:
> > 
> > * Note: consider using drmm_crtc_alloc_with_planes() instead of
> > * drm_crtc_init_with_planes() to let the DRM managed resource infrastructure
> > * take care of cleanup and deallocation.
> > 
> > Just like drm_encoder_init(), drm_simple_encoder_init() and
> > drm_universal_plane_init(), so all the functions we have a drmm_* helper
> > for.
> > 
> > And we have a TODO-list item that heavily hints at using them:
> > https://dri.freedesktop.org/docs/drm/gpu/todo.html#object-lifetime-fixes
> > 
> > So it looks like we're already well on the deprecation path?
> 
> AFAIU that TODO item is about replacing devm_kzalloc() with drmm_kzalloc().
> It's not about the plain init functions, such as drm_crtc_init_with_planes()
> or drm_universal_plane_init(). Many simple drivers allocate their
> modesetting pipeline's components first and then build the pipeline with the
> drm_ functions. I don't think we can take that away from them.

Sure, that's exactly what those first patches are about? It allows to
use a DRM managed initialization without disrupting the drivers
structure too much?

> The concern I have is that we're adding lots of helpers for all kind of
> scenarios and end up with a lot of duplication (and fragmentation among
> drivers).

I can see two: whether you want to allocate / init, or just init?
We're not going to have more than that.

> For example, drmm_crtc_alloc_with_planes() really isn't much used
> by anything. [1]

Not that I disagree here, but it might be that it isn't the most helpful
helper?

In vc4 case, we just can't use it easily.

Our CRTC driver is shared between the "regular" CRTCs in the display
path, and another instance dedicated to the writeback connector.

The shared stuff is initialized through vc4_crtc_init():
https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/vc4/vc4_crtc.c#L1120

It initializes the structure, set up the planes, etc. Basically
everything that our CRTC controller will be doing, and would be shared
by both cases.

However, since the writeback and regular CRTC structures are different,
we can't really make that function allocate the backing structure
either.

We could do some compiler magic to pass the total size and the offset to
that function, just like what drmm_crtc_alloc_with_planes is doing, but
then we would have the same issue with the writeback stuff that needs to
initialize the encoder and connector.

So we would need a drmm_encoder_init anyway.

[PATCH] drm: fix an error code in drm_syncobj_transfer_to_timeline()

[Dan Carpenter]

Return -ENOMEM instead of success if dma_fence_unwrap_merge() fails.

Fixes: ec8d985ff26f ("drm: use dma_fence_unwrap_merge() in drm_syncobj")
Signed-off-by: Dan Carpenter 
---
 drivers/gpu/drm/drm_syncobj.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index bbad9e4696e7..0c2be8360525 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -874,8 +874,10 @@ static int drm_syncobj_transfer_to_timeline(struct 
drm_file *file_private,
 
fence = dma_fence_unwrap_merge(tmp);
dma_fence_put(tmp);
-   if (!fence)
+   if (!fence) {
+   ret = -ENOMEM;
goto err_put_timeline;
+   }
 
chain = dma_fence_chain_alloc();
if (!chain) {
-- 
2.35.1

Re: [PATCH] drm: fix an error code in drm_syncobj_transfer_to_timeline()

[Christian König]

Am 14.06.22 um 14:10 schrieb Dan Carpenter:

Return -ENOMEM instead of success if dma_fence_unwrap_merge() fails.


You are to late Dan, that one was already reported and fixed 
https://lore.kernel.org/lkml/4845ad23-476c-97b9-9b3f-d8aaa9027...@amd.com/T/


Interesting that now the automated checkers are racing on finding and 
fixing those things :)


Christian.



Fixes: ec8d985ff26f ("drm: use dma_fence_unwrap_merge() in drm_syncobj")
Signed-off-by: Dan Carpenter 
---
  drivers/gpu/drm/drm_syncobj.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index bbad9e4696e7..0c2be8360525 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -874,8 +874,10 @@ static int drm_syncobj_transfer_to_timeline(struct 
drm_file *file_private,
  
  	fence = dma_fence_unwrap_merge(tmp);

dma_fence_put(tmp);
-   if (!fence)
+   if (!fence) {
+   ret = -ENOMEM;
goto err_put_timeline;
+   }
  
  	chain = dma_fence_chain_alloc();

if (!chain) {

Re: [PATCH] drm/dp/mst: Read the extended DPCD capabilities during system resume

[Jani Nikula]

On Tue, 14 Jun 2022, Imre Deak  wrote:
> The WD22TB4 Thunderbolt dock at least will revert its DP_MAX_LINK_RATE
> from HBR3 to HBR2 after system suspend/resume if the DP_DP13_DPCD_REV
> registers are not read subsequently also as required.

Does it actually change the behaviour depending on whether the dpcd is
read or not, or is this just about the resume path overwriting mgr->dpcd
with stuff from DP_DPCD_REV?

drm_dp_mst_topology_mgr_set_mst() does use drm_dp_read_dpcd_caps() for
reading the caps, which would normally set mgr->dpcd from
DP_DP13_DPCD_REV.

BR,
Jani.

>
> Fix this by reading DP_DP13_DPCD_REV registers as well, matching what is
> done during connector detection. While at it also fix up the same call
> in drm_dp_mst_dump_topology().
>
> Cc: Lyude Paul 
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5292
> Signed-off-by: Imre Deak 
> ---
>  drivers/gpu/drm/display/drm_dp_mst_topology.c | 7 ++-
>  1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c 
> b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> index 67b3b9697da7f..18f2b6075b780 100644
> --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> @@ -3860,9 +3860,7 @@ int drm_dp_mst_topology_mgr_resume(struct 
> drm_dp_mst_topology_mgr *mgr,
>   if (!mgr->mst_primary)
>   goto out_fail;
>  
> - ret = drm_dp_dpcd_read(mgr->aux, DP_DPCD_REV, mgr->dpcd,
> -DP_RECEIVER_CAP_SIZE);
> - if (ret != DP_RECEIVER_CAP_SIZE) {
> + if (drm_dp_read_dpcd_caps(mgr->aux, mgr->dpcd) < 0) {
>   drm_dbg_kms(mgr->dev, "dpcd read failed - undocked during 
> suspend?\n");
>   goto out_fail;
>   }
> @@ -4911,8 +4909,7 @@ void drm_dp_mst_dump_topology(struct seq_file *m,
>   u8 buf[DP_PAYLOAD_TABLE_SIZE];
>   int ret;
>  
> - ret = drm_dp_dpcd_read(mgr->aux, DP_DPCD_REV, buf, 
> DP_RECEIVER_CAP_SIZE);
> - if (ret) {
> + if (drm_dp_read_dpcd_caps(mgr->aux, buf) < 0) {
>   seq_printf(m, "dpcd read failed\n");
>   goto out;
>   }

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [PATCH] drm/dp/mst: Read the extended DPCD capabilities during system resume

[Jani Nikula]

On Tue, 14 Jun 2022, Jani Nikula  wrote:
> On Tue, 14 Jun 2022, Imre Deak  wrote:
>> The WD22TB4 Thunderbolt dock at least will revert its DP_MAX_LINK_RATE
>> from HBR3 to HBR2 after system suspend/resume if the DP_DP13_DPCD_REV
>> registers are not read subsequently also as required.
>
> Does it actually change the behaviour depending on whether the dpcd is
> read or not, or is this just about the resume path overwriting mgr->dpcd
> with stuff from DP_DPCD_REV?
>
> drm_dp_mst_topology_mgr_set_mst() does use drm_dp_read_dpcd_caps() for
> reading the caps, which would normally set mgr->dpcd from
> DP_DP13_DPCD_REV.

Oh,

Reviewed-by: Jani Nikula 

on the changes, I'm just wondering about the statement in the commit
message.



>
> BR,
> Jani.
>
>>
>> Fix this by reading DP_DP13_DPCD_REV registers as well, matching what is
>> done during connector detection. While at it also fix up the same call
>> in drm_dp_mst_dump_topology().
>>
>> Cc: Lyude Paul 
>> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5292
>> Signed-off-by: Imre Deak 
>> ---
>>  drivers/gpu/drm/display/drm_dp_mst_topology.c | 7 ++-
>>  1 file changed, 2 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c 
>> b/drivers/gpu/drm/display/drm_dp_mst_topology.c
>> index 67b3b9697da7f..18f2b6075b780 100644
>> --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
>> +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
>> @@ -3860,9 +3860,7 @@ int drm_dp_mst_topology_mgr_resume(struct 
>> drm_dp_mst_topology_mgr *mgr,
>>  if (!mgr->mst_primary)
>>  goto out_fail;
>>  
>> -ret = drm_dp_dpcd_read(mgr->aux, DP_DPCD_REV, mgr->dpcd,
>> -   DP_RECEIVER_CAP_SIZE);
>> -if (ret != DP_RECEIVER_CAP_SIZE) {
>> +if (drm_dp_read_dpcd_caps(mgr->aux, mgr->dpcd) < 0) {
>>  drm_dbg_kms(mgr->dev, "dpcd read failed - undocked during 
>> suspend?\n");
>>  goto out_fail;
>>  }
>> @@ -4911,8 +4909,7 @@ void drm_dp_mst_dump_topology(struct seq_file *m,
>>  u8 buf[DP_PAYLOAD_TABLE_SIZE];
>>  int ret;
>>  
>> -ret = drm_dp_dpcd_read(mgr->aux, DP_DPCD_REV, buf, 
>> DP_RECEIVER_CAP_SIZE);
>> -if (ret) {
>> +if (drm_dp_read_dpcd_caps(mgr->aux, buf) < 0) {
>>  seq_printf(m, "dpcd read failed\n");
>>  goto out;
>>  }

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [PATCH 09/19] drm/gma500: Unify *_intel_lvds_mode_fixup()

[Patrik Jakobsson]

On Tue, Jun 14, 2022 at 9:23 AM Thomas Zimmermann  wrote:
>
> Hi
>
> Am 13.06.22 um 14:34 schrieb Patrik Jakobsson:
> > These functions mostly do the same thing so unify them. Change a check
> > of !IS_MRST() to IS_PSB() to not change the behaviour for CDV.
> >
> > Signed-off-by: Patrik Jakobsson 
> > ---
> >   drivers/gpu/drm/gma500/cdv_intel_lvds.c | 51 +--
> >   drivers/gpu/drm/gma500/gma_lvds.c   | 59 ++
> >   drivers/gpu/drm/gma500/gma_lvds.h   |  3 ++
> >   drivers/gpu/drm/gma500/oaktrail_lvds.c  |  2 +-
> >   drivers/gpu/drm/gma500/psb_intel_lvds.c | 65 +
> >   5 files changed, 65 insertions(+), 115 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/gma500/cdv_intel_lvds.c 
> > b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
> > index 61dc65964e21..65532308f1e7 100644
> > --- a/drivers/gpu/drm/gma500/cdv_intel_lvds.c
> > +++ b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
> > @@ -39,55 +39,6 @@
> >   #define PSB_BACKLIGHT_PWM_CTL_SHIFT (16)
> >   #define PSB_BACKLIGHT_PWM_POLARITY_BIT_CLEAR (0xFFFE)
> >
> > -static bool cdv_intel_lvds_mode_fixup(struct drm_encoder *encoder,
> > -   const struct drm_display_mode *mode,
> > -   struct drm_display_mode *adjusted_mode)
> > -{
> > - struct drm_device *dev = encoder->dev;
> > - struct drm_psb_private *dev_priv = to_drm_psb_private(dev);
> > - struct psb_intel_mode_device *mode_dev = &dev_priv->mode_dev;
> > - struct drm_encoder *tmp_encoder;
> > - struct drm_display_mode *panel_fixed_mode = 
> > mode_dev->panel_fixed_mode;
> > -
> > - /* Should never happen!! */
> > - list_for_each_entry(tmp_encoder, &dev->mode_config.encoder_list,
> > - head) {
> > - if (tmp_encoder != encoder
> > - && tmp_encoder->crtc == encoder->crtc) {
> > - pr_err("Can't enable LVDS and another encoder on the 
> > same pipe\n");
> > - return false;
> > - }
> > - }
> > -
> > - /*
> > -  * If we have timings from the BIOS for the panel, put them in
> > -  * to the adjusted mode.  The CRTC will be set up for this mode,
> > -  * with the panel scaling set up to source from the H/VDisplay
> > -  * of the original mode.
> > -  */
> > - if (panel_fixed_mode != NULL) {
> > - adjusted_mode->hdisplay = panel_fixed_mode->hdisplay;
> > - adjusted_mode->hsync_start = panel_fixed_mode->hsync_start;
> > - adjusted_mode->hsync_end = panel_fixed_mode->hsync_end;
> > - adjusted_mode->htotal = panel_fixed_mode->htotal;
> > - adjusted_mode->vdisplay = panel_fixed_mode->vdisplay;
> > - adjusted_mode->vsync_start = panel_fixed_mode->vsync_start;
> > - adjusted_mode->vsync_end = panel_fixed_mode->vsync_end;
> > - adjusted_mode->vtotal = panel_fixed_mode->vtotal;
> > - adjusted_mode->clock = panel_fixed_mode->clock;
> > - drm_mode_set_crtcinfo(adjusted_mode,
> > -   CRTC_INTERLACE_HALVE_V);
> > - }
> > -
> > - /*
> > -  * XXX: It would be nice to support lower refresh rates on the
> > -  * panels to reduce power consumption, and perhaps match the
> > -  * user's requested refresh rate.
> > -  */
> > -
> > - return true;
> > -}
> > -
> >   static void cdv_intel_lvds_prepare(struct drm_encoder *encoder)
> >   {
> >   struct drm_device *dev = encoder->dev;
> > @@ -255,7 +206,7 @@ static int cdv_intel_lvds_set_property(struct 
> > drm_connector *connector,
> >   static const struct drm_encoder_helper_funcs
> >   cdv_intel_lvds_helper_funcs = {
> >   .dpms = gma_lvds_encoder_dpms,
> > - .mode_fixup = cdv_intel_lvds_mode_fixup,
> > + .mode_fixup = gma_lvds_mode_fixup,
> >   .prepare = cdv_intel_lvds_prepare,
> >   .mode_set = cdv_intel_lvds_mode_set,
> >   .commit = cdv_intel_lvds_commit,
> > diff --git a/drivers/gpu/drm/gma500/gma_lvds.c 
> > b/drivers/gpu/drm/gma500/gma_lvds.c
> > index 19679ee36062..32ecf5835828 100644
> > --- a/drivers/gpu/drm/gma500/gma_lvds.c
> > +++ b/drivers/gpu/drm/gma500/gma_lvds.c
> > @@ -209,3 +209,62 @@ void gma_lvds_restore(struct drm_connector *connector)
> >   }
> >   }
> >
> > +bool gma_lvds_mode_fixup(struct drm_encoder *encoder,
> > +  const struct drm_display_mode *mode,
> > +  struct drm_display_mode *adjusted_mode)
> > +{
> > + struct drm_device *dev = encoder->dev;
> > + struct drm_psb_private *dev_priv = to_drm_psb_private(dev);
> > + struct psb_intel_mode_device *mode_dev = &dev_priv->mode_dev;
> > + struct gma_crtc *gma_crtc = to_gma_crtc(encoder->crtc);
> > + struct drm_encoder *tmp_encoder;
> > + struct drm_display_mode *panel_fixed_mode = 
> > mode_dev->panel_fixed_mode;
> > +
> > + /* P

Re: [PATCH 09/19] drm/gma500: Unify *_intel_lvds_mode_fixup()

[Thomas Zimmermann]

Hi

Am 14.06.22 um 14:42 schrieb Patrik Jakobsson:

On Tue, Jun 14, 2022 at 9:23 AM Thomas Zimmermann  wrote:


Hi

Am 13.06.22 um 14:34 schrieb Patrik Jakobsson:

These functions mostly do the same thing so unify them. Change a check
of !IS_MRST() to IS_PSB() to not change the behaviour for CDV.

Signed-off-by: Patrik Jakobsson 
---
   drivers/gpu/drm/gma500/cdv_intel_lvds.c | 51 +--
   drivers/gpu/drm/gma500/gma_lvds.c   | 59 ++
   drivers/gpu/drm/gma500/gma_lvds.h   |  3 ++
   drivers/gpu/drm/gma500/oaktrail_lvds.c  |  2 +-
   drivers/gpu/drm/gma500/psb_intel_lvds.c | 65 +
   5 files changed, 65 insertions(+), 115 deletions(-)

diff --git a/drivers/gpu/drm/gma500/cdv_intel_lvds.c 
b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
index 61dc65964e21..65532308f1e7 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_lvds.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
@@ -39,55 +39,6 @@
   #define PSB_BACKLIGHT_PWM_CTL_SHIFT (16)
   #define PSB_BACKLIGHT_PWM_POLARITY_BIT_CLEAR (0xFFFE)

-static bool cdv_intel_lvds_mode_fixup(struct drm_encoder *encoder,
-   const struct drm_display_mode *mode,
-   struct drm_display_mode *adjusted_mode)
-{
- struct drm_device *dev = encoder->dev;
- struct drm_psb_private *dev_priv = to_drm_psb_private(dev);
- struct psb_intel_mode_device *mode_dev = &dev_priv->mode_dev;
- struct drm_encoder *tmp_encoder;
- struct drm_display_mode *panel_fixed_mode = mode_dev->panel_fixed_mode;
-
- /* Should never happen!! */
- list_for_each_entry(tmp_encoder, &dev->mode_config.encoder_list,
- head) {
- if (tmp_encoder != encoder
- && tmp_encoder->crtc == encoder->crtc) {
- pr_err("Can't enable LVDS and another encoder on the same 
pipe\n");
- return false;
- }
- }
-
- /*
-  * If we have timings from the BIOS for the panel, put them in
-  * to the adjusted mode.  The CRTC will be set up for this mode,
-  * with the panel scaling set up to source from the H/VDisplay
-  * of the original mode.
-  */
- if (panel_fixed_mode != NULL) {
- adjusted_mode->hdisplay = panel_fixed_mode->hdisplay;
- adjusted_mode->hsync_start = panel_fixed_mode->hsync_start;
- adjusted_mode->hsync_end = panel_fixed_mode->hsync_end;
- adjusted_mode->htotal = panel_fixed_mode->htotal;
- adjusted_mode->vdisplay = panel_fixed_mode->vdisplay;
- adjusted_mode->vsync_start = panel_fixed_mode->vsync_start;
- adjusted_mode->vsync_end = panel_fixed_mode->vsync_end;
- adjusted_mode->vtotal = panel_fixed_mode->vtotal;
- adjusted_mode->clock = panel_fixed_mode->clock;
- drm_mode_set_crtcinfo(adjusted_mode,
-   CRTC_INTERLACE_HALVE_V);
- }
-
- /*
-  * XXX: It would be nice to support lower refresh rates on the
-  * panels to reduce power consumption, and perhaps match the
-  * user's requested refresh rate.
-  */
-
- return true;
-}
-
   static void cdv_intel_lvds_prepare(struct drm_encoder *encoder)
   {
   struct drm_device *dev = encoder->dev;
@@ -255,7 +206,7 @@ static int cdv_intel_lvds_set_property(struct drm_connector 
*connector,
   static const struct drm_encoder_helper_funcs
   cdv_intel_lvds_helper_funcs = {
   .dpms = gma_lvds_encoder_dpms,
- .mode_fixup = cdv_intel_lvds_mode_fixup,
+ .mode_fixup = gma_lvds_mode_fixup,
   .prepare = cdv_intel_lvds_prepare,
   .mode_set = cdv_intel_lvds_mode_set,
   .commit = cdv_intel_lvds_commit,
diff --git a/drivers/gpu/drm/gma500/gma_lvds.c 
b/drivers/gpu/drm/gma500/gma_lvds.c
index 19679ee36062..32ecf5835828 100644
--- a/drivers/gpu/drm/gma500/gma_lvds.c
+++ b/drivers/gpu/drm/gma500/gma_lvds.c
@@ -209,3 +209,62 @@ void gma_lvds_restore(struct drm_connector *connector)
   }
   }

+bool gma_lvds_mode_fixup(struct drm_encoder *encoder,
+  const struct drm_display_mode *mode,
+  struct drm_display_mode *adjusted_mode)
+{
+ struct drm_device *dev = encoder->dev;
+ struct drm_psb_private *dev_priv = to_drm_psb_private(dev);
+ struct psb_intel_mode_device *mode_dev = &dev_priv->mode_dev;
+ struct gma_crtc *gma_crtc = to_gma_crtc(encoder->crtc);
+ struct drm_encoder *tmp_encoder;
+ struct drm_display_mode *panel_fixed_mode = mode_dev->panel_fixed_mode;
+
+ /* PSB requires the LVDS is on pipe B, MRST has only one pipe anyway */
+ if (IS_PSB(dev) && gma_crtc->pipe == 0) {
+ pr_err("Can't support LVDS on pipe A\n");
+ return false;
+ }
+ if (IS_MRST(dev) && gma_crtc->pipe != 0) {
+ pr_err("Must use PIPE A\n");
+ return false;
+ }


In my experience, pe

Re: [PATCH] drm/dp/mst: Read the extended DPCD capabilities during system resume

[Imre Deak]

On Tue, Jun 14, 2022 at 03:32:59PM +0300, Jani Nikula wrote:
> On Tue, 14 Jun 2022, Imre Deak  wrote:
> > The WD22TB4 Thunderbolt dock at least will revert its DP_MAX_LINK_RATE
> > from HBR3 to HBR2 after system suspend/resume if the DP_DP13_DPCD_REV
> > registers are not read subsequently also as required.
> 
> Does it actually change the behaviour depending on whether the dpcd is
> read or not, or is this just about the resume path overwriting mgr->dpcd
> with stuff from DP_DPCD_REV?

Yes, the reading out DP_DP13_DPCD_REV has a side-effect, see
https://gitlab.freedesktop.org/drm/intel/-/issues/5292#note_1343399

> drm_dp_mst_topology_mgr_set_mst() does use drm_dp_read_dpcd_caps() for
> reading the caps, which would normally set mgr->dpcd from
> DP_DP13_DPCD_REV.

Right, but at that point DP_DP13_DPCD_REV returns HBR2 w/o this change.

> BR,
> Jani.
> 
> >
> > Fix this by reading DP_DP13_DPCD_REV registers as well, matching what is
> > done during connector detection. While at it also fix up the same call
> > in drm_dp_mst_dump_topology().
> >
> > Cc: Lyude Paul 
> > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5292
> > Signed-off-by: Imre Deak 
> > ---
> >  drivers/gpu/drm/display/drm_dp_mst_topology.c | 7 ++-
> >  1 file changed, 2 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c 
> > b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > index 67b3b9697da7f..18f2b6075b780 100644
> > --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > @@ -3860,9 +3860,7 @@ int drm_dp_mst_topology_mgr_resume(struct 
> > drm_dp_mst_topology_mgr *mgr,
> > if (!mgr->mst_primary)
> > goto out_fail;
> >  
> > -   ret = drm_dp_dpcd_read(mgr->aux, DP_DPCD_REV, mgr->dpcd,
> > -  DP_RECEIVER_CAP_SIZE);
> > -   if (ret != DP_RECEIVER_CAP_SIZE) {
> > +   if (drm_dp_read_dpcd_caps(mgr->aux, mgr->dpcd) < 0) {
> > drm_dbg_kms(mgr->dev, "dpcd read failed - undocked during 
> > suspend?\n");
> > goto out_fail;
> > }
> > @@ -4911,8 +4909,7 @@ void drm_dp_mst_dump_topology(struct seq_file *m,
> > u8 buf[DP_PAYLOAD_TABLE_SIZE];
> > int ret;
> >  
> > -   ret = drm_dp_dpcd_read(mgr->aux, DP_DPCD_REV, buf, 
> > DP_RECEIVER_CAP_SIZE);
> > -   if (ret) {
> > +   if (drm_dp_read_dpcd_caps(mgr->aux, buf) < 0) {
> > seq_printf(m, "dpcd read failed\n");
> > goto out;
> > }
> 
> -- 
> Jani Nikula, Intel Open Source Graphics Center

Re: [PATCH v3 3/3] drm/doc: Add KUnit documentation

[Javier Martinez Canillas]

Hello José,

On 6/13/22 19:17, José Expósito wrote:

[snip]

> +KUnit (Kernel unit testing framework) provides a common framework for unit 
> tests
> +within the Linux kernel.
> +

I think that it will be useful to have a reference to the KUnit kernel doc here,
something like the following:

`KUnit `_ (Kernel Unit...

> +This section covers the specifics for the DRM subsystem. For general 
> information
> +about KUnit, please refer to Documentation/dev-tools/kunit/start.rst.
> +
> +How to run the tests?
> +~
> +
> +In order to facilitate running the test suite, a configuration file is 
> present
> +in ``drivers/gpu/drm/kunit/.kunitconfig``. It can be used by ``kunit.py`` as
> +follows:
> +
> +.. code-block:: bash
> +
> + $ ./tools/testing/kunit/kunit.py run 
> --kunitconfig=drivers/gpu/drm/kunit \
> + --kconfig_add CONFIG_VIRTIO_UML=y \
> + --kconfig_add CONFIG_UML_PCI_OVER_VIRTIO=y
> +
> +.. note::
> + The configuration included in ``.kunitconfig`` should be as generic as
> + possible.
> + ``CONFIG_VIRTIO_UML`` and ``CONFIG_UML_PCI_OVER_VIRTIO`` are not
> + included in it because they are only required for User Mode Linux.
> +
> +

Maybe also add something like this ?

For example, the following command can be used to run the test for x86_64:

$ ./tools/testing/kunit/kunit.py run 
--kunitconfig=drivers/gpu/drm/kunit \
--arch=x86_64

Regardless, the patch looks good to me:

Reviewed-by: Javier Martinez Canillas 

-- 
Best regards,

Javier Martinez Canillas
Linux Engineering
Red Hat

Re: [PATCH v3 0/3] KUnit tests for drm_format_helper

[Javier Martinez Canillas]

On 6/13/22 19:17, José Expósito wrote:
> Hello everyone,
> 
> Here is the v3 of the series, including the documentation, previously
> sent as a standalone patch [1], and changes suggested during review.
> 
> Thanks a lot,
> José Expósito
> 

Before merging this, could you please reach the folks working on [0] ?

I think that would be good to have some consistency with regard to KUnit
tests from the start to avoid future refactorings. For instance, you are
adding the tests under a `kunit` sub-directory while they are doing it
in a `tests` sub-dir.

Also there may be other things that could be made more consistent, like
the naming conventions for the tests, suites, etc.

[0]: https://lore.kernel.org/all/20220608010709.272962-4-maira.ca...@usp.br/T/

-- 
Best regards,

Javier Martinez Canillas
Linux Engineering
Red Hat

[PATCH] drm/arm/hdlcd: Take over EFI framebuffer properly

[Robin Murphy]

The Arm Juno board EDK2 port has provided an EFI GOP display via HDLCD0
for some time now, which works nicely as an early framebuffer. However,
once the HDLCD driver probes and takes over the hardware, it should
take over the logical framebuffer as well, otherwise the now-defunct GOP
device hangs about and virtual console output inevitably disappears into
the wrong place most of the time.

Signed-off-by: Robin Murphy 
---
 drivers/gpu/drm/arm/hdlcd_drv.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c
index af59077a5481..a5d04884658b 100644
--- a/drivers/gpu/drm/arm/hdlcd_drv.c
+++ b/drivers/gpu/drm/arm/hdlcd_drv.c
@@ -331,6 +331,8 @@ static int hdlcd_drm_bind(struct device *dev)
goto err_vblank;
}
 
+   drm_fb_helper_remove_conflicting_framebuffers(NULL, "hdlcd", false);
+
drm_mode_config_reset(drm);
drm_kms_helper_poll_init(drm);
 
-- 
2.36.1.dirty

Re: [PATCH 2/3] mm/slab: delete cache_alloc_debugcheck_before()

[Vlastimil Babka]

On 6/5/22 17:25, Daniel Vetter wrote:
> It only does a might_sleep_if(GFP_RECLAIM) check, which is already
> covered by the might_alloc() in slab_pre_alloc_hook(). And all callers
> of cache_alloc_debugcheck_before() call that beforehand already.
> 
> Signed-off-by: Daniel Vetter 
> Cc: Christoph Lameter 
> Cc: Pekka Enberg 
> Cc: David Rientjes 
> Cc: Joonsoo Kim 
> Cc: Andrew Morton 
> Cc: Vlastimil Babka 
> Cc: Roman Gushchin 
> Cc: linux...@kvack.org

Thanks, added to slab/for-5.20/cleanup as it's slab-specific and independent
from 1/3 and 3/3.

> ---
>  mm/slab.c | 10 --
>  1 file changed, 10 deletions(-)
> 
> diff --git a/mm/slab.c b/mm/slab.c
> index b04e40078bdf..75779ac5f5ba 100644
> --- a/mm/slab.c
> +++ b/mm/slab.c
> @@ -2973,12 +2973,6 @@ static void *cache_alloc_refill(struct kmem_cache 
> *cachep, gfp_t flags)
>   return ac->entry[--ac->avail];
>  }
>  
> -static inline void cache_alloc_debugcheck_before(struct kmem_cache *cachep,
> - gfp_t flags)
> -{
> - might_sleep_if(gfpflags_allow_blocking(flags));
> -}
> -
>  #if DEBUG
>  static void *cache_alloc_debugcheck_after(struct kmem_cache *cachep,
>   gfp_t flags, void *objp, unsigned long caller)
> @@ -3219,7 +3213,6 @@ slab_alloc_node(struct kmem_cache *cachep, gfp_t flags, 
> int nodeid, size_t orig_
>   if (unlikely(ptr))
>   goto out_hooks;
>  
> - cache_alloc_debugcheck_before(cachep, flags);
>   local_irq_save(save_flags);
>  
>   if (nodeid == NUMA_NO_NODE)
> @@ -3304,7 +3297,6 @@ slab_alloc(struct kmem_cache *cachep, struct list_lru 
> *lru, gfp_t flags,
>   if (unlikely(objp))
>   goto out;
>  
> - cache_alloc_debugcheck_before(cachep, flags);
>   local_irq_save(save_flags);
>   objp = __do_cache_alloc(cachep, flags);
>   local_irq_restore(save_flags);
> @@ -3541,8 +3533,6 @@ int kmem_cache_alloc_bulk(struct kmem_cache *s, gfp_t 
> flags, size_t size,
>   if (!s)
>   return 0;
>  
> - cache_alloc_debugcheck_before(s, flags);
> -
>   local_irq_disable();
>   for (i = 0; i < size; i++) {
>   void *objp = kfence_alloc(s, s->object_size, flags) ?: 
> __do_cache_alloc(s, flags);

Re: [PATCH 1/3] mm/page_alloc: use might_alloc()

[Vlastimil Babka (SUSE)]

On 6/5/22 17:25, Daniel Vetter wrote:
> ... instead of open codding it. Completely equivalent code, just
> a notch more meaningful when reading.
> 
> Signed-off-by: Daniel Vetter 
> Cc: Andrew Morton 
> Cc: linux...@kvack.org

Reviewed-by: Vlastimil Babka 

> ---
>  mm/page_alloc.c | 5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)
> 
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 2db95780e003..24d170cb 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -5177,10 +5177,7 @@ static inline bool prepare_alloc_pages(gfp_t gfp_mask, 
> unsigned int order,
>   *alloc_flags |= ALLOC_CPUSET;
>   }
>  
> - fs_reclaim_acquire(gfp_mask);
> - fs_reclaim_release(gfp_mask);
> -
> - might_sleep_if(gfp_mask & __GFP_DIRECT_RECLAIM);
> + might_alloc(gfp_mask);
>  
>   if (should_fail_alloc_page(gfp_mask, order))
>   return false;

Re: [PATCH 3/3] mm/mempool: use might_alloc()

[Vlastimil Babka (SUSE)]

On 6/5/22 17:25, Daniel Vetter wrote:
> mempool are generally used for GFP_NOIO, so this wont benefit all that
> much because might_alloc currently only checks GFP_NOFS. But it does
> validate against mmu notifier pte zapping, some might catch some
> drivers doing really silly things, plus it's a bit more meaningful in
> what we're checking for here.
> 
> Signed-off-by: Daniel Vetter 
> Cc: Andrew Morton 
> Cc: linux...@kvack.org

Reviewed-by: Vlastimil Babka 

> ---
>  mm/mempool.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/mm/mempool.c b/mm/mempool.c
> index b933d0fc21b8..96488b13a1ef 100644
> --- a/mm/mempool.c
> +++ b/mm/mempool.c
> @@ -379,7 +379,7 @@ void *mempool_alloc(mempool_t *pool, gfp_t gfp_mask)
>   gfp_t gfp_temp;
>  
>   VM_WARN_ON_ONCE(gfp_mask & __GFP_ZERO);
> - might_sleep_if(gfp_mask & __GFP_DIRECT_RECLAIM);
> + might_alloc(gfp_mask);
>  
>   gfp_mask |= __GFP_NOMEMALLOC;   /* don't allocate emergency reserves */
>   gfp_mask |= __GFP_NORETRY;  /* don't loop in __alloc_pages */

Re: [PATCH] drm/arm/hdlcd: Take over EFI framebuffer properly

[Javier Martinez Canillas]

Hello Robin,

On 6/14/22 15:04, Robin Murphy wrote:
> The Arm Juno board EDK2 port has provided an EFI GOP display via HDLCD0
> for some time now, which works nicely as an early framebuffer. However,
> once the HDLCD driver probes and takes over the hardware, it should
> take over the logical framebuffer as well, otherwise the now-defunct GOP
> device hangs about and virtual console output inevitably disappears into
> the wrong place most of the time.
> 
> Signed-off-by: Robin Murphy 
> ---
>  drivers/gpu/drm/arm/hdlcd_drv.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c
> index af59077a5481..a5d04884658b 100644
> --- a/drivers/gpu/drm/arm/hdlcd_drv.c
> +++ b/drivers/gpu/drm/arm/hdlcd_drv.c
> @@ -331,6 +331,8 @@ static int hdlcd_drm_bind(struct device *dev)
>   goto err_vblank;
>   }
>  
> + drm_fb_helper_remove_conflicting_framebuffers(NULL, "hdlcd", false);
> +

Seems you are using an older base, since this function doesn't exist anymore
after commit 603dc7ed917f ("drm/aperture: Inline fbdev conflict helpers into
aperture helpers").

Instead, you should use the drm_aperture_remove_framebuffers() function, i.e:

 +  drm_aperture_remove_framebuffers(false, &hdlcd_driver);

If you do that and re-spin the patch, feel free to add:

Reviewed-by: Javier Martinez Canillas 

-- 
Best regards,

Javier Martinez Canillas
Linux Engineering
Red Hat

Re: [PATCH] drm/arm/hdlcd: Take over EFI framebuffer properly

[Robin Murphy]

On 2022-06-14 14:26, Javier Martinez Canillas wrote:

Hello Robin,

On 6/14/22 15:04, Robin Murphy wrote:

The Arm Juno board EDK2 port has provided an EFI GOP display via HDLCD0
for some time now, which works nicely as an early framebuffer. However,
once the HDLCD driver probes and takes over the hardware, it should
take over the logical framebuffer as well, otherwise the now-defunct GOP
device hangs about and virtual console output inevitably disappears into
the wrong place most of the time.

Signed-off-by: Robin Murphy 
---
  drivers/gpu/drm/arm/hdlcd_drv.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c
index af59077a5481..a5d04884658b 100644
--- a/drivers/gpu/drm/arm/hdlcd_drv.c
+++ b/drivers/gpu/drm/arm/hdlcd_drv.c
@@ -331,6 +331,8 @@ static int hdlcd_drm_bind(struct device *dev)
goto err_vblank;
}
  
+	drm_fb_helper_remove_conflicting_framebuffers(NULL, "hdlcd", false);

+


Seems you are using an older base, since this function doesn't exist anymore
after commit 603dc7ed917f ("drm/aperture: Inline fbdev conflict helpers into
aperture helpers").


Ah, you got me! I'm having to work with a 5.10 kernel at the moment, but 
the randomly-disappearing console had finally sufficiently annoyed me 
into figuring out and fixing it.



Instead, you should use the drm_aperture_remove_framebuffers() function, i.e:

  + drm_aperture_remove_framebuffers(false, &hdlcd_driver);

If you do that and re-spin the patch, feel free to add:

Reviewed-by: Javier Martinez Canillas 


Thanks for the advice and review - I'll send a v2 later once I've had 
time to build and boot test 5.19-rc.


Cheers,
Robin.

Re: [PATCH] drm/arm/hdlcd: Take over EFI framebuffer properly

[Thomas Zimmermann]

Hi

Am 14.06.22 um 15:04 schrieb Robin Murphy:

The Arm Juno board EDK2 port has provided an EFI GOP display via HDLCD0
for some time now, which works nicely as an early framebuffer. However,
once the HDLCD driver probes and takes over the hardware, it should
take over the logical framebuffer as well, otherwise the now-defunct GOP
device hangs about and virtual console output inevitably disappears into
the wrong place most of the time.

Signed-off-by: Robin Murphy 
---
  drivers/gpu/drm/arm/hdlcd_drv.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c
index af59077a5481..a5d04884658b 100644
--- a/drivers/gpu/drm/arm/hdlcd_drv.c
+++ b/drivers/gpu/drm/arm/hdlcd_drv.c
@@ -331,6 +331,8 @@ static int hdlcd_drm_bind(struct device *dev)
goto err_vblank;
}
  
+	drm_fb_helper_remove_conflicting_framebuffers(NULL, "hdlcd", false);

+


In addition to what Javier said, it appears to be too late to call this 
function. If anything her etouches hardware, you might accidentally 
interfere with the EFI-related driver. Rather call it at the top of 
ldlcd_drm_bind().


Best regards
Thomas


drm_mode_config_reset(drm);
drm_kms_helper_poll_init(drm);
  


--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev


OpenPGP_signature
Description: OpenPGP digital signature

Re: [PATCH] drm/dp/mst: Read the extended DPCD capabilities during system resume

[Jani Nikula]

On Tue, 14 Jun 2022, Imre Deak  wrote:
> On Tue, Jun 14, 2022 at 03:32:59PM +0300, Jani Nikula wrote:
>> On Tue, 14 Jun 2022, Imre Deak  wrote:
>> > The WD22TB4 Thunderbolt dock at least will revert its DP_MAX_LINK_RATE
>> > from HBR3 to HBR2 after system suspend/resume if the DP_DP13_DPCD_REV
>> > registers are not read subsequently also as required.
>> 
>> Does it actually change the behaviour depending on whether the dpcd is
>> read or not, or is this just about the resume path overwriting mgr->dpcd
>> with stuff from DP_DPCD_REV?
>
> Yes, the reading out DP_DP13_DPCD_REV has a side-effect, see
> https://gitlab.freedesktop.org/drm/intel/-/issues/5292#note_1343399

:o

Okay, the commit message is fine as-is.

>
>> drm_dp_mst_topology_mgr_set_mst() does use drm_dp_read_dpcd_caps() for
>> reading the caps, which would normally set mgr->dpcd from
>> DP_DP13_DPCD_REV.
>
> Right, but at that point DP_DP13_DPCD_REV returns HBR2 w/o this change.
>
>> BR,
>> Jani.
>> 
>> >
>> > Fix this by reading DP_DP13_DPCD_REV registers as well, matching what is
>> > done during connector detection. While at it also fix up the same call
>> > in drm_dp_mst_dump_topology().
>> >
>> > Cc: Lyude Paul 
>> > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5292
>> > Signed-off-by: Imre Deak 
>> > ---
>> >  drivers/gpu/drm/display/drm_dp_mst_topology.c | 7 ++-
>> >  1 file changed, 2 insertions(+), 5 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c 
>> > b/drivers/gpu/drm/display/drm_dp_mst_topology.c
>> > index 67b3b9697da7f..18f2b6075b780 100644
>> > --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
>> > +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
>> > @@ -3860,9 +3860,7 @@ int drm_dp_mst_topology_mgr_resume(struct 
>> > drm_dp_mst_topology_mgr *mgr,
>> >if (!mgr->mst_primary)
>> >goto out_fail;
>> >  
>> > -  ret = drm_dp_dpcd_read(mgr->aux, DP_DPCD_REV, mgr->dpcd,
>> > - DP_RECEIVER_CAP_SIZE);
>> > -  if (ret != DP_RECEIVER_CAP_SIZE) {
>> > +  if (drm_dp_read_dpcd_caps(mgr->aux, mgr->dpcd) < 0) {
>> >drm_dbg_kms(mgr->dev, "dpcd read failed - undocked during 
>> > suspend?\n");
>> >goto out_fail;
>> >}
>> > @@ -4911,8 +4909,7 @@ void drm_dp_mst_dump_topology(struct seq_file *m,
>> >u8 buf[DP_PAYLOAD_TABLE_SIZE];
>> >int ret;
>> >  
>> > -  ret = drm_dp_dpcd_read(mgr->aux, DP_DPCD_REV, buf, 
>> > DP_RECEIVER_CAP_SIZE);
>> > -  if (ret) {
>> > +  if (drm_dp_read_dpcd_caps(mgr->aux, buf) < 0) {
>> >seq_printf(m, "dpcd read failed\n");
>> >goto out;
>> >}
>> 
>> -- 
>> Jani Nikula, Intel Open Source Graphics Center

-- 
Jani Nikula, Intel Open Source Graphics Center

[GIT PULL] exynos-drm-fixes

[Inki Dae]

Hi Dave and Daniel,

   Just two regression fixups.

   Please kindly let me know if there is any problem.

Thanks,
Inki Dae

The following changes since commit b13baccc3850ca8b8cccbf8ed9912dbaa0fdf7f3:

  Linux 5.19-rc2 (2022-06-12 16:11:37 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos 
tags/exynos-drm-fixes-v5.19-rc3

for you to fetch changes up to 7d787184a18f0f84e996de8ff007e4395c1978ea:

  drm/exynos: mic: Rework initialization (2022-06-14 22:32:16 +0900)


two regression fixups
- Check a null pointer instead of IS_ERR().
- Rework initialization code of Exynos MIC driver.


Dan Carpenter (1):
  drm/exynos: fix IS_ERR() vs NULL check in probe

Marek Szyprowski (1):
  drm/exynos: mic: Rework initialization

 drivers/gpu/drm/exynos/exynos_drm_drv.c |  6 ++---
 drivers/gpu/drm/exynos/exynos_drm_mic.c | 42 ++---
 2 files changed, 15 insertions(+), 33 deletions(-)

Re: [PATCH 0/6] drm: Add mouse cursor hotspot support to atomic KMS

[Zack Rusin]

On Tue, 2022-06-14 at 10:36 +0300, Pekka Paalanen wrote:
> On Mon, 13 Jun 2022 14:54:57 +
> Zack Rusin  wrote:
> 
> > On Mon, 2022-06-13 at 17:25 +0300, Pekka Paalanen wrote:
> > > On Mon, 13 Jun 2022 13:14:48 +
> > > Zack Rusin  wrote:
> > >   
> > > > On Mon, 2022-06-13 at 10:33 +0300, Pekka Paalanen wrote:  
> > > > > On Fri, 10 Jun 2022 14:24:01 +
> > > > > Zack Rusin  wrote:
> > > > > 
> > > > > > On Fri, 2022-06-10 at 10:59 +0200, Daniel Vetter wrote:
> > > > > > > ⚠ External Email
> > > > > > > 
> > > > > > > On Fri, Jun 10, 2022 at 10:41:05AM +0200, Daniel Vetter wrote:
> > > > > > >   
> > > > > > > > Hi all,
> > > > > > > > 
> > > > > > > > Kinda top post because the thread is sprawling and I think we 
> > > > > > > > need a
> > > > > > > > summary/restart. I think there's at least 3 issues here:
> > > > > > > > 
> > > > > > > > - lack of hotspot property support, which means compositors 
> > > > > > > > can't really
> > > > > > > >   support hotspot with atomic. Which isn't entirely true, 
> > > > > > > > because you
> > > > > > > >   totally can use atomic for the primary planes/crtcs and the 
> > > > > > > > legacy
> > > > > > > >   cursor ioctls, but I understand that people might find that a 
> > > > > > > > bit silly :-)
> > > > > > > > 
> > > > > > > >   Anyway this problme is solved by the patch set here, and I 
> > > > > > > > think results
> > > > > > > >   in some nice cleanups to boot.
> > > > > > > > 
> > > > > > > > - the fact that cursors for virtual drivers are not planes, but 
> > > > > > > > really
> > > > > > > >   special things. Which just breaks the universal plane kms 
> > > > > > > > uapi. That
> > > > > > > >   part isn't solved, and I do agree with Simon and Pekka that 
> > > > > > > > we really
> > > > > > > >   should solve this before we unleash even more compositors 
> > > > > > > > onto the
> > > > > > > >   atomic paths of virtual drivers.
> > > > > > > > 
> > > > > > > >   I think the simplest solution for this is:
> > > > > > > >   1. add a new DRM_PLANE_TYPE_VIRTUAL_CURSOR, and set that for 
> > > > > > > > these
> > > > > > > >   special cursor planes on all virtual drivers
> > > > > > > >   2. add the new "I understand virtual cursors planes" 
> > > > > > > > setparam, filter
> > > > > > > >   virtual cursor planes for userspace which doesn't set this 
> > > > > > > > (like we do
> > > > > > > >   right now if userspace doesn't set the universal plane mode)
> > > > > > > >   3. backport the above patches to all stable kernels
> > > > > > > >   4. make sure the hotspot property is only set on 
> > > > > > > > VIRTUAL_CURSOR planes
> > > > > > > >   and nothing else in the rebased patch series  
> > > > > > > 
> > > > > > > Simon also mentioned on irc that these special planes must not 
> > > > > > > expose the
> > > > > > > CRTC_X/Y property, since that doesn't really do much at all. Or 
> > > > > > > is our
> > > > > > > understanding of how this all works for commandeered cursors 
> > > > > > > wrong?  
> > > > > > 
> > > > > > Yes, that's the part I don't understand. I don't think I see how 
> > > > > > the CRTC_X|Y
> > > > > > properties aren't used.
> > > > > > 
> > > > > > I think the confusion might stem from the fact that it appears that 
> > > > > > the
> > > > > > hypervisors/hosts are moving that plane, which is not the case. We 
> > > > > > never move the
> > > > > > plane itself, we redirect the mouse focus/movement, that's what's 
> > > > > > reducing the
> > > > > > latency but don't touch drm internals. I can't speak for every 
> > > > > > virtualized stack,
> > > > > > but what is happening on ours is that we set the image that's on 
> > > > > > the cursor plane as
> > > > > > the cursor on the machine that's running the guest. So when you 
> > > > > > move the mouse
> > > > > > across the screen as you enter the VM window the cursor plane isn't 
> > > > > > touched, but the
> > > > > > local machines cursor changes to what's inside the cursor plane. 
> > > > > > When the mouse is
> > > > > > clicked the mouse device in the guest generates the event with the 
> > > > > > proper
> > > > > > coordinates (hence we need the hotspot to route that event 
> > > > > > correctly). That's when
> > > > > > the guest reacts just like it would normally on native if a mouse 
> > > > > > event was
> > > > > > received.
> > > > > > 
> > > > > > The actual cursor plane might not be visible while this is 
> > > > > > happening but even when
> > > > > > it's not visible it's still at whatever crtc_x|y the guest thinks 
> > > > > > it is. crtc_x|y
> > > > > > are still only driven by the guests mouse device.
> > > > > > 
> > > > > > We control the mouse device and visibility of the cursor plane 
> > > > > > itself based on
> > > > > > what's happening in the system but I don't think that's that 
> > > > > > different from a native
> > > > > > system.
> > > > > 
> > > > > Sorry Zack, while I'm sure that is technically correct and

Re: [PATCH v3] drm/msm: Avoid unclocked GMU register access in 6xx gpu_busy

[Akhil P Oommen]

On 6/10/2022 5:39 AM, Douglas Anderson wrote:

>From testing on sc7180-trogdor devices, reading the GMU registers
needs the GMU clocks to be enabled. Those clocks get turned on in
a6xx_gmu_resume(). Confusingly enough, that function is called as a
result of the runtime_pm of the GPU "struct device", not the GMU
"struct device". Unfortunately the current a6xx_gpu_busy() grabs a
reference to the GMU's "struct device".

The fact that we were grabbing the wrong reference was easily seen to
cause crashes that happen if we change the GPU's pm_runtime usage to
not use autosuspend. It's also believed to cause some long tail GPU
crashes even with autosuspend.

We could look at changing it so that we do pm_runtime_get_if_in_use()
on the GPU's "struct device", but then we run into a different
problem. pm_runtime_get_if_in_use() will return 0 for the GPU's
"struct device" the whole time when we're in the "autosuspend
delay". That is, when we drop the last reference to the GPU but we're
waiting a period before actually suspending then we'll think the GPU
is off. One reason that's bad is that if the GPU didn't actually turn
off then the cycle counter doesn't lose state and that throws off all
of our calculations.

Let's change the code to keep track of the suspend state of
devfreq. msm_devfreq_suspend() is always called before we actually
suspend the GPU and msm_devfreq_resume() after we resume it. This
means we can use the suspended state to know if we're powered or not.

NOTE: one might wonder when exactly our status function is called when
devfreq is supposed to be disabled. The stack crawl I captured was:
   msm_devfreq_get_dev_status
   devfreq_simple_ondemand_func
   devfreq_update_target
   qos_notifier_call
   qos_max_notifier_call
   blocking_notifier_call_chain
   pm_qos_update_target
   freq_qos_apply
   apply_constraint
   __dev_pm_qos_update_request
   dev_pm_qos_update_request
   msm_devfreq_idle_work

Fixes: eadf79286a4b ("drm/msm: Check for powered down HW in the devfreq 
callbacks")
Signed-off-by: Douglas Anderson 
---

Changes in v3:
- Totally rewrote to not use the pm_runtime functions.
- Moved the code to be common for all adreno GPUs.

Changes in v2:
- Move the set_freq runtime pm grab to the GPU file.
- Use <= for the pm_runtime test, not ==.

  drivers/gpu/drm/msm/adreno/a5xx_gpu.c |  8 --
  drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 13 -
  drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 12 +++--
  drivers/gpu/drm/msm/adreno/a6xx_gpu.h |  3 ++-
  drivers/gpu/drm/msm/msm_gpu.h |  9 ++-
  drivers/gpu/drm/msm/msm_gpu_devfreq.c | 39 +--
  6 files changed, 51 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index c424e9a37669..3dcec7acb384 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -1666,18 +1666,10 @@ static u64 a5xx_gpu_busy(struct msm_gpu *gpu, unsigned 
long *out_sample_rate)
  {
u64 busy_cycles;
  
-	/* Only read the gpu busy if the hardware is already active */

-   if (pm_runtime_get_if_in_use(&gpu->pdev->dev) == 0) {
-   *out_sample_rate = 1;
-   return 0;
-   }
-
busy_cycles = gpu_read64(gpu, REG_A5XX_RBBM_PERFCTR_RBBM_0_LO,
REG_A5XX_RBBM_PERFCTR_RBBM_0_HI);
*out_sample_rate = clk_get_rate(gpu->core_clk);
  
-	pm_runtime_put(&gpu->pdev->dev);

-
return busy_cycles;
  }
  
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c

index 9f76f5b15759..dc715d88ff21 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -102,7 +102,8 @@ bool a6xx_gmu_gx_is_on(struct a6xx_gmu *gmu)
A6XX_GMU_SPTPRAC_PWR_CLK_STATUS_GX_HM_CLK_OFF));
  }
  
-void a6xx_gmu_set_freq(struct msm_gpu *gpu, struct dev_pm_opp *opp)

+void a6xx_gmu_set_freq(struct msm_gpu *gpu, struct dev_pm_opp *opp,
+  bool suspended)
  {
struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
struct a6xx_gpu *a6xx_gpu = to_a6xx_gpu(adreno_gpu);
@@ -127,15 +128,16 @@ void a6xx_gmu_set_freq(struct msm_gpu *gpu, struct 
dev_pm_opp *opp)
  
  	/*

 * This can get called from devfreq while the hardware is idle. Don't
-* bring up the power if it isn't already active
+* bring up the power if it isn't already active. All we're doing here
+* is updating the frequency so that when we come back online we're at
+* the right rate.
 */
-   if (pm_runtime_get_if_in_use(gmu->dev) == 0)
+   if (suspended)
return;
  
  	if (!gmu->legacy) {

a6xx_hfi_set_freq(gmu, perf_index);
dev_pm_opp_set_opp(&gpu->pdev->dev, opp);
-   pm_runtime_put(gmu->dev);
return;
}
  
@@ -159,7 +161,6 @@ void a6xx_gmu_set_freq(struct msm_gpu *gpu, struct dev_pm_opp *opp

[PATCH v5] drm/msm: Avoid unclocked GMU register access in a6xx gpu_busy

[Douglas Anderson]

>From testing on sc7180-trogdor devices, reading the GMU registers
needs the GMU clocks to be enabled. Those clocks get turned on in
a6xx_gmu_resume(). Confusingly enough, that function is called as a
result of the runtime_pm of the GPU "struct device", not the GMU
"struct device". Unfortunately the current a6xx_gpu_busy() grabs a
reference to the GMU's "struct device".

The fact that we were grabbing the wrong reference was easily seen to
cause crashes that happen if we change the GPU's pm_runtime usage to
not use autosuspend. It's also believed to cause some long tail GPU
crashes even with autosuspend.

We could look at changing it so that we do pm_runtime_get_if_in_use()
on the GPU's "struct device", but then we run into a different
problem. pm_runtime_get_if_in_use() will return 0 for the GPU's
"struct device" the whole time when we're in the "autosuspend
delay". That is, when we drop the last reference to the GPU but we're
waiting a period before actually suspending then we'll think the GPU
is off. One reason that's bad is that if the GPU didn't actually turn
off then the cycle counter doesn't lose state and that throws off all
of our calculations.

Let's change the code to keep track of the suspend state of
devfreq. msm_devfreq_suspend() is always called before we actually
suspend the GPU and msm_devfreq_resume() after we resume it. This
means we can use the suspended state to know if we're powered or not.

NOTE: one might wonder when exactly our status function is called when
devfreq is supposed to be disabled. The stack crawl I captured was:
  msm_devfreq_get_dev_status
  devfreq_simple_ondemand_func
  devfreq_update_target
  qos_notifier_call
  qos_max_notifier_call
  blocking_notifier_call_chain
  pm_qos_update_target
  freq_qos_apply
  apply_constraint
  __dev_pm_qos_update_request
  dev_pm_qos_update_request
  msm_devfreq_idle_work

Fixes: eadf79286a4b ("drm/msm: Check for powered down HW in the devfreq 
callbacks")
Signed-off-by: Douglas Anderson 
Reviewed-by: Rob Clark 
Reviewed-by: Akhil P Oommen 
---

Changes in v5:
- in the commit subject: 6xx -> a6xx

Changes in v4:
- Add a comment that gpu_set_freq() / gpu_busy() assume pm resume

Changes in v3:
- Totally rewrote to not use the pm_runtime functions.
- Moved the code to be common for all adreno GPUs.

Changes in v2:
- Move the set_freq runtime pm grab to the GPU file.
- Use <= for the pm_runtime test, not ==.

 drivers/gpu/drm/msm/adreno/a5xx_gpu.c |  8 --
 drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 13 -
 drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 12 +++--
 drivers/gpu/drm/msm/adreno/a6xx_gpu.h |  3 ++-
 drivers/gpu/drm/msm/msm_gpu.h | 11 +++-
 drivers/gpu/drm/msm/msm_gpu_devfreq.c | 39 +--
 6 files changed, 53 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index c424e9a37669..3dcec7acb384 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -1666,18 +1666,10 @@ static u64 a5xx_gpu_busy(struct msm_gpu *gpu, unsigned 
long *out_sample_rate)
 {
u64 busy_cycles;
 
-   /* Only read the gpu busy if the hardware is already active */
-   if (pm_runtime_get_if_in_use(&gpu->pdev->dev) == 0) {
-   *out_sample_rate = 1;
-   return 0;
-   }
-
busy_cycles = gpu_read64(gpu, REG_A5XX_RBBM_PERFCTR_RBBM_0_LO,
REG_A5XX_RBBM_PERFCTR_RBBM_0_HI);
*out_sample_rate = clk_get_rate(gpu->core_clk);
 
-   pm_runtime_put(&gpu->pdev->dev);
-
return busy_cycles;
 }
 
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c 
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index 9f76f5b15759..dc715d88ff21 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -102,7 +102,8 @@ bool a6xx_gmu_gx_is_on(struct a6xx_gmu *gmu)
A6XX_GMU_SPTPRAC_PWR_CLK_STATUS_GX_HM_CLK_OFF));
 }
 
-void a6xx_gmu_set_freq(struct msm_gpu *gpu, struct dev_pm_opp *opp)
+void a6xx_gmu_set_freq(struct msm_gpu *gpu, struct dev_pm_opp *opp,
+  bool suspended)
 {
struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
struct a6xx_gpu *a6xx_gpu = to_a6xx_gpu(adreno_gpu);
@@ -127,15 +128,16 @@ void a6xx_gmu_set_freq(struct msm_gpu *gpu, struct 
dev_pm_opp *opp)
 
/*
 * This can get called from devfreq while the hardware is idle. Don't
-* bring up the power if it isn't already active
+* bring up the power if it isn't already active. All we're doing here
+* is updating the frequency so that when we come back online we're at
+* the right rate.
 */
-   if (pm_runtime_get_if_in_use(gmu->dev) == 0)
+   if (suspended)
return;
 
if (!gmu->legacy) {
a6xx_hfi_set_freq(gmu, perf_index);
dev_pm_opp_set_opp(&gpu->pdev->dev, opp);
-   pm_runtime_put(gmu->

Re: [PATCH 14/64] drm/vc4: hvs: Remove planes currently allocated before taking down

[Dave Stevenson]

On Fri, 10 Jun 2022 at 10:30, Maxime Ripard  wrote:
>
> When the HVS driver is unbound, a lot of memory allocations in the LBM and
> DLIST RAM are still assigned to planes that are still allocated.
>
> Thus, we hit a warning when calling drm_mm_takedown() since the memory pool
> is not completely free of allocations.
>
> Let's free all the currently live entries before calling drm_mm_takedown().
>
> Signed-off-by: Maxime Ripard 

Reviewed-by: Dave Stevenson 

> ---
>  drivers/gpu/drm/vc4/vc4_hvs.c | 7 +++
>  1 file changed, 7 insertions(+)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hvs.c b/drivers/gpu/drm/vc4/vc4_hvs.c
> index 483053e7b14f..b0906bb96c32 100644
> --- a/drivers/gpu/drm/vc4/vc4_hvs.c
> +++ b/drivers/gpu/drm/vc4/vc4_hvs.c
> @@ -834,11 +834,18 @@ static void vc4_hvs_unbind(struct device *dev, struct 
> device *master,
> struct drm_device *drm = dev_get_drvdata(master);
> struct vc4_dev *vc4 = to_vc4_dev(drm);
> struct vc4_hvs *hvs = vc4->hvs;
> +   struct drm_mm_node *node, *next;
>
> if (drm_mm_node_allocated(&vc4->hvs->mitchell_netravali_filter))
> drm_mm_remove_node(&vc4->hvs->mitchell_netravali_filter);
>
> +   drm_mm_for_each_node_safe(node, next, &vc4->hvs->dlist_mm)
> +   drm_mm_remove_node(node);
> +
> drm_mm_takedown(&vc4->hvs->dlist_mm);
> +
> +   drm_mm_for_each_node_safe(node, next, &vc4->hvs->lbm_mm)
> +   drm_mm_remove_node(node);
> drm_mm_takedown(&vc4->hvs->lbm_mm);
>
> clk_disable_unprepare(hvs->core_clk);
> --
> 2.36.1
>

Re: [PATCH v3] drm/msm: Avoid unclocked GMU register access in 6xx gpu_busy

[Doug Anderson]

Hi,

On Tue, Jun 14, 2022 at 7:42 AM Akhil P Oommen  wrote:
>
> On 6/10/2022 5:39 AM, Douglas Anderson wrote:
> > >From testing on sc7180-trogdor devices, reading the GMU registers
> > needs the GMU clocks to be enabled. Those clocks get turned on in
> > a6xx_gmu_resume(). Confusingly enough, that function is called as a
> > result of the runtime_pm of the GPU "struct device", not the GMU
> > "struct device". Unfortunately the current a6xx_gpu_busy() grabs a
> > reference to the GMU's "struct device".
> >
> > The fact that we were grabbing the wrong reference was easily seen to
> > cause crashes that happen if we change the GPU's pm_runtime usage to
> > not use autosuspend. It's also believed to cause some long tail GPU
> > crashes even with autosuspend.
> >
> > We could look at changing it so that we do pm_runtime_get_if_in_use()
> > on the GPU's "struct device", but then we run into a different
> > problem. pm_runtime_get_if_in_use() will return 0 for the GPU's
> > "struct device" the whole time when we're in the "autosuspend
> > delay". That is, when we drop the last reference to the GPU but we're
> > waiting a period before actually suspending then we'll think the GPU
> > is off. One reason that's bad is that if the GPU didn't actually turn
> > off then the cycle counter doesn't lose state and that throws off all
> > of our calculations.
> >
> > Let's change the code to keep track of the suspend state of
> > devfreq. msm_devfreq_suspend() is always called before we actually
> > suspend the GPU and msm_devfreq_resume() after we resume it. This
> > means we can use the suspended state to know if we're powered or not.
> >
> > NOTE: one might wonder when exactly our status function is called when
> > devfreq is supposed to be disabled. The stack crawl I captured was:
> >msm_devfreq_get_dev_status
> >devfreq_simple_ondemand_func
> >devfreq_update_target
> >qos_notifier_call
> >qos_max_notifier_call
> >blocking_notifier_call_chain
> >pm_qos_update_target
> >freq_qos_apply
> >apply_constraint
> >__dev_pm_qos_update_request
> >dev_pm_qos_update_request
> >msm_devfreq_idle_work
> >
> > Fixes: eadf79286a4b ("drm/msm: Check for powered down HW in the devfreq 
> > callbacks")
> > Signed-off-by: Douglas Anderson 
> > ---
> >
> > Changes in v3:
> > - Totally rewrote to not use the pm_runtime functions.
> > - Moved the code to be common for all adreno GPUs.
> >
> > Changes in v2:
> > - Move the set_freq runtime pm grab to the GPU file.
> > - Use <= for the pm_runtime test, not ==.
> >
> >   drivers/gpu/drm/msm/adreno/a5xx_gpu.c |  8 --
> >   drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 13 -
> >   drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 12 +++--
> >   drivers/gpu/drm/msm/adreno/a6xx_gpu.h |  3 ++-
> >   drivers/gpu/drm/msm/msm_gpu.h |  9 ++-
> >   drivers/gpu/drm/msm/msm_gpu_devfreq.c | 39 +--
> >   6 files changed, 51 insertions(+), 33 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c 
> > b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> > index c424e9a37669..3dcec7acb384 100644
> > --- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> > +++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> > @@ -1666,18 +1666,10 @@ static u64 a5xx_gpu_busy(struct msm_gpu *gpu, 
> > unsigned long *out_sample_rate)
> >   {
> >   u64 busy_cycles;
> >
> > - /* Only read the gpu busy if the hardware is already active */
> > - if (pm_runtime_get_if_in_use(&gpu->pdev->dev) == 0) {
> > - *out_sample_rate = 1;
> > - return 0;
> > - }
> > -
> >   busy_cycles = gpu_read64(gpu, REG_A5XX_RBBM_PERFCTR_RBBM_0_LO,
> >   REG_A5XX_RBBM_PERFCTR_RBBM_0_HI);
> >   *out_sample_rate = clk_get_rate(gpu->core_clk);
> >
> > - pm_runtime_put(&gpu->pdev->dev);
> > -
> >   return busy_cycles;
> >   }
> >
> > diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c 
> > b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> > index 9f76f5b15759..dc715d88ff21 100644
> > --- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> > +++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> > @@ -102,7 +102,8 @@ bool a6xx_gmu_gx_is_on(struct a6xx_gmu *gmu)
> >   A6XX_GMU_SPTPRAC_PWR_CLK_STATUS_GX_HM_CLK_OFF));
> >   }
> >
> > -void a6xx_gmu_set_freq(struct msm_gpu *gpu, struct dev_pm_opp *opp)
> > +void a6xx_gmu_set_freq(struct msm_gpu *gpu, struct dev_pm_opp *opp,
> > +bool suspended)
> >   {
> >   struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
> >   struct a6xx_gpu *a6xx_gpu = to_a6xx_gpu(adreno_gpu);
> > @@ -127,15 +128,16 @@ void a6xx_gmu_set_freq(struct msm_gpu *gpu, struct 
> > dev_pm_opp *opp)
> >
> >   /*
> >* This can get called from devfreq while the hardware is idle. Don't
> > -  * bring up the power if it isn't already active
> > +  * bring up the power if it isn't already active. All we're doing here
> > +  * is updating the frequency so that when we come back on

Re: [PATCH 0/6] drm: Add mouse cursor hotspot support to atomic KMS

[Daniel Stone]

Hi,

On Tue, 14 Jun 2022 at 15:40, Zack Rusin  wrote:
> On Tue, 2022-06-14 at 10:36 +0300, Pekka Paalanen wrote:
> > The reason I am saying that you need to fix other issues with
> > virtualized drivers at the same time is because those other issues are
> > the sole and only reason why the driver would ever need hotspot info.
> >
> > Hotspot info must not be necessary for correct KMS operation, yet you
> > seem to insist it is. You assume that cursor plane commandeering is ok
> > to do. But it is not ok without adding the KMS UAPI that would allow
> > it: a way for guest userspace to explicitly say that commandeering will
> > be ok.
> >
> > If and only if guest userspace says commandeering is ok, then you can
> > require hotspot info. On the other hand, you cannot retrofit hotspot
> > info by saying that if a driver exposes hotspot properties then all KMS
> > clients must set them. That would be a kernel regression by definition:
> > KMS clients that used to abide the KMS UAPI contract are suddenly
> > breaking the contract because the kernel changed the contract.
> >
> > Therefore I very much disagree that virtualized drivers need hotspot
> > info. They do not strictly need hotspot info for correct operation,
> > they need it only for making the user experience more smooth, which is
> > an optional optimization. That optimization may be very important in
> > practise, but it's still an optimization and is generally not expected
> > by KMS clients.
>
> I strongly disagree with that (both the sentiment towards hotspots and the 
> client
> handling of it). I don't think we have to agree on reasoning here at all to 
> make
> progress though so I'm going to let it go (we can always continue on irc or 
> email if
> you'd like to try to conclude this bit but we could all use a few days of 
> break from
> this discussion probably).

Well, it's just coming from two different directions:
* many current KMS clients want the cursor plane to be displayed as
the client-programmed plane properties indicate, and the output can be
nonsensical if they aren't
* VMware optimises the cursor by displaying the cursor plane not as
the client-programmed plane properties indicate, and the output is
sometimes good (faster response!) but sometimes bad (nonsensical
display!)

The client cap sounds good. As a further suggestion, given that
universal planes are supposed to make planes, er, universal, rather
than imbued with magical special behaviour, how about _also_ adding an
'is cursor' plane prop which userspace has to set to 1 to indicate
that the output is a cursor and has the hotspot correctly set and the
'display hardware' is free to make the cursor fly around the screen in
accordance with the input events it sends? That way it's really really
clear what's happening and no-one's getting surprised when 'the right
thing' doesn't happen, not least because it's really clear what 'the
right thing' is.

Cheers,
Daniel

Re: [PATCH 12/64] drm/vc4: Call component_unbind_all()

[Dave Stevenson]

On Fri, 10 Jun 2022 at 10:30, Maxime Ripard  wrote:
>
> While we were using the component framework to deal with all the DRM
> subdevices, we were not calling component_unbind_all().
>
> This leads to none of the subdevices freeing up their resources as part of
> their unbind() or device managed hooks.
>
> Fixes: c8b75bca92cb ("drm/vc4: Add KMS support for Raspberry Pi.")
> Signed-off-by: Maxime Ripard 

Reviewed-by: Dave Stevenson 

> ---
>  drivers/gpu/drm/vc4/vc4_drv.c | 14 --
>  drivers/gpu/drm/vc4/vc4_drv.h |  1 +
>  2 files changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
> index 162bc18e7497..031f2cdd658d 100644
> --- a/drivers/gpu/drm/vc4/vc4_drv.c
> +++ b/drivers/gpu/drm/vc4/vc4_drv.c
> @@ -209,6 +209,13 @@ static void vc4_match_add_drivers(struct device *dev,
> }
>  }
>
> +static void vc4_component_unbind_all(void *ptr)
> +{
> +   struct vc4_dev *vc4 = ptr;
> +
> +   component_unbind_all(vc4->dev, &vc4->base);
> +}
> +
>  static int vc4_drm_bind(struct device *dev)
>  {
> struct platform_device *pdev = to_platform_device(dev);
> @@ -230,6 +237,7 @@ static int vc4_drm_bind(struct device *dev)
> vc4 = devm_drm_dev_alloc(dev, &vc4_drm_driver, struct vc4_dev, base);
> if (IS_ERR(vc4))
> return PTR_ERR(vc4);
> +   vc4->dev = dev;
>
> drm = &vc4->base;
> platform_set_drvdata(pdev, drm);
> @@ -276,6 +284,10 @@ static int vc4_drm_bind(struct device *dev)
> if (ret)
> return ret;
>
> +   ret = devm_add_action_or_reset(dev, vc4_component_unbind_all, vc4);
> +   if (ret)
> +   return ret;
> +
> ret = vc4_plane_create_additional_planes(drm);
> if (ret)
> goto unbind_all;
> @@ -296,8 +308,6 @@ static int vc4_drm_bind(struct device *dev)
> return 0;
>
>  unbind_all:
> -   component_unbind_all(dev, drm);
> -
> return ret;
>  }
>
> diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
> index 15e0c2ac3940..aa4c5910ea05 100644
> --- a/drivers/gpu/drm/vc4/vc4_drv.h
> +++ b/drivers/gpu/drm/vc4/vc4_drv.h
> @@ -73,6 +73,7 @@ struct vc4_perfmon {
>
>  struct vc4_dev {
> struct drm_device base;
> +   struct device *dev;
>
> unsigned int irq;
>
> --
> 2.36.1
>

Re: [Intel-gfx] [PATCH v7] drm/i915/display: disable HPD workers before display driver unregister

[Andrzej Hajda]

On 10.06.2022 20:37, Ville Syrjälä wrote:

On Fri, Jun 10, 2022 at 06:00:24PM +0200, Andrzej Hajda wrote:

Handling HPD during driver removal is pointless, and can cause different
use-after-free/concurrency issues:
1. Setup of deferred fbdev after fbdev unregistration.
2. Access to DP-AUX after DP-AUX removal.

Below stacktraces of both cases observed on CI:

[272.634530] general protection fault, probably for non-canonical address 
0x6b6b6b6b6b6b6b6b:  [#1] PREEMPT SMP NOPTI
[272.634536] CPU: 0 PID: 6030 Comm: i915_selftest Tainted: G U
5.18.0-rc5-CI_DRM_11603-g12dccf4f5eef+ #1
[272.634541] Hardware name: Intel Corporation Raptor Lake Client Platform/RPL-S 
ADP-S DDR5 UDIMM CRB, BIOS RPLSFWI1.R00.2397.A01.2109300731 09/30/2021
[272.634545] RIP: 0010:fb_do_apertures_overlap.part.14+0x26/0x60
...
[272.634582] Call Trace:
[272.634583]  
[272.634585]  do_remove_conflicting_framebuffers+0x59/0xa0
[272.634589]  remove_conflicting_framebuffers+0x2d/0xc0
[272.634592]  remove_conflicting_pci_framebuffers+0xc8/0x110
[272.634595]  drm_aperture_remove_conflicting_pci_framebuffers+0x52/0x70
[272.634604]  i915_driver_probe+0x63a/0xdd0 [i915]

[283.405824] cpu_latency_qos_update_request called for unknown object
[283.405866] WARNING: CPU: 2 PID: 240 at kernel/power/qos.c:296 
cpu_latency_qos_update_request+0x2d/0x100
[283.405912] CPU: 2 PID: 240 Comm: kworker/u64:9 Not tainted 
5.18.0-rc6-Patchwork_103738v3-g1672d1c43e43+ #1
[283.405915] Hardware name: Intel Corporation Raptor Lake Client Platform/RPL-S 
ADP-S DDR5 UDIMM CRB, BIOS RPLSFWI1.R00.2397.A01.2109300731 09/30/2021
[283.405916] Workqueue: i915-dp i915_digport_work_func [i915]
[283.406020] RIP: 0010:cpu_latency_qos_update_request+0x2d/0x100
...
[283.406040] Call Trace:
[283.406041]  
[283.406044]  intel_dp_aux_xfer+0x60e/0x8e0 [i915]
[283.406131]  ? finish_swait+0x80/0x80
[283.406139]  intel_dp_aux_transfer+0xc5/0x2b0 [i915]
[283.406218]  drm_dp_dpcd_access+0x79/0x130 [drm_display_helper]
[283.406227]  drm_dp_dpcd_read+0xe2/0xf0 [drm_display_helper]
[283.406233]  intel_dp_hpd_pulse+0x134/0x570 [i915]
[283.406308]  ? __down_killable+0x70/0x140
[283.406313]  i915_digport_work_func+0xba/0x150 [i915]

Signed-off-by: Andrzej Hajda 
---
Hi All,

I am not sure about changes in shutdown path, any comments welcome.
I suspect suspend path have also some common bits, but I am little
bit afraid of touching it.

Changes:
v1 - v6:
 - chasing the bug appearing only on public CI.
v7:
 - shutdown path adjusted (suggested by Jani)

Regards
Andrzej
---
  drivers/gpu/drm/i915/display/intel_display.c | 11 ---
  drivers/gpu/drm/i915/i915_driver.c   |  5 ++---
  2 files changed, 6 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 186b37925d23f2..f9952ee8289fb2 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -10490,13 +10490,6 @@ void intel_modeset_driver_remove_noirq(struct 
drm_i915_private *i915)
 */
intel_hpd_poll_fini(i915);
  
-	/*

-* MST topology needs to be suspended so we don't have any calls to
-* fbdev after it's finalized. MST will be destroyed later as part of
-* drm_mode_config_cleanup()
-*/
-   intel_dp_mst_suspend(i915);
-
/* poll work can call into fbdev, hence clean that up afterwards */
intel_fbdev_fini(i915);
  
@@ -10588,6 +10581,10 @@ void intel_display_driver_unregister(struct drm_i915_private *i915)

if (!HAS_DISPLAY(i915))
return;
  
+	intel_dp_mst_suspend(i915);

+   intel_hpd_cancel_work(i915);
+   drm_kms_helper_poll_disable(&i915->drm);
+
intel_fbdev_unregister(i915);
intel_audio_deinit(i915);
  
diff --git a/drivers/gpu/drm/i915/i915_driver.c b/drivers/gpu/drm/i915/i915_driver.c

index d26dcca7e654aa..82cdccf072e2bc 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -1070,15 +1070,14 @@ void i915_driver_shutdown(struct drm_i915_private *i915)
i915_gem_suspend(i915);
  
  	if (HAS_DISPLAY(i915)) {

+   intel_dp_mst_suspend(i915);
+   intel_hpd_cancel_work(i915);
drm_kms_helper_poll_disable(&i915->drm);
  
  		drm_atomic_helper_shutdown(&i915->drm);


You can't suspend MST before this since this is what actually turns the
displays off.

The real chicken and egg sitaation is due to MST sideband depending
on HPD_IRQs to work, but we want to stop the rest of hotplug processing
before we shut down the displays to make sure fbdev/etc. doesn't light
them back up.

If we didn't have MST sidband we could just turn off hotplug interrupts
ahead of time and flush the works, but with MST we need to keep the
interrupts alive. So I suspect we need some kind of flag to indicate
that at least full hotplug handling should not happen even though the
hotplug interrupts are st

Re: [PATCH 13/64] drm/vc4: hvs: Protect device resources after removal

[Dave Stevenson]

Hi Maxime

On Fri, 10 Jun 2022 at 10:30, Maxime Ripard  wrote:
>
> Whenever the device and driver are unbound, the main device and all the
> subdevices will be removed by calling their unbind() method.
>
> However, the DRM device itself will only be freed when the last user will
> have closed it.
>
> It means that there is a time window where the device and its resources
> aren't there anymore, but the userspace can still call into our driver.
>
> Fortunately, the DRM framework provides the drm_dev_enter() and
> drm_dev_exit() functions to make sure our underlying device is still there
> for the section protected by those calls. Let's add them to the HVS driver.

The framework appears to rely on the remove function calling
drm_dev_unplug instead of drm_dev_unregister, but I haven't seen a
patch that makes that change in the vc4 driver.
Have I missed it, or is there some other route to set the unplugged
flag that drm_dev_enter/exit are relying on?

  Dave

> Signed-off-by: Maxime Ripard 
> ---
>  drivers/gpu/drm/vc4/vc4_drv.h |   1 +
>  drivers/gpu/drm/vc4/vc4_hvs.c | 106 +++---
>  2 files changed, 99 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
> index aa4c5910ea05..080deae55f64 100644
> --- a/drivers/gpu/drm/vc4/vc4_drv.h
> +++ b/drivers/gpu/drm/vc4/vc4_drv.h
> @@ -317,6 +317,7 @@ struct vc4_v3d {
>  };
>
>  struct vc4_hvs {
> +   struct drm_device *dev;
> struct platform_device *pdev;
> void __iomem *regs;
> u32 __iomem *dlist;
> diff --git a/drivers/gpu/drm/vc4/vc4_hvs.c b/drivers/gpu/drm/vc4/vc4_hvs.c
> index 2a58fc421cf6..483053e7b14f 100644
> --- a/drivers/gpu/drm/vc4/vc4_hvs.c
> +++ b/drivers/gpu/drm/vc4/vc4_hvs.c
> @@ -25,6 +25,7 @@
>  #include 
>
>  #include 
> +#include 
>  #include 
>
>  #include "vc4_drv.h"
> @@ -66,11 +67,15 @@ static const struct debugfs_reg32 hvs_regs[] = {
>
>  void vc4_hvs_dump_state(struct vc4_hvs *hvs)
>  {
> +   struct drm_device *drm = hvs->dev;
> struct drm_printer p = drm_info_printer(&hvs->pdev->dev);
> -   int i;
> +   int idx, i;
>
> drm_print_regset32(&p, &hvs->regset);
>
> +   if (!drm_dev_enter(drm, &idx))
> +   return;
> +
> DRM_INFO("HVS ctx:\n");
> for (i = 0; i < 64; i += 4) {
> DRM_INFO("0x%08x (%s): 0x%08x 0x%08x 0x%08x 0x%08x\n",
> @@ -80,6 +85,8 @@ void vc4_hvs_dump_state(struct vc4_hvs *hvs)
>  readl((u32 __iomem *)hvs->dlist + i + 2),
>  readl((u32 __iomem *)hvs->dlist + i + 3));
> }
> +
> +   drm_dev_exit(idx);
>  }
>
>  static int vc4_hvs_debugfs_underrun(struct seq_file *m, void *data)
> @@ -132,14 +139,18 @@ static int vc4_hvs_upload_linear_kernel(struct vc4_hvs 
> *hvs,
> struct drm_mm_node *space,
> const u32 *kernel)
>  {
> -   int ret, i;
> +   struct drm_device *drm = hvs->dev;
> +   int idx, ret, i;
> u32 __iomem *dst_kernel;
>
> +   if (!drm_dev_enter(drm, &idx))
> +   return -ENODEV;
> +
> ret = drm_mm_insert_node(&hvs->dlist_mm, space, VC4_KERNEL_DWORDS);
> if (ret) {
> DRM_ERROR("Failed to allocate space for filter kernel: %d\n",
>   ret);
> -   return ret;
> +   goto err_dev_exit;
> }
>
> dst_kernel = hvs->dlist + space->start;
> @@ -153,16 +164,26 @@ static int vc4_hvs_upload_linear_kernel(struct vc4_hvs 
> *hvs,
> }
> }
>
> +   drm_dev_exit(idx);
> return 0;
> +
> +err_dev_exit:
> +   drm_dev_exit(idx);
> +   return ret;
>  }
>
>  static void vc4_hvs_lut_load(struct vc4_hvs *hvs,
>  struct vc4_crtc *vc4_crtc)
>  {
> +   struct drm_device *drm = hvs->dev;
> struct drm_crtc *crtc = &vc4_crtc->base;
> struct vc4_crtc_state *vc4_state = to_vc4_crtc_state(crtc->state);
> +   int idx;
> u32 i;
>
> +   if (!drm_dev_enter(drm, &idx))
> +   return;
> +
> /* The LUT memory is laid out with each HVS channel in order,
>  * each of which takes 256 writes for R, 256 for G, then 256
>  * for B.
> @@ -177,6 +198,8 @@ static void vc4_hvs_lut_load(struct vc4_hvs *hvs,
> HVS_WRITE(SCALER_GAMDATA, vc4_crtc->lut_g[i]);
> for (i = 0; i < crtc->gamma_size; i++)
> HVS_WRITE(SCALER_GAMDATA, vc4_crtc->lut_b[i]);
> +
> +   drm_dev_exit(idx);
>  }
>
>  static void vc4_hvs_update_gamma_lut(struct vc4_hvs *hvs,
> @@ -198,7 +221,12 @@ static void vc4_hvs_update_gamma_lut(struct vc4_hvs *hvs,
>
>  u8 vc4_hvs_get_fifo_frame_count(struct vc4_hvs *hvs, unsigned int fifo)
>  {
> +   struct drm_device *drm = hvs->dev;
> u8 field = 0;
> +   int idx;
> +
> +   if (!drm_dev_enter(drm, &idx))
> +   r

Re: [PATCH 15/64] drm/vc4: plane: Take possible_crtcs as an argument

[Dave Stevenson]

On Fri, 10 Jun 2022 at 10:30, Maxime Ripard  wrote:
>
> vc4_plane_init() currently initialises the plane with no possible CRTCs,
> and will expect the caller to set it up by itself.
>
> Let's change that logic a bit to follow the syntax of
> drm_universal_plane_init() and pass the possible CRTCs bitmask as an
> argument to the function instead.
>
> Signed-off-by: Maxime Ripard 
> ---
>  drivers/gpu/drm/vc4/vc4_crtc.c  |  2 +-
>  drivers/gpu/drm/vc4/vc4_drv.h   |  3 ++-
>  drivers/gpu/drm/vc4/vc4_plane.c | 15 +++
>  3 files changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
> index 59b20c8f132b..840a93484bb1 100644
> --- a/drivers/gpu/drm/vc4/vc4_crtc.c
> +++ b/drivers/gpu/drm/vc4/vc4_crtc.c
> @@ -1138,7 +1138,7 @@ int vc4_crtc_init(struct drm_device *drm, struct 
> vc4_crtc *vc4_crtc,
>  * requirement of the plane configuration, and reject ones
>  * that will take too much.
>  */
> -   primary_plane = vc4_plane_init(drm, DRM_PLANE_TYPE_PRIMARY);
> +   primary_plane = vc4_plane_init(drm, DRM_PLANE_TYPE_PRIMARY, 0);
> if (IS_ERR(primary_plane)) {
> dev_err(drm->dev, "failed to construct primary plane\n");
> return PTR_ERR(primary_plane);
> diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
> index 080deae55f64..5125ca1a8158 100644
> --- a/drivers/gpu/drm/vc4/vc4_drv.h
> +++ b/drivers/gpu/drm/vc4/vc4_drv.h
> @@ -952,7 +952,8 @@ int vc4_kms_load(struct drm_device *dev);
>
>  /* vc4_plane.c */
>  struct drm_plane *vc4_plane_init(struct drm_device *dev,
> -enum drm_plane_type type);
> +enum drm_plane_type type,
> +unsigned int possible_crtcs);

A nit pick.
possible_crtcs in struct drm_plane is a uint32_t , not an unsigned int.
It would never matter on a Pi as unsigned int will never be 16bit, but
avoids the oddity.

Otherwise:
Reviewed-by: Dave Stevenson 

>  int vc4_plane_create_additional_planes(struct drm_device *dev);
>  u32 vc4_plane_write_dlist(struct drm_plane *plane, u32 __iomem *dlist);
>  u32 vc4_plane_dlist_size(const struct drm_plane_state *state);
> diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
> index b3438f4a81ce..17dab470ecdf 100644
> --- a/drivers/gpu/drm/vc4/vc4_plane.c
> +++ b/drivers/gpu/drm/vc4/vc4_plane.c
> @@ -1451,7 +1451,8 @@ static const struct drm_plane_funcs vc4_plane_funcs = {
>  };
>
>  struct drm_plane *vc4_plane_init(struct drm_device *dev,
> -enum drm_plane_type type)
> +enum drm_plane_type type,
> +unsigned int possible_crtcs)
>  {
> struct drm_plane *plane = NULL;
> struct vc4_plane *vc4_plane;
> @@ -1483,7 +1484,7 @@ struct drm_plane *vc4_plane_init(struct drm_device *dev,
> }
>
> plane = &vc4_plane->base;
> -   ret = drm_universal_plane_init(dev, plane, 0,
> +   ret = drm_universal_plane_init(dev, plane, possible_crtcs,
>&vc4_plane_funcs,
>formats, num_formats,
>modifiers, type, NULL);
> @@ -1528,13 +1529,11 @@ int vc4_plane_create_additional_planes(struct 
> drm_device *drm)
>  */
> for (i = 0; i < 16; i++) {
> struct drm_plane *plane =
> -   vc4_plane_init(drm, DRM_PLANE_TYPE_OVERLAY);
> +   vc4_plane_init(drm, DRM_PLANE_TYPE_OVERLAY,
> +  GENMASK(drm->mode_config.num_crtc - 1, 
> 0));
>
> if (IS_ERR(plane))
> continue;
> -
> -   plane->possible_crtcs =
> -   GENMASK(drm->mode_config.num_crtc - 1, 0);
> }
>
> drm_for_each_crtc(crtc, drm) {
> @@ -1542,9 +1541,9 @@ int vc4_plane_create_additional_planes(struct 
> drm_device *drm)
>  * since we overlay planes on the CRTC in the order they were
>  * initialized.
>  */
> -   cursor_plane = vc4_plane_init(drm, DRM_PLANE_TYPE_CURSOR);
> +   cursor_plane = vc4_plane_init(drm, DRM_PLANE_TYPE_CURSOR,
> + drm_crtc_mask(crtc));
> if (!IS_ERR(cursor_plane)) {
> -   cursor_plane->possible_crtcs = drm_crtc_mask(crtc);
> crtc->cursor = cursor_plane;
> }
> }
> --
> 2.36.1
>

Re: [PATCH v5] drm/msm/dp: force link training for display resolution change

[Kuogee Hsieh]

On 6/14/2022 1:38 AM, Stephen Boyd wrote:

Quoting Kuogee Hsieh (2022-06-13 14:48:37)

During display resolution changes display have to be disabled first
followed by display enabling with new resolution. Display disable
will turn off both pixel clock and main link clock so that main link
have to be re-trained during display enable to have new video stream
flow again. At current implementation, display enable function manually
kicks up irq_hpd_handle which will read panel link status and start link
training if link status is not in sync state. However, there is rare
case that a particular panel links status keep staying in sync for
some period of time after main link had been shut down previously at
display disabled. Main link retraining will not be executed by
irq_hdp_handle() if the link status read from panel shows it is in
sync state. If this was happen, then video stream of newer display
resolution will fail to be transmitted to panel due to main link is
not in sync between host and panel. This patch force main link always
be retrained during display enable procedure to prevent this rare
failed case from happening. Also this implementation are more
efficient than manual kicking off irq_hpd_handle function.

How is resolution change different from disabling and enabling the
display? The commit text talks about resolution changes, but the code
doesn't compare resolutions from before and after to know when to
retrain the link. Can the code be made to actually do what the commit
text says? It would be clearer if the code looked for actual resolution
changes instead of hooking the dp_bridge_enable() function.


Resolution changes are implemented through modeset. Therefore you can 
treat resolution changes equal to modeset.


dp_bridge_enable() and dp_bridge_disable() are end of function of 
modeset since DP driver is implemented as DRM bridge.


you have to use modeset to disable previous resolution and modeset to 
enable newer resolution.


Resolution changes is the term from end user point of view. For DP 
driver, we should use modeset.


I will revise the commit text for this.





Changes in v2:
-- set force_link_train flag on DP only (is_edp == false)

Changes in v3:
-- revise commit  text
-- add Fixes tag

Changes in v4:
-- revise commit  text

Changes in v5:
-- fix spelling at commit text

Fixes: 62671d2ef24b ("drm/msm/dp: fixes wrong connection state caused by failure of 
link train")
Signed-off-by: Kuogee Hsieh 
---
  drivers/gpu/drm/msm/dp/dp_ctrl.c|  6 +++---
  drivers/gpu/drm/msm/dp/dp_ctrl.h|  2 +-
  drivers/gpu/drm/msm/dp/dp_display.c | 15 ---
  3 files changed, 12 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c b/drivers/gpu/drm/msm/dp/dp_ctrl.c
index af7a80c..bea93eb 100644
--- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
+++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
@@ -1551,7 +1551,7 @@ static int dp_ctrl_process_phy_test_request(struct 
dp_ctrl_private *ctrl)

 ret = dp_ctrl_on_link(&ctrl->dp_ctrl);
 if (!ret)
-   ret = dp_ctrl_on_stream(&ctrl->dp_ctrl);
+   ret = dp_ctrl_on_stream(&ctrl->dp_ctrl, false);

Does this even matter if it's true or false? The 'sink_request' has
DP_TEST_LINK_PHY_TEST_PATTERN set from what I can tell, and then
dp_ctrl_on_stream() bails out before calling dp_ctrl_link_retrain()
anyway. It would be nice if we could split dp_ctrl_on_stream() so that
the part after the check for the sink request is a different function
that is called by dp_display.c and then this code can call the 'prepare'
function that does the first part. Then we can ignore the testing path
in the code, and possibly remove the conditional in dp_ctrl_on_stream()?


 else
 DRM_ERROR("failed to enable DP link controller\n");

diff --git a/drivers/gpu/drm/msm/dp/dp_display.c 
b/drivers/gpu/drm/msm/dp/dp_display.c
index c388323..370348d 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -872,7 +872,7 @@ static int dp_display_enable(struct dp_display_private *dp, 
u32 data)
 return 0;
 }

-   rc = dp_ctrl_on_stream(dp->ctrl);
+   rc = dp_ctrl_on_stream(dp->ctrl, data);
 if (!rc)
 dp_display->power_on = true;

@@ -1654,6 +1654,7 @@ void dp_bridge_enable(struct drm_bridge *drm_bridge)
 int rc = 0;
 struct dp_display_private *dp_display;
 u32 state;
+   bool force_link_train = false;

 dp_display = container_of(dp, struct dp_display_private, dp_display);
 if (!dp_display->dp_mode.drm_mode.clock) {
@@ -1688,10 +1689,14 @@ void dp_bridge_enable(struct drm_bridge *drm_bridge)

 state =  dp_display->hpd_state;

-   if (state == ST_DISPLAY_OFF)
+   if (state == ST_DISPLAY_OFF) {
 dp_display_host_phy_init(dp_display);

-   dp_display_enable(dp_display, 0);
+   if (!dp->is_edp)

I didn't see any answer to my question about wh

Re: [Intel-gfx] [PATCH] drm/i915/guc: Check ctx while waiting for response

[Teres Alexis, Alan Previn]

Can't see anything wrong with this.
I consider this only a NIT, so feel : not sure if -ECANCELLED is reflective of 
the "ct service being temporarily down"
as opposed to the "requester cancelling". Perhaps a -EPIPE or -EAGAIN (if we 
got this far, we know we are probably mid-
reset) ?? (if not already used elsewhere along this callstack). Else :

Reviewed-by: Alan Previn 

...alan


On Thu, 2022-06-02 at 10:21 -0700, Zhanjun Dong wrote:
> We are seeing error message of "No response for request". Some cases happened
> while waiting for response and reset/suspend action was triggered. In this
> case, no response is not an error, active requests will be cancelled.
> 
> This patch will handle this condition and change the error message into
> debug message.
> 
> Signed-off-by: Zhanjun Dong 
> ---
>  drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 21 ++---
>  1 file changed, 14 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c 
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> index f01325cd1b62..a30a388877e2 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> @@ -467,7 +467,7 @@ static int ct_write(struct intel_guc_ct *ct,
>   * * 0 response received (status is valid)
>   * * -ETIMEDOUT no response within hardcoded timeout
>   */
> -static int wait_for_ct_request_update(struct ct_request *req, u32 *status)
> +static int wait_for_ct_request_update(struct ct_request *req, u32 *status, 
> struct intel_guc_ct *ct)
>  {
>   int err;
>  
> @@ -481,12 +481,14 @@ static int wait_for_ct_request_update(struct ct_request 
> *req, u32 *status)
>  #define GUC_CTB_RESPONSE_TIMEOUT_SHORT_MS 10
>  #define GUC_CTB_RESPONSE_TIMEOUT_LONG_MS 1000
>  #define done \
> - (FIELD_GET(GUC_HXG_MSG_0_ORIGIN, READ_ONCE(req->status)) == \
> + (!intel_guc_ct_enabled(ct) || FIELD_GET(GUC_HXG_MSG_0_ORIGIN, 
> READ_ONCE(req->status)) == \
>GUC_HXG_ORIGIN_GUC)
>   err = wait_for_us(done, GUC_CTB_RESPONSE_TIMEOUT_SHORT_MS);
>   if (err)
>   err = wait_for(done, GUC_CTB_RESPONSE_TIMEOUT_LONG_MS);
>  #undef done
> + if (!intel_guc_ct_enabled(ct))
> + err = -ECANCELED;
>  
>   *status = req->status;
>   return err;
> @@ -703,11 +705,15 @@ static int ct_send(struct intel_guc_ct *ct,
>  
>   intel_guc_notify(ct_to_guc(ct));
>  
> - err = wait_for_ct_request_update(&request, status);
> + err = wait_for_ct_request_update(&request, status, ct);
>   g2h_release_space(ct, GUC_CTB_HXG_MSG_MAX_LEN);
>   if (unlikely(err)) {
> - CT_ERROR(ct, "No response for request %#x (fence %u)\n",
> -  action[0], request.fence);
> + if (unlikely(err == ECANCELED))
> + CT_DEBUG(ct, "Request %#x (fence %u) cancelled as CTB 
> is disabled\n",
> + action[0], request.fence);
> + else
> + CT_ERROR(ct, "No response for request %#x (fence %u)\n",
> + action[0], request.fence);
>   goto unlink;
>   }
>  
> @@ -771,8 +777,9 @@ int intel_guc_ct_send(struct intel_guc_ct *ct, const u32 
> *action, u32 len,
>  
>   ret = ct_send(ct, action, len, response_buf, response_buf_size, 
> &status);
>   if (unlikely(ret < 0)) {
> - CT_ERROR(ct, "Sending action %#x failed (%pe) status=%#X\n",
> -  action[0], ERR_PTR(ret), status);
> + if (likely(ret != ECANCELED))
> + CT_ERROR(ct, "Sending action %#x failed (%pe) 
> status=%#X\n",
> + action[0], ERR_PTR(ret), status);
>   } else if (unlikely(ret)) {
>   CT_DEBUG(ct, "send action %#x returned %d (%#x)\n",
>action[0], ret, ret);
> -- 
> 2.36.0
> 

Re: [PATCH] drm/msm: Make msm_gem_free_object() static

[Dmitry Baryshkov]

On Mon, 13 Jun 2022 at 23:49, Rob Clark  wrote:
>
> From: Rob Clark 
>
> Misc small cleanup I noticed.  Not called from another object file since
> 3c9edd9c85f5 ("drm/msm: Introduce GEM object funcs")
>
> Signed-off-by: Rob Clark 

Reviewed-by: Dmitry Baryshkov 

> ---
>  drivers/gpu/drm/msm/msm_gem.c | 2 +-
>  drivers/gpu/drm/msm/msm_gem.h | 1 -
>  2 files changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
> index 35845e273d81..3ef7ada59392 100644
> --- a/drivers/gpu/drm/msm/msm_gem.c
> +++ b/drivers/gpu/drm/msm/msm_gem.c
> @@ -1004,7 +1004,7 @@ void msm_gem_describe_objects(struct list_head *list, 
> struct seq_file *m)
>  #endif
>
>  /* don't call directly!  Use drm_gem_object_put() */
> -void msm_gem_free_object(struct drm_gem_object *obj)
> +static void msm_gem_free_object(struct drm_gem_object *obj)
>  {
> struct msm_gem_object *msm_obj = to_msm_bo(obj);
> struct drm_device *dev = obj->dev;
> diff --git a/drivers/gpu/drm/msm/msm_gem.h b/drivers/gpu/drm/msm/msm_gem.h
> index 6b7d5bb3b575..d608339c1643 100644
> --- a/drivers/gpu/drm/msm/msm_gem.h
> +++ b/drivers/gpu/drm/msm/msm_gem.h
> @@ -175,7 +175,6 @@ void msm_gem_active_get(struct drm_gem_object *obj, 
> struct msm_gpu *gpu);
>  void msm_gem_active_put(struct drm_gem_object *obj);
>  int msm_gem_cpu_prep(struct drm_gem_object *obj, uint32_t op, ktime_t 
> *timeout);
>  int msm_gem_cpu_fini(struct drm_gem_object *obj);
> -void msm_gem_free_object(struct drm_gem_object *obj);
>  int msm_gem_new_handle(struct drm_device *dev, struct drm_file *file,
> uint32_t size, uint32_t flags, uint32_t *handle, char *name);
>  struct drm_gem_object *msm_gem_new(struct drm_device *dev,
> --
> 2.36.1
>


-- 
With best wishes
Dmitry

Re: [PATCH 16/64] drm/vc4: plane: Switch to drmm_universal_plane_alloc()

[Dave Stevenson]

On Fri, 10 Jun 2022 at 10:30, Maxime Ripard  wrote:
>
> Let's switch to drmm_universal_plane_alloc() for our plane allocation and
> initialisation to make the driver a bit simpler.
>
> Signed-off-by: Maxime Ripard 

Reviewed-by: Dave Stevenson 

> ---
>  drivers/gpu/drm/vc4/vc4_crtc.c  | 12 +---
>  drivers/gpu/drm/vc4/vc4_plane.c | 23 ---
>  2 files changed, 9 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
> index 840a93484bb1..7163f924b48b 100644
> --- a/drivers/gpu/drm/vc4/vc4_crtc.c
> +++ b/drivers/gpu/drm/vc4/vc4_crtc.c
> @@ -1176,7 +1176,6 @@ static int vc4_crtc_bind(struct device *dev, struct 
> device *master, void *data)
> const struct vc4_pv_data *pv_data;
> struct vc4_crtc *vc4_crtc;
> struct drm_crtc *crtc;
> -   struct drm_plane *destroy_plane, *temp;
> int ret;
>
> vc4_crtc = devm_kzalloc(dev, sizeof(*vc4_crtc), GFP_KERNEL);
> @@ -1211,7 +1210,7 @@ static int vc4_crtc_bind(struct device *dev, struct 
> device *master, void *data)
>IRQF_SHARED,
>"vc4 crtc", vc4_crtc);
> if (ret)
> -   goto err_destroy_planes;
> +   return ret;
>
> platform_set_drvdata(pdev, vc4_crtc);
>
> @@ -1219,15 +1218,6 @@ static int vc4_crtc_bind(struct device *dev, struct 
> device *master, void *data)
>  &vc4_crtc->regset);
>
> return 0;
> -
> -err_destroy_planes:
> -   list_for_each_entry_safe(destroy_plane, temp,
> -&drm->mode_config.plane_list, head) {
> -   if (destroy_plane->possible_crtcs == drm_crtc_mask(crtc))
> -   destroy_plane->funcs->destroy(destroy_plane);
> -   }
> -
> -   return ret;
>  }
>
>  static void vc4_crtc_unbind(struct device *dev, struct device *master,
> diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
> index 17dab470ecdf..673c963f5c5a 100644
> --- a/drivers/gpu/drm/vc4/vc4_plane.c
> +++ b/drivers/gpu/drm/vc4/vc4_plane.c
> @@ -1442,8 +1442,6 @@ static bool vc4_format_mod_supported(struct drm_plane 
> *plane,
>  static const struct drm_plane_funcs vc4_plane_funcs = {
> .update_plane = drm_atomic_helper_update_plane,
> .disable_plane = drm_atomic_helper_disable_plane,
> -   .destroy = drm_plane_cleanup,
> -   .set_property = NULL,
> .reset = vc4_plane_reset,
> .atomic_duplicate_state = vc4_plane_duplicate_state,
> .atomic_destroy_state = vc4_plane_destroy_state,
> @@ -1454,11 +1452,10 @@ struct drm_plane *vc4_plane_init(struct drm_device 
> *dev,
>  enum drm_plane_type type,
>  unsigned int possible_crtcs)
>  {
> -   struct drm_plane *plane = NULL;
> +   struct drm_plane *plane;
> struct vc4_plane *vc4_plane;
> u32 formats[ARRAY_SIZE(hvs_formats)];
> int num_formats = 0;
> -   int ret = 0;
> unsigned i;
> bool hvs5 = of_device_is_compatible(dev->dev->of_node,
> "brcm,bcm2711-vc5");
> @@ -1471,11 +1468,6 @@ struct drm_plane *vc4_plane_init(struct drm_device 
> *dev,
> DRM_FORMAT_MOD_INVALID
> };
>
> -   vc4_plane = devm_kzalloc(dev->dev, sizeof(*vc4_plane),
> -GFP_KERNEL);
> -   if (!vc4_plane)
> -   return ERR_PTR(-ENOMEM);
> -
> for (i = 0; i < ARRAY_SIZE(hvs_formats); i++) {
> if (!hvs_formats[i].hvs5_only || hvs5) {
> formats[num_formats] = hvs_formats[i].drm;
> @@ -1483,13 +1475,14 @@ struct drm_plane *vc4_plane_init(struct drm_device 
> *dev,
> }
> }
>
> +   vc4_plane = drmm_universal_plane_alloc(dev, struct vc4_plane, base,
> +  possible_crtcs,
> +  &vc4_plane_funcs,
> +  formats, num_formats,
> +  modifiers, type, NULL);
> +   if (IS_ERR(vc4_plane))
> +   return ERR_CAST(vc4_plane);
> plane = &vc4_plane->base;
> -   ret = drm_universal_plane_init(dev, plane, possible_crtcs,
> -  &vc4_plane_funcs,
> -  formats, num_formats,
> -  modifiers, type, NULL);
> -   if (ret)
> -   return ERR_PTR(ret);
>
> drm_plane_helper_add(plane, &vc4_plane_helper_funcs);
>
> --
> 2.36.1
>

Re: [PATCH 18/64] drm/vc4: crtc: Switch to drmm_kzalloc

[Dave Stevenson]

On Fri, 10 Jun 2022 at 10:30, Maxime Ripard  wrote:
>
> Our internal structure that stores the DRM entities structure is allocated
> through a device-managed kzalloc.
>
> This means that this will eventually be freed whenever the device is
> removed. In our case, the most like source of removal is that the main
> device is going to be unbound, and component_unbind_all() is being run.
>
> However, it occurs while the DRM device is still registered, which will
> create dangling pointers, eventually resulting in use-after-free.
>
> Switch to a DRM-managed allocation to keep our structure until the DRM
> driver doesn't need it anymore.
>
> Signed-off-by: Maxime Ripard 

Reviewed-by: Dave Stevenson 

> ---
>  drivers/gpu/drm/vc4/vc4_crtc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
> index 1f7e987e68aa..c74fa3d07561 100644
> --- a/drivers/gpu/drm/vc4/vc4_crtc.c
> +++ b/drivers/gpu/drm/vc4/vc4_crtc.c
> @@ -1178,7 +1178,7 @@ static int vc4_crtc_bind(struct device *dev, struct 
> device *master, void *data)
> struct drm_crtc *crtc;
> int ret;
>
> -   vc4_crtc = devm_kzalloc(dev, sizeof(*vc4_crtc), GFP_KERNEL);
> +   vc4_crtc = drmm_kzalloc(drm, sizeof(*vc4_crtc), GFP_KERNEL);
> if (!vc4_crtc)
> return -ENOMEM;
> crtc = &vc4_crtc->base;
> --
> 2.36.1
>

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

[Niranjana Vishwanathapura]

On Tue, Jun 14, 2022 at 08:16:41AM +0100, Tvrtko Ursulin wrote:


On 14/06/2022 00:39, Matthew Brost wrote:

On Mon, Jun 13, 2022 at 07:09:06PM +0100, Tvrtko Ursulin wrote:


On 13/06/2022 18:49, Niranjana Vishwanathapura wrote:

On Mon, Jun 13, 2022 at 05:22:02PM +0100, Tvrtko Ursulin wrote:


On 13/06/2022 16:05, Niranjana Vishwanathapura wrote:

On Mon, Jun 13, 2022 at 09:24:18AM +0100, Tvrtko Ursulin wrote:


On 10/06/2022 17:14, Niranjana Vishwanathapura wrote:

On Fri, Jun 10, 2022 at 05:48:39PM +0300, Lionel Landwerlin wrote:

On 10/06/2022 13:37, Tvrtko Ursulin wrote:


On 10/06/2022 08:07, Niranjana Vishwanathapura wrote:

VM_BIND and related uapi definitions

Signed-off-by: Niranjana Vishwanathapura

---
  Documentation/gpu/rfc/i915_vm_bind.h | 490
+++
  1 file changed, 490 insertions(+)
  create mode 100644 Documentation/gpu/rfc/i915_vm_bind.h

diff --git
a/Documentation/gpu/rfc/i915_vm_bind.h
b/Documentation/gpu/rfc/i915_vm_bind.h
new file mode 100644
index ..9fc854969cfb
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_vm_bind.h
@@ -0,0 +1,490 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+/**
+ * DOC: I915_PARAM_HAS_VM_BIND
+ *
+ * VM_BIND feature availability.
+ * See typedef drm_i915_getparam_t param.
+ * bit[0]: If set, VM_BIND is supported, otherwise not.
+ * bits[8-15]: VM_BIND implementation version.
+ * version 0 will not have VM_BIND/UNBIND
timeline fence array support.
+ */
+#define I915_PARAM_HAS_VM_BIND    57
+
+/**
+ * DOC: I915_VM_CREATE_FLAGS_USE_VM_BIND
+ *
+ * Flag to opt-in for VM_BIND mode of binding during VM creation.
+ * See struct drm_i915_gem_vm_control flags.
+ *
+ * The older execbuf2 ioctl will not
support VM_BIND mode of operation.
+ * For VM_BIND mode, we have new execbuf3
ioctl which will not accept any
+ * execlist (See struct
drm_i915_gem_execbuffer3 for more details).
+ *
+ */
+#define I915_VM_CREATE_FLAGS_USE_VM_BIND    (1 << 0)
+
+/**
+ * DOC: I915_CONTEXT_CREATE_FLAGS_LONG_RUNNING
+ *
+ * Flag to declare context as long running.
+ * See struct drm_i915_gem_context_create_ext flags.
+ *
+ * Usage of dma-fence expects that they
complete in reasonable amount of time.
+ * Compute on the other hand can be long
running. Hence it is not appropriate
+ * for compute contexts to export request
completion dma-fence to user.
+ * The dma-fence usage will be limited to
in-kernel consumption only.
+ * Compute contexts need to use user/memory fence.
+ *
+ * So, long running contexts do not support output fences. Hence,
+ * I915_EXEC_FENCE_SIGNAL (See
&drm_i915_gem_exec_fence.flags) is expected
+ * to be not used. DRM_I915_GEM_WAIT ioctl
call is also not supported for
+ * objects mapped to long running contexts.
+ */
+#define I915_CONTEXT_CREATE_FLAGS_LONG_RUNNING   (1u << 2)
+
+/* VM_BIND related ioctls */
+#define DRM_I915_GEM_VM_BIND    0x3d
+#define DRM_I915_GEM_VM_UNBIND    0x3e
+#define DRM_I915_GEM_EXECBUFFER3    0x3f
+#define DRM_I915_GEM_WAIT_USER_FENCE    0x40
+
+#define DRM_IOCTL_I915_GEM_VM_BIND
DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_VM_BIND, struct
drm_i915_gem_vm_bind)
+#define DRM_IOCTL_I915_GEM_VM_UNBIND
DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_VM_UNBIND, struct
drm_i915_gem_vm_bind)
+#define DRM_IOCTL_I915_GEM_EXECBUFFER3
DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_EXECBUFFER3, struct
drm_i915_gem_execbuffer3)
+#define DRM_IOCTL_I915_GEM_WAIT_USER_FENCE
DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_WAIT_USER_FENCE, struct
drm_i915_gem_wait_user_fence)
+
+/**
+ * struct drm_i915_gem_vm_bind - VA to object mapping to bind.
+ *
+ * This structure is passed to VM_BIND
ioctl and specifies the mapping of GPU
+ * virtual address (VA) range to the
section of an object that should be bound
+ * in the device page table of the specified address space (VM).
+ * The VA range specified must be unique
(ie., not currently bound) and can
+ * be mapped to whole object or a section
of the object (partial binding).
+ * Multiple VA mappings can be created to
the same section of the object
+ * (aliasing).
+ *
+ * The @queue_idx specifies the queue to
use for binding. Same queue can be
+ * used for both VM_BIND and VM_UNBIND
calls. All submitted bind and unbind
+ * operations in a queue are performed in the order of submission.
+ *
+ * The @start, @offset and @length should
be 4K page aligned. However the DG2
+ * and XEHPSDV has 64K page size for device
local-memory and has compact page
+ * table. On those platforms, for binding
device local-memory objects, the
+ * @start should be 2M aligned, @offset and
@length should be 64K aligned.
+ * Also, on those platforms, it is not
allowed to bind an device local-memory
+ * object and a system memory object in a
single 2M section of VA range.
+ */
+struct drm_i915_gem_vm_bind {
+    /** @vm_id: VM (address space) id to bind */
+    __u32 vm_id;
+
+    /** @queue_idx: Index of queue for binding */
+    __u32 queue_idx;


I have a question here to which I d

Re: [PATCH] drm/sun4i: dw-hdmi: Fix ddc-en GPIO consumer conflict

[Jernej Škrabec]

Dne torek, 14. junij 2022 ob 09:31:00 CEST je Samuel Holland napisal(a):
> commit 6de79dd3a920 ("drm/bridge: display-connector: add ddc-en gpio
> support") added a consumer for this GPIO in the HDMI connector device.
> This new consumer conflicts with the pre-existing GPIO consumer in the
> sun8i HDMI controller driver, which prevents the driver from probing:
> 
>   [4.983358] display-connector connector: GPIO lookup for consumer ddc-
en
>   [4.983364] display-connector connector: using device tree for GPIO 
lookup
>   [4.983392] gpio-226 (ddc-en): gpiod_request: status -16
>   [4.983399] sun8i-dw-hdmi 600.hdmi: Couldn't get ddc-en gpio
>   [4.983618] sun4i-drm display-engine: failed to bind 600.hdmi (ops 
sun8i_dw_hdmi_ops [sun8i_drm_hdmi]): -16
>   [4.984082] sun4i-drm display-engine: Couldn't bind all pipelines 
components
>   [4.984171] sun4i-drm display-engine: adev bind failed: -16
>   [4.984179] sun8i-dw-hdmi: probe of 600.hdmi failed with error -16
> 
> Both drivers have the same behavior: they leave the GPIO active for the
> life of the device. Let's take advantage of the new implementation, and
> drop the now-obsolete code from the HDMI controller driver.
> 
> Fixes: 6de79dd3a920 ("drm/bridge: display-connector: add ddc-en gpio 
support")
> Signed-off-by: Samuel Holland 

Reviewed-by: Jernej Skrabec 

Best regards,
Jernej

[PATCH] drm/amd/display: add stub for crtc_debugfs_init()

[Randy Dunlap]

Fix build error when CONFIG_DEBUG_FS is not enabled by adding a
stub function for crtc_debugfs_init().

Eliminates this build error:

../drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c: In function 
‘amdgpu_dm_crtc_late_register’:
../drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:6599:2: error: 
implicit declaration of function ‘crtc_debugfs_init’; did you mean 
‘amdgpu_debugfs_init’? [-Werror=implicit-function-declaration]
  crtc_debugfs_init(crtc);
  ^
  amdgpu_debugfs_init

Fixes: 86bc22191892 ("drm/amd/display: Support crc on specific region")
Signed-off-by: Randy Dunlap 
Cc: Wayne Lin 
Cc: Alex Deucher 
Cc: Christian König 
Cc: "Pan, Xinhui" 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |2 --
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.h |6 ++
 2 files changed, 6 insertions(+), 2 deletions(-)

--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -57,9 +57,7 @@
 #include "amdgpu_dm_irq.h"
 #include "dm_helpers.h"
 #include "amdgpu_dm_mst_types.h"
-#if defined(CONFIG_DEBUG_FS)
 #include "amdgpu_dm_debugfs.h"
-#endif
 #include "amdgpu_dm_psr.h"
 
 #include "ivsrcid/ivsrcid_vislands30.h"
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.h
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.h
@@ -31,6 +31,12 @@
 
 void connector_debugfs_init(struct amdgpu_dm_connector *connector);
 void dtn_debugfs_init(struct amdgpu_device *adev);
+
+#ifdef CONFIG_DEBUG_FS
 void crtc_debugfs_init(struct drm_crtc *crtc);
+#else
+static inline void crtc_debugfs_init(struct drm_crtc *crtc)
+{}
+#endif
 
 #endif

Re: [PATCH 17/64] drm/vc4: crtc: Move debugfs_name to crtc_data

[Dave Stevenson]

On Fri, 10 Jun 2022 at 10:30, Maxime Ripard  wrote:
>
> All the CRTCs, including the TXP, have a debugfs file and name so we can
> consolidate it into vc4_crtc_data.
>
> Signed-off-by: Maxime Ripard 

Reviewed-by: Dave Stevenson 

I was sort of expecting the vc4_debugfs_add_regset32 call to move to
vc4_crtc_init so that it would be a common call for crtcs and txp, but
that doesn't appear to happen in this set. The debugfs_name for the
txp is therefore actually unused.

> ---
>  drivers/gpu/drm/vc4/vc4_crtc.c | 18 +-
>  drivers/gpu/drm/vc4/vc4_drv.h  |  4 ++--
>  drivers/gpu/drm/vc4/vc4_txp.c  |  1 +
>  3 files changed, 12 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
> index 7163f924b48b..1f7e987e68aa 100644
> --- a/drivers/gpu/drm/vc4/vc4_crtc.c
> +++ b/drivers/gpu/drm/vc4/vc4_crtc.c
> @@ -978,10 +978,10 @@ static const struct drm_crtc_helper_funcs 
> vc4_crtc_helper_funcs = {
>
>  static const struct vc4_pv_data bcm2835_pv0_data = {
> .base = {
> +   .debugfs_name = "crtc0_regs",
> .hvs_available_channels = BIT(0),
> .hvs_output = 0,
> },
> -   .debugfs_name = "crtc0_regs",
> .fifo_depth = 64,
> .pixels_per_clock = 1,
> .encoder_types = {
> @@ -992,10 +992,10 @@ static const struct vc4_pv_data bcm2835_pv0_data = {
>
>  static const struct vc4_pv_data bcm2835_pv1_data = {
> .base = {
> +   .debugfs_name = "crtc1_regs",
> .hvs_available_channels = BIT(2),
> .hvs_output = 2,
> },
> -   .debugfs_name = "crtc1_regs",
> .fifo_depth = 64,
> .pixels_per_clock = 1,
> .encoder_types = {
> @@ -1006,10 +1006,10 @@ static const struct vc4_pv_data bcm2835_pv1_data = {
>
>  static const struct vc4_pv_data bcm2835_pv2_data = {
> .base = {
> +   .debugfs_name = "crtc2_regs",
> .hvs_available_channels = BIT(1),
> .hvs_output = 1,
> },
> -   .debugfs_name = "crtc2_regs",
> .fifo_depth = 64,
> .pixels_per_clock = 1,
> .encoder_types = {
> @@ -1020,10 +1020,10 @@ static const struct vc4_pv_data bcm2835_pv2_data = {
>
>  static const struct vc4_pv_data bcm2711_pv0_data = {
> .base = {
> +   .debugfs_name = "crtc0_regs",
> .hvs_available_channels = BIT(0),
> .hvs_output = 0,
> },
> -   .debugfs_name = "crtc0_regs",
> .fifo_depth = 64,
> .pixels_per_clock = 1,
> .encoder_types = {
> @@ -1034,10 +1034,10 @@ static const struct vc4_pv_data bcm2711_pv0_data = {
>
>  static const struct vc4_pv_data bcm2711_pv1_data = {
> .base = {
> +   .debugfs_name = "crtc1_regs",
> .hvs_available_channels = BIT(0) | BIT(1) | BIT(2),
> .hvs_output = 3,
> },
> -   .debugfs_name = "crtc1_regs",
> .fifo_depth = 64,
> .pixels_per_clock = 1,
> .encoder_types = {
> @@ -1048,10 +1048,10 @@ static const struct vc4_pv_data bcm2711_pv1_data = {
>
>  static const struct vc4_pv_data bcm2711_pv2_data = {
> .base = {
> +   .debugfs_name = "crtc2_regs",
> .hvs_available_channels = BIT(0) | BIT(1) | BIT(2),
> .hvs_output = 4,
> },
> -   .debugfs_name = "crtc2_regs",
> .fifo_depth = 256,
> .pixels_per_clock = 2,
> .encoder_types = {
> @@ -1061,10 +1061,10 @@ static const struct vc4_pv_data bcm2711_pv2_data = {
>
>  static const struct vc4_pv_data bcm2711_pv3_data = {
> .base = {
> +   .debugfs_name = "crtc3_regs",
> .hvs_available_channels = BIT(1),
> .hvs_output = 1,
> },
> -   .debugfs_name = "crtc3_regs",
> .fifo_depth = 64,
> .pixels_per_clock = 1,
> .encoder_types = {
> @@ -1074,10 +1074,10 @@ static const struct vc4_pv_data bcm2711_pv3_data = {
>
>  static const struct vc4_pv_data bcm2711_pv4_data = {
> .base = {
> +   .debugfs_name = "crtc4_regs",
> .hvs_available_channels = BIT(0) | BIT(1) | BIT(2),
> .hvs_output = 5,
> },
> -   .debugfs_name = "crtc4_regs",
> .fifo_depth = 64,
> .pixels_per_clock = 2,
> .encoder_types = {
> @@ -1214,7 +1214,7 @@ static int vc4_crtc_bind(struct device *dev, struct 
> device *master, void *data)
>
> platform_set_drvdata(pdev, vc4_crtc);
>
> -   vc4_debugfs_add_regset32(drm, pv_data->debugfs_name,
> +   vc4_debugfs_add_regset32(drm, pv_data->base.debugfs_name,
>  &vc4_crtc->regset);
>
> return 0;
> diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
> index 5125ca1a8158..9a53ace85d95 100644
> --- a/drivers/gpu/drm/vc4/vc4_drv.h
> +++ b/drivers/gpu/drm/vc4/vc4_drv.h
> @@ -457,

Re: [PATCH 20/64] drm/vc4: dpi: Remove vc4_dev dpi pointer

[Dave Stevenson]

On Fri, 10 Jun 2022 at 10:30, Maxime Ripard  wrote:
>
> There's no user for that pointer so let's just get rid of it.
>
> Signed-off-by: Maxime Ripard 

Reviewed-by: Dave Stevenson 

> ---
>  drivers/gpu/drm/vc4/vc4_dpi.c | 7 ---
>  drivers/gpu/drm/vc4/vc4_drv.h | 1 -
>  2 files changed, 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_dpi.c b/drivers/gpu/drm/vc4/vc4_dpi.c
> index c180eb60bee8..f2b46c524919 100644
> --- a/drivers/gpu/drm/vc4/vc4_dpi.c
> +++ b/drivers/gpu/drm/vc4/vc4_dpi.c
> @@ -249,7 +249,6 @@ static int vc4_dpi_bind(struct device *dev, struct device 
> *master, void *data)
>  {
> struct platform_device *pdev = to_platform_device(dev);
> struct drm_device *drm = dev_get_drvdata(master);
> -   struct vc4_dev *vc4 = to_vc4_dev(drm);
> struct vc4_dpi *dpi;
> struct vc4_dpi_encoder *vc4_dpi_encoder;
> int ret;
> @@ -308,8 +307,6 @@ static int vc4_dpi_bind(struct device *dev, struct device 
> *master, void *data)
>
> dev_set_drvdata(dev, dpi);
>
> -   vc4->dpi = dpi;
> -
> vc4_debugfs_add_regset32(drm, "dpi_regs", &dpi->regset);
>
> return 0;
> @@ -323,8 +320,6 @@ static int vc4_dpi_bind(struct device *dev, struct device 
> *master, void *data)
>  static void vc4_dpi_unbind(struct device *dev, struct device *master,
>void *data)
>  {
> -   struct drm_device *drm = dev_get_drvdata(master);
> -   struct vc4_dev *vc4 = to_vc4_dev(drm);
> struct vc4_dpi *dpi = dev_get_drvdata(dev);
>
> drm_of_panel_bridge_remove(dev->of_node, 0, 0);
> @@ -332,8 +327,6 @@ static void vc4_dpi_unbind(struct device *dev, struct 
> device *master,
> drm_encoder_cleanup(dpi->encoder);
>
> clk_disable_unprepare(dpi->core_clock);
> -
> -   vc4->dpi = NULL;
>  }
>
>  static const struct component_ops vc4_dpi_ops = {
> diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
> index fff3772be2d4..846f3cda179a 100644
> --- a/drivers/gpu/drm/vc4/vc4_drv.h
> +++ b/drivers/gpu/drm/vc4/vc4_drv.h
> @@ -79,7 +79,6 @@ struct vc4_dev {
>
> struct vc4_hvs *hvs;
> struct vc4_v3d *v3d;
> -   struct vc4_dpi *dpi;
> struct vc4_vec *vec;
> struct vc4_txp *txp;
>
> --
> 2.36.1
>

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

[Tvrtko Ursulin]

On 14/06/2022 16:43, Niranjana Vishwanathapura wrote:

On Tue, Jun 14, 2022 at 08:16:41AM +0100, Tvrtko Ursulin wrote:


On 14/06/2022 00:39, Matthew Brost wrote:

On Mon, Jun 13, 2022 at 07:09:06PM +0100, Tvrtko Ursulin wrote:


On 13/06/2022 18:49, Niranjana Vishwanathapura wrote:

On Mon, Jun 13, 2022 at 05:22:02PM +0100, Tvrtko Ursulin wrote:


On 13/06/2022 16:05, Niranjana Vishwanathapura wrote:

On Mon, Jun 13, 2022 at 09:24:18AM +0100, Tvrtko Ursulin wrote:


On 10/06/2022 17:14, Niranjana Vishwanathapura wrote:

On Fri, Jun 10, 2022 at 05:48:39PM +0300, Lionel Landwerlin wrote:

On 10/06/2022 13:37, Tvrtko Ursulin wrote:


On 10/06/2022 08:07, Niranjana Vishwanathapura wrote:

VM_BIND and related uapi definitions

Signed-off-by: Niranjana Vishwanathapura

---
  Documentation/gpu/rfc/i915_vm_bind.h | 490
+++
  1 file changed, 490 insertions(+)
  create mode 100644 Documentation/gpu/rfc/i915_vm_bind.h

diff --git
a/Documentation/gpu/rfc/i915_vm_bind.h
b/Documentation/gpu/rfc/i915_vm_bind.h
new file mode 100644
index ..9fc854969cfb
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_vm_bind.h
@@ -0,0 +1,490 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+/**
+ * DOC: I915_PARAM_HAS_VM_BIND
+ *
+ * VM_BIND feature availability.
+ * See typedef drm_i915_getparam_t param.
+ * bit[0]: If set, VM_BIND is supported, otherwise not.
+ * bits[8-15]: VM_BIND implementation version.
+ * version 0 will not have VM_BIND/UNBIND
timeline fence array support.
+ */
+#define I915_PARAM_HAS_VM_BIND    57
+
+/**
+ * DOC: I915_VM_CREATE_FLAGS_USE_VM_BIND
+ *
+ * Flag to opt-in for VM_BIND mode of binding during VM 
creation.

+ * See struct drm_i915_gem_vm_control flags.
+ *
+ * The older execbuf2 ioctl will not
support VM_BIND mode of operation.
+ * For VM_BIND mode, we have new execbuf3
ioctl which will not accept any
+ * execlist (See struct
drm_i915_gem_execbuffer3 for more details).
+ *
+ */
+#define I915_VM_CREATE_FLAGS_USE_VM_BIND    (1 << 0)
+
+/**
+ * DOC: I915_CONTEXT_CREATE_FLAGS_LONG_RUNNING
+ *
+ * Flag to declare context as long running.
+ * See struct drm_i915_gem_context_create_ext flags.
+ *
+ * Usage of dma-fence expects that they
complete in reasonable amount of time.
+ * Compute on the other hand can be long
running. Hence it is not appropriate
+ * for compute contexts to export request
completion dma-fence to user.
+ * The dma-fence usage will be limited to
in-kernel consumption only.
+ * Compute contexts need to use user/memory fence.
+ *
+ * So, long running contexts do not support output fences. 
Hence,

+ * I915_EXEC_FENCE_SIGNAL (See
&drm_i915_gem_exec_fence.flags) is expected
+ * to be not used. DRM_I915_GEM_WAIT ioctl
call is also not supported for
+ * objects mapped to long running contexts.
+ */
+#define I915_CONTEXT_CREATE_FLAGS_LONG_RUNNING   (1u << 2)
+
+/* VM_BIND related ioctls */
+#define DRM_I915_GEM_VM_BIND    0x3d
+#define DRM_I915_GEM_VM_UNBIND    0x3e
+#define DRM_I915_GEM_EXECBUFFER3    0x3f
+#define DRM_I915_GEM_WAIT_USER_FENCE    0x40
+
+#define DRM_IOCTL_I915_GEM_VM_BIND
DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_VM_BIND, struct
drm_i915_gem_vm_bind)
+#define DRM_IOCTL_I915_GEM_VM_UNBIND
DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_VM_UNBIND, struct
drm_i915_gem_vm_bind)
+#define DRM_IOCTL_I915_GEM_EXECBUFFER3
DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_EXECBUFFER3, struct
drm_i915_gem_execbuffer3)
+#define DRM_IOCTL_I915_GEM_WAIT_USER_FENCE
DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_WAIT_USER_FENCE, struct
drm_i915_gem_wait_user_fence)
+
+/**
+ * struct drm_i915_gem_vm_bind - VA to object mapping to bind.
+ *
+ * This structure is passed to VM_BIND
ioctl and specifies the mapping of GPU
+ * virtual address (VA) range to the
section of an object that should be bound
+ * in the device page table of the specified address space 
(VM).

+ * The VA range specified must be unique
(ie., not currently bound) and can
+ * be mapped to whole object or a section
of the object (partial binding).
+ * Multiple VA mappings can be created to
the same section of the object
+ * (aliasing).
+ *
+ * The @queue_idx specifies the queue to
use for binding. Same queue can be
+ * used for both VM_BIND and VM_UNBIND
calls. All submitted bind and unbind
+ * operations in a queue are performed in the order of 
submission.

+ *
+ * The @start, @offset and @length should
be 4K page aligned. However the DG2
+ * and XEHPSDV has 64K page size for device
local-memory and has compact page
+ * table. On those platforms, for binding
device local-memory objects, the
+ * @start should be 2M aligned, @offset and
@length should be 64K aligned.
+ * Also, on those platforms, it is not
allowed to bind an device local-memory
+ * object and a system memory object in a
single 2M section of VA range.
+ */
+struct drm_i915_gem_vm_bind {
+    /** @vm_id: VM (address space) id to bind */
+    __u32 vm_id;
+
+    /** @queue_idx: Index of queue for bindi

Re: [PATCH 21/64] drm/vc4: dpi: Embed DRM structures into the private structure

[Dave Stevenson]

On Fri, 10 Jun 2022 at 10:30, Maxime Ripard  wrote:
>
> The VC4 DPI driver private structure contains only a pointer to the
> encoder it implements. This makes the overall structure somewhat
> inconsistent with the rest of the driver, and complicates its
> initialisation without any apparent gain.
>
> Let's embed the drm_encoder structure (through the vc4_encoder one) into
> struct vc4_dpi to fix both issues.
>
> Signed-off-by: Maxime Ripard 

Reviewed-by: Dave Stevenson 

> ---
>  drivers/gpu/drm/vc4/vc4_dpi.c | 49 ---
>  1 file changed, 16 insertions(+), 33 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_dpi.c b/drivers/gpu/drm/vc4/vc4_dpi.c
> index f2b46c524919..c88e8e397730 100644
> --- a/drivers/gpu/drm/vc4/vc4_dpi.c
> +++ b/drivers/gpu/drm/vc4/vc4_dpi.c
> @@ -83,10 +83,10 @@
>
>  /* General DPI hardware state. */
>  struct vc4_dpi {
> +   struct vc4_encoder encoder;
> +
> struct platform_device *pdev;
>
> -   struct drm_encoder *encoder;
> -
> void __iomem *regs;
>
> struct clk *pixel_clock;
> @@ -95,21 +95,15 @@ struct vc4_dpi {
> struct debugfs_regset32 regset;
>  };
>
> +static inline struct vc4_dpi *
> +to_vc4_dpi(struct drm_encoder *encoder)
> +{
> +   return container_of(encoder, struct vc4_dpi, encoder.base);
> +}
> +
>  #define DPI_READ(offset) readl(dpi->regs + (offset))
>  #define DPI_WRITE(offset, val) writel(val, dpi->regs + (offset))
>
> -/* VC4 DPI encoder KMS struct */
> -struct vc4_dpi_encoder {
> -   struct vc4_encoder base;
> -   struct vc4_dpi *dpi;
> -};
> -
> -static inline struct vc4_dpi_encoder *
> -to_vc4_dpi_encoder(struct drm_encoder *encoder)
> -{
> -   return container_of(encoder, struct vc4_dpi_encoder, base.base);
> -}
> -
>  static const struct debugfs_reg32 dpi_regs[] = {
> VC4_REG32(DPI_C),
> VC4_REG32(DPI_ID),
> @@ -117,8 +111,7 @@ static const struct debugfs_reg32 dpi_regs[] = {
>
>  static void vc4_dpi_encoder_disable(struct drm_encoder *encoder)
>  {
> -   struct vc4_dpi_encoder *vc4_encoder = to_vc4_dpi_encoder(encoder);
> -   struct vc4_dpi *dpi = vc4_encoder->dpi;
> +   struct vc4_dpi *dpi = to_vc4_dpi(encoder);
>
> clk_disable_unprepare(dpi->pixel_clock);
>  }
> @@ -127,8 +120,7 @@ static void vc4_dpi_encoder_enable(struct drm_encoder 
> *encoder)
>  {
> struct drm_device *dev = encoder->dev;
> struct drm_display_mode *mode = &encoder->crtc->mode;
> -   struct vc4_dpi_encoder *vc4_encoder = to_vc4_dpi_encoder(encoder);
> -   struct vc4_dpi *dpi = vc4_encoder->dpi;
> +   struct vc4_dpi *dpi = to_vc4_dpi(encoder);
> struct drm_connector_list_iter conn_iter;
> struct drm_connector *connector = NULL, *connector_scan;
> u32 dpi_c = DPI_ENABLE | DPI_OUTPUT_ENABLE_MODE;
> @@ -242,7 +234,7 @@ static int vc4_dpi_init_bridge(struct vc4_dpi *dpi)
> return PTR_ERR(bridge);
> }
>
> -   return drm_bridge_attach(dpi->encoder, bridge, NULL, 0);
> +   return drm_bridge_attach(&dpi->encoder.base, bridge, NULL, 0);
>  }
>
>  static int vc4_dpi_bind(struct device *dev, struct device *master, void 
> *data)
> @@ -250,21 +242,12 @@ static int vc4_dpi_bind(struct device *dev, struct 
> device *master, void *data)
> struct platform_device *pdev = to_platform_device(dev);
> struct drm_device *drm = dev_get_drvdata(master);
> struct vc4_dpi *dpi;
> -   struct vc4_dpi_encoder *vc4_dpi_encoder;
> int ret;
>
> dpi = devm_kzalloc(dev, sizeof(*dpi), GFP_KERNEL);
> if (!dpi)
> return -ENOMEM;
> -
> -   vc4_dpi_encoder = devm_kzalloc(dev, sizeof(*vc4_dpi_encoder),
> -  GFP_KERNEL);
> -   if (!vc4_dpi_encoder)
> -   return -ENOMEM;
> -   vc4_dpi_encoder->base.type = VC4_ENCODER_TYPE_DPI;
> -   vc4_dpi_encoder->dpi = dpi;
> -   dpi->encoder = &vc4_dpi_encoder->base.base;
> -
> +   dpi->encoder.type = VC4_ENCODER_TYPE_DPI;
> dpi->pdev = pdev;
> dpi->regs = vc4_ioremap_regs(pdev, 0);
> if (IS_ERR(dpi->regs))
> @@ -298,8 +281,8 @@ static int vc4_dpi_bind(struct device *dev, struct device 
> *master, void *data)
> if (ret)
> DRM_ERROR("Failed to turn on core clock: %d\n", ret);
>
> -   drm_simple_encoder_init(drm, dpi->encoder, DRM_MODE_ENCODER_DPI);
> -   drm_encoder_helper_add(dpi->encoder, &vc4_dpi_encoder_helper_funcs);
> +   drm_simple_encoder_init(drm, &dpi->encoder.base, 
> DRM_MODE_ENCODER_DPI);
> +   drm_encoder_helper_add(&dpi->encoder.base, 
> &vc4_dpi_encoder_helper_funcs);
>
> ret = vc4_dpi_init_bridge(dpi);
> if (ret)
> @@ -312,7 +295,7 @@ static int vc4_dpi_bind(struct device *dev, struct device 
> *master, void *data)
> return 0;
>
>  err_destroy_encoder:
> -   drm_encoder_cleanup(dpi->encoder);
> +   drm_encoder_cleanup(&dpi->encode

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

[Tvrtko Ursulin]

On 14/06/2022 17:02, Tvrtko Ursulin wrote:


On 14/06/2022 16:43, Niranjana Vishwanathapura wrote:

On Tue, Jun 14, 2022 at 08:16:41AM +0100, Tvrtko Ursulin wrote:


On 14/06/2022 00:39, Matthew Brost wrote:

On Mon, Jun 13, 2022 at 07:09:06PM +0100, Tvrtko Ursulin wrote:


On 13/06/2022 18:49, Niranjana Vishwanathapura wrote:

On Mon, Jun 13, 2022 at 05:22:02PM +0100, Tvrtko Ursulin wrote:


On 13/06/2022 16:05, Niranjana Vishwanathapura wrote:

On Mon, Jun 13, 2022 at 09:24:18AM +0100, Tvrtko Ursulin wrote:


On 10/06/2022 17:14, Niranjana Vishwanathapura wrote:
On Fri, Jun 10, 2022 at 05:48:39PM +0300, Lionel Landwerlin 
wrote:

On 10/06/2022 13:37, Tvrtko Ursulin wrote:


On 10/06/2022 08:07, Niranjana Vishwanathapura wrote:

VM_BIND and related uapi definitions

Signed-off-by: Niranjana Vishwanathapura

---
  Documentation/gpu/rfc/i915_vm_bind.h | 490
+++
  1 file changed, 490 insertions(+)
  create mode 100644 Documentation/gpu/rfc/i915_vm_bind.h

diff --git
a/Documentation/gpu/rfc/i915_vm_bind.h
b/Documentation/gpu/rfc/i915_vm_bind.h
new file mode 100644
index ..9fc854969cfb
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_vm_bind.h
@@ -0,0 +1,490 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+/**
+ * DOC: I915_PARAM_HAS_VM_BIND
+ *
+ * VM_BIND feature availability.
+ * See typedef drm_i915_getparam_t param.
+ * bit[0]: If set, VM_BIND is supported, otherwise not.
+ * bits[8-15]: VM_BIND implementation version.
+ * version 0 will not have VM_BIND/UNBIND
timeline fence array support.
+ */
+#define I915_PARAM_HAS_VM_BIND    57
+
+/**
+ * DOC: I915_VM_CREATE_FLAGS_USE_VM_BIND
+ *
+ * Flag to opt-in for VM_BIND mode of binding during VM 
creation.

+ * See struct drm_i915_gem_vm_control flags.
+ *
+ * The older execbuf2 ioctl will not
support VM_BIND mode of operation.
+ * For VM_BIND mode, we have new execbuf3
ioctl which will not accept any
+ * execlist (See struct
drm_i915_gem_execbuffer3 for more details).
+ *
+ */
+#define I915_VM_CREATE_FLAGS_USE_VM_BIND    (1 << 0)
+
+/**
+ * DOC: I915_CONTEXT_CREATE_FLAGS_LONG_RUNNING
+ *
+ * Flag to declare context as long running.
+ * See struct drm_i915_gem_context_create_ext flags.
+ *
+ * Usage of dma-fence expects that they
complete in reasonable amount of time.
+ * Compute on the other hand can be long
running. Hence it is not appropriate
+ * for compute contexts to export request
completion dma-fence to user.
+ * The dma-fence usage will be limited to
in-kernel consumption only.
+ * Compute contexts need to use user/memory fence.
+ *
+ * So, long running contexts do not support output fences. 
Hence,

+ * I915_EXEC_FENCE_SIGNAL (See
&drm_i915_gem_exec_fence.flags) is expected
+ * to be not used. DRM_I915_GEM_WAIT ioctl
call is also not supported for
+ * objects mapped to long running contexts.
+ */
+#define I915_CONTEXT_CREATE_FLAGS_LONG_RUNNING   (1u << 2)
+
+/* VM_BIND related ioctls */
+#define DRM_I915_GEM_VM_BIND    0x3d
+#define DRM_I915_GEM_VM_UNBIND    0x3e
+#define DRM_I915_GEM_EXECBUFFER3    0x3f
+#define DRM_I915_GEM_WAIT_USER_FENCE    0x40
+
+#define DRM_IOCTL_I915_GEM_VM_BIND
DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_VM_BIND, struct
drm_i915_gem_vm_bind)
+#define DRM_IOCTL_I915_GEM_VM_UNBIND
DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_VM_UNBIND, struct
drm_i915_gem_vm_bind)
+#define DRM_IOCTL_I915_GEM_EXECBUFFER3
DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_EXECBUFFER3, struct
drm_i915_gem_execbuffer3)
+#define DRM_IOCTL_I915_GEM_WAIT_USER_FENCE
DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_WAIT_USER_FENCE, struct
drm_i915_gem_wait_user_fence)
+
+/**
+ * struct drm_i915_gem_vm_bind - VA to object mapping to 
bind.

+ *
+ * This structure is passed to VM_BIND
ioctl and specifies the mapping of GPU
+ * virtual address (VA) range to the
section of an object that should be bound
+ * in the device page table of the specified address space 
(VM).

+ * The VA range specified must be unique
(ie., not currently bound) and can
+ * be mapped to whole object or a section
of the object (partial binding).
+ * Multiple VA mappings can be created to
the same section of the object
+ * (aliasing).
+ *
+ * The @queue_idx specifies the queue to
use for binding. Same queue can be
+ * used for both VM_BIND and VM_UNBIND
calls. All submitted bind and unbind
+ * operations in a queue are performed in the order of 
submission.

+ *
+ * The @start, @offset and @length should
be 4K page aligned. However the DG2
+ * and XEHPSDV has 64K page size for device
local-memory and has compact page
+ * table. On those platforms, for binding
device local-memory objects, the
+ * @start should be 2M aligned, @offset and
@length should be 64K aligned.
+ * Also, on those platforms, it is not
allowed to bind an device local-memory
+ * object and a system memory object in a
single 2M section of VA range.
+ */
+struct drm_i915_gem_vm_bind {
+    /** @vm_id: VM (address space) id to bind */
+    __u32 vm_id;

Re: [Intel-gfx] [PATCH] drm/i915/guc: Check ctx while waiting for response

[Michal Wajdeczko]

On 02.06.2022 19:21, Zhanjun Dong wrote:
> We are seeing error message of "No response for request". Some cases happened
> while waiting for response and reset/suspend action was triggered. In this
> case, no response is not an error, active requests will be cancelled.
> 
> This patch will handle this condition and change the error message into
> debug message.
> 
> Signed-off-by: Zhanjun Dong 
> ---
>  drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 21 ++---
>  1 file changed, 14 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c 
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> index f01325cd1b62..a30a388877e2 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> @@ -467,7 +467,7 @@ static int ct_write(struct intel_guc_ct *ct,
>   * * 0 response received (status is valid)
>   * * -ETIMEDOUT no response within hardcoded timeout
>   */
> -static int wait_for_ct_request_update(struct ct_request *req, u32 *status)
> +static int wait_for_ct_request_update(struct ct_request *req, u32 *status, 
> struct intel_guc_ct *ct)

if you need to add "intel_guc_ct *ct" param then make it the first one

>  {
>   int err;
>  
> @@ -481,12 +481,14 @@ static int wait_for_ct_request_update(struct ct_request 
> *req, u32 *status)
>  #define GUC_CTB_RESPONSE_TIMEOUT_SHORT_MS 10
>  #define GUC_CTB_RESPONSE_TIMEOUT_LONG_MS 1000
>  #define done \
> - (FIELD_GET(GUC_HXG_MSG_0_ORIGIN, READ_ONCE(req->status)) == \
> + (!intel_guc_ct_enabled(ct) || FIELD_GET(GUC_HXG_MSG_0_ORIGIN, 
> READ_ONCE(req->status)) == \
>GUC_HXG_ORIGIN_GUC)
>   err = wait_for_us(done, GUC_CTB_RESPONSE_TIMEOUT_SHORT_MS);
>   if (err)
>   err = wait_for(done, GUC_CTB_RESPONSE_TIMEOUT_LONG_MS);
>  #undef done
> + if (!intel_guc_ct_enabled(ct))
> + err = -ECANCELED;
>  
>   *status = req->status;
>   return err;
> @@ -703,11 +705,15 @@ static int ct_send(struct intel_guc_ct *ct,
>  
>   intel_guc_notify(ct_to_guc(ct));
>  
> - err = wait_for_ct_request_update(&request, status);
> + err = wait_for_ct_request_update(&request, status, ct);
>   g2h_release_space(ct, GUC_CTB_HXG_MSG_MAX_LEN);
>   if (unlikely(err)) {
> - CT_ERROR(ct, "No response for request %#x (fence %u)\n",
> -  action[0], request.fence);
> + if (unlikely(err == ECANCELED))

you are looking for -ECANCELED
and I guess you can safely drop "unlikely" hint here

> + CT_DEBUG(ct, "Request %#x (fence %u) cancelled as CTB 
> is disabled\n",
> + action[0], request.fence);
> + else
> + CT_ERROR(ct, "No response for request %#x (fence %u)\n",
> + action[0], request.fence);
>   goto unlink;
>   }
>  
> @@ -771,8 +777,9 @@ int intel_guc_ct_send(struct intel_guc_ct *ct, const u32 
> *action, u32 len,
>  
>   ret = ct_send(ct, action, len, response_buf, response_buf_size, 
> &status);
>   if (unlikely(ret < 0)) {
> - CT_ERROR(ct, "Sending action %#x failed (%pe) status=%#X\n",
> -  action[0], ERR_PTR(ret), status);
> + if (likely(ret != ECANCELED))

ditto

,Michal

> + CT_ERROR(ct, "Sending action %#x failed (%pe) 
> status=%#X\n",
> + action[0], ERR_PTR(ret), status);
>   } else if (unlikely(ret)) {
>   CT_DEBUG(ct, "send action %#x returned %d (%#x)\n",
>action[0], ret, ret);

Re: [PATCH 22/64] drm/vc4: dpi: Switch to drmm_kzalloc

[Dave Stevenson]

On Fri, 10 Jun 2022 at 10:30, Maxime Ripard  wrote:
>
> Our internal structure that stores the DRM entities structure is allocated
> through a device-managed kzalloc.
>
> This means that this will eventually be freed whenever the device is
> removed. In our case, the most like source of removal is that the main
> device is going to be unbound, and component_unbind_all() is being run.
>
> However, it occurs while the DRM device is still registered, which will
> create dangling pointers, eventually resulting in use-after-free.
>
> Switch to a DRM-managed allocation to keep our structure until the DRM
> driver doesn't need it anymore.
>
> Signed-off-by: Maxime Ripard 

Reviewed-by: Dave Stevenson 

> ---
>  drivers/gpu/drm/vc4/vc4_dpi.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_dpi.c b/drivers/gpu/drm/vc4/vc4_dpi.c
> index c88e8e397730..d1eaafb43bd1 100644
> --- a/drivers/gpu/drm/vc4/vc4_dpi.c
> +++ b/drivers/gpu/drm/vc4/vc4_dpi.c
> @@ -244,9 +244,10 @@ static int vc4_dpi_bind(struct device *dev, struct 
> device *master, void *data)
> struct vc4_dpi *dpi;
> int ret;
>
> -   dpi = devm_kzalloc(dev, sizeof(*dpi), GFP_KERNEL);
> +   dpi = drmm_kzalloc(drm, sizeof(*dpi), GFP_KERNEL);
> if (!dpi)
> return -ENOMEM;
> +
> dpi->encoder.type = VC4_ENCODER_TYPE_DPI;
> dpi->pdev = pdev;
> dpi->regs = vc4_ioremap_regs(pdev, 0);
> --
> 2.36.1
>

Re: [PATCH 19/64] drm/vc4: crtc: Switch to DRM-managed CRTC initialization

[Dave Stevenson]

On Fri, 10 Jun 2022 at 10:30, Maxime Ripard  wrote:
>
> The current code will call drm_crtc_cleanup() when the device is
> unbound. However, by then, there might still be some references held to
> that CRTC, including by the userspace that might still have the DRM
> device open.
>
> Let's switch to a DRM-managed initialization to clean up after ourselves
> only once the DRM device has been last closed.
>
> Signed-off-by: Maxime Ripard 
> ---
>  drivers/gpu/drm/vc4/vc4_crtc.c | 18 +++---
>  drivers/gpu/drm/vc4/vc4_drv.h  |  1 -
>  drivers/gpu/drm/vc4/vc4_txp.c  |  1 -
>  3 files changed, 7 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
> index c74fa3d07561..24de4706b61a 100644
> --- a/drivers/gpu/drm/vc4/vc4_crtc.c
> +++ b/drivers/gpu/drm/vc4/vc4_crtc.c
> @@ -205,11 +205,6 @@ static bool vc4_crtc_get_scanout_position(struct 
> drm_crtc *crtc,
> return ret;
>  }
>
> -void vc4_crtc_destroy(struct drm_crtc *crtc)
> -{
> -   drm_crtc_cleanup(crtc);
> -}
> -
>  static u32 vc4_get_fifo_full_level(struct vc4_crtc *vc4_crtc, u32 format)
>  {
> const struct vc4_crtc_data *crtc_data = 
> vc4_crtc_to_vc4_crtc_data(vc4_crtc);
> @@ -953,7 +948,6 @@ void vc4_crtc_reset(struct drm_crtc *crtc)
>
>  static const struct drm_crtc_funcs vc4_crtc_funcs = {
> .set_config = drm_atomic_helper_set_config,
> -   .destroy = vc4_crtc_destroy,
> .page_flip = vc4_page_flip,
> .set_property = NULL,
> .cursor_set = NULL, /* handled by drm_mode_cursor_universal */
> @@ -1131,6 +1125,7 @@ int vc4_crtc_init(struct drm_device *drm, struct 
> vc4_crtc *vc4_crtc,
> struct drm_crtc *crtc = &vc4_crtc->base;
> struct drm_plane *primary_plane;
> unsigned int i;
> +   int ret;
>
> /* For now, we create just the primary and the legacy cursor
>  * planes.  We should be able to stack more planes on easily,
> @@ -1144,10 +1139,13 @@ int vc4_crtc_init(struct drm_device *drm, struct 
> vc4_crtc *vc4_crtc,
> return PTR_ERR(primary_plane);
> }
>
> -   spin_lock_init(&vc4_crtc->irq_lock);
> -   drm_crtc_init_with_planes(drm, crtc, primary_plane, NULL,
> - crtc_funcs, NULL);
> +   ret = drmm_crtc_init_with_planes(drm, crtc, primary_plane, NULL,
> +crtc_funcs, NULL);
> +   if (ret)
> +   return ret;
> +
> drm_crtc_helper_add(crtc, crtc_helper_funcs);
> +   spin_lock_init(&vc4_crtc->irq_lock);

Moving the spin_lock_init appears to be cosmetic and unrelated, but otherwise:

Reviewed-by: Dave Stevenson 

>
> if (!vc4->hvs->hvs5) {
> drm_mode_crtc_set_gamma_size(crtc, 
> ARRAY_SIZE(vc4_crtc->lut_r));
> @@ -1226,8 +1224,6 @@ static void vc4_crtc_unbind(struct device *dev, struct 
> device *master,
> struct platform_device *pdev = to_platform_device(dev);
> struct vc4_crtc *vc4_crtc = dev_get_drvdata(dev);
>
> -   vc4_crtc_destroy(&vc4_crtc->base);
> -
> CRTC_WRITE(PV_INTEN, 0);
>
> platform_set_drvdata(pdev, NULL);
> diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
> index 9a53ace85d95..fff3772be2d4 100644
> --- a/drivers/gpu/drm/vc4/vc4_drv.h
> +++ b/drivers/gpu/drm/vc4/vc4_drv.h
> @@ -845,7 +845,6 @@ int vc4_crtc_disable_at_boot(struct drm_crtc *crtc);
>  int vc4_crtc_init(struct drm_device *drm, struct vc4_crtc *vc4_crtc,
>   const struct drm_crtc_funcs *crtc_funcs,
>   const struct drm_crtc_helper_funcs *crtc_helper_funcs);
> -void vc4_crtc_destroy(struct drm_crtc *crtc);
>  int vc4_page_flip(struct drm_crtc *crtc,
>   struct drm_framebuffer *fb,
>   struct drm_pending_vblank_event *event,
> diff --git a/drivers/gpu/drm/vc4/vc4_txp.c b/drivers/gpu/drm/vc4/vc4_txp.c
> index e983ff7c5e13..f306e05ac5b2 100644
> --- a/drivers/gpu/drm/vc4/vc4_txp.c
> +++ b/drivers/gpu/drm/vc4/vc4_txp.c
> @@ -383,7 +383,6 @@ static void vc4_txp_disable_vblank(struct drm_crtc *crtc) 
> {}
>
>  static const struct drm_crtc_funcs vc4_txp_crtc_funcs = {
> .set_config = drm_atomic_helper_set_config,
> -   .destroy= vc4_crtc_destroy,
> .page_flip  = vc4_page_flip,
> .reset  = vc4_crtc_reset,
> .atomic_duplicate_state = vc4_crtc_duplicate_state,
> --
> 2.36.1
>

Re: [PATCH 3/3] drm/doc/rfc: VM_BIND uapi definition

[Niranjana Vishwanathapura]

On Tue, Jun 14, 2022 at 09:27:05AM +0300, Lionel Landwerlin wrote:

On 10/06/2022 11:53, Matthew Brost wrote:

On Fri, Jun 10, 2022 at 12:07:11AM -0700, Niranjana Vishwanathapura wrote:

VM_BIND and related uapi definitions

Signed-off-by: Niranjana Vishwanathapura 
---
 Documentation/gpu/rfc/i915_vm_bind.h | 490 +++
 1 file changed, 490 insertions(+)
 create mode 100644 Documentation/gpu/rfc/i915_vm_bind.h

diff --git a/Documentation/gpu/rfc/i915_vm_bind.h 
b/Documentation/gpu/rfc/i915_vm_bind.h
new file mode 100644
index ..9fc854969cfb
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_vm_bind.h
@@ -0,0 +1,490 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+/**
+ * DOC: I915_PARAM_HAS_VM_BIND
+ *
+ * VM_BIND feature availability.
+ * See typedef drm_i915_getparam_t param.
+ * bit[0]: If set, VM_BIND is supported, otherwise not.
+ * bits[8-15]: VM_BIND implementation version.
+ * version 0 will not have VM_BIND/UNBIND timeline fence array support.
+ */
+#define I915_PARAM_HAS_VM_BIND 57
+
+/**
+ * DOC: I915_VM_CREATE_FLAGS_USE_VM_BIND
+ *
+ * Flag to opt-in for VM_BIND mode of binding during VM creation.
+ * See struct drm_i915_gem_vm_control flags.
+ *
+ * The older execbuf2 ioctl will not support VM_BIND mode of operation.
+ * For VM_BIND mode, we have new execbuf3 ioctl which will not accept any
+ * execlist (See struct drm_i915_gem_execbuffer3 for more details).
+ *
+ */
+#define I915_VM_CREATE_FLAGS_USE_VM_BIND   (1 << 0)
+
+/**
+ * DOC: I915_CONTEXT_CREATE_FLAGS_LONG_RUNNING
+ *
+ * Flag to declare context as long running.
+ * See struct drm_i915_gem_context_create_ext flags.
+ *
+ * Usage of dma-fence expects that they complete in reasonable amount of time.
+ * Compute on the other hand can be long running. Hence it is not appropriate
+ * for compute contexts to export request completion dma-fence to user.
+ * The dma-fence usage will be limited to in-kernel consumption only.
+ * Compute contexts need to use user/memory fence.
+ *
+ * So, long running contexts do not support output fences. Hence,
+ * I915_EXEC_FENCE_SIGNAL (See &drm_i915_gem_exec_fence.flags) is expected
+ * to be not used. DRM_I915_GEM_WAIT ioctl call is also not supported for
+ * objects mapped to long running contexts.
+ */
+#define I915_CONTEXT_CREATE_FLAGS_LONG_RUNNING   (1u << 2)
+
+/* VM_BIND related ioctls */
+#define DRM_I915_GEM_VM_BIND   0x3d
+#define DRM_I915_GEM_VM_UNBIND 0x3e
+#define DRM_I915_GEM_EXECBUFFER3   0x3f
+#define DRM_I915_GEM_WAIT_USER_FENCE   0x40
+
+#define DRM_IOCTL_I915_GEM_VM_BIND DRM_IOWR(DRM_COMMAND_BASE + 
DRM_I915_GEM_VM_BIND, struct drm_i915_gem_vm_bind)
+#define DRM_IOCTL_I915_GEM_VM_UNBIND   DRM_IOWR(DRM_COMMAND_BASE + 
DRM_I915_GEM_VM_UNBIND, struct drm_i915_gem_vm_bind)
+#define DRM_IOCTL_I915_GEM_EXECBUFFER3 DRM_IOWR(DRM_COMMAND_BASE + 
DRM_I915_GEM_EXECBUFFER3, struct drm_i915_gem_execbuffer3)
+#define DRM_IOCTL_I915_GEM_WAIT_USER_FENCE DRM_IOWR(DRM_COMMAND_BASE + 
DRM_I915_GEM_WAIT_USER_FENCE, struct drm_i915_gem_wait_user_fence)
+
+/**
+ * struct drm_i915_gem_vm_bind - VA to object mapping to bind.
+ *
+ * This structure is passed to VM_BIND ioctl and specifies the mapping of GPU
+ * virtual address (VA) range to the section of an object that should be bound
+ * in the device page table of the specified address space (VM).
+ * The VA range specified must be unique (ie., not currently bound) and can
+ * be mapped to whole object or a section of the object (partial binding).
+ * Multiple VA mappings can be created to the same section of the object
+ * (aliasing).
+ *
+ * The @queue_idx specifies the queue to use for binding. Same queue can be
+ * used for both VM_BIND and VM_UNBIND calls. All submitted bind and unbind
+ * operations in a queue are performed in the order of submission.
+ *
+ * The @start, @offset and @length should be 4K page aligned. However the DG2
+ * and XEHPSDV has 64K page size for device local-memory and has compact page
+ * table. On those platforms, for binding device local-memory objects, the
+ * @start should be 2M aligned, @offset and @length should be 64K aligned.
+ * Also, on those platforms, it is not allowed to bind an device local-memory
+ * object and a system memory object in a single 2M section of VA range.
+ */
+struct drm_i915_gem_vm_bind {
+   /** @vm_id: VM (address space) id to bind */
+   __u32 vm_id;
+
+   /** @queue_idx: Index of queue for binding */
+   __u32 queue_idx;
+
+   /** @rsvd: Reserved, MBZ */
+   __u32 rsvd;
+
+   /** @handle: Object handle */
+   __u32 handle;
+
+   /** @start: Virtual Address start to bind */
+   __u64 start;
+
+   /** @offset: Offset in object to bind */
+   __u64 offset;
+
+   /** @length: Length of mapping to bind */
+   __u64 length;

This probably isn't needed. We are never going to unbind a subset of a
VMA are we? That 

Re: [PATCH 23/64] drm/vc4: dpi: Return an error if we can't enable our clock

[Dave Stevenson]

On Fri, 10 Jun 2022 at 10:30, Maxime Ripard  wrote:
>
> If we fail to enable the DPI clock, we just ignore the error and moves
> forward. Let's return an error instead.
>
> Signed-off-by: Maxime Ripard 

Reviewed-by: Dave Stevenson 

> ---
>  drivers/gpu/drm/vc4/vc4_dpi.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_dpi.c b/drivers/gpu/drm/vc4/vc4_dpi.c
> index d1eaafb43bd1..658e0aa9e2e1 100644
> --- a/drivers/gpu/drm/vc4/vc4_dpi.c
> +++ b/drivers/gpu/drm/vc4/vc4_dpi.c
> @@ -270,6 +270,7 @@ static int vc4_dpi_bind(struct device *dev, struct device 
> *master, void *data)
> DRM_ERROR("Failed to get core clock: %d\n", ret);
> return ret;
> }
> +
> dpi->pixel_clock = devm_clk_get(dev, "pixel");
> if (IS_ERR(dpi->pixel_clock)) {
> ret = PTR_ERR(dpi->pixel_clock);
> @@ -279,8 +280,10 @@ static int vc4_dpi_bind(struct device *dev, struct 
> device *master, void *data)
> }
>
> ret = clk_prepare_enable(dpi->core_clock);
> -   if (ret)
> +   if (ret) {
> DRM_ERROR("Failed to turn on core clock: %d\n", ret);
> +   return ret;
> +   }
>
> drm_simple_encoder_init(drm, &dpi->encoder.base, 
> DRM_MODE_ENCODER_DPI);
> drm_encoder_helper_add(&dpi->encoder.base, 
> &vc4_dpi_encoder_helper_funcs);
> --
> 2.36.1
>

Re: [Intel-gfx] [PATCH] drm/i915/guc: Check ctx while waiting for response

[Jani Nikula]

On Thu, 02 Jun 2022, Zhanjun Dong  wrote:
> We are seeing error message of "No response for request". Some cases happened
> while waiting for response and reset/suspend action was triggered. In this
> case, no response is not an error, active requests will be cancelled.
>
> This patch will handle this condition and change the error message into
> debug message.
>
> Signed-off-by: Zhanjun Dong 
> ---
>  drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 21 ++---
>  1 file changed, 14 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c 
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> index f01325cd1b62..a30a388877e2 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> @@ -467,7 +467,7 @@ static int ct_write(struct intel_guc_ct *ct,
>   * * 0 response received (status is valid)
>   * * -ETIMEDOUT no response within hardcoded timeout
>   */
> -static int wait_for_ct_request_update(struct ct_request *req, u32 *status)
> +static int wait_for_ct_request_update(struct ct_request *req, u32 *status, 
> struct intel_guc_ct *ct)
>  {
>   int err;
>  
> @@ -481,12 +481,14 @@ static int wait_for_ct_request_update(struct ct_request 
> *req, u32 *status)
>  #define GUC_CTB_RESPONSE_TIMEOUT_SHORT_MS 10
>  #define GUC_CTB_RESPONSE_TIMEOUT_LONG_MS 1000
>  #define done \
> - (FIELD_GET(GUC_HXG_MSG_0_ORIGIN, READ_ONCE(req->status)) == \
> + (!intel_guc_ct_enabled(ct) || FIELD_GET(GUC_HXG_MSG_0_ORIGIN, 
> READ_ONCE(req->status)) == \
>GUC_HXG_ORIGIN_GUC)
>   err = wait_for_us(done, GUC_CTB_RESPONSE_TIMEOUT_SHORT_MS);
>   if (err)
>   err = wait_for(done, GUC_CTB_RESPONSE_TIMEOUT_LONG_MS);
>  #undef done
> + if (!intel_guc_ct_enabled(ct))
> + err = -ECANCELED;
>  
>   *status = req->status;
>   return err;
> @@ -703,11 +705,15 @@ static int ct_send(struct intel_guc_ct *ct,
>  
>   intel_guc_notify(ct_to_guc(ct));
>  
> - err = wait_for_ct_request_update(&request, status);
> + err = wait_for_ct_request_update(&request, status, ct);
>   g2h_release_space(ct, GUC_CTB_HXG_MSG_MAX_LEN);
>   if (unlikely(err)) {
> - CT_ERROR(ct, "No response for request %#x (fence %u)\n",
> -  action[0], request.fence);
> + if (unlikely(err == ECANCELED))

I think you mean -ECANCELED, not ECANCELED.

Please drop the unlikely(). I no longer want to see a single unlikely()
or likely() added anywhere without proper performance
justification. They make the code harder to read, for no real benefit,
and people just cargo cult copy paste them everywhere. Moreover, nested
unlikely/likely is just silly.

> + CT_DEBUG(ct, "Request %#x (fence %u) cancelled as CTB 
> is disabled\n",
> + action[0], request.fence);
> + else
> + CT_ERROR(ct, "No response for request %#x (fence %u)\n",
> + action[0], request.fence);
>   goto unlink;
>   }
>  
> @@ -771,8 +777,9 @@ int intel_guc_ct_send(struct intel_guc_ct *ct, const u32 
> *action, u32 len,
>  
>   ret = ct_send(ct, action, len, response_buf, response_buf_size, 
> &status);
>   if (unlikely(ret < 0)) {
> - CT_ERROR(ct, "Sending action %#x failed (%pe) status=%#X\n",
> -  action[0], ERR_PTR(ret), status);
> + if (likely(ret != ECANCELED))

Ditto for -ECANCELED and likely().

BR,
Jani.

> + CT_ERROR(ct, "Sending action %#x failed (%pe) 
> status=%#X\n",
> + action[0], ERR_PTR(ret), status);
>   } else if (unlikely(ret)) {
>   CT_DEBUG(ct, "send action %#x returned %d (%#x)\n",
>action[0], ret, ret);

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [PATCH] drm/i915/guc: Check ctx while waiting for response

[Dixit, Ashutosh]

On Thu, 02 Jun 2022 10:21:19 -0700, Zhanjun Dong wrote:
>

Hi Zhanjun,

> We are seeing error message of "No response for request". Some cases happened
> while waiting for response and reset/suspend action was triggered. In this
> case, no response is not an error, active requests will be cancelled.
>
> This patch will handle this condition and change the error message into
> debug message.

IMO the patch title should be changed: which ctx are we checking while
waiting for response? Something like "check for ct enabled while waiting
for response"?

> @@ -481,12 +481,14 @@ static int wait_for_ct_request_update(struct ct_request 
> *req, u32 *status)
>  #define GUC_CTB_RESPONSE_TIMEOUT_SHORT_MS 10
>  #define GUC_CTB_RESPONSE_TIMEOUT_LONG_MS 1000
>  #define done \
> - (FIELD_GET(GUC_HXG_MSG_0_ORIGIN, READ_ONCE(req->status)) == \
> + (!intel_guc_ct_enabled(ct) || FIELD_GET(GUC_HXG_MSG_0_ORIGIN, 
> READ_ONCE(req->status)) == \
>GUC_HXG_ORIGIN_GUC)
>   err = wait_for_us(done, GUC_CTB_RESPONSE_TIMEOUT_SHORT_MS);
>   if (err)
>   err = wait_for(done, GUC_CTB_RESPONSE_TIMEOUT_LONG_MS);
>  #undef done
> + if (!intel_guc_ct_enabled(ct))
> + err = -ECANCELED;

Also, I really don't like intel_guc_ct_enabled() being called in two
places. Is there a possibility that intel_guc_ct_enabled() can return false
in the first place (causing the wait to exit) and then return true in the
second place (so we don't return -ECANCELED)?

Is it possible to change the status of the request to something else from
intel_guc_ct_disable() (or wherever ct->enabled is set to false) rather
than introducing intel_guc_ct_enabled() checks here. Changing the status of
the request when CT goes down would cause the wait's to exit here. And then
we can check that special request status signifying CT went down?

Thanks.
--
Ashutosh

Re: [PATCH] drm/msm/mdp4: Fix refcount leak in mdp4_modeset_init_intf

[Abhinav Kumar]

On 6/14/2022 3:09 AM, Dmitry Baryshkov wrote:

On 14/06/2022 13:07, Miaoqian Lin wrote:

Hi, Abhinav

On 2022/6/11 7:20, Abhinav Kumar wrote:



On 6/7/2022 4:08 AM, Miaoqian Lin wrote:

of_graph_get_remote_node() returns remote device node pointer with
refcount incremented, we should use of_node_put() on it
when not need anymore.
Add missing of_node_put() to avoid refcount leak.

Fixes: 86418f90a4c1 ("drm: convert drivers to use 
of_graph_get_remote_node")

Signed-off-by: Miaoqian Lin 
---
   drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c | 2 ++
   1 file changed, 2 insertions(+)



This patch itself looks fine and will cover the cases when there was 
an error and we did not release the refcount.


But, even in the normal cases I am not finding where we are releasing 
the refcount for the panel_node.


I dont see a of_node_put() on mdp4_lcdc_encoder->panel_node.


Thanks for your review.

I don't see it either. It's a bit messy because the reference assigned 
to mdp4_lcdc_encoder->panel_node and mdp4_lvds_connector->panel_node 
both.


I have a plan to rework mdp4 lcdc support once I get my ifc6410 lvds 
cable. Thus I think we can land this patch now and fix the mdp4 
lcdc/lvds code leaking the reference in the due time.




Alright, with that assurance,

Reviewed-by: Abhinav Kumar 

Will pick it up for -fixes.



Am i missing something?

diff --git a/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c 
b/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c

index fb48c8c19ec3..17cb1fc78379 100644
--- a/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
+++ b/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
@@ -216,6 +216,7 @@ static int mdp4_modeset_init_intf(struct 
mdp4_kms *mdp4_kms,

   encoder = mdp4_lcdc_encoder_init(dev, panel_node);
   if (IS_ERR(encoder)) {
   DRM_DEV_ERROR(dev->dev, "failed to construct LCDC 
encoder\n");

+    of_node_put(panel_node);
   return PTR_ERR(encoder);
   }
   @@ -225,6 +226,7 @@ static int mdp4_modeset_init_intf(struct 
mdp4_kms *mdp4_kms,
   connector = mdp4_lvds_connector_init(dev, panel_node, 
encoder);

   if (IS_ERR(connector)) {
   DRM_DEV_ERROR(dev->dev, "failed to initialize LVDS 
connector\n");

+    of_node_put(panel_node);
   return PTR_ERR(connector);
   }

Re: [PATCH 24/64] drm/vc4: dpi: Remove unnecessary drm_of_panel_bridge_remove call

[Dave Stevenson]

On Fri, 10 Jun 2022 at 10:30, Maxime Ripard  wrote:
>
> Since we have a managed call to create our panel_bridge instance, the call
> to drm_of_panel_bridge_remove() at unbind is both redundant and dangerous
> since it might lead to a use-after-free.
>
> Signed-off-by: Maxime Ripard 

Reviewed-by: Dave Stevenson 

> ---
>  drivers/gpu/drm/vc4/vc4_dpi.c | 2 --
>  1 file changed, 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_dpi.c b/drivers/gpu/drm/vc4/vc4_dpi.c
> index 658e0aa9e2e1..5a6cdea7bf7b 100644
> --- a/drivers/gpu/drm/vc4/vc4_dpi.c
> +++ b/drivers/gpu/drm/vc4/vc4_dpi.c
> @@ -309,8 +309,6 @@ static void vc4_dpi_unbind(struct device *dev, struct 
> device *master,
>  {
> struct vc4_dpi *dpi = dev_get_drvdata(dev);
>
> -   drm_of_panel_bridge_remove(dev->of_node, 0, 0);
> -
> drm_encoder_cleanup(&dpi->encoder.base);
>
> clk_disable_unprepare(dpi->core_clock);
> --
> 2.36.1
>

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

[Niranjana Vishwanathapura]

On Tue, Jun 14, 2022 at 05:07:37PM +0100, Tvrtko Ursulin wrote:


On 14/06/2022 17:02, Tvrtko Ursulin wrote:


On 14/06/2022 16:43, Niranjana Vishwanathapura wrote:

On Tue, Jun 14, 2022 at 08:16:41AM +0100, Tvrtko Ursulin wrote:


On 14/06/2022 00:39, Matthew Brost wrote:

On Mon, Jun 13, 2022 at 07:09:06PM +0100, Tvrtko Ursulin wrote:


On 13/06/2022 18:49, Niranjana Vishwanathapura wrote:

On Mon, Jun 13, 2022 at 05:22:02PM +0100, Tvrtko Ursulin wrote:


On 13/06/2022 16:05, Niranjana Vishwanathapura wrote:

On Mon, Jun 13, 2022 at 09:24:18AM +0100, Tvrtko Ursulin wrote:


On 10/06/2022 17:14, Niranjana Vishwanathapura wrote:
On Fri, Jun 10, 2022 at 05:48:39PM +0300, Lionel 
Landwerlin wrote:

On 10/06/2022 13:37, Tvrtko Ursulin wrote:


On 10/06/2022 08:07, Niranjana Vishwanathapura wrote:

VM_BIND and related uapi definitions

Signed-off-by: Niranjana Vishwanathapura

---
  Documentation/gpu/rfc/i915_vm_bind.h | 490
+++
  1 file changed, 490 insertions(+)
  create mode 100644 Documentation/gpu/rfc/i915_vm_bind.h

diff --git
a/Documentation/gpu/rfc/i915_vm_bind.h
b/Documentation/gpu/rfc/i915_vm_bind.h
new file mode 100644
index ..9fc854969cfb
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_vm_bind.h
@@ -0,0 +1,490 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+/**
+ * DOC: I915_PARAM_HAS_VM_BIND
+ *
+ * VM_BIND feature availability.
+ * See typedef drm_i915_getparam_t param.
+ * bit[0]: If set, VM_BIND is supported, otherwise not.
+ * bits[8-15]: VM_BIND implementation version.
+ * version 0 will not have VM_BIND/UNBIND
timeline fence array support.
+ */
+#define I915_PARAM_HAS_VM_BIND    57
+
+/**
+ * DOC: I915_VM_CREATE_FLAGS_USE_VM_BIND
+ *
+ * Flag to opt-in for VM_BIND mode of 
binding during VM creation.

+ * See struct drm_i915_gem_vm_control flags.
+ *
+ * The older execbuf2 ioctl will not
support VM_BIND mode of operation.
+ * For VM_BIND mode, we have new execbuf3
ioctl which will not accept any
+ * execlist (See struct
drm_i915_gem_execbuffer3 for more details).
+ *
+ */
+#define I915_VM_CREATE_FLAGS_USE_VM_BIND    (1 << 0)
+
+/**
+ * DOC: I915_CONTEXT_CREATE_FLAGS_LONG_RUNNING
+ *
+ * Flag to declare context as long running.
+ * See struct drm_i915_gem_context_create_ext flags.
+ *
+ * Usage of dma-fence expects that they
complete in reasonable amount of time.
+ * Compute on the other hand can be long
running. Hence it is not appropriate
+ * for compute contexts to export request
completion dma-fence to user.
+ * The dma-fence usage will be limited to
in-kernel consumption only.
+ * Compute contexts need to use user/memory fence.
+ *
+ * So, long running contexts do not support 
output fences. Hence,

+ * I915_EXEC_FENCE_SIGNAL (See
&drm_i915_gem_exec_fence.flags) is expected
+ * to be not used. DRM_I915_GEM_WAIT ioctl
call is also not supported for
+ * objects mapped to long running contexts.
+ */
+#define I915_CONTEXT_CREATE_FLAGS_LONG_RUNNING   (1u << 2)
+
+/* VM_BIND related ioctls */
+#define DRM_I915_GEM_VM_BIND    0x3d
+#define DRM_I915_GEM_VM_UNBIND    0x3e
+#define DRM_I915_GEM_EXECBUFFER3    0x3f
+#define DRM_I915_GEM_WAIT_USER_FENCE    0x40
+
+#define DRM_IOCTL_I915_GEM_VM_BIND
DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_VM_BIND, struct
drm_i915_gem_vm_bind)
+#define DRM_IOCTL_I915_GEM_VM_UNBIND
DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_VM_UNBIND, struct
drm_i915_gem_vm_bind)
+#define DRM_IOCTL_I915_GEM_EXECBUFFER3
DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_EXECBUFFER3, struct
drm_i915_gem_execbuffer3)
+#define DRM_IOCTL_I915_GEM_WAIT_USER_FENCE
DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_WAIT_USER_FENCE, struct
drm_i915_gem_wait_user_fence)
+
+/**
+ * struct drm_i915_gem_vm_bind - VA to 
object mapping to bind.

+ *
+ * This structure is passed to VM_BIND
ioctl and specifies the mapping of GPU
+ * virtual address (VA) range to the
section of an object that should be bound
+ * in the device page table of the 
specified address space (VM).

+ * The VA range specified must be unique
(ie., not currently bound) and can
+ * be mapped to whole object or a section
of the object (partial binding).
+ * Multiple VA mappings can be created to
the same section of the object
+ * (aliasing).
+ *
+ * The @queue_idx specifies the queue to
use for binding. Same queue can be
+ * used for both VM_BIND and VM_UNBIND
calls. All submitted bind and unbind
+ * operations in a queue are performed in 
the order of submission.

+ *
+ * The @start, @offset and @length should
be 4K page aligned. However the DG2
+ * and XEHPSDV has 64K page size for device
local-memory and has compact page
+ * table. On those platforms, for binding
device local-memory objects, the
+ * @start should be 2M aligned, @offset and
@length should be 64K aligned.
+ * Also, on those platforms, it is not
allowed to bind an device local-memory
+ * object and a system memory object in a
single 2M section of VA range.
+ */
+struct drm_i915_gem_vm_bind {
+   

Re: [PATCH 25/64] drm/vc4: dpi: Add action to disable the clock

[Dave Stevenson]

Hi Maxime.

On Fri, 10 Jun 2022 at 10:30, Maxime Ripard  wrote:
>
> Adding a device-managed action will make the error path easier, so let's
> create one to disable our clock.

The DPI block has two clocks (core and pixel), and this is only
affecting one of them (the core clock).
(I'm actually puzzling over what it's wanting to do with the core
clock here as it's only enabling it rather than setting a rate. I
think it may be redundant).

With that text amended:
Reviewed-by: Dave Stevenson 

  Dave

> Signed-off-by: Maxime Ripard 
> ---
>  drivers/gpu/drm/vc4/vc4_dpi.c | 14 +++---
>  1 file changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_dpi.c b/drivers/gpu/drm/vc4/vc4_dpi.c
> index 5a6cdea7bf7b..4e24dbad77f2 100644
> --- a/drivers/gpu/drm/vc4/vc4_dpi.c
> +++ b/drivers/gpu/drm/vc4/vc4_dpi.c
> @@ -237,6 +237,13 @@ static int vc4_dpi_init_bridge(struct vc4_dpi *dpi)
> return drm_bridge_attach(&dpi->encoder.base, bridge, NULL, 0);
>  }
>
> +static void vc4_dpi_disable_clock(void *ptr)
> +{
> +   struct vc4_dpi *dpi = ptr;
> +
> +   clk_disable_unprepare(dpi->core_clock);
> +}
> +
>  static int vc4_dpi_bind(struct device *dev, struct device *master, void 
> *data)
>  {
> struct platform_device *pdev = to_platform_device(dev);
> @@ -285,6 +292,10 @@ static int vc4_dpi_bind(struct device *dev, struct 
> device *master, void *data)
> return ret;
> }
>
> +   ret = devm_add_action_or_reset(dev, vc4_dpi_disable_clock, dpi);
> +   if (ret)
> +   return ret;
> +
> drm_simple_encoder_init(drm, &dpi->encoder.base, 
> DRM_MODE_ENCODER_DPI);
> drm_encoder_helper_add(&dpi->encoder.base, 
> &vc4_dpi_encoder_helper_funcs);
>
> @@ -300,7 +311,6 @@ static int vc4_dpi_bind(struct device *dev, struct device 
> *master, void *data)
>
>  err_destroy_encoder:
> drm_encoder_cleanup(&dpi->encoder.base);
> -   clk_disable_unprepare(dpi->core_clock);
> return ret;
>  }
>
> @@ -310,8 +320,6 @@ static void vc4_dpi_unbind(struct device *dev, struct 
> device *master,
> struct vc4_dpi *dpi = dev_get_drvdata(dev);
>
> drm_encoder_cleanup(&dpi->encoder.base);
> -
> -   clk_disable_unprepare(dpi->core_clock);
>  }
>
>  static const struct component_ops vc4_dpi_ops = {
> --
> 2.36.1
>

Re: [PATCH 26/64] drm/vc4: dpi: Switch to DRM-managed encoder initialization

[Dave Stevenson]

On Fri, 10 Jun 2022 at 10:30, Maxime Ripard  wrote:
>
> The current code will call drm_encoder_cleanup() when the device is
> unbound. However, by then, there might still be some references held to
> that encoder, including by the userspace that might still have the DRM
> device open.
>
> Let's switch to a DRM-managed initialization to clean up after ourselves
> only once the DRM device has been last closed.
>
> Signed-off-by: Maxime Ripard 

Reviewed-by: Dave Stevenson 

> ---
>  drivers/gpu/drm/vc4/vc4_dpi.c | 20 +---
>  1 file changed, 5 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_dpi.c b/drivers/gpu/drm/vc4/vc4_dpi.c
> index 4e24dbad77f2..8a50de2c40d9 100644
> --- a/drivers/gpu/drm/vc4/vc4_dpi.c
> +++ b/drivers/gpu/drm/vc4/vc4_dpi.c
> @@ -296,35 +296,25 @@ static int vc4_dpi_bind(struct device *dev, struct 
> device *master, void *data)
> if (ret)
> return ret;
>
> -   drm_simple_encoder_init(drm, &dpi->encoder.base, 
> DRM_MODE_ENCODER_DPI);
> +   ret = drmm_simple_encoder_init(drm, &dpi->encoder.base, 
> DRM_MODE_ENCODER_DPI);
> +   if (ret)
> +   return ret;
> +
> drm_encoder_helper_add(&dpi->encoder.base, 
> &vc4_dpi_encoder_helper_funcs);
>
> ret = vc4_dpi_init_bridge(dpi);
> if (ret)
> -   goto err_destroy_encoder;
> +   return ret;
>
> dev_set_drvdata(dev, dpi);
>
> vc4_debugfs_add_regset32(drm, "dpi_regs", &dpi->regset);
>
> return 0;
> -
> -err_destroy_encoder:
> -   drm_encoder_cleanup(&dpi->encoder.base);
> -   return ret;
> -}
> -
> -static void vc4_dpi_unbind(struct device *dev, struct device *master,
> -  void *data)
> -{
> -   struct vc4_dpi *dpi = dev_get_drvdata(dev);
> -
> -   drm_encoder_cleanup(&dpi->encoder.base);
>  }
>
>  static const struct component_ops vc4_dpi_ops = {
> .bind   = vc4_dpi_bind,
> -   .unbind = vc4_dpi_unbind,
>  };
>
>  static int vc4_dpi_dev_probe(struct platform_device *pdev)
> --
> 2.36.1
>

Re: [PATCH 27/64] drm/vc4: dpi: Switch to drmm_of_get_bridge

[Dave Stevenson]

On Fri, 10 Jun 2022 at 10:30, Maxime Ripard  wrote:
>
> The current code uses a device-managed function to retrieve the next bridge
> downstream.
>
> However, that means that it will be removed at unbind time, where the DRM
> device is still very much live and might still have some applications that
> still have it open.
>
> Switch to a DRM-managed variant to clean everything up once the DRM device
> has been last closed.
>
> Signed-off-by: Maxime Ripard 

Reviewed-by: Dave Stevenson 

> ---
>  drivers/gpu/drm/vc4/vc4_dpi.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_dpi.c b/drivers/gpu/drm/vc4/vc4_dpi.c
> index 8a50de2c40d9..9950761449cf 100644
> --- a/drivers/gpu/drm/vc4/vc4_dpi.c
> +++ b/drivers/gpu/drm/vc4/vc4_dpi.c
> @@ -220,10 +220,11 @@ static const struct of_device_id vc4_dpi_dt_match[] = {
>   */
>  static int vc4_dpi_init_bridge(struct vc4_dpi *dpi)
>  {
> +   struct drm_device *drm = dpi->encoder.base.dev;
> struct device *dev = &dpi->pdev->dev;
> struct drm_bridge *bridge;
>
> -   bridge = devm_drm_of_get_bridge(dev, dev->of_node, 0, 0);
> +   bridge = drmm_of_get_bridge(drm, dev->of_node, 0, 0);
> if (IS_ERR(bridge)) {
> /* If nothing was connected in the DT, that's not an
>  * error.
> --
> 2.36.1
>

Re: [PATCH 28/64] drm/vc4: dpi: Protect device resources

[Dave Stevenson]

On Fri, 10 Jun 2022 at 10:30, Maxime Ripard  wrote:
>
> Our current code now mixes some resources whose lifetime are tied to the
> device (clocks, IO mappings, etc.) and some that are tied to the DRM device
> (encoder, bridge).
>
> The device one will be freed at unbind time, but the DRM one will only be
> freed when the last user of the DRM device closes its file handle.
>
> So we end up with a time window during which we can call the encoder hooks,
> but we don't have access to the underlying resources and device.
>
> Let's protect all those sections with drm_dev_enter() and drm_dev_exit() so
> that we bail out if we are during that window.
>
> Signed-off-by: Maxime Ripard 

Reviewed-by: Dave Stevenson 

> ---
>  drivers/gpu/drm/vc4/vc4_dpi.c | 14 ++
>  1 file changed, 14 insertions(+)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_dpi.c b/drivers/gpu/drm/vc4/vc4_dpi.c
> index 9950761449cf..ea3d20651f43 100644
> --- a/drivers/gpu/drm/vc4/vc4_dpi.c
> +++ b/drivers/gpu/drm/vc4/vc4_dpi.c
> @@ -13,6 +13,7 @@
>
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -111,9 +112,16 @@ static const struct debugfs_reg32 dpi_regs[] = {
>
>  static void vc4_dpi_encoder_disable(struct drm_encoder *encoder)
>  {
> +   struct drm_device *dev = encoder->dev;
> struct vc4_dpi *dpi = to_vc4_dpi(encoder);
> +   int idx;
> +
> +   if (!drm_dev_enter(dev, &idx))
> +   return;
>
> clk_disable_unprepare(dpi->pixel_clock);
> +
> +   drm_dev_exit(idx);
>  }
>
>  static void vc4_dpi_encoder_enable(struct drm_encoder *encoder)
> @@ -124,6 +132,7 @@ static void vc4_dpi_encoder_enable(struct drm_encoder 
> *encoder)
> struct drm_connector_list_iter conn_iter;
> struct drm_connector *connector = NULL, *connector_scan;
> u32 dpi_c = DPI_ENABLE | DPI_OUTPUT_ENABLE_MODE;
> +   int idx;
> int ret;
>
> /* Look up the connector attached to DPI so we can get the
> @@ -184,6 +193,9 @@ static void vc4_dpi_encoder_enable(struct drm_encoder 
> *encoder)
> else if (!(mode->flags & DRM_MODE_FLAG_PVSYNC))
> dpi_c |= DPI_VSYNC_DISABLE;
>
> +   if (!drm_dev_enter(dev, &idx))
> +   return;
> +
> DPI_WRITE(DPI_C, dpi_c);
>
> ret = clk_set_rate(dpi->pixel_clock, mode->clock * 1000);
> @@ -193,6 +205,8 @@ static void vc4_dpi_encoder_enable(struct drm_encoder 
> *encoder)
> ret = clk_prepare_enable(dpi->pixel_clock);
> if (ret)
> DRM_ERROR("Failed to set clock rate: %d\n", ret);
> +
> +   drm_dev_exit(idx);
>  }
>
>  static enum drm_mode_status vc4_dpi_encoder_mode_valid(struct drm_encoder 
> *encoder,
> --
> 2.36.1
>

Re: [PATCH v2 6/7] drm/bridge: anx7625: Register Type-C mode switches

[Prashant Malani]

On Tue, Jun 14, 2022 at 1:18 AM AngeloGioacchino Del Regno
 wrote:
>
> Il 09/06/22 20:09, Prashant Malani ha scritto:
> > When the DT node has "switches" available, register a Type-C mode-switch
> > for each listed "switch". This allows the driver to receive state
> > information about what operating mode a Type-C port and its connected
> > peripherals are in, as well as status information (like VDOs) related to
> > that state.
> >
> > The callback function is currently a stub, but subsequent patches will
> > implement the required functionality.
> >
> > Signed-off-by: Prashant Malani 
> > ---
> >
> > Changes since v2:
> > - No changes.
> >
> >   drivers/gpu/drm/bridge/analogix/anx7625.c | 73 +++
> >   drivers/gpu/drm/bridge/analogix/anx7625.h |  6 ++
> >   2 files changed, 79 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c 
> > b/drivers/gpu/drm/bridge/analogix/anx7625.c
> > index 07ed44c6b839..d41a21103bd3 100644
> > --- a/drivers/gpu/drm/bridge/analogix/anx7625.c
> > +++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
> > @@ -15,6 +15,7 @@
> >   #include 
> >   #include 
> >   #include 
> > +#include 
> >   #include 
> >
> >   #include 
> > @@ -2581,9 +2582,59 @@ static void anx7625_runtime_disable(void *data)
> >   pm_runtime_disable(data);
> >   }
> >
> > +static int anx7625_typec_mux_set(struct typec_mux_dev *mux,
> > +  struct typec_mux_state *state)
> > +{
> > + return 0;
> > +}
> > +
> > +static int anx7625_register_mode_switch(struct device *dev, struct 
> > device_node *node,
> > + struct anx7625_data *ctx)
> > +{
> > + struct anx7625_port_data *port_data;
> > + struct typec_mux_desc mux_desc = {};
> > + char name[32];
> > + u32 port_num;
> > + int ret;
> > +
> > + ret = of_property_read_u32(node, "reg", &port_num);
> > + if (ret)
> > + return ret;
> > +
> > + if (port_num >= ctx->num_typec_switches) {
> > + dev_err(dev, "Invalid port number specified: %d\n", port_num);
> > + return -EINVAL;
> > + }
> > +
> > + port_data = &ctx->typec_ports[port_num];
> > + port_data->ctx = ctx;
> > + mux_desc.fwnode = &node->fwnode;
> > + mux_desc.drvdata = port_data;
> > + snprintf(name, sizeof(name), "%s-%u", node->name, port_num);
> > + mux_desc.name = name;
> > + mux_desc.set = anx7625_typec_mux_set;
> > +
> > + port_data->typec_mux = typec_mux_register(dev, &mux_desc);
> > + if (IS_ERR(port_data->typec_mux)) {
> > + ret = PTR_ERR(port_data->typec_mux);
> > + dev_err(dev, "Mode switch register for port %d failed: %d", 
> > port_num, ret);
> > + }
>
> Please return 0 at the end of this function.
>
> if (IS_ERR()) {
> ..code..
> return ret;
> }
>
> return 0;
> }

May I ask why? We're not missing any return paths. I would rather we
keep it as is (which has the valid return value).

>
> > +
> > + return ret;
> > +}
> > +
> > +static void anx7625_unregister_typec_switches(struct anx7625_data *ctx)
> > +{
> > + int i;
> > +
> > + for (i = 0; i < ctx->num_typec_switches; i++)
> > + typec_mux_unregister(ctx->typec_ports[i].typec_mux);
> > +}
> > +
> >   static int anx7625_register_typec_switches(struct device *device, struct 
> > anx7625_data *ctx)
> >   {
> >   struct device_node *of = NULL;
> > + struct device_node *sw;
> >   int ret = 0;
> >
> >   of = of_get_child_by_name(device->of_node, "switches");
> > @@ -2594,6 +2645,26 @@ static int anx7625_register_typec_switches(struct 
> > device *device, struct anx7625
> >   if (ctx->num_typec_switches <= 0)
> >   return -ENODEV;
> >
> > + ctx->typec_ports = devm_kzalloc(device,
> > + ctx->num_typec_switches * 
> > sizeof(struct anx7625_port_data),
> > + GFP_KERNEL);
> > + if (!ctx->typec_ports)
> > + return -ENOMEM;
> > +
> > + /* Register switches for each connector. */
> > + for_each_available_child_of_node(of, sw) {
> > + if (!of_property_read_bool(sw, "mode-switch"))
> > + continue;
> > + ret = anx7625_register_mode_switch(device, sw, ctx);
> > + if (ret) {
> > + dev_err(device, "Failed to register mode switch: 
> > %d\n", ret);
> > + break;
> > + }
> > + }
> > +
> > + if (ret)
> > + anx7625_unregister_typec_switches(ctx);
> > +
> >   return ret;
> >   }
> >
> > @@ -2759,6 +2830,8 @@ static int anx7625_i2c_remove(struct i2c_client 
> > *client)
> >
> >   drm_bridge_remove(&platform->bridge);
> >
> > + anx7625_unregister_typec_switches(platform);
> > +
> >   if (platform->pdata.intp_irq)
> >   destroy_workqueue(platform->workqueue);
> >
> > di

Re: [PATCH v2 7/7] drm/bridge: anx7625: Add typec_mux_set callback function

[Prashant Malani]

On Tue, Jun 14, 2022 at 2:08 AM Pin-yen Lin  wrote:
>
> Hi AngeloGioacchino,
>
>
> On Tue, Jun 14, 2022 at 4:15 PM AngeloGioacchino Del Regno
>  wrote:
> >
> > Il 09/06/22 20:09, Prashant Malani ha scritto:
> > > From: Pin-Yen Lin 
> > >
> > > Add the callback function when the driver receives state
> > > changes of the Type-C port. The callback function configures the
> > > crosspoint switch of the anx7625 bridge chip, which can change the
> > > output pins of the signals according to the port state.
> > >
> > > Signed-off-by: Pin-Yen Lin 
> > > Signed-off-by: Prashant Malani 
> > > ---
> > >
> > > Changes since v2:
> > > - No changes.
> > >
> > >   drivers/gpu/drm/bridge/analogix/anx7625.c | 58 +++
> > >   drivers/gpu/drm/bridge/analogix/anx7625.h | 13 +
> > >   2 files changed, 71 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c 
> > > b/drivers/gpu/drm/bridge/analogix/anx7625.c
> > > index d41a21103bd3..2c308d12fab2 100644
> > > --- a/drivers/gpu/drm/bridge/analogix/anx7625.c
> > > +++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
> > > @@ -15,6 +15,7 @@
> > >   #include 
> > >   #include 
> > >   #include 
> > > +#include 
> > >   #include 
> > >   #include 
> > >
> > > @@ -2582,9 +2583,66 @@ static void anx7625_runtime_disable(void *data)
> > >   pm_runtime_disable(data);
> > >   }
> > >
> > > +static void anx7625_set_crosspoint_switch(struct anx7625_data *ctx,
> > > +   enum typec_orientation 
> > > orientation)
> > > +{
> > > + if (orientation == TYPEC_ORIENTATION_NORMAL) {
> > > + anx7625_reg_write(ctx, ctx->i2c.tcpc_client, TCPC_SWITCH_0,
> > > +   SW_SEL1_SSRX_RX1 | SW_SEL1_DPTX0_RX2);
> > > + anx7625_reg_write(ctx, ctx->i2c.tcpc_client, TCPC_SWITCH_1,
> > > +   SW_SEL2_SSTX_TX1 | SW_SEL2_DPTX1_TX2);
> > > + } else if (orientation == TYPEC_ORIENTATION_REVERSE) {
> > > + anx7625_reg_write(ctx, ctx->i2c.tcpc_client, TCPC_SWITCH_0,
> > > +   SW_SEL1_SSRX_RX2 | SW_SEL1_DPTX0_RX1);
> > > + anx7625_reg_write(ctx, ctx->i2c.tcpc_client, TCPC_SWITCH_1,
> > > +   SW_SEL2_SSTX_TX2 | SW_SEL2_DPTX1_TX1);
> > > + }
> > > +}
> > > +
> > > +static void anx7625_typec_two_ports_update(struct anx7625_data *ctx)
> > > +{
> > > + if (ctx->typec_ports[0].dp_connected && 
> > > ctx->typec_ports[1].dp_connected)
> > > + /* Both ports available, do nothing to retain the current 
> > > one. */
> > > + return;
> > > + else if (ctx->typec_ports[0].dp_connected)
> > > + anx7625_set_crosspoint_switch(ctx, 
> > > TYPEC_ORIENTATION_NORMAL);
> > > + else if (ctx->typec_ports[1].dp_connected)
> > > + anx7625_set_crosspoint_switch(ctx, 
> > > TYPEC_ORIENTATION_REVERSE);
> > > +}
> > > +
> > >   static int anx7625_typec_mux_set(struct typec_mux_dev *mux,
> > >struct typec_mux_state *state)
> > >   {
> > > + struct anx7625_port_data *data = typec_mux_get_drvdata(mux);
> > > + struct anx7625_data *ctx = data->ctx;
> > > + struct device *dev = &ctx->client->dev;
> > > +
> > > + bool old_dp_connected = (ctx->typec_ports[0].dp_connected ||
> > > +  ctx->typec_ports[1].dp_connected);
> >
> > So the old connection state is "either port0 or port1 are currently 
> > connected"...
> >
> > > + bool new_dp_connected;
> > > +
> > > + if (ctx->num_typec_switches == 1)
> > > + return 0;
> > > +
> > > + dev_dbg(dev, "mux_set dp_connected: c0=%d, c1=%d\n",
> > > + ctx->typec_ports[0].dp_connected, 
> > > ctx->typec_ports[1].dp_connected);
> > > +
> > > + data->dp_connected = (state->alt && state->alt->svid == 
> > > USB_TYPEC_DP_SID &&
> > > +   state->alt->mode == USB_TYPEC_DP_MODE);
> > > + > + new_dp_connected = (ctx->typec_ports[0].dp_connected ||
> > > + ctx->typec_ports[1].dp_connected);
> >
> > ...and the new connection state is the same as the old one, because I don't 
> > see
> > anything that could ever modify it in this function's flow, until reaching 
> > this
> > assignment.
>
> The typec mux driver data (`struct anx7625_port_data *data =
> typec_mux_get_drvdata(mux)`) is set to one of the
> `ctx->typec_ports[*]` in `anx7625_register_mode_switch` (see patch 6
> of this series).
>
> So, the `data->dp_connected = ...` assignment may change the new
> connection state.

Angelo, I think your interpretation of this logic is not accurate..
|old_dp_connected| represents *whether* port1 or port0 has a DP
partner connected, not that *either* of them has it.

So, this logic looks OK to me.


>
> Best regards,
> Pin-yen
>
> >
> > > +
> > > + /* dp on, power on first */
> > > + if (!old_dp_connected && new_dp_connected)
> > > + pm_runtime_get_sync

Re: [PATCH 13/64] drm/vc4: hvs: Protect device resources after removal

[Dave Stevenson]

On Tue, 14 Jun 2022 at 16:11, Dave Stevenson
 wrote:
>
> Hi Maxime
>
> On Fri, 10 Jun 2022 at 10:30, Maxime Ripard  wrote:
> >
> > Whenever the device and driver are unbound, the main device and all the
> > subdevices will be removed by calling their unbind() method.
> >
> > However, the DRM device itself will only be freed when the last user will
> > have closed it.
> >
> > It means that there is a time window where the device and its resources
> > aren't there anymore, but the userspace can still call into our driver.
> >
> > Fortunately, the DRM framework provides the drm_dev_enter() and
> > drm_dev_exit() functions to make sure our underlying device is still there
> > for the section protected by those calls. Let's add them to the HVS driver.
>
> The framework appears to rely on the remove function calling
> drm_dev_unplug instead of drm_dev_unregister, but I haven't seen a
> patch that makes that change in the vc4 driver.
> Have I missed it, or is there some other route to set the unplugged
> flag that drm_dev_enter/exit are relying on?
>
>   Dave
>
> > Signed-off-by: Maxime Ripard 
> > ---
> >  drivers/gpu/drm/vc4/vc4_drv.h |   1 +
> >  drivers/gpu/drm/vc4/vc4_hvs.c | 106 +++---
> >  2 files changed, 99 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
> > index aa4c5910ea05..080deae55f64 100644
> > --- a/drivers/gpu/drm/vc4/vc4_drv.h
> > +++ b/drivers/gpu/drm/vc4/vc4_drv.h
> > @@ -317,6 +317,7 @@ struct vc4_v3d {
> >  };
> >
> >  struct vc4_hvs {
> > +   struct drm_device *dev;
> > struct platform_device *pdev;
> > void __iomem *regs;
> > u32 __iomem *dlist;
> > diff --git a/drivers/gpu/drm/vc4/vc4_hvs.c b/drivers/gpu/drm/vc4/vc4_hvs.c
> > index 2a58fc421cf6..483053e7b14f 100644
> > --- a/drivers/gpu/drm/vc4/vc4_hvs.c
> > +++ b/drivers/gpu/drm/vc4/vc4_hvs.c
> > @@ -25,6 +25,7 @@
> >  #include 
> >
> >  #include 
> > +#include 
> >  #include 
> >
> >  #include "vc4_drv.h"
> > @@ -66,11 +67,15 @@ static const struct debugfs_reg32 hvs_regs[] = {
> >
> >  void vc4_hvs_dump_state(struct vc4_hvs *hvs)
> >  {
> > +   struct drm_device *drm = hvs->dev;
> > struct drm_printer p = drm_info_printer(&hvs->pdev->dev);
> > -   int i;
> > +   int idx, i;
> >
> > drm_print_regset32(&p, &hvs->regset);
> >
> > +   if (!drm_dev_enter(drm, &idx))
> > +   return;
> > +
> > DRM_INFO("HVS ctx:\n");
> > for (i = 0; i < 64; i += 4) {
> > DRM_INFO("0x%08x (%s): 0x%08x 0x%08x 0x%08x 0x%08x\n",
> > @@ -80,6 +85,8 @@ void vc4_hvs_dump_state(struct vc4_hvs *hvs)
> >  readl((u32 __iomem *)hvs->dlist + i + 2),
> >  readl((u32 __iomem *)hvs->dlist + i + 3));
> > }
> > +
> > +   drm_dev_exit(idx);
> >  }
> >
> >  static int vc4_hvs_debugfs_underrun(struct seq_file *m, void *data)
> > @@ -132,14 +139,18 @@ static int vc4_hvs_upload_linear_kernel(struct 
> > vc4_hvs *hvs,
> > struct drm_mm_node *space,
> > const u32 *kernel)
> >  {
> > -   int ret, i;
> > +   struct drm_device *drm = hvs->dev;
> > +   int idx, ret, i;
> > u32 __iomem *dst_kernel;
> >
> > +   if (!drm_dev_enter(drm, &idx))
> > +   return -ENODEV;
> > +

vc4_hvs_upload_linear_kernel is only called from vc4_hvs_bind, so
unless bind and unbind calls can be concurrent, then there's no need
for protection here.

> > ret = drm_mm_insert_node(&hvs->dlist_mm, space, VC4_KERNEL_DWORDS);
> > if (ret) {
> > DRM_ERROR("Failed to allocate space for filter kernel: 
> > %d\n",
> >   ret);
> > -   return ret;
> > +   goto err_dev_exit;
> > }
> >
> > dst_kernel = hvs->dlist + space->start;
> > @@ -153,16 +164,26 @@ static int vc4_hvs_upload_linear_kernel(struct 
> > vc4_hvs *hvs,
> > }
> > }
> >
> > +   drm_dev_exit(idx);
> > return 0;
> > +
> > +err_dev_exit:
> > +   drm_dev_exit(idx);
> > +   return ret;
> >  }
> >
> >  static void vc4_hvs_lut_load(struct vc4_hvs *hvs,
> >  struct vc4_crtc *vc4_crtc)
> >  {
> > +   struct drm_device *drm = hvs->dev;
> > struct drm_crtc *crtc = &vc4_crtc->base;
> > struct vc4_crtc_state *vc4_state = to_vc4_crtc_state(crtc->state);
> > +   int idx;
> > u32 i;
> >
> > +   if (!drm_dev_enter(drm, &idx))
> > +   return;
> > +
> > /* The LUT memory is laid out with each HVS channel in order,
> >  * each of which takes 256 writes for R, 256 for G, then 256
> >  * for B.
> > @@ -177,6 +198,8 @@ static void vc4_hvs_lut_load(struct vc4_hvs *hvs,
> > HVS_WRITE(SCALER_GAMDATA, vc4_crtc->lut_g[i]);
> > for (i = 0; i < crtc->gamma_size; i++)