[BUG] most: usb: Found a bug at the probe time
Hello, I found a bug in the most usb driver. When the driver fails at mdev->conf = kcalloc(num_endpoints, sizeof(*mdev->conf), GFP_KERNEL); I got the following warning message: [ 15.406256] kobject: '(null)' (8881068f8000): is not initialized, yet kobject_put() is being called. [ 15.406986] WARNING: CPU: 3 PID: 396 at lib/kobject.c:720 kobject_put+0x6e/0x1c0 [ 15.410120] RIP: 0010:kobject_put+0x6e/0x1c0 [ 15.410470] Code: 01 75 29 4c 89 f8 48 c1 e8 03 80 3c 28 00 74 08 4c 89 ff e8 14 2e 73 ff 49 8b 37 48 c7 c7 c0 fc de 85 4c 89 fa e8 e2 61 21 ff <0f> 0b 49 8d 5f 38 48 89 df be 04 00 00 00 e8 df 2e 73 ff b8 ff ff [ 15.416529] Call Trace: [ 15.416896] hdm_probe+0xf3d/0x1090 [most_usb] Since I'm not familiar with the driver, I ask for your help to solve the warning. regards, Zheyu Ma
Re: [linux-next:master] BUILD REGRESSION 4662b7adea50bb62e993a67f611f3be625d3df0d
* Andrew Morton [220716 21:03]: > On Thu, 14 Jul 2022 09:56:19 +0800 kernel test robot wrote: > > > lib/maple_tree.c:1522:52: warning: Parameter 'gaps' can be declared with > > const [constParameter] > > lib/maple_tree.c:1871:21: warning: Array index 'split' is used before > > limits check. [arrayIndexThenCheck] > > lib/maple_tree.c:2033:55: warning: Parameter 'mas' can be declared with > > const [constParameter] > > lib/maple_tree.c:2426:8: warning: Redundant initialization for 'r_tmp'. The > > initialized value is overwritten before it is read. > > [redundantInitialization] > > lib/maple_tree.c:2427:8: warning: Redundant initialization for 'l_tmp'. The > > initialized value is overwritten before it is read. > > [redundantInitialization] > > lib/maple_tree.c:3160:22: warning: Found suspicious operator ',' > > [constStatement] > > lib/maple_tree.c:3208:11: warning: Size of pointer 'pivs' used instead of > > size of its data. [pointerSize] > > lib/maple_tree.c:326:2: warning: Assignment of function parameter has no > > effect outside the function. Did you forget dereferencing it? > > [uselessAssignmentPtrArg] > > lib/maple_tree.c:4266:15: warning: The if condition is the same as the > > previous if condition [duplicateCondition] > > lib/maple_tree.c:4302:23: warning: Boolean result is used in bitwise > > operation. Clarify expression with parentheses. [clarifyCondition] > > lib/maple_tree.c:694:59: warning: Parameter 'pivots' can be declared with > > const [constParameter] > > lib/test_printf.c:415:11: warning: Local variable 'addr' shadows outer > > function [shadowFunction] > > mm/highmem.c:737:13: warning: Uninitialized variable: pam->page [uninitvar] > > mm/migrate.c:355:53: warning: Parameter 'mapping' can be declared with > > const [constParameter] > > mm/migrate.c:875:7: warning: Redundant initialization for 'rc'. The > > initialized value is overwritten before it is read. > > [redundantInitialization] > > mm/mlock.c:230:20: warning: Using pointer that is a temporary. > > [danglingTemporaryLifetime] > > mm/slab.c:1635:24: warning: Uninitialized variables: slab.__page_flags, > > slab.__unused_1, slab.freelist, slab.units, slab.__unused_2, > > slab.__page_refcount [uninitvar] > > mm/slab.c:3289:7: warning: Redundant assignment of 'objp' to itself. > > [selfAssignment] > > mm/slab.c:3509:8: warning: Redundant assignment of 'p[i]' to itself. > > [selfAssignment] > > mm/slab.c:405:9: warning: Local variable 'slab_size' shadows outer function > > [shadowFunction] > > mm/vmstat.c:1409:53: warning: Parameter 'pos' can be declared with const > > [constParameter] > > mm/vmstat.c:1650:68: warning: Parameter 'zone' can be declared with const > > [constParameter] > > mm/zsmalloc.c:2019:15: warning: Uninitialized variables: zspage.huge, > > zspage.fullness, zspage.class, zspage.isolated, zspage.magic, zspage.inuse, > > zspage.freeobj, zspage.first_page, zspage.lock [uninitvar] > > mm/zsmalloc.c:2060:16: warning: Local variable 'obj_allocated' shadows > > outer function [shadowFunction] > > urgh, thanks, lots of stuff to go through here. > > Liam, I suggest we worry about the mapletree things at a later time ;) Thanks. I'll dig into them on top of v11, which I just sent out.
Re: [linux-next:master] BUILD REGRESSION 4662b7adea50bb62e993a67f611f3be625d3df0d
On Thu, 14 Jul 2022 09:56:19 +0800 kernel test robot wrote: > lib/maple_tree.c:1522:52: warning: Parameter 'gaps' can be declared with > const [constParameter] > lib/maple_tree.c:1871:21: warning: Array index 'split' is used before limits > check. [arrayIndexThenCheck] > lib/maple_tree.c:2033:55: warning: Parameter 'mas' can be declared with const > [constParameter] > lib/maple_tree.c:2426:8: warning: Redundant initialization for 'r_tmp'. The > initialized value is overwritten before it is read. [redundantInitialization] > lib/maple_tree.c:2427:8: warning: Redundant initialization for 'l_tmp'. The > initialized value is overwritten before it is read. [redundantInitialization] > lib/maple_tree.c:3160:22: warning: Found suspicious operator ',' > [constStatement] > lib/maple_tree.c:3208:11: warning: Size of pointer 'pivs' used instead of > size of its data. [pointerSize] > lib/maple_tree.c:326:2: warning: Assignment of function parameter has no > effect outside the function. Did you forget dereferencing it? > [uselessAssignmentPtrArg] > lib/maple_tree.c:4266:15: warning: The if condition is the same as the > previous if condition [duplicateCondition] > lib/maple_tree.c:4302:23: warning: Boolean result is used in bitwise > operation. Clarify expression with parentheses. [clarifyCondition] > lib/maple_tree.c:694:59: warning: Parameter 'pivots' can be declared with > const [constParameter] > lib/test_printf.c:415:11: warning: Local variable 'addr' shadows outer > function [shadowFunction] > mm/highmem.c:737:13: warning: Uninitialized variable: pam->page [uninitvar] > mm/migrate.c:355:53: warning: Parameter 'mapping' can be declared with const > [constParameter] > mm/migrate.c:875:7: warning: Redundant initialization for 'rc'. The > initialized value is overwritten before it is read. [redundantInitialization] > mm/mlock.c:230:20: warning: Using pointer that is a temporary. > [danglingTemporaryLifetime] > mm/slab.c:1635:24: warning: Uninitialized variables: slab.__page_flags, > slab.__unused_1, slab.freelist, slab.units, slab.__unused_2, > slab.__page_refcount [uninitvar] > mm/slab.c:3289:7: warning: Redundant assignment of 'objp' to itself. > [selfAssignment] > mm/slab.c:3509:8: warning: Redundant assignment of 'p[i]' to itself. > [selfAssignment] > mm/slab.c:405:9: warning: Local variable 'slab_size' shadows outer function > [shadowFunction] > mm/vmstat.c:1409:53: warning: Parameter 'pos' can be declared with const > [constParameter] > mm/vmstat.c:1650:68: warning: Parameter 'zone' can be declared with const > [constParameter] > mm/zsmalloc.c:2019:15: warning: Uninitialized variables: zspage.huge, > zspage.fullness, zspage.class, zspage.isolated, zspage.magic, zspage.inuse, > zspage.freeobj, zspage.first_page, zspage.lock [uninitvar] > mm/zsmalloc.c:2060:16: warning: Local variable 'obj_allocated' shadows outer > function [shadowFunction] urgh, thanks, lots of stuff to go through here. Liam, I suggest we worry about the mapletree things at a later time ;)
[Bug 216119] 087451f372bf76d breaks hibernation on amdgpu Radeon R9 390
https://bugzilla.kernel.org/show_bug.cgi?id=216119 --- Comment #33 from Harald Judt (h.j...@gmx.at) --- With "if I reboot the machine" I mean, if I shutdown/reboot it later after resume, then the shutdown messages get printed that strange way. -- 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] 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: 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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+
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
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
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
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
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
> 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
Device Coherent type uses device memory that is coherently accesible by the CPU. This could be shown as SP (special purpose) memory range at the BIOS-e820 memory enumeration. If no SP memory is supported in system, this could be faked by setting CONFIG_EFI_FAKE_MEMMAP. Currently, test_hmm only supports two different SP ranges of at least 256MB size. This could be specified in the kernel parameter variable efi_fake_mem. Ex. Two SP ranges of 1GB starting at 0x1 & 0x14000 physical address. Ex. efi_fake_mem=1G@0x1:0x4,1G@0x14000:0x4 Private and coherent device mirror instances can be created in the same probed. This is done by passing the module parameters spm_addr_dev0 & spm_addr_dev1. In this case, it will create four instances of device_mirror. The first two correspond to private device type, the last two to coherent type. Then, they can be easily accessed from user space through /dev/hmm_mirror. Usually num_device 0 and 1 are for private, and 2 and 3 for coherent types. If no module parameters are passed, two instances of private type device_mirror will be created only. Signed-off-by: Alex Sierra Acked-by: Felix Kuehling Reviewed-by: Alistair Poppple --- lib/test_hmm.c | 253 +--- lib/test_hmm_uapi.h | 4 + 2 files changed, 196 insertions(+), 61 deletions(-) diff --git a/lib/test_hmm.c b/lib/test_hmm.c index afb30af9f3ff..7930853e7fc5 100644 --- a/lib/test_hmm.c +++ b/lib/test_hmm.c @@ -32,11 +32,22 @@ #include "test_hmm_uapi.h" -#define DMIRROR_NDEVICES 2 +#define DMIRROR_NDEVICES 4 #define DMIRROR_RANGE_FAULT_TIMEOUT1000 #define DEVMEM_CHUNK_SIZE (256 * 1024 * 1024U) #define DEVMEM_CHUNKS_RESERVE 16 +/* + * For device_private pages, dpage is just a dummy struct page + * representing a piece of device memory. dmirror_devmem_alloc_page + * allocates a real system memory page as backing storage to fake a + * real device. zone_device_data points to that backing page. But + * for device_coherent memory, the struct page represents real + * physical CPU-accessible memory that we can use directly. + */ +#define BACKING_PAGE(page) (is_device_private_page((page)) ? \ + (page)->zone_device_data : (page)) + static unsigned long spm_addr_dev0; module_param(spm_addr_dev0, long, 0644); MODULE_PARM_DESC(spm_addr_dev0, @@ -125,6 +136,21 @@ static int dmirror_bounce_init(struct dmirror_bounce *bounce, return 0; } +static bool dmirror_is_private_zone(struct dmirror_device *mdevice) +{ + return (mdevice->zone_device_type == + HMM_DMIRROR_MEMORY_DEVICE_PRIVATE) ? true : false; +} + +static enum migrate_vma_direction +dmirror_select_device(struct dmirror *dmirror) +{ + return (dmirror->mdevice->zone_device_type == + HMM_DMIRROR_MEMORY_DEVICE_PRIVATE) ? + MIGRATE_VMA_SELECT_DEVICE_PRIVATE : + MIGRATE_VMA_SELECT_DEVICE_COHERENT; +} + static void dmirror_bounce_fini(struct dmirror_bounce *bounce) { vfree(bounce->ptr); @@ -575,16 +601,19 @@ static int dmirror_allocate_chunk(struct dmirror_device *mdevice, static struct page *dmirror_devmem_alloc_page(struct dmirror_device *mdevice) { struct page *dpage = NULL; - struct page *rpage; + struct page *rpage = NULL; /* -* This is a fake device so we alloc real system memory to store -* our device memory. +* For ZONE_DEVICE private type, this is a fake device so we allocate +* real system memory to store our device memory. +* For ZONE_DEVICE coherent type we use the actual dpage to store the +* data and ignore rpage. */ - rpage = alloc_page(GFP_HIGHUSER); - if (!rpage) - return NULL; - + if (dmirror_is_private_zone(mdevice)) { + rpage = alloc_page(GFP_HIGHUSER); + if (!rpage) + return NULL; + } spin_lock(>lock); if (mdevice->free_pages) { @@ -603,7 +632,8 @@ static struct page *dmirror_devmem_alloc_page(struct dmirror_device *mdevice) return dpage; error: - __free_page(rpage); + if (rpage) + __free_page(rpage); return NULL; } @@ -629,12 +659,16 @@ static void dmirror_migrate_alloc_and_copy(struct migrate_vma *args, * unallocated pte_none() or read-only zero page. */ spage = migrate_pfn_to_page(*src); + if (WARN(spage && is_zone_device_page(spage), +"page already in device spage pfn: 0x%lx\n", +page_to_pfn(spage))) + continue; dpage = dmirror_devmem_alloc_page(mdevice); if (!dpage) continue; - rpage = dpage->zone_device_data; + rpage = BACKING_PAGE(dpage);
Re: [PATCH v5 06/13] dt-bindings: mfd: Add MediaTek MT6370
On Fri, 15 Jul 2022 19:26:00 +0800, ChiaEn Wu wrote: > From: ChiYuan Huang > > Add MediaTek MT6370 binding documentation. > > Signed-off-by: ChiYuan Huang > Reviewed-by: Krzysztof Kozlowski > --- > .../devicetree/bindings/mfd/mediatek,mt6370.yaml | 280 > + > include/dt-bindings/iio/adc/mediatek,mt6370_adc.h | 18 ++ > 2 files changed, 298 insertions(+) > create mode 100644 Documentation/devicetree/bindings/mfd/mediatek,mt6370.yaml > create mode 100644 include/dt-bindings/iio/adc/mediatek,mt6370_adc.h > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' on your patch (DT_CHECKER_FLAGS is new in v5.13): yamllint warnings/errors: dtschema/dtc warnings/errors: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/mfd/mediatek,mt6370.example.dtb: pmic@34: indicator:multi-led@0:led@0: Unevaluated properties are not allowed ('reg' was unexpected) From schema: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/mfd/mediatek,mt6370.yaml /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/mfd/mediatek,mt6370.example.dtb: pmic@34: indicator:multi-led@0:led@1: Unevaluated properties are not allowed ('reg' was unexpected) From schema: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/mfd/mediatek,mt6370.yaml /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/mfd/mediatek,mt6370.example.dtb: pmic@34: indicator:multi-led@0:led@2: Unevaluated properties are not allowed ('reg' was unexpected) From schema: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/mfd/mediatek,mt6370.yaml /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/mfd/mediatek,mt6370.example.dtb: indicator: multi-led@0:led@0: Unevaluated properties are not allowed ('reg' was unexpected) From schema: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/leds/mediatek,mt6370-indicator.yaml /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/mfd/mediatek,mt6370.example.dtb: indicator: multi-led@0:led@1: Unevaluated properties are not allowed ('reg' was unexpected) From schema: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/leds/mediatek,mt6370-indicator.yaml /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/mfd/mediatek,mt6370.example.dtb: indicator: multi-led@0:led@2: Unevaluated properties are not allowed ('reg' was unexpected) From schema: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/leds/mediatek,mt6370-indicator.yaml doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/patch/ This check can fail if there are any dependencies. The base for a patch series is generally the most recent rc1. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit.
[PATCH 2/3] drm/i915/display: Use original src in psr2 sel fetch area calculation
drm_plane_state->src is modified when offset is calculated: before calculation: src.x1 = 8192, src.y1 = 8192 after calculation (pitch = 65536, cpp = 4, alignment = 262144) src.x1 = 8192, src.y1 = 0, offset = 0x2000 Damage clips are relative to original coodrdinates provided by user-space. To compare these against src coordinates we need to use original coordinates as provided by user-space. These can be obtained by using drm_plane_state_src. Signed-off-by: Jouni Högander --- drivers/gpu/drm/i915/display/intel_psr.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_psr.c b/drivers/gpu/drm/i915/display/intel_psr.c index 90599dd1cb1b..5c95e24dc8d6 100644 --- a/drivers/gpu/drm/i915/display/intel_psr.c +++ b/drivers/gpu/drm/i915/display/intel_psr.c @@ -1767,7 +1767,8 @@ int intel_psr2_sel_fetch_update(struct intel_atomic_state *state, continue; } - drm_rect_fp_to_int(, _plane_state->uapi.src); + src = drm_plane_state_src(_plane_state->uapi); + drm_rect_fp_to_int(, ); drm_atomic_helper_damage_iter_init(, _plane_state->uapi, -- 2.25.1
[PATCH 3/3] drm/i915/display: Use drm helper instead of own loop for damage clips
Use existing drm_atomic_helper_damage_merged from generic drm code instead of implementing own loop to iterate over damage_clips. Signed-off-by: Jouni Högander --- drivers/gpu/drm/i915/display/intel_psr.c | 17 + 1 file changed, 5 insertions(+), 12 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_psr.c b/drivers/gpu/drm/i915/display/intel_psr.c index 5c95e24dc8d6..d44662f19b53 100644 --- a/drivers/gpu/drm/i915/display/intel_psr.c +++ b/drivers/gpu/drm/i915/display/intel_psr.c @@ -1721,8 +1721,6 @@ int intel_psr2_sel_fetch_update(struct intel_atomic_state *state, new_plane_state, i) { struct drm_rect src, damaged_area = { .x1 = 0, .y1 = -1, .x2 = INT_MAX }; - struct drm_atomic_helper_damage_iter iter; - struct drm_rect clip; if (new_plane_state->uapi.crtc != crtc_state->uapi.crtc) continue; @@ -1770,20 +1768,15 @@ int intel_psr2_sel_fetch_update(struct intel_atomic_state *state, src = drm_plane_state_src(_plane_state->uapi); drm_rect_fp_to_int(, ); - drm_atomic_helper_damage_iter_init(, - _plane_state->uapi, - _plane_state->uapi); - drm_atomic_for_each_plane_damage(, ) { - if (drm_rect_intersect(, )) - clip_area_update(_area, , -_state->pipe_src); - } - - if (damaged_area.y1 == -1) + if (!drm_atomic_helper_damage_merged(_plane_state->uapi, +_plane_state->uapi, _area)) continue; damaged_area.y1 += new_plane_state->uapi.dst.y1 - src.y1; damaged_area.y2 += new_plane_state->uapi.dst.y1 - src.y1; + damaged_area.x1 += new_plane_state->uapi.dst.x1 - src.x1; + damaged_area.x2 += new_plane_state->uapi.dst.x1 - src.x1; + clip_area_update(_clip, _area, _state->pipe_src); } -- 2.25.1