* [PATCH 1/2] clk: tegra: Export peripheral reset functions @ 2013-03-28 20:31 Thierry Reding [not found] ` <1364502688-5135-1-git-send-email-thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org> 0 siblings, 1 reply; 13+ messages in thread From: Thierry Reding @ 2013-03-28 20:31 UTC (permalink / raw) To: Mike Turquette; +Cc: Stephen Warren, linux-tegra-u79uwXL29TY76Z2rM5mHXA The tegra_periph_reset_assert() and tegra_periph_reset_deassert() functions can be used by drivers to reset peripherals. In order to allow such drivers to be built as modules, export the functions. Note that this restores the status quo as the functions were exported before the move to the drivers/clk tree. Signed-off-by: Thierry Reding <thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org> --- drivers/clk/tegra/clk-periph.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/clk/tegra/clk-periph.c b/drivers/clk/tegra/clk-periph.c index 788486e..9dbd301 100644 --- a/drivers/clk/tegra/clk-periph.c +++ b/drivers/clk/tegra/clk-periph.c @@ -16,6 +16,7 @@ #include <linux/clk.h> #include <linux/clk-provider.h> +#include <linux/export.h> #include <linux/slab.h> #include <linux/err.h> @@ -128,6 +129,7 @@ void tegra_periph_reset_deassert(struct clk *c) tegra_periph_reset(gate, 0); } +EXPORT_SYMBOL(tegra_periph_reset_deassert); void tegra_periph_reset_assert(struct clk *c) { @@ -147,6 +149,7 @@ void tegra_periph_reset_assert(struct clk *c) tegra_periph_reset(gate, 1); } +EXPORT_SYMBOL(tegra_periph_reset_assert); const struct clk_ops tegra_clk_periph_ops = { .get_parent = clk_periph_get_parent, -- 1.8.1.5 ^ permalink raw reply related [flat|nested] 13+ messages in thread
[parent not found: <1364502688-5135-1-git-send-email-thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org>]
* [PATCH 2/2] clk: tegra: Make gr2d and gr3d clocks children of pll_c [not found] ` <1364502688-5135-1-git-send-email-thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org> @ 2013-03-28 20:31 ` Thierry Reding [not found] ` <1364502688-5135-2-git-send-email-thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org> 2013-03-28 23:23 ` [PATCH 1/2] clk: tegra: Export peripheral reset functions Stephen Warren ` (3 subsequent siblings) 4 siblings, 1 reply; 13+ messages in thread From: Thierry Reding @ 2013-03-28 20:31 UTC (permalink / raw) To: Mike Turquette; +Cc: Stephen Warren, linux-tegra-u79uwXL29TY76Z2rM5mHXA By default these clocks are children of pll_m, but in downstream kernels they are reparented to pll_c. While at it, decrease their frequencies to 300 MHz because the defaults aren't in the specified range. gr2d can reportedly run at much higher frequencies, but 300 MHz works and is a more conservative default. Signed-off-by: Thierry Reding <thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org> --- drivers/clk/tegra/clk-tegra20.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/clk/tegra/clk-tegra20.c b/drivers/clk/tegra/clk-tegra20.c index bf19400..b020beb 100644 --- a/drivers/clk/tegra/clk-tegra20.c +++ b/drivers/clk/tegra/clk-tegra20.c @@ -1247,6 +1247,8 @@ static __initdata struct tegra_clk_init_table init_table[] = { {host1x, pll_c, 150000000, 0}, {disp1, pll_p, 600000000, 0}, {disp2, pll_p, 600000000, 0}, + {gr2d, pll_c, 300000000, 0}, + {gr3d, pll_c, 300000000, 0}, {clk_max, clk_max, 0, 0}, /* This MUST be the last entry */ }; -- 1.8.1.5 ^ permalink raw reply related [flat|nested] 13+ messages in thread
[parent not found: <1364502688-5135-2-git-send-email-thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org>]
* Re: [PATCH 2/2] clk: tegra: Make gr2d and gr3d clocks children of pll_c [not found] ` <1364502688-5135-2-git-send-email-thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org> @ 2013-03-29 21:46 ` Stephen Warren [not found] ` <51560BC4.8020400-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> 2013-04-02 9:33 ` Peter De Schrijver 1 sibling, 1 reply; 13+ messages in thread From: Stephen Warren @ 2013-03-29 21:46 UTC (permalink / raw) To: Thierry Reding Cc: Mike Turquette, linux-tegra-u79uwXL29TY76Z2rM5mHXA, Peter De Schrijver, Prashant Gaikwad, Terje Bergström On 03/28/2013 02:31 PM, Thierry Reding wrote: > By default these clocks are children of pll_m, but in downstream kernels > they are reparented to pll_c. While at it, decrease their frequencies to > 300 MHz because the defaults aren't in the specified range. > > gr2d can reportedly run at much higher frequencies, but 300 MHz works > and is a more conservative default. Questions on this patch: Do we need to do the same thing for Tegra30 and/or Tegra114? Is 300MHz the right value? I'm hoping that Peter, Prashant, and/or Terje can provide guidance here. ^ permalink raw reply [flat|nested] 13+ messages in thread
[parent not found: <51560BC4.8020400-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>]
* Re: [PATCH 2/2] clk: tegra: Make gr2d and gr3d clocks children of pll_c [not found] ` <51560BC4.8020400-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> @ 2013-04-01 6:03 ` Mark Zhang 2013-04-02 5:28 ` Terje Bergström 1 sibling, 0 replies; 13+ messages in thread From: Mark Zhang @ 2013-04-01 6:03 UTC (permalink / raw) To: Stephen Warren Cc: Thierry Reding, Mike Turquette, linux-tegra-u79uwXL29TY76Z2rM5mHXA, Peter De Schrijver, Prashant Gaikwad, Terje Bergström On 03/30/2013 05:46 AM, Stephen Warren wrote: > On 03/28/2013 02:31 PM, Thierry Reding wrote: >> By default these clocks are children of pll_m, but in downstream kernels >> they are reparented to pll_c. While at it, decrease their frequencies to >> 300 MHz because the defaults aren't in the specified range. >> >> gr2d can reportedly run at much higher frequencies, but 300 MHz works >> and is a more conservative default. > > Questions on this patch: > > Do we need to do the same thing for Tegra30 and/or Tegra114? > I think yes. For Tegra114, it's pll_c2. > Is 300MHz the right value? > Right. I use 300MHz on Tegra114 and it seems OK. I recall sometimes 276MHz can be used as well. Mark > I'm hoping that Peter, Prashant, and/or Terje can provide guidance here. > -- > To unsubscribe from this list: send the line "unsubscribe linux-tegra" in > the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 2/2] clk: tegra: Make gr2d and gr3d clocks children of pll_c [not found] ` <51560BC4.8020400-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> 2013-04-01 6:03 ` Mark Zhang @ 2013-04-02 5:28 ` Terje Bergström [not found] ` <515A6C95.4060900-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> 1 sibling, 1 reply; 13+ messages in thread From: Terje Bergström @ 2013-04-02 5:28 UTC (permalink / raw) To: Stephen Warren Cc: Thierry Reding, Mike Turquette, linux-tegra-u79uwXL29TY76Z2rM5mHXA, Peter De Schrijver, Prashant Gaikwad On 29.03.2013 23:46, Stephen Warren wrote: > On 03/28/2013 02:31 PM, Thierry Reding wrote: >> By default these clocks are children of pll_m, but in downstream kernels >> they are reparented to pll_c. While at it, decrease their frequencies to >> 300 MHz because the defaults aren't in the specified range. >> >> gr2d can reportedly run at much higher frequencies, but 300 MHz works >> and is a more conservative default. > > Questions on this patch: > > Do we need to do the same thing for Tegra30 and/or Tegra114? > > Is 300MHz the right value? > > I'm hoping that Peter, Prashant, and/or Terje can provide guidance here. We need a patch for all SoC's. 2D can fail subtly with the too high clocks, even though most of the time it seems to be doing just fine. In Tegra20, 300MHz is the max rate we drive 2D in. Later Tegras have a higher max clock, and in Tegra114 we drive it from a different PLL. But for all of them 300MHz and PLLC should be a working configuration. I haven't checked how we use PLLC in upstream, so I'm not 100% sure. In downstream, the nvhost driver is responsible for setting a sane value to the host1x clients. In upstream host1x, we missed that because we didn't include the clock management code. Terje ^ permalink raw reply [flat|nested] 13+ messages in thread
[parent not found: <515A6C95.4060900-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>]
* Re: [PATCH 2/2] clk: tegra: Make gr2d and gr3d clocks children of pll_c [not found] ` <515A6C95.4060900-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> @ 2013-04-02 5:47 ` Thierry Reding [not found] ` <20130402054722.GA21277-RM9K5IK7kjIQXX3q8xo1gnVAuStQJXxyR5q1nwbD4aMs9pC9oP6+/A@public.gmane.org> 0 siblings, 1 reply; 13+ messages in thread From: Thierry Reding @ 2013-04-02 5:47 UTC (permalink / raw) To: Terje Bergström Cc: Stephen Warren, Mike Turquette, linux-tegra-u79uwXL29TY76Z2rM5mHXA, Peter De Schrijver, Prashant Gaikwad [-- Attachment #1: Type: text/plain, Size: 1776 bytes --] On Tue, Apr 02, 2013 at 08:28:53AM +0300, Terje Bergström wrote: > On 29.03.2013 23:46, Stephen Warren wrote: > > On 03/28/2013 02:31 PM, Thierry Reding wrote: > >> By default these clocks are children of pll_m, but in downstream kernels > >> they are reparented to pll_c. While at it, decrease their frequencies to > >> 300 MHz because the defaults aren't in the specified range. > >> > >> gr2d can reportedly run at much higher frequencies, but 300 MHz works > >> and is a more conservative default. > > > > Questions on this patch: > > > > Do we need to do the same thing for Tegra30 and/or Tegra114? > > > > Is 300MHz the right value? > > > > I'm hoping that Peter, Prashant, and/or Terje can provide guidance here. > > We need a patch for all SoC's. I think we also need that for all host1x children as well. But I think we can tackle those at the same time as driver support is added. Right now only 2D and 3D have some form of user code. > 2D can fail subtly with the too high clocks, even though most of the > time it seems to be doing just fine. > > In Tegra20, 300MHz is the max rate we drive 2D in. Later Tegras have a > higher max clock, and in Tegra114 we drive it from a different PLL. But > for all of them 300MHz and PLLC should be a working configuration. I > haven't checked how we use PLLC in upstream, so I'm not 100% sure. At least on Tegra30 (CardHu) I can see that the clocks are also children of PLLC. I can add a similar hunk for Tegra30 to the patch. I have no Tegra114 hardware available and none of the downstream kernel branches I have seem to include Tegra114 support either so I can't check what's in use there, but if you say it should be fine I can include that in the patch as well. Thierry [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
[parent not found: <20130402054722.GA21277-RM9K5IK7kjIQXX3q8xo1gnVAuStQJXxyR5q1nwbD4aMs9pC9oP6+/A@public.gmane.org>]
* Re: [PATCH 2/2] clk: tegra: Make gr2d and gr3d clocks children of pll_c [not found] ` <20130402054722.GA21277-RM9K5IK7kjIQXX3q8xo1gnVAuStQJXxyR5q1nwbD4aMs9pC9oP6+/A@public.gmane.org> @ 2013-04-02 5:50 ` Terje Bergström 0 siblings, 0 replies; 13+ messages in thread From: Terje Bergström @ 2013-04-02 5:50 UTC (permalink / raw) To: Thierry Reding Cc: Stephen Warren, Mike Turquette, linux-tegra-u79uwXL29TY76Z2rM5mHXA, Peter De Schrijver, Prashant Gaikwad On 02.04.2013 08:47, Thierry Reding wrote: > On Tue, Apr 02, 2013 at 08:28:53AM +0300, Terje Bergström wrote: >> In Tegra20, 300MHz is the max rate we drive 2D in. Later Tegras have a >> higher max clock, and in Tegra114 we drive it from a different PLL. But >> for all of them 300MHz and PLLC should be a working configuration. I >> haven't checked how we use PLLC in upstream, so I'm not 100% sure. > > At least on Tegra30 (CardHu) I can see that the clocks are also children > of PLLC. I can add a similar hunk for Tegra30 to the patch. I have no Yes, Tegra30 is similar to Tegra20 in this respect. Only max clock is different, so similar hunk for Tegra30 would be a good idea. > Tegra114 hardware available and none of the downstream kernel branches I > have seem to include Tegra114 support either so I can't check what's in > use there, but if you say it should be fine I can include that in the > patch as well. I think it's better we add this when we have a patch that enables host1x driver for Tegra114 and we have tested. Until then, I suggest we just leave the Tegra114 part out. Terje ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 2/2] clk: tegra: Make gr2d and gr3d clocks children of pll_c [not found] ` <1364502688-5135-2-git-send-email-thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org> 2013-03-29 21:46 ` Stephen Warren @ 2013-04-02 9:33 ` Peter De Schrijver 1 sibling, 0 replies; 13+ messages in thread From: Peter De Schrijver @ 2013-04-02 9:33 UTC (permalink / raw) To: Thierry Reding Cc: Mike Turquette, Stephen Warren, linux-tegra-u79uwXL29TY76Z2rM5mHXA On Thu, Mar 28, 2013 at 09:31:28PM +0100, Thierry Reding wrote: > By default these clocks are children of pll_m, but in downstream kernels > they are reparented to pll_c. While at it, decrease their frequencies to > 300 MHz because the defaults aren't in the specified range. > > gr2d can reportedly run at much higher frequencies, but 300 MHz works > and is a more conservative default. > > Signed-off-by: Thierry Reding <thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org> > --- > drivers/clk/tegra/clk-tegra20.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/clk/tegra/clk-tegra20.c b/drivers/clk/tegra/clk-tegra20.c > index bf19400..b020beb 100644 > --- a/drivers/clk/tegra/clk-tegra20.c > +++ b/drivers/clk/tegra/clk-tegra20.c > @@ -1247,6 +1247,8 @@ static __initdata struct tegra_clk_init_table init_table[] = { > {host1x, pll_c, 150000000, 0}, > {disp1, pll_p, 600000000, 0}, > {disp2, pll_p, 600000000, 0}, > + {gr2d, pll_c, 300000000, 0}, > + {gr3d, pll_c, 300000000, 0}, > {clk_max, clk_max, 0, 0}, /* This MUST be the last entry */ > }; > In the end we should move to a more flexible scheme where the pll_c frequency is determined by the needs of the various users, but for now this should do I think. Acked-By: Peter De Schrijver <pdeschrijver-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> Cheers, Peter. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 1/2] clk: tegra: Export peripheral reset functions [not found] ` <1364502688-5135-1-git-send-email-thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org> 2013-03-28 20:31 ` [PATCH 2/2] clk: tegra: Make gr2d and gr3d clocks children of pll_c Thierry Reding @ 2013-03-28 23:23 ` Stephen Warren 2013-03-29 15:34 ` Stephen Warren ` (2 subsequent siblings) 4 siblings, 0 replies; 13+ messages in thread From: Stephen Warren @ 2013-03-28 23:23 UTC (permalink / raw) To: Thierry Reding Cc: Mike Turquette, linux-tegra-u79uwXL29TY76Z2rM5mHXA, Peter De Schrijver, Prashant Gaikwad On 03/28/2013 02:31 PM, Thierry Reding wrote: > The tegra_periph_reset_assert() and tegra_periph_reset_deassert() > functions can be used by drivers to reset peripherals. In order to allow > such drivers to be built as modules, export the functions. > > Note that this restores the status quo as the functions were exported > before the move to the drivers/clk tree. Hopefully soon we can replace these with the new module reset API that's being cooked up. But this should do for now. Peter, Prashant, can you please review this series too? ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 1/2] clk: tegra: Export peripheral reset functions [not found] ` <1364502688-5135-1-git-send-email-thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org> 2013-03-28 20:31 ` [PATCH 2/2] clk: tegra: Make gr2d and gr3d clocks children of pll_c Thierry Reding 2013-03-28 23:23 ` [PATCH 1/2] clk: tegra: Export peripheral reset functions Stephen Warren @ 2013-03-29 15:34 ` Stephen Warren 2013-03-29 21:45 ` Stephen Warren 2013-04-02 9:34 ` Peter De Schrijver 4 siblings, 0 replies; 13+ messages in thread From: Stephen Warren @ 2013-03-29 15:34 UTC (permalink / raw) To: Mike Turquette; +Cc: Thierry Reding, linux-tegra-u79uwXL29TY76Z2rM5mHXA On 03/28/2013 02:31 PM, Thierry Reding wrote: > The tegra_periph_reset_assert() and tegra_periph_reset_deassert() > functions can be used by drivers to reset peripherals. In order to allow > such drivers to be built as modules, export the functions. > > Note that this restores the status quo as the functions were exported > before the move to the drivers/clk tree. Mike, Since I'm taking the Tegra CCF changes through the Tegra tree for this kernel cycle, do you want me to wait for your ack on these small fixes, or just go ahead and apply them? Similarly, I assume you want to review/ack the Tegra114 clock driver that Peter posted? If not, do let me know, since I'm currently waiting for that. (Although I know Peter will post a V9 with minor fixes, but 99% of any review should still be applicable) Thanks. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 1/2] clk: tegra: Export peripheral reset functions [not found] ` <1364502688-5135-1-git-send-email-thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org> ` (2 preceding siblings ...) 2013-03-29 15:34 ` Stephen Warren @ 2013-03-29 21:45 ` Stephen Warren 2013-04-02 9:34 ` Peter De Schrijver 4 siblings, 0 replies; 13+ messages in thread From: Stephen Warren @ 2013-03-29 21:45 UTC (permalink / raw) To: Thierry Reding; +Cc: Mike Turquette, linux-tegra-u79uwXL29TY76Z2rM5mHXA On 03/28/2013 02:31 PM, Thierry Reding wrote: > The tegra_periph_reset_assert() and tegra_periph_reset_deassert() > functions can be used by drivers to reset peripherals. In order to allow > such drivers to be built as modules, export the functions. > > Note that this restores the status quo as the functions were exported > before the move to the drivers/clk tree. I have applied this one patch to Tegra's for-3.10/clk branch, with Mike's ack. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 1/2] clk: tegra: Export peripheral reset functions [not found] ` <1364502688-5135-1-git-send-email-thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org> ` (3 preceding siblings ...) 2013-03-29 21:45 ` Stephen Warren @ 2013-04-02 9:34 ` Peter De Schrijver [not found] ` <20130402093426.GZ18519-Rysk9IDjsxmJz7etNGeUX8VPkgjIgRvpAL8bYrjMMd8@public.gmane.org> 4 siblings, 1 reply; 13+ messages in thread From: Peter De Schrijver @ 2013-04-02 9:34 UTC (permalink / raw) To: Thierry Reding Cc: Mike Turquette, Stephen Warren, linux-tegra-u79uwXL29TY76Z2rM5mHXA On Thu, Mar 28, 2013 at 09:31:27PM +0100, Thierry Reding wrote: > The tegra_periph_reset_assert() and tegra_periph_reset_deassert() > functions can be used by drivers to reset peripherals. In order to allow > such drivers to be built as modules, export the functions. > > Note that this restores the status quo as the functions were exported > before the move to the drivers/clk tree. > I guess we should move to the 'reset framework' at some point in the future? Otherwise: Acked-By: Peter De Schrijver <pdeschrijver-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> Cheers, Peter. ^ permalink raw reply [flat|nested] 13+ messages in thread
[parent not found: <20130402093426.GZ18519-Rysk9IDjsxmJz7etNGeUX8VPkgjIgRvpAL8bYrjMMd8@public.gmane.org>]
* Re: [PATCH 1/2] clk: tegra: Export peripheral reset functions [not found] ` <20130402093426.GZ18519-Rysk9IDjsxmJz7etNGeUX8VPkgjIgRvpAL8bYrjMMd8@public.gmane.org> @ 2013-04-02 17:35 ` Mike Turquette 0 siblings, 0 replies; 13+ messages in thread From: Mike Turquette @ 2013-04-02 17:35 UTC (permalink / raw) To: Peter De Schrijver, Thierry Reding Cc: Stephen Warren, linux-tegra-u79uwXL29TY76Z2rM5mHXA Quoting Peter De Schrijver (2013-04-02 02:34:26) > On Thu, Mar 28, 2013 at 09:31:27PM +0100, Thierry Reding wrote: > > The tegra_periph_reset_assert() and tegra_periph_reset_deassert() > > functions can be used by drivers to reset peripherals. In order to allow > > such drivers to be built as modules, export the functions. > > > > Note that this restores the status quo as the functions were exported > > before the move to the drivers/clk tree. > > > > I guess we should move to the 'reset framework' at some point in the future? > Yes please do. Peripheral reset stuff should not lurk in the clock code. I kind of brought this point up back in June of 2012: http://article.gmane.org/gmane.linux.ports.tegra/5346/ Back then the discussion was around removing this export from your clock driver and putting common reset code in clk.h (which is a bad idea). Now that the reset framework exists this stuff really should be migrated out of the clock framework entirely. But as long as this patch is considered an incremental change then it's OK by me. Regards, Mike > Otherwise: > > Acked-By: Peter De Schrijver <pdeschrijver-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> > > > Cheers, > > Peter. ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2013-04-02 17:35 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-03-28 20:31 [PATCH 1/2] clk: tegra: Export peripheral reset functions Thierry Reding [not found] ` <1364502688-5135-1-git-send-email-thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org> 2013-03-28 20:31 ` [PATCH 2/2] clk: tegra: Make gr2d and gr3d clocks children of pll_c Thierry Reding [not found] ` <1364502688-5135-2-git-send-email-thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org> 2013-03-29 21:46 ` Stephen Warren [not found] ` <51560BC4.8020400-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> 2013-04-01 6:03 ` Mark Zhang 2013-04-02 5:28 ` Terje Bergström [not found] ` <515A6C95.4060900-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> 2013-04-02 5:47 ` Thierry Reding [not found] ` <20130402054722.GA21277-RM9K5IK7kjIQXX3q8xo1gnVAuStQJXxyR5q1nwbD4aMs9pC9oP6+/A@public.gmane.org> 2013-04-02 5:50 ` Terje Bergström 2013-04-02 9:33 ` Peter De Schrijver 2013-03-28 23:23 ` [PATCH 1/2] clk: tegra: Export peripheral reset functions Stephen Warren 2013-03-29 15:34 ` Stephen Warren 2013-03-29 21:45 ` Stephen Warren 2013-04-02 9:34 ` Peter De Schrijver [not found] ` <20130402093426.GZ18519-Rysk9IDjsxmJz7etNGeUX8VPkgjIgRvpAL8bYrjMMd8@public.gmane.org> 2013-04-02 17:35 ` Mike Turquette
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.