subject:"No subject"

Hi mac.shen,

kernel test robot noticed the following build errors:

[auto build test ERROR on drm-misc/drm-misc-next]
[also build test ERROR on pza/reset/next linus/master v6.8-rc4 next-20240213]
[cannot apply to pza/imx-drm/next]
[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#_base_tree_information]

url:
https://github.com/intel-lab-lkp/linux/commits/mac-shen/Subject-PATCH-drm-mediatek-dp-Add-tee-client-application-for-HDCP-feature/20240205-163727
base:   git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
patch link:
https://lore.kernel.org/r/20240205055055.25340-3-mac.shen%40mediatek.com
patch subject: [PATCH v2 2/3] Subject: [PATCH] drm/mediatek/dp: Add HDCP2.x 
feature for DisplayPort
config: arm-randconfig-001-20240213 
(https://download.01.org/0day-ci/archive/20240213/202402131731.omfzwywy-...@intel.com/config)
compiler: arm-linux-gnueabi-gcc (GCC) 13.2.0
reproduce (this is a W=1 build): 
(https://download.01.org/0day-ci/archive/20240213/202402131731.omfzwywy-...@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot 
| Closes: 
https://lore.kernel.org/oe-kbuild-all/202402131731.omfzwywy-...@intel.com/

All errors (new ones prefixed by >>):

   arm-linux-gnueabi-ld: drivers/gpu/drm/mediatek/mtk_dp.o: in function 
`mtk_dp_get_system_time':
>> mtk_dp.c:(.text+0x41c0): undefined reference to `__aeabi_uldivmod'
>> arm-linux-gnueabi-ld: mtk_dp.c:(.text+0x41ce): undefined reference to 
>> `__aeabi_uldivmod'
   arm-linux-gnueabi-ld: drivers/gpu/drm/mediatek/mtk_dp.o: in function 
`mtk_dp_get_time_diff':
   mtk_dp.c:(.text+0x41ea): undefined reference to `__aeabi_uldivmod'
   arm-linux-gnueabi-ld: mtk_dp.c:(.text+0x41f8): undefined reference to 
`__aeabi_uldivmod'

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

[no subject]

2024-02-07 Thread Rob Clark

Hi Dave,

A few fixes for v6.8, description below

The following changes since commit d4ca26ac4be0d9aea7005c40df75e6775749671b:

  drm/msm/dp: call dp_display_get_next_bridge() during probe
(2023-12-14 09:27:46 +0200)

are available in the Git repository at:

  https://gitlab.freedesktop.org/drm/msm.git tags/drm-msm-fixes-2024-02-07

for you to fetch changes up to 8d35217149daa33358c284aca6a56d5ab92cfc6c:

  drm/msm/mdss: specify cfg bandwidth for SDM670 (2024-01-25 14:36:04 -0800)


Fixes for v6.8-rc4

DPU:
- fix for kernel doc warnings and smatch warnings in dpu_encoder
- fix for smatch warning in dpu_encoder
- fix the bus bandwidth value for SDM670

DP:
- fixes to handle unknown bpc case correctly for DP. The current code was
  spilling over into other bits of DP configuration register, had to be
  fixed to avoid the extra shifts which were causing the spill over
- fix for MISC0 programming in DP driver to program the correct
  colorimetry value

GPU:
- dmabuf vmap fix
- a610 UBWC corruption fix (incorrect hbb)
- revert a commit that was making GPU recovery unreliable


Abhinav Kumar (1):
  drm/msm/dpu: check for valid hw_pp in dpu_encoder_helper_phys_cleanup

Dmitry Baryshkov (1):
  drm/msm/mdss: specify cfg bandwidth for SDM670

Kuogee Hsieh (2):
  drm/msms/dp: fixed link clock divider bits be over written in
BPC unknown case
  drm/msm/dp: return correct Colorimetry for DP_TEST_DYNAMIC_RANGE_CEA case

Randy Dunlap (1):
  drm/msm/dpu: fix kernel-doc warnings

 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c |  8 ++--
 drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c  |  3 ++-
 drivers/gpu/drm/msm/dp/dp_ctrl.c|  5 -
 drivers/gpu/drm/msm/dp/dp_link.c| 22 ++
 drivers/gpu/drm/msm/dp/dp_reg.h |  3 +++
 drivers/gpu/drm/msm/msm_mdss.c  |  1 +
 6 files changed, 22 insertions(+), 20 deletions(-)

Re: [PATCH v2 2/3] Subject: [PATCH] drm/mediatek/dp: Add HDCP2.x feature for DisplayPort

2024-02-06 Thread AngeloGioacchino Del Regno


Il 05/02/24 06:50, mac.shen ha scritto:

Add HDCP2.x feature for DisplayPort.
When userspace request the kernel protect future content communicated
over the link with Content_Protection property, the feature will do
HDCP2.x authentication if the sink support HDCP2.X.

Changes in v2:
- remove switch case, and refine code to make more clear
- remove some definitions, and use the definitions in
   include/drm/drm_hdcp.h
- use the struct which defined in include/drm/drm_hdcp.h
- do HDCP2.x authentication when userspace request the
   kernel protect future content communicated
per suggestion from the previous thread:
https://lore.kernel.org/all/8fff59b5567449d8201dd1138c8fa
9218a545c46.ca...@mediatek.com/

Signed-off-by: mac.shen 
---
  drivers/gpu/drm/mediatek/Makefile   |1 +
  drivers/gpu/drm/mediatek/mtk_dp.c   |  297 +--
  drivers/gpu/drm/mediatek/mtk_dp.h   |   99 +++
  drivers/gpu/drm/mediatek/mtk_dp_hdcp2.c | 1021 +++
  drivers/gpu/drm/mediatek/mtk_dp_hdcp2.h |   52 ++
  drivers/gpu/drm/mediatek/mtk_dp_reg.h   |4 +-
  drivers/gpu/drm/mediatek/mtk_dpi.c  |3 +
  7 files changed, 1392 insertions(+), 85 deletions(-)
  create mode 100644 drivers/gpu/drm/mediatek/mtk_dp.h
  create mode 100644 drivers/gpu/drm/mediatek/mtk_dp_hdcp2.c
  create mode 100644 drivers/gpu/drm/mediatek/mtk_dp_hdcp2.h

diff --git a/drivers/gpu/drm/mediatek/Makefile 
b/drivers/gpu/drm/mediatek/Makefile
index c80e6c2f9336..50ea069b047e 100644
--- a/drivers/gpu/drm/mediatek/Makefile
+++ b/drivers/gpu/drm/mediatek/Makefile
@@ -27,6 +27,7 @@ mediatek-drm-hdmi-objs := mtk_cec.o \
  obj-$(CONFIG_DRM_MEDIATEK_HDMI) += mediatek-drm-hdmi.o
  
  mtk-dp-objs := tlc_dp_hdcp.o \

+ mtk_dp_hdcp2.o \
  mtk_dp.o
  
  obj-$(CONFIG_DRM_MEDIATEK_DP) += mtk-dp.o

diff --git a/drivers/gpu/drm/mediatek/mtk_dp.c 
b/drivers/gpu/drm/mediatek/mtk_dp.c
index e4c16ba9902d..7ff72f15528b 100644
--- a/drivers/gpu/drm/mediatek/mtk_dp.c
+++ b/drivers/gpu/drm/mediatek/mtk_dp.c
@@ -1,6 +1,6 @@
  // SPDX-License-Identifier: GPL-2.0
  /*
- * Copyright (c) 2019-2022 MediaTek Inc.
+ * Copyright (c) 2019-2024 MediaTek Inc.
   * Copyright (c) 2022 BayLibre
   */
  
@@ -8,13 +8,13 @@

  #include 
  #include 
  #include 
-#include 
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -30,10 +30,10 @@
  #include 
  #include 
  #include 
-#include 
-#include 
  
+#include "mtk_dp.h"

  #include "mtk_dp_reg.h"
+#include "mtk_dp_hdcp2.h"
  
  #define MTK_DP_SIP_CONTROL_AARCH32	MTK_SIP_SMC_CMD(0x523)

  #define MTK_DP_SIP_ATF_EDP_VIDEO_UNMUTE   (BIT(0) | BIT(5))
@@ -52,43 +52,6 @@
  #define MTK_DP_VERSION 0x11
  #define MTK_DP_SDP_AUI 0x4
  
-enum {

-   MTK_DP_CAL_GLB_BIAS_TRIM = 0,
-   MTK_DP_CAL_CLKTX_IMPSE,
-   MTK_DP_CAL_LN_TX_IMPSEL_PMOS_0,
-   MTK_DP_CAL_LN_TX_IMPSEL_PMOS_1,
-   MTK_DP_CAL_LN_TX_IMPSEL_PMOS_2,
-   MTK_DP_CAL_LN_TX_IMPSEL_PMOS_3,
-   MTK_DP_CAL_LN_TX_IMPSEL_NMOS_0,
-   MTK_DP_CAL_LN_TX_IMPSEL_NMOS_1,
-   MTK_DP_CAL_LN_TX_IMPSEL_NMOS_2,
-   MTK_DP_CAL_LN_TX_IMPSEL_NMOS_3,
-   MTK_DP_CAL_MAX,
-};
-
-struct mtk_dp_train_info {
-   bool sink_ssc;
-   bool cable_plugged_in;
-   /* link_rate is in multiple of 0.27Gbps */
-   int link_rate;
-   int lane_count;
-   unsigned int channel_eq_pattern;
-};
-
-struct mtk_dp_audio_cfg {
-   bool detect_monitor;
-   int sad_count;
-   int sample_rate;
-   int word_length_bits;
-   int channels;
-};
-
-struct mtk_dp_info {
-   enum dp_pixelformat format;
-   struct videomode vm;
-   struct mtk_dp_audio_cfg audio_cur_cfg;
-};
-
  struct mtk_dp_efuse_fmt {
unsigned short idx;
unsigned short shift;
@@ -98,44 +61,6 @@ struct mtk_dp_efuse_fmt {
unsigned short default_val;
  };
  
-struct mtk_dp {

-   bool enabled;
-   bool need_debounce;
-   int irq;
-   u8 max_lanes;
-   u8 max_linkrate;
-   u8 rx_cap[DP_RECEIVER_CAP_SIZE];
-   u32 cal_data[MTK_DP_CAL_MAX];
-   u32 irq_thread_handle;
-   /* irq_thread_lock is used to protect irq_thread_handle */
-   spinlock_t irq_thread_lock;
-
-   struct device *dev;
-   struct drm_bridge bridge;
-   struct drm_bridge *next_bridge;
-   struct drm_connector *conn;
-   struct drm_device *drm_dev;
-   struct drm_dp_aux aux;
-
-   const struct mtk_dp_data *data;
-   struct mtk_dp_info info;
-   struct mtk_dp_train_info train_info;
-
-   struct platform_device *phy_dev;
-   struct phy *phy;
-   struct regmap *regs;
-   struct timer_list debounce_timer;
-
-   /* For audio */
-   bool audio_enable;
-   hdmi_codec_plugged_cb plugged_cb;
-   struct platform_device *audio_pdev;
-
-   struct device *codec_dev;
-   /* protect the plugged_cb as it's used in both bridge ops and audio */
-   struct mutex

Re: [PATCH v2 1/3] Subject: [PATCH] drm/mediatek/dp: Add tee client application for HDCP feature

2024-02-06 Thread AngeloGioacchino Del Regno


Il 05/02/24 06:50, mac.shen ha scritto:

Add tee client application which will be used for
HDCP 1.x and 2.x authentication in DisplayPort.

Changes in v2:
- remove ca folder, and change file name with lower case
- refine the tci_t structure to make the data to tee can
   through this structure
- remove aux and regs from mtk_hdcp_info structure
- remove some definitions, and use the definitions in
   include/drm/drm_hdcp.h
- remove useless code
per suggestion from the previous thread:
https://lore.kernel.org/all/8fff59b5567449d8201dd1138c8fa
9218a545c46.ca...@mediatek.com/

Signed-off-by: mac.shen 
---
  drivers/gpu/drm/mediatek/Makefile  |   5 +-
  drivers/gpu/drm/mediatek/tci.h | 156 +++
  drivers/gpu/drm/mediatek/tlc_dp_hdcp.c | 598 +
  drivers/gpu/drm/mediatek/tlc_dp_hdcp.h | 414 +
  4 files changed, 1172 insertions(+), 1 deletion(-)
  create mode 100644 drivers/gpu/drm/mediatek/tci.h
  create mode 100644 drivers/gpu/drm/mediatek/tlc_dp_hdcp.c
  create mode 100644 drivers/gpu/drm/mediatek/tlc_dp_hdcp.h

diff --git a/drivers/gpu/drm/mediatek/Makefile 
b/drivers/gpu/drm/mediatek/Makefile
index d4d193f60271..c80e6c2f9336 100644
--- a/drivers/gpu/drm/mediatek/Makefile
+++ b/drivers/gpu/drm/mediatek/Makefile
@@ -26,4 +26,7 @@ mediatek-drm-hdmi-objs := mtk_cec.o \
  
  obj-$(CONFIG_DRM_MEDIATEK_HDMI) += mediatek-drm-hdmi.o
  
-obj-$(CONFIG_DRM_MEDIATEK_DP) += mtk_dp.o

+mtk-dp-objs := tlc_dp_hdcp.o \
+ mtk_dp.o
+
+obj-$(CONFIG_DRM_MEDIATEK_DP) += mtk-dp.o
diff --git a/drivers/gpu/drm/mediatek/tci.h b/drivers/gpu/drm/mediatek/tci.h
new file mode 100644
index ..f2239ea3ffbf
--- /dev/null
+++ b/drivers/gpu/drm/mediatek/tci.h
@@ -0,0 +1,156 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2019-2024 MediaTek Inc.
+ */
+
+#ifndef _TCI_H_
+#define _TCI_H_
+
+#include 
+
+#define CMD_DEVICE_ADDED1
+#define CMD_DEVICE_REMOVE   2
+#define CMD_WRITE_VAL   3
+#define CMD_DEVICE_CLEAN4
+#define CMD_ENABLE_ENCRYPT  5
+
+/* V1.3 */
+#define CMD_CALCULATE_LM11
+#define CMD_COMPARE_R0  12
+#define CMD_COMPARE_V1  13
+#define CMD_GET_AKSV14
+
+/* V2.2 */
+#define CMD_AKE_CERTIFICATE 20
+#define CMD_ENC_KM  21
+#define CMD_AKE_H_PRIME 22
+#define CMD_AKE_PARING  23
+#define CMD_LC_L_PRIME  24
+#define CMD_COMPARE_L   25
+#define CMD_SKE_CAL_EKS 26
+
+#define CMD_COMPARE_V2  27
+#define CMD_COMPARE_M   28
+
+/* Need remove in furture */
+#define CMD_LOAD_KEY50
+
+#define RET_COMPARE_PASS 0
+#define RET_COMPARE_FAIL 1
+#define RET_NEW_DEVICE 2
+#define RET_STORED_DEVICE 3
+
+#define TYPE_HDCP_PARAM_AN 10
+#define TYPE_HDCP_PARAM_RST_1 11
+#define TYPE_HDCP_PARAM_RST_2 12
+#define TYPE_HDCP_ENABLE_ENCRYPT 13
+#define TYPE_HDCP_DISABLE_ENCRYPT 14
+
+#define TYPE_HDCP13_KEY 20
+#define TYPE_HDCP22_KEY 21
+
+// reserved:2


Please, C-style comments only.


+#define HDCP2_CERTRX_LEN (HDCP_2_2_RECEIVER_ID_LEN + HDCP_2_2_K_PUB_RX_LEN + \
+   2 + HDCP_2_2_DCP_LLC_SIG_LEN)
+// version:1
+#define HDCP_2_2_TXCAPS_LEN (HDCP_2_2_TXCAP_MASK_LEN + 1)
+#define PARAM_LEN 1024
+
+#define TCI_LENGTH sizeof(struct tci_t)
+
+struct cmd_hdcp_init_for_verion_t {
+   u32 version;
+   bool need_load_key;
+};
+
+struct cmd_hdcp_write_val_t {
+   u8 type;
+   u8 len;
+   u8 val[DRM_HDCP_AN_LEN];
+};
+
+struct cmd_hdcp_calculate_lm_t {
+   u8 bksv[DRM_HDCP_KSV_LEN];
+};
+
+struct cmd_hdcp_get_aksv_t {
+   u8 aksv[DRM_HDCP_KSV_LEN];
+};
+
+struct cmd_hdcp_ake_certificate_t {
+   u8 certification[HDCP2_CERTRX_LEN];
+   bool stored;
+   u8 m[HDCP_2_2_E_KH_KM_M_LEN - HDCP_2_2_E_KH_KM_LEN];
+   u8 ekm[HDCP_2_2_E_KH_KM_LEN];
+};
+
+struct cmd_hdcp_ake_paring_t {
+   u8 ekm[HDCP_2_2_E_KH_KM_LEN];
+};
+
+struct cmd_hdcp_enc_km_t {
+   u8 enc_km[HDCP_2_2_E_KPUB_KM_LEN];
+};
+
+struct cmd_hdcp_ake_h_prime_t {
+   u8 rtx[HDCP_2_2_RTX_LEN];
+   u8 rrx[HDCP_2_2_RRX_LEN];
+   u8 rx_caps[HDCP_2_2_RXCAPS_LEN];
+   u8 tx_caps[HDCP_2_2_TXCAPS_LEN];
+   u32 rx_h_len;
+   u8 rx_h[HDCP_2_2_H_PRIME_LEN];
+};
+
+struct cmd_hdcp_lc_l_prime_t {
+   u8 rn[HDCP_2_2_RN_LEN];
+   u32 rx_l_len;
+   u8 rx_l[HDCP_2_2_L_PRIME_LEN];
+};
+
+struct cmd_hdcp_ske_eks_t {
+   u8 riv[HDCP_2_2_RIV_LEN];
+   u32 eks_len;
+   u32 eks;
+};
+
+struct cmd_hdcp_compare_t {
+   u32 rx_val_len;
+   u8 rx_val[HDCP_2_2_MPRIME_LEN];
+   u32 param_len;
+   u8 param[PARAM_LEN];
+   u32 out_len;
+   u32 out;
+};
+
+union tci_cmd_body_t {
+   /* Init with special HDCP version */
+   struct cmd_hdcp_init_for_verion_t cmd_hdcp_init_for_verion;
+   /* Write uint32 data to hw */
+   struct cmd_hdcp_write_val_t cmd_hdcp_write_val;
+   /* Get aksv */
+   struct cmd_hdcp_get_aksv_t cmd_hdcp_get_aksv;
+   /* Calculate

Re: [PATCH v2 1/3] Subject: [PATCH] drm/mediatek/dp: Add tee client application for HDCP feature

2024-02-05 Thread kernel test robot

Hi mac.shen,

kernel test robot noticed the following build warnings:

[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on pza/reset/next linus/master v6.8-rc3 next-20240205]
[cannot apply to pza/imx-drm/next]
[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#_base_tree_information]

url:
https://github.com/intel-lab-lkp/linux/commits/mac-shen/Subject-PATCH-drm-mediatek-dp-Add-tee-client-application-for-HDCP-feature/20240205-163727
base:   git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
patch link:
https://lore.kernel.org/r/20240205055055.25340-2-mac.shen%40mediatek.com
patch subject: [PATCH v2 1/3] Subject: [PATCH] drm/mediatek/dp: Add tee client 
application for HDCP feature
config: arm64-defconfig 
(https://download.01.org/0day-ci/archive/20240205/202402052342.y5awt1t2-...@intel.com/config)
compiler: aarch64-linux-gcc (GCC) 13.2.0
reproduce (this is a W=1 build): 
(https://download.01.org/0day-ci/archive/20240205/202402052342.y5awt1t2-...@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot 
| Closes: 
https://lore.kernel.org/oe-kbuild-all/202402052342.y5awt1t2-...@intel.com/

All warnings (new ones prefixed by >>):

>> drivers/gpu/drm/mediatek/tlc_dp_hdcp.c:34: warning: Function parameter or 
>> struct member 'dp_tee_priv' not described in 'dp_tee_op_send'
>> drivers/gpu/drm/mediatek/tlc_dp_hdcp.c:34: warning: Function parameter or 
>> struct member 'cmd_id' not described in 'dp_tee_op_send'


vim +34 drivers/gpu/drm/mediatek/tlc_dp_hdcp.c

13  
14  /*
15   * TA_FTPM_UUID: 99975014-3c7c-54ea-8487-a80d215ea92c
16   *
17   * Randomly generated, and must correspond to the GUID on the TA side.
18   * Defined here in the reference implementation:
19   * 
https://github.com/microsoft/ms-tpm-20-ref/blob/master/Samples/ARM32-FirmwareTPM/optee_ta/fTPM/include/fTPM.h#L42
20   */
21  static const uuid_t dp_ta_uuid =
22  UUID_INIT(0x99975014, 0x3c7c, 0x54ea,
230x84, 0x87, 0xa8, 0x0d, 0x21, 0x5e, 0xa9, 0x2c);
24  
25  /**
26   * dp_tee_op_send() - send dp commands through the TEE shared memory.
27   * @len:the number of bytes to send.
28   *
29   * Return:
30   *  In case of success, returns 0.
31   *  On failure, -errno
32   */
33  static int dp_tee_op_send(struct dp_tee_private *dp_tee_priv, size_t 
len, u32 cmd_id)
  > 34  {
35  int rc;
36  u8 *temp_buf;
37  struct tee_ioctl_invoke_arg transceive_args;
38  struct tee_param command_params[4];
39  struct tee_shm *shm = dp_tee_priv->shm;
40  
41  if (len > MAX_COMMAND_SIZE) {
42  TLCERR("%s: len=%zd exceeds MAX_COMMAND_SIZE supported 
by dp TA\n", __func__, len);
43  return -EIO;
44  }
45  
46  memset(_args, 0, sizeof(transceive_args));
47  memset(command_params, 0, sizeof(command_params));
48  dp_tee_priv->resp_len = 0;
49  
50  /* Invoke FTPM_OPTEE_TA_SUBMIT_COMMAND function of dp TA */
51  transceive_args = (struct tee_ioctl_invoke_arg) {
52  .func = cmd_id,
53  .session = dp_tee_priv->session,
54  .num_params = 4,
55  };
56  
57  /* Fill FTPM_OPTEE_TA_SUBMIT_COMMAND parameters */
58  command_params[0] = (struct tee_param) {
59  .attr = TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_INPUT,
60  .u.memref = {
61  .shm = shm,
62  .size = len,
63  .shm_offs = 0,
64  },
65  };
66  
67  command_params[1] = (struct tee_param) {
68  .attr = TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_INOUT,
69  .u.memref = {
70  .shm = shm,
71  .size = MAX_RESPONSE_SIZE,
72  .shm_offs = MAX_COMMAND_SIZE,
73  },
74  };
75  
76  rc = tee_client_invoke_func(dp_tee_priv->ctx, _args, 
command_params);
77  if (rc < 0 || transceive_args.ret != 0) {
78  TLCERR("%s: invoke error: 0x%x\n", __func__, 
transceive_args.ret);
79  return (rc < 0) ? rc : transceive_args.ret;
80  }
81  
82  temp_buf = tee_shm_get_va(shm, 
command_params[1].u.memref.shm_offs);
83  if (IS_ERR(temp_buf)) {
84

[PATCH v2 2/3] Subject: [PATCH] drm/mediatek/dp: Add HDCP2.x feature for DisplayPort

2024-02-04 Thread mac . shen

Add HDCP2.x feature for DisplayPort.
When userspace request the kernel protect future content communicated
over the link with Content_Protection property, the feature will do
HDCP2.x authentication if the sink support HDCP2.X.

Changes in v2:
- remove switch case, and refine code to make more clear
- remove some definitions, and use the definitions in
  include/drm/drm_hdcp.h
- use the struct which defined in include/drm/drm_hdcp.h
- do HDCP2.x authentication when userspace request the
  kernel protect future content communicated
per suggestion from the previous thread:
https://lore.kernel.org/all/8fff59b5567449d8201dd1138c8fa
9218a545c46.ca...@mediatek.com/

Signed-off-by: mac.shen 
---
 drivers/gpu/drm/mediatek/Makefile   |1 +
 drivers/gpu/drm/mediatek/mtk_dp.c   |  297 +--
 drivers/gpu/drm/mediatek/mtk_dp.h   |   99 +++
 drivers/gpu/drm/mediatek/mtk_dp_hdcp2.c | 1021 +++
 drivers/gpu/drm/mediatek/mtk_dp_hdcp2.h |   52 ++
 drivers/gpu/drm/mediatek/mtk_dp_reg.h   |4 +-
 drivers/gpu/drm/mediatek/mtk_dpi.c  |3 +
 7 files changed, 1392 insertions(+), 85 deletions(-)
 create mode 100644 drivers/gpu/drm/mediatek/mtk_dp.h
 create mode 100644 drivers/gpu/drm/mediatek/mtk_dp_hdcp2.c
 create mode 100644 drivers/gpu/drm/mediatek/mtk_dp_hdcp2.h

diff --git a/drivers/gpu/drm/mediatek/Makefile 
b/drivers/gpu/drm/mediatek/Makefile
index c80e6c2f9336..50ea069b047e 100644
--- a/drivers/gpu/drm/mediatek/Makefile
+++ b/drivers/gpu/drm/mediatek/Makefile
@@ -27,6 +27,7 @@ mediatek-drm-hdmi-objs := mtk_cec.o \
 obj-$(CONFIG_DRM_MEDIATEK_HDMI) += mediatek-drm-hdmi.o
 
 mtk-dp-objs := tlc_dp_hdcp.o \
+ mtk_dp_hdcp2.o \
  mtk_dp.o
 
 obj-$(CONFIG_DRM_MEDIATEK_DP) += mtk-dp.o
diff --git a/drivers/gpu/drm/mediatek/mtk_dp.c 
b/drivers/gpu/drm/mediatek/mtk_dp.c
index e4c16ba9902d..7ff72f15528b 100644
--- a/drivers/gpu/drm/mediatek/mtk_dp.c
+++ b/drivers/gpu/drm/mediatek/mtk_dp.c
@@ -1,6 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0
 /*
- * Copyright (c) 2019-2022 MediaTek Inc.
+ * Copyright (c) 2019-2024 MediaTek Inc.
  * Copyright (c) 2022 BayLibre
  */
 
@@ -8,13 +8,13 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -30,10 +30,10 @@
 #include 
 #include 
 #include 
-#include 
-#include 
 
+#include "mtk_dp.h"
 #include "mtk_dp_reg.h"
+#include "mtk_dp_hdcp2.h"
 
 #define MTK_DP_SIP_CONTROL_AARCH32 MTK_SIP_SMC_CMD(0x523)
 #define MTK_DP_SIP_ATF_EDP_VIDEO_UNMUTE(BIT(0) | BIT(5))
@@ -52,43 +52,6 @@
 #define MTK_DP_VERSION 0x11
 #define MTK_DP_SDP_AUI 0x4
 
-enum {
-   MTK_DP_CAL_GLB_BIAS_TRIM = 0,
-   MTK_DP_CAL_CLKTX_IMPSE,
-   MTK_DP_CAL_LN_TX_IMPSEL_PMOS_0,
-   MTK_DP_CAL_LN_TX_IMPSEL_PMOS_1,
-   MTK_DP_CAL_LN_TX_IMPSEL_PMOS_2,
-   MTK_DP_CAL_LN_TX_IMPSEL_PMOS_3,
-   MTK_DP_CAL_LN_TX_IMPSEL_NMOS_0,
-   MTK_DP_CAL_LN_TX_IMPSEL_NMOS_1,
-   MTK_DP_CAL_LN_TX_IMPSEL_NMOS_2,
-   MTK_DP_CAL_LN_TX_IMPSEL_NMOS_3,
-   MTK_DP_CAL_MAX,
-};
-
-struct mtk_dp_train_info {
-   bool sink_ssc;
-   bool cable_plugged_in;
-   /* link_rate is in multiple of 0.27Gbps */
-   int link_rate;
-   int lane_count;
-   unsigned int channel_eq_pattern;
-};
-
-struct mtk_dp_audio_cfg {
-   bool detect_monitor;
-   int sad_count;
-   int sample_rate;
-   int word_length_bits;
-   int channels;
-};
-
-struct mtk_dp_info {
-   enum dp_pixelformat format;
-   struct videomode vm;
-   struct mtk_dp_audio_cfg audio_cur_cfg;
-};
-
 struct mtk_dp_efuse_fmt {
unsigned short idx;
unsigned short shift;
@@ -98,44 +61,6 @@ struct mtk_dp_efuse_fmt {
unsigned short default_val;
 };
 
-struct mtk_dp {
-   bool enabled;
-   bool need_debounce;
-   int irq;
-   u8 max_lanes;
-   u8 max_linkrate;
-   u8 rx_cap[DP_RECEIVER_CAP_SIZE];
-   u32 cal_data[MTK_DP_CAL_MAX];
-   u32 irq_thread_handle;
-   /* irq_thread_lock is used to protect irq_thread_handle */
-   spinlock_t irq_thread_lock;
-
-   struct device *dev;
-   struct drm_bridge bridge;
-   struct drm_bridge *next_bridge;
-   struct drm_connector *conn;
-   struct drm_device *drm_dev;
-   struct drm_dp_aux aux;
-
-   const struct mtk_dp_data *data;
-   struct mtk_dp_info info;
-   struct mtk_dp_train_info train_info;
-
-   struct platform_device *phy_dev;
-   struct phy *phy;
-   struct regmap *regs;
-   struct timer_list debounce_timer;
-
-   /* For audio */
-   bool audio_enable;
-   hdmi_codec_plugged_cb plugged_cb;
-   struct platform_device *audio_pdev;
-
-   struct device *codec_dev;
-   /* protect the plugged_cb as it's used in both bridge ops and audio */
-   struct mutex update_plugged_status_lock;
-};
-
 struct mtk_dp_data {
int bridge_type;
unsigned int

[PATCH v2 1/3] Subject: [PATCH] drm/mediatek/dp: Add tee client application for HDCP feature

2024-02-04 Thread mac . shen

Add tee client application which will be used for
HDCP 1.x and 2.x authentication in DisplayPort.

Changes in v2:
- remove ca folder, and change file name with lower case
- refine the tci_t structure to make the data to tee can
  through this structure
- remove aux and regs from mtk_hdcp_info structure
- remove some definitions, and use the definitions in
  include/drm/drm_hdcp.h
- remove useless code
per suggestion from the previous thread:
https://lore.kernel.org/all/8fff59b5567449d8201dd1138c8fa
9218a545c46.ca...@mediatek.com/

Signed-off-by: mac.shen 
---
 drivers/gpu/drm/mediatek/Makefile  |   5 +-
 drivers/gpu/drm/mediatek/tci.h | 156 +++
 drivers/gpu/drm/mediatek/tlc_dp_hdcp.c | 598 +
 drivers/gpu/drm/mediatek/tlc_dp_hdcp.h | 414 +
 4 files changed, 1172 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/mediatek/tci.h
 create mode 100644 drivers/gpu/drm/mediatek/tlc_dp_hdcp.c
 create mode 100644 drivers/gpu/drm/mediatek/tlc_dp_hdcp.h

diff --git a/drivers/gpu/drm/mediatek/Makefile 
b/drivers/gpu/drm/mediatek/Makefile
index d4d193f60271..c80e6c2f9336 100644
--- a/drivers/gpu/drm/mediatek/Makefile
+++ b/drivers/gpu/drm/mediatek/Makefile
@@ -26,4 +26,7 @@ mediatek-drm-hdmi-objs := mtk_cec.o \
 
 obj-$(CONFIG_DRM_MEDIATEK_HDMI) += mediatek-drm-hdmi.o
 
-obj-$(CONFIG_DRM_MEDIATEK_DP) += mtk_dp.o
+mtk-dp-objs := tlc_dp_hdcp.o \
+ mtk_dp.o
+
+obj-$(CONFIG_DRM_MEDIATEK_DP) += mtk-dp.o
diff --git a/drivers/gpu/drm/mediatek/tci.h b/drivers/gpu/drm/mediatek/tci.h
new file mode 100644
index ..f2239ea3ffbf
--- /dev/null
+++ b/drivers/gpu/drm/mediatek/tci.h
@@ -0,0 +1,156 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2019-2024 MediaTek Inc.
+ */
+
+#ifndef _TCI_H_
+#define _TCI_H_
+
+#include 
+
+#define CMD_DEVICE_ADDED1
+#define CMD_DEVICE_REMOVE   2
+#define CMD_WRITE_VAL   3
+#define CMD_DEVICE_CLEAN4
+#define CMD_ENABLE_ENCRYPT  5
+
+/* V1.3 */
+#define CMD_CALCULATE_LM11
+#define CMD_COMPARE_R0  12
+#define CMD_COMPARE_V1  13
+#define CMD_GET_AKSV14
+
+/* V2.2 */
+#define CMD_AKE_CERTIFICATE 20
+#define CMD_ENC_KM  21
+#define CMD_AKE_H_PRIME 22
+#define CMD_AKE_PARING  23
+#define CMD_LC_L_PRIME  24
+#define CMD_COMPARE_L   25
+#define CMD_SKE_CAL_EKS 26
+
+#define CMD_COMPARE_V2  27
+#define CMD_COMPARE_M   28
+
+/* Need remove in furture */
+#define CMD_LOAD_KEY50
+
+#define RET_COMPARE_PASS 0
+#define RET_COMPARE_FAIL 1
+#define RET_NEW_DEVICE 2
+#define RET_STORED_DEVICE 3
+
+#define TYPE_HDCP_PARAM_AN 10
+#define TYPE_HDCP_PARAM_RST_1 11
+#define TYPE_HDCP_PARAM_RST_2 12
+#define TYPE_HDCP_ENABLE_ENCRYPT 13
+#define TYPE_HDCP_DISABLE_ENCRYPT 14
+
+#define TYPE_HDCP13_KEY 20
+#define TYPE_HDCP22_KEY 21
+
+// reserved:2
+#define HDCP2_CERTRX_LEN (HDCP_2_2_RECEIVER_ID_LEN + HDCP_2_2_K_PUB_RX_LEN + \
+   2 + HDCP_2_2_DCP_LLC_SIG_LEN)
+// version:1
+#define HDCP_2_2_TXCAPS_LEN (HDCP_2_2_TXCAP_MASK_LEN + 1)
+#define PARAM_LEN 1024
+
+#define TCI_LENGTH sizeof(struct tci_t)
+
+struct cmd_hdcp_init_for_verion_t {
+   u32 version;
+   bool need_load_key;
+};
+
+struct cmd_hdcp_write_val_t {
+   u8 type;
+   u8 len;
+   u8 val[DRM_HDCP_AN_LEN];
+};
+
+struct cmd_hdcp_calculate_lm_t {
+   u8 bksv[DRM_HDCP_KSV_LEN];
+};
+
+struct cmd_hdcp_get_aksv_t {
+   u8 aksv[DRM_HDCP_KSV_LEN];
+};
+
+struct cmd_hdcp_ake_certificate_t {
+   u8 certification[HDCP2_CERTRX_LEN];
+   bool stored;
+   u8 m[HDCP_2_2_E_KH_KM_M_LEN - HDCP_2_2_E_KH_KM_LEN];
+   u8 ekm[HDCP_2_2_E_KH_KM_LEN];
+};
+
+struct cmd_hdcp_ake_paring_t {
+   u8 ekm[HDCP_2_2_E_KH_KM_LEN];
+};
+
+struct cmd_hdcp_enc_km_t {
+   u8 enc_km[HDCP_2_2_E_KPUB_KM_LEN];
+};
+
+struct cmd_hdcp_ake_h_prime_t {
+   u8 rtx[HDCP_2_2_RTX_LEN];
+   u8 rrx[HDCP_2_2_RRX_LEN];
+   u8 rx_caps[HDCP_2_2_RXCAPS_LEN];
+   u8 tx_caps[HDCP_2_2_TXCAPS_LEN];
+   u32 rx_h_len;
+   u8 rx_h[HDCP_2_2_H_PRIME_LEN];
+};
+
+struct cmd_hdcp_lc_l_prime_t {
+   u8 rn[HDCP_2_2_RN_LEN];
+   u32 rx_l_len;
+   u8 rx_l[HDCP_2_2_L_PRIME_LEN];
+};
+
+struct cmd_hdcp_ske_eks_t {
+   u8 riv[HDCP_2_2_RIV_LEN];
+   u32 eks_len;
+   u32 eks;
+};
+
+struct cmd_hdcp_compare_t {
+   u32 rx_val_len;
+   u8 rx_val[HDCP_2_2_MPRIME_LEN];
+   u32 param_len;
+   u8 param[PARAM_LEN];
+   u32 out_len;
+   u32 out;
+};
+
+union tci_cmd_body_t {
+   /* Init with special HDCP version */
+   struct cmd_hdcp_init_for_verion_t cmd_hdcp_init_for_verion;
+   /* Write uint32 data to hw */
+   struct cmd_hdcp_write_val_t cmd_hdcp_write_val;
+   /* Get aksv */
+   struct cmd_hdcp_get_aksv_t cmd_hdcp_get_aksv;
+   /* Calculate r0 */
+   struct cmd_hdcp_calculate_lm_t cmd_hdcp_calculate_lm;
+   /* Generate

[PATCH v2 3/3] Subject: [PATCH] drm/mediatek/dp: Add HDCP1.x feature for DisplayPort

2024-02-04 Thread mac . shen

Add HDCP1.x feature for DisplayPort.
If the sink support HDCP1.X only, the feature will do HDCP1.x
authentication when userspace request the kernel protect with
HDCP_Content_Type property as DRM_MODE_HDCP_CONTENT_TYPE0.

Changes in v2:
- remove useless code
- remove the prefix 'mdrv'
- do HDCP1.x authentication when userspace request the
  kernel protect future content communicated
per suggestion from the previous thread:
https://lore.kernel.org/all/8fff59b5567449d8201dd1138c8
fa9218a545c46.ca...@mediatek.com/

Signed-off-by: mac.shen 
---
 drivers/gpu/drm/mediatek/Makefile|   1 +
 drivers/gpu/drm/mediatek/mtk_dp.c|  33 +-
 drivers/gpu/drm/mediatek/mtk_dp_hdcp1x.c | 589 +++
 drivers/gpu/drm/mediatek/mtk_dp_hdcp1x.h |  46 ++
 drivers/gpu/drm/mediatek/mtk_dp_reg.h|   3 +
 5 files changed, 669 insertions(+), 3 deletions(-)
 create mode 100644 drivers/gpu/drm/mediatek/mtk_dp_hdcp1x.c
 create mode 100644 drivers/gpu/drm/mediatek/mtk_dp_hdcp1x.h

diff --git a/drivers/gpu/drm/mediatek/Makefile 
b/drivers/gpu/drm/mediatek/Makefile
index 50ea069b047e..9738235f76b8 100644
--- a/drivers/gpu/drm/mediatek/Makefile
+++ b/drivers/gpu/drm/mediatek/Makefile
@@ -27,6 +27,7 @@ mediatek-drm-hdmi-objs := mtk_cec.o \
 obj-$(CONFIG_DRM_MEDIATEK_HDMI) += mediatek-drm-hdmi.o
 
 mtk-dp-objs := tlc_dp_hdcp.o \
+ mtk_dp_hdcp1x.o \
  mtk_dp_hdcp2.o \
  mtk_dp.o
 
diff --git a/drivers/gpu/drm/mediatek/mtk_dp.c 
b/drivers/gpu/drm/mediatek/mtk_dp.c
index 7ff72f15528b..8cd7562dab7a 100644
--- a/drivers/gpu/drm/mediatek/mtk_dp.c
+++ b/drivers/gpu/drm/mediatek/mtk_dp.c
@@ -33,6 +33,7 @@
 
 #include "mtk_dp.h"
 #include "mtk_dp_reg.h"
+#include "mtk_dp_hdcp1x.h"
 #include "mtk_dp_hdcp2.h"
 
 #define MTK_DP_SIP_CONTROL_AARCH32 MTK_SIP_SMC_CMD(0x523)
@@ -1811,6 +1812,9 @@ void mtk_dp_check_hdcp_version(struct mtk_dp *mtk_dp, 
bool only_hdcp1x)
if (!only_hdcp1x && dp_tx_hdcp2_support(_dp->hdcp_info))
return;
 
+   if (dp_tx_hdcp1x_support(_dp->hdcp_info))
+   return;
+
if (tee_add_device(_dp->hdcp_info, HDCP_NONE) != RET_SUCCESS)
mtk_dp->hdcp_info.auth_status = AUTH_FAIL;
 }
@@ -1860,15 +1864,34 @@ static void mtk_dp_hdcp_handle(struct work_struct *data)
mtk_dp_check_hdcp_version(mtk_dp, false);
if (mtk_dp->hdcp_info.hdcp2_info.enable)
dp_tx_hdcp2_set_start_auth(_dp->hdcp_info, true);
+   else if (mtk_dp->hdcp_info.hdcp1x_info.enable &&
+mtk_dp->hdcp_info.hdcp_content_type != 
DRM_MODE_HDCP_CONTENT_TYPE1)
+   dp_tx_hdcp1x_set_start_auth(_dp->hdcp_info, true);
else
mtk_dp->hdcp_info.auth_status = AUTH_ZERO;
}
 
-   while (mtk_dp->hdcp_info.hdcp2_info.enable &&
-  mtk_dp->hdcp_info.auth_status != AUTH_FAIL &&
+   while ((mtk_dp->hdcp_info.hdcp1x_info.enable ||
+   mtk_dp->hdcp_info.hdcp2_info.enable) &&
+   mtk_dp->hdcp_info.auth_status != AUTH_FAIL &&
mtk_dp->hdcp_info.auth_status != AUTH_PASS) {
-   if (mtk_dp->hdcp_info.hdcp2_info.enable)
+   if (mtk_dp->hdcp_info.hdcp2_info.enable) {
dp_tx_hdcp2_fsm(_dp->hdcp_info);
+   if (mtk_dp->hdcp_info.auth_status == AUTH_FAIL) {
+   tee_remove_device(_dp->hdcp_info);
+   mtk_dp_check_hdcp_version(mtk_dp, true);
+   if (mtk_dp->hdcp_info.hdcp1x_info.enable &&
+   mtk_dp->hdcp_info.hdcp_content_type !=
+   DRM_MODE_HDCP_CONTENT_TYPE1) {
+   mtk_dp->hdcp_info.hdcp2_info.enable = 
false;
+   
dp_tx_hdcp1x_set_start_auth(_dp->hdcp_info, true);
+   }
+   }
+   }
+
+   if (mtk_dp->hdcp_info.hdcp1x_info.enable &&
+   mtk_dp->hdcp_info.hdcp_content_type != 
DRM_MODE_HDCP_CONTENT_TYPE1)
+   dp_tx_hdcp1x_fsm(_dp->hdcp_info);
}
 }
 
@@ -1924,6 +1947,8 @@ static void mtk_dp_hdcp_atomic_check(struct mtk_dp 
*mtk_dp, struct drm_connector
dev_dbg(mtk_dp->dev, "disable HDCP\n");
if (mtk_dp->hdcp_info.hdcp2_info.enable)
dp_tx_hdcp2_set_start_auth(_dp->hdcp_info, false);
+   else if (mtk_dp->hdcp_info.hdcp1x_info.enable)
+   dp_tx_hdcp1x_set_start_auth(_dp->hdcp_info, false);
 
drm_hdcp_update_content_protection(mtk_dp->conn,
   
mtk_dp->hdcp_info.content_protection);
@@ -2394,6 +2419,8 @@ static void mtk_dp_bridge_atomic_disable(struct 
drm_bridge *bridge,
 
if

[no subject]

2024-02-02 Thread Marek Szyprowski

Subject: [PATCH] ARM: multi_v7_defconfig: Enable BACKLIGHT_CLASS_DEVICE

Commit 72fee6b0a3a4 ("fbdev: Restrict FB_SH_MOBILE_LCDC to SuperH")
disabled availablity of the SH_MOBILE_LCDC driver on the RENESAS arch.
This innocent change has a significant side-effect on the ARM's
multi_v7_defconfig, because FB_BACKLIGHT symbol is no longer selected,
what in turn leaves BACKLIGHT_CLASS_DEVICE symbol selected only as
a module. The latter disables some backlight related code in the DRM
core, because the DRM core is set to be compiled-in in this defconfig.
This leaves all DRM display panels without integrated backlight control,
even if the needed modules have been properly loaded and probed.

Fix this by selecting BACKLIGHT_CLASS_DEVICE to be compiled-in in
multi_v7_defconfig.

Signed-off-by: Marek Szyprowski 
---
 arch/arm/configs/multi_v7_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/multi_v7_defconfig 
b/arch/arm/configs/multi_v7_defconfig
index 8f7445729cd0..b2955dcb5a53 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -777,6 +777,7 @@ CONFIG_FB_EFI=y
 CONFIG_FB_WM8505=y
 CONFIG_FB_SH_MOBILE_LCDC=y
 CONFIG_FB_SIMPLE=y
+CONFIG_BACKLIGHT_CLASS_DEVICE=y
 CONFIG_BACKLIGHT_PWM=y
 CONFIG_BACKLIGHT_AS3711=y
 CONFIG_BACKLIGHT_GPIO=y
-- 
2.34.1

[no subject]

2023-11-11 Thread Andrew Worsley

   This patch fix's the failure of the frame buffer driver on my Asahi kernel
which prevented X11 from starting on my Apple M1 laptop. It seems like a 
straight
forward failure to follow the procedure described in drivers/video/aperture.c
to remove the ealier driver. This patch is very simple and minimal. Very likely
there may be better ways to fix this and very like there may be other drivers
which have the same problem but I submit this so at least there is
an interim fix for my problem.

Thanks

Andrew Worsley

[no subject]

2023-08-07 Thread Brandon Pollack

Any progress on this?  Is it ok if yi...@chromium.org and I do the
followups on this patch so that we can also submit the Hotplug patch I
wrote (that's now archived?).

[no subject]

2023-03-11 Thread Danila Chernetsov

Date: Sat, 11 Mar 2023 19:00:03 +
Subject: [PATCH 5.10 1/1] drm/amdgpu: add error handling for 
drm_fb_helper_initial_config

The type of return value of drm_fb_helper_initial_config is int, which may 
return wrong result, so we add error handling for it to reclaim memory resource,
and return when an error occurs.   

Found by Linux Verification Center (linuxtesting.org) with SVACE.

Fixes: d38ceaf99ed0 (drm/amdgpu: add core driver (v4))
Signed-off-by: Danila Chernetsov 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
index 43f29ee0e3b0..e445a2c9f569 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
@@ -348,8 +348,17 @@ int amdgpu_fbdev_init(struct amdgpu_device *adev)
if (!amdgpu_device_has_dc_support(adev))
drm_helper_disable_unused_functions(adev_to_drm(adev));
 
-   drm_fb_helper_initial_config(>helper, bpp_sel);
-   return 0;
+   ret = drm_fb_helper_initial_config(>helper, bpp_sel);
+   if (ret)
+   goto fini;
+
+   return 0;
+
+fini:
+   drm_fb_helper_fini(>helper);
+
+   kfree(rfbdev);
+   return ret;
 }
 
 void amdgpu_fbdev_fini(struct amdgpu_device *adev)
-- 
2.25.1

[no subject]

2022-12-06 Thread Denis Arefev

Date: Thu, 10 Nov 2022 16:47:26 +0300
Subject: [PATCH] drm/amdgpu/display: Add pointer check

Return value of a function 'dc_create_state' is
dereferenced at amdgpu_dm.c:2027 without checking for null

Found by Linux Verification Center (linuxtesting.org) with SVACE.

Signed-off-by: Denis Arefev 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 0f7749e9424d..529483997154 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -1960,7 +1960,9 @@ static int dm_resume(void *handle)
dc_release_state(dm_state->context);
dm_state->context = dc_create_state(dm->dc);
/* TODO: Remove dc_state->dccg, use dc->dccg directly. */
-   dc_resource_state_construct(dm->dc, dm_state->context);
+   if (dm_state->context) {
+   dc_resource_state_construct(dm->dc, dm_state->context);
+   }
 
/* Before powering on DC we need to re-initialize DMUB. */
r = dm_dmub_hw_init(adev);
-- 
2.25.1

[no subject]

2022-11-22 Thread Denis Arefev

Date: Tue, 22 Nov 2022 15:51:44 +0300
Subject: [PATCH] powerplay: hwmgr: added result check

The return value of the 'div64_s64'
function called in ppevvmath.h:371
was not checked.

Found by Linux Verification Center (linuxtesting.org) with SVACE.

Signed-off-by: Denis Arefev 
---
 drivers/gpu/drm/amd/pm/powerplay/hwmgr/ppevvmath.h | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/ppevvmath.h 
b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/ppevvmath.h
index dac29fe6cfc6..82aa7130d143 100644
--- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/ppevvmath.h
+++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/ppevvmath.h
@@ -357,6 +357,7 @@ static fInt fDivide (fInt X, fInt Y)
 {
fInt fZERO, fQuotient;
int64_t longlongX, longlongY;
+   int64_t result;
 
fZERO = ConvertToFraction(0);
 
@@ -367,10 +368,11 @@ static fInt fDivide (fInt X, fInt Y)
longlongY = (int64_t)Y.full;
 
longlongX = longlongX << 16; /*Q(16,16) -> Q(32,32) */
+   longlongY = longlongY << 16;
 
-   div64_s64(longlongX, longlongY); /*Q(32,32) divided by Q(16,16) = 
Q(16,16) Back to original format */
+   result = div64_s64(longlongX, longlongY);
 
-   fQuotient.full = (int)longlongX;
+   fQuotient = ConvertToFraction((int)result);
return fQuotient;
 }
 
-- 
2.25.1

Subject: [PATCH] driver: gpu: add failure check for ftell

2022-10-30 Thread 沈言峰

add return-value check of ftell to improve robustness(and avoid abnormal 
behavior)

Signed-off-by: SPeak 
Signed-off-by: shenyanfeng 
---
 drivers/gpu/drm/radeon/mkregtable.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/mkregtable.c 
b/drivers/gpu/drm/radeon/mkregtable.c
index 52a7246fe..c31c58e5f 100644
--- a/drivers/gpu/drm/radeon/mkregtable.c
+++ b/drivers/gpu/drm/radeon/mkregtable.c
@@ -193,6 +193,7 @@ static int parser_auth(struct table *t, const char 
*filename)
  regmatch_t match[4];
  char buf[1024];
  size_t end;
+ long pos;
  int len;
  int done = 0;
  int r;
@@ -228,12 +229,12 @@ static int parser_auth(struct table *t, const char 
*filename)
  last_reg = strtol(last_reg_s, NULL, 16);

  do {
- if (fgets(buf, 1024, file) == NULL) {
+ if ((fgets(buf, 1024, file) == NULL) || (pos = ftell(file)) < 0) {
  fclose(file);
  return -1;
  }
  len = strlen(buf);
- if (ftell(file) == end)
+ if (pos == end)
  done = 1;
  if (len) {
  r = regexec(_rex, buf, 4, match, 0);
--
2.37.2

#/**本邮件及其附件含有小米公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
 This e-mail and its attachments contain confidential information from XIAOMI, 
which is intended only for the person or entity whose address is listed above. 
Any use of the information contained herein in any way (including, but not 
limited to, total or partial disclosure, reproduction, or dissemination) by 
persons other than the intended recipient(s) is prohibited. If you receive this 
e-mail in error, please notify the sender by phone or email immediately and 
delete it!**/#

[no subject]

2022-05-19 Thread Christian König

Just sending that out once more to intel-gfx to let the CI systems take
a look.

No functional change compared to the last version.

Christian.

[no subject]

2022-05-18 Thread Christian König

Just sending that to intel-gfx to let the CI systems take a look at it.

Regards,
Christian.

[no subject]

2022-05-05 Thread Dave Airlie

Hey Linus,

pretty quiet week, one fbdev, msm, kconfig, and 2 amdgpu fixes, about
what I'd expect for rc6.

Regards,
Dave.

drm-fixes-2022-05-06:
drm fixes for 5.18-rc6

fbdev:
- hotunplugging fix

amdgpu:
- Fix a xen dom0 regression on APUs
- Fix a potential array overflow if a receiver were to
  send an erroneous audio channel count

msm:
- lockdep fix.

it6505:
- kconfig fix
The following changes since commit 672c0c5173427e6b3e2a9bbb7be51ceeec78093a:

  Linux 5.18-rc5 (2022-05-01 13:57:58 -0700)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2022-05-06

for you to fetch changes up to 5727375215b0915f28806c337a7ba9835efd340b:

  Merge tag 'drm-msm-fixes-2022-04-30' of
https://gitlab.freedesktop.org/drm/msm into drm-fixes (2022-05-06
11:22:03 +1000)


drm fixes for 5.18-rc6

fbdev:
- hotunplugging fix

amdgpu:
- Fix a xen dom0 regression on APUs
- Fix a potential array overflow if a receiver were to
  send an erroneous audio channel count

msm:
- lockdep fix.

it6505:
- kconfig fix


Dave Airlie (3):
  Merge tag 'amd-drm-fixes-5.18-2022-05-04' of
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes
  Merge tag 'drm-misc-fixes-2022-05-05' of
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes
  Merge tag 'drm-msm-fixes-2022-04-30' of
https://gitlab.freedesktop.org/drm/msm into drm-fixes

Fabien Parent (1):
  drm/bridge: ite-it6505: add missing Kconfig option select

Harry Wentland (1):
  drm/amd/display: Avoid reading audio pattern past AUDIO_CHANNELS_COUNT

Javier Martinez Canillas (1):
  fbdev: Make fb_release() return -ENODEV if fbdev was unregistered

Kuogee Hsieh (1):
  drm/msm/dp: remove fail safe mode related code

Marek Marczykowski-Górecki (1):
  drm/amdgpu: do not use passthrough mode in Xen dom0

 drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c |  4 +++-
 drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c |  2 +-
 drivers/gpu/drm/bridge/Kconfig   |  1 +
 drivers/gpu/drm/msm/dp/dp_display.c  |  6 --
 drivers/gpu/drm/msm/dp/dp_panel.c| 11 ---
 drivers/gpu/drm/msm/dp/dp_panel.h|  1 -
 drivers/video/fbdev/core/fbmem.c |  5 -
 7 files changed, 9 insertions(+), 21 deletions(-)

[no subject]

2022-04-06 Thread Christian König

Hi Daniel,

rebased on top of all the changes in drm-misc-next now and hopefully
ready for 5.19.

I think I addressed all concern, but there was a bunch of rebase fallout
from i915, so better to double check that once more.

Regards,
Christian.

Re: [PATCH v6 7/9] drm/i915: Reduce the number of objects subject to memcpy recover

2021-09-23 Thread Thomas Hellström




On 9/23/21 11:44 AM, Matthew Auld wrote:

On 22/09/2021 07:25, Thomas Hellström wrote:

We really only need memcpy restore for objects that affect the
operability of the migrate context. That is, primarily the page-table
objects of the migrate VM.

Add an object flag, I915_BO_ALLOC_PM_EARLY for objects that need early
restores using memcpy and a way to assign LMEM page-table object flags
to be used by the vms.

Restore objects without this flag with the gpu blitter and only objects
carrying the flag using TTM memcpy.

Initially mark the migrate, gt, gtt and vgpu vms to use this flag, and
defer for a later audit which vms actually need it. Most importantly, 
user-

allocated vms with pinned page-table objects can be restored using the
blitter.

Performance-wise memcpy restore is probably as fast as gpu restore if 
not

faster, but using gpu restore will help tackling future restrictions in
mappable LMEM size.

v4:
- Don't mark the aliasing ppgtt page table flags for early resume, but
   rather the ggtt page table flags as intended. (Matthew Auld)
- The check for user buffer objects during early resume is pointless, 
since

   they are never marked I915_BO_ALLOC_PM_EARLY. (Matthew Auld)
v5:
- Mark GuC LMEM objects with I915_BO_ALLOC_PM_EARLY to have them 
restored

   before we fire up the migrate context.

Cc: Matthew Brost 
Signed-off-by: Thomas Hellström 
Reviewed-by: Matthew Auld 
---
  drivers/gpu/drm/i915/gem/i915_gem_context.c  |  4 ++--
  drivers/gpu/drm/i915/gem/i915_gem_object_types.h |  9 ++---
  drivers/gpu/drm/i915/gem/i915_gem_pm.c   |  6 +-
  drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c   |  5 +++--
  drivers/gpu/drm/i915/gem/selftests/huge_pages.c  |  2 +-
  drivers/gpu/drm/i915/gt/gen6_ppgtt.c |  2 +-
  drivers/gpu/drm/i915/gt/gen8_ppgtt.c |  5 +++--
  drivers/gpu/drm/i915/gt/gen8_ppgtt.h |  4 +++-
  drivers/gpu/drm/i915/gt/intel_ggtt.c |  3 ++-
  drivers/gpu/drm/i915/gt/intel_gt.c   |  2 +-
  drivers/gpu/drm/i915/gt/intel_gtt.c  |  3 ++-
  drivers/gpu/drm/i915/gt/intel_gtt.h  |  9 +++--
  drivers/gpu/drm/i915/gt/intel_migrate.c  |  2 +-
  drivers/gpu/drm/i915/gt/intel_ppgtt.c    | 13 -
  drivers/gpu/drm/i915/gt/selftest_hangcheck.c |  2 +-
  drivers/gpu/drm/i915/gt/uc/intel_guc.c   |  3 ++-
  drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c |  7 +--
  drivers/gpu/drm/i915/gvt/scheduler.c |  2 +-
  drivers/gpu/drm/i915/selftests/i915_gem_gtt.c    |  4 ++--
  19 files changed, 56 insertions(+), 31 deletions(-)

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

index c2ab0e22db0a..8208fd5b72c3 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1287,7 +1287,7 @@ i915_gem_create_context(struct drm_i915_private 
*i915,

  } else if (HAS_FULL_PPGTT(i915)) {
  struct i915_ppgtt *ppgtt;
  -    ppgtt = i915_ppgtt_create(>gt);
+    ppgtt = i915_ppgtt_create(>gt, 0);
  if (IS_ERR(ppgtt)) {
  drm_dbg(>drm, "PPGTT setup failed (%ld)\n",
  PTR_ERR(ppgtt));
@@ -1465,7 +1465,7 @@ int i915_gem_vm_create_ioctl(struct drm_device 
*dev, void *data,

  if (args->flags)
  return -EINVAL;
  -    ppgtt = i915_ppgtt_create(>gt);
+    ppgtt = i915_ppgtt_create(>gt, 0);
  if (IS_ERR(ppgtt))
  return PTR_ERR(ppgtt);
  diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h 
b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h

index 118691ce81d7..fa2ba9e2a4d0 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -294,13 +294,16 @@ struct drm_i915_gem_object {
  #define I915_BO_ALLOC_USER    BIT(3)
  /* Object is allowed to lose its contents on suspend / resume, even 
if pinned */

  #define I915_BO_ALLOC_PM_VOLATILE BIT(4)
+/* Object needs to be restored early using memcpy during resume */
+#define I915_BO_ALLOC_PM_EARLY    BIT(5)
  #define I915_BO_ALLOC_FLAGS (I915_BO_ALLOC_CONTIGUOUS | \
   I915_BO_ALLOC_VOLATILE | \
   I915_BO_ALLOC_CPU_CLEAR | \
   I915_BO_ALLOC_USER | \
- I915_BO_ALLOC_PM_VOLATILE)
-#define I915_BO_READONLY  BIT(5)
-#define I915_TILING_QUIRK_BIT 6 /* unknown swizzling; do not 
release! */

+ I915_BO_ALLOC_PM_VOLATILE | \
+ I915_BO_ALLOC_PM_EARLY)
+#define I915_BO_READONLY  BIT(6)
+#define I915_TILING_QUIRK_BIT 7 /* unknown swizzling; do not 
release! */

    /**
   * @mem_flags - Mutable placement-related flags
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pm.c 
b/drivers/gpu/drm/i915/gem/i915_gem_pm.c

index 12b37b4c1192..726b40e1fbb0 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
@@ -97,8

Re: [PATCH v6 7/9] drm/i915: Reduce the number of objects subject to memcpy recover

2021-09-23 Thread Matthew Auld


On 22/09/2021 07:25, Thomas Hellström wrote:

We really only need memcpy restore for objects that affect the
operability of the migrate context. That is, primarily the page-table
objects of the migrate VM.

Add an object flag, I915_BO_ALLOC_PM_EARLY for objects that need early
restores using memcpy and a way to assign LMEM page-table object flags
to be used by the vms.

Restore objects without this flag with the gpu blitter and only objects
carrying the flag using TTM memcpy.

Initially mark the migrate, gt, gtt and vgpu vms to use this flag, and
defer for a later audit which vms actually need it. Most importantly, user-
allocated vms with pinned page-table objects can be restored using the
blitter.

Performance-wise memcpy restore is probably as fast as gpu restore if not
faster, but using gpu restore will help tackling future restrictions in
mappable LMEM size.

v4:
- Don't mark the aliasing ppgtt page table flags for early resume, but
   rather the ggtt page table flags as intended. (Matthew Auld)
- The check for user buffer objects during early resume is pointless, since
   they are never marked I915_BO_ALLOC_PM_EARLY. (Matthew Auld)
v5:
- Mark GuC LMEM objects with I915_BO_ALLOC_PM_EARLY to have them restored
   before we fire up the migrate context.

Cc: Matthew Brost 
Signed-off-by: Thomas Hellström 
Reviewed-by: Matthew Auld 
---
  drivers/gpu/drm/i915/gem/i915_gem_context.c  |  4 ++--
  drivers/gpu/drm/i915/gem/i915_gem_object_types.h |  9 ++---
  drivers/gpu/drm/i915/gem/i915_gem_pm.c   |  6 +-
  drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c   |  5 +++--
  drivers/gpu/drm/i915/gem/selftests/huge_pages.c  |  2 +-
  drivers/gpu/drm/i915/gt/gen6_ppgtt.c |  2 +-
  drivers/gpu/drm/i915/gt/gen8_ppgtt.c |  5 +++--
  drivers/gpu/drm/i915/gt/gen8_ppgtt.h |  4 +++-
  drivers/gpu/drm/i915/gt/intel_ggtt.c |  3 ++-
  drivers/gpu/drm/i915/gt/intel_gt.c   |  2 +-
  drivers/gpu/drm/i915/gt/intel_gtt.c  |  3 ++-
  drivers/gpu/drm/i915/gt/intel_gtt.h  |  9 +++--
  drivers/gpu/drm/i915/gt/intel_migrate.c  |  2 +-
  drivers/gpu/drm/i915/gt/intel_ppgtt.c| 13 -
  drivers/gpu/drm/i915/gt/selftest_hangcheck.c |  2 +-
  drivers/gpu/drm/i915/gt/uc/intel_guc.c   |  3 ++-
  drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c |  7 +--
  drivers/gpu/drm/i915/gvt/scheduler.c |  2 +-
  drivers/gpu/drm/i915/selftests/i915_gem_gtt.c|  4 ++--
  19 files changed, 56 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index c2ab0e22db0a..8208fd5b72c3 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1287,7 +1287,7 @@ i915_gem_create_context(struct drm_i915_private *i915,
} else if (HAS_FULL_PPGTT(i915)) {
struct i915_ppgtt *ppgtt;
  
-		ppgtt = i915_ppgtt_create(>gt);

+   ppgtt = i915_ppgtt_create(>gt, 0);
if (IS_ERR(ppgtt)) {
drm_dbg(>drm, "PPGTT setup failed (%ld)\n",
PTR_ERR(ppgtt));
@@ -1465,7 +1465,7 @@ int i915_gem_vm_create_ioctl(struct drm_device *dev, void 
*data,
if (args->flags)
return -EINVAL;
  
-	ppgtt = i915_ppgtt_create(>gt);

+   ppgtt = i915_ppgtt_create(>gt, 0);
if (IS_ERR(ppgtt))
return PTR_ERR(ppgtt);
  
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h

index 118691ce81d7..fa2ba9e2a4d0 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -294,13 +294,16 @@ struct drm_i915_gem_object {
  #define I915_BO_ALLOC_USERBIT(3)
  /* Object is allowed to lose its contents on suspend / resume, even if pinned 
*/
  #define I915_BO_ALLOC_PM_VOLATILE BIT(4)
+/* Object needs to be restored early using memcpy during resume */
+#define I915_BO_ALLOC_PM_EARLYBIT(5)
  #define I915_BO_ALLOC_FLAGS (I915_BO_ALLOC_CONTIGUOUS | \
 I915_BO_ALLOC_VOLATILE | \
 I915_BO_ALLOC_CPU_CLEAR | \
 I915_BO_ALLOC_USER | \
-I915_BO_ALLOC_PM_VOLATILE)
-#define I915_BO_READONLY  BIT(5)
-#define I915_TILING_QUIRK_BIT 6 /* unknown swizzling; do not release! */
+I915_BO_ALLOC_PM_VOLATILE | \
+I915_BO_ALLOC_PM_EARLY)
+#define I915_BO_READONLY  BIT(6)
+#define I915_TILING_QUIRK_BIT 7 /* unknown swizzling; do not release! */
  
  	/**

 * @mem_flags - Mutable placement-related flags
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pm.c 
b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
index 12b37b4c1192..726b40e1fbb0 100644
---

[PATCH v6 7/9] drm/i915: Reduce the number of objects subject to memcpy recover

2021-09-22 Thread Thomas Hellström

We really only need memcpy restore for objects that affect the
operability of the migrate context. That is, primarily the page-table
objects of the migrate VM.

Add an object flag, I915_BO_ALLOC_PM_EARLY for objects that need early
restores using memcpy and a way to assign LMEM page-table object flags
to be used by the vms.

Restore objects without this flag with the gpu blitter and only objects
carrying the flag using TTM memcpy.

Initially mark the migrate, gt, gtt and vgpu vms to use this flag, and
defer for a later audit which vms actually need it. Most importantly, user-
allocated vms with pinned page-table objects can be restored using the
blitter.

Performance-wise memcpy restore is probably as fast as gpu restore if not
faster, but using gpu restore will help tackling future restrictions in
mappable LMEM size.

v4:
- Don't mark the aliasing ppgtt page table flags for early resume, but
  rather the ggtt page table flags as intended. (Matthew Auld)
- The check for user buffer objects during early resume is pointless, since
  they are never marked I915_BO_ALLOC_PM_EARLY. (Matthew Auld)
v5:
- Mark GuC LMEM objects with I915_BO_ALLOC_PM_EARLY to have them restored
  before we fire up the migrate context.

Cc: Matthew Brost 
Signed-off-by: Thomas Hellström 
Reviewed-by: Matthew Auld 
---
 drivers/gpu/drm/i915/gem/i915_gem_context.c  |  4 ++--
 drivers/gpu/drm/i915/gem/i915_gem_object_types.h |  9 ++---
 drivers/gpu/drm/i915/gem/i915_gem_pm.c   |  6 +-
 drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c   |  5 +++--
 drivers/gpu/drm/i915/gem/selftests/huge_pages.c  |  2 +-
 drivers/gpu/drm/i915/gt/gen6_ppgtt.c |  2 +-
 drivers/gpu/drm/i915/gt/gen8_ppgtt.c |  5 +++--
 drivers/gpu/drm/i915/gt/gen8_ppgtt.h |  4 +++-
 drivers/gpu/drm/i915/gt/intel_ggtt.c |  3 ++-
 drivers/gpu/drm/i915/gt/intel_gt.c   |  2 +-
 drivers/gpu/drm/i915/gt/intel_gtt.c  |  3 ++-
 drivers/gpu/drm/i915/gt/intel_gtt.h  |  9 +++--
 drivers/gpu/drm/i915/gt/intel_migrate.c  |  2 +-
 drivers/gpu/drm/i915/gt/intel_ppgtt.c| 13 -
 drivers/gpu/drm/i915/gt/selftest_hangcheck.c |  2 +-
 drivers/gpu/drm/i915/gt/uc/intel_guc.c   |  3 ++-
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c |  7 +--
 drivers/gpu/drm/i915/gvt/scheduler.c |  2 +-
 drivers/gpu/drm/i915/selftests/i915_gem_gtt.c|  4 ++--
 19 files changed, 56 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index c2ab0e22db0a..8208fd5b72c3 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1287,7 +1287,7 @@ i915_gem_create_context(struct drm_i915_private *i915,
} else if (HAS_FULL_PPGTT(i915)) {
struct i915_ppgtt *ppgtt;
 
-   ppgtt = i915_ppgtt_create(>gt);
+   ppgtt = i915_ppgtt_create(>gt, 0);
if (IS_ERR(ppgtt)) {
drm_dbg(>drm, "PPGTT setup failed (%ld)\n",
PTR_ERR(ppgtt));
@@ -1465,7 +1465,7 @@ int i915_gem_vm_create_ioctl(struct drm_device *dev, void 
*data,
if (args->flags)
return -EINVAL;
 
-   ppgtt = i915_ppgtt_create(>gt);
+   ppgtt = i915_ppgtt_create(>gt, 0);
if (IS_ERR(ppgtt))
return PTR_ERR(ppgtt);
 
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h 
b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
index 118691ce81d7..fa2ba9e2a4d0 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -294,13 +294,16 @@ struct drm_i915_gem_object {
 #define I915_BO_ALLOC_USERBIT(3)
 /* Object is allowed to lose its contents on suspend / resume, even if pinned 
*/
 #define I915_BO_ALLOC_PM_VOLATILE BIT(4)
+/* Object needs to be restored early using memcpy during resume */
+#define I915_BO_ALLOC_PM_EARLYBIT(5)
 #define I915_BO_ALLOC_FLAGS (I915_BO_ALLOC_CONTIGUOUS | \
 I915_BO_ALLOC_VOLATILE | \
 I915_BO_ALLOC_CPU_CLEAR | \
 I915_BO_ALLOC_USER | \
-I915_BO_ALLOC_PM_VOLATILE)
-#define I915_BO_READONLY  BIT(5)
-#define I915_TILING_QUIRK_BIT 6 /* unknown swizzling; do not release! */
+I915_BO_ALLOC_PM_VOLATILE | \
+I915_BO_ALLOC_PM_EARLY)
+#define I915_BO_READONLY  BIT(6)
+#define I915_TILING_QUIRK_BIT 7 /* unknown swizzling; do not release! */
 
/**
 * @mem_flags - Mutable placement-related flags
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pm.c 
b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
index 12b37b4c1192..726b40e1fbb0 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
@@

[PATCH v5 7/7] drm/i915: Reduce the number of objects subject to memcpy recover

2021-09-21 Thread Thomas Hellström

We really only need memcpy restore for objects that affect the
operability of the migrate context. That is, primarily the page-table
objects of the migrate VM.

Add an object flag, I915_BO_ALLOC_PM_EARLY for objects that need early
restores using memcpy and a way to assign LMEM page-table object flags
to be used by the vms.

Restore objects without this flag with the gpu blitter and only objects
carrying the flag using TTM memcpy.

Initially mark the migrate, gt, gtt and vgpu vms to use this flag, and
defer for a later audit which vms actually need it. Most importantly, user-
allocated vms with pinned page-table objects can be restored using the
blitter.

Performance-wise memcpy restore is probably as fast as gpu restore if not
faster, but using gpu restore will help tackling future restrictions in
mappable LMEM size.

v4:
- Don't mark the aliasing ppgtt page table flags for early resume, but
  rather the ggtt page table flags as intended. (Matthew Auld)
- The check for user buffer objects during early resume is pointless, since
  they are never marked I915_BO_ALLOC_PM_EARLY. (Matthew Auld)
v5:
- Mark GuC LMEM objects with I915_BO_ALLOC_PM_EARLY to have them restored
  before we fire up the migrate context.

Cc: Matthew Brost 
Signed-off-by: Thomas Hellström 
Reviewed-by: Matthew Auld 
---
 drivers/gpu/drm/i915/gem/i915_gem_context.c  |  4 ++--
 drivers/gpu/drm/i915/gem/i915_gem_object_types.h |  9 ++---
 drivers/gpu/drm/i915/gem/i915_gem_pm.c   |  6 +-
 drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c   |  5 +++--
 drivers/gpu/drm/i915/gem/selftests/huge_pages.c  |  2 +-
 drivers/gpu/drm/i915/gt/gen6_ppgtt.c |  2 +-
 drivers/gpu/drm/i915/gt/gen8_ppgtt.c |  5 +++--
 drivers/gpu/drm/i915/gt/gen8_ppgtt.h |  4 +++-
 drivers/gpu/drm/i915/gt/intel_ggtt.c |  3 ++-
 drivers/gpu/drm/i915/gt/intel_gt.c   |  2 +-
 drivers/gpu/drm/i915/gt/intel_gtt.c  |  3 ++-
 drivers/gpu/drm/i915/gt/intel_gtt.h  |  9 +++--
 drivers/gpu/drm/i915/gt/intel_migrate.c  |  2 +-
 drivers/gpu/drm/i915/gt/intel_ppgtt.c| 13 -
 drivers/gpu/drm/i915/gt/selftest_hangcheck.c |  2 +-
 drivers/gpu/drm/i915/gt/uc/intel_guc.c   |  3 ++-
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c |  7 +--
 drivers/gpu/drm/i915/gvt/scheduler.c |  2 +-
 drivers/gpu/drm/i915/selftests/i915_gem_gtt.c|  4 ++--
 19 files changed, 56 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index c2ab0e22db0a..8208fd5b72c3 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1287,7 +1287,7 @@ i915_gem_create_context(struct drm_i915_private *i915,
} else if (HAS_FULL_PPGTT(i915)) {
struct i915_ppgtt *ppgtt;
 
-   ppgtt = i915_ppgtt_create(>gt);
+   ppgtt = i915_ppgtt_create(>gt, 0);
if (IS_ERR(ppgtt)) {
drm_dbg(>drm, "PPGTT setup failed (%ld)\n",
PTR_ERR(ppgtt));
@@ -1465,7 +1465,7 @@ int i915_gem_vm_create_ioctl(struct drm_device *dev, void 
*data,
if (args->flags)
return -EINVAL;
 
-   ppgtt = i915_ppgtt_create(>gt);
+   ppgtt = i915_ppgtt_create(>gt, 0);
if (IS_ERR(ppgtt))
return PTR_ERR(ppgtt);
 
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h 
b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
index 118691ce81d7..fa2ba9e2a4d0 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -294,13 +294,16 @@ struct drm_i915_gem_object {
 #define I915_BO_ALLOC_USERBIT(3)
 /* Object is allowed to lose its contents on suspend / resume, even if pinned 
*/
 #define I915_BO_ALLOC_PM_VOLATILE BIT(4)
+/* Object needs to be restored early using memcpy during resume */
+#define I915_BO_ALLOC_PM_EARLYBIT(5)
 #define I915_BO_ALLOC_FLAGS (I915_BO_ALLOC_CONTIGUOUS | \
 I915_BO_ALLOC_VOLATILE | \
 I915_BO_ALLOC_CPU_CLEAR | \
 I915_BO_ALLOC_USER | \
-I915_BO_ALLOC_PM_VOLATILE)
-#define I915_BO_READONLY  BIT(5)
-#define I915_TILING_QUIRK_BIT 6 /* unknown swizzling; do not release! */
+I915_BO_ALLOC_PM_VOLATILE | \
+I915_BO_ALLOC_PM_EARLY)
+#define I915_BO_READONLY  BIT(6)
+#define I915_TILING_QUIRK_BIT 7 /* unknown swizzling; do not release! */
 
/**
 * @mem_flags - Mutable placement-related flags
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pm.c 
b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
index 12b37b4c1192..726b40e1fbb0 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
@@

[PATCH v4 6/6] drm/i915: Reduce the number of objects subject to memcpy recover

2021-09-20 Thread Thomas Hellström

We really only need memcpy restore for objects that affect the
operability of the migrate context. That is, primarily the page-table
objects of the migrate VM.

Add an object flag, I915_BO_ALLOC_PM_EARLY for objects that need early
restores using memcpy and a way to assign LMEM page-table object flags
to be used by the vms.

Restore objects without this flag with the gpu blitter and only objects
carrying the flag using TTM memcpy.

Initially mark the migrate, gt, gtt and vgpu vms to use this flag, and
defer for a later audit which vms actually need it. Most importantly, user-
allocated vms with pinned page-table objects can be restored using the
blitter.

Performance-wise memcpy restore is probably as fast as gpu restore if not
faster, but using gpu restore will help tackling future restrictions in
mappable LMEM size.

v4:
- Don't mark the aliasing ppgtt page table flags for early resume, but
  rather the ggtt page table flags as intended. (Matthew Auld)
- The check for user buffer objects during early resume is pointless, since
  they are never marked I915_BO_ALLOC_PM_EARLY. (Matthew Auld)

Signed-off-by: Thomas Hellström 
Reviewed-by: Matthew Auld 
---
 drivers/gpu/drm/i915/gem/i915_gem_context.c  |  4 ++--
 drivers/gpu/drm/i915/gem/i915_gem_object_types.h |  9 ++---
 drivers/gpu/drm/i915/gem/i915_gem_pm.c   |  6 +-
 drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c   |  5 +++--
 drivers/gpu/drm/i915/gem/selftests/huge_pages.c  |  2 +-
 drivers/gpu/drm/i915/gt/gen6_ppgtt.c |  2 +-
 drivers/gpu/drm/i915/gt/gen8_ppgtt.c |  5 +++--
 drivers/gpu/drm/i915/gt/gen8_ppgtt.h |  4 +++-
 drivers/gpu/drm/i915/gt/intel_ggtt.c |  3 ++-
 drivers/gpu/drm/i915/gt/intel_gt.c   |  2 +-
 drivers/gpu/drm/i915/gt/intel_gtt.c  |  3 ++-
 drivers/gpu/drm/i915/gt/intel_gtt.h  |  9 +++--
 drivers/gpu/drm/i915/gt/intel_migrate.c  |  2 +-
 drivers/gpu/drm/i915/gt/intel_ppgtt.c| 13 -
 drivers/gpu/drm/i915/gt/selftest_hangcheck.c |  2 +-
 drivers/gpu/drm/i915/gvt/scheduler.c |  2 +-
 drivers/gpu/drm/i915/selftests/i915_gem_gtt.c|  4 ++--
 17 files changed, 49 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index c2ab0e22db0a..8208fd5b72c3 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1287,7 +1287,7 @@ i915_gem_create_context(struct drm_i915_private *i915,
} else if (HAS_FULL_PPGTT(i915)) {
struct i915_ppgtt *ppgtt;
 
-   ppgtt = i915_ppgtt_create(>gt);
+   ppgtt = i915_ppgtt_create(>gt, 0);
if (IS_ERR(ppgtt)) {
drm_dbg(>drm, "PPGTT setup failed (%ld)\n",
PTR_ERR(ppgtt));
@@ -1465,7 +1465,7 @@ int i915_gem_vm_create_ioctl(struct drm_device *dev, void 
*data,
if (args->flags)
return -EINVAL;
 
-   ppgtt = i915_ppgtt_create(>gt);
+   ppgtt = i915_ppgtt_create(>gt, 0);
if (IS_ERR(ppgtt))
return PTR_ERR(ppgtt);
 
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h 
b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
index 118691ce81d7..fa2ba9e2a4d0 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -294,13 +294,16 @@ struct drm_i915_gem_object {
 #define I915_BO_ALLOC_USERBIT(3)
 /* Object is allowed to lose its contents on suspend / resume, even if pinned 
*/
 #define I915_BO_ALLOC_PM_VOLATILE BIT(4)
+/* Object needs to be restored early using memcpy during resume */
+#define I915_BO_ALLOC_PM_EARLYBIT(5)
 #define I915_BO_ALLOC_FLAGS (I915_BO_ALLOC_CONTIGUOUS | \
 I915_BO_ALLOC_VOLATILE | \
 I915_BO_ALLOC_CPU_CLEAR | \
 I915_BO_ALLOC_USER | \
-I915_BO_ALLOC_PM_VOLATILE)
-#define I915_BO_READONLY  BIT(5)
-#define I915_TILING_QUIRK_BIT 6 /* unknown swizzling; do not release! */
+I915_BO_ALLOC_PM_VOLATILE | \
+I915_BO_ALLOC_PM_EARLY)
+#define I915_BO_READONLY  BIT(6)
+#define I915_TILING_QUIRK_BIT 7 /* unknown swizzling; do not release! */
 
/**
 * @mem_flags - Mutable placement-related flags
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pm.c 
b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
index 12b37b4c1192..726b40e1fbb0 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
@@ -97,8 +97,12 @@ int i915_gem_backup_suspend(struct drm_i915_private *i915)
 * More objects may have become unpinned as requests were
 * retired. Now try to evict again. The gt may be wedged here
 * in which case we automatically fall back

Re: [PATCH v3 6/6] drm/i915: Reduce the number of objects subject to memcpy recover

2021-09-20 Thread Thomas Hellström

On Mon, 2021-09-20 at 12:05 +0100, Matthew Auld wrote:
> On 14/09/2021 20:31, Thomas Hellström wrote:
> > We really only need memcpy restore for objects that affect the
> > operability of the migrate context. That is, primarily the page-
> > table
> > objects of the migrate VM.
> > 
> > Add an object flag, I915_BO_ALLOC_PM_EARLY for objects that need
> > early
> > restores using memcpy and a way to assign LMEM page-table object
> > flags
> > to be used by the vms.
> > 
> > Restore objects without this flag with the gpu blitter and only
> > objects
> > carrying the flag using TTM memcpy.
> > 
> > Initially mark the migrate, gt, gtt and vgpu vms to use this flag,
> > and
> > defer for a later audit which vms actually need it. Most
> > importantly, user-
> > allocated vms with pinned page-table objects can be restored using
> > the
> > blitter.
> > 
> > Performance-wise memcpy restore is probably as fast as gpu restore
> > if not
> > faster, but using gpu restore will help tackling future
> > restrictions in
> > mappable LMEM size.
> > 
> > Signed-off-by: Thomas Hellström 
> > ---
> >   drivers/gpu/drm/i915/gem/i915_gem_context.c  |  4 ++--
> >   drivers/gpu/drm/i915/gem/i915_gem_object_types.h |  9 ++---
> >   drivers/gpu/drm/i915/gem/i915_gem_pm.c   |  5 -
> >   drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c   |  6 --
> >   drivers/gpu/drm/i915/gem/selftests/huge_pages.c  |  2 +-
> >   drivers/gpu/drm/i915/gt/gen6_ppgtt.c |  2 +-
> >   drivers/gpu/drm/i915/gt/gen8_ppgtt.c |  5 +++--
> >   drivers/gpu/drm/i915/gt/gen8_ppgtt.h |  4 +++-
> >   drivers/gpu/drm/i915/gt/intel_ggtt.c |  2 +-
> >   drivers/gpu/drm/i915/gt/intel_gt.c   |  2 +-
> >   drivers/gpu/drm/i915/gt/intel_gtt.c  |  3 ++-
> >   drivers/gpu/drm/i915/gt/intel_gtt.h  |  9 +++--
> >   drivers/gpu/drm/i915/gt/intel_migrate.c  |  2 +-
> >   drivers/gpu/drm/i915/gt/intel_ppgtt.c    | 13 ---
> > --
> >   drivers/gpu/drm/i915/gt/selftest_hangcheck.c |  2 +-
> >   drivers/gpu/drm/i915/gvt/scheduler.c |  2 +-
> >   drivers/gpu/drm/i915/selftests/i915_gem_gtt.c    |  4 ++--
> >   17 files changed, 48 insertions(+), 28 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > index c2ab0e22db0a..8208fd5b72c3 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > @@ -1287,7 +1287,7 @@ i915_gem_create_context(struct
> > drm_i915_private *i915,
> > } else if (HAS_FULL_PPGTT(i915)) {
> > struct i915_ppgtt *ppgtt;
> >   
> > -   ppgtt = i915_ppgtt_create(>gt);
> > +   ppgtt = i915_ppgtt_create(>gt, 0);
> > if (IS_ERR(ppgtt)) {
> > drm_dbg(>drm, "PPGTT setup failed
> > (%ld)\n",
> > PTR_ERR(ppgtt));
> > @@ -1465,7 +1465,7 @@ int i915_gem_vm_create_ioctl(struct
> > drm_device *dev, void *data,
> > if (args->flags)
> > return -EINVAL;
> >   
> > -   ppgtt = i915_ppgtt_create(>gt);
> > +   ppgtt = i915_ppgtt_create(>gt, 0);
> > if (IS_ERR(ppgtt))
> > return PTR_ERR(ppgtt);
> >   
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> > b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> > index 118691ce81d7..fa2ba9e2a4d0 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> > @@ -294,13 +294,16 @@ struct drm_i915_gem_object {
> >   #define I915_BO_ALLOC_USER    BIT(3)
> >   /* Object is allowed to lose its contents on suspend / resume,
> > even if pinned */
> >   #define I915_BO_ALLOC_PM_VOLATILE BIT(4)
> > +/* Object needs to be restored early using memcpy during resume */
> > +#define I915_BO_ALLOC_PM_EARLY    BIT(5)
> >   #define I915_BO_ALLOC_FLAGS (I915_BO_ALLOC_CONTIGUOUS | \
> >  I915_BO_ALLOC_VOLATILE | \
> >  I915_BO_ALLOC_CPU_CLEAR | \
> >  I915_BO_ALLOC_USER | \
> > -    I915_BO_ALLOC_PM_VOLATILE)
> > -#define I915_BO_READONLY  BIT(5)
> > -#define I915_TILING_QUIRK_BIT 6 /* unknown swizzling; do not
> > release! */
> > +    I915_BO_ALLOC_PM_VOLATILE | \
> > +    I915_BO_ALLOC_PM_EARLY)
> > +#define I915_BO_READONLY  BIT(6)
> > +#define I915_TILING_QUIRK_BIT 7 /* unknown swizzling; do not
> > release! */
> >   
> > /**
> >  * @mem_flags - Mutable placement-related flags
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
> > index 8736ae1dfbb2..c4a75e1c12ee 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
> > @@

Re: [PATCH v3 6/6] drm/i915: Reduce the number of objects subject to memcpy recover

2021-09-20 Thread Matthew Auld


On 14/09/2021 20:31, Thomas Hellström wrote:

We really only need memcpy restore for objects that affect the
operability of the migrate context. That is, primarily the page-table
objects of the migrate VM.

Add an object flag, I915_BO_ALLOC_PM_EARLY for objects that need early
restores using memcpy and a way to assign LMEM page-table object flags
to be used by the vms.

Restore objects without this flag with the gpu blitter and only objects
carrying the flag using TTM memcpy.

Initially mark the migrate, gt, gtt and vgpu vms to use this flag, and
defer for a later audit which vms actually need it. Most importantly, user-
allocated vms with pinned page-table objects can be restored using the
blitter.

Performance-wise memcpy restore is probably as fast as gpu restore if not
faster, but using gpu restore will help tackling future restrictions in
mappable LMEM size.

Signed-off-by: Thomas Hellström 
---
  drivers/gpu/drm/i915/gem/i915_gem_context.c  |  4 ++--
  drivers/gpu/drm/i915/gem/i915_gem_object_types.h |  9 ++---
  drivers/gpu/drm/i915/gem/i915_gem_pm.c   |  5 -
  drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c   |  6 --
  drivers/gpu/drm/i915/gem/selftests/huge_pages.c  |  2 +-
  drivers/gpu/drm/i915/gt/gen6_ppgtt.c |  2 +-
  drivers/gpu/drm/i915/gt/gen8_ppgtt.c |  5 +++--
  drivers/gpu/drm/i915/gt/gen8_ppgtt.h |  4 +++-
  drivers/gpu/drm/i915/gt/intel_ggtt.c |  2 +-
  drivers/gpu/drm/i915/gt/intel_gt.c   |  2 +-
  drivers/gpu/drm/i915/gt/intel_gtt.c  |  3 ++-
  drivers/gpu/drm/i915/gt/intel_gtt.h  |  9 +++--
  drivers/gpu/drm/i915/gt/intel_migrate.c  |  2 +-
  drivers/gpu/drm/i915/gt/intel_ppgtt.c| 13 -
  drivers/gpu/drm/i915/gt/selftest_hangcheck.c |  2 +-
  drivers/gpu/drm/i915/gvt/scheduler.c |  2 +-
  drivers/gpu/drm/i915/selftests/i915_gem_gtt.c|  4 ++--
  17 files changed, 48 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index c2ab0e22db0a..8208fd5b72c3 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1287,7 +1287,7 @@ i915_gem_create_context(struct drm_i915_private *i915,
} else if (HAS_FULL_PPGTT(i915)) {
struct i915_ppgtt *ppgtt;
  
-		ppgtt = i915_ppgtt_create(>gt);

+   ppgtt = i915_ppgtt_create(>gt, 0);
if (IS_ERR(ppgtt)) {
drm_dbg(>drm, "PPGTT setup failed (%ld)\n",
PTR_ERR(ppgtt));
@@ -1465,7 +1465,7 @@ int i915_gem_vm_create_ioctl(struct drm_device *dev, void 
*data,
if (args->flags)
return -EINVAL;
  
-	ppgtt = i915_ppgtt_create(>gt);

+   ppgtt = i915_ppgtt_create(>gt, 0);
if (IS_ERR(ppgtt))
return PTR_ERR(ppgtt);
  
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h

index 118691ce81d7..fa2ba9e2a4d0 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -294,13 +294,16 @@ struct drm_i915_gem_object {
  #define I915_BO_ALLOC_USERBIT(3)
  /* Object is allowed to lose its contents on suspend / resume, even if pinned 
*/
  #define I915_BO_ALLOC_PM_VOLATILE BIT(4)
+/* Object needs to be restored early using memcpy during resume */
+#define I915_BO_ALLOC_PM_EARLYBIT(5)
  #define I915_BO_ALLOC_FLAGS (I915_BO_ALLOC_CONTIGUOUS | \
 I915_BO_ALLOC_VOLATILE | \
 I915_BO_ALLOC_CPU_CLEAR | \
 I915_BO_ALLOC_USER | \
-I915_BO_ALLOC_PM_VOLATILE)
-#define I915_BO_READONLY  BIT(5)
-#define I915_TILING_QUIRK_BIT 6 /* unknown swizzling; do not release! */
+I915_BO_ALLOC_PM_VOLATILE | \
+I915_BO_ALLOC_PM_EARLY)
+#define I915_BO_READONLY  BIT(6)
+#define I915_TILING_QUIRK_BIT 7 /* unknown swizzling; do not release! */
  
  	/**

 * @mem_flags - Mutable placement-related flags
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pm.c 
b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
index 8736ae1dfbb2..c4a75e1c12ee 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
@@ -98,8 +98,11 @@ int i915_gem_backup_suspend(struct drm_i915_private *i915)
 * More objects may have become unpinned as requests were
 * retired. Now try to evict again. The gt may be wedged here
 * in which case we automatically fall back to memcpy.
+* We allow also backing up pinned objects that have not been
+* marked for early recover, and that may contain, for example,
+* page-tables for the migrate context. 
 */
-   ret = lmem_suspend(i915, true,

[PATCH v3 6/6] drm/i915: Reduce the number of objects subject to memcpy recover

2021-09-14 Thread Thomas Hellström

We really only need memcpy restore for objects that affect the
operability of the migrate context. That is, primarily the page-table
objects of the migrate VM.

Add an object flag, I915_BO_ALLOC_PM_EARLY for objects that need early
restores using memcpy and a way to assign LMEM page-table object flags
to be used by the vms.

Restore objects without this flag with the gpu blitter and only objects
carrying the flag using TTM memcpy.

Initially mark the migrate, gt, gtt and vgpu vms to use this flag, and
defer for a later audit which vms actually need it. Most importantly, user-
allocated vms with pinned page-table objects can be restored using the
blitter.

Performance-wise memcpy restore is probably as fast as gpu restore if not
faster, but using gpu restore will help tackling future restrictions in
mappable LMEM size.

Signed-off-by: Thomas Hellström 
---
 drivers/gpu/drm/i915/gem/i915_gem_context.c  |  4 ++--
 drivers/gpu/drm/i915/gem/i915_gem_object_types.h |  9 ++---
 drivers/gpu/drm/i915/gem/i915_gem_pm.c   |  5 -
 drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c   |  6 --
 drivers/gpu/drm/i915/gem/selftests/huge_pages.c  |  2 +-
 drivers/gpu/drm/i915/gt/gen6_ppgtt.c |  2 +-
 drivers/gpu/drm/i915/gt/gen8_ppgtt.c |  5 +++--
 drivers/gpu/drm/i915/gt/gen8_ppgtt.h |  4 +++-
 drivers/gpu/drm/i915/gt/intel_ggtt.c |  2 +-
 drivers/gpu/drm/i915/gt/intel_gt.c   |  2 +-
 drivers/gpu/drm/i915/gt/intel_gtt.c  |  3 ++-
 drivers/gpu/drm/i915/gt/intel_gtt.h  |  9 +++--
 drivers/gpu/drm/i915/gt/intel_migrate.c  |  2 +-
 drivers/gpu/drm/i915/gt/intel_ppgtt.c| 13 -
 drivers/gpu/drm/i915/gt/selftest_hangcheck.c |  2 +-
 drivers/gpu/drm/i915/gvt/scheduler.c |  2 +-
 drivers/gpu/drm/i915/selftests/i915_gem_gtt.c|  4 ++--
 17 files changed, 48 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index c2ab0e22db0a..8208fd5b72c3 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1287,7 +1287,7 @@ i915_gem_create_context(struct drm_i915_private *i915,
} else if (HAS_FULL_PPGTT(i915)) {
struct i915_ppgtt *ppgtt;
 
-   ppgtt = i915_ppgtt_create(>gt);
+   ppgtt = i915_ppgtt_create(>gt, 0);
if (IS_ERR(ppgtt)) {
drm_dbg(>drm, "PPGTT setup failed (%ld)\n",
PTR_ERR(ppgtt));
@@ -1465,7 +1465,7 @@ int i915_gem_vm_create_ioctl(struct drm_device *dev, void 
*data,
if (args->flags)
return -EINVAL;
 
-   ppgtt = i915_ppgtt_create(>gt);
+   ppgtt = i915_ppgtt_create(>gt, 0);
if (IS_ERR(ppgtt))
return PTR_ERR(ppgtt);
 
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h 
b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
index 118691ce81d7..fa2ba9e2a4d0 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -294,13 +294,16 @@ struct drm_i915_gem_object {
 #define I915_BO_ALLOC_USERBIT(3)
 /* Object is allowed to lose its contents on suspend / resume, even if pinned 
*/
 #define I915_BO_ALLOC_PM_VOLATILE BIT(4)
+/* Object needs to be restored early using memcpy during resume */
+#define I915_BO_ALLOC_PM_EARLYBIT(5)
 #define I915_BO_ALLOC_FLAGS (I915_BO_ALLOC_CONTIGUOUS | \
 I915_BO_ALLOC_VOLATILE | \
 I915_BO_ALLOC_CPU_CLEAR | \
 I915_BO_ALLOC_USER | \
-I915_BO_ALLOC_PM_VOLATILE)
-#define I915_BO_READONLY  BIT(5)
-#define I915_TILING_QUIRK_BIT 6 /* unknown swizzling; do not release! */
+I915_BO_ALLOC_PM_VOLATILE | \
+I915_BO_ALLOC_PM_EARLY)
+#define I915_BO_READONLY  BIT(6)
+#define I915_TILING_QUIRK_BIT 7 /* unknown swizzling; do not release! */
 
/**
 * @mem_flags - Mutable placement-related flags
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pm.c 
b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
index 8736ae1dfbb2..c4a75e1c12ee 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
@@ -98,8 +98,11 @@ int i915_gem_backup_suspend(struct drm_i915_private *i915)
 * More objects may have become unpinned as requests were
 * retired. Now try to evict again. The gt may be wedged here
 * in which case we automatically fall back to memcpy.
+* We allow also backing up pinned objects that have not been
+* marked for early recover, and that may contain, for example,
+* page-tables for the migrate context.
 */
-   ret = lmem_suspend(i915, true, false);
+   ret = lmem_suspend(i915, true, true);

[PATCH v2 6/6] drm/i915: Reduce the number of objects subject to memcpy recover

2021-09-06 Thread Thomas Hellström

We really only need memcpy restore for objects that affect the
operability of the migrate context. That is, primarily the page-table
objects of the migrate VM.

Add an object flag, I915_BO_ALLOC_PM_EARLY for objects that need early
restores using memcpy and a way to assign LMEM page-table object flags
to be used by the vms.

Restore objects without this flag with the gpu blitter and only objects
carrying the flag using TTM memcpy.

Initially mark the migrate, gt, gtt and vgpu vms to use this flag, and
defer for a later audit which vms actually need it. Most importantly, user-
allocated vms with pinned page-table objects can be restored using the
blitter.

Performance-wise memcpy restore is probably as fast as gpu restore if not
faster, but using gpu restore will help tackling future restrictions in
mappable LMEM size.

Signed-off-by: Thomas Hellström 
---
 drivers/gpu/drm/i915/gem/i915_gem_context.c  |  4 ++--
 drivers/gpu/drm/i915/gem/i915_gem_object_types.h |  9 ++---
 drivers/gpu/drm/i915/gem/i915_gem_pm.c   |  6 --
 drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c   |  6 --
 drivers/gpu/drm/i915/gem/selftests/huge_pages.c  |  2 +-
 drivers/gpu/drm/i915/gt/gen6_ppgtt.c |  2 +-
 drivers/gpu/drm/i915/gt/gen8_ppgtt.c |  5 +++--
 drivers/gpu/drm/i915/gt/gen8_ppgtt.h |  4 +++-
 drivers/gpu/drm/i915/gt/intel_ggtt.c |  2 +-
 drivers/gpu/drm/i915/gt/intel_gt.c   |  2 +-
 drivers/gpu/drm/i915/gt/intel_gtt.c  |  3 ++-
 drivers/gpu/drm/i915/gt/intel_gtt.h  |  9 +++--
 drivers/gpu/drm/i915/gt/intel_migrate.c  |  2 +-
 drivers/gpu/drm/i915/gt/intel_ppgtt.c| 13 -
 drivers/gpu/drm/i915/gt/selftest_hangcheck.c |  2 +-
 drivers/gpu/drm/i915/gvt/scheduler.c |  2 +-
 drivers/gpu/drm/i915/selftests/i915_gem_gtt.c|  4 ++--
 17 files changed, 48 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index fd169cf2f75a..3dbebced0950 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1312,7 +1312,7 @@ i915_gem_create_context(struct drm_i915_private *i915,
} else if (HAS_FULL_PPGTT(i915)) {
struct i915_ppgtt *ppgtt;
 
-   ppgtt = i915_ppgtt_create(>gt);
+   ppgtt = i915_ppgtt_create(>gt, 0);
if (IS_ERR(ppgtt)) {
drm_dbg(>drm, "PPGTT setup failed (%ld)\n",
PTR_ERR(ppgtt));
@@ -1490,7 +1490,7 @@ int i915_gem_vm_create_ioctl(struct drm_device *dev, void 
*data,
if (args->flags)
return -EINVAL;
 
-   ppgtt = i915_ppgtt_create(>gt);
+   ppgtt = i915_ppgtt_create(>gt, 0);
if (IS_ERR(ppgtt))
return PTR_ERR(ppgtt);
 
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h 
b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
index 66123ba46247..477b98b656b4 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -294,13 +294,16 @@ struct drm_i915_gem_object {
 #define I915_BO_ALLOC_USERBIT(3)
 /* Object may lose its contents on suspend / resume */
 #define I915_BO_ALLOC_PM_VOLATILE BIT(4)
+/* Object needs to be restored early using memcpy during resume */
+#define I915_BO_ALLOC_PM_EARLYBIT(5)
 #define I915_BO_ALLOC_FLAGS (I915_BO_ALLOC_CONTIGUOUS | \
 I915_BO_ALLOC_VOLATILE | \
 I915_BO_ALLOC_CPU_CLEAR | \
 I915_BO_ALLOC_USER | \
-I915_BO_ALLOC_PM_VOLATILE)
-#define I915_BO_READONLY  BIT(5)
-#define I915_TILING_QUIRK_BIT 6 /* unknown swizzling; do not release! */
+I915_BO_ALLOC_PM_VOLATILE | \
+I915_BO_ALLOC_PM_EARLY)
+#define I915_BO_READONLY  BIT(6)
+#define I915_TILING_QUIRK_BIT 7 /* unknown swizzling; do not release! */
 
/**
 * @mem_flags - Mutable placement-related flags
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pm.c 
b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
index 9746c255ddcc..cdd344f64404 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
@@ -98,9 +98,11 @@ int i915_gem_backup_suspend(struct drm_i915_private *i915)
 * More objects may have become unpinned as requests were
 * retired. Now try to evict again. The gt may be wedged here
 * in which case we automatically fall back to memcpy.
+* We allow also backing up pinned objects that have not been
+* marked for early recover, and that may contain, for example,
+* page-tables for the migrate context.
 */
-
-   ret = lmem_suspend(i915, true, false);
+   ret = lmem_suspend(i915, true, true);
if (ret)

Subject: [PATCH v2 0/2] Fix a hung during memory pressure test

2021-09-05 Thread Pan, Xinhui

[AMD Official Use Only]

A long time ago, someone reports system got hung during memory test.
In recent days, I am trying to look for or understand the potential
deadlock in ttm/amdgpu code.

This patchset aims to fix the deadlock during ttm populate.

TTM has a parameter called pages_limit, when allocated GTT memory
reaches this limit, swapout would be triggered. As ttm_bo_swapout does
not return the correct retval, populate might get hung.

UVD ib test uses GTT which might be insufficient. So a gpu recovery
would hung if populate hung.

I have made one drm test which alloc two GTT BOs, submit gfx copy
commands and free these BOs without waiting fence. What's more, these
gfx copy commands will cause gfx ring hang. So gpu recovery would be
triggered.

Now here is one possible deadlock case.
gpu_recovery
 -> stop drm scheduler
 -> asic reset
   -> ib test
  -> tt populate (uvd ib test)
->  ttm_bo_swapout (BO A) // this always fails as the fence of
BO A would not be signaled by schedluer or HW. Hit deadlock.

I paste the drm test patch below.
#modprobe ttm pages_limit=65536
#amdgpu_test -s 1 -t 4
---
 tests/amdgpu/basic_tests.c | 32 ++--
 1 file changed, 14 insertions(+), 18 deletions(-)

diff --git a/tests/amdgpu/basic_tests.c b/tests/amdgpu/basic_tests.c
index dbf02fee..f85ed340 100644
--- a/tests/amdgpu/basic_tests.c
+++ b/tests/amdgpu/basic_tests.c
@@ -65,13 +65,16 @@ static void amdgpu_direct_gma_test(void);
 static void amdgpu_command_submission_write_linear_helper(unsigned ip_type);
 static void amdgpu_command_submission_const_fill_helper(unsigned ip_type);
 static void amdgpu_command_submission_copy_linear_helper(unsigned ip_type);
-static void amdgpu_test_exec_cs_helper(amdgpu_context_handle context_handle,
+static void _amdgpu_test_exec_cs_helper(amdgpu_context_handle context_handle,
   unsigned ip_type,
   int instance, int pm4_dw, uint32_t 
*pm4_src,
   int res_cnt, amdgpu_bo_handle *resources,
   struct amdgpu_cs_ib_info *ib_info,
-  struct amdgpu_cs_request *ibs_request);
+  struct amdgpu_cs_request *ibs_request, 
int sync, int repeat);

+#define amdgpu_test_exec_cs_helper(...) \
+   _amdgpu_test_exec_cs_helper(__VA_ARGS__, 1, 1)
+
 CU_TestInfo basic_tests[] = {
{ "Query Info Test",  amdgpu_query_info_test },
{ "Userptr Test",  amdgpu_userptr_test },
@@ -1341,12 +1344,12 @@ static void amdgpu_command_submission_compute(void)
  * pm4_src, resources, ib_info, and ibs_request
  * submit command stream described in ibs_request and wait for this IB 
accomplished
  */
-static void amdgpu_test_exec_cs_helper(amdgpu_context_handle context_handle,
+static void _amdgpu_test_exec_cs_helper(amdgpu_context_handle context_handle,
   unsigned ip_type,
   int instance, int pm4_dw, uint32_t 
*pm4_src,
   int res_cnt, amdgpu_bo_handle *resources,
   struct amdgpu_cs_ib_info *ib_info,
-  struct amdgpu_cs_request *ibs_request)
+  struct amdgpu_cs_request *ibs_request, 
int sync, int repeat)
 {
int r;
uint32_t expired;
@@ -1395,12 +1398,15 @@ static void 
amdgpu_test_exec_cs_helper(amdgpu_context_handle context_handle,
CU_ASSERT_NOT_EQUAL(ibs_request, NULL);

/* submit CS */
-   r = amdgpu_cs_submit(context_handle, 0, ibs_request, 1);
+   while (repeat--)
+   r = amdgpu_cs_submit(context_handle, 0, ibs_request, 1);
CU_ASSERT_EQUAL(r, 0);

r = amdgpu_bo_list_destroy(ibs_request->resources);
CU_ASSERT_EQUAL(r, 0);

+   if (!sync)
+   return;
fence_status.ip_type = ip_type;
fence_status.ip_instance = 0;
fence_status.ring = ibs_request->ring;
@@ -1667,7 +1673,7 @@ static void 
amdgpu_command_submission_sdma_const_fill(void)

 static void amdgpu_command_submission_copy_linear_helper(unsigned ip_type)
 {
-   const int sdma_write_length = 1024;
+   const int sdma_write_length = (255) << 20;
const int pm4_dw = 256;
amdgpu_context_handle context_handle;
amdgpu_bo_handle bo1, bo2;
@@ -1715,8 +1721,6 @@ static void 
amdgpu_command_submission_copy_linear_helper(unsigned ip_type)
_va_handle);
CU_ASSERT_EQUAL(r, 0);

-   /* set bo1 */
-   memset((void*)bo1_cpu, 0xaa, sdma_write_length);

/* allocate UC bo2 for sDMA use */
r = amdgpu_bo_alloc_and_map(device_handle,
@@ -1727,8 +1731,6

[PATCH 6/6] drm/i915: Reduce the number of objects subject to memcpy recover

2021-09-02 Thread Thomas Hellström

We really only need memcpy restore for objects that affect the
operability of the migrate context. That is, primarily the page-table
objects of the migrate VM.

Add an object flag, I915_BO_ALLOC_PM_EARLY for objects that need early
restores using memcpy and a way to assign LMEM page-table object flags
to be used by the vms.

Restore objects without this flag with the gpu blitter and only objects
carrying the flag using TTM memcpy.

Initially mark the migrate, gt, gtt and vgpu vms to use this flag, and
defer for a later audit which vms actually need it. Most importantly, user-
allocated vms with pinned page-table objects can be restored using the
blitter.

Performance-wise memcpy restore is probably as fast as gpu restore if not
faster, but using gpu restore will help tackling future restrictions in
mappable LMEM size.

Signed-off-by: Thomas Hellström 
---
 drivers/gpu/drm/i915/gem/i915_gem_context.c  |  4 ++--
 drivers/gpu/drm/i915/gem/i915_gem_object_types.h |  9 ++---
 drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c   |  3 ++-
 drivers/gpu/drm/i915/gem/selftests/huge_pages.c  |  2 +-
 drivers/gpu/drm/i915/gt/gen6_ppgtt.c |  2 +-
 drivers/gpu/drm/i915/gt/gen8_ppgtt.c |  5 +++--
 drivers/gpu/drm/i915/gt/gen8_ppgtt.h |  4 +++-
 drivers/gpu/drm/i915/gt/intel_ggtt.c |  2 +-
 drivers/gpu/drm/i915/gt/intel_gt.c   |  2 +-
 drivers/gpu/drm/i915/gt/intel_gtt.c  |  3 ++-
 drivers/gpu/drm/i915/gt/intel_gtt.h  |  9 +++--
 drivers/gpu/drm/i915/gt/intel_migrate.c  |  2 +-
 drivers/gpu/drm/i915/gt/intel_ppgtt.c| 13 -
 drivers/gpu/drm/i915/gt/selftest_hangcheck.c |  2 +-
 drivers/gpu/drm/i915/gvt/scheduler.c |  2 +-
 drivers/gpu/drm/i915/selftests/i915_gem_gtt.c|  4 ++--
 16 files changed, 42 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index fd169cf2f75a..3dbebced0950 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1312,7 +1312,7 @@ i915_gem_create_context(struct drm_i915_private *i915,
} else if (HAS_FULL_PPGTT(i915)) {
struct i915_ppgtt *ppgtt;
 
-   ppgtt = i915_ppgtt_create(>gt);
+   ppgtt = i915_ppgtt_create(>gt, 0);
if (IS_ERR(ppgtt)) {
drm_dbg(>drm, "PPGTT setup failed (%ld)\n",
PTR_ERR(ppgtt));
@@ -1490,7 +1490,7 @@ int i915_gem_vm_create_ioctl(struct drm_device *dev, void 
*data,
if (args->flags)
return -EINVAL;
 
-   ppgtt = i915_ppgtt_create(>gt);
+   ppgtt = i915_ppgtt_create(>gt, 0);
if (IS_ERR(ppgtt))
return PTR_ERR(ppgtt);
 
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h 
b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
index 66123ba46247..477b98b656b4 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -294,13 +294,16 @@ struct drm_i915_gem_object {
 #define I915_BO_ALLOC_USERBIT(3)
 /* Object may lose its contents on suspend / resume */
 #define I915_BO_ALLOC_PM_VOLATILE BIT(4)
+/* Object needs to be restored early using memcpy during resume */
+#define I915_BO_ALLOC_PM_EARLYBIT(5)
 #define I915_BO_ALLOC_FLAGS (I915_BO_ALLOC_CONTIGUOUS | \
 I915_BO_ALLOC_VOLATILE | \
 I915_BO_ALLOC_CPU_CLEAR | \
 I915_BO_ALLOC_USER | \
-I915_BO_ALLOC_PM_VOLATILE)
-#define I915_BO_READONLY  BIT(5)
-#define I915_TILING_QUIRK_BIT 6 /* unknown swizzling; do not release! */
+I915_BO_ALLOC_PM_VOLATILE | \
+I915_BO_ALLOC_PM_EARLY)
+#define I915_BO_READONLY  BIT(6)
+#define I915_TILING_QUIRK_BIT 7 /* unknown swizzling; do not release! */
 
/**
 * @mem_flags - Mutable placement-related flags
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c 
b/drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c
index ff35c0535fa4..60c610bb2c88 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c
@@ -149,7 +149,8 @@ static int i915_ttm_restore(struct i915_gem_apply_to_region 
*apply,
if (!obj->ttm.backup)
return 0;
 
-   if (pm_apply->early_restore && (obj->flags & I915_BO_ALLOC_USER))
+   if (pm_apply->early_restore && ((obj->flags & I915_BO_ALLOC_USER) ||
+   !(obj->flags & I915_BO_ALLOC_PM_EARLY)))
return 0;
 
err = i915_gem_object_lock(backup, apply->ww);
diff --git a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c 
b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
index a094f3ce1a90..149f62221a83 100644
---

[no subject]

2021-06-21 Thread shashank singh

Hello everyone, my name is Shashank Singh. I hope this is the right
platform to reach out to the 'X.org' community. I was curious about the
X.org Endless Vacation of Code. Is this program still active?

[no subject]

2021-05-15 Thread Dmitry Baryshkov

>From Dmitry Baryshkov  # This line is ignored.
From: Dmitry Baryshkov 
Reply-To: 
Subject: [PATCH v2 0/6] drm/msm/dpu: simplify RM code
In-Reply-To: 

There is no need to request most of hardware blocks through the resource
manager (RM), since typically there is 1:1 or N:1 relationship between
corresponding blocks. Each LM is tied to the single PP. Each MERGE_3D
can be used by the specified pair of PPs.  Each DSPP is also tied to
single LM. So instead of allocating them through the RM, get them via
static configuration.

Depends on: 
https://lore.kernel.org/linux-arm-msm/20210515190909.1809050-1-dmitry.barysh...@linaro.org

Changes since v1:
 - Split into separate patch series to ease review.


Dmitry Baryshkov (6):
  drm/msm/dpu: get DSPP blocks directly rather than through RM
  drm/msm/dpu: get MERGE_3D blocks directly rather than through RM
  drm/msm/dpu: get PINGPONG blocks directly rather than through RM
  drm/msm/dpu: get INTF blocks directly rather than through RM
  drm/msm/dpu: drop unused lm_max_width from RM
  drm/msm/dpu: simplify peer LM handling

 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c|  54 +---
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h|   8 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h   |   5 -
 .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c   |   8 -
 .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c   |   8 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c |   2 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h |   4 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c  |  14 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.h  |   7 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c|   7 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h|   4 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c|  53 +++-
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h|   5 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 310 ++---
 drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h |  18 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h  |   9 +-
 16 files changed, 115 insertions(+), 401 deletions(-)

[no subject]

2021-02-11 Thread Dave Airlie

Hi Linus,

Regular fixes for final, there is a ttm regression fix, dp-mst fix,
one amdgpu revert, two i915 fixes, and some misc fixes for sun4i,
xlnx, and vc4.

All pretty quiet and don't think we have any known outstanding regressions.

Dave.

drm-fixes-2021-02-12:
drm fixes for 5.11-rc8

ttm:
- page pool regression fix.

dp_mst:
- Don't report un-attached ports as connected

amdgpu:
- Blank screen fix

i915:
- Ensure Type-C FIA is powered when initializing
- Fix overlay frontbuffer tracking

sun4i:
- tcon1 sync polarity fix
- Always set HDMI clock rate
- Fix H6 HDMI PHY config
- Fix H6 max frequency

vc4:
- Fix buffer overflow

xlnx:
- Fix memory leak
The following changes since commit 92bf22614b21a2706f4993b278017e437f7785b3:

  Linux 5.11-rc7 (2021-02-07 13:57:38 -0800)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2021-02-12

for you to fetch changes up to 551c81853d6d3ff016269d62612e7cd0a53104ab:

  Merge branch 'drm-misc-fixes' of
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes (2021-02-12
13:38:51 +1000)


drm fixes for 5.11-rc8

ttm:
- page pool regression fix.

dp_mst:
- Don't report un-attached ports as connected

amdgpu:
- Blank screen fix

i915:
- Ensure Type-C FIA is powered when initializing
- Fix overlay frontbuffer tracking

sun4i:
- tcon1 sync polarity fix
- Always set HDMI clock rate
- Fix H6 HDMI PHY config
- Fix H6 max frequency

vc4:
- Fix buffer overflow

xlnx:
- Fix memory leak


Alex Deucher (1):
  Revert "drm/amd/display: Update NV1x SR latency values"

Christian König (1):
  drm/ttm: make sure pool pages are cleared

Dave Airlie (3):
  Merge tag 'amd-drm-fixes-5.11-2021-02-10' of
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes
  Merge tag 'drm-intel-fixes-2021-02-11' of
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes
  Merge branch 'drm-misc-fixes' of
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes

Imre Deak (2):
  drm/dp_mst: Don't report ports connected if nothing is attached to them
  drm/i915/tgl+: Make sure TypeC FIA is powered up when initializing it

Jernej Skrabec (4):
  drm/sun4i: tcon: set sync polarity for tcon1 channel
  drm/sun4i: dw-hdmi: always set clock rate
  drm/sun4i: Fix H6 HDMI PHY configuration
  drm/sun4i: dw-hdmi: Fix max. frequency for H6

Maxime Ripard (1):
  drm/vc4: hvs: Fix buffer overflow with the dlist handling

Quanyang Wang (1):
  drm/xlnx: fix kmemleak by sending vblank_event in atomic_disable

Ville Syrjälä (1):
  drm/i915: Fix overlay frontbuffer tracking

 .../gpu/drm/amd/display/dc/dcn20/dcn20_resource.c  |  4 +-
 drivers/gpu/drm/drm_dp_mst_topology.c  |  1 +
 drivers/gpu/drm/i915/display/intel_overlay.c   | 17 +++---
 drivers/gpu/drm/i915/display/intel_tc.c| 67 --
 drivers/gpu/drm/sun4i/sun4i_tcon.c | 25 
 drivers/gpu/drm/sun4i/sun4i_tcon.h |  6 ++
 drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c  | 10 +---
 drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h  |  1 -
 drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 26 +++--
 drivers/gpu/drm/ttm/ttm_pool.c | 10 
 drivers/gpu/drm/vc4/vc4_plane.c| 18 --
 drivers/gpu/drm/xlnx/zynqmp_disp.c | 15 +++--
 12 files changed, 122 insertions(+), 78 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[no subject]

2021-02-02 Thread Juan Fernando Diosdado Ramirez

Ayuda
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Subject: [RFC] clang tooling cleanups

2020-11-10 Thread Tom Rix


On 11/9/20 6:52 PM, Joe Perches wrote:
> On Tue, 2020-10-27 at 09:42 -0700, t...@redhat.com wrote:
>> This rfc will describe
>> An upcoming treewide cleanup.
>> How clang tooling was used to programatically do the clean up.
>> Solicit opinions on how to generally use clang tooling.
>>
>> The clang warning -Wextra-semi-stmt produces about 10k warnings.
>> Reviewing these, a subset of semicolon after a switch looks safe to
>> fix all the time.  An example problem
>>
>> void foo(int a) {
>>  switch(a) {
>>     case 1:
>> ...
>>  }; <--- extra semicolon
>> }
>>
>> Treewide, there are about 100 problems in 50 files for x86_64 allyesconfig.
>> These fixes will be the upcoming cleanup.
> coccinelle already does some of these.
>
> For instance: scripts/coccinelle/misc/semicolon.cocci
>
> Perhaps some tool coordination can be done here as
> coccinelle/checkpatch/clang/Lindent call all be used
> to do some facet or another of these cleanup issues.

Thanks for pointing this out.

I will take a look at it.

Tom

>
>

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Subject: [RFC] clang tooling cleanups

2020-11-09 Thread Joe Perches

On Tue, 2020-10-27 at 09:42 -0700, t...@redhat.com wrote:
> This rfc will describe
> An upcoming treewide cleanup.
> How clang tooling was used to programatically do the clean up.
> Solicit opinions on how to generally use clang tooling.
> 
> The clang warning -Wextra-semi-stmt produces about 10k warnings.
> Reviewing these, a subset of semicolon after a switch looks safe to
> fix all the time.  An example problem
> 
> void foo(int a) {
>  switch(a) {
>  case 1:
>  ...
>  }; <--- extra semicolon
> }
> 
> Treewide, there are about 100 problems in 50 files for x86_64 allyesconfig.
> These fixes will be the upcoming cleanup.

coccinelle already does some of these.

For instance: scripts/coccinelle/misc/semicolon.cocci

Perhaps some tool coordination can be done here as
coccinelle/checkpatch/clang/Lindent call all be used
to do some facet or another of these cleanup issues.



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Subject: [RFC] clang tooling cleanups

2020-10-27 Thread trix

This rfc will describe
An upcoming treewide cleanup.
How clang tooling was used to programatically do the clean up.
Solicit opinions on how to generally use clang tooling.

The clang warning -Wextra-semi-stmt produces about 10k warnings.
Reviewing these, a subset of semicolon after a switch looks safe to
fix all the time.  An example problem

void foo(int a) {
 switch(a) {
   case 1:
   ...
 }; <--- extra semicolon
}

Treewide, there are about 100 problems in 50 files for x86_64 allyesconfig.
These fixes will be the upcoming cleanup.

clang already supports fixing this problem. Add to your command line

  clang -c -Wextra-semi-stmt -Xclang -fixit foo.c

  foo.c:8:3: warning: empty expression statement has no effect;
remove unnecessary ';' to silence this warning [-Wextra-semi-stmt]
};
 ^
  foo.c:8:3: note: FIX-IT applied suggested code changes
  1 warning generated.

The big problem is using this treewide is it will fix all 10k problems.
10k changes to analyze and upstream is not practical.

Another problem is the generic fixer only removes the semicolon.
So empty lines with some tabs need to be manually cleaned.

What is needed is a more precise fixer.

Enter clang-tidy.
https://clang.llvm.org/extra/clang-tidy/

Already part of the static checker infrastructure, invoke on the clang
build with
  make clang-tidy

It is only a matter of coding up a specific checker for the cleanup.
Upstream this is review is happening here
https://reviews.llvm.org/D90180

The development of a checker/fixer is
Start with a reproducer

void foo (int a) {
  switch (a) {};
}

Generate the abstract syntax tree (AST)

  clang -Xclang -ast-dump foo.c

`-FunctionDecl 
  |-ParmVarDecl 
  `-CompoundStmt 
|-SwitchStmt 
| |-ImplicitCastExpr
| | `-DeclRefExpr
| `-CompoundStmt
`-NullStmt

Write a matcher to get you most of the way

void SwitchSemiCheck::registerMatchers(MatchFinder *Finder) {
  Finder->addMatcher(
  compoundStmt(has(switchStmt().bind("switch"))).bind("comp"), this);
}

The 'bind' method is important, it allows a string to be associated
with a node in the AST.  In this case these are

`-FunctionDecl 
  |-ParmVarDecl 
  `-CompoundStmt < comp
|-SwitchStmt < switch
| |-ImplicitCastExpr
| | `-DeclRefExpr
| `-CompoundStmt
`-NullStmt

When a match is made the 'check' method will be called.

  void SwitchSemiCheck::check(const MatchFinder::MatchResult ) {
auto *C = Result.Nodes.getNodeAs("comp");
auto *S = Result.Nodes.getNodeAs("switch");

This is where the string in the bind calls are changed to nodes

`-FunctionDecl 
  |-ParmVarDecl 
  `-CompoundStmt < comp, C
|-SwitchStmt < switch, S
| |-ImplicitCastExpr
| | `-DeclRefExpr
| `-CompoundStmt
`-NullStmt <-- looking for N

And then more logic to find the NullStmt

  auto Current = C->body_begin();
  auto Next = Current;
  Next++;
  while (Next != C->body_end()) {
if (*Current == S) {
  if (const auto *N = dyn_cast(*Next)) {

When it is found, a warning is printed and a FixItHint is proposed.

  auto H = FixItHint::CreateReplacement(
SourceRange(S->getBody()->getEndLoc(), N->getSemiLoc()), "}");
  diag(N->getSemiLoc(), "unneeded semicolon") << H;

This fixit replaces from the end of switch to the semicolon with a
'}'.  Because the end of the switch is '}' this has the effect of
removing all the whitespace as well as the semicolon.

Because of the checker's placement in clang-tidy existing linuxkernel
checkers, all that was needed to fix the tree was to add a '-fix'to the
build's clang-tidy call.

I am looking for opinions on what we want to do specifically with
cleanups and generally about other source-to-source programmatic
changes to the code base.

For cleanups, I think we need a new toplevel target

clang-tidy-fix

And an explicit list of fixers that have a very high (100%?) fix rate.

Ideally a bot should make the changes, but a bot could also nag folks.
Is there interest in a bot making the changes? Does one already exist?

The general source-to-source is a bit blue sky.  Ex/ could automagicly
refactor api, outline similar cut-n-pasted functions etc. Anything on
someone's wishlist you want to try out ?

Signed-off-by: Tom Rix 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[no subject]

2020-10-08 Thread sandy . 8925

Signed-off-by: Sandeep Raghuraman 


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[no subject]

2020-09-14 Thread Dave Airlie

The goal here is to make the ttm_tt object just represent a
memory backing store, and now whether the store is bound to a
global translation table. It moves binding up to the bo level.

There's a lot more work on removing the global TT from the core
of TTM, but this seems like a good start.

Dave.


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/4] * SUBJECT HERE *

2020-08-19 Thread Tomer Samara

On Tue, Aug 18, 2020 at 11:50:35AM +0200, Greg Kroah-Hartman wrote:
> On Tue, Aug 18, 2020 at 12:17:08PM +0300, Tomer Samara wrote:
> > *** BLURB HERE ***
> 
> Really?
> 
> And your subject line could use some work too :(
>

sorry for that, i've made a script for sending patchset and accidently 
it sents mails without contorl.
Fixed that
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/4] * SUBJECT HERE *

2020-08-18 Thread Greg Kroah-Hartman

On Tue, Aug 18, 2020 at 12:17:08PM +0300, Tomer Samara wrote:
> *** BLURB HERE ***

Really?

And your subject line could use some work too :(

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCHv2 0/4] Subject: panel-dsi-cm: update bindings

2020-08-04 Thread Tomi Valkeinen

Hi Sebastian,

On 16/07/2020 15:57, Sebastian Reichel wrote:
> The cleanup series for omapdrm's DSI code got too big. Reviewing
> this is not fun and the same goes for keeping track of the change
> requests. Let's do the cleanup in smaller steps instead. This is
> the first batch, which updates the binding (txt -> yaml) and
> modifies the DT slightly.
> 
> Changes since PATCHv1 [0]:
> 
> PATCHv1..PATCHv2:
>  * Update binding as suggested by Sam
>   * Remove 'port' from required list
>   * Drop 'lanes' and 'port' from example ('lanes' is a port property
> used by OMAP's DSI controller)
>   * Drop the label from example
>   * Add '...' at end of file
>  * Fix , in patch description from patch 2
>  * Apply Reviewed-by tags
> 
> [0] 
> https://lore.kernel.org/dri-devel/20200629223315.118256-1-sebastian.reic...@collabora.com/
> 
> -- Sebastian
> 
> Sebastian Reichel (4):
>   dt-bindings: display: panel-dsi-cm: convert to YAML
>   ARM: dts: omap: add channel to DSI panels
>   ARM: dts: omap4-droid4: add panel compatible
>   ARM: dts: omap4-droid4: add panel orientation

For the series:

Reviewed-by: Tomi Valkeinen 

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCHv2 0/4] Subject: panel-dsi-cm: update bindings

2020-07-17 Thread Sebastian Reichel

The cleanup series for omapdrm's DSI code got too big. Reviewing
this is not fun and the same goes for keeping track of the change
requests. Let's do the cleanup in smaller steps instead. This is
the first batch, which updates the binding (txt -> yaml) and
modifies the DT slightly.

Changes since PATCHv1 [0]:

PATCHv1..PATCHv2:
 * Update binding as suggested by Sam
  * Remove 'port' from required list
  * Drop 'lanes' and 'port' from example ('lanes' is a port property
used by OMAP's DSI controller)
  * Drop the label from example
  * Add '...' at end of file
 * Fix , in patch description from patch 2
 * Apply Reviewed-by tags

[0] 
https://lore.kernel.org/dri-devel/20200629223315.118256-1-sebastian.reic...@collabora.com/

-- Sebastian

Sebastian Reichel (4):
  dt-bindings: display: panel-dsi-cm: convert to YAML
  ARM: dts: omap: add channel to DSI panels
  ARM: dts: omap4-droid4: add panel compatible
  ARM: dts: omap4-droid4: add panel orientation

 .../bindings/display/panel/panel-dsi-cm.txt   | 29 ---
 .../bindings/display/panel/panel-dsi-cm.yaml  | 86 +++
 .../boot/dts/motorola-mapphone-common.dtsi|  6 +-
 arch/arm/boot/dts/omap3-n950.dts  |  3 +-
 arch/arm/boot/dts/omap3.dtsi  |  3 +
 arch/arm/boot/dts/omap4-sdp.dts   |  6 +-
 arch/arm/boot/dts/omap4.dtsi  |  6 ++
 arch/arm/boot/dts/omap5.dtsi  |  6 ++
 8 files changed, 111 insertions(+), 34 deletions(-)
 delete mode 100644 
Documentation/devicetree/bindings/display/panel/panel-dsi-cm.txt
 create mode 100644 
Documentation/devicetree/bindings/display/panel/panel-dsi-cm.yaml

-- 
2.27.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Subject: [PATCH v1 0/8] support cmdq helper function on mt6779 platform

2020-07-06 Thread Dennis YC Hsieh

This patch support more gce helper function on mt6779 platform.

depends on patch: support gce on mt6779 platform

and depends on following applied patches
soc: mediatek: cmdq: add set event function
soc: mediatek: cmdq: export finalize function
soc: mediatek: cmdq: add assign function

Change since v1:
- Rename cmdq_mbox_shift() to cmdq_get_shift_pa().


Dennis YC Hsieh (8):
  soc: mediatek: cmdq: add address shift in jump
  soc: mediatek: cmdq: add write_s function
  soc: mediatek: cmdq: add write_s_mask function
  soc: mediatek: cmdq: add read_s function
  soc: mediatek: cmdq: add write_s value function
  soc: mediatek: cmdq: add write_s_mask value function
  soc: mediatek: cmdq: add jump function
  soc: mediatek: cmdq: add clear option in cmdq_pkt_wfe api

 drivers/gpu/drm/mediatek/mtk_drm_crtc.c  |   2 +-
 drivers/soc/mediatek/mtk-cmdq-helper.c   | 113 ++-
 include/linux/mailbox/mtk-cmdq-mailbox.h |   6 +-
 include/linux/soc/mediatek/mtk-cmdq.h|  93 ++-
 4 files changed, 206 insertions(+), 8 deletions(-)

-- 
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[no subject]

2020-06-26 Thread Rob Clark

Hi Dave,

A few fixes, mostly fallout from the address space refactor and dpu
color processing.


The following changes since commit 1cb2c4a2c89b2004a36399860c85a1af9b3fcba7:

  Revert "drm/msm/dpu: add support for clk and bw scaling for display"
(2020-06-01 20:56:18 -0700)

are available in the Git repository at:

  https://gitlab.freedesktop.org/drm/msm.git drm-msm-fixes-2020-06-25

for you to fetch changes up to 30480e6ed508e3ff7a3e03c975696aa5196ffe8a:

  drm/msm: Fix up the rest of the messed up address sizes (2020-06-22
12:12:29 -0700)


Bernard Zhao (1):
  drm/msm: fix potential memleak in error branch

Chen Tao (1):
  drm/msm/dpu: fix error return code in dpu_encoder_init

Eric Anholt (2):
  drm/msm: Fix address space size after refactor.
  drm/msm: Fix setup of a6xx create_address_space.

John Stultz (1):
  drm/msm: Fix 0xlub in "Refactor address space initialization"

Jordan Crouse (1):
  drm/msm: Fix up the rest of the messed up address sizes

Kalyan Thota (1):
  drm/msm/dpu: request for display color blocks based on hw catalog entry

Krishna Manikandan (1):
  drm/msm/dpu: allow initialization of encoder locks during encoder init

 drivers/gpu/drm/msm/adreno/a2xx_gpu.c   |  2 +-
 drivers/gpu/drm/msm/adreno/a6xx_gmu.c   |  2 +-
 drivers/gpu/drm/msm/adreno/a6xx_gpu.c   |  2 +-
 drivers/gpu/drm/msm/adreno/adreno_gpu.c |  2 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 18 +++---
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c |  2 +-
 drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c|  2 +-
 drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c|  2 +-
 drivers/gpu/drm/msm/msm_submitqueue.c   |  4 +++-
 9 files changed, 21 insertions(+), 15 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH V2 00/11] Subject: Remove duplicated kmap code

2020-05-05 Thread Al Viro

On Mon, May 04, 2020 at 01:17:41PM -0700, Ira Weiny wrote:

> > || * arm: much, much worse.  We have several files that pull 
> > linux/highmem.h:
> > || arch/arm/mm/cache-feroceon-l2.c, arch/arm/mm/cache-xsc3l2.c,
> > || arch/arm/mm/copypage-*.c, arch/arm/mm/dma-mapping.c, arch/arm/mm/flush.c,
> > || arch/arm/mm/highmem.c, arch/arm/probes/uprobes/core.c,
> > || arch/arm/include/asm/kvm_mmu.h (kmap_atomic_pfn()).
> > || Those are fine, but we also have this:
> > || arch/arm/include/asm/pgtable.h:200:#define __pte_map(pmd)   
> > (pte_t *)kmap_atomic(pmd_page(*(pmd)))
> > || arch/arm/include/asm/pgtable.h:208:#define pte_offset_map(pmd,addr) 
> > (__pte_map(pmd) + pte_index(addr))
> > || and sure as hell, asm/pgtable.h does *NOT* pull linux/highmem.h.
> 
> It does not pull asm/highmem.h either...

No, but the users of those macros need to be considered.

> > || #define pte_offset_map(dir, addr)   \
> > || ((pte_t *) kmap_atomic(pmd_page(*(dir))) + pte_index(addr))
> > || One pte_offset_map user in arch/microblaze:
> > || arch/microblaze/kernel/signal.c:207:ptep = pte_offset_map(pmdp, 
> > address);
> > || Messy, but doesn't require any changes (we have asm/pgalloc.h included
> > || there, and that pull linux/highmem.h).
> 
> AFAICS asm/pgtable.h does not include asm/highmem.h here...
> 
> So looks like arch/microblaze/kernel/signal.c will need linux/highmem.h

See above - line 39 in there is
#include 
and line 14 in arch/microblaze/include/asm/pgalloc.h is
#include 
It's conditional upon CONFIG_MMU in there, but so's the use of
pte_offset_map() in arch/microblaze/kernel/signal.c 

So it shouldn't be a problem.

> > || * xtensa: users in arch/xtensa/kernel/pci-dma.c, 
> > arch/xtensa/mm/highmem.c,
> > || arch/xtensa/mm/cache.c and arch/xtensa/platforms/iss/simdisk.c (all pull
> > || linux/highmem.h).
> 
> Actually
> 
> arch/xtensa/mm/cache.c gets linux/highmem.h from linux/pagemap.h
> 
> arch/xtensa/platforms/iss/simdisk.c may have an issue?
>   linux/blkdev.h -> CONFIG_BLOCK -> linux/pagemap.h -> linux/highmem.h
>   But simdisk.c requires BLK_DEV_SIMDISK -> CONFIG_BLOCK...
>   

Yep - see above re major chain of indirect includes conditional upon 
CONFIG_BLOCK
and its uses in places that only build with such configs.  There's a plenty of
similar considerations outside of arch/*, unfortunately...
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH V2 00/11] Subject: Remove duplicated kmap code

2020-05-04 Thread Ira Weiny

On Mon, May 04, 2020 at 10:02:25PM +0100, Al Viro wrote:
> On Mon, May 04, 2020 at 01:17:41PM -0700, Ira Weiny wrote:
> 
> > > || * arm: much, much worse.  We have several files that pull 
> > > linux/highmem.h:
> > > || arch/arm/mm/cache-feroceon-l2.c, arch/arm/mm/cache-xsc3l2.c,
> > > || arch/arm/mm/copypage-*.c, arch/arm/mm/dma-mapping.c, 
> > > arch/arm/mm/flush.c,
> > > || arch/arm/mm/highmem.c, arch/arm/probes/uprobes/core.c,
> > > || arch/arm/include/asm/kvm_mmu.h (kmap_atomic_pfn()).
> > > || Those are fine, but we also have this:
> > > || arch/arm/include/asm/pgtable.h:200:#define __pte_map(pmd)  
> > >  (pte_t *)kmap_atomic(pmd_page(*(pmd)))
> > > || arch/arm/include/asm/pgtable.h:208:#define pte_offset_map(pmd,addr)
> > >  (__pte_map(pmd) + pte_index(addr))
> > > || and sure as hell, asm/pgtable.h does *NOT* pull linux/highmem.h.
> > 
> > It does not pull asm/highmem.h either...
> 
> No, but the users of those macros need to be considered.

Agreed, I was trying to point out that highmem.h was being pulled from
somewhere else prior to my series, sorry.

> 
> > > || #define pte_offset_map(dir, addr)   \
> > > || ((pte_t *) kmap_atomic(pmd_page(*(dir))) + pte_index(addr))
> > > || One pte_offset_map user in arch/microblaze:
> > > || arch/microblaze/kernel/signal.c:207:ptep = pte_offset_map(pmdp, 
> > > address);
> > > || Messy, but doesn't require any changes (we have asm/pgalloc.h included
> > > || there, and that pull linux/highmem.h).
> > 
> > AFAICS asm/pgtable.h does not include asm/highmem.h here...
> > 
> > So looks like arch/microblaze/kernel/signal.c will need linux/highmem.h
> 
> See above - line 39 in there is
> #include 
> and line 14 in arch/microblaze/include/asm/pgalloc.h is
> #include 
> It's conditional upon CONFIG_MMU in there, but so's the use of
> pte_offset_map() in arch/microblaze/kernel/signal.c 
> 
> So it shouldn't be a problem.

Ah ok, I did not see that one.  Ok I'll drop that change and this series should
be good.

I was setting up to submit another version with 3 more patches you have
suggested:

kmap: Remove kmap_atomic_to_page()
parisc/kmap: Remove duplicate kmap code
sparc: Remove unnecessary includes

Would you like to see those folded in?  I submitted 2 of the above as a
separate series already.

> 
> > > || * xtensa: users in arch/xtensa/kernel/pci-dma.c, 
> > > arch/xtensa/mm/highmem.c,
> > > || arch/xtensa/mm/cache.c and arch/xtensa/platforms/iss/simdisk.c (all 
> > > pull
> > > || linux/highmem.h).
> > 
> > Actually
> > 
> > arch/xtensa/mm/cache.c gets linux/highmem.h from linux/pagemap.h
> > 
> > arch/xtensa/platforms/iss/simdisk.c may have an issue?
> > linux/blkdev.h -> CONFIG_BLOCK -> linux/pagemap.h -> linux/highmem.h
> > But simdisk.c requires BLK_DEV_SIMDISK -> CONFIG_BLOCK...
> > 
> 
> Yep - see above re major chain of indirect includes conditional upon 
> CONFIG_BLOCK
> and its uses in places that only build with such configs.  There's a plenty of
> similar considerations outside of arch/*, unfortunately...

Indeed.

FWIW the last 2 versions of this series have had no build failures with 0-day.

This series in particular just finished 164 configs without issue.

Would you like me to submit a new series?  With your additional patches?

Ira
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH V2 00/11] Subject: Remove duplicated kmap code

2020-05-04 Thread Ira Weiny

On Mon, May 04, 2020 at 06:33:57AM +0100, Al Viro wrote:
> On Sun, May 03, 2020 at 10:04:47PM -0700, Ira Weiny wrote:
> 
> > Grepping for 'asm/highmem.h' and investigations don't reveal any issues...  
> > But
> > you do have me worried.  That said 0-day has been crunching on multiple
> > versions of this series without issues such as this (save the mips issue
> > above).
> > 
> > I have to say it would be nice if the relation between linux/highmem.h and
> > asm/highmem.h was more straightforward.
> 
> IIRC, the headache was due to asm/pgtable.h on several architectures and
> asm/cacheflush.h on parisc.
> 
> 
> 
> || IOW, there's one in linux/highmem.h (conditional on 
> !CONFIG_HIGHMEM,
> || !ARCH_HAS_KMAP) and several per-architecture variants, usually declared in
> || their asm/highmem.h.  In three of those (microblaze, parisc and powerpc) 
> these
> || are inlines (parisc one identical to linux/highmem.h, lives in 
> asm/cacheflush.h,
> || powerpc and microblaze ones calling kmap_atomic_prot() which is defined in
> || arch/$ARCH/mm/highmem.c).
> || 
> || parisc case is weird - essentially, they want to call 
> || flush_kernel_dcache_page_addr() at the places where kunmap/kunmap_atomic
> || is done.  And they do so despite not selecting HIGHMEM, with definitions
> || in usual place.  They do have ARCH_HAS_KMAP defined, which prevents
> || getting buggered in linux/highmem.h.  ARCH_HAS_KMAP is parisc-unique,
> || BTW, and checked only in linux/highmem.h.
> || 
> || All genuine arch-specific variants are defined in (or call 
> functions
> || defined in) translation units that are only included CONFIG_HIGHMEM builds.

I agree with this statement.  But IMO additional confusion is caused by the
fact that some arch's condition the declarations on CONFIG_HIGHMEM within
asm/highmem.h (arc, arm, nds32) while others depend on linux/highmem.h (and
elsewhere) to do so (csky, microblaze, mips, powerpc, sparc, x86, xtensa).

Why?

I think (perhaps naive) over time asm/highmem.h needs to be isolated to being
included in linux/highmem.h.  But as you point out below that is not so easy.
I think that this series helps toward that goal.

> || 
> || It would be tempting to consolidate those, e.g. by adding 
> __kmap_atomic()
> || and __kmap_atomic_prot() without that boilerplate, with universal 
> kmap_atomic()
> || and kmap_atomic_prot() in linux/highmem.h.  Potential problem with that 
> would
> || be something that pulls ash/highmem.h (or asm/cacheflush.h in case of 
> parisc)
> || directly and uses kmap_atomic/kmap_atomic_prot.  There's not a lot places
> || pulling asm/highmem.h, and many of them are not even in includes:
> || 
> || arch/arm/include/asm/efi.h:13:#include 
> || arch/arm/mm/dma-mapping.c:31:#include 
> || arch/arm/mm/flush.c:14:#include 
> || arch/arm/mm/mmu.c:27:#include 
> || arch/mips/include/asm/pgtable-32.h:22:#include 
> || arch/mips/mm/cache.c:19:#include 
> || arch/mips/mm/fault.c:28:#include /* For 
> VMALLOC_END */
> || arch/nds32/include/asm/pgtable.h:60:#include 
> || arch/x86/kernel/setup_percpu.c:20:#include 
> || include/linux/highmem.h:35:#include 
> || 
> || Users of asm/cacheflush.h are rather more numerous; however, anything
> || outside of parisc-specific code has to pull linux/highmem.h, or it won't 
> see
> || the definitions of kmap_atomic/kmap_atomic_prot at all.  arch/parisc itself
> || has no callers of those.
> || 
> || Outside of arch/* there is a plenty of callers.  However, the following is
> || true: all instances of kmap_atomic or kmap_atomic_prot outside of arch/*
> || are either inside the linux/highmem.h or are preceded by include of
> || linux/highmem.h on any build that sees them (there is a common include
> || chain that is conditional upon CONFIG_BLOCK, but it's only needed in
> || drivers that are BLOCK-dependent).  It was not fun to verify, to put
> || it mildly...
> || 
> || So for parisc we have no problem - leaving 
> __kmap_atomic()/__kmap_atomic_prot()
> || in asm/cachefile.h and adding universal wrappers in linux/highmem.h will be
> || fine.  For other architectures the things might be trickier.

And the follow up series removes kmap_* from asm/cachefile.h in parisc which
should be cleaner going forward.

> || 
> || * arc: all users in arch/arc/ are within arch/arc/mm/{cache,highmem}.c;
> || both pull linux/highmem.h.  We are fine.

Still fine.

> || 
> || * arm: much, much worse.  We have several files that pull linux/highmem.h:
> || arch/arm/mm/cache-feroceon-l2.c, arch/arm/mm/cache-xsc3l2.c,
> || arch/arm/mm/copypage-*.c, arch/arm/mm/dma-mapping.c, arch/arm/mm/flush.c,
> || arch/arm/mm/highmem.c, arch/arm/probes/uprobes/core.c,
> || arch/arm/include/asm/kvm_mmu.h (kmap_atomic_pfn()).
> || Those are fine, but we also have this:
> || arch/arm/include/asm/pgtable.h:200:#define __pte_map(pmd)   
> (pte_t *)kmap_atomic(pmd_page(*(pmd)))
> || arch/arm/include/asm/pgtable.h:208:#define

Re: [PATCH V2 00/11] Subject: Remove duplicated kmap code

2020-05-04 Thread Al Viro

On Sun, May 03, 2020 at 06:09:01PM -0700, ira.we...@intel.com wrote:
> From: Ira Weiny 
> 
> The kmap infrastructure has been copied almost verbatim to every architecture.
> This series consolidates obvious duplicated code by defining core functions
> which call into the architectures only when needed.
> 
> Some of the k[un]map_atomic() implementations have some similarities but the
> similarities were not sufficient to warrant further changes.
> 
> In addition we remove a duplicate implementation of kmap() in DRM.
> 
> Testing was done by 0day to cover all the architectures I can't readily
> build/test.

OK...  Looking through my old notes on kmap unification (this winter, never
went anywhere),

* arch/mips/mm/cache.c ought to use linux/highmem.h, not asm/highmem.h
I suspect that your series doesn't build on some configs there.  Hadn't
verified that, though.

* kmap_atomic_to_page() is dead, but not quite gone - csky and nds32 brought
the damn thing back (nds32 - only an extern).  It needs killin'...

* parisc is (arguably) abusing kunmap()/kunmap_atomic() for cache flushing.
Replace the bulk of its highmem.h with
#define ARCH_HAS_FLUSH_ON_KUNMAP
#define arch_before_kunmap flush_kernel_dcache_page_addr
and have default kunmap()/kunmap_atomic() do
#ifdef ARCH_HAS_FLUSH_ON_KUNMAP
arch_before_kunmap(page_address(page));
#endif
and
#ifdef ARCH_HAS_FLUSH_ON_KUNMAP
arch_before_kunmap(addr);
#endif
resp.  Kills ARCH_HAS_KMAP along with ifdefs on it, makes parisc use somewhat
less hacky.

I'd suggest checking various configs on mips - that's likely to cause headache.
Said that, my analysis of include chains back then is pretty much worthless
by now - I really hate the amount of indirect include chains leading to that
sucker on some, but not all configs ;-/  IIRC, the proof that everything
using kmap*/kunmap* would pull linux/highmem.h regardless of config took several
hours of digging, ran for several pages and had been hopelessly brittle.
arch/mips/mm/cache.c was the only exception caught by it, but these days
there might be more.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH V2 00/11] Subject: Remove duplicated kmap code

2020-05-04 Thread Al Viro

On Sun, May 03, 2020 at 10:04:47PM -0700, Ira Weiny wrote:

> Grepping for 'asm/highmem.h' and investigations don't reveal any issues...  
> But
> you do have me worried.  That said 0-day has been crunching on multiple
> versions of this series without issues such as this (save the mips issue
> above).
> 
> I have to say it would be nice if the relation between linux/highmem.h and
> asm/highmem.h was more straightforward.

IIRC, the headache was due to asm/pgtable.h on several architectures and
asm/cacheflush.h on parisc.

|| IOW, there's one in linux/highmem.h (conditional on !CONFIG_HIGHMEM,
|| !ARCH_HAS_KMAP) and several per-architecture variants, usually declared in
|| their asm/highmem.h.  In three of those (microblaze, parisc and powerpc) 
these
|| are inlines (parisc one identical to linux/highmem.h, lives in 
asm/cacheflush.h,
|| powerpc and microblaze ones calling kmap_atomic_prot() which is defined in
|| arch/$ARCH/mm/highmem.c).
|| 
|| parisc case is weird - essentially, they want to call 
|| flush_kernel_dcache_page_addr() at the places where kunmap/kunmap_atomic
|| is done.  And they do so despite not selecting HIGHMEM, with definitions
|| in usual place.  They do have ARCH_HAS_KMAP defined, which prevents
|| getting buggered in linux/highmem.h.  ARCH_HAS_KMAP is parisc-unique,
|| BTW, and checked only in linux/highmem.h.
|| 
|| All genuine arch-specific variants are defined in (or call functions
|| defined in) translation units that are only included CONFIG_HIGHMEM builds.
|| 
|| It would be tempting to consolidate those, e.g. by adding 
__kmap_atomic()
|| and __kmap_atomic_prot() without that boilerplate, with universal 
kmap_atomic()
|| and kmap_atomic_prot() in linux/highmem.h.  Potential problem with that would
|| be something that pulls ash/highmem.h (or asm/cacheflush.h in case of parisc)
|| directly and uses kmap_atomic/kmap_atomic_prot.  There's not a lot places
|| pulling asm/highmem.h, and many of them are not even in includes:
|| 
|| arch/arm/include/asm/efi.h:13:#include 
|| arch/arm/mm/dma-mapping.c:31:#include 
|| arch/arm/mm/flush.c:14:#include 
|| arch/arm/mm/mmu.c:27:#include 
|| arch/mips/include/asm/pgtable-32.h:22:#include 
|| arch/mips/mm/cache.c:19:#include 
|| arch/mips/mm/fault.c:28:#include /* For 
VMALLOC_END */
|| arch/nds32/include/asm/pgtable.h:60:#include 
|| arch/x86/kernel/setup_percpu.c:20:#include 
|| include/linux/highmem.h:35:#include 
|| 
|| Users of asm/cacheflush.h are rather more numerous; however, anything
|| outside of parisc-specific code has to pull linux/highmem.h, or it won't see
|| the definitions of kmap_atomic/kmap_atomic_prot at all.  arch/parisc itself
|| has no callers of those.
|| 
|| Outside of arch/* there is a plenty of callers.  However, the following is
|| true: all instances of kmap_atomic or kmap_atomic_prot outside of arch/*
|| are either inside the linux/highmem.h or are preceded by include of
|| linux/highmem.h on any build that sees them (there is a common include
|| chain that is conditional upon CONFIG_BLOCK, but it's only needed in
|| drivers that are BLOCK-dependent).  It was not fun to verify, to put
|| it mildly...
|| 
|| So for parisc we have no problem - leaving 
__kmap_atomic()/__kmap_atomic_prot()
|| in asm/cachefile.h and adding universal wrappers in linux/highmem.h will be
|| fine.  For other architectures the things might be trickier.
|| 
|| * arc: all users in arch/arc/ are within arch/arc/mm/{cache,highmem}.c;
|| both pull linux/highmem.h.  We are fine.
|| 
|| * arm: much, much worse.  We have several files that pull linux/highmem.h:
|| arch/arm/mm/cache-feroceon-l2.c, arch/arm/mm/cache-xsc3l2.c,
|| arch/arm/mm/copypage-*.c, arch/arm/mm/dma-mapping.c, arch/arm/mm/flush.c,
|| arch/arm/mm/highmem.c, arch/arm/probes/uprobes/core.c,
|| arch/arm/include/asm/kvm_mmu.h (kmap_atomic_pfn()).
|| Those are fine, but we also have this:
|| arch/arm/include/asm/pgtable.h:200:#define __pte_map(pmd)   
(pte_t *)kmap_atomic(pmd_page(*(pmd)))
|| arch/arm/include/asm/pgtable.h:208:#define pte_offset_map(pmd,addr) 
(__pte_map(pmd) + pte_index(addr))
|| and sure as hell, asm/pgtable.h does *NOT* pull linux/highmem.h.
|| 
|| Fortunately, the users of pte_offset_map() (__pte_map() has no other users)
|| are few, both in arch/arm and outside of arch.  All arm ones are pulling
|| linux/highmem (arch/arm/mm/{pgd,fault*}.c).  Outside of arch we have several
|| that pull highmem.h (by way of rmap.h or pagemap.h, usually):
|| fs/userfaultfd.c, mm/gup.c, mm/hmm.c, mm/huge_memory.c,
|| mm/khugepaged.c, mm/memory-failure.c, mm/memory.c, mm/migrate.c,
|| mm/mremap.c, mm/page_vma_mapped.c, mm/swap_state.c, mm/swapfile.c,
|| mm/vmalloc.c
|| and then there are these in linux/mm.h:
|| 
|| #define pte_offset_map_lock(mm, pmd, address, ptlp) \
|| ({  \
|| spinlock_t *__ptl = pte_lockptr(mm,

Re: [PATCH V2 00/11] Subject: Remove duplicated kmap code

2020-05-03 Thread Ira Weiny

On Mon, May 04, 2020 at 02:35:09AM +0100, Al Viro wrote:
> On Sun, May 03, 2020 at 06:09:01PM -0700, ira.we...@intel.com wrote:
> > From: Ira Weiny 
> > 
> > The kmap infrastructure has been copied almost verbatim to every 
> > architecture.
> > This series consolidates obvious duplicated code by defining core functions
> > which call into the architectures only when needed.
> > 
> > Some of the k[un]map_atomic() implementations have some similarities but the
> > similarities were not sufficient to warrant further changes.
> > 
> > In addition we remove a duplicate implementation of kmap() in DRM.
> > 
> > Testing was done by 0day to cover all the architectures I can't readily
> > build/test.
> 
> OK...  Looking through my old notes on kmap unification (this winter, never
> went anywhere),
> 
> * arch/mips/mm/cache.c ought to use linux/highmem.h, not asm/highmem.h
> I suspect that your series doesn't build on some configs there.  Hadn't
> verified that, though.

Yes patch 6 makes the change because kmap_atomic() was no longer declared in
asm/highmem.h.  I'm pretty sure 0-day caught that ...  but I seem to remember
noticing some oddness in that file and I did go through it by hand.

> 
> * kmap_atomic_to_page() is dead, but not quite gone - csky and nds32 brought
> the damn thing back (nds32 - only an extern).  It needs killin'...

Easy enough. Added as a follow on patch.

> 
> * parisc is (arguably) abusing kunmap()/kunmap_atomic() for cache flushing.
> Replace the bulk of its highmem.h with
> #define ARCH_HAS_FLUSH_ON_KUNMAP
> #define arch_before_kunmap flush_kernel_dcache_page_addr
> and have default kunmap()/kunmap_atomic() do
> #ifdef ARCH_HAS_FLUSH_ON_KUNMAP
>   arch_before_kunmap(page_address(page));
> #endif
> and
> #ifdef ARCH_HAS_FLUSH_ON_KUNMAP
>   arch_before_kunmap(addr);
> #endif
> resp.  Kills ARCH_HAS_KMAP along with ifdefs on it, makes parisc use somewhat
> less hacky.

Agreed.  Done in a follow on patch.

> 
> I'd suggest checking various configs on mips - that's likely to cause 
> headache.
> Said that, my analysis of include chains back then is pretty much worthless
> by now - I really hate the amount of indirect include chains leading to that
> sucker on some, but not all configs ;-/  IIRC, the proof that everything
> using kmap*/kunmap* would pull linux/highmem.h regardless of config took 
> several
> hours of digging, ran for several pages and had been hopelessly brittle.
> arch/mips/mm/cache.c was the only exception caught by it, but these days
> there might be more.

Grepping for 'asm/highmem.h' and investigations don't reveal any issues...  But
you do have me worried.  That said 0-day has been crunching on multiple
versions of this series without issues such as this (save the mips issue
above).

I have to say it would be nice if the relation between linux/highmem.h and
asm/highmem.h was more straightforward.

Ira

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH V2 00/11] Subject: Remove duplicated kmap code

2020-05-03 Thread ira . weiny

From: Ira Weiny 

The kmap infrastructure has been copied almost verbatim to every architecture.
This series consolidates obvious duplicated code by defining core functions
which call into the architectures only when needed.

Some of the k[un]map_atomic() implementations have some similarities but the
similarities were not sufficient to warrant further changes.

In addition we remove a duplicate implementation of kmap() in DRM.

Testing was done by 0day to cover all the architectures I can't readily
build/test.

---
Changes from V1:
Fix bisect-ability
Update commit message and fix line lengths
Remove unneded kunmap_atomic_high() declarations
Remove unneded kmap_atomic_high() declarations
collect reviews
rebase to 5.7-rc4

Changes from V0:
Define kmap_flush_tlb() and make kmap() truely arch independent.
Redefine the k[un]map_atomic_* code to call into the architectures for
high mem pages
Ensure all architectures define kmap_prot, use it appropriately, and
define kmap_atomic_prot()
Remove drm implementation of kmap_atomic()

Ira Weiny (11):
  arch/kmap: Remove BUG_ON()
  arch/xtensa: Move kmap build bug out of the way
  arch/kmap: Remove redundant arch specific kmaps
  arch/kunmap: Remove duplicate kunmap implementations
  {x86,powerpc,microblaze}/kmap: Move preempt disable
  arch/kmap_atomic: Consolidate duplicate code
  arch/kunmap_atomic: Consolidate duplicate code
  arch/kmap: Ensure kmap_prot visibility
  arch/kmap: Don't hard code kmap_prot values
  arch/kmap: Define kmap_atomic_prot() for all arch's
  drm: Remove drm specific kmap_atomic code

 arch/arc/include/asm/highmem.h| 15 ---
 arch/arc/mm/highmem.c | 28 +++-
 arch/arm/include/asm/highmem.h|  7 ---
 arch/arm/mm/highmem.c | 35 +++
 arch/csky/include/asm/highmem.h   |  9 +---
 arch/csky/mm/highmem.c| 43 +--
 arch/microblaze/include/asm/highmem.h | 28 +---
 arch/microblaze/mm/highmem.c  | 16 ++-
 arch/microblaze/mm/init.c |  3 --
 arch/mips/include/asm/highmem.h   |  9 +---
 arch/mips/mm/cache.c  |  6 +--
 arch/mips/mm/highmem.c| 49 -
 arch/nds32/include/asm/highmem.h  |  7 ---
 arch/nds32/mm/highmem.c   | 39 +++--
 arch/parisc/include/asm/cacheflush.h  |  4 +-
 arch/powerpc/include/asm/highmem.h| 29 +
 arch/powerpc/mm/highmem.c | 21 ++---
 arch/powerpc/mm/mem.c |  3 --
 arch/sparc/include/asm/highmem.h  | 22 --
 arch/sparc/mm/highmem.c   | 18 +++-
 arch/x86/include/asm/highmem.h|  9 
 arch/x86/mm/highmem_32.c  | 50 ++---
 arch/xtensa/include/asm/highmem.h | 27 
 arch/xtensa/mm/highmem.c  | 22 --
 drivers/gpu/drm/ttm/ttm_bo_util.c | 56 ++--
 drivers/gpu/drm/vmwgfx/vmwgfx_blit.c  | 16 +++
 include/drm/ttm/ttm_bo_api.h  |  4 --
 include/linux/highmem.h   | 62 +--
 28 files changed, 140 insertions(+), 497 deletions(-)

-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[no subject]

2020-02-26 Thread Ville Syrjälä

Subject: Re: [PATCH 04/12] drm: Nuke mode->vrefresh
Message-ID: <20200226115708.gh13...@intel.com>
References: <20200219203544.31013-1-ville.syrj...@linux.intel.com>
 

 <20200219203544.31013-5-ville.syrj...@linux.intel.com>
 <0f278771-79ce-fe23-e72c-3935dbe82...@samsung.com>
 <20200225112114.ga13...@intel.com>
 <3ca785f2-9032-aaf9-0965-8657d3111...@samsung.com>
 <20200225154506.gf13...@intel.com>
 <20200225192720.gg13...@intel.com>
 
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 

X-Patchwork-Hint: comment
User-Agent: Mutt/1.10.1 (2018-07-13)

On Tue, Feb 25, 2020 at 10:52:25PM +0100, Linus Walleij wrote:
> On Tue, Feb 25, 2020 at 8:27 PM Ville Syrjälä
>  wrote:
> 
> > OK, so I went ahead a wrote a bit of cocci [1] to find the bad apples.
> 
> That's impressive :D
> 
> > Unfortunately it found a lot of strange stuff:
> 
> I will answer for the weirdness I caused.
> 
> I have long suspected that a whole bunch of the "simple" displays
> are not simple but contains a display controller and memory.
> That means that the speed over the link to the display and
> actual refresh rate on the actual display is asymmetric because
> well we are just updating a RAM, the resolution just limits how
> much data we are sending, the clock limits the speed on the
> bus over to the RAM on the other side.

IMO even in command mode mode->clock should probably be the actual
dotclock used by the display. If there's another clock for the bus
speed/etc. it should be stored somewhere else.

-- 
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 4/5] Subject: drm/amdgpu: Redo XGMI reset synchronization.

2019-12-13 Thread Andrey Grodzovsky

Use task barrier in XGMI hive to synchronize ASIC resets
across devices in XGMI hive.

v2: Retrun right away with a warning if no xgmi hive, update doc.
Signed-off-by: Andrey Grodzovsky 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 37 +-
 1 file changed, 31 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 1d19edfa..2ae944c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -67,6 +67,7 @@
 #include "amdgpu_tmz.h"
 
 #include 
+#include 
 
 MODULE_FIRMWARE("amdgpu/vega10_gpu_info.bin");
 MODULE_FIRMWARE("amdgpu/vega12_gpu_info.bin");
@@ -2663,14 +2664,38 @@ static void amdgpu_device_xgmi_reset_func(struct 
work_struct *__work)
 {
struct amdgpu_device *adev =
container_of(__work, struct amdgpu_device, xgmi_reset_work);
+   struct amdgpu_hive_info *hive = amdgpu_get_xgmi_hive(adev, 0);
 
-   if (amdgpu_asic_reset_method(adev) == AMD_RESET_METHOD_BACO)
-   adev->asic_reset_res = (adev->in_baco == false) ?
-   amdgpu_device_baco_enter(adev->ddev) :
-   qamdgpu_device_baco_exit(adev->ddev);
-   else
-   adev->asic_reset_res = amdgpu_asic_reset(adev);
+   /* It's a bug to not have a hive within this function */
+   if (WARN_ON(!hive))
+   return;
+
+   /*
+* Use task barrier to synchronize all xgmi reset works across the
+* hive. task_barrier_enter and task_barrier_exit will block
+* until all the threads running the xgmi reset works reach
+* those points. task_barrier_full will do both blocks.
+*/
+   if (amdgpu_asic_reset_method(adev) == AMD_RESET_METHOD_BACO) {
+
+   task_barrier_enter(>tb);
+   adev->asic_reset_res = amdgpu_device_baco_enter(adev->ddev);
+
+   if (adev->asic_reset_res)
+   goto fail;
+
+   task_barrier_exit(>tb);
+   adev->asic_reset_res = amdgpu_device_baco_exit(adev->ddev);
+
+   if (adev->asic_reset_res)
+   goto fail;
+   } else {
+
+   task_barrier_full(>tb);
+   adev->asic_reset_res =  amdgpu_asic_reset(adev);
+   }
 
+fail:
if (adev->asic_reset_res)
DRM_WARN("ASIC reset failed with error, %d for drm dev, %s",
 adev->asic_reset_res, adev->ddev->unique);
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RESEND PATCH 4/5] Subject: drm/amdgpu: Redo XGMI reset synchronization.

2019-12-12 Thread Andrey Grodzovsky



On 12/11/19 11:05 PM, Ma, Le wrote:


[AMD Official Use Only - Internal Distribution Only]

-Original Message-
From: Andrey Grodzovsky 
Sent: Thursday, December 12, 2019 4:39 AM
To: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org
Cc: Deucher, Alexander ; Ma, Le 
; Zhang, Hawking ; Quan, Evan 
; Grodzovsky, Andrey 
Subject: [RESEND PATCH 4/5] Subject: drm/amdgpu: Redo XGMI reset 
synchronization.


Use task barrier in XGMI hive to synchronize ASIC resets across 
devices in XGMI hive.


Signed-off-by: Andrey Grodzovsky <mailto:andrey.grodzov...@amd.com>>


---

drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 42 
+-


1 file changed, 36 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c


index 1d19edfa..e4089a0 100644

--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c

+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c

@@ -67,6 +67,7 @@

#include "amdgpu_tmz.h"

 #include 

+#include 

 MODULE_FIRMWARE("amdgpu/vega10_gpu_info.bin");

MODULE_FIRMWARE("amdgpu/vega12_gpu_info.bin");

@@ -2663,14 +2664,43 @@ static void 
amdgpu_device_xgmi_reset_func(struct work_struct *__work)  {


   struct amdgpu_device *adev =

container_of(__work, struct amdgpu_device, xgmi_reset_work);

+  struct amdgpu_hive_info *hive = amdgpu_get_xgmi_hive(adev, 0);

-   if (amdgpu_asic_reset_method(adev) == AMD_RESET_METHOD_BACO)

- adev->asic_reset_res = (adev->in_baco == false) ?

- amdgpu_device_baco_enter(adev->ddev) :

- qamdgpu_device_baco_exit(adev->ddev);

-   else

- adev->asic_reset_res = amdgpu_asic_reset(adev);

+  /*

+  * Use task barrier to synchronize all xgmi reset works 
across the


+  * hive.

+  * task_barrier_enter and task_barrier_exit will block 
untill all the


+  * threads running the xgmi reset works reach those points. 
I assume


+  * guarantee of progress here for all the threads as the 
workqueue code


+  * creates new worker threads as needed by amount of work 
items in queue


+  * (see worker_thread) and also each thread sleeps in the 
barrir and by


+  * this yielding the CPU for other work threads to make 
progress.


+  */

[Le]: This comments can be adjusted since we switch to 
system_unbound_wq in patch #5.


+  if (amdgpu_asic_reset_method(adev) == AMD_RESET_METHOD_BACO) {

+

+  if (hive)

+ task_barrier_enter(>tb);

[Le]: The multiple hive condition can be checked only once and moved 
to the location right after the assignment.




Not sure what you meant here but in fact let's note that while in 
amdgpu_device_xgmi_reset_func it's a bug for amdgpu_get_xgmi_hive to 
return NULL so I think better instead to add WARN_ON(!hive,"...") and 
return right at the beginning of the function if indeed hive == NULL


Andrey



+

+ adev->asic_reset_res = amdgpu_device_baco_enter(adev->ddev);

+

+  if (adev->asic_reset_res)

+  goto fail;

+

+  if (hive)

+ task_barrier_exit(>tb);

[Le]: Same as above.

+

+ adev->asic_reset_res = amdgpu_device_baco_exit(adev->ddev);

+

+  if (adev->asic_reset_res)

+  goto fail;

+  } else {

+  if (hive)

+ task_barrier_full(>tb);

[Le]: Same as above.

With above addressed, Reviewed-by: Le Ma <mailto:le...@amd.com>>


Regards,

Ma Le

+

+ adev->asic_reset_res =  amdgpu_asic_reset(adev);

+  }

+fail:

   if (adev->asic_reset_res)

   DRM_WARN("ASIC reset failed with error, %d for 
drm dev, %s",


 adev->asic_reset_res, adev->ddev->unique);

--

2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [RESEND PATCH 4/5] Subject: drm/amdgpu: Redo XGMI reset synchronization.

2019-12-11 Thread Ma, Le

[AMD Official Use Only - Internal Distribution Only]






-Original Message-
From: Andrey Grodzovsky 
Sent: Thursday, December 12, 2019 4:39 AM
To: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org
Cc: Deucher, Alexander ; Ma, Le ; 
Zhang, Hawking ; Quan, Evan ; 
Grodzovsky, Andrey 
Subject: [RESEND PATCH 4/5] Subject: drm/amdgpu: Redo XGMI reset 
synchronization.



Use task barrier in XGMI hive to synchronize ASIC resets across devices in XGMI 
hive.



Signed-off-by: Andrey Grodzovsky 
mailto:andrey.grodzov...@amd.com>>

---

drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 42 +-

1 file changed, 36 insertions(+), 6 deletions(-)



diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c

index 1d19edfa..e4089a0 100644

--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c

+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c

@@ -67,6 +67,7 @@

#include "amdgpu_tmz.h"



 #include 

+#include 



 MODULE_FIRMWARE("amdgpu/vega10_gpu_info.bin");

MODULE_FIRMWARE("amdgpu/vega12_gpu_info.bin");

@@ -2663,14 +2664,43 @@ static void amdgpu_device_xgmi_reset_func(struct 
work_struct *__work)  {

   struct amdgpu_device *adev =

   container_of(__work, struct amdgpu_device, 
xgmi_reset_work);

+  struct amdgpu_hive_info *hive = amdgpu_get_xgmi_hive(adev, 0);



-   if (amdgpu_asic_reset_method(adev) == AMD_RESET_METHOD_BACO)

-   adev->asic_reset_res = (adev->in_baco == false) ?

-   
amdgpu_device_baco_enter(adev->ddev) :

-   
qamdgpu_device_baco_exit(adev->ddev);

-   else

-   adev->asic_reset_res = amdgpu_asic_reset(adev);

+  /*

+  * Use task barrier to synchronize all xgmi reset works across the

+  * hive.

+  * task_barrier_enter and task_barrier_exit will block untill all the

+  * threads running the xgmi reset works reach those points. I assume

+  * guarantee of progress here for all the threads as the workqueue 
code

+  * creates new worker threads as needed by amount of work items in 
queue

+  * (see worker_thread) and also each thread sleeps in the barrir and 
by

+  * this yielding the CPU for other work threads to make progress.

+  */

[Le]: This comments can be adjusted since we switch to system_unbound_wq in 
patch #5.

+  if (amdgpu_asic_reset_method(adev) == AMD_RESET_METHOD_BACO) {

+

+  if (hive)

+  task_barrier_enter(>tb);

[Le]: The multiple hive condition can be checked only once and moved to the 
location right after the assignment.

+

+  adev->asic_reset_res = 
amdgpu_device_baco_enter(adev->ddev);

+

+  if (adev->asic_reset_res)

+  goto fail;

+

+  if (hive)

+  task_barrier_exit(>tb);

[Le]: Same as above.

+

+  adev->asic_reset_res = 
amdgpu_device_baco_exit(adev->ddev);

+

+  if (adev->asic_reset_res)

+  goto fail;

+  } else {

+  if (hive)

+  task_barrier_full(>tb);

[Le]: Same as above.



With above addressed, Reviewed-by: Le Ma mailto:le...@amd.com>>



Regards,

Ma Le

+

+  adev->asic_reset_res =  amdgpu_asic_reset(adev);

+  }



+fail:

   if (adev->asic_reset_res)

   DRM_WARN("ASIC reset failed with error, %d for drm dev, 
%s",

adev->asic_reset_res, adev->ddev->unique);

--

2.7.4


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RESEND PATCH 4/5] Subject: drm/amdgpu: Redo XGMI reset synchronization.

2019-12-11 Thread Andrey Grodzovsky

Use task barrier in XGMI hive to synchronize ASIC resets
across devices in XGMI hive.

Signed-off-by: Andrey Grodzovsky 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 42 +-
 1 file changed, 36 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 1d19edfa..e4089a0 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -67,6 +67,7 @@
 #include "amdgpu_tmz.h"
 
 #include 
+#include 
 
 MODULE_FIRMWARE("amdgpu/vega10_gpu_info.bin");
 MODULE_FIRMWARE("amdgpu/vega12_gpu_info.bin");
@@ -2663,14 +2664,43 @@ static void amdgpu_device_xgmi_reset_func(struct 
work_struct *__work)
 {
struct amdgpu_device *adev =
container_of(__work, struct amdgpu_device, xgmi_reset_work);
+   struct amdgpu_hive_info *hive = amdgpu_get_xgmi_hive(adev, 0);
 
-   if (amdgpu_asic_reset_method(adev) == AMD_RESET_METHOD_BACO)
-   adev->asic_reset_res = (adev->in_baco == false) ?
-   amdgpu_device_baco_enter(adev->ddev) :
-   qamdgpu_device_baco_exit(adev->ddev);
-   else
-   adev->asic_reset_res = amdgpu_asic_reset(adev);
+   /*
+* Use task barrier to synchronize all xgmi reset works across the
+* hive.
+* task_barrier_enter and task_barrier_exit will block untill all the
+* threads running the xgmi reset works reach those points. I assume
+* guarantee of progress here for all the threads as the workqueue code
+* creates new worker threads as needed by amount of work items in queue
+* (see worker_thread) and also each thread sleeps in the barrir and by
+* this yielding the CPU for other work threads to make progress.
+*/
+   if (amdgpu_asic_reset_method(adev) == AMD_RESET_METHOD_BACO) {
+
+   if (hive)
+   task_barrier_enter(>tb);
+
+   adev->asic_reset_res = amdgpu_device_baco_enter(adev->ddev);
+
+   if (adev->asic_reset_res)
+   goto fail;
+
+   if (hive)
+   task_barrier_exit(>tb);
+
+   adev->asic_reset_res = amdgpu_device_baco_exit(adev->ddev);
+
+   if (adev->asic_reset_res)
+   goto fail;
+   } else {
+   if (hive)
+   task_barrier_full(>tb);
+
+   adev->asic_reset_res =  amdgpu_asic_reset(adev);
+   }
 
+fail:
if (adev->asic_reset_res)
DRM_WARN("ASIC reset failed with error, %d for drm dev, %s",
 adev->asic_reset_res, adev->ddev->unique);
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[no subject]

2019-11-05 Thread Rob Clark

Hi Dave,

This time around:

+ OCMEM support to enable the couple generations that had shared OCMEM
  rather than GMEM exclusively for the GPU (late a3xx and I think basically
  all of a4xx).  Bjorn and Brian decided to land this through the drm
  tree to avoid having to coordinate merge requests.
+ a510 support, and various associated display support
+ the usual misc cleanups and fixes

The following changes since commit da0c9ea146cbe92b832f1b0f694840ea8eb33cce:
  Linux 5.4-rc2 (2019-10-06 14:27:30 -0700)

are available in the Git repository at:

  https://gitlab.freedesktop.org/drm/msm.git drm-msm-next-2019-11-05

for you to fetch changes up to e20c9284c8f212081afc28471daaac9b0d54252f:

  drm/msm/adreno: Add support for Adreno 510 GPU (2019-11-04 13:18:31 -0800)


AngeloGioacchino Del Regno (6):
  drm/msm/mdp5: Add optional TBU and TBU_RT clocks
  dt-bindings: msm/mdp5: Document optional TBU and TBU_RT clocks
  drm/msm/mdp5: Add configuration for msm8x76
  drm/msm/dsi: Add configuration for 28nm PLL on family B
  drm/msm/dsi: Add configuration for 8x76
  drm/msm/adreno: Add support for Adreno 510 GPU

Arnd Bergmann (1):
  drm/msm: include linux/sched/task.h

Ben Dooks (2):
  drm/msm: make a5xx_show and a5xx_gpu_state_put static
  drm/msm/mdp5: make config variables static

Brian Masney (6):
  dt-bindings: soc: qcom: add On Chip MEMory (OCMEM) bindings
  dt-bindings: display: msm: gmu: add optional ocmem property
  soc: qcom: add OCMEM driver
  drm/msm/gpu: add ocmem init/cleanup functions
  soc: qcom: ocmem: add missing includes
  drm/msm/hdmi: silence -EPROBE_DEFER warning

Drew Davenport (7):
  drm/msm/dpu: Remove unused variables
  drm/msm/dpu: Remove unused macro
  drm/msm/dpu: Remove unnecessary NULL checks
  drm/msm/dpu: Remove unnecessary NULL checks
  drm/msm/dpu: Remove unnecessary NULL checks
  drm/msm/dpu: Remove unnecessary NULL checks
  drm/msm: Remove unused function arguments

Krzysztof Wilczynski (1):
  drm/msm/dsi: Move static keyword to the front of declarations

Rob Clark (4):
  firmware: qcom: scm: add OCMEM lock/unlock interface
  firmware: qcom: scm: add support to restore secure config to qcm_scm-32
  drm/msm: fix rd dumping for split-IB1
  drm/msm: always dump buffer base/size

Sean Paul (1):
  drm/msm: Sanitize the modeset_is_locked checks in dpu

Stephan Gerhold (1):
  drm/msm/dsi: Implement qcom, dsi-phy-regulator-ldo-mode for 28nm PHY

zhengbin (11):
  drm/msm/dpu: Remove set but not used variable 'priv' in dpu_kms.c
  drm/msm/dpu: Remove set but not used variable 'priv' in
dpu_encoder_phys_vid.c
  drm/msm/dpu: Remove set but not used variable 'priv' in dpu_core_irq.c
  drm/msm/dpu: Remove set but not used variables 'dpu_cstate', 'priv'
  drm/msm/dpu: Remove set but not used variables 'cmd_enc', 'priv'
  drm/msm/dpu: Remove set but not used variables 'mode', 'dpu_kms', 'priv'
  drm/msm/mdp5: Remove set but not used variable 'fmt'
  drm/msm/mdp5: Remove set but not used variable 'hw_cfg' in blend_setup
  drm/msm/dsi: Remove set but not used variable 'lpx'
  drm/msm/dsi: Remove set but not used variable 'lp'
  drm/msm/mdp5: Remove set but not used variable 'hw_cfg' in modeset_init

 .../devicetree/bindings/display/msm/gmu.txt|  51 +++
 .../devicetree/bindings/display/msm/mdp5.txt   |   2 +
 .../devicetree/bindings/sram/qcom,ocmem.yaml   |  96 +
 drivers/firmware/qcom_scm-32.c |  52 ++-
 drivers/firmware/qcom_scm-64.c |  12 +
 drivers/firmware/qcom_scm.c|  53 +++
 drivers/firmware/qcom_scm.h|   9 +
 drivers/gpu/drm/msm/Kconfig|   1 +
 drivers/gpu/drm/msm/adreno/a3xx_gpu.c  |  28 +-
 drivers/gpu/drm/msm/adreno/a3xx_gpu.h  |   3 +-
 drivers/gpu/drm/msm/adreno/a4xx_gpu.c  |  25 +-
 drivers/gpu/drm/msm/adreno/a4xx_gpu.h  |   3 +-
 drivers/gpu/drm/msm/adreno/a5xx_gpu.c  |  79 +++-
 drivers/gpu/drm/msm/adreno/a5xx_power.c|   7 +
 drivers/gpu/drm/msm/adreno/adreno_device.c |  15 +
 drivers/gpu/drm/msm/adreno/adreno_gpu.c|  40 ++
 drivers/gpu/drm/msm/adreno/adreno_gpu.h|  15 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c   |  43 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c  |  21 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c   |  20 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c|  39 +-
 .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c   |  15 -
 .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c   |   7 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c|  60 +--
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h|   4 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_vbif.c   |   6 +-

[no subject]

2019-08-22 Thread Rob Herring

Subject: [PATCH v2 0/8] panfrost: Locking and runtime PM fixes

With further testing of recent changes with lockdep and other locking
checks enabled, we've found several bugs in the shrinker code and one
sleep while atomic in panfrost_gem_open(). This series addresses those
issues.

Delaying the unmapping of pages turns out to be a bad idea. Instead we 
need to rework panfrost_mmu_unmap() to not do a runtime PM resume which 
takes several locks and causes more lockdep warnings. Unfortunately, 
there initially appeared to be some mismatches between the runtime PM 
state and the h/w. The result is several fixes to the runtime PM 
initialization and handling in jobs. With this, the changes to 
panfrost_mmu_unmap() are working correctly.

v2:
 - Drop already applied 'drm/panfrost: Fix sleeping while atomic in 
   panfrost_gem_open'
 - Runtime PM clean-ups
 - Keep panfrost_gem_purge and use mutex_trylock there
 - Rework panfrost_mmu_unmap runtime PM

Rob

Rob Herring (8):
  drm/panfrost: Fix possible suspend in panfrost_remove
  drm/panfrost: Rework runtime PM initialization
  drm/panfrost: Hold runtime PM reference until jobs complete
  drm/shmem: Do dma_unmap_sg before purging pages
  drm/shmem: Use mutex_trylock in drm_gem_shmem_purge
  drm/panfrost: Use mutex_trylock in panfrost_gem_purge
  drm/panfrost: Rework page table flushing and runtime PM interaction
  drm/panfrost: Remove unnecessary flushing from tlb_inv_context

 drivers/gpu/drm/drm_gem_shmem_helper.c| 13 -
 drivers/gpu/drm/panfrost/panfrost_device.c|  9 
 drivers/gpu/drm/panfrost/panfrost_drv.c   | 16 ---
 .../gpu/drm/panfrost/panfrost_gem_shrinker.c  | 11 +++--
 drivers/gpu/drm/panfrost/panfrost_job.c   | 16 ---
 drivers/gpu/drm/panfrost/panfrost_mmu.c   | 47 +--
 include/drm/drm_gem_shmem_helper.h|  2 +-
 7 files changed, 59 insertions(+), 55 deletions(-)

-- 
2.20.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[no subject]

2019-07-22 Thread Sam Ravnborg

The first three patches prepare for the removal of drmP.h.
The last patch remove use of drmP.h and replace with necessary
include files to fix build.

Build tested with various configs and various architectures.

I had preferred that the via driver was replaced by the
openchrome driver, but until we have it then we need
to deal with the legacy via driver when removing old cruft
in the drm subsystem.

v3:
- Use static inline functions for the read/write operations (Emil)
- Use dedicated *_mask_or() and *_mask_and() (Emil)
- Replace DRM_WAIT_ON in same path that introduces VIA_WAIT_ON (Emil)
- Collected r-b's
- Changelog adjustments
- Rebased on top of drm-misc-next

v2:
- Add a copy of DRM_WAIT_ON to the via driver, keeping
  the changes to this legacy driver to a minimum.
  This also gives much more confidence that the
  driver continues to work as there is no changes
  in logic. Therefore dropped "RFT".
- Added Cc: Michel Dänzer  to all
  patches, as Michael have commented on the series.

Sam

Sam Ravnborg (4):
  drm/via: drop use of DRM(READ|WRITE) macros
  drm/via: copy DRM_WAIT_ON as VIA_WAIT_ON and use it
  drm/via: make via_drv.h self-contained
  drm/via: drop use of drmP.h

 drivers/gpu/drm/via/via_dma.c  | 43 +++-
 drivers/gpu/drm/via/via_dmablit.c  | 41 ++-
 drivers/gpu/drm/via/via_drv.c  |  7 +++-
 drivers/gpu/drm/via/via_drv.h  | 83 +++---
 drivers/gpu/drm/via/via_irq.c  | 54 +
 drivers/gpu/drm/via/via_map.c  |  6 ++-
 drivers/gpu/drm/via/via_mm.c   |  7 +++-
 drivers/gpu/drm/via/via_verifier.c | 22 +-
 drivers/gpu/drm/via/via_video.c|  5 ++-
 9 files changed, 182 insertions(+), 86 deletions(-)


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[no subject]

2019-06-06 Thread Dave Airlie

Hey Linus,

A small bit more lively this week but not majorly so. I'm away in
Japan next week for family holiday, so I'll be pretty disconnected,
I've asked Daniel to do fixes for the week while I'm out.

core:
- Allow fb changes in async commits (drivers as well)

udmabuf:
- Unmap scatterlist when unmapping udmabuf

komeda:
- oops, dma mapping and warning fixes

arm-hdlcd:
- clock fixes,
- mode validation fix

i915:
- Add a missing Icelake workaround
- GVT - DMA map fault fix and enforcement fixes

Dave.
amdgpu:
- DCE resume fix
- New raven variation updates



drm-fixes-2019-06-07:
drm i915, amdgpu, arm display, atomic update fixes
The following changes since commit f2c7c76c5d0a443053e94adb9f0918fa2fb85c3a:

  Linux 5.2-rc3 (2019-06-02 13:55:33 -0700)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2019-06-07

for you to fetch changes up to e659b4122cf9e0938b80215de6c06823fb4cf796:

  Merge tag 'drm-intel-fixes-2019-06-06' of
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes (2019-06-07
10:41:33 +1000)


drm i915, amdgpu, arm display, atomic update fixes


Aleksei Gimbitskii (2):
  drm/i915/gvt: Check if cur_pt_type is valid
  drm/i915/gvt: Assign NULL to the pointer after memory free.

Chengming Gui (1):
  drm/amd/powerplay: add set_power_profile_mode for raven1_refresh

Colin Xu (3):
  drm/i915/gvt: Update force-to-nonpriv register whitelist
  drm/i915/gvt: Fix GFX_MODE handling
  drm/i915/gvt: Fix vGPU CSFE_CHICKEN1_REG mmio handler

Dan Carpenter (1):
  drm/komeda: Potential error pointer dereference

Dave Airlie (5):
  Merge tag 'drm-intel-fixes-2019-06-03' of
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes
  Merge branch 'drm-fixes-5.2' of
git://people.freedesktop.org/~agd5f/linux into drm-fixes
  Merge tag 'drm-misc-fixes-2019-06-05' of
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes
  Merge branch 'malidp-fixes' of git://linux-arm.org/linux-ld into drm-fixes
  Merge tag 'drm-intel-fixes-2019-06-06' of
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes

Gao, Fred (1):
  drm/i915/gvt: Fix cmd length of VEB_DI_IECP

Helen Koike (5):
  drm/rockchip: fix fb references in async update
  drm/amd: fix fb references in async update
  drm/msm: fix fb references in async update
  drm/vc4: fix fb references in async update
  drm: don't block fb changes for async plane updates

Joonas Lahtinen (2):
  Merge tag 'gvt-fixes-2019-05-30' of
https://github.com/intel/gvt-linux into drm-intel-fixes
  Merge tag 'gvt-fixes-2019-06-05' of
https://github.com/intel/gvt-linux into drm-intel-fixes

Louis Li (1):
  drm/amdgpu: fix ring test failure issue during s3 in vce 3.0 (V2)

Lowry Li (Arm Technology China) (1):
  drm/komeda: fixing of DMA mapping sg segment warning

Lucas Stach (1):
  udmabuf: actually unmap the scatterlist

Prike Liang (1):
  drm/amd/amdgpu: add RLC firmware to support raven1 refresh

Robin Murphy (2):
  drm/arm/hdlcd: Actually validate CRTC modes
  drm/arm/hdlcd: Allow a bit of clock tolerance

Tina Zhang (1):
  drm/i915/gvt: Initialize intel_gvt_gtt_entry in stack

Tvrtko Ursulin (1):
  drm/i915/icl: Add WaDisableBankHangMode

Weinan Li (1):
  drm/i915/gvt: add F_CMD_ACCESS flag for wa regs

Wen He (1):
  drm/arm/mali-dp: Add a loop around the second set CVAL and try 5 times

Xiaolin Zhang (1):
  drm/i915/gvt: save RING_HEAD into vreg when vgpu switched out

Xiong Zhang (1):
  drm/i915/gvt: refine ggtt range validation

YueHaibing (1):
  drm/komeda: remove set but not used variable 'kcrtc'

james qian wang (Arm Technology China) (1):
  drm/komeda: Constify the usage of komeda_component/pipeline/dev_funcs

 drivers/dma-buf/udmabuf.c  |  1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 12 ++---
 drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 15 +++
 drivers/gpu/drm/amd/amdgpu/amdgpu_pm.h |  1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c|  4 +-
 drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c  | 12 -
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c  |  3 +-
 drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c|  1 +
 drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c  | 31 +++--
 drivers/gpu/drm/amd/powerplay/inc/hwmgr.h  |  1 +
 .../gpu/drm/arm/display/komeda/d71/d71_component.c |  8 ++--
 drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c   |  4 +-
 drivers/gpu/drm/arm/display/komeda/komeda_crtc.c   |  2 +-
 drivers/gpu/drm/arm/display/komeda/komeda_dev.c|  6 ++-
 drivers/gpu/drm/arm/display/komeda/komeda_dev.h|  8 ++--
 .../gpu/drm/arm/display/komeda/komeda_pipeline.c   |  4 +-
 .../gpu/drm/arm/display/komeda/komeda_pipeline.h   | 10 ++---

[no subject]

2019-05-27 Thread Thomas Meyer

From tho...@m3y3r.de Sun May 26 13:49:04 2019
Subject: [PATCH] drm/omap: Make sure device_id tables are NULL terminated
To: tomi.valkei...@ti.com, airl...@linux.ie, dan...@ffwll.ch,
 dri-devel@lists.freedesktop.org, linux-ker...@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Patch: Cocci
X-Mailer: DiffSplit
Message-ID: <1558871364611-249425076-1-diffsplit-tho...@m3y3r.de>
References: <1558871364605-1026448693-0-diffsplit-tho...@m3y3r.de>
In-Reply-To: <1558871364605-1026448693-0-diffsplit-tho...@m3y3r.de>
X-Serial-No: 1

Make sure (of/i2c/platform)_device_id tables are NULL terminated.

Signed-off-by: Thomas Meyer 
---

diff -u -p a/drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c 
b/drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c
--- a/drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c
+++ b/drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c
@@ -198,6 +198,7 @@ static const struct of_device_id omapdss
{ .compatible = "toppoly,td028ttec1" },
{ .compatible = "tpo,td028ttec1" },
{ .compatible = "tpo,td043mtea1" },
+   {},
 };
 
 static int __init omapdss_boot_init(void)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[no subject]

2018-08-23 Thread Dave Airlie

Hi Linus,

Just a couple of fixes PRs for rc1,

One MAINTAINERS address change, two panels fixes, and set of amdgpu
fixes (build fixes, display fixes and some others).

Thanks
Dave.

drm-next-2018-08-24:
amdgpu and panel/misc fixes.
The following changes since commit 3d63a3c14741ed015948943076f3c6a2f2cd7b27:

  Merge tag 'drm-msm-next-2018-08-10' of
git://people.freedesktop.org/~robclark/linux into drm-next (2018-08-17
10:46:51 +1000)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm tags/drm-next-2018-08-24

for you to fetch changes up to 3e20e97c2d55fb18e4b06d16478edc757483b7db:

  Merge tag 'drm-misc-next-fixes-2018-08-23-1' of
git://anongit.freedesktop.org/drm/drm-misc into drm-next (2018-08-24
13:41:03 +1000)


amdgpu and panel/misc fixes.


Alex Deucher (1):
  drm/amdgpu/display: disable eDP fast boot optimization on DCE8

Christian König (3):
  drm/amdgpu: fix incorrect use of fcheck
  drm/amdgpu: fix incorrect use of drm_file->pid
  drm/amdgpu: fix amdgpu_amdkfd_remove_eviction_fence v3

Dave Airlie (3):
  Merge tag 'drm-misc-next-fixes-2018-08-22' of
git://anongit.freedesktop.org/drm/drm-misc into drm-next
  Merge branch 'drm-next-4.19' of
git://people.freedesktop.org/~agd5f/linux into drm-next
  Merge tag 'drm-misc-next-fixes-2018-08-23-1' of
git://anongit.freedesktop.org/drm/drm-misc into drm-next

Dmytro Laktyushkin (3):
  drm/amd/display: fix dp_ss_control vbios flag parsing
  drm/amd/display: make dp_ss_off optional
  drm/amd/display: fix dentist did ranges

Evan Quan (1):
  drm/amdgpu: set correct base for THM/NBIF/MP1 IP

Kai-Heng Feng (1):
  drm/edid: Add 6 bpc quirk for SDC panel in Lenovo B50-80

Leo (Sunpeng) Li (2):
  Revert "drm/amdgpu/display: Replace CONFIG_DRM_AMD_DC_DCN1_0
with CONFIG_X86"
  drm/amd/display: Don't build DCN1 when kcov is enabled

Samson Tam (1):
  drm/amd/display: Do not retain link settings

Sean Paul (2):
  drm/panel: simple: tv123wam: Add unprepare delay
  MAINTAINERS: drm-misc: Change seanpaul's email address

Yintian Tao (2):
  drm/amdgpu: access register without KIQ
  drm/powerplay: enable dpm under pass-through

 MAINTAINERS|   2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c   | 103 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |   2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_sched.c  |  21 ++---
 drivers/gpu/drm/amd/amdgpu/vega20_reg_init.c   |   3 +
 drivers/gpu/drm/amd/amdgpu/vi.c|   4 +-
 drivers/gpu/drm/amd/display/Kconfig|   6 ++
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c  |  10 +-
 drivers/gpu/drm/amd/display/dc/Makefile|   2 +-
 .../amd/display/dc/bios/command_table_helper2.c|   2 +-
 drivers/gpu/drm/amd/display/dc/calcs/Makefile  |   2 +-
 drivers/gpu/drm/amd/display/dc/core/dc.c   |  21 -
 drivers/gpu/drm/amd/display/dc/core/dc_debug.c |   2 +-
 drivers/gpu/drm/amd/display/dc/core/dc_link.c  |   6 +-
 drivers/gpu/drm/amd/display/dc/core/dc_resource.c  |  12 +--
 drivers/gpu/drm/amd/display/dc/dc.h|   2 +-
 .../gpu/drm/amd/display/dc/dce/dce_clock_source.c  |   6 +-
 .../gpu/drm/amd/display/dc/dce/dce_clock_source.h  |   2 +-
 drivers/gpu/drm/amd/display/dc/dce/dce_clocks.c|  18 ++--
 drivers/gpu/drm/amd/display/dc/dce/dce_clocks.h|   2 +-
 drivers/gpu/drm/amd/display/dc/dce/dce_dmcu.c  |   6 +-
 .../drm/amd/display/dc/dce/dce_stream_encoder.c|  20 ++--
 .../amd/display/dc/dce110/dce110_hw_sequencer.c|  10 +-
 drivers/gpu/drm/amd/display/dc/gpio/Makefile   |   2 +-
 drivers/gpu/drm/amd/display/dc/gpio/hw_factory.c   |   4 +-
 drivers/gpu/drm/amd/display/dc/gpio/hw_translate.c |   4 +-
 drivers/gpu/drm/amd/display/dc/i2caux/Makefile |   2 +-
 drivers/gpu/drm/amd/display/dc/i2caux/i2caux.c |   4 +-
 drivers/gpu/drm/amd/display/dc/inc/core_types.h|   7 +-
 drivers/gpu/drm/amd/display/dc/irq/Makefile|   2 +-
 drivers/gpu/drm/amd/display/dc/irq/irq_service.c   |   2 +-
 drivers/gpu/drm/amd/display/dc/os_types.h  |   2 +-
 .../gpu/drm/amd/powerplay/hwmgr/hardwaremanager.c  |   4 +-
 drivers/gpu/drm/drm_edid.c |   3 +
 drivers/gpu/drm/panel/panel-simple.c   |   3 +
 35 files changed, 161 insertions(+), 142 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[no subject]

2018-07-05 Thread Dave Airlie

Hi Linus, (apologies for blank body pull earlier)

This is the drm fixes for rc4. It's a bit larger than I'd like but the
exynos cleanups are pretty mechanical, and I'd rather have them in
sooner rather than later so we can avoid too much conflicts around
them. The non-mechanincal exynos changes are mostly fixes for new
feature recently introduced.

i915:
GVT and GGTT mapping fixes

amdgpu:
HDMI2.0 4K@60 Hz regression
Hotplug fixes for dual-GPU laptops to make power management better
Misc vega12 bios fixes, a race fix and some typos.

sii8620 bridge: small fixes around mode setting

core: use kvzalloc to allocate blob property memory.

If the exynos changes are too much, I'm happy to push back, and the
blank pull was thanks to baby induced sleep deprivation, fat fingers
and gmail.

Thanks,
Dave.

drm-fixes-2018-07-06:
amdgpu, i915, exynos, udl, sii8620 and core fixes
The following changes since commit 021c91791a5e7e85c567452f1be3e4c2c6cb6063:

  Linux 4.18-rc3 (2018-07-01 16:04:53 -0700)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2018-07-06

for you to fetch changes up to c78d1f9d95a9f2cd5546c64f5315f54681dd6055:

  Merge tag 'exynos-drm-fixes-for-v4.18-rc4' of
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into
drm-fixes (2018-07-06 10:47:02 +1000)


amdgpu, i915, exynos, udl, sii8620 and core fixes


Alex Deucher (2):
  drm/amdgpu: fix swapped emit_ib_size in vce3
  drm/amdgpu/pm: fix display count in non-DC path

Andrzej Pietrasiewicz (1):
  drm/exynos: scaler: Reset hardware before starting the operation

Chris Wilson (1):
  drm/i915: Try GGTT mmapping whole object as partial

Dave Airlie (4):
  Merge tag 'drm-misc-fixes-2018-07-05' of
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes
  Merge tag 'drm-intel-fixes-2018-07-05' of
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes
  Merge branch 'drm-fixes-4.18' of
git://people.freedesktop.org/~agd5f/linux into drm-fixes
  Merge tag 'exynos-drm-fixes-for-v4.18-rc4' of
git://git.kernel.org/.../daeinki/drm-exynos into drm-fixes

Evan Quan (3):
  drm/amd/powerplay: correct vega12 thermal support as true
  drm/amd/powerplay: correct vega12 bootup values settings
  drm/amd/powerplay: smc_dpm_info structure change

Jani Nikula (1):
  Merge tag 'gvt-fixes-2018-07-03' of
https://github.com/intel/gvt-linux into drm-intel-fixes

Lyude Paul (3):
  drm/amdgpu: Make struct amdgpu_atif private to amdgpu_acpi.c
  drm/amdgpu: Add amdgpu_atpx_get_dhandle()
  drm/amdgpu: Dynamically probe for ATIF handle (v2)

Maciej Purski (3):
  drm/bridge/sii8620: Send AVI infoframe in all MHL versions
  drm/bridge/sii8620: Fix display of packed pixel modes
  drm/bridge/sii8620: Fix link mode selection

Marek Szyprowski (10):
  drm/exynos: ipp: Rework checking for the correct buffer formats
  drm/exynos: rotator: Fix DRM_MODE_REFLECT_{X,Y} interpretation
  drm/exynos: scaler: Fix support for YUV420, YUV422 and YUV444 modes
  drm/exynos: gsc: Use real buffer width for configuring the hardware
  drm/exynos: gsc: Increase Exynos5433 buffer width alignment to 16 pixels
  drm/exynos: gsc: Fix DRM_MODE_REFLECT_{X,Y} interpretation
  drm/exynos: gsc: Fix support for NV16/61, YUV420/YVU420 and YUV422 modes
  drm/exynos: fimc: Use real buffer width for configuring the hardware
  drm/exynos: decon5433: Fix per-plane global alpha for XRGB modes
  drm/exynos: decon5433: Fix WINCONx reset value

Michel Dänzer (1):
  drm: Use kvzalloc for allocating blob property memory

Mikita Lipski (2):
  drm/amd/display: adding ycbcr420 pixel encoding for hdmi
  drm/amd/display: add a check for display depth validity

Mikulas Patocka (1):
  drm/udl: fix display corruption of the last line

Nicolai Hähnle (1):
  drm/amdgpu: fix user fence write race condition

Stefan Agner (1):
  drm/exynos: ipp: use correct enum type

Thomas Zimmermann (3):
  drm/exynos: Replace drm_framebuffer_{un/reference} with put,get functions
  drm/exynos: Replace drm_gem_object_unreference_unlocked with put function
  drm/exynos: Replace drm_dev_unref with drm_dev_put

Xiaolin Zhang (1):
  drm/i915/gvt: changed DDI mode emulation type

Zhao Yan (1):
  drm/i915/gvt: fix a bug of partially write ggtt enties

 drivers/gpu/drm/amd/amdgpu/amdgpu.h|  46 ++--
 drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c   | 131 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c   |   6 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c |  12 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c |   2 +-
 drivers/gpu/drm/amd/amdgpu/vce_v3_0.c  |   4 +-
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c  |  49 +++-

[no subject]

2018-07-05 Thread rosdi ablatiff


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[no subject]

2018-03-05 Thread Meghana Madhyastha

linux-...@vger.kernel.org,Noralf Trønnes <nor...@tronnes.org>,Sean Paul 
<seanp...@chromium.org>,ker...@martin.sperl.org
Cc: 
Bcc: 
Subject: Re: [PATCH v2 0/2] Chunk splitting of spi transfers
Reply-To: 
In-Reply-To: <f6dbf3ca-4c1b-90cc-c4af-8889f7407...@tronnes.org>

On Sun, Mar 04, 2018 at 06:38:42PM +0100, Noralf Trønnes wrote:
> 
> Den 02.03.2018 12.11, skrev Meghana Madhyastha:
> >On Sun, Feb 25, 2018 at 02:19:10PM +0100, Lukas Wunner wrote:
> >>[cc += linux-rpi-ker...@lists.infradead.org]
> >>
> >>On Sat, Feb 24, 2018 at 06:15:59PM +, Meghana Madhyastha wrote:
> >>>I've added bcm2835_spi_transfer_one_message in spi-bcm2835. This calls
> >>>spi_split_transfers_maxsize to split large chunks for spi dma transfers.
> >>>I then removed chunk splitting in the tinydrm spi helper (as now the core
> >>>is handling the chunk splitting). However, although the SPI HW should be
> >>>able to accomodate up to 65535 bytes for dma transfers, the splitting of
> >>>chunks to 65535 bytes results in a dma transfer time out error. However,
> >>>when the chunks are split to < 64 bytes it seems to work fine.
> >>Hm, that is really odd, how did you test this exactly, what did you
> >>use as SPI slave?  It contradicts our own experience, we're using
> >>Micrel KSZ8851 Ethernet chips as SPI slave on spi0 of a BCM2837
> >>and can send/receive messages via DMA to the tune of several hundred
> >>bytes without any issues.  In fact, for messages < 96 bytes, DMA is
> >>not used at all, so you've probably been using interrupt mode,
> >>see the BCM2835_SPI_DMA_MIN_LENGTH macro in spi-bcm2835.c.
> >Hi Lukas,
> >
> >I think you are right. I checked it and its not using the DMA mode which
> >is why its working with 64 bytes.
> >Noralf, that leaves us back to the
> >initial time out problem. I've tried doing the message splitting in
> >spi_sync as well as spi_pump_messages. Martin had explained that DMA
> >will wait for
> >the SPI HW to set the send_more_data line, but the SPI-HW itself will
> >stop triggering it when SPI_LEN is 0 causing DMA to wait forever. I
> >thought if we split it before itself, the SPI_LEN will not go to zero
> >thus preventing this problem, however it didn't work and started
> >hanging. So I'm a little uncertain as to how to proceed and debug what
> >exactly has caused the time out due to the asynchronous methods.
> 
> I did a quick test and at least this is working:
> 
> int tinydrm_spi_transfer(struct spi_device *spi, u32 speed_hz,
>              struct spi_transfer *header, u8 bpw, const void *buf,
>              size_t len)
> {
>     struct spi_transfer tr = {
>         .bits_per_word = bpw,
>         .speed_hz = speed_hz,
>         .tx_buf = buf,
>         .len = len,
>     };
>     struct spi_message m;
>     size_t maxsize;
>     int ret;
> 
>     maxsize = tinydrm_spi_max_transfer_size(spi, 0);
> 
>     if (drm_debug & DRM_UT_DRIVER)
>         pr_debug("[drm:%s] bpw=%u, maxsize=%zu, transfers:\n",
>              __func__, bpw, maxsize);
> 
>     spi_message_init();
>     m.spi = spi;
>     if (header)
>         spi_message_add_tail(header, );
>     spi_message_add_tail(, );
> 
>     ret = spi_split_transfers_maxsize(spi->controller, , maxsize,
> GFP_KERNEL);
>     if (ret)
>         return ret;
> 
>     tinydrm_dbg_spi_message(spi, );
> 
>     return spi_sync(spi, );
> }
> EXPORT_SYMBOL(tinydrm_spi_transfer);
> 
> 
> Log:
> [   39.015644] [drm:mipi_dbi_fb_dirty [mipi_dbi]] Flushing [FB:36] x1=0,
> x2=320, y1=0, y2=240
> 
> [   39.018079] [drm:mipi_dbi_typec3_command [mipi_dbi]] cmd=2a, par=00 00 01
> 3f
> [   39.018129] [drm:tinydrm_spi_transfer] bpw=8, maxsize=65532, transfers:
> [   39.018152] tr(0): speed=10MHz, bpw=8, len=1, tx_buf=[2a]
> [   39.018231] [drm:tinydrm_spi_transfer] bpw=8, maxsize=65532, transfers:
> [   39.018248] tr(0): speed=10MHz, bpw=8, len=4, tx_buf=[00 00 01 3f]
> 
> [   39.018330] [drm:mipi_dbi_typec3_command [mipi_dbi]] cmd=2b, par=00 00 00
> ef
> [   39.018347] [drm:tinydrm_spi_transfer] bpw=8, maxsize=65532, transfers:
> [   39.018362] tr(0): speed=10MHz, bpw=8, len=1, tx_buf=[2b]
> [   39.018396] [drm:tinydrm_spi_transfer] bpw=8, maxsize=65532, transfers:
> [   39.018428] tr(0): speed=10MHz, bpw=8, len=4, tx_buf=[00 00 00 ef]
> 
> [   39.018487] [drm:mipi_dbi_typec3_command [mipi_dbi]] cmd=2c, len=153600
> [   39.018502] [drm:tinydrm_spi_transfer] bpw=8, maxsize=65532, transfers:
> [   39.018517] tr(0): speed=10MHz, bpw=8, len=1, tx_buf=[2c]
> [   39.018565]

[no subject]

2017-05-31 Thread Dave Airlie

Hi Linus,

This is the main set of fixes for rc4, one amdgpu fix, some exynos
regression fixes, some msm fixes and some i915 and GVT fixes.

I've got a second regression fix for some DP chips that might be a bit
large, but I think we'd like to land it now, I'll send it along
tomorrow, once you are happy with this set.

Dave.

The following changes since commit 5ed02dbb497422bf225783f46e6eadd237d23d6b:

  Linux 4.12-rc3 (2017-05-28 17:20:53 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux tags/drm-fixes-for-v4.12-rc4

for you to fetch changes up to 400129f0a3ae989c30b37104bbc23b35c9d7a9a4:

  Merge tag 'exynos-drm-fixes-for-v4.12' of
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into
drm-fixes (2017-06-01 12:07:48 +1000)


msm/exynos/i915/amdgpu fixes


Changbin Du (1):
  drm/i915/gvt: clean up unsubmited workloads before destroying kmem cache

Chris Wilson (1):
  drm/i915/selftests: Silence compiler warning in igt_ctx_exec

Chuanxiao Dong (2):
  drm/i915: set initialised only when init_context callback is NULL
  drm/i915/gvt: Disable compression workaround for Gen9

Daniel Vetter (2):
  Revert "drm/i915: Restore lost "Initialized i915" welcome message"
  drm/exynos: Merge pre/postclose hooks

Dave Airlie (4):
  Merge tag 'drm-intel-fixes-2017-05-29' of
git://anongit.freedesktop.org/git/drm-intel into drm-fixes
  Merge branch 'msm-fixes-4.12-rc4' of
git://people.freedesktop.org/~robclark/linux into drm-fixes
  Merge branch 'drm-fixes-4.12' of
git://people.freedesktop.org/~agd5f/linux into drm-fixes
  Merge tag 'exynos-drm-fixes-for-v4.12' of
git://git.kernel.org/.../daeinki/drm-exynos into drm-fixes

Eric Anholt (2):
  drm/msm: Expose our reservation object when exporting a dmabuf.
  drm/msm: Reuse dma_fence_release.

Hans de Goede (1):
  drm/i915: Fix new -Wint-in-bool-context gcc compiler warning

Hoegeun Kwon (2):
  drm/exynos: dsi: Fix the parse_dt function
  drm/exynos: dsi: Remove bridge node reference in removal

Inki Dae (1):
  drm/exynos: clean up description of exynos_drm_crtc

Jani Nikula (1):
  Merge tag 'gvt-fixes-2017-05-25' of
https://github.com/01org/gvt-linux into drm-intel-fixes

Joonas Lahtinen (1):
  drm/i915: Do not sync RCU during shrinking

Jordan Crouse (2):
  drm/msm: Take the mutex before calling msm_gem_new_impl
  drm/msm: Fix the check for the command size

Leo Liu (1):
  drm/amdgpu: Program ring for vce instance 1 at its register space

Matthew Auld (1):
  drm/i915: use vma->size for appgtt allocate_va_range

Philipp Zabel (1):
  drm/msm: for array in-fences, check if all backing fences are
from our own context before waiting

Rob Clark (4):
  drm/msm: select PM_OPP
  drm/msm/mdp5: use __drm_atomic_helper_plane_duplicate_state()
  drm/msm/gpu: check legacy clk names in get_clocks()
  drm/msm/mdp5: release hwpipe(s) for unused planes

Tobias Klauser (1):
  drm/msm: constify irq_domain_ops

Ville Syrjälä (1):
  drm/i915: Stop pretending to mask/unmask LPE audio interrupts

 drivers/gpu/drm/amd/amdgpu/vce_v3_0.c | 95 ---
 drivers/gpu/drm/exynos/exynos_drm_drv.c   |  8 +-
 drivers/gpu/drm/exynos/exynos_drm_drv.h   |  5 +-
 drivers/gpu/drm/exynos/exynos_drm_dsi.c   | 26 +++
 drivers/gpu/drm/i915/gvt/execlist.c   | 30 ---
 drivers/gpu/drm/i915/gvt/handlers.c   | 30 ---
 drivers/gpu/drm/i915/i915_drv.c   |  4 -
 drivers/gpu/drm/i915/i915_gem_gtt.c   |  2 +-
 drivers/gpu/drm/i915/i915_gem_shrinker.c  |  5 --
 drivers/gpu/drm/i915/i915_irq.c   | 15 ++--
 drivers/gpu/drm/i915/i915_reg.h   |  2 +-
 drivers/gpu/drm/i915/intel_lpe_audio.c| 36 -
 drivers/gpu/drm/i915/intel_lrc.c  |  2 +-
 drivers/gpu/drm/i915/selftests/i915_gem_context.c |  8 +-
 drivers/gpu/drm/msm/Kconfig   |  1 +
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_mdss.c  |  2 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c |  9 ++-
 drivers/gpu/drm/msm/msm_drv.c |  1 +
 drivers/gpu/drm/msm/msm_drv.h |  1 +
 drivers/gpu/drm/msm/msm_fence.c   | 10 +--
 drivers/gpu/drm/msm/msm_gem.c |  6 ++
 drivers/gpu/drm/msm/msm_gem_prime.c   |  7 ++
 drivers/gpu/drm/msm/msm_gem_submit.c  | 14 ++--
 drivers/gpu/drm/msm/msm_gpu.c |  4 +-
 24 files changed, 169 insertions(+), 154 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

No subject

2016-10-28 Thread Heliogabalo Santos Jugon

hi,

I'm a new programmer, i just was wondering if i can get some docs to
start learning DRI. I googled a lot but i didn't find a starter
documentation. Some refs will be apreciated

thx

No subject

2016-09-30 Thread Maxime Ripard

Subject: [PATCH v5 0/5] drm: Add Support for Passive RGB to VGA bridges

Hi,

This serie is about adding support for the RGB to VGA bridge found in
the A13-Olinuxino and the CHIP VGA adapter.

Both these boards rely on an entirely passive bridge made out of
resitor ladders that do not require any initialisation. The only thing
needed is to get the timings from the screen if available (and if not,
fall back on XGA standards), set up the display pipeline to output on
the RGB bus with the proper timings, and you're done.

This serie also fixes a bunch of bugs uncovered when trying to
increase the resolution, and hence the pixel clock, of our
pipeline. It also fixes a few bugs in the DRM driver itself that went
unnoticed before.

Let me know what you think,
Maxime

Changes from v4:
  - Removed unused functions

Changes from v3:
  - Depends on OF in Kconfig
  - Fixed typos in the driver comments
  - Removed the mention of a "passive" bridge in the bindings doc
  - Made the strcuture const
  - Removed the nops and best_encoders implementations
  - Removed the call to drm_bridge_enable in the sun4i driver

Changes from v2:
  - Changed the compatible as suggested
  - Rebased on top 4.8

Changes from v1:
  - Switch to using a vga-connector
  - Use drm_encoder bridge pointer instead of doing our own
  - Report the connector status as unknown instead of connected by
default, and as connected only if we can retrieve the EDID.
  - Switch to of_i2c_get_adapter by node, and put the reference when done
  - Rebased on linux-next 

Maxime Ripard (5):
  drm/sun4i: rgb: Remove the bridge enable/disable functions
  drm/bridge: Add RGB to VGA bridge support
  ARM: sun5i: a13-olinuxino: Enable VGA bridge
  ARM: multi_v7: enable VGA bridge
  ARM: sunxi: Enable VGA bridge

 .../bindings/display/bridge/rgb-to-vga-bridge.txt  |  48 +
 arch/arm/boot/dts/sun5i-a13-olinuxino.dts  |  54 +
 arch/arm/configs/multi_v7_defconfig|   1 +
 arch/arm/configs/sunxi_defconfig   |   1 +
 drivers/gpu/drm/bridge/Kconfig |   7 +
 drivers/gpu/drm/bridge/Makefile|   1 +
 drivers/gpu/drm/bridge/rgb-to-vga.c| 229 +
 drivers/gpu/drm/sun4i/sun4i_rgb.c  |   6 -
 8 files changed, 341 insertions(+), 6 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/rgb-to-vga-bridge.txt
 create mode 100644 drivers/gpu/drm/bridge/rgb-to-vga.c

-- 
2.9.3

No subject

2016-02-10 Thread Carlos Palminha

With patch 
http://patchwork.freedesktop.org/patch/msgid/1455106118-32145-1-git-send-email-palminha
 at synopsys.com
i2c slave encoder drivers no longer need to implement dummy mode_fixup function.

This patch set nukes the dummy functions from i2c slave encoder drivers.

(changes made on top of Daniel Vetter topic/drm-misc branch)

[GIT PULL x/y] SUBJECT HERE

2016-01-19 Thread Eric Anholt

  Merge tag 'drm-intel-next-fixes-2016-01-14' of 
git://anongit.freedesktop.org/drm-intel into drm-next (2016-01-18 07:02:19 
+1000)

are available in the git repository at:

  http://github.com/anholt/linux tags/drm-vc4-fixes-2015-01-19

for you to fetch changes up to 8483d152db61c5baf5452b844ef65b96ee9a6cfb:

  drm/vc4: Remove broken attempt at GPU reset using genpd. (2016-01-19 13:16:31 
-0800)


This pull request just includes the !CONFIG_PM_SLEEP build fix for
vc4.


Eric Anholt (1):
  drm/vc4: Remove broken attempt at GPU reset using genpd.

 drivers/gpu/drm/vc4/vc4_v3d.c | 17 +++--
 1 file changed, 7 insertions(+), 10 deletions(-)

[no subject]

2014-09-08 Thread Markus Trippelsdorf

On 2014.09.07 at 23:47 -0400, Alex Deucher wrote:
> On Sun, Sep 7, 2014 at 9:24 AM, Markus Trippelsdorf
>  wrote:
> > On 2014.08.25 at 11:10 +0200, Christian K?nig wrote:
> >> Let me know if it works for you, cause we don't really have any hardware
> >> any more to test it.
> >
> > I've tested your patch series today (using drm-next-3.18 from
> > ~agd5f/linux) on a RS780D/Radeon HD 3300 system with a couple of H264
> > videos. While it sometimes works as expected, it stalled the GPU far too
> > often to be usable. The stalls are not recoverable and the machine ends
> > up with a black sreen, but still accepts SysRq keyboard inputs.
> 
> 
> Does it work any better if dpm is disabled?

Unfortunately no. The symptoms are unchanged.

-- 
Markus

[no subject]

2014-09-08 Thread Alex Deucher

On Sun, Sep 7, 2014 at 9:24 AM, Markus Trippelsdorf
 wrote:
> On 2014.08.25 at 11:10 +0200, Christian K?nig wrote:
>> Let me know if it works for you, cause we don't really have any hardware
>> any more to test it.
>
> I've tested your patch series today (using drm-next-3.18 from
> ~agd5f/linux) on a RS780D/Radeon HD 3300 system with a couple of H264
> videos. While it sometimes works as expected, it stalled the GPU far too
> often to be usable. The stalls are not recoverable and the machine ends
> up with a black sreen, but still accepts SysRq keyboard inputs.


Does it work any better if dpm is disabled?

Alex

>
> Here are some logs:
>
> vdpauinfo:
> display: :0   screen: 0
> API version: 1
> Information string: G3DVL VDPAU Driver Shared Library version 1.0
>
> Video surface:
>
> name   width height types
> ---
> 420 8192  8192  NV12 YV12
> 422 8192  8192  UYVY YUYV
> 444 8192  8192  Y8U8V8A8 V8U8Y8A8
>
> Decoder capabilities:
>
> name   level macbs width height
> ---
> MPEG1 0  9216  2048  1152
> MPEG2_SIMPLE  3  9216  2048  1152
> MPEG2_MAIN3  9216  2048  1152
> H264_BASELINE41  9216  2048  1152
> H264_MAIN41  9216  2048  1152
> H264_HIGH41  9216  2048  1152
> VC1_ADVANCED  4  9216  2048  1152
>
> Output surface:
>
> name  width height nat types
> 
> B8G8R8A8  8192  8192y  NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8
> R8G8B8A8  8192  8192y  NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8
> R10G10B10A2   8192  8192y  NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8
> B10G10R10A2   8192  8192y  NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8
>
> Bitmap surface:
>
> name  width height
> --
> B8G8R8A8  8192  8192
> R8G8B8A8  8192  8192
> R10G10B10A2   8192  8192
> B10G10R10A2   8192  8192
> A88192  8192
>
> Video mixer:
>
> feature namesup
> 
> DEINTERLACE_TEMPORAL y
> DEINTERLACE_TEMPORAL_SPATIAL -
> INVERSE_TELECINE -
> NOISE_REDUCTION  y
> SHARPNESSy
> LUMA_KEY -
> HIGH QUALITY SCALING - L1-
> HIGH QUALITY SCALING - L2-
> HIGH QUALITY SCALING - L3-
> HIGH QUALITY SCALING - L4-
> HIGH QUALITY SCALING - L5-
> HIGH QUALITY SCALING - L6-
> HIGH QUALITY SCALING - L7-
> HIGH QUALITY SCALING - L8-
> HIGH QUALITY SCALING - L9-
>
> parameter name  sup  min  max
> -
> VIDEO_SURFACE_WIDTH  y48 2048
> VIDEO_SURFACE_HEIGHT y48 1152
> CHROMA_TYPE  y
> LAYERS   y 04
>
> attribute name  sup  min  max
> -
> BACKGROUND_COLOR y
> CSC_MATRIX   y
> NOISE_REDUCTION_LEVELy  0.00 1.00
> SHARPNESS_LEVEL  y -1.00 1.00
> LUMA_KEY_MIN_LUMAy
> LUMA_KEY_MAX_LUMAy
>
>
> Sep  7 14:03:45 x4 kernel: [drm] Initialized drm 1.1.0 20060810
> Sep  7 14:03:45 x4 kernel: [drm] radeon kernel modesetting enabled.
> Sep  7 14:03:45 x4 kernel: [drm] initializing kernel modesetting (RS780 
> 0x1002:0x9614 0x1043:0x834D).
> Sep  7 14:03:45 x4 kernel: [drm] register mmio base: 0xFBEE
> Sep  7 14:03:45 x4 kernel: [drm] register mmio size: 65536
> Sep  7 14:03:45 x4 kernel: ATOM BIOS: 113
> Sep  7 14:03:45 x4 kernel: radeon :01:05.0: VRAM: 128M 0xC000 
> - 0xC7FF (128M used)
> Sep  7 14:03:45 x4 kernel: radeon :01:05.0: GTT: 512M 0xA000 
> - 0xBFFF
> Sep  7 14:03:45 x4 kernel: [drm] Detected VRAM RAM=128M, BAR=128M
> Sep  7 14:03:45 x4 kernel: [drm] RAM width 32bits DDR
> Sep  7 14:03:45 x4 kernel: [TTM] Zone  kernel: Available graphics memory: 
> 4083350 kiB
> Sep  7 14:03:45 x4 kernel: [TTM] Zone   dma32: Available graphics memory: 
> 2097152 kiB
> Sep  7 14:03:45 x4 kernel: [TTM] Initializing pool allocator
> Sep  7 14:03:45 x4 kernel: [TTM] Initializing DMA pool allocator
> Sep  7 14:03:45 x4 kernel: [drm] radeon: 128M of VRAM memory ready
> Sep  7 14:03:45 x4 kernel: [drm] radeon: 512M of GTT memory ready.
> Sep  7 14:03:45 x4 kernel: [drm] Loading RS780 Microcode
> Sep  7 14:03:45 x4 kernel: == power state 0 ==
> Sep  7 14:03:45 x4 kernel:  ui class: none
> Sep  7 14:03:45 x4 kernel:  internal class: boot
> Sep  7 14:03:45 x4 kernel:  caps: video
> Sep  7 14:03:45 x4 kernel:  uvdvclk: 0 dclk: 0
> Sep  7 14:03:45 x4 kernel:  power level 0sclk:

[no subject]

2014-09-07 Thread Markus Trippelsdorf

On 2014.08.25 at 11:10 +0200, Christian K?nig wrote:
> Let me know if it works for you, cause we don't really have any hardware 
> any more to test it.

I've tested your patch series today (using drm-next-3.18 from
~agd5f/linux) on a RS780D/Radeon HD 3300 system with a couple of H264
videos. While it sometimes works as expected, it stalled the GPU far too
often to be usable. The stalls are not recoverable and the machine ends
up with a black sreen, but still accepts SysRq keyboard inputs.

Here are some logs:

vdpauinfo:
display: :0   screen: 0
API version: 1
Information string: G3DVL VDPAU Driver Shared Library version 1.0

Video surface:

name   width height types
---
420 8192  8192  NV12 YV12 
422 8192  8192  UYVY YUYV 
444 8192  8192  Y8U8V8A8 V8U8Y8A8 

Decoder capabilities:

name   level macbs width height
---
MPEG1 0  9216  2048  1152
MPEG2_SIMPLE  3  9216  2048  1152
MPEG2_MAIN3  9216  2048  1152
H264_BASELINE41  9216  2048  1152
H264_MAIN41  9216  2048  1152
H264_HIGH41  9216  2048  1152
VC1_ADVANCED  4  9216  2048  1152

Output surface:

name  width height nat types

B8G8R8A8  8192  8192y  NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 
R8G8B8A8  8192  8192y  NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 
R10G10B10A2   8192  8192y  NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 
B10G10R10A2   8192  8192y  NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 

Bitmap surface:

name  width height
--
B8G8R8A8  8192  8192
R8G8B8A8  8192  8192
R10G10B10A2   8192  8192
B10G10R10A2   8192  8192
A88192  8192

Video mixer:

feature namesup

DEINTERLACE_TEMPORAL y
DEINTERLACE_TEMPORAL_SPATIAL -
INVERSE_TELECINE -
NOISE_REDUCTION  y
SHARPNESSy
LUMA_KEY -
HIGH QUALITY SCALING - L1-
HIGH QUALITY SCALING - L2-
HIGH QUALITY SCALING - L3-
HIGH QUALITY SCALING - L4-
HIGH QUALITY SCALING - L5-
HIGH QUALITY SCALING - L6-
HIGH QUALITY SCALING - L7-
HIGH QUALITY SCALING - L8-
HIGH QUALITY SCALING - L9-

parameter name  sup  min  max
-
VIDEO_SURFACE_WIDTH  y48 2048
VIDEO_SURFACE_HEIGHT y48 1152
CHROMA_TYPE  y  
LAYERS   y 04

attribute name  sup  min  max
-
BACKGROUND_COLOR y  
CSC_MATRIX   y  
NOISE_REDUCTION_LEVELy  0.00 1.00
SHARPNESS_LEVEL  y -1.00 1.00
LUMA_KEY_MIN_LUMAy  
LUMA_KEY_MAX_LUMAy  


Sep  7 14:03:45 x4 kernel: [drm] Initialized drm 1.1.0 20060810
Sep  7 14:03:45 x4 kernel: [drm] radeon kernel modesetting enabled.
Sep  7 14:03:45 x4 kernel: [drm] initializing kernel modesetting (RS780 
0x1002:0x9614 0x1043:0x834D).
Sep  7 14:03:45 x4 kernel: [drm] register mmio base: 0xFBEE
Sep  7 14:03:45 x4 kernel: [drm] register mmio size: 65536
Sep  7 14:03:45 x4 kernel: ATOM BIOS: 113
Sep  7 14:03:45 x4 kernel: radeon :01:05.0: VRAM: 128M 0xC000 - 
0xC7FF (128M used)
Sep  7 14:03:45 x4 kernel: radeon :01:05.0: GTT: 512M 0xA000 - 
0xBFFF
Sep  7 14:03:45 x4 kernel: [drm] Detected VRAM RAM=128M, BAR=128M
Sep  7 14:03:45 x4 kernel: [drm] RAM width 32bits DDR
Sep  7 14:03:45 x4 kernel: [TTM] Zone  kernel: Available graphics memory: 
4083350 kiB
Sep  7 14:03:45 x4 kernel: [TTM] Zone   dma32: Available graphics memory: 
2097152 kiB
Sep  7 14:03:45 x4 kernel: [TTM] Initializing pool allocator
Sep  7 14:03:45 x4 kernel: [TTM] Initializing DMA pool allocator
Sep  7 14:03:45 x4 kernel: [drm] radeon: 128M of VRAM memory ready
Sep  7 14:03:45 x4 kernel: [drm] radeon: 512M of GTT memory ready.
Sep  7 14:03:45 x4 kernel: [drm] Loading RS780 Microcode
Sep  7 14:03:45 x4 kernel: == power state 0 ==
Sep  7 14:03:45 x4 kernel:  ui class: none
Sep  7 14:03:45 x4 kernel:  internal class: boot 
Sep  7 14:03:45 x4 kernel:  caps: video 
Sep  7 14:03:45 x4 kernel:  uvdvclk: 0 dclk: 0
Sep  7 14:03:45 x4 kernel:  power level 0sclk: 5 
vddc_index: 2
Sep  7 14:03:45 x4 kernel:  power level 1sclk: 5 
vddc_index: 2
Sep  7 14:03:45 x4 kernel:  status: c r b 
Sep  7 14:03:45 x4 kernel: == power state 1 ==
Sep  7 14:03:45 x4 kernel:  ui class: performance
Sep  7 14:03:45 x4 kernel:  internal class: none
Sep  7

[no subject]

2014-08-25 Thread Christian König

Let me know if it works for you, cause we don't really have any hardware 
any more to test it.

Christian.

Am 24.08.2014 um 15:34 schrieb Mike Lothian:
>
> Thanks for this
>
> Good work
>
> On 24 Aug 2014 14:15, "Christian K?nig"  > wrote:
>
> Hello everyone,
>
> the following patches add UVD support for older ASICs (RV6xx,
> RS[78]80, RV7[79]0). For everybody wanting to test it I've also
> uploaded a branch to FDO:
> http://cgit.freedesktop.org/~deathsimple/linux/log/?h=uvd-r600-release
> 
>
> Additionally to the patches you need UVD firmware as well, which
> can be found at the usual location:
> http://people.freedesktop.org/~agd5f/radeon_ucode/
> 
>
> A small Mesa patch is needed as well, cause the older hardware
> doesn't support field based output of video frames. So
> unfortunately VDPAU/OpenGL interop won't work either.
>
> We can only provide best effort support for those older ASICs, but
> at least on my RS[78]80 based laptop it seems to work perfectly fine.
>
> Happy testing,
> Christian.
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> 
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>

-- next part --
An HTML attachment was scrubbed...
URL:

No subject

2014-08-24 Thread Christian König

Hello everyone,

the following patches add UVD support for older ASICs (RV6xx, RS[78]80, 
RV7[79]0). For everybody wanting to test it I've also uploaded a branch to FDO: 
http://cgit.freedesktop.org/~deathsimple/linux/log/?h=uvd-r600-release

Additionally to the patches you need UVD firmware as well, which can be found 
at the usual location: http://people.freedesktop.org/~agd5f/radeon_ucode/

A small Mesa patch is needed as well, cause the older hardware doesn't support 
field based output of video frames. So unfortunately VDPAU/OpenGL interop won't 
work either.

We can only provide best effort support for those older ASICs, but at least on 
my RS[78]80 based laptop it seems to work perfectly fine.

Happy testing,
Christian.

[no subject]

2014-08-24 Thread Mike Lothian

Thanks for this

Good work
On 24 Aug 2014 14:15, "Christian K?nig"  wrote:

> Hello everyone,
>
> the following patches add UVD support for older ASICs (RV6xx, RS[78]80,
> RV7[79]0). For everybody wanting to test it I've also uploaded a branch to
> FDO:
> http://cgit.freedesktop.org/~deathsimple/linux/log/?h=uvd-r600-release
>
> Additionally to the patches you need UVD firmware as well, which can be
> found at the usual location:
> http://people.freedesktop.org/~agd5f/radeon_ucode/
>
> A small Mesa patch is needed as well, cause the older hardware doesn't
> support field based output of video frames. So unfortunately VDPAU/OpenGL
> interop won't work either.
>
> We can only provide best effort support for those older ASICs, but at
> least on my RS[78]80 based laptop it seems to work perfectly fine.
>
> Happy testing,
> Christian.
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL:

No subject

2014-03-13 Thread Thomas Hellstrom

After a previous patch series and a discussion with Daniel Vetter and
David Herrmann, I've reworked the patches a bit. Please review.

Patch 5 is already reviewed.

/Thomas

>From Thomas Hellstrom  # This line is ignored.
From: Thomas Hellstrom <thellst...@vmware.com>
Subject: 
In-Reply-To:

[PATCH v3 0/2] * SUBJECT HERE *

2014-02-07 Thread Jean-Francois Moine

*** BLURB HERE ***

Jean-Francois Moine (2):
  drivers/base: permit base components to omit the bind/unbind ops
  drivers/base: declare phandle DT nodes as components

 drivers/base/component.c | 21 +++--
 drivers/base/core.c  | 18 ++
 include/linux/of.h   |  2 ++
 3 files changed, 39 insertions(+), 2 deletions(-)

-- 
1.9.rc1

[PATCH v3 0/2] * SUBJECT HERE *

2014-02-07 Thread Greg Kroah-Hartman

On Fri, Feb 07, 2014 at 06:09:46PM +0100, Jean-Francois Moine wrote:
> *** BLURB HERE ***

Subject and BLURB forgotten?

No subject

2013-08-13 Thread Christian König

Hey Alex,

here are my patches for reworking the ring function pointers and separating out 
the UVD and DMA rings.

Everything is rebased on your drm-next-3.12-wip branch, please review and add 
them to your branch.

Thanks,
Christian.

[no subject]

2013-08-13 Thread Alex Deucher

On Tue, Aug 13, 2013 at 5:56 AM, Christian K?nig
 wrote:
> Hey Alex,
>
> here are my patches for reworking the ring function pointers and separating 
> out the UVD and DMA rings.
>
> Everything is rebased on your drm-next-3.12-wip branch, please review and add 
> them to your branch.

Patches look good to me.  I've added them to my 3.12 tree.

Alex

[no subject]

2013-08-13 Thread Christian König

Hey Alex,

here are my patches for reworking the ring function pointers and separating out 
the UVD and DMA rings.

Everything is rebased on your drm-next-3.12-wip branch, please review and add 
them to your branch.

Thanks,
Christian.

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 0/4] * SUBJECT HERE *

2013-05-09 Thread Christopher Harvey

I forgot to include some acked and tested-by lines in v1 of this
series.

No code changes in v2.

thanks,
Christopher Harvey (4):
  drm/mgag200: Don't change unrelated registers during modeset
  drm/mgag200: Fix writes into MGA1064_PIX_CLK_CTL register
  drm/mgag200: Convert counter delays to jiffies
  drm/mgag200: Fix framebuffer base address programming

 drivers/gpu/drm/mgag200/mgag200_mode.c | 90 --
 1 file changed, 52 insertions(+), 38 deletions(-)

-- 
1.8.1.5

[PATCH v2 0/4] * SUBJECT HERE *

2013-05-09 Thread Christopher Harvey

I forgot to include some acked and tested-by lines in v1 of this
series.

No code changes in v2.

thanks,
Christopher Harvey (4):
  drm/mgag200: Don't change unrelated registers during modeset
  drm/mgag200: Fix writes into MGA1064_PIX_CLK_CTL register
  drm/mgag200: Convert counter delays to jiffies
  drm/mgag200: Fix framebuffer base address programming

 drivers/gpu/drm/mgag200/mgag200_mode.c | 90 --
 1 file changed, 52 insertions(+), 38 deletions(-)

-- 
1.8.1.5

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

No subject

2012-10-05 Thread Robert Schwebel

, pza
Bcc:
Subject: Re: [PATCH 1/2 v6] of: add helper to parse display timings
Reply-To:
In-Reply-To: 
X-Sent-From: Pengutronix Hildesheim
X-URL: http://www.pengutronix.de/
X-IRC: #ptxdist @freenode
X-Accept-Language: de,en
X-Accept-Content-Type: text/plain
X-Uptime: 09:13:09 up 103 days, 22:24, 36 users,  load average: 0,57, 0,60,
 0,61

On Thu, Oct 04, 2012 at 11:35:35PM +0200, Guennadi Liakhovetski wrote:
> > +optional properties:
> > + - hsync-active-high (bool): Hsync pulse is active high
> > + - vsync-active-high (bool): Vsync pulse is active high
>
> For the above two we also considered using bool properties but eventually
> settled down with integer ones:
>
> - hsync-active = <1>
>
> for active-high and 0 for active low. This has the added advantage of
> being able to omit this property in the .dts, which then doesn't mean,
> that the polarity is active low, but rather, that the hsync line is not
> used on this hardware. So, maybe it would be good to use the same binding
> here too?

Philipp, this is the same argumentation as we discussed yesterday for
the dual-link LVDS option, so that one could be modelled in a similar
way.

rsc
-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

[no subject]

2012-10-05 Thread Robert Schwebel

tomi.valkei...@ti.com, pza
Bcc:
Subject: Re: [PATCH 1/2 v6] of: add helper to parse display timings
Reply-To:
In-Reply-To: Pine.LNX.4.64.1210042307300.3744@axis700.grange
X-Sent-From: Pengutronix Hildesheim
X-URL: http://www.pengutronix.de/
X-IRC: #ptxdist @freenode
X-Accept-Language: de,en
X-Accept-Content-Type: text/plain
X-Uptime: 09:13:09 up 103 days, 22:24, 36 users,  load average: 0,57, 0,60,
 0,61

On Thu, Oct 04, 2012 at 11:35:35PM +0200, Guennadi Liakhovetski wrote:
  +optional properties:
  + - hsync-active-high (bool): Hsync pulse is active high
  + - vsync-active-high (bool): Vsync pulse is active high

 For the above two we also considered using bool properties but eventually
 settled down with integer ones:

 - hsync-active = 1

 for active-high and 0 for active low. This has the added advantage of
 being able to omit this property in the .dts, which then doesn't mean,
 that the polarity is active low, but rather, that the hsync line is not
 used on this hardware. So, maybe it would be good to use the same binding
 here too?

Philipp, this is the same argumentation as we discussed yesterday for
the dual-link LVDS option, so that one could be modelled in a similar
way.

rsc
-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

No subject

2012-06-13 Thread

issue is that changing it will break any app relying on it being REALTIME 
clock.

No subject

2012-05-30 Thread

0x0314e050:  0x61010006: STATE_BASE_ADDRESS
0x0314e054:  0x0001:general state base address 0x
0x0314e058:  0x0001:surface state base address 0x
0x0314e05c:  0x0001:indirect state base address 0x
0x0314e060:  0x0001:instruction state base address 0x
0x0314e064:  0x1001:general state upper bound 0x1000
0x0314e068:  0x1001:indirect state upper bound 0x1000
0x0314e06c:  0x1001:instruction state upper bound 0x1000

And if we look at some of the other auxiliary instructions buffers sent
along with the batch:

  0314e00016384 0048  000ab700 dirty purgeable render uncached
...
  11e3 4096 0011  000ab700 purgeable render uncached
  11e2b000 4096 0011  000ab700 purgeable render uncached
  10e43000 4096 0011  000ab700 render uncached
  10e44000 4096 0011  000ab700 purgeable render uncached

0x10 being the instruction domain for a total of about 20 instruction
buffers referenced from that batch above the upper bound (and in
particular appears to have been the first batch to use addresses above
256M).

This batch fits the modus operandi of the bug that was fixed in
2.14.901, it would seem sensible to address the known issue first.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[no subject]

2012-05-24 Thread Sascha Hauer

On Tue, May 22, 2012 at 04:06:41PM +0200, Lars-Peter Clausen wrote:
> On 05/18/2012 02:27 PM, Sascha Hauer wrote:
> > Hi All,
> > 
> > The following adds a drm/kms driver for the Freescale i.MX LCDC
> > controller. Most notable change to the last SDRM based version is that
> > the SDRM layer has been removed and the driver now is purely i.MX
> > specific. I hope that this is more acceptable now.
> > 
> > Another change is that the probe is now devicetree based. For now I
> > took the easy way out and only put an edid blob into the devicetree.
> > I haven't documented the binding yet, I would add that when the rest
> > is considered ok.
> > 
> > Comments very welcome.
> > 
> 
> Hi,
> 
> I really liked the sdrm layer. At least some bits of it. I've been working
> on a "simple" DRM driver as well. The hardware has no fancy acceleration
> features, just a simple buffer and some scanout logic. I'm basically using
> the same gem buffer structure and the buffer is also allocated using
> dma_alloc_writecombine, which means we can probably share all of the GEM
> handling code and probably also most of the fbdev code. I also started with
> the Exynos GEM code as a template, but reworked it later to be more like the
> UDL code, which made it a bit more compact. I think it would be a good idea
> to put at least the GEM handling in some common code as I expect that we'll
> see more similar "simple" DRM drivers pop up.

Ok, I'll try to put the GEM stuff into helper functions. Would you care
to review/test it? I have something else to do right now but I hope I'll
be there next week.

Sascha

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

No subject

2012-05-23 Thread

i don't think kernel is the right place for it, for instance you need
to set the primary surface thing, i don't want to parse cmd stream in
kernel to figure that out. I would rather have userspace tool that
postprocess thing and convert it to proper AMD dump format.

Cheers,
Jerome

[no subject]

2012-05-23 Thread Sascha Hauer

On Tue, May 22, 2012 at 04:06:41PM +0200, Lars-Peter Clausen wrote:
> On 05/18/2012 02:27 PM, Sascha Hauer wrote:
> > Hi All,
> > 
> > The following adds a drm/kms driver for the Freescale i.MX LCDC
> > controller. Most notable change to the last SDRM based version is that
> > the SDRM layer has been removed and the driver now is purely i.MX
> > specific. I hope that this is more acceptable now.
> > 
> > Another change is that the probe is now devicetree based. For now I
> > took the easy way out and only put an edid blob into the devicetree.
> > I haven't documented the binding yet, I would add that when the rest
> > is considered ok.
> > 
> > Comments very welcome.
> > 
> 
> Hi,
> 
> I really liked the sdrm layer. At least some bits of it. I've been working
> on a "simple" DRM driver as well. The hardware has no fancy acceleration
> features, just a simple buffer and some scanout logic. I'm basically using
> the same gem buffer structure and the buffer is also allocated using
> dma_alloc_writecombine, which means we can probably share all of the GEM
> handling code and probably also most of the fbdev code. I also started with
> the Exynos GEM code as a template, but reworked it later to be more like the
> UDL code, which made it a bit more compact. I think it would be a good idea
> to put at least the GEM handling in some common code as I expect that we'll
> see more similar "simple" DRM drivers pop up.

I totally agree. Having to track other drivers for bug fixes to apply
them on the own driver is not very convenient. As answered to Rob I do
not really have a clue how to accomplish this.

> 
> The code in question can be found at
> https://github.com/lclausen-adi/linux-2.6/commit/87a8fd6b98317c7a486846cc8405d0bd68d8
> 
> Btw. the imx-drm.h is missing in your patch.

Oops, here it is for reference, will include it in the next round.

#ifndef _IMX_DRM_H_
#define _IMX_DRM_H_

/**
 * User-desired buffer creation information structure.
 *
 * @size: requested size for the object.
 *  - this size value would be page-aligned internally.
 * @flags: user request for setting memory type or cache attributes.
 * @handle: returned handle for the object.
 */
struct imx_drm_gem_create {
unsigned int size;
unsigned int flags;
unsigned int handle;
};

struct imx_drm_device;
struct imx_drm_crtc;

struct imx_drm_crtc_helper_funcs {
int (*enable_vblank)(struct drm_crtc *crtc);
void (*disable_vblank)(struct drm_crtc *crtc);
};

int imx_drm_add_crtc(struct drm_crtc *crtc,
struct imx_drm_crtc **new_crtc,
const struct drm_crtc_funcs *crtc_funcs,
const struct drm_crtc_helper_funcs *crtc_helper_funcs,
const struct imx_drm_crtc_helper_funcs *ec_helper_funcs,
struct module *owner);
int imx_drm_remove_crtc(struct imx_drm_crtc *);
int imx_drm_init_drm(struct platform_device *pdev,
int preferred_bpp);
int imx_drm_exit_drm(void);

int imx_drm_crtc_vblank_get(struct imx_drm_crtc *imx_drm_crtc);
void imx_drm_crtc_vblank_put(struct imx_drm_crtc *imx_drm_crtc);
void imx_drm_handle_vblank(struct imx_drm_crtc *imx_drm_crtc);

/*
 * imx drm buffer entry structure.
 *
 * @paddr: physical address of allocated memory.
 * @vaddr: kernel virtual address of allocated memory.
 * @size: size of allocated memory.
 */
struct imx_drm_buf_entry {
dma_addr_t paddr;
void __iomem *vaddr;
unsigned int size;
};

/* get physical memory information of a drm framebuffer. */
struct imx_drm_buf_entry *imx_drm_fb_get_buf(struct drm_framebuffer *fb);

struct imx_drm_encoder;
int imx_drm_add_encoder(struct drm_encoder *encoder,
struct imx_drm_encoder **new_enc,
struct module *owner);
int imx_drm_remove_encoder(struct imx_drm_encoder *);

struct imx_drm_connector;
int imx_drm_add_connector(struct drm_connector *connector,
struct imx_drm_connector **new_con,
struct module *owner);
int imx_drm_remove_connector(struct imx_drm_connector *);

void imx_drm_mode_config_init(struct drm_device *drm);

#define to_imx_drm_gem_obj(x)   container_of(x,\
struct imx_drm_gem_obj, base)

struct imx_drm_gem_obj {
struct drm_gem_object base;
struct imx_drm_buf_entry *entry;
};

/* unmap a buffer from user space. */
int imx_drm_gem_munmap_ioctl(struct drm_device *drm, void *data,
struct drm_file *file_priv);

/* initialize gem object. */
int imx_drm_gem_init_object(struct drm_gem_object *obj);

/* free gem object. */
void imx_drm_gem_free_object(struct drm_gem_object *gem_obj);

/* create memory region for drm framebuffer. */
int imx_drm_gem_dumb_create(struct drm_file *file_priv,
struct drm_device *drm, struct drm_mode_create_dumb *args);

/* map memory region for drm framebuffer to user space. */
int imx_drm_gem_dumb_map_offset(struct drm_file *file_priv,
struct

[no subject]

2012-05-22 Thread Lars-Peter Clausen

On 05/18/2012 02:27 PM, Sascha Hauer wrote:
> Hi All,
> 
> The following adds a drm/kms driver for the Freescale i.MX LCDC
> controller. Most notable change to the last SDRM based version is that
> the SDRM layer has been removed and the driver now is purely i.MX
> specific. I hope that this is more acceptable now.
> 
> Another change is that the probe is now devicetree based. For now I
> took the easy way out and only put an edid blob into the devicetree.
> I haven't documented the binding yet, I would add that when the rest
> is considered ok.
> 
> Comments very welcome.
> 

Hi,

I really liked the sdrm layer. At least some bits of it. I've been working
on a "simple" DRM driver as well. The hardware has no fancy acceleration
features, just a simple buffer and some scanout logic. I'm basically using
the same gem buffer structure and the buffer is also allocated using
dma_alloc_writecombine, which means we can probably share all of the GEM
handling code and probably also most of the fbdev code. I also started with
the Exynos GEM code as a template, but reworked it later to be more like the
UDL code, which made it a bit more compact. I think it would be a good idea
to put at least the GEM handling in some common code as I expect that we'll
see more similar "simple" DRM drivers pop up.

The code in question can be found at
https://github.com/lclausen-adi/linux-2.6/commit/87a8fd6b98317c7a486846cc8405d0bd68d8

Btw. the imx-drm.h is missing in your patch.

- Lars

> Thanks
>  Sascha
> 
> 
> Sascha Hauer (2):
>   DRM: add Freescale i.MX LCDC driver
>   pcm038 lcdc support
> 
>  arch/arm/boot/dts/imx27-phytec-phycore.dts |   39 ++
>  arch/arm/boot/dts/imx27.dtsi   |7 +
>  arch/arm/mach-imx/clock-imx27.c|1 +
>  drivers/gpu/drm/Kconfig|2 +
>  drivers/gpu/drm/Makefile   |1 +
>  drivers/gpu/drm/imx/Kconfig|   18 +
>  drivers/gpu/drm/imx/Makefile   |8 +
>  drivers/gpu/drm/imx/imx-drm-core.c |  745 
> 
>  drivers/gpu/drm/imx/imx-fb.c   |  179 +++
>  drivers/gpu/drm/imx/imx-fbdev.c|  275 ++
>  drivers/gpu/drm/imx/imx-gem.c  |  343 +
>  drivers/gpu/drm/imx/imx-lcdc-crtc.c|  517 +++
>  drivers/gpu/drm/imx/imx-parallel-display.c |  228 +
>  13 files changed, 2363 insertions(+)
>  create mode 100644 drivers/gpu/drm/imx/Kconfig
>  create mode 100644 drivers/gpu/drm/imx/Makefile
>  create mode 100644 drivers/gpu/drm/imx/imx-drm-core.c
>  create mode 100644 drivers/gpu/drm/imx/imx-fb.c
>  create mode 100644 drivers/gpu/drm/imx/imx-fbdev.c
>  create mode 100644 drivers/gpu/drm/imx/imx-gem.c
>  create mode 100644 drivers/gpu/drm/imx/imx-lcdc-crtc.c
>  create mode 100644 drivers/gpu/drm/imx/imx-parallel-display.c
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[no subject]

2012-05-18 Thread Sascha Hauer

Hi All,

The following adds a drm/kms driver for the Freescale i.MX LCDC
controller. Most notable change to the last SDRM based version is that
the SDRM layer has been removed and the driver now is purely i.MX
specific. I hope that this is more acceptable now.

Another change is that the probe is now devicetree based. For now I
took the easy way out and only put an edid blob into the devicetree.
I haven't documented the binding yet, I would add that when the rest
is considered ok.

Comments very welcome.

Thanks
 Sascha


Sascha Hauer (2):
  DRM: add Freescale i.MX LCDC driver
  pcm038 lcdc support

 arch/arm/boot/dts/imx27-phytec-phycore.dts |   39 ++
 arch/arm/boot/dts/imx27.dtsi   |7 +
 arch/arm/mach-imx/clock-imx27.c|1 +
 drivers/gpu/drm/Kconfig|2 +
 drivers/gpu/drm/Makefile   |1 +
 drivers/gpu/drm/imx/Kconfig|   18 +
 drivers/gpu/drm/imx/Makefile   |8 +
 drivers/gpu/drm/imx/imx-drm-core.c |  745 
 drivers/gpu/drm/imx/imx-fb.c   |  179 +++
 drivers/gpu/drm/imx/imx-fbdev.c|  275 ++
 drivers/gpu/drm/imx/imx-gem.c  |  343 +
 drivers/gpu/drm/imx/imx-lcdc-crtc.c|  517 +++
 drivers/gpu/drm/imx/imx-parallel-display.c |  228 +
 13 files changed, 2363 insertions(+)
 create mode 100644 drivers/gpu/drm/imx/Kconfig
 create mode 100644 drivers/gpu/drm/imx/Makefile
 create mode 100644 drivers/gpu/drm/imx/imx-drm-core.c
 create mode 100644 drivers/gpu/drm/imx/imx-fb.c
 create mode 100644 drivers/gpu/drm/imx/imx-fbdev.c
 create mode 100644 drivers/gpu/drm/imx/imx-gem.c
 create mode 100644 drivers/gpu/drm/imx/imx-lcdc-crtc.c
 create mode 100644 drivers/gpu/drm/imx/imx-parallel-display.c
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

1 2 >

1 - 100 of 195 matches

Mail list logo