not pre-load the chip's Tx buffer, but instead waits for the Tx Ready
interrupt to transmit the first chunk of data.
* On the IOP310, set COM_HW_NO_TXPRELOAD, rather than COM_HW_TXFIFO_DISABLE.
This solves the "UART hangs" problem on the Npwr in a nicer way (i.e. we
get to use the FIFO, whee). The COM_HW_NO_TXPRELOAD happens to match the
Linux 16550 driver's Tx algorithm, and the "UART hang" was never observed
on the Npwr running Linux.
Eventually, we might want to eliminate the COM_HW_NO_TXPRELOAD, and simply
always use its algorithm. But it should be tested on more 16x50 variants
before we do that.
Kudos to Valeriy Ushakov <uwe@netbsd.org> for pointing out this solution
(which also happens to fix the stray UART interrupt issue on the Krups
Javastation), and to Allen Briggs <briggs@netbsd.org> for experimenting
with various methods of fixing this.
file, <arm/cpuconf.h>, which pulls in "opt_cputypes.h" and then defines
the following:
* CPU_NTYPES -- now many CPU types are configured into the kernel. What
you really want to know is "== 1" or "> 1".
* Defines ARM_ARCH_2, ARM_ARCH_3, ARM_ARCH_4, ARM_ARCH_5, depending
on which ARM architecture versions are configured (based on CPU_*
options). Also defines ARM_NARCH to determins how many architecture
versions are configured.
* Defines ARM_MMU_MEMC, ARM_MMU_GENERIC, ARM_MMU_XSCALE depending on
which classes of ARM MMUs are configured into the kernel, and ARM_NMMUS
to determine how many MMU classes are configured.
Remove the needless inclusion of "opt_cputypes.h" in several places.
Convert remaining users to <arm/cpuconf.h>.
when SA_SIGINFO is used. The IRIX process will hence find the expected
information using the third argument of the signal handler.
We do not provide code and siginfo yet.
Note: The code is written a little more cruftily than it should be. It's also
only tested on the OSB4. I'm not sure it even makes sense to have support for
`native' mode, but I put it in just in case.
This was tested using a custom INSTALL kernel. The current one is >4Mb
which the cats firmware can't currently boot. We need to decide what
needs to be removed from INSTALL.
are used- didn't make a difference, but hey...
Put in commented out GFF_ID code- for use in future attempts to search
the fabric- this probably has to go thru the management server path.
Don't whine about handles we can't find if these are aborted commands
(we know we can't find the handles because we destroy handles after
a successful mailbox abort- we don't wait for the F/W to decide whether
it wants to return a status IOCB after this happens).
thorpej