From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 26EB6C433FE for ; Sat, 30 Apr 2022 20:05:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244872AbiD3UIb (ORCPT ); Sat, 30 Apr 2022 16:08:31 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42102 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244935AbiD3UI3 (ORCPT ); Sat, 30 Apr 2022 16:08:29 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0773E11A25; Sat, 30 Apr 2022 13:05:04 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 9CCCFB80025; Sat, 30 Apr 2022 20:05:03 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 508D4C385A7; Sat, 30 Apr 2022 20:05:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1651349102; bh=qQ90+vzIfAbuP6uHng6MH3iDdoxyuq9y8LCR9IxIB7o=; h=From:To:Cc:Subject:Date:From; b=oriawJX7mtL42TvPN4GPv6rgWqPRYbv0P0DCAGQPD8ae1FLEM8nDTAzpN14/H7KW8 QGO8HYOlQCAyusmUQxTlX7AU4uE+KX1ejlriQOa0rzN4yzw7PNTQ+m43xh4ZhWINEK umFfsCvsAW9unoPkPirwbA0MrYCae9t8oHywbEBCVl57MTUkR3/qP+8Wzit3EbdMrB Utv4IKODv4i5UoK0rqOFvbtSzUdB4Lg6CHD7ts0KS2IwfajQwn7/6dxCewnKzvHpUO WCOPJqQY+OyWsG+AziiZVxLzCyGmJT4WZJhQFlOMXKxrUPpOdoLISRJsbZDukeTSbV AsdI7I4+hFoBw== Received: from mchehab by mail.kernel.org with local (Exim 4.94.2) (envelope-from ) id 1nktKr-001uvr-Ma; Sat, 30 Apr 2022 21:04:57 +0100 From: Mauro Carvalho Chehab To: Luis Chamberlain Cc: Mauro Carvalho Chehab , mauro.chehab@linux.intel.com, Greg KH , intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, Lucas De Marchi , Kai Vehmanen , Pierre-Louis Bossart , Jaroslav Kysela , Takashi Iwai , alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org, linux-modules@vger.kernel.org, Daniel Vetter , David Airlie Subject: [PATCH v5 0/2] Let userspace know when snd-hda-intel needs i915 Date: Sat, 30 Apr 2022 21:04:53 +0100 Message-Id: X-Mailer: git-send-email 2.35.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: Currently, kernel/module annotates module dependencies when request_symbol is used, but it doesn't cover more complex inter-driver dependencies that are subsystem and/or driver-specific. In the case of hdmi sound, depending on the CPU/GPU, sometimes the snd_hda_driver can talk directly with the hardware, but sometimes, it uses the i915 driver. When the snd_hda_driver uses i915, it should first be unbind/rmmod, as otherwise trying to unbind/rmmod the i915 driver cause driver issues, as as reported by CI tools with different GPU models: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_6415/fi-tgl-1115g4/igt@core_hotunplug@unbind-rebind.html https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11495/bat-adlm-1/igt@i915_module_load@reload.html In the past, just a few CPUs were doing such bindings, but this issue now applies to all "modern" Intel CPUs that have onboard graphics, as well as to the newer discrete GPUs. With the discrete GPU case, the HDA controller is physically separate and requires i915 to power on the hardware for all hardware access. In this case, the issue is hit basicly 100% of the time. With on-board graphics, i915 driver is needed only when the display codec is accessed. If i915 is unbind during runtime suspend, while snd-hda-intel is still bound, nothing bad happens, but unbinding i915 on other situations may also cause issues. So, add support at kernel/modules to allow snd-hda drivers to properly annotate when a dependency on a DRM driver dependencies exists, and add a call to such new function at the snd-hda driver when it successfully binds into the DRM driver. This would allow userspace tools to check and properly remove the audio driver before trying to remove or unbind the GPU driver. It should be noticed that this series conveys the hidden module dependencies. Other changes are needed in order to allow removing or unbinding the i915 driver while keeping the snd-hda-intel driver loaded/bound. With that regards, there are some discussions on how to improve this at alsa-devel a while back: https://mailman.alsa-project.org/pipermail/alsa-devel/2021-September/190099.html So, future improvements on both in i915 and the audio drivers could be made. E.g. with discrete GPUs, it's the only codec of the card, so it seems feasible to detach the ALSA card if i915 is bound (using infra made for VGA switcheroo), but, until these improvements are done and land in upstream, audio drivers needs to be unbound if i915 driver goes unbind. Yet, even if such fixes got merged, this series is still needed, as it makes such dependencies more explicit and easier to debug. PS.: This series was generated against next-20220428. --- v5: - while v4 works fine, it ends calling try_module_format() recursively, which is not what it it was supposed to do. So, change the logic to avoid such recursion, by adding a static __try_module_format() and renaming the new version that takes two arguments as try_module_format_owner(). v4: - fix a compilation warning reported by Intel's Kernel robot when !CONFIG_MODULE_UNLOAD or !CONFIG_MODULE. v3: minor fixes: - fixed a checkpatch warning; - use a single line for the new function prototype. v2: - the dependencies are now handled directly at try_module_get(). Mauro Carvalho Chehab (2): module: update dependencies at try_module_get() ALSA: hda - identify when audio is provided by a video driver include/linux/module.h | 8 +++-- kernel/module/main.c | 65 ++++++++++++++++++++++++++++++-------- sound/hda/hdac_component.c | 2 +- 3 files changed, 57 insertions(+), 18 deletions(-) -- 2.35.1 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id C0333C433FE for ; Sat, 30 Apr 2022 20:05:13 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 08AFA10EAD3; Sat, 30 Apr 2022 20:05:05 +0000 (UTC) Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by gabe.freedesktop.org (Postfix) with ESMTPS id B6A8410EAC9; Sat, 30 Apr 2022 20:05:03 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 09C7C60FAD; Sat, 30 Apr 2022 20:05:03 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 508D4C385A7; Sat, 30 Apr 2022 20:05:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1651349102; bh=qQ90+vzIfAbuP6uHng6MH3iDdoxyuq9y8LCR9IxIB7o=; h=From:To:Cc:Subject:Date:From; b=oriawJX7mtL42TvPN4GPv6rgWqPRYbv0P0DCAGQPD8ae1FLEM8nDTAzpN14/H7KW8 QGO8HYOlQCAyusmUQxTlX7AU4uE+KX1ejlriQOa0rzN4yzw7PNTQ+m43xh4ZhWINEK umFfsCvsAW9unoPkPirwbA0MrYCae9t8oHywbEBCVl57MTUkR3/qP+8Wzit3EbdMrB Utv4IKODv4i5UoK0rqOFvbtSzUdB4Lg6CHD7ts0KS2IwfajQwn7/6dxCewnKzvHpUO WCOPJqQY+OyWsG+AziiZVxLzCyGmJT4WZJhQFlOMXKxrUPpOdoLISRJsbZDukeTSbV AsdI7I4+hFoBw== Received: from mchehab by mail.kernel.org with local (Exim 4.94.2) (envelope-from ) id 1nktKr-001uvr-Ma; Sat, 30 Apr 2022 21:04:57 +0100 From: Mauro Carvalho Chehab To: Luis Chamberlain Subject: [PATCH v5 0/2] Let userspace know when snd-hda-intel needs i915 Date: Sat, 30 Apr 2022 21:04:53 +0100 Message-Id: X-Mailer: git-send-email 2.35.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: mauro.chehab@linux.intel.com, alsa-devel@alsa-project.org, Kai Vehmanen , Greg KH , intel-gfx@lists.freedesktop.org, Lucas De Marchi , Takashi Iwai , dri-devel@lists.freedesktop.org, Jaroslav Kysela , David Airlie , linux-modules@vger.kernel.org, Mauro Carvalho Chehab , linux-kernel@vger.kernel.org, Pierre-Louis Bossart Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" Currently, kernel/module annotates module dependencies when request_symbol is used, but it doesn't cover more complex inter-driver dependencies that are subsystem and/or driver-specific. In the case of hdmi sound, depending on the CPU/GPU, sometimes the snd_hda_driver can talk directly with the hardware, but sometimes, it uses the i915 driver. When the snd_hda_driver uses i915, it should first be unbind/rmmod, as otherwise trying to unbind/rmmod the i915 driver cause driver issues, as as reported by CI tools with different GPU models: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_6415/fi-tgl-1115g4/igt@core_hotunplug@unbind-rebind.html https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11495/bat-adlm-1/igt@i915_module_load@reload.html In the past, just a few CPUs were doing such bindings, but this issue now applies to all "modern" Intel CPUs that have onboard graphics, as well as to the newer discrete GPUs. With the discrete GPU case, the HDA controller is physically separate and requires i915 to power on the hardware for all hardware access. In this case, the issue is hit basicly 100% of the time. With on-board graphics, i915 driver is needed only when the display codec is accessed. If i915 is unbind during runtime suspend, while snd-hda-intel is still bound, nothing bad happens, but unbinding i915 on other situations may also cause issues. So, add support at kernel/modules to allow snd-hda drivers to properly annotate when a dependency on a DRM driver dependencies exists, and add a call to such new function at the snd-hda driver when it successfully binds into the DRM driver. This would allow userspace tools to check and properly remove the audio driver before trying to remove or unbind the GPU driver. It should be noticed that this series conveys the hidden module dependencies. Other changes are needed in order to allow removing or unbinding the i915 driver while keeping the snd-hda-intel driver loaded/bound. With that regards, there are some discussions on how to improve this at alsa-devel a while back: https://mailman.alsa-project.org/pipermail/alsa-devel/2021-September/190099.html So, future improvements on both in i915 and the audio drivers could be made. E.g. with discrete GPUs, it's the only codec of the card, so it seems feasible to detach the ALSA card if i915 is bound (using infra made for VGA switcheroo), but, until these improvements are done and land in upstream, audio drivers needs to be unbound if i915 driver goes unbind. Yet, even if such fixes got merged, this series is still needed, as it makes such dependencies more explicit and easier to debug. PS.: This series was generated against next-20220428. --- v5: - while v4 works fine, it ends calling try_module_format() recursively, which is not what it it was supposed to do. So, change the logic to avoid such recursion, by adding a static __try_module_format() and renaming the new version that takes two arguments as try_module_format_owner(). v4: - fix a compilation warning reported by Intel's Kernel robot when !CONFIG_MODULE_UNLOAD or !CONFIG_MODULE. v3: minor fixes: - fixed a checkpatch warning; - use a single line for the new function prototype. v2: - the dependencies are now handled directly at try_module_get(). Mauro Carvalho Chehab (2): module: update dependencies at try_module_get() ALSA: hda - identify when audio is provided by a video driver include/linux/module.h | 8 +++-- kernel/module/main.c | 65 ++++++++++++++++++++++++++++++-------- sound/hda/hdac_component.c | 2 +- 3 files changed, 57 insertions(+), 18 deletions(-) -- 2.35.1 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 35881C433EF for ; Sat, 30 Apr 2022 20:05:12 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 8956010EADB; Sat, 30 Apr 2022 20:05:05 +0000 (UTC) Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by gabe.freedesktop.org (Postfix) with ESMTPS id B6A8410EAC9; Sat, 30 Apr 2022 20:05:03 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 09C7C60FAD; Sat, 30 Apr 2022 20:05:03 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 508D4C385A7; Sat, 30 Apr 2022 20:05:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1651349102; bh=qQ90+vzIfAbuP6uHng6MH3iDdoxyuq9y8LCR9IxIB7o=; h=From:To:Cc:Subject:Date:From; b=oriawJX7mtL42TvPN4GPv6rgWqPRYbv0P0DCAGQPD8ae1FLEM8nDTAzpN14/H7KW8 QGO8HYOlQCAyusmUQxTlX7AU4uE+KX1ejlriQOa0rzN4yzw7PNTQ+m43xh4ZhWINEK umFfsCvsAW9unoPkPirwbA0MrYCae9t8oHywbEBCVl57MTUkR3/qP+8Wzit3EbdMrB Utv4IKODv4i5UoK0rqOFvbtSzUdB4Lg6CHD7ts0KS2IwfajQwn7/6dxCewnKzvHpUO WCOPJqQY+OyWsG+AziiZVxLzCyGmJT4WZJhQFlOMXKxrUPpOdoLISRJsbZDukeTSbV AsdI7I4+hFoBw== Received: from mchehab by mail.kernel.org with local (Exim 4.94.2) (envelope-from ) id 1nktKr-001uvr-Ma; Sat, 30 Apr 2022 21:04:57 +0100 From: Mauro Carvalho Chehab To: Luis Chamberlain Date: Sat, 30 Apr 2022 21:04:53 +0100 Message-Id: X-Mailer: git-send-email 2.35.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: [Intel-gfx] [PATCH v5 0/2] Let userspace know when snd-hda-intel needs i915 X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: mauro.chehab@linux.intel.com, alsa-devel@alsa-project.org, Kai Vehmanen , Greg KH , intel-gfx@lists.freedesktop.org, Lucas De Marchi , Takashi Iwai , dri-devel@lists.freedesktop.org, Jaroslav Kysela , David Airlie , linux-modules@vger.kernel.org, Mauro Carvalho Chehab , linux-kernel@vger.kernel.org, Pierre-Louis Bossart Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" Currently, kernel/module annotates module dependencies when request_symbol is used, but it doesn't cover more complex inter-driver dependencies that are subsystem and/or driver-specific. In the case of hdmi sound, depending on the CPU/GPU, sometimes the snd_hda_driver can talk directly with the hardware, but sometimes, it uses the i915 driver. When the snd_hda_driver uses i915, it should first be unbind/rmmod, as otherwise trying to unbind/rmmod the i915 driver cause driver issues, as as reported by CI tools with different GPU models: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_6415/fi-tgl-1115g4/igt@core_hotunplug@unbind-rebind.html https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11495/bat-adlm-1/igt@i915_module_load@reload.html In the past, just a few CPUs were doing such bindings, but this issue now applies to all "modern" Intel CPUs that have onboard graphics, as well as to the newer discrete GPUs. With the discrete GPU case, the HDA controller is physically separate and requires i915 to power on the hardware for all hardware access. In this case, the issue is hit basicly 100% of the time. With on-board graphics, i915 driver is needed only when the display codec is accessed. If i915 is unbind during runtime suspend, while snd-hda-intel is still bound, nothing bad happens, but unbinding i915 on other situations may also cause issues. So, add support at kernel/modules to allow snd-hda drivers to properly annotate when a dependency on a DRM driver dependencies exists, and add a call to such new function at the snd-hda driver when it successfully binds into the DRM driver. This would allow userspace tools to check and properly remove the audio driver before trying to remove or unbind the GPU driver. It should be noticed that this series conveys the hidden module dependencies. Other changes are needed in order to allow removing or unbinding the i915 driver while keeping the snd-hda-intel driver loaded/bound. With that regards, there are some discussions on how to improve this at alsa-devel a while back: https://mailman.alsa-project.org/pipermail/alsa-devel/2021-September/190099.html So, future improvements on both in i915 and the audio drivers could be made. E.g. with discrete GPUs, it's the only codec of the card, so it seems feasible to detach the ALSA card if i915 is bound (using infra made for VGA switcheroo), but, until these improvements are done and land in upstream, audio drivers needs to be unbound if i915 driver goes unbind. Yet, even if such fixes got merged, this series is still needed, as it makes such dependencies more explicit and easier to debug. PS.: This series was generated against next-20220428. --- v5: - while v4 works fine, it ends calling try_module_format() recursively, which is not what it it was supposed to do. So, change the logic to avoid such recursion, by adding a static __try_module_format() and renaming the new version that takes two arguments as try_module_format_owner(). v4: - fix a compilation warning reported by Intel's Kernel robot when !CONFIG_MODULE_UNLOAD or !CONFIG_MODULE. v3: minor fixes: - fixed a checkpatch warning; - use a single line for the new function prototype. v2: - the dependencies are now handled directly at try_module_get(). Mauro Carvalho Chehab (2): module: update dependencies at try_module_get() ALSA: hda - identify when audio is provided by a video driver include/linux/module.h | 8 +++-- kernel/module/main.c | 65 ++++++++++++++++++++++++++++++-------- sound/hda/hdac_component.c | 2 +- 3 files changed, 57 insertions(+), 18 deletions(-) -- 2.35.1 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from alsa0.perex.cz (alsa0.perex.cz [77.48.224.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 76D6FC433F5 for ; Sat, 30 Apr 2022 20:06:06 +0000 (UTC) Received: from alsa1.perex.cz (alsa1.perex.cz [207.180.221.201]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa0.perex.cz (Postfix) with ESMTPS id DA02E1F2; Sat, 30 Apr 2022 22:05:13 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz DA02E1F2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1651349163; bh=qQ90+vzIfAbuP6uHng6MH3iDdoxyuq9y8LCR9IxIB7o=; h=From:To:Subject:Date:Cc:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:From; b=ZyrR/nou+3v1LGG6HuhrsWk+LDfY4esVjIm0jNIcXqgBzjpG2AQ6hlFXbVP6Un7jn b9BedXSruOEoKeOpKFU+Cx+YQoUDoWfkQxAPFGIWC9FHHiSWEtzQidd8YC9EUmNjQ4 nTB7/oQLtKNpKuh4vsSsItKjmPCqOZMLrfe0DwYM= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id 719BFF800E9; Sat, 30 Apr 2022 22:05:13 +0200 (CEST) Received: by alsa1.perex.cz (Postfix, from userid 50401) id A4FA4F8016E; Sat, 30 Apr 2022 22:05:11 +0200 (CEST) Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id 64D3EF800E9 for ; Sat, 30 Apr 2022 22:05:04 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 64D3EF800E9 Authentication-Results: alsa1.perex.cz; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="oriawJX7" Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 09C7C60FAD; Sat, 30 Apr 2022 20:05:03 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 508D4C385A7; Sat, 30 Apr 2022 20:05:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1651349102; bh=qQ90+vzIfAbuP6uHng6MH3iDdoxyuq9y8LCR9IxIB7o=; h=From:To:Cc:Subject:Date:From; b=oriawJX7mtL42TvPN4GPv6rgWqPRYbv0P0DCAGQPD8ae1FLEM8nDTAzpN14/H7KW8 QGO8HYOlQCAyusmUQxTlX7AU4uE+KX1ejlriQOa0rzN4yzw7PNTQ+m43xh4ZhWINEK umFfsCvsAW9unoPkPirwbA0MrYCae9t8oHywbEBCVl57MTUkR3/qP+8Wzit3EbdMrB Utv4IKODv4i5UoK0rqOFvbtSzUdB4Lg6CHD7ts0KS2IwfajQwn7/6dxCewnKzvHpUO WCOPJqQY+OyWsG+AziiZVxLzCyGmJT4WZJhQFlOMXKxrUPpOdoLISRJsbZDukeTSbV AsdI7I4+hFoBw== Received: from mchehab by mail.kernel.org with local (Exim 4.94.2) (envelope-from ) id 1nktKr-001uvr-Ma; Sat, 30 Apr 2022 21:04:57 +0100 From: Mauro Carvalho Chehab To: Luis Chamberlain Subject: [PATCH v5 0/2] Let userspace know when snd-hda-intel needs i915 Date: Sat, 30 Apr 2022 21:04:53 +0100 Message-Id: X-Mailer: git-send-email 2.35.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Cc: mauro.chehab@linux.intel.com, alsa-devel@alsa-project.org, Kai Vehmanen , Greg KH , intel-gfx@lists.freedesktop.org, Lucas De Marchi , Takashi Iwai , dri-devel@lists.freedesktop.org, David Airlie , linux-modules@vger.kernel.org, Daniel Vetter , Mauro Carvalho Chehab , linux-kernel@vger.kernel.org, Pierre-Louis Bossart X-BeenThere: alsa-devel@alsa-project.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Alsa-devel mailing list for ALSA developers - http://www.alsa-project.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: "Alsa-devel" Currently, kernel/module annotates module dependencies when request_symbol is used, but it doesn't cover more complex inter-driver dependencies that are subsystem and/or driver-specific. In the case of hdmi sound, depending on the CPU/GPU, sometimes the snd_hda_driver can talk directly with the hardware, but sometimes, it uses the i915 driver. When the snd_hda_driver uses i915, it should first be unbind/rmmod, as otherwise trying to unbind/rmmod the i915 driver cause driver issues, as as reported by CI tools with different GPU models: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_6415/fi-tgl-1115g4/igt@core_hotunplug@unbind-rebind.html https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11495/bat-adlm-1/igt@i915_module_load@reload.html In the past, just a few CPUs were doing such bindings, but this issue now applies to all "modern" Intel CPUs that have onboard graphics, as well as to the newer discrete GPUs. With the discrete GPU case, the HDA controller is physically separate and requires i915 to power on the hardware for all hardware access. In this case, the issue is hit basicly 100% of the time. With on-board graphics, i915 driver is needed only when the display codec is accessed. If i915 is unbind during runtime suspend, while snd-hda-intel is still bound, nothing bad happens, but unbinding i915 on other situations may also cause issues. So, add support at kernel/modules to allow snd-hda drivers to properly annotate when a dependency on a DRM driver dependencies exists, and add a call to such new function at the snd-hda driver when it successfully binds into the DRM driver. This would allow userspace tools to check and properly remove the audio driver before trying to remove or unbind the GPU driver. It should be noticed that this series conveys the hidden module dependencies. Other changes are needed in order to allow removing or unbinding the i915 driver while keeping the snd-hda-intel driver loaded/bound. With that regards, there are some discussions on how to improve this at alsa-devel a while back: https://mailman.alsa-project.org/pipermail/alsa-devel/2021-September/190099.html So, future improvements on both in i915 and the audio drivers could be made. E.g. with discrete GPUs, it's the only codec of the card, so it seems feasible to detach the ALSA card if i915 is bound (using infra made for VGA switcheroo), but, until these improvements are done and land in upstream, audio drivers needs to be unbound if i915 driver goes unbind. Yet, even if such fixes got merged, this series is still needed, as it makes such dependencies more explicit and easier to debug. PS.: This series was generated against next-20220428. --- v5: - while v4 works fine, it ends calling try_module_format() recursively, which is not what it it was supposed to do. So, change the logic to avoid such recursion, by adding a static __try_module_format() and renaming the new version that takes two arguments as try_module_format_owner(). v4: - fix a compilation warning reported by Intel's Kernel robot when !CONFIG_MODULE_UNLOAD or !CONFIG_MODULE. v3: minor fixes: - fixed a checkpatch warning; - use a single line for the new function prototype. v2: - the dependencies are now handled directly at try_module_get(). Mauro Carvalho Chehab (2): module: update dependencies at try_module_get() ALSA: hda - identify when audio is provided by a video driver include/linux/module.h | 8 +++-- kernel/module/main.c | 65 ++++++++++++++++++++++++++++++-------- sound/hda/hdac_component.c | 2 +- 3 files changed, 57 insertions(+), 18 deletions(-) -- 2.35.1