- 15 Apr, 2021 3 commits
-
-
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:
Maxime Ripard <maxime@cerno.tech> Signed-off-by:
Daniel 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
-
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:
Thierry Reding <treding@nvidia.com> Signed-off-by:
-
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:
Vivek Kasireddy <vivek.kasireddy@intel.com> Acked-by:
Gurchetan Singh <gurchetansingh@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/20210413052614.2486768-1-vivek.kasireddy@intel.comSigned-off-by:
Gerd Hoffmann <kraxel@redhat.com>
-
- 14 Apr, 2021 4 commits
-
-
Felix Kuehling authored
Pages in SG BOs were not allocated by TTM. So don't count them against TTM's pages limit. Signed-off-by:
Felix Kuehling <Felix.Kuehling@amd.com> Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
-
Thomas Zimmermann authored
Fbdev's helpers for handling conflicting framebuffer drivers are related to framebuffer apertures, not console emulation. Therefore remove them from drm_fb_helper.h and inline them into the aperture helpers. No functional changes. Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Acked-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210412131043.5787-4-tzimmermann@suse.de
-
Thomas Zimmermann authored
Mass-convert all drivers from FB helpers to aperture interfaces. No functional changes besides checking for returned errno codes. Signed-off-by:
-
Thomas Zimmermann authored
Platform devices might operate on firmware framebuffers, such as VESA or EFI. Before a native driver for the graphics hardware can take over the device, it has to remove any platform driver that operates on the firmware framebuffer. Aperture helpers provide the infrastructure for native drivers to remove the generic ones. For now, this only concerns generic fbdev drivers. Code for removing these is provided by drm_fb_helper_remove_conflicting_framebuffers() et al. Simply wrap these functions for now. At a later point, code can be added for generic DRM drivers to acquire firmware framebuffers. v2: * fix docs for drm_aperture_remove_framebuffers() Signed-off-by:
-
- 13 Apr, 2021 3 commits
-
-
Kai-Heng Feng authored
On some platforms like Hyper-V and RPi4 with UEFI firmware, efifb is not a PCI device. So make sure efifb_pci_dev is found before using it. Fixes: a6c0fd3d ("efifb: Ensure graphics device for efifb stays at PCI D0") BugLink: https://bugs.launchpad.net/bugs/1922403Signed-off-by:
Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Reviewed-by:
-
Parshuram Thombare authored
This patch enable HDCP in MHDP driver. Signed-off-by:
Parshuram Thombare <pthombar@cadence.com> Reviewed-by:
Robert Foss <robert.foss@linaro.org> Signed-off-by:
-
Parshuram Thombare authored
Add binding changes for HDCP in the MHDP8546 DPI/DP bridge binding. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
- 12 Apr, 2021 5 commits
-
-
Fabio M. De Francesco authored
Corrected comments format in accordance to the Linux style guides. Signed-off-by:
Fabio M. De Francesco <fmdefrancesco@gmail.com> Signed-off-by:
-
Fabio M. De Francesco authored
Replaced "unsigned with "unsigned int" since the latter is preferred. Signed-off-by:
-
Fabio M. De Francesco authored
Replaced the type "unsigned" with "unsigned int" because it is preferred. Issue detected by checkpatch.pl. Signed-off-by:
-
Christian König authored
That got lost when we moved back to a static limit. Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210409130113.1459-2-christian.koenig@amd.com
-
Christian König authored
The function returns the number of swapped pages here. Only abort when we get a negative error code. Signed-off-by:
-
- 11 Apr, 2021 4 commits
-
-
Thomas Zimmermann authored
Qxl now uses drm_gem_ttm_dumb_map_offset() to implement struct drm_driver.dumb_map_offset. Signed-off-by:
-
Thomas Zimmermann authored
Nouveau now uses drm_gem_ttm_dumb_map_offset() to implement struct drm_driver.dumb_map_offset. Signed-off-by:
-
Thomas Zimmermann authored
VRAM helpers now use drm_gem_ttm_dumb_map_offset() to implement struct drm_driver.dumb_map_offset. v2: * update hibmc as well (kernel test robot) Signed-off-by:
-
Thomas Zimmermann authored
Provides an implementation of struct drm_driver.dumb_map_offset that can be used by TTM-based GEM drivers. Signed-off-by:
-
- 09 Apr, 2021 2 commits
-
-
Christian König authored
Only needed during device hot plug and remove and not exported. Signed-off-by:
Bernard <bernard@vivo.com> Acked-by:
-
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:
Tian Tao <tiantao6@hisilicon.com> Reviewed-by:
-
- 08 Apr, 2021 13 commits
-
-
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:
Lyude Paul <lyude@redhat.com> Cc: Robert Foss <robert.foss@linaro.org> Reviewed-by:
-
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:
-
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:
-
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:
Randy Dunlap <rdunlap@infradead.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210326203807.105754-2-lyude@redhat.com
-
Christian König authored
Just fix a warning. Signed-off-by:
Stephen Rothwell <sfr@canb.auug.org.au> Fixes: f2f12eb9 ("drm/scheduler: provide scheduler score externally") Reviewed-by:
-
Guobin Huang authored
spinlock can be initialized automatically with DEFINE_SPINLOCK() rather than explicitly calling spin_lock_init(). Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Guobin Huang <huangguobin4@huawei.com> Signed-off-by:
-
Wan Jiabing authored
struct drm_gem_object is declared twice. One is declared at 40th line. The blew one is not needed. Remove the duplicate. Signed-off-by:
Wan Jiabing <wanjiabing@vivo.com> Signed-off-by:
-
Dan Carpenter authored
The dp->train_set[] for this driver is only two characters, not four so this memsets too much. Fortunately, this ends up corrupting a struct hole and not anything important. Fixes: d76271d2 ("drm: xlnx: DRM/KMS driver for Xilinx ZynqMP DisplayPort Subsystem") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
Michal Simek <michal.simek@xilinx.com> Signed-off-by:
-
Dafna Hirschfeld authored
fix 's/controller/controllers/' in the sentence: Most display controller handle display connectors... Signed-off-by:
Dafna Hirschfeld <dafna.hirschfeld@collabora.com> Signed-off-by:
-
Oak Zeng authored
If tbo.mem.bus.caching is cached, buffer is intended to be mapped as cached from CPU. Map it with ioremap_cache. This wasn't necessary before as device memory was never mapped as cached from CPU side. It becomes necessary for aldebaran as device memory is mapped cached from CPU. Signed-off-by:
Oak Zeng <Oak.Zeng@amd.com> Reviewed-by:
-
Felix Kuehling authored
Move fences that have already signaled should not prevent memory allocations with no_wait_gpu. Signed-off-by:
-
David Stevens authored
Allocate a new private stub fence in drm_syncobj_assign_null_handle, instead of using a static stub fence. When userspace creates a fence with DRM_SYNCOBJ_CREATE_SIGNALED or when userspace signals a fence via DRM_IOCTL_SYNCOBJ_SIGNAL, the timestamp obtained when the fence is exported and queried with SYNC_IOC_FILE_INFO should match when the fence's status was changed from the perspective of userspace, which is during the respective ioctl. When a static stub fence started being used in by these ioctls, this behavior changed. Instead, the timestamp returned by SYNC_IOC_FILE_INFO became the first time anything used the static stub fence, which has no meaning to userspace. Signed-off-by:
David Stevens <stevensd@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210408095428.3983055-1-stevensd@google.comReviewed-by:
-
Zhang Jianhua authored
If CONFIG_DRM_LONTIUM_LT8912B=m, the following errors will be seen while compiling lontium-lt8912b.c drivers/gpu/drm/bridge/lontium-lt8912b.c: In function ‘lt8912_hard_power_on’: drivers/gpu/drm/bridge/lontium-lt8912b.c:252:2: error: implicit declaration of function ‘gpiod_set_value_cansleep’; did you mean ‘gpio_set_value_cansleep’? [-Werror=implicit-function-declaration] gpiod_set_value_cansleep(lt->gp_reset, 0); ^~~~~~~~~~~~~~~~~~~~~~~~ gpio_set_value_cansleep drivers/gpu/drm/bridge/lontium-lt8912b.c: In function ‘lt8912_parse_dt’: drivers/gpu/drm/bridge/lontium-lt8912b.c:628:13: error: implicit declaration of function ‘devm_gpiod_get_optional’; did you mean ‘devm_gpio_request_one’? [-Werror=implicit-function-declaration] gp_reset = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH); ^~~~~~~~~~~~~~~~~~~~~~~ devm_gpio_request_one drivers/gpu/drm/bridge/lontium-lt8912b.c:628:51: error: ‘GPIOD_OUT_HIGH’ undeclared (first use in this function); did you mean ‘GPIOF_INIT_HIGH’? gp_reset = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH); ^~~~~~~~~~~~~~ GPIOF_INIT_HIGH Signed-off-by:Zhang Jianhua <zhangjianhua18@huawei.com> Reviewed-by:
-
- 01 Apr, 2021 6 commits
-
-
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:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210218160305.16711-1-ville.syrjala@linux.intel.comReviewed-by:
-
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:
-
Julian Braha authored
When DRM_TOSHIBA_TC358762 is enabled and DRM_KMS_HELPER is disabled, Kbuild gives the following warning: WARNING: unmet direct dependencies detected for DRM_PANEL_BRIDGE Depends on [n]: HAS_IOMEM [=y] && DRM_BRIDGE [=y] && DRM_KMS_HELPER [=n] Selected by [y]: - DRM_TOSHIBA_TC358762 [=y] && HAS_IOMEM [=y] && DRM [=y] && DRM_BRIDGE [=y] && OF [=y] This is because DRM_TOSHIBA_TC358762 selects DRM_PANEL_BRIDGE, without depending on or selecting DRM_KMS_HELPER, despite that config option depending on DRM_KMS_HELPER. Signed-off-by:
Julian Braha <julianbraha@gmail.com> Reviewed-by:
-
Carsten Haitzler authored
Another issue found by KASAN. The bit finding is buried inside the dp_for_each_set_bit() macro (that passes on to for_each_set_bit() that calls the bit stuff. These bit functions want an unsigned long pointer as input and just dumbly casting leads to out-of-bounds accesses. This fixes that. Signed-off-by:
Carsten Haitzler <carsten.haitzler@arm.com> Reviewed-by:
Steven Price <steven.price@arm.com> Reviewed-by:
James Qian Wang <james.qian.wang@arm.com> Signed-off-by:
Liviu Dudau <liviu.dudau@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210204131102.68658-1-carsten.haitzler@foss.arm.com
-
Tian Tao authored
Fix the following coccicheck warning: drivers/gpu/drm/arm/display/komeda/komeda_dev.c:97:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/arm/display/komeda/komeda_dev.c:88:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/arm/display/komeda/komeda_dev.c:65:8-16: WARNING: use scnprintf or sprintf Signed-off-by:
-
Hsin-Yi Wang authored
When suspending the driver, anx7625_power_standby() will be called to turn off reset-gpios and enable-gpios. However, power supplies are not disabled. To save power, the driver can get the power supply regulators and turn off them in anx7625_power_standby(). Signed-off-by:
Hsin-Yi Wang <hsinyi@chromium.org> Reviewed-by:
Xin Ji <xji@analogixsemi.com> Signed-off-by:
-
