Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <d7207c1c-c4e4-f994-cacb-bdfb7952732b@marek.ca>
References: <20200904030958.13325-1-jonathan@marek.ca> <20200904030958.13325-6-jonathan@marek.ca> <160080040123.310579.8471841951357841843@swboyd.mtv.corp.google.com> <0ce9fdb6-e224-ced7-ec32-fe67b2ca6127@marek.ca> <160090383364.310579.1979253418505275623@swboyd.mtv.corp.google.com> <d7207c1c-c4e4-f994-cacb-bdfb7952732b@marek.ca>
Subject: Re: [PATCH v2 5/5] clk: qcom: add video clock controller driver for SM8250
From:   Stephen Boyd <sboyd@kernel.org>
Cc:     Andy Gross <agross@kernel.org>,
        Bjorn Andersson <bjorn.andersson@linaro.org>,
        Michael Turquette <mturquette@baylibre.com>,
        linux-kernel@vger.kernel.org, linux-clk@vger.kernel.org
To:     Jonathan Marek <jonathan@marek.ca>, linux-arm-msm@vger.kernel.org,
        Taniya Das <tdas@codeaurora.org>
Date:   Wed, 23 Sep 2020 23:17:47 -0700
Message-ID: <160092826778.310579.12225989905897101118@swboyd.mtv.corp.google.com>
User-Agent: alot/0.9.1
Precedence: bulk

Quoting Jonathan Marek (2020-09-23 17:54:59)
> On 9/23/20 7:30 PM, Stephen Boyd wrote:
> > Quoting Jonathan Marek (2020-09-23 09:07:16)
> >> On 9/22/20 2:46 PM, Stephen Boyd wrote:
> >>> Quoting Jonathan Marek (2020-09-03 20:09:54)
> >>>
> >>>> +                       .ops =3D &clk_branch2_ops,
> >>>> +               },
> >>>> +       },
> >>>> +};
> >>>> +
> >>>> +static struct clk_branch video_cc_mvs0_clk =3D {
> >>>> +       .halt_reg =3D 0xd34,
> >>>> +       .halt_check =3D BRANCH_HALT_SKIP, /* TODO: hw gated ? */
> >>>
> >>> Is this resolved?
> >>>
> >>
> >> Downstream has this clock as BRANCH_HALT_VOTED, but with the upstream
> >> venus driver (with patches to enable sm8250), that results in a
> >> "video_cc_mvs0_clk status stuck at 'off" error. AFAIK venus
> >> enables/disables this clock on its own (venus still works without
> >> touching this clock), but I didn't want to remove this in case it might
> >> be needed. I removed these clocks in the v3 I just sent.
> >>
> >=20
> > Hmm. Does downstream use these clks? There have been some clk stuck
> > problems with venus recently that were attributed to improperly enabling
> > clks before enabling interconnects and power domains. Maybe it's the
> > same problem.
> >=20
>=20
> Yes, downstream uses these clks.
>=20
> The "stuck" problem still happens if GSDCS/interconnects are always on,=20
> and like I mentioned, venus works even with these clocks completely=20
> removed.
>=20
> I think venus controls these clocks (and downstream just happens to try=20
> enabling it at a point where venus has already enabled it?). I'm not too =

> sure about this, it might have something to do with the GDSC having the=20
> HW_CTRL flag too..

Ok. Maybe Taniya has an idea.