linux-kernel - Re: [PATCH v2 3/3] media: camss: Link CAMSS power domain

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <7bbbf520-d70f-5df6-33ce-a888bf364aa5@linaro.org>
Date:   Fri, 26 May 2023 22:17:06 +0100
From:   Bryan O'Donoghue <bryan.odonoghue@...aro.org>
To:     Konrad Dybcio <konrad.dybcio@...aro.org>,
        Yassine Oudjana <yassine.oudjana@...il.com>,
        Robert Foss <rfoss@...nel.org>,
        Todor Tomov <todor.too@...il.com>,
        Andy Gross <agross@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Hans Verkuil <hansverk@...co.com>
Cc:     Yassine Oudjana <y.oudjana@...tonmail.com>,
        Vladimir Zapolskiy <vladimir.zapolskiy@...aro.org>,
        linux-media@...r.kernel.org, linux-arm-msm@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 3/3] media: camss: Link CAMSS power domain

On 26/05/2023 21:57, Konrad Dybcio wrote:
> This code contains a whole bunch of hacky counting logic that should have
> been substituted with _byname, but now we're stuck with indices to keep
> compatibility with old DTs :/
> 
> If CAMSS_GDSC (talking about pre-TITAN hw) was a parent of all the other
> CAMSS-related GDSCs, we could make it their parent in the clock driver
> and call it a day.

I mean, it wouldn't make much sense from a hw design POV if that weren't 
the case..

Hmm looks like its already there.

static struct gdsc vfe0_gdsc = {
         .gdscr = 0x3664,
         .cxcs = (unsigned int []){ 0x36a8 },
         .cxc_count = 1,
         .pd = {
                 .name = "vfe0",
         },
         .parent = &camss_gdsc.pd,
         .pwrsts = PWRSTS_OFF_ON,
};

static struct gdsc vfe1_gdsc = {
         .gdscr = 0x3674,
         .cxcs = (unsigned int []){ 0x36ac },
         .cxc_count = 1,
         .pd = {
                 .name = "vfe1",
         },
         .parent = &camss_gdsc.pd,
         .pwrsts = PWRSTS_OFF_ON,
};

I feel this is probably a problem in the description of dependencies for 
the CSIPHY in the dts for the 8996..

I.e. the CSIPHY requires some clocks and power-rails to be switched on ah..

static const struct resources csiphy_res_8x96[] = {
         /* CSIPHY0 */
         {
                 .regulators = {},
                 .clock = { "top_ahb", "ispif_ahb", "ahb", 
"csiphy0_timer" },


should probably look something like

static const struct resources csiphy_res_8x96[] = {
         /* CSIPHY0 */
         {
                 .regulators = {},
                 .clock = { "top_ahb", "ispif_ahb", "ahb", 
"csiphy0_timer", "vfe0"},

But basically yeah, we haven't modeled the dependency to the CAMSS_GDSC 
via the VFEx

Hmm wait - why haven't we included the CAMSS_GDSC in the dtsi for the 8996 ?

git diff
diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi 
b/arch/arm64/boot/dts/qcom/msm8996.dtsi
index 30257c07e1279..60e5d3f5336d4 100644
--- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
@@ -2120,7 +2120,8 @@ camss: camss@...000 {
                                 "vfe0",
                                 "vfe1";
                         power-domains = <&mmcc VFE0_GDSC>,
-                                       <&mmcc VFE1_GDSC>;
+                                       <&mmcc VFE1_GDSC>,
+                                       <&mmcc CAMSS_GDSC>;

Either of those approaches should mitigate this patch.

---
bod