* Janusz Krzysztofik [111201 10:48]:
> On Thursday 01 of December 2011 at 20:04:55, Tony Lindgren wrote:
> >
> > From: Tony Lindgren
> > Date: Thu, 1 Dec 2011 11:00:11 -0800
> > Subject: [PATCH] ARM: OMAP1: Fix reprogramming of DPLL1 for systems that
> > boot at rates below 60MHz
> >
> > Commi
On Thursday 01 of December 2011 at 20:04:55, Tony Lindgren wrote:
>
> From: Tony Lindgren
> Date: Thu, 1 Dec 2011 11:00:11 -0800
> Subject: [PATCH] ARM: OMAP1: Fix reprogramming of DPLL1 for systems that boot
> at rates below 60MHz
>
> Commit e9b7086b80c4d9e354f4edc9e280ae85a60df408 (ARM: OMAP:
* Janusz Krzysztofik [111201 10:04]:
> On Thursday 01 of December 2011 at 18:17:58, Tony Lindgren wrote:
> >
> > --- a/arch/arm/mach-omap1/clock_data.c
> > +++ b/arch/arm/mach-omap1/clock_data.c
> > @@ -927,7 +927,7 @@ int __init omap1_clk_init(void)
> >
> > void __init omap1_clk_late_init(voi
On Thursday 01 of December 2011 at 18:17:58, Tony Lindgren wrote:
> * Janusz Krzysztofik [111201 01:20]:
[snip]
> > Perhaps
> > we should rather think of reverting a few commits which caused all these
> > problems if fixing them all during rc cycle seems not possible? I
> > haven't bisected the
* Janusz Krzysztofik [111201 01:20]:
>
> If you still ask me for my opinion: with patch 3/5 omitted, then not
> being able to run at any other frequency than 60 MHz instead of usual
> 150 since the board support was introduced first, isn't this a
> regression?
Yes, assuming that the behaviour
On Thursday 01 of December 2011 at 10:54:09, Janusz Krzysztofik wrote:
>
> Anyway, did you mean resending those 2/5 and 5/5 without any changes,
> only renumbered as 1/2 and 2/2?
This was not a very clever question, sorry. Answering myself: 2/5 must
be refreshed if not on top of 1/5.
Thanks,
J
I've unintentionally answered off-line, sorry, re-adding all Cc:'s.
On Thursday 01 of December 2011 at 03:27:51, Tony Lindgren wrote:
> * Janusz Krzysztofik [30 17:40]:
> > On Wednesday 30 of November 2011 at 23:32:42, Tony Lindgren wrote:
> > >
> > > Can you please split your series into t
* Janusz Krzysztofik [28 13:26]:
>
> I'm not sure which of the patches you meant not ready for 3.2-rc. From
> your comment I would conclude that only patch 3/5, which would really
> break omap1_defconfig booting on some boards, is questionable, while you
> posted this comment against patch 1/5
DPLL1 reprogramming to a different rate is actually blocked inside
omap1_select_table_rate(), resulting in the defalut rate of 60 MHz
always used instead of the one selected in .config. OTOH, in
omap1_defconfig we currently rely on Kconfig options for the supported
MHz rates in case of boards which
