- Feb 16, 2024
-
-
Tomeu Vizoso authored
Otherwise, the VIM3 boards hang during boot, probably due to a spike in power usage when both the GPU, DPU and NPU are probed.
-
- Feb 11, 2024
-
-
David Heidelberg authored
This reverts commit 78a1eb10.
-
David Heidelberg authored
This reverts commit ae795abe.
-
David Heidelberg authored
Useful for many machines, required for some > 2023 machines. Signed-off-by:
David Heidelberg <david@ixit.cz>
-
These ones will be needed to make use fo the NN and TP units in the NPUs based on Vivante IP. Signed-off-by:
Tomeu Vizoso <tomeu@tomeuvizoso.net> Acked-by:
Christian Gmeiner <cgmeiner@igalia.com>
-
Otherwise they are left at 24MHz and the NPU runs very slowly. Signed-off-by:
Tomeu Vizoso <tomeu@tomeuvizoso.net> Suggested-by:
Lucas Stach <l.stach@pengutronix.de> Reviewed-by:
Neil Armstrong <neil.armstrong@linaro.org>
-
David Heidelberg authored
Signed-off-by:
David Heidelberg <david@ixit.cz>
-
David Heidelberg authored
Signed-off-by:
David Heidelberg <david@ixit.cz>
-
David Heidelberg authored
We need `amdgpu.gttsize=3072` for the testing on machines with =< 4G RAM. This reverts commit f1f6f48a.
-
Use the freshly defined DRM_AUX_HPD_BRIDGE instead of open-coding the same functionality for the DRM bridge chain termination. Acked-by:
Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
-
Use the freshly defined DRM_AUX_HPD_BRIDGE instead of open-coding the same functionality for the DRM bridge chain termination. Reviewed-by:
Bjorn Andersson <andersson@kernel.org> Acked-by:
Bjorn Andersson <andersson@kernel.org> Signed-off-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
-
Several USB-C controllers implement a pretty simple DRM bridge which implements just the HPD notification operations. Add special helper for creating such simple bridges. Acked-by:
Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
-
Switch to using the new DRM_AUX_BRIDGE helper to create the transparent DRM bridge device instead of handcoding corresponding functionality. Reviewed-by:
Heikki Krogerus <heikki.krogerus@linux.intel.com> Acked-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
-
Switch to using the new DRM_AUX_BRIDGE helper to create the transparent DRM bridge device instead of handcoding corresponding functionality. Acked-by:
Vinod Koul <vkoul@kernel.org> Signed-off-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
-
Define a helper for creating simple transparent bridges which serve the only purpose of linking devices into the bridge chain up to the last bridge representing the connector. This is especially useful for DP/USB-C bridge chains, which can span across several devices, but do not require any additional functionality from the intermediate bridges. Reviewed-by:
Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
-
This is found popular brands such as StarTech.com or Delock, and has been a source of frustration to quite a few people, if I can trust Amazon comments complaining about Linux support via the official out-of-the-tree driver. Signed-off-by:
Martin Peres <martin.peres@mupuf.org>
-
David Heidelberg authored
Change for v6.4: - rename sc7180-trogdor-kingoftown-r1 to sc7180-trogdor-kingoftown - enable BCM2835 on ARM64 (Raspberry Pi) thx @ Eric Change for v6.6: - source symlink in modules directory no longer exists - enable QRTR Signed-off-by:
David Heidelberg <david@ixit.cz>
-
David Heidelberg authored
These configs are optimized to test graphics hardware. All machines boot directly from NFS and essencial modules are present directly in the kernel. Can be applied together with default architecture defconfigs by running: ./scripts/kconfig/merge_config.sh ${DEFCONFIG} kernel/configs/mesa3d-ci_"${KERNEL_ARCH}".config Signed-off-by:
David Heidelberg <david@ixit.cz>
-
Needed to keep the GPU alive in our farm setup. Signed-off-by:
David Heidelberg <david@ixit.cz>
-
When the special handling of qcom,adreno-smmu was moved into qcom_smmu_create(), it was overlooked that we didn't have all the required entries in qcom_smmu_impl_of_match. So we stopped getting adreno_smmu_priv on sc7180, breaking per-process pgtables. Fixes: 30b912a0 ("iommu/arm-smmu-qcom: Move the qcom,adreno-smmu check into qcom_smmu_create") Signed-off-by:
Rob Clark <robdclark@chromium.org>
-
Kernel changes due during 5.16 had moved apq8016-sbc.dtsi code to the dts file. This patch just redirects the changes made by commit 6a675287edb646020e7dae5766f741a1f9313e44. Where Emma described: > Without this, the presence of the fastboot micro cable in the CI farm > causes the HW to stay in gadget mode instead of host, so it doesn't > find the network. Signed-off-by:
Guilherme Gallo <guilherme.gallo@collabora.com>
-
This reverts commit 5b17993f1d2e988ec7f67f2d796754396dc413c3. Signed-off-by:
Eric Anholt <eric@anholt.net>
-
Currently this is just set from the special qcom,adreno-smmu iommu. But we are not *yet* using that for a5xx. Meanwhile we still need the HUPCF bit set so iommu faults in CI do not take out the CP and cause a follow- on cascade of fail. On qcom systems, it is safe to set HUPCF everywhere so do that. Signed-off-by:
Rob Clark <robdclark@chromium.org>
-
This is a workaround for old cheza firmware v2: - add ifdef for ARM64 since the change isn't relevant outside of it Signed-off-by:
Eric Anholt <eric@anholt.net>
-
This reverts commit 21ea4b62. Otherwise, cheza fails to probe drm-msm.
-
- Feb 05, 2024
-
-
Greg Kroah-Hartman authored
Link: https://lore.kernel.org/r/20240203035359.041730947@linuxfoundation.org Tested-by:
Takeshi Ogasawara <takeshi.ogasawara@futuring-girl.com> Tested-by:
Florian Fainelli <florian.fainelli@broadcom.com> Link: https://lore.kernel.org/r/20240203174810.768708706@linuxfoundation.org Tested-by:
SeongJae Park <sj@kernel.org> Tested-by:
Florian Fainelli <florian.fainelli@broadcom.com> Tested-by:
Takeshi Ogasawara <takeshi.ogasawara@futuring-girl.com> Tested-by:
Bagas Sanjaya <bagasdotme@gmail.com> Tested-by:
Linux Kernel Functional Testing <lkft@linaro.org> Tested-by:
Justin M. Forbes <jforbes@fedoraproject.org> Tested-by:
Ron Economos <re@w6rz.net> Tested-by:
kernelci.org bot <bot@kernelci.org> Tested-by:
Jon Hunter <jonathanh@nvidia.com> Tested-by:
Allen Pais <apais@linux.microsoft.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Brett Creeley authored
[ Upstream commit d9407ff1 ] The PCIe reset handlers can run at the same time as the health thread. This can cause the health thread to stomp on the PCIe reset. Fix this by preventing the health thread from running while a PCIe reset is happening. As part of this use timer_shutdown_sync() during reset and remove to make sure the timer doesn't ever get rearmed. Fixes: ffa55858 ("pds_core: implement pci reset handlers") Signed-off-by:
Brett Creeley <brett.creeley@amd.com> Reviewed-by:
Shannon Nelson <shannon.nelson@amd.com> Reviewed-by:
Przemek Kitszel <przemyslaw.kitszel@intel.com> Link: https://lore.kernel.org/r/20240129234035.69802-2-brett.creeley@amd.com Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
SRINIVASAN SHANMUGAM authored
[ Upstream commit 16da3990 ] Return 0 for success scenairos in 'gmc_v6/7/8/9_0_hw_init()' Fixes the below: drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c:920 gmc_v6_0_hw_init() warn: missing error code? 'r' drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c:1104 gmc_v7_0_hw_init() warn: missing error code? 'r' drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c:1224 gmc_v8_0_hw_init() warn: missing error code? 'r' drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c:2347 gmc_v9_0_hw_init() warn: missing error code? 'r' Fixes: fac4ebd7 ("drm/amdgpu: Fix with right return code '-EIO' in 'amdgpu_gmc_vram_checking()'") Cc: Christian König <christian.koenig@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
Srinivasan Shanmugam <srinivasan.shanmugam@amd.com> Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Johan Hovold authored
commit b53cc614 upstream. The PA gain can be set in steps of 1.5 dB from -3 dB to 18 dB, that is, in 15 levels. Fix the dB values for the PA volume control as experiments using wsa8835 show that the first 16 levels all map to the same lowest gain while the last three map to the highest gain. These values specifically need to be correct for the sound server to provide proper volume control. Note that level 0 (-3 dB) does not mute the PA so the mute flag should also not be set. Fixes: cdb09e62 ("ASoC: codecs: wsa883x: add control, dapm widgets and map") Cc: stable@vger.kernel.org # 6.0 Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by:
Johan Hovold <johan+linaro@kernel.org> Link: https://msgid.link/r/20240119112420.7446-2-johan+linaro@kernel.org Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Johan Hovold authored
commit 46188db0 upstream. The LPASS WSA macro codec driver is updating the digital gain settings behind the back of user space on DAPM events if companding has been enabled. As compander control is exported to user space, this can result in the digital gain setting being incremented (or decremented) every time the sound server is started and the codec suspended depending on what the UCM configuration looks like. Soon enough playback will become distorted (or too quiet). This is specifically a problem on the Lenovo ThinkPad X13s as this bypasses the limit for the digital gain setting that has been set by the machine driver. Fix this by simply dropping the compander gain offset hack. If someone cares about modelling the impact of the compander setting this can possibly be done by exporting it as a volume control later. Note that the volume registers still need to be written after enabling clocks in order for any prior updates to take effect. Fixes: 2c4066e5 ("ASoC: codecs: lpass-wsa-macro: add dapm widgets and route") Cc: stable@vger.kernel.org # 5.11 Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by:
Johan Hovold <johan+linaro@kernel.org> Link: https://msgid.link/r/20240119112420.7446-4-johan+linaro@kernel.org Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Johan Hovold authored
commit 4d0e8bdf upstream. The lowest headphones volume setting does not mute so the leave the TLV mute flag unset. This is specifically needed to let the sound server use the lowest gain setting. Fixes: c03226ba ("ASoC: codecs: wcd938x: fix dB range for HPHL and HPHR") Cc: <stable@vger.kernel.org> # 6.5 Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by:
Johan Hovold <johan+linaro@kernel.org> Link: https://msgid.link/r/20240122091130.27463-1-johan+linaro@kernel.org Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Johan Hovold authored
commit c481016b upstream. The UCM configuration for the Lenovo ThinkPad X13s has up until now been setting the speaker PA volume to the minimum -3 dB when enabling the speakers, but this does not prevent the user from increasing the volume further. Limit the digital gain and PA volumes to a combined -3 dB in the machine driver to reduce the risk of speaker damage until we have active speaker protection in place (or higher safe levels have been established). Note that the PA volume limit cannot be set lower than 0 dB or PulseAudio gets confused when the first 16 levels all map to -3 dB. Also note that this will probably need to be generalised using machine-specific limits, but a common limit should do for now. Cc: <stable@vger.kernel.org> # 6.5 Signed-off-by:
Johan Hovold <johan+linaro@kernel.org> Link: https://msgid.link/r/20240122181819.4038-3-johan+linaro@kernel.org Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Zhengchao Shao authored
commit 486058f4 upstream. As suggested by Paolo in link[1], if the memory allocation fails, the mm layer will emit a lot warning comprising the backtrace, so remove the print. [1] https://lore.kernel.org/all/20231118081653.1481260-1-shaozhengchao@huawei.com/ Suggested-by:
Paolo Abeni <pabeni@redhat.com> Signed-off-by:
Zhengchao Shao <shaozhengchao@huawei.com> Reviewed-by:
Hangbin Liu <liuhangbin@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Yonghong Song authored
commit 56925f38 upstream. With previous patch, one of subtests in test_btf_id becomes flaky and may fail. The following is a failing example: Error: #26 btf Error: #26/174 btf/BTF ID Error: #26/174 btf/BTF ID btf_raw_create:PASS:check 0 nsec btf_raw_create:PASS:check 0 nsec test_btf_id:PASS:check 0 nsec ... test_btf_id:PASS:check 0 nsec test_btf_id:FAIL:check BTF lingersdo_test_get_info:FAIL:check failed: -1 The test tries to prove a btf_id not available after the map is closed. But btf_id is freed only after workqueue and a rcu grace period, compared to previous case just after a rcu grade period. Depending on system workload, workqueue could take quite some time to execute function bpf_map_free_deferred() which may cause the test failure. Instead of adding arbitrary delays, let us remove the logic to check btf_id availability after map is closed. Signed-off-by:
Yonghong Song <yonghong.song@linux.dev> Link: https://lore.kernel.org/r/20231214203820.1469402-1-yonghong.song@linux.dev Signed-off-by:
Alexei Starovoitov <ast@kernel.org> Signed-off-by:
Samasth Norway Ananda <samasth.norway.ananda@oracle.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Huacai Chen authored
commit 5056c596 upstream. Machines which have more than 8 nodes fail to boot SMP after commit a2ccf463 ("LoongArch/smp: Call rcutree_report_cpu_starting() earlier"). Because such machines use tlb-based per-cpu base address rather than dmw-based per-cpu base address, resulting per-cpu variables can only be accessed after tlb_init(). But rcutree_report_cpu_starting() is now called before tlb_init() and accesses per-cpu variables indeed. Since the original patch want to avoid the lockdep warning caused by page allocation in tlb_init(), we can move rcutree_report_cpu_starting() to tlb_init() where after tlb exception configuration but before page allocation. Fixes: a2ccf463 ("LoongArch/smp: Call rcutree_report_cpu_starting() earlier") Signed-off-by:
Huacai Chen <chenhuacai@loongson.cn> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Konrad Dybcio authored
commit 6ab502bc upstream. Some devices power the DSI PHY/PLL through a power rail that we model as a GENPD. Enable runtime PM to make it suspendable. Signed-off-by:
Konrad Dybcio <konrad.dybcio@linaro.org> Reviewed-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/543352/ Link: https://lore.kernel.org/r/20230620-topic-dsiphy_rpm-v2-2-a11a751f34f0@linaro.org Signed-off-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by:
Amit Pundir <amit.pundir@linaro.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Jonathan Gray authored
This reverts commit 107a1163. duplicated a change made in 6.6.8 a8f922ad Cc: stable@vger.kernel.org # 6.6 Signed-off-by:
Jonathan Gray <jsg@jsg.id.au> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Marco Elver authored
commit f6564fce upstream. Alexander Potapenko writes in [1]: "For every memory access in the code instrumented by KMSAN we call kmsan_get_metadata() to obtain the metadata for the memory being accessed. For virtual memory the metadata pointers are stored in the corresponding `struct page`, therefore we need to call virt_to_page() to get them. According to the comment in arch/x86/include/asm/page.h, virt_to_page(kaddr) returns a valid pointer iff virt_addr_valid(kaddr) is true, so KMSAN needs to call virt_addr_valid() as well. To avoid recursion, kmsan_get_metadata() must not call instrumented code, therefore ./arch/x86/include/asm/kmsan.h forks parts of arch/x86/mm/physaddr.c to check whether a virtual address is valid or not. But the introduction of rcu_read_lock() to pfn_valid() added instrumented RCU API calls to virt_to_page_or_null(), which is called by kmsan_get_metadata(), so there is an infinite recursion now. I do not think it is correct to stop that recursion by doing kmsan_enter_runtime()/kmsan_exit_runtime() in kmsan_get_metadata(): that would prevent instrumented functions called from within the runtime from tracking the shadow values, which might introduce false positives." Fix the issue by switching pfn_valid() to the _sched() variant of rcu_read_lock/unlock(), which does not require calling into RCU. Given the critical section in pfn_valid() is very small, this is a reasonable trade-off (with preemptible RCU). KMSAN further needs to be careful to suppress calls into the scheduler, which would be another source of recursion. This can be done by wrapping the call to pfn_valid() into preempt_disable/enable_no_resched(). The downside is that this sacrifices breaking scheduling guarantees; however, a kernel compiled with KMSAN has already given up any performance guarantees due to being heavily instrumented. Note, KMSAN code already disables tracing via Makefile, and since mmzone.h is included, it is not necessary to use the notrace variant, which is generally preferred in all other cases. Link: https://lkml.kernel.org/r/20240115184430.2710652-1-glider@google.com [1] Link: https://lkml.kernel.org/r/20240118110022.2538350-1-elver@google.com Fixes: 5ec8e8ea ("mm/sparsemem: fix race in accessing memory_section->usage") Signed-off-by:
Marco Elver <elver@google.com> Reported-by:
Alexander Potapenko <glider@google.com> Reported-by:
<syzbot+93a9e8a3dea8d6085e12@syzkaller.appspotmail.com> Reviewed-by:
Alexander Potapenko <glider@google.com> Tested-by:
Alexander Potapenko <glider@google.com> Cc: Charan Teja Kalla <quic_charante@quicinc.com> Cc: Borislav Petkov (AMD) <bp@alien8.de> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Huang Shijie authored
commit 7b1a09e4 upstream. The init_irq_stacks() has been changed to use the correct node: https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/commit/?id=75b5e0bf90bf The init_irq_scs() has the same issue with init_irq_stacks(): cpu_to_node() is not initialized yet, it does not work. This patch uses early_cpu_to_node() to set the init_irq_scs() with the correct node. Signed-off-by:
Huang Shijie <shijie@os.amperecomputing.com> Reviewed-by:
Catalin Marinas <catalin.marinas@arm.com> Link: https://lore.kernel.org/r/20231213012046.12014-1-shijie@os.amperecomputing.com Signed-off-by:
Will Deacon <will@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-