|   | 
      | 
  
  
      | 
      | 
  
 
     | 
    | 
  
  
     | 
    | 
  
  
    |   | 
      | 
  
  
    | 
         
xen-ppc-devel
Re: [XenPPC] [rfc] Serial discovery.
 
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
 
 |   
 
 | 
    | 
  
  
    |   | 
    |