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 A508B4EA365 for ; Thu, 23 Jul 2026 13:24:28 +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=1784813076; cv=none; b=Xc69kJL7Lym9NzoKsvbAYprVuc6rQhRpz5OT5+JgBCd05/i0Cp1tbg7KxXoTVPGZh+nkzjPm4ueejQ8j9BWfAk4hd6soRIxIcVknO+0liwD/oOP5oa+aqevBlSTTZeWQhKYEOCUYMjbiJ0fgTXv6jQxv6YCooBmD5yA0QusRcME= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784813076; c=relaxed/simple; bh=66QXVKRJYLwnx8HswYcjbnxXibKlyOWsqjz//XC307A=; h=Message-ID:Date:MIME-Version:From:Subject:To:Cc:References: In-Reply-To:Content-Type; b=mgBOTOZMrIFRmkHT+QhPWP2kU9ZAeDFbWUwvM+ZctU1DNO0xOfpMdDfUhrSAXHUAxuOulG4N4HIcvlKh1oQ2AHNwUHGIxhIaR2x+HYSJIECS8HoksNkSMzMr38gG9z/ZZV6gp9bE3foe4CXJG+uIKNoTI8FqY0Mhp9N7btARLtU= 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=lfO574ye; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b=N4qP2vZm; 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="lfO574ye"; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b="N4qP2vZm" Received: from pps.filterd (m0279862.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 66NCvH3W3951253 for ; Thu, 23 Jul 2026 13:24:23 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= I+tIrIzMEDOG2UJi/AWhvxVqwpvTlllKht4g+vLmRSU=; b=lfO574ye8HK0V0/I 91GQS2pRjr1E8WoOm5PTlrNZxdSSI0AJqh8oYRUkfFX8pmFVSatSUUWBcfmyZ3on Or3yBzJjK2ZJ5K0WOG9+QTXuLxRzvZdwANn/XUu0zbluhwM8V0I78tfJ4wuZWz2I Y/2mCqVhvKMCTEZcJz9gep7mhSWPRwdbPKvvq5L3cqjahuO7G55y18JbIS3GQWXB YmNAHQS+ARzS17d5mJDFLIImML5GPJA8NV+bozEF04h5fIC2iVJ91s0pLIWxLsBN m/ahwT/2lcHjLvDvjCPwMd2pi8wYU4dvkJY/zFzIe2xcZcL2ylmNu88fw6nTpxRA vQvOFw== Received: from mail-qt1-f197.google.com (mail-qt1-f197.google.com [209.85.160.197]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4fkjnu8aj2-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Thu, 23 Jul 2026 13:24:23 +0000 (GMT) Received: by mail-qt1-f197.google.com with SMTP id d75a77b69052e-52827090cc5so8271101cf.0 for ; Thu, 23 Jul 2026 06:24:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1784813062; x=1785417862; darn=vger.kernel.org; h=content-transfer-encoding:content-type:in-reply-to:content-language :references:cc:to:subject:from:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to:content-type; bh=I+tIrIzMEDOG2UJi/AWhvxVqwpvTlllKht4g+vLmRSU=; b=N4qP2vZmErJOUsU56KwNBwzIdqSlR4VuIXjgGwqZScYBLtbXP+NkW7/XEt3Yx9XOWt ItbdV1wHXmIfojBYaWKGlFZt80cH7Gk6/WnsE0FlnmnTudTsF8/HOVDKM06Y/1OMtEe0 uuFxz4QXo+MSvFvLBcE/8c1O9oaVPcPk12FicDsn3lhPK+a30o88Ed+0fzp0bF2xI749 XVsFDwtQSc2Dqc49uRhgImXfwTeclM0VXKBeYsAnI9h307AQTBaUQZBuhbVyH5oJP9Ub myLZ+my4vWRvFe+LMBup8G/51ppTSmzeYzYbwp/+IsV+EkIgBu1RhHBJhPjQJgevXkjh CizA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784813062; x=1785417862; h=content-transfer-encoding:content-type:in-reply-to:content-language :references:cc:to:subject:from: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=I+tIrIzMEDOG2UJi/AWhvxVqwpvTlllKht4g+vLmRSU=; b=oVkHMVJ2Xrlb/NXYOZ11CYsy+3pqputcWcvOuDOpodgDKdLBVxC/8uZ0KxLUfvTcsF Fothls4x6sK7vRSOckb6aIMvV1pD2ZBoHIgInrzBvp+XuqBExgwPnHr6dn6ircLfv+Zr GXH+ayRgHX45uOCalt+6LYjctSjqtZeLUaLnr8C2EpsUNs/HF9g+gWUU1gQoQNCnnKNZ zVcStOGNPQ3MzObynEPnoyHueZKF44yIak1a88GKOO6eR/uVtg5iOVlfB6cuTOKHlKzk I4xyrPVWvcC7Y0rV+wka+V4u0Fv3b1LYXckFoUIZndFz7yEaV05mkQMTAjwDNrrRMYiK 8kSg== X-Forwarded-Encrypted: i=1; AHgh+RobZvIWiJWbhpY7AsLggC7PC+N2BYJpxL1albofo2xB+E3WBWF7+i3S2MDard8nL8TkcD7gYaV/6Mjw1pw=@vger.kernel.org X-Gm-Message-State: AOJu0Yxyp68RUFXxcYmeSQEhqP167iv6MwB8Xz6fCwQ42mJhwCs+wf0X xKS4A2Z1rGwG1Yc+Xg7yXmj/yoFe9IqLw/HakkmKNAj1G2KyjIGjEONIL8LP+yooK6MG+n3f1Dw 49NhmIT9EaDl5KLlPcg5gWbl5JijF/qMWWsu46dXqVQ8WlSXDqKG7yktu34I81Yu+4Bk= X-Gm-Gg: AR+sD129ZVWd89EzpBex60KzBU+HvizHsDUPk2eDTQTm4solci/oa067z8cZQkqm59O x7A0j8ARM+p6QzP5EFer7UlQlJboCjjKX2A7cXpY+/t8Pw3t054R6eeJhO+ZinWvtvpi/xkjsZ0 n0+79M6PRPQTqN6L3Xz5PywziFc9kr9jE31l8TST2srXLj0vjDnt4WIMuRcZ/D/WVYl4SMTL2/B E72yLd5dn0FeuH9jvQxX6QPNas3igf+hHEzGqfXLVMROMCj/FFb4FFdUjT63jK8rhpBx48hzPTT Ubcx/vCaG6B/fyLu9/BcHGlCdwjRobtREg+UFcAORsBsqX7u4iXGebXcHMKjRwKNLufI93hqTen 2SWzPsOCrG697tIG+nVftSc4Na48= X-Received: by 2002:a05:622a:2307:b0:51c:1f35:4638 with SMTP id d75a77b69052e-5283edcea5dmr23958301cf.21.1784813062296; Thu, 23 Jul 2026 06:24:22 -0700 (PDT) X-Received: by 2002:a05:622a:2307:b0:51c:1f35:4638 with SMTP id d75a77b69052e-5283edcea5dmr23957551cf.21.1784813061675; Thu, 23 Jul 2026 06:24:21 -0700 (PDT) Received: from [192.168.68.114] ([5.133.47.210]) by smtp.googlemail.com with ESMTPSA id a640c23a62f3a-c1c32c90b42sm237982866b.38.2026.07.23.06.24.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 23 Jul 2026 06:24:20 -0700 (PDT) Message-ID: <87452472-0ca6-4ed5-a891-3a688598b5b3@oss.qualcomm.com> Date: Thu, 23 Jul 2026 14:24:19 +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 From: Srinivas Kandagatla 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> Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Proofpoint-ORIG-GUID: DzgNk-0zZZk_a8FKK3_DzARU3AifLLga X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwNzIzMDEzMiBTYWx0ZWRfXyp9/ElvcqoDN EtV54wn1utz8/s3qix1N24vIoq4efQWaDNaDXviNlGdUVDWmrY8PzUUIRlbc/aoj4H7lUiR+8xv LBzj0eJeyF3fmz6vwduKFPOdwLtD612iwZCLW7UavjcAr0m+DiUO6ZqP8vPPo9vhzsJc7bC5dwo pBPoQayh/klD9WPH5RXeTaZzLxAn8zWZdcZ6d+muAAWxfoUlQE3b0u96c6hvyZF3eIsJRLjZyZ0 954Ct4GkOyTqr2E/F4Bjcx+Fp0ftrswpuSvGVpYuaB1BQE5vmnTT2RXuDYJtBNrNwGr8YZl32jy 6Xzi2RoPxiEh9IyJ80PpM9vYe0aZrqc0YlAcWMJnwmliqHMMk1RkjAPZdr2xJ4QS+go6i7y42fw K8imVhxuV1Gh0NxdKOEmABtkASmE5RIg6Osh3RkVu12w5fturCMhcuDfDf99ptTNNfkhYx11/aJ UDXrWpJZ8ief6K8D3bg== X-Authority-Analysis: v=2.4 cv=Een4hvmC c=1 sm=1 tr=0 ts=6a621607 cx=c_pps a=EVbN6Ke/fEF3bsl7X48z0g==:117 a=ZsC4DHZuhs/kKio7QBcDoQ==:17 a=IkcTkHD0fZMA:10 a=RAioF0-LDSMA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=_K5XuSEh1TEqbUxoQ0s3:22 a=u_zJV4-JodRfILz-2DsA:9 a=QEXdDO2ut3YA:10 a=a_PwQJl-kcHnX1M80qC6:22 X-Proofpoint-Spam-Info: AW1haW4tMjYwNzIzMDEzMiBTYWx0ZWRfX/X1RHSxCGIH9 TS7ViizHsIvuLcu2Xac5yFUM7YQDD+IYB4At5rNkA9RI5Q18e77VLWLOhIAYC8pyTW4MlyH8hFS Pu4J9fWGsZIPTCvlc2X7LqLeNrqNzHI= X-Proofpoint-GUID: DzgNk-0zZZk_a8FKK3_DzARU3AifLLga 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-23_04,2026-07-22_02,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 lowpriorityscore=0 bulkscore=0 spamscore=0 priorityscore=1501 suspectscore=0 malwarescore=0 impostorscore=0 clxscore=1015 adultscore=0 phishscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2606150000 definitions=main-2607230132 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: >> At Linux Plumbers 2025 in the Devicetree MC I raised the "SDCA and the >> classic ACPI-DT problem" [1]: MIPI SDCA is built around ACPI/DisCo >> firmware descriptors, and the in-tree ASoC SDCA framework >> (sound/soc/sdca/) enumerates functions, entities, controls and PDEs by >> walking those tables. On ARM64 DT platforms there is no DisCo, so the >> framework is unreachable and sdca codecs will not be able to use the >> generic sdca drivers and duplicating. >> >> The direction from that discussion was to let DT platforms reuse the >> same class/function auxiliary driver plumbing and have codec drivers >> supply the small amount of static function/entity metadata that DisCo >> would otherwise carry, plus hooks for device-specific bring-up. This >> series is a first cut at that, with the Qualcomm WCD9378 ("Tambora") >> SDCA codec on the Glymur CRD as the first consumer. Static table that in >> part of this codec is generated from acpi tables. > > Fascinating, a shame I missed the discussion. Main question > I have is what was the reasoning behind using static tables > rather than just putting the data in device tree? All the core > code uses the generic firmware parsing function so should be > perfectly capable of parsing the data out of device tree. The > only bit that is missing is really the sdca_lookup_functions > bit you ifdef out, but updating that to also support DT should > be pretty simple. Two reasons 1. This is laptop platform primarily works on windows with proper acpi tables, These tables are directly derived for ACPI asl tables in windows. Ideally I want to use it the way it is supposed to work. 2. replicating full Disco specs in DT is going to be challenge, Because DT describes hardware but not necessarily at a level of register init tables or to an extent where class drivers need it. > > Looking through your presentation (thanks for linking that), > am I to guess this was mostly a device tree people didn't like > the stuff SDCA contains problem? I do see that some of the SDCA > stuff isn't an exact match for how Linux has traditionally liked > to handle DT but also really not sure I see any benefit to DT > and ACPI support being different. I think there is fine line on what can go into DT, some of the hardware init tables are big No No i guess, Power and other ACPI things are not something DT does. I will let DT maintainers comment on this. > > I guess there is also a slightly risk the standard committee > eventually get round to device tree and adds support differently, > but an existing large user would be an excellent steer on them. > I think whole Disco has not considered DT at all. >> * 1: hw_params fix for OT DAI upstream Input Terminals (found while >> bringing up Tambora capture). > > Thanks that is indeed something that needs some work. > >> * 2: allow sound/soc/sdca/ to build without ACPI. >> * 3: turn sdca_class into an exported library and introduce >> struct sdca_class_hw_ops with hw_init + get_function_data, so a >> codec driver registers its own sdw_driver, supplies static function >> descriptors when there is no DisCo node, and owns regulators/reset >> at probe time. The built-in class_sdw_driver stays for >> pure-generic parts (hw_ops = NULL). > > Yeah, we have not really implemented any XU type stuff yet. Some > discussion about whether we want to proceed with adding custom > callbacks into the class driver or just call the core functions > from the end driver. The later was really the original intention > although I do grant that there has ended up being slightly more > boiler plate in the class driver than would have been ideal. XU should be opaque to class drivers. > >> * 4: pde_pre_pmu / pde_post_pmu hooks in hw_ops so vendor drivers >> can stage/commit register writes around PDE PS0 transitions. >> * 5: of_xlate_dai_name that resolves sound-dai cells by entity index >> rather than positional DAI order. >> * 6: register SDCA_FUNCTION_TYPE_SIMPLE_JACK in the class function >> driver. > > We can probably just merge the simple jack support as is. I will > have a look. > > Going to likely take me a few days to work my way through things, > but please bear with me. Great to see the SDCA stuff getting some > proper usage outside of us :-) Thanks for the positive note. Plan is to get all the Qualcomm SDCA codecs to use existing sdca drivers than writing duplicate code. We do have couple of more SDCA drivers, the one I could include in next version is a Simple Amp driver which has pretty much in similar lines WCD9378 codec, everything leveraged from generic drivers. --srini > > Thanks, > Charles