date:20220716

Hi Matthieu,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on v5.19-rc6]
[also build test ERROR on linus/master]
[cannot apply to drm-misc/drm-misc-next next-20220715]
[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/Matthieu-CHARETTE/drm-Fix-EDID-firmware-load-on-resume/20220716-214028
base:32346491ddf24599decca06190ebca03ff9de7f8
config: parisc-randconfig-r023-20220717 
(https://download.01.org/0day-ci/archive/20220717/202207170636.yv3axya1-...@intel.com/config)
compiler: hppa-linux-gcc (GCC) 12.1.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# 
https://github.com/intel-lab-lkp/linux/commit/e583aaf4f6464add35f2350c728d80a3fe790638
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review 
Matthieu-CHARETTE/drm-Fix-EDID-firmware-load-on-resume/20220716-214028
git checkout e583aaf4f6464add35f2350c728d80a3fe790638
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1 
O=build_dir ARCH=parisc SHELL=/bin/bash

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

All errors (new ones prefixed by >>):

   hppa-linux-ld: drivers/gpu/drm/drm_connector.o: in function `.LC507':
>> drm_connector.c:(.rodata.cst4+0x1f8): undefined reference to 
>> `drm_cache_edid_firmware'

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

[Bug 216119] 087451f372bf76d breaks hibernation on amdgpu Radeon R9 390

2022-07-16 Thread bugzilla-daemon

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

--- Comment #32 from Harald Judt (h.j...@gmx.at) ---
There still seem to be issues with the shared fb implementation and
hibernation. After resume, chvt to another vt causes the following errors in
dmesg:

[  975.920944] [drm:amdgpu_job_timedout] *ERROR* ring gfx timeout, but soft
recovered
[  986.160803] [drm:amdgpu_job_timedout] *ERROR* ring gfx timeout, but soft
recovered
[  996.400610] [drm:amdgpu_job_timedout] *ERROR* ring gfx timeout, but soft
recovered
[ 1006.640916] [drm:amdgpu_job_timedout] *ERROR* ring gfx timeout, but soft
recovered
[ 1016.880923] [drm:amdgpu_job_timedout] *ERROR* ring gfx timeout, but soft
recovered
[ 1027.120907] [drm:amdgpu_job_timedout] *ERROR* ring gfx timeout, but soft
recovered

And the machine gets stuck/freezes, except one can ssh in and reboot it. So
only the graphical display will not restore properly. Also, if I reboot the
machine and the error above does not occur, then the console (not X display) is
somehow misaligned, that is the messages are not printed on the most-left
column, but a bit more in the middle of the screen.

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

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

[PATCH 3/4] drm/amd/display: add doc entries for MPC blending configuration

Describe structs and enums used to set blend mode properties to MPC
blocks. Some pieces of information are already available as code
comments, and were just formatted. Others were collected and summarised
from discusssions on AMD issue tracker[1][2].

[1] https://gitlab.freedesktop.org/drm/amd/-/issues/1734
[2] https://gitlab.freedesktop.org/drm/amd/-/issues/1769

Signed-off-by: Melissa Wen 
---
 drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h | 91 +
 1 file changed, 77 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h 
b/drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h
index 5097037e3962..cf28b841c42d 100644
--- a/drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h
+++ b/drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h
@@ -22,6 +22,16 @@
  *
  */
 
+/**
+ * DOC: mpc-overview
+ *
+ * Multiple Pipe/Plane Combined (MPC) is a component in the hardware pipeline
+ * that performs blending of multiple planes, using global and per-pixel alpha.
+ * It also performs post-blending color correction operations according to the
+ * hardware capabilities, such as color transformation matrix and gamma 1D and
+ * 3D LUT.
+ */
+
 #ifndef __DC_MPCC_H__
 #define __DC_MPCC_H__
 
@@ -48,14 +58,39 @@ enum mpcc_blend_mode {
MPCC_BLEND_MODE_TOP_BOT_BLENDING
 };
 
+/**
+ * enum mpcc_alpha_blend_mode - define the alpha blend mode regarding pixel
+ * alpha and plane alpha values
+ */
 enum mpcc_alpha_blend_mode {
+   /**
+* @MPCC_ALPHA_BLEND_MODE_PER_PIXEL_ALPHA: per pixel alpha using DPP
+* alpha value
+*/
MPCC_ALPHA_BLEND_MODE_PER_PIXEL_ALPHA,
+   /**
+* @MPCC_ALPHA_BLEND_MODE_PER_PIXEL_ALPHA_COMBINED_GLOBAL_GAIN: per
+* pixel alpha using DPP alpha value multiplied by a global gain (plane
+* alpha)
+*/
MPCC_ALPHA_BLEND_MODE_PER_PIXEL_ALPHA_COMBINED_GLOBAL_GAIN,
+   /**
+* @MPCC_ALPHA_BLEND_MODE_GLOBAL_ALPHA: global alpha value, ignores
+* pixel alpha and consider only plane alpha
+*/
MPCC_ALPHA_BLEND_MODE_GLOBAL_ALPHA
 };
 
-/*
- * MPCC blending configuration
+/**
+ * struct mpcc_blnd_cfg - MPCC blending configuration
+ *
+ * @black_color: background color
+ * @alpha_mode: alpha blend mode (MPCC_ALPHA_BLND_MODE)
+ * @pre_multiplied_alpha: whether pixel color values were pre-multiplied by the
+ * alpha channel (MPCC_ALPHA_MULTIPLIED_MODE)
+ * @global_gain: used when blend mode considers both pixel alpha and plane
+ * alpha value and assumes the global alpha value.
+ * @global_alpha: plane alpha value
  */
 struct mpcc_blnd_cfg {
struct tg_color black_color;/* background color */
@@ -107,8 +142,15 @@ struct mpc_dwb_flow_control {
int flow_ctrl_cnt1;
 };
 
-/*
- * MPCC connection and blending configuration for a single MPCC instance.
+/**
+ * struct mpcc - MPCC connection and blending configuration for a single MPCC 
instance.
+ * @mpcc_id: MPCC physical instance
+ * @dpp_id: DPP input to this MPCC
+ * @mpcc_bot: pointer to bottom layer MPCC. NULL when not connected.
+ * @blnd_cfg: the blending configuration for this MPCC
+ * @sm_cfg: stereo mix setting for this MPCC
+ * @shared_bottom: if MPCC output to both OPP and DWB endpoints, true. 
Othewise, false.
+ *
  * This struct is used as a node in an MPC tree.
  */
 struct mpcc {
@@ -120,8 +162,12 @@ struct mpcc {
bool shared_bottom; /* TRUE if MPCC output to both OPP and 
DWB endpoints, else FALSE */
 };
 
-/*
- * MPC tree represents all MPCC connections for a pipe.
+/**
+ * struct mpc_tree - MPC tree represents all MPCC connections for a pipe.
+ *
+ * @opp_id: the OPP instance that owns this MPC tree
+ * @opp_list: the top MPCC layer of the MPC tree that outputs to OPP endpoint
+ *
  */
 struct mpc_tree {
int opp_id; /* The OPP instance that owns this MPC 
tree */
@@ -149,13 +195,18 @@ struct mpcc_state {
uint32_t busy;
 };
 
+/**
+ * struct mpc_funcs - funcs
+ */
 struct mpc_funcs {
void (*read_mpcc_state)(
struct mpc *mpc,
int mpcc_inst,
struct mpcc_state *s);
 
-   /*
+   /**
+* @insert_plane:
+*
 * Insert DPP into MPC tree based on specified blending position.
 * Only used for planes that are part of blending chain for OPP output
 *
@@ -180,7 +231,9 @@ struct mpc_funcs {
int dpp_id,
int mpcc_id);
 
-   /*
+   /**
+* @remove_mpcc:
+*
 * Remove a specified MPCC from the MPC tree.
 *
 * Parameters:
@@ -195,7 +248,9 @@ struct mpc_funcs {
struct mpc_tree *tree,
struct mpcc *mpcc);
 
-   /*
+   /**
+* @mpc_init:
+*
 * Reset the MPCC HW status by disconnecting all muxes.
 *
 * Parameters:
@@ -208,7 +263,9 @@ struct mpc_funcs {

[PATCH 4/4] Documentation/gpu/amdgpu/amdgpu_dm: add DM docs for pixel blend mode

AMD GPU display manager (DM) maps DRM pixel blend modes (None,
Pre-multiplied, Coverage) to MPC hw blocks through blend configuration
options. Describe relevant elements and how to set and test them to get
the expected DRM blend mode on DCN hw.

Signed-off-by: Melissa Wen 
---
 .../gpu/amdgpu/display/display-manager.rst| 98 +++
 Documentation/gpu/drm-kms.rst |  2 +
 2 files changed, 100 insertions(+)

diff --git a/Documentation/gpu/amdgpu/display/display-manager.rst 
b/Documentation/gpu/amdgpu/display/display-manager.rst
index 8960a5f1fa66..7a495ed1f69e 100644
--- a/Documentation/gpu/amdgpu/display/display-manager.rst
+++ b/Documentation/gpu/amdgpu/display/display-manager.rst
@@ -84,3 +84,101 @@ families below.
 **DCN 3.0 family color caps and mapping**
 
 .. kernel-figure:: dcn3_cm_drm_current.svg
+
+Blend Mode Properties
+=
+
+Pixel blend mode is a DRM plane composition property of :c:type:`drm_plane` 
used to
+describes how pixels from a foreground plane (fg) are composited with the
+background plane (bg). Here, we present main concepts of DRM blend mode to help
+to understand how this property is mapped to AMD DC interface. See more about
+this DRM property and the alpha blending equations in :ref:`DRM Plane
+Composition Properties `.
+
+Basically, a blend mode sets the alpha blending equation for plane
+composition that fits the mode in which the alpha channel affects the state of
+pixel color values and, therefore, the resulted pixel color. For
+example, consider the following elements of the alpha blending equation:
+
+- *fg.rgb*: Each of the RGB component values from the foreground's pixel.
+- *fg.alpha*: Alpha component value from the foreground's pixel.
+- *bg.rgb*: Each of the RGB component values from the background.
+- *plane_alpha*: Plane alpha value set by the **plane "alpha" property**, see
+  more in `DRM Plane Composition Properties `.
+
+in the basic alpha blending equation::
+
+   out.rgb = alpha * fg.rgb + (1 - alpha) * bg.rgb
+
+the alpha channel value of each pixel in a plane is ignored and only the plane
+alpha affects the resulted pixel color values.
+
+DRM has three blend mode to define the blend formula in the plane composition:
+
+* **None**: Blend formula that ignores the pixel alpha.
+
+* **Pre-multiplied**: Blend formula that assumes the pixel color values in a
+  plane was already pre-multiplied by its own alpha channel before storage.
+
+* **Coverage**: Blend formula that assumes the pixel color values were not
+  pre-multiplied with the alpha channel values.
+
+and pre-multiplied is the default pixel blend mode, that means, when no blend
+mode property is created or defined, DRM considers the plane's pixels has
+pre-multiplied color values. On IGT GPU tools, the kms_plane_alpha_blend test
+provides a set of subtests to verify plane alpha and blend mode properties.
+
+The DRM blend mode and its elements are then mapped by AMDGPU display manager
+(DM) to program the blending configuration of the Multiple Pipe/Plane Combined
+(MPC), as follows:
+
+.. kernel-doc:: drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h
+   :doc: mpc-overview
+
+.. kernel-doc:: drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h
+   :functions: mpcc_blnd_cfg
+
+Therefore, the blending configuration for a single MPCC instance on the MPC
+tree is defined by :c:type:`mpcc_blnd_cfg`, where
+:c:type:`pre_multiplied_alpha` is the alpha pre-multiplied mode flag used to
+set :c:type:`MPCC_ALPHA_MULTIPLIED_MODE`. It controls whether alpha is
+multiplied (true/false), being only true for DRM pre-multiplied blend mode.
+:c:type:`mpcc_alpha_blend_mode` defines the alpha blend mode regarding pixel
+alpha and plane alpha values. It sets one of the three modes for
+:c:type:`MPCC_ALPHA_BLND_MODE`, as described below.
+
+.. kernel-doc:: drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h
+   :functions: mpcc_alpha_blend_mode
+
+DM then maps the elements of `enum mpcc_alpha_blend_mode` to those in the DRM
+blend formula, as follows:
+
+* *MPC pixel alpha* matches *DRM fg.alpha* as the alpha component value
+  from the plane's pixel
+* *MPC global alpha* matches *DRM plane_alpha* when the pixel alpha should
+  be ignored and, therefore, pixel values are not pre-multiplied
+* *MPC global gain* assumes *MPC global alpha* value when both *DRM
+  fg.alpha* and *DRM plane_alpha* participate in the blend equation
+
+In short, *fg.alpha* is ignored by selecting
+:c:type:`MPCC_ALPHA_BLEND_MODE_GLOBAL_ALPHA`. On the other hand, (plane_alpha *
+fg.alpha) component becomes available by selecting
+:c:type:`MPCC_ALPHA_BLEND_MODE_PER_PIXEL_ALPHA_COMBINED_GLOBAL_GAIN`. And the
+:c:type:`MPCC_ALPHA_MULTIPLIED_MODE` defines if the pixel color values are
+pre-multiplied by alpha or not.
+
+Blend configuration flow
+
+
+The alpha blending equation is configured from DRM to DC interface by the
+following path:
+
+1. When updating a :c:type:`drm_plane_state `, DM calls
+

[PATCH 2/4] Documentation/amdgpu/display: add DC color caps info

Add details about color correction capabilities and explain a bit about
differences between DC hw generations and also how they are mapped
between DRM and DC interface. Two schemas for DCN 2.0 and 3.0 (converted
to svg from the original png) is included to illustrate it. They were
obtained from a discussion[1] in the amd-gfx mailing list.

[1] 
https://lore.kernel.org/amd-gfx/20220422142811.dm6vtk6v64jcw...@mail.igalia.com/

v2:

- remove redundant comments (Harry)
- fix typo (Harry)

Signed-off-by: Melissa Wen 
---
 .../amdgpu/display/dcn2_cm_drm_current.svg| 1370 +++
 .../amdgpu/display/dcn3_cm_drm_current.svg| 1529 +
 .../gpu/amdgpu/display/display-manager.rst|   35 +
 drivers/gpu/drm/amd/display/dc/dc.h   |   74 +-
 4 files changed, 2995 insertions(+), 13 deletions(-)
 create mode 100644 Documentation/gpu/amdgpu/display/dcn2_cm_drm_current.svg
 create mode 100644 Documentation/gpu/amdgpu/display/dcn3_cm_drm_current.svg

diff --git a/Documentation/gpu/amdgpu/display/dcn2_cm_drm_current.svg 
b/Documentation/gpu/amdgpu/display/dcn2_cm_drm_current.svg
new file mode 100644
index ..315ffc5a1a4b
--- /dev/null
+++ b/Documentation/gpu/amdgpu/display/dcn2_cm_drm_current.svg
@@ -0,0 +1,1370 @@
+
+
+
+http://www.inkscape.org/namespaces/inkscape;
+   xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd;
+   xmlns="http://www.w3.org/2000/svg;
+   xmlns:svg="http://www.w3.org/2000/svg;>
+  
+  
+  
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Matrix
+1D LUT
+3D LUT
+Unpacking
+Other
+drm_framebuffer
+format
+drm_plane
+drm_crtc
+Stream
+MPC
+DPP
+
+Blender
+Degamma
+CTM
+Gamma
+format
+bias_and_scale
+color space matrix
+input_csc_color_matrix
+in_transfer_func
+hdr_mult
+gamut_remap_matrix
+in_shaper_func
+lut3d_func
+blend_tf
+Blender
+gamut_remap_matrix
+func_shaper
+lut3d_func
+out_transfer_func
+csc_color_matrix
+bit_depth_param
+clamping
+output_color_space
+Plane
+Legend
+DCN 2.0
+DC Interface
+DRM Interface
+
+CNVC
+Input CSC
+DeGammaRAM and ROM(sRGB, BT2020
+HDR Multiply
+Gamut Remap
+Shaper 
LUTRAM
+3D 
LUTRAM
+Blend Gamma
+Blender
+GammaRAM
+OCSC
+
+
+color_encoding
+
+pixel_blend_mode
+
+color_range
+
+
+
+
+
+
+
+
+
+
+
+
+  
+
diff --git a/Documentation/gpu/amdgpu/display/dcn3_cm_drm_current.svg 
b/Documentation/gpu/amdgpu/display/dcn3_cm_drm_current.svg
new file mode 100644
index ..7299ee9b6d64
--- /dev/null
+++ b/Documentation/gpu/amdgpu/display/dcn3_cm_drm_current.svg
@@ -0,0 +1,1529 @@
+
+
+
+http://www.inkscape.org/namespaces/inkscape;
+   xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd;
+   xmlns="http://www.w3.org/2000/svg;
+   xmlns:svg="http://www.w3.org/2000/svg;>
+  
+  
+  
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Matrix
+1D LUT
+3D LUT
+Unpacking
+Other
+drm_framebuffer
+format
+drm_plane
+drm_crtc
+Stream
+MPC
+DPP
+
+Blender
+Degamma
+CTM
+Gamma
+format
+bias_and_scale
+color space matrix
+input_csc_color_matrix
+in_transfer_func
+hdr_mult
+gamut_remap_matrix
+in_shaper_func
+lut3d_func
+blend_tf
+Blender
+gamut_remap_matrix
+func_shaper
+lut3d_func
+out_transfer_func
+csc_color_matrix
+bit_depth_param
+clamping
+output_color_space
+Plane
+Legend
+DCN 3.0
+DC Interface
+DRM Interface
+
+CNVC
+Input CSC
+DeGammaROM(sRGB, BT2020, Gamma 2.2,PQ, HLG)
+Post CSC
+Gamma Correction
+HDR Multiply
+Gamut Remap
+Shaper 
LUTRAM
+3D 
LUTRAM
+Blend Gamma
+Blender
+Gamut Remap
+Shaper 
LUTRAM
+3D 
LUTRAM
+GammaRAM
+OCSC
+
+
+color_encoding
+
+

[PATCH 0/4] Documentation/amdgpu/display: describe color and blend mode properties mapping

Patches 1 and 2 describe DM mapping of DRM color correction properties
to DC interface and where detached from 3D LUT RFC series [1]. Patches 3
and 4 describe MPC block programming that matches the three DRM blend
modes and came from previous work [2][3] and discussions on AMD issue
tracker. Let me know any misleading information.

[1] https://lore.kernel.org/amd-gfx/20220619223104.667413-1-m...@igalia.com/
[2] https://lore.kernel.org/amd-gfx/20220329201835.2393141-1-m...@igalia.com/
[3] 
https://lore.kernel.org/amd-gfx/7a95d6a4-bc2f-b0e8-83f8-8cc5b7559...@amd.com/

Melissa Wen (4):
  Documentation/amdgpu_dm: Add DM color correction documentation
  Documentation/amdgpu/display: add DC color caps info
  drm/amd/display: add doc entries for MPC blending configuration
  Documentation/gpu/amdgpu/amdgpu_dm: add DM docs for pixel blend mode

 .../amdgpu/display/dcn2_cm_drm_current.svg| 1370 +++
 .../amdgpu/display/dcn3_cm_drm_current.svg| 1529 +
 .../gpu/amdgpu/display/display-manager.rst|  142 ++
 Documentation/gpu/drm-kms.rst |2 +
 .../amd/display/amdgpu_dm/amdgpu_dm_color.c   |  121 +-
 drivers/gpu/drm/amd/display/dc/dc.h   |   74 +-
 drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h   |   91 +-
 7 files changed, 3270 insertions(+), 59 deletions(-)
 create mode 100644 Documentation/gpu/amdgpu/display/dcn2_cm_drm_current.svg
 create mode 100644 Documentation/gpu/amdgpu/display/dcn3_cm_drm_current.svg

-- 
2.35.1

[PATCH 1/4] Documentation/amdgpu_dm: Add DM color correction documentation

AMDGPU DM maps DRM color management properties (degamma, ctm and gamma)
to DC color correction entities. Part of this mapping is already
documented as code comments and can be converted as kernel docs.

v2:
- rebase to amd-staging-drm-next

Reviewed-by: Harry Wentland 
Signed-off-by: Melissa Wen 
---
 .../gpu/amdgpu/display/display-manager.rst|   9 ++
 .../amd/display/amdgpu_dm/amdgpu_dm_color.c   | 121 +-
 2 files changed, 98 insertions(+), 32 deletions(-)

diff --git a/Documentation/gpu/amdgpu/display/display-manager.rst 
b/Documentation/gpu/amdgpu/display/display-manager.rst
index 7ce31f89d9a0..b1b0f11aed83 100644
--- a/Documentation/gpu/amdgpu/display/display-manager.rst
+++ b/Documentation/gpu/amdgpu/display/display-manager.rst
@@ -40,3 +40,12 @@ Atomic Implementation
 
 .. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
:functions: amdgpu_dm_atomic_check amdgpu_dm_atomic_commit_tail
+
+Color Management Properties
+===
+
+.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
+   :doc: overview
+
+.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
+   :internal:
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
index a71177305bcd..93c813089bff 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
@@ -29,7 +29,9 @@
 #include "modules/color/color_gamma.h"
 #include "basics/conversion.h"
 
-/*
+/**
+ * DOC: overview
+ *
  * The DC interface to HW gives us the following color management blocks
  * per pipe (surface):
  *
@@ -71,8 +73,8 @@
 
 #define MAX_DRM_LUT_VALUE 0x
 
-/*
- * Initialize the color module.
+/**
+ * amdgpu_dm_init_color_mod - Initialize the color module.
  *
  * We're not using the full color module, only certain components.
  * Only call setup functions for components that we need.
@@ -82,7 +84,14 @@ void amdgpu_dm_init_color_mod(void)
setup_x_points_distribution();
 }
 
-/* Extracts the DRM lut and lut size from a blob. */
+/**
+ * __extract_blob_lut - Extracts the DRM lut and lut size from a blob.
+ * @blob: DRM color mgmt property blob
+ * @size: lut size
+ *
+ * Returns:
+ * DRM LUT or NULL
+ */
 static const struct drm_color_lut *
 __extract_blob_lut(const struct drm_property_blob *blob, uint32_t *size)
 {
@@ -90,13 +99,18 @@ __extract_blob_lut(const struct drm_property_blob *blob, 
uint32_t *size)
return blob ? (struct drm_color_lut *)blob->data : NULL;
 }
 
-/*
- * Return true if the given lut is a linear mapping of values, i.e. it acts
- * like a bypass LUT.
+/**
+ * __is_lut_linear - check if the given lut is a linear mapping of values
+ * @lut: given lut to check values
+ * @size: lut size
  *
  * It is considered linear if the lut represents:
- * f(a) = (0xFF00/MAX_COLOR_LUT_ENTRIES-1)a; for integer a in
- *   [0, MAX_COLOR_LUT_ENTRIES)
+ * f(a) = (0xFF00/MAX_COLOR_LUT_ENTRIES-1)a; for integer a in [0,
+ * MAX_COLOR_LUT_ENTRIES)
+ *
+ * Returns:
+ * True if the given lut is a linear mapping of values, i.e. it acts like a
+ * bypass LUT. Otherwise, false.
  */
 static bool __is_lut_linear(const struct drm_color_lut *lut, uint32_t size)
 {
@@ -119,9 +133,13 @@ static bool __is_lut_linear(const struct drm_color_lut 
*lut, uint32_t size)
return true;
 }
 
-/*
- * Convert the drm_color_lut to dc_gamma. The conversion depends on the size
- * of the lut - whether or not it's legacy.
+/**
+ * __drm_lut_to_dc_gamma - convert the drm_color_lut to dc_gamma.
+ * @lut: DRM lookup table for color conversion
+ * @gamma: DC gamma to set entries
+ * @is_legacy: legacy or atomic gamma
+ *
+ * The conversion depends on the size of the lut - whether or not it's legacy.
  */
 static void __drm_lut_to_dc_gamma(const struct drm_color_lut *lut,
  struct dc_gamma *gamma, bool is_legacy)
@@ -154,8 +172,11 @@ static void __drm_lut_to_dc_gamma(const struct 
drm_color_lut *lut,
}
 }
 
-/*
- * Converts a DRM CTM to a DC CSC float matrix.
+/**
+ * __drm_ctm_to_dc_matrix - converts a DRM CTM to a DC CSC float matrix
+ * @ctm: DRM color transformation matrix
+ * @matrix: DC CSC float matrix
+ *
  * The matrix needs to be a 3x4 (12 entry) matrix.
  */
 static void __drm_ctm_to_dc_matrix(const struct drm_color_ctm *ctm,
@@ -189,7 +210,18 @@ static void __drm_ctm_to_dc_matrix(const struct 
drm_color_ctm *ctm,
}
 }
 
-/* Calculates the legacy transfer function - only for sRGB input space. */
+/**
+ * __set_legacy_tf - Calculates the legacy transfer function
+ * @func: transfer function
+ * @lut: lookup table that defines the color space
+ * @lut_size: size of respective lut
+ * @has_rom: if ROM can be used for hardcoded curve
+ *
+ * Only for sRGB input space
+ *
+ * Returns:
+ * 0 in case of sucess, -ENOMEM if fails
+ */
 static int

Re: [git pull] drm fixes for 5.19-rc7

2022-07-16 Thread Linus Torvalds

On Sat, Jul 16, 2022 at 2:35 PM Linus Torvalds
 wrote:
>
> That said, even those type simplifications do not fix the fundamental
> issue. That "DIV_ROUND_UP()" still ends up being a 64-bit divide,
> although now it's at least a "64-by-32" bit divide.

Hmm. The "DIV_ROUND_UP()" issue could be solved by just making the
rule be that the max_segment size is always a power of two.

Then you don't need the (expensive!) DIV_ROUND_UP(), and can just use
the regular "round_up()" that works on powers-of-two.

And the simplest way to do that is to just make "max_segments" be 2GB.

The whole "round_down(UINT_MAX, page_alignment)" seems entirely
pointless. Do you really want segments that are some odd number just
under the 4GB mark, and force expensive divides?

For consistency, I used the same value in
i915_rsgt_from_buddy_resource(). I have no idea if that makes sense.

Anyway, the attached patch is COMPLETELY UNTESTED. But it at least
seems to compile. Maybe.

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

diff --git a/drivers/gpu/drm/i915/i915_scatterlist.c b/drivers/gpu/drm/i915/i915_scatterlist.c
index f63b50b71e10..830dcd833d4e 100644
--- a/drivers/gpu/drm/i915/i915_scatterlist.c
+++ b/drivers/gpu/drm/i915/i915_scatterlist.c
@@ -81,7 +81,9 @@ struct i915_refct_sgt *i915_rsgt_from_mm_node(const struct drm_mm_node *node,
 	  u64 region_start,
 	  u64 page_alignment)
 {
-	const u64 max_segment = round_down(UINT_MAX, page_alignment);
+	// Make sure max_segment (and thus segment_pages) is
+	// a power of two that fits in 32 bits.
+	const u64 max_segment = 1ul << 31;
 	u64 segment_pages = max_segment >> PAGE_SHIFT;
 	u64 block_size, offset, prev_end;
 	struct i915_refct_sgt *rsgt;
@@ -96,7 +98,7 @@ struct i915_refct_sgt *i915_rsgt_from_mm_node(const struct drm_mm_node *node,
 
 	i915_refct_sgt_init(rsgt, node->size << PAGE_SHIFT);
 	st = >table;
-	if (sg_alloc_table(st, DIV_ROUND_UP(node->size, segment_pages),
+	if (sg_alloc_table(st, round_up(node->size, segment_pages),
 			   GFP_KERNEL)) {
 		i915_refct_sgt_put(rsgt);
 		return ERR_PTR(-ENOMEM);
@@ -159,7 +161,7 @@ struct i915_refct_sgt *i915_rsgt_from_buddy_resource(struct ttm_resource *res,
 {
 	struct i915_ttm_buddy_resource *bman_res = to_ttm_buddy_resource(res);
 	const u64 size = res->num_pages << PAGE_SHIFT;
-	const u64 max_segment = round_down(UINT_MAX, page_alignment);
+	const u64 max_segment = 1u << 31;
 	struct drm_buddy *mm = bman_res->mm;
 	struct list_head *blocks = _res->blocks;
 	struct drm_buddy_block *block;

Re: [PATCH] drm: Fix EDID firmware load on resume

Hi Matthieu,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on v5.19-rc6]
[also build test ERROR on linus/master]
[cannot apply to drm-misc/drm-misc-next next-20220715]
[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/Matthieu-CHARETTE/drm-Fix-EDID-firmware-load-on-resume/20220716-214028
base:32346491ddf24599decca06190ebca03ff9de7f8
config: x86_64-randconfig-a015 
(https://download.01.org/0day-ci/archive/20220717/202207170521.uxrz8urh-...@intel.com/config)
compiler: gcc-11 (Debian 11.3.0-3) 11.3.0
reproduce (this is a W=1 build):
# 
https://github.com/intel-lab-lkp/linux/commit/e583aaf4f6464add35f2350c728d80a3fe790638
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review 
Matthieu-CHARETTE/drm-Fix-EDID-firmware-load-on-resume/20220716-214028
git checkout e583aaf4f6464add35f2350c728d80a3fe790638
# save the config file
mkdir build_dir && cp config build_dir/.config
make W=1 O=build_dir ARCH=x86_64 SHELL=/bin/bash

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

All errors (new ones prefixed by >>):

   ld: certs/system_keyring.o: in function `load_system_certificate_list':
   system_keyring.c:(.init.text+0x149): undefined reference to 
`x509_load_certificate_list'
   ld: drivers/gpu/drm/drm_connector.o: in function `drm_connector_init':
>> drm_connector.c:(.text+0x21ce): undefined reference to 
>> `drm_cache_edid_firmware'

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

Re: [PATCH v5 10/13] power: supply: mt6370: Add MediaTek MT6370 charger driver

2022-07-16 Thread Sebastian Reichel

Hi,

On Fri, Jul 15, 2022 at 07:26:04PM +0800, ChiaEn Wu wrote:
> From: ChiaEn Wu 
> 
> MediaTek MT6370 is a SubPMIC consisting of a single cell battery charger
> with ADC monitoring, RGB LEDs, dual channel flashlight, WLED backlight
> driver, display bias voltage supply, one general purpose LDO, and the
> USB Type-C & PD controller complies with the latest USB Type-C and PD
> standards.
> 
> This adds MediaTek MT6370 Charger driver support. The charger module
> of MT6370 supports High-Accuracy Voltage/Current Regulation,
> Average Input Current Regulation, Battery Temperature Sensing,
> Over-Temperature Protection, DPDM Detection for BC1.2.
> 
> Signed-off-by: ChiaEn Wu 
> ---

Please provide a dump from '/sys/class/power_supply//uevent'
below the fold in the next revision. I would like to check that you
got the units right in the next submission (in this one they are
definetly not correct).

> v5
> - Replace unsigned int type of pwr_rdy with bool in
>   mt6370_chg_set_online()
> - Remove redundant 'else' in mt6370_chg_field_get()
> - Revise 'if-else' in mt6370_chg_field_set()
> - Revise 'if' condition in mt6370_chg_enable_irq()
> - Revise all text 'otg' --> 'OTG'
> - Revise MT6370_MIVR_IBUS_TH_100_MA --> MT6370_MIVR_IBUS_TH_100_mA
> - Revise the description of Kconfig help text
> ---
>  drivers/power/supply/Kconfig  |   14 +
>  drivers/power/supply/Makefile |1 +
>  drivers/power/supply/mt6370-charger.c | 1062 
> +
>  3 files changed, 1077 insertions(+)
>  create mode 100644 drivers/power/supply/mt6370-charger.c
> 
> diff --git a/drivers/power/supply/Kconfig b/drivers/power/supply/Kconfig
> index 1aa8323..591deb8 100644
> --- a/drivers/power/supply/Kconfig
> +++ b/drivers/power/supply/Kconfig
> @@ -619,6 +619,20 @@ config CHARGER_MT6360
> Average Input Current Regulation, Battery Temperature Sensing,
> Over-Temperature Protection, DPDM Detection for BC1.2.
>  
> +config CHARGER_MT6370
> + tristate "MediaTek MT6370 Charger Driver"
> + depends on MFD_MT6370
> + depends on REGULATOR
> + select LINEAR_RANGES
> + help
> +   Say Y here to enable MT6370 Charger Part.
> +   The device supports High-Accuracy Voltage/Current Regulation,
> +   Average Input Current Regulation, Battery Temperature Sensing,
> +   Over-Temperature Protection, DPDM Detection for BC1.2.
> +
> +   This driver can also be built as a module. If so, the module
> +   will be called "mt6370-charger".
> +
>  config CHARGER_QCOM_SMBB
>   tristate "Qualcomm Switch-Mode Battery Charger and Boost"
>   depends on MFD_SPMI_PMIC || COMPILE_TEST
> diff --git a/drivers/power/supply/Makefile b/drivers/power/supply/Makefile
> index 7f02f36..8c95276 100644
> --- a/drivers/power/supply/Makefile
> +++ b/drivers/power/supply/Makefile
> @@ -82,6 +82,7 @@ obj-$(CONFIG_CHARGER_MAX8997)   += max8997_charger.o
>  obj-$(CONFIG_CHARGER_MAX8998)+= max8998_charger.o
>  obj-$(CONFIG_CHARGER_MP2629) += mp2629_charger.o
>  obj-$(CONFIG_CHARGER_MT6360) += mt6360_charger.o
> +obj-$(CONFIG_CHARGER_MT6370) += mt6370-charger.o
>  obj-$(CONFIG_CHARGER_QCOM_SMBB)  += qcom_smbb.o
>  obj-$(CONFIG_CHARGER_BQ2415X)+= bq2415x_charger.o
>  obj-$(CONFIG_CHARGER_BQ24190)+= bq24190_charger.o
> diff --git a/drivers/power/supply/mt6370-charger.c 
> b/drivers/power/supply/mt6370-charger.c
> new file mode 100644
> index 000..76a8c91
> --- /dev/null
> +++ b/drivers/power/supply/mt6370-charger.c
> @@ -0,0 +1,1062 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (C) 2022 Richtek Technology Corp.
> + *
> + * Author: ChiaEn Wu 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define MT6370_REG_CHG_CTRL1 0x111
> +#define MT6370_REG_CHG_CTRL2 0x112
> +#define MT6370_REG_CHG_CTRL3 0x113
> +#define MT6370_REG_CHG_CTRL4 0x114
> +#define MT6370_REG_CHG_CTRL5 0x115
> +#define MT6370_REG_CHG_CTRL6 0x116
> +#define MT6370_REG_CHG_CTRL7 0x117
> +#define MT6370_REG_CHG_CTRL8 0x118
> +#define MT6370_REG_CHG_CTRL9 0x119
> +#define MT6370_REG_CHG_CTRL100x11A
> +#define MT6370_REG_DEVICE_TYPE   0x122
> +#define MT6370_REG_USB_STATUS1   0x127
> +#define MT6370_REG_CHG_STAT  0x14A
> +#define MT6370_REG_FLED_EN   0x17E
> +#define MT6370_REG_CHG_STAT1 0X1D0
> +#define MT6370_REG_OVPCTRL_STAT  0x1D8
> +
> +#define MT6370_VOBST_MASKGENMASK(7, 2)
> +#define MT6370_OTG_PIN_EN_MASK   BIT(1)
> +#define MT6370_OPA_MODE_MASK BIT(0)
> +#define MT6370_OTG_OC_MASK   GENMASK(2, 0)
> +
> +#define MT6370_MIVR_IBUS_TH_100_mA   10
> +#define MT6370_ADC_CHAN_IBUS 5
> +#define MT6370_ADC_CHAN_MAX

Re: [git pull] drm fixes for 5.19-rc7

2022-07-16 Thread Linus Torvalds

On Fri, Jul 15, 2022 at 2:09 PM Nathan Chancellor  wrote:
>
> On Fri, Jul 15, 2022 at 01:36:17PM +1000, Dave Airlie wrote:
> > Matthew Auld (1):
> >   drm/i915/ttm: fix sg_table construction
>
> This patch breaks i386_defconfig with both GCC and clang:
>
>   ld: drivers/gpu/drm/i915/i915_scatterlist.o: in function 
> `i915_rsgt_from_mm_node':
>   i915_scatterlist.c:(.text+0x1a7): undefined reference to `__udivdi3'

Yeah, we definitely don't want arbitrary 64x64 divides in the kernel,
and the fact that we don't include libgcc.a once again caught this
horrid issue.

The offending code is

if (sg_alloc_table(st, DIV_ROUND_UP(node->size, segment_pages),
   GFP_KERNEL)) {

and I have to say that all of those games with "u64 page_alignment"
that commit aff1e0b09b54 ("drm/i915/ttm: fix sg_table construction")
introduces are absolutely disgusting.

And they are just *pointlessly* disgusting.

Why is that "page_alignment" a "u64"?

And why is it a "size", instead of being a "number of bits"?

The code literally does things like

const u64 max_segment = round_down(UINT_MAX, page_alignment);

which means that

 (a) page_alignment must be a power-of-two for this to work
(round_down() only works in powers of two)

 (b) the result obviously must fit in an "unsigned int", since it's
rounding down a UINT_MAX!

So (a) makes it doubtful that "page_alignment" should have been a
value (as opposed to mask), and (b) then questions why was that made
an "u64" value when it cannot have a u64 range?

And if max_segments cannot have a 64-bit range, then segment_pages here:

u64 segment_pages = max_segment >> PAGE_SHIFT;

sure cannot.

Fixing those then uncovers other things:

len = min(block_size, max_segment - sg->length);

now complains about mixing types ("max_segment - sg->length" being
u32), because 'block_size' is 64, bit, and that does seem to make some
amount of sense:

block_size = node->size << PAGE_SHIFT;

with the 'node->size' being from drm_mm_node, and that size is a
'u64'. That I *could* see being more than 32 bits on a 64-bit
architecture. Ok.

But then that means that 'len' cannot be a 64-bit value either, and it
should probably have been

u32 len;
..
len = min_t(u64, block_size, max_segment - sg->length);

and that would just have been a lot nicer on 32-bit x86, avoiding a
lot of pointlessly 64-bit things.

That said, even those type simplifications do not fix the fundamental
issue. That "DIV_ROUND_UP()" still ends up being a 64-bit divide,
although now it's at least a "64-by-32" bit divide.

Which needs to be handled by "do_div()" rather than the generic
DIV_ROUND_UP() helper, because sadly, at least gcc still generates a
full __udivdi3() even for the 64-by-32 divides.

Can Intel GPU people please take a look?

 Linus

[PATCH] drm/i915/gt: Remove unneeded semicolon

2022-07-16 Thread Jason Wang

The semicolon after the `}' in line 648 is unneeded.

Signed-off-by: Jason Wang 
---
 drivers/gpu/drm/i915/gt/intel_migrate.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_migrate.c 
b/drivers/gpu/drm/i915/gt/intel_migrate.c
index 2c35324b5f68..a69b244f14d0 100644
--- a/drivers/gpu/drm/i915/gt/intel_migrate.c
+++ b/drivers/gpu/drm/i915/gt/intel_migrate.c
@@ -645,7 +645,7 @@ static int scatter_list_length(struct scatterlist *sg)
while (sg && sg_dma_len(sg)) {
len += sg_dma_len(sg);
sg = sg_next(sg);
-   };
+   }
 
return len;
 }
-- 
2.35.1

Re: [PATCH v3 2/6] dt-bindings: Use new video interface bus type macros in examples

2022-07-16 Thread Sakari Ailus

Hi Laurent,

On Thu, Jun 16, 2022 at 01:14:06AM +0300, Laurent Pinchart wrote:
> Now that a header exists with macros for the media interface bus-type
> values, replace hardcoding numerical constants with the corresponding
> macros in the DT binding examples.
> 
> Signed-off-by: Laurent Pinchart 
> ---
> Changes since v2:
> 
> - Go back to PARALLEL
> 
> Changes since v1:
> 
> - Rename PARALLEL to BT601
> ---
>  .../devicetree/bindings/display/bridge/analogix,anx7625.yaml  | 1 +
>  Documentation/devicetree/bindings/media/i2c/mipi-ccs.yaml | 3 ++-
>  Documentation/devicetree/bindings/media/i2c/ovti,ov772x.yaml  | 3 ++-
>  .../devicetree/bindings/media/marvell,mmp2-ccic.yaml  | 3 ++-
>  Documentation/devicetree/bindings/media/microchip,xisc.yaml   | 3 ++-
>  Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml| 4 +++-
>  6 files changed, 12 insertions(+), 5 deletions(-)
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml 
> b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> index 35a48515836e..b0e5585f93e2 100644
> --- a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> +++ b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> @@ -118,6 +118,7 @@ additionalProperties: false
>  examples:
>- |
>  #include 
> +#include 
>  
>  i2c0 {
>  #address-cells = <1>;

The definition doesn't seem to be used here. Is there a need to include
this?

I could drop this chunk while applying. There's just one trivial change
elsewhere in this patch to make.

-- 
Kind regards,

Sakari Ailus

Re: [PATCH 0/1] [RFC] drm/fourcc: Add new unsigned R16_UINT/RG1616_UINT formats

2022-07-16 Thread Dennis Tsiang

On 30/06/2022 08:47, Pekka Paalanen wrote:

On Wed, 29 Jun 2022 14:53:49 +
Simon Ser wrote:

On Wednesday, June 29th, 2022 at 16:46, Dennis Tsiang
wrote:

Thanks for your comments. This is not intended to be used for KMS, where
indeed there would be no difference. This proposal is for other Graphics
APIs such as Vulkan, which requires the application to be explicit
upfront about how they will interpret the data, whether that be UNORM,
UINT .etc. We want to be able to import dma_bufs which create a VkImage
with a "_UINT" VkFormat. However there is currently no explicit mapping
between the DRM fourccs + modifiers combos to "_UINT" VkFormats. One
solution is to encode that into the fourccs, which is what this RFC is
proposing.

As a general comment, I don't think it's reasonable to encode all of the
VkFormat information inside DRM FourCC. For instance, VkFormat has SRGB/UNORM
variants which describe whether pixel values are electrical or optical
(IOW, EOTF-encoded or not). Moreover, other APIs may encode different
information in their format enums.

Yeah, do not add any of that information to the DRM pixel format codes.

There is *so much* other stuff you also need to define than what's
already mentioned, and which bits you need for the API at hand depends
totally on the API at hand. After the API has defined some parts of the
metadata, the API user has to take care of the remaining parts of the
metadata in other ways, like dynamic range or color space.

Besides, when you deal with dmabuf, you already need to pass a lot of
metadata explicitly, like the pixel format, width, height, stride,
modifier, etc. so it's better to add more of those (like we will be
doing in Wayland, and not specific to dmabuf even) than to try make
pixel formats a huge mess through combinatorial explosion and sometimes
partial and sometimes conflicting image metadata.

You might be able to get a glimpse of what all metadata there could be
by reading
https://gitlab.freedesktop.org/pq/color-and-hdr/-/blob/main/doc/pixels_color.md
.

Compare Vulkan formats to e.g.
https://docs.microsoft.com/en-us/windows/win32/api/dxgicommon/ne-dxgicommon-dxgi_color_space_type
and you'll see that while DXGI color space enumeration is mostly about
other stuff, it also has overlap with Vulkan formats I think, at least
the SRGB vs. not part.

Btw. practically all buffers you see used, especially if they are 8
bpc, they are almost guaranteed to be "SRGB" non-linearly encoded, but
do you ever see that fact being explicitly communicated?

Then there is the question that if you have an SRGB-encoded buffer, do
you want to read out SRGB-encoded or linear values? That depends on
what you are doing with the buffer, so if you always mapped dmabuf to
Vulkan SRGB formats (or always to non-SRGB formats), then you need some
other way in Vulkan for the app to say whether to sample encoded or
linear (electrical or optical) values. And whether texture filtering is
done in encoded or linear space, because that makes a difference too.

IOW, there are cases where the format mapping depends on the user of the
buffer and not only on the contents of the buffer.

Therefore you simply cannot create a static mapping table between two
format definition systems when the two systems are fundamentally
different, like Vulkan and DRM fourcc.

Thanks,
pq

Thanks all for your comments. We'll look into an alternative approach to
achieve what we need.
IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient,
please notify the sender immediately and do not disclose the contents to any
other person, use it for any purpose, or store or copy the information in any
medium. Thank you.

[PATCH v2] i2c: imx: fix typo in comment

2022-07-16 Thread Flavio Suligoi

to provid --> to provide

Signed-off-by: Flavio Suligoi 
---
v2:
 - fix typo in subject

 drivers/i2c/busses/i2c-imx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
index e9e2db68b9fb..78fb1a4274a6 100644
--- a/drivers/i2c/busses/i2c-imx.c
+++ b/drivers/i2c/busses/i2c-imx.c
@@ -66,7 +66,7 @@
 
 /* IMX I2C registers:
  * the I2C register offset is different between SoCs,
- * to provid support for all these chips, split the
+ * to provide support for all these chips, split the
  * register offset into a fixed base address and a
  * variable shift value, then the full register offset
  * will be calculated by
-- 
2.25.1

[PATCH] drm/amd/display: move dcn31_update_soc_for_wm_a func to dml fpu folder

Although dcn31_update_soc_for_wm_a() is only called in dml/dcn31/dcn31_fpu by
dc->res_pool->funcs->update_soc_for_wm_a(dc, context), it's declared in
dcn31_resource that is not FPU protected. Move this function to dcn31_fpu
file as part of the work to isolate FPU code.

Signed-off-by: Melissa Wen 
---
 drivers/gpu/drm/amd/display/dc/dcn31/dcn31_resource.c | 9 -
 drivers/gpu/drm/amd/display/dc/dcn31/dcn31_resource.h | 1 -
 drivers/gpu/drm/amd/display/dc/dml/dcn31/dcn31_fpu.c  | 9 +
 drivers/gpu/drm/amd/display/dc/dml/dcn31/dcn31_fpu.h  | 2 ++
 4 files changed, 11 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_resource.c 
b/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_resource.c
index 16bbccc69fdc..17c776e88514 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_resource.c
@@ -1716,15 +1716,6 @@ int dcn31_populate_dml_pipes_from_context(
return pipe_cnt;
 }
 
-void dcn31_update_soc_for_wm_a(struct dc *dc, struct dc_state *context)
-{
-   if (dc->clk_mgr->bw_params->wm_table.entries[WM_A].valid) {
-   context->bw_ctx.dml.soc.dram_clock_change_latency_us = 
dc->clk_mgr->bw_params->wm_table.entries[WM_A].pstate_latency_us;
-   context->bw_ctx.dml.soc.sr_enter_plus_exit_time_us = 
dc->clk_mgr->bw_params->wm_table.entries[WM_A].sr_enter_plus_exit_time_us;
-   context->bw_ctx.dml.soc.sr_exit_time_us = 
dc->clk_mgr->bw_params->wm_table.entries[WM_A].sr_exit_time_us;
-   }
-}
-
 void dcn31_calculate_wm_and_dlg(
struct dc *dc, struct dc_state *context,
display_e2e_pipe_params_st *pipes,
diff --git a/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_resource.h 
b/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_resource.h
index 393458015d6a..41f8ec99da6b 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_resource.h
+++ b/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_resource.h
@@ -59,7 +59,6 @@ dcn31_set_mcif_arb_params(struct dc *dc,
  struct dc_state *context,
  display_e2e_pipe_params_st *pipes,
  int pipe_cnt);
-void dcn31_update_soc_for_wm_a(struct dc *dc, struct dc_state *context);
 
 struct resource_pool *dcn31_create_resource_pool(
const struct dc_init_data *init_data,
diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn31/dcn31_fpu.c 
b/drivers/gpu/drm/amd/display/dc/dml/dcn31/dcn31_fpu.c
index 7be3476989ce..facac3daeaca 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/dcn31/dcn31_fpu.c
+++ b/drivers/gpu/drm/amd/display/dc/dml/dcn31/dcn31_fpu.c
@@ -435,6 +435,15 @@ struct _vcs_dpi_soc_bounding_box_st dcn3_16_soc = {
.urgent_latency_adjustment_fabric_clock_reference_mhz = 0,
 };
 
+void dcn31_update_soc_for_wm_a(struct dc *dc, struct dc_state *context)
+{
+   if (dc->clk_mgr->bw_params->wm_table.entries[WM_A].valid) {
+   context->bw_ctx.dml.soc.dram_clock_change_latency_us = 
dc->clk_mgr->bw_params->wm_table.entries[WM_A].pstate_latency_us;
+   context->bw_ctx.dml.soc.sr_enter_plus_exit_time_us = 
dc->clk_mgr->bw_params->wm_table.entries[WM_A].sr_enter_plus_exit_time_us;
+   context->bw_ctx.dml.soc.sr_exit_time_us = 
dc->clk_mgr->bw_params->wm_table.entries[WM_A].sr_exit_time_us;
+   }
+}
+
 void dcn31_calculate_wm_and_dlg_fp(
struct dc *dc, struct dc_state *context,
display_e2e_pipe_params_st *pipes,
diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn31/dcn31_fpu.h 
b/drivers/gpu/drm/amd/display/dc/dml/dcn31/dcn31_fpu.h
index 24ac19c83687..0a10de80c1a4 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/dcn31/dcn31_fpu.h
+++ b/drivers/gpu/drm/amd/display/dc/dml/dcn31/dcn31_fpu.h
@@ -31,6 +31,8 @@
 #define DCN3_15_MIN_COMPBUF_SIZE_KB 128
 #define DCN3_16_DEFAULT_DET_SIZE 192
 
+void dcn31_update_soc_for_wm_a(struct dc *dc, struct dc_state *context);
+
 void dcn31_calculate_wm_and_dlg_fp(
struct dc *dc, struct dc_state *context,
display_e2e_pipe_params_st *pipes,
-- 
2.35.1

Re: [PATCH] drm: Fix EDID firmware load on resume

Hi Matthieu,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on v5.19-rc6]
[also build test WARNING on linus/master]
[cannot apply to drm-misc/drm-misc-next next-20220715]
[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/Matthieu-CHARETTE/drm-Fix-EDID-firmware-load-on-resume/20220716-214028
base:32346491ddf24599decca06190ebca03ff9de7f8
config: i386-randconfig-a003 
(https://download.01.org/0day-ci/archive/20220717/202207170211.aampuwps-...@intel.com/config)
compiler: gcc-11 (Debian 11.3.0-3) 11.3.0
reproduce (this is a W=1 build):
# 
https://github.com/intel-lab-lkp/linux/commit/e583aaf4f6464add35f2350c728d80a3fe790638
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review 
Matthieu-CHARETTE/drm-Fix-EDID-firmware-load-on-resume/20220716-214028
git checkout e583aaf4f6464add35f2350c728d80a3fe790638
# save the config file
mkdir build_dir && cp config build_dir/.config
make W=1 O=build_dir ARCH=i386 SHELL=/bin/bash drivers/gpu/drm/

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

All warnings (new ones prefixed by >>):

   In file included from drivers/gpu/drm/drm_connector.c:25:
>> include/drm/drm_edid.h:387:1: warning: 'drm_cache_edid_firmware' used but 
>> never defined
 387 | drm_cache_edid_firmware(struct drm_connector *connector);
 | ^~~


vim +/drm_cache_edid_firmware +387 include/drm/drm_edid.h

   374  
   375  int drm_edid_to_sad(const struct edid *edid, struct cea_sad **sads);
   376  int drm_edid_to_speaker_allocation(const struct edid *edid, u8 **sadb);
   377  int drm_av_sync_delay(struct drm_connector *connector,
   378const struct drm_display_mode *mode);
   379  
   380  #ifdef CONFIG_DRM_LOAD_EDID_FIRMWARE
   381  void drm_cache_edid_firmware(struct drm_connector *connector);
   382  struct edid *drm_load_edid_firmware(struct drm_connector *connector);
   383  int __drm_set_edid_firmware_path(const char *path);
   384  int __drm_get_edid_firmware_path(char *buf, size_t bufsize);
   385  #else
   386  static inline void
 > 387  drm_cache_edid_firmware(struct drm_connector *connector);
   388  static inline struct edid *
   389  drm_load_edid_firmware(struct drm_connector *connector)
   390  {
   391  return ERR_PTR(-ENOENT);
   392  }
   393  #endif
   394  

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

[PATCH v1 11/11] drm: Move dri1 core files to drm/dri1

To have more of the dri1 specific support in one place move the dri1
core files to the dri1 folder.
The files continue to be part of the drm module, we just refer to the files
with a folder name.

Signed-off-by: Sam Ravnborg 
---
 drivers/gpu/drm/Makefile | 10 +++---
 drivers/gpu/drm/{ => dri1}/drm_agpsupport.c  |  0
 drivers/gpu/drm/{ => dri1}/drm_bufs.c|  0
 drivers/gpu/drm/{ => dri1}/drm_context.c |  0
 drivers/gpu/drm/{ => dri1}/drm_dma.c |  0
 drivers/gpu/drm/{ => dri1}/drm_hashtab.c |  0
 drivers/gpu/drm/{ => dri1}/drm_irq.c |  0
 drivers/gpu/drm/{ => dri1}/drm_legacy_misc.c |  0
 drivers/gpu/drm/{ => dri1}/drm_lock.c|  0
 drivers/gpu/drm/{ => dri1}/drm_memory.c  |  0
 drivers/gpu/drm/{ => dri1}/drm_scatter.c |  0
 drivers/gpu/drm/{ => dri1}/drm_vm.c  |  0
 12 files changed, 7 insertions(+), 3 deletions(-)
 rename drivers/gpu/drm/{ => dri1}/drm_agpsupport.c (100%)
 rename drivers/gpu/drm/{ => dri1}/drm_bufs.c (100%)
 rename drivers/gpu/drm/{ => dri1}/drm_context.c (100%)
 rename drivers/gpu/drm/{ => dri1}/drm_dma.c (100%)
 rename drivers/gpu/drm/{ => dri1}/drm_hashtab.c (100%)
 rename drivers/gpu/drm/{ => dri1}/drm_irq.c (100%)
 rename drivers/gpu/drm/{ => dri1}/drm_legacy_misc.c (100%)
 rename drivers/gpu/drm/{ => dri1}/drm_lock.c (100%)
 rename drivers/gpu/drm/{ => dri1}/drm_memory.c (100%)
 rename drivers/gpu/drm/{ => dri1}/drm_scatter.c (100%)
 rename drivers/gpu/drm/{ => dri1}/drm_vm.c (100%)

diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index a3bd337bcab4..02ae13a71281 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -18,9 +18,13 @@ drm-y   :=   drm_aperture.o drm_auth.o drm_cache.o \
drm_syncobj.o drm_lease.o drm_writeback.o drm_client.o \
drm_client_modeset.o drm_atomic_uapi.o \
drm_managed.o drm_vblank_work.o
-drm-$(CONFIG_DRM_DRI1) += drm_agpsupport.o drm_bufs.o drm_context.o drm_dma.o \
- drm_hashtab.o drm_irq.o drm_legacy_misc.o drm_lock.o \
- drm_memory.o drm_scatter.o drm_vm.o
+
+drm-$(CONFIG_DRM_DRI1) += dri1/drm_agpsupport.o dri1/drm_bufs.o \
+ dri1/drm_context.o dri1/drm_dma.o \
+ dri1/drm_hashtab.o dri1/drm_irq.o \
+ dri1/drm_legacy_misc.o dri1/drm_lock.o \
+ dri1/drm_memory.o dri1/drm_scatter.o \
+ dri1/drm_vm.o
 drm-$(CONFIG_DRM_LIB_RANDOM) += lib/drm_random.o
 drm-$(CONFIG_COMPAT) += drm_ioc32.o
 drm-$(CONFIG_DRM_PANEL) += drm_panel.o
diff --git a/drivers/gpu/drm/drm_agpsupport.c 
b/drivers/gpu/drm/dri1/drm_agpsupport.c
similarity index 100%
rename from drivers/gpu/drm/drm_agpsupport.c
rename to drivers/gpu/drm/dri1/drm_agpsupport.c
diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/dri1/drm_bufs.c
similarity index 100%
rename from drivers/gpu/drm/drm_bufs.c
rename to drivers/gpu/drm/dri1/drm_bufs.c
diff --git a/drivers/gpu/drm/drm_context.c b/drivers/gpu/drm/dri1/drm_context.c
similarity index 100%
rename from drivers/gpu/drm/drm_context.c
rename to drivers/gpu/drm/dri1/drm_context.c
diff --git a/drivers/gpu/drm/drm_dma.c b/drivers/gpu/drm/dri1/drm_dma.c
similarity index 100%
rename from drivers/gpu/drm/drm_dma.c
rename to drivers/gpu/drm/dri1/drm_dma.c
diff --git a/drivers/gpu/drm/drm_hashtab.c b/drivers/gpu/drm/dri1/drm_hashtab.c
similarity index 100%
rename from drivers/gpu/drm/drm_hashtab.c
rename to drivers/gpu/drm/dri1/drm_hashtab.c
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/dri1/drm_irq.c
similarity index 100%
rename from drivers/gpu/drm/drm_irq.c
rename to drivers/gpu/drm/dri1/drm_irq.c
diff --git a/drivers/gpu/drm/drm_legacy_misc.c 
b/drivers/gpu/drm/dri1/drm_legacy_misc.c
similarity index 100%
rename from drivers/gpu/drm/drm_legacy_misc.c
rename to drivers/gpu/drm/dri1/drm_legacy_misc.c
diff --git a/drivers/gpu/drm/drm_lock.c b/drivers/gpu/drm/dri1/drm_lock.c
similarity index 100%
rename from drivers/gpu/drm/drm_lock.c
rename to drivers/gpu/drm/dri1/drm_lock.c
diff --git a/drivers/gpu/drm/drm_memory.c b/drivers/gpu/drm/dri1/drm_memory.c
similarity index 100%
rename from drivers/gpu/drm/drm_memory.c
rename to drivers/gpu/drm/dri1/drm_memory.c
diff --git a/drivers/gpu/drm/drm_scatter.c b/drivers/gpu/drm/dri1/drm_scatter.c
similarity index 100%
rename from drivers/gpu/drm/drm_scatter.c
rename to drivers/gpu/drm/dri1/drm_scatter.c
diff --git a/drivers/gpu/drm/drm_vm.c b/drivers/gpu/drm/dri1/drm_vm.c
similarity index 100%
rename from drivers/gpu/drm/drm_vm.c
rename to drivers/gpu/drm/dri1/drm_vm.c
-- 
2.34.1

[PATCH v1 06/11] drm/mga: Move the mga driver to drm/dri1/

drm/dri1 is the new home for all the legacy DRI1 drivers.

Signed-off-by: Sam Ravnborg 
Suggested-by: Javier Martinez Canillas 
---
 drivers/gpu/drm/Makefile   | 1 -
 drivers/gpu/drm/dri1/Makefile  | 1 +
 drivers/gpu/drm/{ => dri1}/mga/Makefile| 0
 drivers/gpu/drm/{ => dri1}/mga/mga_dma.c   | 0
 drivers/gpu/drm/{ => dri1}/mga/mga_drv.c   | 0
 drivers/gpu/drm/{ => dri1}/mga/mga_drv.h   | 0
 drivers/gpu/drm/{ => dri1}/mga/mga_ioc32.c | 0
 drivers/gpu/drm/{ => dri1}/mga/mga_irq.c   | 0
 drivers/gpu/drm/{ => dri1}/mga/mga_state.c | 0
 drivers/gpu/drm/{ => dri1}/mga/mga_warp.c  | 0
 10 files changed, 1 insertion(+), 1 deletion(-)
 rename drivers/gpu/drm/{ => dri1}/mga/Makefile (100%)
 rename drivers/gpu/drm/{ => dri1}/mga/mga_dma.c (100%)
 rename drivers/gpu/drm/{ => dri1}/mga/mga_drv.c (100%)
 rename drivers/gpu/drm/{ => dri1}/mga/mga_drv.h (100%)
 rename drivers/gpu/drm/{ => dri1}/mga/mga_ioc32.c (100%)
 rename drivers/gpu/drm/{ => dri1}/mga/mga_irq.c (100%)
 rename drivers/gpu/drm/{ => dri1}/mga/mga_state.c (100%)
 rename drivers/gpu/drm/{ => dri1}/mga/mga_warp.c (100%)

diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 9a664a4a021d..363cecfff919 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -86,7 +86,6 @@ obj-$(CONFIG_DRM_SCHED)   += scheduler/
 obj-$(CONFIG_DRM_DRI1) += dri1/
 obj-$(CONFIG_DRM_RADEON)+= radeon/
 obj-$(CONFIG_DRM_AMDGPU)+= amd/amdgpu/
-obj-$(CONFIG_DRM_MGA)  += mga/
 obj-$(CONFIG_DRM_I915) += i915/
 obj-$(CONFIG_DRM_KMB_DISPLAY)  += kmb/
 obj-$(CONFIG_DRM_MGAG200) += mgag200/
diff --git a/drivers/gpu/drm/dri1/Makefile b/drivers/gpu/drm/dri1/Makefile
index d16bfdf26888..c254e443aa3a 100644
--- a/drivers/gpu/drm/dri1/Makefile
+++ b/drivers/gpu/drm/dri1/Makefile
@@ -3,5 +3,6 @@
 # Makefile for DRI1 drm device drivers
 
 obj-$(CONFIG_DRM_I810) += i810/
+obj-$(CONFIG_DRM_MGA)  += mga/
 obj-$(CONFIG_DRM_R128) += r128/
 obj-$(CONFIG_DRM_TDFX) += tdfx/
diff --git a/drivers/gpu/drm/mga/Makefile b/drivers/gpu/drm/dri1/mga/Makefile
similarity index 100%
rename from drivers/gpu/drm/mga/Makefile
rename to drivers/gpu/drm/dri1/mga/Makefile
diff --git a/drivers/gpu/drm/mga/mga_dma.c b/drivers/gpu/drm/dri1/mga/mga_dma.c
similarity index 100%
rename from drivers/gpu/drm/mga/mga_dma.c
rename to drivers/gpu/drm/dri1/mga/mga_dma.c
diff --git a/drivers/gpu/drm/mga/mga_drv.c b/drivers/gpu/drm/dri1/mga/mga_drv.c
similarity index 100%
rename from drivers/gpu/drm/mga/mga_drv.c
rename to drivers/gpu/drm/dri1/mga/mga_drv.c
diff --git a/drivers/gpu/drm/mga/mga_drv.h b/drivers/gpu/drm/dri1/mga/mga_drv.h
similarity index 100%
rename from drivers/gpu/drm/mga/mga_drv.h
rename to drivers/gpu/drm/dri1/mga/mga_drv.h
diff --git a/drivers/gpu/drm/mga/mga_ioc32.c 
b/drivers/gpu/drm/dri1/mga/mga_ioc32.c
similarity index 100%
rename from drivers/gpu/drm/mga/mga_ioc32.c
rename to drivers/gpu/drm/dri1/mga/mga_ioc32.c
diff --git a/drivers/gpu/drm/mga/mga_irq.c b/drivers/gpu/drm/dri1/mga/mga_irq.c
similarity index 100%
rename from drivers/gpu/drm/mga/mga_irq.c
rename to drivers/gpu/drm/dri1/mga/mga_irq.c
diff --git a/drivers/gpu/drm/mga/mga_state.c 
b/drivers/gpu/drm/dri1/mga/mga_state.c
similarity index 100%
rename from drivers/gpu/drm/mga/mga_state.c
rename to drivers/gpu/drm/dri1/mga/mga_state.c
diff --git a/drivers/gpu/drm/mga/mga_warp.c 
b/drivers/gpu/drm/dri1/mga/mga_warp.c
similarity index 100%
rename from drivers/gpu/drm/mga/mga_warp.c
rename to drivers/gpu/drm/dri1/mga/mga_warp.c
-- 
2.34.1

[PATCH v1 10/11] drm/dri1: Move Kconfig logic to drm/dri1

Move the DRI1 section from drm/Kconfig to a new Kconfig
file that lives in the dri1/ directory.
This isolates more of the DRI1 functionality.

Signed-off-by: Sam Ravnborg 
---
 drivers/gpu/drm/Kconfig  | 77 +--
 drivers/gpu/drm/dri1/Kconfig | 79 
 2 files changed, 80 insertions(+), 76 deletions(-)
 create mode 100644 drivers/gpu/drm/dri1/Kconfig

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 024081480fcf..fd2684c7481f 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -403,82 +403,7 @@ config DRM_HYPERV
 If M is selected the module will be called hyperv_drm.
 
 # Keep legacy DRI1 drivers last
-
-menuconfig DRM_DRI1
-   bool "Enable legacy DRI1 drivers (DANGEROUS)"
-   depends on DRM && MMU
-   help
- Enable legacy DRI1 drivers. Those drivers expose unsafe and dangerous
- APIs to user-space, which can be used to circumvent access
- restrictions and other security measures. For backwards compatibility
- those drivers are still available, but their use is highly
- inadvisable and might harm your system.
-
- You are recommended to use the safe modeset-only drivers instead, and
- perform 3D emulation in user-space.
-
- Unless you have strong reasons to go rogue, say "N".
-
-if DRM_DRI1
-
-config DRM_TDFX
-   tristate "3dfx Banshee/Voodoo3+"
-   depends on DRM && PCI
-   help
- Choose this option if you have a 3dfx Banshee or Voodoo3 (or later),
- graphics card.  If M is selected, the module will be called tdfx.
-
-config DRM_R128
-   tristate "ATI Rage 128"
-   depends on DRM && PCI
-   select FW_LOADER
-   help
- Choose this option if you have an ATI Rage 128 graphics card.  If M
- is selected, the module will be called r128.  AGP support for
- this card is strongly suggested (unless you have a PCI version).
-
-config DRM_I810
-   tristate "Intel I810"
-   # !PREEMPTION because of missing ioctl locking
-   depends on DRM && AGP && AGP_INTEL && (!PREEMPTION || BROKEN)
-   help
- Choose this option if you have an Intel I810 graphics card.  If M is
- selected, the module will be called i810.  AGP support is required
- for this driver to work.
-
-config DRM_MGA
-   tristate "Matrox g200/g400"
-   depends on DRM && PCI
-   select FW_LOADER
-   help
- Choose this option if you have a Matrox G200, G400 or G450 graphics
- card.  If M is selected, the module will be called mga.  AGP
- support is required for this driver to work.
-
-config DRM_SIS
-   tristate "SiS video cards"
-   depends on DRM && AGP
-   depends on FB_SIS || FB_SIS=n
-   help
- Choose this option if you have a SiS 630 or compatible video
- chipset. If M is selected the module will be called sis. AGP
- support is required for this driver to work.
-
-config DRM_VIA
-   tristate "Via unichrome video cards"
-   depends on DRM && PCI
-   help
- Choose this option if you have a Via unichrome or compatible video
- chipset. If M is selected the module will be called via.
-
-config DRM_SAVAGE
-   tristate "Savage video cards"
-   depends on DRM && PCI
-   help
- Choose this option if you have a Savage3D/4/SuperSavage/Pro/Twister
- chipset. If M is selected the module will be called savage.
-
-endif # DRM_DRI1
+source "drivers/gpu/drm/dri1/Kconfig"
 
 config DRM_EXPORT_FOR_TESTS
bool
diff --git a/drivers/gpu/drm/dri1/Kconfig b/drivers/gpu/drm/dri1/Kconfig
new file mode 100644
index ..424b9a142aa2
--- /dev/null
+++ b/drivers/gpu/drm/dri1/Kconfig
@@ -0,0 +1,79 @@
+# SPDX-License-Identifier: GPL-2.0-only
+#
+# DRI1 drm device drivers
+
+menuconfig DRM_DRI1
+   bool "Enable legacy DRI1 drivers (DANGEROUS)"
+   depends on DRM && MMU
+   help
+ Enable legacy DRI1 drivers. Those drivers expose unsafe and dangerous
+ APIs to user-space, which can be used to circumvent access
+ restrictions and other security measures. For backwards compatibility
+ those drivers are still available, but their use is highly
+ inadvisable and might harm your system.
+
+ You are recommended to use the safe modeset-only drivers instead, and
+ perform 3D emulation in user-space.
+
+ Unless you have strong reasons to go rogue, say "N".
+
+if DRM_DRI1
+
+config DRM_TDFX
+   tristate "3dfx Banshee/Voodoo3+"
+   depends on DRM && PCI
+   help
+ Choose this option if you have a 3dfx Banshee or Voodoo3 (or later),
+ graphics card.  If M is selected, the module will be called tdfx.
+
+config DRM_R128
+   tristate "ATI Rage 128"
+   depends on DRM && PCI
+   select FW_LOADER
+   help
+ Choose this option if you have an

[PATCH v1 09/11] drm/savage: Move the savage driver to drm/dri1/

drm/dri1 is the new home for all the legacy DRI1 drivers.

Signed-off-by: Sam Ravnborg 
Suggested-by: Javier Martinez Canillas 
---
 drivers/gpu/drm/Makefile | 1 -
 drivers/gpu/drm/dri1/Makefile| 1 +
 drivers/gpu/drm/{ => dri1}/savage/Makefile   | 0
 drivers/gpu/drm/{ => dri1}/savage/savage_bci.c   | 0
 drivers/gpu/drm/{ => dri1}/savage/savage_drv.c   | 0
 drivers/gpu/drm/{ => dri1}/savage/savage_drv.h   | 0
 drivers/gpu/drm/{ => dri1}/savage/savage_state.c | 0
 7 files changed, 1 insertion(+), 1 deletion(-)
 rename drivers/gpu/drm/{ => dri1}/savage/Makefile (100%)
 rename drivers/gpu/drm/{ => dri1}/savage/savage_bci.c (100%)
 rename drivers/gpu/drm/{ => dri1}/savage/savage_drv.c (100%)
 rename drivers/gpu/drm/{ => dri1}/savage/savage_drv.h (100%)
 rename drivers/gpu/drm/{ => dri1}/savage/savage_state.c (100%)

diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index bb3d8ffb9dd6..a3bd337bcab4 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -91,7 +91,6 @@ obj-$(CONFIG_DRM_KMB_DISPLAY)  += kmb/
 obj-$(CONFIG_DRM_MGAG200) += mgag200/
 obj-$(CONFIG_DRM_V3D)  += v3d/
 obj-$(CONFIG_DRM_VC4)  += vc4/
-obj-$(CONFIG_DRM_SAVAGE)+= savage/
 obj-$(CONFIG_DRM_VMWGFX)+= vmwgfx/
 obj-$(CONFIG_DRM_VGEM) += vgem/
 obj-$(CONFIG_DRM_VKMS) += vkms/
diff --git a/drivers/gpu/drm/dri1/Makefile b/drivers/gpu/drm/dri1/Makefile
index 73c0aa1c7b94..f639d5e0ae2e 100644
--- a/drivers/gpu/drm/dri1/Makefile
+++ b/drivers/gpu/drm/dri1/Makefile
@@ -5,6 +5,7 @@
 obj-$(CONFIG_DRM_I810) += i810/
 obj-$(CONFIG_DRM_MGA)  += mga/
 obj-$(CONFIG_DRM_R128) += r128/
+obj-$(CONFIG_DRM_SAVAGE)   += savage/
 obj-$(CONFIG_DRM_SIS)  += sis/
 obj-$(CONFIG_DRM_TDFX) += tdfx/
 obj-$(CONFIG_DRM_VIA)  += via/
diff --git a/drivers/gpu/drm/savage/Makefile 
b/drivers/gpu/drm/dri1/savage/Makefile
similarity index 100%
rename from drivers/gpu/drm/savage/Makefile
rename to drivers/gpu/drm/dri1/savage/Makefile
diff --git a/drivers/gpu/drm/savage/savage_bci.c 
b/drivers/gpu/drm/dri1/savage/savage_bci.c
similarity index 100%
rename from drivers/gpu/drm/savage/savage_bci.c
rename to drivers/gpu/drm/dri1/savage/savage_bci.c
diff --git a/drivers/gpu/drm/savage/savage_drv.c 
b/drivers/gpu/drm/dri1/savage/savage_drv.c
similarity index 100%
rename from drivers/gpu/drm/savage/savage_drv.c
rename to drivers/gpu/drm/dri1/savage/savage_drv.c
diff --git a/drivers/gpu/drm/savage/savage_drv.h 
b/drivers/gpu/drm/dri1/savage/savage_drv.h
similarity index 100%
rename from drivers/gpu/drm/savage/savage_drv.h
rename to drivers/gpu/drm/dri1/savage/savage_drv.h
diff --git a/drivers/gpu/drm/savage/savage_state.c 
b/drivers/gpu/drm/dri1/savage/savage_state.c
similarity index 100%
rename from drivers/gpu/drm/savage/savage_state.c
rename to drivers/gpu/drm/dri1/savage/savage_state.c
-- 
2.34.1

[PATCH v1 03/11] drm/tdfx: Move the tdfx driver to drm/dri1/

drm/dri1 is the new home for all the legacy DRI1 drivers.

Signed-off-by: Sam Ravnborg 
Suggested-by: Javier Martinez Canillas 
---
 drivers/gpu/drm/Makefile   | 2 +-
 drivers/gpu/drm/dri1/Makefile  | 5 +
 drivers/gpu/drm/{ => dri1}/tdfx/Makefile   | 0
 drivers/gpu/drm/{ => dri1}/tdfx/tdfx_drv.c | 0
 drivers/gpu/drm/{ => dri1}/tdfx/tdfx_drv.h | 0
 5 files changed, 6 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/dri1/Makefile
 rename drivers/gpu/drm/{ => dri1}/tdfx/Makefile (100%)
 rename drivers/gpu/drm/{ => dri1}/tdfx/tdfx_drv.c (100%)
 rename drivers/gpu/drm/{ => dri1}/tdfx/tdfx_drv.h (100%)

diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index dd7f296ef9b8..08a65237ce4e 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -83,7 +83,7 @@ obj-y += arm/
 obj-y  += display/
 obj-$(CONFIG_DRM_TTM)  += ttm/
 obj-$(CONFIG_DRM_SCHED)+= scheduler/
-obj-$(CONFIG_DRM_TDFX) += tdfx/
+obj-$(CONFIG_DRM_DRI1) += dri1/
 obj-$(CONFIG_DRM_R128) += r128/
 obj-$(CONFIG_DRM_RADEON)+= radeon/
 obj-$(CONFIG_DRM_AMDGPU)+= amd/amdgpu/
diff --git a/drivers/gpu/drm/dri1/Makefile b/drivers/gpu/drm/dri1/Makefile
new file mode 100644
index ..a3525b545670
--- /dev/null
+++ b/drivers/gpu/drm/dri1/Makefile
@@ -0,0 +1,5 @@
+# SPDX-License-Identifier: GPL-2.0
+#
+# Makefile for DRI1 drm device drivers
+
+obj-$(CONFIG_DRM_TDFX) += tdfx/
diff --git a/drivers/gpu/drm/tdfx/Makefile b/drivers/gpu/drm/dri1/tdfx/Makefile
similarity index 100%
rename from drivers/gpu/drm/tdfx/Makefile
rename to drivers/gpu/drm/dri1/tdfx/Makefile
diff --git a/drivers/gpu/drm/tdfx/tdfx_drv.c 
b/drivers/gpu/drm/dri1/tdfx/tdfx_drv.c
similarity index 100%
rename from drivers/gpu/drm/tdfx/tdfx_drv.c
rename to drivers/gpu/drm/dri1/tdfx/tdfx_drv.c
diff --git a/drivers/gpu/drm/tdfx/tdfx_drv.h 
b/drivers/gpu/drm/dri1/tdfx/tdfx_drv.h
similarity index 100%
rename from drivers/gpu/drm/tdfx/tdfx_drv.h
rename to drivers/gpu/drm/dri1/tdfx/tdfx_drv.h
-- 
2.34.1

[PATCH v1 05/11] drm/i810: Move the i810 driver to drm/dri1/

drm/dri1 is the new home for all the legacy DRI1 drivers.

Signed-off-by: Sam Ravnborg 
Suggested-by: Javier Martinez Canillas 
---
 drivers/gpu/drm/Makefile   | 1 -
 drivers/gpu/drm/dri1/Makefile  | 1 +
 drivers/gpu/drm/{ => dri1}/i810/Makefile   | 0
 drivers/gpu/drm/{ => dri1}/i810/i810_dma.c | 0
 drivers/gpu/drm/{ => dri1}/i810/i810_drv.c | 0
 drivers/gpu/drm/{ => dri1}/i810/i810_drv.h | 0
 6 files changed, 1 insertion(+), 1 deletion(-)
 rename drivers/gpu/drm/{ => dri1}/i810/Makefile (100%)
 rename drivers/gpu/drm/{ => dri1}/i810/i810_dma.c (100%)
 rename drivers/gpu/drm/{ => dri1}/i810/i810_drv.c (100%)
 rename drivers/gpu/drm/{ => dri1}/i810/i810_drv.h (100%)

diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 0b6b33e64261..9a664a4a021d 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -87,7 +87,6 @@ obj-$(CONFIG_DRM_DRI1)+= dri1/
 obj-$(CONFIG_DRM_RADEON)+= radeon/
 obj-$(CONFIG_DRM_AMDGPU)+= amd/amdgpu/
 obj-$(CONFIG_DRM_MGA)  += mga/
-obj-$(CONFIG_DRM_I810) += i810/
 obj-$(CONFIG_DRM_I915) += i915/
 obj-$(CONFIG_DRM_KMB_DISPLAY)  += kmb/
 obj-$(CONFIG_DRM_MGAG200) += mgag200/
diff --git a/drivers/gpu/drm/dri1/Makefile b/drivers/gpu/drm/dri1/Makefile
index f243aac48bb9..d16bfdf26888 100644
--- a/drivers/gpu/drm/dri1/Makefile
+++ b/drivers/gpu/drm/dri1/Makefile
@@ -2,5 +2,6 @@
 #
 # Makefile for DRI1 drm device drivers
 
+obj-$(CONFIG_DRM_I810) += i810/
 obj-$(CONFIG_DRM_R128) += r128/
 obj-$(CONFIG_DRM_TDFX) += tdfx/
diff --git a/drivers/gpu/drm/i810/Makefile b/drivers/gpu/drm/dri1/i810/Makefile
similarity index 100%
rename from drivers/gpu/drm/i810/Makefile
rename to drivers/gpu/drm/dri1/i810/Makefile
diff --git a/drivers/gpu/drm/i810/i810_dma.c 
b/drivers/gpu/drm/dri1/i810/i810_dma.c
similarity index 100%
rename from drivers/gpu/drm/i810/i810_dma.c
rename to drivers/gpu/drm/dri1/i810/i810_dma.c
diff --git a/drivers/gpu/drm/i810/i810_drv.c 
b/drivers/gpu/drm/dri1/i810/i810_drv.c
similarity index 100%
rename from drivers/gpu/drm/i810/i810_drv.c
rename to drivers/gpu/drm/dri1/i810/i810_drv.c
diff --git a/drivers/gpu/drm/i810/i810_drv.h 
b/drivers/gpu/drm/dri1/i810/i810_drv.h
similarity index 100%
rename from drivers/gpu/drm/i810/i810_drv.h
rename to drivers/gpu/drm/dri1/i810/i810_drv.h
-- 
2.34.1

[PATCH v1 07/11] drm/sis: Move the sis driver to drm/dri1/

drm/dri1 is the new home for all the legacy DRI1 drivers.

Signed-off-by: Sam Ravnborg 
Suggested-by: Javier Martinez Canillas 
---
 drivers/gpu/drm/Makefile | 1 -
 drivers/gpu/drm/dri1/Makefile| 1 +
 drivers/gpu/drm/{ => dri1}/sis/Makefile  | 0
 drivers/gpu/drm/{ => dri1}/sis/sis_drv.c | 0
 drivers/gpu/drm/{ => dri1}/sis/sis_drv.h | 0
 drivers/gpu/drm/{ => dri1}/sis/sis_mm.c  | 0
 6 files changed, 1 insertion(+), 1 deletion(-)
 rename drivers/gpu/drm/{ => dri1}/sis/Makefile (100%)
 rename drivers/gpu/drm/{ => dri1}/sis/sis_drv.c (100%)
 rename drivers/gpu/drm/{ => dri1}/sis/sis_drv.h (100%)
 rename drivers/gpu/drm/{ => dri1}/sis/sis_mm.c (100%)

diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 363cecfff919..7de784da6345 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -91,7 +91,6 @@ obj-$(CONFIG_DRM_KMB_DISPLAY)  += kmb/
 obj-$(CONFIG_DRM_MGAG200) += mgag200/
 obj-$(CONFIG_DRM_V3D)  += v3d/
 obj-$(CONFIG_DRM_VC4)  += vc4/
-obj-$(CONFIG_DRM_SIS)   += sis/
 obj-$(CONFIG_DRM_SAVAGE)+= savage/
 obj-$(CONFIG_DRM_VMWGFX)+= vmwgfx/
 obj-$(CONFIG_DRM_VIA)  +=via/
diff --git a/drivers/gpu/drm/dri1/Makefile b/drivers/gpu/drm/dri1/Makefile
index c254e443aa3a..23e33398fdf5 100644
--- a/drivers/gpu/drm/dri1/Makefile
+++ b/drivers/gpu/drm/dri1/Makefile
@@ -5,4 +5,5 @@
 obj-$(CONFIG_DRM_I810) += i810/
 obj-$(CONFIG_DRM_MGA)  += mga/
 obj-$(CONFIG_DRM_R128) += r128/
+obj-$(CONFIG_DRM_SIS)  += sis/
 obj-$(CONFIG_DRM_TDFX) += tdfx/
diff --git a/drivers/gpu/drm/sis/Makefile b/drivers/gpu/drm/dri1/sis/Makefile
similarity index 100%
rename from drivers/gpu/drm/sis/Makefile
rename to drivers/gpu/drm/dri1/sis/Makefile
diff --git a/drivers/gpu/drm/sis/sis_drv.c b/drivers/gpu/drm/dri1/sis/sis_drv.c
similarity index 100%
rename from drivers/gpu/drm/sis/sis_drv.c
rename to drivers/gpu/drm/dri1/sis/sis_drv.c
diff --git a/drivers/gpu/drm/sis/sis_drv.h b/drivers/gpu/drm/dri1/sis/sis_drv.h
similarity index 100%
rename from drivers/gpu/drm/sis/sis_drv.h
rename to drivers/gpu/drm/dri1/sis/sis_drv.h
diff --git a/drivers/gpu/drm/sis/sis_mm.c b/drivers/gpu/drm/dri1/sis/sis_mm.c
similarity index 100%
rename from drivers/gpu/drm/sis/sis_mm.c
rename to drivers/gpu/drm/dri1/sis/sis_mm.c
-- 
2.34.1

[PATCH v1 08/11] drm/via: Move the via driver to drm/dri1/

drm/dri1 is the new home for all the legacy DRI1 drivers.
Used the opportunity to rename the file to via.c to match the
name of the driver.

Signed-off-by: Sam Ravnborg 
Suggested-by: Javier Martinez Canillas 
---
 drivers/gpu/drm/Makefile   | 1 -
 drivers/gpu/drm/dri1/Makefile  | 1 +
 drivers/gpu/drm/{ => dri1}/via/Makefile| 4 +---
 drivers/gpu/drm/{via/via_dri1.c => dri1/via/via.c} | 2 +-
 4 files changed, 3 insertions(+), 5 deletions(-)
 rename drivers/gpu/drm/{ => dri1}/via/Makefile (77%)
 rename drivers/gpu/drm/{via/via_dri1.c => dri1/via/via.c} (99%)

diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 7de784da6345..bb3d8ffb9dd6 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -93,7 +93,6 @@ obj-$(CONFIG_DRM_V3D)  += v3d/
 obj-$(CONFIG_DRM_VC4)  += vc4/
 obj-$(CONFIG_DRM_SAVAGE)+= savage/
 obj-$(CONFIG_DRM_VMWGFX)+= vmwgfx/
-obj-$(CONFIG_DRM_VIA)  +=via/
 obj-$(CONFIG_DRM_VGEM) += vgem/
 obj-$(CONFIG_DRM_VKMS) += vkms/
 obj-$(CONFIG_DRM_NOUVEAU) +=nouveau/
diff --git a/drivers/gpu/drm/dri1/Makefile b/drivers/gpu/drm/dri1/Makefile
index 23e33398fdf5..73c0aa1c7b94 100644
--- a/drivers/gpu/drm/dri1/Makefile
+++ b/drivers/gpu/drm/dri1/Makefile
@@ -7,3 +7,4 @@ obj-$(CONFIG_DRM_MGA)   += mga/
 obj-$(CONFIG_DRM_R128) += r128/
 obj-$(CONFIG_DRM_SIS)  += sis/
 obj-$(CONFIG_DRM_TDFX) += tdfx/
+obj-$(CONFIG_DRM_VIA)  += via/
diff --git a/drivers/gpu/drm/via/Makefile b/drivers/gpu/drm/dri1/via/Makefile
similarity index 77%
rename from drivers/gpu/drm/via/Makefile
rename to drivers/gpu/drm/dri1/via/Makefile
index 8b978dd51a25..b7cd59c2e226 100644
--- a/drivers/gpu/drm/via/Makefile
+++ b/drivers/gpu/drm/dri1/via/Makefile
@@ -3,6 +3,4 @@
 # Makefile for the drm device driver.  This driver provides support for the
 # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
 
-via-y:= via_dri1.o
-
-obj-$(CONFIG_DRM_VIA)  +=via.o
+obj-$(CONFIG_DRM_VIA)  += via.o
diff --git a/drivers/gpu/drm/via/via_dri1.c b/drivers/gpu/drm/dri1/via/via.c
similarity index 99%
rename from drivers/gpu/drm/via/via_dri1.c
rename to drivers/gpu/drm/dri1/via/via.c
index c5708a3f4530..24bc3ebe66e1 100644
--- a/drivers/gpu/drm/via/via_dri1.c
+++ b/drivers/gpu/drm/dri1/via/via.c
@@ -44,7 +44,7 @@
 #include 
 #include 
 
-#include "via_3d_reg.h"
+#include "../../via/via_3d_reg.h"
 
 #define DRIVER_AUTHOR  "Various"
 
-- 
2.34.1

[PATCH v1 02/11] drm: Rename CONFIG_DRM_LEGACY to CONFIG_DRM_DRI1

The rename is done to make it more obvious what is DRI1 drivers
and what is other type of legacy.

Signed-off-by: Sam Ravnborg 
---
 arch/powerpc/configs/pmac32_defconfig |  2 +-
 arch/powerpc/configs/ppc6xx_defconfig |  2 +-
 drivers/char/agp/Makefile |  2 +-
 drivers/char/agp/agp.h|  2 +-
 drivers/gpu/drm/Kconfig   | 10 -
 drivers/gpu/drm/Makefile  |  6 ++---
 drivers/gpu/drm/drm_file.c|  4 ++--
 drivers/gpu/drm/drm_internal.h|  2 +-
 drivers/gpu/drm/drm_ioc32.c   | 12 +-
 drivers/gpu/drm/drm_ioctl.c   |  2 +-
 drivers/gpu/drm/drm_legacy.h  | 32 +--
 drivers/gpu/drm/drm_pci.c |  4 ++--
 drivers/gpu/drm/drm_vblank.c  |  8 +++
 drivers/gpu/drm/drm_vm.c  |  2 +-
 include/drm/drm_auth.h|  2 +-
 include/drm/drm_device.h  |  2 +-
 include/drm/drm_drv.h |  4 ++--
 include/drm/drm_file.h|  2 +-
 include/drm/drm_legacy.h  |  2 +-
 19 files changed, 51 insertions(+), 51 deletions(-)

diff --git a/arch/powerpc/configs/pmac32_defconfig 
b/arch/powerpc/configs/pmac32_defconfig
index 13885ec563d1..47bb0e8018e4 100644
--- a/arch/powerpc/configs/pmac32_defconfig
+++ b/arch/powerpc/configs/pmac32_defconfig
@@ -187,7 +187,7 @@ CONFIG_AGP=m
 CONFIG_AGP_UNINORTH=m
 CONFIG_DRM=m
 CONFIG_DRM_RADEON=m
-CONFIG_DRM_LEGACY=y
+CONFIG_DRM_DRI1=y
 CONFIG_DRM_R128=m
 CONFIG_FB=y
 CONFIG_FB_OF=y
diff --git a/arch/powerpc/configs/ppc6xx_defconfig 
b/arch/powerpc/configs/ppc6xx_defconfig
index b622ecd73286..5616b669e6ab 100644
--- a/arch/powerpc/configs/ppc6xx_defconfig
+++ b/arch/powerpc/configs/ppc6xx_defconfig
@@ -694,7 +694,7 @@ CONFIG_AGP=y
 CONFIG_AGP_UNINORTH=y
 CONFIG_DRM=m
 CONFIG_DRM_RADEON=m
-CONFIG_DRM_LEGACY=y
+CONFIG_DRM_DRI1=y
 CONFIG_DRM_TDFX=m
 CONFIG_DRM_R128=m
 CONFIG_DRM_MGA=m
diff --git a/drivers/char/agp/Makefile b/drivers/char/agp/Makefile
index 90ed8c789e48..360e8e9dde98 100644
--- a/drivers/char/agp/Makefile
+++ b/drivers/char/agp/Makefile
@@ -1,7 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0
 agpgart-y := backend.o generic.o isoch.o
 
-ifeq ($(CONFIG_DRM_LEGACY),y)
+ifeq ($(CONFIG_DRM_DRI1),y)
 agpgart-$(CONFIG_COMPAT)   += compat_ioctl.o
 agpgart-y  += frontend.o
 endif
diff --git a/drivers/char/agp/agp.h b/drivers/char/agp/agp.h
index bb09d64cd51e..97802b076d80 100644
--- a/drivers/char/agp/agp.h
+++ b/drivers/char/agp/agp.h
@@ -186,7 +186,7 @@ int agp_add_bridge(struct agp_bridge_data *bridge);
 void agp_remove_bridge(struct agp_bridge_data *bridge);
 
 /* Frontend routines. */
-#if IS_ENABLED(CONFIG_DRM_LEGACY)
+#if IS_ENABLED(CONFIG_DRM_DRI1)
 int agp_frontend_initialize(void);
 void agp_frontend_cleanup(void);
 #else
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 1c91e1e861a5..024081480fcf 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -402,10 +402,10 @@ config DRM_HYPERV
 
 If M is selected the module will be called hyperv_drm.
 
-# Keep legacy drivers last
+# Keep legacy DRI1 drivers last
 
-menuconfig DRM_LEGACY
-   bool "Enable legacy drivers (DANGEROUS)"
+menuconfig DRM_DRI1
+   bool "Enable legacy DRI1 drivers (DANGEROUS)"
depends on DRM && MMU
help
  Enable legacy DRI1 drivers. Those drivers expose unsafe and dangerous
@@ -419,7 +419,7 @@ menuconfig DRM_LEGACY
 
  Unless you have strong reasons to go rogue, say "N".
 
-if DRM_LEGACY
+if DRM_DRI1
 
 config DRM_TDFX
tristate "3dfx Banshee/Voodoo3+"
@@ -478,7 +478,7 @@ config DRM_SAVAGE
  Choose this option if you have a Savage3D/4/SuperSavage/Pro/Twister
  chipset. If M is selected the module will be called savage.
 
-endif # DRM_LEGACY
+endif # DRM_DRI1
 
 config DRM_EXPORT_FOR_TESTS
bool
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 25016dcab55e..dd7f296ef9b8 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -18,9 +18,9 @@ drm-y   :=drm_aperture.o drm_auth.o drm_cache.o \
drm_syncobj.o drm_lease.o drm_writeback.o drm_client.o \
drm_client_modeset.o drm_atomic_uapi.o \
drm_managed.o drm_vblank_work.o
-drm-$(CONFIG_DRM_LEGACY) += drm_agpsupport.o drm_bufs.o drm_context.o 
drm_dma.o \
-   drm_hashtab.o drm_irq.o drm_legacy_misc.o 
drm_lock.o \
-   drm_memory.o drm_scatter.o drm_vm.o
+drm-$(CONFIG_DRM_DRI1) += drm_agpsupport.o drm_bufs.o drm_context.o drm_dma.o \
+ drm_hashtab.o drm_irq.o drm_legacy_misc.o drm_lock.o \
+ drm_memory.o drm_scatter.o drm_vm.o
 drm-$(CONFIG_DRM_LIB_RANDOM) += lib/drm_random.o
 drm-$(CONFIG_COMPAT) += drm_ioc32.o
 drm-$(CONFIG_DRM_PANEL) += drm_panel.o
diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index

[PATCH v1 04/11] drm/r128: Move the r128 driver to drm/dri1/

drm/dri1 is the new home for all the legacy DRI1 drivers.

Signed-off-by: Sam Ravnborg 
Suggested-by: Javier Martinez Canillas 
---
 drivers/gpu/drm/Makefile  | 1 -
 drivers/gpu/drm/dri1/Makefile | 1 +
 drivers/gpu/drm/{ => dri1}/r128/Makefile  | 0
 drivers/gpu/drm/{ => dri1}/r128/ati_pcigart.c | 0
 drivers/gpu/drm/{ => dri1}/r128/ati_pcigart.h | 0
 drivers/gpu/drm/{ => dri1}/r128/r128_cce.c| 0
 drivers/gpu/drm/{ => dri1}/r128/r128_drv.c| 0
 drivers/gpu/drm/{ => dri1}/r128/r128_drv.h| 0
 drivers/gpu/drm/{ => dri1}/r128/r128_ioc32.c  | 0
 drivers/gpu/drm/{ => dri1}/r128/r128_irq.c| 0
 drivers/gpu/drm/{ => dri1}/r128/r128_state.c  | 0
 11 files changed, 1 insertion(+), 1 deletion(-)
 rename drivers/gpu/drm/{ => dri1}/r128/Makefile (100%)
 rename drivers/gpu/drm/{ => dri1}/r128/ati_pcigart.c (100%)
 rename drivers/gpu/drm/{ => dri1}/r128/ati_pcigart.h (100%)
 rename drivers/gpu/drm/{ => dri1}/r128/r128_cce.c (100%)
 rename drivers/gpu/drm/{ => dri1}/r128/r128_drv.c (100%)
 rename drivers/gpu/drm/{ => dri1}/r128/r128_drv.h (100%)
 rename drivers/gpu/drm/{ => dri1}/r128/r128_ioc32.c (100%)
 rename drivers/gpu/drm/{ => dri1}/r128/r128_irq.c (100%)
 rename drivers/gpu/drm/{ => dri1}/r128/r128_state.c (100%)

diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 08a65237ce4e..0b6b33e64261 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -84,7 +84,6 @@ obj-y += display/
 obj-$(CONFIG_DRM_TTM)  += ttm/
 obj-$(CONFIG_DRM_SCHED)+= scheduler/
 obj-$(CONFIG_DRM_DRI1) += dri1/
-obj-$(CONFIG_DRM_R128) += r128/
 obj-$(CONFIG_DRM_RADEON)+= radeon/
 obj-$(CONFIG_DRM_AMDGPU)+= amd/amdgpu/
 obj-$(CONFIG_DRM_MGA)  += mga/
diff --git a/drivers/gpu/drm/dri1/Makefile b/drivers/gpu/drm/dri1/Makefile
index a3525b545670..f243aac48bb9 100644
--- a/drivers/gpu/drm/dri1/Makefile
+++ b/drivers/gpu/drm/dri1/Makefile
@@ -2,4 +2,5 @@
 #
 # Makefile for DRI1 drm device drivers
 
+obj-$(CONFIG_DRM_R128) += r128/
 obj-$(CONFIG_DRM_TDFX) += tdfx/
diff --git a/drivers/gpu/drm/r128/Makefile b/drivers/gpu/drm/dri1/r128/Makefile
similarity index 100%
rename from drivers/gpu/drm/r128/Makefile
rename to drivers/gpu/drm/dri1/r128/Makefile
diff --git a/drivers/gpu/drm/r128/ati_pcigart.c 
b/drivers/gpu/drm/dri1/r128/ati_pcigart.c
similarity index 100%
rename from drivers/gpu/drm/r128/ati_pcigart.c
rename to drivers/gpu/drm/dri1/r128/ati_pcigart.c
diff --git a/drivers/gpu/drm/r128/ati_pcigart.h 
b/drivers/gpu/drm/dri1/r128/ati_pcigart.h
similarity index 100%
rename from drivers/gpu/drm/r128/ati_pcigart.h
rename to drivers/gpu/drm/dri1/r128/ati_pcigart.h
diff --git a/drivers/gpu/drm/r128/r128_cce.c 
b/drivers/gpu/drm/dri1/r128/r128_cce.c
similarity index 100%
rename from drivers/gpu/drm/r128/r128_cce.c
rename to drivers/gpu/drm/dri1/r128/r128_cce.c
diff --git a/drivers/gpu/drm/r128/r128_drv.c 
b/drivers/gpu/drm/dri1/r128/r128_drv.c
similarity index 100%
rename from drivers/gpu/drm/r128/r128_drv.c
rename to drivers/gpu/drm/dri1/r128/r128_drv.c
diff --git a/drivers/gpu/drm/r128/r128_drv.h 
b/drivers/gpu/drm/dri1/r128/r128_drv.h
similarity index 100%
rename from drivers/gpu/drm/r128/r128_drv.h
rename to drivers/gpu/drm/dri1/r128/r128_drv.h
diff --git a/drivers/gpu/drm/r128/r128_ioc32.c 
b/drivers/gpu/drm/dri1/r128/r128_ioc32.c
similarity index 100%
rename from drivers/gpu/drm/r128/r128_ioc32.c
rename to drivers/gpu/drm/dri1/r128/r128_ioc32.c
diff --git a/drivers/gpu/drm/r128/r128_irq.c 
b/drivers/gpu/drm/dri1/r128/r128_irq.c
similarity index 100%
rename from drivers/gpu/drm/r128/r128_irq.c
rename to drivers/gpu/drm/dri1/r128/r128_irq.c
diff --git a/drivers/gpu/drm/r128/r128_state.c 
b/drivers/gpu/drm/dri1/r128/r128_state.c
similarity index 100%
rename from drivers/gpu/drm/r128/r128_state.c
rename to drivers/gpu/drm/dri1/r128/r128_state.c
-- 
2.34.1

[PATCH v1 01/11] drm: rename DRIVER_LEGACY to DRIVER_DRI1

"legacy" is a general term - be specific and use the term dri1.
The first step is to rename DRIVER_LEGACY to DRIVER_DRI1.

Suggested-by: Javier Martinez Canillas 
Signed-off-by: Sam Ravnborg 
---
 drivers/gpu/drm/drm_agpsupport.c|  4 ++--
 drivers/gpu/drm/drm_bufs.c  | 22 +++---
 drivers/gpu/drm/drm_context.c   | 24 
 drivers/gpu/drm/drm_dma.c   |  4 ++--
 drivers/gpu/drm/drm_drv.c   |  2 +-
 drivers/gpu/drm/drm_file.c  |  8 
 drivers/gpu/drm/drm_ioctl.c |  2 +-
 drivers/gpu/drm/drm_irq.c   |  6 +++---
 drivers/gpu/drm/drm_legacy_misc.c   |  2 +-
 drivers/gpu/drm/drm_lock.c  |  6 +++---
 drivers/gpu/drm/drm_pci.c   |  8 
 drivers/gpu/drm/drm_scatter.c   |  6 +++---
 drivers/gpu/drm/drm_vblank.c|  4 ++--
 drivers/gpu/drm/i810/i810_drv.c |  2 +-
 drivers/gpu/drm/mga/mga_drv.c   |  2 +-
 drivers/gpu/drm/r128/r128_drv.c |  2 +-
 drivers/gpu/drm/savage/savage_drv.c |  2 +-
 drivers/gpu/drm/sis/sis_drv.c   |  2 +-
 drivers/gpu/drm/tdfx/tdfx_drv.c |  2 +-
 drivers/gpu/drm/via/via_dri1.c  |  2 +-
 include/drm/drm_device.h|  2 +-
 include/drm/drm_drv.h   |  6 +++---
 22 files changed, 60 insertions(+), 60 deletions(-)

diff --git a/drivers/gpu/drm/drm_agpsupport.c b/drivers/gpu/drm/drm_agpsupport.c
index a4ad6fd13abc..b7f6bbe7e340 100644
--- a/drivers/gpu/drm/drm_agpsupport.c
+++ b/drivers/gpu/drm/drm_agpsupport.c
@@ -422,7 +422,7 @@ EXPORT_SYMBOL(drm_legacy_agp_init);
  * intact so it can still be used. It is safe to call this if AGP is disabled 
or
  * was already removed.
  *
- * Cleanup is only done for drivers who have DRIVER_LEGACY set.
+ * Cleanup is only done for drivers who have DRIVER_DRI1 set.
  */
 void drm_legacy_agp_clear(struct drm_device *dev)
 {
@@ -430,7 +430,7 @@ void drm_legacy_agp_clear(struct drm_device *dev)
 
if (!dev->agp)
return;
-   if (!drm_core_check_feature(dev, DRIVER_LEGACY))
+   if (!drm_core_check_feature(dev, DRIVER_DRI1))
return;
 
list_for_each_entry_safe(entry, tempe, >agp->memory, head) {
diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
index fcca21e8efac..8cc134d1c26a 100644
--- a/drivers/gpu/drm/drm_bufs.c
+++ b/drivers/gpu/drm/drm_bufs.c
@@ -424,7 +424,7 @@ int drm_legacy_addmap_ioctl(struct drm_device *dev, void 
*data,
return -EPERM;
 
if (!drm_core_check_feature(dev, DRIVER_KMS_LEGACY_CONTEXT) &&
-   !drm_core_check_feature(dev, DRIVER_LEGACY))
+   !drm_core_check_feature(dev, DRIVER_DRI1))
return -EOPNOTSUPP;
 
err = drm_addmap_core(dev, map->offset, map->size, map->type,
@@ -470,7 +470,7 @@ int drm_legacy_getmap_ioctl(struct drm_device *dev, void 
*data,
int i;
 
if (!drm_core_check_feature(dev, DRIVER_KMS_LEGACY_CONTEXT) &&
-   !drm_core_check_feature(dev, DRIVER_LEGACY))
+   !drm_core_check_feature(dev, DRIVER_DRI1))
return -EOPNOTSUPP;
 
idx = map->offset;
@@ -571,7 +571,7 @@ EXPORT_SYMBOL(drm_legacy_rmmap_locked);
 void drm_legacy_rmmap(struct drm_device *dev, struct drm_local_map *map)
 {
if (!drm_core_check_feature(dev, DRIVER_KMS_LEGACY_CONTEXT) &&
-   !drm_core_check_feature(dev, DRIVER_LEGACY))
+   !drm_core_check_feature(dev, DRIVER_DRI1))
return;
 
mutex_lock(>struct_mutex);
@@ -584,7 +584,7 @@ void drm_legacy_master_rmmaps(struct drm_device *dev, 
struct drm_master *master)
 {
struct drm_map_list *r_list, *list_temp;
 
-   if (!drm_core_check_feature(dev, DRIVER_LEGACY))
+   if (!drm_core_check_feature(dev, DRIVER_DRI1))
return;
 
mutex_lock(>struct_mutex);
@@ -629,7 +629,7 @@ int drm_legacy_rmmap_ioctl(struct drm_device *dev, void 
*data,
int ret;
 
if (!drm_core_check_feature(dev, DRIVER_KMS_LEGACY_CONTEXT) &&
-   !drm_core_check_feature(dev, DRIVER_LEGACY))
+   !drm_core_check_feature(dev, DRIVER_DRI1))
return -EOPNOTSUPP;
 
mutex_lock(>struct_mutex);
@@ -1276,7 +1276,7 @@ int drm_legacy_addbufs(struct drm_device *dev, void *data,
struct drm_buf_desc *request = data;
int ret;
 
-   if (!drm_core_check_feature(dev, DRIVER_LEGACY))
+   if (!drm_core_check_feature(dev, DRIVER_DRI1))
return -EOPNOTSUPP;
 
if (!drm_core_check_feature(dev, DRIVER_HAVE_DMA))
@@ -1322,7 +1322,7 @@ int __drm_legacy_infobufs(struct drm_device *dev,
int i;
int count;
 
-   if (!drm_core_check_feature(dev, DRIVER_LEGACY))
+   if (!drm_core_check_feature(dev, DRIVER_DRI1))
return -EOPNOTSUPP;
 
if (!drm_core_check_feature(dev, DRIVER_HAVE_DMA))
@@ -1412,7 +1412,7 @@ int drm_legacy_markbufs(struct drm_device *dev, void 
*data,
int order;
struct

[PATCH v1 0/11] drm: move dri1 drivers to drm/dri1/

While discussing the way forward for the via driver
Javier came up with the proposal to move all DRI1 drivers
to their own folder.

The idea is to move the old DRI1 drivers so one do not
accidentally consider them modern drivers.

This set of patches implements this idea.

To prepare the move, DRIVER_LEGACY and CONFIG_DRM_LEGACY
are both renamed to *_DRI1. This makes it more obvious
that we are dealing with DRI1 drivers, as we have
a lot of other legacy support.

The drivers continue to have their own sub-directory
so the driver files are not mixed with the core files
which are copied in the last commit.

The DRI1 specific part of drm/Kconfig is likewise pulled
out and located in the dri1/ folder.

Feedback welcome!

Sam

Sam Ravnborg (11):
  drm: rename DRIVER_LEGACY to DRIVER_DRI1
  drm: Rename CONFIG_DRM_LEGACY to CONFIG_DRM_DRI1
  drm/tdfx: Move the tdfx driver to drm/dri1/
  drm/r128: Move the r128 driver to drm/dri1/
  drm/i810: Move the i810 driver to drm/dri1/
  drm/mga: Move the mga driver to drm/dri1/
  drm/sis: Move the sis driver to drm/dri1/
  drm/via: Move the via driver to drm/dri1/
  drm/savage: Move the savage driver to drm/dri1/
  drm/dri1: Move Kconfig logic to drm/dri1
  drm: Move dri1 core files to drm/dri1

 arch/powerpc/configs/pmac32_defconfig  |  2 +-
 arch/powerpc/configs/ppc6xx_defconfig  |  2 +-
 drivers/char/agp/Makefile  |  2 +-
 drivers/char/agp/agp.h |  2 +-
 drivers/gpu/drm/Kconfig| 79 +-
 drivers/gpu/drm/Makefile   | 18 +++--
 drivers/gpu/drm/dri1/Kconfig   | 79 ++
 drivers/gpu/drm/dri1/Makefile  | 11 +++
 drivers/gpu/drm/{ => dri1}/drm_agpsupport.c|  4 +-
 drivers/gpu/drm/{ => dri1}/drm_bufs.c  | 22 +++---
 drivers/gpu/drm/{ => dri1}/drm_context.c   | 24 +++
 drivers/gpu/drm/{ => dri1}/drm_dma.c   |  4 +-
 drivers/gpu/drm/{ => dri1}/drm_hashtab.c   |  0
 drivers/gpu/drm/{ => dri1}/drm_irq.c   |  6 +-
 drivers/gpu/drm/{ => dri1}/drm_legacy_misc.c   |  2 +-
 drivers/gpu/drm/{ => dri1}/drm_lock.c  |  6 +-
 drivers/gpu/drm/{ => dri1}/drm_memory.c|  0
 drivers/gpu/drm/{ => dri1}/drm_scatter.c   |  6 +-
 drivers/gpu/drm/{ => dri1}/drm_vm.c|  2 +-
 drivers/gpu/drm/{ => dri1}/i810/Makefile   |  0
 drivers/gpu/drm/{ => dri1}/i810/i810_dma.c |  0
 drivers/gpu/drm/{ => dri1}/i810/i810_drv.c |  2 +-
 drivers/gpu/drm/{ => dri1}/i810/i810_drv.h |  0
 drivers/gpu/drm/{ => dri1}/mga/Makefile|  0
 drivers/gpu/drm/{ => dri1}/mga/mga_dma.c   |  0
 drivers/gpu/drm/{ => dri1}/mga/mga_drv.c   |  2 +-
 drivers/gpu/drm/{ => dri1}/mga/mga_drv.h   |  0
 drivers/gpu/drm/{ => dri1}/mga/mga_ioc32.c |  0
 drivers/gpu/drm/{ => dri1}/mga/mga_irq.c   |  0
 drivers/gpu/drm/{ => dri1}/mga/mga_state.c |  0
 drivers/gpu/drm/{ => dri1}/mga/mga_warp.c  |  0
 drivers/gpu/drm/{ => dri1}/r128/Makefile   |  0
 drivers/gpu/drm/{ => dri1}/r128/ati_pcigart.c  |  0
 drivers/gpu/drm/{ => dri1}/r128/ati_pcigart.h  |  0
 drivers/gpu/drm/{ => dri1}/r128/r128_cce.c |  0
 drivers/gpu/drm/{ => dri1}/r128/r128_drv.c |  2 +-
 drivers/gpu/drm/{ => dri1}/r128/r128_drv.h |  0
 drivers/gpu/drm/{ => dri1}/r128/r128_ioc32.c   |  0
 drivers/gpu/drm/{ => dri1}/r128/r128_irq.c |  0
 drivers/gpu/drm/{ => dri1}/r128/r128_state.c   |  0
 drivers/gpu/drm/{ => dri1}/savage/Makefile |  0
 drivers/gpu/drm/{ => dri1}/savage/savage_bci.c |  0
 drivers/gpu/drm/{ => dri1}/savage/savage_drv.c |  2 +-
 drivers/gpu/drm/{ => dri1}/savage/savage_drv.h |  0
 drivers/gpu/drm/{ => dri1}/savage/savage_state.c   |  0
 drivers/gpu/drm/{ => dri1}/sis/Makefile|  0
 drivers/gpu/drm/{ => dri1}/sis/sis_drv.c   |  2 +-
 drivers/gpu/drm/{ => dri1}/sis/sis_drv.h   |  0
 drivers/gpu/drm/{ => dri1}/sis/sis_mm.c|  0
 drivers/gpu/drm/{ => dri1}/tdfx/Makefile   |  0
 drivers/gpu/drm/{ => dri1}/tdfx/tdfx_drv.c |  2 +-
 drivers/gpu/drm/{ => dri1}/tdfx/tdfx_drv.h |  0
 drivers/gpu/drm/{ => dri1}/via/Makefile|  4 +-
 drivers/gpu/drm/{via/via_dri1.c => dri1/via/via.c} |  4 +-
 drivers/gpu/drm/drm_drv.c  |  2 +-
 drivers/gpu/drm/drm_file.c | 12 ++--
 drivers/gpu/drm/drm_internal.h |  2 +-
 drivers/gpu/drm/drm_ioc32.c| 12 ++--
 drivers/gpu/drm/drm_ioctl.c|  4 +-
 drivers/gpu/drm/drm_legacy.h   | 32 -
 drivers/gpu/drm/drm_pci.c  | 12 ++--
 drivers/gpu/drm/drm_vblank.c   | 12

Re: [v3] drm/i915/ttm: fix sg_table construction

2022-07-16 Thread Guenter Roeck

On Mon, Jul 11, 2022 at 09:58:59AM +0100, Matthew Auld wrote:
> If we encounter some monster sized local-memory page that exceeds the
> maximum sg length (UINT32_MAX), ensure that don't end up with some
> misaligned address in the entry that follows, leading to fireworks
> later. Also ensure we have some coverage of this in the selftests.
> 
> v2(Chris):
>   - Use round_down consistently to avoid udiv errors
> v3(Nirmoy):
>   - Also update the max_segment in the selftest
> 
> Fixes: f701b16d4cc5 ("drm/i915/ttm: add i915_sg_from_buddy_resource")
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6379
> Signed-off-by: Matthew Auld 
> Cc: Thomas Hellström 
> Cc: Nirmoy Das 
> Reviewed-by: Nirmoy Das 

Building i386:defconfig ... failed
--
Error log:
x86_64-linux-ld: drivers/gpu/drm/i915/i915_scatterlist.o: in function 
`i915_rsgt_from_mm_node':
i915_scatterlist.c:(.text+0x196): undefined reference to `__udivdi3'

Bisect log attached.

Guenter

---
# bad: [9b59ec8d50a1f28747ceff9a4f39af5deba9540e] Merge tag 
'riscv-for-linus-5.19-rc7' of 
git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux
# good: [e5d523f1ae8f2cef01f8e071aeee432654166708] ubsan: disable 
UBSAN_DIV_ZERO for clang
git bisect start 'HEAD' 'e5d523f1ae8f'
# bad: [2a347a06ebb1b186a5cb919c9f5ab6e040554be7] Merge tag 
'platform-drivers-x86-v5.19-4' of 
git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86
git bisect bad 2a347a06ebb1b186a5cb919c9f5ab6e040554be7
# bad: [093f8d8f10aa22935bc8bf7100700f714ebaba9c] Merge tag 
'amd-drm-fixes-5.19-2022-07-13' of https://gitlab.freedesktop.org/agd5f/linux 
into drm-fixes
git bisect bad 093f8d8f10aa22935bc8bf7100700f714ebaba9c
# bad: [ad765fae792e16ce3c1d0b69ce939e3f7dba40ab] drm/i915/gem: Look for 
waitboosting across the whole object prior to individual waits
git bisect bad ad765fae792e16ce3c1d0b69ce939e3f7dba40ab
# good: [f99546298a4537965b75d518c210742f641be389] Merge tag 
'gvt-fixes-2022-07-11' of https://github.com/intel/gvt-linux into 
drm-intel-fixes
git bisect good f99546298a4537965b75d518c210742f641be389
# bad: [aff1e0b09b54b64944b7fe32997229552737b9e9] drm/i915/ttm: fix sg_table 
construction
git bisect bad aff1e0b09b54b64944b7fe32997229552737b9e9
# good: [896dcabd1f8f613c533d948df17408c41f8929f5] drm/i915/selftests: fix a 
couple IS_ERR() vs NULL tests
git bisect good 896dcabd1f8f613c533d948df17408c41f8929f5
# first bad commit: [aff1e0b09b54b64944b7fe32997229552737b9e9] drm/i915/ttm: 
fix sg_table construction

Re: (subset) [PATCH v2 0/9] dt-bindings: msm/dp: cleanup Qualcomm DP and eDP bidndings

On Sun, 10 Jul 2022 11:41:24 +0300, Dmitry Baryshkov wrote:
> Fix several issues with the DP and eDP bindings on the Qualcomm
> platforms. While we are at it, fix several small issues with platform
> files declaring these controllers.
> 
> Changes since v1:
>  - Reordered patches to cleanup dts first, to remove warnings from DP
>schema
>  - Split DP register blocks in sc7180.dtsi and sc7280.dtsi
>  - Cleaned up the p1 register block handling: marked it as required for DP
>and absent for eDP controllers
>  - Dropped unused xo and ref clocks from sc7280-edp node, they belong to
>eDP PHY.
> 
> [...]

Applied, thanks!

[1/9] arm64: dts: qcom: sc7180: split register block for DP controller
  commit: b7b17c6bf3d18d12f198a5ab6ae2f093545de643
[2/9] arm64: dts: qcom: sc7180: drop #clock-cells from displayport-controller
  commit: ae0f7e1d97cb047ab5aeb03c8987671a2da93030
[3/9] arm64: dts: qcom: sc7280: split register block for DP controller
  commit: 3c14a456ee3e94d58682f6c7c77f8e71cbbcd8d8
[4/9] arm64: dts: qcom: sc7280: drop #clock-cells from displayport-controller
  commit: 0f1e23651a0ab71c82ab098ecbfc9ee7a4d74ced
[5/9] arm64: dts: qcom: sc7280: drop address/size-cells from eDP node
  commit: 97e5c82d4e170b815fe31fb91d6639be0f1b11aa
[6/9] arm64: dts: qcom: sc7280: drop unused clocks from eDP node
  commit: f32894b8d8b4300693f1c3549cad544799ffeb3b

Best regards,
-- 
Bjorn Andersson

Re: (subset) [PATCH v2 00/11] dt-bindings: display/msm: rework MDSS and DPU bindings

On Sun, 10 Jul 2022 12:00:29 +0300, Dmitry Baryshkov wrote:
> Create separate YAML schema for MDSS devicesd$ (both for MDP5 and DPU
> devices). Cleanup DPU schema files, so that they do not contain schema
> for both MDSS and DPU nodes. Apply misc small fixes to the DPU schema
> afterwards.
> 
> Changes since v1:
>  - Renamed DPU device nodes from mdp@ to display-controller@
>  - Described removal of mistakenly mentioned "lut" clock
>  - Switched mdss.yaml to use $ref instead of fixing compatible strings
>  - Dropped mdp-opp-table description (renamed by Krzysztof in his
>patchset)
>  - Reworked DPU's ports definitions. Dropped description of individual
>ports, left only /ports $ref and description in dpu-common.yaml.
> 
> [...]

Applied, thanks!

[01/11] arm64: dts: qcom: sdm845: rename DPU device node
commit: 1d52eb6cc827d0f166c728a7577609de75b6b8b1
[02/11] arm64: dts: qcom: sc7180: rename DPU device node
commit: 37e3558b79392ab864fe887b4593c5f737e063a5
[03/11] arm64: dts: qcom: sm8250: rename DPU device node
commit: ce5cf986cdab1973df0042ac5b743d5df008c338

Best regards,
-- 
Bjorn Andersson

Re: [PATCH v3 2/6] dt-bindings: Use new video interface bus type macros in examples

2022-07-16 Thread Laurent Pinchart

Hi Sakari,

On Sat, Jul 16, 2022 at 12:28:45PM +0300, Sakari Ailus wrote:
> On Thu, Jun 16, 2022 at 01:14:06AM +0300, Laurent Pinchart wrote:
> > Now that a header exists with macros for the media interface bus-type
> > values, replace hardcoding numerical constants with the corresponding
> > macros in the DT binding examples.
> > 
> > Signed-off-by: Laurent Pinchart 
> > ---
> > Changes since v2:
> > 
> > - Go back to PARALLEL
> > 
> > Changes since v1:
> > 
> > - Rename PARALLEL to BT601
> > ---
> >  .../devicetree/bindings/display/bridge/analogix,anx7625.yaml  | 1 +
> >  Documentation/devicetree/bindings/media/i2c/mipi-ccs.yaml | 3 ++-
> >  Documentation/devicetree/bindings/media/i2c/ovti,ov772x.yaml  | 3 ++-
> >  .../devicetree/bindings/media/marvell,mmp2-ccic.yaml  | 3 ++-
> >  Documentation/devicetree/bindings/media/microchip,xisc.yaml   | 3 ++-
> >  Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml| 4 +++-
> >  6 files changed, 12 insertions(+), 5 deletions(-)
> > 
> > diff --git 
> > a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml 
> > b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> > index 35a48515836e..b0e5585f93e2 100644
> > --- a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> > +++ b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> > @@ -118,6 +118,7 @@ additionalProperties: false
> >  examples:
> >- |
> >  #include 
> > +#include 
> >  
> >  i2c0 {
> >  #address-cells = <1>;
> 
> The definition doesn't seem to be used here. Is there a need to include
> this?

There was, but the change that added bus-type to this binding got
reverted in commit 979452fbc430 ("dt-bindings: drm/bridge: anx7625:
Revert DPI support") and I forgot to drop the header when rebasing.

> I could drop this chunk while applying. There's just one trivial change
> elsewhere in this patch to make.

Please do :-)

-- 
Regards,

Laurent Pinchart

Re: [PATCH v2 3/9] arm64: dts: qcom: sc7280: split register block for DP controller

On Sun 10 Jul 03:41 CDT 2022, Dmitry Baryshkov wrote:

> Follow the schema for the DP controller and declare 5 register regions
> instead of using a single region for all the registers. Note, this
> extends the dts by adding p1 region to the DP node (to be used for DP
> MST).
> 

Reviewed-by: Bjorn Andersson 

> Signed-off-by: Dmitry Baryshkov 
> ---
>  arch/arm64/boot/dts/qcom/sc7280.dtsi | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi 
> b/arch/arm64/boot/dts/qcom/sc7280.dtsi
> index a3def1022ea2..e54c2000b098 100644
> --- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
> @@ -3810,7 +3810,11 @@ mdss_edp_phy: phy@aec2a00 {
>   mdss_dp: displayport-controller@ae9 {
>   compatible = "qcom,sc7280-dp";
>  
> - reg = <0 0x0ae9 0 0x1400>;
> + reg = <0 0xae9 0 0x200>,
> +   <0 0xae90200 0 0x200>,
> +   <0 0xae90400 0 0xc00>,
> +   <0 0xae91000 0 0x400>,
> +   <0 0xae91400 0 0x400>;
>  
>   interrupt-parent = <>;
>   interrupts = <12>;
> -- 
> 2.35.1
>

Re: [PATCH v2 1/9] arm64: dts: qcom: sc7180: split register block for DP controller

On Sun 10 Jul 03:41 CDT 2022, Dmitry Baryshkov wrote:

> Follow the schema for the DP controller and declare 5 register regions
> instead of using a single region for all the registers. Note, this
> extends the dts by adding p1 region to the DP node (to be used for DP
> MST).
> 

Reviewed-by: Bjorn Andersson 

> Signed-off-by: Dmitry Baryshkov 
> ---
>  arch/arm64/boot/dts/qcom/sc7180.dtsi | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi 
> b/arch/arm64/boot/dts/qcom/sc7180.dtsi
> index 47ce5787ed5b..875808cf0614 100644
> --- a/arch/arm64/boot/dts/qcom/sc7180.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi
> @@ -3080,7 +3080,11 @@ mdss_dp: displayport-controller@ae9 {
>   compatible = "qcom,sc7180-dp";
>   status = "disabled";
>  
> - reg = <0 0x0ae9 0 0x1400>;
> + reg = <0 0xae9 0 0x200>,
> +   <0 0xae90200 0 0x200>,
> +   <0 0xae90400 0 0xc00>,
> +   <0 0xae91000 0 0x400>,
> +   <0 0xae91400 0 0x400>;
>  
>   interrupt-parent = <>;
>   interrupts = <12>;
> -- 
> 2.35.1
>

Re: [PATCH 2/2] drm/msm/dsi: use drm_dsc_config instead of msm_display_dsc_config

2022-07-16 Thread Marijn Suijten

On 2022-07-11 13:04:32, Dmitry Baryshkov wrote:
> There is no need to use the struct msm_display_dsc_config wrapper inside
> the dsi driver, use the struct drm_dsc_config directly to pass pps data.
> 
> Signed-off-by: Dmitry Baryshkov 

Reviewed-by: Marijn Suijten 

> ---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c |   2 +-
>  drivers/gpu/drm/msm/dsi/dsi.c   |   2 +-
>  drivers/gpu/drm/msm/dsi/dsi.h   |   2 +-
>  drivers/gpu/drm/msm/dsi/dsi_host.c  | 157 +++-
>  drivers/gpu/drm/msm/msm_drv.h   |   9 +-
>  5 files changed, 79 insertions(+), 93 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> index 8016d0a3aade..75ed2b36e1b3 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> @@ -585,7 +585,7 @@ static int _dpu_kms_initialize_dsi(struct drm_device *dev,
>   info.h_tile_instance[info.num_of_h_tiles++] = i;
>   info.is_cmd_mode = msm_dsi_is_cmd_mode(priv->dsi[i]);
>  
> - info.dsc = msm_dsi_get_dsc_config(priv->dsi[i])->drm;
> + info.dsc = msm_dsi_get_dsc_config(priv->dsi[i]);
>  
>   if (msm_dsi_is_bonded_dsi(priv->dsi[i]) && priv->dsi[other]) {
>   rc = msm_dsi_modeset_init(priv->dsi[other], dev, 
> encoder);
> diff --git a/drivers/gpu/drm/msm/dsi/dsi.c b/drivers/gpu/drm/msm/dsi/dsi.c
> index 1625328fa430..8f1ed31b048a 100644
> --- a/drivers/gpu/drm/msm/dsi/dsi.c
> +++ b/drivers/gpu/drm/msm/dsi/dsi.c
> @@ -21,7 +21,7 @@ bool msm_dsi_is_cmd_mode(struct msm_dsi *msm_dsi)
>   return !(host_flags & MIPI_DSI_MODE_VIDEO);
>  }
>  
> -struct msm_display_dsc_config *msm_dsi_get_dsc_config(struct msm_dsi 
> *msm_dsi)
> +struct drm_dsc_config *msm_dsi_get_dsc_config(struct msm_dsi *msm_dsi)
>  {
>   return msm_dsi_host_get_dsc_config(msm_dsi->host);
>  }
> diff --git a/drivers/gpu/drm/msm/dsi/dsi.h b/drivers/gpu/drm/msm/dsi/dsi.h
> index 580a1e6358bf..df46cdda1b43 100644
> --- a/drivers/gpu/drm/msm/dsi/dsi.h
> +++ b/drivers/gpu/drm/msm/dsi/dsi.h
> @@ -154,7 +154,7 @@ int dsi_calc_clk_rate_v2(struct msm_dsi_host *msm_host, 
> bool is_bonded_dsi);
>  int dsi_calc_clk_rate_6g(struct msm_dsi_host *msm_host, bool is_bonded_dsi);
>  void msm_dsi_host_snapshot(struct msm_disp_state *disp_state, struct 
> mipi_dsi_host *host);
>  void msm_dsi_host_test_pattern_en(struct mipi_dsi_host *host);
> -struct msm_display_dsc_config *msm_dsi_host_get_dsc_config(struct 
> mipi_dsi_host *host);
> +struct drm_dsc_config *msm_dsi_host_get_dsc_config(struct mipi_dsi_host 
> *host);
>  
>  /* dsi phy */
>  struct msm_dsi_phy;
> diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
> b/drivers/gpu/drm/msm/dsi/dsi_host.c
> index a34078497af1..15e108be1901 100644
> --- a/drivers/gpu/drm/msm/dsi/dsi_host.c
> +++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
> @@ -33,7 +33,7 @@
>  
>  #define DSI_RESET_TOGGLE_DELAY_MS 20
>  
> -static int dsi_populate_dsc_params(struct msm_display_dsc_config *dsc);
> +static int dsi_populate_dsc_params(struct drm_dsc_config *dsc);
>  
>  static int dsi_get_version(const void __iomem *base, u32 *major, u32 *minor)
>  {
> @@ -161,7 +161,7 @@ struct msm_dsi_host {
>   struct regmap *sfpb;
>  
>   struct drm_display_mode *mode;
> - struct msm_display_dsc_config *dsc;
> + struct drm_dsc_config *dsc;
>  
>   /* connected device info */
>   struct device_node *device_node;
> @@ -916,7 +916,7 @@ static void dsi_ctrl_config(struct msm_dsi_host 
> *msm_host, bool enable,
>  
>  static void dsi_update_dsc_timing(struct msm_dsi_host *msm_host, bool 
> is_cmd_mode, u32 hdisplay)
>  {
> - struct msm_display_dsc_config *dsc = msm_host->dsc;
> + struct drm_dsc_config *dsc = msm_host->dsc;
>   u32 reg, intf_width, reg_ctrl, reg_ctrl2;
>   u32 slice_per_intf, total_bytes_per_intf;
>   u32 pkt_per_line;
> @@ -927,24 +927,24 @@ static void dsi_update_dsc_timing(struct msm_dsi_host 
> *msm_host, bool is_cmd_mod
>* compress mode registers
>*/
>   intf_width = hdisplay;
> - slice_per_intf = DIV_ROUND_UP(intf_width, dsc->drm->slice_width);
> + slice_per_intf = DIV_ROUND_UP(intf_width, dsc->slice_width);
>  
>   /* If slice_per_pkt is greater than slice_per_intf
>* then default to 1. This can happen during partial
>* update.
>*/
> - if (slice_per_intf > dsc->drm->slice_count)
> - dsc->drm->slice_count = 1;
> + if (slice_per_intf > dsc->slice_count)
> + dsc->slice_count = 1;
>  
> - slice_per_intf = DIV_ROUND_UP(hdisplay, dsc->drm->slice_width);
> - bytes_in_slice = DIV_ROUND_UP(dsc->drm->slice_width * 
> dsc->drm->bits_per_pixel, 8);
> + slice_per_intf = DIV_ROUND_UP(hdisplay, dsc->slice_width);
> + bytes_in_slice = DIV_ROUND_UP(dsc->slice_width * dsc->bits_per_pixel, 
> 8);
>  
> - dsc->drm->slice_chunk_size = bytes_in_slice;
> +

[PATCH] drm/bridge: megachips: Fix a null pointer dereference bug

2022-07-16 Thread Zheyu Ma

When removing the module we will get the following warning:

[   31.911505] i2c-core: driver [stdp2690-ge-b850v3-fw] unregistered
[   31.912484] general protection fault, probably for non-canonical address 
0xdc01:  [#1] PREEMPT SMP KASAN PTI
[   31.913338] KASAN: null-ptr-deref in range 
[0x0008-0x000f]
[   31.915280] RIP: 0010:drm_bridge_remove+0x97/0x130
[   31.921825] Call Trace:
[   31.922533]  stdp4028_ge_b850v3_fw_remove+0x34/0x60 
[megachips_stdp_ge_b850v3_fw]
[   31.923139]  i2c_device_remove+0x181/0x1f0

The two bridges (stdp2690, stdp4028) do not probe at the same time, so
the driver does not call ge_b850v3_resgiter() when probing, causing the
driver to try to remove the object that has not been initialized.

Fix this by checking whether both the bridges are probed.

Signed-off-by: Zheyu Ma 
---
 drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c 
b/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c
index cce98bf2a4e7..c68a4cdf4625 100644
--- a/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c
+++ b/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c
@@ -296,7 +296,9 @@ static void ge_b850v3_lvds_remove(void)
 * This check is to avoid both the drivers
 * removing the bridge in their remove() function
 */
-   if (!ge_b850v3_lvds_ptr)
+   if (!ge_b850v3_lvds_ptr ||
+   !ge_b850v3_lvds_ptr->stdp2690_i2c ||
+   !ge_b850v3_lvds_ptr->stdp4028_i2c)
goto out;
 
drm_bridge_remove(_b850v3_lvds_ptr->bridge);
-- 
2.25.1

Re: [Intel-gfx] [PATCH RFC] drm/i915/gt: Retry RING_HEAD reset until it sticks

On Fri, Jul 15, 2022 at 09:26:16AM +0100, Mauro Carvalho Chehab wrote:
> From: Chris Wilson 
> 
> On Haswell, in particular, we see an issue where resets fails because

Can we then make this platform specific?
Only because some older hw doesn't behave like expected we shouldn't
make this a default & global workaround.

> the engine resumes from an incorrect RING_HEAD. Since the RING_HEAD
> doesn't point to the remaining requests to re-run, but may instead point
> into the uninitialised portion of the ring, the GPU may be then fed
> invalid instructions from a privileged context, oft pushing the GPU into
> an unrecoverable hang.
> 
> If at first the write doesn't succeed, try, try again.
> 
> References: https://gitlab.freedesktop.org/drm/intel/-/issues/5432
> Testcase: igt/i915_selftest/hangcheck
> Signed-off-by: Chris Wilson 
> Cc: Andrzej Hajda 
> Cc: Mika Kuoppala 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  .../gpu/drm/i915/gt/intel_ring_submission.c   | 44 +--
>  drivers/gpu/drm/i915/i915_utils.h | 10 +
>  2 files changed, 40 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_ring_submission.c 
> b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
> index d5d6f1fadcae..cc53feb1f8ed 100644
> --- a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
> +++ b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
> @@ -190,6 +190,7 @@ static bool stop_ring(struct intel_engine_cs *engine)
>  static int xcs_resume(struct intel_engine_cs *engine)
>  {
>   struct intel_ring *ring = engine->legacy.ring;
> + ktime_t kt;
>  
>   ENGINE_TRACE(engine, "ring:{HEAD:%04x, TAIL:%04x}\n",
>ring->head, ring->tail);
> @@ -228,9 +229,20 @@ static int xcs_resume(struct intel_engine_cs *engine)
>   set_pp_dir(engine);
>  
>   /* First wake the ring up to an empty/idle ring */
> - ENGINE_WRITE_FW(engine, RING_HEAD, ring->head);
> + until_timeout_ns(kt, 2 * NSEC_PER_MSEC) {
> + ENGINE_WRITE_FW(engine, RING_HEAD, ring->head);
> + if (ENGINE_READ_FW(engine, RING_HEAD) == ring->head)
> + break;
> + }
> +
>   ENGINE_WRITE_FW(engine, RING_TAIL, ring->head);
> - ENGINE_POSTING_READ(engine, RING_TAIL);
> + if (ENGINE_READ_FW(engine, RING_HEAD) != ENGINE_READ_FW(engine, 
> RING_TAIL)) {
> + ENGINE_TRACE(engine, "failed to reset empty ring: [%x, %x]: 
> %x\n",
> +  ENGINE_READ_FW(engine, RING_HEAD),
> +  ENGINE_READ_FW(engine, RING_TAIL),
> +  ring->head);
> + goto err;
> + }

commit message mentions until this point I'm afraid... everything below
(except the new until_timeout_ns) looks like a different patch to me,
or deserves some mention in the commit msg.

>  
>   ENGINE_WRITE_FW(engine, RING_CTL,
>   RING_CTL_SIZE(ring->size) | RING_VALID);
> @@ -239,12 +251,16 @@ static int xcs_resume(struct intel_engine_cs *engine)
>   if (__intel_wait_for_register_fw(engine->uncore,
>RING_CTL(engine->mmio_base),
>RING_VALID, RING_VALID,
> -  5000, 0, NULL))
> +  5000, 0, NULL)) {
> + ENGINE_TRACE(engine, "failed to restart\n");
>   goto err;
> + }
>  
> - if (GRAPHICS_VER(engine->i915) > 2)
> + if (GRAPHICS_VER(engine->i915) > 2) {
>   ENGINE_WRITE_FW(engine,
>   RING_MI_MODE, _MASKED_BIT_DISABLE(STOP_RING));
> + ENGINE_POSTING_READ(engine, RING_MI_MODE);
> + }
>  
>   /* Now awake, let it get started */
>   if (ring->tail != ring->head) {
> @@ -257,16 +273,16 @@ static int xcs_resume(struct intel_engine_cs *engine)
>   return 0;
>  
>  err:
> - drm_err(>i915->drm,
> - "%s initialization failed; "
> - "ctl %08x (valid? %d) head %08x [%08x] tail %08x [%08x] start 
> %08x [expected %08x]\n",
> - engine->name,
> - ENGINE_READ(engine, RING_CTL),
> - ENGINE_READ(engine, RING_CTL) & RING_VALID,
> - ENGINE_READ(engine, RING_HEAD), ring->head,
> - ENGINE_READ(engine, RING_TAIL), ring->tail,
> - ENGINE_READ(engine, RING_START),
> - i915_ggtt_offset(ring->vma));
> + ENGINE_TRACE(engine,
> +  "initialization failed; "
> +  "ctl %08x (valid? %d) head %08x [%08x] tail %08x [%08x] 
> start %08x [expected %08x]\n",
> +  ENGINE_READ(engine, RING_CTL),
> +  ENGINE_READ(engine, RING_CTL) & RING_VALID,
> +  ENGINE_READ(engine, RING_HEAD), ring->head,
> +  ENGINE_READ(engine, RING_TAIL), ring->tail,
> +  ENGINE_READ(engine, RING_START),
> +  i915_ggtt_offset(ring->vma));
> +

Re: [PATCH 1/2] drm/msm/dpu: use drm_dsc_config instead of msm_display_dsc_config

2022-07-16 Thread Marijn Suijten

On 2022-07-11 13:04:31, Dmitry Baryshkov wrote:
> There is no need to use the struct msm_display_dsc_config wrapper inside
> the dpu driver, use the struct drm_dsc_config directly to pass pps data.
> 
> Signed-off-by: Dmitry Baryshkov 

Reviewed-by: Marijn Suijten 

> ---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 25 +++
>  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h |  2 +-
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c  | 74 ++---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.h  |  4 +-
>  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c |  2 +-
>  5 files changed, 54 insertions(+), 53 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> index c682d4e02d1b..07b22b7df2e9 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> @@ -162,7 +162,7 @@ enum dpu_enc_rc_states {
>   * @vsync_event_work:worker to handle vsync event for 
> autorefresh
>   * @topology:   topology of the display
>   * @idle_timeout:idle timeout duration in milliseconds
> - * @dsc: msm_display_dsc_config pointer, for DSC-enabled 
> encoders
> + * @dsc: drm_dsc_config pointer, for DSC-enabled encoders
>   */
>  struct dpu_encoder_virt {
>   struct drm_encoder base;
> @@ -208,7 +208,7 @@ struct dpu_encoder_virt {
>   bool wide_bus_en;
>  
>   /* DSC configuration */
> - struct msm_display_dsc_config *dsc;
> + struct drm_dsc_config *dsc;
>  };
>  
>  #define to_dpu_encoder_virt(x) container_of(x, struct dpu_encoder_virt, base)
> @@ -1791,12 +1791,12 @@ static void 
> dpu_encoder_vsync_event_work_handler(struct kthread_work *work)
>  }
>  
>  static u32
> -dpu_encoder_dsc_initial_line_calc(struct msm_display_dsc_config *dsc,
> +dpu_encoder_dsc_initial_line_calc(struct drm_dsc_config *dsc,
> u32 enc_ip_width)
>  {
>   int ssm_delay, total_pixels, soft_slice_per_enc;
>  
> - soft_slice_per_enc = enc_ip_width / dsc->drm->slice_width;
> + soft_slice_per_enc = enc_ip_width / dsc->slice_width;
>  
>   /*
>* minimum number of initial line pixels is a sum of:
> @@ -1808,16 +1808,16 @@ dpu_encoder_dsc_initial_line_calc(struct 
> msm_display_dsc_config *dsc,
>* 5. 6 additional pixels as the output of the rate buffer is
>*48 bits wide
>*/
> - ssm_delay = ((dsc->drm->bits_per_component < 10) ? 84 : 92);
> - total_pixels = ssm_delay * 3 + dsc->drm->initial_xmit_delay + 47;
> + ssm_delay = ((dsc->bits_per_component < 10) ? 84 : 92);
> + total_pixels = ssm_delay * 3 + dsc->initial_xmit_delay + 47;
>   if (soft_slice_per_enc > 1)
>   total_pixels += (ssm_delay * 3);
> - return DIV_ROUND_UP(total_pixels, dsc->drm->slice_width);
> + return DIV_ROUND_UP(total_pixels, dsc->slice_width);
>  }
>  
>  static void dpu_encoder_dsc_pipe_cfg(struct dpu_hw_dsc *hw_dsc,
>struct dpu_hw_pingpong *hw_pp,
> -  struct msm_display_dsc_config *dsc,
> +  struct drm_dsc_config *dsc,
>u32 common_mode,
>u32 initial_lines)
>  {
> @@ -1835,7 +1835,7 @@ static void dpu_encoder_dsc_pipe_cfg(struct dpu_hw_dsc 
> *hw_dsc,
>  }
>  
>  static void dpu_encoder_prep_dsc(struct dpu_encoder_virt *dpu_enc,
> -  struct msm_display_dsc_config *dsc)
> +  struct drm_dsc_config *dsc)
>  {
>   /* coding only for 2LM, 2enc, 1 dsc config */
>   struct dpu_encoder_phys *enc_master = dpu_enc->cur_master;
> @@ -1858,14 +1858,15 @@ static void dpu_encoder_prep_dsc(struct 
> dpu_encoder_virt *dpu_enc,
>   }
>   }
>  
> - pic_width = dsc->drm->pic_width;
> + dsc_common_mode = 0;
> + pic_width = dsc->pic_width;
>  
>   dsc_common_mode = DSC_MODE_MULTIPLEX | DSC_MODE_SPLIT_PANEL;
>   if (enc_master->intf_mode == INTF_MODE_VIDEO)
>   dsc_common_mode |= DSC_MODE_VIDEO;
>  
> - this_frame_slices = pic_width / dsc->drm->slice_width;
> - intf_ip_w = this_frame_slices * dsc->drm->slice_width;
> + this_frame_slices = pic_width / dsc->slice_width;
> + intf_ip_w = this_frame_slices * dsc->slice_width;
>  
>   /*
>* dsc merge case: when using 2 encoders for the same stream,
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
> index d4d1ecd416e3..9e7236ef34e6 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
> @@ -36,7 +36,7 @@ struct msm_display_info {
>   uint32_t h_tile_instance[MAX_H_TILES_PER_DISPLAY];
>   bool is_cmd_mode;
>   bool is_te_using_watchdog_timer;
> - struct msm_display_dsc_config *dsc;
> +

[GIT PULL FOR v5.20] Miscellaneous R-Car DU fixes and enhancements

2022-07-16 Thread Laurent Pinchart

Hi Dave, Daniel,

I would have sworn I had sent this pull request a week ago, but I can't
find any trace of it in the mailing list archive, so I'm not sure what I
messed up. If there's still time for v5.20 it would be nice to get those
5 patches in, otherwise I'll resend for v5.21.

The following changes since commit f929217499cf54a30be995aae65e9951ba079c90:

  Merge tag 'drm-misc-next-2022-06-30' of 
git://anongit.freedesktop.org/drm/drm-misc into drm-next (2022-07-01 09:52:37 
+1000)

are available in the Git repository at:

  git://linuxtv.org/pinchartl/media.git tags/du-next-20220707

for you to fetch changes up to 676ad8e997036e2f815c293b76c356fb7cc97a08:

  drm: rcar-du: Lift z-pos restriction on primary plane for Gen3 (2022-07-07 
05:24:36 +0300)


Miscellaneous R-Car DU fixes and enhancements


Biju Das (1):
  drm: rcar-du: Add num_rpf to struct rcar_du_device_info

Kieran Bingham (1):
  drm: rcar-du: Extend CMM HDSE documentation

LUU HOAI (1):
  drm: rcar-du: Fix Alpha blending issue on Gen3

Laurent Pinchart (2):
  drm: rcar-du: Drop file name from comment header blocks
  drm: rcar-du: Lift z-pos restriction on primary plane for Gen3

 drivers/gpu/drm/rcar-du/rcar_cmm.c   |  2 +-
 drivers/gpu/drm/rcar-du/rcar_cmm.h   |  2 +-
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c   |  7 ++-
 drivers/gpu/drm/rcar-du/rcar_du_crtc.h   |  2 +-
 drivers/gpu/drm/rcar-du/rcar_du_drv.c| 19 ++-
 drivers/gpu/drm/rcar-du/rcar_du_drv.h|  4 +++-
 drivers/gpu/drm/rcar-du/rcar_du_encoder.c|  2 +-
 drivers/gpu/drm/rcar-du/rcar_du_encoder.h|  2 +-
 drivers/gpu/drm/rcar-du/rcar_du_group.c  |  2 +-
 drivers/gpu/drm/rcar-du/rcar_du_group.h  |  2 +-
 drivers/gpu/drm/rcar-du/rcar_du_kms.c|  2 +-
 drivers/gpu/drm/rcar-du/rcar_du_kms.h|  2 +-
 drivers/gpu/drm/rcar-du/rcar_du_plane.c  | 14 +-
 drivers/gpu/drm/rcar-du/rcar_du_plane.h  |  2 +-
 drivers/gpu/drm/rcar-du/rcar_du_regs.h   |  2 +-
 drivers/gpu/drm/rcar-du/rcar_du_vsp.c| 19 +--
 drivers/gpu/drm/rcar-du/rcar_du_vsp.h|  2 +-
 drivers/gpu/drm/rcar-du/rcar_du_writeback.c  |  2 +-
 drivers/gpu/drm/rcar-du/rcar_du_writeback.h  |  2 +-
 drivers/gpu/drm/rcar-du/rcar_lvds.c  |  2 +-
 drivers/gpu/drm/rcar-du/rcar_lvds.h  |  2 +-
 drivers/gpu/drm/rcar-du/rcar_lvds_regs.h |  2 +-
 drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c  |  2 +-
 drivers/gpu/drm/rcar-du/rcar_mipi_dsi_regs.h |  2 +-
 24 files changed, 64 insertions(+), 37 deletions(-)


-- 
Regards,

Laurent Pinchart

[Bug 216120] [BISECTED][REGRESSION] drm/amdgpu: add drm buddy support to amdgpu

2022-07-16 Thread bugzilla-daemon

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

mat2003...@gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WILL_NOT_FIX

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

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

Re: [PATCH v2 24/39] drm/i915: dvo_sil164.c: use SPDX header

2022-07-16 Thread Joe Perches

On Fri, 2022-07-15 at 17:35 -0400, Rodrigo Vivi wrote:
> On Wed, Jul 13, 2022 at 09:12:12AM +0100, Mauro Carvalho Chehab wrote:
> > This file is licensed with MIT license. Change its license text
> > to use SPDX.
> > 
> > Signed-off-by: Mauro Carvalho Chehab 
> 
> Reviewed-by: Rodrigo Vivi 

Not exactly the MIT license as it's missing "or copyright holders"
> 
> > ---
> > 
> > To avoid mailbombing on a large number of people, only mailing lists were 
> > C/C on the cover.
> > See [PATCH v2 00/39] at: 
> > https://lore.kernel.org/all/cover.1657699522.git.mche...@kernel.org/
> > 
> >  drivers/gpu/drm/i915/display/dvo_sil164.c | 32 +--
> >  1 file changed, 6 insertions(+), 26 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/dvo_sil164.c 
> > b/drivers/gpu/drm/i915/display/dvo_sil164.c
> > index 0dfa0a0209ff..12974f7c9dc1 100644
> > --- a/drivers/gpu/drm/i915/display/dvo_sil164.c
> > +++ b/drivers/gpu/drm/i915/display/dvo_sil164.c
> > @@ -1,30 +1,10 @@
> > -/**
> > +// SPDX-License-Identifier: MIT
> >  
> > -Copyright © 2006 Dave Airlie
> > -
> > -All Rights Reserved.
> > -
> > -Permission is hereby granted, free of charge, to any person obtaining a
> > -copy of this software and associated documentation files (the
> > -"Software"), to deal in the Software without restriction, including
> > -without limitation the rights to use, copy, modify, merge, publish,
> > -distribute, sub license, and/or sell copies of the Software, and to
> > -permit persons to whom the Software is furnished to do so, subject to
> > -the following conditions:
> > -
> > -The above copyright notice and this permission notice (including the
> > -next paragraph) shall be included in all copies or substantial portions
> > -of the Software.
> > -
> > -THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
> > -OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> > -MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT.
> > -IN NO EVENT SHALL THE AUTHOR

Missing "Authors or copyright holders"

> > BE LIABLE FOR
> > -ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
> > -TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
> > -SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
> > -
> > -**/
> > +/*
> > + * Copyright © 2006 Dave Airlie
> > + *
> > + * All Rights Reserved.
> > + */
> >  
> >  #include "intel_display_types.h"
> >  #include "intel_dvo_dev.h"
> > -- 
> > 2.36.1
> >

Re: [git pull] drm fixes for 5.19-rc7

2022-07-16 Thread Nathan Chancellor

On Fri, Jul 15, 2022 at 01:36:17PM +1000, Dave Airlie wrote:
> Matthew Auld (1):
>   drm/i915/ttm: fix sg_table construction

This patch breaks i386_defconfig with both GCC and clang:

  ld: drivers/gpu/drm/i915/i915_scatterlist.o: in function 
`i915_rsgt_from_mm_node':
  i915_scatterlist.c:(.text+0x1a7): undefined reference to `__udivdi3'

  ld.lld: error: undefined symbol: __udivdi3
  >>> referenced by i915_scatterlist.c
  >>>   gpu/drm/i915/i915_scatterlist.o:(i915_rsgt_from_mm_node) in 
archive drivers/built-in.a

It was reported by Stephen in -next [1] and there is a fix [2] that
works for me but it doesn't appear to be applied yet (at least, it is
not in drm-intel-fixes at the moment). It is a little disappointing to
see new build errors being introduced before -rc7, especially when
visible with a defconfig...

[1]: https://lore.kernel.org/20220713221454.67bb2...@canb.auug.org.au/
[2]: https://lore.kernel.org/20220712174050.592550-1-matthew.a...@intel.com/

Cheers,
Nathan

Re: [PATCH v2] i2c: imx: fix typo in comment

2022-07-16 Thread Oleksij Rempel

On Fri, Jul 15, 2022 at 03:42:18PM +0200, Flavio Suligoi wrote:
> to provid --> to provide
> 
> Signed-off-by: Flavio Suligoi 

Acked-by: Oleksij Rempel 

Thank you.

> ---
> v2:
>  - fix typo in subject
> 
>  drivers/i2c/busses/i2c-imx.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
> index e9e2db68b9fb..78fb1a4274a6 100644
> --- a/drivers/i2c/busses/i2c-imx.c
> +++ b/drivers/i2c/busses/i2c-imx.c
> @@ -66,7 +66,7 @@
>  
>  /* IMX I2C registers:
>   * the I2C register offset is different between SoCs,
> - * to provid support for all these chips, split the
> + * to provide support for all these chips, split the
>   * register offset into a fixed base address and a
>   * variable shift value, then the full register offset
>   * will be calculated by
> -- 
> 2.25.1
> 
> 

-- 
Pengutronix e.K.   | |
Steuerwalder Str. 21   | http://www.pengutronix.de/  |
31137 Hildesheim, Germany  | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

Re: [PATCH v2 22/39] drm/i915: stop using kernel-doc markups for something else

On Wed, Jul 13, 2022 at 09:12:10AM +0100, Mauro Carvalho Chehab wrote:
> There are some occurrences of "/**" that aren't actually part of
> a kernel-doc markup. Replace them by "/*", in order to make easier
> to identify what i915 files contain kernel-doc markups.
> 
> Signed-off-by: Mauro Carvalho Chehab 

\o/

Reviewed-by: Rodrigo Vivi 



> ---
> 
> To avoid mailbombing on a large number of people, only mailing lists were C/C 
> on the cover.
> See [PATCH v2 00/39] at: 
> https://lore.kernel.org/all/cover.1657699522.git.mche...@kernel.org/
> 
>  drivers/gpu/drm/i915/display/dvo_ch7017.c | 26 
>  drivers/gpu/drm/i915/display/dvo_ch7xxx.c |  6 +-
>  .../drm/i915/display/intel_display_types.h|  2 +-
>  drivers/gpu/drm/i915/display/intel_dvo_dev.h  |  6 +-
>  drivers/gpu/drm/i915/display/intel_sdvo.c |  4 +-
>  drivers/gpu/drm/i915/display/intel_tv.c   |  2 +-
>  drivers/gpu/drm/i915/gt/intel_context_types.h | 63 +--
>  drivers/gpu/drm/i915/gt/intel_ggtt_fencing.h  |  2 +-
>  drivers/gpu/drm/i915/gt/intel_gt_types.h  | 12 ++--
>  drivers/gpu/drm/i915/gt/intel_reset_types.h   |  4 +-
>  .../gpu/drm/i915/gt/intel_timeline_types.h|  6 +-
>  .../drm/i915/gt/shaders/clear_kernel/hsw.asm  |  4 +-
>  .../drm/i915/gt/shaders/clear_kernel/ivb.asm  |  4 +-
>  drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h | 10 +--
>  drivers/gpu/drm/i915/i915_drm_client.h|  2 +-
>  drivers/gpu/drm/i915/i915_drv.h   | 30 -
>  drivers/gpu/drm/i915/i915_file_private.h  |  8 +--
>  drivers/gpu/drm/i915/i915_gpu_error.h |  4 +-
>  drivers/gpu/drm/i915/i915_pmu.h   | 32 +-
>  drivers/gpu/drm/i915/intel_uncore.h   |  4 +-
>  20 files changed, 115 insertions(+), 116 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/dvo_ch7017.c 
> b/drivers/gpu/drm/i915/display/dvo_ch7017.c
> index 0589994dde11..581e29ab77e4 100644
> --- a/drivers/gpu/drm/i915/display/dvo_ch7017.c
> +++ b/drivers/gpu/drm/i915/display/dvo_ch7017.c
> @@ -55,13 +55,13 @@
>  #define CH7017_TEST_PATTERN  0x48
>  
>  #define CH7017_POWER_MANAGEMENT  0x49
> -/** Enables the TV output path. */
> +/* Enables the TV output path. */
>  #define CH7017_TV_EN (1 << 0)
>  #define CH7017_DAC0_POWER_DOWN   (1 << 1)
>  #define CH7017_DAC1_POWER_DOWN   (1 << 2)
>  #define CH7017_DAC2_POWER_DOWN   (1 << 3)
>  #define CH7017_DAC3_POWER_DOWN   (1 << 4)
> -/** Powers down the TV out block, and DAC0-3 */
> +/* Powers down the TV out block, and DAC0-3 */
>  #define CH7017_TV_POWER_DOWN_EN  (1 << 5)
>  
>  #define CH7017_VERSION_ID0x4a
> @@ -84,26 +84,26 @@
>  #define CH7017_UP_SCALER_HORIZONTAL_INC_10x5e
>  
>  #define CH7017_HORIZONTAL_ACTIVE_PIXEL_INPUT 0x5f
> -/**< Low bits of horizontal active pixel input */
> +/* Low bits of horizontal active pixel input */
>  
>  #define CH7017_ACTIVE_INPUT_LINE_OUTPUT  0x60
> -/** High bits of horizontal active pixel input */
> +/* High bits of horizontal active pixel input */
>  #define CH7017_LVDS_HAP_INPUT_MASK   (0x7 << 0)
> -/** High bits of vertical active line output */
> +/* High bits of vertical active line output */
>  #define CH7017_LVDS_VAL_HIGH_MASK(0x7 << 3)
>  
>  #define CH7017_VERTICAL_ACTIVE_LINE_OUTPUT   0x61
> -/**< Low bits of vertical active line output */
> +/* Low bits of vertical active line output */
>  
>  #define CH7017_HORIZONTAL_ACTIVE_PIXEL_OUTPUT0x62
> -/**< Low bits of horizontal active pixel output */
> +/* Low bits of horizontal active pixel output */
>  
>  #define CH7017_LVDS_POWER_DOWN   0x63
> -/** High bits of horizontal active pixel output */
> +/* High bits of horizontal active pixel output */
>  #define CH7017_LVDS_HAP_HIGH_MASK(0x7 << 0)
> -/** Enables the LVDS power down state transition */
> +/* Enables the LVDS power down state transition */
>  #define CH7017_LVDS_POWER_DOWN_EN(1 << 6)
> -/** Enables the LVDS upscaler */
> +/* Enables the LVDS upscaler */
>  #define CH7017_LVDS_UPSCALER_EN  (1 << 7)
>  #define CH7017_LVDS_POWER_DOWN_DEFAULT_RESERVED 0x08
>  
> @@ -116,9 +116,9 @@
>  #define CH7017_LVDS_ENCODING_2   0x65
>  
>  #define CH7017_LVDS_PLL_CONTROL  0x66
> -/** Enables the LVDS panel output path */
> +/* Enables the LVDS panel output path */
>  #define CH7017_LVDS_PANEN(1 << 0)
> -/** Enables the LVDS panel backlight */
> +/* Enables the LVDS panel backlight */
>  #define CH7017_LVDS_BKLEN(1 << 3)
>  
>  #define CH7017_POWER_SEQUENCING_T1   0x67
> @@ -197,7 +197,7 @@ static bool ch7017_write(struct intel_dvo_device *dvo, u8 
> addr, u8 val)
>   return i2c_transfer(dvo->i2c_bus, , 1) == 1;
>  }
>  
> -/** Probes for a CH7017 on the given bus and slave address. */
> +/* Probes for a CH7017 on the given bus and slave address. */
>  static bool ch7017_init(struct

Re: [PATCH v2 25/39] drm/i915: i915_vma_resource.c: fix some kernel-doc markups

On Wed, Jul 13, 2022 at 09:12:13AM +0100, Mauro Carvalho Chehab wrote:
> Building docs currently produces two warnings:
> 
> Documentation/foo/i915:71: 
> ./drivers/gpu/drm/i915/i915_vma_resource.c:286: WARNING: Inline strong 
> start-string without end-string.
> Documentation/foo/i915:71: 
> ./drivers/gpu/drm/i915/i915_vma_resource.c:370: WARNING: Inline strong 
> start-string without end-string.
> 
> That's because @foo evaluates into **foo**, and placing anything
> after it without spaces cause Sphinx to warn and do the wrong
> thing.. So, replace them by a different Sphinx-compatible tag.
> 
> Signed-off-by: Mauro Carvalho Chehab 

Reviewed-by: Rodrigo Vivi 

> ---
> 
> To avoid mailbombing on a large number of people, only mailing lists were C/C 
> on the cover.
> See [PATCH v2 00/39] at: 
> https://lore.kernel.org/all/cover.1657699522.git.mche...@kernel.org/
> 
>  drivers/gpu/drm/i915/i915_vma_resource.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_vma_resource.c 
> b/drivers/gpu/drm/i915/i915_vma_resource.c
> index 27c55027387a..fa5a678018d9 100644
> --- a/drivers/gpu/drm/i915/i915_vma_resource.c
> +++ b/drivers/gpu/drm/i915/i915_vma_resource.c
> @@ -283,7 +283,7 @@ i915_vma_resource_color_adjust_range(struct 
> i915_address_space *vm,
>   *
>   * The function needs to be called with the vm lock held.
>   *
> - * Return: Zero on success, -ERESTARTSYS if interrupted and @intr==true
> + * Return: Zero on success, -ERESTARTSYS if interrupted and ``intr==true``
>   */
>  int i915_vma_resource_bind_dep_sync(struct i915_address_space *vm,
>   u64 offset,
> @@ -367,7 +367,7 @@ void i915_vma_resource_bind_dep_sync_all(struct 
> i915_address_space *vm)
>   * this means that during heavy memory pressure, we will sync in this
>   * function.
>   *
> - * Return: Zero on success, -ERESTARTSYS if interrupted and @intr==true
> + * Return: Zero on success, -ERESTARTSYS if interrupted and ``intr==true``
>   */
>  int i915_vma_resource_bind_dep_await(struct i915_address_space *vm,
>struct i915_sw_fence *sw_fence,
> -- 
> 2.36.1
>

Re: [Intel-gfx] [PATCH v2 16/39] drm/i915: intel_fb: fix a kernel-doc issue with Sphinx

On Wed, Jul 13, 2022 at 09:12:04AM +0100, Mauro Carvalho Chehab wrote:
> We can't use %foo[] as this produces a bad markup.
> Use instead, the emphasis markup directly.
> 
> Fix this issue:
>   Documentation/gpu/i915:136: 
> ./drivers/gpu/drm/i915/display/intel_fb.c:280: WARNING: Inline strong 
> start-string without end-string.
> 
> Signed-off-by: Mauro Carvalho Chehab 

Just trying to understand as well on why in a few you had chosen ```foo```
and here **foo**. why?

anyway, not a blocker:

Reviewed-by: Rodrigo Vivi 



> ---
> 
> To avoid mailbombing on a large number of people, only mailing lists were C/C 
> on the cover.
> See [PATCH v2 00/39] at: 
> https://lore.kernel.org/all/cover.1657699522.git.mche...@kernel.org/
> 
>  drivers/gpu/drm/i915/display/intel_fb.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_fb.c 
> b/drivers/gpu/drm/i915/display/intel_fb.c
> index b191915ab351..fe72c75a9c79 100644
> --- a/drivers/gpu/drm/i915/display/intel_fb.c
> +++ b/drivers/gpu/drm/i915/display/intel_fb.c
> @@ -276,7 +276,7 @@ lookup_format_info(const struct drm_format_info formats[],
>   * @cmd: FB add command structure
>   *
>   * Returns:
> - * Returns the format information for @cmd->pixel_format specific to 
> @cmd->modifier[0],
> + * Returns the format information for @cmd->pixel_format specific to 
> **cmd->modifier[0]**,
>   * or %NULL if the modifier doesn't override the format.
>   */
>  const struct drm_format_info *
> -- 
> 2.36.1
>

Re: [Intel-gfx] [PATCH v2 26/39] drm/i915: i915_gem.c fix a kernel-doc issue

On Wed, Jul 13, 2022 at 09:12:14AM +0100, Mauro Carvalho Chehab wrote:
> Prevent this Sphinx warning:
> 
>   Documentation/foo/i915:728: ./drivers/gpu/drm/i915/i915_gem.c:447: 
> WARNING: Inline emphasis start-string without end-string.
> 
> By using @data to identify the data field, as expected by kernel-doc.
> 
> Signed-off-by: Mauro Carvalho Chehab 

Reviewed-by: Rodrigo Vivi 

> ---
> 
> To avoid mailbombing on a large number of people, only mailing lists were C/C 
> on the cover.
> See [PATCH v2 00/39] at: 
> https://lore.kernel.org/all/cover.1657699522.git.mche...@kernel.org/
> 
>  drivers/gpu/drm/i915/i915_gem.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 41e83d078a70..0ca4bb08ea78 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -444,7 +444,7 @@ i915_gem_gtt_pread(struct drm_i915_gem_object *obj,
>   * @data: ioctl data blob
>   * @file: drm file pointer
>   *
> - * On error, the contents of *data are undefined.
> + * On error, the contents of @data is undefined.
>   */
>  int
>  i915_gem_pread_ioctl(struct drm_device *dev, void *data,
> -- 
> 2.36.1
>

Re: [Intel-gfx] [PATCH v2 20/39] drm/i915: i915_gem_wait.c: fix a kernel-doc markup

On Wed, Jul 13, 2022 at 09:12:08AM +0100, Mauro Carvalho Chehab wrote:
> The return codes for i915_gem_wait_ioctl() have identation issues,
> and will be displayed on a very confusing way. Use lists to improve
> its output.
> 
> Signed-off-by: Mauro Carvalho Chehab 

Reviewed-by: Rodrigo Vivi 

> ---
> 
> To avoid mailbombing on a large number of people, only mailing lists were C/C 
> on the cover.
> See [PATCH v2 00/39] at: 
> https://lore.kernel.org/all/cover.1657699522.git.mche...@kernel.org/
> 
>  drivers/gpu/drm/i915/gem/i915_gem_wait.c | 24 +---
>  1 file changed, 13 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_wait.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_wait.c
> index 4a33ad2d122b..1fd5cff552ed 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_wait.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_wait.c
> @@ -210,23 +210,25 @@ static unsigned long to_wait_timeout(s64 timeout_ns)
>   * @data: ioctl data blob
>   * @file: drm file pointer
>   *
> - * Returns 0 if successful, else an error is returned with the remaining 
> time in
> - * the timeout parameter.
> - *  -ETIME: object is still busy after timeout
> - *  -ERESTARTSYS: signal interrupted the wait
> - *  -ENONENT: object doesn't exist
> - * Also possible, but rare:
> - *  -EAGAIN: incomplete, restart syscall
> - *  -ENOMEM: damn
> - *  -ENODEV: Internal IRQ fail
> - *  -E?: The add request failed
> - *
>   * The wait ioctl with a timeout of 0 reimplements the busy ioctl. With any
>   * non-zero timeout parameter the wait ioctl will wait for the given number 
> of
>   * nanoseconds on an object becoming unbusy. Since the wait itself does so
>   * without holding struct_mutex the object may become re-busied before this
>   * function completes. A similar but shorter * race condition exists in the 
> busy
>   * ioctl
> + *
> + * Returns:
> + * 0 if successful, else an error is returned with the remaining time in
> + * the timeout parameter.
> + * * -ETIME: object is still busy after timeout
> + * * -ERESTARTSYS: signal interrupted the wait
> + * * -ENONENT: object doesn't exist
> + *
> + * Also possible, but rare:
> + * * -EAGAIN: incomplete, restart syscall
> + * * -ENOMEM: damn
> + * * -ENODEV: Internal IRQ fail
> + * * -E?: The add request failed
>   */
>  int
>  i915_gem_wait_ioctl(struct drm_device *dev, void *data, struct drm_file 
> *file)
> -- 
> 2.36.1
>

Re: [PATCH] drm/nouveau/bios: set info only when the return is not 0

2022-07-16 Thread Tom Rix




On 7/15/22 12:09 PM, Lyude Paul wrote:

On Mon, 2022-07-04 at 17:32 -0400, Lyude Paul wrote:

Reviewed-by: Lyude Paul 

Currently on flakey internet in the back of a car, so I probably won't be
able
to push this until I get back tonight or early tomorrow

Whoops! Slipped my mind when I got back, but I just remembered it now so I
will go ahead and push :). apologies for the delay!


Thanks!

T




On Sat, 2022-07-02 at 11:39 -0400, Tom Rix wrote:

clang static analysis reports
drivers/gpu/drm/nouveau/nvkm/subdev/bios/pmu.c:68:17: warning: The right
operand of '*' is a garbage value [core.UndefinedBinaryOperatorResult]
     switch (!!data * *ver) {
    ^ 
A switch statement with only a default should be reduced to an if.

If nvbios_pmuEp() returns 0, via the data variable, the output info
parameter
is not used.  So set info only when data is not 0.

The struct nvbios_pmuE only has the type and data elements.  Since both of
these
are explicitly set, memset is not needed.  So remove it.

Signed-off-by: Tom Rix 
---
  drivers/gpu/drm/nouveau/nvkm/subdev/bios/pmu.c | 5 +
  1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/pmu.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/pmu.c
index b4a308f3cf7b..49e2664a734c 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/pmu.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/pmu.c
@@ -64,12 +64,9 @@ nvbios_pmuEp(struct nvkm_bios *bios, int idx, u8 *ver,
u8
*hdr,
  struct nvbios_pmuE *info)
  {
 u32 data = nvbios_pmuEe(bios, idx, ver, hdr);
-   memset(info, 0x00, sizeof(*info));
-   switch (!!data * *ver) {
-   default:
+   if (data) {
 info->type = nvbios_rd08(bios, data + 0x00);
 info->data = nvbios_rd32(bios, data + 0x02);
-   break;
 }
 return data;
  }

[PATCH] drm/i915/guc: support v69 in parallel to v70

2022-07-16 Thread Daniele Ceraolo Spurio

This patch re-introduces support for GuC v69 in parallel to v70. As this
is a quick fix, v69 has been re-introduced as the single "fallback" guc
version in case v70 is not available on disk. All v69 specific code has
been labeled as such for easy identification, and the same was done for
all v70 functions for which there is a separate v69 version, to avoid
accidentally calling the wrong version via the unlabeled name.

When the fallback mode kicks in, a drm_warn message is printed in dmesg
to warn the user of the required update.

The plan is to follow this up with a more complex rework to allow for
multiple different GuC versions to be supported at the same time.

Fixes: 2584b3549f4c ("drm/i915/guc: Update to GuC version 70.1.1")
Link: https://lists.freedesktop.org/archives/intel-gfx/2022-July/301640.html
Signed-off-by: Daniele Ceraolo Spurio 
Cc: John Harrison 
Cc: Matthew Brost 
Cc: Matt Roper 
Cc: Dave Airlie 
---
 drivers/gpu/drm/i915/gt/intel_context_types.h |  11 +-
 .../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h  |   3 +
 drivers/gpu/drm/i915/gt/uc/intel_guc.h|   5 +
 drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h   |  45 +++
 .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 348 +++---
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c  |  57 ++-
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h  |   7 +
 7 files changed, 419 insertions(+), 57 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h 
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index d2d75d9c0c8d..04eacae1aca5 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -275,10 +275,17 @@ struct intel_context {
u8 child_index;
/** @guc: GuC specific members for parallel submission */
struct {
-   /** @wqi_head: head pointer in work queue */
+   /** @wqi_head: cached head pointer in work queue */
u16 wqi_head;
-   /** @wqi_tail: tail pointer in work queue */
+   /** @wqi_tail: cached tail pointer in work queue */
u16 wqi_tail;
+   /** @wq_head: pointer to the actual head in work queue 
*/
+   u32 *wq_head;
+   /** @wq_tail: pointer to the actual head in work queue 
*/
+   u32 *wq_tail;
+   /** @wq_status: pointer to the status in work queue */
+   u32 *wq_status;
+
/**
 * @parent_page: page in context state (ce->state) used
 * by parent for work queue, process descriptor
diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h 
b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
index 4ef9990ed7f8..29ef8afc8c2e 100644
--- a/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
+++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
@@ -122,6 +122,9 @@ enum intel_guc_action {
INTEL_GUC_ACTION_SCHED_CONTEXT_MODE_DONE = 0x1002,
INTEL_GUC_ACTION_SCHED_ENGINE_MODE_SET = 0x1003,
INTEL_GUC_ACTION_SCHED_ENGINE_MODE_DONE = 0x1004,
+   INTEL_GUC_ACTION_V69_SET_CONTEXT_PRIORITY = 0x1005,
+   INTEL_GUC_ACTION_V69_SET_CONTEXT_EXECUTION_QUANTUM = 0x1006,
+   INTEL_GUC_ACTION_V69_SET_CONTEXT_PREEMPTION_TIMEOUT = 0x1007,
INTEL_GUC_ACTION_CONTEXT_RESET_NOTIFICATION = 0x1008,
INTEL_GUC_ACTION_ENGINE_FAILURE_NOTIFICATION = 0x1009,
INTEL_GUC_ACTION_HOST2GUC_UPDATE_CONTEXT_POLICIES = 0x100B,
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h 
b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
index d0d99f178f2d..a7acffbf15d1 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
@@ -170,6 +170,11 @@ struct intel_guc {
/** @ads_engine_usage_size: size of engine usage in the ADS */
u32 ads_engine_usage_size;
 
+   /** @lrc_desc_pool_v69: object allocated to hold the GuC LRC descriptor 
pool */
+   struct i915_vma *lrc_desc_pool_v69;
+   /** @lrc_desc_pool_vaddr_v69: contents of the GuC LRC descriptor pool */
+   void *lrc_desc_pool_vaddr_v69;
+
/**
 * @context_lookup: used to resolve intel_context from guc_id, if a
 * context is present in this structure it is registered with the GuC
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
index b3c9a9327f76..323b055e5db9 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
@@ -204,6 +204,20 @@ struct guc_wq_item {
u32 fence_id;
 } __packed;
 
+struct guc_process_desc_v69 {
+   u32 stage_id;
+   u64 db_base_addr;
+   u32 head;
+   u32 tail;
+   u32 error_offset;
+   u64 wq_base_addr;
+   u32 wq_size_bytes;
+   u32 wq_status;
+   u32 engine_presence;
+   u32 priority;
+

[PATCH] drm/i915/guc: Check for ct enabled while waiting for response

2022-07-16 Thread Zhanjun Dong

We are seeing error message of "No response for request". Some cases
happened while waiting for response and reset/suspend action was triggered.
In this case, no response is not an error, active requests will be
cancelled.

This patch will handle this condition and change the error message into
debug message.

Signed-off-by: Zhanjun Dong 
---
 drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 27 +--
 1 file changed, 20 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index f01325cd1b62..74194c11234d 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -455,6 +455,7 @@ static int ct_write(struct intel_guc_ct *ct,
 
 /**
  * wait_for_ct_request_update - Wait for CT request state update.
+ * @ct:pointer to CT
  * @req:   pointer to pending request
  * @status:placeholder for status
  *
@@ -467,9 +468,10 @@ static int ct_write(struct intel_guc_ct *ct,
  * *   0 response received (status is valid)
  * *   -ETIMEDOUT no response within hardcoded timeout
  */
-static int wait_for_ct_request_update(struct ct_request *req, u32 *status)
+static int wait_for_ct_request_update(struct intel_guc_ct *ct, struct 
ct_request *req, u32 *status)
 {
int err;
+   bool ct_enabled;
 
/*
 * Fast commands should complete in less than 10us, so sample quickly
@@ -481,12 +483,15 @@ static int wait_for_ct_request_update(struct ct_request 
*req, u32 *status)
 #define GUC_CTB_RESPONSE_TIMEOUT_SHORT_MS 10
 #define GUC_CTB_RESPONSE_TIMEOUT_LONG_MS 1000
 #define done \
-   (FIELD_GET(GUC_HXG_MSG_0_ORIGIN, READ_ONCE(req->status)) == \
+   (!(ct_enabled = intel_guc_ct_enabled(ct)) || \
+FIELD_GET(GUC_HXG_MSG_0_ORIGIN, READ_ONCE(req->status)) == \
 GUC_HXG_ORIGIN_GUC)
err = wait_for_us(done, GUC_CTB_RESPONSE_TIMEOUT_SHORT_MS);
if (err)
err = wait_for(done, GUC_CTB_RESPONSE_TIMEOUT_LONG_MS);
 #undef done
+   if (!ct_enabled)
+   err = -ENODEV;
 
*status = req->status;
return err;
@@ -703,11 +708,18 @@ static int ct_send(struct intel_guc_ct *ct,
 
intel_guc_notify(ct_to_guc(ct));
 
-   err = wait_for_ct_request_update(, status);
+   err = wait_for_ct_request_update(ct, , status);
g2h_release_space(ct, GUC_CTB_HXG_MSG_MAX_LEN);
if (unlikely(err)) {
-   CT_ERROR(ct, "No response for request %#x (fence %u)\n",
-action[0], request.fence);
+   if (err == -ENODEV)
+   /* wait_for_ct_request_update returns -ENODEV on 
reset/suspend in progress.
+* In this case, output is debug rather than error info
+*/
+   CT_DEBUG(ct, "Request %#x (fence %u) cancelled as CTB 
is disabled\n",
+action[0], request.fence);
+   else
+   CT_ERROR(ct, "No response for request %#x (fence %u)\n",
+action[0], request.fence);
goto unlink;
}
 
@@ -771,8 +783,9 @@ int intel_guc_ct_send(struct intel_guc_ct *ct, const u32 
*action, u32 len,
 
ret = ct_send(ct, action, len, response_buf, response_buf_size, 
);
if (unlikely(ret < 0)) {
-   CT_ERROR(ct, "Sending action %#x failed (%pe) status=%#X\n",
-action[0], ERR_PTR(ret), status);
+   if (ret != -ENODEV)
+   CT_ERROR(ct, "Sending action %#x failed (%pe) 
status=%#X\n",
+action[0], ERR_PTR(ret), status);
} else if (unlikely(ret)) {
CT_DEBUG(ct, "send action %#x returned %d (%#x)\n",
 action[0], ret, ret);
-- 
2.36.0

Re: [PATCH 1/2] drm/msm/dpu: use drm_dsc_config instead of msm_display_dsc_config

2022-07-16 Thread Abhinav Kumar





On 7/11/2022 3:04 AM, Dmitry Baryshkov wrote:

There is no need to use the struct msm_display_dsc_config wrapper inside
the dpu driver, use the struct drm_dsc_config directly to pass pps data.

Signed-off-by: Dmitry Baryshkov 


This is a nice cleanup!
Reviewed-by: Abhinav Kumar 

---
  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 25 +++
  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h |  2 +-
  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c  | 74 ++---
  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.h  |  4 +-
  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c |  2 +-
  5 files changed, 54 insertions(+), 53 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index c682d4e02d1b..07b22b7df2e9 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -162,7 +162,7 @@ enum dpu_enc_rc_states {
   * @vsync_event_work: worker to handle vsync event for autorefresh
   * @topology:   topology of the display
   * @idle_timeout: idle timeout duration in milliseconds
- * @dsc:   msm_display_dsc_config pointer, for DSC-enabled 
encoders
+ * @dsc:   drm_dsc_config pointer, for DSC-enabled encoders
   */
  struct dpu_encoder_virt {
struct drm_encoder base;
@@ -208,7 +208,7 @@ struct dpu_encoder_virt {
bool wide_bus_en;
  
  	/* DSC configuration */

-   struct msm_display_dsc_config *dsc;
+   struct drm_dsc_config *dsc;
  };
  
  #define to_dpu_encoder_virt(x) container_of(x, struct dpu_encoder_virt, base)

@@ -1791,12 +1791,12 @@ static void dpu_encoder_vsync_event_work_handler(struct 
kthread_work *work)
  }
  
  static u32

-dpu_encoder_dsc_initial_line_calc(struct msm_display_dsc_config *dsc,
+dpu_encoder_dsc_initial_line_calc(struct drm_dsc_config *dsc,
  u32 enc_ip_width)
  {
int ssm_delay, total_pixels, soft_slice_per_enc;
  
-	soft_slice_per_enc = enc_ip_width / dsc->drm->slice_width;

+   soft_slice_per_enc = enc_ip_width / dsc->slice_width;
  
  	/*

 * minimum number of initial line pixels is a sum of:
@@ -1808,16 +1808,16 @@ dpu_encoder_dsc_initial_line_calc(struct 
msm_display_dsc_config *dsc,
 * 5. 6 additional pixels as the output of the rate buffer is
 *48 bits wide
 */
-   ssm_delay = ((dsc->drm->bits_per_component < 10) ? 84 : 92);
-   total_pixels = ssm_delay * 3 + dsc->drm->initial_xmit_delay + 47;
+   ssm_delay = ((dsc->bits_per_component < 10) ? 84 : 92);
+   total_pixels = ssm_delay * 3 + dsc->initial_xmit_delay + 47;
if (soft_slice_per_enc > 1)
total_pixels += (ssm_delay * 3);
-   return DIV_ROUND_UP(total_pixels, dsc->drm->slice_width);
+   return DIV_ROUND_UP(total_pixels, dsc->slice_width);
  }
  
  static void dpu_encoder_dsc_pipe_cfg(struct dpu_hw_dsc *hw_dsc,

 struct dpu_hw_pingpong *hw_pp,
-struct msm_display_dsc_config *dsc,
+struct drm_dsc_config *dsc,
 u32 common_mode,
 u32 initial_lines)
  {
@@ -1835,7 +1835,7 @@ static void dpu_encoder_dsc_pipe_cfg(struct dpu_hw_dsc 
*hw_dsc,
  }
  
  static void dpu_encoder_prep_dsc(struct dpu_encoder_virt *dpu_enc,

-struct msm_display_dsc_config *dsc)
+struct drm_dsc_config *dsc)
  {
/* coding only for 2LM, 2enc, 1 dsc config */
struct dpu_encoder_phys *enc_master = dpu_enc->cur_master;
@@ -1858,14 +1858,15 @@ static void dpu_encoder_prep_dsc(struct 
dpu_encoder_virt *dpu_enc,
}
}
  
-	pic_width = dsc->drm->pic_width;

+   dsc_common_mode = 0;
+   pic_width = dsc->pic_width;
  
  	dsc_common_mode = DSC_MODE_MULTIPLEX | DSC_MODE_SPLIT_PANEL;

if (enc_master->intf_mode == INTF_MODE_VIDEO)
dsc_common_mode |= DSC_MODE_VIDEO;
  
-	this_frame_slices = pic_width / dsc->drm->slice_width;

-   intf_ip_w = this_frame_slices * dsc->drm->slice_width;
+   this_frame_slices = pic_width / dsc->slice_width;
+   intf_ip_w = this_frame_slices * dsc->slice_width;
  
  	/*

 * dsc merge case: when using 2 encoders for the same stream,
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
index d4d1ecd416e3..9e7236ef34e6 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
@@ -36,7 +36,7 @@ struct msm_display_info {
uint32_t h_tile_instance[MAX_H_TILES_PER_DISPLAY];
bool is_cmd_mode;
bool is_te_using_watchdog_timer;
-   struct msm_display_dsc_config *dsc;
+   struct drm_dsc_config *dsc;
  };
  
  /**

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

Re: [PATCH v2 23/39] drm/i915: dvo_ch7xxx.c: use SPDX header

On Wed, Jul 13, 2022 at 09:12:11AM +0100, Mauro Carvalho Chehab wrote:
> This file is licensed with MIT license. Change its license text
> to use SPDX.
> 
> Signed-off-by: Mauro Carvalho Chehab 

Reviewed-by: Rodrigo Vivi 

> ---
> 
> To avoid mailbombing on a large number of people, only mailing lists were C/C 
> on the cover.
> See [PATCH v2 00/39] at: 
> https://lore.kernel.org/all/cover.1657699522.git.mche...@kernel.org/
> 
>  drivers/gpu/drm/i915/display/dvo_ch7xxx.c | 33 +--
>  1 file changed, 6 insertions(+), 27 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/dvo_ch7xxx.c 
> b/drivers/gpu/drm/i915/display/dvo_ch7xxx.c
> index 1c1fe1f29675..b4d94a565fdb 100644
> --- a/drivers/gpu/drm/i915/display/dvo_ch7xxx.c
> +++ b/drivers/gpu/drm/i915/display/dvo_ch7xxx.c
> @@ -1,30 +1,9 @@
> -/**
> -
> -Copyright © 2006 Dave Airlie
> -
> -All Rights Reserved.
> -
> -Permission is hereby granted, free of charge, to any person obtaining a
> -copy of this software and associated documentation files (the
> -"Software"), to deal in the Software without restriction, including
> -without limitation the rights to use, copy, modify, merge, publish,
> -distribute, sub license, and/or sell copies of the Software, and to
> -permit persons to whom the Software is furnished to do so, subject to
> -the following conditions:
> -
> -The above copyright notice and this permission notice (including the
> -next paragraph) shall be included in all copies or substantial portions
> -of the Software.
> -
> -THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
> -OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> -MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT.
> -IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
> -ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
> -TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
> -SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
> -
> -**/
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright © 2006 Dave Airlie
> + *
> + * All Rights Reserved.
> + */
>  
>  #include "intel_display_types.h"
>  #include "intel_dvo_dev.h"
> -- 
> 2.36.1
>

Re: [PATCH v2 21/39] drm/i915: fix i915_gem_ttm_move.c DOC: markup

On Wed, Jul 13, 2022 at 09:12:09AM +0100, Mauro Carvalho Chehab wrote:
> The doc markup should not end with ":", as it would generate a
> warning on Sphinx while generating the cross-reference tag.
> 
> Signed-off-by: Mauro Carvalho Chehab 

Reviewed-by: Rodrigo Vivi 

> ---
> 
> To avoid mailbombing on a large number of people, only mailing lists were C/C 
> on the cover.
> See [PATCH v2 00/39] at: 
> https://lore.kernel.org/all/cover.1657699522.git.mche...@kernel.org/
> 
>  drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
> index 56217d324a9b..16dd4991d527 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
> @@ -20,7 +20,7 @@
>  #include "gt/intel_migrate.h"
>  
>  /**
> - * DOC: Selftest failure modes for failsafe migration:
> + * DOC: Selftest failure modes for failsafe migration
>   *
>   * For fail_gpu_migration, the gpu blit scheduled is always a clear blit
>   * rather than a copy blit, and then we force the failure paths as if
> -- 
> 2.36.1
>

Re: [Intel-gfx] [PATCH v2 28/39] drm/i915: i915_deps: use a shorter title markup

On Wed, Jul 13, 2022 at 09:12:16AM +0100, Mauro Carvalho Chehab wrote:
> The DOC: tag waits for a one-line short title for the doc
> section. Using multiple lines will produce a weird output.
> So, add a shorter description for the title, while keeping
> the current content below it.
> 
> Signed-off-by: Mauro Carvalho Chehab 

Reviewed-by: Rodrigo Vivi 

> ---
> 
> To avoid mailbombing on a large number of people, only mailing lists were C/C 
> on the cover.
> See [PATCH v2 00/39] at: 
> https://lore.kernel.org/all/cover.1657699522.git.mche...@kernel.org/
> 
>  drivers/gpu/drm/i915/i915_deps.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_deps.c 
> b/drivers/gpu/drm/i915/i915_deps.c
> index 297b8e4e42ee..df6af832e3f2 100644
> --- a/drivers/gpu/drm/i915/i915_deps.c
> +++ b/drivers/gpu/drm/i915/i915_deps.c
> @@ -11,7 +11,9 @@
>  #include "i915_deps.h"
>  
>  /**
> - * DOC: Set of utilities to dynamically collect dependencies into a
> + * DOC: Utilities to collect dependencies for GT migration code
> + *
> + * Set of utilities to dynamically collect dependencies into a
>   * structure which is fed into the GT migration code.
>   *
>   * Once we can do async unbinding, this is also needed to coalesce
> -- 
> 2.36.1
>

Re: [git pull] drm fixes for 5.19-rc7

2022-07-16 Thread pr-tracker-bot

The pull request you sent on Fri, 15 Jul 2022 13:36:17 +1000:

> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2022-07-15

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/fcd1b2b9c7b085e9c200f73c079b322eb8c666f9

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

Re: [PATCH] drm/nouveau/bios: set info only when the return is not 0

2022-07-16 Thread Lyude Paul

On Mon, 2022-07-04 at 17:32 -0400, Lyude Paul wrote:
> Reviewed-by: Lyude Paul 
> 
> Currently on flakey internet in the back of a car, so I probably won't be
> able
> to push this until I get back tonight or early tomorrow

Whoops! Slipped my mind when I got back, but I just remembered it now so I
will go ahead and push :). apologies for the delay!

> 
> On Sat, 2022-07-02 at 11:39 -0400, Tom Rix wrote:
> > clang static analysis reports
> > drivers/gpu/drm/nouveau/nvkm/subdev/bios/pmu.c:68:17: warning: The right
> > operand of '*' is a garbage value [core.UndefinedBinaryOperatorResult]
> >     switch (!!data * *ver) {
> >    ^ 
> > A switch statement with only a default should be reduced to an if.
> > 
> > If nvbios_pmuEp() returns 0, via the data variable, the output info
> > parameter
> > is not used.  So set info only when data is not 0.
> > 
> > The struct nvbios_pmuE only has the type and data elements.  Since both of
> > these
> > are explicitly set, memset is not needed.  So remove it.
> > 
> > Signed-off-by: Tom Rix 
> > ---
> >  drivers/gpu/drm/nouveau/nvkm/subdev/bios/pmu.c | 5 +
> >  1 file changed, 1 insertion(+), 4 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/pmu.c
> > b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/pmu.c
> > index b4a308f3cf7b..49e2664a734c 100644
> > --- a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/pmu.c
> > +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/pmu.c
> > @@ -64,12 +64,9 @@ nvbios_pmuEp(struct nvkm_bios *bios, int idx, u8 *ver,
> > u8
> > *hdr,
> >  struct nvbios_pmuE *info)
> >  {
> > u32 data = nvbios_pmuEe(bios, idx, ver, hdr);
> > -   memset(info, 0x00, sizeof(*info));
> > -   switch (!!data * *ver) {
> > -   default:
> > +   if (data) {
> > info->type = nvbios_rd08(bios, data + 0x00);
> > info->data = nvbios_rd32(bios, data + 0x02);
> > -   break;
> > }
> > return data;
> >  }
> 

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

Re: [Intel-gfx] [PATCH v2 13/39] drm/i915: i915_gpu_error.c: document dump_flags

On Wed, Jul 13, 2022 at 09:12:01AM +0100, Mauro Carvalho Chehab wrote:
> Kernel-doc dump_flags parameter is missing at i915_capture_error_state().
> Document it.
> 
> Fixes: a6f0f9cf330a ("drm/i915/guc: Plumb GuC-capture into gpu_coredump")

Why the fix here and not in the i915_vma_destroy_locked one?
That was also a new introduction. Should we bother with the Fixes
anyway since there were many broken already? And if we do, shouldn't
we add to the others?

But anyway, just trying to understand the differences and reasons,
because the patch is correct:


Reviewed-by: Rodrigo Vivi 



> Signed-off-by: Mauro Carvalho Chehab 
> ---
> 
> To avoid mailbombing on a large number of people, only mailing lists were C/C 
> on the cover.
> See [PATCH v2 00/39] at: 
> https://lore.kernel.org/all/cover.1657699522.git.mche...@kernel.org/
> 
>  drivers/gpu/drm/i915/i915_gpu_error.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
> b/drivers/gpu/drm/i915/i915_gpu_error.c
> index 32e92651ef7c..7790f97b26db 100644
> --- a/drivers/gpu/drm/i915/i915_gpu_error.c
> +++ b/drivers/gpu/drm/i915/i915_gpu_error.c
> @@ -2096,7 +2096,8 @@ void i915_error_state_store(struct i915_gpu_coredump 
> *error)
>   * i915_capture_error_state - capture an error record for later analysis
>   * @gt: intel_gt which originated the hang
>   * @engine_mask: hung engines
> - *
> + * @dump_flags: bitmap flags. When %CORE_DUMP_FLAG_IS_GUC_CAPTURE is used,
> + *   dump engine record registers and execlists.
>   *
>   * Should be called when an error is detected (either a hang or an error
>   * interrupt) to capture error state from the time of the error.  Fills
> -- 
> 2.36.1
>

Re: [Intel-gfx] [PATCH v2 14/39] drm/i915: document kernel-doc trivial issues

On Wed, Jul 13, 2022 at 09:12:02AM +0100, Mauro Carvalho Chehab wrote:
> Fix those kernel-doc warnings:
>   drivers/gpu/drm/i915/intel_region_ttm.c:199: warning: Function 
> parameter or member 'offset' not described in 
> 'intel_region_ttm_resource_alloc'
>   drivers/gpu/drm/i915/i915_vma_resource.h:123: warning: Function 
> parameter or member 'wakeref' not described in 'i915_vma_resource'
>   drivers/gpu/drm/i915/i915_vma.c:1703: warning: Function parameter or 
> member 'vma' not described in 'i915_vma_destroy_locked'
>   drivers/gpu/drm/i915/i915_vma.c:751: warning: Function parameter or 
> member 'ww' not described in 'i915_vma_insert'
>   drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c:159: warning: Function 
> parameter or member 'gt' not described in 'intel_gt_fini_hwconfig'
>   drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c:146: warning: Function 
> parameter or member 'gt' not described in 'intel_gt_init_hwconfig'
>   drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c:113: warning: expecting 
> prototype for intel_guc_hwconfig_init(). Prototype was for 
> guc_hwconfig_init() instead
>   drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c:113: warning: Function 
> parameter or member 'gt' not described in 'guc_hwconfig_init'
>   drivers/gpu/drm/i915/gt/intel_engine_types.h:276: warning: Function 
> parameter or member 'preempt_hang' not described in 'intel_engine_execlists'
> 
> That are due undocumented parameters.
> 
> Signed-off-by: Mauro Carvalho Chehab 

Reviewed-by: Rodrigo Vivi 

> ---
> 
> To avoid mailbombing on a large number of people, only mailing lists were C/C 
> on the cover.
> See [PATCH v2 00/39] at: 
> https://lore.kernel.org/all/cover.1657699522.git.mche...@kernel.org/
> 
>  drivers/gpu/drm/i915/gt/intel_engine_types.h| 1 +
>  drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c | 5 -
>  drivers/gpu/drm/i915/i915_vma.c | 2 ++
>  drivers/gpu/drm/i915/i915_vma_resource.h| 1 +
>  drivers/gpu/drm/i915/intel_region_ttm.c | 3 ++-
>  5 files changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h 
> b/drivers/gpu/drm/i915/gt/intel_engine_types.h
> index 633a7e5dba3b..7c5ad9071fe7 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
> @@ -271,6 +271,7 @@ struct intel_engine_execlists {
>*/
>   u8 csb_head;
>  
> + /* private: Used only in selftests */
>   I915_SELFTEST_DECLARE(struct st_preempt_hang preempt_hang;)
>  };
>  
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c 
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c
> index 4781fccc2687..76f7447302a6 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c
> @@ -103,7 +103,8 @@ static bool has_table(struct drm_i915_private *i915)
>  }
>  
>  /**
> - * intel_guc_hwconfig_init - Initialize the HWConfig
> + * guc_hwconfig_init - Initialize the HWConfig
> + * @gt: GT structure
>   *
>   * Retrieve the HWConfig table from the GuC and save it locally.
>   * It can then be queried on demand by other users later on.
> @@ -138,6 +139,7 @@ static int guc_hwconfig_init(struct intel_gt *gt)
>  
>  /**
>   * intel_gt_init_hwconfig - Initialize the HWConfig if available
> + * @gt: GT structure
>   *
>   * Retrieve the HWConfig table if available on the current platform.
>   */
> @@ -151,6 +153,7 @@ int intel_gt_init_hwconfig(struct intel_gt *gt)
>  
>  /**
>   * intel_gt_fini_hwconfig - Finalize the HWConfig
> + * @gt: GT structure
>   *
>   * Free up the memory allocation holding the table.
>   */
> diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
> index ef3b04c7e153..ddf348c597b0 100644
> --- a/drivers/gpu/drm/i915/i915_vma.c
> +++ b/drivers/gpu/drm/i915/i915_vma.c
> @@ -733,6 +733,7 @@ bool i915_gem_valid_gtt_space(struct i915_vma *vma, 
> unsigned long color)
>  /**
>   * i915_vma_insert - finds a slot for the vma in its address space
>   * @vma: the vma
> + * @ww: An optional struct i915_gem_ww_ctx
>   * @size: requested size in bytes (can be larger than the VMA)
>   * @alignment: required alignment
>   * @flags: mask of PIN_* flags to use
> @@ -1675,6 +1676,7 @@ static void release_references(struct i915_vma *vma, 
> struct intel_gt *gt,
>  /**
>   * i915_vma_destroy_locked - Remove all weak reference to the vma and put
>   * the initial reference.
> + * @vma: VMA to destroy
>   *
>   * This function should be called when it's decided the vma isn't needed
>   * anymore. The caller must assure that it doesn't race with another lookup
> diff --git a/drivers/gpu/drm/i915/i915_vma_resource.h 
> b/drivers/gpu/drm/i915/i915_vma_resource.h
> index 14a0327b2080..a15271d96b7e 100644
> --- a/drivers/gpu/drm/i915/i915_vma_resource.h
> +++ b/drivers/gpu/drm/i915/i915_vma_resource.h
> @@ -49,6 +49,7 @@ struct i915_page_sizes {
>   * @__subtree_last:

Re: [Intel-gfx] [PATCH v3 5/7] drm/i915: Check if the size is too big while creating shmem file

Hi Gwan-gyeong,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on drm-tip/drm-tip]

url:
https://github.com/intel-lab-lkp/linux/commits/Gwan-gyeong-Mun/Fixes-integer-overflow-or-integer-truncation-issues-in-page-lookups-ttm-place-configuration-and-scatterlist-creation/20220714-171019
base:   git://anongit.freedesktop.org/drm/drm-tip drm-tip
config: i386-randconfig-a004 
(https://download.01.org/0day-ci/archive/20220716/202207161058.dmozoqzg-...@intel.com/config)
compiler: clang version 15.0.0 (https://github.com/llvm/llvm-project 
2da550140aa98cf6a3e96417c87f1e89e3a26047)
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# 
https://github.com/intel-lab-lkp/linux/commit/2938379499047baf3189503913f438fda6ea92eb
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review 
Gwan-gyeong-Mun/Fixes-integer-overflow-or-integer-truncation-issues-in-page-lookups-ttm-place-configuration-and-scatterlist-creation/20220714-171019
git checkout 2938379499047baf3189503913f438fda6ea92eb
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 
O=build_dir ARCH=i386 SHELL=/bin/bash drivers/gpu/drm/i915/

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

All warnings (new ones prefixed by >>):

>> drivers/gpu/drm/i915/gem/i915_gem_shmem.c:550:11: warning: result of 
>> comparison of constant 17592186040320 with expression of type 
>> 'resource_size_t' (aka 'unsigned int') is always false 
>> [-Wtautological-constant-out-of-range-compare]
   if (size > MAX_LFS_FILESIZE)
    ^ 
   1 warning generated.


vim +550 drivers/gpu/drm/i915/gem/i915_gem_shmem.c

   534  
   535  static int __create_shmem(struct drm_i915_private *i915,
   536struct drm_gem_object *obj,
   537resource_size_t size)
   538  {
   539  unsigned long flags = VM_NORESERVE;
   540  struct file *filp;
   541  
   542  drm_gem_private_object_init(>drm, obj, size);
   543  
   544  /* XXX: The __shmem_file_setup() function returns -EINVAL if 
size is
   545   * greater than MAX_LFS_FILESIZE.
   546   * To handle the same error as other code that returns -E2BIG 
when
   547   * the size is too large, we add a code that returns -E2BIG 
when the
   548   * size is larger than the size that can be handled.
   549   */
 > 550  if (size > MAX_LFS_FILESIZE)
   551  return -E2BIG;
   552  
   553  if (i915->mm.gemfs)
   554  filp = shmem_file_setup_with_mnt(i915->mm.gemfs, 
"i915", size,
   555   flags);
   556  else
   557  filp = shmem_file_setup("i915", size, flags);
   558  if (IS_ERR(filp))
   559  return PTR_ERR(filp);
   560  
   561  obj->filp = filp;
   562  return 0;
   563  }
   564  

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

[PATCH] drm/msm/dpu: populate wb or intf before reset_intf_cfg

2022-07-16 Thread Abhinav Kumar

dpu_encoder_helper_phys_cleanup() was not populating neither
wb or intf to the intf_cfg before calling the reset_intf_cfg().

This causes the reset of the active bits of wb/intf to be
skipped which is incorrect.

Fix this by populating the relevant wb or intf indices correctly.

Fixes: ae4d721ce100 ("drm/msm/dpu: add an API to reset the encoder related hw 
blocks")
Signed-off-by: Abhinav Kumar 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index c682d4e02d1b..52a626117f70 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -2061,6 +2061,12 @@ void dpu_encoder_helper_phys_cleanup(struct 
dpu_encoder_phys *phys_enc)
 
intf_cfg.stream_sel = 0; /* Don't care value for video mode */
intf_cfg.mode_3d = dpu_encoder_helper_get_3d_blend_mode(phys_enc);
+
+   if (phys_enc->hw_intf)
+   intf_cfg.intf = phys_enc->hw_intf->idx;
+   if (phys_enc->hw_wb)
+   intf_cfg.wb = phys_enc->hw_wb->idx;
+
if (phys_enc->hw_pp->merge_3d)
intf_cfg.merge_3d = phys_enc->hw_pp->merge_3d->idx;
 
-- 
2.7.4

Re: [Freedreno] [PATCH 2/2] drm/msm/dsi: use drm_dsc_config instead of msm_display_dsc_config

2022-07-16 Thread Abhinav Kumar





On 7/11/2022 3:04 AM, Dmitry Baryshkov wrote:

There is no need to use the struct msm_display_dsc_config wrapper inside
the dsi driver, use the struct drm_dsc_config directly to pass pps data.



This change is good but needs to be rebased? See below 


Signed-off-by: Dmitry Baryshkov 
---
  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c |   2 +-
  drivers/gpu/drm/msm/dsi/dsi.c   |   2 +-
  drivers/gpu/drm/msm/dsi/dsi.h   |   2 +-
  drivers/gpu/drm/msm/dsi/dsi_host.c  | 157 +++-
  drivers/gpu/drm/msm/msm_drv.h   |   9 +-
  5 files changed, 79 insertions(+), 93 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index 8016d0a3aade..75ed2b36e1b3 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -585,7 +585,7 @@ static int _dpu_kms_initialize_dsi(struct drm_device *dev,
info.h_tile_instance[info.num_of_h_tiles++] = i;
info.is_cmd_mode = msm_dsi_is_cmd_mode(priv->dsi[i]);
  
-		info.dsc = msm_dsi_get_dsc_config(priv->dsi[i])->drm;

+   info.dsc = msm_dsi_get_dsc_config(priv->dsi[i]);
  
  		if (msm_dsi_is_bonded_dsi(priv->dsi[i]) && priv->dsi[other]) {

rc = msm_dsi_modeset_init(priv->dsi[other], dev, 
encoder);
diff --git a/drivers/gpu/drm/msm/dsi/dsi.c b/drivers/gpu/drm/msm/dsi/dsi.c
index 1625328fa430..8f1ed31b048a 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.c
+++ b/drivers/gpu/drm/msm/dsi/dsi.c
@@ -21,7 +21,7 @@ bool msm_dsi_is_cmd_mode(struct msm_dsi *msm_dsi)
return !(host_flags & MIPI_DSI_MODE_VIDEO);
  }
  
-struct msm_display_dsc_config *msm_dsi_get_dsc_config(struct msm_dsi *msm_dsi)

+struct drm_dsc_config *msm_dsi_get_dsc_config(struct msm_dsi *msm_dsi)
  {
return msm_dsi_host_get_dsc_config(msm_dsi->host);
  }
diff --git a/drivers/gpu/drm/msm/dsi/dsi.h b/drivers/gpu/drm/msm/dsi/dsi.h
index 580a1e6358bf..df46cdda1b43 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.h
+++ b/drivers/gpu/drm/msm/dsi/dsi.h
@@ -154,7 +154,7 @@ int dsi_calc_clk_rate_v2(struct msm_dsi_host *msm_host, 
bool is_bonded_dsi);
  int dsi_calc_clk_rate_6g(struct msm_dsi_host *msm_host, bool is_bonded_dsi);
  void msm_dsi_host_snapshot(struct msm_disp_state *disp_state, struct 
mipi_dsi_host *host);
  void msm_dsi_host_test_pattern_en(struct mipi_dsi_host *host);
-struct msm_display_dsc_config *msm_dsi_host_get_dsc_config(struct 
mipi_dsi_host *host);
+struct drm_dsc_config *msm_dsi_host_get_dsc_config(struct mipi_dsi_host *host);
  
  /* dsi phy */

  struct msm_dsi_phy;
diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index a34078497af1..15e108be1901 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -33,7 +33,7 @@
  
  #define DSI_RESET_TOGGLE_DELAY_MS 20
  
-static int dsi_populate_dsc_params(struct msm_display_dsc_config *dsc);

+static int dsi_populate_dsc_params(struct drm_dsc_config *dsc);
  
  static int dsi_get_version(const void __iomem *base, u32 *major, u32 *minor)

  {
@@ -161,7 +161,7 @@ struct msm_dsi_host {
struct regmap *sfpb;
  
  	struct drm_display_mode *mode;

-   struct msm_display_dsc_config *dsc;
+   struct drm_dsc_config *dsc;
  
  	/* connected device info */

struct device_node *device_node;
@@ -916,7 +916,7 @@ static void dsi_ctrl_config(struct msm_dsi_host *msm_host, 
bool enable,
  
  static void dsi_update_dsc_timing(struct msm_dsi_host *msm_host, bool is_cmd_mode, u32 hdisplay)

  {
-   struct msm_display_dsc_config *dsc = msm_host->dsc;
+   struct drm_dsc_config *dsc = msm_host->dsc;
u32 reg, intf_width, reg_ctrl, reg_ctrl2;
u32 slice_per_intf, total_bytes_per_intf;
u32 pkt_per_line;
@@ -927,24 +927,24 @@ static void dsi_update_dsc_timing(struct msm_dsi_host 
*msm_host, bool is_cmd_mod
 * compress mode registers
 */
intf_width = hdisplay;
-   slice_per_intf = DIV_ROUND_UP(intf_width, dsc->drm->slice_width);
+   slice_per_intf = DIV_ROUND_UP(intf_width, dsc->slice_width);
  
  	/* If slice_per_pkt is greater than slice_per_intf

 * then default to 1. This can happen during partial
 * update.
 */
-   if (slice_per_intf > dsc->drm->slice_count)
-   dsc->drm->slice_count = 1;
+   if (slice_per_intf > dsc->slice_count)
+   dsc->slice_count = 1;
  
-	slice_per_intf = DIV_ROUND_UP(hdisplay, dsc->drm->slice_width);

-   bytes_in_slice = DIV_ROUND_UP(dsc->drm->slice_width * 
dsc->drm->bits_per_pixel, 8);
+   slice_per_intf = DIV_ROUND_UP(hdisplay, dsc->slice_width);
+   bytes_in_slice = DIV_ROUND_UP(dsc->slice_width * dsc->bits_per_pixel, 
8);
  
-	dsc->drm->slice_chunk_size = bytes_in_slice;

+   dsc->slice_chunk_size = bytes_in_slice;
  
  	total_bytes_per_intf = bytes_in_slice * slice_per_intf;
  
  	eol_byte_num = total_bytes_per_intf % 3;

Re: [PATCH 1/2] drm/ttm: fix locking in vmap/vunmap TTM GEM helpers

2022-07-16 Thread Thomas Zimmermann


Hi

Am 15.07.22 um 13:15 schrieb Christian König:

I've stumbled over this while reviewing patches for DMA-buf and it looks
like we completely messed the locking up here.

In general most TTM function should only be called while holding the
appropriate BO resv lock. Without this we could break the internal
buffer object state here.


I remember that I tried to fix this before and you mentioned that it's 
not allowed to hold this lock here. It would possibly deadlock with 
exported buffers. Did this change with Dmitry's rework of the locking 
semantics?


Best regards
Thomas



Only compile tested!

Signed-off-by: Christian König 
Fixes: 43676605f890 drm/ttm: Add vmap/vunmap to TTM and TTM GEM helpers
---
  drivers/gpu/drm/drm_gem_ttm_helper.c | 9 -
  1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_gem_ttm_helper.c 
b/drivers/gpu/drm/drm_gem_ttm_helper.c
index d5962a34c01d..e5fc875990c4 100644
--- a/drivers/gpu/drm/drm_gem_ttm_helper.c
+++ b/drivers/gpu/drm/drm_gem_ttm_helper.c
@@ -64,8 +64,13 @@ int drm_gem_ttm_vmap(struct drm_gem_object *gem,
 struct iosys_map *map)
  {
struct ttm_buffer_object *bo = drm_gem_ttm_of_gem(gem);
+   int ret;
+
+   dma_resv_lock(gem->resv, NULL);
+   ret = ttm_bo_vmap(bo, map);
+   dma_resv_unlock(gem->resv);
  
-	return ttm_bo_vmap(bo, map);

+   return ret;
  }
  EXPORT_SYMBOL(drm_gem_ttm_vmap);
  
@@ -82,7 +87,9 @@ void drm_gem_ttm_vunmap(struct drm_gem_object *gem,

  {
struct ttm_buffer_object *bo = drm_gem_ttm_of_gem(gem);
  
+	dma_resv_lock(gem->resv, NULL);

ttm_bo_vunmap(bo, map);
+   dma_resv_unlock(gem->resv);
  }
  EXPORT_SYMBOL(drm_gem_ttm_vunmap);
  


--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev


OpenPGP_signature
Description: OpenPGP digital signature

Re: [PATCH v5 13/13] video: backlight: mt6370: Add MediaTek MT6370 support

2022-07-16 Thread Daniel Thompson

On Fri, Jul 15, 2022 at 02:38:45PM +0200, AngeloGioacchino Del Regno wrote:
> Il 15/07/22 13:26, ChiaEn Wu ha scritto:
> > From: ChiaEn Wu 
> >
> > MediaTek MT6370 is a SubPMIC consisting of a single cell battery charger
> > with ADC monitoring, RGB LEDs, dual channel flashlight, WLED backlight
> > driver, display bias voltage supply, one general purpose LDO, and the
> > USB Type-C & PD controller complies with the latest USB Type-C and PD
> > standards.
> >
> > This adds support for MediaTek MT6370 Backlight driver. It's commonly used
> > to drive the display WLED. There are 4 channels inside, and each channel
> > supports up to 30mA of current capability with 2048 current steps in
> > exponential or linear mapping curves.
> >
> > Signed-off-by: ChiaEn Wu 
>
> Hello ChiaEn,
>
> I propose to move this one to drivers/leds (or drivers/pwm) and, instead of
> registering a backlight device, register a PWM device.
>
> This way you will be able to reuse the generic backlight-pwm driver, as you'd
> be feeding the PWM device exposed by this driver to the generic one: this will
> most importantly make it easy to chain it with MTK_DISP_PWM (mtk-pwm-disp)
> with a devicetree that looks like...

Out of interest, does MT6370 have the same structure for backlights as the prior
systems using mtk-pwm-disp or was mtk-pwm-disp simply a normal(-ish) PWM
that relied on something on the board for all the constant current
driver hardware?

>
>   pwmleds-disp {
>   compatible = "pwm-leds";
>
>   disp_led: disp-pwm {
>   label = "backlight-pwm";
>   pwms = < 0 50>;
>   max-brightness = <1024>;
>   };
>   };
>
>   backlight_lcd0: backlight {
>   compatible = "led-backlight";
>   leds = <_led>, <_bl_led>;
>   default-brightness-level = <300>;
>   };

I think this proposal has to start with the devicetree bindings rather
than the driver. Instead I think the question is: does this proposal
result in DT bindings that better describe the underlying hardware?

This device has lots of backlight centric features (OCP, OVP, single
control with multiple outputs, exponential curves, etc) and its not
clear where they would fit into the "PWM" bindings.

Come to think of it I'm also a little worried also about the whole linear
versus exponential curve thing since I thought LED drivers were required
to use exponential curves.

Daniel.

[PATCH v9 13/14] tools: add hmm gup tests for device coherent type

The intention is to test hmm device coherent type under different get
user pages paths. Also, test gup with FOLL_LONGTERM flag set in
device coherent pages. These pages should get migrated back to system
memory.

Signed-off-by: Alex Sierra 
Reviewed-by: Alistair Popple 
---
 tools/testing/selftests/vm/hmm-tests.c | 110 +
 1 file changed, 110 insertions(+)

diff --git a/tools/testing/selftests/vm/hmm-tests.c 
b/tools/testing/selftests/vm/hmm-tests.c
index 4b547188ec40..bb38b9777610 100644
--- a/tools/testing/selftests/vm/hmm-tests.c
+++ b/tools/testing/selftests/vm/hmm-tests.c
@@ -36,6 +36,7 @@
  * in the usual include/uapi/... directory.
  */
 #include "../../../../lib/test_hmm_uapi.h"
+#include "../../../../mm/gup_test.h"
 
 struct hmm_buffer {
void*ptr;
@@ -59,6 +60,9 @@ enum {
 #define NTIMES 10
 
 #define ALIGN(x, a) (((x) + (a - 1)) & (~((a) - 1)))
+/* Just the flags we need, copied from mm.h: */
+#define FOLL_WRITE 0x01/* check pte is writable */
+#define FOLL_LONGTERM   0x1 /* mapping lifetime is indefinite */
 
 FIXTURE(hmm)
 {
@@ -1764,4 +1768,110 @@ TEST_F(hmm, exclusive_cow)
hmm_buffer_free(buffer);
 }
 
+static int gup_test_exec(int gup_fd, unsigned long addr, int cmd,
+int npages, int size, int flags)
+{
+   struct gup_test gup = {
+   .nr_pages_per_call  = npages,
+   .addr   = addr,
+   .gup_flags  = FOLL_WRITE | flags,
+   .size   = size,
+   };
+
+   if (ioctl(gup_fd, cmd, )) {
+   perror("ioctl on error\n");
+   return errno;
+   }
+
+   return 0;
+}
+
+/*
+ * Test get user device pages through gup_test. Setting PIN_LONGTERM flag.
+ * This should trigger a migration back to system memory for both, private
+ * and coherent type pages.
+ * This test makes use of gup_test module. Make sure GUP_TEST_CONFIG is added
+ * to your configuration before you run it.
+ */
+TEST_F(hmm, hmm_gup_test)
+{
+   struct hmm_buffer *buffer;
+   int gup_fd;
+   unsigned long npages;
+   unsigned long size;
+   unsigned long i;
+   int *ptr;
+   int ret;
+   unsigned char *m;
+
+   gup_fd = open("/sys/kernel/debug/gup_test", O_RDWR);
+   if (gup_fd == -1)
+   SKIP(return, "Skipping test, could not find gup_test driver");
+
+   npages = 4;
+   size = npages << self->page_shift;
+
+   buffer = malloc(sizeof(*buffer));
+   ASSERT_NE(buffer, NULL);
+
+   buffer->fd = -1;
+   buffer->size = size;
+   buffer->mirror = malloc(size);
+   ASSERT_NE(buffer->mirror, NULL);
+
+   buffer->ptr = mmap(NULL, size,
+  PROT_READ | PROT_WRITE,
+  MAP_PRIVATE | MAP_ANONYMOUS,
+  buffer->fd, 0);
+   ASSERT_NE(buffer->ptr, MAP_FAILED);
+
+   /* Initialize buffer in system memory. */
+   for (i = 0, ptr = buffer->ptr; i < size / sizeof(*ptr); ++i)
+   ptr[i] = i;
+
+   /* Migrate memory to device. */
+   ret = hmm_migrate_sys_to_dev(self->fd, buffer, npages);
+   ASSERT_EQ(ret, 0);
+   ASSERT_EQ(buffer->cpages, npages);
+   /* Check what the device read. */
+   for (i = 0, ptr = buffer->mirror; i < size / sizeof(*ptr); ++i)
+   ASSERT_EQ(ptr[i], i);
+
+   ASSERT_EQ(gup_test_exec(gup_fd,
+   (unsigned long)buffer->ptr,
+   GUP_BASIC_TEST, 1, self->page_size, 0), 0);
+   ASSERT_EQ(gup_test_exec(gup_fd,
+   (unsigned long)buffer->ptr + 1 * 
self->page_size,
+   GUP_FAST_BENCHMARK, 1, self->page_size, 0), 0);
+   ASSERT_EQ(gup_test_exec(gup_fd,
+   (unsigned long)buffer->ptr + 2 * 
self->page_size,
+   PIN_FAST_BENCHMARK, 1, self->page_size, 
FOLL_LONGTERM), 0);
+   ASSERT_EQ(gup_test_exec(gup_fd,
+   (unsigned long)buffer->ptr + 3 * 
self->page_size,
+   PIN_LONGTERM_BENCHMARK, 1, self->page_size, 0), 
0);
+
+   /* Take snapshot to CPU pagetables */
+   ret = hmm_dmirror_cmd(self->fd, HMM_DMIRROR_SNAPSHOT, buffer, npages);
+   ASSERT_EQ(ret, 0);
+   ASSERT_EQ(buffer->cpages, npages);
+   m = buffer->mirror;
+   if (hmm_is_coherent_type(variant->device_number)) {
+   ASSERT_EQ(HMM_DMIRROR_PROT_DEV_COHERENT_LOCAL | 
HMM_DMIRROR_PROT_WRITE, m[0]);
+   ASSERT_EQ(HMM_DMIRROR_PROT_DEV_COHERENT_LOCAL | 
HMM_DMIRROR_PROT_WRITE, m[1]);
+   } else {
+   ASSERT_EQ(HMM_DMIRROR_PROT_WRITE, m[0]);
+   ASSERT_EQ(HMM_DMIRROR_PROT_WRITE, m[1]);
+   }
+   ASSERT_EQ(HMM_DMIRROR_PROT_WRITE, m[2]);
+   ASSERT_EQ(HMM_DMIRROR_PROT_WRITE, m[3]);
+   /*
+* Check again the content

Re: [PATCH v2 17/39] drm/i915: skl_scaler: fix return value kernel-doc markup

On Wed, Jul 13, 2022 at 09:12:05AM +0100, Mauro Carvalho Chehab wrote:
> The way it is, it produces this warning:
> 
>   Documentation/gpu/i915:150: 
> ./drivers/gpu/drm/i915/display/skl_scaler.c:213: WARNING: Block quote ends 
> without a blank line; unexpected unindent.
> 
> Use list markups to suppress the warning.
> 
> Signed-off-by: Mauro Carvalho Chehab 

Reviewed-by: Rodrigo Vivi 

> ---
> 
> To avoid mailbombing on a large number of people, only mailing lists were C/C 
> on the cover.
> See [PATCH v2 00/39] at: 
> https://lore.kernel.org/all/cover.1657699522.git.mche...@kernel.org/
> 
>  drivers/gpu/drm/i915/display/skl_scaler.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/skl_scaler.c 
> b/drivers/gpu/drm/i915/display/skl_scaler.c
> index 4092679be21e..59099f793d3e 100644
> --- a/drivers/gpu/drm/i915/display/skl_scaler.c
> +++ b/drivers/gpu/drm/i915/display/skl_scaler.c
> @@ -208,9 +208,9 @@ int skl_update_scaler_crtc(struct intel_crtc_state 
> *crtc_state)
>   * @crtc_state: crtc's scaler state
>   * @plane_state: atomic plane state to update
>   *
> - * Return
> - * 0 - scaler_usage updated successfully
> - *error - requested scaling cannot be supported or other error condition
> + * Return:
> + * * 0 - scaler_usage updated successfully
> + * * error - requested scaling cannot be supported or other error condition
>   */
>  int skl_update_scaler_plane(struct intel_crtc_state *crtc_state,
>   struct intel_plane_state *plane_state)
> -- 
> 2.36.1
>

Re: [PATCH v2 24/39] drm/i915: dvo_sil164.c: use SPDX header

On Wed, Jul 13, 2022 at 09:12:12AM +0100, Mauro Carvalho Chehab wrote:
> This file is licensed with MIT license.   Change its license text
> to use SPDX.
> 
> Signed-off-by: Mauro Carvalho Chehab 

Reviewed-by: Rodrigo Vivi 

> ---
> 
> To avoid mailbombing on a large number of people, only mailing lists were C/C 
> on the cover.
> See [PATCH v2 00/39] at: 
> https://lore.kernel.org/all/cover.1657699522.git.mche...@kernel.org/
> 
>  drivers/gpu/drm/i915/display/dvo_sil164.c | 32 +--
>  1 file changed, 6 insertions(+), 26 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/dvo_sil164.c 
> b/drivers/gpu/drm/i915/display/dvo_sil164.c
> index 0dfa0a0209ff..12974f7c9dc1 100644
> --- a/drivers/gpu/drm/i915/display/dvo_sil164.c
> +++ b/drivers/gpu/drm/i915/display/dvo_sil164.c
> @@ -1,30 +1,10 @@
> -/**
> +// SPDX-License-Identifier: MIT
>  
> -Copyright © 2006 Dave Airlie
> -
> -All Rights Reserved.
> -
> -Permission is hereby granted, free of charge, to any person obtaining a
> -copy of this software and associated documentation files (the
> -"Software"), to deal in the Software without restriction, including
> -without limitation the rights to use, copy, modify, merge, publish,
> -distribute, sub license, and/or sell copies of the Software, and to
> -permit persons to whom the Software is furnished to do so, subject to
> -the following conditions:
> -
> -The above copyright notice and this permission notice (including the
> -next paragraph) shall be included in all copies or substantial portions
> -of the Software.
> -
> -THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
> -OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> -MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT.
> -IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
> -ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
> -TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
> -SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
> -
> -**/
> +/*
> + * Copyright © 2006 Dave Airlie
> + *
> + * All Rights Reserved.
> + */
>  
>  #include "intel_display_types.h"
>  #include "intel_dvo_dev.h"
> -- 
> 2.36.1
>

Re: [PATCH v5 12/13] leds: flashlight: mt6370: Add MediaTek MT6370 flashlight support

On Fri, Jul 15, 2022 at 1:29 PM ChiaEn Wu  wrote:

> The MediaTek MT6370 is a highly-integrated smart power management IC,
> whichincludes a single cell Li-Ion/Li-Polymer switching battery

which includes

> charger, a USB Type-C & Power Delivery (PD) controller, dual Flash
> LED current sources, a RGB LED driver, a backlight WLED driver,
> a display bias driver and a general LDO for portable devices.
>
> The Flash LED in MT6370 has 2 channel and support torch/strobe mode.

channels

> The commit add the support of MT6370 FLASH LED.

Add the

...

> +#define MT6370_FLCSEN_MASK_ALL (BIT(0) | BIT(1))

GENMASK()

...

> +   for (i = 0; i < MT6370_MAX_LEDS; i++) {
> +   ret = regmap_update_bits(priv->regmap,
> +   MT6370_REG_FLEDISTRB(i),
> +   MT6370_ISTROBE_MASK, 
> flevel[i]);
> +   if (ret)
> +   return ret;
> +   }
> +   } else {

> +   ret = regmap_update_bits(priv->regmap,
> +MT6370_REG_FLEDISTRB(led->led_no),
> +MT6370_ISTROBE_MASK, val);
> +   }
> +   return ret;

return regmap_update_bits(...);
  }

  return 0;

...

> +   /*
> +* If the flash need to be on,

needs

> +* config the flash current ramping up to the setting value.
> +* Else, always recover back to the minimum one.
> +*/

...

> +   /* For the flash turn on/off, need to wait HW ramping up/down time

to turn

> +* 5ms/500us to prevent the unexpected problem.
> +*/

Wrong multi-line comment style.

> +

No need for a blank line.

> +   if (!prev && curr)
> +   usleep_range(5000, 6000);
> +   else if (prev && !curr)
> +   udelay(500);

...

> +static int mt6370_led_register(struct device *parent, struct mt6370_led *led,
> +   struct led_init_data *init_data)
> +{
> +   struct v4l2_flash_config v4l2_config = {0};
> +   int ret;
> +
> +   ret = devm_led_classdev_flash_register_ext(parent, >flash,
> +  init_data);
> +   if (ret) {
> +   dev_err(parent, "Couldn't register flash %d\n", led->led_no);
> +   return ret;

return dev_err_probe() here and everywhere where it is about probe stage.

> +   }
> +
> +   mt6370_init_v4l2_flash_config(led, _config);
> +   led->v4l2_flash = v4l2_flash_init(parent, init_data->fwnode,
> + >flash, _flash_ops,
> + _config);
> +   if (IS_ERR(led->v4l2_flash)) {
> +   dev_err(parent, "Failed to register %d v4l2 sd\n", 
> led->led_no);
> +   return PTR_ERR(led->v4l2_flash);
> +   }
> +
> +   return 0;
> +}

...

> +   num = fwnode_property_count_u32(init_data->fwnode, "led-sources");
> +   if (num < 1 || num > MT6370_MAX_LEDS) {
> +   dev_err(priv->dev,
> +   "Not specified or wrong number of led-sources\n");
> +   return -EINVAL;

Ditto.

> +   }

...

> +   ret = fwnode_property_read_u32(init_data->fwnode, "led-max-microamp",
> +  );

One line?

...

> +   val = clamp_align(val, MT6370_STRBTO_MIN_US, 
> MT6370_STRBTO_MAX_US,
> + MT6370_STRBTO_STEP_US);

I would name it mt6370_clamp() to avoid potential collision in the
global namespace in the future.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v5 11/13] leds: mt6370: Add MediaTek MT6370 current sink type LED Indicator support

On Fri, Jul 15, 2022 at 1:29 PM ChiaEn Wu  wrote:
>
> From: ChiYuan Huang 
>
> The MediaTek MT6370 is a highly-integrated smart power management IC,
> which includes a single cell Li-Ion/Li-Polymer switching battery
> charger, a USB Type-C & Power Delivery (PD) controller, dual
> Flash LED current sources, a RGB LED driver, a backlight WLED driver,
> a display bias driver and a general LDO for portable devices.
>
> In MediaTek MT6370, there are four channel current-sink RGB LEDs that
> support hardware pattern for constant current, PWM, and breath mode.
> Isink4 channel can also be used as a CHG_VIN power good indicator.

...

> + This driver can also be built as a module. If so the module

so, the

> + will be called "leds-mt6370.ko".

No ".ko".

Why did you ignore these comments? Please go and fix _everywhere_ in
your series.
It's basically the rule of thumb, if the reviewer gives a comment
against an occurrence of something, go through entire series and check
if there are other places like commented one and address them all.

...

> + * Author: Alice Chen 

Strange, the commit message doesn't have a corresponding SoB, why?

...

> +#define MT6370_PWM_DUTY31
> +#define MT6372_PMW_DUTY255

Looks like these are limits by hardware?
Check with the datasheet if (BIT(x) - 1) makes more sense here.

...

> +   switch (led_no) {
> +   case MT6370_LED_ISNK1:
> +   sel_field = F_LED1_DUTY;
> +   break;
> +   case MT6370_LED_ISNK2:
> +   sel_field = F_LED2_DUTY;
> +   break;
> +   case MT6370_LED_ISNK3:
> +   sel_field = F_LED3_DUTY;
> +   break;
> +   default:
> +   sel_field = F_LED4_DUTY;

Missed break;

> +   }

...

> +   switch (led_no) {
> +   case MT6370_LED_ISNK1:
> +   sel_field = F_LED1_FREQ;
> +   break;
> +   case MT6370_LED_ISNK2:
> +   sel_field = F_LED2_FREQ;
> +   break;
> +   case MT6370_LED_ISNK3:
> +   sel_field = F_LED3_FREQ;
> +   break;
> +   default:
> +   sel_field = F_LED4_FREQ;

Ditto.

> +   }

...

> +   switch (led_no) {
> +   case MT6370_LED_ISNK1:
> +   case MT6370_LED_ISNK2:
> +   case MT6370_LED_ISNK3:
> +   *base = MT6370_REG_RGB1_TR + led_no * 3;
> +   break;
> +   default:
> +   *base = MT6370_REG_RGB_CHRIND_TR;

Ditto.
It seems you dropped them for all switch-cases. It's not goot, please
restore them back.

> +   }

...

> +   u8 val[P_MAX_PATTERNS / 2] = {0};

{ } should suffice


> +   /*
> +* Pattern list
> +* tr1: byte 0, b'[7: 4]
> +* tr2: byte 0, b'[3: 0]
> +* tf1: byte 1, b'[7: 4]
> +* tf2: byte 1, b'[3: 0]
> +* ton: byte 2, b'[7: 4]
> +* toff: byte 2, b'[3: 0]
> +*/
> +   for (i = 0; i < P_MAX_PATTERNS; i++) {
> +   curr = pattern + i;
> +
> +   sel_range = i == P_LED_TOFF ? R_LED_TOFF : R_LED_TRFON;
> +
> +   linear_range_get_selector_within(priv->ranges + sel_range,
> +curr->delta_t, );
> +
> +   val[i / 2] |= sel << (4 * ((i + 1) % 2));
> +   }
> +
> +   memcpy(pattern_val, val, 3);
> +   return 0;
> +}

...

> +out:

out_unlock:

> +   mutex_unlock(>lock);
> +
> +   return ret;

...

> +out:

Ditto. And so on.

> +   mutex_unlock(>lock);
> +
> +   return ret;

...

> +   sub_led = devm_kzalloc(priv->dev,
> +  sizeof(*sub_led) * MC_CHANNEL_NUM,
> +  GFP_KERNEL);

NIH devm_kcalloc(). Also check if you really need zeroed data.

> +   if (!sub_led)
> +   return -ENOMEM;

...

> +   ret = fwnode_property_read_u32(child, "color", 
> );
> +   if (ret) {
> +   dev_err(priv->dev,
> +   "led %d, no color specified\n",
> +   led->index);
> +   return ret;

return dev_err_probe(...) ; ?

Ditto for many places in your entire series.

> +   }

...

> +   priv = devm_kzalloc(>dev,
> +   struct_size(priv, leds, count), GFP_KERNEL);

At least one parameter can be placed on the previous line.

> +   if (!priv)
> +   return -ENOMEM;

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v14 05/10] drm/mediatek: Add MT8195 Embedded DisplayPort driver

Hi Bo-Chen,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on drm/drm-next pza/reset/next linus/master v5.19-rc6 
next-20220715]
[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/Bo-Chen-Chen/drm-mediatek-Add-MT8195-DisplayPort-driver/20220712-191341
base:   git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
config: arm-allyesconfig 
(https://download.01.org/0day-ci/archive/20220716/202207160102.zyueii7s-...@intel.com/config)
compiler: arm-linux-gnueabi-gcc (GCC) 12.1.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# 
https://github.com/intel-lab-lkp/linux/commit/a3869f524e16c38015e0f124c6597927fc6d26b0
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review 
Bo-Chen-Chen/drm-mediatek-Add-MT8195-DisplayPort-driver/20220712-191341
git checkout a3869f524e16c38015e0f124c6597927fc6d26b0
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1 
O=build_dir ARCH=arm SHELL=/bin/bash drivers/gpu/drm/mediatek/ 
drivers/pci/controller/dwc/

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

All warnings (new ones prefixed by >>):

   drivers/gpu/drm/mediatek/mtk_dp.c: In function 'mtk_dp_train_tps_1':
>> drivers/gpu/drm/mediatek/mtk_dp.c:1092:12: warning: variable 'val' set but 
>> not used [-Wunused-but-set-variable]
1092 | u8 val;
 |^~~
   drivers/gpu/drm/mediatek/mtk_dp.c: In function 
'mtk_dp_bridge_atomic_get_output_bus_fmts':
   drivers/gpu/drm/mediatek/mtk_dp.c:1865:26: error: 'MEDIA_BUS_FMT_FIXED' 
undeclared (first use in this function)
1865 | output_fmts[0] = MEDIA_BUS_FMT_FIXED;
 |  ^~~
   drivers/gpu/drm/mediatek/mtk_dp.c:1865:26: note: each undeclared identifier 
is reported only once for each function it appears in
   drivers/gpu/drm/mediatek/mtk_dp.c: At top level:
   drivers/gpu/drm/mediatek/mtk_dp.c:1870:9: error: 'MEDIA_BUS_FMT_RGB888_1X24' 
undeclared here (not in a function)
1870 | MEDIA_BUS_FMT_RGB888_1X24,
 | ^
   drivers/gpu/drm/mediatek/mtk_dp.c:1871:9: error: 'MEDIA_BUS_FMT_YUV8_1X24' 
undeclared here (not in a function)
1871 | MEDIA_BUS_FMT_YUV8_1X24,
 | ^~~
   drivers/gpu/drm/mediatek/mtk_dp.c:1872:9: error: 'MEDIA_BUS_FMT_YUYV8_1X16' 
undeclared here (not in a function)
1872 | MEDIA_BUS_FMT_YUYV8_1X16,
 | ^~~~


vim +/val +1092 drivers/gpu/drm/mediatek/mtk_dp.c

  1087  
  1088  static int mtk_dp_train_tps_1(struct mtk_dp *mtk_dp, u8 
target_lane_count,
  1089int *iteration_count, u8 *lane_adjust,
  1090int *status_control, u8 *prev_lane_adjust)
  1091  {
> 1092  u8 val;
  1093  u8 link_status[DP_LINK_STATUS_SIZE] = {};
  1094  
  1095  mtk_dp_training_set_scramble(mtk_dp, false);
  1096  
  1097  if (*status_control == 0) {
  1098  mtk_dp_train_set_pattern(mtk_dp, 1);
  1099  val = DP_LINK_SCRAMBLING_DISABLE |
  1100  DP_TRAINING_PATTERN_1;
  1101  drm_dp_dpcd_writeb(_dp->aux,
  1102 DP_TRAINING_PATTERN_SET,
  1103 DP_LINK_SCRAMBLING_DISABLE |
  1104 DP_TRAINING_PATTERN_1);
  1105  drm_dp_dpcd_read(_dp->aux,
  1106   DP_ADJUST_REQUEST_LANE0_1,
  1107   lane_adjust,
  1108   sizeof(*lane_adjust) * 2);
  1109  
  1110  mtk_dp_train_update_swing_pre(mtk_dp,
  target_lane_count, 
lane_adjust);
  1112  *status_control = 1;
  1113  (*iteration_count)++;
  1114  }
  1115  
  1116  drm_dp_link_train_clock_recovery_delay(_dp->aux, 
mtk_dp->rx_cap);
  1117  drm_dp_dpcd_read_link_status(_dp->aux, link_status);
  1118  
  1119  if (drm_dp_clock_recovery_ok(link_status,
  1120   target_lane_count)) {
  1121  mtk_dp->train_info.cr_done = true;
  1122  *iteration_count = 1;
  1123

Re: [PATCH 2/3] drm/komeda - At init write GCU control block to handle already on DPU

2022-07-16 Thread Carsten Haitzler





On 7/8/22 17:07, Liviu Dudau wrote:

On Mon, Jun 06, 2022 at 12:47:13PM +0100, carsten.haitz...@foss.arm.com wrote:

From: Carsten Haitzler 

If something has already set up the DPU before the komeda driver comes
up, it will fail to init because it was just writing to the SRST bit in
the GCU control register and ignoring others. This resulted in TBU
bringup stalling and init failing. By writing completely we also  set the
mode back to 0 (inactive) too and thus TBU bringup works.


This is a rather large hammer, tbh. I would like to see if there is a better 
way of
handling the handover from EFIFB that this patch is trying to fix, but I lack an
usable plaform for that. It will generate a flicker at module load time, but if 
users
of Morello are happy with that, then


Just FYI - it'll flicker anyway as the PHY is external and gets 
re-initted etc. anyway... This also happens to handle the situation 
where something goes wrong and you have an already initted komeda sue to 
a previous module load (and it's still alive and working due to an 
unclean shutdown). It'll allow you to load the module again :) So it's 
multi-useful.



Acked-by: Liviu Dudau 

Best regards,
Liviu



Signed-off-by: Carsten Haitzler 
---
  drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c 
b/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
index 00fa56c29b3e..39618c1a4c81 100644
--- a/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
+++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
@@ -309,8 +309,7 @@ static int d71_reset(struct d71_dev *d71)
u32 __iomem *gcu = d71->gcu_addr;
int ret;
  
-	malidp_write32_mask(gcu, BLK_CONTROL,

-   GCU_CONTROL_SRST, GCU_CONTROL_SRST);
+   malidp_write32(gcu, BLK_CONTROL, GCU_CONTROL_SRST);
  
  	ret = dp_wait_cond(!(malidp_read32(gcu, BLK_CONTROL) & GCU_CONTROL_SRST),

   100, 1000, 1);
--
2.32.0

[PATCH v9 04/14] mm: handling Non-LRU pages returned by vm_normal_pages

With DEVICE_COHERENT, we'll soon have vm_normal_pages() return
device-managed anonymous pages that are not LRU pages. Although they
behave like normal pages for purposes of mapping in CPU page, and for
COW. They do not support LRU lists, NUMA migration or THP.

Callers to follow_page() currently don't expect ZONE_DEVICE pages,
however, with DEVICE_COHERENT we might now return ZONE_DEVICE. Check
for ZONE_DEVICE pages in applicable users of follow_page() as well.

Signed-off-by: Alex Sierra 
Acked-by: Felix Kuehling  (v2)
Reviewed-by: Alistair Popple  (v6)
---
 fs/proc/task_mmu.c |  2 +-
 mm/huge_memory.c   |  2 +-
 mm/khugepaged.c|  9 ++---
 mm/ksm.c   |  6 +++---
 mm/madvise.c   |  4 ++--
 mm/memory.c| 10 +-
 mm/mempolicy.c |  2 +-
 mm/migrate.c   |  4 ++--
 mm/mlock.c |  2 +-
 mm/mprotect.c  |  2 +-
 10 files changed, 27 insertions(+), 16 deletions(-)

diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index 2d04e3470d4c..2dd8c8a66924 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -1792,7 +1792,7 @@ static struct page *can_gather_numa_stats(pte_t pte, 
struct vm_area_struct *vma,
return NULL;
 
page = vm_normal_page(vma, addr, pte);
-   if (!page)
+   if (!page || is_zone_device_page(page))
return NULL;
 
if (PageReserved(page))
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 834f288b3769..c47e95b02244 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -2910,7 +2910,7 @@ static int split_huge_pages_pid(int pid, unsigned long 
vaddr_start,
 
if (IS_ERR(page))
continue;
-   if (!page)
+   if (!page || is_zone_device_page(page))
continue;
 
if (!is_transparent_hugepage(page))
diff --git a/mm/khugepaged.c b/mm/khugepaged.c
index 16be62d493cd..671ac7800e53 100644
--- a/mm/khugepaged.c
+++ b/mm/khugepaged.c
@@ -618,7 +618,7 @@ static int __collapse_huge_page_isolate(struct 
vm_area_struct *vma,
goto out;
}
page = vm_normal_page(vma, address, pteval);
-   if (unlikely(!page)) {
+   if (unlikely(!page) || unlikely(is_zone_device_page(page))) {
result = SCAN_PAGE_NULL;
goto out;
}
@@ -1267,7 +1267,7 @@ static int khugepaged_scan_pmd(struct mm_struct *mm,
writable = true;
 
page = vm_normal_page(vma, _address, pteval);
-   if (unlikely(!page)) {
+   if (unlikely(!page) || unlikely(is_zone_device_page(page))) {
result = SCAN_PAGE_NULL;
goto out_unmap;
}
@@ -1479,7 +1479,8 @@ void collapse_pte_mapped_thp(struct mm_struct *mm, 
unsigned long addr)
goto abort;
 
page = vm_normal_page(vma, addr, *pte);
-
+   if (WARN_ON_ONCE(page && is_zone_device_page(page)))
+   page = NULL;
/*
 * Note that uprobe, debugger, or MAP_PRIVATE may change the
 * page table, but the new page will not be a subpage of hpage.
@@ -1497,6 +1498,8 @@ void collapse_pte_mapped_thp(struct mm_struct *mm, 
unsigned long addr)
if (pte_none(*pte))
continue;
page = vm_normal_page(vma, addr, *pte);
+   if (WARN_ON_ONCE(page && is_zone_device_page(page)))
+   goto abort;
page_remove_rmap(page, vma, false);
}
 
diff --git a/mm/ksm.c b/mm/ksm.c
index 54f78c9eecae..831b18a7a50b 100644
--- a/mm/ksm.c
+++ b/mm/ksm.c
@@ -475,7 +475,7 @@ static int break_ksm(struct vm_area_struct *vma, unsigned 
long addr)
cond_resched();
page = follow_page(vma, addr,
FOLL_GET | FOLL_MIGRATION | FOLL_REMOTE);
-   if (IS_ERR_OR_NULL(page))
+   if (IS_ERR_OR_NULL(page) || is_zone_device_page(page))
break;
if (PageKsm(page))
ret = handle_mm_fault(vma, addr,
@@ -560,7 +560,7 @@ static struct page *get_mergeable_page(struct rmap_item 
*rmap_item)
goto out;
 
page = follow_page(vma, addr, FOLL_GET);
-   if (IS_ERR_OR_NULL(page))
+   if (IS_ERR_OR_NULL(page) || is_zone_device_page(page))
goto out;
if (PageAnon(page)) {
flush_anon_page(vma, page, addr);
@@ -2308,7 +2308,7 @@ static struct rmap_item *scan_get_next_rmap_item(struct 
page **page)
if (ksm_test_exit(mm))
break;
*page = follow_page(vma, ksm_scan.address, FOLL_GET);
-   if (IS_ERR_OR_NULL(*page)) {
+   if (IS_ERR_OR_NULL(*page) ||

Re: [PATCH v2 27/39] drm/i915: i915_scatterlist.h: fix some kernel-doc markups

On Wed, Jul 13, 2022 at 09:12:15AM +0100, Mauro Carvalho Chehab wrote:
> Building docs currently produces this warning:
> 
>   Documentation/foo/i915:159: 
> ./drivers/gpu/drm/i915/i915_scatterlist.h:73: WARNING: Inline strong 
> start-string without end-string.
> 
> That's because @foo evaluates into **foo**, and placing anything
> after it without spaces cause Sphinx to warn and do the wrong
> thing.. So, replace them by a different Sphinx-compatible tag.
> 
> Signed-off-by: Mauro Carvalho Chehab 

Reviewed-by: Rodrigo Vivi 

> ---
> 
> To avoid mailbombing on a large number of people, only mailing lists were C/C 
> on the cover.
> See [PATCH v2 00/39] at: 
> https://lore.kernel.org/all/cover.1657699522.git.mche...@kernel.org/
> 
>  drivers/gpu/drm/i915/i915_scatterlist.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_scatterlist.h 
> b/drivers/gpu/drm/i915/i915_scatterlist.h
> index 0b8bf4be4330..5b5c4eee0f44 100644
> --- a/drivers/gpu/drm/i915/i915_scatterlist.h
> +++ b/drivers/gpu/drm/i915/i915_scatterlist.h
> @@ -70,7 +70,7 @@ static inline struct scatterlist *sg_next(struct 
> scatterlist *sg)
>   *
>   * Description:
>   *   If the entry is the last, return NULL; otherwise, step to the next
> - *   element in the array (@sg@+1). If that's a chain pointer, follow it;
> + *   element in the array (``sg@+1``). If that's a chain pointer, follow it;
>   *   otherwise just return the pointer to the current element.
>   **/
>  static inline struct scatterlist *__sg_next(struct scatterlist *sg)
> -- 
> 2.36.1
>

Re: [PATCH 1/2] drm/ttm: fix locking in vmap/vunmap TTM GEM helpers

2022-07-16 Thread Christian König


Am 15.07.22 um 17:36 schrieb Thomas Zimmermann:

Hi

Am 15.07.22 um 13:15 schrieb Christian König:

I've stumbled over this while reviewing patches for DMA-buf and it looks
like we completely messed the locking up here.

In general most TTM function should only be called while holding the
appropriate BO resv lock. Without this we could break the internal
buffer object state here.


I remember that I tried to fix this before and you mentioned that it's 
not allowed to hold this lock here. It would possibly deadlock with 
exported buffers. Did this change with Dmitry's rework of the locking 
semantics?


No, can you point me to that?

My assumption was that drm_gem_vmap()/vunmap() is always called with the 
lock held, but Dmitry's work is now suggesting otherwise.


We certainly need to hold the lock when we call ttm_bo_vmap()/vunmap() 
because it needs to access the bo->resource.


Thanks,
Christian.



Best regards
Thomas



Only compile tested!

Signed-off-by: Christian König 
Fixes: 43676605f890 drm/ttm: Add vmap/vunmap to TTM and TTM GEM helpers
---
  drivers/gpu/drm/drm_gem_ttm_helper.c | 9 -
  1 file changed, 8 insertions(+), 1 deletion(-)

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

index d5962a34c01d..e5fc875990c4 100644
--- a/drivers/gpu/drm/drm_gem_ttm_helper.c
+++ b/drivers/gpu/drm/drm_gem_ttm_helper.c
@@ -64,8 +64,13 @@ int drm_gem_ttm_vmap(struct drm_gem_object *gem,
   struct iosys_map *map)
  {
  struct ttm_buffer_object *bo = drm_gem_ttm_of_gem(gem);
+    int ret;
+
+    dma_resv_lock(gem->resv, NULL);
+    ret = ttm_bo_vmap(bo, map);
+    dma_resv_unlock(gem->resv);
  -    return ttm_bo_vmap(bo, map);
+    return ret;
  }
  EXPORT_SYMBOL(drm_gem_ttm_vmap);
  @@ -82,7 +87,9 @@ void drm_gem_ttm_vunmap(struct drm_gem_object *gem,
  {
  struct ttm_buffer_object *bo = drm_gem_ttm_of_gem(gem);
  +    dma_resv_lock(gem->resv, NULL);
  ttm_bo_vunmap(bo, map);
+    dma_resv_unlock(gem->resv);
  }
  EXPORT_SYMBOL(drm_gem_ttm_vunmap);

Re: [PATCH 3/3] drm/komeda - Fix handling of pending crtc state commit to avoid lock-up

2022-07-16 Thread Carsten Haitzler





On 7/11/22 11:13, Liviu Dudau wrote:

On Fri, Jul 08, 2022 at 07:03:37PM +0100, Carsten Haitzler wrote:



On 7/8/22 17:02, Liviu Dudau wrote:

On Mon, Jun 06, 2022 at 12:47:14PM +0100, carsten.haitz...@foss.arm.com wrote:

From: Carsten Haitzler 


Hi Carsten,



Sometimes there is an extra dcm crtc state in the pipeline whose
penting vblank event has not been handled yet. We would previously
throw this out and the vblank event never triggers leading to hard
lockups higher up the stack where an expected vlank event never comes
back (screen freezes).

This fixes that by tracking a pending crtc state that needs handling
and handle it producing a vlank event next vblank if it had not
laready been handled before. This fixes the hangs and ensures our
display keeps updating seamlessly and is certainly a much better state
to be in than after some time ending up with a mysteriously frozen
screen and a lot of kernle messages complaining about this too.


Sorry it took me so long to review and reply to this patch, but I had this 
nagging


No worries. :)


feeling that the patch is not actually correct so I've tried to track the actual
issue. It turns out that the problem is easy to reproduce in a different setup 
with
Mali D71 and it comes from the fact that Komeda doesn't properly wait for the
hardware to signal acceptance of config valid on setting new commits. I have 
created
a new patch that I would be happy if you can test to try to fix the actual 
issue.


This works (tested).


Thank you very much for testing this! Can I add your Tested-by?


Indeed. Go for it.


  One errant "flip without commit":

[9.402559] fbcon: Taking over console
[9.525373] [drm:komeda_print_events [komeda]] *ERROR* err detect: gcu:
MERR, pipes[0]: FLIP, pipes[1]: None
[9.525455] [drm] CRTC[0]: FLIP happened but no pending commit.
[9.542215] Console: switching to colour frame buffer device 240x67



Is this with your 2/3 patch applied and coming out from the firmware having 
already
initialised the hardware? If so, the handover probably doesn't quiescence the
interrupts correctly so an interrupt is pending when the kernel driver is
initialised. That's another area worth looking at for the handover purposes.


Yeah. the firmware is not doing a very clean handover - it's leaving the 
hardware in whatever state it has. it probably could shut down 
interrupts on handover, but not something to worry about in the kernel 
driver at this point.



But nothing worrying. It does work, though doesn't compile due to:

drivers/gpu/drm/arm/display/komeda/komeda_kms.c: In function
‘komeda_kms_atomic_commit_hw_done’:
drivers/gpu/drm/arm/display/komeda/komeda_kms.c:77:9: error: ‘for’ loop
initial declarations are only allowed in C99 or C11 mode
77 | for (int i = 0; i < kms->n_crtcs; i++) {
   | ^~~
drivers/gpu/drm/arm/display/komeda/komeda_kms.c:77:9: note: use option
‘-std=c9
’, ‘-std=gnu99’, ‘-std=c11’ or ‘-std=gnu11’ to compile your code

but that was a trivial fixup.


Interesting that I'm not seeing that, probably due to using GCC12? Anyway, I'll 
fix
that and send a proper patch.


I tend to use newer gcc's indeed, but I am using gcc11 in this case.


Your commit handler does sit and wait. I guess I avoided that and had it
still deferred and handled next time the vblank interrupt fires. Yours is a
bit shorter and less complex so it wins. :)


Yes, that's the essence of my issue with your patch. Delaying the handling of 
the
event until the next vblank means older software that doesn't use the 
timestamping
from the vblank event will get wrong framerates (playing video might be 
affected).


But this is a rare situation. I certainly was very happy going from "my 
entire display locks up and only a reboot really fixes it" to "look ma - 
it works and I didn't even see a stuttered frame!" :) But your fix is 
better in that regard.



Waiting here when we're also calling drm_atomic_helper_wait_for_flip_done() 
after
drm_atomic_helper_commit_hw_done() feels wrong, but then the later is checking 
if we
have consumed the event so we have to. Maybe the introduction of the
drm_atomic_helper_fake_vblank() is needed in komeda as well like the generic
commit_tail helper function does? I need to investigate more the next time I 
get some
spare cycles on komeda.

I will send a new email with the updated patch and your Tested-by if that's OK.


All happy and fine with that.


Best regards,
Liviu




--8<---

  From 76f9e5fed216a815e9eb56152f85454521079f10 Mon Sep 17 00:00:00 2001
From: Liviu Dudau 
Date: Fri, 8 Jul 2022 16:39:21 +0100
Subject: [PATCH] drm/komeda: Fix handling of atomic commits in the
   atomic_commit_tail hook

Komeda driver relies on the generic DRM atomic helper functions to handle
commits. It only implements an atomic_commit_tail hook for the
mode_config_helper_funcs and even that one is pretty close to the generic

Re: [PATCH 1/2] drm/ttm: fix locking in vmap/vunmap TTM GEM helpers

2022-07-16 Thread Dmitry Osipenko

On 7/15/22 14:33, Christian König wrote:
> Am 15.07.22 um 13:31 schrieb Dmitry Osipenko:
>> On 7/15/22 14:15, Christian König wrote:
>>> I've stumbled over this while reviewing patches for DMA-buf and it looks
>>> like we completely messed the locking up here.
>>>
>>> In general most TTM function should only be called while holding the
>>> appropriate BO resv lock. Without this we could break the internal
>>> buffer object state here.
>> Could you please clarify which part of the TTM state is affected?
> 
> The ttm_bo_vmap() function calls ttm_mem_io_reserve() with bo->resource
> as parameter.
> 
> Since bo->resource is protected by the lock we must make sure that we
> are holding the lock while doing this.

Thanks, I see now that the resource members need locking.

-- 
Best regards,
Dmitry

[PATCH v9 11/14] tools: update hmm-test to support device coherent type

Test cases such as migrate_fault and migrate_multiple, were modified to
explicit migrate from device to sys memory without the need of page
faults, when using device coherent type.

Snapshot test case updated to read memory device type first and based
on that, get the proper returned results migrate_ping_pong test case
added to test explicit migration from device to sys memory for both
private and coherent zone types.

Helpers to migrate from device to sys memory and vicerversa
were also added.

Signed-off-by: Alex Sierra 
Acked-by: Felix Kuehling 
Reviewed-by: Alistair Popple 
Signed-off-by: Christoph Hellwig 
---
 tools/testing/selftests/vm/hmm-tests.c | 121 -
 1 file changed, 100 insertions(+), 21 deletions(-)

diff --git a/tools/testing/selftests/vm/hmm-tests.c 
b/tools/testing/selftests/vm/hmm-tests.c
index 203323967b50..4b547188ec40 100644
--- a/tools/testing/selftests/vm/hmm-tests.c
+++ b/tools/testing/selftests/vm/hmm-tests.c
@@ -46,6 +46,13 @@ struct hmm_buffer {
uint64_tfaults;
 };
 
+enum {
+   HMM_PRIVATE_DEVICE_ONE,
+   HMM_PRIVATE_DEVICE_TWO,
+   HMM_COHERENCE_DEVICE_ONE,
+   HMM_COHERENCE_DEVICE_TWO,
+};
+
 #define TWOMEG (1 << 21)
 #define HMM_BUFFER_SIZE (1024 << 12)
 #define HMM_PATH_MAX64
@@ -60,6 +67,21 @@ FIXTURE(hmm)
unsigned intpage_shift;
 };
 
+FIXTURE_VARIANT(hmm)
+{
+   int device_number;
+};
+
+FIXTURE_VARIANT_ADD(hmm, hmm_device_private)
+{
+   .device_number = HMM_PRIVATE_DEVICE_ONE,
+};
+
+FIXTURE_VARIANT_ADD(hmm, hmm_device_coherent)
+{
+   .device_number = HMM_COHERENCE_DEVICE_ONE,
+};
+
 FIXTURE(hmm2)
 {
int fd0;
@@ -68,6 +90,24 @@ FIXTURE(hmm2)
unsigned intpage_shift;
 };
 
+FIXTURE_VARIANT(hmm2)
+{
+   int device_number0;
+   int device_number1;
+};
+
+FIXTURE_VARIANT_ADD(hmm2, hmm2_device_private)
+{
+   .device_number0 = HMM_PRIVATE_DEVICE_ONE,
+   .device_number1 = HMM_PRIVATE_DEVICE_TWO,
+};
+
+FIXTURE_VARIANT_ADD(hmm2, hmm2_device_coherent)
+{
+   .device_number0 = HMM_COHERENCE_DEVICE_ONE,
+   .device_number1 = HMM_COHERENCE_DEVICE_TWO,
+};
+
 static int hmm_open(int unit)
 {
char pathname[HMM_PATH_MAX];
@@ -81,12 +121,19 @@ static int hmm_open(int unit)
return fd;
 }
 
+static bool hmm_is_coherent_type(int dev_num)
+{
+   return (dev_num >= HMM_COHERENCE_DEVICE_ONE);
+}
+
 FIXTURE_SETUP(hmm)
 {
self->page_size = sysconf(_SC_PAGE_SIZE);
self->page_shift = ffs(self->page_size) - 1;
 
-   self->fd = hmm_open(0);
+   self->fd = hmm_open(variant->device_number);
+   if (self->fd < 0 && hmm_is_coherent_type(variant->device_number))
+   SKIP(exit(0), "DEVICE_COHERENT not available");
ASSERT_GE(self->fd, 0);
 }
 
@@ -95,9 +142,11 @@ FIXTURE_SETUP(hmm2)
self->page_size = sysconf(_SC_PAGE_SIZE);
self->page_shift = ffs(self->page_size) - 1;
 
-   self->fd0 = hmm_open(0);
+   self->fd0 = hmm_open(variant->device_number0);
+   if (self->fd0 < 0 && hmm_is_coherent_type(variant->device_number0))
+   SKIP(exit(0), "DEVICE_COHERENT not available");
ASSERT_GE(self->fd0, 0);
-   self->fd1 = hmm_open(1);
+   self->fd1 = hmm_open(variant->device_number1);
ASSERT_GE(self->fd1, 0);
 }
 
@@ -211,6 +260,20 @@ static void hmm_nanosleep(unsigned int n)
nanosleep(, NULL);
 }
 
+static int hmm_migrate_sys_to_dev(int fd,
+  struct hmm_buffer *buffer,
+  unsigned long npages)
+{
+   return hmm_dmirror_cmd(fd, HMM_DMIRROR_MIGRATE_TO_DEV, buffer, npages);
+}
+
+static int hmm_migrate_dev_to_sys(int fd,
+  struct hmm_buffer *buffer,
+  unsigned long npages)
+{
+   return hmm_dmirror_cmd(fd, HMM_DMIRROR_MIGRATE_TO_SYS, buffer, npages);
+}
+
 /*
  * Simple NULL test of device open/close.
  */
@@ -875,7 +938,7 @@ TEST_F(hmm, migrate)
ptr[i] = i;
 
/* Migrate memory to device. */
-   ret = hmm_dmirror_cmd(self->fd, HMM_DMIRROR_MIGRATE, buffer, npages);
+   ret = hmm_migrate_sys_to_dev(self->fd, buffer, npages);
ASSERT_EQ(ret, 0);
ASSERT_EQ(buffer->cpages, npages);
 
@@ -923,7 +986,7 @@ TEST_F(hmm, migrate_fault)
ptr[i] = i;
 
/* Migrate memory to device. */
-   ret = hmm_dmirror_cmd(self->fd, HMM_DMIRROR_MIGRATE, buffer, npages);
+   ret = hmm_migrate_sys_to_dev(self->fd, buffer, npages);
ASSERT_EQ(ret, 0);
ASSERT_EQ(buffer->cpages, npages);
 
@@ -936,7 +999,7 @@ TEST_F(hmm, migrate_fault)
ASSERT_EQ(ptr[i], i);
 
/* Migrate memory to the device again. */
-   ret = hmm_dmirror_cmd(self->fd, HMM_DMIRROR_MIGRATE, buffer, npages);
+   ret = hmm_migrate_sys_to_dev(self->fd, buffer, npages);
ASSERT_EQ(ret, 0);
ASSERT_EQ(buffer->cpages,

Re: [PATCH 07/12] drm/i915/guc: Route semaphores to GuC for Gen12+

2022-07-16 Thread Ceraolo Spurio, Daniele





On 7/12/2022 4:31 PM, john.c.harri...@intel.com wrote:

From: Michał Winiarski 

Since we're going to use semaphores in selftests (and eventually in
regular GuC submission), let's route semaphores to GuC.


I'd specify that this interrupt is only relevant for semaphores that 
context switch out when their condition is not satisfied, which is not 
something we currently allow (but we do plan to as you mentioned). Also, 
the routing only happens when in GuC submission mode.


Reviewed-by: Daniele Ceraolo Spurio 

Daniele



Signed-off-by: Michał Winiarski 
---
  drivers/gpu/drm/i915/gt/uc/intel_guc_reg.h|  4 
  drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 14 ++
  2 files changed, 18 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_reg.h 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_reg.h
index 8dc063f087eb1..a7092f711e9cd 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_reg.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_reg.h
@@ -102,6 +102,10 @@
  #define   GUC_SEND_TRIGGER  (1<<0)
  #define GEN11_GUC_HOST_INTERRUPT  _MMIO(0x1901f0)
  
+#define GEN12_GUC_SEM_INTR_ENABLES	_MMIO(0xc71c)

+#define   GUC_SEM_INTR_ROUTE_TO_GUCBIT(31)
+#define   GUC_SEM_INTR_ENABLE_ALL  (0xff)
+
  #define GUC_NUM_DOORBELLS 256
  
  /* format of the HW-monitored doorbell cacheline */

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 40f726c61e951..7537459080278 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -3953,13 +3953,27 @@ int intel_guc_submission_setup(struct intel_engine_cs 
*engine)
  
  void intel_guc_submission_enable(struct intel_guc *guc)

  {
+   struct intel_gt *gt = guc_to_gt(guc);
+
+   /* Enable and route to GuC */
+   if (GRAPHICS_VER(gt->i915) >= 12)
+   intel_uncore_write(gt->uncore, GEN12_GUC_SEM_INTR_ENABLES,
+  GUC_SEM_INTR_ROUTE_TO_GUC |
+  GUC_SEM_INTR_ENABLE_ALL);
+
guc_init_lrc_mapping(guc);
guc_init_engine_stats(guc);
  }
  
  void intel_guc_submission_disable(struct intel_guc *guc)

  {
+   struct intel_gt *gt = guc_to_gt(guc);
+
/* Note: By the time we're here, GuC may have already been reset */
+
+   /* Disable and route to host */
+   if (GRAPHICS_VER(gt->i915) >= 12)
+   intel_uncore_write(gt->uncore, GEN12_GUC_SEM_INTR_ENABLES, 0x0);
  }
  
  static bool __guc_submission_supported(struct intel_guc *guc)

Re: [PATCH v5 10/13] power: supply: mt6370: Add MediaTek MT6370 charger driver

On Fri, Jul 15, 2022 at 1:29 PM ChiaEn Wu  wrote:
>
> From: ChiaEn Wu 
>
> MediaTek MT6370 is a SubPMIC consisting of a single cell battery charger
> with ADC monitoring, RGB LEDs, dual channel flashlight, WLED backlight
> driver, display bias voltage supply, one general purpose LDO, and the
> USB Type-C & PD controller complies with the latest USB Type-C and PD
> standards.
>
> This adds MediaTek MT6370 Charger driver support. The charger module
> of MT6370 supports High-Accuracy Voltage/Current Regulation,
> Average Input Current Regulation, Battery Temperature Sensing,
> Over-Temperature Protection, DPDM Detection for BC1.2.

...

> +static int mt6370_chg_probe(struct platform_device *pdev)
> +{
> +   int ret;
> +   struct mt6370_priv *priv;
> +
> +   priv = devm_kzalloc(>dev, sizeof(*priv), GFP_KERNEL);
> +   if (!priv)
> +   return -ENOMEM;
> +
> +   priv->dev = >dev;
> +
> +   priv->regmap = dev_get_regmap(pdev->dev.parent, NULL);
> +   if (!priv->regmap)
> +   return dev_err_probe(>dev, -ENODEV,
> +"Failed to get regmap\n");
> +
> +   ret = mt6370_chg_init_rmap_fields(priv);
> +   if (ret)
> +   return dev_err_probe(>dev, ret,
> +"Failed to init regmap fields\n");
> +
> +   platform_set_drvdata(pdev, priv);
> +
> +   priv->iio_adcs = devm_iio_channel_get_all(priv->dev);
> +   if (IS_ERR(priv->iio_adcs))
> +   return dev_err_probe(>dev, PTR_ERR(priv->iio_adcs),
> +"Failed to get iio adc\n");
> +
> +   ret = mt6370_chg_init_otg_regulator(priv);
> +   if (ret)
> +   return dev_err_probe(>dev, ret,
> +"Failed to init otg regulator\n");
> +
> +   ret = mt6370_chg_init_psy(priv);
> +   if (ret)
> +   return dev_err_probe(>dev, ret, "Failed to init psy\n");
> +
> +   mutex_init(>attach_lock);
> +   priv->attach = MT6370_ATTACH_STAT_DETACH;
> +
> +   priv->wq = create_singlethread_workqueue(dev_name(priv->dev));
> +   if (IS_ERR(priv->wq))

> +   return dev_err_probe(priv->dev, PTR_ERR(priv->wq),
> +"Failed to create workqueue\n");

You need either wrap mutex to be deallocated by devm or don't use
dev_err_probe() here.

> +   INIT_WORK(>bc12_work, mt6370_chg_bc12_work_func);
> +   INIT_DELAYED_WORK(>mivr_dwork, mt6370_chg_mivr_dwork_func);
> +
> +   ret = mt6370_chg_init_setting(priv);
> +   if (ret) {
> +   dev_err(>dev, "Failed to init mt6370 charger 
> setting\n");
> +   goto probe_out;
> +   }
> +
> +   ret = mt6370_chg_init_irq(priv);
> +   if (ret)
> +   goto probe_out;
> +
> +   mt6370_chg_pwr_rdy_check(priv);
> +
> +   return 0;
> +
> +probe_out:
> +   cancel_delayed_work_sync(>mivr_dwork);
> +   flush_workqueue(priv->wq);
> +   destroy_workqueue(priv->wq);
> +   mutex_destroy(>attach_lock);
> +
> +   return ret;
> +}
> +
> +static int mt6370_chg_remove(struct platform_device *pdev)
> +{
> +   struct mt6370_priv *priv = platform_get_drvdata(pdev);
> +
> +   cancel_delayed_work_sync(>mivr_dwork);
> +   flush_workqueue(priv->wq);
> +   destroy_workqueue(priv->wq);
> +   mutex_destroy(>attach_lock);
> +
> +   return 0;
> +}


-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v1] drm/scheduler: Don't kill jobs in interrupt context

2022-07-16 Thread Dmitry Osipenko

On 7/15/22 18:18, Andrey Grodzovsky wrote:
> 
> On 2022-07-14 17:16, Alex Deucher wrote:
>> On Thu, Jul 14, 2022 at 1:58 PM Andrey Grodzovsky
>>  wrote:
>>> On 2022-07-14 12:22, Alex Deucher wrote:
>>>
 On Thu, Jul 14, 2022 at 10:14 AM Andrey Grodzovsky
  wrote:
> On 2022-07-14 05:57, Dmitry Osipenko wrote:
>> On 7/12/22 11:56, Dmitry Osipenko wrote:
>>> On 7/6/22 18:46, Alex Deucher wrote:
 On Wed, Jul 6, 2022 at 9:49 AM Andrey Grodzovsky
  wrote:
> On 2022-07-06 03:07, Dmitry Osipenko wrote:
>
>> Hello Andrey,
>>
>> On 5/17/22 17:48, Dmitry Osipenko wrote:
>>> On 5/17/22 17:13, Andrey Grodzovsky wrote:
 Done.

 Andrey
>>> Awesome, thank you!
>>>
>> Given that this drm-scheduler issue needs to be fixed in the
>> 5.19-RC and
>> earlier, shouldn't it be in the drm-fixes and not in drm-next?
> I pushed it into drm-misc from where it got into drm-next. I
> don't have
> permission for drm-fixes.
 The -fixes branch of drm-misc.
>>> Now I don't see the scheduler bugfix neither in the -fixes branch
>>> nor in
>>> the -next and today Dave sent out 5.19-rc7 pull request without the
>>> scheduler fix. Could anyone please check what is going on with
>>> the DRM
>>> patches? Thanks!
>>>
>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ffreedesktop%2Fdrm-misc%2Fcommits%2Fdrm-misc-fixesdata=05%7C01%7Candrey.grodzovsky%40amd.com%7C9585d3814d9b4e51bfcb08da65de368d%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637934302314091129%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=QjSspRJyOZpFOoaA988nH2V7Gq54gSUl6mm87B1sYhE%3Dreserved=0
>>>
>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcgit.freedesktop.org%2Fdrm%2Fdrm-misc%2Flog%2F%3Fh%3Ddrm-misc-fixesdata=05%7C01%7Candrey.grodzovsky%40amd.com%7C9585d3814d9b4e51bfcb08da65de368d%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637934302314091129%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=8ysjuD7Ufsyu5c%2BfRdpT9nkWHjotsd1cjCfy4yRw2uw%3Dreserved=0
>>>
>> The patch is in the drm-misc-next-fixes, so it wasn't moved to the
>> drm-misc-fixes.
>>
>> Andrey, don't you have access to drm-misc-fixes? Or you meant
>> drm-fixes=drm-misc-fixes?
> I have only accesses to drm-misc-next to which I pushed this patch.
 anyone with drm-misc rights can commit to any of the branches in the
 drm-misc tree.  You just need to check out and push the appropriate
 branch.  then push the changes.  E.g.,
 dim push-branch drm-misc-next
 vs
 dim push-branch drm-misc-next-fixes
 etc.

 Alex
>>>
>>> I see, but what  is the reason then that Dave sent out 5.19-rc7 pull
>>> request without the
>>> scheduler fix if the patch was merged into drm-misc-next long ago ? All
>>> the changes from
>>> there are usually picked up for pull requests, no ?
>> drm-misc-next is for new stuff for the next kernel (e.g., 5.20).
>> drm-misc-fixes is for fixes for the current kernel cycle (e.g., 5.19).
>> See:
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdrm.pages.freedesktop.org%2Fmaintainer-tools%2Fdrm-misc.htmldata=05%7C01%7Candrey.grodzovsky%40amd.com%7C9585d3814d9b4e51bfcb08da65de368d%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637934302314091129%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=8IW3uNvSEogYjj%2BNKh1b9jkT5CaJ5osZ9GgEcI8zyqo%3Dreserved=0
>>
>>
>> Alex
> 
> 
> Got it, Dmitry, I pushed this time to drm-misc-fixes so i hope this time
> it will be picked up for next rc release.

Great, thank you!

-- 
Best regards,
Dmitry

[PATCH v9 09/14] lib: test_hmm add module param for zone device type

In order to configure device coherent in test_hmm, two module parameters
should be passed, which correspond to the SP start address of each
device (2) spm_addr_dev0 & spm_addr_dev1. If no parameters are passed,
private device type is configured.

Signed-off-by: Alex Sierra 
Acked-by: Felix Kuehling 
Reviewed-by: Alistair Poppple 
Signed-off-by: Christoph Hellwig 
---
 lib/test_hmm.c  | 73 -
 lib/test_hmm_uapi.h |  1 +
 2 files changed, 53 insertions(+), 21 deletions(-)

diff --git a/lib/test_hmm.c b/lib/test_hmm.c
index 915ef6b5b0d4..afb30af9f3ff 100644
--- a/lib/test_hmm.c
+++ b/lib/test_hmm.c
@@ -37,6 +37,16 @@
 #define DEVMEM_CHUNK_SIZE  (256 * 1024 * 1024U)
 #define DEVMEM_CHUNKS_RESERVE  16
 
+static unsigned long spm_addr_dev0;
+module_param(spm_addr_dev0, long, 0644);
+MODULE_PARM_DESC(spm_addr_dev0,
+   "Specify start address for SPM (special purpose memory) used 
for device 0. By setting this Coherent device type will be used. Make sure 
spm_addr_dev1 is set too. Minimum SPM size should be DEVMEM_CHUNK_SIZE.");
+
+static unsigned long spm_addr_dev1;
+module_param(spm_addr_dev1, long, 0644);
+MODULE_PARM_DESC(spm_addr_dev1,
+   "Specify start address for SPM (special purpose memory) used 
for device 1. By setting this Coherent device type will be used. Make sure 
spm_addr_dev0 is set too. Minimum SPM size should be DEVMEM_CHUNK_SIZE.");
+
 static const struct dev_pagemap_ops dmirror_devmem_ops;
 static const struct mmu_interval_notifier_ops dmirror_min_ops;
 static dev_t dmirror_dev;
@@ -455,28 +465,44 @@ static int dmirror_write(struct dmirror *dmirror, struct 
hmm_dmirror_cmd *cmd)
return ret;
 }
 
-static bool dmirror_allocate_chunk(struct dmirror_device *mdevice,
+static int dmirror_allocate_chunk(struct dmirror_device *mdevice,
   struct page **ppage)
 {
struct dmirror_chunk *devmem;
-   struct resource *res;
+   struct resource *res = NULL;
unsigned long pfn;
unsigned long pfn_first;
unsigned long pfn_last;
void *ptr;
+   int ret = -ENOMEM;
 
devmem = kzalloc(sizeof(*devmem), GFP_KERNEL);
if (!devmem)
-   return false;
+   return ret;
 
-   res = request_free_mem_region(_resource, DEVMEM_CHUNK_SIZE,
- "hmm_dmirror");
-   if (IS_ERR(res))
+   switch (mdevice->zone_device_type) {
+   case HMM_DMIRROR_MEMORY_DEVICE_PRIVATE:
+   res = request_free_mem_region(_resource, 
DEVMEM_CHUNK_SIZE,
+ "hmm_dmirror");
+   if (IS_ERR_OR_NULL(res))
+   goto err_devmem;
+   devmem->pagemap.range.start = res->start;
+   devmem->pagemap.range.end = res->end;
+   devmem->pagemap.type = MEMORY_DEVICE_PRIVATE;
+   break;
+   case HMM_DMIRROR_MEMORY_DEVICE_COHERENT:
+   devmem->pagemap.range.start = (MINOR(mdevice->cdevice.dev) - 2) 
?
+   spm_addr_dev0 :
+   spm_addr_dev1;
+   devmem->pagemap.range.end = devmem->pagemap.range.start +
+   DEVMEM_CHUNK_SIZE - 1;
+   devmem->pagemap.type = MEMORY_DEVICE_COHERENT;
+   break;
+   default:
+   ret = -EINVAL;
goto err_devmem;
+   }
 
-   devmem->pagemap.type = MEMORY_DEVICE_PRIVATE;
-   devmem->pagemap.range.start = res->start;
-   devmem->pagemap.range.end = res->end;
devmem->pagemap.nr_range = 1;
devmem->pagemap.ops = _devmem_ops;
devmem->pagemap.owner = mdevice;
@@ -497,10 +523,14 @@ static bool dmirror_allocate_chunk(struct dmirror_device 
*mdevice,
mdevice->devmem_capacity = new_capacity;
mdevice->devmem_chunks = new_chunks;
}
-
ptr = memremap_pages(>pagemap, numa_node_id());
-   if (IS_ERR(ptr))
+   if (IS_ERR_OR_NULL(ptr)) {
+   if (ptr)
+   ret = PTR_ERR(ptr);
+   else
+   ret = -EFAULT;
goto err_release;
+   }
 
devmem->mdevice = mdevice;
pfn_first = devmem->pagemap.range.start >> PAGE_SHIFT;
@@ -529,15 +559,17 @@ static bool dmirror_allocate_chunk(struct dmirror_device 
*mdevice,
}
spin_unlock(>lock);
 
-   return true;
+   return 0;
 
 err_release:
mutex_unlock(>devmem_lock);
-   release_mem_region(devmem->pagemap.range.start, 
range_len(>pagemap.range));
+   if (res && devmem->pagemap.type == MEMORY_DEVICE_PRIVATE)
+   release_mem_region(devmem->pagemap.range.start,
+  range_len(>pagemap.range));
 err_devmem:
kfree(devmem);
 
-   return false;
+

[PATCH v9 07/14] drm/amdkfd: add SPM support for SVM

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

Signed-off-by: Alex Sierra 
Reviewed-by: Felix Kuehling 
Signed-off-by: Christoph Hellwig 
---
 drivers/gpu/drm/amd/amdkfd/kfd_migrate.c | 34 +++-
 1 file changed, 21 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
index e44376c2ecdc..f73e3e340413 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
@@ -671,13 +671,15 @@ svm_migrate_vma_to_ram(struct amdgpu_device *adev, struct 
svm_range *prange,
migrate.vma = vma;
migrate.start = start;
migrate.end = end;
-   migrate.flags = MIGRATE_VMA_SELECT_DEVICE_PRIVATE;
migrate.pgmap_owner = SVM_ADEV_PGMAP_OWNER(adev);
+   if (adev->gmc.xgmi.connected_to_cpu)
+   migrate.flags = MIGRATE_VMA_SELECT_DEVICE_COHERENT;
+   else
+   migrate.flags = MIGRATE_VMA_SELECT_DEVICE_PRIVATE;
 
buf = kvcalloc(npages,
   2 * sizeof(*migrate.src) + sizeof(uint64_t) + 
sizeof(dma_addr_t),
   GFP_KERNEL);
-
if (!buf)
goto out;
 
@@ -947,7 +949,7 @@ int svm_migrate_init(struct amdgpu_device *adev)
 {
struct kfd_dev *kfddev = adev->kfd.dev;
struct dev_pagemap *pgmap;
-   struct resource *res;
+   struct resource *res = NULL;
unsigned long size;
void *r;
 
@@ -962,28 +964,34 @@ int svm_migrate_init(struct amdgpu_device *adev)
 * should remove reserved size
 */
size = ALIGN(adev->gmc.real_vram_size, 2ULL << 20);
-   res = devm_request_free_mem_region(adev->dev, _resource, size);
-   if (IS_ERR(res))
-   return -ENOMEM;
+   if (adev->gmc.xgmi.connected_to_cpu) {
+   pgmap->range.start = adev->gmc.aper_base;
+   pgmap->range.end = adev->gmc.aper_base + adev->gmc.aper_size - 
1;
+   pgmap->type = MEMORY_DEVICE_COHERENT;
+   } else {
+   res = devm_request_free_mem_region(adev->dev, _resource, 
size);
+   if (IS_ERR(res))
+   return -ENOMEM;
+   pgmap->range.start = res->start;
+   pgmap->range.end = res->end;
+   pgmap->type = MEMORY_DEVICE_PRIVATE;
+   }
 
-   pgmap->type = MEMORY_DEVICE_PRIVATE;
pgmap->nr_range = 1;
-   pgmap->range.start = res->start;
-   pgmap->range.end = res->end;
pgmap->ops = _migrate_pgmap_ops;
pgmap->owner = SVM_ADEV_PGMAP_OWNER(adev);
-   pgmap->flags = MIGRATE_VMA_SELECT_DEVICE_PRIVATE;
-
+   pgmap->flags = 0;
/* Device manager releases device-specific resources, memory region and
 * pgmap when driver disconnects from device.
 */
r = devm_memremap_pages(adev->dev, pgmap);
if (IS_ERR(r)) {
pr_err("failed to register HMM device memory\n");
-
/* Disable SVM support capability */
pgmap->type = 0;
-   devm_release_mem_region(adev->dev, res->start, 
resource_size(res));
+   if (pgmap->type == MEMORY_DEVICE_PRIVATE)
+   devm_release_mem_region(adev->dev, res->start,
+   res->end - res->start + 1);
return PTR_ERR(r);
}
 
-- 
2.32.0

[PATCH v9 02/14] mm: move page zone helpers from mm.h to mmzone.h

[WHY]
It makes more sense to have these helpers in zone specific header
file, rather than the generic mm.h

Signed-off-by: Alex Sierra 
---
 include/linux/memremap.h |  2 +-
 include/linux/mm.h   | 78 ---
 include/linux/mmzone.h   | 80 
 3 files changed, 81 insertions(+), 79 deletions(-)

diff --git a/include/linux/memremap.h b/include/linux/memremap.h
index 8af304f6b504..77229165c914 100644
--- a/include/linux/memremap.h
+++ b/include/linux/memremap.h
@@ -2,7 +2,7 @@
 #ifndef _LINUX_MEMREMAP_H_
 #define _LINUX_MEMREMAP_H_
 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 3b31b33bd5be..2df8c2b98d36 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1049,84 +1049,6 @@ vm_fault_t finish_mkwrite_fault(struct vm_fault *vmf);
  *   back into memory.
  */
 
-/*
- * The zone field is never updated after free_area_init_core()
- * sets it, so none of the operations on it need to be atomic.
- */
-
-/* Page flags: | [SECTION] | [NODE] | ZONE | [LAST_CPUPID] | ... | FLAGS | */
-#define SECTIONS_PGOFF ((sizeof(unsigned long)*8) - SECTIONS_WIDTH)
-#define NODES_PGOFF(SECTIONS_PGOFF - NODES_WIDTH)
-#define ZONES_PGOFF(NODES_PGOFF - ZONES_WIDTH)
-#define LAST_CPUPID_PGOFF  (ZONES_PGOFF - LAST_CPUPID_WIDTH)
-#define KASAN_TAG_PGOFF(LAST_CPUPID_PGOFF - KASAN_TAG_WIDTH)
-
-/*
- * Define the bit shifts to access each section.  For non-existent
- * sections we define the shift as 0; that plus a 0 mask ensures
- * the compiler will optimise away reference to them.
- */
-#define SECTIONS_PGSHIFT   (SECTIONS_PGOFF * (SECTIONS_WIDTH != 0))
-#define NODES_PGSHIFT  (NODES_PGOFF * (NODES_WIDTH != 0))
-#define ZONES_PGSHIFT  (ZONES_PGOFF * (ZONES_WIDTH != 0))
-#define LAST_CPUPID_PGSHIFT(LAST_CPUPID_PGOFF * (LAST_CPUPID_WIDTH != 0))
-#define KASAN_TAG_PGSHIFT  (KASAN_TAG_PGOFF * (KASAN_TAG_WIDTH != 0))
-
-/* NODE:ZONE or SECTION:ZONE is used to ID a zone for the buddy allocator */
-#ifdef NODE_NOT_IN_PAGE_FLAGS
-#define ZONEID_SHIFT   (SECTIONS_SHIFT + ZONES_SHIFT)
-#define ZONEID_PGOFF   ((SECTIONS_PGOFF < ZONES_PGOFF)? \
-   SECTIONS_PGOFF : ZONES_PGOFF)
-#else
-#define ZONEID_SHIFT   (NODES_SHIFT + ZONES_SHIFT)
-#define ZONEID_PGOFF   ((NODES_PGOFF < ZONES_PGOFF)? \
-   NODES_PGOFF : ZONES_PGOFF)
-#endif
-
-#define ZONEID_PGSHIFT (ZONEID_PGOFF * (ZONEID_SHIFT != 0))
-
-#define ZONES_MASK ((1UL << ZONES_WIDTH) - 1)
-#define NODES_MASK ((1UL << NODES_WIDTH) - 1)
-#define SECTIONS_MASK  ((1UL << SECTIONS_WIDTH) - 1)
-#define LAST_CPUPID_MASK   ((1UL << LAST_CPUPID_SHIFT) - 1)
-#define KASAN_TAG_MASK ((1UL << KASAN_TAG_WIDTH) - 1)
-#define ZONEID_MASK((1UL << ZONEID_SHIFT) - 1)
-
-static inline enum zone_type page_zonenum(const struct page *page)
-{
-   ASSERT_EXCLUSIVE_BITS(page->flags, ZONES_MASK << ZONES_PGSHIFT);
-   return (page->flags >> ZONES_PGSHIFT) & ZONES_MASK;
-}
-
-static inline enum zone_type folio_zonenum(const struct folio *folio)
-{
-   return page_zonenum(>page);
-}
-
-#ifdef CONFIG_ZONE_DEVICE
-static inline bool is_zone_device_page(const struct page *page)
-{
-   return page_zonenum(page) == ZONE_DEVICE;
-}
-extern void memmap_init_zone_device(struct zone *, unsigned long,
-   unsigned long, struct dev_pagemap *);
-#else
-static inline bool is_zone_device_page(const struct page *page)
-{
-   return false;
-}
-#endif
-
-static inline bool folio_is_zone_device(const struct folio *folio)
-{
-   return is_zone_device_page(>page);
-}
-
-static inline bool is_zone_movable_page(const struct page *page)
-{
-   return page_zonenum(page) == ZONE_MOVABLE;
-}
-
 #if defined(CONFIG_ZONE_DEVICE) && defined(CONFIG_FS_DAX)
 DECLARE_STATIC_KEY_FALSE(devmap_managed_key);
 
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index aab70355d64f..47fc41f43c48 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -730,6 +730,86 @@ static inline bool zone_is_empty(struct zone *zone)
return zone->spanned_pages == 0;
 }
 
+#ifndef BUILD_VDSO32_64
+/*
+ * The zone field is never updated after free_area_init_core()
+ * sets it, so none of the operations on it need to be atomic.
+ */
+
+/* Page flags: | [SECTION] | [NODE] | ZONE | [LAST_CPUPID] | ... | FLAGS | */
+#define SECTIONS_PGOFF ((sizeof(unsigned long)*8) - SECTIONS_WIDTH)
+#define NODES_PGOFF(SECTIONS_PGOFF - NODES_WIDTH)
+#define ZONES_PGOFF(NODES_PGOFF - ZONES_WIDTH)
+#define LAST_CPUPID_PGOFF  (ZONES_PGOFF - LAST_CPUPID_WIDTH)
+#define KASAN_TAG_PGOFF(LAST_CPUPID_PGOFF - KASAN_TAG_WIDTH)
+
+/*
+ * Define the bit shifts to access

[PATCH v9 06/14] mm/gup: migrate device coherent pages when pinning instead of failing

From: Alistair Popple 

Currently any attempts to pin a device coherent page will fail. This is
because device coherent pages need to be managed by a device driver, and
pinning them would prevent a driver from migrating them off the device.

However this is no reason to fail pinning of these pages. These are
coherent and accessible from the CPU so can be migrated just like
pinning ZONE_MOVABLE pages. So instead of failing all attempts to pin
them first try migrating them out of ZONE_DEVICE.

[hch: rebased to the split device memory checks,
  moved migrate_device_page to migrate_device.c]

Signed-off-by: Alistair Popple 
Acked-by: Felix Kuehling 
Signed-off-by: Christoph Hellwig 
---
 mm/gup.c| 50 +--
 mm/internal.h   |  1 +
 mm/migrate_device.c | 52 +
 3 files changed, 96 insertions(+), 7 deletions(-)

diff --git a/mm/gup.c b/mm/gup.c
index b65fe8bf5af4..22b97ab61cd9 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -1881,7 +1881,7 @@ static long check_and_migrate_movable_pages(unsigned long 
nr_pages,
unsigned long isolation_error_count = 0, i;
struct folio *prev_folio = NULL;
LIST_HEAD(movable_page_list);
-   bool drain_allow = true;
+   bool drain_allow = true, coherent_pages = false;
int ret = 0;
 
for (i = 0; i < nr_pages; i++) {
@@ -1891,9 +1891,38 @@ static long check_and_migrate_movable_pages(unsigned 
long nr_pages,
continue;
prev_folio = folio;
 
-   if (folio_is_longterm_pinnable(folio))
+   /*
+* Device coherent pages are managed by a driver and should not
+* be pinned indefinitely as it prevents the driver moving the
+* page. So when trying to pin with FOLL_LONGTERM instead try
+* to migrate the page out of device memory.
+*/
+   if (folio_is_device_coherent(folio)) {
+   /*
+* We always want a new GUP lookup with device coherent
+* pages.
+*/
+   pages[i] = 0;
+   coherent_pages = true;
+
+   /*
+* Migration will fail if the page is pinned, so convert
+* the pin on the source page to a normal reference.
+*/
+   if (gup_flags & FOLL_PIN) {
+   get_page(>page);
+   unpin_user_page(>page);
+   }
+
+   ret = migrate_device_coherent_page(>page);
+   if (ret)
+   goto unpin_pages;
+
continue;
+   }
 
+   if (folio_is_longterm_pinnable(folio))
+   continue;
/*
 * Try to move out any movable page before pinning the range.
 */
@@ -1919,7 +1948,8 @@ static long check_and_migrate_movable_pages(unsigned long 
nr_pages,
folio_nr_pages(folio));
}
 
-   if (!list_empty(_page_list) || isolation_error_count)
+   if (!list_empty(_page_list) || isolation_error_count
+   || coherent_pages)
goto unpin_pages;
 
/*
@@ -1929,10 +1959,16 @@ static long check_and_migrate_movable_pages(unsigned 
long nr_pages,
return nr_pages;
 
 unpin_pages:
-   if (gup_flags & FOLL_PIN) {
-   unpin_user_pages(pages, nr_pages);
-   } else {
-   for (i = 0; i < nr_pages; i++)
+   /*
+* pages[i] might be NULL if any device coherent pages were found.
+*/
+   for (i = 0; i < nr_pages; i++) {
+   if (!pages[i])
+   continue;
+
+   if (gup_flags & FOLL_PIN)
+   unpin_user_page(pages[i]);
+   else
put_page(pages[i]);
}
 
diff --git a/mm/internal.h b/mm/internal.h
index c0f8fbe0445b..899dab512c5a 100644
--- a/mm/internal.h
+++ b/mm/internal.h
@@ -853,6 +853,7 @@ int numa_migrate_prep(struct page *page, struct 
vm_area_struct *vma,
  unsigned long addr, int page_nid, int *flags);
 
 void free_zone_device_page(struct page *page);
+int migrate_device_coherent_page(struct page *page);
 
 /*
  * mm/gup.c
diff --git a/mm/migrate_device.c b/mm/migrate_device.c
index 18bc6483f63a..7feeb447e3b9 100644
--- a/mm/migrate_device.c
+++ b/mm/migrate_device.c
@@ -686,6 +686,12 @@ void migrate_vma_pages(struct migrate_vma *migrate)
}
 
if (!page) {
+   /*
+* The only time there is no vma is when called from
+* migrate_device_coherent_page(). However this isn't
+* called if

[PATCH 1/3] drm: Use original src rect while initializing damage iterator

2022-07-16 Thread Jouni Högander

drm_plane_state->src might be modified by the driver. This is done
e.g. in i915 driver when there is bigger framebuffer than the plane
and there is some offset within framebuffer. I915 driver calculates
separate offset and adjusts src rect coords to be relative to this
offset. Damage clips are still relative to original src coords
provided by user-space.

This patch ensures original coordinates provided by user-space are
used when initiliazing damage iterator.

Signed-off-by: Jouni Högander 
---
 drivers/gpu/drm/drm_damage_helper.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_damage_helper.c 
b/drivers/gpu/drm/drm_damage_helper.c
index 937b699ac2a8..d8b2955e88fd 100644
--- a/drivers/gpu/drm/drm_damage_helper.c
+++ b/drivers/gpu/drm/drm_damage_helper.c
@@ -224,6 +224,7 @@ drm_atomic_helper_damage_iter_init(struct 
drm_atomic_helper_damage_iter *iter,
   const struct drm_plane_state *old_state,
   const struct drm_plane_state *state)
 {
+   struct drm_rect src;
memset(iter, 0, sizeof(*iter));
 
if (!state || !state->crtc || !state->fb || !state->visible)
@@ -233,10 +234,12 @@ drm_atomic_helper_damage_iter_init(struct 
drm_atomic_helper_damage_iter *iter,
iter->num_clips = drm_plane_get_damage_clips_count(state);
 
/* Round down for x1/y1 and round up for x2/y2 to catch all pixels */
-   iter->plane_src.x1 = state->src.x1 >> 16;
-   iter->plane_src.y1 = state->src.y1 >> 16;
-   iter->plane_src.x2 = (state->src.x2 >> 16) + !!(state->src.x2 & 0x);
-   iter->plane_src.y2 = (state->src.y2 >> 16) + !!(state->src.y2 & 0x);
+   src = drm_plane_state_src(state);
+
+   iter->plane_src.x1 = src.x1 >> 16;
+   iter->plane_src.y1 = src.y1 >> 16;
+   iter->plane_src.x2 = (src.x2 >> 16) + !!(src.x2 & 0x);
+   iter->plane_src.y2 = (src.y2 >> 16) + !!(src.y2 & 0x);
 
if (!iter->clips || !drm_rect_equals(>src, _state->src)) {
iter->clips = NULL;
-- 
2.25.1

[PATCH v9 08/14] lib: test_hmm add ioctl to get zone device type

new ioctl cmd added to query zone device type. This will be
used once the test_hmm adds zone device coherent type.

Signed-off-by: Alex Sierra 
Acked-by: Felix Kuehling 
Reviewed-by: Alistair Poppple 
Signed-off-by: Christoph Hellwig 
---
 lib/test_hmm.c  | 11 +--
 lib/test_hmm_uapi.h | 14 ++
 2 files changed, 19 insertions(+), 6 deletions(-)

diff --git a/lib/test_hmm.c b/lib/test_hmm.c
index cfe632047839..915ef6b5b0d4 100644
--- a/lib/test_hmm.c
+++ b/lib/test_hmm.c
@@ -87,6 +87,7 @@ struct dmirror_chunk {
 struct dmirror_device {
struct cdev cdevice;
struct hmm_devmem   *devmem;
+   unsigned intzone_device_type;
 
unsigned intdevmem_capacity;
unsigned intdevmem_count;
@@ -1260,14 +1261,20 @@ static void dmirror_device_remove(struct dmirror_device 
*mdevice)
 static int __init hmm_dmirror_init(void)
 {
int ret;
-   int id;
+   int id = 0;
+   int ndevices = 0;
 
ret = alloc_chrdev_region(_dev, 0, DMIRROR_NDEVICES,
  "HMM_DMIRROR");
if (ret)
goto err_unreg;
 
-   for (id = 0; id < DMIRROR_NDEVICES; id++) {
+   memset(dmirror_devices, 0, DMIRROR_NDEVICES * 
sizeof(dmirror_devices[0]));
+   dmirror_devices[ndevices++].zone_device_type =
+   HMM_DMIRROR_MEMORY_DEVICE_PRIVATE;
+   dmirror_devices[ndevices++].zone_device_type =
+   HMM_DMIRROR_MEMORY_DEVICE_PRIVATE;
+   for (id = 0; id < ndevices; id++) {
ret = dmirror_device_init(dmirror_devices + id, id);
if (ret)
goto err_chrdev;
diff --git a/lib/test_hmm_uapi.h b/lib/test_hmm_uapi.h
index f14dea5dcd06..0511af7464ee 100644
--- a/lib/test_hmm_uapi.h
+++ b/lib/test_hmm_uapi.h
@@ -31,10 +31,11 @@ struct hmm_dmirror_cmd {
 /* Expose the address space of the calling process through hmm device file */
 #define HMM_DMIRROR_READ   _IOWR('H', 0x00, struct hmm_dmirror_cmd)
 #define HMM_DMIRROR_WRITE  _IOWR('H', 0x01, struct hmm_dmirror_cmd)
-#define HMM_DMIRROR_MIGRATE_IOWR('H', 0x02, struct hmm_dmirror_cmd)
-#define HMM_DMIRROR_SNAPSHOT   _IOWR('H', 0x03, struct hmm_dmirror_cmd)
-#define HMM_DMIRROR_EXCLUSIVE  _IOWR('H', 0x04, struct hmm_dmirror_cmd)
-#define HMM_DMIRROR_CHECK_EXCLUSIVE_IOWR('H', 0x05, struct hmm_dmirror_cmd)
+#define HMM_DMIRROR_MIGRATE_TO_DEV _IOWR('H', 0x02, struct hmm_dmirror_cmd)
+#define HMM_DMIRROR_MIGRATE_TO_SYS _IOWR('H', 0x03, struct hmm_dmirror_cmd)
+#define HMM_DMIRROR_SNAPSHOT   _IOWR('H', 0x04, struct hmm_dmirror_cmd)
+#define HMM_DMIRROR_EXCLUSIVE  _IOWR('H', 0x05, struct hmm_dmirror_cmd)
+#define HMM_DMIRROR_CHECK_EXCLUSIVE_IOWR('H', 0x06, struct hmm_dmirror_cmd)
 
 /*
  * Values returned in hmm_dmirror_cmd.ptr for HMM_DMIRROR_SNAPSHOT.
@@ -62,4 +63,9 @@ enum {
HMM_DMIRROR_PROT_DEV_PRIVATE_REMOTE = 0x30,
 };
 
+enum {
+   /* 0 is reserved to catch uninitialized type fields */
+   HMM_DMIRROR_MEMORY_DEVICE_PRIVATE = 1,
+};
+
 #endif /* _LIB_TEST_HMM_UAPI_H */
-- 
2.32.0

Re: [PATCH v2 16/29] ACPI: video: Add Nvidia WMI EC brightness control detection

2022-07-16 Thread Hans de Goede

Hi,

On 7/15/22 17:32, Daniel Dadap wrote:
> 
> 
>> On Jul 15, 2022, at 06:59, Hans de Goede  wrote:
>>
>> Hi Daniel,
>>
>>> On 7/12/22 22:13, Daniel Dadap wrote:
>>> Thanks, Hans:
>>>
 On 7/12/22 14:38, Hans de Goede wrote:
 On some new laptop designs a new Nvidia specific WMI interface is present
 which gives info about panel brightness control and may allow controlling
 the brightness through this interface when the embedded controller is used
 for brightness control.

 When this WMI interface is present and indicates that the EC is used,
 then this interface should be used for brightness control.

 Signed-off-by: Hans de Goede 
 ---
   drivers/acpi/Kconfig   |  1 +
   drivers/acpi/video_detect.c| 35 ++
   drivers/gpu/drm/gma500/Kconfig |  2 ++
   drivers/gpu/drm/i915/Kconfig   |  2 ++
   include/acpi/video.h   |  1 +
   5 files changed, 41 insertions(+)

 diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
 index 1e34f846508f..c372385cfc3f 100644
 --- a/drivers/acpi/Kconfig
 +++ b/drivers/acpi/Kconfig
 @@ -212,6 +212,7 @@ config ACPI_VIDEO
   tristate "Video"
   depends on X86 && BACKLIGHT_CLASS_DEVICE
   depends on INPUT
 +depends on ACPI_WMI
   select THERMAL
   help
 This driver implements the ACPI Extensions For Display Adapters
 diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
 index 8c2863403040..7b89dc9a04a2 100644
 --- a/drivers/acpi/video_detect.c
 +++ b/drivers/acpi/video_detect.c
 @@ -75,6 +75,35 @@ find_video(acpi_handle handle, u32 lvl, void *context, 
 void **rv)
   return AE_OK;
   }
   +#define WMI_BRIGHTNESS_METHOD_SOURCE2
 +#define WMI_BRIGHTNESS_MODE_GET0
 +#define WMI_BRIGHTNESS_SOURCE_EC2
 +
 +struct wmi_brightness_args {
 +u32 mode;
 +u32 val;
 +u32 ret;
 +u32 ignored[3];
 +};
 +
 +static bool nvidia_wmi_ec_supported(void)
 +{
 +struct wmi_brightness_args args = {
 +.mode = WMI_BRIGHTNESS_MODE_GET,
 +.val = 0,
 +.ret = 0,
 +};
 +struct acpi_buffer buf = { (acpi_size)sizeof(args),  };
 +acpi_status status;
 +
 +status = wmi_evaluate_method("603E9613-EF25-4338-A3D0-C46177516DB7", 
 0,
 + WMI_BRIGHTNESS_METHOD_SOURCE, , );
 +if (ACPI_FAILURE(status))
 +return false;
 +
 +return args.ret == WMI_BRIGHTNESS_SOURCE_EC;
 +}
 +
>>>
>>>
>>> The code duplication here with nvidia-wmi-ec-backlight.c is a little 
>>> unfortunate. Can we move the constants, struct definition, and WMI GUID 
>>> from that file to a header file that's used both by the EC backlight driver 
>>> and the ACPI video driver?
>>
>> Yes that is a good idea. I suggest using 
>> include/linux/platform_data/x86/nvidia-wmi-ec-backlight.h
>> to move the shared definitions there.
>>
>> If you can submit 2 patches on top of this series:
>>
>> 1. Moving the definitions from 
>> drivers/platform/x86/nvidia-wmi-ec-backlight.c to
>>   include/linux/platform_data/x86/nvidia-wmi-ec-backlight.h
>>
>> 2. Switching the code from this patch over to using the new 
>> nvidia-wmi-ec-backlight.h
>>
>> Then for the next version I'll add patch 1. to the series and squash patch 2.
>> into this one.
>>
>>> I was thinking it might be nice to add a wrapper around 
>>> wmi_brightness_notify() in nvidia-wmi-ec-backlight.c that does this source 
>>> == WMI_BRIGHTNESS_SOURCE_EC test, and then export it so that it can be 
>>> called both here and in the EC backlight driver's probe routine, but then I 
>>> guess that would make video.ko depend on nvidia-wmi-ec-backlight.ko, which 
>>> seems wrong. It also seems wrong to implement the WMI plumbing in the ACPI 
>>> video driver, and export it so that the EC backlight driver can use it, so 
>>> I guess I can live with the duplication of the relatively simple WMI stuff 
>>> here, it would just be nice to not have to define all of the API constants, 
>>> structure, and GUID twice.
>>
>> Agreed.
>>
>>>
>>>
   /* Force to use vendor driver when the ACPI device is known to be
* buggy */
   static int video_detect_force_vendor(const struct dmi_system_id *d)
 @@ -518,6 +547,7 @@ static const struct dmi_system_id 
 video_detect_dmi_table[] = {
   static enum acpi_backlight_type __acpi_video_get_backlight_type(bool 
 native)
   {
   static DEFINE_MUTEX(init_mutex);
 +static bool nvidia_wmi_ec_present;
   static bool native_available;
   static bool init_done;
   static long video_caps;
 @@ -530,6 +560,7 @@ static enum acpi_backlight_type 
 __acpi_video_get_backlight_type(bool native)

[PATCH v9 03/14] mm: add zone device coherent type memory support

Device memory that is cache coherent from device and CPU point of view.
This is used on platforms that have an advanced system bus (like CAPI
or CXL). Any page of a process can be migrated to such memory. However,
no one should be allowed to pin such memory so that it can always be
evicted.

Signed-off-by: Alex Sierra 
Acked-by: Felix Kuehling 
Reviewed-by: Alistair Popple 
[hch: rebased ontop of the refcount changes,
  removed is_dev_private_or_coherent_page]
Signed-off-by: Christoph Hellwig 
Acked-by: David Hildenbrand 
---
 include/linux/memremap.h | 19 +++
 include/linux/mm.h   |  5 -
 mm/memcontrol.c  |  7 ---
 mm/memory-failure.c  |  8 ++--
 mm/memremap.c| 10 ++
 mm/migrate_device.c  | 16 +++-
 mm/rmap.c|  5 +++--
 7 files changed, 53 insertions(+), 17 deletions(-)

diff --git a/include/linux/memremap.h b/include/linux/memremap.h
index 77229165c914..f27b142fd3d0 100644
--- a/include/linux/memremap.h
+++ b/include/linux/memremap.h
@@ -41,6 +41,13 @@ struct vmem_altmap {
  * A more complete discussion of unaddressable memory may be found in
  * include/linux/hmm.h and Documentation/vm/hmm.rst.
  *
+ * MEMORY_DEVICE_COHERENT:
+ * Device memory that is cache coherent from device and CPU point of view. This
+ * is used on platforms that have an advanced system bus (like CAPI or CXL). A
+ * driver can hotplug the device memory using ZONE_DEVICE and with that memory
+ * type. Any page of a process can be migrated to such memory. However no one
+ * should be allowed to pin such memory so that it can always be evicted.
+ *
  * MEMORY_DEVICE_FS_DAX:
  * Host memory that has similar access semantics as System RAM i.e. DMA
  * coherent and supports page pinning. In support of coordinating page
@@ -61,6 +68,7 @@ struct vmem_altmap {
 enum memory_type {
/* 0 is reserved to catch uninitialized type fields */
MEMORY_DEVICE_PRIVATE = 1,
+   MEMORY_DEVICE_COHERENT,
MEMORY_DEVICE_FS_DAX,
MEMORY_DEVICE_GENERIC,
MEMORY_DEVICE_PCI_P2PDMA,
@@ -150,6 +158,17 @@ static inline bool is_pci_p2pdma_page(const struct page 
*page)
page->pgmap->type == MEMORY_DEVICE_PCI_P2PDMA;
 }
 
+static inline bool is_device_coherent_page(const struct page *page)
+{
+   return is_zone_device_page(page) &&
+   page->pgmap->type == MEMORY_DEVICE_COHERENT;
+}
+
+static inline bool folio_is_device_coherent(const struct folio *folio)
+{
+   return is_device_coherent_page(>page);
+}
+
 #ifdef CONFIG_ZONE_DEVICE
 void *memremap_pages(struct dev_pagemap *pgmap, int nid);
 void memunmap_pages(struct dev_pagemap *pgmap);
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 2df8c2b98d36..3ed101dfbfab 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 
 struct mempolicy;
 struct anon_vma;
@@ -1522,7 +1523,9 @@ static inline bool is_longterm_pinnable_page(struct page 
*page)
if (mt == MIGRATE_CMA || mt == MIGRATE_ISOLATE)
return false;
 #endif
-   return !is_zone_movable_page(page) || is_zero_pfn(page_to_pfn(page));
+   return !(is_device_coherent_page(page) ||
+is_zone_movable_page(page) ||
+is_zero_pfn(page_to_pfn(page)));
 }
 #else
 static inline bool is_longterm_pinnable_page(struct page *page)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 618c366a2f07..5d37a85c67da 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -5665,8 +5665,8 @@ static int mem_cgroup_move_account(struct page *page,
  *   2(MC_TARGET_SWAP): if the swap entry corresponding to this pte is a
  * target for charge migration. if @target is not NULL, the entry is stored
  * in target->ent.
- *   3(MC_TARGET_DEVICE): like MC_TARGET_PAGE  but page is 
MEMORY_DEVICE_PRIVATE
- * (so ZONE_DEVICE page and thus not on the lru).
+ *   3(MC_TARGET_DEVICE): like MC_TARGET_PAGE  but page is device memory and
+ *   thus not on the lru.
  * For now we such page is charge like a regular page would be as for all
  * intent and purposes it is just special memory taking the place of a
  * regular page.
@@ -5704,7 +5704,8 @@ static enum mc_target_type get_mctgt_type(struct 
vm_area_struct *vma,
 */
if (page_memcg(page) == mc.from) {
ret = MC_TARGET_PAGE;
-   if (is_device_private_page(page))
+   if (is_device_private_page(page) ||
+   is_device_coherent_page(page))
ret = MC_TARGET_DEVICE;
if (target)
target->page = page;
diff --git a/mm/memory-failure.c b/mm/memory-failure.c
index da39ec8afca8..79f175eeb190 100644
--- a/mm/memory-failure.c
+++ b/mm/memory-failure.c
@@ -1685,12 +1685,16 @@ static int memory_failure_dev_pagemap(unsigned long 
pfn, int

Re: [PATCH 3/3] drm/komeda - Fix handling of pending crtc state commit to avoid lock-up

2022-07-16 Thread Carsten Haitzler





On 7/14/22 13:20, Robin Murphy wrote:

On 2022-07-11 11:13, Liviu Dudau wrote:
[...]

But nothing worrying. It does work, though doesn't compile due to:

drivers/gpu/drm/arm/display/komeda/komeda_kms.c: In function
‘komeda_kms_atomic_commit_hw_done’:
drivers/gpu/drm/arm/display/komeda/komeda_kms.c:77:9: error: ‘for’ loop
initial declarations are only allowed in C99 or C11 mode
    77 | for (int i = 0; i < kms->n_crtcs; i++) {
   | ^~~
drivers/gpu/drm/arm/display/komeda/komeda_kms.c:77:9: note: use option
‘-std=c9
’, ‘-std=gnu99’, ‘-std=c11’ or ‘-std=gnu11’ to compile your code

but that was a trivial fixup.


Interesting that I'm not seeing that, probably due to using GCC12? 
Anyway, I'll fix

that and send a proper patch.


FWIW we do use -std=gnu11 since 5.18 (see e8c07082a810), but I'm not 
entirely sure what the status quo is for using the new features in fixes 
which might also warrant backporting to stable. I believe Carsten's 
stuck on an older kernel thanks to constraints of the rest of that 
project ;)


Not that old - my last sync was like end of April, but i was basing my 
commits off a stable kernel release tree (5.17.4), I have multiple 
kernels for different purposes and for this stuck to something released 
vaguely recently (i synced my tree to latest release before sending off 
the patch set). I'm not sure on the kernel policy for the above for (int 
i = 0;...) etc. usage. I tend to still be more conservative and keep my 
vars at top of the block anyway out of decades of habit.

Re: [PATCH v5 11/13] leds: mt6370: Add MediaTek MT6370 current sink type LED Indicator support

On Fri, Jul 15, 2022 at 2:40 PM AngeloGioacchino Del Regno
 wrote:
> Il 15/07/22 13:26, ChiaEn Wu ha scritto:

...

> > +#define STATE_OFF0
> > +#define STATE_KEEP   1
> > +#define STATE_ON 2
>
> I propose, instead:
>
> enum mt6370_state {
> STATE_OFF = 0,
> STATE_KEEP,
> STATE_ON,

> STATE_MAX,

Usually we don't put commas at the terminator entries.

> };

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v2 16/29] ACPI: video: Add Nvidia WMI EC brightness control detection

2022-07-16 Thread Daniel Dadap



> On Jul 15, 2022, at 06:59, Hans de Goede  wrote:
> 
> Hi Daniel,
> 
>> On 7/12/22 22:13, Daniel Dadap wrote:
>> Thanks, Hans:
>> 
>>> On 7/12/22 14:38, Hans de Goede wrote:
>>> On some new laptop designs a new Nvidia specific WMI interface is present
>>> which gives info about panel brightness control and may allow controlling
>>> the brightness through this interface when the embedded controller is used
>>> for brightness control.
>>> 
>>> When this WMI interface is present and indicates that the EC is used,
>>> then this interface should be used for brightness control.
>>> 
>>> Signed-off-by: Hans de Goede 
>>> ---
>>>   drivers/acpi/Kconfig   |  1 +
>>>   drivers/acpi/video_detect.c| 35 ++
>>>   drivers/gpu/drm/gma500/Kconfig |  2 ++
>>>   drivers/gpu/drm/i915/Kconfig   |  2 ++
>>>   include/acpi/video.h   |  1 +
>>>   5 files changed, 41 insertions(+)
>>> 
>>> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
>>> index 1e34f846508f..c372385cfc3f 100644
>>> --- a/drivers/acpi/Kconfig
>>> +++ b/drivers/acpi/Kconfig
>>> @@ -212,6 +212,7 @@ config ACPI_VIDEO
>>>   tristate "Video"
>>>   depends on X86 && BACKLIGHT_CLASS_DEVICE
>>>   depends on INPUT
>>> +depends on ACPI_WMI
>>>   select THERMAL
>>>   help
>>> This driver implements the ACPI Extensions For Display Adapters
>>> diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
>>> index 8c2863403040..7b89dc9a04a2 100644
>>> --- a/drivers/acpi/video_detect.c
>>> +++ b/drivers/acpi/video_detect.c
>>> @@ -75,6 +75,35 @@ find_video(acpi_handle handle, u32 lvl, void *context, 
>>> void **rv)
>>>   return AE_OK;
>>>   }
>>>   +#define WMI_BRIGHTNESS_METHOD_SOURCE2
>>> +#define WMI_BRIGHTNESS_MODE_GET0
>>> +#define WMI_BRIGHTNESS_SOURCE_EC2
>>> +
>>> +struct wmi_brightness_args {
>>> +u32 mode;
>>> +u32 val;
>>> +u32 ret;
>>> +u32 ignored[3];
>>> +};
>>> +
>>> +static bool nvidia_wmi_ec_supported(void)
>>> +{
>>> +struct wmi_brightness_args args = {
>>> +.mode = WMI_BRIGHTNESS_MODE_GET,
>>> +.val = 0,
>>> +.ret = 0,
>>> +};
>>> +struct acpi_buffer buf = { (acpi_size)sizeof(args),  };
>>> +acpi_status status;
>>> +
>>> +status = wmi_evaluate_method("603E9613-EF25-4338-A3D0-C46177516DB7", 0,
>>> + WMI_BRIGHTNESS_METHOD_SOURCE, , );
>>> +if (ACPI_FAILURE(status))
>>> +return false;
>>> +
>>> +return args.ret == WMI_BRIGHTNESS_SOURCE_EC;
>>> +}
>>> +
>> 
>> 
>> The code duplication here with nvidia-wmi-ec-backlight.c is a little 
>> unfortunate. Can we move the constants, struct definition, and WMI GUID from 
>> that file to a header file that's used both by the EC backlight driver and 
>> the ACPI video driver?
> 
> Yes that is a good idea. I suggest using 
> include/linux/platform_data/x86/nvidia-wmi-ec-backlight.h
> to move the shared definitions there.
> 
> If you can submit 2 patches on top of this series:
> 
> 1. Moving the definitions from drivers/platform/x86/nvidia-wmi-ec-backlight.c 
> to
>   include/linux/platform_data/x86/nvidia-wmi-ec-backlight.h
> 
> 2. Switching the code from this patch over to using the new 
> nvidia-wmi-ec-backlight.h
> 
> Then for the next version I'll add patch 1. to the series and squash patch 2.
> into this one.
> 
>> I was thinking it might be nice to add a wrapper around 
>> wmi_brightness_notify() in nvidia-wmi-ec-backlight.c that does this source 
>> == WMI_BRIGHTNESS_SOURCE_EC test, and then export it so that it can be 
>> called both here and in the EC backlight driver's probe routine, but then I 
>> guess that would make video.ko depend on nvidia-wmi-ec-backlight.ko, which 
>> seems wrong. It also seems wrong to implement the WMI plumbing in the ACPI 
>> video driver, and export it so that the EC backlight driver can use it, so I 
>> guess I can live with the duplication of the relatively simple WMI stuff 
>> here, it would just be nice to not have to define all of the API constants, 
>> structure, and GUID twice.
> 
> Agreed.
> 
>> 
>> 
>>>   /* Force to use vendor driver when the ACPI device is known to be
>>>* buggy */
>>>   static int video_detect_force_vendor(const struct dmi_system_id *d)
>>> @@ -518,6 +547,7 @@ static const struct dmi_system_id 
>>> video_detect_dmi_table[] = {
>>>   static enum acpi_backlight_type __acpi_video_get_backlight_type(bool 
>>> native)
>>>   {
>>>   static DEFINE_MUTEX(init_mutex);
>>> +static bool nvidia_wmi_ec_present;
>>>   static bool native_available;
>>>   static bool init_done;
>>>   static long video_caps;
>>> @@ -530,6 +560,7 @@ static enum acpi_backlight_type 
>>> __acpi_video_get_backlight_type(bool native)
>>>   acpi_walk_namespace(ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT,
>>>   ACPI_UINT32_MAX, find_video, NULL,
>>>   _caps, NULL);
>>> +

[PATCH v9 10/14] lib: add support for device coherent type in test_hmm