summaryrefslogtreecommitdiffstats
path: root/include/asm-sparc64/spitfire.h (follow)
Commit message (Collapse)AuthorAgeFilesLines
* [SPARC64]: __inline__ --> inlineDavid S. Miller2007-10-271-27/+26
| | | | Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC64]: Do not assume sun4v chips have load-twin/store-init support.David S. Miller2007-08-091-0/+7
| | | | | | | | | | Check the cpu type in the OBP device tree before committing to using the optimized Niagara memcpy and memset implementation. If we don't recognize the cpu type, use a completely generic version. Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC64]: Add 'hypervisor' to ultra_tlb_type enumeration.David S. Miller2006-03-201-0/+1
| | | | Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC64]: Kill totally unused inline functions from asm/spitfire.hDavid S. Miller2005-07-251-130/+0
| | | | Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC64]: Avoid membar instructions in delay slots.David S. Miller2005-06-281-1/+0
| | | | | | | | | | | | | | | | | | | | In particular, avoid membar instructions in the delay slot of a jmpl instruction. UltraSPARC-I, II, IIi, and IIe have a bug, documented in the UltraSPARC-IIi User's Manual, Appendix K, Erratum 51 The long and short of it is that if the IMU unit misses on a branch or jmpl, and there is a store buffer synchronizing membar in the delay slot, the chip can stop fetching instructions. If interrupts are enabled or some other trap is enabled, the chip will unwedge itself, but performance will suffer. We already had a workaround for this bug in a few spots, but it's better to have the entire tree sanitized for this rule. Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC64]: Add boot option to force UltraSPARC-III P-Cache on.David S. Miller2005-05-241-0/+3
| | | | | | | | | | | | | | | | Older UltraSPARC-III chips have a P-Cache bug that makes us disable it by default at boot time. However, this does hurt performance substantially, particularly with memcpy(), and the bug is _incredibly_ obscure. I have never seen it triggered in practice, ever. So provide a "-P" boot option that forces the P-Cache on. It taints the kernel, so if it does trigger and cause some data corruption or OOPS, we will find out in the logs that this option was on when it happened. Signed-off-by: David S. Miller <davem@davemloft.net>
* Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds2005-04-171-0/+461
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!