Message ID | 20221030142333.31019-1-quic_shazhuss@quicinc.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:6687:0:0:0:0:0 with SMTP id l7csp1834734wru; Sun, 30 Oct 2022 08:02:44 -0700 (PDT) X-Google-Smtp-Source: AMsMyM5UoJKpkuYNpH37pskcFbQTDPT1hjs/jjUKur/0LPP02dAV+sCq3RAi+PyhA2dND9mczyDK X-Received: by 2002:aa7:9f0c:0:b0:56b:c0a0:6ab with SMTP id g12-20020aa79f0c000000b0056bc0a006abmr9451220pfr.7.1667142163858; Sun, 30 Oct 2022 08:02:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1667142163; cv=none; d=google.com; s=arc-20160816; b=oIxYcCJvhpuucoQlKgdOnYVzEq6s849G6SVHz1Sl6LV30wtWsfRtELECy9HQredAAy 09qhJrXmqvNxahqsTBAYflkpKfVyxZqY97MjR2kC8NyKt7eq4yoqs+WkoTYwoGW5gixJ ZTXTYalUwryM4SeR0iU6XdqnBXhvPEYMHWhNPdQXPcBNcvGz8A0G7HB5a0uutEbrOTsT IShJHcep/XAbelGOe1JBiClf3HVpIohWKwy058Vms8DoNeFnJATHYkIYCUEcBOhl15yJ LzD5Q4s9IAcfAOftzQpvrntEAdhPzCCsxTXN2yriPoUg6KHpSlOQ/3Hs3RfyaTqooprk 5OMg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=LDUPl7AJWoGiHgR4WjutUPTsZY9o/snrEnz/KgKrF5g=; b=HaLNRpuIR97Qur2xLuM8EPieNHxRD3VL/ziXSNwGXGZk6JrL+SCDr5bPetekr4VTYk kSpSH41mlf2NGca/hWYnY64F3oRBsrwLowXRCnZHNUv/RXFRgLKLbO0+qERDyzS2/zRx Q9tC6XqLLE8kOmqjCe9Po59lCseSpnDhb2iMQ9pr+7ehvCQQkPLIcmYH0mEMwxlMKbP6 FddziAKPpkVBqjZ2OHgC8ocyoky6P8ewu+eEpRJAhjJpdtIrQmnisZmiYI3aPFnUnQMH STjJ6D7EteAkN93F9u+jdmocVqH8KZKm6XQeejuzP6K2Dqx2elPazMnemeI+njZ5Fio6 0+gA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@quicinc.com header.s=qcppdkim1 header.b=k0wXczey; 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 pm8-20020a17090b3c4800b00209b6044d31si5111630pjb.51.2022.10.30.08.02.30; Sun, 30 Oct 2022 08:02:43 -0700 (PDT) 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=k0wXczey; 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 S229695AbiJ3OYl (ORCPT <rfc822;paulgraves1991@gmail.com> + 99 others); Sun, 30 Oct 2022 10:24:41 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45994 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229441AbiJ3OYi (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Sun, 30 Oct 2022 10:24:38 -0400 Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.131]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0EF93B4BB; Sun, 30 Oct 2022 07:24:37 -0700 (PDT) Received: from pps.filterd (m0279868.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 29UEJ0eB029315; Sun, 30 Oct 2022 14:24:25 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; h=from : to : cc : subject : date : message-id : mime-version : content-transfer-encoding : content-type; s=qcppdkim1; bh=LDUPl7AJWoGiHgR4WjutUPTsZY9o/snrEnz/KgKrF5g=; b=k0wXczeyxGiROWoeVqWNRQYePwVtPoNC5eiPWpusSbIaPVJVpM9ZLxkBjCaKFEaV2kA2 O9ueXMHtexRR5rUTUCvI0TfdCb0HYB7t+mcTBxxosL3S7JpDNS16aRX+fBxY5VA4mzjl qZMoU3SCzbpC1sqKNyFz/avlJWcz+zQGKhRQSgcF44rh/8A4cB3expSHtnjwMQF4JisV FbxmyRYtrABMpts2/vSNZCYqV3nnr36bgZ6GMwPM7wqCWViMhDIGOBZe4QI9GTR6uRQE GRhMebPYpyjkc0/gGThlOwstgW0NnhaoTKxRdFxUXAaGkEWIylF+0LgJxlgKLKPY+ldM 3w== Received: from nalasppmta02.qualcomm.com (Global_NAT1.qualcomm.com [129.46.96.20]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 3khf9krkte-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 30 Oct 2022 14:24:25 +0000 Received: from pps.filterd (NALASPPMTA02.qualcomm.com [127.0.0.1]) by NALASPPMTA02.qualcomm.com (8.17.1.5/8.17.1.5) with ESMTP id 29UEOO2f025649; Sun, 30 Oct 2022 14:24:24 GMT Received: from pps.reinject (localhost [127.0.0.1]) by NALASPPMTA02.qualcomm.com (PPS) with ESMTPS id 3khdn4hh9h-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 30 Oct 2022 14:24:23 +0000 Received: from NALASPPMTA02.qualcomm.com (NALASPPMTA02.qualcomm.com [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 29UEON25025644; Sun, 30 Oct 2022 14:24:23 GMT Received: from nalasex01b.na.qualcomm.com (nalasex01b.na.qualcomm.com [10.47.209.197]) by NALASPPMTA02.qualcomm.com (PPS) with ESMTPS id 29UEONCA025643 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 30 Oct 2022 14:24:23 +0000 Received: from shazhuss-linux.qualcomm.com (10.80.80.8) by nalasex01b.na.qualcomm.com (10.47.209.197) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.29; Sun, 30 Oct 2022 07:24:20 -0700 From: Shazad Hussain <quic_shazhuss@quicinc.com> To: <andersson@kernel.org> CC: <bmasney@redhat.com>, Shazad Hussain <quic_shazhuss@quicinc.com>, "Andy Gross" <agross@kernel.org>, Konrad Dybcio <konrad.dybcio@somainline.org>, Michael Turquette <mturquette@baylibre.com>, Stephen Boyd <sboyd@kernel.org>, <linux-arm-msm@vger.kernel.org>, <linux-clk@vger.kernel.org>, <linux-kernel@vger.kernel.org> Subject: [PATCH v1] clk: qcom: gcc-sc8280xp: add cxo as parent for gcc_ufs_ref_clkref_clk Date: Sun, 30 Oct 2022 19:53:33 +0530 Message-ID: <20221030142333.31019-1-quic_shazhuss@quicinc.com> X-Mailer: git-send-email 2.38.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanex01b.na.qualcomm.com (10.46.141.250) To nalasex01b.na.qualcomm.com (10.47.209.197) X-QCInternal: smtphost X-QCInternal: smtphost X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=5800 signatures=585085 X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=5800 signatures=585085 X-Proofpoint-ORIG-GUID: -CXHWSQnbCumlR0LcJXgIvhXYt3QXQrr X-Proofpoint-GUID: -CXHWSQnbCumlR0LcJXgIvhXYt3QXQrr X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.895,Hydra:6.0.545,FMLib:17.11.122.1 definitions=2022-10-30_08,2022-10-27_01,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 impostorscore=0 spamscore=0 mlxscore=0 phishscore=0 suspectscore=0 adultscore=0 lowpriorityscore=0 priorityscore=1501 bulkscore=0 malwarescore=0 clxscore=1011 mlxlogscore=760 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2210170000 definitions=main-2210300094 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, 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?1748125261617687219?= X-GMAIL-MSGID: =?utf-8?q?1748125261617687219?= |
Series |
[v1] clk: qcom: gcc-sc8280xp: add cxo as parent for gcc_ufs_ref_clkref_clk
|
|
Commit Message
Shazad Hussain
Oct. 30, 2022, 2:23 p.m. UTC
Since 'commit f3aa975e230e ("arm64: dts: qcom: sc8280xp: correct ref
clock for ufs_mem_phy")' we need to explicitly make cxo as parent to
gcc_ufs_ref_clkref_clk to have an independent vote from ufs_mem_phy.
Signed-off-by: Shazad Hussain <quic_shazhuss@quicinc.com>
---
drivers/clk/qcom/gcc-sc8280xp.c | 2 ++
1 file changed, 2 insertions(+)
Comments
On Sun, Oct 30, 2022 at 07:53:33PM +0530, Shazad Hussain wrote: > Since 'commit f3aa975e230e ("arm64: dts: qcom: sc8280xp: correct ref > clock for ufs_mem_phy")' we need to explicitly make cxo as parent to > gcc_ufs_ref_clkref_clk to have an independent vote from ufs_mem_phy. > > Signed-off-by: Shazad Hussain <quic_shazhuss@quicinc.com> I verified that the QDrive3 still boots normally with this patch. Tested-by: Brian Masney <bmasney@redhat.com>
Quoting Shazad Hussain (2022-10-30 07:23:33) > Since 'commit f3aa975e230e ("arm64: dts: qcom: sc8280xp: correct ref So we should have a Fixes tag for this commit? Or really back to the beginning of the driver? > clock for ufs_mem_phy")' we need to explicitly make cxo as parent to > gcc_ufs_ref_clkref_clk to have an independent vote from ufs_mem_phy. >
On Tue, Nov 01, 2022 at 11:23:59AM -0700, Stephen Boyd wrote: > Quoting Shazad Hussain (2022-10-30 07:23:33) > > Since 'commit f3aa975e230e ("arm64: dts: qcom: sc8280xp: correct ref > > So we should have a Fixes tag for this commit? Or really back to the > beginning of the driver? > > > clock for ufs_mem_phy")' we need to explicitly make cxo as parent to > > gcc_ufs_ref_clkref_clk to have an independent vote from ufs_mem_phy. The commit message is slightly misleading as this affects the other UFS PHY as well. If CX is indeed a parent of this clock then the issue has been there since the clock driver was added. (And otherwise, the PHY binding may need to be amended instead.) Johan
On 11/2/2022 12:46 PM, Johan Hovold wrote: > On Tue, Nov 01, 2022 at 11:23:59AM -0700, Stephen Boyd wrote: >> Quoting Shazad Hussain (2022-10-30 07:23:33) >>> Since 'commit f3aa975e230e ("arm64: dts: qcom: sc8280xp: correct ref >> >> So we should have a Fixes tag for this commit? Or really back to the >> beginning of the driver? >> >>> clock for ufs_mem_phy")' we need to explicitly make cxo as parent to >>> gcc_ufs_ref_clkref_clk to have an independent vote from ufs_mem_phy. > > The commit message is slightly misleading as this affects the other UFS > PHY as well. > > If CX is indeed a parent of this clock then the issue has been there > since the clock driver was added. (And otherwise, the PHY binding may > need to be amended instead.) > > Johan CX is not the actual parent of this clk. GCC_UFS_REF_CLKREF_CLK is an external clk to the device, which needs to be voted. If we use the GCC_UFS_REF_CLKREF_CLK as ref clk, we don't have explicit vote for CX from ufs_mem_phy. If no client votes for CX,(very unlikely) then it's won't be ON for ufs_mem_phy as well right ! So to maintain the voting to CX, we make this as parent to ref clk. Shazad
On Wed, Nov 02, 2022 at 01:28:48PM +0530, Shazad Hussain wrote: > On 11/2/2022 12:46 PM, Johan Hovold wrote: > > On Tue, Nov 01, 2022 at 11:23:59AM -0700, Stephen Boyd wrote: > >> Quoting Shazad Hussain (2022-10-30 07:23:33) > >>> Since 'commit f3aa975e230e ("arm64: dts: qcom: sc8280xp: correct ref > >> > >> So we should have a Fixes tag for this commit? Or really back to the > >> beginning of the driver? > >> > >>> clock for ufs_mem_phy")' we need to explicitly make cxo as parent to > >>> gcc_ufs_ref_clkref_clk to have an independent vote from ufs_mem_phy. > > > > The commit message is slightly misleading as this affects the other UFS > > PHY as well. > > > > If CX is indeed a parent of this clock then the issue has been there > > since the clock driver was added. (And otherwise, the PHY binding may > > need to be amended instead.) > CX is not the actual parent of this clk. GCC_UFS_REF_CLKREF_CLK is an > external clk to the device, which needs to be voted. If we use the > GCC_UFS_REF_CLKREF_CLK as ref clk, we don't have explicit vote for CX > from ufs_mem_phy. > > If no client votes for CX,(very unlikely) then it's won't be ON for > ufs_mem_phy as well right ! So to maintain the voting to CX, we make > this as parent to ref clk. Right, but if the PHYs really requires CX and it is not an ancestor of the refclk then this should be described by the binding (and not be hidden away in the clock driver). Johan
On 11/2/2022 1:43 PM, Johan Hovold wrote: > On Wed, Nov 02, 2022 at 01:28:48PM +0530, Shazad Hussain wrote: >> On 11/2/2022 12:46 PM, Johan Hovold wrote: >>> On Tue, Nov 01, 2022 at 11:23:59AM -0700, Stephen Boyd wrote: >>>> Quoting Shazad Hussain (2022-10-30 07:23:33) >>>>> Since 'commit f3aa975e230e ("arm64: dts: qcom: sc8280xp: correct ref >>>> >>>> So we should have a Fixes tag for this commit? Or really back to the >>>> beginning of the driver? >>>> >>>>> clock for ufs_mem_phy")' we need to explicitly make cxo as parent to >>>>> gcc_ufs_ref_clkref_clk to have an independent vote from ufs_mem_phy. >>> >>> The commit message is slightly misleading as this affects the other UFS >>> PHY as well. >>> >>> If CX is indeed a parent of this clock then the issue has been there >>> since the clock driver was added. (And otherwise, the PHY binding may >>> need to be amended instead.) > >> CX is not the actual parent of this clk. GCC_UFS_REF_CLKREF_CLK is an >> external clk to the device, which needs to be voted. If we use the >> GCC_UFS_REF_CLKREF_CLK as ref clk, we don't have explicit vote for CX >> from ufs_mem_phy. >> >> If no client votes for CX,(very unlikely) then it's won't be ON for >> ufs_mem_phy as well right ! So to maintain the voting to CX, we make >> this as parent to ref clk. > > Right, but if the PHYs really requires CX and it is not an ancestor of > the refclk then this should be described by the binding (and not be > hidden away in the clock driver). > > Johan This makes sense, will be posting v2 post for the same. I assume this should use the Fixes tag then ! Shazad
On Wed, Nov 02, 2022 at 02:15:26PM +0530, Shazad Hussain wrote: > On 11/2/2022 1:43 PM, Johan Hovold wrote: > > Right, but if the PHYs really requires CX and it is not an ancestor of > > the refclk then this should be described by the binding (and not be > > hidden away in the clock driver). > This makes sense, will be posting v2 post for the same. > I assume this should use the Fixes tag then ! Yeah, I guess to you can add a fixes tag for the commits adding support for sc8280xp to the UFS PHY binding and driver. But please do check with the hardware documentation first so we get this right this time. I've already asked Bjorn to see what he can dig out as it is still not clear how the two "card" refclocks (GCC_UFS_CARD_CLKREF_CLK and GCC_UFS_1_CARD_CLKREF_CLK) are supposed to be used. Johan
On Wed, Nov 02, 2022 at 10:26:13AM +0100, Johan Hovold wrote: > On Wed, Nov 02, 2022 at 02:15:26PM +0530, Shazad Hussain wrote: > > On 11/2/2022 1:43 PM, Johan Hovold wrote: > > > > Right, but if the PHYs really requires CX and it is not an ancestor of > > > the refclk then this should be described by the binding (and not be > > > hidden away in the clock driver). > > > This makes sense, will be posting v2 post for the same. > > I assume this should use the Fixes tag then ! > > Yeah, I guess to you can add a fixes tag for the commits adding support > for sc8280xp to the UFS PHY binding and driver. > > But please do check with the hardware documentation first so we get this > right this time. > > I've already asked Bjorn to see what he can dig out as it is still not > clear how the two "card" refclocks (GCC_UFS_CARD_CLKREF_CLK and > GCC_UFS_1_CARD_CLKREF_CLK) are supposed to be used. > We've come full circle and Shazad's patch came from that discussion :) In line with the downstream dts, we have GCC_UFS{,_1}_CARD_CLKREF_CLK providing a reference clock to the two phys. Then GCC_UFS_REF_CLKREF_CLK feeds the UFS refclock pads (both of them), which connect to the memory device(s). In other words, GCC_UFS{,_1}_CARD_CLKREF_CLK should be "ref" in respective phy. GCC_UFS_REF_CLKREF_CLK is the clock to the devices, but as we don't represent the memory device explicitly it seems suitable to use as "ref_clk" in the ufshc nodes - which would then match the special handling of the "link clock" in the UFS driver. All three clocks are sourced off the CXO pad, so I would like this patch to cover at least all of these. And Fixes: d65d005f9a6c ("clk: qcom: add sc8280xp GCC driver") seems to be in order for such patch. @Johan, would you mind writing a dts patch flipping the clocks around and Shazad can update this patch? Regards, Bjorn
On Sun, Oct 30, 2022 at 07:53:33PM +0530, Shazad Hussain wrote: > Since 'commit f3aa975e230e ("arm64: dts: qcom: sc8280xp: correct ref > clock for ufs_mem_phy")' we need to explicitly make cxo as parent to > gcc_ufs_ref_clkref_clk to have an independent vote from ufs_mem_phy. > Prior to that change we relied on both cxo and gcc_ufs_ref_clkref_clk being voted for. So I think the reasoning for this patch should simply be to express the fact that the clkref is fed from CXO. Regards, Bjorn > Signed-off-by: Shazad Hussain <quic_shazhuss@quicinc.com> > --- > drivers/clk/qcom/gcc-sc8280xp.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/clk/qcom/gcc-sc8280xp.c b/drivers/clk/qcom/gcc-sc8280xp.c > index a18ed88f3b82..72b545121c57 100644 > --- a/drivers/clk/qcom/gcc-sc8280xp.c > +++ b/drivers/clk/qcom/gcc-sc8280xp.c > @@ -5848,6 +5848,8 @@ static struct clk_branch gcc_ufs_ref_clkref_clk = { > .enable_mask = BIT(0), > .hw.init = &(const struct clk_init_data) { > .name = "gcc_ufs_ref_clkref_clk", > + .parent_data = &gcc_parent_data_tcxo, > + .num_parents = 1, > .ops = &clk_branch2_ops, > }, > }, > -- > 2.38.0 >
On Wed, Nov 02, 2022 at 09:49:49PM -0500, Bjorn Andersson wrote: > On Wed, Nov 02, 2022 at 10:26:13AM +0100, Johan Hovold wrote: > > On Wed, Nov 02, 2022 at 02:15:26PM +0530, Shazad Hussain wrote: > > > On 11/2/2022 1:43 PM, Johan Hovold wrote: > > > > > > Right, but if the PHYs really requires CX and it is not an ancestor of > > > > the refclk then this should be described by the binding (and not be > > > > hidden away in the clock driver). > > > > > This makes sense, will be posting v2 post for the same. > > > I assume this should use the Fixes tag then ! > > > > Yeah, I guess to you can add a fixes tag for the commits adding support > > for sc8280xp to the UFS PHY binding and driver. > > > > But please do check with the hardware documentation first so we get this > > right this time. > > > > I've already asked Bjorn to see what he can dig out as it is still not > > clear how the two "card" refclocks (GCC_UFS_CARD_CLKREF_CLK and > > GCC_UFS_1_CARD_CLKREF_CLK) are supposed to be used. > > > > We've come full circle and Shazad's patch came from that discussion :) Ah, good. :) > In line with the downstream dts, we have GCC_UFS{,_1}_CARD_CLKREF_CLK > providing a reference clock to the two phys. Then GCC_UFS_REF_CLKREF_CLK > feeds the UFS refclock pads (both of them), which connect to the memory > device(s). > > In other words, GCC_UFS{,_1}_CARD_CLKREF_CLK should be "ref" in > respective phy. > > GCC_UFS_REF_CLKREF_CLK is the clock to the devices, but as we don't > represent the memory device explicitly it seems suitable to use as > "ref_clk" in the ufshc nodes - which would then match the special > handling of the "link clock" in the UFS driver. Thanks for clearing that up. Using GCC_UFS_REF_CLKREF_CLK as ref_clk for the controller sounds reasonable. I guess the only missing piece is which "card" ref clock is used by which PHY. The ADP dts uses: phy ref clock phy@1d87000 (UFS_PHY) GCC_UFS_CARD_CLKREF_CLK phy@1da7000 (UFS_CARD) GCC_UFS_1_CARD_CLKREF_CLK but that is not what the firmware on ADP and CRD seem to enable. Both the ADP and CRD fw leaves GCC_UFS_1_CARD_CLKREF_CLK enabled, while GCC_UFS_CARD_CLKREF_CLK is only enabled on ADP (which unlike the CRD also uses the UFS_CARD controller). Does the ADP dts have these clocks switched or is the firmware confused? (Also note that experiments suggest that neither refclock appears to has to be explicitly enabled for the controllers to function.) > All three clocks are sourced off the CXO pad, so I would like this patch > to cover at least all of these. And > > Fixes: d65d005f9a6c ("clk: qcom: add sc8280xp GCC driver") > > seems to be in order for such patch. > > > @Johan, would you mind writing a dts patch flipping the clocks around > and Shazad can update this patch? I'll do so, but I'll wait with posting until you can confirm which clkref is which. Johan
On Thu, Nov 03, 2022 at 10:06:20AM +0100, Johan Hovold wrote: > On Wed, Nov 02, 2022 at 09:49:49PM -0500, Bjorn Andersson wrote: > > On Wed, Nov 02, 2022 at 10:26:13AM +0100, Johan Hovold wrote: > > > On Wed, Nov 02, 2022 at 02:15:26PM +0530, Shazad Hussain wrote: > > > > On 11/2/2022 1:43 PM, Johan Hovold wrote: > > > > > > > > Right, but if the PHYs really requires CX and it is not an ancestor of > > > > > the refclk then this should be described by the binding (and not be > > > > > hidden away in the clock driver). > > > > > > > This makes sense, will be posting v2 post for the same. > > > > I assume this should use the Fixes tag then ! > > > > > > Yeah, I guess to you can add a fixes tag for the commits adding support > > > for sc8280xp to the UFS PHY binding and driver. > > > > > > But please do check with the hardware documentation first so we get this > > > right this time. > > > > > > I've already asked Bjorn to see what he can dig out as it is still not > > > clear how the two "card" refclocks (GCC_UFS_CARD_CLKREF_CLK and > > > GCC_UFS_1_CARD_CLKREF_CLK) are supposed to be used. > > > > > > > We've come full circle and Shazad's patch came from that discussion :) > > Ah, good. :) > > > In line with the downstream dts, we have GCC_UFS{,_1}_CARD_CLKREF_CLK > > providing a reference clock to the two phys. Then GCC_UFS_REF_CLKREF_CLK > > feeds the UFS refclock pads (both of them), which connect to the memory > > device(s). > > > > In other words, GCC_UFS{,_1}_CARD_CLKREF_CLK should be "ref" in > > respective phy. > > > > GCC_UFS_REF_CLKREF_CLK is the clock to the devices, but as we don't > > represent the memory device explicitly it seems suitable to use as > > "ref_clk" in the ufshc nodes - which would then match the special > > handling of the "link clock" in the UFS driver. > > Thanks for clearing that up. Using GCC_UFS_REF_CLKREF_CLK as ref_clk for > the controller sounds reasonable. > > I guess the only missing piece is which "card" ref clock is used by > which PHY. > > The ADP dts uses: > > phy ref clock > > phy@1d87000 (UFS_PHY) GCC_UFS_CARD_CLKREF_CLK > phy@1da7000 (UFS_CARD) GCC_UFS_1_CARD_CLKREF_CLK > This matches the documentation. Regards, Bjorn > but that is not what the firmware on ADP and CRD seem to enable. > > Both the ADP and CRD fw leaves GCC_UFS_1_CARD_CLKREF_CLK enabled, while > GCC_UFS_CARD_CLKREF_CLK is only enabled on ADP (which unlike the CRD > also uses the UFS_CARD controller). > > Does the ADP dts have these clocks switched or is the firmware confused? > > (Also note that experiments suggest that neither refclock appears to > has to be explicitly enabled for the controllers to function.) > > > All three clocks are sourced off the CXO pad, so I would like this patch > > to cover at least all of these. And > > > > Fixes: d65d005f9a6c ("clk: qcom: add sc8280xp GCC driver") > > > > seems to be in order for such patch. > > > > > > @Johan, would you mind writing a dts patch flipping the clocks around > > and Shazad can update this patch? > > I'll do so, but I'll wait with posting until you can confirm which > clkref is which. > > Johan
On Thu, Nov 03, 2022 at 10:23:55AM -0500, Bjorn Andersson wrote: > On Thu, Nov 03, 2022 at 10:06:20AM +0100, Johan Hovold wrote: > > On Wed, Nov 02, 2022 at 09:49:49PM -0500, Bjorn Andersson wrote: > > > In line with the downstream dts, we have GCC_UFS{,_1}_CARD_CLKREF_CLK > > > providing a reference clock to the two phys. Then GCC_UFS_REF_CLKREF_CLK > > > feeds the UFS refclock pads (both of them), which connect to the memory > > > device(s). > > > > > > In other words, GCC_UFS{,_1}_CARD_CLKREF_CLK should be "ref" in > > > respective phy. > > > > > > GCC_UFS_REF_CLKREF_CLK is the clock to the devices, but as we don't > > > represent the memory device explicitly it seems suitable to use as > > > "ref_clk" in the ufshc nodes - which would then match the special > > > handling of the "link clock" in the UFS driver. > > > > Thanks for clearing that up. Using GCC_UFS_REF_CLKREF_CLK as ref_clk for > > the controller sounds reasonable. > > > > I guess the only missing piece is which "card" ref clock is used by > > which PHY. > > > > The ADP dts uses: > > > > phy ref clock > > > > phy@1d87000 (UFS_PHY) GCC_UFS_CARD_CLKREF_CLK > > phy@1da7000 (UFS_CARD) GCC_UFS_1_CARD_CLKREF_CLK > > > > This matches the documentation. Thanks for checking. > > > All three clocks are sourced off the CXO pad, so I would like this patch > > > to cover at least all of these. And > > > > > > Fixes: d65d005f9a6c ("clk: qcom: add sc8280xp GCC driver") > > > > > > seems to be in order for such patch. > > > > > > > > > @Johan, would you mind writing a dts patch flipping the clocks around > > > and Shazad can update this patch? > > > > I'll do so, but I'll wait with posting until you can confirm which > > clkref is which. I've know posted a patch fixing the devicetree here: https://lore.kernel.org/lkml/20221104092045.17410-1-johan+linaro@kernel.org/ Note that we need to get Shazad's clock driver fix in first as the UFS controller driver expects a valid frequency for the device ref clock. Johan
diff --git a/drivers/clk/qcom/gcc-sc8280xp.c b/drivers/clk/qcom/gcc-sc8280xp.c index a18ed88f3b82..72b545121c57 100644 --- a/drivers/clk/qcom/gcc-sc8280xp.c +++ b/drivers/clk/qcom/gcc-sc8280xp.c @@ -5848,6 +5848,8 @@ static struct clk_branch gcc_ufs_ref_clkref_clk = { .enable_mask = BIT(0), .hw.init = &(const struct clk_init_data) { .name = "gcc_ufs_ref_clkref_clk", + .parent_data = &gcc_parent_data_tcxo, + .num_parents = 1, .ops = &clk_branch2_ops, }, },