linux-arm-msm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bjorn Andersson <bjorn.andersson@linaro.org>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Michael Turquette <mturquette@baylibre.com>,
	Stephen Boyd <sboyd@codeaurora.org>,
	linux-clk@vger.kernel.org, linux-arm-msm@vger.kernel.org
Subject: Re: [PATCH 3/5 v2] clk: qcom: Implement RPM clocks for MSM8660/APQ8060
Date: Sat, 27 May 2017 13:00:08 -0700	[thread overview]
Message-ID: <20170527200008.GM12920@tuxbook> (raw)
In-Reply-To: <20170419091326.11226-3-linus.walleij@linaro.org>

On Wed 19 Apr 02:13 PDT 2017, Linus Walleij wrote:

> The RPM clocks were missing for MSM8660/APQ8060. For this to be
> completed we need to add a special fixed rate RPM clock that is used
> for the PLL4 on these SoCs. The rest of the clocks are pretty
> similar to the other supported platforms.
> 
> The "active" clock pattern is mirrored in all the clocks. I guess
> that the PLL4 that clocks the LPASS is actually never used as
> "active only" since the low-power audio subsystem should be left
> on when the system suspends, so it can be used as a stand-alone
> MP3 player type of device.
> 
> As we do not have firmware for the LPASS we will probably only use
> this clock when the system is up and running (not suspended) for now,
> so that will be using the "active" clock.
> 

Note that "active" vs "sleep" is not related to the Linux suspend state,
but rather the CPU idle state; at the bottom of the CPU idle path the
RPM will react and reconfigure resources to their sleep state (if one is
configured) and then reconfigured based on the active state before
returning from the idle.

The PLL4 seems to be enabled only on behalf of the booting LPASS Hexagon
- which will cast its own vote once its booted - and as such we only
configure the active state (meaning both states will have same
configuration).  The result is that PLL4 will be on from prepare() to
unprepare() regardless of what the application CPU does.

> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> ChangeLog v1->v2:
> - Add the small hunk to the clk_rpm_handoff() function that just
>   skip over this for the fixed PLL4 clock. This accidentally
>   ended up in another patch.
> ---
>  drivers/clk/qcom/clk-rpm.c | 106 +++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 106 insertions(+)
> 
> diff --git a/drivers/clk/qcom/clk-rpm.c b/drivers/clk/qcom/clk-rpm.c
> index df3e5fe8442a..61c67e93bea3 100644
> --- a/drivers/clk/qcom/clk-rpm.c
> +++ b/drivers/clk/qcom/clk-rpm.c
> @@ -56,6 +56,30 @@
>  		},							      \
>  	}
>  
> +#define DEFINE_CLK_RPM_FIXED(_platform, _name, _active, r_id, r)	      \

Is there a reason why you don't use DEFINE_CLK_RPM_PXO_BRANCH() for
PLL4?

Looking at the downstream code PLL4 is explicitly handled differently
and is only exposing one state. So if you're seeing issues with reusing
the PXO_BRANCH() I think you should slim this down further and only
register a single clk_rpm from this.

> +	static struct clk_rpm _platform##_##_name = {			      \
> +		.rpm_clk_id = (r_id),					      \
> +		.rate = (r),						      \
> +		.hw.init = &(struct clk_init_data){			      \
> +			.ops = &clk_rpm_fixed_ops,			      \
> +			.name = #_name,					      \
> +			.parent_names = (const char *[]){ "pxo_board" },      \
> +			.num_parents = 1,				      \
> +		},							      \
> +	};								      \
> +	static struct clk_rpm _platform##_##_active = {			      \
> +		.rpm_clk_id = (r_id),					      \
> +		.peer = &_platform##_##_name,				      \
> +		.active_only = true,					      \
> +		.rate = (r),						      \
> +		.hw.init = &(struct clk_init_data){			      \
> +			.ops = &clk_rpm_fixed_ops,			      \
> +			.name = #_active,				      \
> +			.parent_names = (const char *[]){ "pxo_board" },      \
> +			.num_parents = 1,				      \
> +		},							      \
> +	}
> +
[..]
> @@ -348,6 +412,46 @@ static const struct clk_ops clk_rpm_branch_ops = {
>  	.recalc_rate	= clk_rpm_recalc_rate,
>  };
>  
> +/* MSM8660/APQ8060 */
> +DEFINE_CLK_RPM_FIXED(msm8660, pll4_clk, pll4_a_clk, QCOM_RPM_PLL_4, 540672000);

My OCD wants this at the bottom of the list...

> +DEFINE_CLK_RPM(msm8660, afab_clk, afab_a_clk, QCOM_RPM_APPS_FABRIC_CLK);
> +DEFINE_CLK_RPM(msm8660, sfab_clk, sfab_a_clk, QCOM_RPM_SYS_FABRIC_CLK);
> +DEFINE_CLK_RPM(msm8660, mmfab_clk, mmfab_a_clk, QCOM_RPM_MM_FABRIC_CLK);
> +DEFINE_CLK_RPM(msm8660, daytona_clk, daytona_a_clk, QCOM_RPM_DAYTONA_FABRIC_CLK);
> +DEFINE_CLK_RPM(msm8660, sfpb_clk, sfpb_a_clk, QCOM_RPM_SFPB_CLK);
> +DEFINE_CLK_RPM(msm8660, cfpb_clk, cfpb_a_clk, QCOM_RPM_CFPB_CLK);
> +DEFINE_CLK_RPM(msm8660, mmfpb_clk, mmfpb_a_clk, QCOM_RPM_MMFPB_CLK);
> +DEFINE_CLK_RPM(msm8660, smi_clk, smi_a_clk, QCOM_RPM_SMI_CLK);
> +DEFINE_CLK_RPM(msm8660, ebi1_clk, ebi1_a_clk, QCOM_RPM_EBI1_CLK);

Regards,
Bjorn

  reply	other threads:[~2017-05-27 20:00 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-19  9:13 [PATCH 1/5 v2] clk: qcom: Update DT bindings for the MSM8660/APQ8060 RPMCC Linus Walleij
2017-04-19  9:13 ` [PATCH 2/5 v2] clk: qcom: Elaborate on "active" clocks in the RPM clock bindings Linus Walleij
     [not found]   ` <20170419091326.11226-2-linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2017-04-28 13:35     ` Rob Herring
2017-06-01  7:39       ` Stephen Boyd
2017-04-19  9:13 ` [PATCH 3/5 v2] clk: qcom: Implement RPM clocks for MSM8660/APQ8060 Linus Walleij
2017-05-27 20:00   ` Bjorn Andersson [this message]
2017-06-01  8:05     ` Stephen Boyd
2017-10-13 11:50     ` Linus Walleij
2017-06-01  7:58   ` Stephen Boyd
2017-04-19  9:13 ` [PATCH 4/5 v2] clk: qcom: Update DT bindings for MSM8660 LCC Linus Walleij
2017-04-19  9:13 ` [PATCH 5/5 v2] clk: qcom: Add support " Linus Walleij
2017-05-27 20:19   ` Bjorn Andersson
2017-05-29 12:23     ` Linus Walleij
2017-05-30 19:24       ` Bjorn Andersson
2017-06-01  7:33         ` Stephen Boyd
2017-06-01  8:20   ` Stephen Boyd
2017-05-17  7:23 ` [PATCH 1/5 v2] clk: qcom: Update DT bindings for the MSM8660/APQ8060 RPMCC Linus Walleij
     [not found]   ` <CACRpkdbXEFeVkD8rETyrnuoAxUvnFt2BL07UsXuXfSnq3Qdyfw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-05-24  9:16     ` Linus Walleij
     [not found]       ` <CACRpkdYvwwJcxKPtKUyZBLWsmjXji7pHDKNz9NRTETqj2P3drQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-05-26 11:57         ` Peter De Schrijver
2017-06-01  7:38       ` Stephen Boyd
2017-06-09  8:48         ` Linus Walleij
     [not found] ` <20170419091326.11226-1-linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2017-06-01  7:48   ` Stephen Boyd

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=20170527200008.GM12920@tuxbook \
    --to=bjorn.andersson@linaro.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=mturquette@baylibre.com \
    --cc=sboyd@codeaurora.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: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).