[linux-next:master] BUILD REGRESSION a35e92ef04c07bd473404b9b73d489aea19a60a8

2024-04-19 Thread kernel test robot
tree/branch: 
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: a35e92ef04c07bd473404b9b73d489aea19a60a8  Add linux-next specific 
files for 20240419

Error/Warning: (recently discovered and may have been fixed)

WARNING: modpost: vmlinux: section mismatch in reference: 
__io_uring_register+0x4e (section: .text) -> .L443 (section: .init.text)
WARNING: modpost: vmlinux: section mismatch in reference: add_master_key+0xcc 
(section: .text) -> .L443 (section: .init.text)
WARNING: modpost: vmlinux: section mismatch in reference: address_val+0x172 
(section: .text) -> .L443 (section: .init.text)
WARNING: modpost: vmlinux: section mismatch in reference: affine_move_task+0x7c 
(section: .text) -> .L443 (section: .init.text)
WARNING: modpost: vmlinux: section mismatch in reference: bcma_pmu_init+0x11c 
(section: .text) -> .LBE2162 (section: .init.text)
WARNING: modpost: vmlinux: section mismatch in reference: 
bitmap_list_string.isra.0+0x176 (section: .text) -> .L498 (section: .init.text)
WARNING: modpost: vmlinux: section mismatch in reference: 
bpf_cgroup_link_fill_link_info+0x18 (section: .text) -> .LBE2191 (section: 
.init.text)
WARNING: modpost: vmlinux: section mismatch in reference: 
bpf_map_meta_alloc+0x68 (section: .text) -> .L443 (section: .init.text)
WARNING: modpost: vmlinux: section mismatch in reference: bstr_printf+0x4c 
(section: .text) -> .L443 (section: .init.text)
WARNING: modpost: vmlinux: section mismatch in reference: 
cgroup1_reconfigure+0x6a (section: .text) -> .LBE2191 (section: .init.text)
WARNING: modpost: vmlinux: section mismatch in reference: 
cgroup_bpf_replace+0x18 (section: .text) -> .LBE2191 (section: .init.text)
WARNING: modpost: vmlinux: section mismatch in reference: 
class_srcu_destructor.isra.0+0x44 (section: .text) -> .L443 (section: 
.init.text)
WARNING: modpost: vmlinux: section mismatch in reference: 
cpu_cluster_pm_enter+0x36 (section: .text) -> .LBB2191 (section: .init.text)
WARNING: modpost: vmlinux: section mismatch in reference: dma_direct_mmap+0xf2 
(section: .text) -> .LVL129 (section: .init.text)
WARNING: modpost: vmlinux: section mismatch in reference: 
drm_atomic_helper_check_plane_state+0x80 (section: .text) -> .L443 (section: 
.init.text)
WARNING: modpost: vmlinux: section mismatch in reference: 
drm_crtc_vblank_helper_get_vblank_timestamp_internal+0x228 (section: .text) -> 
.LBE1217 (section: .init.text)
WARNING: modpost: vmlinux: section mismatch in reference: 
drm_of_component_probe+0xec (section: .text) -> .LVL1112 (section: .init.text)
WARNING: modpost: vmlinux: section mismatch in reference: 
drm_test_rect_rotate_inv+0x3c (section: .text) -> .LVL1139 (section: .init.text)
WARNING: modpost: vmlinux: section mismatch in reference: 
dw_hdmi_bridge_atomic_get_output_bus_fmts+0x80 (section: .text) -> .L443 
(section: .init.text)
WARNING: modpost: vmlinux: section mismatch in reference: 
gpiod_direction_input.part.0+0x2a (section: .text) -> .LVL1117 (section: 
.init.text)
WARNING: modpost: vmlinux: section mismatch in reference: 
gpiod_direction_output_raw_commit+0x40 (section: .text) -> .LVL1117 (section: 
.init.text)
WARNING: modpost: vmlinux: section mismatch in reference: 
gpiod_find_and_request+0x4e (section: .text) -> .LVL1117 (section: .init.text)
WARNING: modpost: vmlinux: section mismatch in reference: 
gpiod_get_direction+0x4e (section: .text) -> .L443 (section: .init.text)
WARNING: modpost: vmlinux: section mismatch in reference: gpiod_to_irq+0x48 
(section: .text) -> .L443 (section: .init.text)
WARNING: modpost: vmlinux: section mismatch in reference: 
gpiolib_seq_start+0x32 (section: .text) -> .L443 (section: .init.text)
WARNING: modpost: vmlinux: section mismatch in reference: gpiolib_seq_stop+0x4e 
(section: .text) -> .L443 (section: .init.text)
WARNING: modpost: vmlinux: section mismatch in reference: 
handle_new_recv_msgs+0x23a (section: .text) -> .LVL1117 (section: .init.text)
WARNING: modpost: vmlinux: section mismatch in reference: 
iio_compute_scan_bytes+0x5e (section: .text) -> .LVL1049 (section: .init.text)
WARNING: modpost: vmlinux: section mismatch in reference: 
iio_dev_attr_in_accel_scale_available+0x14 (section: .data) -> .LVL793 
(section: .init.text)
WARNING: modpost: vmlinux: section mismatch in reference: 
ipmi_get_maintenance_mode+0x8a (section: .text) -> .L443 (section: .init.text)
WARNING: modpost: vmlinux: section mismatch in reference: ipmi_get_my_LUN+0x82 
(section: .text) -> .L443 (section: .init.text)
WARNING: modpost: vmlinux: section mismatch in reference: 
ipmi_get_smi_info+0x32 (section: .text) -> .LVL1117 (section: .init.text)
WARNING: modpost: vmlinux: section mismatch in reference: 
ipmi_set_my_address+0x82 (section: .text) -> .L443 (section: .init.text)
WARNING: modpost: vmlinux: section mismatch in reference: ipmi_timeout+0x6c 
(section: .text) -> .LVL1117 (section: .ini

Re: Nouveau on a RISC-V SBC with Tesla K80? Supposed to not work or yes?

2024-04-19 Thread Ilia Mirkin
I don't think anyone was ever able to get their hands on a K80 to
confirm. It's a different ID than the GK110 (0xf0) / GK110B (0xf1). I
believe it's referred to as a GK210, but not sure if that's just a
marketing thing or if it's actually different.

You can try copying the 0xf1 entry in devinit and seeing what happens.

https://cgit.freedesktop.org/drm/drm/tree/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c#n3284

i.e. just add "case 0xf2: device->chip = &nvf1_chipset; break;"

However it does seem somewhat likely there would be additional
differences, so I wouldn't be extremely surprised if it didn't come up
without at least some extracted firmware (which we've never done for
that chipset).

Cheers,

  -ilia

On Fri, Apr 19, 2024 at 11:14 AM Raymond Wong  wrote:
>
> NOUVEAU MESSAGE :  {
> [ 47.314360] nouveau 0001:03:00.0: enabling device ( -> 0002)
>
> [ 47.314452] nouveau 0001:03:00.0: unknown chipset (0f22d0a1) [ 47.323897]
>
> pci 0001:02:10.0: enabling device ( -> 0002) [ 47.323938] nouveau 
> 0001:04:00.0: enabling device ( -> 0002)
>
> [ 47.324095] nouveau 0001:04:00.0: unknown chipset (0f22d0a1)
> }
>
> CONTEXT : {
> This thing belongs to someone else, but I'm playing with it. It is a 
> VisionFive 2 (a third one). It would seem like the PCIe implementation in 
> there is missing something that Navi 2s and 3s want. Therefore some Polaris 
> cards and Kepler cards are probably the best GPUs this SBC can run.
> Of course, it is two GPUs on a single PCIe 2.0 x1 lane using a riser. I see 
> that the Tesla K80 has it's own suspiciously incomplete line in the CodeNames 
> section. But nouveau reports unknown chipset when attempting to load drivers 
> onto the GPUs. Maybe it doesn't have the configuration for a Tesla K80 after 
> all?
> However, given Fishwaldo's 5.15.131 kernel is running on the SBC, I wonder if 
> Tesla K80 support has been added somewhere, But my roommates (myself 
> included) are combined all just too noob at googling to find it.
> }
>
> SYSTEM : {
> Board : VisionFive 2
> Kernel : 5.15.131 Fishwaldo using pine64-star64_defconfig
> Nouveau enabled using scripts/config -m CONFIG_DRM_NOUVEAU
> GPU : Tesla K80 dual GPU wanting to use nouveau drivers. One PCIe 2.0 x1 link 
> connects both GPUs.
> OS : Slackware ARM RISC-V (Full system, 16GB installed)
> Notes : It would appear that a GTX 750 Ti worked on another VisionFive 2, as 
> did a RX 550 on my Star64.
> }


Re: [PATCH] [v7] nouveau: add command-line GSP-RM registry support

2024-04-19 Thread Danilo Krummrich

Hi,

this patch targets drm-misc-next but depends on commit 838ae9f45c4e 
("nouveau/gsp:
Avoid addressing beyond end of rpc->entries") which is only in drm-misc-fixes.

Please let me know if you want to backmerge directly, let me hold the patch back
until or anything else.

- Danilo

On 4/17/24 23:53, Timur Tabi wrote:

Add the NVreg_RegistryDwords command line parameter, which allows
specifying additional registry keys to be sent to GSP-RM.  This
allows additional configuration, debugging, and experimentation
with GSP-RM, which uses these keys to alter its behavior.

Note that these keys are passed as-is to GSP-RM, and Nouveau does
not parse them.  This is in contrast to the Nvidia driver, which may
parse some of the keys to configure some functionality in concert with
GSP-RM.  Therefore, any keys which also require action by the driver
may not function correctly when passed by Nouveau.  Caveat emptor.

The name and format of NVreg_RegistryDwords is the same as used by
the Nvidia driver, to maintain compatibility.

Signed-off-by: Timur Tabi 
---
v7:
   rebase onto drm-misc-next
   rename vlen to alloc_size

  .../gpu/drm/nouveau/include/nvkm/subdev/gsp.h |   6 +
  .../gpu/drm/nouveau/nvkm/subdev/gsp/r535.c| 355 --
  2 files changed, 337 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/include/nvkm/subdev/gsp.h 
b/drivers/gpu/drm/nouveau/include/nvkm/subdev/gsp.h
index 6f5d376d8fcc..3fbc57b16a05 100644
--- a/drivers/gpu/drm/nouveau/include/nvkm/subdev/gsp.h
+++ b/drivers/gpu/drm/nouveau/include/nvkm/subdev/gsp.h
@@ -211,6 +211,12 @@ struct nvkm_gsp {
struct mutex mutex;;
struct idr idr;
} client_id;
+
+   /* A linked list of registry items. The registry RPC will be built from 
it. */
+   struct list_head registry_list;
+
+   /* The size of the registry RPC */
+   size_t registry_rpc_size;
  };
  
  static inline bool

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
index 9858c1438aa7..1b5d5b02c640 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
@@ -54,6 +54,8 @@
  #include 
  
  #include 

+#include 
+#include 
  
  #define GSP_MSG_MIN_SIZE GSP_PAGE_SIZE

  #define GSP_MSG_MAX_SIZE GSP_PAGE_MIN_SIZE * 16
@@ -1080,51 +1082,356 @@ r535_gsp_rpc_unloading_guest_driver(struct nvkm_gsp 
*gsp, bool suspend)
return nvkm_gsp_rpc_wr(gsp, rpc, true);
  }
  
+enum registry_type {

+   REGISTRY_TABLE_ENTRY_TYPE_DWORD  = 1, /* 32-bit unsigned integer */
+   REGISTRY_TABLE_ENTRY_TYPE_BINARY = 2, /* Binary blob */
+   REGISTRY_TABLE_ENTRY_TYPE_STRING = 3, /* Null-terminated string */
+};
+
+/* An arbitrary limit to the length of a registry key */
+#define REGISTRY_MAX_KEY_LENGTH64
+
+/**
+ * registry_list_entry - linked list member for a registry key/value
+ * @head: list_head struct
+ * @type: dword, binary, or string
+ * @klen: the length of name of the key
+ * @vlen: the length of the value
+ * @key: the key name
+ * @dword: the data, if REGISTRY_TABLE_ENTRY_TYPE_DWORD
+ * @binary: the data, if TYPE_BINARY or TYPE_STRING
+ *
+ * Every registry key/value is represented internally by this struct.
+ *
+ * Type DWORD is a simple 32-bit unsigned integer, and its value is stored in
+ * @dword.
+ *
+ * Types BINARY and STRING are variable-length binary blobs.  The only real
+ * difference between BINARY and STRING is that STRING is null-terminated and
+ * is expected to contain only printable characters.
+ *
+ * Note: it is technically possible to have multiple keys with the same name
+ * but different types, but this is not useful since GSP-RM expects keys to
+ * have only one specific type.
+ */
+struct registry_list_entry {
+   struct list_head head;
+   enum registry_type type;
+   size_t klen;
+   char key[REGISTRY_MAX_KEY_LENGTH];
+   size_t vlen;
+   u32 dword;  /* TYPE_DWORD */
+   u8 binary[] __counted_by(vlen); /* TYPE_BINARY or TYPE_STRING */
+};
+
+/**
+ * add_registry -- adds a registry entry
+ * @gsp: gsp pointer
+ * @key: name of the registry key
+ * @type: type of data
+ * @data: pointer to value
+ * @length: size of data, in bytes
+ *
+ * Adds a registry key/value pair to the registry database.
+ *
+ * This function collects the registry information in a linked list.  After
+ * all registry keys have been added, build_registry() is used to create the
+ * RPC data structure.
+ *
+ * registry_rpc_size is a running total of the size of all registry keys.
+ * It's used to avoid an O(n) calculation of the size when the RPC is built.
+ *
+ * Returns 0 on success, or negative error code on error.
+ */
+static int add_registry(struct nvkm_gsp *gsp, const char *key,
+   enum registry_type type, const void *data, size_t 
length)
+{
+   struct registry_list_entry *reg;
+   const size_t nlen

Re: [PATCH] [v5] nouveau: add command-line GSP-RM registry support

2024-04-19 Thread Danilo Krummrich

On 4/15/24 18:06, Timur Tabi wrote:

On Wed, 2024-04-10 at 13:30 +0200, Danilo Krummrich wrote:

On Tue, Apr 09, 2024 at 06:15:52PM -0500, Timur Tabi wrote:

Add the NVreg_RegistryDwords command line parameter, which allows
specifying additional registry keys to be sent to GSP-RM.  This
allows additional configuration, debugging, and experimentation
with GSP-RM, which uses these keys to alter its behavior.

Note that these keys are passed as-is to GSP-RM, and Nouveau does
not parse them.  This is in contrast to the Nvidia driver, which may
parse some of the keys to configure some functionality in concert with
GSP-RM.  Therefore, any keys which also require action by the driver
may not function correctly when passed by Nouveau.  Caveat emptor.

The name and format of NVreg_RegistryDwords is the same as used by
the Nvidia driver, to maintain compatibility.

Signed-off-by: Timur Tabi mailto:tt...@nvidia.com>>
---
v5:
Add REGISTRY_MAX_KEY_LENGTH
registry_list_entry.key is now char[64] instead of char *
use strnlen instead of strlen
removed some debug printks
fixed most checkpatch complaints
rebased to drm-fixes


This patch seems to be based on drm-misc-fixes instead. For this patch the
correct target branch would be drm-misc-next though.


Ok, but then you need to pick up Kees' patch "nouveau/gsp: Avoid addressing beyond end 
of rpc->entries" because I expect my patch to be applied on top of it.  That's why I 
chose that branch.


We can ask Maxime to backmerge.




You can, additionally, use '--base' when running git format-patch. This will
include the hash of the base commit.


I will take drm-misc-next, add Kees' patch, and rebase onto that.  I'll use 
--base but I'm not sure whether it will print something useful at this point.


Yeah, that sounds good.




+struct registry_list_entry {
+   struct list_head head;
+   enum registry_type type;
+   size_t klen;
+   size_t vlen;
+   char key[REGISTRY_MAX_KEY_LENGTH] __counted_by(klen);


Now that this is an array, we should remove the __counted_by() annotation.


Ok.


+   u32 dword;  /* TYPE_DWORD */
+   u8 binary[] __counted_by(vlen); /* TYPE_BINARY or TYPE_STRING */


NIT: Can't we put these two into a union?


Sure.


+static int add_registry(struct nvkm_gsp *gsp, const char *key,
+   enum registry_type type, const void *data, size_t 
length)
+{
+   struct registry_list_entry *reg;
+   size_t nlen = strnlen(key, REGISTRY_MAX_KEY_LENGTH) + 1;


Guess the only reason for strnlen() here is that you want to stop counting once
you exceed REGISTRY_MAX_KEY_LENGTH anyway, right?


Exactly.




+   size_t vlen; /* value length, non-zero if binary or string */
+
+   if (nlen > REGISTRY_MAX_KEY_LENGTH)
+   return -EFBIG;


Still prefer EINVAL, EFBIG doesn't really apply here.


I knew I was forgetting something.


+   vlen = (type == REGISTRY_TABLE_ENTRY_TYPE_DWORD) ? 0 : length;
+
+   reg = kmalloc(sizeof(*reg) + vlen, GFP_KERNEL);
+   if (!reg)
+   return -ENOMEM;
+
+   switch (type) {
+   case REGISTRY_TABLE_ENTRY_TYPE_DWORD:
+   reg->dword = *(const u32 *)(data);
+   break;
+   case REGISTRY_TABLE_ENTRY_TYPE_BINARY:
+   case REGISTRY_TABLE_ENTRY_TYPE_STRING:
+   memcpy(reg->binary, data, length);


Prefer to use vlen here...


I'll change it, but I think 'length' is more correct, since it's supposed to be 
the actual size of the data, whereas 'vlen' is just used to determine the size 
of the structure.  Especially since ...


Yes, I agree, length is the one to choose here. However, I wouldn't call it 
vlen,
but alloc_size or similar, since that's confusing.






+   break;
+   default:
+   nvkm_error(&gsp->subdev, "unrecognized registry type %u for 
'%s'\n",
+  type, key);
+   kfree(reg);
+   return -EINVAL;
+   }
+
+   memcpy(reg->key, key, nlen);
+   reg->klen = nlen;
+   reg->vlen = length;


...and here.


... it can't be vlen here because the value has to be '4' for dwords, and 
'vlen' is 0 for dwords.


That's even more confusing then. Please rename the local vlen variable.







Nouveau on a RISC-V SBC with Tesla K80? Supposed to not work or yes?

2024-04-19 Thread Raymond Wong
NOUVEAU MESSAGE :*  {*






*[ 47.314360] nouveau 0001:03:00.0: enabling device ( -> 0002)[
47.314452] nouveau 0001:03:00.0: unknown chipset (0f22d0a1) [ 47.323897]pci
0001:02:10.0: enabling device ( -> 0002) [ 47.323938] nouveau
0001:04:00.0: enabling device ( -> 0002)[ 47.324095] nouveau
0001:04:00.0: unknown chipset (0f22d0a1)*
}

CONTEXT : {
This thing belongs to someone else, but I'm playing with it. It is a
VisionFive 2 (a third one). It would seem like the PCIe implementation in
there is missing something that Navi 2s and 3s want. Therefore some Polaris
cards and Kepler cards are probably the best GPUs this SBC can run.
Of course, it is two GPUs on a single PCIe 2.0 x1 lane using a riser. I see
that the Tesla K80 has it's own suspiciously incomplete line in the
CodeNames section. But nouveau reports unknown chipset when attempting to
load drivers onto the GPUs. Maybe it doesn't have the configuration for a
Tesla K80 after all?
However, given Fishwaldo's 5.15.131 kernel is running on the SBC, I wonder
if Tesla K80 support has been added somewhere, But my roommates (myself
included) are combined all just too noob at googling to find it.
}

SYSTEM : {
Board : VisionFive 2
Kernel : 5.15.131 Fishwaldo using pine64-star64_defconfig
Nouveau enabled using scripts/config -m CONFIG_DRM_NOUVEAU
GPU : Tesla K80 dual GPU wanting to use nouveau drivers. One PCIe 2.0 x1
link connects both GPUs.
OS : Slackware ARM RISC-V (Full system, 16GB installed)
Notes : It would appear that a GTX 750 Ti worked on another VisionFive 2,
as did a RX 550 on my Star64.
}


Re: [PATCH v2 1/2] drm/print: drop include debugfs.h and include where needed

2024-04-19 Thread Robert Foss
Hey Jani,

Thanks for doing this cleanup.

On Thu, Apr 18, 2024 at 12:13 PM Jani Nikula  wrote:
>
> Surprisingly many places depend on debugfs.h to be included via
> drm_print.h. Fix them.
>
> v2: Also fix ivpu and vmwgfx
>
> Reviewed-by: Andrzej Hajda 
> Acked-by: Maxime Ripard 
> Link: 
> https://patchwork.freedesktop.org/patch/msgid/20240410141434.157908-1-jani.nik...@intel.com
> Signed-off-by: Jani Nikula 
>
> ---
>
> Cc: Jacek Lawrynowicz 
> Cc: Stanislaw Gruszka 
> Cc: Oded Gabbay 
> Cc: Andrzej Hajda 
> Cc: Neil Armstrong 
> Cc: Robert Foss 
> Cc: Laurent Pinchart 
> Cc: Jonas Karlman 
> Cc: Jernej Skrabec 
> Cc: Maarten Lankhorst 
> Cc: Maxime Ripard 
> Cc: Thomas Zimmermann 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Jani Nikula 
> Cc: Rodrigo Vivi 
> Cc: Joonas Lahtinen 
> Cc: Tvrtko Ursulin 
> Cc: Karol Herbst 
> Cc: Lyude Paul 
> Cc: Danilo Krummrich 
> Cc: Alex Deucher 
> Cc: "Christian König" 
> Cc: "Pan, Xinhui" 
> Cc: Huang Rui 
> Cc: Zack Rusin 
> Cc: Broadcom internal kernel review list 
> 
> Cc: dri-de...@lists.freedesktop.org
> Cc: intel-...@lists.freedesktop.org
> Cc: intel...@lists.freedesktop.org
> Cc: nouveau@lists.freedesktop.org
> Cc: amd-...@lists.freedesktop.org
> ---
>  drivers/accel/ivpu/ivpu_debugfs.c| 2 ++
>  drivers/gpu/drm/bridge/panel.c   | 2 ++
>  drivers/gpu/drm/drm_print.c  | 6 +++---
>  drivers/gpu/drm/i915/display/intel_dmc.c | 1 +
>  drivers/gpu/drm/nouveau/dispnv50/crc.c   | 2 ++
>  drivers/gpu/drm/radeon/r100.c| 1 +
>  drivers/gpu/drm/radeon/r300.c| 1 +
>  drivers/gpu/drm/radeon/r420.c| 1 +
>  drivers/gpu/drm/radeon/r600.c| 3 ++-
>  drivers/gpu/drm/radeon/radeon_fence.c| 1 +
>  drivers/gpu/drm/radeon/radeon_gem.c  | 1 +
>  drivers/gpu/drm/radeon/radeon_ib.c   | 2 ++
>  drivers/gpu/drm/radeon/radeon_pm.c   | 1 +
>  drivers/gpu/drm/radeon/radeon_ring.c | 2 ++
>  drivers/gpu/drm/radeon/radeon_ttm.c  | 1 +
>  drivers/gpu/drm/radeon/rs400.c   | 1 +
>  drivers/gpu/drm/radeon/rv515.c   | 1 +
>  drivers/gpu/drm/ttm/ttm_device.c | 1 +
>  drivers/gpu/drm/ttm/ttm_resource.c   | 3 ++-
>  drivers/gpu/drm/ttm/ttm_tt.c | 5 +++--
>  drivers/gpu/drm/vmwgfx/vmwgfx_gem.c  | 2 ++
>  include/drm/drm_print.h  | 2 +-
>  22 files changed, 34 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/accel/ivpu/ivpu_debugfs.c 
> b/drivers/accel/ivpu/ivpu_debugfs.c
> index d09d29775b3f..e07e447d08d1 100644
> --- a/drivers/accel/ivpu/ivpu_debugfs.c
> +++ b/drivers/accel/ivpu/ivpu_debugfs.c
> @@ -3,6 +3,8 @@
>   * Copyright (C) 2020-2023 Intel Corporation
>   */
>
> +#include 
> +
>  #include 
>  #include 
>  #include 
> diff --git a/drivers/gpu/drm/bridge/panel.c b/drivers/gpu/drm/bridge/panel.c
> index 7f41525f7a6e..32506524d9a2 100644
> --- a/drivers/gpu/drm/bridge/panel.c
> +++ b/drivers/gpu/drm/bridge/panel.c
> @@ -4,6 +4,8 @@
>   * Copyright (C) 2017 Broadcom
>   */
>
> +#include 
> +
>  #include 
>  #include 
>  #include 
> diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
> index 699b7dbffd7b..cf2efb44722c 100644
> --- a/drivers/gpu/drm/drm_print.c
> +++ b/drivers/gpu/drm/drm_print.c
> @@ -23,13 +23,13 @@
>   * Rob Clark 
>   */
>
> -#include 
> -
> +#include 
> +#include 
>  #include 
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>
>  #include 
>  #include 
> diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c 
> b/drivers/gpu/drm/i915/display/intel_dmc.c
> index a34ff3383fd3..370d61c7e342 100644
> --- a/drivers/gpu/drm/i915/display/intel_dmc.c
> +++ b/drivers/gpu/drm/i915/display/intel_dmc.c
> @@ -22,6 +22,7 @@
>   *
>   */
>
> +#include 
>  #include 
>
>  #include "i915_drv.h"
> diff --git a/drivers/gpu/drm/nouveau/dispnv50/crc.c 
> b/drivers/gpu/drm/nouveau/dispnv50/crc.c
> index 9c942fbd836d..5936b6b3b15d 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/crc.c
> +++ b/drivers/gpu/drm/nouveau/dispnv50/crc.c
> @@ -1,5 +1,7 @@
>  // SPDX-License-Identifier: MIT
> +#include 
>  #include 
> +
>  #include 
>  #include 
>  #include 
> diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
> index 86b8b770af19..0b1e19345f43 100644
> --- a/drivers/gpu/drm/radeon/r100.c
> +++ b/drivers/gpu/drm/radeon/r100.c
> @@ -26,6 +26,7 @@
>   *  Jerome Glisse
>   */
>
> +#include 
>  #include 
>  #include 
>  #include 
> diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c
> index 25201b9a5aae..1620f534f55f 100644
> --- a/drivers/gpu/drm/radeon/r300.c
> +++ b/drivers/gpu/drm/radeon/r300.c
> @@ -26,6 +26,7 @@
>   *  Jerome Glisse
>   */
>
> +#include 
>  #include 
>  #include 
>  #include 
> diff --git a/drivers/gpu/drm/radeon/r420.c b/drivers/gpu/drm/radeon/r420.c
> index eae8a6389f5e..a979662eaa73 100644
> --- a/drivers/gpu/drm/radeon/r420.c
> +++ b/drivers/gpu/drm/radeon/r420.c
> @@ -26,6 +26,7 @@
>   *  Jerome Glisse
>   */
>
> +#includ

[PATCH 025/156] drm/nouveau/nvkm: remove perfmon

2024-04-19 Thread Ben Skeggs
This has never really been used for anything, in part due to never
having reclocking stable enough in general to attempt to implement
dynamic clock changes based on load, etc.

To avoid having to rework its interfaces, remove it entirely.

Signed-off-by: Ben Skeggs 
---
 drivers/gpu/drm/nouveau/include/nvif/class.h  |   3 -
 drivers/gpu/drm/nouveau/include/nvif/if0002.h |  39 -
 drivers/gpu/drm/nouveau/include/nvif/if0003.h |  34 -
 .../drm/nouveau/include/nvkm/core/layout.h|   1 -
 .../gpu/drm/nouveau/include/nvkm/engine/pm.h  |  29 -
 drivers/gpu/drm/nouveau/nvkm/device/base.c|  82 --
 drivers/gpu/drm/nouveau/nvkm/device/priv.h|   1 -
 drivers/gpu/drm/nouveau/nvkm/device/user.c|   3 +-
 drivers/gpu/drm/nouveau/nvkm/engine/Kbuild|   1 -
 drivers/gpu/drm/nouveau/nvkm/engine/pm/Kbuild |  11 -
 drivers/gpu/drm/nouveau/nvkm/engine/pm/base.c | 867 --
 drivers/gpu/drm/nouveau/nvkm/engine/pm/g84.c  | 165 
 .../gpu/drm/nouveau/nvkm/engine/pm/gf100.c| 243 -
 .../gpu/drm/nouveau/nvkm/engine/pm/gf100.h|  20 -
 .../gpu/drm/nouveau/nvkm/engine/pm/gf108.c|  66 --
 .../gpu/drm/nouveau/nvkm/engine/pm/gf117.c|  80 --
 .../gpu/drm/nouveau/nvkm/engine/pm/gk104.c| 184 
 .../gpu/drm/nouveau/nvkm/engine/pm/gt200.c| 157 
 .../gpu/drm/nouveau/nvkm/engine/pm/gt215.c| 138 ---
 drivers/gpu/drm/nouveau/nvkm/engine/pm/nv40.c | 123 ---
 drivers/gpu/drm/nouveau/nvkm/engine/pm/nv40.h |  15 -
 drivers/gpu/drm/nouveau/nvkm/engine/pm/nv50.c | 175 
 drivers/gpu/drm/nouveau/nvkm/engine/pm/priv.h | 105 ---
 23 files changed, 1 insertion(+), 2541 deletions(-)
 delete mode 100644 drivers/gpu/drm/nouveau/include/nvif/if0002.h
 delete mode 100644 drivers/gpu/drm/nouveau/include/nvif/if0003.h
 delete mode 100644 drivers/gpu/drm/nouveau/include/nvkm/engine/pm.h
 delete mode 100644 drivers/gpu/drm/nouveau/nvkm/engine/pm/Kbuild
 delete mode 100644 drivers/gpu/drm/nouveau/nvkm/engine/pm/base.c
 delete mode 100644 drivers/gpu/drm/nouveau/nvkm/engine/pm/g84.c
 delete mode 100644 drivers/gpu/drm/nouveau/nvkm/engine/pm/gf100.c
 delete mode 100644 drivers/gpu/drm/nouveau/nvkm/engine/pm/gf100.h
 delete mode 100644 drivers/gpu/drm/nouveau/nvkm/engine/pm/gf108.c
 delete mode 100644 drivers/gpu/drm/nouveau/nvkm/engine/pm/gf117.c
 delete mode 100644 drivers/gpu/drm/nouveau/nvkm/engine/pm/gk104.c
 delete mode 100644 drivers/gpu/drm/nouveau/nvkm/engine/pm/gt200.c
 delete mode 100644 drivers/gpu/drm/nouveau/nvkm/engine/pm/gt215.c
 delete mode 100644 drivers/gpu/drm/nouveau/nvkm/engine/pm/nv40.c
 delete mode 100644 drivers/gpu/drm/nouveau/nvkm/engine/pm/nv40.h
 delete mode 100644 drivers/gpu/drm/nouveau/nvkm/engine/pm/nv50.c
 delete mode 100644 drivers/gpu/drm/nouveau/nvkm/engine/pm/priv.h

diff --git a/drivers/gpu/drm/nouveau/include/nvif/class.h 
b/drivers/gpu/drm/nouveau/include/nvif/class.h
index e668ab1664f0..824e052dcc25 100644
--- a/drivers/gpu/drm/nouveau/include/nvif/class.h
+++ b/drivers/gpu/drm/nouveau/include/nvif/class.h
@@ -7,9 +7,6 @@
 
 #define NVIF_CLASS_CONTROL   /* if0001.h */ -0x0001
 
-#define NVIF_CLASS_PERFMON   /* if0002.h */ -0x0002
-#define NVIF_CLASS_PERFDOM   /* if0003.h */ -0x0003
-
 #define NVIF_CLASS_SW_NV04   /* if0004.h */ -0x0004
 #define NVIF_CLASS_SW_NV10   /* if0005.h */ -0x0005
 #define NVIF_CLASS_SW_NV50   /* if0005.h */ -0x0006
diff --git a/drivers/gpu/drm/nouveau/include/nvif/if0002.h 
b/drivers/gpu/drm/nouveau/include/nvif/if0002.h
deleted file mode 100644
index df2915d6a61e..
--- a/drivers/gpu/drm/nouveau/include/nvif/if0002.h
+++ /dev/null
@@ -1,39 +0,0 @@
-/* SPDX-License-Identifier: MIT */
-#ifndef __NVIF_IF0002_H__
-#define __NVIF_IF0002_H__
-
-#define NVIF_PERFMON_V0_QUERY_DOMAIN   0x00
-#define NVIF_PERFMON_V0_QUERY_SIGNAL   0x01
-#define NVIF_PERFMON_V0_QUERY_SOURCE   0x02
-
-struct nvif_perfmon_query_domain_v0 {
-   __u8  version;
-   __u8  id;
-   __u8  counter_nr;
-   __u8  iter;
-   __u16 signal_nr;
-   __u8  pad05[2];
-   char  name[64];
-};
-
-struct nvif_perfmon_query_signal_v0 {
-   __u8  version;
-   __u8  domain;
-   __u16 iter;
-   __u8  signal;
-   __u8  source_nr;
-   __u8  pad05[2];
-   char  name[64];
-};
-
-struct nvif_perfmon_query_source_v0 {
-   __u8  version;
-   __u8  domain;
-   __u8  signal;
-   __u8  iter;
-   __u8  pad04[4];
-   __u32 source;
-   __u32 mask;
-   char  name[64];
-};
-#endif
diff --git a/drivers/gpu/drm/nouveau/include/nvif/if0003.h 
b/drivers/gpu/drm/nouveau/include/nvif/if0003.h
deleted file mode 100644
index 78467da07c37..
--- a/drivers/gpu/drm/nouveau/include/nvif/if0003.h
+++ /dev/null
@@ -1,34 +0,0 @@
-/* SP