Commits · steev/linux

Signed-off-by: Steev Klimaszewski <steev@kali.org>

I don't like limiting the cpu so early, so let it get a bit warmer before doing so.

Some DE compositors like GNOME's mutter can't handle way too good msm driver. Handicap it to meet the mistaken expectations of the userspace. This patch is taken from CROS with minor modifications. Link: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/30aef5779b6108baaea00750064338bf0ed145c2%5E%21/ Signed-off-by: Nikita Travkin <nikita@trvn.ru>

The Lenovo Thinkpad X13s has a WCN6855 Bluetooth controller on uart2, add this. Signed-off-by: Steev Klimaszewski <steev@kali.org> Link: https://lore.kernel.org/r/20230207052829.3996-5-steev@kali.org

Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Steev Klimaszewski <steev@kali.org> Reviewed-by: Brian Masney <bmasney@redhat.com> Link: https://lore.kernel.org/r/20230207052829.3996-4-steev@kali.org

Added regulators,GPIOs and changes required to power on/off wcn6855. Added support for firmware download for wcn6855. Signed-off-by: Steev Klimaszewski <steev@kali.org> Link: https://lore.kernel.org/r/20230207052829.3996-3-steev@kali.org

Add bindings for the QTI WCN6855 chipset. Signed-off-by: Steev Klimaszewski <steev@kali.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20230207052829.3996-2-steev@kali.org

Signed-off-by: Steev Klimaszewski <steev@kali.org>

Move the include of of_address.h to the top of the file where it belongs. Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20230306100722.28485-11-johan+linaro@kernel.org

Make sure to destroy the workqueue also in case of early errors during bind (e.g. a subcomponent failing to bind). Since commit c3b790e ("drm: Manage drm_mode_config_init with drmm_") the mode config will be freed when the drm device is released also when using the legacy interface, but add an explicit cleanup for consistency and to facilitate backporting. Fixes: 060530f ("drm/msm: use componentised device support") Cc: stable@vger.kernel.org # 3.15 Cc: Rob Clark <robdclark@gmail.com> Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20230306100722.28485-9-johan+linaro@kernel.org

Add the missing sanity check to handle workqueue allocation failures. Fixes: c8afe68 ("drm/msm: basic KMS driver for snapdragon") Cc: stable@vger.kernel.org # 3.12 Cc: Rob Clark <robdclark@gmail.com> Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20230306100722.28485-8-johan+linaro@kernel.org

Make sure to release the VRAM buffer also in a case a subcomponent fails to bind. Fixes: d863f0c ("drm/msm: Call msm_init_vram before binding the gpu") Cc: stable@vger.kernel.org # 5.11 Cc: Craig Tatlor <ctatlor97@gmail.com> Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20230306100722.28485-7-johan+linaro@kernel.org

Make sure to free the DRM device also in case of early errors during bind(). Fixes: 2027e5b ("drm/msm: Initialize MDSS irq domain at probe time") Cc: stable@vger.kernel.org # 5.17 Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20230306100722.28485-6-johan+linaro@kernel.org

In case of early initialisation errors and on platforms that do not use the DPU controller, the deinitilisation code can be called with the kms pointer set to NULL. Fixes: f026e43 ("drm/msm: Convert to Linux IRQ interfaces") Cc: stable@vger.kernel.org # 5.14 Cc: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20230306100722.28485-5-johan+linaro@kernel.org

In case of early initialisation errors and on platforms that do not use the DPU controller, the deinitilisation code can be called with the kms pointer set to NULL. Fixes: 9865948 ("drm/msm: add support to take dpu snapshot") Cc: stable@vger.kernel.org # 5.14 Cc: Abhinav Kumar <quic_abhinavk@quicinc.com> Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20230306100722.28485-4-johan+linaro@kernel.org

This reverts commit 8636500. A recent commit tried to address a drm device leak in the early msm_drm_uninit() error paths but ended up making things worse. Specifically, it moved the drm device reference put in msm_drm_uninit() to msm_drm_init() which means that the drm would now be leaked on normal unbind. For reasons that were never spelled out, it also added kms NULL pointer checks to a couple of helper functions that had nothing to do with the paths modified by the patch. Instead of trying to salvage this incrementally, let's revert the bad commit so that clean and backportable fixes can be added in its place. Fixes: 8636500 ("drm/msm: Fix failure paths in msm_drm_init()") Cc: Akhil P Oommen <quic_akhilpo@quicinc.com> Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20230306100722.28485-3-johan+linaro@kernel.org

…queue" This reverts commit 643b7d0. A recent patch that tried to fix up the msm_drm_init() paths with respect to the workqueue but only ended up making things worse: First, the newly added calls to msm_drm_uninit() on early errors would trigger NULL-pointer dereferences, for example, as the kms pointer would not have been initialised. (Note that these paths were also modified by a second broken error handling patch which in effect cancelled out this part when merged.) Second, the newly added allocation sanity check would still leak the previously allocated drm device. Instead of trying to salvage what was badly broken (and clearly not tested), let's revert the bad commit so that clean and backportable fixes can be added in its place. Fixes: 643b7d0 ("drm/msm: Add missing check and destroy for alloc_ordered_workqueue") Cc: Jiasheng Jiang <jiasheng@iscas.ac.cn> Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20230306100722.28485-2-johan+linaro@kernel.org

The second to last argument is clk_root (root of the clock), however the code called q6prm_request_lpass_clock() with clk_attr instead (copy-paste error). This effectively was passing value of 1 as root clock which worked on some of the SoCs (e.g. SM8450) but fails on others, depending on the ADSP. For example on SM8550 this "1" as root clock is not accepted and results in errors coming from ADSP. Fixes: 2f20640 ("ASoC: qdsp6: qdsp6: q6prm: handle clk disable correctly") Cc: <stable@vger.kernel.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20230302122908.221398-1-krzysztof.kozlowski@linaro.org

v2: rebase Signed-off-by: Rob Clark <robdclark@chromium.org> Link: https://lore.kernel.org/r/20230302235356.3148279-16-robdclark@gmail.com

Drop our custom thing and switch to drm_crtc_next_vblank_start() for calculating the time of the start of the next vblank period. Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20230302235356.3148279-15-robdclark@gmail.com

Add a way for various userspace waits to signal urgency. Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20230302235356.3148279-14-robdclark@gmail.com

Track the nearest deadline on a fence timeline and set a timer to expire shortly before to trigger boost if the fence has not yet been signaled. v2: rebase Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20230302235356.3148279-13-robdclark@gmail.com

For an atomic commit updating a single CRTC (ie. a pageflip) calculate the next vblank time, and inform the fence(s) of that deadline. v2: Comment typo fix (danvet) Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Rob Clark <robdclark@chromium.org> Link: https://lore.kernel.org/r/20230302235356.3148279-12-robdclark@gmail.com

Will be used in the next commit to set a deadline on fences that an atomic update is waiting on. v2: Calculate time at *start* of vblank period, not end v3: Fix kbuild complaints Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Mario Kleiner <mario.kleiner.de@gmail.com> Link: https://lore.kernel.org/r/20230302235356.3148279-11-robdclark@gmail.com

Add a new flag to let userspace provide a deadline as a hint for syncobj and timeline waits. This gives a hint to the driver signaling the backing fences about how soon userspace needs it to compete work, so it can addjust GPU frequency accordingly. An immediate deadline can be given to provide something equivalent to i915 "wait boost". v2: Use absolute u64 ns value for deadline hint, drop cap and driver feature flag in favor of allowing count_handles==0 as a way for userspace to probe kernel for support of new flag v3: More verbose comments about UAPI Signed-off-by: Rob Clark <robdclark@chromium.org> Link: https://lore.kernel.org/r/20230302235356.3148279-10-robdclark@gmail.com

As the finished fence is the one that is exposed to userspace, and therefore the one that other operations, like atomic update, would block on, we need to propagate the deadline from from the finished fence to the actual hw fence. v2: Split into drm_sched_fence_set_parent() (ckoenig) v3: Ensure a thread calling drm_sched_fence_set_deadline_finished() sees fence->parent set before drm_sched_fence_set_parent() does this test_bit(DMA_FENCE_FLAG_HAS_DEADLINE_BIT). Signed-off-by: Rob Clark <robdclark@chromium.org> Acked-by: Luben Tuikov <luben.tuikov@amd.com> Link: https://lore.kernel.org/r/20230302235356.3148279-9-robdclark@gmail.com

This consists of simply storing the most recent deadline, and adding an ioctl to retrieve the deadline. This can be used in conjunction with the SET_DEADLINE ioctl on a fence fd for testing. Ie. create various sw_sync fences, merge them into a fence-array, set deadline on the fence-array and confirm that it is propagated properly to each fence. v2: Switch UABI to express deadline as u64 v3: More verbose UAPI docs, show how to convert from timespec v4: Better comments, track the soonest deadline, as a normal fence implementation would, return an error if no deadline set. Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Christian König <christian.koenig@amd.com> Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com> Link: https://lore.kernel.org/r/20230302235356.3148279-8-robdclark@gmail.com

The initial purpose is for igt tests, but this would also be useful for compositors that wait until close to vblank deadline to make decisions about which frame to show. The igt tests can be found at: https://gitlab.freedesktop.org/robclark/igt-gpu-tools/-/commits/fence-deadline v2: Clarify the timebase, add link to igt tests v3: Use u64 value in ns to express deadline. v4: More doc Signed-off-by: Rob Clark <robdclark@chromium.org> Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com> Link: https://lore.kernel.org/r/20230302235356.3148279-7-robdclark@gmail.com

We had all of the internal driver APIs, but not the all important userspace uABI, in the dma-buf doc. Fix that. And re-arrange the comments slightly as otherwise the comments for the ioctl nr defines would not show up. v2: Fix docs build warning coming from newly including the uabi header in the docs build Signed-off-by: Rob Clark <robdclark@chromium.org> Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com> Link: https://lore.kernel.org/r/20230302235356.3148279-6-robdclark@gmail.com

Add a way to set a deadline on remaining resv fences according to the requested usage. Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://lore.kernel.org/r/20230302235356.3148279-5-robdclark@gmail.com

Propagate the deadline to all the fences in the chain. v2: Use dma_fence_chain_contained [Tvrtko] Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Christian König <christian.koenig@amd.com> for this one. Link: https://lore.kernel.org/r/20230302235356.3148279-4-robdclark@gmail.com

Propagate the deadline to all the fences in the array. Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://lore.kernel.org/r/20230302235356.3148279-3-robdclark@gmail.com

Add a way to hint to the fence signaler of an upcoming deadline, such as vblank, which the fence waiter would prefer not to miss. This is to aid the fence signaler in making power management decisions, like boosting frequency as the deadline approaches and awareness of missing deadlines so that can be factored in to the frequency scaling. v2: Drop dma_fence::deadline and related logic to filter duplicate deadlines, to avoid increasing dma_fence size. The fence-context implementation will need similar logic to track deadlines of all the fences on the same timeline. [ckoenig] v3: Clarify locking wrt. set_deadline callback v4: Clarify in docs comment that this is a hint v5: Drop DMA_FENCE_FLAG_HAS_DEADLINE_BIT. v6: More docs v7: Fix typo, clarify past deadlines Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Christian König <christian.koenig@amd.com> Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com> Reviewed-by: Bagas Sanjaya <bagasdotme@gmail.com> Link: https://lore.kernel.org/r/20230302235356.3148279-2-robdclark@gmail.com

Clean up the component ops initialisers which were indented one level too far. Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20230303164807.13124-5-johan+linaro@kernel.org

The runtime PM status can only be updated while runtime PM is disabled. Drop the bogus pm_runtime_set_active() call that was made after enabling runtime PM and which (incidentally but correctly) left the runtime PM status set to 'suspended'. Fixes: 2c087a3 ("drm/msm/adreno: Load the firmware before bringing up the hardware") Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20230303164807.13124-4-johan+linaro@kernel.org

Commits on Mar 6, 2023