linux-next: manual merge of the drm-intel tree with Linus' tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the drm-intel tree got a conflict in:

  drivers/gpu/drm/i915/intel_device_info.h

between commit:

  5e3094cfd9fb ("drm/i915/xehpsdv: Add has_flat_ccs to device info")

from Linus' tree and commit:

  072ce4164f97 ("drm/i915/dg2: Tile 4 plane format support")

from the drm-intel tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/gpu/drm/i915/intel_device_info.h
index 291215d9da28,8026e805ff12..
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@@ -134,10 -131,9 +134,11 @@@ enum intel_ppgtt_type 
/* Keep has_* in alphabetical order */ \
func(has_64bit_reloc); \
func(has_64k_pages); \
 +  func(needs_compact_pt); \
func(gpu_reset_clobbers_display); \
func(has_reset_engine); \
 +  func(has_flat_ccs); \
+   func(has_4tile); \
func(has_global_mocs); \
func(has_gt_uc); \
func(has_guc_deprivilege); \


pgpDcYkRVbzLz.pgp
Description: OpenPGP digital signature

linux-next: manual merge of the drm-intel tree with Linus' tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the drm-intel tree got a conflict in:

  drivers/gpu/drm/i915/i915_pci.c

between commit:

  132aaaf01788 ("drm/i915: add needs_compact_pt flag")

from Linus' tree and commits:

  072ce4164f97 ("drm/i915/dg2: Tile 4 plane format support")
  412c942bdfae ("drm/i915/ats-m: add ATS-M platform info")

from the drm-intel tree.

I fixed it up (I think, see below) and can carry the fix as necessary.
This is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/gpu/drm/i915/i915_pci.c
index c32c0c6661c8,8e321d300e0c..
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@@ -1040,25 -1038,35 +1040,36 @@@ static const struct intel_device_info x
.require_force_probe = 1,
  };
  
+ #define DG2_FEATURES \
+   XE_HP_FEATURES, \
+   XE_HPM_FEATURES, \
+   DGFX_FEATURES, \
+   .graphics.rel = 55, \
+   .media.rel = 55, \
+   PLATFORM(INTEL_DG2), \
+   .has_4tile = 1, \
+   .has_64k_pages = 1, \
++  .needs_compact_pt = 1, \
+   .has_guc_deprivilege = 1, \
+   .platform_engine_mask = \
+   BIT(RCS0) | BIT(BCS0) | \
+   BIT(VECS0) | BIT(VECS1) | \
+   BIT(VCS0) | BIT(VCS2)
+ 
  __maybe_unused
  static const struct intel_device_info dg2_info = {
-   XE_HP_FEATURES,
-   XE_HPM_FEATURES,
+   DG2_FEATURES,
XE_LPD_FEATURES,
-   DGFX_FEATURES,
-   .graphics.rel = 55,
-   .media.rel = 55,
-   PLATFORM(INTEL_DG2),
-   .has_guc_deprivilege = 1,
-   .has_64k_pages = 1,
-   .needs_compact_pt = 1,
-   .platform_engine_mask =
-   BIT(RCS0) | BIT(BCS0) |
-   BIT(VECS0) | BIT(VECS1) |
-   BIT(VCS0) | BIT(VCS2),
-   .require_force_probe = 1,
.display.cpu_transcoder_mask = BIT(TRANSCODER_A) | BIT(TRANSCODER_B) |
   BIT(TRANSCODER_C) | BIT(TRANSCODER_D),
+   .require_force_probe = 1,
+ };
+ 
+ __maybe_unused
+ static const struct intel_device_info ats_m_info = {
+   DG2_FEATURES,
+   .display = { 0 },
+   .require_force_probe = 1,
  };
  
  #undef PLATFORM


pgpirGhHKUZ2a.pgp
Description: OpenPGP digital signature

[PATCH v2] drm/radeon: change si_default_state table from global to static

[Tom Rix]

Smatch reports these issues
si_blit_shaders.c:31:11: warning: symbol 'si_default_state'
  was not declared. Should it be static?
si_blit_shaders.c:253:11: warning: symbol 'si_default_size'
  was not declared. Should it be static?

Both symbols are only used in si.c.  Single file symbols
should be static.  So move the definition of
si_default_state and si_default_size to si_blit_shader.h
and change their storage-class-specifier to static.

Remove unneeded si_blit_shader.c

Signed-off-by: Tom Rix 
---
v2: move definitions to header

 drivers/gpu/drm/radeon/Makefile  |   2 +-
 drivers/gpu/drm/radeon/si_blit_shaders.c | 253 ---
 drivers/gpu/drm/radeon/si_blit_shaders.h | 223 +++-
 3 files changed, 222 insertions(+), 256 deletions(-)
 delete mode 100644 drivers/gpu/drm/radeon/si_blit_shaders.c

diff --git a/drivers/gpu/drm/radeon/Makefile b/drivers/gpu/drm/radeon/Makefile
index 11c97edde54d..664381f4eb07 100644
--- a/drivers/gpu/drm/radeon/Makefile
+++ b/drivers/gpu/drm/radeon/Makefile
@@ -44,7 +44,7 @@ radeon-y += radeon_device.o radeon_asic.o radeon_kms.o \
evergreen.o evergreen_cs.o evergreen_blit_shaders.o \
evergreen_hdmi.o radeon_trace_points.o ni.o cayman_blit_shaders.o \
atombios_encoders.o radeon_semaphore.o radeon_sa.o atombios_i2c.o si.o \
-   si_blit_shaders.o radeon_prime.o cik.o cik_blit_shaders.o \
+   radeon_prime.o cik.o cik_blit_shaders.o \
r600_dpm.o rs780_dpm.o rv6xx_dpm.o rv770_dpm.o rv730_dpm.o rv740_dpm.o \
rv770_smc.o cypress_dpm.o btc_dpm.o sumo_dpm.o sumo_smc.o trinity_dpm.o 
\
trinity_smc.o ni_dpm.o si_smc.o si_dpm.o kv_smc.o kv_dpm.o ci_smc.o \
diff --git a/drivers/gpu/drm/radeon/si_blit_shaders.c 
b/drivers/gpu/drm/radeon/si_blit_shaders.c
deleted file mode 100644
index ec415e7dfa4b..
--- a/drivers/gpu/drm/radeon/si_blit_shaders.c
+++ /dev/null
@@ -1,253 +0,0 @@
-/*
- * Copyright 2011 Advanced Micro Devices, Inc.
- *
- * Permission is hereby granted, free of charge, to any person obtaining a
- * copy of this software and associated documentation files (the "Software"),
- * to deal in the Software without restriction, including without limitation
- * the rights to use, copy, modify, merge, publish, distribute, sublicense,
- * and/or sell copies of the Software, and to permit persons to whom the
- * Software is furnished to do so, subject to the following conditions:
- *
- * The above copyright notice and this permission notice (including the next
- * paragraph) shall be included in all copies or substantial portions of the
- * Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
- * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
- * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
- * THE COPYRIGHT HOLDER(S) AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM, 
DAMAGES OR
- * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
- * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
- * DEALINGS IN THE SOFTWARE.
- *
- * Authors:
- * Alex Deucher 
- */
-
-#include 
-#include 
-#include 
-
-const u32 si_default_state[] =
-{
-   0xc0066900,
-   0x,
-   0x0060, /* DB_RENDER_CONTROL */
-   0x, /* DB_COUNT_CONTROL */
-   0x, /* DB_DEPTH_VIEW */
-   0x002a, /* DB_RENDER_OVERRIDE */
-   0x, /* DB_RENDER_OVERRIDE2 */
-   0x, /* DB_HTILE_DATA_BASE */
-
-   0xc0046900,
-   0x0008,
-   0x, /* DB_DEPTH_BOUNDS_MIN */
-   0x, /* DB_DEPTH_BOUNDS_MAX */
-   0x, /* DB_STENCIL_CLEAR */
-   0x, /* DB_DEPTH_CLEAR */
-
-   0xc0036900,
-   0x000f,
-   0x, /* DB_DEPTH_INFO */
-   0x, /* DB_Z_INFO */
-   0x, /* DB_STENCIL_INFO */
-
-   0xc0016900,
-   0x0080,
-   0x, /* PA_SC_WINDOW_OFFSET */
-
-   0xc00d6900,
-   0x0083,
-   0x, /* PA_SC_CLIPRECT_RULE */
-   0x, /* PA_SC_CLIPRECT_0_TL */
-   0x20002000, /* PA_SC_CLIPRECT_0_BR */
-   0x,
-   0x20002000,
-   0x,
-   0x20002000,
-   0x,
-   0x20002000,
-   0x, /* PA_SC_EDGERULE */
-   0x, /* PA_SU_HARDWARE_SCREEN_OFFSET */
-   0x000f, /* CB_TARGET_MASK */
-   0x000f, /* CB_SHADER_MASK */
-
-   0xc0226900,
-   0x0094,
-   0x8000, /* PA_SC_VPORT_SCISSOR_0_TL */
-   0x20002000, /* PA_SC_VPORT_SCISSOR_0_BR */
-   0x8000,
-   0x20002000,
-   0x8000,
-   0x20002000,
-   0x8000,
-   0x20002000,
-   0x8000,
-   0x20002000,
-   0x8000,
-   0x20002000,
-   0x8000,
-   0x20002000,
-   0x8000,
-   0x20002000,
-   0x8000,
-   0x20002000,
-   0x8000,
-   0x20002000,
-   

Re: [PATCH v2] drm/scheduler: quieten kernel-doc warnings

[Andrey Grodzovsky]

Reviewed-by: Andrey Grodzovsky 
Andrey

On 2022-04-04 17:30, Randy Dunlap wrote:

Fix kernel-doc warnings in gpu_scheduler.h and sched_main.c.

Quashes these warnings:

include/drm/gpu_scheduler.h:332: warning: missing initial short description on 
line:
  * struct drm_sched_backend_ops
include/drm/gpu_scheduler.h:412: warning: missing initial short description on 
line:
  * struct drm_gpu_scheduler
include/drm/gpu_scheduler.h:461: warning: Function parameter or member 'dev' 
not described in 'drm_gpu_scheduler'

drivers/gpu/drm/scheduler/sched_main.c:201: warning: missing initial short 
description on line:
  * drm_sched_dependency_optimized
drivers/gpu/drm/scheduler/sched_main.c:995: warning: Function parameter or 
member 'dev' not described in 'drm_sched_init'

Fixes: 2d33948e4e00 ("drm/scheduler: add documentation")
Fixes: 8ab62eda177b ("drm/sched: Add device pointer to drm_gpu_scheduler")
Fixes: 542cff7893a3 ("drm/sched: Avoid lockdep spalt on killing a processes")
Signed-off-by: Randy Dunlap 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Andrey Grodzovsky 
Cc: Nayan Deshmukh 
Cc: Alex Deucher 
Cc: Christian König 
Cc: Jiawei Gu 
Cc: dri-devel@lists.freedesktop.org
Acked-by: Christian König 
---
Feel free to make changes or suggest changes...

v2: drop @work description (already done by Andrey)

  drivers/gpu/drm/scheduler/sched_main.c |3 ++-
  include/drm/gpu_scheduler.h|9 +
  2 files changed, 7 insertions(+), 5 deletions(-)

--- linux-next-20220404.orig/drivers/gpu/drm/scheduler/sched_main.c
+++ linux-next-20220404/drivers/gpu/drm/scheduler/sched_main.c
@@ -198,7 +198,7 @@ static void drm_sched_job_done_cb(struct
  }
  
  /**

- * drm_sched_dependency_optimized
+ * drm_sched_dependency_optimized - test if the dependency can be optimized
   *
   * @fence: the dependency fence
   * @entity: the entity which depends on the above fence
@@ -984,6 +984,7 @@ static int drm_sched_main(void *param)
   *used
   * @score: optional score atomic shared with other schedulers
   * @name: name used for debugging
+ * @dev: target  device
   *
   * Return 0 on success, otherwise error code.
   */
--- linux-next-20220404.orig/include/drm/gpu_scheduler.h
+++ linux-next-20220404/include/drm/gpu_scheduler.h
@@ -328,10 +328,10 @@ enum drm_gpu_sched_stat {
  };
  
  /**

- * struct drm_sched_backend_ops
+ * struct drm_sched_backend_ops - Define the backend operations
+ * called by the scheduler
   *
- * Define the backend operations called by the scheduler,
- * these functions should be implemented in driver side.
+ * These functions should be implemented in the driver side.
   */
  struct drm_sched_backend_ops {
/**
@@ -408,7 +408,7 @@ struct drm_sched_backend_ops {
  };
  
  /**

- * struct drm_gpu_scheduler
+ * struct drm_gpu_scheduler - scheduler instance-specific data
   *
   * @ops: backend operations provided by the driver.
   * @hw_submission_limit: the max size of the hardware queue.
@@ -434,6 +434,7 @@ struct drm_sched_backend_ops {
   * @_score: score used when the driver doesn't provide one
   * @ready: marks if the underlying HW is ready to work
   * @free_guilty: A hit to time out handler to free the guilty job.
+ * @dev: system  device
   *
   * One scheduler is implemented for each hardware ring.
   */

Re: [Intel-gfx] [PATCH 15/15] drm/i915/xehp: Eliminate shared/implicit steering

[Matt Roper]

On Fri, Apr 01, 2022 at 09:34:04AM +0100, Tvrtko Ursulin wrote:
> 
> On 31/03/2022 00:28, Matt Roper wrote:
> > Historically we've selected and programmed a single MCR group/instance
> > ID at driver startup that will steer register accesses for GSLICE/DSS
> > ranges to a non-terminated instance.  Any reads of these register ranges
> > that don't need a specific unicast access won't bother explicitly
> > resteering because the control register should already be set to a
> > suitable value to receive a non-terminated response.  Any accesses to
> > other types of MCR ranges (MSLICE, LNCF, etc.) that are also satisfied
> > by the default steering target will also skip explicit re-steering at
> > runtime.
> > 
> > This approach has worked well for many years and many platforms, but our
> > hardware teams have recently advised us that they're not 100%
> > comfortable with our strategy going forward.  They now suggest
> > explicitly steering reads of any multicast register at the time the
> > register access happens rather than relying on previously-programmed
> > steering values.  In debug settings there could be external agents that
> > have adjusted the default steering without the driver's knowledge (e.g.,
> > we could do this manually with IGT's intel_reg today, although the
> > hardware teams also have other tools they use for debug and analysis).
> > In theory it would also be possible for bad firmware and/or incorrect
> > handling of power management events to clobber/wipe the steering
> > value we had previously initialized because they assume we'll be
> > re-programming it anyway.
> > 
> > Signed-off-by: Matt Roper 
> > ---
> >   drivers/gpu/drm/i915/gt/intel_gt_mcr.c  | 40 +
> >   drivers/gpu/drm/i915/gt/intel_gt_types.h|  1 +
> >   drivers/gpu/drm/i915/gt/intel_workarounds.c | 98 -
> >   3 files changed, 56 insertions(+), 83 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c 
> > b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> > index a9a9fa6881f2..787752367337 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> > @@ -35,6 +35,7 @@
> >*/
> >   static const char * const intel_steering_types[] = {
> > +   "GSLICE/DSS",
> > "L3BANK",
> > "MSLICE",
> > "LNCF",
> > @@ -45,6 +46,35 @@ static const struct intel_mmio_range 
> > icl_l3bank_steering_table[] = {
> > {},
> >   };
> > +static const struct intel_mmio_range xehpsdv_dss_steering_table[] = {
> > +   { 0x005200, 0x0052FF },
> > +   { 0x005400, 0x007FFF },
> > +   { 0x008140, 0x00815F },
> > +   { 0x008D00, 0x008DFF },
> > +   { 0x0094D0, 0x00955F },
> > +   { 0x009680, 0x0096FF },
> > +   { 0x00DC00, 0x00DCFF },
> > +   { 0x00DE80, 0x00E8FF },
> > +   { 0x017000, 0x017FFF },
> > +   { 0x024A00, 0x024A7F },
> > +   {},
> > +};
> > +
> > +static const struct intel_mmio_range dg2_dss_steering_table[] = {
> > +   { 0x005200, 0x0052FF },
> > +   { 0x005400, 0x007FFF },
> > +   { 0x008140, 0x00815F },
> > +   { 0x008D00, 0x008DFF },
> > +   { 0x0094D0, 0x00955F },
> > +   { 0x009680, 0x0096FF },
> > +   { 0x00D800, 0x00D87F },
> > +   { 0x00DC00, 0x00DCFF },
> > +   { 0x00DE80, 0x00E8FF },
> > +   { 0x017000, 0x017FFF },
> > +   { 0x024A00, 0x024A7F },
> > +   {},
> > +};
> > +
> >   static const struct intel_mmio_range xehpsdv_mslice_steering_table[] = {
> > { 0x004000, 0x004AFF },
> > { 0x00C800, 0x00CFFF },
> > @@ -87,9 +117,11 @@ void intel_gt_mcr_init(struct intel_gt *gt)
> >  GEN12_MEML3_EN_MASK);
> > if (IS_DG2(i915)) {
> > +   gt->steering_table[DSS] = dg2_dss_steering_table;
> > gt->steering_table[MSLICE] = xehpsdv_mslice_steering_table;
> > gt->steering_table[LNCF] = dg2_lncf_steering_table;
> > } else if (IS_XEHPSDV(i915)) {
> > +   gt->steering_table[DSS] = xehpsdv_dss_steering_table;
> > gt->steering_table[MSLICE] = xehpsdv_mslice_steering_table;
> > gt->steering_table[LNCF] = xehpsdv_lncf_steering_table;
> > } else if (GRAPHICS_VER(i915) >= 11 &&
> > @@ -317,7 +349,15 @@ static void get_valid_steering(struct intel_gt *gt,
> >enum intel_steering_type type,
> >u8 *group, u8 *instance)
> >   {
> > +   u32 dssmask = intel_sseu_get_subslices(>info.sseu, 0);
> > +
> > switch (type) {
> > +   case DSS:
> > +   drm_WARN_ON(>i915->drm, dssmask == 0);
> > +
> > +   *group = __ffs(dssmask) / GEN_DSS_PER_GSLICE;
> > +   *instance = __ffs(dssmask) % GEN_DSS_PER_GSLICE;
> > +   break;
> > case L3BANK:
> > GEM_DEBUG_WARN_ON(!gt->info.l3bank_mask); /* should be 
> > impossible! */
> > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h 
> > b/drivers/gpu/drm/i915/gt/intel_gt_types.h
> > index 937b2e1a305e..b77bbaac7622 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
> > +++ 

Re: [PATCH] drm/format_helper: fix a kernel-doc typo

[Randy Dunlap]

Hi Simon,

On 4/4/22 09:04, Simon Ser wrote:
> Both doc patches pushed, thanks. I had to manually edit them because they
> wouldn't apply cleanly. Next time, please use git-send-email (see
> https://git-send-email.io/ for setup instructions).

That's odd. I did use 'git send-email' and I don't usually have any
problems (AFAIK). I'll check those setup instructions.

thanks.
-- 
~Randy

Re: [Intel-gfx] [PATCH 15/15] drm/i915/xehp: Eliminate shared/implicit steering

[Matt Roper]

On Thu, Mar 31, 2022 at 06:35:52PM +0100, Tvrtko Ursulin wrote:
> 
> On 31/03/2022 00:28, Matt Roper wrote:
> > Historically we've selected and programmed a single MCR group/instance
> > ID at driver startup that will steer register accesses for GSLICE/DSS
> > ranges to a non-terminated instance.  Any reads of these register ranges
> > that don't need a specific unicast access won't bother explicitly
> > resteering because the control register should already be set to a
> > suitable value to receive a non-terminated response.  Any accesses to
> > other types of MCR ranges (MSLICE, LNCF, etc.) that are also satisfied
> > by the default steering target will also skip explicit re-steering at
> > runtime.
> > 
> > This approach has worked well for many years and many platforms, but our
> > hardware teams have recently advised us that they're not 100%
> > comfortable with our strategy going forward.  They now suggest
> > explicitly steering reads of any multicast register at the time the
> > register access happens rather than relying on previously-programmed
> > steering values.  In debug settings there could be external agents that
> > have adjusted the default steering without the driver's knowledge (e.g.,
> > we could do this manually with IGT's intel_reg today, although the
> > hardware teams also have other tools they use for debug and analysis).
> > In theory it would also be possible for bad firmware and/or incorrect
> > handling of power management events to clobber/wipe the steering
> > value we had previously initialized because they assume we'll be
> > re-programming it anyway.
> 
> That external agent of any kind can mess with registers behind drivers back
> is kind of a weak justification, no? Because steering is just one small part
> of what can go wrong in this case.

Apparently the assumption when the hardware was designed was that
software would explicitly steer every MCR access; they never really
considered the design we've been using where we try to set it up once
and try to minimize subsequent updates to the steering control.  In a
lot of cases different agents updating steering have their own steering
control registers (i.e., the GuC, the command streamers, and a couple
other internal hardware units have their own independent steering
control registers to try to avoid racing with whatever the KMD/CPU is
doing), but I think there may have been some cases that aren't 100%
covered there.

This is also partially motivated by the direction the general hardware
teams want to move in the future --- they plan to reduce the number of
different steering control registers for different agents and make more
of them share a single register with the KMD/CPU.  There will be a
separate "semaphore" register used for coordinating access between
various agents (of course that will bring new challenges such as
increased latency and what to do if some hardware unit grabs the
semaphore and somehow fails to release it).

> 
> Also, someone at some point has to know which are the affected registers. Be
> it a range table, or at actual point of submitting patches which add
> register definitions. At any of those points mistakes are possible.

True.  But today there are a lot of registers used by the driver that
are multicast and I don't think the code written around them was really
thinking about the multicast semantics of the register, especially when
the code was copy/pasted from earlier platforms where they weren't
multicast (the TLB invalidation registers are an example --- should we
be waiting for an ack to come back on every mslice rather than just on a
single random mslice?).  MCR registers seem to be an area that's pretty
mysterious to a lot of people that haven't looked at them carefully, and
sometimes doing a simple intel_uncore_{read,write} doesn't accomplish
what you'd expect; forcing us to be a bit more deliberate about the type
of behavior we expect to get seems like it will help reduce mistakes in
the long run.

> 
> So I guess I am not immediately buying the need to refactor all this. Apart
> from churn, the main downside that I see is that all accesses need separate
> helpers. Question is why. Driver could choose to always steer before reading
> today, right?

You mean like making intel_uncore_read always do a steering table lookup
for all registers?  We could, although I'm a bit hesitant to add even
more GT-specific logic to the uncore functions that are used for non-GT
purposes as well.  And like I said before, it still hides the fact that
there may be multiple register instances and you're just reading one
semi-random instance.


Matt

> 
> Regards,
> 
> Tvrtko
> 
> > 
> > Signed-off-by: Matt Roper 
> > ---
> >   drivers/gpu/drm/i915/gt/intel_gt_mcr.c  | 40 +
> >   drivers/gpu/drm/i915/gt/intel_gt_types.h|  1 +
> >   drivers/gpu/drm/i915/gt/intel_workarounds.c | 98 -
> >   3 files changed, 56 insertions(+), 83 deletions(-)
> > 
> > diff --git 

[PATCH v2] drm/scheduler: quieten kernel-doc warnings

[Randy Dunlap]

Fix kernel-doc warnings in gpu_scheduler.h and sched_main.c.

Quashes these warnings:

include/drm/gpu_scheduler.h:332: warning: missing initial short description on 
line:
 * struct drm_sched_backend_ops
include/drm/gpu_scheduler.h:412: warning: missing initial short description on 
line:
 * struct drm_gpu_scheduler
include/drm/gpu_scheduler.h:461: warning: Function parameter or member 'dev' 
not described in 'drm_gpu_scheduler'

drivers/gpu/drm/scheduler/sched_main.c:201: warning: missing initial short 
description on line:
 * drm_sched_dependency_optimized
drivers/gpu/drm/scheduler/sched_main.c:995: warning: Function parameter or 
member 'dev' not described in 'drm_sched_init'

Fixes: 2d33948e4e00 ("drm/scheduler: add documentation")
Fixes: 8ab62eda177b ("drm/sched: Add device pointer to drm_gpu_scheduler")
Fixes: 542cff7893a3 ("drm/sched: Avoid lockdep spalt on killing a processes")
Signed-off-by: Randy Dunlap 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Andrey Grodzovsky 
Cc: Nayan Deshmukh 
Cc: Alex Deucher 
Cc: Christian König 
Cc: Jiawei Gu 
Cc: dri-devel@lists.freedesktop.org
Acked-by: Christian König 
---
Feel free to make changes or suggest changes...

v2: drop @work description (already done by Andrey)

 drivers/gpu/drm/scheduler/sched_main.c |3 ++-
 include/drm/gpu_scheduler.h|9 +
 2 files changed, 7 insertions(+), 5 deletions(-)

--- linux-next-20220404.orig/drivers/gpu/drm/scheduler/sched_main.c
+++ linux-next-20220404/drivers/gpu/drm/scheduler/sched_main.c
@@ -198,7 +198,7 @@ static void drm_sched_job_done_cb(struct
 }
 
 /**
- * drm_sched_dependency_optimized
+ * drm_sched_dependency_optimized - test if the dependency can be optimized
  *
  * @fence: the dependency fence
  * @entity: the entity which depends on the above fence
@@ -984,6 +984,7 @@ static int drm_sched_main(void *param)
  * used
  * @score: optional score atomic shared with other schedulers
  * @name: name used for debugging
+ * @dev: target  device
  *
  * Return 0 on success, otherwise error code.
  */
--- linux-next-20220404.orig/include/drm/gpu_scheduler.h
+++ linux-next-20220404/include/drm/gpu_scheduler.h
@@ -328,10 +328,10 @@ enum drm_gpu_sched_stat {
 };
 
 /**
- * struct drm_sched_backend_ops
+ * struct drm_sched_backend_ops - Define the backend operations
+ * called by the scheduler
  *
- * Define the backend operations called by the scheduler,
- * these functions should be implemented in driver side.
+ * These functions should be implemented in the driver side.
  */
 struct drm_sched_backend_ops {
/**
@@ -408,7 +408,7 @@ struct drm_sched_backend_ops {
 };
 
 /**
- * struct drm_gpu_scheduler
+ * struct drm_gpu_scheduler - scheduler instance-specific data
  *
  * @ops: backend operations provided by the driver.
  * @hw_submission_limit: the max size of the hardware queue.
@@ -434,6 +434,7 @@ struct drm_sched_backend_ops {
  * @_score: score used when the driver doesn't provide one
  * @ready: marks if the underlying HW is ready to work
  * @free_guilty: A hit to time out handler to free the guilty job.
+ * @dev: system  device
  *
  * One scheduler is implemented for each hardware ring.
  */

Re: [PATCH v6 8/8] drm/msm/dp: Handle eDP mode_valid differently from dp

[Dmitry Baryshkov]

On Mon, 4 Apr 2022 at 21:21, Sankeerth Billakanti (QUIC)
 wrote:
>
> Hi Doug,
>
> > On Wed, Mar 30, 2022 at 11:02 PM Sankeerth Billakanti (QUIC)
> >  wrote:
> > >
> > > Hi Dmitry,
> > >
> > > > On Wed, 30 Mar 2022 at 19:04, Sankeerth Billakanti
> > > >  wrote:
> > > > >
> > > > > The panel-edp driver modes needs to be validated differently from
> > > > > DP because the link capabilities are not available for EDP by that 
> > > > > time.
> > > > >
> > > > > Signed-off-by: Sankeerth Billakanti 
> > > >
> > > > This should not be necessary after
> > > >
> > https://patchwork.freedesktop.org/patch/479261/?series=101682=1.
> > > > Could you please check?
> > > >
> > >
> > > The check for DP_MAX_PIXEL_CLK_KHZ is not necessary anymore but we
> > > need to return early for eDP because unlike DP, eDP context will not
> > > have the information about the number of lanes and link clock.
> > >
> > > So, I will modify the patch to return after the DP_MAX_PIXEL_CLK_KHZ
> > check if is_eDP is set.
> >
> > I haven't walked through all the relevant code but something you said above
> > sounds strange. You say that for eDP we don't have info about the number
> > of lanes? We _should_.
> >
> > It's certainly possible to have a panel that supports _either_ 1 or 2 lanes 
> > but
> > then only physically connect 1 lane to it. ...or you could have a panel that
> > supports 2 or 4 lanes and you only connect 1 lane.
> > See, for instance, ti_sn_bridge_parse_lanes. There we assume 4 lanes but if
> > a "data-lanes" property is present then we can use that to know that fewer
> > lanes are physically connected.
> >
> > It's also possible to connect more lanes to a panel than it supports.
> > You could connect 2 lanes to it but then it only supports 1. This case 
> > needs to
> > be handled as well...
> >
>
> I was referring to the checks we do for DP in dp_bridge_mode_valid. We check 
> if the
> Link bandwidth can support the pixel bandwidth. For an external DP 
> connection, the
> Initial DPCD/EDID read after cable connection will return the sink 
> capabilities like link
> rate, lane count and bpp information that are used to we filter out the 
> unsupported
> modes from the list of modes from EDID.
>
> For eDP case, the dp driver performs the first dpcd read during 
> bridge_enable. The
> dp_bridge_mode_valid function is executed before bridge_enable and hence does
> not have the full link or the sink capabilities information like external DP 
> connection,
> by then.

It sounds to me like we should emulate the HPD event for eDP to be
handled earlier than the get_modes()/prepare() calls are attempted.
However this might open another can of worms.

> So, we need to proceed with the reported mode for eDP.

Well... Even if during the first call to get_modes() the DPCD is not
read, during subsequent calls the driver has necessary information, so
it can proceed with all the checks, can't it?

-- 
With best wishes
Dmitry

Re: [PATCH] clk: base: fix an incorrect NULL check on list iterator

[Lyude Paul]

This should probably be prefixed with the title "drm/nouveau/clk:", but I can
fix that before pushing it.

Reviewed-by: Lyude Paul 

Will push it to the appropriate repository shortly


On Sun, 2022-03-27 at 15:58 +0800, Xiaomeng Tong wrote:
> The bug is here:
> if (nvkm_cstate_valid(clk, cstate, max_volt, clk->temp))
> return cstate;
> 
> The list iterator value 'cstate' will *always* be set and non-NULL
> by list_for_each_entry_from_reverse(), so it is incorrect to assume
> that the iterator value will be unchanged if the list is empty or no
> element is found (In fact, it will be a bogus pointer to an invalid
> structure object containing the HEAD). Also it missed a NULL check
> at callsite and may lead to invalid memory access after that.
> 
> To fix this bug, just return 'encoder' when found, otherwise return
> NULL. And add the NULL check.
> 
> Cc: sta...@vger.kernel.org
> Fixes: 1f7f3d91ad38a ("drm/nouveau/clk: Respect voltage limits in
> nvkm_cstate_prog")
> Signed-off-by: Xiaomeng Tong 
> ---
>  drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c
> b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c
> index 57199be082fd..c2b5cc5f97ed 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c
> @@ -135,10 +135,10 @@ nvkm_cstate_find_best(struct nvkm_clk *clk, struct
> nvkm_pstate *pstate,
>  
> list_for_each_entry_from_reverse(cstate, >list, head) {
> if (nvkm_cstate_valid(clk, cstate, max_volt, clk->temp))
> -   break;
> +   return cstate;
> }
>  
> -   return cstate;
> +   return NULL;
>  }
>  
>  static struct nvkm_cstate *
> @@ -169,6 +169,8 @@ nvkm_cstate_prog(struct nvkm_clk *clk, struct
> nvkm_pstate *pstate, int cstatei)
> if (!list_empty(>list)) {
> cstate = nvkm_cstate_get(clk, pstate, cstatei);
> cstate = nvkm_cstate_find_best(clk, pstate, cstate);
> +   if (!cstate)
> +   return -EINVAL;
> } else {
> cstate = >base;
> }

-- 
Cheers,
 Lyude Paul (she/her)
 Software Engineer at Red Hat

Re: [PATCH v6 7/8] drm/msm/dp: Support edp/dp without hpd

[Dmitry Baryshkov]

On Mon, 4 Apr 2022 at 21:32, Sankeerth Billakanti (QUIC)
 wrote:
>
> Hi Doug,
>
> > On Wed, Mar 30, 2022 at 9:04 AM Sankeerth Billakanti
> >  wrote:
> > >
> > > Some eDP sinks or platform boards will not support hpd.
> > > This patch adds support for those cases.
> >
> > You could say more, like:
> >
> > If we're not using HPD then _both_ the panel node and the eDP controller
> > node will have "no-hpd". This tells the eDP panel code to hardcode the
> > maximum possible delay for a panel to power up and tells the eDP driver that
> > it should continue to do transfers even if HPD isn't asserted.
> >
>
> Okay. I will add it
>
> >
> > > Signed-off-by: Sankeerth Billakanti 
> > > ---
> > >  drivers/gpu/drm/msm/dp/dp_catalog.c | 15 ---
> > >  1 file changed, 12 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.c
> > > b/drivers/gpu/drm/msm/dp/dp_catalog.c
> > > index 1809ce2..8f1fc71 100644
> > > --- a/drivers/gpu/drm/msm/dp/dp_catalog.c
> > > +++ b/drivers/gpu/drm/msm/dp/dp_catalog.c
> > > @@ -244,10 +244,17 @@ void dp_catalog_aux_update_cfg(struct
> > dp_catalog
> > > *dp_catalog)
> > >
> > >  int dp_catalog_aux_wait_for_hpd_connect_state(struct dp_catalog
> > > *dp_catalog)  {
> > > -   u32 state;
> > > +   u32 state, hpd_en;
> > > struct dp_catalog_private *catalog = container_of(dp_catalog,
> > > struct dp_catalog_private,
> > > dp_catalog);
> > >
> > > +   hpd_en = dp_read_aux(catalog, REG_DP_DP_HPD_CTRL);
> > > +   hpd_en &= DP_DP_HPD_CTRL_HPD_EN;
> > > +
> > > +   /* no-hpd case */
> > > +   if (!hpd_en)
> > > +   return 0;
> > > +
> > > /* poll for hpd connected status every 2ms and timeout after 
> > > 500ms */
> > > return readl_poll_timeout(catalog->io->dp_controller.aux.base +
> > > REG_DP_DP_HPD_INT_STATUS, @@ -586,8
> > > +593,10 @@ void dp_catalog_ctrl_hpd_config(struct dp_catalog
> > *dp_catalog)
> > > reftimer |= DP_DP_HPD_REFTIMER_ENABLE;
> > > dp_write_aux(catalog, REG_DP_DP_HPD_REFTIMER, reftimer);
> > >
> > > -   /* Enable HPD */
> > > -   dp_write_aux(catalog, REG_DP_DP_HPD_CTRL,
> > DP_DP_HPD_CTRL_HPD_EN);
> > > +   /* Enable HPD if supported*/
> > > +   if (!of_property_read_bool(catalog->dev->of_node, "no-hpd"))
> >
> > I don't think this is a particularly lightweight operation. It's literally 
> > iterating
> > through all of our device tree properties and doing string compares on them.
> > ...but this function is called somewhat often, isn't it? It feels like the 
> > kind of
> > thing that should happen at probe time and be stored in a boolean.
> >
> > ...and then you can use that same boolean in
> > dp_catalog_aux_wait_for_hpd_connect_state() rather than reading the
> > register value, right?
> >
> It is called twice for DP. Once while booting through a thread scheduled from 
> kms_obj_init
> and when resuming from PM suspend.
>
> With aux_bus addition, this function will be called thrice for eDP. Once 
> during bootup with
> aux_bus, then from scheduled event from kms_obj_init and pm resume like DP.
>
> I will check if we can use a no-hpd Boolean flag instead.

As the driver has a separate dp_parser code, it might be a good fit to
parse the DT once and then to use boolean flag afterwards.

-- 
With best wishes
Dmitry

Re: [PATCH v6 6/8] drm/msm/dp: remove unnecessary delay during boot

[Dmitry Baryshkov]

On Mon, 4 Apr 2022 at 16:53, Sankeerth Billakanti (QUIC)
 wrote:
>
> Hi Doug,
>
> > On Wed, Mar 30, 2022 at 9:04 AM Sankeerth Billakanti
> >  wrote:
> > >
> > > Remove the unnecessary delay in executing the EV_HPD_INIT_SETUP
> > event.
> >
> > Tell me more and put it in the commit message! Why did it used to be
> > necessary and why is it no longer necessary? Inquiring minds want to know.
> >
>
> Okay. I will add proper description. The DP phy is shared with usb and 
> executing the
> dp phy_init before the usb phy_init was causing usb devices to not function.

I always wondered, how does this work for the 4-lane DP dongles, where
there is no USB mode/lanes?

> Earlier, enabling phy_init was done when the EV_HPD_INIT_SETUP event was 
> executed.
> So, we had scheduled it to execute after 10 second to let the usb driver 
> complete the phy_init first.
>
> Kuogee made the below change to move the DP phy_init to execute after the DP 
> is connected
> https://patchwork.kernel.org/project/linux-arm-msm/patch/1642531648-8448-2-git-send-email-quic_khs...@quicinc.com/
>
> So, there is no need for the DP driver to wait 10 seconds for the phy 
> initialization anymore.
>
> eDP PHY is not shared with usb. So, it can be programmed anytime, hence not 
> needing any delay.



-- 
With best wishes
Dmitry

Re: [Intel-gfx] [PATCH 14/15] drm/i915: Define multicast registers as a new type

[Matt Roper]

On Fri, Apr 01, 2022 at 08:55:19AM +0100, Tvrtko Ursulin wrote:
> 
> On 31/03/2022 00:28, Matt Roper wrote:
> > Rather than treating multicast registers as 'i915_reg_t' let's define
> > them as a completely new type.  This will allow the compiler to help us
> > make sure we're using multicast-aware functions to operate on multicast
> > registers.
> > 
> > This plan does break down a bit in places where we're just maintaining
> > heterogeneous lists of registers (e.g., various MMIO whitelists used by
> > perf, GVT, etc.) rather than performing reads/writes.  We only really
> > care about the offset in those cases, so for now we can "cast" the
> > registers as non-MCR, leaving us with a list of i915_reg_t's, but we may
> > want to look for better ways to store mixed collections of i915_reg_t
> > and i915_mcr_reg_t in the future.
> > 
> > Signed-off-by: Matt Roper 
> > ---
> >   drivers/gpu/drm/i915/gt/intel_gt_mcr.c| 49 ---
> >   drivers/gpu/drm/i915/gt/intel_gt_mcr.h| 14 +++---
> >   drivers/gpu/drm/i915/gt/intel_gt_regs.h   | 27 +++---
> >   drivers/gpu/drm/i915/gt/intel_lrc.c   |  6 +--
> >   drivers/gpu/drm/i915/gt/intel_workarounds.c   | 32 +++-
> >   .../gpu/drm/i915/gt/selftest_workarounds.c|  2 +-
> >   drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c|  4 +-
> >   .../gpu/drm/i915/gt/uc/intel_guc_capture.c|  4 +-
> >   drivers/gpu/drm/i915/gvt/cmd_parser.c |  2 +-
> >   drivers/gpu/drm/i915/gvt/handlers.c   | 17 ---
> >   drivers/gpu/drm/i915/gvt/mmio_context.c   | 14 +++---
> >   drivers/gpu/drm/i915/i915_perf.c  |  2 +-
> >   drivers/gpu/drm/i915/i915_reg_defs.h  |  9 
> >   13 files changed, 113 insertions(+), 69 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c 
> > b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> > index c8e52d625f18..a9a9fa6881f2 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> > @@ -103,6 +103,19 @@ void intel_gt_mcr_init(struct intel_gt *gt)
> > }
> >   }
> > +/*
> > + * Although the rest of the driver should use MCR-specific functions to
> > + * read/write MCR registers, we still use the regular intel_uncore_* 
> > functions
> > + * internally to implement those, so we need a way for the functions in 
> > this
> > + * file to "cast" an i915_mcr_reg_t into an i915_reg_t.
> > + */
> > +static i915_reg_t mcr_reg_cast(const i915_mcr_reg_t mcr)
> > +{
> > +   i915_reg_t r = { .reg = mcr.mmio };
> > +
> > +   return r;
> > +}
> > +
> >   /*
> >* rw_with_mcr_steering_fw - Access a register with specific MCR steering
> >* @uncore: pointer to struct intel_uncore
> > @@ -117,7 +130,7 @@ void intel_gt_mcr_init(struct intel_gt *gt)
> >* Caller needs to make sure the relevant forcewake wells are up.
> >*/
> >   static u32 rw_with_mcr_steering_fw(struct intel_uncore *uncore,
> > -  i915_reg_t reg, u8 rw_flag,
> > +  i915_mcr_reg_t reg, u8 rw_flag,
> >int group, int instance, u32 value)
> >   {
> > u32 mcr_mask, mcr_ss, mcr, old_mcr, val = 0;
> > @@ -154,9 +167,9 @@ static u32 rw_with_mcr_steering_fw(struct intel_uncore 
> > *uncore,
> > intel_uncore_write_fw(uncore, GEN8_MCR_SELECTOR, mcr);
> > if (rw_flag == FW_REG_READ)
> > -   val = intel_uncore_read_fw(uncore, reg);
> > +   val = intel_uncore_read_fw(uncore, mcr_reg_cast(reg));
> > else
> > -   intel_uncore_write_fw(uncore, reg, value);
> > +   intel_uncore_write_fw(uncore, mcr_reg_cast(reg), value);
> > mcr &= ~mcr_mask;
> > mcr |= old_mcr & mcr_mask;
> > @@ -167,14 +180,14 @@ static u32 rw_with_mcr_steering_fw(struct 
> > intel_uncore *uncore,
> >   }
> >   static u32 rw_with_mcr_steering(struct intel_uncore *uncore,
> > -   i915_reg_t reg, u8 rw_flag,
> > +   i915_mcr_reg_t reg, u8 rw_flag,
> > int group, int instance,
> > u32 value)
> >   {
> > enum forcewake_domains fw_domains;
> > u32 val;
> > -   fw_domains = intel_uncore_forcewake_for_reg(uncore, reg,
> > +   fw_domains = intel_uncore_forcewake_for_reg(uncore, mcr_reg_cast(reg),
> > rw_flag);
> > fw_domains |= intel_uncore_forcewake_for_reg(uncore,
> >  GEN8_MCR_SELECTOR,
> > @@ -203,7 +216,7 @@ static u32 rw_with_mcr_steering(struct intel_uncore 
> > *uncore,
> >* group/instance.
> >*/
> >   u32 intel_gt_mcr_read(struct intel_gt *gt,
> > - i915_reg_t reg,
> > + i915_mcr_reg_t reg,
> >   int group, int instance)
> >   {
> > return rw_with_mcr_steering(gt->uncore, reg, FW_REG_READ,
> > @@ -222,7 +235,7 @@ u32 intel_gt_mcr_read(struct intel_gt *gt,
> >* 

Re: [PATCH v6 1/8] drm/msm/dp: Add eDP support via aux_bus

[Doug Anderson]

Hi,

On Sat, Apr 2, 2022 at 1:26 PM Dmitry Baryshkov
 wrote:
>
> On Sat, 2 Apr 2022 at 20:06, Doug Anderson  wrote:
> >
> > Hi,
> >
> > On Sat, Apr 2, 2022 at 3:37 AM Dmitry Baryshkov
> >  wrote:
> > >
> > > On 01/04/2022 02:22, Doug Anderson wrote:
> > > > Hi,
> > > >
> > > > On Wed, Mar 30, 2022 at 9:03 AM Sankeerth Billakanti
> > > >  wrote:
> > > >>
> > > >> @@ -1547,6 +1593,10 @@ int msm_dp_modeset_init(struct msm_dp 
> > > >> *dp_display, struct drm_device *dev,
> > > >>
> > > >>  dp_display->encoder = encoder;
> > > >>
> > > >> +   ret = dp_display_get_next_bridge(dp_display);
> > > >> +   if (ret)
> > > >> +   return ret;
> > > >
> > > > It feels weird to me that this is in a function called "modeset_init",
> > > > though I certainly don't know the structure of the MSM display code
> > > > well enough to fully comment.
> > >
> > > It's called modeset_init() as it initializes KMS objects used by DP
> > > driver. We have similar functions for dsi and hdmi
> >
> > Sorry, I wasn't meaning to imply that modeset_init() was a bad name or
> > anything. Mostly saying that I wasn't sure that modeset init was the
> > proper time to populate the aux bus. ...but then again, perhaps it is
> > given the current structure of this driver?
> >
> >
> > > > My expectation would have been that
> > > > devm_of_dp_aux_populate_ep_devices() would have been called from your
> > > > probe routine and then you would have returned -EPROBE_DEFER from your
> > > > probe if you were unable to find the panel afterwards.
> > >
> > > I don't think it's possible to call it from probe() since
> > > drm_dp_aux_register() is called only from dp_display_bind().
> > > The PHY also isn't initialized at that moment, so we can not probe AUX
> > > devices.
> > >
> > > The overall semantics of the AUX bus is not clear to me.
> > > Typically the bus is populated (and probed) when devices are accessible.
> > > But for the display related buses this might not be the case.
> >
> > In general the AUX bus is modeled much like the i2c bus. You probe the
> > sub-device when you're able to transfer. Then you can confirm that the
> > device is actually there and init the device.
> >
> >
> > > For example for the DSI bus we clearly define that DSI transfer are not
> > > possible before the corresponding bridge's (or panel's) enable call.
> > >
> > > Maybe the same approach should be adopted for the AUX bus. This would
> > > allow us to populate the AUX bus before hardware access is actually
> > > possible, thus creating all the DRM bridges before the hardware is
> > > actually up and running.
> >
> > So I guess what you're proposing is that you could probe the devices
> > under the AUX bus and they could acquire resources (and possibly
> > return EPROBE_DEFER) at a point in time _before_ it's actually
> > possible to transfer. Then I guess you'd later do the transfer?
>
> Exactly.
>
> >
> > I guess conceivably one could re-design the DRM subsystem like that,
> > but I don't think it's trivial.
>
> The problem is that the DRM subsystem is already designed like that.
> All the bridge chains are static. They are created during the device
> probe. And the modes are populated later (via the get_modes()
> callback), after the HPD signal is delivered.
> For the encoder/bridge chains it is explicitly stated that the display
> pipe (clocks and timing signals) are not running before bridge's
> enable() callback or after the disable() callback being called.
>
> > Why? I believe that we need to know
> > things about the panel at probe time. For instance, we need to be able
> > to populate the panel's modes.
>
> As I said, panel modes are not needed at the probe time. The fact that
> most (if not all) of the panel drivers provide them in the platform
> data (and thus modes are typically populated at the probe time) comes
> from the fact that the panel is usually a known static piece of
> hardware. With the generic edp-panel this is no longer the case. A
> single device handles a (probed) variety of panels.

OK, so I misspoke when I said that the modes are populated during
probe time for edp-panel. They're not and I guess I managed to confuse
myself when I wrote my previous email. Instead they (and everything
else that comes from the EDID) isn't needed until the panel's
get_modes() is called, as you said. So, ignoring the backlight problem
talked about below, we could conceivably delay the reading of the EDID
until get_modes.

...but I think something still isn't quite right with your description
of how it works. Specifically:

1. I'm 99% certain that get_modes() is called _before_ enable, even
for the DP case. I have no idea how that works for you for DP if the
clocks / timing signals don't work until enable happens. Aside from my
previous observations of this, it also logically makes sense that
get_modes() needs to be called before enable(), doesn't it? When
enable() is called then don't you already know what mode userspace has
picked 

[PATCH v5 9/9] drm: vkms: Add support to the RGB565 format

[Igor Torrente]

Adds this common format to vkms.

This commit also adds new helper macros to deal with fixed-point
arithmetic.

It was done to improve the precision of the conversion to ARGB16161616
since the "conversion ratio" is not an integer.

V3: Adapt the handlers to the new format introduced in patch 7 V3.
V5: Minor improvements

Signed-off-by: Igor Torrente 
---
 drivers/gpu/drm/vkms/vkms_formats.c   | 70 +++
 drivers/gpu/drm/vkms/vkms_plane.c |  6 ++-
 drivers/gpu/drm/vkms/vkms_writeback.c |  3 +-
 3 files changed, 76 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/vkms/vkms_formats.c 
b/drivers/gpu/drm/vkms/vkms_formats.c
index 8d913fa7dbde..4af8b295f31e 100644
--- a/drivers/gpu/drm/vkms/vkms_formats.c
+++ b/drivers/gpu/drm/vkms/vkms_formats.c
@@ -5,6 +5,23 @@
 
 #include "vkms_formats.h"
 
+/* The following macros help doing fixed point arithmetic. */
+/*
+ * With Fixed-Point scale 15 we have 17 and 15 bits of integer and fractional
+ * parts respectively.
+ *  |     0.000    |
+ * 31  0
+ */
+#define FIXED_SCALE 15
+
+#define INT_TO_FIXED(a) ((a) << FIXED_SCALE)
+#define FIXED_MUL(a, b) ((s32)(((s64)(a) * (b)) >> FIXED_SCALE))
+#define FIXED_DIV(a, b) ((s32)(((s64)(a) << FIXED_SCALE) / (b)))
+/* This macro converts a fixed point number to int, and round half up it */
+#define FIXED_TO_INT_ROUND(a) (((a) + (1 << (FIXED_SCALE - 1))) >> FIXED_SCALE)
+/* Convert divisor and dividend to Fixed-Point and performs the division */
+#define INT_TO_FIXED_DIV(a, b) (FIXED_DIV(INT_TO_FIXED(a), INT_TO_FIXED(b)))
+
 static int pixel_offset(const struct vkms_frame_info *frame_info, int x, int y)
 {
return frame_info->offset + (y * frame_info->pitch)
@@ -112,6 +129,30 @@ static void XRGB16161616_to_argb_u16(struct line_buffer 
*stage_buffer,
}
 }
 
+static void RGB565_to_argb_u16(struct line_buffer *stage_buffer,
+  const struct vkms_frame_info *frame_info, int y)
+{
+   struct pixel_argb_u16 *out_pixels = stage_buffer->pixels;
+   u16 *src_pixels = get_packed_src_addr(frame_info, y);
+   int x, x_limit = min_t(size_t, drm_rect_width(_info->dst),
+  stage_buffer->n_pixels);
+
+   for (x = 0; x < x_limit; x++, src_pixels++) {
+   u16 rgb_565 = le16_to_cpu(*src_pixels);
+   int fp_r = INT_TO_FIXED((rgb_565 >> 11) & 0x1f);
+   int fp_g = INT_TO_FIXED((rgb_565 >> 5) & 0x3f);
+   int fp_b = INT_TO_FIXED(rgb_565 & 0x1f);
+
+   int fp_rb_ratio = INT_TO_FIXED_DIV(65535, 31);
+   int fp_g_ratio = INT_TO_FIXED_DIV(65535, 63);
+
+   out_pixels[x].a = (u16)0x;
+   out_pixels[x].r = FIXED_TO_INT_ROUND(FIXED_MUL(fp_r, 
fp_rb_ratio));
+   out_pixels[x].g = FIXED_TO_INT_ROUND(FIXED_MUL(fp_g, 
fp_g_ratio));
+   out_pixels[x].b = FIXED_TO_INT_ROUND(FIXED_MUL(fp_b, 
fp_rb_ratio));
+   }
+}
+
 
 /*
  * The following  functions take an line of argb_u16 pixels from the
@@ -199,6 +240,31 @@ static void argb_u16_to_XRGB16161616(struct 
vkms_frame_info *frame_info,
}
 }
 
+static void argb_u16_to_RGB565(struct vkms_frame_info *frame_info,
+  const struct line_buffer *src_buffer, int y)
+{
+   int x, x_dst = frame_info->dst.x1;
+   u16 *dst_pixels = packed_pixels_addr(frame_info, x_dst, y);
+   struct pixel_argb_u16 *in_pixels = src_buffer->pixels;
+   int x_limit = min_t(size_t, drm_rect_width(_info->dst),
+   src_buffer->n_pixels);
+
+   for (x = 0; x < x_limit; x++, dst_pixels++) {
+   int fp_r = INT_TO_FIXED(in_pixels[x].r);
+   int fp_g = INT_TO_FIXED(in_pixels[x].g);
+   int fp_b = INT_TO_FIXED(in_pixels[x].b);
+
+   int fp_rb_ratio = INT_TO_FIXED_DIV(65535, 31);
+   int fp_g_ratio = INT_TO_FIXED_DIV(65535, 63);
+
+   u16 r = FIXED_TO_INT_ROUND(FIXED_DIV(fp_r, fp_rb_ratio));
+   u16 g = FIXED_TO_INT_ROUND(FIXED_DIV(fp_g, fp_g_ratio));
+   u16 b = FIXED_TO_INT_ROUND(FIXED_DIV(fp_b, fp_rb_ratio));
+
+   *dst_pixels = cpu_to_le16(r << 11 | g << 5 | b);
+   }
+}
+
 plane_format_transform_func get_plane_fmt_transform_function(u32 format)
 {
if (format == DRM_FORMAT_ARGB)
@@ -209,6 +275,8 @@ plane_format_transform_func 
get_plane_fmt_transform_function(u32 format)
return _to_argb_u16;
else if (format == DRM_FORMAT_XRGB16161616)
return _to_argb_u16;
+   else if (format == DRM_FORMAT_RGB565)
+   return _to_argb_u16;
else
return NULL;
 }
@@ -223,6 +291,8 @@ wb_format_transform_func get_wb_fmt_transform_function(u32 
format)
return _u16_to_ARGB16161616;
else if (format == DRM_FORMAT_XRGB16161616)
return 

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

[Igor Torrente]

This will be useful to write tests that depends on these formats.

ARGB and XRGB follows the a similar implementation of the former formats.
Just adjusting for 16 bits per channel.

V3: Adapt the handlers to the new format introduced in patch 7 V3.
V5: Minor improvements
Added le16_to_cpu/cpu_to_le16 to the 16 bits color read/writes.

Signed-off-by: Igor Torrente 
---
 drivers/gpu/drm/vkms/vkms_formats.c   | 77 +++
 drivers/gpu/drm/vkms/vkms_plane.c |  5 +-
 drivers/gpu/drm/vkms/vkms_writeback.c |  2 +
 3 files changed, 83 insertions(+), 1 deletion(-)

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

[PATCH v5 7/9] drm: vkms: Supports to the case where primary plane doesn't match the CRTC

[Igor Torrente]

We will break the current assumption that the primary plane has the
same size and position as CRTC.

For that we will add CRTC dimension information to `vkms_crtc_state`
and add a opaque black backgound color.

Because now we need to fill the background, we had a loss in
performance with this change. Results running the IGT[1] test
`igt@kms_cursor_crc@pipe-a-cursor-512x512-onscreen` ten times:

|  Frametime   |
|::|
|  Implementation |  Previous |   This commit  |
|:---:|:-:|:--:|
| frametime range |  5~18 ms  | 10~22 ms   |
| Average |  8.47 ms  | 12.32 ms   |

[1] IGT commit id: bc3f6833a12221a46659535dac06ebb312490eb4

Signed-off-by: Igor Torrente 
---
 Documentation/gpu/vkms.rst   |  3 +--
 drivers/gpu/drm/vkms/vkms_composer.c | 32 +++-
 drivers/gpu/drm/vkms/vkms_crtc.c |  4 
 drivers/gpu/drm/vkms/vkms_drv.h  |  2 ++
 4 files changed, 29 insertions(+), 12 deletions(-)

diff --git a/Documentation/gpu/vkms.rst b/Documentation/gpu/vkms.rst
index a49e4ae92653..49db221c0f52 100644
--- a/Documentation/gpu/vkms.rst
+++ b/Documentation/gpu/vkms.rst
@@ -121,8 +121,7 @@ There's lots of plane features we could add support for:
 - ARGB format on primary plane: blend the primary plane into background with
   translucent alpha.
 
-- Support when the primary plane isn't exactly matching the output size: blend
-  the primary plane into the black background.
+- Add background color KMS property[Good to get started].
 
 - Full alpha blending on all planes.
 
diff --git a/drivers/gpu/drm/vkms/vkms_composer.c 
b/drivers/gpu/drm/vkms/vkms_composer.c
index cf24015bf90f..f80842227669 100644
--- a/drivers/gpu/drm/vkms/vkms_composer.c
+++ b/drivers/gpu/drm/vkms/vkms_composer.c
@@ -61,6 +61,15 @@ static bool check_y_limit(struct vkms_frame_info 
*frame_info, int y)
return false;
 }
 
+static void fill_background(struct pixel_argb_u16 *backgroud_color,
+   struct line_buffer *output_buffer)
+{
+   int i;
+
+   for (i = 0; i < output_buffer->n_pixels; i++)
+   output_buffer->pixels[i] = *backgroud_color;
+}
+
 /**
  * @wb_frame_info: The writeback frame buffer metadata
  * @crtc_state: The crtc state
@@ -78,22 +87,23 @@ static void blend(struct vkms_writeback_job *wb,
  struct line_buffer *output_buffer, s64 row_size)
 {
struct vkms_plane_state **plane = crtc_state->active_planes;
-   struct vkms_frame_info *primary_plane_info = plane[0]->frame_info;
u32 n_active_planes = crtc_state->num_active_planes;
 
-   int y_dst = primary_plane_info->dst.y1;
-   int h_dst = drm_rect_height(_plane_info->dst);
-   int y_limit = y_dst + h_dst;
+   struct pixel_argb_u16 background_color = (struct pixel_argb_u16) {
+   .a = 0x
+   };
+
+   int crtc_y_limit = crtc_state->crtc_height;
int y, i;
 
-   for (y = y_dst; y < y_limit; y++) {
-   plane[0]->format_func(output_buffer, primary_plane_info, y);
+   for (y = 0; y < crtc_y_limit; y++) {
+   fill_background(_color, output_buffer);
 
/* If there are other planes besides primary, we consider the 
active
 * planes should be in z-order and compose them associatively:
 * ((primary <- overlay) <- cursor)
 */
-   for (i = 1; i < n_active_planes; i++) {
+   for (i = 0; i < n_active_planes; i++) {
if (!check_y_limit(plane[i]->frame_info, y))
continue;
 
@@ -154,7 +164,7 @@ static int compose_active_planes(struct vkms_writeback_job 
*active_wb,
if (WARN_ON(check_format_funcs(crtc_state, active_wb)))
return -EINVAL;
 
-   line_width = drm_rect_width(_plane_info->dst);
+   line_width = crtc_state->crtc_width;
stage_buffer.n_pixels = line_width;
output_buffer.n_pixels = line_width;
 
@@ -175,8 +185,10 @@ static int compose_active_planes(struct vkms_writeback_job 
*active_wb,
struct vkms_frame_info *wb_frame_info = _wb->frame_info;
 
wb_format = wb_frame_info->fb->format->format;
-   wb_frame_info->src = primary_plane_info->src;
-   wb_frame_info->dst = primary_plane_info->dst;
+   drm_rect_init(_frame_info->src, 0, 0, crtc_state->crtc_width,
+ crtc_state->crtc_height);
+   drm_rect_init(_frame_info->dst, 0, 0, crtc_state->crtc_width,
+ crtc_state->crtc_height);
}
 
blend(active_wb, crtc_state, crc32, _buffer,
diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c b/drivers/gpu/drm/vkms/vkms_crtc.c
index 57bbd32e9beb..4a37e243c2d7 100644
--- a/drivers/gpu/drm/vkms/vkms_crtc.c
+++ b/drivers/gpu/drm/vkms/vkms_crtc.c
@@ -248,7 +248,9 @@ static void 

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

[Igor Torrente]

Currently the blend function only accepts XRGB_ and ARGB_
as a color input.

This patch refactors all the functions related to the plane composition
to overcome this limitation.

A new internal format(`struct pixel`) is introduced to deal with all
possible inputs. It consists of 16 bits fields that represent each of
the channels.

The pixels blend is done using this internal format. And new handlers
are being added to convert a specific format to/from this internal format.

So the blend operation depends on these handlers to convert to this common
format. The blended result, if necessary, is converted to the writeback
buffer format.

This patch introduces three major differences to the blend function.
1 - All the planes are blended at once.
2 - The blend calculus is done as per line instead of per pixel.
3 - It is responsible to calculates the CRC and writing the writeback
buffer(if necessary).

These changes allow us to allocate way less memory in the intermediate
buffer to compute these operations. Because now we don't need to
have the entire intermediate image lines at once, just one line is
enough.

| Memory consumption (output dimensions) |
|:--:|
|   Current  | This patch|
|:--:|:-:|
|   Width * Heigth   | 2 * Width |

Beyond memory, we also have a minor performance benefit from all
these changes. Results running the IGT[1] test
`igt@kms_cursor_crc@pipe-a-cursor-512x512-onscreen` ten times:

| Frametime  |
|:--:|
|  Implementation |  Current  |  This commit |
|:---:|:-:|::|
| frametime range |  9~22 ms  |5~17 ms   |
| Average |  11.4 ms  |7.8 ms|

[1] IGT commit id: bc3f6833a12221a46659535dac06ebb312490eb4

V2: Improves the performance drastically, by performing the operations
per-line and not per-pixel(Pekka Paalanen).
Minor improvements(Pekka Paalanen).
V3: Changes the code to blend the planes all at once. This improves
performance, memory consumption, and removes much of the weirdness
of the V2(Pekka Paalanen and me).
Minor improvements(Pekka Paalanen and me).
V4: Rebase the code and adapt it to the new NUM_OVERLAY_PLANES constant.
V5: Minor checkpatch fixes and the removal of TO-DO item(Melissa Wen).
Several security/robustness improvents(Pekka Paalanen).
Removes check_planes_x_bounds function and allows partial
partly off-screen(Pekka Paalanen).

Signed-off-by: Igor Torrente 
---
 Documentation/gpu/vkms.rst|   4 -
 drivers/gpu/drm/vkms/Makefile |   1 +
 drivers/gpu/drm/vkms/vkms_composer.c  | 318 --
 drivers/gpu/drm/vkms/vkms_formats.c   | 151 
 drivers/gpu/drm/vkms/vkms_formats.h   |  12 +
 drivers/gpu/drm/vkms/vkms_plane.c |   3 +
 drivers/gpu/drm/vkms/vkms_writeback.c |   3 +
 7 files changed, 311 insertions(+), 181 deletions(-)
 create mode 100644 drivers/gpu/drm/vkms/vkms_formats.c
 create mode 100644 drivers/gpu/drm/vkms/vkms_formats.h

diff --git a/Documentation/gpu/vkms.rst b/Documentation/gpu/vkms.rst
index 973e2d43108b..a49e4ae92653 100644
--- a/Documentation/gpu/vkms.rst
+++ b/Documentation/gpu/vkms.rst
@@ -118,10 +118,6 @@ Add Plane Features
 
 There's lots of plane features we could add support for:
 
-- Clearing primary plane: clear primary plane before plane composition (at the
-  start) for correctness of pixel blend ops. It also guarantees alpha channel
-  is cleared in the target buffer for stable crc. [Good to get started]
-
 - ARGB format on primary plane: blend the primary plane into background with
   translucent alpha.
 
diff --git a/drivers/gpu/drm/vkms/Makefile b/drivers/gpu/drm/vkms/Makefile
index 72f779cbfedd..1b28a6a32948 100644
--- a/drivers/gpu/drm/vkms/Makefile
+++ b/drivers/gpu/drm/vkms/Makefile
@@ -3,6 +3,7 @@ vkms-y := \
vkms_drv.o \
vkms_plane.o \
vkms_output.o \
+   vkms_formats.o \
vkms_crtc.o \
vkms_composer.o \
vkms_writeback.o
diff --git a/drivers/gpu/drm/vkms/vkms_composer.c 
b/drivers/gpu/drm/vkms/vkms_composer.c
index 95029d2ebcac..cf24015bf90f 100644
--- a/drivers/gpu/drm/vkms/vkms_composer.c
+++ b/drivers/gpu/drm/vkms/vkms_composer.c
@@ -7,204 +7,186 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "vkms_drv.h"
 
-static u32 get_pixel_from_buffer(int x, int y, const u8 *buffer,
-const struct vkms_frame_info *frame_info)
+static u16 pre_mul_blend_channel(u16 src, u16 dst, u16 alpha)
 {
-   u32 pixel;
-   int src_offset = frame_info->offset + (y * frame_info->pitch)
-   + (x * frame_info->cpp);
+   u32 new_color;
 
-   pixel = *(u32 *)[src_offset];
+   new_color = (src * 0x + dst * (0x - alpha));
 
-   return pixel;
+   return DIV_ROUND_CLOSEST(new_color, 0x);
 }
 
 /**
- 

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

[Igor Torrente]

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

Also adds two new function pointers (`{wb,plane}_format_transform_func`)
are defined to handle format conversion to/from internal format.

These things will allow us, in the future, to have different compositing
and wb format types.

V2: Change the code to get the drm_framebuffer reference and not copy its
contents(Thomas Zimmermann).
V3: Drop the refcount in the wb code(Thomas Zimmermann).
V5: Add {wb,plane}_format_transform_func to vkms_writeback_job
and vkms_plane_state (Pekka Paalanen)

Signed-off-by: Igor Torrente 
---
 drivers/gpu/drm/vkms/vkms_composer.c  |  4 ++--
 drivers/gpu/drm/vkms/vkms_drv.h   | 31 +--
 drivers/gpu/drm/vkms/vkms_plane.c | 10 -
 drivers/gpu/drm/vkms/vkms_writeback.c | 20 ++---
 4 files changed, 49 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/vkms/vkms_composer.c 
b/drivers/gpu/drm/vkms/vkms_composer.c
index 2d946368a561..95029d2ebcac 100644
--- a/drivers/gpu/drm/vkms/vkms_composer.c
+++ b/drivers/gpu/drm/vkms/vkms_composer.c
@@ -153,7 +153,7 @@ static void compose_plane(struct vkms_frame_info 
*primary_plane_info,
  struct vkms_frame_info *plane_frame_info,
  void *vaddr_out)
 {
-   struct drm_framebuffer *fb = _frame_info->fb;
+   struct drm_framebuffer *fb = plane_frame_info->fb;
void *vaddr;
void (*pixel_blend)(const u8 *p_src, u8 *p_dst);
 
@@ -175,7 +175,7 @@ static int compose_active_planes(void **vaddr_out,
 struct vkms_frame_info *primary_plane_info,
 struct vkms_crtc_state *crtc_state)
 {
-   struct drm_framebuffer *fb = _plane_info->fb;
+   struct drm_framebuffer *fb = primary_plane_info->fb;
struct drm_gem_object *gem_obj = drm_gem_fb_get_obj(fb, 0);
const void *vaddr;
int i;
diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h
index 2e6342164bef..2704cfb6904b 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.h
+++ b/drivers/gpu/drm/vkms/vkms_drv.h
@@ -22,13 +22,8 @@
 
 #define NUM_OVERLAY_PLANES 8
 
-struct vkms_writeback_job {
-   struct dma_buf_map map[DRM_FORMAT_MAX_PLANES];
-   struct dma_buf_map data[DRM_FORMAT_MAX_PLANES];
-};
-
 struct vkms_frame_info {
-   struct drm_framebuffer fb;
+   struct drm_framebuffer *fb;
struct drm_rect src, dst;
struct dma_buf_map map[DRM_FORMAT_MAX_PLANES];
unsigned int offset;
@@ -36,6 +31,29 @@ struct vkms_frame_info {
unsigned int cpp;
 };
 
+struct pixel_argb_u16 {
+   u16 a, r, g, b;
+};
+
+struct line_buffer {
+   size_t n_pixels;
+   struct pixel_argb_u16 *pixels;
+};
+
+typedef void
+(*wb_format_transform_func)(struct vkms_frame_info *frame_info,
+   const struct line_buffer *buffer, int y);
+
+typedef void
+(*plane_format_transform_func)(struct line_buffer *buffer,
+  const struct vkms_frame_info *frame_info, int y);
+
+struct vkms_writeback_job {
+   struct dma_buf_map data[DRM_FORMAT_MAX_PLANES];
+   struct vkms_frame_info frame_info;
+   wb_format_transform_func format_func;
+};
+
 /**
  * vkms_plane_state - Driver specific plane state
  * @base: base plane state
@@ -44,6 +62,7 @@ struct vkms_frame_info {
 struct vkms_plane_state {
struct drm_shadow_plane_state base;
struct vkms_frame_info *frame_info;
+   plane_format_transform_func format_func;
 };
 
 struct vkms_plane {
diff --git a/drivers/gpu/drm/vkms/vkms_plane.c 
b/drivers/gpu/drm/vkms/vkms_plane.c
index a56b0f76eddd..28752af0118c 100644
--- a/drivers/gpu/drm/vkms/vkms_plane.c
+++ b/drivers/gpu/drm/vkms/vkms_plane.c
@@ -50,12 +50,12 @@ static void vkms_plane_destroy_state(struct drm_plane 
*plane,
struct vkms_plane_state *vkms_state = to_vkms_plane_state(old_state);
struct drm_crtc *crtc = vkms_state->base.base.crtc;
 
-   if (crtc) {
+   if (crtc && vkms_state->frame_info->fb) {
/* dropping the reference we acquired in
 * vkms_primary_plane_update()
 */
-   if (drm_framebuffer_read_refcount(_state->frame_info->fb))
-   drm_framebuffer_put(_state->frame_info->fb);
+   if (drm_framebuffer_read_refcount(vkms_state->frame_info->fb))
+   drm_framebuffer_put(vkms_state->frame_info->fb);
}
 
kfree(vkms_state->frame_info);
@@ -110,9 +110,9 @@ static void vkms_plane_atomic_update(struct drm_plane 
*plane,
frame_info = vkms_plane_state->frame_info;
memcpy(_info->src, _state->src, sizeof(struct drm_rect));
memcpy(_info->dst, _state->dst, sizeof(struct drm_rect));
-   

[PATCH v5 4/9] drm: drm_atomic_helper: Add a new helper to deal with the writeback connector validation

[Igor Torrente]

Add a helper function to validate the connector configuration receive in
the encoder atomic_check by the drivers.

So the drivers don't need do these common validations themselves.

V2: Move the format verification to a new helper at the drm_atomic_helper.c
(Thomas Zimmermann).
V3: Format check improvements (Leandro Ribeiro).
Minor improvements(Thomas Zimmermann).

Signed-off-by: Igor Torrente 
---
 drivers/gpu/drm/drm_atomic_helper.c   | 39 +++
 drivers/gpu/drm/vkms/vkms_writeback.c |  9 +++
 include/drm/drm_atomic_helper.h   |  3 +++
 3 files changed, 46 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 9603193d2fa1..2052e18fa64c 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -776,6 +776,45 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
 }
 EXPORT_SYMBOL(drm_atomic_helper_check_modeset);
 
+/**
+ * drm_atomic_helper_check_wb_connector_state() - Check writeback encoder state
+ * @encoder: encoder state to check
+ * @conn_state: connector state to check
+ *
+ * Checks if the writeback connector state is valid, and returns an error if it
+ * isn't.
+ *
+ * RETURNS:
+ * Zero for success or -errno
+ */
+int
+drm_atomic_helper_check_wb_encoder_state(struct drm_encoder *encoder,
+struct drm_connector_state *conn_state)
+{
+   struct drm_writeback_job *wb_job = conn_state->writeback_job;
+   struct drm_property_blob *pixel_format_blob;
+   struct drm_framebuffer *fb;
+   size_t i, nformats;
+   u32 *formats;
+
+   if (!wb_job || !wb_job->fb)
+   return 0;
+
+   pixel_format_blob = wb_job->connector->pixel_formats_blob_ptr;
+   nformats = pixel_format_blob->length / sizeof(u32);
+   formats = pixel_format_blob->data;
+   fb = wb_job->fb;
+
+   for (i = 0; i < nformats; i++)
+   if (fb->format->format == formats[i])
+   return 0;
+
+   drm_dbg_kms(encoder->dev, "Invalid pixel format %p4cc\n", 
>format->format);
+
+   return -EINVAL;
+}
+EXPORT_SYMBOL(drm_atomic_helper_check_wb_encoder_state);
+
 /**
  * drm_atomic_helper_check_plane_state() - Check plane state for validity
  * @plane_state: plane state to check
diff --git a/drivers/gpu/drm/vkms/vkms_writeback.c 
b/drivers/gpu/drm/vkms/vkms_writeback.c
index 8694227f555f..746cb0abc6ec 100644
--- a/drivers/gpu/drm/vkms/vkms_writeback.c
+++ b/drivers/gpu/drm/vkms/vkms_writeback.c
@@ -30,6 +30,7 @@ static int vkms_wb_encoder_atomic_check(struct drm_encoder 
*encoder,
 {
struct drm_framebuffer *fb;
const struct drm_display_mode *mode = _state->mode;
+   int ret;
 
if (!conn_state->writeback_job || !conn_state->writeback_job->fb)
return 0;
@@ -41,11 +42,9 @@ static int vkms_wb_encoder_atomic_check(struct drm_encoder 
*encoder,
return -EINVAL;
}
 
-   if (fb->format->format != vkms_wb_formats[0]) {
-   DRM_DEBUG_KMS("Invalid pixel format %p4cc\n",
- >format->format);
-   return -EINVAL;
-   }
+   ret = drm_atomic_helper_check_wb_encoder_state(encoder, conn_state);
+   if (ret < 0)
+   return ret;
 
return 0;
 }
diff --git a/include/drm/drm_atomic_helper.h b/include/drm/drm_atomic_helper.h
index 4045e2507e11..3fbf695da60f 100644
--- a/include/drm/drm_atomic_helper.h
+++ b/include/drm/drm_atomic_helper.h
@@ -40,6 +40,9 @@ struct drm_private_state;
 
 int drm_atomic_helper_check_modeset(struct drm_device *dev,
struct drm_atomic_state *state);
+int
+drm_atomic_helper_check_wb_encoder_state(struct drm_encoder *encoder,
+struct drm_connector_state 
*conn_state);
 int drm_atomic_helper_check_plane_state(struct drm_plane_state *plane_state,
const struct drm_crtc_state *crtc_state,
int min_scale,
-- 
2.30.2

[PATCH v5 3/9] drm: vkms: Rename `vkms_composer` to `vkms_frame_info`

[Igor Torrente]

Changes the name of this struct to a more meaningful name.
A name that represents better what this struct is about.

Composer is the code that do the compositing of the planes.
This struct contains information on the frame used in the output
composition. Thus, vkms_frame_info is a better name to represent
this.

V5: Fix a commit message typo(Melissa Wen).

Reviewed-by: Melissa Wen 
Signed-off-by: Igor Torrente 
---
 drivers/gpu/drm/vkms/vkms_composer.c | 87 ++--
 drivers/gpu/drm/vkms/vkms_drv.h  |  6 +-
 drivers/gpu/drm/vkms/vkms_plane.c| 38 ++--
 3 files changed, 66 insertions(+), 65 deletions(-)

diff --git a/drivers/gpu/drm/vkms/vkms_composer.c 
b/drivers/gpu/drm/vkms/vkms_composer.c
index 82f79e508f81..2d946368a561 100644
--- a/drivers/gpu/drm/vkms/vkms_composer.c
+++ b/drivers/gpu/drm/vkms/vkms_composer.c
@@ -11,11 +11,11 @@
 #include "vkms_drv.h"
 
 static u32 get_pixel_from_buffer(int x, int y, const u8 *buffer,
-const struct vkms_composer *composer)
+const struct vkms_frame_info *frame_info)
 {
u32 pixel;
-   int src_offset = composer->offset + (y * composer->pitch)
- + (x * composer->cpp);
+   int src_offset = frame_info->offset + (y * frame_info->pitch)
+   + (x * frame_info->cpp);
 
pixel = *(u32 *)[src_offset];
 
@@ -26,24 +26,24 @@ static u32 get_pixel_from_buffer(int x, int y, const u8 
*buffer,
  * compute_crc - Compute CRC value on output frame
  *
  * @vaddr: address to final framebuffer
- * @composer: framebuffer's metadata
+ * @frame_info: framebuffer's metadata
  *
  * returns CRC value computed using crc32 on the visible portion of
  * the final framebuffer at vaddr_out
  */
 static uint32_t compute_crc(const u8 *vaddr,
-   const struct vkms_composer *composer)
+   const struct vkms_frame_info *frame_info)
 {
int x, y;
u32 crc = 0, pixel = 0;
-   int x_src = composer->src.x1 >> 16;
-   int y_src = composer->src.y1 >> 16;
-   int h_src = drm_rect_height(>src) >> 16;
-   int w_src = drm_rect_width(>src) >> 16;
+   int x_src = frame_info->src.x1 >> 16;
+   int y_src = frame_info->src.y1 >> 16;
+   int h_src = drm_rect_height(_info->src) >> 16;
+   int w_src = drm_rect_width(_info->src) >> 16;
 
for (y = y_src; y < y_src + h_src; ++y) {
for (x = x_src; x < x_src + w_src; ++x) {
-   pixel = get_pixel_from_buffer(x, y, vaddr, composer);
+   pixel = get_pixel_from_buffer(x, y, vaddr, frame_info);
crc = crc32_le(crc, (void *), sizeof(u32));
}
}
@@ -98,8 +98,8 @@ static void x_blend(const u8 *xrgb_src, u8 *xrgb_dst)
  * blend - blend value at vaddr_src with value at vaddr_dst
  * @vaddr_dst: destination address
  * @vaddr_src: source address
- * @dst_composer: destination framebuffer's metadata
- * @src_composer: source framebuffer's metadata
+ * @dst_frame_info: destination framebuffer's metadata
+ * @src_frame_info: source framebuffer's metadata
  * @pixel_blend: blending equation based on plane format
  *
  * Blend the vaddr_src value with the vaddr_dst value using a pixel blend
@@ -111,33 +111,33 @@ static void x_blend(const u8 *xrgb_src, u8 *xrgb_dst)
  * pixel color values
  */
 static void blend(void *vaddr_dst, void *vaddr_src,
- struct vkms_composer *dst_composer,
- struct vkms_composer *src_composer,
+ struct vkms_frame_info *dst_frame_info,
+ struct vkms_frame_info *src_frame_info,
  void (*pixel_blend)(const u8 *, u8 *))
 {
int i, j, j_dst, i_dst;
int offset_src, offset_dst;
u8 *pixel_dst, *pixel_src;
 
-   int x_src = src_composer->src.x1 >> 16;
-   int y_src = src_composer->src.y1 >> 16;
+   int x_src = src_frame_info->src.x1 >> 16;
+   int y_src = src_frame_info->src.y1 >> 16;
 
-   int x_dst = src_composer->dst.x1;
-   int y_dst = src_composer->dst.y1;
-   int h_dst = drm_rect_height(_composer->dst);
-   int w_dst = drm_rect_width(_composer->dst);
+   int x_dst = src_frame_info->dst.x1;
+   int y_dst = src_frame_info->dst.y1;
+   int h_dst = drm_rect_height(_frame_info->dst);
+   int w_dst = drm_rect_width(_frame_info->dst);
 
int y_limit = y_src + h_dst;
int x_limit = x_src + w_dst;
 
for (i = y_src, i_dst = y_dst; i < y_limit; ++i) {
for (j = x_src, j_dst = x_dst; j < x_limit; ++j) {
-   offset_dst = dst_composer->offset
-+ (i_dst * dst_composer->pitch)
-+ (j_dst++ * dst_composer->cpp);
-   offset_src = src_composer->offset
-+ (i * 

[PATCH v5 2/9] drm: vkms: Replace hardcoded value of `vkms_composer.map` to DRM_FORMAT_MAX_PLANES

[Igor Torrente]

The `map` vector at `vkms_composer` uses a hardcoded value to define its
size.

If someday the maximum number of planes increases, this hardcoded value
can be a problem.

This value is being replaced with the DRM_FORMAT_MAX_PLANES macro.

Acked-by: Thomas Zimmermann 
Reviewed-by: Melissa Wen 
Signed-off-by: Igor Torrente 
---
 drivers/gpu/drm/vkms/vkms_drv.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h
index 9496fdc900b8..0eeea6f93733 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.h
+++ b/drivers/gpu/drm/vkms/vkms_drv.h
@@ -30,7 +30,7 @@ struct vkms_writeback_job {
 struct vkms_composer {
struct drm_framebuffer fb;
struct drm_rect src, dst;
-   struct dma_buf_map map[4];
+   struct dma_buf_map map[DRM_FORMAT_MAX_PLANES];
unsigned int offset;
unsigned int pitch;
unsigned int cpp;
-- 
2.30.2

[PATCH v5 1/9] drm: vkms: Alloc the compose frame using vzalloc

[Igor Torrente]

Currently, the memory to the composition frame is being allocated using
the kzmalloc. This comes with the limitation of maximum size of one
page size(which in the x86_64 is 4Kb and 4MB for default and hugepage
respectively).

Somes test of igt (e.g. kms_plane@pixel-format) uses more than 4MB when
testing some pixel formats like ARGB16161616 and the following error were
showing up when running kms_plane@plane-panning-bottom-right*:

[drm:vkms_composer_worker [vkms]] *ERROR* Cannot allocate memory for
output frame.

This problem is addessed by allocating the memory using kvzalloc that
circunvents this limitation.

V5: Improve the commit message and drop the debugging issues in VKMS
TO-DO(Melissa Wen).

Reviewed-by: Melissa Wen 
Signed-off-by: Igor Torrente 
---
 Documentation/gpu/vkms.rst   | 6 --
 drivers/gpu/drm/vkms/vkms_composer.c | 6 +++---
 2 files changed, 3 insertions(+), 9 deletions(-)

diff --git a/Documentation/gpu/vkms.rst b/Documentation/gpu/vkms.rst
index 9c873c3912cc..973e2d43108b 100644
--- a/Documentation/gpu/vkms.rst
+++ b/Documentation/gpu/vkms.rst
@@ -102,12 +102,6 @@ Debugging:
 
 - kms_plane: some test cases are failing due to timeout on capturing CRC;
 
-- kms_flip: when running test cases in sequence, some successful individual
-  test cases are failing randomly; when individually, some successful test
-  cases display in the log the following error::
-
-  [drm:vkms_prepare_fb [vkms]] ERROR vmap failed: -4
-
 Virtual hardware (vblank-less) mode:
 
 - VKMS already has support for vblanks simulated via hrtimers, which can be
diff --git a/drivers/gpu/drm/vkms/vkms_composer.c 
b/drivers/gpu/drm/vkms/vkms_composer.c
index 9e8204be9a14..82f79e508f81 100644
--- a/drivers/gpu/drm/vkms/vkms_composer.c
+++ b/drivers/gpu/drm/vkms/vkms_composer.c
@@ -180,7 +180,7 @@ static int compose_active_planes(void **vaddr_out,
int i;
 
if (!*vaddr_out) {
-   *vaddr_out = kzalloc(gem_obj->size, GFP_KERNEL);
+   *vaddr_out = kvzalloc(gem_obj->size, GFP_KERNEL);
if (!*vaddr_out) {
DRM_ERROR("Cannot allocate memory for output frame.");
return -ENOMEM;
@@ -263,7 +263,7 @@ void vkms_composer_worker(struct work_struct *work)
crtc_state);
if (ret) {
if (ret == -EINVAL && !wb_pending)
-   kfree(vaddr_out);
+   kvfree(vaddr_out);
return;
}
 
@@ -275,7 +275,7 @@ void vkms_composer_worker(struct work_struct *work)
crtc_state->wb_pending = false;
spin_unlock_irq(>composer_lock);
} else {
-   kfree(vaddr_out);
+   kvfree(vaddr_out);
}
 
/*
-- 
2.30.2

[PATCH v5 0/9] Add new formats support to vkms

[Igor Torrente]

Summary
===
This series of patches refactor some vkms components in order to introduce
new formats to the planes and writeback connector.

Now in the blend function, the plane's pixels are converted to ARGB16161616
and then blended together.

The CRC is calculated based on the ARGB1616161616 buffer. And if required,
this buffer is copied/converted to the writeback buffer format.

And to handle the pixel conversion, new functions were added to convert
from a specific format to ARGB16161616 (the reciprocal is also true).

Tests
=
This patch series was tested using the following igt tests:
-t ".*kms_plane.*"
-t ".*kms_writeback.*"
-t ".*kms_cursor_crc*"
-t ".*kms_flip.*"

New tests passing
---
- pipe-A-cursor-size-change
- pipe-A-cursor-alpha-transparent

Performance
---
It's running slightly faster than the current implementation.

Results running the IGT[1] test
`igt@kms_cursor_crc@pipe-a-cursor-512x512-onscreen` ten times:

|  Frametime   |
|::|
|  Implementation |  Current  |   This commit  |
|:---:|:-:|:--:|
| frametime range |  9~22 ms  | 10~22 ms   |
| Average |  11.4 ms  | 12.32 ms   |

Memory consumption
==
It consumes less memory than the current implementation in
the common case (more detail in the commit message).

| Memory consumption (output dimensions) |
|:--:|
|   Current  | This patch|
|:--:|:-:|
|   Width * Heigth   | 2 * Width |

[1] IGT commit id: bc3f6833a12221a46659535dac06ebb312490eb4

XRGB to ARGB behavior
=
During the development, I decided to always fill the alpha channel of
the output pixel whenever the conversion from a format without an alpha
channel to ARGB16161616 is necessary. Therefore, I ignore the value
received from the XRGB and overwrite the value with 0x.

Primary plane and CRTC size
===
This patch series reworks the blend function to accept a primary plane with
a different size and position from CRTC.
Because now we need to fill the background, we had a loss in
performance with this change

---
Igor Torrente (9):
  drm: vkms: Alloc the compose frame using vzalloc
  drm: vkms: Replace hardcoded value of `vkms_composer.map` to
DRM_FORMAT_MAX_PLANES
  drm: vkms: Rename `vkms_composer` to `vkms_frame_info`
  drm: drm_atomic_helper: Add a new helper to deal with the writeback
connector validation
  drm: vkms: Add fb information to `vkms_writeback_job`
  drm: vkms: Refactor the plane composer to accept new formats
  drm: vkms: Supports to the case where primary plane doesn't match the
CRTC
  drm: vkms: Adds XRGB_16161616 and ARGB_1616161616 formats
  drm: vkms: Add support to the RGB565 format

 Documentation/gpu/vkms.rst|  13 +-
 drivers/gpu/drm/drm_atomic_helper.c   |  39 
 drivers/gpu/drm/vkms/Makefile |   1 +
 drivers/gpu/drm/vkms/vkms_composer.c  | 325 --
 drivers/gpu/drm/vkms/vkms_crtc.c  |   4 +
 drivers/gpu/drm/vkms/vkms_drv.h   |  41 +++-
 drivers/gpu/drm/vkms/vkms_formats.c   | 298 +++
 drivers/gpu/drm/vkms/vkms_formats.h   |  12 +
 drivers/gpu/drm/vkms/vkms_plane.c |  50 ++--
 drivers/gpu/drm/vkms/vkms_writeback.c |  35 ++-
 include/drm/drm_atomic_helper.h   |   3 +
 11 files changed, 596 insertions(+), 225 deletions(-)
 create mode 100644 drivers/gpu/drm/vkms/vkms_formats.c
 create mode 100644 drivers/gpu/drm/vkms/vkms_formats.h

-- 
2.30.2

[PATCH] fbdev: Fix unregistering of framebuffers without device

[Thomas Zimmermann]

OF framebuffers do not have an underlying device in the Linux
device hierarchy. Do a regular unregister call instead of hot
unplugging such a non-existing device. Fixes a NULL dereference.
An example error message on ppc64le is shown below.

  BUG: Kernel NULL pointer dereference on read at 0x0060
  Faulting instruction address: 0xc080dfa4
  Oops: Kernel access of bad area, sig: 11 [#1]
  LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries
  [...]
  CPU: 2 PID: 139 Comm: systemd-udevd Not tainted 5.17.0-ae085d7f9365 #1
  NIP:  c080dfa4 LR: c080df9c CTR: c0797430
  REGS: c4132fe0 TRAP: 0300   Not tainted  (5.17.0-ae085d7f9365)
  MSR:  82009033   CR: 28228282  XER: 2000
  CFAR: c000c80c DAR: 0060 DSISR: 4000 IRQMASK: 0
  GPR00: c080df9c c4133280 c169d200 0029
  GPR04: efff c4132f90 c4132f88 
  GPR08: c15658f8 c15cd200 c14f57d0 48228283
  GPR12:  c0003fffe300 2000 
  GPR16:  000113fc4a40 0005 000113fcfb80
  GPR20: 01000f7283b0  c0e4a588 c0e4a5b0
  GPR24: 0001 000a c00800db0168 c21f6ec0
  GPR28: c16d65a8 c4b36460  c16d64b0
  NIP [c080dfa4] do_remove_conflicting_framebuffers+0x184/0x1d0
  [c4133280] [c080df9c] 
do_remove_conflicting_framebuffers+0x17c/0x1d0 (unreliable)
  [c4133350] [c080e4d0] 
remove_conflicting_framebuffers+0x60/0x150
  [c41333a0] [c080e6f4] 
remove_conflicting_pci_framebuffers+0x134/0x1b0
  [c4133450] [c00800e70438] 
drm_aperture_remove_conflicting_pci_framebuffers+0x90/0x100 [drm]
  [c4133490] [c00800da0ce4] bochs_pci_probe+0x6c/0xa64 [bochs]
  [...]
  [c4133db0] [c002aaa0] system_call_exception+0x170/0x2d0
  [c4133e10] [c000c3cc] system_call_common+0xec/0x250

The bug [1] was introduced by commit 27599aacbaef ("fbdev: Hot-unplug
firmware fb devices on forced removal"). Most firmware framebuffers
have an underlying platform device, which can be hot-unplugged
before loading the native graphics driver. OF framebuffers do not
(yet) have that device. Fix the code by unregistering the framebuffer
as before without a hot unplug.

Tested with 5.17 on qemu ppc64le emulation.

Signed-off-by: Thomas Zimmermann 
Fixes: 27599aacbaef ("fbdev: Hot-unplug firmware fb devices on forced removal")
Reported-by: Sudip Mukherjee 
Cc: Zack Rusin 
Cc: Javier Martinez Canillas 
Cc: Hans de Goede 
Cc: sta...@vger.kernel.org # v5.11+
Cc: Helge Deller 
Cc: Daniel Vetter 
Cc: Sam Ravnborg 
Cc: Zheyu Ma 
Cc: Xiyu Yang 
Cc: Zhen Lei 
Cc: Matthew Wilcox 
Cc: Alex Deucher 
Cc: Tetsuo Handa 
Cc: Guenter Roeck 
Cc: linux-fb...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Link: https://lore.kernel.org/all/YkHXO6LGHAN0p1pq@debian/ # [1]
---
 drivers/video/fbdev/core/fbmem.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 34d6bb1bf82e..a6bb0e438216 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -1579,7 +1579,14 @@ static void do_remove_conflicting_framebuffers(struct 
apertures_struct *a,
 * If it's not a platform device, at least print a 
warning. A
 * fix would add code to remove the device from the 
system.
 */
-   if (dev_is_platform(device)) {
+   if (!device) {
+   /* TODO: Represent each OF framebuffer as its 
own
+* device in the device hierarchy. For now, offb
+* doesn't have such a device, so unregister the
+* framebuffer as before without warning.
+*/
+   do_unregister_framebuffer(registered_fb[i]);
+   } else if (dev_is_platform(device)) {
registered_fb[i]->forced_out = true;

platform_device_unregister(to_platform_device(device));
} else {
-- 
2.35.1

Re: [pull] amdgpu, amdkfd drm-next-5.18

[Alex Deucher]

On Fri, Mar 25, 2022 at 2:36 PM Alex Deucher  wrote:
>
> Hi Dave, Daniel,
>
> Fixes for 5.18.

Just wanted to make sure this didn't get missed.  This fixes some
warning splat reported by Linus, et al.

Alex

>
> The following changes since commit c6e90a1c660874736bd09c1fec6312b4b4c2ff7b:
>
>   Merge tag 'amd-drm-next-5.18-2022-03-18' of 
> https://gitlab.freedesktop.org/agd5f/linux into drm-next (2022-03-21 13:48:20 
> +1000)
>
> are available in the Git repository at:
>
>   https://gitlab.freedesktop.org/agd5f/linux.git 
> tags/amd-drm-next-5.18-2022-03-25
>
> for you to fetch changes up to 15f9cd4334c83716fa32647652a609e3ba6c998d:
>
>   drm/amdgpu/gfx10: enable gfx1037 clock counter retrieval function 
> (2022-03-25 12:40:25 -0400)
>
> 
> amd-drm-next-5.18-2022-03-25:
>
> amdgpu:
> - GFX 10.3.7 fixes
> - noretry updates
> - VCN fixes
> - TMDS fix
> - zstate fix for freesync video
> - DCN 3.1.5 fix
> - Display stack size fix
> - Audio fix
> - DCN 3.1 pstate fix
> - TMZ VCN fix
> - APU passthrough fix
> - Misc other fixes
>
> amdkfd:
> - Error handling fix
> - xgmi p2p fix
> - HWS VMIDs fix
>
> 
> Alex Deucher (2):
>   drm/amdgpu/gmc: use PCI BARs for APUs in passthrough
>   drm/amdgpu: add more cases to noretry=1
>
> Aurabindo Pillai (1):
>   drm/amd: Add USBC connector ID
>
> Charlene Liu (2):
>   drm/amd/display: fix audio format not updated after edid updated
>   drm/amd/display: remove destructive verify link for TMDS
>
> Chiawen Huang (1):
>   drm/amd/display: FEC check in timing validation
>
> Dan Carpenter (1):
>   drm/amdgpu: fix off by one in amdgpu_gfx_kiq_acquire()
>
> Divya Shikre (1):
>   drm/amdkfd: Check use_xgmi_p2p before reporting hive_id
>
> Emily Deng (1):
>   drm/amdgpu/vcn: Fix the register setting for vcn1
>
> Felix Kuehling (1):
>   drm/amdgpu: set noretry=1 for GFX 10.3.4
>
> Gabe Teeger (1):
>   drm/amd/display: Add support for zstate during extended vblank
>
> Guchun Chen (2):
>   drm/amdgpu: prevent memory wipe in suspend/shutdown stage
>   drm/amdgpu: conduct a proper cleanup of PDB bo
>
> Lang Yu (1):
>   drm/amdgpu: add workarounds for VCN TMZ issue on CHIP_RAVEN
>
> Leo (Hanghong) Ma (1):
>   drm/amd/display: Update VTEM Infopacket definition
>
> Nicholas Kazlauskas (1):
>   drm/amd/display: Fix p-state allow debug index on dcn31
>
> Oliver Logush (1):
>   drm/amd/display: Add fSMC_MSG_SetDtbClk support
>
> Prike Liang (2):
>   drm/amdgpu: set noretry for gfx 10.3.7
>   drm/amdgpu/gfx10: enable gfx1037 clock counter retrieval function
>
> QintaoShen (1):
>   drm/amdkfd: Check for potential null return of kmalloc_array()
>
> Rodrigo Siqueira (1):
>   drm/amd/display: Reduce stack size
>
> Stanley.Yang (1):
>   drm/amdgpu/pm: add asic smu support check
>
> Tianci Yin (1):
>   drm/amdgpu/vcn: improve vcn dpg stop procedure
>
> Tushar Patel (1):
>   drm/amdkfd: Fix Incorrect VMIDs passed to HWS
>
> Yifan Zhang (2):
>   drm/amdgpu/pm: fix the Stable pstate Test in amdgpu_test
>   drm/amdgpu: set noretry=1 for gc 10.3.6
>
>  drivers/gpu/drm/amd/amdgpu/ObjectID.h  |  1 +
>  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |  4 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c|  2 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c|  2 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c|  6 ++
>  drivers/gpu/drm/amd/amdgpu/amdgpu_object.c |  4 +-
>  drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c |  1 +
>  drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c |  2 +-
>  drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c  |  5 +-
>  drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c  |  2 +-
>  drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c  |  4 +-
>  drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c  | 71 
> ++
>  drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c  |  7 ++-
>  drivers/gpu/drm/amd/amdkfd/kfd_device.c| 14 ++---
>  drivers/gpu/drm/amd/amdkfd/kfd_events.c|  2 +
>  .../drm/amd/display/dc/clk_mgr/dcn315/dcn315_smu.c | 19 --
>  .../drm/amd/display/dc/clk_mgr/dcn315/dcn315_smu.h |  4 +-
>  drivers/gpu/drm/amd/display/dc/core/dc.c   | 23 +++
>  drivers/gpu/drm/amd/display/dc/core/dc_link.c  |  3 +-
>  drivers/gpu/drm/amd/display/dc/core/dc_resource.c  |  4 +-
>  drivers/gpu/drm/amd/display/dc/dc.h|  6 +-
>  drivers/gpu/drm/amd/display/dc/dc_stream.h |  2 +
>  .../drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c  |  8 ++-
>  drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c | 12 
>  .../gpu/drm/amd/display/dc/dcn31/dcn31_hubbub.c|  2 +
>  drivers/gpu/drm/amd/display/dc/dcn31/dcn31_hubp.c  |  8 +++
>  .../gpu/drm/amd/display/dc/dcn31/dcn31_resource.c  |  1 +
>  .../gpu/drm/amd/display/dc/dml/dcn20/dcn20_fpu.c   | 

Re: AMDGPU: regression on 5.17.1

[Michele Ballabio]

On Mon, 4 Apr 2022 13:03:41 -0400
Alex Deucher  wrote:

> On Sun, Apr 3, 2022 at 10:19 AM Michele Ballabio
>  wrote:
> >
> > Hi,
> > I've hit a regression on 5.17.1 (haven't tested 5.17.0, but
> > 5.16-stable didn't have this problem).
> >
> > The machine is a Ryzen 5 1600 with AMD graphics (RX 560).
> >
> > The regression I hit seems to trigger when the machine is left
> > idle at boot (I don't boot straight to X, I boot to a tty, login
> > and then start X). The machine after a while blanks the screen.
> > Usually, the screen unblanks as the keyboard is hit or the mouse
> > moves, but with kernel 5.17.1 the screen does not wake up. The
> > machine seems to run mostly fine: I can login from ssh, but I
> > cannot reboot or halt it: a sysrq sequence is needed for that. Note
> > that if the screen goes blank under X, it wakes up fine.
> >
> > Below a dmesg and two traces from syslog (they're quite similar).  
> 
> Can you bisect?  Does setting amdgpu.runpm=0 help?

I can try to bisect, should I narrow the search to drivers/gpu/drm/ ?

Setting amdgpu.runpm=0 works, the display now unblanks without problems.

Thanks,
Michele Ballabio

Re: [PATCH 1/2] dt-bindings: display: bridge: lt9211: Add Lontium LT9211 bridge driver

[Rob Herring]

On Wed, Mar 30, 2022 at 11:22:30PM +0200, Marek Vasut wrote:
> Add bindings for Lontium LT9211 Single/Dual-Link DSI/LVDS or Single DPI to
> Single-link/Dual-Link DSI/LVDS or Single DPI bridge. This chip is highly
> capable at converting formats, but sadly it is also highly undocumented.
> 
> Signed-off-by: Marek Vasut 
> Cc: Laurent Pinchart 
> Cc: Lucas Stach 
> Cc: Maxime Ripard 
> Cc: Rob Herring 
> Cc: Robert Foss 
> Cc: Sam Ravnborg 
> Cc: Thomas Zimmermann 
> Cc: devicet...@vger.kernel.org
> To: dri-devel@lists.freedesktop.org
> ---
>  .../display/bridge/lontium,lt9211.yaml| 117 ++
>  1 file changed, 117 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/bridge/lontium,lt9211.yaml
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/bridge/lontium,lt9211.yaml 
> b/Documentation/devicetree/bindings/display/bridge/lontium,lt9211.yaml
> new file mode 100644
> index ..2faa855b3824
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/lontium,lt9211.yaml
> @@ -0,0 +1,117 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/bridge/lontium,lt9211.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Lontium LT9211 DSI/LVDS/DPI to DSI/LVDS/DPI bridge.
> +
> +maintainers:
> +  - Marek Vasut 
> +
> +description: |
> +  The LT9211 are bridge devices which convert Single/Dual-Link DSI/LVDS
> +  or Single DPI to Single/Dual-Link DSI/LVDS or Single DPI.
> +
> +properties:
> +  compatible:
> +enum:
> +  - lontium,lt9211
> +
> +  reg:
> +maxItems: 1
> +
> +  interrupts:
> +maxItems: 1
> +
> +  reset-gpios:
> +maxItems: 1
> +description: GPIO connected to active high RESET pin.
> +
> +  vccio-supply:
> +description: Regulator for 1.8V IO power.
> +
> +  ports:
> +$ref: /schemas/graph.yaml#/properties/ports
> +
> +properties:
> +  port@0:
> +$ref: /schemas/graph.yaml#/properties/port
> +description:
> +  Primary MIPI DSI port-1 for MIPI input or
> +  LVDS port-1 for LVDS input or DPI input.
> +
> +  port@1:
> +$ref: /schemas/graph.yaml#/properties/port
> +description:
> +  Additional MIPI port-2 for MIPI input or LVDS port-2
> +  for LVDS input. Used in combination with primary
> +  port-1 to drive higher resolution displays
> +
> +  port@2:
> +$ref: /schemas/graph.yaml#/properties/port
> +description:
> +  Primary MIPI DSI port-1 for MIPI output or
> +  LVDS port-1 for LVDS output or DPI output.
> +
> +  port@3:
> +$ref: /schemas/graph.yaml#/properties/port
> +description:
> +  Additional MIPI port-2 for MIPI output or LVDS port-2
> +  for LVDS output. Used in combination with primary
> +  port-1 to drive higher resolution displays.
> +
> +required:
> +  - port@0
> +  - port@2
> +
> +required:
> +  - compatible
> +  - reg
> +  - vccio-supply
> +  - ports
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +#include 
> +#include 
> +
> +i2c10 {

i2c {

With that,

Reviewed-by: Rob Herring 

> +  #address-cells = <1>;
> +  #size-cells = <0>;
> +
> +  hdmi-bridge@3b {
> +compatible = "lontium,lt9211";
> +reg = <0x3b>;
> +
> +reset-gpios = < 128 GPIO_ACTIVE_HIGH>;
> +interrupts-extended = < 84 IRQ_TYPE_EDGE_FALLING>;
> +
> +vccio-supply = <_1v8>;
> +
> +ports {
> +  #address-cells = <1>;
> +  #size-cells = <0>;
> +
> +  port@0 {
> +reg = <0>;
> +
> +endpoint {
> +  remote-endpoint = <_out>;
> +};
> +  };
> +
> +  port@2 {
> +reg = <2>;
> +
> +endpoint {
> +  remote-endpoint = <_in_lvds>;
> +};
> +  };
> +};
> +  };
> +};
> +
> +...
> -- 
> 2.35.1
> 
> 

Re: [RFC][PATCH 2/3] drm/modes: Make width-mm/height-mm mandatory in of_get_drm_panel_display_mode()

[Marek Vasut]

On 4/4/22 18:01, Rob Herring wrote:

On Sat, Apr 02, 2022 at 07:55:59PM +0200, Marek Vasut wrote:

On 4/2/22 19:08, Noralf Trønnes wrote:



Den 02.04.2022 18.39, skrev Marek Vasut:

On 4/2/22 09:45, Noralf Trønnes wrote:



Den 02.04.2022 06.28, skrev Marek Vasut:

On 4/2/22 05:19, Laurent Pinchart wrote:

On Fri, Apr 01, 2022 at 10:36:24PM +0200, Marek Vasut wrote:

On 4/1/22 20:46, Laurent Pinchart wrote:

On Fri, Apr 01, 2022 at 06:37:54PM +0200, Marek Vasut wrote:

Make the width-mm/height-mm panel properties mandatory in
of_get_drm_panel_display_mode(), print error message and
return -ve in case these DT properties are not present.
This is needed to correctly report panel dimensions.


Can we guarantee this won't cause a regression ?


For the upstream DTs, I think we can.
For downstream DTs, we cannot know.


Are there users of this function whose DT bindings don't require the
width-mm and height-mm properties ?


There is literally one user of this function upstream:
drivers/gpu/drm/tiny/panel-mipi-dbi.c


Yes, the function was added for that driver since it was so generic in
nature. What about adding an argument to of_get_drm_panel_display_mode()
that tells if the properties are mandatory or not?


Sure, we can do that, but maybe the question here is even bigger than
this series.

Should every panel set mandatory width_mm/height_mm so e.g. the user
space can infer DPI from it and set up scaling accordingly, or should
width_mm/height_mm be optional ?

I think width_mm/height_mm should be mandatory for all panels.

Thoughts ?


If this had come up during the review of the driver I would have no
problem making it mandatory. It makes sense for DPI. Maybe it's possible
to get around the ABI break by getting in a change through -fixes before
5.18 is released? I'm fine with that.


Well that's awesome, the dbi-spi.yaml didn't land in any kernel release yet,
so we still have a chance to fix it ? Rob ?


Yes, it can be fixed. And the binding, not the kernel, is the place to
enforce it being mandatory IMO.


All right, I sent 1/3 separately with Fixes: tag, so it can be applied .

Re: [PATCH v2 1/3] mm: add vm_normal_lru_pages for LRU handled pages only

[Sierra Guiza, Alejandro (Alex)]

On 4/4/2022 12:38 PM, Jason Gunthorpe wrote:

On Fri, Apr 01, 2022 at 04:08:35PM -0400, Felix Kuehling wrote:


In general I find the vm_normal_lru_page vs vm_normal_page
API highly confusing.  An explicit check for zone device pages
in the dozen or so spots that care has a much better documentation
value, especially if accompanied by comments where it isn't entirely
obvious.

OK. We can do that. It would solve the function naming problem, and we'd
have more visibility of device page handling in more places in the kernel,
which has educational value.

Personally I find the 'is page XYZ' pretty confusing, like I don't
know half of what the PageKsm annotations are for..

Testing against a specific property the code goes on to use right away
seems more descriptive to me.


Hi Jason,

Are you referring to test for properties such as is_lru_page, 
is_numa_page, is_lockable_page, etc?

Otherwise, could you provide an example?

Regards,
Alex Sierra



Jason

[PATCH] dt-bindings: display: panel: mipi-dbi-spi: Make width-mm/height-mm mandatory

[Marek Vasut]

Make the width-mm/height-mm panel properties mandatory
to correctly report the panel dimensions to the OS.

Fixes: 2f3468b82db97 ("dt-bindings: display: add bindings for MIPI DBI 
compatible SPI panels")
Signed-off-by: Marek Vasut 
Cc: Christoph Niedermaier 
Cc: Daniel Vetter 
Cc: Dmitry Osipenko 
Cc: Laurent Pinchart 
Cc: Noralf Trønnes 
Cc: Rob Herring 
Cc: Robert Foss 
Cc: Sam Ravnborg 
Cc: Thomas Zimmermann 
Cc: devicet...@vger.kernel.org
To: dri-devel@lists.freedesktop.org
---
 .../devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml   | 2 ++
 1 file changed, 2 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml 
b/Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml
index f29789994b180..c2df8d28aaf5f 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml
+++ b/Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml
@@ -83,6 +83,8 @@ properties:
 required:
   - compatible
   - reg
+  - width-mm
+  - height-mm
   - panel-timing
 
 unevaluatedProperties: false
-- 
2.35.1

Re: [PATCH v6 4/4] drm: allow real encoder to be passed for drm_writeback_connector

[Rob Clark]

On Fri, Apr 1, 2022 at 8:38 AM Laurent Pinchart
 wrote:
>
> Hi Abhinav,
>
> Thank you for the patch.
>
> On Thu, Mar 31, 2022 at 05:12:13PM -0700, Abhinav Kumar wrote:
> > For some vendor driver implementations, display hardware can
> > be shared between the encoder used for writeback and the physical
> > display.
> >
> > In addition resources such as clocks and interrupts can
> > also be shared between writeback and the real encoder.
> >
> > To accommodate such vendor drivers and hardware, allow
> > real encoder to be passed for drm_writeback_connector.
> >
> > changes in v6:
> >   - assign the encoder inside
> > drm_writeback_connector_init_with_encoder() for
> > better readability
> >   - improve some documentation for internal encoder
> >
> > Co-developed-by: Kandpal Suraj 
> > Signed-off-by: Kandpal Suraj 
> > Signed-off-by: Abhinav Kumar 
> > ---
> >  drivers/gpu/drm/drm_writeback.c | 18 --
> >  drivers/gpu/drm/vc4/vc4_txp.c   | 14 --
> >  include/drm/drm_writeback.h | 21 +++--
>
> Please split this in two patches, one for the DRM core and one for the
> VC4 driver. This applies to most patches as a general rule, with the
> main exception being API refactoring that requires changing the
> implementation and all its users in a single patch.

But this *is* API refactoring ;-)

BR,
-R

> >  3 files changed, 39 insertions(+), 14 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_writeback.c 
> > b/drivers/gpu/drm/drm_writeback.c
> > index 797223c..7f72109 100644
> > --- a/drivers/gpu/drm/drm_writeback.c
> > +++ b/drivers/gpu/drm/drm_writeback.c
> > @@ -179,21 +179,21 @@ int drm_writeback_connector_init(struct drm_device 
> > *dev,
> >  {
> >   int ret = 0;
> >
> > - drm_encoder_helper_add(_connector->encoder, enc_helper_funcs);
> > + drm_encoder_helper_add(_connector->internal_encoder, 
> > enc_helper_funcs);
> >
> > - wb_connector->encoder.possible_crtcs = possible_crtcs;
> > + wb_connector->internal_encoder.possible_crtcs = possible_crtcs;
> >
> > - ret = drm_encoder_init(dev, _connector->encoder,
> > + ret = drm_encoder_init(dev, _connector->internal_encoder,
> >  _writeback_encoder_funcs,
> >  DRM_MODE_ENCODER_VIRTUAL, NULL);
> >   if (ret)
> >   return ret;
> >
> > - ret = drm_writeback_connector_init_with_encoder(dev, wb_connector, 
> > _connector->encoder,
> > - con_funcs, formats, n_formats);
> > + ret = drm_writeback_connector_init_with_encoder(dev, wb_connector,
> > + _connector->internal_encoder, con_funcs, formats, 
> > n_formats);
> >
> >   if (ret)
> > - drm_encoder_cleanup(_connector->encoder);
> > + drm_encoder_cleanup(_connector->internal_encoder);
> >
> >   return ret;
> >  }
> > @@ -238,6 +238,12 @@ int drm_writeback_connector_init_with_encoder(struct 
> > drm_device *dev,
> >   struct drm_mode_config *config = >mode_config;
> >   int ret = create_writeback_properties(dev);
> >
> > + /*
> > +  * Assign the encoder passed to this API to the wb_connector's 
> > encoder.
> > +  * For drm_writeback_connector_init(), this shall be the 
> > internal_encoder
> > +  */
> > + wb_connector->encoder = enc;
> > +
> >   if (ret != 0)
> >   return ret;
> >
> > diff --git a/drivers/gpu/drm/vc4/vc4_txp.c b/drivers/gpu/drm/vc4/vc4_txp.c
> > index 5e53f02..a9b4f83 100644
> > --- a/drivers/gpu/drm/vc4/vc4_txp.c
> > +++ b/drivers/gpu/drm/vc4/vc4_txp.c
> > @@ -151,6 +151,8 @@ struct vc4_txp {
> >
> >   struct platform_device *pdev;
> >
> > + struct drm_encoder drm_enc;
> > +
> >   struct drm_writeback_connector connector;
> >
> >   void __iomem *regs;
> > @@ -159,7 +161,7 @@ struct vc4_txp {
> >
> >  static inline struct vc4_txp *encoder_to_vc4_txp(struct drm_encoder 
> > *encoder)
> >  {
> > - return container_of(encoder, struct vc4_txp, connector.encoder);
> > + return container_of(encoder, struct vc4_txp, drm_enc);
> >  }
> >
> >  static inline struct vc4_txp *connector_to_vc4_txp(struct drm_connector 
> > *conn)
> > @@ -499,9 +501,9 @@ static int vc4_txp_bind(struct device *dev, struct 
> > device *master, void *data)
> >
> >   wb_conn = >connector;
> >
> > - drm_encoder_helper_add(_conn->encoder, 
> > _txp_encoder_helper_funcs);
> > + drm_encoder_helper_add(>drm_enc, _txp_encoder_helper_funcs);
> >
> > - ret = drm_encoder_init(drm, _conn->encoder,
> > + ret = drm_encoder_init(drm, >drm_enc,
> >   _txp_encoder_funcs,
> >   DRM_MODE_ENCODER_VIRTUAL, NULL);
> >
> > @@ -511,10 +513,10 @@ static int vc4_txp_bind(struct device *dev, struct 
> > device *master, void *data)
> >   drm_connector_helper_add(_conn->base,
> >_txp_connector_helper_funcs);
> >
> > - ret = 

Re: Build regressions/improvements in v5.18-rc1

[Kalle Valo]

Geert Uytterhoeven  writes:

>> /kisskb/src/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c:
>> error: case label does not reduce to an integer constant: => 3798:2,
>> 3809:2
>
> arm64-gcc5.4/arm64-allmodconfig
> powerpc-gcc5/powerpc-allmodconfig
> powerpc-gcc5/ppc64_book3e_allmodconfig

After v5.17 there were two commits to brcmfmac/sdio.c:

$ git log --oneline v5.17.. 
drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
ed26edf7bfd9 brcmfmac: Add BCM43454/6 support
6d766d8cb505 brcmfmac: pcie: Declare missing firmware files in pcie.c

I can't see how either of them could cause this warning. Could something
else cause this or am I missing something?

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

RE: [PATCH v6 7/8] drm/msm/dp: Support edp/dp without hpd

[Sankeerth Billakanti (QUIC)]

Hi Doug,

> On Wed, Mar 30, 2022 at 9:04 AM Sankeerth Billakanti
>  wrote:
> >
> > Some eDP sinks or platform boards will not support hpd.
> > This patch adds support for those cases.
> 
> You could say more, like:
> 
> If we're not using HPD then _both_ the panel node and the eDP controller
> node will have "no-hpd". This tells the eDP panel code to hardcode the
> maximum possible delay for a panel to power up and tells the eDP driver that
> it should continue to do transfers even if HPD isn't asserted.
> 

Okay. I will add it

> 
> > Signed-off-by: Sankeerth Billakanti 
> > ---
> >  drivers/gpu/drm/msm/dp/dp_catalog.c | 15 ---
> >  1 file changed, 12 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.c
> > b/drivers/gpu/drm/msm/dp/dp_catalog.c
> > index 1809ce2..8f1fc71 100644
> > --- a/drivers/gpu/drm/msm/dp/dp_catalog.c
> > +++ b/drivers/gpu/drm/msm/dp/dp_catalog.c
> > @@ -244,10 +244,17 @@ void dp_catalog_aux_update_cfg(struct
> dp_catalog
> > *dp_catalog)
> >
> >  int dp_catalog_aux_wait_for_hpd_connect_state(struct dp_catalog
> > *dp_catalog)  {
> > -   u32 state;
> > +   u32 state, hpd_en;
> > struct dp_catalog_private *catalog = container_of(dp_catalog,
> > struct dp_catalog_private,
> > dp_catalog);
> >
> > +   hpd_en = dp_read_aux(catalog, REG_DP_DP_HPD_CTRL);
> > +   hpd_en &= DP_DP_HPD_CTRL_HPD_EN;
> > +
> > +   /* no-hpd case */
> > +   if (!hpd_en)
> > +   return 0;
> > +
> > /* poll for hpd connected status every 2ms and timeout after 500ms 
> > */
> > return readl_poll_timeout(catalog->io->dp_controller.aux.base +
> > REG_DP_DP_HPD_INT_STATUS, @@ -586,8
> > +593,10 @@ void dp_catalog_ctrl_hpd_config(struct dp_catalog
> *dp_catalog)
> > reftimer |= DP_DP_HPD_REFTIMER_ENABLE;
> > dp_write_aux(catalog, REG_DP_DP_HPD_REFTIMER, reftimer);
> >
> > -   /* Enable HPD */
> > -   dp_write_aux(catalog, REG_DP_DP_HPD_CTRL,
> DP_DP_HPD_CTRL_HPD_EN);
> > +   /* Enable HPD if supported*/
> > +   if (!of_property_read_bool(catalog->dev->of_node, "no-hpd"))
> 
> I don't think this is a particularly lightweight operation. It's literally 
> iterating
> through all of our device tree properties and doing string compares on them.
> ...but this function is called somewhat often, isn't it? It feels like the 
> kind of
> thing that should happen at probe time and be stored in a boolean.
> 
> ...and then you can use that same boolean in
> dp_catalog_aux_wait_for_hpd_connect_state() rather than reading the
> register value, right?
> 
It is called twice for DP. Once while booting through a thread scheduled from 
kms_obj_init
and when resuming from PM suspend.

With aux_bus addition, this function will be called thrice for eDP. Once during 
bootup with
aux_bus, then from scheduled event from kms_obj_init and pm resume like DP.

I will check if we can use a no-hpd Boolean flag instead.

> 
> -Doug

Thank you,
Sankeerth

[PATCH] drm/atomic: Convert a warning to dbg atomic printk

[Zack Rusin]

From: Zack Rusin 

By default each flip times out after 0.1 sec and a warning about the
time out is added to the kernel log. The warning is harmless because
there's another flip coming right after but it can quickly fill up
the log, e.g. missing 2 flips every second over a 24 hour span will
add about 172 thousand lines to the log.
Skip printing it by default and instead add it to the atomic drm debug
category. It can be trivially enabled via drm.debug=0x10 and it avoids
filling up logs by default.

This is particularly important on vm's where presentation might be CPU
bound and running multiple vm's or under a CPU heavy load can easily
lead to missing mutliple flips and any actual errors are often blamed
on this due to it being so prevalent in the logs.
Fixes a bunch of bugs reported to RedHat (1792515, 1884401, 1896139
and 1884401) and SUSE (210123) where people complain about having
their logs spammed by this message and blame various errors on it.

Signed-off-by: Zack Rusin 
---
 drivers/gpu/drm/drm_atomic_helper.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 9603193d2fa1..e88b4d83fd5c 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1566,8 +1566,8 @@ void drm_atomic_helper_wait_for_flip_done(struct 
drm_device *dev,
 
ret = wait_for_completion_timeout(>flip_done, 10 * HZ);
if (ret == 0)
-   drm_err(dev, "[CRTC:%d:%s] flip_done timed out\n",
-   crtc->base.id, crtc->name);
+   drm_dbg_atomic(dev, "[CRTC:%d:%s] flip_done timed 
out\n",
+  crtc->base.id, crtc->name);
}
 
if (old_state->fake_commit)
-- 
2.32.0

RE: [PATCH v6 8/8] drm/msm/dp: Handle eDP mode_valid differently from dp

[Sankeerth Billakanti (QUIC)]

Hi Doug,

> On Wed, Mar 30, 2022 at 11:02 PM Sankeerth Billakanti (QUIC)
>  wrote:
> >
> > Hi Dmitry,
> >
> > > On Wed, 30 Mar 2022 at 19:04, Sankeerth Billakanti
> > >  wrote:
> > > >
> > > > The panel-edp driver modes needs to be validated differently from
> > > > DP because the link capabilities are not available for EDP by that time.
> > > >
> > > > Signed-off-by: Sankeerth Billakanti 
> > >
> > > This should not be necessary after
> > >
> https://patchwork.freedesktop.org/patch/479261/?series=101682=1.
> > > Could you please check?
> > >
> >
> > The check for DP_MAX_PIXEL_CLK_KHZ is not necessary anymore but we
> > need to return early for eDP because unlike DP, eDP context will not
> > have the information about the number of lanes and link clock.
> >
> > So, I will modify the patch to return after the DP_MAX_PIXEL_CLK_KHZ
> check if is_eDP is set.
> 
> I haven't walked through all the relevant code but something you said above
> sounds strange. You say that for eDP we don't have info about the number
> of lanes? We _should_.
> 
> It's certainly possible to have a panel that supports _either_ 1 or 2 lanes 
> but
> then only physically connect 1 lane to it. ...or you could have a panel that
> supports 2 or 4 lanes and you only connect 1 lane.
> See, for instance, ti_sn_bridge_parse_lanes. There we assume 4 lanes but if
> a "data-lanes" property is present then we can use that to know that fewer
> lanes are physically connected.
> 
> It's also possible to connect more lanes to a panel than it supports.
> You could connect 2 lanes to it but then it only supports 1. This case needs 
> to
> be handled as well...
>

I was referring to the checks we do for DP in dp_bridge_mode_valid. We check if 
the
Link bandwidth can support the pixel bandwidth. For an external DP connection, 
the
Initial DPCD/EDID read after cable connection will return the sink capabilities 
like link
rate, lane count and bpp information that are used to we filter out the 
unsupported
modes from the list of modes from EDID.

For eDP case, the dp driver performs the first dpcd read during bridge_enable. 
The
dp_bridge_mode_valid function is executed before bridge_enable and hence does
not have the full link or the sink capabilities information like external DP 
connection,
by then.

So, we need to proceed with the reported mode for eDP.

> 
> -Doug

RE: [PATCH v6 4/8] drm/msm/dp: avoid handling masked interrupts

[Sankeerth Billakanti (QUIC)]

> On Thu, 31 Mar 2022 at 14:05, Sankeerth Billakanti
>  wrote:
> >
> > Hi Dmitry,
> >
> > > On 31/03/2022 08:53, Sankeerth Billakanti (QUIC) wrote:
> > > > Hi Dmitry,
> > > >
> > > >> On Wed, 30 Mar 2022 at 19:03, Sankeerth Billakanti
> > > >>  wrote:
> > > >>>
> > > >>> The interrupt register will still reflect the connect and
> > > >>> disconnect interrupt status without generating an actual HW
> interrupt.
> > > >>> The controller driver should not handle those masked interrupts.
> > > >>>
> > > >>> Signed-off-by: Sankeerth Billakanti 
> > > >>> ---
> > > >>>   drivers/gpu/drm/msm/dp/dp_catalog.c | 5 +++--
> > > >>>   1 file changed, 3 insertions(+), 2 deletions(-)
> > > >>>
> > > >>> diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.c
> > > >>> b/drivers/gpu/drm/msm/dp/dp_catalog.c
> > > >>> index 3c16f95..1809ce2 100644
> > > >>> --- a/drivers/gpu/drm/msm/dp/dp_catalog.c
> > > >>> +++ b/drivers/gpu/drm/msm/dp/dp_catalog.c
> > > >>> @@ -608,13 +608,14 @@ u32 dp_catalog_hpd_get_intr_status(struct
> > > >>> dp_catalog *dp_catalog)  {
> > > >>>  struct dp_catalog_private *catalog = container_of(dp_catalog,
> > > >>>  struct dp_catalog_private, 
> > > >>> dp_catalog);
> > > >>> -   int isr = 0;
> > > >>> +   int isr, mask;
> > > >>>
> > > >>>  isr = dp_read_aux(catalog, REG_DP_DP_HPD_INT_STATUS);
> > > >>>  dp_write_aux(catalog, REG_DP_DP_HPD_INT_ACK,
> > > >>>   (isr & DP_DP_HPD_INT_MASK));
> > > >>> +   mask = dp_read_aux(catalog, REG_DP_DP_HPD_INT_MASK);
> > > >>>
> > > >>> -   return isr;
> > > >>> +   return isr & (DP_DP_HPD_STATE_STATUS_MASK | mask);
> > > >>
> > > >> I suspect that the logic is inverted here. Shouldn't it be:
> > > >>
> > > >> return isr & DP_DP_HPD_STATE_STATUS_MASK & mask;
> > > >>
> > > >> ?
> > > >>
> > > >
> > > > The value of DP_DP_HPD_STATE_STATUS_MASK is 0xE000 and the
> > > value
> > > > of the read interrupt mask variable could be is 0xF.
> > > >
> > > > The mask value is indicated via the register,
> > > > REG_DP_DP_HPD_INT_MASK,
> > > bits 3:0.
> > > > The HPD status is indicated via a different read-only register
> > > REG_DP_DP_HPD_INT_STATUS, bits 31:29.
> > >
> > > I see. Maybe the following expression would be better?
> > >
> > > return isr & (mask & ~DP_DP_HPD_INT_MASK);
> 
> Ugh, excuse me please. I meant:
> 
> return isr & (mask | ~DP_DP_HPD_INT_MASK);
> 

Okay. I will change it.

> > >
> >
> > I believe the confusion occurred because the
> > DP_DP_HPD_STATE_STATUS_CONNECTED and others were defined under
> the same register definition as REG_DP_DP_HPD_INT_MASK I will rearrange
> the definitions below.
> >
> > #define REG_DP_DP_HPD_INT_MASK  (0x000C)
> > #define DP_DP_HPD_PLUG_INT_MASK (0x0001)
> > #define DP_DP_IRQ_HPD_INT_MASK  (0x0002)
> > #define DP_DP_HPD_REPLUG_INT_MASK   (0x0004)
> > #define DP_DP_HPD_UNPLUG_INT_MASK   (0x0008)
> > #define DP_DP_HPD_INT_MASK  (DP_DP_HPD_PLUG_INT_MASK | \
> > DP_DP_IRQ_HPD_INT_MASK | \
> > DP_DP_HPD_REPLUG_INT_MASK | 
> > \
> >
> > DP_DP_HPD_UNPLUG_INT_MASK)
> >
> > Below are status bits from register REG_DP_DP_HPD_INT_STATUS
> >
> > #define DP_DP_HPD_STATE_STATUS_CONNECTED(0x4000)
> > #define DP_DP_HPD_STATE_STATUS_PENDING  (0x2000)
> > #define DP_DP_HPD_STATE_STATUS_DISCONNECTED (0x)
> > #define DP_DP_HPD_STATE_STATUS_MASK (0xE000)
> >
> > DP_DP_HPD_INT_MASK is 0xF and scope of mask variable is also 0xF (bits
> 3:0), mask & ~DP_DP_HPD_INT_MASK is 0 always.
> >
> > For DP, we want to enable all interrupts.
> > So the programmed mask value is 0xF. We want to return 0x4001 for
> > connect and 8 for disconnect
> >
> > For eDP, we want to disable the connect and disconnect interrupts. So,
> > the mask will be 0x6 (i.e. DP_DP_IRQ_HPD_INT_MASK |
> DP_DP_HPD_REPLUG_INT_MASK) We want to return 0x4000 (or
> 0x2000 based on hpd line status) and 0 for eDP connect and disconnect
> respectively.
> >
> > > >
> > > > isr & DP_DP_HPD_STATE_STATUS_MASK & mask, will return 0 always.
> > > >
> > > >>>   }
> > > >>>
> > > >>>   int dp_catalog_ctrl_get_interrupt(struct dp_catalog
> > > >>> *dp_catalog)
> > > >>> --
> > > >>> 2.7.4
> > > >>>
> > > >>
> > > >>
> > > >> --
> > > >> With best wishes
> > > >> Dmitry
> > > >
> > > > Thank you,
> > > > Sankeerth
> > >
> > >
> > > --
> > > With best wishes
> > > Dmitry
> >
> > Thank you,
> > Sankeerth
> 
> 
> 
> --
> With best wishes
> Dmitry

Re: [PATCH 3/4] dt-bindings: drm/bridge: anx7625: Change bus-type to 7 (DPI)

[Rob Herring]

On Mon, Mar 28, 2022 at 08:09:54PM +0800, Xin Ji wrote:
> Change bus-type define for DPI.
> 
> Fixes: a43661e7e819 ("dt-bindings:drm/bridge:anx7625:add vendor define")
> 
> Signed-off-by: Xin Ji 
> ---
>  .../devicetree/bindings/display/bridge/analogix,anx7625.yaml  | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml 
> b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> index 0d38d6fe3983..4590186c4a0b 100644
> --- a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> +++ b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> @@ -106,7 +106,7 @@ properties:
>remote-endpoint: true
>  
>bus-type:
> -enum: [1, 5]
> +enum: [7]

Changing is an ABI break, but didn't we revert adding this?

>  default: 1
>  
>data-lanes: true
> @@ -158,7 +158,7 @@ examples:
>  reg = <0>;
>  anx7625_in: endpoint {
>  remote-endpoint = <_dsi>;
> -bus-type = <5>;
> +bus-type = <7>;
>  data-lanes = <0 1 2 3>;
>  };
>  };
> -- 
> 2.25.1
> 
> 

Re: [RFC v4 2/8] cgroup: gpu: Add a cgroup controller for allocator attribution of GPU memory

[Tejun Heo]

Hello,

On Wed, Mar 30, 2022 at 01:56:09PM -0700, T.J. Mercier wrote:
> The use case we have for accounting the total (separate from the
> individual devices) is to include the value as part of bugreports, for
> understanding the system-wide amount of dmabuf allocations. I'm not
> aware of an existing need to limit the total. Admittedly this is just
> the sum over the devices, but we currently maintain out of tree code
> to do this sort of thing today. [1]

So, drop this part?

Thanks.

-- 
tejun

Re: [PATCH v2 1/3] mm: add vm_normal_lru_pages for LRU handled pages only

[Jason Gunthorpe]

On Fri, Apr 01, 2022 at 04:08:35PM -0400, Felix Kuehling wrote:

> > In general I find the vm_normal_lru_page vs vm_normal_page
> > API highly confusing.  An explicit check for zone device pages
> > in the dozen or so spots that care has a much better documentation
> > value, especially if accompanied by comments where it isn't entirely
> > obvious.
> 
> OK. We can do that. It would solve the function naming problem, and we'd
> have more visibility of device page handling in more places in the kernel,
> which has educational value.

Personally I find the 'is page XYZ' pretty confusing, like I don't
know half of what the PageKsm annotations are for..

Testing against a specific property the code goes on to use right away
seems more descriptive to me.

Jason

Re: AMDGPU: regression on 5.17.1

[Alex Deucher]

On Sun, Apr 3, 2022 at 10:19 AM Michele Ballabio  wrote:
>
> Hi,
> I've hit a regression on 5.17.1 (haven't tested 5.17.0, but
> 5.16-stable didn't have this problem).
>
> The machine is a Ryzen 5 1600 with AMD graphics (RX 560).
>
> The regression I hit seems to trigger when the machine is left
> idle at boot (I don't boot straight to X, I boot to a tty, login and then
> start X). The machine after a while blanks the screen. Usually, the screen
> unblanks as the keyboard is hit or the mouse moves, but with kernel 5.17.1
> the screen does not wake up. The machine seems to run mostly fine: I can
> login from ssh, but I cannot reboot or halt it: a sysrq sequence is needed
> for that. Note that if the screen goes blank under X, it wakes up fine.
>
> Below a dmesg and two traces from syslog (they're quite similar).

Can you bisect?  Does setting amdgpu.runpm=0 help?

Alex


>
> dmesg:
> --
> [0.00] Linux version 5.17.1 (r...@darkstar.example.org) (gcc (GCC) 
> 11.2.0, GNU ld version 2.38-slack151) #1 SMP PREEMPT Thu Mar 31 18:20:46 CEST 
> 2022
> [0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point 
> registers'
> [0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
> [0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
> [0.00] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
> [0.00] x86/fpu: Enabled xstate features 0x7, context size is 832 
> bytes, using 'compacted' format.
> [0.00] signal: max sigframe size: 1776
> [0.00] BIOS-provided physical RAM map:
> [0.00] BIOS-e820: [mem 0x-0x0009d3ff] usable
> [0.00] BIOS-e820: [mem 0x0009d400-0x0009] reserved
> [0.00] BIOS-e820: [mem 0x000e-0x000f] reserved
> [0.00] BIOS-e820: [mem 0x0010-0x03ff] usable
> [0.00] BIOS-e820: [mem 0x0400-0x04009fff] ACPI NVS
> [0.00] BIOS-e820: [mem 0x0400a000-0x09bf] usable
> [0.00] BIOS-e820: [mem 0x09c0-0x09ff] reserved
> [0.00] BIOS-e820: [mem 0x0a00-0x0aff] usable
> [0.00] BIOS-e820: [mem 0x0b00-0x0b01] reserved
> [0.00] BIOS-e820: [mem 0x0b02-0xd4434fff] usable
> [0.00] BIOS-e820: [mem 0xd4435000-0xd444] ACPI 
> data
> [0.00] BIOS-e820: [mem 0xd445-0xda830fff] usable
> [0.00] BIOS-e820: [mem 0xda831000-0xda970fff] reserved
> [0.00] BIOS-e820: [mem 0xda971000-0xda97afff] ACPI 
> data
> [0.00] BIOS-e820: [mem 0xda97b000-0xdaa82fff] usable
> [0.00] BIOS-e820: [mem 0xdaa83000-0xdae3efff] ACPI NVS
> [0.00] BIOS-e820: [mem 0xdae3f000-0xdb93efff] reserved
> [0.00] BIOS-e820: [mem 0xdb93f000-0xddff] usable
> [0.00] BIOS-e820: [mem 0xde00-0xdfff] reserved
> [0.00] BIOS-e820: [mem 0xf800-0xfbff] reserved
> [0.00] BIOS-e820: [mem 0xfd80-0xfdff] reserved
> [0.00] BIOS-e820: [mem 0xfea0-0xfea0] reserved
> [0.00] BIOS-e820: [mem 0xfeb8-0xfec01fff] reserved
> [0.00] BIOS-e820: [mem 0xfec1-0xfec10fff] reserved
> [0.00] BIOS-e820: [mem 0xfec3-0xfec30fff] reserved
> [0.00] BIOS-e820: [mem 0xfed0-0xfed00fff] reserved
> [0.00] BIOS-e820: [mem 0xfed4-0xfed44fff] reserved
> [0.00] BIOS-e820: [mem 0xfed8-0xfed8] reserved
> [0.00] BIOS-e820: [mem 0xfedc2000-0xfedc] reserved
> [0.00] BIOS-e820: [mem 0xfedd4000-0xfedd5fff] reserved
> [0.00] BIOS-e820: [mem 0xfee0-0xfeef] reserved
> [0.00] BIOS-e820: [mem 0xff00-0x] reserved
> [0.00] BIOS-e820: [mem 0x0001-0x00041f37] usable
> [0.00] NX (Execute Disable) protection: active
> [0.00] SMBIOS 3.1.1 present.
> [0.00] DMI: System manufacturer System Product Name/PRIME B350-PLUS, 
> BIOS 4011 04/19/2018
> [0.00] tsc: Fast TSC calibration failed
> [0.00] e820: update [mem 0x-0x0fff] usable ==> reserved
> [0.00] e820: remove [mem 0x000a-0x000f] usable
> [0.00] last_pfn = 0x41f380 max_arch_pfn = 0x4
> [0.00] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WP  UC- WT
> [0.00] e820: update [mem 0xe000-0x] usable ==> reserved
> [0.00] last_pfn = 0xde000 max_arch_pfn = 0x4
> [0.00] Using GB pages for direct mapping
> [

Re: [PATCH v2 4/4] drm/msm/dp: make dp_connector_mode_valid() more precise

[Kuogee Hsieh]

On 3/30/2022 3:30 PM, Dmitry Baryshkov wrote:

Make dp_connector_mode_valid() return precise MODE_CLOCK_HIGH rather
than generic MODE_BAD in case the mode clock is higher than
DP_MAX_PIXEL_CLK_KHZ (675 MHz).

Signed-off-by: Dmitry Baryshkov 
---


Reviewed-by: Kuogee Hsieh


  drivers/gpu/drm/msm/dp/dp_drm.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/dp/dp_drm.c b/drivers/gpu/drm/msm/dp/dp_drm.c
index a94c9b34f397..3225435fa81b 100644
--- a/drivers/gpu/drm/msm/dp/dp_drm.c
+++ b/drivers/gpu/drm/msm/dp/dp_drm.c
@@ -89,7 +89,7 @@ static enum drm_mode_status dp_connector_mode_valid(
dp_disp = to_dp_connector(connector)->dp_display;
  
  	if (mode->clock > DP_MAX_PIXEL_CLK_KHZ)

-   return MODE_BAD;
+   return MODE_CLOCK_HIGH;
  
  	return dp_display_validate_mode(dp_disp, mode->clock);

  }

Re: [PATCH 2/4] dt-bindings: display: ssd1307fb: Add entry for SINO WEALTH SH1106

[Javier Martinez Canillas]

On 4/4/22 18:11, Chen-Yu Tsai wrote:

[snip]

>>>
>>
>> tl; dr: unfortunately we can't do it due how SPI and I2C report module
>> aliases. Otherwise module auto loading will not work. I wrote a much
>> longer explanation with some details not so long ago:
>>
>> https://patchwork.kernel.org/project/dri-devel/patch/20220209091204.2513437-1-javi...@redhat.com/#24730793
> 
> Right. I think that crossed my mind at some point, but didn't stick.
> Thanks for raising it again. :)
> 
>> BTW, I bought a SSD1306 SPI controller and go it working this weekend.
>>
>> I plan to post the patches once yours land, to avoid in-flight series
>> that may conflict. And what I did is mark the -fb as deprecated, then
>> added "ssd130x-i2c" and "ssd130x-spi" compatibles strings.
>>
>> The WIP patches can be found here in case you are interested:
>>
>> https://github.com/martinezjavier/linux/tree/drm-ssd130x-spi
> 
> I took a quick look and a couple things stood out:
> 
> 1. Would 3-wire SPI ever be considered? If so, might want to
>rename some of variables/functions as *_spi_4wire_* to
>begin with.
>

That's a good question and something that I considered too. I have to
admit that never had a SPI device that uses the 3-wire scheme though
so I don't know how common that is.

The ssd1306 datasheet mentions that the chip supports it but I could
not find one to buy. Read that should be able to do it by soldering
some pads in the board but that wold be more hustle that would like.

For that reason I just went with only supporting 4-wire and someone
if really like could provide patches for 3-wire SPI.

> 2. Maybe we should move the ssd130x_deviceinfo stuff into the
>core module, and define an enum to use for matching compatible
>strings across the modules to their respective device info
>entries? FYI we are doing this in drivers/mfd/axp20x* .
> 

Yes, that's a good idea. I'll add that refactoring as a part of the
SPI series. Thanks a lot for the suggestion, it was very useful.

> I think a friend of mine has a SPI based SH1106 module that I
> could borrow and test/work on, but that's a big if.
> 
>

Cool. If it uses 4-wire too then I believe that would mostly work
out-of-the-box if you add a compatible string for it. I didn't
have to do any change in the core ssd103x driver for the ssd1306
SPI to work.

> Regards
> ChenYu
> 

-- 
Best regards,

Javier Martinez Canillas
Linux Engineering
Red Hat

Re: [PATCH 4/4] drm: ssd130x: Add support for SINO WEALTH SH1106

[Javier Martinez Canillas]

On 4/4/22 18:35, Chen-Yu Tsai wrote:
> On Fri, Apr 1, 2022 at 6:10 PM Javier Martinez Canillas
>  wrote:

[snip]

>>
>> I wonder if we should also list SH1106 in the
>> drivers/gpu/drm/solomon/Kconfig file so people can find it ?
> 
> I can add it to the help text if that helps?
>

No strong opinion really, it was an honest question.
 
> Recently someone mentioned that users are more likely to find drivers
> via compatible strings though. And I believe there's also a tool in-tree
> that finds all drivers given a device tree.
> 

Yeah I guess so. Looking at existing DTS and drivers' device tables is
certainly what I personally do when searching it a device is supported.

-- 
Best regards,

Javier Martinez Canillas
Linux Engineering
Red Hat

[linux-next:master] BUILD REGRESSION 696206280c5e5c028caf9fd259999cb72b1f6127

[kernel test robot]

tree/branch: 
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 696206280c5e5c028caf9fd25cb72b1f6127  Add linux-next specific 
files for 20220404

Error/Warning reports:

https://lore.kernel.org/linux-media/202203170501.ahquekof-...@intel.com
https://lore.kernel.org/linux-media/202203171537.svhye362-...@intel.com
https://lore.kernel.org/linux-media/202203171840.zxc3igpz-...@intel.com
https://lore.kernel.org/llvm/202203241958.uw9bwfmd-...@intel.com
https://lore.kernel.org/llvm/202204042148.v5rm3bkt-...@intel.com

Error/Warning: (recently discovered and may have been fixed)

/kbuild/src/includecheck/kernel/sched/sched.h: linux/static_key.h is included 
more than once.
ERROR: modpost: "__v4l2_async_nf_add_fwnode_remote" 
[drivers/media/platform/nxp/imx-mipi-csis.ko] undefined!
ERROR: modpost: "v4l2_async_nf_init" 
[drivers/media/platform/nxp/imx-mipi-csis.ko] undefined!
ERROR: modpost: "v4l2_async_register_subdev" 
[drivers/media/platform/nxp/imx-mipi-csis.ko] undefined!
ERROR: modpost: "v4l2_async_subdev_nf_register" 
[drivers/media/platform/nxp/imx-mipi-csis.ko] undefined!
ERROR: modpost: "v4l2_fwnode_endpoint_parse" 
[drivers/media/platform/nxp/imx-mipi-csis.ko] undefined!
ERROR: modpost: "v4l2_subdev_get_fwnode_pad_1_to_1" 
[drivers/media/platform/nxp/imx-mipi-csis.ko] undefined!
ERROR: modpost: "v4l2_subdev_init" 
[drivers/media/platform/nxp/imx-mipi-csis.ko] undefined!
ERROR: modpost: "v4l2_subdev_link_validate" 
[drivers/media/platform/nxp/imx-mipi-csis.ko] undefined!
drivers/bus/mhi/host/main.c:792:13: warning: parameter 'event_quota' set but 
not used [-Wunused-but-set-parameter]
imx-mipi-csis.c:(.text+0x1008): undefined reference to 
`v4l2_subdev_call_wrappers'
imx-mipi-csis.c:(.text+0x3c): undefined reference to 
`v4l2_create_fwnode_links_to_pad'
imx-mipi-csis.c:(.text+0x47c): undefined reference to `v4l_bound_align_image'
imx-mipi-csis.c:(.text+0x974): undefined reference to `v4l2_subdev_init'
imx-mipi-csis.c:(.text+0x984): undefined reference to `v4l2_async_nf_init'
imx-mipi-csis.c:(.text+0x9c8): undefined reference to `v4l2_async_nf_unregister'
include/asm-generic/io.h:464:31: warning: performing pointer arithmetic on a 
null pointer has undefined behavior err: false

Unverified Error/Warning (likely false positive, please contact us if 
interested):

ERROR: modpost: "v4l2_get_link_freq" 
[drivers/media/platform/nxp/imx-mipi-csis.ko] undefined!
ERROR: modpost: "v4l2_subdev_call_wrappers" 
[drivers/media/platform/nxp/imx-mipi-csis.ko] undefined!
arch/s390/include/asm/spinlock.h:81:3: error: unexpected token in '.rept' 
directive
arch/s390/include/asm/spinlock.h:81:3: error: unknown directive
arch/s390/include/asm/spinlock.h:81:3: error: unmatched '.endr' directive
arch/s390/lib/spinlock.c:78:3: error: unexpected token in '.rept' directive
arch/s390/lib/spinlock.c:78:3: error: unknown directive
arch/s390/lib/spinlock.c:78:3: error: unmatched '.endr' directive
arch/x86/kernel/cpu/mce/inject.c:355:6: warning: Call to function 'sprintf' is 
insecure as it does not provide bounding of the memory buffer or security 
checks introduced in the C11 standard. Replace with analogous functions that 
support length arguments or provides boundary checks such as 'sprintf_s' in 
case of C11 
[clang-analyzer-security.insecureAPI.DeprecatedOrUnsafeBufferHandling]
drivers/clk/imx/clk-pll14xx.c:166:2: warning: Value stored to 'pll_div_ctl1' is 
never read [clang-analyzer-deadcode.DeadStores]
drivers/counter/104-quad-8.c:150:9: sparse:unsigned char
drivers/counter/104-quad-8.c:150:9: sparse:void
drivers/counter/104-quad-8.c:150:9: sparse: sparse: incompatible types in 
conditional expression (different base types):
drivers/dma-buf/st-dma-fence-unwrap.c:125:13: warning: variable 'err' set but 
not used [-Wunused-but-set-variable]
drivers/dma-buf/st-dma-fence-unwrap.c:261:1: internal compiler error: 
Segmentation fault
drivers/firmware/turris-mox-rwtm.c:146:1: warning: Call to function 'sprintf' 
is insecure as it does not provide bounding of the memory buffer or security 
checks introduced in the C11 standard. Replace with analogous functions that 
support length arguments or provides boundary checks such as 'sprintf_s' in 
case of C11 
[clang-analyzer-security.insecureAPI.DeprecatedOrUnsafeBufferHandling]
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn31/dcn31_hubp.c:57:6: warning: no 
previous prototype for 'hubp31_program_extended_blank' [-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/calcs/dce_calcs.c:77:13: warning: 
stack frame size (5376) exceeds limit (1024) in 'calculate_bandwidth' 
[-Wframe-larger-than]
drivers/gpu/drm/drm_of.c:292:2-13: ERROR: probable double put.
drivers/gpu/drm/selftests/test-drm_buddy.c:523:7: warning: Value stored to 
'err' is never read [clang-analyzer-deadcode.DeadStores]
drivers/hid/hid-core.c:1665:30: warning: Althoug

Re: [PATCH 4/4] drm: ssd130x: Add support for SINO WEALTH SH1106

[Chen-Yu Tsai]

On Fri, Apr 1, 2022 at 6:10 PM Javier Martinez Canillas
 wrote:
>
> On Wed, Mar 30, 2022 at 9:09 PM Chen-Yu Tsai  wrote:
> >
> > From: Chen-Yu Tsai 
> >
> > The SINO WEALTH SH1106 is an OLED display driver that is somewhat
> > compatible with the SSD1306. It supports a slightly wider display,
> > at 132 instead of 128 pixels. The basic commands are the same, but
> > the SH1106 doesn't support the horizontal or vertical address modes.
> >
> > Add support for this display driver. The default values for some of
> > the hardware settings are taken from the datasheet.
> >
> > Signed-off-by: Chen-Yu Tsai 
> > ---
> >  drivers/gpu/drm/solomon/ssd130x-i2c.c | 11 +++
>
> Thanks a lot for this patch. It's very nice to see that another
> variant of the OLED controller is being supported!
>
> I wonder if we should also list SH1106 in the
> drivers/gpu/drm/solomon/Kconfig file so people can find it ?

I can add it to the help text if that helps?

Recently someone mentioned that users are more likely to find drivers
via compatible strings though. And I believe there's also a tool in-tree
that finds all drivers given a device tree.

> ah, one comment I forgot in 3/4 but that also applies to this patch, I
> believe the convention in DRM is for the subject line to be
> "drm/ssd130x:" instead of "drm: ssd130x:"

Ack.

> Reviewed-by: Javier Martinez Canillas 


Thanks
ChenYu

[PATCH v6 14/14] drm/msm/dsi: Add support for DSC configuration

[Vinod Koul]

When DSC is enabled, we need to configure DSI registers accordingly and
configure the respective stream compression registers.

Add support to calculate the register setting based on DSC params and
timing information and configure these registers.

Signed-off-by: Dmitry Baryshkov 
Signed-off-by: Vinod Koul 
---
 drivers/gpu/drm/msm/dsi/dsi_host.c | 98 +-
 1 file changed, 97 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index eb0be34add45..f3ed6c40b9e1 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -912,6 +912,65 @@ static void dsi_ctrl_config(struct msm_dsi_host *msm_host, 
bool enable,
dsi_write(msm_host, REG_DSI_CPHY_MODE_CTRL, BIT(0));
 }
 
+static void dsi_update_dsc_timing(struct msm_dsi_host *msm_host, bool 
is_cmd_mode, u32 hdisplay)
+{
+   struct msm_display_dsc_config *dsc = msm_host->dsc;
+   u32 reg, intf_width, reg_ctrl, reg_ctrl2;
+   u32 slice_per_intf, total_bytes_per_intf;
+   u32 pkt_per_line;
+   u32 bytes_in_slice;
+   u32 eol_byte_num;
+
+   /* first calculate dsc parameters and then program
+* compress mode registers
+*/
+   intf_width = hdisplay;
+   slice_per_intf = DIV_ROUND_UP(intf_width, dsc->drm->slice_width);
+
+   /* If slice_per_pkt is greater than slice_per_intf
+* then default to 1. This can happen during partial
+* update.
+*/
+   if (slice_per_intf > dsc->drm->slice_count)
+   dsc->drm->slice_count = 1;
+
+   slice_per_intf = DIV_ROUND_UP(hdisplay, dsc->drm->slice_width);
+   bytes_in_slice = DIV_ROUND_UP(dsc->drm->slice_width * 
dsc->drm->bits_per_pixel, 8);
+
+   dsc->drm->slice_chunk_size = bytes_in_slice;
+
+   total_bytes_per_intf = bytes_in_slice * slice_per_intf;
+
+   eol_byte_num = total_bytes_per_intf % 3;
+   pkt_per_line = slice_per_intf / dsc->drm->slice_count;
+
+   if (is_cmd_mode) /* packet data type */
+   reg = 
DSI_COMMAND_COMPRESSION_MODE_CTRL_STREAM0_DATATYPE(MIPI_DSI_DCS_LONG_WRITE);
+   else
+   reg = 
DSI_VIDEO_COMPRESSION_MODE_CTRL_DATATYPE(MIPI_DSI_COMPRESSED_PIXEL_STREAM);
+
+   /* DSI_VIDEO_COMPRESSION_MODE & DSI_COMMAND_COMPRESSION_MODE
+* registers have similar offsets, so for below common code use
+* DSI_VIDEO_COMPRESSION_MODE_ for setting bits
+*/
+   reg |= DSI_VIDEO_COMPRESSION_MODE_CTRL_PKT_PER_LINE(pkt_per_line >> 1);
+   reg |= DSI_VIDEO_COMPRESSION_MODE_CTRL_EOL_BYTE_NUM(eol_byte_num);
+   reg |= DSI_VIDEO_COMPRESSION_MODE_CTRL_EN;
+
+   if (is_cmd_mode) {
+   reg_ctrl = dsi_read(msm_host, 
REG_DSI_COMMAND_COMPRESSION_MODE_CTRL);
+   reg_ctrl2 = dsi_read(msm_host, 
REG_DSI_COMMAND_COMPRESSION_MODE_CTRL2);
+
+   reg_ctrl |= reg;
+   reg_ctrl2 |= 
DSI_COMMAND_COMPRESSION_MODE_CTRL2_STREAM0_SLICE_WIDTH(bytes_in_slice);
+
+   dsi_write(msm_host, REG_DSI_COMMAND_COMPRESSION_MODE_CTRL, reg);
+   dsi_write(msm_host, REG_DSI_COMMAND_COMPRESSION_MODE_CTRL2, 
reg_ctrl2);
+   } else {
+   dsi_write(msm_host, REG_DSI_VIDEO_COMPRESSION_MODE_CTRL, reg);
+   }
+}
+
 static void dsi_timing_setup(struct msm_dsi_host *msm_host, bool is_bonded_dsi)
 {
struct drm_display_mode *mode = msm_host->mode;
@@ -944,7 +1003,38 @@ static void dsi_timing_setup(struct msm_dsi_host 
*msm_host, bool is_bonded_dsi)
hdisplay /= 2;
}
 
+   if (msm_host->dsc) {
+   struct msm_display_dsc_config *dsc = msm_host->dsc;
+
+   /* update dsc params with timing params */
+   if (!dsc || !mode->hdisplay || !mode->vdisplay) {
+   pr_err("DSI: invalid input: pic_width: %d pic_height: 
%d\n",
+  mode->hdisplay, mode->vdisplay);
+   return;
+   }
+
+   dsc->drm->pic_width = mode->hdisplay;
+   dsc->drm->pic_height = mode->vdisplay;
+   DBG("Mode %dx%d\n", dsc->drm->pic_width, dsc->drm->pic_height);
+
+   /* we do the calculations for dsc parameters here so that
+* panel can use these parameters
+*/
+   dsi_populate_dsc_params(dsc);
+
+   /* Divide the display by 3 but keep back/font porch and
+* pulse width same
+*/
+   h_total -= hdisplay;
+   hdisplay /= 3;
+   h_total += hdisplay;
+   ha_end = ha_start + hdisplay;
+   }
+
if (msm_host->mode_flags & MIPI_DSI_MODE_VIDEO) {
+   if (msm_host->dsc)
+   dsi_update_dsc_timing(msm_host, false, mode->hdisplay);
+
dsi_write(msm_host, REG_DSI_ACTIVE_H,
DSI_ACTIVE_H_START(ha_start) |
 

[PATCH v6 13/14] drm/msm: Update generated headers

[Vinod Koul]

Update headers from mesa commit:

  commit 28ae397be111c37c6ced397e12d453a7695701bd
  Author: Vinod Koul 
  Date:   Fri Apr 1 16:53:04 2022 +0530

  freedreno/registers: update dsi registers to support dsc

  Display Stream compression (DSC) compresses the display stream in
  host which is later decoded by panel. This requires addition of 3 new
  DSI registers to support DSC over DSI.

  Signed-off-by: Vinod Koul 
  Part-of: 

Signed-off-by: Vinod Koul 
---
 drivers/gpu/drm/msm/dsi/dsi.xml.h | 80 +++
 1 file changed, 80 insertions(+)

diff --git a/drivers/gpu/drm/msm/dsi/dsi.xml.h 
b/drivers/gpu/drm/msm/dsi/dsi.xml.h
index 4dee6f0bdda6..d1b2a17b0a66 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.xml.h
+++ b/drivers/gpu/drm/msm/dsi/dsi.xml.h
@@ -704,5 +704,85 @@ static inline uint32_t DSI_VERSION_MAJOR(uint32_t val)
 
 #define REG_DSI_CPHY_MODE_CTRL 0x02d4
 
+#define REG_DSI_VIDEO_COMPRESSION_MODE_CTRL0x029c
+#define DSI_VIDEO_COMPRESSION_MODE_CTRL_WC__MASK   0x
+#define DSI_VIDEO_COMPRESSION_MODE_CTRL_WC__SHIFT  16
+static inline uint32_t DSI_VIDEO_COMPRESSION_MODE_CTRL_WC(uint32_t val)
+{
+   return ((val) << DSI_VIDEO_COMPRESSION_MODE_CTRL_WC__SHIFT) & 
DSI_VIDEO_COMPRESSION_MODE_CTRL_WC__MASK;
+}
+#define DSI_VIDEO_COMPRESSION_MODE_CTRL_DATATYPE__MASK 0x3f00
+#define DSI_VIDEO_COMPRESSION_MODE_CTRL_DATATYPE__SHIFT8
+static inline uint32_t DSI_VIDEO_COMPRESSION_MODE_CTRL_DATATYPE(uint32_t val)
+{
+   return ((val) << DSI_VIDEO_COMPRESSION_MODE_CTRL_DATATYPE__SHIFT) & 
DSI_VIDEO_COMPRESSION_MODE_CTRL_DATATYPE__MASK;
+}
+#define DSI_VIDEO_COMPRESSION_MODE_CTRL_PKT_PER_LINE__MASK 0x00c0
+#define DSI_VIDEO_COMPRESSION_MODE_CTRL_PKT_PER_LINE__SHIFT6
+static inline uint32_t DSI_VIDEO_COMPRESSION_MODE_CTRL_PKT_PER_LINE(uint32_t 
val)
+{
+   return ((val) << DSI_VIDEO_COMPRESSION_MODE_CTRL_PKT_PER_LINE__SHIFT) & 
DSI_VIDEO_COMPRESSION_MODE_CTRL_PKT_PER_LINE__MASK;
+}
+#define DSI_VIDEO_COMPRESSION_MODE_CTRL_EOL_BYTE_NUM__MASK 0x0030
+#define DSI_VIDEO_COMPRESSION_MODE_CTRL_EOL_BYTE_NUM__SHIFT4
+static inline uint32_t DSI_VIDEO_COMPRESSION_MODE_CTRL_EOL_BYTE_NUM(uint32_t 
val)
+{
+   return ((val) << DSI_VIDEO_COMPRESSION_MODE_CTRL_EOL_BYTE_NUM__SHIFT) & 
DSI_VIDEO_COMPRESSION_MODE_CTRL_EOL_BYTE_NUM__MASK;
+}
+#define DSI_VIDEO_COMPRESSION_MODE_CTRL_EN 0x0001
+
+#define REG_DSI_COMMAND_COMPRESSION_MODE_CTRL  0x02a4
+#define DSI_COMMAND_COMPRESSION_MODE_CTRL_STREAM1_DATATYPE__MASK   
0x3f00
+#define DSI_COMMAND_COMPRESSION_MODE_CTRL_STREAM1_DATATYPE__SHIFT  24
+static inline uint32_t 
DSI_COMMAND_COMPRESSION_MODE_CTRL_STREAM1_DATATYPE(uint32_t val)
+{
+   return ((val) << 
DSI_COMMAND_COMPRESSION_MODE_CTRL_STREAM1_DATATYPE__SHIFT) & 
DSI_COMMAND_COMPRESSION_MODE_CTRL_STREAM1_DATATYPE__MASK;
+}
+#define DSI_COMMAND_COMPRESSION_MODE_CTRL_STREAM1_PKT_PER_LINE__MASK   
0x00c0
+#define DSI_COMMAND_COMPRESSION_MODE_CTRL_STREAM1_PKT_PER_LINE__SHIFT  22
+static inline uint32_t 
DSI_COMMAND_COMPRESSION_MODE_CTRL_STREAM1_PKT_PER_LINE(uint32_t val)
+{
+   return ((val) << 
DSI_COMMAND_COMPRESSION_MODE_CTRL_STREAM1_PKT_PER_LINE__SHIFT) & 
DSI_COMMAND_COMPRESSION_MODE_CTRL_STREAM1_PKT_PER_LINE__MASK;
+}
+#define DSI_COMMAND_COMPRESSION_MODE_CTRL_STREAM1_EOL_BYTE_NUM__MASK   
0x0030
+#define DSI_COMMAND_COMPRESSION_MODE_CTRL_STREAM1_EOL_BYTE_NUM__SHIFT  20
+static inline uint32_t 
DSI_COMMAND_COMPRESSION_MODE_CTRL_STREAM1_EOL_BYTE_NUM(uint32_t val)
+{
+   return ((val) << 
DSI_COMMAND_COMPRESSION_MODE_CTRL_STREAM1_EOL_BYTE_NUM__SHIFT) & 
DSI_COMMAND_COMPRESSION_MODE_CTRL_STREAM1_EOL_BYTE_NUM__MASK;
+}
+#define DSI_COMMAND_COMPRESSION_MODE_CTRL_STREAM1_EN   0x0001
+#define DSI_COMMAND_COMPRESSION_MODE_CTRL_STREAM0_DATATYPE__MASK   
0x3f00
+#define DSI_COMMAND_COMPRESSION_MODE_CTRL_STREAM0_DATATYPE__SHIFT  8
+static inline uint32_t 
DSI_COMMAND_COMPRESSION_MODE_CTRL_STREAM0_DATATYPE(uint32_t val)
+{
+   return ((val) << 
DSI_COMMAND_COMPRESSION_MODE_CTRL_STREAM0_DATATYPE__SHIFT) & 
DSI_COMMAND_COMPRESSION_MODE_CTRL_STREAM0_DATATYPE__MASK;
+}
+#define DSI_COMMAND_COMPRESSION_MODE_CTRL_STREAM0_PKT_PER_LINE__MASK   
0x00c0
+#define DSI_COMMAND_COMPRESSION_MODE_CTRL_STREAM0_PKT_PER_LINE__SHIFT  6
+static inline uint32_t 
DSI_COMMAND_COMPRESSION_MODE_CTRL_STREAM0_PKT_PER_LINE(uint32_t val)
+{
+   return ((val) << 
DSI_COMMAND_COMPRESSION_MODE_CTRL_STREAM0_PKT_PER_LINE__SHIFT) & 
DSI_COMMAND_COMPRESSION_MODE_CTRL_STREAM0_PKT_PER_LINE__MASK;
+}
+#define DSI_COMMAND_COMPRESSION_MODE_CTRL_STREAM0_EOL_BYTE_NUM__MASK   
0x0030
+#define DSI_COMMAND_COMPRESSION_MODE_CTRL_STREAM0_EOL_BYTE_NUM__SHIFT  4
+static inline uint32_t 

[PATCH v6 12/14] drm/msm/dsi: add mode valid callback for dsi_mgr

[Vinod Koul]

Add a mode valid callback for dsi_mgr for checking mode being valid in
case of DSC. For DSC the height and width needs to be multiple of slice,
so we check that here

Reviewed-by: Dmitry Baryshkov 
Reviewed-by: Abhinav Kumar 
Signed-off-by: Vinod Koul 
---
 drivers/gpu/drm/msm/dsi/dsi.h |  2 ++
 drivers/gpu/drm/msm/dsi/dsi_host.c| 26 ++
 drivers/gpu/drm/msm/dsi/dsi_manager.c | 12 
 3 files changed, 40 insertions(+)

diff --git a/drivers/gpu/drm/msm/dsi/dsi.h b/drivers/gpu/drm/msm/dsi/dsi.h
index 16cd9b2fce86..580a1e6358bf 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.h
+++ b/drivers/gpu/drm/msm/dsi/dsi.h
@@ -114,6 +114,8 @@ int msm_dsi_host_power_on(struct mipi_dsi_host *host,
 int msm_dsi_host_power_off(struct mipi_dsi_host *host);
 int msm_dsi_host_set_display_mode(struct mipi_dsi_host *host,
  const struct drm_display_mode *mode);
+enum drm_mode_status msm_dsi_host_check_dsc(struct mipi_dsi_host *host,
+   const struct drm_display_mode 
*mode);
 struct drm_panel *msm_dsi_host_get_panel(struct mipi_dsi_host *host);
 unsigned long msm_dsi_host_get_mode_flags(struct mipi_dsi_host *host);
 struct drm_bridge *msm_dsi_host_get_bridge(struct mipi_dsi_host *host);
diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index cb2e179127ea..eb0be34add45 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -2554,6 +2554,32 @@ int msm_dsi_host_set_display_mode(struct mipi_dsi_host 
*host,
return 0;
 }
 
+enum drm_mode_status msm_dsi_host_check_dsc(struct mipi_dsi_host *host,
+   const struct drm_display_mode *mode)
+{
+   struct msm_dsi_host *msm_host = to_msm_dsi_host(host);
+   struct msm_display_dsc_config *dsc = msm_host->dsc;
+   int pic_width = mode->hdisplay;
+   int pic_height = mode->vdisplay;
+
+   if (!msm_host->dsc)
+   return MODE_OK;
+
+   if (pic_width % dsc->drm->slice_width) {
+   pr_err("DSI: pic_width %d has to be multiple of slice %d\n",
+  pic_width, dsc->drm->slice_width);
+   return MODE_H_ILLEGAL;
+   }
+
+   if (pic_height % dsc->drm->slice_height) {
+   pr_err("DSI: pic_height %d has to be multiple of slice %d\n",
+  pic_height, dsc->drm->slice_height);
+   return MODE_V_ILLEGAL;
+   }
+
+   return MODE_OK;
+}
+
 struct drm_panel *msm_dsi_host_get_panel(struct mipi_dsi_host *host)
 {
return of_drm_find_panel(to_msm_dsi_host(host)->device_node);
diff --git a/drivers/gpu/drm/msm/dsi/dsi_manager.c 
b/drivers/gpu/drm/msm/dsi/dsi_manager.c
index 0c1b7dde377c..100a8fcbddee 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_manager.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_manager.c
@@ -573,6 +573,17 @@ static void dsi_mgr_bridge_mode_set(struct drm_bridge 
*bridge,
dsi_mgr_bridge_power_on(bridge);
 }
 
+static enum drm_mode_status dsi_mgr_bridge_mode_valid(struct drm_bridge 
*bridge,
+ const struct 
drm_display_info *info,
+ const struct 
drm_display_mode *mode)
+{
+   int id = dsi_mgr_bridge_get_id(bridge);
+   struct msm_dsi *msm_dsi = dsi_mgr_get_dsi(id);
+   struct mipi_dsi_host *host = msm_dsi->host;
+
+   return msm_dsi_host_check_dsc(host, mode);
+}
+
 static const struct drm_connector_funcs dsi_mgr_connector_funcs = {
.detect = dsi_mgr_connector_detect,
.fill_modes = drm_helper_probe_single_connector_modes,
@@ -593,6 +604,7 @@ static const struct drm_bridge_funcs dsi_mgr_bridge_funcs = 
{
.disable = dsi_mgr_bridge_disable,
.post_disable = dsi_mgr_bridge_post_disable,
.mode_set = dsi_mgr_bridge_mode_set,
+   .mode_valid = dsi_mgr_bridge_mode_valid,
 };
 
 /* initialize connector when we're connected to a drm_panel */
-- 
2.34.1

[PATCH v6 11/14] drm/msm/disp/dpu1: Add DSC support in RM

[Vinod Koul]

This add the bits in RM to enable the DSC blocks

Reviewed-by: Dmitry Baryshkov 
Reviewed-by: Abhinav Kumar 
Signed-off-by: Vinod Koul 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h |  1 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c  | 56 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h  |  1 +
 3 files changed, 58 insertions(+)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
index 779e7bd01efd..a41f0eb2761b 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
@@ -145,6 +145,7 @@ struct dpu_global_state {
uint32_t mixer_to_enc_id[LM_MAX - LM_0];
uint32_t ctl_to_enc_id[CTL_MAX - CTL_0];
uint32_t dspp_to_enc_id[DSPP_MAX - DSPP_0];
+   uint32_t dsc_to_enc_id[DSC_MAX - DSC_0];
 };
 
 struct dpu_global_state
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
index 7497538adae1..0e6634b217aa 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
@@ -11,6 +11,7 @@
 #include "dpu_hw_intf.h"
 #include "dpu_hw_dspp.h"
 #include "dpu_hw_merge3d.h"
+#include "dpu_hw_dsc.h"
 #include "dpu_encoder.h"
 #include "dpu_trace.h"
 
@@ -77,6 +78,15 @@ int dpu_rm_destroy(struct dpu_rm *rm)
for (i = 0; i < ARRAY_SIZE(rm->hw_intf); i++)
dpu_hw_intf_destroy(rm->hw_intf[i]);
 
+   for (i = 0; i < ARRAY_SIZE(rm->dsc_blks); i++) {
+   struct dpu_hw_dsc *hw;
+
+   if (rm->dsc_blks[i]) {
+   hw = to_dpu_hw_dsc(rm->dsc_blks[i]);
+   dpu_hw_dsc_destroy(hw);
+   }
+   }
+
return 0;
 }
 
@@ -210,6 +220,19 @@ int dpu_rm_init(struct dpu_rm *rm,
rm->dspp_blks[dspp->id - DSPP_0] = >base;
}
 
+   for (i = 0; i < cat->dsc_count; i++) {
+   struct dpu_hw_dsc *hw;
+   const struct dpu_dsc_cfg *dsc = >dsc[i];
+
+   hw = dpu_hw_dsc_init(dsc->id, mmio, cat);
+   if (IS_ERR_OR_NULL(hw)) {
+   rc = PTR_ERR(hw);
+   DPU_ERROR("failed dsc object creation: err %d\n", rc);
+   goto fail;
+   }
+   rm->dsc_blks[dsc->id - DSC_0] = >base;
+   }
+
return 0;
 
 fail:
@@ -441,6 +464,28 @@ static int _dpu_rm_reserve_ctls(
return 0;
 }
 
+static int _dpu_rm_reserve_dsc(struct dpu_rm *rm,
+  struct dpu_global_state *global_state,
+  struct drm_encoder *enc,
+  const struct msm_display_topology *top)
+{
+   int num_dsc = top->num_dsc;
+   int i;
+
+   /* check if DSC required are allocated or not */
+   for (i = 0; i < num_dsc; i++) {
+   if (global_state->dsc_to_enc_id[i]) {
+   DPU_ERROR("DSC %d is already allocated\n", i);
+   return -EIO;
+   }
+   }
+
+   for (i = 0; i < num_dsc; i++)
+   global_state->dsc_to_enc_id[i] = enc->base.id;
+
+   return 0;
+}
+
 static int _dpu_rm_make_reservation(
struct dpu_rm *rm,
struct dpu_global_state *global_state,
@@ -462,6 +507,10 @@ static int _dpu_rm_make_reservation(
return ret;
}
 
+   ret  = _dpu_rm_reserve_dsc(rm, global_state, enc, >topology);
+   if (ret)
+   return ret;
+
return ret;
 }
 
@@ -499,6 +548,8 @@ void dpu_rm_release(struct dpu_global_state *global_state,
ARRAY_SIZE(global_state->mixer_to_enc_id), enc->base.id);
_dpu_rm_clear_mapping(global_state->ctl_to_enc_id,
ARRAY_SIZE(global_state->ctl_to_enc_id), enc->base.id);
+   _dpu_rm_clear_mapping(global_state->dsc_to_enc_id,
+   ARRAY_SIZE(global_state->dsc_to_enc_id), enc->base.id);
 }
 
 int dpu_rm_reserve(
@@ -567,6 +618,11 @@ int dpu_rm_get_assigned_resources(struct dpu_rm *rm,
hw_to_enc_id = global_state->dspp_to_enc_id;
max_blks = ARRAY_SIZE(rm->dspp_blks);
break;
+   case DPU_HW_BLK_DSC:
+   hw_blks = rm->dsc_blks;
+   hw_to_enc_id = global_state->dsc_to_enc_id;
+   max_blks = ARRAY_SIZE(rm->dsc_blks);
+   break;
default:
DPU_ERROR("blk type %d not managed by rm\n", type);
return 0;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h
index 9b13200a050a..32e0d8aa65ab 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h
@@ -28,6 +28,7 @@ struct dpu_rm {
struct dpu_hw_intf *hw_intf[INTF_MAX - INTF_0];
struct dpu_hw_blk *dspp_blks[DSPP_MAX - DSPP_0];
struct dpu_hw_blk *merge_3d_blks[MERGE_3D_MAX - MERGE_3D_0];
+   struct dpu_hw_blk *dsc_blks[DSC_MAX - DSC_0];
 };
 
 /**
-- 

[PATCH v6 10/14] drm/msm/disp/dpu1: Add support for DSC in topology

[Vinod Koul]

For DSC to work we typically need a 2,2,1 configuration. This should
suffice for resolutions up to 4k. For more resolutions like 8k this won't
work.

Also, it is better to use 2 LMs and DSC instances as half width results
in lesser power consumption as compared to single LM, DSC at full width.

The panel has been tested only with 2,2,1 configuration, so for
now we blindly create 2,2,1 topology when DSC is enabled

Co-developed-by: Abhinav Kumar 
Signed-off-by: Abhinav Kumar 
Reviewed-by: Dmitry Baryshkov 
Signed-off-by: Vinod Koul 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 13 +
 drivers/gpu/drm/msm/msm_drv.h   |  2 ++
 2 files changed, 15 insertions(+)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 95d1588f3bb6..51f24ba68375 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -567,8 +567,21 @@ static struct msm_display_topology 
dpu_encoder_get_topology(
topology.num_enc = 0;
topology.num_intf = intf_count;
 
+   if (dpu_enc->dsc) {
+   /* In case of Display Stream Compression (DSC), we would use
+* 2 encoders, 2 layer mixers and 1 interface
+* this is power optimal and can drive up to (including) 4k
+* screens
+*/
+   topology.num_enc = 2;
+   topology.num_dsc = 2;
+   topology.num_intf = 1;
+   topology.num_lm = 2;
+   }
+
return topology;
 }
+
 static int dpu_encoder_virt_atomic_check(
struct drm_encoder *drm_enc,
struct drm_crtc_state *crtc_state,
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index bf2ccff97562..0ace9b0549a4 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -103,12 +103,14 @@ enum msm_event_wait {
  * @num_enc:  number of compression encoder blocks used
  * @num_intf: number of interfaces the panel is mounted on
  * @num_dspp: number of dspp blocks used
+ * @num_dsc:  number of Display Stream Compression (DSC) blocks used
  */
 struct msm_display_topology {
u32 num_lm;
u32 num_enc;
u32 num_intf;
u32 num_dspp;
+   u32 num_dsc;
 };
 
 /* Commit/Event thread specific structure */
-- 
2.34.1

[PATCH v6 09/14] drm/msm: Add missing num_dspp field documentation

[Vinod Koul]

Somehow documentation for num_dspp was missed, so add that

Reviewed-by: Dmitry Baryshkov 
Reviewed-by: Abhinav Kumar 
Signed-off-by: Vinod Koul 
---
 drivers/gpu/drm/msm/msm_drv.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index 2a3280df7b12..bf2ccff97562 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -102,6 +102,7 @@ enum msm_event_wait {
  * @num_lm:   number of layer mixers used
  * @num_enc:  number of compression encoder blocks used
  * @num_intf: number of interfaces the panel is mounted on
+ * @num_dspp: number of dspp blocks used
  */
 struct msm_display_topology {
u32 num_lm;
-- 
2.34.1

[PATCH v6 08/14] drm/msm/dpu: don't use merge_3d if DSC merge topology is used

[Vinod Koul]

From: Dmitry Baryshkov 

DPU supports different topologies for the case when multiple INTFs are
being driven by the single phys_enc. The driver defaults to using 3DMux
in such cases. Don't use it if DSC merge is used instead.

Suggested-by: Abhinav Kumar 
Signed-off-by: Dmitry Baryshkov 
Signed-off-by: Vinod Koul 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c  | 16 
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h  |  6 ++
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h |  4 +++-
 3 files changed, 25 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 4052486f19d8..95d1588f3bb6 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -511,6 +511,22 @@ void dpu_encoder_helper_split_config(
}
 }
 
+bool dpu_encoder_use_dsc_merge(struct drm_encoder *drm_enc)
+{
+   struct dpu_encoder_virt *dpu_enc = to_dpu_encoder_virt(drm_enc);
+   int i, intf_count = 0, num_dsc = 0;
+
+   for (i = 0; i < MAX_PHYS_ENCODERS_PER_VIRTUAL; i++)
+   if (dpu_enc->phys_encs[i])
+   intf_count++;
+
+   /* See dpu_encoder_get_topology, we only support 2:2:1 topology */
+   if (dpu_enc->dsc)
+   num_dsc = 2;
+
+   return (num_dsc > 0) && (num_dsc > intf_count);
+}
+
 static struct msm_display_topology dpu_encoder_get_topology(
struct dpu_encoder_virt *dpu_enc,
struct dpu_kms *dpu_kms,
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
index ef873e5285a0..084c5265d7e5 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
@@ -172,4 +172,10 @@ int dpu_encoder_get_linecount(struct drm_encoder *drm_enc);
  */
 int dpu_encoder_get_vsync_count(struct drm_encoder *drm_enc);
 
+/**
+ * dpu_encoder_use_dsc_merge - returns true if the encoder uses DSC merge 
topology.
+ * @drm_enc:Pointer to previously created drm encoder structure
+ */
+bool dpu_encoder_use_dsc_merge(struct drm_encoder *drm_enc);
+
 #endif /* __DPU_ENCODER_H__ */
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
index 4842070fdfa8..b5ad43b8a19b 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
@@ -314,8 +314,10 @@ static inline enum dpu_3d_blend_mode 
dpu_encoder_helper_get_3d_blend_mode(
 
dpu_cstate = to_dpu_crtc_state(phys_enc->parent->crtc->state);
 
+   /* Use merge_3d unless DSC MERGE topology is used */
if (phys_enc->split_role == ENC_ROLE_SOLO &&
-   dpu_cstate->num_mixers == CRTC_DUAL_MIXERS)
+   dpu_cstate->num_mixers == CRTC_DUAL_MIXERS &&
+   !dpu_encoder_use_dsc_merge(phys_enc->parent))
return BLEND_3D_H_ROW_INT;
 
return BLEND_3D_NONE;
-- 
2.34.1

[PATCH v6 07/14] drm/msm/disp/dpu1: Add support for DSC in encoder

[Vinod Koul]

We need to configure the encoder for DSC configuration and calculate DSC
parameters for the given timing so this patch adds that support by
adding dpu_encoder_prep_dsc() which is invoked when DSC is enabled.

Reviewed-by: Dmitry Baryshkov 
Reviewed-by: Abhinav Kumar 
Signed-off-by: Vinod Koul 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c   | 128 +-
 .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h  |   8 ++
 2 files changed, 135 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 3940b9c6323b..4052486f19d8 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -21,6 +21,7 @@
 #include "dpu_hw_intf.h"
 #include "dpu_hw_ctl.h"
 #include "dpu_hw_dspp.h"
+#include "dpu_hw_dsc.h"
 #include "dpu_formats.h"
 #include "dpu_encoder_phys.h"
 #include "dpu_crtc.h"
@@ -135,6 +136,8 @@ enum dpu_enc_rc_states {
  * @cur_slave: As above but for the slave encoder.
  * @hw_pp: Handle to the pingpong blocks used for the display. No.
  * pingpong blocks can be different than num_phys_encs.
+ * @hw_dsc:Handle to the DSC blocks used for the display.
+ * @dsc_mask:  Bitmask of used DSC blocks.
  * @intfs_swapped: Whether or not the phys_enc interfaces have been swapped
  * for partial update right-only cases, such as pingpong
  * split where virtual pingpong does not generate IRQs
@@ -168,6 +171,7 @@ enum dpu_enc_rc_states {
  * @vsync_event_work:  worker to handle vsync event for autorefresh
  * @topology:   topology of the display
  * @idle_timeout:  idle timeout duration in milliseconds
+ * @dsc:   msm_display_dsc_config pointer, for DSC-enabled 
encoders
  */
 struct dpu_encoder_virt {
struct drm_encoder base;
@@ -180,6 +184,9 @@ struct dpu_encoder_virt {
struct dpu_encoder_phys *cur_master;
struct dpu_encoder_phys *cur_slave;
struct dpu_hw_pingpong *hw_pp[MAX_CHANNELS_PER_ENC];
+   struct dpu_hw_dsc *hw_dsc[MAX_CHANNELS_PER_ENC];
+
+   unsigned int dsc_mask;
 
bool intfs_swapped;
 
@@ -206,6 +213,9 @@ struct dpu_encoder_virt {
struct msm_display_topology topology;
 
u32 idle_timeout;
+
+   /* DSC configuration */
+   struct msm_display_dsc_config *dsc;
 };
 
 #define to_dpu_encoder_virt(x) container_of(x, struct dpu_encoder_virt, base)
@@ -942,7 +952,9 @@ static void dpu_encoder_virt_atomic_mode_set(struct 
drm_encoder *drm_enc,
struct dpu_hw_blk *hw_ctl[MAX_CHANNELS_PER_ENC];
struct dpu_hw_blk *hw_lm[MAX_CHANNELS_PER_ENC];
struct dpu_hw_blk *hw_dspp[MAX_CHANNELS_PER_ENC] = { NULL };
-   int num_lm, num_ctl, num_pp;
+   struct dpu_hw_blk *hw_dsc[MAX_CHANNELS_PER_ENC];
+   int num_lm, num_ctl, num_pp, num_dsc;
+   unsigned int dsc_mask = 0;
int i;
 
if (!drm_enc) {
@@ -980,6 +992,18 @@ static void dpu_encoder_virt_atomic_mode_set(struct 
drm_encoder *drm_enc,
dpu_enc->hw_pp[i] = i < num_pp ? to_dpu_hw_pingpong(hw_pp[i])
: NULL;
 
+   if (dpu_enc->dsc) {
+   num_dsc = dpu_rm_get_assigned_resources(_kms->rm, 
global_state,
+   drm_enc->base.id, 
DPU_HW_BLK_DSC,
+   hw_dsc, 
ARRAY_SIZE(hw_dsc));
+   for (i = 0; i < num_dsc; i++) {
+   dpu_enc->hw_dsc[i] = to_dpu_hw_dsc(hw_dsc[i]);
+   dsc_mask |= BIT(dpu_enc->hw_dsc[i]->idx - DSC_0);
+   }
+   }
+
+   dpu_enc->dsc_mask = dsc_mask;
+
cstate = to_dpu_crtc_state(crtc_state);
 
for (i = 0; i < num_lm; i++) {
@@ -1677,6 +1701,95 @@ static void dpu_encoder_vsync_event_work_handler(struct 
kthread_work *work)
nsecs_to_jiffies(ktime_to_ns(wakeup_time)));
 }
 
+static u32
+dpu_encoder_dsc_initial_line_calc(struct msm_display_dsc_config *dsc,
+ u32 enc_ip_width)
+{
+   int ssm_delay, total_pixels, soft_slice_per_enc;
+
+   soft_slice_per_enc = enc_ip_width / dsc->drm->slice_width;
+
+   /*
+* minimum number of initial line pixels is a sum of:
+* 1. sub-stream multiplexer delay (83 groups for 8bpc,
+*91 for 10 bpc) * 3
+* 2. for two soft slice cases, add extra sub-stream multiplexer * 3
+* 3. the initial xmit delay
+* 4. total pipeline delay through the "lock step" of encoder (47)
+* 5. 6 additional pixels as the output of the rate buffer is
+*48 bits wide
+*/
+   ssm_delay = ((dsc->drm->bits_per_component < 10) ? 84 : 92);
+   total_pixels = ssm_delay * 3 + dsc->drm->initial_xmit_delay + 47;
+   if (soft_slice_per_enc > 1)

[PATCH v6 06/14] drm/msm/disp/dpu1: Add DSC support in hw_ctl

[Vinod Koul]

Later gens of hardware have DSC bits moved to hw_ctl, so configure these
bits so that DSC would work there as well

Reviewed-by: Dmitry Baryshkov 
Reviewed-by: Abhinav Kumar 
Signed-off-by: Vinod Koul 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 11 ++-
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h |  2 ++
 2 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
index 3584f5ee6bb3..dc27579bb5f6 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
@@ -25,6 +25,8 @@
 #define   CTL_MERGE_3D_ACTIVE   0x0E4
 #define   CTL_INTF_ACTIVE   0x0F4
 #define   CTL_MERGE_3D_FLUSH0x100
+#define   CTL_DSC_ACTIVE0x0E8
+#define   CTL_DSC_FLUSH0x104
 #define   CTL_INTF_FLUSH0x110
 #define   CTL_INTF_MASTER   0x134
 #define   CTL_FETCH_PIPE_ACTIVE 0x0FC
@@ -34,6 +36,7 @@
 
 #define DPU_REG_RESET_TIMEOUT_US2000
 #define  MERGE_3D_IDX   23
+#define  DSC_IDX22
 #define  INTF_IDX   31
 #define CTL_INVALID_BIT 0x
 #define CTL_DEFAULT_GROUP_ID   0xf
@@ -126,7 +129,6 @@ static u32 dpu_hw_ctl_get_pending_flush(struct dpu_hw_ctl 
*ctx)
 
 static inline void dpu_hw_ctl_trigger_flush_v1(struct dpu_hw_ctl *ctx)
 {
-
if (ctx->pending_flush_mask & BIT(MERGE_3D_IDX))
DPU_REG_WRITE(>hw, CTL_MERGE_3D_FLUSH,
ctx->pending_merge_3d_flush_mask);
@@ -511,6 +513,9 @@ static void dpu_hw_ctl_intf_cfg_v1(struct dpu_hw_ctl *ctx,
if ((test_bit(DPU_CTL_VM_CFG, >caps->features)))
mode_sel = CTL_DEFAULT_GROUP_ID  << 28;
 
+   if (cfg->dsc)
+   DPU_REG_WRITE(>hw, CTL_DSC_FLUSH, cfg->dsc);
+
if (cfg->intf_mode_sel == DPU_CTL_MODE_SEL_CMD)
mode_sel |= BIT(17);
 
@@ -522,6 +527,10 @@ static void dpu_hw_ctl_intf_cfg_v1(struct dpu_hw_ctl *ctx,
if (cfg->merge_3d)
DPU_REG_WRITE(c, CTL_MERGE_3D_ACTIVE,
  BIT(cfg->merge_3d - MERGE_3D_0));
+   if (cfg->dsc) {
+   DPU_REG_WRITE(>hw, CTL_FLUSH, DSC_IDX);
+   DPU_REG_WRITE(c, CTL_DSC_ACTIVE, cfg->dsc);
+   }
 }
 
 static void dpu_hw_ctl_intf_cfg(struct dpu_hw_ctl *ctx,
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h
index ac1544474022..97f326dff0af 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h
@@ -40,6 +40,7 @@ struct dpu_hw_stage_cfg {
  * @merge_3d:  3d merge block used
  * @intf_mode_sel: Interface mode, cmd / vid
  * @stream_sel:Stream selection for multi-stream interfaces
+ * @dsc:   DSC BIT masks used
  */
 struct dpu_hw_intf_cfg {
enum dpu_intf intf;
@@ -47,6 +48,7 @@ struct dpu_hw_intf_cfg {
enum dpu_merge_3d merge_3d;
enum dpu_ctl_mode_sel intf_mode_sel;
int stream_sel;
+   unsigned int dsc;
 };
 
 /**
-- 
2.34.1

[PATCH v6 05/14] drm/msm/disp/dpu1: Add DSC for SDM845 to hw_catalog

[Vinod Koul]

This adds SDM845 DSC blocks into hw_catalog

Reviewed-by: Dmitry Baryshkov 
Reviewed-by: Abhinav Kumar 
Signed-off-by: Vinod Koul 
---
 .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 20 +++
 1 file changed, 20 insertions(+)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index a4fe77cddfea..d15fa5845066 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -1117,6 +1117,24 @@ static const struct dpu_pingpong_cfg sc7280_pp[] = {
PP_BLK("pingpong_2", PINGPONG_2, 0x6b000, 0, sc7280_pp_sblk, -1, -1),
PP_BLK("pingpong_3", PINGPONG_3, 0x6c000, 0, sc7280_pp_sblk, -1, -1),
 };
+
+/*
+ * DSC sub blocks config
+ */
+#define DSC_BLK(_name, _id, _base) \
+   {\
+   .name = _name, .id = _id, \
+   .base = _base, .len = 0x140, \
+   .features = 0, \
+   }
+
+static struct dpu_dsc_cfg sdm845_dsc[] = {
+   DSC_BLK("dsc_0", DSC_0, 0x8),
+   DSC_BLK("dsc_1", DSC_1, 0x80400),
+   DSC_BLK("dsc_2", DSC_2, 0x80800),
+   DSC_BLK("dsc_3", DSC_3, 0x80c00),
+};
+
 /*
  * INTF sub blocks config
  */
@@ -1643,6 +1661,8 @@ static void sdm845_cfg_init(struct dpu_mdss_cfg *dpu_cfg)
.mixer = sdm845_lm,
.pingpong_count = ARRAY_SIZE(sdm845_pp),
.pingpong = sdm845_pp,
+   .dsc_count = ARRAY_SIZE(sdm845_dsc),
+   .dsc = sdm845_dsc,
.intf_count = ARRAY_SIZE(sdm845_intf),
.intf = sdm845_intf,
.vbif_count = ARRAY_SIZE(sdm845_vbif),
-- 
2.34.1

[PATCH v6 04/14] drm/msm/disp/dpu1: Add support for DSC in pingpong block

[Vinod Koul]

In SDM845, DSC can be enabled by writing to pingpong block registers, so
add support for DSC in hw_pp

Reviewed-by: Abhinav Kumar 
Reviewed-by: Dmitry Baryshkov 
Signed-off-by: Vinod Koul 
---
 .../gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c   | 32 +++
 .../gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h   | 14 
 2 files changed, 46 insertions(+)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
index 55766c97c4c8..47c6ab6caf95 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
@@ -28,6 +28,9 @@
 #define PP_FBC_MODE 0x034
 #define PP_FBC_BUDGET_CTL   0x038
 #define PP_FBC_LOSSY_MODE   0x03C
+#define PP_DSC_MODE 0x0a0
+#define PP_DCE_DATA_IN_SWAP 0x0ac
+#define PP_DCE_DATA_OUT_SWAP0x0c8
 
 #define PP_DITHER_EN   0x000
 #define PP_DITHER_BITDEPTH 0x004
@@ -245,6 +248,32 @@ static u32 dpu_hw_pp_get_line_count(struct dpu_hw_pingpong 
*pp)
return line;
 }
 
+static int dpu_hw_pp_dsc_enable(struct dpu_hw_pingpong *pp)
+{
+   struct dpu_hw_blk_reg_map *c = >hw;
+
+   DPU_REG_WRITE(c, PP_DSC_MODE, 1);
+   return 0;
+}
+
+static void dpu_hw_pp_dsc_disable(struct dpu_hw_pingpong *pp)
+{
+   struct dpu_hw_blk_reg_map *c = >hw;
+
+   DPU_REG_WRITE(c, PP_DSC_MODE, 0);
+}
+
+static int dpu_hw_pp_setup_dsc(struct dpu_hw_pingpong *pp)
+{
+   struct dpu_hw_blk_reg_map *pp_c = >hw;
+   int data;
+
+   data = DPU_REG_READ(pp_c, PP_DCE_DATA_OUT_SWAP);
+   data |= BIT(18); /* endian flip */
+   DPU_REG_WRITE(pp_c, PP_DCE_DATA_OUT_SWAP, data);
+   return 0;
+}
+
 static void _setup_pingpong_ops(struct dpu_hw_pingpong *c,
unsigned long features)
 {
@@ -256,6 +285,9 @@ static void _setup_pingpong_ops(struct dpu_hw_pingpong *c,
c->ops.get_autorefresh = dpu_hw_pp_get_autorefresh_config;
c->ops.poll_timeout_wr_ptr = dpu_hw_pp_poll_timeout_wr_ptr;
c->ops.get_line_count = dpu_hw_pp_get_line_count;
+   c->ops.setup_dsc = dpu_hw_pp_setup_dsc;
+   c->ops.enable_dsc = dpu_hw_pp_dsc_enable;
+   c->ops.disable_dsc = dpu_hw_pp_dsc_disable;
 
if (test_bit(DPU_PINGPONG_DITHER, ))
c->ops.setup_dither = dpu_hw_pp_setup_dither;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h
index 89d08a715c16..12758468d9ca 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h
@@ -124,6 +124,20 @@ struct dpu_hw_pingpong_ops {
 */
void (*setup_dither)(struct dpu_hw_pingpong *pp,
struct dpu_hw_dither_cfg *cfg);
+   /**
+* Enable DSC
+*/
+   int (*enable_dsc)(struct dpu_hw_pingpong *pp);
+
+   /**
+* Disable DSC
+*/
+   void (*disable_dsc)(struct dpu_hw_pingpong *pp);
+
+   /**
+* Setup DSC
+*/
+   int (*setup_dsc)(struct dpu_hw_pingpong *pp);
 };
 
 struct dpu_hw_merge_3d;
-- 
2.34.1

[PATCH v6 03/14] drm/msm/disp/dpu1: Add support for DSC

[Vinod Koul]

Display Stream Compression (DSC) is one of the hw blocks in dpu, so add
support by adding hw blocks for DSC

Reviewed-by: Dmitry Baryshkov 
Signed-off-by: Vinod Koul 
---
 drivers/gpu/drm/msm/Makefile  |   1 +
 .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h|  13 ++
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c| 215 ++
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.h|  80 +++
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h   |  13 ++
 5 files changed, 322 insertions(+)
 create mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
 create mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.h

diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index e9cc7d8ac301..f551ecc0fefa 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -56,6 +56,7 @@ msm-y := \
disp/dpu1/dpu_formats.o \
disp/dpu1/dpu_hw_catalog.o \
disp/dpu1/dpu_hw_ctl.o \
+   disp/dpu1/dpu_hw_dsc.o \
disp/dpu1/dpu_hw_interrupts.o \
disp/dpu1/dpu_hw_intf.o \
disp/dpu1/dpu_hw_lm.o \
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 b85b24bd3f53..f05c4cdcb7f9 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
@@ -561,6 +561,16 @@ struct dpu_merge_3d_cfg  {
const struct dpu_merge_3d_sub_blks *sblk;
 };
 
+/**
+ * struct dpu_dsc_cfg - information of DSC blocks
+ * @id enum identifying this block
+ * @base   register offset of this block
+ * @features   bit mask identifying sub-blocks/features
+ */
+struct dpu_dsc_cfg {
+   DPU_HW_BLK_INFO;
+};
+
 /**
  * struct dpu_intf_cfg - information of timing engine blocks
  * @id enum identifying this block
@@ -757,6 +767,9 @@ struct dpu_mdss_cfg {
u32 merge_3d_count;
const struct dpu_merge_3d_cfg *merge_3d;
 
+   u32 dsc_count;
+   struct dpu_dsc_cfg *dsc;
+
u32 intf_count;
const struct dpu_intf_cfg *intf;
 
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
new file mode 100644
index ..426224e34900
--- /dev/null
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
@@ -0,0 +1,215 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2020-2022, Linaro Limited
+ */
+
+#include "dpu_kms.h"
+#include "dpu_hw_catalog.h"
+#include "dpu_hwio.h"
+#include "dpu_hw_mdss.h"
+#include "dpu_hw_dsc.h"
+
+#define DSC_COMMON_MODE0x000
+#define DSC_ENC 0X004
+#define DSC_PICTURE 0x008
+#define DSC_SLICE   0x00C
+#define DSC_CHUNK_SIZE  0x010
+#define DSC_DELAY   0x014
+#define DSC_SCALE_INITIAL   0x018
+#define DSC_SCALE_DEC_INTERVAL  0x01C
+#define DSC_SCALE_INC_INTERVAL  0x020
+#define DSC_FIRST_LINE_BPG_OFFSET   0x024
+#define DSC_BPG_OFFSET  0x028
+#define DSC_DSC_OFFSET  0x02C
+#define DSC_FLATNESS0x030
+#define DSC_RC_MODEL_SIZE   0x034
+#define DSC_RC  0x038
+#define DSC_RC_BUF_THRESH   0x03C
+#define DSC_RANGE_MIN_QP0x074
+#define DSC_RANGE_MAX_QP0x0B0
+#define DSC_RANGE_BPG_OFFSET0x0EC
+
+static void dpu_hw_dsc_disable(struct dpu_hw_dsc *dsc)
+{
+   struct dpu_hw_blk_reg_map *c = >hw;
+
+   DPU_REG_WRITE(c, DSC_COMMON_MODE, 0);
+}
+
+static void dpu_hw_dsc_config(struct dpu_hw_dsc *hw_dsc,
+ struct msm_display_dsc_config *dsc,
+ u32 mode,
+ u32 initial_lines)
+{
+   struct dpu_hw_blk_reg_map *c = _dsc->hw;
+   u32 data, lsb, bpp;
+   u32 slice_last_group_size;
+   u32 det_thresh_flatness;
+   bool is_cmd_mode = !(mode & DSC_MODE_VIDEO);
+
+   DPU_REG_WRITE(c, DSC_COMMON_MODE, mode);
+
+   if (is_cmd_mode)
+   initial_lines += 1;
+
+   slice_last_group_size = 3 - (dsc->drm->slice_width % 3);
+   data = (initial_lines << 20);
+   data |= ((slice_last_group_size - 1) << 18);
+   /* bpp is 6.4 format, 4 LSBs bits are for fractional part */
+   data |= dsc->drm->bits_per_pixel << 12;
+   lsb = dsc->drm->bits_per_pixel % 4;
+   bpp = dsc->drm->bits_per_pixel / 4;
+   bpp *= 4;
+   bpp <<= 4;
+   bpp |= lsb;
+
+   data |= bpp << 8;
+   data |= (dsc->drm->block_pred_enable << 7);
+   data |= (dsc->drm->line_buf_depth << 3);
+   data |= (dsc->drm->simple_422 << 2);
+   data |= (dsc->drm->convert_rgb << 1);
+   data |= dsc->drm->bits_per_component;
+
+   DPU_REG_WRITE(c, DSC_ENC, data);
+
+   data = dsc->drm->pic_width << 16;
+   data |= dsc->drm->pic_height;
+   DPU_REG_WRITE(c, DSC_PICTURE, 

[PATCH v6 02/14] drm/msm/dsi: Pass DSC params to drm_panel

[Vinod Koul]

When DSC is enabled, we need to get the DSC parameters from the panel
driver, so add a dsc parameter in panel to fetch and pass DSC
configuration for DSI panels to DPU encoder, which will enable and
then configure DSC hardware blocks accordingly.

Signed-off-by: Dmitry Baryshkov 
Reviewed-by: Abhinav Kumar 
Signed-off-by: Vinod Koul 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h |  2 ++
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c |  2 ++
 drivers/gpu/drm/msm/dsi/dsi.c   |  5 +
 drivers/gpu/drm/msm/dsi/dsi.h   |  1 +
 drivers/gpu/drm/msm/dsi/dsi_host.c  | 22 +
 drivers/gpu/drm/msm/msm_drv.h   |  6 ++
 include/drm/drm_panel.h |  7 +++
 7 files changed, 45 insertions(+)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
index 42db6ce12caf..ef873e5285a0 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
@@ -27,6 +27,7 @@
  *  based on num_of_h_tiles
  * @is_te_using_watchdog_timer:  Boolean to indicate watchdog TE is
  *  used instead of panel TE in cmd mode panels
+ * @dsc:   DSC configuration data for DSC-enabled displays
  */
 struct msm_display_info {
int intf_type;
@@ -34,6 +35,7 @@ struct msm_display_info {
uint32_t num_of_h_tiles;
uint32_t h_tile_instance[MAX_H_TILES_PER_DISPLAY];
bool is_te_using_watchdog_timer;
+   struct msm_display_dsc_config *dsc;
 };
 
 /**
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index e29796c4f27b..e64154407425 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -582,6 +582,8 @@ static int _dpu_kms_initialize_dsi(struct drm_device *dev,
MSM_DISPLAY_CAP_CMD_MODE :
MSM_DISPLAY_CAP_VID_MODE;
 
+   info.dsc = msm_dsi_get_dsc_config(priv->dsi[i]);
+
if (msm_dsi_is_bonded_dsi(priv->dsi[i]) && priv->dsi[other]) {
rc = msm_dsi_modeset_init(priv->dsi[other], dev, 
encoder);
if (rc) {
diff --git a/drivers/gpu/drm/msm/dsi/dsi.c b/drivers/gpu/drm/msm/dsi/dsi.c
index c12e66aa42a3..06a76834be52 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.c
+++ b/drivers/gpu/drm/msm/dsi/dsi.c
@@ -21,6 +21,11 @@ bool msm_dsi_is_cmd_mode(struct msm_dsi *msm_dsi)
return !(host_flags & MIPI_DSI_MODE_VIDEO);
 }
 
+struct msm_display_dsc_config *msm_dsi_get_dsc_config(struct msm_dsi *msm_dsi)
+{
+   return msm_dsi_host_get_dsc_config(msm_dsi->host);
+}
+
 static int dsi_get_phy(struct msm_dsi *msm_dsi)
 {
struct platform_device *pdev = msm_dsi->pdev;
diff --git a/drivers/gpu/drm/msm/dsi/dsi.h b/drivers/gpu/drm/msm/dsi/dsi.h
index c8dedc95428c..16cd9b2fce86 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.h
+++ b/drivers/gpu/drm/msm/dsi/dsi.h
@@ -152,6 +152,7 @@ int dsi_calc_clk_rate_v2(struct msm_dsi_host *msm_host, 
bool is_bonded_dsi);
 int dsi_calc_clk_rate_6g(struct msm_dsi_host *msm_host, bool is_bonded_dsi);
 void msm_dsi_host_snapshot(struct msm_disp_state *disp_state, struct 
mipi_dsi_host *host);
 void msm_dsi_host_test_pattern_en(struct mipi_dsi_host *host);
+struct msm_display_dsc_config *msm_dsi_host_get_dsc_config(struct 
mipi_dsi_host *host);
 
 /* dsi phy */
 struct msm_dsi_phy;
diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 4a8a9b31ce1d..cb2e179127ea 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -2061,9 +2061,24 @@ int msm_dsi_host_modeset_init(struct mipi_dsi_host *host,
 {
struct msm_dsi_host *msm_host = to_msm_dsi_host(host);
const struct msm_dsi_cfg_handler *cfg_hnd = msm_host->cfg_hnd;
+   struct drm_panel *panel;
int ret;
 
msm_host->dev = dev;
+   panel = msm_dsi_host_get_panel(_host->base);
+
+   if (panel && panel->dsc) {
+   struct msm_display_dsc_config *dsc = msm_host->dsc;
+
+   if (!dsc) {
+   dsc = devm_kzalloc(_host->pdev->dev, sizeof(*dsc), 
GFP_KERNEL);
+   if (!dsc)
+   return -ENOMEM;
+   dsc->drm = panel->dsc;
+   msm_host->dsc = dsc;
+   }
+   }
+
ret = cfg_hnd->ops->tx_buf_alloc(msm_host, SZ_4K);
if (ret) {
pr_err("%s: alloc tx gem obj failed, %d\n", __func__, ret);
@@ -2628,3 +2643,10 @@ void msm_dsi_host_test_pattern_en(struct mipi_dsi_host 
*host)
dsi_write(msm_host, 
REG_DSI_TEST_PATTERN_GEN_CMD_STREAM0_TRIGGER,

DSI_TEST_PATTERN_GEN_CMD_STREAM0_TRIGGER_SW_TRIGGER);
 }
+
+struct msm_display_dsc_config *msm_dsi_host_get_dsc_config(struct 
mipi_dsi_host *host)
+{
+   struct 

[PATCH v6 01/14] drm/msm/dsi: add support for dsc data

[Vinod Koul]

Display Stream Compression (DSC) parameters need to be calculated. Add
helpers and struct msm_display_dsc_config in msm_drv for this
msm_display_dsc_config uses drm_dsc_config for DSC parameters.

Reviewed-by: Dmitry Baryshkov 
Reviewed-by: Abhinav Kumar 
Signed-off-by: Vinod Koul 
---
 drivers/gpu/drm/msm/dsi/dsi_host.c | 130 +
 drivers/gpu/drm/msm/msm_drv.h  |   6 ++
 2 files changed, 136 insertions(+)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index d51e70fab93d..4a8a9b31ce1d 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -31,6 +31,8 @@
 
 #define DSI_RESET_TOGGLE_DELAY_MS 20
 
+static int dsi_populate_dsc_params(struct msm_display_dsc_config *dsc);
+
 static int dsi_get_version(const void __iomem *base, u32 *major, u32 *minor)
 {
u32 ver;
@@ -157,6 +159,7 @@ struct msm_dsi_host {
struct regmap *sfpb;
 
struct drm_display_mode *mode;
+   struct msm_display_dsc_config *dsc;
 
/* connected device info */
struct device_node *device_node;
@@ -1722,6 +1725,133 @@ static int dsi_host_parse_lane_data(struct msm_dsi_host 
*msm_host,
return -EINVAL;
 }
 
+static u32 dsi_dsc_rc_buf_thresh[DSC_NUM_BUF_RANGES - 1] = {
+   0x0e, 0x1c, 0x2a, 0x38, 0x46, 0x54, 0x62,
+   0x69, 0x70, 0x77, 0x79, 0x7b, 0x7d, 0x7e
+};
+
+/* only 8bpc, 8bpp added */
+static char min_qp[DSC_NUM_BUF_RANGES] = {
+   0, 0, 1, 1, 3, 3, 3, 3, 3, 3, 5, 5, 5, 7, 13
+};
+
+static char max_qp[DSC_NUM_BUF_RANGES] = {
+   4, 4, 5, 6, 7, 7, 7, 8, 9, 10, 11, 12, 13, 13, 15
+};
+
+static char bpg_offset[DSC_NUM_BUF_RANGES] = {
+   2, 0, 0, -2, -4, -6, -8, -8, -8, -10, -10, -12, -12, -12, -12
+};
+
+static int dsi_populate_dsc_params(struct msm_display_dsc_config *dsc)
+{
+   int mux_words_size;
+   int groups_per_line, groups_total;
+   int min_rate_buffer_size;
+   int hrd_delay;
+   int pre_num_extra_mux_bits, num_extra_mux_bits;
+   int slice_bits;
+   int target_bpp_x16;
+   int data;
+   int final_value, final_scale;
+   int i;
+
+   dsc->drm->rc_model_size = 8192;
+   dsc->drm->first_line_bpg_offset = 12;
+   dsc->drm->rc_edge_factor = 6;
+   dsc->drm->rc_tgt_offset_high = 3;
+   dsc->drm->rc_tgt_offset_low = 3;
+   dsc->drm->simple_422 = 0;
+   dsc->drm->convert_rgb = 1;
+   dsc->drm->vbr_enable = 0;
+
+   /* handle only bpp = bpc = 8 */
+   for (i = 0; i < DSC_NUM_BUF_RANGES - 1 ; i++)
+   dsc->drm->rc_buf_thresh[i] = dsi_dsc_rc_buf_thresh[i];
+
+   for (i = 0; i < DSC_NUM_BUF_RANGES; i++) {
+   dsc->drm->rc_range_params[i].range_min_qp = min_qp[i];
+   dsc->drm->rc_range_params[i].range_max_qp = max_qp[i];
+   dsc->drm->rc_range_params[i].range_bpg_offset = bpg_offset[i];
+   }
+
+   dsc->drm->initial_offset = 6144; /* Not bpp 12 */
+   if (dsc->drm->bits_per_pixel != 8)
+   dsc->drm->initial_offset = 2048;/* bpp = 12 */
+
+   mux_words_size = 48;/* bpc == 8/10 */
+   if (dsc->drm->bits_per_component == 12)
+   mux_words_size = 64;
+
+   dsc->drm->initial_xmit_delay = 512;
+   dsc->drm->initial_scale_value = 32;
+   dsc->drm->first_line_bpg_offset = 12;
+   dsc->drm->line_buf_depth = dsc->drm->bits_per_component + 1;
+
+   /* bpc 8 */
+   dsc->drm->flatness_min_qp = 3;
+   dsc->drm->flatness_max_qp = 12;
+   dsc->drm->rc_quant_incr_limit0 = 11;
+   dsc->drm->rc_quant_incr_limit1 = 11;
+   dsc->drm->mux_word_size = DSC_MUX_WORD_SIZE_8_10_BPC;
+
+   /* FIXME: need to call drm_dsc_compute_rc_parameters() so that rest of
+* params are calculated
+*/
+   groups_per_line = DIV_ROUND_UP(dsc->drm->slice_width, 3);
+   dsc->drm->slice_chunk_size = dsc->drm->slice_width * 
dsc->drm->bits_per_pixel / 8;
+   if ((dsc->drm->slice_width * dsc->drm->bits_per_pixel) % 8)
+   dsc->drm->slice_chunk_size++;
+
+   /* rbs-min */
+   min_rate_buffer_size =  dsc->drm->rc_model_size - 
dsc->drm->initial_offset +
+   dsc->drm->initial_xmit_delay * 
dsc->drm->bits_per_pixel +
+   groups_per_line * 
dsc->drm->first_line_bpg_offset;
+
+   hrd_delay = DIV_ROUND_UP(min_rate_buffer_size, 
dsc->drm->bits_per_pixel);
+
+   dsc->drm->initial_dec_delay = hrd_delay - dsc->drm->initial_xmit_delay;
+
+   dsc->drm->initial_scale_value = 8 * dsc->drm->rc_model_size /
+  (dsc->drm->rc_model_size - 
dsc->drm->initial_offset);
+
+   slice_bits = 8 * dsc->drm->slice_chunk_size * dsc->drm->slice_height;
+
+   groups_total = groups_per_line * dsc->drm->slice_height;
+
+   data = dsc->drm->first_line_bpg_offset * 2048;
+
+   dsc->drm->nfl_bpg_offset = DIV_ROUND_UP(data, (dsc->drm->slice_height - 
1));

[PATCH v6 00/14] drm/msm: Add Display Stream Compression Support

[Vinod Koul]

Display Stream Compression (DSC) compresses the display stream in host which
is later decoded by panel. This series enables this for Qualcomm msm driver.
This was tested on Google Pixel3 phone which use LGE SW43408 panel.
 
The changes include DSC data and hardware block enabling for DPU1 then
support in encoder. We also add support in DSI and introduce required
topology changes.
 
In order for panel to set the DSC parameters we add dsc in drm_panel and
pass the dsc configuration from the panel driver

Complete changes which enable this for Pixel3 along with panel driver (not
part of this series) and DT changes can be found at:
git.linaro.org/people/vinod.koul/kernel.git pixel/dsc_v6
 
Comments welcome!

Changes since v5:
 - rebase on msm-next
 - use generated header patch from mesa for dsc registers
 - use generated header macros for dsc register calculation
 - remove msm dsc struct (Dmitry)

Changes since v4:
 - Use new apprach based on Abhinav suggestion for dsc with 3d-merge
 - Make common function for dsc timing caln and call that from video and cmd
   mode
 - update description for patch "Pass DSC params to drm_panel"
 - update couple of typos as pointed by Marijn
 - drop dpu_encoder_dsc_pclk_param_calc() as that was duplicating the caln
   done in dsi timing
 - Update copyright to 2022 to new files
 - Update Abhinav's email to new quic one

Changes since v3:
 - Merge changes from Dmitry to have dsc per encoder instance
 - add warning for dsc and mode3d enabled together
 - set dsc in dpu_encoder_phys_vid as well
 - remove dsc hardcoded mask
 - use devm_kzalloc for memory allocation for dsc

Changes since v2:
 - Fix comments by Dimitry except the dsc being global.
 - Move RM patch later for dependency on topology now
 - Add patch for mode valid callback for dsi_mgr
 - Add missing structure documentation patch
 - Fix errors in mode_3d changes
 - Rebase on v5.16-rc1 and test

Changes since v1:
 - Fix various issues spotted by kbuildbot
 - Rebase to v5.15-rc3
 - Remove unused fields and duplicate defines
 - Enable DSC blocks only when DSC is enabled
 - remove sdm845 feature mask, use 0
 - Check for DSC in hw_ctl

Changes since RFC:
 - Drop the DT binding patch as we derive the configuration from panel
 - Drop the drm api patch as we no longer need it (use pps drm api)
 - Fix comments raised by Dimitry
 - Add dsc parameters calculation from downstream

*** SUBJECT HERE ***

*** BLURB HERE ***

Dmitry Baryshkov (1):
  drm/msm/dpu: don't use merge_3d if DSC merge topology is used

Vinod Koul (13):
  drm/msm/dsi: add support for dsc data
  drm/msm/dsi: Pass DSC params to drm_panel
  drm/msm/disp/dpu1: Add support for DSC
  drm/msm/disp/dpu1: Add support for DSC in pingpong block
  drm/msm/disp/dpu1: Add DSC for SDM845 to hw_catalog
  drm/msm/disp/dpu1: Add DSC support in hw_ctl
  drm/msm/disp/dpu1: Add support for DSC in encoder
  drm/msm: Add missing num_dspp field documentation
  drm/msm/disp/dpu1: Add support for DSC in topology
  drm/msm/disp/dpu1: Add DSC support in RM
  drm/msm/dsi: add mode valid callback for dsi_mgr
  drm/msm: Update generated headers
  drm/msm/dsi: Add support for DSC configuration

 drivers/gpu/drm/msm/Makefile  |   1 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c   | 157 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h   |   8 +
 .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h  |  12 +-
 .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c|  20 ++
 .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h|  13 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c|  11 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h|   2 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c| 215 ++
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.h|  80 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h   |  13 +
 .../gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c   |  32 ++
 .../gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h   |  14 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c   |   2 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h   |   1 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c|  56 
 drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h|   1 +
 drivers/gpu/drm/msm/dsi/dsi.c |   5 +
 drivers/gpu/drm/msm/dsi/dsi.h |   3 +
 drivers/gpu/drm/msm/dsi/dsi.xml.h |  80 +
 drivers/gpu/drm/msm/dsi/dsi_host.c| 276 +-
 drivers/gpu/drm/msm/dsi/dsi_manager.c |  12 +
 drivers/gpu/drm/msm/msm_drv.h |  15 +
 include/drm/drm_panel.h   |   7 +
 24 files changed, 1032 insertions(+), 4 deletions(-)
 create mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
 create mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.h


base-commit: 05241de1f69eb7f56b0a5e0bec96a7752fad1b2f
-- 
2.34.1

Re: [PATCH 2/4] dt-bindings: display: ssd1307fb: Add entry for SINO WEALTH SH1106

[Chen-Yu Tsai]

On Mon, Apr 4, 2022 at 11:48 PM Javier Martinez Canillas
 wrote:
>
> Hello Chen-Yu,
>
> On 4/4/22 17:06, Chen-Yu Tsai wrote:
>
> [snip]
>
> >>>  enum:
> >>> +  - sinowealth,sh1106-i2c
> >>
> >> I like that you didn't include a "fb" suffix for this, the existing
> >> ones are cargo culting from the previous fbdev driver to make existing
> >> DTBs compatible with the DRM driver.
> >>
> >> I've been thinking if I should post a patch to compatible strings
> >> without the "fb" and mark the current ones as deprecated...
> >>
> >> Reviewed-by: Javier Martinez Canillas 
> >
> > I also thought about dropping the "-i2c" suffix, but then thought
> > there might be a case where someone wanted to search the device
> > tree specifically for an I2C connected node using said compatible
> > string.
> >
> > What do you think?
> >
> >
>
> tl; dr: unfortunately we can't do it due how SPI and I2C report module
> aliases. Otherwise module auto loading will not work. I wrote a much
> longer explanation with some details not so long ago:
>
> https://patchwork.kernel.org/project/dri-devel/patch/20220209091204.2513437-1-javi...@redhat.com/#24730793

Right. I think that crossed my mind at some point, but didn't stick.
Thanks for raising it again. :)

> BTW, I bought a SSD1306 SPI controller and go it working this weekend.
>
> I plan to post the patches once yours land, to avoid in-flight series
> that may conflict. And what I did is mark the -fb as deprecated, then
> added "ssd130x-i2c" and "ssd130x-spi" compatibles strings.
>
> The WIP patches can be found here in case you are interested:
>
> https://github.com/martinezjavier/linux/tree/drm-ssd130x-spi

I took a quick look and a couple things stood out:

1. Would 3-wire SPI ever be considered? If so, might want to
   rename some of variables/functions as *_spi_4wire_* to
   begin with.

2. Maybe we should move the ssd130x_deviceinfo stuff into the
   core module, and define an enum to use for matching compatible
   strings across the modules to their respective device info
   entries? FYI we are doing this in drivers/mfd/axp20x* .

I think a friend of mine has a SPI based SH1106 module that I
could borrow and test/work on, but that's a big if.


Regards
ChenYu

Re: [PATCH] drm/format_helper: fix a kernel-doc typo

[Simon Ser]

Both doc patches pushed, thanks. I had to manually edit them because they
wouldn't apply cleanly. Next time, please use git-send-email (see
https://git-send-email.io/ for setup instructions).

Re: [RFC][PATCH 2/3] drm/modes: Make width-mm/height-mm mandatory in of_get_drm_panel_display_mode()

[Rob Herring]

On Sat, Apr 02, 2022 at 07:55:59PM +0200, Marek Vasut wrote:
> On 4/2/22 19:08, Noralf Trønnes wrote:
> > 
> > 
> > Den 02.04.2022 18.39, skrev Marek Vasut:
> > > On 4/2/22 09:45, Noralf Trønnes wrote:
> > > > 
> > > > 
> > > > Den 02.04.2022 06.28, skrev Marek Vasut:
> > > > > On 4/2/22 05:19, Laurent Pinchart wrote:
> > > > > > On Fri, Apr 01, 2022 at 10:36:24PM +0200, Marek Vasut wrote:
> > > > > > > On 4/1/22 20:46, Laurent Pinchart wrote:
> > > > > > > > On Fri, Apr 01, 2022 at 06:37:54PM +0200, Marek Vasut wrote:
> > > > > > > > > Make the width-mm/height-mm panel properties mandatory in
> > > > > > > > > of_get_drm_panel_display_mode(), print error message and
> > > > > > > > > return -ve in case these DT properties are not present.
> > > > > > > > > This is needed to correctly report panel dimensions.
> > > > > > > > 
> > > > > > > > Can we guarantee this won't cause a regression ?
> > > > > > > 
> > > > > > > For the upstream DTs, I think we can.
> > > > > > > For downstream DTs, we cannot know.
> > > > > > 
> > > > > > Are there users of this function whose DT bindings don't require the
> > > > > > width-mm and height-mm properties ?
> > > > > 
> > > > > There is literally one user of this function upstream:
> > > > > drivers/gpu/drm/tiny/panel-mipi-dbi.c
> > > > 
> > > > Yes, the function was added for that driver since it was so generic in
> > > > nature. What about adding an argument to of_get_drm_panel_display_mode()
> > > > that tells if the properties are mandatory or not?
> > > 
> > > Sure, we can do that, but maybe the question here is even bigger than
> > > this series.
> > > 
> > > Should every panel set mandatory width_mm/height_mm so e.g. the user
> > > space can infer DPI from it and set up scaling accordingly, or should
> > > width_mm/height_mm be optional ?
> > > 
> > > I think width_mm/height_mm should be mandatory for all panels.
> > > 
> > > Thoughts ?
> > 
> > If this had come up during the review of the driver I would have no
> > problem making it mandatory. It makes sense for DPI. Maybe it's possible
> > to get around the ABI break by getting in a change through -fixes before
> > 5.18 is released? I'm fine with that.
> 
> Well that's awesome, the dbi-spi.yaml didn't land in any kernel release yet,
> so we still have a chance to fix it ? Rob ?

Yes, it can be fixed. And the binding, not the kernel, is the place to 
enforce it being mandatory IMO.

Rob

Re: [PATCH] drm/amd/display: cleanup extern usage in function definition

[Harry Wentland]

On 2022-04-04 11:43, Tom Rix wrote:
> 
> On 4/4/22 8:22 AM, Harry Wentland wrote:
>>
>> On 2022-04-03 10:21, Tom Rix wrote:
>>> Smatch reports this issue
>>> hdcp1_execution.c:500:29: warning: function
>>>    'mod_hdcp_hdcp1_dp_execution' with external linkage
>>>    has definition
>>>
>> Which branch are you using?
> 
> linux-next from 4/1
> 

Apologies. I was looking at the wrong function.

Reviewed-by: Harry Wentland 

Harry

> Tom
> 
>>
>> I don't see the 'extern' on
>> https://gitlab.freedesktop.org/agd5f/linux/-/blob/amd-staging-drm-next/drivers/gpu/drm/amd/display/modules/hdcp/hdcp1_execution.c>>>
>> Harry
>>
>>
>>> The storage-class-specifier extern is not needed in a
>>> definition, so remove it.
>>>
>>> Signed-off-by: Tom Rix 
>>> ---
>>>   drivers/gpu/drm/amd/display/modules/hdcp/hdcp1_execution.c | 6 +++---
>>>   1 file changed, 3 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/amd/display/modules/hdcp/hdcp1_execution.c 
>>> b/drivers/gpu/drm/amd/display/modules/hdcp/hdcp1_execution.c
>>> index 6ec918af3bff..1ddb4f5eac8e 100644
>>> --- a/drivers/gpu/drm/amd/display/modules/hdcp/hdcp1_execution.c
>>> +++ b/drivers/gpu/drm/amd/display/modules/hdcp/hdcp1_execution.c
>>> @@ -497,9 +497,9 @@ enum mod_hdcp_status mod_hdcp_hdcp1_execution(struct 
>>> mod_hdcp *hdcp,
>>>   return status;
>>>   }
>>>   -extern enum mod_hdcp_status mod_hdcp_hdcp1_dp_execution(struct mod_hdcp 
>>> *hdcp,
>>> -    struct mod_hdcp_event_context *event_ctx,
>>> -    struct mod_hdcp_transition_input_hdcp1 *input)
>>> +enum mod_hdcp_status mod_hdcp_hdcp1_dp_execution(struct mod_hdcp *hdcp,
>>> + struct mod_hdcp_event_context *event_ctx,
>>> + struct mod_hdcp_transition_input_hdcp1 *input)
>>>   {
>>>   enum mod_hdcp_status status = MOD_HDCP_STATUS_SUCCESS;
>>>   
> 

Re: [PATCH 7/7] video: fbdev: s3fb: Error out if 'pixclock' equals zero

[Geert Uytterhoeven]

On Mon, Apr 4, 2022 at 3:50 PM Zheyu Ma  wrote:
> The userspace program could pass any values to the driver through
> ioctl() interface. If the driver doesn't check the value of 'pixclock',
> it may cause divide error.
>
> Fix this by checking whether 'pixclock' is zero in s3fb_check_var().
>
> The following log reveals it:
>
> [  511.141561] divide error:  [#1] PREEMPT SMP KASAN PTI
> [  511.141607] RIP: 0010:s3fb_check_var+0x3f3/0x530
> [  511.141693] Call Trace:
> [  511.141695]  
> [  511.141716]  fb_set_var+0x367/0xeb0
> [  511.141815]  do_fb_ioctl+0x234/0x670
> [  511.141876]  fb_ioctl+0xdd/0x130
> [  511.141888]  do_syscall_64+0x3b/0x90
>
> Signed-off-by: Zheyu Ma 
> ---
>  drivers/video/fbdev/s3fb.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/drivers/video/fbdev/s3fb.c b/drivers/video/fbdev/s3fb.c
> index 5c74253e7b2c..b93c8eb02336 100644
> --- a/drivers/video/fbdev/s3fb.c
> +++ b/drivers/video/fbdev/s3fb.c
> @@ -549,6 +549,9 @@ static int s3fb_check_var(struct fb_var_screeninfo *var, 
> struct fb_info *info)
> int rv, mem, step;
> u16 m, n, r;
>
> +   if (!var->pixclock)
> +   return -EINVAL;
> +

When passed an invalid value, .check_var() is supposed to
round up the invalid value to a valid value, if possible.

> /* Find appropriate format */
> rv = svga_match_format (s3fb_formats, var, NULL);

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: [PATCH 6/7] video: fbdev: arkfb: Error out if 'pixclock' equals zero

[Geert Uytterhoeven]

On Mon, Apr 4, 2022 at 3:10 PM Zheyu Ma  wrote:
> The userspace program could pass any values to the driver through
> ioctl() interface. If the driver doesn't check the value of 'pixclock',
> it may cause divide error.
>
> Fix this by checking whether 'pixclock' is zero.
>
> The following log reveals it:
>
> [   76.603696] divide error:  [#1] PREEMPT SMP KASAN PTI
> [   76.603712] RIP: 0010:arkfb_set_par+0x10fc/0x24f0
> [   76.603762] Call Trace:
> [   76.603764]  
> [   76.603773]  fb_set_var+0x604/0xeb0
> [   76.603827]  do_fb_ioctl+0x234/0x670
> [   76.603873]  fb_ioctl+0xdd/0x130
> [   76.603881]  do_syscall_64+0x3b/0x90
>
> Signed-off-by: Zheyu Ma 

Thanks for your patch!

> --- a/drivers/video/fbdev/arkfb.c
> +++ b/drivers/video/fbdev/arkfb.c
> @@ -566,6 +566,9 @@ static int arkfb_check_var(struct fb_var_screeninfo *var, 
> struct fb_info *info)
>  {
> int rv, mem, step;
>
> +   if (!var->pixclock)
> +   return -EINVAL;

When passed an invalid value, .check_var() is supposed to
round up the invalid to a valid value, if possible.

> +
> /* Find appropriate format */
> rv = svga_match_format (arkfb_formats, var, NULL);
> if (rv < 0)

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: [PATCH] drm/format_helper: fix a kernel-doc typo

[Javier Martinez Canillas]

Hello Randy,

On 4/4/22 01:29, Randy Dunlap wrote:
> It looks like the incorrect name of a function parameter was used
> in the kernel-doc notation, so just change it to the function's
> parameter name to quell the kernel-doc warning.
> 
> drivers/gpu/drm/drm_format_helper.c:640: warning: Function parameter or 
> member 'vaddr' not described in 'drm_fb_xrgb_to_mono_reversed'
> drivers/gpu/drm/drm_format_helper.c:640: warning: Excess function parameter 
> 'src' description in 'drm_fb_xrgb_to_mono_reversed'
> 
> Fixes: bcf8b616deb8 ("drm/format-helper: Add 
> drm_fb_xrgb_to_mono_reversed()")
> Signed-off-by: Randy Dunlap 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: dri-devel@lists.freedesktop.org
> Cc: Javier Martinez Canillas 
> Cc: Maarten Lankhorst 
> CC: Maxime Ripard 
> CC: Thomas Zimmermann 
> ---
>  drivers/gpu/drm/drm_format_helper.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>

Thanks for the patch.

Reviewed-by: Javier Martinez Canillas 

-- 
Best regards,

Javier Martinez Canillas
Linux Engineering
Red Hat

Re: [PATCH 2/4] dt-bindings: display: ssd1307fb: Add entry for SINO WEALTH SH1106

[Javier Martinez Canillas]

Hello Chen-Yu,

On 4/4/22 17:06, Chen-Yu Tsai wrote:

[snip]

>>>  enum:
>>> +  - sinowealth,sh1106-i2c
>>
>> I like that you didn't include a "fb" suffix for this, the existing
>> ones are cargo culting from the previous fbdev driver to make existing
>> DTBs compatible with the DRM driver.
>>
>> I've been thinking if I should post a patch to compatible strings
>> without the "fb" and mark the current ones as deprecated...
>>
>> Reviewed-by: Javier Martinez Canillas 
> 
> I also thought about dropping the "-i2c" suffix, but then thought
> there might be a case where someone wanted to search the device
> tree specifically for an I2C connected node using said compatible
> string.
> 
> What do you think?
> 
>

tl; dr: unfortunately we can't do it due how SPI and I2C report module
aliases. Otherwise module auto loading will not work. I wrote a much
longer explanation with some details not so long ago:

https://patchwork.kernel.org/project/dri-devel/patch/20220209091204.2513437-1-javi...@redhat.com/#24730793

BTW, I bought a SSD1306 SPI controller and go it working this weekend.

I plan to post the patches once yours land, to avoid in-flight series
that may conflict. And what I did is mark the -fb as deprecated, then
added "ssd130x-i2c" and "ssd130x-spi" compatibles strings.

The WIP patches can be found here in case you are interested:

https://github.com/martinezjavier/linux/tree/drm-ssd130x-spi

> ChenYu
> 

-- 
Best regards,

Javier Martinez Canillas
Linux Engineering
Red Hat

Re: [PATCH] drm/amd/display: cleanup extern usage in function definition

[Tom Rix]

On 4/4/22 8:22 AM, Harry Wentland wrote:


On 2022-04-03 10:21, Tom Rix wrote:

Smatch reports this issue
hdcp1_execution.c:500:29: warning: function
   'mod_hdcp_hdcp1_dp_execution' with external linkage
   has definition


Which branch are you using?


linux-next from 4/1

Tom



I don't see the 'extern' on
https://gitlab.freedesktop.org/agd5f/linux/-/blob/amd-staging-drm-next/drivers/gpu/drm/amd/display/modules/hdcp/hdcp1_execution.c

Harry



The storage-class-specifier extern is not needed in a
definition, so remove it.

Signed-off-by: Tom Rix 
---
  drivers/gpu/drm/amd/display/modules/hdcp/hdcp1_execution.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/modules/hdcp/hdcp1_execution.c 
b/drivers/gpu/drm/amd/display/modules/hdcp/hdcp1_execution.c
index 6ec918af3bff..1ddb4f5eac8e 100644
--- a/drivers/gpu/drm/amd/display/modules/hdcp/hdcp1_execution.c
+++ b/drivers/gpu/drm/amd/display/modules/hdcp/hdcp1_execution.c
@@ -497,9 +497,9 @@ enum mod_hdcp_status mod_hdcp_hdcp1_execution(struct 
mod_hdcp *hdcp,
return status;
  }
  
-extern enum mod_hdcp_status mod_hdcp_hdcp1_dp_execution(struct mod_hdcp *hdcp,

-   struct mod_hdcp_event_context *event_ctx,
-   struct mod_hdcp_transition_input_hdcp1 *input)
+enum mod_hdcp_status mod_hdcp_hdcp1_dp_execution(struct mod_hdcp *hdcp,
+struct mod_hdcp_event_context 
*event_ctx,
+struct 
mod_hdcp_transition_input_hdcp1 *input)
  {
enum mod_hdcp_status status = MOD_HDCP_STATUS_SUCCESS;
  

Re: [Intel-gfx] [PATCH] drm/i915/display/debugfs: Add connector debugfs for "output_bpc"

[Daniel Vetter]

On Mon, Apr 04, 2022 at 01:46:23PM +0300, Jani Nikula wrote:
> On Mon, 04 Apr 2022, "Modem, Bhanuprakash"  
> wrote:
> > On Fri-01-04-2022 06:10 pm, Jani Nikula wrote:
> >> On Tue, 29 Mar 2022, Bhanuprakash Modem  
> >> wrote:
> >>> This new debugfs will expose the connector's max supported bpc
> >>> and the bpc currently using. It is very useful for verifying
> >>> whether we enter the correct output color depth from IGT.
> >>>
> >>> Example:
> >>> cat /sys/kernel/debug/dri/0/DP-1/output_bpc
> >>> Current: 8
> >>> Maximum: 10
> >>>
> >>> V2: Add connector's max bpc to i915_display_info
> >>>
> >>> Cc: Ville Syrjälä 
> >>> Cc: Uma Shankar 
> >>> Cc: Swati Sharma 
> >>> Signed-off-by: Bhanuprakash Modem 
> >>> ---
> >>>   .../drm/i915/display/intel_display_debugfs.c  | 46 +++
> >>>   1 file changed, 46 insertions(+)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c 
> >>> b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> >>> index c1e74a13a0828..694d27f3b109c 100644
> >>> --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> >>> +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> >>> @@ -663,6 +663,8 @@ static void intel_connector_info(struct seq_file *m,
> >>>   seq_puts(m, "\tHDCP version: ");
> >>>   intel_hdcp_info(m, intel_connector);
> >>>   
> >>> + seq_printf(m, "\tmax bpc: %u\n", connector->display_info.bpc);
> >>> +
> >>>   intel_panel_info(m, intel_connector);
> >>>   
> >>>   seq_printf(m, "\tmodes:\n");
> >>> @@ -2275,6 +2277,47 @@ static const struct file_operations 
> >>> i915_dsc_bpp_fops = {
> >>>   .write = i915_dsc_bpp_write
> >>>   };
> >>>   
> >>> +/*
> >>> + * Returns the maximum output bpc for the connector.
> >>> + * Example usage: cat /sys/kernel/debug/dri/0/DP-1/output_bpc
> >>> + */
> >>> +static int output_bpc_show(struct seq_file *m, void *data)
> >>> +{
> >>> + struct drm_connector *connector = m->private;
> >>> + struct drm_device *dev = connector->dev;
> >>> + struct drm_crtc *crtc;
> >>> + struct intel_crtc_state *crtc_state;
> >>> + struct intel_encoder *encoder = 
> >>> intel_attached_encoder(to_intel_connector(connector));
> >>> + int res;
> >>> +
> >>> + if (!encoder)
> >>> + return -ENODEV;
> >>> +
> >>> + res = 
> >>> drm_modeset_lock_single_interruptible(>mode_config.connection_mutex);
> >>> + if (res)
> >>> + return res;
> >>> +
> >>> + crtc = connector->state->crtc;
> >>> + if (connector->status != connector_status_connected || !crtc) {
> >>> + res = -ENODEV;
> >>> + goto unlock;
> >>> + }
> >>> +
> >>> + crtc_state = to_intel_crtc_state(crtc->state);
> >>> + if (!crtc_state->hw.active)
> >>> + goto unlock;
> >>> +
> >>> + seq_printf(m, "Current: %u\n", crtc_state->pipe_bpp / 3);
> >>> + seq_printf(m, "Maximum: %u\n", connector->display_info.bpc);
> >>> + res = 0;
> >>> +
> >>> +unlock:
> >>> + drm_modeset_unlock(>mode_config.connection_mutex);
> >>> +
> >>> + return res;
> >>> +}
> >>> +DEFINE_SHOW_ATTRIBUTE(output_bpc);
> >> 
> >> Looks like an excessive amount of code for a single value.
> >
> > Yeah, but these values are very helpful in many IGT tests like 
> > kms_color, kms_hdr, kms_dither, kms_dsc etc..
> >
> > Otherwise IGT needs to request the kernel to get the EDID, and parse 
> > that EDID to get the "Maximum" value which is redundant (Kernel is 
> > already doing the same) and not recommended in IGT.
> >
> > And there is no way to get the "Current" value except reading it from 
> > i915_display_info which is again not recommended in IGT (As 
> > i915_display_info is Intel specific).
> 
> Note how we have intel_connector_debugfs_add() for connector debugfs and
> intel_crtc_debugfs_add() for crtc debugfs, and how this patch just mixes
> up the two by looking up crtc and state from the connector debugfs.
> 
> > This debugfs is already introduced & using by AMD: 
> > https://patchwork.freedesktop.org/patch/308586
> 
> Wait, what?
> 
> Both amd and i915 adding the name "output_bpc" is *not* the way to
> roll. We only add i915_ prefixed debugfs files from i915.ko.

Yeah vendor prefix would be nice, but it's debugfs so we can always fix
it.

Also would be really good to pull that output_bpc into drm core if it's
something standard that igts need in general, so ideally we don't just
standardize the drm side, but also the testcases that need this and make
them generic to run on any kms driver.
-Daniel

> 
> If you need this to be a standard interface across drivers, IMO it
> should be added in common drm code, not sprinkled around in drivers.
> 
> I see that amd is already using this in what is basically drm core
> debugfs namespace, and there's amd specific IGT built on top.
> 
> Adding a bunch of Cc's to get some clarity on drm debugfs naming and
> usage.
> 
> 
> BR,
> Jani.
> 
> 
> >
> > - Bhanu
> >
> >> 
> >> BR,
> >> Jani.
> >> 
> >>> +
> >>>   /**
> >>>* intel_connector_debugfs_add - add i915 specific 

Re: [PATCH] drm/scheduler: quieten kernel-doc warnings

[Andrey Grodzovsky]

Seems to me better this way to avoid merge conflicts ?

Andrey

On 2022-04-04 11:33, Randy Dunlap wrote:



On 4/4/22 07:34, Andrey Grodzovsky wrote:

On 2022-04-04 00:25, Randy Dunlap wrote:

Fix kernel-doc warnings in gpu_scheduler.h and sched_main.c.

Quashes these warnings:

include/drm/gpu_scheduler.h:316: warning: Function parameter or member 'work' 
not described in 'drm_sched_job'


Looks good to me except one point is that I already commited a fix for the 
above warning to drm-misc-next.



OK. Do I need to send a v2 without the header file fix?

thanks.




include/drm/gpu_scheduler.h:332: warning: missing initial short description on 
line:
   * struct drm_sched_backend_ops
include/drm/gpu_scheduler.h:412: warning: missing initial short description on 
line:
   * struct drm_gpu_scheduler

include/drm/gpu_scheduler.h:461: warning: Function parameter or member 'dev' 
not described in 'drm_gpu_scheduler'
drivers/gpu/drm/scheduler/sched_main.c:201: warning: missing initial short 
description on line:
   * drm_sched_dependency_optimized
drivers/gpu/drm/scheduler/sched_main.c:995: warning: Function parameter or 
member 'dev' not described in 'drm_sched_init'

Fixes: 2d33948e4e00 ("drm/scheduler: add documentation")
Fixes: 8ab62eda177b ("drm/sched: Add device pointer to drm_gpu_scheduler")
Fixes: 542cff7893a3 ("drm/sched: Avoid lockdep spalt on killing a processes")
Signed-off-by: Randy Dunlap 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Andrey Grodzovsky 
Cc: Nayan Deshmukh 
Cc: Alex Deucher 
Cc: Christian König 
Cc: Jiawei Gu 
Cc: dri-devel@lists.freedesktop.org
---
Feel free to make changes or suggest changes...

   drivers/gpu/drm/scheduler/sched_main.c |    3 ++-
   include/drm/gpu_scheduler.h    |   10 ++
   2 files changed, 8 insertions(+), 5 deletions(-)

--- linux-next-20220401.orig/drivers/gpu/drm/scheduler/sched_main.c
+++ linux-next-20220401/drivers/gpu/drm/scheduler/sched_main.c
@@ -198,7 +198,7 @@ static void drm_sched_job_done_cb(struct
   }
     /**
- * drm_sched_dependency_optimized
+ * drm_sched_dependency_optimized - test if the dependency can be optimized
    *
    * @fence: the dependency fence
    * @entity: the entity which depends on the above fence
@@ -984,6 +984,7 @@ static int drm_sched_main(void *param)
    *    used
    * @score: optional score atomic shared with other schedulers
    * @name: name used for debugging
+ * @dev: target  device
    *
    * Return 0 on success, otherwise error code.
    */
--- linux-next-20220401.orig/include/drm/gpu_scheduler.h
+++ linux-next-20220401/include/drm/gpu_scheduler.h
@@ -270,6 +270,7 @@ struct drm_sched_fence *to_drm_sched_fen
    * @sched: the scheduler instance on which this job is scheduled.
    * @s_fence: contains the fences for the scheduling of job.
    * @finish_cb: the callback for the finished fence.
+ * @work: scheduler work queue
    * @id: a unique id assigned to each job scheduled on the scheduler.
    * @karma: increment on every hang caused by this job. If this exceeds the 
hang
    * limit of the scheduler then the job is marked guilty and will not
@@ -328,10 +329,10 @@ enum drm_gpu_sched_stat {
   };
     /**
- * struct drm_sched_backend_ops
+ * struct drm_sched_backend_ops - Define the backend operations
+ *    called by the scheduler
    *
- * Define the backend operations called by the scheduler,
- * these functions should be implemented in driver side.
+ * These functions should be implemented in the driver side.
    */
   struct drm_sched_backend_ops {
   /**
@@ -408,7 +409,7 @@ struct drm_sched_backend_ops {
   };
     /**
- * struct drm_gpu_scheduler
+ * struct drm_gpu_scheduler - scheduler instance-specific data
    *
    * @ops: backend operations provided by the driver.
    * @hw_submission_limit: the max size of the hardware queue.
@@ -434,6 +435,7 @@ struct drm_sched_backend_ops {
    * @_score: score used when the driver doesn't provide one
    * @ready: marks if the underlying HW is ready to work
    * @free_guilty: A hit to time out handler to free the guilty job.
+ * @dev: system  device
    *
    * One scheduler is implemented for each hardware ring.
    */

Re: [PATCH 1/3] drm/vmwgfx: Add debugfs entries for ttm placements

[Daniel Vetter]

On Fri, Apr 01, 2022 at 04:56:00PM -0400, Zack Rusin wrote:
> From: Zack Rusin 
> 
> Add a few debugfs entries for every used TTM placement that vmwgfx is
> using. This allows basic tracking of memory usage inside vmwgfx, e.g.
> 'cat /sys/kernel/debug/dri/0/mob_ttm' will display mob memory usage.
> 
> Signed-off-by: Zack Rusin 
> Reviewed-by: Martin Krastev 
> ---
>  drivers/gpu/drm/vmwgfx/vmwgfx_drv.c|  1 +
>  drivers/gpu/drm/vmwgfx/vmwgfx_drv.h|  1 +
>  drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 97 +-
>  3 files changed, 98 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> index 791f9a5f3868..6d675855f065 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> @@ -1632,6 +1632,7 @@ static int vmw_probe(struct pci_dev *pdev, const struct 
> pci_device_id *ent)
>   goto out_unload;
>  
>   vmw_debugfs_gem_init(vmw);
> + vmw_ttm_debugfs_init(vmw);
>  
>   return 0;
>  out_unload:
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> index be19aa6e1f13..eabe3e8e9cf9 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> @@ -1085,6 +1085,7 @@ vmw_bo_sg_table(struct ttm_buffer_object *bo);
>  extern int vmw_bo_create_and_populate(struct vmw_private *dev_priv,
> unsigned long bo_size,
> struct ttm_buffer_object **bo_p);
> +void vmw_ttm_debugfs_init(struct vmw_private *vdev);
>  
>  extern void vmw_piter_start(struct vmw_piter *viter,
>   const struct vmw_sg_table *vsgt,
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
> index b84ecc6d6611..355414595e52 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
> @@ -1,7 +1,7 @@
>  // SPDX-License-Identifier: GPL-2.0 OR MIT
>  /**
>   *
> - * Copyright 2009-2015 VMware, Inc., Palo Alto, CA., USA
> + * Copyright 2009-2022 VMware, Inc., Palo Alto, CA., USA
>   *
>   * Permission is hereby granted, free of charge, to any person obtaining a
>   * copy of this software and associated documentation files (the
> @@ -677,3 +677,98 @@ int vmw_bo_create_and_populate(struct vmw_private 
> *dev_priv,
>   *bo_p = bo;
>   return ret;
>  }
> +
> +#if defined(CONFIG_DEBUG_FS)
> +
> +static int vmw_ttm_vram_table_show(struct seq_file *m, void *unused)
> +{
> + struct vmw_private *vdev = (struct vmw_private *)m->private;
> + struct ttm_resource_manager *man = ttm_manager_type(>bdev,
> + TTM_PL_VRAM);
> + struct drm_printer p = drm_seq_file_printer(m);
> +
> + ttm_resource_manager_debug(man, );
> + return 0;
> +}
> +
> +static int vmw_ttm_page_pool_show(struct seq_file *m, void *unused)
> +{
> + struct vmw_private *vdev = (struct vmw_private *)m->private;
> +
> + return ttm_pool_debugfs(>bdev.pool, m);
> +}
> +
> +static int vmw_ttm_mob_table_show(struct seq_file *m, void *unused)
> +{
> + struct vmw_private *vdev = (struct vmw_private *)m->private;
> + struct ttm_resource_manager *man = ttm_manager_type(>bdev,
> + VMW_PL_MOB);
> + struct drm_printer p = drm_seq_file_printer(m);
> +
> + ttm_resource_manager_debug(man, );
> + return 0;
> +}
> +
> +static int vmw_ttm_gmr_table_show(struct seq_file *m, void *unused)
> +{
> + struct vmw_private *vdev = (struct vmw_private *)m->private;
> + struct ttm_resource_manager *man = ttm_manager_type(>bdev,
> + VMW_PL_GMR);
> + struct drm_printer p = drm_seq_file_printer(m);
> +
> + ttm_resource_manager_debug(man, );
> + return 0;
> +}
> +
> +static int vmw_ttm_system_table_show(struct seq_file *m, void *unused)
> +{
> + struct vmw_private *vdev = (struct vmw_private *)m->private;
> + struct ttm_resource_manager *man = ttm_manager_type(>bdev,
> + TTM_PL_SYSTEM);
> + struct drm_printer p = drm_seq_file_printer(m);
> +
> + ttm_resource_manager_debug(man, );
> + return 0;
> +}
> +
> +static int vmw_ttm_system_mob_table_show(struct seq_file *m, void *unused)
> +{
> + struct vmw_private *vdev = (struct vmw_private *)m->private;
> + struct ttm_resource_manager *man = ttm_manager_type(>bdev,
> + VMW_PL_SYSTEM);
> + struct drm_printer p = drm_seq_file_printer(m);
> +
> + ttm_resource_manager_debug(man, );
> + return 0;
> +}
> +
> +DEFINE_SHOW_ATTRIBUTE(vmw_ttm_vram_table);
> +DEFINE_SHOW_ATTRIBUTE(vmw_ttm_mob_table);
> 

Re: [Intel-gfx] [CI 8/8] drm/i915: Expose client engine utilisation via fdinfo

[Daniel Vetter]

On Mon, Apr 04, 2022 at 10:23:53AM +0100, Tvrtko Ursulin wrote:
> 
> + Dave and Daniel
> 
> Guys, are you okay with merging this via drm-intel-gt-next? It is one new
> file at Documentation/gpu/drm-usage-stats.rst only which is outside i915. It
> has acks from Christian and Rob.

Acked-by: Daniel Vetter 

> 
> Daniel, series is also fully reviewed and IGT reviewed and ready. Rob also
> demonstrated the approach works for msm when using the vendor agnosstic
> gputop tool I sketched out (see
> 20220225202614.225197-3-robdcl...@gmail.com).
> 
> My plan is to merge the i915 support with the common spec and intel_gpu_top
> on the IGT side. Then follow-up with vendor agnostic gputop and later yet
> potentially re-visit the AMD side by re-sending the patch which tweaks the
> fdinfo format there and adds support for relative engine utilisation as
> provided by amdgpu.
> 
> Regards,
> 
> Tvrtko
> 
> On 04/04/2022 10:12, Tvrtko Ursulin wrote:
> > 
> > On 01/04/2022 15:22, Tvrtko Ursulin wrote:
> > > From: Tvrtko Ursulin 
> > > 
> > > Similar to AMD commit
> > > 874442541133 ("drm/amdgpu: Add show_fdinfo() interface"), using the
> > > infrastructure added in previous patches, we add basic client info
> > > and GPU engine utilisation for i915.
> > > 
> > > Example of the output:
> > > 
> > >    pos:    0
> > >    flags:  012
> > >    mnt_id: 21
> > >    drm-driver: i915
> > >    drm-pdev:   :00:02.0
> > >    drm-client-id:  7
> > >    drm-engine-render:  9288864723 ns
> > >    drm-engine-copy:    2035071108 ns
> > >    drm-engine-video:   0 ns
> > >    drm-engine-video-enhance:   0 ns
> > > 
> > > v2:
> > >   * Update for removal of name and pid.
> > > 
> > > v3:
> > >   * Use drm_driver.name.
> > > 
> > > v4:
> > >   * Added drm-engine-capacity- tag.
> > >   * Fix typo. (Umesh)
> > > 
> > > v5:
> > >   * Don't output engine data before Gen8.
> > > 
> > > Signed-off-by: Tvrtko Ursulin 
> > > Cc: David M Nieto 
> > > Cc: Christian König 
> > > Cc: Daniel Vetter 
> > > Cc: Chris Healy 
> > > Acked-by: Christian König 
> > > Reviewed-by: Umesh Nerlige Ramappa 
> > 
> > Forgot to apply an earlier:
> > 
> > Acked-by: Rob Clark 
> > 
> > Regards,
> > 
> > Tvrtko
> > 
> > > ---
> > >   Documentation/gpu/drm-usage-stats.rst  |  6 ++
> > >   Documentation/gpu/i915.rst | 28 +
> > >   drivers/gpu/drm/i915/i915_driver.c |  3 +
> > >   drivers/gpu/drm/i915/i915_drm_client.c | 84 ++
> > >   drivers/gpu/drm/i915/i915_drm_client.h |  4 ++
> > >   5 files changed, 125 insertions(+)
> > > 
> > > diff --git a/Documentation/gpu/drm-usage-stats.rst
> > > b/Documentation/gpu/drm-usage-stats.rst
> > > index b8cc28f4da6f..6c9f166a8d6f 100644
> > > --- a/Documentation/gpu/drm-usage-stats.rst
> > > +++ b/Documentation/gpu/drm-usage-stats.rst
> > > @@ -104,3 +104,9 @@ object belong to this client, in the respective
> > > memory region.
> > >   Default unit shall be bytes with optional unit specifiers of 'KiB'
> > > or 'MiB'
> > >   indicating kibi- or mebi-bytes.
> > > +
> > > +===
> > > +Driver specific implementations
> > > +===
> > > +
> > > +:ref:`i915-usage-stats`
> > > diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
> > > index 0f08693d05cd..54060cd6c419 100644
> > > --- a/Documentation/gpu/i915.rst
> > > +++ b/Documentation/gpu/i915.rst
> > > @@ -697,3 +697,31 @@ The style guide for ``i915_reg.h``.
> > >   .. kernel-doc:: drivers/gpu/drm/i915/i915_reg.h
> > >  :doc: The i915 register macro definition style guide
> > > +
> > > +.. _i915-usage-stats:
> > > +
> > > +i915 DRM client usage stats implementation
> > > +==
> > > +
> > > +The drm/i915 driver implements the DRM client usage stats
> > > specification as
> > > +documented in :ref:`drm-client-usage-stats`.
> > > +
> > > +Example of the output showing the implemented key value pairs and
> > > entirety of
> > > +the currently possible format options:
> > > +
> > > +::
> > > +
> > > +  pos:    0
> > > +  flags:  012
> > > +  mnt_id: 21
> > > +  drm-driver: i915
> > > +  drm-pdev:   :00:02.0
> > > +  drm-client-id:  7
> > > +  drm-engine-render:  9288864723 ns
> > > +  drm-engine-copy:    2035071108 ns
> > > +  drm-engine-video:   0 ns
> > > +  drm-engine-capacity-video:   2
> > > +  drm-engine-video-enhance:   0 ns
> > > +
> > > +Possible `drm-engine-` key names are: `render`, `copy`, `video` and
> > > +`video-enhance`.
> > > diff --git a/drivers/gpu/drm/i915/i915_driver.c
> > > b/drivers/gpu/drm/i915/i915_driver.c
> > > index b2df273e6d7b..3ffb617d75c9 100644
> > > --- a/drivers/gpu/drm/i915/i915_driver.c
> > > +++ b/drivers/gpu/drm/i915/i915_driver.c
> > > @@ -1745,6 +1745,9 @@ static const struct file_operations
> > > i915_driver_fops = {
> > >   .read = drm_read,
> > >   .compat_ioctl = i915_ioc32_compat_ioctl,
> > >   .llseek = 

Re: [PATCH 2/4] drm/gem: Delete gem array fencing helpers

[Daniel Vetter]

On Mon, Apr 04, 2022 at 03:30:59PM +0200, Christian König wrote:
> Am 04.04.22 um 15:15 schrieb Daniel Vetter:
> > On Thu, Mar 31, 2022 at 10:46:49PM +0200, Daniel Vetter wrote:
> > > Integrated into the scheduler now and all users converted over.
> > > 
> > > v2: Rebased over changes from König.
> > > 
> > > Signed-off-by: Daniel Vetter 
> > > Cc: Maarten Lankhorst 
> > > Cc: Maxime Ripard 
> > > Cc: Thomas Zimmermann 
> > > Cc: David Airlie 
> > > Cc: Daniel Vetter 
> > > Cc: Sumit Semwal 
> > > Cc: "Christian König" 
> > > Cc: linux-me...@vger.kernel.org
> > > Cc: linaro-mm-...@lists.linaro.org
> > Anyone up for an ack for this one here?
> 
> Acked-by: Christian König 
> 
> Please land that ASAP so that I can rebase on top.

First 3 patches pushed, I'll drop the fourth.
-Daniel

> 
> Thanks,
> Christian.
> 
> > 
> > Thanks, Daniel
> > 
> > > ---
> > >   drivers/gpu/drm/drm_gem.c | 80 ---
> > >   include/drm/drm_gem.h |  5 ---
> > >   2 files changed, 85 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> > > index 56fb87885146..133dfae06fab 100644
> > > --- a/drivers/gpu/drm/drm_gem.c
> > > +++ b/drivers/gpu/drm/drm_gem.c
> > > @@ -1273,83 +1273,3 @@ drm_gem_unlock_reservations(struct drm_gem_object 
> > > **objs, int count,
> > >   ww_acquire_fini(acquire_ctx);
> > >   }
> > >   EXPORT_SYMBOL(drm_gem_unlock_reservations);
> > > -
> > > -/**
> > > - * drm_gem_fence_array_add - Adds the fence to an array of fences to be
> > > - * waited on, deduplicating fences from the same context.
> > > - *
> > > - * @fence_array: array of dma_fence * for the job to block on.
> > > - * @fence: the dma_fence to add to the list of dependencies.
> > > - *
> > > - * This functions consumes the reference for @fence both on success and 
> > > error
> > > - * cases.
> > > - *
> > > - * Returns:
> > > - * 0 on success, or an error on failing to expand the array.
> > > - */
> > > -int drm_gem_fence_array_add(struct xarray *fence_array,
> > > - struct dma_fence *fence)
> > > -{
> > > - struct dma_fence *entry;
> > > - unsigned long index;
> > > - u32 id = 0;
> > > - int ret;
> > > -
> > > - if (!fence)
> > > - return 0;
> > > -
> > > - /* Deduplicate if we already depend on a fence from the same context.
> > > -  * This lets the size of the array of deps scale with the number of
> > > -  * engines involved, rather than the number of BOs.
> > > -  */
> > > - xa_for_each(fence_array, index, entry) {
> > > - if (entry->context != fence->context)
> > > - continue;
> > > -
> > > - if (dma_fence_is_later(fence, entry)) {
> > > - dma_fence_put(entry);
> > > - xa_store(fence_array, index, fence, GFP_KERNEL);
> > > - } else {
> > > - dma_fence_put(fence);
> > > - }
> > > - return 0;
> > > - }
> > > -
> > > - ret = xa_alloc(fence_array, , fence, xa_limit_32b, GFP_KERNEL);
> > > - if (ret != 0)
> > > - dma_fence_put(fence);
> > > -
> > > - return ret;
> > > -}
> > > -EXPORT_SYMBOL(drm_gem_fence_array_add);
> > > -
> > > -/**
> > > - * drm_gem_fence_array_add_implicit - Adds the implicit dependencies 
> > > tracked
> > > - * in the GEM object's reservation object to an array of dma_fences for 
> > > use in
> > > - * scheduling a rendering job.
> > > - *
> > > - * This should be called after drm_gem_lock_reservations() on your array 
> > > of
> > > - * GEM objects used in the job but before updating the reservations with 
> > > your
> > > - * own fences.
> > > - *
> > > - * @fence_array: array of dma_fence * for the job to block on.
> > > - * @obj: the gem object to add new dependencies from.
> > > - * @write: whether the job might write the object (so we need to depend 
> > > on
> > > - * shared fences in the reservation object).
> > > - */
> > > -int drm_gem_fence_array_add_implicit(struct xarray *fence_array,
> > > -  struct drm_gem_object *obj,
> > > -  bool write)
> > > -{
> > > - struct dma_resv_iter cursor;
> > > - struct dma_fence *fence;
> > > - int ret = 0;
> > > -
> > > - dma_resv_for_each_fence(, obj->resv, write, fence) {
> > > - ret = drm_gem_fence_array_add(fence_array, fence);
> > > - if (ret)
> > > - break;
> > > - }
> > > - return ret;
> > > -}
> > > -EXPORT_SYMBOL(drm_gem_fence_array_add_implicit);
> > > diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
> > > index e2941cee14b6..9d7c61a122dc 100644
> > > --- a/include/drm/drm_gem.h
> > > +++ b/include/drm/drm_gem.h
> > > @@ -407,11 +407,6 @@ int drm_gem_lock_reservations(struct drm_gem_object 
> > > **objs, int count,
> > > struct ww_acquire_ctx *acquire_ctx);
> > >   void drm_gem_unlock_reservations(struct drm_gem_object **objs, int 
> > > count,
> > >struct ww_acquire_ctx 

Re: [PATCH] drm/scheduler: quieten kernel-doc warnings

[Randy Dunlap]

On 4/4/22 07:34, Andrey Grodzovsky wrote:
> On 2022-04-04 00:25, Randy Dunlap wrote:
>> Fix kernel-doc warnings in gpu_scheduler.h and sched_main.c.
>>
>> Quashes these warnings:
>>
>> include/drm/gpu_scheduler.h:316: warning: Function parameter or member 
>> 'work' not described in 'drm_sched_job'
> 
> Looks good to me except one point is that I already commited a fix for the 
> above warning to drm-misc-next.
> 

OK. Do I need to send a v2 without the header file fix?

thanks.

> 
>> include/drm/gpu_scheduler.h:332: warning: missing initial short description 
>> on line:
>>   * struct drm_sched_backend_ops
>> include/drm/gpu_scheduler.h:412: warning: missing initial short description 
>> on line:
>>   * struct drm_gpu_scheduler
>>
>> include/drm/gpu_scheduler.h:461: warning: Function parameter or member 'dev' 
>> not described in 'drm_gpu_scheduler'
>> drivers/gpu/drm/scheduler/sched_main.c:201: warning: missing initial short 
>> description on line:
>>   * drm_sched_dependency_optimized
>> drivers/gpu/drm/scheduler/sched_main.c:995: warning: Function parameter or 
>> member 'dev' not described in 'drm_sched_init'
>>
>> Fixes: 2d33948e4e00 ("drm/scheduler: add documentation")
>> Fixes: 8ab62eda177b ("drm/sched: Add device pointer to drm_gpu_scheduler")
>> Fixes: 542cff7893a3 ("drm/sched: Avoid lockdep spalt on killing a processes")
>> Signed-off-by: Randy Dunlap 
>> Cc: David Airlie 
>> Cc: Daniel Vetter 
>> Cc: Andrey Grodzovsky 
>> Cc: Nayan Deshmukh 
>> Cc: Alex Deucher 
>> Cc: Christian König 
>> Cc: Jiawei Gu 
>> Cc: dri-devel@lists.freedesktop.org
>> ---
>> Feel free to make changes or suggest changes...
>>
>>   drivers/gpu/drm/scheduler/sched_main.c |    3 ++-
>>   include/drm/gpu_scheduler.h    |   10 ++
>>   2 files changed, 8 insertions(+), 5 deletions(-)
>>
>> --- linux-next-20220401.orig/drivers/gpu/drm/scheduler/sched_main.c
>> +++ linux-next-20220401/drivers/gpu/drm/scheduler/sched_main.c
>> @@ -198,7 +198,7 @@ static void drm_sched_job_done_cb(struct
>>   }
>>     /**
>> - * drm_sched_dependency_optimized
>> + * drm_sched_dependency_optimized - test if the dependency can be optimized
>>    *
>>    * @fence: the dependency fence
>>    * @entity: the entity which depends on the above fence
>> @@ -984,6 +984,7 @@ static int drm_sched_main(void *param)
>>    *    used
>>    * @score: optional score atomic shared with other schedulers
>>    * @name: name used for debugging
>> + * @dev: target  device
>>    *
>>    * Return 0 on success, otherwise error code.
>>    */
>> --- linux-next-20220401.orig/include/drm/gpu_scheduler.h
>> +++ linux-next-20220401/include/drm/gpu_scheduler.h
>> @@ -270,6 +270,7 @@ struct drm_sched_fence *to_drm_sched_fen
>>    * @sched: the scheduler instance on which this job is scheduled.
>>    * @s_fence: contains the fences for the scheduling of job.
>>    * @finish_cb: the callback for the finished fence.
>> + * @work: scheduler work queue
>>    * @id: a unique id assigned to each job scheduled on the scheduler.
>>    * @karma: increment on every hang caused by this job. If this exceeds the 
>> hang
>>    * limit of the scheduler then the job is marked guilty and will 
>> not
>> @@ -328,10 +329,10 @@ enum drm_gpu_sched_stat {
>>   };
>>     /**
>> - * struct drm_sched_backend_ops
>> + * struct drm_sched_backend_ops - Define the backend operations
>> + *    called by the scheduler
>>    *
>> - * Define the backend operations called by the scheduler,
>> - * these functions should be implemented in driver side.
>> + * These functions should be implemented in the driver side.
>>    */
>>   struct drm_sched_backend_ops {
>>   /**
>> @@ -408,7 +409,7 @@ struct drm_sched_backend_ops {
>>   };
>>     /**
>> - * struct drm_gpu_scheduler
>> + * struct drm_gpu_scheduler - scheduler instance-specific data
>>    *
>>    * @ops: backend operations provided by the driver.
>>    * @hw_submission_limit: the max size of the hardware queue.
>> @@ -434,6 +435,7 @@ struct drm_sched_backend_ops {
>>    * @_score: score used when the driver doesn't provide one
>>    * @ready: marks if the underlying HW is ready to work
>>    * @free_guilty: A hit to time out handler to free the guilty job.
>> + * @dev: system  device
>>    *
>>    * One scheduler is implemented for each hardware ring.
>>    */

-- 
~Randy

Re: [PATCH] drm/amd/display: cleanup extern usage in function definition

[Harry Wentland]

On 2022-04-03 10:21, Tom Rix wrote:
> Smatch reports this issue
> hdcp1_execution.c:500:29: warning: function
>   'mod_hdcp_hdcp1_dp_execution' with external linkage
>   has definition
> 

Which branch are you using?

I don't see the 'extern' on
https://gitlab.freedesktop.org/agd5f/linux/-/blob/amd-staging-drm-next/drivers/gpu/drm/amd/display/modules/hdcp/hdcp1_execution.c

Harry


> The storage-class-specifier extern is not needed in a
> definition, so remove it.
> 
> Signed-off-by: Tom Rix 
> ---
>  drivers/gpu/drm/amd/display/modules/hdcp/hdcp1_execution.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/modules/hdcp/hdcp1_execution.c 
> b/drivers/gpu/drm/amd/display/modules/hdcp/hdcp1_execution.c
> index 6ec918af3bff..1ddb4f5eac8e 100644
> --- a/drivers/gpu/drm/amd/display/modules/hdcp/hdcp1_execution.c
> +++ b/drivers/gpu/drm/amd/display/modules/hdcp/hdcp1_execution.c
> @@ -497,9 +497,9 @@ enum mod_hdcp_status mod_hdcp_hdcp1_execution(struct 
> mod_hdcp *hdcp,
>   return status;
>  }
>  
> -extern enum mod_hdcp_status mod_hdcp_hdcp1_dp_execution(struct mod_hdcp 
> *hdcp,
> - struct mod_hdcp_event_context *event_ctx,
> - struct mod_hdcp_transition_input_hdcp1 *input)
> +enum mod_hdcp_status mod_hdcp_hdcp1_dp_execution(struct mod_hdcp *hdcp,
> +  struct mod_hdcp_event_context 
> *event_ctx,
> +  struct 
> mod_hdcp_transition_input_hdcp1 *input)
>  {
>   enum mod_hdcp_status status = MOD_HDCP_STATUS_SUCCESS;
>  

Re: [PATCH 2/4] dt-bindings: display: ssd1307fb: Add entry for SINO WEALTH SH1106

[Chen-Yu Tsai]

On Fri, Apr 1, 2022 at 5:32 PM Javier Martinez Canillas
 wrote:
>
> Hello Chen-Yu,
>
> Thanks a lot for your patch.
>
> On Wed, Mar 30, 2022 at 9:09 PM Chen-Yu Tsai  wrote:
> >
> > From: Chen-Yu Tsai 
> >
> > The SINO WEALTH SH1106 is an OLED display driver that is somewhat
> > compatible with the SSD1306. It supports a slightly wider display,
> > at 132 instead of 128 pixels. The basic commands are the same, but
> > the SH1106 doesn't support the horizontal or vertical address modes.
> >
> > Add a compatible string for it.
> >
> > Signed-off-by: Chen-Yu Tsai 
> > ---
> >  Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git 
> > a/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml 
> > b/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml
> > index 9baafd0c42dd..1ac016a2d847 100644
> > --- a/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml
> > +++ b/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml
> > @@ -13,6 +13,7 @@ maintainers:
> >  properties:
> >compatible:
> >  enum:
> > +  - sinowealth,sh1106-i2c
>
> I like that you didn't include a "fb" suffix for this, the existing
> ones are cargo culting from the previous fbdev driver to make existing
> DTBs compatible with the DRM driver.
>
> I've been thinking if I should post a patch to compatible strings
> without the "fb" and mark the current ones as deprecated...
>
> Reviewed-by: Javier Martinez Canillas 

I also thought about dropping the "-i2c" suffix, but then thought
there might be a case where someone wanted to search the device
tree specifically for an I2C connected node using said compatible
string.

What do you think?


ChenYu

Re: [PATCH] drm/scheduler: quieten kernel-doc warnings

[Andrey Grodzovsky]

On 2022-04-04 00:25, Randy Dunlap wrote:

Fix kernel-doc warnings in gpu_scheduler.h and sched_main.c.

Quashes these warnings:

include/drm/gpu_scheduler.h:316: warning: Function parameter or member 'work' 
not described in 'drm_sched_job'


Looks good to me except one point is that I already commited a fix for 
the above warning to drm-misc-next.


Andrey


include/drm/gpu_scheduler.h:332: warning: missing initial short description on 
line:
  * struct drm_sched_backend_ops
include/drm/gpu_scheduler.h:412: warning: missing initial short description on 
line:
  * struct drm_gpu_scheduler

include/drm/gpu_scheduler.h:461: warning: Function parameter or member 'dev' 
not described in 'drm_gpu_scheduler'
drivers/gpu/drm/scheduler/sched_main.c:201: warning: missing initial short 
description on line:
  * drm_sched_dependency_optimized
drivers/gpu/drm/scheduler/sched_main.c:995: warning: Function parameter or 
member 'dev' not described in 'drm_sched_init'

Fixes: 2d33948e4e00 ("drm/scheduler: add documentation")
Fixes: 8ab62eda177b ("drm/sched: Add device pointer to drm_gpu_scheduler")
Fixes: 542cff7893a3 ("drm/sched: Avoid lockdep spalt on killing a processes")
Signed-off-by: Randy Dunlap 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Andrey Grodzovsky 
Cc: Nayan Deshmukh 
Cc: Alex Deucher 
Cc: Christian König 
Cc: Jiawei Gu 
Cc: dri-devel@lists.freedesktop.org
---
Feel free to make changes or suggest changes...

  drivers/gpu/drm/scheduler/sched_main.c |3 ++-
  include/drm/gpu_scheduler.h|   10 ++
  2 files changed, 8 insertions(+), 5 deletions(-)

--- linux-next-20220401.orig/drivers/gpu/drm/scheduler/sched_main.c
+++ linux-next-20220401/drivers/gpu/drm/scheduler/sched_main.c
@@ -198,7 +198,7 @@ static void drm_sched_job_done_cb(struct
  }
  
  /**

- * drm_sched_dependency_optimized
+ * drm_sched_dependency_optimized - test if the dependency can be optimized
   *
   * @fence: the dependency fence
   * @entity: the entity which depends on the above fence
@@ -984,6 +984,7 @@ static int drm_sched_main(void *param)
   *used
   * @score: optional score atomic shared with other schedulers
   * @name: name used for debugging
+ * @dev: target  device
   *
   * Return 0 on success, otherwise error code.
   */
--- linux-next-20220401.orig/include/drm/gpu_scheduler.h
+++ linux-next-20220401/include/drm/gpu_scheduler.h
@@ -270,6 +270,7 @@ struct drm_sched_fence *to_drm_sched_fen
   * @sched: the scheduler instance on which this job is scheduled.
   * @s_fence: contains the fences for the scheduling of job.
   * @finish_cb: the callback for the finished fence.
+ * @work: scheduler work queue
   * @id: a unique id assigned to each job scheduled on the scheduler.
   * @karma: increment on every hang caused by this job. If this exceeds the 
hang
   * limit of the scheduler then the job is marked guilty and will not
@@ -328,10 +329,10 @@ enum drm_gpu_sched_stat {
  };
  
  /**

- * struct drm_sched_backend_ops
+ * struct drm_sched_backend_ops - Define the backend operations
+ * called by the scheduler
   *
- * Define the backend operations called by the scheduler,
- * these functions should be implemented in driver side.
+ * These functions should be implemented in the driver side.
   */
  struct drm_sched_backend_ops {
/**
@@ -408,7 +409,7 @@ struct drm_sched_backend_ops {
  };
  
  /**

- * struct drm_gpu_scheduler
+ * struct drm_gpu_scheduler - scheduler instance-specific data
   *
   * @ops: backend operations provided by the driver.
   * @hw_submission_limit: the max size of the hardware queue.
@@ -434,6 +435,7 @@ struct drm_sched_backend_ops {
   * @_score: score used when the driver doesn't provide one
   * @ready: marks if the underlying HW is ready to work
   * @free_guilty: A hit to time out handler to free the guilty job.
+ * @dev: system  device
   *
   * One scheduler is implemented for each hardware ring.
   */

Re: [PATCH] drm/radeon: change si_default_state table from global to static

[Tom Rix]

On 4/4/22 6:32 AM, Christian König wrote:

Am 04.04.22 um 15:01 schrieb Tom Rix:

On 4/4/22 5:34 AM, Christian König wrote:

Am 04.04.22 um 14:32 schrieb Tom Rix:

On 4/3/22 8:23 AM, Christian König wrote:

Am 02.04.22 um 18:27 schrieb Tom Rix:

Smatch reports these issues
si_blit_shaders.c:31:11: warning: symbol 'si_default_state'
   was not declared. Should it be static?
si_blit_shaders.c:253:11: warning: symbol 'si_default_size'
   was not declared. Should it be static?

Both symbols are only used in si.c.  Single file symbols
should be static.  So move the si_default_state and
si_default_size to si.c and change their
storage-class-specifier to static.

Remove unneeded si_blit_shaders.[c|h]


Uff, well NAK.

IIRC this was intentionally moved into a separate file because it 
is rather large and not related to anything in si.c.


It's unlikely that we are ever going to update it, but I would 
still rather want to keep it separated.


You should rather just include si_blit_shaders.h in 
si_blit_shaders.c.


Do you mean #include "si_blit_shaders.c" in si.c or similar ?


No, as far as I can see you are getting this warning because of a 
missing previous prototype for the exported array.


This can be avoided if you add si_blit_shaders.h as an include to 
si_blit_shaders.c.


The warning is a symptom.

There are about 5-6 similar big, global tables in radeon/ with 
similar one file uses.


These global tables should become static.

Moving the table to si_blit_shader.h would keep it separated, adding 
the 'static' would remove it from the globals.


*.c removed, Makefile updated.


Sound like that would work for me as well. Main concern is to keep 
that in a separate file.


But why do you want to drop it from globals in the first place?


Generally the least needed access should be used.

For security

https://cwe.mitre.org/data/definitions/1108.html

A big global table can hide introduced code.

For the compiler

global variables (can not/harder to) be optimized.

Tom



Christian.



Tom



Regards,
Christian.



This could have the same effect of while keeping these separate failes

Tom



Regards,
Christian.



Signed-off-by: Tom Rix 
---
  drivers/gpu/drm/radeon/Makefile  |   2 +-
  drivers/gpu/drm/radeon/si.c  | 224 
+++-
  drivers/gpu/drm/radeon/si_blit_shaders.c | 253 
---

  drivers/gpu/drm/radeon/si_blit_shaders.h |  32 ---
  4 files changed, 224 insertions(+), 287 deletions(-)
  delete mode 100644 drivers/gpu/drm/radeon/si_blit_shaders.c
  delete mode 100644 drivers/gpu/drm/radeon/si_blit_shaders.h

diff --git a/drivers/gpu/drm/radeon/Makefile 
b/drivers/gpu/drm/radeon/Makefile

index 11c97edde54d..664381f4eb07 100644
--- a/drivers/gpu/drm/radeon/Makefile
+++ b/drivers/gpu/drm/radeon/Makefile
@@ -44,7 +44,7 @@ radeon-y += radeon_device.o radeon_asic.o 
radeon_kms.o \

  evergreen.o evergreen_cs.o evergreen_blit_shaders.o \
  evergreen_hdmi.o radeon_trace_points.o ni.o 
cayman_blit_shaders.o \
  atombios_encoders.o radeon_semaphore.o radeon_sa.o 
atombios_i2c.o si.o \

-    si_blit_shaders.o radeon_prime.o cik.o cik_blit_shaders.o \
+    radeon_prime.o cik.o cik_blit_shaders.o \
  r600_dpm.o rs780_dpm.o rv6xx_dpm.o rv770_dpm.o rv730_dpm.o 
rv740_dpm.o \
  rv770_smc.o cypress_dpm.o btc_dpm.o sumo_dpm.o sumo_smc.o 
trinity_dpm.o \
  trinity_smc.o ni_dpm.o si_smc.o si_dpm.o kv_smc.o kv_dpm.o 
ci_smc.o \
diff --git a/drivers/gpu/drm/radeon/si.c 
b/drivers/gpu/drm/radeon/si.c

index 8d5e4b25609d..a4032702e302 100644
--- a/drivers/gpu/drm/radeon/si.c
+++ b/drivers/gpu/drm/radeon/si.c
@@ -38,7 +38,6 @@
  #include "radeon_asic.h"
  #include "radeon_audio.h"
  #include "radeon_ucode.h"
-#include "si_blit_shaders.h"
  #include "si.h"
  #include "sid.h"
  @@ -3553,6 +3552,229 @@ static int si_cp_load_microcode(struct 
radeon_device *rdev)

  return 0;
  }
  +static const u32 si_default_state[] = {
+    0xc0066900,
+    0x,
+    0x0060, /* DB_RENDER_CONTROL */
+    0x, /* DB_COUNT_CONTROL */
+    0x, /* DB_DEPTH_VIEW */
+    0x002a, /* DB_RENDER_OVERRIDE */
+    0x, /* DB_RENDER_OVERRIDE2 */
+    0x, /* DB_HTILE_DATA_BASE */
+
+    0xc0046900,
+    0x0008,
+    0x, /* DB_DEPTH_BOUNDS_MIN */
+    0x, /* DB_DEPTH_BOUNDS_MAX */
+    0x, /* DB_STENCIL_CLEAR */
+    0x, /* DB_DEPTH_CLEAR */
+
+    0xc0036900,
+    0x000f,
+    0x, /* DB_DEPTH_INFO */
+    0x, /* DB_Z_INFO */
+    0x, /* DB_STENCIL_INFO */
+
+    0xc0016900,
+    0x0080,
+    0x, /* PA_SC_WINDOW_OFFSET */
+
+    0xc00d6900,
+    0x0083,
+    0x, /* PA_SC_CLIPRECT_RULE */
+    0x, /* PA_SC_CLIPRECT_0_TL */
+    0x20002000, /* PA_SC_CLIPRECT_0_BR */
+    0x,
+    0x20002000,
+    0x,
+    0x20002000,
+    0x,
+    0x20002000,
+    0x, /* PA_SC_EDGERULE */
+    0x, /* 

RE: [PATCH v6 6/8] drm/msm/dp: remove unnecessary delay during boot

[Sankeerth Billakanti (QUIC)]

Hi Doug,

> On Wed, Mar 30, 2022 at 9:04 AM Sankeerth Billakanti
>  wrote:
> >
> > Remove the unnecessary delay in executing the EV_HPD_INIT_SETUP
> event.
> 
> Tell me more and put it in the commit message! Why did it used to be
> necessary and why is it no longer necessary? Inquiring minds want to know.
>

Okay. I will add proper description. The DP phy is shared with usb and 
executing the
dp phy_init before the usb phy_init was causing usb devices to not function.

Earlier, enabling phy_init was done when the EV_HPD_INIT_SETUP event was 
executed.
So, we had scheduled it to execute after 10 second to let the usb driver 
complete the phy_init first.

Kuogee made the below change to move the DP phy_init to execute after the DP is 
connected
https://patchwork.kernel.org/project/linux-arm-msm/patch/1642531648-8448-2-git-send-email-quic_khs...@quicinc.com/

So, there is no need for the DP driver to wait 10 seconds for the phy 
initialization anymore.

eDP PHY is not shared with usb. So, it can be programmed anytime, hence not 
needing any delay.

> -Doug

Thank you,
Sankeerth

[PATCH 3/4] drm/fourcc: Introduce format modifier for DG2 clear color

[Imre Deak]

From: Mika Kahola 

DG2 clear color render compression uses Tile4 layout. Therefore, we need
to define a new format modifier for uAPI to support clear color rendering.

v2:
  Display version is fixed. [Imre]
  KDoc is enhanced for cc modifier. [Nanley & Lionel]
v3:
  Split out the modifier addition to a separate patch.
  Clarify the modifier layout description.

Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Mika Kahola 
cc: Anshuman Gupta 
Signed-off-by: Juha-Pekka Heikkilä 
Signed-off-by: Ramalingam C 
Signed-off-by: Imre Deak 
Acked-by: Nanley Chery 
---
 include/uapi/drm/drm_fourcc.h | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 4a5117715db3c..e5074162bcdd4 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -605,6 +605,20 @@ extern "C" {
  */
 #define I915_FORMAT_MOD_4_TILED_DG2_MC_CCS fourcc_mod_code(INTEL, 11)
 
+/*
+ * Intel Color Control Surface with Clear Color (CCS) for DG2 render 
compression.
+ *
+ * The main surface is Tile 4 and at plane index 0. The CCS data is stored
+ * outside of the GEM object in a reserved memory area dedicated for the
+ * storage of the CCS data for all RC/RC_CC/MC compressible GEM objects. The
+ * main surface pitch is required to be a multiple of four Tile 4 widths. The
+ * clear color is stored at plane index 1 and the pitch should be ignored. The
+ * format of the 256 bits of clear color data matches the one used for the
+ * I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS_CC modifier, see its description
+ * for details.
+ */
+#define I915_FORMAT_MOD_4_TILED_DG2_RC_CCS_CC fourcc_mod_code(INTEL, 12)
+
 /*
  * Tiled, NV12MT, grouped in 64 (pixels) x 32 (lines) -sized macroblocks
  *
-- 
2.30.2

[PATCH 1/4] drm/fourcc: Introduce format modifiers for DG2 render and media compression

[Imre Deak]

From: Matt Roper 

The render/media engines on DG2 unify render compression and media
compression into a single format for the first time, using the Tile 4
layout for main surfaces. The compression algorithm is different from
any previous platform and the display engine must still be configured to
decompress either a render or media compressed surface; as such, we
need new RC and MC framebuffer modifiers to represent buffers in this
format.

v2: Clarify modifier layout description.

Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Matt Roper 
Signed-off-by: Imre Deak 
Acked-by: Nanley Chery 
---
 include/uapi/drm/drm_fourcc.h | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index b73fe6797fc37..4a5117715db3c 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -583,6 +583,28 @@ extern "C" {
  */
 #define I915_FORMAT_MOD_4_TILED fourcc_mod_code(INTEL, 9)
 
+/*
+ * Intel color control surfaces (CCS) for DG2 render compression.
+ *
+ * The main surface is Tile 4 and at plane index 0. The CCS data is stored
+ * outside of the GEM object in a reserved memory area dedicated for the
+ * storage of the CCS data for all RC/RC_CC/MC compressible GEM objects. The
+ * main surface pitch is required to be a multiple of four Tile 4 widths.
+ */
+#define I915_FORMAT_MOD_4_TILED_DG2_RC_CCS fourcc_mod_code(INTEL, 10)
+
+/*
+ * Intel color control surfaces (CCS) for DG2 media compression.
+ *
+ * The main surface is Tile 4 and at plane index 0. For semi-planar formats
+ * like NV12, the Y and UV planes are Tile 4 and are located at plane indices
+ * 0 and 1, respectively. The CCS for all planes are stored outside of the
+ * GEM object in a reserved memory area dedicated for the storage of the
+ * CCS data for all RC/RC_CC/MC compressible GEM objects. The main surface
+ * pitch is required to be a multiple of four Tile 4 widths.
+ */
+#define I915_FORMAT_MOD_4_TILED_DG2_MC_CCS fourcc_mod_code(INTEL, 11)
+
 /*
  * Tiled, NV12MT, grouped in 64 (pixels) x 32 (lines) -sized macroblocks
  *
-- 
2.30.2

Re: [PATCH] drm/radeon: change si_default_state table from global to static

[Christian König]

Am 04.04.22 um 15:01 schrieb Tom Rix:

On 4/4/22 5:34 AM, Christian König wrote:

Am 04.04.22 um 14:32 schrieb Tom Rix:

On 4/3/22 8:23 AM, Christian König wrote:

Am 02.04.22 um 18:27 schrieb Tom Rix:

Smatch reports these issues
si_blit_shaders.c:31:11: warning: symbol 'si_default_state'
   was not declared. Should it be static?
si_blit_shaders.c:253:11: warning: symbol 'si_default_size'
   was not declared. Should it be static?

Both symbols are only used in si.c.  Single file symbols
should be static.  So move the si_default_state and
si_default_size to si.c and change their
storage-class-specifier to static.

Remove unneeded si_blit_shaders.[c|h]


Uff, well NAK.

IIRC this was intentionally moved into a separate file because it 
is rather large and not related to anything in si.c.


It's unlikely that we are ever going to update it, but I would 
still rather want to keep it separated.


You should rather just include si_blit_shaders.h in si_blit_shaders.c.


Do you mean #include "si_blit_shaders.c" in si.c or similar ?


No, as far as I can see you are getting this warning because of a 
missing previous prototype for the exported array.


This can be avoided if you add si_blit_shaders.h as an include to 
si_blit_shaders.c.


The warning is a symptom.

There are about 5-6 similar big, global tables in radeon/ with similar 
one file uses.


These global tables should become static.

Moving the table to si_blit_shader.h would keep it separated, adding 
the 'static' would remove it from the globals.


*.c removed, Makefile updated.


Sound like that would work for me as well. Main concern is to keep that 
in a separate file.


But why do you want to drop it from globals in the first place?

Christian.



Tom



Regards,
Christian.



This could have the same effect of while keeping these separate failes

Tom



Regards,
Christian.



Signed-off-by: Tom Rix 
---
  drivers/gpu/drm/radeon/Makefile  |   2 +-
  drivers/gpu/drm/radeon/si.c  | 224 +++-
  drivers/gpu/drm/radeon/si_blit_shaders.c | 253 
---

  drivers/gpu/drm/radeon/si_blit_shaders.h |  32 ---
  4 files changed, 224 insertions(+), 287 deletions(-)
  delete mode 100644 drivers/gpu/drm/radeon/si_blit_shaders.c
  delete mode 100644 drivers/gpu/drm/radeon/si_blit_shaders.h

diff --git a/drivers/gpu/drm/radeon/Makefile 
b/drivers/gpu/drm/radeon/Makefile

index 11c97edde54d..664381f4eb07 100644
--- a/drivers/gpu/drm/radeon/Makefile
+++ b/drivers/gpu/drm/radeon/Makefile
@@ -44,7 +44,7 @@ radeon-y += radeon_device.o radeon_asic.o 
radeon_kms.o \

  evergreen.o evergreen_cs.o evergreen_blit_shaders.o \
  evergreen_hdmi.o radeon_trace_points.o ni.o 
cayman_blit_shaders.o \
  atombios_encoders.o radeon_semaphore.o radeon_sa.o 
atombios_i2c.o si.o \

-    si_blit_shaders.o radeon_prime.o cik.o cik_blit_shaders.o \
+    radeon_prime.o cik.o cik_blit_shaders.o \
  r600_dpm.o rs780_dpm.o rv6xx_dpm.o rv770_dpm.o rv730_dpm.o 
rv740_dpm.o \
  rv770_smc.o cypress_dpm.o btc_dpm.o sumo_dpm.o sumo_smc.o 
trinity_dpm.o \
  trinity_smc.o ni_dpm.o si_smc.o si_dpm.o kv_smc.o kv_dpm.o 
ci_smc.o \
diff --git a/drivers/gpu/drm/radeon/si.c 
b/drivers/gpu/drm/radeon/si.c

index 8d5e4b25609d..a4032702e302 100644
--- a/drivers/gpu/drm/radeon/si.c
+++ b/drivers/gpu/drm/radeon/si.c
@@ -38,7 +38,6 @@
  #include "radeon_asic.h"
  #include "radeon_audio.h"
  #include "radeon_ucode.h"
-#include "si_blit_shaders.h"
  #include "si.h"
  #include "sid.h"
  @@ -3553,6 +3552,229 @@ static int si_cp_load_microcode(struct 
radeon_device *rdev)

  return 0;
  }
  +static const u32 si_default_state[] = {
+    0xc0066900,
+    0x,
+    0x0060, /* DB_RENDER_CONTROL */
+    0x, /* DB_COUNT_CONTROL */
+    0x, /* DB_DEPTH_VIEW */
+    0x002a, /* DB_RENDER_OVERRIDE */
+    0x, /* DB_RENDER_OVERRIDE2 */
+    0x, /* DB_HTILE_DATA_BASE */
+
+    0xc0046900,
+    0x0008,
+    0x, /* DB_DEPTH_BOUNDS_MIN */
+    0x, /* DB_DEPTH_BOUNDS_MAX */
+    0x, /* DB_STENCIL_CLEAR */
+    0x, /* DB_DEPTH_CLEAR */
+
+    0xc0036900,
+    0x000f,
+    0x, /* DB_DEPTH_INFO */
+    0x, /* DB_Z_INFO */
+    0x, /* DB_STENCIL_INFO */
+
+    0xc0016900,
+    0x0080,
+    0x, /* PA_SC_WINDOW_OFFSET */
+
+    0xc00d6900,
+    0x0083,
+    0x, /* PA_SC_CLIPRECT_RULE */
+    0x, /* PA_SC_CLIPRECT_0_TL */
+    0x20002000, /* PA_SC_CLIPRECT_0_BR */
+    0x,
+    0x20002000,
+    0x,
+    0x20002000,
+    0x,
+    0x20002000,
+    0x, /* PA_SC_EDGERULE */
+    0x, /* PA_SU_HARDWARE_SCREEN_OFFSET */
+    0x000f, /* CB_TARGET_MASK */
+    0x000f, /* CB_SHADER_MASK */
+
+    0xc0226900,
+    0x0094,
+    0x8000, /* PA_SC_VPORT_SCISSOR_0_TL */
+    0x20002000, /* PA_SC_VPORT_SCISSOR_0_BR */
+    0x8000,
+    0x20002000,
+    0x8000,
+    

Re: [PATCH 4/4] drm/etnaviv: Don't break exclusive fence ordering

[Christian König]

Am 04.04.22 um 15:14 schrieb Daniel Vetter:

On Thu, 31 Mar 2022 at 22:46, Daniel Vetter  wrote:

There's only one exclusive slot, and we must not break the ordering.
Adding a new exclusive fence drops all previous fences from the
dma_resv. To avoid violating the signalling order we err on the side of
over-synchronizing by waiting for the existing fences, even if
userspace asked us to ignore them.

A better fix would be to us a dma_fence_chain or _array like e.g.
amdgpu now uses, but it probably makes sense to lift this into
dma-resv.c code as a proper concept, so that drivers don't have to
hack up their own solution each on their own. Hence go with the simple
fix for now.

Another option is the fence import ioctl from Jason:

https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fdri-devel%2F20210610210925.642582-7-jason%40jlekstrand.net%2Fdata=04%7C01%7Cchristian.koenig%40amd.com%7C7db3184856cd4b6fa2ce08da163d2543%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637846749141237874%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=CQqU37VcltOuwmDN3068yv1c%2FKJ9gaf1U3T7eBQohK4%3Dreserved=0

v2: Improve commit message per Lucas' suggestion.

Signed-off-by: Daniel Vetter 
Cc: Lucas Stach 
Cc: Russell King 
Cc: Christian Gmeiner 
Cc: etna...@lists.freedesktop.org

Hm thinking about this some more, with Christian's dma_resv_usage work
this shouldn't be needed anymore.

Christian, do you want me to drop this?


If it isn't committed yet we could as well just drop it. I've already 
pushed the patch which makes this superfluous.


Christian.


-Daniel


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

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c 
b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
index 5f502c49aec2..14c5ff155336 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
@@ -178,19 +178,21 @@ static int submit_fence_sync(struct etnaviv_gem_submit 
*submit)
 for (i = 0; i < submit->nr_bos; i++) {
 struct etnaviv_gem_submit_bo *bo = >bos[i];
 struct dma_resv *robj = bo->obj->base.resv;
+   bool write = bo->flags & ETNA_SUBMIT_BO_WRITE;

-   if (!(bo->flags & ETNA_SUBMIT_BO_WRITE)) {
+   if (!(write)) {
 ret = dma_resv_reserve_shared(robj, 1);
 if (ret)
 return ret;
 }

-   if (submit->flags & ETNA_SUBMIT_NO_IMPLICIT)
+   /* exclusive fences must be ordered */
+   if (submit->flags & ETNA_SUBMIT_NO_IMPLICIT && !write)
 continue;

 ret = 
drm_sched_job_add_implicit_dependencies(>sched_job,
   >obj->base,
- bo->flags & 
ETNA_SUBMIT_BO_WRITE);
+ write);
 if (ret)
 return ret;
 }
--
2.34.1

Re: [PATCH 2/4] drm/gem: Delete gem array fencing helpers

[Christian König]

Am 04.04.22 um 15:15 schrieb Daniel Vetter:

On Thu, Mar 31, 2022 at 10:46:49PM +0200, Daniel Vetter wrote:

Integrated into the scheduler now and all users converted over.

v2: Rebased over changes from König.

Signed-off-by: Daniel Vetter 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Thomas Zimmermann 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Sumit Semwal 
Cc: "Christian König" 
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org

Anyone up for an ack for this one here?


Acked-by: Christian König 

Please land that ASAP so that I can rebase on top.

Thanks,
Christian.



Thanks, Daniel


---
  drivers/gpu/drm/drm_gem.c | 80 ---
  include/drm/drm_gem.h |  5 ---
  2 files changed, 85 deletions(-)

diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 56fb87885146..133dfae06fab 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -1273,83 +1273,3 @@ drm_gem_unlock_reservations(struct drm_gem_object 
**objs, int count,
ww_acquire_fini(acquire_ctx);
  }
  EXPORT_SYMBOL(drm_gem_unlock_reservations);
-
-/**
- * drm_gem_fence_array_add - Adds the fence to an array of fences to be
- * waited on, deduplicating fences from the same context.
- *
- * @fence_array: array of dma_fence * for the job to block on.
- * @fence: the dma_fence to add to the list of dependencies.
- *
- * This functions consumes the reference for @fence both on success and error
- * cases.
- *
- * Returns:
- * 0 on success, or an error on failing to expand the array.
- */
-int drm_gem_fence_array_add(struct xarray *fence_array,
-   struct dma_fence *fence)
-{
-   struct dma_fence *entry;
-   unsigned long index;
-   u32 id = 0;
-   int ret;
-
-   if (!fence)
-   return 0;
-
-   /* Deduplicate if we already depend on a fence from the same context.
-* This lets the size of the array of deps scale with the number of
-* engines involved, rather than the number of BOs.
-*/
-   xa_for_each(fence_array, index, entry) {
-   if (entry->context != fence->context)
-   continue;
-
-   if (dma_fence_is_later(fence, entry)) {
-   dma_fence_put(entry);
-   xa_store(fence_array, index, fence, GFP_KERNEL);
-   } else {
-   dma_fence_put(fence);
-   }
-   return 0;
-   }
-
-   ret = xa_alloc(fence_array, , fence, xa_limit_32b, GFP_KERNEL);
-   if (ret != 0)
-   dma_fence_put(fence);
-
-   return ret;
-}
-EXPORT_SYMBOL(drm_gem_fence_array_add);
-
-/**
- * drm_gem_fence_array_add_implicit - Adds the implicit dependencies tracked
- * in the GEM object's reservation object to an array of dma_fences for use in
- * scheduling a rendering job.
- *
- * This should be called after drm_gem_lock_reservations() on your array of
- * GEM objects used in the job but before updating the reservations with your
- * own fences.
- *
- * @fence_array: array of dma_fence * for the job to block on.
- * @obj: the gem object to add new dependencies from.
- * @write: whether the job might write the object (so we need to depend on
- * shared fences in the reservation object).
- */
-int drm_gem_fence_array_add_implicit(struct xarray *fence_array,
-struct drm_gem_object *obj,
-bool write)
-{
-   struct dma_resv_iter cursor;
-   struct dma_fence *fence;
-   int ret = 0;
-
-   dma_resv_for_each_fence(, obj->resv, write, fence) {
-   ret = drm_gem_fence_array_add(fence_array, fence);
-   if (ret)
-   break;
-   }
-   return ret;
-}
-EXPORT_SYMBOL(drm_gem_fence_array_add_implicit);
diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
index e2941cee14b6..9d7c61a122dc 100644
--- a/include/drm/drm_gem.h
+++ b/include/drm/drm_gem.h
@@ -407,11 +407,6 @@ int drm_gem_lock_reservations(struct drm_gem_object 
**objs, int count,
  struct ww_acquire_ctx *acquire_ctx);
  void drm_gem_unlock_reservations(struct drm_gem_object **objs, int count,
 struct ww_acquire_ctx *acquire_ctx);
-int drm_gem_fence_array_add(struct xarray *fence_array,
-   struct dma_fence *fence);
-int drm_gem_fence_array_add_implicit(struct xarray *fence_array,
-struct drm_gem_object *obj,
-bool write);
  int drm_gem_dumb_map_offset(struct drm_file *file, struct drm_device *dev,
u32 handle, u64 *offset);
  
--

2.34.1

Re: [PATCH 2/4] drm/gem: Delete gem array fencing helpers

[Daniel Vetter]

On Thu, Mar 31, 2022 at 10:46:49PM +0200, Daniel Vetter wrote:
> Integrated into the scheduler now and all users converted over.
> 
> v2: Rebased over changes from König.
> 
> Signed-off-by: Daniel Vetter 
> Cc: Maarten Lankhorst 
> Cc: Maxime Ripard 
> Cc: Thomas Zimmermann 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Sumit Semwal 
> Cc: "Christian König" 
> Cc: linux-me...@vger.kernel.org
> Cc: linaro-mm-...@lists.linaro.org

Anyone up for an ack for this one here?

Thanks, Daniel

> ---
>  drivers/gpu/drm/drm_gem.c | 80 ---
>  include/drm/drm_gem.h |  5 ---
>  2 files changed, 85 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index 56fb87885146..133dfae06fab 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -1273,83 +1273,3 @@ drm_gem_unlock_reservations(struct drm_gem_object 
> **objs, int count,
>   ww_acquire_fini(acquire_ctx);
>  }
>  EXPORT_SYMBOL(drm_gem_unlock_reservations);
> -
> -/**
> - * drm_gem_fence_array_add - Adds the fence to an array of fences to be
> - * waited on, deduplicating fences from the same context.
> - *
> - * @fence_array: array of dma_fence * for the job to block on.
> - * @fence: the dma_fence to add to the list of dependencies.
> - *
> - * This functions consumes the reference for @fence both on success and error
> - * cases.
> - *
> - * Returns:
> - * 0 on success, or an error on failing to expand the array.
> - */
> -int drm_gem_fence_array_add(struct xarray *fence_array,
> - struct dma_fence *fence)
> -{
> - struct dma_fence *entry;
> - unsigned long index;
> - u32 id = 0;
> - int ret;
> -
> - if (!fence)
> - return 0;
> -
> - /* Deduplicate if we already depend on a fence from the same context.
> -  * This lets the size of the array of deps scale with the number of
> -  * engines involved, rather than the number of BOs.
> -  */
> - xa_for_each(fence_array, index, entry) {
> - if (entry->context != fence->context)
> - continue;
> -
> - if (dma_fence_is_later(fence, entry)) {
> - dma_fence_put(entry);
> - xa_store(fence_array, index, fence, GFP_KERNEL);
> - } else {
> - dma_fence_put(fence);
> - }
> - return 0;
> - }
> -
> - ret = xa_alloc(fence_array, , fence, xa_limit_32b, GFP_KERNEL);
> - if (ret != 0)
> - dma_fence_put(fence);
> -
> - return ret;
> -}
> -EXPORT_SYMBOL(drm_gem_fence_array_add);
> -
> -/**
> - * drm_gem_fence_array_add_implicit - Adds the implicit dependencies tracked
> - * in the GEM object's reservation object to an array of dma_fences for use 
> in
> - * scheduling a rendering job.
> - *
> - * This should be called after drm_gem_lock_reservations() on your array of
> - * GEM objects used in the job but before updating the reservations with your
> - * own fences.
> - *
> - * @fence_array: array of dma_fence * for the job to block on.
> - * @obj: the gem object to add new dependencies from.
> - * @write: whether the job might write the object (so we need to depend on
> - * shared fences in the reservation object).
> - */
> -int drm_gem_fence_array_add_implicit(struct xarray *fence_array,
> -  struct drm_gem_object *obj,
> -  bool write)
> -{
> - struct dma_resv_iter cursor;
> - struct dma_fence *fence;
> - int ret = 0;
> -
> - dma_resv_for_each_fence(, obj->resv, write, fence) {
> - ret = drm_gem_fence_array_add(fence_array, fence);
> - if (ret)
> - break;
> - }
> - return ret;
> -}
> -EXPORT_SYMBOL(drm_gem_fence_array_add_implicit);
> diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
> index e2941cee14b6..9d7c61a122dc 100644
> --- a/include/drm/drm_gem.h
> +++ b/include/drm/drm_gem.h
> @@ -407,11 +407,6 @@ int drm_gem_lock_reservations(struct drm_gem_object 
> **objs, int count,
> struct ww_acquire_ctx *acquire_ctx);
>  void drm_gem_unlock_reservations(struct drm_gem_object **objs, int count,
>struct ww_acquire_ctx *acquire_ctx);
> -int drm_gem_fence_array_add(struct xarray *fence_array,
> - struct dma_fence *fence);
> -int drm_gem_fence_array_add_implicit(struct xarray *fence_array,
> -  struct drm_gem_object *obj,
> -  bool write);
>  int drm_gem_dumb_map_offset(struct drm_file *file, struct drm_device *dev,
>   u32 handle, u64 *offset);
>  
> -- 
> 2.34.1
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH 4/4] drm/etnaviv: Don't break exclusive fence ordering

[Daniel Vetter]

On Thu, 31 Mar 2022 at 22:46, Daniel Vetter  wrote:
>
> There's only one exclusive slot, and we must not break the ordering.
> Adding a new exclusive fence drops all previous fences from the
> dma_resv. To avoid violating the signalling order we err on the side of
> over-synchronizing by waiting for the existing fences, even if
> userspace asked us to ignore them.
>
> A better fix would be to us a dma_fence_chain or _array like e.g.
> amdgpu now uses, but it probably makes sense to lift this into
> dma-resv.c code as a proper concept, so that drivers don't have to
> hack up their own solution each on their own. Hence go with the simple
> fix for now.
>
> Another option is the fence import ioctl from Jason:
>
> https://lore.kernel.org/dri-devel/20210610210925.642582-7-ja...@jlekstrand.net/
>
> v2: Improve commit message per Lucas' suggestion.
>
> Signed-off-by: Daniel Vetter 
> Cc: Lucas Stach 
> Cc: Russell King 
> Cc: Christian Gmeiner 
> Cc: etna...@lists.freedesktop.org

Hm thinking about this some more, with Christian's dma_resv_usage work
this shouldn't be needed anymore.

Christian, do you want me to drop this?
-Daniel

> ---
>  drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c 
> b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
> index 5f502c49aec2..14c5ff155336 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
> @@ -178,19 +178,21 @@ static int submit_fence_sync(struct etnaviv_gem_submit 
> *submit)
> for (i = 0; i < submit->nr_bos; i++) {
> struct etnaviv_gem_submit_bo *bo = >bos[i];
> struct dma_resv *robj = bo->obj->base.resv;
> +   bool write = bo->flags & ETNA_SUBMIT_BO_WRITE;
>
> -   if (!(bo->flags & ETNA_SUBMIT_BO_WRITE)) {
> +   if (!(write)) {
> ret = dma_resv_reserve_shared(robj, 1);
> if (ret)
> return ret;
> }
>
> -   if (submit->flags & ETNA_SUBMIT_NO_IMPLICIT)
> +   /* exclusive fences must be ordered */
> +   if (submit->flags & ETNA_SUBMIT_NO_IMPLICIT && !write)
> continue;
>
> ret = 
> drm_sched_job_add_implicit_dependencies(>sched_job,
>   >obj->base,
> - bo->flags & 
> ETNA_SUBMIT_BO_WRITE);
> + write);
> if (ret)
> return ret;
> }
> --
> 2.34.1
>


-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH] drm/radeon: change si_default_state table from global to static

[Tom Rix]

On 4/4/22 5:34 AM, Christian König wrote:

Am 04.04.22 um 14:32 schrieb Tom Rix:


On 4/3/22 8:23 AM, Christian König wrote:

Am 02.04.22 um 18:27 schrieb Tom Rix:

Smatch reports these issues
si_blit_shaders.c:31:11: warning: symbol 'si_default_state'
   was not declared. Should it be static?
si_blit_shaders.c:253:11: warning: symbol 'si_default_size'
   was not declared. Should it be static?

Both symbols are only used in si.c.  Single file symbols
should be static.  So move the si_default_state and
si_default_size to si.c and change their
storage-class-specifier to static.

Remove unneeded si_blit_shaders.[c|h]


Uff, well NAK.

IIRC this was intentionally moved into a separate file because it is 
rather large and not related to anything in si.c.


It's unlikely that we are ever going to update it, but I would still 
rather want to keep it separated.


You should rather just include si_blit_shaders.h in si_blit_shaders.c.


Do you mean #include "si_blit_shaders.c" in si.c or similar ?


No, as far as I can see you are getting this warning because of a 
missing previous prototype for the exported array.


This can be avoided if you add si_blit_shaders.h as an include to 
si_blit_shaders.c.


The warning is a symptom.

There are about 5-6 similar big, global tables in radeon/ with similar 
one file uses.


These global tables should become static.

Moving the table to si_blit_shader.h would keep it separated, adding the 
'static' would remove it from the globals.


*.c removed, Makefile updated.

Tom



Regards,
Christian.



This could have the same effect of while keeping these separate failes

Tom



Regards,
Christian.



Signed-off-by: Tom Rix 
---
  drivers/gpu/drm/radeon/Makefile  |   2 +-
  drivers/gpu/drm/radeon/si.c  | 224 +++-
  drivers/gpu/drm/radeon/si_blit_shaders.c | 253 
---

  drivers/gpu/drm/radeon/si_blit_shaders.h |  32 ---
  4 files changed, 224 insertions(+), 287 deletions(-)
  delete mode 100644 drivers/gpu/drm/radeon/si_blit_shaders.c
  delete mode 100644 drivers/gpu/drm/radeon/si_blit_shaders.h

diff --git a/drivers/gpu/drm/radeon/Makefile 
b/drivers/gpu/drm/radeon/Makefile

index 11c97edde54d..664381f4eb07 100644
--- a/drivers/gpu/drm/radeon/Makefile
+++ b/drivers/gpu/drm/radeon/Makefile
@@ -44,7 +44,7 @@ radeon-y += radeon_device.o radeon_asic.o 
radeon_kms.o \

  evergreen.o evergreen_cs.o evergreen_blit_shaders.o \
  evergreen_hdmi.o radeon_trace_points.o ni.o 
cayman_blit_shaders.o \
  atombios_encoders.o radeon_semaphore.o radeon_sa.o 
atombios_i2c.o si.o \

-    si_blit_shaders.o radeon_prime.o cik.o cik_blit_shaders.o \
+    radeon_prime.o cik.o cik_blit_shaders.o \
  r600_dpm.o rs780_dpm.o rv6xx_dpm.o rv770_dpm.o rv730_dpm.o 
rv740_dpm.o \
  rv770_smc.o cypress_dpm.o btc_dpm.o sumo_dpm.o sumo_smc.o 
trinity_dpm.o \
  trinity_smc.o ni_dpm.o si_smc.o si_dpm.o kv_smc.o kv_dpm.o 
ci_smc.o \

diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
index 8d5e4b25609d..a4032702e302 100644
--- a/drivers/gpu/drm/radeon/si.c
+++ b/drivers/gpu/drm/radeon/si.c
@@ -38,7 +38,6 @@
  #include "radeon_asic.h"
  #include "radeon_audio.h"
  #include "radeon_ucode.h"
-#include "si_blit_shaders.h"
  #include "si.h"
  #include "sid.h"
  @@ -3553,6 +3552,229 @@ static int si_cp_load_microcode(struct 
radeon_device *rdev)

  return 0;
  }
  +static const u32 si_default_state[] = {
+    0xc0066900,
+    0x,
+    0x0060, /* DB_RENDER_CONTROL */
+    0x, /* DB_COUNT_CONTROL */
+    0x, /* DB_DEPTH_VIEW */
+    0x002a, /* DB_RENDER_OVERRIDE */
+    0x, /* DB_RENDER_OVERRIDE2 */
+    0x, /* DB_HTILE_DATA_BASE */
+
+    0xc0046900,
+    0x0008,
+    0x, /* DB_DEPTH_BOUNDS_MIN */
+    0x, /* DB_DEPTH_BOUNDS_MAX */
+    0x, /* DB_STENCIL_CLEAR */
+    0x, /* DB_DEPTH_CLEAR */
+
+    0xc0036900,
+    0x000f,
+    0x, /* DB_DEPTH_INFO */
+    0x, /* DB_Z_INFO */
+    0x, /* DB_STENCIL_INFO */
+
+    0xc0016900,
+    0x0080,
+    0x, /* PA_SC_WINDOW_OFFSET */
+
+    0xc00d6900,
+    0x0083,
+    0x, /* PA_SC_CLIPRECT_RULE */
+    0x, /* PA_SC_CLIPRECT_0_TL */
+    0x20002000, /* PA_SC_CLIPRECT_0_BR */
+    0x,
+    0x20002000,
+    0x,
+    0x20002000,
+    0x,
+    0x20002000,
+    0x, /* PA_SC_EDGERULE */
+    0x, /* PA_SU_HARDWARE_SCREEN_OFFSET */
+    0x000f, /* CB_TARGET_MASK */
+    0x000f, /* CB_SHADER_MASK */
+
+    0xc0226900,
+    0x0094,
+    0x8000, /* PA_SC_VPORT_SCISSOR_0_TL */
+    0x20002000, /* PA_SC_VPORT_SCISSOR_0_BR */
+    0x8000,
+    0x20002000,
+    0x8000,
+    0x20002000,
+    0x8000,
+    0x20002000,
+    0x8000,
+    0x20002000,
+    0x8000,
+    0x20002000,
+    0x8000,
+    0x20002000,
+    0x8000,
+    0x20002000,
+    0x8000,
+    0x20002000,
+   

RE: [PATCH v6 3/8] drm/msm/dp: Support only IRQ_HPD and REPLUG interrupts for eDP

[Sankeerth Billakanti (QUIC)]

Hi Doug,

> On Wed, Mar 30, 2022 at 9:03 AM Sankeerth Billakanti
>  wrote:
> >
> > @@ -1374,6 +1382,12 @@ static int dp_pm_resume(struct device *dev)
> > dp_catalog_ctrl_hpd_config(dp->catalog);
> >
> >
> > +   if (dp->dp_display.connector_type ==
> DRM_MODE_CONNECTOR_DisplayPort)
> > +   dp_catalog_hpd_config_intr(dp->catalog,
> > +   DP_DP_HPD_PLUG_INT_MASK |
> > +   DP_DP_HPD_UNPLUG_INT_MASK,
> > +   true);
> > +
> 
> nit: why are there two blank lines above?
> 
>

Will remove a blank line.
 
> > @@ -1639,6 +1653,9 @@ void dp_bridge_enable(struct drm_bridge
> *drm_bridge)
> > return;
> > }
> >
> > +   if (dp->connector_type == DRM_MODE_CONNECTOR_eDP)
> > +   dp_hpd_plug_handle(dp_display, 0);
> > +
> 
> Should you add a "pre_enable" and do it there? That would make it more
> symmetric with the fact that you have the countertpart in "post_disable".
>

We want to handle the screen off or eDP disable like a cable unplug so that it 
can be integrated into the dp code.
So, we can move plug_handle into pre_enable and the unplug_handle to 
pre_disable.

If we do unplug in post_disable, we need to handle the state changes also. It 
will complicate the driver code.

> 
> Overall: I'm probably not familiar enough with this code to give it a full
> review. I'm hoping that Dmitry knows it well enough... ;-)
> 
> 
> -Doug

Thank you,
Sankeerth

RE: [PATCH v6 2/8] drm/msm/dp: wait for hpd high before aux transaction

[Sankeerth Billakanti (QUIC)]

Hi Doug,

> On Wed, Mar 30, 2022 at 9:03 AM Sankeerth Billakanti
>  wrote:
> >
> > The source device should ensure the sink is ready before proceeding to
> > read the sink capability or performing any aux transactions. The sink
> 
> s/performing/perform
> 
> > will indicate its readiness by asserting the HPD line. The controller
> > driver needs to wait for the hpd line to be asserted by the sink
> > before performing any aux transactions.
> >
> > The eDP sink is assumed to be always connected. It needs power from
> > the source and its HPD line will be asserted only after the panel is
> > powered on. The panel power will be enabled from the panel-edp driver
> > and only after that, the hpd line will be asserted.
> >
> > Whereas for DP, the sink can be hotplugged and unplugged anytime. The
> > hpd line gets asserted to indicate the sink is connected and ready.
> > Hence there is no need to wait for the hpd line to be asserted for a DP 
> > sink.
> >
> > Signed-off-by: Sankeerth Billakanti 
> > ---
> >
> > Changes in v6:
> >   - Wait for hpd high only for eDP
> >   - Split into smaller patches
> >
> >  drivers/gpu/drm/msm/dp/dp_aux.c | 13 -
> >  drivers/gpu/drm/msm/dp/dp_aux.h |  3 ++-
> >  drivers/gpu/drm/msm/dp/dp_catalog.c | 13 +
> > drivers/gpu/drm/msm/dp/dp_catalog.h |  1 +
> > drivers/gpu/drm/msm/dp/dp_display.c |  3 ++-
> >  5 files changed, 30 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/msm/dp/dp_aux.c
> > b/drivers/gpu/drm/msm/dp/dp_aux.c index 6d36f63..a217c80 100644
> > --- a/drivers/gpu/drm/msm/dp/dp_aux.c
> > +++ b/drivers/gpu/drm/msm/dp/dp_aux.c
> > @@ -36,6 +36,7 @@ struct dp_aux_private {
> > bool initted;
> > u32 offset;
> > u32 segment;
> > +   bool is_edp;
> >
> > struct drm_dp_aux dp_aux;
> >  };
> > @@ -337,6 +338,14 @@ static ssize_t dp_aux_transfer(struct drm_dp_aux
> *dp_aux,
> > goto exit;
> > }
> >
> > +   if (aux->is_edp) {
> 
> Adding a comment about _why_ you're doing this just for eDP would
> probably be a good idea. Like maybe:
> 
> /*
>  * For eDP it's important to give a reasonably long wait here for HPD
>  * to be asserted. This is because the panel driver may have _just_
>  * turned on the panel and then tried to do an AUX transfer. The panel
>  * driver has no way of knowing when the panel is ready, so it's up
>  * to us to wait. For DP we never get into this situation so let's
>  * avoid ever doing the extra long wait for DP.
>  */
> 
> 

Okay. Will add it

> > @@ -491,7 +500,8 @@ void dp_aux_unregister(struct drm_dp_aux
> *dp_aux)
> > drm_dp_aux_unregister(dp_aux);  }
> >
> > -struct drm_dp_aux *dp_aux_get(struct device *dev, struct dp_catalog
> > *catalog)
> > +struct drm_dp_aux *dp_aux_get(struct device *dev, struct dp_catalog
> *catalog,
> > +   bool is_edp)
> 
> nit: I think your indentation of the 2nd line isn't quite right.
> 
>

I moved bool is_edp into the next line. In vim , it was sowing fine. I'll check
 
> > diff --git a/drivers/gpu/drm/msm/dp/dp_aux.h
> > b/drivers/gpu/drm/msm/dp/dp_aux.h index 82afc8d..c99aeec 100644
> > --- a/drivers/gpu/drm/msm/dp/dp_aux.h
> > +++ b/drivers/gpu/drm/msm/dp/dp_aux.h
> > @@ -16,7 +16,8 @@ void dp_aux_init(struct drm_dp_aux *dp_aux);  void
> > dp_aux_deinit(struct drm_dp_aux *dp_aux);  void dp_aux_reconfig(struct
> > drm_dp_aux *dp_aux);
> >
> > -struct drm_dp_aux *dp_aux_get(struct device *dev, struct dp_catalog
> > *catalog);
> > +struct drm_dp_aux *dp_aux_get(struct device *dev, struct dp_catalog
> *catalog,
> > +   bool is_edp);
> 
> nit: I think your indentation of the 2nd line isn't quite right.
> 

I'll check

> 
> Things are pretty much nits, so FWIW:
> 
> Reviewed-by: Douglas Anderson 

Thank you,
Sankeerth

Re: [PATCH] drm/radeon: change si_default_state table from global to static

[Christian König]

Am 04.04.22 um 14:32 schrieb Tom Rix:


On 4/3/22 8:23 AM, Christian König wrote:

Am 02.04.22 um 18:27 schrieb Tom Rix:

Smatch reports these issues
si_blit_shaders.c:31:11: warning: symbol 'si_default_state'
   was not declared. Should it be static?
si_blit_shaders.c:253:11: warning: symbol 'si_default_size'
   was not declared. Should it be static?

Both symbols are only used in si.c.  Single file symbols
should be static.  So move the si_default_state and
si_default_size to si.c and change their
storage-class-specifier to static.

Remove unneeded si_blit_shaders.[c|h]


Uff, well NAK.

IIRC this was intentionally moved into a separate file because it is 
rather large and not related to anything in si.c.


It's unlikely that we are ever going to update it, but I would still 
rather want to keep it separated.


You should rather just include si_blit_shaders.h in si_blit_shaders.c.


Do you mean #include "si_blit_shaders.c" in si.c or similar ?


No, as far as I can see you are getting this warning because of a 
missing previous prototype for the exported array.


This can be avoided if you add si_blit_shaders.h as an include to 
si_blit_shaders.c.


Regards,
Christian.



This could have the same effect of while keeping these separate failes

Tom



Regards,
Christian.



Signed-off-by: Tom Rix 
---
  drivers/gpu/drm/radeon/Makefile  |   2 +-
  drivers/gpu/drm/radeon/si.c  | 224 +++-
  drivers/gpu/drm/radeon/si_blit_shaders.c | 253 
---

  drivers/gpu/drm/radeon/si_blit_shaders.h |  32 ---
  4 files changed, 224 insertions(+), 287 deletions(-)
  delete mode 100644 drivers/gpu/drm/radeon/si_blit_shaders.c
  delete mode 100644 drivers/gpu/drm/radeon/si_blit_shaders.h

diff --git a/drivers/gpu/drm/radeon/Makefile 
b/drivers/gpu/drm/radeon/Makefile

index 11c97edde54d..664381f4eb07 100644
--- a/drivers/gpu/drm/radeon/Makefile
+++ b/drivers/gpu/drm/radeon/Makefile
@@ -44,7 +44,7 @@ radeon-y += radeon_device.o radeon_asic.o 
radeon_kms.o \

  evergreen.o evergreen_cs.o evergreen_blit_shaders.o \
  evergreen_hdmi.o radeon_trace_points.o ni.o 
cayman_blit_shaders.o \
  atombios_encoders.o radeon_semaphore.o radeon_sa.o 
atombios_i2c.o si.o \

-    si_blit_shaders.o radeon_prime.o cik.o cik_blit_shaders.o \
+    radeon_prime.o cik.o cik_blit_shaders.o \
  r600_dpm.o rs780_dpm.o rv6xx_dpm.o rv770_dpm.o rv730_dpm.o 
rv740_dpm.o \
  rv770_smc.o cypress_dpm.o btc_dpm.o sumo_dpm.o sumo_smc.o 
trinity_dpm.o \
  trinity_smc.o ni_dpm.o si_smc.o si_dpm.o kv_smc.o kv_dpm.o 
ci_smc.o \

diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
index 8d5e4b25609d..a4032702e302 100644
--- a/drivers/gpu/drm/radeon/si.c
+++ b/drivers/gpu/drm/radeon/si.c
@@ -38,7 +38,6 @@
  #include "radeon_asic.h"
  #include "radeon_audio.h"
  #include "radeon_ucode.h"
-#include "si_blit_shaders.h"
  #include "si.h"
  #include "sid.h"
  @@ -3553,6 +3552,229 @@ static int si_cp_load_microcode(struct 
radeon_device *rdev)

  return 0;
  }
  +static const u32 si_default_state[] = {
+    0xc0066900,
+    0x,
+    0x0060, /* DB_RENDER_CONTROL */
+    0x, /* DB_COUNT_CONTROL */
+    0x, /* DB_DEPTH_VIEW */
+    0x002a, /* DB_RENDER_OVERRIDE */
+    0x, /* DB_RENDER_OVERRIDE2 */
+    0x, /* DB_HTILE_DATA_BASE */
+
+    0xc0046900,
+    0x0008,
+    0x, /* DB_DEPTH_BOUNDS_MIN */
+    0x, /* DB_DEPTH_BOUNDS_MAX */
+    0x, /* DB_STENCIL_CLEAR */
+    0x, /* DB_DEPTH_CLEAR */
+
+    0xc0036900,
+    0x000f,
+    0x, /* DB_DEPTH_INFO */
+    0x, /* DB_Z_INFO */
+    0x, /* DB_STENCIL_INFO */
+
+    0xc0016900,
+    0x0080,
+    0x, /* PA_SC_WINDOW_OFFSET */
+
+    0xc00d6900,
+    0x0083,
+    0x, /* PA_SC_CLIPRECT_RULE */
+    0x, /* PA_SC_CLIPRECT_0_TL */
+    0x20002000, /* PA_SC_CLIPRECT_0_BR */
+    0x,
+    0x20002000,
+    0x,
+    0x20002000,
+    0x,
+    0x20002000,
+    0x, /* PA_SC_EDGERULE */
+    0x, /* PA_SU_HARDWARE_SCREEN_OFFSET */
+    0x000f, /* CB_TARGET_MASK */
+    0x000f, /* CB_SHADER_MASK */
+
+    0xc0226900,
+    0x0094,
+    0x8000, /* PA_SC_VPORT_SCISSOR_0_TL */
+    0x20002000, /* PA_SC_VPORT_SCISSOR_0_BR */
+    0x8000,
+    0x20002000,
+    0x8000,
+    0x20002000,
+    0x8000,
+    0x20002000,
+    0x8000,
+    0x20002000,
+    0x8000,
+    0x20002000,
+    0x8000,
+    0x20002000,
+    0x8000,
+    0x20002000,
+    0x8000,
+    0x20002000,
+    0x8000,
+    0x20002000,
+    0x8000,
+    0x20002000,
+    0x8000,
+    0x20002000,
+    0x8000,
+    0x20002000,
+    0x8000,
+    0x20002000,
+    0x8000,
+    0x20002000,
+    0x8000,
+    0x20002000,
+    0x, /* PA_SC_VPORT_ZMIN_0 */
+    0x3f80, /* PA_SC_VPORT_ZMAX_0 */
+
+    0xc0026900,
+    0x00d9,
+    

Re: [PATCH] gpu: host1x: Do not use mapping cache for job submissions

[Jon Hunter]

On 24/03/2022 10:30, Thierry Reding wrote:

From: Thierry Reding 

Buffer mappings used in job submissions are usually small and not
rapidly reused as opposed to framebuffers (which are usually large and
rapidly reused, for example when page-flipping between double-buffered
framebuffers). Avoid going through the mapping cache for these buffers
since the cache would also lead to leaks if nobody is ever releasing
the cache's last reference. For DRM/KMS these last references are
dropped when the framebuffers are removed and therefore no longer
needed.

While at it, also add a note about the need to explicitly remove the
final reference to the mapping in the cache.

Signed-off-by: Thierry Reding 



I have tested this and verified that it is working well.

Reviewed-by: Jon Hunter 
Tested-by: Jon Hunter 

Thanks
Jon

--
nvpublic

Re: [PATCH] drm/radeon: change si_default_state table from global to static

[Tom Rix]

On 4/3/22 8:23 AM, Christian König wrote:

Am 02.04.22 um 18:27 schrieb Tom Rix:

Smatch reports these issues
si_blit_shaders.c:31:11: warning: symbol 'si_default_state'
   was not declared. Should it be static?
si_blit_shaders.c:253:11: warning: symbol 'si_default_size'
   was not declared. Should it be static?

Both symbols are only used in si.c.  Single file symbols
should be static.  So move the si_default_state and
si_default_size to si.c and change their
storage-class-specifier to static.

Remove unneeded si_blit_shaders.[c|h]


Uff, well NAK.

IIRC this was intentionally moved into a separate file because it is 
rather large and not related to anything in si.c.


It's unlikely that we are ever going to update it, but I would still 
rather want to keep it separated.


You should rather just include si_blit_shaders.h in si_blit_shaders.c.


Do you mean #include "si_blit_shaders.c" in si.c or similar ?

This could have the same effect of while keeping these separate failes

Tom



Regards,
Christian.



Signed-off-by: Tom Rix 
---
  drivers/gpu/drm/radeon/Makefile  |   2 +-
  drivers/gpu/drm/radeon/si.c  | 224 +++-
  drivers/gpu/drm/radeon/si_blit_shaders.c | 253 ---
  drivers/gpu/drm/radeon/si_blit_shaders.h |  32 ---
  4 files changed, 224 insertions(+), 287 deletions(-)
  delete mode 100644 drivers/gpu/drm/radeon/si_blit_shaders.c
  delete mode 100644 drivers/gpu/drm/radeon/si_blit_shaders.h

diff --git a/drivers/gpu/drm/radeon/Makefile 
b/drivers/gpu/drm/radeon/Makefile

index 11c97edde54d..664381f4eb07 100644
--- a/drivers/gpu/drm/radeon/Makefile
+++ b/drivers/gpu/drm/radeon/Makefile
@@ -44,7 +44,7 @@ radeon-y += radeon_device.o radeon_asic.o 
radeon_kms.o \

  evergreen.o evergreen_cs.o evergreen_blit_shaders.o \
  evergreen_hdmi.o radeon_trace_points.o ni.o 
cayman_blit_shaders.o \
  atombios_encoders.o radeon_semaphore.o radeon_sa.o 
atombios_i2c.o si.o \

-    si_blit_shaders.o radeon_prime.o cik.o cik_blit_shaders.o \
+    radeon_prime.o cik.o cik_blit_shaders.o \
  r600_dpm.o rs780_dpm.o rv6xx_dpm.o rv770_dpm.o rv730_dpm.o 
rv740_dpm.o \
  rv770_smc.o cypress_dpm.o btc_dpm.o sumo_dpm.o sumo_smc.o 
trinity_dpm.o \
  trinity_smc.o ni_dpm.o si_smc.o si_dpm.o kv_smc.o kv_dpm.o 
ci_smc.o \

diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
index 8d5e4b25609d..a4032702e302 100644
--- a/drivers/gpu/drm/radeon/si.c
+++ b/drivers/gpu/drm/radeon/si.c
@@ -38,7 +38,6 @@
  #include "radeon_asic.h"
  #include "radeon_audio.h"
  #include "radeon_ucode.h"
-#include "si_blit_shaders.h"
  #include "si.h"
  #include "sid.h"
  @@ -3553,6 +3552,229 @@ static int si_cp_load_microcode(struct 
radeon_device *rdev)

  return 0;
  }
  +static const u32 si_default_state[] = {
+    0xc0066900,
+    0x,
+    0x0060, /* DB_RENDER_CONTROL */
+    0x, /* DB_COUNT_CONTROL */
+    0x, /* DB_DEPTH_VIEW */
+    0x002a, /* DB_RENDER_OVERRIDE */
+    0x, /* DB_RENDER_OVERRIDE2 */
+    0x, /* DB_HTILE_DATA_BASE */
+
+    0xc0046900,
+    0x0008,
+    0x, /* DB_DEPTH_BOUNDS_MIN */
+    0x, /* DB_DEPTH_BOUNDS_MAX */
+    0x, /* DB_STENCIL_CLEAR */
+    0x, /* DB_DEPTH_CLEAR */
+
+    0xc0036900,
+    0x000f,
+    0x, /* DB_DEPTH_INFO */
+    0x, /* DB_Z_INFO */
+    0x, /* DB_STENCIL_INFO */
+
+    0xc0016900,
+    0x0080,
+    0x, /* PA_SC_WINDOW_OFFSET */
+
+    0xc00d6900,
+    0x0083,
+    0x, /* PA_SC_CLIPRECT_RULE */
+    0x, /* PA_SC_CLIPRECT_0_TL */
+    0x20002000, /* PA_SC_CLIPRECT_0_BR */
+    0x,
+    0x20002000,
+    0x,
+    0x20002000,
+    0x,
+    0x20002000,
+    0x, /* PA_SC_EDGERULE */
+    0x, /* PA_SU_HARDWARE_SCREEN_OFFSET */
+    0x000f, /* CB_TARGET_MASK */
+    0x000f, /* CB_SHADER_MASK */
+
+    0xc0226900,
+    0x0094,
+    0x8000, /* PA_SC_VPORT_SCISSOR_0_TL */
+    0x20002000, /* PA_SC_VPORT_SCISSOR_0_BR */
+    0x8000,
+    0x20002000,
+    0x8000,
+    0x20002000,
+    0x8000,
+    0x20002000,
+    0x8000,
+    0x20002000,
+    0x8000,
+    0x20002000,
+    0x8000,
+    0x20002000,
+    0x8000,
+    0x20002000,
+    0x8000,
+    0x20002000,
+    0x8000,
+    0x20002000,
+    0x8000,
+    0x20002000,
+    0x8000,
+    0x20002000,
+    0x8000,
+    0x20002000,
+    0x8000,
+    0x20002000,
+    0x8000,
+    0x20002000,
+    0x8000,
+    0x20002000,
+    0x, /* PA_SC_VPORT_ZMIN_0 */
+    0x3f80, /* PA_SC_VPORT_ZMAX_0 */
+
+    0xc0026900,
+    0x00d9,
+    0x, /* CP_RINGID */
+    0x, /* CP_VMID */
+
+    0xc0046900,
+    0x0100,
+    0x, /* VGT_MAX_VTX_INDX */
+    0x, /* VGT_MIN_VTX_INDX */
+    0x, /* VGT_INDX_OFFSET */
+    0x, /* VGT_MULTI_PRIM_IB_RESET_INDX */
+
+    

Re: [PATCH 2/2] drm: lcdif: Add support for i.MX8MP LCDIF variant

[Lucas Stach]

Hi Marek,

not a full review right now, just the first things that I noticed while
playing around with this.

Am Dienstag, dem 22.03.2022 um 15:28 +0100 schrieb Marek Vasut:
> Add support for i.MX8MP LCDIF variant. This is called LCDIFv3 and is
> completely different from the LCDIFv3 found in i.MX23 in that it has
> a completely scrambled register layout compared to all previous LCDIF
> variants. The new LCDIFv3 also supports 36bit address space.
> 
> Add a separate driver which is really a fork of MXSFB driver with the
> i.MX8MP LCDIF variant handling filled in.
> 
> Signed-off-by: Marek Vasut 
> Cc: Alexander Stein 
> Cc: Laurent Pinchart 
> Cc: Lucas Stach 
> Cc: Peng Fan 
> Cc: Robby Cai 
> Cc: Sam Ravnborg 
> Cc: Stefan Agner 
> ---
>  drivers/gpu/drm/mxsfb/Kconfig  |  16 +
>  drivers/gpu/drm/mxsfb/Makefile |   2 +
>  drivers/gpu/drm/mxsfb/lcdif_drv.c  | 367 +
>  drivers/gpu/drm/mxsfb/lcdif_drv.h  |  48 +++
>  drivers/gpu/drm/mxsfb/lcdif_kms.c  | 492 +
>  drivers/gpu/drm/mxsfb/lcdif_regs.h | 243 ++

Not sure about this placement. I know you hope to share some code with
the other mxsfb driver, but I would prefer to add this into
drivers/gpu/drm/imx, same as the DCSS. Another driver for the imx21-
lcdif will also be added there and we'll move the ipuv3 driver into its
own subdirectory to make it clear that there are multiple separate
drivers.

>  6 files changed, 1168 insertions(+)
>  create mode 100644 drivers/gpu/drm/mxsfb/lcdif_drv.c
>  create mode 100644 drivers/gpu/drm/mxsfb/lcdif_drv.h
>  create mode 100644 drivers/gpu/drm/mxsfb/lcdif_kms.c
>  create mode 100644 drivers/gpu/drm/mxsfb/lcdif_regs.h
> 
> diff --git a/drivers/gpu/drm/mxsfb/Kconfig b/drivers/gpu/drm/mxsfb/Kconfig
> index 987170e16ebd6..deb84f99d2fca 100644
> --- a/drivers/gpu/drm/mxsfb/Kconfig
> +++ b/drivers/gpu/drm/mxsfb/Kconfig
> @@ -19,3 +19,19 @@ config DRM_MXSFB
> i.MX28, i.MX6SX, i.MX7 and i.MX8M).
>  
> If M is selected the module will be called mxsfb.
> +
> +config DRM_LCDIF

The config option name and also the DRM driver name are way too
generic. Every 3rd SoC out there has a block called lcdif to drive a
panel...

Maybe something like CONFIG_FSL_LCDIF_V3 and fsl-lcdif-v3 for the name?

> + tristate "i.MX LCDIFv3 LCD controller"
> + depends on DRM && OF
> + depends on COMMON_CLK
> + select DRM_MXS
> + select DRM_KMS_HELPER
> + select DRM_GEM_CMA_HELPER
> + select DRM_PANEL
> + select DRM_PANEL_BRIDGE
> + help
> +   Choose this option if you have an LCDIFv3 LCD controller.
> +   Those devices are found in various i.MX SoC (i.MX8MP,
> +   i.MXRT).
> +
> +   If M is selected the module will be called lcdif.
> diff --git a/drivers/gpu/drm/mxsfb/Makefile b/drivers/gpu/drm/mxsfb/Makefile
> index 26d153896d720..e57e807d14857 100644
> --- a/drivers/gpu/drm/mxsfb/Makefile
> +++ b/drivers/gpu/drm/mxsfb/Makefile
> @@ -1,3 +1,5 @@
>  # SPDX-License-Identifier: GPL-2.0-only
>  mxsfb-y := mxsfb_drv.o mxsfb_kms.o
>  obj-$(CONFIG_DRM_MXSFB)  += mxsfb.o
> +lcdif-y := lcdif_drv.o lcdif_kms.o
> +obj-$(CONFIG_DRM_LCDIF)  += lcdif.o
> diff --git a/drivers/gpu/drm/mxsfb/lcdif_drv.c 
> b/drivers/gpu/drm/mxsfb/lcdif_drv.c
> new file mode 100644
> index 0..00131fd12bdaa
> --- /dev/null
> +++ b/drivers/gpu/drm/mxsfb/lcdif_drv.c
> @@ -0,0 +1,367 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Copyright (C) 2022 Marek Vasut 
> + *
> + * This code is based on drivers/gpu/drm/mxsfb/mxsfb*
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "lcdif_drv.h"
> +#include "lcdif_regs.h"
> +
> +static struct drm_framebuffer *
> +lcdif_fb_create(struct drm_device *dev, struct drm_file *file_priv,
> + const struct drm_mode_fb_cmd2 *mode_cmd)
> +{
> + const struct drm_format_info *info;
> +
> + info = drm_get_format_info(dev, mode_cmd);
> + if (!info)
> + return ERR_PTR(-EINVAL);
> +
> + if (mode_cmd->width * info->cpp[0] != mode_cmd->pitches[0]) {
> + dev_dbg(dev->dev, "Invalid pitch: fb width must match pitch\n");
> + return ERR_PTR(-EINVAL);
> + }

That's not true. One of the major advantages of the LCDIFv3 vs. the
other controllers supported by mxsfb is that it actually has a
configurable pitch (CTRLDESCL0_3) separate from the display width.

> +
> + return drm_gem_fb_create(dev, file_priv, mode_cmd);
> +}
> +
> +static const struct drm_mode_config_funcs lcdif_mode_config_funcs = {
> + .fb_create  = lcdif_fb_create,
> + .atomic_check   = drm_atomic_helper_check,
> + .atomic_commit  = drm_atomic_helper_commit,
> +};
> +
> +static const struct 

Re: [Intel-gfx] [PATCH] drm/i915/display/debugfs: Add connector debugfs for "output_bpc"

[Modem, Bhanuprakash]

On Mon-04-04-2022 04:16 pm, Jani Nikula wrote:

On Mon, 04 Apr 2022, "Modem, Bhanuprakash"  wrote:

On Fri-01-04-2022 06:10 pm, Jani Nikula wrote:

On Tue, 29 Mar 2022, Bhanuprakash Modem  wrote:

This new debugfs will expose the connector's max supported bpc
and the bpc currently using. It is very useful for verifying
whether we enter the correct output color depth from IGT.

Example:
cat /sys/kernel/debug/dri/0/DP-1/output_bpc
Current: 8
Maximum: 10

V2: Add connector's max bpc to i915_display_info

Cc: Ville Syrjälä 
Cc: Uma Shankar 
Cc: Swati Sharma 
Signed-off-by: Bhanuprakash Modem 
---
   .../drm/i915/display/intel_display_debugfs.c  | 46 +++
   1 file changed, 46 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c 
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index c1e74a13a0828..694d27f3b109c 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -663,6 +663,8 @@ static void intel_connector_info(struct seq_file *m,
seq_puts(m, "\tHDCP version: ");
intel_hdcp_info(m, intel_connector);
   
+	seq_printf(m, "\tmax bpc: %u\n", connector->display_info.bpc);

+
intel_panel_info(m, intel_connector);
   
   	seq_printf(m, "\tmodes:\n");

@@ -2275,6 +2277,47 @@ static const struct file_operations i915_dsc_bpp_fops = {
.write = i915_dsc_bpp_write
   };
   
+/*

+ * Returns the maximum output bpc for the connector.
+ * Example usage: cat /sys/kernel/debug/dri/0/DP-1/output_bpc
+ */
+static int output_bpc_show(struct seq_file *m, void *data)
+{
+   struct drm_connector *connector = m->private;
+   struct drm_device *dev = connector->dev;
+   struct drm_crtc *crtc;
+   struct intel_crtc_state *crtc_state;
+   struct intel_encoder *encoder = 
intel_attached_encoder(to_intel_connector(connector));
+   int res;
+
+   if (!encoder)
+   return -ENODEV;
+
+   res = 
drm_modeset_lock_single_interruptible(>mode_config.connection_mutex);
+   if (res)
+   return res;
+
+   crtc = connector->state->crtc;
+   if (connector->status != connector_status_connected || !crtc) {
+   res = -ENODEV;
+   goto unlock;
+   }
+
+   crtc_state = to_intel_crtc_state(crtc->state);
+   if (!crtc_state->hw.active)
+   goto unlock;
+
+   seq_printf(m, "Current: %u\n", crtc_state->pipe_bpp / 3);
+   seq_printf(m, "Maximum: %u\n", connector->display_info.bpc);
+   res = 0;
+
+unlock:
+   drm_modeset_unlock(>mode_config.connection_mutex);
+
+   return res;
+}
+DEFINE_SHOW_ATTRIBUTE(output_bpc);


Looks like an excessive amount of code for a single value.


Yeah, but these values are very helpful in many IGT tests like
kms_color, kms_hdr, kms_dither, kms_dsc etc..

Otherwise IGT needs to request the kernel to get the EDID, and parse
that EDID to get the "Maximum" value which is redundant (Kernel is
already doing the same) and not recommended in IGT.

And there is no way to get the "Current" value except reading it from
i915_display_info which is again not recommended in IGT (As
i915_display_info is Intel specific).


Note how we have intel_connector_debugfs_add() for connector debugfs and
intel_crtc_debugfs_add() for crtc debugfs, and how this patch just mixes
up the two by looking up crtc and state from the connector debugfs.


I just tried to adopt from existing AMD's implementation, and it may be 
reduce the number of debugfs nodes.


"Maximum" is from connector's display_info (Needs connector debugfs)
"Current" is from crtc state (Needs crtc debugfs)




This debugfs is already introduced & using by AMD:
https://patchwork.freedesktop.org/patch/308586


Wait, what?

Both amd and i915 adding the name "output_bpc" is *not* the way to
roll. We only add i915_ prefixed debugfs files from i915.ko.

If you need this to be a standard interface across drivers, IMO it
should be added in common drm code, not sprinkled around in drivers.


As display_info is the member of drm_connector, perhaps we can move 
"Maximum" value to drm layer and can use common name.

Example: /sys/kernel/debug/dri/0/DP-1/max_bpc

And each hardware specific driver could create a crtc debugfs node for 
"Current" value in their name space.

Example: /sys/kernel/debug/dri/0/crtc-0/i915_current_bpc

Please suggest.

- Bhanu


I see that amd is already using this in what is basically drm core
debugfs namespace, and there's amd specific IGT built on top.

Adding a bunch of Cc's to get some clarity on drm debugfs naming and
usage.


BR,
Jani.




- Bhanu



BR,
Jani.


+
   /**
* intel_connector_debugfs_add - add i915 specific connector debugfs files
* @connector: pointer to a registered drm_connector
@@ -2330,6 +2373,9 @@ void intel_connector_debugfs_add(struct intel_connector 
*intel_connector)
connector->connector_type == DRM_MODE_CONNECTOR_HDMIB)

Re: [PATCH 06/23] drm/nouveau: stop using dma_resv_excl_fence

[Karol Herbst]

On Sun, Apr 3, 2022 at 5:59 PM Christian König  wrote:
>
> Just a gentle ping to the nouveau guys.
>
> Any more comments on this? Otherwise I'm pushing that with Daniels rb.
>

It looks fine, but given that this area broke in the past I will try
to do some testing either before or after you push it. As long as we
do so before 5.19 it should be okay I think.

Unless somebody knowing more about this code has anything else to say.

> Thanks,
> Christian.
>
> Am 21.03.22 um 14:58 schrieb Christian König:
> > Instead use the new dma_resv_get_singleton function.
> >
> > Signed-off-by: Christian König 
> > Reviewed-by: Daniel Vetter 
> > Cc: Ben Skeggs 
> > Cc: Karol Herbst 
> > Cc: Lyude Paul 
> > Cc: nouv...@lists.freedesktop.org
> > ---
> >   drivers/gpu/drm/nouveau/nouveau_bo.c | 9 -
> >   1 file changed, 8 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
> > b/drivers/gpu/drm/nouveau/nouveau_bo.c
> > index fa73fe57f97b..74f8652d2bd3 100644
> > --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> > +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> > @@ -959,7 +959,14 @@ nouveau_bo_vm_cleanup(struct ttm_buffer_object *bo,
> >   {
> >   struct nouveau_drm *drm = nouveau_bdev(bo->bdev);
> >   struct drm_device *dev = drm->dev;
> > - struct dma_fence *fence = dma_resv_excl_fence(bo->base.resv);
> > + struct dma_fence *fence;
> > + int ret;
> > +
> > + /* TODO: This is actually a memory management dependency */
> > + ret = dma_resv_get_singleton(bo->base.resv, false, );
> > + if (ret)
> > + dma_resv_wait_timeout(bo->base.resv, false, false,
> > +   MAX_SCHEDULE_TIMEOUT);
> >
> >   nv10_bo_put_tile_region(dev, *old_tile, fence);
> >   *old_tile = new_tile;
>

Re: [PATCH 4/7] video: fbdev: vt8623fb: Error out if 'pixclock' equals zero

[Geert Uytterhoeven]

Hi Zheyu,

On Mon, Apr 4, 2022 at 1:07 PM Zheyu Ma  wrote:
> The userspace program could pass any values to the driver through
> ioctl() interface. If the driver doesn't check the value of 'pixclock',
> it may cause divide error.
>
> Fix this by checking whether 'pixclock' is zero in the function
> vt8623fb_check_var().
>
> The following log reveals it:
>
> [   47.778727] divide error:  [#1] PREEMPT SMP KASAN PTI
> [   47.778803] RIP: 0010:vt8623fb_set_par+0xecd/0x2210
> [   47.778870] Call Trace:
> [   47.778872]  
> [   47.778909]  fb_set_var+0x604/0xeb0
> [   47.778995]  do_fb_ioctl+0x234/0x670
> [   47.779041]  fb_ioctl+0xdd/0x130
> [   47.779048]  do_syscall_64+0x3b/0x90
>
> Signed-off-by: Zheyu Ma 

Thanks for your patch!

> --- a/drivers/video/fbdev/vt8623fb.c
> +++ b/drivers/video/fbdev/vt8623fb.c
> @@ -321,6 +321,9 @@ static int vt8623fb_check_var(struct fb_var_screeninfo 
> *var, struct fb_info *inf
>  {
> int rv, mem, step;
>
> +   if (!var->pixclock)
> +   return -EINVAL;
> +

When passed an invalid value, .check_var() is supposed to
round up the invalid to a valid value, if possible.

> /* Find appropriate format */
> rv = svga_match_format (vt8623fb_formats, var, NULL);
> if (rv < 0)

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: [BUG] fbdev: i740fb: Divide error when ‘var->pixclock’ is zero

[Geert Uytterhoeven]

Hi Helge,

On Sun, Apr 3, 2022 at 5:41 PM Helge Deller  wrote:
> On 4/3/22 13:26, Zheyu Ma wrote:
> > I found a bug in the function i740fb_set_par().
>
> Nice catch!
>
> > When the user calls the ioctl system call without setting the value to
> > 'var->pixclock', the driver will throw a divide error.
> >
> > This bug occurs because the driver uses the value of 'var->pixclock'
> > without checking it, as the following code snippet show:
> >
> > if ((100 / var->pixclock) > DACSPEED8) {
> >  dev_err(info->device, "requested pixclock %i MHz out of range
> > (max. %i MHz at 8bpp)\n",
> >  100 / var->pixclock, DACSPEED8);
> > return -EINVAL;x
> > }
> >
> > We can fix this by checking the value of 'var->pixclock' in the
> > function i740fb_check_var() similar to commit
> > b36b242d4b8ea178f7fd038965e3cac7f30c3f09, or we should set the lowest
> > supported value when this field is zero.
> > I have no idea about which solution is better.
>
> Me neither.
> I think a solution like commit b36b242d4b8ea178f7fd038965e3cac7f30c3f09
> is sufficient.
>
> Note that i740fb_set_par() is called in i740fb_resume() as well.
> Since this doesn't comes form userspace I think adding a check for
> the return value there isn't necessary.
>
> Would you mind sending a patch like b36b242d4b8ea178f7fd038965e3cac7f30c3f09 ?

When passed an invalid value, .check_var() is supposed to
round up the invalid to a valid value, if possible.

Commit b36b242d4b8ea178 ("video: fbdev: asiliantfb: Error out if
'pixclock' equals zero") does not do that.

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: [PATCH v10 0/3] drivers: ddcci: add drivers for DDCCI

[Hans de Goede]

Hi Yusuf,

On 4/4/22 01:08, Yusuf Khan wrote:
> This patch adds the DDCCI driver by Christoph Grenz into the kernel.
> The original gitlab page is loacted at https://gitlab.com/ddcci-driv
> er-linux/ddcci-driver-linux/-/tree/master.
> 
> DDC/CI is a control protocol for monitor settings supported by most
> monitors since about 2005. A chardev and sysfs interface is provided.
> A backlight driver using DDCCI is also provided in the seccond patch.
> 
> Signed-off-by: Yusuf Khan 
> Signed-off-by: Christoph Grenz 

Thank you for your submission of this patch series.

I must say that I'm a bit surprised that this series was NOT
also send to the drm/kms subsystem maintainers and mailinglists
since this deals with monitors and thus is highly relevant for
those folks. Luckily I saw an article about this at Phoronix
(you write in the changelog that you believe that there is
no interaction with the DRM/KMS subsystems but that is wrong).

One very important thing which I'm missing in this cover-letter
is why you want to have this in the kernel at all? There are
already various tools which do DDCCI from userspace just fine.

I guess you may be interested in offering /sys/class/backlight
functionality for external monitors. That is actually something
which I'm interested in too, but it is not that simple.

The current /sys/class/backlight interface does not offer a
way for userspace to map a /sys/class/backlight device to
a specific display-output / monitor. So userspace currently
assumes that there is only 1 (1 valid) /sys/class/backlight
device and that that *always* belongs to the internal LCD
panel of a laptop.

So just adding /sys/class/backlight device(s) for internal
monitors without addressing the short-comings of the existing
userspace interface is simply not possible because it would
break existing userspace which is something which is not
allowed.

So NACK from me for the backlight part at least and without
that, I really see no reason to do this in the kernel rather
then userspace.

I've recently been discussing this with a colleague of mine,
Sebastian Wick and as a result of that I'm giving a talk
with a proposal for a better userspace API for this at
kernel-recipes:
https://kernel-recipes.org/en/2022/talks/new-userspace-api-for-display-panel-brightness-control/

I hope to start working on a RFC patch series for this soon.

IMHO merging this series should be put on hold until we
have a better idea of how we want to solve the userspace
API challenges, esp. the monitor <-> /sys/class/backlight
mapping problem.

Regards,

Hans



p.s.

This is not the first time this has come up:

https://lore.kernel.org/all/4b17ba08-39f3-57dd-5aad-d37d844b0...@linux.intel.com/
https://www.x.org/wiki/Events/XDC2014/XDC2014GoedeBacklight/



> ---
> v2: Fix typos.
> 
> v3: Add documentation, move files around, replace semaphores with
> mutexes, and replaced  with .
> "imirkin"(which due to his involvement in the dri-devel irc channel
> I cant help but assume to be a DRM developer) said that the DDC/CI
> bus does not intefere with the buses that DRM is involved with.
> 
> v4: Move some documentation, fix grammer mistakes, remove usages of
> likely(), and clarify some documentation.
> 
> v5: Fix grammer mistakes, remove usages of likely(), and clarify
> some documentation.
> 
> v6: Change contact information to reference Christoph Grenz.
> 
> v7: Remove all instances of the unlikely() macro.
> 
> v8: Modify documentation to provide updated date and kernel
> documentation, fix SPDX lines, use isalpha instead of redefining
> logic, change maximum amount of bytes that can be written to be
> conformant with DDC/CI specification, prevent userspace from holding
> locks with the open file descriptor, remove ddcci_cdev_seek, dont
> refine sysfs_emit() logic, use EXPORT_SYMBOL_GPL instead of
> EXPORT_SYMBOL, remove ddcci_device_remove_void, remove module
> paramaters and version, and split into 2 patches.
> 
> v9: Fix IS_ANY_ID matching for compilers and archs where char is
> unsigned char and use the cannonical patch format.
> Reported-by: kernel test robot 
> 
> v10: Change patch title to "drivers: ddcci: add drivers for DDCCI
> and change" and change patch descriptions to add more detailed
> explanations of function.
> 
> Patch 1: Add the main DDCCI component.
> 
> Patch 2: Add the backlight driver that utilizes the DDCCI driver.
> 
> Patch 3: Add documentation for the DDCCI drivers.
> 
> Yusuf Khan (3):
>   drivers: ddcci: add drivers for DDCCI
>   drivers: ddcci: add drivers for DDCCI
>   drivers: ddcci: add drivers for DDCCI
> 
>  Documentation/ABI/testing/sysfs-driver-ddcci |   57 +
>  Documentation/driver-api/ddcci.rst   |  122 ++
>  drivers/char/Kconfig |   11 +
>  drivers/char/Makefile|1 +
>  drivers/char/ddcci.c | 1805 ++
>  drivers/video/backlight/Kconfig  |   11 +
>  drivers/video/backlight/Makefile |