OpenCores
URL https://opencores.org/ocsvn/or1k/or1k/trunk

Subversion Repositories or1k

[/] [or1k/] [trunk/] [linux/] [linux-2.4/] [Documentation/] [DocBook/] [deviceiobook.tmpl] - Blame information for rev 1765

Details | Compare with Previous | View Log

Line No. Rev Author Line
1 1275 phoenix
2
 
3
4
 
5
  Bus-Independent Device Accesses
6
 
7
  
8
   
9
    Matthew
10
    Wilcox
11
    
12
     
13
      matthew@wil.cx
14
     
15
    
16
   
17
  
18
 
19
  
20
   
21
    Alan
22
    Cox
23
    
24
     
25
      alan@redhat.com
26
     
27
    
28
   
29
  
30
 
31
  
32
   2001
33
   Matthew Wilcox
34
  
35
 
36
  
37
   
38
     This documentation is free software; you can redistribute
39
     it and/or modify it under the terms of the GNU General Public
40
     License as published by the Free Software Foundation; either
41
     version 2 of the License, or (at your option) any later
42
     version.
43
   
44
 
45
   
46
     This program is distributed in the hope that it will be
47
     useful, but WITHOUT ANY WARRANTY; without even the implied
48
     warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
49
     See the GNU General Public License for more details.
50
   
51
 
52
   
53
     You should have received a copy of the GNU General Public
54
     License along with this program; if not, write to the Free
55
     Software Foundation, Inc., 59 Temple Place, Suite 330, Boston,
56
     MA 02111-1307 USA
57
   
58
 
59
   
60
     For more details see the file COPYING in the source
61
     distribution of Linux.
62
   
63
  
64
 
65
 
66
67
 
68
  
69
      Introduction
70
  
71
        Linux provides an API which abstracts performing IO across all busses
72
        and devices, allowing device drivers to be written independently of
73
        bus type.
74
  
75
  
76
 
77
  
78
     Known Bugs And Assumptions
79
  
80
        None.
81
  
82
  
83
 
84
  
85
    Memory Mapped IO
86
    
87
      Getting Access to the Device
88
      
89
        The most widely supported form of IO is memory mapped IO.
90
        That is, a part of the CPU's address space is interpreted
91
        not as accesses to memory, but as accesses to a device.  Some
92
        architectures define devices to be at a fixed address, but most
93
        have some method of discovering devices.  The PCI bus walk is a
94
        good example of such a scheme.  This document does not cover how
95
        to receive such an address, but assumes you are starting with one.
96
        Physical addresses are of type unsigned long.
97
      
98
 
99
      
100
        This address should not be used directly.  Instead, to get an
101
        address suitable for passing to the accessor functions described
102
        below, you should call ioremap.
103
        An address suitable for accessing the device will be returned to you.
104
      
105
 
106
      
107
        After you've finished using the device (say, in your module's
108
        exit routine), call iounmap in order to return
109
        the address space to the kernel.  Most architectures allocate new
110
        address space each time you call ioremap, and
111
        they can run out unless you call iounmap.
112
      
113
    
114
 
115
    
116
      Accessing the device
117
      
118
        The part of the interface most used by drivers is reading and
119
        writing memory-mapped registers on the device.  Linux provides
120
        interfaces to read and write 8-bit, 16-bit, 32-bit and 64-bit
121
        quantities.  Due to a historical accident, these are named byte,
122
        word, long and quad accesses.  Both read and write accesses are
123
        supported; there is no prefetch support at this time.
124
      
125
 
126
      
127
        The functions are named readb,
128
        readw, readl,
129
        readq, writeb,
130
        writew, writel and
131
        writeq.
132
      
133
 
134
      
135
        Some devices (such as framebuffers) would like to use larger
136
        transfers than 8 bytes at a time.  For these devices, the
137
        memcpy_toio, memcpy_fromio
138
        and memset_io functions are provided.
139
        Do not use memset or memcpy on IO addresses; they
140
        are not guaranteed to copy data in order.
141
      
142
 
143
      
144
        The read and write functions are defined to be ordered. That is the
145
        compiler is not permitted to reorder the I/O sequence. When the
146
        ordering can be compiler optimised, you can use 
147
        __readb and friends to indicate the relaxed ordering. Use
148
        this with care. The rmb provides a read memory
149
        barrier. The wmb provides a write memory barrier.
150
      
151
 
152
      
153
        While the basic functions are defined to be synchronous with respect
154
        to each other and ordered with respect to each other the busses the
155
        devices sit on may themselves have asynchronocity. In paticular many
156
        authors are burned by the fact that PCI bus writes are posted
157
        asynchronously. A driver author must issue a read from the same
158
        device to ensure that writes have occurred in the specific cases the
159
        author cares. This kind of property cannot be hidden from driver
160
        writers in the API.
161
      
162
    
163
 
164
    
165
      ISA legacy functions
166
      
167
        On older kernels (2.2 and earlier) the ISA bus could be read or
168
        written with these functions and without ioremap being used. This is
169
        no longer true in Linux 2.4. A set of equivalent functions exist for
170
        easy legacy driver porting. The functions available are prefixed
171
        with 'isa_' and are isa_readb,
172
        isa_writeb, isa_readw,
173
        isa_writew, isa_readl,
174
        isa_writel, isa_memcpy_fromio
175
        and isa_memcpy_toio
176
      
177
      
178
        These functions should not be used in new drivers, and will
179
        eventually be going away.
180
      
181
    
182
 
183
  
184
 
185
  
186
    Port Space Accesses
187
    
188
      Port Space Explained
189
 
190
      
191
        Another form of IO commonly supported is Port Space.  This is a
192
        range of addresses separate to the normal memory address space.
193
        Access to these addresses is generally not as fast as accesses
194
        to the memory mapped addresses, and it also has a potentially
195
        smaller address space.
196
      
197
 
198
      
199
        Unlike memory mapped IO, no preparation is required
200
        to access port space.
201
      
202
 
203
    
204
    
205
      Accessing Port Space
206
      
207
        Accesses to this space are provided through a set of functions
208
        which allow 8-bit, 16-bit and 32-bit accesses; also
209
        known as byte, word and long.  These functions are
210
        inb, inw,
211
        inl, outb,
212
        outw and outl.
213
      
214
 
215
      
216
        Some variants are provided for these functions.  Some devices
217
        require that accesses to their ports are slowed down.  This
218
        functionality is provided by appending a _p
219
        to the end of the function.  There are also equivalents to memcpy.
220
        The ins and outs
221
        functions copy bytes, words or longs to the given port.
222
      
223
    
224
 
225
  
226
 
227
  
228
     Public Functions Provided
229
!Einclude/asm-i386/io.h
230
  
231
 
232

powered by: WebSVN 2.1.0

© copyright 1999-2024 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.