All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
To: Peter De Schrijver
	<pdeschrijver-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Cc: Prashant Gaikwad
	<pgaikwad-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>,
	Mike Turquette
	<mturquette-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
	Thierry Reding
	<thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
	<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
	"linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [PATCH v2 1/7] clk: tegra: Add support for PLLSS
Date: Wed, 16 Oct 2013 11:21:12 -0600	[thread overview]
Message-ID: <525ECB08.4020201@wwwdotorg.org> (raw)
In-Reply-To: <20131016074829.GD5643-Rysk9IDjsxmJz7etNGeUX8VPkgjIgRvpAL8bYrjMMd8@public.gmane.org>

On 10/16/2013 01:48 AM, Peter De Schrijver wrote:
> On Tue, Oct 15, 2013 at 10:20:03PM +0200, Stephen Warren wrote:
>> On 10/15/2013 09:14 AM, Peter De Schrijver wrote:
>>> Tegra124 introduces a new PLL type, PLLSS. Add support for it.
>>
>>> diff --git a/drivers/clk/tegra/clk-pll.c b/drivers/clk/tegra/clk-pll.c
>>
>>
>>> +static int clk_pllss_set_rate(struct clk_hw *hw, unsigned long rate,
>>> +				unsigned long parent_rate)
>>
>> This function seems pretty generic. Is it possible to share a bit more
>> code with any of the other pllXXX_set_rate() functions?
>>
>>> +struct clk *tegra_clk_register_pllss(const char *name, const char *parent_name,
>>> +				void __iomem *clk_base, unsigned long flags,
>>> +				struct tegra_clk_pll_params *pll_params,
>>> +				spinlock_t *lock)
>>
>>> +	val = pll_readl_base(pll);
>>> +	if (val & PLLSS_REF_SRC_SEL_MASK) {
>>> +		WARN(1, "Unknown parent selected for %s: %d\n", name,
>>> +			(val & PLLSS_REF_SRC_SEL_MASK) >>
>>> +			PLLSS_REF_SRC_SEL_SHIFT);
>>> +		kfree(pll);
>>> +		return ERR_PTR(-EINVAL);
>>> +	}
>>
>> If there's a field in HW that muxes the clock input between n clocks,
>> why does this function assume there's a single parent for this PLL, by
>> taking a "const char *parent_name" parameter?
>>
>> What happens if the bootloader changed this field in HW; is the kernel
>> simply not able to boot?
>>
> 
> This logic comes from downstream. I guess it means we're running in an
> unvalidated configuration. Do you think we should expose all parents 
> anyway? Even if not all configurations have been validated?
> (which is quite likely)

If we only support one particular parent, why not force the register
field to the desired value, rather than failing?

WARNING: multiple messages have this Message-ID (diff)
From: swarren@wwwdotorg.org (Stephen Warren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 1/7] clk: tegra: Add support for PLLSS
Date: Wed, 16 Oct 2013 11:21:12 -0600	[thread overview]
Message-ID: <525ECB08.4020201@wwwdotorg.org> (raw)
In-Reply-To: <20131016074829.GD5643@tbergstrom-lnx.Nvidia.com>

On 10/16/2013 01:48 AM, Peter De Schrijver wrote:
> On Tue, Oct 15, 2013 at 10:20:03PM +0200, Stephen Warren wrote:
>> On 10/15/2013 09:14 AM, Peter De Schrijver wrote:
>>> Tegra124 introduces a new PLL type, PLLSS. Add support for it.
>>
>>> diff --git a/drivers/clk/tegra/clk-pll.c b/drivers/clk/tegra/clk-pll.c
>>
>>
>>> +static int clk_pllss_set_rate(struct clk_hw *hw, unsigned long rate,
>>> +				unsigned long parent_rate)
>>
>> This function seems pretty generic. Is it possible to share a bit more
>> code with any of the other pllXXX_set_rate() functions?
>>
>>> +struct clk *tegra_clk_register_pllss(const char *name, const char *parent_name,
>>> +				void __iomem *clk_base, unsigned long flags,
>>> +				struct tegra_clk_pll_params *pll_params,
>>> +				spinlock_t *lock)
>>
>>> +	val = pll_readl_base(pll);
>>> +	if (val & PLLSS_REF_SRC_SEL_MASK) {
>>> +		WARN(1, "Unknown parent selected for %s: %d\n", name,
>>> +			(val & PLLSS_REF_SRC_SEL_MASK) >>
>>> +			PLLSS_REF_SRC_SEL_SHIFT);
>>> +		kfree(pll);
>>> +		return ERR_PTR(-EINVAL);
>>> +	}
>>
>> If there's a field in HW that muxes the clock input between n clocks,
>> why does this function assume there's a single parent for this PLL, by
>> taking a "const char *parent_name" parameter?
>>
>> What happens if the bootloader changed this field in HW; is the kernel
>> simply not able to boot?
>>
> 
> This logic comes from downstream. I guess it means we're running in an
> unvalidated configuration. Do you think we should expose all parents 
> anyway? Even if not all configurations have been validated?
> (which is quite likely)

If we only support one particular parent, why not force the register
field to the desired value, rather than failing?

WARNING: multiple messages have this Message-ID (diff)
From: Stephen Warren <swarren@wwwdotorg.org>
To: Peter De Schrijver <pdeschrijver@nvidia.com>
Cc: Prashant Gaikwad <pgaikwad@nvidia.com>,
	Mike Turquette <mturquette@linaro.org>,
	Thierry Reding <thierry.reding@gmail.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>
Subject: Re: [PATCH v2 1/7] clk: tegra: Add support for PLLSS
Date: Wed, 16 Oct 2013 11:21:12 -0600	[thread overview]
Message-ID: <525ECB08.4020201@wwwdotorg.org> (raw)
In-Reply-To: <20131016074829.GD5643@tbergstrom-lnx.Nvidia.com>

On 10/16/2013 01:48 AM, Peter De Schrijver wrote:
> On Tue, Oct 15, 2013 at 10:20:03PM +0200, Stephen Warren wrote:
>> On 10/15/2013 09:14 AM, Peter De Schrijver wrote:
>>> Tegra124 introduces a new PLL type, PLLSS. Add support for it.
>>
>>> diff --git a/drivers/clk/tegra/clk-pll.c b/drivers/clk/tegra/clk-pll.c
>>
>>
>>> +static int clk_pllss_set_rate(struct clk_hw *hw, unsigned long rate,
>>> +				unsigned long parent_rate)
>>
>> This function seems pretty generic. Is it possible to share a bit more
>> code with any of the other pllXXX_set_rate() functions?
>>
>>> +struct clk *tegra_clk_register_pllss(const char *name, const char *parent_name,
>>> +				void __iomem *clk_base, unsigned long flags,
>>> +				struct tegra_clk_pll_params *pll_params,
>>> +				spinlock_t *lock)
>>
>>> +	val = pll_readl_base(pll);
>>> +	if (val & PLLSS_REF_SRC_SEL_MASK) {
>>> +		WARN(1, "Unknown parent selected for %s: %d\n", name,
>>> +			(val & PLLSS_REF_SRC_SEL_MASK) >>
>>> +			PLLSS_REF_SRC_SEL_SHIFT);
>>> +		kfree(pll);
>>> +		return ERR_PTR(-EINVAL);
>>> +	}
>>
>> If there's a field in HW that muxes the clock input between n clocks,
>> why does this function assume there's a single parent for this PLL, by
>> taking a "const char *parent_name" parameter?
>>
>> What happens if the bootloader changed this field in HW; is the kernel
>> simply not able to boot?
>>
> 
> This logic comes from downstream. I guess it means we're running in an
> unvalidated configuration. Do you think we should expose all parents 
> anyway? Even if not all configurations have been validated?
> (which is quite likely)

If we only support one particular parent, why not force the register
field to the desired value, rather than failing?

  parent reply	other threads:[~2013-10-16 17:21 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-15 15:14 [PATCH v2 0/7] Tegra124 clock support Peter De Schrijver
2013-10-15 15:14 ` Peter De Schrijver
2013-10-15 15:14 ` Peter De Schrijver
2013-10-15 15:14 ` [PATCH v2 1/7] clk: tegra: Add support for PLLSS Peter De Schrijver
2013-10-15 15:14   ` Peter De Schrijver
2013-10-15 15:14   ` Peter De Schrijver
     [not found]   ` <1381850098-12357-2-git-send-email-pdeschrijver-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-10-15 20:20     ` Stephen Warren
2013-10-15 20:20       ` Stephen Warren
2013-10-15 20:20       ` Stephen Warren
     [not found]       ` <525DA373.6040805-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-10-16  7:48         ` Peter De Schrijver
2013-10-16  7:48           ` Peter De Schrijver
2013-10-16  7:48           ` Peter De Schrijver
     [not found]           ` <20131016074829.GD5643-Rysk9IDjsxmJz7etNGeUX8VPkgjIgRvpAL8bYrjMMd8@public.gmane.org>
2013-10-16 17:21             ` Stephen Warren [this message]
2013-10-16 17:21               ` Stephen Warren
2013-10-16 17:21               ` Stephen Warren
     [not found]               ` <525ECB08.4020201-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-10-17  7:57                 ` Peter De Schrijver
2013-10-17  7:57                   ` Peter De Schrijver
2013-10-17  7:57                   ` Peter De Schrijver
2013-10-15 15:14 ` [PATCH v2 2/7] clk: tegra: Add periph regs bank X Peter De Schrijver
2013-10-15 15:14   ` Peter De Schrijver
2013-10-15 15:14   ` Peter De Schrijver
2013-10-15 15:14 ` [PATCH v2 3/7] clk: tegra124: Add common clk IDs to clk-id.h Peter De Schrijver
2013-10-15 15:14   ` Peter De Schrijver
2013-10-15 15:14   ` Peter De Schrijver
2013-10-15 15:14 ` [PATCH v2 4/7] clk: tegra124: Add new peripheral clocks Peter De Schrijver
2013-10-15 15:14   ` Peter De Schrijver
2013-10-15 15:14   ` Peter De Schrijver
     [not found]   ` <1381850098-12357-5-git-send-email-pdeschrijver-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-10-15 20:21     ` Stephen Warren
2013-10-15 20:21       ` Stephen Warren
2013-10-15 20:21       ` Stephen Warren
2013-10-15 15:14 ` [PATCH v2 5/7] clk: tegra124: Add support for Tegra124 clocks Peter De Schrijver
2013-10-15 15:14   ` Peter De Schrijver
2013-10-15 15:14   ` Peter De Schrijver
     [not found]   ` <1381850098-12357-6-git-send-email-pdeschrijver-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-10-15 20:29     ` Stephen Warren
2013-10-15 20:29       ` Stephen Warren
2013-10-15 20:29       ` Stephen Warren
     [not found]       ` <525DA5C3.5070903-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-10-16 16:13         ` Peter De Schrijver
2013-10-16 16:13           ` Peter De Schrijver
2013-10-16 16:13           ` Peter De Schrijver
2013-10-15 15:14 ` [PATCH v2 7/7] clk: tegra124: add suspend/resume function for tegra_cpu_car_ops Peter De Schrijver
2013-10-15 15:14   ` Peter De Schrijver
2013-10-15 15:14   ` Peter De Schrijver
     [not found] ` <1381850098-12357-1-git-send-email-pdeschrijver-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-10-15 15:14   ` [PATCH v2 6/7] clk: tegra124: add wait_for_reset and disable_clock " Peter De Schrijver
2013-10-15 15:14     ` Peter De Schrijver
2013-10-15 15:14     ` Peter De Schrijver
2013-10-15 18:14   ` [PATCH v2 0/7] Tegra124 clock support Olof Johansson
2013-10-15 18:14 ` Olof Johansson
2013-10-15 18:14   ` Olof Johansson
2013-10-15 20:31 ` Stephen Warren
2013-10-15 20:31   ` Stephen Warren

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=525ECB08.4020201@wwwdotorg.org \
    --to=swarren-3lzwwm7+weoh9zmkesr00q@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=mturquette-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
    --cc=pdeschrijver-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
    --cc=pgaikwad-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
    --cc=thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.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 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.