Re: [PATCH v2 05/17] drm/msm/dpu: add reset_intf_cfg operation for dpu_hw_ctl

[Dmitry Baryshkov]

On 20/04/2022 04:45, Abhinav Kumar wrote:

Add a reset_intf_cfg operation for dpu_hw_ctl to reset the
entire CTL path by disabling each component namely layer mixer,
3d-merge and interface blocks.

Signed-off-by: Abhinav Kumar 


Reviewed-by: Dmitry Baryshkov 


---
  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 32 ++
  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h |  8 
  2 files changed, 40 insertions(+)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
index dc27579..524f024 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
@@ -563,6 +563,37 @@ static void dpu_hw_ctl_intf_cfg(struct dpu_hw_ctl *ctx,
DPU_REG_WRITE(c, CTL_TOP, intf_cfg);
  }
  
+static void dpu_hw_ctl_reset_intf_cfg_v1(struct dpu_hw_ctl *ctx,

+   struct dpu_hw_intf_cfg *cfg)
+{
+   struct dpu_hw_blk_reg_map *c = &ctx->hw;
+   u32 intf_active = 0;
+   u32 merge3d_active = 0;
+
+   /*
+* This API resets each portion of the CTL path namely,
+* clearing the sspps staged on the lm, merge_3d block,
+* interfaces etc to ensure clean teardown of the pipeline.
+* This will be used for writeback to begin with to have a
+* proper teardown of the writeback session but upon further
+* validation, this can be extended to all interfaces.
+*/
+   if (cfg->merge_3d) {
+   merge3d_active = DPU_REG_READ(c, CTL_MERGE_3D_ACTIVE);
+   merge3d_active &= ~BIT(cfg->merge_3d - MERGE_3D_0);
+   DPU_REG_WRITE(c, CTL_MERGE_3D_ACTIVE,
+   merge3d_active);
+   }
+
+   dpu_hw_ctl_clear_all_blendstages(ctx);
+
+   if (cfg->intf) {
+   intf_active = DPU_REG_READ(c, CTL_INTF_ACTIVE);
+   intf_active &= ~BIT(cfg->intf - INTF_0);
+   DPU_REG_WRITE(c, CTL_INTF_ACTIVE, intf_active);
+   }
+}
+
  static void dpu_hw_ctl_set_fetch_pipe_active(struct dpu_hw_ctl *ctx,
unsigned long *fetch_active)
  {
@@ -586,6 +617,7 @@ static void _setup_ctl_ops(struct dpu_hw_ctl_ops *ops,
if (cap & BIT(DPU_CTL_ACTIVE_CFG)) {
ops->trigger_flush = dpu_hw_ctl_trigger_flush_v1;
ops->setup_intf_cfg = dpu_hw_ctl_intf_cfg_v1;
+   ops->reset_intf_cfg = dpu_hw_ctl_reset_intf_cfg_v1;
ops->update_pending_flush_intf =
dpu_hw_ctl_update_pending_flush_intf_v1;
ops->update_pending_flush_merge_3d =
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h
index 97f326d..c61a8fd 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h
@@ -140,6 +140,14 @@ struct dpu_hw_ctl_ops {
void (*setup_intf_cfg)(struct dpu_hw_ctl *ctx,
struct dpu_hw_intf_cfg *cfg);
  
+	/**

+* reset ctl_path interface config
+* @ctx: ctl path ctx pointer
+* @cfg: interface config structure pointer
+*/
+   void (*reset_intf_cfg)(struct dpu_hw_ctl *ctx,
+   struct dpu_hw_intf_cfg *cfg);
+
int (*reset)(struct dpu_hw_ctl *c);
  
  	/*



--
With best wishes
Dmitry

Re: [PATCH 1/2] dt-bindings: display: ti,am65x-dss: Add missing register & interrupt

[Tomi Valkeinen]

Hi,

On 19/04/2022 17:20, Rob Herring wrote:

On Tue, Apr 19, 2022 at 12:33:01PM +0530, Aradhya Bhatia wrote:

The DSS IP on the ti-am65x soc supports an additional register space,
named "common1". Further. the IP services a maximum number of 2
interrupts.

Add the missing register space "common1" and the additional interrupt.

Signed-off-by: Aradhya Bhatia 
---
  .../devicetree/bindings/display/ti/ti,am65x-dss.yaml   | 10 +++---
  1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml 
b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
index 5c7d2cbc4aac..102059e9e0d5 100644
--- a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
+++ b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
@@ -26,6 +26,7 @@ properties:
Addresses to each DSS memory region described in the SoC's TRM.
  items:
- description: common DSS register area
+  - description: common1 DSS register area


You've just broken the ABI.

New entries have to go on the end.


I'm curious, if the 'reg-names' is a required property, as it is here, 
does this still break the ABI?


 Tomi

Re: refactor the i915 GVT support and move to the modern mdev API v3

[Wang, Zhi A]

On 4/20/22 7:08 AM, Christoph Hellwig wrote:
> On Thu, Apr 14, 2022 at 11:38:59AM -0300, Jason Gunthorpe wrote:
>> pull requests can flow through more than one tree concurrently. The
>> purpose of the topic branch is to allow all the commits to be in all
>> the trees they need to be in at once.
>>
>> So you should send this branch as a PR to the next logical upstream
>> tree gvt patches normally go through, in the usual way that you send
>> PRs. Especially in this case where there is a small merge conflict
>> internal to DRM to resolve. I'm assuming this is the drm-intel-next
>> tree?
>>
>> Once DRM is internally happy then VFIO can merge it as well. You can
>> view VFIO as the secondary path to Linus, DRM as primary. Alex will
>> mention in his pull request that VFIO has a 'shared branch with DRM
>> for gvt'.
> 
> Where do we stand here?  The (somewhat misnamed) topic/for-christoph
> branch looks fine to me now except for the mіssing "static inline" on
> the intel_gvt_iterate_mmio_table stub.
> 
> When can we expect it in the i915 tree and linux-next?
> 
Qur QA finished the test yesterday and I just made a tag. The pull
request is going to be sent today. Yes, I will fix that.

Thanks,
Zhi.

Re: [PATCH v2 06/17] drm/msm/dpu: add dpu_hw_wb abstraction for writeback blocks

[Dmitry Baryshkov]

On 20/04/2022 04:45, Abhinav Kumar wrote:

Add the dpu_hw_wb abstraction to program registers related to the
writeback block. These will be invoked once all the configuration
is set and ready to be programmed to the registers.

changes in v2:
- remove multiple empty lines at the end of the file
- change dpu_hw_wb_bind_pingpong_blk to preserve upper bits

Signed-off-by: Abhinav Kumar 
Reviewed-by: Dmitry Baryshkov 


It's still Reviewed-by, few nits below.


---
  drivers/gpu/drm/msm/Makefile  |   1 +
  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c | 273 ++
  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.h | 131 ++
  3 files changed, 405 insertions(+)
  create mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c
  create mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.h

diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index d5ca2e6..ca779c1 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -74,6 +74,7 @@ msm-$(CONFIG_DRM_MSM_DPU) += \
disp/dpu1/dpu_hw_top.o \
disp/dpu1/dpu_hw_util.o \
disp/dpu1/dpu_hw_vbif.o \
+   disp/dpu1/dpu_hw_wb.o \
disp/dpu1/dpu_kms.o \
disp/dpu1/dpu_plane.o \
disp/dpu1/dpu_rm.o \
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c
new file mode 100644
index 000..afa8aab
--- /dev/null
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c
@@ -0,0 +1,273 @@
+// SPDX-License-Identifier: GPL-2.0-only
+ /*
+  * Copyright (c) 2022 Qualcomm Innovation Center, Inc. All rights reserved
+  */
+
+#include "dpu_hw_mdss.h"
+#include "dpu_hwio.h"
+#include "dpu_hw_catalog.h"
+#include "dpu_hw_wb.h"
+#include "dpu_formats.h"
+#include "dpu_kms.h"
+
+#define WB_DST_FORMAT 0x000
+#define WB_DST_OP_MODE0x004
+#define WB_DST_PACK_PATTERN   0x008
+#define WB_DST0_ADDR  0x00C
+#define WB_DST1_ADDR  0x010
+#define WB_DST2_ADDR  0x014
+#define WB_DST3_ADDR  0x018
+#define WB_DST_YSTRIDE0   0x01C
+#define WB_DST_YSTRIDE1   0x020
+#define WB_DST_YSTRIDE1   0x020
+#define WB_DST_DITHER_BITDEPTH0x024
+#define WB_DST_MATRIX_ROW00x030
+#define WB_DST_MATRIX_ROW10x034
+#define WB_DST_MATRIX_ROW20x038
+#define WB_DST_MATRIX_ROW30x03C
+#define WB_DST_WRITE_CONFIG   0x048
+#define WB_ROTATION_DNSCALER  0x050
+#define WB_ROTATOR_PIPE_DOWNSCALER0x054
+#define WB_N16_INIT_PHASE_X_C03   0x060
+#define WB_N16_INIT_PHASE_X_C12   0x064
+#define WB_N16_INIT_PHASE_Y_C03   0x068
+#define WB_N16_INIT_PHASE_Y_C12   0x06C
+#define WB_OUT_SIZE   0x074
+#define WB_ALPHA_X_VALUE  0x078
+#define WB_DANGER_LUT 0x084
+#define WB_SAFE_LUT   0x088
+#define WB_QOS_CTRL   0x090
+#define WB_CREQ_LUT_0 0x098
+#define WB_CREQ_LUT_1 0x09C
+#define WB_UBWC_STATIC_CTRL   0x144
+#define WB_MUX0x150
+#define WB_CROP_CTRL  0x154
+#define WB_CROP_OFFSET0x158
+#define WB_CSC_BASE   0x260
+#define WB_DST_ADDR_SW_STATUS 0x2B0
+#define WB_CDP_CNTL   0x2B4
+#define WB_OUT_IMAGE_SIZE 0x2C0
+#define WB_OUT_XY 0x2C4
+
+/* WB_QOS_CTRL */
+#define WB_QOS_CTRL_DANGER_SAFE_ENBIT(0)
+
+static const struct dpu_wb_cfg *_wb_offset(enum dpu_wb wb,
+   const struct dpu_mdss_cfg *m, void __iomem *addr,
+   struct dpu_hw_blk_reg_map *b)
+{
+   int i;
+
+   for (i = 0; i < m->wb_count; i++) {
+   if (wb == m->wb[i].id) {
+   b->base_off = addr;
+   b->blk_off = m->wb[i].base;
+   b->length = m->wb[i].len;
+   b->hwversion = m->hwversion;
+   return &m->wb[i];
+   }
+   }
+   return ERR_PTR(-EINVAL);
+}
+
+static void dpu_hw_wb_setup_outaddress(struct dpu_hw_wb *ctx,
+   struct dpu_hw_wb_cfg *data)
+{
+   struct dpu_hw_blk_reg_map *c = &ctx->hw;
+
+   DPU_REG_WRITE(c, WB_DST0_ADDR, data->dest.plane_addr[0]);
+   DPU_REG_WRITE(c, WB_DST1_ADDR, data->dest.plane_addr[1]);
+   DPU_REG_WRITE(c, WB_DST2_ADDR, data->dest.plane_addr[2]);
+   DPU_REG_WRITE(c, WB_DST3_ADDR, data->dest.plane_addr[3]);
+}
+
+static void dpu_hw_wb_setup_format(struct dpu_hw_wb *ctx,
+   struct dpu_hw_wb_cfg

Re: [PATCH v2 09/17] drm/msm/dpu: add an API to reset the encoder related hw blocks

[Dmitry Baryshkov]

On 20/04/2022 04:46, Abhinav Kumar wrote:

Add an API to reset the encoder related hw blocks to ensure
a proper teardown of the pipeline. At the moment this is being
used only for the writeback encoder but eventually we can start
using this for all interfaces.

changes in v2:
- split the writeback part to another commit

Signed-off-by: Abhinav Kumar 


Reviewed-by: Dmitry Baryshkov 

A minor question: do we need to also reset the DSPP alongside resetting 
the LM?



---
  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c  | 82 
  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h |  7 ++
  2 files changed, 89 insertions(+)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 4523693..0e31ad3 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -1,5 +1,6 @@
  // SPDX-License-Identifier: GPL-2.0-only
  /*
+ * Copyright (c) 2022 Qualcomm Innovation Center, Inc. All rights reserved.
   * Copyright (c) 2014-2018, 2020-2021 The Linux Foundation. All rights 
reserved.
   * Copyright (C) 2013 Red Hat
   * Author: Rob Clark 
@@ -22,6 +23,7 @@
  #include "dpu_hw_ctl.h"
  #include "dpu_hw_dspp.h"
  #include "dpu_hw_dsc.h"
+#include "dpu_hw_merge3d.h"
  #include "dpu_formats.h"
  #include "dpu_encoder_phys.h"
  #include "dpu_crtc.h"
@@ -1838,6 +1840,86 @@ void dpu_encoder_kickoff(struct drm_encoder *drm_enc)
DPU_ATRACE_END("encoder_kickoff");
  }
  
+static void dpu_encoder_helper_reset_mixers(struct dpu_encoder_phys *phys_enc)

+{
+   struct dpu_hw_mixer_cfg mixer;
+   int i, num_lm;
+   u32 flush_mask = 0;
+   struct dpu_global_state *global_state;
+   struct dpu_hw_blk *hw_lm[2];
+   struct dpu_hw_mixer *hw_mixer[2];
+   struct dpu_hw_ctl *ctl = phys_enc->hw_ctl;
+
+   memset(&mixer, 0, sizeof(mixer));
+
+   /* reset all mixers for this encoder */
+   if (phys_enc->hw_ctl->ops.clear_all_blendstages)
+   phys_enc->hw_ctl->ops.clear_all_blendstages(phys_enc->hw_ctl);
+
+   global_state = dpu_kms_get_existing_global_state(phys_enc->dpu_kms);
+
+   num_lm = dpu_rm_get_assigned_resources(&phys_enc->dpu_kms->rm, 
global_state,
+   phys_enc->parent->base.id, DPU_HW_BLK_LM, hw_lm, 
ARRAY_SIZE(hw_lm));
+
+   for (i = 0; i < num_lm; i++) {
+   hw_mixer[i] = to_dpu_hw_mixer(hw_lm[i]);
+   flush_mask = phys_enc->hw_ctl->ops.get_bitmask_mixer(ctl, 
hw_mixer[i]->idx);
+   if (phys_enc->hw_ctl->ops.update_pending_flush)
+   phys_enc->hw_ctl->ops.update_pending_flush(ctl, 
flush_mask);
+
+   /* clear all blendstages */
+   if (phys_enc->hw_ctl->ops.setup_blendstage)
+   phys_enc->hw_ctl->ops.setup_blendstage(ctl, 
hw_mixer[i]->idx, NULL);
+   }
+}
+
+void dpu_encoder_helper_phys_cleanup(struct dpu_encoder_phys *phys_enc)
+{
+   struct dpu_hw_ctl *ctl = phys_enc->hw_ctl;
+   struct dpu_hw_intf_cfg intf_cfg = { 0 };
+   int i;
+   struct dpu_encoder_virt *dpu_enc;
+
+   dpu_enc = to_dpu_encoder_virt(phys_enc->parent);
+
+   phys_enc->hw_ctl->ops.reset(ctl);
+
+   dpu_encoder_helper_reset_mixers(phys_enc);
+
+   for (i = 0; i < dpu_enc->num_phys_encs; i++) {
+   if (dpu_enc->phys_encs[i] && 
phys_enc->hw_intf->ops.bind_pingpong_blk)
+   phys_enc->hw_intf->ops.bind_pingpong_blk(
+   dpu_enc->phys_encs[i]->hw_intf, false,
+   dpu_enc->phys_encs[i]->hw_pp->idx);
+
+   /* mark INTF flush as pending */
+   if (phys_enc->hw_ctl->ops.update_pending_flush_intf)
+   
phys_enc->hw_ctl->ops.update_pending_flush_intf(phys_enc->hw_ctl,
+   dpu_enc->phys_encs[i]->hw_intf->idx);
+   }
+
+   /* reset the merge 3D HW block */
+   if (phys_enc->hw_pp->merge_3d) {
+   
phys_enc->hw_pp->merge_3d->ops.setup_3d_mode(phys_enc->hw_pp->merge_3d,
+   BLEND_3D_NONE);
+   if (phys_enc->hw_ctl->ops.update_pending_flush_merge_3d)
+   phys_enc->hw_ctl->ops.update_pending_flush_merge_3d(ctl,
+   phys_enc->hw_pp->merge_3d->idx);
+   }
+
+   intf_cfg.stream_sel = 0; /* Don't care value for video mode */
+   intf_cfg.mode_3d = dpu_encoder_helper_get_3d_blend_mode(phys_enc);
+   if (phys_enc->hw_pp->merge_3d)
+   intf_cfg.merge_3d = phys_enc->hw_pp->merge_3d->idx;
+
+   if (ctl->ops.reset_intf_cfg)
+   ctl->ops.reset_intf_cfg(ctl, &intf_cfg);
+
+   ctl->ops.trigger_flush(ctl);
+   ctl->ops.trigger_start(ctl);
+   ctl->ops.clear_pending_flush(ctl);
+}
+
  void dpu_encoder_prepare_commit(struct drm_encoder *drm_enc)
  {
struct dpu_encoder_virt *dpu_enc;

[PATCH v3] drm/doc: Add sections about tiny drivers and external refs to intro page

[Javier Martinez Canillas]

Learning about the DRM subsystem could be quite overwhelming for newcomers
but there are lots of useful talks, slides and articles available that can
help to understand the needed concepts and ease the learning curve.

There are also simple DRM drivers that can be used as example about how a
DRM driver should look like.

Add sections to the introduction page, that contains references to these.

Suggested-by: Daniel Vetter 
Signed-off-by: Javier Martinez Canillas 
Acked-by: Pekka Paalanen 
Acked-by: Thomas Zimmermann 
---

Changes in v3:
- Fix typos and grammar errors that found when re-reading the changes.

Changes in v2:
- Remove paragraph that gave wrong impression that DRM is complex (Pekka 
Paalanen).
- Add Thomas Zimmermann's and Pekka Paalanen's Acked-by tags.
- Replace "Learning material" title with "External References" (Thomas 
Zimmermann).
- Add a section about tiny DRM drivers being a good first example (Daniel 
Vetter).
- Add some more external references that I found interesting since v1 was 
posted.

 Documentation/gpu/introduction.rst | 60 ++
 1 file changed, 60 insertions(+)

diff --git a/Documentation/gpu/introduction.rst 
b/Documentation/gpu/introduction.rst
index 25a56e9c0cfd..f05eccd2c07c 100644
--- a/Documentation/gpu/introduction.rst
+++ b/Documentation/gpu/introduction.rst
@@ -112,3 +112,63 @@ Please conduct yourself in a respectful and civilised 
manner when
 interacting with community members on mailing lists, IRC, or bug
 trackers. The community represents the project as a whole, and abusive
 or bullying behaviour is not tolerated by the project.
+
+Simple DRM drivers to use as examples
+=
+
+The DRM subsystem contains a lot of helper functions to ease writing drivers 
for
+simple graphic devices. For example, the `drivers/gpu/drm/tiny/` directory has 
a
+set of drivers that are simple enough to be implemented in a single source 
file.
+
+These drivers make use of the `struct drm_simple_display_pipe_funcs`, that 
hides
+any complexity of the DRM subsystem and just requires drivers to implement a 
few
+functions needed to operate the device. This could be used for devices that 
just
+need a display pipeline with one full-screen scanout buffer feeding one output.
+
+The tiny DRM drivers are good examples to understand how DRM drivers should 
look
+like. Since are just a few hundreds lines of code, they are quite easy to read.
+
+External References
+===
+
+Delving into a Linux kernel subsystem for the first time can be an overwhelming
+experience, one needs to get familiar with all the concepts and learn about the
+subsystem's internals, among other details.
+
+To shallow the learning curve, this section contains a list of presentations
+and documents that can be used to learn about DRM/KMS and graphics in general.
+
+There are different reasons why someone might want to get into DRM: porting an
+existing fbdev driver, write a DRM driver for a new hardware, fixing bugs that
+could face when working on the graphics user-space stack, etc. For this reason,
+the learning material covers many aspects of the Linux graphics stack. From an
+overview of the kernel and user-space stacks to very specific topics.
+
+The list is sorted in reverse chronological order, to keep the most up-to-date
+material at the top. But all of them contain useful information, and it can be
+valuable to go through older material to understand the rationale and context
+in which the changes to the DRM subsystem were made.
+
+Conference talks
+
+
+* `An Overview of the Linux and Userspace Graphics Stack 
`_ - Paul Kocialkowski (2020)
+* `Getting pixels on screen on Linux: introduction to Kernel Mode Setting 
`_ - Simon Ser (2020)
+* `Everything Great about Upstream Graphics 
`_ - Daniel Vetter (2019)
+* `An introduction to the Linux DRM subsystem 
`_ - Maxime Ripard (2017)
+* `Embrace the Atomic (Display) Age 
`_ - Daniel Vetter (2016)
+* `Anatomy of an Atomic KMS Driver 
`_ - Laurent Pinchart (2015)
+* `Atomic Modesetting for Drivers 
`_ - Daniel Vetter (2015)
+* `Anatomy of an Embedded KMS Driver 
`_ - Laurent Pinchart (2013)
+
+Slides and articles
+---
+
+* `Understanding the Linux Graphics Stack 
`_ - Bootlin 
(2022)
+* `DRM KMS overview `_ - 
STMicroelectronics (2021)
+* `Linux graphic stack 
`_ - Nathan 
Gauër (2017)
+* `Atomic mode setting design overview, part 1 

Re: [PATCH v2 12/17] drm/msm/dpu: move _dpu_plane_get_qos_lut to dpu_hw_util file

[Dmitry Baryshkov]

On 20/04/2022 04:46, Abhinav Kumar wrote:

_dpu_plane_get_qos_lut() is not specific to just dpu_plane.
It can take any fill level and return the LUT matching it.
This can be used even for other modules like dpu_writeback.

Move _dpu_plane_get_qos_lut() to the common dpu_hw_util file
and rename it to _dpu_hw_get_qos_lut().

Signed-off-by: Abhinav Kumar 


Reviewed-by: Dmitry Baryshkov 


---
  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.c | 25 +
  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.h |  4 
  drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c   | 27 +--
  3 files changed, 30 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.c
index aad8511..512316f 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.c
@@ -422,3 +422,28 @@ void dpu_hw_csc_setup(struct dpu_hw_blk_reg_map *c,
DPU_REG_WRITE(c, csc_reg_off + 0x3c, data->csc_post_bv[1]);
DPU_REG_WRITE(c, csc_reg_off + 0x40, data->csc_post_bv[2]);
  }
+
+/**
+ * _dpu_hw_get_qos_lut - get LUT mapping based on fill level
+ * @tbl:   Pointer to LUT table
+ * @total_fl:  fill level
+ * Return: LUT setting corresponding to the fill level
+ */
+u64 _dpu_hw_get_qos_lut(const struct dpu_qos_lut_tbl *tbl,
+   u32 total_fl)
+{
+   int i;
+
+   if (!tbl || !tbl->nentry || !tbl->entries)
+   return 0;
+
+   for (i = 0; i < tbl->nentry; i++)
+   if (total_fl <= tbl->entries[i].fl)
+   return tbl->entries[i].lut;
+
+   /* if last fl is zero, use as default */
+   if (!tbl->entries[i-1].fl)
+   return tbl->entries[i-1].lut;
+
+   return 0;
+}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.h
index 3913475..529a6e0 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.h
@@ -9,6 +9,7 @@
  #include 
  #include 
  #include "dpu_hw_mdss.h"
+#include "dpu_hw_catalog.h"
  
  #define REG_MASK(n) ((BIT(n)) - 1)
  
@@ -324,4 +325,7 @@ void dpu_hw_csc_setup(struct dpu_hw_blk_reg_map  *c,

u32 csc_reg_off,
const struct dpu_csc_cfg *data, bool csc10);
  
+u64 _dpu_hw_get_qos_lut(const struct dpu_qos_lut_tbl *tbl,

+   u32 total_fl);
+
  #endif /* _DPU_HW_UTIL_H */
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index c77c3d9d..730f0a3 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -280,31 +280,6 @@ static int _dpu_plane_calc_fill_level(struct drm_plane 
*plane,
  }
  
  /**

- * _dpu_plane_get_qos_lut - get LUT mapping based on fill level
- * @tbl:   Pointer to LUT table
- * @total_fl:  fill level
- * Return: LUT setting corresponding to the fill level
- */
-static u64 _dpu_plane_get_qos_lut(const struct dpu_qos_lut_tbl *tbl,
-   u32 total_fl)
-{
-   int i;
-
-   if (!tbl || !tbl->nentry || !tbl->entries)
-   return 0;
-
-   for (i = 0; i < tbl->nentry; i++)
-   if (total_fl <= tbl->entries[i].fl)
-   return tbl->entries[i].lut;
-
-   /* if last fl is zero, use as default */
-   if (!tbl->entries[i-1].fl)
-   return tbl->entries[i-1].lut;
-
-   return 0;
-}
-
-/**
   * _dpu_plane_set_qos_lut - set QoS LUT of the given plane
   * @plane:Pointer to drm plane
   * @fb:   Pointer to framebuffer associated with the 
given plane
@@ -333,7 +308,7 @@ static void _dpu_plane_set_qos_lut(struct drm_plane *plane,
lut_usage = DPU_QOS_LUT_USAGE_MACROTILE;
}
  
-	qos_lut = _dpu_plane_get_qos_lut(

+   qos_lut = _dpu_hw_get_qos_lut(
&pdpu->catalog->perf.qos_lut_tbl[lut_usage], total_fl);
  
  	trace_dpu_perf_set_qos_luts(pdpu->pipe - SSPP_VIG0,



--
With best wishes
Dmitry

Re: [PATCH resend v8 0/5] phy: phy-fsl-imx8-mipi-dphy: Add i.MX8qxp LVDS PHY mode support

[Vinod Koul]

On 19-04-22, 09:08, Liu Ying wrote:
> Hi,
> 
> This is the v8 series to add i.MX8qxp LVDS PHY mode support for the Mixel
> PHY in the Freescale i.MX8qxp SoC.
> 
> The Mixel PHY is MIPI DPHY + LVDS PHY combo, which can works in either
> MIPI DPHY mode or LVDS PHY mode.  The PHY mode is controlled by i.MX8qxp
> SCU firmware.  The PHY driver would call a SCU function to configure the
> mode.
> 
> The PHY driver is already supporting the Mixel MIPI DPHY in i.MX8mq SoC,
> where it appears to be a single MIPI DPHY.
> 
> 
> Patch 1/5 sets PHY mode in the Northwest Logic MIPI DSI host controller
> bridge driver, since i.MX8qxp SoC embeds this controller IP to support
> MIPI DSI displays together with the Mixel PHY.
> 
> Patch 2/5 allows LVDS PHYs to be configured through the generic PHY functions
> and through a custom structure added to the generic PHY configuration union.
> 
> Patch 3/5 converts mixel,mipi-dsi-phy plain text dt binding to json-schema.
> 
> Patch 4/5 adds dt binding support for the Mixel combo PHY in i.MX8qxp SoC.
> 
> Patch 5/5 adds the i.MX8qxp LVDS PHY mode support in the Mixel PHY driver.

Applied patch 2-5 to phy-next, thanks

-- 
~Vinod

Re: [PATCH v3] drm/gma500: fix a potential repeat execution in psb_driver_load

[Patrik Jakobsson]

On Wed, Apr 13, 2022 at 7:11 AM Xiaomeng Tong  wrote:
>
> Instead of exiting the loop as expected when an entry is found, the
> list_for_each_entry() continues until the traversal is complete. To
> avoid potential executing 'ret = gma_backlight_init(dev);' repeatly,
> goto outside the loop when found entry by replacing switch/case with
> if statement.
>
> Signed-off-by: Xiaomeng Tong 

Thanks for the patch. I've applied it to drm-misc-next.

I fixed up an indentation issue on the second line.

Cheers
Patrik

> ---
> changes since v2:
>  - replace switch with if statement (Patrik Jakobsson)
>
> changes since v1:
>  - goto outside the loop (Xiaomeng Tong)
>
> v2: 
> https://lore.kernel.org/dri-devel/20220406113143.10699-1-xiam0nd.t...@gmail.com/
> v1: https://lore.kernel.org/lkml/20220401115811.9656-1-xiam0nd.t...@gmail.com/
> ---
>  drivers/gpu/drm/gma500/psb_drv.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/gma500/psb_drv.c 
> b/drivers/gpu/drm/gma500/psb_drv.c
> index 2aff54d505e2..85211ec16e52 100644
> --- a/drivers/gpu/drm/gma500/psb_drv.c
> +++ b/drivers/gpu/drm/gma500/psb_drv.c
> @@ -396,9 +396,8 @@ static int psb_driver_load(struct drm_device *dev, 
> unsigned long flags)
> drm_for_each_connector_iter(connector, &conn_iter) {
> gma_encoder = gma_attached_encoder(connector);
>
> -   switch (gma_encoder->type) {
> -   case INTEL_OUTPUT_LVDS:
> -   case INTEL_OUTPUT_MIPI:
> +   if (gma_encoder->type == INTEL_OUTPUT_LVDS ||
> +   gma_encoder->type == INTEL_OUTPUT_MIPI) {
> ret = gma_backlight_init(dev);
> break;
> }
> --
> 2.17.1
>

Re: [PATCH v2 2/2] fbdev: Warn in hot-unplug workaround for framebuffers without device

[Javier Martinez Canillas]

Hello Thomas,

Thanks a lot for re-spinning your series.

On 4/19/22 12:04, Thomas Zimmermann wrote:
> A workaround makes fbdev hot-unplugging work for framebuffers without
> device. The only user for this feature was offb. As each OF framebuffer
> now has an associated platform device, the workaround hould no longer
> be triggered. Update it with a warning and rewrite the comment. Fbdev
> drivers that trigger the hot-unplug workaround really need to be fixed.
> 
> Signed-off-by: Thomas Zimmermann 
> Suggested-by: Javier Martinez Canillas 
> ---

Reviewed-by: Javier Martinez Canillas 

-- 
Best regards,

Javier Martinez Canillas
Linux Engineering
Red Hat

Re: [PATCH 03/15] dma-buf & drm/amdgpu: remove dma_resv workaround

[Christian König]

Hi Zack,

Am 20.04.22 um 05:56 schrieb Zack Rusin:

On Thu, 2022-04-07 at 10:59 +0200, Christian König wrote:

Rework the internals of the dma_resv object to allow adding more than
one
write fence and remember for each fence what purpose it had.

This allows removing the workaround from amdgpu which used a container
for
this instead.

Signed-off-by: Christian König 
Reviewed-by: Daniel Vetter 
Cc: amd-...@lists.freedesktop.org


afaict this change broke vmwgfx which now kernel oops right after boot.
I haven't had the time to look into it yet, so I'm not sure what's the
problem. I'll look at this tomorrow, but just in case you have some
clues, the backtrace follows:


that's a known issue and should already be fixed with:

commit d72dcbe9fce505228dae43bef9da8f2b707d1b3d
Author: Christian König 
Date:   Mon Apr 11 15:21:59 2022 +0200

    drm/ttm: fix logic inversion in ttm_eu_reserve_buffers

    That should have been max, not min.

    Signed-off-by: Christian König 
    Fixes: c8d4c18bfbc4 ("dma-buf/drivers: make reserving a shared slot 
mandatory v4")

    Reviewed-by: Matthew Auld 
    Link: 
https://patchwork.freedesktop.org/patch/msgid/20220411134537.2854-1-christian.koe...@amd.com



Just a stupid logic inversion. Sorry for the noise.

Regards,
Christian.



  [ cut here ]
  kernel BUG at drivers/dma-buf/dma-resv.c:306!
  invalid opcode:  [#1] PREEMPT SMP PTI
  CPU: 1 PID: 1608 Comm: gnome-shell Not tainted 5.18.0-rc1-vmwgfx #18
  Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop
Reference Platform, BIOS 6.00 11/12/2020
  RIP: 0010:dma_resv_add_fence+0x2ed/0x300
  Code: ff ff be 01 00 00 00 e8 31 7d d9 ff e9 80 fd ff ff be 03 00 00
00 e8 22 7d d9 ff e9 ee fe ff ff 0f 1f 44 00 00 e9 bc fe ff ff <0f> 0b
e8 4c cc 45 00 66 6>
  RSP: 0018:a1e6846c3ab0 EFLAGS: 00010246
  RAX:  RBX: 94c5c5507138 RCX: 902bc24e7b7c70ae
  RDX: 902bc24e7b7c70ae RSI: aaf7f437 RDI: aaffde66
  RBP: a1e6846c3b08 R08:  R09: 0001
  R10: 0004 R11:  R12: 94c5cba90578
  R13:  R14: 94c5cba8bc00 R15: 
  FS:  7f9a17c6e600() GS:94c6f9e4()
knlGS:
  CS:  0010 DS:  ES:  CR0: 80050033
  CR2: 7f9a14113000 CR3: 0144c003 CR4: 003706e0
  Call Trace:
   
   ttm_eu_fence_buffer_objects+0x54/0x110 [ttm]
   vmw_execbuf_process+0xcae/0x12a0 [vmwgfx]
   ? vmw_execbuf_release_pinned_bo+0x60/0x60 [vmwgfx]
   vmw_execbuf_ioctl+0xfb/0x160 [vmwgfx]
   ? vmw_execbuf_release_pinned_bo+0x60/0x60 [vmwgfx]
   drm_ioctl_kernel+0xba/0x150 [drm]
   ? __might_fault+0x77/0x80
   drm_ioctl+0x247/0x460 [drm]
   ? vmw_execbuf_release_pinned_bo+0x60/0x60 [vmwgfx]
   ? find_held_lock+0x31/0x90
   ? __fget_files+0xc5/0x190
   ? __this_cpu_preempt_check+0x13/0x20
   ? lock_release+0x142/0x2f0
   ? drm_ioctl_kernel+0x150/0x150 [drm]
   vmw_generic_ioctl+0xa3/0x110 [vmwgfx]
   vmw_unlocked_ioctl+0x15/0x20 [vmwgfx]
   __x64_sys_ioctl+0x91/0xc0
   do_syscall_64+0x3b/0x90
   entry_SYSCALL_64_after_hwframe+0x44/0xae
  RIP: 0033:0x7f9a1af1aaff
  Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48
89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <41> 89
c0 3d 00 f0 ff ff 7>
  RSP: 002b:7ffd833696c0 EFLAGS: 0246 ORIG_RAX: 0010
  RAX: ffda RBX: 7ffd83369780 RCX: 7f9a1af1aaff
  RDX: 7ffd83369780 RSI: 4028644c RDI: 000d
  RBP: 4028644c R08: 1248 R09: 7ffd83369808
  R10: 0008 R11: 0246 R12: 7ffd83369808
  R13: 000d R14: 55719cb629c0 R15: 7ffd83369808
   
  Modules linked in: overlay snd_ens1371 intel_rapl_msr snd_ac97_codec
intel_rapl_common ac97_bus vsock_loopback
vmw_vsock_virtio_transport_common vmw_vsock_vmci>
  ---[ end trace  ]---

z

[PATCH] video: clps711x-fb: Use syscon_regmap_lookup_by_phandle

[Alexander Shiyan]

Since version 5.13, the standard syscon bindings have been added
to all clps711x DT nodes, so we can now use the more general
syscon_regmap_lookup_by_phandle function to get the syscon pointer.

Signed-off-by: Alexander Shiyan 
---
 drivers/video/fbdev/clps711x-fb.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/video/fbdev/clps711x-fb.c 
b/drivers/video/fbdev/clps711x-fb.c
index c5d15c6db287..771ce1f76951 100644
--- a/drivers/video/fbdev/clps711x-fb.c
+++ b/drivers/video/fbdev/clps711x-fb.c
@@ -268,8 +268,7 @@ static int clps711x_fb_probe(struct platform_device *pdev)
goto out_fb_release;
}
 
-   cfb->syscon =
-   syscon_regmap_lookup_by_compatible("cirrus,ep7209-syscon1");
+   cfb->syscon = syscon_regmap_lookup_by_phandle(np, "syscon");
if (IS_ERR(cfb->syscon)) {
ret = PTR_ERR(cfb->syscon);
goto out_fb_release;
-- 
2.32.0

Re: [PATCH 13/48] ARM: pxa: use pdev resource for palmld mmio

[Damien Le Moal]

On 4/20/22 01:37, Arnd Bergmann wrote:
> From: Arnd Bergmann 
> 
> The palmld header is almost unused in drivers, the only
> remaining thing now is the PATA device address, which should
> really be passed as a resource.
> 
> Cc: Jens Axboe 
> Cc: linux-...@vger.kernel.org
> Acked-by: Robert Jarzmik 
> Acked-by: Bartlomiej Zolnierkiewicz 
> Signed-off-by: Arnd Bergmann 
> ---
>  arch/arm/mach-pxa/palmld-pcmcia.c |  3 ++-
>  arch/arm/mach-pxa/palmld.c| 12 +---
>  arch/arm/mach-pxa/{include/mach => }/palmld.h |  2 +-
>  drivers/ata/pata_palmld.c |  3 +--
>  4 files changed, 13 insertions(+), 7 deletions(-)
>  rename arch/arm/mach-pxa/{include/mach => }/palmld.h (98%)
> 
> diff --git a/arch/arm/mach-pxa/palmld-pcmcia.c 
> b/arch/arm/mach-pxa/palmld-pcmcia.c
> index 07e0f7438db1..720294a50864 100644
> --- a/arch/arm/mach-pxa/palmld-pcmcia.c
> +++ b/arch/arm/mach-pxa/palmld-pcmcia.c
> @@ -13,9 +13,10 @@
>  #include 
>  
>  #include 
> -#include 
>  #include 
>  
> +#include "palmld.h"
> +
>  static struct gpio palmld_pcmcia_gpios[] = {
>   { GPIO_NR_PALMLD_PCMCIA_POWER,  GPIOF_INIT_LOW, "PCMCIA Power" },
>   { GPIO_NR_PALMLD_PCMCIA_RESET,  GPIOF_INIT_HIGH,"PCMCIA Reset" },
> diff --git a/arch/arm/mach-pxa/palmld.c b/arch/arm/mach-pxa/palmld.c
> index d85146957004..d821606ce0b5 100644
> --- a/arch/arm/mach-pxa/palmld.c
> +++ b/arch/arm/mach-pxa/palmld.c
> @@ -29,8 +29,8 @@
>  #include 
>  
>  #include "pxa27x.h"
> +#include "palmld.h"
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -279,9 +279,15 @@ static inline void palmld_leds_init(void) {}
>   * HDD
>   
> **/
>  #if defined(CONFIG_PATA_PALMLD) || defined(CONFIG_PATA_PALMLD_MODULE)
> +static struct resource palmld_ide_resources[] = {
> + DEFINE_RES_MEM(PALMLD_IDE_PHYS, 0x1000),
> +};
> +
>  static struct platform_device palmld_ide_device = {
> - .name   = "pata_palmld",
> - .id = -1,
> + .name   = "pata_palmld",
> + .id = -1,
> + .resource   = palmld_ide_resources,
> + .num_resources  = ARRAY_SIZE(palmld_ide_resources),
>  };
>  
>  static struct gpiod_lookup_table palmld_ide_gpio_table = {
> diff --git a/arch/arm/mach-pxa/include/mach/palmld.h 
> b/arch/arm/mach-pxa/palmld.h
> similarity index 98%
> rename from arch/arm/mach-pxa/include/mach/palmld.h
> rename to arch/arm/mach-pxa/palmld.h
> index 99a6d8b3a1e3..ee3bc15b71a2 100644
> --- a/arch/arm/mach-pxa/include/mach/palmld.h
> +++ b/arch/arm/mach-pxa/palmld.h
> @@ -9,7 +9,7 @@
>  #ifndef _INCLUDE_PALMLD_H_
>  #define _INCLUDE_PALMLD_H_
>  
> -#include "irqs.h" /* PXA_GPIO_TO_IRQ */
> +#include  /* PXA_GPIO_TO_IRQ */
>  
>  /** HERE ARE GPIOs **/
>  
> diff --git a/drivers/ata/pata_palmld.c b/drivers/ata/pata_palmld.c
> index 2448441571ed..400e65190904 100644
> --- a/drivers/ata/pata_palmld.c
> +++ b/drivers/ata/pata_palmld.c
> @@ -25,7 +25,6 @@
>  #include 
>  
>  #include 
> -#include 
>  
>  #define DRV_NAME "pata_palmld"
>  
> @@ -63,7 +62,7 @@ static int palmld_pata_probe(struct platform_device *pdev)
>   return -ENOMEM;
>  
>   /* remap drive's physical memory address */
> - mem = devm_ioremap(dev, PALMLD_IDE_PHYS, 0x1000);
> + mem = devm_platform_ioremap_resource(pdev, 0);
>   if (!mem)
>   return -ENOMEM;
>  

Acked-by: Damien Le Moal 

-- 
Damien Le Moal
Western Digital Research

Re: [PATCH v2 10/17] drm/msm/dpu: make changes to dpu_encoder to support virtual encoder

[Dmitry Baryshkov]

On 20/04/2022 04:46, Abhinav Kumar wrote:

Make changes to dpu_encoder to support virtual encoder needed
to support writeback for dpu.

changes in v2:
- add the writeback parts to dpu_encoder_helper_phys_cleanup
- rebase on tip of msm-next and fix related dependencies
- get the writeback blocks directly from RM

Signed-off-by: Abhinav Kumar 
---
  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c  | 71 +---
  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h |  3 +
  2 files changed, 54 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 0e31ad3..06b8631 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -928,6 +928,7 @@ static void dpu_encoder_virt_atomic_mode_set(struct 
drm_encoder *drm_enc,
struct dpu_hw_blk *hw_dsc[MAX_CHANNELS_PER_ENC];
int num_lm, num_ctl, num_pp, num_dsc;
unsigned int dsc_mask = 0;
+   enum dpu_hw_blk_type blk_type;
int i;
  
  	if (!drm_enc) {

@@ -1009,12 +1010,21 @@ static void dpu_encoder_virt_atomic_mode_set(struct 
drm_encoder *drm_enc,
phys->hw_pp = dpu_enc->hw_pp[i];
phys->hw_ctl = to_dpu_hw_ctl(hw_ctl[i]);
  
-		if (phys->intf_idx >= INTF_0 && phys->intf_idx < INTF_MAX)

-   phys->hw_intf = dpu_rm_get_intf(&dpu_kms->rm, 
phys->intf_idx);
+   if (dpu_encoder_get_intf_mode(&dpu_enc->base) == 
INTF_MODE_WB_LINE)
+   blk_type = DPU_HW_BLK_WB;
+   else
+   blk_type = DPU_HW_BLK_INTF;
+
+   if (phys->intf_idx >= INTF_0 && phys->intf_idx < INTF_MAX) {
+   if (blk_type == DPU_HW_BLK_INTF)
+   phys->hw_intf = dpu_rm_get_intf(&dpu_kms->rm, 
phys->intf_idx);
+   else if (blk_type == DPU_HW_BLK_WB)
+   phys->hw_wb = dpu_rm_get_wb(&dpu_kms->rm, 
phys->intf_idx);
+   }
  
-		if (!phys->hw_intf) {

+   if (!phys->hw_intf && !phys->hw_wb) {
DPU_ERROR_ENC(dpu_enc,
- "no intf block assigned at idx: %d\n", i);
+ "no intf ow wb block assigned at idx: 
%d\n", i);


or wb


return;
}
  
@@ -1157,15 +1167,22 @@ static void dpu_encoder_virt_disable(struct drm_encoder *drm_enc)

mutex_unlock(&dpu_enc->enc_lock);
  }
  
-static enum dpu_intf dpu_encoder_get_intf(struct dpu_mdss_cfg *catalog,

+static enum dpu_intf dpu_encoder_get_intf_or_wb(struct dpu_mdss_cfg *catalog,
enum dpu_intf_type type, u32 controller_id)
  {
int i = 0;
  
-	for (i = 0; i < catalog->intf_count; i++) {

-   if (catalog->intf[i].type == type
-   && catalog->intf[i].controller_id == controller_id) {
-   return catalog->intf[i].id;
+   if (type != INTF_WB) {
+   for (i = 0; i < catalog->intf_count; i++) {
+   if (catalog->intf[i].type == type
+   && catalog->intf[i].controller_id == 
controller_id) {
+   return catalog->intf[i].id;
+   }
+   }
+   } else {
+   for (i = 0; i < catalog->wb_count; i++) {
+   if (catalog->wb[i].id == controller_id)
+   return catalog->wb[i].id;
}
}
  
@@ -1886,16 +1903,27 @@ void dpu_encoder_helper_phys_cleanup(struct dpu_encoder_phys *phys_enc)
  
  	dpu_encoder_helper_reset_mixers(phys_enc);
  
-	for (i = 0; i < dpu_enc->num_phys_encs; i++) {

-   if (dpu_enc->phys_encs[i] && 
phys_enc->hw_intf->ops.bind_pingpong_blk)
-   phys_enc->hw_intf->ops.bind_pingpong_blk(
-   dpu_enc->phys_encs[i]->hw_intf, false,
-   dpu_enc->phys_encs[i]->hw_pp->idx);
+   if (phys_enc->hw_wb) {


I think this adds a hidden knowledge here. That there is always just a 
single phys_enc for the WB encoder. I'd still do this cleanup in a loop 
together with the INTF cleanup.



+   /* disable the PP block */
+   if (phys_enc->hw_wb->ops.bind_pingpong_blk)
+   phys_enc->hw_wb->ops.bind_pingpong_blk(phys_enc->hw_wb, 
false,
+   phys_enc->hw_pp->idx);
  
-		/* mark INTF flush as pending */

-   if (phys_enc->hw_ctl->ops.update_pending_flush_intf)
-   
phys_enc->hw_ctl->ops.update_pending_flush_intf(phys_enc->hw_ctl,
-   dpu_enc->phys_encs[i]->hw_intf->idx);
+   /* mark WB flush as pending */
+   if (phys_enc->hw_ctl->ops.update_pending_flush_wb)
+ 

Re: [PATCH v2 13/17] drm/msm/dpu: introduce the dpu_encoder_phys_* for writeback

[Dmitry Baryshkov]

On 20/04/2022 04:46, Abhinav Kumar wrote:

Introduce the dpu_encoder_phys_* for the writeback interface
to handle writeback specific hardware programming.

changes in v2:
- rebase on msm-next and fix related dependencies namely
  the irq cleanup
- move cdp_cfg, aspace out of dpu_encoder_phys_wb
- leave a comment about wb master
- start using _dpu_hw_get_qos_lut from dpu_hw_util
- replace hw_pp->merge_3d check with DPU_CTL_ACTIVE_CFG

Signed-off-by: Abhinav Kumar 
---
  drivers/gpu/drm/msm/Makefile   |   1 +
  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h   |  30 +
  .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c| 751 +
  3 files changed, 782 insertions(+)
  create mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c

diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index ca779c1..0387f22 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -60,6 +60,7 @@ msm-$(CONFIG_DRM_MSM_DPU) += \
disp/dpu1/dpu_encoder.o \
disp/dpu1/dpu_encoder_phys_cmd.o \
disp/dpu1/dpu_encoder_phys_vid.o \
+   disp/dpu1/dpu_encoder_phys_wb.o \
disp/dpu1/dpu_formats.o \
disp/dpu1/dpu_hw_catalog.o \
disp/dpu1/dpu_hw_ctl.o \
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
index 00951f3..5452f98 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
@@ -150,6 +150,7 @@ struct dpu_encoder_phys_ops {
   * @INTR_IDX_PINGPONG: Pingpong done unterrupt for cmd mode panel
   * @INTR_IDX_UNDERRUN: Underrun unterrupt for video and cmd mode panel
   * @INTR_IDX_RDPTR:Readpointer done unterrupt for cmd mode panel
+ * @INTR_IDX_WB_DONE:  Writeback fone interrupt for virtual connector
   */
  enum dpu_intr_idx {
INTR_IDX_VSYNC,
@@ -157,6 +158,7 @@ enum dpu_intr_idx {
INTR_IDX_UNDERRUN,
INTR_IDX_CTL_START,
INTR_IDX_RDPTR,
+   INTR_IDX_WB_DONE,
INTR_IDX_MAX,
  };
  
@@ -224,6 +226,27 @@ static inline int dpu_encoder_phys_inc_pending(struct dpu_encoder_phys *phys)

  }
  
  /**

+ * struct dpu_encoder_phys_wb - sub-class of dpu_encoder_phys to handle command
+ * mode specific operations
+ * @base:  Baseclass physical encoder structure
+ * @wbirq_refcount: Reference count of writeback interrupt
+ * @wb_done_timeout_cnt: number of wb done irq timeout errors
+ * @wb_cfg:  writeback block config to store fb related details
+ * @wb_conn: backpointer to writeback connector
+ * @wb_job: backpointer to current writeback job
+ * @dest:   dpu buffer layout for current writeback output buffer
+ */
+struct dpu_encoder_phys_wb {
+   struct dpu_encoder_phys base;
+   atomic_t wbirq_refcount;
+   int wb_done_timeout_cnt;
+   struct dpu_hw_wb_cfg wb_cfg;
+   struct drm_writeback_connector *wb_conn;
+   struct drm_writeback_job *wb_job;
+   struct dpu_hw_fmt_layout dest;
+};
+
+/**
   * struct dpu_encoder_phys_cmd - sub-class of dpu_encoder_phys to handle 
command
   *mode specific operations
   * @base: Baseclass physical encoder structure
@@ -291,6 +314,13 @@ struct dpu_encoder_phys *dpu_encoder_phys_cmd_init(
struct dpu_enc_phys_init_params *p);
  
  /**

+ * dpu_encoder_phys_wb_init - initialize writeback encoder
+ * @init:  Pointer to init info structure with initialization params
+ */
+struct dpu_encoder_phys *dpu_encoder_phys_wb_init(
+   struct dpu_enc_phys_init_params *p);
+
+/**
   * dpu_encoder_helper_trigger_start - control start helper function
   *This helper function may be optionally specified by physical
   *encoders if they require ctl_start triggering.
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c
new file mode 100644
index 000..128317fe
--- /dev/null
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c
@@ -0,0 +1,751 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2022 Qualcomm Innovation Center, Inc. All rights reserved.
+ */
+
+#define pr_fmt(fmt)"[drm:%s:%d] " fmt, __func__, __LINE__
+
+#include 
+
+#include "dpu_encoder_phys.h"
+#include "dpu_formats.h"
+#include "dpu_hw_top.h"
+#include "dpu_hw_wb.h"
+#include "dpu_hw_lm.h"
+#include "dpu_hw_blk.h"
+#include "dpu_hw_merge3d.h"
+#include "dpu_hw_interrupts.h"
+#include "dpu_core_irq.h"
+#include "dpu_vbif.h"
+#include "dpu_crtc.h"
+#include "disp/msm_disp_snapshot.h"
+
+#define DEFAULT_MAX_WRITEBACK_WIDTH 2048
+
+#define to_dpu_encoder_phys_wb(x) \
+   container_of(x, struct dpu_encoder_phys_wb, base)
+
+/**
+ * dpu_encoder_phys_wb_is_master - report wb always as master encoder
+ */
+static bool dpu_encoder_phys_wb_is_master(struct dpu_encoder_phys *phys_enc)
+{
+   /* there is only one physical enc for dpu_writeback *

Re: [PATCH v2] drm/vc4: Fix pm_runtime_get_sync() usage

[Maxime Ripard]

On Wed, Apr 20, 2022 at 12:49:48AM +, Miaoqian Lin wrote:
> If the device is already in a runtime PM enabled state
> pm_runtime_get_sync() will return 1, so a test for negative
> value should be used to check for errors.
> 
> Also, we need to call pm_runtime_put_noidle() when pm_runtime_get_sync()
> fails, so use pm_runtime_resume_and_get() instead. this function
> will handle this.
> 
> Fixes: 4078f5757144 ("drm/vc4: Add DSI driver")
> Signed-off-by: Miaoqian Lin 
> ---
> change in v2:
> - switch to pm_runtime_resume_and_get() to fix refcount leak.
> ---
>  drivers/gpu/drm/vc4/vc4_dsi.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vc4/vc4_dsi.c b/drivers/gpu/drm/vc4/vc4_dsi.c
> index 752f921735c6..9d7ffaf6bc70 100644
> --- a/drivers/gpu/drm/vc4/vc4_dsi.c
> +++ b/drivers/gpu/drm/vc4/vc4_dsi.c
> @@ -846,8 +846,8 @@ static void vc4_dsi_encoder_enable(struct drm_encoder 
> *encoder)
>   unsigned long phy_clock;
>   int ret;
>  
> - ret = pm_runtime_get_sync(dev);
> - if (ret) {
> + ret = pm_runtime_resume_and_get(dev);
> + if (ret < 0) {

pm_runtime_resume_and_get will return 0 on success, so the previous check was 
correct

Maxime


signature.asc
Description: PGP signature

Re: [PATCH v2 14/17] drm/msm/dpu: add the writeback connector layer

[Dmitry Baryshkov]

On 20/04/2022 04:46, Abhinav Kumar wrote:

Introduce the dpu_writeback module which serves as the
interface between dpu operations and the drm_writeback.

This module manages the connector related operations for
dpu writeback.

changes in v2:
- start using drm_writeback_connector_init_with_encoder()
- drop unnecessary arguments from dpu_writeback_init()
- rebase on msm-next tip and remove usage of priv->connectors

Signed-off-by: Abhinav Kumar 
---
  drivers/gpu/drm/msm/Makefile  |  1 +
  drivers/gpu/drm/msm/disp/dpu1/dpu_writeback.c | 68 +++
  drivers/gpu/drm/msm/disp/dpu1/dpu_writeback.h | 25 ++
  3 files changed, 94 insertions(+)
  create mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_writeback.c
  create mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_writeback.h

diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index 0387f22..66395ee 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -80,6 +80,7 @@ msm-$(CONFIG_DRM_MSM_DPU) += \
disp/dpu1/dpu_plane.o \
disp/dpu1/dpu_rm.o \
disp/dpu1/dpu_vbif.o \
+   disp/dpu1/dpu_writeback.o
  
  msm-$(CONFIG_DRM_MSM_MDSS) += \

msm_mdss.o \
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_writeback.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_writeback.c
new file mode 100644
index 000..526d884
--- /dev/null
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_writeback.c
@@ -0,0 +1,68 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2022 Qualcomm Innovation Center, Inc. All rights reserved.
+ */
+
+#include "dpu_writeback.h"
+
+static int dpu_wb_conn_get_modes(struct drm_connector *connector)
+{
+   struct drm_device *dev = connector->dev;
+
+   return drm_add_modes_noedid(connector, dev->mode_config.max_width,
+   dev->mode_config.max_height);
+}
+
+static const struct drm_connector_funcs dpu_wb_conn_funcs = {
+   .reset = drm_atomic_helper_connector_reset,
+   .fill_modes = drm_helper_probe_single_connector_modes,
+   .destroy = drm_connector_cleanup,
+   .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
+   .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
+};
+
+static int dpu_wb_conn_prepare_job(struct drm_writeback_connector *connector,
+   struct drm_writeback_job *job)
+{
+   if (!job->fb)
+   return 0;
+
+   dpu_encoder_prepare_wb_job(connector->encoder, job);
+
+   return 0;
+}
+
+static void dpu_wb_conn_cleanup_job(struct drm_writeback_connector *connector,
+   struct drm_writeback_job *job)
+{
+   if (!job->fb)
+   return;
+
+   dpu_encoder_cleanup_wb_job(connector->encoder, job);
+}
+
+static const struct drm_connector_helper_funcs dpu_wb_conn_helper_funcs = {
+   .get_modes = dpu_wb_conn_get_modes,
+   .prepare_writeback_job = dpu_wb_conn_prepare_job,
+   .cleanup_writeback_job = dpu_wb_conn_cleanup_job,
+};
+
+int dpu_writeback_init(struct drm_device *dev, struct drm_encoder *enc,
+   const u32 *format_list, u32 num_formats)
+{
+   struct dpu_wb_connector *dpu_wb_conn;
+   int rc = 0;
+
+   dpu_wb_conn = devm_kzalloc(dev->dev, sizeof(*dpu_wb_conn), GFP_KERNEL);
+
+   drm_connector_helper_add(&dpu_wb_conn->base.base, 
&dpu_wb_conn_helper_funcs);
+
+   /* DPU initializes the encoder and sets it up completely for writeback
+* cases and hence should use the new API 
drm_writeback_connector_init_with_encoder
+* to initialize the writeback connector
+*/
+   rc = drm_writeback_connector_init_with_encoder(dev, &dpu_wb_conn->base, 
enc,
+   &dpu_wb_conn_funcs, format_list, num_formats);
+
+   return rc;
+}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_writeback.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_writeback.h
new file mode 100644
index 000..05aff05
--- /dev/null
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_writeback.h
@@ -0,0 +1,25 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (c) 2022 Qualcomm Innovation Center, Inc. All rights reserved.
+ */
+
+#ifndef _DPU_WRITEBACK_H
+#define _DPU_WRITEBACK_H
+
+#include 
+#include 
+#include 
+#include 
+
+#include "msm_drv.h"
+#include "dpu_kms.h"
+#include "dpu_encoder_phys.h"
+
+struct dpu_wb_connector {
+   struct drm_writeback_connector base;
+};


Do you plan to add more fields to this struct? If not, we can probably 
drop it and use struct drm_writeback_connector directly.



+
+int dpu_writeback_init(struct drm_device *dev, struct drm_encoder *enc,
+   const u32 *format_list, u32 num_formats);
+
+#endif /*_DPU_WRITEBACK_H */



--
With best wishes
Dmitry

Re: [PATCH v2 15/17] drm/msm/dpu: initialize dpu encoder and connector for writeback

[Dmitry Baryshkov]

On 20/04/2022 04:46, Abhinav Kumar wrote:

Initialize dpu encoder and connector for writeback if the
target supports it in the catalog.

changes in v2:
- start initialing the encoder for writeback since we
have migrated to using drm_writeback_connector_init_with_encoder()
- instead of checking for WB_2 inside _dpu_kms_initialize_writeback
call it only when its WB_2
- rebase on tip of msm-next and remove usage of priv->encoders

Signed-off-by: Abhinav Kumar 



Reviewed-by: Dmitry Baryshkov 

---
  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 27 ++
  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 58 +
  2 files changed, 78 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index b117cad..b1475dd 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -2085,7 +2085,7 @@ static void dpu_encoder_early_unregister(struct 
drm_encoder *encoder)
  }
  
  static int dpu_encoder_virt_add_phys_encs(

-   u32 display_caps,
+   struct msm_display_info *disp_info,
struct dpu_encoder_virt *dpu_enc,
struct dpu_enc_phys_init_params *params)
  {
@@ -2104,7 +2104,7 @@ static int dpu_encoder_virt_add_phys_encs(
return -EINVAL;
}
  
-	if (display_caps & MSM_DISPLAY_CAP_VID_MODE) {

+   if (disp_info->capabilities & MSM_DISPLAY_CAP_VID_MODE) {
enc = dpu_encoder_phys_vid_init(params);
  
  		if (IS_ERR_OR_NULL(enc)) {

@@ -2117,7 +2117,7 @@ static int dpu_encoder_virt_add_phys_encs(
++dpu_enc->num_phys_encs;
}
  
-	if (display_caps & MSM_DISPLAY_CAP_CMD_MODE) {

+   if (disp_info->capabilities & MSM_DISPLAY_CAP_CMD_MODE) {
enc = dpu_encoder_phys_cmd_init(params);
  
  		if (IS_ERR_OR_NULL(enc)) {

@@ -2130,6 +2130,19 @@ static int dpu_encoder_virt_add_phys_encs(
++dpu_enc->num_phys_encs;
}
  
+	if (disp_info->intf_type == DRM_MODE_ENCODER_VIRTUAL) {

+   enc = dpu_encoder_phys_wb_init(params);
+
+   if (IS_ERR_OR_NULL(enc)) {
+   DPU_ERROR_ENC(dpu_enc, "failed to init wb enc: %ld\n",
+   PTR_ERR(enc));
+   return enc == NULL ? -EINVAL : PTR_ERR(enc);
+   }
+
+   dpu_enc->phys_encs[dpu_enc->num_phys_encs] = enc;
+   ++dpu_enc->num_phys_encs;
+   }
+
if (params->split_role == ENC_ROLE_SLAVE)
dpu_enc->cur_slave = enc;
else
@@ -2220,9 +2233,8 @@ static int dpu_encoder_setup_display(struct 
dpu_encoder_virt *dpu_enc,
}
  
  		if (!ret) {

-   ret = 
dpu_encoder_virt_add_phys_encs(disp_info->capabilities,
-   
 dpu_enc,
-   
 &phys_params);
+   ret = dpu_encoder_virt_add_phys_encs(disp_info,
+   dpu_enc, &phys_params);
if (ret)
DPU_ERROR_ENC(dpu_enc, "failed to add phys 
encs\n");
}
@@ -2339,8 +2351,9 @@ struct drm_encoder *dpu_encoder_init(struct drm_device 
*dev,
if (!dpu_enc)
return ERR_PTR(-ENOMEM);
  
+

rc = drm_encoder_init(dev, &dpu_enc->base, &dpu_encoder_funcs,
-   drm_enc_mode, NULL);
+ drm_enc_mode, NULL);
if (rc) {
devm_kfree(dev->dev, dpu_enc);
return ERR_PTR(rc);
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index c683cab..0a50509 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -1,5 +1,6 @@
  // SPDX-License-Identifier: GPL-2.0-only
  /*
+ * Copyright (c) 2022 Qualcomm Innovation Center, Inc. All rights reserved.
   * Copyright (c) 2014-2018, The Linux Foundation. All rights reserved.
   * Copyright (C) 2013 Red Hat
   * Author: Rob Clark 
@@ -15,6 +16,7 @@
  #include 
  #include 
  #include 
+#include 
  
  #include "msm_drv.h"

  #include "msm_mmu.h"
@@ -29,6 +31,7 @@
  #include "dpu_kms.h"
  #include "dpu_plane.h"
  #include "dpu_vbif.h"
+#include "dpu_writeback.h"
  
  #define CREATE_TRACE_POINTS

  #include "dpu_trace.h"
@@ -648,6 +651,45 @@ static int _dpu_kms_initialize_displayport(struct 
drm_device *dev,
return 0;
  }
  
+static int _dpu_kms_initialize_writeback(struct drm_device *dev,

+   struct msm_drm_private *priv, struct dpu_kms *dpu_kms,
+   const u32 *wb_formats, int n_formats)
+{
+   struct drm_encoder *encoder = NULL;
+   str

Re: [PATCH 2/2] drm/nvdla: Add driver support for NVDLA

[kernel test robot]

Hi Cai,

I love your patch! Yet something to improve:

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

url:
https://github.com/intel-lab-lkp/linux/commits/Cai-Huoqing/drm-nvdla-Add-driver-support-for-NVDLA/20220419-220255
base:   git://anongit.freedesktop.org/drm/drm drm-next
config: h8300-randconfig-r014-20220420 
(https://download.01.org/0day-ci/archive/20220420/202204201512.pp20mxt5-...@intel.com/config)
compiler: h8300-linux-gcc (GCC) 11.2.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# 
https://github.com/intel-lab-lkp/linux/commit/7539e5487eb7d0c6f13c03bba596e51a2238106d
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review 
Cai-Huoqing/drm-nvdla-Add-driver-support-for-NVDLA/20220419-220255
git checkout 7539e5487eb7d0c6f13c03bba596e51a2238106d
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross W=1 
O=build_dir ARCH=h8300 SHELL=/bin/bash drivers/gpu/

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

All error/warnings (new ones prefixed by >>):

>> make[5]: *** No rule to make target 
>> 'drivers/gpu/drm/nvdla/nvdla_engine_data.o', needed by 
>> 'drivers/gpu/drm/nvdla/built-in.a'.
>> make[5]: *** No rule to make target 
>> 'drivers/gpu/drm/nvdla/nvdla_engine_debug.o', needed by 
>> 'drivers/gpu/drm/nvdla/built-in.a'.
   make[5]: Target '__build' not remade because of errors.
--
>> drivers/gpu/drm/nvdla/nvdla_drm.c:45:9: warning: no previous prototype for 
>> 'dla_get_time_us' [-Wmissing-prototypes]
  45 | int64_t dla_get_time_us(void)
 | ^~~
   drivers/gpu/drm/nvdla/nvdla_drm.c: In function 'nvdla_engine_isr':
>> drivers/gpu/drm/nvdla/nvdla_drm.c:75:18: warning: variable 'mask' set but 
>> not used [-Wunused-but-set-variable]
  75 | uint32_t mask;
 |  ^~~~
--
   drivers/gpu/drm/nvdla/nvdla_gem.c: In function 'nvdla_fill_task_desc':
>> drivers/gpu/drm/nvdla/nvdla_gem.c:39:17: warning: cast to pointer from 
>> integer of different size [-Wint-to-pointer-cast]
  39 | (void __user *)local_task->address_list,
 | ^
--
   drivers/gpu/drm/nvdla/nvdla_scheduler.c: In function 'dla_op_completion':
>> drivers/gpu/drm/nvdla/nvdla_scheduler.c:513:26: warning: variable 'task' set 
>> but not used [-Wunused-but-set-variable]
 513 | struct dla_task *task;
 |  ^~~~
--
>> drivers/gpu/drm/nvdla/nvdla_scheduler.c:363: warning: This comment starts 
>> with '/**', but isn't a kernel-doc comment. Refer 
>> Documentation/doc-guide/kernel-doc.rst
* Dequeue next operation of same type from list of operations
   drivers/gpu/drm/nvdla/nvdla_scheduler.c:505: warning: This comment starts 
with '/**', but isn't a kernel-doc comment. Refer 
Documentation/doc-guide/kernel-doc.rst
* Handle operation completion notification
   drivers/gpu/drm/nvdla/nvdla_scheduler.c:610: warning: This comment starts 
with '/**', but isn't a kernel-doc comment. Refer 
Documentation/doc-guide/kernel-doc.rst
* Read network configuration from DRAM, network descriptor address
   drivers/gpu/drm/nvdla/nvdla_scheduler.c:920: warning: This comment starts 
with '/**', but isn't a kernel-doc comment. Refer 
Documentation/doc-guide/kernel-doc.rst
* Execute task selected by task scheduler
--
   drivers/gpu/drm/nvdla/nvdla_bdma.c: In function 'dla_bdma_dump_config':
>> drivers/gpu/drm/nvdla/nvdla_bdma.c:157:39: warning: variable 'bdma_surface' 
>> set but not used [-Wunused-but-set-variable]
 157 | struct dla_bdma_surface_desc *bdma_surface;
 |   ^~~~
>> drivers/gpu/drm/nvdla/nvdla_bdma.c:156:34: warning: variable 'bdma_op' set 
>> but not used [-Wunused-but-set-variable]
 156 | struct dla_bdma_op_desc *bdma_op;
 |  ^~~
--
   drivers/gpu/drm/nvdla/nvdla_conv.c: In function 'dla_conv_dump_config':
>> drivers/gpu/drm/nvdla/nvdla_conv.c:666:39: warning: var

Re: [PATCH v2 16/17] drm/msm/dpu: gracefully handle null fb commits for writeback

[Dmitry Baryshkov]

On 20/04/2022 04:46, Abhinav Kumar wrote:

kms_writeback test cases also verify with a null fb for the
writeback connector job. In addition there are also other
commit paths which can result in kickoffs without a valid
framebuffer like while closing the fb which results in the
callback to drm_atomic_helper_dirtyfb() which internally
triggers a commit.

Add protection in the dpu driver to ensure that commits for
writeback encoders without a valid fb are gracefully skipped.

changes in v2:
- rename dpu_encoder_has_valid_fb to dpu_encoder_is_valid_for_commit

Signed-off-by: Abhinav Kumar 


Reviewed-by: Dmitry Baryshkov 


---
  drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c|  9 +
  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 21 +
  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h |  6 ++
  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h|  1 +
  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c | 12 
  5 files changed, 49 insertions(+)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 7763558..d65e124 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -869,6 +869,13 @@ void dpu_crtc_commit_kickoff(struct drm_crtc *crtc)
  
  	DPU_ATRACE_BEGIN("crtc_commit");
  
+	drm_for_each_encoder_mask(encoder, crtc->dev,

+   crtc->state->encoder_mask) {
+   if (!dpu_encoder_is_valid_for_commit(encoder)) {
+   DRM_DEBUG_ATOMIC("invalid FB not kicking off crtc\n");
+   goto end;
+   }
+   }
/*
 * Encoder will flush/start now, unless it has a tx pending. If so, it
 * may delay and flush at an irq event (e.g. ppdone)
@@ -891,6 +898,8 @@ void dpu_crtc_commit_kickoff(struct drm_crtc *crtc)
dpu_encoder_kickoff(encoder);
  
  	reinit_completion(&dpu_crtc->frame_done_comp);

+
+end:
DPU_ATRACE_END("crtc_commit");
  }
  
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c

index b1475dd..d07e3ee 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -1850,6 +1850,27 @@ void dpu_encoder_prepare_for_kickoff(struct drm_encoder 
*drm_enc)
dpu_encoder_prep_dsc(dpu_enc, dpu_enc->dsc);
  }
  
+bool dpu_encoder_is_valid_for_commit(struct drm_encoder *drm_enc)

+{
+   struct dpu_encoder_virt *dpu_enc;
+   unsigned int i;
+   struct dpu_encoder_phys *phys;
+
+   dpu_enc = to_dpu_encoder_virt(drm_enc);
+
+   if (drm_enc->encoder_type == DRM_MODE_ENCODER_VIRTUAL) {
+   for (i = 0; i < dpu_enc->num_phys_encs; i++) {
+   phys = dpu_enc->phys_encs[i];
+   if (phys->ops.is_valid_for_commit && 
!phys->ops.is_valid_for_commit(phys)) {
+   DPU_DEBUG("invalid FB not kicking off\n");
+   return false;
+   }
+   }
+   }
+
+   return true;
+}
+
  void dpu_encoder_kickoff(struct drm_encoder *drm_enc)
  {
struct dpu_encoder_virt *dpu_enc;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
index 6ceec1d..781d41c 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
@@ -196,4 +196,10 @@ void dpu_encoder_prepare_wb_job(struct drm_encoder 
*drm_enc,
  void dpu_encoder_cleanup_wb_job(struct drm_encoder *drm_enc,
struct drm_writeback_job *job);
  
+/**

+ * dpu_encoder_is_valid_for_commit - check if encode has valid parameters for 
commit.
+ * @drm_enc:Pointer to drm encoder structure
+ */
+bool dpu_encoder_is_valid_for_commit(struct drm_encoder *drm_enc);
+
  #endif /* __DPU_ENCODER_H__ */
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
index 5452f98..04d037e 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
@@ -142,6 +142,7 @@ struct dpu_encoder_phys_ops {
struct drm_writeback_job *job);
void (*cleanup_wb_job)(struct dpu_encoder_phys *phys_enc,
struct drm_writeback_job *job);
+   bool (*is_valid_for_commit)(struct dpu_encoder_phys *phys_enc);
  };
  
  /**

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c
index 128317fe..9acbce0 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c
@@ -667,6 +667,16 @@ static void dpu_encoder_phys_wb_cleanup_wb_job(struct 
dpu_encoder_phys *phys_enc
wb_enc->wb_conn = NULL;
  }
  
+static bool dpu_encoder_phys_wb_is_valid_for_commit(struct dpu_encoder_phys *ph

Re: [PATCH] drm/exynos: fix IS_ERR() vs NULL check in probe

[Inki Dae]

Hi,

22. 4. 12. 13:19에 Dan Carpenter 이(가) 쓴 글:
> On Tue, Apr 12, 2022 at 10:01:20AM +0900, Inki Dae wrote:
>> Hi Dan Carpenter.
>>
>> Same patch[1] was posted so I will pick it up. 
>>
>> [1] 
>> https://protect2.fireeye.com/v1/url?k=94e9d569-f562c05f-94e85e26-000babff9b5d-4d4f5b20cfffa24c&q=1&e=727c2c54-2082-4e0f-87d7-c6702bf4c81e&u=https%3A%2F%2Fwww.spinics.net%2Flists%2Farm-kernel%2Fmsg967488.html
>>  
>>
> 
> It's not the same.  That one returns -EINVAL and mine returns
> -EPROBE_DEFER.  I obvoiously thought that -EPROBE_DEFER was the correct
> return but I wasn't positive.  -EPROBE_DEFER is kind of a special
> return so I think it matters to get this correct.
> 

Correct so I requested[1] him to fix it but the delivery failed. :( I will just 
pick your patch up. :)
[Delivery Failure] Re: [PATCH -next] drm/exynos: mic: fix return value check in 
exynos_mic_probe().

[1] My email sent below,

22. 4. 6. 18:22에 Yang Yingliang 이(가) 쓴 글:
 > If of_graph_get_remote_node() fails, it returns NULL pointer, replaces
 > IS_ERR() check with NULL pointer check.
 >
 > Fixes: dd8b6803bc49 ("exynos: drm: dsi: Attach in_bridge in MIC driver")
 > Reported-by: Hulk Robot 
 > Signed-off-by: Yang Yingliang 
 > ---
 > drivers/gpu/drm/exynos/exynos_drm_mic.c | 4 ++--
 > 1 file changed, 2 insertions(+), 2 deletions(-)
 >
 > diff --git a/drivers/gpu/drm/exynos/exynos_drm_mic.c 
b/drivers/gpu/drm/exynos/exynos_drm_mic.c
 > index 9e06f8e2a863..43fc357a6682 100644
 > --- a/drivers/gpu/drm/exynos/exynos_drm_mic.c
 > +++ b/drivers/gpu/drm/exynos/exynos_drm_mic.c
 > @@ -434,9 +434,9 @@ static int exynos_mic_probe(struct platform_device *pdev)
 >
 > remote = of_graph_get_remote_node(dev->of_node, 1, 0);
 > mic->next_bridge = of_drm_find_bridge(remote);
 > - if (IS_ERR(mic->next_bridge)) {
 > + if (!mic->next_bridge) {
 > DRM_DEV_ERROR(dev, "mic: Failed to find next bridge\n");
 > - ret = PTR_ERR(mic->next_bridge);
 > + ret = -EINVAL;

-EPROBE_DEFER should be returned instead. Could you modify and resend it again?

> regards,
> dan carpenter
> 
> 

Re: [PATCH v2] drm/vc4: Fix pm_runtime_get_sync() usage

[Miaoqian Lin]

On 2022/4/20 15:51, Maxime Ripard wrote:
> On Wed, Apr 20, 2022 at 12:49:48AM +, Miaoqian Lin wrote:
>> If the device is already in a runtime PM enabled state
>> pm_runtime_get_sync() will return 1, so a test for negative
>> value should be used to check for errors.
>>
>> Also, we need to call pm_runtime_put_noidle() when pm_runtime_get_sync()
>> fails, so use pm_runtime_resume_and_get() instead. this function
>> will handle this.
>>
>> Fixes: 4078f5757144 ("drm/vc4: Add DSI driver")
>> Signed-off-by: Miaoqian Lin 
>> ---
>> change in v2:
>> - switch to pm_runtime_resume_and_get() to fix refcount leak.
>> ---
>>  drivers/gpu/drm/vc4/vc4_dsi.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/vc4/vc4_dsi.c b/drivers/gpu/drm/vc4/vc4_dsi.c
>> index 752f921735c6..9d7ffaf6bc70 100644
>> --- a/drivers/gpu/drm/vc4/vc4_dsi.c
>> +++ b/drivers/gpu/drm/vc4/vc4_dsi.c
>> @@ -846,8 +846,8 @@ static void vc4_dsi_encoder_enable(struct drm_encoder 
>> *encoder)
>>  unsigned long phy_clock;
>>  int ret;
>>  
>> -ret = pm_runtime_get_sync(dev);
>> -if (ret) {
>> +ret = pm_runtime_resume_and_get(dev);
>> +if (ret < 0) {
> pm_runtime_resume_and_get will return 0 on success, so the previous check was 
> correct

previous check is for pm_runtime_get_sync() not for pm_runtime_resume_and_get 
(),

I switch to pm_runtime_resume_and_get() to fix the refcount leak bug at the 
same time.

Sure it's ok to use check if(ret) to check the retval, I just follow a more 
common way

for usage of pm_runtime_resume_and_get() in the codebase—— check ret<0

Since pm_runtime_resume_and_get() return negative error code.

> Maxime

Re: (subset) [PATCH 1/2] drm/panel/raspberrypi-touchscreen: Avoid NULL deref if not initialised

[Maxime Ripard]

On Fri, 15 Apr 2022 18:25:12 +0200, Stefan Wahren wrote:
> From: Dave Stevenson 
> 
> If a call to rpi_touchscreen_i2c_write from rpi_touchscreen_probe
> fails before mipi_dsi_device_register_full is called, then
> in trying to log the error message if uses ts->dsi->dev when
> it is still NULL.
> 
> [...]

Applied to drm/drm-misc (drm-misc-fixes).

Thanks!
Maxime

Re: (subset) [PATCH 2/2] drm/panel/raspberrypi-touchscreen: Initialise the bridge in prepare

[Maxime Ripard]

On Fri, 15 Apr 2022 18:25:13 +0200, Stefan Wahren wrote:
> From: Dave Stevenson 
> 
> The panel has a prepare call which is before video starts, and an
> enable call which is after.
> The Toshiba bridge should be configured before video, so move
> the relevant power and initialisation calls to prepare.
> 
> [...]

Applied to drm/drm-misc (drm-misc-fixes).

Thanks!
Maxime

Re: (subset) [PATCH v3 -next] drm/vc4: Fix build error when CONFIG_DRM_VC4=y && CONFIG_RASPBERRYPI_FIRMWARE=m

[Maxime Ripard]

On Mon, 11 Apr 2022 10:43:25 +0800, Zheng Bin wrote:
> If CONFIG_DRM_VC4=y, CONFIG_RASPBERRYPI_FIRMWARE=m, CONFIG_COMPILE_TEST=n,
> bulding fails:
> 
> drivers/gpu/drm/vc4/vc4_drv.o: In function `vc4_drm_bind':
> vc4_drv.c:(.text+0x320): undefined reference to `rpi_firmware_get'
> vc4_drv.c:(.text+0x320): relocation truncated to fit: R_AARCH64_CALL26 
> against undefined symbol `rpi_firmware_get'
> vc4_drv.c:(.text+0x34c): undefined reference to `rpi_firmware_property'
> vc4_drv.c:(.text+0x34c): relocation truncated to fit: R_AARCH64_CALL26 
> against undefined symbol `rpi_firmware_property'
> vc4_drv.c:(.text+0x354): undefined reference to `rpi_firmware_put'
> vc4_drv.c:(.text+0x354): relocation truncated to fit: R_AARCH64_CALL26 
> against undefined symbol `rpi_firmware_put'
> 
> [...]

Applied to drm/drm-misc (drm-misc-fixes).

Thanks!
Maxime

[PATCH v3 0/5] Fix some race conditions that exists between fbmem and sysfb

[Javier Martinez Canillas]

Hello,

The patches in this series are mostly changes suggested by Daniel Vetter
to fix some race conditions that exists between the fbdev core (fbmem)
and sysfb with regard to device registration and removal.

For example, it is currently possible for sysfb to register a platform
device after a real DRM driver was registered and requested to remove the
conflicting framebuffers.

A symptom of this issue, was worked around with by commit fb561bf9abde
("fbdev: Prevent probing generic drivers if a FB is already registered")
but that's really a hack and should be reverted.

This series attempt to fix it more properly and revert the mentioned hack.
That will also unblock a pending patch to not make the num_registered_fb
variable visible to drivers anymore, since that's internal to fbdev core.

Patch #1 is just a trivial preparatory change.

Patch #2 add sysfb_disable() and sysfb_try_unregister() helpers for fbmem
to use them.

Patch #3 changes how is dealt with conflicting framebuffers unregistering,
rather than having a variable to determine if a lock should be take, it
just drops the lock before unregistering the platform device.

Patch #4 fixes the mentioned race conditions and finally patch #5 is the
revert patch that was posted by Daniel before but he dropped from his set.

The patches were tested on a rpi4 using different video configurations:
(simpledrm -> vc4 both builtin, only vc4 builtin, only simpledrm builtin
and simpledrm builtin with vc4 built as a module).

Best regards,
Javier

Changes in v3:
- Rebase on top of latest drm-misc-next branch.

Changes in v2:
- Rebase on top of latest drm-misc-next and fix conflicts (Daniel Vetter).
- Add kernel-doc comments and include in other_interfaces.rst (Daniel Vetter).
- Explain in the commit message that fbmem has to unregister the device
  as fallback if a driver registered the device itself (Daniel Vetter).
- Also explain that fallback in a comment in the code (Daniel Vetter).
- Don't encode in fbmem the assumption that sysfb will always register
  platform devices (Daniel Vetter).
- Add a FIXME comment about drivers registering devices (Daniel Vetter).
- Drop RFC prefix since patches were already reviewed by Daniel Vetter.
- Add Daniel Reviewed-by tags to the patches.

Daniel Vetter (1):
  Revert "fbdev: Prevent probing generic drivers if a FB is already
registered"

Javier Martinez Canillas (4):
  firmware: sysfb: Make sysfb_create_simplefb() return a pdev pointer
  firmware: sysfb: Add helpers to unregister a pdev and disable
registration
  fbdev: Restart conflicting fb removal loop when unregistering devices
  fbdev: Fix some race conditions between fbmem and sysfb

 .../driver-api/firmware/other_interfaces.rst  |  6 ++
 drivers/firmware/sysfb.c  | 77 +--
 drivers/firmware/sysfb_simplefb.c | 16 ++--
 drivers/video/fbdev/core/fbmem.c  | 62 ---
 drivers/video/fbdev/efifb.c   | 11 ---
 drivers/video/fbdev/simplefb.c| 11 ---
 include/linux/fb.h|  1 -
 include/linux/sysfb.h | 29 +--
 8 files changed, 158 insertions(+), 55 deletions(-)

-- 
2.35.1

[PATCH v3 1/5] firmware: sysfb: Make sysfb_create_simplefb() return a pdev pointer

[Javier Martinez Canillas]

This function just returned 0 on success or an errno code on error, but it
could be useful for sysfb_init() callers to have a pointer to the device.

Signed-off-by: Javier Martinez Canillas 
Reviewed-by: Daniel Vetter 
---

(no changes since v2)

Changes in v2:
- Rebase on top of latest drm-misc-next and fix conflicts (Daniel Vetter).

 drivers/firmware/sysfb.c  |  4 ++--
 drivers/firmware/sysfb_simplefb.c | 16 
 include/linux/sysfb.h | 10 +-
 3 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/drivers/firmware/sysfb.c b/drivers/firmware/sysfb.c
index 2bfbb05f7d89..b032f40a92de 100644
--- a/drivers/firmware/sysfb.c
+++ b/drivers/firmware/sysfb.c
@@ -46,8 +46,8 @@ static __init int sysfb_init(void)
/* try to create a simple-framebuffer device */
compatible = sysfb_parse_mode(si, &mode);
if (compatible) {
-   ret = sysfb_create_simplefb(si, &mode);
-   if (!ret)
+   pd = sysfb_create_simplefb(si, &mode);
+   if (!IS_ERR(pd))
return 0;
}
 
diff --git a/drivers/firmware/sysfb_simplefb.c 
b/drivers/firmware/sysfb_simplefb.c
index bda8712bfd8c..a353e27f83f5 100644
--- a/drivers/firmware/sysfb_simplefb.c
+++ b/drivers/firmware/sysfb_simplefb.c
@@ -57,8 +57,8 @@ __init bool sysfb_parse_mode(const struct screen_info *si,
return false;
 }
 
-__init int sysfb_create_simplefb(const struct screen_info *si,
-const struct simplefb_platform_data *mode)
+__init struct platform_device *sysfb_create_simplefb(const struct screen_info 
*si,
+const struct 
simplefb_platform_data *mode)
 {
struct platform_device *pd;
struct resource res;
@@ -76,7 +76,7 @@ __init int sysfb_create_simplefb(const struct screen_info *si,
base |= (u64)si->ext_lfb_base << 32;
if (!base || (u64)(resource_size_t)base != base) {
printk(KERN_DEBUG "sysfb: inaccessible VRAM base\n");
-   return -EINVAL;
+   return ERR_PTR(-EINVAL);
}
 
/*
@@ -93,7 +93,7 @@ __init int sysfb_create_simplefb(const struct screen_info *si,
length = mode->height * mode->stride;
if (length > size) {
printk(KERN_WARNING "sysfb: VRAM smaller than advertised\n");
-   return -EINVAL;
+   return ERR_PTR(-EINVAL);
}
length = PAGE_ALIGN(length);
 
@@ -104,11 +104,11 @@ __init int sysfb_create_simplefb(const struct screen_info 
*si,
res.start = base;
res.end = res.start + length - 1;
if (res.end <= res.start)
-   return -EINVAL;
+   return ERR_PTR(-EINVAL);
 
pd = platform_device_alloc("simple-framebuffer", 0);
if (!pd)
-   return -ENOMEM;
+   return ERR_PTR(-ENOMEM);
 
sysfb_apply_efi_quirks(pd);
 
@@ -124,10 +124,10 @@ __init int sysfb_create_simplefb(const struct screen_info 
*si,
if (ret)
goto err_put_device;
 
-   return 0;
+   return pd;
 
 err_put_device:
platform_device_put(pd);
 
-   return ret;
+   return ERR_PTR(ret);
 }
diff --git a/include/linux/sysfb.h b/include/linux/sysfb.h
index b0dcfa26d07b..708152e9037b 100644
--- a/include/linux/sysfb.h
+++ b/include/linux/sysfb.h
@@ -72,8 +72,8 @@ static inline void sysfb_apply_efi_quirks(struct 
platform_device *pd)
 
 bool sysfb_parse_mode(const struct screen_info *si,
  struct simplefb_platform_data *mode);
-int sysfb_create_simplefb(const struct screen_info *si,
- const struct simplefb_platform_data *mode);
+struct platform_device *sysfb_create_simplefb(const struct screen_info *si,
+ const struct 
simplefb_platform_data *mode);
 
 #else /* CONFIG_SYSFB_SIMPLE */
 
@@ -83,10 +83,10 @@ static inline bool sysfb_parse_mode(const struct 
screen_info *si,
return false;
 }
 
-static inline int sysfb_create_simplefb(const struct screen_info *si,
-const struct simplefb_platform_data 
*mode)
+static inline struct platform_device *sysfb_create_simplefb(const struct 
screen_info *si,
+   const struct 
simplefb_platform_data *mode)
 {
-   return -EINVAL;
+   return ERR_PTR(-EINVAL);
 }
 
 #endif /* CONFIG_SYSFB_SIMPLE */
-- 
2.35.1

[PATCH v3 3/5] fbdev: Restart conflicting fb removal loop when unregistering devices

[Javier Martinez Canillas]

Drivers that want to remove registered conflicting framebuffers prior to
register their own framebuffer, calls remove_conflicting_framebuffers().

This function takes the registration_lock mutex, to prevent a races when
drivers register framebuffer devices. But if a conflicting framebuffer
device is found, the underlaying platform device is unregistered and this
will lead to the platform driver .remove callback to be called, which in
turn will call to the unregister_framebuffer() that takes the same lock.

To prevent this, a struct fb_info.forced_out field was used as indication
to unregister_framebuffer() whether the mutex has to be grabbed or not.

A cleaner solution is to drop the lock before platform_device_unregister()
so unregister_framebuffer() can take it when called from the fbdev driver,
and just grab the lock again after the device has been registered and do
a removal loop restart.

Since the framebuffer devices will already be removed, the loop would just
finish when no more conflicting framebuffers are found.

Suggested-by: Daniel Vetter 
Signed-off-by: Javier Martinez Canillas 
Reviewed-by: Daniel Vetter 
---

(no changes since v1)

 drivers/video/fbdev/core/fbmem.c | 22 +++---
 include/linux/fb.h   |  1 -
 2 files changed, 15 insertions(+), 8 deletions(-)

diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 84427470367b..0bb459258df3 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -1553,6 +1553,7 @@ static void do_remove_conflicting_framebuffers(struct 
apertures_struct *a,
 {
int i;
 
+restart_removal:
/* check all firmware fbs and kick off if the base addr overlaps */
for_each_registered_fb(i) {
struct apertures_struct *gen_aper;
@@ -1585,12 +1586,23 @@ static void do_remove_conflicting_framebuffers(struct 
apertures_struct *a,
pr_warn("fb%d: no device set\n", i);
do_unregister_framebuffer(registered_fb[i]);
} else if (dev_is_platform(device)) {
-   registered_fb[i]->forced_out = true;
+   /*
+* Drop the lock because if the device is 
unregistered, its
+* driver will call to 
unregister_framebuffer(), that takes
+* this lock.
+*/
+   mutex_unlock(®istration_lock);

platform_device_unregister(to_platform_device(device));
+   mutex_lock(®istration_lock);
} else {
pr_warn("fb%d: cannot remove device\n", i);
do_unregister_framebuffer(registered_fb[i]);
}
+   /*
+* Restart the removal loop now that the device has been
+* unregistered and its associated framebuffer gone.
+*/
+   goto restart_removal;
}
}
 }
@@ -1897,13 +1909,9 @@ EXPORT_SYMBOL(register_framebuffer);
 void
 unregister_framebuffer(struct fb_info *fb_info)
 {
-   bool forced_out = fb_info->forced_out;
-
-   if (!forced_out)
-   mutex_lock(®istration_lock);
+   mutex_lock(®istration_lock);
do_unregister_framebuffer(fb_info);
-   if (!forced_out)
-   mutex_unlock(®istration_lock);
+   mutex_unlock(®istration_lock);
 }
 EXPORT_SYMBOL(unregister_framebuffer);
 
diff --git a/include/linux/fb.h b/include/linux/fb.h
index f95da1af9ff6..b781bc721113 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -502,7 +502,6 @@ struct fb_info {
} *apertures;
 
bool skip_vt_switch; /* no VT switch on suspend/resume required */
-   bool forced_out; /* set when being removed by another driver */
 };
 
 static inline struct apertures_struct *alloc_apertures(unsigned int max_num) {
-- 
2.35.1

[PATCH v3 2/5] firmware: sysfb: Add helpers to unregister a pdev and disable registration

[Javier Martinez Canillas]

These can be used by subsystems to unregister a platform device registered
by sysfb and also to disable future platform device registration in sysfb.

Suggested-by: Daniel Vetter 
Signed-off-by: Javier Martinez Canillas 
Reviewed-by: Daniel Vetter 
---

(no changes since v2)

Changes in v2:
- Add kernel-doc comments and include in other_interfaces.rst (Daniel Vetter).

 .../driver-api/firmware/other_interfaces.rst  |  6 ++
 drivers/firmware/sysfb.c  | 73 +--
 include/linux/sysfb.h | 19 +
 3 files changed, 92 insertions(+), 6 deletions(-)

diff --git a/Documentation/driver-api/firmware/other_interfaces.rst 
b/Documentation/driver-api/firmware/other_interfaces.rst
index b81794e0cfbb..06ac89adaafb 100644
--- a/Documentation/driver-api/firmware/other_interfaces.rst
+++ b/Documentation/driver-api/firmware/other_interfaces.rst
@@ -13,6 +13,12 @@ EDD Interfaces
 .. kernel-doc:: drivers/firmware/edd.c
:internal:
 
+Generic System Framebuffers Interface
+-
+
+.. kernel-doc:: drivers/firmware/sysfb.c
+   :export:
+
 Intel Stratix10 SoC Service Layer
 -
 Some features of the Intel Stratix10 SoC require a level of privilege
diff --git a/drivers/firmware/sysfb.c b/drivers/firmware/sysfb.c
index b032f40a92de..a50d2858ce4d 100644
--- a/drivers/firmware/sysfb.c
+++ b/drivers/firmware/sysfb.c
@@ -34,21 +34,78 @@
 #include 
 #include 
 
+static struct platform_device *pd;
+static DEFINE_MUTEX(load_lock);
+static bool disabled;
+
+/**
+ * sysfb_disable() - disable the Generic System Framebuffers support
+ *
+ * This disables the registration of system framebuffer devices that match the
+ * generic drivers that make use of the system framebuffer set up by firmware.
+ *
+ * Context: The function can sleep. A @load_lock mutex is acquired to serialize
+ *  against sysfb_init(), that registers a system framebuffer device 
and
+ *  sysfb_try_unregister(), that tries to unregister framebuffer 
devices.
+ */
+void sysfb_disable(void)
+{
+   mutex_lock(&load_lock);
+   disabled = true;
+   mutex_unlock(&load_lock);
+}
+EXPORT_SYMBOL_GPL(sysfb_disable);
+
+/**
+ * sysfb_try_unregister() - attempt to unregister a system framebuffer device
+ * @dev: device to unregister
+ *
+ * This tries to unregister a system framebuffer device if this was registered
+ * by the Generic System Framebuffers. The device will only be unregistered if
+ * it was registered by sysfb_init(), otherwise it will not be unregistered.
+ *
+ * Context: The function can sleep. a @load_lock mutex is acquired to serialize
+ *  against sysfb_init(), that registers a simple framebuffer device 
and
+ *  sysfb_disable(), that disables the Generic System Framebuffers 
support.
+ *
+ * Return:
+ * * true  - the device was unregistered successfully
+ * * false - the device was not unregistered
+ */
+bool sysfb_try_unregister(struct device *dev)
+{
+   bool ret = true;
+
+   mutex_lock(&load_lock);
+   if (!pd || pd != to_platform_device(dev))
+   return false;
+
+   platform_device_unregister(to_platform_device(dev));
+   pd = NULL;
+   mutex_unlock(&load_lock);
+
+   return ret;
+}
+EXPORT_SYMBOL_GPL(sysfb_try_unregister);
+
 static __init int sysfb_init(void)
 {
struct screen_info *si = &screen_info;
struct simplefb_platform_data mode;
-   struct platform_device *pd;
const char *name;
bool compatible;
-   int ret;
+   int ret = 0;
+
+   mutex_lock(&load_lock);
+   if (disabled)
+   goto unlock_mutex;
 
/* try to create a simple-framebuffer device */
compatible = sysfb_parse_mode(si, &mode);
if (compatible) {
pd = sysfb_create_simplefb(si, &mode);
if (!IS_ERR(pd))
-   return 0;
+   goto unlock_mutex;
}
 
/* if the FB is incompatible, create a legacy framebuffer device */
@@ -60,8 +117,10 @@ static __init int sysfb_init(void)
name = "platform-framebuffer";
 
pd = platform_device_alloc(name, 0);
-   if (!pd)
-   return -ENOMEM;
+   if (!pd) {
+   ret = -ENOMEM;
+   goto unlock_mutex;
+   }
 
sysfb_apply_efi_quirks(pd);
 
@@ -73,9 +132,11 @@ static __init int sysfb_init(void)
if (ret)
goto err;
 
-   return 0;
+   goto unlock_mutex;
 err:
platform_device_put(pd);
+unlock_mutex:
+   mutex_unlock(&load_lock);
return ret;
 }
 
diff --git a/include/linux/sysfb.h b/include/linux/sysfb.h
index 708152e9037b..e8c0313fac8f 100644
--- a/include/linux/sysfb.h
+++ b/include/linux/sysfb.h
@@ -55,6 +55,25 @@ struct efifb_dmi_info {
int flags;
 };
 
+#ifdef CONFIG_SYSFB
+
+void sysfb_disable(void);
+bool sysfb_try_unregister(struct device *dev);
+
+#

[PATCH v3 4/5] fbdev: Fix some race conditions between fbmem and sysfb

[Javier Martinez Canillas]

The platform devices registered in sysfb match with a firmware-based fbdev
or DRM driver, that are used to have early graphics using framebuffers set
up by the system firmware.

Real DRM drivers later are probed and remove all conflicting framebuffers,
leading to these platform devices for generic drivers to be unregistered.

But the current solution has two issues that this patch fixes:

1) It is a layering violation for the fbdev core to unregister a device
   that was registered by sysfb.

   Instead, the sysfb_try_unregister() helper function can be called for
   sysfb to attempt unregistering the device if is the one registered.

2) The sysfb_init() function could be called after a DRM driver is probed
   and requested to unregister devices for drivers with a conflicting fb.

   To prevent this, disable any future sysfb platform device registration
   by calling sysfb_disable(), if a driver requested to remove conflicting
   framebuffers with remove_conflicting_framebuffers().

There are video drivers (e.g: vga16fb) that register their own device and
don't use the sysfb infrastructure for that, so an unregistration has to
be forced by fbmem if sysfb_try_unregister() fails to do the unregister.

Suggested-by: Daniel Vetter 
Signed-off-by: Javier Martinez Canillas 
Reviewed-by: Daniel Vetter 
---

(no changes since v2)

Changes in v2:
- Explain in the commit message that fbmem has to unregister the device
  as fallback if a driver registered the device itself (Daniel Vetter).
- Also explain that fallback in a comment in the code (Daniel Vetter).
- Don't encode in fbmem the assumption that sysfb will always register
  platform devices (Daniel Vetter).
- Add a FIXME comment about drivers registering devices (Daniel Vetter).

 drivers/video/fbdev/core/fbmem.c | 42 
 1 file changed, 37 insertions(+), 5 deletions(-)

diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 0bb459258df3..8098305879f8 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1585,18 +1586,38 @@ static void do_remove_conflicting_framebuffers(struct 
apertures_struct *a,
if (!device) {
pr_warn("fb%d: no device set\n", i);
do_unregister_framebuffer(registered_fb[i]);
-   } else if (dev_is_platform(device)) {
+   } else {
/*
 * Drop the lock because if the device is 
unregistered, its
 * driver will call to 
unregister_framebuffer(), that takes
 * this lock.
 */
mutex_unlock(®istration_lock);
-   
platform_device_unregister(to_platform_device(device));
+   /*
+* First attempt the device to be unregistered 
by sysfb.
+*/
+   if (!sysfb_try_unregister(device)) {
+   if (dev_is_platform(device)) {
+   /*
+* FIXME: sysfb didn't register 
this device, is a platform
+* device registered by a video 
driver (e.g: vga16fb), so
+* force its unregistration 
here. A proper fix would be to
+* move all device registration 
to the sysfb infrastructure
+* or platform code.
+*/
+   
platform_device_unregister(to_platform_device(device));
+   } else {
+   /*
+* If is not a platform device, 
at least print a warning. A
+* fix would add to make the 
code that registered the device
+* to also unregister it.
+*/
+   pr_warn("fb%d: cannot remove 
device\n", i);
+   /* call 
unregister_framebuffer() since the lock was dropped */
+   
unregister_framebuffer(registered_fb[i]);
+   }
+   }
mutex_lock(®istration_lock);
-   } else {
-   pr_warn("fb%d: cannot remove device\n"

[PATCH] drm/ttm: fix ttm tt init fail when size exceeds kmalloc limit

[Yang Wang]

if the __GFP_ZERO is set, the kvmalloc() can't fallback to use vmalloc()
to allocate memory, when request size is exceeds kmalloc limit, it will
cause allocate memory fail.

e.g: when ttm want to create a BO with 1TB size, it maybe fail.

Signed-off-by: Yang Wang 
---
 drivers/gpu/drm/ttm/ttm_tt.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index 79c870a3bef8..9f2f3e576b8d 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -97,9 +97,12 @@ int ttm_tt_create(struct ttm_buffer_object *bo, bool 
zero_alloc)
 static int ttm_tt_alloc_page_directory(struct ttm_tt *ttm)
 {
ttm->pages = kvmalloc_array(ttm->num_pages, sizeof(void*),
-   GFP_KERNEL | __GFP_ZERO);
+   GFP_KERNEL);
if (!ttm->pages)
return -ENOMEM;
+
+   memset(ttm->pages, 0, ttm->num_pages * sizeof(void *));
+
return 0;
 }
 
@@ -108,10 +111,12 @@ static int ttm_dma_tt_alloc_page_directory(struct ttm_tt 
*ttm)
ttm->pages = kvmalloc_array(ttm->num_pages,
sizeof(*ttm->pages) +
sizeof(*ttm->dma_address),
-   GFP_KERNEL | __GFP_ZERO);
+   GFP_KERNEL);
if (!ttm->pages)
return -ENOMEM;
 
+   memset(ttm->pages, 0, ttm->num_pages * (sizeof(*ttm->pages) + 
sizeof(*ttm->dma_address)));
+
ttm->dma_address = (void *)(ttm->pages + ttm->num_pages);
return 0;
 }
@@ -120,9 +125,12 @@ static int ttm_sg_tt_alloc_page_directory(struct ttm_tt 
*ttm)
 {
ttm->dma_address = kvmalloc_array(ttm->num_pages,
  sizeof(*ttm->dma_address),
- GFP_KERNEL | __GFP_ZERO);
+ GFP_KERNEL);
if (!ttm->dma_address)
return -ENOMEM;
+
+   memset(ttm->dma_address, 0, ttm->num_pages * sizeof(*ttm->dma_address));
+
return 0;
 }
 
-- 
2.25.1

Re: [PATCH] drm/ttm: fix ttm tt init fail when size exceeds kmalloc limit

[Christian König]

Am 20.04.22 um 10:56 schrieb Yang Wang:

if the __GFP_ZERO is set, the kvmalloc() can't fallback to use vmalloc()


Hui what? Why should kvmalloc() not be able to fallback to vmalloc() 
when __GFP_ZERO is set?


And even that is really the case then that sounds like a bug in kvmalloc().

Regards,
Christian.


to allocate memory, when request size is exceeds kmalloc limit, it will
cause allocate memory fail.

e.g: when ttm want to create a BO with 1TB size, it maybe fail.

Signed-off-by: Yang Wang 
---
  drivers/gpu/drm/ttm/ttm_tt.c | 14 +++---
  1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index 79c870a3bef8..9f2f3e576b8d 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -97,9 +97,12 @@ int ttm_tt_create(struct ttm_buffer_object *bo, bool 
zero_alloc)
  static int ttm_tt_alloc_page_directory(struct ttm_tt *ttm)
  {
ttm->pages = kvmalloc_array(ttm->num_pages, sizeof(void*),
-   GFP_KERNEL | __GFP_ZERO);
+   GFP_KERNEL);
if (!ttm->pages)
return -ENOMEM;
+
+   memset(ttm->pages, 0, ttm->num_pages * sizeof(void *));
+
return 0;
  }
  
@@ -108,10 +111,12 @@ static int ttm_dma_tt_alloc_page_directory(struct ttm_tt *ttm)

ttm->pages = kvmalloc_array(ttm->num_pages,
sizeof(*ttm->pages) +
sizeof(*ttm->dma_address),
-   GFP_KERNEL | __GFP_ZERO);
+   GFP_KERNEL);
if (!ttm->pages)
return -ENOMEM;
  
+	memset(ttm->pages, 0, ttm->num_pages * (sizeof(*ttm->pages) + sizeof(*ttm->dma_address)));

+
ttm->dma_address = (void *)(ttm->pages + ttm->num_pages);
return 0;
  }
@@ -120,9 +125,12 @@ static int ttm_sg_tt_alloc_page_directory(struct ttm_tt 
*ttm)
  {
ttm->dma_address = kvmalloc_array(ttm->num_pages,
  sizeof(*ttm->dma_address),
- GFP_KERNEL | __GFP_ZERO);
+ GFP_KERNEL);
if (!ttm->dma_address)
return -ENOMEM;
+
+   memset(ttm->dma_address, 0, ttm->num_pages * sizeof(*ttm->dma_address));
+
return 0;
  }
  

Re: [PATCH] drm/ttm: fix ttm tt init fail when size exceeds kmalloc limit

[Wang, Yang(Kevin)]

[AMD Official Use Only]



From: Koenig, Christian 
Sent: Wednesday, April 20, 2022 5:00 PM
To: Wang, Yang(Kevin) ; dri-devel@lists.freedesktop.org 
; amd-...@lists.freedesktop.org 

Subject: Re: [PATCH] drm/ttm: fix ttm tt init fail when size exceeds kmalloc 
limit

Am 20.04.22 um 10:56 schrieb Yang Wang:
> if the __GFP_ZERO is set, the kvmalloc() can't fallback to use vmalloc()

Hui what? Why should kvmalloc() not be able to fallback to vmalloc()
when __GFP_ZERO is set?

And even that is really the case then that sounds like a bug in kvmalloc().

Regards,
Christian.

[kevin]:
it is really test case from libdrm amdgpu test, which try to allocate a big BO 
which will cause ttm tt init fail.
it may be a kvmalloc() bug, and this patch can as a workaround in ttm before 
this issue fix.

void *kvmalloc_node(size_t size, gfp_t flags, int node)
{
...
if ((flags & GFP_KERNEL) != GFP_KERNEL)
return kmalloc_node(size, flags, node);
...
}

Best Regards,
Kevin

> to allocate memory, when request size is exceeds kmalloc limit, it will
> cause allocate memory fail.
>
> e.g: when ttm want to create a BO with 1TB size, it maybe fail.
>
> Signed-off-by: Yang Wang 
> ---
>   drivers/gpu/drm/ttm/ttm_tt.c | 14 +++---
>   1 file changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
> index 79c870a3bef8..9f2f3e576b8d 100644
> --- a/drivers/gpu/drm/ttm/ttm_tt.c
> +++ b/drivers/gpu/drm/ttm/ttm_tt.c
> @@ -97,9 +97,12 @@ int ttm_tt_create(struct ttm_buffer_object *bo, bool 
> zero_alloc)
>   static int ttm_tt_alloc_page_directory(struct ttm_tt *ttm)
>   {
>ttm->pages = kvmalloc_array(ttm->num_pages, sizeof(void*),
> - GFP_KERNEL | __GFP_ZERO);
> + GFP_KERNEL);
>if (!ttm->pages)
>return -ENOMEM;
> +
> + memset(ttm->pages, 0, ttm->num_pages * sizeof(void *));
> +
>return 0;
>   }
>
> @@ -108,10 +111,12 @@ static int ttm_dma_tt_alloc_page_directory(struct 
> ttm_tt *ttm)
>ttm->pages = kvmalloc_array(ttm->num_pages,
>sizeof(*ttm->pages) +
>sizeof(*ttm->dma_address),
> - GFP_KERNEL | __GFP_ZERO);
> + GFP_KERNEL);
>if (!ttm->pages)
>return -ENOMEM;
>
> + memset(ttm->pages, 0, ttm->num_pages * (sizeof(*ttm->pages) + 
> sizeof(*ttm->dma_address)));
> +
>ttm->dma_address = (void *)(ttm->pages + ttm->num_pages);
>return 0;
>   }
> @@ -120,9 +125,12 @@ static int ttm_sg_tt_alloc_page_directory(struct ttm_tt 
> *ttm)
>   {
>ttm->dma_address = kvmalloc_array(ttm->num_pages,
>  sizeof(*ttm->dma_address),
> -   GFP_KERNEL | __GFP_ZERO);
> +   GFP_KERNEL);
>if (!ttm->dma_address)
>return -ENOMEM;
> +
> + memset(ttm->dma_address, 0, ttm->num_pages * sizeof(*ttm->dma_address));
> +
>return 0;
>   }
>

Re: [Intel-gfx] [PATCH] drm/i915: Fix race in __i915_vma_remove_closed

[kernel test robot]

Hi Karol,

I love your patch! Perhaps something to improve:

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

url:
https://github.com/intel-lab-lkp/linux/commits/Karol-Herbst/drm-i915-Fix-race-in-__i915_vma_remove_closed/20220420-074525
base:   git://anongit.freedesktop.org/drm/drm-tip drm-tip
config: i386-randconfig-a013 
(https://download.01.org/0day-ci/archive/20220420/202204201724.hgr7l8yu-...@intel.com/config)
compiler: clang version 15.0.0 (https://github.com/llvm/llvm-project 
bac6cd5bf85669e3376610cfc4c4f9ca015e7b9b)
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# 
https://github.com/intel-lab-lkp/linux/commit/50a17180127b7d2527ee9a8f5c9e8207e158afb6
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review 
Karol-Herbst/drm-i915-Fix-race-in-__i915_vma_remove_closed/20220420-074525
git checkout 50a17180127b7d2527ee9a8f5c9e8207e158afb6
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 
O=build_dir ARCH=i386 SHELL=/bin/bash drivers/gpu/drm/i915/

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

All warnings (new ones prefixed by >>):

>> drivers/gpu/drm/i915/i915_vma.c:1654:19: warning: mixing declarations and 
>> code is incompatible with standards before C99 
>> [-Wdeclaration-after-statement]
   struct intel_gt *gt = vma->vm->gt;
^
   1 warning generated.


vim +1654 drivers/gpu/drm/i915/i915_vma.c

  1640  
  1641  static void release_references(struct i915_vma *vma, bool vm_ddestroy)
  1642  {
  1643  struct drm_i915_gem_object *obj = vma->obj;
  1644  
  1645  GEM_BUG_ON(i915_vma_is_active(vma));
  1646  
  1647  spin_lock(&obj->vma.lock);
  1648  list_del(&vma->obj_link);
  1649  if (!RB_EMPTY_NODE(&vma->obj_node))
  1650  rb_erase(&vma->obj_node, &obj->vma.tree);
  1651  
  1652  spin_unlock(&obj->vma.lock);
  1653  
> 1654  struct intel_gt *gt = vma->vm->gt;
  1655  
  1656  spin_lock_irq(>->closed_lock);
  1657  __i915_vma_remove_closed(vma);
  1658  spin_unlock_irq(>->closed_lock);
  1659  
  1660  if (vm_ddestroy)
  1661  i915_vm_resv_put(vma->vm);
  1662  
  1663  i915_active_fini(&vma->active);
  1664  GEM_WARN_ON(vma->resource);
  1665  i915_vma_free(vma);
  1666  }
  1667  

-- 
0-DAY CI Kernel Test Service
https://01.org/lkp

Re: [PATCH 01/41] video: fbdev: omapfb: lcd_ams_delta: fix unused variable warning

[Sergei Shtylyov]

Hello!

On 4/19/22 4:36 PM, Arnd Bergmann wrote:

> From: Arnd Bergmann 
> 
> A recent cleanup patch removed the only reference to a local variable
> in some configurations.
> 
> Move the variable into the one block it is still used in, inside
> of an #ifdef, to avoid this warning.
> 
> Fixes: 9d773f103b89 ("video: fbdev: omapfb: lcd_ams_delta: Make use of the 
> helper function dev_err_probe()")
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/video/fbdev/omap/lcd_ams_delta.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/video/fbdev/omap/lcd_ams_delta.c 
> b/drivers/video/fbdev/omap/lcd_ams_delta.c
> index bbf871f9d862..01944ce46aa1 100644
> --- a/drivers/video/fbdev/omap/lcd_ams_delta.c
> +++ b/drivers/video/fbdev/omap/lcd_ams_delta.c
[...]
> @@ -145,7 +144,7 @@ static int ams_delta_panel_probe(struct platform_device 
> *pdev)
>   &ams_delta_lcd_ops);
>  
>   if (IS_ERR(lcd_device)) {
> - ret = PTR_ERR(lcd_device);
> + int ret = PTR_ERR(lcd_device);

   How about inserting an empty line after declaration?

>   dev_err(&pdev->dev, "failed to register device\n");
>   return ret;
>   }

MBR, Sergey

[PATCH v2] drm/i915: Fix race in __i915_vma_remove_closed

[Karol Herbst]

i915_vma_reopen checked if the vma is closed before without taking the
lock. So multiple threads could attempt removing the vma.

Instead the lock needs to be taken before actually checking.

v2: move struct declaration

Cc: Chris Wilson 
Cc: intel-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5732
Signed-off-by: Karol Herbst 
---
 drivers/gpu/drm/i915/i915_vma.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 162e8d83691b..2efdad2b43fa 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -1615,17 +1615,17 @@ void i915_vma_close(struct i915_vma *vma)
 
 static void __i915_vma_remove_closed(struct i915_vma *vma)
 {
-   struct intel_gt *gt = vma->vm->gt;
-
-   spin_lock_irq(>->closed_lock);
list_del_init(&vma->closed_link);
-   spin_unlock_irq(>->closed_lock);
 }
 
 void i915_vma_reopen(struct i915_vma *vma)
 {
+   struct intel_gt *gt = vma->vm->gt;
+
+   spin_lock_irq(>->closed_lock);
if (i915_vma_is_closed(vma))
__i915_vma_remove_closed(vma);
+   spin_unlock_irq(>->closed_lock);
 }
 
 static void force_unbind(struct i915_vma *vma)
@@ -1641,6 +1641,7 @@ static void force_unbind(struct i915_vma *vma)
 static void release_references(struct i915_vma *vma, bool vm_ddestroy)
 {
struct drm_i915_gem_object *obj = vma->obj;
+   struct intel_gt *gt = vma->vm->gt;
 
GEM_BUG_ON(i915_vma_is_active(vma));
 
@@ -1651,7 +1652,9 @@ static void release_references(struct i915_vma *vma, bool 
vm_ddestroy)
 
spin_unlock(&obj->vma.lock);
 
+   spin_lock_irq(>->closed_lock);
__i915_vma_remove_closed(vma);
+   spin_unlock_irq(>->closed_lock);
 
if (vm_ddestroy)
i915_vm_resv_put(vma->vm);
-- 
2.35.1

Re: [PATCH 2/2] drm/nvdla: Add driver support for NVDLA

[kernel test robot]

Hi Cai,

I love your patch! Yet something to improve:

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

url:
https://github.com/intel-lab-lkp/linux/commits/Cai-Huoqing/drm-nvdla-Add-driver-support-for-NVDLA/20220419-220255
base:   git://anongit.freedesktop.org/drm/drm drm-next
config: m68k-allmodconfig 
(https://download.01.org/0day-ci/archive/20220420/202204201710.5gcg1puu-...@intel.com/config)
compiler: m68k-linux-gcc (GCC) 11.2.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# 
https://github.com/intel-lab-lkp/linux/commit/7539e5487eb7d0c6f13c03bba596e51a2238106d
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review 
Cai-Huoqing/drm-nvdla-Add-driver-support-for-NVDLA/20220419-220255
git checkout 7539e5487eb7d0c6f13c03bba596e51a2238106d
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross W=1 
O=build_dir ARCH=m68k SHELL=/bin/bash drivers/gpu/

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

All errors (new ones prefixed by >>):

>> make[5]: *** No rule to make target 
>> 'drivers/gpu/drm/nvdla/nvdla_engine_data.o', needed by 
>> 'drivers/gpu/drm/nvdla/nvdla-drm.o'.
>> make[5]: *** No rule to make target 
>> 'drivers/gpu/drm/nvdla/nvdla_engine_debug.o', needed by 
>> 'drivers/gpu/drm/nvdla/nvdla-drm.o'.
   make[5]: Target '__build' not remade because of errors.

-- 
0-DAY CI Kernel Test Service
https://01.org/lkp

Re: [PATCH] drm: bridge: panel: Register connector if DRM device is already registered

[Jagan Teki]

On Tue, Apr 19, 2022 at 11:08 PM Laurent Pinchart
 wrote:
>
> On Tue, Apr 19, 2022 at 06:16:07PM +0200, Robert Foss wrote:
> > On Tue, 19 Apr 2022 at 11:41, Jagan Teki  wrote:
> > >
> > > On Tue, Apr 19, 2022 at 2:44 PM Marek Szyprowski
> > >  wrote:
> > > >
> > > > If panel_bridge_attach() happens after DRM device registration, the
> > > > created connector will not be registered by the DRM core anymore. Fix
> > > > this by registering it explicitely in such case.
> > > >
> > > > This fixes the following issue observed on Samsung Exynos4210-based 
> > > > Trats
> > > > board with a DSI panel (the panel driver is registed after the Exynos 
> > > > DRM
> > > > component device is bound):
> > > >
> > > > $ ./modetest -c -Mexynos
> > > > could not get connector 56: No such file or directory
> > > > Segmentation fault
> > > >
> > > > While touching this, move the connector reset() call also under the DRM
> > > > device registered check, because otherwise it is not really needed.
> > > >
> > > > Fixes: 934aef885f9d ("drm: bridge: panel: Reset the connector state 
> > > > pointer")
> > > > Signed-off-by: Marek Szyprowski 
> > > > ---
> > > > Here is a bit more backgroud on this issue is available in this thread:
> > > > https://lore.kernel.org/all/f0474a95-4ba3-a74f-d7de-ef7aab12b...@samsung.com/
> > > > ---
> > > >  drivers/gpu/drm/bridge/panel.c | 7 +--
> > > >  1 file changed, 5 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/bridge/panel.c 
> > > > b/drivers/gpu/drm/bridge/panel.c
> > > > index ff1c37b2e6e5..0ee563eb2b6f 100644
> > > > --- a/drivers/gpu/drm/bridge/panel.c
> > > > +++ b/drivers/gpu/drm/bridge/panel.c
> > > > @@ -83,8 +83,11 @@ static int panel_bridge_attach(struct drm_bridge 
> > > > *bridge,
> > > > drm_connector_attach_encoder(&panel_bridge->connector,
> > > >   bridge->encoder);
> > > >
> > > > -   if (connector->funcs->reset)
> > > > -   connector->funcs->reset(connector);
> > > > +   if (bridge->dev->registered) {
> > > > +   if (connector->funcs->reset)
> > > > +   connector->funcs->reset(connector);
> > > > +   drm_connector_register(connector);
> > > > +   }
> > >
> > > Reviewed-by: Jagan Teki 
> >
> > Fixed typos in commit message.
> >
> > Reviewed-by: Robert Foss 
> >
> > Applied to drm-misc-next
>
> Doesn't this open the door to various race conditions ?
>
> Also, what happens if the panel bridge is detached and reattached ? If I

I believe the dev->registered is the check for those already registered.

Jagan.

Re: [PATCH resend v8 0/5] phy: phy-fsl-imx8-mipi-dphy: Add i.MX8qxp LVDS PHY mode support

[Liu Ying]

On Wed, 2022-04-20 at 13:00 +0530, Vinod Koul wrote:
> On 19-04-22, 09:08, Liu Ying wrote:
> > Hi,
> > 
> > This is the v8 series to add i.MX8qxp LVDS PHY mode support for the
> > Mixel
> > PHY in the Freescale i.MX8qxp SoC.
> > 
> > The Mixel PHY is MIPI DPHY + LVDS PHY combo, which can works in
> > either
> > MIPI DPHY mode or LVDS PHY mode.  The PHY mode is controlled by
> > i.MX8qxp
> > SCU firmware.  The PHY driver would call a SCU function to
> > configure the
> > mode.
> > 
> > The PHY driver is already supporting the Mixel MIPI DPHY in i.MX8mq
> > SoC,
> > where it appears to be a single MIPI DPHY.
> > 
> > 
> > Patch 1/5 sets PHY mode in the Northwest Logic MIPI DSI host
> > controller
> > bridge driver, since i.MX8qxp SoC embeds this controller IP to
> > support
> > MIPI DSI displays together with the Mixel PHY.
> > 
> > Patch 2/5 allows LVDS PHYs to be configured through the generic PHY
> > functions
> > and through a custom structure added to the generic PHY
> > configuration union.
> > 
> > Patch 3/5 converts mixel,mipi-dsi-phy plain text dt binding to
> > json-schema.
> > 
> > Patch 4/5 adds dt binding support for the Mixel combo PHY in
> > i.MX8qxp SoC.
> > 
> > Patch 5/5 adds the i.MX8qxp LVDS PHY mode support in the Mixel PHY
> > driver.
> 
> Applied patch 2-5 to phy-next, thanks

Now that patch 2-5 landed in phy-next, patch 1 is needed to explicitly
set MIPI DPHY mode in the nwl-dsi drm bridge driver, otherwise, i.MX8mq
MIPI DSI display feature will be broken due to the phy mode check added
in patch 5.

I'm assuming patch 1 should go through drm-misc. Robert/drm folks, can
you please pick it up?

Thanks,
Liu Ying

Re: [PATCH] drm/ttm: fix ttm tt init fail when size exceeds kmalloc limit

[Christian König]

Am 20.04.22 um 11:07 schrieb Wang, Yang(Kevin):


[AMD Official Use Only]




*From:* Koenig, Christian 
*Sent:* Wednesday, April 20, 2022 5:00 PM
*To:* Wang, Yang(Kevin) ; 
dri-devel@lists.freedesktop.org ; 
amd-...@lists.freedesktop.org 
*Subject:* Re: [PATCH] drm/ttm: fix ttm tt init fail when size exceeds 
kmalloc limit

Am 20.04.22 um 10:56 schrieb Yang Wang:
> if the __GFP_ZERO is set, the kvmalloc() can't fallback to use vmalloc()

Hui what? Why should kvmalloc() not be able to fallback to vmalloc()
when __GFP_ZERO is set?

And even that is really the case then that sounds like a bug in 
kvmalloc().


Regards,
Christian.

[kevin]:
it is really test case from libdrm amdgpu test, which try to allocate 
a big BO which will cause ttm tt init fail.



LOL! Guys, this test case is intended to fail!

The test consists of allocating a buffer so ridiculous large that it 
should never succeed and be rejected by the kernel driver.


This patch here is a really clear NAK.

Regards,
Christian.

it may be a kvmalloc() bug, and this patch can as a workaround 
in ttm before this issue fix.


void *kvmalloc_node(size_t size, gfp_t flags, int node)
{
...
      if ((flags & GFP_KERNEL) != GFP_KERNEL)
              return kmalloc_node(size, flags, node);
...
}

Best Regards,
Kevin

> to allocate memory, when request size is exceeds kmalloc limit, it will
> cause allocate memory fail.
>
> e.g: when ttm want to create a BO with 1TB size, it maybe fail.
>
> Signed-off-by: Yang Wang 
> ---
>   drivers/gpu/drm/ttm/ttm_tt.c | 14 +++---
>   1 file changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
> index 79c870a3bef8..9f2f3e576b8d 100644
> --- a/drivers/gpu/drm/ttm/ttm_tt.c
> +++ b/drivers/gpu/drm/ttm/ttm_tt.c
> @@ -97,9 +97,12 @@ int ttm_tt_create(struct ttm_buffer_object *bo, 
bool zero_alloc)

>   static int ttm_tt_alloc_page_directory(struct ttm_tt *ttm)
>   {
>    ttm->pages = kvmalloc_array(ttm->num_pages, sizeof(void*),
> - GFP_KERNEL | __GFP_ZERO);
> + GFP_KERNEL);
>    if (!ttm->pages)
>    return -ENOMEM;
> +
> + memset(ttm->pages, 0, ttm->num_pages * sizeof(void *));
> +
>    return 0;
>   }
>
> @@ -108,10 +111,12 @@ static int 
ttm_dma_tt_alloc_page_directory(struct ttm_tt *ttm)

>    ttm->pages = kvmalloc_array(ttm->num_pages,
> sizeof(*ttm->pages) +
> sizeof(*ttm->dma_address),
> - GFP_KERNEL | __GFP_ZERO);
> + GFP_KERNEL);
>    if (!ttm->pages)
>    return -ENOMEM;
>
> + memset(ttm->pages, 0, ttm->num_pages * (sizeof(*ttm->pages) + 
sizeof(*ttm->dma_address)));

> +
>    ttm->dma_address = (void *)(ttm->pages + ttm->num_pages);
>    return 0;
>   }
> @@ -120,9 +125,12 @@ static int 
ttm_sg_tt_alloc_page_directory(struct ttm_tt *ttm)

>   {
>    ttm->dma_address = kvmalloc_array(ttm->num_pages,
> sizeof(*ttm->dma_address),
> -   GFP_KERNEL | __GFP_ZERO);
> + GFP_KERNEL);
>    if (!ttm->dma_address)
>    return -ENOMEM;
> +
> + memset(ttm->dma_address, 0, ttm->num_pages * 
sizeof(*ttm->dma_address));

> +
>    return 0;
>   }
>

[PATCH v2 0/8] drm: Introduce display-helper library

[Thomas Zimmermann]

Move DisplayPort, HDMI and various other display helpers from KMS
helpers into a new module. Adapt all drivers.

This patch is part of an on-going effort to reduce the minimum size
of DRM when linked into the kernel binary. The helpers for various
display and video-output standards are not required for minimal
graphics output and can be moved into a separate module.

The DisplayPort code was already part of the DP module, which now
forms the base of the display-helper module. Moving other helpers
into the new module reduces KMS helpers by ~14 KiB (from 243 KiB to
229 KiB). More importantly, restructuring the code allows for a more
fine-grained selection of helpers and dependencies.

Built on x86-64, i586, aarch64, and arm.

v2:
* reduce number of HDMI helpers (Jani)
* make individual helpers selectable via Kconfig
* fix several include statements
* minor cleanups

Thomas Zimmermann (8):
  drm: Put related statements next to each other in Makefile
  drm: Rename dp/ to display/
  drm/display: Introduce a DRM display-helper module
  drm/display: Split DisplayPort header into core and helper
  drm/display: Move DSC header and helpers into display-helper module
  drm/display: Move HDCP helpers into display-helper module
  drm/display: Move HDMI helpers into display-helper module
  drm/display: Move SCDC helpers into display-helper library

 Documentation/gpu/drm-kms-helpers.rst |  43 +-
 drivers/gpu/drm/Kconfig   |  41 +-
 drivers/gpu/drm/Makefile  |  29 +-
 .../gpu/drm/amd/amdgpu/amdgpu_connectors.c|   2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h  |   4 +-
 drivers/gpu/drm/amd/amdgpu/atombios_dp.c  |   3 +-
 drivers/gpu/drm/amd/display/Kconfig   |   1 +
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |   5 +-
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h |   2 +-
 .../amd/display/amdgpu_dm/amdgpu_dm_hdcp.c|   2 +-
 .../display/amdgpu_dm/amdgpu_dm_mst_types.c   |   4 +-
 .../drm/amd/display/dc/core/dc_link_dpcd.c|   2 +-
 .../gpu/drm/amd/display/dc/dcn20/dcn20_dsc.c  |   2 +
 .../gpu/drm/amd/display/dc/dcn20/dcn20_dsc.h  |   2 +-
 .../drm/amd/display/dc/dml/dsc/rc_calc_fpu.h  |   2 +-
 drivers/gpu/drm/amd/display/dc/dsc/dc_dsc.c   |   4 +-
 .../gpu/drm/amd/display/dc/dsc/dscc_types.h   |   2 +-
 .../gpu/drm/amd/display/dc/dsc/rc_calc_dpi.c  |   2 +-
 drivers/gpu/drm/amd/display/dc/os_types.h |   2 +-
 .../gpu/drm/amd/display/include/dpcd_defs.h   |   2 +-
 .../gpu/drm/amd/display/modules/hdcp/hdcp.h   |   4 +-
 drivers/gpu/drm/bridge/Kconfig|  16 +-
 drivers/gpu/drm/bridge/analogix/Kconfig   |  10 +-
 .../drm/bridge/analogix/analogix-anx6345.c|   2 +-
 .../drm/bridge/analogix/analogix-anx78xx.c|   2 +-
 .../drm/bridge/analogix/analogix-i2c-dptx.c   |   2 +-
 .../drm/bridge/analogix/analogix_dp_core.h|   2 +-
 drivers/gpu/drm/bridge/analogix/anx7625.c |   6 +-
 drivers/gpu/drm/bridge/cadence/Kconfig|   4 +-
 .../drm/bridge/cadence/cdns-mhdp8546-core.c   |   4 +-
 .../drm/bridge/cadence/cdns-mhdp8546-core.h   |   2 +-
 .../drm/bridge/cadence/cdns-mhdp8546-hdcp.c   |   2 +-
 drivers/gpu/drm/bridge/ite-it6505.c   |   4 +-
 drivers/gpu/drm/bridge/parade-ps8640.c|   4 +-
 drivers/gpu/drm/bridge/synopsys/Kconfig   |   2 +
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c |   4 +-
 drivers/gpu/drm/bridge/tc358767.c |   2 +-
 drivers/gpu/drm/bridge/tc358775.c |   2 +-
 drivers/gpu/drm/bridge/ti-sn65dsi86.c |   4 +-
 drivers/gpu/drm/display/Kconfig   |  49 ++
 drivers/gpu/drm/display/Makefile  |  16 +
 .../drm_display_helper_mod.c} |  10 +-
 .../gpu/drm/{dp => display}/drm_dp_aux_bus.c  |   4 +-
 .../gpu/drm/{dp => display}/drm_dp_aux_dev.c  |   4 +-
 drivers/gpu/drm/{dp => display}/drm_dp_cec.c  |   2 +-
 .../{dp => display}/drm_dp_dual_mode_helper.c |   2 +-
 .../{dp/drm_dp.c => display/drm_dp_helper.c}  |   4 +-
 .../{dp => display}/drm_dp_helper_internal.h  |   0
 .../drm/{dp => display}/drm_dp_mst_topology.c |   2 +-
 .../drm_dp_mst_topology_internal.h|   2 +-
 .../{drm_dsc.c => display/drm_dsc_helper.c}   |   5 +-
 .../{drm_hdcp.c => display/drm_hdcp_helper.c} |   4 +-
 drivers/gpu/drm/display/drm_hdmi_helper.c | 199 +
 .../gpu/drm/{ => display}/drm_scdc_helper.c   |   3 +-
 drivers/gpu/drm/dp/Makefile   |   9 -
 drivers/gpu/drm/drm_connector.c   |  34 -
 drivers/gpu/drm/drm_edid.c| 160 
 drivers/gpu/drm/drm_mipi_dsi.c|   6 +-
 drivers/gpu/drm/exynos/Kconfig|   3 +-
 drivers/gpu/drm/gma500/cdv_intel_dp.c |   2 +-
 drivers/gpu/drm/gma500/intel_bios.c   |   3 +-
 drivers/gpu/drm/i915/Kconfig  |   5 +-
 drivers/gpu/drm/i915/display/icl_dsi.c|   1 +
 drivers/gpu/drm/i915/display/intel_bios.c |   3 +-
 drivers/gpu/drm/i915/display/i

[PATCH v2 1/8] drm: Put related statements next to each other in Makefile

[Thomas Zimmermann]

Give the Makefile a bit more structure by putting rules for core,
helpers, drivers, etc next to each other.

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Javier Martinez Canillas 
---
 drivers/gpu/drm/Makefile | 23 +--
 1 file changed, 17 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index c2ef5f9fce54..e5929437e13c 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -18,7 +18,6 @@ drm-y   :=drm_aperture.o drm_auth.o drm_cache.o \
drm_syncobj.o drm_lease.o drm_writeback.o drm_client.o \
drm_client_modeset.o drm_atomic_uapi.o \
drm_managed.o drm_vblank_work.o
-
 drm-$(CONFIG_DRM_LEGACY) += drm_agpsupport.o drm_bufs.o drm_context.o 
drm_dma.o \
drm_hashtab.o drm_irq.o drm_legacy_misc.o 
drm_lock.o \
drm_memory.o drm_scatter.o drm_vm.o
@@ -30,8 +29,16 @@ drm-$(CONFIG_PCI) += drm_pci.o
 drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
 drm-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
 drm-$(CONFIG_DRM_PRIVACY_SCREEN) += drm_privacy_screen.o 
drm_privacy_screen_x86.o
+obj-$(CONFIG_DRM)  += drm.o
 
 obj-$(CONFIG_DRM_NOMODESET) += drm_nomodeset.o
+obj-$(CONFIG_DRM_PANEL_ORIENTATION_QUIRKS) += drm_panel_orientation_quirks.o
+
+#
+# Memory-management helpers
+#
+
+obj-$(CONFIG_DRM_BUDDY) += drm_buddy.o
 
 drm_cma_helper-y := drm_gem_cma_helper.o
 drm_cma_helper-$(CONFIG_DRM_KMS_HELPER) += drm_fb_cma_helper.o
@@ -40,14 +47,16 @@ obj-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_cma_helper.o
 drm_shmem_helper-y := drm_gem_shmem_helper.o
 obj-$(CONFIG_DRM_GEM_SHMEM_HELPER) += drm_shmem_helper.o
 
-obj-$(CONFIG_DRM_BUDDY) += drm_buddy.o
-
 drm_vram_helper-y := drm_gem_vram_helper.o
 obj-$(CONFIG_DRM_VRAM_HELPER) += drm_vram_helper.o
 
 drm_ttm_helper-y := drm_gem_ttm_helper.o
 obj-$(CONFIG_DRM_TTM_HELPER) += drm_ttm_helper.o
 
+#
+# Modesetting helpers
+#
+
 drm_kms_helper-y := drm_bridge_connector.o drm_crtc_helper.o \
drm_dsc.o drm_encoder_slave.o drm_flip_work.o drm_hdcp.o \
drm_probe_helper.o \
@@ -60,14 +69,16 @@ drm_kms_helper-y := drm_bridge_connector.o 
drm_crtc_helper.o \
drm_format_helper.o drm_self_refresh_helper.o drm_rect.o
 drm_kms_helper-$(CONFIG_DRM_PANEL_BRIDGE) += bridge/panel.o
 drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o
-
 obj-$(CONFIG_DRM_KMS_HELPER) += drm_kms_helper.o
+
+#
+# Drivers and the rest
+#
+
 obj-$(CONFIG_DRM_DEBUG_SELFTEST) += selftests/
 
-obj-$(CONFIG_DRM)  += drm.o
 obj-$(CONFIG_DRM_MIPI_DBI) += drm_mipi_dbi.o
 obj-$(CONFIG_DRM_MIPI_DSI) += drm_mipi_dsi.o
-obj-$(CONFIG_DRM_PANEL_ORIENTATION_QUIRKS) += drm_panel_orientation_quirks.o
 obj-y  += arm/
 obj-y  += dp/
 obj-$(CONFIG_DRM_TTM)  += ttm/
-- 
2.35.1

[PATCH v2 2/8] drm: Rename dp/ to display/

[Thomas Zimmermann]

Rename dp/ to display/ to account for additional display-related
helpers, such as HDMI. Update all related include statements. No
functional changes.

Various drivers, such as i915 and amdgpu, use similar naming scheme
by putting code for video-output standards into a local display/
directory. The new directory's name is aligned with this convention.

v2:
* update commit message (Javier)

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Lyude Paul 
Reviewed-by: Javier Martinez Canillas 
Reviewed-by: Alex Deucher 
---
 Documentation/gpu/drm-kms-helpers.rst | 26 +--
 drivers/gpu/drm/Makefile  |  2 +-
 .../gpu/drm/amd/amdgpu/amdgpu_connectors.c|  2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h  |  4 +--
 drivers/gpu/drm/amd/amdgpu/atombios_dp.c  |  3 ++-
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  2 +-
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h |  2 +-
 .../display/amdgpu_dm/amdgpu_dm_mst_types.c   |  4 +--
 .../drm/amd/display/dc/core/dc_link_dpcd.c|  2 +-
 drivers/gpu/drm/amd/display/dc/dsc/dc_dsc.c   |  2 +-
 drivers/gpu/drm/amd/display/dc/os_types.h |  2 +-
 .../gpu/drm/amd/display/include/dpcd_defs.h   |  2 +-
 .../gpu/drm/amd/display/modules/hdcp/hdcp.h   |  2 +-
 .../drm/bridge/analogix/analogix-anx6345.c|  2 +-
 .../drm/bridge/analogix/analogix-anx78xx.c|  2 +-
 .../drm/bridge/analogix/analogix-i2c-dptx.c   |  2 +-
 .../drm/bridge/analogix/analogix_dp_core.h|  2 +-
 drivers/gpu/drm/bridge/analogix/anx7625.c |  4 +--
 .../drm/bridge/cadence/cdns-mhdp8546-core.c   |  2 +-
 .../drm/bridge/cadence/cdns-mhdp8546-core.h   |  2 +-
 drivers/gpu/drm/bridge/ite-it6505.c   |  2 +-
 drivers/gpu/drm/bridge/parade-ps8640.c|  4 +--
 drivers/gpu/drm/bridge/tc358767.c |  2 +-
 drivers/gpu/drm/bridge/tc358775.c |  2 +-
 drivers/gpu/drm/bridge/ti-sn65dsi86.c |  4 +--
 drivers/gpu/drm/{dp => display}/Makefile  |  0
 drivers/gpu/drm/{dp => display}/drm_dp.c  |  4 +--
 .../gpu/drm/{dp => display}/drm_dp_aux_bus.c  |  4 +--
 .../gpu/drm/{dp => display}/drm_dp_aux_dev.c  |  4 +--
 drivers/gpu/drm/{dp => display}/drm_dp_cec.c  |  2 +-
 .../{dp => display}/drm_dp_dual_mode_helper.c |  2 +-
 .../{dp => display}/drm_dp_helper_internal.h  |  0
 .../drm/{dp => display}/drm_dp_helper_mod.c   |  0
 .../drm/{dp => display}/drm_dp_mst_topology.c |  2 +-
 .../drm_dp_mst_topology_internal.h|  2 +-
 drivers/gpu/drm/drm_dsc.c |  3 ++-
 drivers/gpu/drm/gma500/cdv_intel_dp.c |  2 +-
 drivers/gpu/drm/gma500/intel_bios.c   |  3 ++-
 drivers/gpu/drm/i915/display/intel_bios.c |  2 +-
 drivers/gpu/drm/i915/display/intel_display.c  |  2 +-
 .../drm/i915/display/intel_display_types.h|  4 +--
 drivers/gpu/drm/i915/display/intel_dp.c   |  2 +-
 drivers/gpu/drm/i915/display/intel_dp_hdcp.c  |  4 +--
 .../drm/i915/display/intel_dp_link_training.h |  2 +-
 drivers/gpu/drm/i915/display/intel_lspcon.c   |  2 +-
 drivers/gpu/drm/msm/dp/dp_audio.c |  2 +-
 drivers/gpu/drm/msm/dp/dp_aux.h   |  2 +-
 drivers/gpu/drm/msm/dp/dp_catalog.c   |  2 +-
 drivers/gpu/drm/msm/dp/dp_ctrl.c  |  3 ++-
 drivers/gpu/drm/msm/edp/edp.h |  3 ++-
 drivers/gpu/drm/msm/edp/edp_ctrl.c|  3 ++-
 drivers/gpu/drm/nouveau/dispnv50/disp.c   |  2 +-
 drivers/gpu/drm/nouveau/nouveau_connector.h   |  2 +-
 drivers/gpu/drm/nouveau/nouveau_dp.c  |  2 +-
 drivers/gpu/drm/nouveau/nouveau_encoder.h |  6 +++--
 drivers/gpu/drm/panel/panel-edp.c |  4 +--
 .../gpu/drm/panel/panel-samsung-atna33xc20.c  |  4 +--
 drivers/gpu/drm/radeon/atombios_dp.c  |  2 +-
 drivers/gpu/drm/radeon/radeon_connectors.c|  2 +-
 drivers/gpu/drm/radeon/radeon_dp_mst.c|  2 +-
 drivers/gpu/drm/radeon/radeon_mode.h  |  4 +--
 .../gpu/drm/rockchip/analogix_dp-rockchip.c   |  2 +-
 drivers/gpu/drm/rockchip/cdn-dp-core.c|  2 +-
 drivers/gpu/drm/rockchip/cdn-dp-core.h|  2 +-
 drivers/gpu/drm/rockchip/rockchip_lvds.c  |  2 +-
 drivers/gpu/drm/rockchip/rockchip_rgb.c   |  2 +-
 .../drm/selftests/test-drm_dp_mst_helper.c|  4 +--
 drivers/gpu/drm/tegra/dp.c|  2 +-
 drivers/gpu/drm/tegra/dpaux.c |  4 +--
 drivers/gpu/drm/tegra/sor.c   |  2 +-
 drivers/gpu/drm/xlnx/zynqmp_dp.c  |  2 +-
 include/drm/{dp => display}/drm_dp_aux_bus.h  |  0
 .../{dp => display}/drm_dp_dual_mode_helper.h |  0
 include/drm/{dp => display}/drm_dp_helper.h   |  0
 .../drm/{dp => display}/drm_dp_mst_helper.h   |  2 +-
 include/drm/drm_dsc.h |  2 +-
 76 files changed, 106 insertions(+), 98 deletions(-)
 rename drivers/gpu/drm/{dp => display}/Makefile (100%)
 rename drivers/gpu/drm/{dp => display}/drm_dp.c (99%)
 rename drivers/gpu/drm/{dp => display}/drm_dp_aux_bus.c (99%)
 rename drivers/gpu/drm/{dp => display}

[PATCH v2 3/8] drm/display: Introduce a DRM display-helper module

[Thomas Zimmermann]

Replace the DP-helper module with a display-helper module. The
support for DisplayPort becomes an internal option that drivers
have to select. Update all related Kconfig and Makefile rules.

Besides the existing code for DisplayPort, the new module will
contain helpers for other video-output standards, such as HDMI.
Drivers will have to select their required video-output helpers.

Linking all display-related code into a single module avoids the
proliferation of small kernel modules.

The module parameters drm_dp_cec_unregister_delay, dp_aux_i2c_speed_khz,
and dp_aux_i2c_transfer_size are moving from the drm_dp_helper namespace
to drm_display_helper.

v2:
* mention module parameters in commit message (Javier)
* distiguish between display module and DP support in Kconfig
* update Makefile rules for DP helpers
* move Kconfig rules into separate file under display/

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Lyude Paul 
---
 drivers/gpu/drm/Kconfig   | 39 ---
 drivers/gpu/drm/bridge/Kconfig| 15 ---
 drivers/gpu/drm/bridge/analogix/Kconfig   |  9 +++--
 drivers/gpu/drm/bridge/cadence/Kconfig|  3 +-
 drivers/gpu/drm/display/Kconfig   | 37 ++
 drivers/gpu/drm/display/Makefile  | 11 --
 ..._helper_mod.c => drm_display_helper_mod.c} | 10 ++---
 .../drm/display/{drm_dp.c => drm_dp_helper.c} |  0
 drivers/gpu/drm/exynos/Kconfig|  3 +-
 drivers/gpu/drm/i915/Kconfig  |  3 +-
 drivers/gpu/drm/msm/Kconfig   |  3 +-
 drivers/gpu/drm/nouveau/Kconfig   |  3 +-
 drivers/gpu/drm/panel/Kconfig |  3 +-
 drivers/gpu/drm/rockchip/Kconfig  |  4 +-
 drivers/gpu/drm/tegra/Kconfig |  3 +-
 drivers/gpu/drm/xlnx/Kconfig  |  3 +-
 16 files changed, 90 insertions(+), 59 deletions(-)
 create mode 100644 drivers/gpu/drm/display/Kconfig
 rename drivers/gpu/drm/display/{drm_dp_helper_mod.c => 
drm_display_helper_mod.c} (51%)
 rename drivers/gpu/drm/display/{drm_dp.c => drm_dp_helper.c} (100%)

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 5133c3f028ab..353f9427f3c3 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -36,19 +36,6 @@ config DRM_MIPI_DSI
bool
depends on DRM
 
-config DRM_DP_AUX_BUS
-   tristate
-   depends on DRM
-   depends on OF
-
-config DRM_DP_AUX_CHARDEV
-   bool "DRM DP AUX Interface"
-   depends on DRM
-   help
- Choose this option to enable a /dev/drm_dp_auxN node that allows to
- read and write values to arbitrary DPCD registers on the DP aux
- channel.
-
 config DRM_DEBUG_MM
bool "Insert extra checks and debug info into the DRM range managers"
default n
@@ -68,7 +55,8 @@ config DRM_DEBUG_SELFTEST
depends on DRM
depends on DEBUG_KERNEL
select PRIME_NUMBERS
-   select DRM_DP_HELPER
+   select DRM_DISPLAY_DP_HELPER
+   select DRM_DISPLAY_HELPER
select DRM_LIB_RANDOM
select DRM_KMS_HELPER
select DRM_BUDDY
@@ -82,12 +70,6 @@ config DRM_DEBUG_SELFTEST
 
  If in doubt, say "N".
 
-config DRM_DP_HELPER
-   tristate
-   depends on DRM
-   help
- DRM helpers for DisplayPort.
-
 config DRM_KMS_HELPER
tristate
depends on DRM
@@ -187,16 +169,7 @@ config DRM_LOAD_EDID_FIRMWARE
  default case is N. Details and instructions how to build your own
  EDID data are given in Documentation/admin-guide/edid.rst.
 
-config DRM_DP_CEC
-   bool "Enable DisplayPort CEC-Tunneling-over-AUX HDMI support"
-   depends on DRM
-   select CEC_CORE
-   help
- Choose this option if you want to enable HDMI CEC support for
- DisplayPort/USB-C to HDMI adapters.
-
- Note: not all adapters support this feature, and even for those
- that do support this they often do not hook up the CEC pin.
+source "drivers/gpu/drm/display/Kconfig"
 
 config DRM_TTM
tristate
@@ -250,7 +223,8 @@ config DRM_RADEON
depends on DRM && PCI && MMU
depends on AGP || !AGP
select FW_LOADER
-   select DRM_DP_HELPER
+   select DRM_DISPLAY_DP_HELPER
+   select DRM_DISPLAY_HELPER
 select DRM_KMS_HELPER
 select DRM_TTM
select DRM_TTM_HELPER
@@ -271,7 +245,8 @@ config DRM_AMDGPU
tristate "AMD GPU"
depends on DRM && PCI && MMU
select FW_LOADER
-   select DRM_DP_HELPER
+   select DRM_DISPLAY_DP_HELPER
+   select DRM_DISPLAY_HELPER
select DRM_KMS_HELPER
select DRM_SCHED
select DRM_TTM
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 7ac920a57d26..a9b83577e86c 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -78,7 +78,8 @@ config DRM_DISPLAY_CONNECTOR
 con

[PATCH v2 5/8] drm/display: Move DSC header and helpers into display-helper module

[Thomas Zimmermann]

DSC is the Display Stream Compression standard for DisplayPort. Move
the DSC code into display/ and split the header into files for protocol
core and DRM helpers. Adapt all users of the code. No functional
changes.

To avoid the proliferation of Kconfig options, DSC is part of DRM's
support for DisplayPort. If necessary, a new option could make DSC an
independent feature.

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Javier Martinez Canillas 
---
 Documentation/gpu/drm-kms-helpers.rst |  6 +++---
 drivers/gpu/drm/Makefile  |  2 +-
 .../gpu/drm/amd/display/dc/dcn20/dcn20_dsc.c  |  2 ++
 .../gpu/drm/amd/display/dc/dcn20/dcn20_dsc.h  |  2 +-
 .../drm/amd/display/dc/dml/dsc/rc_calc_fpu.h  |  2 +-
 drivers/gpu/drm/amd/display/dc/dsc/dc_dsc.c   |  4 ++--
 .../gpu/drm/amd/display/dc/dsc/dscc_types.h   |  2 +-
 .../gpu/drm/amd/display/dc/dsc/rc_calc_dpi.c  |  2 +-
 drivers/gpu/drm/display/Makefile  |  3 ++-
 .../{drm_dsc.c => display/drm_dsc_helper.c}   |  2 +-
 drivers/gpu/drm/drm_mipi_dsi.c|  6 +++---
 drivers/gpu/drm/i915/display/icl_dsi.c|  1 +
 drivers/gpu/drm/i915/display/intel_bios.c |  1 +
 .../drm/i915/display/intel_display_types.h|  2 +-
 drivers/gpu/drm/i915/display/intel_dp.c   |  1 +
 .../gpu/drm/i915/display/intel_qp_tables.c|  2 +-
 drivers/gpu/drm/i915/display/intel_vdsc.c |  2 ++
 include/drm/{ => display}/drm_dsc.h   |  8 +---
 include/drm/display/drm_dsc_helper.h  | 20 +++
 19 files changed, 46 insertions(+), 24 deletions(-)
 rename drivers/gpu/drm/{drm_dsc.c => display/drm_dsc_helper.c} (99%)
 rename include/drm/{ => display}/drm_dsc.h (97%)
 create mode 100644 include/drm/display/drm_dsc_helper.h

diff --git a/Documentation/gpu/drm-kms-helpers.rst 
b/Documentation/gpu/drm-kms-helpers.rst
index 09463ee99730..7af55fb4072c 100644
--- a/Documentation/gpu/drm-kms-helpers.rst
+++ b/Documentation/gpu/drm-kms-helpers.rst
@@ -326,13 +326,13 @@ MIPI DSI Helper Functions Reference
 Display Stream Compression Helper Functions Reference
 =
 
-.. kernel-doc:: drivers/gpu/drm/drm_dsc.c
+.. kernel-doc:: drivers/gpu/drm/display/drm_dsc_helper.c
:doc: dsc helpers
 
-.. kernel-doc:: include/drm/drm_dsc.h
+.. kernel-doc:: include/drm/display/drm_dsc.h
:internal:
 
-.. kernel-doc:: drivers/gpu/drm/drm_dsc.c
+.. kernel-doc:: drivers/gpu/drm/display/drm_dsc_helper.c
:export:
 
 Output Probing Helper Functions Reference
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 07f7a70a78ea..b8353af70152 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -58,7 +58,7 @@ obj-$(CONFIG_DRM_TTM_HELPER) += drm_ttm_helper.o
 #
 
 drm_kms_helper-y := drm_bridge_connector.o drm_crtc_helper.o \
-   drm_dsc.o drm_encoder_slave.o drm_flip_work.o drm_hdcp.o \
+   drm_encoder_slave.o drm_flip_work.o drm_hdcp.o \
drm_probe_helper.o \
drm_plane_helper.o drm_atomic_helper.o \
drm_kms_helper_common.o \
diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dsc.c 
b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dsc.c
index ef5c4c0f4d6c..6f24ceab97ad 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dsc.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dsc.c
@@ -23,6 +23,8 @@
  *
  */
 
+#include 
+
 #include "reg_helper.h"
 #include "dcn20_dsc.h"
 #include "dsc/dscc_types.h"
diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dsc.h 
b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dsc.h
index 1118e33aaa2c..c21ecedc4692 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dsc.h
+++ b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dsc.h
@@ -26,7 +26,7 @@
 
 #include "dsc.h"
 #include "dsc/dscc_types.h"
-#include 
+#include 
 
 #define TO_DCN20_DSC(dsc)\
container_of(dsc, struct dcn20_dsc, base)
diff --git a/drivers/gpu/drm/amd/display/dc/dml/dsc/rc_calc_fpu.h 
b/drivers/gpu/drm/amd/display/dc/dml/dsc/rc_calc_fpu.h
index cad244c023cd..d7cd8cc24758 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/dsc/rc_calc_fpu.h
+++ b/drivers/gpu/drm/amd/display/dc/dml/dsc/rc_calc_fpu.h
@@ -27,7 +27,7 @@
 #define __RC_CALC_FPU_H__
 
 #include "os_types.h"
-#include 
+#include 
 
 #define QP_SET_SIZE 15
 
diff --git a/drivers/gpu/drm/amd/display/dc/dsc/dc_dsc.c 
b/drivers/gpu/drm/amd/display/dc/dsc/dc_dsc.c
index dc82e04e36dc..fa39a06eed1d 100644
--- a/drivers/gpu/drm/amd/display/dc/dsc/dc_dsc.c
+++ b/drivers/gpu/drm/amd/display/dc/dsc/dc_dsc.c
@@ -22,10 +22,10 @@
  * Author: AMD
  */
 
-#include 
+#include 
+#include 
 #include "dc_hw_types.h"
 #include "dsc.h"
-#include 
 #include "dc.h"
 #include "rc_calc.h"
 #include "fixed31_32.h"
diff --git a/drivers/gpu/drm/amd/display/dc/dsc/dscc_types.h 
b/drivers/gpu/drm/amd/display/dc/dsc/dscc_types.h
index 9f70e87b3ecb..ad80bde9bc0f 100644
--- a/drivers/gpu/drm/amd/display/dc/dsc/dscc_types.h
+++ b/drivers/gpu/drm

[PATCH v2 7/8] drm/display: Move HDMI helpers into display-helper module

[Thomas Zimmermann]

Move DRM's HMDI helpers into the display/ subdirectoy and add it
to DRM's display helpers. Update all affected drivers. No functional
changes.

The HDMI helpers were implemented in the EDID and connector code, but
are actually unrelated. With the move to the display-helper library, we
can remove the dependency on drm_edid.{c,h} in some driver's HDMI source
files.

Several of the HDMI helpers remain in EDID code because both share parts
of their implementation internally. With better refractoring of the EDID
code, those HDMI helpers could be moved into the display-helper library
as well.

v2:
* reduce HDMI helpers to avoid exporting functions (Jani)
* fix include statements (Jani, Javier)
* update Kconfig symbols

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/Kconfig   |   2 +
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |   1 +
 drivers/gpu/drm/bridge/synopsys/Kconfig   |   2 +
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c |   2 +-
 drivers/gpu/drm/display/Kconfig   |   6 +
 drivers/gpu/drm/display/Makefile  |   1 +
 drivers/gpu/drm/display/drm_hdmi_helper.c | 199 ++
 drivers/gpu/drm/drm_connector.c   |  34 ---
 drivers/gpu/drm/drm_edid.c| 159 --
 drivers/gpu/drm/i915/Kconfig  |   1 +
 drivers/gpu/drm/i915/display/intel_dp.c   |   2 +-
 drivers/gpu/drm/i915/display/intel_hdmi.c |   1 +
 drivers/gpu/drm/i915/display/intel_lspcon.c   |   2 +-
 drivers/gpu/drm/i915/display/intel_sdvo.c |   1 +
 drivers/gpu/drm/vc4/Kconfig   |   2 +
 drivers/gpu/drm/vc4/vc4_hdmi.c|   2 +-
 include/drm/display/drm_hdmi_helper.h |  27 +++
 include/drm/drm_connector.h   |   3 -
 include/drm/drm_edid.h|  12 --
 19 files changed, 247 insertions(+), 212 deletions(-)
 create mode 100644 drivers/gpu/drm/display/drm_hdmi_helper.c
 create mode 100644 include/drm/display/drm_hdmi_helper.h

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 353f9427f3c3..3acad8de85d4 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -224,6 +224,7 @@ config DRM_RADEON
depends on AGP || !AGP
select FW_LOADER
select DRM_DISPLAY_DP_HELPER
+   select DRM_DISPLAY_HDMI_HELPER
select DRM_DISPLAY_HELPER
 select DRM_KMS_HELPER
 select DRM_TTM
@@ -246,6 +247,7 @@ config DRM_AMDGPU
depends on DRM && PCI && MMU
select FW_LOADER
select DRM_DISPLAY_DP_HELPER
+   select DRM_DISPLAY_HDMI_HELPER
select DRM_DISPLAY_HELPER
select DRM_KMS_HELPER
select DRM_SCHED
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index b602ffbc1e58..6f330022b06f 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -74,6 +74,7 @@
 #include 
 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpu/drm/bridge/synopsys/Kconfig 
b/drivers/gpu/drm/bridge/synopsys/Kconfig
index 21a1be3ced0f..be7aa717354b 100644
--- a/drivers/gpu/drm/bridge/synopsys/Kconfig
+++ b/drivers/gpu/drm/bridge/synopsys/Kconfig
@@ -1,6 +1,8 @@
 # SPDX-License-Identifier: GPL-2.0-only
 config DRM_DW_HDMI
tristate
+   select DRM_DISPLAY_HDMI_HELPER
+   select DRM_DISPLAY_HELPER
select DRM_KMS_HELPER
select REGMAP_MMIO
select CEC_CORE if CEC_NOTIFIER
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index a563460f8d20..a06a2d51e77f 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -25,10 +25,10 @@
 #include 
 
 #include 
+#include 
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpu/drm/display/Kconfig b/drivers/gpu/drm/display/Kconfig
index ef4c071d8ea3..5e7cdc891e82 100644
--- a/drivers/gpu/drm/display/Kconfig
+++ b/drivers/gpu/drm/display/Kconfig
@@ -23,6 +23,12 @@ config DRM_DISPLAY_HDCP_HELPER
help
  DRM display helpers for HDCP.
 
+config DRM_DISPLAY_HDMI_HELPER
+   bool
+   select DRM_DISPLAY_HELPER
+   help
+ DRM display helpers for HDMI.
+
 config DRM_DP_AUX_CHARDEV
bool "DRM DP AUX Interface"
depends on DRM
diff --git a/drivers/gpu/drm/display/Makefile b/drivers/gpu/drm/display/Makefile
index abeb5ad8c351..db644e7a550d 100644
--- a/drivers/gpu/drm/display/Makefile
+++ b/drivers/gpu/drm/display/Makefile
@@ -8,6 +8,7 @@ drm_display_helper-$(CONFIG_DRM_DISPLAY_DP_HELPER) += 
drm_dp_dual_mode_helper.o
  drm_dp_mst_topology.o \
  drm_dsc_helper.o
 drm_display_helper-$(CONFIG_DRM_DISPLAY_HDCP_HELPER) += drm_hdcp_helper.o
+drm_display_

[PATCH v2 6/8] drm/display: Move HDCP helpers into display-helper module

[Thomas Zimmermann]

Move DRM's HDCP helper library into the display/ subdirectory and add
it to DRM's display helpers. Split the header file into core and helpers.
Update all affected drivers. No functional changes.

v2:
* fix include statements (Jani, Javier)
* update Kconfig symbols

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Javier Martinez Canillas 
---
 Documentation/gpu/drm-kms-helpers.rst |  2 +-
 drivers/gpu/drm/Makefile  |  2 +-
 drivers/gpu/drm/amd/display/Kconfig   |  1 +
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  2 +-
 .../amd/display/amdgpu_dm/amdgpu_dm_hdcp.c|  2 +-
 .../gpu/drm/amd/display/modules/hdcp/hdcp.h   |  2 +-
 drivers/gpu/drm/bridge/Kconfig|  1 +
 drivers/gpu/drm/bridge/analogix/Kconfig   |  1 +
 drivers/gpu/drm/bridge/analogix/anx7625.c |  2 +-
 drivers/gpu/drm/bridge/cadence/Kconfig|  1 +
 .../drm/bridge/cadence/cdns-mhdp8546-core.c   |  2 +-
 .../drm/bridge/cadence/cdns-mhdp8546-hdcp.c   |  2 +-
 drivers/gpu/drm/bridge/ite-it6505.c   |  2 +-
 drivers/gpu/drm/display/Kconfig   |  6 +
 drivers/gpu/drm/display/Makefile  |  1 +
 .../{drm_hdcp.c => display/drm_hdcp_helper.c} |  4 +---
 drivers/gpu/drm/i915/Kconfig  |  1 +
 drivers/gpu/drm/i915/display/intel_dp_hdcp.c  |  2 +-
 drivers/gpu/drm/i915/display/intel_gmbus.c|  2 +-
 drivers/gpu/drm/i915/display/intel_hdcp.c |  2 +-
 drivers/gpu/drm/i915/display/intel_hdmi.c |  2 +-
 drivers/misc/mei/hdcp/mei_hdcp.h  |  2 +-
 include/drm/{ => display}/drm_hdcp.h  | 14 ++--
 include/drm/display/drm_hdcp_helper.h | 22 +++
 include/drm/i915_mei_hdcp_interface.h |  2 +-
 25 files changed, 52 insertions(+), 30 deletions(-)
 rename drivers/gpu/drm/{drm_hdcp.c => display/drm_hdcp_helper.c} (99%)
 rename include/drm/{ => display}/drm_hdcp.h (95%)
 create mode 100644 include/drm/display/drm_hdcp_helper.h

diff --git a/Documentation/gpu/drm-kms-helpers.rst 
b/Documentation/gpu/drm-kms-helpers.rst
index 7af55fb4072c..cfda5a092a48 100644
--- a/Documentation/gpu/drm-kms-helpers.rst
+++ b/Documentation/gpu/drm-kms-helpers.rst
@@ -226,7 +226,7 @@ Panel Self Refresh Helper Reference
 HDCP Helper Functions Reference
 ===
 
-.. kernel-doc:: drivers/gpu/drm/drm_hdcp.c
+.. kernel-doc:: drivers/gpu/drm/display/drm_hdcp_helper.c
:export:
 
 Display Port Helper Functions Reference
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index b8353af70152..746a3a4953f3 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -58,7 +58,7 @@ obj-$(CONFIG_DRM_TTM_HELPER) += drm_ttm_helper.o
 #
 
 drm_kms_helper-y := drm_bridge_connector.o drm_crtc_helper.o \
-   drm_encoder_slave.o drm_flip_work.o drm_hdcp.o \
+   drm_encoder_slave.o drm_flip_work.o \
drm_probe_helper.o \
drm_plane_helper.o drm_atomic_helper.o \
drm_kms_helper_common.o \
diff --git a/drivers/gpu/drm/amd/display/Kconfig 
b/drivers/gpu/drm/amd/display/Kconfig
index 127667e549c1..b4029c0d5d8c 100644
--- a/drivers/gpu/drm/amd/display/Kconfig
+++ b/drivers/gpu/drm/amd/display/Kconfig
@@ -20,6 +20,7 @@ config DRM_AMD_DC_DCN
 config DRM_AMD_DC_HDCP
bool "Enable HDCP support in DC"
depends on DRM_AMD_DC
+   select DRM_DISPLAY_HDCP_HELPER
help
  Choose this option if you want to support HDCP authentication.
 
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 2c69a6c2e6cb..b602ffbc1e58 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -48,7 +48,7 @@
 #include "amdgpu_dm.h"
 #ifdef CONFIG_DRM_AMD_DC_HDCP
 #include "amdgpu_dm_hdcp.h"
-#include 
+#include 
 #endif
 #include "amdgpu_pm.h"
 #include "amdgpu_atombios.h"
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_hdcp.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_hdcp.c
index bf0d50277f8f..15c0e3f2a9c3 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_hdcp.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_hdcp.c
@@ -27,7 +27,7 @@
 #include "amdgpu.h"
 #include "amdgpu_dm.h"
 #include "dm_helpers.h"
-#include 
+#include 
 #include "hdcp_psp.h"
 
 /*
diff --git a/drivers/gpu/drm/amd/display/modules/hdcp/hdcp.h 
b/drivers/gpu/drm/amd/display/modules/hdcp/hdcp.h
index 6e88705e22f7..392c0c03365a 100644
--- a/drivers/gpu/drm/amd/display/modules/hdcp/hdcp.h
+++ b/drivers/gpu/drm/amd/display/modules/hdcp/hdcp.h
@@ -30,7 +30,7 @@
 #include "hdcp_log.h"
 
 #include 
-#include 
+#include 
 
 enum mod_hdcp_trans_input_result {
UNKNOWN = 0,
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index a9b83577e86c..1145bdd96dd4 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@

[PATCH v2 4/8] drm/display: Split DisplayPort header into core and helper

[Thomas Zimmermann]

Move DisplayPort protocol constants and structures into the new
header drm_dp.h, which can be used by DRM core components. The
existing header drm_dp_helper.h now only contains helper code for
graphics drivers. No functional changes.

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Lyude Paul 
Reviewed-by: Javier Martinez Canillas 
---
 Documentation/gpu/drm-kms-helpers.rst |3 +
 include/drm/display/drm_dp.h  | 1688 +
 include/drm/display/drm_dp_helper.h   | 1662 +---
 3 files changed, 1693 insertions(+), 1660 deletions(-)
 create mode 100644 include/drm/display/drm_dp.h

diff --git a/Documentation/gpu/drm-kms-helpers.rst 
b/Documentation/gpu/drm-kms-helpers.rst
index 2584f5bff66f..09463ee99730 100644
--- a/Documentation/gpu/drm-kms-helpers.rst
+++ b/Documentation/gpu/drm-kms-helpers.rst
@@ -235,6 +235,9 @@ Display Port Helper Functions Reference
 .. kernel-doc:: drivers/gpu/drm/display/drm_dp_helper.c
:doc: dp helpers
 
+.. kernel-doc:: include/drm/display/drm_dp.h
+   :internal:
+
 .. kernel-doc:: include/drm/display/drm_dp_helper.h
:internal:
 
diff --git a/include/drm/display/drm_dp.h b/include/drm/display/drm_dp.h
new file mode 100644
index ..3c937f8bdb42
--- /dev/null
+++ b/include/drm/display/drm_dp.h
@@ -0,0 +1,1688 @@
+/*
+ * Copyright © 2008 Keith Packard
+ *
+ * Permission to use, copy, modify, distribute, and sell this software and its
+ * documentation for any purpose is hereby granted without fee, provided that
+ * the above copyright notice appear in all copies and that both that copyright
+ * notice and this permission notice appear in supporting documentation, and
+ * that the name of the copyright holders not be used in advertising or
+ * publicity pertaining to distribution of the software without specific,
+ * written prior permission.  The copyright holders make no representations
+ * about the suitability of this software for any purpose.  It is provided "as
+ * is" without express or implied warranty.
+ *
+ * THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
+ * INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO
+ * EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY SPECIAL, INDIRECT OR
+ * CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE,
+ * DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
+ * TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE
+ * OF THIS SOFTWARE.
+ */
+
+#ifndef _DRM_DP_H_
+#define _DRM_DP_H_
+
+#include 
+
+/*
+ * Unless otherwise noted, all values are from the DP 1.1a spec.  Note that
+ * DP and DPCD versions are independent.  Differences from 1.0 are not noted,
+ * 1.0 devices basically don't exist in the wild.
+ *
+ * Abbreviations, in chronological order:
+ *
+ * eDP: Embedded DisplayPort version 1
+ * DPI: DisplayPort Interoperability Guideline v1.1a
+ * 1.2: DisplayPort 1.2
+ * MST: Multistream Transport - part of DP 1.2a
+ *
+ * 1.2 formally includes both eDP and DPI definitions.
+ */
+
+/* MSA (Main Stream Attribute) MISC bits (as MISC1<<8|MISC0) */
+#define DP_MSA_MISC_SYNC_CLOCK (1 << 0)
+#define DP_MSA_MISC_INTERLACE_VTOTAL_EVEN  (1 << 8)
+#define DP_MSA_MISC_STEREO_NO_3D   (0 << 9)
+#define DP_MSA_MISC_STEREO_PROG_RIGHT_EYE  (1 << 9)
+#define DP_MSA_MISC_STEREO_PROG_LEFT_EYE   (3 << 9)
+/* bits per component for non-RAW */
+#define DP_MSA_MISC_6_BPC  (0 << 5)
+#define DP_MSA_MISC_8_BPC  (1 << 5)
+#define DP_MSA_MISC_10_BPC (2 << 5)
+#define DP_MSA_MISC_12_BPC (3 << 5)
+#define DP_MSA_MISC_16_BPC (4 << 5)
+/* bits per component for RAW */
+#define DP_MSA_MISC_RAW_6_BPC  (1 << 5)
+#define DP_MSA_MISC_RAW_7_BPC  (2 << 5)
+#define DP_MSA_MISC_RAW_8_BPC  (3 << 5)
+#define DP_MSA_MISC_RAW_10_BPC (4 << 5)
+#define DP_MSA_MISC_RAW_12_BPC (5 << 5)
+#define DP_MSA_MISC_RAW_14_BPC (6 << 5)
+#define DP_MSA_MISC_RAW_16_BPC (7 << 5)
+/* pixel encoding/colorimetry format */
+#define _DP_MSA_MISC_COLOR(misc1_7, misc0_21, misc0_3, misc0_4) \
+   ((misc1_7) << 15 | (misc0_4) << 4 | (misc0_3) << 3 | ((misc0_21) << 1))
+#define DP_MSA_MISC_COLOR_RGB  _DP_MSA_MISC_COLOR(0, 0, 0, 0)
+#define DP_MSA_MISC_COLOR_CEA_RGB  _DP_MSA_MISC_COLOR(0, 0, 1, 0)
+#define DP_MSA_MISC_COLOR_RGB_WIDE_FIXED   _DP_MSA_MISC_COLOR(0, 3, 0, 0)
+#define DP_MSA_MISC_COLOR_RGB_WIDE_FLOAT   _DP_MSA_MISC_COLOR(0, 3, 0, 1)
+#define DP_MSA_MISC_COLOR_Y_ONLY   _DP_MSA_MISC_COLOR(1, 0, 0, 0)
+#define DP_MSA_MISC_COLOR_RAW  _DP_MSA_MISC_COLOR(1, 1, 0, 0)
+#define DP_MSA_MISC_COLOR_YCBCR_422_BT601  _DP_MSA_MISC_COLOR(0, 1, 1, 0)
+#define DP_MSA_MISC_COLOR_YCBCR_422_BT709  _DP_MSA_MISC_COLOR

[PATCH v2 8/8] drm/display: Move SCDC helpers into display-helper library

[Thomas Zimmermann]

SCDC is the Status and Control Data Channel for HDMI. Move the SCDC
helpers into display/ and split the header into files for core and
helpers. Update all affected drivers. No functional changes.

To avoid the proliferation of Kconfig options, SCDC is part of DRM's
support for HDMI. If necessary, a new option could make SCDC an
independent feature.

Signed-off-by: Thomas Zimmermann 
---
 Documentation/gpu/drm-kms-helpers.rst |  6 +-
 drivers/gpu/drm/Makefile  |  2 +-
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c |  2 +-
 drivers/gpu/drm/display/Makefile  |  3 +-
 .../gpu/drm/{ => display}/drm_scdc_helper.c   |  3 +-
 drivers/gpu/drm/drm_edid.c|  1 -
 drivers/gpu/drm/i915/display/intel_ddi.c  |  2 +-
 drivers/gpu/drm/i915/display/intel_hdmi.c |  2 +-
 drivers/gpu/drm/nouveau/Kconfig   |  1 +
 drivers/gpu/drm/nouveau/dispnv50/disp.c   |  2 +-
 drivers/gpu/drm/tegra/Kconfig |  1 +
 drivers/gpu/drm/tegra/sor.c   |  2 +-
 drivers/gpu/drm/vc4/vc4_hdmi.c|  2 +-
 .../{drm_scdc_helper.h => display/drm_scdc.h} | 52 +---
 include/drm/display/drm_scdc_helper.h | 79 +++
 15 files changed, 97 insertions(+), 63 deletions(-)
 rename drivers/gpu/drm/{ => display}/drm_scdc_helper.c (99%)
 rename include/drm/{drm_scdc_helper.h => display/drm_scdc.h} (65%)
 create mode 100644 include/drm/display/drm_scdc_helper.h

diff --git a/Documentation/gpu/drm-kms-helpers.rst 
b/Documentation/gpu/drm-kms-helpers.rst
index cfda5a092a48..2d473bc64c9f 100644
--- a/Documentation/gpu/drm-kms-helpers.rst
+++ b/Documentation/gpu/drm-kms-helpers.rst
@@ -356,13 +356,13 @@ EDID Helper Functions Reference
 SCDC Helper Functions Reference
 ===
 
-.. kernel-doc:: drivers/gpu/drm/drm_scdc_helper.c
+.. kernel-doc:: drivers/gpu/drm/display/drm_scdc_helper.c
:doc: scdc helpers
 
-.. kernel-doc:: include/drm/drm_scdc_helper.h
+.. kernel-doc:: include/drm/display/drm_scdc_helper.h
:internal:
 
-.. kernel-doc:: drivers/gpu/drm/drm_scdc_helper.c
+.. kernel-doc:: drivers/gpu/drm/display/drm_scdc_helper.c
:export:
 
 HDMI Infoframes Helper Reference
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 746a3a4953f3..15fe3163f822 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -63,7 +63,7 @@ drm_kms_helper-y := drm_bridge_connector.o drm_crtc_helper.o \
drm_plane_helper.o drm_atomic_helper.o \
drm_kms_helper_common.o \
drm_simple_kms_helper.o drm_modeset_helper.o \
-   drm_scdc_helper.o drm_gem_atomic_helper.o \
+   drm_gem_atomic_helper.o \
drm_gem_framebuffer_helper.o \
drm_atomic_state_helper.o drm_damage_helper.o \
drm_format_helper.o drm_self_refresh_helper.o drm_rect.o
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index a06a2d51e77f..268d1f47d58c 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -26,13 +26,13 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
-#include 
 
 #include "dw-hdmi-audio.h"
 #include "dw-hdmi-cec.h"
diff --git a/drivers/gpu/drm/display/Makefile b/drivers/gpu/drm/display/Makefile
index db644e7a550d..52cdda1180d9 100644
--- a/drivers/gpu/drm/display/Makefile
+++ b/drivers/gpu/drm/display/Makefile
@@ -8,7 +8,8 @@ drm_display_helper-$(CONFIG_DRM_DISPLAY_DP_HELPER) += 
drm_dp_dual_mode_helper.o
  drm_dp_mst_topology.o \
  drm_dsc_helper.o
 drm_display_helper-$(CONFIG_DRM_DISPLAY_HDCP_HELPER) += drm_hdcp_helper.o
-drm_display_helper-$(CONFIG_DRM_DISPLAY_HDMI_HELPER) += drm_hdmi_helper.o
+drm_display_helper-$(CONFIG_DRM_DISPLAY_HDMI_HELPER) += drm_hdmi_helper.o \
+   drm_scdc_helper.o
 drm_display_helper-$(CONFIG_DRM_DP_AUX_CHARDEV) += drm_dp_aux_dev.o
 drm_display_helper-$(CONFIG_DRM_DP_CEC) += drm_dp_cec.o
 
diff --git a/drivers/gpu/drm/drm_scdc_helper.c 
b/drivers/gpu/drm/display/drm_scdc_helper.c
similarity index 99%
rename from drivers/gpu/drm/drm_scdc_helper.c
rename to drivers/gpu/drm/display/drm_scdc_helper.c
index 48a382464d54..81881e81ceae 100644
--- a/drivers/gpu/drm/drm_scdc_helper.c
+++ b/drivers/gpu/drm/display/drm_scdc_helper.c
@@ -21,11 +21,12 @@
  * DEALINGS IN THE SOFTWARE.
  */
 
+#include 
 #include 
 #include 
 
+#include 
 #include 
-#include 
 
 /**
  * DOC: scdc helpers
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 8d5f0cbbf0b4..7a8482b75071 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -42,7 +42,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #include "drm_crtc_internal.h"
 
dif

Re: [PATCH v5 5/9] drm: vkms: Add fb information to `vkms_writeback_job`

[Pekka Paalanen]

On Mon,  4 Apr 2022 17:45:11 -0300
Igor Torrente  wrote:

> This commit is the groundwork to introduce new formats to the planes and
> writeback buffer. As part of it, a new buffer metadata field is added to
> `vkms_writeback_job`, this metadata is represented by the `vkms_composer`
> struct.

Hi,

should this be talking about vkms_frame_info struct instead?

> 
> Also adds two new function pointers (`{wb,plane}_format_transform_func`)
> are defined to handle format conversion to/from internal format.
> 
> These things will allow us, in the future, to have different compositing
> and wb format types.
> 
> V2: Change the code to get the drm_framebuffer reference and not copy its
> contents(Thomas Zimmermann).
> V3: Drop the refcount in the wb code(Thomas Zimmermann).
> V5: Add {wb,plane}_format_transform_func to vkms_writeback_job
> and vkms_plane_state (Pekka Paalanen)
> 
> Signed-off-by: Igor Torrente 
> ---
>  drivers/gpu/drm/vkms/vkms_composer.c  |  4 ++--
>  drivers/gpu/drm/vkms/vkms_drv.h   | 31 +--
>  drivers/gpu/drm/vkms/vkms_plane.c | 10 -
>  drivers/gpu/drm/vkms/vkms_writeback.c | 20 ++---
>  4 files changed, 49 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vkms/vkms_composer.c 
> b/drivers/gpu/drm/vkms/vkms_composer.c
> index 2d946368a561..95029d2ebcac 100644
> --- a/drivers/gpu/drm/vkms/vkms_composer.c
> +++ b/drivers/gpu/drm/vkms/vkms_composer.c
> @@ -153,7 +153,7 @@ static void compose_plane(struct vkms_frame_info 
> *primary_plane_info,
> struct vkms_frame_info *plane_frame_info,
> void *vaddr_out)
>  {
> - struct drm_framebuffer *fb = &plane_frame_info->fb;
> + struct drm_framebuffer *fb = plane_frame_info->fb;
>   void *vaddr;
>   void (*pixel_blend)(const u8 *p_src, u8 *p_dst);
>  
> @@ -175,7 +175,7 @@ static int compose_active_planes(void **vaddr_out,
>struct vkms_frame_info *primary_plane_info,
>struct vkms_crtc_state *crtc_state)
>  {
> - struct drm_framebuffer *fb = &primary_plane_info->fb;
> + struct drm_framebuffer *fb = primary_plane_info->fb;
>   struct drm_gem_object *gem_obj = drm_gem_fb_get_obj(fb, 0);
>   const void *vaddr;
>   int i;
> diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h
> index 2e6342164bef..2704cfb6904b 100644
> --- a/drivers/gpu/drm/vkms/vkms_drv.h
> +++ b/drivers/gpu/drm/vkms/vkms_drv.h
> @@ -22,13 +22,8 @@
>  
>  #define NUM_OVERLAY_PLANES 8
>  
> -struct vkms_writeback_job {
> - struct dma_buf_map map[DRM_FORMAT_MAX_PLANES];
> - struct dma_buf_map data[DRM_FORMAT_MAX_PLANES];
> -};
> -
>  struct vkms_frame_info {
> - struct drm_framebuffer fb;
> + struct drm_framebuffer *fb;
>   struct drm_rect src, dst;
>   struct dma_buf_map map[DRM_FORMAT_MAX_PLANES];
>   unsigned int offset;
> @@ -36,6 +31,29 @@ struct vkms_frame_info {
>   unsigned int cpp;
>  };
>  
> +struct pixel_argb_u16 {
> + u16 a, r, g, b;
> +};
> +
> +struct line_buffer {
> + size_t n_pixels;
> + struct pixel_argb_u16 *pixels;
> +};
> +
> +typedef void
> +(*wb_format_transform_func)(struct vkms_frame_info *frame_info,
> + const struct line_buffer *buffer, int y);
> +
> +typedef void
> +(*plane_format_transform_func)(struct line_buffer *buffer,
> +const struct vkms_frame_info *frame_info, int y);

It wasn't immediately obvious to me in which direction these function
types work from their names. The arguments are not wb and plane but
vkms_frame_info and line_buffer in both. The implementations of these
functions would have nothing specific to a wb or a plane either, would
they?

What about naming them frame_to_line_func and line_to_frame_func?

> +
> +struct vkms_writeback_job {
> + struct dma_buf_map data[DRM_FORMAT_MAX_PLANES];
> + struct vkms_frame_info frame_info;

Which frame_info is this? Should the field be called wb_frame_info?

> + wb_format_transform_func format_func;

line_to_frame_func wb_write;

perhaps? The type explains the general type of the function, and the
field name refers to what it is used for.

> +};
> +
>  /**
>   * vkms_plane_state - Driver specific plane state
>   * @base: base plane state
> @@ -44,6 +62,7 @@ struct vkms_frame_info {
>  struct vkms_plane_state {
>   struct drm_shadow_plane_state base;
>   struct vkms_frame_info *frame_info;
> + plane_format_transform_func format_func;

Similarly here, maybe

frame_to_line_func plane_read;

perhaps?

>  };
>  
>  struct vkms_plane {
> diff --git a/drivers/gpu/drm/vkms/vkms_plane.c 
> b/drivers/gpu/drm/vkms/vkms_plane.c
> index a56b0f76eddd..28752af0118c 100644
> --- a/drivers/gpu/drm/vkms/vkms_plane.c
> +++ b/drivers/gpu/drm/vkms/vkms_plane.c
> @@ -50,12 +50,12 @@ static void vkms_plane_destroy_state(struct drm_plane 
> *plane,
>   struct vkms_pla

Re: [PATCH] drm/ttm: fix ttm tt init fail when size exceeds kmalloc limit

[Wang, Yang(Kevin)]

[AMD Official Use Only]

Hi Chris,

you misunderstood background about this case.

although we expect this test case to fail, it should fail at the location where 
the Bo actual memory is actually allocated. now the code logic will cause the 
failure to allocate memory to store DMA address.

e.g: the case is failed in 2TB system ram machine, it should be allocated 
successful, but it is failed.

allocate 1TB BO, the ttm should allocate 1TB/4k * 8 buffer to store allocate 
result (page address), this should not be failed usually.

There is a similar fix in upstream kernel 5.18, before this fix entered the TTM 
code, this problem existed in TTM.

kernel/git/torvalds/linux.git - Linux kernel source 
tree
mm: allow !GFP_KERNEL allocations for kvmalloc

Best Regards,
Kevin


From: Koenig, Christian 
Sent: Wednesday, April 20, 2022 6:53 PM
To: Wang, Yang(Kevin) ; dri-devel@lists.freedesktop.org 
; amd-...@lists.freedesktop.org 

Subject: Re: [PATCH] drm/ttm: fix ttm tt init fail when size exceeds kmalloc 
limit

Am 20.04.22 um 11:07 schrieb Wang, Yang(Kevin):

[AMD Official Use Only]



From: Koenig, Christian 

Sent: Wednesday, April 20, 2022 5:00 PM
To: Wang, Yang(Kevin) ; 
dri-devel@lists.freedesktop.org 
; 
amd-...@lists.freedesktop.org 

Subject: Re: [PATCH] drm/ttm: fix ttm tt init fail when size exceeds kmalloc 
limit

Am 20.04.22 um 10:56 schrieb Yang Wang:
> if the __GFP_ZERO is set, the kvmalloc() can't fallback to use vmalloc()

Hui what? Why should kvmalloc() not be able to fallback to vmalloc()
when __GFP_ZERO is set?

And even that is really the case then that sounds like a bug in kvmalloc().

Regards,
Christian.

[kevin]:
it is really test case from libdrm amdgpu test, which try to allocate a big BO 
which will cause ttm tt init fail.


LOL! Guys, this test case is intended to fail!

The test consists of allocating a buffer so ridiculous large that it should 
never succeed and be rejected by the kernel driver.

This patch here is a really clear NAK.

Regards,
Christian.

it may be a kvmalloc() bug, and this patch can as a workaround in ttm before 
this issue fix.

void *kvmalloc_node(size_t size, gfp_t flags, int node)
{
...
if ((flags & GFP_KERNEL) != GFP_KERNEL)
return kmalloc_node(size, flags, node);
...
}

Best Regards,
Kevin

> to allocate memory, when request size is exceeds kmalloc limit, it will
> cause allocate memory fail.
>
> e.g: when ttm want to create a BO with 1TB size, it maybe fail.
>
> Signed-off-by: Yang Wang 
> 
> ---
>   drivers/gpu/drm/ttm/ttm_tt.c | 14 +++---
>   1 file changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
> index 79c870a3bef8..9f2f3e576b8d 100644
> --- a/drivers/gpu/drm/ttm/ttm_tt.c
> +++ b/drivers/gpu/drm/ttm/ttm_tt.c
> @@ -97,9 +97,12 @@ int ttm_tt_create(struct ttm_buffer_object *bo, bool 
> zero_alloc)
>   static int ttm_tt_alloc_page_directory(struct ttm_tt *ttm)
>   {
>ttm->pages = kvmalloc_array(ttm->num_pages, sizeof(void*),
> - GFP_KERNEL | __GFP_ZERO);
> + GFP_KERNEL);
>if (!ttm->pages)
>return -ENOMEM;
> +
> + memset(ttm->pages, 0, ttm->num_pages * sizeof(void *));
> +
>return 0;
>   }
>
> @@ -108,10 +111,12 @@ static int ttm_dma_tt_alloc_page_directory(struct 
> ttm_tt *ttm)
>ttm->pages = kvmalloc_array(ttm->num_pages,
>sizeof(*ttm->pages) +
>sizeof(*ttm->dma_address),
> - GFP_KERNEL | __GFP_ZERO);
> + GFP_KERNEL);
>if (!ttm->pages)
>return -ENOMEM;
>
> + memset(ttm->pages, 0, ttm->num_pages * (sizeof(*ttm->pages) + 
> sizeof(*ttm->dma_address)));
> +
>ttm->dma_address = (void *)(ttm->pages + ttm->num_pages);
>return 0;
>   }
> @@ -120,9 +125,12 @@ static int ttm_sg_tt_alloc_page_directory(struct ttm_tt 
> *ttm)
>   {
>ttm->dma_address = kvmalloc_array(ttm->num_pages,
>  sizeof(*ttm->dma_address),
> -   GFP_KERNEL | __GFP_ZERO);
> +   GFP_KERNEL);
>if (!ttm->dma_address)
>return -ENOMEM;
> +
> + memset(ttm->dma_address, 0, ttm->num_pages * sizeof(*ttm->dma_address));
> +
>return 0;
>   }
>

Re: [PATCH 01/41] video: fbdev: omapfb: lcd_ams_delta: fix unused variable warning

[Arnd Bergmann]

On Wed, Apr 20, 2022 at 11:24 AM Sergei Shtylyov
 wrote:
> On 4/19/22 4:36 PM, Arnd Bergmann wrote:
>
> > From: Arnd Bergmann 
> >
> > A recent cleanup patch removed the only reference to a local variable
> > in some configurations.
> >
> > Move the variable into the one block it is still used in, inside
> > of an #ifdef, to avoid this warning.
> >
> > Fixes: 9d773f103b89 ("video: fbdev: omapfb: lcd_ams_delta: Make use of the 
> > helper function dev_err_probe()")
> > Signed-off-by: Arnd Bergmann 
> > ---
> >  drivers/video/fbdev/omap/lcd_ams_delta.c | 3 +--
> >  1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/drivers/video/fbdev/omap/lcd_ams_delta.c 
> > b/drivers/video/fbdev/omap/lcd_ams_delta.c
> > index bbf871f9d862..01944ce46aa1 100644
> > --- a/drivers/video/fbdev/omap/lcd_ams_delta.c
> > +++ b/drivers/video/fbdev/omap/lcd_ams_delta.c
> [...]
> > @@ -145,7 +144,7 @@ static int ams_delta_panel_probe(struct platform_device 
> > *pdev)
> >   &ams_delta_lcd_ops);
> >
> >   if (IS_ERR(lcd_device)) {
> > - ret = PTR_ERR(lcd_device);
> > + int ret = PTR_ERR(lcd_device);
>
>How about inserting an empty line after declaration?

Ok, done.

Arnd

[PATCH v3 0/2] drm/vc4: hdmi: Replace drm_detect_hdmi_monitor() with drm_display_info.is_hdmi

[José Expósito]

Hi everyone,

These patches replace the calls to drm_detect_hdmi_monitor() with the
more efficient drm_display_info.is_hdmi in the VC4 driver and, since
this makes the vc4_hdmi_encoder struct redundant, also removes it.

Thanks,
José Expósito

v1: 
https://lore.kernel.org/dri-devel/20220406165514.6106-1-jose.exposit...@gmail.com/

v2: 
https://lore.kernel.org/dri-devel/20220415154745.170597-1-jose.exposit...@gmail.com/T/
Add the ftrace command used in the first patch
Remove vc4_hdmi_encoder.hdmi_monitor
(Thanks to Maxime for suggesting these changes)

v3: Squash the patches present in v2
Remove vc4_hdmi_encoder
(Thanks to Maxime for suggesting these changes)

José Expósito (2):
  drm/vc4: hdmi: Replace drm_detect_hdmi_monitor() with is_hdmi
  drm/vc4: hdmi: Remove vc4_hdmi_encoder

 drivers/gpu/drm/vc4/vc4_hdmi.c | 41 +++---
 drivers/gpu/drm/vc4/vc4_hdmi.h | 17 ++
 2 files changed, 20 insertions(+), 38 deletions(-)

-- 
2.25.1

[PATCH v3 1/2] drm/vc4: hdmi: Replace drm_detect_hdmi_monitor() with is_hdmi

[José Expósito]

Once EDID is parsed, the monitor HDMI support information is cached in
drm_display_info.is_hdmi by drm_parse_hdmi_vsdb_video().

This driver calls drm_detect_hdmi_monitor() to receive the same
information and stores its own cached value in
vc4_hdmi_encoder.hdmi_monitor, which is less efficient.

Avoid calling drm_detect_hdmi_monitor() and use drm_display_info.is_hdmi
instead. This also allows to remove vc4_hdmi_encoder.hdmi_monitor.

drm_detect_hdmi_monitor() is called in vc4_hdmi_connector_detect() and
vc4_hdmi_connector_get_modes(). In both cases it is safe to rely on
drm_display_info.is_hdmi as shown by ftrace:

$ sudo trace-cmd record -p function_graph -l "vc4_hdmi_*" -l "drm_*"

vc4_hdmi_connector_detect:

vc4_hdmi_connector_detect() {
  drm_get_edid() {
drm_connector_update_edid_property() {
  drm_add_display_info() {
drm_reset_display_info();
drm_for_each_detailed_block.part.0();
drm_parse_cea_ext() {
  drm_find_cea_extension();
  drm_parse_hdmi_vsdb_video();
  /* drm_display_info.is_hdmi is cached here */
}
  }
}
  }
  /* drm_display_info.is_hdmi is used here */
}

vc4_hdmi_connector_get_modes:

vc4_hdmi_connector_get_modes() {
  drm_get_edid() {
drm_connector_update_edid_property() {
  drm_add_display_info() {
drm_reset_display_info();
drm_for_each_detailed_block.part.0();
drm_parse_cea_ext() {
  drm_find_cea_extension();
  drm_parse_hdmi_vsdb_video();
  /* drm_display_info.is_hdmi is cached here */
}
  }
}
  }
  /* drm_display_info.is_hdmi is used here */
  drm_connector_update_edid_property();
}

Signed-off-by: José Expósito 
---
 drivers/gpu/drm/vc4/vc4_hdmi.c | 17 ++---
 drivers/gpu/drm/vc4/vc4_hdmi.h |  1 -
 2 files changed, 6 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 6c58b0fd13fb..9c73a211ae80 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -107,9 +107,9 @@ static bool vc4_hdmi_mode_needs_scrambling(const struct 
drm_display_mode *mode)
 static bool vc4_hdmi_is_full_range_rgb(struct vc4_hdmi *vc4_hdmi,
   const struct drm_display_mode *mode)
 {
-   struct vc4_hdmi_encoder *vc4_encoder = &vc4_hdmi->encoder;
+   struct drm_display_info *display = &vc4_hdmi->connector.display_info;
 
-   return !vc4_encoder->hdmi_monitor ||
+   return !display->is_hdmi ||
drm_default_rgb_quant_range(mode) == 
HDMI_QUANTIZATION_RANGE_FULL;
 }
 
@@ -216,7 +216,6 @@ vc4_hdmi_connector_detect(struct drm_connector *connector, 
bool force)
 
if (edid) {
cec_s_phys_addr_from_edid(vc4_hdmi->cec_adap, 
edid);
-   vc4_hdmi->encoder.hdmi_monitor = 
drm_detect_hdmi_monitor(edid);
kfree(edid);
}
}
@@ -242,7 +241,6 @@ static void vc4_hdmi_connector_destroy(struct drm_connector 
*connector)
 static int vc4_hdmi_connector_get_modes(struct drm_connector *connector)
 {
struct vc4_hdmi *vc4_hdmi = connector_to_vc4_hdmi(connector);
-   struct vc4_hdmi_encoder *vc4_encoder = &vc4_hdmi->encoder;
int ret = 0;
struct edid *edid;
 
@@ -255,8 +253,6 @@ static int vc4_hdmi_connector_get_modes(struct 
drm_connector *connector)
goto out;
}
 
-   vc4_encoder->hdmi_monitor = drm_detect_hdmi_monitor(edid);
-
drm_connector_update_edid_property(connector, edid);
ret = drm_add_edid_modes(connector, edid);
kfree(edid);
@@ -578,13 +574,12 @@ static void vc4_hdmi_set_infoframes(struct drm_encoder 
*encoder)
 static bool vc4_hdmi_supports_scrambling(struct drm_encoder *encoder,
 struct drm_display_mode *mode)
 {
-   struct vc4_hdmi_encoder *vc4_encoder = to_vc4_hdmi_encoder(encoder);
struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
struct drm_display_info *display = &vc4_hdmi->connector.display_info;
 
lockdep_assert_held(&vc4_hdmi->mutex);
 
-   if (!vc4_encoder->hdmi_monitor)
+   if (!display->is_hdmi)
return false;
 
if (!display->hdmi.scdc.supported ||
@@ -1147,7 +1142,7 @@ static void vc4_hdmi_encoder_post_crtc_enable(struct 
drm_encoder *encoder,
 {
struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
struct drm_display_mode *mode = &vc4_hdmi->saved_adjusted_mode;
-   struct vc4_hdmi_encoder *vc4_encoder = to_vc4_hdmi_encoder(encoder);
+   struct drm_display_info *display = &vc4_hdmi->connector.display_info;
bool hsync_pos = mode->flags & DRM_MODE_FLAG_PHSYNC;
bool vsync_pos = mode->flags & DRM_MODE_FLAG_

[PATCH v3 2/2] drm/vc4: hdmi: Remove vc4_hdmi_encoder

[José Expósito]

The vc4_hdmi_encoder struct was used exclusively to cache the value
returned by drm_detect_hdmi_monitor() in order to avoid calling it
multiple times.

Now that drm_detect_hdmi_monitor() has been replaced with
drm_display_info.is_hdmi, there is no need to have an extra struct.

Remove vc4_hdmi_encoder.

Signed-off-by: José Expósito 
---
 drivers/gpu/drm/vc4/vc4_hdmi.c | 24 
 drivers/gpu/drm/vc4/vc4_hdmi.h | 16 ++--
 2 files changed, 14 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 9c73a211ae80..f8d662fde5e0 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -220,7 +220,7 @@ vc4_hdmi_connector_detect(struct drm_connector *connector, 
bool force)
}
}
 
-   vc4_hdmi_enable_scrambling(&vc4_hdmi->encoder.base.base);
+   vc4_hdmi_enable_scrambling(&vc4_hdmi->encoder.base);
pm_runtime_put(&vc4_hdmi->pdev->dev);
mutex_unlock(&vc4_hdmi->mutex);
return connector_status_connected;
@@ -357,7 +357,7 @@ static int vc4_hdmi_connector_init(struct drm_device *dev,
   struct vc4_hdmi *vc4_hdmi)
 {
struct drm_connector *connector = &vc4_hdmi->connector;
-   struct drm_encoder *encoder = &vc4_hdmi->encoder.base.base;
+   struct drm_encoder *encoder = &vc4_hdmi->encoder.base;
int ret;
 
drm_connector_init_with_ddc(dev, connector,
@@ -1463,7 +1463,7 @@ static int vc4_hdmi_audio_startup(struct device *dev, 
void *data)
 
 static void vc4_hdmi_audio_reset(struct vc4_hdmi *vc4_hdmi)
 {
-   struct drm_encoder *encoder = &vc4_hdmi->encoder.base.base;
+   struct drm_encoder *encoder = &vc4_hdmi->encoder.base;
struct device *dev = &vc4_hdmi->pdev->dev;
unsigned long flags;
int ret;
@@ -1553,7 +1553,7 @@ static int vc4_hdmi_audio_prepare(struct device *dev, 
void *data,
  struct hdmi_codec_params *params)
 {
struct vc4_hdmi *vc4_hdmi = dev_get_drvdata(dev);
-   struct drm_encoder *encoder = &vc4_hdmi->encoder.base.base;
+   struct drm_encoder *encoder = &vc4_hdmi->encoder.base;
unsigned int sample_rate = params->sample_rate;
unsigned int channels = params->channels;
unsigned long flags;
@@ -2506,13 +2506,13 @@ static int vc4_hdmi_bind(struct device *dev, struct 
device *master, void *data)
INIT_DELAYED_WORK(&vc4_hdmi->scrambling_work, vc4_hdmi_scrambling_wq);
 
dev_set_drvdata(dev, vc4_hdmi);
-   encoder = &vc4_hdmi->encoder.base.base;
-   vc4_hdmi->encoder.base.type = variant->encoder_type;
-   vc4_hdmi->encoder.base.pre_crtc_configure = 
vc4_hdmi_encoder_pre_crtc_configure;
-   vc4_hdmi->encoder.base.pre_crtc_enable = 
vc4_hdmi_encoder_pre_crtc_enable;
-   vc4_hdmi->encoder.base.post_crtc_enable = 
vc4_hdmi_encoder_post_crtc_enable;
-   vc4_hdmi->encoder.base.post_crtc_disable = 
vc4_hdmi_encoder_post_crtc_disable;
-   vc4_hdmi->encoder.base.post_crtc_powerdown = 
vc4_hdmi_encoder_post_crtc_powerdown;
+   encoder = &vc4_hdmi->encoder.base;
+   vc4_hdmi->encoder.type = variant->encoder_type;
+   vc4_hdmi->encoder.pre_crtc_configure = 
vc4_hdmi_encoder_pre_crtc_configure;
+   vc4_hdmi->encoder.pre_crtc_enable = vc4_hdmi_encoder_pre_crtc_enable;
+   vc4_hdmi->encoder.post_crtc_enable = vc4_hdmi_encoder_post_crtc_enable;
+   vc4_hdmi->encoder.post_crtc_disable = 
vc4_hdmi_encoder_post_crtc_disable;
+   vc4_hdmi->encoder.post_crtc_powerdown = 
vc4_hdmi_encoder_post_crtc_powerdown;
vc4_hdmi->pdev = pdev;
vc4_hdmi->variant = variant;
 
@@ -2674,7 +2674,7 @@ static void vc4_hdmi_unbind(struct device *dev, struct 
device *master,
vc4_hdmi_cec_exit(vc4_hdmi);
vc4_hdmi_hotplug_exit(vc4_hdmi);
vc4_hdmi_connector_destroy(&vc4_hdmi->connector);
-   drm_encoder_cleanup(&vc4_hdmi->encoder.base.base);
+   drm_encoder_cleanup(&vc4_hdmi->encoder.base);
 
pm_runtime_disable(dev);
 
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h b/drivers/gpu/drm/vc4/vc4_hdmi.h
index 44977002445f..71768915cc4b 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.h
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
@@ -8,17 +8,6 @@
 
 #include "vc4_drv.h"
 
-/* VC4 HDMI encoder KMS struct */
-struct vc4_hdmi_encoder {
-   struct vc4_encoder base;
-};
-
-static inline struct vc4_hdmi_encoder *
-to_vc4_hdmi_encoder(struct drm_encoder *encoder)
-{
-   return container_of(encoder, struct vc4_hdmi_encoder, base.base);
-}
-
 struct vc4_hdmi;
 struct vc4_hdmi_register;
 struct vc4_hdmi_connector_state;
@@ -127,7 +116,7 @@ struct vc4_hdmi {
struct platform_device *pdev;
const struct vc4_hdmi_variant *variant;
 
-   struct vc4_hdmi_encoder encoder;
+   struct vc4_encoder encoder;
struct drm_connector connector;
 
struct delay

Re: [PATCH] drm/ttm: fix ttm tt init fail when size exceeds kmalloc limit

[Christian König]

Hi Kevin,

no, the test case should already fail in amdgpu_bo_validate_size().

If we have a system with 2TiB of memory where the test case could 
succeed then we should increase the requested size to something larger.


And if the underlying core Linux kernel functions don't allow 
allocations as large as the requested one we should *NEVER* ever add 
workarounds like this.


It is perfectly expected that this test case is not able to fulfill the 
desired allocation. That it fails during kvmalloc is unfortunate, but 
not a show stopper.


Regards,
Christian.


Am 20.04.22 um 13:32 schrieb Wang, Yang(Kevin):


[AMD Official Use Only]


Hi Chris,

you misunderstood background about this case.

although we expect this test case to fail, it should fail at the 
location where the Bo actual memory is actually allocated. now the 
code logic will cause the failure to allocate memory to store DMA address.


e.g: the case is failed in 2TB system ram machine, it should be 
allocated successful, but it is failed.


allocate 1TB BO, the ttm should allocate 1TB/4k * 8 buffer to store 
allocate result (page address), this should not be failed usually.


There is a similar fix in upstream kernel 5.18, before this fix 
entered the TTM code, this problem existed in TTM.


kernel/git/torvalds/linux.git - Linux kernel source tree 


mm: allow !GFP_KERNEL allocations for kvmalloc

Best Regards,
Kevin


*From:* Koenig, Christian 
*Sent:* Wednesday, April 20, 2022 6:53 PM
*To:* Wang, Yang(Kevin) ; 
dri-devel@lists.freedesktop.org ; 
amd-...@lists.freedesktop.org 
*Subject:* Re: [PATCH] drm/ttm: fix ttm tt init fail when size exceeds 
kmalloc limit

Am 20.04.22 um 11:07 schrieb Wang, Yang(Kevin):


[AMD Official Use Only]




*From:* Koenig, Christian  


*Sent:* Wednesday, April 20, 2022 5:00 PM
*To:* Wang, Yang(Kevin)  
; dri-devel@lists.freedesktop.org 
 
 
; 
amd-...@lists.freedesktop.org  
 
*Subject:* Re: [PATCH] drm/ttm: fix ttm tt init fail when size 
exceeds kmalloc limit

Am 20.04.22 um 10:56 schrieb Yang Wang:
> if the __GFP_ZERO is set, the kvmalloc() can't fallback to use 
vmalloc()


Hui what? Why should kvmalloc() not be able to fallback to vmalloc()
when __GFP_ZERO is set?

And even that is really the case then that sounds like a bug in 
kvmalloc().


Regards,
Christian.

[kevin]:
it is really test case from libdrm amdgpu test, which try to allocate 
a big BO which will cause ttm tt init fail.



LOL! Guys, this test case is intended to fail!
*
*The test consists of allocating a buffer so ridiculous large that it 
should never succeed and be rejected by the kernel driver.


This patch here is a really clear NAK.

Regards,
Christian.

it may be a kvmalloc() bug, and this patch can as a workaround 
in ttm before this issue fix.


void *kvmalloc_node(size_t size, gfp_t flags, int node)
{
...
        if ((flags & GFP_KERNEL) != GFP_KERNEL)
  return kmalloc_node(size, flags, node);
...
}

Best Regards,
Kevin

> to allocate memory, when request size is exceeds kmalloc limit, it will
> cause allocate memory fail.
>
> e.g: when ttm want to create a BO with 1TB size, it maybe fail.
>
> Signed-off-by: Yang Wang  


> ---
>   drivers/gpu/drm/ttm/ttm_tt.c | 14 +++---
>   1 file changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_tt.c 
b/drivers/gpu/drm/ttm/ttm_tt.c

> index 79c870a3bef8..9f2f3e576b8d 100644
> --- a/drivers/gpu/drm/ttm/ttm_tt.c
> +++ b/drivers/gpu/drm/ttm/ttm_tt.c
> @@ -97,9 +97,12 @@ int ttm_tt_create(struct ttm_buffer_object *bo, 
bool zero_alloc)

>   static int ttm_tt_alloc_page_directory(struct ttm_tt *ttm)
>   {
>    ttm->pages = kvmalloc_array(ttm->num_pages, sizeof(void*),
> - GFP_KERNEL | __GFP_ZERO);
> + GFP_KERNEL);
>    if (!ttm->pages)
>    return -ENOMEM;
> +
> + memset(ttm->pages, 0, ttm->num_pages * sizeof(void *));
> +
>    return 0;
>   }
>
> @@ -108,10 +111,12 @@ static int 
ttm_dma_tt_alloc_page_directory(struct ttm_tt *ttm)

>    ttm->pages = kvmalloc_array(ttm->num_pages,
> sizeof(*ttm->pages) +
> sizeof(*ttm->dma_address),
> - GFP_KERNEL | __GFP_ZERO);
> + GFP_KERNEL);
>    if (!ttm->pages)
>    return -ENOMEM;
>
> + memset(ttm->pages, 0, ttm->num_pages * (sizeof(*ttm->pages) + 
sizeof(*ttm->dma_address)));

> +
>    ttm->dma_address = (void *)(ttm->pages + ttm->num_pages);
>    return 0;
>   }
> @@ -120,9 +125,12 @@ stat

Re: [PATCH v2 7/8] drm/display: Move HDMI helpers into display-helper module

[Javier Martinez Canillas]

Hello Thomas,

On 4/20/22 13:08, Thomas Zimmermann wrote:

[snip]

> --- a/drivers/gpu/drm/bridge/synopsys/Kconfig
> +++ b/drivers/gpu/drm/bridge/synopsys/Kconfig
> @@ -1,6 +1,8 @@
>  # SPDX-License-Identifier: GPL-2.0-only
>  config DRM_DW_HDMI
>   tristate
> + select DRM_DISPLAY_HDMI_HELPER
> + select DRM_DISPLAY_HELPER
>   select DRM_KMS_HELPER
>   select REGMAP_MMIO
>   select CEC_CORE if CEC_NOTIFIER

[snip]

> +config DRM_DISPLAY_HDMI_HELPER
> + bool
> + select DRM_DISPLAY_HELPER
> + help
> +   DRM display helpers for HDMI.
> +

Maybe you mentioned already when we discussed it in v1, but could
you please remember me why we need to select both symbols for the
drivers, even when DRM_DISPLAY_HELPER is already selected here ?

Or are select operations not transitive ?

-- 
Best regards,

Javier Martinez Canillas
Linux Engineering
Red Hat

Re: [PATCH v2 8/8] drm/display: Move SCDC helpers into display-helper library

[Javier Martinez Canillas]

On 4/20/22 13:09, Thomas Zimmermann wrote:
> SCDC is the Status and Control Data Channel for HDMI. Move the SCDC
> helpers into display/ and split the header into files for core and
> helpers. Update all affected drivers. No functional changes.
> 
> To avoid the proliferation of Kconfig options, SCDC is part of DRM's
> support for HDMI. If necessary, a new option could make SCDC an
> independent feature.
> 
> Signed-off-by: Thomas Zimmermann 
> ---
Looks good to me.

Reviewed-by: Javier Martinez Canillas 

-- 
Best regards,

Javier Martinez Canillas
Linux Engineering
Red Hat

Re: [PATCH v2 7/8] drm/display: Move HDMI helpers into display-helper module

[Thomas Zimmermann]

Hi

Am 20.04.22 um 14:02 schrieb Javier Martinez Canillas:

Hello Thomas,

On 4/20/22 13:08, Thomas Zimmermann wrote:

[snip]


--- a/drivers/gpu/drm/bridge/synopsys/Kconfig
+++ b/drivers/gpu/drm/bridge/synopsys/Kconfig
@@ -1,6 +1,8 @@
  # SPDX-License-Identifier: GPL-2.0-only
  config DRM_DW_HDMI
tristate
+   select DRM_DISPLAY_HDMI_HELPER
+   select DRM_DISPLAY_HELPER
select DRM_KMS_HELPER
select REGMAP_MMIO
select CEC_CORE if CEC_NOTIFIER


[snip]


+config DRM_DISPLAY_HDMI_HELPER
+   bool
+   select DRM_DISPLAY_HELPER
+   help
+ DRM display helpers for HDMI.
+


Maybe you mentioned already when we discussed it in v1, but could
you please remember me why we need to select both symbols for the
drivers, even when DRM_DISPLAY_HELPER is already selected here ?

Or are select operations not transitive ?


DRM_DISPLAY_HELPER enables the module itself. It's tristate. 
DRM_DISPLAY_HDMI_HELPER, DRM_DISPLAY_DP_HELPER, etc are the individual 
features of the helper module. Each is a boolean.  Drivers can enable 
them according to their needs.  This split allows linking correctly in 
all cases, even if some drivers are built-in and others are modules. 
This didn't always work with the original patches.


Best regards
Thomas





--
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: bridge: panel: Register connector if DRM device is already registered

[Marek Szyprowski]

Hi Laurent,

On 19.04.2022 19:37, Laurent Pinchart wrote:
> On Tue, Apr 19, 2022 at 06:16:07PM +0200, Robert Foss wrote:
>> On Tue, 19 Apr 2022 at 11:41, Jagan Teki  wrote:
>>> On Tue, Apr 19, 2022 at 2:44 PM Marek Szyprowski
>>>  wrote:
>>>> If panel_bridge_attach() happens after DRM device registration, the
>>>> created connector will not be registered by the DRM core anymore. Fix
>>>> this by registering it explicitely in such case.
>>>>
>>>> This fixes the following issue observed on Samsung Exynos4210-based Trats
>>>> board with a DSI panel (the panel driver is registed after the Exynos DRM
>>>> component device is bound):
>>>>
>>>> $ ./modetest -c -Mexynos
>>>> could not get connector 56: No such file or directory
>>>> Segmentation fault
>>>>
>>>> While touching this, move the connector reset() call also under the DRM
>>>> device registered check, because otherwise it is not really needed.
>>>>
>>>> Fixes: 934aef885f9d ("drm: bridge: panel: Reset the connector state 
>>>> pointer")
>>>> Signed-off-by: Marek Szyprowski 
>>>> ---
>>>> Here is a bit more backgroud on this issue is available in this thread:
>>>> https://lore.kernel.org/all/f0474a95-4ba3-a74f-d7de-ef7aab12b...@samsung.com/
>>>> ---
>>>>   drivers/gpu/drm/bridge/panel.c | 7 +--
>>>>   1 file changed, 5 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/bridge/panel.c 
>>>> b/drivers/gpu/drm/bridge/panel.c
>>>> index ff1c37b2e6e5..0ee563eb2b6f 100644
>>>> --- a/drivers/gpu/drm/bridge/panel.c
>>>> +++ b/drivers/gpu/drm/bridge/panel.c
>>>> @@ -83,8 +83,11 @@ static int panel_bridge_attach(struct drm_bridge 
>>>> *bridge,
>>>>  drm_connector_attach_encoder(&panel_bridge->connector,
>>>>bridge->encoder);
>>>>
>>>> -   if (connector->funcs->reset)
>>>> -   connector->funcs->reset(connector);
>>>> +   if (bridge->dev->registered) {
>>>> +   if (connector->funcs->reset)
>>>> +   connector->funcs->reset(connector);
>>>> +   drm_connector_register(connector);
>>>> +   }
>>> Reviewed-by: Jagan Teki 
>> Fixed typos in commit message.
>>
>> Reviewed-by: Robert Foss 
>>
>> Applied to drm-misc-next
> Doesn't this open the door to various race conditions ?

This only patch restores the old behavior of the Exynos DSI driver. IIRC 
Andrzej already checked the possible races and said that the late 
connector registration is fine.

> Also, what happens if the panel bridge is detached and reattached ? If I
> recall correctly, registering new connectors at runtime is at least
> partly supported for DP MST, but I'm not sure about unregistration.

Well, indeed the panel unregistration is broken now:

# rmmod panel_samsung_s6e8aa0
[ cut here ]
WARNING: CPU: 1 PID: 1336 at drivers/gpu/drm/drm_connector.c:462 
drm_connector_cleanup+0x26c/0x288
Modules linked in: cmac bnep hci_uart btbcm btintel bluetooth s5p_csis 
s5p_fimc exynos4_is_common ecdh_generic ecc v4l2_fwnode v4l2_async 
s5p_mfc brcmfmac cfg80211 brcmutil panel_samsung_s6e8aa0(-) s5p_jpeg 
videobuf2_dma_contig videobuf2_memops v4l2_mem2mem videobuf2_v4l2 
videobuf2_common videodev mc
CPU: 1 PID: 1336 Comm: rmmod Not tainted 
5.18.0-rc3-next-20220420-00033-g871e1a91a67f #4866
Hardware name: Samsung Exynos (Flattened Device Tree)
  unwind_backtrace from show_stack+0x10/0x14
  show_stack from dump_stack_lvl+0x58/0x70
  dump_stack_lvl from __warn+0xc8/0x218
  __warn from warn_slowpath_fmt+0x5c/0xb4
  warn_slowpath_fmt from drm_connector_cleanup+0x26c/0x288
  drm_connector_cleanup from exynos_dsi_host_detach+0x24/0x74
  exynos_dsi_host_detach from s6e8aa0_remove+0xc/0x1c 
[panel_samsung_s6e8aa0]
  s6e8aa0_remove [panel_samsung_s6e8aa0] from 
device_release_driver_internal+0x1a4/0x20c
  device_release_driver_internal from driver_detach+0x44/0x80
  driver_detach from bus_remove_driver+0x60/0xd8
  bus_remove_driver from sys_delete_module+0x138/0x22c
  sys_delete_module from ret_fast_syscall+0x0/0x1c
Exception stack(0xf0c01fa8 to 0xf0c01ff0)
1fa0:   005224d8 0002 00522514 0800 e2a92e00 
e2a92e00
1fc0: 005224d8 0002 005224d8 0081 be9daf02 be9dac1c be9dae08 
0001
1fe0: 00520f70 be9dabb4 00503ac4 b6e2a0fc
irq event stamp: 3465
hardirqs last  enabled at (3481): [] 
finish_task_switch+0x11

Re: [PATCH v2 7/8] drm/display: Move HDMI helpers into display-helper module

[Javier Martinez Canillas]

On 4/20/22 14:21, Thomas Zimmermann wrote:
> Hi
> 
> Am 20.04.22 um 14:02 schrieb Javier Martinez Canillas:
>> Hello Thomas,
>>
>> On 4/20/22 13:08, Thomas Zimmermann wrote:
>>
>> [snip]
>>
>>> --- a/drivers/gpu/drm/bridge/synopsys/Kconfig
>>> +++ b/drivers/gpu/drm/bridge/synopsys/Kconfig
>>> @@ -1,6 +1,8 @@
>>>   # SPDX-License-Identifier: GPL-2.0-only
>>>   config DRM_DW_HDMI
>>> tristate
>>> +   select DRM_DISPLAY_HDMI_HELPER
>>> +   select DRM_DISPLAY_HELPER
>>> select DRM_KMS_HELPER
>>> select REGMAP_MMIO
>>> select CEC_CORE if CEC_NOTIFIER
>>
>> [snip]
>>
>>> +config DRM_DISPLAY_HDMI_HELPER
>>> +   bool
>>> +   select DRM_DISPLAY_HELPER
>>> +   help
>>> + DRM display helpers for HDMI.
>>> +
>>
>> Maybe you mentioned already when we discussed it in v1, but could
>> you please remember me why we need to select both symbols for the
>> drivers, even when DRM_DISPLAY_HELPER is already selected here ?
>>
>> Or are select operations not transitive ?
> 
> DRM_DISPLAY_HELPER enables the module itself. It's tristate. 
> DRM_DISPLAY_HDMI_HELPER, DRM_DISPLAY_DP_HELPER, etc are the individual 
> features of the helper module. Each is a boolean.  Drivers can enable 
> them according to their needs.  This split allows linking correctly in 
> all cases, even if some drivers are built-in and others are modules. 
> This didn't always work with the original patches.
>
Right, but that wasn't my question. I wondered why for example DRM_DW_HDMI
Kconfig needs to select both DRM_DISPLAY_HDMI_HELPER and DRM_DISPLAY_HELPER
since DRM_DISPLAY_HDMI_HELPER already selects DRM_DISPLAY_HELPER.

-- 
Best regards,

Javier Martinez Canillas
Linux Engineering
Red Hat

Re: [PATCH v5 6/9] drm: vkms: Refactor the plane composer to accept new formats

[Pekka Paalanen]

On Mon,  4 Apr 2022 17:45:12 -0300
Igor Torrente  wrote:

> Currently the blend function only accepts XRGB_ and ARGB_
> as a color input.
> 
> This patch refactors all the functions related to the plane composition
> to overcome this limitation.
> 
> A new internal format(`struct pixel`) is introduced to deal with all

Hi,

struct pixel_argb_u16 was added in the previous patch.

> possible inputs. It consists of 16 bits fields that represent each of
> the channels.
> 
> The pixels blend is done using this internal format. And new handlers
> are being added to convert a specific format to/from this internal format.
> 
> So the blend operation depends on these handlers to convert to this common
> format. The blended result, if necessary, is converted to the writeback
> buffer format.
> 
> This patch introduces three major differences to the blend function.
> 1 - All the planes are blended at once.
> 2 - The blend calculus is done as per line instead of per pixel.
> 3 - It is responsible to calculates the CRC and writing the writeback
> buffer(if necessary).
> 
> These changes allow us to allocate way less memory in the intermediate
> buffer to compute these operations. Because now we don't need to
> have the entire intermediate image lines at once, just one line is
> enough.
> 
> | Memory consumption (output dimensions) |
> |:--:|
> |   Current  | This patch|
> |:--:|:-:|
> |   Width * Heigth   | 2 * Width |
> 
> Beyond memory, we also have a minor performance benefit from all
> these changes. Results running the IGT[1] test
> `igt@kms_cursor_crc@pipe-a-cursor-512x512-onscreen` ten times:
> 
> | Frametime  |
> |:--:|
> |  Implementation |  Current  |  This commit |
> |:---:|:-:|::|
> | frametime range |  9~22 ms  |5~17 ms   |
> | Average |  11.4 ms  |7.8 ms|
> 
> [1] IGT commit id: bc3f6833a12221a46659535dac06ebb312490eb4
> 
> V2: Improves the performance drastically, by performing the operations
> per-line and not per-pixel(Pekka Paalanen).
> Minor improvements(Pekka Paalanen).
> V3: Changes the code to blend the planes all at once. This improves
> performance, memory consumption, and removes much of the weirdness
> of the V2(Pekka Paalanen and me).
> Minor improvements(Pekka Paalanen and me).
> V4: Rebase the code and adapt it to the new NUM_OVERLAY_PLANES constant.
> V5: Minor checkpatch fixes and the removal of TO-DO item(Melissa Wen).
> Several security/robustness improvents(Pekka Paalanen).
> Removes check_planes_x_bounds function and allows partial
> partly off-screen(Pekka Paalanen).
> 
> Signed-off-by: Igor Torrente 
> ---
>  Documentation/gpu/vkms.rst|   4 -
>  drivers/gpu/drm/vkms/Makefile |   1 +
>  drivers/gpu/drm/vkms/vkms_composer.c  | 318 --
>  drivers/gpu/drm/vkms/vkms_formats.c   | 151 
>  drivers/gpu/drm/vkms/vkms_formats.h   |  12 +
>  drivers/gpu/drm/vkms/vkms_plane.c |   3 +
>  drivers/gpu/drm/vkms/vkms_writeback.c |   3 +
>  7 files changed, 311 insertions(+), 181 deletions(-)
>  create mode 100644 drivers/gpu/drm/vkms/vkms_formats.c
>  create mode 100644 drivers/gpu/drm/vkms/vkms_formats.h
> 
> diff --git a/Documentation/gpu/vkms.rst b/Documentation/gpu/vkms.rst
> index 973e2d43108b..a49e4ae92653 100644
> --- a/Documentation/gpu/vkms.rst
> +++ b/Documentation/gpu/vkms.rst
> @@ -118,10 +118,6 @@ Add Plane Features
>  
>  There's lots of plane features we could add support for:
>  
> -- Clearing primary plane: clear primary plane before plane composition (at 
> the
> -  start) for correctness of pixel blend ops. It also guarantees alpha channel
> -  is cleared in the target buffer for stable crc. [Good to get started]
> -
>  - ARGB format on primary plane: blend the primary plane into background with
>translucent alpha.
>  
> diff --git a/drivers/gpu/drm/vkms/Makefile b/drivers/gpu/drm/vkms/Makefile
> index 72f779cbfedd..1b28a6a32948 100644
> --- a/drivers/gpu/drm/vkms/Makefile
> +++ b/drivers/gpu/drm/vkms/Makefile
> @@ -3,6 +3,7 @@ vkms-y := \
>   vkms_drv.o \
>   vkms_plane.o \
>   vkms_output.o \
> + vkms_formats.o \
>   vkms_crtc.o \
>   vkms_composer.o \
>   vkms_writeback.o
> diff --git a/drivers/gpu/drm/vkms/vkms_composer.c 
> b/drivers/gpu/drm/vkms/vkms_composer.c
> index 95029d2ebcac..cf24015bf90f 100644
> --- a/drivers/gpu/drm/vkms/vkms_composer.c
> +++ b/drivers/gpu/drm/vkms/vkms_composer.c

(For this file, I have removed all the minus diff lines from below to
better see the new code.)


> @@ -7,204 +7,186 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "vkms_drv.h"
>  
> +static u16 pre_mul_blend_channel(u16 src, u16 dst, u16 alpha)
>  {
> + u32 new_color;
>  
> + new_color = (src * 0x + dst * (0xff

Re: [PATCH] drm/ttm: fix ttm tt init fail when size exceeds kmalloc limit

[Wang, Yang(Kevin)]

[AMD Official Use Only]

Hi Chirs,

yes, right, the amdgpu drive rwill use amdgpu_bo_validate_size() function to 
verify bo size,
but when driver try to allocate VRAM domain bo fail, the amdgpu driver will 
fall back to allocate domain = (GTT | VRAM)  bo.
please check following code, it will cause the 2nd time to allocate bo fail 
during allocate 256Mb buffer to store dma address (via kvmalloc()).

initial_domain = (u32)(0x & args->in.domains);
retry:
r = amdgpu_gem_object_create(adev, size, args->in.alignment,
 initial_domain,
 flags, ttm_bo_type_device, resv, &gobj);
if (r && r != -ERESTARTSYS) {
if (flags & AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED) {
flags &= ~AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED;
goto retry;
}

if (initial_domain == AMDGPU_GEM_DOMAIN_VRAM) {
initial_domain |= AMDGPU_GEM_DOMAIN_GTT;
goto retry;
}
DRM_DEBUG("Failed to allocate GEM object (%llu, %d, %llu, 
%d)\n",
size, initial_domain, args->in.alignment, r);
}

Best Regards,
Kevin


From: Christian König 
Sent: Wednesday, April 20, 2022 7:55 PM
To: Wang, Yang(Kevin) ; Koenig, Christian 
; dri-devel@lists.freedesktop.org 
; amd-...@lists.freedesktop.org 

Subject: Re: [PATCH] drm/ttm: fix ttm tt init fail when size exceeds kmalloc 
limit

Hi Kevin,

no, the test case should already fail in amdgpu_bo_validate_size().

If we have a system with 2TiB of memory where the test case could succeed then 
we should increase the requested size to something larger.

And if the underlying core Linux kernel functions don't allow allocations as 
large as the requested one we should *NEVER* ever add workarounds like this.

It is perfectly expected that this test case is not able to fulfill the desired 
allocation. That it fails during kvmalloc is unfortunate, but not a show 
stopper.

Regards,
Christian.


Am 20.04.22 um 13:32 schrieb Wang, Yang(Kevin):

[AMD Official Use Only]

Hi Chris,

you misunderstood background about this case.

although we expect this test case to fail, it should fail at the location where 
the Bo actual memory is actually allocated. now the code logic will cause the 
failure to allocate memory to store DMA address.

e.g: the case is failed in 2TB system ram machine, it should be allocated 
successful, but it is failed.

allocate 1TB BO, the ttm should allocate 1TB/4k * 8 buffer to store allocate 
result (page address), this should not be failed usually.

There is a similar fix in upstream kernel 5.18, before this fix entered the TTM 
code, this problem existed in TTM.

kernel/git/torvalds/linux.git - Linux kernel source 
tree
mm: allow !GFP_KERNEL allocations for kvmalloc

Best Regards,
Kevin


From: Koenig, Christian 

Sent: Wednesday, April 20, 2022 6:53 PM
To: Wang, Yang(Kevin) ; 
dri-devel@lists.freedesktop.org 
; 
amd-...@lists.freedesktop.org 

Subject: Re: [PATCH] drm/ttm: fix ttm tt init fail when size exceeds kmalloc 
limit

Am 20.04.22 um 11:07 schrieb Wang, Yang(Kevin):

[AMD Official Use Only]



From: Koenig, Christian 

Sent: Wednesday, April 20, 2022 5:00 PM
To: Wang, Yang(Kevin) ; 
dri-devel@lists.freedesktop.org 
; 
amd-...@lists.freedesktop.org 

Subject: Re: [PATCH] drm/ttm: fix ttm tt init fail when size exceeds kmalloc 
limit

Am 20.04.22 um 10:56 schrieb Yang Wang:
> if the __GFP_ZERO is set, the kvmalloc() can't fallback to use vmalloc()

Hui what? Why should kvmalloc() not be able to fallback to vmalloc()
when __GFP_ZERO is set?

And even that is really the case then that sounds like a bug in kvmalloc().

Regards,
Christian.

[kevin]:
it is really test case from libdrm amdgpu test, which try to allocate a big BO 
which will cause ttm tt init fail.

Re: [PATCH] drm/ttm: fix ttm tt init fail when size exceeds kmalloc limit

[Wang, Yang(Kevin)]

[AMD Official Use Only]

Hi Chris,

1) Change the test case to use something larger than 1TiB.
sure, we can increase the size of BO and make test pass,
but if user really want to allocate 1TB GTT BO, we have no reason to let it 
fail? right?
the system availed memory about 2T, but it will still fail.

2) Change kvmalloc to allow GFP_ZERO allocations even in the vmalloc fallback 
path.
the 5.18 kernel will add this patch to fix this issue .

Best Regards,
Kevin

From: Koenig, Christian 
Sent: Wednesday, April 20, 2022 8:42 PM
To: Wang, Yang(Kevin) ; Christian König 
; dri-devel@lists.freedesktop.org 
; amd-...@lists.freedesktop.org 

Subject: Re: [PATCH] drm/ttm: fix ttm tt init fail when size exceeds kmalloc 
limit

Hi Kevin,

yes and that is perfectly valid and expected behavior. There is absolutely no 
need to change anything in TTM here.

What we could do is:
1) Change the test case to use something larger than 1TiB.
2) Change kvmalloc to allow GFP_ZERO allocations even in the vmalloc fallback 
path.

Regards,
Christian.

Am 20.04.22 um 14:39 schrieb Wang, Yang(Kevin):

[AMD Official Use Only]

Hi Chirs,

yes, right, the amdgpu drive rwill use amdgpu_bo_validate_size() function to 
verify bo size,
but when driver try to allocate VRAM domain bo fail, the amdgpu driver will 
fall back to allocate domain = (GTT | VRAM)  bo.
please check following code, it will cause the 2nd time to allocate bo fail 
during allocate 256Mb buffer to store dma address (via kvmalloc()).

initial_domain = (u32)(0x & args->in.domains);
retry:
r = amdgpu_gem_object_create(adev, size, args->in.alignment,
 initial_domain,
 flags, ttm_bo_type_device, resv, &gobj);
if (r && r != -ERESTARTSYS) {
if (flags & AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED) {
flags &= ~AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED;
goto retry;
}

if (initial_domain == AMDGPU_GEM_DOMAIN_VRAM) {
initial_domain |= AMDGPU_GEM_DOMAIN_GTT;
goto retry;
}
DRM_DEBUG("Failed to allocate GEM object (%llu, %d, %llu, 
%d)\n",
size, initial_domain, args->in.alignment, r);
}

Best Regards,
Kevin


From: Christian König 

Sent: Wednesday, April 20, 2022 7:55 PM
To: Wang, Yang(Kevin) ; 
Koenig, Christian ; 
dri-devel@lists.freedesktop.org 
; 
amd-...@lists.freedesktop.org 

Subject: Re: [PATCH] drm/ttm: fix ttm tt init fail when size exceeds kmalloc 
limit

Hi Kevin,

no, the test case should already fail in amdgpu_bo_validate_size().

If we have a system with 2TiB of memory where the test case could succeed then 
we should increase the requested size to something larger.

And if the underlying core Linux kernel functions don't allow allocations as 
large as the requested one we should *NEVER* ever add workarounds like this.

It is perfectly expected that this test case is not able to fulfill the desired 
allocation. That it fails during kvmalloc is unfortunate, but not a show 
stopper.

Regards,
Christian.


Am 20.04.22 um 13:32 schrieb Wang, Yang(Kevin):

[AMD Official Use Only]

Hi Chris,

you misunderstood background about this case.

although we expect this test case to fail, it should fail at the location where 
the Bo actual memory is actually allocated. now the code logic will cause the 
failure to allocate memory to store DMA address.

e.g: the case is failed in 2TB system ram machine, it should be allocated 
successful, but it is failed.

allocate 1TB BO, the ttm should allocate 1TB/4k * 8 buffer to store allocate 
result (page address), this should not be failed usually.

There is a similar fix in upstream kernel 5.18, before this fix entered the TTM 
code, this problem existed in TTM.

kernel/git/torvalds/linux.git - Linux kernel source 
tree
mm: allow !GFP_KERNEL allocations for kvmalloc

Best Regards,
Kevin


From: Koenig, Christian 

Sent: Wednesday, Apri

Re: [PATCH] drm/ttm: fix ttm tt init fail when size exceeds kmalloc limit

[Wang, Yang(Kevin)]

[AMD Official Use Only]




From: Koenig, Christian 
Sent: Wednesday, April 20, 2022 8:56 PM
To: Wang, Yang(Kevin) ; Christian König 
; dri-devel@lists.freedesktop.org 
; amd-...@lists.freedesktop.org 

Subject: Re: [PATCH] drm/ttm: fix ttm tt init fail when size exceeds kmalloc 
limit

Am 20.04.22 um 14:54 schrieb Wang, Yang(Kevin):

[AMD Official Use Only]

Hi Chris,

1) Change the test case to use something larger than 1TiB.
sure, we can increase the size of BO and make test pass,
but if user really want to allocate 1TB GTT BO, we have no reason to let it 
fail? right?

No, the reason is the underlying core kernel doesn't allow kvmalloc allocations 
with GFP_ZERO which are large enough to hold the array of allocated pages for 
this.

We are working on top of the core Linux kernel and should *NEVER* ever add 
workarounds like what was suggested here.

Regards,
Christian.


Kevin:

it is ok to explain why we do not need fix this issue at this stage.

thanks.

Best Regards,
Kevin
the system availed memory about 2T, but it will still fail.

2) Change kvmalloc to allow GFP_ZERO allocations even in the vmalloc fallback 
path.
the 5.18 kernel will add this patch to fix this issue .

Best Regards,
Kevin

From: Koenig, Christian 

Sent: Wednesday, April 20, 2022 8:42 PM
To: Wang, Yang(Kevin) ; 
Christian König 
; 
dri-devel@lists.freedesktop.org 
; 
amd-...@lists.freedesktop.org 

Subject: Re: [PATCH] drm/ttm: fix ttm tt init fail when size exceeds kmalloc 
limit

Hi Kevin,

yes and that is perfectly valid and expected behavior. There is absolutely no 
need to change anything in TTM here.

What we could do is:
1) Change the test case to use something larger than 1TiB.
2) Change kvmalloc to allow GFP_ZERO allocations even in the vmalloc fallback 
path.

Regards,
Christian.

Am 20.04.22 um 14:39 schrieb Wang, Yang(Kevin):

[AMD Official Use Only]

Hi Chirs,

yes, right, the amdgpu drive rwill use amdgpu_bo_validate_size() function to 
verify bo size,
but when driver try to allocate VRAM domain bo fail, the amdgpu driver will 
fall back to allocate domain = (GTT | VRAM)  bo.
please check following code, it will cause the 2nd time to allocate bo fail 
during allocate 256Mb buffer to store dma address (via kvmalloc()).

initial_domain = (u32)(0x & args->in.domains);
retry:
r = amdgpu_gem_object_create(adev, size, args->in.alignment,
 initial_domain,
 flags, ttm_bo_type_device, resv, &gobj);
if (r && r != -ERESTARTSYS) {
if (flags & AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED) {
flags &= ~AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED;
goto retry;
}

if (initial_domain == AMDGPU_GEM_DOMAIN_VRAM) {
initial_domain |= AMDGPU_GEM_DOMAIN_GTT;
goto retry;
}
DRM_DEBUG("Failed to allocate GEM object (%llu, %d, %llu, 
%d)\n",
size, initial_domain, args->in.alignment, r);
}

Best Regards,
Kevin


From: Christian König 

Sent: Wednesday, April 20, 2022 7:55 PM
To: Wang, Yang(Kevin) ; 
Koenig, Christian ; 
dri-devel@lists.freedesktop.org 
; 
amd-...@lists.freedesktop.org 

Subject: Re: [PATCH] drm/ttm: fix ttm tt init fail when size exceeds kmalloc 
limit

Hi Kevin,

no, the test case should already fail in amdgpu_bo_validate_size().

If we have a system with 2TiB of memory where the test case could succeed then 
we should increase the requested size to something larger.

And if the underlying core Linux kernel functions don't allow allocations as 
large as the requested one we should *NEVER* ever add workarounds like this.

It is perfectly expected that this test case is not able to fulfill the desired 
allocation. That it fails during kvmalloc is unfortunate, but not a show 
stopper.

Regards,
Christian.


Am 20.04.22 um 13:32 schrieb Wang, Yang(Kevin):

[AMD Official Use Only]

Hi Chris,

you misunderstood background about this case.

although we expect this test case to fail, it should fail at the location where 
the Bo actual memory is actually allocated. now the code logic will cause the 
failure to allocate memory to store DMA address.

e.g: the case is failed in 2TB system ram machine, it should be allocated 
suc

Re: [PATCH v2 7/8] drm/display: Move HDMI helpers into display-helper module

[Thomas Zimmermann]

Hi

Am 20.04.22 um 14:26 schrieb Javier Martinez Canillas:

On 4/20/22 14:21, Thomas Zimmermann wrote:

Hi

Am 20.04.22 um 14:02 schrieb Javier Martinez Canillas:

Hello Thomas,

On 4/20/22 13:08, Thomas Zimmermann wrote:

[snip]


--- a/drivers/gpu/drm/bridge/synopsys/Kconfig
+++ b/drivers/gpu/drm/bridge/synopsys/Kconfig
@@ -1,6 +1,8 @@
   # SPDX-License-Identifier: GPL-2.0-only
   config DRM_DW_HDMI
tristate
+   select DRM_DISPLAY_HDMI_HELPER
+   select DRM_DISPLAY_HELPER
select DRM_KMS_HELPER
select REGMAP_MMIO
select CEC_CORE if CEC_NOTIFIER


[snip]


+config DRM_DISPLAY_HDMI_HELPER
+   bool
+   select DRM_DISPLAY_HELPER
+   help
+ DRM display helpers for HDMI.
+


Maybe you mentioned already when we discussed it in v1, but could
you please remember me why we need to select both symbols for the
drivers, even when DRM_DISPLAY_HELPER is already selected here ?

Or are select operations not transitive ?


DRM_DISPLAY_HELPER enables the module itself. It's tristate.
DRM_DISPLAY_HDMI_HELPER, DRM_DISPLAY_DP_HELPER, etc are the individual
features of the helper module. Each is a boolean.  Drivers can enable
them according to their needs.  This split allows linking correctly in
all cases, even if some drivers are built-in and others are modules.
This didn't always work with the original patches.


Right, but that wasn't my question. I wondered why for example DRM_DW_HDMI
Kconfig needs to select both DRM_DISPLAY_HDMI_HELPER and DRM_DISPLAY_HELPER
since DRM_DISPLAY_HDMI_HELPER already selects DRM_DISPLAY_HELPER.



Oh, well. You found a bug. It should be 'depends on' instead of 'select'.

Best regards
Thomas


--
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 7/9] drm: vkms: Supports to the case where primary plane doesn't match the CRTC

[Pekka Paalanen]

On Mon,  4 Apr 2022 17:45:13 -0300
Igor Torrente  wrote:

> We will break the current assumption that the primary plane has the

Hi,

I'd say "remove" rather than "break". Breaking sounds bad but this is
good. :-)

> same size and position as CRTC.

...and that the primary plane is the bottom-most in zpos order, or is
even enabled. At least as far as the blending machinery is concerned.

> 
> For that we will add CRTC dimension information to `vkms_crtc_state`
> and add a opaque black backgound color.
> 
> Because now we need to fill the background, we had a loss in
> performance with this change. Results running the IGT[1] test
> `igt@kms_cursor_crc@pipe-a-cursor-512x512-onscreen` ten times:
> 
> |  Frametime   |
> |::|
> |  Implementation |  Previous |   This commit  |
> |:---:|:-:|:--:|
> | frametime range |  5~18 ms  | 10~22 ms   |
> | Average |  8.47 ms  | 12.32 ms   |
> 
> [1] IGT commit id: bc3f6833a12221a46659535dac06ebb312490eb4
> 
> Signed-off-by: Igor Torrente 
> ---
>  Documentation/gpu/vkms.rst   |  3 +--
>  drivers/gpu/drm/vkms/vkms_composer.c | 32 +++-
>  drivers/gpu/drm/vkms/vkms_crtc.c |  4 
>  drivers/gpu/drm/vkms/vkms_drv.h  |  2 ++
>  4 files changed, 29 insertions(+), 12 deletions(-)
> 
> diff --git a/Documentation/gpu/vkms.rst b/Documentation/gpu/vkms.rst
> index a49e4ae92653..49db221c0f52 100644
> --- a/Documentation/gpu/vkms.rst
> +++ b/Documentation/gpu/vkms.rst
> @@ -121,8 +121,7 @@ There's lots of plane features we could add support for:
>  - ARGB format on primary plane: blend the primary plane into background with
>translucent alpha.
>  
> -- Support when the primary plane isn't exactly matching the output size: 
> blend
> -  the primary plane into the black background.
> +- Add background color KMS property[Good to get started].
>  
>  - Full alpha blending on all planes.
>  
> diff --git a/drivers/gpu/drm/vkms/vkms_composer.c 
> b/drivers/gpu/drm/vkms/vkms_composer.c
> index cf24015bf90f..f80842227669 100644
> --- a/drivers/gpu/drm/vkms/vkms_composer.c
> +++ b/drivers/gpu/drm/vkms/vkms_composer.c
> @@ -61,6 +61,15 @@ static bool check_y_limit(struct vkms_frame_info 
> *frame_info, int y)
>   return false;
>  }
>  
> +static void fill_background(struct pixel_argb_u16 *backgroud_color,

Hi,

this could be const struct pixel_argb_u16 *. Also a typo: missing n in
backgroud_color.

> + struct line_buffer *output_buffer)
> +{
> + int i;
> +
> + for (i = 0; i < output_buffer->n_pixels; i++)
> + output_buffer->pixels[i] = *backgroud_color;
> +}
> +
>  /**
>   * @wb_frame_info: The writeback frame buffer metadata
>   * @crtc_state: The crtc state
> @@ -78,22 +87,23 @@ static void blend(struct vkms_writeback_job *wb,
> struct line_buffer *output_buffer, s64 row_size)
>  {
>   struct vkms_plane_state **plane = crtc_state->active_planes;
> - struct vkms_frame_info *primary_plane_info = plane[0]->frame_info;
>   u32 n_active_planes = crtc_state->num_active_planes;
>  
> - int y_dst = primary_plane_info->dst.y1;
> - int h_dst = drm_rect_height(&primary_plane_info->dst);
> - int y_limit = y_dst + h_dst;
> + struct pixel_argb_u16 background_color = (struct pixel_argb_u16) {
> + .a = 0x
> + };

Could be const and shorter, if that fits the kernel style:

const struct pixel_arb_u16 background_color = { .a = 0x };

> +
> + int crtc_y_limit = crtc_state->crtc_height;
>   int y, i;
>  
> - for (y = y_dst; y < y_limit; y++) {
> - plane[0]->format_func(output_buffer, primary_plane_info, y);
> + for (y = 0; y < crtc_y_limit; y++) {
> + fill_background(&background_color, output_buffer);
>  
>   /* If there are other planes besides primary, we consider the 
> active
>* planes should be in z-order and compose them associatively:

Is "associatively" the right word here?

>* ((primary <- overlay) <- cursor)

The example (primary <- overlay) is not generally true with real hardware.

Maybe what you are trying to say is: The active planes are composed in
z-order.

>*/
> - for (i = 1; i < n_active_planes; i++) {
> + for (i = 0; i < n_active_planes; i++) {
>   if (!check_y_limit(plane[i]->frame_info, y))
>   continue;
>  
> @@ -154,7 +164,7 @@ static int compose_active_planes(struct 
> vkms_writeback_job *active_wb,

As I mentioned on the previous patch, I think the finding of primary
plane (which was generally incorrect) should be removed here.

>   if (WARN_ON(check_format_funcs(crtc_state, active_wb)))
>   return -EINVAL;
>  
> - line_width = drm_rect_width(&primary_plane_info->dst);
> + line_width = crtc_state->crtc_width;

Re: [PATCH v5 8/9] drm: vkms: Adds XRGB_16161616 and ARGB_1616161616 formats

[Pekka Paalanen]

On Mon,  4 Apr 2022 17:45:14 -0300
Igor Torrente  wrote:

> This will be useful to write tests that depends on these formats.
> 
> ARGB and XRGB follows the a similar implementation of the former formats.
> Just adjusting for 16 bits per channel.
> 
> V3: Adapt the handlers to the new format introduced in patch 7 V3.
> V5: Minor improvements
> Added le16_to_cpu/cpu_to_le16 to the 16 bits color read/writes.
> 
> Signed-off-by: Igor Torrente 
> ---
>  drivers/gpu/drm/vkms/vkms_formats.c   | 77 +++
>  drivers/gpu/drm/vkms/vkms_plane.c |  5 +-
>  drivers/gpu/drm/vkms/vkms_writeback.c |  2 +
>  3 files changed, 83 insertions(+), 1 deletion(-)

Hi,

aside from the comments I already gave on the other patch adding the
*RGB variants that apply here too, this looks good to me, with or
without those changes.

Reviewed-by: Pekka Paalanen 


Thanks,
pq

> 
> diff --git a/drivers/gpu/drm/vkms/vkms_formats.c 
> b/drivers/gpu/drm/vkms/vkms_formats.c
> index 931a61405d6a..8d913fa7dbde 100644
> --- a/drivers/gpu/drm/vkms/vkms_formats.c
> +++ b/drivers/gpu/drm/vkms/vkms_formats.c
> @@ -78,6 +78,41 @@ static void XRGB_to_argb_u16(struct line_buffer 
> *stage_buffer,
>   }
>  }
>  
> +static void ARGB16161616_to_argb_u16(struct line_buffer *stage_buffer,
> +  const struct vkms_frame_info *frame_info,
> +  int y)
> +{
> + struct pixel_argb_u16 *out_pixels = stage_buffer->pixels;
> + u16 *src_pixels = get_packed_src_addr(frame_info, y);
> + int x, x_limit = min_t(size_t, drm_rect_width(&frame_info->dst),
> +stage_buffer->n_pixels);
> +
> + for (x = 0; x < x_limit; x++, src_pixels += 4) {
> + out_pixels[x].a = le16_to_cpu(src_pixels[3]);
> + out_pixels[x].r = le16_to_cpu(src_pixels[2]);
> + out_pixels[x].g = le16_to_cpu(src_pixels[1]);
> + out_pixels[x].b = le16_to_cpu(src_pixels[0]);
> + }
> +}
> +
> +static void XRGB16161616_to_argb_u16(struct line_buffer *stage_buffer,
> +  const struct vkms_frame_info *frame_info,
> +  int y)
> +{
> + struct pixel_argb_u16 *out_pixels = stage_buffer->pixels;
> + u16 *src_pixels = get_packed_src_addr(frame_info, y);
> + int x, x_limit = min_t(size_t, drm_rect_width(&frame_info->dst),
> +stage_buffer->n_pixels);
> +
> + for (x = 0; x < x_limit; x++, src_pixels += 4) {
> + out_pixels[x].a = (u16)0x;
> + out_pixels[x].r = le16_to_cpu(src_pixels[2]);
> + out_pixels[x].g = le16_to_cpu(src_pixels[1]);
> + out_pixels[x].b = le16_to_cpu(src_pixels[0]);
> + }
> +}
> +
> +
>  /*
>   * The following  functions take an line of argb_u16 pixels from the
>   * src_buffer, convert them to a specific format, and store them in the
> @@ -130,12 +165,50 @@ static void argb_u16_to_XRGB(struct vkms_frame_info 
> *frame_info,
>   }
>  }
>  
> +static void argb_u16_to_ARGB16161616(struct vkms_frame_info *frame_info,
> +  const struct line_buffer *src_buffer, int 
> y)
> +{
> + int x, x_dst = frame_info->dst.x1;
> + u16 *dst_pixels = packed_pixels_addr(frame_info, x_dst, y);
> + struct pixel_argb_u16 *in_pixels = src_buffer->pixels;
> + int x_limit = min_t(size_t, drm_rect_width(&frame_info->dst),
> + src_buffer->n_pixels);
> +
> + for (x = 0; x < x_limit; x++, dst_pixels += 4) {
> + dst_pixels[3] = cpu_to_le16(in_pixels[x].a);
> + dst_pixels[2] = cpu_to_le16(in_pixels[x].r);
> + dst_pixels[1] = cpu_to_le16(in_pixels[x].g);
> + dst_pixels[0] = cpu_to_le16(in_pixels[x].b);
> + }
> +}
> +
> +static void argb_u16_to_XRGB16161616(struct vkms_frame_info *frame_info,
> +  const struct line_buffer *src_buffer, int 
> y)
> +{
> + int x, x_dst = frame_info->dst.x1;
> + u16 *dst_pixels = packed_pixels_addr(frame_info, x_dst, y);
> + struct pixel_argb_u16 *in_pixels = src_buffer->pixels;
> + int x_limit = min_t(size_t, drm_rect_width(&frame_info->dst),
> + src_buffer->n_pixels);
> +
> + for (x = 0; x < x_limit; x++, dst_pixels += 4) {
> + dst_pixels[3] = (u8)0x;
> + dst_pixels[2] = cpu_to_le16(in_pixels[x].r);
> + dst_pixels[1] = cpu_to_le16(in_pixels[x].g);
> + dst_pixels[0] = cpu_to_le16(in_pixels[x].b);
> + }
> +}
> +
>  plane_format_transform_func get_plane_fmt_transform_function(u32 format)
>  {
>   if (format == DRM_FORMAT_ARGB)
>   return &ARGB_to_argb_u16;
>   else if (format == DRM_FORMAT_XRGB)
>   return &XRGB_to_argb_u16;
> + else if (format == DRM_FORMAT_ARGB16161616)
> + return &ARGB16161616_to_argb_u16;
> + else if (format 

Re: [PATCH v2 7/8] drm/display: Move HDMI helpers into display-helper module

[Javier Martinez Canillas]

On 4/20/22 15:12, Thomas Zimmermann wrote:

[snip]

>>>
>> Right, but that wasn't my question. I wondered why for example DRM_DW_HDMI
>> Kconfig needs to select both DRM_DISPLAY_HDMI_HELPER and DRM_DISPLAY_HELPER
>> since DRM_DISPLAY_HDMI_HELPER already selects DRM_DISPLAY_HELPER.
>>
> 
> Oh, well. You found a bug. It should be 'depends on' instead of 'select'.
>

Ah, I see. Yeah, that makes more sense.

-- 
Best regards,

Javier Martinez Canillas
Linux Engineering
Red Hat

Re: [PATCH] drm/ttm: fix ttm tt init fail when size exceeds kmalloc limit

[Lazar, Lijo]

On 4/20/2022 6:26 PM, Christian König wrote:

Am 20.04.22 um 14:54 schrieb Wang, Yang(Kevin):


[AMD Official Use Only]


Hi Chris,

1) Change the test case to use something larger than 1TiB.
sure, we can increase the size of BO and make test pass,
but if user really want to allocate 1TB GTT BO, we have no reason to 
let it fail? right?


No, the reason is the underlying core kernel doesn't allow kvmalloc 
allocations with GFP_ZERO which are large enough to hold the array of 
allocated pages for this.


We are working on top of the core Linux kernel and should *NEVER* ever 
add workarounds like what was suggested here. >


AFAIU, for the purpose of ttm use, fallback to vmalloc is fine.

 * Please note that any use of gfp flags outside of GFP_KERNEL is 
careful to not

 * fall back to vmalloc.
 *

Actually the current implementation documents the behavior, but it is 
deep inside the implementation to be noticeable - at least not obvious 
while using kvmalloc_array.


Thanks,
Lijo


Regards,
Christian.


the system availed memory about 2T, but it will still fail.

2) Change kvmalloc to allow GFP_ZERO allocations even in the vmalloc 
fallback path.

    the 5.18 kernel will add this patch to fix this issue .

Best Regards,
Kevin

*From:* Koenig, Christian 
*Sent:* Wednesday, April 20, 2022 8:42 PM
*To:* Wang, Yang(Kevin) ; Christian König 
; dri-devel@lists.freedesktop.org 
; amd-...@lists.freedesktop.org 

*Subject:* Re: [PATCH] drm/ttm: fix ttm tt init fail when size exceeds 
kmalloc limit

Hi Kevin,

yes and that is perfectly valid and expected behavior. There is 
absolutely no need to change anything in TTM here.


What we could do is:
1) Change the test case to use something larger than 1TiB.
2) Change kvmalloc to allow GFP_ZERO allocations even in the vmalloc 
fallback path.


Regards,
Christian.

Am 20.04.22 um 14:39 schrieb Wang, Yang(Kevin):


[AMD Official Use Only]


Hi Chirs,

yes, right, the amdgpu drive rwill use amdgpu_bo_validate_size() 
function to verify bo size,
but when driver try to allocate VRAM domain bo fail, the amdgpu 
driver will fall back to allocate domain = (GTT | VRAM)  bo.
please check following code, it will cause the 2nd time to allocate 
bo fail during allocate 256Mb buffer to store dma address (via 
kvmalloc()).


initial_domain = (u32)(0x & args->in.domains);
retry:
        r = amdgpu_gem_object_create(adev, size, args->in.alignment,
                   initial_domain,
                   flags, ttm_bo_type_device, resv, &gobj);
        if (r && r != -ERESTARTSYS) {
                if (flags & AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED) {
      flags &= ~AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED;
      goto retry;
                }

                if (initial_domain == AMDGPU_GEM_DOMAIN_VRAM) {
      initial_domain |= AMDGPU_GEM_DOMAIN_GTT;
      goto retry;
                }
DRM_DEBUG("Failed to allocate GEM object (%llu, %d, %llu, %d)\n",
              size, initial_domain, args->in.alignment, r);
        }

Best Regards,
Kevin


*From:* Christian König  


*Sent:* Wednesday, April 20, 2022 7:55 PM
*To:* Wang, Yang(Kevin)  
; Koenig, Christian 
 ; 
dri-devel@lists.freedesktop.org 
 
 
; 
amd-...@lists.freedesktop.org  
 
*Subject:* Re: [PATCH] drm/ttm: fix ttm tt init fail when size 
exceeds kmalloc limit

Hi Kevin,

no, the test case should already fail in amdgpu_bo_validate_size().

If we have a system with 2TiB of memory where the test case could 
succeed then we should increase the requested size to something larger.


And if the underlying core Linux kernel functions don't allow 
allocations as large as the requested one we should *NEVER* ever add 
workarounds like this.


It is perfectly expected that this test case is not able to fulfill 
the desired allocation. That it fails during kvmalloc is unfortunate, 
but not a show stopper.


Regards,
Christian.


Am 20.04.22 um 13:32 schrieb Wang, Yang(Kevin):


[AMD Official Use Only]


Hi Chris,

you misunderstood background about this case.

although we expect this test case to fail, it should fail at the 
location where the Bo actual memory is actually allocated. now the 
code logic will cause the failure to allocate memory to store DMA 
address.


e.g: the case is failed in 2TB system ram machine, it should be 
allocated successful, but it is failed.


allocate 1TB BO, the ttm should allocate 1TB/4k * 8 buffer to store 
allocate result (page address), this should not be failed usually.


There is a similar fix in upstream kernel 5.18, before this fix 
entered the TTM code, this problem existed in TTM.


kernel/git/tor

Re: [PATCH v2] drm/vc4: Fix pm_runtime_get_sync() usage

[Maxime Ripard]

On Wed, Apr 20, 2022 at 04:05:35PM +0800, Miaoqian Lin wrote:
> 
> On 2022/4/20 15:51, Maxime Ripard wrote:
> > On Wed, Apr 20, 2022 at 12:49:48AM +, Miaoqian Lin wrote:
> >> If the device is already in a runtime PM enabled state
> >> pm_runtime_get_sync() will return 1, so a test for negative
> >> value should be used to check for errors.
> >>
> >> Also, we need to call pm_runtime_put_noidle() when pm_runtime_get_sync()
> >> fails, so use pm_runtime_resume_and_get() instead. this function
> >> will handle this.
> >>
> >> Fixes: 4078f5757144 ("drm/vc4: Add DSI driver")
> >> Signed-off-by: Miaoqian Lin 
> >> ---
> >> change in v2:
> >> - switch to pm_runtime_resume_and_get() to fix refcount leak.
> >> ---
> >>  drivers/gpu/drm/vc4/vc4_dsi.c | 4 ++--
> >>  1 file changed, 2 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/vc4/vc4_dsi.c b/drivers/gpu/drm/vc4/vc4_dsi.c
> >> index 752f921735c6..9d7ffaf6bc70 100644
> >> --- a/drivers/gpu/drm/vc4/vc4_dsi.c
> >> +++ b/drivers/gpu/drm/vc4/vc4_dsi.c
> >> @@ -846,8 +846,8 @@ static void vc4_dsi_encoder_enable(struct drm_encoder 
> >> *encoder)
> >>unsigned long phy_clock;
> >>int ret;
> >>  
> >> -  ret = pm_runtime_get_sync(dev);
> >> -  if (ret) {
> >> +  ret = pm_runtime_resume_and_get(dev);
> >> +  if (ret < 0) {
> > pm_runtime_resume_and_get will return 0 on success, so the previous check 
> > was correct
> 
> previous check is for pm_runtime_get_sync() not for pm_runtime_resume_and_get 
> (),
> 
> I switch to pm_runtime_resume_and_get() to fix the refcount leak bug at the 
> same time.
> 
> Sure it's ok to use check if(ret) to check the retval, I just follow a more 
> common way
> 
> for usage of pm_runtime_resume_and_get() in the codebase—— check ret<0
> 
> Since pm_runtime_resume_and_get() return negative error code.

If it ain't broke, don't fix it. The previous condition was working
perfectly fine to catch the errors from pm_runtime_resume_and_get,
there's no reason to change it.

Maxime


signature.asc
Description: PGP signature

[PULL] drm-intel-fixes

[Joonas Lahtinen]

Hi Dave & Daniel,

Here go drm-intel-fixes for v5.18-rc4.

Two display fixes: Disable VRR if user disables it from panel settings
and avoid claiming PSR2 is enabled when it is not supported by config.

Regards, Joonas

***

drm-intel-fixes-2022-04-20:

- Unset enable_psr2_sel_fetch if PSR2 detection fails
- Fix to detect when VRR is turned off from panel settings

The following changes since commit b2d229d4ddb17db541098b83524d901257e93845:

  Linux 5.18-rc3 (2022-04-17 13:57:31 -0700)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2022-04-20

for you to fetch changes up to bb02330408a7bde33b5f46aa14fd5d7bfe6093b7:

  drm/i915/display/psr: Unset enable_psr2_sel_fetch if other checks in 
intel_psr2_config_valid() fails (2022-04-20 07:51:14 +0300)


- Unset enable_psr2_sel_fetch if PSR2 detection fails
- Fix to detect when VRR is turned off from panel settings


José Roberto de Souza (1):
  drm/i915/display/psr: Unset enable_psr2_sel_fetch if other checks in 
intel_psr2_config_valid() fails

Manasi Navare (1):
  drm/i915/display/vrr: Reset VRR capable property on a long hpd

 drivers/gpu/drm/i915/display/intel_dp.c  | 17 +-
 drivers/gpu/drm/i915/display/intel_psr.c | 38 ++--
 2 files changed, 32 insertions(+), 23 deletions(-)

Re: [PATCH 40/48] ARM: pxa: tosa: use gpio lookup for battery

[Sebastian Reichel]

Hi,

On Tue, Apr 19, 2022 at 06:38:02PM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann 
> 
> The battery driver uses a lot of GPIO lines, hardcoded from a
> machine header file.
> 
> Change it to use a gpiod lookup table instead.
> 
> Reviewed-by: Sebastian Reichel 
> Acked-by: Sebastian Reichel 
> Cc: linux...@vger.kernel.org
> Signed-off-by: Arnd Bergmann 
> ---

That's the last power-supply driver not yet using descriptor based
gpio API :)

> [...]
> diff --git a/drivers/power/supply/tosa_battery.c 
> b/drivers/power/supply/tosa_battery.c
> index b26b0eca33e1..d10320f348d0 100644
> --- a/drivers/power/supply/tosa_battery.c
> +++ b/drivers/power/supply/tosa_battery.c
> @@ -15,11 +15,16 @@
>  #include 

This should be  now.

-- Sebastian


>  
>  #include 
> -#include 
>  
>  static DEFINE_MUTEX(bat_lock); /* protects gpio pins */
>  static struct work_struct bat_work;
>  
> +struct tosa_gpio {
> + const char *con;
> + enum gpiod_flags flags;
> + struct gpio_desc *desc;
> +};
> +
>  struct tosa_bat {
>   int status;
>   struct power_supply *psy;
> @@ -28,38 +33,42 @@ struct tosa_bat {
>   struct mutex work_lock; /* protects data */
>  
>   bool (*is_present)(struct tosa_bat *bat);
> - int gpio_full;
> - int gpio_charge_off;
> + struct tosa_gpio gpio_full;
> + struct tosa_gpio gpio_charge_off;
>  
>   int technology;
>  
> - int gpio_bat;
> + struct tosa_gpio gpio_bat;
>   int adc_bat;
>   int adc_bat_divider;
>   int bat_max;
>   int bat_min;
>  
> - int gpio_temp;
> + struct tosa_gpio gpio_temp;
>   int adc_temp;
>   int adc_temp_divider;
>  };
>  
>  static struct tosa_bat tosa_bat_main;
>  static struct tosa_bat tosa_bat_jacket;
> +static struct tosa_gpio gpiod_jacket_det = { "jacket detect", GPIOD_IN };
> +static struct tosa_gpio gpiod_battery_switch = { "battery switch", 
> GPIOD_OUT_LOW };
> +static struct tosa_gpio gpiod_main_battery_low = { "main battery low", 
> GPIOD_IN };
> +static struct tosa_gpio gpiod_jacket_battery_low = { "jacket battery low", 
> GPIOD_IN };
>  
>  static unsigned long tosa_read_bat(struct tosa_bat *bat)
>  {
>   unsigned long value = 0;
>  
> - if (bat->gpio_bat < 0 || bat->adc_bat < 0)
> + if (!bat->gpio_bat.desc || bat->adc_bat < 0)
>   return 0;
>  
>   mutex_lock(&bat_lock);
> - gpio_set_value(bat->gpio_bat, 1);
> + gpiod_set_value(bat->gpio_bat.desc, 1);
>   msleep(5);
>   value = wm97xx_read_aux_adc(dev_get_drvdata(bat->psy->dev.parent),
>   bat->adc_bat);
> - gpio_set_value(bat->gpio_bat, 0);
> + gpiod_set_value(bat->gpio_bat.desc, 0);
>   mutex_unlock(&bat_lock);
>  
>   value = value * 100 / bat->adc_bat_divider;
> @@ -71,15 +80,15 @@ static unsigned long tosa_read_temp(struct tosa_bat *bat)
>  {
>   unsigned long value = 0;
>  
> - if (bat->gpio_temp < 0 || bat->adc_temp < 0)
> + if (!bat->gpio_temp.desc || bat->adc_temp < 0)
>   return 0;
>  
>   mutex_lock(&bat_lock);
> - gpio_set_value(bat->gpio_temp, 1);
> + gpiod_set_value(bat->gpio_temp.desc, 1);
>   msleep(5);
>   value = wm97xx_read_aux_adc(dev_get_drvdata(bat->psy->dev.parent),
>   bat->adc_temp);
> - gpio_set_value(bat->gpio_temp, 0);
> + gpiod_set_value(bat->gpio_temp.desc, 0);
>   mutex_unlock(&bat_lock);
>  
>   value = value * 1 / bat->adc_temp_divider;
> @@ -136,7 +145,7 @@ static int tosa_bat_get_property(struct power_supply *psy,
>  
>  static bool tosa_jacket_bat_is_present(struct tosa_bat *bat)
>  {
> - return gpio_get_value(TOSA_GPIO_JACKET_DETECT) == 0;
> + return gpiod_get_value(gpiod_jacket_det.desc) == 0;
>  }
>  
>  static void tosa_bat_external_power_changed(struct power_supply *psy)
> @@ -166,23 +175,23 @@ static void tosa_bat_update(struct tosa_bat *bat)
>   bat->full_chrg = -1;
>   } else if (power_supply_am_i_supplied(psy)) {
>   if (bat->status == POWER_SUPPLY_STATUS_DISCHARGING) {
> - gpio_set_value(bat->gpio_charge_off, 0);
> + gpiod_set_value(bat->gpio_charge_off.desc, 0);
>   mdelay(15);
>   }
>  
> - if (gpio_get_value(bat->gpio_full)) {
> + if (gpiod_get_value(bat->gpio_full.desc)) {
>   if (old == POWER_SUPPLY_STATUS_CHARGING ||
>   bat->full_chrg == -1)
>   bat->full_chrg = tosa_read_bat(bat);
>  
> - gpio_set_value(bat->gpio_charge_off, 1);
> + gpiod_set_value(bat->gpio_charge_off.desc, 1);
>   bat->status = POWER_SUPPLY_STATUS_FULL;
>   } else {
> - gpio_set_value(bat->gpio_charge_off, 0);
> + gpiod_set_value(bat->gpio_charge_off.desc, 0);
>   bat->status = POWER_SUPPLY_STATUS

Re: [PATCH 40/48] ARM: pxa: tosa: use gpio lookup for battery

[Arnd Bergmann]

On Wed, Apr 20, 2022 at 3:43 PM Sebastian Reichel  wrote:
> > @@ -15,11 +15,16 @@
> >  #include 
>
> This should be  now.
>
Fixed now, thanks!

 Arnd

[PATCH v3] drm/vc4: Use pm_runtime_resume_and_get to fix pm_runtime_get_sync() usage

[Miaoqian Lin]

If the device is already in a runtime PM enabled state
pm_runtime_get_sync() will return 1.

Also, we need to call pm_runtime_put_noidle() when pm_runtime_get_sync()
fails, so use pm_runtime_resume_and_get() instead. this function
will handle this.

Fixes: 4078f5757144 ("drm/vc4: Add DSI driver")
Signed-off-by: Miaoqian Lin 
---
change in v2:
- switch to pm_runtime_resume_and_get() to fix refcount leak.
changes in v3:
- keep the original checking way for retval.
---
 drivers/gpu/drm/vc4/vc4_dsi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vc4/vc4_dsi.c b/drivers/gpu/drm/vc4/vc4_dsi.c
index 752f921735c6..98308a17e4ed 100644
--- a/drivers/gpu/drm/vc4/vc4_dsi.c
+++ b/drivers/gpu/drm/vc4/vc4_dsi.c
@@ -846,7 +846,7 @@ static void vc4_dsi_encoder_enable(struct drm_encoder 
*encoder)
unsigned long phy_clock;
int ret;
 
-   ret = pm_runtime_get_sync(dev);
+   ret = pm_runtime_resume_and_get(dev);
if (ret) {
DRM_ERROR("Failed to runtime PM enable on DSI%d\n", 
dsi->variant->port);
return;
-- 
2.17.1

Re: [PATCH] Staging: fbtft: Fix style problem in header

[Uwe Kleine-König]

Hello Ian,

On Wed, Apr 20, 2022 at 09:57:27AM -0400, Ian Cowan wrote:
> On Wed, Apr 20, 2022 at 08:47:11AM +0200, Uwe Kleine-König wrote:
> > On Tue, Apr 19, 2022 at 03:21:28PM -0400, Ian Cowan wrote:
> > > Removed an unnecessary semicolon at the end of a macro call
> > > 
> > > Signed-off-by: Ian Cowan 
> > > ---
> > >  drivers/staging/fbtft/fbtft.h | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/staging/fbtft/fbtft.h b/drivers/staging/fbtft/fbtft.h
> > > index 2c2b5f1c1df3..aa66760e1a9c 100644
> > > --- a/drivers/staging/fbtft/fbtft.h
> > > +++ b/drivers/staging/fbtft/fbtft.h
> > > @@ -277,7 +277,7 @@ static const struct of_device_id dt_ids[] = { 
> > > \
> > >   { .compatible = _compatible },  
> > > \
> > >   {}, 
> > > \
> > >  };   
> > > \
> > > -MODULE_DEVICE_TABLE(of, dt_ids);
> > > +MODULE_DEVICE_TABLE(of, dt_ids)
> > 
> > In fact the ; after MODULE_DEVICE_TABLE is necessary. There is only a
> > single instance in the kernel without a semicolon[1]. That's in
> > drivers/pci/controller/pcie-microchip-host.c and this only works because
> > this driver cannot be compiled as a module and so MODULE_DEVICE_TABLE
> > evaluates to nothing. Will send a patch for that one.

FTR: Patch was sent: 
https://lore.kernel.org/linux-pci/20220420065832.14173-1-u.kleine-koe...@pengutronix.de

> When I built this, it appeared to succeed. I used the command "make
> M=/drivers/staging/fbtft modules". Is this incorrect? For reference this
> is my first patch so it's highly likely I did this incorrectly.

I don't know for sure, but I'd have said that the M= stuff is for
out-of-tree modules only.

I'd recommend:

make allmodconfig
make drivers/staging/fbtft/

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |


signature.asc
Description: PGP signature

Re: [PATCH 14/41] serial: 8250/omap1: include linux/soc/ti/omap1-soc.h

[Greg KH]

On Tue, Apr 19, 2022 at 03:36:56PM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann 
> 
> As a preparation for cleaning up the omap1 headers, start
> including linux/soc/ti/omap1-soc.h directly so we can
> keep calling cpu_is_omap1510().
> 
> Signed-off-by: Arnd Bergmann 

Acked-by: Greg Kroah-Hartman 

Re: [PATCH] drm: of: Improve error handling in bridge/panel detection

[Thierry Reding]

On Thu, Apr 07, 2022 at 11:34:08AM +0200, Paul Kocialkowski wrote:
> With the previous rework of drm_of_find_panel_or_bridge only
> -EPROBE_DEFER is returned while previous behavior allowed -ENODEV
> to be returned when the port/endpoint is either missing or unavailable.
> 
> Make the default return code of the function -ENODEV to handle this and
> only return -EPROBE_DEFER in find_panel_or_bridge when the of device is
> available but not yet registered. Also return the error code whenever
> the remote node exists to avoid checking for child nodes.
> 
> Checking child nodes could result in -EPROBE_DEFER returned by
> find_panel_or_bridge with an unrelated child node that would overwrite
> a legitimate -ENODEV from find_panel_or_bridge if the remote node from
> the of graph is unavailable. This happens because find_panel_or_bridge
> has no way to distinguish between a legitimate panel/bridge node that
> isn't yet registered and an unrelated node.
> 
> Add comments around to clarify this behavior.
> 
> Signed-off-by: Paul Kocialkowski 
> Fixes: 67bae5f28c89 ("drm: of: Properly try all possible cases for 
> bridge/panel detection")
> Cc: Bjorn Andersson 
> Cc: Thierry Reding 
> Cc: Linus Walleij 
> 
> ---
>  drivers/gpu/drm/drm_of.c | 23 ++-
>  1 file changed, 18 insertions(+), 5 deletions(-)

This also fixes the regression that I was seeing on Tegra.

Tested-by: Thierry Reding 


signature.asc
Description: PGP signature

Re: [PATCH] Staging: fbtft: Fix style problem in header

[Javier Martinez Canillas]

On 4/20/22 16:36, Uwe Kleine-König wrote:
> Hello Ian,
> 
> On Wed, Apr 20, 2022 at 09:57:27AM -0400, Ian Cowan wrote:
>> On Wed, Apr 20, 2022 at 08:47:11AM +0200, Uwe Kleine-König wrote:
>>> On Tue, Apr 19, 2022 at 03:21:28PM -0400, Ian Cowan wrote:
 Removed an unnecessary semicolon at the end of a macro call

 Signed-off-by: Ian Cowan 
 ---
  drivers/staging/fbtft/fbtft.h | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/drivers/staging/fbtft/fbtft.h b/drivers/staging/fbtft/fbtft.h
 index 2c2b5f1c1df3..aa66760e1a9c 100644
 --- a/drivers/staging/fbtft/fbtft.h
 +++ b/drivers/staging/fbtft/fbtft.h
 @@ -277,7 +277,7 @@ static const struct of_device_id dt_ids[] = {  
 \
{ .compatible = _compatible },  
 \
{}, 
 \
  };
 \
 -MODULE_DEVICE_TABLE(of, dt_ids);
 +MODULE_DEVICE_TABLE(of, dt_ids)
>>>
>>> In fact the ; after MODULE_DEVICE_TABLE is necessary. There is only a
>>> single instance in the kernel without a semicolon[1]. That's in
>>> drivers/pci/controller/pcie-microchip-host.c and this only works because
>>> this driver cannot be compiled as a module and so MODULE_DEVICE_TABLE
>>> evaluates to nothing. Will send a patch for that one.
>

Indeed. I was curious about this so I went to look at the driver code.

For this particular driver it may be not necessary, but that's just due
how these fbtft drivers define their MODULE_DEVICE_TABLE(), using a lot
of macro layers.

As an example, drivers/staging/fbtft/fb_agm1264k-fl.c does the following:

FBTFT_REGISTER_DRIVER(DRVNAME, "displaytronic,fb_agm1264k-fl", &display);

which is defined as:

#define FBTFT_REGISTER_DRIVER(_name, _compatible, _display)\
...\
FBTFT_DT_TABLE(_compatible)\
...

which in turn is defined as:

#define FBTFT_DT_TABLE(_compatible) 
\
static const struct of_device_id dt_ids[] = {   
\
{ .compatible = _compatible },  
\
{}, 
\
};  
\
MODULE_DEVICE_TABLE(of, dt_ids);

so it seems that it builds, just because the semicolon for the expression
is the one that's after the FBTFT_REGISTER_DRIVER(); in the driver.

> FTR: Patch was sent: 
> https://lore.kernel.org/linux-pci/20220420065832.14173-1-u.kleine-koe...@pengutronix.de
> 
>> When I built this, it appeared to succeed. I used the command "make
>> M=/drivers/staging/fbtft modules". Is this incorrect? For reference this
>> is my first patch so it's highly likely I did this incorrectly.
>

You are just changing a header file though, did you also enable one of the
fbtft drivers as a module to see if those build? But as said, by looking at
the code it seems that should build correctly.

I agree with Uwe though that is less confusing to have a semicolon after
the MODULE_DEVICE_TABLE(), but I'm not the driver maintainer to decide.
 
> I don't know for sure, but I'd have said that the M= stuff is for
> out-of-tree modules only.
>

It does work, I use M= to build drivers in mainline that are configured
to build as a module all the time.

-- 
Best regards,

Javier Martinez Canillas
Linux Engineering
Red Hat

RE: [PATCH v2 1/7] dt-bindings: display: renesas,du: Document r9a07g044l bindings

[Biju Das]

Hi Laurent,

Thanks for the feedback.

> Subject: Re: [PATCH v2 1/7] dt-bindings: display: renesas,du: Document
> r9a07g044l bindings
> 
> Hi Biju,
> 
> Thank you for the patch.
> 
> On Wed, Mar 16, 2022 at 01:10:54PM +, Biju Das wrote:
> > Extend the Renesas DU display bindings to support the r9a07g044l DU
> > module found on RZ/G2L LCDC.
> 
> Stupid question, but as this DU and the R-Car DU are completely different
> pieces of hardware, wouldn't a separate bindings file make sense ?

OK, will create separate bindings for RZ/G2L DU

Cheers,
Biju

> 
> The DT description in this patch looks good to me.
> 
> > Signed-off-by: Biju Das 
> > ---
> > v1->v2:
> >  * Updated commit description.
> >  * Removed LCDC references
> >  * Changed clock name from du.0->aclk
> >  * Changed reset name from du.0->du
> > RFC->v1:
> >  * Changed  minItems->maxItems for renesas,vsps.
> > RFC:
> >
> > ---
> >  .../bindings/display/renesas,du.yaml  | 54 +++
> >  1 file changed, 54 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/display/renesas,du.yaml
> > b/Documentation/devicetree/bindings/display/renesas,du.yaml
> > index 13efea574584..f560608bf4e8 100644
> > --- a/Documentation/devicetree/bindings/display/renesas,du.yaml
> > +++ b/Documentation/devicetree/bindings/display/renesas,du.yaml
> > @@ -40,6 +40,7 @@ properties:
> >- renesas,du-r8a77990 # for R-Car E3 compatible DU
> >- renesas,du-r8a77995 # for R-Car D3 compatible DU
> >- renesas,du-r8a779a0 # for R-Car V3U compatible DU
> > +  - renesas,du-r9a07g044l # for RZ/G2L compatible DU
> >
> >reg:
> >  maxItems: 1
> > @@ -824,6 +825,59 @@ allOf:
> >  - reset-names
> >  - renesas,vsps
> >
> > +  - if:
> > +  properties:
> > +compatible:
> > +  contains:
> > +enum:
> > +  - renesas,du-r9a07g044l
> > +then:
> > +  properties:
> > +clocks:
> > +  items:
> > +- description: Main clock
> > +- description: Register access clock
> > +- description: Video clock
> > +
> > +clock-names:
> > +  items:
> > +- const: aclk
> > +- const: pclk
> > +- const: vclk
> > +
> > +interrupts:
> > +  maxItems: 1
> > +
> > +resets:
> > +  maxItems: 1
> > +
> > +reset-names:
> > +  items:
> > +- const: du
> > +
> > +ports:
> > +  properties:
> > +port@0:
> > +  description: DPAD 0
> > +port@1:
> > +  description: DSI 0
> > +port@2: false
> > +port@3: false
> > +
> > +  required:
> > +- port@0
> > +- port@1
> > +
> > +renesas,vsps:
> > +  maxItems: 1
> > +
> > +  required:
> > +- clock-names
> > +- interrupts
> > +- resets
> > +- reset-names
> > +- renesas,vsps
> > +
> >  additionalProperties: false
> >
> >  examples:
> 
> --
> Regards,
> 
> Laurent Pinchart

RE: [PATCH v2 2/7] drm: rcar-du: Add num_rpf to struct rcar_du_device_info

[Biju Das]

Hi Laurent,

Thanks for the feedback.

> Subject: Re: [PATCH v2 2/7] drm: rcar-du: Add num_rpf to struct
> rcar_du_device_info
> 
> Hi Biju,
> 
> Thank you for the patch.
> 
> On Wed, Mar 16, 2022 at 01:10:55PM +, Biju Das wrote:
> > Number of RPF's VSP is different on R-Car and RZ/G2L  R-Car Gen3 -> 5
> > RPFs  R-Car Gen2 -> 4 RPFs  RZ/G2L -> 2 RPFs
> >
> > Add num_rpf to struct rcar_du_device_info to support later SoC without
> > any code changes.
> >
> > Signed-off-by: Biju Das 
> > ---
> > v1->v2:
> >  * No change
> > RFC->v1:
> >  * Fixed the comment for num_rpf s/rpf's/RPFs/ and s/vsp/VSP/
> > RFC:
> >  *
> > ---
> >  drivers/gpu/drm/rcar-du/rcar_du_drv.c | 17 +
> > drivers/gpu/drm/rcar-du/rcar_du_drv.h |  2 ++
> > drivers/gpu/drm/rcar-du/rcar_du_vsp.c |  6 +-
> >  3 files changed, 20 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> > b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> > index 957ea97541d5..1bc7325aa356 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> > @@ -55,6 +55,7 @@ static const struct rcar_du_device_info
> rzg1_du_r8a7743_info = {
> > },
> > },
> > .num_lvds = 1,
> > +   .num_rpf = 4,
> >  };
> >
> >  static const struct rcar_du_device_info rzg1_du_r8a7745_info = { @@
> > -77,6 +78,7 @@ static const struct rcar_du_device_info
> rzg1_du_r8a7745_info = {
> > .port = 1,
> > },
> > },
> > +   .num_rpf = 4,
> >  };
> >
> >  static const struct rcar_du_device_info rzg1_du_r8a77470_info = { @@
> > -104,6 +106,7 @@ static const struct rcar_du_device_info
> rzg1_du_r8a77470_info = {
> > .port = 2,
> > },
> > },
> > +   .num_rpf = 4,
> >  };
> >
> >  static const struct rcar_du_device_info rcar_du_r8a774a1_info = { @@
> > -133,6 +136,7 @@ static const struct rcar_du_device_info
> rcar_du_r8a774a1_info = {
> > },
> > },
> > .num_lvds = 1,
> > +   .num_rpf = 5,
> > .dpll_mask =  BIT(1),
> >  };
> >
> > @@ -163,6 +167,7 @@ static const struct rcar_du_device_info
> rcar_du_r8a774b1_info = {
> > },
> > },
> > .num_lvds = 1,
> > +   .num_rpf = 5,
> > .dpll_mask =  BIT(1),
> >  };
> >
> > @@ -190,6 +195,7 @@ static const struct rcar_du_device_info
> rcar_du_r8a774c0_info = {
> > },
> > },
> > .num_lvds = 2,
> > +   .num_rpf = 4,
> > .lvds_clk_mask =  BIT(1) | BIT(0),
> >  };
> >
> > @@ -220,6 +226,7 @@ static const struct rcar_du_device_info
> rcar_du_r8a774e1_info = {
> > },
> > },
> > .num_lvds = 1,
> > +   .num_rpf = 5,
> > .dpll_mask =  BIT(1),
> >  };
> >
> > @@ -272,6 +279,7 @@ static const struct rcar_du_device_info
> rcar_du_r8a7790_info = {
> > },
> > },
> > .num_lvds = 2,
> > +   .num_rpf = 4,
> >  };
> >
> >  /* M2-W (r8a7791) and M2-N (r8a7793) are identical */ @@ -297,6
> > +305,7 @@ static const struct rcar_du_device_info rcar_du_r8a7791_info =
> {
> > },
> > },
> > .num_lvds = 1,
> > +   .num_rpf = 4,
> >  };
> >
> >  static const struct rcar_du_device_info rcar_du_r8a7792_info = { @@
> > -317,6 +326,7 @@ static const struct rcar_du_device_info
> rcar_du_r8a7792_info = {
> > .port = 1,
> > },
> > },
> > +   .num_rpf = 4,
> >  };
> >
> >  static const struct rcar_du_device_info rcar_du_r8a7794_info = { @@
> > -340,6 +350,7 @@ static const struct rcar_du_device_info
> rcar_du_r8a7794_info = {
> > .port = 1,
> > },
> > },
> > +   .num_rpf = 4,
> >  };
> >
> >  static const struct rcar_du_device_info rcar_du_r8a7795_info = { @@
> > -373,6 +384,7 @@ static const struct rcar_du_device_info
> rcar_du_r8a7795_info = {
> > },
> > },
> > .num_lvds = 1,
> > +   .num_rpf = 5,
> > .dpll_mask =  BIT(2) | BIT(1),
> >  };
> >
> > @@ -403,6 +415,7 @@ static const struct rcar_du_device_info
> rcar_du_r8a7796_info = {
> > },
> > },
> > .num_lvds = 1,
> > +   .num_rpf = 5,
> > .dpll_mask =  BIT(1),
> >  };
> >
> > @@ -433,6 +446,7 @@ static const struct rcar_du_device_info
> rcar_du_r8a77965_info = {
> > },
> > },
> > .num_lvds = 1,
> > +   .num_rpf = 5,
> > .dpll_mask =  BIT(1),
> >  };
> >
> > @@ -459,6 +473,7 @@ static const struct rcar_du_device_info
> rcar_du_r8a77970_info = {
> > },
> > },
> > .num_lvds = 1,
> > +   .num_rpf = 5,
> >  };
> >
> >  static const struct rcar_du_device_info rcar_du_r8a7799x_info = { @@
> > -486,6 +501,7 @@ static const struct rcar_du_device_info
> rcar_du_r8a7799x_info = {
> > },
> > },
> > .num_lvds = 2,
> > +   .num_rpf = 5,
> > .lvds_clk_mask =  BIT(1) | BIT(0),
> >  };
> >
> > @@ -505,6 +521,7 @@ static const struct rcar_du_device_info
> rcar_du_r8a779a0_info = {
> > .port = 1,
> > },
> > },
> > +   .num_rpf

RE: [PATCH v2 3/7] drm: rcar-du: Add max_width and max_height to struct rcar_du_device_info

[Biju Das]

Hi Laurent,

Thanks for the feedback.

> Subject: Re: [PATCH v2 3/7] drm: rcar-du: Add max_width and max_height to
> struct rcar_du_device_info
> 
> Hi Biju,
> 
> Thank you for the patch.
> 
> On Wed, Mar 16, 2022 at 01:10:56PM +, Biju Das wrote:
> > There are some differences related to max frame size supported by
> > different R-Car/RZ-G family of SoC's
> >
> > Max frame size supported by R-Car Gen1 & R-Car Gen2 is 4095x2047 Max
> > frame size supported by R-Car Gen3 is 8190x8190 Max frame size
> > supported by RZ/G2L is 1920x1080
> >
> > Add max_width and max_height to struct rcar_du_device_info to support
> > later SoC without any code changes.
> >
> > Signed-off-by: Biju Das 
> > ---
> > v1->v2:
> >  * No Change
> > RFC->V1:
> >  * No Change
> > RFC:
> >  *
> > ---
> >  drivers/gpu/drm/rcar-du/rcar_du_drv.c | 36
> > +++  drivers/gpu/drm/rcar-du/rcar_du_drv.h |
> > 4 +++  drivers/gpu/drm/rcar-du/rcar_du_kms.c | 17 +
> >  3 files changed, 46 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> > b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> > index 1bc7325aa356..4640c356a532 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> > @@ -56,6 +56,8 @@ static const struct rcar_du_device_info
> rzg1_du_r8a7743_info = {
> > },
> > .num_lvds = 1,
> > .num_rpf = 4,
> > +   .max_width = 4095,
> > +   .max_height = 2047,
> >  };
> >
> >  static const struct rcar_du_device_info rzg1_du_r8a7745_info = { @@
> > -79,6 +81,8 @@ static const struct rcar_du_device_info
> rzg1_du_r8a7745_info = {
> > },
> > },
> > .num_rpf = 4,
> > +   .max_width = 4095,
> > +   .max_height = 2047,
> >  };
> >
> >  static const struct rcar_du_device_info rzg1_du_r8a77470_info = { @@
> > -107,6 +111,8 @@ static const struct rcar_du_device_info
> rzg1_du_r8a77470_info = {
> > },
> > },
> > .num_rpf = 4,
> > +   .max_width = 4095,
> > +   .max_height = 2047,
> >  };
> >
> >  static const struct rcar_du_device_info rcar_du_r8a774a1_info = { @@
> > -137,6 +143,8 @@ static const struct rcar_du_device_info
> rcar_du_r8a774a1_info = {
> > },
> > .num_lvds = 1,
> > .num_rpf = 5,
> > +   .max_width = 8190,
> > +   .max_height = 8190,
> > .dpll_mask =  BIT(1),
> >  };
> >
> > @@ -168,6 +176,8 @@ static const struct rcar_du_device_info
> rcar_du_r8a774b1_info = {
> > },
> > .num_lvds = 1,
> > .num_rpf = 5,
> > +   .max_width = 8190,
> > +   .max_height = 8190,
> > .dpll_mask =  BIT(1),
> >  };
> >
> > @@ -196,6 +206,8 @@ static const struct rcar_du_device_info
> rcar_du_r8a774c0_info = {
> > },
> > .num_lvds = 2,
> > .num_rpf = 4,
> > +   .max_width = 8190,
> > +   .max_height = 8190,
> > .lvds_clk_mask =  BIT(1) | BIT(0),
> >  };
> >
> > @@ -227,6 +239,8 @@ static const struct rcar_du_device_info
> rcar_du_r8a774e1_info = {
> > },
> > .num_lvds = 1,
> > .num_rpf = 5,
> > +   .max_width = 8190,
> > +   .max_height = 8190,
> > .dpll_mask =  BIT(1),
> >  };
> >
> > @@ -249,6 +263,8 @@ static const struct rcar_du_device_info
> rcar_du_r8a7779_info = {
> > .port = 1,
> > },
> > },
> > +   .max_width = 4095,
> > +   .max_height = 2047,
> >  };
> >
> >  static const struct rcar_du_device_info rcar_du_r8a7790_info = { @@
> > -280,6 +296,8 @@ static const struct rcar_du_device_info
> rcar_du_r8a7790_info = {
> > },
> > .num_lvds = 2,
> > .num_rpf = 4,
> > +   .max_width = 4095,
> > +   .max_height = 2047,
> >  };
> >
> >  /* M2-W (r8a7791) and M2-N (r8a7793) are identical */ @@ -306,6
> > +324,8 @@ static const struct rcar_du_device_info rcar_du_r8a7791_info =
> {
> > },
> > .num_lvds = 1,
> > .num_rpf = 4,
> > +   .max_width = 4095,
> > +   .max_height = 2047,
> >  };
> >
> >  static const struct rcar_du_device_info rcar_du_r8a7792_info = { @@
> > -327,6 +347,8 @@ static const struct rcar_du_device_info
> rcar_du_r8a7792_info = {
> > },
> > },
> > .num_rpf = 4,
> > +   .max_width = 4095,
> > +   .max_height = 2047,
> >  };
> >
> >  static const struct rcar_du_device_info rcar_du_r8a7794_info = { @@
> > -351,6 +373,8 @@ static const struct rcar_du_device_info
> rcar_du_r8a7794_info = {
> > },
> > },
> > .num_rpf = 4,
> > +   .max_width = 4095,
> > +   .max_height = 2047,
> >  };
> >
> >  static const struct rcar_du_device_info rcar_du_r8a7795_info = { @@
> > -385,6 +409,8 @@ static const struct rcar_du_device_info
> rcar_du_r8a7795_info = {
> > },
> > .num_lvds = 1,
> > .num_rpf = 5,
> > +   .max_width = 8190,
> > +   .max_height = 8190,
> > .dpll_mask =  BIT(2) | BIT(1),
> >  };
> >
> > @@ -416,6 +442,8 @@ static const struct rcar_du_device_info
> rcar_du_r8a7796_info = {
> > },
> > .num_lvds = 1,
> > .num_rpf = 5,
> > +   .max_width = 8190,
> > +   .max_height = 8190,
> > .dpll_mask =  BIT

RE: [PATCH v2 4/7] drm: rcar-du: Move rcar_du_output_name() to rcar_du_common.c

[Biju Das]

Hi Laurent,

Thanks for the feedback.

> Subject: Re: [PATCH v2 4/7] drm: rcar-du: Move rcar_du_output_name() to
> rcar_du_common.c
> 
> Hi Biju,
> 
> Thank you for the patch.
> 
> On Wed, Mar 16, 2022 at 01:10:57PM +, Biju Das wrote:
> > RZ/G2L SoC's does not have group/plane registers compared to RCar,
> > hence it needs a different CRTC implementation.
> >
> > Move rcar_du_output_name() to a new common file rcar_du_common.c, So
> > that the same function can be reused by RZ/G2L SoC later.
> >
> > Signed-off-by: Biju Das 
> > ---
> > v1->v2:
> >  * No change
> > RFC->v1:
> >  New patch
> > ---
> >  drivers/gpu/drm/rcar-du/Makefile |  1 +
> >  drivers/gpu/drm/rcar-du/rcar_du_common.c | 30 
> >  drivers/gpu/drm/rcar-du/rcar_du_drv.c| 20 
> >  3 files changed, 31 insertions(+), 20 deletions(-)  create mode
> > 100644 drivers/gpu/drm/rcar-du/rcar_du_common.c
> >
> > diff --git a/drivers/gpu/drm/rcar-du/Makefile
> > b/drivers/gpu/drm/rcar-du/Makefile
> > index e7275b5e7ec8..331e12d65a6b 100644
> > --- a/drivers/gpu/drm/rcar-du/Makefile
> > +++ b/drivers/gpu/drm/rcar-du/Makefile
> > @@ -1,5 +1,6 @@
> >  # SPDX-License-Identifier: GPL-2.0
> >  rcar-du-drm-y := rcar_du_crtc.o \
> > +rcar_du_common.o \
> >  rcar_du_drv.o \
> >  rcar_du_encoder.o \
> >  rcar_du_group.o \
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_common.c
> > b/drivers/gpu/drm/rcar-du/rcar_du_common.c
> > new file mode 100644
> > index ..f9f9908cda6d
> > --- /dev/null
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_common.c
> > @@ -0,0 +1,30 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * rcar_du_common.c  --  R-Car Display Unit Common
> > + *
> > + * Copyright (C) 2013-2022 Renesas Electronics Corporation
> > + *
> > + * Contact: Laurent Pinchart (laurent.pinch...@ideasonboard.com)
> > + */
> > +
> > +#include "rcar_du_drv.h"
> > +
> > +const char *rcar_du_output_name(enum rcar_du_output output) {
> > +   static const char * const names[] = {
> > +   [RCAR_DU_OUTPUT_DPAD0] = "DPAD0",
> > +   [RCAR_DU_OUTPUT_DPAD1] = "DPAD1",
> > +   [RCAR_DU_OUTPUT_DSI0] = "DSI0",
> > +   [RCAR_DU_OUTPUT_DSI1] = "DSI1",
> > +   [RCAR_DU_OUTPUT_HDMI0] = "HDMI0",
> > +   [RCAR_DU_OUTPUT_HDMI1] = "HDMI1",
> > +   [RCAR_DU_OUTPUT_LVDS0] = "LVDS0",
> > +   [RCAR_DU_OUTPUT_LVDS1] = "LVDS1",
> > +   [RCAR_DU_OUTPUT_TCON] = "TCON",
> > +   };
> > +
> > +   if (output >= ARRAY_SIZE(names) || !names[output])
> > +   return "UNKNOWN";
> > +
> > +   return names[output];
> > +}
> 
> As we have nothing else than this function in this file, how about moving
> it to rcar_du_drv.c instead, to avoid adding a new file ?

OK, since it is small change will add the same in rzg2l_du_drv.c file.

Cheers,
Biju

> You also need to add a declaration for rcar_du_output_name() in the
> appropriate header.
> 
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> > b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> > index 4640c356a532..f6e234dafb72 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> > @@ -591,26 +591,6 @@ static const struct of_device_id
> > rcar_du_of_table[] = {
> >
> >  MODULE_DEVICE_TABLE(of, rcar_du_of_table);
> >
> > -const char *rcar_du_output_name(enum rcar_du_output output) -{
> > -   static const char * const names[] = {
> > -   [RCAR_DU_OUTPUT_DPAD0] = "DPAD0",
> > -   [RCAR_DU_OUTPUT_DPAD1] = "DPAD1",
> > -   [RCAR_DU_OUTPUT_DSI0] = "DSI0",
> > -   [RCAR_DU_OUTPUT_DSI1] = "DSI1",
> > -   [RCAR_DU_OUTPUT_HDMI0] = "HDMI0",
> > -   [RCAR_DU_OUTPUT_HDMI1] = "HDMI1",
> > -   [RCAR_DU_OUTPUT_LVDS0] = "LVDS0",
> > -   [RCAR_DU_OUTPUT_LVDS1] = "LVDS1",
> > -   [RCAR_DU_OUTPUT_TCON] = "TCON",
> > -   };
> > -
> > -   if (output >= ARRAY_SIZE(names) || !names[output])
> > -   return "UNKNOWN";
> > -
> > -   return names[output];
> > -}
> > -
> >  /* -
> 
> >   * DRM operations
> >   */
> 
> --
> Regards,
> 
> Laurent Pinchart

RE: [PATCH v2 5/7] drm: rcar-du: Factorise rcar_du_{atomic_check,modeset_init}

[Biju Das]

Hi Laurent,

Thanks for the feedback.

> Subject: Re: [PATCH v2 5/7] drm: rcar-du: Factorise
> rcar_du_{atomic_check,modeset_init}
> 
> Hi Biju,
> 
> Thank you for the patch.
> 
> On Wed, Mar 16, 2022 at 01:10:58PM +, Biju Das wrote:
> > RZ/G2L SoC's does not have group/plane registers compared to RCar,
> > hence it needs a different CRTC implementation. Factorise
> > rcar_du_{atomic_check, modeset_init} by adding struct
> > rcar_du_crtc_helper_funcs to struct rcar_du_device_info, so that it
> > can support RZ/G2L SoC without any code changes.
> 
> I'd like to go the other way around. Instead of adding a layer of
> indirection in the DU driver, could you create a new DRM driver, and share
> common code with the DU driver ?

OK will crate new DRM driver and avoid all the indirection in DU driver.

Regards,
Biju

> 
> > Signed-off-by: Biju Das 
> > ---
> > v1->v2:
> >  * Changed crtc_helper_funcs->rcar_crtc_helper_funcs
> > RFC->v1:
> >  * New patch
> > ---
> >  drivers/gpu/drm/rcar-du/rcar_du_drv.c | 24 
> > drivers/gpu/drm/rcar-du/rcar_du_drv.h | 16 
> > drivers/gpu/drm/rcar-du/rcar_du_kms.c |  6 +++---
> >  3 files changed, 43 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> > b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> > index f6e234dafb72..0df1430b9664 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> > @@ -34,6 +34,12 @@
> >   * Device Information
> >   */
> >
> > +static struct rcar_du_crtc_helper_funcs rcar_crtc_helper_funcs = {
> > +   .du_planes_init = rcar_du_planes_init,
> > +   .du_crtc_create = rcar_du_crtc_create,
> > +   .du_atomic_check_planes = rcar_du_atomic_check_planes, };
> > +
> >  static const struct rcar_du_device_info rzg1_du_r8a7743_info = {
> > .gen = 2,
> > .features = RCAR_DU_FEATURE_CRTC_IRQ @@ -58,6 +64,7 @@ static const
> > struct rcar_du_device_info rzg1_du_r8a7743_info = {
> > .num_rpf = 4,
> > .max_width = 4095,
> > .max_height = 2047,
> > +   .fns = &rcar_crtc_helper_funcs,
> >  };
> >
> >  static const struct rcar_du_device_info rzg1_du_r8a7745_info = { @@
> > -83,6 +90,7 @@ static const struct rcar_du_device_info
> rzg1_du_r8a7745_info = {
> > .num_rpf = 4,
> > .max_width = 4095,
> > .max_height = 2047,
> > +   .fns = &rcar_crtc_helper_funcs,
> >  };
> >
> >  static const struct rcar_du_device_info rzg1_du_r8a77470_info = { @@
> > -113,6 +121,7 @@ static const struct rcar_du_device_info
> rzg1_du_r8a77470_info = {
> > .num_rpf = 4,
> > .max_width = 4095,
> > .max_height = 2047,
> > +   .fns = &rcar_crtc_helper_funcs,
> >  };
> >
> >  static const struct rcar_du_device_info rcar_du_r8a774a1_info = { @@
> > -146,6 +155,7 @@ static const struct rcar_du_device_info
> rcar_du_r8a774a1_info = {
> > .max_width = 8190,
> > .max_height = 8190,
> > .dpll_mask =  BIT(1),
> > +   .fns = &rcar_crtc_helper_funcs,
> >  };
> >
> >  static const struct rcar_du_device_info rcar_du_r8a774b1_info = { @@
> > -179,6 +189,7 @@ static const struct rcar_du_device_info
> rcar_du_r8a774b1_info = {
> > .max_width = 8190,
> > .max_height = 8190,
> > .dpll_mask =  BIT(1),
> > +   .fns = &rcar_crtc_helper_funcs,
> >  };
> >
> >  static const struct rcar_du_device_info rcar_du_r8a774c0_info = { @@
> > -209,6 +220,7 @@ static const struct rcar_du_device_info
> rcar_du_r8a774c0_info = {
> > .max_width = 8190,
> > .max_height = 8190,
> > .lvds_clk_mask =  BIT(1) | BIT(0),
> > +   .fns = &rcar_crtc_helper_funcs,
> >  };
> >
> >  static const struct rcar_du_device_info rcar_du_r8a774e1_info = { @@
> > -242,6 +254,7 @@ static const struct rcar_du_device_info
> rcar_du_r8a774e1_info = {
> > .max_width = 8190,
> > .max_height = 8190,
> > .dpll_mask =  BIT(1),
> > +   .fns = &rcar_crtc_helper_funcs,
> >  };
> >
> >  static const struct rcar_du_device_info rcar_du_r8a7779_info = { @@
> > -265,6 +278,7 @@ static const struct rcar_du_device_info
> rcar_du_r8a7779_info = {
> > },
> > .max_width = 4095,
> > .max_height = 2047,
> > +   .fns = &rcar_crtc_helper_funcs,
> >  };
> >
> >  static const struct rcar_du_device_info rcar_du_r8a7790_info = { @@
> > -298,6 +312,7 @@ static const struct rcar_du_device_info
> rcar_du_r8a7790_info = {
> > .num_rpf = 4,
> > .max_width = 4095,
> > .max_height = 2047,
> > +   .fns = &rcar_crtc_helper_funcs,
> >  };
> >
> >  /* M2-W (r8a7791) and M2-N (r8a7793) are identical */ @@ -326,6
> > +341,7 @@ static const struct rcar_du_device_info rcar_du_r8a7791_info =
> {
> > .num_rpf = 4,
> > .max_width = 4095,
> > .max_height = 2047,
> > +   .fns = &rcar_crtc_helper_funcs,
> >  };
> >
> >  static const struct rcar_du_device_info rcar_du_r8a7792_info = { @@
> > -349,6 +365,7 @@ static const struct rcar_du_device_info
> rcar_du_r8a7792_info = {
> > .num_rpf = 4,
> > .max_width = 4095,
> > .max_height = 2047,
> > +  

Re: [PATCH v5 1/5] dt-bindings: display: ssd1307fb: Deprecate "-i2c" compatible strings

[Rob Herring]

On Tue, 19 Apr 2022 23:48:19 +0200, Javier Martinez Canillas wrote:
> The current compatible strings for SSD130x I2C controllers contain both an
> "fb" and "-i2c" suffixes. It seems to indicate that are for a fbdev driver
> and also that are for devices that can be accessed over an I2C bus.
> 
> But a DT is supposed to describe the hardware and not Linux implementation
> details. So let's deprecate those compatible strings and add new ones that
> only contain the vendor and device name, without any of these suffixes.
> 
> These will just describe the device and can be matched by both I2C and SPI
> DRM drivers. The required properties should still be enforced for old ones.
> 
> While being there, just drop the "sinowealth,sh1106-i2c" compatible string
> since that was never present in a released Linux version.
> 
> Signed-off-by: Javier Martinez Canillas 
> Acked-by: Mark Brown 
> Reviewed-by: Geert Uytterhoeven 
> ---
> 
> (no changes since v3)
> 
> Changes in v3:
> - Drop the "sinowealth,sh1106-i2c", wasn't in a released version (Chen-Yu 
> Tsai)
> - Continue enforcing required properties for deprecated strings (Maxime 
> Ripard)
> 
> Changes in v2:
> - Drop the -i2c suffixes from the compatible strings too (Geert Uytterhoeven)
> 
>  .../bindings/display/solomon,ssd1307fb.yaml   | 44 +--
>  1 file changed, 31 insertions(+), 13 deletions(-)
> 


Please add Acked-by/Reviewed-by tags when posting new versions. However,
there's no need to repost patches *only* to add the tags. The upstream
maintainer will do that for acks received on the version they apply.

If a tag was not added on purpose, please state why and what changed.

Re: [PATCH v5 1/5] dt-bindings: display: ssd1307fb: Deprecate "-i2c" compatible strings

[Javier Martinez Canillas]

Hello Rob,

On 4/20/22 18:15, Rob Herring wrote:
> On Tue, 19 Apr 2022 23:48:19 +0200, Javier Martinez Canillas wrote:
>> The current compatible strings for SSD130x I2C controllers contain both an
>> "fb" and "-i2c" suffixes. It seems to indicate that are for a fbdev driver
>> and also that are for devices that can be accessed over an I2C bus.
>>
>> But a DT is supposed to describe the hardware and not Linux implementation
>> details. So let's deprecate those compatible strings and add new ones that
>> only contain the vendor and device name, without any of these suffixes.
>>
>> These will just describe the device and can be matched by both I2C and SPI
>> DRM drivers. The required properties should still be enforced for old ones.
>>
>> While being there, just drop the "sinowealth,sh1106-i2c" compatible string
>> since that was never present in a released Linux version.
>>
>> Signed-off-by: Javier Martinez Canillas 
>> Acked-by: Mark Brown 
>> Reviewed-by: Geert Uytterhoeven 
>> ---
>>
>> (no changes since v3)
>>
>> Changes in v3:
>> - Drop the "sinowealth,sh1106-i2c", wasn't in a released version (Chen-Yu 
>> Tsai)
>> - Continue enforcing required properties for deprecated strings (Maxime 
>> Ripard)
>>
>> Changes in v2:
>> - Drop the -i2c suffixes from the compatible strings too (Geert Uytterhoeven)
>>
>>  .../bindings/display/solomon,ssd1307fb.yaml   | 44 +--
>>  1 file changed, 31 insertions(+), 13 deletions(-)
>>
> 
> 
> Please add Acked-by/Reviewed-by tags when posting new versions. However,
> there's no need to repost patches *only* to add the tags. The upstream
> maintainer will do that for acks received on the version they apply.
> 
> If a tag was not added on purpose, please state why and what changed.
> 

I meant to add your Acked-by but just forget before posting. Sorry about that.

I'll add it myself before pushing.

-- 
Best regards,

Javier Martinez Canillas
Linux Engineering
Red Hat

[PULL v2] gvt-next

[Wang, Zhi A]

Hi folks:

Here is the PR of gvt-next. Thanks so much for the patience.

Mostly it includes the patch bundle of GVT-g re-factor patches for adapting the 
GVT-g with the
new MDEV interfaces:

- Separating the MMIO table from GVT-g. (Zhi)
- GVT-g re-factor. (Christoph)
- GVT-g mdev API cleanup. (Jason)
- GVT-g trace/makefile cleanup. (Jani)

Thanks so much for making this happen.

This PR has been tested as following and no problem shows up:

$dim update-branches
$dim apply-pull drm-intel-next < this_email.eml

The following changes since commit 3123109284176b1532874591f7c81f3837bbdc17:

  Linux 5.18-rc1 (2022-04-03 14:08:21 -0700)

are available in the Git repository at:

  https://github.com/intel/gvt-linux tags/gvt-next-2022-04-20-for-christoph

for you to fetch changes up to ae7875879b7c838bffb42ed6db4658e5c504032e:

  vfio/mdev: Remove mdev drvdata (2022-04-20 03:15:58 -0400)


gvt-next-2022-04-22-for-christoph

- Separating the MMIO table from GVT-g. (Zhi)
- GVT-g re-factor. (Christoph)
- GVT-g mdev API cleanup. (Jason)
- GVT-g trace/makefile cleanup. (Jani)


Christoph Hellwig (27):
  drm/i915/gvt: remove module refcounting in 
intel_gvt_{,un}register_hypervisor
  drm/i915/gvt: remove enum hypervisor_type
  drm/i915/gvt: rename intel_vgpu_ops to intel_vgpu_mdev_ops
  drm/i915/gvt: move the gvt code into kvmgt.ko
  drm/i915/gvt: remove intel_gvt_ops
  drm/i915/gvt: remove the map_gfn_to_mfn and set_trap_area ops
  drm/i915/gvt: remove the unused from_virt_to_mfn op
  drm/i915/gvt: merge struct kvmgt_vdev into struct intel_vgpu
  drm/i915/gvt: merge struct kvmgt_guest_info into strut intel_vgpu
  drm/i915/gvt: remove vgpu->handle
  drm/i915/gvt: devirtualize ->{read,write}_gpa
  drm/i915/gvt: devirtualize ->{get,put}_vfio_device
  drm/i915/gvt: devirtualize ->set_edid and ->set_opregion
  drm/i915/gvt: devirtualize ->detach_vgpu
  drm/i915/gvt: devirtualize ->inject_msi
  drm/i915/gvt: devirtualize ->is_valid_gfn
  drm/i915/gvt: devirtualize ->gfn_to_mfn
  drm/i915/gvt: devirtualize ->{enable,disable}_page_track
  drm/i915/gvt: devirtualize ->dma_{,un}map_guest_page
  drm/i915/gvt: devirtualize dma_pin_guest_page
  drm/i915/gvt: remove struct intel_gvt_mpt
  drm/i915/gvt: remove the extra vfio_device refcounting for dmabufs
  drm/i915/gvt: streamline intel_vgpu_create
  drm/i915/gvt: pass a struct intel_vgpu to the vfio read/write helpers
  drm/i915/gvt: remove kvmgt_guest_{init,exit}
  drm/i915/gvt: convert to use vfio_register_emulated_iommu_dev
  drm/i915/gvt: merge gvt.c into kvmgvt.c

Jani Nikula (2):
  drm/i915/gvt: fix trace TRACE_INCLUDE_PATH
  drm/i915/gvt: better align the Makefile with i915 Makefile

Jason Gunthorpe (5):
  vfio/mdev: Remove vfio_mdev.c
  vfio/mdev: Remove mdev_parent_ops dev_attr_groups
  vfio/mdev: Remove mdev_parent_ops
  vfio/mdev: Use the driver core to create the 'remove' file
  vfio/mdev: Remove mdev drvdata

Zhi Wang (3):
  i915/gvt: Separate the MMIO tracking table from GVT-g
  i915/gvt: Save the initial HW state snapshot in i915
  i915/gvt: Use the initial HW state snapshot saved in i915

 Documentation/driver-api/vfio-mediated-device.rst |   27 +-
 drivers/gpu/drm/i915/Kconfig  |   36 +-
 drivers/gpu/drm/i915/Makefile |8 +-
 drivers/gpu/drm/i915/gvt/Makefile |   30 +-
 drivers/gpu/drm/i915/gvt/cfg_space.c  |   89 +-
 drivers/gpu/drm/i915/gvt/cmd_parser.c |4 +-
 drivers/gpu/drm/i915/gvt/dmabuf.c |   36 +-
 drivers/gpu/drm/i915/gvt/execlist.c   |   12 +-
 drivers/gpu/drm/i915/gvt/firmware.c   |   25 +-
 drivers/gpu/drm/i915/gvt/gtt.c|   55 +-
 drivers/gpu/drm/i915/gvt/gvt.c|  340 --
 drivers/gpu/drm/i915/gvt/gvt.h|  128 +-
 drivers/gpu/drm/i915/gvt/handlers.c   | 1033 +++-
 drivers/gpu/drm/i915/gvt/hypercall.h  |   82 --
 drivers/gpu/drm/i915/gvt/interrupt.c  |   40 +-
 drivers/gpu/drm/i915/gvt/kvmgt.c  | 1097 +
 drivers/gpu/drm/i915/gvt/mmio.c   |4 +-
 drivers/gpu/drm/i915/gvt/mmio.h   |1 -
 drivers/gpu/drm/i915/gvt/mpt.h|  400 ---
 drivers/gpu/drm/i915/gvt/opregion.c   |  148 +--
 drivers/gpu/drm/i915/gvt/page_track.c |8 +-
 drivers/gpu/drm/i915/gvt/reg.h|9 +-
 drivers/gpu/drm/i915/gvt/scheduler.c  |   37 +-
 drivers/gpu/drm/i915/gvt/trace.h  |2 +-
 drivers/gpu/drm/i915/gvt/vgpu.c   |   22 +-
 drivers/gpu/drm/i915/i915_driver.c|7 -
 drivers/gpu/drm

Re: [PULL v2] gvt-next

[Jason Gunthorpe]

On Wed, Apr 20, 2022 at 04:34:47PM +, Wang, Zhi A wrote:
> Hi folks:
> 
> Here is the PR of gvt-next. Thanks so much for the patience.
> 
> Mostly it includes the patch bundle of GVT-g re-factor patches for adapting 
> the GVT-g with the
> new MDEV interfaces:
> 
> - Separating the MMIO table from GVT-g. (Zhi)
> - GVT-g re-factor. (Christoph)
> - GVT-g mdev API cleanup. (Jason)
> - GVT-g trace/makefile cleanup. (Jani)
> 
> Thanks so much for making this happen.
> 
> This PR has been tested as following and no problem shows up:
> 
> $dim update-branches
> $dim apply-pull drm-intel-next < this_email.eml
> 
> The following changes since commit 3123109284176b1532874591f7c81f3837bbdc17:
> 
>   Linux 5.18-rc1 (2022-04-03 14:08:21 -0700)
> 
> are available in the Git repository at:
> 
>   https://github.com/intel/gvt-linux tags/gvt-next-2022-04-20-for-christoph
> 
> for you to fetch changes up to ae7875879b7c838bffb42ed6db4658e5c504032e:
> 
>   vfio/mdev: Remove mdev drvdata (2022-04-20 03:15:58 -0400)

This looks well constructed now! thanks

Alex you can pull this for VFIO after Jani&co grab it

I'll respin my vfio_group series on top of this branch

Jason

Re: [PATCH v2 06/17] drm/msm/dpu: add dpu_hw_wb abstraction for writeback blocks

[Abhinav Kumar]

On 4/20/2022 12:20 AM, Dmitry Baryshkov wrote:

On 20/04/2022 04:45, Abhinav Kumar wrote:

Add the dpu_hw_wb abstraction to program registers related to the
writeback block. These will be invoked once all the configuration
is set and ready to be programmed to the registers.

changes in v2:
- remove multiple empty lines at the end of the file
- change dpu_hw_wb_bind_pingpong_blk to preserve upper bits

Signed-off-by: Abhinav Kumar 
Reviewed-by: Dmitry Baryshkov 


It's still Reviewed-by, few nits below.


---
  drivers/gpu/drm/msm/Makefile  |   1 +
  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c | 273 
++

  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.h | 131 ++
  3 files changed, 405 insertions(+)
  create mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c
  create mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.h

diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index d5ca2e6..ca779c1 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -74,6 +74,7 @@ msm-$(CONFIG_DRM_MSM_DPU) += \
  disp/dpu1/dpu_hw_top.o \
  disp/dpu1/dpu_hw_util.o \
  disp/dpu1/dpu_hw_vbif.o \
+    disp/dpu1/dpu_hw_wb.o \
  disp/dpu1/dpu_kms.o \
  disp/dpu1/dpu_plane.o \
  disp/dpu1/dpu_rm.o \
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c

new file mode 100644
index 000..afa8aab
--- /dev/null
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c
@@ -0,0 +1,273 @@
+// SPDX-License-Identifier: GPL-2.0-only
+ /*
+  * Copyright (c) 2022 Qualcomm Innovation Center, Inc. All rights 
reserved

+  */
+
+#include "dpu_hw_mdss.h"
+#include "dpu_hwio.h"
+#include "dpu_hw_catalog.h"
+#include "dpu_hw_wb.h"
+#include "dpu_formats.h"
+#include "dpu_kms.h"
+
+#define WB_DST_FORMAT 0x000
+#define WB_DST_OP_MODE    0x004
+#define WB_DST_PACK_PATTERN   0x008
+#define WB_DST0_ADDR  0x00C
+#define WB_DST1_ADDR  0x010
+#define WB_DST2_ADDR  0x014
+#define WB_DST3_ADDR  0x018
+#define WB_DST_YSTRIDE0   0x01C
+#define WB_DST_YSTRIDE1   0x020
+#define WB_DST_YSTRIDE1   0x020
+#define WB_DST_DITHER_BITDEPTH    0x024
+#define WB_DST_MATRIX_ROW0    0x030
+#define WB_DST_MATRIX_ROW1    0x034
+#define WB_DST_MATRIX_ROW2    0x038
+#define WB_DST_MATRIX_ROW3    0x03C
+#define WB_DST_WRITE_CONFIG   0x048
+#define WB_ROTATION_DNSCALER  0x050
+#define WB_ROTATOR_PIPE_DOWNSCALER    0x054
+#define WB_N16_INIT_PHASE_X_C03   0x060
+#define WB_N16_INIT_PHASE_X_C12   0x064
+#define WB_N16_INIT_PHASE_Y_C03   0x068
+#define WB_N16_INIT_PHASE_Y_C12   0x06C
+#define WB_OUT_SIZE   0x074
+#define WB_ALPHA_X_VALUE  0x078
+#define WB_DANGER_LUT 0x084
+#define WB_SAFE_LUT   0x088
+#define WB_QOS_CTRL   0x090
+#define WB_CREQ_LUT_0 0x098
+#define WB_CREQ_LUT_1 0x09C
+#define WB_UBWC_STATIC_CTRL   0x144
+#define WB_MUX    0x150
+#define WB_CROP_CTRL  0x154
+#define WB_CROP_OFFSET    0x158
+#define WB_CSC_BASE   0x260
+#define WB_DST_ADDR_SW_STATUS 0x2B0
+#define WB_CDP_CNTL   0x2B4
+#define WB_OUT_IMAGE_SIZE 0x2C0
+#define WB_OUT_XY 0x2C4
+
+/* WB_QOS_CTRL */
+#define WB_QOS_CTRL_DANGER_SAFE_EN    BIT(0)
+
+static const struct dpu_wb_cfg *_wb_offset(enum dpu_wb wb,
+    const struct dpu_mdss_cfg *m, void __iomem *addr,
+    struct dpu_hw_blk_reg_map *b)
+{
+    int i;
+
+    for (i = 0; i < m->wb_count; i++) {
+    if (wb == m->wb[i].id) {
+    b->base_off = addr;
+    b->blk_off = m->wb[i].base;
+    b->length = m->wb[i].len;
+    b->hwversion = m->hwversion;
+    return &m->wb[i];
+    }
+    }
+    return ERR_PTR(-EINVAL);
+}
+
+static void dpu_hw_wb_setup_outaddress(struct dpu_hw_wb *ctx,
+    struct dpu_hw_wb_cfg *data)
+{
+    struct dpu_hw_blk_reg_map *c = &ctx->hw;
+
+    DPU_REG_WRITE(c, WB_DST0_ADDR, data->dest.plane_addr[0]);
+    DPU_REG_WRITE(c, WB_DST1_ADDR, data->dest.plane_addr[1]);
+    DPU_REG_WRITE(c, WB_DST2_ADDR, data->dest.plane_addr[2]);
+    DPU_REG_WRITE(c, WB_DST3_ADDR, data->dest.plane_addr[3]);
+}
+
+static void dpu_hw_wb_setup_format(struct dpu_hw_wb *ctx,
+    struct dpu_hw_wb_cfg *data)
+{


This function shares significant logic with dpu_hw_sspp_setup_format().

We sh

Re: [PATCH v5 0/5] drm/solomon: Add SSD130x OLED displays SPI support

[Javier Martinez Canillas]

On 4/19/22 23:48, Javier Martinez Canillas wrote:
> Hello,
> 
> This series adds a ssd130x-spi driver that provides a 4-wire SPI transport
> support for SSD130x OLED controllers that can be accessed over a SPI bus.
> 
> The driver is quite similar to existing ssd130x-i2c driver that is used by
> I2C controllers, but there is a difference in the protocol used by SSD130x
> depending on the transport used. The details are in patch #4 description.
> 
> Patch #1 just makes the current ssd130x-i2c compatible strings in the DT
> binding to be deprecated, and add new ones that don't have an "fb-i2c".
> 
> Patch #2 extends the DT binding with the properties needed to support SPI.
> 
> Patch #3 adds the new compatible strings to the OF device ID table in the
> ssd130x-i2c DRM driver and deprecate the old ones.
> 
> Patch #4 moves the device info for the different SSD130x variants from
> the ssd130x-i2c transport driver to the ssd130x core driver.
> 
> Finally patch #5 adds the ssd130x-spi DRM driver for the OLED controllers
> that come with a 4-wire SPI interface, instead of an I2C interface.
> 
> This is a v5 that addresses the issues pointed out in v4.
> 
Pushed this series to drm-misc-next after adding Rob's Reviewed-by
tags to patch 1/5 and 2/5, since I missed that in v5. Thanks all!

-- 
Best regards,

Javier Martinez Canillas
Linux Engineering
Red Hat

[PATCH v2] drm/doc: add rfc section for small BAR uapi

[Matthew Auld]

Add an entry for the new uapi needed for small BAR on DG2+.

v2:
  - Some spelling fixes and other small tweaks. (Akeem & Thomas)
  - Rework error capture interactions, including no longer needing
NEEDS_CPU_ACCESS for objects marked for capture. (Thomas)
  - Add probed_cpu_visible_size. (Lionel)

Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Cc: Lionel Landwerlin 
Cc: Jon Bloomfield 
Cc: Daniel Vetter 
Cc: Jordan Justen 
Cc: Kenneth Graunke 
Cc: Akeem G Abodunrin 
Cc: mesa-...@lists.freedesktop.org
---
 Documentation/gpu/rfc/i915_small_bar.h   | 190 +++
 Documentation/gpu/rfc/i915_small_bar.rst |  58 +++
 Documentation/gpu/rfc/index.rst  |   4 +
 3 files changed, 252 insertions(+)
 create mode 100644 Documentation/gpu/rfc/i915_small_bar.h
 create mode 100644 Documentation/gpu/rfc/i915_small_bar.rst

diff --git a/Documentation/gpu/rfc/i915_small_bar.h 
b/Documentation/gpu/rfc/i915_small_bar.h
new file mode 100644
index ..7bfd0cf44d35
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_small_bar.h
@@ -0,0 +1,190 @@
+/**
+ * struct __drm_i915_memory_region_info - Describes one region as known to the
+ * driver.
+ *
+ * Note this is using both struct drm_i915_query_item and struct 
drm_i915_query.
+ * For this new query we are adding the new query id 
DRM_I915_QUERY_MEMORY_REGIONS
+ * at &drm_i915_query_item.query_id.
+ */
+struct __drm_i915_memory_region_info {
+   /** @region: The class:instance pair encoding */
+   struct drm_i915_gem_memory_class_instance region;
+
+   /** @rsvd0: MBZ */
+   __u32 rsvd0;
+
+   /** @probed_size: Memory probed by the driver (-1 = unknown) */
+   __u64 probed_size;
+
+   /** @unallocated_size: Estimate of memory remaining (-1 = unknown) */
+   __u64 unallocated_size;
+
+   union {
+   /** @rsvd1: MBZ */
+   __u64 rsvd1[8];
+   struct {
+   /**
+* @probed_cpu_visible_size: Memory probed by the driver
+* that is CPU accessible. (-1 = unknown).
+*
+* This will be always be <= @probed_size, and the
+* remainder(if there is any) will not be CPU
+* accessible.
+*/
+   __u64 probed_cpu_visible_size;
+   };
+   };
+};
+
+/**
+ * struct __drm_i915_gem_create_ext - Existing gem_create behaviour, with added
+ * extension support using struct i915_user_extension.
+ *
+ * Note that new buffer flags should be added here, at least for the stuff that
+ * is immutable. Previously we would have two ioctls, one to create the object
+ * with gem_create, and another to apply various parameters, however this
+ * creates some ambiguity for the params which are considered immutable. Also 
in
+ * general we're phasing out the various SET/GET ioctls.
+ */
+struct __drm_i915_gem_create_ext {
+   /**
+* @size: Requested size for the object.
+*
+* The (page-aligned) allocated size for the object will be returned.
+*
+* Note that for some devices we have might have further minimum
+* page-size restrictions(larger than 4K), like for device local-memory.
+* However in general the final size here should always reflect any
+* rounding up, if for example using the 
I915_GEM_CREATE_EXT_MEMORY_REGIONS
+* extension to place the object in device local-memory.
+*/
+   __u64 size;
+   /**
+* @handle: Returned handle for the object.
+*
+* Object handles are nonzero.
+*/
+   __u32 handle;
+   /**
+* @flags: Optional flags.
+*
+* Supported values:
+*
+* I915_GEM_CREATE_EXT_FLAG_NEEDS_CPU_ACCESS - Signal to the kernel that
+* the object will need to be accessed via the CPU.
+*
+* Only valid when placing objects in I915_MEMORY_CLASS_DEVICE, and
+* only strictly required on platforms where only some of the device
+* memory is directly visible or mappable through the CPU, like on DG2+.
+*
+* One of the placements MUST also be I915_MEMORY_CLASS_SYSTEM, to
+* ensure we can always spill the allocation to system memory, if we
+* can't place the object in the mappable part of
+* I915_MEMORY_CLASS_DEVICE.
+*
+* Note that since the kernel only supports flat-CCS on objects that can
+* *only* be placed in I915_MEMORY_CLASS_DEVICE, we therefore don't
+* support I915_GEM_CREATE_EXT_FLAG_NEEDS_CPU_ACCESS together with
+* flat-CCS.
+*
+* Without this hint, the kernel will assume that non-mappable
+* I915_MEMORY_CLASS_DEVICE is preferred for this object. Note that the
+* kernel can still migrate the object to the mappable part, as a last
+* resort, if userspace ever CPU fau

Re: [PATCH v2 08/17] drm/msm/dpu: add changes to support writeback in hw_ctl

[Abhinav Kumar]

On 4/19/2022 11:59 PM, Dmitry Baryshkov wrote:

On 20/04/2022 04:46, Abhinav Kumar wrote:

Add changes to support writeback module in the dpu_hw_ctl
interface.

changes in v2:
- keep only the wb specific changes to reset_intf_cfg
- use cfg->intf / cfg->wb to identify intf or wb
- use bit-wise OR for the wb bits while programming

Signed-off-by: Abhinav Kumar 
---
  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 43 
+++---

  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h | 15 ++-
  2 files changed, 53 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c

index 524f024..495a9cd 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
@@ -1,5 +1,6 @@
  // SPDX-License-Identifier: GPL-2.0-only
-/* Copyright (c) 2015-2018, The Linux Foundation. All rights reserved.
+/* Copyright (c) 2022 Qualcomm Innovation Center, Inc. All rights 
reserved.

+ * Copyright (c) 2015-2018, The Linux Foundation. All rights reserved.
   */
  #include 
@@ -23,10 +24,12 @@
  #define   CTL_SW_RESET  0x030
  #define   CTL_LAYER_EXTN_OFFSET 0x40
  #define   CTL_MERGE_3D_ACTIVE   0x0E4
+#define   CTL_WB_ACTIVE 0x0EC
  #define   CTL_INTF_ACTIVE   0x0F4
  #define   CTL_MERGE_3D_FLUSH    0x100
  #define   CTL_DSC_ACTIVE    0x0E8
  #define   CTL_DSC_FLUSH    0x104
+#define   CTL_WB_FLUSH  0x108
  #define   CTL_INTF_FLUSH    0x110
  #define   CTL_INTF_MASTER   0x134
  #define   CTL_FETCH_PIPE_ACTIVE 0x0FC
@@ -38,6 +41,7 @@
  #define  MERGE_3D_IDX   23
  #define  DSC_IDX    22
  #define  INTF_IDX   31
+#define WB_IDX  16
  #define CTL_INVALID_BIT 0x
  #define CTL_DEFAULT_GROUP_ID    0xf
@@ -135,6 +139,9 @@ static inline void 
dpu_hw_ctl_trigger_flush_v1(struct dpu_hw_ctl *ctx)

  if (ctx->pending_flush_mask & BIT(INTF_IDX))
  DPU_REG_WRITE(&ctx->hw, CTL_INTF_FLUSH,
  ctx->pending_intf_flush_mask);
+    if (ctx->pending_flush_mask & BIT(WB_IDX))
+    DPU_REG_WRITE(&ctx->hw, CTL_WB_FLUSH,
+    ctx->pending_wb_flush_mask);
  DPU_REG_WRITE(&ctx->hw, CTL_FLUSH, ctx->pending_flush_mask);
  }
@@ -255,6 +262,13 @@ static void 
dpu_hw_ctl_update_pending_flush_intf(struct dpu_hw_ctl *ctx,

  }
  }
+static void dpu_hw_ctl_update_pending_flush_wb_v1(struct dpu_hw_ctl 
*ctx,

+    enum dpu_wb wb)
+{
+    ctx->pending_wb_flush_mask |= BIT(wb - WB_0);
+    ctx->pending_flush_mask |= BIT(WB_IDX);
+}
+
  static void dpu_hw_ctl_update_pending_flush_intf_v1(struct 
dpu_hw_ctl *ctx,

  enum dpu_intf intf)
  {
@@ -504,6 +518,7 @@ static void dpu_hw_ctl_intf_cfg_v1(struct 
dpu_hw_ctl *ctx,

  {
  struct dpu_hw_blk_reg_map *c = &ctx->hw;
  u32 intf_active = 0;
+    u32 wb_active = 0;
  u32 mode_sel = 0;
  /* CTL_TOP[31:28] carries group_id to collate CTL paths
@@ -519,11 +534,20 @@ static void dpu_hw_ctl_intf_cfg_v1(struct 
dpu_hw_ctl *ctx,

  if (cfg->intf_mode_sel == DPU_CTL_MODE_SEL_CMD)
  mode_sel |= BIT(17);
-    intf_active = DPU_REG_READ(c, CTL_INTF_ACTIVE);
-    intf_active |= BIT(cfg->intf - INTF_0);
+    if (cfg->intf) {
+    intf_active = DPU_REG_READ(c, CTL_INTF_ACTIVE);
+    intf_active |= BIT(cfg->intf - INTF_0);
+    }
+
+    if (cfg->wb) {
+    wb_active = DPU_REG_READ(c, CTL_WB_ACTIVE);
+    wb_active |= BIT(cfg->wb - WB_0);
+    }
  DPU_REG_WRITE(c, CTL_TOP, mode_sel);
  DPU_REG_WRITE(c, CTL_INTF_ACTIVE, intf_active);
+    DPU_REG_WRITE(c, CTL_WB_ACTIVE, wb_active);


This will not work as expected. If cfg->intf is not set, CTL_INTF_ACTIVE 
will be reset to 0 (while it should have been retained). Please change 
this to always read CTL_INTF_ACTIVE/CTL_WB_ACTIVE.


ack, and thanks for catching this.
Yes, i need to add the always read part back.




+
  if (cfg->merge_3d)
  DPU_REG_WRITE(c, CTL_MERGE_3D_ACTIVE,
    BIT(cfg->merge_3d - MERGE_3D_0));
@@ -546,6 +570,9 @@ static void dpu_hw_ctl_intf_cfg(struct dpu_hw_ctl 
*ctx,

  intf_cfg |= (cfg->mode_3d - 0x1) << 20;
  }
+    if (cfg->wb)
+    intf_cfg |= (cfg->wb & 0x3) + 2;
+


Ugh. I see that we have the same code in downstream driver. And that we 
do not support WB_0 at all. But maybe we should be more explicit here.


Sorry, I didnt follow this comment. Why is this related to WB_0?

All this code is doing is that its programming the lower bits of CTL_TOP 
register to be used for WB mode.


The correct value of this register for linear wb mode which we use is 0x5.

Which will still be correct now because cfg->wb will be 0x3.

Coming to other non-WB_2 values, this code is still correct.

Lets say cfg->wb was 0x1 ( for WB_0), then the register will be 
programmed to 0x3 which is the correct value to

Re: [PATCH] Staging: fbtft: Fix style problem in header

[Javier Martinez Canillas]

On 4/20/22 17:47, Javier Martinez Canillas wrote:

[snip]

>>
>>> When I built this, it appeared to succeed. I used the command "make
>>> M=/drivers/staging/fbtft modules". Is this incorrect? For reference this
>>> is my first patch so it's highly likely I did this incorrectly.
>>
> 
> You are just changing a header file though, did you also enable one of the
> fbtft drivers as a module to see if those build? But as said, by looking at
> the code it seems that should build correctly.
> 

It seems that this is the problem with Ian's build test. If I enabled both
CONFIG_FB_TFT=y and CONFIG_FB_TFT_AGM1264K_FL=m, I get the following build
error (as Uwe pointed out before):

$ make M=drivers/staging/fbtft/
  CC [M]  drivers/staging/fbtft/fb_agm1264k-fl.o
In file included from drivers/staging/fbtft/fb_agm1264k-fl.c:15:
drivers/staging/fbtft/fbtft.h:284:1: error: expected ‘,’ or ‘;’ before ‘static’
  284 | static int fbtft_driver_probe_spi(struct spi_device *spi)   
\
  | ^~
drivers/staging/fbtft/fbtft.h:323:1: note: in expansion of macro 
‘FBTFT_SPI_DRIVER’
  323 | FBTFT_SPI_DRIVER(_name, _compatible, _display, NULL)
   \
  | ^~~~
drivers/staging/fbtft/fb_agm1264k-fl.c:435:1: note: in expansion of macro 
‘FBTFT_REGISTER_DRIVER’
  435 | FBTFT_REGISTER_DRIVER(DRVNAME, "displaytronic,fb_agm1264k-fl", 
&display);
  | ^
drivers/staging/fbtft/fbtft.h:302:18: error: ‘fbtft_driver_probe_spi’ 
undeclared here (not in a function); did you mean ‘fbtft_driver_remove_spi’?
  302 | .probe = fbtft_driver_probe_spi,
\
  |  ^~
drivers/staging/fbtft/fbtft.h:323:1: note: in expansion of macro 
‘FBTFT_SPI_DRIVER’
  323 | FBTFT_SPI_DRIVER(_name, _compatible, _display, NULL)
   \
  | ^~~~
drivers/staging/fbtft/fb_agm1264k-fl.c:435:1: note: in expansion of macro 
‘FBTFT_REGISTER_DRIVER’
  435 | FBTFT_REGISTER_DRIVER(DRVNAME, "displaytronic,fb_agm1264k-fl", 
&display);
  | ^
make[1]: *** [scripts/Makefile.build:288: 
drivers/staging/fbtft/fb_agm1264k-fl.o] Error 1
make: *** [Makefile:1834: drivers/staging/fbtft] Error 2

while without removing the semicolon like this patch does, it builds correctly:

$ make M=drivers/staging/fbtft/
  CC [M]  drivers/staging/fbtft/fb_agm1264k-fl.o
  MODPOST drivers/staging/fbtft/Module.symvers
  LD [M]  drivers/staging/fbtft/fb_agm1264k-fl.ko

-- 
Best regards,

Javier Martinez Canillas
Linux Engineering
Red Hat

Re: [PATCH 03/15] dma-buf & drm/amdgpu: remove dma_resv workaround

[Zack Rusin]

On Wed, 2022-04-20 at 09:37 +0200, Christian König wrote:
> ⚠ External Email
> 
> Hi Zack,
> 
> Am 20.04.22 um 05:56 schrieb Zack Rusin:
> > On Thu, 2022-04-07 at 10:59 +0200, Christian König wrote:
> > > Rework the internals of the dma_resv object to allow adding more
> > > than
> > > one
> > > write fence and remember for each fence what purpose it had.
> > > 
> > > This allows removing the workaround from amdgpu which used a
> > > container
> > > for
> > > this instead.
> > > 
> > > Signed-off-by: Christian König 
> > > Reviewed-by: Daniel Vetter 
> > > Cc: amd-...@lists.freedesktop.org
> > 
> > afaict this change broke vmwgfx which now kernel oops right after
> > boot.
> > I haven't had the time to look into it yet, so I'm not sure what's
> > the
> > problem. I'll look at this tomorrow, but just in case you have some
> > clues, the backtrace follows:
> 
> that's a known issue and should already be fixed with:
> 
> commit d72dcbe9fce505228dae43bef9da8f2b707d1b3d
> Author: Christian König 
> Date:   Mon Apr 11 15:21:59 2022 +0200

Unfortunately that doesn't seem to be it. The backtrace is from the
current (as of the time of sending of this email) drm-misc-next, which
has this change, so it's something else.

z

Re: [PATCH 03/15] dma-buf & drm/amdgpu: remove dma_resv workaround

[Christian König]

Am 20.04.22 um 19:38 schrieb Zack Rusin:

On Wed, 2022-04-20 at 09:37 +0200, Christian König wrote:

⚠ External Email

Hi Zack,

Am 20.04.22 um 05:56 schrieb Zack Rusin:

On Thu, 2022-04-07 at 10:59 +0200, Christian König wrote:

Rework the internals of the dma_resv object to allow adding more
than
one
write fence and remember for each fence what purpose it had.

This allows removing the workaround from amdgpu which used a
container
for
this instead.

Signed-off-by: Christian König 
Reviewed-by: Daniel Vetter 
Cc: amd-...@lists.freedesktop.org

afaict this change broke vmwgfx which now kernel oops right after
boot.
I haven't had the time to look into it yet, so I'm not sure what's
the
problem. I'll look at this tomorrow, but just in case you have some
clues, the backtrace follows:

that's a known issue and should already be fixed with:

commit d72dcbe9fce505228dae43bef9da8f2b707d1b3d
Author: Christian König 
Date:   Mon Apr 11 15:21:59 2022 +0200

Unfortunately that doesn't seem to be it. The backtrace is from the
current (as of the time of sending of this email) drm-misc-next, which
has this change, so it's something else.


Ok, that's strange. In this case I need to investigate further.

Maybe VMWGFX is adding more than one fence and we actually need to 
reserve multiple slots.


Regards,
Christian.



z

Re: [PULL v2] gvt-next

[Alex Williamson]

On Wed, 20 Apr 2022 13:43:51 -0300
Jason Gunthorpe  wrote:

> On Wed, Apr 20, 2022 at 04:34:47PM +, Wang, Zhi A wrote:
> > Hi folks:
> > 
> > Here is the PR of gvt-next. Thanks so much for the patience.
> > 
> > Mostly it includes the patch bundle of GVT-g re-factor patches for adapting 
> > the GVT-g with the
> > new MDEV interfaces:
> > 
> > - Separating the MMIO table from GVT-g. (Zhi)
> > - GVT-g re-factor. (Christoph)
> > - GVT-g mdev API cleanup. (Jason)
> > - GVT-g trace/makefile cleanup. (Jani)
> > 
> > Thanks so much for making this happen.
> > 
> > This PR has been tested as following and no problem shows up:
> > 
> > $dim update-branches
> > $dim apply-pull drm-intel-next < this_email.eml
> > 
> > The following changes since commit 3123109284176b1532874591f7c81f3837bbdc17:
> > 
> >   Linux 5.18-rc1 (2022-04-03 14:08:21 -0700)
> > 
> > are available in the Git repository at:
> > 
> >   https://github.com/intel/gvt-linux tags/gvt-next-2022-04-20-for-christoph
> > 
> > for you to fetch changes up to ae7875879b7c838bffb42ed6db4658e5c504032e:
> > 
> >   vfio/mdev: Remove mdev drvdata (2022-04-20 03:15:58 -0400)  
> 
> This looks well constructed now! thanks
> 
> Alex you can pull this for VFIO after Jani&co grab it
> 
> I'll respin my vfio_group series on top of this branch

Sure, so just to confirm tags/gvt-next-2022-04-20-for-christoph is
pruned down to exactly the commits we're looking for now?  Thanks,

Alex

Re: [PATCH v2 10/17] drm/msm/dpu: make changes to dpu_encoder to support virtual encoder

[Abhinav Kumar]

On 4/20/2022 12:44 AM, Dmitry Baryshkov wrote:

On 20/04/2022 04:46, Abhinav Kumar wrote:

Make changes to dpu_encoder to support virtual encoder needed
to support writeback for dpu.

changes in v2:
- add the writeback parts to dpu_encoder_helper_phys_cleanup
- rebase on tip of msm-next and fix related dependencies
- get the writeback blocks directly from RM

Signed-off-by: Abhinav Kumar 
---
  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c  | 71 
+---

  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h |  3 +
  2 files changed, 54 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c

index 0e31ad3..06b8631 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -928,6 +928,7 @@ static void 
dpu_encoder_virt_atomic_mode_set(struct drm_encoder *drm_enc,

  struct dpu_hw_blk *hw_dsc[MAX_CHANNELS_PER_ENC];
  int num_lm, num_ctl, num_pp, num_dsc;
  unsigned int dsc_mask = 0;
+    enum dpu_hw_blk_type blk_type;
  int i;
  if (!drm_enc) {
@@ -1009,12 +1010,21 @@ static void 
dpu_encoder_virt_atomic_mode_set(struct drm_encoder *drm_enc,

  phys->hw_pp = dpu_enc->hw_pp[i];
  phys->hw_ctl = to_dpu_hw_ctl(hw_ctl[i]);
-    if (phys->intf_idx >= INTF_0 && phys->intf_idx < INTF_MAX)
-    phys->hw_intf = dpu_rm_get_intf(&dpu_kms->rm, 
phys->intf_idx);
+    if (dpu_encoder_get_intf_mode(&dpu_enc->base) == 
INTF_MODE_WB_LINE)

+    blk_type = DPU_HW_BLK_WB;
+    else
+    blk_type = DPU_HW_BLK_INTF;
+
+    if (phys->intf_idx >= INTF_0 && phys->intf_idx < INTF_MAX) {
+    if (blk_type == DPU_HW_BLK_INTF)
+    phys->hw_intf = dpu_rm_get_intf(&dpu_kms->rm, 
phys->intf_idx);

+    else if (blk_type == DPU_HW_BLK_WB)
+    phys->hw_wb = dpu_rm_get_wb(&dpu_kms->rm, 
phys->intf_idx);

+    }
-    if (!phys->hw_intf) {
+    if (!phys->hw_intf && !phys->hw_wb) {
  DPU_ERROR_ENC(dpu_enc,
-  "no intf block assigned at idx: %d\n", i);
+  "no intf ow wb block assigned at idx: %d\n", i);


or wb

ack



  return;
  }
@@ -1157,15 +1167,22 @@ static void dpu_encoder_virt_disable(struct 
drm_encoder *drm_enc)

  mutex_unlock(&dpu_enc->enc_lock);
  }
-static enum dpu_intf dpu_encoder_get_intf(struct dpu_mdss_cfg *catalog,
+static enum dpu_intf dpu_encoder_get_intf_or_wb(struct dpu_mdss_cfg 
*catalog,

  enum dpu_intf_type type, u32 controller_id)
  {
  int i = 0;
-    for (i = 0; i < catalog->intf_count; i++) {
-    if (catalog->intf[i].type == type
-    && catalog->intf[i].controller_id == controller_id) {
-    return catalog->intf[i].id;
+    if (type != INTF_WB) {
+    for (i = 0; i < catalog->intf_count; i++) {
+    if (catalog->intf[i].type == type
+    && catalog->intf[i].controller_id == controller_id) {
+    return catalog->intf[i].id;
+    }
+    }
+    } else {
+    for (i = 0; i < catalog->wb_count; i++) {
+    if (catalog->wb[i].id == controller_id)
+    return catalog->wb[i].id;
  }
  }
@@ -1886,16 +1903,27 @@ void dpu_encoder_helper_phys_cleanup(struct 
dpu_encoder_phys *phys_enc)

  dpu_encoder_helper_reset_mixers(phys_enc);
-    for (i = 0; i < dpu_enc->num_phys_encs; i++) {
-    if (dpu_enc->phys_encs[i] && 
phys_enc->hw_intf->ops.bind_pingpong_blk)

-    phys_enc->hw_intf->ops.bind_pingpong_blk(
-    dpu_enc->phys_encs[i]->hw_intf, false,
-    dpu_enc->phys_encs[i]->hw_pp->idx);
+    if (phys_enc->hw_wb) {


I think this adds a hidden knowledge here. That there is always just a 
single phys_enc for the WB encoder. I'd still do this cleanup in a loop 
together with the INTF cleanup.

alright, I can make this change.



+    /* disable the PP block */
+    if (phys_enc->hw_wb->ops.bind_pingpong_blk)
+    phys_enc->hw_wb->ops.bind_pingpong_blk(phys_enc->hw_wb, 
false,

+    phys_enc->hw_pp->idx);
-    /* mark INTF flush as pending */
-    if (phys_enc->hw_ctl->ops.update_pending_flush_intf)
-
phys_enc->hw_ctl->ops.update_pending_flush_intf(phys_enc->hw_ctl,

-    dpu_enc->phys_encs[i]->hw_intf->idx);
+    /* mark WB flush as pending */
+    if (phys_enc->hw_ctl->ops.update_pending_flush_wb)
+    phys_enc->hw_ctl->ops.update_pending_flush_wb(ctl, 
phys_enc->hw_wb->idx);

+    } else {
+    for (i = 0; i < dpu_enc->num_phys_encs; i++) {
+    if (dpu_enc->phys_encs[i] && 
phys_enc->hw_intf->ops.bind_pingpong_blk)

+    phys_enc->hw_intf->ops.bind_pingpong_blk(
+    dpu_enc->phys_encs[i]->hw_intf, false,
+    dpu_enc->phys_encs[i]->hw_pp->idx);
+
+ 

Re: [PULL v2] gvt-next

[Jason Gunthorpe]

On Wed, Apr 20, 2022 at 11:40:33AM -0600, Alex Williamson wrote:
> On Wed, 20 Apr 2022 13:43:51 -0300
> Jason Gunthorpe  wrote:
> 
> > On Wed, Apr 20, 2022 at 04:34:47PM +, Wang, Zhi A wrote:
> > > Hi folks:
> > > 
> > > Here is the PR of gvt-next. Thanks so much for the patience.
> > > 
> > > Mostly it includes the patch bundle of GVT-g re-factor patches for 
> > > adapting the GVT-g with the
> > > new MDEV interfaces:
> > > 
> > > - Separating the MMIO table from GVT-g. (Zhi)
> > > - GVT-g re-factor. (Christoph)
> > > - GVT-g mdev API cleanup. (Jason)
> > > - GVT-g trace/makefile cleanup. (Jani)
> > > 
> > > Thanks so much for making this happen.
> > > 
> > > This PR has been tested as following and no problem shows up:
> > > 
> > > $dim update-branches
> > > $dim apply-pull drm-intel-next < this_email.eml
> > > 
> > > The following changes since commit 
> > > 3123109284176b1532874591f7c81f3837bbdc17:
> > > 
> > >   Linux 5.18-rc1 (2022-04-03 14:08:21 -0700)
> > > 
> > > are available in the Git repository at:
> > > 
> > >   https://github.com/intel/gvt-linux 
> > > tags/gvt-next-2022-04-20-for-christoph
> > > 
> > > for you to fetch changes up to ae7875879b7c838bffb42ed6db4658e5c504032e:
> > > 
> > >   vfio/mdev: Remove mdev drvdata (2022-04-20 03:15:58 -0400)  
> > 
> > This looks well constructed now! thanks
> > 
> > Alex you can pull this for VFIO after Jani&co grab it
> > 
> > I'll respin my vfio_group series on top of this branch
> 
> Sure, so just to confirm tags/gvt-next-2022-04-20-for-christoph is
> pruned down to exactly the commits we're looking for now?  Thanks,

Yes, the above is correct and the tag points to commit
ae7875879b7c838bffb42ed6db4658e5c504032e

It is the bare minimum series

Thanks,
Jason

Re: [PATCH v2 06/17] drm/msm/dpu: add dpu_hw_wb abstraction for writeback blocks

[Dmitry Baryshkov]

On Wed, 20 Apr 2022 at 20:01, Abhinav Kumar  wrote:
>
>
>
> On 4/20/2022 12:20 AM, Dmitry Baryshkov wrote:
> > On 20/04/2022 04:45, Abhinav Kumar wrote:
> >> Add the dpu_hw_wb abstraction to program registers related to the
> >> writeback block. These will be invoked once all the configuration
> >> is set and ready to be programmed to the registers.
> >>
> >> changes in v2:
> >> - remove multiple empty lines at the end of the file
> >> - change dpu_hw_wb_bind_pingpong_blk to preserve upper bits
> >>
> >> Signed-off-by: Abhinav Kumar 
> >> Reviewed-by: Dmitry Baryshkov 
> >
> > It's still Reviewed-by, few nits below.
> >
> >> ---
> >>   drivers/gpu/drm/msm/Makefile  |   1 +
> >>   drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c | 273
> >> ++
> >>   drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.h | 131 ++
> >>   3 files changed, 405 insertions(+)
> >>   create mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c
> >>   create mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.h
> >>
> >> diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
> >> index d5ca2e6..ca779c1 100644
> >> --- a/drivers/gpu/drm/msm/Makefile
> >> +++ b/drivers/gpu/drm/msm/Makefile
> >> @@ -74,6 +74,7 @@ msm-$(CONFIG_DRM_MSM_DPU) += \
> >>   disp/dpu1/dpu_hw_top.o \
> >>   disp/dpu1/dpu_hw_util.o \
> >>   disp/dpu1/dpu_hw_vbif.o \
> >> +disp/dpu1/dpu_hw_wb.o \
> >>   disp/dpu1/dpu_kms.o \
> >>   disp/dpu1/dpu_plane.o \
> >>   disp/dpu1/dpu_rm.o \
> >> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c
> >> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c
> >> new file mode 100644
> >> index 000..afa8aab
> >> --- /dev/null
> >> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c
> >> @@ -0,0 +1,273 @@
> >> +// SPDX-License-Identifier: GPL-2.0-only
> >> + /*
> >> +  * Copyright (c) 2022 Qualcomm Innovation Center, Inc. All rights
> >> reserved
> >> +  */
> >> +
> >> +#include "dpu_hw_mdss.h"
> >> +#include "dpu_hwio.h"
> >> +#include "dpu_hw_catalog.h"
> >> +#include "dpu_hw_wb.h"
> >> +#include "dpu_formats.h"
> >> +#include "dpu_kms.h"
> >> +
> >> +#define WB_DST_FORMAT 0x000
> >> +#define WB_DST_OP_MODE0x004
> >> +#define WB_DST_PACK_PATTERN   0x008
> >> +#define WB_DST0_ADDR  0x00C
> >> +#define WB_DST1_ADDR  0x010
> >> +#define WB_DST2_ADDR  0x014
> >> +#define WB_DST3_ADDR  0x018
> >> +#define WB_DST_YSTRIDE0   0x01C
> >> +#define WB_DST_YSTRIDE1   0x020
> >> +#define WB_DST_YSTRIDE1   0x020
> >> +#define WB_DST_DITHER_BITDEPTH0x024
> >> +#define WB_DST_MATRIX_ROW00x030
> >> +#define WB_DST_MATRIX_ROW10x034
> >> +#define WB_DST_MATRIX_ROW20x038
> >> +#define WB_DST_MATRIX_ROW30x03C
> >> +#define WB_DST_WRITE_CONFIG   0x048
> >> +#define WB_ROTATION_DNSCALER  0x050
> >> +#define WB_ROTATOR_PIPE_DOWNSCALER0x054
> >> +#define WB_N16_INIT_PHASE_X_C03   0x060
> >> +#define WB_N16_INIT_PHASE_X_C12   0x064
> >> +#define WB_N16_INIT_PHASE_Y_C03   0x068
> >> +#define WB_N16_INIT_PHASE_Y_C12   0x06C
> >> +#define WB_OUT_SIZE   0x074
> >> +#define WB_ALPHA_X_VALUE  0x078
> >> +#define WB_DANGER_LUT 0x084
> >> +#define WB_SAFE_LUT   0x088
> >> +#define WB_QOS_CTRL   0x090
> >> +#define WB_CREQ_LUT_0 0x098
> >> +#define WB_CREQ_LUT_1 0x09C
> >> +#define WB_UBWC_STATIC_CTRL   0x144
> >> +#define WB_MUX0x150
> >> +#define WB_CROP_CTRL  0x154
> >> +#define WB_CROP_OFFSET0x158
> >> +#define WB_CSC_BASE   0x260
> >> +#define WB_DST_ADDR_SW_STATUS 0x2B0
> >> +#define WB_CDP_CNTL   0x2B4
> >> +#define WB_OUT_IMAGE_SIZE 0x2C0
> >> +#define WB_OUT_XY 0x2C4
> >> +
> >> +/* WB_QOS_CTRL */
> >> +#define WB_QOS_CTRL_DANGER_SAFE_ENBIT(0)
> >> +
> >> +static const struct dpu_wb_cfg *_wb_offset(enum dpu_wb wb,
> >> +const struct dpu_mdss_cfg *m, void __iomem *addr,
> >> +struct dpu_hw_blk_reg_map *b)
> >> +{
> >> +int i;
> >> +
> >> +for (i = 0; i < m->wb_count; i++) {
> >> +if (wb == m->wb[i].id) {
> >> +b->base_off = addr;
> >> +b->blk_off = m->wb[i].base;
> >> +b->length = m->wb[i].len;
> >> +b->hwversion = m->hwversion;
> >> +return &m->wb[i];
> >> +}
> >> +}
> >> +return ERR_PTR(

Re: [PATCH v2 06/17] drm/msm/dpu: add dpu_hw_wb abstraction for writeback blocks

[Abhinav Kumar]

Hi Dmitry

Sorry, I missed answering one question.

On 4/20/2022 10:49 AM, Dmitry Baryshkov wrote:

On Wed, 20 Apr 2022 at 20:01, Abhinav Kumar  wrote:




On 4/20/2022 12:20 AM, Dmitry Baryshkov wrote:

On 20/04/2022 04:45, Abhinav Kumar wrote:

Add the dpu_hw_wb abstraction to program registers related to the
writeback block. These will be invoked once all the configuration
is set and ready to be programmed to the registers.

changes in v2:
 - remove multiple empty lines at the end of the file
 - change dpu_hw_wb_bind_pingpong_blk to preserve upper bits

Signed-off-by: Abhinav Kumar 
Reviewed-by: Dmitry Baryshkov 


It's still Reviewed-by, few nits below.


---
   drivers/gpu/drm/msm/Makefile  |   1 +
   drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c | 273
++
   drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.h | 131 ++
   3 files changed, 405 insertions(+)
   create mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c
   create mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.h

diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index d5ca2e6..ca779c1 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -74,6 +74,7 @@ msm-$(CONFIG_DRM_MSM_DPU) += \
   disp/dpu1/dpu_hw_top.o \
   disp/dpu1/dpu_hw_util.o \
   disp/dpu1/dpu_hw_vbif.o \
+disp/dpu1/dpu_hw_wb.o \
   disp/dpu1/dpu_kms.o \
   disp/dpu1/dpu_plane.o \
   disp/dpu1/dpu_rm.o \
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c
new file mode 100644
index 000..afa8aab
--- /dev/null
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c
@@ -0,0 +1,273 @@
+// SPDX-License-Identifier: GPL-2.0-only
+ /*
+  * Copyright (c) 2022 Qualcomm Innovation Center, Inc. All rights
reserved
+  */
+
+#include "dpu_hw_mdss.h"
+#include "dpu_hwio.h"
+#include "dpu_hw_catalog.h"
+#include "dpu_hw_wb.h"
+#include "dpu_formats.h"
+#include "dpu_kms.h"
+
+#define WB_DST_FORMAT 0x000
+#define WB_DST_OP_MODE0x004
+#define WB_DST_PACK_PATTERN   0x008
+#define WB_DST0_ADDR  0x00C
+#define WB_DST1_ADDR  0x010
+#define WB_DST2_ADDR  0x014
+#define WB_DST3_ADDR  0x018
+#define WB_DST_YSTRIDE0   0x01C
+#define WB_DST_YSTRIDE1   0x020
+#define WB_DST_YSTRIDE1   0x020
+#define WB_DST_DITHER_BITDEPTH0x024
+#define WB_DST_MATRIX_ROW00x030
+#define WB_DST_MATRIX_ROW10x034
+#define WB_DST_MATRIX_ROW20x038
+#define WB_DST_MATRIX_ROW30x03C
+#define WB_DST_WRITE_CONFIG   0x048
+#define WB_ROTATION_DNSCALER  0x050
+#define WB_ROTATOR_PIPE_DOWNSCALER0x054
+#define WB_N16_INIT_PHASE_X_C03   0x060
+#define WB_N16_INIT_PHASE_X_C12   0x064
+#define WB_N16_INIT_PHASE_Y_C03   0x068
+#define WB_N16_INIT_PHASE_Y_C12   0x06C
+#define WB_OUT_SIZE   0x074
+#define WB_ALPHA_X_VALUE  0x078
+#define WB_DANGER_LUT 0x084
+#define WB_SAFE_LUT   0x088
+#define WB_QOS_CTRL   0x090
+#define WB_CREQ_LUT_0 0x098
+#define WB_CREQ_LUT_1 0x09C
+#define WB_UBWC_STATIC_CTRL   0x144
+#define WB_MUX0x150
+#define WB_CROP_CTRL  0x154
+#define WB_CROP_OFFSET0x158
+#define WB_CSC_BASE   0x260
+#define WB_DST_ADDR_SW_STATUS 0x2B0
+#define WB_CDP_CNTL   0x2B4
+#define WB_OUT_IMAGE_SIZE 0x2C0
+#define WB_OUT_XY 0x2C4
+
+/* WB_QOS_CTRL */
+#define WB_QOS_CTRL_DANGER_SAFE_ENBIT(0)
+
+static const struct dpu_wb_cfg *_wb_offset(enum dpu_wb wb,
+const struct dpu_mdss_cfg *m, void __iomem *addr,
+struct dpu_hw_blk_reg_map *b)
+{
+int i;
+
+for (i = 0; i < m->wb_count; i++) {
+if (wb == m->wb[i].id) {
+b->base_off = addr;
+b->blk_off = m->wb[i].base;
+b->length = m->wb[i].len;
+b->hwversion = m->hwversion;
+return &m->wb[i];
+}
+}
+return ERR_PTR(-EINVAL);
+}
+
+static void dpu_hw_wb_setup_outaddress(struct dpu_hw_wb *ctx,
+struct dpu_hw_wb_cfg *data)
+{
+struct dpu_hw_blk_reg_map *c = &ctx->hw;
+
+DPU_REG_WRITE(c, WB_DST0_ADDR, data->dest.plane_addr[0]);
+DPU_REG_WRITE(c, WB_DST1_ADDR, data->dest.plane_addr[1]);
+DPU_REG_WRITE(c, WB_DST2_ADDR, data->dest.plane_addr[2]);
+DPU_REG_WRITE(c, WB_DST3_ADDR, data->dest.plane_addr[3]);
+}
+
+static void dpu_h