[lkml]   [1999]   [Mar]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Ideas for abstracting driver IO from bus implementation?
I guess I'm missing something in this discussion -- what is the
bus abstraction and how is it accessed? Things can get "strange" when you
have multiple (many?) PCI buses and have to deal with mapping I/O space,
memory space and address translation from 32bit PCI into 64 bit memory
space especially when some of the PCI bus bridges expect (allow?) the mapping
to be dynamic (for DMA).

I don't know about mapping the bus/port pair into 32 bits, but that's only
part of the problem. I also don't know what's encoded in the upper 16
bits, but you may run out of bits quickly given that some enterprise
server systems can have dozens of PCI busses (not slots!) especially if
you're encoding other information into the upper 16bits.

TTFN - Guy

Quoted mail:
>> My thought is to have a socket driver publish a set of entry points
>> for primitive IO operations: effectively, replacements for readw,
>> writew, inb, outb, and friends. These would be passed out to any
> Ok so you replace a 1 clock pairable operation with 3 or 4 memory operations
> a call, and a pipeline stall.
> That tells me its not general purpose 8)
>> read_io_byte(sock_handle, port) (or sock_handle->read_io_byte(port),
>> or io_handle->read_byte(port)), and having a header file that could
>> collapse this to inb() based on a configuration option.
> I guess "sock_handle" becomes bus.
>> retooled to support indirect device accesses. I guess the 8390 driver
>> has already had something like this hacked in for a special case, so
>> there's some precedent for it. Any comments?
> if you look at the 8390 you'll see it doesn't take any jumps, it turns
> a direct lookup into an indirect with scaling. So it tends to cost 1 or 2
> clocks at most. It also comes out as null on any platform that isnt sick
> like the mac and amiga.
> To give you an example why this matters in many cases - my I2O code paths
> are (last time I checked the asm)
> 2 instructions to get a simple message
> 14 instructions to build a typical message
> 1 instruction to post it
> So it takes me 17 clocks to tell the controller to do something. If you
> wrapped the read/write's it would probably double it
> Macros I would guess are the right answer if you can encode a bus/port
> pair into 32bits. Then you can rebuild any driver with
> DFOR_PCMCIA --include pcmcia_strange.h
---End quote

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:50    [W:0.198 / U:0.612 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site