Re: [PATCH v4 01/10] drm/print: Fix and add support for NULL as first argument in drm_* macros

2023-01-05 Thread Siddh Raman Pant
On Fri, 06 Jan 2023 06:43:35 +0530, kernel test robot wrote
> Hi Siddh,
> 
> Thank you for the patch! Perhaps something to improve:

Yes, I sent the rectification as a reply to this patch. [1]
Reviewers may please take note.

Thanks,
Siddh

[1] https://lore.kernel.org/all/20230105224018.132302-1-c...@siddh.me/


Re: [PATCH] drm/msm: Set preferred depth.

2023-01-05 Thread Dmitry Baryshkov

On 06/01/2023 09:16, Steev Klimaszewski wrote:

As of commit 37c90d589dc0 ("drm/fb-helper: Fix single-probe color-format
selection"), if no supported color formats are found, it tries to use the
driver provided default, which msm didn't have set and leads to the
following output:

msm_dpu ae01000.display-controller: [drm] bpp/depth value of 32/0 not supported
msm_dpu ae01000.display-controller: [drm] bpp/depth value of 32/0 not supported
msm_dpu ae01000.display-controller: [drm] bpp/depth value of 32/0 not supported
msm_dpu ae01000.display-controller: [drm] No compatible format found
[ cut here ]
WARNING: CPU: 0 PID: 73 at drivers/gpu/drm/drm_atomic.c:1604 
__drm_atomic_helper_set_config+0x240/0x33c
Modules linked in: ext4 mbcache jbd2 msm mdt_loader ocmem gpu_sched llcc_qcom 
gpio_keys qrtr
CPU: 0 PID: 73 Comm: kworker/u16:2 Not tainted 6.2.0-rc2-next-20230106 #53
Hardware name: LENOVO 21BX0015US/21BX0015US, BIOS N3HET74W (1.46 ) 10/12/2022
Workqueue: events_unbound deferred_probe_work_func
pstate: 8045 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : __drm_atomic_helper_set_config+0x240/0x33c
lr : __drm_atomic_helper_set_config+0x68/0x33c
sp : 88a7b790
x29: 88a7b790 x28: 73ee3e130a00 x27: 
x26: 73ee3d256e00 x25: 0038 x24: 73e6c0d65e00
x23: 73e6c17a7800 x22: 73e6c0d64e00 x21: 73e79c025e00
x20: c0d64e00 x19: 73ee3e130a00 x18: 
x17: 662074616d726f66 x16: 20656c6269746170 x15: 
x14:  x13:  x12: 
x11:  x10:  x9 : a829144ff8bc
x8 :  x7 :  x6 : 
x5 : 73e6c0d65f50 x4 : 73ee3d254950 x3 : 73e6c0d65ec0
x2 : 73ee3c953a00 x1 : 73e79c025580 x0 : 
Call trace:
__drm_atomic_helper_set_config+0x240/0x33c
drm_client_modeset_commit_atomic+0x160/0x280
drm_client_modeset_commit_locked+0x64/0x194
drm_client_modeset_commit+0x38/0x60
__drm_fb_helper_initial_config_and_unlock+0x528/0x63c
drm_fb_helper_initial_config+0x54/0x64
msm_fbdev_init+0x94/0xfc [msm]
msm_drm_bind+0x548/0x614 [msm]
try_to_bring_up_aggregate_device+0x1e4/0x2d0
__component_add+0xc4/0x1c0
component_add+0x1c/0x2c
dp_display_probe+0x2a4/0x460 [msm]
platform_probe+0x70/0xcc
really_probe+0xc8/0x3e0
__driver_probe_device+0x84/0x190
driver_probe_device+0x44/0x120
__device_attach_driver+0xc4/0x160
bus_for_each_drv+0x84/0xe0
__device_attach+0xa4/0x1cc
device_initial_probe+0x1c/0x2c
bus_probe_device+0xa4/0xb0
deferred_probe_work_func+0xc0/0x114
process_one_work+0x1ec/0x470
worker_thread+0x74/0x410
kthread+0xfc/0x110
ret_from_fork+0x10/0x20
---[ end trace  ]---

Signed-off-by: Steev Klimaszewski 
---
  drivers/gpu/drm/msm/msm_drv.c | 1 +
  1 file changed, 1 insertion(+)


Suggested-by: Dmitry Baryshkov 
Reviewed-by: Dmitry Baryshkov 

--
With best wishes
Dmitry



[PATCH] drm/msm: Set preferred depth.

2023-01-05 Thread Steev Klimaszewski
As of commit 37c90d589dc0 ("drm/fb-helper: Fix single-probe color-format
selection"), if no supported color formats are found, it tries to use the
driver provided default, which msm didn't have set and leads to the
following output:

msm_dpu ae01000.display-controller: [drm] bpp/depth value of 32/0 not supported
msm_dpu ae01000.display-controller: [drm] bpp/depth value of 32/0 not supported
msm_dpu ae01000.display-controller: [drm] bpp/depth value of 32/0 not supported
msm_dpu ae01000.display-controller: [drm] No compatible format found
[ cut here ]
WARNING: CPU: 0 PID: 73 at drivers/gpu/drm/drm_atomic.c:1604 
__drm_atomic_helper_set_config+0x240/0x33c
Modules linked in: ext4 mbcache jbd2 msm mdt_loader ocmem gpu_sched llcc_qcom 
gpio_keys qrtr
CPU: 0 PID: 73 Comm: kworker/u16:2 Not tainted 6.2.0-rc2-next-20230106 #53
Hardware name: LENOVO 21BX0015US/21BX0015US, BIOS N3HET74W (1.46 ) 10/12/2022
Workqueue: events_unbound deferred_probe_work_func
pstate: 8045 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : __drm_atomic_helper_set_config+0x240/0x33c
lr : __drm_atomic_helper_set_config+0x68/0x33c
sp : 88a7b790
x29: 88a7b790 x28: 73ee3e130a00 x27: 
x26: 73ee3d256e00 x25: 0038 x24: 73e6c0d65e00
x23: 73e6c17a7800 x22: 73e6c0d64e00 x21: 73e79c025e00
x20: c0d64e00 x19: 73ee3e130a00 x18: 
x17: 662074616d726f66 x16: 20656c6269746170 x15: 
x14:  x13:  x12: 
x11:  x10:  x9 : a829144ff8bc
x8 :  x7 :  x6 : 
x5 : 73e6c0d65f50 x4 : 73ee3d254950 x3 : 73e6c0d65ec0
x2 : 73ee3c953a00 x1 : 73e79c025580 x0 : 
Call trace:
__drm_atomic_helper_set_config+0x240/0x33c
drm_client_modeset_commit_atomic+0x160/0x280
drm_client_modeset_commit_locked+0x64/0x194
drm_client_modeset_commit+0x38/0x60
__drm_fb_helper_initial_config_and_unlock+0x528/0x63c
drm_fb_helper_initial_config+0x54/0x64
msm_fbdev_init+0x94/0xfc [msm]
msm_drm_bind+0x548/0x614 [msm]
try_to_bring_up_aggregate_device+0x1e4/0x2d0
__component_add+0xc4/0x1c0
component_add+0x1c/0x2c
dp_display_probe+0x2a4/0x460 [msm]
platform_probe+0x70/0xcc
really_probe+0xc8/0x3e0
__driver_probe_device+0x84/0x190
driver_probe_device+0x44/0x120
__device_attach_driver+0xc4/0x160
bus_for_each_drv+0x84/0xe0
__device_attach+0xa4/0x1cc
device_initial_probe+0x1c/0x2c
bus_probe_device+0xa4/0xb0
deferred_probe_work_func+0xc0/0x114
process_one_work+0x1ec/0x470
worker_thread+0x74/0x410
kthread+0xfc/0x110
ret_from_fork+0x10/0x20
---[ end trace  ]---

Signed-off-by: Steev Klimaszewski 
---
 drivers/gpu/drm/msm/msm_drv.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 8b0b0ac74a6f..65c4c93c311e 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -479,6 +479,7 @@ static int msm_drm_init(struct device *dev, const struct 
drm_driver *drv)
 
drm_helper_move_panel_connectors_to_head(ddev);
 
+   ddev->mode_config.preferred_depth = 24;
ddev->mode_config.funcs = _config_funcs;
ddev->mode_config.helper_private = _config_helper_funcs;
 
-- 
2.39.0



Re: [PATCH] drm/gem: Check for valid formats

2023-01-05 Thread Thomas Zimmermann

Hi

Am 05.01.23 um 19:22 schrieb Daniel Vetter:

On Thu, 5 Jan 2023 at 18:48, Maíra Canal  wrote:


On 1/5/23 12:26, Daniel Vetter wrote:

On Tue, Jan 03, 2023 at 09:53:23AM -0300, Maíra Canal wrote:

Currently, drm_gem_fb_create() doesn't check if the pixel format is
supported, which can lead to the acceptance of invalid pixel formats
e.g. the acceptance of invalid modifiers. Therefore, add a check for
valid formats on drm_gem_fb_create().

Moreover, note that this check is only valid for atomic drivers,
because, for non-atomic drivers, checking drm_any_plane_has_format() is
not possible since the format list for the primary plane is fake, and
we'd therefor reject valid formats.

Suggested-by: Thomas Zimmermann 
Signed-off-by: Maíra Canal 


Acked-by: Daniel Vetter 

I think to really make sure we have consensus it'd be good to extend this
to a series which removes all the callers to drm_any_plane_has_format()
from the various drivers, and then unexports that helper. That way your
series here will have more eyes on it :-)


I took a look at the callers to drm_any_plane_has_format() and there are only
3 callers (amdgpu, i915 and vmwgfx). They all use drm_any_plane_has_format()
before calling drm_framebuffer_init(). So, I'm not sure I could remove
drm_any_plane_has_format() from those drivers. Maybe adding this same check
to drm_gem_fb_init() and refactor the drivers to make them use 
drm_gem_fb_init(),
but I guess this would be part of a different series.


Well vmwgfx still not yet using gem afaik, so that doesn't work.


There was a patchset that converted vmwgfx to GEM IIRC. It even uses 
generic fbdev emulation now, for which GEM is a hard requirement.


Best regards
Thomas



But why can't we move the modifier check int drm_framebuffer_init()?
That's kinda where it probably should be anyway, there's nothing gem
bo specific in the code you're adding.
-Daniel


--
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 1/2] drm/atomic: Allow vblank-enabled + self-refresh "disable"

2023-01-05 Thread Greg KH
On Thu, Jan 05, 2023 at 05:40:17PM -0800, Brian Norris wrote:
> The self-refresh helper framework overloads "disable" to sometimes mean
> "go into self-refresh mode," and this mode activates automatically
> (e.g., after some period of unchanging display output). In such cases,
> the display pipe is still considered "on", and user-space is not aware
> that we went into self-refresh mode. Thus, users may expect that
> vblank-related features (such as DRM_IOCTL_WAIT_VBLANK) still work
> properly.
> 
> However, we trigger the WARN_ONCE() here if a CRTC driver tries to leave
> vblank enabled here.
> 
> Add a new exception, such that we allow CRTCs to be "disabled" (with
> self-refresh active) with vblank interrupts still enabled.
> 
> Cc:  # dependency for subsequent patch

"subsequent" doesn't mean much when it is committed, give it a name
perhaps?

thanks,

greg k-h


[PATCH v14 6/6] MAINTAINERS: add maintainer for i.MX8qxp DPU DRM driver

2023-01-05 Thread Liu Ying
Add myself as the maintainer of the i.MX8qxp DPU DRM driver.

Acked-by: Laurentiu Palcu 
Signed-off-by: Liu Ying 
---
v11->v14:
* No change.

v10->v11:
* Rebase upon v6.0-rc1.

v9->v10:
* Add Laurentiu's A-b tag.

v1->v9:
* No change.

 MAINTAINERS | 9 +
 1 file changed, 9 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 2e832cf29bec..cc0e7432ea2b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6918,6 +6918,15 @@ F:   
Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pixel-link.yaml
 F: 
Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pxl2dpi.yaml
 F: drivers/gpu/drm/bridge/imx/
 
+DRM DRIVERS FOR FREESCALE i.MX8QXP
+M: Liu Ying 
+L: dri-devel@lists.freedesktop.org
+S: Maintained
+F: Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dprc.yaml
+F: Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dpu.yaml
+F: Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-prg.yaml
+F: drivers/gpu/drm/imx/dpu/
+
 DRM DRIVERS FOR GMA500 (Poulsbo, Moorestown and derivative chipsets)
 M: Patrik Jakobsson 
 L: dri-devel@lists.freedesktop.org
-- 
2.37.1



[PATCH v14 4/6] drm/atomic: Avoid unused-but-set-variable warning on for_each_old_plane_in_state

2023-01-05 Thread Liu Ying
Artificially use 'plane' and 'old_plane_state' to avoid 'not used' warning.
The precedent has already been set by other macros in the same file.

Acked-by: Daniel Vetter 
Signed-off-by: Liu Ying 
---
v6->v14:
* No change.

v5->v6:
* Fix commit message typo - s/Artifically/Artificially/

v4->v5:
* No change.

v3->v4:
* Add Daniel's A-b tag.

v2->v3:
* Add a missing blank line.

v1->v2:
* No change.

 include/drm/drm_atomic.h | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
index 92586ab55ef5..e88876c29cdd 100644
--- a/include/drm/drm_atomic.h
+++ b/include/drm/drm_atomic.h
@@ -947,7 +947,10 @@ void drm_state_dump(struct drm_device *dev, struct 
drm_printer *p);
 (__i)++)   \
for_each_if ((__state)->planes[__i].ptr &&  \
 ((plane) = (__state)->planes[__i].ptr, \
- (old_plane_state) = 
(__state)->planes[__i].old_state, 1))
+ (void)(plane) /* Only to avoid 
unused-but-set-variable warning */, \
+ (old_plane_state) = 
(__state)->planes[__i].old_state, \
+ (void)(old_plane_state) /* Only to avoid 
unused-but-set-variable warning */, 1))
+
 /**
  * for_each_new_plane_in_state - iterate over all planes in an atomic update
  * @__state:  drm_atomic_state pointer
-- 
2.37.1



[PATCH v14 2/6] dt-bindings: display: imx: Add i.MX8qxp/qm PRG binding

2023-01-05 Thread Liu Ying
This patch adds bindings for i.MX8qxp/qm Display Prefetch Resolve Gasket.

Reviewed-by: Rob Herring 
Signed-off-by: Liu Ying 
---
v4->v14:
* No change.

v3->v4:
* Improve compatible property by using enum instead of oneOf+const. (Rob)
* Add Rob's R-b tag.

v2->v3:
* No change.

v1->v2:
* Use new dt binding way to add clocks in the example.

 .../bindings/display/imx/fsl,imx8qxp-prg.yaml | 60 +++
 1 file changed, 60 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-prg.yaml

diff --git a/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-prg.yaml 
b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-prg.yaml
new file mode 100644
index ..3ff46e0d4e73
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-prg.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/imx/fsl,imx8qxp-prg.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8qm/qxp Display Prefetch Resolve Gasket
+
+maintainers:
+  - Liu Ying 
+
+description: |
+  The i.MX8qm/qxp Prefetch Resolve Gasket (PRG) is a gasket interface between
+  RTRAM controller and Display Controller.  The main function is to convert
+  the AXI interface to the RTRAM interface, which includes re-mapping the
+  ARADDR to a RTRAM address.
+
+properties:
+  compatible:
+enum:
+  - fsl,imx8qxp-prg
+  - fsl,imx8qm-prg
+
+  reg:
+maxItems: 1
+
+  clocks:
+items:
+  - description: rtram clock
+  - description: apb clock
+
+  clock-names:
+items:
+  - const: rtram
+  - const: apb
+
+  power-domains:
+maxItems: 1
+
+required:
+  - compatible
+  - reg
+  - clocks
+  - clock-names
+  - power-domains
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+#include 
+prg@5604 {
+compatible = "fsl,imx8qxp-prg";
+reg = <0x5604 0x1>;
+clocks = <_prg0_lpcg IMX_LPCG_CLK_0>,
+ <_prg0_lpcg IMX_LPCG_CLK_4>;
+clock-names = "rtram", "apb";
+power-domains = < IMX_SC_R_DC_0>;
+};
-- 
2.37.1



[PATCH v14 3/6] dt-bindings: display: imx: Add i.MX8qxp/qm DPR channel binding

2023-01-05 Thread Liu Ying
This patch adds bindings for i.MX8qxp/qm Display Prefetch Resolve Channel.

Reviewed-by: Rob Herring 
Signed-off-by: Liu Ying 
---
v10->v14:
* No change.

v9->v10:
* Add Rob's R-b tag.

v8->v9:
* Reference 'interrupts-extended' schema instead of 'interrupts' to require
  an additional interrupt(r_rtram_stall) because the reference manual does
  mention it, though the driver doesn't get/use it for now.
  Reference 'interrupt-names' schema to define the two interrupt names -
  'dpr_wrap' and 'r_rtram_stall'.
* Drop Rob's R-b tag, as review is needed.

v4->v8:
* No change.

v3->v4:
* Improve compatible property by using enum instead of oneOf+const. (Rob)
* Add Rob's R-b tag.

v2->v3:
* No change.

v1->v2:
* Use new dt binding way to add clocks in the example.

 .../display/imx/fsl,imx8qxp-dprc.yaml | 100 ++
 1 file changed, 100 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dprc.yaml

diff --git 
a/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dprc.yaml 
b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dprc.yaml
new file mode 100644
index ..bd94254c1288
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dprc.yaml
@@ -0,0 +1,100 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/imx/fsl,imx8qxp-dprc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8qm/qxp Display Prefetch Resolve Channel
+
+maintainers:
+  - Liu Ying 
+
+description: |
+  The i.MX8qm/qxp Display Prefetch Resolve Channel(DPRC) is an engine which
+  fetches display data before the display pipeline needs the data to drive
+  pixels in the active display region.  This data is transformed, or resolved,
+  from a variety of tiled buffer formats into linear format, if needed.
+  The DPR works with a double bank memory structure.  This memory structure is
+  implemented in the Resolve Tile Memory(RTRAM) and the banks are referred to
+  as A and B.  Each bank is either 4 or 8 lines high depending on the source
+  frame buffer format.
+
+properties:
+  compatible:
+enum:
+  - fsl,imx8qxp-dpr-channel
+  - fsl,imx8qm-dpr-channel
+
+  reg:
+maxItems: 1
+
+  interrupts-extended:
+items:
+  - description: DPR wrap interrupt
+  - description: |
+  'r_rtram_stall' interrupt which indicates relevant i.MX8qm/qxp
+  Prefetch Resolve Gasket(PRG) or PRGs are forcing an underflow
+  condition in the RTRAM.
+
+  interrupt-names:
+items:
+  - const: dpr_wrap
+  - const: r_rtram_stall
+
+  clocks:
+items:
+  - description: apb clock
+  - description: b clock
+  - description: rtram clock
+
+  clock-names:
+items:
+  - const: apb
+  - const: b
+  - const: rtram
+
+  fsl,sc-resource:
+$ref: /schemas/types.yaml#/definitions/uint32
+description: The SCU resource ID associated with this DPRC instance.
+
+  fsl,prgs:
+$ref: /schemas/types.yaml#/definitions/phandle-array
+description: |
+  List of phandle which points to PRG or PRGs associated with
+  this DPRC instance.
+
+  power-domains:
+maxItems: 1
+
+required:
+  - compatible
+  - reg
+  - interrupts-extended
+  - interrupt-names
+  - clocks
+  - clock-names
+  - fsl,sc-resource
+  - fsl,prgs
+  - power-domains
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+#include 
+#include 
+dpr-channel@5610 {
+compatible = "fsl,imx8qxp-dpr-channel";
+reg = <0x5610 0x1>;
+interrupts-extended = < GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH>,
+  <_irqsteer 324>;
+interrupt-names = "dpr_wrap", "r_rtram_stall";
+clocks = <_dpr1_lpcg IMX_LPCG_CLK_4>,
+ <_dpr1_lpcg IMX_LPCG_CLK_5>,
+ <_rtram1_lpcg IMX_LPCG_CLK_0>;
+clock-names = "apb", "b", "rtram";
+fsl,sc-resource = ;
+fsl,prgs = <_prg4>, <_prg5>;
+power-domains = < IMX_SC_R_DC_0>;
+};
-- 
2.37.1



[PATCH v14 1/6] dt-bindings: display: imx: Add i.MX8qxp/qm DPU binding

2023-01-05 Thread Liu Ying
This patch adds bindings for i.MX8qxp/qm Display Processing Unit.

Reviewed-by: Rob Herring 
Signed-off-by: Liu Ying 
---
v7->v14:
* No change.

v6->v7:
* Add Rob's R-b tag back.

v5->v6:
* Use graph schema. So, drop Rob's R-b tag as review is needed.

v4->v5:
* No change.

v3->v4:
* Improve compatible property by using enum instead of oneOf+const. (Rob)
* Add Rob's R-b tag.

v2->v3:
* No change.

v1->v2:
* Fix yamllint warnings.
* Require bypass0 and bypass1 clocks for both i.MX8qxp and i.MX8qm, as the
  display controller subsystem spec does say that they exist.
* Use new dt binding way to add clocks in the example.
* Trivial tweaks for the example.

 .../bindings/display/imx/fsl,imx8qxp-dpu.yaml | 387 ++
 1 file changed, 387 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dpu.yaml

diff --git a/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dpu.yaml 
b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dpu.yaml
new file mode 100644
index ..6b05c586cd9d
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dpu.yaml
@@ -0,0 +1,387 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/imx/fsl,imx8qxp-dpu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8qm/qxp Display Processing Unit
+
+maintainers:
+  - Liu Ying 
+
+description: |
+  The Freescale i.MX8qm/qxp Display Processing Unit(DPU) is comprised of two
+  main components that include a blit engine for 2D graphics accelerations
+  and a display controller for display output processing, as well as a command
+  sequencer.
+
+properties:
+  compatible:
+enum:
+  - fsl,imx8qxp-dpu
+  - fsl,imx8qm-dpu
+
+  reg:
+maxItems: 1
+
+  interrupts:
+items:
+  - description: |
+  store9 shadow load interrupt(blit engine)
+  - description: |
+  store9 frame complete interrupt(blit engine)
+  - description: |
+  store9 sequence complete interrupt(blit engine)
+  - description: |
+  extdst0 shadow load interrupt
+  (display controller, content stream 0)
+  - description: |
+  extdst0 frame complete interrupt
+  (display controller, content stream 0)
+  - description: |
+  extdst0 sequence complete interrupt
+  (display controller, content stream 0)
+  - description: |
+  extdst4 shadow load interrupt
+  (display controller, safety stream 0)
+  - description: |
+  extdst4 frame complete interrupt
+  (display controller, safety stream 0)
+  - description: |
+  extdst4 sequence complete interrupt
+  (display controller, safety stream 0)
+  - description: |
+  extdst1 shadow load interrupt
+  (display controller, content stream 1)
+  - description: |
+  extdst1 frame complete interrupt
+  (display controller, content stream 1)
+  - description: |
+  extdst1 sequence complete interrupt
+  (display controller, content stream 1)
+  - description: |
+  extdst5 shadow load interrupt
+  (display controller, safety stream 1)
+  - description: |
+  extdst5 frame complete interrupt
+  (display controller, safety stream 1)
+  - description: |
+  extdst5 sequence complete interrupt
+  (display controller, safety stream 1)
+  - description: |
+  disengcfg0 shadow load interrupt
+  (display controller, display stream 0)
+  - description: |
+  disengcfg0 frame complete interrupt
+  (display controller, display stream 0)
+  - description: |
+  disengcfg0 sequence complete interrupt
+  (display controller, display stream 0)
+  - description: |
+  framegen0 programmable interrupt0
+  (display controller, display stream 0)
+  - description: |
+  framegen0 programmable interrupt1
+  (display controller, display stream 0)
+  - description: |
+  framegen0 programmable interrupt2
+  (display controller, display stream 0)
+  - description: |
+  framegen0 programmable interrupt3
+  (display controller, display stream 0)
+  - description: |
+  signature0 shadow load interrupt
+  (display controller, display stream 0)
+  - description: |
+  signature0 measurement valid interrupt
+  (display controller, display stream 0)
+  - description: |
+  signature0 error condition interrupt
+  (display controller, display stream 0)
+  - description: |
+  disengcfg1 shadow load interrupt
+  (display controller, display stream 1)
+  - description: |
+  disengcfg1 frame complete interrupt
+  (display controller, display stream 1)
+  - description: |
+  

[PATCH v14 0/6] drm/imx: Introduce i.MX8qm/qxp DPU DRM

2023-01-05 Thread Liu Ying
Hi,


This is the v14 series to introduce i.MX8qm/qxp Display Processing Unit(DPU)
DRM support.

DPU is comprised of a blit engine for 2D graphics, a display controller
and a command sequencer.  Outside of DPU, optional prefetch engines can
fetch data from memory prior to some DPU fetchunits of blit engine and
display controller.  The pre-fetchers support linear formats and Vivante
GPU tile formats.

Reference manual can be found at:
https://www.nxp.com/webapp/Download?colCode=IMX8DQXPRM


This patch set adds kernel modesetting support for the display controller part.
It supports two CRTCs per display controller, several planes, prefetch
engines and some properties of CRTC and plane.  Currently, the registers of
the controller is accessed without command sequencer involved, instead just by
using CPU.  DRM connectors would be created from the DPU KMS driver.


Patch 1 ~ 3 add dt-bindings for DPU and prefetch engines.
Patch 4 is a minor improvement of a macro to suppress warning as the KMS driver
uses it.
Patch 5 introduces the DPU DRM support.
Patch 6 updates MAINTAINERS.

Welcome comments, thanks.

v13->v14:
* Rebase the patch series to the latest drm-misc-next branch(v6.1-rc6 based).
* Include drm_fbdev_generic.h in dpu_drv.c due to the rebase.
* Fix dpu drm driver suspend/resume by properly get drm device through
  dev_get_drvdata().
* Use pm_ptr() macro for dpu core driver PM operations.
* Use pm_sleep_ptr() macro for dpu drm driver PM operations.
* Use DEFINE_SIMPLE_DEV_PM_OPS() macro to define dpu drm driver PM operations,
  instead of SIMPLE_DEV_PM_OPS().
* Update year of Copyright.
* Add SoC series name 'i.MX8'/'IMX8'/'imx8' to dpu driver module decription,
  Kconfig name, dpu driver names and dpu driver object name.

v12->v13:
* Drop 'drm->irq_enabled = true;' from patch 5/6 to fix a potential build
  break reported by 'kernel test robot '.  drm->irq_enabled
  should not be used by imx-dpu drm as it is only used by legacy drivers
  with userspace modesetting.

v11->v12:
* Rebase the series upon v6.1-rc1.
* Minor update on Kconfigs, struct names and macro names for patch 5/6
  due to the rebase.

v10->v11:
* Rebase the series upon v6.0-rc1.
* Include drm_blend.h and drm_framebuffer.h in dpu-kms.c and dpu-plane.c
  to fix build errors due to the rebase.
* Fix a checkpatch warning for dpu-crtc.c.
* Properly use dev_err_probe() to return it's return value directly where
  possible.

v9->v10:
* Rebase the series upon v5.18-rc1.
* Make 'checkpatch.pl --strict' happier for patch 5/6.
* Add Rob's R-b tag on patch 3/6.
* Add Laurentiu's R-b tag on patch 5/6.
* Add Laurentiu's A-b tag on patch 6/6.

v8->v9:
* Use drm_atomic_get_new_plane_state() in dpu_plane_atomic_update() for
  patch 5/6. (Laurentiu)
* Drop getting DPU DT alias ID for patch 5/6, as it is unused.
* Reference 'interrupts-extended' schema instead of 'interrupts' for patch 3/6
  to require an additional DPR interrupt(r_rtram_stall) because the reference
  manual does mention it, though the driver doesn't get/use it for now.
  Reference 'interrupt-names' schema to define the two DPR interrupt names -
  'dpr_wrap' and 'r_rtram_stall'.  Accordingly, patch 5/6 gets the 'dpr_wrap'
  interrupt by name.
* Drop Rob's R-b tag on patch 3/6, as review is needed.

v7->v8:
* Rebase this series up onto the latest drm-misc-next branch, due to DRM plane
  helper functions API change(atomic_check and atomic_update) from DRM atomic
  core.  So, dpu_plane_atomic_check() and dpu_plane_atomic_update() are updated
  accordingly in patch 5/6.  Also, rename plane->state variables and relevant
  DPU plane state variables in those two functions to reflect they are new
  states, like the patch 'drm: Rename plane->state variables in atomic update
  and disable' recently landed in drm-misc-next.
* Replace drm_gem_fb_prepare_fb() with drm_gem_plane_helper_prepare_fb() in
  patch 5/6, due to DRM core API change.
* Improve DPR burst length for GPU standard tile and 32bpp GPU super tile in
  patch 5/6 to align with the latest version of internal HW documention.

v6->v7:
* Fix return value of dpu_get_irqs() if platform_get_irq() fails. (Laurentiu)
* Use the function array dpu_irq_handler[] to store individual DPU irq handlers.
  (Laurentiu)
* Call get/put() hooks directly to get/put DPU fetchunits for DPU plane groups.
  (Laurentiu)
* Shorten the names of individual DPU irq handlers by using DPU unit abbrev
  names to make writing dpu_irq_handler[] easier.
* Add Rob's R-b tag back on DPU dt-binding patch as change in v6 was reviewed.

v5->v6:
* Use graph schema in the DPU dt-binding.
* Do not use macros where possible in the DPU DRM driver. (Laurentiu)
* Break dpu_plane_atomic_check() into some smaller functions. (Laurentiu)
* Address some minor comments from Laurentiu on the DPU DRM driver.
* Add dpu_crtc_err() helper marco in the DPU DRM driver to tell dmesg
  which CRTC generates error.
* Drop calling dev_set_drvdata() from dpu_drm_bind/unbind() in the DPU DRM
  driver as 

Re: [RFC PATCH v3 0/3] Support for Solid Fill Planes

2023-01-05 Thread Dmitry Baryshkov
On Fri, 6 Jan 2023 at 02:38, Jessica Zhang  wrote:
>
>
>
> On 1/5/2023 3:33 AM, Daniel Vetter wrote:
> > On Wed, Jan 04, 2023 at 03:40:33PM -0800, Jessica Zhang wrote:
> >> Introduce and add support for a solid_fill property. When the solid_fill
> >> property is set, and the framebuffer is set to NULL, memory fetch will be
> >> disabled.
> >>
> >> In addition, loosen the NULL FB checks within the atomic commit callstack
> >> to allow a NULL FB when the solid_fill property is set and add FB checks
> >> in methods where the FB was previously assumed to be non-NULL.
> >>
> >> Finally, have the DPU driver use drm_plane_state.solid_fill and instead of
> >> dpu_plane_state.color_fill, and add extra checks in the DPU atomic commit
> >> callstack to account for a NULL FB in cases where solid_fill is set.
> >>
> >> Some drivers support hardware that have optimizations for solid fill
> >> planes. This series aims to expose these capabilities to userspace as
> >> some compositors have a solid fill flag (ex. SOLID_COLOR in the Android
> >> hardware composer HAL) that can be set by apps like the Android Gears
> >> app.
> >>
> >> Userspace can set the solid_fill property to a blob containing the
> >> appropriate version number and solid fill color (in RGB323232 format) and
> >> setting the framebuffer to NULL.
> >>
> >> Note: Currently, there's only one version of the solid_fill blob property.
> >> However if other drivers want to support a similar feature, but require
> >> more than just the solid fill color, they can extend this feature by
> >> creating additional versions of the drm_solid_fill struct.
> >>
> >> Changes in V2:
> >> - Dropped SOLID_FILL_FORMAT property (Simon)
> >> - Switched to implementing solid_fill property as a blob (Simon, Dmitry)
> >> - Changed to checks for if solid_fill_blob is set (Dmitry)
> >> - Abstracted (plane_state && !solid_fill_blob) checks to helper method
> >>(Dmitry)
> >> - Removed DPU_PLANE_COLOR_FILL_FLAG
> >> - Fixed whitespace and indentation issues (Dmitry)
> >
> > Now that this is a blob, I do wonder again whether it's not cleaner to set
> > the blob as the FB pointer. Or create some kind other kind of special data
> > source objects (because solid fill is by far not the only such thing).
> >
> > We'd still end up in special cases like when userspace that doesn't
> > understand solid fill tries to read out such a framebuffer, but these
> > cases already exist anyway for lack of priviledges.
> >
> > So I still think that feels like the more consistent way to integrate this
> > feature. Which doesn't mean it has to happen like that, but the
> > patches/cover letter should at least explain why we don't do it like this.
>
> Hi Daniel,
>
> IIRC we were facing some issues with this check [1] when trying to set
> FB to a PROP_BLOB instead. Which is why we went with making it a
> separate property instead. Will mention this in the cover letter.

What kind of issues? Could you please describe them?

>
> [1]
> https://gitlab.freedesktop.org/drm/msm/-/blob/msm-next/drivers/gpu/drm/drm_property.c#L71
>
> Thanks,
>
> Jessica Zhang
>
> > -Daniel
> >
> >>
> >> Changes in V3:
> >> - Fixed some logic errors in atomic checks (Dmitry)
> >> - Introduced drm_plane_has_visible_data() and drm_atomic_check_fb() helper
> >>methods (Dmitry)
> >>
> >> Jessica Zhang (3):
> >>drm: Introduce solid fill property for drm plane
> >>drm: Adjust atomic checks for solid fill color
> >>drm/msm/dpu: Use color_fill property for DPU planes
> >>
> >>   drivers/gpu/drm/drm_atomic.c  | 136 +-
> >>   drivers/gpu/drm/drm_atomic_helper.c   |  34 +++---
> >>   drivers/gpu/drm/drm_atomic_state_helper.c |   9 ++
> >>   drivers/gpu/drm/drm_atomic_uapi.c |  59 ++
> >>   drivers/gpu/drm/drm_blend.c   |  17 +++
> >>   drivers/gpu/drm/drm_plane.c   |   8 +-
> >>   drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c  |   9 +-
> >>   drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c |  65 +++
> >>   include/drm/drm_atomic_helper.h   |   5 +-
> >>   include/drm/drm_blend.h   |   1 +
> >>   include/drm/drm_plane.h   |  62 ++
> >>   11 files changed, 302 insertions(+), 103 deletions(-)
> >>
> >> --
> >> 2.38.1
> >>
> >
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch



-- 
With best wishes
Dmitry


Re: [PATCH v7 20/45] drm/amd: Parse both v1 and v2 TA microcode headers using same function

2023-01-05 Thread Lazar, Lijo




On 1/5/2023 10:31 PM, Mario Limonciello wrote:

Several IP versions duplicate code and can't use the common helpers.
Move this code into a single function so that the helpers can be used.

Signed-off-by: Mario Limonciello 
---
v6->v7:
  * Drop tags
  * Only set adev->psp.securedisplay_context.context on PSPv12 Renoir and
PSP v10 which matches previous behavior.  If it should match for Cezanne
and PSPv11 too we can undo this part of the check.
v5->v6:
  * Rebase on earlier patches
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 123 ++--
  drivers/gpu/drm/amd/amdgpu/psp_v10_0.c  |  64 +---
  drivers/gpu/drm/amd/amdgpu/psp_v11_0.c  |  80 ++-
  drivers/gpu/drm/amd/amdgpu/psp_v12_0.c  |  66 ++---
  4 files changed, 115 insertions(+), 218 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
index 7a2fc920739b..bdc2bf87a286 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
@@ -3272,41 +3272,76 @@ static int parse_ta_bin_descriptor(struct psp_context 
*psp,
return 0;
  }
  
-int psp_init_ta_microcode(struct psp_context *psp,

- const char *chip_name)
+static int parse_ta_v1_microcode(struct psp_context *psp)
  {
+   const struct ta_firmware_header_v1_0 *ta_hdr;
struct amdgpu_device *adev = psp->adev;
-   char fw_name[PSP_FW_NAME_LEN];
-   const struct ta_firmware_header_v2_0 *ta_hdr;
-   int err = 0;
-   int ta_index = 0;
  
-	if (!chip_name) {

-   dev_err(adev->dev, "invalid chip name for ta microcode\n");
+   ta_hdr = (const struct ta_firmware_header_v1_0 *) adev->psp.ta_fw->data;
+
+   if (le16_to_cpu(ta_hdr->header.header_version_major) != 1)
return -EINVAL;
-   }
  
-	snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_ta.bin", chip_name);

-   err = request_firmware(>psp.ta_fw, fw_name, adev->dev);
-   if (err)
-   goto out;
+   adev->psp.xgmi_context.context.bin_desc.fw_version =
+   le32_to_cpu(ta_hdr->xgmi.fw_version);
+   adev->psp.xgmi_context.context.bin_desc.size_bytes =
+   le32_to_cpu(ta_hdr->xgmi.size_bytes);
+   adev->psp.xgmi_context.context.bin_desc.start_addr =
+   (uint8_t *)ta_hdr +
+   le32_to_cpu(ta_hdr->header.ucode_array_offset_bytes);
+
+   adev->psp.ras_context.context.bin_desc.fw_version =
+   le32_to_cpu(ta_hdr->ras.fw_version);
+   adev->psp.ras_context.context.bin_desc.size_bytes =
+   le32_to_cpu(ta_hdr->ras.size_bytes);
+   adev->psp.ras_context.context.bin_desc.start_addr =
+   (uint8_t *)adev->psp.xgmi_context.context.bin_desc.start_addr +
+   le32_to_cpu(ta_hdr->ras.offset_bytes);
+
+   adev->psp.hdcp_context.context.bin_desc.fw_version =
+   le32_to_cpu(ta_hdr->hdcp.fw_version);
+   adev->psp.hdcp_context.context.bin_desc.size_bytes =
+   le32_to_cpu(ta_hdr->hdcp.size_bytes);
+   adev->psp.hdcp_context.context.bin_desc.start_addr =
+   (uint8_t *)ta_hdr +
+   le32_to_cpu(ta_hdr->header.ucode_array_offset_bytes);
+
+   adev->psp.dtm_context.context.bin_desc.fw_version =
+   le32_to_cpu(ta_hdr->dtm.fw_version);
+   adev->psp.dtm_context.context.bin_desc.size_bytes =
+   le32_to_cpu(ta_hdr->dtm.size_bytes);
+   adev->psp.dtm_context.context.bin_desc.start_addr =
+   (uint8_t *)adev->psp.hdcp_context.context.bin_desc.start_addr +
+   le32_to_cpu(ta_hdr->dtm.offset_bytes);
+
+   adev->psp.securedisplay_context.context.bin_desc.fw_version =
+   le32_to_cpu(ta_hdr->securedisplay.fw_version);
+   adev->psp.securedisplay_context.context.bin_desc.size_bytes =
+   le32_to_cpu(ta_hdr->securedisplay.size_bytes);
+   adev->psp.securedisplay_context.context.bin_desc.start_addr =
+   (uint8_t *)adev->psp.hdcp_context.context.bin_desc.start_addr +
+   le32_to_cpu(ta_hdr->securedisplay.offset_bytes);
+
+   adev->psp.ta_fw_version = le32_to_cpu(ta_hdr->header.ucode_version);
  
-	err = amdgpu_ucode_validate(adev->psp.ta_fw);

-   if (err)
-   goto out;
+   return 0;
+}
+
+static int parse_ta_v2_microcode(struct psp_context *psp)
+{
+   const struct ta_firmware_header_v2_0 *ta_hdr;
+   struct amdgpu_device *adev = psp->adev;
+   int err = 0;
+   int ta_index = 0;
  
  	ta_hdr = (const struct ta_firmware_header_v2_0 *)adev->psp.ta_fw->data;
  
-	if (le16_to_cpu(ta_hdr->header.header_version_major) != 2) {

-   dev_err(adev->dev, "unsupported TA header version\n");
-   err = -EINVAL;
-   goto out;
-   }
+   if (le16_to_cpu(ta_hdr->header.header_version_major) != 2)
+   return -EINVAL;
  
  	if (le32_to_cpu(ta_hdr->ta_fw_bin_count) >= 

[PATCH 2/2] drm/panel: boe-tv101wum-nl6: Reduce lcm_reset to send initial code time

2023-01-05 Thread xinlei.lee
From: Xinlei Lee 

Since the panel spec stipulates that the time from lcm_reset to DSI to
send the initial code should be greater than 6ms and less than 40ms,
so reduce the delay before sending the initial code and avoid panel
exceptions.

Fixes: a869b9db7adf ("drm/panel: support for boe tv101wum-nl6 wuxga dsi video 
mode panel")
Signed-off-by: Xinlei Lee 
---
 drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c 
b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
index 857a2f0420d7..f0093035f1ff 100644
--- a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
+++ b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
@@ -780,7 +780,6 @@ static const struct panel_init_cmd inx_hj110iz_init_cmd[] = 
{
 };
 
 static const struct panel_init_cmd boe_init_cmd[] = {
-   _INIT_DELAY_CMD(24),
_INIT_DCS_CMD(0xB0, 0x05),
_INIT_DCS_CMD(0xB1, 0xE5),
_INIT_DCS_CMD(0xB3, 0x52),
-- 
2.18.0



[PATCH 0/2]Reduce lcm_reset to DSI LP11 send cmd time

2023-01-05 Thread xinlei.lee
From: Xinlei Lee 

The panel spec stipulates that after lcm_reset is pulled high, cmd
should be sent to initialize the panel. Within the allowable range of
the DSI spec, this time needs to be reduced to avoid panel exceptions.

Xinlei Lee (2):
  drm/mediatek: dsi: Reduce the time of dsi from LP11 to sending cmd
  drm/panel: boe-tv101wum-nl6: Reduce lcm_reset to send initial code
time

 drivers/gpu/drm/mediatek/mtk_dsi.c | 2 +-
 drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c | 1 -
 2 files changed, 1 insertion(+), 2 deletions(-)

-- 
2.18.0



[PATCH 1/2] drm/mediatek: dsi: Reduce the time of dsi from LP11 to sending cmd

2023-01-05 Thread xinlei.lee
From: Xinlei Lee 

According to Figure 16 Turnaround Procedure on page 36 in [1], you
can see the status of LP-00 -> LP10 -> LP11. This state can correspond
to the state of DSI from LP00 -> LP11 in mtk_dsi_lane_ready function
in mtk_dsi.c.

LP-00 -> LP10 -> LP11 takes about 2*TLPX time (refer to [1] page 51
to see that TLPX is 50ns).

The delay at the end of the mtk_dsi_lane_ready function should be
greater than the 2*TLPX specified by the DSI spec, and less than
the time specified by the DSI_RX (generally 6ms to 40ms), to avoid
problems caused by the RX specification.

[1]:mipi_D-PHY_specification_v1-1

Fixes: 39e8d062b03c ("drm/mediatek: Keep dsi as LP00 before dcs cmds transfer")
Signed-off-by: Xinlei Lee 
---
 drivers/gpu/drm/mediatek/mtk_dsi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 3b7d13028fb6..9e1363c9fcdb 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -721,7 +721,7 @@ static void mtk_dsi_lane_ready(struct mtk_dsi *dsi)
mtk_dsi_clk_ulp_mode_leave(dsi);
mtk_dsi_lane0_ulp_mode_leave(dsi);
mtk_dsi_clk_hs_mode(dsi, 0);
-   msleep(20);
+   usleep_range(1000, 3000);
/* The reaction time after pulling up the mipi signal for 
dsi_rx */
}
 }
-- 
2.18.0



[PATCH] drm/panel: boe-tv101wum-nl6: Ensure DSI writes succeed during disable

2023-01-05 Thread Stephen Boyd
The unprepare sequence has started to fail after moving to panel bridge
code in the msm drm driver (commit 007ac0262b0d ("drm/msm/dsi: switch to
DRM_PANEL_BRIDGE")). You'll see messages like this in the kernel logs:

   panel-boe-tv101wum-nl6 ae94000.dsi.0: failed to set panel off: -22

This is because boe_panel_enter_sleep_mode() needs an operating DSI link
to set the panel into sleep mode. Performing those writes in the
unprepare phase of bridge ops is too late, because the link has already
been torn down by the DSI controller in post_disable, i.e. the PHY has
been disabled, etc. See dsi_mgr_bridge_post_disable() for more details
on the DSI .

Split the unprepare function into a disable part and an unprepare part.
For now, just the DSI writes to enter sleep mode are put in the disable
function. This fixes the panel off routine and keeps the panel happy.

My Wormdingler has an integrated touchscreen that stops responding to
touch if the panel is only half disabled too. This patch fixes it. And
finally, this saves power when the screen is off because without this
fix the regulators for the panel are left enabled when nothing is being
displayed on the screen.

Fixes: 007ac0262b0d ("drm/msm/dsi: switch to DRM_PANEL_BRIDGE")
Fixes: a869b9db7adf ("drm/panel: support for boe tv101wum-nl6 wuxga dsi video 
mode panel")
Cc: yangcong 
Cc: Douglas Anderson 
Cc: Jitao Shi 
Cc: Sam Ravnborg 
Cc: Rob Clark 
Cc: Dmitry Baryshkov 
Signed-off-by: Stephen Boyd 
---
 drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c 
b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
index 857a2f0420d7..c924f1124ebc 100644
--- a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
+++ b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
@@ -1193,14 +1193,11 @@ static int boe_panel_enter_sleep_mode(struct boe_panel 
*boe)
return 0;
 }
 
-static int boe_panel_unprepare(struct drm_panel *panel)
+static int boe_panel_disable(struct drm_panel *panel)
 {
struct boe_panel *boe = to_boe_panel(panel);
int ret;
 
-   if (!boe->prepared)
-   return 0;
-
ret = boe_panel_enter_sleep_mode(boe);
if (ret < 0) {
dev_err(panel->dev, "failed to set panel off: %d\n", ret);
@@ -1209,6 +1206,16 @@ static int boe_panel_unprepare(struct drm_panel *panel)
 
msleep(150);
 
+   return 0;
+}
+
+static int boe_panel_unprepare(struct drm_panel *panel)
+{
+   struct boe_panel *boe = to_boe_panel(panel);
+
+   if (!boe->prepared)
+   return 0;
+
if (boe->desc->discharge_on_disable) {
regulator_disable(boe->avee);
regulator_disable(boe->avdd);
@@ -1528,6 +1535,7 @@ static enum drm_panel_orientation 
boe_panel_get_orientation(struct drm_panel *pa
 }
 
 static const struct drm_panel_funcs boe_panel_funcs = {
+   .disable = boe_panel_disable,
.unprepare = boe_panel_unprepare,
.prepare = boe_panel_prepare,
.enable = boe_panel_enable,

base-commit: 1b929c02afd37871d5afb9d498426f83432e71c2
-- 
https://chromeos.dev



[PATCH] drm/msm/dsi: Add missing check for alloc_ordered_workqueue

2023-01-05 Thread Jiasheng Jiang
Add check for the return value of alloc_ordered_workqueue as it may return
NULL pointer and cause NULL pointer dereference.
Moreover, change the "return ret" into "goto fail" in order to be
consistent with the others.

Fixes: a689554ba6ed ("drm/msm: Initial add DSI connector support")
Fixes: 32d3e0feccfe ("drm/msm: dsi: Use OPP API to set clk/perf state")
Signed-off-by: Jiasheng Jiang 
---
 drivers/gpu/drm/msm/dsi/dsi_host.c | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 89aadd3b3202..12239f628d5a 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -1944,19 +1944,19 @@ int msm_dsi_host_init(struct msm_dsi *msm_dsi)
 
ret = devm_pm_opp_set_clkname(>dev, "byte");
if (ret)
-   return ret;
+   goto fail;
/* OPP table is optional */
ret = devm_pm_opp_of_add_table(>dev);
if (ret && ret != -ENODEV) {
dev_err(>dev, "invalid OPP table in device tree\n");
-   return ret;
+   goto fail;
}
 
msm_host->irq = irq_of_parse_and_map(pdev->dev.of_node, 0);
if (msm_host->irq < 0) {
ret = msm_host->irq;
dev_err(>dev, "failed to get irq: %d\n", ret);
-   return ret;
+   goto fail;
}
 
/* do not autoenable, will be enabled later */
@@ -1966,7 +1966,7 @@ int msm_dsi_host_init(struct msm_dsi *msm_dsi)
if (ret < 0) {
dev_err(>dev, "failed to request IRQ%u: %d\n",
msm_host->irq, ret);
-   return ret;
+   goto fail;
}
 
init_completion(_host->dma_comp);
@@ -1977,6 +1977,11 @@ int msm_dsi_host_init(struct msm_dsi *msm_dsi)
 
/* setup workqueue */
msm_host->workqueue = alloc_ordered_workqueue("dsi_drm_work", 0);
+   if (!msm_host->workqueue) {
+   ret = -ENOMEM;
+   goto fail;
+   }
+
INIT_WORK(_host->err_work, dsi_err_worker);
 
msm_dsi->id = msm_host->id;
-- 
2.25.1



[PATCH] drm/msm/hdmi: Add missing check for alloc_ordered_workqueue

2023-01-05 Thread Jiasheng Jiang
Add check for the return value of alloc_ordered_workqueue as it may return
NULL pointer and cause NULL pointer dereference in `hdmi_hdcp.c` and
`hdmi_hpd.c`.

Fixes: c6a57a50ad56 ("drm/msm/hdmi: add hdmi hdcp support (V3)")
Signed-off-by: Jiasheng Jiang 
---
 drivers/gpu/drm/msm/hdmi/hdmi.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.c b/drivers/gpu/drm/msm/hdmi/hdmi.c
index 4d3fdc806bef..8e801ec0b33f 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi.c
@@ -120,6 +120,10 @@ static int msm_hdmi_init(struct hdmi *hdmi)
int ret;
 
hdmi->workq = alloc_ordered_workqueue("msm_hdmi", 0);
+   if (!hdmi->workq) {
+   ret = -ENOMEM;
+   goto fail;
+   }
 
hdmi->i2c = msm_hdmi_i2c_init(hdmi);
if (IS_ERR(hdmi->i2c)) {
-- 
2.25.1



Re: renesas/master bisection: igt-kms-rockchip.kms_vblank.pipe-A-wait-forked on rk3399-gru-kevin

2023-01-05 Thread Brian Norris
On Thu, Jan 05, 2023 at 04:59:55PM -0800, Brian Norris wrote:
> On Wed, Jan 04, 2023 at 10:11:46AM +0100, Michel Dänzer wrote:
> > On 1/4/23 03:11, Brian Norris wrote:
> > > On Tue, Jan 03, 2023 at 07:04:00PM +0100, Michel Dänzer wrote:
> > >> On 12/21/22 23:02, Brian Norris wrote:
> > >>> 3. leave vblank enabled even in the presence of PSR
> > > 
> > > I'm leaning toward this.
> > 
> > If this means vblank interrupts will arrive as expected even while in PSR, 
> > that may be the ideal solution indeed.
> 
> Yes. And I think I have a working patchset for this now. It passes all
> the igt-gpu-tools/kms_vblank tests for me now, and I don't think it
> causes any other issues. I'll send it out shortly, after a bit more
> testing.

For the record, that's here:
https://lore.kernel.org/lkml/20230105174001.2.Ic07cba4ab9a7bd3618a9e4258b8f92ea7d10ae5a@changeid/

I didn't CC everyone who got this report. In included a:

  Reported-by: "kernelci.org bot" 

even though it didn't really bisect the right thing. Let me know if
there's a different/better way to give credit.

Brian


[PATCH 2/2] drm/rockchip: vop: Leave vblank enabled in self-refresh

2023-01-05 Thread Brian Norris
If we disable vblank when entering self-refresh, vblank APIs (like
DRM_IOCTL_WAIT_VBLANK) no longer work. But user space is not aware when
we enter self-refresh, so this appears to be an API violation -- that
DRM_IOCTL_WAIT_VBLANK fails with EINVAL whenever the display is idle and
enters self-refresh.

The downstream driver used by many of these systems never used to
disable vblank for PSR, and in fact, even upstream, we didn't do that
until radically redesigning the state machine in commit 6c836d965bad
("drm/rockchip: Use the helpers for PSR").

Thus, it seems like a reasonable API fix to simply restore that
behavior, and leave vblank enabled.

Note that this appears to potentially unbalance the
drm_crtc_vblank_{off,on}() calls in some cases, but:
(a) drm_crtc_vblank_on() documents this as OK and
(b) if I do the naive balancing, I find state machine issues such that
we're not in sync properly; so it's easier to take advantage of (a).

Backporting notes:
Marking as 'Fixes' commit 6c836d965bad ("drm/rockchip: Use the helpers
for PSR"), but it probably depends on commit bed030a49f3e
("drm/rockchip: Don't fully disable vop on self refresh") as well.

We also need the previous patch ("drm/atomic: Allow vblank-enabled +
self-refresh "disable""), of course.

Fixes: 6c836d965bad ("drm/rockchip: Use the helpers for PSR")
Cc: 
Link: https://lore.kernel.org/dri-devel/y5itf0+yniqa6...@sirena.org.uk/
Reported-by: "kernelci.org bot" 
Signed-off-by: Brian Norris 
---

 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index fa1f4ee6d195..c541967114b4 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -719,11 +719,11 @@ static void vop_crtc_atomic_disable(struct drm_crtc *crtc,
 
mutex_lock(>vop_lock);
 
-   drm_crtc_vblank_off(crtc);
-
if (crtc->state->self_refresh_active)
goto out;
 
+   drm_crtc_vblank_off(crtc);
+
/*
 * Vop standby will take effect at end of current frame,
 * if dsp hold valid irq happen, it means standby complete.
-- 
2.39.0.314.g84b9a713c41-goog



[PATCH 1/2] drm/atomic: Allow vblank-enabled + self-refresh "disable"

2023-01-05 Thread Brian Norris
The self-refresh helper framework overloads "disable" to sometimes mean
"go into self-refresh mode," and this mode activates automatically
(e.g., after some period of unchanging display output). In such cases,
the display pipe is still considered "on", and user-space is not aware
that we went into self-refresh mode. Thus, users may expect that
vblank-related features (such as DRM_IOCTL_WAIT_VBLANK) still work
properly.

However, we trigger the WARN_ONCE() here if a CRTC driver tries to leave
vblank enabled here.

Add a new exception, such that we allow CRTCs to be "disabled" (with
self-refresh active) with vblank interrupts still enabled.

Cc:  # dependency for subsequent patch
Signed-off-by: Brian Norris 
---

 drivers/gpu/drm/drm_atomic_helper.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index d579fd8f7cb8..7b5eddadebd5 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1207,6 +1207,12 @@ disable_outputs(struct drm_device *dev, struct 
drm_atomic_state *old_state)
 
if (!drm_dev_has_vblank(dev))
continue;
+   /*
+* Self-refresh is not a true "disable"; let vblank remain
+* enabled.
+*/
+   if (new_crtc_state->self_refresh_active)
+   continue;
 
ret = drm_crtc_vblank_get(crtc);
WARN_ONCE(ret != -EINVAL, "driver forgot to call 
drm_crtc_vblank_off()\n");
-- 
2.39.0.314.g84b9a713c41-goog



[PATCH] drm/msm: Add missing check and destroy for alloc_ordered_workqueue

2023-01-05 Thread Jiasheng Jiang
Add check for the return value of alloc_ordered_workqueue as it may return
NULL pointer.
Moreover, use the destroy_workqueue in the later fails in order to avoid
memory leak.

Fixes: c8afe684c95c ("drm/msm: basic KMS driver for snapdragon")
Signed-off-by: Jiasheng Jiang 
---
 drivers/gpu/drm/msm/msm_drv.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 8b0b0ac74a6f..b82d938226ad 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -418,6 +418,8 @@ static int msm_drm_init(struct device *dev, const struct 
drm_driver *drv)
priv->dev = ddev;
 
priv->wq = alloc_ordered_workqueue("msm", 0);
+   if (!priv->wq)
+   return -ENOMEM;
 
INIT_LIST_HEAD(>objects);
mutex_init(>obj_lock);
@@ -440,12 +442,12 @@ static int msm_drm_init(struct device *dev, const struct 
drm_driver *drv)
 
ret = msm_init_vram(ddev);
if (ret)
-   return ret;
+   goto err_destroy_workqueue;
 
/* Bind all our sub-components: */
ret = component_bind_all(dev, ddev);
if (ret)
-   return ret;
+   goto err_destroy_workqueue;
 
dma_set_max_seg_size(dev, UINT_MAX);
 
@@ -540,6 +542,8 @@ static int msm_drm_init(struct device *dev, const struct 
drm_driver *drv)
 
 err_msm_uninit:
msm_drm_uninit(dev);
+err_destroy_workqueue:
+   destroy_workqueue(priv->wq);
return ret;
 }
 
-- 
2.25.1



[PATCH -next] drm/amdgpu: clean up some inconsistent indentings

2023-01-05 Thread Yang Li
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c:65 amdgpu_gem_fault() warn: 
inconsistent indenting

Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=3639
Reported-by: Abaci Robot 
Signed-off-by: Yang Li 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
index 00edc7002ee8..ed1164a87fce 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
@@ -62,10 +62,10 @@ static vm_fault_t amdgpu_gem_fault(struct vm_fault *vmf)
goto unlock;
}
 
-ret = ttm_bo_vm_fault_reserved(vmf, vmf->vma->vm_page_prot,
-   TTM_BO_VM_NUM_PREFAULT);
+   ret = ttm_bo_vm_fault_reserved(vmf, vmf->vma->vm_page_prot,
+  TTM_BO_VM_NUM_PREFAULT);
 
-drm_dev_exit(idx);
+   drm_dev_exit(idx);
} else {
ret = ttm_bo_vm_dummy_page(vmf, vmf->vma->vm_page_prot);
}
-- 
2.20.1.7.g153144c



Re: renesas/master bisection: igt-kms-rockchip.kms_vblank.pipe-A-wait-forked on rk3399-gru-kevin

2023-01-05 Thread Brian Norris
On Wed, Jan 04, 2023 at 10:11:46AM +0100, Michel Dänzer wrote:
> On 1/4/23 03:11, Brian Norris wrote:
> > On Tue, Jan 03, 2023 at 07:04:00PM +0100, Michel Dänzer wrote:
> >> On 12/21/22 23:02, Brian Norris wrote:
> > 
> >>> 3. leave vblank enabled even in the presence of PSR
> > 
> > I'm leaning toward this.
> 
> If this means vblank interrupts will arrive as expected even while in PSR, 
> that may be the ideal solution indeed.

Yes. And I think I have a working patchset for this now. It passes all
the igt-gpu-tools/kms_vblank tests for me now, and I don't think it
causes any other issues. I'll send it out shortly, after a bit more
testing.

Side note: I believe this vblank-disabled issue actually came in as an
upstream regression at commit 6c836d965bad ("drm/rockchip: Use the
helpers for PSR"); before that, we were doing this very differently, and
didn't touch vblank at all for PSR, similar to the "downstream" stuff I
mentioned earlier.

> >> 5. Go/stay out of PSR while vblank interrupts are enabled (probably want 
> >> to make sure vblankoffdelay is set up such that vblank interrupts are 
> >> disabled ASAP)
> > 
> > That seems not extremely nice, to waste power. Based on the earlier
> > downstream implementation (which left vblank interrupts enabled), I'd
> > wager there's a much larger power win from PSR (on the display-transport
> > and memory-bandwidth costs), relative to the power cost of vblank
> > interrupts.
> > 
> > Also, messing with vblankoffdelay sounds likely to trigger the races
> > mentioned in the drm_vblank.c kerneldoc.
> 
> Not sure how likely that is, quite a few drivers are setting 
> dev->vblank_disable_immediate = true.
> 
> With that, vblank interrupts should generally be enabled only while there are 
> screen updates as well[0], in which case PSR shouldn't be possible anyway.
> 
> [0] There may be user space which uses the vblank ioctls even while there are 
> no screen updates though, which would prevent PSR in this case.

OK. I'm just reading docs here; definitely not an expert.

> >>> [1] Or is it? I don't really know the DRM_IOCTL_WAIT_VBLANK ABI
> >>> contract in the presence of PSR, but I believe the upstream PSR
> >>> support has always worked this way. I could imagine
> >>> DRM_IOCTL_WAIT_VBLANK users might not love seeing EINVAL here
> >>> though.
> >>
> >> Yeah, that's pretty likely to cause issues with existing real-world user 
> >> space.
> > 
> > OK. Any hints as to what kind of user space uses this?
> 
> I don't have any specific example, just thinking about how user space could 
> respond to the vblank ioctls returning an error, and it would seem to be 
> generally either of:
> 
> * Just run non-throttled, which might negate any energy savings from PSR
> * Fail to work altogether
> 
> 
> > I'm in part simply curious, but I'm also wondering what the
> > error-handling and reliability (e.g., what if vblanks don't come?)
> > expectations might be in practice.
> 
> If vblank events never come, user space might freeze.

Thanks. If my patchset works out like I expect, this should no longer be
noticeable to user space, so I don't really have to test out your
educated guesses :)

Thanks for the idea-bouncing.

Brian


Re: [RFC PATCH v3 0/3] Support for Solid Fill Planes

2023-01-05 Thread Jessica Zhang




On 1/5/2023 3:33 AM, Daniel Vetter wrote:

On Wed, Jan 04, 2023 at 03:40:33PM -0800, Jessica Zhang wrote:

Introduce and add support for a solid_fill property. When the solid_fill
property is set, and the framebuffer is set to NULL, memory fetch will be
disabled.

In addition, loosen the NULL FB checks within the atomic commit callstack
to allow a NULL FB when the solid_fill property is set and add FB checks
in methods where the FB was previously assumed to be non-NULL.

Finally, have the DPU driver use drm_plane_state.solid_fill and instead of
dpu_plane_state.color_fill, and add extra checks in the DPU atomic commit
callstack to account for a NULL FB in cases where solid_fill is set.

Some drivers support hardware that have optimizations for solid fill
planes. This series aims to expose these capabilities to userspace as
some compositors have a solid fill flag (ex. SOLID_COLOR in the Android
hardware composer HAL) that can be set by apps like the Android Gears
app.

Userspace can set the solid_fill property to a blob containing the
appropriate version number and solid fill color (in RGB323232 format) and
setting the framebuffer to NULL.

Note: Currently, there's only one version of the solid_fill blob property.
However if other drivers want to support a similar feature, but require
more than just the solid fill color, they can extend this feature by
creating additional versions of the drm_solid_fill struct.

Changes in V2:
- Dropped SOLID_FILL_FORMAT property (Simon)
- Switched to implementing solid_fill property as a blob (Simon, Dmitry)
- Changed to checks for if solid_fill_blob is set (Dmitry)
- Abstracted (plane_state && !solid_fill_blob) checks to helper method
   (Dmitry)
- Removed DPU_PLANE_COLOR_FILL_FLAG
- Fixed whitespace and indentation issues (Dmitry)


Now that this is a blob, I do wonder again whether it's not cleaner to set
the blob as the FB pointer. Or create some kind other kind of special data
source objects (because solid fill is by far not the only such thing).

We'd still end up in special cases like when userspace that doesn't
understand solid fill tries to read out such a framebuffer, but these
cases already exist anyway for lack of priviledges.

So I still think that feels like the more consistent way to integrate this
feature. Which doesn't mean it has to happen like that, but the
patches/cover letter should at least explain why we don't do it like this.


Hi Daniel,

IIRC we were facing some issues with this check [1] when trying to set 
FB to a PROP_BLOB instead. Which is why we went with making it a 
separate property instead. Will mention this in the cover letter.


[1] 
https://gitlab.freedesktop.org/drm/msm/-/blob/msm-next/drivers/gpu/drm/drm_property.c#L71


Thanks,

Jessica Zhang


-Daniel



Changes in V3:
- Fixed some logic errors in atomic checks (Dmitry)
- Introduced drm_plane_has_visible_data() and drm_atomic_check_fb() helper
   methods (Dmitry)

Jessica Zhang (3):
   drm: Introduce solid fill property for drm plane
   drm: Adjust atomic checks for solid fill color
   drm/msm/dpu: Use color_fill property for DPU planes

  drivers/gpu/drm/drm_atomic.c  | 136 +-
  drivers/gpu/drm/drm_atomic_helper.c   |  34 +++---
  drivers/gpu/drm/drm_atomic_state_helper.c |   9 ++
  drivers/gpu/drm/drm_atomic_uapi.c |  59 ++
  drivers/gpu/drm/drm_blend.c   |  17 +++
  drivers/gpu/drm/drm_plane.c   |   8 +-
  drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c  |   9 +-
  drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c |  65 +++
  include/drm/drm_atomic_helper.h   |   5 +-
  include/drm/drm_blend.h   |   1 +
  include/drm/drm_plane.h   |  62 ++
  11 files changed, 302 insertions(+), 103 deletions(-)

--
2.38.1



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


Re: [Intel-gfx] [PATCH 2/2] drm/i915: Consolidate TLB invalidation flow

2023-01-05 Thread Matt Roper
On Thu, Jan 05, 2023 at 01:06:37PM +, Tvrtko Ursulin wrote:
> 
> On 04/01/2023 17:41, Matt Roper wrote:
> > On Wed, Jan 04, 2023 at 10:08:29AM +, Tvrtko Ursulin wrote:
> > > 
> > > On 03/01/2023 19:57, Matt Roper wrote:
> > > > On Mon, Dec 19, 2022 at 05:10:02PM +0100, Andrzej Hajda wrote:
> > > > > On 19.12.2022 11:13, Tvrtko Ursulin wrote:
> > > > > > From: Tvrtko Ursulin 
> > > > > > 
> > > > > > As the logic for selecting the register and corresponsing values 
> > > > > > grew, the
> > > > > 
> > > > > corresponding
> > > > > 
> > > > > > code become a bit unsightly. Consolidate by storing the required 
> > > > > > values at
> > > > > > engine init time in the engine itself, and by doing so minimise the 
> > > > > > amount
> > > > > > of invariant platform and engine checks during each and every TLB
> > > > > > invalidation.
> > > > > > 
> > > > > > v2:
> > > > > > * Fail engine probe if TLB invlidations registers are unknown.
> > > > > > 
> > > > > > Signed-off-by: Tvrtko Ursulin 
> > > > > > Cc: Andrzej Hajda 
> > > > > > Cc: Matt Roper 
> > > > > > Reviewed-by: Andrzej Hajda  # v1
> > > > > > ---
> > > > > > drivers/gpu/drm/i915/gt/intel_engine_cs.c|  93 +
> > > > > > drivers/gpu/drm/i915/gt/intel_engine_types.h |  15 +++
> > > > > > drivers/gpu/drm/i915/gt/intel_gt.c   | 135 
> > > > > > +++
> > > > > > 3 files changed, 128 insertions(+), 115 deletions(-)
> > > > > > 
> > > > > > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
> > > > > > b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > > > > > index 99c4b866addd..d47dadfc25c8 100644
> > > > > > --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > > > > > +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > > > > > @@ -1143,12 +1143,105 @@ static int init_status_page(struct 
> > > > > > intel_engine_cs *engine)
> > > > > > return ret;
> > > > > > }
> > > > > > +static int intel_engine_init_tlb_invalidation(struct 
> > > > > > intel_engine_cs *engine)
> > > > > > +{
> > > > > > +   static const union intel_engine_tlb_inv_reg gen8_regs[] = {
> > > > > > +   [RENDER_CLASS].reg  = GEN8_RTCR,
> > > > > > +   [VIDEO_DECODE_CLASS].reg= GEN8_M1TCR, /* , 
> > > > > > GEN8_M2TCR */
> > > > > > +   [VIDEO_ENHANCEMENT_CLASS].reg   = GEN8_VTCR,
> > > > > > +   [COPY_ENGINE_CLASS].reg = GEN8_BTCR,
> > > > > > +   };
> > > > > > +   static const union intel_engine_tlb_inv_reg gen12_regs[] = {
> > > > > > +   [RENDER_CLASS].reg  = GEN12_GFX_TLB_INV_CR,
> > > > > > +   [VIDEO_DECODE_CLASS].reg= GEN12_VD_TLB_INV_CR,
> > > > > > +   [VIDEO_ENHANCEMENT_CLASS].reg   = GEN12_VE_TLB_INV_CR,
> > > > > > +   [COPY_ENGINE_CLASS].reg = GEN12_BLT_TLB_INV_CR,
> > > > > > +   [COMPUTE_CLASS].reg = 
> > > > > > GEN12_COMPCTX_TLB_INV_CR,
> > > > > > +   };
> > > > > > +   static const union intel_engine_tlb_inv_reg xehp_regs[] = {
> > > > > > +   [RENDER_CLASS].mcr_reg= XEHP_GFX_TLB_INV_CR,
> > > > > > +   [VIDEO_DECODE_CLASS].mcr_reg  = XEHP_VD_TLB_INV_CR,
> > > > > > +   [VIDEO_ENHANCEMENT_CLASS].mcr_reg = XEHP_VE_TLB_INV_CR,
> > > > > > +   [COPY_ENGINE_CLASS].mcr_reg   = XEHP_BLT_TLB_INV_CR,
> > > > > > +   [COMPUTE_CLASS].mcr_reg   = 
> > > > > > XEHP_COMPCTX_TLB_INV_CR,
> > > > > > +   };
> > > > > > +   struct drm_i915_private *i915 = engine->i915;
> > > > > > +   const union intel_engine_tlb_inv_reg *regs;
> > > > > > +   union intel_engine_tlb_inv_reg reg;
> > > > > > +   unsigned int class = engine->class;
> > > > > > +   unsigned int num = 0;
> > > > > > +   u32 val;
> > > > > > +
> > > > > > +   /*
> > > > > > +* New platforms should not be added with catch-all-newer (>=)
> > > > > > +* condition so that any later platform added triggers the 
> > > > > > below warning
> > > > > > +* and in turn mandates a human cross-check of whether the 
> > > > > > invalidation
> > > > > > +* flows have compatible semantics.
> > > > > > +*
> > > > > > +* For instance with the 11.00 -> 12.00 transition three out of 
> > > > > > five
> > > > > > +* respective engine registers were moved to masked type. Then 
> > > > > > after the
> > > > > > +* 12.00 -> 12.50 transition multi cast handling is required 
> > > > > > too.
> > > > > > +*/
> > > > > > +
> > > > > > +   if (GRAPHICS_VER_FULL(i915) == IP_VER(12, 50)) {
> > > > 
> > > > This is bad...it only captures XEHPSDV and breaks the handling of DG2
> > > > (12.55), PVC (12.60), and MTL (12.70, 12.71, and 12.72).  You're not
> > > > hitting the warning as expected since those are all now being captured
> > > > by the next case of the if/else ladder.  With the way GMD_ID works, we
> > > > may also get new version numbers that silently show up in hardware too
> > > > at some point (e.g., 12.73, 12.74, etc.)
> > 

linux-next: duplicate patches in the amdgpu tree

2023-01-05 Thread Stephen Rothwell
Hi all,

The following commits are also in the drm-fixes tree as a different
commits (but the same patches):

  878a3c004c0e ("drm/amd/display: Uninitialized variables causing 4k60 UCLK to 
stay at DPM1 and not DPM0")
  4243c84aa082 ("Revert "drm/amd/display: Enable Freesync Video Mode by 
default"")

-- 
Cheers,
Stephen Rothwell


pgpB_qIY5tDvv.pgp
Description: OpenPGP digital signature


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

2023-01-05 Thread Stephen Rothwell
Hi all,

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

  drivers/gpu/drm/tests/drm_format_helper_test.c

between commit:

  a52a5451f43b ("kunit: Use KUNIT_EXPECT_MEMEQ macro")

from Linus' tree and commits:

  f21d62c9ce3d ("drm/format-helper: Store RGB565 in little-endian order")
  175073d694cd ("drm/format-helper: Add conversion from XRGB to ARGB")
  56119bfb3914 ("drm/format-helper: Add conversion from XRGB to 
ARGB2101010")
  10cd592e639e ("drm/format-helper: Add conversion from XRGB to 15-bit 
RGB555 formats")

from the drm-misc tree.

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

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/gpu/drm/tests/drm_format_helper_test.c
index 567c71f95edc,f71dc0fe08a1..
--- a/drivers/gpu/drm/tests/drm_format_helper_test.c
+++ b/drivers/gpu/drm/tests/drm_format_helper_test.c
@@@ -375,12 -560,108 +560,108 @@@ static void drm_test_fb_xrgb_to_rgb
iosys_map_set_vaddr(, xrgb);
  
drm_fb_xrgb_to_rgb565(, >dst_pitch, , , 
>clip, false);
+   buf = le16buf_to_cpu(test, (__force const __le16 *)buf, dst_size / 
sizeof(__le16));
 -  KUNIT_EXPECT_EQ(test, memcmp(buf, result->expected, dst_size), 0);
 +  KUNIT_EXPECT_MEMEQ(test, buf, result->expected, dst_size);
  
+   buf = dst.vaddr; /* restore original value of buf */
drm_fb_xrgb_to_rgb565(, >dst_pitch, , , 
>clip, true);
+   buf = le16buf_to_cpu(test, (__force const __le16 *)buf, dst_size / 
sizeof(__le16));
 -  KUNIT_EXPECT_EQ(test, memcmp(buf, result->expected_swab, dst_size), 0);
 +  KUNIT_EXPECT_MEMEQ(test, buf, result->expected_swab, dst_size);
  }
  
+ static void drm_test_fb_xrgb_to_xrgb1555(struct kunit *test)
+ {
+   const struct convert_xrgb_case *params = test->param_value;
+   const struct convert_to_xrgb1555_result *result = 
>xrgb1555_result;
+   size_t dst_size;
+   u16 *buf = NULL;
+   __le32 *xrgb = NULL;
+   struct iosys_map dst, src;
+ 
+   struct drm_framebuffer fb = {
+   .format = drm_format_info(DRM_FORMAT_XRGB),
+   .pitches = { params->pitch, 0, 0 },
+   };
+ 
+   dst_size = conversion_buf_size(DRM_FORMAT_XRGB1555, result->dst_pitch,
+  >clip);
+   KUNIT_ASSERT_GT(test, dst_size, 0);
+ 
+   buf = kunit_kzalloc(test, dst_size, GFP_KERNEL);
+   KUNIT_ASSERT_NOT_ERR_OR_NULL(test, buf);
+   iosys_map_set_vaddr(, buf);
+ 
+   xrgb = cpubuf_to_le32(test, params->xrgb, TEST_BUF_SIZE);
+   KUNIT_ASSERT_NOT_ERR_OR_NULL(test, xrgb);
+   iosys_map_set_vaddr(, xrgb);
+ 
+   drm_fb_xrgb_to_xrgb1555(, >dst_pitch, , , 
>clip);
+   buf = le16buf_to_cpu(test, (__force const __le16 *)buf, dst_size / 
sizeof(__le16));
 -  KUNIT_EXPECT_EQ(test, memcmp(buf, result->expected, dst_size), 0);
++  KUNIT_EXPECT_MEMEQ(test, buf, result->expected, dst_size);
+ }
+ 
+ static void drm_test_fb_xrgb_to_argb1555(struct kunit *test)
+ {
+   const struct convert_xrgb_case *params = test->param_value;
+   const struct convert_to_argb1555_result *result = 
>argb1555_result;
+   size_t dst_size;
+   u16 *buf = NULL;
+   __le32 *xrgb = NULL;
+   struct iosys_map dst, src;
+ 
+   struct drm_framebuffer fb = {
+   .format = drm_format_info(DRM_FORMAT_XRGB),
+   .pitches = { params->pitch, 0, 0 },
+   };
+ 
+   dst_size = conversion_buf_size(DRM_FORMAT_ARGB1555, result->dst_pitch,
+  >clip);
+   KUNIT_ASSERT_GT(test, dst_size, 0);
+ 
+   buf = kunit_kzalloc(test, dst_size, GFP_KERNEL);
+   KUNIT_ASSERT_NOT_ERR_OR_NULL(test, buf);
+   iosys_map_set_vaddr(, buf);
+ 
+   xrgb = cpubuf_to_le32(test, params->xrgb, TEST_BUF_SIZE);
+   KUNIT_ASSERT_NOT_ERR_OR_NULL(test, xrgb);
+   iosys_map_set_vaddr(, xrgb);
+ 
+   drm_fb_xrgb_to_argb1555(, >dst_pitch, , , 
>clip);
+   buf = le16buf_to_cpu(test, (__force const __le16 *)buf, dst_size / 
sizeof(__le16));
 -  KUNIT_EXPECT_EQ(test, memcmp(buf, result->expected, dst_size), 0);
++  KUNIT_EXPECT_MEMEQ(test, buf, result->expected, dst_size);
+ }
+ 
+ static void drm_test_fb_xrgb_to_rgba5551(struct kunit *test)
+ {
+   const struct convert_xrgb_case *params = test->param_value;
+   const struct convert_to_rgba5551_result *result = 
>rgba5551_result;
+   size_t dst_size;
+   u16 *buf = NULL;
+   __le32 *xrgb = NULL;
+   struct iosys_map dst, src;
+ 
+   struct drm_framebuffer fb = {
+  

Re: [PATCH 01/10] drm/print: Fix and add support for NULL as first argument in drm_* macros

2023-01-05 Thread Siddh Raman Pant
Comments say macros DRM_DEBUG_* are deprecated in favor of
drm_dbg_*(NULL, ...), but they have broken support for it,
as the macro will result in `(NULL) ? (NULL)->dev : NULL`.

Thus, fix them by separating logic to get dev ptr in a new
function, which will return the dev ptr if arg is not NULL.
Use it in drm_dbg_*, and also in __DRM_DEFINE_DBG_RATELIMITED,
where a similar (but correct) NULL check was in place.

Also, add support for NULL in __drm_printk, so that all the
drm_* macros will hence support NULL as the first argument.
This also means that deprecation comments mentioning pr_()*
can now be changed to the drm equivalents.

There is a need to support device pointers, as in some cases,
we may not have drm_device but just the device ptr, such as
when dealing with struct mipi_dsi_host. Before this change,
passing just mipi_dsi_host would have worked, since due to
preprocessing, the resultant would be "host->dev", but now
due to NULL check that cannot happen.

Signed-off-by: Siddh Raman Pant 
---
I accidentally removed one underscore in Generic before sending
the patch. Please use this corrected patch, otherwise build will
fail. Sending entire patchset for this unfortunate oversight on
my part doesn't seem a good idea, hence sending as a reply.

 include/drm/drm_print.h | 101 +---
 1 file changed, 73 insertions(+), 28 deletions(-)

diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
index a44fb7ef257f..45bf81ce2339 100644
--- a/include/drm/drm_print.h
+++ b/include/drm/drm_print.h
@@ -34,6 +34,7 @@
 #include 
 
 #include 
+#include 
 
 /* Do *not* use outside of drm_print.[ch]! */
 extern unsigned long __drm_debug;
@@ -451,9 +452,52 @@ void __drm_dev_dbg(struct _ddebug *desc, const struct 
device *dev,
  * Prefer drm_device based logging over device or prink based logging.
  */
 
-/* Helper for struct drm_device based logging. */
+/**
+ * ___drm_get_dev_ptr - Helper function to get device pointer.
+ * @ptr: struct drm_device pointer, struct device pointer, or NULL.
+ * @is_drm: True implies @ptr is drm_device pointer, else device pointer.
+ *
+ * RETURNS:
+ * The device pointer (NULL if @ptr is NULL).
+ */
+static inline struct device *___drm_get_dev_ptr(const void *ptr, bool is_drm)
+{
+   if (!ptr)
+   return NULL;
+
+   if (is_drm)
+   return ((struct drm_device *)ptr)->dev;
+
+   return (struct device *)ptr;
+}
+
+/**
+ * __drm_get_dev_ptr - Helper to get device pointer even if NULL is passed.
+ *Primarily for use in drm_*() print macros, since they
+ *need to handle NULL as the first argument passed.
+ */
+#define  __drm_get_dev_ptr(drm) \
+   _Generic((drm), \
+   struct drm_device * :   \
+   ___drm_get_dev_ptr((drm), true),\
+   struct device * :   \
+   ___drm_get_dev_ptr((drm), false),   \
+   default :   \
+   NULL\
+   )
+
+/**
+ * Helper for struct drm_device based logging (prefer this over struct device).
+ * Also supports struct device ptr as an argument for edge cases.
+ */
 #define __drm_printk(drm, level, type, fmt, ...)   \
-   dev_##level##type((drm)->dev, "[drm] " fmt, ##__VA_ARGS__)
+({ \
+   struct device *__dev_ = __drm_get_dev_ptr(drm); \
+   if (__dev_) \
+   dev_##level##type(__dev_, "[drm] " fmt, ##__VA_ARGS__); \
+   else\
+   pr_##level##type("[drm] " fmt, ##__VA_ARGS__);  \
+})
 
 
 #define drm_info(drm, fmt, ...)\
@@ -487,25 +531,25 @@ void __drm_dev_dbg(struct _ddebug *desc, const struct 
device *dev,
 
 
 #define drm_dbg_core(drm, fmt, ...)\
-   drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_CORE, fmt, ##__VA_ARGS__)
-#define drm_dbg_driver(drm, fmt, ...)  
\
-   drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_DRIVER, fmt, 
##__VA_ARGS__)
+   drm_dev_dbg(__drm_get_dev_ptr(drm), DRM_UT_CORE, fmt, ##__VA_ARGS__)
+#define drm_dbg_driver(drm, fmt, ...)  \
+   drm_dev_dbg(__drm_get_dev_ptr(drm), DRM_UT_DRIVER, fmt, ##__VA_ARGS__)
 #define drm_dbg_kms(drm, fmt, ...) \
-   drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_KMS, fmt, ##__VA_ARGS__)
+   drm_dev_dbg(__drm_get_dev_ptr(drm), DRM_UT_KMS, fmt, ##__VA_ARGS__)
 #define drm_dbg_prime(drm, fmt, ...)

[PATCH v4 09/10] drm/drm_blend: Remove usage of deprecated DRM_DEBUG_ATOMIC

2023-01-05 Thread Siddh Raman Pant
drm_print.h says DRM_DEBUG_ATOMIC is deprecated in favor of
drm_dbg_atomic().

Signed-off-by: Siddh Raman Pant 
Reviewed-by: Simon Ser 
---
 drivers/gpu/drm/drm_blend.c | 13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
index b4c8cab7158c..6e74de833466 100644
--- a/drivers/gpu/drm/drm_blend.c
+++ b/drivers/gpu/drm/drm_blend.c
@@ -450,8 +450,8 @@ static int drm_atomic_helper_crtc_normalize_zpos(struct 
drm_crtc *crtc,
int i, n = 0;
int ret = 0;
 
-   DRM_DEBUG_ATOMIC("[CRTC:%d:%s] calculating normalized zpos values\n",
-crtc->base.id, crtc->name);
+   drm_dbg_atomic(dev, "[CRTC:%d:%s] calculating normalized zpos values\n",
+  crtc->base.id, crtc->name);
 
states = kmalloc_array(total_planes, sizeof(*states), GFP_KERNEL);
if (!states)
@@ -469,9 +469,8 @@ static int drm_atomic_helper_crtc_normalize_zpos(struct 
drm_crtc *crtc,
goto done;
}
states[n++] = plane_state;
-   DRM_DEBUG_ATOMIC("[PLANE:%d:%s] processing zpos value %d\n",
-plane->base.id, plane->name,
-plane_state->zpos);
+   drm_dbg_atomic(dev, "[PLANE:%d:%s] processing zpos value %d\n",
+  plane->base.id, plane->name, plane_state->zpos);
}
 
sort(states, n, sizeof(*states), drm_atomic_state_zpos_cmp, NULL);
@@ -480,8 +479,8 @@ static int drm_atomic_helper_crtc_normalize_zpos(struct 
drm_crtc *crtc,
plane = states[i]->plane;
 
states[i]->normalized_zpos = i;
-   DRM_DEBUG_ATOMIC("[PLANE:%d:%s] normalized zpos value %d\n",
-plane->base.id, plane->name, i);
+   drm_dbg_atomic(dev, "[PLANE:%d:%s] normalized zpos value %d\n",
+  plane->base.id, plane->name, i);
}
crtc_state->zpos_changed = true;
 
-- 
2.39.0




[PATCH v4 01/10] drm/print: Fix and add support for NULL as first argument in drm_* macros

2023-01-05 Thread Siddh Raman Pant
Comments say macros DRM_DEBUG_* are deprecated in favor of
drm_dbg_*(NULL, ...), but they have broken support for it,
as the macro will result in `(NULL) ? (NULL)->dev : NULL`.

Thus, fix them by separating logic to get dev ptr in a new
function, which will return the dev ptr if arg is not NULL.
Use it in drm_dbg_*, and also in __DRM_DEFINE_DBG_RATELIMITED,
where a similar (but correct) NULL check was in place.

Also, add support for NULL in __drm_printk, so that all the
drm_* macros will hence support NULL as the first argument.
This also means that deprecation comments mentioning pr_()*
can now be changed to the drm equivalents.

There is a need to support device pointers, as in some cases,
we may not have drm_device but just the device ptr, such as
when dealing with struct mipi_dsi_host. Before this change,
passing just mipi_dsi_host would have worked, since due to
preprocessing, the resultant would be "host->dev", but now
due to NULL check that cannot happen.

Signed-off-by: Siddh Raman Pant 
---
 include/drm/drm_print.h | 101 +---
 1 file changed, 73 insertions(+), 28 deletions(-)

diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
index a44fb7ef257f..df791cd747da 100644
--- a/include/drm/drm_print.h
+++ b/include/drm/drm_print.h
@@ -34,6 +34,7 @@
 #include 
 
 #include 
+#include 
 
 /* Do *not* use outside of drm_print.[ch]! */
 extern unsigned long __drm_debug;
@@ -451,9 +452,52 @@ void __drm_dev_dbg(struct _ddebug *desc, const struct 
device *dev,
  * Prefer drm_device based logging over device or prink based logging.
  */
 
-/* Helper for struct drm_device based logging. */
+/**
+ * ___drm_get_dev_ptr - Helper function to get device pointer.
+ * @ptr: struct drm_device pointer, struct device pointer, or NULL.
+ * @is_drm: True implies @ptr is drm_device pointer, else device pointer.
+ *
+ * RETURNS:
+ * The device pointer (NULL if @ptr is NULL).
+ */
+static inline struct device *___drm_get_dev_ptr(const void *ptr, bool is_drm)
+{
+   if (!ptr)
+   return NULL;
+
+   if (is_drm)
+   return ((struct drm_device *)ptr)->dev;
+
+   return (struct device *)ptr;
+}
+
+/**
+ * __drm_get_dev_ptr - Helper to get device pointer even if NULL is passed.
+ *Primarily for use in drm_*() print macros, since they
+ *need to handle NULL as the first argument passed.
+ */
+#define  __drm_get_dev_ptr(drm) \
+   _Generic((drm), \
+   struct drm_device * :   \
+   __drm_get_dev_ptr((drm), true), \
+   struct device * :   \
+   __drm_get_dev_ptr((drm), false),\
+   default :   \
+   NULL\
+   )
+
+/**
+ * Helper for struct drm_device based logging (prefer this over struct device).
+ * Also supports struct device ptr as an argument for edge cases.
+ */
 #define __drm_printk(drm, level, type, fmt, ...)   \
-   dev_##level##type((drm)->dev, "[drm] " fmt, ##__VA_ARGS__)
+({ \
+   struct device *__dev_ = __drm_get_dev_ptr(drm); \
+   if (__dev_) \
+   dev_##level##type(__dev_, "[drm] " fmt, ##__VA_ARGS__); \
+   else\
+   pr_##level##type("[drm] " fmt, ##__VA_ARGS__);  \
+})
 
 
 #define drm_info(drm, fmt, ...)\
@@ -487,25 +531,25 @@ void __drm_dev_dbg(struct _ddebug *desc, const struct 
device *dev,
 
 
 #define drm_dbg_core(drm, fmt, ...)\
-   drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_CORE, fmt, ##__VA_ARGS__)
-#define drm_dbg_driver(drm, fmt, ...)  
\
-   drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_DRIVER, fmt, 
##__VA_ARGS__)
+   drm_dev_dbg(__drm_get_dev_ptr(drm), DRM_UT_CORE, fmt, ##__VA_ARGS__)
+#define drm_dbg_driver(drm, fmt, ...)  \
+   drm_dev_dbg(__drm_get_dev_ptr(drm), DRM_UT_DRIVER, fmt, ##__VA_ARGS__)
 #define drm_dbg_kms(drm, fmt, ...) \
-   drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_KMS, fmt, ##__VA_ARGS__)
+   drm_dev_dbg(__drm_get_dev_ptr(drm), DRM_UT_KMS, fmt, ##__VA_ARGS__)
 #define drm_dbg_prime(drm, fmt, ...)   \
-   drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_PRIME, fmt, ##__VA_ARGS__)
+   drm_dev_dbg(__drm_get_dev_ptr(drm), DRM_UT_PRIME, fmt, ##__VA_ARGS__)
 #define drm_dbg_atomic(drm, fmt, ...)  \

[PATCH v4 07/10] drm: Remove usage of deprecated DRM_DEBUG_KMS

2023-01-05 Thread Siddh Raman Pant
drm_print.h says DRM_DEBUG_KMS is deprecated in favor of
drm_dbg_kms().

Signed-off-by: Siddh Raman Pant 
---
 drivers/gpu/drm/drm_client_modeset.c   | 112 ++---
 drivers/gpu/drm/drm_color_mgmt.c   |   4 +-
 drivers/gpu/drm/drm_connector.c|  21 ++---
 drivers/gpu/drm/drm_crtc.c |  36 
 drivers/gpu/drm/drm_crtc_helper.c  |  54 ++--
 drivers/gpu/drm/drm_debugfs_crc.c  |   5 +-
 drivers/gpu/drm/drm_displayid.c|   4 +-
 drivers/gpu/drm/drm_edid.c |  17 ++--
 drivers/gpu/drm/drm_gem_shmem_helper.c |   4 +-
 drivers/gpu/drm/drm_lease.c|   2 +-
 drivers/gpu/drm/drm_mipi_dbi.c |   7 +-
 drivers/gpu/drm/drm_modes.c|  10 +--
 drivers/gpu/drm/drm_plane.c|  32 +++
 drivers/gpu/drm/drm_probe_helper.c |  39 -
 drivers/gpu/drm/drm_rect.c |   4 +-
 drivers/gpu/drm/drm_sysfs.c|   8 +-
 16 files changed, 189 insertions(+), 170 deletions(-)

diff --git a/drivers/gpu/drm/drm_client_modeset.c 
b/drivers/gpu/drm/drm_client_modeset.c
index e2403b8c6347..4e08ae688b83 100644
--- a/drivers/gpu/drm/drm_client_modeset.c
+++ b/drivers/gpu/drm/drm_client_modeset.c
@@ -242,8 +242,9 @@ static void drm_client_connectors_enabled(struct 
drm_connector **connectors,
for (i = 0; i < connector_count; i++) {
connector = connectors[i];
enabled[i] = drm_connector_enabled(connector, true);
-   DRM_DEBUG_KMS("connector %d enabled? %s\n", connector->base.id,
- connector->display_info.non_desktop ? "non 
desktop" : str_yes_no(enabled[i]));
+   drm_dbg_kms(connector->dev, "connector %d enabled? %s\n",
+   connector->base.id,
+   connector->display_info.non_desktop ? "non desktop" 
: str_yes_no(enabled[i]));
 
any_enabled |= enabled[i];
}
@@ -303,7 +304,7 @@ static bool drm_client_target_cloned(struct drm_device *dev,
}
 
if (can_clone) {
-   DRM_DEBUG_KMS("can clone using command line\n");
+   drm_dbg_kms(dev, "can clone using command line\n");
return true;
}
 
@@ -328,7 +329,7 @@ static bool drm_client_target_cloned(struct drm_device *dev,
}
 
if (can_clone) {
-   DRM_DEBUG_KMS("can clone using 1024x768\n");
+   drm_dbg_kms(dev, "can clone using 1024x768\n");
return true;
}
drm_info(dev, "kms: can't enable cloning when we probably wanted 
to.\n");
@@ -352,8 +353,9 @@ static int drm_client_get_tile_offsets(struct drm_connector 
**connectors,
continue;
 
if (!modes[i] && (h_idx || v_idx)) {
-   DRM_DEBUG_KMS("no modes for connector tiled %d %d\n", i,
- connector->base.id);
+   drm_dbg_kms(connector->dev,
+   "no modes for connector tiled %d %d\n",
+   i, connector->base.id);
continue;
}
if (connector->tile_h_loc < h_idx)
@@ -364,7 +366,8 @@ static int drm_client_get_tile_offsets(struct drm_connector 
**connectors,
}
offsets[idx].x = hoffset;
offsets[idx].y = voffset;
-   DRM_DEBUG_KMS("returned %d %d for %d %d\n", hoffset, voffset, h_idx, 
v_idx);
+   drm_dbg_kms(NULL, "returned %d %d for %d %d\n",
+   hoffset, voffset, h_idx, v_idx);
return 0;
 }
 
@@ -421,14 +424,16 @@ static bool drm_client_target_preferred(struct 
drm_connector **connectors,
drm_client_get_tile_offsets(connectors, 
connector_count, modes, offsets, i,
connector->tile_h_loc, 
connector->tile_v_loc);
}
-   DRM_DEBUG_KMS("looking for cmdline mode on connector %d\n",
- connector->base.id);
+   drm_dbg_kms(connector->dev,
+   "looking for cmdline mode on connector %d\n",
+   connector->base.id);
 
/* got for command line mode first */
modes[i] = drm_connector_pick_cmdline_mode(connector);
if (!modes[i]) {
-   DRM_DEBUG_KMS("looking for preferred mode on connector 
%d %d\n",
- connector->base.id, connector->tile_group 
? connector->tile_group->id : 0);
+   drm_dbg_kms(connector->dev,
+   "looking for preferred mode on connector %d 
%d\n",
+   connector->base.id, connector->tile_group ? 
connector->tile_group->id : 0);
modes[i] = drm_connector_has_preferred_mode(connector, 
width, height);
}
/* No preferred 

[PATCH v4 02/10] drm: Remove usage of deprecated DRM_INFO

2023-01-05 Thread Siddh Raman Pant
drm_print.h says DRM_INFO is deprecated in favor of drm_info().

Signed-off-by: Siddh Raman Pant 
---
 drivers/gpu/drm/drm_client_modeset.c | 2 +-
 drivers/gpu/drm/drm_connector.c  | 7 ---
 drivers/gpu/drm/drm_drv.c| 2 +-
 drivers/gpu/drm/drm_pci.c| 2 +-
 4 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/drm_client_modeset.c 
b/drivers/gpu/drm/drm_client_modeset.c
index 1b12a3c201a3..ae19734974b5 100644
--- a/drivers/gpu/drm/drm_client_modeset.c
+++ b/drivers/gpu/drm/drm_client_modeset.c
@@ -331,7 +331,7 @@ static bool drm_client_target_cloned(struct drm_device *dev,
DRM_DEBUG_KMS("can clone using 1024x768\n");
return true;
}
-   DRM_INFO("kms: can't enable cloning when we probably wanted to.\n");
+   drm_info(dev, "kms: can't enable cloning when we probably wanted 
to.\n");
return false;
 }
 
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 8d92777e57dd..6e962ad565db 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -165,13 +165,14 @@ static void drm_connector_get_cmdline_mode(struct 
drm_connector *connector)
return;
 
if (mode->force) {
-   DRM_INFO("forcing %s connector %s\n", connector->name,
-drm_get_connector_force_name(mode->force));
+   drm_info(connector->dev, "forcing %s connector %s\n",
+connector->name, 
drm_get_connector_force_name(mode->force));
connector->force = mode->force;
}
 
if (mode->panel_orientation != DRM_MODE_PANEL_ORIENTATION_UNKNOWN) {
-   DRM_INFO("cmdline forces connector %s panel_orientation to 
%d\n",
+   drm_info(connector->dev,
+"cmdline forces connector %s panel_orientation to 
%d\n",
 connector->name, mode->panel_orientation);
drm_connector_set_panel_orientation(connector,
mode->panel_orientation);
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 11748dd513c3..dfb73c9d7930 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -901,7 +901,7 @@ int drm_dev_register(struct drm_device *dev, unsigned long 
flags)
if (drm_core_check_feature(dev, DRIVER_MODESET))
drm_modeset_register_all(dev);
 
-   DRM_INFO("Initialized %s %d.%d.%d %s for %s on minor %d\n",
+   drm_info(dev, "Initialized %s %d.%d.%d %s for %s on minor %d\n",
 driver->name, driver->major, driver->minor,
 driver->patchlevel, driver->date,
 dev->dev ? dev_name(dev->dev) : "virtual device",
diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
index 39d35fc3a43b..7dfb837d1325 100644
--- a/drivers/gpu/drm/drm_pci.c
+++ b/drivers/gpu/drm/drm_pci.c
@@ -262,7 +262,7 @@ void drm_legacy_pci_exit(const struct drm_driver *driver,
}
mutex_unlock(_dev_list_lock);
}
-   DRM_INFO("Module unloaded\n");
+   drm_info(NULL, "Module unloaded\n");
 }
 EXPORT_SYMBOL(drm_legacy_pci_exit);
 
-- 
2.39.0




[PATCH v4 10/10] drm/drm_lease: Remove usage of deprecated DRM_DEBUG_LEASE

2023-01-05 Thread Siddh Raman Pant
drm_print.h says DRM_DEBUG_LEASE is deprecated in favor of
drm_dbg_lease().

Signed-off-by: Siddh Raman Pant 
Reviewed-by: Simon Ser 
---
 drivers/gpu/drm/drm_lease.c | 64 -
 1 file changed, 34 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/drm_lease.c b/drivers/gpu/drm/drm_lease.c
index c442d5e766d1..08b4f29f8b61 100644
--- a/drivers/gpu/drm/drm_lease.c
+++ b/drivers/gpu/drm/drm_lease.c
@@ -213,11 +213,11 @@ static struct drm_master *drm_lease_create(struct 
drm_master *lessor, struct idr
int id;
void *entry;
 
-   DRM_DEBUG_LEASE("lessor %d\n", lessor->lessee_id);
+   drm_dbg_lease(dev, "lessor %d\n", lessor->lessee_id);
 
lessee = drm_master_create(lessor->dev);
if (!lessee) {
-   DRM_DEBUG_LEASE("drm_master_create failed\n");
+   drm_dbg_lease(dev, "drm_master_create failed\n");
return ERR_PTR(-ENOMEM);
}
 
@@ -231,7 +231,7 @@ static struct drm_master *drm_lease_create(struct 
drm_master *lessor, struct idr
error = -EBUSY;
 
if (error != 0) {
-   DRM_DEBUG_LEASE("object %d failed %d\n", object, error);
+   drm_dbg_lease(dev, "object %d failed %d\n", object, 
error);
goto out_lessee;
}
}
@@ -249,7 +249,8 @@ static struct drm_master *drm_lease_create(struct 
drm_master *lessor, struct idr
 
/* Move the leases over */
lessee->leases = *leases;
-   DRM_DEBUG_LEASE("new lessee %d %p, lessor %d %p\n", lessee->lessee_id, 
lessee, lessor->lessee_id, lessor);
+   drm_dbg_lease(dev, "new lessee %d %p, lessor %d %p\n",
+ lessee->lessee_id, lessee, lessor->lessee_id, lessor);
 
mutex_unlock(>mode_config.idr_mutex);
return lessee;
@@ -268,7 +269,7 @@ void drm_lease_destroy(struct drm_master *master)
 
mutex_lock(>mode_config.idr_mutex);
 
-   DRM_DEBUG_LEASE("drm_lease_destroy %d\n", master->lessee_id);
+   drm_dbg_lease(dev, "drm_lease_destroy %d\n", master->lessee_id);
 
/* This master is referenced by all lessees, hence it cannot be 
destroyed
 * until all of them have been
@@ -277,7 +278,8 @@ void drm_lease_destroy(struct drm_master *master)
 
/* Remove this master from the lessee idr in the owner */
if (master->lessee_id != 0) {
-   DRM_DEBUG_LEASE("remove master %d from device list of 
lessees\n", master->lessee_id);
+   drm_dbg_lease(dev, "remove master %d from device list of 
lessees\n",
+ master->lessee_id);
idr_remove(&(drm_lease_owner(master)->lessee_idr), 
master->lessee_id);
}
 
@@ -292,7 +294,7 @@ void drm_lease_destroy(struct drm_master *master)
drm_master_put(>lessor);
}
 
-   DRM_DEBUG_LEASE("drm_lease_destroy done %d\n", master->lessee_id);
+   drm_dbg_lease(dev, "drm_lease_destroy done %d\n", master->lessee_id);
 }
 
 static void _drm_lease_revoke(struct drm_master *top)
@@ -308,7 +310,8 @@ static void _drm_lease_revoke(struct drm_master *top)
 * the tree is fully connected, we can do this without recursing
 */
for (;;) {
-   DRM_DEBUG_LEASE("revoke leases for %p %d\n", master, 
master->lessee_id);
+   drm_dbg_lease(master->dev, "revoke leases for %p %d\n",
+ master, master->lessee_id);
 
/* Evacuate the lease */
idr_for_each_entry(>leases, entry, object)
@@ -408,7 +411,7 @@ static int fill_object_idr(struct drm_device *dev,
 
ret = validate_lease(dev, object_count, objects, universal_planes);
if (ret) {
-   DRM_DEBUG_LEASE("lease validation failed\n");
+   drm_dbg_lease(dev, "lease validation failed\n");
goto out_free_objects;
}
 
@@ -418,7 +421,7 @@ static int fill_object_idr(struct drm_device *dev,
struct drm_mode_object *obj = objects[o];
u32 object_id = objects[o]->id;
 
-   DRM_DEBUG_LEASE("Adding object %d to lease\n", object_id);
+   drm_dbg_lease(dev, "Adding object %d to lease\n", object_id);
 
/*
 * We're using an IDR to hold the set of leased
@@ -430,8 +433,8 @@ static int fill_object_idr(struct drm_device *dev,
 */
ret = idr_alloc(leases, _lease_idr_object , object_id, 
object_id + 1, GFP_KERNEL);
if (ret < 0) {
-   DRM_DEBUG_LEASE("Object %d cannot be inserted into 
leases (%d)\n",
-   object_id, ret);
+   drm_dbg_lease(dev, "Object %d cannot be inserted into 
leases (%d)\n",
+ object_id, ret);
goto out_free_objects;
}
if (obj->type == 

[PATCH v4 04/10] drm: Remove usage of deprecated DRM_ERROR

2023-01-05 Thread Siddh Raman Pant
drm_print.h says DRM_ERROR is deprecated in favor of drm_err().

Signed-off-by: Siddh Raman Pant 
---
 drivers/gpu/drm/drm_bridge.c |  8 
 drivers/gpu/drm/drm_bufs.c   |  8 
 drivers/gpu/drm/drm_client_modeset.c |  4 ++--
 drivers/gpu/drm/drm_context.c|  4 ++--
 drivers/gpu/drm/drm_crtc_helper.c|  8 
 drivers/gpu/drm/drm_debugfs_crc.c|  3 ++-
 drivers/gpu/drm/drm_drv.c| 14 +++---
 drivers/gpu/drm/drm_flip_work.c  |  2 +-
 drivers/gpu/drm/drm_framebuffer.c|  3 ++-
 drivers/gpu/drm/drm_gem.c|  2 +-
 drivers/gpu/drm/drm_gem_dma_helper.c |  2 +-
 drivers/gpu/drm/drm_hashtab.c|  4 ++--
 drivers/gpu/drm/drm_lock.c   | 16 
 drivers/gpu/drm/drm_mipi_dbi.c   |  2 +-
 drivers/gpu/drm/drm_mipi_dsi.c   | 12 ++--
 drivers/gpu/drm/drm_mm.c |  8 
 drivers/gpu/drm/drm_mode_config.c|  2 +-
 drivers/gpu/drm/drm_modes.c  | 26 +-
 drivers/gpu/drm/drm_modeset_helper.c |  2 +-
 drivers/gpu/drm/drm_plane.c  |  2 +-
 drivers/gpu/drm/drm_scatter.c|  9 +
 drivers/gpu/drm/drm_vm.c |  2 +-
 22 files changed, 73 insertions(+), 70 deletions(-)

diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index c3d69af02e79..3d27f08db74d 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -351,11 +351,11 @@ int drm_bridge_attach(struct drm_encoder *encoder, struct 
drm_bridge *bridge,
list_del(>chain_node);
 
 #ifdef CONFIG_OF
-   DRM_ERROR("failed to attach bridge %pOF to encoder %s: %d\n",
- bridge->of_node, encoder->name, ret);
+   drm_err(encoder->dev, "failed to attach bridge %pOF to encoder %s: 
%d\n",
+   bridge->of_node, encoder->name, ret);
 #else
-   DRM_ERROR("failed to attach bridge to encoder %s: %d\n",
- encoder->name, ret);
+   drm_err(encoder->dev, "failed to attach bridge to encoder %s: %d\n",
+   encoder->name, ret);
 #endif
 
return ret;
diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
index fcca21e8efac..98aaf3379a3b 100644
--- a/drivers/gpu/drm/drm_bufs.c
+++ b/drivers/gpu/drm/drm_bufs.c
@@ -1474,15 +1474,15 @@ int drm_legacy_freebufs(struct drm_device *dev, void 
*data,
if (copy_from_user(, >list[i], sizeof(idx)))
return -EFAULT;
if (idx < 0 || idx >= dma->buf_count) {
-   DRM_ERROR("Index %d (of %d max)\n",
- idx, dma->buf_count - 1);
+   drm_err(dev, "Index %d (of %d max)\n",
+   idx, dma->buf_count - 1);
return -EINVAL;
}
idx = array_index_nospec(idx, dma->buf_count);
buf = dma->buflist[idx];
if (buf->file_priv != file_priv) {
-   DRM_ERROR("Process %d freeing buffer not owned\n",
- task_pid_nr(current));
+   drm_err(dev, "Process %d freeing buffer not owned\n",
+   task_pid_nr(current));
return -EINVAL;
}
drm_legacy_free_buffer(dev, buf);
diff --git a/drivers/gpu/drm/drm_client_modeset.c 
b/drivers/gpu/drm/drm_client_modeset.c
index ae19734974b5..e2403b8c6347 100644
--- a/drivers/gpu/drm/drm_client_modeset.c
+++ b/drivers/gpu/drm/drm_client_modeset.c
@@ -808,7 +808,7 @@ int drm_client_modeset_probe(struct drm_client_dev *client, 
unsigned int width,
offsets = kcalloc(connector_count, sizeof(*offsets), GFP_KERNEL);
enabled = kcalloc(connector_count, sizeof(bool), GFP_KERNEL);
if (!crtcs || !modes || !enabled || !offsets) {
-   DRM_ERROR("Memory allocation failed\n");
+   drm_err(client->dev, "Memory allocation failed\n");
ret = -ENOMEM;
goto out;
}
@@ -832,7 +832,7 @@ int drm_client_modeset_probe(struct drm_client_dev *client, 
unsigned int width,
  offsets, enabled, width, height) 
&&
!drm_client_target_preferred(connectors, connector_count, 
modes,
 offsets, enabled, width, 
height))
-   DRM_ERROR("Unable to find initial modes\n");
+   drm_err(client->dev, "Unable to find initial modes\n");
 
DRM_DEBUG_KMS("picking CRTCs for %dx%d config\n",
  width, height);
diff --git a/drivers/gpu/drm/drm_context.c b/drivers/gpu/drm/drm_context.c
index c6e6a3e7219a..f6d68fad8311 100644
--- a/drivers/gpu/drm/drm_context.c
+++ b/drivers/gpu/drm/drm_context.c
@@ -276,7 +276,7 @@ int drm_legacy_setsareactx(struct drm_device *dev, void 
*data,
 static int drm_context_switch(struct 

[PATCH v4 03/10] drm: Remove usage of deprecated DRM_NOTE

2023-01-05 Thread Siddh Raman Pant
drm_print.h says DRM_NOTE is deprecated in favor of drm_notice().

Signed-off-by: Siddh Raman Pant 
---
 drivers/gpu/drm/drm_displayid.c | 2 +-
 drivers/gpu/drm/drm_kms_helper_common.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_displayid.c b/drivers/gpu/drm/drm_displayid.c
index 38ea8203df45..67fed6cee9e9 100644
--- a/drivers/gpu/drm/drm_displayid.c
+++ b/drivers/gpu/drm/drm_displayid.c
@@ -26,7 +26,7 @@ static int validate_displayid(const u8 *displayid, int 
length, int idx)
for (i = 0; i < dispid_length; i++)
csum += displayid[idx + i];
if (csum) {
-   DRM_NOTE("DisplayID checksum invalid, remainder is %d\n", csum);
+   drm_notice(NULL, "DisplayID checksum invalid, remainder is 
%d\n", csum);
return -EINVAL;
}
 
diff --git a/drivers/gpu/drm/drm_kms_helper_common.c 
b/drivers/gpu/drm/drm_kms_helper_common.c
index 0bf0fc1abf54..7a41373b67dc 100644
--- a/drivers/gpu/drm/drm_kms_helper_common.c
+++ b/drivers/gpu/drm/drm_kms_helper_common.c
@@ -41,7 +41,7 @@ MODULE_LICENSE("GPL and additional rights");
 /* Backward compatibility for drm_kms_helper.edid_firmware */
 static int edid_firmware_set(const char *val, const struct kernel_param *kp)
 {
-   DRM_NOTE("drm_kms_helper.edid_firmware is deprecated, please use 
drm.edid_firmware instead.\n");
+   drm_notice(NULL, "drm_kms_helper.edid_firmware is deprecated, please 
use drm.edid_firmware instead.\n");
 
return __drm_set_edid_firmware_path(val);
 }
-- 
2.39.0




[PATCH v4 00/10] drm: Remove usage of deprecated DRM_* macros

2023-01-05 Thread Siddh Raman Pant
This patchset aims to remove usages of deprecated DRM_* macros from the
files residing in drivers/gpu/drm root.

In process, I found out that NULL as first argument of drm_dbg_* wasn't
working, but it was listed as the alternative in deprecation comment,
so I fixed that before removing usages of DRM_DEBUG_* macros. Courtesy
discussion on v1, I added support for NULL in drm_()* macros too in this
v3.

This patchset should be applied in order as changes might be dependent.


Please review and let me know if any errors are there, and hopefully
this gets accepted.

---
Changes in v4:
- Fix commit message for DRM_NOTE erroneously mentioning DRM_INFO.
- Rebased to drm-misc-next, as 723dad977acd added drm_dbg_core() to some
  files.
- Move Generic out to a separate macro __drm_get_dev_ptr, so that interface
  of drm_dbg_*() is also same as other drm_*() macros.
- Fix comment in __drm_get_dev_ptr (now ___drm_get_dev_ptr) to use correct
  name.

Changes in v3:
- Added support for NULL is __drm_printk and thus by extension to drm_()*.
- Thus, converted dropped pr_()* changes to drm_*(NULL, ...).
- Rebased to drm-misc-next and resulting appropriate changes.

Changes in v2:
- Removed conversions to pr_*() in DRM_INFO, DRM_NOTE, and DRM_ERROR changes.
- Due to above, DRM_NOTE usage cannot be removed and the patch is dropped.
- DRY: NULL support is now achieved by way of a separate function.

Siddh Raman Pant (10):
  drm/print: Fix and add support for NULL as first argument in drm_*
macros
  drm: Remove usage of deprecated DRM_INFO
  drm: Remove usage of deprecated DRM_NOTE
  drm: Remove usage of deprecated DRM_ERROR
  drm: Remove usage of deprecated DRM_DEBUG
  drm: Remove usage of deprecated DRM_DEBUG_DRIVER
  drm: Remove usage of deprecated DRM_DEBUG_KMS
  drm: Remove usage of deprecated DRM_DEBUG_PRIME
  drm/drm_blend: Remove usage of deprecated DRM_DEBUG_ATOMIC
  drm/drm_lease: Remove usage of deprecated DRM_DEBUG_LEASE

 drivers/gpu/drm/drm_agpsupport.c|   4 +-
 drivers/gpu/drm/drm_blend.c |  13 ++-
 drivers/gpu/drm/drm_bridge.c|   8 +-
 drivers/gpu/drm/drm_bufs.c  | 122 
 drivers/gpu/drm/drm_client_modeset.c| 118 +--
 drivers/gpu/drm/drm_color_mgmt.c|   4 +-
 drivers/gpu/drm/drm_connector.c |  28 +++---
 drivers/gpu/drm/drm_context.c   |  18 ++--
 drivers/gpu/drm/drm_crtc.c  |  36 ---
 drivers/gpu/drm/drm_crtc_helper.c   |  62 ++--
 drivers/gpu/drm/drm_debugfs_crc.c   |   8 +-
 drivers/gpu/drm/drm_displayid.c |   6 +-
 drivers/gpu/drm/drm_dma.c   |  10 +-
 drivers/gpu/drm/drm_drv.c   |  26 ++---
 drivers/gpu/drm/drm_edid.c  |  17 ++--
 drivers/gpu/drm/drm_flip_work.c |   2 +-
 drivers/gpu/drm/drm_framebuffer.c   |   3 +-
 drivers/gpu/drm/drm_gem.c   |   7 +-
 drivers/gpu/drm/drm_gem_dma_helper.c|   6 +-
 drivers/gpu/drm/drm_gem_shmem_helper.c  |   6 +-
 drivers/gpu/drm/drm_hashtab.c   |  10 +-
 drivers/gpu/drm/drm_irq.c   |   4 +-
 drivers/gpu/drm/drm_kms_helper_common.c |   2 +-
 drivers/gpu/drm/drm_lease.c |  68 ++---
 drivers/gpu/drm/drm_legacy_misc.c   |   4 +-
 drivers/gpu/drm/drm_lock.c  |  36 +++
 drivers/gpu/drm/drm_mipi_dbi.c  |  19 ++--
 drivers/gpu/drm/drm_mipi_dsi.c  |  12 +--
 drivers/gpu/drm/drm_mm.c|   8 +-
 drivers/gpu/drm/drm_mode_config.c   |   2 +-
 drivers/gpu/drm/drm_mode_object.c   |   6 +-
 drivers/gpu/drm/drm_modes.c |  36 +++
 drivers/gpu/drm/drm_modeset_helper.c|   2 +-
 drivers/gpu/drm/drm_pci.c   |  14 +--
 drivers/gpu/drm/drm_plane.c |  46 -
 drivers/gpu/drm/drm_probe_helper.c  |  39 
 drivers/gpu/drm/drm_rect.c  |   4 +-
 drivers/gpu/drm/drm_scatter.c   |  19 ++--
 drivers/gpu/drm/drm_syncobj.c   |   2 +-
 drivers/gpu/drm/drm_sysfs.c |  22 ++---
 drivers/gpu/drm/drm_vm.c|  45 +
 include/drm/drm_print.h | 103 ++--
 42 files changed, 543 insertions(+), 464 deletions(-)

-- 
2.39.0




[PATCH v4 06/10] drm: Remove usage of deprecated DRM_DEBUG_DRIVER

2023-01-05 Thread Siddh Raman Pant
drm_print.h says DRM_DEBUG_DRIVER is deprecated.
Thus, use newer drm_dbg_driver().

Also fix the deprecation comment in drm_print.h which
mentions drm_dbg() instead of drm_dbg_driver().

Signed-off-by: Siddh Raman Pant 
---
 drivers/gpu/drm/drm_mipi_dbi.c | 10 +-
 include/drm/drm_print.h|  2 +-
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/drm_mipi_dbi.c b/drivers/gpu/drm/drm_mipi_dbi.c
index 58ff9503a403..ab5dd5933a1a 100644
--- a/drivers/gpu/drm/drm_mipi_dbi.c
+++ b/drivers/gpu/drm/drm_mipi_dbi.c
@@ -70,11 +70,11 @@
 #define MIPI_DBI_DEBUG_COMMAND(cmd, data, len) \
 ({ \
if (!len) \
-   DRM_DEBUG_DRIVER("cmd=%02x\n", cmd); \
+   drm_dbg_driver(NULL, "cmd=%02x\n", cmd); \
else if (len <= 32) \
-   DRM_DEBUG_DRIVER("cmd=%02x, par=%*ph\n", cmd, (int)len, data);\
+   drm_dbg_driver(NULL, "cmd=%02x, par=%*ph\n", cmd, (int)len, 
data);\
else \
-   DRM_DEBUG_DRIVER("cmd=%02x, len=%zu\n", cmd, len); \
+   drm_dbg_driver(NULL, "cmd=%02x, len=%zu\n", cmd, len); \
 })
 
 static const u8 mipi_dbi_dcs_read_commands[] = {
@@ -708,7 +708,7 @@ bool mipi_dbi_display_is_on(struct mipi_dbi *dbi)
DCS_POWER_MODE_DISPLAY_NORMAL_MODE | DCS_POWER_MODE_SLEEP_MODE))
return false;
 
-   DRM_DEBUG_DRIVER("Display is ON\n");
+   drm_dbg_driver(NULL, "Display is ON\n");
 
return true;
 }
@@ -1256,7 +1256,7 @@ int mipi_dbi_spi_init(struct spi_device *spi, struct 
mipi_dbi *dbi,
 
mutex_init(>cmdlock);
 
-   DRM_DEBUG_DRIVER("SPI speed: %uMHz\n", spi->max_speed_hz / 100);
+   drm_dbg_driver(NULL, "SPI speed: %uMHz\n", spi->max_speed_hz / 100);
 
return 0;
 }
diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
index df791cd747da..1faecbd407a4 100644
--- a/include/drm/drm_print.h
+++ b/include/drm/drm_print.h
@@ -609,7 +609,7 @@ void __drm_err(const char *format, ...);
 #define DRM_DEBUG(fmt, ...)\
__drm_dbg(DRM_UT_CORE, fmt, ##__VA_ARGS__)
 
-/* NOTE: this is deprecated in favor of drm_dbg(NULL, ...). */
+/* NOTE: this is deprecated in favor of drm_dbg_driver(NULL, ...). */
 #define DRM_DEBUG_DRIVER(fmt, ...) \
__drm_dbg(DRM_UT_DRIVER, fmt, ##__VA_ARGS__)
 
-- 
2.39.0




[PATCH v4 05/10] drm: Remove usage of deprecated DRM_DEBUG

2023-01-05 Thread Siddh Raman Pant
drm_print.h says DRM_DEBUG is deprecated in favor of drm_dbg_core().

Signed-off-by: Siddh Raman Pant 
---
 drivers/gpu/drm/drm_agpsupport.c  |   4 +-
 drivers/gpu/drm/drm_bufs.c| 114 +++---
 drivers/gpu/drm/drm_context.c |  14 ++--
 drivers/gpu/drm/drm_dma.c |  10 +--
 drivers/gpu/drm/drm_drv.c |  10 +--
 drivers/gpu/drm/drm_gem.c |   5 +-
 drivers/gpu/drm/drm_hashtab.c |   6 +-
 drivers/gpu/drm/drm_irq.c |   4 +-
 drivers/gpu/drm/drm_lease.c   |   2 +-
 drivers/gpu/drm/drm_legacy_misc.c |   4 +-
 drivers/gpu/drm/drm_lock.c|  20 +++---
 drivers/gpu/drm/drm_mode_object.c |   6 +-
 drivers/gpu/drm/drm_pci.c |  12 ++--
 drivers/gpu/drm/drm_plane.c   |  12 ++--
 drivers/gpu/drm/drm_scatter.c |  10 +--
 drivers/gpu/drm/drm_syncobj.c |   2 +-
 drivers/gpu/drm/drm_sysfs.c   |  14 ++--
 drivers/gpu/drm/drm_vm.c  |  43 ++-
 18 files changed, 150 insertions(+), 142 deletions(-)

diff --git a/drivers/gpu/drm/drm_agpsupport.c b/drivers/gpu/drm/drm_agpsupport.c
index a4ad6fd13abc..d27686d6e82d 100644
--- a/drivers/gpu/drm/drm_agpsupport.c
+++ b/drivers/gpu/drm/drm_agpsupport.c
@@ -315,8 +315,8 @@ int drm_legacy_agp_bind(struct drm_device *dev, struct 
drm_agp_binding *request)
if (retcode)
return retcode;
entry->bound = dev->agp->base + (page << PAGE_SHIFT);
-   DRM_DEBUG("base = 0x%lx entry->bound = 0x%lx\n",
- dev->agp->base, entry->bound);
+   drm_dbg_core(dev, "base = 0x%lx entry->bound = 0x%lx\n",
+dev->agp->base, entry->bound);
return 0;
 }
 EXPORT_SYMBOL(drm_legacy_agp_bind);
diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
index 98aaf3379a3b..feedd7c6f0d5 100644
--- a/drivers/gpu/drm/drm_bufs.c
+++ b/drivers/gpu/drm/drm_bufs.c
@@ -171,8 +171,8 @@ static int drm_addmap_core(struct drm_device *dev, 
resource_size_t offset,
kfree(map);
return -EINVAL;
}
-   DRM_DEBUG("offset = 0x%08llx, size = 0x%08lx, type = %d\n",
- (unsigned long long)map->offset, map->size, map->type);
+   drm_dbg_core(dev, "offset = 0x%08llx, size = 0x%08lx, type = %d\n",
+(unsigned long long)map->offset, map->size, map->type);
 
/* page-align _DRM_SHM maps. They are allocated here so there is no 
security
 * hole created by that and it works around various broken drivers that 
use
@@ -205,10 +205,10 @@ static int drm_addmap_core(struct drm_device *dev, 
resource_size_t offset,
list = drm_find_matching_map(dev, map);
if (list != NULL) {
if (list->map->size != map->size) {
-   DRM_DEBUG("Matching maps of type %d with "
- "mismatched sizes, (%ld vs %ld)\n",
- map->type, map->size,
- list->map->size);
+   drm_dbg_core(dev, "Matching maps of type %d 
with "
+"mismatched sizes, (%ld vs %ld)\n",
+map->type, map->size,
+list->map->size);
list->map->size = map->size;
}
 
@@ -239,9 +239,9 @@ static int drm_addmap_core(struct drm_device *dev, 
resource_size_t offset,
list = drm_find_matching_map(dev, map);
if (list != NULL) {
if (list->map->size != map->size) {
-   DRM_DEBUG("Matching maps of type %d with "
- "mismatched sizes, (%ld vs %ld)\n",
- map->type, map->size, 
list->map->size);
+   drm_dbg_core(dev, "Matching maps of type %d 
with "
+"mismatched sizes, (%ld vs %ld)\n",
+map->type, map->size, 
list->map->size);
list->map->size = map->size;
}
 
@@ -250,8 +250,8 @@ static int drm_addmap_core(struct drm_device *dev, 
resource_size_t offset,
return 0;
}
map->handle = vmalloc_user(map->size);
-   DRM_DEBUG("%lu %d %p\n",
- map->size, order_base_2(map->size), map->handle);
+   drm_dbg_core(dev, "%lu %d %p\n",
+map->size, order_base_2(map->size), map->handle);
if (!map->handle) {
kfree(map);
return -ENOMEM;
@@ -308,8 +308,8 @@ static int drm_addmap_core(struct drm_device *dev, 
resource_size_t offset,
kfree(map);
return -EPERM;
}
- 

[PATCH v4 08/10] drm: Remove usage of deprecated DRM_DEBUG_PRIME

2023-01-05 Thread Siddh Raman Pant
drm_print.h says DRM_DEBUG_PRIME is deprecated in favor of
drm_dbg_prime().

Signed-off-by: Siddh Raman Pant 
Reviewed-by: Simon Ser 
---
 drivers/gpu/drm/drm_gem_dma_helper.c   | 4 ++--
 drivers/gpu/drm/drm_gem_shmem_helper.c | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_gem_dma_helper.c 
b/drivers/gpu/drm/drm_gem_dma_helper.c
index 1ba551b0ab97..0f903cc8914a 100644
--- a/drivers/gpu/drm/drm_gem_dma_helper.c
+++ b/drivers/gpu/drm/drm_gem_dma_helper.c
@@ -477,8 +477,8 @@ drm_gem_dma_prime_import_sg_table(struct drm_device *dev,
dma_obj->dma_addr = sg_dma_address(sgt->sgl);
dma_obj->sgt = sgt;
 
-   DRM_DEBUG_PRIME("dma_addr = %pad, size = %zu\n", _obj->dma_addr,
-   attach->dmabuf->size);
+   drm_dbg_prime(dev, "dma_addr = %pad, size = %zu\n", _obj->dma_addr,
+ attach->dmabuf->size);
 
return _obj->base;
 }
diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c 
b/drivers/gpu/drm/drm_gem_shmem_helper.c
index e99426b5be93..c8780b72e4e8 100644
--- a/drivers/gpu/drm/drm_gem_shmem_helper.c
+++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
@@ -760,7 +760,7 @@ drm_gem_shmem_prime_import_sg_table(struct drm_device *dev,
 
shmem->sgt = sgt;
 
-   DRM_DEBUG_PRIME("size = %zu\n", size);
+   drm_dbg_prime(dev, "size = %zu\n", size);
 
return >base;
 }
-- 
2.39.0




[PATCH v4] drm/amd/display: fix PSR-SU/DSC interoperability support

2023-01-05 Thread Hamza Mahfooz
Currently, there are issues with enabling PSR-SU + DSC. This stems from
the fact that DSC imposes a slice height on transmitted video data and
we are not conforming to that slice height in PSR-SU regions. So, pass
slice_height into su_y_granularity to feed the DSC slice height into
PSR-SU code.

Signed-off-by: Hamza Mahfooz 
---
v2: move code to modules/power.
v3: use ASSERT() instead of WARN() and add a condition that clarifies
that PSR-SU + DSC can only be enabled on an eDP connection.
v4: change the logic again to allow non-eDP links to pass the first
filter in psr_su_set_y_granularity() (this allows us to maintain
the v1/v2 behaviour, while still being clear as to the fact that we
only care about eDP connections).
---
 .../drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c |  3 ++
 .../amd/display/modules/power/power_helpers.c | 31 +++
 .../amd/display/modules/power/power_helpers.h |  3 ++
 3 files changed, 37 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c
index 26291db0a3cf..872d06fe1436 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c
@@ -122,6 +122,9 @@ bool amdgpu_dm_link_setup_psr(struct dc_stream_state 
*stream)
psr_config.allow_multi_disp_optimizations =
(amdgpu_dc_feature_mask & DC_PSR_ALLOW_MULTI_DISP_OPT);
 
+   if (!psr_su_set_y_granularity(dc, link, stream, _config))
+   return false;
+
ret = dc_link_setup_psr(link, stream, _config, 
_context);
 
}
diff --git a/drivers/gpu/drm/amd/display/modules/power/power_helpers.c 
b/drivers/gpu/drm/amd/display/modules/power/power_helpers.c
index 9b5d9b2c9a6a..cf4fa87c7db6 100644
--- a/drivers/gpu/drm/amd/display/modules/power/power_helpers.c
+++ b/drivers/gpu/drm/amd/display/modules/power/power_helpers.c
@@ -916,3 +916,34 @@ bool mod_power_only_edp(const struct dc_state *context, 
const struct dc_stream_s
 {
return context && context->stream_count == 1 && 
dc_is_embedded_signal(stream->signal);
 }
+
+bool psr_su_set_y_granularity(struct dc *dc, struct dc_link *link,
+ struct dc_stream_state *stream,
+ struct psr_config *config)
+{
+   uint16_t pic_height;
+   uint8_t slice_height;
+
+   if ((link->connector_signal & SIGNAL_TYPE_EDP) &&
+   (!dc->caps.edp_dsc_support ||
+   link->panel_config.dsc.disable_dsc_edp ||
+   
!link->dpcd_caps.dsc_caps.dsc_basic_caps.fields.dsc_support.DSC_SUPPORT ||
+   !stream->timing.dsc_cfg.num_slices_v))
+   return true;
+
+   pic_height = stream->timing.v_addressable +
+   stream->timing.v_border_top + stream->timing.v_border_bottom;
+   slice_height = pic_height / stream->timing.dsc_cfg.num_slices_v;
+
+   if (slice_height) {
+   if (config->su_y_granularity &&
+   (slice_height % config->su_y_granularity)) {
+   ASSERT(0);
+   return false;
+   }
+
+   config->su_y_granularity = slice_height;
+   }
+
+   return true;
+}
diff --git a/drivers/gpu/drm/amd/display/modules/power/power_helpers.h 
b/drivers/gpu/drm/amd/display/modules/power/power_helpers.h
index 316452e9dbc9..bb16b37b83da 100644
--- a/drivers/gpu/drm/amd/display/modules/power/power_helpers.h
+++ b/drivers/gpu/drm/amd/display/modules/power/power_helpers.h
@@ -59,4 +59,7 @@ void mod_power_calc_psr_configs(struct psr_config *psr_config,
const struct dc_stream_state *stream);
 bool mod_power_only_edp(const struct dc_state *context,
const struct dc_stream_state *stream);
+bool psr_su_set_y_granularity(struct dc *dc, struct dc_link *link,
+ struct dc_stream_state *stream,
+ struct psr_config *config);
 #endif /* MODULES_POWER_POWER_HELPERS_H_ */
-- 
2.38.1



linux-next: duplicate patches in the drm-misc tree

2023-01-05 Thread Stephen Rothwell
Hi all,

The following commits also exist in Linus Torvald's tree as different
commits (but the same patches):

  a189b2ee938f ("fbdev: Make fb_modesetting_disabled() static inline")
  7aa3d63e1ad5 ("Revert "drm/fb-helper: Remove damage worker"")
  8b83e1a45538 ("Revert "drm/fb-helper: Schedule deferred-I/O worker after 
writing to framebuffer"")
  e3ddd2d25533 ("Revert "drm/fb-helper: Perform damage handling in deferred-I/O 
helper"")

-- 
Cheers,
Stephen Rothwell


pgpoB_hmH2DBj.pgp
Description: OpenPGP digital signature


Re: [PATCH v3] drm/amd/display: fix PSR-SU/DSC interoperability support

2023-01-05 Thread Harry Wentland
On 1/5/23 15:33, Hamza Mahfooz wrote:
> Currently, there are issues with enabling PSR-SU + DSC. This stems from
> the fact that DSC imposes a slice height on transmitted video data and
> we are not conforming to that slice height in PSR-SU regions. So, pass
> slice_height into su_y_granularity to feed the DSC slice height into
> PSR-SU code.
> 
> Signed-off-by: Hamza Mahfooz 

Acked-by: Harry Wentland 

Harry

> ---
> v2: move code to modules/power.
> v3: use ASSERT() instead of WARN() and add a condition that clarifies
> that PSR-SU + DSC can only be enabled on an eDP connection.
> ---
>  .../drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c |  3 ++
>  .../amd/display/modules/power/power_helpers.c | 31 +++
>  .../amd/display/modules/power/power_helpers.h |  3 ++
>  3 files changed, 37 insertions(+)
> 
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c
> index 26291db0a3cf..872d06fe1436 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c
> @@ -122,6 +122,9 @@ bool amdgpu_dm_link_setup_psr(struct dc_stream_state 
> *stream)
>   psr_config.allow_multi_disp_optimizations =
>   (amdgpu_dc_feature_mask & DC_PSR_ALLOW_MULTI_DISP_OPT);
>  
> + if (!psr_su_set_y_granularity(dc, link, stream, _config))
> + return false;
> +
>   ret = dc_link_setup_psr(link, stream, _config, 
> _context);
>  
>   }
> diff --git a/drivers/gpu/drm/amd/display/modules/power/power_helpers.c 
> b/drivers/gpu/drm/amd/display/modules/power/power_helpers.c
> index 9b5d9b2c9a6a..381f708ef756 100644
> --- a/drivers/gpu/drm/amd/display/modules/power/power_helpers.c
> +++ b/drivers/gpu/drm/amd/display/modules/power/power_helpers.c
> @@ -916,3 +916,34 @@ bool mod_power_only_edp(const struct dc_state *context, 
> const struct dc_stream_s
>  {
>   return context && context->stream_count == 1 && 
> dc_is_embedded_signal(stream->signal);
>  }
> +
> +bool psr_su_set_y_granularity(struct dc *dc, struct dc_link *link,
> +   struct dc_stream_state *stream,
> +   struct psr_config *config)
> +{
> + uint16_t pic_height;
> + uint8_t slice_height;
> +
> + if (!dc->caps.edp_dsc_support ||
> + link->panel_config.dsc.disable_dsc_edp ||
> + 
> !link->dpcd_caps.dsc_caps.dsc_basic_caps.fields.dsc_support.DSC_SUPPORT ||
> + !(link->connector_signal & SIGNAL_TYPE_EDP) ||
> + !stream->timing.dsc_cfg.num_slices_v)
> + return true;
> +
> + pic_height = stream->timing.v_addressable +
> + stream->timing.v_border_top + stream->timing.v_border_bottom;
> + slice_height = pic_height / stream->timing.dsc_cfg.num_slices_v;
> +
> + if (slice_height) {
> + if (config->su_y_granularity &&
> + (slice_height % config->su_y_granularity)) {
> + ASSERT(0);
> + return false;
> + }
> +
> + config->su_y_granularity = slice_height;
> + }
> +
> + return true;
> +}
> diff --git a/drivers/gpu/drm/amd/display/modules/power/power_helpers.h 
> b/drivers/gpu/drm/amd/display/modules/power/power_helpers.h
> index 316452e9dbc9..bb16b37b83da 100644
> --- a/drivers/gpu/drm/amd/display/modules/power/power_helpers.h
> +++ b/drivers/gpu/drm/amd/display/modules/power/power_helpers.h
> @@ -59,4 +59,7 @@ void mod_power_calc_psr_configs(struct psr_config 
> *psr_config,
>   const struct dc_stream_state *stream);
>  bool mod_power_only_edp(const struct dc_state *context,
>   const struct dc_stream_state *stream);
> +bool psr_su_set_y_granularity(struct dc *dc, struct dc_link *link,
> +   struct dc_stream_state *stream,
> +   struct psr_config *config);
>  #endif /* MODULES_POWER_POWER_HELPERS_H_ */



Re: [Intel-gfx] [RFC PATCH 04/20] drm/sched: Convert drm scheduler to use a work queue rather than kthread

2023-01-05 Thread Matthew Brost
On Tue, Jan 03, 2023 at 01:02:15PM +, Tvrtko Ursulin wrote:
> 
> On 02/01/2023 07:30, Boris Brezillon wrote:
> > On Fri, 30 Dec 2022 12:55:08 +0100
> > Boris Brezillon  wrote:
> > 
> > > On Fri, 30 Dec 2022 11:20:42 +0100
> > > Boris Brezillon  wrote:
> > > 
> > > > Hello Matthew,
> > > > 
> > > > On Thu, 22 Dec 2022 14:21:11 -0800
> > > > Matthew Brost  wrote:
> > > > > In XE, the new Intel GPU driver, a choice has made to have a 1 to 1
> > > > > mapping between a drm_gpu_scheduler and drm_sched_entity. At first 
> > > > > this
> > > > > seems a bit odd but let us explain the reasoning below.
> > > > > 
> > > > > 1. In XE the submission order from multiple drm_sched_entity is not
> > > > > guaranteed to be the same completion even if targeting the same 
> > > > > hardware
> > > > > engine. This is because in XE we have a firmware scheduler, the GuC,
> > > > > which allowed to reorder, timeslice, and preempt submissions. If a 
> > > > > using
> > > > > shared drm_gpu_scheduler across multiple drm_sched_entity, the TDR 
> > > > > falls
> > > > > apart as the TDR expects submission order == completion order. Using a
> > > > > dedicated drm_gpu_scheduler per drm_sched_entity solve this problem.
> > > > 
> > > > Oh, that's interesting. I've been trying to solve the same sort of
> > > > issues to support Arm's new Mali GPU which is relying on a FW-assisted
> > > > scheduling scheme (you give the FW N streams to execute, and it does
> > > > the scheduling between those N command streams, the kernel driver
> > > > does timeslice scheduling to update the command streams passed to the
> > > > FW). I must admit I gave up on using drm_sched at some point, mostly
> > > > because the integration with drm_sched was painful, but also because I
> > > > felt trying to bend drm_sched to make it interact with a
> > > > timeslice-oriented scheduling model wasn't really future proof. Giving
> > > > drm_sched_entity exlusive access to a drm_gpu_scheduler probably might
> > > > help for a few things (didn't think it through yet), but I feel it's
> > > > coming short on other aspects we have to deal with on Arm GPUs.
> > > 
> > > Ok, so I just had a quick look at the Xe driver and how it
> > > instantiates the drm_sched_entity and drm_gpu_scheduler, and I think I
> > > have a better understanding of how you get away with using drm_sched
> > > while still controlling how scheduling is really done. Here
> > > drm_gpu_scheduler is just a dummy abstract that let's you use the
> > > drm_sched job queuing/dep/tracking mechanism. The whole run-queue
> > > selection is dumb because there's only one entity ever bound to the
> > > scheduler (the one that's part of the xe_guc_engine object which also
> > > contains the drm_gpu_scheduler instance). I guess the main issue we'd
> > > have on Arm is the fact that the stream doesn't necessarily get
> > > scheduled when ->run_job() is called, it can be placed in the runnable
> > > queue and be picked later by the kernel-side scheduler when a FW slot
> > > gets released. That can probably be sorted out by manually disabling the
> > > job timer and re-enabling it when the stream gets picked by the
> > > scheduler. But my main concern remains, we're basically abusing
> > > drm_sched here.
> > > 
> > > For the Arm driver, that means turning the following sequence
> > > 
> > > 1. wait for job deps
> > > 2. queue job to ringbuf and push the stream to the runnable
> > > queue (if it wasn't queued already). Wakeup the timeslice scheduler
> > > to re-evaluate (if the stream is not on a FW slot already)
> > > 3. stream gets picked by the timeslice scheduler and sent to the FW for
> > > execution
> > > 
> > > into
> > > 
> > > 1. queue job to entity which takes care of waiting for job deps for
> > > us
> > > 2. schedule a drm_sched_main iteration
> > > 3. the only available entity is picked, and the first job from this
> > > entity is dequeued. ->run_job() is called: the job is queued to the
> > > ringbuf and the stream is pushed to the runnable queue (if it wasn't
> > > queued already). Wakeup the timeslice scheduler to re-evaluate (if
> > > the stream is not on a FW slot already)
> > > 4. stream gets picked by the timeslice scheduler and sent to the FW for
> > > execution
> > > 
> > > That's one extra step we don't really need. To sum-up, yes, all the
> > > job/entity tracking might be interesting to share/re-use, but I wonder
> > > if we couldn't have that without pulling out the scheduling part of
> > > drm_sched, or maybe I'm missing something, and there's something in
> > > drm_gpu_scheduler you really need.
> > 
> > On second thought, that's probably an acceptable overhead (not even
> > sure the extra step I was mentioning exists in practice, because dep
> > fence signaled state is checked as part of the drm_sched_main
> > iteration, so that's basically replacing the worker I schedule to
> > check job deps), and I like the idea of being able to re-use 

Re: [PATCH] drm/vkms: Add a DRM render node to vkms

2023-01-05 Thread 吴涛@Eng
Hi Daniel,

May I know what's the requirement for adding render node support to a
"gpu"?  Why we just export render node for every drm devices?
I read document here
https://www.kernel.org/doc/html/v4.8/gpu/drm-uapi.html#render-nodes
and it seems render node allow multiple unprivileged clients
to work with the same gpu, I am not sure why we just enable it for all
kms-only device.
What's wrong if we enable it for all kms-only devices and also let
mesa to use llvmpipe with those devices by default.

Thanks!

On Thu, Jan 5, 2023 at 7:35 AM Daniel Vetter  wrote:
>
> On Fri, Jan 06, 2023 at 12:16:07AM +0900, Yi Xie wrote:
> > On Thu, Jan 5, 2023 at 11:16 PM Daniel Vetter  wrote:
> > >
> > > On Thu, Jan 05, 2023 at 11:10:23PM +0900, Yi Xie wrote:
> > > > On Thu, Jan 5, 2023 at 10:48 PM Daniel Vetter  wrote:
> > > > >
> > > > > On Thu, Jan 05, 2023 at 09:52:26PM +0900, Yi Xie wrote:
> > > > > > > This doesn't sound like a good idea to me. Devices without render
> > > > > > > capabilities should not fake it.
> > > > > > >
> > > > > > > User-space (e.g. wlroots) relies on "no render node" to enable
> > > > > > > software rendering (Pixman instead of GL).
> > > > > >
> > > > > > We have virtgpu driver that exports a render node even when virgl is
> > > > > > not supported.
> > > > > > Mesa has special code path to enable software rendering on it:
> > > > > > https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/egl/drivers/dri2/platform_device.c#L296
> > > > > > We can do the same for vkms to force software rendering.
> > > > >
> > > > > Yeah that is the old kmsro mesa issue, for every combination of kms 
> > > > > and
> > > > > gem device you need one to make this work.
> > > > >
> > > > > > On Thu, Jan 5, 2023 at 8:36 PM Daniel Vetter  
> > > > > > wrote:
> > > > > > >
> > > > > > > On Thu, Jan 05, 2023 at 02:23:25PM +0900, Yi Xie wrote:
> > > > > > > > Some libraries including Mesa and virglrenderer require a 
> > > > > > > > render node to
> > > > > > > > fully function. By adding a render node to vkms those libraries 
> > > > > > > > will
> > > > > > > > work properly, supporting use cases like running crosvm with 
> > > > > > > > virgl GPU
> > > > > > > > support via llvmpipe on a headless virtual machine.
> > > > > > >
> > > > > > > This is what vgem exists for. More or less at least ... I'm 
> > > > > > > honestly not
> > > > > > > really understanding what you're trying to fix here, it sounds a 
> > > > > > > bit like
> > > > > > > userspace being stupid.
> > > > > > > -Daniel
> > > > > > The problem with vgem is that it crashes llvmpipe while working 
> > > > > > with vkms.
> > > > > > Looks like it's due to the same reason as described in this thread 
> > > > > > in Mesa:
> > > > > > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5830
> > > > >
> > > > > I'm not finding any bug description in there and how/why something
> > > > > crashes?
> > > >
> > > > The discussion is in the comment section under the first comment by
> > > > Emil Velikov.
> > > > It's folded by default (inside "6 replies" at the bottom).
> > > >
> > > > >
> > > > > > Importing buffers allocated by vgem to vkms seems to be unexpected 
> > > > > > and
> > > > > > causes the crash. If we create a render node on vkms then llvmpipe 
> > > > > > will use
> > > > > > vkms to allocate buffers and it no longer crashes.
> > > > >
> > > > > Uh importing vgem into virtio might not work because those sometimes 
> > > > > need
> > > > > special buffers iirc. But importing vgem into vkms really should work,
> > > > > there's no technical reason it cannot. If it doesn't, then the right 
> > > > > fix
> > > > > would be to fix that, not paper around it.
> > > >
> > > > The crash stack trace looks like this:
> > > > https://gist.github.com/imxieyi/03053ae79cee2e614850fd41829e1da2
> > > >
> > > > Even if we fix the crash issue with vgem, we still need to workaround
> > > > quite a few
> > > > places that has explicitly blocked vgem. A notable example is 
> > > > virglrenderer:
> > > > https://gitlab.freedesktop.org/virgl/virglrenderer/-/blob/master/src/vrend_winsys_gbm.c#L121
> > > >
> > > > Actually I have tried to force running virglrenderer on vgem and it
> > > > didn't work. I
> > > > didn't look into why it wasn't working but I guess that's the reason
> > > > for blocking
> > > > vgem in the first place. Virglrenderer works well on vkms with render 
> > > > node
> > > > enabled though.
> > >
> > > Ah ok. For next time around, copy a link to the comment you want, e.g.
> > >
> > > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5830#note_582477
> > >
> > > The 3 dots menu on each comments has an option to copy that link tag. That
> > > also highlights the right comment.
> >
> > Thanks for the tips! Actually you need to sign in to reveal that 3 dots 
> > menu.
> >
> > >
> > > On this issue, I'm concurring with Emil:
> > >
> > > "- the import is broken
> > > "IMHO that should be fixed, regardless of the rest"
> > >
> > > The 

Re: [PATCH v2] drm/amd/display: fix PSR-SU/DSC interoperability support

2023-01-05 Thread Harry Wentland



On 1/5/23 15:12, Leo Li wrote:
> 
> 
> 
> On 1/5/23 15:07, Hamza Mahfooz wrote:
>> On 1/5/23 13:29, Harry Wentland wrote:
>>>
>>>
>>> On 1/5/23 12:38, Hamza Mahfooz wrote:
 Currently, there are issues with enabling PSR-SU + DSC. This stems from
 the fact that DSC imposes a slice height on transmitted video data and
 we are not conforming to that slice height in PSR-SU regions. So, pass
 slice_height into su_y_granularity to feed the DSC slice height into
 PSR-SU code.

 Signed-off-by: Hamza Mahfooz 
 ---
 v2: move code to modules/power.
 ---
   .../drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c |  3 ++
   .../amd/display/modules/power/power_helpers.c | 35 +++
   .../amd/display/modules/power/power_helpers.h |  3 ++
   3 files changed, 41 insertions(+)

 diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c 
 b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c
 index 26291db0a3cf..872d06fe1436 100644
 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c
 +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c
 @@ -122,6 +122,9 @@ bool amdgpu_dm_link_setup_psr(struct dc_stream_state 
 *stream)
   psr_config.allow_multi_disp_optimizations =
   (amdgpu_dc_feature_mask & DC_PSR_ALLOW_MULTI_DISP_OPT);
 +    if (!psr_su_set_y_granularity(dc, link, stream, _config))
 +    return false;
 +
   ret = dc_link_setup_psr(link, stream, _config, _context);
   }
 diff --git a/drivers/gpu/drm/amd/display/modules/power/power_helpers.c 
 b/drivers/gpu/drm/amd/display/modules/power/power_helpers.c
 index 9b5d9b2c9a6a..4d27ad9f7370 100644
 --- a/drivers/gpu/drm/amd/display/modules/power/power_helpers.c
 +++ b/drivers/gpu/drm/amd/display/modules/power/power_helpers.c
 @@ -916,3 +916,38 @@ bool mod_power_only_edp(const struct dc_state 
 *context, const struct dc_stream_s
   {
   return context && context->stream_count == 1 && 
 dc_is_embedded_signal(stream->signal);
   }
 +
 +bool psr_su_set_y_granularity(struct dc *dc, struct dc_link *link,
 +  struct dc_stream_state *stream,
 +  struct psr_config *config)
 +{
 +    uint16_t pic_height;
 +    uint8_t slice_height;
 +
 +    if (!dc->caps.edp_dsc_support ||
 +    link->panel_config.dsc.disable_dsc_edp ||
 +    
 !link->dpcd_caps.dsc_caps.dsc_basic_caps.fields.dsc_support.DSC_SUPPORT ||
 +    !stream->timing.dsc_cfg.num_slices_v)
>>>
>>> I'm not sure this condition is correct. We can have DSC but not eDP DSC
>>> support.
>>>
>>
>> AFAIK PSR-SU displays use eDP exclusively, so we shouldn't have to worry 
>> about this case.
> 
> Right, the dc_link here should only be eDP. I suppose that isn't quite
> clear.
>

Right, I was thinking of DSC but PSR-SU is eDP only.

Harry
 
> Maybe add this as part of the condition?
> 
> if (!(link->connector_signal & SIGNAL_TYPE_EDP))
>     return true;
> 
> Thanks,
> Leo
> 
>>
 +    return true;
 +
 +    pic_height = stream->timing.v_addressable +
 +    stream->timing.v_border_top + stream->timing.v_border_bottom;
 +    slice_height = pic_height / stream->timing.dsc_cfg.num_slices_v;
 +
 +    if (slice_height) {
 +    if (config->su_y_granularity &&
 +    (slice_height % config->su_y_granularity)) {
 +    WARN(1,
>>>
>>> We don't use WARN in display/dc or display/modules. DC_LOG_WARNING
>>> might be better, or log it in the caller.
>>>
>>> Harry
>>>
 + "%s: dsc: %d, slice_height: %d, num_slices_v: %d\n",
 + __func__,
 + stream->sink->dsc_caps.dsc_dec_caps.is_dsc_supported,
 + slice_height,
 + stream->timing.dsc_cfg.num_slices_v);
 +    return false;
 +    }
 +
 +    config->su_y_granularity = slice_height;
 +    }
 +
 +    return true;
 +}
 diff --git a/drivers/gpu/drm/amd/display/modules/power/power_helpers.h 
 b/drivers/gpu/drm/amd/display/modules/power/power_helpers.h
 index 316452e9dbc9..bb16b37b83da 100644
 --- a/drivers/gpu/drm/amd/display/modules/power/power_helpers.h
 +++ b/drivers/gpu/drm/amd/display/modules/power/power_helpers.h
 @@ -59,4 +59,7 @@ void mod_power_calc_psr_configs(struct psr_config 
 *psr_config,
   const struct dc_stream_state *stream);
   bool mod_power_only_edp(const struct dc_state *context,
   const struct dc_stream_state *stream);
 +bool psr_su_set_y_granularity(struct dc *dc, struct dc_link *link,
 +  struct dc_stream_state *stream,
 +  struct psr_config *config);
   #endif /* MODULES_POWER_POWER_HELPERS_H_ */
>>>
>>



Re: [Intel-gfx] [RFC PATCH 00/20] Initial Xe driver submission

2023-01-05 Thread Matthew Brost
On Tue, Jan 03, 2023 at 12:21:08PM +, Tvrtko Ursulin wrote:
> 
> On 22/12/2022 22:21, Matthew Brost wrote:
> > Hello,
> > 
> > This is a submission for Xe, a new driver for Intel GPUs that supports both
> > integrated and discrete platforms starting with Tiger Lake (first platform 
> > with
> > Intel Xe Architecture). The intention of this new driver is to have a fresh 
> > base
> > to work from that is unencumbered by older platforms, whilst also taking the
> > opportunity to rearchitect our driver to increase sharing across the drm
> > subsystem, both leveraging and allowing us to contribute more towards other
> > shared components like TTM and drm/scheduler. The memory model is based on 
> > VM
> > bind which is similar to the i915 implementation. Likewise the execbuf
> > implementation for Xe is very similar to execbuf3 in the i915 [1].
> > 
> > The code is at a stage where it is already functional and has experimental
> > support for multiple platforms starting from Tiger Lake, with initial 
> > support
> > implemented in Mesa (for Iris and Anv, our OpenGL and Vulkan drivers), as 
> > well
> > as in NEO (for OpenCL and Level0). A Mesa MR has been posted [2] and NEO
> > implementation will be released publicly early next year. We also have a 
> > suite
> > of IGTs for XE that will appear on the IGT list shortly.
> > 
> > It has been built with the assumption of supporting multiple architectures 
> > from
> > the get-go, right now with tests running both on X86 and ARM hosts. And we
> > intend to continue working on it and improving on it as part of the kernel
> > community upstream.
> > 
> > The new Xe driver leverages a lot from i915 and work on i915 continues as we
> > ready Xe for production throughout 2023.
> > 
> > As for display, the intent is to share the display code with the i915 
> > driver so
> > that there is maximum reuse there. Currently this is being done by 
> > compiling the
> > display code twice, but alternatives to that are under consideration and we 
> > want
> > to have more discussion on what the best final solution will look like over 
> > the
> > next few months. Right now, work is ongoing in refactoring the display 
> > codebase
> > to remove as much as possible any unnecessary dependencies on i915 specific 
> > data
> > structures there..
> > 
> > We currently have 2 submission backends, execlists and GuC. The execlist is
> > meant mostly for testing and is not fully functional while GuC backend is 
> > fully
> > functional. As with the i915 and GuC submission, in Xe the GuC firmware is
> > required and should be placed in /lib/firmware/xe.
> 
> What is the plan going forward for the execlists backend? I think it would
> be preferable to not upstream something semi-functional and so to carry
> technical debt in the brand new code base, from the very start. If it is for
> Tigerlake, which is the starting platform for Xe, could it be made GuC only
> Tigerlake for instance?
> 

A little background here. In the original PoC written by Jason and Dave,
the execlist backend was the only one present and it was in semi-working
state. As soon as myself and a few others started working on Xe we went
full in a on the GuC backend. We left the execlist backend basically in
the state it was in. We left it in place for 2 reasons.

1. Having 2 backends from the start ensured we layered our code
correctly. The layer was a complete disaster in the i915 so we really
wanted to avoid that.
2. The thought was it might be needed for early product bring up one
day.

As I think about this a bit more, we likely just delete execlist backend
before merging this upstream and perhaps just carry 1 large patch
internally with this implementation that we can use as needed. Final
decession TDB though.

Matt

> Regards,
> 
> Tvrtko


Re: Try to address the DMA-buf coherency problem

2023-01-05 Thread Sebastian Wick
On Fri, Dec 9, 2022 at 11:28 AM Christian König
 wrote:
>
> Am 09.12.22 um 09:26 schrieb Tomasz Figa:
> > [SNIP]
> > Although I think the most common case on mainstream Linux today is
> > properly allocating for device X (e.g. V4L2 video decoder or DRM-based
> > GPU) and hoping that other devices would accept the buffers just fine,
> > which isn't a given on most platforms (although often it's just about
> > pixel format, width/height/stride alignment, tiling, etc. rather than
> > the memory itself). That's why ChromiumOS has minigbm and Android has
> > gralloc that act as the central point of knowledge on buffer
> > allocation.
>
> Yeah, completely agree. The crux is really that we need to improve those
> user space allocators by providing more information from the kernel.
>
> >> 2. We don't properly communicate allocation requirements to userspace.
> >>
> >> E.g. even if you allocate from DMA-Heaps userspace can currently only
> >> guess if normal, CMA or even device specific memory is needed.
> > DMA-buf heaps actually make it even more difficult for the userspace,
> > because now it needs to pick the right heap. With allocation built
> > into the specific UAPI (like V4L2), it's at least possible to allocate
> > for one specific device without having any knowledge about allocation
> > constraints in the userspace.
>
> Yes, same what Daniel said as well. We need to provide some more hints
> which allocator to use from the kernel.

This information doesn't necessarily have to come from the kernel. For
KMS it makes sense for the kernel to provide it but Vulkan drivers for
example could have the information entirely in the UMD. The important
point is that user space can somehow query which heap can be used with
which constraints for a specific operation. At that point it's
entirely a user space problem.

>
> >> So if a device driver uses cached system memory on an architecture 
> >> which
> >> devices which can't access it the right approach is clearly to reject
> >> the access.
> > I'd like to accent the fact that "requires cache maintenance" != "can't 
> > access".
>  Well that depends. As said above the exporter exports the buffer as it
>  was allocated.
> 
>  If that means the the exporter provides a piece of memory which requires
>  CPU cache snooping to access correctly then the best thing we can do is
>  to prevent an importer which can't do this from attaching.
> >>> Could you elaborate more about this case? Does it exist in practice?
> >>> Do I assume correctly that it's about sharing a buffer between one DMA
> >>> engine that is cache-coherent and another that is non-coherent, where
> >>> the first one ends up having its accesses always go through some kind
> >>> of a cache (CPU cache, L2/L3/... cache, etc.)?
> >> Yes, exactly that. What happens in this particular use case is that one
> >> device driver wrote to it's internal buffer with the CPU (so some cache
> >> lines where dirty) and then a device which couldn't deal with that tried
> >> to access it.
> > If so, shouldn't that driver surround its CPU accesses with
> > begin/end_cpu_access() in the first place?
>
> The problem is that the roles are reversed. The callbacks let the
> exporter knows that it needs to flush the caches when the importer is
> done accessing the buffer with the CPU.
>
> But here the exporter is the one accessing the buffer with the CPU and
> the importer then accesses stale data because it doesn't snoop the caches.
>
> What we could do is to force all exporters to use begin/end_cpu_access()
> even on it's own buffers and look at all the importers when the access
> is completed. But that would increase the complexity of the handling in
> the exporter.
>
> In other words we would then have code in the exporters which is only
> written for handling the constrains of the importers. This has a wide
> variety of consequences, especially that this functionality of the
> exporter can't be tested without a proper importer.
>
> I was also thinking about reversing the role of exporter and importer in
> the kernel, but came to the conclusion that doing this under the hood
> without userspace knowing about it is probably not going to work either.
>
> > The case that I was suggesting was of a hardware block that actually
> > sits behind the CPU cache and thus dirties it on writes, not the
> > driver doing that. (I haven't personally encountered such a system,
> > though.)
>
> Never heard of anything like that either, but who knows.
>
> >> We could say that all device drivers must always look at the coherency
> >> of the devices which want to access their buffers. But that would
> >> horrible complicate things for maintaining the drivers because then
> >> drivers would need to take into account requirements from other drivers
> >> while allocating their internal buffers.
> > I think it's partially why we have the allocation part of the DMA
> > mapping API, but currently it's only 

[PATCH v3] drm/amd/display: fix PSR-SU/DSC interoperability support

2023-01-05 Thread Hamza Mahfooz
Currently, there are issues with enabling PSR-SU + DSC. This stems from
the fact that DSC imposes a slice height on transmitted video data and
we are not conforming to that slice height in PSR-SU regions. So, pass
slice_height into su_y_granularity to feed the DSC slice height into
PSR-SU code.

Signed-off-by: Hamza Mahfooz 
---
v2: move code to modules/power.
v3: use ASSERT() instead of WARN() and add a condition that clarifies
that PSR-SU + DSC can only be enabled on an eDP connection.
---
 .../drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c |  3 ++
 .../amd/display/modules/power/power_helpers.c | 31 +++
 .../amd/display/modules/power/power_helpers.h |  3 ++
 3 files changed, 37 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c
index 26291db0a3cf..872d06fe1436 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c
@@ -122,6 +122,9 @@ bool amdgpu_dm_link_setup_psr(struct dc_stream_state 
*stream)
psr_config.allow_multi_disp_optimizations =
(amdgpu_dc_feature_mask & DC_PSR_ALLOW_MULTI_DISP_OPT);
 
+   if (!psr_su_set_y_granularity(dc, link, stream, _config))
+   return false;
+
ret = dc_link_setup_psr(link, stream, _config, 
_context);
 
}
diff --git a/drivers/gpu/drm/amd/display/modules/power/power_helpers.c 
b/drivers/gpu/drm/amd/display/modules/power/power_helpers.c
index 9b5d9b2c9a6a..381f708ef756 100644
--- a/drivers/gpu/drm/amd/display/modules/power/power_helpers.c
+++ b/drivers/gpu/drm/amd/display/modules/power/power_helpers.c
@@ -916,3 +916,34 @@ bool mod_power_only_edp(const struct dc_state *context, 
const struct dc_stream_s
 {
return context && context->stream_count == 1 && 
dc_is_embedded_signal(stream->signal);
 }
+
+bool psr_su_set_y_granularity(struct dc *dc, struct dc_link *link,
+ struct dc_stream_state *stream,
+ struct psr_config *config)
+{
+   uint16_t pic_height;
+   uint8_t slice_height;
+
+   if (!dc->caps.edp_dsc_support ||
+   link->panel_config.dsc.disable_dsc_edp ||
+   
!link->dpcd_caps.dsc_caps.dsc_basic_caps.fields.dsc_support.DSC_SUPPORT ||
+   !(link->connector_signal & SIGNAL_TYPE_EDP) ||
+   !stream->timing.dsc_cfg.num_slices_v)
+   return true;
+
+   pic_height = stream->timing.v_addressable +
+   stream->timing.v_border_top + stream->timing.v_border_bottom;
+   slice_height = pic_height / stream->timing.dsc_cfg.num_slices_v;
+
+   if (slice_height) {
+   if (config->su_y_granularity &&
+   (slice_height % config->su_y_granularity)) {
+   ASSERT(0);
+   return false;
+   }
+
+   config->su_y_granularity = slice_height;
+   }
+
+   return true;
+}
diff --git a/drivers/gpu/drm/amd/display/modules/power/power_helpers.h 
b/drivers/gpu/drm/amd/display/modules/power/power_helpers.h
index 316452e9dbc9..bb16b37b83da 100644
--- a/drivers/gpu/drm/amd/display/modules/power/power_helpers.h
+++ b/drivers/gpu/drm/amd/display/modules/power/power_helpers.h
@@ -59,4 +59,7 @@ void mod_power_calc_psr_configs(struct psr_config *psr_config,
const struct dc_stream_state *stream);
 bool mod_power_only_edp(const struct dc_state *context,
const struct dc_stream_state *stream);
+bool psr_su_set_y_granularity(struct dc *dc, struct dc_link *link,
+ struct dc_stream_state *stream,
+ struct psr_config *config);
 #endif /* MODULES_POWER_POWER_HELPERS_H_ */
-- 
2.38.1



Re: [PATCH] drm/drv: Make use of local variable driver in drm_dev_register()

2023-01-05 Thread Uwe Kleine-König
Hello Daniel,

On Thu, Jan 05, 2023 at 03:33:13PM +0100, Daniel Vetter wrote:
> On Tue, Dec 20, 2022 at 08:24:18AM +0100, Thomas Zimmermann wrote:
> > Hi
> > 
> > Am 19.12.22 um 19:31 schrieb Uwe Kleine-König:
> > > There is a local variable that contains dev->driver. Make use of it
> > > instead of "open coding" it.
> > > 
> > > Signed-off-by: Uwe Kleine-König 
> > 
> > Added to drm-misc-next. Thanks a lot.
> 
> Given that Uwe has a pile of drm commits all over, time for drm-misc
> commit rights?

I feel honored, but if you ask me, that's not necessary/sensible. At
least up to now my patches are more or less drive-by changes and letting
them go through someone else with commit access is fine for me. There is
no driver in the drm area I feel responsible for.

Or is this about reducing maintainer load on your end?

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |


signature.asc
Description: PGP signature


Re: [PATCH v2] drm/amd/display: fix PSR-SU/DSC interoperability support

2023-01-05 Thread Leo Li





On 1/5/23 15:07, Hamza Mahfooz wrote:

On 1/5/23 13:29, Harry Wentland wrote:



On 1/5/23 12:38, Hamza Mahfooz wrote:

Currently, there are issues with enabling PSR-SU + DSC. This stems from
the fact that DSC imposes a slice height on transmitted video data and
we are not conforming to that slice height in PSR-SU regions. So, pass
slice_height into su_y_granularity to feed the DSC slice height into
PSR-SU code.

Signed-off-by: Hamza Mahfooz 
---
v2: move code to modules/power.
---
  .../drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c |  3 ++
  .../amd/display/modules/power/power_helpers.c | 35 +++
  .../amd/display/modules/power/power_helpers.h |  3 ++
  3 files changed, 41 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c

index 26291db0a3cf..872d06fe1436 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c
@@ -122,6 +122,9 @@ bool amdgpu_dm_link_setup_psr(struct 
dc_stream_state *stream)

  psr_config.allow_multi_disp_optimizations =
  (amdgpu_dc_feature_mask & DC_PSR_ALLOW_MULTI_DISP_OPT);
+    if (!psr_su_set_y_granularity(dc, link, stream, _config))
+    return false;
+
  ret = dc_link_setup_psr(link, stream, _config, 
_context);

  }
diff --git 
a/drivers/gpu/drm/amd/display/modules/power/power_helpers.c 
b/drivers/gpu/drm/amd/display/modules/power/power_helpers.c

index 9b5d9b2c9a6a..4d27ad9f7370 100644
--- a/drivers/gpu/drm/amd/display/modules/power/power_helpers.c
+++ b/drivers/gpu/drm/amd/display/modules/power/power_helpers.c
@@ -916,3 +916,38 @@ bool mod_power_only_edp(const struct dc_state 
*context, const struct dc_stream_s

  {
  return context && context->stream_count == 1 && 
dc_is_embedded_signal(stream->signal);

  }
+
+bool psr_su_set_y_granularity(struct dc *dc, struct dc_link *link,
+  struct dc_stream_state *stream,
+  struct psr_config *config)
+{
+    uint16_t pic_height;
+    uint8_t slice_height;
+
+    if (!dc->caps.edp_dsc_support ||
+    link->panel_config.dsc.disable_dsc_edp ||
+
!link->dpcd_caps.dsc_caps.dsc_basic_caps.fields.dsc_support.DSC_SUPPORT ||

+    !stream->timing.dsc_cfg.num_slices_v)


I'm not sure this condition is correct. We can have DSC but not eDP DSC
support.



AFAIK PSR-SU displays use eDP exclusively, so we shouldn't have to worry 
about this case.


Right, the dc_link here should only be eDP. I suppose that isn't quite
clear.

Maybe add this as part of the condition?

if (!(link->connector_signal & SIGNAL_TYPE_EDP))
return true;

Thanks,
Leo




+    return true;
+
+    pic_height = stream->timing.v_addressable +
+    stream->timing.v_border_top + stream->timing.v_border_bottom;
+    slice_height = pic_height / stream->timing.dsc_cfg.num_slices_v;
+
+    if (slice_height) {
+    if (config->su_y_granularity &&
+    (slice_height % config->su_y_granularity)) {
+    WARN(1,


We don't use WARN in display/dc or display/modules. DC_LOG_WARNING
might be better, or log it in the caller.

Harry


+ "%s: dsc: %d, slice_height: %d, num_slices_v: %d\n",
+ __func__,
+ stream->sink->dsc_caps.dsc_dec_caps.is_dsc_supported,
+ slice_height,
+ stream->timing.dsc_cfg.num_slices_v);
+    return false;
+    }
+
+    config->su_y_granularity = slice_height;
+    }
+
+    return true;
+}
diff --git 
a/drivers/gpu/drm/amd/display/modules/power/power_helpers.h 
b/drivers/gpu/drm/amd/display/modules/power/power_helpers.h

index 316452e9dbc9..bb16b37b83da 100644
--- a/drivers/gpu/drm/amd/display/modules/power/power_helpers.h
+++ b/drivers/gpu/drm/amd/display/modules/power/power_helpers.h
@@ -59,4 +59,7 @@ void mod_power_calc_psr_configs(struct psr_config 
*psr_config,

  const struct dc_stream_state *stream);
  bool mod_power_only_edp(const struct dc_state *context,
  const struct dc_stream_state *stream);
+bool psr_su_set_y_granularity(struct dc *dc, struct dc_link *link,
+  struct dc_stream_state *stream,
+  struct psr_config *config);
  #endif /* MODULES_POWER_POWER_HELPERS_H_ */






Re: [PATCH v2] drm/amd/display: fix PSR-SU/DSC interoperability support

2023-01-05 Thread Hamza Mahfooz

On 1/5/23 13:29, Harry Wentland wrote:



On 1/5/23 12:38, Hamza Mahfooz wrote:

Currently, there are issues with enabling PSR-SU + DSC. This stems from
the fact that DSC imposes a slice height on transmitted video data and
we are not conforming to that slice height in PSR-SU regions. So, pass
slice_height into su_y_granularity to feed the DSC slice height into
PSR-SU code.

Signed-off-by: Hamza Mahfooz 
---
v2: move code to modules/power.
---
  .../drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c |  3 ++
  .../amd/display/modules/power/power_helpers.c | 35 +++
  .../amd/display/modules/power/power_helpers.h |  3 ++
  3 files changed, 41 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c
index 26291db0a3cf..872d06fe1436 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c
@@ -122,6 +122,9 @@ bool amdgpu_dm_link_setup_psr(struct dc_stream_state 
*stream)
psr_config.allow_multi_disp_optimizations =
(amdgpu_dc_feature_mask & DC_PSR_ALLOW_MULTI_DISP_OPT);
  
+		if (!psr_su_set_y_granularity(dc, link, stream, _config))

+   return false;
+
ret = dc_link_setup_psr(link, stream, _config, 
_context);
  
  	}

diff --git a/drivers/gpu/drm/amd/display/modules/power/power_helpers.c 
b/drivers/gpu/drm/amd/display/modules/power/power_helpers.c
index 9b5d9b2c9a6a..4d27ad9f7370 100644
--- a/drivers/gpu/drm/amd/display/modules/power/power_helpers.c
+++ b/drivers/gpu/drm/amd/display/modules/power/power_helpers.c
@@ -916,3 +916,38 @@ bool mod_power_only_edp(const struct dc_state *context, 
const struct dc_stream_s
  {
return context && context->stream_count == 1 && 
dc_is_embedded_signal(stream->signal);
  }
+
+bool psr_su_set_y_granularity(struct dc *dc, struct dc_link *link,
+ struct dc_stream_state *stream,
+ struct psr_config *config)
+{
+   uint16_t pic_height;
+   uint8_t slice_height;
+
+   if (!dc->caps.edp_dsc_support ||
+   link->panel_config.dsc.disable_dsc_edp ||
+   
!link->dpcd_caps.dsc_caps.dsc_basic_caps.fields.dsc_support.DSC_SUPPORT ||
+   !stream->timing.dsc_cfg.num_slices_v)


I'm not sure this condition is correct. We can have DSC but not eDP DSC
support.



AFAIK PSR-SU displays use eDP exclusively, so we shouldn't have to worry 
about this case.



+   return true;
+
+   pic_height = stream->timing.v_addressable +
+   stream->timing.v_border_top + stream->timing.v_border_bottom;
+   slice_height = pic_height / stream->timing.dsc_cfg.num_slices_v;
+
+   if (slice_height) {
+   if (config->su_y_granularity &&
+   (slice_height % config->su_y_granularity)) {
+   WARN(1,


We don't use WARN in display/dc or display/modules. DC_LOG_WARNING
might be better, or log it in the caller.

Harry


+"%s: dsc: %d, slice_height: %d, num_slices_v: 
%d\n",
+__func__,
+
stream->sink->dsc_caps.dsc_dec_caps.is_dsc_supported,
+slice_height,
+stream->timing.dsc_cfg.num_slices_v);
+   return false;
+   }
+
+   config->su_y_granularity = slice_height;
+   }
+
+   return true;
+}
diff --git a/drivers/gpu/drm/amd/display/modules/power/power_helpers.h 
b/drivers/gpu/drm/amd/display/modules/power/power_helpers.h
index 316452e9dbc9..bb16b37b83da 100644
--- a/drivers/gpu/drm/amd/display/modules/power/power_helpers.h
+++ b/drivers/gpu/drm/amd/display/modules/power/power_helpers.h
@@ -59,4 +59,7 @@ void mod_power_calc_psr_configs(struct psr_config *psr_config,
const struct dc_stream_state *stream);
  bool mod_power_only_edp(const struct dc_state *context,
const struct dc_stream_state *stream);
+bool psr_su_set_y_granularity(struct dc *dc, struct dc_link *link,
+ struct dc_stream_state *stream,
+ struct psr_config *config);
  #endif /* MODULES_POWER_POWER_HELPERS_H_ */




--
Hamza



Re: [PATCH] drm/gem: Check for valid formats

2023-01-05 Thread Simon Ser
To be honest, your suggestion to put the check inside framebuffer_check()
sounds like a better idea: we wouldn't even hit any driver-specific
code-path when the check fails. Daniel, do you think there'd be an issue
with this approach?


[PULL] drm-intel-fixes

2023-01-05 Thread Rodrigo Vivi
Hi Dave and Daniel,

Only GVT related fixes for this round.

I have another fix queued for i915_vma_unbind_async from Nirmoy that will
target stable 5.18, but I figured it out late so I didn't run CI on that yet.
So I'm holding this for now. Maybe and extra PR tomorrow or it will
wait for the next week.

Here goes drm-intel-fixes-2023-01-05:

Only gvt-fixes:
 - debugfs fixes (Zhenyu)
 - fix up for vgpu status (Zhi)
 - double free fix in split_2MB_gtt_entry (Zheng)

Thanks,
Rodrigo.

The following changes since commit 88603b6dc419445847923fcb7fe5080067a30f98:

  Linux 6.2-rc2 (2023-01-01 13:53:16 -0800)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2023-01-05

for you to fetch changes up to 87809d3196c2a7a015ab80ca1cb8c19b659bc5f6:

  Merge tag 'gvt-fixes-2023-01-05' of https://github.com/intel/gvt-linux into 
drm-intel-fixes (2023-01-05 08:03:38 -0500)


Only gvt-fixes:
 - debugfs fixes (Zhenyu)
 - fix up for vgpu status (Zhi)
 - double free fix in split_2MB_gtt_entry (Zheng)


Dan Carpenter (1):
  drm/i915: unpin on error in intel_vgpu_shadow_mm_pin()

Rodrigo Vivi (1):
  Merge tag 'gvt-fixes-2023-01-05' of https://github.com/intel/gvt-linux 
into drm-intel-fixes

Zheng Wang (1):
  drm/i915/gvt: fix double free bug in split_2MB_gtt_entry

Zhenyu Wang (2):
  drm/i915/gvt: fix gvt debugfs destroy
  drm/i915/gvt: fix vgpu debugfs clean in remove

Zhi Wang (1):
  drm/i915/gvt: use atomic operations to change the vGPU status

 drivers/gpu/drm/i915/gvt/debugfs.c   | 36 +++-
 drivers/gpu/drm/i915/gvt/dmabuf.c|  3 ++-
 drivers/gpu/drm/i915/gvt/gtt.c   | 21 +++--
 drivers/gpu/drm/i915/gvt/gvt.h   | 15 ++-
 drivers/gpu/drm/i915/gvt/interrupt.c |  2 +-
 drivers/gpu/drm/i915/gvt/kvmgt.c | 35 +--
 drivers/gpu/drm/i915/gvt/scheduler.c |  4 +++-
 drivers/gpu/drm/i915/gvt/vgpu.c  | 12 +---
 8 files changed, 80 insertions(+), 48 deletions(-)


Re: [RFC PATCH 04/20] drm/sched: Convert drm scheduler to use a work queue rather than kthread

2023-01-05 Thread Matthew Brost
On Mon, Jan 02, 2023 at 08:30:19AM +0100, Boris Brezillon wrote:
> On Fri, 30 Dec 2022 12:55:08 +0100
> Boris Brezillon  wrote:
> 
> > On Fri, 30 Dec 2022 11:20:42 +0100
> > Boris Brezillon  wrote:
> > 
> > > Hello Matthew,
> > > 
> > > On Thu, 22 Dec 2022 14:21:11 -0800
> > > Matthew Brost  wrote:
> > >   
> > > > In XE, the new Intel GPU driver, a choice has made to have a 1 to 1
> > > > mapping between a drm_gpu_scheduler and drm_sched_entity. At first this
> > > > seems a bit odd but let us explain the reasoning below.
> > > > 
> > > > 1. In XE the submission order from multiple drm_sched_entity is not
> > > > guaranteed to be the same completion even if targeting the same hardware
> > > > engine. This is because in XE we have a firmware scheduler, the GuC,
> > > > which allowed to reorder, timeslice, and preempt submissions. If a using
> > > > shared drm_gpu_scheduler across multiple drm_sched_entity, the TDR falls
> > > > apart as the TDR expects submission order == completion order. Using a
> > > > dedicated drm_gpu_scheduler per drm_sched_entity solve this problem.
> > > 
> > > Oh, that's interesting. I've been trying to solve the same sort of
> > > issues to support Arm's new Mali GPU which is relying on a FW-assisted
> > > scheduling scheme (you give the FW N streams to execute, and it does
> > > the scheduling between those N command streams, the kernel driver
> > > does timeslice scheduling to update the command streams passed to the
> > > FW). I must admit I gave up on using drm_sched at some point, mostly
> > > because the integration with drm_sched was painful, but also because I
> > > felt trying to bend drm_sched to make it interact with a
> > > timeslice-oriented scheduling model wasn't really future proof. Giving
> > > drm_sched_entity exlusive access to a drm_gpu_scheduler probably might
> > > help for a few things (didn't think it through yet), but I feel it's
> > > coming short on other aspects we have to deal with on Arm GPUs.  
> > 
> > Ok, so I just had a quick look at the Xe driver and how it
> > instantiates the drm_sched_entity and drm_gpu_scheduler, and I think I
> > have a better understanding of how you get away with using drm_sched
> > while still controlling how scheduling is really done. Here
> > drm_gpu_scheduler is just a dummy abstract that let's you use the
> > drm_sched job queuing/dep/tracking mechanism. The whole run-queue

You nailed it here, we use the DRM scheduler for queuing jobs,
dependency tracking and releasing jobs to be scheduled when dependencies
are met, and lastly a tracking mechanism of inflights jobs that need to
be cleaned up if an error occurs. It doesn't actually do any scheduling
aside from the most basic level of not overflowing the submission ring
buffer. In this sense, a 1 to 1 relationship between entity and
scheduler fits quite well.

FWIW this design was also ran by AMD quite a while ago (off the list)
and we didn't get any serious push back. Things can change however...

> > selection is dumb because there's only one entity ever bound to the
> > scheduler (the one that's part of the xe_guc_engine object which also
> > contains the drm_gpu_scheduler instance). I guess the main issue we'd
> > have on Arm is the fact that the stream doesn't necessarily get
> > scheduled when ->run_job() is called, it can be placed in the runnable
> > queue and be picked later by the kernel-side scheduler when a FW slot
> > gets released. That can probably be sorted out by manually disabling the
> > job timer and re-enabling it when the stream gets picked by the
> > scheduler. But my main concern remains, we're basically abusing
> > drm_sched here.
> > 

That's a matter of opinion, yes we are using it slightly differently
than anyone else but IMO the fact the DRM scheduler works for the Xe use
case with barely any changes is a testament to its design.

> > For the Arm driver, that means turning the following sequence
> > 
> > 1. wait for job deps
> > 2. queue job to ringbuf and push the stream to the runnable
> >queue (if it wasn't queued already). Wakeup the timeslice scheduler
> >to re-evaluate (if the stream is not on a FW slot already)
> > 3. stream gets picked by the timeslice scheduler and sent to the FW for
> >execution
> > 
> > into
> > 
> > 1. queue job to entity which takes care of waiting for job deps for
> >us
> > 2. schedule a drm_sched_main iteration
> > 3. the only available entity is picked, and the first job from this
> >entity is dequeued. ->run_job() is called: the job is queued to the
> >ringbuf and the stream is pushed to the runnable queue (if it wasn't
> >queued already). Wakeup the timeslice scheduler to re-evaluate (if
> >the stream is not on a FW slot already)
> > 4. stream gets picked by the timeslice scheduler and sent to the FW for
> >execution
> >

Yes, an extra step but you get to use all the nice DRM scheduler
functions for dependency tracking. Also in our case we really want a
single 

[PATCH 1/2] drm/debugfs: use octal permissions instead of symbolic permissions

2023-01-05 Thread Maíra Canal
Currently, debugfs functions are using symbolic macros as permission
bits, but checkpatch reinforces permission bits in the octal form, as
they are more readable and easier to understand [1].

Therefore, use octal permission bits in all debugfs functions.

[1] https://docs.kernel.org/dev-tools/checkpatch.html#permissions

Suggested-by: Jani Nikula 
Signed-off-by: Maíra Canal 
---
 drivers/gpu/drm/drm_debugfs.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index 5ea237839439..4f643a490dc3 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
@@ -207,7 +207,7 @@ void drm_debugfs_create_files(const struct drm_info_list 
*files, int count,
 
tmp->minor = minor;
tmp->dent = debugfs_create_file(files[i].name,
-   S_IFREG | S_IRUGO, root, tmp,
+   0444, root, tmp,
_debugfs_fops);
tmp->info_ent = [i];
 
@@ -246,7 +246,7 @@ int drm_debugfs_init(struct drm_minor *minor, int minor_id,
dev->driver->debugfs_init(minor);
 
list_for_each_entry_safe(entry, tmp, >debugfs_list, list) {
-   debugfs_create_file(entry->file.name, S_IFREG | S_IRUGO,
+   debugfs_create_file(entry->file.name, 0444,
minor->debugfs_root, entry, 
_debugfs_entry_fops);
list_del(>list);
}
@@ -263,7 +263,7 @@ void drm_debugfs_late_register(struct drm_device *dev)
return;
 
list_for_each_entry_safe(entry, tmp, >debugfs_list, list) {
-   debugfs_create_file(entry->file.name, S_IFREG | S_IRUGO,
+   debugfs_create_file(entry->file.name, 0444,
minor->debugfs_root, entry, 
_debugfs_entry_fops);
list_del(>list);
}
@@ -508,15 +508,15 @@ void drm_debugfs_connector_add(struct drm_connector 
*connector)
connector->debugfs_entry = root;
 
/* force */
-   debugfs_create_file("force", S_IRUGO | S_IWUSR, root, connector,
+   debugfs_create_file("force", 0644, root, connector,
_connector_fops);
 
/* edid */
-   debugfs_create_file("edid_override", S_IRUGO | S_IWUSR, root, connector,
+   debugfs_create_file("edid_override", 0644, root, connector,
_edid_fops);
 
/* vrr range */
-   debugfs_create_file("vrr_range", S_IRUGO, root, connector,
+   debugfs_create_file("vrr_range", 0444, root, connector,
_range_fops);
 
/* max bpc */
-- 
2.39.0



[PATCH 2/2] drm/debugfs: add descriptions to struct parameters

2023-01-05 Thread Maíra Canal
The structs drm_debugfs_info and drm_debugfs_entry don't have
descriptions for their parameters, which is causing the following warnings:

include/drm/drm_debugfs.h:93: warning: Function parameter or member
'name' not described in 'drm_debugfs_info'
include/drm/drm_debugfs.h:93: warning: Function parameter or member
'show' not described in 'drm_debugfs_info'
include/drm/drm_debugfs.h:93: warning: Function parameter or member
'driver_features' not described in 'drm_debugfs_info'
include/drm/drm_debugfs.h:93: warning: Function parameter or member
'data' not described in 'drm_debugfs_info'
include/drm/drm_debugfs.h:105: warning: Function parameter or member
'dev' not described in 'drm_debugfs_entry'
include/drm/drm_debugfs.h:105: warning: Function parameter or member
'file' not described in 'drm_debugfs_entry'
include/drm/drm_debugfs.h:105: warning: Function parameter or member
'list' not described in 'drm_debugfs_entry'

Therefore, fix the warnings by adding descriptions to all struct
parameters.

Reported-by: Stephen Rothwell 
Signed-off-by: Maíra Canal 
---
 include/drm/drm_debugfs.h | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/include/drm/drm_debugfs.h b/include/drm/drm_debugfs.h
index 53b7297260a5..7616f457ce70 100644
--- a/include/drm/drm_debugfs.h
+++ b/include/drm/drm_debugfs.h
@@ -86,9 +86,22 @@ struct drm_info_node {
  * core.
  */
 struct drm_debugfs_info {
+   /** @name: File name */
const char *name;
+
+   /**
+* @show:
+*
+* Show callback. _file->private will be set to the 
+* drm_debugfs_entry corresponding to the instance of this info
+* on a given  drm_device.
+*/
int (*show)(struct seq_file*, void*);
+
+   /** @driver_features: Required driver features for this entry. */
u32 driver_features;
+
+   /** @data: Driver-private data, should not be device-specific. */
void *data;
 };
 
@@ -99,8 +112,13 @@ struct drm_debugfs_info {
  * drm_debugfs_info on a  drm_device.
  */
 struct drm_debugfs_entry {
+   /** @dev:  drm_device for this node. */
struct drm_device *dev;
+
+   /** @file: Template for this node. */
struct drm_debugfs_info file;
+
+   /** @list: Linked list of all device nodes. */
struct list_head list;
 };
 
-- 
2.39.0



Re: [GIT PULL - v2] fbdev fixes for v6.2-rc3

2023-01-05 Thread pr-tracker-bot
The pull request you sent on Thu, 5 Jan 2023 12:11:54 +0100:

> http://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev.git 
> tags/fbdev-for-6.2-rc3

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

Thank you!

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


[PATCH] fbdev: Replace 0-length array with flexible array

2023-01-05 Thread Kees Cook
Zero-length arrays are deprecated[1]. Replace struct aperture's "ranges"
0-length array with a flexible array. (How is the size of this array
verified?) Detected with GCC 13, using -fstrict-flex-arrays=3:

samples/vfio-mdev/mdpy-fb.c: In function 'mdpy_fb_probe':
samples/vfio-mdev/mdpy-fb.c:169:32: warning: array subscript 0 is outside array 
bounds of 'struct aperture[0]' [-Warray-bounds=]
  169 | info->apertures->ranges[0].base = info->fix.smem_start;
  | ~~~^~~
In file included from samples/vfio-mdev/mdpy-fb.c:21:
include/linux/fb.h:510:19: note: while referencing 'ranges'
  510 | } ranges[0];
  |   ^~

[1] 
https://www.kernel.org/doc/html/latest/process/deprecated.html#zero-length-and-one-element-arrays

Cc: Helge Deller 
Cc: "Gustavo A. R. Silva" 
Cc: linux-fb...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Kees Cook 
---
 include/linux/fb.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/fb.h b/include/linux/fb.h
index 96b96323e9cb..bf59d6a3590f 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -507,7 +507,7 @@ struct fb_info {
struct aperture {
resource_size_t base;
resource_size_t size;
-   } ranges[0];
+   } ranges[];
} *apertures;
 
bool skip_vt_switch; /* no VT switch on suspend/resume required */
-- 
2.34.1



Re: [PATCH -next] drm/amd/display: Remove redundant assignment to variable dc

2023-01-05 Thread Harry Wentland
On 12/16/22 05:23, Yi Yang wrote:
> Smatch report warning as follows:
> 
> Line 53679: drivers/gpu/drm/amd/display/dc/core/dc_stream.c:402
> dc_stream_set_cursor_position() warn: variable dereferenced before
> check 'stream'
> 
> The value of 'dc' has been assigned after check whether 'stream' is
> NULL. Fix it by remove redundant assignment.
> 
> Signed-off-by: Yi Yang 

If this didn't blow up until now we might not even need
the NULL check below, but either way this is correct and

Reviewed-by: Harry Wentland 

Harry

> ---
>  drivers/gpu/drm/amd/display/dc/core/dc_stream.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_stream.c 
> b/drivers/gpu/drm/amd/display/dc/core/dc_stream.c
> index 20e534f73513..78d31bb875d1 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc_stream.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc_stream.c
> @@ -408,7 +408,7 @@ bool dc_stream_set_cursor_position(
>   struct dc_stream_state *stream,
>   const struct dc_cursor_position *position)
>  {
> - struct dc  *dc = stream->ctx->dc;
> + struct dc *dc;
>   bool reset_idle_optimizations = false;
>  
>   if (NULL == stream) {



Re: [PATCH] drm/gem: Check for valid formats

2023-01-05 Thread Maíra Canal




On 1/5/23 15:54, Simon Ser wrote:

On Thursday, January 5th, 2023 at 19:48, Maíra Canal  wrote:


On 1/5/23 15:36, Simon Ser wrote:


On Thursday, January 5th, 2023 at 19:30, Maíra Canal mca...@igalia.com wrote:


I think to really make sure we have consensus it'd be good to extend this
to a series which removes all the callers to drm_any_plane_has_format()
from the various drivers, and then unexports that helper. That way your
series here will have more eyes on it :-)


I took a look at the callers to drm_any_plane_has_format() and there are only
3 callers (amdgpu, i915 and vmwgfx). They all use drm_any_plane_has_format()
before calling drm_framebuffer_init(). So, I'm not sure I could remove
drm_any_plane_has_format() from those drivers. Maybe adding this same check
to drm_gem_fb_init() and refactor the drivers to make them use 
drm_gem_fb_init(),
but I guess this would be part of a different series.


Well vmwgfx still not yet using gem afaik, so that doesn't work.

But why can't we move the modifier check int drm_framebuffer_init()?
That's kinda where it probably should be anyway, there's nothing gem
bo specific in the code you're adding.


I'm not sure if this would correct the problem that I was trying to fix 
initially.
I was trying to make sure that the drivers pass on the
igt@kms_addfb_basic@addfb25-bad-modifier IGT test by making sure that the addfb
ioctl returns the error.

By moving the modifier check to the drm_framebuffer_init(), the test would still
fail.


Hm, why is that? The ADDFB2 IOCTL impl calls drm_framebuffer_init().



 From what I can see, ADDFB2 IOCTL calls drm_internal_framebuffer_create() [1],
then drm_internal_framebuffer_create() calls the fb_create hook [2]. I'm not 
sure
here ADDFB2 implicitly calls drm_framebuffer_init(), but I'm probably missing
something.


Right, but then all drivers will call drm_framebuffer_init() somewhere
in their fb_create hook. For instance amdgpu calls it in
amdgpu_display_gem_fb_verify_and_init().


I see. Thanks for explaining me the relation between the functions. I will send 
a v3
of this patch, introducing the check on drm_framebuffer_init().

Best Regards,
- Maíra Canal


Re: [PATCH] drm/gem: Check for valid formats

2023-01-05 Thread Simon Ser
On Thursday, January 5th, 2023 at 19:48, Maíra Canal  wrote:

> On 1/5/23 15:36, Simon Ser wrote:
> 
> > On Thursday, January 5th, 2023 at 19:30, Maíra Canal mca...@igalia.com 
> > wrote:
> > 
> > > > > > I think to really make sure we have consensus it'd be good to 
> > > > > > extend this
> > > > > > to a series which removes all the callers to 
> > > > > > drm_any_plane_has_format()
> > > > > > from the various drivers, and then unexports that helper. That way 
> > > > > > your
> > > > > > series here will have more eyes on it :-)
> > > > > 
> > > > > I took a look at the callers to drm_any_plane_has_format() and there 
> > > > > are only
> > > > > 3 callers (amdgpu, i915 and vmwgfx). They all use 
> > > > > drm_any_plane_has_format()
> > > > > before calling drm_framebuffer_init(). So, I'm not sure I could remove
> > > > > drm_any_plane_has_format() from those drivers. Maybe adding this same 
> > > > > check
> > > > > to drm_gem_fb_init() and refactor the drivers to make them use 
> > > > > drm_gem_fb_init(),
> > > > > but I guess this would be part of a different series.
> > > > 
> > > > Well vmwgfx still not yet using gem afaik, so that doesn't work.
> > > > 
> > > > But why can't we move the modifier check int drm_framebuffer_init()?
> > > > That's kinda where it probably should be anyway, there's nothing gem
> > > > bo specific in the code you're adding.
> > > 
> > > I'm not sure if this would correct the problem that I was trying to fix 
> > > initially.
> > > I was trying to make sure that the drivers pass on the
> > > igt@kms_addfb_basic@addfb25-bad-modifier IGT test by making sure that the 
> > > addfb
> > > ioctl returns the error.
> > > 
> > > By moving the modifier check to the drm_framebuffer_init(), the test 
> > > would still
> > > fail.
> > 
> > Hm, why is that? The ADDFB2 IOCTL impl calls drm_framebuffer_init().
> 
> 
> From what I can see, ADDFB2 IOCTL calls drm_internal_framebuffer_create() [1],
> then drm_internal_framebuffer_create() calls the fb_create hook [2]. I'm not 
> sure
> here ADDFB2 implicitly calls drm_framebuffer_init(), but I'm probably missing
> something.

Right, but then all drivers will call drm_framebuffer_init() somewhere
in their fb_create hook. For instance amdgpu calls it in
amdgpu_display_gem_fb_verify_and_init().


Re: [PATCH] drm/gem: Check for valid formats

2023-01-05 Thread Maíra Canal

On 1/5/23 15:36, Simon Ser wrote:

On Thursday, January 5th, 2023 at 19:30, Maíra Canal  wrote:


I think to really make sure we have consensus it'd be good to extend this
to a series which removes all the callers to drm_any_plane_has_format()
from the various drivers, and then unexports that helper. That way your
series here will have more eyes on it :-)


I took a look at the callers to drm_any_plane_has_format() and there are only
3 callers (amdgpu, i915 and vmwgfx). They all use drm_any_plane_has_format()
before calling drm_framebuffer_init(). So, I'm not sure I could remove
drm_any_plane_has_format() from those drivers. Maybe adding this same check
to drm_gem_fb_init() and refactor the drivers to make them use 
drm_gem_fb_init(),
but I guess this would be part of a different series.


Well vmwgfx still not yet using gem afaik, so that doesn't work.

But why can't we move the modifier check int drm_framebuffer_init()?
That's kinda where it probably should be anyway, there's nothing gem
bo specific in the code you're adding.



I'm not sure if this would correct the problem that I was trying to fix 
initially.
I was trying to make sure that the drivers pass on the
igt@kms_addfb_basic@addfb25-bad-modifier IGT test by making sure that the addfb
ioctl returns the error.

By moving the modifier check to the drm_framebuffer_init(), the test would still
fail.


Hm, why is that? The ADDFB2 IOCTL impl calls drm_framebuffer_init().


From what I can see, ADDFB2 IOCTL calls drm_internal_framebuffer_create() [1],
then drm_internal_framebuffer_create() calls the fb_create hook [2]. I'm not 
sure
here ADDFB2 implicitly calls drm_framebuffer_init(), but I'm probably missing
something.

Also, by looking at this file, I realize that maybe it would be better to add 
the
check on framebuffer_check(), but I don't know how does it sound to Daniel.

[1] 
https://cgit.freedesktop.org/drm/drm-misc/tree/drivers/gpu/drm/drm_framebuffer.c#n346
[2] 
https://cgit.freedesktop.org/drm/drm-misc/tree/drivers/gpu/drm/drm_framebuffer.c#n321

Best Regards,
- Maíra Canal


Re: [PATCH v4 3/7] accel/ivpu: Add GEM buffer object management

2023-01-05 Thread Andrew Davis

On 12/8/22 5:07 AM, Jacek Lawrynowicz wrote:

Adds four types of GEM-based BOs for the VPU:
   - shmem
   - userptr


Do you have some specific need for userptr that would not
be covered by prime import + heaps? I'm just trying to get
a feel for the typical use-cases for these.

Andrew


   - internal
   - prime

All types are implemented as struct ivpu_bo, based on
struct drm_gem_object. VPU address is allocated when buffer is created
except for imported prime buffers that allocate it in BO_INFO IOCTL due
to missing file_priv arg in gem_prime_import callback.
Internal buffers are pinned on creation, the rest of buffers types
can be pinned on demand (in SUBMIT IOCTL).
Buffer VPU address, allocated pages and mappings are relased when the
buffer is destroyed.
Eviction mechism is planned for future versions.

Add three new IOCTLs: BO_CREATE, BO_INFO, BO_USERPTR

Signed-off-by: Jacek Lawrynowicz 


Re: [PATCH] drm/vkms: introduce prepare_fb and cleanup_fb functions

2023-01-05 Thread Melissa Wen
On 01/05, Maíra Canal wrote:
> With commit 359c6649cd9a ("drm/gem: Implement shadow-plane {begin,
> end}_fb_access with vmap"), the behavior of the shadow-plane helpers
> changed and the vunmap is now performed at the end of
> the current pageflip, instead of the end of the following pageflip.
> 
> By performing the vunmap at the end of the current pageflip, invalid
> memory is accessed by the vkms during the plane composition, as the data
> is being unmapped before being used.

Hi Maíra,

Thanks for investigating this issue. Can you add in the commit message
the kernel Oops caused by this change?

Besides that, I wonder if the right thing would be to restore the
previous behavior of vunmap in shadow-plane helpers, instead of
reintroduce driver-specific hooks for vmap/vunmap correctly to vkms.

Maybe Thomas has some inputs on this shadow-plane changing to help us on
figuring out the proper fix (?)

Best Regards,

Melissa

> 
> Therefore, introduce again prepare_fb and cleanup_fb functions to the
> vkms, which were previously removed on commit b43e2ec03b0d ("drm/vkms:
> Let shadow-plane helpers prepare the plane's FB").
> 
> Fixes: 359c6649cd9a ("drm/gem: Implement shadow-plane {begin, end}_fb_access 
> with vmap")
> Signed-off-by: Maíra Canal 
> ---
>  drivers/gpu/drm/vkms/vkms_plane.c | 36 ++-
>  1 file changed, 35 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/vkms/vkms_plane.c 
> b/drivers/gpu/drm/vkms/vkms_plane.c
> index c3a845220e10..b3f8a115cc23 100644
> --- a/drivers/gpu/drm/vkms/vkms_plane.c
> +++ b/drivers/gpu/drm/vkms/vkms_plane.c
> @@ -160,10 +160,44 @@ static int vkms_plane_atomic_check(struct drm_plane 
> *plane,
>   return 0;
>  }
> 
> +static int vkms_prepare_fb(struct drm_plane *plane,
> +struct drm_plane_state *state)
> +{
> + struct drm_shadow_plane_state *shadow_plane_state;
> + struct drm_framebuffer *fb = state->fb;
> + int ret;
> +
> + if (!fb)
> + return 0;
> +
> + shadow_plane_state = to_drm_shadow_plane_state(state);
> +
> + ret = drm_gem_plane_helper_prepare_fb(plane, state);
> + if (ret)
> + return ret;
> +
> + return drm_gem_fb_vmap(fb, shadow_plane_state->map, 
> shadow_plane_state->data);
> +}
> +
> +static void vkms_cleanup_fb(struct drm_plane *plane,
> + struct drm_plane_state *state)
> +{
> + struct drm_shadow_plane_state *shadow_plane_state;
> + struct drm_framebuffer *fb = state->fb;
> +
> + if (!fb)
> + return;
> +
> + shadow_plane_state = to_drm_shadow_plane_state(state);
> +
> + drm_gem_fb_vunmap(fb, shadow_plane_state->map);
> +}
> +
>  static const struct drm_plane_helper_funcs vkms_primary_helper_funcs = {
>   .atomic_update  = vkms_plane_atomic_update,
>   .atomic_check   = vkms_plane_atomic_check,
> - DRM_GEM_SHADOW_PLANE_HELPER_FUNCS,
> + .prepare_fb = vkms_prepare_fb,
> + .cleanup_fb = vkms_cleanup_fb,
>  };
> 
>  struct vkms_plane *vkms_plane_init(struct vkms_device *vkmsdev,
> --
> 2.39.0
> 


signature.asc
Description: PGP signature


Re: [PATCH] drm/gem: Check for valid formats

2023-01-05 Thread Simon Ser
On Thursday, January 5th, 2023 at 19:30, Maíra Canal  wrote:

> > > > I think to really make sure we have consensus it'd be good to extend 
> > > > this
> > > > to a series which removes all the callers to drm_any_plane_has_format()
> > > > from the various drivers, and then unexports that helper. That way your
> > > > series here will have more eyes on it :-)
> > > 
> > > I took a look at the callers to drm_any_plane_has_format() and there are 
> > > only
> > > 3 callers (amdgpu, i915 and vmwgfx). They all use 
> > > drm_any_plane_has_format()
> > > before calling drm_framebuffer_init(). So, I'm not sure I could remove
> > > drm_any_plane_has_format() from those drivers. Maybe adding this same 
> > > check
> > > to drm_gem_fb_init() and refactor the drivers to make them use 
> > > drm_gem_fb_init(),
> > > but I guess this would be part of a different series.
> > 
> > Well vmwgfx still not yet using gem afaik, so that doesn't work.
> > 
> > But why can't we move the modifier check int drm_framebuffer_init()?
> > That's kinda where it probably should be anyway, there's nothing gem
> > bo specific in the code you're adding.
> 
> 
> I'm not sure if this would correct the problem that I was trying to fix 
> initially.
> I was trying to make sure that the drivers pass on the
> igt@kms_addfb_basic@addfb25-bad-modifier IGT test by making sure that the 
> addfb
> ioctl returns the error.
> 
> By moving the modifier check to the drm_framebuffer_init(), the test would 
> still
> fail.

Hm, why is that? The ADDFB2 IOCTL impl calls drm_framebuffer_init().


Re: [PATCH] drm/gem: Check for valid formats

2023-01-05 Thread Maíra Canal

On 1/5/23 15:22, Daniel Vetter wrote:

On Thu, 5 Jan 2023 at 18:48, Maíra Canal  wrote:


On 1/5/23 12:26, Daniel Vetter wrote:

On Tue, Jan 03, 2023 at 09:53:23AM -0300, Maíra Canal wrote:

Currently, drm_gem_fb_create() doesn't check if the pixel format is
supported, which can lead to the acceptance of invalid pixel formats
e.g. the acceptance of invalid modifiers. Therefore, add a check for
valid formats on drm_gem_fb_create().

Moreover, note that this check is only valid for atomic drivers,
because, for non-atomic drivers, checking drm_any_plane_has_format() is
not possible since the format list for the primary plane is fake, and
we'd therefor reject valid formats.

Suggested-by: Thomas Zimmermann 
Signed-off-by: Maíra Canal 


Acked-by: Daniel Vetter 

I think to really make sure we have consensus it'd be good to extend this
to a series which removes all the callers to drm_any_plane_has_format()
from the various drivers, and then unexports that helper. That way your
series here will have more eyes on it :-)


I took a look at the callers to drm_any_plane_has_format() and there are only
3 callers (amdgpu, i915 and vmwgfx). They all use drm_any_plane_has_format()
before calling drm_framebuffer_init(). So, I'm not sure I could remove
drm_any_plane_has_format() from those drivers. Maybe adding this same check
to drm_gem_fb_init() and refactor the drivers to make them use 
drm_gem_fb_init(),
but I guess this would be part of a different series.


Well vmwgfx still not yet using gem afaik, so that doesn't work.

But why can't we move the modifier check int drm_framebuffer_init()?
That's kinda where it probably should be anyway, there's nothing gem
bo specific in the code you're adding.


I'm not sure if this would correct the problem that I was trying to fix 
initially.
I was trying to make sure that the drivers pass on the
igt@kms_addfb_basic@addfb25-bad-modifier IGT test by making sure that the addfb
ioctl returns the error.

By moving the modifier check to the drm_framebuffer_init(), the test would still
fail.

Best Regards,
- Maíra Canal


-Daniel


Re: [PATCH v2] drm/amd/display: fix PSR-SU/DSC interoperability support

2023-01-05 Thread Harry Wentland



On 1/5/23 12:38, Hamza Mahfooz wrote:
> Currently, there are issues with enabling PSR-SU + DSC. This stems from
> the fact that DSC imposes a slice height on transmitted video data and
> we are not conforming to that slice height in PSR-SU regions. So, pass
> slice_height into su_y_granularity to feed the DSC slice height into
> PSR-SU code.
> 
> Signed-off-by: Hamza Mahfooz 
> ---
> v2: move code to modules/power.
> ---
>  .../drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c |  3 ++
>  .../amd/display/modules/power/power_helpers.c | 35 +++
>  .../amd/display/modules/power/power_helpers.h |  3 ++
>  3 files changed, 41 insertions(+)
> 
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c
> index 26291db0a3cf..872d06fe1436 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c
> @@ -122,6 +122,9 @@ bool amdgpu_dm_link_setup_psr(struct dc_stream_state 
> *stream)
>   psr_config.allow_multi_disp_optimizations =
>   (amdgpu_dc_feature_mask & DC_PSR_ALLOW_MULTI_DISP_OPT);
>  
> + if (!psr_su_set_y_granularity(dc, link, stream, _config))
> + return false;
> +
>   ret = dc_link_setup_psr(link, stream, _config, 
> _context);
>  
>   }
> diff --git a/drivers/gpu/drm/amd/display/modules/power/power_helpers.c 
> b/drivers/gpu/drm/amd/display/modules/power/power_helpers.c
> index 9b5d9b2c9a6a..4d27ad9f7370 100644
> --- a/drivers/gpu/drm/amd/display/modules/power/power_helpers.c
> +++ b/drivers/gpu/drm/amd/display/modules/power/power_helpers.c
> @@ -916,3 +916,38 @@ bool mod_power_only_edp(const struct dc_state *context, 
> const struct dc_stream_s
>  {
>   return context && context->stream_count == 1 && 
> dc_is_embedded_signal(stream->signal);
>  }
> +
> +bool psr_su_set_y_granularity(struct dc *dc, struct dc_link *link,
> +   struct dc_stream_state *stream,
> +   struct psr_config *config)
> +{
> + uint16_t pic_height;
> + uint8_t slice_height;
> +
> + if (!dc->caps.edp_dsc_support ||
> + link->panel_config.dsc.disable_dsc_edp ||
> + 
> !link->dpcd_caps.dsc_caps.dsc_basic_caps.fields.dsc_support.DSC_SUPPORT ||
> + !stream->timing.dsc_cfg.num_slices_v)

I'm not sure this condition is correct. We can have DSC but not eDP DSC
support.

> + return true;
> +
> + pic_height = stream->timing.v_addressable +
> + stream->timing.v_border_top + stream->timing.v_border_bottom;
> + slice_height = pic_height / stream->timing.dsc_cfg.num_slices_v;
> +
> + if (slice_height) {
> + if (config->su_y_granularity &&
> + (slice_height % config->su_y_granularity)) {
> + WARN(1,

We don't use WARN in display/dc or display/modules. DC_LOG_WARNING
might be better, or log it in the caller.

Harry

> +  "%s: dsc: %d, slice_height: %d, num_slices_v: 
> %d\n",
> +  __func__,
> +  
> stream->sink->dsc_caps.dsc_dec_caps.is_dsc_supported,
> +  slice_height,
> +  stream->timing.dsc_cfg.num_slices_v);
> + return false;
> + }
> +
> + config->su_y_granularity = slice_height;
> + }
> +
> + return true;
> +}
> diff --git a/drivers/gpu/drm/amd/display/modules/power/power_helpers.h 
> b/drivers/gpu/drm/amd/display/modules/power/power_helpers.h
> index 316452e9dbc9..bb16b37b83da 100644
> --- a/drivers/gpu/drm/amd/display/modules/power/power_helpers.h
> +++ b/drivers/gpu/drm/amd/display/modules/power/power_helpers.h
> @@ -59,4 +59,7 @@ void mod_power_calc_psr_configs(struct psr_config 
> *psr_config,
>   const struct dc_stream_state *stream);
>  bool mod_power_only_edp(const struct dc_state *context,
>   const struct dc_stream_state *stream);
> +bool psr_su_set_y_granularity(struct dc *dc, struct dc_link *link,
> +   struct dc_stream_state *stream,
> +   struct psr_config *config);
>  #endif /* MODULES_POWER_POWER_HELPERS_H_ */



Re: [PATCH] drm/gem: Check for valid formats

2023-01-05 Thread Daniel Vetter
On Thu, 5 Jan 2023 at 18:48, Maíra Canal  wrote:
>
> On 1/5/23 12:26, Daniel Vetter wrote:
> > On Tue, Jan 03, 2023 at 09:53:23AM -0300, Maíra Canal wrote:
> >> Currently, drm_gem_fb_create() doesn't check if the pixel format is
> >> supported, which can lead to the acceptance of invalid pixel formats
> >> e.g. the acceptance of invalid modifiers. Therefore, add a check for
> >> valid formats on drm_gem_fb_create().
> >>
> >> Moreover, note that this check is only valid for atomic drivers,
> >> because, for non-atomic drivers, checking drm_any_plane_has_format() is
> >> not possible since the format list for the primary plane is fake, and
> >> we'd therefor reject valid formats.
> >>
> >> Suggested-by: Thomas Zimmermann 
> >> Signed-off-by: Maíra Canal 
> >
> > Acked-by: Daniel Vetter 
> >
> > I think to really make sure we have consensus it'd be good to extend this
> > to a series which removes all the callers to drm_any_plane_has_format()
> > from the various drivers, and then unexports that helper. That way your
> > series here will have more eyes on it :-)
>
> I took a look at the callers to drm_any_plane_has_format() and there are only
> 3 callers (amdgpu, i915 and vmwgfx). They all use drm_any_plane_has_format()
> before calling drm_framebuffer_init(). So, I'm not sure I could remove
> drm_any_plane_has_format() from those drivers. Maybe adding this same check
> to drm_gem_fb_init() and refactor the drivers to make them use 
> drm_gem_fb_init(),
> but I guess this would be part of a different series.

Well vmwgfx still not yet using gem afaik, so that doesn't work.

But why can't we move the modifier check int drm_framebuffer_init()?
That's kinda where it probably should be anyway, there's nothing gem
bo specific in the code you're adding.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


Re: [PATCH] drm/gem: Check for valid formats

2023-01-05 Thread Maíra Canal

On 1/5/23 12:26, Daniel Vetter wrote:

On Tue, Jan 03, 2023 at 09:53:23AM -0300, Maíra Canal wrote:

Currently, drm_gem_fb_create() doesn't check if the pixel format is
supported, which can lead to the acceptance of invalid pixel formats
e.g. the acceptance of invalid modifiers. Therefore, add a check for
valid formats on drm_gem_fb_create().

Moreover, note that this check is only valid for atomic drivers,
because, for non-atomic drivers, checking drm_any_plane_has_format() is
not possible since the format list for the primary plane is fake, and
we'd therefor reject valid formats.

Suggested-by: Thomas Zimmermann 
Signed-off-by: Maíra Canal 


Acked-by: Daniel Vetter 

I think to really make sure we have consensus it'd be good to extend this
to a series which removes all the callers to drm_any_plane_has_format()
from the various drivers, and then unexports that helper. That way your
series here will have more eyes on it :-)


I took a look at the callers to drm_any_plane_has_format() and there are only
3 callers (amdgpu, i915 and vmwgfx). They all use drm_any_plane_has_format()
before calling drm_framebuffer_init(). So, I'm not sure I could remove
drm_any_plane_has_format() from those drivers. Maybe adding this same check
to drm_gem_fb_init() and refactor the drivers to make them use 
drm_gem_fb_init(),
but I guess this would be part of a different series.

Best Regards,
- Maíra Canal


-Daniel



Re: [PATCH v4 1/7] accel/ivpu: Introduce a new DRM driver for Intel VPU

2023-01-05 Thread Oded Gabbay
On Thu, Jan 5, 2023 at 6:25 PM Jeffrey Hugo  wrote:
>
> On 1/5/2023 5:57 AM, Daniel Vetter wrote:
> > On Thu, Dec 08, 2022 at 12:07:27PM +0100, Jacek Lawrynowicz wrote:
> >> +static const struct drm_driver driver = {
> >> +.driver_features = DRIVER_GEM | DRIVER_COMPUTE_ACCEL,
> >
> > So I was wondering whether this is a bright idea, and whether we shouldn't
> > just go ahead and infuse more meaning into accel vs render nodes.
> >
> > The uapi relevant part of render nodes is that they're multi-user safe, at
> > least as much as feasible. Every new open() gives you a new private
> > accelerator. This also has implications on how userspace drivers iterate
> > them, they just open them all in turn and check whether it's the right
> > one - because userspace apis allow applications to enumerate them all.
> > Which also means that any devicie initialization at open() time is a
> > really bad idea.
> >
> > A lot of the compute accelerators otoh (well habanalabs) are single user,
> > init can be done at open() time because you only open this when you
> > actually know you're going to use it.
> >
> > So given this, shouldn't multi-user inference engines be more like render
> > drivers, and less like accel? So DRIVER_RENDER, but still under
> > drivers/accel.
> >
> > This way that entire separate /dev node would actually become meaningful
> > beyond just the basic bikeshed:
> > - render nodes are multi user, safe to iterate and open() just for
> >iteration
> > - accel nodes are single user, you really should not ever open them unless
> >you want to use them
> >
> > Of course would need a doc patch :-)
> >
> > Thoughts?
> > -Daniel
>
> Hmm.
>
> I admit, I thought DRIVER_ACCEL was the same as DRIVER_RENDER, except
> that DRIVER_ACCEL dropped the "legacy" dual node setup and also avoided
> "legacy" userspace.
>
> qaic is multi-user.  I thought habana was the same, at-least for
> inference.  Oded, am I wrong?
Habana's devices support a single user at a time acquiring the device
and working on it.
Both for training and inference.
>
> So, if DRIVER_ACCEL is for single-user (training?), and multi-user ends
> up in DRIVER_RENDER, that would seem to mean qaic ends up using
> DRIVER_RENDER and not DRIVER_ACCEL.  Then qaic ends up over under
> /dev/dri with both a card node (never used) and a render node.  That
> would seem to mean that the "legacy" userspace would open qaic nodes by
> default - something I understood Oded was trying to avoid.
>
> If there really a usecase for DRIVER_ACCEL to support single-user?  I
> wonder why we can't default to multi-user, and if a particular
> user/driver has a single-user usecase, it enforces that in a driver
> specific manner?
>
> -Jeff

Honestly, Daniel, I don't like this suggestion. I don't understand why
you make a connection between render/accel to single/multi user.

As Jeff has said, one of the goals was to expose accelerator devices
to userspace with new device char nodes so we won't be bothered by
legacy userspace graphics software. This is something we all agreed on
and I don't see why we should change it now, even if you think it's
bike-shedding (which I disagree with).

But in any case, creating a new device char nodes had nothing to do
with whether the device supports single or multi user. I can
definitely see in the future training devices that support multiple
users.

The common drm/accel ioctls should of course not be limited to a
single user, and I agree with Jeff here, if a specific driver has such
a limitation (e.g. Habana), then that driver should handle it on its
own.
Maybe if there will be multiple drivers with such a limitation, we can
make that "handling" to be common code.

Bottom line, I prefer we keep things as we all agreed upon in LPC.

Oded


[PATCH v2] drm/amd/display: fix PSR-SU/DSC interoperability support

2023-01-05 Thread Hamza Mahfooz
Currently, there are issues with enabling PSR-SU + DSC. This stems from
the fact that DSC imposes a slice height on transmitted video data and
we are not conforming to that slice height in PSR-SU regions. So, pass
slice_height into su_y_granularity to feed the DSC slice height into
PSR-SU code.

Signed-off-by: Hamza Mahfooz 
---
v2: move code to modules/power.
---
 .../drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c |  3 ++
 .../amd/display/modules/power/power_helpers.c | 35 +++
 .../amd/display/modules/power/power_helpers.h |  3 ++
 3 files changed, 41 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c
index 26291db0a3cf..872d06fe1436 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c
@@ -122,6 +122,9 @@ bool amdgpu_dm_link_setup_psr(struct dc_stream_state 
*stream)
psr_config.allow_multi_disp_optimizations =
(amdgpu_dc_feature_mask & DC_PSR_ALLOW_MULTI_DISP_OPT);
 
+   if (!psr_su_set_y_granularity(dc, link, stream, _config))
+   return false;
+
ret = dc_link_setup_psr(link, stream, _config, 
_context);
 
}
diff --git a/drivers/gpu/drm/amd/display/modules/power/power_helpers.c 
b/drivers/gpu/drm/amd/display/modules/power/power_helpers.c
index 9b5d9b2c9a6a..4d27ad9f7370 100644
--- a/drivers/gpu/drm/amd/display/modules/power/power_helpers.c
+++ b/drivers/gpu/drm/amd/display/modules/power/power_helpers.c
@@ -916,3 +916,38 @@ bool mod_power_only_edp(const struct dc_state *context, 
const struct dc_stream_s
 {
return context && context->stream_count == 1 && 
dc_is_embedded_signal(stream->signal);
 }
+
+bool psr_su_set_y_granularity(struct dc *dc, struct dc_link *link,
+ struct dc_stream_state *stream,
+ struct psr_config *config)
+{
+   uint16_t pic_height;
+   uint8_t slice_height;
+
+   if (!dc->caps.edp_dsc_support ||
+   link->panel_config.dsc.disable_dsc_edp ||
+   
!link->dpcd_caps.dsc_caps.dsc_basic_caps.fields.dsc_support.DSC_SUPPORT ||
+   !stream->timing.dsc_cfg.num_slices_v)
+   return true;
+
+   pic_height = stream->timing.v_addressable +
+   stream->timing.v_border_top + stream->timing.v_border_bottom;
+   slice_height = pic_height / stream->timing.dsc_cfg.num_slices_v;
+
+   if (slice_height) {
+   if (config->su_y_granularity &&
+   (slice_height % config->su_y_granularity)) {
+   WARN(1,
+"%s: dsc: %d, slice_height: %d, num_slices_v: 
%d\n",
+__func__,
+
stream->sink->dsc_caps.dsc_dec_caps.is_dsc_supported,
+slice_height,
+stream->timing.dsc_cfg.num_slices_v);
+   return false;
+   }
+
+   config->su_y_granularity = slice_height;
+   }
+
+   return true;
+}
diff --git a/drivers/gpu/drm/amd/display/modules/power/power_helpers.h 
b/drivers/gpu/drm/amd/display/modules/power/power_helpers.h
index 316452e9dbc9..bb16b37b83da 100644
--- a/drivers/gpu/drm/amd/display/modules/power/power_helpers.h
+++ b/drivers/gpu/drm/amd/display/modules/power/power_helpers.h
@@ -59,4 +59,7 @@ void mod_power_calc_psr_configs(struct psr_config *psr_config,
const struct dc_stream_state *stream);
 bool mod_power_only_edp(const struct dc_state *context,
const struct dc_stream_state *stream);
+bool psr_su_set_y_granularity(struct dc *dc, struct dc_link *link,
+ struct dc_stream_state *stream,
+ struct psr_config *config);
 #endif /* MODULES_POWER_POWER_HELPERS_H_ */
-- 
2.38.1



Re: [PATCH v7 00/45] Recover from failure to probe GPU

2023-01-05 Thread Alex Deucher
On Thu, Jan 5, 2023 at 12:02 PM Mario Limonciello
 wrote:
>
> One of the first thing that KMS drivers do during initialization is
> destroy the system firmware framebuffer by means of
> `drm_aperture_remove_conflicting_pci_framebuffers`
>
> This means that if for any reason the GPU failed to probe the user
> will be stuck with at best a screen frozen at the last thing that
> was shown before the KMS driver continued it's probe.
>
> The problem is most pronounced when new GPU support is introduced
> because users will need to have a recent linux-firmware snapshot
> on their system when they boot a kernel with matching support.
>
> However the problem is further exaggerated in the case of amdgpu because
> it has migrated to "IP discovery" where amdgpu will attempt to load
> on "ALL" AMD GPUs even if the driver is missing support for IP blocks
> contained in that GPU.
>
> IP discovery requires some probing and isn't run until after the
> framebuffer has been destroyed.
>
> This means a situation can occur where a user purchases a new GPU not
> yet supported by a distribution and when booting the installer it will
> "freeze" even if the distribution doesn't have the matching kernel support
> for those IP blocks.
>
> The perfect example of this is Ubuntu 22.10 and the new dGPUs just
> launched by AMD.  The installation media ships with kernel 5.19 (which
> has IP discovery) but the amdgpu support for those IP blocks landed in
> kernel 6.0. The matching linux-firmware was released after 22.10's launch.
> The screen will freeze without nomodeset. Even if a user manages to install
> and then upgrades to kernel 6.0 after install they'll still have the
> problem of missing firmware, and the same experience.
>
> This is quite jarring for users, particularly if they don't know
> that they have to use "nomodeset" to install.
>
> To help the situation make changes to GPU discovery:
> 1) Delay releasing the firmware framebuffer until after early_init
> completed.  This will help the situation of an older kernel that doesn't
> yet support the IP blocks probing a new GPU. IP discovery will have failed.
> 2) Request loading all PSP, VCN, SDMA, SMU, DMCUB, MES and GC microcode
> into memory during early_init. This will help the situation of new enough
> kernel for the IP discovery phase to otherwise pass but missing microcode
> from linux-firmware.git.

Series is:
Reviewed-by: Alex Deucher 

>
> v6->v7:
>  * Pick up tags
>  * Fix PSP TAv1 handling to match previous behavior (securedisplay_context
>only is set on PSPv10 and PSPv12/Renoir)
> v5->v6:
>  * Fix arguments for amdgpu_ucode_release to allow clearing pointer
>  * Fix whitespace mistake in VCN
>  * Pick up tags
> v4->v5:
>  * Rename amdgpu_ucode_load to amdgpu_ucode_request
>  * Add and utilize amdgpu_ucode_release throughout existing patches
>  * Update all amdgpu code to stop using request_firmware and
>release_firmware for microcode
>  * Drop export of amdgpu_ucode_validate outside of amdgpu_ucode.c
>  * Pick up relevant tags for some patches
> v3->v4:
>  * Rework to delay framebuffer release until early_init is done
>  * Make IP load microcode during early init phase
>  * Add SMU and DMCUB checks for early_init loading
>  * Add some new helper code for wrapping request_firmware calls (needed for
>early_init to return something besides -ENOENT)
> v2->v3:
>  * Pick up tags for patches 1-10
>  * Rework patch 11 to not validate during discovery
>  * Fix bugs with GFX9 due to gfx.num_gfx_rings not being set during
>discovery
>  * Fix naming scheme for SDMA on dGPUs
> v1->v2:
>  * Take the suggestion from v1 thread to delay the framebuffer release
>until ip discovery is done. This patch is CC to stable to that older
>stable kernels with IP discovery won't try to probe unknown IP.
>  * Drop changes to drm aperature.
>  * Fetch SDMA, VCN, MES, GC and PSP microcode during IP discovery.
>
> Mario Limonciello (27):
>   drm/amd: Delay removal of the firmware framebuffer
>   drm/amd: Add a legacy mapping to "amdgpu_ucode_ip_version_decode"
>   drm/amd: Convert SMUv11 microcode to use
> `amdgpu_ucode_ip_version_decode`
>   drm/amd: Convert SMUv13 microcode to use
> `amdgpu_ucode_ip_version_decode`
>   drm/amd: Add a new helper for loading/validating microcode
>   drm/amd: Use `amdgpu_ucode_request` helper for SDMA
>   drm/amd: Convert SDMA to use `amdgpu_ucode_ip_version_decode`
>   drm/amd: Make SDMA firmware load failures less noisy.
>   drm/amd: Use `amdgpu_ucode_*` helpers for VCN
>   drm/amd: Load VCN microcode during early_init
>   drm/amd: Load MES microcode during early_init
>   drm/amd: Use `amdgpu_ucode_*` helpers for MES
>   drm/amd: Remove superfluous assignment for `adev->mes.adev`
>   drm/amd: Use `amdgpu_ucode_*` helpers for GFX9
>   drm/amd: Load GFX9 microcode during early_init
>   drm/amd: Use `amdgpu_ucode_*` helpers for GFX10
>   drm/amd: Load GFX10 microcode during early_init
>   drm/amd: Use `amdgpu_ucode_*` helpers for 

Re: [PATCH v6 42/45] drm/amd: Use `amdgpu_ucode_*` helpers for DMCU

2023-01-05 Thread Harry Wentland



On 1/4/23 22:43, Mario Limonciello wrote:
> The `amdgpu_ucode_request` helper will ensure that the return code for
> missing firmware is -ENODEV so that early_init can fail.
> 
> The `amdgpu_ucode_release` helper is for symmetry on unloading.
> 
> Reviewed-by: Alex Deucher 
> Signed-off-by: Mario Limonciello 

Reviewed-by: Harry Wentland 

Harry

> ---
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 11 ++-
>  1 file changed, 2 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 61c192ead62f..79c4652e8e40 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -1881,20 +1881,13 @@ static int load_dmcu_fw(struct amdgpu_device *adev)
>   return 0;
>   }
>  
> - r = request_firmware_direct(>dm.fw_dmcu, fw_name_dmcu, adev->dev);
> - if (r == -ENOENT) {
> + r = amdgpu_ucode_request(adev, >dm.fw_dmcu, fw_name_dmcu);
> + if (r == -ENODEV) {
>   /* DMCU firmware is not necessary, so don't raise a fuss if 
> it's missing */
>   DRM_DEBUG_KMS("dm: DMCU firmware not found\n");
>   adev->dm.fw_dmcu = NULL;
>   return 0;
>   }
> - if (r) {
> - dev_err(adev->dev, "amdgpu_dm: Can't load firmware \"%s\"\n",
> - fw_name_dmcu);
> - return r;
> - }
> -
> - r = amdgpu_ucode_validate(adev->dm.fw_dmcu);
>   if (r) {
>   dev_err(adev->dev, "amdgpu_dm: Can't validate firmware 
> \"%s\"\n",
>   fw_name_dmcu);



Re: [PATCH v6 25/45] drm/amd: Use `amdgpu_ucode_release` helper for DMUB

2023-01-05 Thread Harry Wentland
On 1/4/23 22:42, Mario Limonciello wrote:
> The `amdgpu_ucode_release` helper is for symmetry on unloading.
> 
> Reviewed-by: Alex Deucher 
> Signed-off-by: Mario Limonciello 

Reviewed-by: Harry Wentland 

Harry

> ---
> v5->v6:
>  * Adjust for amdgpu_ucode_release argument change
> ---
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 10 +++---
>  1 file changed, 3 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index c8c5d37c8b3a..61c192ead62f 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -1898,8 +1898,7 @@ static int load_dmcu_fw(struct amdgpu_device *adev)
>   if (r) {
>   dev_err(adev->dev, "amdgpu_dm: Can't validate firmware 
> \"%s\"\n",
>   fw_name_dmcu);
> - release_firmware(adev->dm.fw_dmcu);
> - adev->dm.fw_dmcu = NULL;
> + amdgpu_ucode_release(>dm.fw_dmcu);
>   return r;
>   }
>  
> @@ -2113,11 +2112,8 @@ static int dm_sw_fini(void *handle)
>   adev->dm.dmub_srv = NULL;
>   }
>  
> - release_firmware(adev->dm.dmub_fw);
> - adev->dm.dmub_fw = NULL;
> -
> - release_firmware(adev->dm.fw_dmcu);
> - adev->dm.fw_dmcu = NULL;
> + amdgpu_ucode_release(>dm.dmub_fw);
> + amdgpu_ucode_release(>dm.fw_dmcu);
>  
>   return 0;
>  }



[PATCH v7 37/45] drm/amd: Use `amdgpu_ucode_*` helpers for SDMA on CIK

2023-01-05 Thread Mario Limonciello
The `amdgpu_ucode_request` helper will ensure that the return code for
missing firmware is -ENODEV so that early_init can fail.

The `amdgpu_ucode_release` helper is for symmetry on unloading.

Reviewed-by: Alex Deucher 
Reviewed-by: Lijo Lazar 
Signed-off-by: Mario Limonciello 
---
v5->v6:
 * Adjust for amdgpu_ucode_release argument change
---
 drivers/gpu/drm/amd/amdgpu/cik_sdma.c | 16 ++--
 1 file changed, 6 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/cik_sdma.c 
b/drivers/gpu/drm/amd/amdgpu/cik_sdma.c
index cbca9866645c..67d16236b216 100644
--- a/drivers/gpu/drm/amd/amdgpu/cik_sdma.c
+++ b/drivers/gpu/drm/amd/amdgpu/cik_sdma.c
@@ -73,10 +73,9 @@ u32 amdgpu_cik_gpu_check_soft_reset(struct amdgpu_device 
*adev);
 static void cik_sdma_free_microcode(struct amdgpu_device *adev)
 {
int i;
-   for (i = 0; i < adev->sdma.num_instances; i++) {
-   release_firmware(adev->sdma.instance[i].fw);
-   adev->sdma.instance[i].fw = NULL;
-   }
+
+   for (i = 0; i < adev->sdma.num_instances; i++)
+   amdgpu_ucode_release(>sdma.instance[i].fw);
 }
 
 /*
@@ -137,18 +136,15 @@ static int cik_sdma_init_microcode(struct amdgpu_device 
*adev)
snprintf(fw_name, sizeof(fw_name), 
"amdgpu/%s_sdma.bin", chip_name);
else
snprintf(fw_name, sizeof(fw_name), 
"amdgpu/%s_sdma1.bin", chip_name);
-   err = request_firmware(>sdma.instance[i].fw, fw_name, 
adev->dev);
+   err = amdgpu_ucode_request(adev, >sdma.instance[i].fw, 
fw_name);
if (err)
goto out;
-   err = amdgpu_ucode_validate(adev->sdma.instance[i].fw);
}
 out:
if (err) {
pr_err("cik_sdma: Failed to load firmware \"%s\"\n", fw_name);
-   for (i = 0; i < adev->sdma.num_instances; i++) {
-   release_firmware(adev->sdma.instance[i].fw);
-   adev->sdma.instance[i].fw = NULL;
-   }
+   for (i = 0; i < adev->sdma.num_instances; i++)
+   amdgpu_ucode_release(>sdma.instance[i].fw);
}
return err;
 }
-- 
2.34.1



[PATCH v7 43/45] drm/amd: Use `amdgpu_ucode_release` helper for powerplay

2023-01-05 Thread Mario Limonciello
The `amdgpu_ucode_release` helper is replacing all calls to
release_firmware.

Reviewed-by: Alex Deucher 
Reviewed-by: Lijo Lazar 
Signed-off-by: Mario Limonciello 
---
v5->v6:
 * Adjust for amdgpu_ucode_release argument change
---
 drivers/gpu/drm/amd/pm/powerplay/amd_powerplay.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/pm/powerplay/amd_powerplay.c 
b/drivers/gpu/drm/amd/pm/powerplay/amd_powerplay.c
index 8f2cc6310340..11b7b4cffaae 100644
--- a/drivers/gpu/drm/amd/pm/powerplay/amd_powerplay.c
+++ b/drivers/gpu/drm/amd/pm/powerplay/amd_powerplay.c
@@ -111,8 +111,7 @@ static int pp_sw_fini(void *handle)
 
hwmgr_sw_fini(hwmgr);
 
-   release_firmware(adev->pm.fw);
-   adev->pm.fw = NULL;
+   amdgpu_ucode_release(>pm.fw);
 
return 0;
 }
-- 
2.34.1



[PATCH v7 45/45] drm/amd: make amdgpu_ucode_validate static

2023-01-05 Thread Mario Limonciello
No consumers outside of amdgpu_ucode.c use amdgpu_ucode_validate
anymore, so make the function static.

Reviewed-by: Alex Deucher 
Reviewed-by: Lijo Lazar 
Signed-off-by: Mario Limonciello 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c | 2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.h | 1 -
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
index 8ebfec12da87..47549d659d9b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
@@ -504,7 +504,7 @@ void amdgpu_ucode_print_gpu_info_hdr(const struct 
common_firmware_header *hdr)
}
 }
 
-int amdgpu_ucode_validate(const struct firmware *fw)
+static int amdgpu_ucode_validate(const struct firmware *fw)
 {
const struct common_firmware_header *hdr =
(const struct common_firmware_header *)fw->data;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.h
index 848579d4988b..bee93ab4298f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.h
@@ -543,7 +543,6 @@ void amdgpu_ucode_print_rlc_hdr(const struct 
common_firmware_header *hdr);
 void amdgpu_ucode_print_sdma_hdr(const struct common_firmware_header *hdr);
 void amdgpu_ucode_print_psp_hdr(const struct common_firmware_header *hdr);
 void amdgpu_ucode_print_gpu_info_hdr(const struct common_firmware_header *hdr);
-int amdgpu_ucode_validate(const struct firmware *fw);
 int amdgpu_ucode_request(struct amdgpu_device *adev, const struct firmware 
**fw,
 const char *fw_name);
 void amdgpu_ucode_release(const struct firmware **fw);
-- 
2.34.1



[PATCH v7 42/45] drm/amd: Use `amdgpu_ucode_*` helpers for DMCU

2023-01-05 Thread Mario Limonciello
The `amdgpu_ucode_request` helper will ensure that the return code for
missing firmware is -ENODEV so that early_init can fail.

The `amdgpu_ucode_release` helper is for symmetry on unloading.

Reviewed-by: Alex Deucher 
Reviewed-by: Lijo Lazar 
Signed-off-by: Mario Limonciello 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 11 ++-
 1 file changed, 2 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 61c192ead62f..79c4652e8e40 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -1881,20 +1881,13 @@ static int load_dmcu_fw(struct amdgpu_device *adev)
return 0;
}
 
-   r = request_firmware_direct(>dm.fw_dmcu, fw_name_dmcu, adev->dev);
-   if (r == -ENOENT) {
+   r = amdgpu_ucode_request(adev, >dm.fw_dmcu, fw_name_dmcu);
+   if (r == -ENODEV) {
/* DMCU firmware is not necessary, so don't raise a fuss if 
it's missing */
DRM_DEBUG_KMS("dm: DMCU firmware not found\n");
adev->dm.fw_dmcu = NULL;
return 0;
}
-   if (r) {
-   dev_err(adev->dev, "amdgpu_dm: Can't load firmware \"%s\"\n",
-   fw_name_dmcu);
-   return r;
-   }
-
-   r = amdgpu_ucode_validate(adev->dm.fw_dmcu);
if (r) {
dev_err(adev->dev, "amdgpu_dm: Can't validate firmware 
\"%s\"\n",
fw_name_dmcu);
-- 
2.34.1



[PATCH v7 40/45] drm/amd: Use `amdgpu_ucode_*` helpers for CGS

2023-01-05 Thread Mario Limonciello
The `amdgpu_ucode_request` helper will ensure that the return code for
missing firmware is -ENODEV so that early_init can fail.

The `amdgpu_ucode_release` helper is for symmetry on unloading.

Reviewed-by: Alex Deucher 
Reviewed-by: Lijo Lazar 
Signed-off-by: Mario Limonciello 
---
v5->v6:
 * Adjust for amdgpu_ucode_release argument change
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c | 11 ++-
 1 file changed, 2 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c
index f1a050379190..456e385333b6 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c
@@ -411,17 +411,10 @@ static int amdgpu_cgs_get_firmware_info(struct cgs_device 
*cgs_device,
return -EINVAL;
}
 
-   err = request_firmware(>pm.fw, fw_name, 
adev->dev);
-   if (err) {
-   DRM_ERROR("Failed to request firmware\n");
-   return err;
-   }
-
-   err = amdgpu_ucode_validate(adev->pm.fw);
+   err = amdgpu_ucode_request(adev, >pm.fw, fw_name);
if (err) {
DRM_ERROR("Failed to load firmware \"%s\"", 
fw_name);
-   release_firmware(adev->pm.fw);
-   adev->pm.fw = NULL;
+   amdgpu_ucode_release(>pm.fw);
return err;
}
 
-- 
2.34.1



[PATCH v7 41/45] drm/amd: Use `amdgpu_ucode_*` helpers for GPU info bin

2023-01-05 Thread Mario Limonciello
The `amdgpu_ucode_request` helper will ensure that the return code for
missing firmware is -ENODEV so that early_init can fail.

The `amdgpu_ucode_release` helper is for symmetry on unloading.

Reviewed-by: Alex Deucher 
Reviewed-by: Lijo Lazar 
Signed-off-by: Mario Limonciello 
---
v5->v6:
 * Adjust for amdgpu_ucode_release argument change
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 14 +++---
 1 file changed, 3 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index cdb681398a99..406d53ac3096 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -1983,17 +1983,10 @@ static int amdgpu_device_parse_gpu_info_fw(struct 
amdgpu_device *adev)
}
 
snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_gpu_info.bin", chip_name);
-   err = request_firmware(>firmware.gpu_info_fw, fw_name, adev->dev);
+   err = amdgpu_ucode_request(adev, >firmware.gpu_info_fw, fw_name);
if (err) {
dev_err(adev->dev,
-   "Failed to load gpu_info firmware \"%s\"\n",
-   fw_name);
-   goto out;
-   }
-   err = amdgpu_ucode_validate(adev->firmware.gpu_info_fw);
-   if (err) {
-   dev_err(adev->dev,
-   "Failed to validate gpu_info firmware \"%s\"\n",
+   "Failed to get gpu_info firmware \"%s\"\n",
fw_name);
goto out;
}
@@ -4030,8 +4023,7 @@ void amdgpu_device_fini_sw(struct amdgpu_device *adev)
 
amdgpu_fence_driver_sw_fini(adev);
amdgpu_device_ip_fini(adev);
-   release_firmware(adev->firmware.gpu_info_fw);
-   adev->firmware.gpu_info_fw = NULL;
+   amdgpu_ucode_release(>firmware.gpu_info_fw);
adev->accel_working = false;
dma_fence_put(rcu_dereference_protected(adev->gang_submit, true));
 
-- 
2.34.1



[PATCH v7 38/45] drm/amd: Use `amdgpu_ucode_*` helpers for UVD

2023-01-05 Thread Mario Limonciello
The `amdgpu_ucode_request` helper will ensure that the return code for
missing firmware is -ENODEV so that early_init can fail.

The `amdgpu_ucode_release` helper is for symmetry on unloading.

Reviewed-by: Alex Deucher 
Reviewed-by: Lijo Lazar 
Signed-off-by: Mario Limonciello 
---
v5->v6:
 * Adjust for amdgpu_ucode_release argument change
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 14 +++---
 1 file changed, 3 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
index 6eac649499d3..482fcf71d1c1 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
@@ -260,19 +260,11 @@ int amdgpu_uvd_sw_init(struct amdgpu_device *adev)
return -EINVAL;
}
 
-   r = request_firmware(>uvd.fw, fw_name, adev->dev);
-   if (r) {
-   dev_err(adev->dev, "amdgpu_uvd: Can't load firmware \"%s\"\n",
-   fw_name);
-   return r;
-   }
-
-   r = amdgpu_ucode_validate(adev->uvd.fw);
+   r = amdgpu_ucode_request(adev, >uvd.fw, fw_name);
if (r) {
dev_err(adev->dev, "amdgpu_uvd: Can't validate firmware 
\"%s\"\n",
fw_name);
-   release_firmware(adev->uvd.fw);
-   adev->uvd.fw = NULL;
+   amdgpu_ucode_release(>uvd.fw);
return r;
}
 
@@ -394,7 +386,7 @@ int amdgpu_uvd_sw_fini(struct amdgpu_device *adev)
amdgpu_ring_fini(>uvd.inst[j].ring_enc[i]);
}
amdgpu_bo_free_kernel(>uvd.ib_bo, NULL, );
-   release_firmware(adev->uvd.fw);
+   amdgpu_ucode_release(>uvd.fw);
 
return 0;
 }
-- 
2.34.1



[PATCH v7 44/45] drm/amd: Use `amdgpu_ucode_release` helper for si

2023-01-05 Thread Mario Limonciello
The `amdgpu_ucode_release` helper is replacing all calls
to release_firmware.

Reviewed-by: Alex Deucher 
Reviewed-by: Lijo Lazar 
Signed-off-by: Mario Limonciello 
---
v5->v6:
 * Adjust for amdgpu_ucode_release argument change
---
 drivers/gpu/drm/amd/pm/legacy-dpm/si_dpm.c | 11 ++-
 1 file changed, 2 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/amd/pm/legacy-dpm/si_dpm.c 
b/drivers/gpu/drm/amd/pm/legacy-dpm/si_dpm.c
index 49c398ec0aaf..d6d9e3b1b2c0 100644
--- a/drivers/gpu/drm/amd/pm/legacy-dpm/si_dpm.c
+++ b/drivers/gpu/drm/amd/pm/legacy-dpm/si_dpm.c
@@ -7714,20 +7714,13 @@ static int si_dpm_init_microcode(struct amdgpu_device 
*adev)
}
 
snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_smc.bin", chip_name);
-   err = request_firmware(>pm.fw, fw_name, adev->dev);
-   if (err)
-   goto out;
-   err = amdgpu_ucode_validate(adev->pm.fw);
-
-out:
+   err = amdgpu_ucode_request(adev, >pm.fw, fw_name);
if (err) {
DRM_ERROR("si_smc: Failed to load firmware. err = %d\"%s\"\n",
  err, fw_name);
-   release_firmware(adev->pm.fw);
-   adev->pm.fw = NULL;
+   amdgpu_ucode_release(>pm.fw);
}
return err;
-
 }
 
 static int si_dpm_sw_init(void *handle)
-- 
2.34.1



[PATCH v7 32/45] drm/amd: Use `amdgpu_ucode_*` helpers for GMC6

2023-01-05 Thread Mario Limonciello
The `amdgpu_ucode_request` helper will ensure that the return code for
missing firmware is -ENODEV so that early_init can fail.

The `amdgpu_ucode_release` helper is for symmetry on unloading.

Reviewed-by: Alex Deucher 
Reviewed-by: Lijo Lazar 
Signed-off-by: Mario Limonciello 
---
v5->v6:
 * Adjust for amdgpu_ucode_release argument change
---
 drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c | 14 +++---
 1 file changed, 3 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c 
b/drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c
index ec291d28edff..d154ab48f507 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c
@@ -131,19 +131,12 @@ static int gmc_v6_0_init_microcode(struct amdgpu_device 
*adev)
snprintf(fw_name, sizeof(fw_name), "amdgpu/si58_mc.bin");
else
snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_mc.bin", 
chip_name);
-   err = request_firmware(>gmc.fw, fw_name, adev->dev);
-   if (err)
-   goto out;
-
-   err = amdgpu_ucode_validate(adev->gmc.fw);
-
-out:
+   err = amdgpu_ucode_request(adev, >gmc.fw, fw_name);
if (err) {
dev_err(adev->dev,
   "si_mc: Failed to load firmware \"%s\"\n",
   fw_name);
-   release_firmware(adev->gmc.fw);
-   adev->gmc.fw = NULL;
+   amdgpu_ucode_release(>gmc.fw);
}
return err;
 }
@@ -894,8 +887,7 @@ static int gmc_v6_0_sw_fini(void *handle)
amdgpu_vm_manager_fini(adev);
amdgpu_gart_table_vram_free(adev);
amdgpu_bo_fini(adev);
-   release_firmware(adev->gmc.fw);
-   adev->gmc.fw = NULL;
+   amdgpu_ucode_release(>gmc.fw);
 
return 0;
 }
-- 
2.34.1



[PATCH v7 24/45] drm/amd/display: Load DMUB microcode during early_init

2023-01-05 Thread Mario Limonciello
If DMUB is required for an ASIC, ensure that the microcode is available
and validates during early_init.

Any failures will cause the driver to fail to probe before the firmware
framebuffer has been removed.

Reviewed-by: Alex Deucher 
Reviewed-by: Harry Wentland 
Reviewed-by: Lijo Lazar 
Signed-off-by: Mario Limonciello 
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 89 ---
 1 file changed, 58 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 4829b5431e4c..c8c5d37c8b3a 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -1945,7 +1945,6 @@ static int dm_dmub_sw_init(struct amdgpu_device *adev)
struct dmub_srv_fb_info *fb_info;
struct dmub_srv *dmub_srv;
const struct dmcub_firmware_header_v1_0 *hdr;
-   const char *fw_name_dmub;
enum dmub_asic dmub_asic;
enum dmub_status status;
int r;
@@ -1953,73 +1952,46 @@ static int dm_dmub_sw_init(struct amdgpu_device *adev)
switch (adev->ip_versions[DCE_HWIP][0]) {
case IP_VERSION(2, 1, 0):
dmub_asic = DMUB_ASIC_DCN21;
-   fw_name_dmub = FIRMWARE_RENOIR_DMUB;
-   if (ASICREV_IS_GREEN_SARDINE(adev->external_rev_id))
-   fw_name_dmub = FIRMWARE_GREEN_SARDINE_DMUB;
break;
case IP_VERSION(3, 0, 0):
-   if (adev->ip_versions[GC_HWIP][0] == IP_VERSION(10, 3, 0)) {
+   if (adev->ip_versions[GC_HWIP][0] == IP_VERSION(10, 3, 0))
dmub_asic = DMUB_ASIC_DCN30;
-   fw_name_dmub = FIRMWARE_SIENNA_CICHLID_DMUB;
-   } else {
+   else
dmub_asic = DMUB_ASIC_DCN30;
-   fw_name_dmub = FIRMWARE_NAVY_FLOUNDER_DMUB;
-   }
break;
case IP_VERSION(3, 0, 1):
dmub_asic = DMUB_ASIC_DCN301;
-   fw_name_dmub = FIRMWARE_VANGOGH_DMUB;
break;
case IP_VERSION(3, 0, 2):
dmub_asic = DMUB_ASIC_DCN302;
-   fw_name_dmub = FIRMWARE_DIMGREY_CAVEFISH_DMUB;
break;
case IP_VERSION(3, 0, 3):
dmub_asic = DMUB_ASIC_DCN303;
-   fw_name_dmub = FIRMWARE_BEIGE_GOBY_DMUB;
break;
case IP_VERSION(3, 1, 2):
case IP_VERSION(3, 1, 3):
dmub_asic = (adev->external_rev_id == YELLOW_CARP_B0) ? 
DMUB_ASIC_DCN31B : DMUB_ASIC_DCN31;
-   fw_name_dmub = FIRMWARE_YELLOW_CARP_DMUB;
break;
case IP_VERSION(3, 1, 4):
dmub_asic = DMUB_ASIC_DCN314;
-   fw_name_dmub = FIRMWARE_DCN_314_DMUB;
break;
case IP_VERSION(3, 1, 5):
dmub_asic = DMUB_ASIC_DCN315;
-   fw_name_dmub = FIRMWARE_DCN_315_DMUB;
break;
case IP_VERSION(3, 1, 6):
dmub_asic = DMUB_ASIC_DCN316;
-   fw_name_dmub = FIRMWARE_DCN316_DMUB;
break;
case IP_VERSION(3, 2, 0):
dmub_asic = DMUB_ASIC_DCN32;
-   fw_name_dmub = FIRMWARE_DCN_V3_2_0_DMCUB;
break;
case IP_VERSION(3, 2, 1):
dmub_asic = DMUB_ASIC_DCN321;
-   fw_name_dmub = FIRMWARE_DCN_V3_2_1_DMCUB;
break;
default:
/* ASIC doesn't support DMUB. */
return 0;
}
 
-   r = request_firmware_direct(>dm.dmub_fw, fw_name_dmub, adev->dev);
-   if (r) {
-   DRM_ERROR("DMUB firmware loading failed: %d\n", r);
-   return 0;
-   }
-
-   r = amdgpu_ucode_validate(adev->dm.dmub_fw);
-   if (r) {
-   DRM_ERROR("Couldn't validate DMUB firmware: %d\n", r);
-   return 0;
-   }
-
hdr = (const struct dmcub_firmware_header_v1_0 *)adev->dm.dmub_fw->data;
adev->dm.dmcub_fw_version = le32_to_cpu(hdr->header.ucode_version);
 
@@ -4513,6 +4485,61 @@ DEVICE_ATTR_WO(s3_debug);
 
 #endif
 
+static int dm_init_microcode(struct amdgpu_device *adev)
+{
+   char *fw_name_dmub;
+   int r;
+
+   switch (adev->ip_versions[DCE_HWIP][0]) {
+   case IP_VERSION(2, 1, 0):
+   fw_name_dmub = FIRMWARE_RENOIR_DMUB;
+   if (ASICREV_IS_GREEN_SARDINE(adev->external_rev_id))
+   fw_name_dmub = FIRMWARE_GREEN_SARDINE_DMUB;
+   break;
+   case IP_VERSION(3, 0, 0):
+   if (adev->ip_versions[GC_HWIP][0] == IP_VERSION(10, 3, 0))
+   fw_name_dmub = FIRMWARE_SIENNA_CICHLID_DMUB;
+   else
+   fw_name_dmub = FIRMWARE_NAVY_FLOUNDER_DMUB;
+   break;
+   case IP_VERSION(3, 0, 1):
+   fw_name_dmub = FIRMWARE_VANGOGH_DMUB;
+   

[PATCH v7 35/45] drm/amd: Use `amdgpu_ucode_*` helpers for SDMA2.4

2023-01-05 Thread Mario Limonciello
The `amdgpu_ucode_request` helper will ensure that the return code for
missing firmware is -ENODEV so that early_init can fail.

The `amdgpu_ucode_release` helper is for symmetry on unloading.

Reviewed-by: Alex Deucher 
Reviewed-by: Lijo Lazar 
Signed-off-by: Mario Limonciello 
---
v5->v6:
 * Adjust for amdgpu_ucode_release argument change
---
 drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c | 18 ++
 1 file changed, 6 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c 
b/drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c
index c52d246a1d96..fd2a7b66ac56 100644
--- a/drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c
+++ b/drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c
@@ -113,10 +113,9 @@ static void sdma_v2_4_init_golden_registers(struct 
amdgpu_device *adev)
 static void sdma_v2_4_free_microcode(struct amdgpu_device *adev)
 {
int i;
-   for (i = 0; i < adev->sdma.num_instances; i++) {
-   release_firmware(adev->sdma.instance[i].fw);
-   adev->sdma.instance[i].fw = NULL;
-   }
+
+   for (i = 0; i < adev->sdma.num_instances; i++)
+   amdgpu_ucode_release(>sdma.instance[i].fw);
 }
 
 /**
@@ -151,10 +150,7 @@ static int sdma_v2_4_init_microcode(struct amdgpu_device 
*adev)
snprintf(fw_name, sizeof(fw_name), 
"amdgpu/%s_sdma.bin", chip_name);
else
snprintf(fw_name, sizeof(fw_name), 
"amdgpu/%s_sdma1.bin", chip_name);
-   err = request_firmware(>sdma.instance[i].fw, fw_name, 
adev->dev);
-   if (err)
-   goto out;
-   err = amdgpu_ucode_validate(adev->sdma.instance[i].fw);
+   err = amdgpu_ucode_request(adev, >sdma.instance[i].fw, 
fw_name);
if (err)
goto out;
hdr = (const struct sdma_firmware_header_v1_0 
*)adev->sdma.instance[i].fw->data;
@@ -176,10 +172,8 @@ static int sdma_v2_4_init_microcode(struct amdgpu_device 
*adev)
 out:
if (err) {
pr_err("sdma_v2_4: Failed to load firmware \"%s\"\n", fw_name);
-   for (i = 0; i < adev->sdma.num_instances; i++) {
-   release_firmware(adev->sdma.instance[i].fw);
-   adev->sdma.instance[i].fw = NULL;
-   }
+   for (i = 0; i < adev->sdma.num_instances; i++)
+   amdgpu_ucode_release(>sdma.instance[i].fw);
}
return err;
 }
-- 
2.34.1



[PATCH v7 18/45] drm/amd: Use `amdgpu_ucode_*` helpers for GFX11

2023-01-05 Thread Mario Limonciello
The `amdgpu_ucode_request` helper will ensure that the return code for
missing firmware is -ENODEV so that early_init can fail.

The `amdgpu_ucode_release` helper will provide symmetery on unload.

Reviewed-by: Alex Deucher 
Reviewed-by: Lijo Lazar 
Signed-off-by: Mario Limonciello 
---
v5->v6:
 * Adjust for amdgpu_ucode_release argument change
---
 drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c | 104 +
 drivers/gpu/drm/amd/amdgpu/imu_v11_0.c |   7 +-
 2 files changed, 39 insertions(+), 72 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c
index a56c6e106d00..d4f67624d05b 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c
@@ -431,18 +431,39 @@ static int gfx_v11_0_ring_test_ib(struct amdgpu_ring 
*ring, long timeout)
 
 static void gfx_v11_0_free_microcode(struct amdgpu_device *adev)
 {
-   release_firmware(adev->gfx.pfp_fw);
-   adev->gfx.pfp_fw = NULL;
-   release_firmware(adev->gfx.me_fw);
-   adev->gfx.me_fw = NULL;
-   release_firmware(adev->gfx.rlc_fw);
-   adev->gfx.rlc_fw = NULL;
-   release_firmware(adev->gfx.mec_fw);
-   adev->gfx.mec_fw = NULL;
+   amdgpu_ucode_release(>gfx.pfp_fw);
+   amdgpu_ucode_release(>gfx.me_fw);
+   amdgpu_ucode_release(>gfx.rlc_fw);
+   amdgpu_ucode_release(>gfx.mec_fw);
 
kfree(adev->gfx.rlc.register_list_format);
 }
 
+static int gfx_v11_0_init_toc_microcode(struct amdgpu_device *adev)
+{
+   const struct psp_firmware_header_v1_0 *toc_hdr;
+   int err = 0;
+   char fw_name[40];
+   char ucode_prefix[30];
+
+   amdgpu_ucode_ip_version_decode(adev, GC_HWIP, ucode_prefix, 
sizeof(ucode_prefix));
+   snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_toc.bin", ucode_prefix);
+   err = amdgpu_ucode_request(adev, >psp.toc_fw, fw_name);
+   if (err)
+   goto out;
+
+   toc_hdr = (const struct psp_firmware_header_v1_0 
*)adev->psp.toc_fw->data;
+   adev->psp.toc.fw_version = le32_to_cpu(toc_hdr->header.ucode_version);
+   adev->psp.toc.feature_version = le32_to_cpu(toc_hdr->sos.fw_version);
+   adev->psp.toc.size_bytes = 
le32_to_cpu(toc_hdr->header.ucode_size_bytes);
+   adev->psp.toc.start_addr = (uint8_t *)toc_hdr +
+   
le32_to_cpu(toc_hdr->header.ucode_array_offset_bytes);
+   return 0;
+out:
+   amdgpu_ucode_release(>psp.toc_fw);
+   return err;
+}
+
 static int gfx_v11_0_init_microcode(struct amdgpu_device *adev)
 {
char fw_name[40];
@@ -457,10 +478,7 @@ static int gfx_v11_0_init_microcode(struct amdgpu_device 
*adev)
amdgpu_ucode_ip_version_decode(adev, GC_HWIP, ucode_prefix, 
sizeof(ucode_prefix));
 
snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_pfp.bin", ucode_prefix);
-   err = request_firmware(>gfx.pfp_fw, fw_name, adev->dev);
-   if (err)
-   goto out;
-   err = amdgpu_ucode_validate(adev->gfx.pfp_fw);
+   err = amdgpu_ucode_request(adev, >gfx.pfp_fw, fw_name);
if (err)
goto out;
/* check pfp fw hdr version to decide if enable rs64 for gfx11.*/
@@ -477,10 +495,7 @@ static int gfx_v11_0_init_microcode(struct amdgpu_device 
*adev)
}
 
snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_me.bin", ucode_prefix);
-   err = request_firmware(>gfx.me_fw, fw_name, adev->dev);
-   if (err)
-   goto out;
-   err = amdgpu_ucode_validate(adev->gfx.me_fw);
+   err = amdgpu_ucode_request(adev, >gfx.me_fw, fw_name);
if (err)
goto out;
if (adev->gfx.rs64_enable) {
@@ -493,10 +508,7 @@ static int gfx_v11_0_init_microcode(struct amdgpu_device 
*adev)
 
if (!amdgpu_sriov_vf(adev)) {
snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_rlc.bin", 
ucode_prefix);
-   err = request_firmware(>gfx.rlc_fw, fw_name, adev->dev);
-   if (err)
-   goto out;
-   err = amdgpu_ucode_validate(adev->gfx.rlc_fw);
+   err = amdgpu_ucode_request(adev, >gfx.rlc_fw, fw_name);
if (err)
goto out;
rlc_hdr = (const struct rlc_firmware_header_v2_0 
*)adev->gfx.rlc_fw->data;
@@ -508,10 +520,7 @@ static int gfx_v11_0_init_microcode(struct amdgpu_device 
*adev)
}
 
snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_mec.bin", ucode_prefix);
-   err = request_firmware(>gfx.mec_fw, fw_name, adev->dev);
-   if (err)
-   goto out;
-   err = amdgpu_ucode_validate(adev->gfx.mec_fw);
+   err = amdgpu_ucode_request(adev, >gfx.mec_fw, fw_name);
if (err)
goto out;
if (adev->gfx.rs64_enable) {
@@ -530,54 +539,15 @@ static int gfx_v11_0_init_microcode(struct amdgpu_device 
*adev)
 
 out:
if (err) {
-   dev_err(adev->dev,
-   "gfx11: Failed to init firmware 

[PATCH v7 39/45] drm/amd: Use `amdgpu_ucode_*` helpers for VCE

2023-01-05 Thread Mario Limonciello
The `amdgpu_ucode_request` helper will ensure that the return code for
missing firmware is -ENODEV so that early_init can fail.

The `amdgpu_ucode_release` helper is for symmetry on unloading.

Reviewed-by: Alex Deucher 
Reviewed-by: Lijo Lazar 
Signed-off-by: Mario Limonciello 
---
v5->v6:
 * Adjust for amdgpu_ucode_release argument change
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c | 14 +++---
 1 file changed, 3 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
index 02cb3a12dd76..ea78b7513182 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
@@ -158,19 +158,11 @@ int amdgpu_vce_sw_init(struct amdgpu_device *adev, 
unsigned long size)
return -EINVAL;
}
 
-   r = request_firmware(>vce.fw, fw_name, adev->dev);
-   if (r) {
-   dev_err(adev->dev, "amdgpu_vce: Can't load firmware \"%s\"\n",
-   fw_name);
-   return r;
-   }
-
-   r = amdgpu_ucode_validate(adev->vce.fw);
+   r = amdgpu_ucode_request(adev, >vce.fw, fw_name);
if (r) {
dev_err(adev->dev, "amdgpu_vce: Can't validate firmware 
\"%s\"\n",
fw_name);
-   release_firmware(adev->vce.fw);
-   adev->vce.fw = NULL;
+   amdgpu_ucode_release(>vce.fw);
return r;
}
 
@@ -226,7 +218,7 @@ int amdgpu_vce_sw_fini(struct amdgpu_device *adev)
for (i = 0; i < adev->vce.num_rings; i++)
amdgpu_ring_fini(>vce.ring[i]);
 
-   release_firmware(adev->vce.fw);
+   amdgpu_ucode_release(>vce.fw);
mutex_destroy(>vce.idle_mutex);
 
return 0;
-- 
2.34.1



[PATCH v7 27/45] drm/amd: Load SMU microcode during early_init

2023-01-05 Thread Mario Limonciello
This will ensure that the microcode is available before the firmware
framebuffer has been destroyed.

Reviewed-by: Alex Deucher 
Reviewed-by: Lijo Lazar 
Signed-off-by: Mario Limonciello 
---
 drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c 
b/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
index 2fa79f892a92..ec52830dde24 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
@@ -623,6 +623,7 @@ static int smu_early_init(void *handle)
 {
struct amdgpu_device *adev = (struct amdgpu_device *)handle;
struct smu_context *smu;
+   int r;
 
smu = kzalloc(sizeof(struct smu_context), GFP_KERNEL);
if (!smu)
@@ -640,7 +641,10 @@ static int smu_early_init(void *handle)
adev->powerplay.pp_handle = smu;
adev->powerplay.pp_funcs = _pm_funcs;
 
-   return smu_set_funcs(adev);
+   r = smu_set_funcs(adev);
+   if (r)
+   return r;
+   return smu_init_microcode(smu);
 }
 
 static int smu_set_default_dpm_table(struct smu_context *smu)
@@ -1067,12 +1071,6 @@ static int smu_sw_init(void *handle)
smu->smu_dpm.dpm_level = AMD_DPM_FORCED_LEVEL_AUTO;
smu->smu_dpm.requested_dpm_level = AMD_DPM_FORCED_LEVEL_AUTO;
 
-   ret = smu_init_microcode(smu);
-   if (ret) {
-   dev_err(adev->dev, "Failed to load smu firmware!\n");
-   return ret;
-   }
-
ret = smu_smc_table_sw_init(smu);
if (ret) {
dev_err(adev->dev, "Failed to sw init smc table!\n");
-- 
2.34.1



[PATCH v7 36/45] drm/amd: Use `amdgpu_ucode_*` helpers for SDMA3.0

2023-01-05 Thread Mario Limonciello
The `amdgpu_ucode_request` helper will ensure that the return code for
missing firmware is -ENODEV so that early_init can fail.

The `amdgpu_ucode_release` helper is for symmetry on unloading.

Reviewed-by: Alex Deucher 
Reviewed-by: Lijo Lazar 
Signed-off-by: Mario Limonciello 
---
v5->v6:
 * Adjust for amdgpu_ucode_release argument change
---
 drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c | 18 ++
 1 file changed, 6 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c 
b/drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c
index 486d9b5c1b9e..e572389089d2 100644
--- a/drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c
@@ -250,10 +250,9 @@ static void sdma_v3_0_init_golden_registers(struct 
amdgpu_device *adev)
 static void sdma_v3_0_free_microcode(struct amdgpu_device *adev)
 {
int i;
-   for (i = 0; i < adev->sdma.num_instances; i++) {
-   release_firmware(adev->sdma.instance[i].fw);
-   adev->sdma.instance[i].fw = NULL;
-   }
+
+   for (i = 0; i < adev->sdma.num_instances; i++)
+   amdgpu_ucode_release(>sdma.instance[i].fw);
 }
 
 /**
@@ -309,10 +308,7 @@ static int sdma_v3_0_init_microcode(struct amdgpu_device 
*adev)
snprintf(fw_name, sizeof(fw_name), 
"amdgpu/%s_sdma.bin", chip_name);
else
snprintf(fw_name, sizeof(fw_name), 
"amdgpu/%s_sdma1.bin", chip_name);
-   err = request_firmware(>sdma.instance[i].fw, fw_name, 
adev->dev);
-   if (err)
-   goto out;
-   err = amdgpu_ucode_validate(adev->sdma.instance[i].fw);
+   err = amdgpu_ucode_request(adev, >sdma.instance[i].fw, 
fw_name);
if (err)
goto out;
hdr = (const struct sdma_firmware_header_v1_0 
*)adev->sdma.instance[i].fw->data;
@@ -332,10 +328,8 @@ static int sdma_v3_0_init_microcode(struct amdgpu_device 
*adev)
 out:
if (err) {
pr_err("sdma_v3_0: Failed to load firmware \"%s\"\n", fw_name);
-   for (i = 0; i < adev->sdma.num_instances; i++) {
-   release_firmware(adev->sdma.instance[i].fw);
-   adev->sdma.instance[i].fw = NULL;
-   }
+   for (i = 0; i < adev->sdma.num_instances; i++)
+   amdgpu_ucode_release(>sdma.instance[i].fw);
}
return err;
 }
-- 
2.34.1



[PATCH v7 28/45] drm/amd: Optimize SRIOV switch/case for PSP microcode load

2023-01-05 Thread Mario Limonciello
Now that IP version decoding is used, a number of case statements
can be combined.

Reviewed-by: Alex Deucher 
Reviewed-by: Christian König 
Reviewed-by: Lijo Lazar 
Signed-off-by: Mario Limonciello 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
index aae76acc38e5..706cce2edfaa 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
@@ -132,14 +132,8 @@ static int psp_init_sriov_microcode(struct psp_context 
*psp)
 
switch (adev->ip_versions[MP0_HWIP][0]) {
case IP_VERSION(9, 0, 0):
-   adev->virt.autoload_ucode_id = AMDGPU_UCODE_ID_CP_MEC2;
-   ret = psp_init_cap_microcode(psp, ucode_prefix);
-   break;
-   case IP_VERSION(11, 0, 9):
-   adev->virt.autoload_ucode_id = AMDGPU_UCODE_ID_CP_MEC2;
-   ret = psp_init_cap_microcode(psp, ucode_prefix);
-   break;
case IP_VERSION(11, 0, 7):
+   case IP_VERSION(11, 0, 9):
adev->virt.autoload_ucode_id = AMDGPU_UCODE_ID_CP_MEC2;
ret = psp_init_cap_microcode(psp, ucode_prefix);
break;
-- 
2.34.1



[PATCH v7 34/45] drm/amd: Use `amdgpu_ucode_*` helpers for GMC8

2023-01-05 Thread Mario Limonciello
The `amdgpu_ucode_request` helper will ensure that the return code for
missing firmware is -ENODEV so that early_init can fail.

The `amdgpu_ucode_release` helper is for symmetry on unloading.

Reviewed-by: Alex Deucher 
Reviewed-by: Lijo Lazar 
Signed-off-by: Mario Limonciello 
---
v5->v6:
 * Adjust for amdgpu_ucode_release argument change
---
 drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 13 +++--
 1 file changed, 3 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c 
b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
index 382dde1ce74c..561daac2e6f7 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
@@ -264,16 +264,10 @@ static int gmc_v8_0_init_microcode(struct amdgpu_device 
*adev)
}
 
snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_mc.bin", chip_name);
-   err = request_firmware(>gmc.fw, fw_name, adev->dev);
-   if (err)
-   goto out;
-   err = amdgpu_ucode_validate(adev->gmc.fw);
-
-out:
+   err = amdgpu_ucode_request(adev, >gmc.fw, fw_name);
if (err) {
pr_err("mc: Failed to load firmware \"%s\"\n", fw_name);
-   release_firmware(adev->gmc.fw);
-   adev->gmc.fw = NULL;
+   amdgpu_ucode_release(>gmc.fw);
}
return err;
 }
@@ -1203,8 +1197,7 @@ static int gmc_v8_0_sw_fini(void *handle)
kfree(adev->gmc.vm_fault_info);
amdgpu_gart_table_vram_free(adev);
amdgpu_bo_fini(adev);
-   release_firmware(adev->gmc.fw);
-   adev->gmc.fw = NULL;
+   amdgpu_ucode_release(>gmc.fw);
 
return 0;
 }
-- 
2.34.1



[PATCH v7 33/45] drm/amd: Use `amdgpu_ucode_*` helpers for GMC7

2023-01-05 Thread Mario Limonciello
The `amdgpu_ucode_request` helper will ensure that the return code for
missing firmware is -ENODEV so that early_init can fail.

The `amdgpu_ucode_release` helper is for symmetry on unloading.

Reviewed-by: Alex Deucher 
Reviewed-by: Lijo Lazar 
Signed-off-by: Mario Limonciello 
---
v5->v6:
 * Adjust for amdgpu_ucode_release argument change
---
 drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c | 13 +++--
 1 file changed, 3 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c 
b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
index 979da6f510e8..4412e8c65726 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
@@ -156,16 +156,10 @@ static int gmc_v7_0_init_microcode(struct amdgpu_device 
*adev)
 
snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_mc.bin", chip_name);
 
-   err = request_firmware(>gmc.fw, fw_name, adev->dev);
-   if (err)
-   goto out;
-   err = amdgpu_ucode_validate(adev->gmc.fw);
-
-out:
+   err = amdgpu_ucode_request(adev, >gmc.fw, fw_name);
if (err) {
pr_err("cik_mc: Failed to load firmware \"%s\"\n", fw_name);
-   release_firmware(adev->gmc.fw);
-   adev->gmc.fw = NULL;
+   amdgpu_ucode_release(>gmc.fw);
}
return err;
 }
@@ -1081,8 +1075,7 @@ static int gmc_v7_0_sw_fini(void *handle)
kfree(adev->gmc.vm_fault_info);
amdgpu_gart_table_vram_free(adev);
amdgpu_bo_fini(adev);
-   release_firmware(adev->gmc.fw);
-   adev->gmc.fw = NULL;
+   amdgpu_ucode_release(>gmc.fw);
 
return 0;
 }
-- 
2.34.1



[PATCH v7 23/45] drm/amd: Use `amdgpu_ucode_*` helpers for PSP

2023-01-05 Thread Mario Limonciello
The `amdgpu_ucode_request` helper will ensure that the return code for
missing firmware is -ENODEV so that early_init can fail.

The `amdgpu_ucode_release` helper is for symmetry on unloading.

Reviewed-by: Alex Deucher 
Reviewed-by: Lijo Lazar 
Signed-off-by: Mario Limonciello 
---
v5->v6:
 * Adjust for amdgpu_ucode_release argument change
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 80 +++--
 1 file changed, 21 insertions(+), 59 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
index 73d67a4d0f5b..aae76acc38e5 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
@@ -510,20 +510,11 @@ static int psp_sw_fini(void *handle)
 
psp_memory_training_fini(psp);
 
-   release_firmware(psp->sos_fw);
-   psp->sos_fw = NULL;
-
-   release_firmware(psp->asd_fw);
-   psp->asd_fw = NULL;
-
-   release_firmware(psp->ta_fw);
-   psp->ta_fw = NULL;
-
-   release_firmware(psp->cap_fw);
-   psp->cap_fw = NULL;
-
-   release_firmware(psp->toc_fw);
-   psp->toc_fw = NULL;
+   amdgpu_ucode_release(>sos_fw);
+   amdgpu_ucode_release(>asd_fw);
+   amdgpu_ucode_release(>ta_fw);
+   amdgpu_ucode_release(>cap_fw);
+   amdgpu_ucode_release(>toc_fw);
 
if (adev->ip_versions[MP0_HWIP][0] == IP_VERSION(11, 0, 0) ||
adev->ip_versions[MP0_HWIP][0] == IP_VERSION(11, 0, 7))
@@ -2912,11 +2903,7 @@ int psp_init_asd_microcode(struct psp_context *psp, 
const char *chip_name)
int err = 0;
 
snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_asd.bin", chip_name);
-   err = request_firmware(>psp.asd_fw, fw_name, adev->dev);
-   if (err)
-   goto out;
-
-   err = amdgpu_ucode_validate(adev->psp.asd_fw);
+   err = amdgpu_ucode_request(adev, >psp.asd_fw, fw_name);
if (err)
goto out;
 
@@ -2928,9 +2915,7 @@ int psp_init_asd_microcode(struct psp_context *psp, const 
char *chip_name)

le32_to_cpu(asd_hdr->header.ucode_array_offset_bytes);
return 0;
 out:
-   dev_err(adev->dev, "fail to initialize asd microcode\n");
-   release_firmware(adev->psp.asd_fw);
-   adev->psp.asd_fw = NULL;
+   amdgpu_ucode_release(>psp.asd_fw);
return err;
 }
 
@@ -2942,11 +2927,7 @@ int psp_init_toc_microcode(struct psp_context *psp, 
const char *chip_name)
int err = 0;
 
snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_toc.bin", chip_name);
-   err = request_firmware(>psp.toc_fw, fw_name, adev->dev);
-   if (err)
-   goto out;
-
-   err = amdgpu_ucode_validate(adev->psp.toc_fw);
+   err = amdgpu_ucode_request(adev, >psp.toc_fw, fw_name);
if (err)
goto out;
 
@@ -2958,9 +2939,7 @@ int psp_init_toc_microcode(struct psp_context *psp, const 
char *chip_name)

le32_to_cpu(toc_hdr->header.ucode_array_offset_bytes);
return 0;
 out:
-   dev_err(adev->dev, "fail to request/validate toc microcode\n");
-   release_firmware(adev->psp.toc_fw);
-   adev->psp.toc_fw = NULL;
+   amdgpu_ucode_release(>psp.toc_fw);
return err;
 }
 
@@ -3105,11 +3084,7 @@ int psp_init_sos_microcode(struct psp_context *psp, 
const char *chip_name)
int fw_index = 0;
 
snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_sos.bin", chip_name);
-   err = request_firmware(>psp.sos_fw, fw_name, adev->dev);
-   if (err)
-   goto out;
-
-   err = amdgpu_ucode_validate(adev->psp.sos_fw);
+   err = amdgpu_ucode_request(adev, >psp.sos_fw, fw_name);
if (err)
goto out;
 
@@ -3181,10 +3156,7 @@ int psp_init_sos_microcode(struct psp_context *psp, 
const char *chip_name)
 
return 0;
 out:
-   dev_err(adev->dev,
-   "failed to init sos firmware\n");
-   release_firmware(adev->psp.sos_fw);
-   adev->psp.sos_fw = NULL;
+   amdgpu_ucode_release(>psp.sos_fw);
 
return err;
 }
@@ -3341,10 +3313,7 @@ int psp_init_ta_microcode(struct psp_context *psp, const 
char *chip_name)
int err;
 
snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_ta.bin", chip_name);
-   err = request_firmware(>psp.ta_fw, fw_name, adev->dev);
-   if (err)
-   return err;
-   err = amdgpu_ucode_validate(adev->psp.ta_fw);
+   err = amdgpu_ucode_request(adev, >psp.ta_fw, fw_name);
if (err)
return err;
 
@@ -3361,11 +3330,8 @@ int psp_init_ta_microcode(struct psp_context *psp, const 
char *chip_name)
err = -EINVAL;
}
 
-   if (err) {
-   dev_err(adev->dev, "fail to initialize ta microcode\n");
-   release_firmware(adev->psp.ta_fw);
-   adev->psp.ta_fw = NULL;
-   }
+   if (err)
+   amdgpu_ucode_release(>psp.ta_fw);
 
return err;
 }
@@ -3384,17 

[PATCH v7 20/45] drm/amd: Parse both v1 and v2 TA microcode headers using same function

2023-01-05 Thread Mario Limonciello
Several IP versions duplicate code and can't use the common helpers.
Move this code into a single function so that the helpers can be used.

Signed-off-by: Mario Limonciello 
---
v6->v7:
 * Drop tags
 * Only set adev->psp.securedisplay_context.context on PSPv12 Renoir and
   PSP v10 which matches previous behavior.  If it should match for Cezanne
   and PSPv11 too we can undo this part of the check.
v5->v6:
 * Rebase on earlier patches
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 123 ++--
 drivers/gpu/drm/amd/amdgpu/psp_v10_0.c  |  64 +---
 drivers/gpu/drm/amd/amdgpu/psp_v11_0.c  |  80 ++-
 drivers/gpu/drm/amd/amdgpu/psp_v12_0.c  |  66 ++---
 4 files changed, 115 insertions(+), 218 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
index 7a2fc920739b..bdc2bf87a286 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
@@ -3272,41 +3272,76 @@ static int parse_ta_bin_descriptor(struct psp_context 
*psp,
return 0;
 }
 
-int psp_init_ta_microcode(struct psp_context *psp,
- const char *chip_name)
+static int parse_ta_v1_microcode(struct psp_context *psp)
 {
+   const struct ta_firmware_header_v1_0 *ta_hdr;
struct amdgpu_device *adev = psp->adev;
-   char fw_name[PSP_FW_NAME_LEN];
-   const struct ta_firmware_header_v2_0 *ta_hdr;
-   int err = 0;
-   int ta_index = 0;
 
-   if (!chip_name) {
-   dev_err(adev->dev, "invalid chip name for ta microcode\n");
+   ta_hdr = (const struct ta_firmware_header_v1_0 *) adev->psp.ta_fw->data;
+
+   if (le16_to_cpu(ta_hdr->header.header_version_major) != 1)
return -EINVAL;
-   }
 
-   snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_ta.bin", chip_name);
-   err = request_firmware(>psp.ta_fw, fw_name, adev->dev);
-   if (err)
-   goto out;
+   adev->psp.xgmi_context.context.bin_desc.fw_version =
+   le32_to_cpu(ta_hdr->xgmi.fw_version);
+   adev->psp.xgmi_context.context.bin_desc.size_bytes =
+   le32_to_cpu(ta_hdr->xgmi.size_bytes);
+   adev->psp.xgmi_context.context.bin_desc.start_addr =
+   (uint8_t *)ta_hdr +
+   le32_to_cpu(ta_hdr->header.ucode_array_offset_bytes);
+
+   adev->psp.ras_context.context.bin_desc.fw_version =
+   le32_to_cpu(ta_hdr->ras.fw_version);
+   adev->psp.ras_context.context.bin_desc.size_bytes =
+   le32_to_cpu(ta_hdr->ras.size_bytes);
+   adev->psp.ras_context.context.bin_desc.start_addr =
+   (uint8_t *)adev->psp.xgmi_context.context.bin_desc.start_addr +
+   le32_to_cpu(ta_hdr->ras.offset_bytes);
+
+   adev->psp.hdcp_context.context.bin_desc.fw_version =
+   le32_to_cpu(ta_hdr->hdcp.fw_version);
+   adev->psp.hdcp_context.context.bin_desc.size_bytes =
+   le32_to_cpu(ta_hdr->hdcp.size_bytes);
+   adev->psp.hdcp_context.context.bin_desc.start_addr =
+   (uint8_t *)ta_hdr +
+   le32_to_cpu(ta_hdr->header.ucode_array_offset_bytes);
+
+   adev->psp.dtm_context.context.bin_desc.fw_version =
+   le32_to_cpu(ta_hdr->dtm.fw_version);
+   adev->psp.dtm_context.context.bin_desc.size_bytes =
+   le32_to_cpu(ta_hdr->dtm.size_bytes);
+   adev->psp.dtm_context.context.bin_desc.start_addr =
+   (uint8_t *)adev->psp.hdcp_context.context.bin_desc.start_addr +
+   le32_to_cpu(ta_hdr->dtm.offset_bytes);
+
+   adev->psp.securedisplay_context.context.bin_desc.fw_version =
+   le32_to_cpu(ta_hdr->securedisplay.fw_version);
+   adev->psp.securedisplay_context.context.bin_desc.size_bytes =
+   le32_to_cpu(ta_hdr->securedisplay.size_bytes);
+   adev->psp.securedisplay_context.context.bin_desc.start_addr =
+   (uint8_t *)adev->psp.hdcp_context.context.bin_desc.start_addr +
+   le32_to_cpu(ta_hdr->securedisplay.offset_bytes);
+
+   adev->psp.ta_fw_version = le32_to_cpu(ta_hdr->header.ucode_version);
 
-   err = amdgpu_ucode_validate(adev->psp.ta_fw);
-   if (err)
-   goto out;
+   return 0;
+}
+
+static int parse_ta_v2_microcode(struct psp_context *psp)
+{
+   const struct ta_firmware_header_v2_0 *ta_hdr;
+   struct amdgpu_device *adev = psp->adev;
+   int err = 0;
+   int ta_index = 0;
 
ta_hdr = (const struct ta_firmware_header_v2_0 *)adev->psp.ta_fw->data;
 
-   if (le16_to_cpu(ta_hdr->header.header_version_major) != 2) {
-   dev_err(adev->dev, "unsupported TA header version\n");
-   err = -EINVAL;
-   goto out;
-   }
+   if (le16_to_cpu(ta_hdr->header.header_version_major) != 2)
+   return -EINVAL;
 
if (le32_to_cpu(ta_hdr->ta_fw_bin_count) >= UCODE_MAX_PSP_PACKAGING) {
   

[PATCH v7 22/45] drm/amd: Load PSP microcode during early_init

2023-01-05 Thread Mario Limonciello
Simplifies the code so that all PSP versions will get the firmware
name from `amdgpu_ucode_ip_version_decode` and then use this filename
to load microcode as part of the early_init process.

Any failures will cause the driver to fail to probe before the firmware
framebuffer has been removed.

Reviewed-by: Alex Deucher 
Reviewed-by: Lijo Lazar 
Signed-off-by: Mario Limonciello 
---
v6->v7:
 * rebase on earlier patches
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c  | 120 +--
 drivers/gpu/drm/amd/amdgpu/psp_v10_0.c   |  12 ---
 drivers/gpu/drm/amd/amdgpu/psp_v11_0.c   |  51 ++
 drivers/gpu/drm/amd/amdgpu/psp_v12_0.c   |  13 +--
 drivers/gpu/drm/amd/amdgpu/psp_v13_0.c   |  27 ++---
 drivers/gpu/drm/amd/amdgpu/psp_v13_0_4.c |  14 +--
 drivers/gpu/drm/amd/amdgpu/psp_v3_1.c|  16 +--
 7 files changed, 69 insertions(+), 184 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
index 8b2f1783f93b..73d67a4d0f5b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
@@ -122,6 +122,44 @@ static void 
psp_check_pmfw_centralized_cstate_management(struct psp_context *psp
}
 }
 
+static int psp_init_sriov_microcode(struct psp_context *psp)
+{
+   struct amdgpu_device *adev = psp->adev;
+   char ucode_prefix[30];
+   int ret = 0;
+
+   amdgpu_ucode_ip_version_decode(adev, MP0_HWIP, ucode_prefix, 
sizeof(ucode_prefix));
+
+   switch (adev->ip_versions[MP0_HWIP][0]) {
+   case IP_VERSION(9, 0, 0):
+   adev->virt.autoload_ucode_id = AMDGPU_UCODE_ID_CP_MEC2;
+   ret = psp_init_cap_microcode(psp, ucode_prefix);
+   break;
+   case IP_VERSION(11, 0, 9):
+   adev->virt.autoload_ucode_id = AMDGPU_UCODE_ID_CP_MEC2;
+   ret = psp_init_cap_microcode(psp, ucode_prefix);
+   break;
+   case IP_VERSION(11, 0, 7):
+   adev->virt.autoload_ucode_id = AMDGPU_UCODE_ID_CP_MEC2;
+   ret = psp_init_cap_microcode(psp, ucode_prefix);
+   break;
+   case IP_VERSION(13, 0, 2):
+   adev->virt.autoload_ucode_id = AMDGPU_UCODE_ID_CP_MEC2;
+   ret = psp_init_cap_microcode(psp, ucode_prefix);
+   ret &= psp_init_ta_microcode(psp, ucode_prefix);
+   break;
+   case IP_VERSION(13, 0, 0):
+   adev->virt.autoload_ucode_id = 0;
+   break;
+   case IP_VERSION(13, 0, 10):
+   adev->virt.autoload_ucode_id = AMDGPU_UCODE_ID_CP_MES1_DATA;
+   break;
+   default:
+   return -EINVAL;
+   }
+   return ret;
+}
+
 static int psp_early_init(void *handle)
 {
struct amdgpu_device *adev = (struct amdgpu_device *)handle;
@@ -192,7 +230,10 @@ static int psp_early_init(void *handle)
 
psp_check_pmfw_centralized_cstate_management(psp);
 
-   return 0;
+   if (amdgpu_sriov_vf(adev))
+   return psp_init_sriov_microcode(psp);
+   else
+   return psp_init_microcode(psp);
 }
 
 void psp_ta_free_shared_buf(struct ta_mem_context *mem_ctx)
@@ -350,42 +391,6 @@ static bool psp_get_runtime_db_entry(struct amdgpu_device 
*adev,
return ret;
 }
 
-static int psp_init_sriov_microcode(struct psp_context *psp)
-{
-   struct amdgpu_device *adev = psp->adev;
-   int ret = 0;
-
-   switch (adev->ip_versions[MP0_HWIP][0]) {
-   case IP_VERSION(9, 0, 0):
-   adev->virt.autoload_ucode_id = AMDGPU_UCODE_ID_CP_MEC2;
-   ret = psp_init_cap_microcode(psp, "vega10");
-   break;
-   case IP_VERSION(11, 0, 9):
-   adev->virt.autoload_ucode_id = AMDGPU_UCODE_ID_CP_MEC2;
-   ret = psp_init_cap_microcode(psp, "navi12");
-   break;
-   case IP_VERSION(11, 0, 7):
-   adev->virt.autoload_ucode_id = AMDGPU_UCODE_ID_CP_MEC2;
-   ret = psp_init_cap_microcode(psp, "sienna_cichlid");
-   break;
-   case IP_VERSION(13, 0, 2):
-   adev->virt.autoload_ucode_id = AMDGPU_UCODE_ID_CP_MEC2;
-   ret = psp_init_cap_microcode(psp, "aldebaran");
-   ret &= psp_init_ta_microcode(psp, "aldebaran");
-   break;
-   case IP_VERSION(13, 0, 0):
-   adev->virt.autoload_ucode_id = 0;
-   break;
-   case IP_VERSION(13, 0, 10):
-   adev->virt.autoload_ucode_id = AMDGPU_UCODE_ID_CP_MES1_DATA;
-   break;
-   default:
-   ret = -EINVAL;
-   break;
-   }
-   return ret;
-}
-
 static int psp_sw_init(void *handle)
 {
struct amdgpu_device *adev = (struct amdgpu_device *)handle;
@@ -401,15 +406,6 @@ static int psp_sw_init(void *handle)
ret = -ENOMEM;
}
 
-   if (amdgpu_sriov_vf(adev))
-   ret = psp_init_sriov_microcode(psp);
-   else
-   ret = 

[PATCH v7 29/45] drm/amd: Use `amdgpu_ucode_*` helpers for GFX6

2023-01-05 Thread Mario Limonciello
The `amdgpu_ucode_request` helper will ensure that the return code for
missing firmware is -ENODEV so that early_init can fail.

The `amdgpu_ucode_release` helper is for symmetry on unloading.

Reviewed-by: Alex Deucher 
Reviewed-by: Lijo Lazar 
Signed-off-by: Mario Limonciello 
---
v5->v6:
 * Adjust for amdgpu_ucode_release argument change
---
 drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c | 30 +++
 1 file changed, 8 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c
index 204b246f0e3f..438eab348fc8 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c
@@ -338,10 +338,7 @@ static int gfx_v6_0_init_microcode(struct amdgpu_device 
*adev)
}
 
snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_pfp.bin", chip_name);
-   err = request_firmware(>gfx.pfp_fw, fw_name, adev->dev);
-   if (err)
-   goto out;
-   err = amdgpu_ucode_validate(adev->gfx.pfp_fw);
+   err = amdgpu_ucode_request(adev, >gfx.pfp_fw, fw_name);
if (err)
goto out;
cp_hdr = (const struct gfx_firmware_header_v1_0 
*)adev->gfx.pfp_fw->data;
@@ -349,10 +346,7 @@ static int gfx_v6_0_init_microcode(struct amdgpu_device 
*adev)
adev->gfx.pfp_feature_version = 
le32_to_cpu(cp_hdr->ucode_feature_version);
 
snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_me.bin", chip_name);
-   err = request_firmware(>gfx.me_fw, fw_name, adev->dev);
-   if (err)
-   goto out;
-   err = amdgpu_ucode_validate(adev->gfx.me_fw);
+   err = amdgpu_ucode_request(adev, >gfx.me_fw, fw_name);
if (err)
goto out;
cp_hdr = (const struct gfx_firmware_header_v1_0 *)adev->gfx.me_fw->data;
@@ -360,10 +354,7 @@ static int gfx_v6_0_init_microcode(struct amdgpu_device 
*adev)
adev->gfx.me_feature_version = 
le32_to_cpu(cp_hdr->ucode_feature_version);
 
snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_ce.bin", chip_name);
-   err = request_firmware(>gfx.ce_fw, fw_name, adev->dev);
-   if (err)
-   goto out;
-   err = amdgpu_ucode_validate(adev->gfx.ce_fw);
+   err = amdgpu_ucode_request(adev, >gfx.ce_fw, fw_name);
if (err)
goto out;
cp_hdr = (const struct gfx_firmware_header_v1_0 *)adev->gfx.ce_fw->data;
@@ -371,10 +362,9 @@ static int gfx_v6_0_init_microcode(struct amdgpu_device 
*adev)
adev->gfx.ce_feature_version = 
le32_to_cpu(cp_hdr->ucode_feature_version);
 
snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_rlc.bin", chip_name);
-   err = request_firmware(>gfx.rlc_fw, fw_name, adev->dev);
+   err = amdgpu_ucode_request(adev, >gfx.rlc_fw, fw_name);
if (err)
goto out;
-   err = amdgpu_ucode_validate(adev->gfx.rlc_fw);
rlc_hdr = (const struct rlc_firmware_header_v1_0 
*)adev->gfx.rlc_fw->data;
adev->gfx.rlc_fw_version = le32_to_cpu(rlc_hdr->header.ucode_version);
adev->gfx.rlc_feature_version = 
le32_to_cpu(rlc_hdr->ucode_feature_version);
@@ -382,14 +372,10 @@ static int gfx_v6_0_init_microcode(struct amdgpu_device 
*adev)
 out:
if (err) {
pr_err("gfx6: Failed to load firmware \"%s\"\n", fw_name);
-   release_firmware(adev->gfx.pfp_fw);
-   adev->gfx.pfp_fw = NULL;
-   release_firmware(adev->gfx.me_fw);
-   adev->gfx.me_fw = NULL;
-   release_firmware(adev->gfx.ce_fw);
-   adev->gfx.ce_fw = NULL;
-   release_firmware(adev->gfx.rlc_fw);
-   adev->gfx.rlc_fw = NULL;
+   amdgpu_ucode_release(>gfx.pfp_fw);
+   amdgpu_ucode_release(>gfx.me_fw);
+   amdgpu_ucode_release(>gfx.ce_fw);
+   amdgpu_ucode_release(>gfx.rlc_fw);
}
return err;
 }
-- 
2.34.1



[PATCH v7 30/45] drm/amd: Use `amdgpu_ucode_*` helpers for GFX7

2023-01-05 Thread Mario Limonciello
The `amdgpu_ucode_request` helper will ensure that the return code for
missing firmware is -ENODEV so that early_init can fail.

The `amdgpu_ucode_release` helper is for symmetry on unloading.

Reviewed-by: Alex Deucher 
Reviewed-by: Lijo Lazar 
Signed-off-by: Mario Limonciello 
---
v5->v6:
 * Adjust for amdgpu_ucode_release argument change
---
 drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c | 68 +++
 1 file changed, 17 insertions(+), 51 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c
index 0f2976507e48..646999ad4f04 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c
@@ -887,6 +887,16 @@ static void gfx_v7_0_get_csb_buffer(struct amdgpu_device 
*adev, volatile u32 *bu
 static void gfx_v7_0_init_pg(struct amdgpu_device *adev);
 static void gfx_v7_0_get_cu_info(struct amdgpu_device *adev);
 
+static void gfx_v7_0_free_microcode(struct amdgpu_device *adev)
+{
+   amdgpu_ucode_release(>gfx.pfp_fw);
+   amdgpu_ucode_release(>gfx.me_fw);
+   amdgpu_ucode_release(>gfx.ce_fw);
+   amdgpu_ucode_release(>gfx.mec_fw);
+   amdgpu_ucode_release(>gfx.mec2_fw);
+   amdgpu_ucode_release(>gfx.rlc_fw);
+}
+
 /*
  * Core functions
  */
@@ -927,88 +937,44 @@ static int gfx_v7_0_init_microcode(struct amdgpu_device 
*adev)
}
 
snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_pfp.bin", chip_name);
-   err = request_firmware(>gfx.pfp_fw, fw_name, adev->dev);
-   if (err)
-   goto out;
-   err = amdgpu_ucode_validate(adev->gfx.pfp_fw);
+   err = amdgpu_ucode_request(adev, >gfx.pfp_fw, fw_name);
if (err)
goto out;
 
snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_me.bin", chip_name);
-   err = request_firmware(>gfx.me_fw, fw_name, adev->dev);
-   if (err)
-   goto out;
-   err = amdgpu_ucode_validate(adev->gfx.me_fw);
+   err = amdgpu_ucode_request(adev, >gfx.me_fw, fw_name);
if (err)
goto out;
 
snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_ce.bin", chip_name);
-   err = request_firmware(>gfx.ce_fw, fw_name, adev->dev);
-   if (err)
-   goto out;
-   err = amdgpu_ucode_validate(adev->gfx.ce_fw);
+   err = amdgpu_ucode_request(adev, >gfx.ce_fw, fw_name);
if (err)
goto out;
 
snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_mec.bin", chip_name);
-   err = request_firmware(>gfx.mec_fw, fw_name, adev->dev);
-   if (err)
-   goto out;
-   err = amdgpu_ucode_validate(adev->gfx.mec_fw);
+   err = amdgpu_ucode_request(adev, >gfx.mec_fw, fw_name);
if (err)
goto out;
 
if (adev->asic_type == CHIP_KAVERI) {
snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_mec2.bin", 
chip_name);
-   err = request_firmware(>gfx.mec2_fw, fw_name, adev->dev);
-   if (err)
-   goto out;
-   err = amdgpu_ucode_validate(adev->gfx.mec2_fw);
+   err = amdgpu_ucode_request(adev, >gfx.mec2_fw, fw_name);
if (err)
goto out;
}
 
snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_rlc.bin", chip_name);
-   err = request_firmware(>gfx.rlc_fw, fw_name, adev->dev);
+   err = amdgpu_ucode_request(adev, >gfx.rlc_fw, fw_name);
if (err)
goto out;
-   err = amdgpu_ucode_validate(adev->gfx.rlc_fw);
-
 out:
if (err) {
pr_err("gfx7: Failed to load firmware \"%s\"\n", fw_name);
-   release_firmware(adev->gfx.pfp_fw);
-   adev->gfx.pfp_fw = NULL;
-   release_firmware(adev->gfx.me_fw);
-   adev->gfx.me_fw = NULL;
-   release_firmware(adev->gfx.ce_fw);
-   adev->gfx.ce_fw = NULL;
-   release_firmware(adev->gfx.mec_fw);
-   adev->gfx.mec_fw = NULL;
-   release_firmware(adev->gfx.mec2_fw);
-   adev->gfx.mec2_fw = NULL;
-   release_firmware(adev->gfx.rlc_fw);
-   adev->gfx.rlc_fw = NULL;
+   gfx_v7_0_free_microcode(adev);
}
return err;
 }
 
-static void gfx_v7_0_free_microcode(struct amdgpu_device *adev)
-{
-   release_firmware(adev->gfx.pfp_fw);
-   adev->gfx.pfp_fw = NULL;
-   release_firmware(adev->gfx.me_fw);
-   adev->gfx.me_fw = NULL;
-   release_firmware(adev->gfx.ce_fw);
-   adev->gfx.ce_fw = NULL;
-   release_firmware(adev->gfx.mec_fw);
-   adev->gfx.mec_fw = NULL;
-   release_firmware(adev->gfx.mec2_fw);
-   adev->gfx.mec2_fw = NULL;
-   release_firmware(adev->gfx.rlc_fw);
-   adev->gfx.rlc_fw = NULL;
-}
-
 /**
  * gfx_v7_0_tiling_mode_table_init - init the hw tiling table
  *
-- 
2.34.1



[PATCH v7 21/45] drm/amd: Avoid BUG() for case of SRIOV missing IP version

2023-01-05 Thread Mario Limonciello
No need to crash the kernel.  AMDGPU will now fail to probe.

Reviewed-by: Alex Deucher 
Reviewed-by: Lijo Lazar 
Signed-off-by: Mario Limonciello 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
index bdc2bf87a286..8b2f1783f93b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
@@ -380,7 +380,7 @@ static int psp_init_sriov_microcode(struct psp_context *psp)
adev->virt.autoload_ucode_id = AMDGPU_UCODE_ID_CP_MES1_DATA;
break;
default:
-   BUG();
+   ret = -EINVAL;
break;
}
return ret;
-- 
2.34.1



  1   2   3   >