Re: [PATCH v4 1/8] accel/qaic: Add documentation for AIC100 accelerator driver

[Bagas Sanjaya]

On Tue, Mar 21, 2023 at 03:52:11PM -0600, Jeffrey Hugo wrote:
> > > +
> > > +Request field descriptions:
> > > +
> > > +| req_id- request ID. A request FIFO element and a response FIFO element 
> > > with
> > > +| the same request ID refer to the same command.
> > > +
> > > +| seq_id- sequence ID within a request. Ignored by the DMA Bridge.
> > > +
> > > +| pcie_dma_cmd- describes the DMA element of this request.
> > > +|Bit(7) is the force msi flag, which overrides the DMA Bridge 
> > > MSI logic
> > > +|and generates a MSI when this request is complete, and 
> > > QSM
> > > +|configures the DMA Bridge to look at this bit.
> > > +|Bits(6:5) are reserved.
> > > +|Bit(4) is the completion code flag, and indicates that the DMA 
> > > Bridge
> > > +|shall generate a response FIFO element when this 
> > > request is
> > > +|complete.
> > > +|Bit(3) indicates if this request is a linked list transfer(0) 
> > > or a bulk
> > > +|transfer(1).
> > > +|Bit(2) is reserved.
> > > +|Bits(1:0) indicate the type of transfer. No transfer(0), to 
> > > device(1),
> > > +|from device(2). Value 3 is illegal.
> > > +
> > > +| pcie_dma_source_addr- source address for a bulk transfer, or the 
> > > address of
> > > +| the linked list.
> > > +
> > > +| pcie_dma_dest_addr- destination address for a bulk transfer.
> > > +
> > > +| pcie_dma_len- length of the bulk transfer. Note that the size of this 
> > > field
> > > +|limits transfers to 4G in size.
> > > +
> > > +| doorbell_addr- address of the doorbell to ring when this request is 
> > > complete.
> > > +
> > > +| doorbell_attr- doorbell attributes.
> > > +|Bit(7) indicates if a write to a doorbell is to occur.
> > > +|Bits(6:2) are reserved.
> > > +|Bits(1:0) contain the encoding of the doorbell length. 0 is 
> > > 32-bit,
> > > +|1 is 16-bit, 2 is 8-bit, 3 is reserved. The doorbell 
> > > address
> > > +|must be naturally aligned to the specified length.
> > > +
> > > +| doorbell_data- data to write to the doorbell. Only the bits 
> > > corresponding to
> > > +|the doorbell length are valid.
> > > +
> > > +| sem_cmdN- semaphore command.
> > > +|Bit(31) indicates this semaphore command is enabled.
> > > +|Bit(30) is the to-device DMA fence. Block this request until all
> > > +|to-device DMA transfers are complete.
> > > +|Bit(29) is the from-device DMA fence. Block this request until 
> > > all
> > > +|from-device DMA transfers are complete.
> > > +|Bits(28:27) are reserved.
> > > +|Bits(26:24) are the semaphore command. 0 is NOP. 1 is init with 
> > > the
> > > +|specified value. 2 is increment. 3 is decrement. 4 is 
> > > wait
> > > +|until the semaphore is equal to the specified value. 5 
> > > is wait
> > > +|until the semaphore is greater or equal to the 
> > > specified value.
> > > +|6 is "P", wait until semaphore is greater than 0, then
> > > +|decrement by 1. 7 is reserved.
> > > +|Bit(23) is reserved.
> > > +|Bit(22) is the semaphore sync. 0 is post sync, which means that 
> > > the
> > > +|semaphore operation is done after the DMA transfer. 1 is
> > > +|presync, which gates the DMA transfer. Only one presync 
> > > is
> > > +|allowed per request.
> > > +|Bit(21) is reserved.
> > > +|Bits(20:16) is the index of the semaphore to operate on.
> > > +|Bits(15:12) are reserved.
> > > +|Bits(11:0) are the semaphore value to use in operations.
> > 
> > What about bullet lists?
> 
> It doesn't feel like the above fits into a bullet list structure.  Do you
> have an example reference, or can you transform a small section of the above
> to illustrate what you are thinking?
> 

Oops, sorry for suggesting the wrong construct.

Definition lists fit in this case, since there are request fields along
with their individual descriptions. For bit lists, bullet lists should
suffice.

Here is the illustration diff:

diff --git a/Documentation/accel/qaic/aic100.rst 
b/Documentation/accel/qaic/aic100.rst
index 7ed95bb164bbeb..4d438fd8121451 100644
--- a/Documentation/accel/qaic/aic100.rst
+++ b/Documentation/accel/qaic/aic100.rst
@@ -308,67 +308,79 @@ A request FIFO element has the following structure:
 
 Request field descriptions:
 
-| req_id- request ID. A request FIFO element and a response FIFO element with
-| the same request ID refer to the same command.
+  req_id
+  request ID. A request FIFO element and a response FIFO element with
+  the same request ID refer to the same command.
 
-| seq_id- sequence ID within a request. Ignored by the DMA Bridge.
+  seq_id
+  sequence ID within a 

Re: [v2,1/8] drm/fbdev-generic: Always use shadow buffering

[Sui Jingfeng]

Tested-by: Sui Jingfeng 

On 2023/3/20 23:07, Thomas Zimmermann wrote:

Remove all codepaths that implement fbdev output directly on GEM
buffers. Always allocate a shadow buffer in system memory and set
up deferred I/O for mmap.

The fbdev code that operated directly on GEM buffers was used by
drivers based on GEM DMA helpers. Those drivers have been migrated
to use fbdev-dma, a dedicated fbdev emulation for DMA memory. All
remaining users of fbdev-generic require shadow buffering.

Memory management of the remaining callers uses TTM, GEM SHMEM
helpers or a variant of GEM DMA helpers that is incompatible with
fbdev-dma. Therefore remove the unused codepaths from fbdev-generic
and simplify the code.

Using a shadow buffer with deferred I/O is probably the best case
for most remaining callers. Some of the TTM-based drivers might
benefit from a dedicated fbdev emulation that operates directly on
the driver's video memory.

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Javier Martinez Canillas 
Acked-by: Zack Rusin 
---
  drivers/gpu/drm/drm_fbdev_generic.c | 184 +---
  1 file changed, 30 insertions(+), 154 deletions(-)

diff --git a/drivers/gpu/drm/drm_fbdev_generic.c 
b/drivers/gpu/drm/drm_fbdev_generic.c
index 4d6325e91565..e48a8e82378d 100644
--- a/drivers/gpu/drm/drm_fbdev_generic.c
+++ b/drivers/gpu/drm/drm_fbdev_generic.c
@@ -11,16 +11,6 @@
  
  #include 
  
-static bool drm_fbdev_use_shadow_fb(struct drm_fb_helper *fb_helper)

-{
-   struct drm_device *dev = fb_helper->dev;
-   struct drm_framebuffer *fb = fb_helper->fb;
-
-   return dev->mode_config.prefer_shadow_fbdev ||
-  dev->mode_config.prefer_shadow ||
-  fb->funcs->dirty;
-}
-
  /* @user: 1=userspace, 0=fbcon */
  static int drm_fbdev_fb_open(struct fb_info *info, int user)
  {
@@ -46,115 +36,33 @@ static int drm_fbdev_fb_release(struct fb_info *info, int 
user)
  static void drm_fbdev_fb_destroy(struct fb_info *info)
  {
struct drm_fb_helper *fb_helper = info->par;
-   void *shadow = NULL;
+   void *shadow = info->screen_buffer;
  
  	if (!fb_helper->dev)

return;
  
-	if (info->fbdefio)

-   fb_deferred_io_cleanup(info);
-   if (drm_fbdev_use_shadow_fb(fb_helper))
-   shadow = info->screen_buffer;
-
+   fb_deferred_io_cleanup(info);
drm_fb_helper_fini(fb_helper);
-
-   if (shadow)
-   vfree(shadow);
-   else if (fb_helper->buffer)
-   drm_client_buffer_vunmap(fb_helper->buffer);
-
+   vfree(shadow);
drm_client_framebuffer_delete(fb_helper->buffer);
-   drm_client_release(_helper->client);
  
+	drm_client_release(_helper->client);

drm_fb_helper_unprepare(fb_helper);
kfree(fb_helper);
  }
  
-static int drm_fbdev_fb_mmap(struct fb_info *info, struct vm_area_struct *vma)

-{
-   struct drm_fb_helper *fb_helper = info->par;
-
-   if (drm_fbdev_use_shadow_fb(fb_helper))
-   return fb_deferred_io_mmap(info, vma);
-   else if (fb_helper->dev->driver->gem_prime_mmap)
-   return 
fb_helper->dev->driver->gem_prime_mmap(fb_helper->buffer->gem, vma);
-   else
-   return -ENODEV;
-}
-
-static bool drm_fbdev_use_iomem(struct fb_info *info)
-{
-   struct drm_fb_helper *fb_helper = info->par;
-   struct drm_client_buffer *buffer = fb_helper->buffer;
-
-   return !drm_fbdev_use_shadow_fb(fb_helper) && buffer->map.is_iomem;
-}
-
-static ssize_t drm_fbdev_fb_read(struct fb_info *info, char __user *buf,
-size_t count, loff_t *ppos)
-{
-   ssize_t ret;
-
-   if (drm_fbdev_use_iomem(info))
-   ret = drm_fb_helper_cfb_read(info, buf, count, ppos);
-   else
-   ret = drm_fb_helper_sys_read(info, buf, count, ppos);
-
-   return ret;
-}
-
-static ssize_t drm_fbdev_fb_write(struct fb_info *info, const char __user *buf,
- size_t count, loff_t *ppos)
-{
-   ssize_t ret;
-
-   if (drm_fbdev_use_iomem(info))
-   ret = drm_fb_helper_cfb_write(info, buf, count, ppos);
-   else
-   ret = drm_fb_helper_sys_write(info, buf, count, ppos);
-
-   return ret;
-}
-
-static void drm_fbdev_fb_fillrect(struct fb_info *info,
- const struct fb_fillrect *rect)
-{
-   if (drm_fbdev_use_iomem(info))
-   drm_fb_helper_cfb_fillrect(info, rect);
-   else
-   drm_fb_helper_sys_fillrect(info, rect);
-}
-
-static void drm_fbdev_fb_copyarea(struct fb_info *info,
- const struct fb_copyarea *area)
-{
-   if (drm_fbdev_use_iomem(info))
-   drm_fb_helper_cfb_copyarea(info, area);
-   else
-   drm_fb_helper_sys_copyarea(info, area);
-}
-
-static void drm_fbdev_fb_imageblit(struct fb_info *info,
-  const struct fb_image *image)
-{
-   if 

Re: [PATCH 1/1] drm/sun4i: tcon: Fix setting PLL rate when using DSI

[Roman Beranek]

On Tue Mar 21, 2023 at 8:55 PM CET, Frank Oltmanns wrote:
> My apologies, I wasn’t patient enough.

Frank, there's no need to apologize, in my judgement. You weren't
impatient, we simply happened to run into a coordination problem for
which, I think, neither of us was particularly to blamew. Take it easy
:)

Roman

[PATCH] drm/amd/display: Clean up some inconsistent indenting

[Jiapeng Chong]

No functional modification involved.

Reported-by: Abaci Robot 
Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=4585
Signed-off-by: Jiapeng Chong 
---
 drivers/gpu/drm/amd/display/modules/power/power_helpers.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/modules/power/power_helpers.c 
b/drivers/gpu/drm/amd/display/modules/power/power_helpers.c
index fa469de3e935..0d3a983cb9ec 100644
--- a/drivers/gpu/drm/amd/display/modules/power/power_helpers.c
+++ b/drivers/gpu/drm/amd/display/modules/power/power_helpers.c
@@ -758,8 +758,8 @@ bool dmcu_load_iram(struct dmcu *dmcu,
 
if (dmcu->dmcu_version.abm_version == 0x24) {
fill_iram_v_2_3((struct iram_table_v_2_2 *)ram_table, params, 
true);
-   result = dmcu->funcs->load_iram(
-   dmcu, 0, (char *)(_table), 
IRAM_RESERVE_AREA_START_V2_2);
+   result = dmcu->funcs->load_iram(dmcu, 0, (char *)(_table),
+   IRAM_RESERVE_AREA_START_V2_2);
} else if (dmcu->dmcu_version.abm_version == 0x23) {
fill_iram_v_2_3((struct iram_table_v_2_2 *)ram_table, params, 
true);
 
-- 
2.20.1.7.g153144c

[PATCH] drm/amd/display: Remove the unused variable dppclk_delay_subtotal

[Jiapeng Chong]

Variable dppclk_delay_subtotal is not effectively used, so delete it.

drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn314/display_rq_dlg_calc_314.c:1004:15:
 warning: variable 'dppclk_delay_subtotal' set but not used.

Reported-by: Abaci Robot 
Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=4584
Signed-off-by: Jiapeng Chong 
---
 .../display/dc/dml/dcn314/display_rq_dlg_calc_314.c| 10 --
 1 file changed, 10 deletions(-)

diff --git 
a/drivers/gpu/drm/amd/display/dc/dml/dcn314/display_rq_dlg_calc_314.c 
b/drivers/gpu/drm/amd/display/dc/dml/dcn314/display_rq_dlg_calc_314.c
index 6576b897a512..d1c2693a2e28 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/dcn314/display_rq_dlg_calc_314.c
+++ b/drivers/gpu/drm/amd/display/dc/dml/dcn314/display_rq_dlg_calc_314.c
@@ -1001,7 +1001,6 @@ static void dml_rq_dlg_get_dlg_params(
unsigned int vupdate_width;
unsigned int vready_offset;
 
-   unsigned int dppclk_delay_subtotal;
unsigned int dispclk_delay_subtotal;
 
unsigned int vstartup_start;
@@ -1130,17 +1129,8 @@ static void dml_rq_dlg_get_dlg_params(
vupdate_offset = dst->vupdate_offset;
vupdate_width = dst->vupdate_width;
vready_offset = dst->vready_offset;
-
-   dppclk_delay_subtotal = mode_lib->ip.dppclk_delay_subtotal;
dispclk_delay_subtotal = mode_lib->ip.dispclk_delay_subtotal;
 
-   if (scl_enable)
-   dppclk_delay_subtotal += mode_lib->ip.dppclk_delay_scl;
-   else
-   dppclk_delay_subtotal += mode_lib->ip.dppclk_delay_scl_lb_only;
-
-   dppclk_delay_subtotal += mode_lib->ip.dppclk_delay_cnvc_formatter + 
src->num_cursors * mode_lib->ip.dppclk_delay_cnvc_cursor;
-
if (dout->dsc_enable) {
double dsc_delay = get_dsc_delay(mode_lib, e2e_pipe_param, 
num_pipes, pipe_idx); // FROM VBA
 
-- 
2.20.1.7.g153144c

Re: [Intel-gfx] [PATCH] drm/i915: Make IRQ reset and postinstall multi-gt aware

[Andi Shyti]

Hi Matt,

On Tue, Mar 21, 2023 at 05:10:51PM -0700, Matt Roper wrote:
> On Wed, Mar 22, 2023 at 12:20:09AM +0100, Andi Shyti wrote:
> > From: Paulo Zanoni 
> > 
> > In multitile systems IRQ need to be reset and enabled per GT.
> 
> At the moment we're not enabling multi-tile support on any platforms
> yet.  Xe_HP SDV has pretty much already served its purpose as an early
> Xe_HP test platform, and most PVC effort is refocusing on the Xe KMD
> right now.
> 
> Note that we don't want/need changes like this on non-tile multi-gt
> platforms like MTL.  The interrupt registers you're accessing here are
> sgunit registers so there's only ever a single copy of the register on
> such platforms; looping around and processing the same register two
> times in a row doesn't accomplish anything that just processing them a
> single time doesn't.

Right... irq's registers in MTL are in the root tile.

However, In a multi-gt point of view all the "gt" functions need
to be iterated over all the GT's... maybe to have things cleaner
we might need some dedicated mtl_irq_reset and
mtl_irq_postinstall wrappers.

Thanks! (again :-))

Andi

[PATCH] drm/i915: Use i915 instead of dev_priv insied the file_priv structure

[Andi Shyti]

In the process of renaming all instances of 'dev_priv' to 'i915',
start using 'i915' within the 'drm_i915_file_private' structure.

Signed-off-by: Andi Shyti 
---
 drivers/gpu/drm/i915/gem/i915_gem_context.c | 22 ++---
 drivers/gpu/drm/i915/i915_drm_client.c  |  2 +-
 drivers/gpu/drm/i915/i915_file_private.h|  2 +-
 drivers/gpu/drm/i915/i915_gem.c |  2 +-
 4 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 6d639ca24dfbb..5402a7bbcb1d1 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -364,7 +364,7 @@ static int set_proto_ctx_vm(struct drm_i915_file_private 
*fpriv,
struct i915_gem_proto_context *pc,
const struct drm_i915_gem_context_param *args)
 {
-   struct drm_i915_private *i915 = fpriv->dev_priv;
+   struct drm_i915_private *i915 = fpriv->i915;
struct i915_address_space *vm;
 
if (args->size)
@@ -733,7 +733,7 @@ static int set_proto_ctx_engines(struct 
drm_i915_file_private *fpriv,
 struct i915_gem_proto_context *pc,
 const struct drm_i915_gem_context_param *args)
 {
-   struct drm_i915_private *i915 = fpriv->dev_priv;
+   struct drm_i915_private *i915 = fpriv->i915;
struct set_proto_ctx_engines set = { .i915 = i915 };
struct i915_context_param_engines __user *user =
u64_to_user_ptr(args->value);
@@ -813,7 +813,7 @@ static int set_proto_ctx_sseu(struct drm_i915_file_private 
*fpriv,
  struct i915_gem_proto_context *pc,
  struct drm_i915_gem_context_param *args)
 {
-   struct drm_i915_private *i915 = fpriv->dev_priv;
+   struct drm_i915_private *i915 = fpriv->i915;
struct drm_i915_gem_context_param_sseu user_sseu;
struct intel_sseu *sseu;
int ret;
@@ -913,7 +913,7 @@ static int set_proto_ctx_param(struct drm_i915_file_private 
*fpriv,
break;
 
case I915_CONTEXT_PARAM_PRIORITY:
-   ret = validate_priority(fpriv->dev_priv, args);
+   ret = validate_priority(fpriv->i915, args);
if (!ret)
pc->sched.priority = args->value;
break;
@@ -934,12 +934,12 @@ static int set_proto_ctx_param(struct 
drm_i915_file_private *fpriv,
if (args->size)
ret = -EINVAL;
else
-   ret = proto_context_set_persistence(fpriv->dev_priv, pc,
+   ret = proto_context_set_persistence(fpriv->i915, pc,
args->value);
break;
 
case I915_CONTEXT_PARAM_PROTECTED_CONTENT:
-   ret = proto_context_set_protected(fpriv->dev_priv, pc,
+   ret = proto_context_set_protected(fpriv->i915, pc,
  args->value);
break;
 
@@ -1770,7 +1770,7 @@ void i915_gem_context_close(struct drm_file *file)
unsigned long idx;
 
xa_for_each(_priv->proto_context_xa, idx, pc)
-   proto_context_close(file_priv->dev_priv, pc);
+   proto_context_close(file_priv->i915, pc);
xa_destroy(_priv->proto_context_xa);
mutex_destroy(_priv->proto_context_lock);
 
@@ -2206,7 +2206,7 @@ finalize_create_context_locked(struct 
drm_i915_file_private *file_priv,
 
lockdep_assert_held(_priv->proto_context_lock);
 
-   ctx = i915_gem_create_context(file_priv->dev_priv, pc);
+   ctx = i915_gem_create_context(file_priv->i915, pc);
if (IS_ERR(ctx))
return ctx;
 
@@ -2223,7 +2223,7 @@ finalize_create_context_locked(struct 
drm_i915_file_private *file_priv,
 
old = xa_erase(_priv->proto_context_xa, id);
GEM_BUG_ON(old != pc);
-   proto_context_close(file_priv->dev_priv, pc);
+   proto_context_close(file_priv->i915, pc);
 
return ctx;
 }
@@ -2352,7 +2352,7 @@ int i915_gem_context_destroy_ioctl(struct drm_device 
*dev, void *data,
GEM_WARN_ON(ctx && pc);
 
if (pc)
-   proto_context_close(file_priv->dev_priv, pc);
+   proto_context_close(file_priv->i915, pc);
 
if (ctx)
context_close(ctx);
@@ -2505,7 +2505,7 @@ int i915_gem_context_setparam_ioctl(struct drm_device 
*dev, void *data,
 * GEM_CONTEXT_CREATE starting with graphics
 * version 13.
 */
-   WARN_ON(GRAPHICS_VER(file_priv->dev_priv) > 12);
+   WARN_ON(GRAPHICS_VER(file_priv->i915) > 12);
ret = set_proto_ctx_param(file_priv, pc, args);
} else {
ret = 

Re: [Intel-gfx] [PATCH] drm/i915: Make IRQ reset and postinstall multi-gt aware

[Matt Roper]

On Wed, Mar 22, 2023 at 12:20:09AM +0100, Andi Shyti wrote:
> From: Paulo Zanoni 
> 
> In multitile systems IRQ need to be reset and enabled per GT.

At the moment we're not enabling multi-tile support on any platforms
yet.  Xe_HP SDV has pretty much already served its purpose as an early
Xe_HP test platform, and most PVC effort is refocusing on the Xe KMD
right now.

Note that we don't want/need changes like this on non-tile multi-gt
platforms like MTL.  The interrupt registers you're accessing here are
sgunit registers so there's only ever a single copy of the register on
such platforms; looping around and processing the same register two
times in a row doesn't accomplish anything that just processing them a
single time doesn't.


Matt

> 
> Signed-off-by: Paulo Zanoni 
> Cc: Tvrtko Ursulin 
> Signed-off-by: Andi Shyti 
> ---
>  drivers/gpu/drm/i915/i915_irq.c | 28 ++--
>  1 file changed, 18 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 31271c30a8cf4..ee4530ec14de3 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -2762,14 +2762,19 @@ static void dg1_irq_reset(struct drm_i915_private 
> *dev_priv)
>  {
>   struct intel_gt *gt = to_gt(dev_priv);
>   struct intel_uncore *uncore = gt->uncore;
> + unsigned int i;
>  
>   dg1_master_intr_disable(dev_priv->uncore.regs);
>  
> - gen11_gt_irq_reset(gt);
> - gen11_display_irq_reset(dev_priv);
> + for_each_gt(gt, dev_priv, i) {
> + gen11_gt_irq_reset(gt);
>  
> - GEN3_IRQ_RESET(uncore, GEN11_GU_MISC_);
> - GEN3_IRQ_RESET(uncore, GEN8_PCU_);
> + uncore = gt->uncore;
> + GEN3_IRQ_RESET(uncore, GEN11_GU_MISC_);
> + GEN3_IRQ_RESET(uncore, GEN8_PCU_);
> + }
> +
> + gen11_display_irq_reset(dev_priv);
>  }
>  
>  void gen8_irq_power_well_post_enable(struct drm_i915_private *dev_priv,
> @@ -3423,13 +3428,16 @@ static void gen11_irq_postinstall(struct 
> drm_i915_private *dev_priv)
>  
>  static void dg1_irq_postinstall(struct drm_i915_private *dev_priv)
>  {
> - struct intel_gt *gt = to_gt(dev_priv);
> - struct intel_uncore *uncore = gt->uncore;
>   u32 gu_misc_masked = GEN11_GU_MISC_GSE;
> + struct intel_gt *gt;
> + unsigned int i;
>  
> - gen11_gt_irq_postinstall(gt);
> + for_each_gt(gt, dev_priv, i) {
> + gen11_gt_irq_postinstall(gt);
>  
> - GEN3_IRQ_INIT(uncore, GEN11_GU_MISC_, ~gu_misc_masked, gu_misc_masked);
> + GEN3_IRQ_INIT(gt->uncore, GEN11_GU_MISC_, ~gu_misc_masked,
> +   gu_misc_masked);
> + }
>  
>   if (HAS_DISPLAY(dev_priv)) {
>   icp_irq_postinstall(dev_priv);
> @@ -3438,8 +3446,8 @@ static void dg1_irq_postinstall(struct drm_i915_private 
> *dev_priv)
>  GEN11_DISPLAY_IRQ_ENABLE);
>   }
>  
> - dg1_master_intr_enable(uncore->regs);
> - intel_uncore_posting_read(uncore, DG1_MSTR_TILE_INTR);
> + dg1_master_intr_enable(to_gt(dev_priv)->uncore->regs);
> + intel_uncore_posting_read(to_gt(dev_priv)->uncore, DG1_MSTR_TILE_INTR);
>  }
>  
>  static void cherryview_irq_postinstall(struct drm_i915_private *dev_priv)
> -- 
> 2.39.2
> 

-- 
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation

Re: [PATCH v2 00/65] clk: Make determine_rate mandatory for muxes

[Stephen Boyd]

Quoting Maxime Ripard (2022-11-04 06:17:17)
> Hi,
> 
> This is a follow-up to a previous series that was printing a warning
> when a mux has a set_parent implementation but is missing
> determine_rate().
> 
> The rationale is that set_parent() is very likely to be useful when
> changing the rate, but it's determine_rate() that takes the parenting
> decision. If we're missing it, then the current parent is always going
> to be used, and thus set_parent() will not be used. The only exception
> being a direct call to clk_set_parent(), but those are fairly rare
> compared to clk_set_rate().
> 
> Stephen then asked to promote the warning to an error, and to fix up all
> the muxes that are in that situation first. So here it is :)
> 
> Let me know what you think,

What's the plan here? Are you going to resend?

[PATCH] drm/i915: Make IRQ reset and postinstall multi-gt aware

[Andi Shyti]

From: Paulo Zanoni 

In multitile systems IRQ need to be reset and enabled per GT.

Signed-off-by: Paulo Zanoni 
Cc: Tvrtko Ursulin 
Signed-off-by: Andi Shyti 
---
 drivers/gpu/drm/i915/i915_irq.c | 28 ++--
 1 file changed, 18 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 31271c30a8cf4..ee4530ec14de3 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2762,14 +2762,19 @@ static void dg1_irq_reset(struct drm_i915_private 
*dev_priv)
 {
struct intel_gt *gt = to_gt(dev_priv);
struct intel_uncore *uncore = gt->uncore;
+   unsigned int i;
 
dg1_master_intr_disable(dev_priv->uncore.regs);
 
-   gen11_gt_irq_reset(gt);
-   gen11_display_irq_reset(dev_priv);
+   for_each_gt(gt, dev_priv, i) {
+   gen11_gt_irq_reset(gt);
 
-   GEN3_IRQ_RESET(uncore, GEN11_GU_MISC_);
-   GEN3_IRQ_RESET(uncore, GEN8_PCU_);
+   uncore = gt->uncore;
+   GEN3_IRQ_RESET(uncore, GEN11_GU_MISC_);
+   GEN3_IRQ_RESET(uncore, GEN8_PCU_);
+   }
+
+   gen11_display_irq_reset(dev_priv);
 }
 
 void gen8_irq_power_well_post_enable(struct drm_i915_private *dev_priv,
@@ -3423,13 +3428,16 @@ static void gen11_irq_postinstall(struct 
drm_i915_private *dev_priv)
 
 static void dg1_irq_postinstall(struct drm_i915_private *dev_priv)
 {
-   struct intel_gt *gt = to_gt(dev_priv);
-   struct intel_uncore *uncore = gt->uncore;
u32 gu_misc_masked = GEN11_GU_MISC_GSE;
+   struct intel_gt *gt;
+   unsigned int i;
 
-   gen11_gt_irq_postinstall(gt);
+   for_each_gt(gt, dev_priv, i) {
+   gen11_gt_irq_postinstall(gt);
 
-   GEN3_IRQ_INIT(uncore, GEN11_GU_MISC_, ~gu_misc_masked, gu_misc_masked);
+   GEN3_IRQ_INIT(gt->uncore, GEN11_GU_MISC_, ~gu_misc_masked,
+ gu_misc_masked);
+   }
 
if (HAS_DISPLAY(dev_priv)) {
icp_irq_postinstall(dev_priv);
@@ -3438,8 +3446,8 @@ static void dg1_irq_postinstall(struct drm_i915_private 
*dev_priv)
   GEN11_DISPLAY_IRQ_ENABLE);
}
 
-   dg1_master_intr_enable(uncore->regs);
-   intel_uncore_posting_read(uncore, DG1_MSTR_TILE_INTR);
+   dg1_master_intr_enable(to_gt(dev_priv)->uncore->regs);
+   intel_uncore_posting_read(to_gt(dev_priv)->uncore, DG1_MSTR_TILE_INTR);
 }
 
 static void cherryview_irq_postinstall(struct drm_i915_private *dev_priv)
-- 
2.39.2

Re: [PATCH v2 1/2] drm/i915: Sanitycheck MMIO access early in driver load

[Andi Shyti]

Hi Matt,

> > We occasionally see the PCI device in a non-accessible state at the
> > point the driver is loaded.  When this happens, all BAR accesses will
> > read back as 0x.  Rather than reading registers and
> > misinterpreting their (invalid) values, let's specifically check for
> > 0x in a register that cannot have that value to see if the
> > device is accessible.
> > 
> > Signed-off-by: Matt Roper 
> > Cc: Mika Kuoppala 
> > Signed-off-by: Andi Shyti 
> > ---
> >  drivers/gpu/drm/i915/intel_uncore.c | 35 +
> >  1 file changed, 35 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
> > b/drivers/gpu/drm/i915/intel_uncore.c
> > index e1e1f34490c8e..0b69081d6d285 100644
> > --- a/drivers/gpu/drm/i915/intel_uncore.c
> > +++ b/drivers/gpu/drm/i915/intel_uncore.c
> > @@ -2602,11 +2602,46 @@ static int uncore_forcewake_init(struct 
> > intel_uncore *uncore)
> > return 0;
> >  }
> >  
> > +static int sanity_check_mmio_access(struct intel_uncore *uncore)
> > +{
> > +   struct drm_i915_private *i915 = uncore->i915;
> > +   int ret;
> > +
> > +   if (GRAPHICS_VER(i915) < 8)
> > +   return 0;
> > +
> > +   /*
> > +* Sanitycheck that MMIO access to the device is working properly.  If
> > +* the CPU is unable to communcate with a PCI device, BAR reads will
> > +* return 0x.  Let's make sure the device isn't in this state
> > +* before we start trying to access registers.
> > +*
> > +* We use the primary GT's forcewake register as our guinea pig since
> > +* it's been around since HSW and it's a masked register so the upper
> > +* 16 bits can never read back as 1's if device access is operating
> > +* properly.
> > +*
> > +* If MMIO isn't working, we'll wait up to 2 seconds to see if it
> > +* recovers, then give up.
> > +*/
> > +   ret = intel_wait_for_register_fw(uncore, FORCEWAKE_MT, 0, 0, 200);
> 
> It looks like you lost the check for 0x specifically.  In fact
> with a mask/value of 0, isn't this always going to just always pass
> immediately?

uh... yes... sorry, I just got confused and lost track of the
goal of the patch.

Sorry, then please ignore... I don't see then how
intel_wait_for_register_fw() can be used with a '!='.

Please, ignore this v2.

Thanks and sorry, again,
Andi

> We don't know what the value of this register will be (there may or may
> not be some bits set), but we need to make sure that it isn't 0x
> because that means we're not even truly accessing the register, just
> hitting a PCI BAR read failure.
> 
> 
> Matt
> 
> > +   if (ret == -ETIMEDOUT) {
> > +   drm_err(>drm, "Device is non-operational; MMIO access 
> > returns 0x!\n");
> > +   return -EIO;
> > +   }
> > +
> > +   return 0;
> > +}
> > +
> >  int intel_uncore_init_mmio(struct intel_uncore *uncore)
> >  {
> > struct drm_i915_private *i915 = uncore->i915;
> > int ret;
> >  
> > +   ret = sanity_check_mmio_access(uncore);
> > +   if (ret)
> > +   return ret;
> > +
> > /*
> >  * The boot firmware initializes local memory and assesses its health.
> >  * If memory training fails, the punit will have been instructed to
> > -- 
> > 2.39.2
> > 
> 
> -- 
> Matt Roper
> Graphics Software Engineer
> Linux GPU Platform Enablement
> Intel Corporation

Re: [PATCH 25/32] drm/amdkfd: add debug suspend and resume process queues operation

[Felix Kuehling]

On 2023-01-25 14:53, Jonathan Kim wrote:

In order to inspect waves from the saved context at any point during a
debug session, the debugger must be able to preempt queues to trigger
context save by suspending them.

On queue suspend, the KFD will copy the context save header information
so that the debugger can correctly crawl the appropriate size of the saved
context. The debugger must then also be allowed to resume suspended queues.

A queue that is newly created cannot be suspended because queue ids are
recycled after destruction so the debugger needs to know that this has
occurred.  Query functions will be later added that will clear a given
queue of its new queue status.

A queue cannot be destroyed while it is suspended to preserve its saved
context during debugger inspection.  Have queue destruction block while
a queue is suspended and unblocked when it is resumed.  Likewise, if a
queue is about to be destroyed, it cannot be suspended.

Return the number of queues successfully suspended or resumed along with
a per queue status array where the upper bits per queue status show that
the request was invalid (new/destroyed queue suspend request, missing
queue) or an error occurred (HWS in a fatal state so it can't suspend or
resume queues).

v2: add gfx11/mes support.
prevent header copy on suspend from overwriting user fields.
simplify resume_queues function.
address other nit-picks

Signed-off-by: Jonathan Kim 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c|   5 +
  drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h|   1 +
  drivers/gpu/drm/amd/amdkfd/kfd_chardev.c  |  11 +
  drivers/gpu/drm/amd/amdkfd/kfd_debug.c|   7 +
  .../drm/amd/amdkfd/kfd_device_queue_manager.c | 446 +-
  .../drm/amd/amdkfd/kfd_device_queue_manager.h |  10 +
  .../gpu/drm/amd/amdkfd/kfd_mqd_manager_v10.c  |  14 +
  .../gpu/drm/amd/amdkfd/kfd_mqd_manager_v11.c  |  11 +-
  .../gpu/drm/amd/amdkfd/kfd_mqd_manager_v9.c   |  18 +-
  drivers/gpu/drm/amd/amdkfd/kfd_priv.h |   5 +-
  10 files changed, 518 insertions(+), 10 deletions(-)


[snip]

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_v9.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_v9.c
index 50da16dd4c96..047c43418a1a 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_v9.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_v9.c
@@ -288,6 +288,11 @@ static int get_wave_state(struct mqd_manager *mm, void 
*mqd,
  u32 *save_area_used_size)
  {
struct v9_mqd *m;
+   struct kfd_context_save_area_header header;
+   size_t header_copy_size = sizeof(header.control_stack_size) +
+   sizeof(header.wave_state_size) +
+   sizeof(header.wave_state_offset) +
+   sizeof(header.control_stack_offset);


This makes assumptions about the structure layout. I'd feel better if 
these fields were in a sub-structure, which would make this easier and 
safer to handle.


struct kfd_context_save_area_header {
struct {
__u32 control_stack_offset;
__u32 control_stack_size;
__u32 wave_state_offset;
__u32 wave_state_size;
} wave_state;
...
};

...

|static int get_wave_state(...) { struct kfd_context_save_area_header 
header; ... header.wave_state.control_stack_size = *ctl_stack_used_size; 
header.wave_state.wave_state_size = *save_area_used_size; 
header.wave_state.wave_state_offset = m->cp_hqd_wg_state_offset; 
header.wave_state.control_stack_offset = m->cp_hqd_cntl_stack_offset; if 
(copy_to_user(ctl_stack, _state, sizeof(header.wave_state))) 
return -EFAULT; ... } |


This way you're sure you only copy initialized data. The only assumption 
this still makes is, that wave_state is at the start of the header 
structure.


Regards,
  Felix


  
  	/* Control stack is located one page after MQD. */

void *mqd_ctl_stack = (void *)((uintptr_t)mqd + PAGE_SIZE);
@@ -299,7 +304,18 @@ static int get_wave_state(struct mqd_manager *mm, void 
*mqd,
*save_area_used_size = m->cp_hqd_wg_state_offset -
m->cp_hqd_cntl_stack_size;
  
-	if (copy_to_user(ctl_stack, mqd_ctl_stack, m->cp_hqd_cntl_stack_size))

+   header.control_stack_size = *ctl_stack_used_size;
+   header.wave_state_size = *save_area_used_size;
+
+   header.wave_state_offset = m->cp_hqd_wg_state_offset;
+   header.control_stack_offset = m->cp_hqd_cntl_stack_offset;
+
+   if (copy_to_user(ctl_stack, , header_copy_size))
+   return -EFAULT;
+
+   if (copy_to_user(ctl_stack + m->cp_hqd_cntl_stack_offset,
+   mqd_ctl_stack + m->cp_hqd_cntl_stack_offset,
+   *ctl_stack_used_size))
return -EFAULT;
  
  	return 0;

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_priv.h 
b/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
index 6f7dc23af104..8dc7cc1e18a5 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
+++ 

Re: [PATCH v2 1/2] drm/i915: Sanitycheck MMIO access early in driver load

[Matt Roper]

On Tue, Mar 21, 2023 at 06:09:35PM +0100, Andi Shyti wrote:
> From: Matt Roper 
> 
> We occasionally see the PCI device in a non-accessible state at the
> point the driver is loaded.  When this happens, all BAR accesses will
> read back as 0x.  Rather than reading registers and
> misinterpreting their (invalid) values, let's specifically check for
> 0x in a register that cannot have that value to see if the
> device is accessible.
> 
> Signed-off-by: Matt Roper 
> Cc: Mika Kuoppala 
> Signed-off-by: Andi Shyti 
> ---
>  drivers/gpu/drm/i915/intel_uncore.c | 35 +
>  1 file changed, 35 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
> b/drivers/gpu/drm/i915/intel_uncore.c
> index e1e1f34490c8e..0b69081d6d285 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -2602,11 +2602,46 @@ static int uncore_forcewake_init(struct intel_uncore 
> *uncore)
>   return 0;
>  }
>  
> +static int sanity_check_mmio_access(struct intel_uncore *uncore)
> +{
> + struct drm_i915_private *i915 = uncore->i915;
> + int ret;
> +
> + if (GRAPHICS_VER(i915) < 8)
> + return 0;
> +
> + /*
> +  * Sanitycheck that MMIO access to the device is working properly.  If
> +  * the CPU is unable to communcate with a PCI device, BAR reads will
> +  * return 0x.  Let's make sure the device isn't in this state
> +  * before we start trying to access registers.
> +  *
> +  * We use the primary GT's forcewake register as our guinea pig since
> +  * it's been around since HSW and it's a masked register so the upper
> +  * 16 bits can never read back as 1's if device access is operating
> +  * properly.
> +  *
> +  * If MMIO isn't working, we'll wait up to 2 seconds to see if it
> +  * recovers, then give up.
> +  */
> + ret = intel_wait_for_register_fw(uncore, FORCEWAKE_MT, 0, 0, 200);

It looks like you lost the check for 0x specifically.  In fact
with a mask/value of 0, isn't this always going to just always pass
immediately?

We don't know what the value of this register will be (there may or may
not be some bits set), but we need to make sure that it isn't 0x
because that means we're not even truly accessing the register, just
hitting a PCI BAR read failure.


Matt

> + if (ret == -ETIMEDOUT) {
> + drm_err(>drm, "Device is non-operational; MMIO access 
> returns 0x!\n");
> + return -EIO;
> + }
> +
> + return 0;
> +}
> +
>  int intel_uncore_init_mmio(struct intel_uncore *uncore)
>  {
>   struct drm_i915_private *i915 = uncore->i915;
>   int ret;
>  
> + ret = sanity_check_mmio_access(uncore);
> + if (ret)
> + return ret;
> +
>   /*
>* The boot firmware initializes local memory and assesses its health.
>* If memory training fails, the punit will have been instructed to
> -- 
> 2.39.2
> 

-- 
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation

Re: [PATCH v4 1/8] accel/qaic: Add documentation for AIC100 accelerator driver

[Jeffrey Hugo]

On 3/21/2023 7:31 AM, Bagas Sanjaya wrote:

On Mon, Mar 20, 2023 at 09:11:07AM -0600, Jeffrey Hugo wrote:

+AIC100 defines a number of MHI channels for different purposes. This is a list
+of the defined channels, and their uses.
+
+| QAIC_LOOPBACK
+| Channels 0 & 1
+| Valid for AMSS
+| Any data sent to the device on this channel is sent back to the host.
+
+| QAIC_SAHARA
+| Channels 2 & 3
+| Valid for SBL
+| Used by SBL to obtain the runtime firmware from the host.
+
+| QAIC_DIAG
+| Channels 4 & 5
+| Valid for AMSS
+| Used to communicate with QSM via the Diag protocol.
+
+| QAIC_SSR
+| Channels 6 & 7
+| Valid for AMSS
+| Used to notify the host of subsystem restart events, and to offload SSR 
crashdumps.
+
+| QAIC_QDSS
+| Channels 8 & 9
+| Valid for AMSS
+| Used for the Qualcomm Debug Subsystem.
+
+| QAIC_CONTROL
+| Channels 10 & 11
+| Valid for AMSS
+| Used for the Neural Network Control (NNC) protocol.  This is the primary 
channel between host and
+  QSM for managing workloads.
+
+| QAIC_LOGGING
+| Channels 12 & 13
+| Valid for SBL
+| Used by the SBL to send the bootlog to the host.
+
+| QAIC_STATUS
+| Channels 14 & 15
+| Valid for AMSS
+| Used to notify the host of Reliability, Accessibility, Serviceability (RAS) 
events.
+
+| QAIC_TELEMETRY
+| Channels 16 & 17
+| Valid for AMSS
+| Used to get/set power/thermal/etc attributes.
+
+| QAIC_DEBUG
+| Channels 18 & 19
+| Valid for AMSS
+| Not used.
+
+| QAIC_TIMESYNC
+| Channels 20 & 21
+| Valid for SBL/AMSS
+| Used to synchronize timestamps in the device side logs with the host time 
source.


For the tabular data above, use table syntax instead.


Done.


+A request FIFO element has the following structure:
+
+| {
+|  u16 req_id;
+|  u8  seq_id;
+|  u8  pcie_dma_cmd;
+|  u32 reserved;
+|  u64 pcie_dma_source_addr;
+|  u64 pcie_dma_dest_addr;
+|  u32 pcie_dma_len;
+|  u32 reserved;
+|  u64 doorbell_addr;
+|  u8  doorbell_attr;
+|  u8  reserved;
+|  u16 reserved;
+|  u32 doorbell_data;
+|  u32 sem_cmd0;
+|  u32 sem_cmd1;
+|  u32 sem_cmd2;
+|  u32 sem_cmd3;
+| }


IMO code blocks should better fit the struct listing above.


Done


+
+Request field descriptions:
+
+| req_id- request ID. A request FIFO element and a response FIFO element with
+| the same request ID refer to the same command.
+
+| seq_id- sequence ID within a request. Ignored by the DMA Bridge.
+
+| pcie_dma_cmd- describes the DMA element of this request.
+|  Bit(7) is the force msi flag, which overrides the DMA Bridge MSI logic
+|  and generates a MSI when this request is complete, and QSM
+|  configures the DMA Bridge to look at this bit.
+|  Bits(6:5) are reserved.
+|  Bit(4) is the completion code flag, and indicates that the DMA Bridge
+|  shall generate a response FIFO element when this request is
+|  complete.
+|  Bit(3) indicates if this request is a linked list transfer(0) or a bulk
+|  transfer(1).
+|  Bit(2) is reserved.
+|  Bits(1:0) indicate the type of transfer. No transfer(0), to device(1),
+|  from device(2). Value 3 is illegal.
+
+| pcie_dma_source_addr- source address for a bulk transfer, or the address of
+| the linked list.
+
+| pcie_dma_dest_addr- destination address for a bulk transfer.
+
+| pcie_dma_len- length of the bulk transfer. Note that the size of this field
+|  limits transfers to 4G in size.
+
+| doorbell_addr- address of the doorbell to ring when this request is complete.
+
+| doorbell_attr- doorbell attributes.
+|  Bit(7) indicates if a write to a doorbell is to occur.
+|  Bits(6:2) are reserved.
+|  Bits(1:0) contain the encoding of the doorbell length. 0 is 32-bit,
+|  1 is 16-bit, 2 is 8-bit, 3 is reserved. The doorbell address
+|  must be naturally aligned to the specified length.
+
+| doorbell_data- data to write to the doorbell. Only the bits corresponding to
+|  the doorbell length are valid.
+
+| sem_cmdN- semaphore command.
+|  Bit(31) indicates this semaphore command is enabled.
+|  Bit(30) is the to-device DMA fence. Block this request until all
+|  to-device DMA transfers are complete.
+|  Bit(29) is the from-device DMA fence. Block this request until all
+|  from-device DMA transfers are complete.
+|  Bits(28:27) are reserved.
+|  Bits(26:24) are the semaphore command. 0 is NOP. 1 is init with the
+|  specified value. 2 is increment. 3 is decrement. 4 is wait
+|  until the semaphore is equal to the specified value. 5 is wait
+|  until the semaphore is greater or equal to the specified value.
+|  6 is "P", wait until semaphore is greater than 0, then
+|  decrement by 1. 7 is reserved.
+|  Bit(23) is reserved.
+|  Bit(22) is the semaphore sync. 0 is post sync, which means that the
+|  semaphore operation is 

Re: [PATCH 24/32] drm/amdkfd: add debug wave launch mode operation

[Felix Kuehling]

On 2023-01-25 14:53, Jonathan Kim wrote:

Allow the debugger to set wave behaviour on to either normally operate,
halt at launch, trap on every instruction, terminate immediately or
stall on allocation.

v2: add gfx11 support and remove deprecated launch mode options

Signed-off-by: Jonathan Kim 
---
  .../drm/amd/amdgpu/amdgpu_amdkfd_aldebaran.c  | 12 +++
  .../drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c   |  1 +
  .../drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c| 25 +
  .../drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.h|  3 ++
  .../drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10_3.c  |  3 +-
  .../drm/amd/amdgpu/amdgpu_amdkfd_gfx_v11.c| 14 +++-
  .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c | 25 +
  .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.h |  3 ++
  drivers/gpu/drm/amd/amdkfd/kfd_chardev.c  |  3 ++
  drivers/gpu/drm/amd/amdkfd/kfd_debug.c| 36 ++-
  drivers/gpu/drm/amd/amdkfd/kfd_debug.h|  5 ++-
  11 files changed, 124 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_aldebaran.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_aldebaran.c
index 84a9d9391ea4..4de2066215b4 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_aldebaran.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_aldebaran.c
@@ -107,6 +107,17 @@ static uint32_t 
kgd_aldebaran_set_wave_launch_trap_override(struct amdgpu_device
return data;
  }
  
+static uint32_t kgd_aldebaran_set_wave_launch_mode(struct amdgpu_device *adev,

+   uint8_t wave_launch_mode,
+   uint32_t vmid)
+{
+   uint32_t data = 0;
+
+   data = REG_SET_FIELD(data, SPI_GDBG_PER_VMID_CNTL, LAUNCH_MODE, 
wave_launch_mode);
+
+   return data;
+}
+
  const struct kfd2kgd_calls aldebaran_kfd2kgd = {
.program_sh_mem_settings = kgd_gfx_v9_program_sh_mem_settings,
.set_pasid_vmid_mapping = kgd_gfx_v9_set_pasid_vmid_mapping,
@@ -128,6 +139,7 @@ const struct kfd2kgd_calls aldebaran_kfd2kgd = {
.disable_debug_trap = kgd_aldebaran_disable_debug_trap,
.validate_trap_override_request = 
kgd_aldebaran_validate_trap_override_request,
.set_wave_launch_trap_override = 
kgd_aldebaran_set_wave_launch_trap_override,
+   .set_wave_launch_mode = kgd_aldebaran_set_wave_launch_mode,
.get_iq_wait_times = kgd_gfx_v9_get_iq_wait_times,
.build_grace_period_packet_info = 
kgd_gfx_v9_build_grace_period_packet_info,
.program_trap_handler_settings = 
kgd_gfx_v9_program_trap_handler_settings,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c
index 0405725e95e3..500013540356 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c
@@ -412,6 +412,7 @@ const struct kfd2kgd_calls arcturus_kfd2kgd = {
.disable_debug_trap = kgd_arcturus_disable_debug_trap,
.validate_trap_override_request = 
kgd_gfx_v9_validate_trap_override_request,
.set_wave_launch_trap_override = 
kgd_gfx_v9_set_wave_launch_trap_override,
+   .set_wave_launch_mode = kgd_gfx_v9_set_wave_launch_mode,
.get_iq_wait_times = kgd_gfx_v9_get_iq_wait_times,
.build_grace_period_packet_info = 
kgd_gfx_v9_build_grace_period_packet_info,
.get_cu_occupancy = kgd_gfx_v9_get_cu_occupancy,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c
index 32a6e5fbeacd..7591145bc69f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c
@@ -854,6 +854,30 @@ uint32_t kgd_gfx_v10_set_wave_launch_trap_override(struct 
amdgpu_device *adev,
return 0;
  }
  
+uint32_t kgd_gfx_v10_set_wave_launch_mode(struct amdgpu_device *adev,

+   uint8_t wave_launch_mode,
+   uint32_t vmid)
+{
+   uint32_t data = 0;
+   bool is_mode_set = !!wave_launch_mode;
+
+   mutex_lock(>grbm_idx_mutex);
+
+   kgd_gfx_v10_set_wave_launch_stall(adev, vmid, true);
+
+   data = REG_SET_FIELD(data, SPI_GDBG_WAVE_CNTL2,
+   VMID_MASK, is_mode_set ? 1 << vmid : 0);
+   data = REG_SET_FIELD(data, SPI_GDBG_WAVE_CNTL2,
+   MODE, is_mode_set ? wave_launch_mode : 0);
+   WREG32(SOC15_REG_OFFSET(GC, 0, mmSPI_GDBG_WAVE_CNTL2), data);
+
+   kgd_gfx_v10_set_wave_launch_stall(adev, vmid, false);
+
+   mutex_unlock(>grbm_idx_mutex);
+
+   return 0;
+}
+
  /* kgd_gfx_v10_get_iq_wait_times: Returns the mmCP_IQ_WAIT_TIME1/2 values
   * The values read are:
   * ib_offload_wait_time -- Wait Count for Indirect Buffer Offloads.
@@ -941,6 +965,7 @@ const struct kfd2kgd_calls gfx_v10_kfd2kgd = {
.disable_debug_trap = kgd_gfx_v10_disable_debug_trap,
.validate_trap_override_request = 

Re: [PATCH 23/32] drm/amdkfd: add debug wave launch override operation

[Felix Kuehling]

On 2023-01-25 14:53, Jonathan Kim wrote:

This operation allows the debugger to override the enabled HW
exceptions on the device.

On debug devices that only support the debugging of a single process,
the HW exceptions are global and set through the SPI_GDBG_TRAP_MASK
register.
Because they are global, only address watch exceptions are allowed to
be enabled.  In other words, the debugger must preserve all non-address
watch exception states in normal mode operation by barring a full
replacement override or a non-address watch override request.

For multi-process debugging, all HW exception overrides are per-VMID so
all exceptions can be overridden or fully replaced.

In order for the debugger to know what is permissible, returned the
supported override mask back to the debugger along with the previously
enable overrides.

v3: v2 was reviewed but requesting re-review for GFX11 added supported.

v2: switch unsupported override mode return from EPERM to EINVAL to
support unique EPERM on PTRACE failure.

Signed-off-by: Jonathan Kim 
---
  .../drm/amd/amdgpu/amdgpu_amdkfd_aldebaran.c  | 47 ++
  .../drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c   |  2 +
  .../drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c| 55 
  .../drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.h| 10 +++
  .../drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10_3.c  |  5 +-
  .../drm/amd/amdgpu/amdgpu_amdkfd_gfx_v11.c| 86 ++-
  .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c | 55 
  .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.h | 10 +++
  drivers/gpu/drm/amd/amdkfd/kfd_chardev.c  |  7 ++
  drivers/gpu/drm/amd/amdkfd/kfd_debug.c| 69 +++
  drivers/gpu/drm/amd/amdkfd/kfd_debug.h|  6 ++
  11 files changed, 350 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_aldebaran.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_aldebaran.c
index a64a53f9efe6..84a9d9391ea4 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_aldebaran.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_aldebaran.c
@@ -25,6 +25,7 @@
  #include "amdgpu_amdkfd_gfx_v9.h"
  #include "gc/gc_9_4_2_offset.h"
  #include "gc/gc_9_4_2_sh_mask.h"
+#include 
  
  /**

   * Returns TRAP_EN, EXCP_EN and EXCP_REPLACE.
@@ -62,6 +63,50 @@ static uint32_t kgd_aldebaran_disable_debug_trap(struct 
amdgpu_device *adev,
return data;
  }
  
+static int kgd_aldebaran_validate_trap_override_request(struct amdgpu_device *adev,

+   uint32_t trap_override,
+   uint32_t 
*trap_mask_supported)
+{
+   *trap_mask_supported &= KFD_DBG_TRAP_MASK_FP_INVALID |
+   KFD_DBG_TRAP_MASK_FP_INPUT_DENORMAL |
+   KFD_DBG_TRAP_MASK_FP_DIVIDE_BY_ZERO |
+   KFD_DBG_TRAP_MASK_FP_OVERFLOW |
+   KFD_DBG_TRAP_MASK_FP_UNDERFLOW |
+   KFD_DBG_TRAP_MASK_FP_INEXACT |
+   KFD_DBG_TRAP_MASK_INT_DIVIDE_BY_ZERO |
+   KFD_DBG_TRAP_MASK_DBG_ADDRESS_WATCH |
+   KFD_DBG_TRAP_MASK_DBG_MEMORY_VIOLATION;
+
+   if (trap_override != KFD_DBG_TRAP_OVERRIDE_OR &&
+   trap_override != KFD_DBG_TRAP_OVERRIDE_REPLACE)
+   return -EPERM;
+
+   return 0;
+}
+
+/* returns TRAP_EN, EXCP_EN and EXCP_RPLACE. */
+static uint32_t kgd_aldebaran_set_wave_launch_trap_override(struct 
amdgpu_device *adev,
+   uint32_t vmid,
+   uint32_t trap_override,
+   uint32_t trap_mask_bits,
+   uint32_t trap_mask_request,
+   uint32_t *trap_mask_prev,
+   uint32_t kfd_dbg_trap_cntl_prev)
+
+{
+   uint32_t data = 0;
+
+   *trap_mask_prev = REG_GET_FIELD(kfd_dbg_trap_cntl_prev, 
SPI_GDBG_PER_VMID_CNTL, EXCP_EN);
+   trap_mask_bits = (trap_mask_bits & trap_mask_request) |
+   (*trap_mask_prev & ~trap_mask_request);
+
+   data = REG_SET_FIELD(data, SPI_GDBG_PER_VMID_CNTL, TRAP_EN, 1);
+   data = REG_SET_FIELD(data, SPI_GDBG_PER_VMID_CNTL, EXCP_EN, 
trap_mask_bits);
+   data = REG_SET_FIELD(data, SPI_GDBG_PER_VMID_CNTL, EXCP_REPLACE, 
trap_override);
+
+   return data;
+}
+
  const struct kfd2kgd_calls aldebaran_kfd2kgd = {
.program_sh_mem_settings = kgd_gfx_v9_program_sh_mem_settings,
.set_pasid_vmid_mapping = kgd_gfx_v9_set_pasid_vmid_mapping,
@@ -81,6 +126,8 @@ const struct kfd2kgd_calls aldebaran_kfd2kgd = {
.set_vm_context_page_table_base = 
kgd_gfx_v9_set_vm_context_page_table_base,
.enable_debug_trap = kgd_aldebaran_enable_debug_trap,
.disable_debug_trap = kgd_aldebaran_disable_debug_trap,
+   

[PATCH] dt-bindings: display: msm: sm8350-mdss: Fix DSI compatible

[Konrad Dybcio]

The DSI compatible changed between patchset revisions, but that wasn't
reflected in the bindings. Fix it.

Fixes: 430e11f42bff ("dt-bindings: display: msm: Add qcom, sm8350-mdss binding")
Signed-off-by: Konrad Dybcio 
---
 .../devicetree/bindings/display/msm/qcom,sm8350-mdss.yaml   | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/Documentation/devicetree/bindings/display/msm/qcom,sm8350-mdss.yaml 
b/Documentation/devicetree/bindings/display/msm/qcom,sm8350-mdss.yaml
index 4d94dbff3054..79a226e4cc6a 100644
--- a/Documentation/devicetree/bindings/display/msm/qcom,sm8350-mdss.yaml
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sm8350-mdss.yaml
@@ -64,7 +64,7 @@ patternProperties:
 type: object
 properties:
   compatible:
-const: qcom,dsi-phy-5nm-8350
+const: qcom,sm8350-dsi-phy-5nm
 
 unevaluatedProperties: false
 
-- 
2.40.0

Re: [PATCH 21/32] drm/amdkfd: update process interrupt handling for debug events

[Felix Kuehling]

On 2023-01-25 14:53, Jonathan Kim wrote:

The debugger must be notified by any debugger subscribed exception
that comes from hardware interrupts.

If a debugger session exits, any exceptions it subscribed to may still
have interrupts in the interrupt ring buffer or KGD/KFD pipeline.
To prevent a new session from inheriting stale interrupts, when a new
queue is created, open an interrupt drain and allow the IH ring to drain
from a timestamped checkpoint.  Then inject a custom IV so that once
the custom IV is picked up by the KFD, it's safe to close the drain
and proceed with queue creation.

The drain must also be on debug disable as SW interrupts may still
be processed.  Drain at this time and clear all the exception status.

The debugger may also not be attached nor subscibed to certain
exceptions so forward them directly to the runtime.

GFX10 also requires its own IV processing, hence the creation of
kfd_int_process_v10.c.  This is because the IV from SQ interrupts are
packed into a new continguous format unlike GFX9. To make this clear,
a separate interrupting handling code file was created.

v3: enable gfx11 interrupts
v2: fix interrupt drain on debug disable.
fix interrupt drain on queue create during -ERESTARTSYS.
fix up macros naming for ECODE parsing.

Signed-off-by: Jonathan Kim 


Some indentation nit-picks inline. With those fixed, the patch is

Reviewed-by: Felix Kuehling 



---
  drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c|  16 +
  drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h|   2 +
  drivers/gpu/drm/amd/amdkfd/Makefile   |   1 +
  drivers/gpu/drm/amd/amdkfd/kfd_debug.c|  85 
  drivers/gpu/drm/amd/amdkfd/kfd_debug.h|   6 +
  drivers/gpu/drm/amd/amdkfd/kfd_device.c   |   4 +-
  .../gpu/drm/amd/amdkfd/kfd_int_process_v10.c  | 405 ++
  .../gpu/drm/amd/amdkfd/kfd_int_process_v11.c  |  21 +-
  .../gpu/drm/amd/amdkfd/kfd_int_process_v9.c   |  98 -
  drivers/gpu/drm/amd/amdkfd/kfd_priv.h |  12 +
  drivers/gpu/drm/amd/amdkfd/kfd_process.c  |  47 ++
  .../amd/amdkfd/kfd_process_queue_manager.c|   4 +
  12 files changed, 681 insertions(+), 20 deletions(-)
  create mode 100644 drivers/gpu/drm/amd/amdkfd/kfd_int_process_v10.c

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
index 8816853e50c0..60c3b0449d86 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
@@ -763,6 +763,22 @@ void amdgpu_amdkfd_ras_poison_consumption_handler(struct 
amdgpu_device *adev, bo
amdgpu_umc_poison_handler(adev, reset);
  }
  
+int amdgpu_amdkfd_send_close_event_drain_irq(struct amdgpu_device *adev,

+   uint32_t *payload)
+{
+   int ret;
+
+   /* Device or IH ring is not ready so bail. */
+   ret = amdgpu_ih_wait_on_checkpoint_process_ts(adev, >irq.ih);
+   if (ret)
+   return ret;
+
+   /* Send payload to fence KFD interrupts */
+   amdgpu_amdkfd_interrupt(adev, payload);
+
+   return 0;
+}
+
  bool amdgpu_amdkfd_ras_query_utcl2_poison_status(struct amdgpu_device *adev)
  {
if (adev->gfx.ras && adev->gfx.ras->query_utcl2_poison_status)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
index 333780491867..df782274a4c8 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
@@ -241,6 +241,8 @@ int amdgpu_amdkfd_get_xgmi_bandwidth_mbytes(struct 
amdgpu_device *dst,
struct amdgpu_device *src,
bool is_min);
  int amdgpu_amdkfd_get_pcie_bandwidth_mbytes(struct amdgpu_device *adev, bool 
is_min);
+int amdgpu_amdkfd_send_close_event_drain_irq(struct amdgpu_device *adev,
+   uint32_t *payload);
  
  /* Read user wptr from a specified user address space with page fault

   * disabled. The memory must be pinned and mapped to the hardware when
diff --git a/drivers/gpu/drm/amd/amdkfd/Makefile 
b/drivers/gpu/drm/amd/amdkfd/Makefile
index 747754428073..2ec8f27c5366 100644
--- a/drivers/gpu/drm/amd/amdkfd/Makefile
+++ b/drivers/gpu/drm/amd/amdkfd/Makefile
@@ -53,6 +53,7 @@ AMDKFD_FILES  := $(AMDKFD_PATH)/kfd_module.o \
$(AMDKFD_PATH)/kfd_events.o \
$(AMDKFD_PATH)/cik_event_interrupt.o \
$(AMDKFD_PATH)/kfd_int_process_v9.o \
+   $(AMDKFD_PATH)/kfd_int_process_v10.o \
$(AMDKFD_PATH)/kfd_int_process_v11.o \
$(AMDKFD_PATH)/kfd_smi_events.o \
$(AMDKFD_PATH)/kfd_crat.o \
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_debug.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_debug.c
index 16acf3d416eb..0c876172db4b 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_debug.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_debug.c
@@ -125,6 +125,65 @@ bool kfd_dbg_ev_raise(uint64_t 

Re: [PATCH] drm/sun4i: uncouple DSI dotclock divider from TCON0_DCLK_REG

[Roman Beranek]

On Tue Mar 21, 2023 at 5:50 PM CET, Roman Beranek wrote:

> > Also, how was it tested/confirmed?
>
> By counting Vblank interrupts (GIC 118).

Sorry, that was perhaps too abbreviated. To test this change, I set up
an A64 board running kmscube on DSI-1 and verified that the rate of
Vblank IRQs tracked with a video mode set on DSI-1, once with a 2-lane
panel and once with a 4-lane panel.

Roman

Re: [PATCH v6 5/5] arm64: dts: qcom: sm8450: add dp controller

[Konrad Dybcio]

On 17.03.2023 16:06, Neil Armstrong wrote:
> Add the Display Port controller subnode to the MDSS node.
> 
> Signed-off-by: Neil Armstrong 
> ---
>  arch/arm64/boot/dts/qcom/sm8450.dtsi | 79 
> 
>  1 file changed, 79 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/qcom/sm8450.dtsi 
> b/arch/arm64/boot/dts/qcom/sm8450.dtsi
> index 97ce5fe0e9b0..da6d1881ef60 100644
> --- a/arch/arm64/boot/dts/qcom/sm8450.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sm8450.dtsi
> @@ -2751,6 +2751,13 @@ dpu_intf2_out: endpoint {
>   };
>   };
>  
> + port@2 {
> + reg = <2>;
> + dpu_intf0_out: endpoint {
> + remote-endpoint = 
> <_dp0_in>;
> + };
> + };
> +
>   };
>  
>   mdp_opp_table: opp-table {
> @@ -2783,6 +2790,78 @@ opp-5 {
>   };
>   };
>  
> + mdss_dp0: displayport-controller@ae9 {
> + compatible = "qcom,sm8450-dp", "qcom,sm8350-dp";
> + reg = <0 0xae9 0 0x200>,
> +   <0 0xae90200 0 0x200>,
> +   <0 0xae90400 0 0xc00>,
> +   <0 0xae91000 0 0x400>,
> +   <0 0xae91400 0 0x400>;
> + interrupt-parent = <>;
> + interrupts = <12>;
> + clocks = < DISP_CC_MDSS_AHB_CLK>,
> +  < DISP_CC_MDSS_DPTX0_AUX_CLK>,
> +  < DISP_CC_MDSS_DPTX0_LINK_CLK>,
> +  < 
> DISP_CC_MDSS_DPTX0_LINK_INTF_CLK>,
> +  < 
> DISP_CC_MDSS_DPTX0_PIXEL0_CLK>;
> + clock-names = "core_iface",
> +   "core_aux",
> +   "ctrl_link",
> +   "ctrl_link_iface",
I applied this locally and noticed line has 2x 8 spaces.. Bjorn, could
you please take care of that when applying?

Konrad
> +   "stream_pixel";
> +
> + assigned-clocks = < 
> DISP_CC_MDSS_DPTX0_LINK_CLK_SRC>,
> +   < 
> DISP_CC_MDSS_DPTX0_PIXEL0_CLK_SRC>;
> + assigned-clock-parents = <_1_qmpphy 
> QMP_USB43DP_DP_LINK_CLK>,
> +  <_1_qmpphy 
> QMP_USB43DP_DP_VCO_DIV_CLK>;
> +
> + phys = <_1_qmpphy QMP_USB43DP_DP_PHY>;
> + phy-names = "dp";
> +
> + #sound-dai-cells = <0>;
> +
> + operating-points-v2 = <_opp_table>;
> + power-domains = < SM8450_MMCX>;
> +
> + status = "disabled";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + mdss_dp0_in: endpoint {
> + remote-endpoint = 
> <_intf0_out>;
> + };
> + };
> + };
> +
> + dp_opp_table: opp-table {
> + compatible = "operating-points-v2";
> +
> + opp-16000 {
> + opp-hz = /bits/ 64 <16000>;
> + required-opps = 
> <_opp_low_svs>;
> + };
> +
> + opp-27000 {
> + opp-hz = /bits/ 64 <27000>;
> + required-opps = 
> <_opp_svs>;
> + };
> +
> + opp-54000 {
> + opp-hz = /bits/ 64 <54000>;
> + required-opps = 
> <_opp_svs_l1>;
> + };
> +
> + opp-81000 {
> + opp-hz = /bits/ 64 <81000>;
> + 

Re: [PATCH v2] dt-bindings: display: Drop unneeded quotes

[Miguel Ojeda]

On Tue, Mar 21, 2023 at 12:38 AM Rob Herring  wrote:
>
>  .../bindings/auxdisplay/holtek,ht16k33.yaml   |  2 +-

Acked-by: Miguel Ojeda 

Cheers,
Miguel

Re: [PATCH 1/1] drm/sun4i: tcon: Fix setting PLL rate when using DSI

[Frank Oltmanns]

Hi Maxime,

On 2023-03-21 at 15:57:39 +0100, Maxime Ripard  wrote:
> Hi,
>
> On Sun, Mar 19, 2023 at 05:07:04PM +0100, Frank Oltmanns wrote:
>> Set the required PLL rate by adjusting the dotclock rate when calling
>> clk_set_rate() when using DSI.
>>
>> According to the Allwinners A64’s BSP code, a TCON divider of 4 has to
>> be used and the PLL rate needs to be set to the following frequency when
>> using DSI:
>> PLL rate = DCLK * bpp / lanes
>>
>> After this change the common mode set function would only contain
>> setting the resolution. Therefore, dissolve the function and transfer
>> the functionality to the individual mode set functions.
>>
>> Signed-off-by: Frank Oltmanns 
>
> This is similar to:
> 
>
> What’s the story there?

Sorry, as Roman wrote in the other thread, I submitted the patch after not 
hearing back from him for a week. My apologies, I wasn’t patient enough. So now 
there are two submissions to consider. FWIW, I think this patch is a bit more 
straightforward than the other one.

Best regards,
  Frank

> Maxime
>

Re: [PATCH 2/3] drm/vmwgfx: Print errors when running on broken/unsupported configs

["Maaz Mombasawala (VMware)]

On 3/20/23 19:09, Zack Rusin wrote:
> From: Zack Rusin 
> 
> virtualbox implemented an incomplete version of the svga device which
> they decided to drop soon after the initial release. The device was
> always broken in various ways and never supported by vmwgfx.
> 
> vmwgfx should refuse to load on those configurations but currently
> drm has no way of reloading fbdev when the specific pci driver refuses
> to load, which would leave users without a usable fb. Instead of
> refusing to load print an error and disable a bunch of functionality
> that virtualbox never implemented to at least get fb to work on their
> setup.
> 
> Signed-off-by: Zack Rusin 
> ---
>  drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 29 +
>  drivers/gpu/drm/vmwgfx/vmwgfx_drv.h |  2 ++
>  drivers/gpu/drm/vmwgfx/vmwgfx_msg.c |  9 +
>  3 files changed, 40 insertions(+)
> 
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> index 2588615a2a38..8b24ecf60e3e 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> @@ -45,6 +45,9 @@
>  #include 
>  #include 
>  
> +#ifdef CONFIG_X86
> +#include 
> +#endif
>  #include 
>  #include 
>  #include 
> @@ -897,6 +900,16 @@ static int vmw_driver_load(struct vmw_private *dev_priv, 
> u32 pci_id)
>cap2_names, ARRAY_SIZE(cap2_names));
>   }
>  
> + if (!vmwgfx_supported(dev_priv)) {
> + vmw_disable_backdoor();
> + drm_err_once(_priv->drm,
> +  "vmwgfx seems to be running on an unsupported 
> hypervisor.");
> + drm_err_once(_priv->drm,
> +  "This configuration is likely broken.");
> + drm_err_once(_priv->drm,
> +  "Please switch to a supported graphics device to 
> avoid problems.");
> + }
> +
>   ret = vmw_dma_select_mode(dev_priv);
>   if (unlikely(ret != 0)) {
>   drm_info(_priv->drm,
> @@ -1320,6 +1333,22 @@ static void vmw_master_drop(struct drm_device *dev,
>   vmw_kms_legacy_hotspot_clear(dev_priv);
>  }
>  
> +bool vmwgfx_supported(struct vmw_private *vmw)
> +{
> +#if defined(CONFIG_X86)
> + return hypervisor_is_type(X86_HYPER_VMWARE);
> +#elif defined(CONFIG_ARM64)
> + /*
> +  * On aarch64 only svga3 is supported
> +  */
> + return vmw->pci_id == VMWGFX_PCI_ID_SVGA3;
> +#else
> + drm_warn_once(>drm,
> +   "vmwgfx is running on an unknown architecture.");
> + return false;
> +#endif
> +}
> +
>  /**
>   * __vmw_svga_enable - Enable SVGA mode, FIFO and use of VRAM.
>   *
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> index fb8f0c0642c0..3810a9984a7f 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> @@ -773,6 +773,7 @@ static inline u32 vmw_max_num_uavs(struct vmw_private 
> *dev_priv)
>  
>  extern void vmw_svga_enable(struct vmw_private *dev_priv);
>  extern void vmw_svga_disable(struct vmw_private *dev_priv);
> +bool vmwgfx_supported(struct vmw_private *vmw);
>  
>  
>  /**
> @@ -1358,6 +1359,7 @@ int vmw_bo_cpu_blit(struct ttm_buffer_object *dst,
>   struct vmw_diff_cpy *diff);
>  
>  /* Host messaging -vmwgfx_msg.c: */
> +void vmw_disable_backdoor(void);
>  int vmw_host_get_guestinfo(const char *guest_info_param,
>  char *buffer, size_t *length);
>  __printf(1, 2) int vmw_host_printf(const char *fmt, ...);
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c
> index ca1a3fe44fa5..2651fe0ef518 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c
> @@ -1179,3 +1179,12 @@ int vmw_mksstat_remove_ioctl(struct drm_device *dev, 
> void *data,
>  
>   return -EAGAIN;
>  }
> +
> +/**
> + * vmw_disable_backdoor: Disables all backdoor communication
> + * with the hypervisor.
> + */
> +void vmw_disable_backdoor(void)
> +{
> + vmw_msg_enabled = 0;
> +}


LGTM

Reviewed-by: Maaz Mombasawala 

-- 
Maaz Mombasawala (VMware) 

Re: [v2,1/8] drm/fbdev-generic: Always use shadow buffering

[Thomas Zimmermann]

Hi,

thanks for testing the patchset.

Am 21.03.23 um 16:23 schrieb Sui jingfeng:


On 2023/3/20 23:07, Thomas Zimmermann wrote:

Remove all codepaths that implement fbdev output directly on GEM
buffers. Always allocate a shadow buffer in system memory and set
up deferred I/O for mmap.

The fbdev code that operated directly on GEM buffers was used by
drivers based on GEM DMA helpers. Those drivers have been migrated
to use fbdev-dma, a dedicated fbdev emulation for DMA memory. All
remaining users of fbdev-generic require shadow buffering.

Memory management of the remaining callers uses TTM, GEM SHMEM
helpers or a variant of GEM DMA helpers that is incompatible with
fbdev-dma. Therefore remove the unused codepaths from fbdev-generic
and simplify the code.

Using a shadow buffer with deferred I/O is probably the best case
for most remaining callers. Some of the TTM-based drivers might
benefit from a dedicated fbdev emulation that operates directly on
the driver's video memory.


I don't understand here,  the TTM-based drivers should have equivalent 
performance


with you implement. Because device memory typically very slow for cpu 
read, at least


this is true for Mips and loongarch architecture.  TTM-based drivers for 
those platform


is also prefer to render to system ram first(for fast reading and 
compositing) and then


blit to the real framebuffer pinned to VRAM.


Right. But in practice, writing the console directly to the video ram is 
perceived as faster. The shadow buffer needs an additional memcpy to the 
video ram. That adds latency to the output. It's more a slowness in 
perception than in actual I/O access.


The drawing helpers for system memory have also been slow compared to 
the helper for I/O memory. I've fixed some of it, but I'm not sure if I 
covered all cases. See [1] for the patches.


[1] https://patchwork.freedesktop.org/series/100317/

And finally, with the fbdev buffer in video memory, drivers could 
utilize hardware blitting to further speed up drawing. Although not many 
drivers ever did this.





In turn, I think shmem helper based drivers might benefit from a 
dedicated fbdev emulation.


Because you are blit to the shadow of the video memory for shmem helper 
based driver. The


driver may need another blit to the ultimate framebuffer.  Using a 


Indeed. SHMEM has two memcpy operations. If we could remove the fbdev 
shadow buffer and operate on the SHMEM buffer directly, we'd reduce 
overhead.


It would also mean that we'd mmap the SHMEM pages to fbdev's userspace. 
I've not yet managed to implement this successfully, as it would require 
new mmap code in the GEM SHMEM object for this purpose. And so far, I've 
always ran into a bug where the fbdev emulation would end up in a 
corrupt state.


I've spend time on 'fbdev-shmem' emulation, but given the problems, it 
hasn't paid off so far.


Best regards
Thomas


shadow buffer is still acceptable

though, but why  do you say "the TTM-based drivers might benefit from a 
dedicated fbdev emulation" ?




Signed-off-by: Thomas Zimmermann 
Reviewed-by: Javier Martinez Canillas 
Acked-by: Zack Rusin 
---
  drivers/gpu/drm/drm_fbdev_generic.c | 184 +---
  1 file changed, 30 insertions(+), 154 deletions(-)

diff --git a/drivers/gpu/drm/drm_fbdev_generic.c 
b/drivers/gpu/drm/drm_fbdev_generic.c

index 4d6325e91565..e48a8e82378d 100644
--- a/drivers/gpu/drm/drm_fbdev_generic.c
+++ b/drivers/gpu/drm/drm_fbdev_generic.c
@@ -11,16 +11,6 @@
  #include 
-static bool drm_fbdev_use_shadow_fb(struct drm_fb_helper *fb_helper)
-{
-    struct drm_device *dev = fb_helper->dev;
-    struct drm_framebuffer *fb = fb_helper->fb;
-
-    return dev->mode_config.prefer_shadow_fbdev ||
-   dev->mode_config.prefer_shadow ||
-   fb->funcs->dirty;
-}
-
  /* @user: 1=userspace, 0=fbcon */
  static int drm_fbdev_fb_open(struct fb_info *info, int user)
  {
@@ -46,115 +36,33 @@ static int drm_fbdev_fb_release(struct fb_info 
*info, int user)

  static void drm_fbdev_fb_destroy(struct fb_info *info)
  {
  struct drm_fb_helper *fb_helper = info->par;
-    void *shadow = NULL;
+    void *shadow = info->screen_buffer;
  if (!fb_helper->dev)
  return;
-    if (info->fbdefio)
-    fb_deferred_io_cleanup(info);
-    if (drm_fbdev_use_shadow_fb(fb_helper))
-    shadow = info->screen_buffer;
-
+    fb_deferred_io_cleanup(info);
  drm_fb_helper_fini(fb_helper);
-
-    if (shadow)
-    vfree(shadow);
-    else if (fb_helper->buffer)
-    drm_client_buffer_vunmap(fb_helper->buffer);
-
+    vfree(shadow);
  drm_client_framebuffer_delete(fb_helper->buffer);
-    drm_client_release(_helper->client);
+    drm_client_release(_helper->client);
  drm_fb_helper_unprepare(fb_helper);
  kfree(fb_helper);
  }
-static int drm_fbdev_fb_mmap(struct fb_info *info, struct 
vm_area_struct *vma)

-{
-    struct drm_fb_helper *fb_helper = info->par;
-
-    if (drm_fbdev_use_shadow_fb(fb_helper))
-   

Re: [PATCH v4 2/8] kunit: drm/tests: move generic helpers

[Stephen Boyd]

Quoting Matti Vaittinen (2023-03-20 22:45:52)
> Morning Stephen,
> 
> On 3/20/23 21:23, Stephen Boyd wrote:
> > Quoting Matti Vaittinen (2023-03-18 23:36:20)
> >>>
> >>> I think you would have an easier time if you just copied and renamed
> >>> them into the kunit folder as an preparation series.
> >>
> >> Yes. That would simplify the syncing between the trees. It slightly bugs
> >> me to add dublicate code in kernel-but the clean-up series for DRM users
> >> could be prepared at the same time. It would be even possible to just
> >> change the drm-helper to be a wrapper for the generic one - and leave
> >> the callers intact - although it leaves some seemingly unnecessary
> >> "onion code" there.
> >>
> >>> That way, you wouldn't have to coordinate DRM, CCF and IIO, you'd just
> >>> create new helpers that can be reused/converted to by everyone eventually
> >>
> >> Yes. Thanks - I think I may go with this approach for the v5 :)
> > 
> > Which kunit directory?
> 
> I was thinking of adding the platform_device.h (I liked your suggestion) 
> in the include/kunit/

Ok, thanks for clarifying.

> 
> > I imagine if there are conflicts they will be
> > trivial so it probably doesn't matter.
> 
> Probably so. Still, I am not the one who needs to deal with the 
> conflicts. Hence I like at least asking if people see good way to avoid 
> them in the first place.

Same for me. I'm not the maintainer of the drivers/base directory.

> 
> Besides, I was not sure if you were planning to add similar helper or 
> just wrappers to individual functions. Wanted to ping you just in case 
> this has some impact to what you do.

I don't have a need to bind a device to a driver to satisfy devm APIs
currently. I could probably use it though to test some devm code in the
clk APIs. The only impact is that we're modifying the same files.

> 
> > Have you Cced kunit folks and the
> > list on the kunit patches? They may have some opinion.
> 
> This patch was should have contained the 
> include/kunit/platform_device.h. That file was pulling the Kunit people 
> in recipients but I messed up things with last minute changes so both 
> the header and people were dropped. I'll fix this for v5.
> 

Ok, I'll be on the lookout for v5. From what I can tell kunit goes
through the kernel selftest tree and there isn't a kunit git tree as
such.

Re: [RFC PATCH 1/5] x86/xen: disable swiotlb for xen pvh

[Christian König]

Am 17.03.23 um 15:45 schrieb Alex Deucher:

On Thu, Mar 16, 2023 at 7:09 PM Stefano Stabellini
 wrote:

On Thu, 16 Mar 2023, Juergen Gross wrote:

On 16.03.23 14:53, Alex Deucher wrote:

On Thu, Mar 16, 2023 at 9:48 AM Juergen Gross  wrote:

On 16.03.23 14:45, Alex Deucher wrote:

On Thu, Mar 16, 2023 at 3:50 AM Jan Beulich  wrote:

On 16.03.2023 00:25, Stefano Stabellini wrote:

On Wed, 15 Mar 2023, Jan Beulich wrote:

On 15.03.2023 01:52, Stefano Stabellini wrote:

On Mon, 13 Mar 2023, Jan Beulich wrote:

On 12.03.2023 13:01, Huang Rui wrote:

Xen PVH is the paravirtualized mode and takes advantage of
hardware
virtualization support when possible. It will using the
hardware IOMMU
support instead of xen-swiotlb, so disable swiotlb if
current domain is
Xen PVH.

But the kernel has no way (yet) to drive the IOMMU, so how can
it get
away without resorting to swiotlb in certain cases (like I/O
to an
address-restricted device)?

I think Ray meant that, thanks to the IOMMU setup by Xen, there
is no
need for swiotlb-xen in Dom0. Address translations are done by
the IOMMU
so we can use guest physical addresses instead of machine
addresses for
DMA. This is a similar case to Dom0 on ARM when the IOMMU is
available
(see include/xen/arm/swiotlb-xen.h:xen_swiotlb_detect, the
corresponding
case is XENFEAT_not_direct_mapped).

But how does Xen using an IOMMU help with, as said,
address-restricted
devices? They may still need e.g. a 32-bit address to be
programmed in,
and if the kernel has memory beyond the 4G boundary not all I/O
buffers
may fulfill this requirement.

In short, it is going to work as long as Linux has guest physical
addresses (not machine addresses, those could be anything) lower
than
4GB.

If the address-restricted device does DMA via an IOMMU, then the
device
gets programmed by Linux using its guest physical addresses (not
machine
addresses).

The 32-bit restriction would be applied by Linux to its choice of
guest
physical address to use to program the device, the same way it does
on
native. The device would be fine as it always uses Linux-provided
<4GB
addresses. After the IOMMU translation (pagetable setup by Xen), we
could get any address, including >4GB addresses, and that is
expected to
work.

I understand that's the "normal" way of working. But whatever the
swiotlb
is used for in baremetal Linux, that would similarly require its use
in
PVH (or HVM) aiui. So unconditionally disabling it in PVH would look
to
me like an incomplete attempt to disable its use altogether on x86.
What
difference of PVH vs baremetal am I missing here?

swiotlb is not usable for GPUs even on bare metal.  They often have
hundreds or megs or even gigs of memory mapped on the device at any
given time.  Also, AMD GPUs support 44-48 bit DMA masks (depending on
the chip family).

But the swiotlb isn't per device, but system global.

Sure, but if the swiotlb is in use, then you can't really use the GPU.
So you get to pick one.

The swiotlb is used only for buffers which are not within the DMA mask of a
device (see dma_direct_map_page()). So an AMD GPU supporting a 44 bit DMA mask
won't use the swiotlb unless you have a buffer above guest physical address of
16TB (so basically never).

Disabling swiotlb in such a guest would OTOH mean, that a device with only
32 bit DMA mask passed through to this guest couldn't work with buffers
above 4GB.

I don't think this is acceptable.

 From the Xen subsystem in Linux point of view, the only thing we need to
do is to make sure *not* to enable swiotlb_xen (yes "swiotlb_xen", not
the global swiotlb) on PVH because it is not needed anyway.

I think we should leave the global "swiotlb" setting alone. The global
swiotlb is not relevant to Xen anyway, and surely baremetal Linux has to
have a way to deal with swiotlb/GPU incompatibilities.

We just have to avoid making things worse on Xen, and for that we just
need to avoid unconditionally enabling swiotlb-xen. If the Xen subsystem
doesn't enable swiotlb_xen/swiotlb, and no other subsystem enables
swiotlb, then we have a good Linux configuration capable of handling the
GPU properly.

Alex, please correct me if I am wrong. How is x86_swiotlb_enable set to
false on native (non-Xen) x86?

In most cases we have an IOMMU enabled and IIRC, TTM has slightly
different behavior for memory allocation depending on whether swiotlb
would be needed or not.


Well "slightly different" is an understatement. We need to disable quite 
a bunch of features to make swiotlb work with GPUs.


Especially userptr and inter device sharing won't work any more.

Regards,
Christian.



Alex

Re: BUG: KASAN: slab-use-after-free in drm_sched_get_cleanup_job+0x47b/0x5c0 [gpu_sched]

[Christian König]

Hi Mikhail,

Am 20.03.23 um 13:05 schrieb Mikhail Gavrilov:

Hi,
after enabling KASAN literally I was bombarded with messages about
slab-use-after-free in drm_sched_get_cleanup_job.


mhm, interesting.


All messages has similar backtrace:
[ 1138.492091] 
==
[ 1138.492104] BUG: KASAN: slab-use-after-free in
drm_sched_get_cleanup_job+0x47b/0x5c0 [gpu_sched]
[ 1138.492120] Read of size 8 at addr 88815adf04c0 by task sdma1/749

[ 1138.492130] CPU: 29 PID: 749 Comm: sdma1 Tainted: GWL
  ---  ---  6.3.0-0.rc2.20230317git38e04b3e4240.27.fc39.x86_64+debug
#1
[ 1138.492136] Hardware name: System manufacturer System Product
Name/ROG STRIX X570-I GAMING, BIOS 4601 02/02/2023
[ 1138.492141] Call Trace:
[ 1138.492145]  
[ 1138.492150]  dump_stack_lvl+0x72/0xc0
[ 1138.492159]  print_report+0xcf/0x670
[ 1138.492169]  ? drm_sched_get_cleanup_job+0x47b/0x5c0 [gpu_sched]
[ 1138.492181]  ? drm_sched_get_cleanup_job+0x47b/0x5c0 [gpu_sched]
[ 1138.492193]  kasan_report+0xa4/0xe0
[ 1138.492200]  ? drm_sched_get_cleanup_job+0x47b/0x5c0 [gpu_sched]
[ 1138.492215]  drm_sched_get_cleanup_job+0x47b/0x5c0 [gpu_sched]
[ 1138.492229]  drm_sched_main+0x643/0x990 [gpu_sched]
[ 1138.492245]  ? __pfx_drm_sched_main+0x10/0x10 [gpu_sched]
[ 1138.492259]  ? __pfx_autoremove_wake_function+0x10/0x10
[ 1138.492269]  ? __kthread_parkme+0xc1/0x1f0
[ 1138.492277]  ? __pfx_drm_sched_main+0x10/0x10 [gpu_sched]
[ 1138.492288]  kthread+0x29e/0x340
[ 1138.492294]  ? __pfx_kthread+0x10/0x10
[ 1138.492301]  ret_from_fork+0x2c/0x50
[ 1138.492314]  

[ 1138.492320] Allocated by task 10867:
[ 1138.492323]  kasan_save_stack+0x2f/0x50
[ 1138.492329]  kasan_set_track+0x21/0x30
[ 1138.492334]  __kasan_kmalloc+0x8b/0x90
[ 1138.492339]  amdgpu_driver_open_kms+0x10b/0x5a0 [amdgpu]
[ 1138.493112]  drm_file_alloc+0x46e/0x880
[ 1138.493120]  drm_open_helper+0x161/0x460
[ 1138.493126]  drm_open+0x1e7/0x5c0
[ 1138.493131]  drm_stub_open+0x24d/0x400
[ 1138.493138]  chrdev_open+0x215/0x620
[ 1138.493144]  do_dentry_open+0x5f1/0x1000
[ 1138.493149]  path_openat+0x1b3d/0x28a0
[ 1138.493156]  do_filp_open+0x1bd/0x400
[ 1138.493161]  do_sys_openat2+0x140/0x420
[ 1138.493167]  __x64_sys_openat+0x11f/0x1d0
[ 1138.493173]  do_syscall_64+0x5b/0x80
[ 1138.493179]  entry_SYSCALL_64_after_hwframe+0x72/0xdc

[ 1138.493189] Freed by task 10867:
[ 1138.493193]  kasan_save_stack+0x2f/0x50
[ 1138.493199]  kasan_set_track+0x21/0x30
[ 1138.493205]  kasan_save_free_info+0x2a/0x50
[ 1138.493210]  __kasan_slab_free+0x107/0x1a0
[ 1138.493216]  slab_free_freelist_hook+0x11e/0x1d0
[ 1138.493221]  __kmem_cache_free+0xbc/0x2e0
[ 1138.493227]  amdgpu_driver_postclose_kms+0x582/0x8d0 [amdgpu]
[ 1138.493963]  drm_file_free.part.0+0x638/0xb70
[ 1138.493969]  drm_release+0x1ea/0x470
[ 1138.493975]  __fput+0x213/0x9e0
[ 1138.493981]  task_work_run+0x11b/0x200
[ 1138.493987]  exit_to_user_mode_prepare+0x23a/0x260
[ 1138.493994]  syscall_exit_to_user_mode+0x16/0x50
[ 1138.494001]  do_syscall_64+0x67/0x80
[ 1138.494006]  entry_SYSCALL_64_after_hwframe+0x72/0xdc

[ 1138.494015] The buggy address belongs to the object at 88815adf
 which belongs to the cache kmalloc-4k of size 4096
[ 1138.494021] The buggy address is located 1216 bytes inside of
 freed 4096-byte region [88815adf, 88815adf1000)

[ 1138.494030] The buggy address belongs to the physical page:
[ 1138.494034] page:17cd5a82 refcount:1 mapcount:0
mapping: index:0x0 pfn:0x15adf0
[ 1138.494041] head:17cd5a82 order:3 entire_mapcount:0
nr_pages_mapped:0 pincount:0
[ 1138.494046] flags:
0x17c0010200(slab|head|node=0|zone=2|lastcpupid=0x1f)
[ 1138.494055] raw: 0017c0010200 88810004d040 dead0122

[ 1138.494061] raw:  00040004 0001

[ 1138.494065] page dumped because: kasan: bad access detected

[ 1138.494071] Memory state around the buggy address:
[ 1138.494076]  88815adf0380: fb fb fb fb fb fb fb fb fb fb fb fb
fb fb fb fb
[ 1138.494080]  88815adf0400: fb fb fb fb fb fb fb fb fb fb fb fb
fb fb fb fb
[ 1138.494084] >88815adf0480: fb fb fb fb fb fb fb fb fb fb fb fb
fb fb fb fb
[ 1138.494088]^
[ 1138.494092]  88815adf0500: fb fb fb fb fb fb fb fb fb fb fb fb
fb fb fb fb
[ 1138.494095]  88815adf0580: fb fb fb fb fb fb fb fb fb fb fb fb
fb fb fb fb
[ 1138.494099] 
==
[ 1138.494140] Disabling lock debugging due to kernel taint

First thing I checked RAM for sure that it is definitely not a
hardware problem. I started investigating which application triggered
this message. I started to notice that it usually happens when any
game starts in the steam client. So I came to the culprit of the
problem is the compilation of shaders. For reproduction we should have
a kernel with 

[PATCH] drm/vmwgfx: remove unused vmw_overlay function

[Tom Rix]

clang with W=1 reports
drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c:56:35: error:
  unused function 'vmw_overlay' [-Werror,-Wunused-function]
static inline struct vmw_overlay *vmw_overlay(struct drm_device *dev)
  ^
This function is not used, so remove it.

Signed-off-by: Tom Rix 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c
index 8d171d71cb8a..7e112319a23c 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c
@@ -53,12 +53,6 @@ struct vmw_overlay {
struct vmw_stream stream[VMW_MAX_NUM_STREAMS];
 };
 
-static inline struct vmw_overlay *vmw_overlay(struct drm_device *dev)
-{
-   struct vmw_private *dev_priv = vmw_priv(dev);
-   return dev_priv ? dev_priv->overlay_priv : NULL;
-}
-
 struct vmw_escape_header {
uint32_t cmd;
SVGAFifoCmdEscape body;
-- 
2.27.0

[PATCH] drm/amd/display: Slightly optimize dm_dmub_outbox1_low_irq()

[Christophe JAILLET]

A kzalloc()+memcpy() can be optimized in a single kmemdup().
This saves a few cycles because some memory doesn't need to be zeroed.

Signed-off-by: Christophe JAILLET 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 5bac5781a06b..57a5fbdab890 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -820,15 +820,14 @@ static void dm_dmub_outbox1_low_irq(void 
*interrupt_params)
DRM_ERROR("Failed to allocate 
dmub_hpd_wrk");
return;
}
-   dmub_hpd_wrk->dmub_notify = 
kzalloc(sizeof(struct dmub_notification), GFP_ATOMIC);
+   dmub_hpd_wrk->dmub_notify = kmemdup(, 
sizeof(struct dmub_notification),
+   GFP_ATOMIC);
if (!dmub_hpd_wrk->dmub_notify) {
kfree(dmub_hpd_wrk);
DRM_ERROR("Failed to allocate 
dmub_hpd_wrk->dmub_notify");
return;
}
INIT_WORK(_hpd_wrk->handle_hpd_work, 
dm_handle_hpd_work);
-   if (dmub_hpd_wrk->dmub_notify)
-   memcpy(dmub_hpd_wrk->dmub_notify, 
, sizeof(struct dmub_notification));
dmub_hpd_wrk->adev = adev;
if (notify.type == DMUB_NOTIFICATION_HPD) {
plink = 
adev->dm.dc->links[notify.link_index];
-- 
2.32.0

Re: [PATCH v2 2/2] drm/i915: Check for unreliable MMIO during forcewake

[Andi Shyti]

> Although we now sanitycheck MMIO access during driver load to make sure
> the MMIO BAR isn't returning all 0x, there have been a few cases
> where (temporarily?) unreliable MMIO access has happened after GPU
> resets or power events.  We'll often notice this on our next GT register
> access since forcewake handling will fail; let's change our handling
> slightly so that when this happens we print a more meaningful message
> clarifying that the problem is the MMIO access, not forcewake
> specifically.
> 
> Signed-off-by: Matt Roper 
> Cc: Mika Kuoppala 
> Signed-off-by: Andi Shyti 

Reviewed-by: Andi Shyti 

Andi

Re: [PATCH v2 1/2] drm/i915: Sanitycheck MMIO access early in driver load

[Andi Shyti]

> We occasionally see the PCI device in a non-accessible state at the
> point the driver is loaded.  When this happens, all BAR accesses will
> read back as 0x.  Rather than reading registers and
> misinterpreting their (invalid) values, let's specifically check for
> 0x in a register that cannot have that value to see if the
> device is accessible.
> 
> Signed-off-by: Matt Roper 
> Cc: Mika Kuoppala 
> Signed-off-by: Andi Shyti 

Reviewed-by: Andi Shyti 

Andi

[PATCH v2 2/2] drm/i915: Check for unreliable MMIO during forcewake

[Andi Shyti]

From: Matt Roper 

Although we now sanitycheck MMIO access during driver load to make sure
the MMIO BAR isn't returning all 0x, there have been a few cases
where (temporarily?) unreliable MMIO access has happened after GPU
resets or power events.  We'll often notice this on our next GT register
access since forcewake handling will fail; let's change our handling
slightly so that when this happens we print a more meaningful message
clarifying that the problem is the MMIO access, not forcewake
specifically.

Signed-off-by: Matt Roper 
Cc: Mika Kuoppala 
Signed-off-by: Andi Shyti 
---
 drivers/gpu/drm/i915/intel_uncore.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index 0b69081d6d285..303a5d38c93a5 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -178,9 +178,15 @@ static inline void
 fw_domain_wait_ack_clear(const struct intel_uncore_forcewake_domain *d)
 {
if (wait_ack_clear(d, FORCEWAKE_KERNEL)) {
-   drm_err(>uncore->i915->drm,
-   "%s: timed out waiting for forcewake ack to clear.\n",
-   intel_uncore_forcewake_domain_to_str(d->id));
+   if (fw_ack(d) == ~0)
+   drm_err(>uncore->i915->drm,
+   "%s: MMIO unreliable (forcewake register 
returns 0x)!\n",
+   intel_uncore_forcewake_domain_to_str(d->id));
+   else
+   drm_err(>uncore->i915->drm,
+   "%s: timed out waiting for forcewake ack to 
clear.\n",
+   intel_uncore_forcewake_domain_to_str(d->id));
+
add_taint_for_CI(d->uncore->i915, TAINT_WARN); /* CI now 
unreliable */
}
 }
-- 
2.39.2

[PATCH v2 1/2] drm/i915: Sanitycheck MMIO access early in driver load

[Andi Shyti]

From: Matt Roper 

We occasionally see the PCI device in a non-accessible state at the
point the driver is loaded.  When this happens, all BAR accesses will
read back as 0x.  Rather than reading registers and
misinterpreting their (invalid) values, let's specifically check for
0x in a register that cannot have that value to see if the
device is accessible.

Signed-off-by: Matt Roper 
Cc: Mika Kuoppala 
Signed-off-by: Andi Shyti 
---
 drivers/gpu/drm/i915/intel_uncore.c | 35 +
 1 file changed, 35 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index e1e1f34490c8e..0b69081d6d285 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -2602,11 +2602,46 @@ static int uncore_forcewake_init(struct intel_uncore 
*uncore)
return 0;
 }
 
+static int sanity_check_mmio_access(struct intel_uncore *uncore)
+{
+   struct drm_i915_private *i915 = uncore->i915;
+   int ret;
+
+   if (GRAPHICS_VER(i915) < 8)
+   return 0;
+
+   /*
+* Sanitycheck that MMIO access to the device is working properly.  If
+* the CPU is unable to communcate with a PCI device, BAR reads will
+* return 0x.  Let's make sure the device isn't in this state
+* before we start trying to access registers.
+*
+* We use the primary GT's forcewake register as our guinea pig since
+* it's been around since HSW and it's a masked register so the upper
+* 16 bits can never read back as 1's if device access is operating
+* properly.
+*
+* If MMIO isn't working, we'll wait up to 2 seconds to see if it
+* recovers, then give up.
+*/
+   ret = intel_wait_for_register_fw(uncore, FORCEWAKE_MT, 0, 0, 200);
+   if (ret == -ETIMEDOUT) {
+   drm_err(>drm, "Device is non-operational; MMIO access 
returns 0x!\n");
+   return -EIO;
+   }
+
+   return 0;
+}
+
 int intel_uncore_init_mmio(struct intel_uncore *uncore)
 {
struct drm_i915_private *i915 = uncore->i915;
int ret;
 
+   ret = sanity_check_mmio_access(uncore);
+   if (ret)
+   return ret;
+
/*
 * The boot firmware initializes local memory and assesses its health.
 * If memory training fails, the punit will have been instructed to
-- 
2.39.2

[PATCH v2 0/2] Report MMIO communication problems more clearly

[Andi Shyti]

Hi,

just copy pasting Matt's original cover letter:

We're periodically facing problems in CI where all registers read back
as 0x.  In general this is what happens when the CPU is unable
to communicate with a PCI device, so the transaction autocompletes with
all F's as a placeholder.  Sometimes the device will recover on its own,
sometimes it will never come back.

We already have some attempts to detect when this happens (e.g., when
checking FPGA_DBG), but let's add a couple more checks with descriptive
error messages to identify the problem in other cases:

 - When the device is first probed, we'll do an initial check of the GT
   forcewake register.  As a masked register, the upper bits should
   always come back as 0's if device access is behaving properly, so if
   we see all F's, we can conclude that the device is already in a bad
   state.  We'll wait two seconds to see if it recovers on its own, then
   give up on the device.

 - When we encounter a 'forcewake timed out while waiting for clear'
   error, we'll do one more read of the register to see if it's because
   we're just reading back all F's.  If so, we'll print a more
   meaningful message clarifying that it isn't the forcewake itself
   that's the problem, but rather communication with the device.

Note that this only captures the failure case where accessing the device
is problematic (resulting in registers giving all F's).  There's a
separate class of problems where the device is okay, but the GT inside
the device is busted and all GT registers read back as 0's (other
registers like sgunit registers are usually still readable).  This
series does not address that class of errors.

This is just a quick change to get some better CI error messages.  Some
ideas for future enhancements:

 - Try something to reset the device if we detect a problem at driver
   load (e.g., PCI FLR, toggling the PCI power state, etc.)?

 - Use something more standard like pci_read_config_dword() instead of a
   device register read to determine when we're not communicating
   properly?  Generally the PCI config space is also giving all F's at
   this point.

 - Also handle the "device OK, GT dead" case by finding some GT
   register(s) that should never be 0 on a functioning system.  Maybe
   one of the fuse registers would work for this?

Changelog
=
v1 -> v2
 - The sanity check can use intel_wait_for_register_fw().
   (Thanks, Jani)

Matt Roper (2):
  drm/i915: Sanitycheck MMIO access early in driver load
  drm/i915: Check for unreliable MMIO during forcewake

 drivers/gpu/drm/i915/intel_uncore.c | 47 +++--
 1 file changed, 44 insertions(+), 3 deletions(-)

-- 
2.39.2

[syzbot] [dri?] BUG: sleeping function called from invalid context in _vm_unmap_aliases

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:f3594f0204b7 Add linux-next specific files for 20230321
git tree:   linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=161552eec8
kernel config:  https://syzkaller.appspot.com/x/.config?x=f22105589e896af1
dashboard link: https://syzkaller.appspot.com/bug?extid=a9a2bb6afe9eb31efc56
compiler:   gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for 
Debian) 2.35.2

Unfortunately, I don't have any reproducer for this issue yet.

Downloadable assets:
disk image: 
https://storage.googleapis.com/syzbot-assets/0b755145006a/disk-f3594f02.raw.xz
vmlinux: 
https://storage.googleapis.com/syzbot-assets/fca26e328a81/vmlinux-f3594f02.xz
kernel image: 
https://storage.googleapis.com/syzbot-assets/39744d7d289f/bzImage-f3594f02.xz

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+a9a2bb6afe9eb31ef...@syzkaller.appspotmail.com

BUG: sleeping function called from invalid context at kernel/locking/mutex.c:580
in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 10028, name: 
syz-executor.4
preempt_count: 0, expected: 0
RCU nest depth: 1, expected: 0
3 locks held by syz-executor.4/10028:
 #0: 88807597afd8 (>mmap_lock){}-{3:3}, at: 
mmap_write_lock_killable include/linux/mmap_lock.h:110 [inline]
 #0: 88807597afd8 (>mmap_lock){}-{3:3}, at: 
vm_mmap_pgoff+0x158/0x3b0 mm/util.c:541
 #1: 888081123270 (>pages_lock){+.+.}-{3:3}, at: 
drm_gem_shmem_get_pages+0x53/0x180 drivers/gpu/drm/drm_gem_shmem_helper.c:216
 #2: 8c796500 (rcu_read_lock){}-{1:2}, at: 
_vm_unmap_aliases.part.0+0x138/0x560 mm/vmalloc.c:2182
CPU: 1 PID: 10028 Comm: syz-executor.4 Not tainted 
6.3.0-rc3-next-20230321-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 
03/02/2023
Call Trace:
 
 __dump_stack lib/dump_stack.c:88 [inline]
 dump_stack_lvl+0x136/0x150 lib/dump_stack.c:106
 __might_resched+0x358/0x580 kernel/sched/core.c:10059
 __mutex_lock_common kernel/locking/mutex.c:580 [inline]
 __mutex_lock+0x9f/0x1350 kernel/locking/mutex.c:747
 _vm_unmap_aliases.part.0+0x1ca/0x560 mm/vmalloc.c:2187
 _vm_unmap_aliases mm/vmalloc.c:2181 [inline]
 vm_unmap_aliases+0x49/0x50 mm/vmalloc.c:2230
 change_page_attr_set_clr+0x226/0x470 arch/x86/mm/pat/set_memory.c:1837
 cpa_set_pages_array arch/x86/mm/pat/set_memory.c:1892 [inline]
 _set_pages_array+0x1c6/0x220 arch/x86/mm/pat/set_memory.c:2230
 drm_gem_shmem_get_pages_locked+0x155/0x240 
drivers/gpu/drm/drm_gem_shmem_helper.c:191
 drm_gem_shmem_get_pages+0x71/0x180 drivers/gpu/drm/drm_gem_shmem_helper.c:219
 drm_gem_shmem_mmap drivers/gpu/drm/drm_gem_shmem_helper.c:636 [inline]
 drm_gem_shmem_mmap+0x153/0x540 drivers/gpu/drm/drm_gem_shmem_helper.c:620
 drm_gem_mmap_obj+0x1b6/0x6c0 drivers/gpu/drm/drm_gem.c:1046
 drm_gem_mmap+0x41d/0x780 drivers/gpu/drm/drm_gem.c:1124
 call_mmap include/linux/fs.h:1859 [inline]
 mmap_region+0x694/0x28d0 mm/mmap.c:2652
 do_mmap+0x831/0xf60 mm/mmap.c:1438
 vm_mmap_pgoff+0x1a2/0x3b0 mm/util.c:543
 ksys_mmap_pgoff+0x41f/0x5a0 mm/mmap.c:1484
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7f905968c0f9
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 19 00 00 90 48 89 f8 48 89 f7 48 
89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 
c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:7f905a3fa168 EFLAGS: 0246 ORIG_RAX: 0009
RAX: ffda RBX: 7f90597abf80 RCX: 7f905968c0f9
RDX:  RSI: 3028 RDI: 20ffc000
RBP: 7f90596e7b39 R08: 0004 R09: 0001
R10: 0012 R11: 0246 R12: 
R13: 7ffcde03503f R14: 7f905a3fa300 R15: 00022000
 

=
[ BUG: Invalid wait context ]
6.3.0-rc3-next-20230321-syzkaller #0 Tainted: GW 
-
syz-executor.4/10028 is trying to lock:
888027c7a068 (>lock){+.+.}-{3:3}, at: 
_vm_unmap_aliases.part.0+0x1ca/0x560 mm/vmalloc.c:2187
other info that might help us debug this:
context-{4:4}
3 locks held by syz-executor.4/10028:
 #0: 88807597afd8 (>mmap_lock){}-{3:3}, at: 
mmap_write_lock_killable include/linux/mmap_lock.h:110 [inline]
 #0: 88807597afd8 (>mmap_lock){}-{3:3}, at: 
vm_mmap_pgoff+0x158/0x3b0 mm/util.c:541
 #1: 888081123270 (>pages_lock){+.+.}-{3:3}, at: 
drm_gem_shmem_get_pages+0x53/0x180 drivers/gpu/drm/drm_gem_shmem_helper.c:216
 #2: 8c796500 (rcu_read_lock){}-{1:2}, at: 
_vm_unmap_aliases.part.0+0x138/0x560 mm/vmalloc.c:2182
stack backtrace:
CPU: 1 PID: 10028 Comm: syz-executor.4 Tainted: GW      
6.3.0-rc3-next-20230321-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 
03/02/2023
Call

[syzbot] [fbdev?] KASAN: use-after-free Write in fbcon_get_font

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:fe15c26ee26e Linux 6.3-rc1
git tree:   git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git 
for-kernelci
console output: https://syzkaller.appspot.com/x/log.txt?x=11bc9c16c8
kernel config:  https://syzkaller.appspot.com/x/.config?x=7573cbcd881a88c9
dashboard link: https://syzkaller.appspot.com/bug?extid=5a04eb16db96950bb112
compiler:   Debian clang version 15.0.7, GNU ld (GNU Binutils for Debian) 
2.35.2
userspace arch: arm64
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=135becbac8
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=1182c9d2c8

Downloadable assets:
disk image: 
https://storage.googleapis.com/syzbot-assets/89d41abd07bd/disk-fe15c26e.raw.xz
vmlinux: 
https://storage.googleapis.com/syzbot-assets/fa75f5030ade/vmlinux-fe15c26e.xz
kernel image: 
https://storage.googleapis.com/syzbot-assets/590d0f5903ee/Image-fe15c26e.gz.xz

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+5a04eb16db96950bb...@syzkaller.appspotmail.com

==
BUG: KASAN: use-after-free in fbcon_get_font+0x240/0x8cc 
drivers/video/fbdev/core/fbcon.c:2290
Write of size 22062 at addr e1bfabd6 by task syz-executor329/5944

CPU: 0 PID: 5944 Comm: syz-executor329 Not tainted 
6.3.0-rc1-syzkaller-gfe15c26ee26e #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 
03/02/2023
Call trace:
 dump_backtrace+0x1c8/0x1f4 arch/arm64/kernel/stacktrace.c:158
 show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:165
 __dump_stack lib/dump_stack.c:88 [inline]
 dump_stack_lvl+0xd0/0x124 lib/dump_stack.c:106
 print_address_description mm/kasan/report.c:319 [inline]
 print_report+0x174/0x514 mm/kasan/report.c:430
 kasan_report+0xd4/0x130 mm/kasan/report.c:536
 kasan_check_range+0x264/0x2a4 mm/kasan/generic.c:187
 __asan_memset+0x40/0x70 mm/kasan/shadow.c:84
 fbcon_get_font+0x240/0x8cc drivers/video/fbdev/core/fbcon.c:2290
 con_font_get drivers/tty/vt/vt.c:4559 [inline]
 con_font_op+0x468/0xfa0 drivers/tty/vt/vt.c:4674
 vt_k_ioctl drivers/tty/vt/vt_ioctl.c:474 [inline]
 vt_ioctl+0x1a90/0x252c drivers/tty/vt/vt_ioctl.c:752
 tty_ioctl+0x8a4/0xd8c drivers/tty/tty_io.c:2777
 vfs_ioctl fs/ioctl.c:51 [inline]
 __do_sys_ioctl fs/ioctl.c:870 [inline]
 __se_sys_ioctl fs/ioctl.c:856 [inline]
 __arm64_sys_ioctl+0x14c/0x1c8 fs/ioctl.c:856
 __invoke_syscall arch/arm64/kernel/syscall.c:38 [inline]
 invoke_syscall+0x98/0x2c0 arch/arm64/kernel/syscall.c:52
 el0_svc_common+0x138/0x258 arch/arm64/kernel/syscall.c:142
 do_el0_svc+0x64/0x198 arch/arm64/kernel/syscall.c:193
 el0_svc+0x58/0x168 arch/arm64/kernel/entry-common.c:637
 el0t_64_sync_handler+0x84/0xf0 arch/arm64/kernel/entry-common.c:655
 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:591

The buggy address belongs to the physical page:
page:c3c989b0 refcount:1 mapcount:0 mapping: index:0x0 
pfn:0x121800
head:c3c989b0 order:10 entire_mapcount:0 nr_pages_mapped:0 pincount:0
flags: 0x5ffc001(head|node=0|zone=2|lastcpupid=0x7ff)
raw: 05ffc001  dead0122 
raw:   0001 
page dumped because: kasan: bad access detected

Memory state around the buggy address:
 e1bfff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 e1bfff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>e1c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
   ^
 e1c00080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 e1c00100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
==


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkal...@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
syzbot can test patches for this issue, for details see:
https://goo.gl/tpsmEJ#testing-patches

Re: [PATCH] drm/sun4i: uncouple DSI dotclock divider from TCON0_DCLK_REG

[Roman Beranek]

Hello Maxime,

On Tue Mar 21, 2023 at 3:56 PM CET, Maxime Ripard wrote:
>
> This is similar to
> https://lore.kernel.org/all/20230319160704.9858-2-fr...@oltmanns.dev/
>
> What's the story there?

Yes, Frank Oltmanns wrote me recently in relation to a patch I wrote
~ 3 years ago that addressed the framerate issue, proposing to
collaborate on pushing it upstream, however as I've been keeping up
with my inbox rather sporadically these days, by the time I read his
message, Frank had already taken the initiative and sent the patch.
So that's how we've got to this slightly awkward situation with two
patches on the same subject arriving 1 day apart of each other.

The problem with the original patch was that it went around
sun4i_dotclock by feeding it a rate adjusted such that the pll-mipi rate
was set correctly. I couldn't quite figure out at the time of how big
a portion of the tcon logic does the sun4i_dotclock code need to be made
aware of.

>Also, how was it tested/confirmed?

By counting Vblank interrupts (GIC 118).

Roman

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Sanitycheck MMIO access early in driver load

[Andi Shyti]

Hi Jani,

Thanks for looking into this,

[...]

> > +#define COND (__raw_uncore_read32(uncore, FORCEWAKE_MT) != ~0)
> > +   if (wait_for(COND, 2000) == -ETIMEDOUT) {
> 
> I guess this somewhat reimplements intel_wait_for_register_fw()?

Thanks!

Andi

> > +   drm_err(>drm, "Device is non-operational; MMIO access 
> > returns 0x!\n");
> > +   return -EIO;
> > +   }

Re: [v2,3/8] drm/fb-helper: Export drm_fb_helper_release_info()

[Sui jingfeng]

Tested-by: Sui Jingfeng

On 2023/3/20 23:07, Thomas Zimmermann wrote:

Export the fb_info release code as drm_fb_helper_release_info(). Will
help with cleaning up failed fbdev probing.

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Javier Martinez Canillas 
Acked-by: Zack Rusin 
---
  drivers/gpu/drm/drm_fb_helper.c | 33 -
  include/drm/drm_fb_helper.h |  5 +
  2 files changed, 29 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index a39998047f8a..7e96ed9efdb5 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -538,6 +538,29 @@ struct fb_info *drm_fb_helper_alloc_info(struct 
drm_fb_helper *fb_helper)
  }
  EXPORT_SYMBOL(drm_fb_helper_alloc_info);
  
+/**

+ * drm_fb_helper_release_info - release fb_info and its members
+ * @fb_helper: driver-allocated fbdev helper
+ *
+ * A helper to release fb_info and the member cmap.  Drivers do not
+ * need to release the allocated fb_info structure themselves, this is
+ * automatically done when calling drm_fb_helper_fini().
+ */
+void drm_fb_helper_release_info(struct drm_fb_helper *fb_helper)
+{
+   struct fb_info *info = fb_helper->info;
+
+   if (!info)
+   return;
+
+   fb_helper->info = NULL;
+
+   if (info->cmap.len)
+   fb_dealloc_cmap(>cmap);
+   framebuffer_release(info);
+}
+EXPORT_SYMBOL(drm_fb_helper_release_info);
+
  /**
   * drm_fb_helper_unregister_info - unregister fb_info framebuffer device
   * @fb_helper: driver-allocated fbdev helper, can be NULL
@@ -561,8 +584,6 @@ EXPORT_SYMBOL(drm_fb_helper_unregister_info);
   */
  void drm_fb_helper_fini(struct drm_fb_helper *fb_helper)
  {
-   struct fb_info *info;
-
if (!fb_helper)
return;
  
@@ -574,13 +595,7 @@ void drm_fb_helper_fini(struct drm_fb_helper *fb_helper)

cancel_work_sync(_helper->resume_work);
cancel_work_sync(_helper->damage_work);
  
-	info = fb_helper->info;

-   if (info) {
-   if (info->cmap.len)
-   fb_dealloc_cmap(>cmap);
-   framebuffer_release(info);
-   }
-   fb_helper->info = NULL;
+   drm_fb_helper_release_info(fb_helper);
  
  	mutex_lock(_fb_helper_lock);

if (!list_empty(_helper->kernel_fb_list)) {
diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
index 013654de3fc5..c5822ec2fdd1 100644
--- a/include/drm/drm_fb_helper.h
+++ b/include/drm/drm_fb_helper.h
@@ -256,6 +256,7 @@ int drm_fb_helper_check_var(struct fb_var_screeninfo *var,
  int drm_fb_helper_restore_fbdev_mode_unlocked(struct drm_fb_helper 
*fb_helper);
  
  struct fb_info *drm_fb_helper_alloc_info(struct drm_fb_helper *fb_helper);

+void drm_fb_helper_release_info(struct drm_fb_helper *fb_helper);
  void drm_fb_helper_unregister_info(struct drm_fb_helper *fb_helper);
  void drm_fb_helper_fill_info(struct fb_info *info,
 struct drm_fb_helper *fb_helper,
@@ -365,6 +366,10 @@ drm_fb_helper_alloc_info(struct drm_fb_helper *fb_helper)
return NULL;
  }
  
+static inline void drm_fb_helper_release_info(struct drm_fb_helper *fb_helper)

+{
+}
+
  static inline void drm_fb_helper_unregister_info(struct drm_fb_helper 
*fb_helper)
  {
  }

Re: [v2,7/8] drm/fb-helper: Consolidate CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM

[Sui jingfeng]

Tested-by: Sui Jingfeng

On 2023/3/20 23:07, Thomas Zimmermann wrote:

Consolidate all handling of CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM by
making the module parameter optional in drm_fb_helper.c.

Without the config option, modules can set smem_start in struct
fb_info for internal usage, but not export if to userspace. The
address can only be exported by enabling the option and setting
the module parameter. Also update the comment.

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Javier Martinez Canillas 
Acked-by: Zack Rusin 
---
  drivers/gpu/drm/drm_fb_helper.c | 22 --
  drivers/gpu/drm/drm_fbdev_dma.c |  9 +
  include/drm/drm_fb_helper.h |  9 -
  3 files changed, 9 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index bb0b25209b3e..63ec95e86d0e 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -60,16 +60,17 @@ MODULE_PARM_DESC(drm_fbdev_overalloc,
   * In order to keep user-space compatibility, we want in certain use-cases
   * to keep leaking the fbdev physical address to the user-space program
   * handling the fbdev buffer.
- * This is a bad habit essentially kept into closed source opengl driver
- * that should really be moved into open-source upstream projects instead
- * of using legacy physical addresses in user space to communicate with
- * other out-of-tree kernel modules.
+ *
+ * This is a bad habit, essentially kept to support closed-source OpenGL
+ * drivers that should really be moved into open-source upstream projects
+ * instead of using legacy physical addresses in user space to communicate
+ * with other out-of-tree kernel modules.
   *
   * This module_param *should* be removed as soon as possible and be
   * considered as a broken and legacy behaviour from a modern fbdev device.
   */
-#if IS_ENABLED(CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM)
  static bool drm_leak_fbdev_smem;
+#if IS_ENABLED(CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM)
  module_param_unsafe(drm_leak_fbdev_smem, bool, 0600);
  MODULE_PARM_DESC(drm_leak_fbdev_smem,
 "Allow unsafe leaking fbdev physical smem address 
[default=false]");
@@ -1983,10 +1984,6 @@ static int drm_fb_helper_single_fb_probe(struct 
drm_fb_helper *fb_helper)
return ret;
}
  
-#if IS_ENABLED(CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM)

-   fb_helper->hint_leak_smem_start = drm_leak_fbdev_smem;
-#endif
-
/* push down into drivers */
ret = (*fb_helper->funcs->fb_probe)(fb_helper, );
if (ret < 0)
@@ -2185,11 +2182,8 @@ __drm_fb_helper_initial_config_and_unlock(struct 
drm_fb_helper *fb_helper)
  
  	info = fb_helper->info;

info->var.pixclock = 0;
-   /* Shamelessly allow physical address leaking to userspace */
-#if IS_ENABLED(CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM)
-   if (!fb_helper->hint_leak_smem_start)
-#endif
-   /* don't leak any physical addresses to userspace */
+
+   if (!drm_leak_fbdev_smem)
info->flags |= FBINFO_HIDE_SMEM_START;
  
  	/* Need to drop locks to avoid recursive deadlock in

diff --git a/drivers/gpu/drm/drm_fbdev_dma.c b/drivers/gpu/drm/drm_fbdev_dma.c
index cf553ac12a0f..728deffcc0d9 100644
--- a/drivers/gpu/drm/drm_fbdev_dma.c
+++ b/drivers/gpu/drm/drm_fbdev_dma.c
@@ -136,16 +136,9 @@ static int drm_fbdev_dma_helper_fb_probe(struct 
drm_fb_helper *fb_helper,
info->flags |= FBINFO_READS_FAST; /* signal caching */
info->screen_size = sizes->surface_height * fb->pitches[0];
info->screen_buffer = map.vaddr;
+   info->fix.smem_start = page_to_phys(virt_to_page(info->screen_buffer));
info->fix.smem_len = info->screen_size;
  
-#if IS_ENABLED(CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM)

-   /*
-* Shamelessly leak the physical address to user-space.
-*/
-   if (fb_helper->hint_leak_smem_start && !info->fix.smem_start)
-   info->fix.smem_start = 
page_to_phys(virt_to_page(info->screen_buffer));
-#endif
-
return 0;
  
  err_drm_client_buffer_vunmap:

diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
index c5822ec2fdd1..72032c354a30 100644
--- a/include/drm/drm_fb_helper.h
+++ b/include/drm/drm_fb_helper.h
@@ -195,15 +195,6 @@ struct drm_fb_helper {
 */
int preferred_bpp;
  
-	/**

-* @hint_leak_smem_start:
-*
-* Hint to the fbdev emulation to store the framebuffer's physical
-* address in struct _info.fix.smem_start. If the hint is unset,
-* the smem_start field should always be cleared to zero.
-*/
-   bool hint_leak_smem_start;
-
  #ifdef CONFIG_FB_DEFERRED_IO
/**
 * @fbdefio:

Re: [v2,8/8] drm/fbdev-generic: Rename symbols

[Sui jingfeng]

I have tested this patch on my loongson mips64el machine,
not seeing any weird happens.
Tested-by: Sui Jingfeng 

On 2023/3/20 23:07, Thomas Zimmermann wrote:

Rename symbols to match the style of other fbdev-emulation source
code. No functional changes.

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Javier Martinez Canillas 
Acked-by: Zack Rusin 
---
  drivers/gpu/drm/drm_fbdev_generic.c | 66 ++---
  1 file changed, 33 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/drm_fbdev_generic.c 
b/drivers/gpu/drm/drm_fbdev_generic.c
index e7eeba0c44b4..8e5148bf40bb 100644
--- a/drivers/gpu/drm/drm_fbdev_generic.c
+++ b/drivers/gpu/drm/drm_fbdev_generic.c
@@ -13,7 +13,7 @@
  #include 
  
  /* @user: 1=userspace, 0=fbcon */

-static int drm_fbdev_fb_open(struct fb_info *info, int user)
+static int drm_fbdev_generic_fb_open(struct fb_info *info, int user)
  {
struct drm_fb_helper *fb_helper = info->par;
  
@@ -24,7 +24,7 @@ static int drm_fbdev_fb_open(struct fb_info *info, int user)

return 0;
  }
  
-static int drm_fbdev_fb_release(struct fb_info *info, int user)

+static int drm_fbdev_generic_fb_release(struct fb_info *info, int user)
  {
struct drm_fb_helper *fb_helper = info->par;
  
@@ -34,7 +34,7 @@ static int drm_fbdev_fb_release(struct fb_info *info, int user)

return 0;
  }
  
-static void drm_fbdev_fb_destroy(struct fb_info *info)

+static void drm_fbdev_generic_fb_destroy(struct fb_info *info)
  {
struct drm_fb_helper *fb_helper = info->par;
void *shadow = info->screen_buffer;
@@ -52,10 +52,10 @@ static void drm_fbdev_fb_destroy(struct fb_info *info)
kfree(fb_helper);
  }
  
-static const struct fb_ops drm_fbdev_fb_ops = {

+static const struct fb_ops drm_fbdev_generic_fb_ops = {
.owner  = THIS_MODULE,
-   .fb_open= drm_fbdev_fb_open,
-   .fb_release = drm_fbdev_fb_release,
+   .fb_open= drm_fbdev_generic_fb_open,
+   .fb_release = drm_fbdev_generic_fb_release,
.fb_read= drm_fb_helper_sys_read,
.fb_write   = drm_fb_helper_sys_write,
DRM_FB_HELPER_DEFAULT_OPS,
@@ -63,14 +63,14 @@ static const struct fb_ops drm_fbdev_fb_ops = {
.fb_copyarea= drm_fb_helper_sys_copyarea,
.fb_imageblit   = drm_fb_helper_sys_imageblit,
.fb_mmap= fb_deferred_io_mmap,
-   .fb_destroy = drm_fbdev_fb_destroy,
+   .fb_destroy = drm_fbdev_generic_fb_destroy,
  };
  
  /*

   * This function uses the client API to create a framebuffer backed by a dumb 
buffer.
   */
-static int drm_fbdev_fb_probe(struct drm_fb_helper *fb_helper,
- struct drm_fb_helper_surface_size *sizes)
+static int drm_fbdev_generic_helper_fb_probe(struct drm_fb_helper *fb_helper,
+struct drm_fb_helper_surface_size 
*sizes)
  {
struct drm_client_dev *client = _helper->client;
struct drm_device *dev = fb_helper->dev;
@@ -109,7 +109,7 @@ static int drm_fbdev_fb_probe(struct drm_fb_helper 
*fb_helper,
  
  	drm_fb_helper_fill_info(info, fb_helper, sizes);
  
-	info->fbops = _fbdev_fb_ops;

+   info->fbops = _fbdev_generic_fb_ops;
info->flags = FBINFO_DEFAULT;
  
  	/* screen */

@@ -140,9 +140,9 @@ static int drm_fbdev_fb_probe(struct drm_fb_helper 
*fb_helper,
return ret;
  }
  
-static void drm_fbdev_damage_blit_real(struct drm_fb_helper *fb_helper,

-  struct drm_clip_rect *clip,
-  struct iosys_map *dst)
+static void drm_fbdev_generic_damage_blit_real(struct drm_fb_helper *fb_helper,
+  struct drm_clip_rect *clip,
+  struct iosys_map *dst)
  {
struct drm_framebuffer *fb = fb_helper->fb;
size_t offset = clip->y1 * fb->pitches[0];
@@ -179,8 +179,8 @@ static void drm_fbdev_damage_blit_real(struct drm_fb_helper 
*fb_helper,
}
  }
  
-static int drm_fbdev_damage_blit(struct drm_fb_helper *fb_helper,

-struct drm_clip_rect *clip)
+static int drm_fbdev_generic_damage_blit(struct drm_fb_helper *fb_helper,
+struct drm_clip_rect *clip)
  {
struct drm_client_buffer *buffer = fb_helper->buffer;
struct iosys_map map, dst;
@@ -204,7 +204,7 @@ static int drm_fbdev_damage_blit(struct drm_fb_helper 
*fb_helper,
goto out;
  
  	dst = map;

-   drm_fbdev_damage_blit_real(fb_helper, clip, );
+   drm_fbdev_generic_damage_blit_real(fb_helper, clip, );
  
  	drm_client_buffer_vunmap(buffer);
  
@@ -214,7 +214,8 @@ static int drm_fbdev_damage_blit(struct drm_fb_helper *fb_helper,

return ret;
  }
  
-static int drm_fbdev_fb_dirty(struct drm_fb_helper *helper, struct drm_clip_rect *clip)

+static int drm_fbdev_generic_helper_fb_dirty(struct 

Re: Build regressions/improvements in v6.3-rc3 (drm/msm/)

[Geert Uytterhoeven]

Hi Randy,

On Tue, Mar 21, 2023 at 4:10 PM Randy Dunlap  wrote:
> On 3/21/23 00:34, Geert Uytterhoeven wrote:
> > On Tue, Mar 21, 2023 at 6:38 AM Randy Dunlap  wrote:
> >> On 3/20/23 01:21, Geert Uytterhoeven wrote:
> >>> Below is the list of build error/warning regressions/improvements in
> >>> v6.3-rc3[1] compared to v6.2[2].
> >>>
> >>> Summarized:
> >>>   - build errors: +9/-14
> >>>   - build warnings: +4/-1447
> >>>
> >>> JFYI, when comparing v6.3-rc3[1] to v6.3-rc2[3], the summaries are:
> >>>   - build errors: +0/-1
> >>>   - build warnings: +0/-0
> >>>
> >>> Happy fixing! ;-)
> >>>
> >>> Thanks to the linux-next team for providing the build service.
> >>>
> >>> [1] 
> >>> http://kisskb.ellerman.id.au/kisskb/branch/linus/head/e8d018dd0257f744ca50a729e3d042cf2ec9da65/
> >>>  (all 152 configs)
> >>> [2] 
> >>> http://kisskb.ellerman.id.au/kisskb/branch/linus/head/c9c3395d5e3dcc6daee66c6908354d47bf98cb0c/
> >>>  (all 152 configs)
> >>> [3] 
> >>> http://kisskb.ellerman.id.au/kisskb/branch/linus/head/eeac8ede17557680855031c6f305ece2378af326/
> >>>  (all 152 configs)
> >>>
> >>>
> >>> *** ERRORS ***
> >>>
> >>> 9 error regressions:
> >>
> >>>   + /kisskb/src/drivers/gpu/drm/msm/msm_mdss.c: error: case label does 
> >>> not reduce to an integer constant:  => 300:2, 299:2, 296:2
> >>
> >>
> >> Are these due to the sign bit being set after a shift?
> >> It looks that way since it is only reported for such values.
> >
> > Yep.
> >
> >> From the reports on the build server, it only happens when building with 
> >> gcc5.
> >> I don't have the ability to build with gcc5 or I would test it.
> >
> > I deliberately installed gcc-5.5.0-nolibc/aarch64-linux to reproduce it
> > (gcc5 on x86 didn't reproduce).
>
> Yes, I installed that same compiler. When I tried to use it, I got:
>
> /opt/crosstool/gcc-5.5.0-nolibc/aarch64-linux/bin/aarch64-linux-gcc: unknown 
> C compiler
> scripts/Kconfig.include:44: Sorry, this C compiler is not supported.

I didn't run into that. I used

make ARCH=arm64
CROSS_COMPILE=/opt/cross/gcc-5.5.0-nolibc/aarch64-linux/bin/aarch64-linux-
drivers/gpu/drm/msm/msm_mdss.o

I did have to disable CONFIG_GCC_PLUGINS, else it couldn't find
.

> >> @Rob and other drm/msm people, what do you think about this?
> >> (or is this already fixed somewhere but not yet in linux-next?)
> >
> > Thanks, I posted a similar fix two weeks ago:
> > https://lore.kernel.org/all/20230306090633.65918-1-geert+rene...@glider.be
>
> OK, I replied to that one.

Thanks!

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [v2,1/8] drm/fbdev-generic: Always use shadow buffering

[Sui jingfeng]

On 2023/3/20 23:07, Thomas Zimmermann wrote:

Remove all codepaths that implement fbdev output directly on GEM
buffers. Always allocate a shadow buffer in system memory and set
up deferred I/O for mmap.

The fbdev code that operated directly on GEM buffers was used by
drivers based on GEM DMA helpers. Those drivers have been migrated
to use fbdev-dma, a dedicated fbdev emulation for DMA memory. All
remaining users of fbdev-generic require shadow buffering.

Memory management of the remaining callers uses TTM, GEM SHMEM
helpers or a variant of GEM DMA helpers that is incompatible with
fbdev-dma. Therefore remove the unused codepaths from fbdev-generic
and simplify the code.

Using a shadow buffer with deferred I/O is probably the best case
for most remaining callers. Some of the TTM-based drivers might
benefit from a dedicated fbdev emulation that operates directly on
the driver's video memory.


I don't understand here,  the TTM-based drivers should have equivalent 
performance


with you implement. Because device memory typically very slow for cpu 
read, at least


this is true for Mips and loongarch architecture.  TTM-based drivers for 
those platform


is also prefer to render to system ram first(for fast reading and 
compositing) and then


blit to the real framebuffer pinned to VRAM.


In turn, I think shmem helper based drivers might benefit from a 
dedicated fbdev emulation.


Because you are blit to the shadow of the video memory for shmem helper 
based driver. The


driver may need another blit to the ultimate framebuffer.  Using a 
shadow buffer is still acceptable


though, but why  do you say "the TTM-based drivers might benefit from a 
dedicated fbdev emulation" ?




Signed-off-by: Thomas Zimmermann 
Reviewed-by: Javier Martinez Canillas 
Acked-by: Zack Rusin 
---
  drivers/gpu/drm/drm_fbdev_generic.c | 184 +---
  1 file changed, 30 insertions(+), 154 deletions(-)

diff --git a/drivers/gpu/drm/drm_fbdev_generic.c 
b/drivers/gpu/drm/drm_fbdev_generic.c
index 4d6325e91565..e48a8e82378d 100644
--- a/drivers/gpu/drm/drm_fbdev_generic.c
+++ b/drivers/gpu/drm/drm_fbdev_generic.c
@@ -11,16 +11,6 @@
  
  #include 
  
-static bool drm_fbdev_use_shadow_fb(struct drm_fb_helper *fb_helper)

-{
-   struct drm_device *dev = fb_helper->dev;
-   struct drm_framebuffer *fb = fb_helper->fb;
-
-   return dev->mode_config.prefer_shadow_fbdev ||
-  dev->mode_config.prefer_shadow ||
-  fb->funcs->dirty;
-}
-
  /* @user: 1=userspace, 0=fbcon */
  static int drm_fbdev_fb_open(struct fb_info *info, int user)
  {
@@ -46,115 +36,33 @@ static int drm_fbdev_fb_release(struct fb_info *info, int 
user)
  static void drm_fbdev_fb_destroy(struct fb_info *info)
  {
struct drm_fb_helper *fb_helper = info->par;
-   void *shadow = NULL;
+   void *shadow = info->screen_buffer;
  
  	if (!fb_helper->dev)

return;
  
-	if (info->fbdefio)

-   fb_deferred_io_cleanup(info);
-   if (drm_fbdev_use_shadow_fb(fb_helper))
-   shadow = info->screen_buffer;
-
+   fb_deferred_io_cleanup(info);
drm_fb_helper_fini(fb_helper);
-
-   if (shadow)
-   vfree(shadow);
-   else if (fb_helper->buffer)
-   drm_client_buffer_vunmap(fb_helper->buffer);
-
+   vfree(shadow);
drm_client_framebuffer_delete(fb_helper->buffer);
-   drm_client_release(_helper->client);
  
+	drm_client_release(_helper->client);

drm_fb_helper_unprepare(fb_helper);
kfree(fb_helper);
  }
  
-static int drm_fbdev_fb_mmap(struct fb_info *info, struct vm_area_struct *vma)

-{
-   struct drm_fb_helper *fb_helper = info->par;
-
-   if (drm_fbdev_use_shadow_fb(fb_helper))
-   return fb_deferred_io_mmap(info, vma);
-   else if (fb_helper->dev->driver->gem_prime_mmap)
-   return 
fb_helper->dev->driver->gem_prime_mmap(fb_helper->buffer->gem, vma);
-   else
-   return -ENODEV;
-}
-
-static bool drm_fbdev_use_iomem(struct fb_info *info)
-{
-   struct drm_fb_helper *fb_helper = info->par;
-   struct drm_client_buffer *buffer = fb_helper->buffer;
-
-   return !drm_fbdev_use_shadow_fb(fb_helper) && buffer->map.is_iomem;
-}
-
-static ssize_t drm_fbdev_fb_read(struct fb_info *info, char __user *buf,
-size_t count, loff_t *ppos)
-{
-   ssize_t ret;
-
-   if (drm_fbdev_use_iomem(info))
-   ret = drm_fb_helper_cfb_read(info, buf, count, ppos);
-   else
-   ret = drm_fb_helper_sys_read(info, buf, count, ppos);
-
-   return ret;
-}
-
-static ssize_t drm_fbdev_fb_write(struct fb_info *info, const char __user *buf,
- size_t count, loff_t *ppos)
-{
-   ssize_t ret;
-
-   if (drm_fbdev_use_iomem(info))
-   ret = drm_fb_helper_cfb_write(info, buf, count, ppos);
-   else
-   ret = drm_fb_helper_sys_write(info, 

Re: [PATCH 00/10] drm/msm: fix bind error handling

[Dmitry Baryshkov]

On 21/03/2023 15:02, Johan Hovold wrote:

On Mon, Mar 06, 2023 at 11:07:12AM +0100, Johan Hovold wrote:

I had reasons to look closer at the MSM DRM driver error handling and
realised that it had suffered from a fair amount of bit rot over the
years.

Unfortunately, I started fixing this in my 6.2 branch and failed to
notice two partial and, as it turned out, broken attempts to address
this that are now in 6.3-rc1.

Instead of trying to salvage this incrementally, I'm reverting the two
broken commits so that clean and backportable fixes can be added in
their place.

Included are also two related cleanups.


Any further comments to these patches (except for 9/10, which should be
dropped)?

As the patches being reverted here were first added in 6.3-rc1 there is
still time to get this into 6.3-rc (e.g. before AUTOSEL starts trying to
backport them).


I will take a look at the patches. Additional question, as you have been 
looking into this area. We have plenty of code which is only called 
under the `if (kms)` condition. Could you hopefully move these parts to 
separate functions, so that the error handling is also simpler? If not, 
I'll put this to my todo list, but it might take some time before I have 
time for that.




Johan


Johan Hovold (10):
   Revert "drm/msm: Add missing check and destroy for
 alloc_ordered_workqueue"
   Revert "drm/msm: Fix failure paths in msm_drm_init()"
   drm/msm: fix NULL-deref on snapshot tear down
   drm/msm: fix NULL-deref on irq uninstall
   drm/msm: fix drm device leak on bind errors
   drm/msm: fix vram leak on bind errors
   drm/msm: fix missing wq allocation error handling
   drm/msm: fix workqueue leak on bind errors
   drm/msm: use drmm_mode_config_init()
   drm/msm: move include directive

  drivers/gpu/drm/msm/disp/msm_disp_snapshot.c |  3 -
  drivers/gpu/drm/msm/msm_drv.c| 67 +---
  2 files changed, 44 insertions(+), 26 deletions(-)


--
With best wishes
Dmitry

Re: [PATCH 1/2] dt-bindings: drm/bridge: Add no-hpd property

[Krzysztof Kozlowski]

On 21/03/2023 15:28, Jayesh Choudhary wrote:
> 
> 
> On 21/03/23 18:08, Krzysztof Kozlowski wrote:
>> On 21/03/2023 13:02, Jayesh Choudhary wrote:

> +type: boolean
> +description:
> +  Set if the HPD line on the bridge isn't hooked up to anything or is
> +  otherwise unusable.

 It's the property of the panel, not bridge. Unless you want to say that
 bridge physically does not have HPD? Does it follow the standard in such
 case?
>>>
>>> MHDP does have hpd. But the mhdp driver should handle the cases when the
>>
>> This is about bindings, not driver. Your driver can still handle this as
>> it wishes.
>>
>>> hpd pin of bridge is not connected to that of the DP-connector. This is
>>> to add support for that. (optional property)
>>
>> Which is indicated by panel no-hpd, right?
> 
> Actually no panel is involved in this. For TI SoC J721S2, the data 
> pipeline involves the bridge whose endpoint is directly the DP connector 
> with compatible 'dp-connector'. And in the binding dp-connector.yaml, 
> there isn't any 'no-hpd' property for this indication.
> 
> Does this clarifies the issue? Or did I misinterpret your comment?

Yes, then you only need to narrow which hardware does not have HPD
hooked up. Or at least clarify that it is not about driver having or not
having HPD control...


Best regards,
Krzysztof

Re: [PATCH 04/10] drm/msm: fix NULL-deref on irq uninstall

[Dmitry Baryshkov]

On 06/03/2023 12:07, Johan Hovold wrote:

In case of early initialisation errors and on platforms that do not use
the DPU controller, the deinitilisation code can be called with the kms
pointer set to NULL.

Fixes: f026e431cf86 ("drm/msm: Convert to Linux IRQ interfaces")
Cc: sta...@vger.kernel.org  # 5.14
Cc: Thomas Zimmermann 
Signed-off-by: Johan Hovold 


Reviewed-by: Dmitry Baryshkov 


---
  drivers/gpu/drm/msm/msm_drv.c | 8 +---
  1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 17a59d73fe01..2f2bcdb671d2 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -251,9 +251,11 @@ static int msm_drm_uninit(struct device *dev)
drm_bridge_remove(priv->bridges[i]);
priv->num_bridges = 0;
  
-	pm_runtime_get_sync(dev);

-   msm_irq_uninstall(ddev);
-   pm_runtime_put_sync(dev);
+   if (kms) {
+   pm_runtime_get_sync(dev);
+   msm_irq_uninstall(ddev);
+   pm_runtime_put_sync(dev);
+   }
  
  	if (kms && kms->funcs)

kms->funcs->destroy(kms);


--
With best wishes
Dmitry

Re: display band (display area vs real visible area)

[Simon Ser]

The thread is:
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/87

Re: Build regressions/improvements in v6.3-rc3 (drm/msm/)

[Randy Dunlap]

Hiya,

On 3/21/23 00:34, Geert Uytterhoeven wrote:
> Hi Randy,
> 
> On Tue, Mar 21, 2023 at 6:38 AM Randy Dunlap  wrote:
>> On 3/20/23 01:21, Geert Uytterhoeven wrote:
>>> Below is the list of build error/warning regressions/improvements in
>>> v6.3-rc3[1] compared to v6.2[2].
>>>
>>> Summarized:
>>>   - build errors: +9/-14
>>>   - build warnings: +4/-1447
>>>
>>> JFYI, when comparing v6.3-rc3[1] to v6.3-rc2[3], the summaries are:
>>>   - build errors: +0/-1
>>>   - build warnings: +0/-0
>>>
>>> Happy fixing! ;-)
>>>
>>> Thanks to the linux-next team for providing the build service.
>>>
>>> [1] 
>>> http://kisskb.ellerman.id.au/kisskb/branch/linus/head/e8d018dd0257f744ca50a729e3d042cf2ec9da65/
>>>  (all 152 configs)
>>> [2] 
>>> http://kisskb.ellerman.id.au/kisskb/branch/linus/head/c9c3395d5e3dcc6daee66c6908354d47bf98cb0c/
>>>  (all 152 configs)
>>> [3] 
>>> http://kisskb.ellerman.id.au/kisskb/branch/linus/head/eeac8ede17557680855031c6f305ece2378af326/
>>>  (all 152 configs)
>>>
>>>
>>> *** ERRORS ***
>>>
>>> 9 error regressions:
>>
>>>   + /kisskb/src/drivers/gpu/drm/msm/msm_mdss.c: error: case label does not 
>>> reduce to an integer constant:  => 300:2, 299:2, 296:2
>>
>>
>> Are these due to the sign bit being set after a shift?
>> It looks that way since it is only reported for such values.
> 
> Yep.
> 
>> From the reports on the build server, it only happens when building with 
>> gcc5.
>> I don't have the ability to build with gcc5 or I would test it.
> 
> I deliberately installed gcc-5.5.0-nolibc/aarch64-linux to reproduce it
> (gcc5 on x86 didn't reproduce).

Yes, I installed that same compiler. When I tried to use it, I got:

/opt/crosstool/gcc-5.5.0-nolibc/aarch64-linux/bin/aarch64-linux-gcc: unknown C 
compiler
scripts/Kconfig.include:44: Sorry, this C compiler is not supported.

and I didn't try to track down what that means or what is causing it...

>> @Rob and other drm/msm people, what do you think about this?
>> (or is this already fixed somewhere but not yet in linux-next?)
> 
> Thanks, I posted a similar fix two weeks ago:
> https://lore.kernel.org/all/20230306090633.65918-1-geert+rene...@glider.be

OK, I replied to that one.

Thanks.

-- 
~Randy

Re: [PATCH] drm/msm/dpu: Fix bit-shifting UB in DPU_HW_VER() macro

[Randy Dunlap]

On 3/6/23 01:06, Geert Uytterhoeven wrote:
> With gcc-5 and CONFIG_UBSAN_SHIFT=y:
> 
> drivers/gpu/drm/msm/msm_mdss.c: In function 'msm_mdss_enable':
> drivers/gpu/drm/msm/msm_mdss.c:296:2: error: case label does not reduce 
> to an integer constant
>   case DPU_HW_VER_800:
>   ^
> drivers/gpu/drm/msm/msm_mdss.c:299:2: error: case label does not reduce 
> to an integer constant
>   case DPU_HW_VER_810:
>   ^
> drivers/gpu/drm/msm/msm_mdss.c:300:2: error: case label does not reduce 
> to an integer constant
>   case DPU_HW_VER_900:
>   ^
> 
> This happens because for major revisions 8 or greather, the non-sign bit
> of the major revision number is shifted into bit 31 of a signed integer,
> which is undefined behavior.
> 
> Fix this by casting the major revision number to unsigned int.
> 
> Fixes: efcd0107727c4f04 ("drm/msm/dpu: add support for SM8550")
> Fixes: 4a352c2fc15aec1e ("drm/msm/dpu: Introduce SC8280XP")
> Fixes: 100d7ef6995d1f86 ("drm/msm/dpu: add support for SM8450")
> Signed-off-by: Geert Uytterhoeven 

Reviewed-by: Randy Dunlap 

Thanks.

> ---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
> index ddab9caebb18c40d..bbd3cbdd77956c5d 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
> @@ -19,8 +19,9 @@
>   */
>  #define MAX_BLOCKS12
>  
> -#define DPU_HW_VER(MAJOR, MINOR, STEP) (((MAJOR & 0xF) << 28)|\
> - ((MINOR & 0xFFF) << 16)  |\
> +#define DPU_HW_VER(MAJOR, MINOR, STEP)   \
> + unsigned int)MAJOR & 0xF) << 28) |  \
> + ((MINOR & 0xFFF) << 16) |   \
>   (STEP & 0x))
>  
>  #define DPU_HW_MAJOR(rev)((rev) >> 28)

-- 
~Randy

Re: [PATCH v4 2/8] accel/qaic: Add uapi and core driver file

[Jeffrey Hugo]

On 3/21/2023 4:34 AM, Oded Gabbay wrote:

On Mon, Mar 20, 2023 at 5:11 PM Jeffrey Hugo  wrote:


Add the QAIC driver uapi file and core driver file that binds to the PCIe
device. The core driver file also creates the accel device and manages
all the interconnections between the different parts of the driver.

The driver can be built as a module. If so, it will be called "qaic.ko".

Signed-off-by: Jeffrey Hugo 
Reviewed-by: Carl Vanderlip 
Reviewed-by: Pranjal Ramajor Asha Kanojiya 
Reviewed-by: Stanislaw Gruszka 
---
  drivers/accel/qaic/qaic.h | 282 ++
  drivers/accel/qaic/qaic_drv.c | 647 ++
  include/uapi/drm/qaic_accel.h | 397 ++
  3 files changed, 1326 insertions(+)
  create mode 100644 drivers/accel/qaic/qaic.h
  create mode 100644 drivers/accel/qaic/qaic_drv.c
  create mode 100644 include/uapi/drm/qaic_accel.h

diff --git a/drivers/accel/qaic/qaic.h b/drivers/accel/qaic/qaic.h
new file mode 100644
index 000..36c0d0ba
--- /dev/null
+++ b/drivers/accel/qaic/qaic.h
@@ -0,0 +1,282 @@
+/* SPDX-License-Identifier: GPL-2.0-only
+ *
+ * Copyright (c) 2019-2021, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2021-2023 Qualcomm Innovation Center, Inc. All rights 
reserved.
+ */
+
+#ifndef _QAIC_H_
+#define _QAIC_H_
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define QAIC_DBC_BASE  SZ_128K
+#define QAIC_DBC_SIZE  SZ_4K
+
+#define QAIC_NO_PARTITION  -1
+
+#define QAIC_DBC_OFF(i)((i) * QAIC_DBC_SIZE + QAIC_DBC_BASE)
+
+#define to_qaic_bo(obj) container_of(obj, struct qaic_bo, base)
+
+extern bool datapath_polling;
+
+struct qaic_user {
+   /* Uniquely identifies this user for the device */
+   int handle;
+   struct kref ref_count;
+   /* Char device opened by this user */
+   struct qaic_drm_device  *qddev;
+   /* Node in list of users that opened this drm device */
+   struct list_headnode;
+   /* SRCU used to synchronize this user during cleanup */
+   struct srcu_struct  qddev_lock;
+   atomic_tchunk_id;
+};
+
+struct dma_bridge_chan {
+   /* Pointer to device strcut maintained by driver */
+   struct qaic_device  *qdev;
+   /* ID of this DMA bridge channel(DBC) */
+   unsigned intid;
+   /* Synchronizes access to xfer_list */
+   spinlock_t  xfer_lock;
+   /* Base address of request queue */
+   void*req_q_base;
+   /* Base address of response queue */
+   void*rsp_q_base;
+   /*
+* Base bus address of request queue. Response queue bus address can be
+* calculated by adding request queue size to this variable
+*/
+   dma_addr_t  dma_addr;
+   /* Total size of request and response queue in byte */
+   u32 total_size;
+   /* Capacity of request/response queue */
+   u32 nelem;
+   /* The user that opened this DBC */
+   struct qaic_user*usr;
+   /*
+* Request ID of next memory handle that goes in request queue. One
+* memory handle can enqueue more than one request elements, all
+* this requests that belong to same memory handle have same request ID
+*/
+   u16 next_req_id;
+   /* true: DBC is in use; false: DBC not in use */
+   boolin_use;
+   /*
+* Base address of device registers. Used to read/write request and
+* response queue's head and tail pointer of this DBC.
+*/
+   void __iomem*dbc_base;
+   /* Head of list where each node is a memory handle queued in request 
queue */
+   struct list_headxfer_list;
+   /* Synchronizes DBC readers during cleanup */
+   struct srcu_struct  ch_lock;
+   /*
+* When this DBC is released, any thread waiting on this wait queue is
+* woken up
+*/
+   wait_queue_head_t   dbc_release;
+   /* Head of list where each node is a bo associated with this DBC */
+   struct list_headbo_lists;
+   /* The irq line for this DBC. Used for polling */
+   unsigned intirq;
+   /* Polling work item to simulate interrupts */
+   struct work_struct  poll_work;
+};
+
+struct qaic_device {
+   /* Pointer to base PCI device struct of our physical device */
+   struct pci_dev  *pdev;
+   /* Req. ID of request that will be queued next in MHI control device */
+   u32 next_seq_num;
+   /* Base address of bar 0 */
+   void __iomem*bar_0;
+   /* Base address of bar 2 */
+   void __iomem*bar_2;
+   /* Controller structure for MHI devices 

Re: [PATCH 03/10] drm/msm: fix NULL-deref on snapshot tear down

[Dmitry Baryshkov]

On 06/03/2023 12:07, Johan Hovold wrote:

In case of early initialisation errors and on platforms that do not use
the DPU controller, the deinitilisation code can be called with the kms
pointer set to NULL.

Fixes: 98659487b845 ("drm/msm: add support to take dpu snapshot")
Cc: sta...@vger.kernel.org  # 5.14
Cc: Abhinav Kumar 
Signed-off-by: Johan Hovold 


Reviewed-by: Dmitry Baryshkov 


---
  drivers/gpu/drm/msm/msm_drv.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 9ded384acba4..17a59d73fe01 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -242,7 +242,8 @@ static int msm_drm_uninit(struct device *dev)
msm_fbdev_free(ddev);
  #endif
  
-	msm_disp_snapshot_destroy(ddev);

+   if (kms)
+   msm_disp_snapshot_destroy(ddev);
  
  	drm_mode_config_cleanup(ddev);
  


--
With best wishes
Dmitry

Re: [PATCH 1/1] drm/sun4i: tcon: Fix setting PLL rate when using DSI

[Maxime Ripard]

Hi,

On Sun, Mar 19, 2023 at 05:07:04PM +0100, Frank Oltmanns wrote:
> Set the required PLL rate by adjusting the dotclock rate when calling
> clk_set_rate() when using DSI.
> 
> According to the Allwinners A64's BSP code, a TCON divider of 4 has to
> be used and the PLL rate needs to be set to the following frequency when
> using DSI:
> PLL rate = DCLK * bpp / lanes
> 
> After this change the common mode set function would only contain
> setting the resolution. Therefore, dissolve the function and transfer
> the functionality to the individual mode set functions.
> 
> Signed-off-by: Frank Oltmanns 

This is similar to:
https://lore.kernel.org/all/20230320161636.24411-1-romanbera...@icloud.com/

What's the story there?

Maxime


signature.asc
Description: PGP signature

Re: [PATCH] drm/sun4i: uncouple DSI dotclock divider from TCON0_DCLK_REG

[Maxime Ripard]

Hi,

On Mon, Mar 20, 2023 at 05:16:36PM +0100, Roman Beranek wrote:
> In the case of DSI output, the value of SUN4I_TCON0_DCLK_DIV (4) does
> not represent the actual dotclock divider, PLL_MIPI instead runs at
> (bpp / lanes )-multiple [1] of the dotclock. [2] Setting 4 as dotclock
> divder thus leads to reduced frame rate, specifically by 1/3 on 4-lane
> panels, and by 2/3 on 2-lane panels respectively.
> 
> As sun4i_dotclock driver stores its calculated divider directly in
> the register, conditional handling of the DSI output scenario is needed.
> Instead of reading the divider from SUN4I_TCON0_DCLK_REG, retrieve
> the value from tcon->dclk_min_div.
> 
> [1] bits per pixel / number of DSI lanes
> [2] 
> https://github.com/BPI-SINOVOIP/BPI-M64-bsp-4.4/blob/66bef0f2f30b367eb93b1cbad21ce85e0361f7ae/linux-sunxi/drivers/video/fbdev/sunxi/disp2/disp/de/lowlevel_sun50iw1/disp_al.c#L322
> 
> Signed-off-by: Roman Beranek 

This is similar to
https://lore.kernel.org/all/20230319160704.9858-2-fr...@oltmanns.dev/

What's the story there? Also, how was it tested/confirmed?

Maxime


signature.asc
Description: PGP signature

Re: [PATCH 05/10] drm/msm: fix drm device leak on bind errors

[Dmitry Baryshkov]

On 06/03/2023 12:07, Johan Hovold wrote:

Make sure to free the DRM device also in case of early errors during
bind().

Fixes: 2027e5b3413d ("drm/msm: Initialize MDSS irq domain at probe time")
Cc: sta...@vger.kernel.org  # 5.17
Cc: Dmitry Baryshkov 
Signed-off-by: Johan Hovold 


Can we migrate to devm_drm_dev_alloc instead() ? Will it make code 
simpler and/or easier to handle?



---
  drivers/gpu/drm/msm/msm_drv.c | 10 --
  1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 2f2bcdb671d2..89634159ad75 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -444,12 +444,12 @@ static int msm_drm_init(struct device *dev, const struct 
drm_driver *drv)
  
  	ret = msm_init_vram(ddev);

if (ret)
-   return ret;
+   goto err_put_dev;
  
  	/* Bind all our sub-components: */

ret = component_bind_all(dev, ddev);
if (ret)
-   return ret;
+   goto err_put_dev;
  
  	dma_set_max_seg_size(dev, UINT_MAX);
  
@@ -544,6 +544,12 @@ static int msm_drm_init(struct device *dev, const struct drm_driver *drv)
  
  err_msm_uninit:

msm_drm_uninit(dev);
+
+   return ret;
+
+err_put_dev:
+   drm_dev_put(ddev);
+
return ret;
  }
  


--
With best wishes
Dmitry

Re: [PATCH 06/37] drm/vkms/vkms_composer: Fix a few different kerneldoc formatting

[Randy Dunlap]

On 3/21/23 02:49, Melissa Wen wrote:
> O 03/20, Randy Dunlap wrote:
>>
>>
>> On 3/20/23 16:46, Melissa Wen wrote:
>>> On 03/17, Lee Jones wrote:
 Fixes the following W=1 kernel build warning(s):

  drivers/gpu/drm/vkms/vkms_composer.c:41: warning: Function parameter or 
 member 'frame_info' not described in 'pre_mul_alpha_blend'
  drivers/gpu/drm/vkms/vkms_composer.c:41: warning: Excess function 
 parameter 'src_frame_info' description in 'pre_mul_alpha_blend'
  drivers/gpu/drm/vkms/vkms_composer.c:72: warning: Cannot understand  * 
 @wb_frame_info: The writeback frame buffer metadata

 Cc: Rodrigo Siqueira 
 Cc: Melissa Wen 
 Cc: Haneen Mohammed 
 Cc: Daniel Vetter 
 Cc: David Airlie 
 Cc: dri-devel@lists.freedesktop.org
 Signed-off-by: Lee Jones 
 ---
  drivers/gpu/drm/vkms/vkms_composer.c | 6 --
  1 file changed, 4 insertions(+), 2 deletions(-)

 diff --git a/drivers/gpu/drm/vkms/vkms_composer.c 
 b/drivers/gpu/drm/vkms/vkms_composer.c
 index 8e53fa80742b2..41668eedf4272 100644
 --- a/drivers/gpu/drm/vkms/vkms_composer.c
 +++ b/drivers/gpu/drm/vkms/vkms_composer.c
 @@ -22,7 +22,7 @@ static u16 pre_mul_blend_channel(u16 src, u16 dst, u16 
 alpha)
  
  /**
   * pre_mul_alpha_blend - alpha blending equation
 - * @src_frame_info: source framebuffer's metadata
 + * @frame_info: source framebuffer's metadata
   * @stage_buffer: The line with the pixels from src_plane
   * @output_buffer: A line buffer that receives all the blends output
   *
 @@ -69,11 +69,13 @@ static void fill_background(const struct 
 pixel_argb_u16 *background_color,
  }
  
  /**
 - * @wb_frame_info: The writeback frame buffer metadata
 + * blend
>>> As we are already here:
>>> * blend - blend pixels from a given row and calculate crc
>>
>>  * blend: blend pixels from a given row and calculate CRC
>>
>> preferably.
> 
> Hmm.. I didn't get the colon suggestion. This first line is a brief
> description of the function blend(), so I understand that a more
> accurate doc standard is:
> 
> blend() - Blend pixels from a given row and calculate crc
> 

You are correct. My bad. Sorry for the noise.

> 
>>
>>> Reviewed-by: Melissa Wen 
>>>
 + * @wb: The writeback frame buffer metadata
   * @crtc_state: The crtc state
   * @crc32: The crc output of the final frame
   * @output_buffer: A buffer of a row that will receive the result of the 
 blend(s)
   * @stage_buffer: The line with the pixels from plane being blend to the 
 output
 + * @row_size: Size of memory taken up by row data (line_width * 
 pixel_size)
   *
   * This function blends the pixels (Using the `pre_mul_alpha_blend`)
   * from all planes, calculates the crc32 of the output from the former 
 step,
 -- 
 2.40.0.rc1.284.g88254d51c5-goog

>>
>> -- 
>> ~Randy

-- 
~Randy

Re: [PATCHv4 2/2] i915/display/dp: SDP CRC16 for 128b132b link layer

[Jani Nikula]

On Tue, 07 Mar 2023, Jani Nikula  wrote:
> On Tue, 07 Mar 2023, Jani Nikula  wrote:
>> On Thu, 02 Mar 2023, Arun R Murthy  wrote:
>>> Enable SDP error detection configuration, this will set CRC16 in
>>> 128b/132b link layer.
>>> For Display version 13 a hardware bit31 in register VIDEO_DIP_CTL is
>>> added to enable/disable SDP CRC applicable for DP2.0 only, but the
>>> default value of this bit will enable CRC16 in 128b/132b hence
>>> skipping this write.
>>> Corrective actions on SDP corruption is yet to be defined.
>>>
>>> v2: Moved the CRC enable to link training init(Jani N)
>>> v3: Moved crc enable to ddi pre enable 
>>> v4: Separate function for SDP CRC16 (Jani N)
>>>
>>> Signed-off-by: Arun R Murthy 
>>
>> Reviewed-by: Jani Nikula 
>
> PS. I've queued retest on this one, need to wait for results before
> applying.

And finally pushed to drm-intel-next. Thanks for the patches & patience.

BR,
Jani.

>
>
>>
>>> ---
>>>  drivers/gpu/drm/i915/display/intel_ddi.c  |  4 
>>>  .../drm/i915/display/intel_dp_link_training.c | 20 +++
>>>  .../drm/i915/display/intel_dp_link_training.h |  2 ++
>>>  3 files changed, 26 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
>>> b/drivers/gpu/drm/i915/display/intel_ddi.c
>>> index e5979427b38b..127b3035f92d 100644
>>> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
>>> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
>>> @@ -2519,6 +2519,10 @@ static void intel_ddi_pre_enable_dp(struct 
>>> intel_atomic_state *state,
>>>  {
>>> struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
>>>  
>>> +   if (HAS_DP20(dev_priv))
>>> +   intel_dp_128b132b_sdp_crc16(enc_to_intel_dp(encoder),
>>> +   crtc_state);
>>> +
>>> if (DISPLAY_VER(dev_priv) >= 12)
>>> tgl_ddi_pre_enable_dp(state, encoder, crtc_state, conn_state);
>>> else
>>> diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c 
>>> b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
>>> index 3d3efcf02011..35d31e4efab9 100644
>>> --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
>>> +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
>>> @@ -1454,3 +1454,23 @@ void intel_dp_start_link_train(struct intel_dp 
>>> *intel_dp,
>>> if (!passed)
>>> intel_dp_schedule_fallback_link_training(intel_dp, crtc_state);
>>>  }
>>> +
>>> +void intel_dp_128b132b_sdp_crc16(struct intel_dp *intel_dp,
>>> +const struct intel_crtc_state *crtc_state)
>>> +{
>>> +   struct drm_i915_private *i915 = dp_to_i915(intel_dp);
>>> +
>>> +   /*
>>> +* VIDEO_DIP_CTL register bit 31 should be set to '0' to not
>>> +* disable SDP CRC. This is applicable for Display version 13.
>>> +* Default value of bit 31 is '0' hence discarding the write
>>> +* TODO: Corrective actions on SDP corruption yet to be defined
>>> +*/
>>> +   if (intel_dp_is_uhbr(crtc_state))
>>> +   /* DP v2.0 SCR on SDP CRC16 for 128b/132b Link Layer */
>>> +   drm_dp_dpcd_writeb(_dp->aux,
>>> +  DP_SDP_ERROR_DETECTION_CONFIGURATION,
>>> +  DP_SDP_CRC16_128B132B_EN);
>>> +
>>> +   drm_dbg_kms(>drm, "DP2.0 SDP CRC16 for 128b/132b enabled\n");
>>> +}
>>> diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.h 
>>> b/drivers/gpu/drm/i915/display/intel_dp_link_training.h
>>> index 7fa1c0833096..2c8f2775891b 100644
>>> --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.h
>>> +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.h
>>> @@ -39,4 +39,6 @@ static inline u8 intel_dp_training_pattern_symbol(u8 
>>> pattern)
>>> return pattern & ~DP_LINK_SCRAMBLING_DISABLE;
>>>  }
>>>  
>>> +void intel_dp_128b132b_sdp_crc16(struct intel_dp *intel_dp,
>>> +const struct intel_crtc_state *crtc_state);
>>>  #endif /* __INTEL_DP_LINK_TRAINING_H__ */

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [PATCH 10/10] drm/msm: move include directive

[Dmitry Baryshkov]

On 06/03/2023 12:07, Johan Hovold wrote:

Move the include of of_address.h to the top of the file where it
belongs.

Signed-off-by: Johan Hovold 


Reviewed-by: Dmitry Baryshkov 


---
  drivers/gpu/drm/msm/msm_drv.c | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)


--
With best wishes
Dmitry

[RFC][PATCH v2 2/3] drm/i915: Adjust cursor_size_ok() func calling convention

[Ville Syrjala]

From: Ville Syrjälä 

Tweak the parameters we pass to the cursor size_ok() functions
in preparation for using them to populate the SIZE_HINT property.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_cursor.c | 63 +++--
 1 file changed, 32 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_cursor.c 
b/drivers/gpu/drm/i915/display/intel_cursor.c
index 31bef0427377..edeeb5f9f795 100644
--- a/drivers/gpu/drm/i915/display/intel_cursor.c
+++ b/drivers/gpu/drm/i915/display/intel_cursor.c
@@ -65,12 +65,10 @@ static u32 intel_cursor_position(const struct 
intel_plane_state *plane_state)
return pos;
 }
 
-static bool intel_cursor_size_ok(const struct intel_plane_state *plane_state)
+static bool intel_cursor_size_ok(struct drm_i915_private *i915,
+int width, int height)
 {
-   const struct drm_mode_config *config =
-   _state->uapi.plane->dev->mode_config;
-   int width = drm_rect_width(_state->uapi.dst);
-   int height = drm_rect_height(_state->uapi.dst);
+   const struct drm_mode_config *config = >drm.mode_config;
 
return width > 0 && width <= config->cursor_width &&
height > 0 && height <= config->cursor_height;
@@ -198,23 +196,25 @@ static u32 i845_cursor_ctl(const struct intel_crtc_state 
*crtc_state,
CURSOR_STRIDE(plane_state->view.color_plane[0].mapping_stride);
 }
 
-static bool i845_cursor_size_ok(const struct intel_plane_state *plane_state)
+static bool i845_cursor_size_ok(struct drm_plane *plane,
+   int width, int height)
 {
-   int width = drm_rect_width(_state->uapi.dst);
+   struct drm_i915_private *i915 = to_i915(plane->dev);
 
/*
 * 845g/865g are only limited by the width of their cursors,
 * the height is arbitrary up to the precision of the register.
 */
-   return intel_cursor_size_ok(plane_state) && IS_ALIGNED(width, 64);
+   return intel_cursor_size_ok(i915, width, height) && IS_ALIGNED(width, 
64);
 }
 
 static int i845_check_cursor(struct intel_crtc_state *crtc_state,
 struct intel_plane_state *plane_state)
 {
+   struct intel_plane *plane = to_intel_plane(plane_state->uapi.plane);
+   struct drm_i915_private *i915 = to_i915(plane->base.dev);
const struct drm_framebuffer *fb = plane_state->hw.fb;
-   struct drm_i915_private *i915 = to_i915(plane_state->uapi.plane->dev);
-   int ret;
+   int ret, width, height;
 
ret = intel_check_cursor(crtc_state, plane_state);
if (ret)
@@ -224,12 +224,14 @@ static int i845_check_cursor(struct intel_crtc_state 
*crtc_state,
if (!fb)
return 0;
 
+   width = drm_rect_width(_state->uapi.dst);
+   height = drm_rect_height(_state->uapi.dst);
+
/* Check for which cursor types we support */
-   if (!i845_cursor_size_ok(plane_state)) {
+   if (!i845_cursor_size_ok(>base, width, height)) {
drm_dbg_kms(>drm,
"Cursor dimension %dx%d not supported\n",
-   drm_rect_width(_state->uapi.dst),
-   drm_rect_height(_state->uapi.dst));
+   width, height);
return -EINVAL;
}
 
@@ -386,14 +388,13 @@ static u32 i9xx_cursor_ctl(const struct intel_crtc_state 
*crtc_state,
return cntl;
 }
 
-static bool i9xx_cursor_size_ok(const struct intel_plane_state *plane_state)
+static bool i9xx_cursor_size_ok(struct drm_plane *plane,
+   int width, int height,
+   unsigned int rotation)
 {
-   struct drm_i915_private *dev_priv =
-   to_i915(plane_state->uapi.plane->dev);
-   int width = drm_rect_width(_state->uapi.dst);
-   int height = drm_rect_height(_state->uapi.dst);
+   struct drm_i915_private *i915 = to_i915(plane->dev);
 
-   if (!intel_cursor_size_ok(plane_state))
+   if (!intel_cursor_size_ok(i915, width, height))
return false;
 
/* Cursor width is limited to a few power-of-two sizes */
@@ -412,8 +413,7 @@ static bool i9xx_cursor_size_ok(const struct 
intel_plane_state *plane_state)
 * cursor is not rotated. Everything else requires square
 * cursors.
 */
-   if (HAS_CUR_FBC(dev_priv) &&
-   plane_state->hw.rotation & DRM_MODE_ROTATE_0) {
+   if (HAS_CUR_FBC(i915) && rotation & DRM_MODE_ROTATE_0) {
if (height < 8 || height > width)
return false;
} else {
@@ -431,7 +431,7 @@ static int i9xx_check_cursor(struct intel_crtc_state 
*crtc_state,
struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
const struct drm_framebuffer *fb = plane_state->hw.fb;
enum pipe pipe = plane->pipe;
-   int ret;
+   int ret, width, height;
 
ret = 

[RFC][PATCH v2 3/3] drm/i915: Add SIZE_HINTS property for cursors

[Ville Syrjala]

From: Ville Syrjälä 

Advertize more suitable cursor sizes via the new SIZE_HINTS
plane property.

Here are some examples on various platforms:
ivb+:
31 SIZE_HINTS:
flags: immutable blob
blobs:

value:
48010001ff6f0200
size_hints blob decoded:
min: 64x8
max: 256x256
bitmap[0]: 0b100110
64  128  256
   8 ***
  16 ***
  32 ***
  64 ***
 128  **
 256   *
i945+:
31 SIZE_HINTS:
flags: immutable blob
blobs:

value:
4000400100011101
size_hints blob decoded:
min: 64x64
max: 256x256
bitmap[0]: 0b100010001
64  128  256
  64 *
 128  *
 256   *
i865:
31 SIZE_HINTS:
flags: immutable blob
blobs:

value:
4102ff03ff0f
size_hints blob decoded:
min: 64x1
max: 512x1023
bitmap[0]: 0b
bitmap[1]: 0b
64  128  256  512
   1 ****
   2 ****
   4 ****
   8 ****
  16 ****
  32 ****
  64 ****
 128 ****
 256 ****
 512 ****
1023 ****

Cc: Simon Ser 
Cc: Jonas Ådahl 
Cc: Daniel Stone 
Cc: Pekka Paalanen 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_cursor.c | 43 ++---
 1 file changed, 38 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_cursor.c 
b/drivers/gpu/drm/i915/display/intel_cursor.c
index edeeb5f9f795..449860342aea 100644
--- a/drivers/gpu/drm/i915/display/intel_cursor.c
+++ b/drivers/gpu/drm/i915/display/intel_cursor.c
@@ -388,9 +388,9 @@ static u32 i9xx_cursor_ctl(const struct intel_crtc_state 
*crtc_state,
return cntl;
 }
 
-static bool i9xx_cursor_size_ok(struct drm_plane *plane,
-   int width, int height,
-   unsigned int rotation)
+static bool _i9xx_cursor_size_ok(struct drm_plane *plane,
+int width, int height,
+unsigned int rotation)
 {
struct drm_i915_private *i915 = to_i915(plane->dev);
 
@@ -424,6 +424,12 @@ static bool i9xx_cursor_size_ok(struct drm_plane *plane,
return true;
 }
 
+static bool i9xx_cursor_size_ok(struct drm_plane *plane,
+   int width, int height)
+{
+   return _i9xx_cursor_size_ok(plane, width, height, DRM_MODE_ROTATE_0);
+}
+
 static int i9xx_check_cursor(struct intel_crtc_state *crtc_state,
 struct intel_plane_state *plane_state)
 {
@@ -445,8 +451,8 @@ static int i9xx_check_cursor(struct intel_crtc_state 
*crtc_state,
height = drm_rect_height(_state->uapi.dst);
 
/* Check for which cursor types we support */
-   if (!i9xx_cursor_size_ok(>base, width, height,
-plane_state->hw.rotation)) {
+   if (!_i9xx_cursor_size_ok(>base, width, height,
+ plane_state->hw.rotation)) {
drm_dbg_kms(_priv->drm,
"Cursor dimension %dx%d not supported\n",
width, height);
@@ -757,6 +763,31 @@ static const struct drm_plane_funcs 
intel_cursor_plane_funcs = {
.format_mod_supported = intel_cursor_format_mod_supported,
 };
 
+static void intel_cursor_add_size_hints_property(struct intel_plane *plane)
+{
+   struct drm_i915_private *i915 = to_i915(plane->base.dev);
+   const struct drm_mode_config *config = >drm.mode_config;
+
+   if (IS_I845G(i915) || IS_I865G(i915))
+   drm_plane_add_size_hints_property(>base,
+   

[RFC][PATCH v2 1/3] drm: Introduce plane SIZE_HINTS property

[Ville Syrjala]

From: Ville Syrjälä 

Add a new immutable plane property by which a plane can advertise
a handful of recommended plane sizes. This would be mostly exposed
by cursor planes as a slightly more capable replacement for
the DRM_CAP_CURSOR_WIDTH/HEIGHT caps, which can only declare
a one size fits all limit for the whole device.

Currently eg. amdgpu/i915/nouveau just advertize the max cursor
size via the cursor size caps. But always using the max sized
cursor can waste a surprising amount of power, so a better
stragey is desirable.

Most other drivers don't specify any cursor size at all, in
which case the ioctl code just claims that 64x64 is a great
choice. Whether that is actually true is debatable.

A poll of various compositor developers informs us that
blindly probing with setcursor/atomic ioctl to determine
suitable cursor sizes is not acceptable, thus the
introduction of the new property to supplant the cursor
size caps. The compositor will now be free to select a
more optimal cursor size from the short list of options.

The blob contains explicit min and max plane sizes, as
well as a 2D bitmap representing all the square and non-square
power of two sizes between the min and max.

Note that the reported sizes (either via the property or the
caps) make no claims about things such as plane scaling. So
these things should only really be consulted for simple
"cursor like" use cases.

v2: Try to add some docs
v3: Specify that value 0 is reserved for future use (basic idea from Jonas)
Drop the note about typical hardware (Pekka)
v4: Total redesign to include the 2D bitmap

Cc: Simon Ser 
Cc: Jonas Ådahl 
Cc: Daniel Stone 
Cc: Pekka Paalanen 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_mode_config.c |  7 +++
 drivers/gpu/drm/drm_plane.c   | 96 +++
 include/drm/drm_mode_config.h |  5 ++
 include/drm/drm_plane.h   |  6 ++
 include/uapi/drm/drm_mode.h   | 29 ++
 5 files changed, 143 insertions(+)

diff --git a/drivers/gpu/drm/drm_mode_config.c 
b/drivers/gpu/drm/drm_mode_config.c
index 87eb591fe9b5..21860f94a18c 100644
--- a/drivers/gpu/drm/drm_mode_config.c
+++ b/drivers/gpu/drm/drm_mode_config.c
@@ -374,6 +374,13 @@ static int drm_mode_create_standard_properties(struct 
drm_device *dev)
return -ENOMEM;
dev->mode_config.modifiers_property = prop;
 
+   prop = drm_property_create(dev,
+  DRM_MODE_PROP_IMMUTABLE | DRM_MODE_PROP_BLOB,
+  "SIZE_HINTS", 0);
+   if (!prop)
+   return -ENOMEM;
+   dev->mode_config.size_hints_property = prop;
+
return 0;
 }
 
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 24e7998d1731..fb9cee504767 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -140,6 +140,27 @@
  * DRM_FORMAT_MOD_LINEAR. Before linux kernel release v5.1 there have been
  * various bugs in this area with inconsistencies between the capability
  * flag and per-plane properties.
+ *
+ * SIZE_HINTS:
+ * Blob property which contains the set of recommended plane size
+ * which can used for simple "cursor like" use cases (eg. no scaling).
+ * Using these hints frees userspace from extensive probing of
+ * supported plane sizes through atomic/setcursor ioctls.
+ *
+ * For optimal usage userspace should pick the smallest size
+ * that satisfies its own requirements.
+ *
+ * The blob contains explicit min/max sizes, as well as a 2D bitmap
+ * representign all square and non-square POT sizes between.
+ *
+ * Drivers should only attach this property to planes that
+ * support a very limited set of sizes.
+ *
+ * Note that property value 0 (ie. no blob) is reserved for potential
+ * future use. Current userspace is expected to ignore the property
+ * if the value is 0, and fall back to some other means (eg.
+ * _CAP_CURSOR_WIDTH and _CAP_CURSOR_HEIGHT) to determine
+ * the appropriate plane size to use.
  */
 
 static unsigned int drm_num_planes(struct drm_device *dev)
@@ -1582,3 +1603,78 @@ int drm_plane_create_scaling_filter_property(struct 
drm_plane *plane,
return 0;
 }
 EXPORT_SYMBOL(drm_plane_create_scaling_filter_property);
+
+static int hint_dim(int x, int x0, int w, int min, int max)
+{
+   if (x == 0)
+   return min;
+   else if (x == w - 1)
+   return max;
+   else
+   return 1 << (x0 + x);
+}
+
+/**
+ * drm_plane_add_size_hint_property - create a size hint property
+ *
+ * @plane: drm plane
+ * @min_width: minimum width
+ * @min_height: minimum height
+ * @max_width: maximum width
+ * @max_height: maximum height
+ * @cursor_size_ok: function to check if specified size is ok
+ *
+ * Create a size hints property for the plane.
+ *
+ * RETURNS:
+ * Zero for success or -errno
+ */
+int drm_plane_add_size_hints_property(struct drm_plane *plane,
+

[RFC][PATCH v2 0/3] drm: Add plane SIZE_HINTS property

[Ville Syrjala]

From: Ville Syrjälä 

I was pondering how I'd be able to do non-square cursor
sizes without have a massive list of them in the SIZE_HINTS
blob.

So I came up with this idea of having a 2D bitmap in
there to indicate support for (mostly) POT non-square
sizes..

What does everyone think? Is this just getting too
complicated and should we just go with the original
"a list of suppored sizes" approach?

Cc: Simon Ser 
Cc: Jonas Ådahl 
Cc: Daniel Stone 
Cc: Pekka Paalanen 

Ville Syrjälä (3):
  drm: Introduce plane SIZE_HINTS property
  drm/i915: Adjust cursor_size_ok() func calling convention
  drm/i915: Add SIZE_HINTS property for cursors

 drivers/gpu/drm/drm_mode_config.c   |  7 ++
 drivers/gpu/drm/drm_plane.c | 96 +
 drivers/gpu/drm/i915/display/intel_cursor.c | 96 ++---
 include/drm/drm_mode_config.h   |  5 ++
 include/drm/drm_plane.h |  6 ++
 include/uapi/drm/drm_mode.h | 29 +++
 6 files changed, 208 insertions(+), 31 deletions(-)

-- 
2.39.2

Re: [PATCH v10 01/15] dma-buf/dma-fence: Add deadline awareness

[Rob Clark]

On Tue, Mar 21, 2023 at 6:24 AM Jonas Ådahl  wrote:
>
> On Fri, Mar 17, 2023 at 08:59:48AM -0700, Rob Clark wrote:
> > On Fri, Mar 17, 2023 at 3:23 AM Jonas Ådahl  wrote:
> > >
> > > On Thu, Mar 16, 2023 at 09:28:55AM -0700, Rob Clark wrote:
> > > > On Thu, Mar 16, 2023 at 2:26 AM Jonas Ådahl  wrote:
> > > > >
> > > > > On Wed, Mar 15, 2023 at 09:19:49AM -0700, Rob Clark wrote:
> > > > > > On Wed, Mar 15, 2023 at 6:53 AM Jonas Ådahl  
> > > > > > wrote:
> > > > > > >
> > > > > > > On Fri, Mar 10, 2023 at 09:38:18AM -0800, Rob Clark wrote:
> > > > > > > > On Fri, Mar 10, 2023 at 7:45 AM Jonas Ådahl  
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > On Wed, Mar 08, 2023 at 07:52:52AM -0800, Rob Clark wrote:
> > > > > > > > > > From: Rob Clark 
> > > > > > > > > >
> > > > > > > > > > Add a way to hint to the fence signaler of an upcoming 
> > > > > > > > > > deadline, such as
> > > > > > > > > > vblank, which the fence waiter would prefer not to miss.  
> > > > > > > > > > This is to aid
> > > > > > > > > > the fence signaler in making power management decisions, 
> > > > > > > > > > like boosting
> > > > > > > > > > frequency as the deadline approaches and awareness of 
> > > > > > > > > > missing deadlines
> > > > > > > > > > so that can be factored in to the frequency scaling.
> > > > > > > > > >
> > > > > > > > > > v2: Drop dma_fence::deadline and related logic to filter 
> > > > > > > > > > duplicate
> > > > > > > > > > deadlines, to avoid increasing dma_fence size.  The 
> > > > > > > > > > fence-context
> > > > > > > > > > implementation will need similar logic to track 
> > > > > > > > > > deadlines of all
> > > > > > > > > > the fences on the same timeline.  [ckoenig]
> > > > > > > > > > v3: Clarify locking wrt. set_deadline callback
> > > > > > > > > > v4: Clarify in docs comment that this is a hint
> > > > > > > > > > v5: Drop DMA_FENCE_FLAG_HAS_DEADLINE_BIT.
> > > > > > > > > > v6: More docs
> > > > > > > > > > v7: Fix typo, clarify past deadlines
> > > > > > > > > >
> > > > > > > > > > Signed-off-by: Rob Clark 
> > > > > > > > > > Reviewed-by: Christian König 
> > > > > > > > > > Acked-by: Pekka Paalanen 
> > > > > > > > > > Reviewed-by: Bagas Sanjaya 
> > > > > > > > > > ---
> > > > > > > > >
> > > > > > > > > Hi Rob!
> > > > > > > > >
> > > > > > > > > >  Documentation/driver-api/dma-buf.rst |  6 +++
> > > > > > > > > >  drivers/dma-buf/dma-fence.c  | 59 
> > > > > > > > > > 
> > > > > > > > > >  include/linux/dma-fence.h| 22 +++
> > > > > > > > > >  3 files changed, 87 insertions(+)
> > > > > > > > > >
> > > > > > > > > > diff --git a/Documentation/driver-api/dma-buf.rst 
> > > > > > > > > > b/Documentation/driver-api/dma-buf.rst
> > > > > > > > > > index 622b8156d212..183e480d8cea 100644
> > > > > > > > > > --- a/Documentation/driver-api/dma-buf.rst
> > > > > > > > > > +++ b/Documentation/driver-api/dma-buf.rst
> > > > > > > > > > @@ -164,6 +164,12 @@ DMA Fence Signalling Annotations
> > > > > > > > > >  .. kernel-doc:: drivers/dma-buf/dma-fence.c
> > > > > > > > > > :doc: fence signalling annotation
> > > > > > > > > >
> > > > > > > > > > +DMA Fence Deadline Hints
> > > > > > > > > > +
> > > > > > > > > > +
> > > > > > > > > > +.. kernel-doc:: drivers/dma-buf/dma-fence.c
> > > > > > > > > > +   :doc: deadline hints
> > > > > > > > > > +
> > > > > > > > > >  DMA Fences Functions Reference
> > > > > > > > > >  ~~
> > > > > > > > > >
> > > > > > > > > > diff --git a/drivers/dma-buf/dma-fence.c 
> > > > > > > > > > b/drivers/dma-buf/dma-fence.c
> > > > > > > > > > index 0de0482cd36e..f177c56269bb 100644
> > > > > > > > > > --- a/drivers/dma-buf/dma-fence.c
> > > > > > > > > > +++ b/drivers/dma-buf/dma-fence.c
> > > > > > > > > > @@ -912,6 +912,65 @@ dma_fence_wait_any_timeout(struct 
> > > > > > > > > > dma_fence **fences, uint32_t count,
> > > > > > > > > >  }
> > > > > > > > > >  EXPORT_SYMBOL(dma_fence_wait_any_timeout);
> > > > > > > > > >
> > > > > > > > > > +/**
> > > > > > > > > > + * DOC: deadline hints
> > > > > > > > > > + *
> > > > > > > > > > + * In an ideal world, it would be possible to pipeline a 
> > > > > > > > > > workload sufficiently
> > > > > > > > > > + * that a utilization based device frequency governor 
> > > > > > > > > > could arrive at a minimum
> > > > > > > > > > + * frequency that meets the requirements of the use-case, 
> > > > > > > > > > in order to minimize
> > > > > > > > > > + * power consumption.  But in the real world there are 
> > > > > > > > > > many workloads which
> > > > > > > > > > + * defy this ideal.  For example, but not limited to:
> > > > > > > > > > + *
> > > > > > > > > > + * * Workloads that ping-pong between device and CPU, with 
> > > > > > > > > > alternating periods
> > > > > > > > > > + *   of CPU waiting for device, and device waiting on CPU. 
> > > > > > > > > >  This can result in
> > > > > > > > > > + 

Re: [PATCH] drm/meson: fix missing component unbind on bind errors

[Johan Hovold]

On Tue, Mar 21, 2023 at 02:27:08PM +0100, Neil Armstrong wrote:

> Anyway for this patch, sorry for the delay, but it's looks fine:
> 
> Acked-by: Neil Armstrong 

Thanks for reviewing!

Johan

Re: [PATCH v4 1/8] accel/qaic: Add documentation for AIC100 accelerator driver

[Bagas Sanjaya]

On Mon, Mar 20, 2023 at 09:11:07AM -0600, Jeffrey Hugo wrote:
> +AIC100 defines a number of MHI channels for different purposes. This is a 
> list
> +of the defined channels, and their uses.
> +
> +| QAIC_LOOPBACK
> +| Channels 0 & 1
> +| Valid for AMSS
> +| Any data sent to the device on this channel is sent back to the host.
> +
> +| QAIC_SAHARA
> +| Channels 2 & 3
> +| Valid for SBL
> +| Used by SBL to obtain the runtime firmware from the host.
> +
> +| QAIC_DIAG
> +| Channels 4 & 5
> +| Valid for AMSS
> +| Used to communicate with QSM via the Diag protocol.
> +
> +| QAIC_SSR
> +| Channels 6 & 7
> +| Valid for AMSS
> +| Used to notify the host of subsystem restart events, and to offload SSR 
> crashdumps.
> +
> +| QAIC_QDSS
> +| Channels 8 & 9
> +| Valid for AMSS
> +| Used for the Qualcomm Debug Subsystem.
> +
> +| QAIC_CONTROL
> +| Channels 10 & 11
> +| Valid for AMSS
> +| Used for the Neural Network Control (NNC) protocol.  This is the primary 
> channel between host and
> +  QSM for managing workloads.
> +
> +| QAIC_LOGGING
> +| Channels 12 & 13
> +| Valid for SBL
> +| Used by the SBL to send the bootlog to the host.
> +
> +| QAIC_STATUS
> +| Channels 14 & 15
> +| Valid for AMSS
> +| Used to notify the host of Reliability, Accessibility, Serviceability 
> (RAS) events.
> +
> +| QAIC_TELEMETRY
> +| Channels 16 & 17
> +| Valid for AMSS
> +| Used to get/set power/thermal/etc attributes.
> +
> +| QAIC_DEBUG
> +| Channels 18 & 19
> +| Valid for AMSS
> +| Not used.
> +
> +| QAIC_TIMESYNC
> +| Channels 20 & 21
> +| Valid for SBL/AMSS
> +| Used to synchronize timestamps in the device side logs with the host time 
> source.

For the tabular data above, use table syntax instead.

> +A request FIFO element has the following structure:
> +
> +| {
> +|u16 req_id;
> +|u8  seq_id;
> +|u8  pcie_dma_cmd;
> +|u32 reserved;
> +|u64 pcie_dma_source_addr;
> +|u64 pcie_dma_dest_addr;
> +|u32 pcie_dma_len;
> +|u32 reserved;
> +|u64 doorbell_addr;
> +|u8  doorbell_attr;
> +|u8  reserved;
> +|u16 reserved;
> +|u32 doorbell_data;
> +|u32 sem_cmd0;
> +|u32 sem_cmd1;
> +|u32 sem_cmd2;
> +|u32 sem_cmd3;
> +| }

IMO code blocks should better fit the struct listing above.

> +
> +Request field descriptions:
> +
> +| req_id- request ID. A request FIFO element and a response FIFO element with
> +| the same request ID refer to the same command.
> +
> +| seq_id- sequence ID within a request. Ignored by the DMA Bridge.
> +
> +| pcie_dma_cmd- describes the DMA element of this request.
> +|Bit(7) is the force msi flag, which overrides the DMA Bridge MSI logic
> +|and generates a MSI when this request is complete, and QSM
> +|configures the DMA Bridge to look at this bit.
> +|Bits(6:5) are reserved.
> +|Bit(4) is the completion code flag, and indicates that the DMA Bridge
> +|shall generate a response FIFO element when this request is
> +|complete.
> +|Bit(3) indicates if this request is a linked list transfer(0) or a bulk
> +|transfer(1).
> +|Bit(2) is reserved.
> +|Bits(1:0) indicate the type of transfer. No transfer(0), to device(1),
> +|from device(2). Value 3 is illegal.
> +
> +| pcie_dma_source_addr- source address for a bulk transfer, or the address of
> +| the linked list.
> +
> +| pcie_dma_dest_addr- destination address for a bulk transfer.
> +
> +| pcie_dma_len- length of the bulk transfer. Note that the size of this field
> +|limits transfers to 4G in size.
> +
> +| doorbell_addr- address of the doorbell to ring when this request is 
> complete.
> +
> +| doorbell_attr- doorbell attributes.
> +|Bit(7) indicates if a write to a doorbell is to occur.
> +|Bits(6:2) are reserved.
> +|Bits(1:0) contain the encoding of the doorbell length. 0 is 32-bit,
> +|1 is 16-bit, 2 is 8-bit, 3 is reserved. The doorbell address
> +|must be naturally aligned to the specified length.
> +
> +| doorbell_data- data to write to the doorbell. Only the bits corresponding 
> to
> +|the doorbell length are valid.
> +
> +| sem_cmdN- semaphore command.
> +|Bit(31) indicates this semaphore command is enabled.
> +|Bit(30) is the to-device DMA fence. Block this request until all
> +|to-device DMA transfers are complete.
> +|Bit(29) is the from-device DMA fence. Block this request until all
> +|from-device DMA transfers are complete.
> +|Bits(28:27) are reserved.
> +|Bits(26:24) are the semaphore command. 0 is NOP. 1 is init with the
> +|specified value. 2 is increment. 3 is decrement. 4 is wait
> +|until the semaphore is equal to the specified value. 5 is wait
> +|until the semaphore is greater or equal to the specified value.
> +|6 is "P", wait until semaphore is greater than 0, then
> +|decrement by 1. 7 is reserved.
> +|Bit(23) is 

Re: [PATCH] drm/meson: fix missing component unbind on bind errors

[Neil Armstrong]

On 21/03/2023 14:14, Johan Hovold wrote:

On Thu, Mar 09, 2023 at 10:41:18PM +0100, Martin Blumenstingl wrote:


On Mon, Mar 6, 2023 at 11:35 AM Johan Hovold  wrote:
[...]

@@ -325,23 +325,23 @@ static int meson_drv_bind_master(struct device *dev, bool 
has_components)

 ret = meson_encoder_hdmi_init(priv);



I'm wondering if component_bind_all() can be moved further down.
Right now it's between meson_encoder_cvbs_init() and
meson_encoder_hdmi_init(). So it seems that encoders don't rely on
component registration.


Perhaps it can, but that would be a separate change (unless there is
something inherently wrong with the current initialisation order).


The CVBS doesn't rely on any components unlike HDMI, this explains the
current position of component_bind_all().

  

Unfortunately I am also not familiar with this and I'm hoping that
Neil can comment on this.


Any comments on this one, Neil?


Yep, components should be bind for HDMI encoder/bridge init.

Anyway for this patch, sorry for the delay, but it's looks fine:

Acked-by: Neil Armstrong 



Johan

Re: [PATCH v10 01/15] dma-buf/dma-fence: Add deadline awareness

[Jonas Ådahl]

On Fri, Mar 17, 2023 at 08:59:48AM -0700, Rob Clark wrote:
> On Fri, Mar 17, 2023 at 3:23 AM Jonas Ådahl  wrote:
> >
> > On Thu, Mar 16, 2023 at 09:28:55AM -0700, Rob Clark wrote:
> > > On Thu, Mar 16, 2023 at 2:26 AM Jonas Ådahl  wrote:
> > > >
> > > > On Wed, Mar 15, 2023 at 09:19:49AM -0700, Rob Clark wrote:
> > > > > On Wed, Mar 15, 2023 at 6:53 AM Jonas Ådahl  wrote:
> > > > > >
> > > > > > On Fri, Mar 10, 2023 at 09:38:18AM -0800, Rob Clark wrote:
> > > > > > > On Fri, Mar 10, 2023 at 7:45 AM Jonas Ådahl  
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > On Wed, Mar 08, 2023 at 07:52:52AM -0800, Rob Clark wrote:
> > > > > > > > > From: Rob Clark 
> > > > > > > > >
> > > > > > > > > Add a way to hint to the fence signaler of an upcoming 
> > > > > > > > > deadline, such as
> > > > > > > > > vblank, which the fence waiter would prefer not to miss.  
> > > > > > > > > This is to aid
> > > > > > > > > the fence signaler in making power management decisions, like 
> > > > > > > > > boosting
> > > > > > > > > frequency as the deadline approaches and awareness of missing 
> > > > > > > > > deadlines
> > > > > > > > > so that can be factored in to the frequency scaling.
> > > > > > > > >
> > > > > > > > > v2: Drop dma_fence::deadline and related logic to filter 
> > > > > > > > > duplicate
> > > > > > > > > deadlines, to avoid increasing dma_fence size.  The 
> > > > > > > > > fence-context
> > > > > > > > > implementation will need similar logic to track deadlines 
> > > > > > > > > of all
> > > > > > > > > the fences on the same timeline.  [ckoenig]
> > > > > > > > > v3: Clarify locking wrt. set_deadline callback
> > > > > > > > > v4: Clarify in docs comment that this is a hint
> > > > > > > > > v5: Drop DMA_FENCE_FLAG_HAS_DEADLINE_BIT.
> > > > > > > > > v6: More docs
> > > > > > > > > v7: Fix typo, clarify past deadlines
> > > > > > > > >
> > > > > > > > > Signed-off-by: Rob Clark 
> > > > > > > > > Reviewed-by: Christian König 
> > > > > > > > > Acked-by: Pekka Paalanen 
> > > > > > > > > Reviewed-by: Bagas Sanjaya 
> > > > > > > > > ---
> > > > > > > >
> > > > > > > > Hi Rob!
> > > > > > > >
> > > > > > > > >  Documentation/driver-api/dma-buf.rst |  6 +++
> > > > > > > > >  drivers/dma-buf/dma-fence.c  | 59 
> > > > > > > > > 
> > > > > > > > >  include/linux/dma-fence.h| 22 +++
> > > > > > > > >  3 files changed, 87 insertions(+)
> > > > > > > > >
> > > > > > > > > diff --git a/Documentation/driver-api/dma-buf.rst 
> > > > > > > > > b/Documentation/driver-api/dma-buf.rst
> > > > > > > > > index 622b8156d212..183e480d8cea 100644
> > > > > > > > > --- a/Documentation/driver-api/dma-buf.rst
> > > > > > > > > +++ b/Documentation/driver-api/dma-buf.rst
> > > > > > > > > @@ -164,6 +164,12 @@ DMA Fence Signalling Annotations
> > > > > > > > >  .. kernel-doc:: drivers/dma-buf/dma-fence.c
> > > > > > > > > :doc: fence signalling annotation
> > > > > > > > >
> > > > > > > > > +DMA Fence Deadline Hints
> > > > > > > > > +
> > > > > > > > > +
> > > > > > > > > +.. kernel-doc:: drivers/dma-buf/dma-fence.c
> > > > > > > > > +   :doc: deadline hints
> > > > > > > > > +
> > > > > > > > >  DMA Fences Functions Reference
> > > > > > > > >  ~~
> > > > > > > > >
> > > > > > > > > diff --git a/drivers/dma-buf/dma-fence.c 
> > > > > > > > > b/drivers/dma-buf/dma-fence.c
> > > > > > > > > index 0de0482cd36e..f177c56269bb 100644
> > > > > > > > > --- a/drivers/dma-buf/dma-fence.c
> > > > > > > > > +++ b/drivers/dma-buf/dma-fence.c
> > > > > > > > > @@ -912,6 +912,65 @@ dma_fence_wait_any_timeout(struct 
> > > > > > > > > dma_fence **fences, uint32_t count,
> > > > > > > > >  }
> > > > > > > > >  EXPORT_SYMBOL(dma_fence_wait_any_timeout);
> > > > > > > > >
> > > > > > > > > +/**
> > > > > > > > > + * DOC: deadline hints
> > > > > > > > > + *
> > > > > > > > > + * In an ideal world, it would be possible to pipeline a 
> > > > > > > > > workload sufficiently
> > > > > > > > > + * that a utilization based device frequency governor could 
> > > > > > > > > arrive at a minimum
> > > > > > > > > + * frequency that meets the requirements of the use-case, in 
> > > > > > > > > order to minimize
> > > > > > > > > + * power consumption.  But in the real world there are many 
> > > > > > > > > workloads which
> > > > > > > > > + * defy this ideal.  For example, but not limited to:
> > > > > > > > > + *
> > > > > > > > > + * * Workloads that ping-pong between device and CPU, with 
> > > > > > > > > alternating periods
> > > > > > > > > + *   of CPU waiting for device, and device waiting on CPU.  
> > > > > > > > > This can result in
> > > > > > > > > + *   devfreq and cpufreq seeing idle time in their 
> > > > > > > > > respective domains and in
> > > > > > > > > + *   result reduce frequency.
> > > > > > > > > + *
> > > > > > > > > + * * Workloads that interact with a periodic time based 
> > > > > > > > > 

Re: [PATCH] drm/meson: fix missing component unbind on bind errors

[Johan Hovold]

On Thu, Mar 09, 2023 at 10:41:18PM +0100, Martin Blumenstingl wrote:

> On Mon, Mar 6, 2023 at 11:35 AM Johan Hovold  wrote:
> [...]
> > @@ -325,23 +325,23 @@ static int meson_drv_bind_master(struct device *dev, 
> > bool has_components)
> >
> > ret = meson_encoder_hdmi_init(priv);

> I'm wondering if component_bind_all() can be moved further down.
> Right now it's between meson_encoder_cvbs_init() and
> meson_encoder_hdmi_init(). So it seems that encoders don't rely on
> component registration.

Perhaps it can, but that would be a separate change (unless there is
something inherently wrong with the current initialisation order).
 
> Unfortunately I am also not familiar with this and I'm hoping that
> Neil can comment on this.

Any comments on this one, Neil?

Johan

Re: display band (display area vs real visible area)

[Michael Nazzareno Trimarchi]

Hi Daniel

On Tue, Mar 21, 2023 at 1:15 PM Daniel Stone  wrote:
>
> Hi,
>
> On Tue, 21 Mar 2023 at 12:08, Jani Nikula  wrote:
> > On Tue, 21 Mar 2023, Daniel Stone  wrote:
> > > There have been some threads - mostly motivated by MacBooks and the
> > > Asahi team - about creating a KMS property to express invisible areas.
> > > This would be the same thing, and the userspace ecosystem will pick it
> > > up when the kernel exposes it.
> >
> > In my case the kernel handled it completely internally, and the
> > userspace didn't even know. But I guess it depends on the display being
> > able to take a smaller framebuffer, otherwise I don't think it's
> > feasible.
> >
> > I haven't checked the threads you mention but I assume it covers the
> > more general case of having rounded corners or holes for the camera, not
> > just the frame covering the edges or something like that. That couldn't
> > possibly be handled by kernel alone, but it's also a bunch of
> > infrastructure work both in kernel and userspace to make it happen.
>
> Yeah, exactly. Just a connector property, which could come from DT or
> ACPI or manual overrides or whatever. Userspace would still allocate a
> full-size framebuffer, but look at that property and not render
> anything useful into those areas. In the camera/notch case, it's a
> matter of not putting useful content there. In the letterbox/pillarbox
> case, it's about shrinking the reported screen size so that window
> management, clients, etc, all believe that the screen is smaller than
> it is.

So it's up to wayland or compositor to take account of the side band,
including touch controller.
Am I right?

Michael
>
> Cheers,
> Daniel

Re: [PATCH v2 00/21] Enable Colorspace connector property in amdgpu

[Sebastian Wick]

FWIW, I still think this series is good (minus the UAPI changes) and
would allow us to work on user space HDR support without custom
kernels.

On Fri, Jan 13, 2023 at 5:24 PM Harry Wentland  wrote:
>
> This patchset enables the DP and HDMI infoframe properties
> in amdgpu.
>
> The first two patches are not completely related to the rest. The
> first patch allows for HDR_OUTPUT_METADATA with EOTFs that are
> unknown in the kernel.
>
> The second one prints a connector's max_bpc as part of the atomic
> state debugfs print.
>
> The following patches rework the connector colorspace code to
> 1) allow for easy printing of the colorspace in the drm_atomic
>state debugfs, and
> 2) allow drivers to specify the supported colorspaces on a
>connector.
>
> The rest of the patches deal with the Colorspace enablement
> in amdgpu.
>
> Why do drivers need to specify supported colorspaces? The amdgpu
> driver needs support for RGB-to-YCbCr conversion when we drive
> the display in YCbCr. This is currently not implemented for all
> colorspaces.
>
> Since the Colorspace property didn't have an IGT test I added
> one to kms_hdr. The relevant patchset can be found on the IGT
> mailing list or on
> https://gitlab.freedesktop.org/hwentland/igt-gpu-tools/-/tree/hdr-colorimetry
>
> We tested v1 of the patchset and confirmed that the infoframes
> are as expected for both DP and HDMI when running the IGT
> colorimetry tests.
>
> Open Items
> --
>
> A couple comments from Pekka about colorspace documentation are
> left unaddressed. I hope they won't block merging this set but
> should still be addressed separately.
>
> Pekka's questions really got me thinking of how this colorspace
> property should be used and working with it more closely with
> Joshua who is enabling HDR in gamescope made me wonder even more.
>
> Uma, is there a (canonical, upstream) userspace that uses this
> property that I can look at to understand more?
>
> One of the key challenges that is currently not addressed is that
> userspace is expected to pick a colorspace format straight from the
> list of definitions out of the DP or HDMI spec. But the kernel
> driver are the ones deciding on the output encoding (RGB, YCBCR444,
> YCBCR420, etc.). So there is no way for userspace to decide correctly
> between, for example, BT2020_RGB, BT2020_CYCC, BT2020_YCC.
>
> So we end up in a scenario where gamescope sets BT2020_RGB but we
> output YCBCR444 so have to correct the colorspace value to
> BT2020_YCC. This in turn breaks the colorspace IGT tests I
> wrote. I don't think "fixing" the IGT tests to accept this is
> the right thing to do.
>
> The way it stands this patchset allows us to specify the output
> colorspace on amdgpu and we try to do the right thing, but I don't
> thing the way the colorspace property is defined is right. We're trying
> to expose things to userspace that should be under driver control. A
> much better approach would be to give userspace options for colorspace
> that are not tied to DP or HDMI specs, i.e., sRGB, BT709, BT2020, etc.,
> and have the driver do the right thing to fill the infoframe, e.g., by
> picking BT2020_YCC if the requested colorspace is BT2020 and the
> is YCBCR444.
>
> If no upstream userspace currently makes use of this property I
> can make that change, i.e., no longer tie the colorspace property
> directly to the infoframe and reduce the options to sRGB, BT709,
> BT601, and BT2020 (and possibly opRGB).
>
> v2:
> - Tested with DP and HDMI analyzers
> - Confirmed driver will fallback to lower bpc when needed
> - Dropped hunk to set HDMI AVI infoframe as it was a no-op
> - Fixed BT.2020 YCbCr colorimetry (JoshuaAshton)
> - Simplify initialization of supported colorspaces (Jani)
> - Fix kerneldoc (kernel test robot)
>
> Cc: Pekka Paalanen 
> Cc: Sebastian Wick 
> Cc: vitaly.pros...@amd.com
> Cc: Uma Shankar 
> Cc: Ville Syrjälä 
> Cc: Joshua Ashton 
> Cc: Jani Nikula 
> Cc: Michel Dänzer 
> Cc: dri-devel@lists.freedesktop.org
> Cc: amd-...@lists.freedesktop.org
>
> Harry Wentland (16):
>   drm/display: Don't block HDR_OUTPUT_METADATA on unknown EOTF
>   drm/connector: print max_requested_bpc in state debugfs
>   drm/connector: Drop COLORIMETRY_NO_DATA
>   drm/connector: Convert DRM_MODE_COLORIMETRY to enum
>   drm/connector: Pull out common create_colorspace_property code
>   drm/connector: Allow drivers to pass list of supported colorspaces
>   drm/connector: Print connector colorspace in state debugfs
>   drm/amd/display: Always pass connector_state to stream validation
>   drm/amd/display: Register Colorspace property for DP and HDMI
>   drm/amd/display: Signal mode_changed if colorspace changed
>   drm/amd/display: Send correct DP colorspace infopacket
>   drm/amd/display: Add support for explicit BT601_YCC
>   drm/amd/display: Add debugfs for testing output colorspace
>   drm/amd/display: Add default case for output_color_space switch
>   drm/amd/display: Don't restrict bpc to 8 bpc
>   drm/amd/display: 

Re: stable-rc/linux-5.10.y bisection: baseline.login on hp-x360-14-G1-sona

[Greg Kroah-Hartman]

On Tue, Mar 21, 2023 at 12:58:22PM +, Mark Brown wrote:
> On Tue, Mar 21, 2023 at 05:18:03AM -0700, KernelCI bot wrote:
> 
> The KernelCI bisection bot found a boot bisection on one of the HP
> ChromeBooks in v5.10.175 triggered by b5005605013d ("drm/i915: Don't use
> BAR mappings for ring buffers with LLC").  The system appears to die
> very early in boot with no output.

Should be fixed in the 5.10-rc that is out for review right now.

thanks,

greg k-h

Re: [PATCH 00/10] drm/msm: fix bind error handling

[Johan Hovold]

On Mon, Mar 06, 2023 at 11:07:12AM +0100, Johan Hovold wrote:
> I had reasons to look closer at the MSM DRM driver error handling and
> realised that it had suffered from a fair amount of bit rot over the
> years.
> 
> Unfortunately, I started fixing this in my 6.2 branch and failed to
> notice two partial and, as it turned out, broken attempts to address
> this that are now in 6.3-rc1.
> 
> Instead of trying to salvage this incrementally, I'm reverting the two
> broken commits so that clean and backportable fixes can be added in
> their place.
> 
> Included are also two related cleanups.

Any further comments to these patches (except for 9/10, which should be
dropped)?

As the patches being reverted here were first added in 6.3-rc1 there is
still time to get this into 6.3-rc (e.g. before AUTOSEL starts trying to
backport them).

Johan

> Johan Hovold (10):
>   Revert "drm/msm: Add missing check and destroy for
> alloc_ordered_workqueue"
>   Revert "drm/msm: Fix failure paths in msm_drm_init()"
>   drm/msm: fix NULL-deref on snapshot tear down
>   drm/msm: fix NULL-deref on irq uninstall
>   drm/msm: fix drm device leak on bind errors
>   drm/msm: fix vram leak on bind errors
>   drm/msm: fix missing wq allocation error handling
>   drm/msm: fix workqueue leak on bind errors
>   drm/msm: use drmm_mode_config_init()
>   drm/msm: move include directive
> 
>  drivers/gpu/drm/msm/disp/msm_disp_snapshot.c |  3 -
>  drivers/gpu/drm/msm/msm_drv.c| 67 +---
>  2 files changed, 44 insertions(+), 26 deletions(-)

Re: stable-rc/linux-5.10.y bisection: baseline.login on hp-x360-14-G1-sona

[Mark Brown]

On Tue, Mar 21, 2023 at 05:18:03AM -0700, KernelCI bot wrote:

The KernelCI bisection bot found a boot bisection on one of the HP
ChromeBooks in v5.10.175 triggered by b5005605013d ("drm/i915: Don't use
BAR mappings for ring buffers with LLC").  The system appears to die
very early in boot with no output.

I've left the full report from the bot below, including links to full
boot logs such as they are and a tag for the bot, and the full web
dashboard for the test case fail is at:

https://linux.kernelci.org/test/plan/id/64147346939869e04b8c8694/

including details of the successful test on v5.10.174.

> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
> * This automated bisection report was sent to you on the basis  *
> * that you may be involved with the breaking commit it has  *
> * found.  No manual investigation has been done to verify it,   *
> * and the root cause of the problem may be somewhere else.  *
> *   *
> * If you do send a fix, please include this trailer:*
> *   Reported-by: "kernelci.org bot"   *
> *   *
> * Hope this helps!  *
> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
> 
> stable-rc/linux-5.10.y bisection: baseline.login on hp-x360-14-G1-sona
> 
> Summary:
>   Start:  de26e1b2103b Linux 5.10.175
>   Plain log:  
> https://storage.kernelci.org/stable-rc/linux-5.10.y/v5.10.175/x86_64/x86_64_defconfig+x86-chromebook/gcc-10/lab-collabora/baseline-hp-x360-14-G1-sona.txt
>   HTML log:   
> https://storage.kernelci.org/stable-rc/linux-5.10.y/v5.10.175/x86_64/x86_64_defconfig+x86-chromebook/gcc-10/lab-collabora/baseline-hp-x360-14-G1-sona.html
>   Result: b5005605013d drm/i915: Don't use BAR mappings for ring buffers 
> with LLC
> 
> Checks:
>   revert: PASS
>   verify: PASS
> 
> Parameters:
>   Tree:   stable-rc
>   URL:
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
>   Branch: linux-5.10.y
>   Target: hp-x360-14-G1-sona
>   CPU arch:   x86_64
>   Lab:lab-collabora
>   Compiler:   gcc-10
>   Config: x86_64_defconfig+x86-chromebook
>   Test case:  baseline.login
> 
> Breaking commit found:
> 
> ---
> commit b5005605013d30ab27c303cbaeff60b7872234a3
> Author: John Harrison 
> Date:   Wed Feb 15 17:11:01 2023 -0800
> 
> drm/i915: Don't use BAR mappings for ring buffers with LLC
> 
> commit 85636167e3206c3fbd52254fc432991cc4e90194 upstream.
> 
> Direction from hardware is that ring buffers should never be mapped
> via the BAR on systems with LLC. There are too many caching pitfalls
> due to the way BAR accesses are routed. So it is safest to just not
> use it.
> 
> Signed-off-by: John Harrison 
> Fixes: 9d80841ea4c9 ("drm/i915: Allow ringbuffers to be bound anywhere")
> Cc: Chris Wilson 
> Cc: Joonas Lahtinen 
> Cc: Jani Nikula 
> Cc: Rodrigo Vivi 
> Cc: Tvrtko Ursulin 
> Cc: intel-...@lists.freedesktop.org
> Cc:  # v4.9+
> Tested-by: Jouni Högander 
> Reviewed-by: Daniele Ceraolo Spurio 
> Link: 
> https://patchwork.freedesktop.org/patch/msgid/20230216011101.1909009-3-john.c.harri...@intel.com
> (cherry picked from commit 65c08339db1ada87afd6cfe7db8e60bb4851d919)
> Signed-off-by: Jani Nikula 
> Signed-off-by: John Harrison 
> Signed-off-by: Greg Kroah-Hartman 
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_ring.c 
> b/drivers/gpu/drm/i915/gt/intel_ring.c
> index 4034a4bac7f0..69b2e5509d67 100644
> --- a/drivers/gpu/drm/i915/gt/intel_ring.c
> +++ b/drivers/gpu/drm/i915/gt/intel_ring.c
> @@ -49,7 +49,7 @@ int intel_ring_pin(struct intel_ring *ring, struct 
> i915_gem_ww_ctx *ww)
>   if (unlikely(ret))
>   goto err_unpin;
>  
> - if (i915_vma_is_map_and_fenceable(vma))
> + if (i915_vma_is_map_and_fenceable(vma) && !HAS_LLC(vma->vm->i915))
>   addr = (void __force *)i915_vma_pin_iomap(vma);
>   else
>   addr = i915_gem_object_pin_map(vma->obj,
> @@ -91,7 +91,7 @@ void intel_ring_unpin(struct intel_ring *ring)
>   return;
>  
>   i915_vma_unset_ggtt_write(vma);
> - if (i915_vma_is_map_and_fenceable(vma))
> + if (i915_vma_is_map_and_fenceable(vma) && !HAS_LLC(vma->vm->i915))
>   i915_vma_unpin_iomap(vma);
>   else
>   i915_gem_object_unpin_map(vma->obj);
> ---
> 
> 
> Git bisection log:
> 
> ---
> git bisect start
> # good: [955623617f2f505ac08d0efda2bb50c1a52e2c96] Linux 5.10.174
> git bisect good 955623617f2f505ac08d0efda2bb50c1a52e2c96
> # bad: 

Re: [PATCH 2/3] drm/vmwgfx: Print errors when running on broken/unsupported configs

[Martin Krastev (VMware)]

From: Martin Krastev 


LGTM!

Reviewed-by: Martin Krastev 


Regards,

Martin


On 21.03.23 г. 4:09 ч., Zack Rusin wrote:

From: Zack Rusin 

virtualbox implemented an incomplete version of the svga device which
they decided to drop soon after the initial release. The device was
always broken in various ways and never supported by vmwgfx.

vmwgfx should refuse to load on those configurations but currently
drm has no way of reloading fbdev when the specific pci driver refuses
to load, which would leave users without a usable fb. Instead of
refusing to load print an error and disable a bunch of functionality
that virtualbox never implemented to at least get fb to work on their
setup.

Signed-off-by: Zack Rusin 
---
  drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 29 +
  drivers/gpu/drm/vmwgfx/vmwgfx_drv.h |  2 ++
  drivers/gpu/drm/vmwgfx/vmwgfx_msg.c |  9 +
  3 files changed, 40 insertions(+)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index 2588615a2a38..8b24ecf60e3e 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -45,6 +45,9 @@
  #include 
  #include 
  
+#ifdef CONFIG_X86

+#include 
+#endif
  #include 
  #include 
  #include 
@@ -897,6 +900,16 @@ static int vmw_driver_load(struct vmw_private *dev_priv, 
u32 pci_id)
 cap2_names, ARRAY_SIZE(cap2_names));
}
  
+	if (!vmwgfx_supported(dev_priv)) {

+   vmw_disable_backdoor();
+   drm_err_once(_priv->drm,
+"vmwgfx seems to be running on an unsupported 
hypervisor.");
+   drm_err_once(_priv->drm,
+"This configuration is likely broken.");
+   drm_err_once(_priv->drm,
+"Please switch to a supported graphics device to avoid 
problems.");
+   }
+
ret = vmw_dma_select_mode(dev_priv);
if (unlikely(ret != 0)) {
drm_info(_priv->drm,
@@ -1320,6 +1333,22 @@ static void vmw_master_drop(struct drm_device *dev,
vmw_kms_legacy_hotspot_clear(dev_priv);
  }
  
+bool vmwgfx_supported(struct vmw_private *vmw)

+{
+#if defined(CONFIG_X86)
+   return hypervisor_is_type(X86_HYPER_VMWARE);
+#elif defined(CONFIG_ARM64)
+   /*
+* On aarch64 only svga3 is supported
+*/
+   return vmw->pci_id == VMWGFX_PCI_ID_SVGA3;
+#else
+   drm_warn_once(>drm,
+ "vmwgfx is running on an unknown architecture.");
+   return false;
+#endif
+}
+
  /**
   * __vmw_svga_enable - Enable SVGA mode, FIFO and use of VRAM.
   *
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h 
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
index fb8f0c0642c0..3810a9984a7f 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
@@ -773,6 +773,7 @@ static inline u32 vmw_max_num_uavs(struct vmw_private 
*dev_priv)
  
  extern void vmw_svga_enable(struct vmw_private *dev_priv);

  extern void vmw_svga_disable(struct vmw_private *dev_priv);
+bool vmwgfx_supported(struct vmw_private *vmw);
  
  
  /**

@@ -1358,6 +1359,7 @@ int vmw_bo_cpu_blit(struct ttm_buffer_object *dst,
struct vmw_diff_cpy *diff);
  
  /* Host messaging -vmwgfx_msg.c: */

+void vmw_disable_backdoor(void);
  int vmw_host_get_guestinfo(const char *guest_info_param,
   char *buffer, size_t *length);
  __printf(1, 2) int vmw_host_printf(const char *fmt, ...);
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c
index ca1a3fe44fa5..2651fe0ef518 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c
@@ -1179,3 +1179,12 @@ int vmw_mksstat_remove_ioctl(struct drm_device *dev, 
void *data,
  
  	return -EAGAIN;

  }
+
+/**
+ * vmw_disable_backdoor: Disables all backdoor communication
+ * with the hypervisor.
+ */
+void vmw_disable_backdoor(void)
+{
+   vmw_msg_enabled = 0;
+}

Re: [PATCH v2 0/4] drm/msm/adreno: fix runtime PM imbalance at unbind

[Johan Hovold]

On Fri, Mar 03, 2023 at 05:48:03PM +0100, Johan Hovold wrote:
> As reported by Bjorn, we can end up with an unbalanced runtime PM
> disable count if unbind() is called before the DRM device is opened
> (e.g. if component bind fails due to the panel driver not having been
> loaded yet).
> 
> As runtime PM must currently stay disabled until the firmware has been
> loaded, fix this by making the runtime PM disable call at unbind()
> conditional.
> 
> The rest of the series fixes further imbalances in the load_gpu() error
> paths and removes a bogus pm_runtime_set_active() call. Included is also
> a related indentation cleanup.

I noticed that Rob picked up the first patch below from v1 of this
series. Any comments to the remaining three?

Johan

> Changes in v2
>  - fix the runtime PM imbalance in the gpu load error paths (new)
> 
>  - drop the patch removing the pm_runtime_disable() from
>adreno_gpu_cleanup() as this function can currently still be called
>with runtime PM enabled if suspending the scheduler in
>adreno_system_suspend() at unbind fails
> 
> 
> Johan Hovold (4):
>   drm/msm/adreno: fix runtime PM imbalance at unbind
>   drm/msm/adreno: fix runtime PM imbalance at gpu load
>   drm/msm/adreno: drop bogus pm_runtime_set_active()
>   drm/msm/adreno: clean up component ops indentation
> 
>  drivers/gpu/drm/msm/adreno/adreno_device.c | 26 +-
>  1 file changed, 16 insertions(+), 10 deletions(-)

Re: [PATCH 1/2] dt-bindings: drm/bridge: Add no-hpd property

[Krzysztof Kozlowski]

On 21/03/2023 13:02, Jayesh Choudhary wrote:
>>
>>> +type: boolean
>>> +description:
>>> +  Set if the HPD line on the bridge isn't hooked up to anything or is
>>> +  otherwise unusable.
>>
>> It's the property of the panel, not bridge. Unless you want to say that
>> bridge physically does not have HPD? Does it follow the standard in such
>> case?
> 
> MHDP does have hpd. But the mhdp driver should handle the cases when the

This is about bindings, not driver. Your driver can still handle this as
it wishes.

> hpd pin of bridge is not connected to that of the DP-connector. This is 
> to add support for that. (optional property)

Which is indicated by panel no-hpd, right? Or you mean now that HPD
physically cannot go to panel because it is cut on the bridge side? But
isn't this the same case (from hardware/bindings point, not driver) as
panel would not have HPD?


Best regards,
Krzysztof

[PATCH v30 3/7] drm/mediatek: add ovl_adaptor support for MT8195

[Nancy . Lin]

Add ovl_adaptor driver for MT8195.
Ovl_adaptor is an encapsulated module and designed for simplified
DRM control flow. This module is composed of 8 RDMAs, 4 MERGEs and
an ETHDR. Two RDMAs merge into one layer, so this module support 4
layers.

Signed-off-by: Nancy.Lin 
Reviewed-by: Chun-Kuang Hu 
Reviewed-by: AngeloGioacchino Del Regno 

Tested-by: AngeloGioacchino Del Regno 
Tested-by: Bo-Chen Chen 
---
 drivers/gpu/drm/mediatek/Makefile |   1 +
 drivers/gpu/drm/mediatek/mtk_disp_drv.h   |  26 +
 .../gpu/drm/mediatek/mtk_disp_ovl_adaptor.c   | 533 ++
 drivers/gpu/drm/mediatek/mtk_drm_drv.h|   1 +
 4 files changed, 561 insertions(+)
 create mode 100644 drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c

diff --git a/drivers/gpu/drm/mediatek/Makefile 
b/drivers/gpu/drm/mediatek/Makefile
index 840f14436d3c..d4d193f60271 100644
--- a/drivers/gpu/drm/mediatek/Makefile
+++ b/drivers/gpu/drm/mediatek/Makefile
@@ -6,6 +6,7 @@ mediatek-drm-y := mtk_disp_aal.o \
  mtk_disp_gamma.o \
  mtk_disp_merge.o \
  mtk_disp_ovl.o \
+ mtk_disp_ovl_adaptor.o \
  mtk_disp_rdma.o \
  mtk_drm_crtc.o \
  mtk_drm_ddp_comp.o \
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_drv.h 
b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
index 33e61a136bbc..654f8e257984 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
+++ b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
@@ -7,6 +7,8 @@
 #define _MTK_DISP_DRV_H_
 
 #include 
+#include 
+#include 
 #include "mtk_drm_plane.h"
 #include "mtk_mdp_rdma.h"
 
@@ -116,6 +118,30 @@ void mtk_rdma_unregister_vblank_cb(struct device *dev);
 void mtk_rdma_enable_vblank(struct device *dev);
 void mtk_rdma_disable_vblank(struct device *dev);
 
+void mtk_ovl_adaptor_add_comp(struct device *dev, struct mtk_mutex *mutex);
+void mtk_ovl_adaptor_remove_comp(struct device *dev, struct mtk_mutex *mutex);
+void mtk_ovl_adaptor_connect(struct device *dev, struct device *mmsys_dev,
+unsigned int next);
+void mtk_ovl_adaptor_disconnect(struct device *dev, struct device *mmsys_dev,
+   unsigned int next);
+int mtk_ovl_adaptor_clk_enable(struct device *dev);
+void mtk_ovl_adaptor_clk_disable(struct device *dev);
+void mtk_ovl_adaptor_config(struct device *dev, unsigned int w,
+   unsigned int h, unsigned int vrefresh,
+   unsigned int bpc, struct cmdq_pkt *cmdq_pkt);
+void mtk_ovl_adaptor_layer_config(struct device *dev, unsigned int idx,
+ struct mtk_plane_state *state,
+ struct cmdq_pkt *cmdq_pkt);
+void mtk_ovl_adaptor_register_vblank_cb(struct device *dev, void 
(*vblank_cb)(void *),
+   void *vblank_cb_data);
+void mtk_ovl_adaptor_unregister_vblank_cb(struct device *dev);
+void mtk_ovl_adaptor_enable_vblank(struct device *dev);
+void mtk_ovl_adaptor_disable_vblank(struct device *dev);
+void mtk_ovl_adaptor_start(struct device *dev);
+void mtk_ovl_adaptor_stop(struct device *dev);
+unsigned int mtk_ovl_adaptor_layer_nr(struct device *dev);
+struct device *mtk_ovl_adaptor_dma_dev_get(struct device *dev);
+
 int mtk_mdp_rdma_clk_enable(struct device *dev);
 void mtk_mdp_rdma_clk_disable(struct device *dev);
 void mtk_mdp_rdma_start(struct device *dev, struct cmdq_pkt *cmdq_pkt);
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c 
b/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
new file mode 100644
index ..046217828ab3
--- /dev/null
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
@@ -0,0 +1,533 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2021 MediaTek Inc.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "mtk_disp_drv.h"
+#include "mtk_drm_crtc.h"
+#include "mtk_drm_ddp_comp.h"
+#include "mtk_drm_drv.h"
+#include "mtk_ethdr.h"
+
+#define MTK_OVL_ADAPTOR_RDMA_MAX_WIDTH 1920
+#define MTK_OVL_ADAPTOR_LAYER_NUM 4
+
+enum mtk_ovl_adaptor_comp_type {
+   OVL_ADAPTOR_TYPE_RDMA = 0,
+   OVL_ADAPTOR_TYPE_MERGE,
+   OVL_ADAPTOR_TYPE_ETHDR,
+   OVL_ADAPTOR_TYPE_NUM,
+};
+
+enum mtk_ovl_adaptor_comp_id {
+   OVL_ADAPTOR_MDP_RDMA0,
+   OVL_ADAPTOR_MDP_RDMA1,
+   OVL_ADAPTOR_MDP_RDMA2,
+   OVL_ADAPTOR_MDP_RDMA3,
+   OVL_ADAPTOR_MDP_RDMA4,
+   OVL_ADAPTOR_MDP_RDMA5,
+   OVL_ADAPTOR_MDP_RDMA6,
+   OVL_ADAPTOR_MDP_RDMA7,
+   OVL_ADAPTOR_MERGE0,
+   OVL_ADAPTOR_MERGE1,
+   OVL_ADAPTOR_MERGE2,
+   OVL_ADAPTOR_MERGE3,
+   OVL_ADAPTOR_ETHDR0,
+   OVL_ADAPTOR_ID_MAX
+};
+
+struct ovl_adaptor_comp_match {
+   enum mtk_ovl_adaptor_comp_type type;
+   int alias_id;
+};
+
+struct mtk_disp_ovl_adaptor {
+   struct device *ovl_adaptor_comp[OVL_ADAPTOR_ID_MAX];
+   struct 

[PATCH v30 5/7] drm/mediatek: modify mediatek-drm for mt8195 multi mmsys support

[Nancy . Lin]

MT8195 have two mmsys. Modify drm for MT8195 multi-mmsys support.
The two mmsys (vdosys0 and vdosys1) will bring up two drm drivers,
only one drm driver register as the drm device.
Each drm driver binds its own component. The last bind drm driver
allocates and registers the drm device to drm core.
Each crtc path is created with the corresponding drm driver data.

Signed-off-by: Nancy.Lin 
Reviewed-by: AngeloGioacchino Del Regno 

Reviewed-by: CK Hu 
Tested-by: AngeloGioacchino Del Regno 
Tested-by: Bo-Chen Chen 
Tested-by: Nícolas F. R. A. Prado 
---
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c |  24 +-
 drivers/gpu/drm/mediatek/mtk_drm_crtc.h |   3 +-
 drivers/gpu/drm/mediatek/mtk_drm_drv.c  | 296 ++--
 drivers/gpu/drm/mediatek/mtk_drm_drv.h  |  10 +-
 4 files changed, 245 insertions(+), 88 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c 
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index 137f7df836ef..8e97a34ebd47 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -874,21 +874,28 @@ struct device *mtk_drm_crtc_dma_dev_get(struct drm_crtc 
*crtc)
 }
 
 int mtk_drm_crtc_create(struct drm_device *drm_dev,
-   const enum mtk_ddp_comp_id *path, unsigned int path_len)
+   const enum mtk_ddp_comp_id *path, unsigned int path_len,
+   int priv_data_index)
 {
struct mtk_drm_private *priv = drm_dev->dev_private;
struct device *dev = drm_dev->dev;
struct mtk_drm_crtc *mtk_crtc;
unsigned int num_comp_planes = 0;
-   int pipe = priv->num_pipes;
int ret;
int i;
bool has_ctm = false;
uint gamma_lut_size = 0;
+   struct drm_crtc *tmp;
+   int crtc_i = 0;
 
if (!path)
return 0;
 
+   priv = priv->all_drm_private[priv_data_index];
+
+   drm_for_each_crtc(tmp, drm_dev)
+   crtc_i++;
+
for (i = 0; i < path_len; i++) {
enum mtk_ddp_comp_id comp_id = path[i];
struct device_node *node;
@@ -900,7 +907,7 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
if (!node) {
dev_info(dev,
 "Not creating crtc %d because component %d is 
disabled or missing\n",
-pipe, comp_id);
+crtc_i, comp_id);
return 0;
}
 
@@ -958,7 +965,7 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
 
for (i = 0; i < mtk_crtc->ddp_comp_nr; i++) {
ret = mtk_drm_crtc_init_comp_planes(drm_dev, mtk_crtc, i,
-   pipe);
+   crtc_i);
if (ret)
return ret;
}
@@ -970,24 +977,23 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
 */
mtk_crtc->dma_dev = mtk_ddp_comp_dma_dev_get(>ddp_comp[path[0]]);
 
-   ret = mtk_drm_crtc_init(drm_dev, mtk_crtc, pipe);
+   ret = mtk_drm_crtc_init(drm_dev, mtk_crtc, crtc_i);
if (ret < 0)
return ret;
 
if (gamma_lut_size)
drm_mode_crtc_set_gamma_size(_crtc->base, gamma_lut_size);
drm_crtc_enable_color_mgmt(_crtc->base, 0, has_ctm, gamma_lut_size);
-   priv->num_pipes++;
mutex_init(_crtc->hw_lock);
 
 #if IS_REACHABLE(CONFIG_MTK_CMDQ)
+   i = priv->mbox_index++;
mtk_crtc->cmdq_client.client.dev = mtk_crtc->mmsys_dev;
mtk_crtc->cmdq_client.client.tx_block = false;
mtk_crtc->cmdq_client.client.knows_txdone = true;
mtk_crtc->cmdq_client.client.rx_callback = ddp_cmdq_cb;
mtk_crtc->cmdq_client.chan =
-   mbox_request_channel(_crtc->cmdq_client.client,
-drm_crtc_index(_crtc->base));
+   mbox_request_channel(_crtc->cmdq_client.client, i);
if (IS_ERR(mtk_crtc->cmdq_client.chan)) {
dev_dbg(dev, "mtk_crtc %d failed to create mailbox client, 
writing register by CPU now\n",
drm_crtc_index(_crtc->base));
@@ -997,7 +1003,7 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
if (mtk_crtc->cmdq_client.chan) {
ret = of_property_read_u32_index(priv->mutex_node,
 "mediatek,gce-events",
-
drm_crtc_index(_crtc->base),
+i,
 _crtc->cmdq_event);
if (ret) {
dev_dbg(dev, "mtk_crtc %d failed to get 
mediatek,gce-events property\n",
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.h 
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.h
index f5a6e80c5265..606f72f35924 100644
--- 

[PATCH v30 4/7] drm/mediatek: add dma dev get function

[Nancy . Lin]

This is a preparation for adding support for the ovl_adaptor sub driver
Ovl_adaptor is a DRM sub driver, which doesn't have dma dev. Add
dma_dev_get function for getting representative dma dev in ovl_adaptor.

Signed-off-by: Nancy.Lin 
Reviewed-by: AngeloGioachino Del Regno 
Reviewed-by: CK Hu 
Tested-by: AngeloGioacchino Del Regno 
Tested-by: Bo-Chen Chen 
---
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 15 +++
 drivers/gpu/drm/mediatek/mtk_drm_crtc.h |  1 +
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h |  8 
 3 files changed, 24 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c 
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index 5071f1263216..137f7df836ef 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -58,6 +58,7 @@ struct mtk_drm_crtc {
 #endif
 
struct device   *mmsys_dev;
+   struct device   *dma_dev;
struct mtk_mutex*mutex;
unsigned intddp_comp_nr;
struct mtk_ddp_comp **ddp_comp;
@@ -865,6 +866,13 @@ static int mtk_drm_crtc_init_comp_planes(struct drm_device 
*drm_dev,
return 0;
 }
 
+struct device *mtk_drm_crtc_dma_dev_get(struct drm_crtc *crtc)
+{
+   struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
+
+   return mtk_crtc->dma_dev;
+}
+
 int mtk_drm_crtc_create(struct drm_device *drm_dev,
const enum mtk_ddp_comp_id *path, unsigned int path_len)
 {
@@ -955,6 +963,13 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
return ret;
}
 
+   /*
+* Default to use the first component as the dma dev.
+* In the case of ovl_adaptor sub driver, it needs to use the
+* dma_dev_get function to get representative dma dev.
+*/
+   mtk_crtc->dma_dev = mtk_ddp_comp_dma_dev_get(>ddp_comp[path[0]]);
+
ret = mtk_drm_crtc_init(drm_dev, mtk_crtc, pipe);
if (ret < 0)
return ret;
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.h 
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.h
index cb9a36c48d4f..f5a6e80c5265 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.h
@@ -22,5 +22,6 @@ int mtk_drm_crtc_plane_check(struct drm_crtc *crtc, struct 
drm_plane *plane,
 struct mtk_plane_state *state);
 void mtk_drm_crtc_async_update(struct drm_crtc *crtc, struct drm_plane *plane,
   struct drm_atomic_state *plane_state);
+struct device *mtk_drm_crtc_dma_dev_get(struct drm_crtc *crtc);
 
 #endif /* MTK_DRM_CRTC_H */
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h 
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
index 2d0052c23dcb..364f3f7f59fa 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
@@ -71,6 +71,7 @@ struct mtk_ddp_comp_funcs {
void (*bgclr_in_off)(struct device *dev);
void (*ctm_set)(struct device *dev,
struct drm_crtc_state *state);
+   struct device * (*dma_dev_get)(struct device *dev);
 };
 
 struct mtk_ddp_comp {
@@ -203,6 +204,13 @@ static inline void mtk_ddp_ctm_set(struct mtk_ddp_comp 
*comp,
comp->funcs->ctm_set(comp->dev, state);
 }
 
+static inline struct device *mtk_ddp_comp_dma_dev_get(struct mtk_ddp_comp 
*comp)
+{
+   if (comp->funcs && comp->funcs->dma_dev_get)
+   return comp->funcs->dma_dev_get(comp->dev);
+   return comp->dev;
+}
+
 int mtk_ddp_comp_get_id(struct device_node *node,
enum mtk_ddp_comp_type comp_type);
 unsigned int mtk_drm_find_possible_crtc_by_comp(struct drm_device *drm,
-- 
2.18.0

[PATCH v30 7/7] drm/mediatek: add mediatek-drm of vdosys1 support for MT8195

[Nancy . Lin]

Add driver data of mt8195 vdosys1 to mediatek-drm.

Signed-off-by: Nancy.Lin 
Reviewed-by: AngeloGioacchino Del Regno 

Reviewed-by: CK Hu 
Tested-by: AngeloGioacchino Del Regno 
Tested-by: Bo-Chen Chen 
---
 drivers/gpu/drm/mediatek/mtk_drm_drv.c | 17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c 
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index f689e6750974..dce2d86df6d9 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -208,6 +208,12 @@ static const unsigned int mt8195_mtk_ddp_main[] = {
DDP_COMPONENT_DP_INTF0,
 };
 
+static const unsigned int mt8195_mtk_ddp_ext[] = {
+   DDP_COMPONENT_DRM_OVL_ADAPTOR,
+   DDP_COMPONENT_MERGE5,
+   DDP_COMPONENT_DP_INTF1,
+};
+
 static const struct mtk_mmsys_driver_data mt2701_mmsys_driver_data = {
.main_path = mt2701_mtk_ddp_main,
.main_len = ARRAY_SIZE(mt2701_mtk_ddp_main),
@@ -277,7 +283,14 @@ static const struct mtk_mmsys_driver_data 
mt8192_mmsys_driver_data = {
 static const struct mtk_mmsys_driver_data mt8195_vdosys0_driver_data = {
.main_path = mt8195_mtk_ddp_main,
.main_len = ARRAY_SIZE(mt8195_mtk_ddp_main),
-   .mmsys_dev_num = 1,
+   .mmsys_dev_num = 2,
+};
+
+static const struct mtk_mmsys_driver_data mt8195_vdosys1_driver_data = {
+   .ext_path = mt8195_mtk_ddp_ext,
+   .ext_len = ARRAY_SIZE(mt8195_mtk_ddp_ext),
+   .mmsys_id = 1,
+   .mmsys_dev_num = 2,
 };
 
 static const struct of_device_id mtk_drm_of_ids[] = {
@@ -301,6 +314,8 @@ static const struct of_device_id mtk_drm_of_ids[] = {
  .data = _vdosys0_driver_data},
{ .compatible = "mediatek,mt8195-vdosys0",
  .data = _vdosys0_driver_data},
+   { .compatible = "mediatek,mt8195-vdosys1",
+ .data = _vdosys1_driver_data},
{ }
 };
 MODULE_DEVICE_TABLE(of, mtk_drm_of_ids);
-- 
2.18.0

[PATCH v30 6/7] drm/mediatek: add drm ovl_adaptor sub driver for MT8195

[Nancy . Lin]

Add drm ovl_adaptor sub driver. Bring up ovl_adaptor sub driver if
the component exists in the path.

Signed-off-by: Nancy.Lin 
Reviewed-by: AngeloGioacchino Del Regno 

Reviewed-by: CK Hu 
Tested-by: AngeloGioacchino Del Regno 
Tested-by: Bo-Chen Chen 
Tested-by: Nícolas F. R. A. Prado 
---
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c |  50 +---
 drivers/gpu/drm/mediatek/mtk_drm_crtc.h |   2 +-
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 129 
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h |  50 +++-
 drivers/gpu/drm/mediatek/mtk_drm_drv.c  |  78 ++--
 drivers/gpu/drm/mediatek/mtk_drm_drv.h  |  12 +-
 6 files changed, 207 insertions(+), 114 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c 
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index 8e97a34ebd47..ac93f2b4a300 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -379,13 +379,17 @@ static int mtk_crtc_ddp_hw_init(struct mtk_drm_crtc 
*mtk_crtc)
}
 
for (i = 0; i < mtk_crtc->ddp_comp_nr - 1; i++) {
-   mtk_mmsys_ddp_connect(mtk_crtc->mmsys_dev,
- mtk_crtc->ddp_comp[i]->id,
- mtk_crtc->ddp_comp[i + 1]->id);
-   mtk_mutex_add_comp(mtk_crtc->mutex,
-   mtk_crtc->ddp_comp[i]->id);
+   if (!mtk_ddp_comp_connect(mtk_crtc->ddp_comp[i], 
mtk_crtc->mmsys_dev,
+ mtk_crtc->ddp_comp[i + 1]->id))
+   mtk_mmsys_ddp_connect(mtk_crtc->mmsys_dev,
+ mtk_crtc->ddp_comp[i]->id,
+ mtk_crtc->ddp_comp[i + 1]->id);
+   if (!mtk_ddp_comp_add(mtk_crtc->ddp_comp[i], mtk_crtc->mutex))
+   mtk_mutex_add_comp(mtk_crtc->mutex,
+  mtk_crtc->ddp_comp[i]->id);
}
-   mtk_mutex_add_comp(mtk_crtc->mutex, mtk_crtc->ddp_comp[i]->id);
+   if (!mtk_ddp_comp_add(mtk_crtc->ddp_comp[i], mtk_crtc->mutex))
+   mtk_mutex_add_comp(mtk_crtc->mutex, mtk_crtc->ddp_comp[i]->id);
mtk_mutex_enable(mtk_crtc->mutex);
 
for (i = 0; i < mtk_crtc->ddp_comp_nr; i++) {
@@ -434,17 +438,22 @@ static void mtk_crtc_ddp_hw_fini(struct mtk_drm_crtc 
*mtk_crtc)
}
 
for (i = 0; i < mtk_crtc->ddp_comp_nr; i++)
-   mtk_mutex_remove_comp(mtk_crtc->mutex,
-  mtk_crtc->ddp_comp[i]->id);
+   if (!mtk_ddp_comp_remove(mtk_crtc->ddp_comp[i], 
mtk_crtc->mutex))
+   mtk_mutex_remove_comp(mtk_crtc->mutex,
+ mtk_crtc->ddp_comp[i]->id);
mtk_mutex_disable(mtk_crtc->mutex);
for (i = 0; i < mtk_crtc->ddp_comp_nr - 1; i++) {
-   mtk_mmsys_ddp_disconnect(mtk_crtc->mmsys_dev,
-mtk_crtc->ddp_comp[i]->id,
-mtk_crtc->ddp_comp[i + 1]->id);
-   mtk_mutex_remove_comp(mtk_crtc->mutex,
-  mtk_crtc->ddp_comp[i]->id);
+   if (!mtk_ddp_comp_disconnect(mtk_crtc->ddp_comp[i], 
mtk_crtc->mmsys_dev,
+mtk_crtc->ddp_comp[i + 1]->id))
+   mtk_mmsys_ddp_disconnect(mtk_crtc->mmsys_dev,
+mtk_crtc->ddp_comp[i]->id,
+mtk_crtc->ddp_comp[i + 1]->id);
+   if (!mtk_ddp_comp_remove(mtk_crtc->ddp_comp[i], 
mtk_crtc->mutex))
+   mtk_mutex_remove_comp(mtk_crtc->mutex,
+ mtk_crtc->ddp_comp[i]->id);
}
-   mtk_mutex_remove_comp(mtk_crtc->mutex, mtk_crtc->ddp_comp[i]->id);
+   if (!mtk_ddp_comp_remove(mtk_crtc->ddp_comp[i], mtk_crtc->mutex))
+   mtk_mutex_remove_comp(mtk_crtc->mutex, 
mtk_crtc->ddp_comp[i]->id);
mtk_crtc_ddp_clk_disable(mtk_crtc);
mtk_mutex_unprepare(mtk_crtc->mutex);
 
@@ -874,7 +883,7 @@ struct device *mtk_drm_crtc_dma_dev_get(struct drm_crtc 
*crtc)
 }
 
 int mtk_drm_crtc_create(struct drm_device *drm_dev,
-   const enum mtk_ddp_comp_id *path, unsigned int path_len,
+   const unsigned int *path, unsigned int path_len,
int priv_data_index)
 {
struct mtk_drm_private *priv = drm_dev->dev_private;
@@ -904,10 +913,13 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
node = priv->comp_node[comp_id];
comp = >ddp_comp[comp_id];
 
-   if (!node) {
+   /* Not all drm components have a DTS device node, such as 
ovl_adaptor,
+* which is the drm bring up sub driver
+*/
+   if 

[PATCH v30 1/7] dt-bindings: mediatek: add ethdr definition for mt8195

[Nancy . Lin]

Add vdosys1 ETHDR definition.

Signed-off-by: Nancy.Lin 
Reviewed-by: Chun-Kuang Hu 
Reviewed-by: AngeloGioacchino Del Regno 

Reviewed-by: Krzysztof Kozlowski 
Tested-by: AngeloGioacchino Del Regno 
---
 .../display/mediatek/mediatek,ethdr.yaml  | 182 ++
 1 file changed, 182 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml

diff --git 
a/Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml 
b/Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml
new file mode 100644
index ..801fa66ae615
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml
@@ -0,0 +1,182 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/mediatek/mediatek,ethdr.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek Ethdr Device
+
+maintainers:
+  - Chun-Kuang Hu 
+  - Philipp Zabel 
+
+description:
+  ETHDR (ET High Dynamic Range) is a MediaTek internal HDR engine and is
+  designed for HDR video and graphics conversion in the external display path.
+  It handles multiple HDR input types and performs tone mapping, color
+  space/color format conversion, and then combine different layers,
+  output the required HDR or SDR signal to the subsequent display path.
+  This engine is composed of two video frontends, two graphic frontends,
+  one video backend and a mixer. ETHDR has two DMA function blocks, DS and ADL.
+  These two function blocks read the pre-programmed registers from DRAM and
+  set them to HW in the v-blanking period.
+
+properties:
+  compatible:
+const: mediatek,mt8195-disp-ethdr
+
+  reg:
+maxItems: 7
+
+  reg-names:
+items:
+  - const: mixer
+  - const: vdo_fe0
+  - const: vdo_fe1
+  - const: gfx_fe0
+  - const: gfx_fe1
+  - const: vdo_be
+  - const: adl_ds
+
+  interrupts:
+maxItems: 1
+
+  iommus:
+minItems: 1
+maxItems: 2
+
+  clocks:
+items:
+  - description: mixer clock
+  - description: video frontend 0 clock
+  - description: video frontend 1 clock
+  - description: graphic frontend 0 clock
+  - description: graphic frontend 1 clock
+  - description: video backend clock
+  - description: autodownload and menuload clock
+  - description: video frontend 0 async clock
+  - description: video frontend 1 async clock
+  - description: graphic frontend 0 async clock
+  - description: graphic frontend 1 async clock
+  - description: video backend async clock
+  - description: ethdr top clock
+
+  clock-names:
+items:
+  - const: mixer
+  - const: vdo_fe0
+  - const: vdo_fe1
+  - const: gfx_fe0
+  - const: gfx_fe1
+  - const: vdo_be
+  - const: adl_ds
+  - const: vdo_fe0_async
+  - const: vdo_fe1_async
+  - const: gfx_fe0_async
+  - const: gfx_fe1_async
+  - const: vdo_be_async
+  - const: ethdr_top
+
+  power-domains:
+maxItems: 1
+
+  resets:
+items:
+  - description: video frontend 0 async reset
+  - description: video frontend 1 async reset
+  - description: graphic frontend 0 async reset
+  - description: graphic frontend 1 async reset
+  - description: video backend async reset
+
+  reset-names:
+items:
+  - const: vdo_fe0_async
+  - const: vdo_fe1_async
+  - const: gfx_fe0_async
+  - const: gfx_fe1_async
+  - const: vdo_be_async
+
+  mediatek,gce-client-reg:
+$ref: /schemas/types.yaml#/definitions/phandle-array
+minItems: 1
+maxItems: 7
+description: The register of display function block to be set by gce.
+  There are 4 arguments in this property, gce node, subsys id, offset and
+  register size. The subsys id is defined in the gce header of each chips
+  include/dt-bindings/gce/-gce.h, mapping to the register of display
+  function block.
+
+required:
+  - compatible
+  - reg
+  - clocks
+  - clock-names
+  - interrupts
+  - power-domains
+  - resets
+  - mediatek,gce-client-reg
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+soc {
+#address-cells = <2>;
+#size-cells = <2>;
+
+hdr-engine@1c114000 {
+compatible = "mediatek,mt8195-disp-ethdr";
+reg = <0 0x1c114000 0 0x1000>,
+  <0 0x1c115000 0 0x1000>,
+  <0 0x1c117000 0 0x1000>,
+  <0 0x1c119000 0 0x1000>,
+  <0 0x1c11a000 0 0x1000>,
+  <0 0x1c11b000 0 0x1000>,
+  <0 0x1c11c000 0 0x1000>;
+reg-names = "mixer", "vdo_fe0", "vdo_fe1", "gfx_fe0", 
"gfx_fe1",
+"vdo_be", "adl_ds";
+mediatek,gce-client-reg = < SUBSYS_1c11 0x4000 
0x1000>,
+

[PATCH v30 2/7] drm/mediatek: add ETHDR support for MT8195

[Nancy . Lin]

ETHDR is a part of ovl_adaptor.
ETHDR is designed for HDR video and graphics conversion in the external
display path. It handles multiple HDR input types and performs tone
mapping, color space/color format conversion, and then combine
different layers, output the required HDR or SDR signal to the
subsequent display path.

Signed-off-by: Nancy.Lin 
Reviewed-by: Chun-Kuang Hu 
Reviewed-by: AngeloGioacchino Del Regno 

Tested-by: AngeloGioacchino Del Regno 
Tested-by: Bo-Chen Chen 
---
 drivers/gpu/drm/mediatek/Makefile  |   1 +
 drivers/gpu/drm/mediatek/mtk_drm_drv.c |   1 +
 drivers/gpu/drm/mediatek/mtk_drm_drv.h |   1 +
 drivers/gpu/drm/mediatek/mtk_ethdr.c   | 370 +
 drivers/gpu/drm/mediatek/mtk_ethdr.h   |  25 ++
 5 files changed, 398 insertions(+)
 create mode 100644 drivers/gpu/drm/mediatek/mtk_ethdr.c
 create mode 100644 drivers/gpu/drm/mediatek/mtk_ethdr.h

diff --git a/drivers/gpu/drm/mediatek/Makefile 
b/drivers/gpu/drm/mediatek/Makefile
index 3517d1c65cd7..840f14436d3c 100644
--- a/drivers/gpu/drm/mediatek/Makefile
+++ b/drivers/gpu/drm/mediatek/Makefile
@@ -14,6 +14,7 @@ mediatek-drm-y := mtk_disp_aal.o \
  mtk_drm_plane.o \
  mtk_dsi.o \
  mtk_dpi.o \
+ mtk_ethdr.o \
  mtk_mdp_rdma.o
 
 obj-$(CONFIG_DRM_MEDIATEK) += mediatek-drm.o
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c 
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index ee7024fed65c..72935eb6935e 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -782,6 +782,7 @@ static struct platform_driver * const mtk_drm_drivers[] = {
_dpi_driver,
_drm_platform_driver,
_dsi_driver,
+   _ethdr_driver,
_mdp_rdma_driver,
 };
 
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.h 
b/drivers/gpu/drm/mediatek/mtk_drm_drv.h
index 64a1f66df26a..3fb85776b8b3 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.h
@@ -55,6 +55,7 @@ extern struct platform_driver mtk_disp_ovl_driver;
 extern struct platform_driver mtk_disp_rdma_driver;
 extern struct platform_driver mtk_dpi_driver;
 extern struct platform_driver mtk_dsi_driver;
+extern struct platform_driver mtk_ethdr_driver;
 extern struct platform_driver mtk_mdp_rdma_driver;
 
 #endif /* MTK_DRM_DRV_H */
diff --git a/drivers/gpu/drm/mediatek/mtk_ethdr.c 
b/drivers/gpu/drm/mediatek/mtk_ethdr.c
new file mode 100644
index ..73dc4da3ba3b
--- /dev/null
+++ b/drivers/gpu/drm/mediatek/mtk_ethdr.c
@@ -0,0 +1,370 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2021 MediaTek Inc.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "mtk_drm_crtc.h"
+#include "mtk_drm_ddp_comp.h"
+#include "mtk_drm_drv.h"
+#include "mtk_ethdr.h"
+
+#define MIX_INTEN  0x4
+#define MIX_FME_CPL_INTEN  BIT(1)
+#define MIX_INTSTA 0x8
+#define MIX_EN 0xc
+#define MIX_RST0x14
+#define MIX_ROI_SIZE   0x18
+#define MIX_DATAPATH_CON   0x1c
+#define OUTPUT_NO_RND  BIT(3)
+#define SOURCE_RGB_SEL BIT(7)
+#define BACKGROUND_RELAY   (4 << 9)
+#define MIX_ROI_BGCLR  0x20
+#define BGCLR_BLACK0xff00
+#define MIX_SRC_CON0x24
+#define MIX_SRC_L0_EN  BIT(0)
+#define MIX_L_SRC_CON(n)   (0x28 + 0x18 * (n))
+#define NON_PREMULTI_SOURCE(2 << 12)
+#define MIX_L_SRC_SIZE(n)  (0x30 + 0x18 * (n))
+#define MIX_L_SRC_OFFSET(n)(0x34 + 0x18 * (n))
+#define MIX_FUNC_DCM0  0x120
+#define MIX_FUNC_DCM1  0x124
+#define MIX_FUNC_DCM_ENABLE0x
+
+#define HDR_VDO_FE_0804_HDR_DM_FE  0x804
+#define HDR_VDO_FE_0804_BYPASS_ALL 0xfd
+#define HDR_GFX_FE_0204_GFX_HDR_FE 0x204
+#define HDR_GFX_FE_0204_BYPASS_ALL 0xfd
+#define HDR_VDO_BE_0204_VDO_DM_BE  0x204
+#define HDR_VDO_BE_0204_BYPASS_ALL 0x7e
+
+#define MIXER_INX_MODE_BYPASS  0
+#define MIXER_INX_MODE_EVEN_EXTEND 1
+#define DEFAULT_9BIT_ALPHA 0x100
+#defineMIXER_ALPHA_AEN BIT(8)
+#defineMIXER_ALPHA 0xff
+#define ETHDR_CLK_NUM  13
+
+enum mtk_ethdr_comp_id {
+   ETHDR_MIXER,
+   ETHDR_VDO_FE0,
+   ETHDR_VDO_FE1,
+   ETHDR_GFX_FE0,
+   ETHDR_GFX_FE1,
+   ETHDR_VDO_BE,
+   ETHDR_ADL_DS,
+   ETHDR_ID_MAX
+};
+
+struct mtk_ethdr_comp {
+   struct device   *dev;
+   void __iomem*regs;
+   struct cmdq_client_reg  cmdq_base;
+};
+
+struct 

[PATCH v30 0/7] Add MediaTek SoC DRM (vdosys1) support for mt8195

[Nancy . Lin]

The hardware path of vdosys1 with DPTx output need to go through by several 
modules, such as, OVL_ADAPTOR and MERGE.

Add DRM and these modules support by the patches below:

Changes in v30:
- rebase to next-20230321
- fix ethdr dt_binding_check message

Changes in v29:
- rebase to next-20221226
- fix reviewer comment in v28
  - keep original flow if comp node not found in mtk_drm_crtc_create()

Changes in v28:
- rebase to next-20221107
- fix reviewer comment in v27
  - extra new line at the end mtk_ethdr.h

Changes in v27:
- rebase to next-20221102
- change mmsys compatible for mt8195 vdosys1
  - base on jason's series[ref 1]
- fix reviewer comment
  - add error return code if no ovl_adaptor's comp found

Changes in v26:
- rebase to next-20220819
- resend for patch corrupted in v25

Changes in v25:
- rebase to next-20220803

Changes in v24:
- fix ovl_adaptor binding issue (mtk_disp_ovl_adaptor.c)
  - Since ovl_adaptor is an aggregated component, it should be bounded after
all its child components are bounded.
- rebase to next-20220708

Changes in v23:
- separate[7] mmsys/mutex and drm patches into two series

Changes in v22:
- rebase to next-20220525
- rebase to vdosys0 series v22
- separate dts to a new patch

Changes in v21:
- fix reviewer comment
  - fix rdma and ethdr binding doc and dts

Changes in v20:
- fix reviewer comment
  - update mmsys update bit api name
  - add mtk_mmsys_update_bits error message if lose gce property
  - list all mt8195 vdosys1 reset bits

Changes in v19:
- fix reviewer comment
  - separate mt8195 mmsys component to a new patch
  - separate mt8195 vdo0 and vdo1 routing table
  - separate mmsys_write_reg api to a new patch and simplify write reg code
  - separate mmsys 64 bit reset to a new patch
  - separate mtk-mutex dp_intf1 component to a new patch

Changes in v18:
- fix reviewer comment
  - fix rdma binding doc
  - fix ethdr binding doc
  - refine mmsys config cmdq support
  - refine merge reset control flow, get reset control in probe function
  - add ethdr reset control error handling and remove dbg log
- rebase to vdosys0 series v20 (ref [5])

Changes in v17:
- fix reviewer comment in v16
  - separate ovl adaptor comp in mtk-mmsys and mtk-mutex
  - separate mmsys config API
  - move mdp_rdma binding yaml
- fix ovl adaptor pm runtime get sync timing issue
- rebase to vdosys0 series v19 (ref [5])
- rebase to [7] for modify vblank register change

Changes in v16:
- fix reviewer comment in v 15
  - fix mtk_drm_ddp_comp.c alignment
  - fix vdosys0 mmsys num before adding vdosys1 patch

Changes in v15:
- fix ethdr uppercase hex number in dts

Changes in v14:
- remove MTK_MMSYS 64 bit dependency
- add ethdr.yaml back and fix dt_schema check fail

Resend v13
- add related maintainer in maillist

Changes in v13:
- fix reviewer comment in v12
  - fix rdma dt-binding format
  - fix dts node naming
- fix 32 bit build error
  - modify 64bit dependency for mtk-mmsys
- rebase to vdosys0 series v16. (ref [5])

Changes in v12:
- fix reviewer comment in v11
  - modify mbox index
  - refine dma dev for ovl_adaptor sub driver

Changes in v11:
- remove ethdr vblank spin lock
- refine ovl_adaptor print message

Changes in v10:
- refine ethdr reset control using 
devm_reset_control_array_get_optional_exclusive
- fix ovl_adaptor mtk_ovl_adaptor_clk_enable error handle issue

Changes in v9:
- rebase on kernel-5.16-rc1
- rebase on vdosys0 series v13. (ref [5])
- fix ovl_adaptor sub driver is brought up unintentionally
- fix clang build test fail- duplicate ethdr/mdp_rdma 
init_module/cleanup_module symbol issue 

Changes in v8:
- separate merge async reset to new patch.
- separate drm ovl_adaptor sub driver to new patch.
- fix reviewer comment in v7.

Changes in v7:
- rebase on vdosys0 series v12 (ref[5])
- add dma description in ethdr binding document.
- refine vdosys1 bit definition of mmsys routing table.
- separate merge modification into 3 pathces.
- separate mutex modification into 2 patches.
- add plane color coding for mdp_rdma csc.
- move mdp_rdma pm control to ovl_adaptor.
- fix reviewer comment in v6.

Changes in v6:
- rebase on kernel-5.15-rc1.
- change mbox label to gce0 for dts node of vdosys1.
- modify mmsys reset num for mt8195.
- rebase on vdosys0 series v10. (ref [5])
- use drm to bring up ovl_adaptor driver.
- move drm iommu/mutex check from kms init to drm bind.
- modify rdma binding doc location. (Documentation/devicetree/bindings/arm/)
- modify for reviewer's comment in v5.

Changes in v5:
- add mmsys reset controller reference.

Changes in v4:
- use merge common driver for merge1~4.
- refine ovl_adaptor rdma driver.
- use ovl_adaptor ddp_comp function instead of ethdr.
- modify for reviewer's comment in v3.

Changes in v3:
- modify for reviewer's comment in v2.
- add vdosys1 2 pixels align limit.
- add mixer odd offset support.

Changes in v2:
- Merge PSEUDO_OVL and ETHDR into one DRM component.
- Add mmsys config API for vdosys1 hardware setting.
- Add mmsys reset

Re: display band (display area vs real visible area)

[Daniel Stone]

Hi,

On Tue, 21 Mar 2023 at 12:08, Jani Nikula  wrote:
> On Tue, 21 Mar 2023, Daniel Stone  wrote:
> > There have been some threads - mostly motivated by MacBooks and the
> > Asahi team - about creating a KMS property to express invisible areas.
> > This would be the same thing, and the userspace ecosystem will pick it
> > up when the kernel exposes it.
>
> In my case the kernel handled it completely internally, and the
> userspace didn't even know. But I guess it depends on the display being
> able to take a smaller framebuffer, otherwise I don't think it's
> feasible.
>
> I haven't checked the threads you mention but I assume it covers the
> more general case of having rounded corners or holes for the camera, not
> just the frame covering the edges or something like that. That couldn't
> possibly be handled by kernel alone, but it's also a bunch of
> infrastructure work both in kernel and userspace to make it happen.

Yeah, exactly. Just a connector property, which could come from DT or
ACPI or manual overrides or whatever. Userspace would still allocate a
full-size framebuffer, but look at that property and not render
anything useful into those areas. In the camera/notch case, it's a
matter of not putting useful content there. In the letterbox/pillarbox
case, it's about shrinking the reported screen size so that window
management, clients, etc, all believe that the screen is smaller than
it is.

Cheers,
Daniel

Re: [v2,2/8] drm/fbdev-generic: Remove unused prefer_shadow_fbdev flag

[Sui jingfeng]

Well, this patch looks good to me.

Tested-by: Sui Jingfeng 

On 2023/3/20 23:07, Thomas Zimmermann wrote:

Remove the flag prefer_shadow_fbdev from struct drm_mode_config.
Drivers set this flag to enable shadow buffering in the generic
fbdev emulation. Such shadow buffering is now mandatory, so the
flag is unused.

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Javier Martinez Canillas 
Reviewed-by: Zack Rusin 
---
  drivers/gpu/drm/tiny/bochs.c| 1 -
  drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 1 -
  include/drm/drm_mode_config.h   | 7 ---
  3 files changed, 9 deletions(-)

diff --git a/drivers/gpu/drm/tiny/bochs.c b/drivers/gpu/drm/tiny/bochs.c
index 024346054c70..d254679a136e 100644
--- a/drivers/gpu/drm/tiny/bochs.c
+++ b/drivers/gpu/drm/tiny/bochs.c
@@ -545,7 +545,6 @@ static int bochs_kms_init(struct bochs_device *bochs)
  
  	bochs->dev->mode_config.preferred_depth = 24;

bochs->dev->mode_config.prefer_shadow = 0;
-   bochs->dev->mode_config.prefer_shadow_fbdev = 1;
bochs->dev->mode_config.quirk_addfb_prefer_host_byte_order = true;
  
  	bochs->dev->mode_config.funcs = _mode_funcs;

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index 84d6380b9895..5162a7a12792 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -2112,7 +2112,6 @@ int vmw_kms_init(struct vmw_private *dev_priv)
dev->mode_config.max_width = dev_priv->texture_max_width;
dev->mode_config.max_height = dev_priv->texture_max_height;
dev->mode_config.preferred_depth = dev_priv->assume_16bpp ? 16 : 32;
-   dev->mode_config.prefer_shadow_fbdev = !dev_priv->has_mob;
  
  	drm_mode_create_suggested_offset_properties(dev);

vmw_kms_create_hotplug_mode_update_property(dev_priv);
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index e5b053001d22..973119a9176b 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -890,13 +890,6 @@ struct drm_mode_config {
/* dumb ioctl parameters */
uint32_t preferred_depth, prefer_shadow;
  
-	/**

-* @prefer_shadow_fbdev:
-*
-* Hint to framebuffer emulation to prefer shadow-fb rendering.
-*/
-   bool prefer_shadow_fbdev;
-
/**
 * @quirk_addfb_prefer_xbgr_30bpp:
 *

Re: display band (display area vs real visible area)

[Jani Nikula]

On Tue, 21 Mar 2023, Daniel Stone  wrote:
> Hi,
>
> On Tue, 21 Mar 2023 at 11:24, Jani Nikula  wrote:
>> On Tue, 21 Mar 2023, Michael Nazzareno Trimarchi 
>>  wrote:
>> > On Tue, Mar 21, 2023 at 11:43 AM Jani Nikula
>> >  wrote:
>> >> On Tue, 21 Mar 2023, Michael Nazzareno Trimarchi 
>> >>  wrote:
>> >> > I would like to know the best approach in the graphics subsystem how
>> >> > deal with panels where the display area is different from the visible
>> >> > area because the display has a band left and right. I have already
>> >> > done the drm driver for the panel but from userspace point of view
>> >> > it's a pain to deal in wayland for input device and output device. Do
>> >> > you have any suggestions?
>> >>
>> >> Do you have the EDID for the panel?
>> >
>> > mipi->panel so should not have edid
>>
>> That's the kind of information you'd expect in the original question. ;)
>>
>> I've done that sort of thing in the past, but not sure if it would fly
>> upstream. Basically the kernel driver would lie about the resolution to
>> userspace, and handle the centering and the bands internally. In my
>> case, the DSI command mode panel in question had commands to set the
>> visible area, so the driver didn't have to do all that much extra to
>> make it happen.
>
> There have been some threads - mostly motivated by MacBooks and the
> Asahi team - about creating a KMS property to express invisible areas.
> This would be the same thing, and the userspace ecosystem will pick it
> up when the kernel exposes it.

In my case the kernel handled it completely internally, and the
userspace didn't even know. But I guess it depends on the display being
able to take a smaller framebuffer, otherwise I don't think it's
feasible.

I haven't checked the threads you mention but I assume it covers the
more general case of having rounded corners or holes for the camera, not
just the frame covering the edges or something like that. That couldn't
possibly be handled by kernel alone, but it's also a bunch of
infrastructure work both in kernel and userspace to make it happen.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Graphics Center

Re: display band (display area vs real visible area)

[Michael Nazzareno Trimarchi]

Hi Daniel

On Tue, Mar 21, 2023 at 12:49 PM Daniel Stone  wrote:
>
> Hi,
>
> On Tue, 21 Mar 2023 at 11:24, Jani Nikula  wrote:
> > On Tue, 21 Mar 2023, Michael Nazzareno Trimarchi 
> >  wrote:
> > > On Tue, Mar 21, 2023 at 11:43 AM Jani Nikula
> > >  wrote:
> > >> On Tue, 21 Mar 2023, Michael Nazzareno Trimarchi 
> > >>  wrote:
> > >> > I would like to know the best approach in the graphics subsystem how
> > >> > deal with panels where the display area is different from the visible
> > >> > area because the display has a band left and right. I have already
> > >> > done the drm driver for the panel but from userspace point of view
> > >> > it's a pain to deal in wayland for input device and output device. Do
> > >> > you have any suggestions?
> > >>
> > >> Do you have the EDID for the panel?
> > >
> > > mipi->panel so should not have edid
> >
> > That's the kind of information you'd expect in the original question. ;)
> >
> > I've done that sort of thing in the past, but not sure if it would fly
> > upstream. Basically the kernel driver would lie about the resolution to
> > userspace, and handle the centering and the bands internally. In my
> > case, the DSI command mode panel in question had commands to set the
> > visible area, so the driver didn't have to do all that much extra to
> > make it happen.
>
> There have been some threads - mostly motivated by MacBooks and the
> Asahi team - about creating a KMS property to express invisible areas.
> This would be the same thing, and the userspace ecosystem will pick it
> up when the kernel exposes it.
>
> Cheers,
> Daniel

Any thread or patches?

Michael

Re: display band (display area vs real visible area)

[Daniel Stone]

Hi,

On Tue, 21 Mar 2023 at 11:24, Jani Nikula  wrote:
> On Tue, 21 Mar 2023, Michael Nazzareno Trimarchi 
>  wrote:
> > On Tue, Mar 21, 2023 at 11:43 AM Jani Nikula
> >  wrote:
> >> On Tue, 21 Mar 2023, Michael Nazzareno Trimarchi 
> >>  wrote:
> >> > I would like to know the best approach in the graphics subsystem how
> >> > deal with panels where the display area is different from the visible
> >> > area because the display has a band left and right. I have already
> >> > done the drm driver for the panel but from userspace point of view
> >> > it's a pain to deal in wayland for input device and output device. Do
> >> > you have any suggestions?
> >>
> >> Do you have the EDID for the panel?
> >
> > mipi->panel so should not have edid
>
> That's the kind of information you'd expect in the original question. ;)
>
> I've done that sort of thing in the past, but not sure if it would fly
> upstream. Basically the kernel driver would lie about the resolution to
> userspace, and handle the centering and the bands internally. In my
> case, the DSI command mode panel in question had commands to set the
> visible area, so the driver didn't have to do all that much extra to
> make it happen.

There have been some threads - mostly motivated by MacBooks and the
Asahi team - about creating a KMS property to express invisible areas.
This would be the same thing, and the userspace ecosystem will pick it
up when the kernel exposes it.

Cheers,
Daniel

[PATCH] drm: omapdrm: use devm_platform_ioremap_resource_byname()

[ye.xingchen]

From: Ye Xingchen 

Convert platform_get_resource_byname(),devm_ioremap_resource() to a single
call to devm_platform_ioremap_resource_byname(), as this is exactly what
this function does.

Signed-off-by: Ye Xingchen 
---
 drivers/gpu/drm/omapdrm/dss/hdmi_wp.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi_wp.c 
b/drivers/gpu/drm/omapdrm/dss/hdmi_wp.c
index 9d830584a762..77a7aa797ad0 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi_wp.c
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi_wp.c
@@ -280,8 +280,7 @@ int hdmi_wp_init(struct platform_device *pdev, struct 
hdmi_wp_data *wp,
 {
struct resource *res;

-   res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "wp");
-   wp->base = devm_ioremap_resource(>dev, res);
+   wp->base = devm_platform_ioremap_resource_byname(pdev, "wp");
if (IS_ERR(wp->base))
return PTR_ERR(wp->base);

-- 
2.25.1

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Sanitycheck MMIO access early in driver load

[Jani Nikula]

On Mon, 20 Mar 2023, Andi Shyti  wrote:
> From: Matt Roper 
>
> We occasionally see the PCI device in a non-accessible state at the
> point the driver is loaded.  When this happens, all BAR accesses will
> read back as 0x.  Rather than reading registers and
> misinterpreting their (invalid) values, let's specifically check for
> 0x in a register that cannot have that value to see if the
> device is accessible.
>
> Signed-off-by: Matt Roper 
> Cc: Mika Kuoppala 
> Signed-off-by: Andi Shyti 
> ---
>  drivers/gpu/drm/i915/intel_uncore.c | 34 +
>  1 file changed, 34 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
> b/drivers/gpu/drm/i915/intel_uncore.c
> index e1e1f34490c8e..14ec45e6facfa 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -2602,11 +2602,45 @@ static int uncore_forcewake_init(struct intel_uncore 
> *uncore)
>   return 0;
>  }
>  
> +static int sanity_check_mmio_access(struct intel_uncore *uncore)
> +{
> + struct drm_i915_private *i915 = uncore->i915;
> +
> + if (GRAPHICS_VER(i915) < 8)
> + return 0;
> +
> + /*
> +  * Sanitycheck that MMIO access to the device is working properly.  If
> +  * the CPU is unable to communcate with a PCI device, BAR reads will
> +  * return 0x.  Let's make sure the device isn't in this state
> +  * before we start trying to access registers.
> +  *
> +  * We use the primary GT's forcewake register as our guinea pig since
> +  * it's been around since HSW and it's a masked register so the upper
> +  * 16 bits can never read back as 1's if device access is operating
> +  * properly.
> +  *
> +  * If MMIO isn't working, we'll wait up to 2 seconds to see if it
> +  * recovers, then give up.
> +  */
> +#define COND (__raw_uncore_read32(uncore, FORCEWAKE_MT) != ~0)
> + if (wait_for(COND, 2000) == -ETIMEDOUT) {

I guess this somewhat reimplements intel_wait_for_register_fw()?

> + drm_err(>drm, "Device is non-operational; MMIO access 
> returns 0x!\n");
> + return -EIO;
> + }
> +
> + return 0;
> +}
> +
>  int intel_uncore_init_mmio(struct intel_uncore *uncore)
>  {
>   struct drm_i915_private *i915 = uncore->i915;
>   int ret;
>  
> + ret = sanity_check_mmio_access(uncore);
> + if (ret)
> + return ret;
> +
>   /*
>* The boot firmware initializes local memory and assesses its health.
>* If memory training fails, the punit will have been instructed to

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: display band (display area vs real visible area)

[Jani Nikula]

On Tue, 21 Mar 2023, Michael Nazzareno Trimarchi  
wrote:
> Hi
>
> On Tue, Mar 21, 2023 at 11:43 AM Jani Nikula
>  wrote:
>>
>> On Tue, 21 Mar 2023, Michael Nazzareno Trimarchi 
>>  wrote:
>> > Hi all
>> >
>> > I would like to know the best approach in the graphics subsystem how
>> > deal with panels where the display area is different from the visible
>> > area because the display has a band left and right. I have already
>> > done the drm driver for the panel but from userspace point of view
>> > it's a pain to deal in wayland for input device and output device. Do
>> > you have any suggestions?
>>
>> Do you have the EDID for the panel?
>
> mipi->panel so should not have edid

That's the kind of information you'd expect in the original question. ;)

I've done that sort of thing in the past, but not sure if it would fly
upstream. Basically the kernel driver would lie about the resolution to
userspace, and handle the centering and the bands internally. In my
case, the DSI command mode panel in question had commands to set the
visible area, so the driver didn't have to do all that much extra to
make it happen.

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Graphics Center

[PATCH] drm/mediatek: Clarify/finish documentation for some driver structures

[AngeloGioacchino Del Regno]

The documentation for some of the driver structures in mediatek-drm
was set to be kerneldoc but some code additions didn't actually update
the comments accordingly and this caused triggering some warnings.

Add comments for the remaining undocumented entries; while at it, also
clarify some acronyms for various display HW blocks and fix some comment
blocks to actually get parsed as kerneldoc.

Signed-off-by: AngeloGioacchino Del Regno 

---
 drivers/gpu/drm/mediatek/mtk_disp_aal.c   |  8 +---
 drivers/gpu/drm/mediatek/mtk_disp_ccorr.c |  8 +---
 drivers/gpu/drm/mediatek/mtk_disp_color.c | 11 +++
 drivers/gpu/drm/mediatek/mtk_disp_gamma.c |  8 ++--
 drivers/gpu/drm/mediatek/mtk_disp_ovl.c   | 13 +
 drivers/gpu/drm/mediatek/mtk_disp_rdma.c  | 12 +---
 6 files changed, 41 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_disp_aal.c 
b/drivers/gpu/drm/mediatek/mtk_disp_aal.c
index 434e8a9ce8ab..12d1800c1d34 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_aal.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_aal.c
@@ -27,9 +27,11 @@ struct mtk_disp_aal_data {
 };
 
 /**
- * struct mtk_disp_aal - DISP_AAL driver structure
- * @ddp_comp - structure containing type enum and hardware resources
- * @crtc - associated crtc to report irq events to
+ * struct mtk_disp_aal - Display Adaptive Ambient Light driver structure
+ * @clk:  clock for DISP_AAL controller
+ * @regs: MMIO registers base
+ * @cmdq_reg: CMDQ Client register
+ * @data: platform specific data for DISP_AAL
  */
 struct mtk_disp_aal {
struct clk *clk;
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ccorr.c 
b/drivers/gpu/drm/mediatek/mtk_disp_ccorr.c
index 1773379b2439..b173aa058573 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ccorr.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ccorr.c
@@ -35,9 +35,11 @@ struct mtk_disp_ccorr_data {
 };
 
 /**
- * struct mtk_disp_ccorr - DISP_CCORR driver structure
- * @ddp_comp - structure containing type enum and hardware resources
- * @crtc - associated crtc to report irq events to
+ * struct mtk_disp_ccorr - Display Color Correction driver structure
+ * @clk:  clock for DISP_CCORR block
+ * @regs: MMIO registers base
+ * @cmdq_reg: CMDQ Client register
+ * @data: platform specific data for DISP_CCORR
  */
 struct mtk_disp_ccorr {
struct clk *clk;
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_color.c 
b/drivers/gpu/drm/mediatek/mtk_disp_color.c
index cac9206079e7..7884f4736b7c 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_color.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_color.c
@@ -31,10 +31,13 @@ struct mtk_disp_color_data {
unsigned int color_offset;
 };
 
-/*
- * struct mtk_disp_color - DISP_COLOR driver structure
- * @crtc: associated crtc to report irq events to
- * @data: platform colour driver data
+/**
+ * struct mtk_disp_color - DISP_COLOR (Display Color) driver structure
+ * @crtc: associated crtc to report irq events to
+ * @clk:  clock for DISP_COLOR block
+ * @regs: MMIO registers base
+ * @cmdq_reg: CMDQ Client register
+ * @data: platform specific data for DISP_COLOR
  */
 struct mtk_disp_color {
struct drm_crtc *crtc;
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c 
b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
index c844942603f7..7e748613fccb 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
@@ -31,8 +31,12 @@ struct mtk_disp_gamma_data {
bool lut_diff;
 };
 
-/*
- * struct mtk_disp_gamma - DISP_GAMMA driver structure
+/**
+ * struct mtk_disp_gamma - Display Gamma driver structure
+ * @clk:  clock for DISP_GAMMA block
+ * @regs: MMIO registers base
+ * @cmdq_reg: CMDQ Client register
+ * @data: platform data for DISP_GAMMA
  */
 struct mtk_disp_gamma {
struct clk *clk;
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c 
b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index 9d8c986700ee..00f2871fd1a4 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -76,10 +76,15 @@ struct mtk_disp_ovl_data {
bool supports_afbc;
 };
 
-/*
- * struct mtk_disp_ovl - DISP_OVL driver structure
- * @crtc: associated crtc to report vblank events to
- * @data: platform data
+/**
+ * struct mtk_disp_ovl - Display Overlay driver structure
+ * @crtc:   associated crtc to report vblank events to
+ * @clk:clock for DISP_OVL block
+ * @regs:   MMIO registers base
+ * @cmdq_reg:   CMDQ Client register
+ * @data:   platform data
+ * @vblank_cb:  vblank callback function
+ * @vblank_cb_data: pointer to data that will be passed to vblank_cb()
  */
 struct mtk_disp_ovl {
struct drm_crtc *crtc;
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c 
b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
index e8e337903b0d..74f4a0bce5cc 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
+++ 

Re: display band (display area vs real visible area)

[Michael Nazzareno Trimarchi]

Hi

On Tue, Mar 21, 2023 at 11:43 AM Jani Nikula
 wrote:
>
> On Tue, 21 Mar 2023, Michael Nazzareno Trimarchi 
>  wrote:
> > Hi all
> >
> > I would like to know the best approach in the graphics subsystem how
> > deal with panels where the display area is different from the visible
> > area because the display has a band left and right. I have already
> > done the drm driver for the panel but from userspace point of view
> > it's a pain to deal in wayland for input device and output device. Do
> > you have any suggestions?
>
> Do you have the EDID for the panel?

mipi->panel so should not have edid

Michael

>
> BR,
> Jani.
>
> --
> Jani Nikula, Intel Open Source Graphics Center



-- 
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
mich...@amarulasolutions.com
__

Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
i...@amarulasolutions.com
www.amarulasolutions.com

Re: [PATCH] drm: panel-orientation-quirks: Add quirk for Lenovo Yoga Book X90F

[Hans de Goede]

Hi,

On 3/13/23 16:39, Javier Martinez Canillas wrote:
> Hans de Goede  writes:
> 
> Hello Hans,
> 
>> Like the Windows Lenovo Yoga Book X91F/L the Android Lenovo Yoga Book
>> X90F/L has a portrait 1200x1920 screen used in landscape mode,
>> add a quirk for this.
>>
>> When the quirk for the X91F/L was initially added it was written to
>> also apply to the X90F/L but this does not work because the Android
>> version of the Yoga Book uses completely different DMI strings.
>> Also adjust the X91F/L quirk to reflect that it only applies to
>> the X91F/L models.
>>
>> Signed-off-by: Hans de Goede 
>> ---
> 
> Patch looks good to me.
> 
> Reviewed-by: Javier Martinez Canillas 

Thanks, I have pushed this to drm-misc-fixes now.

Regards,

Hans

Re: display band (display area vs real visible area)

[Jani Nikula]

On Tue, 21 Mar 2023, Michael Nazzareno Trimarchi  
wrote:
> Hi all
>
> I would like to know the best approach in the graphics subsystem how
> deal with panels where the display area is different from the visible
> area because the display has a band left and right. I have already
> done the drm driver for the panel but from userspace point of view
> it's a pain to deal in wayland for input device and output device. Do
> you have any suggestions?

Do you have the EDID for the panel?

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [PATCH v4 2/8] accel/qaic: Add uapi and core driver file

[Oded Gabbay]

On Mon, Mar 20, 2023 at 5:11 PM Jeffrey Hugo  wrote:
>
> Add the QAIC driver uapi file and core driver file that binds to the PCIe
> device. The core driver file also creates the accel device and manages
> all the interconnections between the different parts of the driver.
>
> The driver can be built as a module. If so, it will be called "qaic.ko".
>
> Signed-off-by: Jeffrey Hugo 
> Reviewed-by: Carl Vanderlip 
> Reviewed-by: Pranjal Ramajor Asha Kanojiya 
> Reviewed-by: Stanislaw Gruszka 
> ---
>  drivers/accel/qaic/qaic.h | 282 ++
>  drivers/accel/qaic/qaic_drv.c | 647 
> ++
>  include/uapi/drm/qaic_accel.h | 397 ++
>  3 files changed, 1326 insertions(+)
>  create mode 100644 drivers/accel/qaic/qaic.h
>  create mode 100644 drivers/accel/qaic/qaic_drv.c
>  create mode 100644 include/uapi/drm/qaic_accel.h
>
> diff --git a/drivers/accel/qaic/qaic.h b/drivers/accel/qaic/qaic.h
> new file mode 100644
> index 000..36c0d0ba
> --- /dev/null
> +++ b/drivers/accel/qaic/qaic.h
> @@ -0,0 +1,282 @@
> +/* SPDX-License-Identifier: GPL-2.0-only
> + *
> + * Copyright (c) 2019-2021, The Linux Foundation. All rights reserved.
> + * Copyright (c) 2021-2023 Qualcomm Innovation Center, Inc. All rights 
> reserved.
> + */
> +
> +#ifndef _QAIC_H_
> +#define _QAIC_H_
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define QAIC_DBC_BASE  SZ_128K
> +#define QAIC_DBC_SIZE  SZ_4K
> +
> +#define QAIC_NO_PARTITION  -1
> +
> +#define QAIC_DBC_OFF(i)((i) * QAIC_DBC_SIZE + QAIC_DBC_BASE)
> +
> +#define to_qaic_bo(obj) container_of(obj, struct qaic_bo, base)
> +
> +extern bool datapath_polling;
> +
> +struct qaic_user {
> +   /* Uniquely identifies this user for the device */
> +   int handle;
> +   struct kref ref_count;
> +   /* Char device opened by this user */
> +   struct qaic_drm_device  *qddev;
> +   /* Node in list of users that opened this drm device */
> +   struct list_headnode;
> +   /* SRCU used to synchronize this user during cleanup */
> +   struct srcu_struct  qddev_lock;
> +   atomic_tchunk_id;
> +};
> +
> +struct dma_bridge_chan {
> +   /* Pointer to device strcut maintained by driver */
> +   struct qaic_device  *qdev;
> +   /* ID of this DMA bridge channel(DBC) */
> +   unsigned intid;
> +   /* Synchronizes access to xfer_list */
> +   spinlock_t  xfer_lock;
> +   /* Base address of request queue */
> +   void*req_q_base;
> +   /* Base address of response queue */
> +   void*rsp_q_base;
> +   /*
> +* Base bus address of request queue. Response queue bus address can 
> be
> +* calculated by adding request queue size to this variable
> +*/
> +   dma_addr_t  dma_addr;
> +   /* Total size of request and response queue in byte */
> +   u32 total_size;
> +   /* Capacity of request/response queue */
> +   u32 nelem;
> +   /* The user that opened this DBC */
> +   struct qaic_user*usr;
> +   /*
> +* Request ID of next memory handle that goes in request queue. One
> +* memory handle can enqueue more than one request elements, all
> +* this requests that belong to same memory handle have same request 
> ID
> +*/
> +   u16 next_req_id;
> +   /* true: DBC is in use; false: DBC not in use */
> +   boolin_use;
> +   /*
> +* Base address of device registers. Used to read/write request and
> +* response queue's head and tail pointer of this DBC.
> +*/
> +   void __iomem*dbc_base;
> +   /* Head of list where each node is a memory handle queued in request 
> queue */
> +   struct list_headxfer_list;
> +   /* Synchronizes DBC readers during cleanup */
> +   struct srcu_struct  ch_lock;
> +   /*
> +* When this DBC is released, any thread waiting on this wait queue is
> +* woken up
> +*/
> +   wait_queue_head_t   dbc_release;
> +   /* Head of list where each node is a bo associated with this DBC */
> +   struct list_headbo_lists;
> +   /* The irq line for this DBC. Used for polling */
> +   unsigned intirq;
> +   /* Polling work item to simulate interrupts */
> +   struct work_struct  poll_work;
> +};
> +
> +struct qaic_device {
> +   /* Pointer to base PCI device struct of our physical device */
> +   struct pci_dev  *pdev;
> +   /* Req. ID of request that will be queued next in MHI control device 
> */
> +   u32   

display band (display area vs real visible area)

[Michael Nazzareno Trimarchi]

Hi all

I would like to know the best approach in the graphics subsystem how
deal with panels where the display area is different from the visible
area because the display has a band left and right. I have already
done the drm driver for the panel but from userspace point of view
it's a pain to deal in wayland for input device and output device. Do
you have any suggestions?

Regards
Michael

Re: [PATCH v29 1/7] dt-bindings: mediatek: add ethdr definition for mt8195

[AngeloGioacchino Del Regno]

Il 21/03/23 06:33, Nancy Lin (林欣螢) ha scritto:

Dear Angelo,

Sorry for late reply.

On Fri, 2023-03-17 at 10:58 +0100, AngeloGioacchino Del Regno wrote:

Il 17/03/23 10:52, Nancy Lin (林欣螢) ha scritto:

On Fri, 2023-03-17 at 10:37 +0100, AngeloGioacchino Del Regno
wrote:

Il 17/03/23 10:03, Krzysztof Kozlowski ha scritto:

On 17/03/2023 08:55, Nancy Lin (林欣螢) wrote:

On Thu, 2023-03-16 at 12:36 +0100, Krzysztof Kozlowski wrote:

On 16/03/2023 10:53, AngeloGioacchino Del Regno wrote:


Hello Krzysztof, Nancy,

Since this series has reached v29, can we please reach an
agreement
on the bindings
to use here, so that we can get this finally upstreamed?

I will put some examples to try to get this issue
resolved.

### Example 1: Constrain the number of GCE entries to
*seven*
array
elements (7x4!)

  mediatek,gce-client-reg:
$ref: /schemas/types.yaml#/definitions/phandle-
array
maxItems: 1
description: The register of display function
block to
be set
by gce.
  There are 4 arguments in this property, gce
node,
subsys id,
offset and
  register size. The subsys id is defined in the
gce
header of
each chips
  include/dt-bindings/gce/-gce.h, mapping to
the
register of display
  function block.
items:
  minItems: 28
  maxItems: 28
  items: <- this block
doesn't
seem to
get checked :\
- description: phandle of GCE
- description: GCE subsys id
- description: register offset
- description: register size


This is what we would like to have but it requires
exception in
dtschema. Thus:




### Example 2: Don't care about constraining the number
of
arguments

  mediatek,gce-client-reg:
$ref: /schemas/types.yaml#/definitions/phandle-
array
maxItems: 1
description: The register of display function
block to
be set
by gce.
  There are 4 arguments in this property, gce
node,
subsys id,
offset and
  register size. The subsys id is defined in the
gce
header of
each chips
  include/dt-bindings/gce/-gce.h, mapping to
the
register of display
  function block.


use this.

Best regards,
Krzysztof



Hi Krzysztof, Angelo,

Thanks for the comment.
The Example 2 can pass dt_binding_check.

But the example in the binding has 7 items [1] and dts [2].
Does
the
"maxItems: 1" affect any other schema or dts check?


Ah, then it should be maxItems: 7, not 1.



Keep in mind for your v30:

maxItems: 7 will pass - but only if minItems is *not* 7 :-)

-> (so, do not declare minItems, as default is 1) <-

Regards,
Angelo



Hi Angelo,

I still have one message [1] when runing dt_binding_check for
"example
2 + maxItems: 7" [2].

[1]
/proj/mtk19347/cros/src/third_party/kernel/v5.10/Documentation/devi
cetr
ee/bindings/display/mediatek/mediatek,ethdr.example.dtb:
hdr-engine@1c114000: mediatek,gce-client-reg: [[4294967295, 7,
16384,
4096, 4294967295, 7, 20480, 4096, 4294967295, 7, 28672, 4096,
4294967295, 7, 36864, 4096, 4294967295, 7, 40960, 4096, 4294967295,
7,
45056, 4096, 4294967295, 7, 49152, 4096]] is too short


[2]
 mediatek,gce-client-reg:
   $ref: /schemas/types.yaml#/definitions/phandle-array
   maxItems: 7
   description: The register of display function block to be set
by
gce.
 There are 4 arguments in this property, gce node, subsys
id,
offset and
 register size. The subsys id is defined in the gce header
of
each chips
 include/dt-bindings/gce/-gce.h, mapping to the
register of
display
 function block.



Maybe I'm wrong about the "do not declare minItems"... try with

minItems: 1
maxItems: 7


...does it work now?



Yes, It works well with "example2 + minItems:1 + maxItems: 7" [1]

[1]
   mediatek,gce-client-reg:
 $ref: /schemas/types.yaml#/definitions/phandle-array
 minItems: 1
 maxItems: 7
 description: The register of display function block to be set by
gce.
   There are 4 arguments in this property, gce node, subsys id,
offset and
   register size. The subsys id is defined in the gce header of each
chips
   include/dt-bindings/gce/-gce.h, mapping to the register of
display
   function block.



Please send a v30 with that solution ASAP then, so that we may perhaps *finally*
get it in for v6.4.

Regards,
Angelo

Re: [PATCH 06/37] drm/vkms/vkms_composer: Fix a few different kerneldoc formatting

[Melissa Wen]

O 03/20, Randy Dunlap wrote:
> 
> 
> On 3/20/23 16:46, Melissa Wen wrote:
> > On 03/17, Lee Jones wrote:
> >> Fixes the following W=1 kernel build warning(s):
> >>
> >>  drivers/gpu/drm/vkms/vkms_composer.c:41: warning: Function parameter or 
> >> member 'frame_info' not described in 'pre_mul_alpha_blend'
> >>  drivers/gpu/drm/vkms/vkms_composer.c:41: warning: Excess function 
> >> parameter 'src_frame_info' description in 'pre_mul_alpha_blend'
> >>  drivers/gpu/drm/vkms/vkms_composer.c:72: warning: Cannot understand  * 
> >> @wb_frame_info: The writeback frame buffer metadata
> >>
> >> Cc: Rodrigo Siqueira 
> >> Cc: Melissa Wen 
> >> Cc: Haneen Mohammed 
> >> Cc: Daniel Vetter 
> >> Cc: David Airlie 
> >> Cc: dri-devel@lists.freedesktop.org
> >> Signed-off-by: Lee Jones 
> >> ---
> >>  drivers/gpu/drm/vkms/vkms_composer.c | 6 --
> >>  1 file changed, 4 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/vkms/vkms_composer.c 
> >> b/drivers/gpu/drm/vkms/vkms_composer.c
> >> index 8e53fa80742b2..41668eedf4272 100644
> >> --- a/drivers/gpu/drm/vkms/vkms_composer.c
> >> +++ b/drivers/gpu/drm/vkms/vkms_composer.c
> >> @@ -22,7 +22,7 @@ static u16 pre_mul_blend_channel(u16 src, u16 dst, u16 
> >> alpha)
> >>  
> >>  /**
> >>   * pre_mul_alpha_blend - alpha blending equation
> >> - * @src_frame_info: source framebuffer's metadata
> >> + * @frame_info: source framebuffer's metadata
> >>   * @stage_buffer: The line with the pixels from src_plane
> >>   * @output_buffer: A line buffer that receives all the blends output
> >>   *
> >> @@ -69,11 +69,13 @@ static void fill_background(const struct 
> >> pixel_argb_u16 *background_color,
> >>  }
> >>  
> >>  /**
> >> - * @wb_frame_info: The writeback frame buffer metadata
> >> + * blend
> > As we are already here:
> > * blend - blend pixels from a given row and calculate crc
> 
>  * blend: blend pixels from a given row and calculate CRC
> 
> preferably.

Hmm.. I didn't get the colon suggestion. This first line is a brief
description of the function blend(), so I understand that a more
accurate doc standard is:

blend() - Blend pixels from a given row and calculate crc

Thanks,

Melissa

> 
> > Reviewed-by: Melissa Wen 
> > 
> >> + * @wb: The writeback frame buffer metadata
> >>   * @crtc_state: The crtc state
> >>   * @crc32: The crc output of the final frame
> >>   * @output_buffer: A buffer of a row that will receive the result of the 
> >> blend(s)
> >>   * @stage_buffer: The line with the pixels from plane being blend to the 
> >> output
> >> + * @row_size: Size of memory taken up by row data (line_width * 
> >> pixel_size)
> >>   *
> >>   * This function blends the pixels (Using the `pre_mul_alpha_blend`)
> >>   * from all planes, calculates the crc32 of the output from the former 
> >> step,
> >> -- 
> >> 2.40.0.rc1.284.g88254d51c5-goog
> >>
> 
> -- 
> ~Randy


signature.asc
Description: PGP signature

Re: [PATCH 00/10] drm/radeon: Convert fbdev to DRM client

[Thomas Zimmermann]

Hi

Am 20.03.23 um 16:23 schrieb Alex Deucher:

On Mon, Mar 20, 2023 at 11:19 AM Thomas Zimmermann  wrote:


Hi

Am 20.03.23 um 16:11 schrieb Christian König:

Am 17.03.23 um 10:20 schrieb Thomas Zimmermann:

Hi Christian

Am 17.03.23 um 09:53 schrieb Christian König:

Am 16.03.23 um 10:37 schrieb Thomas Zimmermann:

Convert radeon's fbdev code to drm_client. Replaces the current
ad-hoc integration. The conversion includes a number of cleanups.
Only build fbdev support if the config option has been set.


I'm torn apart on that. On the one hand it looks like a really nice
cleanup on the other hand we don't really want to touch radeon any more.


It's a driver in the upstream kernel. You have to expect at least some
changes.


Some changes is not the problem, but we need a justification to change
something. Just that it's nice to have won't do it without extensive
testing.





Alex what do you think? Is that worth the risk of breaking stuff?


Moving all fbdev emulation to struct drm_client is required for new
in-kernel DRM clients, such as a DRM kernel logger or a boot splash.


Well that's a rather good justification. I suggest to add that to the
cover-letter.


Ok, will go into a possible v2. The mid-term plan is to convert the
fbdev code in all remaining drivers to struct drm_client and remove the
old ad-hoc callbacks.

With struct drm_client, we can select in-kernel clients at compile time
or runtime just like userspace clients. I guess, we can have a bootup
screen and then switch to the console or the DRM logger. Or go from any
client to the logger on kernel panics (or something like that). There's
been occasional talk about userspace consoles, which would use such
functionality.


Patches look good to me.  I have a pretty limited set of HW I can test
on since I don't have a functional AGP system anymore and most of my
older PCIe radeons are packed up in the attic.  Feel free to add my:


I've tested the patches with an R5-based card.


Reviewed-by: Alex Deucher 
to the series.


Thank you so much. Do you want to take the patches into the amd tree?

Best regards
Thomas



Alex



Best regards
Thomas



Regards,
Christian.



Best regards
Thomas



Christian.



Thomas Zimmermann (10):
drm/radeon: Move radeon_align_pitch() next to dumb-buffer helpers
drm/radeon: Improve fbdev object-test helper
drm/radeon: Remove struct radeon_fbdev
drm/radeon: Remove test for !screen_base in fbdev probing
drm/radeon: Move fbdev object helpers before struct fb_ops et al
drm/radeon: Fix coding style in fbdev emulation
drm/radeon: Move fbdev cleanup code into fb_destroy callback
drm/radeon: Correctly clean up failed display probing
drm/radeon: Implement client-based fbdev emulation
drm/radeon: Only build fbdev if DRM_FBDEV_EMULATION is set

   drivers/gpu/drm/radeon/Makefile |   3 +-
   drivers/gpu/drm/radeon/radeon.h |   2 +
   drivers/gpu/drm/radeon/radeon_display.c |   4 -
   drivers/gpu/drm/radeon/radeon_drv.c |   3 +-
   drivers/gpu/drm/radeon/radeon_drv.h |   1 -
   drivers/gpu/drm/radeon/radeon_fb.c  | 400 --
   drivers/gpu/drm/radeon/radeon_fbdev.c   | 422

   drivers/gpu/drm/radeon/radeon_gem.c |  24 ++
   drivers/gpu/drm/radeon/radeon_kms.c |  18 -
   drivers/gpu/drm/radeon/radeon_mode.h|  20 +-
   10 files changed, 464 insertions(+), 433 deletions(-)
   delete mode 100644 drivers/gpu/drm/radeon/radeon_fb.c
   create mode 100644 drivers/gpu/drm/radeon/radeon_fbdev.c


base-commit: ec0708e846b819c8d5b642de42448a87d7526564








--
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


--
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