On May 1, 2006, at 11:45 AM, Hollis Blanchard wrote:
On Mon, 2006-05-01 at 11:23 -0400, Jimi Xenidis wrote:
Right now our serial device is assumed to be hanging off an ISA bus
(hardcoded address) at an offset (also hardcoded).
Neglecting the IOMMU, the only devices that we are interested is
console.
Right now we are restricting console to a UART, and have no plans to
support a framebuffer,ps/2,ADB,USB stuff tho it is possible (except
for USB :)).
I assume you mention these because xen/drivers/char/console.c uses the
IO accessors for VGA, e.g. inb(0x3da). Why should we write those off?
I don't want to write them off at all, we are just not focused on them.
Anyway, rather defining a bus+offset I think we should just keep an
absolute address for the UART.
What problem does this solve?
Some UARTs will not be the ISA (like on all apple machines), when all
we are interested is where the console device is.
The isa_base+offset logic could be simulated but, but why?
(It looks like ns16550.c may work with this change, but note the logic
in e.g. ns16550_init_preirq and ns_read_reg. The behavior of that
driver
would change.)
It does work, its how we got it to work first, but I was convinced to
use an ISA base, and I'm beginning to believe that it was the wrong
way to do it.
If the issue is that you want to use inb/outb in a Zilog driver,
You wish to make inb/outb ISA only interfaces?
please
use ioremap (even though it's a no-op) and readb/writeb instead, like
ns16550.c.
agreed.
-JX
_______________________________________________
Xen-ppc-devel mailing list
Xen-ppc-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ppc-devel
|
Home