1. 09 Jun, 2022 12 commits
  2. 08 Jun, 2022 8 commits
    • Christophe Leroy's avatar
      drm/nouveau/bios: Rename prom_init() and friends functions · 6aed665f
      Christophe Leroy authored
      While working at fixing powerpc headers, I ended up with the
      following error.
      
      	drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowrom.c:48:1: error: conflicting types for 'prom_init'; have 'void *(struct nvkm_bios *, const char *)'
      	make[5]: *** [scripts/Makefile.build:288: drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowrom.o] Error 1
      
      powerpc and a few other architectures have a prom_init() global function.
      One day or another it will conflict with the one in shadowrom.c
      
      Those being static, they can easily be renamed. Do it.
      
      While at it, also rename the ops structure as 'nvbios_prom' instead of
      'nvbios_rom' in order to make it clear that it refers to the
      NV_PROM device.
      Signed-off-by: default avatarChristophe Leroy <christophe.leroy@csgroup.eu>
      Reviewed-by: default avatarLyude Paul <lyude@redhat.com>
      Signed-off-by: default avatarLyude Paul <lyude@redhat.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/7e0612b61511ec8030e3b2dcbfaa7751781c8b91.1647684507.git.christophe.leroy@csgroup.eu
      6aed665f
    • Joel Selvaraj's avatar
    • Joel Selvaraj's avatar
      drm/panel: nt36672a: add backlight support · c11256f8
      Joel Selvaraj authored
      Add support for backlight. This panel supports backlight control
      through the QCOM WLED driver in Xiaomi Poco F1 device.
      Signed-off-by: default avatarJoel Selvaraj <jo@jsfamily.in>
      Reviewed-by: default avatarMarijn Suijten <marijn.suijten@somainline.org>
      Signed-off-by: default avatarSumit Semwal <sumit.semwal@linaro.org>
      Link: https://patchwork.freedesktop.org/patch/msgid/BY5PR02MB700935F5817128CB7C3991CDD9E09@BY5PR02MB7009.namprd02.prod.outlook.com
      c11256f8
    • Geert Uytterhoeven's avatar
      fbcon: Remove obsolete reference to initmem_freed · 514c6204
      Geert Uytterhoeven authored
      initmem_freed was removed in v2.1.124, and the underlying issue was
      fixed for good in commit 92b004d1 ("video/logo: prevent use of
      logos after they have been freed").
      Signed-off-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: https://patchwork.freedesktop.org/patch/msgid/b8b9147a48e233fe32e072f2085c7b413cd92a00.1654702835.git.geert+renesas@glider.be
      514c6204
    • Daniel Thompson's avatar
      drm/cma-helper: Describe what a "contiguous chunk" actually means · faa406f4
      Daniel Thompson authored
      Since it's inception in 2012 it has been understood that the DRM GEM CMA
      helpers do not depend on CMA as the backend allocator. In fact the first
      bug fix to ensure the cma-helpers work correctly with an IOMMU backend
      appeared in 2014. However currently the documentation for
      drm_gem_cma_create() talks about "a contiguous chunk of memory" without
      making clear which address space it will be a contiguous part of.
      Additionally the CMA introduction is actively misleading because it only
      contemplates the CMA backend.
      
      This matters because when the device accesses the bus through an IOMMU
      (and don't use the CMA backend) then the allocated memory is contiguous
      only in the IOVA space. This is a significant difference compared to the
      CMA backend and the behaviour can be a surprise even to someone who does
      a reasonable level of code browsing (but doesn't find all the relevant
      function pointers ;-) ).
      
      Improve the kernel doc comments accordingly.
      Signed-off-by: default avatarDaniel Thompson <daniel.thompson@linaro.org>
      Reviewed-by: default avatarLucas Stach <l.stach@pengutronix.de>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: https://patchwork.freedesktop.org/patch/msgid/20220608135821.1153346-1-daniel.thompson@linaro.org
      faa406f4
    • Jason Ekstrand's avatar
      dma-buf: Add an API for importing sync files (v10) · 59474049
      Jason Ekstrand authored
      This patch is analogous to the previous sync file export patch in that
      it allows you to import a sync_file into a dma-buf.  Unlike the previous
      patch, however, this does add genuinely new functionality to dma-buf.
      Without this, the only way to attach a sync_file to a dma-buf is to
      submit a batch to your driver of choice which waits on the sync_file and
      claims to write to the dma-buf.  Even if said batch is a no-op, a submit
      is typically way more overhead than just attaching a fence.  A submit
      may also imply extra synchronization with other work because it happens
      on a hardware queue.
      
      In the Vulkan world, this is useful for dealing with the out-fence from
      vkQueuePresent.  Current Linux window-systems (X11, Wayland, etc.) all
      rely on dma-buf implicit sync.  Since Vulkan is an explicit sync API, we
      get a set of fences (VkSemaphores) in vkQueuePresent and have to stash
      those as an exclusive (write) fence on the dma-buf.  We handle it in
      Mesa today with the above mentioned dummy submit trick.  This ioctl
      would allow us to set it directly without the dummy submit.
      
      This may also open up possibilities for GPU drivers to move away from
      implicit sync for their kernel driver uAPI and instead provide sync
      files and rely on dma-buf import/export for communicating with other
      implicit sync clients.
      
      We make the explicit choice here to only allow setting RW fences which
      translates to an exclusive fence on the dma_resv.  There's no use for
      read-only fences for communicating with other implicit sync userspace
      and any such attempts are likely to be racy at best.  When we got to
      insert the RW fence, the actual fence we set as the new exclusive fence
      is a combination of the sync_file provided by the user and all the other
      fences on the dma_resv.  This ensures that the newly added exclusive
      fence will never signal before the old one would have and ensures that
      we don't break any dma_resv contracts.  We require userspace to specify
      RW in the flags for symmetry with the export ioctl and in case we ever
      want to support read fences in the future.
      
      There is one downside here that's worth documenting:  If two clients
      writing to the same dma-buf using this API race with each other, their
      actions on the dma-buf may happen in parallel or in an undefined order.
      Both with and without this API, the pattern is the same:  Collect all
      the fences on dma-buf, submit work which depends on said fences, and
      then set a new exclusive (write) fence on the dma-buf which depends on
      said work.  The difference is that, when it's all handled by the GPU
      driver's submit ioctl, the three operations happen atomically under the
      dma_resv lock.  If two userspace submits race, one will happen before
      the other.  You aren't guaranteed which but you are guaranteed that
      they're strictly ordered.  If userspace manages the fences itself, then
      these three operations happen separately and the two render operations
      may happen genuinely in parallel or get interleaved.  However, this is a
      case of userspace racing with itself.  As long as we ensure userspace
      can't back the kernel into a corner, it should be fine.
      
      v2 (Jason Ekstrand):
       - Use a wrapper dma_fence_array of all fences including the new one
         when importing an exclusive fence.
      
      v3 (Jason Ekstrand):
       - Lock around setting shared fences as well as exclusive
       - Mark SIGNAL_SYNC_FILE as a read-write ioctl.
       - Initialize ret to 0 in dma_buf_wait_sync_file
      
      v4 (Jason Ekstrand):
       - Use the new dma_resv_get_singleton helper
      
      v5 (Jason Ekstrand):
       - Rename the IOCTLs to import/export rather than wait/signal
       - Drop the WRITE flag and always get/set the exclusive fence
      
      v6 (Jason Ekstrand):
       - Split import and export into separate patches
       - New commit message
      
      v7 (Daniel Vetter):
       - Fix the uapi header to use the right struct in the ioctl
       - Use a separate dma_buf_import_sync_file struct
       - Add kerneldoc for dma_buf_import_sync_file
      
      v8 (Jason Ekstrand):
       - Rebase on Christian König's fence rework
      
      v9 (Daniel Vetter):
       - Fix -EINVAL checks for the flags parameter
       - Add documentation about read/write fences
       - Add documentation about the expected usage of import/export and
         specifically call out the possible userspace race.
      
      v10 (Simon Ser):
       - Fix a typo in the docs
      Signed-off-by: default avatarJason Ekstrand <jason@jlekstrand.net>
      Signed-off-by: default avatarJason Ekstrand <jason.ekstrand@intel.com>
      Signed-off-by: default avatarJason Ekstrand <jason.ekstrand@collabora.com>
      Reviewed-by: default avatarChristian König <christian.koenig@amd.com>
      Reviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Sumit Semwal <sumit.semwal@linaro.org>
      Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Signed-off-by: default avatarSimon Ser <contact@emersion.fr>
      Link: https://patchwork.freedesktop.org/patch/msgid/20220608152142.14495-3-jason@jlekstrand.net
      59474049
    • Jason Ekstrand's avatar
      dma-buf: Add an API for exporting sync files (v14) · 20e10881
      Jason Ekstrand authored
      Modern userspace APIs like Vulkan are built on an explicit
      synchronization model.  This doesn't always play nicely with the
      implicit synchronization used in the kernel and assumed by X11 and
      Wayland.  The client -> compositor half of the synchronization isn't too
      bad, at least on intel, because we can control whether or not i915
      synchronizes on the buffer and whether or not it's considered written.
      
      The harder part is the compositor -> client synchronization when we get
      the buffer back from the compositor.  We're required to be able to
      provide the client with a VkSemaphore and VkFence representing the point
      in time where the window system (compositor and/or display) finished
      using the buffer.  With current APIs, it's very hard to do this in such
      a way that we don't get confused by the Vulkan driver's access of the
      buffer.  In particular, once we tell the kernel that we're rendering to
      the buffer again, any CPU waits on the buffer or GPU dependencies will
      wait on some of the client rendering and not just the compositor.
      
      This new IOCTL solves this problem by allowing us to get a snapshot of
      the implicit synchronization state of a given dma-buf in the form of a
      sync file.  It's effectively the same as a poll() or I915_GEM_WAIT only,
      instead of CPU waiting directly, it encapsulates the wait operation, at
      the current moment in time, in a sync_file so we can check/wait on it
      later.  As long as the Vulkan driver does the sync_file export from the
      dma-buf before we re-introduce it for rendering, it will only contain
      fences from the compositor or display.  This allows to accurately turn
      it into a VkFence or VkSemaphore without any over-synchronization.
      
      By making this an ioctl on the dma-buf itself, it allows this new
      functionality to be used in an entirely driver-agnostic way without
      having access to a DRM fd. This makes it ideal for use in driver-generic
      code in Mesa or in a client such as a compositor where the DRM fd may be
      hard to reach.
      
      v2 (Jason Ekstrand):
       - Use a wrapper dma_fence_array of all fences including the new one
         when importing an exclusive fence.
      
      v3 (Jason Ekstrand):
       - Lock around setting shared fences as well as exclusive
       - Mark SIGNAL_SYNC_FILE as a read-write ioctl.
       - Initialize ret to 0 in dma_buf_wait_sync_file
      
      v4 (Jason Ekstrand):
       - Use the new dma_resv_get_singleton helper
      
      v5 (Jason Ekstrand):
       - Rename the IOCTLs to import/export rather than wait/signal
       - Drop the WRITE flag and always get/set the exclusive fence
      
      v6 (Jason Ekstrand):
       - Drop the sync_file import as it was all-around sketchy and not nearly
         as useful as import.
       - Re-introduce READ/WRITE flag support for export
       - Rework the commit message
      
      v7 (Jason Ekstrand):
       - Require at least one sync flag
       - Fix a refcounting bug: dma_resv_get_excl() doesn't take a reference
       - Use _rcu helpers since we're accessing the dma_resv read-only
      
      v8 (Jason Ekstrand):
       - Return -ENOMEM if the sync_file_create fails
       - Predicate support on IS_ENABLED(CONFIG_SYNC_FILE)
      
      v9 (Jason Ekstrand):
       - Add documentation for the new ioctl
      
      v10 (Jason Ekstrand):
       - Go back to dma_buf_sync_file as the ioctl struct name
      
      v11 (Daniel Vetter):
       - Go back to dma_buf_export_sync_file as the ioctl struct name
       - Better kerneldoc describing what the read/write flags do
      
      v12 (Christian König):
       - Document why we chose to make it an ioctl on dma-buf
      
      v13 (Jason Ekstrand):
       - Rebase on Christian König's fence rework
      
      v14 (Daniel Vetter & Christian König):
       - Use dma_rev_usage_rw to get the properly inverted usage to pass to
         dma_resv_get_singleton()
       - Clean up the sync_file and fd if copy_to_user() fails
      Signed-off-by: default avatarJason Ekstrand <jason@jlekstrand.net>
      Signed-off-by: default avatarJason Ekstrand <jason.ekstrand@intel.com>
      Signed-off-by: default avatarJason Ekstrand <jason.ekstrand@collabora.com>
      Acked-by: default avatarSimon Ser <contact@emersion.fr>
      Reviewed-by: default avatarChristian König <christian.koenig@amd.com>
      Reviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Sumit Semwal <sumit.semwal@linaro.org>
      Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Signed-off-by: default avatarSimon Ser <contact@emersion.fr>
      Link: https://patchwork.freedesktop.org/patch/msgid/20220608152142.14495-2-jason@jlekstrand.net
      20e10881
    • Thomas Zimmermann's avatar
      drm/ast: Support multiple outputs · 7f35680a
      Thomas Zimmermann authored
      Systems with AST graphics can have multiple output; typically VGA
      plus some other port. Record detected output chips in a bitmask and
      initialize each output on its own.
      
      Assume a VGA output by default and use SIL164 and DP501 if available.
      For ASTDP assume that it can run in parallel with VGA.
      
      Tested on AST2100.
      
      v3:
      	* define a macro for each BIT(ast_tx_chip) (Patrik)
      v2:
      	* make VGA/SIL164/DP501 mutually exclusive
      Signed-off-by: default avatarThomas Zimmermann <tzimmermann@suse.de>
      Reviewed-by: default avatarPatrik Jakobsson <patrik.r.jakobsson@gmail.com>
      Fixes: a59b0264 ("drm/ast: Initialize encoder and connector for VGA in helper function")
      Cc: Thomas Zimmermann <tzimmermann@suse.de>
      Cc: Javier Martinez Canillas <javierm@redhat.com>
      Cc: Dave Airlie <airlied@redhat.com>
      Cc: dri-devel@lists.freedesktop.org
      Link: https://patchwork.freedesktop.org/patch/msgid/20220607092008.22123-2-tzimmermann@suse.de
      7f35680a
  3. 07 Jun, 2022 13 commits
  4. 06 Jun, 2022 1 commit
  5. 03 Jun, 2022 2 commits
  6. 02 Jun, 2022 4 commits