macro was changed. Since copying 64-bit srr1 into 32-bit srr1 drops the upper
32 bits, any bits set in the context were dropped, meaning the context check
fails. Since 32-bit set_context can't change those bits anyway, copy the ones
from the current context (td->td_frame) before calling set_context().
MFC after: 3 weeks
This is the first step needed to get the snapper codec working on those
machines.
The second step is to enable the corresponding I2S device and its clock.
Tested on machines where the snapper codec was already working, a G4 PowerBook
and a PowerMac9,1 with a Shasta based macio.
The PowerMac7,2/7,3 with a K2 based macio can now also play sound.
MFC after: 1 month
obsolete. This involves the following pieces:
- Remove it entirely on PowerPC, where it is not used by MD code either
- Remove all references to machine/fdt.h in non-architecture-specific code
(aside from uart_cpu_fdt.c, shared by ARM and MIPS, and so is somewhat
non-arch-specific).
- Fix code relying on header pollution from machine/fdt.h includes
- Legacy fdtbus.c (still used on x86 FDT systems) now passes resource
requests to its parent (nexus). This allows x86 FDT devices to allocate
both memory and IO requests and removes the last notionally MI use of
fdtbus_bs_tag.
- On those architectures that retain a machine/fdt.h, unused bits like
FDT_MAP_IRQ and FDT_INTR_MAX have been removed.
This, and several subsequent commits, are suspend/resume for various PowerMac
drivers, which will include a change to the global suspend/resume code
eventually.
With this, also shut shut off the display (DPMS-style) and disable the clocking
when the backlight level is set to 0. This is taken from the radeonkms driver
(radeon_legacy_encoders.c) which doesn't yet support PowerPC, and won't for a
while, as it's missing full AGP support.
containing the trap instruction encoding (0x7c810808), and restoring it back
with the frame on return. This caused it to panic on my ppc32 machine, but
somehow my ppc64 machine overlooked it, because I was using such a simple
dtrace probe.
X-MFC-with: r259245
MFC after: 2 weeks
regions which represent the total amount of memory. The size of these regions
is not the physical size of the chip but it is a logical one and it is given
by the OpenFirmware, it is selectable at boot time and varies between 16MB and
256MB in my case. There is an 'automatic' option which would select the size as
64MB in case you have around 16GB of RAM.
To make sure we can allocate RAM with the automatic option bump this value
of PHYS_AVAIL_SZ to 256.
Open Firmware-centric:
- Keep the static list of regions in platform.c instead of ofw_machdep.c
- Move various merging and sorting operations to platform.c as well
- Move apple_hacks code out of ofw_machdep.c and into platform_powermac.c,
where it belongs
- Move CHRP-specific dynamic-reconfiguration memory parsing into
platform_chrp.c instead of pretending it is shared code
shifts into the sign bit. Instead use (1U << 31) which gets the
expected result.
This fix is not ideal as it assumes a 32 bit int, but does fix the issue
for most cases.
A similar change was made in OpenBSD.
Discussed with: -arch, rdivacky
Reviewed by: cperciva
requires process descriptors to work and having PROCDESC in GENERIC
seems not enough, especially that we hope to have more and more consumers
in the base.
MFC after: 3 days
from OF. Linux does it similar, means they also read the OF values and
display them.
Tested under qemu and real hardware:
cpu0: IBM POWER5+ revision 2.0, 1898.10 MHz
preserve any existing fault buffer. RTAS calls are meant to be safe from
interrupt context (and are indeed used there to implement the xics PIC
drvier). Without this, calling into RTAS in interrupt context would have
the effect of clearing any existing onfault state of the interrupted
thread, potentially leading to a panic.
option, unbreak the lock tracing release semantic by embedding
calls to LOCKSTAT_PROFILE_RELEASE_LOCK() direclty in the inlined
version of the releasing functions for mutex, rwlock and sxlock.
Failing to do so skips the lockstat_probe_func invokation for
unlocking.
- As part of the LOCKSTAT support is inlined in mutex operation, for
kernel compiled without lock debugging options, potentially every
consumer must be compiled including opt_kdtrace.h.
Fix this by moving KDTRACE_HOOKS into opt_global.h and remove the
dependency by opt_kdtrace.h for all files, as now only KDTRACE_FRAMES
is linked there and it is only used as a compile-time stub [0].
[0] immediately shows some new bug as DTRACE-derived support for debug
in sfxge is broken and it was never really tested. As it was not
including correctly opt_kdtrace.h before it was never enabled so it
was kept broken for a while. Fix this by using a protection stub,
leaving sfxge driver authors the responsibility for fixing it
appropriately [1].
Sponsored by: EMC / Isilon storage division
Discussed with: rstone
[0] Reported by: rstone
[1] Discussed with: philip
It turned out that on pSeries machines the call into OF modified the trap
vectors and this made further behaviour unpredictable.
With this commit I'm now able to boot multi user on a network booted
environment on my IntelliStation 285. This is a POWER5+ machine.
Discussed with: nwhitehorn
MFC after: 1 week
ibm,dma-window properties. This is especially a concern when
#ibm,dma-address-cells is not specified and we have to use the regular
#address-cells property.
MFC after: 1 week
On some machines (G5 with lots of RAM), entering OF sometimes causes the
machine to hang. Once the machine is booted, currently the only entry point
into OF is through resetting the framebuffer on mode switch on these machines.
Disabling this allows the machine to stay up at the expense of less usable
consoles after X is started.
MFC after: Never, this is only a hack
