All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thierry Reding <thierry.reding@gmail.com>
To: Joseph Lo <josephl@nvidia.com>
Cc: devicetree@vger.kernel.org, Stephen Boyd <sboyd@kernel.org>,
	Peter De Schrijver <pdeschrijver@nvidia.com>,
	Jonathan Hunter <jonathanh@nvidia.com>,
	Rob Herring <robh+dt@kernel.org>,
	linux-tegra@vger.kernel.org, linux-clk@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 2/8] clk: tegra: clock changes for emc scaling support on Tegra210
Date: Wed, 3 Apr 2019 11:22:50 +0200	[thread overview]
Message-ID: <20190403092250.GG5238@ulmo> (raw)
In-Reply-To: <20190325074523.26456-3-josephl@nvidia.com>


[-- Attachment #1.1: Type: text/plain, Size: 5248 bytes --]

On Mon, Mar 25, 2019 at 03:45:17PM +0800, Joseph Lo wrote:
> 1) Introduce low jitter paths for pllp and pll_mb used by the EMC driver.
> 2) Remove the old emc_mux clock and don't use the common EMC clock
>    definition. This will be replaced by a new clock defined in the EMC
>    driver.
> 3) Export functions to allow accessing the CAR register required for EMC
>    clock scaling. These functions will be used to access the CAR register
>    as part of the scaling sequence.

The fact that you can enumerate 3 logical changes made by this commit
indicates that it should be split up into smaller patches.

> Based on the work of Peter De Schrijver <pdeschrijver@nvidia.com>.
> 
> Signed-off-by: Joseph Lo <josephl@nvidia.com>
> ---
>  drivers/clk/tegra/clk-tegra210.c         | 112 +++++++++++++++++++----
>  include/dt-bindings/clock/tegra210-car.h |   4 +-
>  include/linux/clk/tegra.h                |   5 +
>  3 files changed, 103 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/clk/tegra/clk-tegra210.c b/drivers/clk/tegra/clk-tegra210.c
> index 7545af763d7a..e17b5279ea69 100644
> --- a/drivers/clk/tegra/clk-tegra210.c
> +++ b/drivers/clk/tegra/clk-tegra210.c
> @@ -47,6 +47,7 @@
>  #define CLK_SOURCE_LA 0x1f8
>  #define CLK_SOURCE_SDMMC2 0x154
>  #define CLK_SOURCE_SDMMC4 0x164
> +#define CLK_SOURCE_EMC_DLL 0x664
>  
>  #define PLLC_BASE 0x80
>  #define PLLC_OUT 0x84
> @@ -234,6 +235,10 @@
>  #define RST_DFLL_DVCO 0x2f4
>  #define DVFS_DFLL_RESET_SHIFT 0
>  
> +#define CLK_RST_CONTROLLER_CLK_OUT_ENB_X_SET	0x284
> +#define CLK_RST_CONTROLLER_CLK_OUT_ENB_X_CLR	0x288
> +#define CLK_OUT_ENB_X_CLK_ENB_EMC_DLL		BIT(14)
> +
>  #define CLK_RST_CONTROLLER_RST_DEV_Y_SET 0x2a8
>  #define CLK_RST_CONTROLLER_RST_DEV_Y_CLR 0x2ac
>  
> @@ -319,12 +324,6 @@ static unsigned long tegra210_input_freq[] = {
>  	[8] = 12000000,
>  };
>  
> -static const char *mux_pllmcp_clkm[] = {
> -	"pll_m", "pll_c", "pll_p", "clk_m", "pll_m_ud", "pll_mb", "pll_mb",
> -	"pll_p",
> -};
> -#define mux_pllmcp_clkm_idx NULL
> -
>  #define PLL_ENABLE			(1 << 30)
>  
>  #define PLLCX_MISC1_IDDQ		(1 << 27)
> @@ -2310,7 +2309,7 @@ static struct tegra_clk tegra210_clks[tegra_clk_max] __initdata = {
>  	[tegra_clk_i2c2] = { .dt_id = TEGRA210_CLK_I2C2, .present = true },
>  	[tegra_clk_uartc_8] = { .dt_id = TEGRA210_CLK_UARTC, .present = true },
>  	[tegra_clk_mipi_cal] = { .dt_id = TEGRA210_CLK_MIPI_CAL, .present = true },
> -	[tegra_clk_emc] = { .dt_id = TEGRA210_CLK_EMC, .present = true },
> +	[tegra_clk_emc] = { .dt_id = TEGRA210_CLK_EMC, .present = false },
>  	[tegra_clk_usb2] = { .dt_id = TEGRA210_CLK_USB2, .present = true },
>  	[tegra_clk_bsev] = { .dt_id = TEGRA210_CLK_BSEV, .present = true },
>  	[tegra_clk_uartd_8] = { .dt_id = TEGRA210_CLK_UARTD, .present = true },
> @@ -2921,6 +2920,82 @@ static int tegra210_init_pllu(void)
>  	return 0;
>  }
>  
> +void tegra210_clk_emc_dll_enable(bool flag)
> +{
> +	unsigned long flags = 0;
> +	u32 offset = flag ? CLK_RST_CONTROLLER_CLK_OUT_ENB_X_SET :
> +		     CLK_RST_CONTROLLER_CLK_OUT_ENB_X_CLR;
> +
> +	spin_lock_irqsave(&emc_lock, flags);
> +
> +	writel_relaxed(CLK_OUT_ENB_X_CLK_ENB_EMC_DLL, clk_base + offset);
> +	readl(clk_base + offset);
> +
> +	spin_unlock_irqrestore(&emc_lock, flags);
> +}
> +EXPORT_SYMBOL_GPL(tegra210_clk_emc_dll_enable);
> +
> +void tegra210_clk_emc_dll_update_setting(u32 emc_dll_src_value)

Do we really want to pass the whole register value through this
function? The register has three fields, so perhaps it's safer to pass
the fields individually? Or perhaps we only need to modify a subset of
the fields and can reduce the number of parameters we pass? Letting a
different driver pass any arbitrary value here takes away any means of
checking for validity.

> +{
> +	unsigned long flags = 0;
> +
> +	spin_lock_irqsave(&emc_lock, flags);
> +
> +	writel_relaxed(emc_dll_src_value, clk_base + CLK_SOURCE_EMC_DLL);
> +	readl(clk_base + CLK_SOURCE_EMC_DLL);

Could we not just use a writel() here and do away with the flushing
readl()?

Also, it doesn't look like that spinlock actually protects anything.
You're just writing a value. If anyone else is holding that lock they
will either overwrite our value after we release the lock, or we
overwrite their value when they release the lock.

> +
> +	spin_unlock_irqrestore(&emc_lock, flags);
> +}
> +EXPORT_SYMBOL_GPL(tegra210_clk_emc_dll_update_setting);
> +
> +void tegra210_clk_emc_update_setting(u32 emc_src_value)
> +{
> +	unsigned long flags = 0;
> +
> +	spin_lock_irqsave(&emc_lock, flags);
> +
> +	writel_relaxed(emc_src_value, clk_base + CLK_SOURCE_EMC);
> +	readl(clk_base + CLK_SOURCE_EMC);
> +
> +	spin_unlock_irqrestore(&emc_lock, flags);
> +}
> +EXPORT_SYMBOL_GPL(tegra210_clk_emc_update_setting);

Same comments as above.

> +
> +u32 tegra210_clk_emc_get_setting(void)
> +{
> +	unsigned long flags = 0;
> +	u32 val;
> +
> +	spin_lock_irqsave(&emc_lock, flags);
> +
> +	val = readl_relaxed(clk_base + CLK_SOURCE_EMC);
> +
> +	spin_unlock_irqrestore(&emc_lock, flags);

Similar to the above, the spinlock doesn't protect anything here.

Thierry

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Thierry Reding <thierry.reding@gmail.com>
To: Joseph Lo <josephl@nvidia.com>
Cc: Peter De Schrijver <pdeschrijver@nvidia.com>,
	Jonathan Hunter <jonathanh@nvidia.com>,
	Rob Herring <robh+dt@kernel.org>, Stephen Boyd <sboyd@kernel.org>,
	linux-arm-kernel@lists.infradead.org,
	linux-tegra@vger.kernel.org, linux-clk@vger.kernel.org,
	devicetree@vger.kernel.org
Subject: Re: [PATCH 2/8] clk: tegra: clock changes for emc scaling support on Tegra210
Date: Wed, 3 Apr 2019 11:22:50 +0200	[thread overview]
Message-ID: <20190403092250.GG5238@ulmo> (raw)
In-Reply-To: <20190325074523.26456-3-josephl@nvidia.com>

[-- Attachment #1: Type: text/plain, Size: 5248 bytes --]

On Mon, Mar 25, 2019 at 03:45:17PM +0800, Joseph Lo wrote:
> 1) Introduce low jitter paths for pllp and pll_mb used by the EMC driver.
> 2) Remove the old emc_mux clock and don't use the common EMC clock
>    definition. This will be replaced by a new clock defined in the EMC
>    driver.
> 3) Export functions to allow accessing the CAR register required for EMC
>    clock scaling. These functions will be used to access the CAR register
>    as part of the scaling sequence.

The fact that you can enumerate 3 logical changes made by this commit
indicates that it should be split up into smaller patches.

> Based on the work of Peter De Schrijver <pdeschrijver@nvidia.com>.
> 
> Signed-off-by: Joseph Lo <josephl@nvidia.com>
> ---
>  drivers/clk/tegra/clk-tegra210.c         | 112 +++++++++++++++++++----
>  include/dt-bindings/clock/tegra210-car.h |   4 +-
>  include/linux/clk/tegra.h                |   5 +
>  3 files changed, 103 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/clk/tegra/clk-tegra210.c b/drivers/clk/tegra/clk-tegra210.c
> index 7545af763d7a..e17b5279ea69 100644
> --- a/drivers/clk/tegra/clk-tegra210.c
> +++ b/drivers/clk/tegra/clk-tegra210.c
> @@ -47,6 +47,7 @@
>  #define CLK_SOURCE_LA 0x1f8
>  #define CLK_SOURCE_SDMMC2 0x154
>  #define CLK_SOURCE_SDMMC4 0x164
> +#define CLK_SOURCE_EMC_DLL 0x664
>  
>  #define PLLC_BASE 0x80
>  #define PLLC_OUT 0x84
> @@ -234,6 +235,10 @@
>  #define RST_DFLL_DVCO 0x2f4
>  #define DVFS_DFLL_RESET_SHIFT 0
>  
> +#define CLK_RST_CONTROLLER_CLK_OUT_ENB_X_SET	0x284
> +#define CLK_RST_CONTROLLER_CLK_OUT_ENB_X_CLR	0x288
> +#define CLK_OUT_ENB_X_CLK_ENB_EMC_DLL		BIT(14)
> +
>  #define CLK_RST_CONTROLLER_RST_DEV_Y_SET 0x2a8
>  #define CLK_RST_CONTROLLER_RST_DEV_Y_CLR 0x2ac
>  
> @@ -319,12 +324,6 @@ static unsigned long tegra210_input_freq[] = {
>  	[8] = 12000000,
>  };
>  
> -static const char *mux_pllmcp_clkm[] = {
> -	"pll_m", "pll_c", "pll_p", "clk_m", "pll_m_ud", "pll_mb", "pll_mb",
> -	"pll_p",
> -};
> -#define mux_pllmcp_clkm_idx NULL
> -
>  #define PLL_ENABLE			(1 << 30)
>  
>  #define PLLCX_MISC1_IDDQ		(1 << 27)
> @@ -2310,7 +2309,7 @@ static struct tegra_clk tegra210_clks[tegra_clk_max] __initdata = {
>  	[tegra_clk_i2c2] = { .dt_id = TEGRA210_CLK_I2C2, .present = true },
>  	[tegra_clk_uartc_8] = { .dt_id = TEGRA210_CLK_UARTC, .present = true },
>  	[tegra_clk_mipi_cal] = { .dt_id = TEGRA210_CLK_MIPI_CAL, .present = true },
> -	[tegra_clk_emc] = { .dt_id = TEGRA210_CLK_EMC, .present = true },
> +	[tegra_clk_emc] = { .dt_id = TEGRA210_CLK_EMC, .present = false },
>  	[tegra_clk_usb2] = { .dt_id = TEGRA210_CLK_USB2, .present = true },
>  	[tegra_clk_bsev] = { .dt_id = TEGRA210_CLK_BSEV, .present = true },
>  	[tegra_clk_uartd_8] = { .dt_id = TEGRA210_CLK_UARTD, .present = true },
> @@ -2921,6 +2920,82 @@ static int tegra210_init_pllu(void)
>  	return 0;
>  }
>  
> +void tegra210_clk_emc_dll_enable(bool flag)
> +{
> +	unsigned long flags = 0;
> +	u32 offset = flag ? CLK_RST_CONTROLLER_CLK_OUT_ENB_X_SET :
> +		     CLK_RST_CONTROLLER_CLK_OUT_ENB_X_CLR;
> +
> +	spin_lock_irqsave(&emc_lock, flags);
> +
> +	writel_relaxed(CLK_OUT_ENB_X_CLK_ENB_EMC_DLL, clk_base + offset);
> +	readl(clk_base + offset);
> +
> +	spin_unlock_irqrestore(&emc_lock, flags);
> +}
> +EXPORT_SYMBOL_GPL(tegra210_clk_emc_dll_enable);
> +
> +void tegra210_clk_emc_dll_update_setting(u32 emc_dll_src_value)

Do we really want to pass the whole register value through this
function? The register has three fields, so perhaps it's safer to pass
the fields individually? Or perhaps we only need to modify a subset of
the fields and can reduce the number of parameters we pass? Letting a
different driver pass any arbitrary value here takes away any means of
checking for validity.

> +{
> +	unsigned long flags = 0;
> +
> +	spin_lock_irqsave(&emc_lock, flags);
> +
> +	writel_relaxed(emc_dll_src_value, clk_base + CLK_SOURCE_EMC_DLL);
> +	readl(clk_base + CLK_SOURCE_EMC_DLL);

Could we not just use a writel() here and do away with the flushing
readl()?

Also, it doesn't look like that spinlock actually protects anything.
You're just writing a value. If anyone else is holding that lock they
will either overwrite our value after we release the lock, or we
overwrite their value when they release the lock.

> +
> +	spin_unlock_irqrestore(&emc_lock, flags);
> +}
> +EXPORT_SYMBOL_GPL(tegra210_clk_emc_dll_update_setting);
> +
> +void tegra210_clk_emc_update_setting(u32 emc_src_value)
> +{
> +	unsigned long flags = 0;
> +
> +	spin_lock_irqsave(&emc_lock, flags);
> +
> +	writel_relaxed(emc_src_value, clk_base + CLK_SOURCE_EMC);
> +	readl(clk_base + CLK_SOURCE_EMC);
> +
> +	spin_unlock_irqrestore(&emc_lock, flags);
> +}
> +EXPORT_SYMBOL_GPL(tegra210_clk_emc_update_setting);

Same comments as above.

> +
> +u32 tegra210_clk_emc_get_setting(void)
> +{
> +	unsigned long flags = 0;
> +	u32 val;
> +
> +	spin_lock_irqsave(&emc_lock, flags);
> +
> +	val = readl_relaxed(clk_base + CLK_SOURCE_EMC);
> +
> +	spin_unlock_irqrestore(&emc_lock, flags);

Similar to the above, the spinlock doesn't protect anything here.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2019-04-03  9:22 UTC|newest]

Thread overview: 73+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-25  7:45 [PATCH 0/8] Add EMC scaling support for Tegra210 Joseph Lo
2019-03-25  7:45 ` Joseph Lo
2019-03-25  7:45 ` Joseph Lo
2019-03-25  7:45 ` [PATCH 1/8] dt-bindings: memory: tegra: Add Tegra210 EMC bindings Joseph Lo
2019-03-25  7:45   ` Joseph Lo
2019-03-25  7:45   ` Joseph Lo
2019-03-31  6:41   ` Rob Herring
2019-03-31  6:41     ` Rob Herring
2019-03-31  6:41     ` Rob Herring
2019-04-01  7:57     ` Joseph Lo
2019-04-01  7:57       ` Joseph Lo
2019-04-01  7:57       ` Joseph Lo
2019-04-03  4:26       ` Rob Herring
2019-04-03  4:26         ` Rob Herring
2019-04-03  4:26         ` Rob Herring
2019-04-10  2:41         ` Joseph Lo
2019-04-10  2:41           ` Joseph Lo
2019-04-10  2:41           ` Joseph Lo
2019-04-01 12:12   ` Dmitry Osipenko
2019-04-01 12:12     ` Dmitry Osipenko
2019-04-02  2:26     ` Joseph Lo
2019-04-02  2:26       ` Joseph Lo
2019-04-02 10:21       ` Dmitry Osipenko
2019-04-02 10:21         ` Dmitry Osipenko
2019-04-04  9:17   ` Dmitry Osipenko
2019-04-04  9:17     ` Dmitry Osipenko
2019-04-04  9:30     ` Dmitry Osipenko
2019-04-04  9:30       ` Dmitry Osipenko
2019-04-08  8:49     ` Joseph Lo
2019-04-08  8:49       ` Joseph Lo
2019-03-25  7:45 ` [PATCH 2/8] clk: tegra: clock changes for emc scaling support on Tegra210 Joseph Lo
2019-03-25  7:45   ` Joseph Lo
2019-03-25  7:45   ` Joseph Lo
2019-04-03  9:22   ` Thierry Reding [this message]
2019-04-03  9:22     ` Thierry Reding
2019-04-08  7:52     ` Joseph Lo
2019-04-08  7:52       ` Joseph Lo
2019-04-08  7:52       ` Joseph Lo
2019-04-08  9:15     ` Peter De Schrijver
2019-04-08  9:15       ` Peter De Schrijver
2019-04-08  9:15       ` Peter De Schrijver
2019-03-25  7:45 ` [PATCH 3/8] memory: tegra: Add Tegra210 EMC clock driver Joseph Lo
2019-03-25  7:45   ` Joseph Lo
2019-03-25  7:45   ` Joseph Lo
2019-04-03 11:34   ` Thierry Reding
2019-04-03 11:34     ` Thierry Reding
2019-04-08  9:25     ` Peter De Schrijver
2019-04-08  9:25       ` Peter De Schrijver
2019-04-08  9:25       ` Peter De Schrijver
2019-04-03 11:55   ` Dmitry Osipenko
2019-04-03 11:55     ` Dmitry Osipenko
2019-03-25  7:45 ` [PATCH 4/8] memory: tegra: add EMC scaling support code for Tegra210 Joseph Lo
2019-03-25  7:45   ` Joseph Lo
2019-03-25  7:45   ` Joseph Lo
2019-04-02 11:39   ` Dmitry Osipenko
2019-04-02 11:39     ` Dmitry Osipenko
2019-04-02 14:53     ` Joseph Lo
2019-04-02 14:53       ` Joseph Lo
2019-03-25  7:45 ` [PATCH 5/8] memory: tegra: Add EMC scaling sequence " Joseph Lo
2019-03-25  7:45   ` Joseph Lo
2019-03-25  7:45   ` Joseph Lo
2019-04-02 11:36   ` Dmitry Osipenko
2019-04-02 11:36     ` Dmitry Osipenko
2019-04-02 14:49     ` Joseph Lo
2019-04-02 14:49       ` Joseph Lo
2019-03-25  7:45 ` [PATCH 6/8] arm64: tegra: Add external memory controller node " Joseph Lo
2019-03-25  7:45   ` Joseph Lo
2019-03-25  7:45   ` Joseph Lo
2019-03-25  7:45 ` [PATCH 7/8] arm64: tegra: Add EMC table of ram code 0 for Tegra210 Shield platform Joseph Lo
2019-03-25  7:45 ` [PATCH 8/8] arm64: tegra: Add EMC table of ram code 1 " Joseph Lo
2019-03-29 14:41 ` [PATCH 0/8] Add EMC scaling support for Tegra210 Peter De Schrijver
2019-03-29 14:41   ` Peter De Schrijver
2019-03-29 14:41   ` Peter De Schrijver

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=20190403092250.GG5238@ulmo \
    --to=thierry.reding@gmail.com \
    --cc=devicetree@vger.kernel.org \
    --cc=jonathanh@nvidia.com \
    --cc=josephl@nvidia.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=pdeschrijver@nvidia.com \
    --cc=robh+dt@kernel.org \
    --cc=sboyd@kernel.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.