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 --]
next prev parent 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: 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.