Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1515083
| From | "Sricharan" <sricharan@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-04 10:20 +0100 |
| Message-ID | <szIPg-8bj-3@gated-at.bofh.it> (permalink) |
| References | <svKwh-6el-13@gated-at.bofh.it> <svKwh-6el-11@gated-at.bofh.it> <szwXM-lr-27@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
Hi, > >A better design would be to check if the associated GDSC is in hw >control mode and then skip the checks because the clocks are no >longer under the control of the registers. I presume we only >enable the clocks here to turn on parent clocks which don't turn >on/off automatically, i.e. the PLL. > I was thinking clocks in the powerdomain still needs to be turned on explicitly, these are branch clocks, irrespective of the PLLs. Putting the gdsc in hw_ctrl, only makes the polling on their status invalid. Anyways would be good to be aligned on this. >Given that hw control is a static decision I guess that is an >over-engineered solution though? The problem is that this seems >brittle because we have to keep two things in sync, the branches >and the gdsc. So I guess this is ok, but it deserves a comment >like "GDSC is in HW control" so we know what's going on. Also the >commit text could be more explicit that clocks within the gdsc >power domain don't work when the gdsc is off, and with hw control >of a gdsc we can't tell when the gdsc may be off or on. > ok, i will reword the commit log better as above. So i understand its ok to continue with this way of checking ? since we are always having a static association which never changes, than introducing additional fields in the clk_branch which can get the status of the gdsc. Regards, Sricharan
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll 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