Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1519443

Re: [PATCH 3/3] clk: qcom: Set BRANCH_HALT_DELAY flags for venus core0/1 clks

From 'Stephen Boyd' <sboyd@codeaurora.org>
Newsgroups linux.kernel
Subject Re: [PATCH 3/3] clk: qcom: Set BRANCH_HALT_DELAY flags for venus core0/1 clks
Date 2016-11-11 00:40 +0100
Message-ID <sC76N-4It-1@gated-at.bofh.it> (permalink)
References (3 earlier) <szIPg-8bj-3@gated-at.bofh.it> <szThD-6we-3@gated-at.bofh.it> <sAKYF-7ax-7@gated-at.bofh.it> <sBndD-7bv-19@gated-at.bofh.it> <sBEo9-1rS-1@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On 11/09, Sricharan wrote:
> 
> So the above is the sequence which is actually carried out on the
> firmware side. The same can be done in host as well.
> The clocks stuck issue indeed is not there with this.

Great! We've finally connected on what the actual problem is.

> But with the above sequence we need to add a step to do inverse
> of STEP3 above (ie write the registers to de-assert hw_signal),
> to keep the subdomains in off, till firmware uses it. So the
> above sequence helps to avoid masking the halt check, although
> the host really does not wants to use these clocks, except
> setting it up for the firmware.
> 

Right, but knowing that the clocks failed to turn on in the first
place is much safer than silently ignoring the failure.
Otherwise, we could hand over control to the firmware, and the
firmware would fail to operate the hardware, and we're stuck with
debugging the firmware now. That sounds quite painful to figure
out.

If we properly toggle the video hw bits in coordination with
firmware and turn on/off the clocks with the GDSC ON, then
debugging is made simpler. The point is, we don't want to lose
robustness by silencing halt checks. The semantics of
clk_enable() means the clock is running, and that won't be true
here unless we ensure the GDSC is enabled.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Back to linux.kernel | Previous | NextPrevious in thread | Find similar | Unroll thread


Thread

Re: [PATCH 3/3] clk: qcom: Set BRANCH_HALT_DELAY flags for venus  core0/1 clks Stephen Boyd <sboyd@codeaurora.org> - 2016-11-03 21:40 +0100
  RE: [PATCH 3/3] clk: qcom: Set BRANCH_HALT_DELAY flags for venus core0/1 clks "Sricharan" <sricharan@codeaurora.org> - 2016-11-04 10:20 +0100
    Re: [PATCH 3/3] clk: qcom: Set BRANCH_HALT_DELAY flags for venus  core0/1 clks 'Stephen Boyd' <sboyd@codeaurora.org> - 2016-11-04 21:30 +0100
      Re: [PATCH 3/3] clk: qcom: Set BRANCH_HALT_DELAY flags for venus  core0/1 clks Rajendra Nayak <rnayak@codeaurora.org> - 2016-11-07 06:50 +0100
        Re: [PATCH 3/3] clk: qcom: Set BRANCH_HALT_DELAY flags for venus  core0/1 clks 'Stephen Boyd' <sboyd@codeaurora.org> - 2016-11-08 23:40 +0100
          RE: [PATCH 3/3] clk: qcom: Set BRANCH_HALT_DELAY flags for venus core0/1 clks "Sricharan" <sricharan@codeaurora.org> - 2016-11-09 18:00 +0100
            Re: [PATCH 3/3] clk: qcom: Set BRANCH_HALT_DELAY flags for venus  core0/1 clks Rajendra Nayak <rnayak@codeaurora.org> - 2016-11-10 03:40 +0100
              RE: [PATCH 3/3] clk: qcom: Set BRANCH_HALT_DELAY flags for venus core0/1 clks "Sricharan" <sricharan@codeaurora.org> - 2016-11-10 04:30 +0100
            Re: [PATCH 3/3] clk: qcom: Set BRANCH_HALT_DELAY flags for venus  core0/1 clks 'Stephen Boyd' <sboyd@codeaurora.org> - 2016-11-11 00:40 +0100

csiph-web