forked from Minki/linux
spelling fixes: arch/m68k/
Spelling fixes in arch/m68k/. Signed-off-by: Simon Arlott <simon@fire.lp0.eu> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Adrian Bunk <bunk@kernel.org>
This commit is contained in:
parent
5aa8b6c1a6
commit
0c79cf6af1
@ -33,7 +33,7 @@ void pcmcia_reset(void)
|
||||
|
||||
|
||||
/* copy a tuple, including tuple header. return nb bytes copied */
|
||||
/* be carefull as this may trigger a GAYLE_IRQ_WR interrupt ! */
|
||||
/* be careful as this may trigger a GAYLE_IRQ_WR interrupt ! */
|
||||
|
||||
int pcmcia_copy_tuple(unsigned char tuple_id, void *tuple, int max_len)
|
||||
{
|
||||
|
@ -284,7 +284,7 @@ static struct mac_model mac_data_table[] = {
|
||||
},
|
||||
|
||||
/*
|
||||
* Weirdified MacII hardware - all subtley different. Gee thanks
|
||||
* Weirdified MacII hardware - all subtly different. Gee thanks
|
||||
* Apple. All these boxes seem to have VIA2 in a different place to
|
||||
* the MacII (+1A000 rather than +4000)
|
||||
* CSA: see http://developer.apple.com/technotes/hw/hw_09.html
|
||||
@ -707,7 +707,7 @@ static struct mac_model mac_data_table[] = {
|
||||
* All of these probably have onboard SONIC in the Dock which
|
||||
* means we'll have to probe for it eventually.
|
||||
*
|
||||
* Are these reallly MAC_VIA_IIci? The developer notes for the
|
||||
* Are these really MAC_VIA_IIci? The developer notes for the
|
||||
* Duos show pretty much the same custom parts as in most of
|
||||
* the other PowerBooks which would imply MAC_VIA_QUADRA.
|
||||
*/
|
||||
|
@ -100,7 +100,7 @@
|
||||
* finished; this function moves the message state to MSG_COMPLETE and signals
|
||||
* the IOP. This two-step process is provided to allow the handler to defer
|
||||
* message processing to a bottom-half handler if the processing will take
|
||||
* a signifigant amount of time (handlers are called at interrupt time so they
|
||||
* a significant amount of time (handlers are called at interrupt time so they
|
||||
* should execute quickly.)
|
||||
*/
|
||||
|
||||
@ -120,7 +120,7 @@
|
||||
|
||||
/*#define DEBUG_IOP*/
|
||||
|
||||
/* Set to nonezero if the IOPs are present. Set by iop_init() */
|
||||
/* Set to non-zero if the IOPs are present. Set by iop_init() */
|
||||
|
||||
int iop_scc_present,iop_ism_present;
|
||||
|
||||
|
@ -8,7 +8,7 @@
|
||||
*
|
||||
* 990502 (jmt) - Major rewrite for new interrupt architecture as well as some
|
||||
* recent insights into OSS operational details.
|
||||
* 990610 (jmt) - Now taking fulll advantage of the OSS. Interrupts are mapped
|
||||
* 990610 (jmt) - Now taking full advantage of the OSS. Interrupts are mapped
|
||||
* to mostly match the A/UX interrupt scheme supported on the
|
||||
* VIA side. Also added support for enabling the ISM irq again
|
||||
* since we now have a functional IOP manager.
|
||||
|
@ -1,7 +1,7 @@
|
||||
/*
|
||||
* 6522 Versatile Interface Adapter (VIA)
|
||||
*
|
||||
* There are two of these on the Mac II. Some IRQ's are vectored
|
||||
* There are two of these on the Mac II. Some IRQs are vectored
|
||||
* via them as are assorted bits and bobs - eg RTC, ADB.
|
||||
*
|
||||
* CSA: Motorola seems to have removed documentation on the 6522 from
|
||||
|
@ -65,7 +65,7 @@ fp_fsqrt(struct fp_ext *dest, struct fp_ext *src)
|
||||
fp_copy_ext(&src2, dest);
|
||||
|
||||
/*
|
||||
* The taylor row arround a for sqrt(x) is:
|
||||
* The taylor row around a for sqrt(x) is:
|
||||
* sqrt(x) = sqrt(a) + 1/(2*sqrt(a))*(x-a) + R
|
||||
* With a=1 this gives:
|
||||
* sqrt(x) = 1 + 1/2*(x-1)
|
||||
|
@ -184,7 +184,7 @@ static struct IRQ_TABLE eirqs[] = {
|
||||
};
|
||||
|
||||
/* complain only this many times about spurious ints : */
|
||||
static int ccleirq=60; /* ISA dev IRQ's*/
|
||||
static int ccleirq=60; /* ISA dev IRQs*/
|
||||
/*static int cclirq=60;*/ /* internal */
|
||||
|
||||
/* FIXME: add shared ints,mask,unmask,probing.... */
|
||||
@ -234,7 +234,7 @@ static void q40_irq_handler(unsigned int irq, struct pt_regs *fp)
|
||||
* There is a little mess wrt which IRQ really caused this irq request. The
|
||||
* main problem is that IIRQ_REG and EIRQ_REG reflect the state when they
|
||||
* are read - which is long after the request came in. In theory IRQs should
|
||||
* not just go away but they occassionally do
|
||||
* not just go away but they occasionally do
|
||||
*/
|
||||
if (irq > 4 && irq <= 15 && mext_disabled) {
|
||||
/*aliased_irq++;*/
|
||||
|
@ -239,7 +239,7 @@ void clear_context(unsigned long context)
|
||||
/* gets an empty context. if full, kills the next context listed to
|
||||
die first */
|
||||
/* This context invalidation scheme is, well, totally arbitrary, I'm
|
||||
sure it could be much more intellegent... but it gets the job done
|
||||
sure it could be much more intelligent... but it gets the job done
|
||||
for now without much overhead in making it's decision. */
|
||||
/* todo: come up with optimized scheme for flushing contexts */
|
||||
unsigned long get_free_context(struct mm_struct *mm)
|
||||
|
Loading…
Reference in New Issue
Block a user