From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C655835E1AA for ; Mon, 7 Sep 2026 22:37:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=205.220.180.131 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788820675; cv=none; b=AF3XBQtFNWKDYwZW/nF3GeRZGHGYgThZRtC7jJ4J9Nczlv+b9xds1HTGxUExbVCZ8Dtd07TIT+Li5Yk86N7waLxRsZHkaVCJ8RJQeiHFMuGXlXnoF17p4sNM2/4Ki6aE0UNmCsliw340jPpw/C2cIMIxH3XAWwX2bUjpmDx04B4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788820675; c=relaxed/simple; bh=TZ4DWrxjbgCOgZGMyUgrWtEjIm1edbnu1qkrI7QgGP0=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=l8f5qCnBMpS6yD00qbp7rpCgFMwd/41jQlZGY7kRbmdg1oZHVfWnBG7CyrReyY7yYNoUN22m5ZBNUy4y3cWrYoxA777ZQ+d35pmfnQ9x7V2VrpCEu56MunaN3aaIp3pl0aLWf+NfJvOTt5AINHrzRWoPaO/O4LaZdEwjBGEHHhA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oss.qualcomm.com; spf=pass smtp.mailfrom=oss.qualcomm.com; dkim=pass (2048-bit key) header.d=qualcomm.com header.i=@qualcomm.com header.b=UKFgZ5l+; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b=VYSgASjI; arc=none smtp.client-ip=205.220.180.131 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=qualcomm.com header.i=@qualcomm.com header.b="UKFgZ5l+"; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b="VYSgASjI" Received: from pps.filterd (m0279870.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 687Kl84B1155543 for ; Mon, 7 Sep 2026 22:37:52 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qualcomm.com; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s=qcppdkim1; bh= 66fvz1bKKpOHQ2hALp4KOX+2R/2+zrYNIxixzBLxwIs=; b=UKFgZ5l+J5A92JZC QyHm2GiOwoLt9px5CfUWrMjodF7pGpxHu+DHd7MLQEEa/rtZ4bNRu/WIQUXS8eYW 3aXtbovulB6iFiUEUfboe6A1r+UZqILk5ZyW0sac87nK1A4J+pAqRNHi1ndCslQm xCPm2GKIVfxKVpo1FDiX+fnInZW9XST6DRxguxXBlS9R4L6Eo2BliJqDQ+xlVGx3 K8c6xjGM+9665n50GEOiJnzaW3aLiGT8xIk2XsZYCrtcwlwzHeHdQorbC1VrXUCj rBXhDcHg6Ns70cU+nG3f4FvODTys5SujfAiH2YlMr12Ta0KSNTuXgh1vt634yRN1 WzPO3w== Received: from mail-qk1-f197.google.com (mail-qk1-f197.google.com [209.85.222.197]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4ghs86u064-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Mon, 07 Sep 2026 22:37:52 +0000 (GMT) Received: by mail-qk1-f197.google.com with SMTP id af79cd13be357-92e4f946461so716706785a.2 for ; Mon, 07 Sep 2026 15:37:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1788820672; x=1789425472; darn=vger.kernel.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=66fvz1bKKpOHQ2hALp4KOX+2R/2+zrYNIxixzBLxwIs=; b=VYSgASjICD/OXD5a4SrEmgNDL9qGiJH7fHUO/azPAP7bdWbIy3/yZw26vRhKnk+e0B h35FpdIiQu0MczTH1/XTTTpQ1ZDMJn8JxuRTV6zdqZrcgkmPDhbPWvzx/0do91bJoJqu H5GqQhWFT8EXCOx/NTNfxEFub3XRIMoy6RT8lb7K36p9Ku1uSPSKKAKnuTJuhk7iLyiA BC5XBeSwYHb+snAza57GMmbKiAZ/+3W7mlFbU65ImvO+k4s//sPZvfT0WXpqMvpZ0I+g 4TgEx1E/4el0f/Vrg/xCup1qqeoOHqtWasU/y1oLMVIUfIJO/0ruqlFxazfzJgiNzhtS dpZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788820672; x=1789425472; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=66fvz1bKKpOHQ2hALp4KOX+2R/2+zrYNIxixzBLxwIs=; b=Ll0H/KGH+11wCcX+mIs4iNcGLIX3mBhQpJszsGJK7JXahgJXu1FNAUNyptRx2UqCeX V450zD1iEUcqM8Yv3v1cEg0jc/HshQgIzBd6YXG8KVt5XTbQFoXEv3LwnezhuNDR+hn6 Nu0zLHtDOSt+VUEyv2ma/oMv/5ml3H1BODVbO91YFKiubHtHCn5HnH8GnmiBdFI2Zd55 MCuoeJFUDpryd8f7qL+WK49j36m3j9Eb9S3iPHXkHd9zGThey3QjqfCD7W7to4CSz+7h 3SHsAJsUZvNHuzpNES5kzcZzfCuR5OYKsSNB8Yjj5T6w0PLq1xJJb78sFlh1X3rxkrhJ 9h5w== X-Forwarded-Encrypted: i=1; AKwUvBw8E//bjjKYtP/14I4f3paLeqeaCEt6jndi64rvZH+jKn7epgfwLfTJ/gLVdQXCidiujX5JegKUuM9DEg==@vger.kernel.org X-Gm-Message-State: AFuF++kpWgSeUOXVqVpyvTroqtgYkb/B9FvZBxY1+5J2EzbMpQYBWYCI w8jSrloVS3qvOsX9AdnvShKWQ/5pxe7sOfo0DhDRM7Ad6DXMyTjOAylJzwAAPQFC4Oivh+Eszv9 iMxdQTzyfvXpjLfvQsQzaSQ4yI0+9JmUW8Eodp5DSHCjC2j2JXDmf8CdtnaK296XXcA== X-Gm-Gg: AYBFou3+Y4UCwUH6bW7Gh52+FVPCS+niKc2ACUbBT1LyLFdOYF7EX8SPQYMBnEF6Yyx p8uxPS5FNhmfwtrh+xvvckXLj9KhC7BXEt7VmeJJnMmFAdf1imMXbNE3tuxGMcsJ2xjQDc1NWKk Cc85/B8vyaexqRqyhHpqFeHJ+PUs0qtCsq0Zf5VT2pW12UmIzLQiW1qKR5lvGU+E54sPmJjVebU 32fZMnk92+CJhxeps1XlHTxQGqiDv2DzNg1xOK2uSG/iocR1WOedlRSWpEc9QOHXfpbOfXL9Fuq u2dHglgHQ/Ybhzpfy1rs82Oy9SRgvGqEUvfMkR/xtRnginmORnrzM5KPgVZbMsj1ZdZNrjgm465 Gk1NpthZUMWvqPnd5XSw/czpNxvE= X-Received: by 2002:a05:620a:6890:b0:930:f337:ebeb with SMTP id af79cd13be357-93980379720mr2890723485a.12.1788820671653; Mon, 07 Sep 2026 15:37:51 -0700 (PDT) X-Received: by 2002:a05:620a:6890:b0:930:f337:ebeb with SMTP id af79cd13be357-93980379720mr2890717685a.12.1788820671090; Mon, 07 Sep 2026 15:37:51 -0700 (PDT) Received: from [192.168.68.120] ([5.133.47.210]) by smtp.googlemail.com with ESMTPSA id 5b1f17b1804b1-49cee5d476esm468229645e9.1.2026.09.07.15.37.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 07 Sep 2026 15:37:50 -0700 (PDT) Message-ID: Date: Mon, 7 Sep 2026 23:37:49 +0100 Precedence: bulk X-Mailing-List: linux-sound@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 11/11] ASoC: codecs: add Qualcomm Tambora (WCD9378) SDCA codec To: Pierre-Louis Bossart , Mark Brown , Rob Herring , Charles Keepax Cc: Krzysztof Kozlowski , Conor Dooley , Bard Liao , Jaroslav Kysela , Liam Girdwood , Maciej Strozek , Takashi Iwai , Faiz Nabi Kuchay , Jorijn van der Graaf , patches@opensource.cirrus.com, linux-sound@vger.kernel.org, devicetree@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org References: <20260907083727.733705-1-srinivas.kandagatla@oss.qualcomm.com> <20260907083727.733705-12-srinivas.kandagatla@oss.qualcomm.com> <525f887e-cb3b-4e74-8b93-30c3baeb8018@linux.dev> <7006ad74-334c-41cb-bcc8-9ef5e75dde7e@oss.qualcomm.com> <005e3c81-778a-47bc-a8ae-fb5c38ea2e2c@linux.dev> Content-Language: en-US From: Srinivas Kandagatla In-Reply-To: <005e3c81-778a-47bc-a8ae-fb5c38ea2e2c@linux.dev> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Proofpoint-GUID: KGOTuMzeHmMr0_jgjE-ZSllPYeEy5DpR X-Proofpoint-ORIG-GUID: KGOTuMzeHmMr0_jgjE-ZSllPYeEy5DpR X-Proofpoint-Spam-Info: AW1haW4tMjYwOTA3MDI0OSBTYWx0ZWRfX36JaCzkY0QEj hL9K5byph6a9Rdk5bKX6h2V83yscvaYTWm1rg/pqRBbLIByBLy4IS1D1uAv5VxGkwD5cgdFWLkl YxWUOz8cPS6AMq9kVD/bryc1BhInlgI= X-Authority-Analysis: v=2.4 cv=LseiDHdc c=1 sm=1 tr=0 ts=6a9f3cc0 cx=c_pps a=50t2pK5VMbmlHzFWWp8p/g==:117 a=ZsC4DHZuhs/kKio7QBcDoQ==:17 a=IkcTkHD0fZMA:10 a=VdqzKS8jKosA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=gowsoOTTUOVcmtlkKump:22 a=D19gQVrFAAAA:8 a=D15zt_m3DPPUnS_4hLIA:9 a=QEXdDO2ut3YA:10 a=O8hF6Hzn-FEA:10 a=IoWCM6iH3mJn3m4BftBB:22 a=W4TVW4IDbPiebHqcZpNg:22 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwOTA3MDI0OSBTYWx0ZWRfX8O52ErOruI9G U7fGx5R8Jm84VTTWsH71DXGPDumYaBg1odcOkL/hvZ3WurjeialkK1GL9f/Qs3jHLkE7IUCIQdX 6PJDbV1WF1O/42LNmMCIs+88gCZoOuGg26vvY7pGE0GJClJhpLrfm9TB9Is55TmpUdQM5tZE3cZ dtOkzchNbRs/pUsODtmRcsmK8hF+0Z59pvlU7tbaTXlJJiuatilw99X3JObm1voE/CfJ3QYCGMW SCeEbW1MnRNJicRwEKk6uM2fAPOZ2PEYVKfGZSKre5uL4zWBA9YOIPHsHm3pa66r38bj1LPavO3 jGy7zE7mANY8NX02fz0eDv4vdotWwy90OfDchQkEp6UBsVLFIYvfgRw6Jf6T+RmW2FBQjoA3Nkn 66gtxm/hLwLuGiA0GCSkY9Zp1sfGfkqSBZQTNk7eo+P14HAWKzGaqCSLs/ma0hCZ5u0/ZUeL+DP g5O9BvnmnLmDQEL6eqQ== X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49 definitions=2026-09-07_06,2026-09-07_01,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 phishscore=0 impostorscore=0 spamscore=0 lowpriorityscore=0 suspectscore=0 adultscore=0 bulkscore=0 malwarescore=0 priorityscore=1501 clxscore=1015 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2606150000 definitions=main-2609070249 On 9/7/26 8:47 PM, Pierre-Louis Bossart wrote: > My take is that rather than encode all properties in C, it's probably > worth exploring a DT representation of the concepts that *can* be used > fairly easily and make the life of codec vendors easier - not as a> literal translation of ACPI. Two things are getting mixed here: A. Representation: how the SDCA info is expressed as ACPI DisCo, DT properties, static C tables, or a firmware blob. B. Reuse of the generic class function drivers, which ultimately consume struct sdca_function_data. Whatever A looks like, we end up at the same struct sdca_function_data that B consumes. sdca_parse_function() converts ACPI DisCo to it today; populate_function() does the same from static C tables; a DT parser would do it from DT. Same runtime after that. Static C tables at least mirror the SDCA spec's own entity/control structure, so the code stays readable against the spec rather than inventing a new shape. They are also a byte-for-byte match against Qualcomm's QcSimpleJack.asl and a live Lenovo T14s DSDT, so we are not maintaining them as a fork of the vendor source, they are a mechanical transcription with a verifiable origin. We landed on static C tables here because the previous DT round was clear: "if it's derivable from the compat string, keep it out of DT" (https://lkml.org/lkml/2026/7/29/1166). As Mark pointed out, DT + SDCA has two use-cases today: 1. Devices that have a reference ACPI table but boot Linux with DT because no ACPI enablement package (PEP) exists on the SoC yet. this is what I'm working on. 2. Devices with no ACPI reference at all. I'm not sure any of the SDCA codecs in sound/soc/codecs/*sdca* today falls into that category. Solving both in one shot requires SDCA DT bindings that either translate to struct sdca_function_data, or represent the SDCA spec fully in DT and share the same parser flow. I agree a DT expression of the *concepts* not a literal DisCo mirror would be a better A. I want to bring that back to LPC 2026 DT MC as a concrete proposal grounded in the earlier DT-maintainer feedback rather than re-litigating it inline on this series. Because B stays put, switching A later is a change inside populate_function, not an ABI break. so landing this series does not close the door on the representation you're asking for. --srini > > Putting everything in C seems like a code management nightmare to me.