> This is an horrible hack that breaks so many defined semantics that it's
> not even funny.
> If you want something like that, then you need to freeze/resume _all_
> devices with the proper ordering defined by the bus linkage. It has a
> number of side effects though, can't be done that easily. Maybe cpufreq
> should have the necessary infrastructure for that ?
> That's the wrong approach. If you need to stop
> DMA's during the frequency change, you either need to fix all drivers to
> register cpufreq notifiers that do so (ick !) or if you want to reuse
> the PM callbacks, you need to respect their semantics, notably vs. call
> ordering, or very bad things will happen.
> If we want to go that way, we probably need to add a bit of
> infrastructure to cpufreq to cooperate with the PM code to trigger a
> "light" machine suspend/resume, though expect delays and artifacts, it's
> not something that code be done lightly.
> Ben.
I'm toys salesman. I don't think that I'm capable.
There is already necessary infrastructure (PM). I can do freeze for all
devices with just one function call. Problem is that only block devices
implement freeze. Most devices do suspend insteed of freeze. Some
devices (Speedtouch) don't implement suspend/resume. After USB power
down You have to unplug modem.
Block devices are at top level? If I remove PCI suspend/resume
(network card compatible) will this be OK? Other subsystems
are visible. Can block subsystem be visible too?
> But you should really add that preempt_disable and not try this on smp
> system...
> Pavel
Datasheet for my C3 Nehemiah says that this processor don't have local
APIC and is not SMP capable. I have assumed (based on original longhaul.c)
that all VIA C3 are not SMP capable.
Would You consider appling part of this patch if I add all my assumptions
to Kconfig?
depends on EXPERIMENTAL && (HZ_100 || HZ_250) && (PREEMPT_NONE || PREEMPT_VOLUNTARY)
Rafal
----------------------------------------------------------------------
Potrzebujesz gotowki? Halogotowka to nawet 50 000 bez wizyty w banku.
Rata od 35 zl, bez poreczycieli. Wypelnij formularz. Oddzwonimy.
>>> http://link.interia.pl/f1942
On Sun, May 28, 2006 at 01:38:01PM +0200, Rafa? Bilski wrote:
> Datasheet for my C3 Nehemiah says that this processor don't have local
> APIC and is not SMP capable. I have assumed (based on original longhaul.c)
> that all VIA C3 are not SMP capable.
Nehemiah has a local APIC, and is SMP capable.
(Though boards are hard to come by, and longhaul.ko has never
been tested on such a system)
Dave
--
http://www.codemonkey.org.uk
> Nehemiah has a local APIC, and is SMP capable.
> (Though boards are hard to come by, and longhaul.ko has never
> been tested on such a system)
>
> Dave
We both have right. My C3 is in EBGA and datasheet (v1.90) for
EBGA C3 says:
> OMITTED FUNCTIONS
>
> Symmetric Multiprocessing Support: APIC
> This bus function is omitted since the target market for the VIA C3
> in EBGA is portables and typical desktop systems (which do not
> support APIC multiprocessing). A bit in the feature identification
> returned from the CPUID instruction indicates whether this feature
> is present or not. This enhancement is not provided on the VIA C3 in EBGA.
But C3 in FCPGA(?) have APIC support.
Rafal
----------------------------------------------------------------------
INTERIA.PL dla kobiet... >>> http://link.interia.pl/f193b