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 2CDD7C433FE for ; Thu, 27 Oct 2022 02:57:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233540AbiJ0C5J (ORCPT ); Wed, 26 Oct 2022 22:57:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37588 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229456AbiJ0C5G (ORCPT ); Wed, 26 Oct 2022 22:57:06 -0400 Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 277D517587 for ; Wed, 26 Oct 2022 19:57:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1666839426; x=1698375426; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=bf2paH8sGyUfEw1cg7Z4uilrA3dFquFMe+m0DHeulpU=; b=T880nBdgsITIa1afeAB+XKQ1fc64JJ3W+m2irLYksAPQHHWp0XldJGlE XKzpmSdCS/1+WGxXhxI0MmFLcbwVLq0ju3m1HOSWDWN7YPXiVC8eaBGoH 7JlDPSGjNlUcsWS248Dd0jNFRtwSBk4vAdD56H0ulfUIRYHhxssIap1lf fqdBgBCsTlDh4ibmLNcioKWIh0zniYdK/Y7fsN75VKgWDgFuJlXsaCfAj T9N4qIOxZn/3p1UG+KA1WYiua3R5pjVCnFYmwdw80k1iu+1fPYTLo4uXD dAwlAoZlJ0orvPcEZXu/XZjjfyp0sn9fi8w8qXcOy/BaPMmG5XZ8HcvJ4 w==; X-IronPort-AV: E=McAfee;i="6500,9779,10512"; a="305730005" X-IronPort-AV: E=Sophos;i="5.95,215,1661842800"; d="scan'208";a="305730005" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Oct 2022 19:57:05 -0700 X-IronPort-AV: E=McAfee;i="6500,9779,10512"; a="632248942" X-IronPort-AV: E=Sophos;i="5.95,215,1661842800"; d="scan'208";a="632248942" Received: from bcoan-mobl2.amr.corp.intel.com (HELO [10.209.189.197]) ([10.209.189.197]) by orsmga002-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Oct 2022 19:57:03 -0700 Message-ID: Date: Wed, 26 Oct 2022 20:30:00 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0 Thunderbird/102.2.2 Subject: Re: [PATCH 2/2] ASoC: Intel: sof_rt5682: quirk auto detection To: "Lu, Brent" , "alsa-devel@alsa-project.org" Cc: "C, Balamurugan" , "Rojewski, Cezary" , Chao Song , Kai Vehmanen , "Wang, Rander" , Bard Liao , Takashi Iwai , "Song, Gongjun" , "linux-kernel@vger.kernel.org" , Liam Girdwood , "Chiang, Mac" , Mark Brown , "Reddy, Muralidhar" , Ranjani Sridharan , Ajye Huang , Peter Ujfalusi , "Gopal, Vamshi Krishna" , "Zhi, Yong" References: <20221026071409.3235144-1-brent.lu@intel.com> <20221026071409.3235144-3-brent.lu@intel.com> <6916c126-c710-330a-ffcd-50dd3cdc47d3@linux.intel.com> Content-Language: en-US From: Pierre-Louis Bossart In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/26/22 19:13, Lu, Brent wrote: >> >> This is a bit confusing: this quirk does not work for Volteer >> >> { >> .callback = sof_rt5682_quirk_cb, >> .matches = { >> DMI_MATCH(DMI_PRODUCT_FAMILY, >> "Google_Volteer"), >> DMI_MATCH(DMI_OEM_STRING, "AUDIO- >> MAX98373_ALC5682I_I2S_UP4"), >> }, >> .driver_data = (void *)(SOF_RT5682_MCLK_EN | >> SOF_RT5682_SSP_CODEC(0) | >> SOF_SPEAKER_AMP_PRESENT | >> >> SOF_MAX98373_SPEAKER_AMP_PRESENT | >> SOF_RT5682_SSP_AMP(2) | >> SOF_RT5682_NUM_HDMIDEV(4)), >> }, > > I checked Volteer reference kit, it should use SSP1 for amplifier. It seems to me > this quirk is for some customer variants which implements MAX98373 on SSP2. > >> >> Same for Brya and all usages of SSP_AMP(2) >> >> > > It's a compromise that Google implements amplifiers on SSP2 on Brya so they can > connect SDW codec to SSP1 pins, but we asked customers to implement amplifiers > on SSP1 to reserve BT offload capability. I appreciate what you are trying to suggest, and I am all for trying to put this proliferation of quirks under control, but the autodetection based on rules seems out-of-reach if we don't first cleanup the existing quirks. If "volteer" and "brya" mean different things to different people, and reference and derivatives are not well identified, the odds of regressions seem very high to me. > >>> - { >>> - .name = "adl_rt1019_rt5682s", >>> - .driver_data = (kernel_ulong_t)(SOF_RT5682_MCLK_EN | >>> - SOF_RT5682_SSP_CODEC(0) | >>> - >> SOF_RT5682S_HEADPHONE_CODEC_PRESENT | >> >> and HEADPHONE_CODEC_PRESENT is not handled either. >> > > Headphone type will be detected later in the sof_audio_probe(). > >>> - SOF_SPEAKER_AMP_PRESENT | >>> - SOF_RT1019_SPEAKER_AMP_PRESENT >> | >>> - SOF_RT5682_SSP_AMP(1) | >>> - SOF_RT5682_NUM_HDMIDEV(4)), >>> - }, >> >> Overall I doubt that the SOC alone can tell you what the quirk is. >> >> Maybe it's a default to avoid repeats of the same baseline configuration, but >> there's not much else that can be infer from an SOC definition in light of the >> creativity of our hardware friends who routinely swap interfaces. > > I'm thinking about using kernel module parameters for those boards which do not > use default SSP port allocation. Not sure it's doable for machine driver module. That's not a working solution IMHO, the kernel parameters should be used by expert developers only for specific and short-term debug. It's not possible to add a dependency on kernel parameters, that would prevent a kernel update.