* For use on linux hosts to attach a secondary GPU directly
to a qemu / kvm virtual machine.
* The attached card may be in a limbo state, so the driver will
need to re-post the GPUU
* Add isb just because.
* pdziepak pointed out that ARMv5 and before
had different barrier support.
* pdziepak also mentioned that dsb was too strong
for __sync_synchronize
* On ARMv6 or older, we do a simulated dsb.
* Move __sync_synchronize into thread.c in libroot
and use the new arch_atomic.h dsb/dmb defines.
* Gets arm @bootstrap-raw to end of bootstrap.
* Don't assume verdex as it isn't clear this was
occurring.
* Make an educated guess on HAIKU_BOOT_PLATFORM
based on provided board (but still allow it to
be overridden)
* Error out if user doesn't populate
HAIKU_BOOT_PLATFORM or enters an unknown board
name.
* You need to add "-sHAIKU_BOOT_BOARD=xxx" to
your jam to build for the proper ARM device.
* Rename beagle to beagleboneblk as per the
documentation.
* Was causing LLVM to fail to build on x86_64
* Make XINT64 adjust based on architecture like
config/types.h to ensure these macros match
uint64 and int64 at all times.
* Resolves#10566
* As per the ML discussions. Bumps MIPS to tier 3.
* We've reached a unanimous descision that MIPS doesn't
target any real / valid hardware Haiku wants to pursue
at the moment. In the event that anyone wants to pursue
MIPS, feel free to fork Haiku into your own repository
(and we'll even link to it on the website ports page)
* If someone develops a viable plan for MIPS (and gets the
port working, it can be readded at a later date)
* Use atomic_get_and_set for return value
* Atomics are no longer volatile
* Add missing arch_cpu_pause stub
* Move arch_cpu_idle to arch_cpu header to match
other architectures
* Some cards have a lot of pins!
* Should fix#10536
* Add a check to give a friendy warning if we find
more GPIO pins than what we are prepared for.
* Technically the maximum GPIO pins could be
ATOM device max * 2 (16 for i2c and other)
however lets leave some room for expansion.
* This is less pretty, but we need access to the connector
to find the HPD gpio pin mask on the card.
* dp_aux communications seem to work again.
* If you have a DisplayPort item attached to your card you
may want to just unplug it at this point. We attempt DP
link training and it fails. This failure will also cause
other monitors to not function as app_server still isn't
multi-head aware (#10486)
* Bump i2c data into it's own struct
* Populate gGPIOInfo with general gpio pins
(for things like HPD, and voltage control)
* Attach HPD gpio pins to connectors
* Dump trace info of HPD pins as well as i2c pins
* There are GPIO pins for hotplug interrupts and i2c
communications (for edid). Add two fields to connector
(index for each in gGPIOInfo).
* DP aux communcation seems to want the hotplug GPIO pin
info, which we don't get (I think this is why DP AUX comms
is broken at the moment)
* GPIO LUT seems to know about a wide range of GPIO pins, while
the i2c gpio calls only know about the ones needed for i2c.
* I'm tempted to populate gGPIOInfo with the LUT pins and
then suplement that data with the i2c GPIO pins data.
(however, not sure how many pins there are generally defined
so it could impact performance. More investigation is needed)
This would reverse how it works now with this commit.
* The DPMS hook would be called on all
possible displays causing lots of link
training on incomplete connector structures
that may be not attached / connected.
* Added cards need testing.
* 3dfx, ati, neomagic, and s3 still don't build due to some
more complex pointer size issues. (and I don't have hardware
to test on)
* open_count only got raised on initial open,
subsequent opens didn't increment the counter
thus when they exited the driver unloaded
causing app_server to crash
* Thanks to hamishm for pointing out that
the if checks the pre-increment number
* Resolves#10452
* open_count only got raised on initial open,
subsequent opens didn't increment the counter
thus when they exited the driver unloaded
causing app_server to crash
* Thanks to hamishm for pointing out that
the if checks the pre-increment number
* Resolves#10452
* Add a kdl debug command to radeon_hd
* Fix incorrect cpu vendor name mapping
* Add additional CPU architectures
* Add additional CPU vendors
* Rework PowerPC arch_system_info passing
PVR back for cpu model
* Set max cpu to 1 for PPC until atomic functions are finished
* We have atomic functions inline in the kernel and assembly
code in libroot post-scheduler merge... isn't that a lot of
duplication?
* Resolves problem with secondary arch builds
not picking up secondary os kit headers
* Still need to build x86 gcc packages
* No binary changes, shouldn't need a bootstrap
* Displays standard CPUID, and shows what the
internal CPUID used by OS.h *should* be.
* Should help out in identifying new CPU's
as all end users have to do is run sysinfo
to get the CPU info + value for OS.h
* Previously PE binaries would trigger the "incorrectly
executable" dialog. Now we get a special message for
B_LEGACY_EXECUTABLE and B_UNKNOWN_EXECUTABLE
* Legacy at the moment is a R3 x86 PE binary. This could
be extended to gcc2 binaries someday far, far, down the
road though
* The check for legacy is based on a PE flag I see
set on every R3 binary (that isn't set on dos ones)
* Unknown is something we know *is* an executable, but
can't do anything with (such as an MSDOS or Windows
application)
* No performance drops as we do the PE scan last
* Tested on x86 and x86_gcc2
* My BeagleBone gcc defines __ARMEL__ but not
__ARM__ which breaks the native tool builds
* As ARM was originally Little Endian, we assume
__ARM__ means as such.
* Look for Big Endian ARM and define the needed big
endian preprocessors
* As the OpenGL kit is assumed by most ports (and BeOS apps)
to "exist", lets make mesa_devel present by default until
post R1
* mesa_swrast ensures we always have the basic swrast renderer
To play with mesa_swpipe (gallium llvmpipe, gcc4) uninstall
mesa_swrast and install mesa_swpipe. (you can install both,
but it's first renderer found, first used atm)
* Fix issue where mesa_devel attempted to lay
a symlink over a directory causing instability
installing mesa_devel
* Add mesa_swpipe to repos (LLVM enabled Gallium softpipe)
* This has positive and negitive effects. Using the
first monitor's EDID vs the VESA EDID means DisplayPort
monitors and adaptors function. I think the benefits
outweigh the risks at this point.
* Haiku will use the native display mode of the first
monitor and set it across all attached displays.
* Please open bug reports if you notice and regressions.
* The needed LLVM libraries are now within
the Mesa optional build package.
* The swpipe renderer needs some work still
and will likey change, swrast is fully
functional.
* For #9894
* No clue how that is going to work, seems mulitple
GPU onboard.. we will likely just use the first
card we see.
* We may need to remove one of these if additional
work is required to switch GPU's.
* They are all over the place.. I give up
* Going off of engineering names and DCE is more accurate
* A lot of this info came from the x.org wiki
* I'd like to transition some of the engineering
name checks to use DCE versions.. they tend to be more
accurate and exact. (in some cases we can't, but most of
the time we can)
