[Backport][6.6] Support KP950 for velinux-6.6#122
Open
jackYoung0915 wants to merge 80 commits intoopenvelinux:6.6-velinuxfrom
Open
[Backport][6.6] Support KP950 for velinux-6.6#122jackYoung0915 wants to merge 80 commits intoopenvelinux:6.6-velinuxfrom
jackYoung0915 wants to merge 80 commits intoopenvelinux:6.6-velinuxfrom
Conversation
jackYoung0915
force-pushed
the
bsk-opensource-6.6-yjs-KP950-new
branch
from
e883ac8 to
2a9ab6f
Compare
commit ce3d99c upstream. Based on grepping through the source code these drivers appear 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. All of the drivers in this patch were fairly straightforward to fix since they already had a call to drm_atomic_helper_shutdown() at remove/unbind time but were just lacking one at system shutdown. The only hitch is that some of these drivers use the component model to register/unregister their DRM devices. The shutdown callback is part of the original device. The typical solution here, based on how other DRM drivers do this, is to keep track of whether the device is bound based on drvdata. In most cases the drvdata is the drm_device, so we can just make sure it is NULL when the device is not bound. In some drivers, this required minor code changes. To make things simpler, drm_atomic_helper_shutdown() has been modified to consider a NULL drm_device as a noop in the patch ("drm/atomic-helper: drm_atomic_helper_shutdown(NULL) should be a noop"). Suggested-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Tested-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Acked-by: Maxime Ripard <mripard@kernel.org> Tested-by: Jernej Skrabec <jernej.skrabec@gmail.com> Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com> Reviewed-by: Sui Jingfeng <suijingfeng@loongson.cn> Tested-by: Sui Jingfeng <suijingfeng@loongson.cn> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230901163944.RFT.2.I9115e5d094a43e687978b0699cc1fe9f2a3452ea@changeid Signed-off-by: slim6882 <yangjunshuo@huawei.com>
commit 225a8d0 upstream. Implement polling for VGA and SIL164 connectors. Set the flag DRM_CONNECTOR_POLL_DISCONNECT for each to detect the removal of the monitor cable. Implement struct drm_connector_helper_funcs.detect_ctx for each type of connector by testing for EDID data. The helper drm_connector_helper_detect_ctx() implements .detect_ctx() on top of the connector's DDC channel. The function can be used by other drivers as companion to drm_connector_helper_get_modes(). v6: - change helper name to drm_connector_helper_detec_from_ddc() (Maxime, Sui) v5: - share implementation in drm_connector_helper_detect_ctx() (Maxime) - test for DDC presence with drm_probe_ddc() (Maxime, Jani) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Acked-by: Sui Jingfeng <sui.jingfeng@linux.dev> Acked-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240325200855.21150-13-tzimmermann@suse.de Signed-off-by: slim6882 <yangjunshuo@huawei.com>
commit ff2a391 upstream. Prefer the struct drm_edid based functions for reading the EDID and updating the connector. Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/386e3a64efbdd61c3eaed3f49ea9c3ebd4fcd41d.1715691257.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: slim6882 <yangjunshuo@huawei.com>
commit 239af7de8f23ce757bd8081f5e8aca18e505868e upstream. DRM's aperture functions have long been implemented as helpers under drivers/video/ for use with fbdev. Avoid the DRM wrappers by calling the video functions directly. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Cc: Xinliang Liu <xinliang.liu@linaro.org> Cc: Tian Tao <tiantao6@hisilicon.com> Cc: Xinwei Kong <kong.kongxinwei@hisilicon.com> Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: Yongqin Liu <yongqin.liu@linaro.org> Cc: John Stultz <jstultz@google.com> Acked-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240930130921.689876-6-tzimmermann@suse.de Signed-off-by: slim6882 <yangjunshuo@huawei.com>
commit 057e77972556aed4a0f1eed7eeb85024d0a22ba1 upstream. Add dp aux read/write functions. They are basic functions and will be used later. Signed-off-by: Baihan Li <libaihan@huawei.com> Signed-off-by: Yongbang Shi <shiyongbang@huawei.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Tian Tao <tiantao6@hisilicon.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250103093824.1963816-2-shiyongbang@huawei.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: slim6882 <yangjunshuo@huawei.com>
commit 54063d86e0369f53f180137e5e889bc19cd9015b upstream. Add link training process functions in this moduel. Signed-off-by: Baihan Li <libaihan@huawei.com> Signed-off-by: Yongbang Shi <shiyongbang@huawei.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Tian Tao <tiantao6@hisilicon.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250103093824.1963816-3-shiyongbang@huawei.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: slim6882 <yangjunshuo@huawei.com>
commit 94ee73ee30208f3d92b2f2a4f7d3346ba56245bf upstream. Build a dp level that hibmc driver can enable dp by calling their functions. Signed-off-by: Baihan Li <libaihan@huawei.com> Signed-off-by: Yongbang Shi <shiyongbang@huawei.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Tian Tao <tiantao6@hisilicon.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250103093824.1963816-4-shiyongbang@huawei.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: slim6882 <yangjunshuo@huawei.com>
commit 587013d72c1a217ced9f42a9a08c8013052cabfc upstream. Refactored struct hibmc_drm_private to separate VGA module from generic struct. Signed-off-by: Baihan Li <libaihan@huawei.com> Signed-off-by: Yongbang Shi <shiyongbang@huawei.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Tian Tao <tiantao6@hisilicon.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250103093824.1963816-5-shiyongbang@huawei.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: slim6882 <yangjunshuo@huawei.com>
commit 0ab6ea261c1fe4edbf4d99dfe65d8ebaae905092 upstream. To support DP interface displaying in hibmc driver. Add a encoder and connector for DP modual. The HPD function and get_edid function will be add in next series, so temporarily using 1024x768 as default in hibmc_dp_connector_get_modes() Signed-off-by: Baihan Li <libaihan@huawei.com> Signed-off-by: Yongbang Shi <shiyongbang@huawei.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Tian Tao <tiantao6@hisilicon.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250103093824.1963816-6-shiyongbang@huawei.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: slim6882 <yangjunshuo@huawei.com>
commit 9ab127a18018fb06bd42a54ed38bb7b8c449d686 upstream.
Without the DP helper code, the newly added displayport support
causes a link failure:
x86_64-linux-ld: drivers/gpu/drm/hisilicon/hibmc/dp/dp_aux.o: in function `hibmc_dp_aux_init':
dp_aux.c:(.text+0x37e): undefined reference to `drm_dp_aux_init'
x86_64-linux-ld: drivers/gpu/drm/hisilicon/hibmc/dp/dp_link.o: in function `hibmc_dp_link_set_pattern':
dp_link.c:(.text+0xae): undefined reference to `drm_dp_dpcd_write'
x86_64-linux-ld: drivers/gpu/drm/hisilicon/hibmc/dp/dp_link.o: in function `hibmc_dp_link_get_adjust_train':
dp_link.c:(.text+0x121): undefined reference to `drm_dp_get_adjust_request_voltage'
x86_64-linux-ld: dp_link.c:(.text+0x12e): undefined reference to `drm_dp_get_adjust_request_pre_emphasis'
x86_64-linux-ld: drivers/gpu/drm/hisilicon/hibmc/dp/dp_link.o: in function `hibmc_dp_link_training':
dp_link.c:(.text+0x2b0): undefined reference to `drm_dp_dpcd_write'
x86_64-linux-ld: dp_link.c:(.text+0x2e3): undefined reference to `drm_dp_dpcd_write'
Add both DRM_DISPLAY_DP_HELPER and DRM_DISPLAY_HELPER, which is
in turn required by the former.
Fixes: 0ab6ea261c1f ("drm/hisilicon/hibmc: add dp module in hibmc")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20250127071059.617567-1-arnd@kernel.org
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: slim6882 <yangjunshuo@huawei.com>
commit f9698f802e50fbe696b3ac6f82c0e966574a3edb upstream. Move the macros below their corresponding registers to make them more obvious. Signed-off-by: Baihan Li <libaihan@huawei.com> Signed-off-by: Yongbang Shi <shiyongbang@huawei.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20250331074212.3370287-2-shiyongbang@huawei.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: slim6882 <yangjunshuo@huawei.com>
… and pre-emphasis commit 9e736cd444f49efa2334e405f7a59773ea02155b upstream. This dp controller need features of digital-to-analog conversion and high-speed transmission in chip by its extern serdes controller. Our serdes cfg is relatively simple, just need two register configurations. Don't need too much functions, like: power on/off, initialize, and some complex configurations, so I'm not going to use the phy framework. This serdes is inited and configured in dp initialization, and also integrating them into link training process. For rate changing, we can change from 1.62-8.2Gpbs by cfg reg. For voltage and pre-emphasis levels changing, we can cfg different serdes ffe value. Signed-off-by: Baihan Li <libaihan@huawei.com> Signed-off-by: Yongbang Shi <shiyongbang@huawei.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20250331074212.3370287-3-shiyongbang@huawei.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: slim6882 <yangjunshuo@huawei.com>
commit 5f80fb4d6abd1f7f4007e4bf8dd75a8c71d2f724 upstream. Add dp serdes cfg in link training process, and related adapting and modificating. Change some init values about training, because we want completely to negotiation process, so we start with the maximum rate and the electrical characteristic level is 0. Because serdes default cfgs is changed and used in hibmc_kms_init(), we changed the if-statement to check whether the value is 0. Signed-off-by: Baihan Li <libaihan@huawei.com> Signed-off-by: Yongbang Shi <shiyongbang@huawei.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20250331074212.3370287-4-shiyongbang@huawei.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: slim6882 <yangjunshuo@huawei.com>
commit 1e7f35512e77dd7276e91ade4e03807f88b97eb3 upstream. Because the drm_aux of struct hibmc_dp_dev's member is not easy to get in hibmc_drm_dp.c, move the drm_aux to struct hibmc_dp. Then there are some adaptations and modifications to make this patch compile. Signed-off-by: Baihan Li <libaihan@huawei.com> Signed-off-by: Yongbang Shi <shiyongbang@huawei.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20250331074212.3370287-5-shiyongbang@huawei.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: slim6882 <yangjunshuo@huawei.com>
…nnel commit bd1c935811ae6bd112321c50ed83444eca4facc8 upstream. Add registering drm_aux and use it to get connector edid with drm functions. Add ddc channel in connector initialization to put drm_aux in drm_connector. Signed-off-by: Baihan Li <libaihan@huawei.com> Signed-off-by: Yongbang Shi <shiyongbang@huawei.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20250331074212.3370287-6-shiyongbang@huawei.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: slim6882 <yangjunshuo@huawei.com>
commit 2f6182616cfdb154e2ecfe9554bb814b8a6378e9 upstream. DP controller can support generating a color bar signal over the DisplayPort interface. This can be useful to check for possible DDR or GPU problems, as the signal generator resides completely in the DP block. Add debugfs file that controls colorbar generator. echo: config the color bar register to display cat: print the color bar configuration Signed-off-by: Baihan Li <libaihan@huawei.com> Signed-off-by: Yongbang Shi <shiyongbang@huawei.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20250331074212.3370287-7-shiyongbang@huawei.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: slim6882 <yangjunshuo@huawei.com>
commit 3c7623fb5bb6c319531b941b15b7bfc12455d3d3 upstream. Add HPD interrupt enable functions in drm framework, and also add detect_ctx functions. Because of the debouncing when HPD pulled out, add 200 ms delay in detect. Add link reset process to reset link status when a new connector pulgged in. Signed-off-by: Baihan Li <libaihan@huawei.com> Signed-off-by: Yongbang Shi <shiyongbang@huawei.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20250331074212.3370287-8-shiyongbang@huawei.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: slim6882 <yangjunshuo@huawei.com>
commit b11bc1ae46587f3563c47078e605184f18e7fa57 upstream. To realize HPD feature, request irq for HPD , add its handler function. We use pci_alloc_irq_vectors() to get our msi irq, because we have two interrupts now. Signed-off-by: Baihan Li <libaihan@huawei.com> Signed-off-by: Yongbang Shi <shiyongbang@huawei.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20250331074212.3370287-9-shiyongbang@huawei.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: slim6882 <yangjunshuo@huawei.com>
commit 4c962bc929f1734d209a0862359e25fef8f56fa0 upstream. Because the connected VGA connector would make driver can't get the userspace call, adding detect_ctx in vga connector to make HPD active userspace. Signed-off-by: Baihan Li <libaihan@huawei.com> Signed-off-by: Yongbang Shi <shiyongbang@huawei.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20250331074212.3370287-10-shiyongbang@huawei.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: slim6882 <yangjunshuo@huawei.com>
…failed commit e5f48bfa2ae0806d5f51fb8061afc619a73599a7 upstream. Currently the driver missed to clean the i2c adapter when vdac init failed. It may cause resource leak. Fixes: a0d078d ("drm/hisilicon: Features to support reading resolutions from EDID") Signed-off-by: Baihan Li <libaihan@huawei.com> Signed-off-by: Yongbang Shi <shiyongbang@huawei.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250813094238.3722345-2-shiyongbang@huawei.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: slim6882 <yangjunshuo@huawei.com>
commit 8bed4ec42a4e0dc8113172696ff076d1eb6d8bcb upstream.
The local variable is passed in request_irq (), and there will be use
after free problem, which will make request_irq failed. Using the global
irq name instead of it to fix.
Fixes: b11bc1ae4658 ("drm/hisilicon/hibmc: Add MSI irq getting and requesting for HPD")
Signed-off-by: Baihan Li <libaihan@huawei.com>
Signed-off-by: Yongbang Shi <shiyongbang@huawei.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20250813094238.3722345-4-shiyongbang@huawei.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: slim6882 <yangjunshuo@huawei.com>
commit 9f98b429ba67d430b873e06bcfb90afa22888978 upstream.
In some case, the dp link training success at 8.1Gbps, but the sink's
maximum supported rate is less than 8.1G. So change the default 8.1Gbps
link rate to the rate that reads from devices' capabilities.
Fixes: 54063d86e036 ("drm/hisilicon/hibmc: add dp link moduel in hibmc drivers")
Signed-off-by: Baihan Li <libaihan@huawei.com>
Signed-off-by: Yongbang Shi <shiyongbang@huawei.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20250813094238.3722345-6-shiyongbang@huawei.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: slim6882 <yangjunshuo@huawei.com>
commit 3271faf42d135bcf569c3ff6af55c21858eec212 upstream.
If VGA and DP connected together, there will be only one can get crtc.
Add encoder possible_clones to support two connectors enable.
Fixes: 3c7623fb5bb6 ("drm/hisilicon/hibmc: Enable this hot plug detect of irq feature")
Signed-off-by: Baihan Li <libaihan@huawei.com>
Signed-off-by: Yongbang Shi <shiyongbang@huawei.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20250813094238.3722345-8-shiyongbang@huawei.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: slim6882 <yangjunshuo@huawei.com>
commit aa47dcda2708e571695dae2e3f9537d9a8eb804c upstream. Update ID_AA64MMFR1_EL1 register fields definition per DDI0601 (ID092424) 2024-09. ID_AA64MMFR1_EL1.ETS adds definition for FEAT_ETS2 and FEAT_ETS3. ID_AA64MMFR1_EL1.HAFDBS adds definition for FEAT_HAFT and FEAT_HDBSS. Reviewed-by: Mark Brown <broonie@kernel.org> Signed-off-by: Yicong Yang <yangyicong@hisilicon.com> Link: https://lore.kernel.org/r/20241102104235.62560-2-yangyicong@huawei.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: JiangShui Yang <yangjiangshui@h-partners.com> Signed-off-by: Slim6882 <15605196882@163.com> Signed-off-by: chenyi <chenyi211@h-partners.com> Signed-off-by: slim6882 <yangjunshuo@huawei.com>
commit efe72541355d4d40a4f076af453f6533e98e058c upstream.
Armv8.9/v9.4 introduces the feature Hardware managed Access Flag
for Table descriptors (FEAT_HAFT). The feature is indicated by
ID_AA64MMFR1_EL1.HAFDBS == 0b0011 and can be enabled by
TCR2_EL1.HAFT so it has a dependency on FEAT_TCR2.
Adds the Kconfig for FEAT_HAFT and support detecting and enabling
the feature. The feature is enabled in __cpu_setup() before MMU on
just like HA. A CPU capability is added to notify the user of the
feature.
Add definition of P{G,4,U,M}D_TABLE_AF bit and set the AF bit
when creating the page table, which will save the hardware
from having to update them at runtime. This will be ignored if
FEAT_HAFT is not enabled.
The AF bit of table descriptors cannot be managed by the software
per spec, unlike the HA. So this should be used only if it's supported
system wide by system_supports_haft().
Signed-off-by: Yicong Yang <yangyicong@hisilicon.com>
Link: https://lore.kernel.org/r/20241102104235.62560-4-yangyicong@huawei.com
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
[catalin.marinas@arm.com: added the ID check back to __cpu_setup in case of future CPU errata]
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Conflicts:
arch/arm64/Kconfig
arch/arm64/include/asm/cpufeature.h
arch/arm64/kernel/cpufeature.c
arch/arm64/mm/mmu.c
arch/arm64/tools/cpucaps
[Context conflicts]
Signed-off-by: JiangShui Yang <yangjiangshui@h-partners.com>
Signed-off-by: Slim6882 <15605196882@163.com>
Signed-off-by: chenyi <chenyi211@h-partners.com>
Signed-off-by: slim6882 <yangjunshuo@huawei.com>
commit 62df5870ebf7cec96a51c9b9008daf167e22db14 upstream. With the support of FEAT_HAFT, the NONLEAF_PMD_YOUNG can be enabled on arm64 since the hardware is capable of updating the AF flag for PMD table descriptor. Since the AF bit of the table descriptor shares the same bit position in block descriptors, we only need to implement arch_has_hw_nonleaf_pmd_young() and select related configs. The related pmd_young test/update operations keeps the same with and already implemented for transparent page support. Currently ARCH_HAS_NONLEAF_PMD_YOUNG is used to improve the efficiency of lru-gen aging. Signed-off-by: Yicong Yang <yangyicong@hisilicon.com> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Link: https://lore.kernel.org/r/20241102104235.62560-5-yangyicong@huawei.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Conflicts: arch/arm64/Kconfig [Context conflicts] Signed-off-by: JiangShui Yang <yangjiangshui@h-partners.com> Signed-off-by: Slim6882 <15605196882@163.com> Signed-off-by: chenyi <chenyi211@h-partners.com> Signed-off-by: slim6882 <yangjunshuo@huawei.com>
commit b349a5a2b6e236b25095c6ff886b3451de5ea041 upstream. Young bit operation on PMD table entry is only supported if FEAT_HAFT enabled system wide. Add a warning for notifying the misbehaviour. Signed-off-by: Yicong Yang <yangyicong@hisilicon.com> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Link: https://lore.kernel.org/r/20241102104235.62560-6-yangyicong@huawei.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: JiangShui Yang <yangjiangshui@h-partners.com> Signed-off-by: Slim6882 <15605196882@163.com> Signed-off-by: chenyi <chenyi211@h-partners.com> Signed-off-by: slim6882 <yangjunshuo@huawei.com>
commit ddadbcdaaed5c3c44cc6c36093f6bf02d942d71d upstream. We have filled all 64 bits of AT_HWCAP2 so in order to support discovery of further features provide the framework to use the already defined AT_HWCAP3 for further CPU features. Signed-off-by: Mark Brown <broonie@kernel.org> Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com> Link: https://lore.kernel.org/r/20241004-arm64-elf-hwcap3-v2-2-799d1daad8b0@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> [conflicts with e218c611e32c8d4315a6d64790b9a86f3d4fa4dc] Signed-off-by: Hongye Lin <linhongye@h-partners.com> Signed-off-by: Qi Xi <xiqi2@huawei.com> Signed-off-by: slim6882 <yangjunshuo@huawei.com>
commit 3281366 upstream. Changes from v1: - Add Acked-by lines. The powerpc toolchain keeps a copy of the HWCAP bit masks in our TCB for fast access by the __builtin_cpu_supports built-in function. The TCB space for the HWCAP entries - which are created in pairs - is an ABI extension, so waiting to create the space for HWCAP3 and HWCAP4 until we need them is problematical. Define AT_HWCAP3 and AT_HWCAP4 in the generic uapi header so they can be used in glibc to reserve space in the powerpc TCB for their future use. I scanned through the Linux and GLIBC source codes looking for unused AT_* values and 29 and 30 did not seem to be used, so they are what I went with. This has received Acked-by's from both GLIBC and Linux kernel developers and no reservations or Nacks from anyone. Arnd, we seem to have consensus on the patch below. Is this something you could take and apply to your tree? Peter Signed-off-by: Peter Bergner <bergner@linux.ibm.com> Acked-by: Adhemerval Zanella <adhemerval.zanella@linaro.org> Acked-by: Nicholas Piggin <npiggin@gmail.com> Acked-by: Szabolcs Nagy <szabolcs.nagy@arm.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Commit: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/a406b535-dc55-4856-8ae9-5a063644a1af@linux.ibm.com Signed-off-by: Hongye Lin <linhongye@h-partners.com> Signed-off-by: Qi Xi <xiqi2@huawei.com> Signed-off-by: slim6882 <yangjunshuo@huawei.com>
…rrent_freq() commit 908981d85f86c5e2b39dfe0b2267c6d44d9c48f7 upstream. Move the check of cpufreq_driver->get into cpufreq_verify_current_freq() in case of calling it without check. Signed-off-by: Lifeng Zheng <zhenglifeng1@huawei.com> Link: https://patch.msgid.link/20250709104145.2348017-4-zhenglifeng1@huawei.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Hongye Lin <linhongye@h-partners.com> Signed-off-by: heppen <hepeng68@huawei.com> Signed-off-by: slim6882 <yangjunshuo@huawei.com>
commit 3906e7a3b26d683868704fe262db443207f392fe upstream.
The issue is that drm_connector_helper_detect_from_ddc() returns wrong
status when plugging or unplugging the monitor, which may cause the link
failed err.[0] Use HPD pin status in DP's detect_ctx() for real physical
monitor in/out, and implement a complete DP detection including read DPCD,
check if it's a branch device and its sink count for different situations.
[0]:
hibme-drm 0000:83:00.0: [drm] *ERROR* channel equalization failed 5 times
hibme-drm 0000:83:00.0: [drm] *ERROR* channel equalization failed 5 times
hibme-drm 0000:83:00.0: [drm] *ERROR* dp link training failed, ret: -16
hibmc-drm 0000:83:00.0: [drm] *ERROR* hibme dp mode set failed: -16
Fixes: 3c7623fb5bb6 ("drm/hisilicon/hibmc: Enable this hot plug detect of irq feature")
Signed-off-by: Baihan Li <libaihan@huawei.com>
Signed-off-by: Yongbang Shi <shiyongbang@huawei.com>
Reviewed-by: Tao Tian <tiantao6@hisilicon.com>
Link: https://patch.msgid.link/20251210023759.3944834-2-shiyongbang@huawei.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: slim6882 <yangjunshuo@huawei.com>
commit 607805abfb747b98f43aa57d6d9ba4caed4d106f upstream.
If DP is connected, check the DP BW in mode_valid_ctx() to ensure
that DP's link rate supports high-resolution data transmission.
Fixes: 0ab6ea261c1f ("drm/hisilicon/hibmc: add dp module in hibmc")
Signed-off-by: Baihan Li <libaihan@huawei.com>
Signed-off-by: Yongbang Shi <shiyongbang@huawei.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Tao Tian <tiantao6@hisilicon.com>
Link: https://patch.msgid.link/20251210023759.3944834-3-shiyongbang@huawei.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: slim6882 <yangjunshuo@huawei.com>
commit 0607052a6aee1e3d218a99fae70ba9f14b3b47ed upstream.
When using command rmmod and insmod, there is no showing in second time
insmoding. Because DP controller won't send HPD signals, if connection
doesn't change or controller isn't reset. So add reset before unreset
in hibmc_dp_hw_init().
And also need to move the HDCP cfg after DP controller de-resets, so
that HDCP configuration takes effect.
Fixes: 3c7623fb5bb6 ("drm/hisilicon/hibmc: Enable this hot plug detect of irq feature")
Signed-off-by: Baihan Li <libaihan@huawei.com>
Signed-off-by: Yongbang Shi <shiyongbang@huawei.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Tao Tian <tiantao6@hisilicon.com>
Link: https://patch.msgid.link/20251210023759.3944834-4-shiyongbang@huawei.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: slim6882 <yangjunshuo@huawei.com>
commit 6dad7fa8581e96321ec8a6a4f8160762466f539a upstream.
Add colorbar disable operation before reset chontroller, to make sure
colorbar status is clear in the DP init, so if rmmod the driver and the
previous colorbar configuration will not affect the next time insmod the
driver.
Fixes: 3c7623fb5bb6 ("drm/hisilicon/hibmc: Enable this hot plug detect of irq feature")
Signed-off-by: Baihan Li <libaihan@huawei.com>
Signed-off-by: Yongbang Shi <shiyongbang@huawei.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Tao Tian <tiantao6@hisilicon.com>
Link: https://patch.msgid.link/20251210023759.3944834-5-shiyongbang@huawei.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: slim6882 <yangjunshuo@huawei.com>
commit 1f7d1bab50e6ae517f8b6699e56d709d61ae13e5 upstream. It is possible to have a scenario where not all cpufreq policies support boost frequencies. And letting sysfs (or other parts of the kernel) enable boost feature for that policy isn't correct. Add a new flag, boost_supported, which will be set to true by the cpufreq core only if the freq table contains valid boost frequencies. Some cpufreq drivers though don't have boost frequencies in the freq-table, they can set this flag from their ->init() callbacks. Once all the drivers are updated to set the flag correctly, we can check it before enabling boost feature for a policy. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: wangyi <wangyi395@huawei.com> Signed-off-by: slim6882 <yangjunshuo@huawei.com>
commit 3d59224947b024c9b2aa6e149a1537d449adb828 upstream.
During CPU hotunplug events (such as those occurring during
suspend/resume cycles), platform firmware may modify the CPU boost
state.
If boost was disabled prior to CPU removal, it correctly remains
disabled upon re-plug. However, if firmware re-enables boost while the
CPU is offline, the CPU may return with boost enabled—even if it was
originally disabled—once it is hotplugged back in. This leads to
inconsistent behavior and violates user or kernel policy expectations.
To maintain consistency, ensure the boost state is re-synchronized with
the kernel policy when a CPU is hotplugged back in.
Note: This re-synchronization is not necessary during the initial call
to ->init() for a CPU, as the cpufreq core handles it via
cpufreq_online(). At that point, acpi_cpufreq_driver.boost_enabled is
initialized to the value returned by boost_state(0).
Fixes: 2b16c631832d ("cpufreq: ACPI: Remove set_boost in acpi_cpufreq_cpu_init()")
Reported-by: Nicholas Chin <nic.c3.14@gmail.com>
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220013
Tested-by: Nicholas Chin <nic.c3.14@gmail.com>
Reviewed-by: Lifeng Zheng <zhenglifeng1@huawei.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Link: https://patch.msgid.link/9c7de55fb06015c1b77e7dafd564b659838864e0.1745511526.git.viresh.kumar@linaro.org
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: wangyi <wangyi395@huawei.com>
Signed-off-by: slim6882 <yangjunshuo@huawei.com>
commit 68cb0139fec8e05b93978dc0ef1bc8df90a86419 upstream. for_each_possible_cpu() is currently used to initialize cpuidle in below cpuidle drivers: drivers/cpuidle/cpuidle-arm.c drivers/cpuidle/cpuidle-big_little.c drivers/cpuidle/cpuidle-psci.c drivers/cpuidle/cpuidle-qcom-spm.c drivers/cpuidle/cpuidle-riscv-sbi.c However, in cpu_dev_register_generic(), for_each_present_cpu() is used to register CPU devices which means the CPU devices are only registered for present CPUs and not all possible CPUs. With nosmp or maxcpus=0, only the boot CPU is present, lead to the failure: | Failed to register cpuidle device for cpu1 Then rollback to cancel all CPUs' cpuidle registration. Change for_each_possible_cpu() to for_each_present_cpu() in the above cpuidle drivers to ensure it only registers cpuidle devices for CPUs that are actually present. Fixes: b0c69e1 ("drivers: base: Use present CPUs in GENERIC_CPU_DEVICES") Reviewed-by: Dhruva Gole <d-gole@ti.com> Reviewed-by: Sudeep Holla <sudeep.holla@arm.com> Tested-by: Yuanjie Yang <quic_yuanjiey@quicinc.com> Signed-off-by: Jacky Bai <ping.bai@nxp.com> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Link: https://patch.msgid.link/20250307145547.2784821-1-ping.bai@nxp.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: wangyi <wangyi395@huawei.com> Signed-off-by: slim6882 <yangjunshuo@huawei.com>
commit 45f589b7167f36290d29c79e3a442dc0b13c086a upstream. for_each_possible_cpu() is currently used to initialize cpufreq. However, in cpu_dev_register_generic(), for_each_present_cpu() is used to register CPU devices which means the CPU devices are only registered for present CPUs and not all possible CPUs. With nosmp or maxcpus=0, only the boot CPU is present, lead to the cpufreq probe failure or defer probe due to no cpu device available for not present CPUs. Change for_each_possible_cpu() to for_each_present_cpu() in the above cpufreq drivers to ensure it only registers cpufreq for CPUs that are actually present. Fixes: b0c69e1 ("drivers: base: Use present CPUs in GENERIC_CPU_DEVICES") Reviewed-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jacky Bai <ping.bai@nxp.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: wangyi <wangyi395@huawei.com> Signed-off-by: slim6882 <yangjunshuo@huawei.com>
commit 004b500a9031973ba0d05edca860193f9a5938df upstream. It's useful to have capacity_freq_ref initialized to 0 for users of arch_scale_freq_ref() to detect when capacity_freq_ref was not yet set. The only scenario affected by this change in the init value is when a cpufreq driver is never loaded. As a result, the only setter of a cpu scale factor remains the call of topology_normalize_cpu_scale() from parse_dt_topology(). There we cannot use the value 0 of capacity_freq_ref so we have to compensate for its uninitialized state. Signed-off-by: Ionela Voinescu <ionela.voinescu@arm.com> Signed-off-by: Beata Michalska <beata.michalska@arm.com> Reviewed-by: Vincent Guittot <vincent.guittot@linaro.org> Reviewed-by: Sudeep Holla <sudeep.holla@arm.com> Link: https://lore.kernel.org/r/20240827154818.1195849-1-ionela.voinescu@arm.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Chuyi Zhou <zhouchuyi@bytedance.com> Signed-off-by: slim6882 <yangjunshuo@huawei.com>
commit 38e480d4fcac2e191e2f24f381aa8957865c49b2 upstream. Allow arch_freq_get_on_cpu to return an error for cases when retrieving current CPU frequency is not possible, whether that being due to lack of required arch support or due to other circumstances when the current frequency cannot be determined at given point of time. Signed-off-by: Beata Michalska <beata.michalska@arm.com> Reviewed-by: Prasanna Kumar T S M <ptsm@linux.microsoft.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Rafael J. Wysocki <rafael@kernel.org> Link: https://lore.kernel.org/r/20250131162439.3843071-2-beata.michalska@arm.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Chuyi Zhou <zhouchuyi@bytedance.com> Signed-off-by: slim6882 <yangjunshuo@huawei.com>
commit fbb4a4759b541d09ebb8e391d5fa7f9a5a0cad61 upstream. Currently the CPUFreq core exposes two sysfs attributes that can be used to query current frequency of a given CPU(s): namely cpuinfo_cur_freq and scaling_cur_freq. Both provide slightly different view on the subject and they do come with their own drawbacks. cpuinfo_cur_freq provides higher precision though at a cost of being rather expensive. Moreover, the information retrieved via this attribute is somewhat short lived as frequency can change at any point of time making it difficult to reason from. scaling_cur_freq, on the other hand, tends to be less accurate but then the actual level of precision (and source of information) varies between architectures making it a bit ambiguous. The new attribute, cpuinfo_avg_freq, is intended to provide more stable, distinct interface, exposing an average frequency of a given CPU(s), as reported by the hardware, over a time frame spanning no more than a few milliseconds. As it requires appropriate hardware support, this interface is optional. Note that under the hood, the new attribute relies on the information provided by arch_freq_get_on_cpu, which, up to this point, has been feeding data for scaling_cur_freq attribute, being the source of ambiguity when it comes to interpretation. This has been amended by restoring the intended behavior for scaling_cur_freq, with a new dedicated config option to maintain status quo for those, who may need it. CC: Jonathan Corbet <corbet@lwn.net> CC: Thomas Gleixner <tglx@linutronix.de> CC: Ingo Molnar <mingo@redhat.com> CC: Borislav Petkov <bp@alien8.de> CC: Dave Hansen <dave.hansen@linux.intel.com> CC: H. Peter Anvin <hpa@zytor.com> CC: Phil Auld <pauld@redhat.com> CC: x86@kernel.org CC: linux-doc@vger.kernel.org Signed-off-by: Beata Michalska <beata.michalska@arm.com> Reviewed-by: Prasanna Kumar T S M <ptsm@linux.microsoft.com> Reviewed-by: Sumit Gupta <sumitg@nvidia.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Rafael J. Wysocki <rafael@kernel.org> Link: https://lore.kernel.org/r/20250131162439.3843071-3-beata.michalska@arm.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Chuyi Zhou <zhouchuyi@bytedance.com> Signed-off-by: slim6882 <yangjunshuo@huawei.com>
commit 16d1e27475f673295f3eaac296dd835db3b8c4d4 upstream. With the Frequency Invariance Engine (FIE) being already wired up with sched tick and making use of relevant (core counter and constant counter) AMU counters, getting the average frequency for a given CPU, can be achieved by utilizing the frequency scale factor which reflects an average CPU frequency for the last tick period length. The solution is partially based on APERF/MPERF implementation of arch_freq_get_on_cpu. Suggested-by: Ionela Voinescu <ionela.voinescu@arm.com> Signed-off-by: Beata Michalska <beata.michalska@arm.com> Reviewed-by: Prasanna Kumar T S M <ptsm@linux.microsoft.com> Reviewed-by: Sumit Gupta <sumitg@nvidia.com> Link: https://lore.kernel.org/r/20250131162439.3843071-4-beata.michalska@arm.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Chuyi Zhou <zhouchuyi@bytedance.com> Signed-off-by: slim6882 <yangjunshuo@huawei.com>
commit 39b19974982e03bd7b950f33bc0855385845c9fb upstream. Now that the frequency scale factor has been activated for retrieving current frequency on a given CPU, trigger its update upon entering idle. This will, to an extent, allow querying last known frequency in a non-invasive way. It will also improve the frequency scale factor accuracy when a CPU entering idle did not receive a tick for a while. As a consequence, for idle cores, the reported frequency will be the last one observed before entering the idle state. Suggested-by: Vanshidhar Konda <vanshikonda@os.amperecomputing.com> Signed-off-by: Beata Michalska <beata.michalska@arm.com> Reviewed-by: Prasanna Kumar T S M <ptsm@linux.microsoft.com> Reviewed-by: Sumit Gupta <sumitg@nvidia.com> Link: https://lore.kernel.org/r/20250131162439.3843071-5-beata.michalska@arm.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Chuyi Zhou <zhouchuyi@bytedance.com> Signed-off-by: slim6882 <yangjunshuo@huawei.com>
commit 20711efa91e8ba44149f5e2ed1cf81e5355650e5 upstream.
While searching for a reference CPU within a given policy,
arch_freq_get_on_cpu relies on cpumask_next_wrap to iterate over
all available CPUs and to ensure each is verified only once.
Recent changes to cpumask_next_wrap will handle the latter no more,
so switching to for_each_cpu_wrap, which preserves expected behavior
while ensuring compatibility with the updates.
Not to mention that when iterating over each CPU, using a dedicated
iterator is preferable to an open-coded loop.
Fixes: 16d1e27475f6 ("arm64: Provide an AMU-based version of arch_freq_get_on_cpu")
Signed-off-by: Beata Michalska <beata.michalska@arm.com>
Link: https://lore.kernel.org/r/20250220091015.2319901-1-beata.michalska@arm.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Chuyi Zhou <zhouchuyi@bytedance.com>
Signed-off-by: slim6882 <yangjunshuo@huawei.com>
commit 46f69b1 upstream. On trace end we disable the hardware but leave the interrupt unmasked. Mask the interrupt to make the process reverse to the start. No actual issue since hardware should send no interrupt after disabled. Signed-off-by: Yicong Yang <yangyicong@hisilicon.com> Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com> Link: https://lore.kernel.org/r/20231010084731.30450-2-yangyicong@huawei.com Signed-off-by: shiyongbang <shiyongbang@huawei.com> Signed-off-by: Slim6882 <15605196882@163.com> Signed-off-by: chenyi <chenyi211@h-partners.com> Signed-off-by: slim6882 <yangjunshuo@huawei.com>
commit dabf410 upstream. In the current implementation, there're 4*4MiB trace buffer and hardware will fill the buffer one by one. The driver will get notified if one buffer is full and then copy data to the AUX buffer. If there's no enough room for the next trace buffer, we'll commit the AUX buffer to the perf core and try to apply a new one. In a typical configuration the AUX buffer will be 16MiB, so we'll commit the data after the whole AUX buffer is occupied. Then the driver cannot apply a new AUX buffer immediately until the committed data is consumed by userspace and then there's room in the AUX buffer again. This patch tries to optimize this by commit the data after one single trace buffer is filled. Since there's still room in the AUX buffer, driver can apply a new one without failure and don't need to wait for the userspace to consume the data. Signed-off-by: Yicong Yang <yangyicong@hisilicon.com> Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com> Link: https://lore.kernel.org/r/20231010084731.30450-4-yangyicong@huawei.com Signed-off-by: shiyongbang <shiyongbang@huawei.com> Signed-off-by: Slim6882 <15605196882@163.com> Signed-off-by: chenyi <chenyi211@h-partners.com> Signed-off-by: slim6882 <yangjunshuo@huawei.com>
commit 2ae8fbb upstream. MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit According to PCIe r6.0 sec 6.7.6 [1], async removal with DPC may result in surprise down error. This error is expected and is just a side-effect of async remove. Ignore surprise down error generated as a side-effect of async remove. Typically, this error is benign as the pciehp handler invoked by PDC or/and DLLSC alongside DPC, de-enumerates and brings down the device appropriately, but the error messages might confuse users. Get rid of these irritating log messages with a 1s delay while pciehp waits for DPC recovery. The implementation is as follows: On an async remove a DPC is triggered along with a Presence Detect State change and/or DLL State Change. Determine it's an async remove by checking for DPC Trigger Status in DPC Status Register and Surprise Down Error Status in AER Uncorrected Error Status to be non-zero. If true, treat the DPC event as a side-effect of async remove, clear the error status registers and continue with hot-plug tear down routines. If not, follow the existing routine to handle AER and DPC errors. Masking Surprise Down Errors was explored as an alternative approach, but discarded due to the odd behavior that masking only avoids the interrupt, but still records an error per PCIe r6.0, sec 6.2.3.2.2. That stale error would be reported the next time some error other than Surprise Down is handled. Dmesg before: pcieport 0000:00:01.4: DPC: containment event, status:0x1f01 source:0x0000 pcieport 0000:00:01.4: DPC: unmasked uncorrectable error detected pcieport 0000:00:01.4: PCIe Bus Error: severity=Uncorrected (Fatal), type=Transaction Layer, (Receiver ID) pcieport 0000:00:01.4: device [1022:14ab] error status/mask=00000020/04004000 pcieport 0000:00:01.4: [ 5] SDES (First) nvme nvme2: frozen state error detected, reset controller pcieport 0000:00:01.4: DPC: Data Link Layer Link Active not set in 1000 msec pcieport 0000:00:01.4: AER: subordinate device reset failed pcieport 0000:00:01.4: AER: device recovery failed pcieport 0000:00:01.4: pciehp: Slot(16): Link Down nvme2n1: detected capacity change from 1953525168 to 0 pci 0000:04:00.0: Removing from iommu group 49 Dmesg after: pcieport 0000:00:01.4: pciehp: Slot(16): Link Down nvme1n1: detected capacity change from 1953525168 to 0 pci 0000:04:00.0: Removing from iommu group 37 [1] PCI Express Base Specification Revision 6.0, Dec 16 2021. https://members.pcisig.com/wg/PCI-SIG/document/16609 Fixes: aea4741 ("PCI/DPC: Expose dpc_process_error(), dpc_reset_link() for use by EDR") Link: https://lore.kernel.org/r/20240207181854.121335-1-Smita.KoralahalliChannabasappa@amd.com Signed-off-by: Smita Koralahalli <Smita.KoralahalliChannabasappa@amd.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: lujunhua <lujunhua7@h-partners.com> Reviewed-by: Lukas Wunner <lukas@wunner.de> Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: xia-bing1 <2328702590@qq.com> Signed-off-by: Slim6882 <15605196882@163.com> Signed-off-by: chenyi <chenyi211@h-partners.com> Signed-off-by: slim6882 <yangjunshuo@huawei.com>
commit 54a9e47 upstream. hisi_pcie_pmu_{config,clear}_filter() are config/clear HISI_PCIE_EVENT_CTRL register which contains not only the filter but also the event code. The function names are bit misleading. Rename it to hisi_pcie_pmu_{config,clear}_event_ctrl() to reflects their functions more accurately. Signed-off-by: Yicong Yang <yangyicong@hisilicon.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Link: https://lore.kernel.org/r/20240223103359.18669-2-yangyicong@huawei.com Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Bing Xia <xiabing12@h-partners.com> Signed-off-by: Slim6882 <15605196882@163.com> Signed-off-by: chenyi <chenyi211@h-partners.com> Signed-off-by: slim6882 <yangjunshuo@huawei.com>
commit 4d47346 upstream. Factor out retrieving of the register value for the corresponding event from hisi_pcie_config_event_ctrl() into a new function hisi_pcie_pmu_get_event_ctrl_val() allowing future reuse. Signed-off-by: Yicong Yang <yangyicong@hisilicon.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Link: https://lore.kernel.org/r/20240223103359.18669-3-yangyicong@huawei.com Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Bing Xia <xiabing12@h-partners.com> Signed-off-by: Slim6882 <15605196882@163.com> Signed-off-by: chenyi <chenyi211@h-partners.com> Signed-off-by: slim6882 <yangjunshuo@huawei.com>
commit b6693ad upstream. The metric counting shows incorrect results if the events in the metric group using the same event but different filter options. This is because we only judge the event code to decide whether the event in the metric group should share the same hardware counter, but ignore the settings of the filter. For example, on a platform of 2 ports 0x1 and 0x2 but only port 0x1 has a downstream PCIe NVME device. The metric counting shows both ports have the same counts because we misassign these two events to one same hardware counter: [root@localhost perf-iostat]# ./perf stat -e '{hisi_pcie0_core1/event=0x0104,port=0x2/,hisi_pcie0_core1/event=0x0104,port=0x1/}' Performance counter stats for 'system wide': 7907484924 hisi_pcie0_core1/event=0x0104,port=0x2/ 7907484924 hisi_pcie0_core1/event=0x0104,port=0x1/ 10.153863691 seconds time elapsed Fix this by using the whole config rather than the event only to judge whether two events are the same and should share the same hardware counter. With this patch, the metric counting in the above case tends to be corrected: [root@localhost perf-iostat]# ./perf stat -e '{hisi_pcie0_core1/event=0x0104,port=0x2/,hisi_pcie0_core1/event=0x0104,port=0x1/}' Performance counter stats for 'system wide': 0 hisi_pcie0_core1/event=0x0104,port=0x2/ 8123122077 hisi_pcie0_core1/event=0x0104,port=0x1/ 10.152875631 seconds time elapsed Fixes: 8404b0f ("drivers/perf: hisi: Add driver for HiSilicon PCIe PMU") Signed-off-by: Yicong Yang <yangyicong@hisilicon.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Link: https://lore.kernel.org/r/20240223103359.18669-4-yangyicong@huawei.com Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Bing Xia <xiabing12@h-partners.com> Signed-off-by: Slim6882 <15605196882@163.com> Signed-off-by: chenyi <chenyi211@h-partners.com> Signed-off-by: slim6882 <yangjunshuo@huawei.com>
commit 00ca69b upstream. A typical PCIe transaction is consisted of various TLP packets in both direction. For counting bandwidth only memory read events are exported currently. Add memory write and completion counting events of both direction to complete the bandwidth counting. Signed-off-by: Yicong Yang <yangyicong@hisilicon.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Link: https://lore.kernel.org/r/20240223103359.18669-5-yangyicong@huawei.com Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Bing Xia <xiabing12@h-partners.com> Signed-off-by: Slim6882 <15605196882@163.com> Signed-off-by: chenyi <chenyi211@h-partners.com> Signed-off-by: slim6882 <yangjunshuo@huawei.com>
commit 2f864fe upstream. The PMU can monitor traffic of certain target Root Port or downstream target Endpoint. User can specify the target filter by the "port" or "bdf" option respectively. The PMU can only monitor the Root Port or Endpoint on the same PCIe core so the value of "port" or "bdf" should be valid and will be checked by the driver. Currently at least and only one of "port" and "bdf" option must be set. If "port" filter is not set or is set explicitly to zero (default), driver will regard the user specifies a "bdf" option since "port" option is a bitmask of the target Root Ports and zero is not a valid value. If user not explicitly set "port" or "bdf" filter, the driver uses "bdf" default value (zero) to set target filter, but driver will skip the check of bdf=0, although it's a valid value (meaning 0000:000:00.0). Then the user just gets zero. Therefore, we need to check if both "port" and "bdf" are invalid, then return failure and report warning. Testing: before the patch: 0 hisi_pcie0_core1/rx_mrd_flux/ 0 hisi_pcie0_core1/rx_mrd_flux,port=0/ 24,124 hisi_pcie0_core1/rx_mrd_flux,port=1/ 0 hisi_pcie0_core1/rx_mrd_flux,bdf=0/ 0 hisi_pcie0_core1/rx_mrd_flux,port=0x800/ <not supported> hisi_pcie0_core1/rx_mrd_flux,bdf=1/ 24,132 hisi_pcie0_core1/rx_mrd_flux,bdf=0x1700/ <not supported> hisi_pcie0_core1/rx_mrd_flux,port=0x0,bdf=0x0/ <not supported> hisi_pcie0_core1/rx_mrd_flux,port=0x0,bdf=0x1/ 24,138 hisi_pcie0_core1/rx_mrd_flux,port=0x0,bdf=0x1700/ 24,126 hisi_pcie0_core1/rx_mrd_flux,port=0x1,bdf=0x0/ after the patch: <not supported> hisi_pcie0_core1/rx_mrd_flux/ <not supported> hisi_pcie0_core1/rx_mrd_flux,port=0/ 24,153 hisi_pcie0_core1/rx_mrd_flux,port=1/ 0 hisi_pcie0_core1/rx_mrd_flux,port=0x800/ <not supported> hisi_pcie0_core1/rx_mrd_flux,bdf=0/ <not supported> hisi_pcie0_core1/rx_mrd_flux,bdf=1/ 24,117 hisi_pcie0_core1/rx_mrd_flux,bdf=0x1700/ <not supported> hisi_pcie0_core1/rx_mrd_flux,port=0x0,bdf=0x0/ <not supported> hisi_pcie0_core1/rx_mrd_flux,port=0x0,bdf=0x1/ 24,120 hisi_pcie0_core1/rx_mrd_flux,port=0x0,bdf=0x1700/ 24,123 hisi_pcie0_core1/rx_mrd_flux,port=0x1,bdf=0x0/ Signed-off-by: Junhao He <hejunhao3@huawei.com> Signed-off-by: Yicong Yang <yangyicong@hisilicon.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Link: https://lore.kernel.org/r/20240223103359.18669-6-yangyicong@huawei.com Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Bing Xia <xiabing12@h-partners.com> Signed-off-by: Slim6882 <15605196882@163.com> Signed-off-by: chenyi <chenyi211@h-partners.com> Signed-off-by: slim6882 <yangjunshuo@huawei.com>
commit 2fbf96e upstream. If we use two events with the same filter and related event type (see the following example), the driver check whether they are related events and are in the same group, otherwise the function hisi_pcie_pmu_find_related_event() return -EINVAL, then the 2nd event cannot count but the 1st event is running, although the PCIe PMU has other idle counters. In this case, The perf event scheduler will make the two events to multiplex a counter, if the user use the formula (1st event_value / 2nd event_value) to calculate the bandwidth, he/she won't get the correct value, because they are not counting at the same period. This patch tries to fix this by making the related events to use different idle counters if they are not in the same event group. And finally, I'm going to say. The related events are best used in the same group [1]. There are two ways to know if they are related events. a) By event name, such as the latency events "xxx_latency, xxx_cnt" or bandwidth events "xxx_flux, xxx_time". b) By event type, such as "event=0xXXXX, event=0x1XXXX". Use group to count the related events: [1] -e "{pmu_name/xxx_latency,port=1/,pmu_name/xxx_cnt,port=1/}" example: 1st event: hisi_pcie0_core1/event=0x804,port=1 2nd event: hisi_pcie0_core1/event=0x10804,port=1 test cmd: perf stat -e hisi_pcie0_core1/event=0x804,port=1/ \ -e hisi_pcie0_core1/event=0x10804,port=1/ before patch: 25,281 hisi_pcie0_core1/event=0x804,port=1/ (49.91%) 470,598 hisi_pcie0_core1/event=0x10804,port=1/ (50.09%) after patch: 24,147 hisi_pcie0_core1/event=0x804,port=1/ 474,558 hisi_pcie0_core1/event=0x10804,port=1/ Signed-off-by: Junhao He <hejunhao3@huawei.com> Signed-off-by: Yicong Yang <yangyicong@hisilicon.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huwei.com> Link: https://lore.kernel.org/r/20240223103359.18669-7-yangyicong@huawei.com Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Bing Xia <xiabing12@h-partners.com> Signed-off-by: Slim6882 <15605196882@163.com> Signed-off-by: chenyi <chenyi211@h-partners.com> Signed-off-by: slim6882 <yangjunshuo@huawei.com>
commit 7da3770 upstream. The function xxx_find_related_event() scan all working events to find related events. During this process, we also can find the idle counters. If not found related events, return the first idle counter to simplify the code. Signed-off-by: Junhao He <hejunhao3@huawei.com> Signed-off-by: Yicong Yang <yangyicong@hisilicon.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Link: https://lore.kernel.org/r/20240223103359.18669-8-yangyicong@huawei.com Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Bing Xia <xiabing12@h-partners.com> Signed-off-by: Slim6882 <15605196882@163.com> Signed-off-by: chenyi <chenyi211@h-partners.com> Signed-off-by: slim6882 <yangjunshuo@huawei.com>
commit d1c93d5 upstream. Currently users can get the Root Ports supported by the PCIe PMU by "bus" sysfs attributes which indicates the PCIe bus number where Root Ports are located. This maybe insufficient since Root Ports supported by different PCIe PMUs may be located on the same PCIe bus. So export the BDF range the Root Ports additionally. Signed-off-by: Yicong Yang <yangyicong@hisilicon.com> Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Link: https://lore.kernel.org/r/20240829090332.28756-4-yangyicong@huawei.com Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: zhangyuyang <zhangyuyang31@huawei.com> Signed-off-by: Slim6882 <15605196882@163.com> Signed-off-by: chenyi <chenyi211@h-partners.com> Signed-off-by: slim6882 <yangjunshuo@huawei.com>
commit 89a0329 upstream. One of the "port" and "bdf" target filter interface must be set, and the related events should preferably used in the same group. Update the usage in the documentation. Signed-off-by: Junhao He <hejunhao3@huawei.com> Signed-off-by: Yicong Yang <yangyicong@hisilicon.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Link: https://lore.kernel.org/r/20240223103359.18669-9-yangyicong@huawei.com Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Bing Xia <xiabing12@h-partners.com> Signed-off-by: Slim6882 <15605196882@163.com> Signed-off-by: chenyi <chenyi211@h-partners.com> Signed-off-by: slim6882 <yangjunshuo@huawei.com>
commit b037e40 upstream. `make htmldocs SPHINXDIRS="admin-guide"` shows below warnings: Documentation/admin-guide/perf/hisi-pcie-pmu.rst:48: ERROR: Unexpected indentation. Documentation/admin-guide/perf/hisi-pcie-pmu.rst:49: WARNING: Block quote ends without a blank line; unexpected unindent. Fix this. Fixes: 89a0329 ("docs: perf: Update usage for target filter of hisi-pcie-pmu") Signed-off-by: Yicong Yang <yangyicong@hisilicon.com> Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Bing Xia <xiabing12@h-partners.com> Signed-off-by: Slim6882 <15605196882@163.com> Signed-off-by: chenyi <chenyi211@h-partners.com> Signed-off-by: slim6882 <yangjunshuo@huawei.com>
commit be7a4ca upstream. In the previous code, there was a memory leak issue where the previously allocated memory was not freed upon a failed lseek operation. This patch addresses the problem by releasing the old memory before returning -errno in case of a lseek failure. This ensures that memory is properly managed and avoids potential memory leaks. Signed-off-by: Kuan-Wei Chiu <visitorckw@gmail.com> Acked-by: Namhyung Kim <namhyung@kernel.org> Cc: yangyicong@hisilicon.com Cc: jonathan.cameron@huawei.com Link: https://lore.kernel.org/r/20230930072719.1267784-1-visitorckw@gmail.com Signed-off-by: Namhyung Kim <namhyung@kernel.org> Signed-off-by: Slim6882 <15605196882@163.com> Signed-off-by: chenyi <chenyi211@h-partners.com> Signed-off-by: slim6882 <yangjunshuo@huawei.com>
jackYoung0915
force-pushed
the
bsk-opensource-6.6-yjs-KP950-new
branch
from
6f14b4a to
5501d3b
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
15 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
hibmc-drm:
drm: Call drm_atomic_helper_shutdown() at shutdown time for misc drivers
drm/ast: Implement polling for VGA and SIL164 connectors
drm/hisilicon/hibmc: convert to struct drm_edid
drm/hisilicon/hibmc: Use video aperture helpers
drm/hisilicon/hibmc: add dp aux in hibmc drivers
drm/hisilicon/hibmc: add dp link moduel in hibmc drivers
drm/hisilicon/hibmc: add dp hw moduel in hibmc driver
drm/hisilicon/hibmc: refactored struct hibmc_drm_private
drm/hisilicon/hibmc: add dp module in hibmc
drm/hisilicon/hibmc: select CONFIG_DRM_DISPLAY_DP_HELPER
drm/hisilicon/hibmc: Restructuring the header dp_reg.h
drm/hisilicon/hibmc: Add dp serdes cfg to adjust serdes rate, voltage and pre-emphasis
drm/hisilicon/hibmc: Add dp serdes cfg in dp process
drm/hisilicon/hibmc: Refactor the member of drm_aux in struct hibmc_dp
drm/hisilicon/hibmc: Getting connector info and EDID by using AUX channel
drm/hisilicon/hibmc: Add colorbar-cfg feature and its debugfs file
drm/hisilicon/hibmc: Enable this hot plug detect of irq feature
drm/hisilicon/hibmc: Add MSI irq getting and requesting for HPD
drm/hisilicon/hibmc: Add vga connector detect functions
drm/hisilicon/hibmc: fix the i2c device resource leak when vdac init failed
drm/hisilicon/hibmc: fix irq_request()'s irq name variable is local
drm/hisilicon/hibmc: fix the hibmc loaded failed bug
drm/hisilicon/hibmc: fix rare monitors cannot display problem
drm/hisilicon/hibmc: fix dp and vga cannot show together
drm/hisilicon/hibmc: fix dp probabilistical detect errors after HPD irq
drm/hisilicon/hibmc: add dp mode valid check
drm/hisilicon/hibmc: fix no showing problem with loading hibmc manually
drm/hisilicon/hibmc: Adding reset colorbar cfg in dp init.
cpufeature:
arm64/sysreg: Update ID_AA64MMFR1_EL1 register
arm64: Add support for FEAT_HAFT
arm64: Enable ARCH_HAS_NONLEAF_PMD_YOUNG
arm64: pgtable: Warn unexpected pmdp_test_and_clear_young()
arm64: Support AT_HWCAP3
uapi/auxvec: Define AT_HWCAP3 and AT_HWCAP4 aux vector, entries
binfmt_elf: Wire up AT_HWCAP3 at AT_HWCAP4
arm64: Provide basic EL2 setup for FEAT_{LS64, LS64_V} usage at EL0/1
arm64: Add support for FEAT_{LS64, LS64_V}
KVM: arm64: Enable FEAT_{LS64, LS64_V} in the supported guest
irqchip/gicv3-its: Add workaround for hip09 ITS erratum 162100801
sched/fair: Use candidate prev/recent_used CPU if scanning failed for cluster wakeup
sched/topology: Add a new arch_scale_freq_ref() method
cpu/SMT: Provide a default topology_is_primary_thread()
arch_topology: Support SMT control for OF based system
arm64: Kconfig: Enable HOTPLUG_SMT
arm64: topology: Support SMT control on ACPI based system
arm64: setup: name 'tcr2' register
cpufreq:
cpufreq: Use the fixed and coherent frequency for scaling capacity
cpufreq/schedutil: Use a fixed reference frequency
energy_model: Use a fixed reference frequency
cpufreq/cppc: Set the frequency used for computing the capacity
arm64/amu: Use capacity_ref_freq() to set AMU ratio
topology: Set capacity_freq_ref in all cases
cpufreq: Fix re-boost issue after hotplugging a CPU
cpufreq: Introduce a more generic way to set default per-policy boost flag
cpufreq: CPPC: Fix wrong max_freq in policy initialization
cpufreq: ACPI: Remove set_boost in acpi_cpufreq_cpu_init()
cpufreq: prevent NULL dereference in cpufreq_online()
cpufreq: CPPC: Remove cpu_data_list
cpufreq: CPPC: Do not return a value from populate_efficiency_class()
cpufreq: CPPC: Remove forward declaration of cppc_cpufreq_register_em()
cpufreq: Contain scaling_cur_freq.attr in cpufreq_attrs
cpufreq: Remove duplicate check in __cpufreq_offline()
cpufreq: Initialize cpufreq-based frequency-invariance later
cpufreq: Init policy->rwsem before it may be possibly used
cpufreq: Move the check of cpufreq_driver->get into cpufreq_verify_current_freq()
cpufreq: Exit governor when failed to start old governor
PCIe:
hwtracing: hisi_ptt: Disable interrupt after trace end
hwtracing: hisi_ptt: Optimize the trace data committing
PCI/DPC: Ignore Surprise Down error on hot removal
drivers/perf: hisi_pcie: Rename hisi_pcie_pmu_{config,clear}_filter()
drivers/perf: hisi_pcie: Introduce hisi_pcie_pmu_get_event_ctrl_val()
drivers/perf: hisi_pcie: Fix incorrect counting under metric mode
drivers/perf: hisi_pcie: Add more events for counting TLP bandwidth
drivers/perf: hisi_pcie: Check the target filter properly
drivers/perf: hisi_pcie: Relax the check on related events
drivers/perf: hisi_pcie: Merge find_related_event() and get_event_idx()
drivers/perf: hisi_pcie: Export supported Root Ports [bdf_min, bdf_max]
docs: perf: Update usage for target filter of hisi-pcie-pmu
docs: perf: Fix build warning of hisi-pcie-pmu.rst
perf hisi-ptt: Fix memory leak in lseek failure handling