]>
Commit | Line | Data |
---|---|---|
1da177e4 LT |
1 | <?xml version="1.0" encoding="UTF-8"?> |
2 | <!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN" | |
3 | "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" []> | |
4 | ||
5 | <book id="libataDevGuide"> | |
6 | <bookinfo> | |
7 | <title>libATA Developer's Guide</title> | |
8 | ||
9 | <authorgroup> | |
10 | <author> | |
11 | <firstname>Jeff</firstname> | |
12 | <surname>Garzik</surname> | |
13 | </author> | |
14 | </authorgroup> | |
15 | ||
16 | <copyright> | |
4f931374 | 17 | <year>2003-2006</year> |
1da177e4 LT |
18 | <holder>Jeff Garzik</holder> |
19 | </copyright> | |
20 | ||
21 | <legalnotice> | |
22 | <para> | |
23 | The contents of this file are subject to the Open | |
24 | Software License version 1.1 that can be found at | |
4ff162f0 MO |
25 | <ulink url="http://fedoraproject.org/wiki/Licensing:OSL1.1">http://fedoraproject.org/wiki/Licensing:OSL1.1</ulink> |
26 | and is included herein by reference. | |
1da177e4 LT |
27 | </para> |
28 | ||
29 | <para> | |
30 | Alternatively, the contents of this file may be used under the terms | |
31 | of the GNU General Public License version 2 (the "GPL") as distributed | |
32 | in the kernel source COPYING file, in which case the provisions of | |
33 | the GPL are applicable instead of the above. If you wish to allow | |
34 | the use of your version of this file only under the terms of the | |
35 | GPL and not to allow others to use your version of this file under | |
36 | the OSL, indicate your decision by deleting the provisions above and | |
37 | replace them with the notice and other provisions required by the GPL. | |
38 | If you do not delete the provisions above, a recipient may use your | |
39 | version of this file under either the OSL or the GPL. | |
40 | </para> | |
41 | ||
42 | </legalnotice> | |
43 | </bookinfo> | |
44 | ||
45 | <toc></toc> | |
46 | ||
07dd39b9 JG |
47 | <chapter id="libataIntroduction"> |
48 | <title>Introduction</title> | |
49 | <para> | |
50 | libATA is a library used inside the Linux kernel to support ATA host | |
51 | controllers and devices. libATA provides an ATA driver API, class | |
52 | transports for ATA and ATAPI devices, and SCSI<->ATA translation | |
53 | for ATA devices according to the T10 SAT specification. | |
54 | </para> | |
55 | <para> | |
56 | This Guide documents the libATA driver API, library functions, library | |
57 | internals, and a couple sample ATA low-level drivers. | |
58 | </para> | |
59 | </chapter> | |
60 | ||
1da177e4 LT |
61 | <chapter id="libataDriverApi"> |
62 | <title>libata Driver API</title> | |
92bab26b JG |
63 | <para> |
64 | struct ata_port_operations is defined for every low-level libata | |
65 | hardware driver, and it controls how the low-level driver | |
66 | interfaces with the ATA and SCSI layers. | |
67 | </para> | |
68 | <para> | |
69 | FIS-based drivers will hook into the system with ->qc_prep() and | |
70 | ->qc_issue() high-level hooks. Hardware which behaves in a manner | |
71 | similar to PCI IDE hardware may utilize several generic helpers, | |
72 | defining at a bare minimum the bus I/O addresses of the ATA shadow | |
73 | register blocks. | |
74 | </para> | |
1da177e4 LT |
75 | <sect1> |
76 | <title>struct ata_port_operations</title> | |
77 | ||
92bab26b | 78 | <sect2><title>Disable ATA port</title> |
1da177e4 LT |
79 | <programlisting> |
80 | void (*port_disable) (struct ata_port *); | |
81 | </programlisting> | |
82 | ||
83 | <para> | |
29444088 SS |
84 | Called from ata_bus_probe() error path, as well as when |
85 | unregistering from the SCSI module (rmmod, hot unplug). | |
8b2af8f0 EF |
86 | This function should do whatever needs to be done to take the |
87 | port out of use. In most cases, ata_port_disable() can be used | |
88 | as this hook. | |
89 | </para> | |
90 | <para> | |
91 | Called from ata_bus_probe() on a failed probe. | |
8b2af8f0 | 92 | Called from ata_scsi_release(). |
1da177e4 LT |
93 | </para> |
94 | ||
92bab26b JG |
95 | </sect2> |
96 | ||
97 | <sect2><title>Post-IDENTIFY device configuration</title> | |
1da177e4 LT |
98 | <programlisting> |
99 | void (*dev_config) (struct ata_port *, struct ata_device *); | |
100 | </programlisting> | |
101 | ||
102 | <para> | |
103 | Called after IDENTIFY [PACKET] DEVICE is issued to each device | |
104 | found. Typically used to apply device-specific fixups prior to | |
105 | issue of SET FEATURES - XFER MODE, and prior to operation. | |
106 | </para> | |
8b2af8f0 | 107 | <para> |
8b2af8f0 EF |
108 | This entry may be specified as NULL in ata_port_operations. |
109 | </para> | |
1da177e4 | 110 | |
92bab26b JG |
111 | </sect2> |
112 | ||
113 | <sect2><title>Set PIO/DMA mode</title> | |
1da177e4 LT |
114 | <programlisting> |
115 | void (*set_piomode) (struct ata_port *, struct ata_device *); | |
116 | void (*set_dmamode) (struct ata_port *, struct ata_device *); | |
5444a6f4 AC |
117 | void (*post_set_mode) (struct ata_port *); |
118 | unsigned int (*mode_filter) (struct ata_port *, struct ata_device *, unsigned int); | |
1da177e4 LT |
119 | </programlisting> |
120 | ||
121 | <para> | |
122 | Hooks called prior to the issue of SET FEATURES - XFER MODE | |
5444a6f4 AC |
123 | command. The optional ->mode_filter() hook is called when libata |
124 | has built a mask of the possible modes. This is passed to the | |
125 | ->mode_filter() function which should return a mask of valid modes | |
126 | after filtering those unsuitable due to hardware limits. It is not | |
127 | valid to use this interface to add modes. | |
128 | </para> | |
129 | <para> | |
130 | dev->pio_mode and dev->dma_mode are guaranteed to be valid when | |
131 | ->set_piomode() and when ->set_dmamode() is called. The timings for | |
132 | any other drive sharing the cable will also be valid at this point. | |
133 | That is the library records the decisions for the modes of each | |
134 | drive on a channel before it attempts to set any of them. | |
135 | </para> | |
136 | <para> | |
137 | ->post_set_mode() is | |
1da177e4 LT |
138 | called unconditionally, after the SET FEATURES - XFER MODE |
139 | command completes successfully. | |
140 | </para> | |
141 | ||
142 | <para> | |
143 | ->set_piomode() is always called (if present), but | |
144 | ->set_dma_mode() is only called if DMA is possible. | |
145 | </para> | |
146 | ||
92bab26b JG |
147 | </sect2> |
148 | ||
149 | <sect2><title>Taskfile read/write</title> | |
1da177e4 | 150 | <programlisting> |
40868c85 SS |
151 | void (*sff_tf_load) (struct ata_port *ap, struct ata_taskfile *tf); |
152 | void (*sff_tf_read) (struct ata_port *ap, struct ata_taskfile *tf); | |
1da177e4 LT |
153 | </programlisting> |
154 | ||
155 | <para> | |
156 | ->tf_load() is called to load the given taskfile into hardware | |
157 | registers / DMA buffers. ->tf_read() is called to read the | |
158 | hardware registers / DMA buffers, to obtain the current set of | |
159 | taskfile register values. | |
8b2af8f0 | 160 | Most drivers for taskfile-based hardware (PIO or MMIO) use |
40868c85 | 161 | ata_sff_tf_load() and ata_sff_tf_read() for these hooks. |
1da177e4 LT |
162 | </para> |
163 | ||
92bab26b JG |
164 | </sect2> |
165 | ||
bf717b11 JG |
166 | <sect2><title>PIO data read/write</title> |
167 | <programlisting> | |
40868c85 | 168 | void (*sff_data_xfer) (struct ata_device *, unsigned char *, unsigned int, int); |
bf717b11 JG |
169 | </programlisting> |
170 | ||
171 | <para> | |
172 | All bmdma-style drivers must implement this hook. This is the low-level | |
173 | operation that actually copies the data bytes during a PIO data | |
174 | transfer. | |
40868c85 SS |
175 | Typically the driver will choose one of ata_sff_data_xfer_noirq(), |
176 | ata_sff_data_xfer(), or ata_sff_data_xfer32(). | |
bf717b11 JG |
177 | </para> |
178 | ||
179 | </sect2> | |
180 | ||
92bab26b | 181 | <sect2><title>ATA command execute</title> |
1da177e4 | 182 | <programlisting> |
40868c85 | 183 | void (*sff_exec_command)(struct ata_port *ap, struct ata_taskfile *tf); |
1da177e4 LT |
184 | </programlisting> |
185 | ||
186 | <para> | |
187 | causes an ATA command, previously loaded with | |
188 | ->tf_load(), to be initiated in hardware. | |
40868c85 | 189 | Most drivers for taskfile-based hardware use ata_sff_exec_command() |
8b2af8f0 | 190 | for this hook. |
1da177e4 LT |
191 | </para> |
192 | ||
92bab26b JG |
193 | </sect2> |
194 | ||
195 | <sect2><title>Per-cmd ATAPI DMA capabilities filter</title> | |
780a87f7 JG |
196 | <programlisting> |
197 | int (*check_atapi_dma) (struct ata_queued_cmd *qc); | |
198 | </programlisting> | |
199 | ||
200 | <para> | |
201 | Allow low-level driver to filter ATA PACKET commands, returning a status | |
202 | indicating whether or not it is OK to use DMA for the supplied PACKET | |
203 | command. | |
204 | </para> | |
8b2af8f0 EF |
205 | <para> |
206 | This hook may be specified as NULL, in which case libata will | |
207 | assume that atapi dma can be supported. | |
208 | </para> | |
780a87f7 | 209 | |
92bab26b JG |
210 | </sect2> |
211 | ||
212 | <sect2><title>Read specific ATA shadow registers</title> | |
1da177e4 | 213 | <programlisting> |
40868c85 SS |
214 | u8 (*sff_check_status)(struct ata_port *ap); |
215 | u8 (*sff_check_altstatus)(struct ata_port *ap); | |
1da177e4 LT |
216 | </programlisting> |
217 | ||
218 | <para> | |
bf717b11 | 219 | Reads the Status/AltStatus ATA shadow register from |
780a87f7 JG |
220 | hardware. On some hardware, reading the Status register has |
221 | the side effect of clearing the interrupt condition. | |
8b2af8f0 | 222 | Most drivers for taskfile-based hardware use |
40868c85 | 223 | ata_sff_check_status() for this hook. |
1da177e4 LT |
224 | </para> |
225 | ||
92bab26b JG |
226 | </sect2> |
227 | ||
41dec29b SS |
228 | <sect2><title>Write specific ATA shadow register</title> |
229 | <programlisting> | |
230 | void (*sff_set_devctl)(struct ata_port *ap, u8 ctl); | |
231 | </programlisting> | |
232 | ||
233 | <para> | |
234 | Write the device control ATA shadow register to the hardware. | |
235 | Most drivers don't need to define this. | |
236 | </para> | |
237 | ||
238 | </sect2> | |
239 | ||
92bab26b | 240 | <sect2><title>Select ATA device on bus</title> |
1da177e4 | 241 | <programlisting> |
40868c85 | 242 | void (*sff_dev_select)(struct ata_port *ap, unsigned int device); |
1da177e4 LT |
243 | </programlisting> |
244 | ||
245 | <para> | |
246 | Issues the low-level hardware command(s) that causes one of N | |
247 | hardware devices to be considered 'selected' (active and | |
780a87f7 | 248 | available for use) on the ATA bus. This generally has no |
8b2af8f0 EF |
249 | meaning on FIS-based devices. |
250 | </para> | |
251 | <para> | |
252 | Most drivers for taskfile-based hardware use | |
40868c85 | 253 | ata_sff_dev_select() for this hook. |
1da177e4 LT |
254 | </para> |
255 | ||
92bab26b JG |
256 | </sect2> |
257 | ||
5444a6f4 AC |
258 | <sect2><title>Private tuning method</title> |
259 | <programlisting> | |
260 | void (*set_mode) (struct ata_port *ap); | |
261 | </programlisting> | |
262 | ||
263 | <para> | |
264 | By default libata performs drive and controller tuning in | |
265 | accordance with the ATA timing rules and also applies blacklists | |
266 | and cable limits. Some controllers need special handling and have | |
267 | custom tuning rules, typically raid controllers that use ATA | |
268 | commands but do not actually do drive timing. | |
269 | </para> | |
270 | ||
271 | <warning> | |
272 | <para> | |
273 | This hook should not be used to replace the standard controller | |
274 | tuning logic when a controller has quirks. Replacing the default | |
275 | tuning logic in that case would bypass handling for drive and | |
276 | bridge quirks that may be important to data reliability. If a | |
277 | controller needs to filter the mode selection it should use the | |
278 | mode_filter hook instead. | |
279 | </para> | |
280 | </warning> | |
281 | ||
282 | </sect2> | |
283 | ||
92bab26b | 284 | <sect2><title>Control PCI IDE BMDMA engine</title> |
1da177e4 LT |
285 | <programlisting> |
286 | void (*bmdma_setup) (struct ata_queued_cmd *qc); | |
287 | void (*bmdma_start) (struct ata_queued_cmd *qc); | |
780a87f7 JG |
288 | void (*bmdma_stop) (struct ata_port *ap); |
289 | u8 (*bmdma_status) (struct ata_port *ap); | |
1da177e4 LT |
290 | </programlisting> |
291 | ||
292 | <para> | |
780a87f7 JG |
293 | When setting up an IDE BMDMA transaction, these hooks arm |
294 | (->bmdma_setup), fire (->bmdma_start), and halt (->bmdma_stop) | |
295 | the hardware's DMA engine. ->bmdma_status is used to read the standard | |
296 | PCI IDE DMA Status register. | |
297 | </para> | |
298 | ||
299 | <para> | |
300 | These hooks are typically either no-ops, or simply not implemented, in | |
301 | FIS-based drivers. | |
1da177e4 | 302 | </para> |
8b2af8f0 EF |
303 | <para> |
304 | Most legacy IDE drivers use ata_bmdma_setup() for the bmdma_setup() | |
305 | hook. ata_bmdma_setup() will write the pointer to the PRD table to | |
306 | the IDE PRD Table Address register, enable DMA in the DMA Command | |
307 | register, and call exec_command() to begin the transfer. | |
308 | </para> | |
309 | <para> | |
310 | Most legacy IDE drivers use ata_bmdma_start() for the bmdma_start() | |
311 | hook. ata_bmdma_start() will write the ATA_DMA_START flag to the DMA | |
312 | Command register. | |
313 | </para> | |
314 | <para> | |
315 | Many legacy IDE drivers use ata_bmdma_stop() for the bmdma_stop() | |
316 | hook. ata_bmdma_stop() clears the ATA_DMA_START flag in the DMA | |
317 | command register. | |
318 | </para> | |
319 | <para> | |
320 | Many legacy IDE drivers use ata_bmdma_status() as the bmdma_status() hook. | |
321 | </para> | |
1da177e4 | 322 | |
92bab26b JG |
323 | </sect2> |
324 | ||
325 | <sect2><title>High-level taskfile hooks</title> | |
1da177e4 LT |
326 | <programlisting> |
327 | void (*qc_prep) (struct ata_queued_cmd *qc); | |
328 | int (*qc_issue) (struct ata_queued_cmd *qc); | |
329 | </programlisting> | |
330 | ||
331 | <para> | |
332 | Higher-level hooks, these two hooks can potentially supercede | |
333 | several of the above taskfile/DMA engine hooks. ->qc_prep is | |
334 | called after the buffers have been DMA-mapped, and is typically | |
335 | used to populate the hardware's DMA scatter-gather table. | |
336 | Most drivers use the standard ata_qc_prep() helper function, but | |
337 | more advanced drivers roll their own. | |
338 | </para> | |
339 | <para> | |
340 | ->qc_issue is used to make a command active, once the hardware | |
341 | and S/G tables have been prepared. IDE BMDMA drivers use the | |
342 | helper function ata_qc_issue_prot() for taskfile protocol-based | |
780a87f7 | 343 | dispatch. More advanced drivers implement their own ->qc_issue. |
1da177e4 | 344 | </para> |
8b2af8f0 EF |
345 | <para> |
346 | ata_qc_issue_prot() calls ->tf_load(), ->bmdma_setup(), and | |
347 | ->bmdma_start() as necessary to initiate a transfer. | |
348 | </para> | |
1da177e4 | 349 | |
92bab26b JG |
350 | </sect2> |
351 | ||
bf717b11 | 352 | <sect2><title>Exception and probe handling (EH)</title> |
1da177e4 LT |
353 | <programlisting> |
354 | void (*eng_timeout) (struct ata_port *ap); | |
bf717b11 JG |
355 | void (*phy_reset) (struct ata_port *ap); |
356 | </programlisting> | |
357 | ||
358 | <para> | |
359 | Deprecated. Use ->error_handler() instead. | |
360 | </para> | |
361 | ||
362 | <programlisting> | |
363 | void (*freeze) (struct ata_port *ap); | |
364 | void (*thaw) (struct ata_port *ap); | |
365 | </programlisting> | |
366 | ||
367 | <para> | |
368 | ata_port_freeze() is called when HSM violations or some other | |
369 | condition disrupts normal operation of the port. A frozen port | |
370 | is not allowed to perform any operation until the port is | |
371 | thawed, which usually follows a successful reset. | |
372 | </para> | |
373 | ||
374 | <para> | |
375 | The optional ->freeze() callback can be used for freezing the port | |
376 | hardware-wise (e.g. mask interrupt and stop DMA engine). If a | |
377 | port cannot be frozen hardware-wise, the interrupt handler | |
378 | must ack and clear interrupts unconditionally while the port | |
379 | is frozen. | |
380 | </para> | |
381 | <para> | |
382 | The optional ->thaw() callback is called to perform the opposite of ->freeze(): | |
383 | prepare the port for normal operation once again. Unmask interrupts, | |
384 | start DMA engine, etc. | |
385 | </para> | |
386 | ||
387 | <programlisting> | |
388 | void (*error_handler) (struct ata_port *ap); | |
389 | </programlisting> | |
390 | ||
391 | <para> | |
392 | ->error_handler() is a driver's hook into probe, hotplug, and recovery | |
393 | and other exceptional conditions. The primary responsibility of an | |
394 | implementation is to call ata_do_eh() or ata_bmdma_drive_eh() with a set | |
395 | of EH hooks as arguments: | |
396 | </para> | |
397 | ||
398 | <para> | |
399 | 'prereset' hook (may be NULL) is called during an EH reset, before any other actions | |
400 | are taken. | |
401 | </para> | |
402 | ||
403 | <para> | |
404 | 'postreset' hook (may be NULL) is called after the EH reset is performed. Based on | |
405 | existing conditions, severity of the problem, and hardware capabilities, | |
406 | </para> | |
407 | ||
408 | <para> | |
409 | Either 'softreset' (may be NULL) or 'hardreset' (may be NULL) will be | |
410 | called to perform the low-level EH reset. | |
411 | </para> | |
412 | ||
413 | <programlisting> | |
414 | void (*post_internal_cmd) (struct ata_queued_cmd *qc); | |
1da177e4 LT |
415 | </programlisting> |
416 | ||
417 | <para> | |
bf717b11 JG |
418 | Perform any hardware-specific actions necessary to finish processing |
419 | after executing a probe-time or EH-time command via ata_exec_internal(). | |
1da177e4 LT |
420 | </para> |
421 | ||
92bab26b JG |
422 | </sect2> |
423 | ||
424 | <sect2><title>Hardware interrupt handling</title> | |
1da177e4 LT |
425 | <programlisting> |
426 | irqreturn_t (*irq_handler)(int, void *, struct pt_regs *); | |
427 | void (*irq_clear) (struct ata_port *); | |
428 | </programlisting> | |
429 | ||
430 | <para> | |
431 | ->irq_handler is the interrupt handling routine registered with | |
432 | the system, by libata. ->irq_clear is called during probe just | |
433 | before the interrupt handler is registered, to be sure hardware | |
434 | is quiet. | |
435 | </para> | |
8b2af8f0 EF |
436 | <para> |
437 | The second argument, dev_instance, should be cast to a pointer | |
438 | to struct ata_host_set. | |
439 | </para> | |
440 | <para> | |
40868c85 | 441 | Most legacy IDE drivers use ata_sff_interrupt() for the |
8b2af8f0 EF |
442 | irq_handler hook, which scans all ports in the host_set, |
443 | determines which queued command was active (if any), and calls | |
40868c85 | 444 | ata_sff_host_intr(ap,qc). |
8b2af8f0 EF |
445 | </para> |
446 | <para> | |
40868c85 | 447 | Most legacy IDE drivers use ata_sff_irq_clear() for the |
8b2af8f0 EF |
448 | irq_clear() hook, which simply clears the interrupt and error |
449 | flags in the DMA status register. | |
450 | </para> | |
1da177e4 | 451 | |
92bab26b JG |
452 | </sect2> |
453 | ||
454 | <sect2><title>SATA phy read/write</title> | |
1da177e4 | 455 | <programlisting> |
110dd8f1 JB |
456 | int (*scr_read) (struct ata_port *ap, unsigned int sc_reg, |
457 | u32 *val); | |
458 | int (*scr_write) (struct ata_port *ap, unsigned int sc_reg, | |
1da177e4 LT |
459 | u32 val); |
460 | </programlisting> | |
461 | ||
462 | <para> | |
463 | Read and write standard SATA phy registers. Currently only used | |
464 | if ->phy_reset hook called the sata_phy_reset() helper function. | |
8b2af8f0 | 465 | sc_reg is one of SCR_STATUS, SCR_CONTROL, SCR_ERROR, or SCR_ACTIVE. |
1da177e4 LT |
466 | </para> |
467 | ||
92bab26b JG |
468 | </sect2> |
469 | ||
470 | <sect2><title>Init and shutdown</title> | |
1da177e4 LT |
471 | <programlisting> |
472 | int (*port_start) (struct ata_port *ap); | |
473 | void (*port_stop) (struct ata_port *ap); | |
474 | void (*host_stop) (struct ata_host_set *host_set); | |
475 | </programlisting> | |
476 | ||
477 | <para> | |
478 | ->port_start() is called just after the data structures for each | |
479 | port are initialized. Typically this is used to alloc per-port | |
480 | DMA buffers / tables / rings, enable DMA engines, and similar | |
8b2af8f0 EF |
481 | tasks. Some drivers also use this entry point as a chance to |
482 | allocate driver-private memory for ap->private_data. | |
483 | </para> | |
484 | <para> | |
485 | Many drivers use ata_port_start() as this hook or call | |
486 | it from their own port_start() hooks. ata_port_start() | |
487 | allocates space for a legacy IDE PRD table and returns. | |
1da177e4 LT |
488 | </para> |
489 | <para> | |
a33f3224 | 490 | ->port_stop() is called after ->host_stop(). Its sole function |
1da177e4 | 491 | is to release DMA/memory resources, now that they are no longer |
8b2af8f0 EF |
492 | actively being used. Many drivers also free driver-private |
493 | data from port at this time. | |
494 | </para> | |
495 | <para> | |
780a87f7 JG |
496 | ->host_stop() is called after all ->port_stop() calls |
497 | have completed. The hook must finalize hardware shutdown, release DMA | |
498 | and other resources, etc. | |
8b2af8f0 | 499 | This hook may be specified as NULL, in which case it is not called. |
780a87f7 | 500 | </para> |
1da177e4 | 501 | |
92bab26b JG |
502 | </sect2> |
503 | ||
1da177e4 | 504 | </sect1> |
a1213499 JG |
505 | </chapter> |
506 | ||
507 | <chapter id="libataEH"> | |
bfd00722 TH |
508 | <title>Error handling</title> |
509 | ||
510 | <para> | |
511 | This chapter describes how errors are handled under libata. | |
512 | Readers are advised to read SCSI EH | |
513 | (Documentation/scsi/scsi_eh.txt) and ATA exceptions doc first. | |
514 | </para> | |
515 | ||
a1213499 | 516 | <sect1><title>Origins of commands</title> |
bfd00722 TH |
517 | <para> |
518 | In libata, a command is represented with struct ata_queued_cmd | |
519 | or qc. qc's are preallocated during port initialization and | |
520 | repetitively used for command executions. Currently only one | |
521 | qc is allocated per port but yet-to-be-merged NCQ branch | |
522 | allocates one for each tag and maps each qc to NCQ tag 1-to-1. | |
523 | </para> | |
524 | <para> | |
525 | libata commands can originate from two sources - libata itself | |
526 | and SCSI midlayer. libata internal commands are used for | |
527 | initialization and error handling. All normal blk requests | |
528 | and commands for SCSI emulation are passed as SCSI commands | |
529 | through queuecommand callback of SCSI host template. | |
530 | </para> | |
a1213499 | 531 | </sect1> |
bfd00722 | 532 | |
a1213499 | 533 | <sect1><title>How commands are issued</title> |
bfd00722 TH |
534 | |
535 | <variablelist> | |
536 | ||
537 | <varlistentry><term>Internal commands</term> | |
538 | <listitem> | |
539 | <para> | |
540 | First, qc is allocated and initialized using | |
541 | ata_qc_new_init(). Although ata_qc_new_init() doesn't | |
542 | implement any wait or retry mechanism when qc is not | |
543 | available, internal commands are currently issued only during | |
544 | initialization and error recovery, so no other command is | |
545 | active and allocation is guaranteed to succeed. | |
546 | </para> | |
547 | <para> | |
548 | Once allocated qc's taskfile is initialized for the command to | |
549 | be executed. qc currently has two mechanisms to notify | |
550 | completion. One is via qc->complete_fn() callback and the | |
551 | other is completion qc->waiting. qc->complete_fn() callback | |
552 | is the asynchronous path used by normal SCSI translated | |
553 | commands and qc->waiting is the synchronous (issuer sleeps in | |
554 | process context) path used by internal commands. | |
555 | </para> | |
556 | <para> | |
557 | Once initialization is complete, host_set lock is acquired | |
558 | and the qc is issued. | |
559 | </para> | |
560 | </listitem> | |
561 | </varlistentry> | |
562 | ||
563 | <varlistentry><term>SCSI commands</term> | |
564 | <listitem> | |
565 | <para> | |
566 | All libata drivers use ata_scsi_queuecmd() as | |
567 | hostt->queuecommand callback. scmds can either be simulated | |
568 | or translated. No qc is involved in processing a simulated | |
569 | scmd. The result is computed right away and the scmd is | |
570 | completed. | |
571 | </para> | |
572 | <para> | |
573 | For a translated scmd, ata_qc_new_init() is invoked to | |
574 | allocate a qc and the scmd is translated into the qc. SCSI | |
575 | midlayer's completion notification function pointer is stored | |
576 | into qc->scsidone. | |
577 | </para> | |
578 | <para> | |
579 | qc->complete_fn() callback is used for completion | |
580 | notification. ATA commands use ata_scsi_qc_complete() while | |
581 | ATAPI commands use atapi_qc_complete(). Both functions end up | |
582 | calling qc->scsidone to notify upper layer when the qc is | |
583 | finished. After translation is completed, the qc is issued | |
584 | with ata_qc_issue(). | |
585 | </para> | |
586 | <para> | |
587 | Note that SCSI midlayer invokes hostt->queuecommand while | |
588 | holding host_set lock, so all above occur while holding | |
589 | host_set lock. | |
590 | </para> | |
591 | </listitem> | |
592 | </varlistentry> | |
593 | ||
594 | </variablelist> | |
a1213499 | 595 | </sect1> |
bfd00722 | 596 | |
a1213499 | 597 | <sect1><title>How commands are processed</title> |
bfd00722 TH |
598 | <para> |
599 | Depending on which protocol and which controller are used, | |
600 | commands are processed differently. For the purpose of | |
601 | discussion, a controller which uses taskfile interface and all | |
602 | standard callbacks is assumed. | |
603 | </para> | |
604 | <para> | |
605 | Currently 6 ATA command protocols are used. They can be | |
606 | sorted into the following four categories according to how | |
607 | they are processed. | |
608 | </para> | |
609 | ||
610 | <variablelist> | |
611 | <varlistentry><term>ATA NO DATA or DMA</term> | |
612 | <listitem> | |
613 | <para> | |
614 | ATA_PROT_NODATA and ATA_PROT_DMA fall into this category. | |
615 | These types of commands don't require any software | |
616 | intervention once issued. Device will raise interrupt on | |
617 | completion. | |
618 | </para> | |
619 | </listitem> | |
620 | </varlistentry> | |
621 | ||
622 | <varlistentry><term>ATA PIO</term> | |
623 | <listitem> | |
624 | <para> | |
625 | ATA_PROT_PIO is in this category. libata currently | |
626 | implements PIO with polling. ATA_NIEN bit is set to turn | |
627 | off interrupt and pio_task on ata_wq performs polling and | |
628 | IO. | |
629 | </para> | |
630 | </listitem> | |
631 | </varlistentry> | |
632 | ||
633 | <varlistentry><term>ATAPI NODATA or DMA</term> | |
634 | <listitem> | |
635 | <para> | |
636 | ATA_PROT_ATAPI_NODATA and ATA_PROT_ATAPI_DMA are in this | |
637 | category. packet_task is used to poll BSY bit after | |
638 | issuing PACKET command. Once BSY is turned off by the | |
639 | device, packet_task transfers CDB and hands off processing | |
640 | to interrupt handler. | |
641 | </para> | |
642 | </listitem> | |
643 | </varlistentry> | |
644 | ||
645 | <varlistentry><term>ATAPI PIO</term> | |
646 | <listitem> | |
647 | <para> | |
648 | ATA_PROT_ATAPI is in this category. ATA_NIEN bit is set | |
649 | and, as in ATAPI NODATA or DMA, packet_task submits cdb. | |
650 | However, after submitting cdb, further processing (data | |
651 | transfer) is handed off to pio_task. | |
652 | </para> | |
653 | </listitem> | |
654 | </varlistentry> | |
655 | </variablelist> | |
a1213499 | 656 | </sect1> |
bfd00722 | 657 | |
a1213499 | 658 | <sect1><title>How commands are completed</title> |
bfd00722 TH |
659 | <para> |
660 | Once issued, all qc's are either completed with | |
661 | ata_qc_complete() or time out. For commands which are handled | |
662 | by interrupts, ata_host_intr() invokes ata_qc_complete(), and, | |
663 | for PIO tasks, pio_task invokes ata_qc_complete(). In error | |
664 | cases, packet_task may also complete commands. | |
665 | </para> | |
666 | <para> | |
667 | ata_qc_complete() does the following. | |
668 | </para> | |
669 | ||
670 | <orderedlist> | |
671 | ||
672 | <listitem> | |
673 | <para> | |
674 | DMA memory is unmapped. | |
675 | </para> | |
676 | </listitem> | |
677 | ||
678 | <listitem> | |
679 | <para> | |
680 | ATA_QCFLAG_ACTIVE is clared from qc->flags. | |
681 | </para> | |
682 | </listitem> | |
683 | ||
684 | <listitem> | |
685 | <para> | |
686 | qc->complete_fn() callback is invoked. If the return value of | |
687 | the callback is not zero. Completion is short circuited and | |
688 | ata_qc_complete() returns. | |
689 | </para> | |
690 | </listitem> | |
691 | ||
692 | <listitem> | |
693 | <para> | |
694 | __ata_qc_complete() is called, which does | |
695 | <orderedlist> | |
696 | ||
697 | <listitem> | |
698 | <para> | |
699 | qc->flags is cleared to zero. | |
700 | </para> | |
701 | </listitem> | |
702 | ||
703 | <listitem> | |
704 | <para> | |
705 | ap->active_tag and qc->tag are poisoned. | |
706 | </para> | |
707 | </listitem> | |
708 | ||
709 | <listitem> | |
710 | <para> | |
711 | qc->waiting is claread & completed (in that order). | |
712 | </para> | |
713 | </listitem> | |
714 | ||
715 | <listitem> | |
716 | <para> | |
717 | qc is deallocated by clearing appropriate bit in ap->qactive. | |
718 | </para> | |
719 | </listitem> | |
720 | ||
721 | </orderedlist> | |
722 | </para> | |
723 | </listitem> | |
724 | ||
725 | </orderedlist> | |
726 | ||
727 | <para> | |
728 | So, it basically notifies upper layer and deallocates qc. One | |
729 | exception is short-circuit path in #3 which is used by | |
730 | atapi_qc_complete(). | |
731 | </para> | |
732 | <para> | |
733 | For all non-ATAPI commands, whether it fails or not, almost | |
734 | the same code path is taken and very little error handling | |
735 | takes place. A qc is completed with success status if it | |
736 | succeeded, with failed status otherwise. | |
737 | </para> | |
738 | <para> | |
739 | However, failed ATAPI commands require more handling as | |
740 | REQUEST SENSE is needed to acquire sense data. If an ATAPI | |
741 | command fails, ata_qc_complete() is invoked with error status, | |
742 | which in turn invokes atapi_qc_complete() via | |
743 | qc->complete_fn() callback. | |
744 | </para> | |
745 | <para> | |
746 | This makes atapi_qc_complete() set scmd->result to | |
747 | SAM_STAT_CHECK_CONDITION, complete the scmd and return 1. As | |
748 | the sense data is empty but scmd->result is CHECK CONDITION, | |
749 | SCSI midlayer will invoke EH for the scmd, and returning 1 | |
750 | makes ata_qc_complete() to return without deallocating the qc. | |
751 | This leads us to ata_scsi_error() with partially completed qc. | |
752 | </para> | |
753 | ||
a1213499 | 754 | </sect1> |
bfd00722 | 755 | |
a1213499 | 756 | <sect1><title>ata_scsi_error()</title> |
bfd00722 | 757 | <para> |
9227c33d | 758 | ata_scsi_error() is the current transportt->eh_strategy_handler() |
bfd00722 TH |
759 | for libata. As discussed above, this will be entered in two |
760 | cases - timeout and ATAPI error completion. This function | |
761 | calls low level libata driver's eng_timeout() callback, the | |
762 | standard callback for which is ata_eng_timeout(). It checks | |
763 | if a qc is active and calls ata_qc_timeout() on the qc if so. | |
764 | Actual error handling occurs in ata_qc_timeout(). | |
765 | </para> | |
766 | <para> | |
767 | If EH is invoked for timeout, ata_qc_timeout() stops BMDMA and | |
768 | completes the qc. Note that as we're currently in EH, we | |
769 | cannot call scsi_done. As described in SCSI EH doc, a | |
770 | recovered scmd should be either retried with | |
771 | scsi_queue_insert() or finished with scsi_finish_command(). | |
772 | Here, we override qc->scsidone with scsi_finish_command() and | |
773 | calls ata_qc_complete(). | |
774 | </para> | |
775 | <para> | |
776 | If EH is invoked due to a failed ATAPI qc, the qc here is | |
777 | completed but not deallocated. The purpose of this | |
778 | half-completion is to use the qc as place holder to make EH | |
779 | code reach this place. This is a bit hackish, but it works. | |
780 | </para> | |
781 | <para> | |
782 | Once control reaches here, the qc is deallocated by invoking | |
783 | __ata_qc_complete() explicitly. Then, internal qc for REQUEST | |
784 | SENSE is issued. Once sense data is acquired, scmd is | |
785 | finished by directly invoking scsi_finish_command() on the | |
786 | scmd. Note that as we already have completed and deallocated | |
787 | the qc which was associated with the scmd, we don't need | |
788 | to/cannot call ata_qc_complete() again. | |
789 | </para> | |
790 | ||
a1213499 | 791 | </sect1> |
bfd00722 | 792 | |
a1213499 | 793 | <sect1><title>Problems with the current EH</title> |
bfd00722 TH |
794 | |
795 | <itemizedlist> | |
796 | ||
797 | <listitem> | |
798 | <para> | |
799 | Error representation is too crude. Currently any and all | |
800 | error conditions are represented with ATA STATUS and ERROR | |
801 | registers. Errors which aren't ATA device errors are treated | |
802 | as ATA device errors by setting ATA_ERR bit. Better error | |
803 | descriptor which can properly represent ATA and other | |
804 | errors/exceptions is needed. | |
805 | </para> | |
806 | </listitem> | |
807 | ||
808 | <listitem> | |
809 | <para> | |
810 | When handling timeouts, no action is taken to make device | |
811 | forget about the timed out command and ready for new commands. | |
812 | </para> | |
813 | </listitem> | |
814 | ||
815 | <listitem> | |
816 | <para> | |
817 | EH handling via ata_scsi_error() is not properly protected | |
818 | from usual command processing. On EH entrance, the device is | |
819 | not in quiescent state. Timed out commands may succeed or | |
820 | fail any time. pio_task and atapi_task may still be running. | |
821 | </para> | |
822 | </listitem> | |
823 | ||
824 | <listitem> | |
825 | <para> | |
826 | Too weak error recovery. Devices / controllers causing HSM | |
827 | mismatch errors and other errors quite often require reset to | |
828 | return to known state. Also, advanced error handling is | |
829 | necessary to support features like NCQ and hotplug. | |
830 | </para> | |
831 | </listitem> | |
832 | ||
833 | <listitem> | |
834 | <para> | |
835 | ATA errors are directly handled in the interrupt handler and | |
836 | PIO errors in pio_task. This is problematic for advanced | |
837 | error handling for the following reasons. | |
838 | </para> | |
839 | <para> | |
840 | First, advanced error handling often requires context and | |
841 | internal qc execution. | |
842 | </para> | |
843 | <para> | |
844 | Second, even a simple failure (say, CRC error) needs | |
845 | information gathering and could trigger complex error handling | |
846 | (say, resetting & reconfiguring). Having multiple code | |
847 | paths to gather information, enter EH and trigger actions | |
848 | makes life painful. | |
849 | </para> | |
850 | <para> | |
851 | Third, scattered EH code makes implementing low level drivers | |
852 | difficult. Low level drivers override libata callbacks. If | |
853 | EH is scattered over several places, each affected callbacks | |
854 | should perform its part of error handling. This can be error | |
855 | prone and painful. | |
856 | </para> | |
857 | </listitem> | |
858 | ||
859 | </itemizedlist> | |
a1213499 | 860 | </sect1> |
1da177e4 LT |
861 | </chapter> |
862 | ||
863 | <chapter id="libataExt"> | |
864 | <title>libata Library</title> | |
58707cce | 865 | !Edrivers/ata/libata-core.c |
1da177e4 LT |
866 | </chapter> |
867 | ||
868 | <chapter id="libataInt"> | |
869 | <title>libata Core Internals</title> | |
58707cce | 870 | !Idrivers/ata/libata-core.c |
1da177e4 LT |
871 | </chapter> |
872 | ||
873 | <chapter id="libataScsiInt"> | |
874 | <title>libata SCSI translation/emulation</title> | |
58707cce HK |
875 | !Edrivers/ata/libata-scsi.c |
876 | !Idrivers/ata/libata-scsi.c | |
1da177e4 LT |
877 | </chapter> |
878 | ||
fe998aa7 | 879 | <chapter id="ataExceptions"> |
7db51fbe | 880 | <title>ATA errors and exceptions</title> |
fe998aa7 TH |
881 | |
882 | <para> | |
883 | This chapter tries to identify what error/exception conditions exist | |
884 | for ATA/ATAPI devices and describe how they should be handled in | |
885 | implementation-neutral way. | |
886 | </para> | |
887 | ||
888 | <para> | |
889 | The term 'error' is used to describe conditions where either an | |
890 | explicit error condition is reported from device or a command has | |
891 | timed out. | |
892 | </para> | |
893 | ||
894 | <para> | |
895 | The term 'exception' is either used to describe exceptional | |
896 | conditions which are not errors (say, power or hotplug events), or | |
897 | to describe both errors and non-error exceptional conditions. Where | |
898 | explicit distinction between error and exception is necessary, the | |
899 | term 'non-error exception' is used. | |
900 | </para> | |
901 | ||
902 | <sect1 id="excat"> | |
903 | <title>Exception categories</title> | |
904 | <para> | |
905 | Exceptions are described primarily with respect to legacy | |
906 | taskfile + bus master IDE interface. If a controller provides | |
907 | other better mechanism for error reporting, mapping those into | |
908 | categories described below shouldn't be difficult. | |
909 | </para> | |
910 | ||
911 | <para> | |
912 | In the following sections, two recovery actions - reset and | |
913 | reconfiguring transport - are mentioned. These are described | |
914 | further in <xref linkend="exrec"/>. | |
915 | </para> | |
916 | ||
917 | <sect2 id="excatHSMviolation"> | |
918 | <title>HSM violation</title> | |
919 | <para> | |
920 | This error is indicated when STATUS value doesn't match HSM | |
921 | requirement during issuing or excution any ATA/ATAPI command. | |
922 | </para> | |
923 | ||
924 | <itemizedlist> | |
925 | <title>Examples</title> | |
926 | ||
927 | <listitem> | |
928 | <para> | |
929 | ATA_STATUS doesn't contain !BSY && DRDY && !DRQ while trying | |
930 | to issue a command. | |
931 | </para> | |
932 | </listitem> | |
933 | ||
934 | <listitem> | |
935 | <para> | |
936 | !BSY && !DRQ during PIO data transfer. | |
937 | </para> | |
938 | </listitem> | |
939 | ||
940 | <listitem> | |
941 | <para> | |
942 | DRQ on command completion. | |
943 | </para> | |
944 | </listitem> | |
945 | ||
946 | <listitem> | |
947 | <para> | |
40e47125 | 948 | !BSY && ERR after CDB transfer starts but before the |
fe998aa7 TH |
949 | last byte of CDB is transferred. ATA/ATAPI standard states |
950 | that "The device shall not terminate the PACKET command | |
951 | with an error before the last byte of the command packet has | |
952 | been written" in the error outputs description of PACKET | |
953 | command and the state diagram doesn't include such | |
954 | transitions. | |
955 | </para> | |
956 | </listitem> | |
957 | ||
958 | </itemizedlist> | |
959 | ||
960 | <para> | |
961 | In these cases, HSM is violated and not much information | |
962 | regarding the error can be acquired from STATUS or ERROR | |
963 | register. IOW, this error can be anything - driver bug, | |
964 | faulty device, controller and/or cable. | |
965 | </para> | |
966 | ||
967 | <para> | |
968 | As HSM is violated, reset is necessary to restore known state. | |
969 | Reconfiguring transport for lower speed might be helpful too | |
970 | as transmission errors sometimes cause this kind of errors. | |
971 | </para> | |
972 | </sect2> | |
973 | ||
974 | <sect2 id="excatDevErr"> | |
975 | <title>ATA/ATAPI device error (non-NCQ / non-CHECK CONDITION)</title> | |
976 | ||
977 | <para> | |
978 | These are errors detected and reported by ATA/ATAPI devices | |
979 | indicating device problems. For this type of errors, STATUS | |
980 | and ERROR register values are valid and describe error | |
981 | condition. Note that some of ATA bus errors are detected by | |
982 | ATA/ATAPI devices and reported using the same mechanism as | |
983 | device errors. Those cases are described later in this | |
984 | section. | |
985 | </para> | |
986 | ||
987 | <para> | |
988 | For ATA commands, this type of errors are indicated by !BSY | |
989 | && ERR during command execution and on completion. | |
990 | </para> | |
991 | ||
992 | <para>For ATAPI commands,</para> | |
993 | ||
994 | <itemizedlist> | |
995 | ||
996 | <listitem> | |
997 | <para> | |
998 | !BSY && ERR && ABRT right after issuing PACKET | |
999 | indicates that PACKET command is not supported and falls in | |
1000 | this category. | |
1001 | </para> | |
1002 | </listitem> | |
1003 | ||
1004 | <listitem> | |
1005 | <para> | |
1006 | !BSY && ERR(==CHK) && !ABRT after the last | |
1007 | byte of CDB is transferred indicates CHECK CONDITION and | |
1008 | doesn't fall in this category. | |
1009 | </para> | |
1010 | </listitem> | |
1011 | ||
1012 | <listitem> | |
1013 | <para> | |
1014 | !BSY && ERR(==CHK) && ABRT after the last byte | |
1015 | of CDB is transferred *probably* indicates CHECK CONDITION and | |
1016 | doesn't fall in this category. | |
1017 | </para> | |
1018 | </listitem> | |
1019 | ||
1020 | </itemizedlist> | |
1021 | ||
1022 | <para> | |
1023 | Of errors detected as above, the followings are not ATA/ATAPI | |
1024 | device errors but ATA bus errors and should be handled | |
1025 | according to <xref linkend="excatATAbusErr"/>. | |
1026 | </para> | |
1027 | ||
1028 | <variablelist> | |
1029 | ||
1030 | <varlistentry> | |
1031 | <term>CRC error during data transfer</term> | |
1032 | <listitem> | |
1033 | <para> | |
1034 | This is indicated by ICRC bit in the ERROR register and | |
25985edc | 1035 | means that corruption occurred during data transfer. Up to |
fe998aa7 TH |
1036 | ATA/ATAPI-7, the standard specifies that this bit is only |
1037 | applicable to UDMA transfers but ATA/ATAPI-8 draft revision | |
1038 | 1f says that the bit may be applicable to multiword DMA and | |
1039 | PIO. | |
1040 | </para> | |
1041 | </listitem> | |
1042 | </varlistentry> | |
1043 | ||
1044 | <varlistentry> | |
1045 | <term>ABRT error during data transfer or on completion</term> | |
1046 | <listitem> | |
1047 | <para> | |
25985edc | 1048 | Up to ATA/ATAPI-7, the standard specifies that ABRT could be |
fe998aa7 TH |
1049 | set on ICRC errors and on cases where a device is not able |
1050 | to complete a command. Combined with the fact that MWDMA | |
25985edc | 1051 | and PIO transfer errors aren't allowed to use ICRC bit up to |
fe998aa7 | 1052 | ATA/ATAPI-7, it seems to imply that ABRT bit alone could |
40e47125 | 1053 | indicate transfer errors. |
fe998aa7 TH |
1054 | </para> |
1055 | <para> | |
1056 | However, ATA/ATAPI-8 draft revision 1f removes the part | |
1057 | that ICRC errors can turn on ABRT. So, this is kind of | |
1058 | gray area. Some heuristics are needed here. | |
1059 | </para> | |
1060 | </listitem> | |
1061 | </varlistentry> | |
1062 | ||
1063 | </variablelist> | |
1064 | ||
1065 | <para> | |
1066 | ATA/ATAPI device errors can be further categorized as follows. | |
1067 | </para> | |
1068 | ||
1069 | <variablelist> | |
1070 | ||
1071 | <varlistentry> | |
1072 | <term>Media errors</term> | |
1073 | <listitem> | |
1074 | <para> | |
1075 | This is indicated by UNC bit in the ERROR register. ATA | |
1076 | devices reports UNC error only after certain number of | |
1077 | retries cannot recover the data, so there's nothing much | |
1078 | else to do other than notifying upper layer. | |
1079 | </para> | |
1080 | <para> | |
1081 | READ and WRITE commands report CHS or LBA of the first | |
1082 | failed sector but ATA/ATAPI standard specifies that the | |
1083 | amount of transferred data on error completion is | |
1084 | indeterminate, so we cannot assume that sectors preceding | |
1085 | the failed sector have been transferred and thus cannot | |
1086 | complete those sectors successfully as SCSI does. | |
1087 | </para> | |
1088 | </listitem> | |
1089 | </varlistentry> | |
1090 | ||
1091 | <varlistentry> | |
1092 | <term>Media changed / media change requested error</term> | |
1093 | <listitem> | |
1094 | <para> | |
1095 | <<TODO: fill here>> | |
1096 | </para> | |
1097 | </listitem> | |
1098 | </varlistentry> | |
1099 | ||
1100 | <varlistentry><term>Address error</term> | |
1101 | <listitem> | |
1102 | <para> | |
1103 | This is indicated by IDNF bit in the ERROR register. | |
1104 | Report to upper layer. | |
1105 | </para> | |
1106 | </listitem> | |
1107 | </varlistentry> | |
1108 | ||
1109 | <varlistentry><term>Other errors</term> | |
1110 | <listitem> | |
1111 | <para> | |
1112 | This can be invalid command or parameter indicated by ABRT | |
1113 | ERROR bit or some other error condition. Note that ABRT | |
1114 | bit can indicate a lot of things including ICRC and Address | |
1115 | errors. Heuristics needed. | |
1116 | </para> | |
1117 | </listitem> | |
1118 | </varlistentry> | |
1119 | ||
1120 | </variablelist> | |
1121 | ||
1122 | <para> | |
1123 | Depending on commands, not all STATUS/ERROR bits are | |
1124 | applicable. These non-applicable bits are marked with | |
25985edc | 1125 | "na" in the output descriptions but up to ATA/ATAPI-7 |
fe998aa7 TH |
1126 | no definition of "na" can be found. However, |
1127 | ATA/ATAPI-8 draft revision 1f describes "N/A" as | |
1128 | follows. | |
1129 | </para> | |
1130 | ||
1131 | <blockquote> | |
1132 | <variablelist> | |
1133 | <varlistentry><term>3.2.3.3a N/A</term> | |
1134 | <listitem> | |
1135 | <para> | |
1136 | A keyword the indicates a field has no defined value in | |
1137 | this standard and should not be checked by the host or | |
1138 | device. N/A fields should be cleared to zero. | |
1139 | </para> | |
1140 | </listitem> | |
1141 | </varlistentry> | |
1142 | </variablelist> | |
1143 | </blockquote> | |
1144 | ||
1145 | <para> | |
1146 | So, it seems reasonable to assume that "na" bits are | |
1147 | cleared to zero by devices and thus need no explicit masking. | |
1148 | </para> | |
1149 | ||
1150 | </sect2> | |
1151 | ||
1152 | <sect2 id="excatATAPIcc"> | |
1153 | <title>ATAPI device CHECK CONDITION</title> | |
1154 | ||
1155 | <para> | |
1156 | ATAPI device CHECK CONDITION error is indicated by set CHK bit | |
1157 | (ERR bit) in the STATUS register after the last byte of CDB is | |
1158 | transferred for a PACKET command. For this kind of errors, | |
1159 | sense data should be acquired to gather information regarding | |
1160 | the errors. REQUEST SENSE packet command should be used to | |
1161 | acquire sense data. | |
1162 | </para> | |
1163 | ||
1164 | <para> | |
1165 | Once sense data is acquired, this type of errors can be | |
1166 | handled similary to other SCSI errors. Note that sense data | |
1167 | may indicate ATA bus error (e.g. Sense Key 04h HARDWARE ERROR | |
1168 | && ASC/ASCQ 47h/00h SCSI PARITY ERROR). In such | |
1169 | cases, the error should be considered as an ATA bus error and | |
1170 | handled according to <xref linkend="excatATAbusErr"/>. | |
1171 | </para> | |
1172 | ||
1173 | </sect2> | |
1174 | ||
1175 | <sect2 id="excatNCQerr"> | |
1176 | <title>ATA device error (NCQ)</title> | |
1177 | ||
1178 | <para> | |
1179 | NCQ command error is indicated by cleared BSY and set ERR bit | |
1180 | during NCQ command phase (one or more NCQ commands | |
1181 | outstanding). Although STATUS and ERROR registers will | |
1182 | contain valid values describing the error, READ LOG EXT is | |
1183 | required to clear the error condition, determine which command | |
1184 | has failed and acquire more information. | |
1185 | </para> | |
1186 | ||
1187 | <para> | |
1188 | READ LOG EXT Log Page 10h reports which tag has failed and | |
1189 | taskfile register values describing the error. With this | |
1190 | information the failed command can be handled as a normal ATA | |
1191 | command error as in <xref linkend="excatDevErr"/> and all | |
1192 | other in-flight commands must be retried. Note that this | |
1193 | retry should not be counted - it's likely that commands | |
1194 | retried this way would have completed normally if it were not | |
1195 | for the failed command. | |
1196 | </para> | |
1197 | ||
1198 | <para> | |
1199 | Note that ATA bus errors can be reported as ATA device NCQ | |
1200 | errors. This should be handled as described in <xref | |
1201 | linkend="excatATAbusErr"/>. | |
1202 | </para> | |
1203 | ||
1204 | <para> | |
1205 | If READ LOG EXT Log Page 10h fails or reports NQ, we're | |
1206 | thoroughly screwed. This condition should be treated | |
1207 | according to <xref linkend="excatHSMviolation"/>. | |
1208 | </para> | |
1209 | ||
1210 | </sect2> | |
1211 | ||
1212 | <sect2 id="excatATAbusErr"> | |
1213 | <title>ATA bus error</title> | |
1214 | ||
1215 | <para> | |
1216 | ATA bus error means that data corruption occurred during | |
1217 | transmission over ATA bus (SATA or PATA). This type of errors | |
1218 | can be indicated by | |
1219 | </para> | |
1220 | ||
1221 | <itemizedlist> | |
1222 | ||
1223 | <listitem> | |
1224 | <para> | |
1225 | ICRC or ABRT error as described in <xref linkend="excatDevErr"/>. | |
1226 | </para> | |
1227 | </listitem> | |
1228 | ||
1229 | <listitem> | |
1230 | <para> | |
1231 | Controller-specific error completion with error information | |
1232 | indicating transmission error. | |
1233 | </para> | |
1234 | </listitem> | |
1235 | ||
1236 | <listitem> | |
1237 | <para> | |
1238 | On some controllers, command timeout. In this case, there may | |
1239 | be a mechanism to determine that the timeout is due to | |
1240 | transmission error. | |
1241 | </para> | |
1242 | </listitem> | |
1243 | ||
1244 | <listitem> | |
1245 | <para> | |
1246 | Unknown/random errors, timeouts and all sorts of weirdities. | |
1247 | </para> | |
1248 | </listitem> | |
1249 | ||
1250 | </itemizedlist> | |
1251 | ||
1252 | <para> | |
1253 | As described above, transmission errors can cause wide variety | |
1254 | of symptoms ranging from device ICRC error to random device | |
1255 | lockup, and, for many cases, there is no way to tell if an | |
1256 | error condition is due to transmission error or not; | |
1257 | therefore, it's necessary to employ some kind of heuristic | |
1258 | when dealing with errors and timeouts. For example, | |
1259 | encountering repetitive ABRT errors for known supported | |
1260 | command is likely to indicate ATA bus error. | |
1261 | </para> | |
1262 | ||
1263 | <para> | |
1264 | Once it's determined that ATA bus errors have possibly | |
1265 | occurred, lowering ATA bus transmission speed is one of | |
1266 | actions which may alleviate the problem. See <xref | |
1267 | linkend="exrecReconf"/> for more information. | |
1268 | </para> | |
1269 | ||
1270 | </sect2> | |
1271 | ||
1272 | <sect2 id="excatPCIbusErr"> | |
1273 | <title>PCI bus error</title> | |
1274 | ||
1275 | <para> | |
1276 | Data corruption or other failures during transmission over PCI | |
1277 | (or other system bus). For standard BMDMA, this is indicated | |
1278 | by Error bit in the BMDMA Status register. This type of | |
1279 | errors must be logged as it indicates something is very wrong | |
1280 | with the system. Resetting host controller is recommended. | |
1281 | </para> | |
1282 | ||
1283 | </sect2> | |
1284 | ||
1285 | <sect2 id="excatLateCompletion"> | |
1286 | <title>Late completion</title> | |
1287 | ||
1288 | <para> | |
1289 | This occurs when timeout occurs and the timeout handler finds | |
1290 | out that the timed out command has completed successfully or | |
1291 | with error. This is usually caused by lost interrupts. This | |
1292 | type of errors must be logged. Resetting host controller is | |
1293 | recommended. | |
1294 | </para> | |
1295 | ||
1296 | </sect2> | |
1297 | ||
1298 | <sect2 id="excatUnknown"> | |
1299 | <title>Unknown error (timeout)</title> | |
1300 | ||
1301 | <para> | |
1302 | This is when timeout occurs and the command is still | |
1303 | processing or the host and device are in unknown state. When | |
1304 | this occurs, HSM could be in any valid or invalid state. To | |
1305 | bring the device to known state and make it forget about the | |
1306 | timed out command, resetting is necessary. The timed out | |
1307 | command may be retried. | |
1308 | </para> | |
1309 | ||
1310 | <para> | |
1311 | Timeouts can also be caused by transmission errors. Refer to | |
1312 | <xref linkend="excatATAbusErr"/> for more details. | |
1313 | </para> | |
1314 | ||
1315 | </sect2> | |
1316 | ||
1317 | <sect2 id="excatHoplugPM"> | |
1318 | <title>Hotplug and power management exceptions</title> | |
1319 | ||
1320 | <para> | |
1321 | <<TODO: fill here>> | |
1322 | </para> | |
1323 | ||
1324 | </sect2> | |
1325 | ||
1326 | </sect1> | |
1327 | ||
1328 | <sect1 id="exrec"> | |
1329 | <title>EH recovery actions</title> | |
1330 | ||
1331 | <para> | |
1332 | This section discusses several important recovery actions. | |
1333 | </para> | |
1334 | ||
1335 | <sect2 id="exrecClr"> | |
1336 | <title>Clearing error condition</title> | |
1337 | ||
1338 | <para> | |
1339 | Many controllers require its error registers to be cleared by | |
1340 | error handler. Different controllers may have different | |
1341 | requirements. | |
1342 | </para> | |
1343 | ||
1344 | <para> | |
1345 | For SATA, it's strongly recommended to clear at least SError | |
1346 | register during error handling. | |
1347 | </para> | |
1348 | </sect2> | |
1349 | ||
1350 | <sect2 id="exrecRst"> | |
1351 | <title>Reset</title> | |
1352 | ||
1353 | <para> | |
1354 | During EH, resetting is necessary in the following cases. | |
1355 | </para> | |
1356 | ||
1357 | <itemizedlist> | |
1358 | ||
1359 | <listitem> | |
1360 | <para> | |
1361 | HSM is in unknown or invalid state | |
1362 | </para> | |
1363 | </listitem> | |
1364 | ||
1365 | <listitem> | |
1366 | <para> | |
1367 | HBA is in unknown or invalid state | |
1368 | </para> | |
1369 | </listitem> | |
1370 | ||
1371 | <listitem> | |
1372 | <para> | |
1373 | EH needs to make HBA/device forget about in-flight commands | |
1374 | </para> | |
1375 | </listitem> | |
1376 | ||
1377 | <listitem> | |
1378 | <para> | |
1379 | HBA/device behaves weirdly | |
1380 | </para> | |
1381 | </listitem> | |
1382 | ||
1383 | </itemizedlist> | |
1384 | ||
1385 | <para> | |
1386 | Resetting during EH might be a good idea regardless of error | |
1387 | condition to improve EH robustness. Whether to reset both or | |
1388 | either one of HBA and device depends on situation but the | |
1389 | following scheme is recommended. | |
1390 | </para> | |
1391 | ||
1392 | <itemizedlist> | |
1393 | ||
1394 | <listitem> | |
1395 | <para> | |
1396 | When it's known that HBA is in ready state but ATA/ATAPI | |
670e9f34 | 1397 | device is in unknown state, reset only device. |
fe998aa7 TH |
1398 | </para> |
1399 | </listitem> | |
1400 | ||
1401 | <listitem> | |
1402 | <para> | |
1403 | If HBA is in unknown state, reset both HBA and device. | |
1404 | </para> | |
1405 | </listitem> | |
1406 | ||
1407 | </itemizedlist> | |
1408 | ||
1409 | <para> | |
1410 | HBA resetting is implementation specific. For a controller | |
1411 | complying to taskfile/BMDMA PCI IDE, stopping active DMA | |
1412 | transaction may be sufficient iff BMDMA state is the only HBA | |
1413 | context. But even mostly taskfile/BMDMA PCI IDE complying | |
1414 | controllers may have implementation specific requirements and | |
1415 | mechanism to reset themselves. This must be addressed by | |
1416 | specific drivers. | |
1417 | </para> | |
1418 | ||
1419 | <para> | |
1420 | OTOH, ATA/ATAPI standard describes in detail ways to reset | |
1421 | ATA/ATAPI devices. | |
1422 | </para> | |
1423 | ||
1424 | <variablelist> | |
1425 | ||
1426 | <varlistentry><term>PATA hardware reset</term> | |
1427 | <listitem> | |
1428 | <para> | |
1429 | This is hardware initiated device reset signalled with | |
1430 | asserted PATA RESET- signal. There is no standard way to | |
1431 | initiate hardware reset from software although some | |
1432 | hardware provides registers that allow driver to directly | |
1433 | tweak the RESET- signal. | |
1434 | </para> | |
1435 | </listitem> | |
1436 | </varlistentry> | |
1437 | ||
1438 | <varlistentry><term>Software reset</term> | |
1439 | <listitem> | |
1440 | <para> | |
1441 | This is achieved by turning CONTROL SRST bit on for at | |
1442 | least 5us. Both PATA and SATA support it but, in case of | |
1443 | SATA, this may require controller-specific support as the | |
1444 | second Register FIS to clear SRST should be transmitted | |
1445 | while BSY bit is still set. Note that on PATA, this resets | |
1446 | both master and slave devices on a channel. | |
1447 | </para> | |
1448 | </listitem> | |
1449 | </varlistentry> | |
1450 | ||
1451 | <varlistentry><term>EXECUTE DEVICE DIAGNOSTIC command</term> | |
1452 | <listitem> | |
1453 | <para> | |
1454 | Although ATA/ATAPI standard doesn't describe exactly, EDD | |
1455 | implies some level of resetting, possibly similar level | |
1456 | with software reset. Host-side EDD protocol can be handled | |
1457 | with normal command processing and most SATA controllers | |
1458 | should be able to handle EDD's just like other commands. | |
1459 | As in software reset, EDD affects both devices on a PATA | |
1460 | bus. | |
1461 | </para> | |
1462 | <para> | |
1463 | Although EDD does reset devices, this doesn't suit error | |
1464 | handling as EDD cannot be issued while BSY is set and it's | |
1465 | unclear how it will act when device is in unknown/weird | |
1466 | state. | |
1467 | </para> | |
1468 | </listitem> | |
1469 | </varlistentry> | |
1470 | ||
1471 | <varlistentry><term>ATAPI DEVICE RESET command</term> | |
1472 | <listitem> | |
1473 | <para> | |
1474 | This is very similar to software reset except that reset | |
1475 | can be restricted to the selected device without affecting | |
1476 | the other device sharing the cable. | |
1477 | </para> | |
1478 | </listitem> | |
1479 | </varlistentry> | |
1480 | ||
1481 | <varlistentry><term>SATA phy reset</term> | |
1482 | <listitem> | |
1483 | <para> | |
1484 | This is the preferred way of resetting a SATA device. In | |
1485 | effect, it's identical to PATA hardware reset. Note that | |
1486 | this can be done with the standard SCR Control register. | |
1487 | As such, it's usually easier to implement than software | |
1488 | reset. | |
1489 | </para> | |
1490 | </listitem> | |
1491 | </varlistentry> | |
1492 | ||
1493 | </variablelist> | |
1494 | ||
1495 | <para> | |
1496 | One more thing to consider when resetting devices is that | |
1497 | resetting clears certain configuration parameters and they | |
1498 | need to be set to their previous or newly adjusted values | |
1499 | after reset. | |
1500 | </para> | |
1501 | ||
1502 | <para> | |
1503 | Parameters affected are. | |
1504 | </para> | |
1505 | ||
1506 | <itemizedlist> | |
1507 | ||
1508 | <listitem> | |
1509 | <para> | |
25985edc | 1510 | CHS set up with INITIALIZE DEVICE PARAMETERS (seldom used) |
fe998aa7 TH |
1511 | </para> |
1512 | </listitem> | |
1513 | ||
1514 | <listitem> | |
1515 | <para> | |
1516 | Parameters set with SET FEATURES including transfer mode setting | |
1517 | </para> | |
1518 | </listitem> | |
1519 | ||
1520 | <listitem> | |
1521 | <para> | |
1522 | Block count set with SET MULTIPLE MODE | |
1523 | </para> | |
1524 | </listitem> | |
1525 | ||
1526 | <listitem> | |
1527 | <para> | |
1528 | Other parameters (SET MAX, MEDIA LOCK...) | |
1529 | </para> | |
1530 | </listitem> | |
1531 | ||
1532 | </itemizedlist> | |
1533 | ||
1534 | <para> | |
1535 | ATA/ATAPI standard specifies that some parameters must be | |
1536 | maintained across hardware or software reset, but doesn't | |
1537 | strictly specify all of them. Always reconfiguring needed | |
1538 | parameters after reset is required for robustness. Note that | |
1539 | this also applies when resuming from deep sleep (power-off). | |
1540 | </para> | |
1541 | ||
1542 | <para> | |
1543 | Also, ATA/ATAPI standard requires that IDENTIFY DEVICE / | |
1544 | IDENTIFY PACKET DEVICE is issued after any configuration | |
1545 | parameter is updated or a hardware reset and the result used | |
1546 | for further operation. OS driver is required to implement | |
1547 | revalidation mechanism to support this. | |
1548 | </para> | |
1549 | ||
1550 | </sect2> | |
1551 | ||
1552 | <sect2 id="exrecReconf"> | |
1553 | <title>Reconfigure transport</title> | |
1554 | ||
1555 | <para> | |
1556 | For both PATA and SATA, a lot of corners are cut for cheap | |
1557 | connectors, cables or controllers and it's quite common to see | |
1558 | high transmission error rate. This can be mitigated by | |
1559 | lowering transmission speed. | |
1560 | </para> | |
1561 | ||
1562 | <para> | |
1563 | The following is a possible scheme Jeff Garzik suggested. | |
1564 | </para> | |
1565 | ||
1566 | <blockquote> | |
1567 | <para> | |
1568 | If more than $N (3?) transmission errors happen in 15 minutes, | |
1569 | </para> | |
1570 | <itemizedlist> | |
1571 | <listitem> | |
1572 | <para> | |
1573 | if SATA, decrease SATA PHY speed. if speed cannot be decreased, | |
1574 | </para> | |
1575 | </listitem> | |
1576 | <listitem> | |
1577 | <para> | |
1578 | decrease UDMA xfer speed. if at UDMA0, switch to PIO4, | |
1579 | </para> | |
1580 | </listitem> | |
1581 | <listitem> | |
1582 | <para> | |
1583 | decrease PIO xfer speed. if at PIO3, complain, but continue | |
1584 | </para> | |
1585 | </listitem> | |
1586 | </itemizedlist> | |
1587 | </blockquote> | |
1588 | ||
1589 | </sect2> | |
1590 | ||
1591 | </sect1> | |
1592 | ||
1593 | </chapter> | |
1594 | ||
1da177e4 LT |
1595 | <chapter id="PiixInt"> |
1596 | <title>ata_piix Internals</title> | |
58707cce | 1597 | !Idrivers/ata/ata_piix.c |
1da177e4 LT |
1598 | </chapter> |
1599 | ||
1600 | <chapter id="SILInt"> | |
1601 | <title>sata_sil Internals</title> | |
58707cce | 1602 | !Idrivers/ata/sata_sil.c |
1da177e4 LT |
1603 | </chapter> |
1604 | ||
0cba632b JG |
1605 | <chapter id="libataThanks"> |
1606 | <title>Thanks</title> | |
1607 | <para> | |
1608 | The bulk of the ATA knowledge comes thanks to long conversations with | |
1609 | Andre Hedrick (www.linux-ide.org), and long hours pondering the ATA | |
1610 | and SCSI specifications. | |
1611 | </para> | |
1612 | <para> | |
1613 | Thanks to Alan Cox for pointing out similarities | |
1614 | between SATA and SCSI, and in general for motivation to hack on | |
1615 | libata. | |
1616 | </para> | |
1617 | <para> | |
1618 | libata's device detection | |
1619 | method, ata_pio_devchk, and in general all the early probing was | |
1620 | based on extensive study of Hale Landis's probe/reset code in his | |
1621 | ATADRVR driver (www.ata-atapi.com). | |
1622 | </para> | |
1623 | </chapter> | |
1624 | ||
1da177e4 | 1625 | </book> |