Re: [PATCH 01/10] drm/ttm: allocate resource object instead of embedding it v2

[Intel]

Hi,

On 6/7/21 7:59 PM, Christian König wrote:



Am 07.06.21 um 19:58 schrieb Thomas Hellström (Intel):


On 6/7/21 7:54 PM, Christian König wrote:



Am 07.06.21 um 19:06 schrieb Thomas Hellström (Intel):


On 6/7/21 6:40 PM, Thomas Hellström (Intel) wrote:


On 6/2/21 12:09 PM, Christian König wrote:
...
@@ -728,14 +728,15 @@ static int ttm_bo_add_move_fence(struct 
ttm_buffer_object *bo,

   */
  static int ttm_bo_mem_force_space(struct ttm_buffer_object *bo,
    const struct ttm_place *place,
-  struct ttm_resource *mem,
+  struct ttm_resource **mem,
    struct ttm_operation_ctx *ctx)
  {
  struct ttm_device *bdev = bo->bdev;
-    struct ttm_resource_manager *man = ttm_manager_type(bdev, 
mem->mem_type);

+    struct ttm_resource_manager *man;
  struct ww_acquire_ctx *ticket;
  int ret;
  +    man = ttm_manager_type(bdev, (*mem)->mem_type);


Isn't (*mem) uninitialized here? Should be place->mem_type? 
Eviction is immediately sent to the bushes.


Got at least one additional NULL pointer deref to track down in 
the eviction code, but could be a merge error of mine as well.


Actually this last one was probably due to a bad temporary fix of 
the above one.


I've found one more warning during my testing now. But that is just 
a false positive.


Apart from that I haven't seen any other fallout, but fingers crossed.


vmwgfx doesn't seem to happy. It works AFAICT., but warns in 
vmw_move() about ttm_bo_assign_mem() replacing an existing resource.


Yeah, that's the one I've just fixed. Patch is underway.


If that's the move_to_ghost patch, I don't think that would fix the 
vmwgfx issue, as IIRC vmwgfx ever uses ghost objects.


/Thomas

[PATCH] drm: display: Remove duplicate include in dce110

[Wan Jiabing]

Fix the following checkincludes.pl warning:
./drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c
35  #include "dce110_hw_sequencer.h"
69  #include "dce110_hw_sequencer.h"


Signed-off-by: Wan Jiabing 
---
 drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c 
b/drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c
index a08cd52f6ba8..e20d4def3eb9 100644
--- a/drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c
+++ b/drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c
@@ -66,7 +66,6 @@
 
 #include "atomfirmware.h"
 
-#include "dce110_hw_sequencer.h"
 #include "dcn10/dcn10_hw_sequencer.h"
 
 #define GAMMA_HW_POINTS_NUM 256
-- 
2.20.1

linux-next: build failure after merge of the drm-misc tree

[Stephen Rothwell]

Hi all,

After merging the drm-misc tree, today's linux-next build (x86_64
allmodconfig) failed like this:

drivers/gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c: In function 
'amdgpu_preempt_mgr_new':
drivers/gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c:75:5: error: 'struct 
ttm_resource' has no member named 'mm_node'
   75 |  mem->mm_node = NULL;
  | ^~
drivers/gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c: At top level:
drivers/gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c:129:11: error: initialization 
of 'int (*)(struct ttm_resource_manager *, struct ttm_buffer_object *, const 
struct ttm_place *, struct ttm_resource **)' from incompatible pointer type 
'int (*)(struct ttm_resource_manager *, struct ttm_buffer_object *, const 
struct ttm_place *, struct ttm_resource *)' [-Werror=incompatible-pointer-types]
  129 |  .alloc = amdgpu_preempt_mgr_new,
  |   ^~
drivers/gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c:129:11: note: (near 
initialization for 'amdgpu_preempt_mgr_func.alloc')

Caused by commit

  cb1c81467af3 ("drm/ttm: flip the switch for driver allocated resources v2")

from the drm-misc tree interacting with commit

  b453e42a6e8b ("drm/amdgpu: Add new placement for preemptible SG BOs")

from the drm tree.

I don't know how to fix this, so I added the following hack (a better
fix would be nice):

From: Stephen Rothwell 
Date: Tue, 8 Jun 2021 12:41:16 +1000
Subject: [PATCH] hack fix up for needed amdgpu_preempt_mgr_new() fix up

Signed-off-by: Stephen Rothwell 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c
index d607f314cc1b..e1a7b3e967b9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c
@@ -66,14 +66,16 @@ static DEVICE_ATTR_RO(mem_info_preempt_used);
 static int amdgpu_preempt_mgr_new(struct ttm_resource_manager *man,
  struct ttm_buffer_object *tbo,
  const struct ttm_place *place,
- struct ttm_resource *mem)
+ struct ttm_resource **res)
 {
+#if 0
struct amdgpu_preempt_mgr *mgr = to_preempt_mgr(man);
 
atomic64_add(mem->num_pages, >used);
 
mem->mm_node = NULL;
mem->start = AMDGPU_BO_INVALID_OFFSET;
+#endif
return 0;
 }
 
-- 
2.30.2

-- 
Cheers,
Stephen Rothwell


pgpXwT3TT63iB.pgp
Description: OpenPGP digital signature

Re: [PATCH 08/13] drm/i915/guc: New CTB based communication

[Daniele Ceraolo Spurio]

On 6/7/2021 11:03 AM, Matthew Brost wrote:

From: Michal Wajdeczko 

Format of the CTB messages has changed:
  - support for multiple formats
  - message fence is now part of the header
  - reuse of unified HXG message formats

Signed-off-by: Michal Wajdeczko 
Signed-off-by: Matthew Brost 
Cc: Piotr Piórkowski 
---
  .../gt/uc/abi/guc_communication_ctb_abi.h |  56 +
  drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 194 +++---
  drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h |   2 +-
  3 files changed, 135 insertions(+), 117 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h 
b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
index 127b256a662c..92660726c094 100644
--- a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
+++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
@@ -60,6 +60,62 @@ struct guc_ct_buffer_desc {
  } __packed;
  static_assert(sizeof(struct guc_ct_buffer_desc) == 64);
  
+/**

+ * DOC: CTB Message
+ *
+ *  
+---+---+--+
+ *  |   | Bits  | Description  
|
+ *  
+===+===+==+
+ *  | 0 | 31:16 | **FENCE** - message identifier   
|
+ *  |   
+---+--+
+ *  |   | 15:12 | **FORMAT** - format of the CTB message   
|
+ *  |   |   |  - _`GUC_CTB_FORMAT_HXG` = 0 - see `CTB HXG Message`_
|
+ *  |   
+---+--+
+ *  |   |  11:8 | **RESERVED** 
|
+ *  |   
+---+--+
+ *  |   |   7:0 | **NUM_DWORDS** - length of the CTB message (w/o header)  
|
+ *  
+---+---+--+
+ *  | 1 |  31:0 | optional (depends on FORMAT) 
|
+ *  +---+---+  
|
+ *  |...|   |  
|
+ *  +---+---+  
|
+ *  | n |  31:0 |  
|
+ *  
+---+---+--+
+ */
+
+#define GUC_CTB_MSG_MIN_LEN1u
+#define GUC_CTB_MSG_MAX_LEN256u
+#define GUC_CTB_MSG_0_FENCE(0x << 16)
+#define GUC_CTB_MSG_0_FORMAT   (0xf << 12)
+#define   GUC_CTB_FORMAT_HXG   0u
+#define GUC_CTB_MSG_0_RESERVED (0xf << 8)
+#define GUC_CTB_MSG_0_NUM_DWORDS   (0xff << 0)
+
+/**
+ * DOC: CTB HXG Message
+ *
+ *  
+---+---+--+
+ *  |   | Bits  | Description  
|
+ *  
+===+===+==+
+ *  | 0 | 31:16 | FENCE
|
+ *  |   
+---+--+
+ *  |   | 15:12 | FORMAT = GUC_CTB_FORMAT_HXG_ 
|
+ *  |   
+---+--+
+ *  |   |  11:8 | RESERVED = MBZ   
|
+ *  |   
+---+--+
+ *  |   |   7:0 | NUM_DWORDS = length (in dwords) of the embedded HXG message  
|
+ *  
+---+---+--+
+ *  | 1 |  31:0 |  ++  
|
+ *  +---+---+  ||  
|
+ *  |...|   |  |  Embedded `HXG Message`_   |  
|
+ *  +---+---+  ||  
|
+ *  | n |  31:0 |  ++  
|
+ *  
+---+---+--+
+ */
+
+#define GUC_CTB_HXG_MSG_MIN_LEN(GUC_CTB_MSG_MIN_LEN + 
GUC_HXG_MSG_MIN_LEN)
+#define GUC_CTB_HXG_MSG_MAX_LENGUC_CTB_MSG_MAX_LEN
+
  /**
   * DOC: CTB based communication
   *
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index 6a29be779cc9..729f29bc2a57 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -365,24 +365,6 @@ static void write_barrier(struct intel_guc_ct *ct)
}
  }
  
-/**

- * DOC: CTB Host to GuC request
- *
- * Format of the CTB Host to GuC request 

Re: [PATCH v3] drm/msm/dsi: add continuous clock support for 7nm PHY

[abhinavk]

On 2021-06-07 16:00, Dmitry Baryshkov wrote:

Unlike previous generations, 7nm PHYs are required to collaborate with
the host for conitnuos clock mode. Add changes neccessary to enable

"the host for continuous clock mode"

continuous clock mode in the 7nm DSI PHYs.

Signed-off-by: Dmitry Baryshkov 
---

Changes since v2:
 - Really drop msm_dsi_phy_needs_hs_phy_sel()

Changes since v1:
 - Remove the need for a separate msm_dsi_phy_needs_hs_phy_sel() call
 - Fix setting continuous clock for a dual DSI case.

Maybe I am missing something but I cannot find this part of the change.
What has been fixed for dual DSI?


---
 drivers/gpu/drm/msm/dsi/dsi.h |  3 ++-
 drivers/gpu/drm/msm/dsi/dsi.xml.h |  1 +
 drivers/gpu/drm/msm/dsi/dsi_host.c| 12 
 drivers/gpu/drm/msm/dsi/dsi_manager.c |  4 ++--
 drivers/gpu/drm/msm/dsi/phy/dsi_phy.c |  9 +
 drivers/gpu/drm/msm/dsi/phy/dsi_phy.h |  1 +
 drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c | 17 +
 7 files changed, 40 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi.h 
b/drivers/gpu/drm/msm/dsi/dsi.h

index 7abfeab08165..5be458c701d2 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.h
+++ b/drivers/gpu/drm/msm/dsi/dsi.h
@@ -108,7 +108,7 @@ int msm_dsi_host_enable(struct mipi_dsi_host 
*host);

 int msm_dsi_host_disable(struct mipi_dsi_host *host);
 int msm_dsi_host_power_on(struct mipi_dsi_host *host,
struct msm_dsi_phy_shared_timings *phy_shared_timings,
-   bool is_dual_dsi);
+   bool is_dual_dsi, struct msm_dsi_phy *phy);
 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);
@@ -173,6 +173,7 @@ int msm_dsi_phy_get_clk_provider(struct msm_dsi_phy 
*phy,

struct clk **byte_clk_provider, struct clk **pixel_clk_provider);
 void msm_dsi_phy_pll_save_state(struct msm_dsi_phy *phy);
 int msm_dsi_phy_pll_restore_state(struct msm_dsi_phy *phy);
+bool msm_dsi_phy_set_continuous_clock(struct msm_dsi_phy *phy, bool 
enable);


 #endif /* __DSI_CONNECTOR_H__ */

diff --git a/drivers/gpu/drm/msm/dsi/dsi.xml.h
b/drivers/gpu/drm/msm/dsi/dsi.xml.h
index 50eb4d1b8fdd..9762af6035e9 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.xml.h
+++ b/drivers/gpu/drm/msm/dsi/dsi.xml.h
@@ -510,6 +510,7 @@ static inline uint32_t
DSI_CLKOUT_TIMING_CTRL_T_CLK_POST(uint32_t val)
 #define DSI_LANE_STATUS_DLN0_DIRECTION 0x0001

 #define REG_DSI_LANE_CTRL  0x00a8
+#define DSI_LANE_CTRL_HS_REQ_SEL_PHY   0x0100
 #define DSI_LANE_CTRL_CLKLN_HS_FORCE_REQUEST   0x1000

 #define REG_DSI_LANE_SWAP_CTRL 0x00ac
diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 41e1d0f7ab6e..50be935edcad 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -835,7 +835,7 @@ static inline enum dsi_cmd_dst_format 
dsi_get_cmd_fmt(

 }

 static void dsi_ctrl_config(struct msm_dsi_host *msm_host, bool 
enable,

-   struct msm_dsi_phy_shared_timings *phy_shared_timings)
+   struct msm_dsi_phy_shared_timings *phy_shared_timings, 
struct
msm_dsi_phy *phy)
 {
u32 flags = msm_host->mode_flags;
enum mipi_dsi_pixel_format mipi_fmt = msm_host->format;
@@ -930,6 +930,10 @@ static void dsi_ctrl_config(struct msm_dsi_host
*msm_host, bool enable,

if (!(flags & MIPI_DSI_CLOCK_NON_CONTINUOUS)) {
lane_ctrl = dsi_read(msm_host, REG_DSI_LANE_CTRL);
+
+   if (msm_dsi_phy_set_continuous_clock(phy, enable))
+   lane_ctrl |= DSI_LANE_CTRL_HS_REQ_SEL_PHY;
+
Not sure how I missed this in the prev patch but for enabling continuous 
clock mode for new PHY, you need to clear bit 24
and not set it. If you set it, it goes back to legacy mode ( older 
method of continuous clock mode )

dsi_write(msm_host, REG_DSI_LANE_CTRL,
lane_ctrl | DSI_LANE_CTRL_CLKLN_HS_FORCE_REQUEST);
}
@@ -2360,7 +2364,7 @@ static void msm_dsi_sfpb_config(struct
msm_dsi_host *msm_host, bool enable)

 int msm_dsi_host_power_on(struct mipi_dsi_host *host,
struct msm_dsi_phy_shared_timings *phy_shared_timings,
-   bool is_dual_dsi)
+   bool is_dual_dsi, struct msm_dsi_phy *phy)
 {
struct msm_dsi_host *msm_host = to_msm_dsi_host(host);
const struct msm_dsi_cfg_handler *cfg_hnd = msm_host->cfg_hnd;
@@ -2400,7 +2404,7 @@ int msm_dsi_host_power_on(struct mipi_dsi_host 
*host,


dsi_timing_setup(msm_host, is_dual_dsi);
dsi_sw_reset(msm_host);
-   dsi_ctrl_config(msm_host, true, phy_shared_timings);
+   dsi_ctrl_config(msm_host, 

Re: [PATCH 07/13] drm/i915/guc: New definition of the CTB registration action

[Daniele Ceraolo Spurio]

On 6/7/2021 11:03 AM, Matthew Brost wrote:

From: Michal Wajdeczko 

Definition of the CTB registration action has changed.
Add some ABI documentation and implement required changes.

Signed-off-by: Michal Wajdeczko 
Signed-off-by: Matthew Brost 
Cc: Piotr Piórkowski  #4
---
  .../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h  | 107 ++
  .../gt/uc/abi/guc_communication_ctb_abi.h |   4 -
  drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c |  76 -
  3 files changed, 152 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h 
b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
index 90efef8a73e4..6426fc183692 100644
--- a/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
+++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
@@ -6,6 +6,113 @@
  #ifndef _ABI_GUC_ACTIONS_ABI_H
  #define _ABI_GUC_ACTIONS_ABI_H
  
+/**

+ * DOC: HOST2GUC_REGISTER_CTB
+ *
+ * This message is used as part of the `CTB based communication`_ setup.
+ *
+ * This message must be sent as `MMIO HXG Message`_.
+ *
+ *  
+---+---+--+
+ *  |   | Bits  | Description  
|
+ *  
+===+===+==+
+ *  | 0 |31 | ORIGIN = GUC_HXG_ORIGIN_HOST_
|
+ *  |   
+---+--+
+ *  |   | 30:28 | TYPE = GUC_HXG_TYPE_REQUEST_ 
|
+ *  |   
+---+--+
+ *  |   | 27:16 | DATA0 = MBZ  
|
+ *  |   
+---+--+
+ *  |   |  15:0 | ACTION = _`GUC_ACTION_HOST2GUC_REGISTER_CTB` = 0x5200
|


Specs says 4505


+ *  
+---+---+--+
+ *  | 1 | 31:12 | RESERVED = MBZ   
|
+ *  |   
+---+--+
+ *  |   |  11:8 | **TYPE** - type for the `CT Buffer`_ 
|
+ *  |   |   |  
|
+ *  |   |   |   - _`GUC_CTB_TYPE_HOST2GUC` = 0 
|
+ *  |   |   |   - _`GUC_CTB_TYPE_GUC2HOST` = 1 
|
+ *  |   
+---+--+
+ *  |   |   7:0 | **SIZE** - size of the `CT Buffer`_ in 4K units minus 1  
|
+ *  
+---+---+--+
+ *  | 2 |  31:0 | **DESC_ADDR** - GGTT address of the `CTB Descriptor`_
|
+ *  
+---+---+--+
+ *  | 3 |  31:0 | **BUFF_ADDF** - GGTT address of the `CT Buffer`_ 
|
+ *  
+---+---+--+
+*
+ *  
+---+---+--+
+ *  |   | Bits  | Description  
|
+ *  
+===+===+==+
+ *  | 0 |31 | ORIGIN = GUC_HXG_ORIGIN_GUC_ 
|
+ *  |   
+---+--+
+ *  |   | 30:28 | TYPE = GUC_HXG_TYPE_RESPONSE_SUCCESS_
|
+ *  |   
+---+--+
+ *  |   |  27:0 | DATA0 = MBZ  
|
+ *  
+---+---+--+
+ */
+#define GUC_ACTION_HOST2GUC_REGISTER_CTB   0x4505 // FIXME 0x5200


Why FIXME? AFAICS the specs still says 4505, even if we plan to update 
at some point I don;t think this deserves a FIXME since nothing is 
incorrect.



+
+#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_LEN  
(GUC_HXG_REQUEST_MSG_MIN_LEN + 3u)
+#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_0_MBZ
GUC_HXG_REQUEST_MSG_0_DATA0
+#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_MBZ(0xf << 12)
+#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_TYPE   (0xf << 8)
+#define   GUC_CTB_TYPE_HOST2GUC0u
+#define   GUC_CTB_TYPE_GUC2HOST1u
+#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_SIZE   (0xff << 0)
+#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_2_DESC_ADDR  
GUC_HXG_REQUEST_MSG_n_DATAn
+#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_3_BUFF_ADDR  
GUC_HXG_REQUEST_MSG_n_DATAn


The full mask still seems like overkill to me and I still think we 
should use BIT()/GENMASK() and a _MASK prefix, but not going to block on it.



+
+#define HOST2GUC_REGISTER_CTB_RESPONSE_MSG_LEN 

Re: [PATCH 06/13] drm/i915/guc: New definition of the CTB descriptor

[Daniele Ceraolo Spurio]

On 6/7/2021 11:03 AM, Matthew Brost wrote:

From: Michal Wajdeczko 

Definition of the CTB descriptor has changed, leaving only
minimal shared fields like HEAD/TAIL/STATUS.

Both HEAD and TAIL are now in dwords.

Add some ABI documentation and implement required changes.

Signed-off-by: Michal Wajdeczko 
Signed-off-by: Matthew Brost 
---
  .../gt/uc/abi/guc_communication_ctb_abi.h | 70 ++-
  drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 70 +--
  drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h |  2 +-
  3 files changed, 85 insertions(+), 57 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h 
b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
index d38935f47ecf..c2a069a78e01 100644
--- a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
+++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
@@ -7,6 +7,58 @@
  #define _ABI_GUC_COMMUNICATION_CTB_ABI_H
  
  #include 

+#include 
+
+#include "guc_messages_abi.h"
+
+/**
+ * DOC: CT Buffer
+ *
+ * TBD


What's the plan with this TBD here?


+ */
+
+/**
+ * DOC: CTB Descriptor
+ *
+ *  
+---+---+--+
+ *  |   | Bits  | Description  
|
+ *  
+===+===+==+
+ *  | 0 |  31:0 | **HEAD** - offset (in dwords) to the last dword that was 
|
+ *  |   |   | read from the `CT Buffer`_.  
|
+ *  |   |   | It can only be updated by the receiver.  
|
+ *  
+---+---+--+
+ *  | 1 |  31:0 | **TAIL** - offset (in dwords) to the last dword that was 
|
+ *  |   |   | written to the `CT Buffer`_. 
|
+ *  |   |   | It can only be updated by the sender.
|
+ *  
+---+---+--+
+ *  | 2 |  31:0 | **STATUS** - status of the CTB   
|
+ *  |   |   |  
|
+ *  |   |   |   - _`GUC_CTB_STATUS_NO_ERROR` = 0 (normal operation)
|
+ *  |   |   |   - _`GUC_CTB_STATUS_OVERFLOW` = 1 (head/tail too large) 
|
+ *  |   |   |   - _`GUC_CTB_STATUS_UNDERFLOW` = 2 (truncated message)  
|
+ *  |   |   |   - _`GUC_CTB_STATUS_MISMATCH` = 4 (head/tail modified)  
|
+ *  |   |   |   - _`GUC_CTB_STATUS_NO_BACKCHANNEL` = 8 
|
+ *  |   |   |   - _`GUC_CTB_STATUS_MALFORMED_MSG` = 16 
|


I don't see the last 2 error (8 & 16) in the 62.0.0 specs. Where is the 
reference for them?



+ *  
+---+---+--+
+ *  |...|   | RESERVED = MBZ   
|
+ *  
+---+---+--+
+ *  | 15|  31:0 | RESERVED = MBZ   
|
+ *  
+---+---+--+
+ */
+
+struct guc_ct_buffer_desc {
+   u32 head;
+   u32 tail;
+   u32 status;
+#define GUC_CTB_STATUS_NO_ERROR0
+#define GUC_CTB_STATUS_OVERFLOW(1 << 0)
+#define GUC_CTB_STATUS_UNDERFLOW   (1 << 1)
+#define GUC_CTB_STATUS_MISMATCH(1 << 2)
+#define GUC_CTB_STATUS_NO_BACKCHANNEL  (1 << 3)
+#define GUC_CTB_STATUS_MALFORMED_MSG   (1 << 4)


use BIT() ?


+   u32 reserved[13];
+} __packed;
+static_assert(sizeof(struct guc_ct_buffer_desc) == 64);
  
  /**

   * DOC: CTB based communication
@@ -60,24 +112,6 @@
   * - **flags**, holds various bits to control message handling
   */
  
-/*

- * Describes single command transport buffer.
- * Used by both guc-master and clients.
- */
-struct guc_ct_buffer_desc {
-   u32 addr;   /* gfx address */
-   u64 host_private;   /* host private data */
-   u32 size;   /* size in bytes */
-   u32 head;   /* offset updated by GuC*/
-   u32 tail;   /* offset updated by owner */
-   u32 is_in_error;/* error indicator */
-   u32 reserved1;
-   u32 reserved2;
-   u32 owner;  /* id of the channel owner */
-   u32 owner_sub_id;   /* owner-defined field for extra tracking */
-   u32 reserved[5];
-} __packed;
-
  /* Type of command transport buffer */
  #define INTEL_GUC_CT_BUFFER_TYPE_SEND 0x0u
  #define INTEL_GUC_CT_BUFFER_TYPE_RECV 0x1u
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index 63056ea0631e..3241a477196f 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ 

[PATCH 06/10] vfio/mdev: Remove CONFIG_VFIO_MDEV_DEVICE

[Jason Gunthorpe]

For some reason the vfio_mdev shim mdev_driver has its own module and
kconfig. As the next patch requires access to it from mdev.ko merge the
two modules together and remove VFIO_MDEV_DEVICE.

A later patch deletes this driver entirely.

Signed-off-by: Jason Gunthorpe 
---
 Documentation/s390/vfio-ap.rst   |  1 -
 arch/s390/Kconfig|  2 +-
 drivers/gpu/drm/i915/Kconfig |  2 +-
 drivers/vfio/mdev/Kconfig|  7 ---
 drivers/vfio/mdev/Makefile   |  3 +--
 drivers/vfio/mdev/mdev_core.c| 16 ++--
 drivers/vfio/mdev/mdev_private.h |  2 ++
 drivers/vfio/mdev/vfio_mdev.c| 24 +---
 samples/Kconfig  |  6 +++---
 9 files changed, 23 insertions(+), 40 deletions(-)

diff --git a/Documentation/s390/vfio-ap.rst b/Documentation/s390/vfio-ap.rst
index e15436599086b7..f57ae621f33e89 100644
--- a/Documentation/s390/vfio-ap.rst
+++ b/Documentation/s390/vfio-ap.rst
@@ -514,7 +514,6 @@ These are the steps:
* S390_AP_IOMMU
* VFIO
* VFIO_MDEV
-   * VFIO_MDEV_DEVICE
* KVM
 
If using make menuconfig select the following to build the vfio_ap module::
diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index b4c7c34069f81a..ea63fd22e1198a 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -768,7 +768,7 @@ config VFIO_CCW
 config VFIO_AP
def_tristate n
prompt "VFIO support for AP devices"
-   depends on S390_AP_IOMMU && VFIO_MDEV_DEVICE && KVM
+   depends on S390_AP_IOMMU && VFIO_MDEV && KVM
depends on ZCRYPT
help
This driver grants access to Adjunct Processor (AP) devices
diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index 69f57ca9c68d73..9ab1cecd69b2a0 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -126,7 +126,7 @@ config DRM_I915_GVT_KVMGT
tristate "Enable KVM/VFIO support for Intel GVT-g"
depends on DRM_I915_GVT
depends on KVM
-   depends on VFIO_MDEV && VFIO_MDEV_DEVICE
+   depends on VFIO_MDEV
default n
help
  Choose this option if you want to enable KVMGT support for
diff --git a/drivers/vfio/mdev/Kconfig b/drivers/vfio/mdev/Kconfig
index 5da27f2100f9bd..763c877a1318bc 100644
--- a/drivers/vfio/mdev/Kconfig
+++ b/drivers/vfio/mdev/Kconfig
@@ -9,10 +9,3 @@ config VFIO_MDEV
  See Documentation/driver-api/vfio-mediated-device.rst for more 
details.
 
  If you don't know what do here, say N.
-
-config VFIO_MDEV_DEVICE
-   tristate "VFIO driver for Mediated devices"
-   depends on VFIO && VFIO_MDEV
-   default n
-   help
- VFIO based driver for Mediated devices.
diff --git a/drivers/vfio/mdev/Makefile b/drivers/vfio/mdev/Makefile
index 101516fdf3753e..ff9ecd80212503 100644
--- a/drivers/vfio/mdev/Makefile
+++ b/drivers/vfio/mdev/Makefile
@@ -1,6 +1,5 @@
 # SPDX-License-Identifier: GPL-2.0-only
 
-mdev-y := mdev_core.o mdev_sysfs.o mdev_driver.o
+mdev-y := mdev_core.o mdev_sysfs.o mdev_driver.o vfio_mdev.o
 
 obj-$(CONFIG_VFIO_MDEV) += mdev.o
-obj-$(CONFIG_VFIO_MDEV_DEVICE) += vfio_mdev.o
diff --git a/drivers/vfio/mdev/mdev_core.c b/drivers/vfio/mdev/mdev_core.c
index 2a85d6fcb7ddd0..ff8c1a84516698 100644
--- a/drivers/vfio/mdev/mdev_core.c
+++ b/drivers/vfio/mdev/mdev_core.c
@@ -360,11 +360,24 @@ int mdev_device_remove(struct mdev_device *mdev)
 
 static int __init mdev_init(void)
 {
-   return mdev_bus_register();
+   int rc;
+
+   rc = mdev_bus_register();
+   if (rc)
+   return rc;
+   rc = mdev_register_driver(_mdev_driver);
+   if (rc)
+   goto err_bus;
+   return 0;
+err_bus:
+   mdev_bus_unregister();
+   return rc;
 }
 
 static void __exit mdev_exit(void)
 {
+   mdev_unregister_driver(_mdev_driver);
+
if (mdev_bus_compat_class)
class_compat_unregister(mdev_bus_compat_class);
 
@@ -378,4 +391,3 @@ MODULE_VERSION(DRIVER_VERSION);
 MODULE_LICENSE("GPL v2");
 MODULE_AUTHOR(DRIVER_AUTHOR);
 MODULE_DESCRIPTION(DRIVER_DESC);
-MODULE_SOFTDEP("post: vfio_mdev");
diff --git a/drivers/vfio/mdev/mdev_private.h b/drivers/vfio/mdev/mdev_private.h
index 6999c89db7b162..afbad7b0a14a17 100644
--- a/drivers/vfio/mdev/mdev_private.h
+++ b/drivers/vfio/mdev/mdev_private.h
@@ -37,6 +37,8 @@ struct mdev_type {
 #define to_mdev_type(_kobj)\
container_of(_kobj, struct mdev_type, kobj)
 
+extern struct mdev_driver vfio_mdev_driver;
+
 int  parent_create_sysfs_files(struct mdev_parent *parent);
 void parent_remove_sysfs_files(struct mdev_parent *parent);
 
diff --git a/drivers/vfio/mdev/vfio_mdev.c b/drivers/vfio/mdev/vfio_mdev.c
index 922729071c5a8e..d5b4eede47c1a5 100644
--- a/drivers/vfio/mdev/vfio_mdev.c
+++ b/drivers/vfio/mdev/vfio_mdev.c
@@ -17,10 +17,6 @@
 
 #include "mdev_private.h"
 
-#define DRIVER_VERSION  "0.1"
-#define DRIVER_AUTHOR   "NVIDIA Corporation"
-#define DRIVER_DESC "VFIO based driver for Mediated 

[PATCH 00/10] Allow mdev drivers to directly create the vfio_device

[Jason Gunthorpe]

This is a "v3" of the previous posted full conversion:
  https://lore.kernel.org/r/0-v2-7667f42c9bad+935-vfio3_...@nvidia.com

Without the trailing patches that are running into complications:
 - The CCW conversion has some complicated remarks
 - AP is waiting for some locking stuff to get worked out
 - No feedback on GT
 - The license change topic for removing vfio_mdev.c

Getting the baseline functionality merged will allow Intel's IDXD mdev
driver to advance. It has already been RFC posted in the new format:

https://lore.kernel.org/kvm/162164243591.261970.3439987543338120797.st...@djiang5-desk3.ch.intel.com/

This series includes base infrastructure and the sample conversions. The
remaining four issues can be sorted out one by one.

The major change in v3 is to enhance the driver core support for binding
based on the request from Christoph Hellwig and Dan Williams. Based on
some light analysis this looks broadly useful:

https://lore.kernel.org/kvm/20210428233856.gy1370...@nvidia.com/



The mdev bus's core part for managing the lifecycle of devices is mostly
as one would expect for a driver core bus subsystem.

However instead of having a normal 'struct device_driver' and binding the
actual mdev drivers through the standard driver core mechanisms it open
codes this with the struct mdev_parent_ops and provides a single driver
that shims between the VFIO core's struct vfio_device and the actual
device driver.

Instead, allow mdev drivers implement an actual struct mdev_driver and
directly call vfio_register_group_dev() in the probe() function for the
mdev. Arrange to bind the created mdev_device to the mdev_driver that is
provided by the end driver.

The actual execution flow doesn't change much, eg what was
parent_ops->create is now device_driver->probe and it is called at almost
the exact same time - except under the normal control of the driver core.

Ultimately converting all the drivers unlocks a fair number of additional
VFIO simplifications and cleanups.

v3:
 - Use device_driver_attach() from the driver core
 - 5 new patches to make device_driver_attach() exported and usable for this
 - Remove trailing patches for now
v2: https://lore.kernel.org/r/0-v2-7667f42c9bad+935-vfio3_...@nvidia.com
 - Keep && m in samples kconfig
 - Restore accidently squashed removeal of vfio_mdev.c
 - Remove indirections to call bus_register()/bus_unregister()
 - Reflow long doc lines
v1: https://lore.kernel.org/r/0-v1-d88406ed308e+418-vfio3_...@nvidia.com

Jason Gunthorpe (10):
  driver core: Do not continue searching for drivers if deferred probe
is used
  driver core: Pull required checks into driver_probe_device()
  driver core: Flow the return code from ->probe() through to sysfs bind
  driver core: Don't return EPROBE_DEFER to userspace during sysfs bind
  driver core: Export device_driver_attach()
  vfio/mdev: Remove CONFIG_VFIO_MDEV_DEVICE
  vfio/mdev: Allow the mdev_parent_ops to specify the device driver to
bind
  vfio/mtty: Convert to use vfio_register_group_dev()
  vfio/mdpy: Convert to use vfio_register_group_dev()
  vfio/mbochs: Convert to use vfio_register_group_dev()

 Documentation/s390/vfio-ap.rst   |   1 -
 arch/s390/Kconfig|   2 +-
 drivers/base/base.h  |   1 -
 drivers/base/bus.c   |   6 +-
 drivers/base/dd.c| 116 ---
 drivers/gpu/drm/i915/Kconfig |   2 +-
 drivers/vfio/mdev/Kconfig|   7 --
 drivers/vfio/mdev/Makefile   |   3 +-
 drivers/vfio/mdev/mdev_core.c|  46 ++--
 drivers/vfio/mdev/mdev_driver.c  |  10 ++
 drivers/vfio/mdev/mdev_private.h |   2 +
 drivers/vfio/mdev/vfio_mdev.c|  24 +---
 include/linux/device.h   |   2 +
 include/linux/mdev.h |   2 +
 samples/Kconfig  |   6 +-
 samples/vfio-mdev/mbochs.c   | 163 +++
 samples/vfio-mdev/mdpy.c | 159 ++
 samples/vfio-mdev/mtty.c | 185 ++-
 18 files changed, 397 insertions(+), 340 deletions(-)

-- 
2.31.1

Re: [RFC PATCH v2 1/8] ext4/xfs: add page refcount helper

[Liam Howlett]

* Alex Sierra  [210607 16:43]:
> From: Ralph Campbell 
> 
> There are several places where ZONE_DEVICE struct pages assume a reference
> count == 1 means the page is idle and free. Instead of open coding this,
> add a helper function to hide this detail.
> 
> Signed-off-by: Ralph Campbell 
> ---
>  fs/dax.c|  4 ++--
>  fs/ext4/inode.c |  5 +
>  fs/xfs/xfs_file.c   |  4 +---
>  include/linux/dax.h | 10 ++
>  4 files changed, 14 insertions(+), 9 deletions(-)
> 
> diff --git a/fs/dax.c b/fs/dax.c
> index 26d5dcd2d69e..321f4ddc6643 100644
> --- a/fs/dax.c
> +++ b/fs/dax.c
> @@ -358,7 +358,7 @@ static void dax_disassociate_entry(void *entry, struct 
> address_space *mapping,
>   for_each_mapped_pfn(entry, pfn) {
>   struct page *page = pfn_to_page(pfn);
>  
> - WARN_ON_ONCE(trunc && page_ref_count(page) > 1);
> + WARN_ON_ONCE(trunc && !dax_layout_is_idle_page(page));
>   WARN_ON_ONCE(page->mapping && page->mapping != mapping);
>   page->mapping = NULL;
>   page->index = 0;
> @@ -372,7 +372,7 @@ static struct page *dax_busy_page(void *entry)
>   for_each_mapped_pfn(entry, pfn) {
>   struct page *page = pfn_to_page(pfn);
>  
> - if (page_ref_count(page) > 1)
> + if (!dax_layout_is_idle_page(page))
>   return page;
>   }
>   return NULL;
> diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
> index c173c8405856..9ee00186412f 100644
> --- a/fs/ext4/inode.c
> +++ b/fs/ext4/inode.c
> @@ -3972,10 +3972,7 @@ int ext4_break_layouts(struct inode *inode)
>   if (!page)
>   return 0;
>  
> - error = ___wait_var_event(>_refcount,
> - atomic_read(>_refcount) == 1,
> - TASK_INTERRUPTIBLE, 0, 0,
> - ext4_wait_dax_page(ei));
> + error = dax_wait_page(ei, page, ext4_wait_dax_page);
>   } while (error == 0);
>  
>   return error;
> diff --git a/fs/xfs/xfs_file.c b/fs/xfs/xfs_file.c
> index 5b0f93f73837..39565fe5f817 100644
> --- a/fs/xfs/xfs_file.c
> +++ b/fs/xfs/xfs_file.c
> @@ -782,9 +782,7 @@ xfs_break_dax_layouts(
>   return 0;
>  
>   *retry = true;
> - return ___wait_var_event(>_refcount,
> - atomic_read(>_refcount) == 1, TASK_INTERRUPTIBLE,
> - 0, 0, xfs_wait_dax_page(inode));
> + return dax_wait_page(inode, page, xfs_wait_dax_page);
>  }
>  
>  int
> diff --git a/include/linux/dax.h b/include/linux/dax.h
> index b52f084aa643..8909a91cd381 100644
> --- a/include/linux/dax.h
> +++ b/include/linux/dax.h
> @@ -243,6 +243,16 @@ static inline bool dax_mapping(struct address_space 
> *mapping)
>   return mapping->host && IS_DAX(mapping->host);
>  }
>  
> +static inline bool dax_layout_is_idle_page(struct page *page)
> +{
> + return page_ref_count(page) == 1;
> +}

If this races with page_ref_count(page) == 0, then it will return false
that a page is idle when the page is being freed.  I don't know the code
well enough to say if this is an issue or not so please let me know.

For example:
!dax_layout_is_idle_page() will return true in dax_busy_page() above
when the count is 0 and return the page.

Maybe you are sure to have at least one reference when calling this?  It
might be worth adding a comment.

> +
> +#define dax_wait_page(_inode, _page, _wait_cb)   
> \
> + ___wait_var_event(&(_page)->_refcount,  \
> + dax_layout_is_idle_page(_page), \
> + TASK_INTERRUPTIBLE, 0, 0, _wait_cb(_inode))
> +
>  #ifdef CONFIG_DEV_DAX_HMEM_DEVICES
>  void hmem_register_device(int target_nid, struct resource *r);
>  #else
> -- 
> 2.17.1
> 
> 

Re: [PATCH] drm/mediatek: remove redundant error log print

[Chun-Kuang Hu]

Hi, Bernard:

Bernard Zhao  於 2021年6月3日 週四 下午7:15寫道：
>
> Fix coccicheck warning:
> drivers/gpu/drm/mediatek/mtk_dsi.c:1074:2-9: line 1074 is
> redundant because platform_get_irq() already prints an error.
>
> Signed-off-by: Bernard Zhao 
> ---
>  drivers/gpu/drm/mediatek/mtk_dsi.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
> b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index ae403c67cbd9..e2e4fc8b1360 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -1082,10 +1082,8 @@ static int mtk_dsi_probe(struct platform_device *pdev)
>
> ret = devm_request_irq(>dev, irq_num, mtk_dsi_irq,
>IRQF_TRIGGER_NONE, dev_name(>dev), dsi);

devm_request_irq() would have below call stack to allocate memory.
When allocate memory fail, it would not print any error message,
doesn't it?

devm_request_irq() -> devm_request_threaded_irq() -> devres_alloc() ->
devres_alloc_node() -> alloc_dr() -> kmalloc_node_track_caller()

Regards,
Chun-Kuang.

> -   if (ret) {
> -   dev_err(>dev, "failed to request mediatek dsi irq\n");
> +   if (ret)
> goto err_unregister_host;
> -   }
>
> init_waitqueue_head(>irq_wait_queue);
>
> --
> 2.31.0
>

Re: [PATCH 03/13] drm/i915/guc: Update CTB response status definition

[Daniele Ceraolo Spurio]

On 6/7/2021 11:03 AM, Matthew Brost wrote:

From: Michal Wajdeczko 

Format of the STATUS dword in CTB response message now follows
definition of the HXG header. Update our code and remove any
obsolete legacy definitions.


This is kind of hard to review on its own against the specs, because 
there are larger changes to the CTB flows which AFAICS are part of patch 
8. If what you wanted to do here was a simple replacement of defines to 
keep the later patch simpler, then, considering all patches are going to 
be squashed anyway:


Reviewed-by: Daniele Ceraolo Spurio 

One suggestion below.



GuC: 55.0.0
Signed-off-by: Michal Wajdeczko 
Acked-by: Piotr Piórkowski 
---
  drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c   | 14 --
  drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 17 -
  2 files changed, 8 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index 8f7b148fef58..3f7f48611487 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -477,7 +477,9 @@ static int wait_for_ct_request_update(struct ct_request 
*req, u32 *status)
 * up to that length of time, then switch to a slower sleep-wait loop.
 * No GuC command should ever take longer than 10ms.
 */
-#define done INTEL_GUC_MSG_IS_RESPONSE(READ_ONCE(req->status))
+#define done \
+   (FIELD_GET(GUC_HXG_MSG_0_ORIGIN, READ_ONCE(req->status)) == \
+GUC_HXG_ORIGIN_GUC)
err = wait_for_us(done, 10);
if (err)
err = wait_for(done, 10);
@@ -532,21 +534,21 @@ static int ct_send(struct intel_guc_ct *ct,
if (unlikely(err))
goto unlink;
  
-	if (!INTEL_GUC_MSG_IS_RESPONSE_SUCCESS(*status)) {

+   if (FIELD_GET(GUC_HXG_MSG_0_TYPE, *status) != 
GUC_HXG_TYPE_RESPONSE_SUCCESS) {
err = -EIO;
goto unlink;
}
  
  	if (response_buf) {

/* There shall be no data in the status */
-   WARN_ON(INTEL_GUC_MSG_TO_DATA(request.status));
+   WARN_ON(FIELD_GET(GUC_HXG_RESPONSE_MSG_0_DATA0, 
request.status));
/* Return actual response len */
err = request.response_len;
} else {
/* There shall be no response payload */
WARN_ON(request.response_len);
/* Return data decoded from the status dword */
-   err = INTEL_GUC_MSG_TO_DATA(*status);
+   err = FIELD_GET(GUC_HXG_RESPONSE_MSG_0_DATA0, *status);


Given that the same FIELD_GET() are repeated multiple times, IMO we 
could've kept some helper macros, something like:


INTEL_GUC_HXG_RESPONSE_TO_DATA(hxg) \
FIELD_GET(GUC_HXG_RESPONSE_MSG_0_DATA0, hxg)

INTEL_GUC_HXG_ORIGIN_IS_GUC(hxg) \
(FIELD_GET(GUC_HXG_MSG_0_ORIGIN, hxg) == GUC_HXG_ORIGIN_GUC)

INTEL_GUC_HXG_TYPE(hxg) \
FIELD_GET(GUC_HXG_MSG_0_TYPE, hxg)

Which could be useful in the mmio code as well.
Not sure how this changes in patch 8 though, I might put some more 
comments on that patch.


Daniele


}
  
  unlink:

@@ -741,8 +743,8 @@ static int ct_handle_response(struct intel_guc_ct *ct, 
struct ct_incoming_msg *r
status = response->msg[2];
datalen = len - 2;
  
-	/* Format of the status follows RESPONSE message */

-   if (unlikely(!INTEL_GUC_MSG_IS_RESPONSE(status))) {
+   /* Format of the status dword follows HXG header */
+   if (unlikely(FIELD_GET(GUC_HXG_MSG_0_ORIGIN, status) != 
GUC_HXG_ORIGIN_GUC)) {
CT_ERROR(ct, "Corrupted response (status %#x)\n", status);
return -EPROTO;
}
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
index e9a9d85e2aa3..fb04e2211b79 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
@@ -414,23 +414,6 @@ struct guc_shared_ctx_data {
struct guc_ctx_report preempt_ctx_report[GUC_MAX_ENGINES_NUM];
  } __packed;
  
-#define __INTEL_GUC_MSG_GET(T, m) \

-   (((m) & INTEL_GUC_MSG_ ## T ## _MASK) >> INTEL_GUC_MSG_ ## T ## _SHIFT)
-#define INTEL_GUC_MSG_TO_TYPE(m)   __INTEL_GUC_MSG_GET(TYPE, m)
-#define INTEL_GUC_MSG_TO_DATA(m)   __INTEL_GUC_MSG_GET(DATA, m)
-#define INTEL_GUC_MSG_TO_CODE(m)   __INTEL_GUC_MSG_GET(CODE, m)
-
-#define __INTEL_GUC_MSG_TYPE_IS(T, m) \
-   (INTEL_GUC_MSG_TO_TYPE(m) == INTEL_GUC_MSG_TYPE_ ## T)
-#define INTEL_GUC_MSG_IS_REQUEST(m)__INTEL_GUC_MSG_TYPE_IS(REQUEST, m)
-#define INTEL_GUC_MSG_IS_RESPONSE(m)   __INTEL_GUC_MSG_TYPE_IS(RESPONSE, m)
-
-#define INTEL_GUC_MSG_IS_RESPONSE_SUCCESS(m) \
-(typecheck(u32, (m)) && \
- ((m) & (INTEL_GUC_MSG_TYPE_MASK | INTEL_GUC_MSG_CODE_MASK)) == \
- ((INTEL_GUC_MSG_TYPE_RESPONSE << INTEL_GUC_MSG_TYPE_SHIFT) | \
-  (INTEL_GUC_RESPONSE_STATUS_SUCCESS << INTEL_GUC_MSG_CODE_SHIFT)))
-
  /* 

Re: [PATCH] treewide: Add missing semicolons to __assign_str uses

[Jason Gunthorpe]

On Fri, Jun 04, 2021 at 12:38:07PM -0700, Joe Perches wrote:
> The __assign_str macro has an unusual ending semicolon but the vast
> majority of uses of the macro already have semicolon termination.
> 
> $ git grep -P '\b__assign_str\b' | wc -l
> 551
> $ git grep -P '\b__assign_str\b.*;' | wc -l
> 480
> 
> Add semicolons to the __assign_str() uses without semicolon termination
> and all the other uses without semicolon termination via additional defines
> that are equivalent to __assign_str() with the eventual goal of removing
> the semicolon from the __assign_str() macro definition.

Acked-by: Jason Gunthorpe 

Jason

Re: [PATCH 02/13] drm/i915/guc: Update MMIO based communication

[Daniele Ceraolo Spurio]

On 6/7/2021 11:03 AM, Matthew Brost wrote:

From: Michal Wajdeczko 

The MMIO based Host-to-GuC communication protocol has been
updated to use unified HXG messages.

Update our intel_guc_send_mmio() function by correctly handle
BUSY, RETRY and FAILURE replies. Also update our documentation.

GuC: 55.0.0
Signed-off-by: Matthew Brost 
Signed-off-by: Michal Wajdeczko 
Cc: Piotr Piórkowski 
Cc: Michal Winiarski  #v3
---
  .../gt/uc/abi/guc_communication_mmio_abi.h| 63 ++---
  drivers/gpu/drm/i915/gt/uc/intel_guc.c| 92 ++-
  2 files changed, 97 insertions(+), 58 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_mmio_abi.h 
b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_mmio_abi.h
index be066a62e9e0..3f9039e3ef9d 100644
--- a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_mmio_abi.h
+++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_mmio_abi.h
@@ -7,46 +7,43 @@
  #define _ABI_GUC_COMMUNICATION_MMIO_ABI_H
  
  /**

- * DOC: MMIO based communication
+ * DOC: GuC MMIO based communication
   *
- * The MMIO based communication between Host and GuC uses software scratch
- * registers, where first register holds data treated as message header,
- * and other registers are used to hold message payload.
+ * The MMIO based communication between Host and GuC relies on special
+ * hardware registers which format could be defined by the software
+ * (so called scratch registers).
   *
- * For Gen9+, GuC uses software scratch registers 0xC180-0xC1B8,
- * but no H2G command takes more than 8 parameters and the GuC FW
- * itself uses an 8-element array to store the H2G message.
- *
- *  +---+-+-+-+
- *  |  MMIO[0]  | MMIO[1] |   ...   | MMIO[n] |
- *  +---+-+-+-+
- *  | header|  optional payload   |
- *  +==++=+=+=+
- *  | 31:28|type| | | |
- *  +--++ | | |
- *  | 27:16|data| | | |
- *  +--++ | | |
- *  |  15:0|code| | | |
- *  +--++-+-+-+
- *
- * The message header consists of:
- *
- * - **type**, indicates message type
- * - **code**, indicates message code, is specific for **type**
- * - **data**, indicates message data, optional, depends on **code**
+ * Each MMIO based message, both Host to GuC (H2G) and GuC to Host (G2H)
+ * messages, which maximum length depends on number of available scratch
+ * registers, is directly written into those scratch registers.
   *
- * The following message **types** are supported:
+ * For Gen9+, there are 16 software scratch registers 0xC180-0xC1B8,
+ * but no H2G command takes more than 8 parameters and the GuC firmware
+ * itself uses an 8-element array to store the H2G message.


Is this statement still true? I believe no MMIO H2G is over 4 DWs (given 
the limitation of the new gen11+ scratch regs), while CTB messages can 
be longer than 8 DWs.



   *
- * - **REQUEST**, indicates Host-to-GuC request, requested GuC action code
- *   must be priovided in **code** field. Optional action specific parameters
- *   can be provided in remaining payload registers or **data** field.
+ * For Gen11+, there are additional 4 registers 0x190240-0x19024C, which
+ * are, regardless on lower count, preffered over legacy ones.


typo: preffered -> preferred


   *
- * - **RESPONSE**, indicates GuC-to-Host response from earlier GuC request,
- *   action response status will be provided in **code** field. Optional
- *   response data can be returned in remaining payload registers or **data**
- *   field.
+ * The MMIO based communication is mainly used during driver initialization
+ * phase to setup the `CTB based communication`_ that will be used afterwards.
   */
  
  #define GUC_MAX_MMIO_MSG_LEN		8


See comment above. Reduce this to 4?

  
+/**

+ * DOC: MMIO HXG Message
+ *
+ * Format of the MMIO messages follows definitions of `HXG Message`_.
+ *
+ *  
+---+---+--+
+ *  |   | Bits  | Description  
|
+ *  
+===+===+==+
+ *  | 0 |  31:0 |  ++  
|
+ *  +---+---+  ||  
|
+ *  |...|   |  |  Embedded `HXG Message`_   |  
|
+ *  +---+---+  ||  
|
+ *  | n |  31:0 |  ++  
|
+ *  
+---+---+--+
+ */
+
  #endif /* _ABI_GUC_COMMUNICATION_MMIO_ABI_H */
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c 

[PATCH v3] drm/msm/dsi: add continuous clock support for 7nm PHY

[Dmitry Baryshkov]

Unlike previous generations, 7nm PHYs are required to collaborate with
the host for conitnuos clock mode. Add changes neccessary to enable
continuous clock mode in the 7nm DSI PHYs.

Signed-off-by: Dmitry Baryshkov 
---

Changes since v2:
 - Really drop msm_dsi_phy_needs_hs_phy_sel()

Changes since v1:
 - Remove the need for a separate msm_dsi_phy_needs_hs_phy_sel() call
 - Fix setting continuous clock for a dual DSI case.

---
 drivers/gpu/drm/msm/dsi/dsi.h |  3 ++-
 drivers/gpu/drm/msm/dsi/dsi.xml.h |  1 +
 drivers/gpu/drm/msm/dsi/dsi_host.c| 12 
 drivers/gpu/drm/msm/dsi/dsi_manager.c |  4 ++--
 drivers/gpu/drm/msm/dsi/phy/dsi_phy.c |  9 +
 drivers/gpu/drm/msm/dsi/phy/dsi_phy.h |  1 +
 drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c | 17 +
 7 files changed, 40 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi.h b/drivers/gpu/drm/msm/dsi/dsi.h
index 7abfeab08165..5be458c701d2 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.h
+++ b/drivers/gpu/drm/msm/dsi/dsi.h
@@ -108,7 +108,7 @@ int msm_dsi_host_enable(struct mipi_dsi_host *host);
 int msm_dsi_host_disable(struct mipi_dsi_host *host);
 int msm_dsi_host_power_on(struct mipi_dsi_host *host,
struct msm_dsi_phy_shared_timings *phy_shared_timings,
-   bool is_dual_dsi);
+   bool is_dual_dsi, struct msm_dsi_phy *phy);
 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);
@@ -173,6 +173,7 @@ int msm_dsi_phy_get_clk_provider(struct msm_dsi_phy *phy,
struct clk **byte_clk_provider, struct clk **pixel_clk_provider);
 void msm_dsi_phy_pll_save_state(struct msm_dsi_phy *phy);
 int msm_dsi_phy_pll_restore_state(struct msm_dsi_phy *phy);
+bool msm_dsi_phy_set_continuous_clock(struct msm_dsi_phy *phy, bool enable);
 
 #endif /* __DSI_CONNECTOR_H__ */
 
diff --git a/drivers/gpu/drm/msm/dsi/dsi.xml.h 
b/drivers/gpu/drm/msm/dsi/dsi.xml.h
index 50eb4d1b8fdd..9762af6035e9 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.xml.h
+++ b/drivers/gpu/drm/msm/dsi/dsi.xml.h
@@ -510,6 +510,7 @@ static inline uint32_t 
DSI_CLKOUT_TIMING_CTRL_T_CLK_POST(uint32_t val)
 #define DSI_LANE_STATUS_DLN0_DIRECTION 0x0001
 
 #define REG_DSI_LANE_CTRL  0x00a8
+#define DSI_LANE_CTRL_HS_REQ_SEL_PHY   0x0100
 #define DSI_LANE_CTRL_CLKLN_HS_FORCE_REQUEST   0x1000
 
 #define REG_DSI_LANE_SWAP_CTRL 0x00ac
diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 41e1d0f7ab6e..50be935edcad 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -835,7 +835,7 @@ static inline enum dsi_cmd_dst_format dsi_get_cmd_fmt(
 }
 
 static void dsi_ctrl_config(struct msm_dsi_host *msm_host, bool enable,
-   struct msm_dsi_phy_shared_timings *phy_shared_timings)
+   struct msm_dsi_phy_shared_timings *phy_shared_timings, 
struct msm_dsi_phy *phy)
 {
u32 flags = msm_host->mode_flags;
enum mipi_dsi_pixel_format mipi_fmt = msm_host->format;
@@ -930,6 +930,10 @@ static void dsi_ctrl_config(struct msm_dsi_host *msm_host, 
bool enable,
 
if (!(flags & MIPI_DSI_CLOCK_NON_CONTINUOUS)) {
lane_ctrl = dsi_read(msm_host, REG_DSI_LANE_CTRL);
+
+   if (msm_dsi_phy_set_continuous_clock(phy, enable))
+   lane_ctrl |= DSI_LANE_CTRL_HS_REQ_SEL_PHY;
+
dsi_write(msm_host, REG_DSI_LANE_CTRL,
lane_ctrl | DSI_LANE_CTRL_CLKLN_HS_FORCE_REQUEST);
}
@@ -2360,7 +2364,7 @@ static void msm_dsi_sfpb_config(struct msm_dsi_host 
*msm_host, bool enable)
 
 int msm_dsi_host_power_on(struct mipi_dsi_host *host,
struct msm_dsi_phy_shared_timings *phy_shared_timings,
-   bool is_dual_dsi)
+   bool is_dual_dsi, struct msm_dsi_phy *phy)
 {
struct msm_dsi_host *msm_host = to_msm_dsi_host(host);
const struct msm_dsi_cfg_handler *cfg_hnd = msm_host->cfg_hnd;
@@ -2400,7 +2404,7 @@ int msm_dsi_host_power_on(struct mipi_dsi_host *host,
 
dsi_timing_setup(msm_host, is_dual_dsi);
dsi_sw_reset(msm_host);
-   dsi_ctrl_config(msm_host, true, phy_shared_timings);
+   dsi_ctrl_config(msm_host, true, phy_shared_timings, phy);
 
if (msm_host->disp_en_gpio)
gpiod_set_value(msm_host->disp_en_gpio, 1);
@@ -2431,7 +2435,7 @@ int msm_dsi_host_power_off(struct mipi_dsi_host *host)
goto unlock_ret;
}
 
-   dsi_ctrl_config(msm_host, false, NULL);
+   dsi_ctrl_config(msm_host, false, NULL, NULL);
 
if (msm_host->disp_en_gpio)

Re: [PATCH 01/13] drm/i915/guc: Introduce unified HXG messages

[Daniele Ceraolo Spurio]

On 6/7/2021 11:03 AM, Matthew Brost wrote:

From: Michal Wajdeczko 

New GuC firmware will unify format of MMIO and CTB H2G messages.
Introduce their definitions now to allow gradual transition of
our code to match new changes.

Signed-off-by: Matthew Brost 
Signed-off-by: Michal Wajdeczko 
Cc: Michał Winiarski 
---
  .../gpu/drm/i915/gt/uc/abi/guc_messages_abi.h | 213 ++
  1 file changed, 213 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_messages_abi.h 
b/drivers/gpu/drm/i915/gt/uc/abi/guc_messages_abi.h
index 775e21f3058c..29ac823acd4c 100644
--- a/drivers/gpu/drm/i915/gt/uc/abi/guc_messages_abi.h
+++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_messages_abi.h
@@ -6,6 +6,219 @@
  #ifndef _ABI_GUC_MESSAGES_ABI_H
  #define _ABI_GUC_MESSAGES_ABI_H
  
+/**

+ * DOC: HXG Message
+ *
+ * All messages exchanged with GuC are defined using 32 bit dwords.
+ * First dword is treated as a message header. Remaining dwords are optional.
+ *
+ *  
+---+---+--+
+ *  |   | Bits  | Description  
|
+ *  
+===+===+==+
+ *  |   |   |  
|
+ *  | 0 |31 | **ORIGIN** - originator of the message   
|
+ *  |   |   |   - _`GUC_HXG_ORIGIN_HOST` = 0   
|
+ *  |   |   |   - _`GUC_HXG_ORIGIN_GUC` = 1
|
+ *  |   |   |  
|
+ *  |   
+---+--+
+ *  |   | 30:28 | **TYPE** - message type  
|
+ *  |   |   |   - _`GUC_HXG_TYPE_REQUEST` = 0  
|
+ *  |   |   |   - _`GUC_HXG_TYPE_EVENT` = 1
|
+ *  |   |   |   - _`GUC_HXG_TYPE_NO_RESPONSE_BUSY` = 3 
|
+ *  |   |   |   - _`GUC_HXG_TYPE_NO_RESPONSE_RETRY` = 5
|
+ *  |   |   |   - _`GUC_HXG_TYPE_RESPONSE_FAILURE` = 6 
|
+ *  |   |   |   - _`GUC_HXG_TYPE_RESPONSE_SUCCESS` = 7 
|
+ *  |   
+---+--+
+ *  |   |  27:0 | **AUX** - auxiliary data (depends on TYPE)   
|
+ *  
+---+---+--+
+ *  | 1 |  31:0 |  
|
+ *  +---+---+  
|
+ *  |...|   | **PAYLOAD** - optional payload (depends on TYPE) 
|
+ *  +---+---+  
|
+ *  | n |  31:0 |  
|
+ *  
+---+---+--+
+ */
+
+#define GUC_HXG_MSG_MIN_LEN1u
+#define GUC_HXG_MSG_0_ORIGIN   (0x1 << 31)


Any reason not to use BIT(31) here? same below with other bits and with 
GENMASK for masks.



+#define   GUC_HXG_ORIGIN_HOST  0u
+#define   GUC_HXG_ORIGIN_GUC   1u
+#define GUC_HXG_MSG_0_TYPE (0x7 << 28)


I think the masks could use a _MASK postfix


+#define   GUC_HXG_TYPE_REQUEST 0u
+#define   GUC_HXG_TYPE_EVENT   1u
+#define   GUC_HXG_TYPE_NO_RESPONSE_BUSY3u
+#define   GUC_HXG_TYPE_NO_RESPONSE_RETRY   5u
+#define   GUC_HXG_TYPE_RESPONSE_FAILURE6u
+#define   GUC_HXG_TYPE_RESPONSE_SUCCESS7u
+#define GUC_HXG_MSG_0_AUX  (0xfff << 0)
+#define GUC_HXG_MSG_n_PAYLOAD  (0x << 0)


Is a mask that covers the whole u32 really needed? Even for future 
proofing, I find it very unlikely that we'll ever have a case where the 
payload is not an entire dword.



+
+/**
+ * DOC: HXG Request
+ *
+ * The `HXG Request`_ message should be used to initiate synchronous activity
+ * for which confirmation or return data is expected.
+ *
+ * The recipient of this message shall use `HXG Response`_, `HXG Failure`_
+ * or `HXG Retry`_ message as a definite reply, and may use `HXG Busy`_
+ * message as a intermediate reply.
+ *
+ * Format of @DATA0 and all @DATAn fields depends on the @ACTION code.
+ *
+ *  
+---+---+--+
+ *  |   | Bits  | Description  
|
+ *  
+===+===+==+
+ *  | 0 |31 | ORIGIN   
|
+ *  |   
+---+--+
+ *  |   | 30:28 | TYPE = 

Re: [PATCH v2] drm/msm/dsi: add continuous clock support for 7nm PHY

[kernel test robot]

Hi Dmitry,

Thank you for the patch! Perhaps something to improve:

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

url:
https://github.com/0day-ci/linux/commits/Dmitry-Baryshkov/drm-msm-dsi-add-continuous-clock-support-for-7nm-PHY/20210608-040715
base:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
614124bea77e452aa6df7a8714e8bc820b489922
config: arm-defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# 
https://github.com/0day-ci/linux/commit/a0cec71ca8eb8dc521ab7a99c28865ce4e428e01
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Dmitry-Baryshkov/drm-msm-dsi-add-continuous-clock-support-for-7nm-PHY/20210608-040715
git checkout a0cec71ca8eb8dc521ab7a99c28865ce4e428e01
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arm 

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

All warnings (new ones prefixed by >>):

>> drivers/gpu/drm/msm/dsi/phy/dsi_phy.c:838:6: warning: no previous prototype 
>> for 'msm_dsi_phy_needs_hs_phy_sel' [-Wmissing-prototypes]
 838 | bool msm_dsi_phy_needs_hs_phy_sel(struct msm_dsi_phy *phy)
 |  ^~~~


vim +/msm_dsi_phy_needs_hs_phy_sel +838 drivers/gpu/drm/msm/dsi/phy/dsi_phy.c

   837  
 > 838  bool msm_dsi_phy_needs_hs_phy_sel(struct msm_dsi_phy *phy)
   839  {
   840  if (!phy)
   841  return false;
   842  return phy->cfg->ops.set_continuous_clock != NULL;
   843  }
   844  

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


.config.gz
Description: application/gzip

Re: [PATCH 00/13] Update firmware to v62.0.0

[Daniele Ceraolo Spurio]

On 6/7/2021 11:03 AM, Matthew Brost wrote:

As part of enabling GuC submission [1] we need to update to the latest
and greatest firmware. This series does that. This is a destructive
change. e.g. Without all the patches in this series it will break the
i915 driver. As such, after we review all of these patches they will
squashed into a single patch for merging.


Can you resubmit with an added HAX patch for enable_guc=2 after the 
first round of review? none of the machines in CI seems to have 
attempted to load the guc, not even cfl-guc and kbl-guc. If all the 
reviews are good maybe just resubmit the squashed patch and the 
enablement with a CI tag, so we can merge once we get the results.


Daniele



Signed-off-by: Matthew Brost 

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

John Harrison (3):
   drm/i915/guc: Support per context scheduling policies
   drm/i915/guc: Unified GuC log
   drm/i915/guc: Update firmware to v62.0.0

Michal Wajdeczko (10):
   drm/i915/guc: Introduce unified HXG messages
   drm/i915/guc: Update MMIO based communication
   drm/i915/guc: Update CTB response status definition
   drm/i915/guc: Add flag for mark broken CTB
   drm/i915/guc: New definition of the CTB descriptor
   drm/i915/guc: New definition of the CTB registration action
   drm/i915/guc: New CTB based communication
   drm/i915/doc: Include GuC ABI documentation
   drm/i915/guc: Kill guc_clients.ct_pool
   drm/i915/guc: Kill ads.client_info

  Documentation/gpu/i915.rst|   8 +
  .../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h  | 107 ++
  .../gt/uc/abi/guc_communication_ctb_abi.h | 130 +--
  .../gt/uc/abi/guc_communication_mmio_abi.h|  63 ++--
  .../gpu/drm/i915/gt/uc/abi/guc_messages_abi.h | 213 +++
  drivers/gpu/drm/i915/gt/uc/intel_guc.c| 107 --
  drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c|  45 +--
  drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 355 +-
  drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h |   6 +-
  drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h   |  75 +---
  drivers/gpu/drm/i915/gt/uc/intel_guc_log.c|  29 +-
  drivers/gpu/drm/i915/gt/uc/intel_guc_log.h|   6 +-
  drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c  |  26 +-
  13 files changed, 750 insertions(+), 420 deletions(-)

[PATCH] drm/msm/dsi: do not enable PHYs when called for the slave DSI interface

[Dmitry Baryshkov]

Move the call to dsi_mgr_phy_enable after checking whether the DSI
interface is slave, so that PHY enablement happens together with the
host enablement.

Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/msm/dsi/dsi_manager.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_manager.c 
b/drivers/gpu/drm/msm/dsi/dsi_manager.c
index cc18ea2b244c..d77693904a15 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_manager.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_manager.c
@@ -374,14 +374,14 @@ static void dsi_mgr_bridge_pre_enable(struct drm_bridge 
*bridge)
if (!msm_dsi_device_connected(msm_dsi))
return;
 
-   ret = dsi_mgr_phy_enable(id, phy_shared_timings);
-   if (ret)
-   goto phy_en_fail;
-
/* Do nothing with the host if it is slave-DSI in case of dual DSI */
if (is_dual_dsi && !IS_MASTER_DSI_LINK(id))
return;
 
+   ret = dsi_mgr_phy_enable(id, phy_shared_timings);
+   if (ret)
+   goto phy_en_fail;
+
ret = msm_dsi_host_power_on(host, _shared_timings[id], is_dual_dsi, 
msm_dsi->phy);
if (ret) {
pr_err("%s: power on host %d failed, %d\n", __func__, id, ret);
-- 
2.30.2

Re: [PATCH v2] drm/sun4i: dw-hdmi: Make HDMI PHY into a platform device

[Saravana Kannan]

On Mon, Jun 7, 2021 at 4:41 AM Maxime Ripard  wrote:
>
> On Mon, Jun 07, 2021 at 10:58:36AM +0200, Ondrej Jirman wrote:
> > From: Saravana Kannan 
> >
> > On sunxi boards that use HDMI output, HDMI device probe keeps being
> > avoided indefinitely with these repeated messages in dmesg:
> >
> >   platform 1ee.hdmi: probe deferral - supplier 1ef.hdmi-phy
> > not ready
> >
> > There's a fwnode_link being created with fw_devlink=on between hdmi
> > and hdmi-phy nodes, because both nodes have 'compatible' property set.
> >
> > Fw_devlink code assumes that nodes that have compatible property
> > set will also have a device associated with them by some driver
> > eventually. This is not the case with the current sun8i-hdmi
> > driver.
> >
> > This commit makes sun8i-hdmi-phy into a proper platform device
> > and fixes the display pipeline probe on sunxi boards that use HDMI.
> >
> > More context: https://lkml.org/lkml/2021/5/16/203
> >
> > Signed-off-by: Saravana Kannan 
> > Signed-off-by: Ondrej Jirman 
>
> Applied, thanks
> Maxime

Thanks everyone! And thanks for following up on this Ondrej!

-Saravana

Re: [PATCH 0/9] Enhance pipe color support for multi segmented luts

[Harry Wentland]

On 2021-06-07 2:01 p.m., Shankar, Uma wrote:
> 
> 
>> -Original Message-
>> From: Harry Wentland 
>> Sent: Saturday, June 5, 2021 12:21 AM
>> To: Shankar, Uma ; intel-...@lists.freedesktop.org; 
>> dri-
>> de...@lists.freedesktop.org
>> Cc: Modem, Bhanuprakash ; Cyr, Aric
>> 
>> Subject: Re: [PATCH 0/9] Enhance pipe color support for multi segmented luts
>>
>> On 2021-06-01 6:41 a.m., Uma Shankar wrote:
>>> Modern hardwares have multi segmented lut approach to prioritize the
>>> darker regions of the spectrum. This series introduces a new UAPI to
>>> define the lut ranges supported by the respective hardware.
>>>
>>> This also enables Pipe Color Management Support for Intel's XE_LPD hw.
>>> Enable Support for Pipe Degamma with the increased lut samples
>>> supported by hardware. This also adds support for newly introduced
>>> Logarithmic Gamma for XE_LPD. Also added the gamma readout support.
>>>
>>> The Logarithmic gamma implementation on XE_LPD is non linear and adds
>>> 25 segments with non linear lut samples in each segment. The
>>> expectation is userspace will create the luts as per this distribution
>>> and pass the final samples to driver to be programmed in hardware.
>>>
>>
>> Is this design targetting Intel XE_LPD HW in particular or is it intended to 
>> be generic?
>>
>> If this is intended to be generic I think it would benefit from a lot more
>> documentation. At this point it's difficult for me to see how to adapt this 
>> to AMD
>> HW. It would take me a while to be comfortable to make a call on whether we 
>> can
>> use it or not. And what about other vendors?
> 
> This is expected to be generic for all vendors.  XE_LPD is just a reference 
> implementation.
> It's basically an extension of what we have for crtc color but designing the 
> UAPI to have it
> more scalable for future hardware. The legacy hardware implementation which 
> we have in
> crtc properties can easily fit in this new UAPI and this can help represent 
> hardware better
> with more precision and scalability. Credits to Ville as to this is his idea 
> of how we can represent
> hardware generically and advertise to userspace.
> 
> Sure, I will add more documentation to make this clearer. 
> 
>> I think we need to be cautious in directly exposing HW functionality through 
>> UAPI.
>> The CM parts of AMD HW seem to be changing in some way each generation and it
>> looks like the same is true for Intel. The trouble we have with adapting the 
>> old
>> gamma/degamma properties to modern HW is some indication to me that this
>> approach is somewhat problematic.
>>
> 
> The advantage of having flexibility in userspace is that we give access of 
> hardware to
> userspace.It can then control things based on various usecases and not 
> limited by just
> a subset of operations what we define (in the lack of such an implementation).
> 
>> It would be useful to understand and document the specific use-cases we want 
>> to
>> provide to userspace implementers with this functionality. Do we want to 
>> support
>> modern transfer functions such as PQ or HLG? If so, it might be beneficial 
>> to have an
>> API to explicitly specify that, and then use LUT tables in drivers that are 
>> optimized for
>> the implementing HW. Or is the use case tone mapping? If so, would a 
>> parametric
>> definition of tone mapping be easier to manage?
>>
> 
> Yes right, ideally this is what intend to achieve here. We cant have fixed 
> tables for operations
> like Tone mapping as it will depend on mastering luminance values which can 
> vary along with
> other attributes of metadata. Eventually this operation would be done by the 
> gamma block
> (non linear luts), the values for which would be calculated and send by 
> userspace. Thus making
> all this very generic. Also we can't do any color math in driver as it has 
> lot of floating operations.
> 
> So here the trade-off is between having a UAPI where userspace controls hw, 
> computes and sends
> values vs having just a fixed function operations with hard coded lut tables 
> in driver.
> 
> Maybe we can have both the options in order to give flexibility to hardware 
> vendors. We can
> document the usage of the UAPI we create which can help things co-exist. 
> Userspace can query
> the supported properties and implement based on the properties exposed by the 
> respective
> vendor driver implementation. 
> 
> My personal preference would be to go with generic option (expose hardware to 
> userspace) which
> will make life easier for userspace developers. This will help use hardware 
> for any color operation not
> just limited to linearization, CSC conversions and tone mapping. Also this is 
> already done for crtc, so it just
> need to be extended to planes.
> 

Thanks for providing more background.

How would a driver handle this segmented LUT when the implementing HW
doesn't have 512 points, but uses more, or less, or differently
distributed points?

What about HW that doesn't support RAM 

Re: nouveau broken on Riva TNT2 in 5.13.0-rc4: NULL pointer dereference in nouveau_bo_sync_for_device

[Ondrej Zary]

On Sunday 06 June 2021 23:16:03 Ondrej Zary wrote:
> On Saturday 05 June 2021 23:34:23 Ondrej Zary wrote:
> > On Saturday 05 June 2021 21:43:52 Ondrej Zary wrote:
> > > Hello,
> > > I'm testing 5.13.0-rc4 and nouveau crashes with NULL pointer dereference 
> > > in nouveau_bo_sync_for_device.
> > > Found various reports like this but that was back in februaryso that 
> > > should be fixed now.
> > 
> > So it is the same bug. Broken since 5.11. This revert fixes it in 5.11:
> > https://lists.freedesktop.org/archives/dri-devel/2021-February/298531.html
> > 
> > Added some debug printks to nouveau_bo_sync_for_device:
> > [   22.225048] ttm_dma=fc33b500
> > [   22.225066] ttm_dma->num_pages=18
> > [   22.225071] i=0 num_pages=16
> > [   22.225077] ttm_dma->dma_address=
> > [   22.225094] BUG: kernel NULL pointer dereference, address: 
> > 
> > So ttm->dma_address is NULL.
> > 
> 
> Tested reverting f295c8cfec833c2707ff1512da10d65386dde7af again and it does 
> not work...
> Not sure what I did before.
> 
> Bisecting between 5.10 and 5.11 is impossible - I keep hitting neverending 
> stream of bugs.
> As always with nouveau...

e34b8feeaa4b65725b25f49c9b08a0f8707e8e86 seems to be the first bad commit
Going back one commit makes it crash in a different way:

[   55.444208] BUG: kernel NULL pointer dereference, address: 01b0
[   55.444219] #PF: supervisor read access in kernel mode
[   55.444222] #PF: error_code(0x) - not-present page
[   55.444225] *pde = 
[   55.444231] Oops:  [#1] SMP
[   55.444237] CPU: 0 PID: 1740 Comm: Xorg Not tainted 5.9.0-rc5+ #361
[   55.444240] Hardware name:  /848P-ICH5, BIOS 6.00 PG 02/03/2005
[   55.444321] EIP: nouveau_bo_wr16+0x8/0x27 [nouveau]
[   55.444326] Code: 85 ff 74 0d 80 7d f3 00 74 07 80 a6 f4 01 00 00 fe 89 f0 
e8 0c ef ff ff 8d 65 f4 89 f8 5b 5e 5f 5d c3 55 01 d2 89 e5 53 89 c3 <03> 93 b0 
01 00 00 0f b7 c1 f6 83 b8 01 00 00 80 74 07 e8 40 49 69
[   55.444330] EAX:  EBX:  ECX:  EDX: 
[   55.444334] ESI: 0020 EDI: e7a14400 EBP: e786fd98 ESP: e786fd94
[   55.444338] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 EFLAGS: 00210246
[   55.444341] CR0: 80050033 CR2: 01b0 CR3: 27896000 CR4: 0690
[   55.444344] Call Trace:
[   55.444395]  nv04_crtc_cursor_set+0x148/0x1d8 [nouveau]
[   55.42]  ? ttm_bo_reserve.constprop.15+0x1c/0x1c [nouveau]
[   55.51]  drm_mode_cursor_common+0x13b/0x1ad
[   55.97]  ? ttm_bo_reserve.constprop.15+0x1c/0x1c [nouveau]
[   55.444504]  drm_mode_cursor_ioctl+0x2e/0x36
[   55.444509]  ? drm_mode_setplane+0x203/0x203
[   55.444514]  drm_ioctl_kernel+0x66/0x99
[   55.444518]  drm_ioctl+0x211/0x2d8
[   55.444522]  ? drm_mode_setplane+0x203/0x203
[   55.444529]  ? _cond_resched+0x1e/0x22
[   55.444533]  ? mutex_lock+0xb/0x24
[   55.444582]  ? nouveau_bo_add_io_reserve_lru+0x53/0x58 [nouveau]
[   55.444589]  ? rpm_resume.part.13+0x72/0x365
[   55.444594]  ? ktime_get_mono_fast_ns+0x5e/0xf2
[   55.444598]  ? __pm_runtime_resume+0x5b/0x63
[   55.444647]  nouveau_drm_ioctl+0x65/0x81 [nouveau]
[   55.444696]  ? nouveau_cli_work+0xc3/0xc3 [nouveau]
[   55.444702]  vfs_ioctl+0x1a/0x24
[   55.444706]  __ia32_sys_ioctl+0x583/0x59d
[   55.444711]  ? doublefault_shim+0x120/0x120
[   55.444717]  ? exit_to_user_mode_prepare+0x71/0xba
[   55.444721]  do_int80_syscall_32+0x2c/0x39
[   55.444725]  entry_INT80_32+0xf0/0xf0
[   55.444729] EIP: 0xb7fb2092
[   55.444733] Code: 00 00 00 e9 90 ff ff ff ff a3 24 00 00 00 68 30 00 00 00 
e9 80 ff ff ff ff a3 e8 ff ff ff 66 90 00 00 00 00 00 00 00 00 cd 80  8d b4 
26 00 00 00 00 8d b6 00 00 00 00 8b 1c 24 c3 8d b4 26 00
[   55.444737] EAX: ffda EBX: 000e ECX: c01c64a3 EDX: bfe89750
[   55.444741] ESI: 02580b40 EDI: c01c64a3 EBP: 000e ESP: bfe89704
[   55.444744] DS: 007b ES: 007b FS:  GS: 0033 SS: 007b EFLAGS: 00200292
[   55.444748] Modules linked in: i2c_dev nouveau serial_cs snd_intel8x0 
snd_ac97_codec wmi hwmon ttm ac97_bus 8139cp snd_pcm pcmcia snd_timer snd sg 
soundcore psmouse yenta_socket serio_raw pcmcia_rsrc pcmcia_core intel_agp 
parport_pc parport
[   55.444769] CR2: 01b0
[   55.444774] ---[ end trace e2b0d4c3c2e4e488 ]---
[   55.444827] EIP: nouveau_bo_wr16+0x8/0x27 [nouveau]
[   55.444831] Code: 85 ff 74 0d 80 7d f3 00 74 07 80 a6 f4 01 00 00 fe 89 f0 
e8 0c ef ff ff 8d 65 f4 89 f8 5b 5e 5f 5d c3 55 01 d2 89 e5 53 89 c3 <03> 93 b0 
01 00 00 0f b7 c1 f6 83 b8 01 00 00 80 74 07 e8 40 49 69
[   55.444835] EAX:  EBX:  ECX:  EDX: 
[   55.444838] ESI: 0020 EDI: e7a14400 EBP: e786fd98 ESP: e786fd94
[   55.444842] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 EFLAGS: 00210246
[   55.444845] CR0: 80050033 CR2: 01b0 CR3: 27896000 CR4: 0690


-- 
Ondrej Zary

Re: [PATCH][next] drm/i915/gem: Fix fall-through warning for Clang

[Joe Perches]

On Mon, 2021-06-07 at 15:32 -0500, Gustavo A. R. Silva wrote:
> In preparation to enable -Wimplicit-fallthrough for Clang, fix a
> warning by explicitly adding a fallthrough; statement.
[]
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
[]
> @@ -62,6 +62,7 @@ static void try_to_writeback(struct drm_i915_gem_object 
> *obj,
>   switch (obj->mm.madv) {
>   case I915_MADV_DONTNEED:
>   i915_gem_object_truncate(obj);
> + fallthrough;
>   case __I915_MADV_PURGED:
>   return;
>   }

I think fallthrough to return is not particularly nice to follow.

This is the current function:

static void try_to_writeback(struct drm_i915_gem_object *obj,
 unsigned int flags)
{
switch (obj->mm.madv) {
case I915_MADV_DONTNEED:
i915_gem_object_truncate(obj);
case __I915_MADV_PURGED:
return;
}

if (flags & I915_SHRINK_WRITEBACK)
i915_gem_object_writeback(obj);
}

One of these might be more typical:

static void try_to_writeback(struct drm_i915_gem_object *obj,
 unsigned int flags)
{
switch (obj->mm.madv) {
case I915_MADV_DONTNEED:
i915_gem_object_truncate(obj);
break;
case __I915_MADV_PURGED:
break;
default:
if (flags & I915_SHRINK_WRITEBACK)
i915_gem_object_writeback(obj);
break;
}
}

or maybe:

static void try_to_writeback(struct drm_i915_gem_object *obj,
 unsigned int flags)
{
switch (obj->mm.madv) {
case I915_MADV_DONTNEED:
i915_gem_object_truncate(obj);
return;
case __I915_MADV_PURGED:
return;
}

if (flags & I915_SHRINK_WRITEBACK)
i915_gem_object_writeback(obj);
}

[RFC PATCH v2 8/8] mm: call pgmap->ops->page_free for DEVICE_GENERIC pages

[Alex Sierra]

Add MEMORY_DEVICE_GENERIC case to free_zone_device_page
callback.
Device generic type memory case is now able to free its
pages properly.

Signed-off-by: Alex Sierra 
---
 mm/memremap.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/mm/memremap.c b/mm/memremap.c
index 614b3d600e95..6c884e2542a9 100644
--- a/mm/memremap.c
+++ b/mm/memremap.c
@@ -438,7 +438,7 @@ struct dev_pagemap *get_dev_pagemap(unsigned long pfn,
 EXPORT_SYMBOL_GPL(get_dev_pagemap);
 
 #ifdef CONFIG_DEV_PAGEMAP_OPS
-static void free_device_private_page(struct page *page)
+static void free_device_page(struct page *page)
 {
 
__ClearPageWaiters(page);
@@ -477,7 +477,8 @@ void free_zone_device_page(struct page *page)
wake_up_var(>_refcount);
return;
case MEMORY_DEVICE_PRIVATE:
-   free_device_private_page(page);
+   case MEMORY_DEVICE_GENERIC:
+   free_device_page(page);
return;
default:
return;
-- 
2.17.1

[RFC PATCH v2 7/8] mm: add generic type support to migrate_vma helpers

[Alex Sierra]

Device generic type case added for migrate_vma_pages and
migrate_vma_check_page helpers.
Both, generic and private device types have the same
conditions to decide to migrate pages from/to device
memory.

Signed-off-by: Alex Sierra 
---
 mm/migrate.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/mm/migrate.c b/mm/migrate.c
index 8c2430d3e77b..3b6aaba96fe6 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -2602,7 +2602,7 @@ static bool migrate_vma_check_page(struct page *page)
 * FIXME proper solution is to rework migration_entry_wait() so
 * it does not need to take a reference on page.
 */
-   return is_device_private_page(page);
+   return is_device_page(page);
}
 
/* For file back page */
@@ -3064,10 +3064,10 @@ void migrate_vma_pages(struct migrate_vma *migrate)
mapping = page_mapping(page);
 
if (is_zone_device_page(newpage)) {
-   if (is_device_private_page(newpage)) {
+   if (is_device_page(newpage)) {
/*
-* For now only support private anonymous when
-* migrating to un-addressable device memory.
+* For now only support private and generic
+* anonymous when migrating to device memory.
 */
if (mapping) {
migrate->src[i] &= ~MIGRATE_PFN_MIGRATE;
-- 
2.17.1

[RFC PATCH v2 6/8] include/linux/mm.h: helpers to check zone device generic type

[Alex Sierra]

Two helpers added. One checks if zone device page is generic
type. The other if page is either private or generic type.

Signed-off-by: Alex Sierra 
---
 include/linux/mm.h | 8 
 1 file changed, 8 insertions(+)

diff --git a/include/linux/mm.h b/include/linux/mm.h
index d8d79bb94be8..f5b247a63044 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1125,6 +1125,14 @@ static inline bool is_device_private_page(const struct 
page *page)
page->pgmap->type == MEMORY_DEVICE_PRIVATE;
 }
 
+static inline bool is_device_page(const struct page *page)
+{
+   return IS_ENABLED(CONFIG_DEV_PAGEMAP_OPS) &&
+   is_zone_device_page(page) &&
+   (page->pgmap->type == MEMORY_DEVICE_PRIVATE ||
+page->pgmap->type == MEMORY_DEVICE_GENERIC);
+}
+
 static inline bool is_pci_p2pdma_page(const struct page *page)
 {
return IS_ENABLED(CONFIG_DEV_PAGEMAP_OPS) &&
-- 
2.17.1

[RFC PATCH v2 5/8] drm/amdkfd: generic type as sys mem on migration to ram

[Alex Sierra]

Generic device type memory on VRAM to RAM migration,
has similar access as System RAM from the CPU. This flag sets
the source from the sender. Which in Generic type case,
should be set as SYSTEM.

Signed-off-by: Alex Sierra 
Reviewed-by: Felix Kuehling 
---
 drivers/gpu/drm/amd/amdkfd/kfd_migrate.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
index f5939449a99f..7b41006c1164 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
@@ -653,8 +653,9 @@ svm_migrate_vma_to_ram(struct amdgpu_device *adev, struct 
svm_range *prange,
migrate.vma = vma;
migrate.start = start;
migrate.end = end;
-   migrate.flags = MIGRATE_VMA_SELECT_DEVICE_PRIVATE;
migrate.pgmap_owner = SVM_ADEV_PGMAP_OWNER(adev);
+   migrate.flags = adev->gmc.xgmi.connected_to_cpu ?
+   MIGRATE_VMA_SELECT_SYSTEM : 
MIGRATE_VMA_SELECT_DEVICE_PRIVATE;
 
size = 2 * sizeof(*migrate.src) + sizeof(uint64_t) + sizeof(dma_addr_t);
size *= npages;
-- 
2.17.1

[RFC PATCH v2 4/8] drm/amdkfd: add SPM support for SVM

[Alex Sierra]

When CPU is connected throug XGMI, it has coherent
access to VRAM resource. In this case that resource
is taken from a table in the device gmc aperture base.
This resource is used along with the device type, which could
be DEVICE_PRIVATE or DEVICE_GENERIC to create the device
page map region.

Signed-off-by: Alex Sierra 
Reviewed-by: Felix Kuehling 
---
 drivers/gpu/drm/amd/amdkfd/kfd_migrate.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
index c8ca3252cbc2..f5939449a99f 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
@@ -895,6 +895,7 @@ int svm_migrate_init(struct amdgpu_device *adev)
struct resource *res;
unsigned long size;
void *r;
+   bool xgmi_connected_to_cpu = adev->gmc.xgmi.connected_to_cpu;
 
/* Page migration works on Vega10 or newer */
if (kfddev->device_info->asic_family < CHIP_VEGA10)
@@ -907,17 +908,22 @@ int svm_migrate_init(struct amdgpu_device *adev)
 * should remove reserved size
 */
size = ALIGN(adev->gmc.real_vram_size, 2ULL << 20);
-   res = devm_request_free_mem_region(adev->dev, _resource, size);
+   if (xgmi_connected_to_cpu)
+   res = lookup_resource(_resource, adev->gmc.aper_base);
+   else
+   res = devm_request_free_mem_region(adev->dev, _resource, 
size);
+
if (IS_ERR(res))
return -ENOMEM;
 
-   pgmap->type = MEMORY_DEVICE_PRIVATE;
pgmap->nr_range = 1;
pgmap->range.start = res->start;
pgmap->range.end = res->end;
+   pgmap->type = xgmi_connected_to_cpu ?
+   MEMORY_DEVICE_GENERIC : MEMORY_DEVICE_PRIVATE;
pgmap->ops = _migrate_pgmap_ops;
pgmap->owner = SVM_ADEV_PGMAP_OWNER(adev);
-   pgmap->flags = MIGRATE_VMA_SELECT_DEVICE_PRIVATE;
+   pgmap->flags = 0;
r = devm_memremap_pages(adev->dev, pgmap);
if (IS_ERR(r)) {
pr_err("failed to register HMM device memory\n");
-- 
2.17.1

[RFC PATCH v2 3/8] kernel: resource: lookup_resource as exported symbol

[Alex Sierra]

The AMD architecture for the Frontier supercomputer will
have device memory which can be coherently accessed by
the CPU. The system BIOS advertises this memory as SPM
(special purpose memory) in the UEFI system address map.

The AMDGPU driver needs to be able to lookup this resource
in order to claim it as MEMORY_DEVICE_GENERIC using
devm_memremap_pages.

Signed-off-by: Alex Sierra 
---
 kernel/resource.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/resource.c b/kernel/resource.c
index 627e61b0c124..269489bb7097 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -783,7 +783,7 @@ struct resource *lookup_resource(struct resource *root, 
resource_size_t start)
 
return res;
 }
-
+EXPORT_SYMBOL_GPL(lookup_resource);
 /*
  * Insert a resource into the resource tree. If successful, return NULL,
  * otherwise return the conflicting resource (compare to __request_resource())
-- 
2.17.1

[RFC PATCH v2 2/8] mm: remove extra ZONE_DEVICE struct page refcount

[Alex Sierra]

From: Ralph Campbell 

ZONE_DEVICE struct pages have an extra reference count that complicates the
code for put_page() and several places in the kernel that need to check the
reference count to see that a page is not being used (gup, compaction,
migration, etc.). Clean up the code so the reference count doesn't need to
be treated specially for ZONE_DEVICE.

v2:
AS: merged this patch in linux 5.11 version

Signed-off-by: Ralph Campbell 
Signed-off-by: Alex Sierra 
---
 arch/powerpc/kvm/book3s_hv_uvmem.c |  2 +-
 drivers/gpu/drm/nouveau/nouveau_dmem.c |  2 +-
 fs/dax.c   |  4 +-
 include/linux/dax.h|  2 +-
 include/linux/memremap.h   |  7 +--
 include/linux/mm.h | 44 -
 lib/test_hmm.c |  2 +-
 mm/internal.h  |  8 +++
 mm/memremap.c  | 68 +++---
 mm/migrate.c   |  5 --
 mm/page_alloc.c|  3 ++
 mm/swap.c  | 45 ++---
 12 files changed, 45 insertions(+), 147 deletions(-)

diff --git a/arch/powerpc/kvm/book3s_hv_uvmem.c 
b/arch/powerpc/kvm/book3s_hv_uvmem.c
index 84e5a2dc8be5..acee67710620 100644
--- a/arch/powerpc/kvm/book3s_hv_uvmem.c
+++ b/arch/powerpc/kvm/book3s_hv_uvmem.c
@@ -711,7 +711,7 @@ static struct page *kvmppc_uvmem_get_page(unsigned long 
gpa, struct kvm *kvm)
 
dpage = pfn_to_page(uvmem_pfn);
dpage->zone_device_data = pvt;
-   get_page(dpage);
+   init_page_count(dpage);
lock_page(dpage);
return dpage;
 out_clear:
diff --git a/drivers/gpu/drm/nouveau/nouveau_dmem.c 
b/drivers/gpu/drm/nouveau/nouveau_dmem.c
index 92987daa5e17..8bc7120e1216 100644
--- a/drivers/gpu/drm/nouveau/nouveau_dmem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_dmem.c
@@ -324,7 +324,7 @@ nouveau_dmem_page_alloc_locked(struct nouveau_drm *drm)
return NULL;
}
 
-   get_page(page);
+   init_page_count(page);
lock_page(page);
return page;
 }
diff --git a/fs/dax.c b/fs/dax.c
index 321f4ddc6643..7b4c6b35b098 100644
--- a/fs/dax.c
+++ b/fs/dax.c
@@ -560,14 +560,14 @@ static void *grab_mapping_entry(struct xa_state *xas,
 
 /**
  * dax_layout_busy_page_range - find first pinned page in @mapping
- * @mapping: address space to scan for a page with ref count > 1
+ * @mapping: address space to scan for a page with ref count > 0
  * @start: Starting offset. Page containing 'start' is included.
  * @end: End offset. Page containing 'end' is included. If 'end' is LLONG_MAX,
  *   pages from 'start' till the end of file are included.
  *
  * DAX requires ZONE_DEVICE mapped pages. These pages are never
  * 'onlined' to the page allocator so they are considered idle when
- * page->count == 1. A filesystem uses this interface to determine if
+ * page->count == 0. A filesystem uses this interface to determine if
  * any page in the mapping is busy, i.e. for DMA, or other
  * get_user_pages() usages.
  *
diff --git a/include/linux/dax.h b/include/linux/dax.h
index 8909a91cd381..9487dc06b220 100644
--- a/include/linux/dax.h
+++ b/include/linux/dax.h
@@ -245,7 +245,7 @@ static inline bool dax_mapping(struct address_space 
*mapping)
 
 static inline bool dax_layout_is_idle_page(struct page *page)
 {
-   return page_ref_count(page) == 1;
+   return page_ref_count(page) == 0;
 }
 
 #define dax_wait_page(_inode, _page, _wait_cb) \
diff --git a/include/linux/memremap.h b/include/linux/memremap.h
index 79c49e7f5c30..327f32427d21 100644
--- a/include/linux/memremap.h
+++ b/include/linux/memremap.h
@@ -66,9 +66,10 @@ enum memory_type {
 
 struct dev_pagemap_ops {
/*
-* Called once the page refcount reaches 1.  (ZONE_DEVICE pages never
-* reach 0 refcount unless there is a refcount bug. This allows the
-* device driver to implement its own memory management.)
+* Called once the page refcount reaches 0. The reference count
+* should be reset to one with init_page_count(page) before reusing
+* the page. This allows the device driver to implement its own
+* memory management.
 */
void (*page_free)(struct page *page);
 
diff --git a/include/linux/mm.h b/include/linux/mm.h
index c9900aedc195..d8d79bb94be8 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1117,39 +1117,6 @@ static inline bool is_zone_device_page(const struct page 
*page)
 }
 #endif
 
-#ifdef CONFIG_DEV_PAGEMAP_OPS
-void free_devmap_managed_page(struct page *page);
-DECLARE_STATIC_KEY_FALSE(devmap_managed_key);
-
-static inline bool page_is_devmap_managed(struct page *page)
-{
-   if (!static_branch_unlikely(_managed_key))
-   return false;
-   if (!is_zone_device_page(page))
-   return false;
-   switch (page->pgmap->type) {
-   case MEMORY_DEVICE_PRIVATE:
-   case 

[RFC PATCH v2 0/8] Support DEVICE_GENERIC memory in migrate_vma_*

[Alex Sierra]

v1:
https://lore.kernel.org/linux-mm/20210529064022.gb15...@lst.de/T/

v2:
This patch series version has merged "[RFC PATCH v3 0/2]
mm: remove extra ZONE_DEVICE struct page refcount" patch series made by
Ralph Campbell. It also applies at the top of these series, our changes
to support device generic type in migration_vma helpers.
This has been tested in systems with device memory that has coherent
access by CPU.

Also addresses the following feedback made in v1:
- Isolate in one patch kernel/resource.c modification, based
on Christoph's feedback.
- Add helpers check for generic and private type to avoid
duplicated long lines.

I like to provide an overview of what each of the patches does in a series:

Patches 1-2: Rebased Ralph Campbell's ZONE_DEVICE page refcounting patches
Patch 3: Export lookup_resource
Patches 4-5: AMDGPU driver changes to register and use DEVICE_GENERIC memory
Patches 6-8: Handle DEVICE_GENERIC memory in migration helpers

Alex Sierra (6):
  kernel: resource: lookup_resource as exported symbol
  drm/amdkfd: add SPM support for SVM
  drm/amdkfd: generic type as sys mem on migration to ram
  include/linux/mm.h: helpers to check zone device generic type
  mm: add generic type support to migrate_vma helpers
  mm: call pgmap->ops->page_free for DEVICE_GENERIC pages

Ralph Campbell (2):
  ext4/xfs: add page refcount helper
  mm: remove extra ZONE_DEVICE struct page refcount

 arch/powerpc/kvm/book3s_hv_uvmem.c   |  2 +-
 drivers/gpu/drm/amd/amdkfd/kfd_migrate.c | 15 --
 drivers/gpu/drm/nouveau/nouveau_dmem.c   |  2 +-
 fs/dax.c |  8 +--
 fs/ext4/inode.c  |  5 +-
 fs/xfs/xfs_file.c|  4 +-
 include/linux/dax.h  | 10 
 include/linux/memremap.h |  7 +--
 include/linux/mm.h   | 52 +++---
 kernel/resource.c|  2 +-
 lib/test_hmm.c   |  2 +-
 mm/internal.h|  8 +++
 mm/memremap.c| 69 +++-
 mm/migrate.c | 13 ++---
 mm/page_alloc.c  |  3 ++
 mm/swap.c| 45 ++--
 16 files changed, 83 insertions(+), 164 deletions(-)

-- 
2.17.1

[RFC PATCH v2 1/8] ext4/xfs: add page refcount helper

[Alex Sierra]

From: Ralph Campbell 

There are several places where ZONE_DEVICE struct pages assume a reference
count == 1 means the page is idle and free. Instead of open coding this,
add a helper function to hide this detail.

Signed-off-by: Ralph Campbell 
---
 fs/dax.c|  4 ++--
 fs/ext4/inode.c |  5 +
 fs/xfs/xfs_file.c   |  4 +---
 include/linux/dax.h | 10 ++
 4 files changed, 14 insertions(+), 9 deletions(-)

diff --git a/fs/dax.c b/fs/dax.c
index 26d5dcd2d69e..321f4ddc6643 100644
--- a/fs/dax.c
+++ b/fs/dax.c
@@ -358,7 +358,7 @@ static void dax_disassociate_entry(void *entry, struct 
address_space *mapping,
for_each_mapped_pfn(entry, pfn) {
struct page *page = pfn_to_page(pfn);
 
-   WARN_ON_ONCE(trunc && page_ref_count(page) > 1);
+   WARN_ON_ONCE(trunc && !dax_layout_is_idle_page(page));
WARN_ON_ONCE(page->mapping && page->mapping != mapping);
page->mapping = NULL;
page->index = 0;
@@ -372,7 +372,7 @@ static struct page *dax_busy_page(void *entry)
for_each_mapped_pfn(entry, pfn) {
struct page *page = pfn_to_page(pfn);
 
-   if (page_ref_count(page) > 1)
+   if (!dax_layout_is_idle_page(page))
return page;
}
return NULL;
diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index c173c8405856..9ee00186412f 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -3972,10 +3972,7 @@ int ext4_break_layouts(struct inode *inode)
if (!page)
return 0;
 
-   error = ___wait_var_event(>_refcount,
-   atomic_read(>_refcount) == 1,
-   TASK_INTERRUPTIBLE, 0, 0,
-   ext4_wait_dax_page(ei));
+   error = dax_wait_page(ei, page, ext4_wait_dax_page);
} while (error == 0);
 
return error;
diff --git a/fs/xfs/xfs_file.c b/fs/xfs/xfs_file.c
index 5b0f93f73837..39565fe5f817 100644
--- a/fs/xfs/xfs_file.c
+++ b/fs/xfs/xfs_file.c
@@ -782,9 +782,7 @@ xfs_break_dax_layouts(
return 0;
 
*retry = true;
-   return ___wait_var_event(>_refcount,
-   atomic_read(>_refcount) == 1, TASK_INTERRUPTIBLE,
-   0, 0, xfs_wait_dax_page(inode));
+   return dax_wait_page(inode, page, xfs_wait_dax_page);
 }
 
 int
diff --git a/include/linux/dax.h b/include/linux/dax.h
index b52f084aa643..8909a91cd381 100644
--- a/include/linux/dax.h
+++ b/include/linux/dax.h
@@ -243,6 +243,16 @@ static inline bool dax_mapping(struct address_space 
*mapping)
return mapping->host && IS_DAX(mapping->host);
 }
 
+static inline bool dax_layout_is_idle_page(struct page *page)
+{
+   return page_ref_count(page) == 1;
+}
+
+#define dax_wait_page(_inode, _page, _wait_cb) \
+   ___wait_var_event(&(_page)->_refcount,  \
+   dax_layout_is_idle_page(_page), \
+   TASK_INTERRUPTIBLE, 0, 0, _wait_cb(_inode))
+
 #ifdef CONFIG_DEV_DAX_HMEM_DEVICES
 void hmem_register_device(int target_nid, struct resource *r);
 #else
-- 
2.17.1

Re: [PATCH 4/4] drm/i915/display: Add handling for new "active bpc" property

[Werner Sembach]

Am 07.06.21 um 08:47 schrieb Werner Sembach:


Am 04.06.21 um 19:30 schrieb Ville Syrjälä:

On Fri, Jun 04, 2021 at 07:17:23PM +0200, Werner Sembach wrote:
This commits implements the "active bpc" drm property for the Intel 
GPU driver.


Signed-off-by: Werner Sembach 
---
  drivers/gpu/drm/i915/display/intel_display.c | 13 +
  drivers/gpu/drm/i915/display/intel_dp.c  |  8 ++--
  drivers/gpu/drm/i915/display/intel_dp_mst.c  |  4 +++-
  drivers/gpu/drm/i915/display/intel_hdmi.c    |  4 +++-
  4 files changed, 25 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c

index 64e9107d70f7..f7898d9d7438 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -10164,6 +10164,8 @@ static void intel_atomic_commit_tail(struct 
intel_atomic_state *state)

  struct drm_i915_private *dev_priv = to_i915(dev);
  struct intel_crtc_state *new_crtc_state, *old_crtc_state;
  struct intel_crtc *crtc;
+    struct drm_connector *connector;
+    struct drm_connector_state *new_conn_state;
  u64 put_domains[I915_MAX_PIPES] = {};
  intel_wakeref_t wakeref = 0;
  int i;
@@ -10324,6 +10326,17 @@ static void intel_atomic_commit_tail(struct 
intel_atomic_state *state)

  }
  intel_runtime_pm_put(_priv->runtime_pm, state->wakeref);
  +    /* Extract information from crtc to communicate it to 
userspace as connector properties */
+    for_each_new_connector_in_state(>base, connector, 
new_conn_state, i) {

+    struct drm_crtc *crtc = new_conn_state->crtc;
+    if (crtc) {
+    new_crtc_state = 
to_intel_crtc_state(drm_atomic_get_new_crtc_state(>base, crtc));

intel_atomic_get_new_crtc_state()

Thanks, will use that.



+ new_conn_state->active_bpc = new_crtc_state->pipe_bpp / 3;
+    }
+    else
+    new_conn_state->active_bpc = 0;
+    }

This also seems too late. I think the whole thing should be
done somewhere around the normal swap_state() stuff.

Ok, will look into it.
So I tried to put it in intel_atomic_commit() after 
drm_atomic_helper_swap_state() and before 
INIT_WORK(>base.commit_work, intel_atomic_commit_work) (which 
creates a worker for intel_atomic_commit_tail), but somewhere in 
between, the connector_state seems to change: The bpc written with the 
for_each_new_connector_in_state() loop, gets discarded.



+
  /*
   * Defer the cleanup of the old state to a separate worker to not
   * impede the current task (userspace for blocking modesets) that
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c

index 642c60f3d9b1..67826ba976ed 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4671,10 +4671,14 @@ intel_dp_add_properties(struct intel_dp 
*intel_dp, struct drm_connector *connect

  intel_attach_force_audio_property(connector);
    intel_attach_broadcast_rgb_property(connector);
-    if (HAS_GMCH(dev_priv))
+    if (HAS_GMCH(dev_priv)) {
  drm_connector_attach_max_bpc_property(connector, 6, 10);
-    else if (DISPLAY_VER(dev_priv) >= 5)
+    drm_connector_attach_active_bpc_property(connector, 6, 10);
+    }
+    else if (DISPLAY_VER(dev_priv) >= 5) {
  drm_connector_attach_max_bpc_property(connector, 6, 12);
+    drm_connector_attach_active_bpc_property(connector, 6, 12);
+    }
    /* Register HDMI colorspace for case of lspcon */
  if (intel_bios_is_lspcon_present(dev_priv, port)) {
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c 
b/drivers/gpu/drm/i915/display/intel_dp_mst.c

index 2daa3f67791e..5a1869dc2210 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -844,8 +844,10 @@ static struct drm_connector 
*intel_dp_add_mst_connector(struct drm_dp_mst_topolo

   */
  connector->max_bpc_property =
intel_dp->attached_connector->base.max_bpc_property;
-    if (connector->max_bpc_property)
+    if (connector->max_bpc_property) {
  drm_connector_attach_max_bpc_property(connector, 6, 12);
+    drm_connector_attach_active_bpc_property(connector, 6, 12);
+    }
    return connector;
  diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
b/drivers/gpu/drm/i915/display/intel_hdmi.c

index d69f0a6dc26d..8af78b27b6ce 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -2463,8 +2463,10 @@ intel_hdmi_add_properties(struct intel_hdmi 
*intel_hdmi, struct drm_connector *c

  drm_object_attach_property(>base,
connector->dev->mode_config.hdr_output_metadata_property, 0);
  -    if (!HAS_GMCH(dev_priv))
+    if (!HAS_GMCH(dev_priv)) {
  drm_connector_attach_max_bpc_property(connector, 8, 12);
+    drm_connector_attach_active_bpc_property(connector, 8, 12);
+    }
  }
    /*
--
2.25.1

[PATCH][next] drm/i915/gem: Fix fall-through warning for Clang

[Gustavo A. R. Silva]

In preparation to enable -Wimplicit-fallthrough for Clang, fix a
warning by explicitly adding a fallthrough; statement.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva 
---
JFYI: We had thousands of these sorts of warnings and now we are down
  to just 13 in linux-next(20210607). This is one of those last
  remaining warnings. :)

 drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c 
b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
index f4fb68e8955a..17714da24033 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
@@ -62,6 +62,7 @@ static void try_to_writeback(struct drm_i915_gem_object *obj,
switch (obj->mm.madv) {
case I915_MADV_DONTNEED:
i915_gem_object_truncate(obj);
+   fallthrough;
case __I915_MADV_PURGED:
return;
}
-- 
2.27.0

[PATCH] drm: panel: simple: specify bpc for powertip_ph800480t013_idf02

[Dmitry Baryshkov]

Specify bpc value for the powertip_ph800480t013_idf02 panel to stop drm
code from complaining about unexpected bpc value (0).

Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/panel/panel-simple.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 4e2dad314c79..e273bc2ab6b1 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -3317,6 +3317,7 @@ static const struct drm_display_mode 
powertip_ph800480t013_idf02_mode = {
 static const struct panel_desc powertip_ph800480t013_idf02  = {
.modes = _ph800480t013_idf02_mode,
.num_modes = 1,
+   .bpc = 8,
.size = {
.width = 152,
.height = 91,
-- 
2.30.2

[PATCH v2] drm/msm/dsi: add continuous clock support for 7nm PHY

[Dmitry Baryshkov]

Unlike previous generations, 7nm PHYs are required to collaborate with
the host for conitnuos clock mode. Add changes neccessary to enable
continuous clock mode in the 7nm DSI PHYs.

Signed-off-by: Dmitry Baryshkov 
---

Changes since v1:

 - Remove the need for a separate msm_dsi_phy_needs_hs_req_sel call
 - Fix setting continuous clock for a dual DSI case.

---
 drivers/gpu/drm/msm/dsi/dsi.h |  3 ++-
 drivers/gpu/drm/msm/dsi/dsi.xml.h |  1 +
 drivers/gpu/drm/msm/dsi/dsi_host.c| 12 
 drivers/gpu/drm/msm/dsi/dsi_manager.c |  4 ++--
 drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 16 
 drivers/gpu/drm/msm/dsi/phy/dsi_phy.h |  1 +
 drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c | 17 +
 7 files changed, 47 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi.h b/drivers/gpu/drm/msm/dsi/dsi.h
index 7abfeab08165..5be458c701d2 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.h
+++ b/drivers/gpu/drm/msm/dsi/dsi.h
@@ -108,7 +108,7 @@ int msm_dsi_host_enable(struct mipi_dsi_host *host);
 int msm_dsi_host_disable(struct mipi_dsi_host *host);
 int msm_dsi_host_power_on(struct mipi_dsi_host *host,
struct msm_dsi_phy_shared_timings *phy_shared_timings,
-   bool is_dual_dsi);
+   bool is_dual_dsi, struct msm_dsi_phy *phy);
 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);
@@ -173,6 +173,7 @@ int msm_dsi_phy_get_clk_provider(struct msm_dsi_phy *phy,
struct clk **byte_clk_provider, struct clk **pixel_clk_provider);
 void msm_dsi_phy_pll_save_state(struct msm_dsi_phy *phy);
 int msm_dsi_phy_pll_restore_state(struct msm_dsi_phy *phy);
+bool msm_dsi_phy_set_continuous_clock(struct msm_dsi_phy *phy, bool enable);
 
 #endif /* __DSI_CONNECTOR_H__ */
 
diff --git a/drivers/gpu/drm/msm/dsi/dsi.xml.h 
b/drivers/gpu/drm/msm/dsi/dsi.xml.h
index 50eb4d1b8fdd..9762af6035e9 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.xml.h
+++ b/drivers/gpu/drm/msm/dsi/dsi.xml.h
@@ -510,6 +510,7 @@ static inline uint32_t 
DSI_CLKOUT_TIMING_CTRL_T_CLK_POST(uint32_t val)
 #define DSI_LANE_STATUS_DLN0_DIRECTION 0x0001
 
 #define REG_DSI_LANE_CTRL  0x00a8
+#define DSI_LANE_CTRL_HS_REQ_SEL_PHY   0x0100
 #define DSI_LANE_CTRL_CLKLN_HS_FORCE_REQUEST   0x1000
 
 #define REG_DSI_LANE_SWAP_CTRL 0x00ac
diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 41e1d0f7ab6e..50be935edcad 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -835,7 +835,7 @@ static inline enum dsi_cmd_dst_format dsi_get_cmd_fmt(
 }
 
 static void dsi_ctrl_config(struct msm_dsi_host *msm_host, bool enable,
-   struct msm_dsi_phy_shared_timings *phy_shared_timings)
+   struct msm_dsi_phy_shared_timings *phy_shared_timings, 
struct msm_dsi_phy *phy)
 {
u32 flags = msm_host->mode_flags;
enum mipi_dsi_pixel_format mipi_fmt = msm_host->format;
@@ -930,6 +930,10 @@ static void dsi_ctrl_config(struct msm_dsi_host *msm_host, 
bool enable,
 
if (!(flags & MIPI_DSI_CLOCK_NON_CONTINUOUS)) {
lane_ctrl = dsi_read(msm_host, REG_DSI_LANE_CTRL);
+
+   if (msm_dsi_phy_set_continuous_clock(phy, enable))
+   lane_ctrl |= DSI_LANE_CTRL_HS_REQ_SEL_PHY;
+
dsi_write(msm_host, REG_DSI_LANE_CTRL,
lane_ctrl | DSI_LANE_CTRL_CLKLN_HS_FORCE_REQUEST);
}
@@ -2360,7 +2364,7 @@ static void msm_dsi_sfpb_config(struct msm_dsi_host 
*msm_host, bool enable)
 
 int msm_dsi_host_power_on(struct mipi_dsi_host *host,
struct msm_dsi_phy_shared_timings *phy_shared_timings,
-   bool is_dual_dsi)
+   bool is_dual_dsi, struct msm_dsi_phy *phy)
 {
struct msm_dsi_host *msm_host = to_msm_dsi_host(host);
const struct msm_dsi_cfg_handler *cfg_hnd = msm_host->cfg_hnd;
@@ -2400,7 +2404,7 @@ int msm_dsi_host_power_on(struct mipi_dsi_host *host,
 
dsi_timing_setup(msm_host, is_dual_dsi);
dsi_sw_reset(msm_host);
-   dsi_ctrl_config(msm_host, true, phy_shared_timings);
+   dsi_ctrl_config(msm_host, true, phy_shared_timings, phy);
 
if (msm_host->disp_en_gpio)
gpiod_set_value(msm_host->disp_en_gpio, 1);
@@ -2431,7 +2435,7 @@ int msm_dsi_host_power_off(struct mipi_dsi_host *host)
goto unlock_ret;
}
 
-   dsi_ctrl_config(msm_host, false, NULL);
+   dsi_ctrl_config(msm_host, false, NULL, NULL);
 
if (msm_host->disp_en_gpio)
gpiod_set_value(msm_host->disp_en_gpio, 0);
diff --git 

Re: [PATCH v2] drm/panel: db7430: Add driver for Samsung DB7430

[Doug Anderson]

Hi,

On Fri, Jun 4, 2021 at 4:19 PM Linus Walleij  wrote:
>
> On Tue, Jun 1, 2021 at 11:31 PM Doug Anderson  wrote:
>
> > Still hoping that this can work atop DBI so we can avoid the raw SPI
> > writes. You said you're trying for it for v3 so I'm looking forward to
> > checking it out there.
>
> Struggling with this. The DBI bus is only used by tiny DRM
> for the panel drivers that are jitted with that display controller
> ATM. No normal panel driver is using it.

:( So how about this, then?

* If someone more senior than me in DRM says it's fine to just do this
directly for now then I have no objections. It'd be nice to mention
that this is actually DBI "type c1" somewhere in the comments, but
other than that the direct SPI stuff is OK.

* If there are 3+ other panels drivers that you can point to that
directly use SPI functions for DBI like you are doing then I'm OK w/
it too even if nobody more senior signs on w/ it. Presumably if there
are at least 3 already then someone else has already signed on to the
fact that this is fine to do. It'd still be nice to do a cleanup but
presumably that could all be done at the same time.

* If you're the first or second or third panel driver that's doing
this directly with SPI commands then it probably makes sense to pause
and figure out how to use DBI right now before more drivers come
around and copy the code.

Hopefully that sounds OK.

-Doug

Re: [PATCH 5/7] dma-buf: rename and cleanup dma_resv_get_list

[Jason Ekstrand]

On Sun, Jun 6, 2021 at 3:53 AM Christian König
 wrote:
>
> Am 02.06.21 um 22:22 schrieb Jason Ekstrand:
> > On Wed, Jun 2, 2021 at 6:17 AM Christian König
> >  wrote:
> >> When the comment needs to state explicitly that this is doesn't get a 
> >> reference
> >> to the object then the function is named rather badly.
> >>
> >> Rename the function and use it in even more places.
> >>
> >> Signed-off-by: Christian König 
> >> ---
> >>   drivers/dma-buf/dma-resv.c| 32 +--
> >>   .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c  |  2 +-
> >>   drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c   |  2 +-
> >>   drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c  |  2 +-
> >>   drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c   |  2 +-
> >>   drivers/gpu/drm/etnaviv/etnaviv_gem.c |  2 +-
> >>   drivers/gpu/drm/i915/gem/i915_gem_busy.c  |  2 +-
> >>   drivers/gpu/drm/msm/msm_gem.c |  4 +--
> >>   drivers/gpu/drm/nouveau/nouveau_fence.c   |  2 +-
> >>   drivers/gpu/drm/qxl/qxl_debugfs.c |  2 +-
> >>   drivers/gpu/drm/radeon/radeon_sync.c  |  2 +-
> >>   drivers/gpu/drm/ttm/ttm_bo.c  |  2 +-
> >>   include/linux/dma-resv.h  | 25 +++
> >>   13 files changed, 39 insertions(+), 42 deletions(-)
> >>
> >> diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
> >> index 81b032b43457..b1a1a31dc009 100644
> >> --- a/drivers/dma-buf/dma-resv.c
> >> +++ b/drivers/dma-buf/dma-resv.c
> >> @@ -149,8 +149,7 @@ int dma_resv_reserve_shared(struct dma_resv *obj, 
> >> unsigned int num_fences)
> >>
> >>  dma_resv_assert_held(obj);
> >>
> >> -   old = dma_resv_get_list(obj);
> >> -
> >> +   old = dma_resv_shared(obj);
> >>  if (old && old->shared_max) {
> >>  if ((old->shared_count + num_fences) <= old->shared_max)
> >>  return 0;
> >> @@ -217,12 +216,13 @@ EXPORT_SYMBOL(dma_resv_reserve_shared);
> >>*/
> >>   void dma_resv_reset_shared_max(struct dma_resv *obj)
> >>   {
> >> -   /* Test shared fence slot reservation */
> >> -   if (rcu_access_pointer(obj->fence)) {
> >> -   struct dma_resv_list *fence = dma_resv_get_list(obj);
> >> +   struct dma_resv_list *fences = dma_resv_shared(obj);
> >>
> >> -   fence->shared_max = fence->shared_count;
> >> -   }
> >> +   dma_resv_assert_held(obj);
> > Does it make sense to assert we hold the lock *before* we touch it
> > with something that requires that we do?  Maybe it doesn't matter?
>
> As far as I can see that shouldn't matter.
>
> >
> >> +
> >> +   /* Test shared fence slot reservation */
> >> +   if (fences)
> >> +   fences->shared_max = fences->shared_count;
> >>   }
> >>   #endif
> >>
> >> @@ -244,7 +244,7 @@ void dma_resv_add_shared_fence(struct dma_resv *obj, 
> >> struct dma_fence *fence)
> >>
> >>  dma_resv_assert_held(obj);
> >>
> >> -   fobj = dma_resv_get_list(obj);
> >> +   fobj = dma_resv_shared(obj);
> >>  count = fobj->shared_count;
> >>
> >>  write_seqcount_begin(>seq);
> >> @@ -287,7 +287,7 @@ void dma_resv_add_excl_fence(struct dma_resv *obj, 
> >> struct dma_fence *fence)
> >>
> >>  dma_resv_assert_held(obj);
> >>
> >> -   old = dma_resv_get_list(obj);
> >> +   old = dma_resv_shared(obj);
> >>  if (old)
> >>  i = old->shared_count;
> >>
> >> @@ -326,7 +326,7 @@ int dma_resv_copy_fences(struct dma_resv *dst, struct 
> >> dma_resv *src)
> >>  dma_resv_assert_held(dst);
> >>
> >>  rcu_read_lock();
> >> -   src_list = rcu_dereference(src->fence);
> >> +   src_list = dma_resv_shared(src);
> >>
> >>   retry:
> >>  if (src_list) {
> >> @@ -339,7 +339,7 @@ int dma_resv_copy_fences(struct dma_resv *dst, struct 
> >> dma_resv *src)
> >>  return -ENOMEM;
> >>
> >>  rcu_read_lock();
> >> -   src_list = rcu_dereference(src->fence);
> >> +   src_list = dma_resv_shared(src);
> >>  if (!src_list || src_list->shared_count > shared_count) {
> >>  kfree(dst_list);
> >>  goto retry;
> >> @@ -357,7 +357,7 @@ int dma_resv_copy_fences(struct dma_resv *dst, struct 
> >> dma_resv *src)
> >>
> >>  if (!dma_fence_get_rcu(fence)) {
> >>  dma_resv_list_free(dst_list);
> >> -   src_list = rcu_dereference(src->fence);
> >> +   src_list = dma_resv_shared(src);
> >>  goto retry;
> >>  }
> >>
> >> @@ -376,7 +376,7 @@ int dma_resv_copy_fences(struct dma_resv *dst, struct 
> >> dma_resv *src)
> >>  new = dma_fence_get_rcu_safe(>fence_excl);
> >>  rcu_read_unlock();
> >>
> >> -   src_list = dma_resv_get_list(dst);
> >> +   src_list = 

Re: [Intel-gfx] [PATCH 09/13] drm/i915/doc: Include GuC ABI documentation

[Matthew Brost]

On Mon, Jun 07, 2021 at 09:38:58PM +0200, Michal Wajdeczko wrote:
> 
> 
> On 07.06.2021 19:45, Matthew Brost wrote:
> > On Mon, Jun 07, 2021 at 11:03:51AM -0700, Matthew Brost wrote:
> >> From: Michal Wajdeczko 
> >>
> >> GuC ABI documentation is now ready to be included in i915.rst
> >>
> >> Signed-off-by: Michal Wajdeczko 
> >> Signed-off-by: Matthew Brost 
> >> Cc: Piotr Piórkowski 
> > 
> > Michal - I noticed while putting this series together that there is
> > kernel doc in intel_guc_ct.* but this isn't inclued in i915.rst. Do you
> > think we should add the those here or in a new section (e.g. GuC CTBs)?
> > 
> > Let me know what you think and I can fix this up before this gets
> > merged.
> 
> What's in intel_guc_ct.* is implementation detail, that should be placed
> in separate section, while this patch adds pure ABI definitions that
> deserve its own dedicated section.
> 

Sounds good. Will fix that in the next rev.

> Btw, this patch does not need to be squashed with others, as it is about
> updating .rst only and is not breaking anything. Same for patch 1/13
> that introduces new definitions in new .h file.
> 

Agree. What I said in the cover letter isn't 100% correct as some of
patches probably don't have to be squashed. Next rev I'll go through
patch by patch and figure that part out.

Matt

> Michal
> 
> > 
> > With that, for this patch:
> > 
> > Reviewed-by: Matthew Brost 
> > 
> >> ---
> >>  Documentation/gpu/i915.rst | 8 
> >>  1 file changed, 8 insertions(+)
> >>
> >> diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
> >> index 42ce0196930a..c7846b1d9293 100644
> >> --- a/Documentation/gpu/i915.rst
> >> +++ b/Documentation/gpu/i915.rst
> >> @@ -518,6 +518,14 @@ GuC-based command submission
> >>  .. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> >> :doc: GuC-based command submission
> >>  
> >> +GuC ABI
> >> +
> >> +
> >> +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/abi/guc_messages_abi.h
> >> +.. kernel-doc:: 
> >> drivers/gpu/drm/i915/gt/uc/abi/guc_communication_mmio_abi.h
> >> +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
> >> +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
> >> +
> >>  HuC
> >>  ---
> >>  .. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_huc.c
> >> -- 
> >> 2.28.0
> >>
> >> ___
> >> Intel-gfx mailing list
> >> intel-...@lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > ___
> > Intel-gfx mailing list
> > intel-...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > 

[Bug 213145] AMDGPU resets, timesout and crashes after "*ERROR* Waiting for fences timed out!"

[bugzilla-daemon]

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

--- Comment #7 from Tomas Gayoso (tgay...@gmail.com) ---
System config for the record as in the mesa bug: 

root@tufboxen:~# date 
Mon Jun  7 16:40:27 -03 2021
root@tufboxen:~# inxi -GSC -xx
System:Host: tufboxen.lan Kernel: 5.10.42-TUF x86_64 bits: 64 compiler: gcc
v: 2.36.1-slack15 Desktop: i3 4.18.3 dm: XDM 
   Distro: Slackware 14.2 
CPU:   Info: 8-Core model: AMD Ryzen 7 4800H with Radeon Graphics bits: 64
type: MT MCP arch: Zen 2 rev: 1 cache: 
   L1: 512 KiB L2: 4 MiB L3: 8 MiB 
   flags: avx avx2 lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3
svm bogomips: 92624 
   Speed: 1370 MHz min/max: 1400/2900 MHz boost: enabled Core speeds
(MHz): 1: 1370 2: 1290 3: 1402 4: 1497 5: 1388 
   6: 1327 7: 1390 8: 1391 9: 1566 10: 1370 11: 1301 12: 1396 13: 1394
14: 1411 15: 1397 16: 1517 
Graphics:  Device-1: NVIDIA TU116M [GeForce GTX 1660 Ti Mobile] vendor: ASUSTeK
driver: nvidia v: 465.31 bus-ID: 01:00.0 
   chip-ID: 10de:2191 
   Device-2: Advanced Micro Devices [AMD/ATI] Renoir vendor: ASUSTeK
driver: amdgpu v: kernel bus-ID: 05:00.0 
   chip-ID: 1002:1636 
   Device-3: IMC Networks USB2.0 HD UVC WebCam type: USB driver:
uvcvideo bus-ID: 3-4:4 chip-ID: 13d3:56a2 
   Display: server: X.Org 1.20.11 driver: loaded: amdgpu,ati,nvidia
unloaded: modesetting,nouveau,nv,vesa 
   alternate: fbdev resolution: 1: 1920x1080~144Hz 2: 2560x1440 s-dpi:
96 
   OpenGL: renderer: AMD RENOIR (DRM 3.40.0 5.10.42-TUF LLVM 12.0.0) v:
4.6 Mesa 21.1.2 direct render: Yes 
root@tufboxen:~#

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

You are receiving this mail because:
You are watching the assignee of the bug.

Re: [Intel-gfx] [PATCH 09/13] drm/i915/doc: Include GuC ABI documentation

[Michal Wajdeczko]

On 07.06.2021 19:45, Matthew Brost wrote:
> On Mon, Jun 07, 2021 at 11:03:51AM -0700, Matthew Brost wrote:
>> From: Michal Wajdeczko 
>>
>> GuC ABI documentation is now ready to be included in i915.rst
>>
>> Signed-off-by: Michal Wajdeczko 
>> Signed-off-by: Matthew Brost 
>> Cc: Piotr Piórkowski 
> 
> Michal - I noticed while putting this series together that there is
> kernel doc in intel_guc_ct.* but this isn't inclued in i915.rst. Do you
> think we should add the those here or in a new section (e.g. GuC CTBs)?
> 
> Let me know what you think and I can fix this up before this gets
> merged.

What's in intel_guc_ct.* is implementation detail, that should be placed
in separate section, while this patch adds pure ABI definitions that
deserve its own dedicated section.

Btw, this patch does not need to be squashed with others, as it is about
updating .rst only and is not breaking anything. Same for patch 1/13
that introduces new definitions in new .h file.

Michal

> 
> With that, for this patch:
> 
> Reviewed-by: Matthew Brost 
> 
>> ---
>>  Documentation/gpu/i915.rst | 8 
>>  1 file changed, 8 insertions(+)
>>
>> diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
>> index 42ce0196930a..c7846b1d9293 100644
>> --- a/Documentation/gpu/i915.rst
>> +++ b/Documentation/gpu/i915.rst
>> @@ -518,6 +518,14 @@ GuC-based command submission
>>  .. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>> :doc: GuC-based command submission
>>  
>> +GuC ABI
>> +
>> +
>> +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/abi/guc_messages_abi.h
>> +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/abi/guc_communication_mmio_abi.h
>> +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
>> +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
>> +
>>  HuC
>>  ---
>>  .. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_huc.c
>> -- 
>> 2.28.0
>>
>> ___
>> Intel-gfx mailing list
>> intel-...@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 

[Bug 213145] AMDGPU resets, timesout and crashes after "*ERROR* Waiting for fences timed out!"

[bugzilla-daemon]

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

--- Comment #6 from Tomas Gayoso (tgay...@gmail.com) ---
I upgraded my setep to mesa-21.1.2, but I can still trigger the bug at will on
fresh boot by opening a single xterm on i3wm and resizing it while running any
fast scrolling character binary, like cli-visualizer (
https://github.com/dpayne/cli-visualizer ). 

The other suggestions on the thread for the amdgpu module setting do nothing
for me. 

Willing to patch my kernel and test, I can compile my own.

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

You are receiving this mail because:
You are watching the assignee of the bug.

Re: [Intel-gfx] [PATCH 13/13] drm/i915/guc: Update firmware to v62.0.0

[Matthew Brost]

On Mon, Jun 07, 2021 at 11:03:55AM -0700, Matthew Brost wrote:
> From: John Harrison 
> 
> Signed-off-by: John Harrison 
> Signed-off-by: Michal Wajdeczko 
> Signed-off-by: Matthew Brost 

Reviewed-by: Matthew Brost 

> ---
>  drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 26 
>  1 file changed, 13 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c 
> b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
> index df647c9a8d56..9f23e9de3237 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
> @@ -48,19 +48,19 @@ void intel_uc_fw_change_status(struct intel_uc_fw *uc_fw,
>   * firmware as TGL.
>   */
>  #define INTEL_UC_FIRMWARE_DEFS(fw_def, guc_def, huc_def) \
> - fw_def(ALDERLAKE_S, 0, guc_def(tgl, 49, 0, 1), huc_def(tgl,  7, 5, 0)) \
> - fw_def(ROCKETLAKE,  0, guc_def(tgl, 49, 0, 1), huc_def(tgl,  7, 5, 0)) \
> - fw_def(TIGERLAKE,   0, guc_def(tgl, 49, 0, 1), huc_def(tgl,  7, 5, 0)) \
> - fw_def(JASPERLAKE,  0, guc_def(ehl, 49, 0, 1), huc_def(ehl,  9, 0, 0)) \
> - fw_def(ELKHARTLAKE, 0, guc_def(ehl, 49, 0, 1), huc_def(ehl,  9, 0, 0)) \
> - fw_def(ICELAKE, 0, guc_def(icl, 49, 0, 1), huc_def(icl,  9, 0, 0)) \
> - fw_def(COMETLAKE,   5, guc_def(cml, 49, 0, 1), huc_def(cml,  4, 0, 0)) \
> - fw_def(COMETLAKE,   0, guc_def(kbl, 49, 0, 1), huc_def(kbl,  4, 0, 0)) \
> - fw_def(COFFEELAKE,  0, guc_def(kbl, 49, 0, 1), huc_def(kbl,  4, 0, 0)) \
> - fw_def(GEMINILAKE,  0, guc_def(glk, 49, 0, 1), huc_def(glk,  4, 0, 0)) \
> - fw_def(KABYLAKE,0, guc_def(kbl, 49, 0, 1), huc_def(kbl,  4, 0, 0)) \
> - fw_def(BROXTON, 0, guc_def(bxt, 49, 0, 1), huc_def(bxt,  2, 0, 0)) \
> - fw_def(SKYLAKE, 0, guc_def(skl, 49, 0, 1), huc_def(skl,  2, 0, 0))
> + fw_def(ALDERLAKE_S, 0, guc_def(tgl, 62, 0, 0), huc_def(tgl,  7, 5, 0)) \
> + fw_def(ROCKETLAKE,  0, guc_def(tgl, 62, 0, 0), huc_def(tgl,  7, 5, 0)) \
> + fw_def(TIGERLAKE,   0, guc_def(tgl, 62, 0, 0), huc_def(tgl,  7, 5, 0)) \
> + fw_def(JASPERLAKE,  0, guc_def(ehl, 62, 0, 0), huc_def(ehl,  9, 0, 0)) \
> + fw_def(ELKHARTLAKE, 0, guc_def(ehl, 62, 0, 0), huc_def(ehl,  9, 0, 0)) \
> + fw_def(ICELAKE, 0, guc_def(icl, 62, 0, 0), huc_def(icl,  9, 0, 0)) \
> + fw_def(COMETLAKE,   5, guc_def(cml, 62, 0, 0), huc_def(cml,  4, 0, 0)) \
> + fw_def(COMETLAKE,   0, guc_def(kbl, 62, 0, 0), huc_def(kbl,  4, 0, 0)) \
> + fw_def(COFFEELAKE,  0, guc_def(kbl, 62, 0, 0), huc_def(kbl,  4, 0, 0)) \
> + fw_def(GEMINILAKE,  0, guc_def(glk, 62, 0, 0), huc_def(glk,  4, 0, 0)) \
> + fw_def(KABYLAKE,0, guc_def(kbl, 62, 0, 0), huc_def(kbl,  4, 0, 0)) \
> + fw_def(BROXTON, 0, guc_def(bxt, 62, 0, 0), huc_def(bxt,  2, 0, 0)) \
> + fw_def(SKYLAKE, 0, guc_def(skl, 62, 0, 0), huc_def(skl,  2, 0, 0))
>  
>  #define __MAKE_UC_FW_PATH(prefix_, name_, major_, minor_, patch_) \
>   "i915/" \
> -- 
> 2.28.0
> 
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] drm/ttm: fix access to uninitialized variable.

[Das, Nirmoy]

Reviewed-by:  Nirmoy Das 

On 6/7/2021 7:11 PM, Christian König wrote:

The resource is not allocated yet, so no chance that this will work.

Use the placement instead.

Signed-off-by: Christian König 
---
  drivers/gpu/drm/ttm/ttm_bo.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 7e7284da5630..0c74f4cb2a3b 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -736,7 +736,7 @@ static int ttm_bo_mem_force_space(struct ttm_buffer_object 
*bo,
struct ww_acquire_ctx *ticket;
int ret;
  
-	man = ttm_manager_type(bdev, (*mem)->mem_type);

+   man = ttm_manager_type(bdev, place->mem_type);
ticket = dma_resv_locking_ctx(bo->base.resv);
do {
ret = ttm_resource_alloc(bo, place, mem);

[PATCH] drm/rockchip: remove of_match_ptr() from vop_driver_dt_match

[Souptick Joarder]

kernel test robot throws warning when CONFIG_OF not set.

>> drivers/gpu/drm/rockchip/rockchip_vop_reg.c:1038:34:
warning: unused variable 'vop_driver_dt_match' [-Wunused-const-variable]
   static const struct of_device_id vop_driver_dt_match[] = {

Fixed it by removing of_match_ptr().

Reported-by: kernel test robot 
Signed-off-by: Souptick Joarder 
Cc: Robin Murphy 
---
 drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c 
b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index ca7cc82125cb..1f7353f0684a 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -1124,6 +1124,6 @@ struct platform_driver vop_platform_driver = {
.remove = vop_remove,
.driver = {
.name = "rockchip-vop",
-   .of_match_table = of_match_ptr(vop_driver_dt_match),
+   .of_match_table = vop_driver_dt_match,
},
 };
-- 
2.25.1

[PATCH v2] drm/rockchip: remove of_match_ptr()

[Souptick Joarder]

Kernel test robot throws below warning when CONFIG_OF
is not set.

>> drivers/gpu/drm/rockchip/analogix_dp-rockchip.c:457:34:
warning: unused variable 'rockchip_dp_dt_ids' [-Wunused-const-variable]
   static const struct of_device_id rockchip_dp_dt_ids[] = {

Fixed it by removing of_match_ptr().

Reported-by: kernel test robot 
Signed-off-by: Souptick Joarder 
Cc: Robin Murphy  
---
v2:
Address review comment from Robin.
updated change logs and subject line.

 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c 
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index ade2327a10e2..8abb5ac26807 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -467,6 +467,6 @@ struct platform_driver rockchip_dp_driver = {
.driver = {
   .name = "rockchip-dp",
   .pm = _dp_pm_ops,
-  .of_match_table = of_match_ptr(rockchip_dp_dt_ids),
+  .of_match_table = rockchip_dp_dt_ids,
},
 };
-- 
2.25.1

Re: [PATCH] drm/rockchip: defined struct rockchip_dp_dt_ids[] under CONFIG_OF

[Souptick Joarder]

On Wed, Jun 2, 2021 at 3:37 PM Robin Murphy  wrote:
>
> On 2021-06-02 09:02, Souptick Joarder wrote:
> > Kernel test robot throws below warning when CONFIG_OF
> > is not set.
> >
> >>> drivers/gpu/drm/rockchip/analogix_dp-rockchip.c:457:34:
> > warning: unused variable 'rockchip_dp_dt_ids' [-Wunused-const-variable]
> > static const struct of_device_id rockchip_dp_dt_ids[] = {
> >
> > Fixed it by defining rockchip_dp_dt_ids[] under CONFIG_OF.
>
> I think the __maybe_unused annotation is generally preferred over
> #ifdefs these days. However, since these drivers only work with
> devicetree anyway, it probably makes more sense to just remove the
> of_match_ptr() uses which lead to these warnings in the first place.

Ok. Will remove of_match_ptr().
>
> Robin.
>
> > Reported-by: kernel test robot 
> > Signed-off-by: Souptick Joarder 
> > ---
> >   drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 2 ++
> >   1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c 
> > b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> > index ade2327a10e2..9b79ebaeae97 100644
> > --- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> > +++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> > @@ -454,12 +454,14 @@ static const struct rockchip_dp_chip_data rk3288_dp = 
> > {
> >   .chip_type = RK3288_DP,
> >   };
> >
> > +#ifdef CONFIG_OF
> >   static const struct of_device_id rockchip_dp_dt_ids[] = {
> >   {.compatible = "rockchip,rk3288-dp", .data = _dp },
> >   {.compatible = "rockchip,rk3399-edp", .data = _edp },
> >   {}
> >   };
> >   MODULE_DEVICE_TABLE(of, rockchip_dp_dt_ids);
> > +#endif
> >
> >   struct platform_driver rockchip_dp_driver = {
> >   .probe = rockchip_dp_probe,
> >

[PATCH 6/6] drm/i915/ttm: restore min_page_size behaviour

[Matthew Auld]

We now have bo->page_alignment which perfectly describes what we need if
we have min page size restrictions for lmem. We can also drop the flag
here, since this is the default behaviour for all objects.

Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
---
 drivers/gpu/drm/i915/gem/i915_gem_ttm.c  | 3 +--
 drivers/gpu/drm/i915/intel_memory_region.h   | 3 +--
 drivers/gpu/drm/i915/intel_region_ttm.c  | 2 +-
 drivers/gpu/drm/i915/selftests/mock_region.c | 2 +-
 4 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c 
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 3f5624f36afc..eda6c258ea92 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -684,9 +684,8 @@ int __i915_gem_ttm_object_init(struct intel_memory_region 
*mem,
 */
obj->base.vma_node.driver_private = i915_gem_to_ttm(obj);
ret = ttm_bo_init(>bdev, i915_gem_to_ttm(obj), size,
- bo_type, _sys_placement, PAGE_SIZE,
+ bo_type, _sys_placement, mem->min_page_size,
  true, NULL, NULL, i915_ttm_bo_destroy);
-
if (!ret)
obj->ttm.created = true;
 
diff --git a/drivers/gpu/drm/i915/intel_memory_region.h 
b/drivers/gpu/drm/i915/intel_memory_region.h
index b04fb22726d9..2be8433d373a 100644
--- a/drivers/gpu/drm/i915/intel_memory_region.h
+++ b/drivers/gpu/drm/i915/intel_memory_region.h
@@ -40,8 +40,7 @@ enum intel_region_id {
 #define REGION_STOLEN_SMEM   BIT(INTEL_REGION_STOLEN_SMEM)
 #define REGION_STOLEN_LMEM   BIT(INTEL_REGION_STOLEN_LMEM)
 
-#define I915_ALLOC_MIN_PAGE_SIZE  BIT(0)
-#define I915_ALLOC_CONTIGUOUS BIT(1)
+#define I915_ALLOC_CONTIGUOUS BIT(0)
 
 #define for_each_memory_region(mr, i915, id) \
for (id = 0; id < ARRAY_SIZE((i915)->mm.regions); id++) \
diff --git a/drivers/gpu/drm/i915/intel_region_ttm.c 
b/drivers/gpu/drm/i915/intel_region_ttm.c
index 23af995f7b67..59fa78225852 100644
--- a/drivers/gpu/drm/i915/intel_region_ttm.c
+++ b/drivers/gpu/drm/i915/intel_region_ttm.c
@@ -153,7 +153,7 @@ intel_region_ttm_node_alloc(struct intel_memory_region *mem,
int ret;
 
mock_bo.base.size = size;
-   mock_bo.page_alignment = PAGE_SIZE;
+   mock_bo.page_alignment = mem->min_page_size;
place.flags = flags;
 
ret = man->func->alloc(man, _bo, , );
diff --git a/drivers/gpu/drm/i915/selftests/mock_region.c 
b/drivers/gpu/drm/i915/selftests/mock_region.c
index d3e4e6573cb9..6ce0f9dacad7 100644
--- a/drivers/gpu/drm/i915/selftests/mock_region.c
+++ b/drivers/gpu/drm/i915/selftests/mock_region.c
@@ -28,7 +28,7 @@ static int mock_region_get_pages(struct drm_i915_gem_object 
*obj)
struct sg_table *pages;
int err;
 
-   flags = I915_ALLOC_MIN_PAGE_SIZE;
+   flags = 0;
if (obj->flags & I915_BO_ALLOC_CONTIGUOUS)
flags |= TTM_PL_FLAG_CONTIGUOUS;
 
-- 
2.26.3

[PATCH 5/6] drm/i915/ttm: switch over to ttm_buddy_man

[Matthew Auld]

Move back to the buddy allocator for managing device local memory, and
restore the lost mock selftests. Keep around the range manager related
bits, since we likely need this for managing stolen at some point. For
stolen we also don't need to reserve anything so no need to support a
generic reserve interface.

Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
---
 drivers/gpu/drm/i915/gem/i915_gem_ttm.c   |  26 +--
 drivers/gpu/drm/i915/intel_memory_region.c|  55 +-
 drivers/gpu/drm/i915/intel_memory_region.h|  17 --
 drivers/gpu/drm/i915/intel_region_ttm.c   | 100 +++
 .../drm/i915/selftests/intel_memory_region.c  | 170 --
 drivers/gpu/drm/i915/selftests/mock_region.c  |  15 +-
 6 files changed, 168 insertions(+), 215 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c 
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 0b0fce445e9b..3f5624f36afc 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -185,11 +185,7 @@ static bool i915_ttm_eviction_valuable(struct 
ttm_buffer_object *bo,
struct drm_i915_gem_object *obj = i915_ttm_to_gem(bo);
 
/* Will do for now. Our pinned objects are still on TTM's LRU lists */
-   if (!i915_gem_object_evictable(obj))
-   return false;
-
-   /* This isn't valid with a buddy allocator */
-   return ttm_bo_eviction_valuable(bo, place);
+   return i915_gem_object_evictable(obj);
 }
 
 static void i915_ttm_evict_flags(struct ttm_buffer_object *bo,
@@ -332,11 +328,15 @@ i915_ttm_resource_get_st(struct drm_i915_gem_object *obj,
struct ttm_buffer_object *bo = i915_gem_to_ttm(obj);
struct ttm_resource_manager *man =
ttm_manager_type(bo->bdev, res->mem_type);
+   struct intel_memory_region *mr = obj->mm.region;
 
if (man->use_tt)
return i915_ttm_tt_get_st(bo->ttm);
 
-   return intel_region_ttm_node_to_st(obj->mm.region, res->mm_node);
+   if (mr->is_range_manager)
+   return intel_region_ttm_node_to_st(mr, res);
+   else
+   return i915_sg_from_buddy_resource(res, mr->region.start);
 }
 
 static int i915_ttm_move(struct ttm_buffer_object *bo, bool evict,
@@ -661,20 +661,8 @@ int __i915_gem_ttm_object_init(struct intel_memory_region 
*mem,
static struct lock_class_key lock_class;
struct drm_i915_private *i915 = mem->i915;
enum ttm_bo_type bo_type;
-   size_t alignment = 0;
int ret;
 
-   /* Adjust alignment to GPU- and CPU huge page sizes. */
-
-   if (mem->is_range_manager) {
-   if (size >= SZ_1G)
-   alignment = SZ_1G >> PAGE_SHIFT;
-   else if (size >= SZ_2M)
-   alignment = SZ_2M >> PAGE_SHIFT;
-   else if (size >= SZ_64K)
-   alignment = SZ_64K >> PAGE_SHIFT;
-   }
-
drm_gem_private_object_init(>drm, >base, size);
i915_gem_object_init(obj, _gem_ttm_obj_ops, _class, flags);
i915_gem_object_init_memory_region(obj, mem);
@@ -696,7 +684,7 @@ int __i915_gem_ttm_object_init(struct intel_memory_region 
*mem,
 */
obj->base.vma_node.driver_private = i915_gem_to_ttm(obj);
ret = ttm_bo_init(>bdev, i915_gem_to_ttm(obj), size,
- bo_type, _sys_placement, alignment,
+ bo_type, _sys_placement, PAGE_SIZE,
  true, NULL, NULL, i915_ttm_bo_destroy);
 
if (!ret)
diff --git a/drivers/gpu/drm/i915/intel_memory_region.c 
b/drivers/gpu/drm/i915/intel_memory_region.c
index 12fb5423fd5e..df59f884d37c 100644
--- a/drivers/gpu/drm/i915/intel_memory_region.c
+++ b/drivers/gpu/drm/i915/intel_memory_region.c
@@ -5,6 +5,7 @@
 
 #include "intel_memory_region.h"
 #include "i915_drv.h"
+#include "i915_ttm_buddy_manager.h"
 
 static const struct {
u16 class;
@@ -28,11 +29,6 @@ static const struct {
},
 };
 
-struct intel_region_reserve {
-   struct list_head link;
-   struct ttm_resource *res;
-};
-
 struct intel_memory_region *
 intel_memory_region_lookup(struct drm_i915_private *i915,
   u16 class, u16 instance)
@@ -63,27 +59,6 @@ intel_memory_region_by_type(struct drm_i915_private *i915,
return NULL;
 }
 
-/**
- * intel_memory_region_unreserve - Unreserve all previously reserved
- * ranges
- * @mem: The region containing the reserved ranges.
- */
-void intel_memory_region_unreserve(struct intel_memory_region *mem)
-{
-   struct intel_region_reserve *reserve, *next;
-
-   if (!mem->priv_ops || !mem->priv_ops->free)
-   return;
-
-   mutex_lock(>mm_lock);
-   list_for_each_entry_safe(reserve, next, >reserved, link) {
-   list_del(>link);
-   mem->priv_ops->free(mem, reserve->res);
-   kfree(reserve);
-   }
-   mutex_unlock(>mm_lock);
-}
-
 /**
  * intel_memory_region_reserve - 

[PATCH 4/6] drm/i915/ttm: pass along the I915_BO_ALLOC_CONTIGUOUS

[Matthew Auld]

Currently we just ignore the I915_BO_ALLOC_CONTIGUOUS flag, which is
fine since everything is already contiguous with the ttm range manager.
However in the next patch we want to switch over to the ttm buddy
manager, where allocations are by default not contiguous.

Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
---
 drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c 
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 73d52df8f2be..0b0fce445e9b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -86,10 +86,18 @@ i915_ttm_select_tt_caching(const struct drm_i915_gem_object 
*obj)
 
 static void
 i915_ttm_place_from_region(const struct intel_memory_region *mr,
-  struct ttm_place *place)
+  struct ttm_place *place,
+  unsigned int flags)
 {
memset(place, 0, sizeof(*place));
place->mem_type = intel_region_to_ttm_type(mr);
+
+   switch(mr->type) {
+   case INTEL_MEMORY_LOCAL:
+   if (flags & I915_BO_ALLOC_CONTIGUOUS)
+   place->flags = TTM_PL_FLAG_CONTIGUOUS;
+   break;
+   }
 }
 
 static void
@@ -100,15 +108,16 @@ i915_ttm_placement_from_obj(const struct 
drm_i915_gem_object *obj,
 {
unsigned int i;
unsigned int num_allowed = obj->mm.n_placements;
+   unsigned int flags = obj->flags;
 
placement->num_placement = 1;
i915_ttm_place_from_region(num_allowed ? obj->mm.placements[0] :
-  obj->mm.region, requested);
+  obj->mm.region, requested, flags);
 
/* Cache this on object? */
placement->num_busy_placement = num_allowed;
for (i = 0; i < placement->num_busy_placement; ++i)
-   i915_ttm_place_from_region(obj->mm.placements[i], busy + i);
+   i915_ttm_place_from_region(obj->mm.placements[i], busy + i, 
flags);
 
if (num_allowed == 0) {
*busy = *requested;
-- 
2.26.3

[PATCH 3/6] drm/i915/ttm: Calculate the object placement at get_pages time

[Matthew Auld]

From: Thomas Hellström 

Instead of relying on a static placement, calculate at get_pages() time.
This should work for LMEM regions and system for now. For stolen we need
to take preallocated range into account. That well be added later.

Signed-off-by: Thomas Hellström 
---
 drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 69 +
 drivers/gpu/drm/i915/intel_region_ttm.c |  8 ++-
 drivers/gpu/drm/i915/intel_region_ttm.h |  2 +
 3 files changed, 68 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c 
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 9dd6e4f69d53..73d52df8f2be 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -24,6 +24,11 @@
 #define I915_TTM_PRIO_NO_PAGES  1
 #define I915_TTM_PRIO_HAS_PAGES 2
 
+/*
+ * Size of struct ttm_place vector in on-stack struct ttm_placement allocs
+ */
+#define I915_TTM_MAX_PLACEMENTS 10
+
 /**
  * struct i915_ttm_tt - TTM page vector with additional private information
  * @ttm: The base TTM page vector.
@@ -56,13 +61,6 @@ static const struct ttm_place lmem0_sys_placement_flags[] = {
}
 };
 
-static struct ttm_placement i915_lmem0_placement = {
-   .num_placement = 1,
-   .placement = _sys_placement_flags[0],
-   .num_busy_placement = 1,
-   .busy_placement = _sys_placement_flags[0],
-};
-
 static struct ttm_placement i915_sys_placement = {
.num_placement = 1,
.placement = _sys_placement_flags[1],
@@ -72,6 +70,55 @@ static struct ttm_placement i915_sys_placement = {
 
 static void i915_ttm_adjust_lru(struct drm_i915_gem_object *obj);
 
+static enum ttm_caching
+i915_ttm_select_tt_caching(const struct drm_i915_gem_object *obj)
+{
+   /*
+* Objects only allowed in system get cached cpu-mappings.
+* Other objects get WC mapping for now. Even if in system.
+*/
+   if (obj->mm.region->type == INTEL_MEMORY_SYSTEM &&
+   obj->mm.n_placements <= 1)
+   return ttm_cached;
+
+   return ttm_write_combined;
+}
+
+static void
+i915_ttm_place_from_region(const struct intel_memory_region *mr,
+  struct ttm_place *place)
+{
+   memset(place, 0, sizeof(*place));
+   place->mem_type = intel_region_to_ttm_type(mr);
+}
+
+static void
+i915_ttm_placement_from_obj(const struct drm_i915_gem_object *obj,
+   struct ttm_place *requested,
+   struct ttm_place *busy,
+   struct ttm_placement *placement)
+{
+   unsigned int i;
+   unsigned int num_allowed = obj->mm.n_placements;
+
+   placement->num_placement = 1;
+   i915_ttm_place_from_region(num_allowed ? obj->mm.placements[0] :
+  obj->mm.region, requested);
+
+   /* Cache this on object? */
+   placement->num_busy_placement = num_allowed;
+   for (i = 0; i < placement->num_busy_placement; ++i)
+   i915_ttm_place_from_region(obj->mm.placements[i], busy + i);
+
+   if (num_allowed == 0) {
+   *busy = *requested;
+   placement->num_busy_placement = 1;
+   }
+
+   placement->placement = requested;
+   placement->busy_placement = busy;
+}
+
 static struct ttm_tt *i915_ttm_tt_create(struct ttm_buffer_object *bo,
 uint32_t page_flags)
 {
@@ -89,7 +136,8 @@ static struct ttm_tt *i915_ttm_tt_create(struct 
ttm_buffer_object *bo,
man->use_tt)
page_flags |= TTM_PAGE_FLAG_ZERO_ALLOC;
 
-   ret = ttm_tt_init(_tt->ttm, bo, page_flags, ttm_write_combined);
+   ret = ttm_tt_init(_tt->ttm, bo, page_flags,
+ i915_ttm_select_tt_caching(obj));
if (ret) {
kfree(i915_tt);
return NULL;
@@ -414,10 +462,13 @@ static int i915_ttm_get_pages(struct drm_i915_gem_object 
*obj)
.no_wait_gpu = false,
};
struct sg_table *st;
+   struct ttm_place requested, busy[I915_TTM_MAX_PLACEMENTS];
+   struct ttm_placement placement;
int ret;
 
/* Move to the requested placement. */
-   ret = ttm_bo_validate(bo, _lmem0_placement, );
+   i915_ttm_placement_from_obj(obj, , busy, );
+   ret = ttm_bo_validate(bo, , );
if (ret)
return ret == -ENOSPC ? -ENXIO : ret;
 
diff --git a/drivers/gpu/drm/i915/intel_region_ttm.c 
b/drivers/gpu/drm/i915/intel_region_ttm.c
index 27fe0668d094..5a664f6cc93f 100644
--- a/drivers/gpu/drm/i915/intel_region_ttm.c
+++ b/drivers/gpu/drm/i915/intel_region_ttm.c
@@ -50,12 +50,16 @@ void intel_region_ttm_device_fini(struct drm_i915_private 
*dev_priv)
  * driver-private types for now, reserving TTM_PL_VRAM for stolen
  * memory and TTM_PL_TT for GGTT use if decided to implement this.
  */
-static int intel_region_to_ttm_type(struct intel_memory_region *mem)
+int intel_region_to_ttm_type(const struct intel_memory_region *mem)
 {

[PATCH 1/6] drm/i915/ttm: add ttm_buddy_man

[Matthew Auld]

Add back our standalone i915_buddy allocator and integrate it into a
ttm_resource_manager. This will plug into our ttm backend for managing
device local-memory in the next couple of patches.

Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
---
 drivers/gpu/drm/i915/Makefile |   2 +
 drivers/gpu/drm/i915/i915_buddy.c | 412 +
 drivers/gpu/drm/i915/i915_buddy.h | 133 +++
 drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 246 ++
 drivers/gpu/drm/i915/i915_ttm_buddy_manager.h |  56 ++
 drivers/gpu/drm/i915/selftests/i915_buddy.c   | 789 ++
 6 files changed, 1638 insertions(+)
 create mode 100644 drivers/gpu/drm/i915/i915_buddy.c
 create mode 100644 drivers/gpu/drm/i915/i915_buddy.h
 create mode 100644 drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
 create mode 100644 drivers/gpu/drm/i915/i915_ttm_buddy_manager.h
 create mode 100644 drivers/gpu/drm/i915/selftests/i915_buddy.c

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index f57dfc74d6ce..6c84e96ab26a 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -162,6 +162,7 @@ gem-y += \
 i915-y += \
  $(gem-y) \
  i915_active.o \
+ i915_buddy.o \
  i915_cmd_parser.o \
  i915_gem_evict.o \
  i915_gem_gtt.o \
@@ -171,6 +172,7 @@ i915-y += \
  i915_request.o \
  i915_scheduler.o \
  i915_trace_points.o \
+ i915_ttm_buddy_manager.o \
  i915_vma.o \
  intel_wopcm.o
 
diff --git a/drivers/gpu/drm/i915/i915_buddy.c 
b/drivers/gpu/drm/i915/i915_buddy.c
new file mode 100644
index ..29dd7d0310c1
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_buddy.c
@@ -0,0 +1,412 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2021 Intel Corporation
+ */
+
+#include 
+
+#include "i915_buddy.h"
+
+#include "i915_gem.h"
+#include "i915_utils.h"
+
+static struct i915_buddy_block *i915_block_alloc(struct i915_buddy_mm *mm,
+struct i915_buddy_block 
*parent,
+unsigned int order,
+u64 offset)
+{
+   struct i915_buddy_block *block;
+
+   GEM_BUG_ON(order > I915_BUDDY_MAX_ORDER);
+
+   block = kmem_cache_zalloc(mm->slab_blocks, GFP_KERNEL);
+   if (!block)
+   return NULL;
+
+   block->header = offset;
+   block->header |= order;
+   block->parent = parent;
+
+   GEM_BUG_ON(block->header & I915_BUDDY_HEADER_UNUSED);
+   return block;
+}
+
+static void i915_block_free(struct i915_buddy_mm *mm,
+   struct i915_buddy_block *block)
+{
+   kmem_cache_free(mm->slab_blocks, block);
+}
+
+static void mark_allocated(struct i915_buddy_block *block)
+{
+   block->header &= ~I915_BUDDY_HEADER_STATE;
+   block->header |= I915_BUDDY_ALLOCATED;
+
+   list_del(>link);
+}
+
+static void mark_free(struct i915_buddy_mm *mm,
+ struct i915_buddy_block *block)
+{
+   block->header &= ~I915_BUDDY_HEADER_STATE;
+   block->header |= I915_BUDDY_FREE;
+
+   list_add(>link,
+>free_list[i915_buddy_block_order(block)]);
+}
+
+static void mark_split(struct i915_buddy_block *block)
+{
+   block->header &= ~I915_BUDDY_HEADER_STATE;
+   block->header |= I915_BUDDY_SPLIT;
+
+   list_del(>link);
+}
+
+int i915_buddy_init(struct i915_buddy_mm *mm, u64 size, u64 chunk_size)
+{
+   unsigned int i;
+   u64 offset;
+
+   if (size < chunk_size)
+   return -EINVAL;
+
+   if (chunk_size < PAGE_SIZE)
+   return -EINVAL;
+
+   if (!is_power_of_2(chunk_size))
+   return -EINVAL;
+
+   size = round_down(size, chunk_size);
+
+   mm->size = size;
+   mm->chunk_size = chunk_size;
+   mm->max_order = ilog2(size) - ilog2(chunk_size);
+
+   GEM_BUG_ON(mm->max_order > I915_BUDDY_MAX_ORDER);
+
+   mm->slab_blocks = KMEM_CACHE(i915_buddy_block, SLAB_HWCACHE_ALIGN);
+   if (!mm->slab_blocks)
+   return -ENOMEM;
+
+   mm->free_list = kmalloc_array(mm->max_order + 1,
+ sizeof(struct list_head),
+ GFP_KERNEL);
+   if (!mm->free_list)
+   goto out_destroy_slab;
+
+   for (i = 0; i <= mm->max_order; ++i)
+   INIT_LIST_HEAD(>free_list[i]);
+
+   mm->n_roots = hweight64(size);
+
+   mm->roots = kmalloc_array(mm->n_roots,
+ sizeof(struct i915_buddy_block *),
+ GFP_KERNEL);
+   if (!mm->roots)
+   goto out_free_list;
+
+   offset = 0;
+   i = 0;
+
+   /*
+* Split into power-of-two blocks, in case we are given a size that is
+* not itself a power-of-two.
+*/
+   do {
+   struct i915_buddy_block *root;
+  

[PATCH 2/6] drm/i915/ttm: add i915_sg_from_buddy_resource

[Matthew Auld]

We need to be able to build an sg table from our list of buddy blocks,
so that we can later plug this into our ttm backend, and replace our use
of the range manager.

Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
---
 drivers/gpu/drm/i915/i915_scatterlist.c | 80 +
 drivers/gpu/drm/i915/i915_scatterlist.h |  5 ++
 2 files changed, 85 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_scatterlist.c 
b/drivers/gpu/drm/i915/i915_scatterlist.c
index 69e9e6c3135e..0959fe3efbbb 100644
--- a/drivers/gpu/drm/i915/i915_scatterlist.c
+++ b/drivers/gpu/drm/i915/i915_scatterlist.c
@@ -6,6 +6,9 @@
 
 #include "i915_scatterlist.h"
 
+#include "i915_buddy.h"
+#include "i915_ttm_buddy_manager.h"
+
 #include 
 
 #include 
@@ -104,6 +107,83 @@ struct sg_table *i915_sg_from_mm_node(const struct 
drm_mm_node *node,
return st;
 }
 
+/**
+ * i915_sg_from_buddy_resource - Create an sg_table from a struct
+ * i915_buddy_block list
+ * @res: The i915_ttm_buddy_resource.
+ * @region_start: An offset to add to the dma addresses of the sg list.
+ *
+ * Create a struct sg_table, initializing it from struct i915_buddy_block list,
+ * taking a maximum segment length into account, splitting into segments
+ * if necessary.
+ *
+ * Return: A pointer to a kmalloced struct sg_table on success, negative
+ * error code cast to an error pointer on failure.
+ */
+struct sg_table *i915_sg_from_buddy_resource(struct ttm_resource *res,
+u64 region_start)
+{
+   struct i915_ttm_buddy_resource *bman_res = to_ttm_buddy_resource(res);
+   struct i915_buddy_mm *mm = bman_res->mm;
+   const u64 size = res->num_pages << PAGE_SHIFT;
+   const u64 max_segment = UINT_MAX;
+   struct list_head *blocks = _res->blocks;
+   struct i915_buddy_block *block;
+   struct scatterlist *sg;
+   struct sg_table *st;
+   resource_size_t prev_end;
+
+   GEM_BUG_ON(list_empty(blocks));
+
+   st = kmalloc(sizeof(*st), GFP_KERNEL);
+   if (!st)
+   return ERR_PTR(-ENOMEM);
+
+   if (sg_alloc_table(st, size >> PAGE_SHIFT, GFP_KERNEL)) {
+   kfree(st);
+   return ERR_PTR(-ENOMEM);
+   }
+
+   sg = st->sgl;
+   st->nents = 0;
+   prev_end = (resource_size_t)-1;
+
+   list_for_each_entry(block, blocks, link) {
+   u64 block_size, offset;
+
+   block_size = min_t(u64, size, i915_buddy_block_size(mm, block));
+   offset = i915_buddy_block_offset(block);
+
+   while (block_size) {
+   u64 len;
+
+   if (offset != prev_end || sg->length >= max_segment) {
+   if (st->nents)
+   sg = __sg_next(sg);
+
+   sg_dma_address(sg) = region_start + offset;
+   sg_dma_len(sg) = 0;
+   sg->length = 0;
+   st->nents++;
+   }
+
+   len = min(block_size, max_segment - sg->length);
+   sg->length += len;
+   sg_dma_len(sg) += len;
+
+   offset += len;
+   block_size -= len;
+
+   prev_end = offset;
+   }
+   }
+
+   sg_mark_end(sg);
+   i915_sg_trim(st);
+
+   return st;
+}
+
 #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
 #include "selftests/scatterlist.c"
 #endif
diff --git a/drivers/gpu/drm/i915/i915_scatterlist.h 
b/drivers/gpu/drm/i915/i915_scatterlist.h
index 5acca45ea981..b8bd5925b03f 100644
--- a/drivers/gpu/drm/i915/i915_scatterlist.h
+++ b/drivers/gpu/drm/i915/i915_scatterlist.h
@@ -14,6 +14,7 @@
 #include "i915_gem.h"
 
 struct drm_mm_node;
+struct ttm_resource;
 
 /*
  * Optimised SGL iterator for GEM objects
@@ -145,4 +146,8 @@ bool i915_sg_trim(struct sg_table *orig_st);
 
 struct sg_table *i915_sg_from_mm_node(const struct drm_mm_node *node,
  u64 region_start);
+
+struct sg_table *i915_sg_from_buddy_resource(struct ttm_resource *res,
+u64 region_start);
+
 #endif
-- 
2.26.3

[PATCH 0/6] Add back the buddy allocator

[Matthew Auld]

Needs to be applied on top of:
https://patchwork.freedesktop.org/series/90681/

Matthew Auld (5):
  drm/i915/ttm: add ttm_buddy_man
  drm/i915/ttm: add i915_sg_from_buddy_resource
  drm/i915/ttm: pass along the I915_BO_ALLOC_CONTIGUOUS
  drm/i915/ttm: switch over to ttm_buddy_man
  drm/i915/ttm: restore min_page_size behaviour

Thomas Hellström (1):
  drm/i915/ttm: Calculate the object placement at get_pages time

 drivers/gpu/drm/i915/Makefile |   2 +
 drivers/gpu/drm/i915/gem/i915_gem_ttm.c   | 105 ++-
 drivers/gpu/drm/i915/i915_buddy.c | 412 +
 drivers/gpu/drm/i915/i915_buddy.h | 133 +++
 drivers/gpu/drm/i915/i915_scatterlist.c   |  80 ++
 drivers/gpu/drm/i915/i915_scatterlist.h   |   5 +
 drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 246 ++
 drivers/gpu/drm/i915/i915_ttm_buddy_manager.h |  56 ++
 drivers/gpu/drm/i915/intel_memory_region.c|  55 +-
 drivers/gpu/drm/i915/intel_memory_region.h|  20 +-
 drivers/gpu/drm/i915/intel_region_ttm.c   | 108 +--
 drivers/gpu/drm/i915/intel_region_ttm.h   |   2 +
 drivers/gpu/drm/i915/selftests/i915_buddy.c   | 789 ++
 .../drm/i915/selftests/intel_memory_region.c  | 170 ++--
 drivers/gpu/drm/i915/selftests/mock_region.c  |  17 +-
 15 files changed, 1970 insertions(+), 230 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/i915_buddy.c
 create mode 100644 drivers/gpu/drm/i915/i915_buddy.h
 create mode 100644 drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
 create mode 100644 drivers/gpu/drm/i915/i915_ttm_buddy_manager.h
 create mode 100644 drivers/gpu/drm/i915/selftests/i915_buddy.c

-- 
2.26.3

[PATCH] Fix i.MX IPU-v3 offset calculations for (semi)planar U/V formats

[Krzysztof Hałasa]

Video captured in 1400x1050 resolution (bytesperline aka stride = 1408
bytes) is invalid. Fix it.

Signed-off-by: Krzysztof Halasa 

--- a/drivers/gpu/ipu-v3/ipu-cpmem.c
+++ b/drivers/gpu/ipu-v3/ipu-cpmem.c
@@ -585,21 +585,21 @@ static const struct ipu_rgb def_bgra_16 = {
.bits_per_pixel = 16,
 };
 
-#define Y_OFFSET(pix, x, y)((x) + pix->width * (y))
-#define U_OFFSET(pix, x, y)((pix->width * pix->height) +   \
-(pix->width * ((y) / 2) / 2) + (x) / 2)
-#define V_OFFSET(pix, x, y)((pix->width * pix->height) +   \
-(pix->width * pix->height / 4) +   \
-(pix->width * ((y) / 2) / 2) + (x) / 2)
-#define U2_OFFSET(pix, x, y)   ((pix->width * pix->height) +   \
-(pix->width * (y) / 2) + (x) / 2)
-#define V2_OFFSET(pix, x, y)   ((pix->width * pix->height) +   \
-(pix->width * pix->height / 2) +   \
-(pix->width * (y) / 2) + (x) / 2)
-#define UV_OFFSET(pix, x, y)   ((pix->width * pix->height) +   \
-(pix->width * ((y) / 2)) + (x))
-#define UV2_OFFSET(pix, x, y)  ((pix->width * pix->height) +   \
-(pix->width * y) + (x))
+#define Y_OFFSET(pix, x, y)((x) + pix->bytesperline * (y))
+#define U_OFFSET(pix, x, y)((pix->bytesperline * pix->height) + \
+(pix->bytesperline * ((y) / 2) / 2) + (x) / 2)
+#define V_OFFSET(pix, x, y)((pix->bytesperline * pix->height) + \
+(pix->bytesperline * pix->height / 4) + \
+(pix->bytesperline * ((y) / 2) / 2) + (x) / 2)
+#define U2_OFFSET(pix, x, y)   ((pix->bytesperline * pix->height) + \
+(pix->bytesperline * (y) / 2) + (x) / 2)
+#define V2_OFFSET(pix, x, y)   ((pix->bytesperline * pix->height) + \
+(pix->bytesperline * pix->height / 2) + \
+(pix->bytesperline * (y) / 2) + (x) / 2)
+#define UV_OFFSET(pix, x, y)   ((pix->bytesperline * pix->height) + \
+(pix->bytesperline * ((y) / 2)) + (x))
+#define UV2_OFFSET(pix, x, y)  ((pix->bytesperline * pix->height) + \
+(pix->bytesperline * y) + (x))
 
 #define NUM_ALPHA_CHANNELS 7
 

-- 
Krzysztof Hałasa

Sieć Badawcza Łukasiewicz
Przemysłowy Instytut Automatyki i Pomiarów PIAP
Al. Jerozolimskie 202, 02-486 Warszawa

Re: [PATCH 12/13] drm/i915/guc: Unified GuC log

[Matthew Brost]

On Mon, Jun 07, 2021 at 11:03:54AM -0700, Matthew Brost wrote:
> From: John Harrison 
> 
> GuC v57 unified the 'DPC' and 'ISR' buffers into a single buffer with
> the option for it to be larger.
> 
> Signed-off-by: Matthew Brost 

Reviewed-by: Matthew Brost 

> Signed-off-by: John Harrison 
> Cc: Alan Previn 
> ---
>  drivers/gpu/drm/i915/gt/uc/intel_guc.c  | 15 ---
>  drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h |  9 +++
>  drivers/gpu/drm/i915/gt/uc/intel_guc_log.c  | 29 +++--
>  drivers/gpu/drm/i915/gt/uc/intel_guc_log.h  |  6 ++---
>  4 files changed, 20 insertions(+), 39 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c 
> b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> index b773567cb080..6661dcb02239 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> @@ -219,24 +219,19 @@ static u32 guc_ctl_log_params_flags(struct intel_guc 
> *guc)
>  
>   BUILD_BUG_ON(!CRASH_BUFFER_SIZE);
>   BUILD_BUG_ON(!IS_ALIGNED(CRASH_BUFFER_SIZE, UNIT));
> - BUILD_BUG_ON(!DPC_BUFFER_SIZE);
> - BUILD_BUG_ON(!IS_ALIGNED(DPC_BUFFER_SIZE, UNIT));
> - BUILD_BUG_ON(!ISR_BUFFER_SIZE);
> - BUILD_BUG_ON(!IS_ALIGNED(ISR_BUFFER_SIZE, UNIT));
> + BUILD_BUG_ON(!DEBUG_BUFFER_SIZE);
> + BUILD_BUG_ON(!IS_ALIGNED(DEBUG_BUFFER_SIZE, UNIT));
>  
>   BUILD_BUG_ON((CRASH_BUFFER_SIZE / UNIT - 1) >
>   (GUC_LOG_CRASH_MASK >> GUC_LOG_CRASH_SHIFT));
> - BUILD_BUG_ON((DPC_BUFFER_SIZE / UNIT - 1) >
> - (GUC_LOG_DPC_MASK >> GUC_LOG_DPC_SHIFT));
> - BUILD_BUG_ON((ISR_BUFFER_SIZE / UNIT - 1) >
> - (GUC_LOG_ISR_MASK >> GUC_LOG_ISR_SHIFT));
> + BUILD_BUG_ON((DEBUG_BUFFER_SIZE / UNIT - 1) >
> + (GUC_LOG_DEBUG_MASK >> GUC_LOG_DEBUG_SHIFT));
>  
>   flags = GUC_LOG_VALID |
>   GUC_LOG_NOTIFY_ON_HALF_FULL |
>   FLAG |
>   ((CRASH_BUFFER_SIZE / UNIT - 1) << GUC_LOG_CRASH_SHIFT) |
> - ((DPC_BUFFER_SIZE / UNIT - 1) << GUC_LOG_DPC_SHIFT) |
> - ((ISR_BUFFER_SIZE / UNIT - 1) << GUC_LOG_ISR_SHIFT) |
> + ((DEBUG_BUFFER_SIZE / UNIT - 1) << GUC_LOG_DEBUG_SHIFT) |
>   (offset << GUC_LOG_BUF_ADDR_SHIFT);
>  
>   #undef UNIT
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h 
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
> index f2df5c11c11d..617ec601648d 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
> @@ -81,10 +81,8 @@
>  #define   GUC_LOG_ALLOC_IN_MEGABYTE  (1 << 3)
>  #define   GUC_LOG_CRASH_SHIFT4
>  #define   GUC_LOG_CRASH_MASK (0x3 << GUC_LOG_CRASH_SHIFT)
> -#define   GUC_LOG_DPC_SHIFT  6
> -#define   GUC_LOG_DPC_MASK   (0x7 << GUC_LOG_DPC_SHIFT)
> -#define   GUC_LOG_ISR_SHIFT  9
> -#define   GUC_LOG_ISR_MASK   (0x7 << GUC_LOG_ISR_SHIFT)
> +#define   GUC_LOG_DEBUG_SHIFT6
> +#define   GUC_LOG_DEBUG_MASK (0xF << GUC_LOG_DEBUG_SHIFT)
>  #define   GUC_LOG_BUF_ADDR_SHIFT 12
>  
>  #define GUC_CTL_WA   1
> @@ -311,8 +309,7 @@ struct guc_ads {
>  /* GuC logging structures */
>  
>  enum guc_log_buffer_type {
> - GUC_ISR_LOG_BUFFER,
> - GUC_DPC_LOG_BUFFER,
> + GUC_DEBUG_LOG_BUFFER,
>   GUC_CRASH_DUMP_LOG_BUFFER,
>   GUC_MAX_LOG_BUFFER
>  };
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c 
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
> index c36d5eb5bbb9..ac0931f0374b 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
> @@ -197,10 +197,8 @@ static bool guc_check_log_buf_overflow(struct 
> intel_guc_log *log,
>  static unsigned int guc_get_log_buffer_size(enum guc_log_buffer_type type)
>  {
>   switch (type) {
> - case GUC_ISR_LOG_BUFFER:
> - return ISR_BUFFER_SIZE;
> - case GUC_DPC_LOG_BUFFER:
> - return DPC_BUFFER_SIZE;
> + case GUC_DEBUG_LOG_BUFFER:
> + return DEBUG_BUFFER_SIZE;
>   case GUC_CRASH_DUMP_LOG_BUFFER:
>   return CRASH_BUFFER_SIZE;
>   default:
> @@ -245,7 +243,7 @@ static void guc_read_update_log_buffer(struct 
> intel_guc_log *log)
>   src_data += PAGE_SIZE;
>   dst_data += PAGE_SIZE;
>  
> - for (type = GUC_ISR_LOG_BUFFER; type < GUC_MAX_LOG_BUFFER; type++) {
> + for (type = GUC_DEBUG_LOG_BUFFER; type < GUC_MAX_LOG_BUFFER; type++) {
>   /*
>* Make a copy of the state structure, inside GuC log buffer
>* (which is uncached mapped), on the stack to avoid reading
> @@ -463,21 +461,16 @@ int intel_guc_log_create(struct intel_guc_log *log)
>*  +===+ 00B
>*  |Crash dump state header|
>*  +---+ 32B
> -  *  |   DPC state header|
> +  *  |  Debug state 

RE: [PATCH 0/9] Enhance pipe color support for multi segmented luts

[Shankar, Uma]

> -Original Message-
> From: dri-devel  On Behalf Of Pekka
> Paalanen
> Sent: Monday, June 7, 2021 1:00 PM
> To: Harry Wentland 
> Cc: intel-...@lists.freedesktop.org; Shankar, Uma ;
> Sebastian Wick ; dri-devel@lists.freedesktop.org;
> Modem, Bhanuprakash 
> Subject: Re: [PATCH 0/9] Enhance pipe color support for multi segmented luts
> 
> On Fri, 4 Jun 2021 14:51:25 -0400
> Harry Wentland  wrote:
> 
> > On 2021-06-01 6:41 a.m., Uma Shankar wrote:
> > > Modern hardwares have multi segmented lut approach to prioritize the
> > > darker regions of the spectrum. This series introduces a new UAPI to
> > > define the lut ranges supported by the respective hardware.
> > >
> > > This also enables Pipe Color Management Support for Intel's XE_LPD hw.
> > > Enable Support for Pipe Degamma with the increased lut samples
> > > supported by hardware. This also adds support for newly introduced
> > > Logarithmic Gamma for XE_LPD. Also added the gamma readout support.
> > >
> > > The Logarithmic gamma implementation on XE_LPD is non linear and
> > > adds 25 segments with non linear lut samples in each segment. The
> > > expectation is userspace will create the luts as per this
> > > distribution and pass the final samples to driver to be programmed in 
> > > hardware.
> > >
> >
> > Is this design targetting Intel XE_LPD HW in particular or is it
> > intended to be generic?
> >
> > If this is intended to be generic I think it would benefit from a lot
> > more documentation. At this point it's difficult for me to see how to
> > adapt this to AMD HW. It would take me a while to be comfortable to
> > make a call on whether we can use it or not. And what about other vendors?
> >
> > I think we need to be cautious in directly exposing HW functionality
> > through UAPI. The CM parts of AMD HW seem to be changing in some way
> > each generation and it looks like the same is true for Intel. The
> > trouble we have with adapting the old gamma/degamma properties to
> > modern HW is some indication to me that this approach is somewhat 
> > problematic.
> >
> > It would be useful to understand and document the specific use-cases
> > we want to provide to userspace implementers with this functionality.
> > Do we want to support modern transfer functions such as PQ or HLG? If
> > so, it might be beneficial to have an API to explicitly specify that,
> > and then use LUT tables in drivers that are optimized for the implementing 
> > HW.
> 
> Hi Harry,
> 
> from my very limited understanding so far, enum might be fine for PQ, but HLG 
> is not
> just one transfer function, although it may often be confused as one. PQ and 
> HLG
> are fundamentally different designs to HDR broadcasting I believe. It would be
> unfortunate to make a mistake here, engraving it into UAPI.

Yes Pekka, putting this in UAPI may limit us.

> > Or is the use case tone mapping? If so, would a parametric definition
> > of tone mapping be easier to manage?
> 
> A very good question at least I have no idea about.

Responded on earlier mail in thread. For non linear lut (gamma block), usecase 
is primarily tone
mapping but there are implementations where non linear blending is seeked 
(AFAIR Android does that),
so it leaves room for those usecases as well.

Regards,
Uma Shankar
> 
> Thanks,
> pq
> 
> > > +-+--+
> > > | x   |  2 pow x segment|No of Entries
> > > | |  0  | 1  |
> > > | 0   |  1  | 1  |
> > > | 1   |  2  | 2  |
> > > | 2   |  4  | 2  |
> > > | 3   |  8  | 2  |
> > > | 4   |  16 | 2  |
> > > | 5   |  32 | 4  |
> > > | 6   |  64 | 4  |
> > > | 7   |  128| 4  |
> > > | 8   |  256| 8  |
> > > | 9   |  512| 8  |
> > > | 10  |  1024   | 8  |
> > > | 11  |  2048   | 16 |
> > > | 12  |  4096   | 16 |
> > > | 13  |  8192   | 16 |
> > > | 14  |  16384  | 32 |
> > > | 15  |  32768  | 32 |
> > > | 16  |  65536  | 64 |
> > > | 17  |  131072 | 64 |
> > > | 18  |  262144 | 64 |
> > > | 19  |  524288 | 32 |
> > > | 20  |  1048576| 32 |
> > > | 21  |  2097152| 32 |
> > > | 22  |  4194304| 32 |
> > > | 23  |  8388608| 32 |
> > > | 24  |  16777216   | 1  |
> > > | | Total Entries   | 511|
> > >  -+-++
> > >
> > > Credits: Special mention and credits to Ville Syrjala for coming up
> > > with a design for this feature and inputs. This series is based on
> > > his original design.
> > >
> > > Note: Userspace support for this new UAPI will be done on Chrome and
> > > plan is to get this supported on mutter as well. We will notify the
> > > 

Re: [PATCH 10/13] drm/i915/guc: Kill guc_clients.ct_pool

[Matthew Brost]

On Mon, Jun 07, 2021 at 11:03:52AM -0700, Matthew Brost wrote:
> From: Michal Wajdeczko 
> 
> CTB pool is now maintained internally by the GuC as part of its
> "private data". No need to allocate separate buffer and pass it
> to GuC as yet another ADS.
> 
> Signed-off-by: Matthew Brost  #v4
> Signed-off-by: Michal Wajdeczko 
> Cc: Janusz Krzysztofik 

Reviewed-by: Matthew Brost 

> ---
>  drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c  | 12 
>  drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 12 +---
>  2 files changed, 1 insertion(+), 23 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c 
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> index 4fcbe4b921f9..6e26fe04ce92 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> @@ -26,8 +26,6 @@
>   *  +---+
>   *  | guc_clients_info  |
>   *  +---+
> - *  | guc_ct_pool_entry[size]   |
> - *  +---+
>   *  | padding   |
>   *  +---+ <== 4K aligned
>   *  | private data  |
> @@ -40,7 +38,6 @@ struct __guc_ads_blob {
>   struct guc_policies policies;
>   struct guc_gt_system_info system_info;
>   struct guc_clients_info clients_info;
> - struct guc_ct_pool_entry ct_pool[GUC_CT_POOL_SIZE];
>  } __packed;
>  
>  static u32 guc_ads_private_data_size(struct intel_guc *guc)
> @@ -68,11 +65,6 @@ static void guc_policies_init(struct guc_policies 
> *policies)
>   policies->is_valid = 1;
>  }
>  
> -static void guc_ct_pool_entries_init(struct guc_ct_pool_entry *pool, u32 num)
> -{
> - memset(pool, 0, num * sizeof(*pool));
> -}
> -
>  static void guc_mapping_table_init(struct intel_gt *gt,
>  struct guc_gt_system_info *system_info)
>  {
> @@ -161,11 +153,7 @@ static void __guc_ads_init(struct intel_guc *guc)
>   base = intel_guc_ggtt_offset(guc, guc->ads_vma);
>  
>   /* Clients info  */
> - guc_ct_pool_entries_init(blob->ct_pool, ARRAY_SIZE(blob->ct_pool));
> -
>   blob->clients_info.clients_num = 1;
> - blob->clients_info.ct_pool_addr = base + ptr_offset(blob, ct_pool);
> - blob->clients_info.ct_pool_count = ARRAY_SIZE(blob->ct_pool);
>  
>   /* ADS */
>   blob->ads.scheduler_policies = base + ptr_offset(blob, policies);
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h 
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
> index 251c3836bd2c..2266444d074f 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
> @@ -295,19 +295,9 @@ struct guc_gt_system_info {
>  } __packed;
>  
>  /* Clients info */
> -struct guc_ct_pool_entry {
> - struct guc_ct_buffer_desc desc;
> - u32 reserved[7];
> -} __packed;
> -
> -#define GUC_CT_POOL_SIZE 2
> -
>  struct guc_clients_info {
>   u32 clients_num;
> - u32 reserved0[13];
> - u32 ct_pool_addr;
> - u32 ct_pool_count;
> - u32 reserved[4];
> + u32 reserved[19];
>  } __packed;
>  
>  /* GuC Additional Data Struct */
> -- 
> 2.28.0
> 

Re: [PATCH] drm/ttm: fix warning after moving resource to ghost obj

[Intel]

On 6/7/21 7:57 PM, Christian König wrote:

After we moved the resource to the ghost the bo->resource pointer needs
to be resetted since the owner of the resource is now the ghost.

s/resetted/reset/

Signed-off-by: Christian König 


Reviewed-by: Thomas Hellström 

RE: [PATCH 0/9] Enhance pipe color support for multi segmented luts

[Shankar, Uma]

> -Original Message-
> From: Harry Wentland 
> Sent: Saturday, June 5, 2021 12:21 AM
> To: Shankar, Uma ; intel-...@lists.freedesktop.org; 
> dri-
> de...@lists.freedesktop.org
> Cc: Modem, Bhanuprakash ; Cyr, Aric
> 
> Subject: Re: [PATCH 0/9] Enhance pipe color support for multi segmented luts
> 
> On 2021-06-01 6:41 a.m., Uma Shankar wrote:
> > Modern hardwares have multi segmented lut approach to prioritize the
> > darker regions of the spectrum. This series introduces a new UAPI to
> > define the lut ranges supported by the respective hardware.
> >
> > This also enables Pipe Color Management Support for Intel's XE_LPD hw.
> > Enable Support for Pipe Degamma with the increased lut samples
> > supported by hardware. This also adds support for newly introduced
> > Logarithmic Gamma for XE_LPD. Also added the gamma readout support.
> >
> > The Logarithmic gamma implementation on XE_LPD is non linear and adds
> > 25 segments with non linear lut samples in each segment. The
> > expectation is userspace will create the luts as per this distribution
> > and pass the final samples to driver to be programmed in hardware.
> >
> 
> Is this design targetting Intel XE_LPD HW in particular or is it intended to 
> be generic?
> 
> If this is intended to be generic I think it would benefit from a lot more
> documentation. At this point it's difficult for me to see how to adapt this 
> to AMD
> HW. It would take me a while to be comfortable to make a call on whether we 
> can
> use it or not. And what about other vendors?

This is expected to be generic for all vendors.  XE_LPD is just a reference 
implementation.
It's basically an extension of what we have for crtc color but designing the 
UAPI to have it
more scalable for future hardware. The legacy hardware implementation which we 
have in
crtc properties can easily fit in this new UAPI and this can help represent 
hardware better
with more precision and scalability. Credits to Ville as to this is his idea of 
how we can represent
hardware generically and advertise to userspace.

Sure, I will add more documentation to make this clearer. 

> I think we need to be cautious in directly exposing HW functionality through 
> UAPI.
> The CM parts of AMD HW seem to be changing in some way each generation and it
> looks like the same is true for Intel. The trouble we have with adapting the 
> old
> gamma/degamma properties to modern HW is some indication to me that this
> approach is somewhat problematic.
> 

The advantage of having flexibility in userspace is that we give access of 
hardware to
userspace.It can then control things based on various usecases and not limited 
by just
a subset of operations what we define (in the lack of such an implementation).

> It would be useful to understand and document the specific use-cases we want 
> to
> provide to userspace implementers with this functionality. Do we want to 
> support
> modern transfer functions such as PQ or HLG? If so, it might be beneficial to 
> have an
> API to explicitly specify that, and then use LUT tables in drivers that are 
> optimized for
> the implementing HW. Or is the use case tone mapping? If so, would a 
> parametric
> definition of tone mapping be easier to manage?
> 

Yes right, ideally this is what intend to achieve here. We cant have fixed 
tables for operations
like Tone mapping as it will depend on mastering luminance values which can 
vary along with
other attributes of metadata. Eventually this operation would be done by the 
gamma block
(non linear luts), the values for which would be calculated and send by 
userspace. Thus making
all this very generic. Also we can't do any color math in driver as it has lot 
of floating operations.

So here the trade-off is between having a UAPI where userspace controls hw, 
computes and sends
values vs having just a fixed function operations with hard coded lut tables in 
driver.

Maybe we can have both the options in order to give flexibility to hardware 
vendors. We can
document the usage of the UAPI we create which can help things co-exist. 
Userspace can query
the supported properties and implement based on the properties exposed by the 
respective
vendor driver implementation. 

My personal preference would be to go with generic option (expose hardware to 
userspace) which
will make life easier for userspace developers. This will help use hardware for 
any color operation not
just limited to linearization, CSC conversions and tone mapping. Also this is 
already done for crtc, so it just
need to be extended to planes.

> > +-+--+
> > | x   |  2 pow x segment|No of Entries
> > | |  0  | 1  |
> > | 0   |  1  | 1  |
> > | 1   |  2  | 2  |
> > | 2   |  4  | 2  |
> > | 3   |  8  | 2  |
> > | 4   |  16 | 2  |
> > | 5   |  32 | 4  |
> > | 6   |  64 | 4  

Re: [PATCH 01/10] drm/ttm: allocate resource object instead of embedding it v2

[Christian König]

Am 07.06.21 um 19:58 schrieb Thomas Hellström (Intel):


On 6/7/21 7:54 PM, Christian König wrote:



Am 07.06.21 um 19:06 schrieb Thomas Hellström (Intel):


On 6/7/21 6:40 PM, Thomas Hellström (Intel) wrote:


On 6/2/21 12:09 PM, Christian König wrote:
...
@@ -728,14 +728,15 @@ static int ttm_bo_add_move_fence(struct 
ttm_buffer_object *bo,

   */
  static int ttm_bo_mem_force_space(struct ttm_buffer_object *bo,
    const struct ttm_place *place,
-  struct ttm_resource *mem,
+  struct ttm_resource **mem,
    struct ttm_operation_ctx *ctx)
  {
  struct ttm_device *bdev = bo->bdev;
-    struct ttm_resource_manager *man = ttm_manager_type(bdev, 
mem->mem_type);

+    struct ttm_resource_manager *man;
  struct ww_acquire_ctx *ticket;
  int ret;
  +    man = ttm_manager_type(bdev, (*mem)->mem_type);


Isn't (*mem) uninitialized here? Should be place->mem_type? 
Eviction is immediately sent to the bushes.


Got at least one additional NULL pointer deref to track down in the 
eviction code, but could be a merge error of mine as well.


Actually this last one was probably due to a bad temporary fix of 
the above one.


I've found one more warning during my testing now. But that is just a 
false positive.


Apart from that I haven't seen any other fallout, but fingers crossed.


vmwgfx doesn't seem to happy. It works AFAICT., but warns in 
vmw_move() about ttm_bo_assign_mem() replacing an existing resource.


Yeah, that's the one I've just fixed. Patch is underway.

Christian.



/Thomas





Christian.



/Thomas

Re: [PATCH 01/10] drm/ttm: allocate resource object instead of embedding it v2

[Intel]

On 6/7/21 7:54 PM, Christian König wrote:



Am 07.06.21 um 19:06 schrieb Thomas Hellström (Intel):


On 6/7/21 6:40 PM, Thomas Hellström (Intel) wrote:


On 6/2/21 12:09 PM, Christian König wrote:
...
@@ -728,14 +728,15 @@ static int ttm_bo_add_move_fence(struct 
ttm_buffer_object *bo,

   */
  static int ttm_bo_mem_force_space(struct ttm_buffer_object *bo,
    const struct ttm_place *place,
-  struct ttm_resource *mem,
+  struct ttm_resource **mem,
    struct ttm_operation_ctx *ctx)
  {
  struct ttm_device *bdev = bo->bdev;
-    struct ttm_resource_manager *man = ttm_manager_type(bdev, 
mem->mem_type);

+    struct ttm_resource_manager *man;
  struct ww_acquire_ctx *ticket;
  int ret;
  +    man = ttm_manager_type(bdev, (*mem)->mem_type);


Isn't (*mem) uninitialized here? Should be place->mem_type? Eviction 
is immediately sent to the bushes.


Got at least one additional NULL pointer deref to track down in the 
eviction code, but could be a merge error of mine as well.


Actually this last one was probably due to a bad temporary fix of the 
above one.


I've found one more warning during my testing now. But that is just a 
false positive.


Apart from that I haven't seen any other fallout, but fingers crossed.


vmwgfx doesn't seem to happy. It works AFAICT., but warns in vmw_move() 
about ttm_bo_assign_mem() replacing an existing resource.


/Thomas





Christian.



/Thomas

[PATCH] drm/ttm: fix warning after moving resource to ghost obj

[Christian König]

After we moved the resource to the ghost the bo->resource pointer needs
to be resetted since the owner of the resource is now the ghost.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/ttm/ttm_bo_util.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c 
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 1b326e70cb02..a2b97cd84d8f 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -603,6 +603,7 @@ static int ttm_bo_move_to_ghost(struct ttm_buffer_object 
*bo,
ghost_obj->ttm = NULL;
else
bo->ttm = NULL;
+   bo->resource = NULL;
 
dma_resv_unlock(_obj->base._resv);
ttm_bo_put(ghost_obj);
-- 
2.25.1

Re: [PATCH 01/10] drm/ttm: allocate resource object instead of embedding it v2

[Christian König]

Am 07.06.21 um 19:06 schrieb Thomas Hellström (Intel):


On 6/7/21 6:40 PM, Thomas Hellström (Intel) wrote:


On 6/2/21 12:09 PM, Christian König wrote:
...
@@ -728,14 +728,15 @@ static int ttm_bo_add_move_fence(struct 
ttm_buffer_object *bo,

   */
  static int ttm_bo_mem_force_space(struct ttm_buffer_object *bo,
    const struct ttm_place *place,
-  struct ttm_resource *mem,
+  struct ttm_resource **mem,
    struct ttm_operation_ctx *ctx)
  {
  struct ttm_device *bdev = bo->bdev;
-    struct ttm_resource_manager *man = ttm_manager_type(bdev, 
mem->mem_type);

+    struct ttm_resource_manager *man;
  struct ww_acquire_ctx *ticket;
  int ret;
  +    man = ttm_manager_type(bdev, (*mem)->mem_type);


Isn't (*mem) uninitialized here? Should be place->mem_type? Eviction 
is immediately sent to the bushes.


Got at least one additional NULL pointer deref to track down in the 
eviction code, but could be a merge error of mine as well.


Actually this last one was probably due to a bad temporary fix of the 
above one.


I've found one more warning during my testing now. But that is just a 
false positive.


Apart from that I haven't seen any other fallout, but fingers crossed.

Christian.



/Thomas

Re: [Intel-gfx] [PATCH 09/13] drm/i915/doc: Include GuC ABI documentation

[Matthew Brost]

On Mon, Jun 07, 2021 at 11:03:51AM -0700, Matthew Brost wrote:
> From: Michal Wajdeczko 
> 
> GuC ABI documentation is now ready to be included in i915.rst
> 
> Signed-off-by: Michal Wajdeczko 
> Signed-off-by: Matthew Brost 
> Cc: Piotr Piórkowski 

Michal - I noticed while putting this series together that there is
kernel doc in intel_guc_ct.* but this isn't inclued in i915.rst. Do you
think we should add the those here or in a new section (e.g. GuC CTBs)?

Let me know what you think and I can fix this up before this gets
merged.

With that, for this patch:

Reviewed-by: Matthew Brost 

> ---
>  Documentation/gpu/i915.rst | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
> index 42ce0196930a..c7846b1d9293 100644
> --- a/Documentation/gpu/i915.rst
> +++ b/Documentation/gpu/i915.rst
> @@ -518,6 +518,14 @@ GuC-based command submission
>  .. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> :doc: GuC-based command submission
>  
> +GuC ABI
> +
> +
> +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/abi/guc_messages_abi.h
> +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/abi/guc_communication_mmio_abi.h
> +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
> +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
> +
>  HuC
>  ---
>  .. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_huc.c
> -- 
> 2.28.0
> 
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH 08/13] drm/i915/guc: New CTB based communication

[Matthew Brost]

From: Michal Wajdeczko 

Format of the CTB messages has changed:
 - support for multiple formats
 - message fence is now part of the header
 - reuse of unified HXG message formats

Signed-off-by: Michal Wajdeczko 
Signed-off-by: Matthew Brost 
Cc: Piotr Piórkowski 
---
 .../gt/uc/abi/guc_communication_ctb_abi.h |  56 +
 drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 194 +++---
 drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h |   2 +-
 3 files changed, 135 insertions(+), 117 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h 
b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
index 127b256a662c..92660726c094 100644
--- a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
+++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
@@ -60,6 +60,62 @@ struct guc_ct_buffer_desc {
 } __packed;
 static_assert(sizeof(struct guc_ct_buffer_desc) == 64);
 
+/**
+ * DOC: CTB Message
+ *
+ *  
+---+---+--+
+ *  |   | Bits  | Description  
|
+ *  
+===+===+==+
+ *  | 0 | 31:16 | **FENCE** - message identifier   
|
+ *  |   
+---+--+
+ *  |   | 15:12 | **FORMAT** - format of the CTB message   
|
+ *  |   |   |  - _`GUC_CTB_FORMAT_HXG` = 0 - see `CTB HXG Message`_
|
+ *  |   
+---+--+
+ *  |   |  11:8 | **RESERVED** 
|
+ *  |   
+---+--+
+ *  |   |   7:0 | **NUM_DWORDS** - length of the CTB message (w/o header)  
|
+ *  
+---+---+--+
+ *  | 1 |  31:0 | optional (depends on FORMAT) 
|
+ *  +---+---+  
|
+ *  |...|   |  
|
+ *  +---+---+  
|
+ *  | n |  31:0 |  
|
+ *  
+---+---+--+
+ */
+
+#define GUC_CTB_MSG_MIN_LEN1u
+#define GUC_CTB_MSG_MAX_LEN256u
+#define GUC_CTB_MSG_0_FENCE(0x << 16)
+#define GUC_CTB_MSG_0_FORMAT   (0xf << 12)
+#define   GUC_CTB_FORMAT_HXG   0u
+#define GUC_CTB_MSG_0_RESERVED (0xf << 8)
+#define GUC_CTB_MSG_0_NUM_DWORDS   (0xff << 0)
+
+/**
+ * DOC: CTB HXG Message
+ *
+ *  
+---+---+--+
+ *  |   | Bits  | Description  
|
+ *  
+===+===+==+
+ *  | 0 | 31:16 | FENCE
|
+ *  |   
+---+--+
+ *  |   | 15:12 | FORMAT = GUC_CTB_FORMAT_HXG_ 
|
+ *  |   
+---+--+
+ *  |   |  11:8 | RESERVED = MBZ   
|
+ *  |   
+---+--+
+ *  |   |   7:0 | NUM_DWORDS = length (in dwords) of the embedded HXG message  
|
+ *  
+---+---+--+
+ *  | 1 |  31:0 |  ++  
|
+ *  +---+---+  ||  
|
+ *  |...|   |  |  Embedded `HXG Message`_   |  
|
+ *  +---+---+  ||  
|
+ *  | n |  31:0 |  ++  
|
+ *  
+---+---+--+
+ */
+
+#define GUC_CTB_HXG_MSG_MIN_LEN(GUC_CTB_MSG_MIN_LEN + 
GUC_HXG_MSG_MIN_LEN)
+#define GUC_CTB_HXG_MSG_MAX_LENGUC_CTB_MSG_MAX_LEN
+
 /**
  * DOC: CTB based communication
  *
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index 6a29be779cc9..729f29bc2a57 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -365,24 +365,6 @@ static void write_barrier(struct intel_guc_ct *ct)
}
 }
 
-/**
- * DOC: CTB Host to GuC request
- *
- * Format of the CTB Host to GuC request message is as follows::
- *
- *  

[PATCH 11/13] drm/i915/guc: Kill ads.client_info

[Matthew Brost]

From: Michal Wajdeczko 

New GuC does not require it any more.

Reviewed-by: Matthew Brost 
Signed-off-by: Michal Wajdeczko 
Cc: Piotr Piórkowski 
---
 drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c  | 7 ---
 drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 8 +---
 2 files changed, 1 insertion(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
index 6e26fe04ce92..b82145652d57 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
@@ -24,8 +24,6 @@
  *  +---+
  *  | guc_gt_system_info|
  *  +---+
- *  | guc_clients_info  |
- *  +---+
  *  | padding   |
  *  +---+ <== 4K aligned
  *  | private data  |
@@ -37,7 +35,6 @@ struct __guc_ads_blob {
struct guc_ads ads;
struct guc_policies policies;
struct guc_gt_system_info system_info;
-   struct guc_clients_info clients_info;
 } __packed;
 
 static u32 guc_ads_private_data_size(struct intel_guc *guc)
@@ -152,13 +149,9 @@ static void __guc_ads_init(struct intel_guc *guc)
 
base = intel_guc_ggtt_offset(guc, guc->ads_vma);
 
-   /* Clients info  */
-   blob->clients_info.clients_num = 1;
-
/* ADS */
blob->ads.scheduler_policies = base + ptr_offset(blob, policies);
blob->ads.gt_system_info = base + ptr_offset(blob, system_info);
-   blob->ads.clients_info = base + ptr_offset(blob, clients_info);
 
/* Private Data */
blob->ads.private_data = base + guc_ads_private_data_offset(guc);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
index 2266444d074f..f2df5c11c11d 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
@@ -294,19 +294,13 @@ struct guc_gt_system_info {
u32 generic_gt_sysinfo[GUC_GENERIC_GT_SYSINFO_MAX];
 } __packed;
 
-/* Clients info */
-struct guc_clients_info {
-   u32 clients_num;
-   u32 reserved[19];
-} __packed;
-
 /* GuC Additional Data Struct */
 struct guc_ads {
struct guc_mmio_reg_set 
reg_state_list[GUC_MAX_ENGINE_CLASSES][GUC_MAX_INSTANCES_PER_CLASS];
u32 reserved0;
u32 scheduler_policies;
u32 gt_system_info;
-   u32 clients_info;
+   u32 reserved1;
u32 control_data;
u32 golden_context_lrca[GUC_MAX_ENGINE_CLASSES];
u32 eng_state_size[GUC_MAX_ENGINE_CLASSES];
-- 
2.28.0

[PATCH 12/13] drm/i915/guc: Unified GuC log

[Matthew Brost]

From: John Harrison 

GuC v57 unified the 'DPC' and 'ISR' buffers into a single buffer with
the option for it to be larger.

Signed-off-by: Matthew Brost 
Signed-off-by: John Harrison 
Cc: Alan Previn 
---
 drivers/gpu/drm/i915/gt/uc/intel_guc.c  | 15 ---
 drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h |  9 +++
 drivers/gpu/drm/i915/gt/uc/intel_guc_log.c  | 29 +++--
 drivers/gpu/drm/i915/gt/uc/intel_guc_log.h  |  6 ++---
 4 files changed, 20 insertions(+), 39 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
index b773567cb080..6661dcb02239 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
@@ -219,24 +219,19 @@ static u32 guc_ctl_log_params_flags(struct intel_guc *guc)
 
BUILD_BUG_ON(!CRASH_BUFFER_SIZE);
BUILD_BUG_ON(!IS_ALIGNED(CRASH_BUFFER_SIZE, UNIT));
-   BUILD_BUG_ON(!DPC_BUFFER_SIZE);
-   BUILD_BUG_ON(!IS_ALIGNED(DPC_BUFFER_SIZE, UNIT));
-   BUILD_BUG_ON(!ISR_BUFFER_SIZE);
-   BUILD_BUG_ON(!IS_ALIGNED(ISR_BUFFER_SIZE, UNIT));
+   BUILD_BUG_ON(!DEBUG_BUFFER_SIZE);
+   BUILD_BUG_ON(!IS_ALIGNED(DEBUG_BUFFER_SIZE, UNIT));
 
BUILD_BUG_ON((CRASH_BUFFER_SIZE / UNIT - 1) >
(GUC_LOG_CRASH_MASK >> GUC_LOG_CRASH_SHIFT));
-   BUILD_BUG_ON((DPC_BUFFER_SIZE / UNIT - 1) >
-   (GUC_LOG_DPC_MASK >> GUC_LOG_DPC_SHIFT));
-   BUILD_BUG_ON((ISR_BUFFER_SIZE / UNIT - 1) >
-   (GUC_LOG_ISR_MASK >> GUC_LOG_ISR_SHIFT));
+   BUILD_BUG_ON((DEBUG_BUFFER_SIZE / UNIT - 1) >
+   (GUC_LOG_DEBUG_MASK >> GUC_LOG_DEBUG_SHIFT));
 
flags = GUC_LOG_VALID |
GUC_LOG_NOTIFY_ON_HALF_FULL |
FLAG |
((CRASH_BUFFER_SIZE / UNIT - 1) << GUC_LOG_CRASH_SHIFT) |
-   ((DPC_BUFFER_SIZE / UNIT - 1) << GUC_LOG_DPC_SHIFT) |
-   ((ISR_BUFFER_SIZE / UNIT - 1) << GUC_LOG_ISR_SHIFT) |
+   ((DEBUG_BUFFER_SIZE / UNIT - 1) << GUC_LOG_DEBUG_SHIFT) |
(offset << GUC_LOG_BUF_ADDR_SHIFT);
 
#undef UNIT
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
index f2df5c11c11d..617ec601648d 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
@@ -81,10 +81,8 @@
 #define   GUC_LOG_ALLOC_IN_MEGABYTE(1 << 3)
 #define   GUC_LOG_CRASH_SHIFT  4
 #define   GUC_LOG_CRASH_MASK   (0x3 << GUC_LOG_CRASH_SHIFT)
-#define   GUC_LOG_DPC_SHIFT6
-#define   GUC_LOG_DPC_MASK (0x7 << GUC_LOG_DPC_SHIFT)
-#define   GUC_LOG_ISR_SHIFT9
-#define   GUC_LOG_ISR_MASK (0x7 << GUC_LOG_ISR_SHIFT)
+#define   GUC_LOG_DEBUG_SHIFT  6
+#define   GUC_LOG_DEBUG_MASK   (0xF << GUC_LOG_DEBUG_SHIFT)
 #define   GUC_LOG_BUF_ADDR_SHIFT   12
 
 #define GUC_CTL_WA 1
@@ -311,8 +309,7 @@ struct guc_ads {
 /* GuC logging structures */
 
 enum guc_log_buffer_type {
-   GUC_ISR_LOG_BUFFER,
-   GUC_DPC_LOG_BUFFER,
+   GUC_DEBUG_LOG_BUFFER,
GUC_CRASH_DUMP_LOG_BUFFER,
GUC_MAX_LOG_BUFFER
 };
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
index c36d5eb5bbb9..ac0931f0374b 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
@@ -197,10 +197,8 @@ static bool guc_check_log_buf_overflow(struct 
intel_guc_log *log,
 static unsigned int guc_get_log_buffer_size(enum guc_log_buffer_type type)
 {
switch (type) {
-   case GUC_ISR_LOG_BUFFER:
-   return ISR_BUFFER_SIZE;
-   case GUC_DPC_LOG_BUFFER:
-   return DPC_BUFFER_SIZE;
+   case GUC_DEBUG_LOG_BUFFER:
+   return DEBUG_BUFFER_SIZE;
case GUC_CRASH_DUMP_LOG_BUFFER:
return CRASH_BUFFER_SIZE;
default:
@@ -245,7 +243,7 @@ static void guc_read_update_log_buffer(struct intel_guc_log 
*log)
src_data += PAGE_SIZE;
dst_data += PAGE_SIZE;
 
-   for (type = GUC_ISR_LOG_BUFFER; type < GUC_MAX_LOG_BUFFER; type++) {
+   for (type = GUC_DEBUG_LOG_BUFFER; type < GUC_MAX_LOG_BUFFER; type++) {
/*
 * Make a copy of the state structure, inside GuC log buffer
 * (which is uncached mapped), on the stack to avoid reading
@@ -463,21 +461,16 @@ int intel_guc_log_create(struct intel_guc_log *log)
 *  +===+ 00B
 *  |Crash dump state header|
 *  +---+ 32B
-*  |   DPC state header|
+*  |  Debug state header   |
 *  +---+ 64B
-*  |   ISR state header|
-*  +---+ 96B
 *  |   |
 

[PATCH 09/13] drm/i915/doc: Include GuC ABI documentation

[Matthew Brost]

From: Michal Wajdeczko 

GuC ABI documentation is now ready to be included in i915.rst

Signed-off-by: Michal Wajdeczko 
Signed-off-by: Matthew Brost 
Cc: Piotr Piórkowski 
---
 Documentation/gpu/i915.rst | 8 
 1 file changed, 8 insertions(+)

diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
index 42ce0196930a..c7846b1d9293 100644
--- a/Documentation/gpu/i915.rst
+++ b/Documentation/gpu/i915.rst
@@ -518,6 +518,14 @@ GuC-based command submission
 .. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
:doc: GuC-based command submission
 
+GuC ABI
+
+
+.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/abi/guc_messages_abi.h
+.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/abi/guc_communication_mmio_abi.h
+.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
+.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
+
 HuC
 ---
 .. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_huc.c
-- 
2.28.0

[PATCH 06/13] drm/i915/guc: New definition of the CTB descriptor

[Matthew Brost]

From: Michal Wajdeczko 

Definition of the CTB descriptor has changed, leaving only
minimal shared fields like HEAD/TAIL/STATUS.

Both HEAD and TAIL are now in dwords.

Add some ABI documentation and implement required changes.

Signed-off-by: Michal Wajdeczko 
Signed-off-by: Matthew Brost 
---
 .../gt/uc/abi/guc_communication_ctb_abi.h | 70 ++-
 drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 70 +--
 drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h |  2 +-
 3 files changed, 85 insertions(+), 57 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h 
b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
index d38935f47ecf..c2a069a78e01 100644
--- a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
+++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
@@ -7,6 +7,58 @@
 #define _ABI_GUC_COMMUNICATION_CTB_ABI_H
 
 #include 
+#include 
+
+#include "guc_messages_abi.h"
+
+/**
+ * DOC: CT Buffer
+ *
+ * TBD
+ */
+
+/**
+ * DOC: CTB Descriptor
+ *
+ *  
+---+---+--+
+ *  |   | Bits  | Description  
|
+ *  
+===+===+==+
+ *  | 0 |  31:0 | **HEAD** - offset (in dwords) to the last dword that was 
|
+ *  |   |   | read from the `CT Buffer`_.  
|
+ *  |   |   | It can only be updated by the receiver.  
|
+ *  
+---+---+--+
+ *  | 1 |  31:0 | **TAIL** - offset (in dwords) to the last dword that was 
|
+ *  |   |   | written to the `CT Buffer`_. 
|
+ *  |   |   | It can only be updated by the sender.
|
+ *  
+---+---+--+
+ *  | 2 |  31:0 | **STATUS** - status of the CTB   
|
+ *  |   |   |  
|
+ *  |   |   |   - _`GUC_CTB_STATUS_NO_ERROR` = 0 (normal operation)
|
+ *  |   |   |   - _`GUC_CTB_STATUS_OVERFLOW` = 1 (head/tail too large) 
|
+ *  |   |   |   - _`GUC_CTB_STATUS_UNDERFLOW` = 2 (truncated message)  
|
+ *  |   |   |   - _`GUC_CTB_STATUS_MISMATCH` = 4 (head/tail modified)  
|
+ *  |   |   |   - _`GUC_CTB_STATUS_NO_BACKCHANNEL` = 8 
|
+ *  |   |   |   - _`GUC_CTB_STATUS_MALFORMED_MSG` = 16 
|
+ *  
+---+---+--+
+ *  |...|   | RESERVED = MBZ   
|
+ *  
+---+---+--+
+ *  | 15|  31:0 | RESERVED = MBZ   
|
+ *  
+---+---+--+
+ */
+
+struct guc_ct_buffer_desc {
+   u32 head;
+   u32 tail;
+   u32 status;
+#define GUC_CTB_STATUS_NO_ERROR0
+#define GUC_CTB_STATUS_OVERFLOW(1 << 0)
+#define GUC_CTB_STATUS_UNDERFLOW   (1 << 1)
+#define GUC_CTB_STATUS_MISMATCH(1 << 2)
+#define GUC_CTB_STATUS_NO_BACKCHANNEL  (1 << 3)
+#define GUC_CTB_STATUS_MALFORMED_MSG   (1 << 4)
+   u32 reserved[13];
+} __packed;
+static_assert(sizeof(struct guc_ct_buffer_desc) == 64);
 
 /**
  * DOC: CTB based communication
@@ -60,24 +112,6 @@
  * - **flags**, holds various bits to control message handling
  */
 
-/*
- * Describes single command transport buffer.
- * Used by both guc-master and clients.
- */
-struct guc_ct_buffer_desc {
-   u32 addr;   /* gfx address */
-   u64 host_private;   /* host private data */
-   u32 size;   /* size in bytes */
-   u32 head;   /* offset updated by GuC*/
-   u32 tail;   /* offset updated by owner */
-   u32 is_in_error;/* error indicator */
-   u32 reserved1;
-   u32 reserved2;
-   u32 owner;  /* id of the channel owner */
-   u32 owner_sub_id;   /* owner-defined field for extra tracking */
-   u32 reserved[5];
-} __packed;
-
 /* Type of command transport buffer */
 #define INTEL_GUC_CT_BUFFER_TYPE_SEND  0x0u
 #define INTEL_GUC_CT_BUFFER_TYPE_RECV  0x1u
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index 63056ea0631e..3241a477196f 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -112,32 +112,28 @@ static inline const char *guc_ct_buffer_type_to_str(u32 
type)
}
 }
 
-static void guc_ct_buffer_desc_init(struct guc_ct_buffer_desc *desc,
-  

[PATCH 13/13] drm/i915/guc: Update firmware to v62.0.0

[Matthew Brost]

From: John Harrison 

Signed-off-by: John Harrison 
Signed-off-by: Michal Wajdeczko 
Signed-off-by: Matthew Brost 
---
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 26 
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c 
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
index df647c9a8d56..9f23e9de3237 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -48,19 +48,19 @@ void intel_uc_fw_change_status(struct intel_uc_fw *uc_fw,
  * firmware as TGL.
  */
 #define INTEL_UC_FIRMWARE_DEFS(fw_def, guc_def, huc_def) \
-   fw_def(ALDERLAKE_S, 0, guc_def(tgl, 49, 0, 1), huc_def(tgl,  7, 5, 0)) \
-   fw_def(ROCKETLAKE,  0, guc_def(tgl, 49, 0, 1), huc_def(tgl,  7, 5, 0)) \
-   fw_def(TIGERLAKE,   0, guc_def(tgl, 49, 0, 1), huc_def(tgl,  7, 5, 0)) \
-   fw_def(JASPERLAKE,  0, guc_def(ehl, 49, 0, 1), huc_def(ehl,  9, 0, 0)) \
-   fw_def(ELKHARTLAKE, 0, guc_def(ehl, 49, 0, 1), huc_def(ehl,  9, 0, 0)) \
-   fw_def(ICELAKE, 0, guc_def(icl, 49, 0, 1), huc_def(icl,  9, 0, 0)) \
-   fw_def(COMETLAKE,   5, guc_def(cml, 49, 0, 1), huc_def(cml,  4, 0, 0)) \
-   fw_def(COMETLAKE,   0, guc_def(kbl, 49, 0, 1), huc_def(kbl,  4, 0, 0)) \
-   fw_def(COFFEELAKE,  0, guc_def(kbl, 49, 0, 1), huc_def(kbl,  4, 0, 0)) \
-   fw_def(GEMINILAKE,  0, guc_def(glk, 49, 0, 1), huc_def(glk,  4, 0, 0)) \
-   fw_def(KABYLAKE,0, guc_def(kbl, 49, 0, 1), huc_def(kbl,  4, 0, 0)) \
-   fw_def(BROXTON, 0, guc_def(bxt, 49, 0, 1), huc_def(bxt,  2, 0, 0)) \
-   fw_def(SKYLAKE, 0, guc_def(skl, 49, 0, 1), huc_def(skl,  2, 0, 0))
+   fw_def(ALDERLAKE_S, 0, guc_def(tgl, 62, 0, 0), huc_def(tgl,  7, 5, 0)) \
+   fw_def(ROCKETLAKE,  0, guc_def(tgl, 62, 0, 0), huc_def(tgl,  7, 5, 0)) \
+   fw_def(TIGERLAKE,   0, guc_def(tgl, 62, 0, 0), huc_def(tgl,  7, 5, 0)) \
+   fw_def(JASPERLAKE,  0, guc_def(ehl, 62, 0, 0), huc_def(ehl,  9, 0, 0)) \
+   fw_def(ELKHARTLAKE, 0, guc_def(ehl, 62, 0, 0), huc_def(ehl,  9, 0, 0)) \
+   fw_def(ICELAKE, 0, guc_def(icl, 62, 0, 0), huc_def(icl,  9, 0, 0)) \
+   fw_def(COMETLAKE,   5, guc_def(cml, 62, 0, 0), huc_def(cml,  4, 0, 0)) \
+   fw_def(COMETLAKE,   0, guc_def(kbl, 62, 0, 0), huc_def(kbl,  4, 0, 0)) \
+   fw_def(COFFEELAKE,  0, guc_def(kbl, 62, 0, 0), huc_def(kbl,  4, 0, 0)) \
+   fw_def(GEMINILAKE,  0, guc_def(glk, 62, 0, 0), huc_def(glk,  4, 0, 0)) \
+   fw_def(KABYLAKE,0, guc_def(kbl, 62, 0, 0), huc_def(kbl,  4, 0, 0)) \
+   fw_def(BROXTON, 0, guc_def(bxt, 62, 0, 0), huc_def(bxt,  2, 0, 0)) \
+   fw_def(SKYLAKE, 0, guc_def(skl, 62, 0, 0), huc_def(skl,  2, 0, 0))
 
 #define __MAKE_UC_FW_PATH(prefix_, name_, major_, minor_, patch_) \
"i915/" \
-- 
2.28.0

[PATCH 01/13] drm/i915/guc: Introduce unified HXG messages

[Matthew Brost]

From: Michal Wajdeczko 

New GuC firmware will unify format of MMIO and CTB H2G messages.
Introduce their definitions now to allow gradual transition of
our code to match new changes.

Signed-off-by: Matthew Brost 
Signed-off-by: Michal Wajdeczko 
Cc: Michał Winiarski 
---
 .../gpu/drm/i915/gt/uc/abi/guc_messages_abi.h | 213 ++
 1 file changed, 213 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_messages_abi.h 
b/drivers/gpu/drm/i915/gt/uc/abi/guc_messages_abi.h
index 775e21f3058c..29ac823acd4c 100644
--- a/drivers/gpu/drm/i915/gt/uc/abi/guc_messages_abi.h
+++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_messages_abi.h
@@ -6,6 +6,219 @@
 #ifndef _ABI_GUC_MESSAGES_ABI_H
 #define _ABI_GUC_MESSAGES_ABI_H
 
+/**
+ * DOC: HXG Message
+ *
+ * All messages exchanged with GuC are defined using 32 bit dwords.
+ * First dword is treated as a message header. Remaining dwords are optional.
+ *
+ *  
+---+---+--+
+ *  |   | Bits  | Description  
|
+ *  
+===+===+==+
+ *  |   |   |  
|
+ *  | 0 |31 | **ORIGIN** - originator of the message   
|
+ *  |   |   |   - _`GUC_HXG_ORIGIN_HOST` = 0   
|
+ *  |   |   |   - _`GUC_HXG_ORIGIN_GUC` = 1
|
+ *  |   |   |  
|
+ *  |   
+---+--+
+ *  |   | 30:28 | **TYPE** - message type  
|
+ *  |   |   |   - _`GUC_HXG_TYPE_REQUEST` = 0  
|
+ *  |   |   |   - _`GUC_HXG_TYPE_EVENT` = 1
|
+ *  |   |   |   - _`GUC_HXG_TYPE_NO_RESPONSE_BUSY` = 3 
|
+ *  |   |   |   - _`GUC_HXG_TYPE_NO_RESPONSE_RETRY` = 5
|
+ *  |   |   |   - _`GUC_HXG_TYPE_RESPONSE_FAILURE` = 6 
|
+ *  |   |   |   - _`GUC_HXG_TYPE_RESPONSE_SUCCESS` = 7 
|
+ *  |   
+---+--+
+ *  |   |  27:0 | **AUX** - auxiliary data (depends on TYPE)   
|
+ *  
+---+---+--+
+ *  | 1 |  31:0 |  
|
+ *  +---+---+  
|
+ *  |...|   | **PAYLOAD** - optional payload (depends on TYPE) 
|
+ *  +---+---+  
|
+ *  | n |  31:0 |  
|
+ *  
+---+---+--+
+ */
+
+#define GUC_HXG_MSG_MIN_LEN1u
+#define GUC_HXG_MSG_0_ORIGIN   (0x1 << 31)
+#define   GUC_HXG_ORIGIN_HOST  0u
+#define   GUC_HXG_ORIGIN_GUC   1u
+#define GUC_HXG_MSG_0_TYPE (0x7 << 28)
+#define   GUC_HXG_TYPE_REQUEST 0u
+#define   GUC_HXG_TYPE_EVENT   1u
+#define   GUC_HXG_TYPE_NO_RESPONSE_BUSY3u
+#define   GUC_HXG_TYPE_NO_RESPONSE_RETRY   5u
+#define   GUC_HXG_TYPE_RESPONSE_FAILURE6u
+#define   GUC_HXG_TYPE_RESPONSE_SUCCESS7u
+#define GUC_HXG_MSG_0_AUX  (0xfff << 0)
+#define GUC_HXG_MSG_n_PAYLOAD  (0x << 0)
+
+/**
+ * DOC: HXG Request
+ *
+ * The `HXG Request`_ message should be used to initiate synchronous activity
+ * for which confirmation or return data is expected.
+ *
+ * The recipient of this message shall use `HXG Response`_, `HXG Failure`_
+ * or `HXG Retry`_ message as a definite reply, and may use `HXG Busy`_
+ * message as a intermediate reply.
+ *
+ * Format of @DATA0 and all @DATAn fields depends on the @ACTION code.
+ *
+ *  
+---+---+--+
+ *  |   | Bits  | Description  
|
+ *  
+===+===+==+
+ *  | 0 |31 | ORIGIN   
|
+ *  |   
+---+--+
+ *  |   | 30:28 | TYPE = GUC_HXG_TYPE_REQUEST_ 
|
+ *  |   
+---+--+
+ *  |   | 27:16 | **DATA0** - request data (depends on ACTION) 
|
+ *  |   
+---+--+
+ *  |   |  15:0 | **ACTION** - requested action code   

[PATCH 00/13] Update firmware to v62.0.0

[Matthew Brost]

As part of enabling GuC submission [1] we need to update to the latest
and greatest firmware. This series does that. This is a destructive
change. e.g. Without all the patches in this series it will break the
i915 driver. As such, after we review all of these patches they will
squashed into a single patch for merging.

Signed-off-by: Matthew Brost 

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

John Harrison (3):
  drm/i915/guc: Support per context scheduling policies
  drm/i915/guc: Unified GuC log
  drm/i915/guc: Update firmware to v62.0.0

Michal Wajdeczko (10):
  drm/i915/guc: Introduce unified HXG messages
  drm/i915/guc: Update MMIO based communication
  drm/i915/guc: Update CTB response status definition
  drm/i915/guc: Add flag for mark broken CTB
  drm/i915/guc: New definition of the CTB descriptor
  drm/i915/guc: New definition of the CTB registration action
  drm/i915/guc: New CTB based communication
  drm/i915/doc: Include GuC ABI documentation
  drm/i915/guc: Kill guc_clients.ct_pool
  drm/i915/guc: Kill ads.client_info

 Documentation/gpu/i915.rst|   8 +
 .../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h  | 107 ++
 .../gt/uc/abi/guc_communication_ctb_abi.h | 130 +--
 .../gt/uc/abi/guc_communication_mmio_abi.h|  63 ++--
 .../gpu/drm/i915/gt/uc/abi/guc_messages_abi.h | 213 +++
 drivers/gpu/drm/i915/gt/uc/intel_guc.c| 107 --
 drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c|  45 +--
 drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 355 +-
 drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h |   6 +-
 drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h   |  75 +---
 drivers/gpu/drm/i915/gt/uc/intel_guc_log.c|  29 +-
 drivers/gpu/drm/i915/gt/uc/intel_guc_log.h|   6 +-
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c  |  26 +-
 13 files changed, 750 insertions(+), 420 deletions(-)

-- 
2.28.0

[PATCH 10/13] drm/i915/guc: Kill guc_clients.ct_pool

[Matthew Brost]

From: Michal Wajdeczko 

CTB pool is now maintained internally by the GuC as part of its
"private data". No need to allocate separate buffer and pass it
to GuC as yet another ADS.

Signed-off-by: Matthew Brost  #v4
Signed-off-by: Michal Wajdeczko 
Cc: Janusz Krzysztofik 
---
 drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c  | 12 
 drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 12 +---
 2 files changed, 1 insertion(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
index 4fcbe4b921f9..6e26fe04ce92 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
@@ -26,8 +26,6 @@
  *  +---+
  *  | guc_clients_info  |
  *  +---+
- *  | guc_ct_pool_entry[size]   |
- *  +---+
  *  | padding   |
  *  +---+ <== 4K aligned
  *  | private data  |
@@ -40,7 +38,6 @@ struct __guc_ads_blob {
struct guc_policies policies;
struct guc_gt_system_info system_info;
struct guc_clients_info clients_info;
-   struct guc_ct_pool_entry ct_pool[GUC_CT_POOL_SIZE];
 } __packed;
 
 static u32 guc_ads_private_data_size(struct intel_guc *guc)
@@ -68,11 +65,6 @@ static void guc_policies_init(struct guc_policies *policies)
policies->is_valid = 1;
 }
 
-static void guc_ct_pool_entries_init(struct guc_ct_pool_entry *pool, u32 num)
-{
-   memset(pool, 0, num * sizeof(*pool));
-}
-
 static void guc_mapping_table_init(struct intel_gt *gt,
   struct guc_gt_system_info *system_info)
 {
@@ -161,11 +153,7 @@ static void __guc_ads_init(struct intel_guc *guc)
base = intel_guc_ggtt_offset(guc, guc->ads_vma);
 
/* Clients info  */
-   guc_ct_pool_entries_init(blob->ct_pool, ARRAY_SIZE(blob->ct_pool));
-
blob->clients_info.clients_num = 1;
-   blob->clients_info.ct_pool_addr = base + ptr_offset(blob, ct_pool);
-   blob->clients_info.ct_pool_count = ARRAY_SIZE(blob->ct_pool);
 
/* ADS */
blob->ads.scheduler_policies = base + ptr_offset(blob, policies);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
index 251c3836bd2c..2266444d074f 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
@@ -295,19 +295,9 @@ struct guc_gt_system_info {
 } __packed;
 
 /* Clients info */
-struct guc_ct_pool_entry {
-   struct guc_ct_buffer_desc desc;
-   u32 reserved[7];
-} __packed;
-
-#define GUC_CT_POOL_SIZE   2
-
 struct guc_clients_info {
u32 clients_num;
-   u32 reserved0[13];
-   u32 ct_pool_addr;
-   u32 ct_pool_count;
-   u32 reserved[4];
+   u32 reserved[19];
 } __packed;
 
 /* GuC Additional Data Struct */
-- 
2.28.0

[PATCH 03/13] drm/i915/guc: Update CTB response status definition

[Matthew Brost]

From: Michal Wajdeczko 

Format of the STATUS dword in CTB response message now follows
definition of the HXG header. Update our code and remove any
obsolete legacy definitions.

GuC: 55.0.0
Signed-off-by: Michal Wajdeczko 
Acked-by: Piotr Piórkowski 
---
 drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c   | 14 --
 drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 17 -
 2 files changed, 8 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index 8f7b148fef58..3f7f48611487 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -477,7 +477,9 @@ static int wait_for_ct_request_update(struct ct_request 
*req, u32 *status)
 * up to that length of time, then switch to a slower sleep-wait loop.
 * No GuC command should ever take longer than 10ms.
 */
-#define done INTEL_GUC_MSG_IS_RESPONSE(READ_ONCE(req->status))
+#define done \
+   (FIELD_GET(GUC_HXG_MSG_0_ORIGIN, READ_ONCE(req->status)) == \
+GUC_HXG_ORIGIN_GUC)
err = wait_for_us(done, 10);
if (err)
err = wait_for(done, 10);
@@ -532,21 +534,21 @@ static int ct_send(struct intel_guc_ct *ct,
if (unlikely(err))
goto unlink;
 
-   if (!INTEL_GUC_MSG_IS_RESPONSE_SUCCESS(*status)) {
+   if (FIELD_GET(GUC_HXG_MSG_0_TYPE, *status) != 
GUC_HXG_TYPE_RESPONSE_SUCCESS) {
err = -EIO;
goto unlink;
}
 
if (response_buf) {
/* There shall be no data in the status */
-   WARN_ON(INTEL_GUC_MSG_TO_DATA(request.status));
+   WARN_ON(FIELD_GET(GUC_HXG_RESPONSE_MSG_0_DATA0, 
request.status));
/* Return actual response len */
err = request.response_len;
} else {
/* There shall be no response payload */
WARN_ON(request.response_len);
/* Return data decoded from the status dword */
-   err = INTEL_GUC_MSG_TO_DATA(*status);
+   err = FIELD_GET(GUC_HXG_RESPONSE_MSG_0_DATA0, *status);
}
 
 unlink:
@@ -741,8 +743,8 @@ static int ct_handle_response(struct intel_guc_ct *ct, 
struct ct_incoming_msg *r
status = response->msg[2];
datalen = len - 2;
 
-   /* Format of the status follows RESPONSE message */
-   if (unlikely(!INTEL_GUC_MSG_IS_RESPONSE(status))) {
+   /* Format of the status dword follows HXG header */
+   if (unlikely(FIELD_GET(GUC_HXG_MSG_0_ORIGIN, status) != 
GUC_HXG_ORIGIN_GUC)) {
CT_ERROR(ct, "Corrupted response (status %#x)\n", status);
return -EPROTO;
}
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
index e9a9d85e2aa3..fb04e2211b79 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
@@ -414,23 +414,6 @@ struct guc_shared_ctx_data {
struct guc_ctx_report preempt_ctx_report[GUC_MAX_ENGINES_NUM];
 } __packed;
 
-#define __INTEL_GUC_MSG_GET(T, m) \
-   (((m) & INTEL_GUC_MSG_ ## T ## _MASK) >> INTEL_GUC_MSG_ ## T ## _SHIFT)
-#define INTEL_GUC_MSG_TO_TYPE(m)   __INTEL_GUC_MSG_GET(TYPE, m)
-#define INTEL_GUC_MSG_TO_DATA(m)   __INTEL_GUC_MSG_GET(DATA, m)
-#define INTEL_GUC_MSG_TO_CODE(m)   __INTEL_GUC_MSG_GET(CODE, m)
-
-#define __INTEL_GUC_MSG_TYPE_IS(T, m) \
-   (INTEL_GUC_MSG_TO_TYPE(m) == INTEL_GUC_MSG_TYPE_ ## T)
-#define INTEL_GUC_MSG_IS_REQUEST(m)__INTEL_GUC_MSG_TYPE_IS(REQUEST, m)
-#define INTEL_GUC_MSG_IS_RESPONSE(m)   __INTEL_GUC_MSG_TYPE_IS(RESPONSE, m)
-
-#define INTEL_GUC_MSG_IS_RESPONSE_SUCCESS(m) \
-(typecheck(u32, (m)) && \
- ((m) & (INTEL_GUC_MSG_TYPE_MASK | INTEL_GUC_MSG_CODE_MASK)) == \
- ((INTEL_GUC_MSG_TYPE_RESPONSE << INTEL_GUC_MSG_TYPE_SHIFT) | \
-  (INTEL_GUC_RESPONSE_STATUS_SUCCESS << INTEL_GUC_MSG_CODE_SHIFT)))
-
 /* This action will be programmed in C1BC - SOFT_SCRATCH_15_REG */
 enum intel_guc_recv_message {
INTEL_GUC_RECV_MSG_CRASH_DUMP_POSTED = BIT(1),
-- 
2.28.0

[PATCH 05/13] drm/i915/guc: Add flag for mark broken CTB

[Matthew Brost]

From: Michal Wajdeczko 

Once CTB descriptor is found in error state, either set by GuC
or us, there is no need continue checking descriptor any more,
we can rely on our internal flag.

Signed-off-by: Matthew Brost 
Signed-off-by: Michal Wajdeczko 
Cc: Piotr Piórkowski 
Reviewed-by: Matthew Brost 
---
 drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 13 +++--
 drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h |  2 ++
 2 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index 3f7f48611487..63056ea0631e 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -123,6 +123,7 @@ static void guc_ct_buffer_desc_init(struct 
guc_ct_buffer_desc *desc,
 
 static void guc_ct_buffer_reset(struct intel_guc_ct_buffer *ctb, u32 cmds_addr)
 {
+   ctb->broken = false;
guc_ct_buffer_desc_init(ctb->desc, cmds_addr, ctb->size);
 }
 
@@ -387,9 +388,12 @@ static int ct_write(struct intel_guc_ct *ct,
u32 *cmds = ctb->cmds;
unsigned int i;
 
-   if (unlikely(desc->is_in_error))
+   if (unlikely(ctb->broken))
return -EPIPE;
 
+   if (unlikely(desc->is_in_error))
+   goto corrupted;
+
if (unlikely(!IS_ALIGNED(head | tail, 4) ||
 (tail | head) >= size))
goto corrupted;
@@ -451,6 +455,7 @@ static int ct_write(struct intel_guc_ct *ct,
CT_ERROR(ct, "Corrupted descriptor addr=%#x head=%u tail=%u size=%u\n",
 desc->addr, desc->head, desc->tail, desc->size);
desc->is_in_error = 1;
+   ctb->broken = true;
return -EPIPE;
 }
 
@@ -632,9 +637,12 @@ static int ct_read(struct intel_guc_ct *ct, struct 
ct_incoming_msg **msg)
unsigned int i;
u32 header;
 
-   if (unlikely(desc->is_in_error))
+   if (unlikely(ctb->broken))
return -EPIPE;
 
+   if (unlikely(desc->is_in_error))
+   goto corrupted;
+
if (unlikely(!IS_ALIGNED(head | tail, 4) ||
 (tail | head) >= size))
goto corrupted;
@@ -698,6 +706,7 @@ static int ct_read(struct intel_guc_ct *ct, struct 
ct_incoming_msg **msg)
CT_ERROR(ct, "Corrupted descriptor addr=%#x head=%u tail=%u size=%u\n",
 desc->addr, desc->head, desc->tail, desc->size);
desc->is_in_error = 1;
+   ctb->broken = true;
return -EPIPE;
 }
 
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
index cb222f202301..7d3cd375d6a7 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
@@ -32,12 +32,14 @@ struct intel_guc;
  * @desc: pointer to the buffer descriptor
  * @cmds: pointer to the commands buffer
  * @size: size of the commands buffer
+ * @broken: flag to indicate if descriptor data is broken
  */
 struct intel_guc_ct_buffer {
spinlock_t lock;
struct guc_ct_buffer_desc *desc;
u32 *cmds;
u32 size;
+   bool broken;
 };
 
 
-- 
2.28.0

[PATCH 07/13] drm/i915/guc: New definition of the CTB registration action

[Matthew Brost]

From: Michal Wajdeczko 

Definition of the CTB registration action has changed.
Add some ABI documentation and implement required changes.

Signed-off-by: Michal Wajdeczko 
Signed-off-by: Matthew Brost 
Cc: Piotr Piórkowski  #4
---
 .../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h  | 107 ++
 .../gt/uc/abi/guc_communication_ctb_abi.h |   4 -
 drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c |  76 -
 3 files changed, 152 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h 
b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
index 90efef8a73e4..6426fc183692 100644
--- a/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
+++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
@@ -6,6 +6,113 @@
 #ifndef _ABI_GUC_ACTIONS_ABI_H
 #define _ABI_GUC_ACTIONS_ABI_H
 
+/**
+ * DOC: HOST2GUC_REGISTER_CTB
+ *
+ * This message is used as part of the `CTB based communication`_ setup.
+ *
+ * This message must be sent as `MMIO HXG Message`_.
+ *
+ *  
+---+---+--+
+ *  |   | Bits  | Description  
|
+ *  
+===+===+==+
+ *  | 0 |31 | ORIGIN = GUC_HXG_ORIGIN_HOST_
|
+ *  |   
+---+--+
+ *  |   | 30:28 | TYPE = GUC_HXG_TYPE_REQUEST_ 
|
+ *  |   
+---+--+
+ *  |   | 27:16 | DATA0 = MBZ  
|
+ *  |   
+---+--+
+ *  |   |  15:0 | ACTION = _`GUC_ACTION_HOST2GUC_REGISTER_CTB` = 0x5200
|
+ *  
+---+---+--+
+ *  | 1 | 31:12 | RESERVED = MBZ   
|
+ *  |   
+---+--+
+ *  |   |  11:8 | **TYPE** - type for the `CT Buffer`_ 
|
+ *  |   |   |  
|
+ *  |   |   |   - _`GUC_CTB_TYPE_HOST2GUC` = 0 
|
+ *  |   |   |   - _`GUC_CTB_TYPE_GUC2HOST` = 1 
|
+ *  |   
+---+--+
+ *  |   |   7:0 | **SIZE** - size of the `CT Buffer`_ in 4K units minus 1  
|
+ *  
+---+---+--+
+ *  | 2 |  31:0 | **DESC_ADDR** - GGTT address of the `CTB Descriptor`_
|
+ *  
+---+---+--+
+ *  | 3 |  31:0 | **BUFF_ADDF** - GGTT address of the `CT Buffer`_ 
|
+ *  
+---+---+--+
+*
+ *  
+---+---+--+
+ *  |   | Bits  | Description  
|
+ *  
+===+===+==+
+ *  | 0 |31 | ORIGIN = GUC_HXG_ORIGIN_GUC_ 
|
+ *  |   
+---+--+
+ *  |   | 30:28 | TYPE = GUC_HXG_TYPE_RESPONSE_SUCCESS_
|
+ *  |   
+---+--+
+ *  |   |  27:0 | DATA0 = MBZ  
|
+ *  
+---+---+--+
+ */
+#define GUC_ACTION_HOST2GUC_REGISTER_CTB   0x4505 // FIXME 0x5200
+
+#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_LEN  
(GUC_HXG_REQUEST_MSG_MIN_LEN + 3u)
+#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_0_MBZ
GUC_HXG_REQUEST_MSG_0_DATA0
+#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_MBZ(0xf << 12)
+#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_TYPE   (0xf << 8)
+#define   GUC_CTB_TYPE_HOST2GUC0u
+#define   GUC_CTB_TYPE_GUC2HOST1u
+#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_SIZE   (0xff << 0)
+#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_2_DESC_ADDR  
GUC_HXG_REQUEST_MSG_n_DATAn
+#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_3_BUFF_ADDR  
GUC_HXG_REQUEST_MSG_n_DATAn
+
+#define HOST2GUC_REGISTER_CTB_RESPONSE_MSG_LEN 
GUC_HXG_RESPONSE_MSG_MIN_LEN
+#define HOST2GUC_REGISTER_CTB_RESPONSE_MSG_0_MBZ   
GUC_HXG_RESPONSE_MSG_0_DATA0
+
+/**
+ * DOC: HOST2GUC_DEREGISTER_CTB
+ *
+ * This message is used as part of the `CTB based communication`_ teardown.
+ *
+ * This message must be sent as `MMIO HXG Message`_.
+ *
+ *  
+---+---+--+
+ *  |   | Bits  | 

[PATCH 04/13] drm/i915/guc: Support per context scheduling policies

[Matthew Brost]

From: John Harrison 

GuC firmware v53.0.0 introduced per context scheduling policies. This
includes changes to some of the ADS structures which are required to
load the firmware even if not using GuC submission.

Signed-off-by: John Harrison 
Signed-off-by: Matthew Brost 
Reviewed-by: Matthew Brost 
---
 drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c  | 26 +++--
 drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 31 +
 2 files changed, 11 insertions(+), 46 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
index 9abfbc6edbd6..4fcbe4b921f9 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
@@ -59,30 +59,12 @@ static u32 guc_ads_blob_size(struct intel_guc *guc)
   guc_ads_private_data_size(guc);
 }
 
-static void guc_policy_init(struct guc_policy *policy)
-{
-   policy->execution_quantum = POLICY_DEFAULT_EXECUTION_QUANTUM_US;
-   policy->preemption_time = POLICY_DEFAULT_PREEMPTION_TIME_US;
-   policy->fault_time = POLICY_DEFAULT_FAULT_TIME_US;
-   policy->policy_flags = 0;
-}
-
 static void guc_policies_init(struct guc_policies *policies)
 {
-   struct guc_policy *policy;
-   u32 p, i;
-
-   policies->dpc_promote_time = POLICY_DEFAULT_DPC_PROMOTE_TIME_US;
-   policies->max_num_work_items = POLICY_MAX_NUM_WI;
-
-   for (p = 0; p < GUC_CLIENT_PRIORITY_NUM; p++) {
-   for (i = 0; i < GUC_MAX_ENGINE_CLASSES; i++) {
-   policy = >policy[p][i];
-
-   guc_policy_init(policy);
-   }
-   }
-
+   policies->dpc_promote_time = GLOBAL_POLICY_DEFAULT_DPC_PROMOTE_TIME_US;
+   policies->max_num_work_items = GLOBAL_POLICY_MAX_NUM_WI;
+   /* Disable automatic resets as not yet supported. */
+   policies->global_flags = GLOBAL_POLICY_DISABLE_ENGINE_RESET;
policies->is_valid = 1;
 }
 
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
index fb04e2211b79..251c3836bd2c 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
@@ -247,32 +247,14 @@ struct guc_stage_desc {
 
 /* Scheduling policy settings */
 
-/* Reset engine upon preempt failure */
-#define POLICY_RESET_ENGINE(1<<0)
-/* Preempt to idle on quantum expiry */
-#define POLICY_PREEMPT_TO_IDLE (1<<1)
-
-#define POLICY_MAX_NUM_WI 15
-#define POLICY_DEFAULT_DPC_PROMOTE_TIME_US 50
-#define POLICY_DEFAULT_EXECUTION_QUANTUM_US 100
-#define POLICY_DEFAULT_PREEMPTION_TIME_US 50
-#define POLICY_DEFAULT_FAULT_TIME_US 25
-
-struct guc_policy {
-   /* Time for one workload to execute. (in micro seconds) */
-   u32 execution_quantum;
-   /* Time to wait for a preemption request to completed before issuing a
-* reset. (in micro seconds). */
-   u32 preemption_time;
-   /* How much time to allow to run after the first fault is observed.
-* Then preempt afterwards. (in micro seconds) */
-   u32 fault_time;
-   u32 policy_flags;
-   u32 reserved[8];
-} __packed;
+#define GLOBAL_POLICY_MAX_NUM_WI 15
+
+/* Don't reset an engine upon preemption failure */
+#define GLOBAL_POLICY_DISABLE_ENGINE_RESET BIT(0)
+
+#define GLOBAL_POLICY_DEFAULT_DPC_PROMOTE_TIME_US 50
 
 struct guc_policies {
-   struct guc_policy 
policy[GUC_CLIENT_PRIORITY_NUM][GUC_MAX_ENGINE_CLASSES];
u32 submission_queue_depth[GUC_MAX_ENGINE_CLASSES];
/* In micro seconds. How much time to allow before DPC processing is
 * called back via interrupt (to prevent DPC queue drain starving).
@@ -286,6 +268,7 @@ struct guc_policies {
 * idle. */
u32 max_num_work_items;
 
+   u32 global_flags;
u32 reserved[4];
 } __packed;
 
-- 
2.28.0

[PATCH 02/13] drm/i915/guc: Update MMIO based communication

[Matthew Brost]

From: Michal Wajdeczko 

The MMIO based Host-to-GuC communication protocol has been
updated to use unified HXG messages.

Update our intel_guc_send_mmio() function by correctly handle
BUSY, RETRY and FAILURE replies. Also update our documentation.

GuC: 55.0.0
Signed-off-by: Matthew Brost 
Signed-off-by: Michal Wajdeczko 
Cc: Piotr Piórkowski 
Cc: Michal Winiarski  #v3
---
 .../gt/uc/abi/guc_communication_mmio_abi.h| 63 ++---
 drivers/gpu/drm/i915/gt/uc/intel_guc.c| 92 ++-
 2 files changed, 97 insertions(+), 58 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_mmio_abi.h 
b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_mmio_abi.h
index be066a62e9e0..3f9039e3ef9d 100644
--- a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_mmio_abi.h
+++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_mmio_abi.h
@@ -7,46 +7,43 @@
 #define _ABI_GUC_COMMUNICATION_MMIO_ABI_H
 
 /**
- * DOC: MMIO based communication
+ * DOC: GuC MMIO based communication
  *
- * The MMIO based communication between Host and GuC uses software scratch
- * registers, where first register holds data treated as message header,
- * and other registers are used to hold message payload.
+ * The MMIO based communication between Host and GuC relies on special
+ * hardware registers which format could be defined by the software
+ * (so called scratch registers).
  *
- * For Gen9+, GuC uses software scratch registers 0xC180-0xC1B8,
- * but no H2G command takes more than 8 parameters and the GuC FW
- * itself uses an 8-element array to store the H2G message.
- *
- *  +---+-+-+-+
- *  |  MMIO[0]  | MMIO[1] |   ...   | MMIO[n] |
- *  +---+-+-+-+
- *  | header|  optional payload   |
- *  +==++=+=+=+
- *  | 31:28|type| | | |
- *  +--++ | | |
- *  | 27:16|data| | | |
- *  +--++ | | |
- *  |  15:0|code| | | |
- *  +--++-+-+-+
- *
- * The message header consists of:
- *
- * - **type**, indicates message type
- * - **code**, indicates message code, is specific for **type**
- * - **data**, indicates message data, optional, depends on **code**
+ * Each MMIO based message, both Host to GuC (H2G) and GuC to Host (G2H)
+ * messages, which maximum length depends on number of available scratch
+ * registers, is directly written into those scratch registers.
  *
- * The following message **types** are supported:
+ * For Gen9+, there are 16 software scratch registers 0xC180-0xC1B8,
+ * but no H2G command takes more than 8 parameters and the GuC firmware
+ * itself uses an 8-element array to store the H2G message.
  *
- * - **REQUEST**, indicates Host-to-GuC request, requested GuC action code
- *   must be priovided in **code** field. Optional action specific parameters
- *   can be provided in remaining payload registers or **data** field.
+ * For Gen11+, there are additional 4 registers 0x190240-0x19024C, which
+ * are, regardless on lower count, preffered over legacy ones.
  *
- * - **RESPONSE**, indicates GuC-to-Host response from earlier GuC request,
- *   action response status will be provided in **code** field. Optional
- *   response data can be returned in remaining payload registers or **data**
- *   field.
+ * The MMIO based communication is mainly used during driver initialization
+ * phase to setup the `CTB based communication`_ that will be used afterwards.
  */
 
 #define GUC_MAX_MMIO_MSG_LEN   8
 
+/**
+ * DOC: MMIO HXG Message
+ *
+ * Format of the MMIO messages follows definitions of `HXG Message`_.
+ *
+ *  
+---+---+--+
+ *  |   | Bits  | Description  
|
+ *  
+===+===+==+
+ *  | 0 |  31:0 |  ++  
|
+ *  +---+---+  ||  
|
+ *  |...|   |  |  Embedded `HXG Message`_   |  
|
+ *  +---+---+  ||  
|
+ *  | n |  31:0 |  ++  
|
+ *  
+---+---+--+
+ */
+
 #endif /* _ABI_GUC_COMMUNICATION_MMIO_ABI_H */
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
index f147cb389a20..b773567cb080 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
@@ -376,29 +376,27 @@ void intel_guc_fini(struct intel_guc *guc)
 /*
  * This function implements the MMIO based host to GuC interface.
  */
-int 

[PATCH V6 2/2] drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and SN65DSI84 driver

[Marek Vasut]

Add driver for TI SN65DSI83 Single-link DSI to Single-link LVDS bridge
and TI SN65DSI84 Single-link DSI to Dual-link or 2x Single-link LVDS
bridge. TI SN65DSI85 is unsupported due to lack of hardware to test on,
but easy to add.

The driver operates the chip via I2C bus. Currently the LVDS clock are
always derived from DSI clock lane, which is the usual mode of operation.
Support for clock from external oscillator is not implemented, but it is
easy to add if ever needed. Only RGB888 pixel format is implemented, the
LVDS666 is not supported, but could be added if needed.

Reviewed-by: Linus Walleij 
Reviewed-by: Frieder Schrempf 
Tested-by: Frieder Schrempf 
Tested-by: Adam Ford 
Signed-off-by: Marek Vasut 
Cc: Douglas Anderson 
Cc: Jagan Teki 
Cc: Laurent Pinchart 
Cc: Linus Walleij 
Cc: Loic Poulain 
Cc: Philippe Schenker 
Cc: Sam Ravnborg 
Cc: Stephen Boyd 
Cc: Valentin Raevsky 
To: dri-devel@lists.freedesktop.org
---
V2: - Use dev_err_probe()
- Set REG_RC_RESET as volatile
- Wait for PLL stabilization by polling REG_RC_LVDS_PLL
- Use ctx->mode = *adj instead of *mode in sn65dsi83_mode_set
- Add tested DSI84 support in dual-link mode
- Correctly set VCOM
- Fill in missing DSI CHB and LVDS CHB bits from DSI84 and DSI85
  datasheets, with that all the reserved bits make far more sense
  as the DSI83 and DSI84 seems to be reduced version of DSI85
V3: - Handle the dual-link LVDS with two port panel or bridge
V4: - Add RB from Linus Walleij
- Rename REG_DSI_LANE_LVDS_LINK_CFG_DUAL to
  REG_DSI_LANE_DSI_CHANNEL_MODE_SINGLE and fill in the remaining
  DSI link options from DSI85 datasheet. DSI85 can do dual and 2x
  single DSI mode, but DSI85 is currently unsupported by the
  driver. Add a comment about DSI85, so that all the places which
  need to be adjusted for DSI85 are marked accordingly.
- Add REG_DSI_LANE_LEFT_RIGHT_PIXELS bit for DSI
- Add handling for JEIDA18/JEIDA24/SPWG24 LVDS formats. Use SPWG24
  as fallback on output bridges until they are all fixed.
- Patch DSI bus format to fixed RGB888_1X24 instead of passing
  through the LVDS bus format.
V5: - Move bus format patching to mode_fixup
- Use cpu_to_le16() to guarantee endianness in regmap_bulk_write()
V6: - Cast of_device_get_match_data() output to uintptr_t first
---
 drivers/gpu/drm/bridge/Kconfig|  10 +
 drivers/gpu/drm/bridge/Makefile   |   1 +
 drivers/gpu/drm/bridge/ti-sn65dsi83.c | 709 ++
 3 files changed, 720 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/ti-sn65dsi83.c

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 8e15b387e013..1df1704262d0 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -300,6 +300,16 @@ config DRM_TI_TFP410
help
  Texas Instruments TFP410 DVI/HDMI Transmitter driver
 
+config DRM_TI_SN65DSI83
+   tristate "TI SN65DSI83 and SN65DSI84 DSI to LVDS bridge"
+   depends on OF
+   select DRM_KMS_HELPER
+   select REGMAP_I2C
+   select DRM_PANEL
+   select DRM_MIPI_DSI
+   help
+ Texas Instruments SN65DSI83 and SN65DSI84 DSI to LVDS Bridge driver
+
 config DRM_TI_SN65DSI86
tristate "TI SN65DSI86 DSI to eDP bridge"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index e2218e40b3b3..61302be291af 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -25,6 +25,7 @@ obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
 obj-$(CONFIG_DRM_TOSHIBA_TC358768) += tc358768.o
 obj-$(CONFIG_DRM_TOSHIBA_TC358775) += tc358775.o
 obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
+obj-$(CONFIG_DRM_TI_SN65DSI83) += ti-sn65dsi83.o
 obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o
 obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o
 obj-$(CONFIG_DRM_TI_TPD12S015) += ti-tpd12s015.o
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c 
b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
new file mode 100644
index ..eff35611fabf
--- /dev/null
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
@@ -0,0 +1,709 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * TI SN65DSI83,84,85 driver
+ *
+ * Currently supported:
+ * - SN65DSI83
+ *   = 1x Single-link DSI ~ 1x Single-link LVDS
+ *   - Supported
+ *   - Single-link LVDS mode tested
+ * - SN65DSI84
+ *   = 1x Single-link DSI ~ 2x Single-link or 1x Dual-link LVDS
+ *   - Supported
+ *   - Dual-link LVDS mode tested
+ *   - 2x Single-link LVDS mode unsupported
+ * (should be easy to add by someone who has the HW)
+ * - SN65DSI85
+ *   = 2x Single-link or 1x Dual-link DSI ~ 2x Single-link or 1x Dual-link LVDS
+ *   - Unsupported
+ * (should be easy to add by someone who has the HW)
+ *
+ * Copyright (C) 2021 Marek Vasut 
+ *
+ * Based on previous work of:
+ * Valentin Raevsky 
+ * Philippe Schenker 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 

[PATCH V6 1/2] dt-bindings: drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and SN65DSI84 bindings

[Marek Vasut]

Add DT binding document for TI SN65DSI83 and SN65DSI84 DSI to LVDS bridge.

Reviewed-by: Linus Walleij 
Reviewed-by: Rob Herring 
Signed-off-by: Marek Vasut 
Cc: Douglas Anderson 
Cc: Jagan Teki 
Cc: Laurent Pinchart 
Cc: Linus Walleij 
Cc: Rob Herring 
Cc: Sam Ravnborg 
Cc: Stephen Boyd 
Cc: devicet...@vger.kernel.org
To: dri-devel@lists.freedesktop.org
---
V2: Add compatible string for SN65DSI84, since this is now tested on it
V3: - Add 0x2c as valid i2c address
- Switch to schemas/graph.yaml
- Constraint data-lanes to <1>, <1 2>, <1 2 3>, <1 2 3 4> only
- Indent example by 4 spaces
- Handle dual-link LVDS with two ports and describe the second DSI
  channel-B port as well. Based on the register defaults of DSI83
  and DSI84, it is likely that the LVDS-channel-B and DSI-channel-B
  hardware is present in all the chips, so just reuse port@0 and 2
  for DSI83, port@0,2,3 for DSI84 and all of 0,1,2,3 for DSI85 when
  that is supported
V4: - Fix typo in port@3 description
- Add RB from Linus Walleij
- Replace oneOf: and const with enum:
- ref /schemas/media/video-interfaces.yaml#
- Drop empty endpoint: and properties:
V5: - Add RB from Rob Herring
V6: - No change
---
 .../bindings/display/bridge/ti,sn65dsi83.yaml | 159 ++
 1 file changed, 159 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml

diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml 
b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml
new file mode 100644
index ..d101233ae17f
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml
@@ -0,0 +1,159 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/ti,sn65dsi83.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: SN65DSI83 and SN65DSI84 DSI to LVDS bridge chip
+
+maintainers:
+  - Marek Vasut 
+
+description: |
+  Texas Instruments SN65DSI83 1x Single-link MIPI DSI
+  to 1x Single-link LVDS
+  https://www.ti.com/lit/gpn/sn65dsi83
+  Texas Instruments SN65DSI84 1x Single-link MIPI DSI
+  to 1x Dual-link or 2x Single-link LVDS
+  https://www.ti.com/lit/gpn/sn65dsi84
+
+properties:
+  compatible:
+enum:
+  - ti,sn65dsi83
+  - ti,sn65dsi84
+
+  reg:
+enum:
+  - 0x2c
+  - 0x2d
+
+  enable-gpios:
+maxItems: 1
+description: GPIO specifier for bridge_en pin (active high).
+
+  ports:
+$ref: /schemas/graph.yaml#/properties/ports
+
+properties:
+  port@0:
+$ref: /schemas/graph.yaml#/properties/port
+description: Video port for MIPI DSI Channel-A input
+
+properties:
+  endpoint:
+$ref: /schemas/media/video-interfaces.yaml#
+unevaluatedProperties: false
+
+properties:
+  data-lanes:
+description: array of physical DSI data lane indexes.
+minItems: 1
+maxItems: 4
+items:
+  - const: 1
+  - const: 2
+  - const: 3
+  - const: 4
+
+  port@1:
+$ref: /schemas/graph.yaml#/properties/port
+description: Video port for MIPI DSI Channel-B input
+
+properties:
+  endpoint:
+$ref: /schemas/media/video-interfaces.yaml#
+unevaluatedProperties: false
+
+properties:
+  data-lanes:
+description: array of physical DSI data lane indexes.
+minItems: 1
+maxItems: 4
+items:
+  - const: 1
+  - const: 2
+  - const: 3
+  - const: 4
+
+  port@2:
+$ref: /schemas/graph.yaml#/properties/port
+description: Video port for LVDS Channel-A output (panel or bridge).
+
+  port@3:
+$ref: /schemas/graph.yaml#/properties/port
+description: Video port for LVDS Channel-B output (panel or bridge).
+
+required:
+  - port@0
+  - port@2
+
+required:
+  - compatible
+  - reg
+  - enable-gpios
+  - ports
+
+allOf:
+  - if:
+  properties:
+compatible:
+  contains:
+const: ti,sn65dsi83
+then:
+  properties:
+ports:
+  properties:
+port@1: false
+port@3: false
+
+  - if:
+  properties:
+compatible:
+  contains:
+const: ti,sn65dsi84
+then:
+  properties:
+ports:
+  properties:
+port@1: false
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+
+i2c {
+#address-cells = <1>;
+#size-cells = <0>;
+
+bridge@2d {
+compatible = "ti,sn65dsi83";
+reg = <0x2d>;
+
+enable-gpios = < 1 GPIO_ACTIVE_HIGH>;
+
+ports {
+

Re: [Intel-gfx] [RFC PATCH 36/97] drm/i915/guc: Add non blocking CTB send function

[Matthew Brost]

On Thu, May 27, 2021 at 04:11:50PM +0100, Tvrtko Ursulin wrote:
> 
> On 27/05/2021 15:35, Matthew Brost wrote:
> > On Thu, May 27, 2021 at 11:02:24AM +0100, Tvrtko Ursulin wrote:
> > > 
> > > On 26/05/2021 19:10, Matthew Brost wrote:
> > > 
> > > [snip]
> > > 
> > > > > > > > +static int ct_send_nb(struct intel_guc_ct *ct,
> > > > > > > > + const u32 *action,
> > > > > > > > + u32 len,
> > > > > > > > + u32 flags)
> > > > > > > > +{
> > > > > > > > +   struct intel_guc_ct_buffer *ctb = >ctbs.send;
> > > > > > > > +   unsigned long spin_flags;
> > > > > > > > +   u32 fence;
> > > > > > > > +   int ret;
> > > > > > > > +
> > > > > > > > +   spin_lock_irqsave(>lock, spin_flags);
> > > > > > > > +
> > > > > > > > +   ret = ctb_has_room(ctb, len + 1);
> > > > > > > > +   if (unlikely(ret))
> > > > > > > > +   goto out;
> > > > > > > > +
> > > > > > > > +   fence = ct_get_next_fence(ct);
> > > > > > > > +   ret = ct_write(ct, action, len, fence, flags);
> > > > > > > > +   if (unlikely(ret))
> > > > > > > > +   goto out;
> > > > > > > > +
> > > > > > > > +   intel_guc_notify(ct_to_guc(ct));
> > > > > > > > +
> > > > > > > > +out:
> > > > > > > > +   spin_unlock_irqrestore(>lock, spin_flags);
> > > > > > > > +
> > > > > > > > +   return ret;
> > > > > > > > +}
> > > > > > > > +
> > > > > > > >  static int ct_send(struct intel_guc_ct *ct,
> > > > > > > >const u32 *action,
> > > > > > > >u32 len,
> > > > > > > > @@ -473,6 +541,7 @@ static int ct_send(struct intel_guc_ct *ct,
> > > > > > > >u32 response_buf_size,
> > > > > > > >u32 *status)
> > > > > > > >  {
> > > > > > > > +   struct intel_guc_ct_buffer *ctb = >ctbs.send;
> > > > > > > > struct ct_request request;
> > > > > > > > unsigned long flags;
> > > > > > > > u32 fence;
> > > > > > > > @@ -482,8 +551,20 @@ static int ct_send(struct intel_guc_ct *ct,
> > > > > > > > GEM_BUG_ON(!len);
> > > > > > > > GEM_BUG_ON(len & ~GUC_CT_MSG_LEN_MASK);
> > > > > > > > GEM_BUG_ON(!response_buf && response_buf_size);
> > > > > > > > +   might_sleep();
> > > > > > > 
> > > > > > > Sleep is just cond_resched below or there is more?
> > > > > > > 
> > > > > > 
> > > > > > Yes, the cond_resched.
> > > > > > 
> > > > > > > > +   /*
> > > > > > > > +* We use a lazy spin wait loop here as we believe that 
> > > > > > > > if the CT
> > > > > > > > +* buffers are sized correctly the flow control 
> > > > > > > > condition should be
> > > > > > > > +* rare.
> > > > > > > > +*/
> > > > > > > > +retry:
> > > > > > > > spin_lock_irqsave(>ctbs.send.lock, flags);
> > > > > > > > +   if (unlikely(!ctb_has_room(ctb, len + 1))) {
> > > > > > > > +   spin_unlock_irqrestore(>ctbs.send.lock, 
> > > > > > > > flags);
> > > > > > > > +   cond_resched();
> > > > > > > > +   goto retry;
> > > > > > > > +   }
> > > > > > > 
> > > > > > > If this patch is about adding a non-blocking send function, and 
> > > > > > > below we can
> > > > > > > see that it creates a fork:
> > > > > > > 
> > > > > > > intel_guc_ct_send:
> > > > > > > ...
> > > > > > >   if (flags & INTEL_GUC_SEND_NB)
> > > > > > >   return ct_send_nb(ct, action, len, flags);
> > > > > > > 
> > > > > > >   ret = ct_send(ct, action, len, response_buf, 
> > > > > > > response_buf_size, );
> > > > > > > 
> > > > > > > Then why is there a change in ct_send here, which is not the new
> > > > > > > non-blocking path?
> > > > > > > 
> > > > > > 
> > > > > > There is not a change to ct_send(), just to intel_guc_ct_send.
> > > > > 
> > > > > I was doing by the diff which says:
> > > > > 
> > > > >static int ct_send(struct intel_guc_ct *ct,
> > > > >  const u32 *action,
> > > > >  u32 len,
> > > > > @@ -473,6 +541,7 @@ static int ct_send(struct intel_guc_ct *ct,
> > > > >  u32 response_buf_size,
> > > > >  u32 *status)
> > > > >{
> > > > > + struct intel_guc_ct_buffer *ctb = >ctbs.send;
> > > > >   struct ct_request request;
> > > > >   unsigned long flags;
> > > > >   u32 fence;
> > > > > @@ -482,8 +551,20 @@ static int ct_send(struct intel_guc_ct *ct,
> > > > >   GEM_BUG_ON(!len);
> > > > >   GEM_BUG_ON(len & ~GUC_CT_MSG_LEN_MASK);
> > > > >   GEM_BUG_ON(!response_buf && response_buf_size);
> > > > > + might_sleep();
> > > > > + /*
> > > > > +  * We use a lazy spin wait loop here as we believe that if the 
> > > > > CT
> > > > > +  * buffers are sized correctly the flow control condition 
> > > > > should be
> > > > > +  * rare.
> > > > > +  */
> > > > > +retry:
> > > > >   spin_lock_irqsave(>ctbs.send.lock, flags);
> > > > > + if 

Re: [PATCH] drm/ttm: fix access to uninitialized variable.

[Intel]

On 6/7/21 7:11 PM, Christian König wrote:

The resource is not allocated yet, so no chance that this will work.

Use the placement instead.

Signed-off-by: Christian König 


Reviewed-by: Thomas Hellström 



---
  drivers/gpu/drm/ttm/ttm_bo.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 7e7284da5630..0c74f4cb2a3b 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -736,7 +736,7 @@ static int ttm_bo_mem_force_space(struct ttm_buffer_object 
*bo,
struct ww_acquire_ctx *ticket;
int ret;
  
-	man = ttm_manager_type(bdev, (*mem)->mem_type);

+   man = ttm_manager_type(bdev, place->mem_type);
ticket = dma_resv_locking_ctx(bo->base.resv);
do {
ret = ttm_resource_alloc(bo, place, mem);

RE: [PATCH 02/21] drm: Add Plane Degamma Mode property

[Shankar, Uma]

> -Original Message-
> From: Harry Wentland 
> Sent: Friday, June 4, 2021 11:54 PM
> To: Shankar, Uma ; intel-...@lists.freedesktop.org; 
> dri-
> de...@lists.freedesktop.org
> Cc: Modem, Bhanuprakash ; Cyr, Aric
> 
> Subject: Re: [PATCH 02/21] drm: Add Plane Degamma Mode property
> 
> On 2021-06-01 6:51 a.m., Uma Shankar wrote:
> > Add Plane Degamma Mode as an enum property. Create a helper function
> > for all plane color management features.
> >
> > This is an enum property with values as blob_id's and exposes the
> > various gamma modes supported and the lut ranges. Getting the blob id
> > in userspace, user can get the mode supported and also the range of
> > gamma mode supported with number of lut coefficients. It can then set
> > one of the modes using this enum property.
> >
> > Lut values will be sent through separate GAMMA_LUT blob property.
> >
> > Signed-off-by: Uma Shankar 
> > ---
> >  Documentation/gpu/drm-kms.rst | 90 ++
> >  drivers/gpu/drm/drm_atomic.c  |  1 +
> >  drivers/gpu/drm/drm_atomic_state_helper.c |  2 +
> >  drivers/gpu/drm/drm_atomic_uapi.c |  4 +
> >  drivers/gpu/drm/drm_color_mgmt.c  | 93 ++-
> >  include/drm/drm_mode_object.h |  2 +-
> >  include/drm/drm_plane.h   | 23 ++
> >  7 files changed, 212 insertions(+), 3 deletions(-)
> >
> > diff --git a/Documentation/gpu/drm-kms.rst
> > b/Documentation/gpu/drm-kms.rst index 87e5023e3f55..752be545e7d7
> > 100644
> > --- a/Documentation/gpu/drm-kms.rst
> > +++ b/Documentation/gpu/drm-kms.rst
> > @@ -514,9 +514,99 @@ Damage Tracking Properties  Color Management
> > Properties
> >  ---
> >
> > +Below is how a typical hardware pipeline for color will look like:
> > +
> > +.. kernel-render:: DOT
> > +   :alt: Display Color Pipeline
> > +   :caption: Display Color Pipeline Overview
> > +
> > +   digraph "KMS" {
> > +  node [shape=box]
> > +
> > +  subgraph cluster_static {
> > +  style=dashed
> > +  label="Display Color Hardware Blocks"
> > +
> > +  node [bgcolor=grey style=filled]
> > +  "Plane Degamma A" -> "Plane CSC/CTM A"
> > +  "Plane CSC/CTM A" -> "Plane Gamma A"
> > +  "Pipe Blender" [color=lightblue,style=filled, width=5.25, 
> > height=0.75];
> > +  "Plane Gamma A" -> "Pipe Blender"
> > + "Pipe Blender" -> "Pipe DeGamma"
> > +  "Pipe DeGamma" -> "Pipe CSC/CTM"
> > +  "Pipe CSC/CTM" -> "Pipe Gamma"
> > +  "Pipe Gamma" -> "Pipe Output"
> > +  }
> > +
> 
> It might be worthwhile to also highlight the YCbCr coefficient matrix in the 
> pipeline,
> between the FB and Plane degamma, i.e.
>   YCbCr coefficients > plane degamma > csc > ...
> 
> One problem with this view is that not all HW will support all (or any) of 
> these CM
> blocks on all planes. For example, on AMD HW cursors are very different from 
> other
> planes and don't really have full CM support.
> 
> > +  subgraph cluster_static {
> > +  style=dashed
> > +
> > +  node [shape=box]
> > +  "Plane Degamma B" -> "Plane CSC/CTM B"
> > +  "Plane CSC/CTM B" -> "Plane Gamma B"
> > +  "Plane Gamma B" -> "Pipe Blender"
> > +  }
> > +
> > +  subgraph cluster_static {
> > +  style=dashed
> > +
> > +  node [shape=box]
> > +  "Plane Degamma C" -> "Plane CSC/CTM C"
> > +  "Plane CSC/CTM C" -> "Plane Gamma C"
> > +  "Plane Gamma C" -> "Pipe Blender"
> > +  }
> > +
> > +  subgraph cluster_fb {
> > +  style=dashed
> > +  label="RAM"
> > +
> > +  node [shape=box width=1.7 height=0.2]
> > +
> > +  "FB 1" -> "Plane Degamma A"
> > +  "FB 2" -> "Plane Degamma B"
> > +  "FB 3" -> "Plane Degamma C"
> > +  }
> > +   }
> > +
> > +In real world usecases,
> > +
> > +1. Plane Degamma can be used to linearize a non linear gamma encoded
> > +framebuffer. This is needed to do any linear math like color space
> > +conversion. For ex, linearize frames encoded in SRGB or by HDR curve.
> > +
> > +2. Later Plane CTM block can convert the content to some different
> > +colorspace. For ex, SRGB to BT2020 etc.
> > +
> > +3. Plane Gamma block can be used later to re-apply the non-linear
> > +curve. This can also be used to apply Tone Mapping for HDR usecases.
> > +
> 
> This would mean you're blending in gamma space which is likely not what most
> compositors expect. There are numerous articles that describe why blending in
> gamma space is problematic, such as [1]
> 
> [1] https://ninedegreesbelow.com/photography/linear-gamma-blur-normal-
> blend.html
> 
> To blend in linear space this should be configured to do
> 
>   Plane Degamma > Plane CTM > CRTC Gamma
> 
> I think it would also be good if we moved away from calling this gamma. It's 
> really
> only gamma for legacy SDR scenarios. For HDR cases I would never expect 

[PATCH] drm/stm: Remove usage of drm_display_mode_to_videomode()

[Marek Vasut]

There is not much value in the extra conversion step, the calculations
required for the LTDC IP are different than what is used in the
drm_display_mode_to_videomode(), so just do the right ones in the LTDC
driver right away.

Signed-off-by: Marek Vasut 
Cc: Alexandre Torgue 
Cc: Antonio Borneo 
Cc: Benjamin Gaignard 
Cc: Maxime Coquelin 
Cc: Philippe Cornu 
Cc: Sam Ravnborg 
Cc: Vincent Abriou 
Cc: Yannick Fertre 
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-st...@st-md-mailman.stormreply.com
To: dri-devel@lists.freedesktop.org
---
 drivers/gpu/drm/stm/ltdc.c | 33 +
 1 file changed, 17 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
index e99771b947b6..08b71248044d 100644
--- a/drivers/gpu/drm/stm/ltdc.c
+++ b/drivers/gpu/drm/stm/ltdc.c
@@ -531,7 +531,6 @@ static void ltdc_crtc_mode_set_nofb(struct drm_crtc *crtc)
struct drm_encoder *encoder = NULL;
struct drm_bridge *bridge = NULL;
struct drm_display_mode *mode = >state->adjusted_mode;
-   struct videomode vm;
u32 hsync, vsync, accum_hbp, accum_vbp, accum_act_w, accum_act_h;
u32 total_width, total_height;
u32 bus_flags = 0;
@@ -570,31 +569,33 @@ static void ltdc_crtc_mode_set_nofb(struct drm_crtc *crtc)
}
}
 
-   drm_display_mode_to_videomode(mode, );
-
DRM_DEBUG_DRIVER("CRTC:%d mode:%s\n", crtc->base.id, mode->name);
-   DRM_DEBUG_DRIVER("Video mode: %dx%d", vm.hactive, vm.vactive);
+   DRM_DEBUG_DRIVER("Video mode: %dx%d", mode->hdisplay, mode->vdisplay);
DRM_DEBUG_DRIVER(" hfp %d hbp %d hsl %d vfp %d vbp %d vsl %d\n",
-vm.hfront_porch, vm.hback_porch, vm.hsync_len,
-vm.vfront_porch, vm.vback_porch, vm.vsync_len);
+mode->hsync_start - mode->hdisplay,
+mode->htotal - mode->hsync_end,
+mode->hsync_end - mode->hsync_start,
+mode->vsync_start - mode->vdisplay,
+mode->vtotal - mode->vsync_end,
+mode->vsync_end - mode->vsync_start);
 
/* Convert video timings to ltdc timings */
-   hsync = vm.hsync_len - 1;
-   vsync = vm.vsync_len - 1;
-   accum_hbp = hsync + vm.hback_porch;
-   accum_vbp = vsync + vm.vback_porch;
-   accum_act_w = accum_hbp + vm.hactive;
-   accum_act_h = accum_vbp + vm.vactive;
-   total_width = accum_act_w + vm.hfront_porch;
-   total_height = accum_act_h + vm.vfront_porch;
+   hsync = mode->hsync_end - mode->hsync_start - 1;
+   vsync = mode->vsync_end - mode->vsync_start - 1;
+   accum_hbp = mode->htotal - mode->hsync_start - 1;
+   accum_vbp = mode->vtotal - mode->vsync_start - 1;
+   accum_act_w = accum_hbp + mode->hdisplay;
+   accum_act_h = accum_vbp + mode->vdisplay;
+   total_width = mode->htotal - 1;
+   total_height = mode->vtotal - 1;
 
/* Configures the HS, VS, DE and PC polarities. Default Active Low */
val = 0;
 
-   if (vm.flags & DISPLAY_FLAGS_HSYNC_HIGH)
+   if (mode->flags & DRM_MODE_FLAG_PHSYNC)
val |= GCR_HSPOL;
 
-   if (vm.flags & DISPLAY_FLAGS_VSYNC_HIGH)
+   if (mode->flags & DRM_MODE_FLAG_PVSYNC)
val |= GCR_VSPOL;
 
if (bus_flags & DRM_BUS_FLAG_DE_LOW)
-- 
2.30.2

Re: [PATCH][next] drm/amd/display: Fix two spelling mistakes, clean wide lines

[Alex Deucher]

Applied.  Thanks!

Alex

On Mon, Jun 7, 2021 at 7:58 AM Colin King  wrote:
>
> From: Colin Ian King 
>
> There are two spelling mistakes in dml_print messages, fix these and
> clear up checkpatch warning on overly wide line length.
>
> Signed-off-by: Colin Ian King 
> ---
>  .../drm/amd/display/dc/dml/dcn31/display_mode_vba_31.c | 10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn31/display_mode_vba_31.c 
> b/drivers/gpu/drm/amd/display/dc/dml/dcn31/display_mode_vba_31.c
> index c725160a095b..d655655baaba 100644
> --- a/drivers/gpu/drm/amd/display/dc/dml/dcn31/display_mode_vba_31.c
> +++ b/drivers/gpu/drm/amd/display/dc/dml/dcn31/display_mode_vba_31.c
> @@ -1494,10 +1494,11 @@ static bool CalculatePrefetchSchedule(
> dml_print(
> "DML:  Tsw: %fus = time to fetch enough pixel 
> data and cursor data to feed the scalers init position and detile\n",
> (double) LinesToRequestPrefetchPixelData * 
> LineTime);
> -   dml_print("DML: To: %fus - time for propogation from scaler 
> to optc\n", (*DSTYAfterScaler + ((double) (*DSTXAfterScaler) / (double) 
> myPipe->HTotal)) * LineTime);
> +   dml_print("DML: To: %fus - time for propagation from scaler 
> to optc\n",
> + (*DSTYAfterScaler + ((double) (*DSTXAfterScaler) /
> + (double) myPipe->HTotal)) * LineTime);
> dml_print("DML: Tvstartup - TSetup - Tcalc - Twait - Tpre - 
> To > 0\n");
> -   dml_print(
> -   "DML: Tslack(pre): %fus - time left over in 
> schedule\n",
> +   dml_print("DML: Tslack(pre): %fus - time left over in 
> schedule\n",
> VStartup * LineTime - TimeForFetchingMetaPTE 
> - 2 * TimeForFetchingRowInVBlank
> - (*DSTYAfterScaler + 
> ((double) (*DSTXAfterScaler) / (double) myPipe->HTotal)) * LineTime - TWait - 
> TCalc - *TSetup);
> dml_print("DML: row_bytes = dpte_row_bytes (per_pipe) = 
> PixelPTEBytesPerRow = : %d\n", PixelPTEBytesPerRow);
> @@ -3023,7 +3024,8 @@ static void 
> DISPCLKDPPCLKDCFCLKDeepSleepPrefetchParametersWatermarksAndPerforman
> for (k = 0; k < v->NumberOfActivePlanes; ++k) {
> if (v->ImmediateFlipSupportedForPipe[k] == 
> false) {
>  #ifdef __DML_VBA_DEBUG__
> -   dml_print("DML::%s: Pipe %0d not 
> supporing iflip\n", __func__, k);
> +   dml_print("DML::%s: Pipe %0d not 
> supporting iflip\n",
> + __func__, k);
>  #endif
> v->ImmediateFlipSupported = false;
> }
> --
> 2.31.1
>

RE: [PATCH 01/21] drm: Add Enhanced Gamma and color lut range attributes

[Shankar, Uma]

> -Original Message-
> From: Harry Wentland 
> Sent: Friday, June 4, 2021 8:53 PM
> To: Shankar, Uma ; Pekka Paalanen
> 
> Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; Modem,
> Bhanuprakash 
> Subject: Re: [PATCH 01/21] drm: Add Enhanced Gamma and color lut range
> attributes
> 
> On 2021-06-02 4:26 p.m., Shankar, Uma wrote:
> >
> >
> >> -Original Message-
> >> From: Pekka Paalanen 
> >> Sent: Wednesday, June 2, 2021 3:04 PM
> >> To: Shankar, Uma 
> >> Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
> >> Modem, Bhanuprakash 
> >> Subject: Re: [PATCH 01/21] drm: Add Enhanced Gamma and color lut
> >> range attributes
> >>
> >> On Tue,  1 Jun 2021 16:21:58 +0530
> >> Uma Shankar  wrote:
> >>
> >>> Existing LUT precision structure is having only 16 bit precision.
> >>> This is not enough for upcoming enhanced hardwares and advance
> >>> usecases like HDR processing. Hence added a new structure with 32
> >>> bit precision values.
> >>>
> >>> This also defines a new structure to define color lut ranges, along
> >>> with related macro definitions and enums. This will help describe
> >>> multi segmented lut ranges in the hardware.
> >>>
> >>> Signed-off-by: Uma Shankar 
> >>> ---
> >>>  include/uapi/drm/drm_mode.h | 58
> >>> +
> >>>  1 file changed, 58 insertions(+)
> >>>
> >>> diff --git a/include/uapi/drm/drm_mode.h
> >>> b/include/uapi/drm/drm_mode.h index 9b6722d45f36..d0ce48d2e732
> >>> 100644
> >>> --- a/include/uapi/drm/drm_mode.h
> >>> +++ b/include/uapi/drm/drm_mode.h
> >>> @@ -819,6 +819,64 @@ struct hdr_output_metadata {
> >>>   };
> >>>  };
> >>>
> >>> +/*
> >>> + * DRM_MODE_LUT_GAMMA|DRM_MODE_LUT_DEGAMMA is legal and
> means
> >> the LUT
> >>> + * can be used for either purpose, but not simultaneously. To
> >>> + expose
> >>> + * modes that support gamma and degamma simultaneously the gamma
> >>> + mode
> >>> + * must declare distinct DRM_MODE_LUT_GAMMA and
> >> DRM_MODE_LUT_DEGAMMA
> >>> + * ranges.
> >>> + */
> >>> +/* LUT is for gamma (after CTM) */
> >>> +#define DRM_MODE_LUT_GAMMA BIT(0)
> >>> +/* LUT is for degamma (before CTM) */ #define DRM_MODE_LUT_DEGAMMA
> >>> +BIT(1)
> >>> +/* linearly interpolate between the points */ #define
> >>> +DRM_MODE_LUT_INTERPOLATE BIT(2)
> >>> +/*
> >>> + * the last value of the previous range is the
> >>> + * first value of the current range.
> >>> + */
> >>> +#define DRM_MODE_LUT_REUSE_LAST BIT(3)
> >>> +/* the curve must be non-decreasing */ #define
> >>> +DRM_MODE_LUT_NON_DECREASING BIT(4)
> >>> +/* the curve is reflected across origin for negative inputs */
> >>> +#define DRM_MODE_LUT_REFLECT_NEGATIVE BIT(5)
> >>> +/* the same curve (red) is used for blue and green channels as well
> >>> +*/ #define DRM_MODE_LUT_SINGLE_CHANNEL BIT(6)
> >>> +
> >>> +struct drm_color_lut_range {
> >>> + /* DRM_MODE_LUT_* */
> >>> + __u32 flags;
> >>> + /* number of points on the curve */
> >>> + __u16 count;
> >>> + /* input/output bits per component */
> >>> + __u8 input_bpc, output_bpc;
> >>> + /* input start/end values */
> >>> + __s32 start, end;
> >>> + /* output min/max values */
> >>> + __s32 min, max;
> >>> +};
> >>> +
> >>> +enum lut_type {
> >>
> >> Unprefixed type name in UAPI headers is probably not a good idea.
> >
> > Ok, will rename these.
> >
> >>> + LUT_TYPE_DEGAMMA = 0,
> >>> + LUT_TYPE_GAMMA = 1,
> >>> +};
> >>
> >> All the above stuff seems to be the same in your other patch series'
> >> patch "[PATCH 1/9] drm: Add gamma mode property". Is this series
> >> replacing the series "[PATCH 0/9] Enhance pipe color support for
> >> multi segmented luts" or what does this mean?
> >
> > The concept and idea is similar and the range definition is also
> > common. But this series focuses on plane color management while the other 
> > one
> is for pipe/crtc color features.
> > Hence separated and floated them as unique series for review.
> >
> 
> Might be better in this case to combine both patchsets. It wasn't entirely 
> clear to me
> whether I could base one patchset on top of the other (doesn't look like it) 
> and what
> base to apply them on. I had success applying the plane stuff on drm-next and 
> the
> crtc stuff on drm-intel.

Sure Harry, I guess its better to combine both the series to avoid any 
confusions.
I will send out next version with some more UAPI documentation based on the 
feedback
received.

Regards,
Uma Shankar
> 
> Harry
> 
> > Regards,
> > Uma Shankar
> >>
> >> Thanks,
> >> pq
> >>
> >>> +
> >>> +/*
> >>> + * Creating 64 bit palette entries for better data
> >>> + * precision. This will be required for HDR and
> >>> + * similar color processing usecases.
> >>> + */
> >>> +struct drm_color_lut_ext {
> >>> + /*
> >>> +  * Data is U32.32 fixed point format.
> >>> +  */
> >>> + __u64 red;
> >>> + __u64 green;
> >>> + __u64 blue;
> >>> + __u64 reserved;
> >>> +};
> >>> +
> >>>  #define DRM_MODE_PAGE_FLIP_EVENT 0x01  #define
> >>> 

Re: [PATCH] drm/amdgpu: Fix a a typo in a comment

[Alex Deucher]

Applied.  Thanks!

Alex

On Mon, Jun 7, 2021 at 6:46 AM Christian König
 wrote:
>
> Am 05.06.21 um 11:06 schrieb Christophe JAILLET:
> > s/than/then/
> >
> > Signed-off-by: Christophe JAILLET 
>
> Acked-by: Christian König 
>
> > ---
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c 
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> > index 89ebbf363e27..1476236f5c7c 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> > @@ -662,7 +662,7 @@ static int amdgpu_cs_sync_rings(struct amdgpu_cs_parser 
> > *p)
> >* @error:  error number
> >* @backoff:indicator to backoff the reservation
> >*
> > - * If error is set than unvalidate buffer, otherwise just free memory
> > + * If error is set then unvalidate buffer, otherwise just free memory
> >* used by parsing context.
> >**/
> >   static void amdgpu_cs_parser_fini(struct amdgpu_cs_parser *parser, int 
> > error,
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm/amd/display: Fix duplicate included dce110_hw_sequencer.h

[Alex Deucher]

Applied.  Thanks!

Alex

On Mon, Jun 7, 2021 at 6:27 AM Jiapeng Chong
 wrote:
>
> Clean up the following includecheck warning:
>
> ./drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c:
> dce110_hw_sequencer.h is included more than once.
>
> No functional change.
>
> Reported-by: Abaci Robot 
> Signed-off-by: Jiapeng Chong 
> ---
>  drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c 
> b/drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c
> index e731987..04d02ce 100644
> --- a/drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c
> +++ b/drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c
> @@ -32,7 +32,6 @@
>  #include "core_status.h"
>  #include "resource.h"
>  #include "dm_helpers.h"
> -#include "dce110_hw_sequencer.h"
>  #include "dce110_timing_generator.h"
>  #include "dce/dce_hwseq.h"
>  #include "gpio_service_interface.h"
> --
> 1.8.3.1
>

Re: [PATCH] drm/amd/display: remove no need variable

[Alex Deucher]

On Sat, Jun 5, 2021 at 8:31 AM Bernard Zhao  wrote:
>
> remove no need variable, just return the DC_OK
>
> Signed-off-by: Bernard Zhao 

Applied.  Thanks!

Alex

> ---
>  drivers/gpu/drm/amd/display/dc/dcn10/dcn10_resource.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_resource.c 
> b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_resource.c
> index f962b905e79e..7daadb6a5233 100644
> --- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_resource.c
> +++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_resource.c
> @@ -1266,8 +1266,6 @@ static enum dc_status dcn10_validate_global(struct dc 
> *dc, struct dc_state *cont
>
>  static enum dc_status dcn10_patch_unknown_plane_state(struct dc_plane_state 
> *plane_state)
>  {
> -   enum dc_status result = DC_OK;
> -
> enum surface_pixel_format surf_pix_format = plane_state->format;
> unsigned int bpp = resource_pixel_format_to_bpp(surf_pix_format);
>
> @@ -1279,7 +1277,7 @@ static enum dc_status 
> dcn10_patch_unknown_plane_state(struct dc_plane_state *pla
> swizzle = DC_SW_64KB_S;
>
> plane_state->tiling_info.gfx9.swizzle = swizzle;
> -   return result;
> +   return DC_OK;
>  }
>
>  struct stream_encoder *dcn10_find_first_free_match_stream_enc_for_link(
> --
> 2.31.0
>

[PATCH] drm/ttm: fix access to uninitialized variable.

[Christian König]

The resource is not allocated yet, so no chance that this will work.

Use the placement instead.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/ttm/ttm_bo.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 7e7284da5630..0c74f4cb2a3b 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -736,7 +736,7 @@ static int ttm_bo_mem_force_space(struct ttm_buffer_object 
*bo,
struct ww_acquire_ctx *ticket;
int ret;
 
-   man = ttm_manager_type(bdev, (*mem)->mem_type);
+   man = ttm_manager_type(bdev, place->mem_type);
ticket = dma_resv_locking_ctx(bo->base.resv);
do {
ret = ttm_resource_alloc(bo, place, mem);
-- 
2.25.1

Re: [PATCH 01/10] drm/ttm: allocate resource object instead of embedding it v2

[Christian König]

Am 07.06.21 um 18:40 schrieb Thomas Hellström (Intel):


On 6/2/21 12:09 PM, Christian König wrote:
...
@@ -728,14 +728,15 @@ static int ttm_bo_add_move_fence(struct 
ttm_buffer_object *bo,

   */
  static int ttm_bo_mem_force_space(struct ttm_buffer_object *bo,
    const struct ttm_place *place,
-  struct ttm_resource *mem,
+  struct ttm_resource **mem,
    struct ttm_operation_ctx *ctx)
  {
  struct ttm_device *bdev = bo->bdev;
-    struct ttm_resource_manager *man = ttm_manager_type(bdev, 
mem->mem_type);

+    struct ttm_resource_manager *man;
  struct ww_acquire_ctx *ticket;
  int ret;
  +    man = ttm_manager_type(bdev, (*mem)->mem_type);


Isn't (*mem) uninitialized here? Should be place->mem_type? Eviction 
is immediately sent to the bushes.


Indeed and I'm like 99% sure that Nirmoy has pointed that out to me as well.

Looks like I missed to fix that one. We need more CI testing.

Thanks,
Christian.



Got at least one additional NULL pointer deref to track down in the 
eviction code, but could be a merge error of mine as well.


/Thomas

Re: [PATCH v8 08/11] drm/bridge: ti-sn65dsi86: Promote the AUX channel to its own sub-dev

[Doug Anderson]

Hi,

On Sat, Jun 5, 2021 at 9:40 PM Bjorn Andersson
 wrote:
>
> > + /*
> > +  * We couldn't do this pre-probe because it would confuse pinctrl.
> > +  * It would have tried to grab the same pins that the main device had.
> > +  * Set it now so that we can put the proper (sub) device in the aux
> > +  * structure and it will have the right node.
> > +  */
> > + adev->dev.of_node = pdata->dev->of_node;
>
> I suspect the refcount of the of_node will be wrong here and upon
> removing the aux device things will be off...
>
> Instead, I think you're looking for device_set_of_node_from_dev(), which
> also sets of_node_reused, which in turn causes pinctrl_bind_pins() to be
> skipped - i.e. it seems to deal with the problem your comment describes.

You rock! This is exactly what I wanted. I wish I had thought to look
for it--I somehow just assumed that this wasn't already a solved
problem.

-Doug

Re: [PATCH v8 07/11] drm/panel: panel-simple: Stash DP AUX bus; allow using it for DDC

[Doug Anderson]

Hi,

On Fri, Jun 4, 2021 at 9:10 AM  wrote:
>
> Hi Doug,
>
> >   panel->no_hpd = of_property_read_bool(dev->of_node, "no-hpd");
> >   if (!panel->no_hpd) {
> > @@ -708,6 +712,8 @@ static int panel_simple_probe(struct device *dev,
> > const struct panel_desc *desc)
> >
> >   if (!panel->ddc)
> >   return -EPROBE_DEFER;
> > + } else if (aux) {
> > + panel->ddc = >ddc;
> >   }
>
> In panel_simple_probe(), the put_device(>ddc->dev) call is
> causing issue when the aux->ddc is used to assign panel->ddc
> It works well when "ddc-i2c-bus" is used to assign panel->ddc
>
> static int panel_simple_probe(...)
> {
> ...
>
> free_ddc:
>  if (panel->ddc)
>  put_device(>ddc->dev);
>
>  return err;
> }

Thanks for catching! Fixed in v9.


-Doug

[PATCH v9 11/11] arm64: dts: qcom: sc7180-trogdor: Move panel under the bridge chip

[Douglas Anderson]

Putting the panel under the bridge chip (under the aux-bus node)
allows the panel driver to get access to the DP AUX bus, enabling all
sorts of fabulous new features.

While we're at this, get rid of a level of hierarchy for the panel
node. It doesn't need "ports / port" and can just have a "port" child.

For Linux, this patch has a hard requirement on the patches adding DP
AUX bus support to the ti-sn65dsi86 bridge chip driver. See the patch
("drm/bridge: ti-sn65dsi86: Add support for the DP AUX bus").

Signed-off-by: Douglas Anderson 
Acked-by: Linus Walleij 
---

(no changes since v7)

Changes in v7:
- Panel now under bridge chip instead of getting a link to ddc-i2c

 arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi | 30 ++--
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi 
b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
index 24d293ef56d7..c76afd857b54 100644
--- a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
@@ -260,21 +260,6 @@ max98357a: audio-codec-0 {
#sound-dai-cells = <0>;
};
 
-   panel: panel {
-   /* Compatible will be filled in per-board */
-   power-supply = <_dx_edp>;
-   backlight = <>;
-   hpd-gpios = <_bridge 2 GPIO_ACTIVE_HIGH>;
-
-   ports {
-   port {
-   panel_in_edp: endpoint {
-   remote-endpoint = <_out>;
-   };
-   };
-   };
-   };
-
pwmleds {
compatible = "pwm-leds";
keyboard_backlight: keyboard-backlight {
@@ -674,6 +659,21 @@ sn65dsi86_out: endpoint {
};
};
};
+
+   aux-bus {
+   panel: panel {
+   /* Compatible will be filled in per-board */
+   power-supply = <_dx_edp>;
+   backlight = <>;
+   hpd-gpios = <_bridge 2 
GPIO_ACTIVE_HIGH>;
+
+   port {
+   panel_in_edp: endpoint {
+   remote-endpoint = 
<_out>;
+   };
+   };
+   };
+   };
};
 };
 
-- 
2.32.0.rc1.229.g3e70b5a671-goog

[PATCH v9 09/11] drm/bridge: ti-sn65dsi86: Don't read EDID blob over DDC

[Douglas Anderson]

This is really just a revert of commit 58074b08c04a ("drm/bridge:
ti-sn65dsi86: Read EDID blob over DDC"), resolving conflicts.

The old code failed to read the EDID properly in a very important
case: before the bridge's pre_enable() was called. The way things need
to work:
1. Read the EDID.
2. Based on the EDID, decide on video settings and pixel clock.
3. Enable the bridge w/ the desired settings.

The way things were working:
1. Try to read the EDID but fail; fall back to hardcoded values.
2. Based on hardcoded values, decide on video settings and pixel clock.
3. Enable the bridge w/ the desired settings.
4. Try again to read the EDID, it works now!
5. Realize that the hardcoded settings weren't quite right.
6. Disable / reenable the bridge w/ the right settings.

The reasons for the failures were twofold:
a) Since we never ran the bridge chip's pre-enable then we never set
   the bit to ignore HPD. This meant the bridge chip didn't even _try_
   to go out on the bus and communicate with the panel.
b) Even if we fixed things to ignore HPD, the EDID still wouldn't read
   if the panel wasn't on.

Instead of reverting the code, we could fix it to set the HPD bit and
also power on the panel. However, it also works nicely to just let the
panel code read the EDID. Now that we've split the driver up we can
expose the DDC AUX channel bus to the panel node. The panel can take
charge of reading the EDID.

NOTE: in order for things to work, anyone that needs to read the EDID
will need to instantiate their panel using the new DP AUX bus (AKA by
listing their panel under the "aux-bus" node of the bridge chip in the
device tree).

In the future if we want to use the bridge chip to provide a full
external DP port (which won't have a panel) then we will have to
conditinally add EDID reading back in.

Suggested-by: Andrzej Hajda 
Signed-off-by: Douglas Anderson 
Reviewed-by: Bjorn Andersson 
---

(no changes since v7)

Changes in v7:
- Adjusted commit message to talk about DP AUX bus.

 drivers/gpu/drm/bridge/ti-sn65dsi86.c | 22 --
 1 file changed, 22 deletions(-)

diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c 
b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
index 32bd35c98d95..b544cbce7fdd 100644
--- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
@@ -126,7 +126,6 @@
  * @connector:Our connector.
  * @host_node:Remote DSI node.
  * @dsi:  Our MIPI DSI source.
- * @edid: Detected EDID of eDP panel.
  * @refclk:   Our reference clock.
  * @panel:Our panel.
  * @enable_gpio:  The GPIO we toggle to enable the bridge.
@@ -157,7 +156,6 @@ struct ti_sn65dsi86 {
struct drm_dp_aux   aux;
struct drm_bridge   bridge;
struct drm_connectorconnector;
-   struct edid *edid;
struct device_node  *host_node;
struct mipi_dsi_device  *dsi;
struct clk  *refclk;
@@ -406,24 +404,6 @@ connector_to_ti_sn65dsi86(struct drm_connector *connector)
 static int ti_sn_bridge_connector_get_modes(struct drm_connector *connector)
 {
struct ti_sn65dsi86 *pdata = connector_to_ti_sn65dsi86(connector);
-   struct edid *edid = pdata->edid;
-   int num, ret;
-
-   if (!edid) {
-   pm_runtime_get_sync(pdata->dev);
-   edid = pdata->edid = drm_get_edid(connector, >aux.ddc);
-   pm_runtime_put_autosuspend(pdata->dev);
-   }
-
-   if (edid && drm_edid_is_valid(edid)) {
-   ret = drm_connector_update_edid_property(connector, edid);
-   if (!ret) {
-   num = drm_add_edid_modes(connector, edid);
-   if (num)
-   return num;
-   }
-   }
-
return drm_panel_get_modes(pdata->panel, connector);
 }
 
@@ -1356,8 +1336,6 @@ static void ti_sn_bridge_remove(struct auxiliary_device 
*adev)
mipi_dsi_device_unregister(pdata->dsi);
}
 
-   kfree(pdata->edid);
-
drm_bridge_remove(>bridge);
 
of_node_put(pdata->host_node);
-- 
2.32.0.rc1.229.g3e70b5a671-goog

[PATCH v9 10/11] drm/bridge: ti-sn65dsi86: Improve probe errors with dev_err_probe()

[Douglas Anderson]

As I was testing to make sure that the DEFER path worked well with my
patch series, I got tired of seeing this scary message in my logs just
because the panel needed to defer:
  [drm:ti_sn_bridge_probe] *ERROR* could not find any panel node

Let's use dev_err_probe() which nicely quiets this error and also
simplifies the code a tiny bit. We'll also update other places in the
file which can use dev_err_probe().

Signed-off-by: Douglas Anderson 
---

Changes in v9:
- ("Improve probe errors") patch new for v9.

 drivers/gpu/drm/bridge/ti-sn65dsi86.c | 31 +++
 1 file changed, 13 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c 
b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
index b544cbce7fdd..5d712c8c3c3b 100644
--- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
@@ -1305,10 +1305,9 @@ static int ti_sn_bridge_probe(struct auxiliary_device 
*adev,
int ret;
 
ret = drm_of_find_panel_or_bridge(np, 1, 0, >panel, NULL);
-   if (ret) {
-   DRM_ERROR("could not find any panel node\n");
-   return ret;
-   }
+   if (ret)
+   return dev_err_probe(>dev, ret,
+"could not find any panel node\n");
 
ti_sn_bridge_parse_lanes(pdata, np);
 
@@ -1456,27 +1455,23 @@ static int ti_sn65dsi86_probe(struct i2c_client *client,
 
pdata->regmap = devm_regmap_init_i2c(client,
 _sn65dsi86_regmap_config);
-   if (IS_ERR(pdata->regmap)) {
-   DRM_ERROR("regmap i2c init failed\n");
-   return PTR_ERR(pdata->regmap);
-   }
+   if (IS_ERR(pdata->regmap))
+   return dev_err_probe(dev, PTR_ERR(pdata->regmap),
+"regmap i2c init failed\n");
 
pdata->enable_gpio = devm_gpiod_get(dev, "enable", GPIOD_OUT_LOW);
-   if (IS_ERR(pdata->enable_gpio)) {
-   DRM_ERROR("failed to get enable gpio from DT\n");
-   ret = PTR_ERR(pdata->enable_gpio);
-   return ret;
-   }
+   if (IS_ERR(pdata->enable_gpio))
+   return dev_err_probe(dev, PTR_ERR(pdata->enable_gpio),
+"failed to get enable gpio from DT\n");
 
ret = ti_sn65dsi86_parse_regulators(pdata);
-   if (ret) {
-   DRM_ERROR("failed to parse regulators\n");
-   return ret;
-   }
+   if (ret)
+   return dev_err_probe(dev, ret, "failed to parse regulators\n");
 
pdata->refclk = devm_clk_get_optional(dev, "refclk");
if (IS_ERR(pdata->refclk))
-   return PTR_ERR(pdata->refclk);
+   return dev_err_probe(dev, PTR_ERR(pdata->refclk),
+"failed to get reference clock\n");
 
pm_runtime_enable(dev);
ret = devm_add_action_or_reset(dev, ti_sn65dsi86_runtime_disable, dev);
-- 
2.32.0.rc1.229.g3e70b5a671-goog

[PATCH v9 07/11] drm/bridge: ti-sn65dsi86: Promote the AUX channel to its own sub-dev

[Douglas Anderson]

On its own, this change looks a little strange and doesn't do too much
useful. To understand why we're doing this we need to look forward to
future patches where we're going to probe our panel using the new DP
AUX bus. See the patch ("drm/bridge: ti-sn65dsi86: Add support for the
DP AUX bus").

Let's think about the set of steps we'll want to happen when we have
the DP AUX bus:

1. We'll create the DP AUX bus.
2. We'll populate the devices on the DP AUX bus (AKA our panel).
3. For setting up the bridge-related functions of ti-sn65dsi86 we'll
   need to get a reference to the panel.

If we do #1 - #3 in a single probe call things _mostly_ will work, but
it won't be massively robust. Let's explore.

First let's think of the easy case of no -EPROBE_DEFER. In that case
in step #2 when we populate the devices on the DP AUX bus it will
actually try probing the panel right away. Since the panel probe
doesn't defer then in step #3 we'll get a reference to the panel and
we're golden.

Second, let's think of the case when the panel returns
-EPROBE_DEFER. In that case step #2 won't synchronously create the
panel (it'll just add the device to the defer list to do it
later). Step #3 will fail to get the panel and the bridge sub-device
will return -EPROBE_DEFER. We'll depopulate the DP AUX bus. Later
we'll try the whole sequence again. Presumably the panel will
eventually stop returning -EPROBE_DEFER and we'll go back to the first
case where things were golden. So this case is OK too even if it's a
bit ugly that we have to keep creating / deleting the AUX bus over and
over.

So where is the problem? As I said, it's mostly about robustness. I
don't believe that step #2 (creating the sub-devices) is really
guaranteed to be synchronous. This is evidenced by the fact that it's
allowed to "succeed" by just sticking the device on the deferred
list. If anything about the process changes in Linux as a whole and
step #2 just kicks off the probe of the DP AUX endpoints (our panel)
in the background then we'd be in trouble because we might never get
the panel in step #3.

Adding an extra sub-device means we just don't need to worry about
it. We'll create the sub-device for the DP AUX bus and it won't go
away until the whole ti-sn65dsi86 driver goes away. If the bridge
sub-device defers (maybe because it can't find the panel) that won't
depopulate the DP AUX bus and so we don't need to worry about it.

NOTE: there's a little bit of a trick here. Though the AUX channel can
run without the MIPI-to-eDP bits of the code, the MIPI-to-eDP bits
can't run without the AUX channel. We could come up a complicated
signaling scheme (have the MIPI-to-eDP bits return EPROBE_DEFER for a
while or wait on some sort of completion), but it seems simple enough
to just not even bother creating the bridge device until the AUX
channel probes. That's what we'll do.

Signed-off-by: Douglas Anderson 
Reviewed-by: Lyude Paul 
---

Changes in v9:
- Properly set the of_node of sn65dsi86 auxbus devices now.

Changes in v7:
- Beefed up commit message in context of the DP AUX bus.
- Remove use of now-dropped drm_dp_aux_register_ddc() call.
- Set the proper sub-device "dev" pointer in the AUX structure.

Changes in v6:
- Use new drm_dp_aux_register_ddc() calls.

 drivers/gpu/drm/bridge/ti-sn65dsi86.c | 70 +++
 1 file changed, 51 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c 
b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
index 45a2969afb2b..8e61005cf4ad 100644
--- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
@@ -116,6 +116,7 @@
  * struct ti_sn65dsi86 - Platform data for ti-sn65dsi86 driver.
  * @bridge_aux:   AUX-bus sub device for MIPI-to-eDP bridge functionality.
  * @gpio_aux: AUX-bus sub device for GPIO controller functionality.
+ * @aux_aux:  AUX-bus sub device for eDP AUX channel functionality.
  *
  * @dev:  Pointer to the top level (i2c) device.
  * @regmap:   Regmap for accessing i2c.
@@ -148,6 +149,7 @@
 struct ti_sn65dsi86 {
struct auxiliary_device bridge_aux;
struct auxiliary_device gpio_aux;
+   struct auxiliary_device aux_aux;
 
struct device   *dev;
struct regmap   *regmap;
@@ -1333,11 +1335,6 @@ static int ti_sn_bridge_probe(struct auxiliary_device 
*adev,
if (ret)
return ret;
 
-   pdata->aux.name = "ti-sn65dsi86-aux";
-   pdata->aux.dev = pdata->dev;
-   pdata->aux.transfer = ti_sn_aux_transfer;
-   drm_dp_aux_init(>aux);
-
pdata->bridge.funcs = _sn_bridge_funcs;
pdata->bridge.of_node = np;
 
@@ -1406,17 +1403,10 @@ static int ti_sn65dsi86_add_aux_device(struct 
ti_sn65dsi86 *pdata,
struct device *dev = pdata->dev;
int ret;
 
-   /*
-* NOTE: It would be nice to set the "of_node" of our children to be
-* the same "of_node"" that the top-level component 

[PATCH v9 05/11] drm/panel: panel-simple: Allow panel-simple be a DP AUX endpoint device

[Douglas Anderson]

The panel-simple driver can already have devices instantiated as
platform devices or MIPI DSI devices. Let's add a 3rd way to
instantiate it: as DP AUX endpoint devices.

At the moment there is no benefit to instantiating it in this way,
but:
- In the next patch we'll give it access to the DDC channel via the DP
  AUX bus.
- Possibly in the future we may use this channel to configure the
  backlight.

Signed-off-by: Douglas Anderson 
Reviewed-by: Lyude Paul 
---

(no changes since v7)

Changes in v7:
- Patch to allow panel-simple to be DP AUX EP new for v7.

 drivers/gpu/drm/panel/Kconfig|  1 +
 drivers/gpu/drm/panel/panel-simple.c | 52 +---
 2 files changed, 49 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index ef87d92cdf49..b1ea86d9fdaf 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -82,6 +82,7 @@ config DRM_PANEL_SIMPLE
depends on BACKLIGHT_CLASS_DEVICE
depends on PM
select VIDEOMODE_HELPERS
+   select DRM_DP_AUX_BUS
help
  DRM panel driver for dumb panels that need at most a regulator and
  a GPIO to be powered up. Optionally a backlight can be attached so
diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 21939d4352cf..d3b5ae22d939 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -36,6 +36,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -4957,6 +4958,38 @@ static struct mipi_dsi_driver panel_simple_dsi_driver = {
.shutdown = panel_simple_dsi_shutdown,
 };
 
+static int panel_simple_dp_aux_ep_probe(struct dp_aux_ep_device *aux_ep)
+{
+   const struct of_device_id *id;
+
+   id = of_match_node(platform_of_match, aux_ep->dev.of_node);
+   if (!id)
+   return -ENODEV;
+
+   return panel_simple_probe(_ep->dev, id->data);
+}
+
+static void panel_simple_dp_aux_ep_remove(struct dp_aux_ep_device *aux_ep)
+{
+   panel_simple_remove(_ep->dev);
+}
+
+static void panel_simple_dp_aux_ep_shutdown(struct dp_aux_ep_device *aux_ep)
+{
+   panel_simple_shutdown(_ep->dev);
+}
+
+static struct dp_aux_ep_driver panel_simple_dp_aux_ep_driver = {
+   .driver = {
+   .name = "panel-simple-dp-aux",
+   .of_match_table = platform_of_match,/* Same as platform 
one! */
+   .pm = _simple_pm_ops,
+   },
+   .probe = panel_simple_dp_aux_ep_probe,
+   .remove = panel_simple_dp_aux_ep_remove,
+   .shutdown = panel_simple_dp_aux_ep_shutdown,
+};
+
 static int __init panel_simple_init(void)
 {
int err;
@@ -4965,15 +4998,25 @@ static int __init panel_simple_init(void)
if (err < 0)
return err;
 
+   err = dp_aux_dp_driver_register(_simple_dp_aux_ep_driver);
+   if (err < 0)
+   goto err_did_platform_register;
+
if (IS_ENABLED(CONFIG_DRM_MIPI_DSI)) {
err = mipi_dsi_driver_register(_simple_dsi_driver);
-   if (err < 0) {
-   
platform_driver_unregister(_simple_platform_driver);
-   return err;
-   }
+   if (err < 0)
+   goto err_did_aux_ep_register;
}
 
return 0;
+
+err_did_aux_ep_register:
+   dp_aux_dp_driver_unregister(_simple_dp_aux_ep_driver);
+
+err_did_platform_register:
+   platform_driver_unregister(_simple_platform_driver);
+
+   return err;
 }
 module_init(panel_simple_init);
 
@@ -4982,6 +5025,7 @@ static void __exit panel_simple_exit(void)
if (IS_ENABLED(CONFIG_DRM_MIPI_DSI))
mipi_dsi_driver_unregister(_simple_dsi_driver);
 
+   dp_aux_dp_driver_unregister(_simple_dp_aux_ep_driver);
platform_driver_unregister(_simple_platform_driver);
 }
 module_exit(panel_simple_exit);
-- 
2.32.0.rc1.229.g3e70b5a671-goog

[PATCH v9 08/11] drm/bridge: ti-sn65dsi86: Add support for the DP AUX bus

[Douglas Anderson]

We want to provide our panel with access to the DP AUX channel. The
way to do this is to let our panel be a child of ours using the fancy
new DP AUX bus support.

Signed-off-by: Douglas Anderson 
Acked-by: Linus Walleij 
Reviewed-by: Lyude Paul 
---

Changes in v9:
- Rebased atop v9 ("Promote the AUX channel") patch.

Changes in v7:
- Patch to support for DP AUX bus on ti-sn65dsi86 new for v7.

 drivers/gpu/drm/bridge/Kconfig| 1 +
 drivers/gpu/drm/bridge/ti-sn65dsi86.c | 6 ++
 2 files changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index c96e4b38d1d3..5e1e28d4520f 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -293,6 +293,7 @@ config DRM_TI_SN65DSI86
select DRM_PANEL
select DRM_MIPI_DSI
select AUXILIARY_BUS
+   select DRM_DP_AUX_BUS
help
  Texas Instruments SN65DSI86 DSI to eDP Bridge driver
 
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c 
b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
index 8e61005cf4ad..32bd35c98d95 100644
--- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1426,12 +1427,17 @@ static int ti_sn_aux_probe(struct auxiliary_device 
*adev,
   const struct auxiliary_device_id *id)
 {
struct ti_sn65dsi86 *pdata = dev_get_drvdata(adev->dev.parent);
+   int ret;
 
pdata->aux.name = "ti-sn65dsi86-aux";
pdata->aux.dev = >dev;
pdata->aux.transfer = ti_sn_aux_transfer;
drm_dp_aux_init(>aux);
 
+   ret = devm_of_dp_aux_populate_ep_devices(>aux);
+   if (ret)
+   return ret;
+
/*
 * The eDP to MIPI bridge parts don't work until the AUX channel is
 * setup so we don't add it in the main driver probe, we add it now.
-- 
2.32.0.rc1.229.g3e70b5a671-goog