From: marek.vasut.n900@gmail.com (Marek Vasut)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH RFC] ARM: PXA27x: CPUFREQ: Don't use fastbus mode
Date: Sun, 27 Mar 2011 17:34:49 +0200 [thread overview]
Message-ID: <1301240089.10831.2.camel@konomi> (raw)
In-Reply-To: <201103271756.19262.anarsoul@gmail.com>
> 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
next prev parent reply other threads:[~2011-03-27 15:34 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-26 19:51 [PATCH RFC] ARM: PXA27x: CPUFREQ: Don't use fastbus mode Vasily Khoruzhick
2011-03-27 0:52 ` Marek Vasut
2011-03-27 7:28 ` Vasily Khoruzhick
2011-03-27 9:09 ` Igor Grinberg
2011-03-27 9:48 ` Vasily Khoruzhick
2011-03-27 10:09 ` Igor Grinberg
2011-03-27 14:45 ` Vasily Khoruzhick
2011-03-27 14:50 ` Marek Vasut
2011-03-27 14:56 ` Vasily Khoruzhick
2011-03-27 15:34 ` Marek Vasut [this message]
2011-03-27 16:56 ` Robert Jarzmik
2011-03-27 17:13 ` Vasily Khoruzhick
2011-03-28 8:22 ` Igor Grinberg
2011-04-11 13:46 ` Pavel Machek
2011-04-11 20:11 ` Vasily Khoruzhick
2011-04-12 5:22 ` Marek Vasut
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1301240089.10831.2.camel@konomi \
--to=marek.vasut.n900@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).