Skip to content
Snippets Groups Projects
  1. Feb 08, 2023
  2. Jan 03, 2023
  3. Dec 21, 2022
    • Simon Ser's avatar
      xf86drm: fix warning in drmGetFormatModifierNameFromVivante() · 64d6faba
      Simon Ser authored
      
      Fixes the following warning:
      
          ../xf86drm.c: In function ‘drmGetFormatModifierNameFromVivante’:
          ../xf86drm.c:614:14: warning: passing argument 1 of ‘asprintf’ from incompatible pointer type [-Wincompatible-pointer-types]
            614 |     asprintf(&mod_vivante, "%s%s%s", color_tiling, tile_status, compression);
                |              ^~~~~~~~~~~~
                |              |
                |              const char **
          In file included from ../xf86drm.c:34:
          /usr/include/stdio.h:396:40: note: expected ‘char ** restrict’ but argument is of type ‘const char **’
            396 | extern int asprintf (char **__restrict __ptr,
                |                      ~~~~~~~~~~~~~~~~~~^~~~~
          ../xf86drm.c:615:12: warning: return discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers]
            615 |     return mod_vivante;
                |            ^~~~~~~~~~~
      
      Signed-off-by: Simon Ser's avatarSimon Ser <contact@emersion.fr>
      64d6faba
  4. Nov 30, 2022
  5. Nov 23, 2022
    • Matt Roper's avatar
      intel: Eliminate need to keep adding PCI IDs · 07dae1d1
      Matt Roper authored
      
      The Intel-specific code in libdrm is continually updated with new PCI
      IDs for each new platform so that we can recognize the IP version
      properly.  However this is mostly a pointless exercise; none of the
      Intel code in libdrm is conditional on IP versions above 8.  If we just
      treat any future unrecognized Intel platforms as IP version 8, we should
      get the same behavior without the need for continued PCI ID updates.
      
      Note that the intel_decode tool probably _should_ have conditions on
      newer IP versions, but it was last updated for gen8 and has been
      bitrotting from gen9 onward.  This change won't make the tool behave any
      more incorrectly than it already does today.
      
      Cc: Lucas De Marchi <lucas.demarchi@intel.com>
      Signed-off-by: default avatarMatt Roper <matthew.d.roper@intel.com>
      07dae1d1
  6. Nov 11, 2022
  7. Nov 09, 2022
  8. Nov 03, 2022
  9. Nov 02, 2022
  10. Oct 27, 2022
    • Simon Ser's avatar
      xf86drmMode: add helpers for dumb buffers · 3be3b1a8
      Simon Ser authored
      
      Up until now, DRM clients had to hand-roll their code to create,
      destroy and map dumb buffers. This is slightly inconvenient,
      a bit error-prone, and not easily discoverable.
      
      Introduce wrappers for these operations, just like we have for
      other KMS IOCTLs.
      
      Signed-off-by: Simon Ser's avatarSimon Ser <contact@emersion.fr>
      3be3b1a8
  11. Oct 23, 2022
    • Simon Ser's avatar
      amdgpu: silence uninitialized variable warning · 82b2b1e8
      Simon Ser authored
      
      The compiler isn't smart enough to tell that this can't happen:
      
          [30/74] Compiling C object amdgpu/libdrm_amdgpu.so.1.0.0.p/amdgpu_bo.c.o
          In file included from ../amdgpu/amdgpu_internal.h:32,
                           from ../amdgpu/amdgpu_bo.c:39:
          ../xf86atomic.h: In function ‘amdgpu_find_bo_by_cpu_mapping’:
          ../xf86atomic.h:47:54: warning: ‘bo’ may be used uninitialized [-Wmaybe-uninitialized]
             47 | # define atomic_inc(x) ((void) __sync_fetch_and_add (&(x)->atomic, 1))
                |                                                      ^
          ../amdgpu/amdgpu_bo.c:536:27: note: ‘bo’ was declared here
            536 |         struct amdgpu_bo *bo;
                |                           ^~
      
      Signed-off-by: Simon Ser's avatarSimon Ser <contact@emersion.fr>
      Reviewed-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      82b2b1e8
  12. Oct 17, 2022
  13. Oct 06, 2022
  14. Oct 03, 2022
  15. Sep 29, 2022
  16. Sep 11, 2022
  17. Aug 31, 2022
  18. Aug 30, 2022
    • Matt Roper's avatar
      intel: Hook up new platforms IDs · 03e0ab4d
      Matt Roper authored
      In commit 98794e2a ("lib: sync i915_pciids.h with kernel") we
      resynchronized the PCI header with the kernel to bring in the
      definitions for several new platforms.  But before those IDs will be
      recognized, we still need to hook them up in the libdrm chipset code as
      well.
      
      References: https://gitlab.freedesktop.org/drm/intel/-/issues/5416
      
      
      Signed-off-by: default avatarMatt Roper <matthew.d.roper@intel.com>
      03e0ab4d
    • Sui Jingfeng's avatar
      meson: auto-enable etnaviv on arm, arc, mips and loongarch architectures · 33f0009d
      Sui Jingfeng authored and Eric Engestrom's avatar Eric Engestrom committed
      There is a Vivante GC1000 gpu in LS2K1000 and LS7A1000.
      
      LS7A1000 is a bridge chip made by Loongson corporation
      which act as north and/or south bridge of loongson's
      desktop and server level processor. It is equivalent
      to RS780E or something like that. In fact, the company
      use RS780E as bridge of LS3A3000 at its early stage,
      but as RS780E is out of stock long long time ago, the
      company have to made one by themself. More details can
      be read from its user manual[1].
      
      This bridge chip typically use with LS3A3000, LS3A4000
      and LS3A5000.
      
      LS3A3000 is 4 core 1.45gHz mips64r2 compatible cpu.
      LS3A4000 is 4 core 1.8gHz mips64r5 compatible cpu.
      LS3A5000 is 4 core 2.5gHz loongarch cpu, the company
      acclaim that loongarch a new archtecture with its
      instruction set is released[2].
      
      LS2K1000 is a double core 1.0Ghz mips64r2 compatible SoC[3].
      
      we need to enable it to test and developing driver on above
      listed archtecture.
      
      [1] https://loongson.githu...
      33f0009d
  19. Aug 23, 2022
  20. Aug 22, 2022
Loading