- 19 Sep, 2023 9 commits
-
-
Ben Skeggs authored
These will be made static later in the patch series, after the code that uses them has been cleaned up in preparation for GSP-RM support. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Acked-by: Danilo Krummrich <me@dakr.org> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230919220442.202488-10-lyude@redhat.com
-
Ben Skeggs authored
- needed to support TMDS EDID on RM Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Acked-by: Danilo Krummrich <me@dakr.org> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230919220442.202488-9-lyude@redhat.com
-
Ben Skeggs authored
This will check the relevant hotplug pin and skip the DDC probe we currently do if a display is present. - preparation for GSP-RM. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Acked-by: Danilo Krummrich <me@dakr.org> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230919220442.202488-8-lyude@redhat.com
-
Ben Skeggs authored
- preparation for a bunch of API changes, to make diffs prettier Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Acked-by: Danilo Krummrich <me@dakr.org> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230919220442.202488-7-lyude@redhat.com
-
Ben Skeggs authored
Programming -1 (vc_start_slot, if alloc fails) into HW probably isn't the best idea. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Acked-by: Danilo Krummrich <me@dakr.org> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230919220442.202488-6-lyude@redhat.com
-
Ben Skeggs authored
Fixes some issues when running on top of RM. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Acked-by: Danilo Krummrich <me@dakr.org> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230919220442.202488-5-lyude@redhat.com
-
Ben Skeggs authored
Some of these buffers are quite large, and there's no need to preserve them across suspend. Mark the contents as lost to speedup suspend/resume. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Acked-by: Danilo Krummrich <me@dakr.org> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230919220442.202488-4-lyude@redhat.com
-
Ben Skeggs authored
Will initially be used to tag some large grctx allocations which don't need to be saved, to speedup suspend/resume. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Acked-by: Danilo Krummrich <me@dakr.org> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230919220442.202488-3-lyude@redhat.com
-
Ben Skeggs authored
From Turing, HW will already have handled this and locked-down the falcon before we get control. So this *should* be a no-op. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Acked-by: Danilo Krummrich <me@dakr.org> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230919220442.202488-2-lyude@redhat.com
-
- 18 Sep, 2023 4 commits
-
-
Imre Deak authored
If a sink is removed in the middle of payload addition the corresponding AUX transfer will fail as expected, so tune the error message down to a debug messge. Cc: Wayne Lin <Wayne.Lin@amd.com> Cc: Lyude Paul <lyude@redhat.com> Cc: dri-devel@lists.freedesktop.org Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230913223218.540365-3-imre.deak@intel.com
-
Imre Deak authored
Return an error during payload addition if the payload port isn't found. This shouldn't change the behavior since only the i915 driver checks the return value, printing an error message in case of a failure. While at it simplify the control flow. Cc: Wayne Lin <Wayne.Lin@amd.com> Cc: Lyude Paul <lyude@redhat.com> Cc: dri-devel@lists.freedesktop.org Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230913223218.540365-2-imre.deak@intel.com
-
Imre Deak authored
Fix the NULL dereference leading to the following stack trace: [ 129.687181] i915 0000:00:02.0: [drm:drm_dp_add_payload_part1 [drm_display_helper]] VCPI 1 for port 000000005be4423e not in topology, not creating a payload to remote [ 129.687257] BUG: kernel NULL pointer dereference, address: 0000000000000560 [ 129.694276] #PF: supervisor read access in kernel mode [ 129.699459] #PF: error_code(0x0000) - not-present page [ 129.704612] PGD 0 P4D 0 [ 129.707178] Oops: 0000 [#1] PREEMPT SMP NOPTI [ 129.711556] CPU: 2 PID: 1623 Comm: Xorg Tainted: G U 6.6.0-rc1-imre+ #985 [ 129.719744] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR5 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023 [ 129.732509] RIP: 0010:drm_dp_mst_topology_put_port+0x19/0x170 [drm_display_helper] [ 129.740111] Code: 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41 55 41 54 53 48 89 fb 48 83 ec 08 <48> 8b 87 60 05 00 00 44 8b 0f 48 8b 70 58 41 83 e9 01 48 85 f6 74 [ 129.758842] RSP: 0018:ffffc90001daf900 EFLAGS: 00010286 [ 129.764104] RAX: 0000000000000001 RBX: 0000000000000000 RCX: 0000000000000000 [ 129.771246] RDX: 0000000000000000 RSI: ffffffff9e73d613 RDI: 0000000000000000 [ 129.778394] RBP: ffffc90001daf930 R08: 0000000000000000 R09: 0000000000000020 [ 129.785533] R10: 0000000000ffff10 R11: 000000000000000f R12: ffff888116c65e40 [ 129.792680] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 129.799822] FS: 00007f39f74b1a80(0000) GS:ffff88840f680000(0000) knlGS:0000000000000000 [ 129.807913] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 129.813670] CR2: 0000000000000560 CR3: 0000000138b88000 CR4: 0000000000750ee0 [ 129.820815] PKRU: 55555554 [ 129.823551] Call Trace: [ 129.826022] <TASK> [ 129.828154] ? show_regs+0x65/0x70 [ 129.831599] ? __die+0x24/0x70 [ 129.834683] ? page_fault_oops+0x160/0x480 [ 129.838824] ? dev_printk_emit+0x83/0xb0 [ 129.842797] ? do_user_addr_fault+0x2e2/0x680 [ 129.847175] ? exc_page_fault+0x78/0x180 [ 129.851143] ? asm_exc_page_fault+0x27/0x30 [ 129.855353] ? drm_dp_mst_topology_put_port+0x19/0x170 [drm_display_helper] [ 129.862354] drm_dp_add_payload_part1+0x85/0x100 [drm_display_helper] [ 129.868832] intel_mst_pre_enable_dp+0x1ef/0x240 [i915] [ 129.874170] intel_encoders_pre_enable+0x83/0xa0 [i915] [ 129.879524] hsw_crtc_enable+0xbe/0x750 [i915] [ 129.884095] intel_enable_crtc+0x68/0xa0 [i915] [ 129.888752] skl_commit_modeset_enables+0x2c4/0x5d0 [i915] [ 129.894365] intel_atomic_commit_tail+0x765/0x1070 [i915] [ 129.899885] intel_atomic_commit+0x3ba/0x400 [i915] [ 129.904892] drm_atomic_commit+0x96/0xd0 [drm] [ 129.909405] ? __pfx___drm_printfn_info+0x10/0x10 [drm] [ 129.914698] drm_atomic_helper_set_config+0x7e/0xc0 [drm_kms_helper] [ 129.921102] drm_mode_setcrtc+0x5af/0x8d0 [drm] [ 129.925695] ? __pfx_drm_mode_setcrtc+0x10/0x10 [drm] [ 129.930810] drm_ioctl_kernel+0xc4/0x170 [drm] [ 129.935317] drm_ioctl+0x2a4/0x520 [drm] [ 129.939305] ? __pfx_drm_mode_setcrtc+0x10/0x10 [drm] [ 129.944415] ? __fget_light+0xa5/0x110 [ 129.948212] __x64_sys_ioctl+0x98/0xd0 [ 129.951985] do_syscall_64+0x37/0x90 [ 129.955581] entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Fixes: 5aa1dfcd ("drm/mst: Refactor the flow for payload allocation/removement") Cc: Wayne Lin <Wayne.Lin@amd.com> Cc: Lyude Paul <lyude@redhat.com> Cc: dri-devel@lists.freedesktop.org Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230913223218.540365-1-imre.deak@intel.com
-
Jernej Skrabec authored
Add handling of arbitration lost event. Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com> Reviewed-by: Robert Foss <rfoss@kernel.org> Signed-off-by: Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230909144432.34972-1-jernej.skrabec@gmail.com
-
- 15 Sep, 2023 8 commits
-
-
Justin Stitt authored
`strncpy` is deprecated for use on NUL-terminated destination strings [1]. We should prefer more robust and less ambiguous string interfaces. A suitable replacement is `strscpy` [2] due to the fact that it guarantees NUL-termination on the destination buffer without unnecessarily NUL-padding. Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1] Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html [2] Link: https://github.com/KSPP/linux/issues/90 Cc: linux-hardening@vger.kernel.org Signed-off-by: Justin Stitt <justinstitt@google.com> Reviewed-by: Kees Cook <keescook@chromium.org> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230914-strncpy-drivers-gpu-drm-nouveau-nvkm-engine-pm-base-c-v1-1-4b09ed453f84@google.com
-
Justin Stitt authored
`strncpy` is deprecated for use on NUL-terminated destination strings [1]. We should prefer more robust and less ambiguous string interfaces. A suitable replacement is `strscpy` [2] due to the fact that it guarantees NUL-termination on the destination buffer without unnecessarily NUL-padding. There is likely no bug in the current implementation due to the safeguard: | cname[sizeof(cname) - 1] = '\0'; ... however we can provide simpler and easier to understand code using the newer (and recommended) `strscpy` api. Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1] Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html [2] Link: https://github.com/KSPP/linux/issues/90 Cc: linux-hardening@vger.kernel.org Signed-off-by: Justin Stitt <justinstitt@google.com> Reviewed-by: Kees Cook <keescook@chromium.org> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230914-strncpy-drivers-gpu-drm-nouveau-nvkm-core-firmware-c-v1-1-3aeae46c032f@google.com
-
Justin Stitt authored
`strncpy` is deprecated and as such we should prefer more robust and less ambiguous string interfaces. A suitable replacement is `strscpy_pad` due to the fact that it guarantees NUL-termination on the destination buffer whilst also maintaining the NUL-padding behavior that `strncpy` provides. I am not sure whether NUL-padding is strictly needed but I see in `nvif_object_ctor()` args is memcpy'd elsewhere so I figured we'd keep the same functionality. Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1] Link: https://github.com/KSPP/linux/issues/90 Cc: linux-hardening@vger.kernel.org Signed-off-by: Justin Stitt <justinstitt@google.com> Reviewed-by: Kees Cook <keescook@chromium.org> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230914-strncpy-drivers-gpu-drm-nouveau-nvif-client-c-v1-1-dc3b3719fcb4@google.com
-
baozhu.liu authored
When testing the d71 writeback layer function, the output format is set to NV12, and the following error message is displayed: [drm:komeda_fb_is_layer_supported] Layer TYPE: 4 doesn't support fb FMT: NV12 little-endian (0x3231564e) with modifier: 0x0.. Check the d71 data manual, writeback layer output formats includes NV12 format. Signed-off-by: baozhu.liu <lucas.liu@siengine.com> Signed-off-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230829093004.22860-1-lucas.liu@siengine.com
-
Jani Nikula authored
Clearly this should be under bridge chips. Cc: Andrzej Hajda <andrzej.hajda@intel.com> Cc: Neil Armstrong <neil.armstrong@linaro.org> Cc: Robert Foss <rfoss@kernel.org> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Neil Armstrong <neil.armstrong@linaro.org> Acked-by: Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230914131951.2473844-1-jani.nikula@intel.com
-
Pranjal Ramajor Asha Kanojiya authored
Since drm_dev_alloc() is deprecated it is recommended to use devm_drm_dev_alloc() instead. Update the driver to start using devm_drm_dev_alloc(). Signed-off-by: Pranjal Ramajor Asha Kanojiya <quic_pkanojiy@quicinc.com> Reviewed-by: Carl Vanderlip <quic_carlv@quicinc.com> Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com> Signed-off-by: Jeffrey Hugo <quic_jhugo@quicinc.com> Reviewed-by: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230901161236.8371-1-quic_jhugo@quicinc.com
-
Pranjal Ramajor Asha Kanojiya authored
As qaic drivers base device is connected to host via PCI framework, it makes sense to register in PCI framework at the beginning of module init. Signed-off-by: Pranjal Ramajor Asha Kanojiya <quic_pkanojiy@quicinc.com> Reviewed-by: Carl Vanderlip <quic_carlv@quicinc.com> Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com> Signed-off-by: Jeffrey Hugo <quic_jhugo@quicinc.com> Reviewed-by: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230901161037.6124-1-quic_jhugo@quicinc.com
-
Jani Nikula authored
The drm stack does not expect error valued pointers for EDID anywhere. Fixes: e6685650 ("drm: bridge: it66121: Set DDC preamble only once before reading EDID") Cc: Paul Cercueil <paul@crapouillou.net> Cc: Robert Foss <robert.foss@linaro.org> Cc: Phong LE <ple@baylibre.com> Cc: Neil Armstrong <neil.armstrong@linaro.org> Cc: Andrzej Hajda <andrzej.hajda@intel.com> Cc: Robert Foss <rfoss@kernel.org> Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com> Cc: Jonas Karlman <jonas@kwiboo.se> Cc: Jernej Skrabec <jernej.skrabec@gmail.com> Cc: <stable@vger.kernel.org> # v6.3+ Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Paul Cercueil <paul@crapouillou.net> Link: https://patchwork.freedesktop.org/patch/msgid/20230914131159.2472513-1-jani.nikula@intel.com
-
- 14 Sep, 2023 2 commits
-
-
Javier Martinez Canillas authored
The commit 45b58669 ("drm/ssd130x: Allocate buffer in the plane's .atomic_check() callback") moved the allocation of the intermediate and HW buffers from the encoder's .atomic_enable callback, to the plane's .atomic_check callback. This was suggested by Maxime Ripard, because drivers aren't allowed to fail after the drm_atomic_helper_swap_state() function has been called. And the encoder's .atomic_enable happens after the new atomic state has been swapped, so allocations (that can fail) shouldn't be done there. But the HW buffer isn't really tied to the plane's state. It has a fixed size that only depends on the (also fixed) display resolution defined in the Device Tree Blob. That buffer can be considered part of the CRTC state, and for this reason makes more sense to do its allocation in the CRTC .atomic_check callback. The other allocated buffer (used to store a conversion from the emulated XR24 format to the native R1 format) is part of the plane's state, since it will be optional once the driver supports R1 and allows user-space to set that pixel format. So let's keep the allocation for it in the plane's .atomic_check callback, this can't be moved to the CRTC's .atomic_check because changing a format does not trigger a CRTC mode set. Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> Closes: https://lore.kernel.org/dri-devel/CAMuHMdWv_QSatDgihr8=2SXHhvp=icNxumZcZOPwT9Q_QiogNQ@mail.gmail.com/Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230913052938.1114651-1-javierm@redhat.com
-
Nathan Chancellor authored
When building without CONFIG_DEBUG_FS: drivers/gpu/drm/tegra/dc.c:1757:59: error: too many arguments to function call, expected 3, have 4 1757 | drm_debugfs_remove_files(dc->debugfs_files, count, root, minor); | ~~~~~~~~~~~~~~~~~~~~~~~~ ^~~~~ include/drm/drm_debugfs.h:162:19: note: 'drm_debugfs_remove_files' declared here 162 | static inline int drm_debugfs_remove_files(const struct drm_info_list *files, | ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 163 | int count, struct drm_minor *minor) | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1 error generated. Update the stub to include the root parameter. Fixes: 8e455145 ("drm/debugfs: rework drm_debugfs_create_files implementation v2") Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230913-fix-drm_debugfs_remove_files-stub-v1-1-6b952ac559f3@kernel.orgSigned-off-by: Christian König <christian.koenig@amd.com>
-
- 13 Sep, 2023 8 commits
-
-
Nathan Chancellor authored
When building with clang, there is a warning (or error when CONFIG_WERROR is set): drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_helpers.c:368:21: error: variable 'old_payload' is uninitialized when used here [-Werror,-Wuninitialized] 368 | new_payload, old_payload); | ^~~~~~~~~~~ drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_helpers.c:344:61: note: initialize the variable 'old_payload' to silence this warning 344 | struct drm_dp_mst_atomic_payload *new_payload, *old_payload; | ^ | = NULL 1 error generated. This variable is not required outside of this function so allocate old_payload on the stack and pass it by reference to dm_helpers_construct_old_payload(), resolving the warning. Closes: https://github.com/ClangBuiltLinux/linux/issues/1931 Fixes: 5aa1dfcd ("drm/mst: Refactor the flow for payload allocation/removement") Reviewed-by: Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230913-fix-wuninitialized-dm_helpers_dp_mst_send_payload_allocation-v1-1-2d1b0a3ef16c@kernel.org
-
Douglas Anderson authored
Based on grepping through the source code this driver appears to be missing a call to drm_atomic_helper_shutdown() at system shutdown time. Among other things, this means that if a panel is in use that it won't be cleanly powered off at system shutdown time. The fact that we should call drm_atomic_helper_shutdown() in the case of OS shutdown/restart comes straight out of the kernel doc "driver instance overview" in drm_drv.c. Since this driver uses the component model and shutdown happens at the base driver, we communicate whether we have to call drm_atomic_helper_shutdown() by seeing if drvdata is non-NULL. Suggested-by: Maxime Ripard <mripard@kernel.org> Acked-by: Paul Cercueil <paul@crapouillou.net> Reviewed-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230901164111.RFT.3.Iea742f06d8bec41598aa40378fc625fbd7e8a3d6@changeid
-
Douglas Anderson authored
Based on grepping through the source code this driver appears to be missing a call to drm_atomic_helper_shutdown() at system shutdown time and at driver unbind time. Among other things, this means that if a panel is in use that it won't be cleanly powered off at system shutdown time. The fact that we should call drm_atomic_helper_shutdown() in the case of OS shutdown/restart and at driver remove (or unbind) time comes straight out of the kernel doc "driver instance overview" in drm_drv.c. A few notes about this fix: - When adding drm_atomic_helper_shutdown() to the unbind path, I added it after drm_kms_helper_poll_fini() since that's when other drivers seemed to have it. - Technically with a previous patch, ("drm/atomic-helper: drm_atomic_helper_shutdown(NULL) should be a noop"), we don't actually need to check to see if our "drm" pointer is NULL before calling drm_atomic_helper_shutdown(). We'll leave the "if" test in, though, so that this patch can land without any dependencies. It could potentially be removed later. - This patch also makes sure to set the drvdata to NULL in the case of bind errors to make sure that shutdown can't access freed data. Suggested-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Maxime Ripard <mripard@kernel.org> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230901164111.RFT.13.I0a9940ff6f387d6acf4e71d8c7dbaff8c42e3aaa@changeid
-
Douglas Anderson authored
As with other places in the Linux kernel--kfree(NULL) being the most famous example--it's convenient to treat being passed a NULL argument as a noop in cleanup functions. Let's make drm_atomic_helper_shutdown() work like this. This is convenient for DRM devices that use the "component" model. On these devices we want shutdown to be a noop if the bind() call of the component hasn't been called yet. As long as drivers are careful to make sure the drvdata is NULL whenever the driver is not bound then we can just do a simple call to drm_atomic_helper_shutdown() with the drvdata at shutdown time. Acked-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230901163944.RFT.1.I906acd535bece03b6671d97c2826c6f0444f4728@changeid
-
Douglas Anderson authored
As per the discussion on the lists [1], changes to this driver generally flow through drm-misc. If they need to be coordinated with v4l2 they sometimes go through Philipp Zabel's tree instead. List both trees in MAINTAINERS. Also update the title of this driver to specify that it's just for IMX 5/6 since, as per Philipp "There are a lot more i.MX that do not use IPUv3 than those that do." [1] https://lore.kernel.org/r/d56dfb568711b4b932edc9601010feda020c2c22.camel@pengutronix.deAcked-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230906072803.1.Idef7e77e8961cbeb8625183eec9db0356b2eccd0@changeid
-
Douglas Anderson authored
As talked about in commit d2aacaf0 ("drm/panel: Check for already prepared/enabled in drm_panel"), we want to remove needless code from panel drivers that was storing and double-checking the prepared/enabled state. Even if someone was relying on the double-check before, that double-check is now in the core and not needed in individual drivers. For the "otm8009a" driver we fully remove the storing of the "enabled" state and we remove the double-checking, but we still keep the storing of the "prepared" state since the backlight code in the driver checks it. This backlight code may not be perfectly safe since there doesn't appear to be sufficient synchronization between the backlight driver (which userspace can call into directly) and the code that's unpreparing the panel. However, this lack of safety is not new and can be addressed in a future patch. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230804140605.RFC.3.I6a4a3c81c78acf5acdc2e5b5d936e19bf57ec07a@changeid
-
Douglas Anderson authored
As talked about in commit d2aacaf0 ("drm/panel: Check for already prepared/enabled in drm_panel"), we want to remove needless code from panel drivers that was storing and double-checking the prepared/enabled state. Even if someone was relying on the double-check before, that double-check is now in the core and not needed in individual drivers. For the s6e63m0 panel driver, this actually fixes a subtle/minor error handling bug in s6e63m0_prepare(). In one error case s6e63m0_prepare() called s6e63m0_unprepare() directly if there was an error. This call to s6e63m0_unprepare() would have been a no-op since ctx->prepared wasn't set yet. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230804140605.RFC.2.Iabafd062e70f6b6b554cf23eeb75f57a80f7e985@changeid
-
Douglas Anderson authored
As talked about in commit d2aacaf0 ("drm/panel: Check for already prepared/enabled in drm_panel"), we want to remove needless code from panel drivers that was storing and double-checking the prepared/enabled state. Even if someone was relying on the double-check before, that double-check is now in the core and not needed in individual drivers. This pile of panel drivers appears to be simple to handle. Based on code inspection they seemed to be using the prepared/enabled state simply for double-checking that nothing else in the kernel called them inconsistently. Now that the core drm_panel is doing the double checking (and warning) it should be very clear that these devices don't need their own double-check. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230804140605.RFC.1.Ia54954fd2f7645c1b86597494902973f57feeb71@changeid
-
- 11 Sep, 2023 9 commits
-
-
Arunpravin Paneer Selvam authored
- Move roundup_power_of_two() to drm buddy file to support the new try harder mechanism for contiguous allocation. - Move trim function call to drm_buddy_alloc_blocks() function. Signed-off-by: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230909160902.15644-2-Arunpravin.PaneerSelvam@amd.comReviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Christian König <christian.koenig@amd.com>
-
Arunpravin Paneer Selvam authored
- Move roundup_power_of_two() and IS_ALIGNED() computations to drm buddy file to support the new try harder mechanism for contiguous allocation. - Move trim function call to drm_buddy_alloc_blocks() function. Signed-off-by: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230909160902.15644-2-Arunpravin.PaneerSelvam@amd.comReviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Christian König <christian.koenig@amd.com>
-
Arunpravin Paneer Selvam authored
Problem statement: The current method roundup_power_of_two() to allocate contiguous address triggers -ENOSPC in some cases even though we have enough free spaces and so to help with that we introduce a try harder mechanism. In case of -ENOSPC, the new try harder mechanism rounddown the original size to power of 2 and iterating over the round down sized freelist blocks to allocate the required size traversing RHS and LHS. As part of the above new method implementation we moved contiguous/alignment size computation part and trim function to the drm buddy file. v2: Modify the alloc_range() function to return total allocated size on -ENOSPC err and traverse RHS/LHS to allocate the required size (Matthew). Signed-off-by: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230909160902.15644-1-Arunpravin.PaneerSelvam@amd.comReviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Christian König <christian.koenig@amd.com>
-
Thomas Zimmermann authored
Remove all unnecessary include statements from fbmem.c. Most of them were for functionality that has meanwhile been moved into other files. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230907085408.9354-8-tzimmermann@suse.de
-
Thomas Zimmermann authored
Remove the two empty helpers for the case the CONFIG_FB_LOGO_EXTRA has not been set. They are internal functions and only called once. Providing empty replacements seems like overkill. Instead protect the call sites with a test for CONFIG_FB_LOGO_EXTRA. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230907085408.9354-7-tzimmermann@suse.de
-
Thomas Zimmermann authored
Move the fbdev function for displaying boot-up logos into their own file fb_logo.c. Only build fb_logo.c if CONFIG_LOGO has been selected. No functional changes. v2: * include fb_internal.h (kernel test robot) * simplify option-parsing ifdefs * build fb_logo.o iff CONFIG_LOGO has been set Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230907085408.9354-6-tzimmermann@suse.de
-
Thomas Zimmermann authored
The interfaces for the fbdev logo are not used outside of the fbdev module. Hence declare the fbdev logo functions in the internal header file and remove their symbol exports. Only build the functions if CONFIG_LOGO has been selected. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230907085408.9354-5-tzimmermann@suse.de
-
Thomas Zimmermann authored
Fix a number of warnings from checkpatch.pl in this code before moving it into a separate file. This includes * Prefer 'unsigned int' to bare use of 'unsigned' * space required after that ',' (ctx:VxV) * space prohibited after that open parenthesis '(' * suspect code indent for conditional statements (16, 32) * braces {} are not necessary for single statement blocks No functional changes. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230907085408.9354-4-tzimmermann@suse.de
-
Thomas Zimmermann authored
The fbcon module takes care of displaying the logo, if any. Remove the code form mmpfb. It is probably no tworking as expected, as it interferes with the framebuffer console. If we want to display the logo without fbcon, we should implement this in the fbdev core code. v2: * add a note on fbcon interference (Javier) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230907085408.9354-3-tzimmermann@suse.de
-