Skip to content
  1. Apr 15, 2021
    • Daniel Vetter's avatar
      drm/imx: Don't set allow_fb_modifiers explicitly · 0d113754
      Daniel Vetter authored 
      Since

commit 890880dd


Author: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Date:   Fri Jan 4 09:56:10 2019 +0100

    drm: Auto-set allow_fb_modifiers when given modifiers at plane init

this is done automatically as part of plane init, if drivers set the
modifier list correctly. Which is the case here for both dcss and
imx-drm drivers.

Reviewed-by: default avatarLucas Stach <l.stach@pengutronix.de>
Signed-off-by: default avatarDaniel Vetter <daniel.vetter@intel.com>
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: NXP Linux Team <linux-imx@nxp.com>
Cc: linux-arm-kernel@lists.infradead.org
Link: https://patchwork.freedesktop.org/patch/msgid/20210413094904.3736372-5-daniel.vetter@ffwll.ch
      0d113754
    • Daniel Vetter's avatar
      drm/vc4: Don't set allow_fb_modifiers explicitly · 53d68269
      Daniel Vetter authored 
      Since

commit 890880dd


Author: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Date:   Fri Jan 4 09:56:10 2019 +0100

    drm: Auto-set allow_fb_modifiers when given modifiers at plane init

this is done automatically as part of plane init, if drivers set the
modifier list correctly. Which is the case here.

Acked-by: default avatarMaxime Ripard <maxime@cerno.tech>
Signed-off-by: default avatarDaniel Vetter <daniel.vetter@intel.com>
Cc: Eric Anholt <eric@anholt.net>
Cc: Maxime Ripard <mripard@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210413094904.3736372-11-daniel.vetter@ffwll.ch
      53d68269
    • Daniel Vetter's avatar
      drm/tegra: Don't set allow_fb_modifiers explicitly · be4306ad
      Daniel Vetter authored 
      Since

commit 890880dd


Author: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Date:   Fri Jan 4 09:56:10 2019 +0100

    drm: Auto-set allow_fb_modifiers when given modifiers at plane init

this is done automatically as part of plane init, if drivers set the
modifier list correctly. Which is the case here.

It was slightly inconsistently though, since planes with only linear
modifier support haven't listed that explicitly. Fix that, and cc:
stable to allow userspace to rely on this. Again don't backport
further than where Paul's patch got added.

Cc: stable@vger.kernel.org # v5.1 +
Cc: Pekka Paalanen <pekka.paalanen@collabora.com>
Acked-by: default avatarThierry Reding <treding@nvidia.com>
Signed-off-by: default avatarDaniel Vetter <daniel.vetter@intel.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Jonathan Hunter <jonathanh@nvidia.com>
Cc: linux-tegra@vger.kernel.org
Link: https://patchwork.freedesktop.org/patch/msgid/20210413094904.3736372-10-daniel.vetter@ffwll.ch
      be4306ad
    • Vivek Kasireddy's avatar
      drm/virtio: Create Dumb BOs as guest Blobs (v3) · 3389082b
      Vivek Kasireddy authored 
      

If support for Blob resources is available, then dumb BOs created
by the driver can be considered as guest Blobs.

v2: Don't skip transfer and flush commands as part of plane update
as the device may have created a shared mapping. (Gerd)

v3: Don't create dumb BOs as Guest blobs if Virgl is enabled. (Gurchetan)

Cc: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: default avatarVivek Kasireddy <vivek.kasireddy@intel.com>
Acked-by: default avatarGurchetan Singh <gurchetansingh@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20210413052614.2486768-1-vivek.kasireddy@intel.com
Signed-off-by: default avatarGerd Hoffmann <kraxel@redhat.com>
      3389082b
  3. Apr 14, 2021
  5. Apr 13, 2021
  7. Apr 12, 2021
  9. Apr 09, 2021
    • Christian König's avatar
      drm/ttm: make global mutex and use count static · d4e68236
      Christian König authored 
      

Only needed during device hot plug and remove and not exported.

Signed-off-by: default avatarChristian König <christian.koenig@amd.com>
Suggested-by: default avatarBernard <bernard@vivo.com>
Acked-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20210409110730.2958-1-christian.koenig@amd.com
      d4e68236
    • Tian Tao's avatar
      drm/panel: Convert sysfs sprintf/snprintf family to sysfs_emit · e8b8b0df
      Tian Tao authored 
      

Fix the following coccicheck warning:
drivers/gpu/drm/panel//panel-tpo-td043mtea1.c:217:8-16: WARNING:
use scnprintf or sprintf
drivers/gpu/drm/panel//panel-tpo-td043mtea1.c:189:8-16: WARNING:
use scnprintf or sprintf

Signed-off-by: default avatarTian Tao <tiantao6@hisilicon.com>
Reviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/1617069288-8317-1-git-send-email-tiantao6@hisilicon.com
      e8b8b0df
    • Lyude Paul's avatar
      drm/dp_mst: Drop DRM_ERROR() on kzalloc() fail in drm_dp_mst_handle_up_req() · 90876fd4
      Lyude Paul authored 
      

Checkpatch was complaining about this - there's no need for us to print
errors when kzalloc() fails, as kzalloc() will already WARN for us. So,
let's fix that before converting things to make checkpatch happy.

Signed-off-by: default avatarLyude Paul <lyude@redhat.com>
Cc: Robert Foss <robert.foss@linaro.org>
Reviewed-by: default avatarRobert Foss <robert.foss@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210326203807.105754-20-lyude@redhat.com
      90876fd4
    • Lyude Paul's avatar
      drm/print: Fixup DRM_DEBUG_KMS_RATELIMITED() · c5261e93
      Lyude Paul authored 
      

Since we're about to move drm_dp_helper.c over to drm_dbg_*(), we'll want
to make sure that we can also add ratelimited versions of these macros in
order to retain some of the previous debugging output behavior we had.

However, as I was preparing to do this I noticed that the current
rate limited macros we have are kind of bogus. It looks like when I wrote
these, I didn't notice that we'd always be calling __ratelimit() even if
the debugging message we'd be printing would normally be filtered out due
to the relevant DRM debugging category being disabled.

So, let's fix this by making sure to check drm_debug_enabled() in our
ratelimited macros before calling __ratelimit(), and start using
drm_dev_printk() in order to print debugging messages since that will save
us from doing a redundant drm_debug_enabled() check. And while we're at it,
let's move the code for this into another macro that we can reuse for
defining new ratelimited DRM debug macros more easily.

v2:
* Make sure to use tabs where possible in __DRM_DEFINE_DBG_RATELIMITED()

Signed-off-by: default avatarLyude Paul <lyude@redhat.com>
Cc: Robert Foss <robert.foss@linaro.org>
Reviewed-by: default avatarRobert Foss <robert.foss@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210326203807.105754-8-lyude@redhat.com
      c5261e93
    • Lyude Paul's avatar
      drm/tegra: Don't register DP AUX channels before connectors · 39c17ae6
      Lyude Paul authored 
      

As pointed out by the documentation for drm_dp_aux_register(),
drm_dp_aux_init() should be used in situations where the AUX channel for a
display driver can potentially be registered before it's respective DRM
driver. This is the case with Tegra, since the DP aux channel exists as a
platform device instead of being a grandchild of the DRM device.

Since we're about to add a backpointer to a DP AUX channel's respective DRM
device, let's fix this so that we don't potentially allow userspace to use
the AUX channel before we've associated it with it's DRM connector.

Signed-off-by: default avatarLyude Paul <lyude@redhat.com>
Acked-by: default avatarThierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210326203807.105754-3-lyude@redhat.com
      39c17ae6
    • Lyude Paul's avatar
      drm/dp: Fixup kernel docs for struct drm_dp_aux · 45d96999
      Lyude Paul authored 
      

* Make sure that struct members are referred to using @, otherwise they
  won't be formatted as such
* Make sure to refer to other struct types using & so they link back to
  each struct's definition
* Make sure to precede constant values with % so they're formatted
  correctly

Signed-off-by: default avatarLyude Paul <lyude@redhat.com>
Acked-by: default avatarRandy Dunlap <rdunlap@infradead.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210326203807.105754-2-lyude@redhat.com
      45d96999
  11. Apr 08, 2021
  13. Apr 02, 2021
    • Ville Syrjälä's avatar
      drm/vblank: Do not store a new vblank timestamp in drm_vblank_restore() · 167b4002
      Ville Syrjälä authored 
      

drm_vblank_restore() exists because certain power saving states
can clobber the hardware frame counter. The way it does this is
by guesstimating how many frames were missed purely based on
the difference between the last stored timestamp vs. a newly
sampled timestamp.

If we should call this function before a full frame has
elapsed since we sampled the last timestamp we would end up
with a possibly slightly different timestamp value for the
same frame. Currently we will happily overwrite the already
stored timestamp for the frame with the new value. This
could cause userspace to observe two different timestamps
for the same frame (and the timestamp could even go
backwards depending on how much error we introduce when
correcting the timestamp based on the scanout position).

To avoid that let's not update the stored timestamp at all,
and instead we just fix up the last recorded hw vblank counter
value such that the already stored timestamp/seq number will
match. Thus the next time a vblank irq happens it will calculate
the correct diff between the current and stored hw vblank counter
values.

Sidenote: Another possible idea that came to mind would be to
do this correction only if the power really was removed since
the last time we sampled the hw frame counter. But to do that
we would need a robust way to detect when it has occurred. Some
possibilities could involve some kind of hardare power well
transition counter, or potentially we could store a magic value
in a scratch register that lives in the same power well. But
I'm not sure either of those exist, so would need an actual
investigation to find out. All of that is very hardware specific
of course, so would have to be done in the driver code.

Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210218160305.16711-1-ville.syrjala@linux.intel.com
Reviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      167b4002
    • Ville Syrjälä's avatar
      drm: Refuse to create zero width/height cmdline modes · 19a9a0ef
      Ville Syrjälä authored 
      

If the user specifies zero width/height cmdline mode i915 will
blow up as the fbdev path will bypass the regular fb sanity
check that would otherwise have refused to create a framebuffer
with zero width/height.

The reason I thought to try this is so that I can force a specific
depth for fbdev without actually having to hardcode the mode
on the kernel cmdline. Eg. if I pass video=0x0-8 I will get an
8bpp framebuffer at my monitor's native resolution.

Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190607162611.23514-2-ville.syrjala@linux.intel.com
Reviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      19a9a0ef
  15. Apr 01, 2021