[PATCH 1/2] clk: tegra114: Rename gr_2d/gr_3d to gr2d/gr3d

[PATCH 1/2] clk: tegra114: Rename gr_2d/gr_3d to gr2d/gr3d

[Thierry Reding]

These clocks were named gr2d and gr3d on Tegra20 and Tegra30, so use the
same names on Tegra114 for consistency.

Signed-off-by: Thierry Reding <treding@nvidia.com>
---
 drivers/clk/tegra/clk-tegra114.c         | 6 +++---
 include/dt-bindings/clock/tegra114-car.h | 4 ++--
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/clk/tegra/clk-tegra114.c b/drivers/clk/tegra/clk-tegra114.c
index 1c8701d..ef8e892 100644
--- a/drivers/clk/tegra/clk-tegra114.c
+++ b/drivers/clk/tegra/clk-tegra114.c
@@ -867,7 +867,7 @@ static unsigned long tegra114_input_freq[] = {
 enum tegra114_clk {
 	rtc = 4, timer = 5, uarta = 6, sdmmc2 = 9, i2s1 = 11, i2c1 = 12,
 	ndflash = 13, sdmmc1 = 14, sdmmc4 = 15, pwm = 17, i2s2 = 18, epp = 19,
-	gr_2d = 21, usbd = 22, isp = 23, gr_3d = 24, disp2 = 26, disp1 = 27,
+	gr2d = 21, usbd = 22, isp = 23, gr3d = 24, disp2 = 26, disp1 = 27,
 	host1x = 28, vcp = 29, i2s0 = 30, apbdma = 34, kbc = 36, kfuse = 40,
 	sbc1 = 41, nor = 42, sbc2 = 44, sbc3 = 46, i2c5 = 47, dsia = 48,
 	mipi = 50, hdmi = 51, csi = 52, i2c2 = 54, uartc = 55, mipi_cal = 56,
@@ -1884,8 +1884,8 @@ static struct tegra_periph_init_data tegra_periph_clk_list[] = {
 	TEGRA_INIT_DATA_UART("uartb", NULL, "tegra_uart.1", mux_pllp_pllc_pllm_clkm, CLK_SOURCE_UARTB, 7, &periph_l_regs, uartb),
 	TEGRA_INIT_DATA_UART("uartc", NULL, "tegra_uart.2", mux_pllp_pllc_pllm_clkm, CLK_SOURCE_UARTC, 55, &periph_h_regs, uartc),
 	TEGRA_INIT_DATA_UART("uartd", NULL, "tegra_uart.3", mux_pllp_pllc_pllm_clkm, CLK_SOURCE_UARTD, 65, &periph_u_regs, uartd),
-	TEGRA_INIT_DATA_INT("3d", NULL, "3d", mux_pllm_pllc2_c_c3_pllp_plla, CLK_SOURCE_3D, 24, &periph_l_regs, 0, gr_3d),
-	TEGRA_INIT_DATA_INT("2d", NULL, "2d", mux_pllm_pllc2_c_c3_pllp_plla, CLK_SOURCE_2D, 21, &periph_l_regs, 0, gr_2d),
+	TEGRA_INIT_DATA_INT("3d", NULL, "3d", mux_pllm_pllc2_c_c3_pllp_plla, CLK_SOURCE_3D, 24, &periph_l_regs, 0, gr3d),
+	TEGRA_INIT_DATA_INT("2d", NULL, "2d", mux_pllm_pllc2_c_c3_pllp_plla, CLK_SOURCE_2D, 21, &periph_l_regs, 0, gr2d),
 	TEGRA_INIT_DATA_MUX("vi_sensor", "vi_sensor", "tegra_camera", mux_pllm_pllc2_c_c3_pllp_plla, CLK_SOURCE_VI_SENSOR, 20, &periph_l_regs, TEGRA_PERIPH_NO_RESET, vi_sensor),
 	TEGRA_INIT_DATA_INT8("vi", "vi", "tegra_camera", mux_pllm_pllc2_c_c3_pllp_plla, CLK_SOURCE_VI, 20, &periph_l_regs, 0, vi),
 	TEGRA_INIT_DATA_INT8("epp", NULL, "epp", mux_pllm_pllc2_c_c3_pllp_plla, CLK_SOURCE_EPP, 19, &periph_l_regs, 0, epp),
diff --git a/include/dt-bindings/clock/tegra114-car.h b/include/dt-bindings/clock/tegra114-car.h
index 614aec4..62a39aa 100644
--- a/include/dt-bindings/clock/tegra114-car.h
+++ b/include/dt-bindings/clock/tegra114-car.h
@@ -37,10 +37,10 @@
 #define TEGRA114_CLK_I2S2 18
 #define TEGRA114_CLK_EPP 19
 /* 20 (register bit affects vi and vi_sensor) */
-#define TEGRA114_CLK_GR_2D 21
+#define TEGRA114_CLK_GR2D 21
 #define TEGRA114_CLK_USBD 22
 #define TEGRA114_CLK_ISP 23
-#define TEGRA114_CLK_GR_3D 24
+#define TEGRA114_CLK_GR3D 24
 /* 25 */
 #define TEGRA114_CLK_DISP2 26
 #define TEGRA114_CLK_DISP1 27
-- 
1.8.4

[PATCH 2/2] clk: tegra114: Initialize gr2d clock

[Thierry Reding]

Set up the gr2d clock as a child of PLLC and let it run at 300 MHz by
default.

Signed-off-by: Thierry Reding <treding@nvidia.com>
---
 drivers/clk/tegra/clk-tegra114.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clk/tegra/clk-tegra114.c b/drivers/clk/tegra/clk-tegra114.c
index ef8e892..698a92d 100644
--- a/drivers/clk/tegra/clk-tegra114.c
+++ b/drivers/clk/tegra/clk-tegra114.c
@@ -2226,6 +2226,7 @@ static struct tegra_clk_init_table init_table[] __initdata = {
 	{host1x, pll_c, 150000000, 0},
 	{disp1, pll_p, 600000000, 0},
 	{disp2, pll_p, 600000000, 0},
+	{gr2d, pll_c, 300000000, 0},
 	{clk_max, clk_max, 0, 0}, /* This MUST be the last entry. */
 };
 
-- 
1.8.4

[PATCH 1/2] clk: tegra114: Rename gr_2d/gr_3d to gr2d/gr3d

[Stephen Warren]

On 10/02/2013 03:12 PM, Thierry Reding wrote:
> These clocks were named gr2d and gr3d on Tegra20 and Tegra30, so use the
> same names on Tegra114 for consistency.

The series,
Acked-by: Stephen Warren <swarren@nvidia.com>

Although I wonder if there will be merge conflicts with Peter's "clk:
tegra: replace enum tegra114_clk by binding header"?

[PATCH 1/2] clk: tegra114: Rename gr_2d/gr_3d to gr2d/gr3d

[Mike Turquette]

Quoting Stephen Warren (2013-10-04 10:00:38)
> On 10/02/2013 03:12 PM, Thierry Reding wrote:
> > These clocks were named gr2d and gr3d on Tegra20 and Tegra30, so use the
> > same names on Tegra114 for consistency.
> 
> The series,
> Acked-by: Stephen Warren <swarren@nvidia.com>
> 
> Although I wonder if there will be merge conflicts with Peter's "clk:
> tegra: replace enum tegra114_clk by binding header"?

There are merge conflicts in other places too. The latest clk-next
branch is based on -rc3 with only a few patches (publicly) applied so
far. As of the time of this writing the top-most commit is
96a7ed9079a3483c5681b17f4713c37c1cf2b1c9.

Can the Tegra folks send me a pull request with the following
patches applied? (likely in this order):

ARM: tegra114: add missing clocks to binding
clk: tegra: replace enum tegra114_clk by binding header
[PATCH v2] clk: tegra: Correct sbc mux width & parent
clk: tegra: Fix vde/2d/3d clock src offset
clk: tegra: Set the clock parent of gr2d/gr3d to pll_c2
clk: tegra: Set the clk parent of host1x to pll_p
clk: tegra114: Rename gr_2d/gr_3d to gr2d/gr3d
clk: tegra114: Initialize gr2d clock

The set of patches above (with their functional dependencies) were
giving me some conflict resolution issues (e.g. large data tables that
needed to be updated in clk-tegra-114.c) against the latest clk-next.

Additionally I've looked at the following patches on the list which can
be added to the pull request if you want (these patches all look fine
but I haven't yet Acked each individually):

clk: tegra30: Don't wait for PLL_U lock bit
clk: tegra114: Initialize host1x and related clocks
clk: tegra: PLLE spread spectrum control (with updated changelog)

If there are plans to spin a v3 of "Introduce common infra for tegra
clocks" then basing it on top of this tegra pull request would be nice.

Let me know if this is a problem for you.

Regards,
Mike

[PATCH 1/2] clk: tegra114: Rename gr_2d/gr_3d to gr2d/gr3d

[Peter De Schrijver]

On Mon, Oct 07, 2013 at 02:14:33AM +0200, Mike Turquette wrote:
> Quoting Stephen Warren (2013-10-04 10:00:38)
> > On 10/02/2013 03:12 PM, Thierry Reding wrote:
> > > These clocks were named gr2d and gr3d on Tegra20 and Tegra30, so use the
> > > same names on Tegra114 for consistency.
> > 
> > The series,
> > Acked-by: Stephen Warren <swarren@nvidia.com>
> > 
> > Although I wonder if there will be merge conflicts with Peter's "clk:
> > tegra: replace enum tegra114_clk by binding header"?
> 
> There are merge conflicts in other places too. The latest clk-next
> branch is based on -rc3 with only a few patches (publicly) applied so
> far. As of the time of this writing the top-most commit is
> 96a7ed9079a3483c5681b17f4713c37c1cf2b1c9.
> 
> Can the Tegra folks send me a pull request with the following
> patches applied? (likely in this order):
> 
> ARM: tegra114: add missing clocks to binding
> clk: tegra: replace enum tegra114_clk by binding header
> [PATCH v2] clk: tegra: Correct sbc mux width & parent
> clk: tegra: Fix vde/2d/3d clock src offset
> clk: tegra: Set the clock parent of gr2d/gr3d to pll_c2
> clk: tegra: Set the clk parent of host1x to pll_p
> clk: tegra114: Rename gr_2d/gr_3d to gr2d/gr3d
> clk: tegra114: Initialize gr2d clock

This conflicts with 'clk: tegra: Set the clock parent of gr2d/gr3d to pll_c2'
I suggest we drop 'clk: tegra114: Initialize gr2d clock' and use pll_c2 to clock gr2d.

> The set of patches above (with their functional dependencies) were
> giving me some conflict resolution issues (e.g. large data tables that
> needed to be updated in clk-tegra-114.c) against the latest clk-next.
> 
> Additionally I've looked at the following patches on the list which can
> be added to the pull request if you want (these patches all look fine
> but I haven't yet Acked each individually):
> 
> clk: tegra30: Don't wait for PLL_U lock bit

This is already part of next-20130927.

> clk: tegra114: Initialize host1x and related clocks

This conflicts with 'clk: tegra: Set the clk parent of host1x to pll_p'. I
suggest we drop 'clk: tegra: Set the clk parent of host1x to pll_p' and run
host1x from pll_c. Mark, Thierry, is this ok?

> clk: tegra: PLLE spread spectrum control (with updated changelog)
> 
> If there are plans to spin a v3 of "Introduce common infra for tegra
> clocks" then basing it on top of this tegra pull request would be nice.
> 
> Let me know if this is a problem for you.
> 
> Regards,
> Mike

[PATCH 1/2] clk: tegra114: Rename gr_2d/gr_3d to gr2d/gr3d

[Thierry Reding]

On Mon, Oct 07, 2013 at 05:28:39PM +0300, Peter De Schrijver wrote:
> On Mon, Oct 07, 2013 at 02:14:33AM +0200, Mike Turquette wrote:
> > Quoting Stephen Warren (2013-10-04 10:00:38)
> > > On 10/02/2013 03:12 PM, Thierry Reding wrote:
> > > > These clocks were named gr2d and gr3d on Tegra20 and Tegra30, so use the
> > > > same names on Tegra114 for consistency.
> > > 
> > > The series,
> > > Acked-by: Stephen Warren <swarren@nvidia.com>
> > > 
> > > Although I wonder if there will be merge conflicts with Peter's "clk:
> > > tegra: replace enum tegra114_clk by binding header"?
> > 
> > There are merge conflicts in other places too. The latest clk-next
> > branch is based on -rc3 with only a few patches (publicly) applied so
> > far. As of the time of this writing the top-most commit is
> > 96a7ed9079a3483c5681b17f4713c37c1cf2b1c9.
> > 
> > Can the Tegra folks send me a pull request with the following
> > patches applied? (likely in this order):
> > 
> > ARM: tegra114: add missing clocks to binding
> > clk: tegra: replace enum tegra114_clk by binding header
> > [PATCH v2] clk: tegra: Correct sbc mux width & parent
> > clk: tegra: Fix vde/2d/3d clock src offset
> > clk: tegra: Set the clock parent of gr2d/gr3d to pll_c2
> > clk: tegra: Set the clk parent of host1x to pll_p
> > clk: tegra114: Rename gr_2d/gr_3d to gr2d/gr3d
> > clk: tegra114: Initialize gr2d clock
> 
> This conflicts with 'clk: tegra: Set the clock parent of gr2d/gr3d to pll_c2'
> I suggest we drop 'clk: tegra114: Initialize gr2d clock' and use pll_c2 to clock gr2d.

What's wrong with pll_c? We've used it for Tegra20 and Tegra30 and I
have at least tested that gr2d works properly with it. It will also
cause both host1x and gr2d to run off the same clock, which I guess may
not matter at all.

Furthermore we've usually only added clock initialization when a driver
became available to use it. There is currently no driver for gr3d in the
upstream kernel, so perhaps we should leave the gr3d clock unconfigured
for now?

> > The set of patches above (with their functional dependencies) were
> > giving me some conflict resolution issues (e.g. large data tables that
> > needed to be updated in clk-tegra-114.c) against the latest clk-next.
> > 
> > Additionally I've looked at the following patches on the list which can
> > be added to the pull request if you want (these patches all look fine
> > but I haven't yet Acked each individually):
> > 
> > clk: tegra30: Don't wait for PLL_U lock bit
> 
> This is already part of next-20130927.
> 
> > clk: tegra114: Initialize host1x and related clocks
> 
> This conflicts with 'clk: tegra: Set the clk parent of host1x to pll_p'. I
> suggest we drop 'clk: tegra: Set the clk parent of host1x to pll_p' and run
> host1x from pll_c. Mark, Thierry, is this ok?

Sounds good to me. We use pll_c for host1x on earlier SoC generations as
well.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131007/894433c3/attachment-0001.sig>

[PATCH 1/2] clk: tegra114: Rename gr_2d/gr_3d to gr2d/gr3d

[Peter De Schrijver]

On Mon, Oct 07, 2013 at 04:53:44PM +0200, Thierry Reding wrote:
> * PGP Signed by an unknown key
> 
> On Mon, Oct 07, 2013 at 05:28:39PM +0300, Peter De Schrijver wrote:
> > On Mon, Oct 07, 2013 at 02:14:33AM +0200, Mike Turquette wrote:
> > > Quoting Stephen Warren (2013-10-04 10:00:38)
> > > > On 10/02/2013 03:12 PM, Thierry Reding wrote:
> > > > > These clocks were named gr2d and gr3d on Tegra20 and Tegra30, so use the
> > > > > same names on Tegra114 for consistency.
> > > > 
> > > > The series,
> > > > Acked-by: Stephen Warren <swarren@nvidia.com>
> > > > 
> > > > Although I wonder if there will be merge conflicts with Peter's "clk:
> > > > tegra: replace enum tegra114_clk by binding header"?
> > > 
> > > There are merge conflicts in other places too. The latest clk-next
> > > branch is based on -rc3 with only a few patches (publicly) applied so
> > > far. As of the time of this writing the top-most commit is
> > > 96a7ed9079a3483c5681b17f4713c37c1cf2b1c9.
> > > 
> > > Can the Tegra folks send me a pull request with the following
> > > patches applied? (likely in this order):
> > > 
> > > ARM: tegra114: add missing clocks to binding
> > > clk: tegra: replace enum tegra114_clk by binding header
> > > [PATCH v2] clk: tegra: Correct sbc mux width & parent
> > > clk: tegra: Fix vde/2d/3d clock src offset
> > > clk: tegra: Set the clock parent of gr2d/gr3d to pll_c2
> > > clk: tegra: Set the clk parent of host1x to pll_p
> > > clk: tegra114: Rename gr_2d/gr_3d to gr2d/gr3d
> > > clk: tegra114: Initialize gr2d clock
> > 
> > This conflicts with 'clk: tegra: Set the clock parent of gr2d/gr3d to pll_c2'
> > I suggest we drop 'clk: tegra114: Initialize gr2d clock' and use pll_c2 to clock gr2d.
> 
> What's wrong with pll_c? We've used it for Tegra20 and Tegra30 and I
> have at least tested that gr2d works properly with it. It will also
> cause both host1x and gr2d to run off the same clock, which I guess may
> not matter at all.
> 

Using pll_c2 is consistent with our policy in downstream. It allows more
freedom in scaling gr2d independently from host1x.

> Furthermore we've usually only added clock initialization when a driver
> became available to use it. There is currently no driver for gr3d in the
> upstream kernel, so perhaps we should leave the gr3d clock unconfigured
> for now?
> 

I don't have a strong opinion if we want the gr3d clock in or not. Mark?

> > > The set of patches above (with their functional dependencies) were
> > > giving me some conflict resolution issues (e.g. large data tables that
> > > needed to be updated in clk-tegra-114.c) against the latest clk-next.
> > > 
> > > Additionally I've looked at the following patches on the list which can
> > > be added to the pull request if you want (these patches all look fine
> > > but I haven't yet Acked each individually):
> > > 
> > > clk: tegra30: Don't wait for PLL_U lock bit
> > 
> > This is already part of next-20130927.
> > 
> > > clk: tegra114: Initialize host1x and related clocks
> > 
> > This conflicts with 'clk: tegra: Set the clk parent of host1x to pll_p'. I
> > suggest we drop 'clk: tegra: Set the clk parent of host1x to pll_p' and run
> > host1x from pll_c. Mark, Thierry, is this ok?
> 
> Sounds good to me. We use pll_c for host1x on earlier SoC generations as
> well.

Ok.

Cheers,

Peter.

[PATCH 1/2] clk: tegra114: Rename gr_2d/gr_3d to gr2d/gr3d

[Terje Bergström]

On 08.10.2013 10:53, Peter De Schrijver wrote:
> On Mon, Oct 07, 2013 at 04:53:44PM +0200, Thierry Reding wrote:
>> What's wrong with pll_c? We've used it for Tegra20 and Tegra30 and I
>> have at least tested that gr2d works properly with it. It will also
>> cause both host1x and gr2d to run off the same clock, which I guess may
>> not matter at all.
> Using pll_c2 is consistent with our policy in downstream. It allows more
> freedom in scaling gr2d independently from host1x.

host1x really should be on a clock that is not scaled. This is because
it has some registers that need to be calibrated to the clock rate. It's
a pain to recalibrate whenever clock rate is modified. This is why
host1x is on PLLP downstream.

2D on the other hand (and all clients) is a prime candidate for clock
scaling.

This all is of course just hypothetical as long as we don't really scale
host1x' or its clients' clocks.

Terje