From: linux@arm.linux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH RFC 0/4] Scheduler idle notifiers and users
Date: Wed, 15 Feb 2012 16:00:28 +0000 [thread overview]
Message-ID: <20120215160028.GD27825@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <1329318063.2293.136.camel@twins>
On Wed, Feb 15, 2012 at 04:01:03PM +0100, Peter Zijlstra wrote:
> On Wed, 2012-02-15 at 14:02 +0000, Russell King - ARM Linux wrote:
>
> > There's a problem with that: SA11x0 platforms (for which cpufreq was
> > _originally_ written for before it spouted all the policy stuff which
> > Linus demanded) need to notify drivers when the CPU frequency changes so
> > that drivers can readjust stuff to keep within the bounds of the hardware.
> >
> > Unfortunately, there's embedded platforms out there where the CPU core
> > clock is not just the CPU core clock, but also is the memory bus clock,
> > PCMCIA clock, and some peripheral clocks. All these peripherals need
> > their timing registers rewritten when the CPU core clock changes.
> >
> > Even more unfortunately, some of these peripherals can't be adjusted
> > with the click of your fingers: you have to wait for them to finish
> > what they're doing. In the case of a LCD controller, that means the
> > hardware must finish displaying the current frame before the LCD
> > controller will shut down and let you change its registers.
> >
> > We _could_ make it atomic, but in return we'd have to spin in the driver
> > for maybe 20+ ms, during which time the system would not be able to do
> > anything else, not even those threaded IRQs.
>
> Thing is, the scheduler doesn't care about completion, all it needs is
> to be able to kick-start the thing atomically. So you really have to
> wait for it or can you do an interrupt driven state machine?
Well, in the case I'm most familiar with, the sequence is this:
1. Receive request to change frequency
2. Shut down LCD controller and wait for it to stop (can take 20ms)
3. Check new frequency wrt old frequency, reprogram timings for PCMCIA
if moving to a faster clock rate
4. Simultaneously program new frequency and SDRAM clocking
5. Recheck new frequency wrt old frequency, reprogram things for PCMCIA
if moving to a slower clock rate
6. Reconfigure LCD controller
Now, the problem is that this sequence is spread across multiple drivers,
and today is handled by a notifier, which can sleep in the case of the
LCD controller waiting for the shutdown to complete.
> A third possibility is to self-IPI and take it from there.. assuming
> these platforms can actually self-IPI.
Even if there was an IPI (not talking about SMP anyway) I'm not sure
what good it would be. We can (and do) get an IRQ from the LCD
controller when its shutdown is complete, but that would have to be
somehow propagated back up to the cpufreq code. And the cpufreq code
would have to know that the LCD controller was alive and therefore had
to be waited for. All sounds rather yucky to me.
next prev parent reply other threads:[~2012-02-15 16:00 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-08 1:39 [PATCH RFC 0/4] Scheduler idle notifiers and users Anton Vorontsov
2012-02-08 1:41 ` [PATCH 1/4] sched: Introduce idle notifiers API Anton Vorontsov
2012-02-08 1:43 ` [PATCH 2/4] sched: Wire up idle notifiers Anton Vorontsov
2012-02-08 1:44 ` [PATCH 3/4] cpufreq: New 'interactive' governor Anton Vorontsov
2012-02-08 23:00 ` Vincent Guittot
2012-02-09 0:32 ` Anton Vorontsov
2012-02-08 1:44 ` [PATCH 4/4] ARM: Move leds idle start/stop calls to sched idle notifiers Anton Vorontsov
2012-02-08 3:05 ` [PATCH RFC 0/4] Scheduler idle notifiers and users Peter Zijlstra
2012-02-08 20:23 ` Dave Jones
2012-02-08 21:33 ` Benjamin Herrenschmidt
2012-02-09 7:51 ` Ingo Molnar
2012-02-11 3:15 ` Saravana Kannan
2012-02-11 14:39 ` Mark Brown
2012-02-11 14:53 ` Peter Zijlstra
2012-02-11 15:33 ` Mark Brown
2012-02-15 13:38 ` Peter Zijlstra
2012-02-15 16:04 ` Mark Brown
2012-02-12 21:33 ` Benjamin Herrenschmidt
2012-02-11 14:45 ` Ingo Molnar
2012-02-14 23:20 ` Saravana Kannan
2012-02-15 13:38 ` Peter Zijlstra
2012-02-15 14:02 ` Russell King - ARM Linux
2012-02-15 15:01 ` Peter Zijlstra
2012-02-15 16:00 ` Russell King - ARM Linux [this message]
2012-02-15 16:09 ` Peter Zijlstra
2012-02-16 3:31 ` Benjamin Herrenschmidt
2012-02-16 10:14 ` Peter Zijlstra
2012-02-17 9:00 ` Dominik Brodowski
2012-02-20 11:03 ` Peter Zijlstra
2012-02-21 12:38 ` Pantelis Antoniou
2012-02-21 12:56 ` Peter Zijlstra
2012-02-21 13:31 ` Pantelis Antoniou
2012-02-21 14:52 ` Amit Kucheria
2012-02-21 17:06 ` Pantelis Antoniou
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=20120215160028.GD27825@n2100.arm.linux.org.uk \
--to=linux@arm.linux.org.uk \
--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).