[PATCH RFC] ARM: PXA27x: CPUFREQ: Don't use fastbus mode

[PATCH RFC] ARM: PXA27x: CPUFREQ: Don't use fastbus mode

[Vasily Khoruzhick]

PXA27x does not like fastbus for some reason, it can hang in
random places when it's enabled. So don't use it to make cpufreq
stable.

Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
---
 arch/arm/mach-pxa/cpufreq-pxa2xx.c |   12 ++++++------
 1 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-pxa/cpufreq-pxa2xx.c b/arch/arm/mach-pxa/cpufreq-pxa2xx.c
index 6a7aeab..b5727aa 100644
--- a/arch/arm/mach-pxa/cpufreq-pxa2xx.c
+++ b/arch/arm/mach-pxa/cpufreq-pxa2xx.c
@@ -156,13 +156,13 @@ MODULE_PARM_DESC(pxa255_turbo_table, "Selects the frequency table (0 = run table
    ((T)  ? CCLKCFG_TURBO : 0))
 
 static pxa_freqs_t pxa27x_freqs[] = {
-	{104000, 104000, PXA27x_CCCR(1,	 8, 2), 0, CCLKCFG2(1, 0, 1),  900000, 1705000 },
-	{156000, 104000, PXA27x_CCCR(1,	 8, 3), 0, CCLKCFG2(1, 0, 1), 1000000, 1705000 },
+	{104000, 104000, PXA27x_CCCR(1,	 8, 2), 0, CCLKCFG2(0, 0, 1),  900000, 1705000 },
+	{156000, 104000, PXA27x_CCCR(1,	 8, 3), 0, CCLKCFG2(0, 0, 1), 1000000, 1705000 },
 	{208000, 208000, PXA27x_CCCR(0, 16, 2), 1, CCLKCFG2(0, 0, 1), 1180000, 1705000 },
-	{312000, 208000, PXA27x_CCCR(1, 16, 3), 1, CCLKCFG2(1, 0, 1), 1250000, 1705000 },
-	{416000, 208000, PXA27x_CCCR(1, 16, 4), 1, CCLKCFG2(1, 0, 1), 1350000, 1705000 },
-	{520000, 208000, PXA27x_CCCR(1, 16, 5), 1, CCLKCFG2(1, 0, 1), 1450000, 1705000 },
-	{624000, 208000, PXA27x_CCCR(1, 16, 6), 1, CCLKCFG2(1, 0, 1), 1550000, 1705000 }
+	{312000, 208000, PXA27x_CCCR(1, 16, 3), 1, CCLKCFG2(0, 0, 1), 1250000, 1705000 },
+	{416000, 208000, PXA27x_CCCR(1, 16, 4), 1, CCLKCFG2(0, 0, 1), 1350000, 1705000 },
+	{520000, 208000, PXA27x_CCCR(1, 16, 5), 1, CCLKCFG2(0, 0, 1), 1450000, 1705000 },
+	{624000, 208000, PXA27x_CCCR(1, 16, 6), 1, CCLKCFG2(0, 0, 1), 1550000, 1705000 }
 };
 
 #define NUM_PXA27x_FREQS ARRAY_SIZE(pxa27x_freqs)
-- 
1.7.4.1

[PATCH RFC] ARM: PXA27x: CPUFREQ: Don't use fastbus mode

[Marek Vasut]

On Saturday 26 March 2011 20:51:43 Vasily Khoruzhick wrote:
> PXA27x does not like fastbus for some reason, it can hang in
> random places when it's enabled. So don't use it to make cpufreq
> stable.

This is B/S, you're loosing performance! I'd suggest module parameter or device-
specific callback to toggle use of fastbus on/off.

Cheers
> 
> Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
> ---
>  arch/arm/mach-pxa/cpufreq-pxa2xx.c |   12 ++++++------
>  1 files changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/arm/mach-pxa/cpufreq-pxa2xx.c
> b/arch/arm/mach-pxa/cpufreq-pxa2xx.c index 6a7aeab..b5727aa 100644
> --- a/arch/arm/mach-pxa/cpufreq-pxa2xx.c
> +++ b/arch/arm/mach-pxa/cpufreq-pxa2xx.c
> @@ -156,13 +156,13 @@ MODULE_PARM_DESC(pxa255_turbo_table, "Selects the
> frequency table (0 = run table ((T)  ? CCLKCFG_TURBO : 0))
> 
>  static pxa_freqs_t pxa27x_freqs[] = {
> -	{104000, 104000, PXA27x_CCCR(1,	 8, 2), 0, CCLKCFG2(1, 0, 1),  900000,
> 1705000 }, -	{156000, 104000, PXA27x_CCCR(1,	 8, 3), 0, CCLKCFG2(1, 0, 1),
> 1000000, 1705000 }, +	{104000, 104000, PXA27x_CCCR(1,	 8, 2), 0,
> CCLKCFG2(0, 0, 1),  900000, 1705000 }, +	{156000, 104000, PXA27x_CCCR(1,	
> 8, 3), 0, CCLKCFG2(0, 0, 1), 1000000, 1705000 }, {208000, 208000,
> PXA27x_CCCR(0, 16, 2), 1, CCLKCFG2(0, 0, 1), 1180000, 1705000 },
> -	{312000, 208000, PXA27x_CCCR(1, 16, 3), 1, CCLKCFG2(1, 0, 1), 1250000,
> 1705000 }, -	{416000, 208000, PXA27x_CCCR(1, 16, 4), 1, CCLKCFG2(1, 0, 1),
> 1350000, 1705000 }, -	{520000, 208000, PXA27x_CCCR(1, 16, 5), 1,
> CCLKCFG2(1, 0, 1), 1450000, 1705000 }, -	{624000, 208000, PXA27x_CCCR(1,
> 16, 6), 1, CCLKCFG2(1, 0, 1), 1550000, 1705000 } +	{312000, 208000,
> PXA27x_CCCR(1, 16, 3), 1, CCLKCFG2(0, 0, 1), 1250000, 1705000 },
> +	{416000, 208000, PXA27x_CCCR(1, 16, 4), 1, CCLKCFG2(0, 0, 1), 1350000,
> 1705000 }, +	{520000, 208000, PXA27x_CCCR(1, 16, 5), 1, CCLKCFG2(0, 0, 1),
> 1450000, 1705000 }, +	{624000, 208000, PXA27x_CCCR(1, 16, 6), 1,
> CCLKCFG2(0, 0, 1), 1550000, 1705000 } };
> 
>  #define NUM_PXA27x_FREQS ARRAY_SIZE(pxa27x_freqs)

[PATCH RFC] ARM: PXA27x: CPUFREQ: Don't use fastbus mode

[Vasily Khoruzhick]

On Sunday 27 March 2011 03:52:45 Marek Vasut wrote:
> On Saturday 26 March 2011 20:51:43 Vasily Khoruzhick wrote:
> > PXA27x does not like fastbus for some reason, it can hang in
> > random places when it's enabled. So don't use it to make cpufreq
> > stable.
> 
> This is B/S, you're loosing performance!

I'm losing nothing, without this patch cpufreq does not work stable at all on 
Zipit Z2.

> I'd suggest module parameter or
> device- specific callback to toggle use of fastbus on/off.

Can you test cpufreq without this patch on pxa270-based board with ondemand or 
conservative governor (or userspace with 104/208/312mhz)? Is it stable? If not 
then there's no reason to leave fastbus. Btw, pxa25x table has fastbit unset 
for some reason. Maybe there's some unknown errata about fastbus bit (same as 
half turbo?)

Regards
Vasily

[PATCH RFC] ARM: PXA27x: CPUFREQ: Don't use fastbus mode

[Igor Grinberg]

Hi,

On 03/27/11 09:28, Vasily Khoruzhick wrote:

> On Sunday 27 March 2011 03:52:45 Marek Vasut wrote:
>> On Saturday 26 March 2011 20:51:43 Vasily Khoruzhick wrote:
>>> PXA27x does not like fastbus for some reason, it can hang in
>>> random places when it's enabled. So don't use it to make cpufreq
>>> stable.
>> This is B/S, you're loosing performance!
> I'm losing nothing, without this patch cpufreq does not work stable at all on 
> Zipit Z2.

Possibly, but Z2 is not the only one using PXA27x.
And of course you lose performance, unless you don't care,
because if it does not work at all, you don't care about performance,
but again it is wrong to force all PXA27x based boards to this.

>> I'd suggest module parameter or
>> device- specific callback to toggle use of fastbus on/off.
> Can you test cpufreq without this patch on pxa270-based board with ondemand or 
> conservative governor (or userspace with 104/208/312mhz)? Is it stable? If not 
> then there's no reason to leave fastbus.

cm-x270 and em-x270 work well with fast bus bit set with userspace governor and
with the above frequencies.
I'd check the hardware (especially DRAM).
And I agree with Marek, if you want to disable the fast bus,
then it should be board (or otherwise) controllable.


-- 
Regards,
Igor.

[PATCH RFC] ARM: PXA27x: CPUFREQ: Don't use fastbus mode

[Vasily Khoruzhick]

On Sunday 27 March 2011 12:09:21 Igor Grinberg wrote:

> Possibly, but Z2 is not the only one using PXA27x.
> And of course you lose performance, unless you don't care,
> because if it does not work at all, you don't care about performance,
> but again it is wrong to force all PXA27x based boards to this.

Ok, that's why I've sent this patch with RFC in subject - Z2 is the only 
PXA270-based device I own :)

> cm-x270 and em-x270 work well with fast bus bit set with userspace governor
> and with the above frequencies.

What about ondemand and conservative governors?

> I'd check the hardware (especially DRAM).
> And I agree with Marek, if you want to disable the fast bus,
> then it should be board (or otherwise) controllable.

Ok

Regards
Vasily

[PATCH RFC] ARM: PXA27x: CPUFREQ: Don't use fastbus mode

[Igor Grinberg]

On 03/27/11 11:48, Vasily Khoruzhick wrote:

> On Sunday 27 March 2011 12:09:21 Igor Grinberg wrote:
>> Possibly, but Z2 is not the only one using PXA27x.
>> And of course you lose performance, unless you don't care,
>> because if it does not work at all, you don't care about performance,
>> but again it is wrong to force all PXA27x based boards to this.
> Ok, that's why I've sent this patch with RFC in subject - Z2 is the only 
> PXA270-based device I own :)
>
>> cm-x270 and em-x270 work well with fast bus bit set with userspace governor
>> and with the above frequencies.
> What about ondemand and conservative governors?

I haven't tested those and I don't think I will have an opportunity in the near future,
but is it really important also to test those? Are they different in any special way?

>> I'd check the hardware (especially DRAM).
>> And I agree with Marek, if you want to disable the fast bus,
>> then it should be board (or otherwise) controllable.
> Ok
>
> Regards
> Vasily

-- 
Regards,
Igor.

[PATCH RFC] ARM: PXA27x: CPUFREQ: Don't use fastbus mode

[Vasily Khoruzhick]

On Sunday 27 March 2011 13:09:20 Igor Grinberg wrote:
> On 03/27/11 11:48, Vasily Khoruzhick wrote:
> > On Sunday 27 March 2011 12:09:21 Igor Grinberg wrote:
> >> Possibly, but Z2 is not the only one using PXA27x.
> >> And of course you lose performance, unless you don't care,
> >> because if it does not work at all, you don't care about performance,
> >> but again it is wrong to force all PXA27x based boards to this.
> > 
> > Ok, that's why I've sent this patch with RFC in subject - Z2 is the only
> > PXA270-based device I own :)
> > 
> >> cm-x270 and em-x270 work well with fast bus bit set with userspace
> >> governor and with the above frequencies.
> > 
> > What about ondemand and conservative governors?
> 
> I haven't tested those and I don't think I will have an opportunity in the
> near future, but is it really important also to test those? Are they
> different in any special way?

They switch freq rapidly, so they can be used as stability test for cpufreq 
implementation.

Regards
Vasily

[PATCH RFC] ARM: PXA27x: CPUFREQ: Don't use fastbus mode

[Marek Vasut]

> On Sunday 27 March 2011 13:09:20 Igor Grinberg wrote:
> > On 03/27/11 11:48, Vasily Khoruzhick wrote:
> > > On Sunday 27 March 2011 12:09:21 Igor Grinberg wrote:
> > > > Possibly, but Z2 is not the only one using PXA27x.
> > > > And of course you lose performance, unless you don't care,
> > > > because if it does not work at all, you don't care about
> > > > performance, but again it is wrong to force all PXA27x based
> > > > boards to this.
> > > 
> > > Ok, that's why I've sent this patch with RFC in subject - Z2 is the
> > > only PXA270-based device I own :)
> > > 
> > > > cm-x270 and em-x270 work well with fast bus bit set with userspace
> > > > governor and with the above frequencies.
> > > 
> > > What about ondemand and conservative governors?
> > 
> > I haven't tested those and I don't think I will have an opportunity in
> > the near future, but is it really important also to test those? Are
> > they different in any special way?
> 
> They switch freq rapidly, so they can be used as stability test for
> cpufreq?  implementation.

Aren't you seeing a locking issue during the switch instead of fastbus problem then?

> 
> Regards
> Vasily

[PATCH RFC] ARM: PXA27x: CPUFREQ: Don't use fastbus mode

[Vasily Khoruzhick]

On Sunday 27 March 2011 17:50:45 Marek Vasut wrote:
> > On Sunday 27 March 2011 13:09:20 Igor Grinberg wrote:
> > > On 03/27/11 11:48, Vasily Khoruzhick wrote:
> > > > On Sunday 27 March 2011 12:09:21 Igor Grinberg wrote:
> > > > > Possibly, but Z2 is not the only one using PXA27x.
> > > > > And of course you lose performance, unless you don't care,
> > > > > because if it does not work at all, you don't care about
> > > > > performance, but again it is wrong to force all PXA27x based
> > > > > boards to this.
> > > > 
> > > > Ok, that's why I've sent this patch with RFC in subject - Z2 is the
> > > > only PXA270-based device I own :)
> > > > 
> > > > > cm-x270 and em-x270 work well with fast bus bit set with userspace
> > > > > governor and with the above frequencies.
> > > > 
> > > > What about ondemand and conservative governors?
> > > 
> > > I haven't tested those and I don't think I will have an opportunity in
> > > the near future, but is it really important also to test those? Are
> > > they different in any special way?
> > 
> > They switch freq rapidly, so they can be used as stability test for
> > cpufreq   implementation.
> 
> Aren't you seeing a locking issue during the switch instead of fastbus
> problem then?

I don't see any problems with conservative governor. What symptoms should 
point to locking issue(s)?

Regards
Vasily

[PATCH RFC] ARM: PXA27x: CPUFREQ: Don't use fastbus mode

[Marek Vasut]

> On Sunday 27 March 2011 17:50:45 Marek Vasut wrote:
> > > On Sunday 27 March 2011 13:09:20 Igor Grinberg wrote:
> > > > On 03/27/11 11:48, Vasily Khoruzhick wrote:
> > > > > On Sunday 27 March 2011 12:09:21 Igor Grinberg wrote:
> > > > > > Possibly, but Z2 is not the only one using PXA27x.
> > > > > > And of course you lose performance, unless you don't care,
> > > > > > because if it does not work at all, you don't care about
> > > > > > performance, but again it is wrong to force all PXA27x based
> > > > > > boards to this.
> > > > > 
> > > > > Ok, that's why I've sent this patch with RFC in subject - Z2 is
> > > > > the only PXA270-based device I own :)
> > > > > 
> > > > > > cm-x270 and em-x270 work well with fast bus bit set with
> > > > > > userspace governor and with the above frequencies.
> > > > > 
> > > > > What about ondemand and conservative governors?
> > > > 
> > > > I haven't tested those and I don't think I will have an
> > > > opportunity in the near future, but is it really important also to
> > > > test those? Are they different in any special way?
> > > 
> > > They switch freq rapidly, so they can be used as stability test for
> > > cpufreq? ?  implementation.
> > 
> > Aren't you seeing a locking issue during the switch instead of fastbus
> > problem then?
> 
> I don't see any problems with conservative governor. What symptoms
> should?  point to locking issue(s)?

Probably some hardware didn't finish the transition, while the cpufreq layer thinks the transition is complete and can initiate another one. So two transitions quickly following each other will in this case cause a race.

Disabling fastbus might only change the timing so you're not seeing this issue.

Another possibility is the cpu/system is suffering from undervolt. Or the regulator is unstable when it's switching voltages so fast. So it might even be a regulator issue -- try also configuring the regulator so it doesn't switch at all during frequency change and so it's running on higher, fixed voltage. Simple hack should accomplish that.

> 
> Regards
> Vasily

[PATCH RFC] ARM: PXA27x: CPUFREQ: Don't use fastbus mode

[Robert Jarzmik]

Marek Vasut <marek.vasut.n900@gmail.com> writes:

>> On Sunday 27 March 2011 17:50:45 Marek Vasut wrote:
>> > > On Sunday 27 March 2011 13:09:20 Igor Grinberg wrote:
>> > > > On 03/27/11 11:48, Vasily Khoruzhick wrote:
>> > > > > On Sunday 27 March 2011 12:09:21 Igor Grinberg wrote:
>> > > > > > Possibly, but Z2 is not the only one using PXA27x.
>> > > > > > And of course you lose performance, unless you don't care,
>> > > > > > because if it does not work at all, you don't care about
>> > > > > > performance, but again it is wrong to force all PXA27x based
>> > > > > > boards to this.
>> > > > > 
>> > > > > Ok, that's why I've sent this patch with RFC in subject - Z2 is
>> > > > > the only PXA270-based device I own :)
>> > > > > 
>> > > > > > cm-x270 and em-x270 work well with fast bus bit set with
>> > > > > > userspace governor and with the above frequencies.
>> > > > > 
>> > > > > What about ondemand and conservative governors?
These 2 work well on the mioa701 platform, under the constraint that the minimal
frequency is set to 208 instead of 104.

I would think as Marek that it's a under-voltage issue, unless it's the 104Mhz
transition issue which lasts for as long as I own my platform (and which might
be mioa701 specific AFAIK).

--
Robert

[PATCH RFC] ARM: PXA27x: CPUFREQ: Don't use fastbus mode

[Vasily Khoruzhick]

On Sunday 27 March 2011 19:56:58 Robert Jarzmik wrote:

> These 2 work well on the mioa701 platform, under the constraint that the
> minimal frequency is set to 208 instead of 104.
> 
> I would think as Marek that it's a under-voltage issue, unless it's the
> 104Mhz transition issue which lasts for as long as I own my platform (and
> which might be mioa701 specific AFAIK).

I tried to disable regulator at all (so, regulator is left in default state), 
stock bootloader configures CPU to 208mhz(normal)/312mhz(fast) and enables 
fast mode, but leaves fastbus disabled. So I tried fixed 208mhz and 312mhz 
with fastbus bit set - it hangs in random places, even without cpu freq 
transitions... So maybe it's some hw misdesign, but once again - it works 
pretty stable @104-416mhz with fastbus disabled.

Regards
Vasily

[PATCH RFC] ARM: PXA27x: CPUFREQ: Don't use fastbus mode

[Igor Grinberg]

On 03/27/11 19:13, Vasily Khoruzhick wrote:

> On Sunday 27 March 2011 19:56:58 Robert Jarzmik wrote:
>
>> These 2 work well on the mioa701 platform, under the constraint that the
>> minimal frequency is set to 208 instead of 104.
>>
>> I would think as Marek that it's a under-voltage issue, unless it's the
>> 104Mhz transition issue which lasts for as long as I own my platform (and
>> which might be mioa701 specific AFAIK).
> I tried to disable regulator at all (so, regulator is left in default state), 

What is the default state on Z2? Can you measure it?
The most important are VCC_CORE and VCC_MEM and usually there should be
some "good" capacitors on those, so it should be relatively easy to measure.

> stock bootloader configures CPU to 208mhz(normal)/312mhz(fast) and enables 
> fast mode, but leaves fastbus disabled. So I tried fixed 208mhz and 312mhz 
> with fastbus bit set - it hangs in random places, even without cpu freq 
> transitions... So maybe it's some hw misdesign,

Yep, it looks like it is... PXA27x local bus was always hard to please...

>  but once again - it works 
> pretty stable @104-416mhz with fastbus disabled.


-- 
Regards,
Igor.

[PATCH RFC] ARM: PXA27x: CPUFREQ: Don't use fastbus mode

[Pavel Machek]

Hi!

> >>> PXA27x does not like fastbus for some reason, it can hang in
> >>> random places when it's enabled. So don't use it to make cpufreq
> >>> stable.
> >> This is B/S, you're loosing performance!
> > I'm losing nothing, without this patch cpufreq does not work stable at all on 
> > Zipit Z2.
> 
> Possibly, but Z2 is not the only one using PXA27x.
> And of course you lose performance, unless you don't care,
> because if it does not work at all, you don't care about performance,
> but again it is wrong to force all PXA27x based boards to this.

Well, some other pxa27x machcines  (spitz) are crashing randomly for
_years_ now... so maybe the problem is more widespread?

How easy is to trigger the problem? Do you have script?

Is it possible that this bug triggers with governor==performance.

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[PATCH RFC] ARM: PXA27x: CPUFREQ: Don't use fastbus mode

[Vasily Khoruzhick]

On Monday 11 April 2011 16:46:43 Pavel Machek wrote:
> Hi!
> 
> Well, some other pxa27x machcines  (spitz) are crashing randomly for
> _years_ now... so maybe the problem is more widespread?
> 
> How easy is to trigger the problem? Do you have script?
> 
> Is it possible that this bug triggers with governor==performance.

It's hard to trigger it with performance governor (because it's quite stable 
@416mhz even with fastbus), so I suggest trying ondemand or conservative 
governors.

[PATCH RFC] ARM: PXA27x: CPUFREQ: Don't use fastbus mode

[Marek Vasut]

> On Monday 11 April 2011 16:46:43 Pavel Machek wrote:
> > Hi!
> > 
> > Well, some other pxa27x machcines?  (spitz) are crashing randomly for
> > _years_ now... so maybe the problem is more widespread?
> > 
> > How easy is to trigger the problem? Do you have script?
> > 
> > Is it possible that this bug triggers with governor==performance.
> 
> It's hard to trigger it with performance governor (because it's quite
> stable?  @416mhz even with fastbus), so I suggest trying ondemand or
> conservative?  governors.

Iirc ondemand crashes it easily, yes.