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 X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 32E43C3815B for ; Mon, 20 Apr 2020 07:11:45 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id 111682078E for ; Mon, 20 Apr 2020 07:11:44 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 111682078E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=intel-gfx-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 8FB486E1CD; Mon, 20 Apr 2020 07:11:44 +0000 (UTC) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by gabe.freedesktop.org (Postfix) with ESMTPS id 4B2376E1CD for ; Mon, 20 Apr 2020 07:11:43 +0000 (UTC) IronPort-SDR: /F2G0nqAUFtmaKql7xwiyLoalyl/RPy5NaXIR8/zJA87r9NW5PXD1vIqRpxoijooF5SvVTJUSJ mp5rlNDeKwPg== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Apr 2020 00:11:42 -0700 IronPort-SDR: yoKGQc9AUIUrZlZfQaELfoyCHiZ+zZxH+keabxbcZ7U3GWegBwhC/tswh5g4Eu/U58lmp5b8dZ WERh3X0IRgUw== X-IronPort-AV: E=Sophos;i="5.72,406,1580803200"; d="scan'208";a="429020644" Received: from iastakh-mobl.ccr.corp.intel.com (HELO localhost) ([10.252.63.229]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Apr 2020 00:11:40 -0700 From: Jani Nikula To: Kai Vehmanen In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo References: <20200417065132.23048-1-jani.nikula@intel.com> Date: Mon, 20 Apr 2020 10:11:37 +0300 Message-ID: <875zdu3a3a.fsf@intel.com> MIME-Version: 1.0 Subject: Re: [Intel-gfx] [PATCH] drm/i915/audio: error log non-zero audio power refcount after unbind 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: intel-gfx@lists.freedesktop.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" On Fri, 17 Apr 2020, Kai Vehmanen wrote: > Hi Jani, > > On Fri, 17 Apr 2020, Jani Nikula wrote: > >> We have some module unload/reload tests hitting an issue with i915 >> unbinding the component interface before the audio driver has properly >> put the power. Log an error about it for ease of debugging. (Normally > > thanks, this is a good addition: > Reviewed-by: Kai Vehmanen Thanks for the review, pushed to drm-intel-next-queued. > Maybe one point to consider is whether to take the next step and just > block the unload. On audio side, once acomp binding is done to i915 > driver, it is only released at hda driver unload. So any test case where > audio driver is bound to i915, and test unloads i915 without unloading > the audio driver first, will not work. Even if no immediate failure is > seen at unload, functionality will be impacted after i915 is loaded > again. > > Not sure how to do this though. Normally module refcounts would take care > of this (and block i915 unload), but now that we have the component > framework in between, something else is needed. Heh, had I known what to do, I'd have posted that. So I just opted for logging to make the failure mode obvious. I admit I didn't check what having an unbalanced get will actually do. If we go ahead and power down the power well, I assume it'll cripple the audio driver. I think our refcounting and power well handling should read the hardware state and set up everything properly on load, but the audio driver will have lost its marbles in the mean time. Even if by some chance it doesn't lose its power during i915 unload/load cycle, it won't have the component interface and can't ensure i915 doesn't go ahead and cut power later. BR, Jani. > > PS Audio driver also doesn't implement component unbind(), but I don't > immediately see what it could do there. It can't return an error > and the audio framework is not really prepared for invidual codec > drivers to disappear at runtime. We can handle hotplug of complete > cards (like USB), but individual codec drivers are expected to stay loaded. -- Jani Nikula, Intel Open Source Graphics Center _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx