After this change, low level cpuidle drivers load the generic cpuidle
module if they can support the underlying platform.
change the intel cpuidle driver accordingly, now it's loaded by acpi
bus manager during boot, although it doesn't depend on acpi
Signed-off-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
Currently, it's only used to load generic cpuidle module. But in the
future, we will add some features such as stats reporting etc.
Signed-off-by: Yongcong Du <ycdu.vmcore@gmail.com>
Signed-off-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
Currently, it only supports intel sandy bridge processors.
Signed-off-by: Yongcong Du <ycdu.vmcore@gmail.com>
Signed-off-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
This module will load the various lowlevel cpuidle modules' implementations
during initialiation. If it finds one available module, it will change
the global gCpuIdleFunc as its own better one.
When idle, cpuidle module will select the best cstate and enter it by
calling the lowlevel module's implementation.
Signed-off-by: Yongcong Du <ycdu.vmcore@gmail.com>
Signed-off-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
* The HEADERS_DEPENDENCY isn't needed
for GLU as Mesa is a dependency and requires
GLU to build
* I actually didn't break the build,
we were however using the Mesa GLU headers
with the external GLU lib which could be bad
* Check if offset is actually an error code and attempt to compensate
At the very least don't use it as an offset (would be bad).
* Write to the output string directly instead of copying a temp string.
* Add a ToDo to check if day of week should go after time for locale
* Replace hardcoded 64 in GetCurrentDate().
... with day of week tacked on at the beginning.
This fixes #9143 by better allowing the Locale Kit to
format the time. It was localized before but now also
uses localized time separators.
There might be still a bug with day of week though,
depending on if day of week should go before or after
the time in your locale (It is hard coded to before).
* We felt that me adding this didn't really
properly communicate the spirit of the
email approval. You really can't just
'change' a license from MIT without author
approval... so this is superfluous.
This will get libroot.so to build, which should give us much more compilation
coverage for ARM now too. Will have to go through all the libroot code with
a tooth comb anyway once userland comes up...
(Will consider replacing the glibc mess with bsd for all non gcc2 platforms)
* A copy of the email approving this change is
in the LICENSE.txt file
* This clears up several concerns
* We now have permission to clean / update GLUT
code and redistrubute its binaries.
* We have to ensure all of Mark's work is *not*
GPL licensed as per his wishes.
* GCC 4.7 is more picky than GCC 4.6, so have to make changes accordingly
* Changes include addressing issues with scoping, redeclaration, etc.
Thanks Rene and Ingo for your input on these changes
Will sort this out properly when userland is coming up. Need to get
a basic libroot version working first, so I can build a proper HaikuImage
to boot from ;)
These are pretty generic 32bit target files, so just copy them over.
Once we get userland properly starting, we can review these to see
if they need any changes.
This adds a few generic implementations of basic arithmetic functions. These
would normally be implemented in assembly, but add them for easy bringup of
new architectures.
This enables new platforms to start with a minimal set of changes to libroot.
There is no ARM port for the glibc version we're using mostly, so I'm picking
up files from more recent glibc and will probably need to hack around in them,
as glibc seem to have cleaned up their arch support a lot these days.
This is some defensive coding that assumes that the AddTeamMenu(),
RemoveTeamMenu(), AddSeperatorItem(), and RemoveSeperatorItem()
methods might fail and tries to compensate. Although it is unlikely
to be the case that these methods could fail I am trying to prevent
the bug that caused #9151 to happen.
