diff options
author | Linus Torvalds <torvalds@ppc970.osdl.org> | 2005-04-16 18:20:36 -0400 |
---|---|---|
committer | Linus Torvalds <torvalds@ppc970.osdl.org> | 2005-04-16 18:20:36 -0400 |
commit | 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 (patch) | |
tree | 0bba044c4ce775e45a88a51686b5d9f90697ea9d /Documentation/filesystems/sysfs-pci.txt |
Linux-2.6.12-rc2v2.6.12-rc2
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!
Diffstat (limited to 'Documentation/filesystems/sysfs-pci.txt')
-rw-r--r-- | Documentation/filesystems/sysfs-pci.txt | 88 |
1 files changed, 88 insertions, 0 deletions
diff --git a/Documentation/filesystems/sysfs-pci.txt b/Documentation/filesystems/sysfs-pci.txt new file mode 100644 index 000000000000..e97d024eae77 --- /dev/null +++ b/Documentation/filesystems/sysfs-pci.txt | |||
@@ -0,0 +1,88 @@ | |||
1 | Accessing PCI device resources through sysfs | ||
2 | |||
3 | sysfs, usually mounted at /sys, provides access to PCI resources on platforms | ||
4 | that support it. For example, a given bus might look like this: | ||
5 | |||
6 | /sys/devices/pci0000:17 | ||
7 | |-- 0000:17:00.0 | ||
8 | | |-- class | ||
9 | | |-- config | ||
10 | | |-- detach_state | ||
11 | | |-- device | ||
12 | | |-- irq | ||
13 | | |-- local_cpus | ||
14 | | |-- resource | ||
15 | | |-- resource0 | ||
16 | | |-- resource1 | ||
17 | | |-- resource2 | ||
18 | | |-- rom | ||
19 | | |-- subsystem_device | ||
20 | | |-- subsystem_vendor | ||
21 | | `-- vendor | ||
22 | `-- detach_state | ||
23 | |||
24 | The topmost element describes the PCI domain and bus number. In this case, | ||
25 | the domain number is 0000 and the bus number is 17 (both values are in hex). | ||
26 | This bus contains a single function device in slot 0. The domain and bus | ||
27 | numbers are reproduced for convenience. Under the device directory are several | ||
28 | files, each with their own function. | ||
29 | |||
30 | file function | ||
31 | ---- -------- | ||
32 | class PCI class (ascii, ro) | ||
33 | config PCI config space (binary, rw) | ||
34 | detach_state connection status (bool, rw) | ||
35 | device PCI device (ascii, ro) | ||
36 | irq IRQ number (ascii, ro) | ||
37 | local_cpus nearby CPU mask (cpumask, ro) | ||
38 | resource PCI resource host addresses (ascii, ro) | ||
39 | resource0..N PCI resource N, if present (binary, mmap) | ||
40 | rom PCI ROM resource, if present (binary, ro) | ||
41 | subsystem_device PCI subsystem device (ascii, ro) | ||
42 | subsystem_vendor PCI subsystem vendor (ascii, ro) | ||
43 | vendor PCI vendor (ascii, ro) | ||
44 | |||
45 | ro - read only file | ||
46 | rw - file is readable and writable | ||
47 | mmap - file is mmapable | ||
48 | ascii - file contains ascii text | ||
49 | binary - file contains binary data | ||
50 | cpumask - file contains a cpumask type | ||
51 | |||
52 | The read only files are informational, writes to them will be ignored. | ||
53 | Writable files can be used to perform actions on the device (e.g. changing | ||
54 | config space, detaching a device). mmapable files are available via an | ||
55 | mmap of the file at offset 0 and can be used to do actual device programming | ||
56 | from userspace. Note that some platforms don't support mmapping of certain | ||
57 | resources, so be sure to check the return value from any attempted mmap. | ||
58 | |||
59 | Accessing legacy resources through sysfs | ||
60 | |||
61 | Legacy I/O port and ISA memory resources are also provided in sysfs if the | ||
62 | underlying platform supports them. They're located in the PCI class heirarchy, | ||
63 | e.g. | ||
64 | |||
65 | /sys/class/pci_bus/0000:17/ | ||
66 | |-- bridge -> ../../../devices/pci0000:17 | ||
67 | |-- cpuaffinity | ||
68 | |-- legacy_io | ||
69 | `-- legacy_mem | ||
70 | |||
71 | The legacy_io file is a read/write file that can be used by applications to | ||
72 | do legacy port I/O. The application should open the file, seek to the desired | ||
73 | port (e.g. 0x3e8) and do a read or a write of 1, 2 or 4 bytes. The legacy_mem | ||
74 | file should be mmapped with an offset corresponding to the memory offset | ||
75 | desired, e.g. 0xa0000 for the VGA frame buffer. The application can then | ||
76 | simply dereference the returned pointer (after checking for errors of course) | ||
77 | to access legacy memory space. | ||
78 | |||
79 | Supporting PCI access on new platforms | ||
80 | |||
81 | In order to support PCI resource mapping as described above, Linux platform | ||
82 | code must define HAVE_PCI_MMAP and provide a pci_mmap_page_range function. | ||
83 | Platforms are free to only support subsets of the mmap functionality, but | ||
84 | useful return codes should be provided. | ||
85 | |||
86 | Legacy resources are protected by the HAVE_PCI_LEGACY define. Platforms | ||
87 | wishing to support legacy functionality should define it and provide | ||
88 | pci_legacy_read, pci_legacy_write and pci_mmap_legacy_page_range functions. \ No newline at end of file | ||