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 7BF31C4167B for ; Tue, 5 Dec 2023 17:23:21 +0000 (UTC) Received: from alsa1.perex.cz (alsa1.perex.cz [207.180.221.201]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by alsa0.perex.cz (Postfix) with ESMTPS id 1DC849F6; Tue, 5 Dec 2023 18:23:09 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz 1DC849F6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1701796999; bh=MeDMLrXfTdh4yho03MywBVkvXJzOkrKUTV/2+kLOfuo=; h=Date:Subject:To:Cc:References:From:In-Reply-To:List-Id: List-Archive:List-Help:List-Owner:List-Post:List-Subscribe: List-Unsubscribe:From; b=t8kkTsaXeBQoLv1qxvHZccsLyZmWsAtf9VnnIut5zssILHDcP8ed08hY0s25VqUpI 4IfztSJ/k8Loe6gEndhbaOJalAoEyENpR85EMf+hdzQ+3V3tsvYd3zn6qHvDjvj9Sa azqUx6L4kML8a7lih4qvtFkNn0pzH5rK2pDeJdU0= Received: by alsa1.perex.cz (Postfix, from userid 50401) id 30288F8057C; Tue, 5 Dec 2023 18:22:48 +0100 (CET) Received: from mailman-core.alsa-project.org (mailman-core.alsa-project.org [10.254.200.10]) by alsa1.perex.cz (Postfix) with ESMTP id A4BF4F80587; Tue, 5 Dec 2023 18:22:47 +0100 (CET) Received: by alsa1.perex.cz (Postfix, from userid 50401) id 8175DF8024E; Tue, 5 Dec 2023 18:22:43 +0100 (CET) Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id 4AAC4F800AC for ; Tue, 5 Dec 2023 18:22:36 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 4AAC4F800AC Authentication-Results: alsa1.perex.cz; dkim=pass (2048-bit key, unprotected) header.d=intel.com header.i=@intel.com header.a=rsa-sha256 header.s=Intel header.b=aenZMG1o DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1701796959; x=1733332959; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=MeDMLrXfTdh4yho03MywBVkvXJzOkrKUTV/2+kLOfuo=; b=aenZMG1oW0eUUJHxxGniIzDNDOPr7Sh7wDhQ07fAsqeB/tjj9u1hfyX+ xwiEXKgt3WNJxi1ONpZisoA1+2tcLBG6+bsbEKY4+kv+n7Wrr8SuXut+P YhNm/Az874vLULzLEUnhraRv1o6YSottr0yhSkE3yhGrbJ20YpeI2Uv6l 3ZbX2W57URK0DJsbvPT1p+fvYbQ4inzohm6B0DX68fx8mi5iaPSLMhKuW 58vk6+hRfdbtr2ryfndkNrkbR2W+iLJ8+PH1Gk1kI8UX3qp/5u7OUUv/Q aKrS/rnlieGLRJX7xY4Sa6h59G/ZzCkd2C8yqLNqs24a9/V0wLIJx8zlW g==; X-IronPort-AV: E=McAfee;i="6600,9927,10915"; a="458246971" X-IronPort-AV: E=Sophos;i="6.04,252,1695711600"; d="scan'208";a="458246971" Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Dec 2023 09:22:34 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10915"; a="774702299" X-IronPort-AV: E=Sophos;i="6.04,252,1695711600"; d="scan'208";a="774702299" Received: from mbapna-mobl1.amr.corp.intel.com (HELO [10.212.151.198]) ([10.212.151.198]) by fmsmga007-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Dec 2023 09:22:33 -0800 Message-ID: <830d8e26-dbb9-4b9c-bbab-a5c4c49a7ffd@linux.intel.com> Date: Tue, 5 Dec 2023 11:22:32 -0600 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/2] ALSA: hda/tas2563: Add tas2563 HDA driver Content-Language: en-US To: Gergo Koteles , Shenghao Ding , Kevin Lu , Baojun Xu , Jaroslav Kysela , Takashi Iwai , Liam Girdwood , Mark Brown Cc: linux-kernel@vger.kernel.org, alsa-devel@alsa-project.org References: <4a2f31d4eb8479789ceb1daf2e93ec0e25c23171.1701733441.git.soyer@irl.hu> <90765ee0-a814-4852-9b2a-020cda98d930@linux.intel.com> <974d41f6c703d9b65ebcd75a2c659cecf13bd877.camel@irl.hu> <9c3846ae0da417c0fe5d4fa2d9d4134143184dda.camel@irl.hu> From: Pierre-Louis Bossart In-Reply-To: <9c3846ae0da417c0fe5d4fa2d9d4134143184dda.camel@irl.hu> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Message-ID-Hash: SL5R3A4DEOY257K6CHV7YLRFIRWPXSB7 X-Message-ID-Hash: SL5R3A4DEOY257K6CHV7YLRFIRWPXSB7 X-MailFrom: pierre-louis.bossart@linux.intel.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-alsa-devel.alsa-project.org-0; header-match-alsa-devel.alsa-project.org-1; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.9 Precedence: list List-Id: "Alsa-devel mailing list for ALSA developers - http://www.alsa-project.org" Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: >>>>> +static void tas2563_fixup_i2c(struct hda_codec *cdc, >>>>> + const struct hda_fixup *fix, int action) >>>>> +{ >>>>> + tas2xxx_generic_fixup(cdc, action, "i2c", "INT8866"); >>>> >>>> Any specific reason to use an Intel ACPI identifier? Why not use >>>> "TIAS2563" ? >>>> >>> INT8866 is in the ACPI. >>> I don't know why Lenovo uses this name. >>> I think it's more internal than intel. >>> >>>    Scope (_SB.I2CD) >>>     { >>>         Device (TAS) >>>         { >>>             Name (_HID, "INT8866") // _HID: Hardware ID >> >> Ouch, I hope they checked with Intel that this isn't an HID already in >> use... >> > It looks the INT prefix is not reserved. (yet) > https://uefi.org/ACPI_ID_List?acpi_search=INT It's been de-facto reclaimed by Intel over the years, apparently using INTC or INTL was too hard for some of my colleagues... There are lots of INT devices in the kernel today, here's a small list for sound/soc/codecs only rt274.c: { "INT34C2", 0 }, rt286.c: { "INT343A", 0 }, rt298.c: { "INT343A", 0 }, ssm4567.c: { "INT343B", 0 }, Those INT values were added by Intel teams though, it's really odd to see Lenovo use an INT-based HID. Should really use 104C2563 or something. >>>>> + return 0; >>>>> +} >>>>> + >>>>> +static const struct dev_pm_ops tas2563_hda_pm_ops = { >>>>> + SYSTEM_SLEEP_PM_OPS(tas2563_system_suspend, tas2563_system_resume) >>>> >>>> where's the pm_runtime stuff? >>>> >>> >>> The amp stores its state in software shutdown mode. >>> The tas2563_hda_playback_hook wakes/shutdowns the amp, not the >>> pm_runtime. >> >> My point was that you have all these pm_runtime_ calls in the code, but >> nothing that provides pm_runtime suspend-resume functions so not sure >> what exactly the result is? >> >> > I think nothing. I haven't experienced anything unusual recently. you can probably see from the /sys directory what the pm_runtime power state is, most likely the status is 'unknown'.