| Message ID | 1363274825-2439-1-git-send-email-thierry.reding@avionic-design.de |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
On Thu, Mar 14, 2013 at 04:27:05PM +0100, Thierry Reding wrote: > Under some circumstances the PLLE needs to be retrained, in which case > access to the PMC registers is required. Fix this by passing a pointer > to the PMC registers instead of NULL when registering the PLLE clock. > > Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de> Acked-By: Peter De Schrijver <pdeschrijver@nvidia.com> > --- > drivers/clk/tegra/clk-tegra20.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/clk/tegra/clk-tegra20.c b/drivers/clk/tegra/clk-tegra20.c > index b92d48b..bf19400 100644 > --- a/drivers/clk/tegra/clk-tegra20.c > +++ b/drivers/clk/tegra/clk-tegra20.c > @@ -703,7 +703,7 @@ static void tegra20_pll_init(void) > clks[pll_a_out0] = clk; > > /* PLLE */ > - clk = tegra_clk_register_plle("pll_e", "pll_ref", clk_base, NULL, > + clk = tegra_clk_register_plle("pll_e", "pll_ref", clk_base, pmc_base, > 0, 100000000, &pll_e_params, > 0, pll_e_freq_table, NULL); > clk_register_clkdev(clk, "pll_e", NULL); Cheers, Peter. -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 03/14/2013 09:27 AM, Thierry Reding wrote: > Under some circumstances the PLLE needs to be retrained, in which case > access to the PMC registers is required. Fix this by passing a pointer > to the PMC registers instead of NULL when registering the PLLE clock. Mike, I believe this patch is appropriate as a fix for v3.9. I assume you'll take it through the clock tree? Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoting Stephen Warren (2013-03-15 12:28:21) > On 03/14/2013 09:27 AM, Thierry Reding wrote: > > Under some circumstances the PLLE needs to be retrained, in which case > > access to the PMC registers is required. Fix this by passing a pointer > > to the PMC registers instead of NULL when registering the PLLE clock. > > Mike, I believe this patch is appropriate as a fix for v3.9. I assume > you'll take it through the clock tree? Thanks. Does this patch fix a crash or a documented failure? Linus is being more strict about taking fixes in the -rc cycles these days and knowing exactly what behavior this fixes would be beneficial. Thanks, Mike -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Mar 22, 2013 at 01:48:22PM -0700, Mike Turquette wrote: > Quoting Stephen Warren (2013-03-15 12:28:21) > > On 03/14/2013 09:27 AM, Thierry Reding wrote: > > > Under some circumstances the PLLE needs to be retrained, in which case > > > access to the PMC registers is required. Fix this by passing a pointer > > > to the PMC registers instead of NULL when registering the PLLE clock. > > > > Mike, I believe this patch is appropriate as a fix for v3.9. I assume > > you'll take it through the clock tree? Thanks. > > Does this patch fix a crash or a documented failure? Linus is being > more strict about taking fixes in the -rc cycles these days and knowing > exactly what behavior this fixes would be beneficial. This fixes a failure where the clock can't be retrained. Under some circumstances the timing is such that retraining isn't required, in which case the code runs normally. However I've seen in happen that the PLL isn't stable in other cases, so the code tries to retrain. But the current code doesn't allow retraining to happen because the MC registers aren't accessible for the PLLE and therefore the clk_plle_training() function immediately errors out with -ENOSYS. Comparing to Tegra30 this is obviously just a typo when registering the PLLE clock and the virtual address to the PMC registers can be passed in at PLLE registration time to resolve this issue. Thierry
On Mon, Mar 25, 2013 at 02:13:04PM -0700, Mike Turquette wrote: > Quoting Thierry Reding (2013-03-25 11:53:21) > > On Fri, Mar 22, 2013 at 01:48:22PM -0700, Mike Turquette wrote: > > > Quoting Stephen Warren (2013-03-15 12:28:21) > > > > On 03/14/2013 09:27 AM, Thierry Reding wrote: > > > > > Under some circumstances the PLLE needs to be retrained, in which case > > > > > access to the PMC registers is required. Fix this by passing a pointer > > > > > to the PMC registers instead of NULL when registering the PLLE clock. > > > > > > > > Mike, I believe this patch is appropriate as a fix for v3.9. I assume > > > > you'll take it through the clock tree? Thanks. > > > > > > Does this patch fix a crash or a documented failure? Linus is being > > > more strict about taking fixes in the -rc cycles these days and knowing > > > exactly what behavior this fixes would be beneficial. > > > > This fixes a failure where the clock can't be retrained. Under some > > circumstances the timing is such that retraining isn't required, in > > which case the code runs normally. However I've seen in happen that > > the PLL isn't stable in other cases, so the code tries to retrain. > > > > But the current code doesn't allow retraining to happen because the > > MC registers aren't accessible for the PLLE and therefore the > > clk_plle_training() function immediately errors out with -ENOSYS. > > > > Comparing to Tegra30 this is obviously just a typo when registering > > the PLLE clock and the virtual address to the PMC registers can be > > passed in at PLLE registration time to resolve this issue. > > > > Hi Thierry, > > Let me rephrase. Does this really need to go into the current -rc's or > can it go towards 3.10? What user-visible failure does this fix? For > example, the board doesn't boot, or randomly crashes, or ethernet wasn't > working but now it is. That sort of thing. Without the patch, PCIe doesn't work reliably. So on some hardware this indeed causes hardware like ethernet to not be properly initialized. With this patch applied, training for the PLL can succeed and PCIe comes up reliably. So yes, I think this belongs in 3.9. Thierry
diff --git a/drivers/clk/tegra/clk-tegra20.c b/drivers/clk/tegra/clk-tegra20.c index b92d48b..bf19400 100644 --- a/drivers/clk/tegra/clk-tegra20.c +++ b/drivers/clk/tegra/clk-tegra20.c @@ -703,7 +703,7 @@ static void tegra20_pll_init(void) clks[pll_a_out0] = clk; /* PLLE */ - clk = tegra_clk_register_plle("pll_e", "pll_ref", clk_base, NULL, + clk = tegra_clk_register_plle("pll_e", "pll_ref", clk_base, pmc_base, 0, 100000000, &pll_e_params, 0, pll_e_freq_table, NULL); clk_register_clkdev(clk, "pll_e", NULL);
Under some circumstances the PLLE needs to be retrained, in which case access to the PMC registers is required. Fix this by passing a pointer to the PMC registers instead of NULL when registering the PLLE clock. Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de> --- drivers/clk/tegra/clk-tegra20.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)