Skip to content
Snippets Groups Projects
  1. Jan 28, 2025
  2. Jan 10, 2025
  3. Oct 01, 2024
    • Lucas De Marchi's avatar
      treewide: Fix intel_register_access_init() · f0ee2e62
      Lucas De Marchi authored
      
      In several places intel_register_access_init() is called with fd == -1
      as argument, even if it's passing a certain pci_dev, as e.g. the one
      returned by intel_get_pci_device().  Those don't actually operate for
      the same device. The fd is used for taking the forcewake, however if
      fd == -1, then it always use <debugfs>/dri/0, which is not correct.
      
      intel_get_pci_device() may not be the right function to use, but this
      can be fixed later - for now it will at least use the same pci device
      for taking the forcewake.
      
      For intel_reg,
      
      Before:
      $ # with runtime pm already taken
      $ sudo ./build/tools/intel_reg read 0x2358
                                          (0x00002358): 0x00000000
      $ # without runtime pm
      $ sudo ./build/tools/intel_reg read 0x2358
                                          (0x00002358): 0xffffffff
      
      After:
      $ sudo ./build/tools/intel_reg read 0x2358
                                          (0x00002358): 0xc3945002
      
      Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://lore.kernel.org/r/20240926041651.412396-4-lucas.demarchi@intel.com
      
      
      Signed-off-by: default avatarLucas De Marchi <lucas.demarchi@intel.com>
      f0ee2e62
  4. Jul 31, 2024
  5. Jul 26, 2024
  6. May 07, 2024
  7. Apr 10, 2024
    • Mauro Carvalho Chehab's avatar
      benchmarks: fix calloc calls with inverted arguments · 58ca03ee
      Mauro Carvalho Chehab authored
      
      The new gcc version 14 now complains when calloc is called
      with inverted arguments:
      
      	../benchmarks/gem_exec_reloc.c:85:31: warning: ‘calloc’ sizes specified with ‘sizeof’ in the earlier argument and not in the later argument [-Wcalloc-transposed-args]
      	   85 |         target = calloc(sizeof(*target), num_relocs);
      	      |                               ^
      	../benchmarks/gem_exec_reloc.c:85:31: note: earlier argument should specify number of elements, later size of each element
      
      Replace all occurrences of calloc that were warned on gcc 14 by
      placing the arguments at the right order.
      
      Logic fixed using this small python script, written specifically
      to catch gcc calloc warnings:
      
          #!/usr/bin/env python3
          import re
          warnings = [
          	"lib/igt_kms.c:2781",
          	"lib/igt_kms.c:2809",
          	"lib/igt_kms.c:2858",
          	"lib/igt_chamelium.c:156",
          	"lib/igt_chamelium.c:1519",
          	"tests/kms_atomic_transition.c:483",
          	"tests/kms_atomic_transition.c:485",
          	"tests/kms_atomic_transition.c:487",
          	"tests/kms_flip.c:426",
          	"tests/kms_flip.c:427",
          	"tests/intel/gem_exec_alignment.c:204",
          	"tests/intel/gem_exec_alignment.c:409",
          	"tests/intel/gem_exec_fair.c:1121",
          	"tests/intel/gem_exec_fair.c:1122",
          	"tests/intel/gem_fence_thrash.c:153",
          	"tests/intel/gem_fence_thrash.c:234",
          	"tests/intel/gem_ppgtt.c:432",
          	"tests/intel/gem_ppgtt.c:459",
          	"tests/intel/gem_render_tiled_blits.c:152",
          	"tests/intel/gem_userptr_blits.c:1433",
          	"tests/chamelium/kms_chamelium_frames.c:943",
          	"tests/amdgpu/amd_multidisplay_modeset.c:242",
          	"benchmarks/gem_exec_reloc.c:83",
          	"benchmarks/gem_exec_reloc.c:84",
          	"benchmarks/gem_exec_reloc.c:85",
          	"benchmarks/gem_latency.c:196",
          	"assembler/main.c:400",
          	"assembler/gram.y:219",
          	"assembler/gram.y:231",
          	"assembler/gram.y:242",
          ]
          split_file = re.compile(r"([^\:]+):(\d+)")
          calloc = re.compile(r"(calloc\s*\()(.*)\,\s*([\w\d\ \+\*\-\>]+)(\))")
          for f in warnings:
              match = split_file.match(f)
              if not match:
                  continue
              fname = match.group(1)
              line_number = int(match.group(2))
              new = ""
              with open(fname, 'r', encoding = 'utf8') as fp:
                  for ln, line in enumerate(fp):
                      if ln + 1 == line_number:
                          new_line = calloc.sub(r"\1\3, \2\4", line)
                          if new_line != line:
                              line = new_line
                          else:
                              print(f"{fname}, line {line_number}: FAILED: {line.strip()}")
                      new += line
              with open(fname, 'w', encoding = 'utf8') as fp:
                  fp.write(new)
      
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@kernel.org>
      Reviewed-by: default avatarKamil Konieczny <kamil.konieczny@linux.intel.com>
      58ca03ee
  8. Mar 04, 2024
  9. Feb 14, 2024
  10. Jan 26, 2024
  11. Dec 15, 2023
  12. Dec 11, 2023
  13. Dec 05, 2023
  14. Nov 27, 2023
    • Marcin Bernatowicz's avatar
      benchmarks/gem_wsim: introduce bb_size field · 357e38a0
      Marcin Bernatowicz authored and Kamil Konieczny's avatar Kamil Konieczny committed
      
      In certain scenarios (ATS-M when using LMEM), PAGE_SIZE=4096
      is insufficient for Xe, necessitating alignment considerations.
      This change ensures that 'bb_size' aligns properly,
      preventing VM BIND failures in cases where the size is not aligned
      to the minimum page size of the region.
      
      Additionally, 'alloc_bo' for i915 has been updated to
      accommodate page-aligned allocated size.
      
      v2: Reverted to intel_allocator_alloc_with_strategy as not related
          to the change and for clarity due to its origin in a library
          rather than local definition. (Tvrtko)
      
      Signed-off-by: default avatarMarcin Bernatowicz <marcin.bernatowicz@intel.com>
      Reviewed-by: default avatarLukasz Laguna <lukasz.laguna@intel.com>
      357e38a0
  15. Nov 17, 2023
  16. Oct 17, 2023
  17. Oct 10, 2023
Loading