[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200712301810.59790.juergen127@kreuzholzen.de>
Date: Sun, 30 Dec 2007 18:10:58 +0100
From: Juergen Beisert <juergen127@...uzholzen.de>
To: linux-kernel@...r.kernel.org
Cc: Alan Cox <alan@...rguk.ukuu.org.uk>, Ingo Molnar <mingo@...e.hu>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Rene Herman <rene.herman@...access.nl>, dpreed@...d.com,
Islam Amer <pharon@...il.com>, hpa@...or.com,
Pavel Machek <pavel@....cz>, Ingo Molnar <mingo@...hat.com>,
Andi Kleen <andi@...stfloor.org>,
Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override
On Sunday 30 December 2007 16:38, Alan Cox wrote:
> > do you have any memories about the outb_p() use of misc_32.c:
> >
> > pos = (x + cols * y) * 2; /* Update cursor position */
> > outb_p(14, vidport);
> > outb_p(0xff & (pos >> 9), vidport+1);
> > outb_p(15, vidport);
> > outb_p(0xff & (pos >> 1), vidport+1);
> >
> > was this ever needed? This is so early in the bootup that can we cannot
>
> None - but we don't care.
Was this embedded outb to 0x80 for delay only? Maybe I'm wrong. But in the
case above it forces the chipselect signal to deselect the hardware between
the access to vidport and vidport+1. Some devices need this to latch the
values correctly. Otherwise the chipselect signal would be active for all
four accesses in the example above (and only data and addresses are changing
from device's view).
Juergen
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists