Message ID | 20221213-sm6350-cci-v2-2-15c2c14c34bb@fairphone.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 s9csp194736wrn; Fri, 20 Jan 2023 05:22:01 -0800 (PST) X-Google-Smtp-Source: AMrXdXuPw0NKZPcFRsA90FMaHaF631RzxxHPs7OHXK/Oufw8kxndP6vtt8LmiPgWREup08mi339Z X-Received: by 2002:a17:907:8d18:b0:7c0:d6b6:1ee9 with SMTP id tc24-20020a1709078d1800b007c0d6b61ee9mr17093594ejc.11.1674220921434; Fri, 20 Jan 2023 05:22:01 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1674220921; cv=none; d=google.com; s=arc-20160816; b=Xr/UaiOMsdffCaLWGshDzOH5FvXHd7afIFNypUd3RHwNpein5D8S8wYnfL4f24IKx1 5RqXp7P1iE/Rbnyr30cd2dEhc5QmqCr8nCgeap3olfW5N6hdhKevKkTL1c8VIWepAxYf YIMxwDTYnowyN3CquMJggEyJWoGYImn1580n7jG1g4dpII5vXzk00Qk33ZfVkryj6EDQ Lstlobj7ymgvjQRtT0GWpYrzn7JvzBI74KUA6OCfou7StN3cLFGvKYH62VZMA3Xpvgmf rZL+VQ4WbSkW6n1b7R7ugvxfhr8iKkgPF1wveHhjqL6+P3O4VU/Ng+5O2+aUGIm9udvC aP9w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:in-reply-to:references:message-id :content-transfer-encoding:mime-version:subject:date:from :dkim-signature; bh=ySBpf/g54h4mieeOX1iTHn4nbDJmcd4e2yinCvFCp5c=; b=IDbuOemKmqBYFZ5haOlEoDppL7z+HbH952td9nJ9eq8ooVYG569py1JTjopbN4mGA3 gad9ryTRJ1XixTccxCEUp/TjDVB4BXEXVJHymWQJkJoOjXZS2Du42hmKWWK+5dC8oXh/ +AujXfnwIInjrjM9D9PdZVg7w7ll0vgCcymvzCkmmR0s4y+TYxIzzUlFpfbxvHJouDqC nrwqoC3gq2SDE8i2jZPlzfQJIDUxF9rPQ+J/sHCLOeTNLttirm/MTswDvtMu5oM/dnfR utjSL6oVLM+d4/AWah9R2uEV2adNz5DZPFeh9g29uZS8KSi728yB2LCpONYqKTxOhwnO 6zXA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@fairphone.com header.s=fair header.b=LQoXIY51; 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=fairphone.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id g26-20020aa7d1da000000b004764be0b8f8si39852472edp.424.2023.01.20.05.21.37; Fri, 20 Jan 2023 05:22:01 -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=@fairphone.com header.s=fair header.b=LQoXIY51; 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=fairphone.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230105AbjATNSz (ORCPT <rfc822;literming00@gmail.com> + 99 others); Fri, 20 Jan 2023 08:18:55 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36172 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231135AbjATNSf (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 20 Jan 2023 08:18:35 -0500 Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [IPv6:2a00:1450:4864:20::62a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5ECD0C41E6 for <linux-kernel@vger.kernel.org>; Fri, 20 Jan 2023 05:14:54 -0800 (PST) Received: by mail-ej1-x62a.google.com with SMTP id kt14so13893080ejc.3 for <linux-kernel@vger.kernel.org>; Fri, 20 Jan 2023 05:14:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fairphone.com; s=fair; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:from:to:cc:subject:date:message-id :reply-to; bh=ySBpf/g54h4mieeOX1iTHn4nbDJmcd4e2yinCvFCp5c=; b=LQoXIY51ocKZoiJFhh/AKSvIacV/F1db3r+IWRBBO5CRnSUd4/y6t+JPN0hZcOZC4j 5g67O4XNBTR/+4FcVFML8g5LzcxfzWKtB9YbLXV3o/Db+9DuJBVvgDmf6VRweZz9QhDU bV1mIusIhlsezQ+F7aqLrpXr/4I4jyYEmNI8gosKdTeftWaoFn1xi/3E81QKglReGzWm TGMHSuUcV+YZiR5D5WDxbZsbn3viFZ1oQNXG1fdq0+VPKfTaNemr1mbtrXs9xNrEEgw4 7JVC9CibLH/pdTT/Po5D4c3F3Oiyy4xXwS3aNWAxEZNeXLTRFj386RA7xlUos4xg0BOx gGBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ySBpf/g54h4mieeOX1iTHn4nbDJmcd4e2yinCvFCp5c=; b=BZPX3ttCMF9FbAb0OmFpaP+0wQGKD9se+qx9//txfyUTN7NInbiiikf10dPKbPCl/K zJq78TB7JzVcTLbAsm7lxG289qV2WhW3NWVONMAn00RUsLg6hTmvRJnCe5UV3WHd1XaN flITL1UAad5SxxAn5yG1h1l97JXpOsoK7+xj6ikP9UdwrSLjOloKthGiwjR41ji+UAAY wr1XhPGhOFOzQv5RrGENh7L7AfXXjbqi1ziqBz+J9kDRqKwh26efga1BS/WQ4HOt91Yb 3t04wh0WHEmQoITguwC82Ubb4i8rdhtw41QHZ+rxail7C6zYuNHITpSXfXk1ISSuETYd 0WBg== X-Gm-Message-State: AFqh2kqXyo9fX3301HRitqgMTTDJorC/JpoHQQQhlcNQ7Dg1V282gj5A SleVhgU8CNSRh8wfAwqXArTvLg== X-Received: by 2002:a17:906:c7cc:b0:7ae:bfec:74c7 with SMTP id dc12-20020a170906c7cc00b007aebfec74c7mr14237590ejb.72.1674220492599; Fri, 20 Jan 2023 05:14:52 -0800 (PST) Received: from [172.16.220.87] (144-178-202-138.static.ef-service.nl. [144.178.202.138]) by smtp.gmail.com with ESMTPSA id t1-20020a1709061be100b0086f40238403sm8063276ejg.223.2023.01.20.05.14.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 20 Jan 2023 05:14:52 -0800 (PST) From: Luca Weiss <luca.weiss@fairphone.com> Date: Fri, 20 Jan 2023 14:13:45 +0100 Subject: [PATCH v2 2/4] arm64: dts: qcom: sm6350: Add camera clock controller MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20221213-sm6350-cci-v2-2-15c2c14c34bb@fairphone.com> References: <20221213-sm6350-cci-v2-0-15c2c14c34bb@fairphone.com> In-Reply-To: <20221213-sm6350-cci-v2-0-15c2c14c34bb@fairphone.com> To: Andy Gross <agross@kernel.org>, Bjorn Andersson <andersson@kernel.org>, Konrad Dybcio <konrad.dybcio@linaro.org>, Loic Poulain <loic.poulain@linaro.org>, Robert Foss <rfoss@kernel.org>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org> Cc: ~postmarketos/upstreaming@lists.sr.ht, phone-devel@vger.kernel.org, linux-i2c@vger.kernel.org, linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Luca Weiss <luca.weiss@fairphone.com> X-Mailer: b4 0.12-dev-78462 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=unavailable 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?1755547877215749738?= X-GMAIL-MSGID: =?utf-8?q?1755547877215749738?= |
Series |
Add CCI bus support for SM6350
|
|
Commit Message
Luca Weiss
Jan. 20, 2023, 1:13 p.m. UTC
Add a node for the camcc found on SM6350 SoC. Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com> --- arch/arm64/boot/dts/qcom/sm6350.dtsi | 9 +++++++++ 1 file changed, 9 insertions(+)
Comments
On 20/01/2023 13:13, Luca Weiss wrote: > + camcc: clock-controller@ad00000 { > + compatible = "qcom,sm6350-camcc"; > + reg = <0 0x0ad00000 0 0x16000>; > + clocks = <&rpmhcc RPMH_CXO_CLK>; > + #clock-cells = <1>; > + #reset-cells = <1>; > + #power-domain-cells = <1>; > + }; Should you include required-opps = <&rpmhpd_opp_low_svs>; ? --- bod
On Fri Jan 20, 2023 at 5:49 PM CET, Bryan O'Donoghue wrote: > On 20/01/2023 13:13, Luca Weiss wrote: > > + camcc: clock-controller@ad00000 { > > + compatible = "qcom,sm6350-camcc"; > > + reg = <0 0x0ad00000 0 0x16000>; > > + clocks = <&rpmhcc RPMH_CXO_CLK>; > > + #clock-cells = <1>; > > + #reset-cells = <1>; > > + #power-domain-cells = <1>; > > + }; > > Should you include > > required-opps = <&rpmhpd_opp_low_svs>; > > ? I don't know, it works without. But doesn't this property not just affect power-domains? I haven't passed any here. > > --- > bod
On 24/01/2023 14:48, Luca Weiss wrote: > On Fri Jan 20, 2023 at 5:49 PM CET, Bryan O'Donoghue wrote: >> On 20/01/2023 13:13, Luca Weiss wrote: >>> + camcc: clock-controller@ad00000 { >>> + compatible = "qcom,sm6350-camcc"; >>> + reg = <0 0x0ad00000 0 0x16000>; >>> + clocks = <&rpmhcc RPMH_CXO_CLK>; >>> + #clock-cells = <1>; >>> + #reset-cells = <1>; >>> + #power-domain-cells = <1>; >>> + }; >> >> Should you include >> >> required-opps = <&rpmhpd_opp_low_svs>; >> >> ? > > I don't know, it works without. But doesn't this property not just > affect power-domains? I haven't passed any here. > Should you have a TITAN_TOP pd though ? --- bod
On Tue Jan 24, 2023 at 4:25 PM CET, Bryan O'Donoghue wrote: > On 24/01/2023 14:48, Luca Weiss wrote: > > On Fri Jan 20, 2023 at 5:49 PM CET, Bryan O'Donoghue wrote: > >> On 20/01/2023 13:13, Luca Weiss wrote: > >>> + camcc: clock-controller@ad00000 { > >>> + compatible = "qcom,sm6350-camcc"; > >>> + reg = <0 0x0ad00000 0 0x16000>; > >>> + clocks = <&rpmhcc RPMH_CXO_CLK>; > >>> + #clock-cells = <1>; > >>> + #reset-cells = <1>; > >>> + #power-domain-cells = <1>; > >>> + }; > >> > >> Should you include > >> > >> required-opps = <&rpmhpd_opp_low_svs>; > >> > >> ? > > > > I don't know, it works without. But doesn't this property not just > > affect power-domains? I haven't passed any here. > > > > Should you have a TITAN_TOP pd though ? Can I reference <&camcc TITAN_TOP_GDSC> from itself? I know that having it on is required to turn on at least some clocks (maybe all clocks). But from what I understand how power domains are normally handled, the driver core enables them before the driver is probed, so self referencing wouldn't work. And at least no other SoC upstream references TITAN_TOP_GDSC in camcc. Regards Luca > > --- > bod
On 27/01/2023 12:45, Luca Weiss wrote: > Can I reference <&camcc TITAN_TOP_GDSC> from itself? I know that having > it on is required to turn on at least some clocks (maybe all clocks). > But from what I understand how power domains are normally handled, the > driver core enables them before the driver is probed, so self > referencing wouldn't work. > > And at least no other SoC upstream references TITAN_TOP_GDSC in camcc. > > Regards > Luca Doh I meant to say a power-domain to an mmcx a la power-domains = <&rpmhpd SM8250_MMCX>; required-opps = <&rpmhpd_opp_low_svs>; TITAN_TOP should be in your cci and camss dt nodes. --- bod
On Fri Jan 27, 2023 at 1:49 PM CET, Bryan O'Donoghue wrote: > On 27/01/2023 12:45, Luca Weiss wrote: > > Can I reference <&camcc TITAN_TOP_GDSC> from itself? I know that having > > it on is required to turn on at least some clocks (maybe all clocks). > > But from what I understand how power domains are normally handled, the > > driver core enables them before the driver is probed, so self > > referencing wouldn't work. > > > > And at least no other SoC upstream references TITAN_TOP_GDSC in camcc. > > > > Regards > > Luca > > Doh I meant to say a power-domain to an mmcx a la > > power-domains = <&rpmhpd SM8250_MMCX>; > required-opps = <&rpmhpd_opp_low_svs>; > > TITAN_TOP should be in your cci and camss dt nodes. Okay, that makes more sense. What I don't quite understand is why sm8250 only has MMCX listed there since downstream has both vdd_mx-supply = <&VDD_MX_LEVEL> and vdd_mm-supply = <&VDD_MMCX_LEVEL> and both "supplies" are used for different clocks using .vdd_class But back to sm6350, downstream has vdd_mx-supply = <&VDD_MX_LEVEL> and vdd_cx-supply = <&VDD_CX_LEVEL> and like sm8250 uses cx and mx for different clocks. Not sure if I should add both, and I guess mainline also currently doesn't use higher ops for the power domain when higher clock rate is needed, from what I understand? > > --- > bod
On 27.01.2023 14:11, Luca Weiss wrote: > On Fri Jan 27, 2023 at 1:49 PM CET, Bryan O'Donoghue wrote: >> On 27/01/2023 12:45, Luca Weiss wrote: >>> Can I reference <&camcc TITAN_TOP_GDSC> from itself? I know that having >>> it on is required to turn on at least some clocks (maybe all clocks). >>> But from what I understand how power domains are normally handled, the >>> driver core enables them before the driver is probed, so self >>> referencing wouldn't work. >>> >>> And at least no other SoC upstream references TITAN_TOP_GDSC in camcc. >>> >>> Regards >>> Luca >> >> Doh I meant to say a power-domain to an mmcx a la >> >> power-domains = <&rpmhpd SM8250_MMCX>; >> required-opps = <&rpmhpd_opp_low_svs>; >> >> TITAN_TOP should be in your cci and camss dt nodes. > > Okay, that makes more sense. > > What I don't quite understand is why sm8250 only has MMCX listed there > since downstream has both vdd_mx-supply = <&VDD_MX_LEVEL> and > vdd_mm-supply = <&VDD_MMCX_LEVEL> and both "supplies" are used for > different clocks using .vdd_class > > But back to sm6350, downstream has vdd_mx-supply = <&VDD_MX_LEVEL> and > vdd_cx-supply = <&VDD_CX_LEVEL> and like sm8250 uses cx and mx for > different clocks. > Not sure if I should add both, and I guess mainline also currently > doesn't use higher ops for the power domain when higher clock rate is > needed, from what I understand? Basically if you don't need to power any of these power rails to have access to the clock controller, you don't need any of them. What you will need to do however, is make sure that they are scaled with child devices then.. but that's no bueno since they all need TITAN_GDSC. That's why Bryan suggests leaving a vote on a power rail in the clock controller, so that if no other votes are present (as improbable as that may be), you will still be able to get the clocks going. That OTOH will require you to add power management support (PM ops) to the clock controller, as otherwise you can say goodbye to battery life.. Konrad > >> >> --- >> bod >
On 27/01/2023 13:11, Luca Weiss wrote: >> Doh I meant to say a power-domain to an mmcx a la >> >> power-domains = <&rpmhpd SM8250_MMCX>; >> required-opps = <&rpmhpd_opp_low_svs>; >> >> TITAN_TOP should be in your cci and camss dt nodes. > Okay, that makes more sense. > > What I don't quite understand is why sm8250 only has MMCX listed there > since downstream has both vdd_mx-supply = <&VDD_MX_LEVEL> and > vdd_mm-supply = <&VDD_MMCX_LEVEL> and both "supplies" are used for > different clocks using .vdd_class power-domains = <&rpmhpd SM8250_MMCX>; == MMCX_LEVEL required for camcc power-domains = <&camcc TITAN_TOP_GDSC>; required for cci/camss now that you ask the question about MX_LEVEL you're making me doubt we have a 100% complete representation upstream TB perfectly honest, warrants a deep dive.. I just remember that on 8250 we tripped over MMCX not being switched on when - display I think was switched off. --- bod
On 27.01.2023 14:54, Bryan O'Donoghue wrote: > On 27/01/2023 13:11, Luca Weiss wrote: >>> Doh I meant to say a power-domain to an mmcx a la >>> >>> power-domains = <&rpmhpd SM8250_MMCX>; >>> required-opps = <&rpmhpd_opp_low_svs>; >>> >>> TITAN_TOP should be in your cci and camss dt nodes. >> Okay, that makes more sense. >> >> What I don't quite understand is why sm8250 only has MMCX listed there >> since downstream has both vdd_mx-supply = <&VDD_MX_LEVEL> and >> vdd_mm-supply = <&VDD_MMCX_LEVEL> and both "supplies" are used for >> different clocks using .vdd_class > > power-domains = <&rpmhpd SM8250_MMCX>; == MMCX_LEVEL required for camcc > power-domains = <&camcc TITAN_TOP_GDSC>; required for cci/camss > > now that you ask the question about MX_LEVEL you're making me doubt we have a 100% complete representation upstream TB perfectly honest, warrants a deep dive.. > > I just remember that on 8250 we tripped over MMCX not being switched on when - display I think was switched off. There's no MMCX on 6350 and MX is a parent of CX, so if we just stick CX here and add the lowest level to required-opps and add corresponding PM ops to the clk driver, it'll all be taken care of! Konrad > > --- > bod >
diff --git a/arch/arm64/boot/dts/qcom/sm6350.dtsi b/arch/arm64/boot/dts/qcom/sm6350.dtsi index 8224adb99948..300ced5cda57 100644 --- a/arch/arm64/boot/dts/qcom/sm6350.dtsi +++ b/arch/arm64/boot/dts/qcom/sm6350.dtsi @@ -1435,6 +1435,15 @@ usb_1_dwc3: usb@a600000 { }; }; + camcc: clock-controller@ad00000 { + compatible = "qcom,sm6350-camcc"; + reg = <0 0x0ad00000 0 0x16000>; + clocks = <&rpmhcc RPMH_CXO_CLK>; + #clock-cells = <1>; + #reset-cells = <1>; + #power-domain-cells = <1>; + }; + pdc: interrupt-controller@b220000 { compatible = "qcom,sm6350-pdc", "qcom,pdc"; reg = <0 0x0b220000 0 0x30000>, <0 0x17c000f0 0 0x64>;