- 09 Apr, 2021 9 commits
-
-
Alex Deucher authored
Once the device has runtime suspended, we don't need to power it back up again for system suspend. Likewise for resume, we don't to power up the device again on resume only to power it back off again via runtime pm because it's still idle. v2: add DPM_FLAG_SMART_PREPARE as well Reviewed-by:
Evan Quan <evan.quan@amd.com> Acked-by: Rajneesh Bhardwaj <rajneesh.bhardwaj@amd.com> (v1) Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
Alex Deucher authored
as per: https://www.kernel.org/doc/html/latest/driver-api/pm/devices.html The prepare callback is required to support the DPM_FLAG_SMART_SUSPEND driver flag. This allows runtime pm to auto complete when the system goes into suspend avoiding a wake up on suspend and on resume. Apply this for hybrid gfx and BOCO systems where d3cold is provided by the ACPI platform. v2: check if device is runtime suspended in prepare. Reviewed-by:
-
Alex Deucher authored
Add new DID. Reviewed-by:
Guchun Chen <guchun.chen@amd.com> Signed-off-by:
-
Alex Deucher authored
Added a new parameter and forgot to update the documentation. Fixes: b6f91fc1 ("drm/amdgpu/display: buffer INTERRUPT_LOW_IRQ_CONTEXT interrupt work") Reviewed-by:
Xiaogang Chen <xiaogang.chen@amd.com> Signed-off-by:
-
Nirmoy Das authored
KIQ ring is being operated by kfd as well as amdgpu. KFD is using kiq lock, we should the same from amdgpu side as well. Signed-off-by:
Nirmoy Das <nirmoy.das@amd.com> Acked-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
-
Xiaojian Du authored
This reverts commit 33cf440d. And it will enable mode-2 gpu reset for vangogh, it asks PSP firmware version is 00.1A.00.0F or newer. Signed-off-by:
Xiaojian Du <Xiaojian.Du@amd.com> Reviewed-by:
Huang Rui <ray.huang@amd.com> Signed-off-by:
-
Dennis Li authored
When recovery thread has begun GPU reset, there should be not other threads to access hardware, otherwise system randomly hang. v2 (chk): rewritten from scratch, use trylock and lockdep instead of hand wiring the logic. v3: add in_irq check v4: change to check in_task Signed-off-by:
Dennis Li <Dennis.Li@amd.com> Signed-off-by:
Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by:
-
git://anongit.freedesktop.org/drm/drm-miscDave Airlie authored
drm-misc-next for 5.13: UAPI Changes: Cross-subsystem Changes: Core Changes: - bridge: Fix Kconfig dependency - cmdline: Refuse zero width/height mode - ttm: Ignore signaled move fences, ioremap buffer according to mem caching settins Driver Changes: - Conversions to sysfs_emit - tegra: Don't register DP AUX channels before connectors - zynqmp: Fix for an out-of-bound (but within struct padding) memset Signed-off-by:Dave Airlie <airlied@redhat.com> From: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20210409090020.jroa2d4p4qansrpa@gilmour
-
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:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/1617069288-8317-1-git-send-email-tiantao6@hisilicon.com
-
- 08 Apr, 2021 16 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:
Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210326203807.105754-20-lyude@redhat.com
-
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:
Thierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210326203807.105754-3-lyude@redhat.com
-
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:
Felix Kuehling <Felix.Kuehling@amd.com> Reviewed-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:
-
git://anongit.freedesktop.org/drm/drm-intelDave Airlie authored
Features: - Add support for FBs requiring a power-of-two stride padding (Imre) Refactoring: - Disassociate display version from gen (Matt) - Refactor legacy DP and HDMI code to separate files (Ville) - Refactor FB plane code to a separate file (Imre) - Refactor VBT child device info parsing and usage (Jani) - Refactor KBL/TGL/ADL-S display and gt stepping schemes (Jani) Fixes: - DP Link-Training Tunable PHY Repeaters (LTTPR) fixes (Imre) - HDCP fixes (Anshuman) - DP 2.0 HDMI 2.1 PCON Fixed Rate Link (FRL) fixes (Ankit) - Set HDA link parameters in driver (Kai) - Fix enabled_planes bitmask (Ville) - Fix transposed arguments to skl_plane_wm_level() (Ville) - Stop adding planes to the commit needlessly (Ville) Signed-off-by:
-
Dave Airlie authored
Merge tag 'drm-intel-gt-next-2021-04-06' of git://anongit.freedesktop.org/drm/drm-intel into drm-next Driver Changes: - Prepare for local/device memory support on DG1 by starting to use it for kernel internal allocations: context, ring and engine scratch (Matt A, CQ, Abdiel, Imre) - Sandybridge fix to avoid hard hang on ring resume (Chris) - Limit imported dma-buf size to int32 (Matt A) - Double check heartbeat timeout before resetting (Chris) - Use new tasklet API for execution list (Emil) - Fix SPDX checkpats warnings (Chris) - Fixes for various checkpatch warnings (Chris) - Selftest improvements (Chris) - Move the defer_request waiter active assertion to correct spot (Chris) - Make local-memory probing a GT operation (Matt, Tvrtko) - Protect against request freeing during cancellation on wedging (Chris) - Retire unexpected starting state error dumping (Chris) - Distinction of memory regions in debugging (Zbigniew) - Always flush the submission queue on checking for idle (Chris) - Consolidate 2big error check to helper (Matt) - Decrease number of subplatform bits (Tvrtko) - Remove unused internal request priority levels (Chris) - Document the unused internal header bits in buddy allocator (Matt) - Cleanup the region class/instance encoding (Matt) Signed-off-by:
-
Dave Airlie authored
Merge tag 'mediatek-drm-next-5.13' of https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux into drm-next Mediatek DRM Next for Linux 5.13 1. Fine tune the line time for EOTp. 2. Add support mt8192 dpi. 3. Make crtc config-updating atomic. 4. Don't support hdmi connector creation. From: Chun-Kuang Hu <chunkuang.hu@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210405082248.3578-1-chunkuang.hu@kernel.orgSigned-off-by:
-
- 07 Apr, 2021 1 commit
-
-
git://anongit.freedesktop.org/drm/drm-miscDave Airlie authored
drm-misc-next for 5.13: UAPI Changes: Cross-subsystem Changes: Core Changes: - mst: Improve topology logging - edid: Rework and improvements for displayid Driver Changes: - anx7625: Regulators support - bridge: Support for the Chipone ICN6211, Lontium LT8912B - lt9611: Fix 4k panels handling Signed-off-by:
-
- 01 Apr, 2021 9 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:
-
Dafna Hirschfeld authored
commit f0119514 ("drm/mediatek: mtk_dpi: Create connector for bridges") broke the display support for elm device since mtk_dpi calls drm_bridge_attach with the flag DRM_BRIDGE_ATTACH_NO_CONNECTOR while mtk_hdmi does not yet support this flag. Fix this by accepting DRM_BRIDGE_ATTACH_NO_CONNECTOR in bridge attachment. Implement the drm_bridge_funcs .detect() and .get_edid() operations, and call drm_bridge_hpd_notify() to report HPD. This provides the necessary API to support disabling connector creation. In addition, the field 'conn' is removed from the mtk_hdmi struct since mtk_hdmi don't create a connector. It is replaced with a pointer 'curr_conn' that points to the current connector which can be access through the global state. This patch is inspired by a similar patch for bridge/synopsys/dw-hdmi.c: commit ec971aaa ("drm: bridge: dw-hdmi: Make connector creation optional") But with the difference that in mtk-hdmi only the option of not creating a connector is supported. Fixes: f0119514 ("drm/mediatek: mtk_dpi: Create connector for bridges") Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Chun-Kuang Hu <chunkuang.hu@kernel.org>
-
Dafna Hirschfeld authored
The bridge operation '.enable' and the audio cb '.get_eld' access hdmi->conn. In the future we will want to support the flag DRM_BRIDGE_ATTACH_NO_CONNECTOR and then we will not have direct access to the connector. The atomic version '.atomic_enable' allows accessing the current connector from the state. This patch switches the bridge to the atomic version to prepare access to the connector in later patches. Signed-off-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:
-
Hsin-Yi Wang authored
anx7625 requires 3 power supply regulators. Signed-off-by:
Rob Herring <robh@kernel.org> Reviewed-by:
-
- 31 Mar, 2021 5 commits
-
-
Dave Airlie authored
Merge tag 'exynos-drm-next-for-v5.13' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-next One cleanup - Based on the patch[1], clean up the use of request_irq function series. [1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next-history.git/commit/?id=cbe16f35bee6880becca6f20d2ebf6b457148552Signed-off-by:
-
ssh://git.freedesktop.org/git/drm/drmDave Airlie authored
special i915-gem-next pull as requested - Conversion to dma_resv_locking, obj->mm.lock is gone (Maarten, with help from Thomas Hellström) - watchdog (Tvrtko, one patch to cancel individual request from Chris) - legacy ioctl cleanup (Jason+Ashutosh) - i915-gem TODO and RFC process doc (me) - i915_ prefix for vma_lookup (Liam Howlett) just because I spotted it and put it in here too Signed-off-by:
-
Imre Deak authored
Fix the Documentation/gpu/i915:22: /drivers/gpu/drm/i915/intel_runtime_pm.c:423: WARNING: Inline strong start-string without end-string. warning from the htmldocs build. Fixes: 9d58aa46 ("drm/i915: Fix the GT fence revocation runtime PM logic") Reported-by:
Imre Deak <imre.deak@intel.com> Acked-by:
Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20210330150118.1105079-1-imre.deak@intel.com
-
Jani Nikula authored
Avoid any confusion with High Dynamic Range. No functional changes. Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/ce083bd2789c7e22a91710726162287db88e3f6c.1617024940.git.jani.nikula@intel.com
-
Jani Nikula authored
The DisplayID specifications explicitly call out 0 as a valid payload length for data blocks. The mere presence of a data block, or the information coded in the block specific data (bits 7:3 in offset 1), may be enough to convey the necessary information. Reviewed-by:
-
