summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2022-04-21drm/vc4: hdmi: Replace drm_detect_hdmi_monitor() with is_hdmiJosé Expósito
Once EDID is parsed, the monitor HDMI support information is cached in drm_display_info.is_hdmi by drm_parse_hdmi_vsdb_video(). This driver calls drm_detect_hdmi_monitor() to receive the same information and stores its own cached value in vc4_hdmi_encoder.hdmi_monitor, which is less efficient. Avoid calling drm_detect_hdmi_monitor() and use drm_display_info.is_hdmi instead. This also allows to remove vc4_hdmi_encoder.hdmi_monitor. drm_detect_hdmi_monitor() is called in vc4_hdmi_connector_detect() and vc4_hdmi_connector_get_modes(). In both cases it is safe to rely on drm_display_info.is_hdmi as shown by ftrace: $ sudo trace-cmd record -p function_graph -l "vc4_hdmi_*" -l "drm_*" vc4_hdmi_connector_detect: vc4_hdmi_connector_detect() { drm_get_edid() { drm_connector_update_edid_property() { drm_add_display_info() { drm_reset_display_info(); drm_for_each_detailed_block.part.0(); drm_parse_cea_ext() { drm_find_cea_extension(); drm_parse_hdmi_vsdb_video(); /* drm_display_info.is_hdmi is cached here */ } } } } /* drm_display_info.is_hdmi is used here */ } vc4_hdmi_connector_get_modes: vc4_hdmi_connector_get_modes() { drm_get_edid() { drm_connector_update_edid_property() { drm_add_display_info() { drm_reset_display_info(); drm_for_each_detailed_block.part.0(); drm_parse_cea_ext() { drm_find_cea_extension(); drm_parse_hdmi_vsdb_video(); /* drm_display_info.is_hdmi is cached here */ } } } } /* drm_display_info.is_hdmi is used here */ drm_connector_update_edid_property(); } Signed-off-by: José Expósito <jose.exposito89@gmail.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20220420114500.187664-2-jose.exposito89@gmail.com
2022-04-21pinctrl: samsung: fix missing GPIOLIB on ARM64 Exynos configKrzysztof Kozlowski
The Samsung pinctrl drivers depend on OF_GPIO, which is part of GPIOLIB. ARMv7 Exynos platform selects GPIOLIB and Samsung pinctrl drivers. ARMv8 Exynos selects only the latter leading to possible wrong configuration on ARMv8 build: WARNING: unmet direct dependencies detected for PINCTRL_EXYNOS Depends on [n]: PINCTRL [=y] && OF_GPIO [=n] && (ARCH_EXYNOS [=y] || ARCH_S5PV210 || COMPILE_TEST [=y]) Selected by [y]: - ARCH_EXYNOS [=y] Always select the GPIOLIB from the Samsung pinctrl drivers to fix the issue. This requires removing of OF_GPIO dependency (to avoid recursive dependency), so add dependency on OF for COMPILE_TEST cases. Reported-by: Necip Fazil Yildiran <fazilyildiran@gmail.com> Fixes: eed6b3eb20b9 ("arm64: Split out platform options to separate Kconfig") Cc: <stable@vger.kernel.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20220420141407.470955-1-krzysztof.kozlowski@linaro.org
2022-04-20drm/vmwgfx: Fix gem refcounting and memory evictionsZack Rusin
v2: Add the last part of the ref count fix which was spotted by Philipp Sieweck where the ref count of cpu writers is off due to ERESTARTSYS or EBUSY during bo waits. The initial GEM port broke refcounting on shareable (prime) surfaces and memory evictions. The prime surfaces broke because the parent surfaces weren't increasing the ref count on GEM surfaces, which meant that the memory backing textures could have been deleted while the texture was still accessible. The evictions broke due to a typo, the code was supposed to exit if the passed buffers were not vmw_buffer_object not if they were. They're tied because the evictions depend on having memory to actually evict. This fixes crashes with XA state tracker which is used for xrender acceleration on xf86-video-vmware, apps/tests which use a lot of memory (a good test being the piglit's streaming-texture-leak) and desktops. Signed-off-by: Zack Rusin <zackr@vmware.com> Fixes: 8afa13a0583f ("drm/vmwgfx: Implement DRIVER_GEM") Reported-by: Philipp Sieweck <psi@informatik.uni-kiel.de> Cc: <stable@vger.kernel.org> # v5.17+ Reviewed-by: Maaz Mombasawala <mombasawalam@vmware.com> Reviewed-by: Martin Krastev <krastevm@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220420040328.1007409-1-zack@kde.org
2022-04-20drm/radeon: Use TTM builtin resource manager debugfs codeZack Rusin
Switch to using the TTM resource manager debugfs helpers. The functionality is largely the same. The TTM resource managers need to stay valid for as long as the drm debugfs_root is valid. Signed-off-by: Zack Rusin <zackr@vmware.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: "Pan, Xinhui" <Xinhui.Pan@amd.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: amd-gfx@lists.freedesktop.org Link: https://patchwork.freedesktop.org/patch/msgid/20220412033526.369115-6-zack@kde.org Reviewed-by: Christian König <christian.koenig@amd.com>
2022-04-20drm/qxl: Use TTM builtin resource manager debugfs codeZack Rusin
Switch to using the TTM resource manager debugfs helpers. The functionality is largely the same. The TTM resource managers need to stay valid for as long as the drm debugfs_root is valid. Signed-off-by: Zack Rusin <zackr@vmware.com> Cc: Dave Airlie <airlied@redhat.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: virtualization@lists.linux-foundation.org Cc: spice-devel@lists.freedesktop.org Link: https://patchwork.freedesktop.org/patch/msgid/20220412033526.369115-5-zack@kde.org Reviewed-by: Christian König <christian.koenig@amd.com>
2022-04-20drm/amdgpu: Use TTM builtin resource manager debugfs codeZack Rusin
Switch to using the TTM resource manager debugfs helpers. It's exactly the same functionality but the debugfs code is shared with other drivers. The TTM resource managers need to stay valid for as long as the drm debugfs_root is valid. Signed-off-by: Zack Rusin <zackr@vmware.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: "Pan, Xinhui" <Xinhui.Pan@amd.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Felix Kuehling <Felix.Kuehling@amd.com> Cc: Nirmoy Das <nirmoy.das@amd.com> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: amd-gfx@lists.freedesktop.org Link: https://patchwork.freedesktop.org/patch/msgid/20220412033526.369115-4-zack@kde.org Reviewed-by: Christian König <christian.koenig@amd.com>
2022-04-20drm/vmwgfx: Add debugfs entries for various ttm resource managersZack Rusin
Use the newly added TTM's ability to automatically create debugfs entries for specified placements. This creates debugfs files that can be read to get information about various TTM resource managers which are used by vmwgfx. Signed-off-by: Zack Rusin <zackr@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220412033526.369115-3-zack@kde.org Reviewed-by: Christian König <christian.koenig@amd.com>
2022-04-20drm/ttm: Add common debugfs code for resource managersZack Rusin
Drivers duplicate the code required to add debugfs entries for various ttm resource managers. To fix it add common TTM resource manager debugfs code that each driver can reuse. Specific resource managers can overwrite ttm_resource_manager_func::debug to get more information from those debugfs entries. Signed-off-by: Zack Rusin <zackr@vmware.com> Cc: Huang Rui <ray.huang@amd.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20220412033526.369115-2-zack@kde.org Reviewed-by: Christian König <christian.koenig@amd.com>
2022-04-21pinctrl: mediatek: moore: Fix build errorYueHaibing
If EINT_MTK is m and PINCTRL_MTK_V2 is y, build fails: drivers/pinctrl/mediatek/pinctrl-moore.o: In function `mtk_gpio_set_config': pinctrl-moore.c:(.text+0xa6c): undefined reference to `mtk_eint_set_debounce' drivers/pinctrl/mediatek/pinctrl-moore.o: In function `mtk_gpio_to_irq': pinctrl-moore.c:(.text+0xacc): undefined reference to `mtk_eint_find_irq' Select EINT_MTK for PINCTRL_MTK_V2 to fix this. Fixes: 8174a8512e3e ("pinctrl: mediatek: make MediaTek pinctrl v2 driver ready for buidling loadable module") Signed-off-by: YueHaibing <yuehaibing@huawei.com> Link: https://lore.kernel.org/r/20220409105958.37412-1-yuehaibing@huawei.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2022-04-20xen: Convert kmap() to kmap_local_page()Alaa Mohamed
kmap() is being deprecated and these usages are all local to the thread so there is no reason kmap_local_page() can't be used. Replace kmap() calls with kmap_local_page(). Signed-off-by: Alaa Mohamed <eng.alaamohamedsoliman.am@gmail.com> Reviewed-by: Juergen Gross <jgross@suse.com> Link: https://lore.kernel.org/r/20220419234328.10346-1-eng.alaamohamedsoliman.am@gmail.com Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
2022-04-20drm/i915: Fixup merge of the power well refactor patchsetImre Deak
The wrong v2 version of drm/i915: Move per-platform power well hooks to intel_display_power_well.c patch was pushed to drm-intel-next branch instead of v3, fix this up applying the difference between v2 and v3. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220415082524.1826924-1-imre.deak@intel.com
2022-04-20drm/i915: Remove the XELPD specific AUX and DDI power domainsImre Deak
The spec calls the XELPD_D/E ports just D/E, the platform prefix in the domain names was only needed by the port->domain mapping relying on matching enum values for the whole port/domain range (and the corresponding aliasing between the platform specific domain enums). Since a previous patch we can define the port->domain mapping explicitly so do this by reusing the already existing D/E power domain names. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220414210657.1785773-18-imre.deak@intel.com
2022-04-20drm/i915: Remove duplicate DDI/AUX power domain mappingsImre Deak
The DDI and AUX domain -> power well mappings are identical for a few platforms/power well instances, reuse the mappings of earlier platforms for these removing the duplicate mapping of new platforms. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220414210657.1785773-17-imre.deak@intel.com
2022-04-20drm/i915: Remove the ICL specific TBT power domainsImre Deak
The spec calls the ICL TBT AUX power well instances TBT1-4 (similarly to all later platforms), align the power domain names with the spec. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220414210657.1785773-16-imre.deak@intel.com
2022-04-20drm/i915: Remove the aliasing of power domain enum valuesImre Deak
Aliasing the intel_display_power_domain enum values was required because of the u64 power domain mask size limit. This makes the dmesg/debugfs printouts of the domain names somewhat unclear, for instance domain names for port D are shown on D12+ platforms where the corresponding port is called TC1. Make this clearer by removing the aliasing which is possible after a previous patch converting the mask to a bitmap. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220414210657.1785773-15-imre.deak@intel.com
2022-04-20drm/i915: Sanitize the port -> DDI/AUX power domain mapping for each platformImre Deak
Atm the port -> DDI and AUX power domain mapping is specified by relying on the aliasing of the platform specific intel_display_power_domain enum values. For instance D12+ platforms refer to the 'D' port and power domain instances, which doesn't match the bspec terminology, on these platforms the corresponding port is TC1. To make it clear what port/domain the code refers to add a mapping between them which matches the bspec terms on different display versions. This also allows for removing the aliasing in enum values in a follow-up patch. v2: Add the functions to intel_display_power.c, use intel_display_power_ prefix. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220414210657.1785773-14-imre.deak@intel.com
2022-04-20drm/i915: Sanitize the ADL-S power well definitionImre Deak
Instead of the skip_mask special casing of the ADL-S power well descriptors, add a power well descriptor list for ADL-S as well reusing the TGL descriptors, w/o the TC-cold power well. ADL-S doesn't have TypeC PHYs, so a better way would be having ADL-S specific AUX descriptors, but I left changing this for a follow-up. This changes the ordering of the AUX and TC-cold vs. PW_4/5 power wells on TGL and ADL-S, but this shouldn't make a difference (PW_4/5 don't depend on the AUX/TC-cold power wells). Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220414210657.1785773-13-imre.deak@intel.com
2022-04-20drm/i915: Simplify the DG1 power well descriptorsImre Deak
Simplify the definition of DG1 power wells by reusing the identical RKL DDI/AUX descriptors. This reorders the DG1 DDI/AUX vs. PW4/5 power wells, but this shouldn't make a difference (it is the order on RKL and the DDI/AUX power wells don't have a dependency on PW4/5). Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220414210657.1785773-12-imre.deak@intel.com
2022-04-20drm/i915: Allow platforms to share power well descriptorsImre Deak
Some power wells - like always-on and skl+/icl+ PW_1 - with the same name, domain list, flags, ops are used by multiple platforms, so allow platforms to reuse the descriptors of such power wells. This change also lets the follow up patches to simplify the DG1/RKL power well definitions, and remove the ADL-S skip_mask special casing. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220414210657.1785773-11-imre.deak@intel.com
2022-04-20drm/i915: Simplify power well definitions by adding power well instancesImre Deak
All the port specific AUX/DDI_IO power wells share the same power well ops struct and flags, so we can save some space and simplify the definition of these by listing for all such power wells only the params specific to them (name, domains, power well register index, id). Move these params to a new i915_power_well_instance struct and convert the per-platform power well definitions accordingly. For all power well instance the name and power domain list params must be specified, while the register index and id are optional, add the I915_PW() macro that both simplifies the definitions and ensures that the required params are set. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220414210657.1785773-10-imre.deak@intel.com
2022-04-20drm/i915: Convert the u64 power well domains mask to a bitmapImre Deak
To remove the aliasing of the power domain enum values in a follow-up patch in this patchset (requiring a bigger mask) and allow for defining additional power domains in the future (at least some upcoming TypeC changes requires this) convert the u64 i915_power_well_desc::domains mask to a bitmap. For simplicity I changed the for_each_power_domain_well() macros to accept one domain only instead of a mask, as there isn't any current user passing multiple domains. v2: Don't add a typedef for the bitmap struct. (Jani) Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220414210657.1785773-9-imre.deak@intel.com
2022-04-20drm/i915: Convert the power well descriptor domain mask to an array of domainsImre Deak
The next patch converts the i915_power_well_desc::domain mask from a u64 mask to a bitmap. I didn't find a reasonably simple way to initialize bitmaps statically, so prepare for the next patch here by converting the masks to an array of domain enums and initing the masks from these arrays during module loading. v2: Clarify list vs. array in the commit message. (Jani) Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220414210657.1785773-8-imre.deak@intel.com
2022-04-20drm/i915: Sanitize the power well namesImre Deak
Use the shortest descriptive name for all power wells for simplicity and to use the same name for the same type of power wells on multiple platforms. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220414210657.1785773-7-imre.deak@intel.com
2022-04-20drm/i915: Rename the power domain names to end with pipes/portsImre Deak
Make all power domain names end with the pipe/port instance for consistency. No functional changes. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220414210657.1785773-6-imre.deak@intel.com
2022-04-20drm/i915: Move the HSW power well flags to a common bitfieldImre Deak
Save some space by grouping the HSW power well descriptor flags along with other flags in one bitfield. This change also lets simplifying the definition of power well descriptors sharing the same flags in an upcoming patch. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220414210657.1785773-5-imre.deak@intel.com
2022-04-20drm/i915: Move the dg2 fixed_enable_delay power well param to a common bitfieldImre Deak
The DG2 fixed delay duration is always 600usec, so save some space in the power well descriptors by converting the parameter to a flag. While at it also use a bitfield for both the always_on and fixed_enable_delay flag. This change also lets simplifying the definiton of power wells sharing the same flags in an upcoming patch. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220414210657.1785773-4-imre.deak@intel.com
2022-04-20drm/i915: Move the power domain->well mappings to intel_display_power_map.cImre Deak
Move the list of platform specific power domain -> power well definitions to intel_display_power_map.c. While at it group the platforms' power domain macros with the corresponding power well lists and keep all the power domain lists in the same order (matching the enum order). No functional changes. v2: - s/intel_display_power_internal.h/intel_display_power_map.h/ (Jani) - Simplify intel_cleanup_power_wells(). - Don't move intel_display_power_domain_str(). v3: - Rename intel_init/cleanup_power_wells() to intel_display_power_map_init/cleanup(). - Add documentation to intel_display_power_map_init/cleanup(). Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220414210657.1785773-3-imre.deak@intel.com
2022-04-20drm/i915: Unexport the for_each_power_well() macrosImre Deak
The for_each_power_well() macros are only used in intel_display_power.c and intel_display_power_well.c, so unexport them. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220414210657.1785773-2-imre.deak@intel.com
2022-04-20drm/i915: Move per-platform power well hooks to intel_display_power_well.cImre Deak
Move the implementation of platform specific power well hooks to intel_display_power_well.c, to reduce the clutter in intel_display_power.c. The locking of all the power domain/power well state is handled in the power domain functions in intel_display_power.c using i915_power_domains::lock. This patch also moves the chy_phy_powergate_ch/lanes() functions to intel_display_power_well.c which borrow the same lock to protect the DISPLAY_PHY_CONTROL register state, which the HW uses both for toggling power wells and power gating PHY lanes. No functional change. v2: - Clarify in the commit log why CHV functions using the i915_power_domains::lock were moved, while others locking the power domain/well state were kept in intel_display_power.c . (Jouni) - Move forward declaration of chv_phy_powergate_ch/lanes() to intel_display_power_well.h . Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220414210657.1785773-1-imre.deak@intel.com
2022-04-20arch_topology: Do not set llc_sibling if llc_id is invalidWang Qing
When ACPI is not enabled, cpuid_topo->llc_id = cpu_topo->llc_id = -1, which will set llc_sibling 0xff(...), this is misleading. Don't set llc_sibling(default 0) if we don't know the cache topology. Reviewed-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Wang Qing <wangqing@vivo.com> Fixes: 37c3ec2d810f ("arm64: topology: divorce MC scheduling domain from core_siblings") Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/1649644580-54626-1-git-send-email-wangqing@vivo.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-04-20topology: make core_mask include at least cluster_siblingsDarren Hart
Ampere Altra defines CPU clusters in the ACPI PPTT. They share a Snoop Control Unit, but have no shared CPU-side last level cache. cpu_coregroup_mask() will return a cpumask with weight 1, while cpu_clustergroup_mask() will return a cpumask with weight 2. As a result, build_sched_domain() will BUG() once per CPU with: BUG: arch topology borken the CLS domain not a subset of the MC domain The MC level cpumask is then extended to that of the CLS child, and is later removed entirely as redundant. This sched domain topology is an improvement over previous topologies, or those built without SCHED_CLUSTER, particularly for certain latency sensitive workloads. With the current scheduler model and heuristics, this is a desirable default topology for Ampere Altra and Altra Max system. Rather than create a custom sched domains topology structure and introduce new logic in arch/arm64 to detect these systems, update the core_mask so coregroup is never a subset of clustergroup, extending it to cluster_siblings if necessary. Only do this if CONFIG_SCHED_CLUSTER is enabled to avoid also changing the topology (MC) when CONFIG_SCHED_CLUSTER is disabled. This has the added benefit over a custom topology of working for both symmetric and asymmetric topologies. It does not address systems where the CLUSTER topology is above a populated MC topology, but these are not considered today and can be addressed separately if and when they appear. The final sched domain topology for a 2 socket Ampere Altra system is unchanged with or without CONFIG_SCHED_CLUSTER, and the BUG is avoided: For CPU0: CONFIG_SCHED_CLUSTER=y CLS [0-1] DIE [0-79] NUMA [0-159] CONFIG_SCHED_CLUSTER is not set DIE [0-79] NUMA [0-159] Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: "Rafael J. Wysocki" <rafael@kernel.org> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Vincent Guittot <vincent.guittot@linaro.org> Cc: D. Scott Phillips <scott@os.amperecomputing.com> Cc: Ilkka Koskinen <ilkka@os.amperecomputing.com> Cc: <stable@vger.kernel.org> # 5.16.x Suggested-by: Barry Song <song.bao.hua@hisilicon.com> Reviewed-by: Barry Song <song.bao.hua@hisilicon.com> Reviewed-by: Dietmar Eggemann <dietmar.eggemann@arm.com> Acked-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Darren Hart <darren@os.amperecomputing.com> Link: https://lore.kernel.org/r/c8fe9fce7c86ed56b4c455b8c902982dc2303868.1649696956.git.darren@os.amperecomputing.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-04-20topology/sysfs: Hide PPIN on systems that do not support it.Tony Luck
Systems that do not support a Protected Processor Identification Number currently report: # cat /sys/devices/system/cpu/cpu0/topology/ppin 0x0 which is confusing/wrong. Add a ".is_visible" function to suppress inclusion of the ppin file. Fixes: ab28e944197f ("topology/sysfs: Add PPIN in sysfs under cpu topology") Signed-off-by: Tony Luck <tony.luck@intel.com> Link: https://lore.kernel.org/r/20220406220150.63855-1-tony.luck@intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-04-20drm/i915/dg2: Add workaround 18019627453José Roberto de Souza
A new DG2 workaround added to fix some corner cases hangs. v2: - implementing the second and preferred option for this workaround BSpec: 54077 BSpec: 68173 BSpec: 71488 Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220419182753.364237-2-jose.souza@intel.com
2022-04-20drm/solomon: Add SSD130x OLED displays SPI supportJavier Martinez Canillas
The ssd130x driver only provides the core support for these devices but it does not have any bus transport logic. Add a driver to interface over SPI. There is a difference in the communication protocol when using 4-wire SPI instead of I2C. For the latter, a control byte that contains a D/C# field has to be sent. This field tells the controller whether the data has to be written to the command register or to the graphics display data memory. But for 4-wire SPI that control byte is not used, instead a real D/C# line must be pulled HIGH for commands data and LOW for graphics display data. For this reason the standard SPI regmap can't be used and a custom .write bus handler is needed. Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Mark Brown <broonie@kernel.org> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patchwork.freedesktop.org/patch/msgid/20220419214824.335075-6-javierm@redhat.com
2022-04-20drm/solomon: Move device info from ssd130x-i2c to the core driverJavier Martinez Canillas
These are declared in the ssd130x-i2c transport driver but the information is not I2C specific, and could be used by other SSD130x transport drivers. Move them to the ssd130x core driver and just set the OF device entries to an ID that could be used to lookup the correct device info from an array. While being there, also move the SSD130X_DATA and SSD130X_COMMAND control bytes. Since even though they are used by the I2C interface, they could also be useful for other transport protocols such as SPI. Suggested-by: Chen-Yu Tsai <wens@kernel.org> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Mark Brown <broonie@kernel.org> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patchwork.freedesktop.org/patch/msgid/20220419214824.335075-5-javierm@redhat.com
2022-04-20drm/solomon: Add ssd130x new compatible strings and deprecate old ones.Javier Martinez Canillas
The current compatible strings for SSD130x I2C controllers contain an "fb" and "-i2c" suffixes. These have been deprecated and more correct ones were added, that don't encode a subsystem or bus used to interface the devices. Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Mark Brown <broonie@kernel.org> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patchwork.freedesktop.org/patch/msgid/20220419214824.335075-4-javierm@redhat.com
2022-04-20drm/i915/display: Add workaround 22014263786José Roberto de Souza
This workaround fixes screen flickers with FBC. BSpec: 33450 BSpec: 52890 BSpec: 54369 BSpec: 66624 Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220419182753.364237-1-jose.souza@intel.com
2022-04-20tty: n_gsm: fix missing update of modem controls after DLCI openDaniel Starke
Currently the peer is not informed about the initial state of the modem control lines after a new DLCI has been opened. Fix this by sending the initial modem control line states after DLCI open. Fixes: e1eaea46bb40 ("tty: n_gsm line discipline") Cc: stable@vger.kernel.org Signed-off-by: Daniel Starke <daniel.starke@siemens.com> Link: https://lore.kernel.org/r/20220420101346.3315-1-daniel.starke@siemens.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-04-20drm/i915: Program i830 DPLL FP register laterVille Syrjälä
Follow the new i9xx DPLL FP register programming sequence introduced in commit 62d66b218386 ("drm/i915: Fold i9xx_set_pll_dividers() into i9xx_enable_pll()") in the i830 "power well" code as well. Just for consistency. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220321195006.775-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-04-20drm/i915: program wm blocks to at least blocks required per lineVinod Govindapillai
In configurations with single DRAM channel, for usecases like 4K 60 Hz, FIFO underruns are observed quite frequently. Looks like the wm0 watermark values need to bumped up because the wm0 memory latency calculations are probably not taking the DRAM channel's impact into account. As per the Bspec 49325, if the ddb allocation can hold at least one plane_blocks_per_line we should have selected method2. Assuming that modern HW versions have enough dbuf to hold at least one line, set the wm blocks to equivalent to blocks per line. v2: styling and comments changes (Ville) v3: Updated the reviewed-by tag v4: max_t to max and patch styling (Ville) References: https://gitlab.freedesktop.org/drm/intel/-/issues/4321 Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220417093105.729014-1-vinod.govindapillai@intel.com
2022-04-20drm/i915: Fix DISP_POS_Y and DISP_HEIGHT definesHans de Goede
Commit 428cb15d5b00 ("drm/i915: Clean up pre-skl primary plane registers") introduced DISP_POS_Y and DISP_HEIGHT defines but accidentally set these their masks to REG_GENMASK(31, 0) instead of REG_GENMASK(31, 16). This breaks the primary display pane on at least pineview machines, fix the mask to fix the primary display pane only showing black. Tested on an Acer One AO532h with an Intel N450 SoC. Fixes: 428cb15d5b00 ("drm/i915: Clean up pre-skl primary plane registers") Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220418150936.5499-1-hdegoede@redhat.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
2022-04-20dmaengine: idxd: skip clearing device context when device is read-onlyDave Jiang
If the device shows up as read-only configuration, skip the clearing of the state as the context must be preserved for device re-enable after being disabled. Fixes: 0dcfe41e9a4c ("dmanegine: idxd: cleanup all device related bits after disabling device") Reported-by: Tony Zhu <tony.zhu@intel.com> Tested-by: Tony Zhu <tony.zhu@intel.com> Signed-off-by: Dave Jiang <dave.jiang@intel.com> Link: https://lore.kernel.org/r/164971479479.2200566.13980022473526292759.stgit@djiang5-desk3.ch.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2022-04-20dmaengine: idxd: add RO check for wq max_transfer_size writeDave Jiang
Block wq_max_transfer_size_store() when the device is configured as read-only and not configurable. Fixes: d7aad5550eca ("dmaengine: idxd: add support for configurable max wq xfer size") Reported-by: Bernice Zhang <bernice.zhang@intel.com> Tested-by: Bernice Zhang <bernice.zhang@intel.com> Signed-off-by: Dave Jiang <dave.jiang@intel.com> Link: https://lore.kernel.org/r/164971488154.2200913.10706665404118545941.stgit@djiang5-desk3.ch.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2022-04-20dmaengine: idxd: add RO check for wq max_batch_size writeDave Jiang
Block wq_max_batch_size_store() when the device is configured as read-only and not configurable. Fixes: e7184b159dd3 ("dmaengine: idxd: add support for configurable max wq batch size") Reported-by: Bernice Zhang <bernice.zhang@intel.com> Tested-by: Bernice Zhang <bernice.zhang@intel.com> Signed-off-by: Dave Jiang <dave.jiang@intel.com> Link: https://lore.kernel.org/r/164971493551.2201159.1942042593642155209.stgit@djiang5-desk3.ch.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2022-04-20dmaengine: idxd: fix retry value to be constant for duration of function callDave Jiang
When retries is compared to wq->enqcmds_retries each loop of idxd_enqcmds(), wq->enqcmds_retries can potentially changed by user. Assign the value of retries to wq->enqcmds_retries during initialization so it is the original value set when entering the function. Fixes: 7930d8553575 ("dmaengine: idxd: add knob for enqcmds retries") Suggested-by: Dave Hansen <dave.hansen@intel.com> Signed-off-by: Dave Jiang <dave.jiang@intel.com> Link: https://lore.kernel.org/r/165031760154.3658664.1983547716619266558.stgit@djiang5-desk3.ch.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2022-04-20dmaengine: idxd: match type for retries var in idxd_enqcmds()Dave Jiang
wq->enqcmds_retries is defined as unsigned int. However, retries on the stack is defined as int. Change retries to unsigned int to compare the same type. Fixes: 7930d8553575 ("dmaengine: idxd: add knob for enqcmds retries") Suggested-by: Thiago Macieira <thiago.macieira@intel.com> Signed-off-by: Dave Jiang <dave.jiang@intel.com> Link: https://lore.kernel.org/r/165031747059.3658198.6035308204505664375.stgit@djiang5-desk3.ch.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2022-04-20dmaengine: dw-edma: Fix inconsistent indentingJiapeng Chong
Eliminate the follow smatch warning: drivers/dma/dw-edma/dw-edma-v0-core.c:419 dw_edma_v0_core_start() warn: inconsistent indenting. Reported-by: Abaci Robot <abaci@linux.alibaba.com> Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Link: https://lore.kernel.org/r/20220413023442.18856-1-jiapeng.chong@linux.alibaba.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2022-04-20net: stmmac: Use readl_poll_timeout_atomic() in atomic stateKevin Hao
The init_systime() may be invoked in atomic state. We have observed the following call trace when running "phc_ctl /dev/ptp0 set" on a Intel Agilex board. BUG: sleeping function called from invalid context at drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c:74 in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 381, name: phc_ctl preempt_count: 1, expected: 0 RCU nest depth: 0, expected: 0 Preemption disabled at: [<ffff80000892ef78>] stmmac_set_time+0x34/0x8c CPU: 2 PID: 381 Comm: phc_ctl Not tainted 5.18.0-rc2-next-20220414-yocto-standard+ #567 Hardware name: SoCFPGA Agilex SoCDK (DT) Call trace: dump_backtrace.part.0+0xc4/0xd0 show_stack+0x24/0x40 dump_stack_lvl+0x7c/0xa0 dump_stack+0x18/0x34 __might_resched+0x154/0x1c0 __might_sleep+0x58/0x90 init_systime+0x78/0x120 stmmac_set_time+0x64/0x8c ptp_clock_settime+0x60/0x9c pc_clock_settime+0x6c/0xc0 __arm64_sys_clock_settime+0x88/0xf0 invoke_syscall+0x5c/0x130 el0_svc_common.constprop.0+0x4c/0x100 do_el0_svc+0x7c/0xa0 el0_svc+0x58/0xcc el0t_64_sync_handler+0xa4/0x130 el0t_64_sync+0x18c/0x190 So we should use readl_poll_timeout_atomic() here instead of readl_poll_timeout(). Also adjust the delay time to 10us to fix a "__bad_udelay" build error reported by "kernel test robot <lkp@intel.com>". I have tested this on Intel Agilex and NXP S32G boards, there is no delay needed at all. So the 10us delay should be long enough for most cases. Fixes: ff8ed737860e ("net: stmmac: use readl_poll_timeout() function in init_systime()") Signed-off-by: Kevin Hao <haokexin@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-04-20phy: amlogic: fix error path in phy_g12a_usb3_pcie_probe()Heiner Kallweit
If clk_prepare_enable() fails we call clk_disable_unprepare() in the error path what results in a warning that the clock is disabled and unprepared already. And if we fail later in phy_g12a_usb3_pcie_probe() then we bail out w/o calling clk_disable_unprepare(). This patch fixes both errors. Fixes: 36077e16c050 ("phy: amlogic: Add Amlogic G12A USB3 + PCIE Combo PHY Driver") Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Link: https://lore.kernel.org/r/8e416f95-1084-ee28-860e-7884f7fa2e32@gmail.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2022-04-20drm/vc4: Fix build error when CONFIG_DRM_VC4=y && CONFIG_RASPBERRYPI_FIRMWARE=mZheng Bin
If CONFIG_DRM_VC4=y, CONFIG_RASPBERRYPI_FIRMWARE=m, CONFIG_COMPILE_TEST=n, bulding fails: drivers/gpu/drm/vc4/vc4_drv.o: In function `vc4_drm_bind': vc4_drv.c:(.text+0x320): undefined reference to `rpi_firmware_get' vc4_drv.c:(.text+0x320): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `rpi_firmware_get' vc4_drv.c:(.text+0x34c): undefined reference to `rpi_firmware_property' vc4_drv.c:(.text+0x34c): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `rpi_firmware_property' vc4_drv.c:(.text+0x354): undefined reference to `rpi_firmware_put' vc4_drv.c:(.text+0x354): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `rpi_firmware_put' Make DRM_VC4 depends on RASPBERRYPI_FIRMWARE || (COMPILE_TEST && !RASPBERRYPI_FIRMWARE) to fix this. Fixes: c406ad5e4a85 ("drm/vc4: Notify the firmware when DRM is in charge") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Zheng Bin <zhengbin13@huawei.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20220411024325.3968413-1-zhengbin13@huawei.com