[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Deva interface

From: R. Koot
Subject: Deva interface
Date: Mon, 17 Jan 2005 19:03:22 +0100
User-agent: Mozilla Thunderbird 1.0 (X11/20041206)

Sorry, mailed this to Bas instead of the mailing list.

Bas Wijnen wrote:

> Neal H. Walfield wrote:
>>> *I tried to design some interfaces for deva.
>>> deva should respond to at least these RPCs:
>>> -enumerate
>>> -open
>>> -close
>>> -read
>>> -write
>>> -map

> I think the most important thing of the framework is to have clear definitions of "device class interfaces", a bit like usb device classes have them. The difference is that every device should fall into a class. An example: there should be a class "network device", for which an interface is defined. To write a driver for an ethernet card, or a modem, or a wifi card, it is then clear what interface to implement. Drivers may follow more than one interface (in fact, most devices will do that, I think). I mention in particular the modem, as I heard from some companies who were complaining about the way Linux handles them: in fact it doesn't at all, if you're lucky you get a serial port, with nowhere in the system a hint on how to set up exotic parameters. That sort of information should be usable by the client, either by making it available, or better yet, by providing an RPC to set it up.

I'm actually writing a driver interface (originaly for my own L4 OS, but I think I want to help with the HURD now), maybe it's useful.

+--------+     +--------+     +--------+     +--------+
|        |     |        | --> |  Deva  | <-> |+------+|
|  The   | --> | Direct |     +--------+     ||Driver||
|  Game  |     |  Axe   |                    ||      ||
|        |     |        | -----------------> |+------+|
+--------+     +--------+                    +--------+

In a multi-server OS applications/services can and should talk directly with the drivers. This means deva doesn't have to specifiy/provide the interfaces to them. Deva should just manage drivers (load/unload/power-mangement) and provide an interface to let applications find devices.

I think it would be best if each driver prvides several separate interfaces. One general interface that communicates with Deva and a few that communicate with services (which abstract the device further to a 'POSIX device' for example). A video driver would contain a basic video interface that does mode-setting and framebuffer-mapping, but could also contain an interface for 2D acceleration and one or more interfaces for 3D acceleration (OpenGL, 3Dfx, DirectX-ish,...). The closer it gets to how the real hardware does it the better the performance. These kind of thing would just be very hard to doe with read/write/ioctl.

\title{OpenDriver Specification 0.1}
\author{Mithrill Group}

\chapter{C Run-Time Environment}


int8\_t \\
int16\_t \\
int32\_t \\
int64\_t \\
int128\_t \\
int256\_t \\

uint8\_t \\
uint16\_t \\
uint32\_t \\
uint64\_t \\
uint128\_t \\
uint256\_t \\

real32\_t \\
real64\_t \\
real128\_t \\

size\_t \\
pointer\_t \\

bool\_t \\
char\_t \\
string\_t \\

\chapter{C++ Run-Time Environment}

\chapter{Java Run-Time Environment}


\chapter{ISA Bus}


The ISA bus was the original bus or the IBM PC. It was an 8-bit bus without any 
support for Plug\&Play. In the IBM AT it was expanded to a 16 bit bus, with 
support for more IRQ levels and DMA channels. Some of the controllers of the 
early PCs (which are now intergrated into the \emph{southbridge} or modern 
chipsets) were also conected to the ISA bus, but because they were not limited 
by the connector they had access to additional IRQ levels and DMA channels. 
This is sometimes called the LPC (\emph{Legacy PC}) bus. An example is the 
keyboard controller. \\

Later a Plug\&Play option  was added, but very few cards supported this. The 
device should already be configured when the driver is loaded. \\

The original bus and DMA controller ran at 4.77 MHz but in modern systems this 
is increased to 8.33 MHz (a quarter of the PCI clock). \\

\subsection{I/O Ports}
While the IA-32 processors are able to access $2^{16}$ I/O ports, the ISA bus 
allows only access to $2^{10}$ I/O ports. Because I/O port addresses above 
0x3FF are not filtered out, every I/O port $x$ \emph{might} be aliased at $x + 
0$x$400k$, with $k \in \{1, 2, ..., 63\}$.

The ISA bus uses two cascaded 8259A PIC controllers. These allow for a total of 
16 IRQ levels, but only 11 are wired onto the bus. The ISA bus only supports 
\emph{edge-triggered} interrupts, so officially interrupt sharing is not 
possible. If care is taken that two devices are not active at the same time it 
can be done, however. In some PCs the sound card and the second parallel port 
both use IRQ 7, for example. \\

IRQ 2 is used for the cascade, the pin on the bus was rerouted to IRQ 9 on the 
AT and is sometimes refered to as IRQ 2/9 or on 8-bit cards as IRQ 2. \\

IRQ 13 was used to report FPU errors for the 80287 and 80387 but is not used on 
the 80487 and up in native mode. \\

Level & Bus & Usage \\
 0 & No       & Timer \\
 1 & No       & Keyboard \\
 2 & No       & Cascade \\
 3 & Yes      & Serial Port 2 \\
 4 & Yes      & Serial Port 1 \\
 5 & Yes      & Parallel Port 2 \\ 
 6 & Yes      & Floppy Disk \\
 7 & Yes      & Parallel Port 1 \\
 8 & No       & Real-Time Clock \\
 9 & Yes      & PCI \\
10 & Yes (16) & PCI \\
11 & Yes (16) & PCI \\
12 & Yes (16) & Mouse \\
13 & No       & FPU \\ 
14 & Yes (16) & Hard Disk 1 \\
15 & Yes (16) & Hard Disk 2 \\

The ISA bus uses two cascaded 8237A DMA controllers providing 8 DMA channels. 
Channels 0 to 3 can do 8-bit transfers, while channels 5 to 7 can only do 
16-bit transfers. Channel 4 is used for cascading and is not available for use 
by devices. Transfers cannot be done simultaniously. \\

A common misconception is that channel 0 is used for the refreshing of the RAM. 
This was only done in the original PC-XT. ATs and higher use dedicated hardware 
and channel 0 was made available, although only for 16-bit cards. \\

For 8-bit transfers the DMA controller can transfer upto 64 kB. It can only 
address 64 kB also. To solve this an extra 8-bit page register is used to 
extend the address space to the full 16 MB. This page register is not updated 
during a transfer however, meaning that the data read/written will wrap back on 
a 64 kB boundary. To avoid this you should align transfers on 64 kB boundaries. 
If you planned for this behaviour the operating system will support it, 
however. \\

\emph{For 16-bit transfers the DMA controller can transfer upto 128 kB. As far 
as I know the low bit op the page register is ignored allowing for 128 kB DMA 
pages. The Intel SIO also supported extra page register allowing 128 MB 
(27-bits) or 4 GB (32-bits) of physical memory to be addressed. This 
information is not on the Intel PIIX or Intel ICH datasheets. The Intel SIO 
could also program individual DMA channels into 8-bit, 16-bit or the new 16-bit 
count-by-byte modes, and even supported scatter/gather DMA, alerting the CPU on 
IRQ 13 when the transfer was done.}

Channel & Bus & Width & Usage \\
0 & Yes (16) & 8  & \\
1 & Yes      & 8  & Parallel Port 1 \\
2 & Yes      & 8  & Floppy Disk \\
3 & Yes      & 8  & Parallel Port 2 \\
4 & No       & 16 & Cascade \\
5 & Yes (16) & 16 & Hard Disk 2 \\ 
6 & Yes (16) & 16 & \\
7 & Yes (16) & 16 & Hard Disk 1 \\

The ISA bus supports mapped memory to support option ROMs, video memory and EMS 
frames. Only 24 address-bits are put onto the bus (20 for 8-bit cards) so the 
mapped memory must be located below 16 MB (1 MB for 8-bit cards).


enum isa\_resourcetype\_t \{ \\
\}; \\

struct isa\_resource\_t \{ \\
isa\_resourcetype\_t type; \\
isa\_resourceaddress\_t address; \\
\}; \\


void isa\_initialize( isa\_resource\_t resourcelist[ ] ); \\

void isa\_finalize( void ); \\


bool\_t isa\_resource\_allocate( isa\_resource\_t ); \\

bool\_t isa\_resource\_free( isa\_resource\_t ); \\

void isa\_dma\_read( isa\_resourceaddress\_t, pointer\_t, size\_t ); \\

This operating will lock the DMA controller so no other device driver can use 
it. It will then configure it for a read operationg. If the DMA controller is 
already locked this call waits until it is unblocked. \\

resourceaddress: the DMA channel. \\
pointer: the buffer. \\
size: the amount of bytes/words (8-bit/16-bit transfers) to transfer. \\

void isa\_dma\_write( pointer\_t, isa\_resourceaddress\_t, size\_t ); \\

bool\_t isa\_dma\_polldone( isa\_resourceaddress\_t ); \\

void isa\_dma\_waitdone( isa\_resourceaddress\_t ); \\

bool\_t isa\_dma\_pollrequest( isa\_resourceaddress\_t ); \\

void isa\_dma\_waitrequest( isa\_resourceaddress\_t ); \\

interrupt\_t isa\_irq\_getinterrupt( isa\_resourceaddress\_t ); \\

int8\_t isa\_io\_read8( isa\_resourceaddress\_t ); \\
int8\_t isa\_io\_read16( isa\_resourceaddress\_t ); \\
int8\_t isa\_io\_read32( isa\_resourceaddress\_t ); \\
void isa\_io\_write8( int8\_t, isa\_resourceaddress\_t ); \\
void isa\_io\_write16( int16\_t, isa\_resourceaddress\_t ); \\
void isa\_io\_write32( int32\_t, isa\_resourceaddress\_t ); \\


isa\_dma\_read( FLOPPY\_DMA, buffer, 512 ); \\
isa\_io\_write8( FLOPPY\_COMMAND, FLOPPY\_READ ); \\
interrupt\_wait( isa\_irq\_getinterrupt( FLOPPY\_IRQ ) ); \\
isa\_dma\_polldone( FLOPPY\_DMA ); \\

%\chapter{EISA Bus}
%\chapter{MCA Bus}
%\chapter{VESA Local Bus}
%\chapter{PCI Bus}


%\chapter{PCI-X Bus}
%\chapter{PCI Express Bus}
%\chapter{AGP Bus}
%\chapter{NuBus Bus}
%\chapter{SBUS Bus}

%\chapter{Fibre Channel}
%\chapter{SCSI/ATAPI Bus}
%\chapter{USB Bus}

%\chapter{Future Bus}
%\chapter{Scalable Coherent Interconect}

%\chapter{Apple Desktop Bus}
%\chpater{Processor Direct Slot}

\chapter{Audio Devices}
\chapter{Graphics Devices}
\chapter{Video Devices}



reply via email to

[Prev in Thread] Current Thread [Next in Thread]