From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0a-0031df01.pphosted.com (mx0a-0031df01.pphosted.com [205.220.168.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 659AA3451A6 for ; Fri, 24 Jul 2026 16:29:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=205.220.168.131 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784910589; cv=none; b=eDesgGzq3hAQlt2QsFU81bMo6BSI2Wp5CPZqAUqmE2nu1mERwRHusLXGEI6dCSbZzOlcVkaXon1So98IQtke6jNfY+xujj116E5NS+YXyKr6Cvzjh7xz3KySHEiT0SYAchxapBqz2cUJj3Gq+BUzTArsOBUQwwpIHX4W/X9vKbM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784910589; c=relaxed/simple; bh=519jXsEOx2nmWF6tQf42pw3IycBl4FPwWx2Sr4UsdfE=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=W+b+4Bll3T4quI3if5A7zVbN5uq46tOCcyVHQK8+RJzwYap0scUe1satcPdTRCy2vL8ZGLJ7Q13MMbooaVK3KzVaV4mRwawRzPf6VqBDIyBeUvia1zJvDv8QCb60y0opR6MqVR8LPunWuXnICNrhSFGdLxp/tpiqO380d6+wIpU= 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=MwFCVUG4; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b=VUKMZO5G; arc=none smtp.client-ip=205.220.168.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="MwFCVUG4"; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b="VUKMZO5G" Received: from pps.filterd (m0279863.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 66ODbMCE3344886 for ; Fri, 24 Jul 2026 16:29:47 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= LLcN47DbXTezK++pGJvoRjhYXt0+3r2c+iWJU0RjDto=; b=MwFCVUG4ip4G/YrO tr8iopJZ+2tR3DFWW3FOW+h/ns1lLINT46/Z3E5gT1aafx7wOvc77PZeL+W+i5TW TQNOywn/W7pV4Gd+nzUcsetrYj5pZS1UCu+wU6NDaRUOy4tkiCAt3RGlq2CazqBn S1ogl0lQYQkzbOkQO9/gWZ3numjq9oAsW4cDhGYPF08aKJdgraU07YuO33fSg085 g9zaZ9vU5fasJ0IgVl+px+aNrac0uLQNrDHJKWxAHhj12kDTQnBZLNp5cRnn+2uM F+CtKDoJmJQ7GY40NbF+elDFasJtFoSPs/3jVJ4nIMmpje4YFcXjUW6/UTFt/QOm cdyHoQ== Received: from mail-qt1-f200.google.com (mail-qt1-f200.google.com [209.85.160.200]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4fm8cf0ud5-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Fri, 24 Jul 2026 16:29:47 +0000 (GMT) Received: by mail-qt1-f200.google.com with SMTP id d75a77b69052e-5276aa86d00so10181521cf.2 for ; Fri, 24 Jul 2026 09:29:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1784910586; x=1785515386; 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=LLcN47DbXTezK++pGJvoRjhYXt0+3r2c+iWJU0RjDto=; b=VUKMZO5GoYPn+++5+aFZKmwUQ47dpCy7TluAHjd+EgeS6rcJW/OKpoSxspBxVk0oyE 9JCUrw4QBZzyPFMRAP28PMWymaE1J2zbR8Jdn9UtqNF1nP2jufdCHIA1AERLFooy0RvI K1vSTXlbR0cMHVEob8ZZbl3iN9yxayGCG/xl+7qryuMCy8hLLt710Owhg7hlmQIo7E9S vZoZiU6e9LOefMNT/7u7Zsxuo15eMk6ks0+Fx2gdHrki02gMD4Q5RvNiLUtnI4GB+pUI P8iikO6MbGNgLXGXy0GmGN2IORRoKf9L6czjeYihlAHBOp/TdkSaK6srkF4P9PfRqF2w h6Og== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784910586; x=1785515386; 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=LLcN47DbXTezK++pGJvoRjhYXt0+3r2c+iWJU0RjDto=; b=JupKEix1zAO6ad08fIP1I+/nOpqDobi7qF8AsL+FAbtJvYRgfTU2FJKQpT0k4vQIeu pzftgwQLfR1W1MBbduil1lGkNis6V2hRCEs2Ys+kDCGRpoW5B2PtuP6uHXPG05h74oeE Gi7PPE639Y7i90/F+p9FdY2arUL8EgxLWvNe+eRZNgegfvQTg6fZueAhxPSF22tTQnMc vjNsPEjnNOYhEXZ2p/sAAdu4GDWFrCqwrZWggpUFxSDNFZSzoXqk5VkJIDX/fRkdHIA3 5fQY4Evm3ojJBlTeLGl5gH5ZDSCYCA0y0pVyFqlruVySj8zGJXOqtsueHlamypwmxc68 qbTA== X-Forwarded-Encrypted: i=1; AHgh+Rpo0L31XEAnIiWoD0Iv7vXHyfYYk4h075zsHsRI/pFAbHgsMB6LhqnDsSKPqeiYJDNXErS/kQAA++5N7kU=@vger.kernel.org X-Gm-Message-State: AOJu0YyFW5AYfs3eJb+SXUBgw8/UWWhrt3Ul0r8dIlVxsFi3kJrQlJB0 KP21Afm8k05FLuyNHvHdA/BEq0GTR6IF7yzgxX7QciZ/n43fqDYx61XWFj+1kxrff6dOOXx+2lQ LO5nB+rTg6WfCvD6M660ylokCQyYXRxqGeeEkqiXPkUHyOieUGhL3pLk3lWoeccLC+e8= X-Gm-Gg: AR+sD10vIVYbCb2JXpqT9pJ6UqSd21pEjZZi6QsDzsGePbgq1PPNgZb1XTHv7Sn3Dtg Em94k3ROb9RvYbRWDOMVj4W3S2728dZrr3EDTIHSrN1WFpivwScAKAvpQTNpEJ8kkEGBNLvrG0c BECb0Z2ZZ6/ooax5uwkrKlDYnYi0ZG1NKuwp0K2IwTNTU9FaCEKDYtz+TFG1X0GAvJQony32MZQ zUTnSY7A7nJ44zKlcQW7diRnb29fcgIKZfN093B2lQFl7ysrGRNUJpQEq0JJKtcJmc2nowhuQ4E BkppH9E18JQu1drQi0Shk3NfEQBvJzPpbiRZhSYTXQLgbzF0BHWYolfVB9ynY8/dJe5iAXIhk7L 6i0UYuuDiFhml5qQqRFynBX4XocY= X-Received: by 2002:ac8:610d:0:b0:51c:7b12:5ff5 with SMTP id d75a77b69052e-5283dfea897mr79954001cf.81.1784910586411; Fri, 24 Jul 2026 09:29:46 -0700 (PDT) X-Received: by 2002:ac8:610d:0:b0:51c:7b12:5ff5 with SMTP id d75a77b69052e-5283dfea897mr79953671cf.81.1784910585797; Fri, 24 Jul 2026 09:29:45 -0700 (PDT) Received: from [192.168.68.114] ([5.133.47.210]) by smtp.googlemail.com with ESMTPSA id 5b1f17b1804b1-496b486cbc7sm2053125e9.12.2026.07.24.09.29.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 24 Jul 2026 09:29:44 -0700 (PDT) Message-ID: <28811194-255d-41e1-a952-1c10c03f669d@oss.qualcomm.com> Date: Fri, 24 Jul 2026 17:29:44 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH 0/8] ASoC: SDCA: enable on DT platforms and add Qualcomm WCD9378 (Tambora) codec To: Charles Keepax Cc: Mark Brown , Liam Girdwood , Jaroslav Kysela , Takashi Iwai , Maciej Strozek , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Srinivas Kandagatla , Bard Liao , Pierre-Louis Bossart , Richard Fitzgerald , Jorijn van der Graaf , linux-sound@vger.kernel.org, linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org, patches@opensource.cirrus.com, linux-kernel@vger.kernel.org References: <20260722234221.884765-1-srinivas.kandagatla@oss.qualcomm.com> <87452472-0ca6-4ed5-a891-3a688598b5b3@oss.qualcomm.com> <6d1870c1-7fff-4569-8de2-bb45b83cde25@oss.qualcomm.com> Content-Language: en-US From: Srinivas Kandagatla In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Proofpoint-Spam-Info: AW1haW4tMjYwNzI0MDE0NyBTYWx0ZWRfX96jOclawLKJz Uku6A6e/pdlgiW3lX1o1qoWKllnizmgM2PNLZVhd+HBBnhnuy6jbEfoeiH2PfHcoLXrICG3Fos9 HCC4SJWGQGLmQSA7dxYOrSNQEaEtJ6o= X-Proofpoint-GUID: wj0FsKNrVKM6xU-dDTNk2yN_G_k3ArAU X-Proofpoint-ORIG-GUID: wj0FsKNrVKM6xU-dDTNk2yN_G_k3ArAU X-Authority-Analysis: v=2.4 cv=er/vCIpX c=1 sm=1 tr=0 ts=6a6392fb cx=c_pps a=JbAStetqSzwMeJznSMzCyw==:117 a=ZsC4DHZuhs/kKio7QBcDoQ==:17 a=IkcTkHD0fZMA:10 a=RAioF0-LDSMA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=yOCtJkima9RkubShWh1s:22 a=RbUyBYV5fK3iINMusi0A:9 a=QEXdDO2ut3YA:10 a=uxP6HrT_eTzRwkO_Te1X:22 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwNzI0MDE0NyBTYWx0ZWRfX5XrsKEk5fs+/ KRV3REV34bRfdcYOKePvqnoek8Aazuxua9yC4o0DTpdmQX3PWv6s0UQyep7dY7bgt7z5A6sykyN +OrliO07kDflf6PwW/WpdOfmeBIhY0xyf3umHPAUxmu+vmL6FgrLO/ubIATYWPvCvxmhCkms5iA +pM+JBC0j1KNvl1Vb40H1u28aKNvqrE8kaaUsCsVhHoq+w/D2FomoFt2ANxfYOVptSDEpIAfiGs 4gqYyrqMC+Csyl5cuGgXD31pv65a+/QaNn5bRnVoOR0aQaxN5pWVvs+AKmOfxy04SHBb2fDJF43 tH9Bbyr9AVY/gEfO8m+Y52eFIbUKz8GXzgG0O76i/+Kv0EacfsbzYZQr9u6tefaqRVLoKJdZf6g Sn8TLGI8QL318k5zKP+uWcEIC4NmQkefKJrZu7HlSx4iwdh+46AZa4KV5nfjOlPiUcjxq2nVl22 lv7LyhJs53KIvpn63CA== X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.134,FMLib:17.12.100.49 definitions=2026-07-24_03,2026-07-24_02,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 suspectscore=0 priorityscore=1501 impostorscore=0 spamscore=0 clxscore=1015 bulkscore=0 malwarescore=0 phishscore=0 lowpriorityscore=0 adultscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2606150000 definitions=main-2607240147 On 7/24/26 4:40 PM, Charles Keepax wrote: > On Fri, Jul 24, 2026 at 03:31:51PM +0100, Srinivas Kandagatla wrote: >> On 7/24/26 1:36 PM, Charles Keepax wrote: >>> On Thu, Jul 23, 2026 at 02:24:19PM +0100, Srinivas Kandagatla wrote: >>>> Thanks Charles, for the feedback. >>>> On 7/23/26 11:17 AM, Charles Keepax wrote: >>>>> On Thu, Jul 23, 2026 at 12:42:10AM +0100, Srinivas Kandagatla wrote: >>> Yeah agree be good to get the DT guys thoughts on this. It seems >>> like a misstep to me to insist that the SDCA spec implements a >>> completely different system of storing information for DT. SDCA >>> is what SDCA is now, and supporting two different parsers seems >>> like work no one needs when the one parser we have would work >>> fine for both. >> Am not sure I understood the two parser concern, what we are >> representing in the table is something that sdca core already does after >> parsing acpi tables. So we are reusing the same structures. Its like >> result of already parsed acpi tables. >> >> I did try > > Apologies for not being clear. It wasn't strictly a review > comment on the code in the series. It was a wider point that at > some point the world likely will want to put SDCA data in DT, > when that happens there are basically two choices: > > 1) Use the "same" representation as ACPI, in this case we can > share all the parsing code we have now. But some of the things > might be a little unusual for DT. > > 2) Do something more idiomatic for DT, which would likely end > up looking very different. But this would require a whole new > parser and lengthy standardisation process. > I'm inclined to go with this approach as well, provided the Device Tree maintainers are satisfied with the initialization sequences. The rest of the topology bindings appears solid. This decision would also establish a precedent for handling other DisCo-based devices in Device Trees. > Mostly what I am interested in here is getting at what the end > goal is. The impression I got was that really everyone from > Plumbers was really more aligned to 2). I am not sure I agree > that is the right choice, although willing to be convinced here. > >>> That said I don't totally object to the idea of an option to >>> supply a static block of information as you are in the series. It >>> could be useful for transitional and work around situations. But >>> it doesn't seem like a good choice for SDCA on DT going forward, >>> it is basically going back to the board files that DT was saving >>> us from. >> >> Either we have this at driver level or at dt level, both of them have >> pros and cons. >> >> If we decide to go with dt, this how the dt entries will look like, this >> should give fair bit of idea to DT maintianers for discussion. > > Thank you so much for mocking this up, that is very helpful. > > Are there additional constraints from your side pushing you > one way or another on this? Or are you happy to do either? I am > thinking things like DT needing to be flashed onto systems that > have now shipped or something. No restrictions as such, its just consensuses with DT maintainers. --srini > > Thanks, > Charles