Re: [XenPPC] [rfc] Serial discovery.

[Maria Butrico <butrico@xxxxxxxxxxxxx>]

I was hoping to bring in and use as much as possible linux' pmac_zilog.h 
that defines read and write regs inlined functions that only use readb 
and writeb. 

As for the NS driver I would wish for something a bit more robust that 
testing the value of io_base.   My changes to the serial code discovery 
atm simply set io_base to be the sum of the value we squirrel in 
isa_io_base and the device address.  This would cause the ns device 
driver on ppc to do always read/writeb.  Not that is matters on ppc 
becuase inb and outb in fact add the two anyway. 

In general I would prefer to see logic in the serial discovery code that 
decides if the device is on the isa bus, sets or checks isa_io_base, and 
flags the device as one that should use inb/outb, rather than this funky 
thing based on the value of io_base. 

Jimi Xenidis wrote:
> On May 4, 2006, at 7:54 AM, Maria Butrico wrote:
>
> > The ns device driver is shared between ia and ppc (and who knows what 
> > else).    What concerns me more is the way in which inb/outb is 
> > selected and furthermore the fact that up to now on ppc we have been 
> > using the emulated inb/outb and with my changes we would start using 
> > readb/writeb exclusively.
> The NS driver assumes that if the io_base > 0x10000 (the 16-bit limit 
> of ISA) then it must be an absolute address, and therefor has to be 
> ioremap()ed and accessed with the read*() interfaces that use absolute 
> addressing.
> Not sure if we'll ever see a Zilog off an ISA, we certainly could.
> It is way more likely that we'll all see an NS not on ISA :).
>
> Hollis objects to removing the inb/outb, I don't feel as strongly so I 
> guess we can keep it.
> >   Do I hear consensus on doing away with inb/outb for zilog?
> I'd simply keep zilog ioremap()ed, readb()/writeb() and the first 
> person who sees it on an ISA can add that logic, but feel free to 
> repeat the NS logic if you wish.
> -JX


_______________________________________________
Xen-ppc-devel mailing list
Xen-ppc-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ppc-devel