lkml.org 
[lkml]   [1999]   [Mar]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Ideas for abstracting driver IO from bus implementation?
Date
From

Alan Cox writes:
> > (1) Can you give some examples of what tokens you might want? I've been
>
> mca slot, pci slot

I presume that you're making these values as tokens so that the I/O access
routines (such as pcibios_write_config_byte) can be told how to access their
devices.

If this is the case, then the Vendor-Defined-Registers access functions that I
already provide could prove useful (or may be extended). This involves a pair
of functions pointed to by my device operations structure that allow access to
the devices registers:

int (*ci_read_vdr)(cmgr_device *dev, int addr, int num, int size,
void *buf);
int (*ci_set_vdr)(cmgr_device *dev, int addr, int num, int size,
const void *buf);

You pass the functions a device structure to say how to reach the device, and
leave the actual communication method up to them. It may involve a pcibios_*
function, or it may involve rendering down to some PCMCIA operations.

> private physical address space (not to be mapped by the kernel)

I'm not sure what your mean by this - doesn't it need to be mapped so that the
kernel can access it, or do you mean giving bits of real memory to a device
for its own purposes?

> I2O wants to claim things buy bus.

What exactly do you mean? Does I2O deal with whole buses rather than devices?
Or is it a case of I2O allocating resources to a bus?

David Howells

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:50    [from the cache]
©2003-2011 Jasper Spaans