From: "Sricharan" <sricharan@codeaurora.org> To: 'Stephen Boyd' <sboyd@codeaurora.org> Cc: mturquette@baylibre.com, linux-clk@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org, rnayak@codeaurora.org, stanimir.varbanov@linaro.org Subject: RE: [PATCH 3/3] clk: qcom: Set BRANCH_HALT_DELAY flags for venus core0/1 clks Date: Fri, 4 Nov 2016 14:39:01 +0530 [thread overview] Message-ID: <006701d2367b$19a6ba00$4cf42e00$@codeaurora.org> (raw) In-Reply-To: <20161103203418.GA16026@codeaurora.org> 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
WARNING: multiple messages have this Message-ID (diff)
From: "Sricharan" <sricharan@codeaurora.org> To: "'Stephen Boyd'" <sboyd@codeaurora.org> Cc: <mturquette@baylibre.com>, <linux-clk@vger.kernel.org>, <linux-arm-msm@vger.kernel.org>, <linux-kernel@vger.kernel.org>, <rnayak@codeaurora.org>, <stanimir.varbanov@linaro.org> Subject: RE: [PATCH 3/3] clk: qcom: Set BRANCH_HALT_DELAY flags for venus core0/1 clks Date: Fri, 4 Nov 2016 14:39:01 +0530 [thread overview] Message-ID: <006701d2367b$19a6ba00$4cf42e00$@codeaurora.org> (raw) In-Reply-To: <20161103203418.GA16026@codeaurora.org> 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
next prev parent reply other threads:[~2016-11-04 9:09 UTC|newest] Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-10-24 10:18 [PATCH 0/3] clk: qcom: Add support for hw controlled gdscs/clocks Sricharan R 2016-10-24 10:18 ` [PATCH 1/3] clk: qcom: gdsc: Add support for gdscs with HW control Sricharan R 2016-10-25 13:01 ` Stanimir Varbanov 2016-10-26 4:12 ` Sricharan 2016-10-26 4:12 ` Sricharan 2016-11-02 0:18 ` Stephen Boyd 2016-11-02 6:50 ` Sricharan 2016-11-02 6:50 ` Sricharan 2016-11-02 6:53 ` Sricharan 2016-11-02 6:53 ` Sricharan 2016-11-02 17:59 ` 'Stephen Boyd' 2016-11-03 13:30 ` Sricharan 2016-11-03 13:30 ` Sricharan 2016-11-03 20:05 ` 'Stephen Boyd' 2016-10-24 10:18 ` [PATCH 2/3] clk: qcom: Put venus core0/1 gdscs to hw control mode Sricharan R 2016-10-24 10:18 ` [PATCH 3/3] clk: qcom: Set BRANCH_HALT_DELAY flags for venus core0/1 clks Sricharan R 2016-11-03 20:34 ` Stephen Boyd 2016-11-04 9:09 ` Sricharan [this message] 2016-11-04 9:09 ` Sricharan 2016-11-04 20:18 ` 'Stephen Boyd' 2016-11-07 5:48 ` Rajendra Nayak 2016-11-08 22:33 ` 'Stephen Boyd' 2016-11-09 16:56 ` Sricharan 2016-11-09 16:56 ` Sricharan 2016-11-10 2:32 ` Rajendra Nayak 2016-11-10 3:28 ` Sricharan 2016-11-10 3:28 ` Sricharan 2016-11-10 23:30 ` 'Stephen Boyd' 2016-11-14 3:51 ` Sricharan 2016-11-14 3:51 ` Sricharan 2016-12-12 15:40 ` Stanimir Varbanov
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='006701d2367b$19a6ba00$4cf42e00$@codeaurora.org' \ --to=sricharan@codeaurora.org \ --cc=linux-arm-msm@vger.kernel.org \ --cc=linux-clk@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=mturquette@baylibre.com \ --cc=rnayak@codeaurora.org \ --cc=sboyd@codeaurora.org \ --cc=stanimir.varbanov@linaro.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.