Message ID | 1674728065-24955-6-git-send-email-quic_srivasam@quicinc.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:eb09:0:0:0:0:0 with SMTP id s9csp198440wrn; Thu, 26 Jan 2023 02:18:18 -0800 (PST) X-Google-Smtp-Source: AMrXdXsbteR7ABoHyIXY2q90cUFU1CbsqrB/L40jmKN8wl3FD1l0TT06Gtj8VmvIyreOZKdq03Sn X-Received: by 2002:a05:6402:5110:b0:499:8849:5fb3 with SMTP id m16-20020a056402511000b0049988495fb3mr47591165edd.31.1674728298486; Thu, 26 Jan 2023 02:18:18 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1674728298; cv=none; d=google.com; s=arc-20160816; b=Xhp7RIkw33oYGcal3GPR9hm3jr+awko1NEKvJ1D6azfnwupNYEM0kO1IFmSKP7iwIb lxfheOhts8IUGrwOEviNHbG9P4PlWcoNO9j874IOmhlUpowxsW0300hPdDhFum2qMbR5 MClVA7RI8kaILLxBJYwCR1paSyNAyv4/0l2B6rCktHuCBOs9AkQzkgTTt66i6B+5w6Uj zxlSUu9p//w+NWm0YHfUcDVw/fUbG4+swLOXDTJ4yp9CJefZInDZNTC7y5YzR7j2m7Tr AU8wmVRrsyHp/7B3QtCvn8tAIiYrE8O4MsRcn7RJ7mBY2A/d0a85zfCi72bwVc+9cMbE HaaA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:references:in-reply-to:message-id :date:subject:cc:to:from:dkim-signature; bh=Rog7IjBl53peKfwf86UNTR0z1spPZn0jX6cQAVnSuSI=; b=Lz0vTdb8Y8W1EV2oULl8afun3HjZVkB9qqfSjwopFkCY5I51u9BaMmq+Nefo4OaXGb 68sttqP50bufO+Q1SJw44TM9mmwMNUBTFvpWhZa/iXoKLGaVUN+13tKgkUUhJiKgpAJz tCBLnIo2SJprCup+/kntQw61ubzAx9IMJQyBtBArPthltluKF7sUY9g/ZSicuFmQM4Nx FDRNLN3LZMPE7Ee1WLWYKnCCGcqZ7HT8I/W9vQgHbT7NvSaS7o19N+i8dYF4a0EX4wiw nt1nw/M3f3IlDZwJjWBdP0S9OPiJvkqwg+otHENRmrLAqQTLPcfXMYc6byqguJFu7AEA R7ow== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@quicinc.com header.s=qcppdkim1 header.b=VCIjdT0N; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=quicinc.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id r29-20020a50aadd000000b004a0aacac82esi1558940edc.192.2023.01.26.02.17.53; Thu, 26 Jan 2023 02:18:18 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@quicinc.com header.s=qcppdkim1 header.b=VCIjdT0N; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=quicinc.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236715AbjAZKPv (ORCPT <rfc822;lekhanya01809@gmail.com> + 99 others); Thu, 26 Jan 2023 05:15:51 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38060 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237058AbjAZKPX (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 26 Jan 2023 05:15:23 -0500 Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.131]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A4A332E821; Thu, 26 Jan 2023 02:15:15 -0800 (PST) Received: from pps.filterd (m0279869.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 30Q9nP8T031637; Thu, 26 Jan 2023 10:15:10 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; h=from : to : cc : subject : date : message-id : in-reply-to : references : mime-version : content-type; s=qcppdkim1; bh=Rog7IjBl53peKfwf86UNTR0z1spPZn0jX6cQAVnSuSI=; b=VCIjdT0N3felBCa9nLLr9lWChjtEsZPw9Is9trWHiODWpMJ52wRB1cvpy0sbEmjiDCU6 mTIVgDCAfN5uWgHaZy8nZOp3wYiND9gLQl08b4myQwKJCpTYEz6mzYQ+dZEXRXAV+Ber M3qG7N1Dp5/rbq+3yCK5GBFHHO//BijrE7DT1EO/TNG4M63a3Ycy+rHeZRIYmjMslXBW tODwLnuqE63PzPE8Vur2R8nZZrVVeHumRDAvcavV8Iz0b2TtAXx+SFdrFYmz/RLWa0rw kAO01dfLqujxy01FsVe3Uj670Kp8hBNhqp/qgJ8LSda/xGi2W7ccMFGfF6yMDdPr2L8r WA== Received: from nalasppmta02.qualcomm.com (Global_NAT1.qualcomm.com [129.46.96.20]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 3nak7jkn39-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 26 Jan 2023 10:15:09 +0000 Received: from nalasex01a.na.qualcomm.com (nalasex01a.na.qualcomm.com [10.47.209.196]) by NALASPPMTA02.qualcomm.com (8.17.1.5/8.17.1.5) with ESMTPS id 30QAF8HK001632 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 26 Jan 2023 10:15:08 GMT Received: from hu-srivasam-hyd.qualcomm.com (10.80.80.8) by nalasex01a.na.qualcomm.com (10.47.209.196) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.36; Thu, 26 Jan 2023 02:15:03 -0800 From: Srinivasa Rao Mandadapu <quic_srivasam@quicinc.com> To: <swboyd@chromium.org>, <agross@kernel.org>, <andersson@kernel.org>, <robh+dt@kernel.org>, <broonie@kernel.org>, <quic_plai@quicinc.com>, <krzysztof.kozlowski+dt@linaro.org>, <konrad.dybcio@somainline.org>, <mturquette@baylibre.com>, <sboyd@kernel.org>, <linux-arm-msm@vger.kernel.org>, <linux-clk@vger.kernel.org>, <linux-kernel@vger.kernel.org>, <quic_rohkumar@quicinc.com> CC: Srinivasa Rao Mandadapu <quic_srivasam@quicinc.com> Subject: [PATCH v6 5/6] clk: qcom: lpassaudiocc-sc7280: Merge lpasscc into lpass_aon Date: Thu, 26 Jan 2023 15:44:24 +0530 Message-ID: <1674728065-24955-6-git-send-email-quic_srivasam@quicinc.com> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1674728065-24955-1-git-send-email-quic_srivasam@quicinc.com> References: <1674728065-24955-1-git-send-email-quic_srivasam@quicinc.com> MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanex01b.na.qualcomm.com (10.46.141.250) To nalasex01a.na.qualcomm.com (10.47.209.196) X-QCInternal: smtphost X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=5800 signatures=585085 X-Proofpoint-GUID: _zDrVA-byk2A6Xty8x3IAiZy8PfQr40s X-Proofpoint-ORIG-GUID: _zDrVA-byk2A6Xty8x3IAiZy8PfQr40s X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.219,Aquarius:18.0.930,Hydra:6.0.562,FMLib:17.11.122.1 definitions=2023-01-26_04,2023-01-25_01,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 impostorscore=0 lowpriorityscore=0 spamscore=0 malwarescore=0 mlxlogscore=781 priorityscore=1501 mlxscore=0 phishscore=0 clxscore=1015 bulkscore=0 suspectscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2212070000 definitions=main-2301260097 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1756079900024057791?= X-GMAIL-MSGID: =?utf-8?q?1756079900024057791?= |
Series |
Add resets for ADSP based audio clock controller driver
|
|
Commit Message
Srinivasa Rao Mandadapu
Jan. 26, 2023, 10:14 a.m. UTC
Merge lpasscc clocks into lpass_aon clk_regmap structure as they are using same register space. Add conditional check for doing lpasscc clock registration only if regname specified in device tree node. In existing implementation, lpasscc clocks and lpass_aon clocks are being registered exclusively and overlapping if both of them are to be used. This is required to avoid such overlapping and to register lpasscc clocks and lpass_aon clocks simultaneously. Fixes: 4ab43d171181 ("clk: qcom: Add lpass clock controller driver for SC7280") Signed-off-by: Srinivasa Rao Mandadapu <quic_srivasam@quicinc.com> Tested-by: Mohammad Rafi Shaik <quic_mohs@quicinc.com> --- drivers/clk/qcom/lpassaudiocc-sc7280.c | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-)
Comments
Quoting Srinivasa Rao Mandadapu (2023-01-26 02:14:24) > Merge lpasscc clocks into lpass_aon clk_regmap structure as they > are using same register space. > Add conditional check for doing lpasscc clock registration only > if regname specified in device tree node. > In existing implementation, lpasscc clocks and lpass_aon clocks are > being registered exclusively and overlapping if both of them are > to be used. > This is required to avoid such overlapping and to register > lpasscc clocks and lpass_aon clocks simultaneously. Can you describe the register ranges that are overlapping? Here's what I see in DT right now: lpasscc: lpasscc@3000000 { compatible = "qcom,sc7280-lpasscc"; reg = <0 0x03000000 0 0x40>, <0 0x03c04000 0 0x4>; ... }; lpass_audiocc: clock-controller@3300000 { compatible = "qcom,sc7280-lpassaudiocc"; reg = <0 0x03300000 0 0x30000>, <0 0x032a9000 0 0x1000>; ... }; lpass_aon: clock-controller@3380000 { compatible = "qcom,sc7280-lpassaoncc"; reg = <0 0x03380000 0 0x30000>; ... }; lpass_core: clock-controller@3900000 { compatible = "qcom,sc7280-lpasscorecc"; reg = <0 0x03900000 0 0x50000>; ... }; Presumably lpascc is really supposed to be a node named 'clock-controller' and is the node that is overlapping with lpass_aon? > > Fixes: 4ab43d171181 ("clk: qcom: Add lpass clock controller driver for SC7280") > Signed-off-by: Srinivasa Rao Mandadapu <quic_srivasam@quicinc.com> > Tested-by: Mohammad Rafi Shaik <quic_mohs@quicinc.com> > --- > drivers/clk/qcom/lpassaudiocc-sc7280.c | 13 +++++++++---- > 1 file changed, 9 insertions(+), 4 deletions(-) > > diff --git a/drivers/clk/qcom/lpassaudiocc-sc7280.c b/drivers/clk/qcom/lpassaudiocc-sc7280.c > index 1339f92..8e2f433 100644 > --- a/drivers/clk/qcom/lpassaudiocc-sc7280.c > +++ b/drivers/clk/qcom/lpassaudiocc-sc7280.c > @@ -826,10 +829,12 @@ static int lpass_aon_cc_sc7280_probe(struct platform_device *pdev) > return ret; > > if (of_property_read_bool(pdev->dev.of_node, "qcom,adsp-pil-mode")) { > - lpass_audio_cc_sc7280_regmap_config.name = "cc"; > - desc = &lpass_cc_sc7280_desc; > - ret = qcom_cc_probe(pdev, desc); > - goto exit; > + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "cc"); We shouldn't need to check for reg-name property. Instead, the index should be the only thing that matters. > + if (res) { > + lpass_audio_cc_sc7280_regmap_config.name = "cc"; > + desc = &lpass_cc_sc7280_desc;
On 1/31/2023 6:34 AM, Stephen Boyd wrote: Thanks for your Time Stephen!!! > Quoting Srinivasa Rao Mandadapu (2023-01-26 02:14:24) >> Merge lpasscc clocks into lpass_aon clk_regmap structure as they >> are using same register space. >> Add conditional check for doing lpasscc clock registration only >> if regname specified in device tree node. >> In existing implementation, lpasscc clocks and lpass_aon clocks are >> being registered exclusively and overlapping if both of them are >> to be used. >> This is required to avoid such overlapping and to register >> lpasscc clocks and lpass_aon clocks simultaneously. > Can you describe the register ranges that are overlapping? Okay. Will add register ranges in description. > > Here's what I see in DT right now: > > lpasscc: lpasscc@3000000 { > compatible = "qcom,sc7280-lpasscc"; > reg = <0 0x03000000 0 0x40>, > <0 0x03c04000 0 0x4>; > ... > }; > > lpass_audiocc: clock-controller@3300000 { > compatible = "qcom,sc7280-lpassaudiocc"; > reg = <0 0x03300000 0 0x30000>, > <0 0x032a9000 0 0x1000>; > ... > }; > > lpass_aon: clock-controller@3380000 { > compatible = "qcom,sc7280-lpassaoncc"; > reg = <0 0x03380000 0 0x30000>; > ... > }; > > lpass_core: clock-controller@3900000 { > compatible = "qcom,sc7280-lpasscorecc"; > reg = <0 0x03900000 0 0x50000>; > ... > }; > > Presumably lpascc is really supposed to be a node named > 'clock-controller' and is the node that is overlapping with lpass_aon? Okay. As it's been coming previous patches, didn't change the name. May be we need to do it as separate patch. Yes. It's overlapping with lpass_aon ( <0 0x03380000 0 0x30000>). CC clocks range is <0 0x03389000 0 0x24>; > >> Fixes: 4ab43d171181 ("clk: qcom: Add lpass clock controller driver for SC7280") >> Signed-off-by: Srinivasa Rao Mandadapu <quic_srivasam@quicinc.com> >> Tested-by: Mohammad Rafi Shaik <quic_mohs@quicinc.com> >> --- >> drivers/clk/qcom/lpassaudiocc-sc7280.c | 13 +++++++++---- >> 1 file changed, 9 insertions(+), 4 deletions(-) >> >> diff --git a/drivers/clk/qcom/lpassaudiocc-sc7280.c b/drivers/clk/qcom/lpassaudiocc-sc7280.c >> index 1339f92..8e2f433 100644 >> --- a/drivers/clk/qcom/lpassaudiocc-sc7280.c >> +++ b/drivers/clk/qcom/lpassaudiocc-sc7280.c >> @@ -826,10 +829,12 @@ static int lpass_aon_cc_sc7280_probe(struct platform_device *pdev) >> return ret; >> >> if (of_property_read_bool(pdev->dev.of_node, "qcom,adsp-pil-mode")) { >> - lpass_audio_cc_sc7280_regmap_config.name = "cc"; >> - desc = &lpass_cc_sc7280_desc; >> - ret = qcom_cc_probe(pdev, desc); >> - goto exit; >> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "cc"); > We shouldn't need to check for reg-name property. Instead, the index > should be the only thing that matters. As qcom_cc_probe() function is mapping the zero index reg property, and in next implementation qcom_cc_really_probe() is also probing zero index reg property, unable to map the same region twice. Hence all I want here is to skip this cc clock probing by keeping some check. If we remove, it may cause ABI break. > >> + if (res) { >> + lpass_audio_cc_sc7280_regmap_config.name = "cc"; >> + desc = &lpass_cc_sc7280_desc;
Quoting Srinivasa Rao Mandadapu (2023-01-31 01:29:16) > > On 1/31/2023 6:34 AM, Stephen Boyd wrote: > Thanks for your Time Stephen!!! > > Quoting Srinivasa Rao Mandadapu (2023-01-26 02:14:24) > >> Merge lpasscc clocks into lpass_aon clk_regmap structure as they > >> are using same register space. > >> Add conditional check for doing lpasscc clock registration only > >> if regname specified in device tree node. > >> In existing implementation, lpasscc clocks and lpass_aon clocks are > >> being registered exclusively and overlapping if both of them are > >> to be used. > >> This is required to avoid such overlapping and to register > >> lpasscc clocks and lpass_aon clocks simultaneously. > > Can you describe the register ranges that are overlapping? > Okay. Will add register ranges in description. Thanks! > > > > Here's what I see in DT right now: > > > > lpasscc: lpasscc@3000000 { > > compatible = "qcom,sc7280-lpasscc"; > > reg = <0 0x03000000 0 0x40>, > > <0 0x03c04000 0 0x4>; > > ... > > }; > > > > lpass_audiocc: clock-controller@3300000 { > > compatible = "qcom,sc7280-lpassaudiocc"; > > reg = <0 0x03300000 0 0x30000>, > > <0 0x032a9000 0 0x1000>; > > ... > > }; > > > > lpass_aon: clock-controller@3380000 { > > compatible = "qcom,sc7280-lpassaoncc"; > > reg = <0 0x03380000 0 0x30000>; > > ... > > }; > > > > lpass_core: clock-controller@3900000 { > > compatible = "qcom,sc7280-lpasscorecc"; > > reg = <0 0x03900000 0 0x50000>; > > ... > > }; > > > > Presumably lpascc is really supposed to be a node named > > 'clock-controller' and is the node that is overlapping with lpass_aon? > > Okay. As it's been coming previous patches, didn't change the name. > > May be we need to do it as separate patch. Sure, another patch to rename lpasscc to clock-controller would be appreciated. > > Yes. It's overlapping with lpass_aon ( <0 0x03380000 0 0x30000>). > > CC clocks range is <0 0x03389000 0 0x24>; Is that a new register range for lpasscc? Why do we have that node at all? Can we add different properties to the existing lpass_audiocc, lpass_aon, or lpass_core nodes to indicate what clks should or shouldn't be registered or provided to the kernel? > > > > >> Fixes: 4ab43d171181 ("clk: qcom: Add lpass clock controller driver for SC7280") > >> Signed-off-by: Srinivasa Rao Mandadapu <quic_srivasam@quicinc.com> > >> Tested-by: Mohammad Rafi Shaik <quic_mohs@quicinc.com> > >> --- > >> drivers/clk/qcom/lpassaudiocc-sc7280.c | 13 +++++++++---- > >> 1 file changed, 9 insertions(+), 4 deletions(-) > >> > >> diff --git a/drivers/clk/qcom/lpassaudiocc-sc7280.c b/drivers/clk/qcom/lpassaudiocc-sc7280.c > >> index 1339f92..8e2f433 100644 > >> --- a/drivers/clk/qcom/lpassaudiocc-sc7280.c > >> +++ b/drivers/clk/qcom/lpassaudiocc-sc7280.c > >> @@ -826,10 +829,12 @@ static int lpass_aon_cc_sc7280_probe(struct platform_device *pdev) > >> return ret; > >> > >> if (of_property_read_bool(pdev->dev.of_node, "qcom,adsp-pil-mode")) { > >> - lpass_audio_cc_sc7280_regmap_config.name = "cc"; > >> - desc = &lpass_cc_sc7280_desc; > >> - ret = qcom_cc_probe(pdev, desc); > >> - goto exit; > >> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "cc"); > > We shouldn't need to check for reg-name property. Instead, the index > > should be the only thing that matters. > > As qcom_cc_probe() function is mapping the zero index reg property, and > > in next implementation qcom_cc_really_probe() is also probing zero index > reg property, > > unable to map the same region twice. Use qcom_cc_probe_by_index()? > > Hence all I want here is to skip this cc clock probing by keeping some > check. > > If we remove, it may cause ABI break. > I'm not sure what you mean here about ABI break, but hopefully just using qcom_cc_probe_by_index() works!
On 2/1/2023 1:56 AM, Stephen Boyd wrote: Thanks for your time Stephen!!! > Quoting Srinivasa Rao Mandadapu (2023-01-31 01:29:16) >> On 1/31/2023 6:34 AM, Stephen Boyd wrote: >> Thanks for your Time Stephen!!! >>> Quoting Srinivasa Rao Mandadapu (2023-01-26 02:14:24) >>>> Merge lpasscc clocks into lpass_aon clk_regmap structure as they >>>> are using same register space. >>>> Add conditional check for doing lpasscc clock registration only >>>> if regname specified in device tree node. >>>> In existing implementation, lpasscc clocks and lpass_aon clocks are >>>> being registered exclusively and overlapping if both of them are >>>> to be used. >>>> This is required to avoid such overlapping and to register >>>> lpasscc clocks and lpass_aon clocks simultaneously. >>> Can you describe the register ranges that are overlapping? >> Okay. Will add register ranges in description. > Thanks! > >>> Here's what I see in DT right now: >>> >>> lpasscc: lpasscc@3000000 { >>> compatible = "qcom,sc7280-lpasscc"; >>> reg = <0 0x03000000 0 0x40>, >>> <0 0x03c04000 0 0x4>; >>> ... >>> }; >>> >>> lpass_audiocc: clock-controller@3300000 { >>> compatible = "qcom,sc7280-lpassaudiocc"; >>> reg = <0 0x03300000 0 0x30000>, >>> <0 0x032a9000 0 0x1000>; >>> ... >>> }; >>> >>> lpass_aon: clock-controller@3380000 { >>> compatible = "qcom,sc7280-lpassaoncc"; >>> reg = <0 0x03380000 0 0x30000>; >>> ... >>> }; >>> >>> lpass_core: clock-controller@3900000 { >>> compatible = "qcom,sc7280-lpasscorecc"; >>> reg = <0 0x03900000 0 0x50000>; >>> ... >>> }; >>> >>> Presumably lpascc is really supposed to be a node named >>> 'clock-controller' and is the node that is overlapping with lpass_aon? >> Okay. As it's been coming previous patches, didn't change the name. >> >> May be we need to do it as separate patch. > Sure, another patch to rename lpasscc to clock-controller would be > appreciated. > >> Yes. It's overlapping with lpass_aon ( <0 0x03380000 0 0x30000>). >> >> CC clocks range is <0 0x03389000 0 0x24>; > Is that a new register range for lpasscc? Why do we have that node at > all? Can we add different properties to the existing lpass_audiocc, > lpass_aon, or lpass_core nodes to indicate what clks should or shouldn't > be registered or provided to the kernel? It's not new register range. They are actually AHBM and AHBS clock registers within lpass_aon regmap range. Here what I meant lpasscc clocks are not of lpasscc node. I am sorry to make you confused. As the reg-name used as "CC", mentioning it as lpasscc clocks. I will rephrase commit message and re-post. Previously these two clocks are registered separately. Now we are merging them into lpass_aon clk reg space. > >>>> Fixes: 4ab43d171181 ("clk: qcom: Add lpass clock controller driver for SC7280") >>>> Signed-off-by: Srinivasa Rao Mandadapu <quic_srivasam@quicinc.com> >>>> Tested-by: Mohammad Rafi Shaik <quic_mohs@quicinc.com> >>>> --- >>>> drivers/clk/qcom/lpassaudiocc-sc7280.c | 13 +++++++++---- >>>> 1 file changed, 9 insertions(+), 4 deletions(-) >>>> >>>> diff --git a/drivers/clk/qcom/lpassaudiocc-sc7280.c b/drivers/clk/qcom/lpassaudiocc-sc7280.c >>>> index 1339f92..8e2f433 100644 >>>> --- a/drivers/clk/qcom/lpassaudiocc-sc7280.c >>>> +++ b/drivers/clk/qcom/lpassaudiocc-sc7280.c >>>> @@ -826,10 +829,12 @@ static int lpass_aon_cc_sc7280_probe(struct platform_device *pdev) >>>> return ret; >>>> >>>> if (of_property_read_bool(pdev->dev.of_node, "qcom,adsp-pil-mode")) { >>>> - lpass_audio_cc_sc7280_regmap_config.name = "cc"; >>>> - desc = &lpass_cc_sc7280_desc; >>>> - ret = qcom_cc_probe(pdev, desc); >>>> - goto exit; >>>> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "cc"); >>> We shouldn't need to check for reg-name property. Instead, the index >>> should be the only thing that matters. >> As qcom_cc_probe() function is mapping the zero index reg property, and >> >> in next implementation qcom_cc_really_probe() is also probing zero index >> reg property, >> >> unable to map the same region twice. > Use qcom_cc_probe_by_index()? With this, if we mention some index and if it's not present in DT, it will return error. Is it okay if error is ignored and proceed? > >> Hence all I want here is to skip this cc clock probing by keeping some >> check. >> >> If we remove, it may cause ABI break. >> > I'm not sure what you mean here about ABI break, but hopefully just > using qcom_cc_probe_by_index() works!
diff --git a/drivers/clk/qcom/lpassaudiocc-sc7280.c b/drivers/clk/qcom/lpassaudiocc-sc7280.c index 1339f92..8e2f433 100644 --- a/drivers/clk/qcom/lpassaudiocc-sc7280.c +++ b/drivers/clk/qcom/lpassaudiocc-sc7280.c @@ -660,6 +660,8 @@ static struct clk_regmap *lpass_aon_cc_sc7280_clocks[] = { [LPASS_AON_CC_TX_MCLK_2X_CLK] = &lpass_aon_cc_tx_mclk_2x_clk.clkr, [LPASS_AON_CC_TX_MCLK_CLK] = &lpass_aon_cc_tx_mclk_clk.clkr, [LPASS_AON_CC_TX_MCLK_RCG_CLK_SRC] = &lpass_aon_cc_tx_mclk_rcg_clk_src.clkr, + [LPASS_Q6_AHBM_CLK] = &lpass_q6ss_ahbm_clk.clkr, + [LPASS_Q6_AHBS_CLK] = &lpass_q6ss_ahbs_clk.clkr, }; static struct gdsc *lpass_aon_cc_sc7280_gdscs[] = { @@ -819,6 +821,7 @@ static int lpass_aon_cc_sc7280_probe(struct platform_device *pdev) { const struct qcom_cc_desc *desc; struct regmap *regmap; + struct resource *res; int ret; ret = lpass_audio_setup_runtime_pm(pdev); @@ -826,10 +829,12 @@ static int lpass_aon_cc_sc7280_probe(struct platform_device *pdev) return ret; if (of_property_read_bool(pdev->dev.of_node, "qcom,adsp-pil-mode")) { - lpass_audio_cc_sc7280_regmap_config.name = "cc"; - desc = &lpass_cc_sc7280_desc; - ret = qcom_cc_probe(pdev, desc); - goto exit; + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "cc"); + if (res) { + lpass_audio_cc_sc7280_regmap_config.name = "cc"; + desc = &lpass_cc_sc7280_desc; + return qcom_cc_probe(pdev, desc); + } } lpass_audio_cc_sc7280_regmap_config.name = "lpasscc_aon";